Patent Description:
Distributed ledger systems provide a platform for the execution of smart contracts. Smart contracts typically include program instructions that may be executed in response to a transaction in the distributed ledger system addressed to the contract. Smart contracts may also represent legal contracts between users, with program functions of the smart contracts implementing terms, conditions, etc. of the legal contract.

Properties of distributed ledger systems provide improved immutability of data, such as transactions and smart contracts of such systems, ensuring that such data may be written to the system but not tampered with. Implementing legal contracts and other functionality using smart contracts thus provides a highly reliable way to implement such functions.

Unfortunately, problems exist with the execution of smart contracts in distributed ledger systems. For example, a legal contract represented by the smart contract may represent an illegal transaction in some jurisdictions. Additionally, the smart contract may include logical errors that cause it to execute a transaction different from that agreed to by parties to the legal contract. However, the immutability of the transactions, contracts, etc. provided by the distributed ledger system may be a barrier to actions to stop execution of such a contract.

Thus, a need exists for systems and methods to provide improved intervention in the operation of smart contracts in a distributed ledger system.

<CIT> relates to an apparatus for use in a product tracking system includes a storage device and a processor coupled to the storage device.

<CIT> relates to a system, method and computer program product for the external validation of the status of a distributed resource via a block chain database.

So that the features of the present invention can be understood, a number of drawings are described below. However, the appended drawings illustrate only particular embodiments of the invention.

Intervening in the operation of a smart contract in a distributed ledger system may include launching execution of the smart contract; upon launching execution of the smart contract, executing a judgment checking function to determine whether a judgment against the smart contract exists in a judgment database; in response to a judgment against the smart contract existing in the judgment database, intervening in the operation of the smart contract to prevent the execution of the smart contract; and, in response to no judgment against the smart contract existing in the judgment database, continuing execution of the smart contract.

Intervening in the operation of a smart contract in a distributed ledger system also may include determining a judgment of a validity of a complaint against the smart contract based on input received from one or more judges; in response to the judgment upholding the validity of the complaint against the smart contract, recording the judgment in a judgment database; receiving a request, from a judgment checking function, to determine whether the judgment against the smart contract exists in the judgment database in response to launching execution of the smart contract; and responding to the request indicating whether the judgment exists in the judgment database.

<FIG> depicts an embodiment of a system <NUM> for providing improved intervention in the operation of smart contracts in a distributed ledger system. The system <NUM> includes a distributed ledger system <NUM>, a virtual court server system <NUM>, one or more judge systems <NUM>, one or more complainant system(s) <NUM>, and one or more other systems <NUM>. The distributed ledger system <NUM> provides a platform for the operation of smart contracts, including a first smart contract <NUM> for which a judgment may be evaluated, and a second smart contract <NUM>, also referred to herein as a court contract <NUM>, which may be utilized to implement a judgment against the smart contract <NUM>. The virtual court server system <NUM> receives complaints regarding the operation of the smart contract <NUM> from the complainant system <NUM>, receives one or more inputs regarding the complaint from the judge systems <NUM>, and provides mechanisms for intervention in the operation of the smart contract <NUM> in the distributed ledger system <NUM>, such as maintaining a judgment database and/or communicating with the court contract <NUM>. The other system <NUM> may also interact with the distributed ledger system <NUM>, such as, e.g., interacting with smart contracts of the distributed ledger system <NUM>.

In embodiments, the system for providing improved intervention in the operation of smart contracts may include only any subset of, or an alternative connection of, the features depicted in or discussed herein in regard to <FIG>.

<FIG> depicts an embodiment of the virtual court server system <NUM>, including a judge system interface module <NUM>, a complainant system interface module <NUM>, a distributed ledger system interface module <NUM>, a virtual court server system control module <NUM>, and a judgment database module <NUM>. The complainant system interface module <NUM> provides a communication interface between the virtual court server system <NUM> and the complainant system <NUM> to receive complaint information from the complainant system <NUM>. The judge system interface module <NUM> provides a communication interface between the virtual court server system <NUM> and the judge systems <NUM> to communicate complaint information to the judge systems <NUM> and receive judgment information from the judge systems <NUM>. The distributed ledger system interface module <NUM> provides a communication interface between the distributed ledger system <NUM> and the virtual court server system <NUM> to provide enforcement mechanisms for intervention in the operation of the smart contract <NUM>, such as maintaining the judgment database and/or communicating with the court contract <NUM>. The virtual court server system control module <NUM> provides control logic to implement functions of the virtual court server system <NUM> discussed herein. The judgment database module <NUM> provides a judgment database for storage for and access to the judgments against the smart contract <NUM>. The judgment database may instead or additionally be stored in the distributed ledger system <NUM>, such as in the form of a data structure of the court contract <NUM>.

In embodiments, the virtual court server system may include only any subset of, or an alternative connection of, the features depicted in or discussed herein in regard to <FIG>.

<FIG> depicts an exemplary embodiment of the distributed ledger system <NUM>. The distributed ledger system <NUM> includes a plurality of distributed nodes <NUM>. The distributed nodes <NUM> are organized as a peer-to-peer network, in which each of the nodes <NUM> may connect to one or more of the other nodes <NUM> using a peer-to-peer communication protocol. At least one of the distributed nodes <NUM> may also connect to the virtual court server system <NUM>. At least one of the distributed nodes <NUM> also may connect to the other system <NUM>. As a peer-to-peer network, the configuration of connections between individual distributed nodes <NUM> may change over time according to operation of the peer-to-peer protocol.

<FIG> depicts an exemplary embodiment of the distributed node <NUM> of the distributed ledger system <NUM>, including a ledger structure storage module <NUM>, a communication module <NUM>, a virtual machine module <NUM>, and a ledger structure creation module <NUM>. The ledger structure storage module <NUM> stores data structures into which the ledger of the distributed ledger system <NUM> is organized in a non-transitory machine-readable storage medium. The communication module <NUM> performs communications between the distributed node <NUM> and other distributed nodes <NUM> and other systems or components connected to the distributed node <NUM>, such as the virtual court server system <NUM>. The virtual machine module <NUM> executes smart contracts stored on the distributed ledger of the distributed ledger system <NUM>. The ledger structure creation module <NUM> performs an algorithm to incorporate new transactions and other data into ledger structures of the distributed ledger system <NUM>, such as a data encryption algorithm of a selected complexity.

In embodiments, the distributed node may include only any subset of, or an alternative connection of, the features depicted in or discussed herein in regard to <FIG>.

In embodiments, the distributed ledger system <NUM> may be a blockchain system in which the ledger implemented by the distributed ledger system <NUM> is in the form of a sequence of structured data blocks, also referred to as a blockchain. In such embodiments, the ledger structure storage module <NUM> is a block storage module that stores the blocks of the blockchain system, and the ledger structure creation module <NUM> is a block creation module performing an algorithm to incorporate new transactions and other data into blocks of the blockchain of the blockchain system, also referred to as mining blocks of the blockchain system. In other embodiments, the distributed ledger system <NUM> may be another type of distributed ledger system instead of a blockchain system, in which the ledger may be organized into a structure other than blocks of a blockchain.

