CROSS-REFERENCES TO RELATED APPLICATIONS

The present application claims priority to US Provisional Patent Application 63/034,451 to Merfeld et al., filed June 4, 2020, and entitled "Cryptocurrency Tools." The above-referenced application is incorporated herein by reference for all purposes.

FIELD OF THE INVENTION

Some applications of the present invention relate in general to cryptocurrency. More specifically, some applications of the present invention relate to tools for increasing information available regarding cryptocurrency transactions.

BACKGROUND

Cryptocurrencies are decentralized currencies that uses strong cryptography to secure financial transactions, control the creation of additional units, and verify the transfer of assets. Decentralized control is achieved using distributed ledger technology, such as a blockchain. A recognized advantage of cryptocurrencies is their facilitation of anonymous transactions. However, cryptocurrencies provide challenges for banks and other regulated institutions, as well as for the regulators that regulate them.

SUMMARY OF THE INVENTION

Some applications of the invention may facilitate cryptocurrency transactions in a manner that increases trust in the source of the cryptocurrency. Some applications of the invention may facilitate oversight by regulators. Some applications of the invention include a system, such as a cryptocurrency wallet, that facilitates, when multiple users each use a respective copy of the system, construction of an ecosystem within which an otherwise generally /publicly used cryptocurrency may be transacted (e.g., traded) with a greater degree of trust, e.g., compared to transacting (e.g., trading) the same cryptocurrency outside of the ecosystem.

For some applications, a system (e.g., including software running on hardware, such as a cryptocurrency wallet) assesses incoming cryptocurrency transactions in order to determine (i) which are appropriate for automatic clearance, and (ii) which are appropriate for (e.g., to require) manual clearance, such as by one or more compliance officers. For some such applications, all incoming cryptocurrency transactions are automatically quarantined upon receipt, such that they are unavailable for use as inputs in outgoing transactions. Upon the assessment of a given transaction, that transaction may be released from quarantine. This release may be performed irrespective of whether the assessment determines that the incoming transaction is appropriate for automatic clearance, or flags the incoming transaction for manual clearance. Furthermore, this release may be performed for a transaction that is determined to be appropriate for manual clearance, even before manual clearance has been performed. Once released from quarantine, an incoming transaction may be used as an input in an outgoing transaction. For some applications, such a technique is performed and/or enforced by a cryptocurrency wallet that is associated with a cryptocurrency address on a cryptocurrency blockchain.

Typically, when an outgoing transaction is performed, a tag is included within the assignment of that transaction on the cryptocurrency blockchain. The tag is typically encrypted, so that only authorized entities may identify and/or read the tag. For some applications, the tag includes additional information, such as a score for the outgoing transaction. The score may be calculated based on scores previously calculated for the incoming transactions that are inputs for the outgoing transaction. The additional information may alternatively or additionally include the identity of the recipient of the outgoing transaction, a transaction identifier (ID), and/or a timestamp.

When assessing an incoming transaction, upstream transactions on the cryptocurrency blockchain may be examined, typically up to a predefined depth upstream of the incoming transaction. Within the predefined depth, upstream transactions that include the tag (i.e., were tagged during a previous cycle through the system) are identified. Each tagged upstream transaction that is identified contributes to (e.g., increases) a score assigned to the incoming transaction. The additional information included in the tag may also contribute to the score. The score assigned to the incoming transaction typically serves as the basis of the assessment regarding whether the incoming transaction is appropriate for automatic clearance or for manual clearance.

For some applications, a manual clearance system (e.g., including software running on hardware) facilitates manual clearance of transactions, e.g., by one or more compliance persons. For example, incoming transactions flagged for manual clearance (e.g., as described hereinabove) may be appointed to the manual clearance system.

The manual clearance system may utilize a compliance blockchain that is distinct from the cryptocurrency blockchain. The manual clearance system may receive a transaction ID associated with the incoming transaction that has been flagged for manual clearance, along with the score (described hereinabove) that is associated with the transaction ID. The manual clearance system may also receive information about the incoming transaction - typically also associated with the transaction ID.

On the compliance blockchain, an event associated with the transaction ID may be recorded, and may be assigned to one or more compliance addresses, each of the compliance addresses having been provided to a respective compliance person (or another compliance entity, such as a compliance organization). A compliance rule is designated to the event, typically in response to the score of the associated transaction. The rule typically includes a signature condition that stipulates a quota of digital compliance signatures. The signature condition (e.g., the quota thereof) may define a number of signatures required, and/or a tier or seniority of compliance persons whose digital signatures are required. Each compliance person is typically provided with a software product that has an address on the compliance blockchain, identifies events currently assigned to that address, and conveys those events to the compliance person - e.g., by displaying a list on a graphical user-interface (GUI). At least some additional information about the flagged incoming transaction is typically also securely provided to the compliance person, e.g., via the same software product / GUI. If the compliance person wishes to clear the event (e.g., after reviewing the information concerning the incoming transaction), he or she digitally signs the event using a private key associated with his or her software product.

The manual clearance system monitors the compliance blockchain to determine whether the signature condition for a given event has been fulfilled. Only once the signature condition has been fulfilled, does the manual clearance system record, on the compliance blockchain, that the event has been cleared.

The compliance blockchain is made securely available to authorized entities such as regulators, thereby facilitating transparency and oversight.

