JP2002024618A - Electronic transaction management system - Google Patents

Abstract

PROBLEM TO BE SOLVED: To provide an escrow system using a transaction management system based on a global computer network for allowing correction of a transaction between a purchaser and a seller in real time, and also to provide a transaction management system capable of managing a multifactorial trade including multiple purchasers, multiple sellers, multiple assets, and multiple payments, although only a transaction comprising a single seller, a single purchases, a single asset, and a single payment can be managed in a present commerce management system. SOLUTION: This electronic transaction management system constructed on the global computer network allows multiple trades multiple assets between multiple purchases and multiple sellers. In this electronic commerce management system, a parameter of each trade can be regulated between the multiple purchasers and the multiple sellers when a trade condition is corrected in the middle of the trade.

Description

DETAILED DESCRIPTION OF THE INVENTION

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to electronic transaction management, and more particularly, to an electronic transaction management system operated on a global computer network, which enables participants to dynamically change the conditions defining a transaction. And a system for managing multiple transactions involving multiple participants and multiple assets.

[0002]

BACKGROUND OF THE INVENTION Buyers and sellers involved in transactions often seek assurance that the other party will fulfill the other party's obligations with respect to the transaction. In certain transactions involving relatively expensive or unique items, buyers and sellers traditionally involve a neutral third party, an escrow service. As such, it ensures that the transaction is completed in a satisfactory manner for both the seller and the buyer. Typically, the buyer hands over the escrow service. The seller then hands the goods to the buyer for the purpose of inspection and receipt of the buyer. Once the buyer receives the goods, the escrow service will pay the seller. Conversely, if the buyer rejects the item, the escrow service will typically mediate the dispute between the seller and the buyer. This includes the ability of the buyer to reserve the goods and subsequently be refunded from the escrow service. In the past, escrow was performed manually and not in an automated fashion,
Escrow agents did not allow dynamic, ie real-time, coordination of trading conditions and participants.

[0003]

As the Internet, especially online commerce and B-to-B (business-to-business) transactions become more common, there is a need for an escrow system that optimizes electronic commercial transactions. Has become apparent. The Internet provides a means for buyers and sellers to execute transactions quickly and dynamically. Given the dynamic nature of the Internet, there is a need for an escrow system that allows buyers and sellers to modify transactions in real time, utilizing a transaction management system based on a global computer network. Ideally, users of the transaction management system are free to adapt the transaction according to their needs based on the progress of the transaction. This includes, for example, modifying the terms of the transaction, modifying the number of purchases and sellers, and modifying the goods or services associated with the transaction.

In addition, current transaction management systems can only manage transactions consisting of a single seller, a single buyer, a single asset, and a single payment. With these prior arts, it is difficult to recognize the need for a transaction management system that can manage multiple transactions involving many buyers, many sellers, many assets, and many payments. Was.

[0005]

SUMMARY OF THE INVENTION The present invention provides a global
The present invention relates to systems and methods for enabling modifications to trading conditions and managing multiple transactions during the course of a transaction through the use of a computer network. Transactions governed by the present invention include commercial and consumer transactions, namely the sale and purchase of certain assets between sellers and buyers.

According to a first aspect of the present invention, there is provided a transaction management method including transfer of assets between participants using a global computer network. Initial information about the transaction is first obtained from the participants. The initial information can be entered directly by the participant or retrieved from data previously stored in the computer system used to implement the method. Based on the initial information, a financial model providing the parameters of the transaction is assigned to the transaction. The financial model can also be a preset financial model stored and retrieved on a computer system utilized to perform the method. Alternatively, participants can provide a financial model.

[0007] Using the assigned financial model, a set of transaction instructions is created and communicated to attach the consent of each participant. The transaction instruction includes information identifying each participant, the interests of each participant in the transaction, the target assets, and some performance conditions. Once the instructions are approved, the transaction is managed based on the assigned financial model. Input is received from participants. Based on the input, it is determined whether the participant has fulfilled the conditions specified by the instructions. Based on which conditions have been fulfilled and which conditions have been fulfilled, the participants are instructed to take certain actions including, for example, providing funds and transferring assets. To track and create reports of what happened during the transaction,
A transaction record book is used.

In a second aspect of the present invention, there is provided a method for managing a transaction including a large number of participants, a large number of assets, and a large number of fulfillment conditions through a global computer network. An interface is provided that allows participants to interact with the transaction management system. The interface may be a website or a specially programmed application program interface toolkit. If the interface is a toolkit, the toolkit is installed on a local server or local terminal.

At the start of a transaction, a financial model that specifies performance conditions defining the transaction is assigned to the transaction.
The participant can then modify the financial model to customize the model for the transaction.
The funds associated with the transaction are managed and the transfer of assets between participants is directed. Depending on the terms of the financial model, the payment of funds is preferably made upon completion of a particular transfer related to the transaction or fund.

[0010] In another embodiment, a set of pre-set financial models is maintained, with each model containing conditions generally applied to a transaction. If these pre-defined financial models are assigned to transactions,
Participants can modify the pre-configured model to customize the model for their transaction.

The preset financial model and the model provided by the participant allow the participant to modify the assigned financial model at any point during the transaction. The desired amendments are presented for approval by all unsolicited participants. Amendments are reserved until the approval of the unsolicited participant is obtained. Once the participant approves the amendment, the financial model is amended with the required amendments. Participants who are required to approve the amendment can be limited to those affected by the amendment, or they can seek approval from all unsolicited participants.

[0012] A transaction record book that records events that occur during the transaction period can be maintained for each transaction. In this embodiment, the participant is allowed access to the register to obtain information on the history of the transaction. The register is also used to generate summary reports on transactions. Reports can be generated automatically at the end of a transaction or at the request of participants.

[0013] Third party service providers can also participate in the transaction. If no activity occurs within the period specified in advance, the transaction can be automatically terminated. According to a third aspect of the invention, the system operates on a global computer network, such as the Internet, allowing multiple buyers and sellers to manage multiple transactions in real time, dynamically. The negotiation component of the system causes the system to assign a model to the transaction. The model can be updated, if necessary, based on the participant's request. The negotiation component registers the unsolicited participant's approval for a request to modify the model. The payment component allows the system to manage the funds provided for the assets involved in the transaction. With the fulfillment component,
The system can manage the transfer of assets from the selling participant to the purchasing participant. The fulfillment component also allows the system to receive instructions from the buyer participant regarding the acceptance or rejection of the buyer's assets. The fulfillment component also determines whether other fulfillment conditions have been satisfied by the participant.

