PEER-TO-PEER EXCHANGE PLATFORM

REFERENCE TO RELATED APPLICATION

[0001] This application claims the benefit of U.S. Provisional Application No.

62/446,275 filed January 13, 2017, whose disclosure is hereby incorporated by reference in its entirety into the present disclosure.

FIELD OF INVENTION

[0002] The present invention is related to a peer-to-peer exchange platform, and more specifically, to a peer-to-peer platform enabling people and objects to exchange value instantly and securely.

BACKGROUND

[0003] People and communities are hindered with a large number of unlocked transactions and exchange potential. There are many reasons that these transactions remain unlocked or the potential not realized. At least one reason is the low accessibility for most transactions requires physical networks, physical assets, or intermediaries that can be trusted. There are delays associated with transactions including delays ranging from minutes to days for wire-transfer, SWIFT, card payments and Bitcoin. Present potential transactions suffer from a lack of sophistication with no rules built-in, and often specific conditions are executed by third parties. In addition, these potential transactions are hindered by proprietary or non-inclusive systems and high costs, as well as large risks including more than $11 billion in fraud and chargebacks in a year, accounting for five percent of merchant revenues. With the number of transactions growing by ten percent a year, a need exists to unlock the transactions and exchange potential by adding sophistication, reducing risk, increasing accessibility while minimizing cost, delays and risk.

SUMMARY

[0004] The present peer-to-peer exchange platform is designed to unlock transactions and exchange potential by providing affordable access to exchanges that occur in real-time using secure blockchain security. The present exchange platform provides programmable smart contracts with built-in rules over the internet in a peer-to- peer configuration. The exchange platform provides added sophistication, reduced risk, and increased accessibility while minimizing cost, delays and risk.

[0005] The peer-to-peer exchange includes system and method for providing peer- to-peer exchanges for enabling transaction between parties. The system and method include digitizing assets into the exchange, wherein the assets in the exchange are tracked utilizing a blockchain registry to enable validity, uniqueness, authentication and immutability the digitized assets, performing a transaction for at least one of the digitized assets, the transaction between a first party of the parties and a second party of the parties, the first party currently owning the at least one of the digitized assets based on the blockchain registry, wherein a set of rules governing the transaction are determined between the first party and the second party with a trust authority, and wherein the second party becomes the owner of the at least one of the digitized assets, and transferring the transacted at least one of the digital assets to a physical asset for the second party.

[0006] The system and method further include a plurality of digital custodians, each of the digital custodians capable of transitioning assets between legacy assets and digital assets, the digital assets being used to transact within the system, at least one trust authority capable of operating with the at least a first party and a second party in the transaction to define the transaction terms, verify the digital assets involved, wherein the trust authority utilizes a blockchain registry to enable validity, uniqueness, authentication and immutability of transactions and the digitized assets, and at least one information hub capable of providing access and communication between the at least first party and second party, the digital custodians, and the at least one trust authority, wherein the at least first party provides a signed digital contract for the digitized assets, the second party verifies the contract and signature, signs the contract allowing the trust authority to verify the transaction and transfer the digital assets in the blockchain registry.

BRIEF DESCRIPTION OF THE DRAWINGS

[0007] A more detailed understanding may be had from the following description, given by way of example in conjunction with the accompanying drawings wherein:

[0008] Figure 1 illustrates a system of the peer-to-peer exchange platform;

[0009] Figure 2 illustrates a method performed with the system of the peer-to-peer exchange platform of Figure 1; [0010] Figure 3 illustrates the interactions of the entities in the peer-to-peer exchange platform of Figure 1 for the example exchange of one or more assets using one trust authority;

[0011] Figure 4 illustrates a method of the digitize-in component of Figure 3;

[0012] Figure 5 illustrates a method of the digitize-out component of Figure 3;

[0013] Figure 6 illustrates a method of the transaction component of Figure 3;

[0014] Figure 7 illustrates the interactions of the entities in the peer-to-peer exchange platform of Figure 1 for the example exchange of one or more assets using two or more trust authorities;

[0015] Figure 8 illustrates a method of the transaction component of Figure 7;

[0016] Figure 9 A illustrates the interactions of the entities in the peer-to-peer exchange platform of Figure 1 for the example exchange of two or more assets using two or more trust authorities;

[0017] Figure 9B illustrates the interactions of the entities in the peer-to-peer exchange platform of Figure 1 for another example exchange of two or more assets using two or more trust authorities;

[0018] Figure 10 illustrates the interactions of the entities in the peer-to-peer exchange platform of Figure 1 for the example identity enrollment using one trust authority;

[0019] Figure 11 illustrates the interactions of the entities in the peer-to-peer exchange platform of Figure 1 for the example identity check using one trust authority;

[0020] Figure 12 illustrates a software stack of the system of Figure 1;

[0021] Figure 13 A illustrates a method for performing a digitization in of a physical asset, or some other right, to a digital assets with respect to the software stack of Figure 12;

[0022] Figure 13B illustrates a diagram of the signaling that occurs during digitization in of Figure 13 A;

[0023] Figure 14A illustrates a method for performing a digitization out of a digital asset, or some other right, to a physical asset with respect to the software stack of Figure 12;

[0024] Figure 14B illustrates a diagram of the signaling that occurs during the digitization out of Figure 14 A;

[0025] Figure 15A illustrates a method for performing the transaction component with respect to the software stack of Figure 12; [0026] Figure 15B illustrates a diagram of the signaling that occurs during the transaction component of Figure 15 A;

[0027] Figure 16 illustrates the parties, obligations/assets and events that may occur within the peer-to-peer exchange platform of Figure 1;

[0028] Figure 17 illustrates a user interface of the present application;

[0029] Figure 18 illustrates the business services of the present application;

[0030] Figure 19 illustrates a contacts menu of the present application;

[0031] Figure 20 illustrates a send money function of the present application;

[0032] Figure 21 illustrates a request money function of the present application; and

[0033] Figure 22 illustrates a QR code screen that can be delivered to request/receive funds.

DETAILED DESCRIPTION

[0034] The present peer-to-peer exchange platform enables individuals and objects to exchange value instantly and securely as will be described herein. The peer-to-peer exchange platform includes a seamless user experience built on applications enabling use cases affordably and driving loyalty. The platform utilizes trusted institutions including legal authorities enabling innovative business models and providing critical mass and network. The platform provides for digitization of assets ranging from money to identities, documents, and other commodities, more value through contracts ensuring certainty instantaneity, cost-efficiency, and intelligence as will be described in more detail herein.

[0035] The peer-to-peer exchange includes systems and methods for providing peer-to-peer exchanges for enabling transaction between parties. The systems and methods include digitizing assets into the exchange, wherein the assets in the exchange are tracked utilizing a blockchain registry to enable validity, uniqueness, authentication and immutability the digitized assets, performing a transaction for at least one of the digitized assets, the transaction between a first party of the parties and a second party of the parties, the first party currently owning the at least one of the digitized assets based on the blockchain registry, wherein a set of rules governing the transaction are determined between the first party and the second party with a trust authority, and wherein the second party becomes the owner of the at least one of the digitized assets, and transferring the transacted at least one of the digital assets to a physical asset for the second party. [0036] The systems and methods further include a plurality of digital custodians, each of the digital custodians capable of transitioning assets between legacy assets and digital assets, the digital assets being used to transact within the system, at least one trust authority capable of operating with the at least a first party and a second party in the transaction to define the transaction terms, verify the digital assets involved, wherein the trust authority utilizes a blockchain registry to enable validity, uniqueness, authentication and immutability of transactions and the digitized assets, and at least one information hub capable of providing access and communication between the at least first party and second party, the digital custodians, and the at least one trust authority, wherein the at least first party provides a signed digital contract for the digitized assets, the second party verifies the contract and signature, signs the contract allowing the trust authority to verify the transaction and transfer the digital assets in the blockchain registry.

[0037] The systems and methods included herein operate using blockchain technology. Blockchain technology is a distributed database that maintains a continuously-growing list of ordered records called blocks. Each block contains a timestamp and a link to a previous block. By design, blockchains are inherently resistant to modification of the data; once recorded, the data in a block cannot be altered retroactively.

[0038] Blockchains are secure by design, and are an example of a distributed computing system with high byzantine fault tolerance. Decentralized consensus can therefore be achieved with a blockchain. Through the use of the peer-to-peer network and a distributed timestamping server, a blockchain database is managed autonomously.

[0039] For example, assets are in a digital form and are represented by a digital document, with certified authenticity and unicity using cryptographic hashes and signatures. The transfer of assets between parties is performed through transaction scripts that determine the flow of the transaction, how the parties cooperate in order to execute the transaction, and how the transaction is confirmed and recorded. One or more trusted parties have a special authority to validate and approve transactions in exchange of remuneration. The validation of a new transaction is based on all the previous transactions of the parties involved in the transaction, and a new transaction may be valid only if all previous transactions are valid.

[0040] The assets to the transaction are mined, (i.e., converted from a physical to a digital form), based on special defined events that are part of the consensus of the system. The data providing the proof of the transactions is stored in multiple locations, and is available to the relevant parties. The functioning of the system is based on the consent and the agreement of all the parties involved in the system according to a consensus protocol that determines how the system work. Parties wanting to be part of the system must agree to abide by the protocol. Transactions and exchanges not abiding by the protocol are rejected. Parties not abiding by the protocol are de facto not part of the system. These features of assets, transaction script, mining, distributed data, and consensus highlight the use of the blockchain technology as will become more evident in the attached description.

