An automatic tool for checking multi-party contracts

09/04/2018 ∙ by Adilson Luiz Bonifacio, et al. ∙ 0

Contracts play an important role in business where relationships among different parties are dictated by legal rules. The notion of electronic contracts has emerged mostly due to technological advances and the electronic trading among companies and customers. Thereby new challenges have arisen to guarantee reliability among the stakeholders in electronic negotiations. In this scenery, the automatic verification of electronic contracts appeared as the solution but as a new challenge at the same time. An important task on verifying contracts is concerned of detecting conflicts in multi-party contracts. The problem of checking contracts has been largely addressed in the literature, but we are not aware about any method and tool that deals with multi-party contracts and conflict detection using a contract language. This work presents an automatic checker, so-called RECALL, for finding conflicts on multi-party contracts modeled by an extension of a contract language. We developed an automatic checking tool and also applied it to a a well-known case study of selling products that is characterized by multi-party aspects of the contracts. We also performed some experiments in order to show the tool performance w.r.t. the size of contracts.

READ FULL TEXT VIEW PDF
POST COMMENT

Comments

There are no comments yet.

Authors

page 1

page 2

page 3

page 4

This week in AI

Get the week's most popular data science and artificial intelligence research sent straight to your inbox every Saturday.

1 Introduction

Business relationships have become increasingly more customary among companies and customers thanks to technological advances. In this setting new challenges have arisen on business negotiations seeing that interrelationships among the stakeholders are liable to disagreements. To overcome potential disagreements transaction rules have been introduced to avoid conflict situations based on the notion of legal contracts.

Contracts are composed by clauses that describe business rules in a setting with several involved parties. Then, obligations, prohibitions, and permissions can be enforced by rules which express rights and duties over the parties of a contract. A contract can be, in general, classified in three groups: unilateral contracts, when only a single party assumes responsibilities; bilateral contracts, when responsibilities are upon two involved parties; and multilateral, or multi-party contracts, when several parties assume responsibilities 

[1].

Conflicts may arise in a contract when two or more parties are involved by associated rules, especially for multi-party contracts, where several parties are simultaneously related to each other. An ambiguous description of a contract, e.g. given in natural language, may result in inconsistent relationships. Problems of this nature can be avoided or mitigated when contracts are more accurately described by formalisms. A precise description of contracts guarantees more reliability in their interpretations. However, even making use of formalisms inconsistencies and ambiguities can be introduced in a contract specification. Therefore an automatic verification of contracts specified by an appropriate formalism is desirable to avoid conflicts.

Formal verification of electronic contracts have been largely studied in the literature [23, 5, 12, 19]. Some approaches were proposed to either guarantee certain properties on the contracts or detect undesired situations, such as deadlocks, and unnecessary or conflicting clauses. Conflicts are characterized by contradictory clauses which, in turn, can incur in incoherent rules of a contract. Hence it is desirable that a conflict may be detected and solved in a contract negotiation process before running the contract in practice.

