Usage Scenario:
A Buying Contract that Utilizes Escrow
Author(s): Michael Kifer
URL(s) or other references: None so far
Domain: Contracting and negotiation
A buyer wants to buy something from an on-line store. This service involves two other independent services, a delivery service and a financing service. Due to the high stakes involved (e.g., it is a Rolls-Royce purchase), the deal involves an escrow account where the buyer deposits some amount of $$.
The buyer and the seller (represented by the broker) have conflicting interests in the deal. They do not trust each other completely. The seller does not know if the buyer is serious. The buyer does not want to loose 100K in an on-line deal. Other services involved here, such as delivery and financing are unpredictable. The former may loose the Rolls-Royce and the latter may not approve the loan.
This can be made more complex by adding an escrow broker, an insurance service, and the like.
Buyer wants to get the good or, at least, not loose money due to lost goods. Seller wants to sell goods and wants protection from buyers who are not serious. This is why escrow is required.
Same as for the overall scenario.
Both the customer and seller should be able to analyze the contract and determine if they can achieve their goals.
Same as before.
Buyer wants to buy; Seller wants to sell; nobody wants to loose. Both must understand the logic in which the contract is expressed and need to specify their particular requirements in that logic.
None.
The contract tells what the buyer must do, what the seller must do, etc. Each actor has several options, which it can exercise. Therefore, the whole scenario has a game-theoretic flavor.
The contract (or, rather, the offer that Seller gives) is described from Buyer's point of view in terms of which actions Buyer can control and which are beyond his control.
All these processes can happen over time. Note: Buyer controls the decision to cancel here.
Note: Seller is not free to decide which action to take (i.e., deliver or take escrow). It all depends on what Buyer does.
In the latter case, the bank can approve the loan (in which case Buyer pays using the loan) or reject the application (in which case Buyer is forced to cancel). Note: Buyer and Seller have no control over the outcome of the financing service action (i.e., whether the loan will be approved or not).
Insured service can deliver or loose the good. In the latter case, Buyer gets the insurance money. Note: Buyer and Seller have no control over the outcome of the delivery service action (i.e., if the delivery happens or the item is lost). But the decision whether to use insured delivery or the uninsured one is with Buyer.
Buyer might want to do some reasoning about the contract. For instance, he may propose a constraint, such as
Some domain-specific ontology that describes the meaning of payments, escrows, etc.
Requires a logic that supports rules, process modeling, and game-like situations described here. The first two requirements are met by Concurrent Transaction Logic (CTR). The latter is supported by an extension to CTR, Concurrent Transaction Logic for Services (CTR-S), which we are currently working on.