There is therefore provided, in accordance with an application of the present invention, a cryptocurrency wallet having an address on a blockchain for a cryptocurrency, the wallet including: a receive function, configured to receive incoming transactions of the cryptocurrency by, for each incoming transaction, (1) on the blockchain, signing the incoming transaction using a private key associated with the address, and (2) quarantining the incoming transaction; a send function, configured to send outgoing transactions of the cryptocurrency from the wallet by, for each outgoing transaction, (1) on the blockchain, recording an assignment of the cryptocurrency away from the address, and (2) including a tag within the assignment of the cryptocurrency away from the address; and a release subroutine that, for each incoming transaction allocated to the quarantine: by examining, on the blockchain, transactions upstream of the incoming transaction, identifies tagged upstream transactions, a tagged upstream transaction being defined as a transaction, upstream of the incoming transaction, that is identified as including the tag; calculates a score for the incoming transaction in response to the tagged upstream transactions, each of the tagged upstream transactions contributing to the score; sorts the incoming transaction, according to: if the score is above a threshold, the release subroutine automatically clears the incoming transaction, and if the score is below the threshold, the release subroutine flags the incoming transaction for manual clearance by a manual clearance system; and only subsequently to sorting the incoming transaction, and irrespective of whether the incoming transaction is automatically cleared or flagged for manual clearance, releasing the incoming transaction from quarantine, and the send function is disallowed from performing outgoing transactions for which an input is an incoming transaction that has been quarantined but not released.

In an application, the receive function is configured to sign the incoming transaction only if the incoming transaction is from a third-party address that is listed on a whitelist of approved third-party addresses.

In an application, the release subroutine identifies tagged upstream transactions by examining, on the blockchain, transactions upstream of the incoming transaction only up to a predefined depth from the incoming transaction.

In an application, the transactions upstream of the incoming transaction define a plurality of transaction paths leading to the incoming transaction, and the release subroutine examines the transactions upstream of the incoming transaction in a path-wise manner, following each of the transaction paths upstream until reaching a tagged upstream transaction, and ignoring any transactions that are further upstream than the tagged upstream transaction.

In an application, the release subroutine: for each of the tagged upstream transactions, calculates a contribution that the tagged upstream transaction contributes to the score; and calculates the score responsively to the calculated contribution for each of the tagged upstream transactions.

In an application: for each outgoing transaction: the outgoing transaction has at least one input that is an output of an incoming transaction that was previously received by the receive function, and the send function is configured to write, within the tag, score data that is at least partly dependent on the score calculated for the incoming transaction, and for each of the tagged upstream transactions, the release subroutine calculates the contribution of the tagged upstream transaction responsively to the score data written within the tag of the tagged upstream transaction.

In an application, for each of the tagged upstream transactions, the release subroutine calculates the contribution of the tagged upstream transaction responsively to a depth of the tagged upstream transaction from the incoming transaction.

In an application, the contribution of the tagged upstream transaction is negatively weighted according to the depth of the tagged upstream transaction.

In an application, for each of the tagged upstream transactions, the release subroutine calculates the contribution of the tagged upstream transaction responsively to a reciprocal of the depth of the tagged upstream transaction.

In an application, for each of the tagged upstream transactions, the release subroutine calculates the contribution of the tagged upstream transaction responsively to a currency value of the tagged upstream transaction.

In an application, the contribution of the tagged upstream transaction is positively weighted according to the currency value of the tagged upstream transaction.

In an application, for each outgoing transaction: the outgoing transaction has at least one input that is an output of an incoming transaction that was previously received by the receive function, and the send function is configured to write, within the tag, score data that is at least partly dependent on the score calculated for the incoming transaction.

In an application, the release subroutine calculates the score in response to the score data written within the tag of each of the tagged upstream transactions.

There is further provided, in accordance with an application of the present invention, a method, including: receiving a transaction ID associated with an incoming transaction of a cryptocurrency, the incoming transaction being on a cryptocurrency blockchain; receiving information about the incoming transaction, the information being associated with the transaction ID; receiving a score associated with the transaction ID; on a compliance blockchain that is distinct from the cryptocurrency blockchain, recording an event associated with the transaction ID; in response to the score: on the compliance blockchain, assigning the event to one or more compliance addresses, each of the compliance addresses having been provided to a respective compliance entity; and designating a compliance rule to the event, the rule including a signature condition, the signature condition stipulating a quota of compliance signatures, each of the compliance signatures being signed using a respective private key associated with a respective one of the compliance addresses; securely providing each of the compliance entities with at least some of the information about the incoming transaction; monitoring whether the signature condition has been fulfilled; and only upon determining that the signature condition has been fulfilled, recording a clearance label on the compliance blockchain, the clearance label indicating that the event has been cleared.

In an application: the cryptocurrency blockchain is an open public blockchain; the compliance blockchain is an open private blockchain; receiving the transaction ID associated with the incoming transaction includes receiving the transaction ID associated with the incoming transaction that is on the on the open public cryptocurrency blockchain; and

In an application, assigning the event to one or more compliance addresses includes assigning the event to a number of compliance addresses than is greater than the quota.

In an application, assigning the event to one or more compliance addresses includes assigning the event to a number of compliance addresses than is equal to the quota.

In an application, the method further includes providing, to each of the one or more compliance entities, a computer software product including a non-transitory computer- readable medium in which program instructions are stored, which instructions, when read by a computer cause the computer to: identify, on the compliance blockchain, that the event has been assigned to the compliance address that was provided to the compliance entity; present the event to the compliance entity; receive, from the compliance entity, an input indicating that the compliance entity wishes to sign the event; and in response to the input, signing the event with a compliance signature using the private key associated with the compliance address that was provided to the compliance entity.

In an application, the program instructions of the computer software product, when read by the computer, cause the computer to securely provide the compliance entity with the at least some information about the incoming transaction, and providing the computer software product includes providing the computer software product whose program instructions, when read by the computer, cause the computer to securely provide the compliance entity with the at least some information about the incoming transaction. recording the event on the compliance blockchain includes recording the event on the open private compliance blockchain.

