Title of Invention

A REAL-TIME TRANSACTION ORDER MANAGEMENT SYSTEM AND A METHOD OF MANAGING TRANSACTION ORDERS IN REAL-TIME.

Abstract In the field of transaction processing, a real-time transaction order management system that enables a plurality of entities to cooperatively process a transaction order is disclosed. The system comprises a communications network and a central repository (102). The system also includes a central repository controller (270). A system administrator controls the central repository (102) by configuring the central repository controller (270) to selectively enable and permit deposits of, access to, and modification of the contents of the central repository (102) by other entities. A transaction initiator (120) initiates cooperative processing of the transaction order by depositing transaction order attribute information into the central repository (102). At least one participant selectively accesses and modifies ongoing attribute and status information while processing the transaction order through remote real-time interaction on demand with the central repository controller (270) via the communications network.
Full Text A REAL-TIME TRANSACTION ORDER MANAGEMENT SYSTEM AND A METHOD OF MANAGING TRANSACTION ORDERS IN REAL-TIME"
TECHNICAL FIELD
The present invention relates to a real-time transaction order management system and a method of managing transaction orders in real-time and methods for providing business fulfillment of many-to-many relationships among independent participating entities.
Background Information
Business entities function and thrive on acquiring and serving customers. Generally speaking, the more options a business entity has to acquire and serve customers, the more likely it will be successful as a business. Cooperation among separate and independent business entities can create more options for customer acquisition and service, greater customer satisfaction, and success for a cooperating business entity. Unfortunately, there exist many barriers to efficient, effective, and scalable cooperation among independent business entities.
With previous approaches, such a cooperative effort could add significant complexity, inefficiency, and uncertainty to the process of serving customers. Particular cooperative efforts that have high overhead costs may require high transaction volume to reduce the per transaction . costs enough to enable profitability. The pertransaction costs of other cooperative efforts may prevent profitability at any scalable volume. Other cooperative efforts may simply not be scalable to any profitable level. Efforts that require high volume to be profitable often require higher risks.
Barriers to efficiency stem from the differences in the methods and systems employed by independent businesses to serve their customers, and the differing localities from which each business operates. These differences create discontinuities with the control and flow of information between cooperating entities. These information flow discontinuities prevent efficient synchronization of effort required for profitability, especially at low volumes. Low volume profitability greatly reduces the financial risk of an inter-business cooperative effort.
Various attempts have been made to overcome these inter-business entity inefficiencies. One approach, electronic data interchange (EDI), stores and transfers transaction order


-2-
information in bulk on a periodic basis between entities. Another approach makes use of facsimile machines to communicate individual requisition orders from merchants to suppliers, shipping instructions to carriers, and invoices back to customers or merchants. Yet another approach custom formats and reformats route data associated with a transaction order to various merchant, supplier, and carrier specific computer systems. Each business entity views the transaction data custom formatted to their particular computer system specifications.
All of the above approaches suffer from the associated discontinuities in the flow of current collective information required to support real-time synchronization of effort to support efficiency at low volumes. Furthermore, some approaches require some level of human intervention per transaction, which can cause the transaction to be error prone, costly, and constrained in terms of scalability and volume.
In all of the previous approaches, each participant's knowledge and efforts are delayed until the transaction order information is received. Furthermore, each participant has no current knowledge of the status of the transaction order outside the scope of each participant's involvement. For example, a supplier may have picked an item from inventory, and possibly shipped it, not knowing that the customer had cancelled the order. Or, the supplier may later discover a problem with inventory and not be able to satisfy an order already acknowledged to the merchant as being in stock. The supplier cannot anticipate the receipt of products already returned by customers. Each participant is uninformed as to events associated with other participants as they happen and are delayed until after the transfer of information is made. Delayed and limited access to transaction order status can have unexpected and inefficient consequences.
Furthermore, each approach is centric to one participating entity responsible for formatting and communicating the order information to other entity participants. At most, this approach can support one-to-many relationships, for example, centric to one merchant with multiple suppliers or centric to one supplier with multiple merchants. When centric to one merchant, that merchant would not be motivated to service other merchants, such as reformatting and routing data, especially for competitors. The same can be said for suppliers. The scalability of this approach is limited to the motivation of the controlling participant. The controlling participant is most informed, but not totally informed. Other participants must wait until



-3-
transaction order data arrives. Some aspects of these methods, such as handling customer returned items, render dealing with low volume cooperative participants unprofitable.
Summary Of The Invention
Generally, the invention solves the problems outlined above by creating a central repository that contains current transaction order attribute and status information that is real-time accessible by all participants. Participants may be independent business entities cooperating to process a transaction order. Each participant can be promptly informed of relevant events and actions associated with the transaction order that occur outside of their scope of participation. Likewise, each participant updates the repository with events and actions occurring within then-own scope of participation to inform other participants outside the scope of their participation.
In one aspect, the invention is a real-time transaction order management system for enabling a plurality of independent entities to cooperatively process a transaction order. The system includes a communications network, a central repository containing ongoing transaction order attribute and status information, and a central repository controller for controlling deposits of, access to, and modification of the contents of the central repository. The central repository controller is accessible through remote real-time interaction on demand via the communications network, where a system administrator controls the central repository by configuring the central repository controller to selectively enable and permit deposits of, access to, and modification of the contents of the central repository by other entities. A transaction initiator initiates cooperative processing of the transaction order by depositing transaction order attribute information into the central repository through remote real-time interaction on demand with the central repository controller via the communications network. A participant selectively accesses and modifies ongoing attribute and status information while processing the transaction order through remote real-time interaction on demand with the central repository controller via the communications network.
Various embodiments include the participants communicating with other participants, a transaction initiator communicating with a participant, or a transaction initiator notifying a merchant, supplier, or a third party as a participant through remote real-time interaction on demand with the central repository controller via the communications network. Additionally, the merchant may be the system administrator. By this method, the merchant, supplier, or a third party as a participant is notified of being selected to process a deposited transaction order and of


.4.
associated processing requirements, and acknowledges being selected to process a deposited transaction order and of associated processing requirements through remote real-time interaction, on demand with the central repository controller via the communications network.
Various embodiments also include the system administrator controlling the central repository and the central repository controller via a collection of directives, where the repository controller registers and authenticates a participant as an entity authorized to access the repository, where the repository controller prevents unauthorized participants from accessing the repository, where the repository controller constrains the actions of each authorized entity, and where the repository controller can selectively reveal or conceal the identity of any one participant from any other participant.
In another aspect, the invention provides a method of managing transaction orders in realtime to enable a plurality of independent entities to cooperatively process a transaction order. The method includes the steps of creating a central repository capable of storing ongoing transaction order attribute and status information, the central repository being accessible from a communications network, registering entities as participants capable of processing at least some portion of the deposited transaction order stored in the central repository, configuring a central repository controller to facilitate cooperative processing of a transaction order among participants, receiving the deposited transaction order from a transaction initiator, storing attribute and status information associated with the deposited transaction order within the central repository, and managing the deposited transaction order by monitoring, and updating as necessary, the attribute and status information of the deposited transaction order within the central repository until the processing of the transaction order is complete.
In one embodiment, the method of managing transaction orders optionally includes the step of enabling participants to access the central repository via the communications network in a manner dictated by the central repository controller configuration.
In yet another aspect, the invention provides a method of participating in the processing of transaction orders in real-time via a system that enables a plurality of independent entities to cooperatively process a transaction order, the method including the steps of registering with a central repository controller associated with a system administrator as a participant capable of processing at least a portion of a transaction order deposited within a central repository, where the central repository controller is configured by the system administrator, and monitoring the