Components of embodiments of the system <NUM> for providing an improved intervention in the operation of the smart contract <NUM> in the distributed ledger system <NUM>, such as the virtual court server system <NUM>, the judge system(s) <NUM>, the complainant system(s) <NUM>, the other system(s) <NUM>, nodes <NUM> of the distributed ledger system <NUM>, etc., and/or any individual one, subset, or all of the components thereof, may be implemented as hardware, software, or a mixture of hardware and software. For example, each of the virtual court server system <NUM>, the judge system(s) <NUM>, the complainant system(s) <NUM>, the other system(s) <NUM>, nodes <NUM> of the distributed ledger system <NUM>, etc., and/or any individual one, subset, or all of the components thereof, may be implemented using a processor and a non-transitory storage medium, where the non-transitory machine-readable storage medium includes program instructions that when executed by the processor perform embodiments of the functions of such components discussed herein. In embodiments, each of the virtual court server system <NUM>, the judge system(s) <NUM>, the complainant system(s) <NUM>, the other system(s) <NUM>, nodes <NUM> of the distributed ledger system <NUM>, etc., and/or any individual one, subset, or all of the components thereof, may be implemented using a computer system, such as, e.g., a desktop computer, laptop computer, mobile computing device, network device, server, Internet server, cloud server, etc..

Components of embodiments of the system <NUM> for providing an improved intervention in the operation of the smart contract <NUM> in the distributed ledger system <NUM>, such as the virtual court server system <NUM>, the judge system(s) <NUM>, the complainant system(s) <NUM>, the other system(s) <NUM>, nodes <NUM> of the distributed ledger system <NUM>, etc., and/or any individual one, subset, or all of the components thereof, may each be connected to, and communicate with, other components of embodiments of the system <NUM>, e.g., as indicated by the connections exemplarily depicted in <FIG>, over one or more communication networks represented by such connections.

<FIG> depicts an embodiment of a method <NUM> of intervening in the operation of the smart contract <NUM> in the distributed ledger system <NUM>. The method <NUM> begins at step <NUM>.

At step <NUM>, a complaint is received regarding the smart contract <NUM> from a complainant. The complaint contains information alleging an illegality or other problem with the operation of the smart contract <NUM>. The complaint includes an identifier identifying the smart contract <NUM>, such as an address of the smart contract <NUM> in the distributed ledger system <NUM>, and one or more assertions that the smart contract <NUM> has violated a legal rule. For example, the complaint may identify a legal jurisdiction, such as a state or country, etc., identify a law or rule of the identified legal jurisdiction, such as a rule related to the conducting of financial transactions, etc., and assert that the smart contract <NUM> violates the identified law. In another example, the complaint may identify a portion of a legal contract between a person or system originating the complaint and the owner or operator of the smart contract <NUM>, which legal contract the smart contract <NUM> is intended to implement, and assert that the smart contract <NUM> implements something other than the identified portion of the legal contract.

The complaint is received at the virtual court server system <NUM> from a complainant operating the complainant system <NUM>. For example, the complainant may transmit a file containing the complaint to the virtual court server system via the complainant system interface module <NUM>.

The complainant is a person or other legal entity, such as a corporation, etc., that asserts the illegality or other problem against the smart contract <NUM>. The complainant typically has interacted with the smart contract <NUM> and observed the asserted illegality or other problem, and is turning to the system <NUM> for intervention in the operation of smart contracts for relief, much in a similar way to how a complainant turns to a court of a jurisdiction for relief for a legal complaint.

The virtual court server system <NUM> is typically operated by an organization or other entity with a mandate to conduct intervention in the operation of smart contracts in the distributed ledger system <NUM>. For example, the virtual court server system <NUM> may be operated by an organization that created or operates the distributed ledger system <NUM>. Providing the virtual court server system <NUM> and the intervention functionality discussed herein provides advantageous properties to the distributed ledger system <NUM>, such as an improved likelihood of legal operation and redress of legal problems, which the operator of the distributed ledger system <NUM> can advertise to increase the business conducted by the distributed ledger system <NUM>.

At step <NUM>, input regarding the complaint is received from one or more judges. The input contains information regarding a judgment of the complaint. For example, the received input may include a vote from each of the one or more judges as to whether the complaint is agreed with and/or valid, and the judgment being that the smart contract <NUM> is illegal or has the indicated problem, or whether the complaint is disagreed with and/or invalid, and the judgment being that the smart contract <NUM> is not illegal or does not include the identified problem.

The input regarding the complaint is received at the virtual court server system <NUM> from the one or more judges operating the one or more judge systems <NUM>. For example, a judge may transmit a file or other data containing the input regarding the complaint to the virtual court server system <NUM> via the judge system interface module <NUM>.

The one or more judges are people or other legal entities, such as corporations, etc., elected or otherwise designated within the operation of the distributed ledger system <NUM> to pass judgment on complaints. For example, the judges may be elected via an election by users or other stakeholders in the distributed ledger system <NUM>. The judges are typically required to satisfy one or more criteria to run for election, such as being authenticated users of the distributed ledger system <NUM>, submitting an application to be a judge, etc. In another example, the judges are appointed by the organization or other entity with the mandate to conduct intervention in the operation of smart contracts, such as the organization that created or operates the distributed ledger system <NUM>.

In embodiments, the one or more judges providing input may include a predetermined number of judges organized according to one or more of a geographic region, a legal jurisdiction, a smart contract type, a legal rule type, etc..

At step <NUM>, a judgment of the complaint is determined based on the received input. The determined judgment includes whether the complaint is upheld, in whole or part, and the smart contract <NUM> judged illegal or having the indicated problem, or whether the complaint is dismissed, and the smart contract <NUM> judged to not be illegal or have the indicated problem. The determination is performed by combining the inputs received from the one or more judges. For example, the determination may be performed by adding together votes received from the one or more judges, and then determining whether a threshold has been reached regarding a judgment for the contract. The threshold may selected according to various different voting systems. In one example, the threshold is whether one of the options for the judgment, i.e., it being upheld or dismissed, reaches a plurality of the votes of the one or more judges. In another example, the threshold is whether one of the options for the judgment reaches a majority of the votes of the one or more judges.

The determination is conducted by the virtual court server system based on the received input from the one or more judges, such as by the control module acting on the inputs received via the judge system interface module.

If at step <NUM>, it is determined that the judgment is that the smart contract <NUM> has the illegality or other problem indicated in the complaint, the method proceeds to step <NUM>. At step <NUM> the determined judgment is recorded in a judgment database. The judgment database may be stored in the virtual court server system <NUM> and/or in the distributed ledger system <NUM>.

