WO2008001372A2

WO2008001372A2 - System and method for management of property data and processes

Info

Publication number: WO2008001372A2
Application number: PCT/IL2007/000789
Authority: WO
Inventors: Jacob Zaid
Original assignee: Zaid Orniv Ltd.
Priority date: 2006-06-29
Filing date: 2007-06-28
Publication date: 2008-01-03
Also published as: WO2008001372A3

Abstract

A system and a method for at least semi-automated process management for property-related processes, and preferably also for automated management of property data, optionally allowing security and Business Intelligence mapping management.

Description

SYSTEM AND METHOD FOR MANAGEMENT OF PROPERTY DATA AND PROCESSES

FIELD OF THE INVENTION The present invention relates to a system and a method for management of data concerning land and buildings (collectively described herein as "property"), and in particular, to such a system and method which enable the process of granting and reviewing permissions, and other land and building management activities, to be automated.

BACKGROUND OF THE INVENTION

The management of information about land and buildings, and also about various activities or functions that may be performed with such land or buildings, is an important function of one or more government agencies. The identity of such agencies may differ in different countries; for example, in Israel the responsible government agency is associated with city hall and city government, while in the US, the responsible agency may be associated with county government. However, all of these agencies have roughly similar responsibilities and functions regarding property control and management.

The function of management and control of property and data about the property enables purchasers of land and/or buildings to review the title deeds, while also controlling the use(s) of such land and/or buildings, for example through zoning regulations. Furthermore, this function also controls rights associated with a property, which determine for example whether the owner of the building may add another story to the top of the building and/or add one or more extensions on the sides of the building at ground level (all such rights are collectively termed herein "property improvements" or

"betterment"). These rights also relate to building(s) which may be built on an empty plot of land, for example or to other types of development of the property.

The function of managing these different aspects of properties is related to other governmental functions as well, such as the assessment and collection of property tax, and also other forms of property-related tax, such as betterment tax for example (in which obtaining and/or possessing the rights to improve a property and/or the exercise of such rights incur additional tax under certain circumstances). Furthermore, the government uses the information related to properties to perform other functions, such as long term planning and development, the construction of new or improved infrastructure, the construction of new or improved facilities such as schools and hospitals, and so forth. Despite the importance of such data and management functions, the data is currently collected manually and maintained in a database by one or more government agencies. However, it is also managed manually, in the sense that data from planning applications (requesting a change in zoning status and/or permission(s) associated with a property for example) are entered manually to the database, and then the various tasks associated with determining whether the planning application should be granted are also performed manually. The government agency which performs these functions may have a standard list of activities associated with an examining a planning application, which may be fixed by law, governmental regulation or a combination thereof. However, the result of each such activity in the list must then be entered manually to the database. Manual entry can easily lead to human error and to inefficiency.

If a worker in the agency is overwhelmed with applications and/or is inefficient or incompetent, action on the planning application may be unnecessarily delayed. It is difficult to pinpoint the cause of such delays because different clerks in the agency may have responsibility for different aspects of the planning application review, and since the entire process is managed manually, it is necessary to speak to several different employees before the cause of the delay can be determined. Even if all workers in the agency are active and efficient, external factors may cause delays in processing the planning application which are also difficult to assess, as the process is managed manually.

By way of example only and without wishing to be limited in any way, two illustrative situations are described herein regarding property-related processes. In a first illustrative non-limiting example, a property owner wishes to request permission for a building activity related to the property of the owner. Typically the property owner must fill out a planning application, which may optionally include such details as the plans of building activity, information regarding materials and other parameters as required by law or government regulation, and of course information about the property itself. The receiving clerk must currently manually extract information from the planning application and must then enter it to a database. A process then starts in which the parameters of the proposed building activity are checked against one or more permission(s) already granted to the property owner, as well any building activities already performed by the property owner. Under some circumstances, if a change in permission(s) or even zoning is required, then various other activities may also be necessary, including but not limited to publication of advertisements, informing the near-by or neighboring property owners or even having a public hearing. Clearly, the complexity of this process makes it difficult to manage manually.

In a second illustrative non-limiting example, a simpler situation is presented, in which a prospective purchaser of a property wishes to examine the details of the property before purchase. For example, the prospective purchaser may wish to view any building(s) of the property in place on a map of the area and/or may wish to know which additional permission(s) apply to the property and/or may wish to know the taxes levied on the property. Currently, such information cannot easily be automatically obtained online, but instead requires the prospective purchaser to hire others to perform these activities manually. Unfortunately, currently no solution is available to the problem of manual data entry and management, and manual process control of property management activities by the responsible government agency or agencies.

SUMMARY OF THE INVENTION There is an unmet need for, and it would be highly useful to have, a system and a method for automatically managing property data and also for providing automated process management for property-related processes. There is also an unmet need for, and it would be highly useful to have, a system and method for automatically analyzing planning applications for property to extract the necessary data, and for automatically entering this data into a database.

The present invention overcomes the deficiencies of the background art by providing a system and method for performing one or more these functions in various embodiments. According to preferred embodiments, the system and method of the present invention provide automated process management for property-related processes, and preferably also support the automatic management of property data. Such automatic process and data management provides a secure yet transparent system for property- related processes, reducing the potential for human error and increasing the efficiency of the worker(s) performing these activities. It also enables others, such as supervisory or auditing agencies or workers, to view these processes. Optionally and preferably, the owner of the property (and/or others who have permission by law and/or government regulation) may also be able to view one or more aspects of the property data and/or management processes. According to other preferred embodiments, the system and method of the present invention may optionally and preferably automatically analyze planning applications to extract the necessary data, and may also optionally and preferably automatically enter this data into a database. More preferably, the automatically entered data is then automatically connected to the process management functions of the present invention, thereby enabling a more efficient transfer and distribution of data to the necessary worker (s).

In some locations, these worker(s) who must handle the data and planning applications belong to a planning committee. This term is used herein to describe any type of committee, group, office or agency, or even an individual worker, with responsibility for at least one decision regarding a planning application and/or an executed application and/or a structure (whether under construction or already built).

The system and method of the present invention is preferably structured such that it preferably ensures the integrity of the process on a whole. Preferably this is accomplished by integrating the various system components, thereby allowing communication between modules. Overall system control is preferably performed such that the specific rules relating to a governing body and/or region specific processes are integrated to produce a flowing process that preferably ensures that no step or stage is missed, that compulsory steps are defined and adhered to and that the process is carried out in the correct order relative to the governing body and its specific process. Without wishing to be limited in any way, it is noted that one of the planning committee's duties may optionally include ensuring the overall safety of a structure, preferably ensuring that the appropriate building safety standards and codes are implemented during the construction phase, as well as preferably to ensure that an existing structure or a recently completed structure adheres to all building codes and structural safety requirements. An optional additional embodiment of the system and method of the present invention optionally and preferably allows the planning committee to implement an automated process that preferably assists the planning committee to ensure that the safety requirements of a structure or property are met during the various stages of construction and planning processes.

A still further optional embodiment of the present invention is a security application wherein security information, specific to a property, is preferably mapped and stored as part of the property information database. Such security information may optionally include one or more of information applicable to the structure's interior security (exemplarily including but not limited to one or more of escape routes, fire escapes, emergency stairs and exits) and/or its external security (exemplarily including but not limited to one or more of emergency crews' routes and perimeter based road blockade coordinates).

Optionally the mapping and storing functions of the present invention may include security detail(s) about the property, building or structure. Preferably the security data includes but is not limited to escape or evacuation routes based on the full structure as a single unit or as a plurality of partitions of the complete structure, for example a collection of individual floors of a building, or an individual floor by itself and/or room by room (or any other such partition).

Preferably the security data is linked to the property database according to some embodiments of the system and method of the present invention. The stored security data is preferably sufficient data regarding the structure and one or more functions or interactions with the structure during an emergency situation, including but not limited to protocols that allow the appropriate authorities to handle an emergency situation, preferably including but not limited to earthquake, terror attack or fire. An emergency situation may be understood to optionally be any situation that poses a risk such that the safety of any one of the structure itself or a portion thereof or one or more individuals housed therein is in any way compromised or placed at risk by the emergency event.