5
attribute and status information associated with a deposited transaction order by remotely accessing the central repository on demand and in real-time via a communications network, and modifying attribute information, status information, or both for the deposited transaction order in real-time via the communications network, and processing at least a portion of the transaction order stored within the central repository as directed by the central repository controller.
In one embodiment, the method of participating in the processing of transaction orders includes the participation of a merchant and the steps of providing merchant participant configuration information to the system administrator for inclusion into the central repository controller configuration.
In another embodiment, the system includes a communications network, a central repository that contains current and ongoing transaction order attribute and status information, and a central repository controller. The central repository controller registers, authenticates, and authorizes system access to the participants, controls the deposits of, access to, and modification of the contents of the central repository by the participants. The central repository controller is accessible through remote real-time interaction on demand via the communications network, wherein a system administrator controls the central repository by configuring the central repository controller to selectively enable and permit deposits of, access to, and modification of the contents of the central repository by registered, authenticated, and authorized participants.
In further embodiments, entities capable of being responsible for processing at least some portion of a transaction order, which type is anticipated to be deposited in the repository, are registered with the central repository controller as participants. Configuration directives for the controller can reference these participants to authenticate and authorize system access and specify deposit, access, and modification rights associated with each such participant to facilitate cooperative processing of a transaction order. Each registered participant accesses the system via an authenticating and authorizing log-in procedure, either directly through the controller user interface or indirectly through non-system apparatus that interfaces with the controller via a communications protocol transmitted over the communications network.
Further still, a transaction initiator, classified as a participant and acting like a buyer, initiates cooperative processing of the transaction order by directly depositing transaction order attribute information into the central repository through remote real-time interaction on demand with the central repository controller user interface, via the communications network.


-6-
Alternatively, the transaction initiator classified as a participant, also acting like a buyer, can indirectly deposit transaction order attribute information by interacting with an apparatus operating outside the system that subsequently communicates transaction order information to the repository controller via a communications protocol transmitted over the communications network.
In addition, a transaction initiator may query the system or cause the system to otherwise act without depositing transaction order attribute information. For example, a transaction initiator, acting like a buyer, may want to check availability of an item. A potential buyer can choose an item and in return the system can inform a potential buyer of availability of the item and can facilitate soft reservation of the item. Soft reservation is the system reserving inventory of a particular item pending an actual order from a buyer. The system facilitates soft reservation through the set-up of business rules, for example, if a buyer does not place an order for the item within a predetermined time frame, the item is then available for sale again. Another business rule can facilitate a spot-buying process. For example, a potential buyer wishes to obtain an item that does not exist within the central repository. The spot-buy process collects the desired product attributes and then initiates a query process based on profiles of suppliers that meet the query criteria. In the process, the suppliers are asked to respond with product availability and pricing.
Regardless of how the transaction order is initiated, at least one participant selectively accesses and modifies the ongoing attribute and status information while processing at least a portion of the transaction order through remote real-time interaction on demand with the central repository controller via the communications network. The participant may or may not take actions outside of the system to process the transaction order.
In various other embodiments, a participant takes or directs actions outside of the system that are necessary to complete the participant's responsibilities for processing at least some portion of a transaction order. Before, during, and after talcing these actions, the participant selectively monitors, accesses, and modifies the ongoing attribute and status information of the associated transaction order, as appropriate, to maintain current system information. Alternatively, the participant's responsibilities and actions may be entirely embodied into an apparatus, such as software, controlled by the participant, which automatically performs all

-7-
processing and interaction with the repository controller via a communications protocol transmitted over the communications network.
In addition, the system generates reports summarizing various activities of the participants and of the system as a whole. The reports, can also include shipping and return labels, including co-branding, customized or personalized messages, and promotional literature. Such reports can be embodied in electronic form or printed onto printable media.
The roles of participants can include, but are not limited to, the roles of buyers, merchants, suppliers, carriers, escrow agents, and the like. The system administrator may be any participant, or a third party acting as a non-participant. Any participant may communicate with any other participant, or the system administrator, as permitted by the controller configuration. The identity of participants are selectively concealed or revealed to other participants based upon the controller configuration. Each participant's permitted and required actions, and system actions towards the participant, such as notification and acknowledgment, are constrained within boundaries dictated by the controller configuration.
A further embodiment of the system enables, non-participants to act as the system administrator to scale the system beyond the motivations of any one participant and to allow for many-to-many, as opposed to one-to-many, relationships among participants. For example, the system could accommodate multiple merchants and multiple suppliers and carriers. Not all merchants would cooperate with all suppliers and not all suppliers would cooperate with all merchants, but the system as a whole could have a low cost, high volume account with one or more carriers. Each unrelated merchant and supplier could make use of the system's high, but unrelated, volume of transactions.

-7A-
Accordingly, the present invention provides a real-time transaction order management system for enabling a plurality of independent entities to cooperatively process a transaction order, the system comprising: a communication network; a central repository containing ongoing transaction order attribute and status information; and a central repository controller for controlling deposits of, access to, and modification of the contents of the central repository, the central repository controller being accessible through remote real-time interaction on demand via the communications network, wherein: a system administrator controls the central repository by configuring the central repository controller to selectively enable and permit deposits of, access to, and modification of the contents of the central repository by other entities; a transaction initiator initiates cooperative processing of the transaction order by depositing transaction order attribute information into the central repository through remote real-time interaction on demand with the central repository controller via the communications network; and at least one participant selectively accesses and modifies ongoing attribute and status information while processing the transaction order through remote real-time interaction on demand with the central repository controller (270) via the communications network.
The present invention also provides a method of managing transaction orders in a real-time to enable a plurality of independent entities to cooperatively process a transaction order, the method comprising the steps of: creating a central repository capable of storing ongoing transaction order attribute and status information, the central repository being accessible from a communications network; registering entities as participants capable of processing at least some portion of a deposited transaction order stored in the central repository; configuring a central repository controller to facilitate cooperative processing of a transaction order among participants; receiving the deposited transaction order from a transaction initiator; storing attribute and status information associated with the deposited transaction order within the central repository; and managing the deposited transaction order by monitoring, and updating, as necessary, the attribute and status information of the deposited transaction order within the central repository until processing of the transaction order is complete.

-7B-
The present invention further provides a method of managing transaction orders in real-time to enable a plurality of independent entities to cooperatively process a transaction order, the method comprising the steps of: creating a central repository capable of storing ongoing transaction order attribute and status information, the central repository being accessible from a communications network; registering entities as participants capable of processing at least some portion of a deposited transaction order stored in the central repository; configuring a central repository controller to facilitate cooperative processing of a transaction order among participants; enabling participants to access the central repository via the communications network in a manner dictated by central repository controller configuration; receiving the deposited transaction order from a transaction initiator; storing attribute and status information associated with the deposited transaction order within the central repository; managing the transaction order by facilitating real-time interaction between the participants and the central repository via the communications network, wherein the participants cooperatively process the transaction order; and monitoring and updating, as necessary, the attribute and status information of the transaction order within the central repository until completion of the transaction order.
The present invention still further provides a method of participating in the processing of transaction orders in real-time via a system that enables a plurality of independent entities to cooperatively process a transaction order, the method comprising the steps of: registering with a central repository controller associated with a system administrator as a participant capable of processing at least a portion of a transaction order deposited within a central repository, wherein the central repository controller is configures by the system administrator; monitoring attribute information and status information associated with a deposited transaction order by remotely accessing the central repository on demand and in real-time via a communications network; modifying the attribute information, the status information, or both for the deposited transaction order in real-time via the communications network; and processing at least a portion of the transaction order stored within the central repository as directed by the central repository controller.