In embodiments in which the judgment database is stored in the judgment database module <NUM> of the virtual court server system <NUM>, the determined judgment is recorded in the judgment database module <NUM>. In such embodiments, the judgment is recorded by the virtual court server system <NUM>, such as by the control module <NUM> storing the judgment in the judgment database module <NUM>. The judgment database module <NUM> provides a database to store and provide access to the judgments of smart contracts. To record a judgment, the control module <NUM> provides as inputs to a write function of the judgment database module <NUM> an identifier of the smart contract <NUM>, such as an address of the smart contract <NUM>, and the judgment.

In embodiments in which the judgment is stored in a judgment database in the distributed ledger system <NUM>, the judgment may be recorded in a data structure of the distributed ledger system <NUM> representing the judgment database using a smart contract of the distributed ledger system <NUM>, such as the court contract <NUM>. <FIG> depicts an embodiment of the court contract <NUM>, including one or more judgment database updating functions <NUM>, one or more judgment database checking functions <NUM>, and one or more judgment database data structures <NUM>. The judgment database updating function <NUM> includes program instructions to execute a write to the judgment database data structure <NUM>, which contains the judgment database. The write can include as an input an identification of the smart contract <NUM>, such as an address of the smart contract <NUM>, and the judgment, such as, e.g., a Boolean or integer value indicating that a judgment against the smart contract <NUM> exists, and as a result of its execution record the identifiers of the contract <NUM> and judgment as a corresponding pair of data values in the data structure <NUM>.

To record the judgment, the virtual court server system <NUM> generates and transmits, such as via the distributed ledger system interface module <NUM>, to at least one distributed node <NUM> of the distributed ledger system <NUM> a transaction addressed to the court contract <NUM> invoking the judgment database updating function <NUM>. In response, upon incorporation by at least one distributed node <NUM> of the transaction into a ledger structure of the distributed ledger system <NUM>, the court contract is executed to execute the judgment database updating function <NUM> to record the judgment in the judgment database data structure <NUM> of the court contract <NUM>.

Below are exemplary program instructions illustrating an example embodiment of the court contract <NUM>:
<IMG>
<IMG>
Other embodiments of the court contract <NUM> may include different specific program instructions. The exemplary contract Court{} includes an isLegal[] data structure, an updateStatus() function, and a checkStatus() function. In the exemplary embodiment, the judgment database is implemented using the isLegal[] data structure, and the judgment database updating function is implemented using the updateStatus() function. Upon being invoked by a transaction to the Court{} contract, the updateStatus() function updates the isLegal[] data structure with a judgment b for an indicated address when the function is triggered by a transaction from the court contract owner.

In embodiments, the court contract <NUM> may include only any subset of, or an alternative connection of, the features depicted in or discussed herein in regard to <FIG>.

Returning to <FIG>, if at step <NUM>, it is determined that the judgment is that the smart contract <NUM> does not have the illegality or other problem indicated in the complaint, the method proceeds to step <NUM>.

At step <NUM>, an inquiry is received regarding whether a judgment against the smart contract <NUM> exists. The inquiry includes an identifier identifying the smart contract <NUM>, such as an address of the smart contract <NUM> in the distributed ledger system <NUM>, and a request for identification of any judgments against the smart contract <NUM>. The inquiry may be received by a component of the virtual court server system <NUM> or the distributed ledger system <NUM>. In embodiments in which judgments are stored in the judgment database module <NUM>, the inquiry is received by the virtual court server system <NUM>. For example, the inquiry may be received via the distributed ledger system interface module <NUM>. In embodiments in which judgments are stored in a data structure of the distributed ledger system <NUM>, the inquiry may be received by a smart contract such as the court contract <NUM>. For example, returning to <FIG>, the inquiry may be received by the court contract <NUM> as part of it being executed to perform the judgment database checking function <NUM>. The judgment database checking function <NUM> includes program instructions to execute a read of the judgment database data structure <NUM>, which contains the judgment database. In the exemplary contract Court{} discussed above, this may take the form of a call to or invocation of the checkStatus() function.

The inquiry is received from and/or initiated by a component of the distributed ledger system <NUM> in response to launching or requesting to launch execution of the smart contract <NUM>. For example, the inquiry may be received from and/or initiated by the smart contract <NUM> itself, such as as a result of execution of at least one program instruction of the smart contract <NUM>, or received from and/or initiated by the virtual machine <NUM> of a distributed node <NUM> of the distributed ledger system <NUM> that is launching execution of the smart contract <NUM>. Embodiments of generating the inquiry are discussed further below in regard to embodiments of the method <NUM> of intervening in the operation of the smart contract <NUM>.

At step <NUM>, the judgment database is read to determine whether any judgment against the smart contract <NUM> has been recorded in the judgment database. The judgment database may be read by a component of the virtual court server system <NUM> or the distributed ledger system <NUM>. In embodiments in which judgments are stored the judgment database module <NUM>, to read the judgment database, the control module <NUM> provides as inputs to a read function of the judgment database module <NUM> an identifier of the smart contract <NUM>, such as an address of the smart contract <NUM>. In embodiments in which judgments are stored in the judgment database data structure <NUM> of the court contract <NUM> in the distributed ledger system <NUM>, the court contract <NUM> may be executed to perform the judgment database checking function <NUM> to perform a read of the data structure <NUM> for any judgments associated with the contract <NUM>. The read can include as an input an identification of the smart contract <NUM>, such as an address of the smart contract <NUM>, and as a result of its execution return any judgment, such as, e.g., a Boolean or integer value indicating that a judgment against the smart contract <NUM> exists, stored in the data structure <NUM> in association with the identifier of the smart contract <NUM>. In the exemplary contract Court{} discussed above, this make take the form of executing the checkstatus() function to perform a read of the isLegal[] data structure for a judgment value corresponding to the address a.

At step <NUM>, a response to the inquiry is provided to the requesting component. The response indicates whether any judgment against the indicated smart contract <NUM> exists in the judgment database. In embodiments in which the virtual court server system <NUM> performs the read of the judgment database stored in the judgment database module <NUM>, the response is transmitted by the virtual court server system <NUM>. For example, the response may be transmitted by the virtual court server system control module <NUM> via the distributed ledger system interface module <NUM>.

The response is transmitted to the requesting component of the distributed ledger system <NUM>. For example, the response may be transmitted to the smart contract <NUM> or virtual machine <NUM> of the distributed ledger system <NUM> that initiated the inquiry. In embodiments in which the response is transmitted to the smart contract <NUM>, the virtual court server system <NUM> may generate a transaction containing the response and transmit the transaction to at least one node <NUM> of the distributed ledger system <NUM>. The transaction may be addressed to the smart contract <NUM>, or to another smart contract acting as an intermediary, such as as an oracle, for the smart contract <NUM>. In the case of using an intermediary or oracle contract, the intermediary or oracle contract may transmit a second transaction to or execute a call to the requesting smart contract <NUM> to deliver the response, or alternatively the requesting smart contract <NUM> may transmit a transaction to or execute a call to the intermediary or oracle contract to retrieve the response. In embodiments in which the response is transmitted to the virtual machine <NUM>, the virtual court server system <NUM> may provide a communication to the virtual machine module <NUM> of a distributed node <NUM> of the distributed ledger system <NUM> containing the response, such as via the distributed ledger system interface module <NUM>.

