WO2001046854A1 - A system and method for inter-enterprise workflow and document management - Google Patents

Abstract

The invention provides a secure system of workflow and document management utilizing a central data repository for storing and accessing the work objects and documents (1200). The work objects have defined data groups and business processes and can have supporting documents attached or linked. The supporting documents are stored independently from the work objects within the central data repository. The use of the central repository and work objects with defined business processes allows multiple users or organizations (1201, 1202, 1209, 1203) to access the central data repository and interact with all or parts of the work objects or documents. The invention has particular use in an online automated permit application system where contractors can create and submit permits and jurisdictions can subsequently review, approve or reject, collect fees, and maintain records of the permit applications.

Description

A System and Method for Inter-Enterprise Workflow and Document Management

This application claims the benefit of U.S. Provisional Application 60/171,579 filed December 23, 1999, which is incorporated herein by reference.

Field of the Invention

The invention relates to the processing of documents on computer networks, and more particularly to a system and method for enabling workflow and document processing to be coordinated across organizational boundaries.

Background of the Invention

The invention pertains to information technology relating to the field of Workflow and Document Management. Existing workflow and document management technologies are designed to support back-office operations of single enterprises. There are many system limitations deriving from the known workflow and document management architectures including limited support for user administration within an enterprise. When simultaneously using multiple enteφrises, there is a limited amount of security provided to the user. Little use has been made of the Internet in the known workflow and document processing technologies over a wide area network.

It has been found to be difficult to share work and documents across enteφrise boundaries. These boundaries may be between departments within a single enteφrise or between enteφrises of widely different organizations separated by large physical distances. When moving data across enteφrise boundaries, there has been a lack of support in providing common electronic formats between the boundaries. It is difficult to check the status of the work and documents outside of the enteφrise when crossing enteφrise boundaries.

What is needed is a system and method to overcome the limitations of the known art and to combine additional workflow and document management capabilities in a novel way to encompass Internet and web technologies for a wide area system of workflow and document management.

Summary of the Invention

It is an object of the present invention to support a community model of enteφrises collaborating to conduct a business process. It is a further object of the invention to allow enteφrises to tightly control the use and modification of their provided data. It is still a further object of the present invention to minimize the need for data conversion in electric form as it flows across enteφrise boundaries. It is yet still another object of the present invention to provide a status of the work on a current and readily available basis across an inter-enteφrise network.

The present invention provides for user registration and authentication to provide a secure system of workflow and document management. A centralized data repository of work objects and supporting documentation is maintained in a data warehouse. A workflow definition engine controls the manner of processing of the data for the user across the enteφrise. The present invention provides a standard and readily customized predefined workflow pattern to the end user which interfaces with the enteφrise data currently in existence. The architecture is scalable and capable of supporting multiple enteφrises in a single implementation. Brief Description of the Drawings

Figure 1 : Illustrates a central data repository object structure;

Figure 2: Illustrates a business process rules relationship to the central data objects;

Figure 3: Illustrates a workflow object template;

Figure 4: Illustrates an instantiation of template-based work objects;

Figure 5: Illustrates state transitions of work objects across organizational boundaries;

Figure 6: Illustrates the storage of supporting documentation objects;

Figure 7: Illustrates the relationships between work objects and supporting documentation;

Figure 8: Illustrates document object sharing across organizational boundaries;

Figure 9: Illustrates document life-cycle management;

Figure 10: Illustrates the organization domain sharing of the present invention;

Figure 1 1 : Illustrates the wide-area access to central data repository; and

Figure 12: Illustrates shared object namespace to facilitate inter-organization communication.

Figure 13: Illustrates one embodiment of the system architecture of the present invention.

Figure 14: Illustrates a screen capture of the home page in a preferred embodiment of the present invention.

Figure 15: Illustrates a screen capture of the system administrator page in a preferred embodiment of the present invention. Figure 16: Illustrates a screen capture of a contractor's main page in a preferred embodiment of the present invention.

Figure 17A: Illustrates a screen capture of a contractor's information page in a preferred embodiment of the present invention.