In this work we treat a more complex class of contracts, so-called multi-party contracts which are specified by an extended contract language. The classical Contract Language (CL) has been proposed by Prisacariu [20] to comprise concepts of the relativized deontic logic [10] and the dynamic logic [8] to specify multi-party contracts. We then propose a conflict detection method for multi-party contracts modeled by this extended contract language, named Relativized Contract Language ([4]. Our method allows for more complex contracts where parties’ relationships and their designations are deemed important. The method has been developed and named by elativizd ontrct anguage anayser (RECALL)111Available on http://recallcontracts.github.io. We also model and check a real-world case study by using the RECALL tool. The presented case study aims in twofold: first, it provides a proof of concept on the RECALL’s functionalities; and secondly, it allow us to check a well-known problem in the literature. We further describe some practical experiments to evaluate the efficiency and effectiveness of our tool. We randomly generate different groups of multi-party contracts where each experiment evaluates aspects related to scalability, processing time, and resource consumption.

The remaining of this paper is organized as follows. We survey some works that are more closely related to the conflict detection problem for multi-party contracts in Section 2. In Section 3 we motivate our work introducing a real case study for a sales contract. We give the foundations of our proposed method in Section 4. Section 5 presents the RECALL tool and its practical application over the real case study based on trading rules modeled and checked using . In Section 6 some experimental results are presented to evaluated the proposal. Section 7 gives some concluding remarks and future directions.

2 Related work

Multi-party contracts are defined by agreements signed by several stakeholders in a business deal. A contract of this nature cannot be decomposed within a set of bilateral contracts, where the arrangements are firmed by stakeholders in pairs, without loss of information [23]. Therefore multi-party contracts are, in fact, more complex to be modeled and verified because they require suitable formalisms to appropriately express manifold relationships and particular identifications. According to Fenech et al. [5], particular responsibilities cannot be placed in a bilateral contract modeled by  [18].

By contrast, Herrestad and Krogh [10] have proposed an extension of the standard deontic logic [11], so-called relativized deontic logic, to identify stakeholders in relationships. The relativized deontic logic personifies deontic operators, allowing for more complex scenarios when several parties are simultaneously involved in a deal. Unfortunately, a formalism to precisely deal with the remaining aspects of , aside from the standard deontic logic, is lacking.

Fenech et al. [5] then proposed a conflict detection method for bilateral contracts based on . Thus we extend their classical mechanism to support the analysis of multi-party contracts. First, we extend the contract representation and then we propose a conflict detection algorithm for the extension.

We represent our contribution and its relation with logics, languages, and techniques proposed in the literature by the scheme depicted in Figure 1. The rounded rectangles and dashed arrows indicate our contributions.

Deontic Logic

Dynamic Logic

conflict detection

Relativized Deontic Logic

Multi-party conflict detection

using

using
Figure 1: Scheme of our contribution.

3 A Real-world Multi-party Contract

In this section we start with the real-world case study that motivates our work and also supports the proof of concept in the tool testing. The case study looks into a well-known business model of selling products [2]. In the following subsections we, first, describe the electronic sales contract and in the sequel present multi-party aspects that characterize it.

3.1 The Sales Contract

Electronic transactions have become a fairly common practice. Although there are several consumer protection laws, barely formulated agreements can remain on a contract in such a way that frauds and misunderstandings may still arise among the stakeholders. Electronic commerce become more complex when its business model contains interdependencies among the participating parties. Interdependencies are, in fact, necessary to precisely express the complexity of a certain contract.

For instance, in a bilateral sales contract we cannot guarantee that the seller and the buyer comply with the agreement upon the payment and the delivery of the traded product. On the one hand, the seller cannot deliver the product to the buyer before the latter has paid it. In this case, the seller is unprotected once the buyer in turn does not pay the product and the former is harmed. On the other hand, if the buyer pays for the product before receiving it, then the seller might not deliver the product and the agreement comes to a violation. In any case both are unprotected and the contract can be violated either due to the lack of payment or not receiving the goods.

Financial agencies are then used to intermediate payments in a electronic commerce, and thus avoiding contractual breaches. In the present case study, financial transactions are intermediated by a bank to which payments are accomplished by a buyer but the amount is transfered to the seller only after the respective product is delivered to the buyer. Thus we guarantee that a buyer is not harmed since the bank can reimburse him if the product is not delivered. In addition, internal rules and specific regulations of the involved parties can also be included in a contract.

Next we present all arrangements and rules of the sales contract. The stakeholders in the case study are: buyer, seller, bank and shipping company. A buyer buys a product from a seller, the shipping company (or carrier) is in charge to deliver the product to the buyer, and the bank intermediates all financial transactions. Besides the agreements we need to take into account internal rules of the stakeholders. For instance, the carrier need not to deliver an order while the shipping cost has not been paid by the seller. In addition payments are accomplished by the bank only after it receives an appropriate notification in order to prevent frauds. Now we fully describe the contract:

  1. [Sales Contract]

  2. Buyer performs the purchase of a product from the Seller.

  3. Buyer is obliged to pay the product to the Bank.

  4. Bank must send the notification about product’s payment to Seller.

  5. After Bank notifies the Seller about the payment, Seller is obliged to send the product by means of Carrier and pays the product’s shipping costs to the Bank.

  6. Carrier must deliver the product to Buyer.

  7. After the product is delivered, Buyer is obliged to acknowledge the Bank about the product delivery, whereas Carrier must notify the Seller that the product was delivered to Buyer.

  8. When the Seller is notified about the product delivery, the Seller is obliged to notify the Bank allowing the payment of the shipping costs to the Carrier.

  9. When Buyer notifies the Bank that the product was received, Bank releases the payment amount to the Seller.

  10. Bank must pay the shipping costs to the Carrier after Seller makes the payment of the referred amount.

  11. [Internal Bank Rules]

  12. Bank is prohibited to pay Seller till it has received a proper notification from Buyer confirming the product delivery.

  13. Bank is prohibited to release the payment of shipping costs for the Carrier till Seller notifies the bank.

  14. [Internal Carrier Rules]

  15. Carrier is prohibited to deliver the product till Seller has paid the shipping costs.

To easy the reference and to keep the notation uncluttered we define some symbols and key words for the contract. The stakeholders are also called by individuals and we refer them by symbols as defined in Table 2. Similarly, actions related to the contract are given in Table 2.

Individual Symbol buyer b seller s bank k carrier c
Table 1: List of individuals.
Action Description buyProduct Buy a product payProduct Pay the product notifyProductPayment Notify the product payment sendProduct Send the product deliverProduct Deliver the product notifyProductReceipt Notify the product receipt notifyProductDelivery Notify the product delivery payShippingCosts Pay the shipping costs releaseShippingCosts Release the shipping costs
Table 2: List of actions

3.2 Multi-party Aspects of the Contract

Bilateral contracts are not able to establish multi-party relationships composed by more than two individuals [24]. Hence a multi-party contract cannot be broken down into a set of bilateral contracts without loss of information. In this section we have no intention to formally prove such property, provided that other works have studied it [23, 9]. Instead we aim at showing that the sales contract is, in fact, characterized by multi-party aspects. Therefore we make use of Petri Net models [17, 21, 14] to specify the sales contract. Petri Net is a well-known formalism that can appropriately describe distributed systems which, in turn, is characterized by different components communicating to coordinate to each other in whole system.

A basic Petri Net model is defined by a collection of directed arcs connecting places and transitions. Places may hold tokens which represent the state or marking of a net according to its assignment by tokens to places. Arcs can only connect places to transitions and have capacity one by default. Otherwise the capacity must be explicitly marked on the arc. A transition is enabled when the number of tokens in each of its input places is at least equal to the arc weight going from the place to the transition. Tokens of input places are moved to output places when an enabled transition is fired according to arc weights. After the transition firing, a new marking of the net is obtained as the result, a state description of all places.

The Petri Net model for the sales contract is depicted in Figure 2. The specification basically follows the previous Sales Contract description. The resulting model is composed by eleven places, , nine transitions, , and has one token marked at place to start the execution. This token at place enables transition that can be fired at any time. When the buyer performs the purchase transition fires and produces one token at place . It means that transition is enabled to fire, i.e. buyer can pay the product. When is fired one token is produced at places and . It means that the buyer is waiting for the product (place ) and the payment was received by the bank (place ).

Figure 2: Petri net for the sales contract.

Note that the marked token at place is not enough to enable transition because its precondition (arc from to ) is weighted by two tokens. However transition is enabled by and when it is fired the bank notifies the seller about the payment, producing one token at place . It represents that the seller must send the product by means of the carrier and also must pay the shipping costs. When both conditions are satisfied transition is then fired and one token is produced in each place, and . Place reflects that although the bank holds the shipping costs, the carrier cannot be payed yet (transition ), unless the product is delivered to the buyer (transition ). But place denotes the product is already in tenure of the carrier and enables transition . The product is effectively delivered to the buyer when transition is fired and another token is produced at place .

At this point place has two tokens and it enables transition . After transition is fired one token is produced at place , and another one is produced at place . The latter says the bank is notified by the buyer as concerning the product receipt, and the former says the carrier has notified the seller about the delivery. Hence transition is enabled and after it is fired another token is produced at place . Now place enables transition and when is fired the carrier receives the shipping costs. The payment is represented by the token produced at place . On the other hand, that token produced at place enables transition which means that the bank can release the payment to the seller. After is fired one token is produced at place meaning that the seller has received the payment. The final marking of the net with one token at place and another token at place means the trading is already finished.

We know that different bilateral contracts cannot share information and actions which are preconditions cannot be assured to happen simultaneously on distinct bilateral contracts. Thus we notice that when the sales contract is modeled by separating bilateral contracts where one individual of a subcontract is not directly related to other individual of a distinct subcontract the expressiveness of whole business model cannot be properly captured.

It is a simple matter to see that whether we have both seller and carrier separated in two different bilateral contracts we would have a setting where the carrier could not notify the seller about the delivery. So one cannot guarantee that the seller would notify the bank to release the shipping costs to the carrier which, in turn, could be harmed in the trading. We can observe this scenario in the Petri Net model depicted in Figure 2. Had the transition not been fired to produce one token at place , transition would not also be fired to produce the required token at place . Then the transition which is weighted by two would not be enabled and so place would never take the required token to denote the end of the process. Such situations render to unstable contracts since the required relationships and preconditions cannot be properly modeled.

4 Multi-party conflict detection method

We extend the classical mechanism proposed by Fenech et al. [5] to support the analysis of multi-party contracts. The conflict detection method comprises, basically, two steps: the construction of an automaton to represent the contract; and the conflict detection analysis that is applied on this automaton.

The conflict detection process for multi-party contracts also requires an appropriate formalism to specify agreements of rights and duties under the perspective of several stakeholders. In this case, business rules rely on specific parties of a contract, in contrast to bilateral relationships where rights and duties are globally assumed in the whole contract. The extension proposed in this work comprises on: extending the syntax to support relativization; defining a semantics for operators according to new syntax; modifying the automaton construction based on the new semantics; and adapting the conflict detection algorithm regarding the new trace semantics. Next subsections detail each step of our method and also give part of the case study of a sales contract as a running example. We make it clear that our work has a more practical leaning and it is not our intention here to formally prove the correctness of the proposal.

4.1 Extension of  syntax

Revitalizations upon deontic operators were proposed by Herrestad and Krogh [10]. Particular individuals can be associated to deontic operators to allow individual identification when actions are performed in a contract. Beyond the global operators, as defined in the standard deontic logic, relativized operators can explicitly specify senders, receivers, or both on the operators. The classical is defined over the standard deontic logic and over the dynamic logic, but no relativization is allowed by the language.

A multi-party contract can be defined by a set of clauses, which in turn, are composed by obligations, permissions, prohibitions, and dynamic modalities over actions. Formally, let be a contract, where is the set of individuals (parties) of the contract. The set of deontic modal operators is , where is an obligation, ) is a permission and is a prohibition. The set defines all possible relativizations, and is the set of basic actions, where is an action associated to the operator , with . For instance, indicates that the action must be performed by all individuals of according to the deontic operator . On the other hand, indicates that the action , associated to , must be performed by . Finally, says that the action associated to operator must be performed by and received by . For the sake of simplicity, we omit the symbol , which represents a global operator. Considering dynamic operators, indicates that after action is performed, a contract takes place. The relativized dynamic operator denotes that is valid if the individual performs . Lastly, indicates that takes place if performs to .