In embodiments in which the court contract <NUM> performs the read of the judgment database stored in the judgment database data structure <NUM> of the court contract <NUM>, the court contract outputs the response. For example, the court contract <NUM> may be invoked by the smart contract <NUM> to perform the judgment database checking function <NUM>, and output the result of the read of the judgment database data structure <NUM> to the smart contract <NUM>. In the exemplary contract Court{} discussed above, this may take the form of the checkstatus() function outputting the result of this function to the invoking smart contract.

In embodiments, a method of determining a judgment for a smart contract in a distributed ledger system may include only any subset of, or an alternative ordering of, the features depicted in or discussed above in regard to <FIG>.

<FIG> depicts an embodiment of another method <NUM> of intervening in the operation of the smart contract <NUM> based on the judgment for the smart contract <NUM>. The method <NUM> of intervening in the operation of the smart contract <NUM> may be complimentary to the method <NUM> of intervening in the operation of the smart contract <NUM>. For example, the method <NUM>, or portions thereof, may be performed by a first set of components, such as one or more components of the virtual court server system <NUM> and/or distributed ledger system <NUM>, as discussed herein, and the method <NUM>, or portions thereof, may be performed by a second set of components, such as one or more components of the virtual court server system <NUM> and/or distributed ledger system <NUM>, as discussed herein, in concert with the performance of the method <NUM>. The method <NUM> begins at step <NUM>.

At step <NUM>, execution of the smart contract <NUM> is launched or requested to be launched. Execution of the smart contract <NUM> is launched in response to events in the distributed ledger system <NUM>. In one example, execution of the smart contract <NUM> is launched in response to a transaction addressed to the smart contract <NUM> being transmitted to a node <NUM> of the distributed ledger system <NUM>, such as by a component of a distributed application of which the smart contract <NUM> is a part, or in response to a call to the smart contract <NUM> that does not require a transaction, such as by another smart contract or other component. Execution of the smart contract <NUM> is performed by the virtual machine module <NUM> of at least one distributed node <NUM> of the distributed ledger system <NUM>.

At step <NUM>, a judgment checking function is executed. The judgment checking function checks whether a judgment against the smart contract exists in the judgment database, such as in the judgment database module <NUM> or the judgment database data structure <NUM> of the court contract <NUM>. The judgment checking function is executed prior to other, non-judgment-checking functions of the smart contract <NUM>, so that if a judgment against the smart contract <NUM> exists, intervention in the operation of the smart contract <NUM> can be performed before such other functions of the smart contract <NUM> are executed. The judgment checking function may be or include a function of a contract of the distributed ledger system <NUM>, such as the court contract <NUM> or the smart contract <NUM>; a function of another component of the distributed ledger system <NUM>, such as the virtual machine <NUM> of a distributed node <NUM> of the distributed ledger system <NUM>; a function of a component of the virtual court server system <NUM>; or combinations thereof.

In embodiments, the judgment checking function is or includes a function of a contract of the distributed ledger system <NUM>, such as the court contract <NUM>, invoked by the smart contract <NUM>, which checks a judgment database stored as a data structure of such a contract, such as the judgment database data structure <NUM>. <FIG> depicts an embodiment of the smart contract <NUM> including one or more judgment checking functions <NUM> and one or more other functions <NUM>. The one or more other functions <NUM> include program instructions to perform other functionality of the smart contract <NUM>, such as in a role as part of a distributed application. In embodiments, the judgment checking function <NUM> includes program instructions to invoke another contract of the distributed ledger system, such as the court contract <NUM>, to check whether a judgment for the smart contract <NUM> exits in a data structure of such a contract, such as the judgment database data structure <NUM>. For example, to perform the judgment checking function, the smart contract <NUM> may execute the judgment checking function <NUM>, which may invoke the court contract <NUM> to perform the judgment database checking function <NUM>, which determines whether a judgment exists for the smart contract <NUM> in the data structure <NUM> of the court contract <NUM>. The invocation of the court contract <NUM> by the smart contract <NUM> may communicate as an input to the judgment database checking function <NUM> an identification of the smart contract <NUM>, such as an address of the smart contract <NUM>, and output as a result of the execution of the judgment database checking function <NUM> an indication of whether a judgment exists against the smart contract <NUM>.

Below are exemplary program instructions illustrating an example embodiment of the smart contract <NUM>:
<IMG>
Other embodiments of the smart contract <NUM> may include different specific program instructions. The exemplary contract someContract{} includes functions someConract() and someFunction(). The function someConract() may be executed upon launching, and invokes an instance of the Court{} contract, providing it with an input of the address a of the contract someContract{}. The function someFunction(), which performs other functionality of the smart contract (the details of which are omitted for simplicity of illustration and replaced by a comment to "do stuff"), and which may be invoked by a transaction addressed to the contract, performs this functionality conditional upon the output of an invocation of the checkStatus() function of the instantiated Court{} contract, which returns an indication of whether there is a judgment against the contract, such as, e.g., a "<NUM>" or "true" for there being a judgment against the contract, and a "<NUM>" or "false" for there being no judgment against the contract.

In embodiments, the judgment checking function is or includes a function of the smart contract <NUM> itself. In embodiments, the judgment checking function <NUM> includes program instructions to check whether a judgment for the smart contract exits in the judgment database module <NUM>. In one example, the judgment checking function <NUM> includes one or more predetermined instructions of a programming language in which the smart contract <NUM> is written that executes a read of the judgment database, such as the judgment database module <NUM>, to determine if it includes a judgment for the smart contract <NUM>. The read can include as input the address of the smart contract <NUM>. The predetermined instruction may be configured in the programming language to execute the read to the judgment database. The predetermined instruction may communicate with the judgment database module <NUM> via the distributed ledger system interface module <NUM> of the virtual court server system <NUM>.

In embodiments, the judgment checking function is or includes a function of the virtual machine <NUM> of the distributed node <NUM> executing the smart contract <NUM>. <FIG> depicts an embodiment of the virtual machine <NUM> including one or more judgment checking functions <NUM> and one or more other functions <NUM>. The one or more other functions <NUM> perform functionality of the virtual machine <NUM>, such as to execute the smart contract <NUM>. The judgment checking function <NUM> performs functionality to check whether a judgment for the smart contract <NUM> exits in the judgment database, such as in the judgment database module <NUM>. For example, the judgment checking function <NUM> may execute a read of the judgment database, such as the judgment database module <NUM>, to determine if it includes a judgment for the smart contract <NUM>. The read can include as input the address of the smart contract <NUM>. The virtual machine may communicate with the judgment database module <NUM> via the distributed ledger system interface module <NUM> of the virtual court server system <NUM>.