-7C-
The present invention still further provides a method of participating in processing of transaction orders as a merchant in real-time via a system that enables a plurality of independent entities to cooperatively process a transaction order, the method comprising the steps of: registering with a central repository controller as a merchant participant capable of processing at least a portion of a transaction order deposited within a central repository, central repository controller configuration being controlled by a system administrator; providing merchant participant configuration information to the system administrator for inclusion into the central repository controller configuration; monitoring attribute information and status information associated with a deposited transaction order by remotely accessing the central repository on demand and in realtime via a communications network; modifying attribute information, status information, or both for the deposited transaction order in real-time via the communications network; and processing at least a portion of the transaction order stored within the central repository as directed or executed by the central repository controller.
These and other objects, along with advantages and features of the present invention herein disclosed, will become apparent through reference to the following description of embodiments of the invention, the accompanying drawings, and the claims.
BRIEF DESCRIPTION OF THE ACCOMPANYING DRAWINGS
In the drawings, like reference characters generally refer to the same parts throughout the different figures. Also, emphasis is generally being placed upon illustrating the principles of the invention. Further preferred and exemplary embodiments of the present invention are discussed with reference to the drawings which show the following.


-8-
Figure 1 is an illustrative logical block diagram depicting an embodiment of a real-time transaction order management system.
Figure 2 is an illustrative logical block diagram depicting the internal components of the central repository.
Figure 3 is an illustrative logical block diagram depicting the communication dialog between the central repository and other system participants.
Figure 4 is an illustrative logical block diagram depicting a transaction order processing scenario.
Figure 5 is an illustrative logical block diagram depicting direct communication between participants over shared networks.
Figure 6 is an illustrative logical block diagram depicting one participant performing multiple participant roles with respect to certain types of transactions.
Figure 7 is an illustrative logical block diagram depicting the elimination of some participant roles with respect to certain types of transactions.
Figure 8 is an illustrative logical block diagram depicting a transaction order item return scenario.
Figure 9 is an illustrative logical block diagram depicting the inclusion of a carrier ratings information participant into the system.
Figure 10 is an illustrative logical block diagram depicting the use of a carrier ratings information component by the market interface participant.
Figure 11 is an illustrative logical block diagram depicting the inclusion of multiple participants of each type into the system.
Figure 12 is an illustrative logical block diagram depicting a many-to-many relationship between supplier and market interface participants registered as participants by the system.
Description
Embodiments of the present invention are described below. It is, however, expressly noted that the present invention is not limited to these embodiments, but rather the intention is that modifications that are apparent to the person skilled in the art are also included. In


-9-
particular, the present invention is not intended to be limited to the specific embodiments described herein.
Figure 1 is a logical block diagram of a transaction order management system 100 according to an illustrative embodiment of the invention. A transaction involves the one way transfer or two way exchange of subject matter between the system and a user of the system. This subject matter can be anything of value, tangible or intangible, that can be exchanged or transferred. A unit of subject matter transferred as part of a transaction will be referred to as an item. By way of example, items can include products, services, currency, real or intellectual property, rentals, information, promises, gambling wagers and the like. Items offered need not be exchanged only for currency, but can be exchanged or "swapped" for one or more other items of the same or different type.
The transaction initiator interface (TII) 120 component is a user interface mechanism that presents to its users, or potential transaction initiators, the types of transactions that are available to be initiated from the TII 120 and then processed by the system 100. These transactions are referred to as "available transactions." Illustratively, Figure 1 shows only point-to-point communication paths between participants 120,130, 140, 150 and 160a-160n. No such restriction exists for the underlying network topology. A shared public network or private network, such as the Internet or an ethernet network could support these communication paths. The TII 120 can be an Internet web site accessible by its users over the Internet network.
For simplicity of reference, the transaction initiator interface (TII) 120 will be referred to as "the market interface." The entity that determines the design of and manages the operation of the market interface will be referred to as "the merchant." Transactions available to be initiated from the (TII) 120 will be referred to as "available transactions," potential transaction initiators will be collectively referred to as "the market," a potential transaction initiator who exercises the market interface, whether or not a resulting transaction is initiated, will be referred to as a "market user," and an actual individual transaction initiator will be referred to as "a buyer" 125. These simplified terms are for illustration only and are not intended to limit the scope of the invention in any way.
The market user may be a consumer or any business entity in a supply chain. Furthermore, the market user may not be an individual, but may be a machine, such as automated transaction initiation software executing on another Internet web site. For this embodiment, the


-10-
market interface provides a protocol interface suitable for machine-to-machine communications over a network, such as the Internet or an extranet.
Inside the system 100, each available transaction is represented by a collection of information, divided into individual fields referred to as "attributes." A portion of this information is predetermined before the transaction is made available for execution. For example, a transaction involving the exchange of a manufactured item for currency can have an associated template, or framework. The template has fields or attributes for identifying the item(s), such as make, model, and manufacturer, options associated with the item such as size and color, an attribute identifying the supplier, and the wholesale and/or retail price of the item, if known before its initiation. For example, the subject matter of a transaction can be the exchange of a "toaster" for a specific amount of U.S. currency. Options associated with the subject matter can specify the year, make and model of the toaster, specify available colors, accessories, voltage requirements, etc.
In some embodiments, the supplier 130 would be determined by the system 100 shortly after it is initiated by a market user. In other embodiments, a supplier 130 would be determined by the system 100, such as by the market interface, before it is initiated by a market user. Supplier selection can be based upon a priority list factoring cost to supply, carrier capability, response time to ship, etc.
Another portion of this information is determined upon initiation. For example, there may be many potential suppliers of the item. The contents of the supplier identification field may be determined upon initiation. Also, the wholesale or retail price charged by a manufacturer may also be determined based upon the supplier determination.
Any remaining portion is determined some time after initiation. For example, the status of processing of the transaction can be indicated by the contents of a field that changes during each stage of its processing in the system. For example, the status field may indicate that the item has been picked from the supplier's inventory, but not yet transferred to the carrier 140.
What transaction information is revealed and how it is represented to potential transaction initiators, or "market users," is determined by the design of the market interface 120. The source of information for each available transaction can be from one or many sources, as dictated by the design of the market interface 120. This collection of information is referred to as a collection of


-11-
attributes associated with a particular transaction. Upon transaction initiation, these attributes provide enough information to enable the transaction to be fully processed by the system 100.
Participants are actors which process some portion of certain transactions supported and processed by the system 100. Each participant acts within a particular scope of participation to process a particular transaction. Participants are typically independent business entities. The central repository 102 is a special sort of participant in that it coordinates the collective output of all participants. The system 100 is said to be "centric" to the organization controlling the central repository 102. Outside of the central repository 102, any participant is referred to as a peripheral participant. The market interface 120, a supplier 130, a carrier 140, a credit/payment verifier 150 and the other participants 160a-160n are all peripheral participants. Other participant types can include import/export tariffs and customs verifiers, escrow agents, carrier rate information providers, or whoever is required to process a portion of a transaction supported by the system 100. The supplier 130, the carrier 140, the market interface 120 and the credit payment verifier 150 are core participants. Other participants such as 160a-160n are referred to as non-core or "third party" participants.
A participant may be an organization of one or more people and equipment, or a totally automated component, such as an automated Internet web site that interfaces with the remainder of the system 100. Every participant interfaces with the central repository 102 according to rules specified by the central repository controller configuration 220 (not shown). Every participant registers with the central repository 102 to be recognized by the central repository 102 and referenced as part of the central repository configuration. Registration creates a profile of the participant which describes the participant in sufficient detail to enable its selection and participation in the processing of some transactions supported by the system 100. A registered participant is qualified by the central repository 102 to be permitted to participate in the processing of a transaction supported by the system 100. There are profiles in the system 100 for each type of participant, such as for a supplier 130, carrier 140, market interface 120, or for participant types 160a-160n. Access to the central repository 102 is controlled via password or some other means of authentication.
The supplier 130 is in possession of some or all of the transaction associated subject matter at the time the transaction is initiated. Suppliers are identified by the ownership and/or control of inventory containing some or all of the subject matter associated with the transaction.


