System and process for electronic subrogation, inter-organization workflow management, inter-organization transaction processing and optimized web-based user interaction

[0001] This application is a continuation application of utility application Ser. No. 10/704,460 filed Nov. 7, 2003, now abandoned. This application is related to Provisional Application No. 60/425,058 filed on Nov. 8, 2002, entitled “Electronic Subrogation System and Process”, and Provisional Application No. 60/425,670 filed on Nov. 12, 2002, entitled “Electronic Subrogation system and Process”.

[0002] The invention relates generally to an intelligent electronic subrogation network (“ESN”) that automates intra-organization workflow, inter-organization workflow and collaboration for insurance subrogation. The invention also relates to a novel system architecture and process that includes an inter-organizational workflow management system, an inter-organizational transaction processing system, and a unique mechanism for optimizing and enriching web-based user interaction within any such system. The invention will primarily be discussed, at least initially, with reference to the operation of an electronic subrogation network.

[0003] During the 80's and 90's, many business transaction processing systems were focused on integrating business processes and data that existed within an organization (i.e., intra-organization). These systems cover a wide array of business applications, of varying complexity, including production forecasting/scheduling, order processing, human resources management, financial accounting, sales management, etc. Commercial examples of such systems include offerings from SAP, Oracle, and PeopleSoft. Organizations that successfully implemented such systems achieved reduced costs, higher efficiency, and were more competitive. With the intra-organization systems in place, these organizations are now looking to integrate the business processes and data that exist between trading partner organizations (i.e., inter-organization).

[0004] Today, most inter-organizational business transactions occur using paper as the primary medium of exchange. This process is characterized by a high degree of manual processing and lengthy transaction cycle times resulting in high costs, errors, and much inefficiency. In contrast, automating inter-organizational processing systems have demonstrated substantial benefits including greater efficiency, reduced costs, reduced transaction cycle times, and vastly improved management information.

[0005] For example, within many industries, numerous opportunities exist for automating the processing of inter-organizational business transactions, e.g., Insurance, Manufacturing, HealthCare, Banking, etc. Within the insurance industry, one such opportunity exists related to subrogation. Insurance subrogation is defined as the process by which one insurance company (demanding party) seeks reimbursement from another company (responding party) or person for a claim it has already paid. For more information related to subrogation, refer to the detailed description below.

[0006] Within most insurance companies, the subrogation function is not highly automated. Many of the larger carriers have implemented a rudimentary scoring system for identifying subrogation, but very few have implemented automation for enterprise-wide and inter-enterprise subrogation workflow. Paper and manual processes still dominate the subrogation business practices in use today.

[0007] Hence, there is needed in the marketplace an automated system with the following capabilities unique to inter-organizational business transaction processing: 1) a centralized network hub (web-based) that facilitates the inter-connection of various organizations and eliminates the proliferation of point-to-point interfaces, 2) an inter-organizational workflow management system that provides a common framework for managing the state and status of all transactions within the system, 3) an inter-organizational transaction processing component that supports multiple organizations and their distinct relationship with each transaction while also ensuring the security and privacy of each organization's data, 4) a unified data model mechanism that allows common data elements to be exchanged while also supporting organization specific interface requirements, and 5) application specific data and functionality specific to the types of business transactions being processed.

[0008] Furthermore, within the insurance industry, an inter-organizational system for subrogation claims is needed. Such a system would provide the application specific data and functions unique to insurance subrogation workflow.

[0009] The electronic subrogation network (ESN) is a virtual clearinghouse for subrogation claims designed to eliminate inefficiencies and manual tasks in subrogation processing. Using the ESN, demanding parties can issue subrogation demands electronically to responding parties. The ESN's electronic folder supports both structured and unstructured data so that the involved parties can share claim information as well as any supporting documents. While the primary parties to the subrogation claim often involve the demanding and responding insurance carriers, additional parties can also take part in this business transaction (e.g., arbitration organizations, collection organizations, attorneys, etc.) The ESN is unique in its ability to provide a common workflow and collaboration process for subrogation that spans multiple distinct organizations—i.e., inter-organizational workflow and transaction processing.

[0010] The ESN provides functions to manage inter-company workflow and collaboration. The ESN manages workflow between the involved parties through a state-based workflow model that ensures workflow consistency among multiple parties. Responding parties can create rules in the ESN to automatically route the incoming subrogation demand to the appropriate file handlers. All involved parties can create business rules in the ESN based on each company's business practices, which are used to audit every file and identify exception conditions. Multiple parties can collaborate and negotiate online through the ESN. The ESN provides functions for automatic settlement of subrogation claims—without any human intervention—when claim files pass all parties' business rule audits and liability calls match. The ESN audits files against comparative negligence regulations of each state and, when appropriate, automatically generate counter claims that are linked to the original file. Any party using the ESN can assign any file to a third party, e.g., arbitration firm, collection firm, outside attorney, service provider, etc.

[0011] The ESN provides payment-netting functions. Payments can be netted bi-laterally or multi-laterally whereby the ESN will keep track of payments due between two or more parties over a definable period of time then issue an alert to the party(s) that needs to make a payment. In addition, the ESN will provide all parties with reconciliation and file allocation information.

[0012] All members of the ESN will have online access to comprehensive management reporting including both demand-side and response-side reports. In addition, the ESN provides a benchmarking function so that members can compare various aspects of their demand-side and response-side performance against the industry.

[0013] The ESN provides sophisticated inter-organizational workflow, collaboration and transaction processing capabilities. In doing so, the ESN is based on a core software platform that consists of several generic technologies including the Inter-Organization Workflow Subsystem, the Inter-Organization Transaction Processing System, and the JView™ Subsystem.

[0014] The Inter-Organization Workflow Subsystem is designed to meet the requirements of both intra- and inter-organizational workflow. It uses a series of workflow tables (data structures) and a unique workflow algorithm to perform all workflow management operations. The workflow tables are essentially a set of finite state machines (FSM's), that define a closed loop system for the workflow related to a given business process. The Workflow Subsystem manages the status of inter-organizational workflow, the status of intra-organization workflow, ownership of the next action on a file, navigation of functions that can be performed, and the state of the file.

[0015] The Inter-Organization Transaction Processing System provides the framework for a central processing network that handles inter-organizational business transactions. This framework insulates member organizations from each other, supports the exchange of structured and unstructured information, supports multi-party transactions and workflow, and provides extensive data security and privacy for each organization. This system consists of four major areas—Interface Subsystems, Transaction Processing Layer (TPL), System Services, and Application Logic. The Interface Subsystem supports the unique interface requirements of any given source of transaction origination. In doing so, the Interface subsystem supports transaction origination from either automated systems (using electronic messaging interfaces) or interactive users (using web-based interfaces). The Transaction Processing Layer is responsible for coordinating the processing of all transaction requests within the system. The System Services provide common components and services for locking and reservation, object graph services, business rule and alert management, workflow management, security management, individual and team ownership, external notifications, snapshot services, reporting, and document management. The Application Logic layer provides the system with the application specific functionality required for a given vertical business process. This layer consists of the Unified Data Model—a mechanism for organizing and modeling subrogation-specific business information, model-related application logic, transaction-related application logic, and configuration.

[0016] The JView™ subsystem provides a system and process for optimizing and enriching the inter-organizational interaction. It significantly improves system response time by offloading the HTML generation to the client system thereby substantially reducing the processing performed on the server. It reduces the size of the messages transmitted between the browser and the web server, thereby substantially reducing the communication bandwidth required. It provides a rich set of local functions (performed on the client system) that eliminate requests to the server. This further reduces the processing load on the server and greatly enhances the overall responsiveness of the system. Siteras JView™ fully utilizes existing web browser standards thereby maintaining compatibility with existing client browsers (i.e., it supports a true thin-client implementation and does not utilize any special browser extensions—e.g., browser plug-ins, java applets, or ActiveX controls).

[0017] Using this core technology, the combination of the ESN's subrogation-specific business functionality and advanced technology provide many unique benefits for the insurance industry. Benefits of the Electronic Subrogation Network include streamlining inter- and intra-company subrogation workflow; reducing the amount of paper handling of subrogation documents and transactions; improving productivity of both subrogation staffs (demanding party) and claim office staffs (responding party) by eliminating many manual tasks; reducing cycle time of subrogation claims; increasing subrogation recoveries through better resource allocation and automatic counter-claims; reduce claims loss costs through electronic auditing of subrogation files; improving customer satisfaction by accelerating deductible refunds; reducing payment handling expenses; and providing valuable management information.

[0047] Subrogation Defined

[0048] Insurance subrogation is defined as the process by which one insurance company (demanding party) seeks reimbursement from another company (responding party) or person for a claim it has already paid. Examples of subrogation include:

[0049] Sally's vehicle is stopped at a stop sign when Pete's vehicle rear-ends her vehicle. Sally's car is damaged and she suffers some injuries. Sally files a claim with her auto insurance company. Her insurance company pays for Sally's damages and injuries, but believes that Pete was at fault in the accident. Sally's insurance company (demanding party) will then subrogate against Pete's insurance company (responding party) to recover the cost of the claims they paid.

[0050] Tom's house caught on fire as a result of a fire in the store next door. Tom files a claim with his homeowner's insurance company. Tom's insurance company pays for Tom's damages, but believes the store was liable for causing the fire. Tom's insurance company then subrogates against the insurance company of the store for the amount of the claims they paid.

[0051] Doug loses control of his sports utility vehicle and strikes a tree after his tires unravel. Doug files a claim with his auto insurance company who pays for his damages then subrogates against the SUV manufacturer and/or the tire manufacturer to recover the cost of the claim.

[0052] Jane's vehicle is hit by an uninsured motorist, Bob. Jane files a claim with her auto insurance company. Her insurance company pays for Jane's damages, but believes that Bob was at fault in the accident. Jane's insurance company will subrogate against Bob for the cost of the claim.

[0053] Current Subrogation Process

[0054] Subrogation today is a very manual, paper-intensive process. Some insurance carriers have information systems that help identify subrogation opportunities, but very few have any electronic communications with other carriers.

[0055] The subrogation process starts when the claim is first reported to the insurance carrier by the insured. During the claim investigation process, insurance carriers determine if there is an opportunity for subrogation. If a claim is “scored” as having an opportunity for subrogation, the file is transferred to the subrogation office (larger carriers have specialized units for subrogation while smaller carriers typically handle subrogation from their field offices with claim adjusters). Once the claim is paid, the subrogation office prepares a subrogation file consisting of a demand letter and some supporting documents. The demand letter contains basic information about the claim, e.g. claim amount, claim number, etc. as well as how much the demanding carrier believes the responding carrier is at fault. The subrogation file is then mailed to the responding carrier. The supporting documents usually include a copy of the estimate of damage off which the claim was paid, some proof of payment and copies of any associated invoices (e.g., rental car bill). However, supporting documents may include many other types of documents including police reports, photographs, vehicle valuation reports, witness statements, etc. Once assembled, the subrogation file (referred to as a “demand”) is then mailed to the responding carrier. Subrogation departments often have difficulty determining where to send subrogation demands especially when the responding party is a large insurance carrier with hundreds or thousands of claim offices. As a result, subrogation demands often are sent to the wrong location.

[0056] Typically, responding carriers receive and handle subrogation files in their field offices. These claims are known as third party claims. If a subrogation demand is sent to the wrong office, it is re-routed to the proper office. This may add weeks or even months to the process. Once the demand finally reaches the appropriate file handler (usually a claims adjuster), the file handler will compare the facts of the demand to the facts of the claim they have on file. Usually the responding carrier's insured will have already filed a claim by the time the responding carrier receives the subrogation demand. The responding carrier's claims adjuster will then investigate the claim and determine if the demanding carrier's demand is justifiable. Often this will include obtaining additional documentation from the demanding carrier including damage photos, witness statements, etc. If the adjuster agrees with the demand, then he will authorize the claim for payment. Most auto subrogation files are settled this way, i.e., without any negotiation. If he does not agree with the demand, then he will deny the claim or negotiate the claim with the demanding carrier. Typically, negotiation occurs via the telephone and details of the negotiation are usually not documented. If settlement is eventually reached, the responding carrier pays the agreed amount. If settlement is not reached, then the file goes to arbitration or litigation. If the at-fault party is an uninsured motorist (UM), most carriers outsource the collection effort to a collection agency.

[0057] Most of the major property and casualty carriers are members of arbitration networks—non-profit organizations created to arbitrate subrogation claims between carriers. Members of the arbitration networks always send their arbitration files to the arbitration network's arbitration service. The arbitration networks charge a fee per filing and the arbitration process usually takes about 90 days. If either the demanding carrier or responding carrier is not a member of the arbitration network then the file goes to litigation.

[0058] Payment between carriers is also very inefficient. Typically, checks are cut for each and every file between carriers. This may result in hundreds or thousands of checks a day flowing in both directions between major carriers. Once payment is collected, the demanding carrier refunds its insured for the deductible paid—again via check.

[0059] Due in large part to all the paper and manual processes, subrogation cycle time is often very long. A typical cycle time for an average auto subrogation file is 90-120 days. Cycle time can be much longer for files that go to arbitration or litigation, total loss claims, and uninsured motorist claims.

[0060] Management information on subrogation workflow (as typical of any paper-based process) is usually poor. Some carriers have limited information on the demand-side process and very few, if any, carriers have any meaningful management information on the response-side.

[0061] Types of Subrogation

[0062] Auto Physical Damage

[0063] Auto physical damage (“APD”) claims are those claims associated with the physical damage to the vehicle of an insured usually due to a collision. The vehicle may be repairable or it may be a total loss. Other claims that fall into this category include stolen vehicles and vandalism.

[0064] MedPay/PIP

[0065] MedPay/PIP claims are the result of injuries or sickness to a person covered by an insurance policy. MedPay/PIP claims include injuries from a vehicle collision.

[0066] Property

[0067] Property claims result from damage to real or personal property. Some property subrogation claims can be straightforward while others can be very large and complex to negotiate. Property claim volumes are much lower than auto claims, but property subrogation is a very similar workflow to APD.

[0068] Product Liability

[0069] Product liability claims result from damages caused by a defect in a product. Product liability subrogation claims usually involve complex negotiations and volumes are small.

[0070] Workers Compensation

[0071] Workers compensation claims result from injuries sustained in the course of performing one's occupation. Some workers comp subrogation claims can be straightforward while others can be very complex to negotiate.

[0072] Health Insurance

Like property and casualty claims, health insurance claims are also subrogated whenever the sickness or injury has been caused by negligence of another party.

[0073] Trends in Subrogation

[0074] Insurance carriers started to dedicate staff to subrogation in the mid-1990's. Historically, field claims adjusters handled subrogation claims. As larger carriers began to understand the significance and potential size of subrogation demand recovery dollars, they created special subrogation centers (usually centralized or regionalized) dedicated to recovering subrogation.

[0075] The subrogation function is not generally highly automated. Many of the larger carriers have implemented a rudimentary scoring system for identifying subrogation, but very few have implemented automation for enterprise-wide subrogation workflow. Paper and manual processes still dominate subrogation processes.

[0076] Several years ago, the industry recognized the need for improving inter-company communication of subrogation files. Through American National Standards Institute (“ANSI”), the industry formed a standards committee that completed an EDI X12 specification for subrogation in February 2001. The standard has not been implemented by any carrier. The standard defines business cases for only a subset of the real-world business cases. In addition, it assumes every carrier supports the standard and implements its own back-end software logic to interpret the data and execute its workflow.

[0077] Thus, there is needed an electronic subrogation system and process for all types of insurance claims, including those identified under the section entitled “Types of Subrogation.” Benefits of the Electronic Subrogation Network (“ESN”) of the present invention include: streamlining inter- and intra-company subrogation workflow’; reducing the amount of paper handling of subrogation documents and transactions; improving productivity of both the demanding and responding parties; reducing cycle time of subrogation claims; increase subrogation recoveries through automatic counter-claims; reducing claims loss costs through electronic auditing of subrogation files; improving customer satisfaction by accelerating deductible refunds; reducing payment handling expenses; and providing valuable management information.

Detailed Description—Electronic Subrogation Network (ESN)

[0078] The detailed description that follows may be presented in terms of programs, data structures or procedures executed on a computer or network of computers. These procedural descriptions and representations are the means used by those skilled in the art to most effectively convey the substance of their work to others skilled in the art.

[0079] As indicated above, the ESN acts as an electronic clearinghouse for subrogation demands and responses. The ESN is an Internet-based, computer implemented system and process that allows insurance carriers to interact with each other as well as with other parties (arbitrators, attorneys, collection agencies, etc.) involved in the subrogation process. With the ESN, parties can electronically send and receive subrogation demands, attach supporting documents (estimates, photos, police reports, etc.), negotiate online, settle files automatically, assign files to arbitrators and vendors, view and download online reports, automatically audit files, receive electronic alerts and notifications, and much more. In addition, the ESN includes the ability to send and receive electronic payments and net payments due. With the ESN's online reporting, parties have access to powerful management information on both subrogation demands issued and third party demands received. Because the ESN is web-based, information can be accessed anytime, anywhere provided the user has Internet access and implementation is often simple and straightforward since there is no software to install. If necessary, the ESN can interface directly to claims systems in virtually any format in a real-time or batch mode.

[0080] The ESN relates to an Internet- or other network-based system and process for electronically managing and settling inter-company subrogation transactions. The ESN provides a system for facilitating subrogation transactions and workflow between all parties involved in subrogation. As best seen in FIG. 2, the ESN may include data translation, collaboration, workflow, demand routing, security, business functions, business rules, electronic payments, subrogation folder reporting and connectivity modules or subsystems. Each subsystem or module, one or more of which may be used for processing a demand, may include software, hardware or both that facilitate processing of a demand.

[0081] The Electronic Subrogation Network (“ESN”), as indicated in FIG. 2, is a method for processing insurance subrogation claims through an electronic network. As best seen in FIG. 2, the ESN contains a variety of components and processes:

• • [0082] Subrogation Demand Information Submission & Document Management;
  • [0083] Subrogation Community Workflow;
  • [0084] Subrogation claim Routing;
  • [0085] Subrogation Follow-up Actions;
  • [0086] Subrogation Business Rules & Alerts;
  • [0087] Subrogation Advisor;
  • [0088] Subrogation Vehicle Valuation;
  • [0089] Subrogation Collaboration;
  • [0090] Subrogation Automatic Settlement;
  • [0091] Subrogation Automatic Counter claims;
  • [0092] Subrogation Assignment to Third Parties;
  • [0093] Subrogation Payment Handling;
  • [0094] Subrogation Payment Netting;
  • [0095] Subrogation Management Reporting;
  • [0096] Subrogation Benchmarking; and
  • [0097] Unified Data Model for Subrogation.
    Subrogation Demand Information Submission & Document Management

[0098] As best seen in FIG. 3, the ESN provides a method for submitting subrogation demands so as to provide a mechanism for transmitting structured (claims data from claims system) and unstructured (supporting documents and images) demand information, and provides a mechanism to digitize paper supporting documents.

[0099] In operation then, the ESN provides a process and system to perform the following operations: manually enter subrogation demand information into the ESN; upload file of subrogation demand records into the ESN; transmit subrogation demand files into the ESN via electronic interface.

[0100] The File Upload function allows a party to use the file upload capabilities within the ESN ASP to manually upload a file of transactions for processing. This technique can be used with any file format. It offers excellent security because it utilizes the same HTTPS transport as all other ASP-based interactive functions. Of all interface techniques, it requires the least amount of setup and configuration. To use File Upload, the party creates a file of subrogation demand records from their claim or subrogation system then uploads the file with the click of one button. The ESN then automatically maps each record to the Unified Data Model.

[0101] The ESN supports both batch and transactional interfaces. The batch interface allows a carrier to automatically send/receive a batch file of transactions to/from the ESN on a regular basis. Typically, a file transfer protocol is utilized (e.g., FTP, etc.). The file transfer is automated and does not require any manual processing. The transactional interface allows a party to automatically send/receive individual transactions to/from the ESN in a real-time event manner. This interface is fully automated and does not require any manual processing. This type of interface is used where real-time information is needed.

[0102] As best seen in FIG. 4, once the ESN receives a subrogation demand record, the ESN creates an electronic subrogation folder, which can contain both structured and unstructured information as well as a history file. The history file is a time-stamped event log for every action taken on the folder. The history file contains a time-stamped event log that tracks the documents that were affected by the event and the user ID of the user who took the action that created the event. The history file provides both demanding and responding parties with a comprehensive audit trail.

[0103] Through electronic interfaces or file uploads, the ESN can send and receive messages in many formats, including EDI X12, XML, or ASCII files. The ESN also supports the ANSI X12N 272 Automobile Subrogation Demand and Response standard.

[0104] As best seen in FIG. 5, unstructured supporting documents can be uploaded into the ESN generally with any of the following techniques.

[0105] When demands are submitted electronically, the electronic message (containing the demand data) can specify the URL (Internet location) for one or more related documents. Upon receipt of the electronic message, the ESN will automatically retrieve the specified document from the specified URL. This capability requires the sender to make all related documents available on a server that can be accessed via the Internet. Secure access to these documents can be provided in a number of ways (e.g., VPN, secure login, client-side digital certificates, etc.).

[0106] Users attach electronic supporting documents using the ESN direct attach function. Users browse to documents they wish to attach, select the document, select the type of document from a pull-down menu, provide a title and/or description of the document, select which parties have access to the document, then click an Attach button to attach the documents to the folder. To use this function, the supporting document must be available as a file on the local machine or on an available network server. Supporting documents can be in any of the following formats:

[0107]

	Application			Standard
Type	or Format	File Extension	MIME Type	Format
Document	Microsoft	.DOC	application/	pdf
	Word		msword
	Word Perfect	.wpd	application/
			wordperfect
			5.1
	Microsoft	.xls	vnd.ms-excel
	Excel
	Adobe Acrobat	.pdf	application/
			pdf
	Plain Text	.txt	text/plain
	HTML	.htm, .html	text/html
Graphics	JPEG	.jpg, .jpeg	image/jpeg	pdf
	GIF	.gif	image/gif
	TIFF	.tif	image/tiff
	PNG	.png	image/png
Audio	MP3	.mp3	audio/mpeg	mp3
	WAV	.wav	audio/wav
Video	MPEG	.mpg, .mpeg	video/mpeg	mpeg

[0108] The ESN then converts the source document from its original format into a standard format for universal viewing. Documents are converted into the following formats:

• • [0109] Documents—Adobe Acrobat viewer/plug-in.
  • [0110] Graphics—Adobe Acrobat viewer/plug-in.
  • [0111] Audio—any standard MP3 player/plug-in (e.g., Microsoft Media Player)
  • [0112] Video—any standard MPEG player/plug-in (e.g., Microsoft Media Player)

[0113] Any paper documents can be sent to the ESN using its fax support. To use this support, the user would first uses the “Quick Attach” function to select the type of document then print a special fax cover sheet. This cover sheet is then placed on top of the document to be faxed. The document can then be faxed to the ESN. Upon receiving the fax, the ESN will automatically scan the special cover sheet (using OCR) for special codes and information. Using this information, the system will attach the document to the appropriate demand folder. The ESN manages multiple version of supporting documents.

Subrogation Community Workflow

[0114] The ESN manages workflow between parties (two or more) within the subrogation process so as to provide consistent workflow for inter-company collaboration, provide real time status information to all parties involved, and trigger company-specific workflow based on events and exception conditions within the workflow.

[0115] The subrogation specific workflow model includes inter-company workflow states, transitions, conditionality, status, action flags, etc. Company-specific workflow is also provided within the context of community workflow.

[0116] As best seen in TABLE 1, the ESN may support standard codes to represent the state of a demand at any point in the process (i.e., the standard inter-company subrogation workflow). These standard codes establish the basis for consistent understanding and communication between parties regarding the status of a given demand. As such, these codes represent the standard ESN inter-party subrogation file status.

[0117] Additionally, the ESN may be configured to allow for the definition of party specific status codes (i.e., intra-company subrogation workflow). These codes enable an organization to define additional workflow states that are specific to their business processes while still maintaining a standard process definition between organizations.

Subrogation Claim Routing

[0118] The ESN routes subrogation demands to responding parties. A routing algorithm combines a demanding party specific index and a heuristic algorithm to determine the responding party. Data never actually leaves the ESN's server; the routing is virtual, and the file handler is notified of the demand on the ESN through an electronic notification (e-mail, page, text message, etc.). If notified via email, then the ESN provides a URL link for the user to access the ESN and the appropriate demand file. As best seen in FIG. 6, a responding party that is a member of the ESN will maintain routing rules in the ESN so that the ESN can electronically route incoming subrogation files to the appropriate office, group, or file handler. The ESN supports both Semi-Automated Routing and Automated Routing.

[0119] With Semi-Automatic Routing, the initial demand is routed to a responding party coordinator (“router”) in a central, regional, or claim office location. Using the ESN, the router can view all incoming demands (“Pending Routing”). Using their internal claim system, routers can determine the responding party's claim number associated with the demand and the group or individual currently assigned to the file. The router will then use the “Route Demand” function to update the demand with additional information (e.g., the claim number, the liability percentage, etc), and transfer the demand to the correct group/individual within the party's organization. After completing this function, the system has now “queued” this demand to the specified group/individual (“Pending Response”).

[0120] With Automatic Routing, the responding party will upload to the ESN a “claim index” file on a regular basis (e.g., daily). The claim index provides summary information about a claim, which permits a search to be made of the ESN to locate the claim. When the ESN receives an initial demand for this party, it may use the claim index to automatically route the demand to the correct group/individual within the responding party's organization. The claim index file can also be the basis for supporting automated agents within the ESN that can automatically review and respond to initial demands based on business rules.

[0121] The ESN also provides a function for first notice of loss conditions in which the ESN or the responding party can determine if the claim is a first notice of loss and automatically route the file to the responding party's loss reporting unit. When the responding party receives the initial demand, if the “claimant” (as identified in the initial demand) is insured/covered by the responding party, but no claim exists (within the responding party's claim system) for the specified loss date, then this demand represents a First Notice of Loss. In this case, the responding party will first need to establish a claim file (within their system) before processing this demand.