Returning to <FIG>, at step <NUM>, it is determined whether a judgment against the contract <NUM> exists as a function of the output of the execution of the judgment checking function at step <NUM>. The determination is conducted according to the embodiment of the judgment checking function. For embodiments in which the judgment checking function is or includes a function of the smart contract <NUM>, the smart contract <NUM> may include program instructions that invoke the judgment checking function and output the result. For example, in the above exemplary embodiment of the smart contract someContract{}, the statement "if(court. checkStatus(. }"determines whether a judgment against the smart contract exists as a function of the output of the checkStatus() function of the Court{} contract. In another example, the smart contract <NUM> may include a program instruction "if (legalToken()) {suicide(recipient);}" which invokes a judgment checking function legalToken() and takes an action as a result of the output of the function, as discussed further below. For embodiments in which the judgment checking function is a function of the virtual machine <NUM>, the virtual machine may similarly invoke the judgment checking function and taken an action as a function of the output, as discussed further below.

If at step <NUM>, it is determined that a judgment does not exist for the smart contract <NUM>, the method proceeds to step <NUM>. At step <NUM>, execution of the smart contract <NUM> continues without any intervention. For embodiments in which the judgment checking function is or includes a function of the smart contract <NUM>, the smart contract <NUM> proceeds to executing the other function(s) <NUM> of the smart contract <NUM>. For embodiments in which the judgment checking function is or includes a function of the virtual machine <NUM>, the virtual machine proceeds to execute the smart contract <NUM>. In embodiments, continuing execution of the smart contract includes at least one of: conducting a financial transaction between at least two parties by the smart contract, transferring ownership of a digital or physical asset between at least two parties by the smart contract, performing an identification of an individual to authorize access to restricted systems by the smart contract, or triggering by the smart contract an electronic device to generate an electrical signal to control operation of an electrical, mechanical or electromechanical apparatus.

If at step <NUM>, it is determined that a judgment does exist for the smart contract <NUM>, the method proceeds to step <NUM>. At step <NUM>, intervention in the operation of the smart contract <NUM> is performed to prevent the contract <NUM> from executing. For embodiments in which the judgment checking function is or includes a function of the smart contract <NUM>, the smart contract <NUM> may abort operation of the smart contract before other functionality is performed. For example, in the above exemplary embodiment of the smart contract someContract{}, the statement "if(court. checkStatus(. }" performs the "else{. } content, which may include nothing, or notification of the legal status, etc. In other embodiments, the smart contract may execute a self destruct function to prevent current and future operation of the smart contract <NUM>. In one example, in the exemplary program instruction above, the program instruction calls a self destruct function "suicide()" to prevent current and future operation of the smart contract <NUM>. The self destruct function may delete data of the smart contract <NUM> from the distributed ledger system <NUM>. For embodiments in which the judgment checking function is a function of the virtual machine <NUM>, the virtual machine <NUM> does not execute and/or stops execution of the smart contract <NUM>. The method ends at step <NUM>.

In embodiments, a method of intervening in the operation of a smart contract based on a judgment for the smart contract may include only any subset of, or an alternative ordering of, the features depicted in or discussed above in regard to <FIG>.

In embodiments, a method of determining a judgment against a smart contract and/or intervening in the operation of a smart contract based on the judgment may include any combination of the methods of <FIG> and <FIG>, or any combination of any subset and/or alternative ordering of the features of such methods.

As discussed above, in scenarios improved intervention in the operation of a smart contract may be provided by preventing operation of the smart contract in response to a judgment against the contract. However, in some scenarios, a smart contract may execute before any fault, illegality or other problem with the contract is discovered or a judgment against the contract reached. In such scenarios, improved intervention may be provided by remedying the actions that the smart contract may have already taken before a judgment against the contract is determined. For example, for a smart contract that conducts a financial or other transaction that transfer tokens, or other items of value, within the distributed ledger system from one party to another party, a remedying intervention may be provided by transferring, either in whole or in part, the erroneously transferred tokens back to the originating party, as well as complimentary actions.

<FIG> depicts an embodiment of a system <NUM> for providing improved intervention in the operation of a smart contract in a distributed ledger system. The system includes first and second counterparty systems <NUM>, <NUM>, the distributed ledger system <NUM>, and a court system <NUM>. The system <NUM> of <FIG> may be an embodiment of the system <NUM> of <FIG>, with the first counterparty system <NUM> being an embodiment of the complainant system <NUM>, the second counterparty system <NUM> being an embodiment of the other system <NUM>, the court system <NUM> being an embodiment of the virtual court server system <NUM> and the one or more judge systems <NUM>. The first and second counterparty systems <NUM>, <NUM> are systems of first and second counterparties to a financial or other transaction being conducted using the distributed ledger system <NUM>. The contract <NUM> conducts the financial or other transaction between the counterparties, the token transfer contract <NUM> implements token transfers in the distributed ledger system <NUM>, and the court contract <NUM> implements the intervention in the operation of smart contracts in the distributed ledger system <NUM>.

In embodiments, the system for providing improved intervention in the operation of a smart contract may include only any subset of, or an alternative connection of, the features depicted in or discussed herein in regard to <FIG>.

The depiction of <FIG> shows a view of an architecture of smart contracts implemented by the distributed ledger system <NUM>. <FIG> depicts another view of the embodiment of the system <NUM> for providing improved intervention of <FIG>, showing details of an architecture of the hardware interconnection of the first counterparty system <NUM>, second counterparty system <NUM>, and court system <NUM> with the distributed ledger system <NUM>. The first and second counterparty systems <NUM>, <NUM> each include an interface module <NUM>, <NUM> to communicate, such as via a direct connection or over one or more communication networks, with a communication module <NUM> of a distributed node <NUM> of the distributed ledger system <NUM> to implemented interactions between the first and second counterparty systems <NUM>, <NUM> and the distributed ledger system <NUM>, such as to implement communications with the contract <NUM> to conduct a financial or other transaction. The court system <NUM> likewise includes an interface module <NUM> to communicate, such as via a direct connection or over one or more communication networks, with the communication module <NUM> of a distributed node <NUM> to implemented interactions between the court system <NUM> and the distributed ledger system <NUM>, such as to implement communications with the court contract <NUM> to implement an intervention in the operation of the contract <NUM>.