Figure 17B: Illustrates a screen capture depicting the user's ability to attach supporting documentation in a preferred embodiment of the present invention.

Figure 18: Illustrates a screen capture of general information page for a contractor in a preferred embodiment of the present invention.

Figure 19: Illustrates general information page concerning a permit application in a preferred embodiment of the present invention.

Figure 20: Illustrates a screen capture of a contractor's preview page in a preferred embodiment of the present invention.

Figure 21 : Illustrates a screen capture of a contractor's ability to proceed to the shopping cart function in a preferred embodiment of the present invention.

Figure 22: Illustrates a screen capture of a contractor's invoice slip page in a preferred embodiment of the present invention.

Figure 23: Illustrates a screen capture of a contractor's credit card checkout information page in a preferred embodiment of the present invention.

Figure 24: Illustrates a screen capture of a contractor's electronic receipt page in a preferred embodiment of the present invention.

Figure 25: Illustrates a screen capture of a jurisdictions main page in a preferred embodiment of the present invention. Figure 26: Illustrates a screen capture of submitted applications page for a given jurisdiction in a preferred embodiment of the present invention.

Figure 27: Illustrates a screen capture for the history of a given submitted permit for a certain jurisdiction in a preferred embodiment of the present invention.

Figure 28: Illustrates a screen capture of a jurisdiction's status page in a preferred embodiment of the present invention.

Figure 29: Illustrates a screen capture of an application activity page for a given jurisdiction in a preferred embodiment of the present invention.

Figure 30: Illustrates a screen capture of a completed application page in a preferred embodiment of the present invention.

Figure 31 : Illustrates a screen capture, similar to Figure 26, showing the status of submitted applications in a preferred embodiment of the present invention.

Figure 32: Illustrates a screen capture showing the status of submitted applications, similar to Figure 31 , in a preferred embodiment of the present invention.

Detailed Description of the Preferred Embodiments

The system and methods of the present invention builds a central data repository of workflow objects and supporting documentation for these workflow objects as will be described in conjunction with Figures 1-12. The central repository is made accessible to users within multiple organizations on a wide-area network basis. The central data repository will allow the users to access and work with the data files from the central data repository database which will ultimately allow users from within the multiple organizations to share the data files. As seen in Figure 1 , the system of the present invention allows users to create a series of workflow templates 100, ... 110 which can have defined data groups or data fields, supporting documentation and its own set of defined business processes. Once the workflow templates 100, ... 110 are created the system will store each workflow instance 101, 102, ... 109, and 11 1, 112, ... 119 separately. The system is designed to allow as many workflow templates and workflow instances as needed. The workflow instances 101, 102, ...109, and 1 11, 112, ... H 9 are referred to as workflow objects.

Each workflow object can have its own supporting documentation which the user can specify using the required number of document templates 120, ... 130. The system will allow as many supporting documentation files as needed, which in Figure 1 are referred to as a Document Instance 121, 122, ... 129 and 131, 132, ... 139, for each document template 120, ... 130 created. In addition, as seen in Figure 2, each workflow object can have associated business processes (BP) which are defined and created using the business process templates 200, ... 210. Each business process template 200, ... 210 can have a countless numbers of defined business process rules 201, 202, ... 209 and 211, 212, ... 219.

Therefore, as illustrated in Figure 3, the system allows a workflow object 300 to be created with an endless number of data fields 310, and endless number of supporting documentation 320, and an endless number of business processes 330 associated with that particular workflow object 300. The data fields 310 are defined as part of the workflow templates 100, ... 110, as seen in Figures 1 and 2. The supporting documentation 320 are defined as part of the documentation template 120, ... 130, as seen in Figures 1 and 2. The business processes 330 are defined as part of the business process templates 200, ... 210, as seen in Figure 2. The system allows users to create an endless number of workflow objects using the workflow templates 100, ... 110, as seen in Figures 1 and 2. Figure 4 represent a workflow object 400 with defined data groups or information fields 410, 412, 414, and 416. In addition, the workflow object 400 contains supporting documentation 420 and defined business processes 430. An example of the workflow object 400 would be a permit application template with the data groups defined with the applicant's information 410, the building or structure information 412, the features to be installed information 414, and the fee and payment information 416. The supporting documentation 420 could be data files containing plats, design drawings, site plans, building or structure designs and other documents or data files which may be needed. The business process rules 430 could include processes to create the permit, complete the permit application, submit the permit application, processes for approving the permit application, reviewing the permit application, routing of the permit application and rejection of the permit application.

