"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
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
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
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 real-
time 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
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.
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 taking 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
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.
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.
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.
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 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.
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, nice 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.
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
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
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
attributes associated with a particular transaction. Upon transaction initiation, these attributes
provide enough information to enable the transaction to be folly 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
i
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.
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 Til 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
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
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.
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 (TIT) 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.
hi 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
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
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. In 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
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 tliis 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
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
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
conglomorate'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
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,
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
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
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-13 On 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 160a-160n, such as carrier rating information providers, escrow agents,
etc.
In this embodiment, every supplier 130a-13 On 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-1230h. Market interfaces 1220c and 1220d each have participatory relationships
with three suppliers, including one common supplier 1230e. Likewise, market interfaces 1220d
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
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.
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.
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.
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.
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:
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
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.