In an application: each of the compliance entities is pre-assigned to a respective one of a plurality of tiers, such that the compliance entities include at least (i) first-tier compliance entities, pre assigned to a first tier, the compliance address of each of the first-tier compliance entities being a first-tier compliance address, and (ii) second-tier compliance entities, pre-assigned to a second tier, the compliance address of each of the second-tier compliance entities being a second-tier compliance address, assigning the event to one or more compliance addresses includes assigning the event to (i) one or more first- tier compliance addresses, and (ii) one or more second-tier compliance addresses, the quota of compliance signatures is a first quota of first-tier compliance signatures, each of the first-tier compliance signatures being signed using a respective private key associated with a respective one of the first- tier compliance addresses, the signature condition further stipulates a second quota of second-tier compliance signatures, each of the second-tier compliance signatures being signed using a respective private key associated with a respective one of the second-tier compliance addresses, and monitoring whether the signature condition has been fulfilled includes monitoring whether both (i) the first quota has been fulfilled, and (ii) the second quota has been fulfilled.

In an application, assigning the event to one or more first-tier compliance addresses includes assigning the event to a number of first-tier compliance addresses than is greater than the first quota.

In an application, assigning the event to one or more second-tier compliance addresses includes assigning the event to a number of second-tier compliance addresses than is greater than the second quota.

In an application, assigning the event to one or more second-tier compliance addresses includes assigning the event to a number of second-tier compliance addresses than is equal to the second quota.

There is further provided, in accordance with an application of the present invention, a method for use with a computer system, the method including: on a blockchain, receiving an incoming transaction of cryptocurrency in which cryptocurrency has been assigned to an address on the blockchain; in response to receiving the incoming transaction, automatically quarantining the incoming transaction such that the computer system is disallowed from using the incoming transaction as an input for an outgoing transaction in which cryptocurrency is assigned away from the address; by examining, on the blockchain, upstream transactions upstream of the incoming transaction, identifying tagged upstream transactions, a tagged upstream transaction being defined as an examined upstream transaction, upstream of the incoming transaction, that is identified as including a pre-defined tag, the pre-defined tag being indicative that the tagged upstream transaction was assigned away from the address by the computer system; calculating a score for the incoming transaction in response to one or more factors, one of the factors being a number of tagged upstream transactions, and each of the tagged upstream transactions increases the score; appointing the incoming transaction to automatic clearance or to manual clearance, according to: if the score is above a threshold, appointing the incoming transaction to automatic clearance, and automatically clearing by the release subroutine, and if the score is below the threshold, appointing the incoming transaction to a manual clearance system; only subsequently to appointing the incoming transaction, and irrespective of whether the incoming transaction is appointed to automatic clearance or to manual clearance, releasing the incoming transaction from quarantine, such that the computer system is allowed to use the incoming transaction as an input for an outgoing transaction in which cryptocurrency is assigned away from the address.

There is further provided, in accordance with an application of the present invention, a computer software product including a non-transitory computer-readable medium in which program instructions are stored, which instructions, when read by a computer cause the computer to perform the method.

In an application, the method is a first method, and the program instructions are first program instructions that, when read by the computer cause the computer to execute the first method, and second program instructions are stored in the non-transitory computer-readable medium, which second program instructions, when read by the computer, cause the computer to execute a second method, including: sending an outgoing transaction by (1) on the blockchain, recording an assignment of cryptocurrency away from the address, with the incoming transaction being an input for the outgoing transaction, and (2) including the pre-defined tag within the assignment of cryptocurrency away from the address.

There is further provided, in accordance with an application of the present invention, a cryptocurrency wallet having an address on a blockchain for a cryptocurrency, including: a primary container; a quarantine; a receive function, configured to receive incoming transactions of the cryptocurrency by, for each incoming transaction, (1) signing the incoming transaction using a private key associated with the address, and (2) allocating the incoming transaction to the quarantine; a send function: configured to send outgoing transactions of the cryptocurrency from the primary container, each outgoing transaction including (1) recording, on the blockchain, an assignment of the cryptocurrency away from the address, and (2) including a tag within the assignment of the cryptocurrency away from the address, and unable to perform outgoing transactions of cryptocurrency from the quarantine; and a release subroutine that, for each incoming transaction allocated to the quarantine: by examining, on the blockchain, upstream transactions upstream of the incoming transaction, identifies tagged upstream transactions, a tagged upstream transaction being defined as an upstream transaction, upstream of the incoming transaction, that is identified as including the tag; calculates a score for the incoming transaction in response to one or more factors, one of the factors being a number of tagged upstream transactions, and each of the tagged upstream transactions increases the score; appoints the incoming transaction to automatic clearance or to manual clearance, according to: if the score is above a threshold, the incoming transaction is appointed to automatic clearance, and is automatically cleared by the release subroutine, if the score is below the threshold, the incoming transaction is appointed to a manual clearance system, and, only subsequently to appointing the incoming transaction, and irrespective of whether the incoming transaction is appointed to automatic clearance or to manual clearance, releasing the incoming transaction from the quarantine into the primary container.

The present invention will be more fully understood from the following detailed description of applications thereof, taken together with the drawings, in which: BRIEF DESCRIPTION OF THE DRAWINGS

Fig. 1 is a schematic illustration of a system for use with cryptocurrency, in accordance with some applications of the invention;

Fig. 2 is a schematic illustration of transactions on the blockchain, in accordance with some applications of the invention;

Figs. 3A-D are schematic illustrations of a system for use with cryptocurrency, in accordance with some applications of the invention;

Figs. 4A-B are schematic illustrations of a computer software product that may be provided to compliance entities, in accordance with some applications of the invention; and

Figs. 5-6 are a schematic illustration of respective ecosystems that each include multiple systems for use with cryptocurrency, in accordance with some applications of the invention.

DETAILED DESCRIPTION OF EMBODIMENTS

Reference is made to Fig. 1, which is a schematic illustration of a system 100 for use with a cryptocurrency blockchain 10, in accordance with some applications of the invention. System 100 is illustrated in a manner that represents a computer software product, which may be embodied as a cryptocurrency wallet. For simplicity, blockchain 10 is represented by a dashed rectangle. Blockchain 10 is typically an open public blockchain, and may be the Bitcoin blockchain, or another cryptocurrency blockchain.