Proceeding according to the business processes 430 the workflow object 400, which in this instance is a permit application template, is created forming the permit application 401. The various data groups 410, 412, 414, 416, and the supporting documentation 420 are supplied by information previously entered into the system or supplied by a user. The supplied information populates the data groups 411, 413, 415, 417, and supporting documentation 421 and is stored in the central data repository. The supporting documentation 421 are stored as separate data from the workflow object or permit application 401 within the central data repository thereby allowing other users or organizations access to the various files.

Described another way, the workflow objects are defined as object templates as shown in Figure 3. Various data documents and business processes are defined. Certain business process rules result in the instantiation of new object instances based on the predefined template as shown in Figure 4. For instance, a workflow template 400 may be a permit application. The business process 430 <CREATE PERMIT APPLICATION results in the creation of a new permit application object based on the permit application template. Data from the various data groups 410, 412, 414, 416 include applicant, structure, features, and fee payment fields. Additional supporting documentation 420 may be provided. An illustrative business process 430 is CREATE, COMPLETE, APPROVE, REVIEW, ROUTE and REJECT for the application. The complete process is done on-line resulting in acceptance or rejection of the permit request.

Subsequent business process rules affect the state of the workflow object and govern which users in which organizations may access and update the workflow object. As seen in Figure 5 where, for example, once the permit application 505, workflow object 1, is completed and submitted by a member of the originating organization 501 (Organization A) the submitted permit application 525 can no longer be updated by the originating organization 501 because the originating organization 501 no longer has update access rights to the submitted permit application 525. Instead, the submitted permit application 525 is queued, as seen in the defined business processes 430 seen in Figure 4, for REVIEW, APPROVAL, COMMENT, ROUTE, and REJECTION by the receiving organization 550 (Organization B). Rejection results in the rejected permit application 530 becoming accessible to the originating organization 501 again, while ROUTE results in a routed permit application 535 in which the receiving organization 550 retains access rights. In this manner, workflow processes on the single workflow object are governed on an inter-organizational basis while the object remains in a single location within the central repository. Security is maintained for both the applicant and the agency processing the application.

As seen in Figure 6, supporting documentation 610, 611, ... 619 are stored within the repository as objects separate from the workflow objects 600, 601, ... 609. In this manner, the invention can flexibly support one-to-one, one-to-many, and many-to-one relationships between workflow objects and s φporting documentation as further shown in Figure 7. Workflow object 700, as seen in Figure 7, can access many documents 710 and 719 as illustrative of a one-to-many relationship, workflow object 701 can access document 711 as illustrative of a one-to-one relationship, and workflow objects 701 and 709 can access document 711 as illustrative of a many-to-one relationship.

These relationships can even be maintained across organizational boundaries so that workflow objects private to a given organization can share public domain or shared access supporting documentation as shown in Figure 8. Shown in Figure 8 is an organization 870, referred to as Organization 1, and an organization 880 referred to as Organization 2 sharing documentation with the public domain 860.

As seen in Figure 8, Organization 1 has their own set of workflow objects 800, 801, ... 809 which are separate from the workflow objects 850, 851, ... 852 of Organization 2. Organization 1 has documents 810, 811, ... 819 located in a private Organization 1 domain 862 which allows only Organization 1 access to the documents. Organization 2 has documents 830, 831, ... 839 located in a private Organization 2 domain 864 which allows only Organization 2 access to the documents. However, both Organization 1 and Organization 2 can have various documents 820, 821 , ... 829 available in the public domain 860 which allows multiple organizations access.