In one embodiment, a payment component processes funds for all transactions. The fulfillment component then directs the transfer of all assets involved in the transaction.
Alternatively, the payment component may process funds for a particular asset. In that case, the fulfillment component dictates the transfer of only the specific asset. The clearing component of the system oversees that funds are paid to the appropriate participants based on instructions received from the fulfillment component. In addition, the system includes a transaction log to record events during the transaction. Participants can review the records to see what happened during the transaction. Another embodiment includes a modification component that manages request modifications to the financial model assigned to the transaction during the course of the transaction.

[0015] In a fourth aspect of the present invention, there is provided an application that allows participants to interact with the system. The application has an interface, a command compilation, and a notification subcomponent. The interface can receive commands, requests, or other data related to the transaction from the participants, and then communicate the commands, requests, or data to the system. One embodiment includes a validation subcomponent that verifies the participant's name and password before transmitting the command, request, or data to the system. Additionally, a name and password can be embedded in the command, request, or data before transmitting the command, request, or data to the system. Compiling the commands allows the application to provide the participant with a list of commands that the participant can request to operate the system. The notification subcomponent allows an application to receive transmissions from the system and transport these transmissions to participants. For business participants,
The application is preferably an application program interface toolkit. For non-business participants, the application is preferably a website.

In view of the foregoing, it is an object of the present invention to provide an electronic transaction management system built on a global computer network that allows multiple buyers and multiple sellers to allow multiple transactions of multiple assets. It is to be. It is another object of the present invention to provide an electronic transaction management system that allows multiple buyers and multiple sellers to adjust the parameters of each transaction by modifying the transaction conditions during the transaction.

Other objects and features of the present invention will become apparent from the following description with reference to the accompanying drawings.

[0018]

DETAILED DESCRIPTION OF THE INVENTION [I. Transaction Management System] A transaction management system 1000 in accordance with an embodiment of the present invention allows for a particular transaction environment, such as multiple buyer, multiple seller, and multiple asset scenarios, and for different transaction types to trade. Conditions can be changed. The system 1000 is shown in the box of FIG. System 1
One special inventive feature of 00 is that participants can modify the terms and conditions of a transaction through a global computer network while the transaction is ongoing and in progress.