[0122] To support this workflow, the system will place this demand in a special state “First Notice of Loss”. Thereby allowing the responding party to easily identify and process all incoming demands in this condition. With automated routing, this condition can be automatically identified with the addition of a policyholder index. With semi-automated routing, the routing coordinator, which may be a human operator, can use the “FNOL” function to move the demand into this state.

[0123] The ESN also supports the ability to reassign a file to another file handler through the Assign function. This electronic routing function is available for parties who are members of the ESN.

[0124] As best seen in FIG. 7, a responding party that is not a member of the ESN will receive email or fax notification of subrogation demand from the ESN. A responding user can click a link in email to access the specific subrogation demand file. Responding parties who are not members of the ESN can reassign files by forwarding the ESN's email notification to the appropriate file handler. When an off-network responding user logs onto the system for the first time, the system will present a tutorial that provides a basic introduction to the ESN and familiarizes that user with the basic features they will need to correctly respond to the demand that was issued. Demanding parties will have access to online directory of off-network responding contacts, locations, and email addresses. This directory will be automatically updated whenever a demand is issued to a new off-network contact and is accessible by all demanding parties on the ESN.

Subrogation Follow-Up Actions

[0125] The ESN sets and automatically triggers follow-up actions for demanding users. As best seen in FIG. 8, if a responding party is not responding to subrogation demand, a demanding party can send multiple email reminders to a responding party. A demanding party can define company-specific follow-up action reminders in the ESN; for example, the ESN can issue reminders to demanding users to contact a responding user if there is no response in a specific timeframe defined by the demanding party. The ESN can issue alerts, reminders and next actions either to 1) a pooled team of demand users so that a given user in the pool gets the file that requires the next action, or 2) an individual file handler.

Subrogation Business Rules & Alerts

[0126] The ESN models the unique business practices of each member of the network and for handling workflow exception conditions so as to facilitate consistency between each member's business practices and the network's workflow.

[0127] The processing and functions performed by the ESN may be affected by a number of party specific parameters and settings. Collectively, these settings represent a party's “business rules” and allow a party to customize the processing of the ESN to support party specific business processes. Parties can define global or trading partner specific profiles and business rules. For example, when the ESN processes a given transaction, the logic within the ESN references an identified party's “business rules” and uses them to control the processing of the transaction. The ESN permits party specific business rules to be divided generally into a number of main categories as follows.

[0128] Company Rules

[0129] Define global settings for this party.

[0130] Workflow Rules

[0131] Define the party specific workflow.

[0132] Routing Rules

[0133] Define the party specific settings for semi-automated or automated demand routing. These settings are typically used to control how the ESN will route an incoming demand within a party's organization.

[0134] File Audit Rules

[0135] Define the party specific rules for file audits and conditions. This includes the following groups:

[0136] General

[0137] If total loss, was salvage deducted.

[0138] Demanding Party Specific

[0139] For any response received, is the Recovery percentage less than the Minimum Recovery percentage.

[0140] Responding Party Specific

[0141] Abnormal damage amounts specified as a percentage against the collision damage—i.e., rental reimbursement, towing, loss of use, etc. (by Demand Amount Range).

[0142] Maximum thresholds for various damage amounts (by Demand Amount Range.

[0143] Business Partner Rules

[0144] Define party specific settings applied to one or more business partners. A single generic set of rules can be established for all partners. In addition, a specific set can be established for a given business partner. In this case, these settings would then override any of the generic settings for this specific partner.

[0145] The following rules may also be included: required attachments for demands (by Demand Amount Range), and require attachments for demands based on each coverage code claimed.

[0146] Members can configure company-specific business rules. Every file is audited based on the business rules of all parties involved in the transaction. Alerts are triggered by exception conditions or violations of the business rules based on multi-party parameters (defined by ALL parties currently having access to the folder), e.g., a responding party can be alerted based on parameters of the demanding party.

[0147] Alerts may be customized for a particular party. This feature permits a party to determine specific exceptions conditions that will generate an alert. When viewing a file, if any alerts exist, an “Alert Pane” will be displayed within the file. When taking an action on a file, if any alerts exist or are newly detected, the user will be presented with a warning message. To continue with the transaction, the user must explicitly override this warning. In this case, the warnings and the user are logged in the history. The following list illustrates standard or generic alerts that may be included in the ESN:

[0148] File Audit Alerts

[0149] These alerts relate to exception conditions that are detected based on the “File Audit Rules” defined for a party.

[0150] Business Partner Exception Alerts

[0151] These alerts relate to exception conditions that are detected based on the “Business Partner Rules” defined for a party.

[0152] Comparative Negligence Alerts

[0153] These alerts relate to exception conditions that are detected based on the comparative negligence laws of the state where the loss occurred. For more information, refer to “Comparative Negligence Support” below.

[0154] Statute of Limitations Alerts

[0155] These alerts relate to exception conditions that are detected based on the statute of limitations laws for the applicable state.

[0156] Subrogation Advisor

[0157] The ESN assesses the best course of action within the subrogation process so as to improve subrogation performance, increase recoveries, and lower costs. The ESN can assess, for example, the cost-benefit of pursuing demand and/or pursuing a particular course of action, e.g., pursue litigation, etc.

[0158] Subrogation Vehicle Valuation

[0159] The ESN assesses the validity of a subrogation demand from a third party. For example, electronic audits for certain conditions of the file may be based on the configurable parameters of the demanding party, responding party, and vehicle value, e.g., total loss salvage, loss-of-use conditions, etc.

[0160] Subrogation Collaboration

[0161] The ESN provides a method for multiple parties including demanding party and responding party to collaborate interactively. As best seen in FIG. 9, a responding party can Accept (agree to pay), Counter (negotiate), or Deny (refuse to pay) a subrogation demand. As best seen in FIG. 10, a responding party can prepare a counteroffer that may include counters on liability percentage and/or damage amounts (e.g., amount of collision damage, amount of rental reimbursement, etc.). A demanding party can define minimum acceptable counteroffers on a file-by-file basis and the ESN will issue an alert to the demanding party if a counteroffer is below a demanding party's minimum. As best seen in FIG. 11, a demanding party can define business rules regarding minimum acceptable counteroffers including liability percentage, damage amounts, and/or total demand, and the ESN can automatically approve counteroffers if the demanding party's business rules are met. As best seen in FIG. 12, a responding party can deny a demand and provide standard denial codes back to the demanding party.

[0162] Business Functions

[0163] The ESN provides business functions that support subrogation workflow. In addition to the standard functions provided in TABLE 2, the system allows a party to define custom functions that are specific to their business process and workflow. These custom functions can be defined to control data modification or display.

[0164] Subrogation Automatic Settlement

[0165] As best seen in FIG. 13, the ESN provides a method for settling subrogation claims between parties automatically with little or no human intervention by eliminating many manual tasks, and reduce cycle time for subrogation files. The ESN functions to settle files electronically if the file passes both parties' business rule audits and both parties' liability calls (the liability percentage assigned by each party to each party's insured) match or overlap. The liability call from the demanding party is provided in the initial demand submission. The liability call from the responding party is read by the ESN via an electronic interface to the responding party's claim system or via a claim index provided by the responding party. “Anti-gaming” capabilities eliminate responding parties guessing at demanding parties' business rules and/or liability calls.

[0166] Subrogation Automatic Counter Claims

[0167] As best seen in FIG. 14, the ESN may create counterclaims when in regulatory compliance, i.e., is configured to include the relevant laws of the state where the loss occurred, so as to help reduce lost counterclaim opportunities, and to help increase subrogation recovery, to help improve productivity of both demanding parties and responding parties by eliminating many manual tasks, and to help reduce cycle time for subrogation files.

[0168] Upon settlement of original demand, the ESN can audit liability percentage and comparative negligence regulations of the appropriate state department of insurance then, when the initial demand is settled at a liability percentage less than 100% for the responding party and meets the comparative negligence regulations of the state of loss, automatically prepare a counterclaim for the responding party against the demanding party for their fair share of the liability. For example, if the loss was in a pure comparative state and the two parties agreed on an 80% liability to the responding party on the initial demand, the ESN will prepare a counterclaim demand for the responding party for the 20% liability against the demanding party. Counterclaims are linked to the original demand. The ESN will alert a demanding party if their business rule audits are violated.

[0169] Within the ESN, users can create counterclaims in one of two ways—1) Using the “Create Counterclaim” action, or 2) Issuing a new demand where the demanding and responding claim numbers link to an existing demand (in a reverse relationship).

[0170] Create Counterclaim

[0171] Once the responding party has accepted a demand, the system will determine whether or not a counterclaim opportunity exists for this demand (depending on the liability percentage and the comparative negligence laws of the specific state which apply to this demand).

[0172] In processing the “Accept” function for a demand, the system will analyze these conditions. If this demand has the opportunity for a counterclaim, then the system will automatically flag it as such. A responding party specific view “Counterclaim Opportunities” will be provided that lists all demands that are candidates for issuing a counterclaim.

[0173] To issue a counterclaim, the responding party will select one of the demands from the “Counterclaim Opportunities” view. When that view is displayed, a new action will be available “Create Counterclaim”. This action can be used to create a new demand document that is linked to the initial demand. When this document is created (via Save), the ESN automatically routes the counter claim to the demanding party that issued the initial demand. In doing so, both the initial demand and the counterclaim will be crosslinked (i.e., refer to one another).

[0174] Automatic Counterclaim Linking

[0175] When two companies issue demands to each other (independently) for the same loss, at the point the second demand is issued, the ESN will recognize the counterclaim relationship and automatically link the demands. This capability handles the situation where both companies believe the other to be “at-fault”.

[0176] In general, any time the ESN detects that two demands have been issued between two companies (where the demanding and responding claim numbers reference each other); the system automatically “links” these demands.

[0177] Once a counterclaim relationship has been identified, the user can easily move back and forth between both claims by selecting the link to the counterclaim. From that point on, the collaboration capabilities for the counterclaim are exactly the same as for the initial demand.

[0178] Additionally, the ESN will also apply its knowledge of the comparative negligence laws of the appropriate state and issue warnings in the event a party's ability to issue, or continue with, a counter claim is impaired.

[0179] Additional views are provided to enable the responding party to manage counter claims that have been issued.

[0180] Within each state, comparative negligence laws are defined which govern the ability of a given party to issue a counterclaim. When a demand is being “Accepted” by a responding party, the ESN will apply the comparative negligence laws of the loss location state. Based on these laws, if the demand is accepted, the ESN will issue warnings to the user under the following situations: a counterclaim has not been issued, but accepting this demand will prevent a counterclaim from being issued; and a counterclaim has been issued, but accepting this demand may “invalidate” the counter claim that is currently “in negotiation”. In this case, the system will require the user to override this warning in order for the demand to be accepted.

[0181] Major Types of Comparative Negligence Laws

[0182] There are three major types of negligence laws—pure comparative, modified comparative (49% and 50%), and none (i.e., contributory negligence). The following is a summary of how these laws affect the ability to issue claims and counter-claims.

[0183] Pure Comparative

[0184] The at-fault party can issue a counter-claim for any liability between 1% and 50%.

[0185] Modified Comparative 50%

[0186] Unless both parties agree to liability of 50%, the at-fault party cannot issue a counter claim.

[0187] Modified Comparative 49%

[0188] The at-fault party cannot issue a counter-claim. If both parties agree to 50% liability, then neither party can issue a claim to the other.

[0189] None

[0190] No subrogation is allowed. Neither party can file a claim.

[0191] Subrogation Assignment to Third Parties

[0192] The ESN provides a method for assigning subrogation files to third parties so as to improve productivity of both demanding parties and responding parties, reduce subrogation cycle time, and provide consistent management information.

[0193] As best seen in FIG. 15, a demanding party can place arbitration filing through the ESN. Once the demanding party selects the arbitrate function, the ESN electronically notifies the responding party that the demanding party is filing for arbitration. This gives the responding party one more chances to settle prior to binding arbitration. The demanding party can then electronically file arbitration at any time after the initial notice is sent to the responding party.

[0194] Through its multi-party support function, the ESN notifies the arbitrator that the demanding party has filed for arbitration and provides the arbitrator with a view of all demands that have been filed for arbitration. The arbitrator can then enter hearing dates, docket numbers and other information into the file. The responding party can then review the arbitration filing online and file their answer. Once the hearing is complete and the judgment is awarded, the arbitrator can notify both parties of the award through the ESN. In this way, the ESN becomes an electronic “gearbox” for arbitration.

[0195] The ESN is designed to enable controlled access to each “shared” subrogation folder by multiple parties. In doing so, each party typically has a specific “business relationship” to that folder (Demander, Responder, Arbitrator, etc.). The ESN explicitly defines these named relationships; and for each relationship, the ESN explicitly controls what information is seen within the folder and what actions can be taken.

[0196] For example, suppose three parties are set up on the ESN—Gordon Insurance, Acme Insurance, and Arbco. If Gordon issues a demand to Acme, then when the subrogation folder for that demand is created, the demanding party will be Gordon (Demander relationship) and the responding party will be Acme (Responder relationship). As such, all users of Gordon will be limited to the data and functions associated with the “Demander” relationship when accessing this folder; and all users of Acme will be limited to the data and functions associated with the “Responder” relationship when accessing this folder.

[0197] Additionally, if Gordon submits the file for arbitration, then their arbitrator (Arbco) will be given access to the file. In doing so, all users of Arbco will be limited to the data and functions associated with the “Arbitrator” relationship when accessing this folder. Furthermore, if Acme had submitted a demand to Gordon, then the Demander/Responder relationships would be flipped for that specific subrogation folder.

[0198] When a company is setup on the ESN, all possible relationships for a given company are defined. In the example above, both Gordon and Acme would be configured to support both the “Demander” and “Responder” relationships. However, Arbco would be configured to only support the “Arbitrator” relationship (since it cannot directly issue or respond to subrogation demands).

[0199] As best seen in FIG. 16, either a demanding party or a responding party can electronically assign a subrogation file to a vendor (e.g. collection agencies, outside attorneys, service providers, etc.) through the ESN. When a demanding party or responding party uses the assign function, the ESN automatically notifies the third party that there is a file they need to work. Depending on the interface from the third party, the ESN either notifies through an e-mail with a URL link or actually passes the file information through an interface to the third party's system. The ESN also provides the ability for third parties to enter status updates in the ESN.

[0200] Subrogation Payment Handling

[0201] The ESN provides a method for handling payments between parties involved in a subrogation claim so as to improve productivity of both demanding parties and responding parties by eliminating many manual tasks, and lower the costs of payment handling.