The centralized nature of the data repository allows convenient storage of full document revisions. Using this capability, the complete life cycle of a document can be stored along with all comments and annotations leading to subsequent revisions. The document life cycle management is shown in Figure 9 and contains a complete history of the permit application. In the example provided in Figure 9, the original version of the document 900 can have multiple annotations, revisions, and comments made throughout the document life cycle, see steps 901 and 903. The annotations, revisions, and comments 901, 903 can be stored as well as the revised documents 902, 904. In this manner, a work process involving review of a workflow object can result in not only referencing current supporting documentation, but also full review of all historical versions of those supporting documents.

In this shared environment, it is necessary to provide security measures which allow participating organizations to define which workflow and supporting documentation objects are within their private domains 862, 864, as seen in Figure 8, and which are in shared or public domains 860. Domain sharing can occur on either a one-to-one private basis or on a completely open public basis. This organizational domain sharing is illustrated in Figure 10 where organization 1001, referred to as Organization 1 and organization 1002, referred to as Organization 2, have shared documents and shared access to some of the documents of each other. Organization 1 has established a private domain 1010 and a shared domain 1020 for sharing with only Organization 2. A shared domain 1030 has been established allowing all organizations access to the documents in the shared domain 1030. In addition, users within a given organization's domain also possess security privileges within that domain based on the user's class privilege level. Therefore, documents within the private domain 1010 can have access restrictions associated with them depending upon the access rights of the users within an organization.

The present invention is designed to support access through industry standard wide area networks such as the Internet. This wide area network support allows a centralized data repository 1100 and associate workflows to be shared among multiple organizations 1101, 1102, 1103, ... 1109 regardless of geographic location. This capability also allows organizations 1101, 1102, 1103, ... 1109 to participate in the shared workflow community without installing specialized software or hardware within the organizational premises. This worldwide access to the central repository 1100 is shown in Figure 11 wherein Organizations 1, 2, 3, to n, are shown interconnected with the central data repository 1100.

The implementation architecture of the present invention is designed to allow all participating organizations 1201, 1202, 1203, ... 1209 to utilize a shared implementation of the central data repository 1200 as shown in Figure 12. Because all repository workflow and documentation objects exist within a single namespace, communication of work and documents within and among organizations occurs by altering object references rather than by physically moving objects in storage or translating and transmitting objects through communications networks. Because of this central data repository, workflow and documents may be processed in a secure, reliable and expedient manner.

A preferred embodiment of the present invention will be described in conjunction with figures 13-32 which utilizes the Inter-Enteφrise workflow and document management system and methods for preparing, submitting, review, rejection and approval of construction permit applications. Users or organizations of the system will include contractors who must submit permits and jurisdiction who must approve the permits prior to the contractors starting the work for which a permit was submitted.

The general system architecture of the preferred embodiment of the present invention is shown in Figure 13. The general system architecture allows users, which includes both contractors and jurisdictions, to access the database through the internet. The users, such as contractors or jurisdictions, would use desktop PCs 1310, 1330, laptop computers 1320, or personal digital assistants (PDA) 1340. The users, contractors and jurisdictions, could use any device capable of accessing the internet including wireless phones with internet communications capability. The users through their various electronic devices 1310, 1320, 1330, 1340 would access the internet 1305 and be connected with the servers and databases of the system 1300. The servers may consist of a web-server 1350, a database server 1360, and a multimedia server 1370. The web-server can access a web database 1380 with web specific content. The database server 1360 can access a main database 1390 which acts as the central data repository, containing all the documents and files. In addition, the multimedia server 1370 could access a multimedia database 1395 which would contain multimedia content and files, such as instructional video or audio clips on how to use the system.

Upon accessing the preferred embodiment of the present invention users are presented with user friendly interactive screens. The interactive screens, Figures 14 through 32, provide multiple organizations with an easy and efficient manner to create, access, and control documents, such as permits, providing a document and workflow system.

