Abstract:
In a complex workflow environment, a data-type-definition (DTD) schema drives a dynamic business component instantiation and execution framework that integrates documents with data and information created by various applications, potentially operating on several different platforms, enabling complex workflow and collaboration to occur over a communication network such as the Internet. The DTD execution language is preferably an industry specific XML-based tag set that defines business component instantiation, execution, input and output parameters, workflow, user profile, and collaboration specifications for a given task or data in a complex workflow process. Business and data processing components available on systems both within and outside the complex workflow system are called upon to provide the processing, interpretation, and transformation functions for the complex workflow system. The results of such processing are then returned to the complex workflow system for integration within the workflow process.

Description:
CROSS REFERENCE TO RELATED APPLICATIONS  
       [0001]    This application claims the benefit of priority of U.S. provisional application serial No. 60/283,701 filed Apr. 12, 2001 entitled Data-Type Definition Driven Dynamic Business Component Instantiation and Execution Framework, which is hereby incorporated by reference as though fully set forth herein. This application is related to U.S. application Ser. No. 09/672,938 filed Sep. 28, 2000 entitled Process and System for Matching Buyers and Sellers of Goods and/or Services, and U.S. application Ser. No. 09/801,106 filed Mar. 6, 2001 entitled Method and Process for Providing Relevant Data, Comparing Proposal Alternatives, and Reconciling Proposals, Invoices, and Purchase Orders with Actual Costs in a Workflow Process, each of which are hereby incorporated by reference as though fully set forth herein. 
     
    
     
       BACKGROUND OF THE INVENTION  
         [0002]    1. Field of the Invention  
           [0003]    This invention relates generally to the use of data-type definition language to identify types of electronic files and provide functional instructions for the processing of such files. The invention further relates to systems for managing workflow processes over a communication network.  
           [0004]    2. Description of the Related Art  
           [0005]    Present systems for enhancing business workflow, whether intra-business or inter-business are generally limited to the scope of the information subject matter they were designed to address. For example, some accounting systems have the ability to import information from external sources in order to manipulate it according to the processes and constructs of that system. Some systems have integrated even more categories of business information to provide more comprehensive tracking and business management capabilities for the user. For example, available “enterprise software” applications track not only accounting information, but also sales, inventory, pricing, shipping, and other information in a single, integrated environment.  
           [0006]    The limitation of these systems is that information provided to these systems must be in a format that is recognizable and manipulable by the systems. In many instances, the information must be entered in a system specific environment in order to be recognized and processed by the system. Further, many of the more complex systems integrating various and previously disparate functions require the components of the systems to constantly monitor the information flowing through the system to determine whether that information is relevant to that component and therefore whether that component must then perform some function.  
           [0007]    Many of these systems take the form of a hub and spoke network as seen in prior art FIG. A. For example, an enterprise integration system could have a hub for routing information from one application to the others on the network. A hub contains multiple ports and is used to connect segments of the network. When an information packet arrives at one port, it is copied to the other ports so that all enterprise applications on the network can see all packets. A hub serves simply as a conduit for the data, enabling it to go from one application on the network to another. In this example, when an order is entered in the ordering interface application, the hub publishes the order to each of the other applications in the network. The accounting application monitoring the network may capture the order information transmitted by the hub to store it for future action. Upon receiving the order information, the inventory database application may reduce the inventory a corresponding quantity and publish the reduction to the hub. The accounting application, with receipt of the inventory publication from the hub, now knows that the order can be fulfilled and then uses the order information previously received to credit the ledger.  
           [0008]    However, the shipping application may not be activated by the order information inherently received from the hub. Instead the shipping application waits for information from the inventory application before initiating shipping arrangements, because if there is no product in inventory there is nothing to ship. The shipping application may then publish shipping costs to the hub, which are transmitted to all applications on the network. While the inventory and ordering applications do not need the shipping information received, the accounting application debits the shipping costs to the ledger when the shipping information is received to populate and maintain the business books. In a hub and spoke system, therefore, any information received at the hub is published to all other applications on the network, regardless of whether they have use for the information. The applications are in constant communication with the hub to monitor for relevant incoming information that indicates that they must take action. This constant publication and monitoring can result in bottlenecks in the network.  
           [0009]    Another prior art system is a channel-based enterprise integration model as shown in prior art FIG. B. An example using business process systems integrating accounting, ordering, shipping, and inventory modules is again depicted. In a channel model, instead of a hub operating to serve as a focal point for the distribution of incoming information, different applications subscribe to one or more channels to monitor for or to publish an event. For example, an event might be an “order entered” published by the ordering application to this channel. All other applications with an interest in an “order entered” event would subscribe to monitor that particular channel. For example, an inventory application would subscribe to the “order entered” channel in order to check the inventory database to ensure that the order entered is available in inventory. If the item ordered was available, the inventory application could publish to another channel called “fulfill order” to which a shipping application could be a subscriber. This can be a waste of significant resources in terms of processing power and bandwidth for communications. By creating specific channels for specific events, the channel model helps avoid the bottleneck drawback of the hub and spoke model. However, applications in the channel model must still maintain a constant connection with subscription channels to monitor for pertinent new information.  
         SUMMARY OF THE INVENTION  
         [0010]    In a complex workflow system, it is desirable to integrate documents with data and information created by various applications, perhaps even operating on several different platforms. Integration of such documents in the complex workflow system may be difficult because the workflow system may not have the necessary components or applications to process, interpret, or transform the data in the documents into data manageable by the workflow system. Further, creating or integrating the necessary components or applications for processing and interpreting the documents can be extremely time and resource consuming and a significant expense; in fact it may be never-ending. On the other hand, the information contained in such files could be very valuable to the complex workflow process.  
           [0011]    In order to integrate the information in such files into the complex workflow environment, an XML-driven dynamic business component instantiation and execution framework is created, enabling complex workflow and collaboration to occur over a communication network, for example, the Internet. Business and data processing components available on systems both within and outside the complex workflow system are called upon to provide the processing, interpretation, and transformation functions for the complex workflow system. The results of such processing are then returned to the complex workflow system for integration within the workflow process. In this way, the complex workflow system maintains a focus on the workflow process, rather than branching out into other tangential processing functions.  
           [0012]    A data-type-definition (DTD) or schema, preferably an extensible mark-up language (XML) schema, is contemplated for the consistent, dynamic exchange of complex services data via valid DTD encoded documents. These DTDs provided for documents can be global or industry specific depending upon the processes desired by any particular workflow system. The DTD execution language is preferably an XML-based tag set that defines business component instantiation, execution, input and output parameters, workflow, user profile, and collaboration specifications for a given task or data in a complex workflow process. A language execution broker matches incoming DTD documents with appropriate processing instructions, also preferably identified by DTDs, and dispatches the documents and instructions to a processor selection component, for example, a dynamic plug-and-play (PNP) engine, for execution.  
           [0013]    The PNP engine then executes the instructions in the DTD document by calling upon the necessary processing objects or components, either internal or external on third party processing systems. The PNP engine either calls a local object or routes the DTD document and instructions to an external application. The PNP engine also orchestrates the processing flow and collaboration with the external components as defined by the particular DTD document and instructions. The PNP engine preferably interfaces in an object-oriented environment such that objects, applications, and other components called upon by the PNP engine can be added, removed, or updated dynamically without affecting the functionality of the PNP engine. 
       
    
    
     BRIEF DESCRIPTION OF THE DRAWINGS  
       [0014]    FIG. A is a prior art diagram of exemplary components of a hub and spoke business component integration system.  
         [0015]    FIG. B is a prior art diagram of exemplary components of a channel linked business component integration system.  
         [0016]    [0016]FIG. 1 is a flow diagram of the components of a framework for providing dynamic business component instantiation and execution in the present inventive system to process data and information in a complex workflow environment.  
         [0017]    [0017]FIGS. 2A and 2B depict a flow diagram of the process implemented according to the present invention for routing and processing information.  
         [0018]    [0018]FIG. 3 is an exemplary representation of a preferred embodiment XML data-type definition document as used by the systems and processes of the present invention.  
         [0019]    [0019]FIG. 4 is a relationship diagram depicting the relationship between process functions in a preferred embodiment applying the methods of the present invention.  
         [0020]    [0020]FIG. 5 is a logic diagram indicating the decisions made in determining the path to take between the functions of FIG. 4. 
     
    
     DETAILED DESCRIPTION OF THE INVENTION  
       [0021]    The interaction of the components of the dynamic DTD processing system  100  is shown in FIG. 1. A user initiates a connection with a complex workflow platform  120  over a communication network  115  through a user interface device  105 . The communication network is preferably the Internet, but it can likewise be any other sort of communication network, for example, an intranet, an extranet, a local area network, a wide area network, a public network, and a private network. The user interface device  105  can be any sort of processor device with the ability to connect to the communication network and transmit data, for example, a personal computer or a computer workstation. The user interface device could also be a wireless device such as a personal digital assistant (PDA), a wireless telephone, a web pad, or other wireless device. If the user interface device  105  has the capability to directly connect to the communication network, the transfer of information to the complex workflow platform  120  can be immediate. For example, the complex workflow platform  120  may provide web-based templates and documents from its system server  125  for the user to directly access and populate with information via a web browser on the user interface device.  
         [0022]    In other instances, the user may not be able to directly access the complex workflow platform and the transfer of information may be delayed. For example, a user with a PDA may work on browser-based documents while offline, using XML or other DTD-based browser generation and data storage processes instead of server-based. The information entered into these documents may be stored on the PDA as, for example, XML documents until the user has access to a network. The user then has two options: 1) to directly synchronize document information from the PDA over a connection with the communication network  115  with project or document information already residing on the system server  125 ; or 2) to first synchronize the information on the PDA with a desktop personal computer utilizing synchronization client software or any other appropriate application, and then to synchronize with the system server  125  from the desktop computer. The synchronization and transmission preferably takes place via secure socket layer connections between the user interface device  105  and the system server  125 .  
         [0023]    The data, information, object, application, relational data structure, or other file type (herein referred to individually as a “document” or collectively as “documents”) prepared by a user and transmitted from the user interface device  105  is preferably tagged with DTD information. In the preferred embodiment the DTD language used is XML and the user transmitted documents referred to herein are XML tagged documents  110 . An XML tagged document  110  can be generated within a client application correlative to the complex workflow platform  120  environment, or by any other application. An XML tagged document  110  may likewise be generated on the system server  125  within the complex workflow platform  120 , for example, via user input into web-based templates resident on the system server  125 . In a preferred embodiment the XML tags are taken from a particular set that defines business component instantiation and execution, input and output parameters, and workflow and collaboration specifications for a given complex workflow process. An XML tagged document  110  preferably has at minimum an “XML set” tag to identify the particular industry XML subset, and a “document type” tag that would be used to match the document with appropriate XML based processing instructions. Other sets of DTD language constructs may be used to tag documents for performance within the scope of this invention.  
         [0024]    A specific instantiation of a preferred complex workflow platform  120  is the workflow system for the upstream oil and gas industry disclosed in two prior, related U.S. patent applications identified by Ser. No. 09/672,938 filed Sep. 28, 2000 entitled Process and System for Matching Buyers and Sellers of Goods and/or Services, and Ser. No. 09/801,106 filed Mar. 6, 2001 entitled Method and Process for Providing Relevant Data, Comparing Proposal Alternatives, and Reconciling Proposals, Invoices, and Purchase Orders with Actual Costs in a Workflow Process. The XML tagged documents  110  in such an embodiment preferably adhere to a specific subset of XML to provide deep vertical integration within the oil and gas industry. Such an XML subset called WellXML™ has been proposed and developed by Wellogix, Inc. of Houston, Tex. An exemplary XML tagged document  110  using WellXML™ tags is shown in FIG. 3.  
         [0025]    The XML tagged document1 110 of FIG. 3 begins with a subset identification  300  of the particular XML subset in which the document is coded, in this case “wellXML.” Additionally, a document type identifier  310  is present to provide the document type, which is generally industry and XML subset specific. The document type  310  is a minimal indication to the complex workflow platform of the process requirements for the document. In this example, the document type is “&lt;dailyDrillingReport&gt;.” Other tags in the XML tagged document  110  include specific data types  320  (“&lt;holeSummary&gt;”) and  324  (“&lt;casingSummary&gt;”), each of which further include multiple data fields  322  and  326  such as input parameters and others. The data types  320 ,  324  and data fields  322 ,  326  provide additional information for use in processing the XML tagged document  110 . A further XML tag may provide a user profile  340  (“&lt;operational&gt;”) indicating information about the user that can be used to provide processing routines specific to that user. The data structure of the XML tagged document  110  may be thought of as an “envelope.” The data transferred in the document is wrapped (or enveloped) in XML tags that identify the nature of the document, the identity of the sender, processing instructions, and an addressee for transmission; it further may contain return address information.  
         [0026]    Returning to FIG. 1, the complex workflow platform  120  is composed of a system server  125  that interfaces with users via the communication network  115  to facilitate the transfer of documents and other data generated by a user at a user interface device  105 . The complex workflow platform further preferably has a synchronization server  130  that constantly checks for incoming XML tagged documents  110  at the system server  125  and coordinates the processing of the documents  110  in the workflow platform  120 . The synchronization server  130  may either pass the XML tagged document  110  to a predetermined holding repository  135  or forward the XML tagged document  110  directly to a language execution broker  140  upon reception. The XML tagged document  110  does not necessarily have to be placed in the repository  135 , but such placement may be preferred if there is not an urgent need for processing the document or it is known that processing is not immediately possible.  
         [0027]    The language execution broker  140  reads the tags on the XML tagged document  110  and, if necessary, provides additional information or instructions in order to ensure appropriate processing of the XML tagged document  110 . The language execution broker  140  initially reads the “document type”  310  of the incoming XML tagged document  110 , matches it with the appropriate XML-based processing instruction set, and forwards these two documents to the PNP engine  145  for processing. The XML based processing set contains key processing information, for example: the name of the component, application, or software object (hereinafter collectively “component(s)”) that processes the incoming document; the methods of that component that should be executed; the location of the component, either within the complex workflow platform  120  or accessible over the network  115 ; the input and output parameters for the particular component; and if more than one component is needed to process the incoming document, the processing set provided by the language execution broker  140  includes instructions for orchestrating the workflow between the components. Any additional instructions determined by the language execution broker are attached to the XML tagged document  110  as it is routed for additional processing.  
         [0028]    With reference to the exemplary XML tagged document of FIG. 3, the functions of the language execution broker  140  can be further detailed. Again, in this example, the subset identification  300  is “wellXML” so the language execution broker  140  knows to look for processing instructions related only to the “wellXML” subset. The language execution broker next notes the document type  310 , which in this example is “&lt;dailyDrillingReport&gt;.” If certain standard processes are generally applied to a “(dailyDrillingReport)” document, the language execution broker  140  attaches these instructions. Also, if there are user profile tags  340  as part of the document, these may indicate to the language execution broker  140  that user specific processing components are desired and should be chosen over general components used for that document type  310  or data type  320 ,  324 . In addition to processes linked to the document type  310 , the document further includes the data types  320  and  324  that the language execution broker may recognize as requiring additional specific processing components. In fact, based upon the data types  320  in a particular document, the process results for a first data type may be required by the methods of the component processing a second data type. In this case the instructions provided by the language execution broker may dictate an order for processing various document types  310  or data types  320  and  324 , or the instructions may indicate that the process results for one data type be saved for use in future processing calls to other components. For example, the component processing the “&lt;holeSummary&gt;” data type  320  may require process results from the component that processed the “&lt;casingSummary&gt;” data type  324 . Therefore, the language execution broker  140  may instruct that the “&lt;casingSummary&gt;” data type  324  be processed first.  
         [0029]    After the language execution broker  140  has matched the XML tagged document  110  with the appropriate XML language processes, it then dispatches the document, along with the processing information, to the dynamic Plug and Play (PNP) engine  145  for execution. The PNP engine  145  executes the instructions in the XML tagged document  110 , and in any further attachments thereto generated by the language execution broker  140 , by dynamically calling upon the necessary business component found in either an internal component of the complex workflow platform  120  or an external processing system  150 , and orchestrating the entire workflow and collaboration process as defined by the particular XML tagged document  110 . The PNP engine can interface with numerous external processing systems  150  that have many and varied business component processes in order to appropriately process the XML tagged document  110  for use by the complex workflow system  120 . The PNP engine  145  contacts the desired external processing systems  150  as needed and transmits the XML tagged document  110  and supporting instructions for processing.  
         [0030]    The PNP engine  145  uses the XML-based processing instructions in its dynamic instantiation and execution of external processing systems  150 . The PNP engine  145  makes the appropriate dynamic component calls depending upon the nature of the external processing system  150 . For example, the PNP engine  145  can simply transmit the necessary information from the XML tagged document  110  and from any additional XML instructions as XML via hypertext transfer protocol (HTTP) if the external processing system  150  is a simple object access protocol (SOAP) enabled web service or related architecture. In this case the PNP engine  145  would contact the external processing system  150  by its uniform resource locator (URL) and request, using web services description language (WSDL), the data variables needed by the processing system  150  and the expected data type return after processing. Once this information is known the PNP engine  145  sends the appropriate XML tagged data to the URL for processing and provides a URL for return of the process result to the PNP engine  145 .  
         [0031]    Other methodologies for calling external processing systems into service may be used by the PNP engine  145 . A second exemplary method is through dynamic Java® component instantiation using reflection- and introspection-based components. Briefly, this is a Java® construct wherein the PNP engine  145  asks an object about itself and the object returns information about the functions it performs, the input parameters it requires, and the output parameters it provides. This allows the PNP engine  145  to determine what data to provide to the object for processing. A third exemplary method is to use Java® native interface capabilities to similarly ask a non-Java® component (e.g., C, C++) how to instantiate itself and what input parameters it requires. A fourth exemplary method employs Java database connectivity (JDBC) to interface with all JDBC enabled databases. The connectivity protocol allows the PNP engine  145  access to a database to determine requirements for start procedures in the database, call methods, and input and output parameters. This method also allows for both structured query language (SQL) calls and access to stored procedures.  
         [0032]    None of the external processing systems  150  needs to monitor the PNP engine  145  for data that they have the ability to process. Rather, the PNP engine  145  contacts only an external processing system  150  with desired business components, which is then instantiated for processing the XML tagged documents  110 . The XML tagged document  110  can therefore originate from any application or platform. However, with the identification of the XML tags, the PNP engine  145  can chose an appropriate internal component or external processing system  150  to process the XML tagged document  110  according to the instructions defined therein and provide resulting information, or the document itself, in a format that can be integrated into the workflow process of the complex workflow system  120 .  
         [0033]    [0033]FIGS. 2A and 2B depict the routing and processing steps of the XML tagged document  110  through the dynamic DTD processing system  100 . At step  200  the XML tagged document  110  is received at the system server  125 . The synchronization server  130 , which is constantly monitoring the data exchanges by the system server  125 , determines whether an incoming document has an XML tag, step  205 . If not, the document is processed through the normal functions of the complex workflow system  120 , step  210 , and integrated into the workflow process of the complex workflow system  120 , step  270 . If the document is determined by the synchronization server  130  to be an XML tagged document  110 , the synchronization server  130  accesses the XML tagged document  110  from the system server and determines whether immediate processing is required, step  215 . If it is determined that no immediate processing is necessary, the synchronization server  130  stores the XML tagged document  110  in a repository for delayed processing step  220 .  
         [0034]    If immediate processing of the XML tagged document  110  is necessary for the operation of the complex workflow system, or otherwise desired, or if it is appropriate for an XML tagged document  110  stored in the repository to be processed, the function moves to step  225 . At step  225 , the language execution broker  140 , to which the XML tagged document  110  is passed by the synchronization server  130 , determines the processing requirements of the XML tagged document  110  based upon the information provided about the document  110  in the XML tag. The language execution broker  140  attaches any necessary additional processing information for the XML tagged document  110  document, based upon the XML tags, step  230  and then routes the XML tagged document  110  and any additional processing instructions, to the PNP engine  145 , step  235 .  
         [0035]    The PNP engine  145  next determines the appropriate business component to instantiate to process the XML tagged document  110  according to the instructions provided in the XML tags, step  240 . The PNP engine queries whether the appropriate business component is internal to the complex workflow system, step  245 . If the complex workflow system has the ability to process the XML tagged document  110  document internally, the document  110  is routed within the complex workflow system  120  to the appropriate component for processing. Once processed, the document  110 , or the information or data therein, is integrated into the workflow process of the complex workflow system  120 , step  270 .  
         [0036]    If the XML tagged document  110  cannot be processed internally, the PNP engine  145  contacts an appropriate business component on an external system  150  to instantiate it for processing XML tagged document  110 , step  255 . The XML tagged document  110  is transmitted over the communication network  115  to the business component of the external processing system  150 . Once the XML tagged document  110  has been processed by the chosen external processing system  150 , the processed document  110  is returned to the PNP engine  145  over the communication network  115 , step  265 , and integrated into the workflow process of the complex workflow system  120 , step  270 .  
         [0037]    In addition to providing for the dynamic instantiation of external components for processing data used by the dynamic DTD processing system  100 , the methodologies disclosed also provide an ability for users who are not able to use the complex workflow platform  120 , or who have documents that cannot be created within the complex workflow platform  120 , to interface with other users. FIG. 4 shows various possibilities for users of the system in the preferred oil and gas industry embodiment, referenced previously, to interact through the assistance of the DTD dynamic processing system  100 . In the preferred oil and gas embodiment, a buyer generally initiates a request for a quote from a seller of goods or services by preparing a request on the complex workflow platform  120  through an interface, block  400 . In this case the DTD processing system  100  on the platform  120  tags the data and documents in the request and creates various XML communication envelopes. These communication envelopes are inserted into an entire request package for submission to a seller of the desired goods or services, block  420 . There may be a situation, however, where the buyer is unable to enter his request directly through the platform  120 , and instead creates a request for goods and services outside the platform, block  410 . If the buyer appropriately tags the documents in the request with the industry specific DTD language subset to create communication envelopes recognizable by the system  100 , the externally created envelopes can similarly be inserted into a request package for submission to a seller, block  420 .  
         [0038]    Normally then, the seller would be notified by the complex workflow platform  120  that a request is available for review, and the seller would review the data and documents in the request through the seller&#39;s interface with the platform  120 , block  430 . In this case as well, the communication envelopes in the request would be processed by the DTD dynamic processing system  100 . As an alternative, if the seller is not part of the complex workflow platform, the communication envelopes may simply be passed by the platform  120  to the seller&#39;s external system for processing and review by the seller external to the platform  120 . In this instance, the DTD dynamic processing system  100  might not actually process the envelopes for the seller, but merely route them to the seller for external processing, block  450 .  
         [0039]    A response by a seller to a request by a buyer is normally prepared within the complex workflow platform  120  via inputs from the seller through an interface, block  440 . The DTD dynamic processing system  100  appropriately tags response documents and inserts the envelopes created into a response package made available to the buyer, block  460 . However, in the event the seller is external to the platform  120 , the seller may still pass appropriately tagged documents to the platform  120 , block  450 , which will be recognized by the DTD dynamic processing system and inserted in to a response package to be made available to the buyer, block  460 . Again, normally the buyer would be notified that a response to a request is available and review the response as processed by the DTD dynamic processing system  100  within the platform  120  through a user interface, block  470 . However, in the event the buyer is external to the complex workflow platform  120 , the response package may merely be routed to the buyer&#39;s external system for processing and review by the buyer system. In this way, through the use of the tagged documents in communication envelopes, the workflow processes of the platform  120  are made accessible to a greater body of users. This may be desirable for users who, for example, would rather use their own, perhaps proprietary, processing systems to analyze the data and documents, but still want the opportunity to interface with other users through the complex workflow platform  120 .  
         [0040]    [0040]FIG. 5 is a logic flow for the routing performed between the process functions described with reference to FIG. 4. The system  100  first determines whether the buyer request is originated external to the platform  120 , step  500 . If the request is external, the related envelopes are simply passed and inserted into the request package, step  520 . If the request is originated within the platform  120 , the DTD dynamic processing system  100  must tag the documents, step  510 , to create the envelopes that are then inserted into the request package, step  520 . The logic next determines whether a particular seller is external to the system, step  530 , (e.g., the seller desires to perform its own document processing). If so, the request package is routed directly to the seller for external review and processing, step  540 . If the seller interfaces with the platform  120  and uses its processing functions, the seller is notified of the request for review and response preparation within the DTD dynamic processing system  100 , step  550 .  
         [0041]    Whether the response documents are prepared within the system  100  or on a seller&#39;s external system, the DTD dynamic processing system  100  inserts the prepared envelopes into a response package for provision to the buyer, step  560 . The logic then queries whether the buyer is external to the platform  120 , step  570 . If not, the DTD dynamic processing system  100  processes the response package and the buyer reviews the response within the platform  120  via an interface, step  580 . If the buyer is external to the platform  120 , the system  100  recognizes that it need not perform any processing and merely routes the envelopes comprising the response package to the buyer system for processing and review, step  590 .  
         [0042]    Although various embodiments of this invention have been described above with a certain degree of particularity, or with reference to one or more individual embodiments, those skilled in the art could make numerous alterations to the disclosed embodiments without departing from the spirit or scope of this invention. It is intended that all matter contained in the above description and shown in the accompanying drawings shall be interpreted as illustrative only of particular embodiments and not limiting. Changes in detail or structure may be made without departing from the basic elements of the invention as defined in the following claims.