[0202] As best seen in FIG. 17, after receiving payment from responding parties, demanding parties can enter payment information manually into the ESN or upload files of payment information (payment amounts, dates, associated claim numbers, etc.) into the ESN. The ESN will automatically close out files where payment has been made in full. As best seen in FIG. 18, EFT payments can be triggered automatically upon acceptance by the responding party—the ESN can generate a message to a responding party's bank to trigger EFT or the ESN can generate a message to a responding party's system that in turn will initiate a message to a bank to trigger EFT (in the latter case, a responding party's system will send an EFT confirmation message back to the ESN).

[0203] Subrogation Payment Netting

[0204] As best seen in FIG. 19, the ESN provides a method for netting payments between parties involved in a subrogation claim so as to improve productivity of both demanding parties and responding parties by eliminating many manual steps, and lower the cost of payment handling.

[0205] The ESN functions to track payments owed and payments due over any time period for any member and provides information on or automatically triggers a payment. Payments can be netted bi-laterally (e.g., between two parties as best seen in FIG. 19) or multi-laterally (between a party and the ESN, which represents all members participating in the netting service). In bi-lateral netting, the ESN keeps track of the payments owed between two parties and initiates a notice for EFT to the party who has the payment balance at the end of any time period defined by the two parties. For example, if Party A and Party B agree to net payments every week, the ESN will track the amount of all the payments owed from A to B in the week and all the payments owed from B to A in the week, determine which party owes more and initiate a payment notice to the appropriate party. In multi-lateral netting, the ESN nets all payments and receipts with all the parties participating in the netting service for a given party. The ESN is then paid by the party or pays the party depending on the balance. Parties can configure the ESN to define party-specific netting periods. The ESN will provide management information and reconciliation file to allocate netted payments to each appropriate file.

[0206] Subrogation Management Reporting

[0207] The ESN provides management information to members of the network so as to improve subrogation performance for all parties, and provide better management information to both subrogation managers and claims managers. The ESN provides two types of online reporting—detail and summary. For subrogation, a number of standard reports may be provided with the ESN (listed below). The ESN allows members to filter, sort, and view management reports online. In addition to the standard reports, a member can define custom reports that are specific to their organization's business process and workflow.

[0208] For summary reports, typically data can be aggregated along the major dimensions of time period, geography, party, office, region, department, file handler/team, and status. Within these dimensions, the main data elements that can be summarized may include Demand Total Dollar, Response Total Dollar, Recovery Percentage Cycle Time or other relevant or desired data elements. For any of the identified data elements, the following summary statistics are generally supported: sum, average, weighted average, percentage, maximum, minimum, and count. However, other needed statistics may be supported.

[0209]

Typical Demander Reports
Pending Files	Total Payments - Amount demanding party
	paid to close coverage
	Total Demands - Amount demanding party
	demanded
	Number of Files - Number of open files
Dollars Recovered	Total Dollars Recovered - Total Dollars
Files	recovered from all closed files
	Avg. Recovery Percentage -- Total Dollars
	recovered divided by the total Dollars
	demanded
	No. of Files - Total number of closed files
	Avg. Cycle Time - Date of demand issuance
	to payment receipt
Cycle Time	Date of Loss to Demand Issuance (days)
	Demand Issuance to Promise-to-Pay (days)
	Demand Issuance to Payment Receipt (days)
	Date of Loss to Payment Receipt (days)

[0210]

Responder Reports
	Pending Files	Total Payments - Amount demanding
		party paid to close coverage
		Total Demands - Amount demanding
		party demanded
		Number of Files - Number of
		open files
	Paid Files	Total Dollars Paid - Total Dollars
		paid from all closed files
		Avg. Payment Percentage - Total Dollar
		paid divided by the total Dollars
		demanded
		No. of Files - Total number of
		closed files
		Avg. Cycle Time - Date of demand
		issuance to payment receipt
	Cycle Time	Demand Issuance to Promise-to-pay
		(days)
		Demand Issuance to Payment Receipt
		(days)
	Counter Claims	Total Dollars Recovered - Total
		Dollars recovered from all closed
		files
		Avg. Recovery Percentage - Total
		Dollars recovered divided by
		the total Dollars demanded
		No. of Files - Total number of
		closed files
		Avg. Cycle Time - Date of counter
		claim issuance to payment
		receipt

[0211] Operational Reports

[0212] Operational Reports are designed to provide management information to system administrators. Standard reports include User Profile Reports and Usage Reports.

[0213] Subrogation Benchmarking

[0214] The ESN provides a method for members of the network to conduct benchmarks of best practices across the insurance industry so as to improve subrogation performance in all insurance carriers, and provide better management information to both subrogation managers and claims managers. The ESN allows members to benchmark various parameters of their subrogation and/or claims operation against the aggregate industry based on the ESN's database. For example, demanding parties may benchmark their recovery ratios against the industry for a specific geographic area; responding parties may benchmark their payout ratios against the industry for a specific geographic area.

[0215] Unified Data Model (UDM) for Subrogation

[0216] As best seen in FIG. 20, the ESN provides a method for organizing and modeling subrogation-specific business information so as to provide consistent data to both demanding parties and responding parties, and provide translation of data from one format to another format. The ESN provides entities, attributes, and relationships specific to subrogation workflow. Incoming data formats are translated from their source format to the UDM format. UDM data formats are translated to outgoing data formats. Symantec translations occur such that the meaning of any particular element is consistent from file-to-file.

[0217]

TABLE 1
Inter-company States (Status)
A demand file can only be in one of the
following discrete “inter-company” states at a time.
Discrete State	Description
Pending	Indicates that the demand file has been
Issuance	received by the ESN (either electronically
	or via demand file upload) and that the
	ESN detected an error that is preventing
	this demand from being issued (e.g., missing
	or invalid data). At this point, the demand
	has not been issued to the responding party
	and can only be viewed by the demanding party.
Pending	Indicates that the demand has been issued
Routing	and assigned to a responding party, but this
	party has not “routed” this demand
	within its organization. For responding
	parties using semi-automated routing, this
	status is normal. For responding parties
	using automated routing, this status is rare.
Pending FNOL	Upon receipt of the demand, if the demand
	represents the “First Notice of Loss”
	for the responding party, then this status
	indicates that the responding party is in
	the process of setting up a claim file within
	their claim system.
Pending	Indicates that the demand has been routed to
Response	a file handler within the responding party's
	organization and is awaiting an initial response.
Pending	Indicates that the demand has been initially
Investigation	reviewed and is being investigated by the
	responding party.
Counter Offer	Indicates that the responding party reviewed
Issued	the demand, and that a counter offer has been
	made for consideration by the (D)emanding party.
Counter Offer	Indicates that the demanding party reviewed
Approved	the counter offer and agrees to the terms of
	the counter offer.
Revised	Indicates that the demanding party reviewed
Demand	the counter offer and that the demand has been
Issued	revised for consideration by the (R)esponding
	party.
Disputed	In the event that demanding party and
	responding party cannot agree on the demand,
	and if arbitration is not an option, then
	this status indicates that the demand is in
	dispute. At this point, the demanding party
	is typically evaluating whether or not to
	pursue litigation.
Denied	Indicates that the responding party has
	denied the demand.
Pending	Indicates that the demanding party intends
Arbitration	to submit this demand to arbitration and is
Filing	now in the process of preparing their
	contentions.
Arbitration	Indicates that the demand is formally in
Filed	arbitration. The demanding party has submitted
	this demand for arbitration and the
	(R)esponding party is now required to submit
	their response to the arbitration filing.
Arbitration	Indicates that the demand is formally in
Answer Filed	arbitration. The responding party has submitted
	their response to the arbitration filing. The
	file has been assigned to an (A)rbitrator
	and is awaiting the award of a settlement.
Settlement	Indicates that the arbitration process is
Awarded	now complete and that a settlement has been
	awarded. The responding party must now
	“Accept” the settlement.
Accepted	Indicates that the responding party has
	“Accepted” the demand as it currently
	stands, and will now proceed with the payment
	of the agreed amount to the demanding party.
	This status represents a formal “promise
	to pay” by the responding party.
Closed	Indicates that the file has been closed. In
	the typical case, this will represent that
	the demanding party has received all
	outstanding payments as agreed from the
	responding party. If not, the file disposition
	codes will indicate the reason for file
	closure.

Aggregate States

[0218] In addition to the discrete states listed above, the workflow subsystem may include the following “aggregate states.” An aggregate state is a set of two or more discrete states. Standard views are provided within the system to display files in a given aggregate state.

[0219]

	Aggregate
	State	Description
	Open	Any file that is not “Closed”.
	Pending	Any file that is “Open” and
	Acceptance	not “Accepted”.
	In-Negotiation	Any file that is “Counter Offer
		Issued”, “Counter Offer Approved”,
		or “Revised Demand Issued”.
	In-Arbitration	Any file that is either “Arbitration
		Filed” or “Arbitration Answer Filed”.

[0220]

TABLE 2
Demander Functions
The following section lists the business functions
that are typically specific to a Demander.
	Function	Description
	Create	Manually create and issue a new demand.
	Demand
	Repair	Manually correct an incomplete or invalid
		demand that was created from a demand
		file upload or an electronic message.
	Delete	Manually delete an incomplete or invalid
		demand that was created from a demand
		file upload or an electronic message. Once
		a demand file has been issued, it cannot
		be deleted.
	Revise	Revise a demand. This function is typically
		used in response to a counter offer that
		was received from a responding party.
	Approve	Approve a counter offer. This approval
		indicates the acceptance, by the
		demanding party, of the proposed counter
		offer and allows the responding party to
		now “Accept” the demand as currently
		proposed in the counter offer.
	Arbitrate	Prepare to submit a demand for arbitration.
		This function indicates to the responding
		party that the demand is being prepared for
		arbitration. This action places the file in a
		state (Pending Arbitration Filing) that allows
		the demanding party to prepare and attach
		their arbitration contentions.
	File	Formally submit the demand for arbitration.
	Arbitration	This action implicitly grants “Arbitrator”
		access rights for this specific file to the
		arbitration service, thereby allowing them
		to process the arbitration filing.
	Supplement	Amend a specific demand to include a
		“supplement”.
	Dispute	Indicate that no agreement can be reached
		with the responding party. This function is
		typically used to indicate that the
		demanding party cannot reach agreement
		with the responding party and that
		arbitration is not an option. At this point,
		the demanding party will decide whether or
		not to litigate the file or close it. It places
		the file in a state (Disputed), which allows
		the demanding party to easily identify all
		files in this condition.
	Apply	Record a payment received for a file. This
	Payment	function will apply the payment to the
		specific file. If the payment relieves the
		outstanding balance on the file, then the file
		will be automatically closed.
	Close	Close a file. This function will typically be
		performed automatically when the final
		payment is applied to the file. When used
		manually, the user will be required to
		specify a file disposition representing the
		reason for closure.
	Reissue	Reissue a demand to another party. If a
		demand was issued to the wrong
		responding party, this function allows the
		demanding party to reissue the demand to
		the correct responding party.
	Reopen	Reopen a file that has been closed. This
		function allows a demanding party to
		re-open a file that has been closed for the
		purpose of presenting additional payment
		amounts for recovery, or for providing new
		information to the responding party for
		reconsideration.
	Upload	Upload a file of demands. This function is
	Demands	used to manually upload a file of demands
		to the ESN. In processing this command,
		the ESN will ensure that the complete
		contents of the file are successfully stored
		on the ESN. It will then respond back to
		the user. In the background, the ESN will
		process each demand in the file by
		creating a demand and issuing the
		demand to the correct party. A view will be
		provided that enables the user to review
		the status of the subsequent processing of
		the demand upload.
	Upload	Upload a file of payments. This function is
	Payments	used to manually upload a file of payments
		to the ESN. In processing this command,
		the ESN will ensure that the complete
		contents of the file are successfully stored
		on the system. It will then respond back to
		the user. In the background, the ESN will
		process each payment in the file by
		applying the payment to a specific demand
		file. If the payment relieves the outstanding
		balance in the file, it will automatically close
		the file. A view will be provided that
		enables the user to review the status of the
		subsequent processing of the payment
		upload.
	Responder	The following section lists the business
	Functions	functions that are typically specific to a
		Responder. In general, the main
		responding party functions are available to
		both on-network and off-network
		responding parties. Where a function is
		only available to an on-network responding
		party, it is so indicated.
	Accept	Accept a demand. This function is used to
		accept the terms of the demand as it
		currently stands. In doing so, this
		represents the formal “promise to pay”
		commitment on the part of the responding
		party.
	Counter	Make a counter offer. This function is used
		by a responding party to make a counter
		offer to a demand. When making the
		counter offer, the responding party can
		alter the liability percentage or the payment
		amounts.
	Investigating	Indicate that the demand is being
		investigated. This function will change the
		status of the file to “Pending Investigation”.
	File	File a response to an arbitration filing. If
	Arbitration	the demanding party has submitted the file
	Answer	for arbitration, the status of the file will be
		changed to “In-Arbitration (R)”. At this
		point, the responding party may prepare
		and attach its response to the arbitration
		filing. After the response has been
		attached, then this function is used to
		indicate that the response has been filed.
		This function will change the status of the
		file to “In-Arbitration (A)” indicating that it is
		now ready to be reviewed by the arbitrator
		for a final judgment.
	Deny	Deny the demand. This function is used to
		indicate that the demand is being denied.
		When denying a demand, the responding
		party must select a denial code from the
		ESN's list of standard denial codes.
	Create	Create and issue a counter claim. After a
	Counter	demand has been accepted, the ESN will
	Claim	determine whether or not the responding
		party can issue a subrogation counter
		claim. If so, then this function is used to
		create and issue the counter claim.
	Route	Route an incoming demand within the
	Demand	responding party's organization. For
		responding parties using semi-automated
		demand routing, this function is used to
		manually route/assign the demand to the
		appropriate team or individual.
	FNOL	Indicates that the demand represents the
		“First Notice of Loss” to the responding
		party. This function changes the status of
		the file to “Pending FNOL” and allows the
		responding party to first establish a claim
		file within their claim system.

Arbitrator Functions
The following table lists the business functions that are typically specific to an Arbitrator.

[0221]

	Function	Description
	Award Settlement	Award a settlement to the demanding party
		that filed the arbitration. This function is
		used by an arbitrator to award a settlement
		to the demanding party that filed the
		arbitration.

Common Functions
The following table lists business functions that are not specific to a given relationship and may be shared by all relationships (unless specifically noted). Where a function is only available to an on-network party, it is so indicated.

[0222]

	Function	Description
	Attach	Attach a related document to the file.
		When using this function to attach the
		related document, the document must exist
		as a file on the local system or network
		accessible by the local system. The user
		will be required to enter the file name, or
		use the “file browser” to locate the file to be
		attached. When attaching a document, the
		attachment can be marked as “Private”.
		Private attachments can ONLY be viewed
		by the users of the party who created the
		private attachment.
	Fax	Prepare the fax cover sheet for related
	Attachment	documents that are being attached to a file
		by fax. When a related document exists as
		a paper document, this document can be
		attached to the file by faxing the document
		to the ESN. To do so, a special fax cover
		sheet needs to be attached as the first
		page of the fax. This function is used to
		create the special fax cover sheet. The fax
		cover sheet will be displayed in a separate
		browser window where it can then be
		printed.
	Note	Make a free-form text note in the file.
		When making a note, the note can be
		marked as “Private”. Private notes can
		only be viewed by the users of the party
		who created the private note or other
		designees.
	Inquiry	Make a free-form text note requesting a
		clarification or more information from
		another party. This function differs from
		the Note function above only in that a
		“reply” is expected from the party to whom
		the request is being issued.
	Update	Update any other data fields within the file
		that do not affect the business terms of the
		demand (e.g., loss date, loss location,
		responding party's claim number, etc.).
		This function is used to update certain
		details of the file that do not affect the
		current terms of the subrogation demand
		(i.e., this function does not allow the
		payment amounts or the liability
		percentage to be modified). A separate
		version of this function is available for each
		party to maintain shared data elements or
		party specific data elements (that are
		private to that party).
	Assign	Transfers file ownership to another team or
		individual within an organization. This
		function is used accommodate intra-
		company workflow and file assignment by
		allowing the ownership to be changed
		within an organization.

Background—JView

[0223] During the mid to late 90's, the commercial use of the Internet emerged and flourished due in large part to the emergence of user-friendly browser technology (e.g., Mosaic, Netscape, Internet Explorer, etc.). This movement fueled the wide scale implementation of web-based systems (web servers) to support the growing number of browser-based users. One key to this movement was the definition of message format standards (i.e., HTML) that were supported by all browsers.

[0224] The initial web servers were used to provide static content by merely transmitting static web pages (containing HTML) to a browser. Using this approach, web sites were created by developing sets of interrelated web pages that were linked together.

[0225] As the use of the Internet expanded, it became necessary for these servers to deliver dynamic content (e.g., a page with the current status of an order, a page with the current arrival time of a flight, etc.). Dynamic content requires that the server dynamically construct the information for each browser request. In doing so, the server uses logic to analyze what information is requested, retrieves the information from the necessary data source, and dynamically constructs the web page containing HTML (i.e., HTML Generation) for transmission back to the browser. Using this approach, the browser cannot distinguish a static page from a dynamic page.

[0226] Browser technology also evolved in parallel with web server technology. Most notably, was the development of a standard browser scripting capability that allowed a user to interact with a web page without creating a new request back to the web server. This greatly enhanced the user interaction and responsiveness capabilities of the browser making it possible to construct a rich user interface (similar to that of a standard fat-client interface). This scripting capability was initially referred to as JavaScript, but is now formally referred to as ECMAScript.

Requirements and Challenges

[0227] Currently, most web-based systems expend processing cycles to format the dynamic content into HTML format. This processing load can account for 30-50% of the processing load for a typical server. Relative to the size of the information being transmitted, the size of the HTML stream containing this information is substantially larger (by 3-5×). This requires additional communication bandwidth for transmission. Being dependent on the server for web page generation requires each user interaction to be processed by the web server, which results in increased response time for various operations (e.g. sorting a result page of items, performing data validation, performing calculations, etc.).

[0228] The JView subsystem, described below, overcomes these limitations by 1) off-loading the HTML generation to the client system, thereby substantially reducing the processing performed on the server, 2) reduces the size of the messages transmitted between the browser and the web server, thereby substantially reducing the communication bandwidth required, 3) provides a rich set of local functions (performed on the client system) that eliminate requests to the server; this further reduces the processing load on the server and greatly enhances the overall responsiveness of the system, and 4) fully utilizes existing web browser standards thereby maintaining compatibility with existing client browsers (i.e., it supports a true thin-client implementation and does not utilize any special browser extensions—e.g., browser plug-ins, java applets, or ActiveX controls).

[0229] These capabilities are achieved with a JavaScript subsystem that runs within the browser and an HTML compatible message structure (a “Siteras Transaction Message”—STM) that is transmitted between the browser and the server.

[0230] Within the client browser, the JView™ subsystem consists of a series of JavaScript files. In response to an initial request to the web server, a small set of JavaScript files (i.e., the JView™ subsystem core) are downloaded to the client browser. Once downloaded, these files are cached by the browser (just like other images or static pages). Additional JavaScript files are downloaded on a modular basis as they are needed by the various application interactions with the server (once downloaded, these additional files are also cached by the browser). These JavaScript files provide the browser with the ability to perform the following functions locally (without any further interaction with the server): HTML Generation (all HTML generation is performed by the JView™ subsystem on the client); sorting (including multi-column sorting); data formatting (dates, numbers, percents, etc.); dynamic HTML (e.g., expanding/collapsing panes/tabs); print formatting and preview; hierarchical menuing; syntactical editing and validation; basic application validation; static and dynamic domain management (i.e., checking a value against a list of values); required field checking; application calculations; and response time measurement

[0231] Within the JView™ subsystem, a unique set of JavaScript coding techniques are employed to keep the response time overhead for the JView™ subsystem processing itself to a minimum.

[0232] Each interaction with the server consists of a standard HTTP request/response (the format of which is HTML 3.2 based and contains a “Siteras Transaction Message” (STM)). The STM is a hierarchical structure of key-value pairs (similar to an XML based message in structure and content). Unlike a typical server generated HTML message, the STM contains mostly business data. As such, the size of this message is greatly reduced. Essentially, this message structure is used to deliver a “data island” to the client browser where the JView™ subsystem can operate on it generically. NOTE: There are two reasons why the JView™ subsystem uses the STM vs. XML format—1) The STM maintains compatibility with a broad set of browsers (many browsers do not support XML), and 2) XML is also very verbose and is 1-2× the size of the STM.

JView™ Benefits

[0233] The following is a summary of the key features and benefits of the JView™ subsystem architecture. Taken together, these features allow the JView™ subsystem to approach the performance and functionality of a fat-client system, with ease of use and manageability of a thin-client system.

[0234] Broad Browser Compatibility

[0235] The system can work with any browser that supports JavaScript v1.2, HTML 3.2, and CSS Level 1.0. This provides support for a broad number of browsers, including older versions of mainstream browsers (e.g., 4.x series browsers from both Microsoft and Netscape). It does not utilize any of the features that are specific to a given browser type or version.

[0236] Totally Thin Client

[0237] The system supports true “thin-client” architecture in that it does not require or utilize any java applets, java applications, browser plug-ins, or active-X controls. Additionally, it does not utilize persistent “cookies”.

[0238] Exploits Client System Processing Power

[0239] Many of the JView™ subsystem features are aimed at utilizing the local processing power of the client machine. This greatly improves the responsiveness of the system, reduces the number of interactions with the server, and offloads the server from having to perform this processing. The performance of the JView™ subsystem has been optimized to have as minimal an impact as possible on the response time to/from the server. In general, the JView™ subsystem processing adds less than 1 second of response time to any server interaction. Additionally, as the processing power of client systems continues to improve the response time overhead due to the JView™ subsystem processing should continue to reduce.

[0240] Reduces Transmission Size

[0241] On a transaction-by-transaction basis, the size of the STM stream to/from the server is 4 to 5 times smaller than the comparable server generated HTML page. This characteristic makes it ideal for applications where dial-up access or other low-bandwidth channels (e.g., wireless) are still dominant.

[0242] Reduces Server Processing Load

[0243] Due to the offloading of HTML generation to the client system, and the reduced number of interactions with the server (because of the JView™ subsystem local processing capabilities), the processing load for the typical server is reduced by 30-50%.

[0244] Improves End User Response Time

[0245] Due to reduced transmission size, the use of dynamic HTML, and the other functions and services that are performed locally, the JView™ based subsystem outperforms a typical server based HTML implementation by a factor of 8-10 times.

[0246] Rich User Interface

[0247] Due to the local processing capabilities (described above), the user interface capabilities of the JView™ subsystem are comparable with those of many fat-client systems.

[0248] Improves User Interface Development Productivity

[0249] The typical development cycle for thin-client user interfaces involving dynamic content starts with the graphic designer creating static pages as prototypes. Once these are approved, they are given to an engineer to be coded (so that the pages can be dynamically generated within the server). Multiple iterations of review and correction often follow. In general, this is a serial development process.

[0250] With the JView™ subsystem architecture, the development of the user interface can proceed in parallel with the development of the server side transaction processing code. All that is needed at the outset is the definition of the STM (i.e., the data packet) for each type of interaction. Once the STM is defined, both the UI and the server side code can be developed in parallel. In addition, there is no effort wasted on a UI prototype. Various iterations of the UI can be developed and refined, and once done; the UI is ready for production. Only a final integration test with the server side code is needed to ensure operability.

[0251] Provides a Foundation for User Interface Customization

[0252] Since the UI is maintained externally from the server code, and since the transaction request is message based, the JView™ subsystem architecture supports a high degree of UI customization (without the need to modify the code on the server).

Commercial Example

[0253] The Electronic Subrogation Network is a commercial example of a fully operational system that embodies the concepts described herein specifically for the vertical market of Insurance Subrogation claims Processing.

Terminology

[0254] This section contains terminology definitions that are useful in understanding the concepts described in the description that follows.

[0255] Browser-Based Client

[0256] A client system should have a browser that supports HTML 3.2 (or higher) and ECMA script 1.0 (or higher). (ECMA script is commonly referred to as JavaScript). Examples include, but not limited to, Microsoft Internet Explorer v4.0 or higher and Netscape Navigator 4.7 or higher.

[0257] Server-Based HTML Generation Approach

[0258] Any approach wherein the server produces an HTML stream and where such stream contains the user-interface tags such that the browser merely needs to “render” this HTML stream for display.

[0259] End-User Session

[0260] A finite period of time, usually denoted by explicit logon and logoff events, that allows a given user to conduct one or more application specific processing requests.

[0261] Basic Thin Client Architecture

[0262] An architecture that provides application functionality to an end-user via a browser-based client that accesses a server, wherein the browser-based client does not rely on any special extensions including, but not limited to, non-standard plug-ins, download-able java applets, and/or ActiveX controls.

[0263] “Siteras Transaction Message” (STM)

[0264] A message between a browser and a server conforms to standard HTML format. This message is used to transmit transaction data between a server and the browser. Unlike a typical HTML message, it uses JavaScript syntax to encapsulate transaction data.

Detailed Description—JView

[0265] The JView™ subsystem is an object-oriented system that consists of a modular set of JavaScript, CSS and graphic files. The JView™ subsystem runs within browsers that support ECMAScript 1.0 (i.e., JavaScript).

[0266] This section contains detailed process and component descriptions related to the JView™ subsystem, and discusses concepts and technologies known in the computer field such as:

• • [0267] Object-oriented design and programming
  • [0268] Basic Internet Fundamentals (browser/server interaction, HTTP requests/responses, TCP/IP basics, etc.)
  • [0269] HTML
  • [0270] CSS
  • [0271] JavaScript
  • [0272] W3C Document Model (DOM)

[0273] JView™ Subsystem Files

[0274] The files that make up the JView™ subsystem can be divided into the following categories—Core, Business Classes, Images, Core Display Components, Display Components, Domain Components, Views/Forms, Logos, and Application Query Components.

[0275] Core Files

[0276] These files perform the generic services of the JView™ subsystem used by all application interactions. These files are a small subset of the overall application system. Since these files are reloaded by the by the browser with each interaction, it is important to minimize the total size and number of the files in this set. The following table describes the files included in this category.

[0277]

	File	Description/Functions
	jv_main_000.js	JView ™ Main.
		Contains the class definitions
		needed for initialization.
		Controls the load sequence for
		the remaining files in the Core.
		Contains common JavaScript
		functions (service functions) that
		are used by the entire
		JView ™ system.
	jv_jvmgr_000.js	JView ™ Manager.
		Contains the JVMGR class definition.
	jv_jvbase_000.js	Base Classes.
		Contains the abstract class
		hierarchy used to represent the
		data (objects) received from the
		server in the STM. These classes
		are subclassed by the business
		classes (described later).
	jv_jvdisp_000.js	Display Classes.
		Contains the abstract class
		hierarchy used for any UI elements
		that are displayed in the
		browser. These classes are
		subclassed by the display
		components (described later).
	jv_JView_000.js	JView ™ Display Class.
		Contains the JVIEW ™ class
		definition.
	jv_stm_000.js	STM Classes.
		Contains the class definitions
		that are used to represent the
		major components of the STM
		received from the server.
	jv_dommgr_000.js	Domain Manager.
		Contains the JVDOMAINMGR
		class definition.
	jv_global_000.js	JView ™ Globals.
		Contains global constants used
		throughout the entire JView ™
		subsystem.
	style.css	Cascading Style Sheet (CSS)
		Definitions.
		Contains all the CSS definitions
		used throughout the JView ™
		subsystem. This file ensures that
		the “look and feel” of all UI
		elements are consistent.

[0278] Business Classes

[0279] For each vertical application, the business classes represent the business objects used within that vertical application. One file is defined per business object. These definitions relate directly to the business object definitions (classes) that are implemented on the server (as defined in the application repository or data model).

[0280] Views/Forms

[0281] With each interaction from the server, the JView™ subsystem will display either a “view” or a “form” in the data area portion of the overall JView™ subsystem UI framework. A view is used to display a collection or list of multiple business items (usually in a summary format). A form is used to display a single business item (usually in a detail format). For example, a “view” could be used to display a list of “orders”; a “form” would be used to display the details for a specific order from that list.

[0282] For each vertical application, one or more views and forms are defined. The entire collection of views and forms for any given application represents the complete set of UI interactions for that application. A complex application system typically consists of hundreds of views and forms.

[0283] Core Display Components

[0284] These files are used to define abstract display classes from which other application specific display components can be subclassed. In doing so, all the application components inherit their common capabilities from the core display classes. This allows the JView™ subsystem to maintain UI consistency within a given application. The following table describes the files included in this category.

[0285]

File	Description/Functions
jvd_Table_000.js	Table Component
	Contains the JVDTable abstract
	class definition. This class
	is subclassed by other application
	specific display components to
	define an application specific
	table within a view or a form.
jvd_Pane_000.js	Pane Component
	Contains the JVDPane abstract
	class definition. This class
	is subclassed by other application
	specific display components to
	define an application specific pane
	within a form.
jvd_GroupBox_000.js	GroupBox Component
	Contains the JVDGroupBox abstract
	class definition. This class is
	subclassed by other application
	specific display components to
	define an application specific
	group box within a form.
jv_jvField_000.js	JView ™ Field Component.
	Contains the JVField class
	definition. This class is used to
	display a single business data
	element within a form.
jv_jvComplexField_000.js	JView ™ Complex Field Component
	Contains the JVComplexField
	class definition. This class is
	used to display a complex
	arrangement of multiple
	business data elements within
	a form.
jvd_Domain_000.js	Domain Selection Component.
	Contains the JVDomainComponent
	class definition. This class
	is used when displaying multiple
	values from a domain to the
	user on a form.
jv_jvquery_000.js	JVQuery Component
	Contains the JVQUERY abstract
	class definition. This
	class is subclassed by the
	query components (described
	later).

[0286] Display Components

[0287] For each vertical application, one or more display components are defined that contain the application specific data elements that are to be displayed to the user on a view or a form. In order to maintain a high degree of UI consistency within the overall application, each display component is subclassed from one of the core display components.

[0288] Query Components

[0289] A “View” is typically defined to display a list of homogeneous items in a summary format (e.g., a table). In many cases, the items in the list all share one or more common characteristics—for example, a list of orders awaiting shipment, a list of customers that are “active”, and a list of open accounts, etc. In many cases, users will want to filter the list from a larger list to a smaller list.

[0290] For each vertical application, one or more query components are defined that allow the user to filter the items that are displayed in a given view. As such, for each view that is defined, one or more query components will be defined. The query component is used to limit the filter/query operations that can be performed against a specific view.

[0291] Domain Components

[0292] When entering data for a specific business data element, it is often required that the value being entered belong to a predefined list of values (i.e., exist within a domain).

[0293] For example, a domain for “gender” could contain the values “M” and “F”. For each vertical application, one or more domain components can be defined. Each component defines the list of values that make up that specific application domain. Once defined, the JView™ subsystem can then use these lists to facilitate data entry (by display lists of values that can be selected from) and for validation.

[0294] Images

[0295] The files in this category represent any generic graphics files that are used throughout the JView™ subsystem and not specific to any given vertical application or client.

Logos

[0296] The files in this category represent any application or customer specific graphics files that are used within a given vertical application.

JView™ Subsystem Classes

[0297] The classes that make up the JView™ subsystem can be divided into the following categories—Core, STM, Base, and Display.

[0298] Core Classes

[0299] The Core classes represent those classes that perform generic functions and services used by the entire JView™ subsystem. The following table describes the classes included in this category.