Optionally and preferably the stored security data may include but is not limited to signs and indicators that are located on the structure itself, preferably including indicators for all emergency critical points, including but not limited to air ducts, vent ducts, roof escape routes to the roof, escape route to the basements, emergency doors, emergency stair case, emergency exits or any other emergency relief escape route or need.

Optionally the system and method of the present invention supports the storage of vital information for emergency response teams, police, fire, medical personnel, security teams, military or any appropriate authority. The information stored may optionally include but is not limited to details regarding the periphery and area in the vicinity of a construction, optionally including for example road block routes in the direct vicinity and the far perimeter around the construct. Optionally one or more further external escape routes, optionally used to escape the structure from its external face (for example through a window and/or roof escape route) are mapped and available in the database.

A still further optional embodiment of the present invention allows the use of the information stored in a property database to be used for market intelligence information.

A process according to an optional embodiment of the present invention allows for the use of market data - exemplarily including but not limited to customer relationship management (CRM) data - in conjunction with geographical data to map and determine geographical market intelligence information. Preferably the integration of the geographical data is initiated with a geographical coding process (also known as "geo- coding") where a street address is converted into map coordinates, allowing the mapping of addresses onto a map. Similarly, other forms of market information may be optionally included, including but not limited to asset location distribution, routing details, customer support locations, purchasing details, employee details, market research, or any data that may be mapped by optionally and preferably automatically converting a physical address into map coordinates or optionally manually entering map coordinates of asset related data, thereby allowing assets to be readily mapped and visualized on a map.

The preferred conversion of business data including but not limited to assets, customer locations enables the visualizing a set of data on a map that may optionally empower business and decision making processes according to the mapped asset allocation hidden within the raw data. The optional embodiment of the present invention related to business intelligence may optionally and preferably be used in a variety of business settings. For example, it may optionally be implemented as a decision support system allowing the appropriate management of an organization in all of its facets including but not limited to management of one or more of asset portfolios, customer service teams, sales teams, marketing teams, finance and operations by enabling the visualization and geographical mapping of the organization's various facets. Similarly, the application may also optionally be applied to an election setting where much like a client, a voter's behavior and details may be mapped and readily visualized allowing campaign managers to analyze the details at hand using the decision support system of the present invention.

One optional application as a result of customer mapping is the creation of a routing system such that a physical transportation route may be determined for most efficiently traveling to a plurality of clients, optionally based on the customer and/or asset details. Optionally and preferably the routing feature may be implemented in an automatic manner based on the available information.

As described herein, the term "property" refers to land and/or buildings. The term "building" optionally and preferably refers to any type of fixed physical structure which may be constructed on a plot of land. Under some circumstances, the term "building" may also optionally encompass temporary structures which require permission to be erected, as for example temporary tents or other non-permanent buildings which may optionally be associated with a time-delimited event at a particular location (for example on a plot of land). Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this invention belongs. The materials, methods, and examples provided herein are illustrative only and not intended to be limiting.

Implementation of the method and system of the present invention involves performing or completing certain selected tasks or stages manually, automatically, or a combination thereof. Moreover, according to actual instrumentation and equipment of preferred embodiments of the method and system of the present invention, several selected stages could be implemented by hardware or by software on any operating system of any firmware or a combination thereof. For example, as hardware, selected stages of the invention could be implemented as a chip or a circuit. As software, selected stages of the invention could be implemented as a plurality of software instructions being executed by a computer using any suitable operating system. In any case, selected stages of the method and system of the invention could be described as being performed by a data processor, such as a computing platform for executing a plurality of instructions. Although the present invention is described with regard to a "computer" on a

"computer network", it should be noted that optionally any device featuring a data processor and/or the ability to execute one or more instructions may be described as a computer, including but not limited to a PC (personal computer), a server, a minicomputer, a cellular telephone, a smart phone, a PDA (personal data assistant), a pager, TV decoder, game console, digital music player, ATM (machine for dispensing cash). Any two or more of such devices in communication with each other, and/or any computer in communication with any other computer, may optionally comprise a "computer network".

By "online", it is meant that communication is performed through an electronic communication medium, including but not limited to, telephone voice communication through the PSTN (public switched telephone network), cellular telephones or a combination thereof; exchanging, information through Web pages according to HTTP (HyperText Transfer Protocol) or any other protocol for communication with and through mark-up language documents; exchanging messages through e-mail^' (electronic mail), messaging services such as ICQ™ for example, and any other type of messaging service; any type of communication using a computational device as previously defined; as well as any other type of communication which incorporates an electronic medium for transmission.

BRIEF DESCRIPTION OF THE DRAWINGS

The invention is herein described, by way of example only, with reference to the accompanying drawings. With specific reference now to the drawings in detail, it is stressed that the particulars shown are by way of example and for purposes of illustrative discussion of the preferred embodiments of the present invention only, and are presented in order to provide what is believed to be the most useful and readily understood description of the principles and conceptual aspects of the invention. In this regard, no attempt is made to show structural details of the invention in more detail than is necessary for a fundamental understanding of the invention, the description taken with the drawings making apparent to those skilled in the art how the several forms of the invention may be embodied in practice.

It should also be noted that the below diagrams are logic diagrams and may or may not correspond to actual physical and/or code components of the present invention. In the drawings:

FIG. IA is a schematic block diagram of an exemplary system according to the present invention; FIG. IB is a schematic block diagram of an exemplary system according to the present invention;

FIGS. 2 A and 2B relate to property information; Figure 2 A is a detailed schematic block diagram of an exemplary property information module according to the present invention from the system of Figure 1, while Figure 2B relates to property use management;

FIG. 3 shows an exemplary map according to the present invention as part of a GUI (graphical user interface) display;

FIG. 4 is a detailed schematic block diagram of an exemplary property activity module according to the present invention from the system of Figure 1 ;

FIG. 5 is a detailed schematic block diagram of an exemplary property process module according to the present invention from the system of Figure 1;

FIG. 6 is a schematic block diagram of an exemplary implementation of the system of Figure 1 in a system for user access according to the present invention; FIG. 7 shows an exemplary illustrative method according to the present invention for a planning application process;

FIG. 8 shows an exemplary screenshot of a GUI (graphical user interface) display regarding a District Zoning Plan and its statutory stages;;

FIG. 9 shows an exemplary screenshot of a GUI (graphical user interface) display regarding a tax assessment of the value of a granted planning permission;

FIG. 10 shows an exemplary screenshot of a GUI (graphical user interface) display regarding an exemplary meeting agenda for a planning committee meeting;

FIG. 11 shows an exemplary screenshot of a GUI (graphical user interface) display regarding searches through a property information file; FIG. 12 shows an exemplary screenshot of a GUI (graphical user interface) display regarding data entry for a planning application;

FIG. 13 shows an exemplary screenshot of a GUI (graphical user interface) display regarding entering a new event for the property information file;

FIG. 14 shows an exemplary screenshot of a GUI (graphical user interface) display regarding linking one or more external documents to the property information file;

FIG. 15 shows an exemplary screenshot of a GUI (graphical user interface) display regarding entering a new event for a planning application; FIG. 16 shows an exemplary screenshot of a GUI (graphical user interface) display regarding data entry of information regarding building measurements for the planning application;

FIG. 17 shows an exemplary screenshot of a GUI (graphical user interface) display regarding checking building rights (property improvement rights) for a planning application;

FIG. 18 shows an exemplary screenshot of a GUI (graphical user interface) display regarding a search through information related to one or more planning committee meetings; FIG. 19 shows an exemplary screenshot of a GUI (graphical user interface) display regarding entering a new meeting;

FIG. 20 shows an exemplary screenshot of a GUI (graphical user interface) display regarding locking the minutes of a planning committee meeting after it has occurred;

FIG. 21 shows an exemplary screenshot of a GUI (graphical user interface) display regarding entry of free text after the meeting has occurred;

FIGS. 22 A and B relate to the agenda of a meeting, in which Figure 22 A relates to entering items to the meeting and agenda and Figure 22B relates to the list of items on the meeting agenda;

FIG. 23 shows an exemplary screenshot of a GUI (graphical user interface) display regarding a search through information regarding enforcement of building and property rules and regulations;