Figure 14 illustrates the home page 1400 for the user. The user must enter their user name in field 1410 and password in field 1412 and press the enter tab 1414 to enter the system. The home page 1400 may also contain additional information available to the user, such as coφorate profile 1420, the locations and permits which are available 1422, any press room news 1424, upcoming event 1426, and partners 1428.

Figure 15 represents the main page a system administrator would see when entering the system. The system administrator would be a certain user within a given organization or within the company creating and maintaining the system itself. The system administrators main page 1500 includes a Welcome Message 1501, as well as information related to the system benefits 1503 and partners 1504. The administrator is provided a menu 1505 of functions, which they can utilize. This menu 1505 indicates various features and functions the system administrator is provide i. These features and functions include: under the administrators 1510 they can acces ; a list 1511 of all administrators; under the applicants 1520 they can create 1521 a new applicant with their corresponding profile or list all applicants 1522; the administrator can review the issuers 1530 and create 1531 new issuers or list 1532 all issuers; and the administrator can also access the permit forms 1540 and create 1541 new forms or list current forms 1542 on the system. In addition, the administrator can access the fee maintenance 1550 features to review or alter the fees, they can access the distribution list 1560, the welcome message 1570, the shopping cart report 1580, and the payment reconcile feature 1590. The shopping cart report 1580 allows the administrator to see current activity 1571, as well as payment type 1572.

By utilizing the system administrator main page 1500 the system administrator is able to create and manage new organizations in the system which may include contractors and jurisdictions. The system administrator can also create forms, establish filing fees for the permits or forms, and input the pertinent information for the given organizations.

Figure 16 illustrates a screen capture 1600 of an organization's, in this instance a contractor's, main page for interacting with the preferred embodiment of the present invention. The contactor's main page 1600 includes a welcome message 1601 as well as a menu 1605 of features and functions which allow the contractor to interact with the system. The menu 1605 can be established in a user specific manner such that the system knows that the contractor is involved in certain kinds of functions such as electrical 1610, mechanical 1620, and plumbing and gas 1630. Therefore, the contractor can quickly view certain permits they would need to fill out and submit. Viewing the menu 1605 the contractor could choose an electrical 1610 permit and therefore, create 1611 or view 1613 electrical permits. The system also allows the contractor to have multiple jurisdictions in which they can create and view permits. In this example, the contractor has licenses to perform work in Fairfax County, Virginia and therefore the system indicates the ability to create and access permits for that locale. However, the contractor could also have additional jurisdictions such as Montgomery County, Maryland or the District of Columbia. Therefore, as seen under the electrical permits section 1610 they could create a new permit for Fairfax County by selecting the Fairfax County link or view Fairfax County permits by selecting the Fairfax County link 1614 under the view heading 1613.

The contractor could also choose to create or view a mechanical permit 1620 by creating permits under the create link 1620 for a given jurisdiction, such as Fairfax County 1621, or viewing existing permits 1622 in specific jurisdictions, such as Fairfax County 1623. The contractor could also create and view plumbing and gas permits 1630. The contractor could create 1631 plumbing and gas permits in specific jurisdictions, such as Fairfax County 1632 or view plumbing and gas permits 1633 in specific jurisdictions 1634. The contractor could also decide to view all permits 1640, view the shopping cart 1640, which is an indication of all permits for which they have filled out with the intent of submitting. The user, contractor, can also review the shopping cart report 1660 which would include the activity 1661 and payment type 1662 information.

By utilizing the present invention the user, contractor in this sense, can create and view permits for given types of work they have licenses to perform in given jurisdictions. Each jurisdiction they are licensed in can be added to the system thereby allowing the contractor or user to create and submit permits online, which are then accessible by the various jurisdictions which they are licensed in. Permits can be reviewed, rejected and accepted via the online internet system of the present invention, thereby expediting the approval process of permits and eliminating the cumbersome and time intensive process currently involved in submitting and approval of permits.

As indicated in Figure 16 a user, or contractor, has access to various features and functions of the present invention. Figures 17 through 24 are screen captures illustrating the user or contractor interface pages of the preferred embodiment of the system of the present invention. Figures 17-24 illustrate the various features, information and options provided.