Similarly to existing cryptocurrency wallets, system 100 has an address on cryptocurrency blockchain 10, and has a private key associated with the address. Arrow 102 represents system 100 receiving an incoming transaction 22i of the cryptocurrency on blockchain 10. Although Fig. 1 schematically illustrates transaction 22i moving from blockchain 10 into system 100, a person of ordinary skill in the art will recognize that, similarly to existing cryptocurrency wallets, the receipt of transaction 22i is achieved by the system signing, on the blockchain, the incoming transaction using its private key. Arrow 102 may therefore be considered to represent a receive function of system 100.

Arrow 104 schematically represents system 100 sending an outgoing transaction 22o to another address on blockchain 10, which is performed in a similar manner to that performed by existing cryptocurrency wallets, by recording on blockchain 10 an assignment of the cryptocurrency away from the address of system 100 - i.e., to another address on the blockchain. Arrow 104 may therefore be considered to represent a send function of system

100.

As will be understood by a person of ordinary skill in the art, an outgoing transaction requires, as an input, one or more previously-received incoming transactions (i.e., the output(s) thereof) totaling at least a sufficient value. That is, an outgoing transaction is effectively a reassignment, away from a given address, of cryptocurrency previously assigned to that address in one or more incoming transactions. Unlike a standard cryptocurrency wallet, system 100 quarantines incoming transaction 22i upon receipt. This is represented by arrow 102 pointing directly into box 110, which represents quarantine. Receive function 102 may therefore be considered to both (i) sign the incoming transaction on blockchain 10, and (ii) quarantine the incoming transaction (e.g., immediately). A quarantined transaction is unavailable for use as an input for an outgoing transaction. That is, send function 104 (and system 100 as a whole) is disallowed from performing outgoing transactions for which an input is an incoming transaction that is in quarantine 110.

For each incoming transaction in quarantine 110, system 100 examines information regarding the incoming transaction, and responsively appoints the incoming transaction either to automatic clearance or to manual clearance. This decision is represented by rhombus 122, and is described in more detail hereinbelow. Appointment to automatic clearance is represented by box 124, and results in system 100 automatically clearing the incoming transaction. Appointment to manual clearance is represented by box 126, and results in system 100 flagging the incoming transaction for manual clearance by a manual clearance system 200, described in more detail hereinbelow, e.g., with reference to Figs. 3A- D.

Only subsequently to appointing the incoming transaction, system 100 releases (e.g., automatically) the incoming transaction from quarantine 110, such that the computer system is allowed to use the incoming transaction as an input for an outgoing transaction in which cryptocurrency is assigned away from the address. This release is represented by arrow 128. Reference numeral 22r indicates released transactions - i.e., previous incoming transactions that have already been released from quarantine, and are available for use as inputs for an outgoing transaction. For some applications, system 100 releases the incoming transaction from quarantine irrespective of whether the incoming transaction is appointed to automatic clearance or to manual clearance. For some applications, the examination of the information regarding the incoming transaction, the appointment of the incoming transaction to automatic or manual clearance, and the release of the incoming transaction from quarantine, are performed by (e.g., are steps or components of) a release subroutine 120.

For some applications, release subroutine 120 is performed automatically upon receipt of each incoming transaction 22i (e.g., may be triggered by receipt of the incoming transaction), e.g., effectively immediately, or after a programmed delay. For some applications, release subroutine 120 is performed periodically, e.g., after a certain number of incoming transactions have been received, or after a particular duration since the previous performance of the subroutine, and at that time may be performed on all incoming transactions that are currently in quarantine.

For some applications, system 100 releases from quarantine incoming transactions appointed to manual clearance, irrespective of whether manual clearance has yet been performed, e.g., in manual clearance system 200. Moreover, for those such applications in which incoming transactions are automatically released upon appointment to manual clearance, incoming transactions may frequently be released from quarantine before it is practically possible to perform manual clearance. System 100 may therefore advantageously facilitate manual inspection and clearance of incoming transactions (described in more detail hereinbelow) without obstructing the use of those incoming transactions as inputs in outgoing transactions.

In order to appoint a given incoming transaction appropriately to automatic clearance or to manual clearance, system 100 (e.g., release subroutine 120) calculates a score for the incoming transaction in response to one or more factors (described hereinbelow). If the score is above a pre-set threshold, release subroutine 120 appoints the incoming transaction to automatic clearance, typically automatically clearing the incoming transaction. If the score is below the threshold, release subroutine 120 appoints the incoming transaction to manual clearance, typically flagging the incoming transaction for manual clearance by manual clearance system 200. (It is to be understood that the scoring system could be inverted such that above-threshold scores result in appointment to manual clearance, and below-threshold scores result in appointment to automatic clearance.)

As described hereinabove, system 100 (e.g., send function 104 thereof) sends each outgoing transaction 22o to another address on blockchain 10 by recording on blockchain 10 an assignment of the cryptocurrency away from the address of system 100 - i.e., to another address on the blockchain. When sending each outgoing transaction 22o, system 100 (e.g., send function 104 thereof) typically also includes a tag within the assignment of the cryptocurrency away from the address (e.g., for Bitcoin, within a "null data" transaction). This tagging is represented by outgoing transaction 22o being shaded in Fig. 1. Typically, system 100 can identify the presence of the tag in a transaction on blockchain 10, and release subroutine 120 utilizes this information, e.g., as described in more detail hereinbelow. Typically, the tag is encrypted, such that it (i.e., its presence) can be identified only by using an appropriate key, which is typically possessed by system 100. For some applications, other systems and/or entities are also provided with the ability to identify the tag. For some applications, the tag contains data (i.e., in addition to the feature that makes the tag identifiable), such as data about the outgoing transaction. For some applications, the tag is encrypted in a manner that provides multiple permission levels. For example, the encryption may be such that not all systems and/or entities that can identify the tag are able to also read the data contained by the tag. Alternatively or additionally, the encryption may be such that a first group of one or more systems and/or entities can read a first portion of the data contained by the tag, while a second group of one or more systems and/or entities (overlapping or non-overlapping with the first group) can read a second portion of the data contained by the tag.