The syntax is presented in Figure 3.

Figure 3: Relativized Grammar

A contract can then be derived following this grammar according to the conventional definitions. Penalty mechanisms, denoted by a subscript , can also be defined on operators of obligation and prohibition when violations occur.

We also note that actions can be composed by different operators: choice between two actions denoted by , concurrency between actions specified by , priority on actions given by , as well as the special actions and to represent, respectively, the contract violation and the execution of any action. A dynamic operator allows the iteration operator over an action, and the negation of an action , which means that any other action can be performed instead of .

Decompositions and equivalences obtained from the grammar extension, likewise in , define the semantics. Figure 4 presents some decompositions over , and the equivalences follow as proposed by Meyer [13].

Figure 4: Decompositions of

For the sake of illustration we completely specify the sales contract according to the Syntax as depicted in Figure 5. For instance, see the clause described at line (10) now specified at line (19) in .

1{b,s}[buyProduct](
2 {b,k}O(payProduct)^
3 {b,k}[payProduct](
4  {k,s}O(notifyProductPayment)^
5  {k,s}[notifyProductPayment](
6   {s,c}O(sendProduct)^
7   {s,k}O(payShippingCosts)^
8   {s,k}[payShippingCosts](
9    {s,c}[sendProduct](
10     {c,b}O(deliverProduct) ^
11     {c,b}[deliverProduct](
12      {b, k}O(notifyProductReceipt) ^
13      {c, s}O(notifyProductDelivery) ^
14      {b,k}[notifyProductReceipt]({k,c}O(payProduct)) ^
15      {c, s}[notifyProductDelivery](
16       {s, k}O(liberateShippingCosts) ^
17       {s, k}[liberateShippingCosts]({k,c}O(payShippingCosts))
18)))))));
19{b,k}[(!notifyDelivery)*]({k,s}F(payProduct));
20{s,k}[(!liberateShippingCosts)*]({k,c}F(payShippingCosts));
21{s,c}[(!payShippingCosts)*]({c,b}F(deliverProduct));
Figure 5: The sales contract specification

4.2 semantics

We extend the trace semantics proposed by Fenech et al. [5] now upon the notion of relativization given by Herrestad and Krogh [10]. The trace semantics on is now defined by sequences of actions, which can be relativized, that run in a contract. A trace is composed by a pair: a action trace and a deontic trace. The action trace is composed by relativized actions putting together information upon the action associated to an operator, as well as the involved parties. The deontic traces are also preserved over the deontic operators with relativizations. Hence the extension allow us to deal with relativized operators of relativized syntax.

Formally speaking, a relativized action is given by a tuple , where is a basic action and are individuals, a sender and a receiver, respectively, associated to . The set of relativized actions is then obtained by , combining basic actions and individuals. In addition, the set of concurrent relativized actions is obtained by the power set , where concurrent relativized actions can be combined to each other. An action trace is, formally, defined by , where gives the concurrent actions at position on the trace. Let be a trace with , , we get . The length of a trace is and the empty trace is denoted by . A sub-trace is written , where is the initial position and is the final position on the trace. An infinite trace denotes a sub-trace starting at position . The concatenation of two traces and follows the standard definition, denoted by . The union operation over two deontic traces is defined by with . The set of deontic modalities upon actions is given by . Thus denotes the deontic, where each position of gives a set of representation combinations of deontic modalities, with for all . Representations of distinguish conjunctions and disjunctions over the deontic modalities.

To illustrate the definitions and notation, let and be contracts. The deontic traces are and , respectively. In the former, we have a conflict due to the obligation and the prohibition over the action . In contrast, in the latter contract any conflict can be found since the choice operator into the obligation over actions and does not violate the prohibition over .

The new trace semantics also deals with global deontic modalities, where a concurrent relativized action denotes that the action associated to the modality must be performed by all individuals of the contract. For instance, generates the action trace . If the modality is relativized, i.e. , we get the trace . Similarly, a directed modality produces the trace .

We also redefine the satisfaction relation on the semantics of operators to determine whether the action trace and the deontic trace satisfy the contract . The trace semantics is partially described in Figure 6, where is a clause (or contract), is a relativized action and are individuals. Formulas comprise actions that are composed by the operators of choice, concurrency and sequence (See Subsection 4.1).