[0041] For example, and as will be described in more detail below, the transaction script may be implicit or explicit, and implemented by the parties and the trust authorities involved in the business transactions. The outline of the transaction script may be defined in a contracts module or terms module. For example, a terms module may specify for trust authority X to witness and validate a given type of business transaction Y by taking a commission or fee of Z.

[0042] For further example, and as will be described in more detail below, the data proving the business transactions is stored in a distributed fashion with copies maintained in several locations, that include and are not limited to, local storage of party A, cloud storage of party A, storage of trust authority, backup of trust authority, local storage of party B, cloud storage of party B.

[0043] Figure 1 illustrates a system 100 of a peer-to-peer exchange platform.

System 100 includes a plurality of parties to a transaction(s), depicted for ease of understanding as party A 20 and party B 21, at least one custodian 60, at least one digital custodian 61, an information hub 41 and at least one trust authority 40. System 100 allows one or more parties 20, 21 to make a transaction under transaction rules they establish with one or more other parties 21, 20 or entities, or some combination thereof, using a personal device such a smartphone or a computer.

[0044] The parties involved, such as party A 20 and party B 21, may use a computing device, such as a smartphone, computer, or tablet to interact within system 100. The parties are referred to herein knowing that the party would require some device in order to interact with system 100. This device is assumed and for ease of understanding is not included generally in the description herein in order to simplify the description. Multiple parties are contemplated. As described herein, two parties may be involved. While two parties are described, any number of parties may be involved in a transaction and the two-party description may be extrapolated for any additional parties. Parties may be remotely from one another and may be remotely located from other parts of system 100.

[0045] The device of a given party may connect using a wireless or wired connection, and may operate using software stored and run on the device, remotely, or a combination thereof. Generally, the device includes a processor, memory, and input/output controllers to perform the communications described herein.

[0046] The device can include, for example, a computer, a gaming device, a handheld device, a set-top box, a television, a mobile phone, or a tablet computer. The device includes a processor, a memory, a storage, one or more input devices, and one or more output devices. The device can also optionally include an input driver and an output driver. It is understood that the device can include additional components not specifically described.

[0047] In various alternatives, the processor includes a central processing unit

(CPU), a graphics processing unit (GPU), a CPU and GPU located on the same die, or one or more processor cores, wherein each processor core can be a CPU or a GPU. In various alternatives, the memory is be located on the same die as the processor, or is located separately from the processor. The memory includes a volatile or non-volatile memory, for example, random access memory (RAM), dynamic RAM, or a cache.

[0048] The storage includes a fixed or removable storage, for example, a hard disk drive, a solid state drive, an optical disk, or a flash drive. The input devices include, without limitation, a keyboard, a keypad, a touchscreen, a touchpad, a detector, a microphone, an accelerometer, a gyroscope, a biometric scanner, or a network connection (e.g., a wireless local area network card for transmission and/or reception of wireless IEEE 802 signals). The output devices include, without limitation, a display, a speaker, a printer, a haptic feedback device, one or more lights, an antenna, or a network connection (e.g., a wireless local area network card for transmission and/or reception of wireless IEEE 802 signals).

[0049] The input driver communicates with the processor and the input devices, and permits the processor to receive input from the input devices. The output driver communicates with the processor and the output devices, and permits the processor to send output to the output devices.

[0050] The software and application aspects of these devices are described hereinafter with respect to at least Figure 12. This discussion also evidences the connectivity and tracking functions associated with each device. [0051] Custodian 60 may be a legacy system and may operate using physical assets separate from the digital assets. A legacy system may be a system that operates in the real-world to convert assets into accounts, such as a bank, for example. In the case of a bank, a party may appear at the teller seeking to deposit a certain amount of cash. That cash is collected by the bank and digitally represented with the account of the party.

[0052] Custodian 60 may interact with digital custodian 61. Digital custodian 61 may take the form of a computer, including the hardware described with respect to the devices above. Digital custodian 61 is generally responsible for monitoring digital assets within system 100 and providing the blockchain tracking of the assets. Digital custodian 61 may communicate with the parties' devices and the custodian 60. The software and application aspects of the digital custodian 61 are described hereinafter with respect to at least Figure 12, which sets forth the connectivity and tracking functions associated with the digital custodian 61.

[0053] Information hub 41 may include communication, router and server functionality, allowing connection with the parties and providing storage and notifications methods as will be described below with respect to at least Figure 12.

[0054] Trust authority 40 may take the form of a computer, including the hardware described with respect to the devices above. Trust authority 40 is generally responsible for tracking the business transactions, validating and authorizing the transactions occurring within the system 100 allowing of the blockchain tracking of the assets. Trust authority 40 may communicate with the parties' devices. The software and application aspects of the trust authority 40 are described hereinafter with respect to at least Figure 12, which sets forth the connectivity and tracking functions associated with the trust authority 40.

[0055] The digitize-in portion 200 of system 100 includes custodian 60 and digital custodian 61 for interaction with party A 20. Party A 20 is used for example only in describing the digitize-in portion 200. Party A 20 communicates with custodian 60 through a deposit channel 1-1 using the internet, a bank, or some other process that links a physical asset, or some other right, to party A 20. For example, party A 20 may use a personal device such as a smartphone to transfer funds or some other right to the digital representation of party A 20.

[0056] By further example, if the deposit is for a physical asset, party A 20 may present physical currency (or some other physical asset) in some amount to a bank or other institution for deposit and conversion into digital currency. Deposit of the physical asset is received by custodian 60, and converted into digital currency by the digital custodian 61 of the system 100. Communication of the deposit of a physical asset with custodian 60 is accomplished by the physical liability channel 1-2 between custodian 60 and digital custodian 61 and communication of a digital asset between digital custodian 61 and party A 20 is accomplished by the digital asset channel 1-3.

[0057] The digital assets are generated by digital custodian 61 and "mined" at the time the digital assets are created (digitize-in) with a deposit asset event. The description of the asset type (e.g., USD, Gold, VIP Ticket for Event X, etc.) is created as a digital document, which may be, but is not limited to, a JSON file with a digital signature of digital custodian 61 that generated the digital form of the asset.

[0058] JSON, short for JavaScript Object Notation, is an open-standard format that uses human-readable text to transmit data objects consisting of attribute-value pairs. JSON is commonly used as a data format for asynchronous browser/server communication, and may be used instead of XML which is used by Ajax. JSON is a language-independent data format derived from JavaScript.

[0059] Digitize-out portion 300 of system 100 includes custodian 60 process and digital custodian 61 for interaction with a user party B 21. Party B 21 is used as an example only. Party B 21 communicates with custodian 60 through a withdrawal channel 2-1 using the internet, a bank, or some other process or entity that links the digital asset, or some other right, to party B 21. For example, party B 21 may use a personal device like a smartphone to transfer funds or some other right from digital representation to real world party B 21.

[0060] By further example, if the withdrawal transaction is for a digital asset to a physical asset, party B 21 may present its digital asset to the digital custodian 61, which may be a bank, a digital bank, or exchange that maintains digital assets. Digital custodian 61 may reconcile the digital transaction and authorize custodian 60 to release the physical asset or right to party B 21.

[0061] Communication between party B 21 and digital custodian 61 may be accomplished through a digital liability channel 2-3. Communication of the withdrawal of a physical asset or right is accomplished by a withdrawal asset channel 2-2.

[0062] Accordingly, the process for converting a physical asset or right to a digital asset is accomplished between custodian 60 and digital custodian 61, through the physical liability channel 1-2. The process for converting a digital asset to a physical asset or right is accomplished between digital custodian 61 and custodian 60 through the digital liability channel 2-2. It should be understood by those of skill in the art that this process may reversed. Accordingly, the reverse process with digitize-out becoming digitize-in and digitize-in becoming digitize-out may occur.

[0063] Transaction 400 includes the digital transactions between parties in by system 100. A transaction is the digital representation of an exchange of a physical asset like currency, or a legal right like an inheritance in a will, under transaction rules established with one or more parties 20, 21 or entities, or some combination thereof, using a personal device such a smartphone or a computer.

[0064] Transaction 400 includes one or more of any combination of an information hub 41, a trust authority 40, and at least one third party. Information hub 41 informs a party, such as party B 21, that party A 20 desires to engage in a transaction, such as but not limited to party A's 20 offer. If party B 21 accepts the transaction, party B 21 may sign the offered transaction and send the signed offer and signed offered transaction to trust authority 40. Trust authority 40 may witness and validate the transaction. If validated, the transaction is signed by trust authority 40 and the validated, signed transaction may then be sent to party A 20, and a notice may be sent to party B 21, and any third party involved as determined by the rules of the transaction. The consensus happens by each party or trust authority expressing its agreement with the transaction by adding its digital (cryptographic) signature to the digital transaction document.

[0065] For example, a title right in real property is deposited into custodian 60, digitized by digital custodian 61 and registered with party A 20. Party A 20 offers the property to party B 21. Once a price for the property is settled upon with party B 21 and the terms of the transaction are agreed to, party B 21 may accept the transaction. Upon acceptance, party A 20 delivers the digital title to party B 21, and party B 21 delivers the settled price to party A 20.

[0066] By further example, the delivery of the settlement price by party B 21 to party A 20 may be within system 100 or outside the system as determined by the rules established by the parties independently of system 100 during the transaction 400.

[0067] By further example, party B 21 may transfer its title right to a third party that is a member of system 100 under a transaction rule or without a transaction rule, even if there are rules defined by the system 100 itself. System 100 may have rules established. For example, party B 21 may own a digital asset or title claiming property in real estate, and party B 21 transfers or is seeking to transfer the digital title to party B 22 without other strings attached, such as for free as a wedding or birthday gift, for example, using the mechanism of transaction 400. Alternatively, party B 21 transfers the digital title to party B 22 under the rule that party B 22 reaches age 18.