Each transaction is assigned a financial model with transaction conditions that define the transaction. The transaction conditions specify actions to be performed and conditions applied to the transaction.
The term "terms" refers to all types of specific terms that apply to a transaction. Typically, terms and conditions are based on the type of activity and terms identified,
It is classified into several categories. Examples of transaction terms include certain conditions for a seller to pay for an asset, certain conditions for a buyer to receive an asset liquidation, (such as an inspector)
Includes specific conditions for receiving liquidation for services provided by third parties and specific conditions for the system to receive transaction fees. In the following, the term “assets (asset
The term "s)" includes both tangible assets, such as goods and raw materials, and intangible assets, such as services. Intangible assets also include various rights, including intellectual property rights in the form of, for example, licenses, trademarks, domain names, patents, and the like.

[0020] Preferably, the system 1000 maintains a set of default types of transaction conditions categorized into five categories: defined conditions, financial conditions, fulfillment conditions, notification conditions, and conditional conditions. The defining conditions define key elements of the transaction, such as participants, assets, and pricing. Fulfillment terms specify how to send or receive assets, including data and forms of intellectual property transfer. For example, specific conditions for sending a quantity of goods from one participant to another, specific conditions for one participant to perform service to another, and transferring ownership registration from one participant to another Includes specific conditions for:

In the notification condition, either the purchase participant or the sales participant is notified when the transaction condition is satisfied or fulfilled. For example, the notification may be made via electronic communication such as e-mail or fax. Conditional conditions specify the conditions that must be satisfied for the transaction workflow to proceed to the next step or stage. For example, suppose that the conditional conditions are not fulfilled until a third-party inspection is performed or that payment is not made until the seller submits a copy of the operating license to the buyer,
Specify such. Conditional conditions are extremely flexible. A simple yes and no answer to whether a condition has been met can represent a condition in any context. Conditional conditions can be inserted anywhere in the two workflow steps or stages. Conditional conditions can also be used by users to customize their financial model.

The financial model may be reused. The same financial model applies to many transactions, facilitating the use of standard set conditions in the form of a financial model. Preferably, the system 1000 maintains a set of financial models, each model having a financial model that specifies the standard conditions that apply to the model on the computer used to implement the system 1000. When a transaction is created, a financial model is assigned. The trading participant can then modify the financial model, if desired, to identify those that deviate from the initial terms of the financial model.

Transaction management system 1000 supports a plurality of participants involved in a transaction. For example, the system 100
0 allows multiple buyers and sellers as well as third party participants to be included in the transaction. System 100
Third parties that can be incorporated into a transaction include, for example, shippers, certifying agents, customs agents, carriers, appraisers, rights transfer services, intermediaries, escrow agents,
And renters. The particular third parties that system 1000 can incorporate into a transaction will be determined by the terms of the transaction. In one embodiment, the third party is the system 1
000 can be implemented, and the system 1000 can substitute third-party services for the corresponding internal services of the system itself. For example, a third party that is an escrow agent, if the participant wishes,
A transfer of goods between the buyer and the seller can be performed.

For record keeping purposes, trading system 1000
Preferably maintains a transaction log for each transaction. The system 1000 records entries in a transaction log for each action that occurs on a transaction. Utilizing the transaction log, the system 1000 monitors all participants in the transaction and the history of fees associated with those participants. In addition, the system 1000 can utilize a transaction log to track transaction fees and funds, including, for example, all third party fees, transaction fees, participating funds, and escrow fees. Fees and funds are sorted and tracked based on completion and payment. Preferably, the system 1000 records all payments made during the transaction, partial deposits, multiple payments, and commission installments,
Manage and track. When a participant wants to look at the history of a transaction, they can access the transaction entries at any time. Utilizing a transaction log, preferably, the system 1000 can create customized reports based on different transaction environments and different transaction details for each particular transaction. One important aspect of the system 1000 in which all transaction history can be recorded and stored is that the participant does not need to save the data itself.

A typical transaction managed by the system 100 is preferably a negotiation phase 1100, a payment phase 12
00, an execution stage 1300, and a settlement stage 1400. Further, during each step, a modification procedure is performed, whereby the participants can modify their assigned financial model to change the parameters of their transactions over time. In another embodiment, the system 1000 further provides a time-out procedure to keep the transaction alive and always progress in a timely manner.

[A. Negotiation Stage] FIG. 1 is a flowchart showing a process flow of a typical transaction negotiation stage 1100 executed by the electronic transaction management system 1000. In the negotiation phase 1100, a financial model defining the transaction is assigned, updated as needed, and accepted by each participant.

The participant first initiates the negotiation phase 1100 using either the API 105 or the website 109 interface, as described at the bottom of the system infrastructure in this detailed description of FIG. (Step 1101) A transaction is started by communicating with the system 1000. Trading system 100
Each participant accessing 0 is assigned a unique log-in ID or participant name and password. In addition, some access methods require additional security measures, such as digital certificates or signatures. For each participant, the participant's specific name and password allows the participant to perform one's actions or issue certain instructions for a particular transaction. The set of instructions or actions that a participant is authorized to perform may be further modified based on the stage in progress or the steps of the transaction.

A transaction is assigned a financial model. In one embodiment, participants select a financial model that governs their transaction (step 1102). Here, the participant selects a standard financial model that includes a set of preset transaction conditions preset by the system 1000 to initiate a transaction (step 1102a). System 1
000 preferably stores a library of pre-configured standard financial models on a computer system utilized to implement system 100. Alternatively, system 1000 assigns a financial model to the transaction based on information provided by the participant. In this embodiment, initially, a participant enters data and information related to the transaction into system 1000 using interface 105 or 109 described below. For participants who use the system 1000 repeatedly, the system 1000 can store their data, eliminating the need to enter all of their original transaction-related data. The system then assigns a financial model to the transaction based on the transaction-related data and information provided by the participant. The assigned financial model may be a preset financial model or a model created by the system based on data and information provided by the participants.

In another embodiment, the participant can submit a pre-negotiated overall financial model to the system 1000 (step 1102b). Here, a pre-negotiated financial model is used to define the transaction, rather than one of the standard financial models stored in the system. In one embodiment, the system 1000
Can review the terms of the financial model that are negotiated in advance and approve the model before the transaction proceeds (this step is not shown). When a participant presents a pre-negotiated financial model, the terms of the transaction are typically first specified in a text document such as an escrow instruction document or purchase agreement. System 10 not designed to directly read and interpret textual conditions
One variant of 00 requires manual conversion of business terms into computer-based information. Alternatively, the system 1000 can be designed to have the ability to directly read and interpret the automatically transcribed conditions directly, eliminating the need to manually convert the conditions to computer readable form. This can be accomplished, for example, through an optical text reader or by requiring the system 1000 to present the financial model in a form that can be read directly. From this information, the system 1000 builds an internal representation of the transaction that enables automatic management of the transaction workflow and information.

Once a transaction is defined by assigning a financial model to the transaction, a set of participants is associated with the transaction based on the financial model. Preferably the buyer,
Some participants, such as sellers and third party inspectors, are specifically identified. Other participants can be more generically identified, for example, an escrow agent. Preferably, the relevant participants are limited to representatives who are allowed to access the transaction. An important aspect of the system 1000 is that one type of participant in a transaction can associate multiple members. For example, multiple buyers and multiple sellers can be assigned for a particular transaction. In addition, you can add multiple escrow agents and multiple third-party service providers, including shippers, certifying agents, customs agents, carriers, appraisers, rights registration transfer services, intermediaries, renters, etc. .

Each participant is involved in a transaction, for example, a purchaser,
Assigned roles such as seller or escrow agent. If you act on behalf of an authorized delegate on behalf of a participant and another party accesses the transaction on behalf of that participant, that party will be given the same role as the acting participant. You. After a financial model is assigned to a transaction, participants must register that they approve the model before proceeding with the transaction (step 1104). To accomplish this, the system 10
00 creates a transaction instruction document from the transaction terms defined and stored as part of the financial model (this step is not shown). The system 1000 can create a transaction order at any time, but preferably the order is completed by the time the transaction begins. The system 1000 preferably sends notices, including instructions, to the transaction associated with the transaction, such as by email, fax, or other direct electronic communication between the system 1000 and the participant's local server, computer or terminal. (This step is not shown). The instruction text is preferably transmitted by a file compatible with the server, computer, or terminal used by the participant, or by a link accessible to the participant through the link. The link is, for example, a hypertext link. So the participants
Again, preferably via the electronic communication, a response is made as to whether or not the financial model is acceptable (step 1104). If the participant rejects the terms of the model, the transaction ends (step 1106). If the participant accepts the terms of the model, the transaction will continue.

In one embodiment of the system 1000,
Each buyer or each seller must accept the trading instructions in order for the transaction to proceed beyond the negotiation phase.
Alternatively, all participants, including third party participants, must accept the trading instructions in order for the transaction to proceed. Once the financial model is complete, the system 1000
In step 1108, the participant is notified of the final initial conditions, and in step 1110 the transaction proceeds to the payment phase 1200.

The Condition Modification system 1000 preferably creates conditions on demand to customize a standard financial model or further customize a pre-negotiated financial model to meet the needs of a particular transaction. And adding, updating conditions, or deleting conditions allows the participant to modify and build the transaction (step 1150). For example, a participant can standardize transactions by increasing or decreasing purchasers and sellers, or increasing or decreasing items such as products or services. The participant can also extend the transaction period or change other conditions typical of a transaction. In one embodiment, prior to implementing the modifications to the financial model for the transaction, each added, updated, or deleted condition is presented to obtain the consent of all affected participants (step 1152). , 1154). Alternatively, all participants, including unaffected participants, must approve the amendment.

The modification of the financial model of a transaction can be made at any time during the period of the transaction. Therefore, the modification is not limited to the negotiation stage 1100. Correction procedure is negotiation stage 1100
Is shown in the context of In one embodiment of the system 1000, when a transaction is in the negotiation phase 1100, a change in transaction conditions must be approved by all affected participants (this step is not shown).
In this embodiment, the affected participant must accept a modified financial model in order to proceed to the remainder of the transaction.