-12-
This inventory can reside somewhere in the chain of manufacturing, distribution, and sales of a particular item. A supplier can be the original manufacturer, a distributor, or a retail merchant whether or not associated with the TII 120 itself. As a participant, a supplier 130 must be pre-qualified by the system 100 to service available transactions.
A carrier 140 performs the transfer of some or all of the subject matter between the transaction initiator 120 and the supplier 130 consistent with attributes of the transaction. As a participant, a carrier 140 must be pre-qualified by the system 100 to service available transactions. For example, a carrier 140 may or may not deliver to a particular destination, such as Eastern Europe, or deliver within a particular time limit, or deliver within a particular cost limit. A carrier 140 may or may not provide sufficient protection of the transferred subject matter in the form of security, insurance, bonding, impact resistance, temperature controlled packages for perishable food items, etc. Such terms and conditions associated with the transfer of subject matter are articulated via attributes associated with the transaction.
A credit/payment verifier 150 either verifies credit or effects payment of the transaction for the transaction initiator. As a participant, a credit/payment verifier 150 is pre-qualified to service available transactions. A transaction attribute may demand that credit is verified, or that payment is made, or that either is performed as a prerequisite to the transfer of any other subject matter associated with the transaction.
The central repository 102, is a mechanism that enables the coordination of the activities of other peripheral participants such as the market interface 120, supplier 130, carrier 140, credit/payment verifier 150, or other types of participants 160a-160n. To enable coordination, the central repository 102 is illustratively situated as a center point for communication between other peripheral system participants. As a center point of communication, any communication involving a coordinated action of any participant is transmitted to the central repository 102. The central repository 102 can selectively make the content and status effect of these communications available to other participants.
In some embodiments, the central repository 102 can be embodied in multiple locations on a network where repository information can be replicated or otherwise synchronized across locations to act as a center point of communication between peripheral participants.
Figure 2 is an illustrative logical block diagram depicting the internal components of the
central repository 102. The central repository 102 is divided into a controller component 270 and


-13-
a repository component 272. The controller 270 is an active and animated portion of the central repository 102 while the repository 272 is a relatively passive storage mechanism. The behavior of the central repository 102 is dictated by the behavior of the controller 270. The controller 270 controls all access to the contents and the capabilities of the central repository 102 and it is the orchestrator of system activity.
In one embodiment, the controller 270 is implemented in software in a manner where its behavior is flexible and programmable, and where it can be frequently changed in an efficient and orderly manner. The controller's behavior at any given time is dictated by the controller configuration, which is essentially a behavioral specification including directives which act like programming commands. The commands activate rules of behavior associated with each interface to every participant in the system. The configuration information is stored in configuration files 274. The controller 270 is implemented as an application program executing on an operating system 276. The controller 270, like other application programs, accesses configuration files 274 and other types of files through the operating system 276.
The configuration editor 278 is also an application program used to display and modify the configuration information in human readable form. The communications interface hardware 280 is used to interface with one or more communication channels 282, connecting the central repository 102 with system participants 260a-260n. The communications channel 282 can be a public or private network. The repository 272 can be a type of database that is manipulated by the controller 270 through the operating system 276. This type of database could be relational or more object oriented, depending upon the scope of system functionality.
A controller configuration, as stored in the configuration files 274, can define various types of transactions and how they are processed by the system in terms of a collection of attribute types and associated values. The configuration can also define what attribute values are determined inside or outside of the repository 272, and can specify when and how attribute values are determined and processed in the course of the transaction.
The configuration can also specify types of participants and their relationships, and identify participants and participant relationships that are registered with the system 100 and qualified to participate in the processing of particular transaction types. Participants are selected or qualified to participate in processing particular transactions supported by the system 100. To participate, qualified participants are authenticated and authorized while establishing a


-14-
communication session with, or logging onto, the central repository 102. In one embodiment, the configuration is designed to regularly add or remove supported transactions, participants, and participant relationship support as the system's associated circumstances change.
Figure 3 illustrates the communication dialog between the central repository 102 and other peripheral participants . Each participant communicates with the central repository 102 via a communications protocol, referred to as a central repository protocol (CRP) transmitted over a communications channel linking the participant and the central repository 102. This dialog can optionally provide graphical user interface support to the participant and can occur interactively and in real-time.
The CRP categorizes communication between system participants as action requests and action responses. The participant transmitting an action request is signaling the receiver to take some action. The action may be for the receiving participant to reply by communicating certain information back to the transmitting participant, or to take some other action apart from the communication of information. The receiving participant replies either with information requested by the previous action request, if applicable, by taking some other requested action and responding with a positive acknowledgement communication, or by not taking the requested action and responding with a negative acknowledgement communication of the previous action request. An action request can request actions within or outside the scope of particular transactions being processed by the system 100. Action requests within the scope of a particular transaction reference the transaction and are consistent with what is permitted by the system configuration and with the state of processing for that particular transaction.
The central repository 102 specifies and polices what types of transactions are processed by the system 100, what peripheral participants are qualified to process any of those transactions inside the system 100, what qualified peripheral participants are permitted to participate in the processing of each particular transaction, and what types of communications or action requests are expected or permitted from each qualified peripheral participant relative to the context of the communication. The central repository 102 also selectively reveals and conceals information under its control to each participant based on the participant's profile, the profiles of other participants providing or associated with such information, and the central repository policy as specified by its configuration.


-15-
For example, the market interface 120, cannot request to initiate the processing of a transaction for which it is not qualified as a participant, nor can the market interface 120 request to select a carrier 140 when the configuration does not permit the market interface 120 to select the carrier 140 for that type of transaction, nor can the market interface 120, when permitted by the configuration to select a carrier 140, select a carrier that the configuration indicates is not qualified to participate in the processing of that particular transaction. The central repository configuration diverts such permitted actions by participants to be rejected by the central repository 102.
The market interface 120 can communicate an action request to the central repository 102 to initiate the processing of a particular transaction referenced by the action request. Each referenced transaction is a collection of attributes indicating everything the system needs to fully process the transaction. Typically, this action request corresponds to actions of a buyer made while interacting with the market interface (TII) 120. The central repository 102 verifies that the type of transaction, as indicated by a transaction attribute, is supported by the system 100 and that the remaining transaction attributes indicate or imply actions that are permitted by the central repository 102. For example, a transaction attribute indicating a supplier 130 or carrier 140 not qualified by the system 100 to participate in the processing of this type of transaction would not be permitted by the central repository 102.
A configuration may restrict what information is revealed to particular participants. For example, to protect buyer privacy, the central repository 102 may only reveal the buyer's identity and the currency amount of a transaction to the credit/payment verifier participant. Accordingly, the central repository 102 may selectively conceal what items the buyer 125 is buying from the market interface 120, or additionally conceal the market interface and the supplier identity from the credit/payment verifier participant. This central repository policy restricts what the credit/payment verifier participant can selectively access and monitor via the central repository 102.
In one embodiment, each buyer 125 has a profile. A buyer profile can reference other compatible participant profiles. Each buyer 125 can have a list of carrier profiles based upon the buyer's preferences and default shipment destination. For example, an international buyer located in France may not be serviced by certain carriers. Based on carrier profiles, a particular buyer 125 is matched to one or more particular suppliers 130 that deliver in France. In another