Figure 17A illustrates a screen capture 1700 of a contractor's license information. The screen capture 1700 also includes the same menu 1705 previously described. The screen capture 1700 shows an assortment of user or contractor specific information which has previously been entered into the system and is pre-populated into subsequent permits or forms created by the user. Figure 17B is a screen capture 1750 illustrating the ability of the user, contractor, to attach supporting documentation. The attached drawing or document file location would be entered in filed 1755.

Figure 18 represents a screen capture 1800 of general information related to a permit application the user or contractor must input. Once again, the menu 1805 is provided. The permit application can be identified by either inputting a known building permit number in field 1880 or by filling out the owner information for new permits 1890. Icons 1895, such as highlighted bullets, are included to indicate fields which are required by the jurisdiction to grant approval of a permit. Therefore, the system indicates required fields to assist the user in filling out permits using the system.

Figure 19 illustrates a screen capture 1900 which includes a listing of equipment to be installed for a given permit, in this instance an electrical permit. By filling in the appropriate fields 1910 the contractor is able to specify which items and actions are to be included on a given permit. By utilizing the easy user interface pages the user or contractor can quickly generate a permit for a particular project. Once again, the screen capture 1900 includes the menu 1905 for ease of movement throughout the system.

Figure 20 illustrates a screen capture 2000 which depicts a preview of all information to be generated on the official permit. Once again, the screen capture 2000 includes menu 2005. By utilizing the preview screen 2000 the user can review the information for correctness prior to submitting the completed permit. Figure 21 illustrates a screen capture 2100 indicating the assessed fees for a particular permit and by utilizing tab 2125 the user can go to the shopping cart to pay for all the permits they have processed and subsequently submit the permits to the appropriate jurisdiction for review and approval. Once again, screen capture 2100 includes the menu 2105 for ease of movement throughout the various features and functions of the system.

Figure 22 illustrates a screen capture 2200 which depicts the users invoice slip indicating all permits and costs associated. The screen capture 2200 shows the menu 2205 as well as indicating the cost for each permit, indicated in column 2210, and the associated fee charged by the system, indicated in column 2220. The system can generate revenue by charging a processing fee per permit as indicated in line 2230 and by charging a system fee for the process of creating and directing the permits to the appropriate jurisdiction for approval which is indicated in column 2220.

Figure 23 represents a screen capture 2300 whereby user or contractor can pay the invoice by use of a credit card. The credit card information is entered into a credit payment form 2350. Figure 24 represent a screen capture 2400 of an electronic receipt received after payment.

Figures 25 through 32 represent screen captures in which the user is a jurisdictional organization which has access to the system to review filed permits. The jurisdiction has the ability to receive and review the various work order permits allowed in their jurisdiction through the system and can accept or reject and add comments throughout the process.

Figure 25 represents a scree capture 2500 of the main page provided a jurisdictional user. The screen capture 2500 includes a menu 2505, a welcome banner 2501, a benefits listing 2502, and a partner listing 2503. As can be seen on the menu 2505, the jurisdictional user is provided a list of features including a list of applications 2510 and payment a reconciliation feature 2520. Under the list of applications 2510 the jurisdictional user can selected to view a listing of all submitted permits under the given types including building 2511, electrical 2512, household appliance 2513, mechanical 2514, and plumbing and gas 2515.

Figure 26 illustrates a screen capture 2600 of the list of applications under the electrical listing tab 2512 indicated on Figure 25. As seen in screen capture 2600 the jurisdictional user is once again provided a menu 2605 and a list of pending submitted permits 2610. The jurisdictional user can select the range of dates to search for submitted permits by using fields 2635 and 2637 to select dates and then selecting the search tab 2639. Under the listing of submitted permits 2610 the jurisdictional user is also shown the transaction number in column 2620 and the status of the permits in column 2630.