If the modification is accepted by the participant, system 1000 notifies the participant and modifies the financial model accordingly (step 1156). If the modification is rejected, system 1000 proceeds to step 11
The rejection is rejected at 58 and the rejection is electronically notified to the participant at step 1160. In any of the above embodiments, the system 1000 reserves the modification until all participants have registered their answers.

The final version of the original transactional financial model is when all participants who have accepted the terms and conditions have accepted the instructions and the applicable modifications. The system 1000 notifies appropriate participants that the original transactional financial model has been finalized.
(Step 1108). The transaction then proceeds to payment step 1200 (step 1110). The system 1000
Preferably, these notifications are sent electronically via the preferred electronic communications described above.

Again, it should be noted that, even after the financial model of the transaction has been finalized, ie, even if it has been fully defined and accepted by the required participants, any modification of the transaction at any stage of the transaction is That is still possible. Depending on the implementation of the system, any modifications proposed after the initial financial model has been approved must be approved by various contracting parties. In one embodiment,
Amendments must be approved by each "affected" participant. "Affected" participants may also be limited to those who are explicitly affected by the proposed amendments. In order for Buyers and Participants to be "affected" participants, they must be affected by the proposed amendments. In another embodiment, the modification must be approved by the escrow agent participant in the transaction as well as the "affected" participant. In yet another embodiment, all participants, including unaffected participants, must accept the modification.

Preferably, the modification can be applied to a condition for which the relevant action has not yet occurred, or the modification can be applied to a completed action. For example,
The transfer of certain assets is not retroactive, that is, they cannot be returned and the original transfer remains in fact. However, the price of an asset can change even after the transfer has taken place. In rare cases, the trading system may not be able to accurately determine whether the proposed amendment was actually made. Therefore, if an escrow agent is involved in the transaction, the final acceptance of the amendment may preferably be granted at the escrow agent's responsibility.

As mentioned above, the appropriate participant, as determined by the implementation of the system 1000, must accept the amendment in order for changes to the implementation of the amendment to be implemented. If the participant accepts the proposed amendment, the trading system 1000 may be accessed using the interface.
Send your consent to. (Preferably, business participants utilize the application program 105 and non-business participants use the website interface 109, as described below in the section on system infrastructure.) And fill in the record book. When all necessary participants have accepted the proposed amendment, trading system 1000 modifies the specific terms of the financial model accordingly. However, in some cases, trading system 1000 cannot automatically perform the specified modifications. In these cases, escrow agent participants intervene and manually edit the transaction.

In accordance with the accepted amendment, trading system 1000 makes the appropriate amendments to the financial model and notifies the appropriate participants that the transaction has been amended (step 115).
6). And it is possible to further modify the transaction even before the currently executing stage. For the consent of the participants,
It is also possible to offer many, simultaneous modifications. In one embodiment, trading system 1000 can create each amendment in the order in which the amendments are accepted. Alternatively, trading system 1000 can delegate to the escrow agent participant the order in which to make the accepted modifications.

[B. Payment Stage] The system 1000 can support at least two payment models. One-time payment and performance payment. The payment model is a procedure in which a buyer participant submits payment for a product related to a transaction. It should be noted that with respect to payment phase 1200, system 1000 supports a flexible clearing and fulfillment model. For example, system 1000 preferably supports two clearing models. This is a transaction clearing and transfer settlement. System 1000 can also preferably support transaction lump-sum and clearing with multiple partial transfers. One alternative is to split the fulfillment into partial fulfillments. Multiple fulfillments can proceed simultaneously between a buyer and a seller participant in a transaction. Performance may be staged at offset intervals. Preferably, system 1000 is designed to allow for other alternative payment, clearing, and fulfillment models that can be defined by trading participants. The execution stage 1300 and the settlement stage 1400 will be described later.

FIG. 2 shows the flow procedure of the payment step 1200. Typically, payment phase 1200 begins after negotiation phase 1100 is completed (step 12).
01). Here, the buyer participant submits the transaction payment (step 1202). Supported payment types are:
Examples include types such as checks, bills, credit cards, debit cards, wire transfers, pre-authorized accounts, and online currency. The payment is then submitted for approval (step 1204). Additionally, the system 100
0 can process payments from multiple participants at one time.

Certain types of payments, such as credit cards, are presented directly to the system 1000 and approved. Other types of payments are notified to the trust account,
The trust account notifies system 1000 that it has received and approved the payment. A trust account is a system 1 for verifying certain types of payments, such as checks and bills.
000 is an external service used. For payments presented to the trust account, the system 1000 may not be notified of the payment offer but only notified of the payment approval. The trust account verifies and approves the payment. When the payment is approved, the trust account notifies the trading system that it has received and approved the payment for the particular participant in the particular transaction. If the payment was made for the fulfillment of a portion of the transaction, rather than the fulfillment of the entire transaction, the trust account identifies further fulfillment (step 1206). The transaction system records the payment information and registers the payment in the participant's transaction log (step 1208).

For payments presented directly to trading system 1000, the participant submits payment information for a particular participant in a particular transaction to system 1000 via the Internet (or API 105 or website 109). If the payment is for a specific performance rather than for the entire transaction, the participant specifies further performance. Once the payment has been verified and approved (step 1204) and a specific or total performance has been indicated (step 1206), the trading system registers the payment in the participant's transaction log (step 12).
08).

The trading system 1000 preferably has two default payment procedures, but participants modify this procedure and use the above-described modification procedure to change the payment phase 1200 to their specific one. Can be customized to the transaction. Payment can be made for the entire transaction. If multiple payments are for the entire transaction, any partial payments will be accumulated until sufficient funds have been received for the full defined performance, at which point all defined payments will be made. The implementation phase for the same is started simultaneously (step 1210).

Alternatively, payment can be directed to a particular performance. The multiple performance payments are accumulated until sufficient funds are received for a particular performance, at which point the performance phase of that performance only is initiated (step 1210). In the system 1000, the participant can modify the terms of the transaction during the payment phase 1200 with substantially the same procedure (steps 1150 to 1160) that is similar to and includes the same steps as the modification procedure described above. At this point in the transaction, the amendments are limited to incomplete terms only.