-16-
embodiment, the buyer 125 may specify a destination address to override the buyer's carrier profile as the sole criteria to determine feasible carriers 140 and suppliers 130. In another embodiment, the buyer 125 is informed of any items that are not listed as available due to carrier disqualification or option mismatch.
In one embodiment, the TII 120 determines both the supplier 130 and carrier 140. In another embodiment, the user decides from a list of carriers 140 supported by various suppliers 130 determined by the TII 120. In yet another embodiment, the user decides both the supplier 130 and the carrier 140 from a list of feasible suppliers 130 and carriers 140. All these variations must be compatible with the rules of operation specified by the central repository configuration.
Figure 4 illustrates an example of a basic transaction processing scenario. All peripheral participants, including the market interface 120, the supplier 130, the carrier 140, and the credit/payment verifier 150 have been qualified to participate within the system 100 and to process the type of transaction referenced by the initiate transaction action request 424. Corresponding from interaction with a buyer 125, the market interface 120 transmits an initiate transaction action request 424 referencing a particular transaction to the central repository 102. This action is also referred to as "depositing" a transaction order. The central repository 102 then begins orchestrating the processing of the transaction and positively acknowledges this status by transmitting the initiate transaction processing response 426 back to the market interface 120.
If the referenced transaction attributes indicate that credit verification is a pre-requisite to processing the transaction, the central repository 102 then transmits a credit verification action request 454 to the credit/payment verifier participant 150. The credit/payment verifier 150 participant performs a credit check and, if successful, communicates a positive acknowledgement to the central repository 102. The central repository 102 can make the status of the transaction, namely the successful credit check, available to other participants including the market interface 120, as transaction status. The central repository 102 then transmits an inventory item pick and pack request 434 to the supplier 130. The supplier 130 picks the item from its inventory and packs the item as specified by the attributes of the referenced transaction. The supplier 130 then positively acknowledges its actions by transmitting an inventory item pick and pack action response 436 back to the central repository 102. Once again, the central repository 102 can make the current status of the transaction, namely the completed supplier pick and pack, available to other participants, including the market interface 120, which has the option to reveal this to the


-17-
buyer 125. The central repository 102 then transmits a pick up and deliver action request 444 to the carrier 140 specified by attributes of the referenced transaction. The carrier 140 then travels to the supplier site and picks up, or takes possession of the packed item from the supplier 130. Once again, the central repository 102 can make the status of the transaction, namely the completed supplier pick and pack, available to other participants, including the market interface 120 which has the option to reveal this to the buyer 125. The carrier 140 then delivers the subject matter of the transaction to the destination address as specified by the attributes of the referenced transaction. The carrier 140 next positively acknowledges its actions by transmitting a pick up and deliver action response 446 back to the central repository 102. Once again, the central repository 102 can make the status of the transaction, namely the completed supplier pick and pack, available to other participants, including the market interface 120, which has the option to reveal this to the buyer 125.
Transaction attributes can include shipping options, such as particular packing materials to be used by either the supplier 130 or the carrier 140, including, but not limited to, "styrofoam peanuts," gift wrapping, personalized messaging and identification, advertising, branding, etc. Branding may involve co-branding, where both the merchant and the supplier apply their identification, trademarks, or logos to the packaged and delivered item, or simply single branding, where the identification, trademark, or logo of one participant, such as the merchant or supplier, is applied to the packaged and delivered item.
International destination addresses may require special documents to accompany the shipped item. For example, Thailand may require multiple duplicate bills of lading and other documentation to be packed with the shipped item, m one embodiment, the transaction attributes supply the carrier with information needed to satisfy shipping documentation for a particular destination. The carrier 140, can then complete the documentation and communicate this information as, for example, a completed PDF file to the supplier 130 for packing inside the item packaging, if appropriate. The supplier 130 then prints the routed PDF file onto paper and packs it with the shipped items.
In this embodiment, the credit/payment verifier 150, the supplier 130, and the carrier 140 all responded to the central repository 102 after their respective actions were completed. In an alternative embodiment, each participant can immediately respond to the central repository 102 with a positive acknowledgement of receipt of the action request and later respond with a


-18-
positive or negative acknowledgement with respect to the required actions associated with the action request. In another embodiment, the central repository 102 can notify other participants upon receipt of any response from any other participant. For example, the credit/payment verifier's positive acknowledgment of credit verification to the central repository 102 could be immediately made known to other participants. The central repository 102 could notify other participants, such as the carrier 140, so that the carrier 140 could earlier anticipate and schedule item pickup from the supplier 130, knowing that credit for the transaction has been approved, and knowing that both it and the supplier 130 have been specified and selected to process the transaction.
Central repository supplied notification can take the form of active or passive notification. Active notification involves the central repository transmitting a specific action request to a participant for the purpose of notifying that participant of some event. One example of active notification is e-mail notification. Passive notification involves the central repository 102 making available status information when responding to a status request received from a participant. Status information transmitted by the central repository 102 back to the participant contains information constituting a notification of some event.
In this embodiment, the attributes of the referenced transaction, as initiated by the market interface 120, specified all parameters needed for the central repository 102 to orchestrate and complete processing of the transaction. The referenced transaction specifies credit verification and the identity of the credit verifier 150, the item, the identity of the supplier 130, the method of packing, the identity of the carrier 140, the method of delivery, and the destination address. In alternative embodiments, the central repository 102 can override processing decisions that are specified by the referenced transaction, or make processing decisions when not specified by the referenced transaction. For example, the central repository 102 could select the supplier 130 and/or carrier 140 to participate in the processing of the referenced transaction regardless of the contents of the referenced transaction attributes. Such a decision could be based upon, but is not limited to, volume discounts given to the central repository 102 by the supplier 130 or carrier 140, or based on the cost of delivery to the destination address specified by the referenced transaction. Additionally, the central repository configuration can specify that the market interface may decide the method of delivery for a particular type of transaction upon its initiation. If such a decision was not made by the market interface 120, then the central repository 102


-19-
would override the required decision with a default method of delivery, such as U.S Postal Service Priority Mail. Otherwise, the market interface decision, as indicated by a transaction attribute, would dictate the method of delivery.
For this type of embodiment, the design of the market interface 120 has the option of passing the method of delivery decision onto the buyer, or automatically making this decision before sending the transaction initiation request to the central repository. The combined design of the central repository 102 and the market interface 120 dictates what attributes are determined by the buyer 125, what attributes are determined by the market interface 120, and what attributes are determined by the central repository 102.
In an alternative embodiment, the referenced transaction attributes indicate that the transaction must be pre-paid or payment verified, instead of credit verified, before processing the transaction. The central repository 102 notifies the credit/payment verifier 150 by communicating a payment verification action request referencing the transaction. The credit/payment verifier 150 makes use of buyer account information identified by transaction attributes to debit the buyer's account to effect payment for the transaction. The credit/payment verifier 150 then positively acknowledges its actions to the central repository 102 by transmitting a payment verification action response 456 back to the central repository.
Central repository receipt of such acknowledgements or notifications from one participant enables the central repository 102 to notify other participants of the processing status of that particular transaction. In one alternative embodiment, the central repository configuration 102 may specify that notification to the carrier 140 of the initiated transaction will occur only after the presence of the item in the supplier's inventory is verified and acknowledged by the supplier 130, and after payment or credit is verified and acknowledged by the credit/payment verifier 150. This central repository policy specified by its configuration may enable the carrier 140 to more accurately plan its routing and delivery schedule, knowing that there is now a high likelihood of item delivery for this particular transaction. If it is the carrier's policy to travel to the supplier 130 to "pick up" items for delivery, it can also better plan item pick up routing and scheduling.
Note that some embodiments of the system, as specified by the central repository configuration and the supplier profile, do not require the supplier 130 to supply inventory information to the system. In these circumstances, the supplier 130 simply verifies and