[0068] Any party in possession of a digital asset may convert that asset into a physical asset or right at any time and withdraw it at any time through digitize-in 200/digitize out 300. System 100 may include, as depicted in Figure 1, an interconnection of the elements of Figure 1 for the process of digitizing a physical asset or some other right into a digital asset (digitize-in 200), the process of digitizing a digital asset from a digital asset (digitize-out 300), the process of the transaction for transacting assets within the system (transaction 400). That is, system 100 includes a digitize-in portion 200 of system 100 for receiving and digitizing a physical asset or some other right into the system, a digitize-out portion 300 of system 100 for redeeming a digitized physical asset, or some other right to real world assets, and a transaction component 400 that executes the transaction according to rules established by one or more, or any combination of, the parties to the transaction, the at least one trust authority 40 or a third party (not shown in Figure 1).

[0069] Figure 2 illustrates a method 150 performed with the system 100 of the peer-to-peer exchange platform of Figure 1. Method 150 includes digitizing the assets into the system 100 via the custodian and digital custodian via a digitize-in process at step 152. A party communicates with custodian 60 through a deposit channel 1-1 using the internet, a bank, or some other process that links a physical asset, or some other right, to the party. The party may present physical currency in some amount to a bank for deposit and conversion into digital currency. Deposit of the physical asset is received by custodian 60, and converted into digital currency by the digital custodian 61 component of the system 100. Communication of the receipt of a physical asset between the custodian 60 and digital custodian 61 is accomplished by the physical liability channel 1-2 and communication of a digital asset between the digital custodian 61 and the party is accomplished by the digital asset channel 1-3.

[0070] At step 154, method 150 performs a transaction between at least party A and party B by establishing rules of the transaction with a trust authority. The transaction includes one or more in any combination of an information hub 41, a trust authority 40, and at least one third party. Information hub 41 informs a party, that another party desires to engage in a transaction, such as but not limited to an offer. If the party accepts the offer as a transaction, the another party may sign the offered transaction and send the signed offer and signed offered transaction to trust authority 40. Trust authority 40 may witness and validate the transaction. If validated, the transaction is signed by trust authority 40 and the validated, signed transaction may then be sent to the another party, and a notice may be sent to the party, and any third party there may be as determined by the rules of the transaction.

[0071] At step 156, method 150 performs a transfer of assets from the digital system via the digital custodian 61 and the custodian 60. A party communicates with custodian 60 through a withdrawal channel 2-1 using the internet, a bank, or some other process that links the digital asset, or some other right, to the party. For example, party B 21 may use a personal device like a smartphone to transfer funds or some other right to party B 21. Once initiated custodian 60 communicates across channel 2-2 with digital custodian 61 to identify assets being transferred. Once the party communicates the corresponding digital assets to digital custodian 61, digital custodian 61 destroys digital assets and communicates with custodian 60 to release physical asset.

[0072] Figure 3 illustrates the interactions of the entities in the system 100 of the peer-to-peer exchange platform of Figure 1 for the example exchange of one or more assets using one trust authority. Again, as described above with respect to Figure 1, there is digitize-in portion 200 of system 100 for receiving and digitizing a physical asset or some other right into system 100, digitize-out portion 300 of system 100 for redeeming a digitized physical asset, or some other right, and transaction 400 component that executes the transaction according to rules established by one or more, or any combination of, the parties to the transaction, a trust authority 40 or any third party 50.

[0073] As described with respect to Figure 1, digitize-in portion 200 of system 100 includes custodian 60 and digital custodian 61 for interaction with a user, such as party A 20. Referring now also to Figure 4 there is illustrated a method 250 of the digitize-in component 200 of Figure 3.

[0074] Party A 20 brings the assets that are to be converted into digital assets to the custodian 60 via a physical or electronic channel. Party A 20 communicates with custodian 60 through a deposit channel 1-1 using the internet, a bank, or some other process that links a physical asset, or some other right, to party A 20 at step 252 of method 250. This may include, in the case of a physical asset, for example party A 20 presenting a physical currency amount to a bank for deposit and conversion into digital currency. Deposit of the physical asset is received by custodian 60 ultimately to be converted into digital currency by digital custodian 61. [0075] The custodian 60 applies a procedure to handle the asset and gives back an acknowledgment (physical receipt or return code in case of another system) to party A 20 confirming the reception of assets. The procedure to handle assets is designed according to specifications of the asset (type, nature, size, value, possible operations etc.).

[0076] For example, an event organizer creates a defined number of entry tickets to an upcoming event. The specifications of the tickets are the number of seats, the validity, the name of the event, the venue, the date, the seat number, the price and the return conditions. The organizer writes these specifications in a confirmation document that is sent (physically or electronically) to the custodian 60 for digitizing in the specified tickets.

[0077] Communication of the deposit of a physical asset with custodian 60 is provided to digital custodian 61 via the physical liability channel 1-2 at step 254. Custodian 60 notifies party A 20 in a confirmation document that assets have been received. Custodian 60 sends an electronic version of the specifications, such as the specifications of the tickets described above, and the confirmation documents through a pre-established communication channel to party A 20 for confirmation. Digital custodian 61 sends a notification to custodian 60 acknowledging the receipt of the documents. Digital custodian 61 generates the specific digital assets, such as the specified tickets in our example with the associated attributes in a digital cryptographic format.

[0078] Communication of a digital asset to the party, party A 20 from the digital custodian 61 is accomplished across the digital asset channel 1-3. After digital custodian 61 generates the digital asset, such as the digital tickets, with the associated attribute in digital cryptographic format, digital custodian 61 sends the digital assets to party A 20. Party A 20 notifies digital custodian 61 that the digital asset is received. Party A 20 may then transact the asset using digital contracts with other parties. Party A 20 may receive against each contract the agreed amount of other assets (for example, money in a form of fiat currency) in the same contract or outside the system 100.

[0079] As described with respect to Figure 1, digitize-out portion 300 of system

100 includes custodian 60 and digital custodian 61 for interaction with a user, such as party B 21. Referring now also to Figure 5 there is illustrated a method 350 of digitize-out component of Figure 3. Party B 21 communicates with custodian 60 through a withdrawal channel 2-1 at step 352 using the internet, a bank, or some other process that links the digital asset, or some other right, to party B 21. Party A 20 initiates an asset withdrawal by initiating a contract with the amount and details of the asset. A signed digital contract is sent to digital custodian 61 by party B 21.

[0080] Party B 21 may present its digital asset to digital custodian 61 for conversion to a physical asset via the digital asset channel 2-2 at step 354. The details of the digital contract, such as a JSON contract described herein, are sent by digital custodian 61 to custodian 60. Once the custodian 60 acknowledges reception of the information of the digital contract and the authorization to deliver assets, the corresponding digital units of the asset that is withdrawn are digitally destroyed by digital custodian 61.

[0081] Digital custodian 61 reconciles the digital transaction and authorizes custodian 60 to release the physical asset or right to party B 21 through the digital liability 2-3 channel at step 356.

[0082] Accordingly, the process for converting a physical asset or right is accomplished via method 250 within digitize - in 200 of system 100 and the process for converting a digital asset to a physical asset or right is accomplished via method 350 within digitize-out 300 of system 100.

[0083] As described with respect to Figure 1, transaction 400 describes the digital transaction within system 100. Referring now also to Figure 6 there is illustrated a method 450 of the transaction of Figure 3. A first party, party A 20 provides or makes an offer for a transaction. This offer is delivered to an information hub 41 in preparation for sending the offer to the second party, party B 21, on a first offer channel 3-1 at step 452.

[0084] Party A 20 creates a digital contract, such as a digital document like a

JSON file, for example. Party A 20 may pre-sign his terms or his offer and parts of the JSON file may include the cryptographic signature of party A 20 on all or some of the clauses of the contract, for example JSON described above. Party A 20 posts the digital contract to the information hub 41.

[0085] Information hub 41 informs the second party, party B 21, that party A 20 has made an offer for a transaction using the second offer channel 3-2 at step 454. Information hub 41 receives a digital file (contract from party A 20 to party B 21). Information hub 41 puts the file in a buffer and checks in the database of information hub 41 to determine the address at which party B 21 is reachable (e.g. IP address, GCM token, etc.). Information hub 41 notifies party B 21 by sending a communication to party B's 21 address using a relevant communication method. When party B 21 receives the notification, party B 21 opens a secure connection to information hub 41 (e.g., HTTPS connection) and retrieves the file waiting in information hub 41 buffer. [0086] If party B 21 accepts the transaction, party B 21 digitally signs the offered transaction and sends the agreed to transaction to the trust authority 40 for the trust authority 40 to witness and validate the transaction using the validation channel 3-3 at step 456. Party B 21 checks the document it retrieved from information hub 41, checks if the signature of party A 20, and/or of other parties that already signed the document, party B 21 checks the terms and the clauses of the contract, and adds a signature confirming the clauses and that party B 21 accepted.

[0087] A digital signature, electronic signature, or e-signature, refers to data in electronic form, which is logically associated with other data in electronic form and which is used by the signatory to sign. This type of signature provides the same legal standing as a handwritten signature.

[0088] The new version of the document, including party B's 21 signature, is sent by party B 21 to the next party present in the contract or to trust authority 40 through information hub 41, or through a direct connection, if party B 21 is the last party to sign the contract before handing over to the witnesses.