Typically, the data contained by the tag includes data regarding the outgoing transaction. For example, the data may include the identity of the recipient of the outgoing transaction (or a reference thereto). Alternatively or additionally, the data may include a timestamp. For some applications, (e.g., for an outgoing transaction of cryptocurrency due to purchase of the cryptocurrency), the data may include information about the purchase. For example, the data may include the identity of the purchaser (e.g., if different to the recipient of the outgoing transaction), a timestamp for the purchase, and/or a purchase reference number that can be used to uniquely identify the purchase and/or look up information regarding the purchase in a database.

As described in more detail hereinbelow, system 100 (e.g., release subroutine 120) calculates a score for the incoming transaction in response to one or more factors. Typically, the data contained by the tag further includes score data that is at least partly dependent on this score. For some applications, the score data may be indicative of and/or derived from the score previously calculated for each of the incoming transactions that are (i.e., whose outputs are) the inputs for the one or more outgoing transaction that is being tagged (or data indicative of the score). For some such applications, the contribution of the score of each input toward the score of the outgoing transaction is weighted according to the currency value of that input relative to that of any other inputs. For some applications, system 100 may calculate a score for the outgoing transaction based on the same (or similar) factors as used for calculating the score for each incoming transaction, and the score data contained by the tag may be indicative of the score calculated for the outgoing transaction.

Reference is further made to Fig. 2, which is a schematic illustration of transactions 22 on blockchain 10, in accordance with some applications of the invention. As described hereinabove, system 100 is typically able to identify tagged transactions on blockchain 10, and also read data contained within the tag. As also described hereinabove, for each incoming transaction in quarantine 110, system 100 calculates a score for the incoming transaction in response to one or more factors, appoints above-threshold incoming transactions to automatic clearance, and appoints below-threshold incoming transactions to manual clearance. One such factor is typically a number of upstream transactions that include the tag. It is to be noted that the presence of the tag in a given upstream transaction indicates that that upstream transaction was, at the time it was transacted, an outgoing transaction from system 100. It is hypothesized by the inventors that the given upstream transaction having been an outgoing transaction from system 100 is an indicator of trustworthiness of the given upstream transaction.

For each incoming transaction in quarantine 110, system 100 (e.g., release subroutine 120) typically examines, on blockchain 10, upstream transactions to the incoming transaction. Throughout this patent application (including the specification and the claims), in reference to a given transaction the term "upstream transaction" means a transaction that, on a blockchain, is an input of that given transaction, or is an input of an input of that given transaction, recursively. For example, Fig. 2 shows incoming transaction 22i of Fig. 1, and upstream transactions of transaction 22i. Except for transaction 22i itself, all of the transactions (represented by squares) shown in Fig. 2 are upstream transactions of transaction 22i. Typically, system 100 (e.g., release subroutine 120) examines upstream transactions on blockchain 10 only up to a predefined depth 12 upstream of the incoming transaction - i.e., up to a predefined number of transaction generations preceding the incoming transaction. In Fig. 2, the transactions deeper than depth 12 are shown in phantom, to illustrate that they are not examined. Within the predefined depth, upstream transactions that include the tag (herein "tagged upstream transactions" 22t) are identified by system 100 (e.g., by release subroutine 120). In the example shown in Fig. 2, incoming transaction 22i has four tagged upstream transactions 22t (22tl, 22t2, 22t3, and 22t4), although as discussed hereinbelow, typically not all of these would be identified by system 100.

Typically, each tagged upstream transaction that is identified increases the score assigned to the incoming transaction. For some applications, each tagged upstream transaction contributes equally to the score. However, typically, other determinants affect the contribution of a given tagged upstream transaction, e.g., as will now be described.

For some applications, the contribution of a given tagged upstream transaction to the score is positively weighted according to a currency value of the tagged upstream transaction. For example, a tagged upstream transaction of a greater currency value may contribute more to the score than a comparable tagged upstream transactions of a lesser currency value. For some applications, the contribution may be proportional to the currency value. For some applications, a stepwise relationship may exist, in which one or more thresholds are defined, and the contribution is dependent on whether the currency value is above or below a given threshold. For some applications, the currency value is the value of the tagged upstream transaction in the cryptocurrency. Alternatively, the currency value is the value of the tagged upstream transaction in another currency (e.g., according to an exchange rate at the time that the tagged upstream transaction was transacted, according to an exchange rate at the time that the incoming transaction was transacted, or according to an exchange rate at the time that the score is calculated).

For some applications, the contribution of a given tagged upstream transaction to the score is negatively weighted according to the depth of the tagged upstream transaction from the incoming transaction. For example, tagged upstream transaction 22tl, which has a depth of 1, may increase the score more than tagged upstream transaction 22t2, which has a depth of 2. For example, the contribution of a given tagged upstream transaction to the score may be related to the reciprocal of the depth of that tagged upstream transaction.

As described hereinabove, the tag included in each outgoing transaction typically includes score data. For some applications, when scoring an incoming transaction, the contribution of a given tagged upstream transaction to the score is weighted according to the score data included in the tag of that tagged upstream transaction. This therefore allows previous scoring of transactions that are upstream transactions of a current incoming transaction, to contribute to the score of the current incoming transaction.

For some applications, the contribution of a given tagged upstream transaction toward the score is derived from a combination of more than one of the above determinants. For example, more than one of the above determinants may be a mathematical factor of the contribution of a given tagged upstream transaction. For example, the contribution of a given tagged upstream transaction toward the score may be (or may be derived from) the result of multiplying the currency value of the tagged upstream transaction, the score in the score data of the tagged upstream transaction, and the reciprocal of the depth of the tagged upstream transaction. That is, the contribution may be, or may be derived from, [currency value] x [score data] x [1/depth].