FIG. 24 shows an exemplary screenshot of a GUI (graphical user interface) display regarding entering details concerning an investigation of a property for one or more violations; FIG. 25 shows an exemplary screenshot of a GUI (graphical user interface) display regarding for entering details of a property that is to be subject to a new investigation;

FIG. 26 shows an exemplary screenshot of a GUI (graphical user interface) display regarding the details of the new investigation;

FIG. 27 shows an exemplary screenshot of a GUI (graphical user interface) display regarding a search through community development plans;

FIG. 28 shows an exemplary screenshot of a GUI (graphical user interface) display regarding data entry of a new plan upon execution to the property registry; FIG. 29 shows an exemplary screenshot of a GUI (graphical user interface) display regarding data of building materials and structural parameters;

FIG. 30 shows an exemplary screenshot of a GUI (graphical user interface) display regarding building parameters; FIG. 31 shows an exemplary screenshot of a GUI (graphical user interface) display regarding statutory stages in the building process with regard to required inspections and approvals;

FIG. 32 is a schematic block diagram of an exemplary system according to an optional embodiment of the present invention; and FIG. 33 shows an exemplary illustrative method according to the present invention for a planning application process.

DESCRIPTION OF THE PREFERRED EMBODIMENTS

The present invention is of a system and a method for at least semi-automated process management for property-related processes, and preferably also for automated management of property data. A "property-related process" may optionally include any type of process performed for management of a property, preferably with regard to any type of legal right or governmental function.

According to preferred embodiments of the present invention, the process management optionally and preferably features information about the property (optionally and preferably including location and other parameters of the property) and also information about the process to be performed with this information. The outcome of each such process, optionally with information about one or more planning applications, is then preferably recorded as a compilation of information about activities performed regarding the property. Optionally and more preferably, the process and/or data associated with the property may be examined from the perspective of each of the above focal points (information about the property, information about the process to be performed regarding the property and information about activities performed with regard to the property). The principles and operation of the present invention may be better understood with reference to the drawings and the accompanying description. Referring now to the drawings, Figure IA is a schematic block diagram of an exemplary, illustrative system according to the present invention for management of property.

A system 100 according to the present invention optionally and preferably features three modules as shown: a property activity module 102, a property process module 104 and a property information module 106. Property information module 106 optionally and preferably includes one or more parameters about the property, including but not limited to the exact location of the property, the boundaries of the property, the boundaries and location of one or more buildings on the property and/or one or more permissions associated with the property. The information may also optionally and preferably include information about the area, such as zoning information for example, which may apply to more than one property in the area. The information in property information module 106 may optionally and preferably be updated and/or changed as one or more activities are performed with regard to the property; however, property information module 106 optionally and preferably features the current data about the property.

Property activity module 102 optionally and preferably features information about one or more activities being performed with regard to the property and/or that were previously performed with regard to the property. Property activity module 102 optionally and preferably includes information about one or more current planning applications, and more preferably also includes information about one or more previous planning applications, most preferably including the outcome of such planning application(s). Although the effect of such application(s) on the property, if successful, is preferably included in property information module 106, the history of such application(s) is preferably included in property activity module 102. More preferably, the history also includes how the application(s) were handled by the responsible government agency or agencies, most preferably including the internal process performed with regard to such application(s).

Property process module 104 preferably communicates with both property activity module 102 and property information module 106 for managing a process regarding the property. For example, property process module 104 preferably communicates with property information module 106 regarding one or more parameters of the property, such as the exact location and boundaries for example, and preferably communicates with property activity module 102 regarding a planning application. Property process module 104 preferably also manages a process regarding the property, optionally and more preferably by including a plurality of stages for the process, and most preferably by enabling the status of the process with regard to each stage to be determined.

Optionally and most preferably, as described herein property process module 104 features one or more control functions, such that a process is not permitted to continue to a subsequent stage before finishing a prior stage if the prior stage is a required (compulsory) stage. According to preferred embodiments of the present invention, as described herein property process module 104 may optionally control access to data through one or both of property activity module 102 and property information module 106. Such access control is preferably combined with process control, such that a worker is preferably not able to access data if such access is not required and/or permitted for the current stage of the process.

Another optional but preferred control function is that of an electronic "signature", in which a worker who is responsible for a particular stage in the process and/or a particular part of a particular stage must sign off upon completion of a task through property process module 104. Such a "signature" may optionally simply feature entry of a positive signifier, including but not limited to a check mark in a check box or selection of

"yes" or any other electronic signifier of signing off on the task. Alternatively or additionally, more elaborate or complex signifϊers may optionally be provided, including actual electronic signatures as are known in the art. Preferably, property process module

104 stores the identity of the worker who signed off on the task as well as the action of entering the signifier, for example for a later optional audit.

Property process module 104 is also optionally and preferably able to determine one or more permissions for one or more activities related to the data regarding one or both of property activity module 102 and property information module 106. For example, certain permission(s) are preferably required before a worker can access and/or change one or more aspects of the information in property information module 106. Optionally, one or more workers may be granted access to information but may not be allowed to change the information, thereby protecting data integrity. Such permissions also enable signing off through electronic signifiers to be performed only by those workers who have permission to sign off. Permissions may also optionally be used for data security, as in the case of sensitive information about a property for example. Although the above is described with regard to permissions for workers, it is understood that one or more permissions for access may optionally be given in a similar manner to the general public and/or to specific members of the general public, such as the property owner for example.

Although specific mention is not made above of one or more databases or other associated information technology, it is understood that data and information are preferably recorded in one or more databases which may optionally be implemented according to any technology known in the art. Non-limiting examples of such technology include Oracle database technology (implemented through SQL) and/or Microsoft Access database technology, or any other suitable database technology as is well known in the art.

The exact structures of such databases may easily be implemented by one of ordinary skill in the art. Non-limiting illustrative examples of such database structures are described in greater detail below. Such database(s) are preferably accessed through one or both of property activity module 102 and property information module 106 as described in greater detail below.

Figure IB is a schematic block diagram of another embodiment of a system 110 according to the present invention for management of property. System 110 provides a property processing management solution which is preferably implemented for governing bodies and systems that require a planning committee (or other similar entity as previously described) to undertake and manage all or part of the property related issues and transactions. System 110 according to the present invention optionally and preferably features four modules as shown: a planning committee module 112, a district zoning plan and town planning module 114, property activity module 116 and a property betterment activity module 118. The overall planning process is preferably coordinated and operated through the planning committee module 112 which may optionally be implemented in a similar manner to the process activity module 104 described in Figure IA above. Planning committee module 112 preferably interacts with the other components of system 110 allowing full process control and visibility of the processes brought before the planning committee. More preferably, any requests regarding a change to an existing or newly designated property are preferably controlled through committee module 112. Property Activity Module 116 preferably interfaces with and controls the various activities of committee module 112. Preferably committee module 112 interacts with the district zoning and town planning module 114 which may optionally be implemented in a similar manner to the property information module 106 of system 100 depicted in Figure IA above. District Zoning and Town Planning Module 114 optionally and preferably includes one or more parameters about the property, including but not limited to the exact location of the property, the boundaries of the property, the boundaries and location of one or more buildings on the property and/or one or more permissions associated with the property. Module 114 may also optionally and preferably include one or more of zoning information for example, the type of structures which may be erected on the property, size limitations, or any restrictions associated with the property. The data stored in the District

Zoning and Town Planning module 114 may optionally and preferably be updated and/or changed as one or more activities are performed with regard to the property; however, optionally and preferably District Zoning and Town Planning module 114 is able to provide both current and historical information about the property, more preferably through some type of simultaneous or comparative display (display itself not shown).

Activities relating to the property are optionally and preferably obtained from the property activity module 116. Any request to change a property is preferably given to a planning committee and processed by planning committee module 112; such a request optionally may not only cause changes with respect to zoning rights controlled by module 112, but rather may also have an effect on government fees, tariffs or taxes that apply to the property. Any change to fees relating to a property change is preferably processed and controlled by the Betterment Activity Module 118. Preferably and optionally changes to a property currently being processed by the planning committee 112 are communicated to the betterment activity module 118 and allows the appropriate tax to be assessed according to the activity undertaken.