[0300]

	Class	Description/Functions
	JVMgr	JView ™ Manager
		Main class, anchor point, used to control
		main flow within the JView ™ subsystem
		for each interaction.
		Control point for all requests submitted
		to the server.
	JVTraceMgr	Trace Manager.
		Controls and manages the internal trace
		table used for debugging.
	JVLoadMgr	Loaded File Manager.
		Controls and manages the JavaScript
		“include” files that are to be
		dynamically loaded after each interaction
		with the server.
		Ensures that the same JavaScript file is
		not being loaded multiple times.
	JVDomainMgr	Domain Manager
		Controls and manages any static and dynamic
		application domains that are being used for
		the current interaction.

[0301] STM Classes

[0302] The STM classes are used to represent the major components of the STM received from the server. The following table describes the classes included in this category.

[0303]

Class	Description/Functions
STM	STM Message - Overall
	This class is a container class that references
	all the other objects that make up the overall STM.
STMHdr	STM Header
	Contains the STM Header attributes (described
	later).
STMNB	STM NavBar
	Contains the STM NavBar data structures
	(described later).
STMMsg	STM Application Messages
	Contains the any application message data
	structures from the server (described later).
STMFnList	STM Function List
	Contains the list of valid application functions
	that can be performed by this user for this
	interaction (described later). This is an array
	of STMFunction objects.
STMFunction	STM Function
	Contains the attributes for an application
	function contained within the STMFnList.

[0304] Base Classes

[0305] The Base classes represent the abstract class hierarchy that is used to represent the data and structure of the business information received from the server in the STM. The following table describes the classes included in this category.

[0306]

	Class	Description/Functions
	JVBase	Base Object Class
		This abstract class contains the attributes
		that are common to all other JView ™ base
		objects. All other JView ™ Base classes are
		subclassed from this class.
	JVList	List Class
		This abstract class is used to represent an
		array of other base objects (i.e., either
		an array of JVBObjects or JVGAttr objects).
	JVBObject	Business Object Class
		This abstract class is used to represent a
		single instance of a business object. All
		business class files are subclassed from
		this class.
	JVBoolean	Boolean Attribute Class
		This class is used to represent a single
		Boolean data element (attribute) within a
		business object (JVBObject).
	JVString	String Attribute Class
		This class is used to represent a single
		string/character data element (attribute)
		within a business object (JVBObject).
	JVDateTime	DateTime Attribute Class
		This class is used to represent a single
		date time data element (attribute) within
		a business object (JVBObject).
	JVInteger	Integer Attribute Class
		This class is used to represent a single
		integer numeric data element (attribute)
		within a business object (JVBObject).
	JVFloat	Float Attribute Class
		This class is used to represent a single
		floating point numeric data element
		(attribute) within a business object
		(JVBObject).
	JVMemo	Memo Attribute Class
		This class is used to represent a single
		memo data element (attribute) within a
		business object (JVBObject). A memo data
		element is like a string data element, but
		the memo data element allows for special
		characters.
	JVGAttr	Generic Attribute Class
		This class is used to represent a generic
		data element (attribute) within a business
		object (JVBObject). In this case, the
		interpretation of the data contained within
		this attribute is dependent on the containing
		component class.

[0307] Display Classes

[0308] The Display classes represent the abstract class hierarchy that is used by the display components to define and control the UI. The following table describes the classes included in this category.

[0309]

Class	Description/Functions
JVDisplay	Display Object Class
	This abstract class contains the attributes
	that are common to all other JView ™
	display objects. All other JView ™
	Display classes are subclassed from
	this class.
JView ™	JView ™ Class
	This class is used to represent the
	current view or form object for the
	current interaction. It serves as the
	anchor point for the display object
	component hierarchy.
JVQuery	Query Component Class
	This class is used to represent the
	current query component (if defined)
	for the current interaction. The appli-
	cation specific query component defini-
	tion will create an instance of this
	class to contain the specific data
	elements and values used to control
	querying/filtering operations.
JVDTable	Table Component Class
	This abstract class is used to define
	a table component within the UI. It
	provides generic services common to
	all tables. Any application specific
	table components will be subclassed
	from this class.
JVDPane	Pane Component Class
	This abstract class is used to define
	a pane component within the UI. It
	provides generic services common to
	all panes. Any application specific
	pane components will be subclassed
	from this class.
JVDGroupBox	GroupBox Component Class
	This abstract class is used to define
	a groupbox component within the UI. It
	provides generic services common to all
	groupboxes. Any application specific
	groupbox components will be subclassed
	from this class.
JVDDomainComponent	Domain Component Class
	This class is used to represent an
	application domain (if defined) for the
	current interaction. For each interaction,
	multiple domain definitions can be used
	and in this case, one instance of this
	class will be created for each domain.
	The application specific domain component
	definition will create an instance of
	this class to contain the specific data
	elements and values used to control
	domain search, retrieval, and validation
	operations.
JVField	Field Component Class
	This class is used to define a field
	component within the UI. It provides
	generic services common to all fields.
JVComplexField	Complex Field Component Class
	This class is used to define a complex
	field component within the UI. It
	provides generic services common to
	all complex fields.

STM Format and Structure
The “Siteras Transaction Message” (STM) is a hierarchical structure of key value pairs that are specifically designed to hold business data, in raw format, being transmitted between a server and a browser. It is similar in structure, capability, and purpose to other data encoding mechanisms (e.g., XML, PList, etc.). This format allows the JView™ subsystem to achieve high performance and broad browser compatibility. The STM contains the following logical subsets of data—Header, Nav Bar, Business Objects, Function List, Messages, and Domains.

[0310] Header

[0311] This section contains data elements that are used to maintain the state of the JView™ subsystem environment and coordinate the execution of a transaction between the server and the JView™ subsystem executing in the browser.

[0312] Nav Bar

[0313] This section contains the data structures that are used by the JView™ subsystem to construct the NavBar within the UI. The NavBar provides the user with a hierarchical menuing system for accessing the functions within the application system.

[0314] Business Objects

[0315] This section contains the business objects (business data) related to the application function being executed. Within the STM, these business objects exist in their primitive object format. Using these business objects, the JView™ subsystem provides a user friendly presentation (i.e., generates the HTML displayed in the browser) based on the definition of the application specific view or form (JView™ subsystem object) contained in each interaction.

[0316] Function List

[0317] This section contains an array of the application functions that the user is allowed to perform. This list allows the system to enforce a first layer of security.

[0318] Messages

[0319] This section contains an array of any application messages that were generated as a result of executing the last application function. These messages may be informational, warnings, or errors.

[0320] Domains

[0321] This section contains an array of dynamic domain definitions that have been sent from the server (where the content of the values within the domain are dynamically determined by application conditions with each function). Static domain definitions, where the values within the domain do not change, are provided via Domain Components (i.e., JavaScript files). However, these static domain definitions are not transmitted within the STM.

[0322] STM HTML Message Format

[0323] Upon receiving the HTTP response from the server, the browser will perform its normal functions related to processing an HTML message. When initially received by the browser, the STM is encoded within a standard HTML stream. A sample message is contained in Diagram 1. The following table summarizes the major parts of this message (the line number references relate to the sample message in Diagram 1).

[0324]

Line(s)	Description
1-4	Standard HTML tags. These tags declare the
	stream as an HTML stream. The overall HTML
	stream is declared in lines 1-219.
	The HTML HEAD portion (containing the STM)
	is declared in lines 3-207. The HTML BODY
	portion is declared in lines 209-218.
5	Cascading Style Sheet inclusion.
6	Include the main JView ™ JavaScript file.
	This statement causes the entire JView ™
	Core to be loaded.
7	Include JView ™ view or form definition.
	This statement provides the definition for
	the application specific form or view that
	will be displayed within the JView ™ UI
	framework. This statement will also cause
	all the related application class definitions
	to be loaded.
8	If a “view” is being displayed, this
	line provides the definition for the
	application specific query component to be
	used with the view.
10-206	STM
	The full STM encapsulated in JavaScript
	functions.
13-48	Header
	The Header portion of the STM.
50-59	NavBar
	The NavBar portion of the STM. In this example,
	the Nav Bar contains 6 distinct navigation
	items on lines 52, 53, 54, 55, 56, and 57.
61-143	Business Objects
	The Business Object portion of the STM. In this
	example, there are two instances of business
	objects contained in this section. Both business
	objects are SAFolder_Subro objects. The first
	instance is defined by lines 62-101, the
	second instance is defined by lines 102-142.
145-162	Function List
	The Function List portion of the STM. In this
	example, the function list contains two distinct
	Function entries on lines 147-153 and 154-160.
164-169	Messages
	The Message portion of the STM. In this example,
	two distinct application messages are defined on
	lines 166 and 167.
171-200	Domains
	The Domains portion of the STM. In this
	example, a single application domain named
	“RespondingCompanies” is defined
	containing 4 domain items.
209-218	HTML BODY
	These lines represent the HTML BODY
	declaration. In most standard HTML streams,
	this section will contain a large number of
	definitions that define the UI formatting to
	be performed by the browser. With the JView ™
	subsystem this section is virtually empty. On
	line 209, the “ONLOAD=” parameter
	causes the browser to invoke the JView ™
	Manager to complete the JView ™ initialization
	and generate the HTML to be displayed in the
	browser for this interaction.

[0325] JavaScript STM Functions

[0326] Within the HTML stream described above, JavaScript functions are used to encapsulate the business data. Using these functions, any business data structure, simple or complex, can be defined. For the STM portion of the message, the following JavaScript functions are used:

[0327]

Single Objects
	NS(<classId>,<objectId>,<instanceName>)
	NE( )

[0328] These functions are used to define a single object node. The NS( ) function is used to start the declaration of the object and the NE( ) function is used to end the declaration. A single object node can contain other single objects, array nodes, or attribute nodes. When defining the object node, the <class> specifies the type of object to be instantiated, the <objectId> is its unique object identifier, and the <instanceName> is the name by which the parent object (if any) refers to this object.

[0329]

Object Arrays
	RS(<instanceName>)
	RE( )

[0330] These functions are used to define an array node. Essentially, this type of node is used to define a collection of objects of the same type/class. The RS( ) function is used to start the declaration of the array and the RE( ) function is used to end the declaration. An array node can contain any number of single object (NS) or generic attribute (GA) nodes. When defining the array node, the <instanceName> is the name by which the parent object (if any) refers to this array.

[0331]

Attributes
	AB(<attributeId>, <value>)
	AD(<attributeId>, <value>)
	AF(<attributeId>, <value>)
	AI(<attributeId>, <value>)
	AM(<attributeId>, <value>)
	AS(<attributeId>, <value>)

[0332] These functions are used to define a single attribute node (data element) within an object (NS). The different function names related to the primitive type of the data represented by the attribute—Boolean (AB), DateTime (AD), Numeric-Floating Point (AF), Numeric-Integer (AI), Memo (AM), and String (AS). When defining an attribute node, the <attributeId> is the name by which the parent object refers to this attributed, and the <value> is the data value of the attribute.

[0333]

Generic Attributes
	GA(<attributeType>, <value1>, <value2>, ..., <valuen>)

[0334] These functions are used to define a single generic attribute node (complex data element) within an array (RS). This attribute can only be used within an array node. It is a special type of complex attribute and the interpretation of the attribute type and values is left to the parent object.

[0335] Full Mode vs. Raw Mode Format

[0336] In the message example above, the “full mode” format is used. In this format, the classIds and attributeIds are expressed as full character strings. A “raw mode” format is also used that further reduces the overall message size by replacing the character string representations of the classIds and attributeIds with numeric codes. Additionally, raw mode can use either the JavaScript function method of data encapsulation or the JavaScript array syntax. The JavaScript array method is preferred for production as this eliminates any overhead associated with the execution of the data encapsulation functions themselves. Using this method, all data encoding rules conform to those defined by JavaScript syntax.

[0337] The following summarizes various STM formats:

[0338] STM Full Mode

[0339]

	NS(“STMHdr”,null,“oHdr”);
	AB(“readOnly”,0);
	AD(“dateCreated”,“20000531105702”);
	AF(“amtTotal”,17.43);
	AI(“count”,4);
	AM(“comments”,“This is line 1\nThis is line2\n”);
	AS(“companyName”,“Insurance Property & Casualty”);
	NE( );

[0340] STM Raw Mode (Using JavaScript Function Encapsulation)

[0341]

	NS(1,null,1);
	AB(1,0);
	AD(3,“20000531105702”);
	AF(4,17.43);
	AI(8,4);
	AM(2,“This is line 1\nThis is line2\n”);
	AS(7,“Insurance Property & Casualty”);
	NE( );

[0342] STM Raw Mode (Using JavaScript Array Encapsulation)

[0343]

	STMHdr =
	[[1,null,1],
	[1,1,0],
	[2,3,“20000531105702”],
	[3,4,17.43],
	[4,8,4],
	[5,2,“This is line 1\nThis is line2\n”);],
	[6,7, “Insurance Property & Casualty”);]
	];

STM Object Format

[0344] The processing of the STM message results in the creation of the STM object within the browser environment. The structure of this object is depicted in FIG. 21.

JView™ Subsystem Object Hierarchies

[0345] During the initialization of the JView™ subsystem environment, two main object hierarchies are constructed—the Base Object Hierarchy and the Display Object Hierarchy.

[0346] Base Object Component Hierarchy

[0347] The base object hierarchy consists of the base objects (derived from JVBase) that were created as a result of processing the STM (as depicted within Diagram 1). This hierarchy is anchored within a global variable “goSTM” that can be accessed at any time by any part of the system. All business objects related to the application function are contained in the subtree goSTM.oData. This subtree is an array (RS) that can contain 0-n business object subtrees. For a View, it will contain 0-n business object subtrees. For a form, it will only contain a single business object subtree.

[0348] Display Object Component Hierarchy

[0349] The display object hierarchy consists of display objects (derived from JVDisplay) that were created as a result of processing the JView™ Subsystem View/Form component associated with this interaction (as defined in line 7 of the sample message in Diagram 1). This hierarchy is anchored within an instance variable of the JView™ Subsystem Manager “oJView” (the JView™ Subsystem Manager Object instance is in turn anchored with a global variable “goJM”). The display objects are used to hold instance and state data related to the UI and to some extent mirror the DOM objects that are created from the generated HTML. This hierarchy is necessary because certain local operations (e.g., resorting a table) are used to completely refresh portions of the DOM—in this case, the display object contains the data needed to regenerate the DOM objects.

JView™ Subsystem Processing The three distinct phases to the JView™ subsystem operation are described in detail in the following sections.

• • [0350] Initialization
  • [0351] Interaction
  • [0352] Request Submission

[0353] JView™ Subsystem Initialization

[0354] With each HTTP response received from the server, the JView™ subsystem environment within the browser is completely rebuilt. Because of this, the system was designed modularly in order to minimize any delays associated with this initialization. Some browser platforms allow for data to persist across interactions (e.g., cookies, IE behaviors, etc.)—other than the normal browser caching mechanisms (i.e., used for HTML pages, graphics, CSS, and Javascript files), the JView™ subsystem does not rely on any browser specific mechanisms for caching data across server interactions.

[0355] Browser Initialization

[0356] Upon receipt of a new HTTP response from the server, the browser will perform any internal initialization and process the newly received HTML stream.

[0357] Core Loading and Initialization

[0358] After the browser has loaded the CSS file, the JVMain JavaScript file will be loaded and processed by the browser as follows. A series of global constants (needed for initialization) are processed first. The class definition for the Trace Manager is processed. The Trace Manager is instantiated and initializes itself. The early creation and initialization of the Trace Manager allows all other parts of the JView™ subsystem to record trace entries for debugging purposes. The Trace Manager is anchored in the global variable goJVTraceMgr so that it can be accessed by any part of the system. The class definition for the Load Manager is processed. The Load Manager is instantiated and initializes itself. The Load Manager is used to keep track of all JavaScript files (e.g., views/forms, components, classes, etc.) that have been loaded. The Load Manager is anchored in the global variable goJVLoadMgr so that it can be accessed by any part of the system.

[0359] A series of JV_Include functions are processed to load the other JavaScript files that make up the JView Core (refer to JView™ “Include” Capability for more detail). As a result the following core files will be loaded in sequence when the browser completes the processing for JVMain—JView™ Manager Class (jv_jvmgr_—000.js), JView™ Base Classes (jv_jvbase_—000.js), JView™ Display Classes (jv_jvdisp_—000.js), JView™ View/Form Class (jv_JView_—000.js), STM Classes (jv_stm_—000.js), Domain Manager Class (jv_dommgr_—000.js), and Global Constants (jv_global_—000.js). As each file is loaded, it is recorded in the Load Manager.

[0360] A series of global function definitions will then be processed. These functions provide general services that can be used by any part of the JView™ subsystem. After the processing for JVMain is complete, the browser will load and process each of the core files included above.

[0361] JView™ Subsystem Manager Creation

[0362] During the processing of the Global file (jv_globals_—000.js), the JView™ Subsystem Manager is instantiated. This object is anchored in the global variable goJM so that it can be access by any part of the system. The initialization of this object is deferred until later (see “JView™ Subsystem Manager Initialization” below).

[0363] View/Form and Application Class Loading

[0364] Once the loading of the JView™ Subsystem Core files is complete, the browser will continue processing the statements in the HTML stream from the current HTTP response. The next statement in this stream will be a <SCRIPT> tag that references the JavaScript file for the application specific View or Form. This statement causes the browser to load and process this file as follows. Additional method and attribute definitions for the JVIEW class (specific to this form) are processed. These definitions give the JVIEW class its application specific behavior for the current interaction.

[0365] A series of JV_Include functions are processed to load the other JavaScript files that are used by this form/view. There are two main groups of files that are included—Display Components and Business Classes. A JView™ subsystem form or view is built by assembling one or more display components (described below in “JView™ Subsystem UI Architecture”). The Display Component “includes” result in the loading of all display component definitions that are needed for this view/form. Within the Business Object portion of the STM, each business object requires that its application class definition exist within the JavaScript environment within the browser. The Business Class “includes” result in the loading of all business class definitions that are needed by the current STM.

[0366] After the processing for the application specific view/form is complete, the browser will load and process each of the display component and business class files included above.

[0367] Query Component Loading

[0368] Once the loading of the application view/form, display component, and business class files is complete, the browser will continue processing the statements in the HTML stream from the current HTTP response. If a view is being processed for this interaction, the next statement in this stream will be a <SCRIPT> tag that references the JavaScript file for the application specific query component. This statement causes the browser to load and process this file.

[0369] STM Processing—Base Object Hierarchy Creation and Initialization

[0370] After all the JView™ subsystem core and application specific files have been loaded, the browser will continue processing the statements in the HTML stream from the current HTTP response. The next statements in the stream are in-line JavaScript statements that represent the STM. The browser will process these statements as follows. The browser will execute each JavaScript STM function in the order it occurs within the HTML stream (e.g., NS( ), RS( ), etc).

[0371] As each function is processed, a new node (object) in the JView™ Subsystem Base Object hierarchy will be created. For NS( ) functions, an application specific object will be created (based on the classId specified in the NS( ) function). For all other STM functions the type of object created depends on the specific STM function as follows:

• • [0372] RS( )—JVList
  • [0373] AB( )—JVBoolean
  • [0374] AD( )—JVDateTime
  • [0375] AF( )—JVFloat
  • [0376] AI( )—JVInteger
  • [0377] AM( )—JVMemo
  • [0378] AS( )—JVString
  • [0379] GA( )—JVGAttr

[0380] As each node is created, JVBase initialization will be executed. This initialization sets JVBase attributes used to represent the linkage of this node within the Base Object hierarchy (i.e., parent, child, sibling, etc.). Based on the sequence of the statements in the STM, the Base Object hierarchy is created from top to bottom and left to right. As each application specific subtree is created, any application specific initialization will be executed. This initialization, if any, exists within each application business class as an Init( ) method. The application specific initialization performs any application specific data manipulations that are needed by the current interaction. After all STM JavaScript functions have been executed, the JView™ Subsystem Base Object Hierarchy is created. This object hierarchy contains all the business data, as business objects, sent from the server in response to the previous request.

[0381] JView™ Subsystem Manager Initialization

[0382] After the STM functions have been processed, the Init( ) method of the JView™ Subsystem Manager (JVMgr) will be executed. This method is triggered by the “ONLOAD=” parameter of the <BODY> tag in the current HTML stream. The following summarizes the processing performed in this method.

[0383] Initialize the Domain Manager. This initialization results in the processing and setup of any domains that were contain in the STM (in the Domains section).

[0384] Create an instance of a JVIEW object. Up to this point, only various JVIEW class definitions have been processed (both generic and application specific). At this point, the actual JVIEW object (view or form) is created. This object anchors the display hierarchy that controls the UI associated with the current interaction.

[0385] At this point, the display object hierarchy will be created and initialized. This complex process is described next. At the completion of this process, control will be returned to the JView™ Subsystem Manager and its initialization will be completed.

[0386] Display Object Hierarchy Creation and Initialization

[0387] This process results in the creation of the display objects used to generate and control the UI for the current interaction. It is trigged by invoking the Init( ) method of the JVIEW object. Within this method, the following processing is performed (for brevity, any references to “view” below imply a view or a form).

[0388] Any application specific view initialization is performed by invoking the InitView( ) method for the JVIEW object. This method allows the view to perform any application specific processing prior to generating and displaying the HTML. Such initialization includes initializing the component variables that contain references to any display components created later, initializing other variables based on data conditions within the base hierarchy, sorting business data within the base hierarchy, etc.

[0389] Once the view is initialized, the display components are created and the HTML is generated in a single process. This process is triggered by invoking the CreateHTML( ) method of the JVIEW object. Prior to invoking this method, an array is created and passed to this method as a parameter (i.e., the HTML array). This array is used to contain all the HTML statements that are generated by all display methods and components invoked during the processing of the CreateHTML method. This method will perform the following: invoke the CreateHeader( ) method to generate the HTML for the Header portion of the UI; invoke the CreateInfoBar( ) method to generate the HTML for the Info Bar portion of the UI; invoke the CreateNavBar( ) method to generate the HTML for the NavBar portion of the UI; if any application messages exist, invoke the CreateMsgArea( ) method to generate the Message Area portion of the UI; for a form, invoke the CreateActionBar( ) method to generate the HTML for the Workflow Bar portion of the UI; and invoke the CreateDataArea( ) method to create/initialize any display components and generate the HTML for the Data Area portion of the UI (the portion that contains application specific information). This method is defined in the application specific JView™ subsystem file for the current interaction. It will either 1) generate HTML directly, 2) create any child display components that make up the UI for this view, or 3) use a combination of both techniques.

[0390] For each display component created, the following processing will occur. The display object for this component will be instantiated and linked into the display hierarchy. Any initialization of the component will occur within the constructor of the class for this display object. The CreatePreHTML( ) method will be invoked for the newly created display object. This method provides for container-oriented HTML generation by any of the super classes for this object. The CreateHTML( ) method will be invoked for the newly created display object. Similar to the above, this method will result in the generation of any application specific HTML for this component. To do so, it will either 1) generate HTML directly, 2) create any child display components that make up the UI for this view, or 3) use a combination of both techniques. This process allows for orderly nesting and creation of display components anchored off of the initial JVIEW object. This process supports the construction of a simple or complex UI. The CreatePostHTML method will be invoked for the newly created display object. This method provides for container-oriented HTML generation by any of the super classes for this object.

[0391] After the CreateDataArea( ) method completes, some final special HTML tags are generated. An HTML FORM is created—JVFORM_STM. For JView™ subsystem forms that support the uploading of files from the local environment, a standard browser file widget (STMFILE) is created within this HTML FORM (<INPUT TYPE=“file” . . . >). Finally, a special hidden field (STMDATA) is also defined within this HTML FORM (<INPUT TYPE=“hidden” . . . >)—this field is used to contain the outbound STM stream for any subsequent request to the server.

[0392] Upon completion of the main CreateHTML( ) method for the JVIEW object, the HTML stream will be prepared and the DOM object within the browser for the BODY portion of the current Document will be updated with the new HTML (this process is described further in “HTML Generation” below). At this point, the UI “focus” will be set (based on the definition within the JView™ subsystem of the first field that is to receive the input focus), and control will be returned back to the JView™ Subsystem Manager.