Typically, system 100 follows each transaction path upstream through blockchain 10 until it reaches a tagged upstream transaction, and ignores any transactions that are beyond the tagged upstream transaction. Therefore, in the example shown in Fig. 2, system 100 identifies tagged upstream transaction 22t2, (which is at depth 2) and ignores the two depth 3 transactions that are deeper than (i.e., beyond) tagged upstream transaction 22t2. Similarly, system 100 identifies tagged upstream transaction 22tl, (which is at depth 1) and ignores the two transactions that are deeper than tagged upstream transaction 22tl (one of which is at depth 2, and one of which is at depth 3). It is to be noted that, therefore, although transaction 22t3 is tagged, and is within maximum depth 12, it is typically not identified by system 100 as a tagged upstream transaction. It is hypothesized by the inventors that this path-wise approach increases the efficiency of examining the upstream transactions.

For some applications, depth 12 (i.e. the depth of depth 12) is configurable, e.g., in response to instructions from a regulator. For some applications, the depth that was used to calculate the score is recorded, and may be included in the data contained within a tag, such as the tag of a subsequent outgoing transaction.

For some applications, a list (e.g. a whitelist) of approved addresses (or public keys associated therewith) on the cryptocurrency blockchain is maintained (on system 100, or in a manner that is accessible by system 100), each address corresponding to an approved entity, such as a cryptocurrency exchange, and the list being assigned a reliability factor. For some such applications, if the sender of a given upstream transaction is listed on the list, the upstream transaction contributes to the score of the incoming transaction currently being calculated, e.g., according to the reliability factor of the list. For some such applications, more than one such list exists, each list being assigned a respective reliability factor. For some applications, when scoring an incoming transaction, the reliability factor is used even for upstream transactions that are not tagged. For some applications, when scoring an incoming transaction, the reliability factor is used only for upstream transactions that are not tagged, e.g., as described hereinbelow. For some such applications, the reliability factor is used in a similar way to score data, and the contribution of the upstream transaction toward the score may be similarly weighted according to depth and currency value. For example, the contribution of a given upstream transaction toward the score may be (or may be derived from) the result of multiplying the currency value of the upstream transaction, the reliability factor, and the reciprocal of the depth of the upstream transaction. That is, the contribution may be, or may be derived from, [currency value] x [reliability factor] x [1/depth].

In the example shown in Fig. 2, incoming transaction 22i has, within maximum depth 12, one upstream transaction 22a whose sender is listed as an approved address.

For some applications, system 100 follows each transaction path upstream through blockchain 10 until it reaches an upstream transaction whose sender is listed as an approved address, and ignores any transactions that are beyond that transaction. Therefore, in the example shown in Fig. 2, system 100 identifies, at depth 2, upstream transaction 22a as having an approved sender, and ignores the three depth 3 transactions that are deeper than (i.e., beyond) transaction 22a. Therefore, for such applications, although transaction 22t4 is tagged, and is within maximum depth 12, it is not identified by system 100 as a tagged upstream transaction. It is hypothesized by the inventors that this path-wise approach increases the efficiency of examining the upstream transactions.

For some applications, a combined path-wise approach is used, in which system 100 follows each transaction path upstream through blockchain 10, until it reaches the first of either (i) a tagged upstream transaction, or (ii) an upstream transaction whose sender is listed as an approved address, and ignores any transactions that are beyond that transaction.

Reference is now made to Figs. 3A-D, which are schematic illustrations of a system 200 for use with cryptocurrency, in accordance with some applications of the invention. System 200 is a manual clearance system that facilitates manual clearance (e.g., by human compliance officers) of cryptocurrency transactions. Typically, system 200 is used in combination with system 100, e.g., by being in electronic communication with system 100. For some applications, systems 100 and 200 are interconnected software, which may run on the same hardware. However, it is to be noted that for some applications system 200 may be used independently of system 100.

System 200 is configured to read and write to a compliance blockchain 30. Compliance blockchain 30 is distinct from cryptocurrency blockchain 10. For some applications, compliance blockchain 30 is a private blockchain. For some such applications, compliance blockchain 30 is a private and open blockchain, meaning that only authorized entities may write onto the blockchain, but any entity may read the blockchain. Alternatively, compliance blockchain 30 may be a private and closed blockchain, meaning that only authorized entities may write to the blockchain, and only authorized entities may read the blockchain.

System 200 facilitates compliance entities, such as compliance persons or compliance institutions, contributing to the clearance of cryptocurrency transactions. Each compliance entity is provided with a compliance address 250 on compliance blockchain 30. The compliance address is typically comparable to an address on a cryptocurrency blockchain, and is associated with a public key and a corresponding private key. As described in more detail hereinbelow, the compliance entity contributes to the clearance of a cryptocurrency transaction by applying a digital signature using the compliance entity's private key.

For each cryptocurrency transaction (e.g., for each incoming transaction that system 100 appoints to manual clearance), system 200 facilitates manual clearance by recording an event 32 on compliance blockchain 30, assigning the event to one or more compliance addresses 250 on the compliance blockchain, monitoring whether a compliance rule has been met, and clearing the event only upon the compliance rule being met. Typically, and as described in more detail hereinbelow, the compliance rule includes a signature condition that stipulates a quota of compliance signatures, the quota specifying a number and/or type of compliance signature required. These compliance signatures are digital signatures provided by compliance entities. Typically, and as described in more detail hereinbelow, system 200 designates a given compliance rule to the event responsively to the score of the transaction associated with the event.