Property activity module 116 is a module that optionally and preferably monitors the activities associated with a property. Data relating to a property that is entered in the activity module may optionally originate from the committee planning module 112 and/or from property inspections that are undertaken by the appropriate governing agencies. Any activities undertaken on a property either during the planning stages or any time thereafter are preferably managed by the property activity module 116. Property activity module 116 preferably assists one or more governing bodies, such as the planning committee, to ensure that the use, size or any activity relating to a property is undertaken within the confines of permissions defined by district zoning and town planning module 112.

Property activity module 116 therefore preferably interacts with other components of system 110 to ensure that any activity requested or undertaken on a given property is appropriate. To this end, if any activity is registered that is not permitted according to one or more components of system 110, one or more components are preferably updated accordingly, ensuring that appropriate action(s) are taken. For example, if a person added a floor to a building, the property activity module 116 updates the betterment activity module 118 to ensuring that the proper taxation information is updated if this is required by law or regulation. The information contained in activity module 1.16 is optionally based on two sources: primary sources (such as the deed registry for example) and the planning committee and inspections performed by the appropriate governing body. Although specific mention is not made above of one or more databases or other associated information technology, it is understood that data and information are preferably recorded in one or more databases which may optionally be implemented according to any technology known in the art. Non-limiting examples of such technology include Oracle database technology (implemented through SQL) and/or Microsoft Access database technology, or any other suitable database technology as is well known in the art. The exact structures of such databases may easily be implemented by one of ordinary skill in the art. Non-limiting illustrative examples of such database structures are described in greater detail below. Such database(s) are preferably accessed through any one of the components of system 110. Figures 2A and 2B relate to property information. Figure 2A is a detailed schematic block diagram of an exemplary property information module according to the present invention from the system of Figure 1. As shown, property information module 106 optionally and preferably features a property process module interface 200, which communicates with property process module 104. In turn, each module of property information module 106 optionally and preferably communicates with property process module interface 200. Such communication may optionally and preferably be performed according to any standard protocol or language, including but not limited to XML or HTML, or any other mark-up language; preferably communication is performed through HTTP although again any type of communication protocol may optionally be used. A property location module 202 optionally and preferably accesses, and more preferably is able to change, information about the location of the property, preferably including but not limited to the geographical location of the property, the boundaries of the property, and also such legal geographical designations as block, parcel and so forth, which also refer to the location of the property. Property location module 202 optionally may further be able to display the construction plans, lot details or any other information specific to or within a particular property. Optionally data analysis may be performed on a property, providing visualization of data related to a property, including but not limited to property designation. Optionally, various layers of a property may also be visualized separately, for example a specific floor of a building, or a roof of a building or the like.

This information is optionally and preferably stored in a location database 204 or in Property Event database 222, and is preferably related to or obtained from one or more activities of the Property event module 224. Property event module 224 and Property Event database 222 preferably interact to ensure the overall integrity of the process being undertaken. Property event database 222 ensures that all steps or stages are defined, that no step or stage is omitted and that any compulsory steps or stages are defined as such.

Property event module 224 communicates to the appropriate module any compulsory step or stage that is required, thereby preventing the process from continuing if the compulsory step or stage has not been completed.

Property location module 202 also optionally and preferably features a map reader

206, which is able to read the information from location database 204. Map reader 206 may also optionally be able to construct one or more maps for viewing which include location information about the property, for example by showing the boundaries of the property on a map of the area.

Alternatively or additionally, such functionality may be located at property process module 104.

Regardless of the location of the functionality, map reading and optionally map construction are preferably performed by using one or more tools provided by an outsourced software agent including but not limited to the tools offered by ESRI (California, USA) or Maplnfo (New York USA). Optionally the outsourced agents' tools that are used may include but are not limited to one or more of ESRTs ArcIMS, ArcGIS and ArcObjects or Maplnfo's Maplnfo Professional, Map Basic and MapXTreme. These tools or any other suitable tools that are known in the art optionally and preferably enable geographic information to be captured in a digital form, stored, updated and then converted automatically to one or more maps for viewing. Any changes to the data for updating are preferably then automatically propagated to the generated maps, such that manual intervention is preferably not required. Optionally and preferably, if required these tools support various mapping regulations and/or laws which may vary by country. For example, digital mapping may optionally be performed according to a digital landscape model (DLM) at full detail (e.g., scale of 1 : 10,000), or at coarser resolutions (scales of 1 :50,000 and 1 :250,000). Each DLM is in turn the starting point for one or more derived digital cartographic models (DCM or DKM), which relate to the actual visual representation of the map itself to the human eye. These latter models may rely more on visual clarity than on exact digital representation of the geographical data.

Also optionally and preferably, map reader 206 is able to convert paper maps to digital geographical information, for example by featuring raster to vector conversion. A non-limiting example of software for performing such a function is the ArcScan for

ArcGIS tool of ESRI, although alternatively any suitable software tool as is known in the art could be used.

Also optionally and preferably, map reader 206 is able to extract data from digital drawings such as those created by AutoCAD or other automated drawing software. These digital drawings feature a list of objects and their position on the drawing. Map reader

206 is preferably able to read map information as a set of polygons from the digital drawing, and to determine the area, size and boundaries of each polygon. Map reader 206 is then optionally and preferably able to relate these polygons to the boundaries of the property, for example regarding the boundaries of land and/or one or more buildings, and/or an apartment or other portion of a building, and other map related information regarding the property. Map reader 206 may also optionally be able to read information about neighboring properties and/or other properties in the area, and to also show these properties on a map. Map reader 206 may also optionally be able to create a correlate between two layers of information on a map, thereby creating a new layer; such layers are well known in the art. Preferably map reader 206 is able to update and make changes to existing layers or polygons, calculate area of a polygon. ArcIMS of ESRI is preferably used with the ArcObjects tools of ESRI for reading digital drawings, although again optionally any type of suitable tool that is known in the art may be used, for example

MapXTreme 2005 offered by Maplnfo Ltd. These tools may optionally be purchased "off the shelf from ESRI or Maplnfo and implemented in the present invention as a non-limiting example of map generating software. Figure 3 shows an exemplary map according to the present invention as part of a GUI (graphical user interface) display. Various portions of the map are optionally and preferably marked in different colors and/or patterns, which are then preferably linked to a map key. Optionally, the user could indicate a part of the map with a mouse or other pointing device, which could then enable the user to access information about the property or properties associated with that portion of the map (not shown). Optionally, a user may navigate within the map by using tools including but not limited to zoom in, zoom out, move, extended zoom, zoom preview. Optionally, some of the data is only made available once the map is zoomed in on a particular object. Also optionally, information about objects found within the map may be accessed by selecting a particular object where preferably all of the details regarding the selected object are made available to the user. Preferably selecting an object within the map is undertaken with mapping tools including but not limited to zoom to select, or clear selection.

Turning back to Figure 2A, a building plan module 216 preferably communicates with a building plan database 218 for storing information about one or more buildings or portion(s) of buildings associated with the property. For example, if the property is a single apartment in a building, then building plan database 218 preferably stores at least the plan for that apartment, but more preferably also stores the plan for the entire building. If the property is an entire building, then preferably building plan database 218 stores the plan for the entire building.

Building plan module 216 is also preferably able to retrieve, add and/or alter information to building plan database 218. Building plan module 216 optionally and preferably features a building plan reader 220 for retrieving, adding and/or altering information in building plan database 218. As described above with regard to map reader 206, building plan reader 220 is optionally and preferably able to automatically extract information from digital drawings, for example to extract objects in these drawings as a plurality of polygons and to analyze them