<FIG> depicts an embodiment of a computer system <NUM> that may be used to implement the first counterparty system <NUM>, the second counterparty system <NUM>, the court system <NUM>, the distributed nodes <NUM> of the distributed ledger system <NUM>, and/or any individual one, subset, or all of the components thereof. The computer system <NUM> includes a processor <NUM>, a non-transitory machine-readable storage medium <NUM>, a communication circuit <NUM>, and optionally other components <NUM>. The processor <NUM> executes program instructions stored in the non-transitory machine-readable storage medium <NUM> to perform the functionality of the component it is implementing as discussed herein. The communication circuit <NUM> can be controlled by the processor <NUM> to communicate with other devices, such as others of the first counterparty system <NUM>, the second counterparty system <NUM>, the court system <NUM>, and/or the distributed nodes <NUM> of the distributed ledger system <NUM>, to perform the functionality of the component it is implementing as discussed herein. The optional other components <NUM> may include any further components required by the computer system <NUM> to perform this functionality.

In embodiments, a computer system that may be used to implement the first counterparty system <NUM>, the second counterparty system <NUM>, the court system <NUM>, the distributed nodes <NUM> of the distributed ledger system <NUM>, and/or any individual one, subset, or all of the components thereof may include only any subset of, or an alternative connection or ordering of, the features depicted in or discussed herein in regard to <FIG>.

<FIG> depicts an embodiment of a method <NUM> of intervening in the operation of a smart contract. The method may be performed by or involving components of the system <NUM> for providing improved intervention of <FIG>. The method of intervening in the operation of the smart contract remedies actions that the smart contract may have already taken before any judgment against the contract is determined, thereby improving the accuracy and performance of contracts within the distributed ledger system <NUM>, and the distributed ledger system <NUM> as a whole, by eliminating or reducing erroneous effects caused by smart contracts containing a fault, illegality or other problem. The method <NUM> begins at step <NUM>.

At step <NUM>, a financial or other type of transaction is conducted using a smart contract of the distributed ledger system <NUM>. The financial or other transaction may be conducted using the contract <NUM> of the distributed ledger system <NUM>. The contract <NUM> may be any contract of the distributed ledger system configured to conduct the financial or other type of transaction between parties. The parties to the transaction may be the first counterparty and the second counterparty. The financial or other transaction may be initiated by the first and second counterparties engaging the contract <NUM> to conduct the financial or other transaction, such as by the first and second counterparty systems <NUM>, <NUM> each transmitting a transaction, or executing a call, to the contract <NUM> to request and/or authorize the conducting of the financial or other transaction.

Note that, as used herein, "transaction" as in "conducting a financial or other transaction" refers to the action of implementing a financial or other transaction between parties, such as the sale of a financial commodity, the implementation of an interest or dividend payment for a financial commodity, etc.; while "transaction" as in "generating and transmitting a transaction to a smart contract" refers to the act of generating and transmitting a piece of data called a transaction in the distributed ledger system to a distributed node of the distributed ledger system to initiate execution of a smart contract.

Conducting the financial or other transaction by the contract <NUM> may include transferring tokens or other commodities of value within the distributed ledger system <NUM> between parties to the financial or other transaction. Tokens are units of value stored as data structures in the ledger of the distributed ledger system <NUM>, which may be a type of currency within the distributed ledger system <NUM>, and may be configured to represent value in various ways. For example, tokens may be configured to have a mathematical relationship to real-world currency, such as X tokens equal Y dollars, where X and Y can be selected to implement the relationship. The financial or other transaction may transfer tokens for a variety of purposes related to the nature of the transaction. For example, for a transaction performing a purchase of a financial commodity, such as a stock or bond, etc., the transaction may include transferring of tokens representing payment of the price of the financial commodity. For a transaction performing an interest or dividend payout from a financial commodity, such as a stock or bond, etc., the transaction may include transferring of tokens representing payment of the interest or dividend.

The contract <NUM> may transfer tokens using another contract of the distributed ledger system <NUM> configured to perform token transfers for contracts. In the embodiment of <FIG>, the token transfer contract <NUM> is a contract configured to perform token transfers for other contracts, and the contract <NUM> may use the token transfer contract <NUM> to perform token transfers. The contract <NUM> may execute a token transfer using the token transfer contract <NUM> by generating and transmitting a transaction, or executing a call, to the token transfer contract <NUM> to request the token transfer. The transaction or call to the token transfer contract <NUM> includes identification of an account in the distributed ledger system <NUM> of the party from whom the tokens will be transferred (such as, e.g., an account of the first counterparty), an account in the distributed ledger system <NUM> of the party to whom the tokens will be transferred (such as, e.g., an account of the second counterparty), and the number of tokens to be transferred. An account within the distributed ledger system <NUM> may be represented and/or identified by an address in the distributed ledger system <NUM>. In other embodiments, the contract <NUM> may itself include a token transfer functionality, which it may use to execute the token transfer.

Below are exemplary program instructions illustrating an example embodiment of a token transfer function of the token transfer contract <NUM>:
<IMG>
<IMG>
The exemplary function transfer() checks if the balance of the invoker msg. sender of the function is greater than an indicated amount _amount to be transferred, and, if so, the amount to be transferred is transferred to an indicated address _to in the distributed ledger system <NUM>.

Other embodiments of a transfer function may include different specific program instructions.

At step <NUM>, a determination of a judgment that the operation of the contract <NUM> includes an illegality, fault contrary to the intended operation of the contract <NUM>, or other problem is conducted. The determination of the judgment may be conducted by or involving the court system <NUM>, the court contract <NUM>, and a system of a party acting as the complainant, such as the first counterparty system <NUM>. In embodiments, the determination may be performed using embodiments of the method of <FIG>. For example, the determination of the judgment may be performed by performing steps <NUM> to <NUM> of the method of <FIG>, i.e., the court system <NUM>, such as the virtual court server system <NUM>, may receive a complaint regarding the smart contract <NUM> from a complainant, such as from the first counterparty system <NUM>; the virtual court server system <NUM> may receive input regarding the complaint from the one or more judges, such as from the one or more judge systems <NUM>; the court system <NUM>, such as the virtual court server system <NUM>, may determine a judgment of the complaint based on the received input; and the court system <NUM>, such as the virtual court sever system <NUM>, may record the determined judgment in the judgment database, such as the judgment database module <NUM> or a data store <NUM> of the court contract <NUM>. In other embodiments, instead of or in addition to the first counterparty system <NUM> providing the complaint to the court system <NUM>, the first counterparty system <NUM> may transmit a transaction, or execute a call, to the court contract <NUM> including the complaint, and the court system <NUM> may retrieve the complaint from a data structure of the court contract <NUM>.

The determination of the judgment may include a specific determination that an effect of the financial or other transaction conducted by the contract <NUM> is in error. For example, the determination of the judgment may determine that a quantity of tokens transferred as part of the financial or other transaction conducted using the contract <NUM> were transferred in error. An erroneous token transfer may arise in a variety of ways. The contract <NUM> may include a logical, data or other programming error that causes it to transfer a quantity of tokens that is not the quantity of tokens intended by the parties to be transferred. For example, a contract intended to implement an interest payment of <NUM>%, which may take the form of a number of tokens Z, may include an error that causes it to instead implement an interest payment of <NUM>%, which may take the form of a number of tokens <NUM>*Z.