Figure 6: semantics

The satisfaction relation follows the rules of the classical semantics However, specific individuals need to be checked on the trace when operators are relativized with a sender, a receiver, or both, to satisfy the formula. In the following example, , at least one relativized action in must be the action which, in turn, must be performed by to another individual . Formally, we have . A dynamic modality, , does not introduce deontic information on deontic traces. Therefore one considers only the action trace in the satisfaction verification. The remaining modalities of are obtained according to the standard derivation as described in the original semantics [5].

4.3 Automaton construction

To proceed with the process of detecting conflicts on a contract an automaton thats represents it must be constructed. We adapt the classical algorithm [5] to detect conflicts on multi-party contracts described by . New deontic operators are taken into account by the algorithm and new criteria with relativizations are considered on detecting conflicts.

We formally define an automaton , representing a contract , by , where is the set of states, is the set of concurrent relativized actions, is the set of deontic labels, is the set of individuals, is the initial state, is the labeled transition relation, is the violation state, is a labeling function of states with contract decompositions, and is a labeling function of states with deontic information from the decompositions. A sequence of concurrent relativized actions from that defines the action trace is a string of the accepted language by the generated automaton.

The construction is given by function and it is described by Algorithm 1. Function decomposes a given contract according to the relativized actions to be performed on it. We illustrate a decomposition over a relativized dynamic operator and a relativized action . We get when and . Otherwise, . Note that the complete definition of also considers global and directed dynamic operators, deontic operators of obligation [3], prohibition and permission as well as compound actions of dynamic operators according to the syntax and the decomposition rules of Subsection 4.1.

input : State of
output : Automaton
begin
       if searchConflicts (s) then
             conflict found in state ;
            
      else if  then
             ;
            
      else if  then
             ;
             ;
            
      else
             for  do
                   ;
                   if  then
                         ;
                        
                  else
                         ;
                         ;
                         ;
                         ;
                         constructAutomaton ();
                        
                   end if
                  
             end for
            
       end if
      return ;
end
Algorithm 1 Contract automaton construction

Algorithm 1 also makes use of an auxiliary function for deontic labeling. The function labels every state of the automaton after a decomposition with deontic information according to the deontic trace . Given a contract, then returns a subset of that provides the decomposed contract at a state with the deontic operators and their respective actions. An empty set is returned by the function when only dynamic operators and no deontic information are presented on the contract. Deontic information obtained by are at that time associated to states that represent the decompositions obtained by function . The whole process stops either when a conflict is found or if whole contract were decomposed into atomic clauses. An atomic clause of a contract is a clause that contains only basic actions associated to deontic and dynamic operators. At this time, the atomic clauses are evaluated to satisfaction, violation or conflict.

Note that the trace semantics is obtained according to the construction of the automaton. States and transitions of the automaton are constructed whereas their sequences give the semantics of traces that represents the contract as seen at line (4) in Figure 8. The corresponding automaton of the sales contract is partially depicted in Figure 7. Each state of the automaton contains its respective decomposition of the contract i.e., a formula, and an ongoing transition to it represents the set of relativized actions that was applied to obtain this formula. Unfilled states represent intermediary decompositions obtained after evaluating their respective clauses. A special state represents a contract violation when the evaluated formula returns false. Another special state indicates the satisfaction of the contract, where the evaluated formula is reduced to true. Finally the last special state that is highlighted in gray at Figure 7 indicates a conflicting decomposition as seen at line (3) on Figure 8.

Figure 7: Partial generated automaton of the contract

4.4 Conflict detection

Next the conflict detection process is applied according as the algorithm constructs the automaton. The corresponding contract to a decomposition at a generated state is then checked in order to find conflicts. Sceneries of conflicts treated by the algorithm are characterized by the occurrence of: (1) deontic operators of obligation and prohibition on the same action; (2) deontic operators of prohibition and permission on the same action; (3) deontic operators of obligation on pre-defined conflicting actions; and (4) deontic operators of permission and obligation on pre-defined conflicting actions. A pre-defined conflicting action is, in fact, characterized when actions are performed by the same individual specified in a relativization.

In the classical approach a conflict is characterized by deontic operators occurring over the same action. However, a conflict does not accomplish when relativized deontic operators are associated to the same action but they are performed by distinct individuals. For instance, in the contract where the action is obliged and prohibited, simultaneously, a conflict is not characterized since different individuals are associated to the operators. Similarly, an action performed under operators of permission and prohibition at the same time, and fired by distinct individuals, will not induce a conflict.

We note that global deontic operators are always in conflict with relativized prohibition operators. A conflict can then be characterized by a global obligation together with a relativized prohibition associated to the same action in a conjunction, e.g., or simply . Similarly to permission and prohibition operators when at least one of them is a global modality.

Thus the detection mechanism has been also modified to deal with for pre-defined actions in the presence of relativizations. The conflict relation is now defined by instead of the classical , where denotes that actions and can not be performed concurrently. Thus pre-defined conflicts among relativized actions can be described in a contract. Relativized actions are in conflict if they are performed by the same individual. We can defined a conflict relation in two forms to prevent both actions being performed by a single individual: by a global conflict relation when conflicting actions cannot be concurrently performed whatever be the senders; and by a relativized conflict relation when conflicting actions cannot be performed by the same individual. The global conflict relation is denoted by and follows as the original relation for . The relation , , denotes that actions and cannot happen at the same time whatever be the senders. Similarly, the relativized conflict relation is denoted by . The relation , denotes that the actions cannot occur simultaneously when performed by the same individual. Thus in a relativized conflict relation if the actions are performed by distinct individuals then a conflict does not occur.

We then proceed by redefining the conflict detection procedure described by Algorithm 2. An evaluation on a state of the automaton considers the deontic information obtained by the function . For every set of deontic labels , a state of has a conflict if there exists an element which is in conflict to an element of .

input : A state of
output : A conflict
begin
           for  do
                     for  do
                               if  then
                                         return Conflict between and ;
                                        
                               end if
                              
                     end for
                    
           end for
          return no conflict detected;
          
end
Algorithm 2 Conflict detection in

The set of conflicting deontic operators with respect to another operator is obtained by the function  [3]. Given a deontic operator , returns operators that are in conflict to . For each , the algorithm searches for an element of in the set of operators obtained by .