More preferably, building plan reader 220 is able to determine the size, area and boundary of each polygon and to place it on a building plan for the building (or at least for a portion of the building, as for an apartment for example). Alternatively, such functionality may be located at property process module 104. Similar software tools as described above may optionally be used for performing these functions or alternatively other tools that are well known in the art may be used. A property owner module 212 is preferably able to provide information regarding the owner of a property, and more preferably is able to retrieve, add or alter such information, which is more preferably stored in a title deed information database 214. Title deed information database 214 preferably stores information about at least the current owner, including but not limited to identification information (such as a national identification number or a company identification number if applicable), current address and so forth. If the owner is a company, optionally information about the company owner and/or corporate officers may be stored. Title deed information database 214 also optionally and preferably stores information about one or more previous owners, preferably including the details of transfer of ownership of the property. Title deed information database 214 may also optionally and preferably store an image of the title deed itself and/or any other information about the title deed. However, optionally and preferably, the actual title deed registry (property registry) is present at a separate location and is preferably not managed through property owner module 212. A building rights module 208 is preferably able to provide information regarding one or more building rights associated with the property (which may also be termed "betterment rights"), which may optionally include information about building rights in the area and/or permitted function(s) of the property and/or of the area (such as zoning information for example). Building rights module 208 is more preferably able to retrieve, add or alter such information, which is more preferably stored in a building rights database 210. Such information optionally and preferably includes a description of the building rights, whether such rights have already been used, the value of such rights (for taxation purposes for example) and so forth.

It should be noted that although the above figure is described with regard to a plurality of databases, optionally a single database could be used, or alternatively a plurality of databases could optionally be implemented but with a different structure. The above description is provided for the purposes of clarity only and is not meant to be limiting in any way. Furthermore, all figure descriptions provided herein with regard to databases may optionally be so implemented and/or altered. Figure 2B relates to a process for managing community development planning as related to property and property information, which may optionally be performed with regard to property process module 104 or alternatively may optionally be performed with the above modules as described in Figure 2A. By "community development planning" it is meant any type of overall plan for an area, which may optionally be for a city, a metropolitan area, a county or any other area. Such planning also provides a basis for the use and development of land, for example with regard to zoning, the location of roads and such amenities as schools and hospitals for example. Community development planning also impacts later use of land, including building on land and making improvements to the land. As described in greater detail below, if a proposed use of land and/or a proposed building to be built on the land does not fit the initial community development plan, then preferably special permission must be sought and given, more preferably in a parallel process to the property process described in greater detail below. Such special permission optionally and preferably is performed in a process according to laws and/or regulations, with one or more statutory stages. Such a management process is described briefly below; it should be noted that greater detail is provided with regard to a parallel process, for managing building applications, as described with regard to Figure 7. Turning now to Figure 2B, as shown in stage 1 a community development plan is created. This plan forms the basis for property use, including land use and/or building use, and is typically created for an area which encompasses a plurality of properties.

In stage 2, an application to alter property use is submitted, for example by altering the zoning for a property (from residential to commercial or vice versa for example). In stage 3, the property use application is analyzed and data extraction is performed. In stage 4, a process is constructed for the property use application, optionally and preferably according to one or more rules and/or regulations. More preferably at least a portion of the process is constructed automatically according to such one or more rules and/or regulations and most preferably also according to data extracted from the application For example, preferably each such process is examined to determine any checkpoints, milestones or landmark points or stages that may be defined within the process or project being undertaken. A landmark stage defined within the process may preferably and optionally be further defined as either a compulsory stage or a non- compulsory stage. Preferably, a compulsory stage is one that must be completed before the process is allowed to move forward. Preferably, a non-compulsory stage is optionally marked as a milestone stage, however, the overall process may continue even if the non- compulsory stage has not been completed. In stage 5 a worker is notified of required activity. In stage 6, the worker performs the activity and preferably signs off. In stage 7, a planning meeting is optionally and preferably held to discuss the application for those jurisdictions requiring or recommending such a meeting. It should be noted that stages 5-7 may optionally be performed a plurality of times, alone or in combination.

In stage 8, the application is approved or rejected. Of course, other outcomes are possible (for example requesting more information, returning the application to an earlier stage in the process and so forth). Also other stages may optionally be required for example in order to advertise the proposed property use change. Figure 4 is a detailed schematic block diagram of an exemplary property activity module 102 according to the present invention from the system of Figure 1. As shown, property activity module 102 optionally and preferably features property process module interface 200, which communicates with property process module 104 as previously described. Property activity module 102 also optionally and preferably features a planning application module 400 which in turn communicates with a planning application database

402. Property process module 400 is preferably an integral part of the system of the present invention according to the embodiment shown herein as property process module

400 preferably communicates with the other components of property activity module 102, and more preferably communicates with the other components of the system as previously described, to ensure that the overall process itself is intact and uniform, and that all stages, preferably including compulsory and non-compulsory stages, are properly performed.

Optionally and preferably any created action or event may be identified according to an identification number to ensure system integrity and ability to reference any event. Planning application module 400 is optionally and preferably able to retrieve, add and/or alter information from a planning application to planning application database 402.

Planning application information optionally and preferably includes but is not limited to information regarding the property, an identifier for the planning application, a description of one or more activities for execution, a drawing of the plan, the one requesting the planning application (which may optionally be the owner of the property and/or leasing the property for example), one or more professional entities for executing the plan and/or managing the plan, and any other requests or information. Information regarding the property may optionally be provided with regard to an identifier which allows planning application module 400 to retrieve the necessary information from property information module 106. The property identifier is preferably associated with the planning application identifier in planning application database 402.

Planning application module 400 is optionally and preferably able to read digital drawings for example for automatic conversion of digital drawing information in a plan to one or more parameters as required for processing the planning application. Additionally or alternatively, planning application module 400 is optionally and preferably able to read a plan image from paper and to digitize the plan information to form a digital drawing by optionally using Map Reader module 206 through interface module 200. Such functionality may optionally be provided as described with regard the map reader 206 and/or building plan reader 220 of Figure 2, and/or according to any other suitable implementation as is well known to one of ordinary skill in the art.

Property activity module 102 also optionally and preferably features a statutory stage and event module 404 which in turn communicates with a statutory stage and event database 406 for retrieving, adding and/or altering property event information. Property event information optionally and preferably includes but is not limited to actual building on the property, alterations to the property and any other information regarding the physical status of the property. Property event information may also optionally relate to physical events that are in progress, such as tearing down an old building and then building a new building, adding a floor to an existing building and/or a room to an existing apartment or building, and so forth.

Planning location module 408 and planning location database 410 preferably interact to ensure the overall integrity of the process being undertaken. Planning location database 410 preferably ensures that all steps or stages are defined, that no step or stage is omitted and that any compulsory steps or stages are defined as such. Planning location module 408 preferably communicates to the appropriate module any compulsory step or stage that is required, preferably preventing the process continuing if compulsory step or stage has not been completed.

Figure 5 is a detailed schematic block diagram of an exemplary property process module 104 according to the present invention from the system of Figure 1. As shown, property process module 104 preferably features separate interfaces to property activity module 102 and property information module 106, shown as property activity interface

500 and property information interface 502 respectively. These interfaces enable property process module 104 to obtain the necessary information and/or to store such information as part of the performance of the process.

Property process module 104 also optionally and preferably features a user interface module 504 which provides the user interface to outside users, including presenting information to the user and also receiving information from the user (not shown; see Figure 6). User interface module 504 may optionally and preferably communicate with the user interface according to any known protocol, such as HTTP for example. User interface module 504 optionally and preferably features an electronic signature module 514 for enabling the user to "sign off' on some aspect of the process and/or data associated thereto. As previously described, the user may optionally sign off by providing some type of positive electronic indication, which may optionally include an electronic signature as is well known in the art.

User interface module 504 optionally and preferably communicates with a permissions module 506, which determines whether certain information may be shown to the user and/or whether the user has authority to "sign off' on one or more tasks within the process. Permissions module 506 optionally and preferably filters all information and communication between user interface module 504 and other parts of property process module 104 as shown, for data and process security. Optionally and more preferably, permissions module 506 enables the retrieval of information through property activity interface 500 and property information interface 502 if the user has one or more permissions necessary for retrieving such information.

Permissions module 506 optionally and preferably determines the one or more permissions for the user according to information stored in a permissions database 508. Such information may optionally be retrieved, added or altered by permissions module 506.