[0393] JView™ Subsystem Manager Initialization (Continued)

[0394] After the UI has been created, the JView™ Subsystem Manager will complete its initialization by performing its response time calculations. At this point, control will be returned to the browser and UI control is returned to the user.

[0395] JView™ Subsystem Interaction

[0396] Once control has been returned to the user, the JView™ subsystem environment allows the user to operate locally (without interaction from the server). To do so, the JView™ subsystem relies on the Dynamic HTML mechanism within the browser to perform interaction related services. These services include the following:

• • [0397] Dynamic Sorting
  • [0398] Data Formatting and Display
  • [0399] Expanding/Collapsing Portions of the UI (e.g., Panes).
  • [0400] Print Formatting and Preview
  • [0401] Hierarchical Menuing
  • [0402] Syntactical Editing and Validation
  • [0403] Complex Application Validation
  • [0404] Application Calculations

[0405] The HTML that was initially generated contains the definitions that allow for the triggering of specific methods within the JView™ subsystem display objects in response to any Dynamic HTML events generated by the browser in response to various user interactions.

[0406] One key aspect of this local interaction relates to data entry. For any data entered by the user, the JView™ subsystem environment will perform syntactical validation (e.g., ensure valid numbers, dates, etc.) and invoke any application specific validation defined within the business classes. Once these validations have been performed successfully, the specific base object affected by this data (within the base object hierarchy) will be modified with the new data. As such, as the user interacts with the UI, the base object hierarchy is dynamically updated to reflect the current state of the data. The importance of this will be clear later when describing request submission to the server.

[0407] For more information on these services, refer to the “JView™ Subsystem Services”.

[0408] JView™ Subsystem Request Submission

[0409] The user will continue to operate locally within the browser environment until they select a UI element that triggers a new request to the server. Within the JView™ subsystem environment, all such requests are processed and generated from a central point within the JView™ subsystem environment—namely the JView™ Subsystem Manager. The following summarizes the request submission process.

[0410] For any UI elements that will trigger a request to the server, the generate HTML will ensure that the element results in a call to the InvokeFunction( ) method within the JView™ Subsystem Manager (JVMgr).

[0411] The InvokeFunction( ) method will perform parameter validation and then invoke the JVMgr.SubmitHostRequest( ) method.

[0412] The SubmitHostRequest( ) method will perform the following: save the current NavBar state (i.e., which menu levels are open/closed) within an instance variable in the STM Header; update other STM Header variables with data values specific to the new request (e.g., functionName, chainType, objectId, transactionParms, OLS command, qualifier, and other JView™ subsystem environment context variables); and construct the outgoing STM stream for the request by traversing the base object hierarchy for the Header and Business Object subtrees and creating a single text stream (whose format is identical to the inbound STM format depicted in Diagram 1).

[0413] In fact, the specific format used depends on the server and can be any serial syntax that can represent hierarchical structure of key:value pairs (e.g., STM, XML, PList, etc.). The resulting stream is then stored in the special form variable (STMDATA), that was created when the HTML was initially generated (refer to 2 g in the “Display Object Hierarchy Creation and Initialization” section above).

[0414] Based on the type of request (non-editing or editing), the request is submitted to the host in one of two ways. For non-editing requests (i.e., requests that do not result in data modification on the server), the HTML FORM JVFORM_STM is “submitted” with METHOD=GET. For editing requests (i.e., requests that result in data modification on the server), the HTML FORM JVFORM_STM is “submitted” with METHOD=POST.

[0415] After submitting the request to the server, control is returned to the browser to await the response to the newly issued request.

JView™ Subsystem Services

[0416] Within the overall JView™ subsystem processing described above, specific services are performed. This section details the operation of these specific services.

[0417] JView™ Subsystem “Include” Capability

[0418] The JView™ subsystem “include” capability was intended to insulate the server from the specific manner in which the JView™ Subsystem Core was modularized. This allows the server to merely specify a single JView™ subsystem file (i.e., jv_main_—000.js) in its HTTP response stream. Within that file, other files are subsequently “included” so as to complete the loading of the JView™ Subsystem Core. This approach allows the JView™ Subsystem Core to be divided in any manner or extended without requiring any change on the server.

[0419] The standard browser environment does not provide for a generic mechanism to “include” JavaScript files. As such, the following process is used.

[0420] Within the <HEAD> section of the HTML stream for a given HTTP response stream, a reference to an initial main JavaScript file using an HTML <SCRIPT SRC= . . . > tag is defined. The browser will load the JavaScript file referenced by this tag from its local cache, or from the server. Once loaded, the browser will start processing the statements defined in this file. These statements can either be JavaScript definitions or executable statements.

[0421] To “include” another JavaScript file, a series of executable JavaScript statements are contained within the main JavaScript file that perform the following: construct a string variable that contains a new HTML <SCRIPT> tag for the JavaScript file to be included; and perform a document.write function specifying this new string variable. This function will result in the new HTML statement being written to the current HTML stream being processed (ahead of any HTML statements that are being sent from the server).

[0422] Once the browser completes the processing of the main JavaScript file, it will then process any newly inserted HTML statements that were dynamically created by executing the JavaScript code in the main file—thereby resulting in the loading of the additional JavaScript files.

[0423] Essentially, the processing is the same as if the server had included the additional JavaScript files in its original HTML stream

[0424] Trace Management

[0425] Within the JView™ subsystem environment, the Trace Manager maintains trace information that is useful for debugging purposes. The following process is used to manage trace information. Upon initialization, the Trace Manager will allocate an array (with a fixed number of entries) for trace data. The Trace Manager is anchored in a global variable goJVTraceMgr. Whenever the Trace Manager method AddTraceEntry( ) is called, the Trace Manager will add the new trace entry to its internal trace table. When the trace table becomes full, the trace manager will wrap around to the start and replace the oldest trace entry with the newest trace entry. Other Trace Manager methods are available for displaying the trace table.

[0426] JView™ Subsystem Initialization Optimization

[0427] Due to the fact that the JView™ subsystem environment must be completely reconstructed by the browser, it is essential to keep the processing overhead related to initialization to a minimum.

[0428] One mechanism used to reduce initialization time was to modularize the JView™ subsystem into a number of distinct files. This approach had a number of distinct advantages. Relative to the combined file sizes of the entire application system, the JView™ Subsystem Core files represent a small subset (15% or less). Once a JView™ subsystem file is downloaded from the server, it will be placed in the browsers local cache—unless that file changes, any subsequent references to it will be satisfied from the browsers local cache (rather than retrieving it from the server). The overall modularization of the system minimizes the number of files that are needed for each application interaction. Even though the overall application system may comprise thousands of views, forms, reports, and related components, a user will only need to download those files that are needed for the current interaction. As such, the JView™ subsystem avoids long “initialization” delays associated with the loading of a monolithic system (e.g., Java application, Java applets, etc.). Because of the extensive modularization, if a JView™ subsystem file does change, only the new JView™ subsystem file needs to be downloaded, not the entire system.

[0429] State and Context Management

[0430] Upon each interaction with the server, the JView™ subsystem environment running within the browser is completely refreshed (reinitialized). Since the system does not rely on, or use, any browser provided persistence mechanisms for recording state (e.g., cookies, IE behaviors, etc.), the Header section of the STM is used to store any context information from the JView subsystem environment. When a new request is submitted to the server, the JView™ subsystem environment will store information related to its current “context” within the STM header. This information will be passed to the server. In response to the request, the server will return this context information, unaltered, back to the JView™ subsystem environment within the same STM header variable. The JView™ subsystem environment will then use this context information to re-establish the context it had when it submitted the original request.

[0431] Function Security

[0432] In order to eliminate the proliferation of user specific forms, views, and reports (views), the JView™ subsystem allows these views to be created in a way that is not user specific. However, because these views can be used by multiple users, they often need to contain embedded links to other application functions. In this case, not all users will be authorized to perform all functions.

[0433] The function security architecture within the JView™ subsystem provides a mechanism to ensure that a given user can only access the functions for which they are authorized. The following summarizes the operation of this mechanism. The FunctionList portion of the STM defines a complete set of functions for which the current operator is authorized. During the creation and initialization of a JView™ subsystem form/view, any embedded links to application functions on the server are all defined using the JVIEW.CreateEmbeddedLink( ) method. As the form is being created this method will be invoked for each link defined on the form/view. Using the FunctionList, the CreateEmbeddedLink( ) method will validate that the current user is authorized to access the application function associated with this link. If not, the link will be disabled or hidden (based on the parameters passed to this method).

[0434] JView™ Subsystem UI Architecture

[0435] The JView Subsystem UI architecture is based on a component model. These components are organized around the JView™ Subsystem UI framework. The JView™ subsystem framework provides a consistent application workspace for the user. Since all the parts of the framework are themselves components, this framework can be easily modified and extended to be compatible with a large number of application systems. The JView™ subsystem framework consists of the following major components.

[0436] Header Area—general area for providing “branding” information for the company using the system and the vendor.

[0437] Info Bar—general information area displaying information about the current task and user.

[0438] Nav Bar—this area provides access to the specific functions within the application in the form of a hierarchical menuing system.

[0439] Message Area—an area for displaying application specific messages.

[0440] Workflow Bar—For forms, this area is used to display one or more action buttons that are used to perform common application functions that affect the workflow of the specific business document being displayed.

[0441] Command Area—For views and forms, this area is used to display one or more links that are used to perform secondary application functions related to the specific business document being displayed.

[0442] Data Area—For views, this area is used to display application specific information, usually in tabular form related to multiple business transactions or documents. For forms, this area is used to display application specific information related to a single business transaction or document.

[0443] Within the Data Area of a view or form, one or more additional display components can be defined (e.g., tables, panes, groupboxes, etc.).

[0444] FIG. 23 contains an example of a JView™ subsystem “view”. FIG. 24 contains an example of a JView™ subsystem “form”.

[0445] The component based nature of the JView™ Subsystem UI architecture allows a given application component to be defined once and then be reused across multiple views or forms.

[0446] HTML Generation

[0447] Due to the extensive amount of HTML generation performed within the JView™ subsystem environment, the performance of this aspect of the system has a major impact on the responsiveness of the system. When the JView™ subsystem was developed, the HTML generation techniques that were documented within the industry did not perform adequately enough for use in a production class system. For large HTML streams (150 KB or more), these techniques often took 30 seconds or more (on a Pentium III class processor). As such, the JView™ subsystem uses a special algorithm, disclosed herein, that has demonstrated the capability of generating a large HTML stream (150 KB) in less than 500 milliseconds on a Pentium III class processor.

[0448] Diagram 2 contains a code section that illustrates the HTML generation technique used within the JView™ subsystem. The following table summarizes this technique (the line number references relate to the code section in Diagram 2).

[0449]

Line(s)	Description
1	Declaration for a standard JavaScript array. Each
	element in this array will be used to hold an HTML
	code generation fragment.
2	Declaration for a standard JavaScript variable.
	This variable will later be used to hold the entire
	HTML stream that is being generated.
4-7	HTML code generation statements. Each HTML fragment
	being generated is assigned to a new element within
	the HTML array.
9	Using the standard JavaScript “join” method
	(for Array objects), the complete HTML stream is
	generated by concatenating all the individual array
	elements together in one atomic operation.
10	Once the full HTML stream is generated, the DOM
	within the browser is updated with a single atomic
	operation that completely replaces the HTML for
	the document BODY (using the outerHTML property).

[0450] Sorting

[0451] Due to the high “data” bandwidth capability inherent in the JView™ subsystem architecture, a JView™ subsystem “view” is able to efficiently display a large number of result rows for any given business query—500 to 1000 (compared to the 20-25 displayed by most search engines). Once this result set is returned to the JView™ subsystem environment, users will typically want to resort the result rows based on various columns.

[0452] Within JavaScript, a primitive sort method is provided for Array objects. This sort method relies on the existence of a “compare” function that can compare any two elements within an array and pass a return code indicating whether one element was greater than, less than, or equal to the other element.

[0453] Within the Business Object portion of the base hierarchy, an Array is used to store the full set of Business Objects for the current interaction. However, since these objects are arbitrarily complex, it is not practical to statically code a “compare” function. Additionally, even though JavaScript provides an “eval( )” function that can be used within a generic compare function to evaluate arbitrary business objects, this function is performance intensive. As such, the use of this function for sorting large results sets was not practical.

[0454] To overcome this limitation and provide a robust sorting capability for both single and multicolumn sorting, the following technique is used within the JView™ subsystem: when a view is initialized, a compare function is dynamically code generated for each column within the view; for each compare function generated, the “eval( )” function is invoked once to essentially compile this function into internal JavaScript format; and when the view needs to be sorted, the system determines the column(s) being sorted and then passes the compiled compare function to the sort method for the array being sorted.

[0455] Using this technique, JView™ subsystem sort times are typically less than 1 second (on a Pentium III processor) for result sets containing as many as 1000 rows.

[0456] Application Validation and Processing

[0457] Due to the rich object oriented environment established within the JView™ subsystem environment, application validation and processing is simplified. Whenever a data element within the Base Object Hierarchy is modified, the “OnUpdate( )” method is invoked for each immediate parent object in the base hierarchy (all the way to the root object—the STM). This method allows each containing object to trigger validation or processing logic based on the specific portion of their tree that was updated.

[0458] During this process, any data modifications made to the base hierarchy are automatically displayed in the UI. This occurs because of the linkages that are established between the base and display hierarchies. Namely, when a base object is updated, the JView™ system maintains a linkage to any display objects that are dependent on this base object. From these display objects, the correct DOM object (within the browser environment) can be refreshed.

[0459] Response Time Measurement

[0460] The JView™ subsystem, running in the client browser, also measures and tracks response time. The following summarizes the mechanism used for response time measurement and tracking. Whenever a request is made, the JView™ subsystem records a local timestamp (TS1) within the client browser and passes this to the server (along with the request). After processing the request, the response from the server will contain the original timestamp (TS1). Additionally, the server will provide its own host response time (HostTime) that measures the duration from when the server received the request to when the server generated the response. Upon receiving the request, the JView™ subsystem records another local timestamp (TS2). This timestamp is taken very early in the JView™ subsystem initialization process so as to accurately record the closest time to the receipt of the response.

[0461] After taking timestamp TS2, the JView™ subsystem will proceed with its initialization. After the initialization is nearly complete (just before returning browser control to the user), a final timestamp will be take TS3 and response time statistics will be calculated as follows:

• • [0462] Total End User Response Time=TS3−TS1.
  • [0463] JView™ Overhead Time=TS3−TS2
  • [0464] Host Response Time=HostTime (provided by the server)
  • [0465] Network Time=(TS3−TS1)−HostTime

[0466] These statistics are stored within the current JView™ subsystem environment (within the JView™ Subsystem Manager), and are transmitted back to the server with the next processing request. The server can then store this information within the application database. In this way, each new request to the server contains the response time statistics for the previous processing request.

[0467] This mechanism is unique in its ability to measure the actual response time experience by the end-user at their browser.

[0468] Performance Optimization

[0469] The wide array of local services available eliminate the need for the client to communicate with the server—thereby further reducing bandwidth, end-user response time, and server processing cycles.

[0470] By off-loading the above services to the client (especially the HTML generation), a substantial reduction in server processing cycles is achieved.

[0471] The JavaScript core application components used in the JView™ subsystem are extremely modular. This modularity helps to eliminate the response time delays upon initial interaction with the server that are associated with non-modular systems.

[0472] Multi-Channel Communication

[0473] Multiple browser windows are used when creating a separate communication channel with the server. This allows an end-user to issue multiple independent and parallel application processing requests with the server. The OLS maintains the state of each of these parallel communication channels so as to preserve the integrity of each request.

[0474] Within each communication channel, either structured (STM), unstructured (files), or both types of information can be communicated in either direction.

[0475] Maintaining Browser Compatibility

[0476] To maintain compatibility with the broadest set of browser-based clients, the lowest possible levels of JavaScript and HTML are used. Additionally, only the basic set of thin client services provided by the client browser is provided. The system does not use special plug-ins, Java applets, or ActiveX controls as the use of such services reduce the general applicability of the system to a wide range of environments.

Diagrams—JView

[0477] The following diagrams illustrate a number of features of the JView™ subsystem described above.

Diagram 1 shows a STM Sample Message (Full Mode) code.

Diagram 2 shows a JView™ Subsystem HTML Generation code.

Diagram 1—STM Sample Message (Full Mode)

[0478]

1.	<!DOCTYPE HTML PUBLIC “-//W3C//DTD HTML 3.2//EN”>
2.	<HTML>
3.	<HEAD>
4.	<META HTTP-EQUIV=“expires” CONTENT=“Wed, 02 Aug 2000 08:00:00 GMT”>
5.	<LINK REL=“stylesheet” TYPE=“text/css” HREF=“../jview/common/style.css”>
6.	<SCRIPT LANGUAGE=“JavaScript” SRC=“../jview/common/jv_main_000.js”></SCRIPT>
7.	<SCRIPT LANGUAGE=“JavaScript” SRC=“../jview/jviews/jv_SubroFoldersD_Summary_Full_000.js”></SCRIPT>
8.	<SCRIPT LANGUAGE=“JavaScript” SRC=“../jview/queries/jvq_SubroFoldersD_Basic_000.js”></SCRIPT>
9.
10.	<SCRIPT language=JavaScript>
11.	<!- STM Start
12.	NS(“STM”);
13.	NS(“STMHDR”,null,“oHdr”);
14.	AS(“url”,“/Scripts/WebObjects.exe/subro”);
15.	AS(“wosid”,“HvAcD1oBZTEHxTNIito9F0”);
16.	AS(“coName”,“Insurance Property & Casualty”);
17.	AS(“coLogo”,“ipc.gif”);
18.	AS(“operatorID”,“Henry HQMgr”);
19.	AS(“OLSMode”,“Normal”);
20.	AS(“woContextID”,“4”);
21.	AS(“title”,“Demand Files - All Open”);
22.	AS(“functionName”,“SubroFoldersD_OpenAll”);
23.	AS(“intrinsicId”,“_ReadManyRaw”);
24.	AS(“object”);
25.	AS(“refObject”);
26.	AS(“insertionRef”);
27.	AS(“partyType”,“D”);
28.	AS(“qualifier”);
29.	AS(“sortParams”,“[[\”toAppData.toDemand.dateDemandReceived\“,\”A\“]]”);
30.	AS(“queryParams”);
31.	AS(“chainedQualifier”);
32.	AS(“coID”,“IPC”);
33.	AS(“nbState”,“JVNB_3:1,JVNB_5:1,JVNB_0:1,JVNB_2:1”);
34.	AS(“jvContext”,“1061946572477”);
35.	AS(“responseStat”,“{JVSUBMIT:‘null‘}”);
36.	AS(“helpPath”,“../Help/_Common”);
37.	AS(“tutorialPath”,“../Tutorial/_Common”);
38.	AS(“OLSCmd”);
39.	AS(“chainType”,“Top”);
40.	AS(“stackId”,“2”);
41.	AS(“urlHome”);
42.	AS(“urlSupport”);
43.	AI(“woi”,−1);
44.	AI(“stackDepth”,1);
45.	AB(“displayCoName”,1);
46.	AB(“displayFirst”,0);
47.	AB(“displayTutorial”,0);
48.	NE( );
49.
50.	NS(“STMNB”,null,“oNB”);
51.	RS(“oActions”);
52.	GA(“NBACTION”,“/001,Demand Files/006,Open Files/008,Pending Acceptance”,“SubroFoldersD_PendingAcceptanceAll”);
53.	GA(“NBACTION”,“/001,Demand Files/006,Open Files/010,Pending Response”,“SubroFoldersD_PendingResponse”);
54.	GA(“NBACTION”,“/001,Demand Files/006,Open Files/016,Search...”,“SubroFoldersD_OpenSearchBasic”);
55.	GA(“NBACTION”,“/50,System/10,Home”,null);
56.	GA(“NBACTION”,“/50,System/20,Support”,null);
57.	GA(“NBACTION”,“/50,System/30,Logout”,“Logout”);
58.	RE( );
59.	NE( );
60.
61.	RS(“oData”);
62.	NS(“SAFolder_Subro”,1,null);
63.	AS(“stage”,“Issued”);
64.	NS(“SAFolderData_Subro”,2,“toAppData”);
65.	NS(“SAParty”,3,“toPartyD”);
66.	AB(“actionFlag”,1);
67.	AI(“alertCount”,3);
68.	NE( );
69.	NS(“SAParty”,3,“toPartyR”);
70.	NS(“SACompany”,4,“toCompany”);
71.	AS(“companyName”,“Allstate Insurance Company” );
72.	AS(“companyId”,“Allstate” );
73.	NE( );
74.	NE( );
75.	NS(“SA_Demand”,5,“toDemand”);
76.	AD(“dateDemandIssued”,“20030507000000”);
77.	AF(“pctRecovery”);
78.	NS(“SA_DemandClaimDetail”, 6, “toClaimDetailD” );
79.	AS(“claimNumber”,“34-000224”);
80.	NE( );
81.	NS(“SA_DemandClaimDetail”, 7, “toClaimDetailR” );
82.	AS(“claimNumber”,“175-00224”);
83.	NE( );
84.	NS(“SA_DemandNeg”, 8, “toCurrentNeg” );
85.	NS(“SA_DemandNegDetail”, 9, “toCurrentProposalD” )
86.	AF(“amtPaymentTotal”,2203.61);
87.	AF(“amtDemandTotal”,2203.61);
88.	NE( );
89.	NS(“SA_DemandNegDetail”, 9, “toCurrentProposalR” )
90.	NE( );
91.	NE( );
92.	NE( );
93.	NS(“SATask_Subro”,6,“toTaskDemand”);
94.	AS(“lastActivity”,“Issued”);
95.	NE( );
96.	NS(“SATask_Subro”,null,“toTaskArbitration”);
97.	NE( );
98.	NS(“SATask_Subro”,null,“toTaskLitigation”);
99.	NE( );
100.	NE( );
101.	NE( );
102.	NS(“SAFolder_Subro”,1,null);
103.	AS(“stage”,“Issued”);
104.	NS(“SAFolderData_Subro”,2,“toAppData”);
105.	NS(“SAParty”,3,“toPartyD”);
106.	AB(“actionFlag”,1);
107.	AI(“alertCount”,3);
108.	NE( );
109.	NS(“SAParty”,3,“toPartyR”);
110.	NS(“SACompany”,4,“toCompany”);
111.	AS(“companyName”, “Gordon Insurance Company” );
112.	AS(“companyId”, “Gordon” );
113.	NE( );
114.	NE( );
115.	NS(“SA_Demand”,5,“toDemand”);
116.	AD(“dateDemandIssued”,“20030407000000”);
117.	AF(“pctRecovery”,.80);
118.	NS(“SA_DemandClaimDetail”, 6, “toClaimDetailD” );
119.	AS(“claimNumber”,“34-000108”);
120.	NE( );
121.	NS(“SA_DemandClaimDetail”, 7, “toClaimDetailR” );
122.	AS(“claimNumber”,“GI-138-00331”);
123.	NE( );
124.	NS(“SA_DemandNeg”, 8, “toCurrentNeg” );
125.	NS(“SA_DemandNegDetail”, 9, “toCurrentProposalD” )
126.	AF(“amtPaymentTotal”,5000.00);
127.	AF(“amtDemandTotal”,5000.00);
128.	NE( );
129.	NS(“SA_DemandNegDetail”, 9, “toCurrentProposalR” )
130.	AF(“amtDemandTotal”,4000.00);
131.	NE( );
132.	NE( );
133.	NE( );
134.	NS(“SATask_Subro”,6,“toTaskDemand”);
135.	AS(“lastActivity”,“Negotiation”);
136.	NE( );
137.	NS(“SATask_Subro”,null,“toTaskArbitration”);
138.	NE( );
139.	NS(“SATask_Subro”,null,“toTaskLitigation”);
140.	NE( );
141.	NE( );
142.	NE( );
143.	RE( );
144.
145.	NS(“STMFNLIST”,null,“oFnList”);
146.	RS(“oFunctions”);
147.	NS(“STMFunction”,null,“”);
148.	AS(“name”,“DemandD_Detail”);
149.	AS(“text”);
150.	AS(“rootObjectType”,“SA_Demand”);
151.	AB(“bWorkFlow”,0);
152.	AS(“workflowBarRootClass”);
153.	NE( );
154.	NS(“ STMFunction”,null,“”);
155.	AS(“name”,“DemandD_History”);
156.	AS(“text”);
157.	AS(“rootObjectType”,“SA_Demand”);
158.	AB(“bWorkFlow”,0);
159.	AS(“workflowBarRootClass”);
160.	NE( );
161.	RE( );
162.	NE( );
163.
164.	NS(“STMMSG”,null,“oMsg”);
165.	RS(“oMessages”);
166.	GA(“MSG_INFO”,“Application informational message.”);
167.	GA(“MSG_ERROR”,“Application error message.”);
168.	RE( );
169.	NE( );
170.
171.	RS(“oDomains”);	//New Domain Support
172.	NS(“SADomain”,501);
173.	AS(“domainName”,“RespondingCompanies”);
174.	AS(“domainType”,“DYNAMIC”);	//DYNAMIC, STATIC, LOOKUP
175.	AS(“domainItemType”,“COMPLEX”);	//COMPLEX, ATTRIBUTE
176.	AS(“domainClass”,“SACompany”);
177.	RS(“toDomainItems”);
178.	NS(“SACompany”,77771);
179.	AS(“name”,“Erie Insurance”);
180.	AS(“companyId”, “Erie”);
181.	AB(“onNetwork”,0);
182.	NE( );
183.	NS(“SACompany”,77774);
184.	AS(“name”,“Gordon Insurance Company”);
185.	AS(“companyId”, “Gordon”);
186.	AB(“onNetwork”,0);
187.	NE( );
188.	NS(“SACompany”,77776);
189.	AS(“name”,“Insurance Property & Casualty”);
190.	AS(“companyId”, “IPC”);
191.	AB(“onNetwork”,0);
192.	NE( );
193.	NS(“SACompany”,77780);
194.	AS(“name”,“New Jersey Manufacturers”);
195.	AS(“companyId”, “NJM”);
196.	AB(“onNetwork”,0);
197.	NE( );
198.	RE( );
199.	NE( );
200.	RE( );
201.
202.	NE( );
203.
204.	// STM End
205.	//-->
206.	</SCRIPT>
207.	</HEAD>
208.
209.	<BODY TOPMARGIN=“0” LEFTMARGIN=“0” MARGINHEIGHT=“0” MARGINWIDTH=“0” ONLOAD=“goJM.Init( )” >
210.	<DIV ID=“JV_BODY”>
211.	<NOSCRIPT>
212.	Site Error 0001 - Javascript Not Supported or Currently Disabled Within Your Browser.
213.	<br><br>
214.	To resolve this problem, please contact Siteras Customer Support at
215.	<A href=“http://www.siteras.com”>www.siteras.com</A>
216.	</NOSCRIPT>
217.	</DIV>
218.	</BODY>
219.	</HTML>

Diagram 2—JView™ HTML Generation

[0479]

1.	var aHTML = new Array( );	// HTML Array
2.	var sHTML;	// HTML Stream
3.
4.	aHTML[aHTML.length] = “<BODY>”;
5.	aHTML[aHTML.length] = “<TABLE>”;
6.	aHTML[aHTML.length] = “<TR><TD>This is some
	text.</TD></TR>”
7.	... additional HTML generation statements or method
	calls ....
8.
9.	sHTML = aHTML.join(“”);	// Create the HTML Stream
10.	JV_BODY.outerHTML = sHTML;

Background—Inter-Organizational Workflow Management

[0480] Automated systems that process business transactions often need to manage and track the flow of these transactions within the related business process (i.e., workflow). Typically, this workflow capability is explicitly coded within the software used to control the system. These systems cover a wide array of business applications, of varying complexity, including production forecasting/scheduling, order processing, human resources management, financial accounting, sales management, etc. Commercial examples of such systems include offerings from SAP, Oracle, and PeopleSoft.

[0481] During the 80's and 90's, these systems were focused on integration of business processes and data that existed within an organization (i.e., intra-organization). Organizations that successfully implement such systems achieve reduced costs, higher efficiency, and compete more effectively in the global economy. With the intra-organization systems in place, these organizations are now looking to integrate the business processes and data that exist between trading partner organizations (i.e., inter-organizational).

Requirements and Challenges

[0482] At a minimum, intra-organization workflow management must be capable of the following: 1) maintaining status information related to the current state of the business transaction (Status). In general, the status information is defined in such a way that it is easy to understand the flow of the transaction as is proceeds from inception to conclusion, 2) maintaining ownership information related to the current owner of the business transaction—i.e., the person/group/organization that is responsible for taking the next action on the transaction (Ownership), 3) determining the allowed operations/functions that can be performed on the business transaction at any given point within the workflow (Navigation), and 4) determining the new state for a business transaction when an operation/function is performed that affects that transaction (State Management).

[0483] When workflow management for a complex business process is explicitly coded within an application system, the following limitations arise: 1) it is very difficult to determine whether or not all business process conditions can be handled; as a result, comprehensive testing of such workflow is difficult, time consuming, and expensive, and 2) when the underlying business process changes, software modifications are required to support any changes or additions to the related workflow.