Figure 27 illustrates a screen capture 2700 which indicates the status history of a selected permit. Therefore, a jurisdictional user may select a given submitted permit as indicated in Figure 26 and they will be shown specific details regarding the submitted permit, as seen in screen capture 2700. The jurisdictional user will have the ability to change the status of the permit using change status bar 2710 or cancel the review by using the cancel bar 2720. Once again, screen capture 2700 includes menu 2705 which allows the user to quickly move throughout the system.

Figure 28 illustrates a screen capture 2800 of the change status page a jurisdictional user is presented when they have reviewed a submitted permit. As can be seen in Figure 27, when a user selects the change status bar 2710 they will be provided screen 2800 which allows them to select a new status for the permit using menu 2810. The jurisdictional user can update the permit fee indicated in section 2820 and can add comments in section 2830. The jurisdictional user may also update the status of the permit application using tab 2845 and include a permit number in section 2840.

Figure 29 represents a screen capture 2900 which the jurisdictional user sees if they select the transaction number of a given submitted permit application in column 2620, as indicated in Figure 26. The jurisdictional user is provided detailed information about the submitted permit in section 2920 and are given the option to edit the application using edit tab 2930 and print the application using print tab 2940. By using the present invention, the jurisdictional user has the ability to quickly review pertinent information about the submitted permits as well as edit the application or print the application.

Figure 30 represents a screen capture 3000 of a completed application in proper form. The present system is able to take the inputted text fields from the user input sections and input them into the proper form for a given jurisdiction. Therefore, the jurisdictional user when reviewing a completed application as seen in screen capture 3000 will see the appropriate information populated into the appropriate sections of the actual form required in that jurisdiction. The jurisdictional user will be able to review the form online as well as print it out for proper circulation throughout their organization.

Figure 31 represents a screen capture 3100 indicating the list of submitted permits, similar to Figure 26, in which the jurisdictional user is provided with the updated status of the submitted permit applications. As can be seen in reviewing screen capture 3100, the submitted permit application on the top line of the listing of applications 3110 indicates the

U status has changed to "in review" as seen in column 3130. Figure 32 illustrates a screen capture 3200 showing the same listing of submitted permits 3210 in which the status of the submitted permit application on the top line has changed to "active" as seen in column 3230.

Utilizing the various jurisdictional user screens discussed and illustrated in conjunction with Figures 25 through 32 the jurisdictional user can see listings of submitted applications, pull up pertinent information of these application, review and change the status of the submitted applications, activate the submitted applications, or reject the submitted applications. Therefore, the jurisdictional organization and its members can easily go online accessing the preferred embodiment of the present invention and quickly and easily interact with the submitted permits. The users can also print the permits in their proper form for circulation throughout the organization. The organization's ability to interact with the submitted online permits allows them to efficiently streamline their review process, ease the billing and receipt of funds as well as reduce the manpower required to effectively review, store and receive permits.

What has been disclosed is a unique approach to the problem of permit and license automation wherein an Internet portal community is used, which provides complete automation of many types of permit and license applications. The web-based workflow system and method processes the permits in an automated internal data repository. The architecture is bi-directional and self-ramping which allows local jurisdictions to add content to the site quickly and easily. Private links can be provided to public and agency databases in a centralized site which may be accessed and reviewed by the public as a record of approved permits and licenses. The system and method provides electronic payment of fees directly to the issuing agencies account. There is substantial cost reduction and significant decrease in processing errors within the system which provides real time approval of permits and licenses with a confirmation.

The contractors, as one organization, either by themselves or with the help of a system administrator are able to create a series of template workflow objects such as electrical, mechanical, and plumbing and gas permit applications. Each permit application for a given project, such as an electrical permit application for a specific house, becomes an instance of that workflow object. The workflow object has a set of data groups included such as the applicant's information, the structure information, work information, and fee information. In addition, as previously mentioned, the workflow object may have associated supporting documentation such as building plans. Each workflow object also has a set of business processes such as create, complete, submit, approve, review, route, and reject. The workflow object is saved in the central data repository as previously described with the supporting documentation saved as a separate data file.