In our case study, the conflict detection process has found that the internal rule of the carrier conflicts with the remaining contract as described at line (20) of Figure 5. This internal rule states that the carrier only sends the product after the payment of the shipping costs. On the other hand, in the original contract, one expects that the product will be delivered by the carrier to the buyer before the payment of shipping costs is released by the bank. Therefore an incompatibility happens on the internal rule of the carrier, where the payment of the seller related to shipping costs was expected by the carrier before sending the product to the buyer. The conflict emerges due to the internal rule of the carrier that waits the payment of shipping costs by the seller, instead of the bank, to deliver the product.

The output analysis obtained by the practical tool (See Section 5) reveals such conflict as given in Figure 8.

1[CONFLICT] A conflict was found in the analyzed contract.
2Conflict found in state (s24)
3Conflict: F(c,deliverProduct,b) conflicts with [O(c,deliverProduct,b)]
4Trace: (s24)<-T19-(s23)<-T17-(s22)<-T13-(s21)<-T12-(s20)<-T11-(s0)
Figure 8: The RECALL output analysis

At the at line (1) of Figure 8 we see the message declaring that a conflict was found in the contract. Line (2) says in which state the conflict was found and Line (3) gives the precise information about the conflict that was detected, i.e. an atomic and subcontract. We notice that the first clause specifies that the carrier is forbidden to deliver the product to the buyer. At the same time, in the second clause, it is required that the carrier is obligated to deliver the product to the buyer. Clearly, both clauses cannot be simultaneously satisfied.

An automaton trace is shown at line (4) as a sequence of states and transitions that leads the contract to a conflicting state. For instance, the entire contract was processed and decomposed at the initial state (). According to the action on transition () the state () is obtained. Similarly, successive decompositions are held until reaching the conflicting state (). More details are also provided by the tool such as decompositions associated to each state of the automaton and actions that were performed over the transitions. Figure 9 shows the decomposition of the contract at state into state by transition , when the seller sends the product to the carrier.

1(s24) - {s,c}[!payShippingCosts*]({c,b}F(deliverProduct)_/F/_) AND
2{c,b}[deliverProduct]({c,s}[notifyProductDelivery](
3{s,k}[releaseShippingCosts]({k,c}O(payShippingCosts)_/F/_) AND
4{s,k}O(releaseShippingCosts)_/F/_) AND {b,k}[notifyProductReceipt]
5({k,c}O(payProduct)_/F/_) AND {c,s}O(notifyProductDelivery)_/F/_ AND
6{b,k}O(notifyProductReceipt)_/F/_) AND {c,b}O(deliverProduct)_/F/_
7<T19> - [(s, sendProduct, c), (s, payShippingCosts, k)]
8(s23) - {s,c}[!payShippingCosts*]({c,b}F(deliverProduct)_/F/_) AND
9{s,c}[sendProduct]({c,b}[deliverProduct]({c,s}[notifyProductDelivery](
10{s,k}[releaseShippingCosts]({k,c}O(payShippingCosts)_/F/_) AND
11{s,k}O(releaseShippingCosts)_/F/_) AND {b,k}[notifyProductReceipt]
12({k,c}O(payProduct)_/F/_) AND {c,s}O(notifyProductDelivery)_/F/_ AND
13{b,k}O(notifyProductReceipt)_/F/_) AND {c,b}O(deliverProduct)_/F/_) AND
14{s,k}O(payShippingCosts)_/F/_ AND {s,c}O(sendProduct)_/F/_
Figure 9: A contract decomposition

5 RECALL Tool

The conflict detection method proposed in Section 4 has been implemented to allow automatic analysis for multi-party contracts specified on . The fundamental structures that composes the RECALL tool is presented in Figure 10.

Figure 10: The RECALL architecture

The Command Line Interface module implements the interaction between the tool and users, where settings for a contract analysis need to be provided to the tool. The data information of a contract specified by the syntax are stated by the Contract Representation module. The Automaton Construction module constructs the automaton that models the contract described in . The Conflict Analysis module aims at finding conflicts according to decompositions while the automaton is constructed.

5.1 Development

RECALL is mainly developed in Java [15], but it is supported by several libraries such as ANTLR [16], which generates the grammar syntax, and Apache Commons CLI [22], which configures the user interface file. Some mathematical operations of set theory that are used by Automaton Construction and Conflict Analysis modules were optimized by Guava [7] library. Further, the generated automaton of the analysis can also be graphically yield due to the Graphviz [6] library.

The core method of the construction automaton is shown at Figure 11. We highlight some important fragments of this method. At line (4) we see that the Conflict Analysis module is invoked for every decomposition obtained by the automaton construction. It allows to stop the verification process as soon as a conflict is found, avoiding unnecessary subsequent decompositions. Nevertheless, the verification process may also continue up to the end of construction, when the yielded automaton represents the whole contract. All possible conflicts can then be revealed as seen at lines (7) to (9) of Figure 11. A contract is declared free of conflicts when all decompositions are conflict-free. Otherwise, the contract is deemed in conflict and a counter-example is displayed by the tool.

1void constructAutomaton(State s) {
2 Clause c1 = s.getClause();
3 if (c1.getValue() == null) {
4  if (searcher.hasConflict(s))
5   automaton.setConflictFound(true);
6  for (Set<RelativizedAction> a : generateActions(c1)) {
7   if ((automaton.isConflictFound() && !config.isContinueOnConflict())
8   || s.getSituation() == StateSituation.conflicting)
9    return;
10   Clause c2 = decomposer.decompose((Clause) c1.clone(), a);
11   State s1 = automaton.getStateByClause(c2);
12   if (s1 != null) {
13    automaton.getTransitions().add(new Transition(s, s1, a));
14   } else {
15    s1 = new State(c2);
16    automaton.getStates().add(s1);
17    automaton.getTransitions().add(new Transition(s, s1, a));
18    constructAutomaton(s1);
19    s1.getTrace().add(new Transition(s, s1, a));
20   }
21  }
22 } else
23  s.setSituation(
24   c1.getValue()?StateSituation.satisfaction:StateSituation.violating);
25}
Figure 11: The automaton construction method

Decompositions are successively obtained by the Decomposer class at line (10) according to the decomposition function (See Section 4). The decompose method receives as parameters a clause that must be decomposed and a set of relativized actions and then returns a new clause following the rules defined in semantics. A new state is added to the automaton in order to represent the decomposed clause.

The conflict detection algorithm is invoked for every decomposition of the automaton construction. This algorithm is implemented by the method hasConflict and depicted at Figure 12.