[0089] If validated by the trust authority 40, the transaction is signed by the trust authority 40 and delivered to party A 20 via the receipt channel 3-4 at step 458. The rules defined in the contract, the consensus module, and the terms module (described herein with respect to Figure 12) may govern the validation. For example, for a money transfer, the validation may include determining if party A 20 signed all of the required clauses in the contract and is the signature used valid, determining if party B 21 signed all of the required clauses in the contract and is the signature used valid, determining if party A 20 actually owned the money that is being transferred (this may be performed using the single-entry books of party A 20 using the copy stored as described with respect to Figure 12 herein below, but is basically the sum of all previous incoming and outgoing transfers of party A 20 for that particular asset type, which in this case is dollars), determining if the commission or fee for the transactions has been properly included, determining if other conditions for validation are in place such as is party A 20 allowed to transact for that type of asset, and determining if there is any limit to the amount of transfer. Notice may be provided to party B 21 from trust authority 40. Notice may also be provided to any third party 50.

[0090] Trust authority 40 adds its signature to the document and sends copies of the new version of the document, which may be the final version and may be considered as executed if it has been signed by all the parties, to party A 20 and party B 21 by sending separately each copy to the party through information hub 41.

[0091] Figure 7 illustrates the interactions of the entities in the peer-to-peer exchange platform of Figure 1 for the example exchange of one or more assets using two or more trust authorities. Again, as described above with respect to Figure 1, there is digitize-in portion 200 of system 100 for receiving and digitizing a physical asset or some other right, a digitize-out portion 300 of system 100 for redeeming a digitized physical asset, or some other right, and transaction 400 component that executes the transaction according to rules established by one or more, or any combination of, the parties to the transaction, a trust authority 40 or any third party 50.

[0092] As described with respect to Figure 1, digitize-in portion 200 of system 100 includes custodian 60 and digital custodian 61 for interaction with a user, such as party A 20 in conjunction with method 250 as illustrated in Figure 4. The digitize-in portion 200 of system 100 is similar to those described even with the additional trust authorities 40, 41 depicted in Figure 7.

[0093] As described with respect to Figure 1, digitize-out portion 300 of system

100 includes custodian 60 and digital custodian 61 for interaction with a user, such as party B 21 in conjunction with method 350 as illustrated in Figure 5. The digitize-out portion 300 of system 100 is similar to those described even with the additional trust authorities 40, 41 depicted in Figure 7.

[0094] As described with respect to Figures 1 and 6, transaction 400 describes the digital transaction within system 100 in conjunction with method 450-1 of Figure 8 of the transaction of Figure 7. A first party, party A 20, provides or makes an offer for a transaction. This offer is delivered to an information hub 41 in preparation for sending the offer to the second party on a first offer channel 3-1 at step 452. Information hub 41 informs a second party, party B 21, that party A 20 has made an offer for a transaction via the second offer channel 3-2 at step 454. If party B 21 accepts the transaction, party B 21 signs the offered transaction and sends the agreed to transaction to the trust authority 40. In the method 450-1 with two trust authorities 40, 41, this communication may occur with trust authority 2 41, to witness and validate the transaction via the validation channel 3-3 at step 456.

[0095] The trust authority 2 41 communicates with trust authority 1 40 to further validate the transaction via the second validation channel 3-32. The flow of moving the contract is enriched at each step by additional information and additional signatures (until signed by all parties and authorities assuming the contract is accepted by each party before signing) is the same in each step as the flow described above with respect to Figure 3.

[0096] Some types of business transactions may require the involvement and signatures of several trust authorities, such as and exemplified by trust authority 2 41 and trust authority 1 40. Generally, the number of trust authorities may be defined as n of m. To be valid, certain business transactions may require approval from exactly n given authorities out of a given set of m authorities or at least n or more authorities out of a given set of m authorities or any combination thereof where m is greater than n.

[0097] By way of non-limiting examples, for a money transfer having a value less than $100, there may be a requirement necessitating a validation by one of bank A or bank B. For a money transfer having a value of between $100 and $200, there may be a requirement necessitating a validation by both bank C and bank D. For a money transfer having a value over $1000, there may be a requirement necessitating a validation from at least any 3 banks out of a set of 7 known banks.

[0098] For the exchange of a house versus money (the exchange of the house and the money are stipulated in the same digital contract), there may be a requirement necessitating a validation from both a real estate authority and a bank. For the purchase of a ticket for an event Z restricted to people over 18 years in exchange for money (all terms are stipulated in the same digital contract), there may be a requirement necessitating a validation of Z authority, bank B, and the Ministry of Interior (or the authority in charge of the identification or birth certificates, in order to validate the over 18 years condition).

[0099] If validated by the trust authorities 40, 41 the transaction is signed by the trust authority 1 40 and trust authority 2 41 and delivered to party A 20 via the receipt channel 3-4 at step 458. Although not specifically shown in the figure, notice may be provided to party B 21 from trust authority 40. Notice may also be provided to any third party 50 as described herein.

[0100] Figure 9 A illustrates the interactions of the entities in the system 100 of peer-to-peer exchange platform of Figure 1 for the example exchange of two or more assets using two or more trust authorities. Again, as described above with respect to Figure 1, there is digitize-in portion 200 of system 100 for receiving and digitizing a physical asset or some other right, digitize-out portion 300 of system 100 for redeeming a digitized physical asset, or some other right, and transaction component that executes the transaction according to rules established by one or more, or any combination of, the parties to the transaction, a trust authority 40 or any third party 50. For the present example, when additional assets are involved, the transaction component 400 may remain as described with respect to Figure 7 above.

[0101] As two assets are depicted in Figure 9 A, both residing with party A 20, party A 20 may digitize-in the first asset, asset 1, using digitize-in 200a. Either before, subsequent, or simultaneously with the digitizing-in of asset 1, party A may digitize-in the second asset, asset 2, using digitize-in 200b.

[0102] Once the two assets, asset 1 and asset 2, are in digital form, the transaction component may occur, in this example, transferring the right to asset 1 and asset 2 to party B 21. By way of non-limiting example, party A 20 enters two assets in system 100. In this case say the two assets are an identity and money. Identity transactions are validated by trust authority 40 (Ministry) different from trust authority 40 (Bank) that validates the money transactions. Party A 20 may send a digital contract with a digitized identity and digitized money in the same transaction. Therefore in order to complete the transaction, trust authority 40 (ministry), party A 20, party B21 must sign the identity contract and trust authority (Bank), party A 20, party B 21 must sign the money contract. If performed via a single contract party A 20, party B21, trust authority 40 (ministry), trust authority 40 (Bank) must sign the contract.

[0103] Once party B 21 receives asset 1 and asset 2, party B may wish to digitize- out these assets. Assets 1 may be digitized out using digitize-out 300a. Either before, subsequent, or simultaneously with the digitizing-out of asset 1, party B may digitize-out the second asset, asset 2, using digitize-out 300b.

[0104] Figure 9B illustrates the interactions of the entities in the peer-to-peer exchange platform of Figure 1 for another example exchange of two or more assets using two or more trust authorities. Again, as described above with respect to Figure 1, there is digitize-in portion 200 of system 100 for receiving and digitizing a physical asset or some other right, digitize-out portion 300 of system 100 for redeeming a digitized physical asset, or some other right, and transaction component that executes the transaction according to rules established by one or more, or any combination of, the parties to the transaction, a trust authority 40 or any third party 50. For the present example when additional assets are involved, the transaction component 400 may remain as described with respect to Figure 7 above.

[0105] As two assets are depicted in Figure 9B, one residing with each of party A

20 and party B 21, party A 20 may digitize-in the first asset, asset 1, using digitize-in 200a. Either before, subsequent, or simultaneously with the digitizing-in of asset 1, party B may digitize-in the second asset, asset 2, using digitize-in 200b.

[0106] Once the two assets, asset 1 and asset 2, are in digital form, the transaction component may occur, in this example, transferring the right to asset 1 to party B 21 and asset 2 to party A 20. By way of non-limiting example only, party A 20 deposits money and party B 21 deposits gold. Money transactions are validated by trust authority A 40 (such as a bank) and gold transactions are validated by trust authority B 40 (such as a gold exchange). Party A 20 and party B 21 transact digital contracts with money and gold. Therefore in order to complete the transaction, trust authority 40 (ministry), party A 20, party B21 must sign the identity contract and trust authority (Bank), party A 20, party B 21 must sign the money contract. If performed via a single contract party A 20, party B21, trust authority 40 (ministry), trust authority 40 (Bank) must sign the contract.

[0107] Once party B 21 receives asset 1 and party A 20 asset 2, party B and party

A may each wish to digitize-out these assets. Asset 1 may be digitized out using digitize- out 300a to party B 21. Either before, subsequent, or simultaneously with the digitizing- out of asset 1, party A may digitize-out the second asset, asset 2, using digitize-out 300b.

[0108] Figure 10 illustrates the interactions of the entities in the peer-to-peer exchange platform of Figure 1 for the example identity enrollment using one trust authority. Again, as described above with respect to Figure 1, there is digitize-in portion 501 of system 500 for receiving and digitizing a physical asset or some other right into system 500, and digitize-out portion 502 of system 500 for redeeming a digitized right. In the identity enrollment example, the asset that is deposited into system 500 is biometric data.