At step <NUM>, the effect of the financial or other transaction determined to be in error is at least partially remedied. The remedying of the effect of the financial or other transaction determined to be in error may be performed by or involving the court system <NUM> and the court contract <NUM>. The remedying of the effect of the financial or other transaction determined to be in error may include remedying any specific effect identified by the judgment determination, such as an erroneous transfer of a quantity of tokens. The remedying may be conducted by the court system <NUM> engaging the court contract <NUM> to perform the remedying, such as by the court system <NUM> transmitting a transaction, or executing a call, to the court contract <NUM> to request the remedying. The transaction or call to the court contract <NUM> may identify the effect to be remedied and the parties involved in the remedy. For example, for an erroneous transfer of tokens, the transaction or call may identify an account in the distributed ledger system <NUM> of the party from whom the tokens will be transferred (e.g., the account to whom the tokens were transferred in error), an account in the distributed ledger system <NUM> of the party to whom the tokens will be transferred (e.g., the account from whom the tokens were transferred in error), and the quantity of tokens to be transferred for the remedy (e.g., the quantity of tokens transferred in error).

The court contract <NUM> may implement the remedy using another contract of the distributed ledger system <NUM>. For remedying an erroneous transfer of tokens, the court contract <NUM> may transfer tokens using the token transfer contract <NUM>. Typically, token transfers within a distributed ledger system <NUM> are only possible when the transfer request comes from the account from which the tokens are to be transferred, to prevent unauthorized token transfers. In the present system, however, the token transfer contract <NUM> may include a token transfer function configured to allow token transfers originating from the court contract <NUM>, referred to herein as a court transfer function, even though the account of the court contract <NUM> may be different from the account from which the remedying token transfer is to be drawn. The operators of the distributed ledger system <NUM> may find this acceptable, as the court contract <NUM> is a contract administered and operated by the court system <NUM>, which is a trusted entity. The court contract <NUM> may execute a token transfer using the token transfer contract <NUM> by generating and transmitting a transaction, or executing a call, to the token transfer contract <NUM> to request the court token transfer function. For example, for an erroneous transfer of tokens, the transaction or call may identify the court token transfer function, an account in the distributed ledger system <NUM> of the party from whom the tokens will be transferred (e.g., the account to whom the tokens were transferred in error), an account in the distributed ledger system <NUM> of the party to whom the tokens will be transferred (e.g., the account from whom the tokens were transferred in error), and the quantity of tokens to be transferred for the remedy (e.g., the quantity of tokens transferred in error).

Below are exemplary program instructions illustrating an example embodiment of a court token transfer function of the token transfer contract <NUM>:
<IMG>
<IMG>
The exemplary function courtTransfer() checks if the invoker of the function msg. sender is the court, then if so, checks whether the balance associated with an indicated address _from, from where the tokens are to be transferred, is greater than the indicated amount _amount to be transferred, and if so, transfers the amount to to an indicated address _to, to which the amount is to be transferred.

Other embodiments of a court transfer function may include different specific program instructions.

In embodiments, a method of intervening in the operation of a smart contract may include only any subset of, or an alternative ordering of, the features depicted in or discussed above in regard to <FIG>.

<FIG> depicts an embodiment of another method <NUM> of intervening in the operation of a smart contract. In embodiments, the method of <FIG> may be used to perform the remedying step <NUM> of the method of <FIG>. The method may be performed by or involving components of the system <NUM> for providing improved intervention of <FIG>, such as by the court contract <NUM> of the distributed ledger system <NUM>. The method of intervening in the operation of the smart contract remedies actions that the smart contract may have already taken before any judgment against the contract is determined, thereby improving the accuracy and performance of contracts within the distributed ledger system <NUM>, and the distributed ledger system <NUM> as a whole, by eliminating or reducing erroneous effects caused by smart contracts containing a fault, illegality or other problem. The method <NUM> begins at step <NUM>.

At step <NUM>, a request to remedy an erroneous token transfer performed as part of a financial or other transaction conducted in the distributed ledger system <NUM> is received. The request may be received by the court contract <NUM> from the court system <NUM>. The court system <NUM> may execute the request by generating and transmitting a transaction, or executing a call, to the court contract <NUM> to request the remedying action. The transaction or call to the court contract <NUM> may include identification of the account in the distributed ledger system <NUM> of the party from whom the tokens will be transferred (e.g., the account that received the erroneous transfer), an account in the distributed ledger system <NUM> of the party to whom the tokens will be transferred (e.g., the account from which the erroneous transfer originated), and the number of tokens to be transferred (e.g., the amount of tokens erroneously transferred).

At step <NUM>, a check is conducted of whether the balance of the account from where the remedying transfer is to be taken is greater than or equal to the amount of tokens to be transferred as a remedy. The check may be conducted by the court contract <NUM> executing program logic to determine the balance and compare the determined balance to the indicated amount of tokens to be transferred as a remedy.

If at step <NUM>, the balance is greater than or equal to the amount of tokens to be transferred as a remedy, the method proceeds to step <NUM>, where the entire amount of tokens to be remedied is transferred from the indicated account owing the tokens to the indicated account from which the erroneous transfer originated. The court contract <NUM> may execute the transfer by generating and transmitting a transaction, or executing a call, to the token transfer contract <NUM> to request the transfer. The transaction or call to the transfer contract <NUM> may include identification of the account in the distributed ledger system <NUM> of the party from whom the tokens will be transferred, the account in the distributed ledger system <NUM> of the party to whom the tokens will be transferred, and the number of tokens to be transferred.

As discussed above, to overcome the limitation of transfer functions only transferring tokens from an account that calls the function, and to preserve the prevention of unauthorized transfer of tokens, the token transfer contract <NUM> may include a court transfer function responsive only to the court contract <NUM> for implementing remedying transfers. One embodiment of such a court transfer function is discussed above, while a further embodiment is discussed below. In embodiments, the court contract <NUM> itself may include a court transfer function responsive only to the court contract <NUM> for implementing remedying transfers.

However, if at step <NUM>, the balance is less than the amount of tokens to be transferred as a remedy, the method proceeds along a course to provide one or both of a partial remedy or continuing remedy actions. For example, the method proceeds to step <NUM>, where a restriction is placed on the account receiving the erroneous transfer that prevents that account from making any transfers other than to the account from which the erroneous transfer was made. The restriction may be placed on the account in a variety of ways. In one example, a list of accounts that owe tokens erroneously transferred to them may be maintained, such as by the transfer contract <NUM>, and the transfer function of the transfer contract <NUM> may consult the list before conducting a transfer of tokens, with the transfer function not conducting the transfer if the account attempting to transfer tokens is on the list. In another example, an outstanding debt of erroneously transferred tokens may be maintained for an account that erroneously received tokens, and the transfer function of the transfer contract <NUM> may consult the outstanding debt before conducting a transfer of tokens from that account, with the transfer function not conducting the transfer until the outstanding debt is zero.

Below are exemplary program instructions illustrating another example embodiment of a court token transfer function, a token transfer function, and a restriction function of a token transfer contract:
<IMG>
<IMG>
The exemplary restriction function updateBlacklist() maintains a list of accounts of the distributed ledger system that owe tokens erroneously transferred to them (e.g., via the instruction: blacklist[_address] = _status), and the exemplary transfer function transfer() checks the maintained list (e.g., via the instruction: if (. !blacklist[msg. sender])), and only performs a requested transfer if the invoker of the transfer msg. sender is not on the maintained list. Also, the exemplary court transfer function courtTransfer() maintains an outstanding amount of erroneously transferred tokens still owed by an account that erroneously received tokens as the tokens are partially transferred back to the originating account (e.g., via the instruction: outstanding[_from] = _amount - balances[_from]), and the transfer function transfer() consults the outstanding debt before conducting a transfer of tokens (e.g., via the instruction: if (. outstanding[msg. sender] == <NUM>. )), with the transfer function not conducting the transfer until the outstanding debt is zero.

Other embodiments of a restriction function, a transfer function, and a court transfer function may include different specific program instructions.

Returning to <FIG>, at step <NUM>, a check is conducted of whether the balance of the account from where the remedying transfer is to be taken is greater than zero. The check may be conducted by a contract, such as the court contract <NUM> or transfer contract <NUM>, executing program logic to determine the balance of the account and comparing the determined balance to zero.

If at step <NUM>, the balance is greater than zero, the method proceeds to step <NUM>, where the existing balance is transferred from the indicated account owing the debt to the indicated account from which the erroneous transfer originated. The court contract <NUM> may execute the transfer by generating and transmitting a transaction, or executing a call, to the token transfer contract <NUM> to request the transfer. The transaction or call to the transfer contract <NUM> may include identification of the account in the distributed ledger system <NUM> of the party from whom the debt will be transferred, the account in the distributed ledger system <NUM> of the party to whom the tokens will be transferred to remedy the erroneous transfer, and the number of tokens to be transferred.

At step <NUM>, the outstanding debt of tokens of the account receiving the erroneously transferred tokens is updated to reflect the transfer of tokens conducted at step <NUM>. The updating may be conducted by a contract, such as the court contract <NUM> or transfer contract <NUM>, executing program logic to calculate the outstanding debt as a previous outstanding debt minus the amount of tokens transferred at step <NUM>.

At step <NUM>, a check is conducted of whether the outstanding debt of erroneously transferred tokens is greater than zero. The check may be conducted by a contract, such as the court contract <NUM> or transfer contract <NUM>, executing program logic to compare the outstanding determined at step <NUM> to zero.

If at step <NUM>, the outstanding debt is not greater than zero, the method proceeds to step <NUM>, where the restriction on the account that received the erroneous transfer from making any transfers other than remedying transfers is removed. The restriction may be removed from the account in a variety of ways. In one example, where a list of accounts that owe tokens erroneously transferred to them is maintained, such as by the court contract <NUM> or the transfer contract <NUM>, as discussed above, the restriction may be removed by removing the account from this list. In another example, where an outstanding debt of erroneously transferred tokens is maintained for an account that erroneously received tokens, the restriction may be removed by this debt reaching zero and any conditions placed on this debt being greater than zero likewise being removed or evaluating in manner to permit transfers.

If at step <NUM>, the outstanding debt is greater than zero, the method proceeds to step <NUM>, where the method waits for the passage of a predetermined period of time or until a predetermined trigger occurs, upon which the method proceeds back to step <NUM>. By waiting for the predetermined period of time or trigger, and then rechecking the balance of the account owing the debt of erroneously transferred tokens, the method is able to conduct an ongoing remedial action to detect and then transfer out any tokens newly accumulated by the account. The predetermined trigger may take a variety of forms, such as the creation of a new ledger structure in the distributed ledger system, e.g., the creation of a new block in a blockchain-based distributed ledger system. The method ends at step <NUM>.

<FIG> is a diagram showing an embodiment of function and data flows of the methods of <FIG> and <FIG>. In first and second events, the first and second counterparty systems <NUM>, <NUM> generate and transmit transactions to the contract <NUM> to initiate and/or authorize the contract <NUM> to conduct the financial or other transaction. In a third event, the contract <NUM> generates and transmits a transaction to the transfer contract <NUM> to initiate and/or authorize the transfer contract <NUM> to conduct a token transfer between accounts of the first and second counterparties as part of the financial or other transaction. In a fourth event, the transfer contract <NUM> conducts the token transfer between the accounts of the first and second counterparties as part of the financial or other transaction. In a fifth event, upon discovering an illegality, unintended aspect or other problem with the conducting of the token transfer for the financial or other transaction, the first counterparty system <NUM> transmits a request to the court system <NUM> for a judgment against the contract <NUM>. In a sixth event, upon determining a judgment against the contract <NUM>, the court system <NUM> generates and transmits a transaction to the court contract <NUM> to request remedial action against the contract <NUM>. In a seventh event, the court contract <NUM> generates and transmits a transaction to the transfer contract <NUM> to initiate and/or authorize the transfer contract to conduct a remedial token transfer or other action between accounts of the first and second counterparties. In an eighth event, the transfer contract <NUM> conducts the remedial token transfer or other action between the accounts of the first and second counterparties. Other embodiments of function and data flows may include additional and/or different function and data flow events.

In embodiments, function and data flows of a method of intervening in the operation of a smart contract may include only any subset of, or an alternative ordering of, the features depicted in or discussed above in regard to <FIG>.

Claim 1:
A method of remedying an erroneous transaction in a distributed ledger system, the method comprising:
determining, by a court system associated with the distributed ledger system, a judgment that a transfer by a token transfer smart contract of the distributed ledger system while conducting the transaction, of a quantity of tokens of the distributed ledger system from a first account of the distributed ledger system to a second account of the distributed ledger system, is erroneous; and
in response to determining the judgment:
determining, by a court smart contract of the distributed ledger system, a balance of tokens of the second account, the court smart contract including program instructions stored in a ledger of the distributed ledger system;
in response to determining that the balance of the second account is less than the quantity of tokens erroneously transferred, executing, by the court smart contract, a restriction function of the token transfer smart contract to prevent transfers of tokens from the second account other than by the court smart contract; and
executing, by the court smart contract, a transfer function of the token transfer smart contract, the token transfer smart contract including program instructions stored in the ledger of the distributed ledger system, the transfer function configured to be responsive to the court smart contract, to transfer at least a portion of the quantity of tokens from the second account to the first account.