[0484] Beyond the requirements of intra-organization workflow, inter-organizational workflow requires the following additional capabilities. 1) a common framework, specific to the business process, that enables all the individual organizations to be able to communicate about the status of a business transaction in a consistent manner; this is referred to as community workflow status or inter-organizational workflow status, 2) the ability to maintain the transaction status with respect to each individual organization involved in the transaction (i.e., related to it's own internal systems or business processes); this is referred to as organization-specific workflow status or intra-organization workflow status, 3) the ability to distinguish between and amongst multiple organizations involved in a transaction (i.e., the parties involved in the transaction), 4) the ability to distinguish the role or relationship that any given organization has with respect to a specific transaction, 5) the ability to manage the functions/operations that each organization can perform based on their relationship in the business transaction and the current state of the transaction, and 6) the ability to provide security and privacy for each organization with respect to data and functions.

Inter-Organization Workflow Management Subsystem

[0485] The Inter-Organization Workflow Management Subsystem (or just Workflow Subsystem) is designed to meet the requirements of both intra and inter organization workflow. This subsystem is not dependent on a specific vertical business process or application. This subsystem is unique in its ability to deal with multi-party workflow management that spans distinct organizations. The following sections describe the key characteristics and benefits of the Workflow Subsystem.

[0486] General

[0487] The workflow subsystem does not manage workflow based on explicitly coded software instructions. Rather, it uses a series of workflow tables (data structures) and a unique workflow algorithm to perform all workflow management operations.

[0488] The workflow tables are essentially a set of finite state machines (FSM's), that define a closed loop system for the workflow related to a given business process. Using this approach, the workflow defined for each business process is complete (i.e., no holes or gaps can exist in the workflow table).

[0489] Status (Community Status—Inter-Organization Workflow)

[0490] With inter-organizational workflow, the workflow subsystem includes a framework that allows all the participants to communicate about the status of their transactions using a consistent language. For each business process, a specific community framework (i.e., terminology, status codes, etc.) will be defined. The workflow subsystem can support any number of independent community frameworks.

[0491] Within the folder, the stage is used to represent the main community workflow status for the transaction. This is used to track the overall progression of the transaction through its workflow towards conclusion.

[0492] For each task within the folder, the parties that are allowed to operate on that task are defined. For each such party, a community task party state is maintained. This allows the workflow subsystem to manage and track the community status of each party on each task.

[0493] Status (Organization Status—Intra-Organization Workflow)

[0494] In order to support intra-organization workflow, a parallel framework (similar to the community framework) is established within the workflow subsystem. The only difference is that this framework is specific to a given organization. This framework is used to manage and track any organization specific activities that occur within a business process. For each business process, a specific organization specific framework (i.e., terminology, status codes, etc.) can be defined (by party type). The workflow subsystem can support any number of independent organization specific frameworks.

[0495] For each party on the folder, the organization stage is used to represent the main organization workflow status for the transaction. This is used to track the overall progression of the transaction through its organization specific workflow towards conclusion.

[0496] For each task within the folder, the parties that are allowed to operate on that task are defined. For each such party, an organization task party state is maintained. This allows the workflow subsystem to manage and track the organization specific status of each party on each task.

[0497] Ownership

[0498] By maintaining the action party on each task within the folder, the workflow subsystem is able to determine which organization is responsible for taking action on the business transaction at both the folder level, and the specific task level.

[0499] Navigation

[0500] Based on the current state information maintained within the folder and tasks, the workflow subsystem can determine the functions that can be performed at any time by any party. This capability is referred to as workflow navigation or just navigation.

[0501] Using this navigation capability, the enclosing system that uses the workflow subsystem can present to any user the list of valid business operations that can be performed at any time (subject to that user's security profile). This eliminates the need for the operator to remember the different workflow conditions and greatly aids in the training of new operators. At the same time, this mechanism ensures the integrity of the business process by preventing any “out of process” operations from being performed.

[0502] State Management

[0503] Based on the current state information maintained within the folder and tasks, when a new function is performed on the folder, the workflow subsystem will automatically update the state information within the folder (i.e., on the folder and any tasks).

[0504] This capability is at the heart of the workflow subsystem and allows for an orderly transition from one business state to another. Upon completion of any given workflow transition, the folder will now reside in a new state (or just the same state).

[0505] Within the workflow table, it is possible to define conditional workflow. This workflow allows the resulting workflow state to be set based on the value of any number of additional business data elements contained within the folder (i.e., as affected by the function that is just performed). The definition of these criteria can be arbitrarily complex and any number of conditional workflow rules can be defined.

Commercial Example

[0506] The Electronic Subrogation Network is a commercial example of a fully operational system that embodies the concepts described herein specifically for the vertical market of Insurance Subrogation claims Processing.

Terminology

[0507] This section contains terminology definitions that are useful in understanding the concepts described in this section.

[0508] Folder

[0509] Each distinct business transaction is represented by a folder. The folder is used to logically contain all information related to this transaction (e.g., parties, tasks, documents, contacts, alerts, attachments, events, etc.).

[0510] Party

[0511] A business transaction involves the interaction between two or more parties where, for the purpose of that transaction, each party takes on a specific relationship (described further below). With intra-organization workflow, parties are typically different business units (e.g., division, department, etc.) within the same organization. With inter-organizational workflow, parties are typically different organizations or individuals.

[0512] Relationship (Party Type)

[0513] For each specific type of business transaction (folder), one or more relationships are defined. Each relationship defines the role that a given party will play with respect to that transaction. For example, in a simple order management transaction (Order Folder), one party represents the “Buyer” and one party represents the “Supplier”. As such, for each party defined on the folder, that party's relationship to the transaction is referred to as their party type. FIG. 22 illustrates the relationships of multiple parties with respect to an Insurance Subrogation Demand transaction.

[0514] Tasks

[0515] A task is used to represent an independent business activity (related to the transaction for this folder). Each folder must have at least one task (its primary task). With complex business processes, multiple tasks are used within the folder to manage and track multiple parallel activities related to a given business transaction. For example, for an order management transaction (Order Folder), one task is defined for the order itself, and additional tasks are defined for each distinct shipment/invoice.

[0516] Action Party

[0517] For each task on the folder, the party responsible for taking the next action related to that business activity is referred to as the action party. When the business transaction is concluded, no further business activity will occur. At this point, no action party will exist on any tasks within the folder.

[0518] Function

[0519] Each operation that can be performed on the folder, that affects the information or status of the folder, is referred to as a function. Based on the folder, certain functions can only be performed by a specific party type, while others can be performed by some or all party types. In a simple order management transaction some examples of functions include: issuing a purchase order (buyer), accepting an initial order (supplier), creating a shipment/invoice (supplier), etc.

[0520] Business Transaction

[0521] An interaction between two or more parties that results in the formal exchange or transfer of goods, services, capital, information, or other resources. Examples include an insurance claim, a purchase order, booking an airline flight, ordering a book, etc.

[0522] Organization

[0523] Two distinct legal entities (e.g., companies or individuals) as opposed to different business units (of arbitrary size) within a single legal entity.

[0524] Workflow

[0525] A defined set of business operations and/or processes, triggered by an initial business event (business transaction), that proceed in a specific sequence or order, and culminate in a conclusion or completion of the transaction. A simple workflow will follow a prescribed set of operations in sequence to conclusion (single path). A complex workflow will contain multiple conditional paths, only one of which will be taken based on the business conditions present in the transaction.

[0526] Inter-Organization Workflow

[0527] A workflow that exists between two organizations for the purpose of conducting/completing a business process/transaction specific to those organizations.

[0528] Workflow State

[0529] A specific point within a given business workflow. For any given transaction, its complete workflow will typically encompass many distinct states.

[0530] Workflow Progression (Stage)

[0531] Within the context of a business transaction, most transactions progress from inception towards some form of closure. There can be many different paths that any given transaction takes through the various workflow states towards closure. And, the number of possible paths is directly related to the number of distinct workflow states and possible transitions allowed in any given workflow (essentially most business workflows are defined as “closed loop” processes in that any transactions entering the system will eventually exit the system). Within the Inter-Organization Workflow Management system, the current progression of a given transaction is referred to as its stage. The stage is maintained in the folder for each business transaction.

[0532] Finite State Machine (FSM)

[0533] A model of computation consisting of a set of states, a start state, an input alphabet, and a transition function that maps input symbols and current states to a next state. Computation begins in the start state with an input string. It changes to new states depending on the transition function.

(Above definition from NIST—http://www.nist.gov/dads/HTMUfiniteStateMachine.html)

Detailed Description—Inter-Organizational Workflow Management

[0534] The Inter-Organization Workflow Management Subsystem (or just Workflow Subsystem) provides for both intra and inter organization workflow management. This subsystem is not dependent on a specific vertical business process or application and is unique in its ability to deal with multi-party workflow management that spans distinct organizations.

[0535] This section contains detailed process and component descriptions related to the workflow subsystem. This discussion assumes some familiarity with the following concepts and technologies:

• • [0536] finite state machine concepts and terminology
  • [0537] general business-oriented transaction processing concepts
  • [0538] object-oriented design and programming

[0539] The workflow subsystem described in this section has been implemented within the following business transaction contexts:

• • [0540] Insurance—Subrogation claims (Demands, Responses, Arbitration Filings, etc.)
  • [0541] Manufacturing—Order Processing (Purchase Orders, Shipping, Invoicing, Returns, etc.)
  • [0542] Retail—Store Management (Labor Scheduling, Employee Maintenance, Timecard Tracking, etc.)
  • [0543] General—Call Logging and Problem Management

[0544] Overview

[0545] The following sections summarize the key concepts used within the system.

[0546] General

[0547] The following general insights have driven the development of the workflow subsystem. A folder (defined below) is a container for a related set of data elements for a given business transaction. In its purest sense, the true workflow state of any given folder is represented by the distinct values that exist in all its data elements at any given point in time. Unfortunately, this approach would not be practical for human comprehension (i.e., information overload). From a practical standpoint, the workflow of a given folder can be adequately represented by a finite set of value permutations that occur across a subset of its data elements. Each such permutation is represented by a given workflow state. This is a form of shorthand that allows humans to understand, organize, and relate to the processing of any business transaction.

[0548] Folder

[0549] Within the system, each distinct business transaction is represented by a transactional folder. Each folder has the following key characteristics. It is a logical container for all information related to the transaction (e.g., parties, tasks, documents, contacts, alerts, attachments, events, etc.). Within the folder, a major workflow variable (stage) is maintained. This variable represents the workflow progression for this folder. Within the folder, one or more parties (party) are defined. This collection of parties represents the distinct set of organizations that are allowed to interact with this transaction. Each such party so defined is governed by their relationship to the transaction (referred to as their party type). This party relationship is used to constrain the information that can be viewed and the functions that can be performed (by this party, with respect to this transaction). Within the folder, one or more workflow tasks (task) are defined. A task is used to represent an independent business activity (related to the transaction for this folder). Each folder must have at least one task (its primary task).

[0550] Stage

[0551] For any transactional folder, the stage represents the major progression (i.e., its workflow progression) of that transaction towards its eventual completion or closure. In general, once a transaction has moved to a given stage, it does not move back to a prior stage.

[0552] Tasks and Task Parties

[0553] Within a folder, tasks are used to represent one or more business activities that are occurring related to the completion of the transaction. The following are the characteristics of a task:

[0554] The granularity of the task definition (i.e., the specific business activity to which it relates) depends on the needs of the specific business application. By default, a primary task is created when the transactional folder is created. When the task is created, a certain number of parties must be assigned to the task (at least 1). This assignment is used to constrain the information that can be viewed and the functions that can be performed (by this party, with respect to this task). Additional parties can be granted access to the task during its life. Once assigned, a party is never removed from a task. For each party assigned to a task, a task party is created. Multiple tasks can exist within a folder at the same time. This enables the system to support parallel business activity within a given business transaction. Within each task party, a party specific variable (party state) exists for each party defined on the task. This variable is used to track the current workflow state of that party with respect to the task.

[0555] A single action variable (action party) exists for each task that identifies the party that needs to take the next action for this task. Since multiple tasks can exist in a folder, multiple action variables can exist (i.e., parallel workflow can be managed). Within each task, a last activity variable contains a description of the last activity that was performed on the task that changed the action party. Any party can view all the workflow states of any task that it has access to. Any function can change the state of one or more party specific state variables on one or more tasks (as defined within the workflow table). When all the party states on a task are “closed”, the task is “closed”. In this case, the action flag is set to null (i.e., a task that is closed cannot require action). When the state of the primary task is “closed”, the stage of the folder is “closed”. However, in this case, other tasks within the folder may not be closed. This allows for “post-close” workflow to occur in an orderly fashion. At the point all the tasks within the folder are “closed”, the folder is “closed”. The true workflow state of a folder is really the aggregation of all states on all tasks.

[0556] Community Workflow

[0557] With inter-organizational workflow, a common language or framework must be established for all organizations involved in the transactions. This allows for consistent and effective communication related to the workflow state of any given transaction. Within the workflow subsystem, the following data elements represent this common framework:

• • [0558] Folder—stage
  • [0559] Party—partyType
  • [0560] Task—actionParty, lastActivity
  • [0561] Task Party—partyState

[0562] These data elements represent the community workflow information that is available to all parties defined for the specific folder.

[0563] Intra-Organization Workflow

[0564] Since any inter-organizational workflow must also exist within the context of intra-organization workflow (i.e., workflow that is specific to a given organization), the workflow subsystem supports the maintenance of the organization specific workflow states. The following data elements are used to maintain organization specific workflow state:

• • [0565] Party—orgStage
  • [0566] Task Party—orgState

[0567] These data elements represent the organization specific workflow information. This information is private to each party within the folder.

[0568] Workflow Data Model

[0569] FIG. 25 illustrates those main data entities and their relationships used by the workflow subsystem. The Folder (SAFolder), Party (SAParty), Task (SATask) and TaskParty (SATaskParty) entities contain the actual workflow state information for a given business transaction. The Workflow Table contains the workflow definitions that are used by the workflow processes.

[0570] Workflow Table

[0571] The Workflow table is at the heart of the workflow subsystem. Essentially, this table is used to define and organize multiple Finite State Machines (FSM's). These FSM's work in combination to define and control the workflow for the entire application system. This table and the related workflow processes are described in detail below.

[0572] For any given application system, a single workflow table is defined that contains the community workflow definitions for all business transactions processed by this application. Another table is also defined that contains the organization specific workflow definitions. This organization specific workflow table is similar in structure to the community workflow table.

[0573] Workflow State Transitions

[0574] The main purposes of the workflow table is to allow the system to determine the next workflow state for a transactional folder based on its current state and the completion of a given application function that alters that folder—i.e., the workflow state transition. Within the workflow subsystem, the workflow state transition mechanism is used to modify any or all of the following: stage, party state, actionParty, or taskParties.

[0575] Workflow Navigation

[0576] In addition to defining workflow state transitions, the workflow table implicitly defines workflow navigation as well. For any given transactional folder in a given state, the workflow table will define the application functions that are allowed to be performed in this state. Based on these definitions, the workflow subsystem can return this list of valid application functions for any folder at any time.

[0577] With an online system, this is useful as it allows the system to guide or navigate a user through the system by displaying the allowed functions that are valid. This reduces the workflow knowledge required by the users, speeds training, and allows lesser skilled users to operate the system.

[0578] Action Party Management

[0579] One problem that exists with inter-organizational workflow is determining, at any given time, which organization is responsible for taking the next action on the transaction. With each task, the actionParty field contains the party type of the party that is responsible for taking the next action on this task. In fact, since multiple tasks can exist within a folder, the workflow subsystem is capable of keeping track of the action party for multiple tasks.

Workflow Table Structure

[0580] The workflow table contains records that define the workflow for all business transactions within a given application system. The detailed attributes within this table contained in Diagram 3 below.

[0581] The records in the workflow table are organized into groups along the following dimensions: folder type; task type; stage; task party type; and party State.

[0582] These groupings essentially divide the table into multiple sets of workflow records along a given dimension.

[0583] Within these dimensions, each workflow record defines the workflow state transition that is to occur after the processing of a specific application function has been completed. Additionally, each workflow record implicitly defines the application functions that are “valid” (from a workflow standpoint) within any given workflow state (thereby allowing the system to support workflow navigation).

[0584] Workflow Operation Code

[0585] A given workflow record can be defined to control either workflow navigation, workflow state transitions, or both. The operationCode field is used to specify which of these workflow operations are to be performed.

[0586] Conditional Workflow

[0587] In most cases, workflow state transitions are simple and deterministic—the next workflow state is determined simply by the current workflow state and the application function that was completed. However, in some cases, the transition can only be determined by inspecting other data elements within the transactional folder. In this case, the workflow is conditional.

[0588] To support conditional workflow, the workflow table allows multiple workflow records to be defined for the same workflow state and same application function. These records are then further differentiated by the postConditionQualifier. Similar to a “WHERE” clause within an SQL statement, this field defines the data condition under which the state transition is to be performed. If this condition evaluates to “TRUE” the workflow engine will perform the state transition as defined on this record. If not, it will continue to evaluate the conditional qualifiers on the other workflow records (if all conditions return “FALSE”, the workflow engine will return a workflow error to the calling subsystem).

[0589] This conditional workflow capability also applies to workflow navigation. In some cases, a given application may or may not be allowed within a given workflow state based on the values of other data elements within the transactional folder. To support this capability, a preConditionQualifier can be defined for each workflow record. When performing workflow navigation, the system will only return application functions for a given workflow state where this field is either null or where the qualifier evaluates to “TRUE”.

[0590] Assigning Additional Task Parties to a Task

[0591] As part of the workflow state transition mechanism, additional task parties can be added to a specific task in response to an application function. This is controlled by the taskPartyArray field. Once a given workflow record is selected for workflow state transition, if the task party array contains a party type for a party that does not exist on that Task, then the new partyType is added to the currentPartyArray field for that task.

[0592] Action Party Management

[0593] As part of the workflow state transition mechanism, the actionParty for a given task can be modified in response to an application function. This is controlled by the nextActionParty field. Once a given workflow record is selected for workflow state transition and if the nextActionParty field contains a partyType, then the actionParty for this task will be updated. Additionally, if the nextActionParty field contains a “?”, then this indicates that the nextActionParty type is application dependent, and in this case, the nextActionPartyType will have been provided from subsystem that invokes the workflow manager.

Workflow Processing

[0594] There are two distinct types of workflow processing that are performed by the workflow subsystem—workflow navigation and workflow state transitions. The following sections describe this processing in detail.

[0595] Workflow Navigation

[0596] The following describes the operation of the workflow navigation mechanism.

[0597] The calling subsystem will invoke the GetWorkflowFunctions( ) class method of the WorkflowManager Class. In doing so, the following parameters will be passed:

• • [0598] oFolder—reference to the folder being accessed;
  • [0599] sPartyType—the party type of the organization accessing the folder;
  • [0600] aFunctions—an empty array (that is to contain the valid workflow functions).

[0601] Within the GetWorkflowFunctions( ) method, the following will be performed:

[0602] Based on the folder reference, the current workflow state will be determined (e.g., stage, tasks, task party states, etc.).

[0603] Retrieve the Task records for this folder.

• • [0604] FOR EACH task within the folder (oTask),

[0605] Retrieve the task party records for this task.

• • [0606] FOR EACH task party record (oTaskParty),

[0607] Query the workflow table will be queried using the following:

[0608]

	SELECT * FROM SAWORKFLOW WHERE
	((folderType = oFolder.folderType)
	AND
	(taskType = oTask.taskType)
	AND
	(stage = oFolder.stage) AND
	(taskPartyType =
	oTaskParty.partyType) AND
	(partyState =oTaskParty.partyState)
	AND
	(actionParty = sPartyType)
	AND
	((operationCode = ‘N’) or
	(operationCode = ‘B’))
	);
	FOR EACH workflow record returned,
	IF the preConditionQualifier is null THEN
	Add the application function specified
	in this record to aFunctions.
	ELSE
	IF the preConditionQualifier evaluates to
	TRUE THEN
	Add the application function specified
	in this record to aFunctions.
	END IF
	END IF
	END FOR (no more workflow records)
	END FOR (no more task party records)
END FOR (no more task records)

[0609] At this point, the aFunctions array contains the list of application functions that are allowed for the current folder in its current state. The GetWorkflowFunctions( ) method will return to the caller.

[0610] Workflow State Transitions

[0611] The following describes the operation of the workflow state transition mechanism.

[0612] The calling subsystem will invoke the EvaluateWorkflow( ) class method of the WorkflowManager Class. In doing so, the following parameters will be passed:

• • [0613] oFolder—reference to the folder being processed;
  • [0614] oFunction—reference to the application function (whose processing has just been completed);
  • [0615] sPartyType—the party type of the organization accessing the folder; and
  • [0616] sNextActionPartyType—if the nextActionParty for this application function is application dependent, then this field will contain the nextActionPartyType, otherwise it will be null.

[0617] Within the EvaluateWorkflow( ) method, the following will be performed. Based on the folder reference, the current workflow state will be determined (e.g., stage, tasks, task party states, etc.). The current stage is saved in sCurrentStage.

[0618]

	IF the application function (oFunction) indicates that a
	new task should be
	created, THEN
	Create the new task for this folder
	END IF
	Retrieve the Task records for this folder.
	FOR EACH task within the folder (oTask),
	Retrieve the task party records for this task.
	FOR EACH task party record (oTaskParty),
	Query the workflow table will be queried
	using the
	following:
	SELECT * FROM SAWORKFLOW
	WHERE
	((folderType = oFolder.folderType)
	AND
	(taskType = oTask.taskType)
	AND
	(stage = sCurrentStage) AND
	(taskPartyType =
	oTaskParty.partyType)
	AND
	(partyState =
	oTaskParty.partyState) AND
	(actionParty = sPartyType)
	AND
	((operationCode = ‘S’) or
	(operationCode =
	‘B’))
	);
	FOR EACH workflow record returned,
	IF the postConditionQualifier is null
	THEN
	Perform the state transition
	indicated
	by this workflow record (see
	below).
	ELSE
	IF the postConditionQualifier
	evaluates
	to TRUE THEN
	Perform the state
	transition
	indicated by this workflow
	record (see
	below).
	END IF
	END IF
	END FOR (no more workflow records)
	END FOR (no more task party records)
	END FOR (no more task records)

[0619] When a state transition is to be performed, the following operations will occur using the values from the selected workflow record.

[0620]

	IF the nextStage is not null THEN
	Set the oFolder.stage = nextStage
	END IF
	IF the nextPartyState is not null THEN
	Set the oTaskParty.partyState = nextPartyState
	END IF
	IF the nextActionParty is not null THEN
	IF the nextActionParty = “?” THEN
	Set the oTask.action Party = sNextActionPartyType
	ELSE
	Set the oTask.actionParty = nextActionParty
	END IF
	END IF
	IF the taskPartyArray is not null THEN
	Add any new parties to oTask.currentPartyArray.
	FOR EACH new party added
	Create a new TaskParty record for this Task
	Add this new TaskParty record to the array of task
	parties currently being processed (so that the party state for
	this new task party record will be correctly initialized).
	END FOR
END IF

[0621] At this point, the workflow state transition has been completed and the EvaluateWorkflow( ) method will return to the caller.

[0622] NOTE: Within this processing, the evaluation of the workflow occurs, after the processing for the application function that modified the folder. This is necessary in order to allow the application to modify the application data elements within the folder. Once this is complete, any postConditionQualifiers (and resulting workflow) will be evaluated against the new application data.

Workflow Subsystem Processing Example

[0623] This section illustrates one example of the workflow subsystem within the context of the Insurance Subrogation application.

[0624] Subrogation Workflow Overview

[0625] A subrogation claim is a business transaction between two insurance companies—a demanding company and a responding company. This claim arises when an accident occurs between two insured vehicles—one insured by the demanding party and one insured by the responding party (where the responding party's driver was liable for the accident). In this case, the demanding company is entitled to seek reimbursement from responding company for the costs incurred to repair their insured's vehicle. The demanding company initiates the transaction by sending a subrogation demand to the responding company.

[0626] The applicant provides an ASP based application (electronic network), that allows insurance carriers to process and settle their subrogation claims using an automated system. This system can interface with an insurance carrier either electronically or manually (via a web based interface).

[0627] The workflow related to processing a subrogation claim is complex in that the transaction can follow many different paths during its life. As such, additional parties (beyond the Demander and Responder) can be involved in the transaction. FIG. 22 depicts the full set of parties that can participate in a given subrogation transaction.

[0628] Folders

[0629] The Subrogation application deals with the following transactional folders:

• • [0630] Demand Folder (SAFolder_Subro)
  • [0631] Demand File Upload Folder (SAFolder_DemandUpload)
  • [0632] Company Folder (SAFolder_Company)
  • [0633] Location Folder (SAFolder_Location)
  • [0634] Group Folder (SAFolder_Group)
  • [0635] Operator Folder (SAFolder_Operator)
  • [0636] System Folder (SAFolder_System)
  • [0637] System Alert Folder (SAFolder_SystemAlert)

[0638] Each of the above folders has its own workflow defined within the workflow table. For this example, we will only describe the workflow related to the Demand folder.

[0639] Parties

[0640] The Demand folder can have the following parties:

• • [0641] Demander (D)—the primary party (i.e., insurance carrier) who initiates the transaction.
  • [0642] Responder (R)—the counter-party (i.e., insurance carrier or uninsured motorist) responsible for the claim.
  • [0643] Arbitrator (A)—For demands being arbitrated, the arbitration organization.
  • [0644] Collection Agency (C)—If the responding party is an uninsured motorist, the collection agency handling the recovery.
  • [0645] Demander's Attorney (X)—For demands being litigated, the demanding party's attorney.
  • [0646] Responder's Attorney (Y)—For demands being litigated, the responding party's attorney.
  • [0647] Demander's Insured (E)—The demanding party's policyholder.
  • [0648] Responder's Insured (S)—The responding party's policyholder.

[0649] Demand Folder Tasks

[0650] The Demand folder can have the following tasks:

• • [0651] Demand—the primary task representing the subrogation claim.
  • [0652] Arbitration—a secondary task used to track arbitration activity.
  • [0653] Litigation—a secondary task used to track litigation activity.

[0654] Demand Folder Stages

[0655] The following stages are defined for the Demand Folder:

• • [0656] Init—Initial stage used when the Demand folder is initially created.
  • [0657] Preparation—Demand has been created, but not issued to a responding company.
  • [0658] Issued—Demand has been issued to a responding company.
  • [0659] Negotiation—Demand is being negotiated between the demanding party and responding party.
  • [0660] Arbitration—Demander has decided to pursue binding arbitration.
  • [0661] ArbFinal—Arbitration is complete and an award has been made.
  • [0662] Litigation—Demander has decided to pursue litigation.
  • [0663] LitFinal—Litigation is complete and a judgment has been made.
  • [0664] Closed—the Demand transaction has been settled.

[0665] Party States

[0666] For each of the tasks above, and for each party, specific party states are defined. Within the subrogation workflow, there are currently 60 valid combinations of party states and stages.

[0667] Application Functions

[0668] Within the subrogation application, there are currently 60 different editing functions that can be performed on a Demand folder.

[0669] Workflow Table Example

[0670] Within Diagram 4 (below) are some representative rows from the workflow table used within the Insurance Subrogation application. These sample rows all relate to the Demand folder and illustrate workflow for a Demander (partyType D) or Responder (partyType R).

[0671] Based on the number of workflow states (60) and application functions (60), the Demand folder has 3600 possible workflow conditions. However, since the workflow table only contains “valid” workflow conditions, the final table only contains 1000 rows (i.e., 2600 combinations are invalid). The following describes how these workflow rows are used to control the subrogation related workflow.

[0672] Creating a New Subrogation Demand Folder (Row 344)

[0673] This workflow row is used to control the workflow when a new subrogation transaction folder is initially created (from the application function DemandD_CreateElectronic).

Line(s) Description

• [0674] 1,2 This row applies to the Demand folder (SAFolder_Subro) and Demand task.
• [0675] 3,5 When a folder does not exist, its stage and all party state variables are defined as “Init”.
  Line(s) Description
• [0676] 4 Within the Demand task, this row applies to the Demander (D) task party.
• [0677] 8 This workflow row is used for BOTH workflow navigation and state transition processing.
• [0678] 6,7 Within the workflow state specified in this row, any state transition processing will be triggered when the Demander (partyType D) executes the application function DemandD_CreateElectronic.
• [0679] 9 No preConditionQualifier is specified. For workflow navigation, this function will be unconditionally included in the list of allowed functions for this workflow state.
• [0680] 10 A postConditionQualifer is specified for this workflow row. If this condition is true, then the workflow state transition will be performed using the other values for this row. If this condition is false, then the workflow transition will be performed using another workflow row in the table (not shown).
• [0681] 11 If the state transition is performed for this row, the stage of the new folder will be set to “Preparation”
• [0682] 12 If the state transition is performed for this row, the party state for the Demander's task party record will be set to “Pending Issuance”.
• [0683] 13 If the state transition is performed for this row, the actionParty for this task will be set to the Demander (D) (i.e., the demanding party will be responsible for taking the next action on this task within this transactional folder).
• [0684] 14 Since this folder is being newly created, no parties have been assigned to the Demand task. If the state transition is performed for this row, the Demander (D) will be assigned to this task.

[0685] Workflow Navigation Control for Arbitration Function (Row 805)

[0686] This workflow row is only used to control workflow navigation for the Demander. By using a “preConditionQualifier”, this row will allow the Demander to perform the application function DemandD_Arbitrate only if the responding party belongs is a member of the arbitration organization.

Line(s) Description

• [0687] 1,2 This row applies to the Demand folder (SAFolder_Subro) and Demand task.
• [0688] 3 This row applies to the Negotiation stage.
• [0689] 4 Within the Demand task, this row applies to the Demander (D) task party.
• [0690] 5 Within the Demand task, within the Demander's task party record, this row applies to the party state “Counter Offer Approved”.
• [0691] 8 This workflow row will ONLY be used for workflow navigation.
• [0692] 9 A preConditionQualifier is specified for this workflow row. If this condition is true, then the application function will be included in the list of allowed functions for this workflow state.
• [0693] 6,7 The actionParty and application function for this workflow row.
  Line(s) Description
• [0694] 11 Not applicable (since the operation code is N).
• [0695] 12 Not applicable (since the operation code is N).
• [0696] 13 Not applicable (since the operation code is N).
• [0697] 14 Not applicable (since the operation code is N).

[0698] Setting the Action Party with Assistance from the Application Function (Row 808)

[0699] This workflow row is used to control the workflow for an Inquiry function executed by the Demander within the stage “Negotiation” and the Demander's party state “Counter Offer Approved”. Since an inquiry can be sent to one of many parties, this row illustrates the use of the “?” for setting the next action party for this task on the folder.

Line(s) Description

• [0700] 1,2 This row applies to the Demand folder (SAFolder_Subro) and Demand task.
• [0701] 3 This row applies to the Negotiation stage.
• [0702] 4 Within the Demand task, this row applies to the Demander (D) task party.
• [0703] 5 Within the Demand task, within the Demander's task party record, this row applies to the party state “Counter Offer Approved”.
• [0704] 8 This workflow row is used for BOTH workflow navigation and state transition processing.
• [0705] 6,7 Within the workflow state specified in this row, any state transition processing will be triggered when the Demander (partyType D) executes the application function DemandD_Inquiry.
• [0706] 9 No preConditionQualifier is specified. For workflow navigation, this function will be unconditionally included in the list of allowed functions for this workflow state.
• [0707] 10 No postConditionQualifer is specified for this workflow row. If triggered, the state transition specified in this row will be unconditionally applied to the folder.
• [0708] 11 If the state transition is performed for this row, the stage of the folder will NOT be changed (since this field is null).
• [0709] 12 If the state transition is performed for this row, the party state for the Demander's task party record will NOT be changed (since this field is null).
• [0710] 13 If the state transition is performed for this row, the actionParty for this task will be changed. Since the value specified in this row is “?”, the application function will have passed the actionPartyType to the calling subsystem. This value will have been passed on the EvaluateWorkflow( ) method. This value will be used to set the actionParty for this task. If no value is provided by the calling subsystem, a workflow error will be returned.
• [0711] 14 No new parties will be added to this task.

[0712] Workflow State Transition Processing only for Counter Offer Approval (Row 856)

[0713] This workflow row is only used to control the workflow state transition when a counter offer is approved by the demanding party. Since the ability to perform this function is based on the party state of the responding party, the workflow navigation for this function is defined within the responding party's task party section (described later in row 936).

Line(s) Description

• [0714] 1,2 This row applies to the Demand folder (SAFolder_Subro) and Demand task.
• [0715] 3 This row applies to the Negotiation stage.
• [0716] 4 Within the Demand task, this row applies to the Demander (D) task party.
• [0717] 5 Within the Demand task, within the Demander's task party record, this row applies to the party state “Demand Issued”.
• [0718] 8 This workflow row is ONLY used for workflow state transition processing.
• [0719] 6,7 Within the workflow state specified in this row, any state transition processing will be triggered when the Demander (partyType D) executes the application function DemandD_Approve.
• [0720] 9 Not applicable (since the operation code is S).
• [0721] 10 No postConditionQualifer is specified for this workflow row. If triggered, the state transition specified in this row will be unconditionally applied to the folder.
• [0722] 11 If the state transition is performed for this row, the stage of the folder will NOT be changed (since this field is null).
• [0723] 12 If the state transition is performed for this row, the party state for the Demander's task party record will be changed to “Counter Offer Approved”.
• [0724] 13 If the state transition is performed for this row, the actionParty for this task will be set to the Responder (R) (i.e., the responding party will be responsible for taking the next action on this task within this transactional folder).
• [0725] 14 No new parties will be added to this task.

[0726] Workflow Navigation Based on yhe Party State of Another Party (Row 936)

[0727] This workflow row is used to control the workflow navigation to ensure that a Demander can only approve a counter offer based on the party state of the responding party. Additionally, when if the demanding party performs this function, this row is also used to update the party state for the responding party.

Line(s) Description

• [0728] 1,2 This row applies to the Demand folder (SAFolder_Subro) and Demand task.
• [0729] 3 This row applies to the Negotiation stage.
• [0730] 4 Within the Demand task, this row applies to the Responder (R) task party.
• [0731] 5 Within the Demand task, within the Responder's task party record, this row applies to the party state “Counter Offer Issued”.
• [0732] 8 This workflow row is used for BOTH workflow navigation and state transition processing.
• [0733] 6,7 Within the workflow state specified in this row, any state transition processing will be triggered when the Demander (partyType D) executes the application function DemandD_Approve.
• [0734] 9 No preConditionQualifier is specified. For workflow navigation, this function will be unconditionally included in the list of allowed functions for this workflow state.
• [0735] 10 No postConditionQualifer is specified for this workflow row. If triggered, the state transition specified in this row will be unconditionally applied to the folder.
• [0736] 11 If the state transition is performed for this row, the stage of the folder will NOT be changed (since this field is null).
• [0737] 12 If the state transition is performed for this row, the party state for the Responder's task party record will be changed to “Pending Response”.
• [0738] 13 If the state transition is performed for this row, the actionParty for this task will be set to the Responder (R) (i.e., the responding party will be responsible for taking the next action on this task within this transactional folder).
• [0739] 14 No new parties will be added to this task.

[0740] Adding Parties to a New Task (Row 51)

[0741] When the demanding party performs the function DemandD_Arbitrate (indicating that they are pursuing arbitration for this demand), the workflow subsystem will create a new task for this folder—the Arbitration task (as indicated on the Function record for this application function). The workflow table contains distinct rows to manage the workflow state defined by each task within a folder. This workflow row is only used to control the workflow state transition for the newly created Arbitration task.

Line(s) Description

• [0742] 1,2 This row applies to the Demand folder (SAFolder_Subro) and Arbitration task.
• [0743] 3 This row applies to the Issued stage.
• [0744] 4 Within the Demand task, this row applies to the Demander's (D) task party.
• [0745] 5 Within the Demand task, within the Responder's task party record, this row applies to the party state “Init”.
• [0746] 8 This workflow row is ONLY used for workflow state transition processing.
• [0747] 6,7 Within the workflow state specified in this row, any state transition processing
  Line(s) Description
  • [0748] will be triggered when the Demander (partyType D) executes the application function DemandD_Arbitrate.
• [0749] 9 Not applicable (since the operation code is S).
• [0750] 10 No postConditionQualifer is specified for this workflow row. If triggered, the state transition specified in this row will be unconditionally applied to the folder.
• [0751] 11 If the state transition is performed for this row, the stage of the folder will be changed to “Arbitration”.
• [0752] 12 If the state transition is performed for this row, the party state for the Demander's task party record (within the Arbitration task) will be changed to “Preparing For Arbitration”.
• [0753] 13 If the state transition is performed for this row, the actionParty for this task will be set to the Demander (D) (i.e., the demanding party will be responsible for taking the next action on this task within this transactional folder).
• [0754] 14 Since this task is being newly created, no parties have been assigned. If the state transition is performed for this row, the Demander (D) and the Responder (R) will be assigned to this task.
  Diagrams—Inter-Organizational Workflow Management

[0755] The following diagrams illustrate a number of features of the Inter-Organizational low Management subsystem described above.

• • [0756] Diagram 3—Workflow Data Model Schema—Workflow Table (SAWorkflow)
  • [0757] Diagram 4—Workflow Table Example—Insurance Subrogation
    Diagram 3—Workflow Data Model Schema—Workflow Table (SAWorkflow)

[0758] This data model schema represents the entity used to control the community workflow that is defined for any given application. Whenever an “editing” function is performed on a folder, the workflow management methods use this table to control the stage, state, and actionParty fields within SATask and SATaskParty entities within that folder.

[0759] This table is used for two workflow purposes:

[0760] 1) To determine the next workflow steps that are allowed, based on a given workflow condition (stage, partyType, state, substate, etc.).

[0761] 2) To determine the next workflow state of the folder after performing a given function, based on the current workflow state of the folder.

[0762] The workflow records within this table are organized into the following hierarchy/groups:

[0763]

	folderType
	taskType
	stage
	taskPartyType
	partyState

Attributes

[0764]

	Data		Dec
Name	Type	Len	Dgts	Nulls	Req	Description
actionPartyType	String	1		N	R	The party type of the party performing the function.
folderType	String	64		N	R	The type of folder. This field contains the entity name of the
						folder to which this workflow record applies (e.g.,
						SASubroFolder, SADemandUploadFolder, etc.).
intrinsicFunctionId	String	255		N	R	The Id of the intrinsicFunction (as specified in
						SAIntrinsicFunction) associated with the function being
						performed.
nextActionParty	String	1		Y	O	Specifies the party type that is responsible for taking the
						next action for this task.
						If specified, this field can contain a valid party type code
						(e.g., D, R, or A), or a “?”. The “?” value is a special value
						that indicates to the Workflow Manager that the
						nextActionParty will be determined dynamically by
						application function at execution. In doing so, the TPL must
						provide an API call that allows the application function to set
						the “nextActionParty” for a given task (during the Validate
						call). Since multiple tasks may exist, the application
						function may have to specify the action party for each task
						(if each task specifies a “?”).
						When the TPL calls the Workflow Manager to evaluate the
						workflow for a folder, it should pass the values for the action
						party that were set by the application function for each task.
nextPartyState	String	64		Y	O	The next party specific state (within the specific
						SATaskParty entity) for this workflow entry.
						If this field is null, the current party specific state (for this
						party) is not affected.
nextStage	String	64		Y	O	The next stage to be set (within the Folder entity) for this
						workflow entry.
						If this field is null, the current stage is not affected.
nextStateEventPathToRoot	String	255		Y	O	If a “next state event” is to be generated (as indicated by a
						nextStateEventTemplateId), then this field is used to specify
						the key path to the root object for this event. The root
						object for this key path will be the folder whose workflow
						state is currently being processed.
						NOTE: If the root object for the event is the same as the
						root object for this workflow entry (i.e., the folder, then this
						field is null).
nextStateEventTemplateld	String	255		Y	O	If a “next state event” is to be generated, this field is used to
						specify the event template Id for that event.
operationCode	String	1		N	R	The workflow operation for this row as follows:
						S—State Change—indicates this row is only used to
						evaluate the next state of the folder after an editing function
						has been performed.
						N—Navigation—indicates that this row is only used to
						determine the valid set of editing functions that are allowed
						based on the current state of the folder.
						B—Both—indicates that this row is used for both State
						Change and Navigation operations.
partyState	String	64		N	R	Workflow state (party type specific).
postConditionQualifier	String	4000		Y	O	This qualifier is used to support “conditional” workflow. In
						this case, two or more rows within the table for the current
						workflow state will specify this qualifier. The system will
						evaluate the qualifier for each row and set the next work
						flow state based on the row whose qualifier that evaluates
						to “true”.
						NOTE: When this field is used, the qualifiers specified for a
						given set of rows must be MUTUALLY EXCLUSIVE in that
						only one and only one qualifier should evaluate to true at
						any given time.
						If this field is null, then it is assumed that the next workflow
						state specified for this workflow entry can be unconditionally
						performed.
preConditionQualifier	String	4000		Y	O	A qualifier used to conditionally determine whether or not
						the function specified for this workflow entry can be
						performed.
						If this field is null, then it is assumed that the function
						specified for this workflow entry can be unconditionally
						performed.
						If this field is not null, then the system will evaluate the
						qualifier. If the qualifier evaluates to “True” then the function
						specified for this workflow entry is allowed, otherwise it is
						disallowed.
stage	String	64		N	R	Workflow stage.
status	String	255		Y	O	This field is used to set the status of the task for the specific
						party (SATaskParty).
						The Workflow Manager will set the status for the
						appropriate party based on the value in this field as follows:
						Null - the action party's state will be used as the status.
						Non-null - the value of this field will be used as the status.
						Non-null and first character is “&” - the value of this field will
						be appended to the current status and the “&” will be
						replaced with a “,”.
stkeyNextStateEventTemplate						Relationship field (see Relationships below).
taskPartyArray	String	16		Y	O	Specifies the party types that should be given access to the
						task represented by this workflow entry. The syntax of this
						field is a Stringing of one or more party type codes where
						each distinct party type is represented by a single character
						(i.e., the party type code).
						The following should be noted:
						This field is additive in that it only specifies parties that can
						be added to a task.
						If a given party specified within this field has already been
						given access to this task, then no additional action is taken.
						If a party of the type specified in this field does not exist on
						the folder, then no action is taken.
						If a party is to be given access to this task, the system will
						create an SATaskParty to link the party to the task.
						For subrogation, the following party type codes are defined:
						D, R, and A.
taskPartyType	String	1		N	R	The party type of the party whose state variable (contained
						in SATaskParty) is being affected.
taskType	String	32		N	R	The type of task.
						The valid task types for subrogation are:
						Demand
						Arbitration
						Litigation
workflowBarRootClass	String	64		Y	O	Used for navigation control, if specified this field indicates
						that a button (for this function) should be displayed in the
						workflow bar (action bar) for any form whose root object
						class matches the class specified in this workflow entry.
	Rel	Relationship Fields
Name	Type	(source/destination)	Req.	Description
toNextStateEventTemplate	1-1	SAEventTemplate	O	If specified, the SAEventTemplate that is to be used to create an
				application specific “event” representing the state change that is taking place.
				This field is typically used to create an event that will trigger a background
				function. For unconditional workflow entries, this can typically be
				performed using the “completion event” that is defined on the
				SAIntrinsicFunction. For conditional workflow (where a background function
				needs to be triggered conditionally), this relationship should be specified.
				NOTE: The Workflow Manager will always create a “generic” event that
				records the workflow state of the folder both prior to, and after,
				the workflow is evaluated. This event is a “detail” event and can be
				used for debugging workflow problems (not for triggering background
				functions).

Diagram 4—Workflow Table Example—Insurance Subrogation

[0765] The following is a small subset of rows from a Workflow Table used within the Siteras Insurance Subrogation application.

[0766]

RowNumber - 344
1.	FolderType:	SAFolder_Subro
2.	TaskType:	Demand
3.	Stage:	Init
4.	TaskPartyType:	Demander(D)
5.	PartyState:	Init
6.	ActionParty:	D
7.	Function:	DemandD_CreateElectronic
8.	OperationCode:	B
9.	PreConditionQualifier:
10.	PostConditionQualifier:	DataComplete
11.	NextStage:	Preparation
12.	NextPartyState:	Pending Issuance
13.	NextActionParty:	D
14.	TaskPartyArray:	D
RowNumber - 805
1.	FolderType:	SAFolder_Subro
2.	TaskType:	Demand
3.	Stage:	Negotiation
4.	TaskPartyType:	Demander(D)
5.	PartyState:	Counter Offer Approved
6.	ActionParty:	D
7.	Function:	DemandD_Arbitrate
8.	OperationCode:	N
9.	PreConditionQualifier:	ResponderIsArbitrationMember
10.	PostConditionQualifier:
11.	NextStage:
12.	NextPartyState:
13.	NextActionParty:
14.	TaskPartyArray:
RowNumber - 808
1.	FolderType:	SAFolder_Subro
2.	TaskType:	Demand
3.	Stage:	Negotiation
4.	TaskPartyType:	Demander(D)
5.	PartyState:	Counter Offer Approved
6.	ActionParty:	D
7.	Function:	DemandD_Inquiry
8.	OperationCode:	B
9.	PreConditionQualifier:
10.	PostConditionQualifier:
11.	NextStage:
12.	NextPartyState:
13.	NextActionParty:	?
14.	TaskPartyArray:
RowNumber - 856
1.	FolderType:	SAFolder_Subro
2.	TaskType:	Demand
3.	Stage:	Negotiation
4.	TaskPartyType:	Demander(D)
5.	PartyState:	Demand Issued
6.	ActionParty:	D
7.	Function:	DemandD_Approve
8.	OperationCode:	S
9.	PreConditionQualifier:
10.	PostConditionQualifier:
11.	NextStage:
12.	NextPartyState:	Counter Offer Approved
13.	NextActionParty:	R
14.	TaskPartyArray:
RowNumber - 936
1.	FolderType:	SAFolder_Subro
2.	TaskType:	Demand
3.	Stage:	Negotiation
4.	TaskPartyType:	Responder(R)
5.	PartyState:	Counter Offer Issued
6.	ActionParty:	D
7.	Function:	DemandD_Approve
8.	OperationCode:	B
9.	PreConditionQualifier:
10.	PostConditionQualifier:
11.	NextStage:
12.	NextPartyState:	Pending Response
13.	NextActionParty:	R
14.	TaskPartyArray:
RowNumber - 51
1.	FolderType:	SAFolder_Subro
2.	TaskType:	Arbitration
3.	Stage:	Issued
4.	TaskPartyType:	Demander(D)
5.	PartyState:	Init
6.	ActionParty:	D
7.	Function:	DemandD_Arbitrate
8.	OperationCode:	S
9.	PreConditionQualifier:
10.	PostConditionQualifier:
11.	NextStage:	Arbitration
12.	NextPartyState:	Preparing For Arbitration
13.	NextActionParty:	D
14.	TaskPartyArray:	DR

Background—Inter-Organizational Transaction Processing

[0767] During the 80's and 90's, many business transaction processing systems were focused on integrating business processes and data that existed within an organization (i.e., intra-organization). These systems cover a wide array of business applications, of varying complexity, including production forecasting/scheduling, order processing, human resources management, financial accounting, sales management, etc. Commercial examples of such systems include offerings from SAP, Oracle, and PeopleSoft. Organizations that successfully implemented such systems achieved reduced costs, higher efficiency, and were more competitive. With the intra-organization systems in place, these organizations are now looking to integrate the business processes and data that exist between trading partner organizations (i.e., inter-organizational).

[0768] In 1999 and 2000, a number of web-based “B2B Exchanges” emerged. These virtual marketplaces demonstrated the tremendous value of integrating business processes and data across different organizations. Unfortunately, this technology movement failed due to a fundamental flaw in the concept of the exchange—namely, that while these exchanges were good for buyers (due to reduced prices for goods), the same exchanges were not good for suppliers because of the downward price pressure due to increased competition. The resulting marketplace had many buyers, but no suppliers—hence, the marketplace collapsed.

[0769] Even though this initial B2B movement failed, it clearly demonstrated that substantial cost reductions and greater efficiency could be achieved with systems that automate transaction processing between trading partners (i.e., Inter-Organization Transaction Processing).

Requirements and Challenges

[0770] This section provides an overview of the requirements of an inter-organizational transaction processing system.

[0771] Central Processing Network

[0772] Unlike intra-organization transaction processing (where the transaction processing system can be implemented directly within a given organization), inter-organizational transaction processing requires that information flow through a centralized hub or network (either explicitly or logically). For any given vertical market, this central network is best implemented by a single neutral third-party organization (e.g., a clearinghouse). This facilitates broad participation within a given vertical network by eliminating any data privacy/ownership concerns that would arise if the network were run by one of the dominant organizations within that vertical market.

[0773] In addition, by connecting to the trading community through a centralized network, the numbers of connections that need to be maintained are dramatically reduced when compared to a point-to-point network. With a centralized network, each member maintains only a single connection to the network (rather than maintaining one connection per trading partner).

[0774] Insulation of Member Organizations

[0775] The value of the central network lies in its ability to insulate the member organizations from the implementation details necessary to connect to the network. Rather than creating a single common set of standards that all member organizations must adhere to, the central network facilitates membership by allowing each member organization to communicate and integrate with the network in a manner that best suits the needs and capabilities of that organization. To do so, the network must insulate all member organizations along the following dimensions.

[0776] Connectivity Insulation

[0777] The network must support a wide array of interface capabilities. This allows member organizations with varying technical capabilities to interact with the network. Some organizations will want to interface with the network using fully automated interfaces (communicating message based transaction information), while other less sophisticated organizations will want to interact manually (using a web-based interface). This facilitates broad participation in the network and provides technical interface insulation.

[0778] Data Format and Content Insulation

[0779] Building on the connectivity insulation described above, the network must support a wide array of data formats while maintaining the meaning and content of the application data within the specific vertical market. This allows members to send/receive data elements associated with each business transaction in a format that is native to their local system. To support this requirement, the network will need to perform both format and semantic translations. This reduces the integration requirements further increasing member participation.

[0780] At the heart of this capability is the definition of a “unified data model” which is specific to the vertical market. This data model provides a single target database against which all translations are performed. Simply put, incoming data is transformed from its member specific inbound format to the format prescribed by the unified data model—the same process is performed in reverse for outbound information.

[0781] Business Process Insulation

[0782] The previous requirements allow the members to 1) connect, and 2) exchange data in a consistent manner. With this capability in place, the network must provide a common framework for conducting inter-organizational transactions (inter-organizational workflow) while also insulating each member from the specific business processes and workflows that are unique to their organizations (intra-organization workflow). The common transaction framework will be specific to a given vertical market and defines a common business process that allows all members to communicate consistently about the transactions being processed by the network. For more information on this capability, refer to the related section on “Inter-Organization Workflow Management”.

[0783] In addition, this insulation also ensures for the consistent processing of each transaction. Rather than just passing information from one member to another, the network must provide the application specific processing that is required by a given vertical market. At a minimum, this processing must maintain all data related to the inter-organizational transaction as defined within the unified data model for that market.

Structured and Unstructured Information

[0784] Most automated business systems deal with structured information where the structure of the information is decomposed into related sets of data elements (attributes) that are grouped into data entities. In turn, the data entities are stored within a database management system.

[0785] While structured information is necessary, many inter-organizational transactions involved related information (supporting documents) that exists in unstructured format (e.g., pictures, images, audio, video, etc.). Since most inter-organizational transactions currently occur manually via mail and fax, this related information is usually passed along with any structured information.

[0786] The network must be able to provide storage and retrieval for both structured and unstructured information. And, with respect to unstructured information, it must provide a means of allowing all member organizations to access the unstructured information without substantially increasing technology required to perform such access (i.e., without requiring proprietary access mechanisms for specific types of unstructured information).

[0787] Multi-Party Transactions and Workflow

[0788] While most B2B transactions involve a primary and a counter-party (e.g., Buyer/Supplier, Manufacturer/Customer, Claimer/Claimant, etc.), real-life workflow consists of complex conditional workflow involving multiple parties. Unlike an intra-organization transaction processing system, this multi-party access requirement permeates all aspects of the network's transaction processing capabilities and must be supported.

[0789] Each of the following transaction processing subsystems must account for multi-party access to some extent: Business Rule Evaluation and Processing; Security Organization Structure (Locations); Workflow Management; Transaction Routing Non-Member Access; Pooled Operator Access; Transaction Audit Trail Locking and Reservation (within and between members); Reporting; Document Management; and External Notification.

[0790] Data Privacy and Security

[0791] Finally, since the network will be storing information about each member's transactions, it must provide comprehensive security to ensure that a given organization can only access the transactions and related data elements that it is allowed to access.

Inter-Organization Transaction Processing System

[0792] The Inter-Organization Transaction Processing System consists of an application framework designed to meet the requirements of inter-organizational transaction processing (outlined above). This framework is not dependent on a specific vertical business process or application and is unique in its ability to deal with multi-party transactions that span distinct organizations.

[0793] This framework operates within an overall system architecture consisting of a number of servers working in an integrated manner. This is depicted in FIG. 26, System Architecture.

[0794] The software system that represents this application framework resides within the application server. This system consists of four major areas—Interface Subsystems, Transaction Processing Layer (TPL), System Services, and Application Logic. This structure is depicted in FIG. 27, Application Framework Architecture. Each of these areas is described in more detail below.

[0795] Interface Subsystems

[0796] Transaction requests can originate from many different sources—e.g., manually via a web-based interface, electronically via a message-based interface, internally as a result of native processing, etc. The purpose of the interface subsystem is to support the unique interface requirements of any given source of transaction origination. As new/unique forms of transaction origination evolve (e.g., wireless networks), the system can quickly support new transactions through the creation of new interface subsystems.

[0797] The end result of each subsystem is the same, namely convert the transaction request into an internal object format (an Object Graph) and invoke the services of the TPL to process the transaction request. This centralized transaction processing structure provides the following major benefits. All transaction requests flow through a single common point within the system. Security validation is performed for all transaction requests at a single point (i.e., there is no way to execute a transaction within the system that bypasses security validation). All transaction processing is performed in a consistent manner. A set of common transaction processing services are performed by the TPL (thereby eliminating the need for these to be coded explicitly within the application logic for each transaction).

[0798] The following sections describe the interface subsystems that are provided to support the common methods of transaction origination.

[0799] Online Subsystem (OLS)

[0800] The Online Subsystem is used to support transactions that originate manually via a web-based, HTML-oriented interface. This subsystem can provide supports both a standard server-based web interface or the JView™ subsystem web interface.

[0801] Event Subsystem

[0802] The Event Subsystem is used to support transactions that originate as a result of internal processing by application transaction logic. These transaction requests are processed in the background. For more information, refer to the “Event Management” section.

[0803] Mail Subsystem

[0804] The Mail Subsystem is used to support transactions that originate as a result of the receipt of an incoming e-mail message. This subsystem validates that the incoming e-mail message contains a valid security descriptor, and will then create an event that triggers the transaction request to process the data associated with the incoming e-mail message.

[0805] Batch Subsystem

[0806] The Batch Subsystem is used to support transactions that originate as a result of a pre-defined schedule. This batch schedule is used to define “point in time” transaction requests. For example, this subsystem would be used to trigger a processing request that is to prepare a specific report each night.

[0807] Message Translation Subsystem

[0808] The Message Translation subsystem is designed to communicate with other external system using automated electronic interfaces. This subsystem can handle both incoming and outgoing electronic messages. Incoming messages result in transaction requests that are processed by the TPL. Outgoing messages are generated in response to a specific event processed by the Event Manager. In general, this subsystem supports asynchronous messages (rather than synchronous messages).

[0809] Transaction Processing Layer

[0810] The Transaction Processing Layer is responsible for processing all transaction requests. For each transaction request, this layer will utilize the system services to perform the following: perform transaction security validation; lock the folder (if necessary); perform input data validation (editing functions only); retrieve objects from database; invoke application data model related validation (editing functions only); invoke application transaction related validation (editing functions only); create audit trail events (editing functions only); invoke alert manager to evaluate application business rules and generate alerts (editing functions only); invoke workflow manager to evaluate and set workflow state (editing functions only); save any new or modified data to the database; and unlock the folder (if necessary). These services are described in more detail below in the section “System Services”.

[0811] Application Logic

[0812] For any given vertical market the generic transaction processing capabilities of the system will be extended with the application logic and configuration that is specific to a given vertical market. These application extensions are what give the system its specific vertical market focus. As a result, the generic transaction processing system can service any number of vertical markets. The application logic consists of the following four main parts.

[0813] Unified Data Model

[0814] Mentioned previously, this is the data model that defines the entities and attributes that are specific to a given vertical market.

[0815] Application Logic—Model Related

[0816] For each application specific data entity, application logic can be defined related to validation and processing that is specific to this entity.

[0817] Application Logic—Transaction Related

[0818] For each application specific transaction, application logic can be defined related to validation and processing that is specific to this transaction.

[0819] Configuration

[0820] Many of the generic transaction processing services rely on the definition of external configuration information. This configuration is defined for any given vertical market (and allows the services of the generic transaction processing system to be customized to the specific needs of the vertical market).

[0821] System Services

[0822] The various subsystems and layers described above rely on a rich set of System Services. Some of the major services include: Locking and Reservation; Object Graph Services; Business Rule and Alert Management; Workflow Management; Security Management; Individual and Team Ownership; External Notifications; Snapshot Services; Reporting; and Document Management. These services are described in detail within the System Services Processing section below.

[0823] Prior Art—Acknowledged

This Application Framework relies on the services of the following technologies and acknowledges any prior art in these domains.

[0824]

	Technology	Commercial Examples
	Web Servers	IIS (Microsoft)
		Apache (Open Software Foundation)
	Application Servers	.Net (Microsoft)
		WebLogic (BEA)
		WebSphere (IBM)
		Tomcat (Open Software Foundation)
		WebObjects (Apple)
	B2B Integration Servers	WebMethods (WebMethods)
		BizTalk (Microsoft)
	Database Servers	Oracle (Oracle)
		SQL/Sever (Microsoft)
	Mail Servers	Exchange (Microsoft)

[0825] This Application Framework builds on the capabilities established by these technologies and provides additional services and capabilities specifically target at inter-organizational transaction processing that are not addressed. This structure of a general web-based transaction processing system, and the role of the Application Framework within this structure, is illustrated in FIG. 28.

[0826] This framework is related closely to the above description of the JView™ Subsystem and Inter-Organization Workflow Management.

[0827] Commercial Example

[0828] The Electronic Subrogation Network is a commercial example of a fully operational system that embodies the concepts described herein specifically for the vertical market of Insurance Subrogation Claims Processing.

[0829] Terminology

[0830] This section contains terminology definitions that are useful in understanding the concepts described in this section.

[0831] Folder

[0832] Each distinct business transaction is represented by a folder. The folder is used to logically contain all information related to this transaction (e.g., parties, tasks, documents, contacts, alerts, attachments, events, etc.).

[0833] Party

[0834] A business transaction involves the interaction between two or more parties where, for the purpose of that transaction, each party takes on a specific relationship (described further below). With intra-organization workflow, parties are typically different business units (e.g., division, department, etc.) within the same organization. With inter-organizational workflow, parties are typically different organizations or individuals.

[0835] Relationship (Party Type)

[0836] For each specific type of business transaction (folder), one or more relationships are defined. Each relationship defines the role that a given party will play with respect to that transaction. For example, in a simple order management transaction (Order Folder), one party represents the “Buyer” and one party represents the “Supplier”. As such, for each party defined on the folder, that party's relationship to the transaction is referred to as their party type.

[0837] Tasks

[0838] A task is used to represent an independent business activity (related to the transaction for this folder). Each folder must have at least one task (its primary task). With complex business processes, multiple tasks are used within the folder to manage and track multiple parallel activities related to a given business transaction. For example, for an order management transaction (Order Folder), one task is defined for the order itself, and additional tasks are defined for each distinct shipment/invoice.

[0839] Action Party

[0840] For each task on the folder, the party responsible for taking the next action related to that business activity is referred to as the action party. When the business transaction is concluded, no further business activity will occur. At this point, no action party will exist on any tasks within the folder.

[0841] Function

[0842] Each operation that can be performed on the folder, that affects the information or status of the folder, is referred to as a function. Based on the folder, certain functions can only be performed by a specific party type, while others can be performed by some or all party types. In a simple order management transaction some examples of functions include: issuing a purchase order (buyer), accepting an initial order (supplier), creating a shipment/invoice (supplier), etc.

[0843] Two main types of functions exist—editing functions and non-editing functions. Editing functions result in the modification of business data within the database; non-editing functions do not (i.e., essentially non-editing functions are only used to retrieve data).

[0844] Function definitions are contained within the system configuration tables. Each Function definition contains settings that control the processing of the transaction requests (e.g., editing type, party type, object graph specification, etc.). The collection of Function definitions within the system are specific to a given vertical market and essentially define the business processing capabilities of the system.

[0845] Organization

[0846] Two distinct legal entities (e.g., companies) as opposed to different business units (of arbitrary size) within a single legal entity.

[0847] Workflow

[0848] A defined set of business operations and/or processes, triggered by an initial business event (business transaction), that proceed in a specific sequence or order, and culminating in a conclusion or completion of the transaction. A simple workflow will follow a prescribed set of operations in sequence to conclusion (single path). A complex workflow will contain multiple conditional paths, only one of which will be taken based on the business conditions present in the transaction.

[0849] Inter-Organization Workflow

[0850] A workflow that exists between two organizations for the purpose of conducting/completing a business process/transaction specific to those organizations.

[0851] Object Graph Specification (OGS)

[0852] A set of configuration data that defines the set of data entities and attributes, and their object structure, used for a given transaction request (i.e., function). The TPL uses the OGS to ensure that a given party only can send or receive data elements allowed for their party type. Additionally, this mechanism can also be used to further constrain data access based on a specific user role (within a party type).

[0853] Role

[0854] A set of configuration data that defines a group of functions. The resulting set of functions can then be associated with an operator or automated system. The Security Management services will use the role definition to limit the functions that can be performed by a given operator or system.

Detailed Description—Inter-Organizational Transaction Processing

[0855] The Inter-Organization Transaction Processing System (henceforth referred to as the Application Framework or just A/F) consists of an application framework designed to meet the requirements of inter-organizational transaction processing (outlined above). This framework is not dependent on a specific vertical business process or application and is unique in its ability to deal with multi-party transactions that span distinct organizations.

[0856] This section contains detailed process and component descriptions related to the A/F. This discussion presumes familiarity with the following concepts and technologies:

• • [0857] general business-oriented transaction processing concepts
  • [0858] object-oriented design and programming
  • [0859] basic internet fundamentals

[0860] The A/F described in this section has been validated against the following vertical business application contexts:

• • [0861] Insurance—Subrogation claims (Demands, Responses, Arbitration Filings, etc.);
  • [0862] Manufacturing—Order Processing (Purchase Orders, Shipping, Invoicing, Returns, etc.);
  • [0863] Retail—Store Management (Labor Scheduling, Employee Maintenance, Timecard Tracking, etc.); and
  • [0864] General—Call Logging and Problem Management.
    Overview

[0865] Core Object Model and Structures

[0866] The A/F includes a core object model that provides a set of foundational classes and data entities used for constructing applications. The core objects within this model are typically used in most applications. Additional objects, specific to the A/F, allow the system to perform its control operations within the context of inter-organizational transaction processing. When constructing an application, these objects can be used as is, or subclassed to support application specific extensions.

[0867] The objects within the core object model can be grouped into three major categories—transactional objects, configuration objects, and system objects. The transactional objects represent the application or transaction control structures within the business transactions being processed by the system. The configuration objects represent the configuration structures, used by the A/F at runtime, that define the specific processing characteristics of each vertical application. The system objects represent internal system structures that are used to control the internal operation of the system.

[0868] Transactional Objects

[0869]

Class/Entity Name	Summary
SAFolder	Abstract. The generic container for all
	data related to a given transaction.
SAFolderData	Abstract. This class is used to support
	application specific extensions to a folder.
SAParty	The organization or individual involved
	in a given transaction.
SADocument	Abstract. A set of structured data elements
	related to a transaction.
SAAttachment	Abstract. A set of structured meta-data
	related about a set of unstructured data
	(see SAAttachmentData).
SAAttachmentData	A set of unstructured data related to a
	transaction (e.g., graphics, photos, etc.).
SAComment	A free-form comment related to a document
	within a transaction.
SAContact	A set of name and/or address information
	related to a contact within a transaction.
SADocContact	A relational object that connects a document
	with a contact.
SAAlert	A business condition that exists within
	a given transaction.
SAEvent	Audit information that provides a record
	of every modification to the folder contents.
SASnapshot	A blob of information that contains a complete
	set of folder information at a given point
	in time (i.e., a snapshot). This object is
	used to maintain a historical record of all
	data modifications to the folder.
SATask	A business activity that is occurring within
	the folder.

[0870] Configuration Objects

[0871]

Class/Entity Name	Summary
SAFunction	An application function (transaction)
	that is supported by the system (external).
SAIntrinsicFunction	An application function (transaction)
	that is supported by the system (internal).
SAIntrinsic	A primitive (intrinsic) transaction
	processing function supported within
	the application software classes.
SACompany	An organization or individual that can
	participate in transactions within the
	vertical application.
SAGroup	Within a Company, a group or team of
	individuals at a Location.
SALocation	Within a Company, a physical office or
	location.
SAOperator	Within a Company, a person (or account)
	that can access the system.
SARole	Within a Company, a group of related
	application functions that are needed
	to perform a specific job or role within
	a Company.
SARoleFunction	Relates a specific Function to a
	specific Role.
SAAlertRuleTemplate	A template that defines a generic type
	of business rule that can be evaluated
	by the system
SAAlertRule	A business rule used to evaluate a
	specific business condition for a
	specific company.
SADocContactTemplate	A template that defines a generic type
	of document contact.
SADomain	A set of application specific values
	that define an application domain.
SAEventTemplate	A template that defines the processing
	characteristics for an Event.
SAMessageTemplate	A template that defines the processing
	characteristics for a Message.
SANotificationRule	A system rule that defines the processing
	characteristics used for generating an
	external notification based on the
	occurrence of an event.
SAObjectGraphSpec	In a transaction template the constrains,
	the data entities, and attributes that
	can be exchanged/processed within a
	given transaction.
SAWorkflow	A template used by the Workflow Manager
	to control the workflow of a transactional
	folder.
SAWorkflowRule	A company specific workflow rule used
	by the Workflow Manager to perform
	intra-company workflow.
SAWorkflowRuleTemplate	A template that defines a generic company
	specific workflow function that can be
	performed by the Workflow Manager.