Once the payment for a particular fulfillment or all fulfillments has been completed and there are no more modifications to the financial model of the transaction, the transaction typically proceeds to the fulfillment phase 1300 (step 1212). [C. Fulfillment Stage] FIG. 3 shows the flow process of the fulfillment stage 1300. Typically, the performance stage 1300
Is started after payment step 1200 (step 13
10). In the fulfillment phase 1300, assets associated with the transaction, such as products, services, titles, etc., are transferred from the seller participant to the buyer participant. In a multi-participant transaction, multiple fulfillments and transfers can be performed simultaneously at different steps according to the fulfillment procedure, and the fulfillments and transfers can occur independently.

Each performance specified is accomplished by one or more transfers. Transfers may include, for example, physical shipping of assets using a liner or cargo ship, electronic transmission of information, performance of services, transfer of deeds between participants, and transfer between third parties on behalf of participants. It can take several forms, such as the transfer of a deed in the United States. In one embodiment, when a merchant transfers goods (step 1).
302) Notify the trading system 1000 that the transfer has begun, that is, the goods have been sent or the title document has been transferred for the specified fulfillment of the particular transaction (step 1303). Sellers have the option,
The system 1000 can also be notified of any of the load tracking numbers. Trading system 1000 records the date and time the transfer started (not shown here). Further, once receiving the shipping notification from the seller, the system 1000 notifies the buyer of the shipping (step 1304).

For some types of transfers utilizing third party shipping services, trading system 1000 may be notified directly by the shipping services that the transfer has started. In another alternative embodiment, to detect when the transfer has begun, the trading system 1000 includes:
Investigate the specific third party shipping services involved in the transaction.

After the buyer participant has received the transfer, either the purchaser or the shipper electronically notifies system 1000 (step 1305). This communication, like all communication between the buyer participant and the system 1000, can be performed electronically via the website 109 or the API interface 105 when transmitted by the shipper rather than the purchaser. Trading system 1000 records the time at which the transfer was completed (this step is not shown). Again, in the transfer using the third-party shipping service,
The transaction system 1000 can receive a notification from the shipping service that the transfer has been completed. Also, in another alternative embodiment, the trading system 1000 is designed to investigate the specific third-party shipping services involved in the transaction to detect when the transfer has ended.

The system 1000 then informs the seller that the purchaser has received the product, and informs both that the inspection phase of the purchaser has started (step 1306).
During the inspection period (step 1306), the buyer participant
There is a specific time period to inspect and accept the transfer (step 1308). In one embodiment, a third party inspector participant is included in the transaction and the purchaser relies on the third party inspector participant during the inspection period. If the inspection period has expired without explicit acceptance or rejection of the transfer, the system 1000 automatically registers the acceptance of the goods and the clearing phase 1400 begins.

When the buyer participant accepts the transfer,
The participant notifies trading system 1000 that the specified transfer has been accepted (this step is not shown). Trading system 1000 preferably records the date and time of receipt and records the completion of the test (this step is not shown). If the transfer satisfies the relevant performance, the performance is also recorded and the transaction proceeds to the clearing phase 1400 (step 1318).

If the buyer participant refuses the transfer,
The participant notifies trading system 1000 that the specified transfer has been rejected (this step is not shown). Trading system 1000 preferably records the date and time of the rejection (this step is not shown). The transaction system then initiates a transfer return, which is the reverse of the original transfer (step 1310). The return transfer is associated with the original transfer. The order of the steps for returning the relocation is the same as that for general relocation. For example, a seller participant has an inspection period (step 1312) and accepts or rejects the transfer within that period (step 131).
4).

If the seller participant refuses to return, transaction system 1000 initiates a dispute resolution procedure (step 1316). For example, trading system 1000
Optionally involves a dispute resolution agency to resolve differences between buyers and sellers. If the seller accepts the return, the system 1000 initiates the checkout phase 1400 and the buyer participant receives a fund return.

Although not shown in FIG. 3, the participant may modify the financial model for the transaction during the fulfillment phase 1300, much like that described above in the negotiation phase 1100 and the payment phase 1200. [D. Settlement Stage] FIG. 4 shows the settlement stage flow process. Once, once the fulfillment phase 1300 has been satisfied and completed, ie, when the buyer participant has accepted the transfer of the goods, or when the seller participant has accepted the return of the goods from the buyer, the clearing phase 1400 begins. (Step 1401). In the settlement phase 1400, the trading system 10
00 monitors the allocation of funds to the appropriate participants (step 1402). In a manner similar to payment phase 1200, system 1000 can manage multiple distributions to multiple participants at one time. Trading system 1000 registers the distribution of all funds in the corresponding participant's log book (this step is not shown).

Clearing may be initiated in several ways. For example, clearing is initiated when all performance of all transactions has been completed. Once all fulfillment is complete, all settlements are performed. Alternatively, clearing begins when the individual transfer is completed. Once an individual transfer has been accepted, liquidation will only be performed on that transfer. The start of the liquidation is preferably defined by the terms of the financial model for the transaction.

In one embodiment, trading system 100
When 0 detects that the clearing condition has been satisfied, trading system 1000 notifies the appropriate escrow agent that the clearing should be performed. Here, trading system 100 does not automatically grant the right to clearing. The liquidation authority rests with the escrow agent. When the escrow agent authorizes payment, the trust account
Allocate the right funds to the right participants. In this embodiment, trading system 1000 does not automatically allocate funds. However, in another alternative embodiment, automatic funding is performed, especially when an electronic agent replaces an escrow agent.

After the trust account has allocated the funds, the trading system is notified that the allocation has been performed for a particular participant in a particular transaction. If a settlement is performed for a particular transfer, the particular transfer cleared is recorded. The transaction system records the clearing information and registers the distribution in the participant's transaction log. Once the distribution is complete, trading system 1000 determines whether there are any remaining items to be transferred from the seller participant to the buyer participant (step 1404). If there are any remaining products, the trading system 1000 will prompt the participant to a payment step 120 depending on whether any payment is required.
0 or indicate the implementation stage 1300 (step 140
4). If there are no remaining goods to be transferred, ie, the transaction has been completed, the system 100
0 ends the transaction (step 1408).