System 200 is configured to receive a transaction identifier (ID) 204 associated with an incoming transaction of a cryptocurrency on a cryptocurrency blockchain. Transaction ID 204 is typically provided by system 100 described hereinabove, which is configured to receive such incoming transactions. For example, transaction ID 204 may be provided for a given transaction by release subroutine 120 upon processing of the given transaction by the release subroutine, e.g., upon appointment of the given transaction to manual clearance. System 100 (e.g., release subroutine 120) may generate transaction ID 204 for a given transaction upon processing of the given transaction by the release subroutine, e.g., upon release of the given transaction from quarantine, or upon appointment of the given transaction to manual clearance.

System 200 is also configured to receive a score 202 associated with the transaction ID. Score 202 is typically the score calculated by system 100, as described hereinabove. For applications in which score 202 is the score calculated by system 100, score 202 is therefore typically lower than the threshold set in system 100 because system 100 typically appoints, to manual clearance, only transactions with below-threshold scores.

System 200 records, on compliance blockchain 30, an event 32 associated with the transaction ID 204 received by system 200. In response to the score associated with that transaction ID, system 200 (e.g., an assignor module 210 thereof) assigns, on the compliance blockchain, the event to one or more compliance addresses 250. Also in response to the score, system 200 designates a compliance rule to the event. The compliance rule typically includes a signature condition that stipulates a quota of compliance signatures required to clear the event. For some applications, the compliance rule (e.g., the signature condition thereof) may also have a time component, e.g., stipulating a timeframe within which the quota of compliance signatures must be met.

As described hereinabove, system 200 typically designates the compliance rule in response to the score. As also described hereinabove, the quota typically specifies a number and/or type of compliance signature required. For some applications, compliance entities and the compliance addresses 250 provided thereto are pre-assigned to tiers, e.g., according to seniority and/or authority. For example, a junior compliance person might be pre-assigned to a lower tier (e.g., tier 1 in the example shown), while a senior compliance officer might be pre-assigned to a higher tier (e.g., tier 3 in the example shown). For such applications, the specified type of a compliance signature means the pre-assigned tier of the compliance entity applying the signature. Therefore, for some applications, in response to the score, system 200 designates a compliance rule with a quota that specifies a number of compliance signatures required from each of one or more tiers.

Typically, more demanding compliance rules are designated to events associated with lower-scoring transactions.

System 200 is typically also configured to securely provide each of the compliance entities with at least some information 206 about the incoming transaction (e.g., in addition to the score). Such information may include trade, trader, and/or client information. This providing of the information is represented by double-headed arrow 228. For some applications, and as shown, securely providing this information involves system 200 receiving the information into a data store 220, and providing an interface 222 via which compliance entities, with appropriate permission, may access the information. However, it is to be noted that, in this context, the scope of the term "provide" (including in the specification and the claims) also includes system 200 receiving and directly sending the information to the compliance entities, as well as system 200 managing secure permissioned access to the information without the information necessarily passing through system 200.

Fig. 3A shows system 200 recording an event 32, which is associated with transaction ID 204, on compliance blockchain 30. Fig. 3A also shows system 200 (e.g., assignor module 210 thereof) assigning event 32 to multiple compliance addresses 250 (e.g., in response to score 202). The assignment is indicated by dashed lines connecting the event to the compliance entities. Although not shown in Fig. 3A, system 200 has also designated a compliance rule to event 32 in response to score 202.

Each compliance entity to which event 32 is assigned is made aware of that assignment, and may access the event, the transaction and/or transaction ID associated with the event, and typically information 206 associated with the transaction. Based on this, and optionally other information, the compliance entity may evaluate the transaction, and decide whether or not to digitally sign the event on compliance blockchain 30. Digitally signing the event indicates that the compliance entity approves clearance of the transaction.

At this point, reference is also made to Figs. 4A-B, which are schematic illustrations of a computer software product 300 (e.g., a user interface 302 thereof) that may be provided to each of compliance entities 250, in accordance with some applications of the invention. Product 300 typically comprises a non-transitory computer-readable medium in which program instructions are stored. Product 300 is associated (typically irrevocably associated) with the compliance address (and its public key and corresponding private key) provided to a given compliance entity 250. Product 300 identifies, on the compliance blockchain, events assigned to that compliance address, and makes the compliance entity aware of these events, e.g., by providing an event list 310 in user interface 302. Fig. 4A shows an example of such an event list, including the transaction ID 314 and a date 312, but it will be understood by one of ordinary skill in the art that other display options are possible. In the example shown, each event has an associated "review" button 316, and Fig. 4A shows the compliance entity selecting the second event in the list (indicated by the double -border of the "review" button of that event).

Product 300 then provides a transaction record 320 in user interface 302 (Fig. 4B). Transaction record 420 typically includes the transaction ID associated with the event, as well as other information about the transaction, such as a timestamp, the source of the incoming transaction (typically a cryptocurrency exchange), and/or the value of the transaction. For applications in which product 300 is configured to handle events associated with transactions of different cryptocurrencies, record 320 may also provide the identity of the cryptocurrency of the transaction. The information in transaction record 320 may be at least some of information 206 described hereinabove, e.g., by product 300 communicating with system 200 via interface 222. Alternatively or additionally, at least some of information 206 may be provided independently of product 300.

After reviewing the information provided in record 320 and/or elsewhere, if the compliance entity is satisfied, the compliance entity may then digitally sign the transaction by selecting the "sign" option (indicated by the double-border of the "sign" button). For some applications, if the compliance entity is not satisfied, the compliance entity may "escalate" the event, thereby bringing the event to the attention of a superior. For some applications, the compliance entity may choose to "defer," thereby exiting record 320 without deciding whether or not to sign the event.

For some applications, product 300 enables the compliance entity to view events that the same compliance entity has already signed. For some applications, product 300 enables the compliance entity to view whether such events have also been signed by other compliance entities, and/or whether such events were eventually cleared.