Permissions module 506 is also preferably in communication with a process stage module 510, which controls the different stages of the process and also determines which stage is the current stage for the process, as well as the identity of the past stage(s) and the future stage(s) of the process. Process stage module 510 preferably stores, retrieves, adds and alters such information in a process stage database 512, which preferably also records information concerning the overall process, the status of each stage of the process, whether any information or documentation are missing (and hence which must be submitted), and also optionally whether the property is involved in more than one process. Process stage module 510 also preferably determines whether the process may proceed to the next stage, as well as the user(s) required for that stage and also any missing information or documentation that are necessary for that stage.

For certain legal and/or governmental regulatory reasons, one or more stages may require a meeting of a planning committee. This meeting may then optionally result in a decision of some type, as opposed to having a decision made by a single worker.

Preferably process stage module 510 stores the minutes of the planning committee meeting, the decision of such a meeting and whether any information or documentation was determined to be missing at the meeting. Also process stage module 510 optionally and preferably supports scheduling of the meeting, for example by providing a list of individuals and/or departments who must participate, and also optionally by including a calendar and diary function for determining the availability of each participant.

One or more stages may also optionally require publication of one or more details of the planning application, for example in a newspaper and/or by placing a sign at the physical site of the property. Process stage module 510 also optionally and preferably includes one or more tasks related to such a publication, optionally including contacting one or more outside organizations to perform such a publication.

One or more stages may also optionally permit a protest to be lodged by a member of the public against a planning application, for example to protest an added building permission and/or a change in zoning. Process stage module 510 also optionally and preferably includes one or more tasks related to such a protest, optionally including requiring such a protest to be considered by a worker and/or by a planning committee, for example during a planning committee meeting.

Optionally and preferably process stage module 510 is able to determine statistics regarding how these processes are performed and more preferably is able to determine the efficiency of the process as part of management of such property process(es). For example, optionally and preferably such statistics include information regarding how many different applications of each type were received, how much time was required to handle each one and so forth. Figure 6 is a schematic block diagram of an exemplary implementation of the system of Figure 1 in a system for user access according to the present invention, shown as system 600. System 600 optionally and preferably features one or more user interfaces; as shown, different types of user interfaces may be provided. For example, system 600 may optionally feature a public user interface 602 for a user who is a member of the public. Such a user may still need to provide evidence of identity, for example to prove that the user is owner of a property; alternatively, the user may optionally be any member of the public. System 600 also optionally and preferably features a worker user interface 604, which is preferably located behind a firewall 606. Worker user interface 604 preferably provides access related to the job function of the worker who "logs in" to worker user interface 604. Firewall 606 preferably protects the integrity and security of the data and processes of system 100, although optionally and alternatively or additionally any type of security system could be used. Optionally, an intranet is located behind firewall 606 for connecting worker user interface(s) 604 to system 100 (not shown).

Public user interface 602 optionally and preferably connects through firewall 606 to gain access to system 100 as shown. Such a connection could optionally be made through the Internet or alternatively through a kiosk or other computational device (not shown). Such a kiosk or other computational device could optionally be physically located in the same building or area as system 100, and thereby could optionally be connected to the intranet through firewall 606 (not shown).

System 100 could optionally and preferably be operated by a server 608 as shown, although alternatively the different components of system 100 could optionally be operated by a plurality of computers such as a plurality of servers (not shown). Server 608 optionally and preferably communicates with the various user interfaces through HTTP and/or any other suitable communication protocol.

According to optional but preferred embodiments of the present invention, system

600 preferably permits members of the public to retrieve and/or enter data through public user interface 602. For example, members of the public who are considering whether to request a building permit to add to their property may optionally and preferably determine property tax information on the planned structure based on the building permit(s) and the governmental tax structure. System 100 is preferably able to calculate this information based upon the building plan submitted with the planning application and any necessary tax information. System 100 is also preferably able to calculate any additional fees which may be required for the actual permit and/or building process, such as a betterment tax

(described in greater detail below). A member of the public is also optionally and preferably able to access building plan and/or map information regarding a property through public user interface 602.

Optionally the user may be required to show proof of ownership of the property, but alternatively the user may be any member of the public, as for example when a neighbor to a property wishes to determine whether any planning applications have been submitted and/or special permissions requested. Preferably, the user is able to see actual building plans and/or maps, more preferably with one or more neighboring properties indicated and also more preferably with the proposed change(s) highlighted. This functionality was previously described with regard to Figure 2 and could optionally be implemented here as well

System 600 also optionally and preferably supports an online information retrieval service for the public, including but not limited to such data as all of the planning application(s) that have been filed/requested for a property, the current stage for processing of the planning application, who is responsible for the planning application (optionally including the name of any professionals handling it for the property owner and/or one or more responsible workers), a list of missing but required details or information, the owner of the property, the person or company submitting the planning application and so forth. Optionally and preferably, such on-line access does not include data that that is currently before the planning committee. Also optionally and preferably, system 600 supports the more general retrieval of on-line information regarding property tax records by members of the public, optionally allowing members of the public to obtain a personal view of the property tax account information including receipts and computerized building plan.

Optionally and preferably, system 600 supports one or more workers in the field, for example surveyors. This support permits surveying information such as measurements from surveyor to be added the appropriate database, as well as permitting analyses for enforcement of property rights and requirements. For example, it is possible to determine whether a permitted building was built correctly and in the correct area. This work (at least regarding gathering information about physical characteristics of property) must be done in the field at the property itself. Preferably, periodic examinations are performed according to laws/regulations.

To provide such support, optionally and preferably system 600 features a remote device 610. Remote device 610 is preferably any type of wireless device, including but not limited to a PDA, laptop, any type of handheld computer, mobile telephone, GPS device or any other suitable device for checking property in the field. Remote device 610 is preferably able to send and receive information, and more preferably is granted at least some access permissions as for worker user interface 604 Figure 7 shows an exemplary illustrative method according to the present invention for a planning application process. As the requirements and regulations for submitting and obtaining approval for a planning application differ widely from country to country and even within countries, the below method is descriptive only and is not meant to be limiting in any way. As shown, in stage 1 a planning application is submitted. The planning application optionally and preferably features a drawing of the proposed plan, information regarding the property, details regarding the applicant (who may also be the owner of the property) and optionally details regarding one or more professionals who will do the actual work.

In stage 2, the planning application is analyzed and data extraction is performed. If the drawing of the plan is on paper, it is preferably scanned and digitized as previously described. Electronic drawings are preferably analyzed as previously described.

In stage 3, a process is constructed for the planning application. The process may optionally feature a plurality of stages as determined by law and governmental regulation. The process is optionally determined automatically, for example according to the type of activity or activities requested in the planning application. Preferably at least some manual input or intervention is at least permitted if not required for process construction. The process preferably includes such information as to who handles each stage, whether a planning committee meeting is required and whether contact with an external organization is required (for example for publication of an advertisement regarding the planning application). If a time factor is required, for example that a publication be made at least 30 days before the next decision is taken, then the process is preferably held at this stage until the required time has elapsed.

In stage 4, the planning application enters the first process stage, which for example may optionally require activity by a worker. If so, then in stage 5 data is given to the worker, for example in a message through the user interface, indicating that an activity by the worker is required. In stage 6, the worker performs the activity and signs off electronically, for example through an electronic signature. In stage 7, the next process stage may optionally require a meeting. Preferably the meeting participants are notified, more preferably electronically, and the meeting agenda is set. The meeting agenda may optionally feature a plurality of planning applications and may require one more decisions to be made by a planning committee. In stage 8 the meeting is held and the minutes are preferably recorded. The decision of the meeting may optionally indicate that one or more documents or information is missing, in which case the process is held until the missing documents or information is supplied. Alternatively, the decision of the meeting may be to proceed or stop completely. In stage 9, if the decision of the meeting is to proceed and if that is the final decision required, the applicant is notified that the planning application was granted. Of course, one or more additional stages may be required; optionally any one or more of the above stages may be repeated.

Preferably the system of the present invention receives input regarding the decision(s) after the meeting as part of an automatic process to determine the next correct stage (and/or the next event within a stage) after each stage and/or event has passed, including receiving decision from the meeting. The system of the present invention may also optionally block further work on an application until one or more conditions and/or requirements for a particular stage are met, as part of managing the planning process, for example by locking the process(es) and/or actions which may optionally be performed on an application.

Figure 8 shows an exemplary screenshot of a GUI (graphical user interface) display of the District Zoning Plan and Town Planning Module 114 as described in figure