At the end of the transaction, the participant
A customized end report can be requested from 00 (this step is not shown). The closing report reflects specific transaction details based on the specific financial model of each transaction and outlines all event details, including all participants, financial models, payments, fulfillment, and adjustments to liquidation . These reports are prepared using events recorded in each participant's transaction log.

[E. Time Out Procedure] System 1000
Optionally, a time-out procedure 1500 may be included, whereby at any point in the transaction, the system 1000 will close the transaction if the participant has not performed the selected action for a predetermined period of time for the transaction. finish. The timeout procedure 1500 reminds the participant that the transaction is going on, and the system 1000
000 allows to eliminate transactions that are no longer active.

FIG. 5 shows a flow process of the timeout procedure 1500. The system 1000 initiates a time-out procedure 1500 after the transaction-related action is completed (step 1502). For example, the system 1000
Initiates a time-out procedure 1500 after completing the above actions for the negotiation step 1200, the payment step 1300, and the clearing step 1400.

In one embodiment, one day after any action, system 1000 electronically requests the participant to confirm that the transaction is still alive (step 1504). ). If there is no response after 4 days after any action, the system 1
000 delivers to the participant another series of electronic notifications requesting the participant to confirm the status of the transaction (step 1506). At the end of the seven days, the system 1000 reserves or "holds" the transaction until the participant confirms that the transaction is alive or the participant takes another action on the transaction. This is electronically notified to the participant (step 1508).
After nine days without confirmation or action execution, the system 1000 electronically notifies the participant that the transaction is still pending and that the participant
If the user does not confirm or take action, the user is notified that the process will be completed two days later (step 1510). Finally, after 11 days without confirmation or action execution, the system 1000 terminates the transaction and electronically notifies the participant of the termination (step 1512). At this point, the timeout procedure 1500 is complete (step 1514).

The participant can prevent automatic termination of the transaction by confirming that the transaction is alive at some point prior to step 1512 or by performing an action. Additionally, in another alternative embodiment, the participant can modify the timeout period in the negotiation phase 1100 by specifying different periods as part of the selected financial model.

[II. System Infrastructure]
The following illustrates a typical system infrastructure utilized to operate the transaction management system 1000 of the present invention. In FIG. 6, system 1000 is preferably based on a computer system as server 100. The server 100 includes a logical program for implementing the system 1000 and a database. The logic program comprises sub-programs that enable the various steps described above to be executed by the server 100 and ultimately by the system 1000.

In one embodiment, the logic program is
Initially included in computer program products.
As used herein, the term "computer program product" refers to any medium utilized to provide program instructions to server 100.
Examples of these media include removable storage media inserted into a removable storage drive, a hard disk built into a hard disk drive, a disk inserted into a disk drive, and digital media sent to server 100 via a communications network. Including signals. These computer program products are means for providing the server 100 with program instructions. For example,
In an embodiment using the present invention by software,
The software is stored in a computer program product from which it is mounted on a server using a hard drive, a removable storage drive, a disk drive, or a communication interface.

The server 100 preferably has a load
Provides the ability to operate in a cluster with balancing and failover. For example, in one embodiment of the system 1000 running on one primary server 100, if the server 100 becomes overworked, the server 100 may load the work load onto a second server 113 designed to handle the overflow.・ Relocate over. In this arrangement, it is described as operating in a cluster with load balancing.
In this way, the total workload is now balanced between server 100 and server 113.

Regarding the failover, if the main server 100 fails, the second server 11
3 takes over the operation of system 1000. With the fail over function, when the main server 100 malfunctions,
It is ensured that the system 1000 operates without any data or process loss. System 100
0 can be implemented on multiple primary servers 100 for system scalability. Therefore, it is preferable that there be a sufficient number of second servers 113 for each primary server 100 to operate in a cluster with load balancing and failover.

In one embodiment, the system 1000 further includes an application server 11 for handling communications between participants and business logic on the server 100.
5 is included. For business participants rather than general participants, the business partner server 103 is optimally utilized to provide communication between the business participants and the system 1000. The business partner server is preferably a global
It can provide a way to ensure reliable and guaranteed distribution over computer networks.

In order to communicate with the business partner server 103 and, ultimately, the server 100 of the system 1000, the business participant is provided with the customer application program interface toolkit 10.
5 (Customer API) is provided. The customer API 105 includes an interface through which participants can enter commands that they want the system 1000 to execute. The interface also allows participants to enter financial model modifications, submit financial model modifications, send data about transactions, and submit transaction-related requests to the system 1000. Customer API 105 also includes editing instructions and functions to allow participants to direct system 1000 to execute during a transaction. All business participants wishing to utilize the system 1000 to manage electronic transactions preferably have a computer /
Server 106 located on terminal or locally
The customer API 105 is mounted on the top. In this embodiment, customer API 105 is preferably initially included in the computer program product.

The participant preferably transmits instructions, requests, or transaction-related data to the system 1 using the customer API 105.
You will be asked to enter a participant name and password before sending to 000. The participant name and password are used to verify the identity of the person transmitting the command or to confirm that the participant is authorized to execute that particular command or send certain data or requests. Used for requests. Once the customer API 105 verifies that the participant is authorized to execute a particular command or submit a particular request or data, the customer API 105
Communicates instructions, requests, or data to the system 1000. In one embodiment, the customer API 105 incorporates the participant name and password into the command, request, or data before communicating to the system 1000. For example, customer API1
05 communicates instructions, requests, or data to the system 1000, such as an XLM document string incorporating a participant name and password.

In addition, the customer API 105 is
000 notifications can be received and those notifications can be sent to participants. For example, a notification may include a request to accept a financial model, a request to accept modifications to a financial model,
Requesting acceptance of instructions for the transaction, requesting funding for the transfer of one or more assets, requesting the transfer of one or more assets to other participants, requesting the conduct of transaction-related actions, and Includes notification that certain events have occurred. The participant may send instructions, requests, or other data to the customer in a similar manner as the participant sends to the system 1000.
It is possible to respond to these notifications using the API 105.

Every day consumers, ie non-business participants, communicate through a specially designed interface, preferably a website, to communicate commands, requests, and data to the system 1000. Hereinafter, the interface 109 will be referred to as the website 109. The functionality of website 109 and website 10
9. Intercommunication between the participant and the system 1000 is similar to that described above for the customer API 105. Therefore, for the sake of brevity, such operations and details will not be repeated.