-20-
acknowledges to the central repository 120, via an action response, that the item can be supplied and has been reserved for the referenced transaction.
This type of arrangement would also apply to "made to order" or "on demand" suppliers, where no inventory is intended to exist at the time of transaction initiation. A supplier 130 can have a warehouse of components that supply a customized assembly process according to the attributes of the transaction. The supplier 130 simply acknowledges its capability to supply the order without providing or verifying any other inventory related information.
Each transaction is identified by at least one unique repository assigned order number or identifier. Additionally, each participant, including the TII and the user, can assign an identifier for individual tracking purposes. These identifiers are also referred to as tracking numbers. After the central repository identifier is assigned and communicated to the TII 120 or any other participant, the TII 120 or any other participant can query the status of the transaction by specifying this identifier. In an alternative embodiment, acknowledgement of notification by any participant can also be indicated by the centrally accessible transaction status associated with this identifier.
Other non-core participants 160a-160n can include an import/export tariffs and customs verifier. This participant provides expertise in verifying that a particular transaction complies with all applicable import/export laws. Such a participant may provide documents that must accompany certain items into or out of a particular country. Such documents can be produced from a database of information and communicated electronically to other participants such as suppliers 130 and carriers 140.
Other non-core participants 160a-160n can include a compliance verifier. A buyer 125, such as a large retail conglomerate, may have strict rules for delivery of items to the conglomerate's facilities. For example, the buyer 125, may require bar code labels encoding buyer specific stocking codes be placed on the items before shipment. Such buyer specific information can be communicated, and verified as communicated, from one participant to another participant through the system 100.
Figure 5 illustrates an alternative embodiment where the system 100 accommodates participation scenarios involving direct communication between peripheral participants and where the system 100 can reside on private or public networks that carry non-central repository
and non-system related communication traffic. For this type of scenario, the central repository


-21-
102 preferably functions in a complimentary way with activity associated with direct communication between peripheral participants.
The "star communication topology" depicted in Figures 1, and 3-4 indicates only point-to-point paths of communication, and places no such restriction on the underlying network topology. A public network, such as the Internet, would be suitable to support such point-to-point communication paths between the central repository 102 and other system participants or an extranet, for example, an extension of a corporate intranet, can be used to connect participants. The system 100 does not require that all inter-participant communications involve the central repository 102. Communication involving the central repository 102, however, has the advantage of being centrally posted for all participants to access.
In the illustrative embodiment of Figure 1, the central repository 102 supplies all information describing all available transactions associated with the market interface 120. Consequently, the market interface exclusively relies upon the central repository as a sole source for all information describing all available transactions. In alternative embodiments, such as depicted in Figure 5, the central repository 102 can supply only a portion of all information describing all of the available transactions. Accordingly, the market interface can rely upon information from non-central repository sources and can integrate information from both the central repository 102 and non-central repository sources to support the presentment and processing of available transactions.
Figure 6 depicts one participant, the supplier 130, performing multiple participant roles with respect to particular transactions. For some types of transactions, a supplier 130 may also act as a carrier 140. For example, a transaction involving the exchange of digital information does not require a separate carrier participant for physical delivery if the supplier effects the exchange of digital information via transmission over the Internet to a transaction attribute specified Internet address. However, if the digital information is to be delivered as stored onto a compact disk, a carrier 140 may be required for physical delivery as specified by a transaction attribute specified mailing address destination.
As another example, the supplier 130 could be a florist local to a particular area that also delivers its inventory to the transaction attribute specified destination address. Thus, within a particular delivery area, the florist acts as both the supplier 130 and the carrier 140. Furthermore,


-22-
the florist may supply credit to certain buyers, eliminating the required participation of the credit/payment verifier 150.
As another example, the market interface, or merchant, may inventory certain types of items associated with certain transactions, enabling it to act as the supplier 130 for those particular transactions. Although one advantage of the system is that it allows a merchant, and in particular a net merchant, to operate with zero inventory. For those certain items, the market interface 120 acts as a supplier 130, but may still require the physical delivery services of a separate carrier 140.
Figure 7 depicts the elimination of participant roles with respect to particular transactions. Some transactions do not require payment nor credit verification. For example, a transaction involving the distribution of free information does not require payment or credit verification. The market interface 120, simply collects information about the buyer 125, including a mailing and/or Internet destination address that is stored as transaction attributes, and initiates transactions through the central repository 102 to deliver the information to the specified destination address. Printed information may require the services of a separate carrier 140 for physical delivery.
Figure 8 depicts the process of returning items previously acquired and delivered to a buyer 125 as a result of previous transactions processed by the system 100; however, returns are not limited to items purchased by a buyer. Returns can include, for example, a supplier returning reusable shipping containers to a carrier or manufacturer. The buyer 125 interacts with the market interface 120 to inquire about item return terms and options. If the buyer 125 decides to return an item, the buyer 125 provides notice to the system by interacting with the market interface 120. Due to this interaction with the buyer 125, the market interface 120 transmits an item return notification request 824 to the central repository 102 that references the previously


-23-
information 846 required by the system 100 and the buyer 125 to execute return of the item back to the supplier 130. The supplier 130 responds, acknowledging that the supplier 130 anticipates the return of the item via an item return notification response 836 and will proceed to inspect the item for damage upon its receipt from the carrier 140.
The item return response 836 references relevant return shipping information required by the buyer 125 to execute delivery of the item back to the supplier 130. This information provides directions to a local carrier drop-off facility or provides a schedule for item pickup by the carrier 140 at the buyer's address. This information can also support the printing of return labels and other information required by the carrier 140 to execute the return of the item to the supplier 130. The buyer 125 affixes the printed labels onto the item packaging before the carrier 140 takes possession of the item.
Figure 9 depicts multiple carrier participants 140a-140n operating within the system 100 along with a carrier ratings information provider 160n. The carrier ratings information provider 160n can be queried to provide current rate information based upon pick up and delivery locations and schedules, item weight and size, method and time limit for delivery, etc. For transactions where the central repository 102 is configured to select a carrier 140, the central repository 102 can select from many registered and available carriers 140a-140n in response to information queried form the carrier ratings information provider 160n.
All suppliers 130 may not deal with all carriers 140a-140n. For example, the U.S. Postal Service may require that the goods be dropped off at a U.S. Postal Service facility as a prerequisite for delivery. A supplier 130, as a matter of policy, may only use carriers that pick up goods to be delivered at the supplier's place of business. To track these types of preferences, each supplier 130 can reference compatible carrier profiles. Compatible carrier profiles identify which carriers 140 the supplier 130 will and will not do business with, and ranks those carriers 140 in terms of preference.
Figure 10 depicts an alternative embodiment where the market interface 120 has direct access to the carrier ratings information provider 160n. Like that depicted in Figure 5, this direct access involves non-central repository related communication. The carrier ratings information provider 160n can be queried by the market interface 120 to provide current rate information based upon pick up and delivery locations and schedules, item weight and size, method and time limit for delivery, etc. For transactions where the central repository 102 is configured not to