IB above, regarding a property and the process stages, showing both recent and current actions. This display may optionally be viewed by a worker for example, enabling the worker to see various activities for which the worker is responsible and the process stage for each property involved. As shown, details of each stage are given, where the stage stands (for example, halted because of lack of information and/or the requirement for time to elapse; passed; blocked; to be performed in the future; and so forth). If a meeting is required but has not yet been held, then this is indicated along with the proposed meeting date; alternatively if the meeting was held already, then the meeting identifier is given.

The estimated time for performing the stage is given; if the stage has been completed then the actual time of completion is given. On the bottom row, a more detailed view of a particular stage is given, which the user may optionally access by clicking on or otherwise selecting one of the properties listed above with a mouse or other pointing device. This detailed view may optionally include a plurality of events that comprise each stage, the name of the worker responsible for the stage and the date of the next action to be taken.

On the right hand side, a menu list is provided, which optionally permits the user to determine the physical location of the paper plans, access documents electronically, determine which changes have been made to the property already (whether physical or in planning permissions) and so forth. Figure 9 shows an exemplary screenshot of a GUI (graphical user interface) display of the Betterment Activity Module 118 as described in figure IB above, regarding a tax assessment of the value of a granted planning permission. In certain jurisdictions, a betterment tax is required if the value of the property is raised. Depending upon local laws and regulations, the value may optionally be raised if one or more new planning permissions are granted to the owner of the property and/or if actual construction of some type occurs on the property. A tax on this increased value may be levied in some jurisdictions, optionally at particular points in the life cycle of the property (for example when the property is sold and/or when the new planning permissions are used) or alternatively as part of the regular taxation scheme of the government. This screenshot shows a display which indicates certain processes which are required for this type of value and tax assessment for a particular jurisdiction.

As shown, the display relates to a particular property which may optionally be indicated by a property identifier such as a number for example. Also optionally, a planning application identifier is given (this may optionally be a "dummy" number if in fact the permission is being granted as a result of an action by the government rather than through a request by the property owner). The value is optionally assessed by a government worker or workers as shown, who preferably receive an automatically generated request to do this work by the present invention. This value is then preferably sent to the property owner, who has a certain period of time to respond, for example 30 days. Optionally and preferably the present invention is able to automatically construct a letter with all of the necessary information, including the added tax that would become due, for the property owner. The amount charged may optionally be calculated also according to consumer price index, inflation information and/or any other pricing scheme or information, or a combination thereof.

The value assessment may optionally feature a plurality of components as shown, depending upon the local laws and regulations. If the property owner disputes the valuation, in some jurisdictions the owner may present a separate valuation. This is also preferably recorded. The dispute between these valuations may optionally be settled in a hearing and/or through direct negotiation of the evaluators, for example. Negotiations to set the amount for the valuation may optionally be performed according to negotiations between the owner and/or any representative thereof and a representative of the government. Optionally and preferably the process of negotiations is also managed, for example according to one or more rules and/or regulations, but preferably at least such that information regarding the negotiations is recorded for possible future examination.

Figure 10 shows an exemplary screenshot of a GUI (graphical user interface) display, of the Planning committee Module 112 as described in figure IB above, regarding an exemplary meeting agenda for a planning committee meeting. The display preferably indicates each property, the stage of the planning process, information that is available, information that is missing and optionally links to one or more documents for the meeting.

The meeting date is also preferably given. After the meeting has taken place, this information is preferably stored with the minutes of the meeting and any decisions taken thereto.

Figures 11-14 relate to the user experience in- interacting with an exemplary implementation of software for the system and method according to the present invention, with regard to the property activity information file. The property activity information file may also optionally be termed a "building file" as it may optionally and preferably relate to a physical structure located on the property, although this should not be construed as a limitation. Figure 11 shows an exemplary screenshot of a GUI (graphical user interface) display regarding searches through a property activity information file.

Figure 12 shows an exemplary screenshot of a GUI (graphical user interface) display regarding data entry for a planning application. Exemplary and illustrative parameters for such data entry include but are not limited to the plan itself (preferably as a drawing), a plan identifier, a plan name, the stage of the process for examining the plan application for approval (preferably this is automatically entered from another module in the system as previously described), a description of the process stage, the date of the start and (if available) completion of the stage, the type of stage, the legal geographical identification information for the property (such as the block and parcel information), the area of the property, the current or proposed use of property, which betterment and/or building rights are available, and free text entry. Figure 13 shows an exemplary screenshot of a GUI (graphical user interface) display regarding entering a new event for the property activity information file. Exemplary and illustrative parameters for such data entry include but are not limited to the type of event, status of the event, the person who is handling the event, when the event was entered, who entered it, an automatic link to the event (preferably this cannot be changed as it is preferably entered by another module in the system), an indicator or flag (for example optionally for potential problems) and comments.

Figure 14 shows an exemplary screenshot of a GUI (graphical user interface) display regarding linking one or more external documents to the property information file. These external documents may optionally be any type of document, including but not limited to filled out forms or other documentation, building plans (for example as AutoCAD drawing files) and calculations regarding money and/or building value (for example as Microsoft Excel and/or other spreadsheet files).

Figures 15-17 relate to the user experience in interacting with an exemplary implementation of software for the system and method according to the present invention, with regard to planning applications. Figure 15 shows an exemplary screenshot of a GUI (graphical user interface) display regarding entering a new event for a planning application. Such an event may optionally have parameters as previously described for other types of events.

Figure 16 shows an exemplary screenshot of a GUI (graphical user interface) display regarding data entry of information regarding building measurements for the planning application. Such building measurements preferably include but are not limited to height of the building, length and width measurements, the footprint or area occupied by the building and so forth. These measurements may optionally be entered manually as shown or alternatively may be automatically filled in from one or more electronic drawings of the plans as previously described (optionally with manual overview of the results by a user).

Figure 17 shows an exemplary screenshot of a GUI (graphical user interface) display regarding checking building rights (property improvement rights) for a planning application. Building rights or betterment rights optionally include any type of property improvement rights as previously described. Exemplary and illustrative parameters for such data entry include but are not limited to the type of rights, the purpose for obtaining and/or using these rights, limits of these rights, the plan number, the previous value of the property, the additional value provided by the betterment rights and the combination of the new and previous values.

Figures 18-22 relate to planning committee meetings that are held to consider planning applications

These figures relate to a particular aspect of process management, as in some jurisdictions, review of planning applications and approval/denial is required by law or regulation to be performed by a committee. These figures relate to various aspects of such meetings which may optionally be managed and recorded by the system and method of the present invention. Figure 18 shows an exemplary screenshot of a GUI (graphical user interface) display regarding a search through information related to one or more planning committee meetings.

Figure 19 shows an exemplary screenshot of a GUI (graphical user interface) display regarding entering a new meeting, which for example may optionally include such information as date, time, location, participants and so forth.

Figure 20 shows an exemplary screenshot of a GUI (graphical user interface) display regarding locking the minutes of a planning committee meeting after it has occurred. Such locking may optionally be required by law and/or regulation, so as to provide a definitive record of the discussion during the meeting. Optionally an electronic signature may be required by one or more users as part of the locking process.

Figure 21 shows an exemplary screenshot of a GUI (graphical user interface) display regarding entry of free text after the meeting has occurred.

Figures 22A and B relate to the agenda of a meeting, in which Figure 22 A relates to entering items to the meeting and agenda, and Figure 22B relates to a display of the list of items on the meeting agenda. This enables details of each item to optionally be provided to meeting participants before the meeting. Information on the meeting agenda may optionally relate to any aspect of the application, including but not limited to missing material, information on the building file, information on the property, details of the application and so forth. Preferably the agenda also includes a list of information on the subject(s) to be discussed, including whether the application is opposed, the nature of a decision to be taken and so forth.

Figures 23-26 relate to enforcement of property laws and regulations, preferably including building code enforcement Figure 23 shows an exemplary screenshot of a GUI (graphical user interface) display regarding a search through information regarding enforcement of building and property rules and regulations.

Figure 24 shows an exemplary screenshot of a GUI (graphical user interface) display regarding entering details concerning an investigation of a property for one or more violations.

Figure 25 shows an exemplary screenshot of a GUI (graphical user interface) display regarding for entering details of a property that is to be subject to a new investigation.

Figure 26 shows an exemplary screenshot of a GUI (graphical user interface) display regarding the details of the new investigation. Exemplary and illustrative parameters for such data entry include but are not limited to a code for the type of investigation, the type of request, dates related to the investigation, who entered the new investigation, whether it was completed and/or closed, and free text entry.

Figures 27-31 relate to community development plans Figure 27 shows an exemplary screenshot of a GUI (graphical user interface) display regarding a search through such community development plans. As noted previously, community development plans relate to potential and planned property use. The search allows the user to view information from the development plans, for example according to a model of parameters for such plans. Figure 28 shows an exemplary screenshot of a GUI (graphical user interface) display regarding data entry of a new plan upon execution to the community development plans database (property information database).

Figure 29 shows an exemplary screenshot of a GUI (graphical user interface) display regarding data of building materials and structural parameters which may optionally be required as part of the community development plan.

Figure 30 shows an exemplary screenshot of a GUI (graphical user interface) display regarding building parameters which may optionally be required as part of the community development plan. Figure 31 shows an exemplary screenshot of a GUI (graphical user interface) display regarding statutory stages in the property development process with regard to required inspections and approvals.

Figure 32 depicts an optional embodiment of a system 3200 according to the present invention, wherein a data retrieval system 3240 preferably stores data and is able to query the data stored therein. Data retrieval system 3240 comprises at least one database 3241 that optionally comprises market data, optionally and preferably relating to an existing market and/or to a market of interest. The market intelligence data exemplarily may optionally be stored through a customer relationship management (CRM) system (not shown) or optionally individual components of such a system thereof, optionally and preferably including but not limited to statistical data 3243, taskforce data

3242, research results 3244, market analysis data 3245, client list 3246 and historical data

3247. Preferably the information contained in data retrieval system 3240 may be queried by using standard query language (SQL) requests or any language, protocol, interface or system able to gather, query and group data from at least one database associated with data retrieval system 3240. Optionally, the query may be abstracted from a map rather than a database such that a particular region is defined by according to a region defined by a user within a map. Once the query is run and its results are available, query result 3248 is optionally packaged in a format that allows mapping module 3220 to transcribe or convert the data onto a map

Preferably query result 3248 is transmitted to mapping module 3220 optionally and preferably in a secure manner by any means of communication including but not limited to a network connection, a landline wire connection or a wireless connection using communication protocols accepted and known in the art optionally including but not limited to http, https and XML. Query results 3248 are preferably and optionally packaged allowing mapping module 3220 to convert the results into a visual map of the query. Optionally and preferably mapping module 3220 utilizes mapping functions that are able to preferably automatically map a physical address to mapping coordinates, therefore obtaining mapping query results 3248. Optionally once the mapping is completed by the mapping module 3220, the resultant mapping coordinates 3221 are optionally and preferably communicated to a decision support module 3200 for further analysis. Decision support module 3200 optionally allows the user to graphically visualize query results 3248 preferably on a map enabling a user to analyze the results. Decision support module 3200 optionally comprises a planning module 3201; a clustering module 3202; a focus group module 3203; asset allocation module 3204; planar mapping module 3205; and routing module 3206. Optionally decision support module 3200 may evoke at least one of the modules comprised therein to automatically point to trends in the mapped results.

Without the intent of limiting the present invention and solely for the purpose of clarity to better understand the present embodiment of the system and method of the present invention, an example is set forth applying by way of example the present embodiment to an election campaign scenario. During a campaign a candidate would like to know how to reach the maximum number of new potential voters in a given jurisdiction. A query 3230 is abstracted by selecting the jurisdiction of interest, for example by having the user select the area of interest on the map. Query 3230 is then preferably further defined by identifying criteria such as voters that did not previously vote for the candidate's party in the given area. To solve query 3230, data retrieval system 3240 uses a plurality of stored data optionally including but not limited to historical data 3247 and statistics relating to the area from statistical database 3243. Once query 3230 is compiled and solved by retrieval system 3240, query results 3248 are then communicated to mapping module 3220 wherein the results are mapped. The mapping results 3221 are then communicated to decision support system 3200 where a clustering module 3202 defines the various pockets within the jurisdiction that have not previously voted for the candidate's party.

Optionally, routing module 3206 and planning module 3201 are able to compose a route that defines the best roads within the chosen jurisdiction to tour when trying to reach new voters. The route is optionally and preferably visualized on the map, along with the clusters of areas within the given jurisdiction. Furthermore, asset allocation module 3204 may suggest a local center that may be used in order to reach the voters when giving a campaign speech. The asset allocation module 3204 optionally defines the best local center to use based on given variables or criteria such the minimum distance connecting the various clusters defined by cluster module 3202.

Figure 33 shows an exemplary illustrative method according to the present invention for a planning application process where in stage 1 , information is gathered. In stage 2 the data is entered and stored into the appropriate databases comprising data retrieval system 3240. In stage 3 a query 3230 is defined, for example by the user. In stage 4, the query is abstracted for further analysis. In stage 5 optionally query result 3248 is communicated to mapping module 3220. The map results are then preferably mapped in stage 6 and communicated to decision support system 3200 for analysis in stage 7. In stage 8 the results are optionally and preferably brought to practice, for example to implement a particular campaign decision.

While the invention has been described with respect to a limited number of embodiments, it will be appreciated that many variations, modifications and other applications of the invention may be made.

Claims

What is claimed is:

1. A method for management of property-related processes comprising managing at least one process related to an activity for the property.

2. The method of claim 1, wherein said managing at least one process comprises obtaining an electronic signifier related to at least a portion of said at least one process.

3. The method of claim 2, wherein said electronic signifier is provided by a worker and said obtaining comprises review of one or more parameters about the property.

4. The method of claim 3, wherein said one or more parameters are selected from the group consisting of the exact location of the property, the boundaries of the property, the boundaries and location of one or more buildings on the property, one or more permissions associated with the property and information applying to more than one property.

5. The method of claim 4, wherein said information applying to more than one property includes zoning information.

6. The method of any of claims 1-5, wherein said activity is a planning application.

7. The method of claim 6, wherein said managing comprises: a. Automatically comparing at least one action in said planning application to at least one parameter of the property; and b. Rejecting said planning application if said at least one action is not permitted according to said at least one parameter.

8. The method of claim 7, wherein said managing further comprises: a. Recording a decision by a committee for at least one action of said planning application; and b. Approving or rejecting said planning application at least partially according to said recorded decision.

9. The method of any of claims 1-8, wherein said managing comprises: a. Dividing said at least one process into a plurality of stages; b. Determining at least one stage as a compulsory stage; and c. Halting said at least one process at said compulsory stage until said compulsory stage is fulfilled.

10. The method of claim 9, wherein said compulsory stage is fulfilled after provision of an electronic signifϊer.

11. The method of any of claims 1-10, further comprising: a. Visualizing the property according to at least one map.

12. The method of claim 11, wherein said at least one map is automatically generated from at least one plan related to the property.

13. The method of any of claims 1-12, further comprising determining at least one activity related to security of the property automatically according to a plan of the property.

14. The method of claim I₅ wherein said managing further comprises analyzing a geographical location of the property for geographical data; Analyzing marketing data regarding the property for marketing; and Combining said marketing data and said geographical data to determine a marketing plan.

15. A system for process management for a process related to a property, comprising a property activity module for managing information regarding at least one property activity, a property information module for storing information about the property and a property process module for managing the process.

16. The system of claim 15 wherein said property information module stores information related to at least one of an escape route and perimeter information.

17. The system of claim 15, further comprising: a. A property location module for accessing information regarding a location of the property; and b. a map reader for reading said location information and for constructing a map of the property.

18. The system of any of claims 15-17, further comprising: a. A planning committee module for analyzing a request to change at least one parameter of the property.

19. The system of claim 18, wherein said planning committee module accepts an electronic signifier for determining whether said request is accepted.

20. The system of claims 18 or 19, further comprising a betterment module for determining at least one change in tax according to said request.