In a preferred embodiment, the system 1000
Utilizes object-relational mapping to retrieve attributes and execute instructions by comprehensively setting attributes relevant to the transaction. The ability to globally set attributes and search for attributes in a comprehensive manner minimizes the number of structured search language calls to the database and increases the operational efficiency of the system 1000.

When an instruction is executed, the system 10
00 also preferably creates and distributes electronic notifications to the participants of the transaction, and thus notifies the participants performing any action regarding the transaction. In this method, the participant grasps the current status of the transaction in real time as the transaction progresses. Preferably, the participant is notified based on the notification conditions set in the financial model that defines the transaction.

The system 1000 is compatible with existing online
Can be integrated with business processes. For example, an existing online site may integrate the system 1000 as part of the site in order to transfer goods and funds electronically between the site and customers or visitors to the site. In this method, the system 1000
Said that while existing online sites maintained brand uniformity and a consistent user experience for visitors to those sites,
000 innovative aspects.

The systems and methods described herein may additionally be applied to other commercial and consumer transactions, for example, letters of credit. Unlike the previously described transactions in which one or more buyers and one or more sellers exchange assets or funds, letters of credit require issuers, such as banks and other lending institutions, at the request of the customer. To make sure that you pay for checks and other requests payable. These demand payments generally must meet the conditions specified in the letter of credit before the issuer confirms the request and the payment for issuance. When creating a letter of credit, the system 1000 must first receive information about the letter of credit from the holder or issuer of the letter of credit.
Either the credential holder or the issuer submits this information to the system 1000 using the interface 105 or 109 described above. System 1000 uses this information to assign a financial model to the letter of credit governing all transactions, including the letter of credit. For example, a letter of credit or issuer provides system 1000 with a letter of credit, terms and conditions for granting credit, and an entity authorized to seek bills or demand payments. Based on the information provided, system 1000 assigns an appropriate financial model to the letter of credit.

Thereafter, the third party, or in some cases, the letter of credit, presents the requested payment to the third party via the letter of credit. If all the conditions of the financial model are satisfied, the system 1000 notifies the issuer that the bill of credit has been authenticated. As in the previous embodiment, the key aspects of the system 1000 creating a letter of credit are the ability to dynamically modify the terms of the financial model assigned to the letter of credit while the letter of credit is valid, and the ability to rely on the letter of credit. The ability to make multiple claims from multiple parties attempting to withdraw.

While the invention is susceptible to various modifications and alternative forms, specific examples have been described herein. However, the invention is not limited to the specific forms or methods disclosed, and the invention covers all modifications, equivalents, and alternatives falling under the claims of the invention.

[Brief description of the drawings]

FIG. 1 illustrates a flow diagram of a typical transaction negotiation phase performed by an electronic transaction management system according to an embodiment of the present invention.

FIG. 2 illustrates a flow diagram of a payment phase of a typical transaction performed by an electronic transaction management system according to an embodiment of the present invention.

FIG. 3 illustrates a flow chart of a typical transaction fulfillment stage performed by an electronic transaction management system according to an embodiment of the present invention.

FIG. 4 illustrates a flow diagram of a typical transaction clearing phase performed by an electronic transaction management system according to an embodiment of the present invention.

FIG. 5 illustrates a flow diagram of a typical transaction timeout procedure performed by an electronic transaction management system according to an embodiment of the present invention.

FIG. 6 shows a block diagram of an electronic transaction management system according to an embodiment of the present invention.

Claims (44)