-24-
select a carrier, the market interface 120 can select from many registered and available carriers 140a-140n in response to information queried from the carrier ratings information provider 160n.
Figure 11 illustrates an embodiment of the system 100 scaled to support multiple participants of each type. The system 100 can support multiple suppliers 130a-13 On each making subject matter available to multiple market interfaces 120a-120n. The system can support multiple carriers 140a-140n picking up items from multiple suppliers 130a-130n for delivery to individual buyers, each associated with different and multiple market interfaces 120a-120n. The system 100 can support multiple credit payment verifiers 150a-150n or multiple other types of peripheral participants l60a-160n, such as carrier rating information providers, escrow agents, etc.
In this embodiment, every supplier 130a-130n in the system does not necessarily interact with every market interface 120a-120n participant of the system 100. Every carrier 140a-140n is not necessarily participating with every supplier, nor with every market interface in the system 100. Every credit/payment verifier 150a-150n is not necessarily participating with every market interface 120a-120n, or merchant. All participants are interacting with the central repository 102 which processes transactions regardless of the associated participant's alliance or relationship to other participants of the system 100.
Figure 12 illustrates a many-to-many participatory relationship between six market interfaces 1220a-1220f and eight suppliers 1230a-1230h. The lines, such as the line 1240a, connecting individual suppliers 1230a-123 Oh to select individual market interfaces 1220a-1220f indicate a participatory relationship between the supplier and the market interface for some transaction types supported by the system 100.
In this example, none of the market interfaces 1220a-1220f have participatory relationships with all the suppliers 1230a-1230h registered within the system 100. Likewise, none of the suppliers 1230a-123 Oh have participatory relationships with all the market interfaces 1220a-1220f registered within the system 100. Market interface 1220b does not require a participatory relationship with any outside supplier 1130a-l 130h and can act as its own supplier. Market interfaces 1220e and 1220f do not have a participatory relationship with any common supplier 1230a-123 Oh. Market interfaces 1220c and 1220d each have participatory relationships with three suppliers, including one common supplier 1230e. Likewise, market interfaces 1220d


-25-
and 1220e have one common supplier 1230g. Market interfaces 1220a and 1220f have participatory relationships with three common suppliers, except for supplier 1230f.
Each supplier profile references an inventory profile indicating the types and number of items and associated options that are available in stock to be ordered. When multiple suppliers have common inventory of the same model and manufacturer, the market interface can aggregate the inventory for a particular item and its options over all suppliers with inventory for such an item. For example, if supplier A has 3 white and 2 black toasters, and if supplier B has 4 black and 1 olive toaster, then 3 white, 6 black and 1 olive toaster are listed as available for delivery to a destination specified by a buyer 125. If the buyer 125 is allowed to select a carrier 140 prior to selection of a particular item, then if a carrier 140 is not qualified to service a supplier, that supplier's inventory is not listed to the buyer 125 by the market interface.
System support for such complex relationships between participants provides potential for the system to scale in size beyond the interests of any one participant. When the system administrator of the central repository 102 is not a participant, the system administrator's motivations to expand the system are not limited to participants not competing with the system administrator. Such a system administrator can have motivations to scale the activities of the system beyond the motivations of any individual participant. For example, the system could accommodate rival participants in a neutral fashion. Alternatively, if the system administrator is a participant, the system 100 could be configured to support participants that do not detract from the business goals of the participant role of the system administrator.
With an independent system administrator, unrelated merchants and suppliers, or competing merchants and suppliers, can operate within the same system administrator managed system. Competing suppliers can compete for transaction orders in real-time. Suppliers can bid in real-time on bulk transaction orders. Such bidding and selection of the winning bidder can be automated via software executing inside the system 100. Likewise, high transaction volumes can solicit discounts from various participants operating inside the system 100. These high volumes can be paid for and associated with an account of any participant, including the central repository 102.
Configurations that expand the number of participants yield increased transaction volumes processed by the central repository 102. Economy of scale, as applied to increased
transaction volumes, can translate into lower processing costs per transaction. Lower processing

WO 01/84348 PCT/US01/13066
-26-
costs can render new alliances between merchants and suppliers less costly and can render such alliances profitable at lower transaction volumes. Such benefits translate into lower risks associated with such new alliances and can enable small merchants, including Internet merchants, to operate without local inventory.
For example, carrier discounts can be given to a merchant account associated with a market participant interface or the system administrator can supply free shipping and provide volume carrier discounts to even the smallest supplier or merchant run market interface.
Furthermore, every qualified participant has a familiar and standard interface with the system 100, via its interface with the central repository 102. Consequently, adding new alliances between existing system participants results in little procedural, learning, or cost overhead for either participant. Adding new participants to the system 100, such as new suppliers 130 or carriers 140, does not burden the merchant 120 with new procedures or communications interfaces. The same procedures and interfaces are used to participate with the new participants. The system 100 provides a situation that encourages many-to-many relationships between several different types of participants.
Having described certain embodiments of the invention, it will be apparent to those of
ordinary skill in the art that other embodiments incorporating the concepts disclosed herein can
be used without departing from the spirit and the scope of the invention. The described
embodiments are to be considered in all respects only as illustrative and not restrictive.
Therefore, it is intended that the scope of the present invention be only limited by the following
claims.

-27-
WE CLAIM :
1. A real-time transaction order management system for enabling a plurality of
independent entities to cooperatively process a transaction order, the system
comprising:
a communication network;
a central repository (102) containing ongoing transaction order attribute and status information; and
a central repository controller (270) for controlling deposits of, access to, and modification of the contents of the central repository (102), the central repository controller (270) being accessible through remote real-time interaction on demand via the communications network, wherein:
a system administrator controls the central repository by configuring the central repository controller to selectively enable and permit deposits of, access to, and modification of the contents of the central repository (102) by other entities;
a transaction initiator (120) initiates cooperative processing of the transaction order by depositing transaction order attribute information into the central repository (102) through remote real-time interaction on demand with the central repository controller (270) via the communications network; and
at least one participant selectively accesses and modifies ongoing attribute and status information while processing the transaction order through remote real-time interaction on demand with the central repository controller (270) via the communications network.
2. The system as claimed in claim 1, wherein the system administrator controls the
central repository and the central repository controller via a collection of directives.
3. The system as claimed in claim 1, wherein the at least one participant is a
merchant.

-28-
4. The system as claimed in claim 3, wherein the merchant is notified of being
selected by the transaction initiator to process a deposited transaction order and of
associated processing requirements through remote real-time interaction on demand
with the central repository controller via the communications network.
5. The system as claimed in claim 3, wherein the merchant is the system
administrator.
6. The system as claimed in claim 1, wherein the transaction initiator and the at least
one participant communicate by accessing and modifying the contents of the central
repository through remote real-time interaction on demand with the central repository
controller via the communications network.
7. The system as claimed in claim 1, wherein multiple participants communicate with
each other by accessing and modifying the contents of the central repository through
remote real-time interaction on demand with the central repository controller via the
communications network.
8. The system as claimed in claim 1, wherein the at least one participant is a
supplier.
9. The system as claimed in claim 8, wherein the supplier is notified of being
selected to process a deposited transaction order and of associated processing
requirements through remote real-time interaction on demand with the central repository
controller via the communications network.
10. The system as claimed in claim 8, wherein the supplier is the system
administrator.