[0109] As described with respect to Figure 1, digitize-in portion 501 of system 500 includes custodian 60 and digital custodian 61 for interaction with a user, such as party A 20. Party A 20 brings the assets that are to be converted into digital assets to the custodian 60 via a physical or electronic channel. Party A 20 communicates with custodian 60 through a deposit channel 1-1 using the internet, a bank, or some other process that links a physical asset, or some other right, to party A 20. This may include, in the case of a physical asset, for example party A 20 presenting biometric information to custodian 60. Biometric information may include any distinctive, measurable characteristics used to label and describe individuals. Biometric information may include, but are not limited to fingerprint, palm veins, face recognition, facial expression recognition, DNA, palm print, hand geometry, iris recognition, retina and odor/scent. The holder 30 may enter biometric information through a standalone application or other mechanism that uses device sensors, effectively party A 20. For example, holder 30 may use a finger print scanner to scan in holder's 30 biometric information of a fingerprint.

[0110] The custodian 60 applies a procedure to handle the received biometric information and provides an acknowledgment (physical receipt or return code in case of another system) to party A 20 confirming the reception of the information.

[0111] Communication of the deposit of the biometric information with custodian

60 is provided to digital custodian 61 via the physical identity channel 1-2. Custodian 60 sends an electronic version of the specifications, such as the specifications of the biometric information described above, and the confirmation documents through a pre-established communication channel to party A 20 for confirmation. Digital custodian 61 sends a notification to custodian 60 acknowledging the receipt of the information. Digital custodian 61 generates the specific digital identity with the associated attributes in a digital cryptographic format.

[0112] Communication of a digital asset to the party, party A 20 from the digital custodian 61 is accomplished across the digital identity channel 1-3. After digital custodian 61 generates the digital identity in digital cryptographic format, digital custodian

61 sends the digital identity to party A 20. Party A 20 notifies digital custodian 61 that the digital identity is received. This allows party A 20 to store identity information on their respective device. Party A 20 may then operate using the digital identity with other parties.

[0113] As described with respect to Figure 1, digitize-out portion 502 of system

500 includes custodian 60 and digital custodian 61 for interaction with a user, such as party B 21. Party B 21 communicates with custodian 60 through a digital identity channel 2-1 using the internet, a bank, or some other process that links the digital identity to party B 21. Party A 20 initiates an identity check by interacting in some way with party B 21. This interaction may include any mechanism where identity needs to be verified.

[0114] Party B 21 may present its digital identity to digital custodian 61 for verification via the digital identity channel 2-2. The details of the digital identity are sent by digital custodian 61 to custodian 60. Digital custodian 61 in conjunction with the custodian 60 verifies the identity by providing a comparison of the biometric information in biometric channel 2-3 with the received biometric information via digitize-in. In this way, it may be determined if the person using the digital identity matches the biologic information to access that identity. [0115] Figure 11 illustrates the interactions of the entities in the peer-to-peer exchange platform of Figure 1 for the example identity check using one trust authority. Again as described with respect to Figure 1, identity check 600 describes the digital transaction within system 100. A first party, party A 20 provides or makes an offer for an identity check. This offer is delivered to an information hub 41 in preparation for sending the offer to the second party, party B 21, on a first offer channel 3-1.

[0116] Party A 20 provides digitized identity information to the information hub

41. Information hub 41 informs the second party, party B 21, that party A 20 has provided the identity information using the second offer channel 3-2. Information hub 41 receives a digital file (contract from party A 20 to party B 21). Information hub 41 puts the file in a buffer and checks in the database of information hub 41 to determine the address at which party B 21 is reachable (e.g. IP address, GCM token, etc.). Information hub 41 notifies party B 21 by sending a communication to party B's 21 address using a relevant communication method. When party B 21 receives the notification, party B 21 opens a secure connection to information hub 41 (e.g., HTTPS connection) and retrieves the file waiting in information hub 41 buffer.

[0117] If party B 21 accepts the identity, i.e., the information is valid, a digital identity contract across channel 3-1 may be initiated. This digital identity contract may be sent to party B 21 across channel 3-2 via information hub 41. Party B 21 digitally sends the signed contract to the trust authority 40 for the trust authority 40 to witness and validate the transaction using the validation channel 3-3. The trust authority 40 checks compliance, i.e., black lists, and sends receipt to party A 20 and party B 21 across channel 3-4. The rules defined in the identification, the consensus module, and the terms module (described herein with respect to Figure 12) may govern the validation. Notice may also be provided to any third party 50.

[0118] Trust authority 40 adds its signature to the document and sends copies of the new version of the document, which may be the final version and may be considered as executed if it has been signed by all the parties, to party A 20 and party B 21 by sending separately each copy to the party through information hub 41.

[0119] Figure 12 illustrates a software stack of system 100. Party A 20 is a peer involved in a business transaction. A party may be a sender, a receiver, a beneficiary, a rights holder, a voter, or the like. One or multiple parties may be involved in a business transaction. The software stack of party A 20 is described. This stack represents that used by any party to system 100 including party B 21, party 21A, and party 21B, for example. [0120] The application 20-10 has a user interface (UI) 20-11, an applications programming interface (API) 20-12 and a set of business logic 20-13. Application 20-10 may be implemented by a general purpose computer. The application 20-10 includes, but is not limited to, a mobile application, a server application, a desktop application, a web application, an embedded application (IoT), by way of non-limiting example. The application 20-10 interacts within system 100 through a software development kit (SDK) or wallet 20-20 to enable business transactions to be executed.

[0121] The UI 20-11 displays a set of screens and designs through which a user, such as party A 20, interacts with the application 20-10. Examples of screen shots of the UI 20-11 are included in the figures and description below. The user, again party A 20, may execute actions, input information, and check the information through the UI 20-1 1. The UI 20-11 enables among other things, the user to initiate a business transaction 400, or confirm, amend, or reject a step in the business transaction 400.

[0122] The API 20-12 presents a set of services through which a machine user (not shown) interacts with the application 20-10. The user may execute actions, input information, and check the information through the API 20-12. The API 20-12 enables the user to initiate a business transaction 400, or confirm, amend, or reject a step in the business transaction 400.

[0123] The business logic 20-13 is the logic through which the application handles the events pertaining to the use of system 100 or the business transaction 400. For example, if new funds or other forms of assets (physical or legal rights) are received by party A 20, then the business logic 20-13 updates the balance maintained by party A 20, and to display the balance of party A 20 on the UI 20-11 or through the API 20-12. If the transaction history maintained by the transaction database 40-31 is needed, the business logic 20-13 may load the list of transactions from the LS 20-23, and display the list of transactions on the UI 20-11. The same process may be applied to party B 21.

[0124] The balance for party A 20 is defined by the sum of amounts of all transactions as credits and debits sent or received by party A 20 using single entry accounting. This balance may be listed in the wallet 20-21 and stored in the LS 20-23 of the wallet 20-20.

[0125] Single entry accounting is a single entry system records each accounting transaction with a single entry to the accounting records. The single entry system is centered on the results of a business that are reported in the income statement. The core information tracked in a single entry system is cash disbursements and cash receipts. The primary form of record keeping in a single entry system is the cash book, which is essentially an expanded form of a check register, with columns in which to record the particular sources and uses of cash, and room at the top and bottom of each page in which to show beginning and ending balances. Single entry accounting is a simple form of bookkeeping and accounting in which each financial transaction is a single entry in a journal or transaction log in LS 20-23, 21-23.

[0126] The balance for party B 21 is defined by the sum of amounts of all transactions as credits and debits sent or received by party A 20 also using single entry accounting and is listed in the wallet 21-20 and stored in the LS 21-23 of the wallet component 21-20.

[0127] The balance of system 100 is maintained by the trust authority 40 through the trust authority node 40-21 of the validation component 40-20. All transactions are maintained as using triple entry accounting in the storage 40-31 of the services component 40-30.

[0128] For example, party A 20 sends an asset to party B 21. Under triple entry accounting, the accounts of three entries are used: (1) the credit of party B 21, (2) the debit of party A 20, and (3) the receipt 3-4 of the transaction 400. The receipt 3-4 is a cryptographic signed acknowledgement of the transaction 400 verified by the trust authority node 40-21 according to the terms included in the contracts 20-33, 21-33, and the terms module 40-22. The terms of the contracts 20-33, 21-33 and the terms module 40- 22 are established alone, or in any combination, by party A 20, party B 21 and/or the trust authority 40, or some other third party or group of third parties.

[0129] The application 20-10 includes a wallet 20-20 for managing the transactions and a protocol 20-30 for managing the communication between the device of party A 20 and the trust authority 40 or other parties 21, 21A, 21B that are involved in the transaction.

[0130] The wallet 20-20 includes a wallet component 20-21, a notification module

20-22, and one or more LS 20-23 and/or CB 20-24.

[0131] The wallet 20-20 communicates with the protocol 20-30 to execute business transactions within system 100. The wallet 20-20 may be the container of all business transactions represented in the form of digital contracts. The wallet 20-20 contains the set of business transactions, assets, IDs, or rights, and assigns a status of: confirmed, pending, failed, canceled, or the like. [0132] The wallet component 20-21 uses a pair of public and private keys that represent the identity of the wallet 20-20. The private key of the wallet component 20-21 signs all the business transactions in which party A is involved. The signed transactions represent the list of business transactions initiated or accepted by party A 20. The wallet component 20-21 signs the business transactions through the protocol 20-30.

[0133] Public key cryptography, or asymmetric cryptography, is any cryptographic system that uses pairs of keys: public keys which may be disseminated widely, and private keys which are known only to the owner. This accomplishes two functions: authentication, which is when the public key is used to verify that a holder of the paired private key sent the message, and encryption, whereby only the holder of the paired private key can decrypt the message encrypted with the public key.