Fig. 3B shows one of the tier-1 compliance addresses to which event 32 was assigned having signed the event (i.e., having applied its digital signature to the event on compliance blockchain 30). This signing is represented by the solid line connecting that particular compliance address to event 32. System 200 (e.g., a clearance subroutine 212 thereof) monitors whether the signature condition of the rule designated to event 32 has been fulfilled. This monitoring is represented by the broken line connecting clearance subroutine 212 to event 32. In the particular example shown, a single tier-1 signature is insufficient to fulfill the signature condition (e.g., does not meet the quota). Therefore, at this point, event 32 is not cleared.

Fig. 3C shows event 32 having been signed by two of the tier-1 compliance addresses to which the event was assigned, and by one of the tier-2 compliance addresses to which event 32 was assigned. Clearance subroutine 212 is shown as continuing to monitor event 32. In the particular example shown, two tier-1 signatures and one tier-2 compliance signature fulfills the signature condition (e.g., meets the quota). Clearance subroutine 212 determines that the signature condition has been fulfilled, and therefore (e.g., automatically) clears event 32, e.g., by recording a clearance label on the compliance blockchain. This is illustrated by the hexagon that represents event 32 becoming dashed.

Typically, clearance subroutine monitors only events that have not yet been cleared, e.g., by ignoring events that include the clearance label. For some applications, the compliance addresses to which an event is assigned are the same (e.g., the same in number and/or type) as those specified in the quota. Alternatively, system 200 may provide some redundancy by assigning an event to more addresses than specified in the quota. In the example shown, system 200 assigns event 32 to five tier-1 compliance addresses, three tier-2 compliance addresses, and two tier-3 compliance addresses, while the quota was met by only two tier-1 signatures and one tier-2 signature.

For some applications, the signature condition may stipulate multiple quotas as alternatives to each other, such that the signature condition is considered to be met if any of the quotas is met. For example, one quota may require a number of lower-tier signatures, while another quota may require a smaller number of higher-tier signatures. That is, system 200 may be configured such that a smaller number of higher-tier signatures can substitute for a larger number of lower- tier signatures. For example, a signature condition may specify that either three tier- 1 signatures or one tier-2 signature is sufficient. (It is to be noted that this provision of alternative quotas may alternatively be viewed as providing a single quota with multiple options specified within.)

For some applications, systems 100 and 200 are configured for use by a regulated entity, such as a bank. For some such applications, a third-party (such as a regulator) is provided access to compliance blockchain 30, and can thereby examine the compliance activities that have occurred thereon, such as clearance of events, and events that have not been cleared. Via the transaction ID, the third-party may examine the cryptocurrency transaction associated with the event.

As described hereinabove, for some applications system 100 releases quarantined incoming transactions upon the incoming transaction being appointed, but irrespective of whether this appointment is to automatic clearance or to manual clearance. As also described hereinabove, for some applications system 100 releases quarantined incoming transactions that are appointed to manual clearance, irrespective of whether manual clearance has yet been performed. For some applications, system 100 is provided with an additional threshold set at a lower score than the threshold used for the automatic/manual clearance decision, and is configured to not release a quarantined incoming transaction scoring below this additional threshold until the quarantined incoming transaction has actually been cleared (e.g., manually cleared). For example, system 100 may be configured to release such a quarantined incoming transaction only upon receipt of a signal from system 200 that the transaction has been manually cleared. Alternatively or additionally, system 100 may be configured to monitor compliance blockchain 30, and to release such a quarantined incoming transaction only upon determining that a clearance label has been recorded on the event associated with the quarantined incoming transaction.

Reference is made to Figs. 5-6, which are a schematic illustration of respective ecosystems 400 that each includes multiple systems 100, in accordance with some applications of the invention. Typically, each system 100 is in electronic communication with a system 200. Fig. 5 shows an ecosystem 400a in which each system 200 serves a single system 100, e.g., with each system 100 transacting in a single cryptocurrency on that cryptocurrency's blockchain, and a dedicated system 200 facilitating manual clearance of incoming transactions received by that system 100. Fig. 6 shows an ecosystem 400b in which a given system 200 may serve more than one system 100, e.g., with multiple systems 100 each transacting in a single cryptocurrency on that cryptocurrency's blockchain, but with a common system 200 facilitating manual clearance of incoming transactions received by any of the systems 100. For example, while systems 200a and 200c are shown as each serving a single system 100, system 200b is shown as serving three systems 100, and system 200d is shown as serving two systems 100. Furthermore, for some applications, a given entity (e.g., bank) may use one or more systems 100. For example, while an entity 410a is shown as using one system 100, an entity 410b and an entity 410c are each shown as using three systems 100, each of which may transact a different cryptocurrency.

For some applications, system 100 is configured so as to be restricted to transact cryptocurrency only with approved entities 402, such as approved exchanges. This is typically achieved by providing system 100 with a list of approved addresses on the cryptocurrency blockchain, and enabling system 100 to receive cryptocurrency from only addresses on the list, and to send cryptocurrency to only addresses on the list. Respective copies of systems 100 and 200 may be provided to respective entities, each restricted to transact cryptocurrency only with the same approved entities 402. Typically, each system 100 is able to identify and read the tags that the other systems 100 include in their outgoing transactions. In this way, an ecosystem 400 is constructed. Each system 100 contributes information to the ecosystem by scoring and tagging transactions, and each system 200 facilitates manual examination and clearance of low-scoring transactions. Furthermore, providing access to compliance blockchain 30 and to the tags on the cryptocurrency blockchain confers transparency to the ecosystem, e.g., for regulators. Thereby, trust of the cryptocurrency within the ecosystem is increased. It is to be noted that the term "computer software product" (including the specification and the claims) means a computer software product comprising a non- transitory computer-readable medium in which program instructions are stored, which instructions, when read by a computer cause the computer to perform certain steps or a certain method.

It will be appreciated by persons skilled in the art that the present invention is not limited to what has been particularly shown and described hereinabove. Rather, the scope of the present invention includes both combinations and subcombinations of the various features described hereinabove, as well as variations and modifications thereof that are not in the prior art, which would occur to persons skilled in the art upon reading the foregoing description.