The jurisdictional user, as the second organization, can now enter the same system and access the central data repository and review and access the submitted permits. The workflow object business process determine the routing, flow and protocol for the permit application as well as determining which data groups and supporting documentation are stored in private and public domains. Therefore, the jurisdiction user can review and access the appropriate documents and files.

Although the present invention was described by use of an illustrative example of creating and submitting permit applications online the system could be employed for many systems where organizations would benefit from shared data files and document accessibility. This could include federal, state, and local government forms and regulations as well as medical forms and documentation. The following examples are for illustrative puφoses only and are not intended as limiting the uses of the system and methods of the Inter-Enteφrise Workflow and Document Management schema of the present invention.

While the invention has been particularly shown and described with reference to a preferred embodiment thereof, it will be understood by those skilled in the art that various changes in form and details may be made therein without departing from the spirit and scope of the invention.

Claims

WHAT IS CLAIMED IS:

1. A system for sharing at least one work object across organization boundaries comprising: a central data repository for storing at least one work object, wherein said at least one work object comprises at least one data group and at least one business process; at least one server for providing a user interface and access to said central data repository; a first user electronic device for communicating with said at least one server through said user interface for creating and storing said at least one work object; and a second user electronic device for communicating with said at least one server through said user interface for accessing and implementing on said at least one work object one of said at least one business process.

2. The system of claim 1, wherein said user interface is provided through an Internet connection.

3. The system of claim 2, wherein said user interface is provided through the world wide web.

4. The system of claim 1, wherein said at least one work object also comprises at least one document.

5. The system of claim 1, wherein said system further comprises a work object definition engine for controlling the manner of processing of said at least one work object.

6. The system of claim 1, wherein either of said first user electronic device or said second user electronic device are desktop computers.

7. The system of claim 1 , wherein either of said first user electronic device or said second user electronic device are laptop computers.

8. The system of claim 1 , wherein either of said first user electronic device or said second user electronic device are personal digital assistants.

9. The system of claim 1 , wherein either of said first user electronic device or said second user electronic device are web enabled wireless phones.

10. A method of sharing at least one work object across organization boundaries comprising the steps of: providing a user interface through a server; establishing an electronic communication between a first user and said server, wherein said server provides access to a central data repository; creating a work object, by said first user, with at least one data group and at least one business process; storing said work object in said central data repository; establishing an electronic communication between a second user and said server, accessing said work object, by said second user, within said central data repository for implementing on said at least one work object one of said at least one business process.

11. The method of claim 10, further comprising the step of: controlling the access of said first user and said second user to said central data repository.

12. The method of claim 10, further comprising the step of: linking at least one document file to said work object.

13. The method of claim 12, further comprising the step of: storing said at least one document file separate from said work object within said central data repository.

14. A method of providing an online automated permit application process comprising the steps of: providing a user interface through a server; establishing an electronic communication between an applicant applying for a permit and said server, wherein said server provides access to a central data repository; creating a work object with at least one data group and at least one business process, wherein said work object is a permit application template, said at least one data group includes information from said applicant, and said at least one business process for facilitating said permit application process; storing said work object in said central data repository; establishing an electronic communication between a jurisdictional user and said server, accessing said central data repository, by said jurisdictional user, to interact with said permit.

15. The method of claim 14, further comprising the step of establishing an Internet portal for accessing said user interlace.

16. The method of claim 1.5, farther comprising the step of establishing Internet portal for accessing said user interface through the world wide web.

17. The method of claim 14, further comprising the steps of: reviewing said permit by said jurisdictional user; and approving or rejecting said permit by said jurisdictional user.

18. The method of claim 14, further comprising the steps of: calculating filing fees of said permits; and processing a payment of said filing fees.

19. The method of claim 14, further comprising the steps of: attaching at least one document to said work object stored in said central data repository.

20. The method of claim 19, further comprising the step of: storing said at least one document separate from said work object within said central data repository.

21. The method of claim 14, wherein said at least one business process includes business processes to create, complete, submit, review, approve, route and reject said permit.