[Claims] Claims 1. A transaction management method for transferring a plurality of assets between transaction participants using a global computer network, comprising: one or more buyers and one or more. Obtaining initial transaction information from a participant, including a seller of the transaction; assigning a financial model that provides transaction terms to the transaction; creating a series of transaction instructions from the assigned financial model, wherein the order comprises: Identify the participants involved in the transaction, the interests of each participant in the transaction, the assets involved in the transaction, and all the terms and conditions of the transaction; and present the transaction instructions for the participant's consent, Managing the transaction based on the assigned financial model after accepting the transaction instruction, wherein the transaction management receives data from the participant Determining whether the participant has fulfilled the conditions specified by the financial model, and instructing the participant to take an action based on the performance of one or more of the specified conditions. Method. 2. The transaction management method according to claim 1, wherein the act of receiving instructions from the participant is an act selected from the group consisting of funding and asset transfer. 3. The transaction management method according to claim 1, wherein the first transaction information is provided by direct input from a participant. 4. The method of claim 1, wherein said initial transaction information is received from data stored in at least one computer system utilized to perform said method. 5. The method of claim 1, wherein the assigned financial model is used to perform the method.
How it is retrieved from the system. 6. The method of claim 1, wherein the assigned financial model is a pre-negotiated financial model provided by a participant. 7. The method of claim 1, wherein the assigned financial model is a financial model derived from initial information provided by a participant. 8. The method of claim 1, wherein the participant further comprises one or more escrow (third party deposit) agent participants. 9. The method according to claim 1, wherein the participant further comprises one or more third party suppliers. 10. The transaction management method according to claim 1, wherein said participants further include one or more escrow (third party deposit) agent participants and one or more third party service providers. Method. 11. The transaction management method according to claim 1, wherein the condition includes a payment detail of each asset, a service assigned to each participant, and a procedure for notifying the participant of an event occurring during the transaction. Method. 12. The method of claim 1, further comprising maintaining a transaction log for each transaction for recording events that occurred during the transaction. 13. The transaction management method according to claim 12, wherein the recorded events include a credit book of funds, a credit book of funds, and an asset transfer performed by a participant. 14. The transaction management method according to claim 1, further comprising: registering a required amendment, withholding the amendment until approval by an appropriate participant, and determining whether or not to accept the amendment. Participant modifies the financial model during the continuation of the transaction by conducting a vote and, if the appropriate participant has registered an amendment, modifying the financial model in accordance with the required amendment A method with enabling. 15. The transaction management method according to claim 14, wherein the voting participant is a participant affected by the modification. 16. The transaction management method according to claim 14, wherein the voting participant is both a participant affected by the modification and a participant not affected by the modification. 17. The transaction management method according to claim 1, further comprising: assigning a participant name and a password to each participant, and submitting the participant name and the password to each participant when providing information. And verifying the participant name and password before processing the provided information. 18. A method of managing transactions through the use of a global computer network, wherein the transaction involves a participant and one or more assets,
Method comprising: providing an interface for participants to communicate with a transaction management system implemented on a global computer network including one or more buyers and one or more sellers. Assigning a financial model to the transaction, the model specifying one or more conditions that define the transaction, enabling participants to modify the model to customize the model of the transaction, Manage funding for the transaction and direct the transfer of assets between participants. 19. The method of claim 18, further comprising paying the fund when a transaction associated with the fund has ended. 20. The method of claim 18, further comprising maintaining a pre-defined set of financial models, each model having conditions that match a transaction type. how to. 21. The method of claim 20, further comprising allowing a participant to select a pre-defined financial model to define the participant's transaction. 22. The method according to claim 20, further comprising automatically assigning a preset financial model to the transaction based on initial information regarding the transaction provided by the participant. 23. The method of claim 20, further comprising the participant being able to modify the selected financial model to the participant's transaction. 24. The method of claim 18, wherein said interface is an interface selected from the group consisting of a website and an application program interface toolkit. 25. The method of claim 18, wherein the step of allowing a participant to modify the model comprises: a method wherein all of the participants are assigned after the model is assigned. Presenting the desired amendments to obtain consent, allowing the participant to modify the model assigned to the transaction, suspending the amendment until the consent of the participant, The model is modified by enabling registration of the participant's consent and performing the modification after receiving the modification consent of each participant. 26. The method of claim 18, wherein the step of allowing a participant to modify the model comprises: a method wherein after the model is assigned, the modification is affected by the modification. Presenting the desired modifications to obtain the consent of the receiving participant, allowing the participant to modify the model assigned to the transaction, suspending the modification until the affected participant's consent, Modifying the model by enabling the registration of the consent of each affected participant in response to the modification, and performing the modification after receiving the modified consent of each affected participant. 27. The method according to claim 18, further comprising integrating a third party service provider into the transaction, wherein the third party service provider is a shipper, certifier, customs broker. A method characterized by being selected from the group consisting of agents, carriers, appraisers, rights transfer services, intermediaries, escrow agents, and renters. 28. The method of claim 18, further comprising maintaining a transaction log that records events that have occurred within the transaction. 29. The method of claim 28, further comprising providing a participant with access to the transaction log to obtain progress information regarding the transaction. 30. The method of claim 28, further comprising creating a summary report of the transaction based on the transaction record upon completion of the transaction. 31. The method of claim 30, wherein the report is created automatically upon completion of the transaction. 32. The method according to claim 30, wherein the report is created at the request of a participant. 33. The method of claim 18, further comprising terminating the transaction if no action is presented by the participant within a predetermined time period. 34. A global computer network that allows one or more buyers and one or more sellers to electronically make one or more transactions in real time, over time. A transaction management system operating on a system comprising: a negotiation component for assigning a model to a transaction, updating the model on demand, and recording the acceptance of the model by a trading participant; A payment component that manages payments for assets, including one or more assets, related to the transfer of assets from a selling participant to a purchasing participant, and where the purchasing participant receives the asset A fulfillment component for receiving instructions from the purchasing participant regarding the rejection or rejection, and said fulfillment Liquidation components in response to orders received from components pay the funds to the appropriate participants. 35. The transaction management system according to claim 34, wherein the system has a payment for the entire transaction in a payment phase and directs a transfer of all assets associated with the transaction in a fulfillment phase. Equipped system. 36. The transaction management system according to claim 34, wherein the system has payment for a particular transaction in a payment phase and directs a transfer of a particular asset associated with the transaction in a fulfillment phase. A system comprising: 37. The transaction management system according to claim 34, further comprising a transaction log for recording an event occurring during the transaction, wherein the transaction log is accessible by a participant. . 38. The transaction management system according to claim 34, further comprising a modification component for managing required modifications to the model during a transaction. 39. A global computer that allows one or more buyers and one or more sellers to electronically perform one or more transactions electronically over time in real time.・
An application program for communicating with a transaction management system operating on a network, the application program comprising: receiving data from the participant and transmitting the data to the system, wherein the data is An interface comprising instructions, requests, transaction-related data, transaction participant information, transaction asset information, transaction fund information, and transaction modifications in the drunk court; compilation of instructions that the participant can request the system to perform; A notification sub-component for receiving a communication from the system and routing the communication to the participant. 40. The application program according to claim 39, wherein the application program is an application program interface toolkit. 41. The application program according to claim 39, wherein the application program is a website. 42. The application program according to claim 39, further comprising a verification subcomponent for verifying a participant name and password entered by the participant before transmitting the data to the system. 43. The system of claim 42, further comprising a verification subcomponent that embeds the participant name and password in the data after checking the participant name and password, but before transmitting the data to the system. Application program. 44. A transaction management method for transferring a plurality of assets between transaction participants using a global computer network, comprising: one or more buyers, one or more. Obtain initial transaction information from participants, including one or more sellers, one or more escrow agents, and one or more third-party suppliers; a pre-established financial model, pre-negotiated Selecting from a group consisting of a financial model and a financial model derived from the initial transaction information, a financial model providing transaction conditions and assigning it to said transaction;
In creating a series of trading instructions from the assigned financial model, the instructions identify the participants involved in the transaction, the interests of each participant in the transaction, the assets associated with the transaction, and all the conditions related to the transaction. And presenting the transaction instruction for participant acceptance and managing the transaction based on the assigned financial model after the participant accepts the transaction instruction, wherein transaction management comprises: Assigning a participant name and password to each participant, requesting each participant to submit the participant name and password when providing information, and verifying the participant name and password before processing the provided information Determining whether the participant has fulfilled the conditions specified by the financial model; and instructing the participant to act on the participant based on one or more of the specified conditions. And in that the act is selected from the group consisting of providing funds, transferring assets, and providing Dansan services, maintaining a transaction log that records events that occur during the transaction, and In allowing the participant to modify the financial model during, the enabling step registers the required modification, suspends the modification until approval by an appropriate participant, and accepts or rejects the modification. Voting for the appropriate participant in order to modify the financial model using the requested amendment if the appropriate participant registered acceptance of the amendment in the previous period; A method comprising: