WO2015116998A2

WO2015116998A2 - Electronic transfer and obligation enforcement system

Info

Publication number: WO2015116998A2
Application number: PCT/US2015/013908
Authority: WO
Inventors: Gary Kremen
Original assignee: Gary Kremen
Priority date: 2014-01-30
Filing date: 2015-01-30
Publication date: 2015-08-06
Also published as: WO2015116998A3

Abstract

Several embodiments includes a secured method of implementing an electronic transfer system in a distributed manner while enforcing an obligatory distribution rule. A computer can receive an electronic record representing an electronic transfer of a transfer amount from a source account to a destination account; verify availability of the transfer amount from the source account via a public ledger in a distributed consensus system; determine a conditional circumstance of the electronic transfer; access an obligatory distribution rule object, wherein the obligatory distribution rule object dictates how the transfer amount is distributed amongst the destination account and at least a third account; authenticate the obligatory distribution rule object with a sponsor server; and generate a second electronic record based on the obligatory distribution rule object, the conditional circumstance, and/or the electronic record to modify the electronic transfer to distribute a portion of the transfer amount to the third account.

Description

ELECTRONIC TRANSFER AND OBLIGATION ENFORCEMENT SYSTEM

CROSS-REFERENCE TO RELATED APPLICATION^) [Θ001] This application claims the benefit of U.S. Provisional Patent Application No.

61/933,474, entitled "ELECTRONIC TRANSFER AND OBLIGATION ENFORCEMENT SYSTEM," which was filed on January 30, 2014, which is incorporated by reference herein in its entirety.

RELATED FIELD

[0002] This disclosure relates to electronic transfer systems. More particularly, this disclosure relates to systems and techniques for implementing a decentralized electronic transfer system.

BACKGROUND

[ΘΘ03] Decentralized electronic transfer systems are created to circumvent the necessity and avoid the costs of having a central entity checking and validating each transfer. Central electronic transfer systems rely on the central entity to validate a transfer request made by a user via identification and authentication of the user. An electronic transfer represents a persistent record of an electronic communication that denotes a public or semi- public transfer of quantified value from one account to another.

[0004] On the other hand, decentralized electronic transfer systems rely on identification and publication of user accounts (e.g., via public electronic addresses whose ownership is cry to graphically verifiable) and electronic transfers to validate a transfer request. This enables the public to access all electronic transfers in a public ledger (e.g., maintained in a distributed consensus system) and to check the correctness (e.g., via cryptographic verification) of such electronic transfers in these decentralized systems. This form of crowd-based transfer control, combined with mechanisms to reject incorrect published transfers, form the backbone of most decentralized electronic transfer systems. The decentralized electronic transfer systems enable users to remain anonymous in each transfer.

[Θ005] A drawback of the decentralized electronic transfer system is a lack of means to enforce legal obligations that is normally associated with other electronic transfers.

Consequently, use of decentralized electronic transfer systems can become a channel to avoid legal obligations. BRIEF DESCRIPTION OF THE DRAWINGS

[0006] FIG. 1 is a diagrammatic representation of a conventional decentralized digital exchange system.

[0007] FIG. 2 is a diagram illustrating a decentralized electronic transfer system with distribution control capability.

[0008] FIG. 3 is an example of a data flow diagram for initiating an electronic transfer on the electronic transfer system.

[0009] FIG. 4 is a control flow diagram of an electronic transfer system for facilitating secure electronic transfers.

[0010] FIG, 5 is a flow chart of a method of operating a computing node in an electronic transfer system for facilitating secure electronic transfers.

[0011] FIG. 6 is a diagrammatic representation of a machine in the exemplary form of a computer system within which a set of instructions, for causing the machine to perform any one or more of the methodologies or modules discussed herein, may be executed.

[0012] The figures depict various embodimen ts for purposes of illustration only. One skilled in the art will readily recognize from the following discussion that alternative embodiments of the structures and methods illustrated herein may be employed without departing from the principles of the embodiments described herein.

DETAILED DESCRIPTION

[0013] This disclosure is directed at technical means for authorizing and modifying electronic transfers based at least in part on digital means of determining obligations associated with each electronic transfer. Such obligations may stem from obligations of residents within a governing sovereignty, such as tax obligations within a country. Such obligations may also stem from contractual obligations for using a particular electronic transfer related service, such as crypto-currency service, electronic insurance service, electronic banking service, electronic transaction service, digital accounting service, etc. The disclosed techniques can provide a method of enforcing legal obligations while allowing at least some of the participants of the electronic transfers to remain anonymous. The disclosed techniques further provide a way for a sponsor (e.g., the beneficiary of the obligations) or a hierarchy of sponsors to manage and modify the obligations at a system-level to ensure that al l electronic transfers, anonymous or not, are consistent with the obligations.

[ΘΘ14] An electronic transfer system implementing the disclosed techniques can provide secured publication and authentication of the rules that dictate the obligations of parties in an electronic transfer. The secured publication and authentication of these rules issued by the sponsor(s) protect the electronic transfers against malicious electronic attacks and scams. Once authenticated, the issued rules can become a fundamental part of the electronic transfer system implemented by a network of computing nodes. Alternatively, the issued rules can be inserted into each electronic transfer as part of the digital contract of the electronic transfer. It is hence noted that these technical means are beyond mere

administrative procedures that a computer programmer may be asked to implement.

[Θ015] A decentralized electronic transfer system may include computing nodes that are each capable of identifying, validating, and publishing transfer requests. Each transfer request may require a validation that a source account derives a transfer amount from a history of electronic transfers. The validation serves to verify at least one part of the transfer request. A cryptographic verification of each block in the chain of transfer further validates the transfer request.

[ΘΘ16] The disclosed electronic transfer system can issue digital currency

cryptographically. The electronic transfer system can safeguard the safety, integrity, and balance of all ledgers for the digital currency via cryptographic signatures and proof of work. The disclosed electronic transfer system can enable bond issuance and inflation control of the digital currency. The disclosed electronic transfer system can issue new digital currency from the sponsor and buy back existing digital currency from the sponsor. The disclosed electronic transfer system further enables the sponsor to back the digital currency with real property or physical items, such as precious metal. The disclosed electronic transfer system can maintain audit trails for all electronic transfers so that the sponsor can enforce contractual or legal rules or laws despite granting the ability for participants to be anonymous.

[0017] FIG. 1 is a diagrammatic representation of a conventional decentralized digital exchange system 100, such as BitCoin or Ripple. The digital exchange system 100 can be implemented by a decentralized network of computing nodes, such as desktop computers, computer servers, mobile devices, or any combination thereof. Computing nodes can freely join the network to request an electronic transfer involving an amount of digital currency or leave the network. Every computing node within the network can store a complete history of all electronic transfers ever made in the digital exchange system 100.

[0018] FIG. 2 is a diagram illustrating a decentralized electronic transfer system 200 with distribution control capabi lity. The electronic transfer system 200 can also be implemented by a decentralized network of computing nodes. The computing nodes can also freely join the network to request an electronic transfer or leave the networ k. E very computing node within the network can store a complete history of all electronic transfers ever made in the electronic transfer system 200. The electronic transfer system 200 differs from the conventional digital exchange in that a sponsor or a hierarchy of sponsors can propagate rules to modify all electronic transfers going through the electronic transfer system. These rules can be cryptographically verified so that malicious entities are prevented from destroying or stealing ownership interests of any accounts within the electronic transfer system.

[0019] FIG. 3 is an example of a data flow diagram for initiating an electronic transfer on the electronic transfer system. Illustrated is a transfer request 302 that can be propagated from computer node to computer node within a decentralized electronic transfer system, such as the electronic transfer system 200 of FIG, 2, implemented by a network of computer nodes. The transfer request 302 includes an indication of a source account 304 and an indication of a destination account 306. In some embodiments, the transfer request 302 can include multiple source accounts and/or multiple destination accounts. An indication of the source account 304 can include attributes of the source account, such as location, IP address, or identifier (e.g., via national identification schemes such as Social Security). An indication of the destination account 306 can include attributes of the destination account, such as location, IP address, or identifier (e.g., via national identification schemes such as Social Security). The transfer request 302 further includes an indication of a transfer amount 308. Optionally, the transfer request 302 may indicate the currency type(s) of digital or real- world currency to use for the electronic transfer.

[0020] A computing node can verity the transfer amount 308 against a block chain 310 of electronic transfers. The block chain is a sequential linked list of blocks, where each block is a group of electronic transfers that are deemed to have occurred concurrently. The computing node can determine a complete electronic transfer history 311 of all electronic transfers that occurred on the electronic transfer system from the block chain 310.

[0021J The computing node can determine whether the transfer request 302 needs to be modified by checking against an obligatory distribution rule object 312. The obligatory distribution rule object 312 is a data structure that dictates the circumstances under which a transfer request should be modified, how the transfer request should be modified, and how much of the transfer amount is to distribute amongst the destination account and one or more sponsor accounts. The obligatory distribution rule object 312 may be a hierarchical data structure, where the distribution rule corresponding to a higher level node (i.e., closer to the root node) applies first before the distribution rule corresponding to a lower level applies, [0022] The transfer request 302 may include other electronic transfer

information 314, such as timestamp of the request, available currency of the source account, other self-reported information by a user of the source account, an object (e.g., merchandise or services) of the request, contractual tenns of the request, necessary conditions to effectuate the electronic transfer, etc., or any combination thereof. Ail of the information contained within the transfer request 302 may be used to match an entry within the obligatory distribution rule object 312. The entry dictates how^r the transfer request should be modified and how much of the transfer amount is to distribute amongst the destination account and the one or more sponsor accounts. Optionally, the transfer request 302 may include a sponsor list 316. The user of the source account can voluntarily include itself under the jurisdiction of particular sponsors listed in the sponsor list 316 in exchange for service, legal rights or interest, monetary incentive, property, or a combination thereof.

[0023] FIG, 4 is a control flow diagram of a computing node 400 of an electronic transfer system, such as the electronic transfer system 200 of FIG, 2, The computing node 400 can facilitate secure electronic transfers within the electronic transfer system implemented by network of computing nodes. The computing node 400 includes a user interface module 402. The user interface module 402 generates and displays a user interface so that a user can make electronic transfers through the electronic transfer system. The user interface may request the user to present a private key associated with a user account whenever the user requests an electronic transfer to he made.

[0024] The computing node 400 also includes a transfer protocol module 404 implemented to communicate with other computing nodes within the electronic transfer system. The transfer protocol module 404 may include a cryptography module 406 capable of verifying certificate signatures. The cryptography module 406 can determine a hash code from a message and/or a private key. The cryptography module 406 can also verify whether a given private key matches a given hash code.

[0025] The transfer protocol module 404 has access to a local memory 408. The local memory 408 may include a rule object cache 410 and a transfer history cache 412. The rule object cache 410 stores at least an instance of an obligatoiy distribution rule object, such as the obligatory distribution rule object 312 of FIG, 3. The transfer protocol module 404 can update the rule object cache 410 with a newer instance of the obligator)' distribution rule object based on an updated schedule or in response to push messages from one or more sponsor servers (i.e., computing devices operated by one of the sponsor entities). The cryptography module 406 can authenticate such updates. The transfer history cache 412 stores a block chain of electronic transfers, such as the block chain 310 of FIG. 3. The transfer protocol module 404 can update the transfer history cache 412 from one or more peer computing nodes in the electronic transfer system. The cryptography module 406 can authenticate each block within the block chain.

[Θ026] Regarding FIG. 4, blocks, components, and/or modules associated with the computing node 400, each may be implemented in the form of special-purpose circuitry, or in the form of one or more appropriately programmed programmable processors, or a combination thereof. For example, the modules described can be implemented as instructions on a tangible storage memory capable of being executed by a processor or a controller on a machine. The tangible storage memory may be volatile or non-volatile memory. In some embodiments, the volatile memory may be considered "non-transitory" in the sense that it is not a transitory signal. Modules may be operable when executed by a processor or other computing device, e.g., a single board chip, application-specific integrated circuit, a field programmable field array, a network capable computing device, a virtual machine terminal device, a cloud-based computing terminal device, or any combination thereof, ( aches, memory space, and storages described in the figures can be implemented with the tangible storage memory as well, including volatile or non-volatile memory. [0027] Each of the modules may operate individually and independently of other modules. Some or all of the modules may be executed on the same host device or on separate devices. The separate devices can be coupled via a communication module to coordinate its operations via an interconnect or wirelessly. Some or all of the modules may be combined as one module.

[0028] A single module may also be divided into sub-modules, each sub-module performing separate method step or method steps of the single module. In some

embodiments, the modules can share access to a memory space. One module may access data accessed by or transformed by another module. The modules may be considered "coupled" to one another if they share a physical connection or a virtual connection, directly or indirectly, allowing data accessed or modified from one module to be accessed in another module. In some embodiments, some or all of the modules can be upgraded or modified remotely. The computing node 400 may include additional, fewer, or different modules for various applications.

[0029] FIG. 5 is a flow chart of a method 500 of operating a computing node in an electronic transfer system for facilitating secure electronic transfers. The electronic transfer system can be implemented as a decentralized network of computer nodes. For exampl e, applications on the computer nodes can share a standardized protocol or application programming interface to make electronic transfers. The electronic transfers are transactions that move a quantity of accountable resources from one account to another. The electronic transfers are identified, verified, validated, and published by the network of computing nodes. The accountable resources may include social currency (e.g., social approval rating, social trust score, etc.), electronic records of credit/debit, digital ledgers, digital currency, crypto- currency (e.g., Bitcoin, Novacoin, XRP, Linden dol lars ), other means of tracking real world or virtual items of value, interest, obligation, rights, or ownership share, or any combination thereof.

[0030] The method 500 includes a computer node receiving, in step 502, a first digital string representing an electronic transfer of a transfer amount from a source account to a destination account. The first digital string represents a transfer request. Step 502 can represent the step where the user of the source account attempts to initiate an electronic transfer to move the transfer amount of accountable resources to the destination account.

[0031] Before publishing the electronic transfer, the electronic transfer system must verify the availability of the transfer amount and determine whether any obligatory distribution has to be made from the transfer amount or whether the transfer amount has to be modified. As shown in FIG, 5, a computer node verifies, in step 504, the availability of the transfer amount from the source account via a transaction history. The computer node of step 504 can be the computer node that received the first digital string and publishes the first digital string. The computer node of step 504 can also be a computer node that is propagating the electronic transfer through the decentralized network. Further, the computer node of step 504 can be a block producing computer node that decides whether to include the electronic transfer in a new block that is to be included in the next instance of the transaction history. The transaction history is a chain of blocks. Each block can be cryptographical ly validated. Each block contains a group of electronic transfers that have been sent since the previous block. The transaction history can be used to validate electronic transfers that traces the transfer amount of accountable resources have indeed been allocated to the source account since the latest block in the transaction history. For example, each block in the chain of verifiable electronic transfers can be verified and validated mathematically through a cryptographic proof of work, such as using a hashcash cost function. Other technical methods known to one of ordinary ski ll in the related field of this disclosure can also be used to verify the availability of the transfer amount.

[0032] The computer node can also access, in step 506, conditional circumstances of the electronic transfer after the transfer request is received. A conditional circumstance is a digital means of quantifying an attribute of the electronic transfer or of accounts involved in the electronic transfer. The conditional circumstances may be used to determine how the transfer amount is to be distributed to the destination account and/or to at least a third account. In various embodiments, the third account represents a government taxing agency. A conditional circumstance of the electronic transfer may pertain to an attribute of the source account, an attribute of the destination account, an attribute of the electronic transfer, or an attribute of the third account. For example, the conditional circumstance may be an identification (e.g., ID links to national identity schemes such as Social Security numbers) of the source account, the destination account, or the third account. As another example, the conditional circumstance may be a physical or virtual location identifier of the source account, the destination account, or the third account.

[Θ033] Other examples of the conditional circumstances include a time stamp of the electronic transfer; an account type of the source account, the destination account, or the third account; the transfer amount involved in the electronic transfer; revenue of the source account, the destination account, or the third account; business type of the source account, the destination account, or the third account; a digital indication of an object of the electronic transfer, the object being a merchandise, a sendee, a property, or a legal interest; a digital indication of a contractual term of the electronic transfer; a system- wide condition associated with a network of computing nodes; a system-wide condition associated with a statistical distribution of at least a portion of electronic transfers within the network of computing nodes; how the electronic transfer is to be carried out; whether the source account, the destination account, or the third account is anonymous; whether the transfer amount is backed by physical good or property; whether the transfer amount is backed by nationally issued currency; or any combination thereof.

[0034] The computing node can access, in step 508, an obligatory distribution rale object in its local cache to determine how the transfer amount is to be distributed amongst the destination account and at least a third account. Upon retrieving the obligatory distribution rule object, the computing node can authenticate the obligatory distribution rule object with at least a sponsor server in step 510. In various embodiments, the computer node can authenticate the obiigatoiy distribution rule object with other external servers, including other computing notes of the electronic transfer system.

[Θ035] Once the conditional circumstance is determined and the obligatory distribution rule object is authenticated, the computing node generates, in step 512, a second digital string based at least partly on the obligatory distribution rule object, the conditional circumstance, and the first digital string to modify the electronic transfer to distribute a portion of the transfer amount to the third account. The computing node then publishes, in step 514, the second digital string electronically to other nodes in the electronic transfer system to represent a modified electronic transfer in accordance with the obligator)' distribution rule object,

[0036] While processes or blocks are presented in a given order in FIG. 5, alternative embodiments may perform routines having steps, or employ systems having blocks, in a different order, and some processes or blocks may be deleted, moved, added, subdivided, combined, and/or modified to provide alternative or subcombinations. Each of these processes or blocks may be implemented in a variety of different ways. In addition, while processes or blocks are at times shown as being performed in series, these processes or blocks may instead be performed in parallel, or may be performed at different times.

[0037J FIG. 6 is a block schematic diagram that depicts a machine in the exemplar}' form of a computer system 600, such as the computing node 400 of FIG, 4, within which a set of instructions for causing the machine to perform any of the herein disclosed

methodologies may be executed. In alternative embodiments, the machine may comprise or include a network router, a network switch, a network bridge, personal digital assistant (PDA), a cellular telephone, a Web appliance or any machine capable of executing or transmitting a sequence of instructions that specify actions to be taken. The computer system 600 is intended to illustrate a hardware device on which any of the instructions, processes, modules and components depicted in the examples in FIGs. 3-5 (and any other processes, techniques, modules, and/or components described in this specification) can be implemented. As shown, the computer system 600 includes a processor 602, memory 604, non-volatile memory 606, and a network interface 608. Various common components (e.g., cache memory) are omitted for illustrative simplicity. The computer system 600 can be of any applicable known or convenient type, such as a personal computer (PC), or a server-class computer or mobile device (e.g., smartphone, card reader, tablet computer, etc.). The components of the computer system 600 can be coupled together via a bus and/or through any other kno wn or con venient form of interconnect.

[Θ038] One of ordinary skill in the relevant art will recognize that the terms

"machine-readable (storage) medium" or "computer-readable (storage) medium" include any type of device that is accessible by the processor 602, The memory 604 is coupled to the processor 602 by, for example, a bus 610. The memory 604 can include, by way of example but not limitation, random access memory (RAM), such as dynamic RAM (DRAM) and static RAM (SRAM). The memory 604 can be local, remote, or distributed.

[0039] The bus 610 also couples the processor 602 to the non-volatile memory 606 and drive unit 612. The non-volatile memory 606 may be a hard disk, a magnetic-optical disk, an optical disk, a read-only memory (ROM ), such as a CD-ROM, Erasable

Programmable Read-Only Memory (EPROM), or Electrically Erasable Programmable Readonly Memory (EEPROM), a magnetic or optical card, or another form of storage for large amounts of data. The non-volatile memory 606 can be local, remote, or distributed.

[0040] The data structures, modules, and instruction steps described in FIGs. 3-5 may^¬ be stored in the non-volatile memory 606, the drive unit 612, or the memory 604. The processor 602 may execute one or more of the modules stored in the memory components, [0041] The bus 610 also couples the processor 602 to the network interface 608. The network interface 608 can include one or more of a modem or network interface, A modem or network interface can be considered to be part of the computer system 600. The network interface 608 can include an analog modem, ISDN modem, cable modem, token ring interface, satellite transmission interface (e.g., "direct PC"), or other interfaces for coupling a computer system to other computer systems. [0042] It is to be understood that embodiments may be used as, or to support, software programs or software modules executed upon some form of processing core (such as the CPU of a cornputer) or otherwise implemented or realized upon, or within, a machine or computer readable medium. A machine -readable medium includes any mechanism for storing or transmitting information in a form readable by a machine, e.g., a computer. For example, a machine readable medium includes read-only memory (ROM); random access memor}_' (RAM); magnetic disk storage media; optical storage media; flash memory devices; electrical, optical, acoustical or other form of propagated signals, such as, carrier waves, infrared signals, digital signals, etc.; or any other type of media suitable for storing or transmitting information.

[0043] Although system and methods are described herein with reference to one or more embodiments, one skilled in the art will readily appreciate that other applications may be substituted for those set forth herein without departing from the spirit and scope of the disclosure.

[0044] Some embodiments of the disclosure have other aspects, elements, features, and steps in addition to or in place of what is described above. These potential additions and repl acements are described throughout the rest of the specification. For example, some embodiments include a method of operating a computing node in an electronic transfer system. The electronic transfer system can include a distributed computer system

implemented by a network of delegation nodes for facilitating secure electronic transactions. The computing node can be one of the delegation nodes, or a computing device with network access to the delegation nodes. The method advantageously provides a mechanism to facilitate the anonymous or pseudo-anonymous electronic transfers in a distributed manner (e.g., without a centralized server system) while enforcing transfer-related rules managed by a central entity. This mechanism provides a technical solution to the technical problem (e.g., difficulty in transfer-related rule enforcement) faced in implementing the electronic transfer system, such as a distributed consensus system.

[0045] The method can include the computing node receiving a first digital string

(e.g., an electronic record) representing an electronic transfer of a transfer amount from a source account to a destination account. The first digital string can be cryptographically signed with a private key corresponding to the source account and/or a private key corresponding to the destination account. Receiving the first digital string can include receiving the first digital string f om another computer node with an indication to propagate and publish the first digital string to other nodes in the network. Receiving the first digital string can include receiving the first digital string via a local application executed by a processor. The local application can provide a user interface on a local display component for a user to certify that the user is an owner of the source account through a local input component.

[ΘΘ46] The computing node can then verify availability of the transfer amount from the source account in a transaction history database. The transaction history database can maintain transaction records for all electronic transfers that ever occurred through the distributed consensus system (e.g., the electronic transfer system). The transaction history database may be available as a public ledger provided by the distributed consensus system .

[0047] For example, the distributed consensus system can include multiple delegation nodes (e.g., computing devices). The public ledger can be maintained in a distributed manner, such as a block chain, in these delegation nodes. The block chain keeps track of all confirmed electronic transfers that are reported to the distributed consensus system.

[Θ048] In several embodiments, the block chain confirms the electronic transfers via the distributed consensus system. The distributed consensus system confirms waiting electronic transfers by including them in the block chain. The distributed consensus system enforces a chronological order in the block chain and hence protects the neutrality of a network of delegation nodes that implements the public ledger. This enables the block chain to keep track of multiple electronic transfers in sequential groups (e.g., blocks). Any external computing device can access the block chain to verify that there is one or more

cryptographically verified sequence of ancestor electronic transfers that sourced a given electronic transfer by accessing the block chain. If the given electronic transfer can be traced back to an origination of value (e.g., a cryptographically "minted" digital currency), then that given electronic transfer can be verified and confirmed.

[0049] In some embodiments, after verifying the availability of the transfer amount, the computing node determines a conditional circumstance of the electronic transfer. The computing node can access an obligatory distribution rule object. For example, the obligator}' distribution rule object dictates how the transfer amount is distributed amongst the destination account and at least a third account. The computing node then authenticates the obligatory distribution rule object against a sponsor server (e.g., a computer server that has access to a public cryptographic key of a "sponsor". For example, the obligatory distribution rule object may be signed by a cryptographic signature using a private cryptographic key (e.g., corresponding to the public cryptographic key accessible to the sponsor server) of the sponsor. The sponsor server or another server with access to a corresponding public cryptographic key can verify the cryptographic signature of the obligatory distribution rule object .

[0050] For example, the conditional circumstance can include an attribute of the destination account, the source account, or the third account; an attribute of the el ectronic transfer; an identification of the source account, the destination account, or the third account; a location identifier of the source account, the destination account, or the third account; a time stamp of the electronic transfer; an account type (e.g., indicated as an enumeration for at least a non-profit organization account, a charity account, a religious entity account, a wholesaler account, a consumer account, a retailer account, a local business account, a service provider account, a large business account, a small business account, an international business account, or any combination thereof) of the source account, the destination account, or the third account; the transfer amount; a digital indication of an object (e.g., a

merchandise, a service, a property, or a legal interest ) of the electronic transfer; a digital indication of a contractual term of the electronic transfer; a system- wide condition associated with the network of the delegation nodes; a system-wide condition associ ated with a statistical distribution of at least a portion of electronic transfers within the network of the delegation nodes; how the electronic transfer is to be carried out (e.g., whether the electronic transfer is pre-authenticated or pre -validated, whether the source account, the destination account, or the third account is anonymous, whether the transfer amount is backed by at least a physical good or property, whether the transfer amount is backed by nationally issued currency, or any combination thereof), or any combination thereof.

[0051J In response to verifying the obligatory distribution rule object, the computing node can execute the distribution rule by generating a second digital string (e.g., an electronic record) based at least partly on the obligator}' distribution rule object, the conditional circumstance, and the first digital string to modify the electronic transfer to distribute a portion of the transfer amount to the third account. For example, the computing node can generate the second digital string by matching the conditional circumstance to a rule entry of the obligatory distribution rule object and executing a distribution apportionment indication corresponding to the rule entry to modify the electronic transfer.

[0052] In some embodiments, the computing node can generate a transfer record corresponding to the second digital string and publish the transfer record to the public ledger. The computing node can publish the transfer record responsive to the obligator}' distribution rule object being authenticated. For example, a delegation node of the distributed consensus system can incorporate the transfer record to a newly created block (e.g., containing a group of electronic transfers along with a proof-of-work indication) for appending to the end of the block chain. The delegation node can include the second digital string in the block responsive to the obligatory distribution rule object being authenticated. The computing node can then publish the block to the network of the delegation nodes in the distributed consensus system.

[0053] In some embodiments, the computing node can receive an indication from a user (e.g., verified user) of the source account. The indication can identify the third account based on the user's choice, in these embodiments, the portion of the transfer amount to the third account is dictated by the obligatory distribution rule object.

[0054] In some embodiments, the obligator}' distribution rule object dictates at least a tax obligation within a sovereign governing entity, and the sponsor server is controlled by the sovereign governing entity. In some embodiments, the obligatory distribution rule object dictates a jurisdictional boundary of the soverei gn governing entity and conditional circumstances that places an account beyond or within the jurisdictional boundary. For example, whether an electronic transfer falls within the jurisdictional boundary can be determined by a geographical location of the internet protocol (IP) address associated with the source account, the destination account, or the computing node.

[0055] In some embodiments, the obligatory distribution rule object dictates at least a fee owed to a credit issuer, and the sponsor server is controlled by the credit issuer. In some embodiments, the obligatory distribution rule object dictates at least a service fee owed to a service provider, and the sponsor server is controlled by the sendee provider. For example, the service provider can be a provider of digital currency; and the transfer amount is measured in that digital currency.

[0056] In some embodiments, the obligatory distribution rule object includes a conditional tree structure. Each node of the conditional tree structure can determine what conditions trigger a modification of the electronic transfer, how the transfer amount is to be distributed, who to distribute the amount to, or any combination thereof. For example, when the conditional circumstance of the computing node matches more than one node of the conditional tree structure, a branch node closer to the root node of the conditional tree structure governs how the transfer amount is to be distributed. In some embodiments, the obligatory distribution rule object includes a conditional tree structure. At least a branch node can correspond to a sub-sponsor that dictates a distribution apportionment of how the transfer amount is distributed but only if the distribution apportionment is consistent with conditional logics of a parent node of the branch node. [0057] For example, the obligatory distribution rule object includes a conditional tree structure with two or more levels. The root level can represent taxation required by a national soverei gn government. A. branch level can represent taxation required by local government or service fee requested by a service provider. For example, the obligatory distribution rule object can include a conditional tree structure with two or more levels.

Authentication of the obligator}' distribution rule object can include the computing node authenticating against a plurality of sponsor servers (e.g., including agents of the sponsor having the public key associated with the sponsor) corresponding to nodes in the obligatory distribution rule object. In this example, generating the second digital string can include determining which nodes of the obligatory distribution rule object apply to the electronic transfer. Here, the plurality of the sponsor servers can respectively correspond to the nodes that do apply to the electronic transfer in question.

[0058J In some embodiments, authenticating the obligatory distribution rule object includes receiving a cryptographic hash that solves a cryptographic puzzle. For example, the computing node can authenticate the obligatory distribution rule object by performing a mutual authentication using a challenge-response handshake in both directions between the computing node and the sponsor server.

[0059] In some embodiments, the obligatory distribution rule object dictates a jurisdictional boundary of a sponsor entity and conditional circumstances that places an account beyond or within the jurisdictional boundary. The sponsor entity can control the sponsor server. For example, the obligatory distribution rule object can dictate a increase of the transfer amount from the source account when the source account falls within the jurisdictional boundary. The obligatory distribution rule object can dictate a portion of the transfer amount that is to be deposited to the third account instead of the destination account when the destination account falls within the jurisdictional boundary. The account can indicate that it is within the jurisdictional boundary when the account has signed up for a sendee provided by the sponsor server or the sponsor entity. For example, the service provided by the sponsor entity or the sponsor server can include interest value generation, cache recovery, cryptographic key storage, risk management, accounting service, legal service, inflation protection, the reward or refund incentive, or any combination thereof. The service provided can also include providing allocation of at least a portion of digital currency implemented by the electronic transfer system that is lost due to shrinkage of the account.

[0060] In some embodiments, the computing node accesses the obligatory distribution rule object by retrieving the obligatory distribution rule object from a local cache on the computer node or retrieving it from a remote server. In some embodiments, the computing node can poll the sponsor server based on a schedule for updates to the obligatory distribution rale object. In some embodiments, the computing node can receive a push message from the sponsor server to update the obligatory distribution rale object. In some embodiments, the computing node can receive a push message from another node of the electronic transfer system to update the obligatory distribution rule object,

[Θ061] In some embodiments, when authentication of the obligatory distribution ru le object fails, the computing node retrieves an updated instance of the obligatory distribution rule object from the sponsor server, verifies authenticity and/or data integrity of the updated instance, and caches the updated instance in the local cache of the computing node. In some embodiments, the computing node propagates the updated instance to at least another node in the network of the comp uter nodes.

[0062 J The updated instance can include a certificate signature generated using a private cryptographic key known only to an operator of the sponsor server. The updated instance can include at least two certificate signatures generated with different private cryptographic keys. For example, authenticating the obligator}' distribution rale object can include performing a bifurcated authentication with the at least two certificate signatures. In some embodiments, a previous instance of the obligatory distribution rale object can include a first certificate signature generated by a first private key that indicates that the previous instance is generated from the sponsor server and the updated instance of the obligatory distribution rule object can include a second certificate signature generated by a second private key corresponding to the first certificate signature that indicates that the previous instance is to be replaced by the updated instance.

[0063] While processes, steps, and functional components are described in a given order for the method, alternative embodiments may perform routines having steps, or employ systems having components, implemented in a different order, and some processes, steps or components may be deleted, moved, added, subdivided, combined, and/or modified to provide al ternative or subcombinations. Each of these processes, steps, or components may be implemented in a variety of different ways. In addition, while processes, steps or components are at times described as being performed or executed in series, these processes, steps or components may instead be performed or executed in paral lel, or may be performed or executed at different times.

[0064] The various steps in the method described above can be implemented in the computing node, such as the computer system 600 of FIG. 1. The processor 602 can execute any number of the steps or functions described above as configured by executable instructions stored in the memory 604 or the non-volatile memory 606.

Claims

What is claimed is:

1. A method of operating a computing node in an electronic transfer system implemented by a network of computing nodes for facilitating secure electronic transactions, the method comprising:

receiving a first digital string representing an electronic transfer of a transfer

amount from a source account to a destination account;

verifying availability of the transfer amount from the source account via a public ledger in a distributed consensus system;

deteiiiiining a conditional circumstance of the electronic transfer;

accessing an obligatory distribution rule object, wherein the obligatory distribution rale object dictates how the transfer amount is distributed amongst the destination account and at least a third account;

authenticating the obligator distribution rule object with a sponsor server; and generating a second digital string based at least partly on the obligatory distribution rule object, the conditional circumstance, and the first digital string to modify the electronic transfer to distribute a portion of the transfer amount to the third account.

2. The method of claim 1, wherein generating the second digital string by matching the conditional circumstance to a rule entry of the obligatory distribu tion rule object and executing a distribution apportionment indication corresponding to the rule entry to modify the electronic transfer.

3. The method of claim 1, further comprising identifying the third account as indicated by a user of the source account; and wherein the portion of the transfer amount to the third account is dictated by the obligator}' distribution rale object.

4. The method of claim 1, wherein the obligatory distribution rale object dictates at least a tax obligation within a sovereign governing entity, and wherein the sponsor server is controlled by the sovereign governing entity.

5. The method of claim 4, wherein the obligatory distribution rule object dictates a jurisdictional boundary of the sovereign governing entity and conditional circumstances that places an account beyond or within the jurisdictional boundary.

6. The method of claim 1, wherein the obligatory distribution rule object dictates at least a fee owed to a credit issuer, and wherein the sponsor server is controlled by the credit issuer.

7. The method of claim 1, wherein the obligatory distribution rule object dictates at least a sendee fee owed to a service provider, and wherein the sponsor server is controlled by the sendee provider.

8. The method of claim 7, wherein the sendee provider is a provider of digital currency; and wherein the transfer amount is measured in that digital currency.

9. The method of claim 1 , wherein the obligatory distribution rule object includes a conditional tree structure, wherein each node of the conditional tree structure determines what conditions trigger a modification of the electronic transfer, how the transfer amount is to be distributed, who to distribute the amount to, or any combination thereof.

10. The method of claim 9, wherein when the conditional circumstance of the computing node matches more than one node of the conditional tree structure, a branch node closer to a root node of the conditional tree structure governs how the transfer amount is to be distributed.

11. The method of claim 1 , wherein the obligatory distribution rule object includes a conditional tree structure, wherein at least a branch node corresponds to a sub-sponsor that dictates a distribution apportionment of how the transfer amount is distributed but only if the distribution apportionment is consistent with conditional logics of a parent node of the branch node.

12. The method of claim 1, wherein the obligatory distribution rule object includes a conditional tree structure with two or more levels, wherein a root level represents taxation required by a national sovereign government, and a branch level represents taxation required by local government or service fee requested by a sendee provider.

13. The method of claim 1, wherein the obligatory distribution rule object includes a conditional tree structure with two or more levels, wherein authenticating the obligatory distribution rule object includes authenticating with a plurality of sponsor senders

corresponding to nodes in the obligatory distribution rule object.

14. The method of claim 13, wherein generating the second digital string includes determining which nodes of the obligatory distribution rule object apply to the electronic transfer, and wherein the plurality of the sponsor servers respectively correspond to the nodes that apply to the electronic transfer.

15. The method of claim 1, wherein authenticating the obligatory distribution rule object includes receiving a cryptographic hash that solves a cryptographic puzzle.

16, The method of claim 1 , wherein authenticating the obligatory distribution rule object includes performing a mutual authentication by using a challenge-response handshake in both directions between the computing node and the sponsor server.

17. The method of claim 1, wherein the conditional circumstance includes an attribute of the destination account.

18, The method of claim 1 , w^rherein the conditional circumstance includes an attribute of the source account.

19. The method of claim 1 , wherein the conditional circumstance includes an attribute of the third account.

20, The method of claim 1, wherein the conditional circumstance includes an attribute of the electronic transfer.

21. The method of claim 1, wherein the conditional circumstance includes an identification of the source account, the destination account, or the third account.

22. The method of claim 1, wherein the conditional circumstance includes a location identifier of the source account, the destination account, or the third account.

23. The method of claim 1, wherein the conditional circumstance includes a time stamp of the electronic transfer.

24. The method of claim 1, wherein the conditional circumstance includes an account type of the source account, the destination account, or the third account.

25. The method of claim 24, wherein the account type is indicated as an enumeration for at least a non-profit organization account, a charity account, a religious entity account, a wholesaler account, a consumer account, a retailer account, a local business account, a service provider account, a large business account, a small business account, an international business account, or any combination thereof.

26. The method of claim 1, wherein the conditional circumstance includes the transfer amount,

27. The method of claim 1, wherein the conditional circumstance includes a digital indication of an object of the electronic transfer, the object being a merchandise, a service, a property, or a legal interest.

28. The method of claim 1, wherein the conditional circumstance includes a digital indication of a contractual term of the electronic transfer.

29, The method of claim 1, wherein the conditional circumstance includes a system-wide condition associated with a network of delegation nodes of the distributed consensus system.

30. The method of claim 1, wherein the conditional circumstance includes a system- wide condition associated with a statistical distribution of at least a portion of electronic transfers within a network of delegation nodes of the distributed consensus system.

31. The method of claim 1, wherein the conditional circumstance includes how the electronic transfer is to be carried out.

32. The method of claim 31 , wherein how the electronic transfer is to be carried out includes whether the electronic transfer is pre-authenticated or pre-validated.

33. The method of claim 31, wherein how the electronic transfer is to be carried out includes whether the source account, the destination account, or the third account is anonymous.

34. The method of claim 31 , wherein how the electronic transfer is to be carried out includes whether the transfer amount is backed by at least a physical good or property.

35. The method of claim 31, wherein how the electronic transfer is to be carried out includes whether the transfer amount is backed by nationally issued currency.

36. A computing device, comprising:

a memory storing executable instructions;

a processor that is configured by the executable instructions to execute a process, the process comprising:

receiving a first electronic record representing an electronic transfer of a transfer amount from a source account to a destination account;

determining a conditional circumstance of the electronic transfer; accessing an obligatory distribution rule object, wherein the obligatory distribution rule object dictates how the transfer amount is distributed amongst the destination account and at least a third account;

authenticating the obligatory distribution rule object with a sponsor server; and

generating a second electronic record based at least partly on the

obligatory distribution rule object, the conditional

circumstance, and the first electronic record to modify the electronic transfer to distribute a portion of the transfer amount to the third account.

37. The computing device of claim 36, wherein receiving the first electronic record includes receiving the first electronic record from another computer node with an indication to propagate and publish the first electronic record to other nodes in network connection with the computing device.

38. The computing device of claim 36, wherein receiving the first electronic record includes receiving the first electronic record via a local application executed by a processor, the local application providing a user interface on a local display component for a user to certify th at the user is an owner of the source account through a local input component.

39. The computing device of claim 36, wherein the process further comprises: generating a transfer record corresponding to the second electronic record after the obligatory distribution rale object is authenticated; and publishing the transfer record to be included in a block containing a group of recent electronic transfers, the block being appended to an end of a block chain representing the public ledger.

40. The computing device of claim 36, wherein the obligatory distribution rule object dictates a jurisdictional boundary of a sponsor entity and conditional circumstances that places an account beyond or within the jurisdictional boundary; and wherein the sponsor entity controls the sponsor server.

41. The computing device of claim 40, wherein the obligatory distribution rule object dictates an increase of the transfer amount from the source account when the source account falls within the jurisdictional boundary.

42. The computing device of claim 40, wherein the obligatory distribution rale object dictates a portion of the transfer amount that is to be deposited to the third account instead of the destination account when the destination account falls within the jurisdictional boundary.

43, The computing device of claim 40, wherein the account is within the jurisdictional boundary when the account has signed up for a se dee provided by the sponsor server or the sponsor entity.

44, The computing device of claim 43, wherein the service provided includes interest generation, cache recovery, cryptographic key storage, risk management, accounting service, legal service, inflation protection, reward or refund incentive, or any combination thereof.

45. The computing device of claim 43, wherein the service provided includes allocating at least a portion of digital currency implemented by an electronic transfer system that is lost due to shrinkage of the account.

46. The computing device of claim 36, wherein accessing the obligatory distribution rule object comprises retrieving the obligatory distribution rule object from a local cache on the computing device.

47. The computing device of claim 46, wherein the process further comprises polling the sponsor server based on a schedule for updates to the obligatory distribution mle object.

48. The computing device of claim 46, wherein the process further comprises receiving a push message from the sponsor server to update the obligatory distribution rule object.

49, The computing device of claim 46, wherein the process further comprises receiving a push message from another node of an electronic transfer system that the computing device is part, of to update the obligatory distribution rule object.

50. The computing device of claim 46, wherein the process further comprises: when authentication of the obligatory distribution rule object fails, retrieving an updated instance of the obligatory distribution mle object from the sponsor server;

verifying authenticity and data integrity of the updated instance; and

caching the updated instance in the local cache.

51. The computing device of claim 50, wherein the process further comprises propagating the updated instance to at least another node in a network of computer nodes that the computing device is part of; wherein the updated instance includes a certificate signature generated with a private cryptographic key known only to an operator of the sponsor server.

52. The computing device of claim 51 , wherein the updated instance includes at least two certificate signatures generated with different private cryptographic keys.

53. The computing device of claim 52, wherein authenticating the obligatory distribution rule object includes performing a bifurcated authentication with the at least two certificate signatures.

54. The computing d evice of claim 50, wherein a previous instance of the obligatory distribution rule object includes a first certificate signature generated by a first private key that indicates that the previous instance is generated from the sponsor server; and wherein the updated instance of the obligatory distribution mle object includes a second certificate signature generated by a second private key corresponding to the first certificate signature that indicates that the previous instance is to be replaced by the updated instance.