1boolean hasConflict(State state) {
2 Clause clause = state.getClause();
3 Set<Set<DeonticTag>> delta = extractTags(clause);
4 for (Set<DeonticTag> d1 : delta)
5  for (Set<DeonticTag> d2 : Sets.difference(delta, Sets.newHashSet(d1)))
6   for (DeonticTag d : d1) {
7    Set<DeonticTag> conflictSet = generateConflictSet(d);
8    Set<DeonticTag> inter = Sets.intersection(conflictSet, d2);
9    if (!inter.isEmpty()) {
10     state.setSituation(StateSituation.CONFLICTING);
11     state.setConflictInformation(new ConflictInformation(d,inter,d2));
12     return true;
13    }
14   }
15 state.setSituation(StateSituation.CONFLICTFREE);
16 return false;
17}
Figure 12: The conflict detection method

We see at line (3) that the extractTags method implements the deontic extractor function  [4]. This method receives a clause and returns sets of deontic tags according to the evaluation of the current clause. Every element of these sets of deontic tags, e.g., , is checked against each element of the other sets, e.g., , to finding potential conflicts. Function returns any conflict between deontic operators related to , for all , and any , for all , according to pre-defined conflicts. A conflict is raised by the tool if at least one element of is conflicting to an element of . In this case hasConflict method, at line (10), adds a flag at the state that contains the conflicting decompositions and stores the list of conflicting deontic tags, at line (11), to be returned by the tool.

In the process of checking a multi-party contract, RECALL tool loads a text file with the contract’s description in . The set of individuals and the set of actions are extracted to calculate the set of relativized actions and also the set of concurrent actions . The sets of concurrent relativized actions are then ordered according to number of actions. We firstly consider the largest sets to be processed in the process. The ordering strategy potentially increases the possibility of finding conflicts as soon as possible once a conflict becomes more likely to happen the bigger the number of concurrent actions.

The combinatorial computing of relativized actions grows exponentially as the number of actions and individuals also grows. But we notice that many of these combinatorial computation need not to be calculated since their representations do not reflect sceneries of the contract under test. States and transitions of the automaton are constructed unnecessarily when theses sceneries are considered on the analysis. To illustrate this problem one considers the contract with and . Hence the set of relativized actions and the set of concurrent actions . We easily see that not only the ordering strategy over actions is important but also it is needed to overcome the combinatorial explosion problem. In any case we make clear that the nature of the problem remains combinatorial. We discuss aspects related to processing time and scalability in Section 6.

We also apply a pruning strategy over the set of relativized actions when precessing clauses. We select on-the-fly only relativized actions related to the current decomposition on the process. Note that only actions of a current subcontract must be considered in the computation from that point onwards for corresponding decompositions. Irrelevant actions with respect to the current clause in a decomposition are then discarded in subsequent evaluations. Decompositions over dynamic modalities need to take into account only trigger actions. Thus only one particular state among those possible decompositions need to be computed, and the remaining clause is discarded in the current computation. Penalties of deontic modalities are also discarded in an evaluation since they take effect only when the obligation (or prohibition) is violated.

5.2 Tool Practical Application

RECALL222More information and the source code is available on http://recallcontracts.github.io has been conceived to analyze multi-party contracts specified in . A multi-party contract must be described in a text file according to the syntax. Then the specification is submitted to the tool which, in turn, analyses the contract.

The specification file is arranged in two parts: pre-defined conflicts and clauses. Figure 13 presents a simple example of a contract specification file.

conflict {
    global { (a, b), (c, d) };
    relativized { (e, f), (e, a) };
};
[e]({j,k}O(f) ^ P(a) ^ {k}[a.b]({i,j}O(e&f)));
{j,i}F(c) _/{j}O(d)/_ ^ P(b) ^ {i,k}[a]({k}[b]({j,i}P(h))));
Figure 13: A simple example of a contract in .

See that the pre-defined conflicts are described in the header of the file and it is optional once a contract may not have pre-defined conflicts. We note that global conflicts are given pairwise within the tag global, and relativized conflicts are defined pairwise within the tag relativized. Clauses of the contract are specified in sequel following the grammar.

Relativization on deontic operators can be defined as follows:

  1. relativized, when there is only one individual between braces, e.g. {i}O(a), where individual is obliged to perform action .

  2. directed, when there are two individuals related to the modality, e.g. {i,j}O(a), where individual is obliged to perform action to individual .

  3. global, if the information is omitted, e.g. O(a), where all individuals of the contract are obliged to perform action .

Similarly we have relativizations over dynamic operators. Deontic modalities are represented by O, P, e F, respectively, obligation, permission and prohibition operators. Penalties are described between and after the associated clause.

Once the contract has been specified we submit it to RECALL by setting the parameters of analysis. Table 3 lists the running parameters of the tool.

Parameter Description
the automaton is completely constructed and all conflicts can be found
the resulting automaton is exported to a DOT file
one considers all possible combinations of actions
the resulting analysis is displayed in verbose mode
the running options and some examples are displayed
Table 3: Running parameters of RECALL tool

After running the tool, the resulting analysis says whether the contract under test is conflict-free. We obtain the output verdict by means of conflict detection traces (See Figure 8) and also by a graphical representation of the constructed automaton.

5.3 Providing a Conflict-free Sales Contract

The result of the verification analysis allows us to solve the raised conflict changing some deals in the original contract. We first include a new clause where the bank now must notify the carrier with respect to the payment of the shipping costs performed by the seller. Another amendment in the contract has been done specifically in the internal rule of the carrier. Now the carrier takes into account the bank notification as a guarantee of payment for shipping costs.

We then rewrite the contract specification following the proposed changes in order to avoid the conflict situation. We change clauses (5) and (12) of the contract’s description as follows:

  1. [General Contract]

  2. Bank must notify the Carrier about the payment with respect to the shipping costs and after Bank attests the payment, the Carrier is obliged to deliver the product to the Buyer.

  3. [Carrier Rules]

  4. Carrier is prohibited to deliver the product till Bank has notified the Carrier that Seller has paid the shipping costs.

* Note that the remaining clauses of the original contract is kept unchanged.

The amendments of the new contract are presented in Figure 14. The specific clause where the bank notifies the carrier with respect to the shipping costs is described at line (2), which represents line (9) in the original contract. The carrier considers the bank notification as guarantee to release the product delivery at line (4) in the new version corresponding to line (21) in the original contract. Lines (1)-(8) and (10)-(20) of the original contract remain unchanged.