[0134] In a public key encryption system, any person can encrypt a message using the public key of the receiver, but such a message can be decrypted only with the receiver's private key. For this to work it must be computationally easy for a user to generate a public and private key-pair to be used for encryption and decryption. The strength of a public key cryptography system relies on the degree of difficulty (computational impracticality) for a properly generated private key to be determined from its corresponding public key. Security then depends only on keeping the private key private, and the public key may be published without compromising security.

[0135] In a public key signature system, a person can combine a message with a private key to create a short digital signature on the message. Anyone with the corresponding public key can combine a message, and put a digital signature on it, and a known public key to verify whether the signature was valid— made by the owner of the corresponding private key. Changing the message, even replacing a single letter, will cause verification to fail: in a secure signature system, it is computationally infeasible for anyone who does not know the private key to deduce it from the public key or from any number of signatures, or to find a valid signature on any message for which a signature has not hitherto been seen. Thus the authenticity of a message can be demonstrated by the signature, provided the owner of the private key keeps the private key secret.

[0136] Notification module 20-22 component is a messaging service which receives information and sends information about business transactions (from and to other parties). The notification module 20-22 communicates with communication 40-10 using an online communication channel 3-1. The notification module 20-22 may receive a notice about a business transaction in which party A 20 is a party. Notification module 20-22 may send a notice to other parties with who party A wants to transact, for example party B 21.

[0137] Local storage (LS) 20-23 of the wallet 20-20 includes a storage module in the device of party A 20. LS 20-23 stores the list of business transactions in which party A 20 is a party. LS 20-23 may store a list of business transactions of which party A 20 is informed but is not necessarily a party. The list of business transactions may be written into or retrieved from the LS 20-23.

[0138] Cloud backup (CB) 20-24 is a remote storage feature that may be a remote server or a storage on a cloud system. The CB 20-24 receives information about the business transactions recorded in LS 20-23. The wallet 20-20 sends data to the CB 20-24 through an online communication channel 3-1. The transaction data saved in CB 20-24 may be used to recover a wallet 20-20 in case the device (and its local storage 20-23) has been lost by party A 20. The recovery process may occur by copying the transaction data from CB 20-24 to the new local storage 20-23 of a new device of party A 20.

[0139] The protocol 20-30 manages the communication between the wallet 20-20 and validation 40-20 of the trust authority 40 through the communication channel 3-1 and communication component 40-10. Wallet 20-20 includes a consensus module 20-31, a cryptographic module 20-32, a contracts module 20-33, a utility module 20-34 and an authentication module 20-35. The protocol 20-30 enables the wallet 20-20 to validate or issue digital contracts that are used in a business transaction in which party A 20 is involved.

[0140] Consensus module 20-31 is a software module that identifies the role party

A is playing in a business transaction and interacts with the validation module 40-20 and ensures that party A 20 is compliant with the rules set in terms module 40-22 for a given business transaction. The consensus module 20-31 also checks that other parties involved in a given business transaction with party A 20 are compliant with the rules of the transaction set in the terms module 40-22, and whether party A 20 should accept the transaction, suggest an amendment, or reject the transaction.

[0141] The cryptographic module 20-32 is a set of cryptographic libraries. The cryptographic module 20-32 enables to generate cryptographic keys, sign clauses in a digital contract pertaining to a business transaction, verify the signature of other parties in the digital contract, and encrypt or decrypt pieces of information. Party A materializes its acceptance or commitment to an agreement in a digital contract by signing it through the cryptographic module 20-32. Cryptographic module 20-32 may operate using public key/private key technology described above, for example.

[0142] The contracts module 20-33 is a software module that reads or creates digital contracts. The digital contracts may be represented in the form of a JSON file or any other format, and includes terms and clauses for each party involved in the business transaction. If party A 20 receives a digital contract through wallet 20-20 from other parties who want to transact with party A 20, then the digital contract is read and parsed by the contracts module 20-33, analyzed and assessed by the consensus module 20-31, accepted and signed by the cryptographic module 20-32, and sent back to the other parties involved in the business transaction by wallet 20-20 notification module 20-22 and communication component 41-10, and stored by wallet 20-20 in LS 20-23 and CB 20-24. The contracts module 20-33 may include a library of predefined templates suitable for use in different types of business transactions and descriptions of how those business transactions may flow.

[0143] If party A 20 wants to transact with other parties, party A 20 generates a digital contract through the contracts module 20-33, signs the contract through the cryptographic module 20-32 and sends the contract to the other parties through wallet 20- 20 notification module 20-22 and communication component 41-10. Once the other parties accept the transaction and sign the contract, those parties send a copy of the accepted business transaction (i.e., signed by all the other parties involved in the business transaction) through communication component 41-10, which is received by wallet 20-20 notification module 20-22, and stored by wallet 20-20 in LS 20-23 and CB 20-24. Party A 20 is informed of the outcome of the business transaction through the UI 20-11 in application 20-10.

[0144] The utilities module 20-34 is a set of tools used by the different elements, including date management, QR code encoder, currency formatter, backup generator, sharing options, and the like, to perform tasks, such as parsing strings, generating images, initiating network connections, and the like, for example.

[0145] The authentication module 20-35 is a module that is able to authenticate a network communication. When party A 20 communicates with other parties through protocol and communication component 41-10, the communication is authenticated and encrypted through the authentication module 20-35.

[0146] Information hub 41 manages the flow of information between the parties in system 100. Information hub 41 includes communication component 41-10. Communication component 41-10 is a component that orchestrates the communication between the parties involved in a business transaction. Communication component 41-10 has a dispatcher 41-11 and a notification module 41-12.

[0147] Dispatcher 41-11 handles the dispatching of information to the relevant parties involved in a business transaction. The dispatcher 41-1 1 operates as a "post office service." If party A 20 wants to communicate with party B 21, party A 20 may post a message to party B 21 in the dispatcher 41-11. The message may include the digital contract forming the basis of the business transaction between party A 20 and party B 21, for example.

[0148] When a message for party B 21 is deposited in the dispatcher 41-11 by party A 20, the dispatcher 41-11 informs the notification module 41-12 to notify party B 21 that a message is waiting in the dispatcher 41-11.

[0149] Notification module 41-12 provides a notification service which has the ability to send a notification through online communication networks to any party in system 100. Parties who wish to be part of system 100 inform the notification module 41- 12 of their address and how they may be reached or contacted (IP address, GCM token, etc.). If a party's address changes, the party updates the notification module 41-12 of its new address. When notification module 41-12 needs to inform party B 21 that a message is posted in the dispatcher 41-11, the notification module 41-12 may send a message to party B 21 on one of his known addresses through the relevant communication protocol (http request to an IP address, GCM notification to a GCM token, etc.).

[0150] If party B 21 receives a notification from the notification module 40-12, party B 21 contacts the dispatcher 41-11 to retrieve the message. Party B 21 contacts dispatcher 41-11 through protocol 21-30 using authentication 21-35 to retrieve the message.

[0151] If party B 21 processes the message and wants to send back information to another party, such as back to party A 20, party B 21 may send that message to the desired party using the mechanism described above. The message may include the same or an amended version of the digital contract, confirming the agreement or the commitment of party B 21 to some specific clauses in the contract, or suggesting an amendment or even adding additional clauses to the contract.

[0152] Trust authority 40 is a special party that has oversight on a specific type of business transactions (e.g., for digital cash exchange the trust authority 40 may be a bank, for example). Trust authority 40 witnesses and approves the validity of the business transaction as outlined in the digital contract exchanged between the parties involved in the transaction, according to the rules set in the terms module 40-22 for the relevant type of business transaction. Trust authority 40 has a validation component 40-20, and a services component 40-30. The system 100 may have one or more trust authorities 40.

[0153] Validation component 40-20 witnesses and approves or disapproves a business transaction. Validation component 40-20 has a trust authority node 40-21 and a terms module component 40-22.

[0154] Trust authority node 40-21 is a component that reviews digital contracts drafted by the parties involved in a business transaction and provides an acceptance seal if the contracts rise to an acceptable level and are deemed worthy. An acceptable level may be defined by review of the blockchain registry for the digital asset to confirm that party A is the proper owner of the asset. The acceptable level may also include analyzing the signature of the parties who have signed the contract to confirm that the signature is valid. Trust authority node 40-21 receives the last iteration of the digital contract prepared by the parties (typically sent by the last party amending the contract proposal). Trust authority node 40-21 analyses the content of the contract and checks the content against the rules previously set and stored in terms module 40-22 for the given business transaction. If the contract is compliant to the rules of the business transaction then trust authority node 40- 21 adds a signature to the approved clauses in the contract and sends copies of the contract to the involved parties through communication component 41-10. The business transaction is considered executed when the contract is accepted and signed by all the parties and the final signed version is dispatched to the parties through communication component 41-10.

[0155] As set forth above by way of example, for a money transfer, the validation may include determining if party A 20 signed all of the required clauses in the contract and is the signature used valid, determining if party B 21 signed all of the required clauses in the contract and is the signature used valid, determining if party A 20 actually owned the money that is being transferred (this may be performed using the single-entry books of party A 20 using the copy stored as described with respect to Figure 12 herein below, but is basically the sum of all previous incoming and outgoing transfers of party A 20 for that particular asset type, which in this case is dollars), determining if the commission or fee for the transactions has been properly included, determining if other conditions for validation are in place such as is party A 20 allowed to transact for that type of asset, and determining if there is any limit to the amount of transfer. [0156] Terms module 40-22 is a container of business rules pertaining to specific transaction types. For each business transaction type, a set of business rules is defined and stored in the terms module 40-22. Terms module 40-22 serves the set of business rules of a specific transaction type to the trust authority node 40-21 or any other party acting based on the rules in order to apply them when taking part in a business transaction. Terms module 40-22 may include a library of predefined templates of digital contracts that are suitable for use in different types of business transactions and descriptions of how those business transactions may flow. By way of example, terms module 40-22 may contain that for an operation type "transfer US dollars" the commission or fee is to be paid to Party X (which may be the trust authority) and is Y% of the amount transacted. Other terms in the terms module 40-22 include that the transfer may occur only in the case of party B 21 is geographically located at a location Z.