-29-
11. The system as claimed in claim 8, wherein the supplier acknowledges being
selected to process the deposited transaction order and the supplier processes the
deposited transaction order through remote real-time interaction on demand with the
central repository controller via the communications network.
12. The system as claimed in claim 1, wherein the at least one participant is a third
party.
13. The system as claimed in claim 12, wherein the third party is notified of being
selected to process a deposited transaction order and of associated processing
requirements through remote real-time interaction on demand with the central repository
controller via the communications network.
14. The system as claimed in claim 13, wherein the third party acknowledges being
selected to process the deposited transaction order and the third party processes the
deposited transaction order through remote real-time interaction on demand with the
central repository controller via the communications network.
15. The system as claimed in claim 1, wherein the repository controller registers and
authenticates the at least one participant as an entity authorized to access the
repository.
16. The system as claimed in claim 1, wherein the repository controller prevents
unauthorized participants from accessing the repository.
17. The system as claimed in claim 15, wherein the repository controller constrains
the actions of each authorized entity.
18. The system as claimed in claim 1, wherein the repository controller can selectively
reveal or conceal an identity of any one participant from any other participant.

-30-
19. The system as claimed in claim 1, wherein the repository controller enables
remote printing of one or more reports.
20. The system as claimed in claim 1, wherein the at least one participant is an
escrow agent.
21. The system as claimed in claim 20, wherein the escrow agent is notified of being
selected to process a deposited transaction order and of associated processing
requirements through remote real-time interaction on demand with the central repository
controller via the communications network.
22. A method of managing transaction orders in a real-time to enable a plurality of
independent entities to cooperatively process a transaction order, the method
comprising the steps of:
creating a central repository capable of storing ongoing transaction order attribute and status information, the central repository being accessible from a communications network;
registering entities as participants capable of processing at least some portion of a deposited transaction order stored in the central repository;
configuring a central repository controller to facilitate cooperative processing of a transaction order among participants;
receiving the deposited transaction order from a transaction initiator;
storing attribute and status information associated with the deposited transaction order within the central repository; and
managing the deposited transaction order by monitoring, and updating, as necessary, the attribute and status information of the deposited transaction order within the central repository until processing of the transaction order is complete.
23. A method of managing transaction orders in real-time to enable a plurality of
independent entities to cooperatively process a transaction order, the method
comprising the steps of:

-31-
creating a central repository capable of storing ongoing transaction order attribute and status information, the central repository being accessible from a communications network;
registering entities as participants capable of processing at least some portion of a deposited transaction order stored in the central repository;
configuring a central repository controller to facilitate cooperative processing of a transaction order among participants;
enabling participants to access the central repository via the communications network in a manner dictated by central repository controller configuration;
receiving the deposited transaction order from a transaction initiator;
storing attribute and status information associated with the deposited transaction order within the central repository;
managing the transaction order by facilitating real-time interaction between the participants and the central repository via the communications network, wherein the participants cooperatively process the transaction order; and
monitoring and updating, as necessary, the attribute and status information of the transaction order within the central repository until completion of the transaction order.
24. A method of participating in the processing of transaction orders in real-time via a system that enables a plurality of independent entities to cooperatively process a transaction order, the method comprising the steps of:
registering with a central repository controller associated with a system administrator as a participant capable of processing at least a portion of a transaction order deposited within a central repository, wherein the central repository controller is configures by the system administrator;
monitoring attribute information and status information associated with a deposited transaction order by remotely accessing the central repository on demand and in real-time via a communications network;
modifying the attribute information, the status information, or both for the deposited transaction order in real-time via the communications network; and

-32-
processing at least a portion of the transaction order stored within the central repository as directed by the central repository controller.
26. A method of participating in processing of transaction orders as a merchant in real-time via a system that enables a plurality of independent entities to cooperatively process a transaction order, the method comprising the steps of:
registering with a central repository controller as a merchant participant capable of processing at least a portion of a transaction order deposited within a central repository, central repository controller configuration being controlled by a system administrator;
providing merchant participant configuration information to the system administrator for inclusion into the central repository controller configuration;
monitoring attribute information and status information associated with a deposited transaction order by remotely accessing the central repository on demand and in real-time via a communications network;
modifying attribute information, status information, or both for the deposited transaction order in real-time via the communications network; and
processing at least a portion of the transaction order stored within the central repository as directed or executed by the central repository controller.
In the field of transaction processing, a real-time transaction order management system that enables a plurality of entities to cooperatively process a transaction order is disclosed. The system comprises a communications network and a central repository (102). The system also includes a central repository controller (270). A system administrator controls the central repository (102) by configuring the central repository controller (270) to selectively enable and permit deposits of, access to, and modification of the contents of the central repository (102) by other entities. A transaction initiator (120) initiates cooperative processing of the transaction order by depositing transaction order attribute information into the central repository (102). At least one participant selectively accesses and modifies ongoing attribute and status information while processing the transaction order through remote real-time interaction on demand with the central repository controller (270) via the communications network.

Documents:

in-pct-2002-01354-kol abstract.pdf

in-pct-2002-01354-kol assignment.pdf

in-pct-2002-01354-kol claims.pdf

in-pct-2002-01354-kol correspondence.pdf

in-pct-2002-01354-kol description (complete).pdf

in-pct-2002-01354-kol drawings.pdf

in-pct-2002-01354-kol form-1.pdf

in-pct-2002-01354-kol form-18.pdf

in-pct-2002-01354-kol form-3.pdf

in-pct-2002-01354-kol form-5.pdf

in-pct-2002-01354-kol g.p.a.pdf

in-pct-2002-01354-kol letters patent.pdf

in-pct-2002-01354-kol priority document.pdf

in-pct-2002-01354-kol reply f.e.p.pdf

in-pct-2002-1354-kol-granted-abstract.pdf

in-pct-2002-1354-kol-granted-assignment.pdf

in-pct-2002-1354-kol-granted-claims.pdf

in-pct-2002-1354-kol-granted-correspondence.pdf

in-pct-2002-1354-kol-granted-description (complete).pdf

in-pct-2002-1354-kol-granted-drawings.tif

in-pct-2002-1354-kol-granted-form 1.pdf

in-pct-2002-1354-kol-granted-form 18.pdf

in-pct-2002-1354-kol-granted-form 3.pdf

in-pct-2002-1354-kol-granted-form 5.pdf

in-pct-2002-1354-kol-granted-gpa.pdf

in-pct-2002-1354-kol-granted-letter patent.pdf

in-pct-2002-1354-kol-granted-reply to examination report.pdf

in-pct-2002-1354-kol-granted-specification.pdf

in-pct-2002-1354-kol-granted-translated copy of priority document.pdf


Patent Number 213448
Indian Patent Application Number IN/PCT/2002/1354/KOL
PG Journal Number 01/2008
Publication Date 04-Jan-2008
Grant Date 02-Jan-2008
Date of Filing 29-Oct-2002
Name of Patentee YANTRA CORPORATION
Applicant Address 100 NAGOG PARK, ACTON, MA 01720,
Inventors:
# Inventor's Name Inventor's Address
1 YELLURKAR DEVDUTT 35 JACKSON DRIVE, ACTON, MA 01720,
2 CHINTAMANI DEVASHISH 147 KING STREET 3204, LITTLETON, MA 01460, U.S.A
3 VARMA PRAMOND 283 BROWN BEAR CROSSING, NAGOG WOODS, ACTON,MA 01718, U.S.A.
4 STEELE ROBERT E 514 BLOSSON STREET FITCHBURG, MA 01420, USA.
PCT International Classification Number G06F 17/00
PCT International Application Number PCT/US01/13066
PCT International Filing date 2001-04-23
PCT Conventions:
# PCT Application Number Date of Convention Priority Country
1 09/561,360 2000-04-28 U.S.A.