1
2(09)  {k,c}O(notifyShippingPayment) ^ {s,c}[sendProduct](
3
4(21) {k,c}[(!notifyShippingPayment)*]({c,b}F(deliverProduct));
Figure 14: The amended version of the sales contract

On the next step we resubmit the new version of sales contract to RECALL tool. This time the resulting analysis has declared that the sales contract is conflict-free. After these adjustments once the bank is now obliged to notify the carrier about the payment of the shipping costs we guarantee that the contract runs to completion safely without no loss to any party. We remark that no other conflict has been detected in the contract.

For the sack of completeness we note that even the latest version of the sales contract cannot be captured by a set of bilateral contracts due to similar arguments that have been given beforehand over the oldest version.

6 Practical Experiments

We performed some experiments in order to verify the efficiency of our method and the tool scalability. The experiments are classified according to the number of actions and individuals modeled in the contract specifications. We basically explore two main aspects on each group: execution time and memory consumption. We separated the experiments into three groups, each group described in a corresponding subsection in the sequel. In the first group we studied how the number of actions impacts in the verification process; in the second group the number of individuals in the contracts were varied; and in the third we consider a high number of actions and individuals, simultaneously, in order to stress the tool up to its limit.

All experiments were performed using randomly generated contract specifications which were checked on a Core2duo running Linux with 8Gb of RAM memory. For each variation of a specific parameter, a total of 100 contract specifications were generated and checked. We chose randomized experiments in order to avoid biases when treating each set of experiments.

6.1 Varying the Number of Actions

In this first group of experiments we varied the number of actions for each contract specification, with fixed number of individuals. The number of actions ranged from 8 to 15 and the number of individuals was fixed at 8. The execution time and the memory consumption is given by the average of 100 generated contracts for each class. For instance, the processing time takes at most 1.5 minutes for contracts with 8 individuals and 11 actions for 100 contract specifications, on average.

Figure 15 shows how the execution time of the verification process varied according to the number of actions in the contracts. We remark that some contract verifications have not finished with a verdict due to the explosion problem, specially for contracts with a higher number of actions. The execution time average is calculated based on the whole group of 100 contracts, seeing that for those unfinished experiments the resource consumption was much higher than the experiments with a verdict. For each class of contracts with 8 up to 15 actions, we obtained 2, 2, 3, 6, 5, 5, 2, and 13 unfinished checking processes of 100 performed experiments.

Figure 15: Varying the number of actions: execution time

We observe that the execution time, on average, does not take more than 2.5 minutes, in general, even for contracts with a high number of actions.

Similarly, we can observe the memory consumption for the same scenario in Figure 16. We note that the memory consumption, on average, does not take more than around 1.4 Gb, in general. We also see that for the class of contracts with 8 individuals and 15 actions the memory consumption grows drastically compared to previous classes. We remark again that those unfinished checking processes are being calculated on the memory consumption average.

Figure 16: Varying the number of actions: memory consumption

6.2 Varying the Number of Individuals

In this group of experiments we varied the number of individuals in the contract specifications, with fixed number of actions. We ranged the number of individuals from 5 to 12 and the number of actions remained fixed at 10.

We show in Figure 17 how the execution time of the verification process varied according to the number of individuals in the contracts. Again, we remark that the execution time and memory average is calculated based on 100 contract specifications. In this scenario we notice that all experiments in groups with 5, and 6 individuals have finished with a verdict. Groups with 7 and 8 individuals had one unfinished checking process, while groups with 9, 10, 11, and 12 individuals had 6, 6, 16, and 20, respectively, unfinished processes.

Figure 17: Varying the number of individuals: execution time

We observe that the execution time, on average, does not take more than 5 minutes, but we note that the execution time substantially grows from 11 individuals onwards.

In Figure 18 we observe the memory consumption for the same scenario. Similarly to the execution time the memory consumption drastically grows from experiments with 11 individuals onwards, more precisely, from 1 Gb to 3 Gb approximately. But, in general, the memory consumption does not take more than 3 Gb at maximum.

Figure 18: Varying the number of individuals: memory consumption

6.3 Stress testing

In the last set of experiments we have run contract specifications to stress the tool. We generated four groups of 100 contracts, but in this case we discarded unfinished checking runs.

In the first group we performed experiments where the contracts have a fixed number of 8 individuals and a fixed number of 15 actions. The execution time on checking each contract is shown in Figure 19. Here we have 13 contracts that do not run to completion. In contrast, we obtain 87 contract runs with a verdict, and most of them takes less than 30 seconds to be checked.

Figure 19: Contracts with 8 individuals and 15 actions: execution time

We also observe the memory consumption for the same scenario in Figure 20, and only 9 experiments from 87 finished runs take more than 1 Gb of RAM memory.

Figure 20: Contracts with 8 individuals and 15 actions: memory consumption

Next we increase the number of actions from 15 to 20, while the number of individuals remains fixed at 8. We show in Figure 21 the execution time. We have 25 unfinished checking runs due to the memory overflow whereas 75 contracts have finished the process with a verdict, and only 10 % (8 runs of 75 in total) has taken more than 3 minutes to be checked.

Figure 21: Contracts with 8 individuals and 20 actions: execution time

We also observe that the memory consumption did not grow too much if compared to previous group, as seen in Figure 22. Most of the experiments takes up to 2 Gb of memory at maximum, and only 16% of the experiments (12 runs of 75 in total) have consumed between 2Gb and 7Gb of RAM memory.

Figure 22: Contracts with 8 individuals and 20 actions: memory consumption

In the third group we performed experiments where the contracts have a fixed number of 15 individuals and a fixed number of 10 actions. That is, we increase the number of individuals, compared to the previous group, from 8 to 15, but we reduce the number of actions from 15 to 10 in total. Figure 23 shows the execution time on checking each contract. We reach 36 unfinished checking runs and 64 experiments that run to completion. We note that only 6% (4 of 64 in total) of those finished experiments take more than 5 minutes, and up to 17 minutes to be checked.

Figure 23: Contracts with 15 individuals and 10 actions: execution time

By completeness Figure 24 presents the memory consumption for the same scenario. Most experiments also takes up to 2 Gb of memory at maximum, and only around 15% of the experiments (10 runs of 64 in total) have consumed between 2Gb and 8Gb of RAM memory.

Figure 24: Contracts with 15 individuals and 10 actions: memory consumption

The resource consumption increases as the number of actions and individuals grows in the experiment. But also notice that the number of individuals has a more pronounced impact than the number of actions in the contracts.

In the last group we performed experiments where the contracts have a fixed number of 18 individuals and a fixed number of 10 actions. That is, we increase the number of individuals, compared to the second group, from 8 to 18, and reduce the number of actions from 20 to 10. Figure 25 shows the execution time. In this case we obtained at the rate of 81% of unfinished checking runs while only 19 experiments have run to completion with the execution time up to 15 minutes.

Figure 25: Contracts with 18 individuals and 10 actions: execution time

Regarding the memory consumption we see in the Figure 26 that only 5 contracts were checked with less than 2Gb of RAM memory, and the remaining takes between 2Gb and 8Gb of RAM memory.

Figure 26: Contracts with 18 individuals and 10 actions: memory consumption

We noticed a more prominently resource consumption when the number of individuals grows in the experiment. In this last scenario, with 18 individuals and 10 actions, we observe higher ratios of execution time and memory consumption when the number of individuals and actions are inversely proportional compared to the second group where the contracts have 8 individuals and 20 actions. The result reinforces the effect regarding the growth of individuals more than the number of actions in the contract specifications.

6.4 Threats to Validity

All contract specifications were randomly generated in our experiments. Even though the generation procedure is unbiased, we cannot able to make claims about the similarity between these generated contract specifications and real contracts which may appear in practice. To overcome this threat, in future works, more experiments could be replicated using real contract specifications as made with the sales contract. Another threat is related to the algorithm that randomly generate the contract specifications. It may somehow bring forth rarer and special cases where the RECALL tool does not deal with very well, e.g. which logical operators have been randomly chosen within the clauses. We tackled this threat by using a high number of contracts for each group of experiments, reducing the influence of this factor on the results.

7 Conclusion

This work proposed a method for checking multi-party contracts that can be formally modeled by an extended contract language. We defined the syntax and the semantics for t The extended contract language, named , was defined to enclose relativizations in the classical contract language. We developed the proposal to automatically check multi-party contracts specified by .

A real-world contract, characterized by multi-party aspects, was also specified and submitted to our tool as a case study of an electronic commerce problem. The tool was able to detect an important problem in the original specification rising a conflicting relationship between their participating parties. We could fix the contract specification by means the resulting analysis and in a new checking run with our tool declared a conflict-free verdict over the reviewed version for the sales contract.

We also performed practical experiments for different scenarios in order to evaluate the RECALL tool. We assay aspects related to scalability and efficiency of our tool, exploring complementary parameters, i.e. number of actions and number of individuals that are restrained on the contract. The experimental results indicated a good performance when we have a balance between the number of individuals and the number of actions summed up of around 20. The analyses also revealed that the number of individuals has greater influence than the number of actions on this efficiency.

We leave for future work a graphical user interface to ease the contract modeling and the process of analysis. We also expect to inspire other works to improve the algorithms proposed in this work.

References

  • [1] S. Angelov and P. Grefen. B2b econtract handling - a survey of projects, papers and standards. Technical report, University of Twente, The Netherlands, 2001.
  • [2] Aspassia Daskalopulu. Model checking contractual protocols. CoRR, cs.SE/0106009, 2001.
  • [3] Wellington A. Della Mura and Adilson L. Bonifácio. A conflict detection approach for multi-party contracts. Technical Report DC-15-01, Department of Computing, University of Londrina, August 2015. In English, 14 pages.
  • [4] Wellington Aparecido Della Mura and Adilson Luiz Bonifácio. Devising a conflict detection method for multi-party contracts. In 34th International Conference of the Chilean Computer Science Society, SCCC 2015, Santiago, Chile, November 9-13, 2015, pages 1–6. IEEE, 2015.
  • [5] Stephen Fenech, GordonJ. Pace, and Gerardo Schneider. Automatic conflict detection on contracts. In Martin Leucker and Carroll Morgan, editors, Theoretical Aspects of Computing - ICTAC 2009, volume 5684 of Lecture Notes in Computer Science, pages 200–214. Springer Berlin Heidelberg, 2009.
  • [6] Emden Gansner. Graphviz 2.38, 2016.
  • [7] Google. Guava 1.8, 2015.
  • [8] David Harel, Dexter Kozen, and Jerzy Tiuryn. Dynamic logic. In Handbook of Philosophical Logic, pages 497–604. MIT Press, 1984.
  • [9] B Haugen. Multi-party electronic business transactions. http://www.supplychainlinks.com/MultiPartyBusinessTransactions.PDF, 2002.
  • [10] Henning Herrestad and Christen Krogh. Obligations directed from bearers to counterparts.

    ICAIL ’95 Proceedings of the 5th international conference on Artificial intelligence and law

    , pages 453–522, 1995.
  • [11] Risto Hilpinen. Deontic logic. In Lou Goble, editor, The blackwell guide to philosophical logic, chapter 8. Blackwell, 2001.
  • [12] Marcel Kyas, Cristian Prisacariu, and Gerardo Schneider. Runtime monitoring of electronic contracts. In In ATVA08, LNCS. Springer-Verlag, 2008.
  • [13] J. J. Ch Meyer. A different approach to deontic logic: Deontic logic viewed as a variant of dynamic logic. Notre Dame Journal of Formal Logic, 29(1):109–136, 1987.
  • [14] T. Murata. Petri nets: Properties, analysis and applications. Proceedings of the IEEE, 77(4):541–580, Apr 1989.
  • [15] Oracle. Java se development kit 8, 2015.
  • [16] Terence Parr. Antlr 4.5, 2015.
  • [17] C. A. Petri. Fundamentals of a theory of asynchronous information flow. In IFIP Congress, pages 386–390, 1962.
  • [18] Cristian Prisacariu and Gerardo Schneider. A formal language for electronic contracts. In In FMOODS’07, volume 4468 of LNCS, pages 174–189. Springer, 2007.
  • [19] Cristian Prisacariu and Gerardo Schneider. Cl: An action-based logic for reasoning about contracts. In Hiroakira Ono, Makoto Kanazawa, and Ruy Queiroz, editors, Logic, Language, Information and Computation, volume 5514 of Lecture Notes in Computer Science, pages 335–349. Springer Berlin Heidelberg, 2009.
  • [20] Cristian Prisacariu and Gerardo Schneider. A dynamic deontic logic for complex contracts. The Journal of Logic and Algebraic Programming, 81(4):458 – 490, 2012.
  • [21] Wolfgang Reisig. Petri Nets: An Introduction. Springer-Verlag New York, Inc., New York, NY, USA, 1985.
  • [22] The Apache Software Foundation. Apache commons cli 1.3.1, 2015.
  • [23] Lai Xu. A multi-party contract model. ACM SIGecom Exchanges, 5, 2004.
  • [24] Lai Xu. Monitoring Multi-party contracts for e-business. Tese, Faculty of Economics and Business Administration of Tilburg University, 2004b.