[0157] Services 40-30 is a general purpose module that has several services that support trust authority 40 to perform the role of trust authority 40. Services 40-30 includes a storage component 40-31, a monitoring component 40-32, a logging component 40-33 and a backup component 40-34.

[0158] Storage component 40-31 is a database, either distributed or centralized, or any combination thereof, where the transactions witnessed and verified by the trust authority 40 are stored. The data stored by trust authority 40 may be used as an input to validate future transactions between parties, or only for reference. The stored copy of the digital contract signed by party A 20, party B, 21, 21A, 21B and by trust authority 40 is proof that a business transaction has occurred, been agreed and committed to by the parties.

[0159] Monitoring component 40-32 monitors the proper functioning of the system

100. Logging component 40-33 logs events at the trust authority 40. Backup component 40-34 is a replica of storage 40-31 in a remote storage service to reduce the risk of data loss for situations where storage 40-31 is compromised. In case of data loss, data may be recovered from backup component 40-34 to storage 40-31 to allow the system 100 to keep functioning normally.

[0160] Digital custodian 61 is a component that generates and destroys digital assets by acknowledging asset reception or delivery with custodian 60 through physical liability channel 1-2 and digital liability channel 2-3. Digital custodian 61 includes generator component 61-11, business services component 61-12 and a connector component 61-13. [0161] Generator component 61-11 generates new digital assets to be sent to party

A 20 after receiving an acknowledgement from digital custodian 61 with the specifications of physical asset reception. That is, new digital assets, such as an increase in the value of a bank account in dollars or other currency, or a digital asset that is described using the specification described herein in order to designate a piece of real property. The specification in such an example may include the address, a description of a dwelling, the number of bedrooms, bathrooms and the like. The new digital assets are sent to party A 20 through channel 1-3.

[0162] Business services component 61-12 interprets the acknowledgement received from digital custodian 61 depending on the business type of the asset received (for example interpretation of cash acknowledgement, an event ticket or a vote is different).

[0163] Connector component 61-13 opens a connection on the system used by the digital custodian 61 and establishes a communication channel through which the acknowledgments may be received.

[0164] Custodian 60 is a component of the legacy world that receives an asset from a party, such as party A 20. Custodian 60 keeps a record of the asset in custody.

[0165] Figure 13 A illustrates a method 275 for performing a digitization-in of a physical asset, or some other right, to digital assets with respect to the software stack of Figure 12. As described with respect to Figure 1 and method 250 of Figure 4, digitize-in portion 200 of system 100 includes custodian 60 and digital custodian 61 for interaction with a user, such as party A 20. Party A 20 communicates with custodian 60 through a deposit channel 1-1 using the internet, a bank, or some other process that links a physical asset, or some other right, to party A 20 at step 252 of method 250. Deposit of the physical asset is received by custodian 60, and converted into digital currency by digital custodian 61.

[0166] More specifically, as illustrated in Figure 13 A, party A 20 interacts with custodian 60, potentially through a legacy or other system, to begin digitizing the physical asset into system 100 at step 277. Custodian 60 applies a procedure to handle the asset and returns an acknowledgment, such as a physical receipt or return code, for example, approving the reception of assets. The procedure to handle assets is designed according to specifications of the asset including the type, nature, size, value, possible operations and the like. [0167] Referring now also to Figure 13B. Figure 13B illustrates a diagram 1100 of the signaling that occurs during digitization in of Figure 13 A. Party A 20 and custodian 60 communicate during the deposit of asset 1-1. This communication includes deposit details 1110.

[0168] Communication of the deposit of a physical asset with custodian 60 is provided to digital custodian 61 via the physical liability channel 1-2 at step 254 of method 250. Digital custodian 61 sends a notification to custodian 60 acknowledging the reception of the documents. Digital custodian 61 generates the specified assets with the associated attributes in a digital cryptographic format. More specifically, once custodian 60 notifies party A 20 that the confirmation document is received, custodian 60 sends an electronic version of the specifications and the confirmation documents through a communication channel between custodian 60 and connector 61-13 of digital custodian 61 at step 279. Connector 61-13 calls business services 61-12 to pass along the details of the asset at step 280. Business services 61-12 calls generator 61-11 requesting generation of the requested number of digital units in a new digital contract signed by generator 61-11 for the digital custodian 61 at step 281.

[0169] As illustrated in Figure 13B, custodian 60 and digital custodian 61 interact using physical liability channel 1-2. This interaction may include details of the deposit and a JSON contract 1120 for the assets deposited, as discussed herein.

[0170] Communication of a digital asset to the party, party A 20, from the digital custodian 61 is accomplished across the digital asset channel 1-3. The digital contract is delivered to party A 20. Generator 61-11 sends the signed digital contract to dispatcher 41-11 in information hub 41 at step 282. Once received, a notification is sent by dispatcher 41-11 to notification module 20-22 of party A 20 at step 283. Upon receipt of notification at party A 20, wallet component 20-21 connects to dispatcher 41-11 and retrieves the signed digital contract at step 284. Wallet component 20-21 calls for consensus module 20-31 to validate the content of the digital contract and calls for cryptographic module 20- 32 to add a signature of party A 20 at step 285. Wallet component 20-21 sends the signed digital contract to the LS 20-23 and CB 20-24 and updates the list of transactions at step 286.

[0171] As illustrated in Figure 13B, digital custodian 61 and party A 20 may interact across digital asset channel 1-3. This interaction may include details of the transaction and/or deposit of the asset, including a receipt, for example, and may include JSON contract details 1130. [0172] Party A 20 may then transact the assets using digital contracts with other parties. Party A 20 may receive against each contract the agreed amount of other assets (for example money in a form of fiat currency) in the same contract or outside system 100 as described.

[0173] Figure 14A illustrates a method 375 for performing a digitization out of a digital asset, or some other right, to a physical asset with respect to the software stack of Figure 12. As described with respect to Figure 1 and method 350 of Figure 5, digitize-out portion 300 of system 100 includes custodian 60 and digital custodian 61 for interaction with a user, such as party B 21. Party B 21 communicates with custodian 60 through a withdrawal channel 2-1 at step 352 using the internet, a bank, or some other process that links the digital asset, or some other right, to party B 21 at step 377.

[0174] Referring now also to Figure 14B. Figure 14B illustrates a diagram 1200 of the signaling that occurs during the digitization out of Figure 14 A. Party A 20 and custodian 60 communicate during the withdrawal of asset using withdraw asset channel 1- 1. This communication includes withdrawal details 1230.

[0175] Party B 21 may present its digital asset to digital custodian 61 for conversion to physical asset via the digital asset channel 2-2 at step 354. Party B 21 initiates an asset withdrawal by initiating a contract with the amount and details of the asset through the user interface 21-11 or API 21-12 and calls wallet component 21-21 at step 378. Wallet component 21-21 calls contracts component 21-33 of protocol 21-30 and generates a digital contract including the requested details of the withdrawal at step 379. Contract module 21-33 calls cryptographic module 21-32 to sign the digital contract at step 380. The signed digital contract is delivered to dispatcher 41-11 of information hub 41, and information hub 41 notifies the business services component 61-12 of gateway 61- 10 of the digital custodian 61 at step 381 to examine the digital contract.

[0176] As illustrated in Figure 14B, party B 21 and digital custodian 61 communicate regarding the digital asset across channel 2-2. This communication includes JSON contract details and details of the transaction 1210.

[0177] The business services component 61-12 of gateway 61-10 retrieves the digital contract from dispatcher 41-11 and sends the details of the digital contract to connector 61-13 and connector 61-13 relays the contract (or details) to the custodian 60 at step 382.

[0178] Digital custodian 61 reconciles the digital transaction and authorizes custodian 60 to release the physical asset or right to party B 21 through the digital liability 2-3 channel at step 356. Digital custodian 61 acknowledges receipt of the digital contract and the authorization to deliver assets by custodian 60 and operates so that, the corresponding digital units of the asset that is withdrawn are digitally destroyed within system 100 at step 383.

[0179] As illustrated in Figure 14B, custodian 60 and digital custodian 61 interact using digital liability channel 2-3. This interaction may include details of the transaction and a JSON contract 1220 for the assets, as discussed herein.

[0180] Figure 15A illustrates a method 475 for performing the transaction component with respect to the software stack of Figure 12. As described with respect to Figure 1 and method 450 of Figure 6, transaction 400 describes the digital transaction within system 100. A first party, party A 20, provides or makes an offer for a transaction. This offer is delivered to an information hub 41 in preparation for sending the offer to the second party on a first offer channel 3-1 at step 452.

[0181] Specifically, wallet component 20-21 operates with contracts component

20-33 of protocol 20-30 to generate a digital contract at step 477. The details related to the withdrawal are included in the digital contract. Contract module 20-33 operates with cryptographic module 20-32 to sign the digital contract at step 478. The signed digital contract is delivered to dispatcher 41-11 of information hub 41 at step 479. Information hub 41 sends a notification through the notification component 41-12 to party B 21 at step 480.

[0182] Referring now also to Figure 15B. Figure 15B illustrates a diagram 1300 of the signaling that occurs during the transaction component of Figure 15 A. Party A 20 makes an offer via first offer channel 3-1 by providing JSON contract details 1310 to information hub 41.

[0183] Information hub 41 informs a second party, party B 21, through notification component 41-12, that party A 20 has made an offer for a transaction via the second offer channel 3-2 at step 454. Once party B 21 receives a notification through the notification component 21-22 of wallet component 21-21, wallet component 21-21 retrieves the digital contract from dispatcher 41-11 at step 481. Wallet component 21-21 calls the consensus component 21-31 to check the validity of the digital contract and the signature of party A 20 at step 482.

[0184] As illustrated in Figure 15B, information hub 41 interacts with party B 21 across relay channel 3-2. This interaction may include a notification 1320 a notification to access information hub 41 to receive the transaction details. Party B 21 accesses information hub 41 with a retrieval request 1330 and is provided JSON contract details from the contract presented by party A 20.

[0185] If party B 21 accepts the transaction, party B 21 signs the offered transaction and sends the agreed upon transaction to the trust authority 40 to witness and validate the transaction via the validation channel 3-3 at step 456. Wallet component 21- 21, once the validity of the digital contract is verified, calls cryptographic module 21-32 to add a signature of party B 21 on the digital contract and sends the signed digital contract to trust authority node 40-21 of the validation component 40-20 at step 483.

[0186] As illustrated in Figure 15B, party B 21 contacts trust authority 40 in order to validate the contract via validation channel 3-3. The validation of the contract includes the JSON contract 1340 to be validated.

[0187] If validated by the trust authority 40, the transaction is signed by the trust authority 40 and delivered to party A 20 via the receipt channel 3-4 at step 458. Trust authority node 40-21 requests that the terms module 40-22 check the terms detailed in the digital contract and any fee calculation at step 484. Once the signed digital contract is verified the trust authority 40 adds the signature of the trust authority 40 at step 485. Notice may be provided to party B 21 from trust authority 40.

[0188] As illustrated in Figure 15B, trust authority 40 validates the signatures of party A 20 and party B 21, along with any other terms attendant to the contract residing in terms module 40-22 at 1350.

[0189] If validation is approved, as illustrated in Figure 15B, Trust authority 40 provides a receipt via receipt channel 3-4 to all parties involved including at least receipts to party A 20 and party B 21 1370. Notice may also be provided to any third party 50. Such a notice is illustrated in Figure 15B as being provided across information channel. This notice may include signed receipts being sent to subscribed parties 1360, for example.

[0190] Figure 16 illustrates the parties, obligations/assets and events that may occur within system 100 of Figure 1. These are shown on the axes that define transaction in system 100. The x-axis defines types of events, the y-axis participants to the transactions, and z-axis the obligations and assets involved. The transaction, parties and types, demonstrate that any transaction on this graph may occur within system 100.

[0191] As illustrated in Figure 16, participants in system 100 may include a witness and/or trusted guarantor, subscribed members, and third parties depicted on the y- axis of the graph illustrated in Figure 16. [0192] The obligations/assets involved in transaction within system 100 of Figure

1 may include money and/or gold, securities, titles, deeds, shares, voting rights, benefits and wills. These obligations/assets are depicted on the z-axis of the graph illustrated in Figure 16.

[0193] The events that may be a basis for the transactions occurring within system

100 of Figure 1 are depicted in the x-axis of the graph illustrated in Figure 16. These events may include participant-based, event-based, time-based and location-based, for example. Participant based transactions include those where one or more of the participants in the transaction are identified. Event based transaction occur when an event occurs, such as the first snow of the year, for example. Time based transactions may occur at specified times, such as the time of the New Year, for example. Location based transactions may occur when a party goes to a certain location.

[0194] Table 1 is a table of use-case examples for the peer-to-peer exchange platform of Figure 1 combining the various participants, assets and types of event depicted within Figure 16.

Table 1: Use-case examples for the peer-to-peer exchange platform

Service or Condition met/

Registered

Goods on Poste N.A. Third Party/

User

condition Participants

[0195] As illustrated in Table 1, different business transactions, such as the transaction component of Figure 1, or the digitize-in or digitize-out components of Figure 1, may utilize the peer-to-peer exchange platform of Figure 1. These include cash exchanges, a registrar of wills, shareholder meetings, tickets, Oscars, real estate, online goods, and service or goods on a condition. These business transactions are provided by way of non-limiting example only.

[0196] Table 1 further provides a witness/trusted guarantor/controlling authority referred to as trust authority in Figure 1, or may also be third parties to the transaction depending on the configuration of the specific transaction, participants in the transactions referred to as parties in Figure 1, third parties and terms and conditions for each of the business transactions discussed. By way of example, when the business transaction is cash, the controlling authority may be a financial institution, the participants or parties may be clients such as the buyer and sellers, for example. The terms and conditions on such a cash exchange may be limited only by the cash balance of the buyer, for example.

[0197] In the case of a will, the controlling authority may be the court of wills or a lawyer, and the participants may include the executor, while third parties include the beneficiaries. In the case of a will, the terms and conditions may include having a will and death of the willed party.

[0198] For the use-case of a meeting of shareholders, the controlling authority may be a custodian and/or stock exchange, and the participants may be shareholders. Third parties to the transaction may include banks, for example. The terms and conditions applied to the exchange may be resolutions and votes, for example.

[0199] In the case of tickets, the controlling authority may include a sports league like the National Basketball Association (NBA), participants to the exchange may include the ticket holders, while third parties to the exchange may include the destination or venue involved in specific sporting events. The terms and conditions to the exchange may include the tickets.

[0200] A controlling authority may be the Academy of Motion Pictures, when the exchange includes the Oscars, for example. In this case, the participants may include the members of the Academy of Motion Pictures, third parties may include the viewers of the motion pictures, and the terms and conditions may include votes and awards to give.

[0201] In the exchange of real estate, the controlling authority may be the title holder (or title insurance company) and, participants to the exchange may be the buyer and seller, or anyone with interest in the real estate. Third party information may include the bank or mortgage company, and the terms and conditions may include the property to transact.

[0202] System 100 may also be used to exchange goods online. A controlling authority in such a case may include an online retailer or transactor, such as E-bay, for example. Participants to the exchange may include registered users to the online retailers and the terms and conditions may include the goods or services being acquired.

[0203] System 100 may be used to provide service or goods on a condition. The controlling authority in such a case may include the Poste, for example. Participants to the exchange may include registered users to the controlling authority and the terms and conditions may include the conditions being met including goods or services being acquired, for example.

[0204] Figure 17 illustrates a user interface 1500 of the present application. The user interface 1500 may be shown the main screen of the application. The user interface provides the balance 1510 on the account and main functions for initiating a transaction including send 1515 and receive 1520. User interface 1500 may include a menu bar 1525 and an identity button 1530.

[0205] Send 1515 and receive 1520 may be used to interact with the system 100 in transactions as described herein above. Menu bar 1525 functions to activate to provide access to functions illustrated in Figure 18. Contacts button 1530 functions to activate to provide access to functions illustrate in Figure 19.

[0206] Figure 18 illustrates the business services 1600 of the present application.

The business services 1600 may be accessed via menu bar 1525 of Figure 17 that opens a drop-down (actually depicted as coming from left side) menu 1610. Business services 1600 include a home selection 1620, a recharge wallet selection 1630, top-up airtime selection 1640, pay invoices selection 1650, settings selection 1660, aid or help selection 1670 and information about the software selection 1680.

[0207] Figure 19 illustrates a contacts menu 1700 of the present application accessed via contacts button 1530 of Figure 17. Contacts menu 1700 may be a floating menu providing access to identity selection 1710, adding a new contact selection 1720, access list of all contacts selection 1730 and a button 1740 to minimize the contacts menu 1700.

[0208] Figure 20 illustrates a send money function 1800 of the present application activated using the send button 1515 of Figure 17. Send money function 1800 provides the ability to send money remotely to a known contact accessed via contacts button 1810 or scan a QR code presented by another user via scan button 1820.

[0209] Figure 21 illustrates a request money function 1900 of the present application activated using the receive button 1520 of Figure 17. Request money function 1900 provides the ability to request money remotely through any social media application or show a QR code to another user to be scanned. The amount of the request may be entered in box 1910, and the show QR code button 1920 may be activated to produce a QR code, or the share button 1930 may be activated to share the request on social media.

[0210] Figure 22 illustrates a QR code screen 2000 that can be delivered to request/receive funds. Specifically, QR code screen allows entry of an amount in the amount bar 2010 and a QR code 2020 is created and presented. QR code 202 may be provided to others, allowing them to scan and send the requested amount.

[0211] Although features and elements are described above in particular combinations, one of ordinary skill in the art will appreciate that each feature or element may be used alone or in any combination with the other features and elements. In addition, the methods described herein may be implemented in a computer program, software, or firmware incorporated in a computer-readable medium for execution by a computer or processor. Examples of computer-readable media include electronic signals (transmitted over wired or wireless connections) and computer-readable storage media. Examples of computer-readable storage media include, but are not limited to, a read only memory (ROM), a random access memory (RAM), a register, cache memory, semiconductor memory devices, magnetic media such as internal hard disks and removable disks, magneto-optical media, and optical media such as CD-ROM disks, and digital versatile disks (DVDs). A processor in association with software may be used to implement a radio frequency transceiver for communication of signals as discussed herein.

* * *