Detailed Action
Claims 1-14 are pending and are examined.
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Status of Claims
Claims 1, and 8-10 are currently amended.
Response to Remarks
35 U.S.C. § 112(a/b), pertaining to 112(f)
Applicant’s amendments to the claims have overcome all the previous rejections. Accordingly, the previous rejections are withdrawn.
35 U.S.C. § 112(a)
Applicant argues “the specification provides sufficient detail to satisfy the written description requirement of 35 U.S.C. § 112. A person of ordinary skill in the art of computer-implemented transaction processing, particularly in the field of cryptocurrency systems, would understand that "causing a failure" of a transaction in this context means programmatically halting further processing of the transaction, refusing to sign or broadcast the transaction, and/or generating an error or rejection message. . . The use of "causing a failure FL" in these passages, in conjunction with the block diagrams and method steps, would be understood by a person of ordinary skill in the art to mean that the device or method programmatically halts the transaction process, does not generate a digital signature, and does not output a signed transaction for further processing or broadcasting. In the context of transaction processing systems, this is a standard and well-understood approach to "failing" a transaction-by refusing to authorize or sign it, and optionally returning an error or status code indicating the failure.” (Applicant Arguments, 2025-09-30). However, the office is not persuaded that the deficiency has been cured. While the specification states that, if the destination address is not in a fixed list, the secure data processing module is ‘configured to cause a failure FL of the cryptocurrency transaction’ and likewise recites the step of ‘ causing 503 . . . a failure’, these passages merely repeat the claimed functional result without describing what the inventors actually possessed as the implementation of ‘causing a failure’ (e.g. what signal/state/output was halted, what processing was halted, what is communicated back to the host/ electronic calculator, and at what interface boundary the failure occurs). Accordingly, the previous rejections are maintained.
35 U.S.C. § 112(b) – Relative Terminology
Applicant’s amendments to the claims have overcome the previous rejections. Accordingly, the previous rejections are withdrawn.
35 U.S.C. § 112(b) – Lack of Antecedent Basis
Applicant’s amendments to the claims have overcome the previous rejections. Accordingly, the previous rejections are withdrawn.
35 U.S.C. § 101 – Lack of Statutory Subject Matter
Applicant’s amendments to the claims have overcome the previous rejection. Accordingly, the previous rejections are withdrawn.
35 U.S.C. § 101
Remark 1: The Applicant argues “The claims are not directed to "certain methods of organizing human activity," as alleged in the Office Action. Instead, the claims are directed to a specific technological process for managing cryptocurrency transactions using cryptographic techniques and secure hardware modules. The claimed invention does not recite or preempt fundamental economic practices, commercial interactions, or interpersonal relationships, which are the types of activities typically encompassed by the "organizing human activity" grouping of abstract ideas. Rather, the claims are rooted in the operation of computer technology and cryptographic systems, and are not directed to organizing or managing human behavior or business practices.” (Applicant Arguments, 2025-09-30).
Remark 2: The Applicant continues “Here, the claims recite a device and method that utilize a secure module-including a secure data processing module and a secure data storage module (such as a hardware security module)-to deterministically generate and manage private keys, verify destination addresses against a fixed list, and conditionally sign or reject cryptocurrency transactions. These features are not simply a generic application of organizing human activity, but instead integrate cryptographic and hardware-based security mechanisms to address the technical challenge of preventing unauthorized or fraudulent cryptocurrency transfers. The claims, when considered as a whole, provide significantly more than an abstract idea by reciting a particular way to achieve secure transaction authorization and key management, thereby improving the security and reliability of cryptocurrency systems in a manner rooted in computer technology.” (Applicant Arguments, 2025-09-30).
Response to Remark 1: Claim 1 recites and is directed to an abstract idea (e.g. authorizing or denying a cryptocurrency value-transfer transaction based on a policy rule). This is a ‘certain method of organizing human activity’ (e.g. a commercial/financial interaction involving authorization of a transfer) and/or mental process (e.g. evaluation/comparison and decision-making) performed using a computer as a tool. Applicants reliance on ‘cryptographic techniques’ and ‘secure hardware modules’ is unavailing because the claim only invokes them at a high level as conventional tools (e.g. storing private keys and producing a digital signature) to implement the abstract authorization rule, without reciting any specific improvement to the computer security, cryptographic processing, or secure hardware operation.
Response to Remark 2: The claims still recite an abstract idea of authorizing a cryptocurrency transfer by applying a rule, comparing a destination address to a fixed list, and based on that comparison, either failing the transaction or permitting it by signing (i.e. a fundamental commercial/financial authorization practice and/or mental process implemented on a computer). The added recitation that the secure data storage module ‘is a hardware security module’ merely designates a known security component for its conventional role of storing private keys and producing digital signatures, without adding any specific technical mechanism or improvement to computer security, cryptography, HSM operation, or transaction processing beyond what generic processor and conventional HSMs already provide. Accordingly, this contention is unpersuasive.
35 U.S.C. § 102 and § 103
Remark 1: Applicant notes “Claim 1 recites, inter alia, a secure data processing module configured to: (1) check if the relative destination cryptocurrency address associated with an unsigned cryptocurrency transaction belongs to a fixed list of destination cryptocurrency addresses stored in a secure data storage module of the secure module of the device; and (2) in the case the destination address belongs to the fixed list, sign, via a relative digital signature, the unsigned cryptocurrency transaction using a private key of a deterministic list of private keys, thereby generating a signed cryptocurrency transaction. Both the "check" and "sign" operations are performed by the secure module, and the fixed list of destination cryptocurrency addresses is stored within the secure module.” (Applicant Arguments, 2025-09-30). The applicant contends “. . .the present claims are distinguished over Black and the cited combinations because they require that the unsigned transaction is first verified for an authorized destination address and only then signed, with both steps performed within the same secure module. . .”. (Applicant Arguments, 2025-09-30).
Response to Remark 1: Examiner respectfully disagrees, as the cited references (e.g. Black, Sadrizadeh, and Van de Ruit) still teach the amended independent claims, as shown at least in paragraphs 25 and 40 of Sadrizadeh, and as further outlined in paragraph 56-59 of this action. Black discloses ‘the whitelist can include target transaction addresses’ (i.e. an allowlist of permitted destinations), and provides the conditional fail/allow logic in the form of a ‘rejecting purchase’ when not whitelisted, and conversely ‘allowing purchase’ when the destination is whitelisted. Sadrizadeh further teaches implementing private-key generation/storage and signing function inside dedicated secure hardware, teaching that the hardware ‘generates and stores the private key in a secure microcontroller (secure element)’. Accordingly, this contention is unpersuasive.
Claim Interpretation
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The following is a quotation of pre-AIA 35 U.S.C. 112, sixth paragraph:
An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The claims in this application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the specification as it would be understood by one of ordinary skill in the art. The broadest reasonable interpretation of a claim element (also commonly referred to as a claim limitation) is limited by the description in the specification when 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is invoked.
As explained in MPEP § 2181, subsection I, claim limitations that meet the following three-prong test will be interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph:
(A) the claim limitation uses the term “means” or “step” or a term used as a substitute for “means” that is a generic placeholder (also called a nonce term or a non-structural term having no specific structural meaning) for performing the claimed function;
(B) the term “means” or “step” or the generic placeholder is modified by functional language, typically, but not always linked by the transition word “for” (e.g., “means for”) or another linking word or phrase, such as “configured to” or “so that”; and
(C) the term “means” or “step” or the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function.
Use of the word “means” (or “step”) in a claim with functional language creates a rebuttable presumption that the claim limitation is to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites sufficient structure, material, or acts to entirely perform the recited function.
Absence of the word “means” (or “step”) in a claim creates a rebuttable presumption that the claim limitation is not to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is not interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites function without reciting sufficient structure, material or acts to entirely perform the recited function.
Claim limitations in this application that use the word “means” (or “step”) are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action. Conversely, claim limitations in this application that do not use the word “means” (or “step”) are not being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action.
This application includes one or more claim limitations that do not use the word “means,” but are nonetheless being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, because the claim limitation(s) uses a generic placeholder that is coupled with functional language without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier. Such claim limitation(s) is/are:
Regarding claims 1, 3, 7, 8, 10, 12, and 14, the term “data processing unit” acts as a generic placeholder for the term “means”. The generic placeholder is modified by functional language “configured to receive …” in claim 1, “configured to send …” in claim 3, “configured to receive …” in claim 7, “configured to receive …” in claim 8, “receiving …” in claim 10, “sending …” in claim 12, and “receiving …” in claim 14. Further, the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function. The structure corresponding to the “data processing unit” may be found in at least paragraphs 0052 of Applicant’s Pre-Grant Publication (e.g., “microcontroller or microprocessor”).
Regarding claims 1, 6, 8, 10, and 13, the term “secure data processing module” act as generic placeholders for the term “means”. The generic placeholder is modified by functional language “being configured to: check … cause a failure … sign …” in claim 1, “being configured to check … being configured … to cause a failure … being configured to check …” in claim 6, “being configured to: check … cause a failure … sign …” in claim 8, “checking … causing … a failure … signing …” in claim 10, and “checking … causing … a failure … ” in claim 13. Further, the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function. The structure corresponding to the “secure data processing module” may be found in at least paragraphs 0061 of Applicant’s Pre-Grant Publication (e.g., “microcontroller or microprocessor”).
Because this/these claim limitation(s) is/are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, it/they is/are being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof.
If applicant does not intend to have this/these limitation(s) interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, applicant may: (1) amend the claim limitation(s) to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph (e.g., by reciting sufficient structure to perform the claimed function); or (2) present a sufficient showing that the claim limitation(s) recite(s) sufficient structure to perform the claimed function so as to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-5 and 8-12 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
Claims 1-5:
Step 1
Claims 1-5 are directed to a computer-implemented device (i.e., machine, and manufacture). Therefore, these claims fall within the four statutory categories of invention, and thus must be further analyzed at Step 2A to determine if the claims are directed to a judicial exception (See MPEP 2106.03, subsection II).
Step 2A Prong One
In Prong One examiners evaluate whether the claim recites a judicial exception, i.e., whether a law of nature, natural phenomenon, or abstract idea is set forth or described in the claim. Claim 1 recites (i.e., sets forth or describes) an abstract idea of transaction signing/processing based on a fixed list of destination addresses. Specifically, but for the additional elements, the claim under its broadest reasonable interpretation recites limitations grouped within the “certain methods of organizing human activity” grouping of abstract ideas. The certain method of organizing human activity grouping is used to describe fundamental economic principles or practices, commercial or legal interactions, and managing personal behavior or relationships or interactions between people. Fundamental economic principles or practices are relating to the economy and commerce, or recite hedging, insurance, and mitigating risks. Commercial or legal interactions recite agreements in the form of contracts, legal obligations, advertising, marketing or sales activities or behaviors, and business relations. Managing personal behavior or relationships or interactions between people recite social activities, teaching, and following rules or instructions. See MPEP § 2106.04(a)(2), subsection II. Also, but for the additional elements, the claim under its broadest reasonable interpretation recites limitations grouped within the “mental processes” grouping of abstract ideas. The mental processes abstract idea grouping is defined as concepts performed in the human mind, and examples of mental processes recite observations, evaluations, judgments, and opinions. Claims recite a mental process when they recite limitations that can practically be performed in the human mind, with or without the use of a physical aid. The use of a physical aid to help perform a mental step does not negate the mental nature of the limitation, but simply accounts for variations in memory capacity from one person to another. Further, claims can recite a mental process even if they are claimed as being performed on a computer. See MPEP § 2106.04(a)(2), subsection III. The claim limitations reciting the abstract ideas are grouped within the “certain methods of organizing human activity” and “mental processes” grouping of abstract ideas because the limitations recite fundamental economic principles or practices, as they recite mitigating risk, commercial or legal interactions, as they recite sales activities or behaviors, and concepts that can practically be performed in the human mind, with or without the use of a physical aid. More specifically, the following underlined claim elements recite abstract ideas while the non-underlined claim elements recite additional elements according to MPEP 2106.04(a).
A device for managing cryptocurrency transactions, comprising:
a data processing unit configured to receive an unsigned cryptocurrency transaction, said unsigned cryptocurrency transaction having associated a relative destination cryptocurrency address;
a secure module, operatively connected to the data processing unit, comprising:
a secure data processing module;
a secure data storage module that is a hardware security module operatively connected to the secure data processing module, said secure data storage module being configured to store:
a deterministic list of private keys used to sign the cryptocurrency transactions via digital signature;
a fixed list of destination cryptocurrency addresses;
said secure data processing module of the secure module being configured to:
check if the relative destination cryptocurrency address associated to the unsigned cryptocurrency transaction belongs to the fixed list of destination cryptocurrency addresses stored in the secure data storage module of the secure module of the device;
in the case the relative destination cryptocurrency address associated to the unsigned cryptocurrency transaction does not belong to the fixed list of destination cryptocurrency addresses stored in the secure data storage module of the secure module of the device, cause a failure of the unsigned cryptocurrency transaction;
in the case the relative destination cryptocurrency address associated to the unsigned cryptocurrency transaction belongs to the fixed list of destination cryptocurrency addresses stored in the secure data storage module of the secure module of the device, sign, via a relative digital signature, the unsigned cryptocurrency transaction using a private key of said deterministic list of private keys, generating a signed cryptocurrency transaction.
Step 2A Prong Two
In Prong Two, examiners evaluate whether the claim as a whole integrates the exception into a practical application of that exception. A claim that integrates a judicial exception into a practical application will apply, rely on, or use the judicial exception in a manner that imposes a meaningful limit on the judicial exception, such that the claim is more than a drafting effort designed to monopolize the judicial exception. Here, claim 1 as a whole, looking at the identified additional elements individually and in combination, does not integrate the judicial exception into a practical application. First, the non-underlined additional elements merely serve as a tool to perform the abstract idea (MPEP § 2106.05(f)). Further, the additional element “cryptocurrency” generally links the use of the judicial exception to a particular technological environment, that being of cryptocurrency transactions (MPEP § 2106.05(h)). Additionally, regarding the specification and claims, there is no improvement in the functioning of a computer or an improvement to other technology or technical field present (MPEP §§ 2106.04(d)(1) and 2106.05(a)), there is no applying or using the judicial exception to effect a particular treatment or prophylaxis for a disease or medical condition present (MPEP § 2106.04(d)(2)), there is no implementing the judicial exception with or using the judicial exception in conjunction with a particular machine or manufacture that is integral to the claim present (MPEP § 2106.05(b)), there is no effecting a transformation or reduction of a particular article to a different state or thing present (MPEP § 2106.05(c)), and there is no applying or using the judicial exception in some other meaningful way beyond generally linking the use of the judicial exception to a particular technological environment present, such that the claim as a whole is more than a drafting effort designed to monopolize the exception (MPEP § 2106.05(e)). Thus, the claim as a whole is directed to a judicial exception and thus requires further analysis at Step 2B to determine if the claim as a whole, amounts to significantly more than the exception itself (See MPEP 2106.04, subsection II).
Step 2B
Step 2B determines whether the claim as a whole amount to significantly more than the exception itself. Evaluating additional elements to determine whether they amount to an inventive concept requires considering them both individually and in combination to ensure that they amount to significantly more than the judicial exception itself. Here, the additional elements, taken individually and in combination, do not result in claim 1, as a whole, amounting to significantly more than the judicial exception. As discussed previously with respect to Step 2A, the additional elements merely serve as a tool to perform an abstract idea, and generally links the use of the judicial exception to a particular technological environment. Thus, there is no inventive concept in the claim and thus the claim is not eligible, warranting a rejection for lack of subject matter eligibility and concluding the eligibility analysis.
Dependent Claims:
Claims 2-5 have also been analyzed. However, the subject matter of these claims also fails to recite patent eligible subject matter for the following reasons:
Claim 2 recites the following underlined claim elements as abstract ideas while the non-underlined claim elements recite additional elements according to MPEP 2106.04(a). The additional element is insignificant extra-solution activity as it is mere data gathering (See MPEP 2106.05(g)) and well-understood, routine, and conventional activity as it is “receiving or transmitting data over a network” (See MPEP 2106.05(d)(II)).
wherein the device is configured to be operatively connected to an electronic calculator of a user, said electronic calculator being configured to be used by the user to send the received unsigned cryptocurrency transaction to the device.
Claim 3 recites the following underlined claim elements as abstract ideas while the non-underlined claim elements recite additional elements according to MPEP 2106.04(a). The additional element is insignificant extra-solution activity as it is mere data gathering (See MPEP 2106.05(g)) and well-understood, routine, and conventional activity as it is “receiving or transmitting data over a network” (See MPEP 2106.05(d)(II)).
wherein the data processing unit of the device is further configured to send to the electronic calculator of the user the signed cryptocurrency transaction.
Claim 4 recites the following underlined claim elements as abstract ideas while the non-underlined claim elements recite additional elements according to MPEP 2106.04(a). The non-underlined additional elements fail to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP § 2106.05(f)).
wherein the device is a portable device configured to be operatively connected to the electronic calculator of the user via a universal serial bus connection.
Claim 5 recites the following underlined claim elements as abstract ideas while the non-underlined claim elements recite additional elements according to MPEP 2106.04(a). The non-underlined additional elements fail to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP § 2106.05(f)).
wherein the device is embedded within the electronic calculator of the user.
Claims 8-9:
Step 1
Claims 8-9 are directed to a computer-implemented system (i.e., machine, and manufacture). Therefore, these claims fall within the four statutory categories of invention, and thus must be further analyzed at Step 2A to determine if the claims are directed to a judicial exception (See MPEP 2106.03, subsection II).
Step 2A Prong One
In Prong One examiners evaluate whether the claim recites a judicial exception, i.e., whether a law of nature, natural phenomenon, or abstract idea is set forth or described in the claim. Claim 8 recites (i.e., sets forth or describes) an abstract idea of transaction signing/processing based on a fixed list of destination addresses. Specifically, but for the additional elements, the claim under its broadest reasonable interpretation recites limitations grouped within the “certain methods of organizing human activity” grouping of abstract ideas. The certain method of organizing human activity grouping is used to describe fundamental economic principles or practices, commercial or legal interactions, and managing personal behavior or relationships or interactions between people. Fundamental economic principles or practices are relating to the economy and commerce, or recite hedging, insurance, and mitigating risks. Commercial or legal interactions recite agreements in the form of contracts, legal obligations, advertising, marketing or sales activities or behaviors, and business relations. Managing personal behavior or relationships or interactions between people recite social activities, teaching, and following rules or instructions. See MPEP § 2106.04(a)(2), subsection II. Also, but for the additional elements, the claim under its broadest reasonable interpretation recites limitations grouped within the “mental processes” grouping of abstract ideas. The mental processes abstract idea grouping is defined as concepts performed in the human mind, and examples of mental processes recite observations, evaluations, judgments, and opinions. Claims recite a mental process when they recite limitations that can practically be performed in the human mind, with or without the use of a physical aid. The use of a physical aid to help perform a mental step does not negate the mental nature of the limitation, but simply accounts for variations in memory capacity from one person to another. Further, claims can recite a mental process even if they are claimed as being performed on a computer. See MPEP § 2106.04(a)(2), subsection III. The claim limitations reciting the abstract ideas are grouped within the “certain methods of organizing human activity” and “mental processes” grouping of abstract ideas because the limitations recite fundamental economic principles or practices, as they recite mitigating risk, commercial or legal interactions, as they recite sales activities or behaviors, and concepts that can practically be performed in the human mind, with or without the use of a physical aid. More specifically, the following underlined claim elements recite abstract ideas while the non-underlined claim elements recite additional elements according to MPEP 2106.04(a).
A system comprising:
a device for managing cryptocurrency transactions, comprising:
a data processing unit configured to receive an unsigned cryptocurrency transaction, said unsigned cryptocurrency transaction having associated a relative destination cryptocurrency address;
a secure module, operatively connected to the data processing unit, comprising:
a secure data processing module;
a secure data storage module that is a hardware security module operatively connected to the secure data processing module, said secure data storage module being configured to store:
a deterministic list of private keys used to sign the cryptocurrency transactions via digital signature;
a fixed list of destination cryptocurrency addresses;
said secure data processing module of the secure module being configured to:
check if the relative destination cryptocurrency address associated to the unsigned cryptocurrency transaction belongs to the fixed list of destination cryptocurrency addresses stored in the secure data storage module of the secure module of the device;
in the case the relative destination cryptocurrency address associated to the unsigned cryptocurrency transaction does not belong to the fixed list of destination cryptocurrency addresses stored in the secure data storage module of the secure module of the device, cause a failure of the unsigned cryptocurrency transaction;
in the case the relative destination cryptocurrency address associated to the unsigned cryptocurrency transaction belongs to the fixed list of destination cryptocurrency addresses stored in the secure data storage module of the secure module of the device, sign, via a relative digital signature, the unsigned cryptocurrency transaction using a private key of said deterministic list of private keys, generating a signed cryptocurrency transaction,
wherein the device is configured to be operatively connected to an electronic calculator of a user,
said electronic calculator being configured to be used by the user to:
send the unsigned cryptocurrency transaction to the device; and
broadcast a signed cryptocurrency transaction received from the device to a cryptocurrency communication network.
Step 2A Prong Two
In Prong Two, examiners evaluate whether the claim as a whole integrates the exception into a practical application of that exception. A claim that integrates a judicial exception into a practical application will apply, rely on, or use the judicial exception in a manner that imposes a meaningful limit on the judicial exception, such that the claim is more than a drafting effort designed to monopolize the judicial exception. Here, claim 8 as a whole, looking at the identified additional elements individually and in combination, does not integrate the judicial exception into a practical application. First, the non-underlined additional elements merely serve as a tool to perform the abstract idea (MPEP § 2106.05(f)). Further, the additional element “cryptocurrency” generally links the use of the judicial exception to a particular technological environment, that being of cryptocurrency transactions (MPEP § 2106.05(h)). Additionally, regarding the specification and claims, there is no improvement in the functioning of a computer or an improvement to other technology or technical field present (MPEP §§ 2106.04(d)(1) and 2106.05(a)), there is no applying or using the judicial exception to effect a particular treatment or prophylaxis for a disease or medical condition present (MPEP § 2106.04(d)(2)), there is no implementing the judicial exception with or using the judicial exception in conjunction with a particular machine or manufacture that is integral to the claim present (MPEP § 2106.05(b)), there is no effecting a transformation or reduction of a particular article to a different state or thing present (MPEP § 2106.05(c)), and there is no applying or using the judicial exception in some other meaningful way beyond generally linking the use of the judicial exception to a particular technological environment present, such that the claim as a whole is more than a drafting effort designed to monopolize the exception (MPEP § 2106.05(e)). Further, the additional element “wherein the device is configured to be operatively connected to an electronic calculator of a user, said electronic calculator being configured to be used by the user to send the received unsigned cryptocurrency transaction to the device; an electronic calculator of a user, said device being configured to be operatively connected to said electronic calculator, said electronic calculator being configured to be used by the user to: send the unsigned cryptocurrency transaction to the device; and broadcast a signed cryptocurrency transaction received from the device to a cryptocurrency communication network” amounts to mere data gathering, which is a form of insignificant extra-solution activity (MPEP § 2106.05(g)). Thus, the claim as a whole is directed to a judicial exception and thus requires further analysis at Step 2B to determine if the claim as a whole, amounts to significantly more than the exception itself (See MPEP 2106.04, subsection II).
Step 2B
Step 2B determines whether the claim as a whole amount to significantly more than the exception itself. Evaluating additional elements to determine whether they amount to an inventive concept requires considering them both individually and in combination to ensure that they amount to significantly more than the judicial exception itself. Here, the additional elements, taken individually and in combination, do not result in claim 8, as a whole, amounting to significantly more than the judicial exception. As discussed previously with respect to Step 2A, the additional elements merely serve as a tool to perform an abstract idea, and generally links the use of the judicial exception to a particular technological environment. A conclusion that an additional element is insignificant extra-solution activity in Step 2A should be re-evaluated in Step 2B to determine if it is more than what is well-understood, routine, conventional activity in the field. MPEP 2106.05(d)(II) indicates that “receiving or transmitting data over a network” is a well-understood, routine, conventional function when it is claimed in a merely generic manner (as it is here). Accordingly, a conclusion that the additional elements amounting to mere data gathering are well-understood, routine, conventional activity is supported under Berkheimer Option 2. Thus, there is no inventive concept in the claim and thus the claim is not eligible, warranting a rejection for lack of subject matter eligibility and concluding the eligibility analysis.
Dependent Claims:
Claim 9 has also been analyzed. However, the subject matter of this claim also fails to recite patent eligible subject matter for the following reasons:
Claim 9 recites the following underlined claim elements as abstract ideas while the non-underlined claim elements recite additional elements according to MPEP 2106.04(a). The claim recites the abstract idea of transaction authorization. In other words, it recites limitations grouped within the “certain methods of organizing human activity” and “mental processes” grouping of abstract ideas. The non-underlined additional elements fail to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP § 2106.05(f)).
wherein the electronic calculator of the user is configured to receive via a data communication network an authorized unsigned cryptocurrency transaction authorized by at least one third-party authority.
Claims 10-12:
Step 1
Claims 10-12 are directed to a computer-implemented method (i.e., process). Therefore, these claims fall within the four statutory categories of invention, and thus must be further analyzed at Step 2A to determine if the claims are directed to a judicial exception (See MPEP 2106.03, subsection II).
Step 2A Prong One
In Prong One examiners evaluate whether the claim recites a judicial exception, i.e., whether a law of nature, natural phenomenon, or abstract idea is set forth or described in the claim. Claim 10 recites (i.e., sets forth or describes) an abstract idea of transaction signing/processing based on a fixed list of destination addresses. Specifically, but for the additional elements, the claim under its broadest reasonable interpretation recites limitations grouped within the “certain methods of organizing human activity” grouping of abstract ideas. The certain method of organizing human activity grouping is used to describe fundamental economic principles or practices, commercial or legal interactions, and managing personal behavior or relationships or interactions between people. Fundamental economic principles or practices are relating to the economy and commerce, or recite hedging, insurance, and mitigating risks. Commercial or legal interactions recite agreements in the form of contracts, legal obligations, advertising, marketing or sales activities or behaviors, and business relations. Managing personal behavior or relationships or interactions between people recite social activities, teaching, and following rules or instructions. See MPEP § 2106.04(a)(2), subsection II. Also, but for the additional elements, the claim under its broadest reasonable interpretation recites limitations grouped within the “mental processes” grouping of abstract ideas. The mental processes abstract idea grouping is defined as concepts performed in the human mind, and examples of mental processes recite observations, evaluations, judgments, and opinions. Claims recite a mental process when they recite limitations that can practically be performed in the human mind, with or without the use of a physical aid. The use of a physical aid to help perform a mental step does not negate the mental nature of the limitation, but simply accounts for variations in memory capacity from one person to another. Further, claims can recite a mental process even if they are claimed as being performed on a computer. See MPEP § 2106.04(a)(2), subsection III. The claim limitations reciting the abstract ideas are grouped within the “certain methods of organizing human activity” and “mental processes” grouping of abstract ideas because the limitations recite fundamental economic principles or practices, as they recite mitigating risk, commercial or legal interactions, as they recite sales activities or behaviors, and concepts that can practically be performed in the human mind, with or without the use of a physical aid. More specifically, the following underlined claim elements recite abstract ideas while the non-underlined claim elements recite additional elements according to MPEP 2106.04(a).
A method for managing cryptocurrency transactions, the method comprising:
receiving, by a data processing unit of a device for managing cryptocurrency transactions, an unsigned cryptocurrency transaction, said unsigned cryptocurrency transaction having associated a relative destination cryptocurrency address;
checking, by a secure data processing module of a secure module of the device, if the relative destination cryptocurrency address associated to the unsigned cryptocurrency transaction belongs to a fixed list of destination cryptocurrency addresses stored in a secure data storage module that is a hardware security module of the secure module of the device;
in the case the relative destination cryptocurrency address associated to the unsigned cryptocurrency transaction does not belong to the fixed list of destination cryptocurrency addresses stored in the secure data storage module of the secure module of the device, causing, by the secure data processing module of the secure module of the device, a failure of the unsigned cryptocurrency transaction;
in the case the relative destination cryptocurrency address associated to the unsigned cryptocurrency transaction belongs to the fixed list of destination cryptocurrency addresses stored in the secure data storage module of the secure module of the device, signing, by the secure data processing module of the secure module of the device, via a relative digital signature, the unsigned cryptocurrency transaction using a private key of a deterministic list of private keys stored in the secure data storage module of the secure module of the device, generating a signed cryptocurrency transaction.
Step 2A Prong Two
In Prong Two, examiners evaluate whether the claim as a whole integrates the exception into a practical application of that exception. A claim that integrates a judicial exception into a practical application will apply, rely on, or use the judicial exception in a manner that imposes a meaningful limit on the judicial exception, such that the claim is more than a drafting effort designed to monopolize the judicial exception. Here, claim 10 as a whole, looking at the identified additional elements individually and in combination, does not integrate the judicial exception into a practical application. First, the non-underlined additional elements merely serve as a tool to perform the abstract idea (MPEP § 2106.05(f)). Further, the additional element “cryptocurrency” generally links the use of the judicial exception to a particular technological environment, that being of cryptocurrency transactions (MPEP § 2106.05(h)). Additionally, regarding the specification and claims, there is no improvement in the functioning of a computer or an improvement to other technology or technical field present (MPEP §§ 2106.04(d)(1) and 2106.05(a)), there is no applying or using the judicial exception to effect a particular treatment or prophylaxis for a disease or medical condition present (MPEP § 2106.04(d)(2)), there is no implementing the judicial exception with or using the judicial exception in conjunction with a particular machine or manufacture that is integral to the claim present (MPEP § 2106.05(b)), there is no effecting a transformation or reduction of a particular article to a different state or thing present (MPEP § 2106.05(c)), and there is no applying or using the judicial exception in some other meaningful way beyond generally linking the use of the judicial exception to a particular technological environment present, such that the claim as a whole is more than a drafting effort designed to monopolize the exception (MPEP § 2106.05(e)). Thus, the claim as a whole is directed to a judicial exception and thus requires further analysis at Step 2B to determine if the claim as a whole, amounts to significantly more than the exception itself (See MPEP 2106.04, subsection II).
Step 2B
Step 2B determines whether the claim as a whole amount to significantly more than the exception itself. Evaluating additional elements to determine whether they amount to an inventive concept requires considering them both individually and in combination to ensure that they amount to significantly more than the judicial exception itself. Here, the additional elements, taken individually and in combination, do not result in claim 10, as a whole, amounting to significantly more than the judicial exception. As discussed previously with respect to Step 2A, the additional elements merely serve as a tool to perform an abstract idea, and generally links the use of the judicial exception to a particular technological environment. Thus, there is no inventive concept in the claim and thus the claim is not eligible, warranting a rejection for lack of subject matter eligibility and concluding the eligibility analysis.
Dependent Claims:
Claims 11-12 have also been analyzed. However, the subject matter of these claims also fails to recite patent eligible subject matter for the following reasons:
Claim 11 recites the following underlined claim elements as abstract ideas while the non-underlined claim elements recite additional elements according to MPEP 2106.04(a). The additional element is insignificant extra-solution activity as it is mere data gathering (See MPEP 2106.05(g)) and well-understood, routine, and conventional activity as it is “receiving or transmitting data over a network” (See MPEP 2106.05(d)(II)).
sending, by an electronic calculator of a user, the received unsigned cryptocurrency transaction to the device.
Claim 12 recites the following underlined claim elements as abstract ideas while the non-underlined claim elements recite additional elements according to MPEP 2106.04(a). The additional element is insignificant extra-solution activity as it is mere data gathering (See MPEP 2106.05(g)) and well-understood, routine, and conventional activity as it is “receiving or transmitting data over a network” (See MPEP 2106.05(d)(II)).
sending, by the data processing unit of the device, the signed cryptocurrency transaction to the electronic calculator of the user.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim(s) 1-4, and 6-14 are is rejected under 35 U.S.C. 103 as being unpatentable over Black et al. (US 20200051072A1) (hereinafter “Black”) in view of Sadrizadeh et al. (US 20190251524) (hereinafter “Sadrizadeh”)
As per Claim 1, Black teaches:
A device for managing cryptocurrency transactions, comprising: a data processing unit configured to receive an unsigned cryptocurrency transaction, said unsigned cryptocurrency transaction having associated a relative destination cryptocurrency address; (“Method 300 begins with receiving an intent to purchase a token into a target transaction address from a remotely located computing device (block 302). In some examples, the intent to purchase a token includes the remotely located computing device sending a submission of a request or some other type of communication to communicate interest in purchasing the token. In some examples, the token represents at least one of a security, a currency, a commodity, a bond, a fund, or a combination thereof. In some examples, the token is implemented using a smart contract. For example, the token is a self-regulating token implemented as an extension of Ethereum Request for Comment 20 (ERC20).” (Para. 0045)
a secure module, operatively connected to the data processing unit, comprising: a secure data processing module; a secure data storage module operatively connected to the secure data processing module, said secure data storage module . . . being configured to store: a deterministic list of private keys used to sign the cryptocurrency transactions via digital signature; (“the potential customer provides identity data to the issuer of the token or other entity in order to be considered for the whitelist. Identity data may include a customer's name, date of birth, driver's license number and expiration date, address, phone number(s), email address(es), social security number, employment information, and/or income. In some examples, the customer also provides payment data to the asset exchange 104 or other entity in order to be considered for the whitelist. Payment data may include bank account information, credit card information, contactless payment data (e.g., Apple Pay® or Android Pay® user name and passwords), existing cryptocurrency wallet key, and/or other payment processing information (e.g., user name and password for PayPal® or WhatsApp®). The customer device 102 may transmit the identity data and the payment data associated with the customer to the issuer of the token or other entity using a secure transfer protocol, for example.” (Para. 0038); “Method 300 optionally proceeds with rejecting purchase of the token into the target transaction address when the at least one of the target transaction address or the target public key associated with the target transaction address is not both: (1) associated with the target transaction address associated with the private key and (2) whitelisted to purchase the token (block 312). In some examples, this includes sending a failure message to the remotely located computing device. The message can identify which requirement was the point of failure for the transaction. For example, when the customer's transaction address or public key is not whitelisted, the message can notify the customer that the target transaction address and the target public key associated with the target transaction address are not on the appropriate whitelist. In such examples, the message may also include directions regarding how to be added to the required whitelist (such as, for example, using a process similar to that described above with respect to FIG. 1). When the transaction address or the public key is not associated with the private key, the message can notify the customer that the target transaction address and the target public key associated with the target transaction address are not associated with the private key.” (Para. 0053)
a fixed list of destination cryptocurrency addresses; (“The whitelist(s) can be updated periodically to ensure that the customers associated with the public keys or transaction addresses comply with the particular rules for the whitelist. The whitelist(s) can be modified over time based on a number of factors. For example, the status of an individual or entity that qualifies as an “accredited investor” may change over time based on the value of assets owned, net worth, or income level of individual or entity. Another example is where a particular regulation that the whitelist is intended to implement has time-based restrictions. For example, Regulation S limits the sale of certain securities during the first 40 days following the commencement of an offer, so after the first 40 days, additional addresses may be whitelisted that were previously ineligible due to the location of the purchaser/seller. Accordingly, in some examples, the whitelist is modified or implemented using an oracle or other entity that operates as a data feed for providing verified information to the smart contract for the token.” (Para. 0052); “Since the token is a tradable asset, the initial purchaser of the token may desire to sell or exchange the token with a subsequent purchaser. As discussed above, a problem can arise when a subsequent purchaser of a regulated token with whitelisting functionality tries to withdraw the token. In particular, the withdrawal of the regulated token may be restricted to certain public keys or transaction addresses included in a smart contract implementing the whitelist. If the subsequent purchaser's public key or transaction address is not on the necessary whitelist(s), then the subsequent purchaser will not be able to withdraw the token, e.g., for fiat currency, cryptocurrency, services, etc.” (Para. 0043).
said secure data processing module of the secure module being configured to: check if the relative destination cryptocurrency address associated to the unsigned cryptocurrency transaction belongs to the fixed list of destination cryptocurrency addresses stored in the secure data storage module of the secure module of the device; in the case the relative destination cryptocurrency address associated to the unsigned cryptocurrency transaction does not belong to the fixed list of destination cryptocurrency addresses stored in the secure data storage module of the secure module of the device, cause a failure of the unsigned cryptocurrency transaction; in the case the relative destination cryptocurrency address associated to the unsigned cryptocurrency transaction belongs to the fixed list of destination cryptocurrency addresses stored in the secure data storage module of the secure module of the device, sign, via a relative digital signature, the unsigned cryptocurrency transaction using a private key of said deterministic list of private keys, generating a signed cryptocurrency transaction. (“Method 300 proceeds with allowing purchase of the token into the target transaction address when the at least one of the target transaction address or the target public key associated with the target transaction address is both: (1) associated with the target transaction address associated with the private key and (2) whitelisted to purchase the token (block 314). If the purchase of the token is allowed, the transfer of the tokens to the target address will be executed upon receipt of the agreed upon payment..” (Para. 0054); “In some examples, method 300 optionally proceeds with communicating data to the remotely located computing device to be signed by the remotely located computing device using the private key to create the signed data in response to the intent to purchase a token into a target transaction address being received from the remotely located computing device (block 303). For example, the data sent to the remotely located computing device can include a string that is to be modified by the computing device with the private key.” (Para. 0046).
Black does not disclose:
• “that is a hardware security module” (claim 1).
However, as per Claim 1, Sadrizadeh in the analogous art of blockchain transaction security, teaches: “that is a hardware security module”. (See “The hardware encryption device 22 generates and stores the private key in a secure microcontroller (secure element).” (Para. 0025); “The Secure Element used in the hardware encryption device 22 is also talking on a TLS secured SPI bus only to the ARM processor. This thwarts any replay attacks. During the initial hardware encryption device 22 initialization process in manufacturing, the ARM processor generates a unique random key which is then sent to the Secure Element. The Secure Element stores this key and from that point on will require all messages over the SPI bus to be signed by that unique immutable key. This protects from an attack where the Secure Element is removed from the original hardware encryption device 22 and is then placed in another hardware key in an attempt to bypass the biometric authentication.” (Para. 0040)
It would have been obvious to one of ordinary skill in the art before the effective filing date to combine the method of Black, which controls whether a cryptocurrency transaction proceeds based on destination-address authorization logic and related signing flow, with the technique of Sadrizadeh, which teaches generating/storing private keys in a secure microcontroller/secure element and using that protected hardware to perform signing, to include implementing private-key storage and signing operations within a hardware security module. Therefore, the incentives of improving private-key isolation and reducing exposure of signing keys to compromise in the host processor/software environment provided a reason to make an adaptation, and the invention resulted from application of the prior knowledge in a predictable manner.
As per Claim 2, Black teaches:
The device of claim 1, wherein the device is configured to be operatively connected to an electronic calculator of a user, said electronic calculator being configured to be used by the user to send the received unsigned cryptocurrency transaction to the device. (“Method 300 begins with receiving an intent to purchase a token into a target transaction address from a remotely located computing device (block 302). In some examples, the intent to purchase a token includes the remotely located computing device sending a submission of a request or some other type of communication to communicate interest in purchasing the token. In some examples, the token represents at least one of a security, a currency, a commodity, a bond, a fund, or a combination thereof. In some examples, the token is implemented using a smart contract. For example, the token is a self-regulating token implemented as an extension of Ethereum Request for Comment 20 (ERC20). In some examples, the token is self-regulating in the sense that it implements commands for compliance as a security or an asset under SEC regulations.” (Para. 0045); “the customer device 102 may be a mobile device, e.g., using the Android® or iOS® operating systems. A customer may download, to the customer device 102, an application corresponding to the asset exchange 104. The application may present a user interface on the customer device 102, and the customer may provide input using the user interface. Based at least in part on the user input, the application on the customer device 102 may send and receive instructions and/or other data to the asset exchange 104. In some examples, the application on the customer device 102 may only communicate directly with the asset exchange 104, which communicates with other devices in the system 100, i.e., the asset exchange 104 may be a gateway to other devices in the system 100. Alternatively, the application on the customer device 102 may communicate directly with the asset exchange 104 and/or other devices in the system 100.” (Para. 0023).
As per Claim 3, Black teaches:
The device of claim 2, wherein the data processing unit of the device is further configured to send to the electronic calculator of the user the signed cryptocurrency transaction. (“Method 300 proceeds with allowing purchase of the token into the target transaction address when the at least one of the target transaction address or the target public key associated with the target transaction address is both: (1) associated with the target transaction address associated with the private key and (2) whitelisted to purchase the token (block 314). If the purchase of the token is allowed, the transfer of the tokens to the target address will be executed upon receipt of the agreed upon payment.” (Para. 0054); “the examples described herein implement validation/verification of a particular transaction address being on the whitelist before allowing a transaction of the token to occur. In one example, the verification can be implemented by an asset exchange (such as, for example, asset exchange 104). The verification includes requiring a potential purchaser of the regulated tokens (that require the user to be whitelisted) to send signed data to a system, where the data is signed with a private key corresponding to the particular transaction address the potential purchaser wants to transact into. The asset exchange verifies that the data was signed with the private key that corresponds to the transaction address the user indicated was the intended destination for the regulated token and that the transaction address is on the appropriate whitelist. In some examples, the asset exchange could verify that the data was signed with the private key that corresponds to a public key associated with the transaction address. The asset exchange allows the transfer to proceed when the private key corresponds to the target transaction address or target public key and the target transaction address or the target public key is on the whitelist. If these conditions are not met, the asset exchange rejects or otherwise denies the transfer.” (Para. 0016); “Method 300 optionally proceeds with rejecting purchase of the token into the target transaction address when the at least one of the target transaction address or the target public key associated with the target transaction address is not both: (1) associated with the target transaction address associated with the private key and (2) whitelisted to purchase the token (block 312). In some examples, this includes sending a failure message to the remotely located computing device. The message can identify which requirement was the point of failure for the transaction. For example, when the customer's transaction address or public key is not whitelisted, the message can notify the customer that the target transaction address and the target public key associated with the target transaction address are not on the appropriate whitelist. In such examples, the message may also include directions regarding how to be added to the required whitelist (such as, for example, using a process similar to that described above with respect to FIG. 1). When the transaction address or the public key is not associated with the private key, the message can notify the customer that the target transaction address and the target public key associated with the target transaction address are not associated with the private key.” (Para. 0053).
As per Claim 4, Black teaches:
The device of claim 2, wherein the device is a portable device configured to be operatively connected to the electronic calculator of the user via a . . .. (“The method includes sending, with a validator computing device, a restoration request to a key management device to restore the asset private key from the plurality of subkeys; sending, with the validator computing device, confirmation to the key management device that the validator computing device has access to a first number of the subkeys; receiving, at the validator computing device, from the key management device, at least one validator subkey; and restoring, with a restoring algorithm executed by the validator computing device, the asset private key from the first number of the subkeys and the validator subkey; wherein the at least one validator subkey is required to restore the asset private key, wherein the key management device stores an encrypted version of the validator subkey on a blockchain platform and uses blockchain mapping information securely stored by the key management device to locate and accesses the encrypted version of the validator subkey in response to receiving the restoration request and confirmation from the validator computing device.” (Para. 0006) “to restore the asset private key 110, the restoration process may be initiated by the validator at the validator computing device 212 because the validator was charged with verifying the condition initially specified by the initiating user for restoring the asset private key. Thus, the restoration process may be initiated at step 260 by a validating user connecting, with the validator computing device 212 to the key management device 204, providing authentication information to the key management device 204 and providing a restoration request indicating that the validator wishes to restore the asset private key. Prior to step 260, the user 103 selected as the validator (e.g., an heir, stakeholder, or third party such as legal entity) may perform any of a variety of verification steps to confirm the condition for key restoration has occurred” (Para. 0048); “the validator computing device, e.g., with instructions received by key management device 204 and executed in a web browser, can compare the received and decrypted subkeys 116 to the minimum threshold, T, of subkeys required to restore the asset private key 110” (Para. 0051).
Black does not disclose:
• “universal serial bus connection.” (claim 4).
However, as per Claim 4, Sadrizadeh in the analogous art of blockchain transaction security, teaches: “. . . universal serial bus connection. .”. (See “The present hardware encryption device 22 is connected to the smartphone 22, only when required for transactions requiring authorization using the private key, via a connector 24 (e.g., a LIGHTNING connector, a micro-USB connector, a USB-C connector, and the like).” (Para. 0020).
It would have been obvious to one of ordinary skill in the art before the effective filing date to combine the method of Black with the technique of Sadrizadeh to utilize a universal serial bus connection in transacting with cryptographic assets. Therefore, the incentives of providing increased data accessibility for the user provided a reason to make an adaptation, and the invention resulted from application of the prior knowledge in a predictable manner.
As per Claim 6, Black teaches:
The device of claim 1, wherein said unsigned cryptocurrency transaction is authorized with at least M1 digital signatures generated using M1 authorization private keys from a set of N1 authorization private keys, wherein 0<M1≤N1 and M1, N1 are integers, said authorization private key being associated to a relative authorization public key, said secure data storage module of the secure module of the device being further configured to store a list of N1 authorization public keys, the secure data processing module of the secure module being further configured to check, before having checked if the relative destination cryptocurrency address associated to an authorized unsigned cryptocurrency transaction belongs to the fixed list of destination cryptocurrency addresses stored in the secure data storage module of the secure module of the device, using an algorithm of digital signature validity verification, if verification of validity of the at least M1 digital signatures used to authorize the authorized unsigned cryptocurrency transaction succeeds using M1 different keys in the list of N1 authorization public keys stored in the secure data storage module of the secure module of the device, the secure data processing module of the secure module being configured, in the case the verification of the validity of the at least M1 digital signatures used to authorize the authorized unsigned cryptocurrency transaction AU BT does not succeed using all combinations of M1 different keys in the list of N1 authorization public keys stored in the secure data storage module of the secure module of the device, to cause a failure of the authorized unsigned cryptocurrency transaction,
said secure data processing module of the secure module being configured to check if the relative destination cryptocurrency address associated to the authorized unsigned cryptocurrency transaction belongs to the fixed list of destination cryptocurrency addresses stored in the secure data storage module of the secure module of the device only in the case the verification of the validity of the at least M1 digital signatures used to authorize the authorized unsigned cryptocurrency transaction succeeds using M1 different keys in the list of N1 authorization public keys stored in the secure data storage module of the secure module of the device. (“the examples described herein implement validation/verification of a particular transaction address being on the whitelist before allowing a transaction of the token to occur. In one example, the verification can be implemented by an asset exchange (such as, for example, asset exchange 104). The verification includes requiring a potential purchaser of the regulated tokens (that require the user to be whitelisted) to send signed data to a system, where the data is signed with a private key corresponding to the particular transaction address the potential purchaser wants to transact into. The asset exchange verifies that the data was signed with the private key that corresponds to the transaction address the user indicated was the intended destination for the regulated token and that the transaction address is on the appropriate whitelist. In some examples, the asset exchange could verify that the data was signed with the private key that corresponds to a public key associated with the transaction address. The asset exchange allows the transfer to proceed when the private key corresponds to the target transaction address or target public key and the target transaction address or the target public key is on the whitelist. If these conditions are not met, the asset exchange rejects or otherwise denies the transfer.” (Para. 0016); “Method 300 proceeds with verifying that at least one of the target transaction address or the target public key associated with the target transaction address is associated with the private key (block 308). In some examples, verifying that the at least one of the target transaction address or the target public key associated with the target transaction address is associated with the private key is performed at least in part by: verifying that the at least one of the target transaction address or the target public key associated with the target transaction address is derivable from the private key used to sign the signed data. When the target public key is provided, the verification/validation can be performed using a verification algorithm that takes the string, the signature, and the target public key and returns a determination of whether the private key matches the target public key.” (Para. 0050).
As per Claim 7, Black teaches:
The device of claim 6, wherein said data processing unit is configured to receive the authorized unsigned cryptocurrency transaction from a third party authority, said third-party authority being configured to receive the unsigned cryptocurrency transaction, said unsigned cryptocurrency transaction having associated the relative destination cryptocurrency address, said third-party authority being configured to authorize said unsigned cryptocurrency transaction with the relative digital signature generated using the relative authorization private key. (“When the AML and/or KYC procedures are complete, the identity services provider 106 may transmit a notification to the issuer of the token. The notification may indicate the success or failure of the AML and/or KYC procedures for the customer. In some examples, the identity services provider 106 may transmit a report indicating all AML and KYC checks that it performed.” (Para. 0040); “a whitelisting functionality can be incorporated into the token contract. In order to be considered for the initial regulated token sale or offering, a potential purchaser (customer) of the token goes through a whitelisting process to ensure that they satisfy certain requirements for the purchase. For example, the whitelisting process may be implemented for token sales complying with Regulation D, and require that the potential purchaser qualify as an accredited investor as defined in Rule 501 of Regulation D. The issuer of the token verifies that the customer satisfies the criteria for purchasing a regulated token and then a public key or transaction address provided by the customer is added to the whitelist. In some examples, the whitelist is implemented on a smart contract that is different than the token contract. In such examples, the token contract includes a function call to the different smart contract implementing the whitelist. In some examples, the token contract includes a function call to multiple smart contracts implementing different whitelists, where each different whitelist verifies that the customers satisfy criteria for different regulations. For example, one whitelist may implement compliance with Regulation D while another whitelist may implement compliance with Regulation S or Regulation A.” (Para. 0037); “The whitelist(s) can be updated periodically to ensure that the customers associated with the public keys or transaction addresses comply with the particular rules for the whitelist. The whitelist(s) can be modified over time based on a number of factors. For example, the status of an individual or entity that qualifies as an “accredited investor” may change over time based on the value of assets owned, net worth, or income level of individual or entity. Another example is where a particular regulation that the whitelist is intended to implement has time-based restrictions. For example, Regulation S limits the sale of certain securities during the first 40 days following the commencement of an offer, so after the first 40 days, additional addresses may be whitelisted that were previously ineligible due to the location of the purchaser/seller. Accordingly, in some examples, the whitelist is modified or implemented using an oracle or other entity that operates as a data feed for providing verified information to the smart contract for the token.” (Para. 0052).
As per Claim 8, Black teaches:
A system comprising: a device for managing cryptocurrency transactions, comprising: a data processing unit configured to receive an unsigned cryptocurrency transaction, said unsigned cryptocurrency transaction having associated a relative destination cryptocurrency address ; (“Method 300 begins with receiving an intent to purchase a token into a target transaction address from a remotely located computing device (block 302). In some examples, the intent to purchase a token includes the remotely located computing device sending a submission of a request or some other type of communication to communicate interest in purchasing the token. In some examples, the token represents at least one of a security, a currency, a commodity, a bond, a fund, or a combination thereof. In some examples, the token is implemented using a smart contract. For example, the token is a self-regulating token implemented as an extension of Ethereum Request for Comment 20 (ERC20).” (Para. 0045)
a secure module, operatively connected to the data processing unit, comprising: a secure data processing module; a secure data storage module . . . operatively connected to the secure data processing module, said secure data storage module being configured to store: a deterministic list of private keys used to sign the cryptocurrency transactions via digital signature; (“the potential customer provides identity data to the issuer of the token or other entity in order to be considered for the whitelist. Identity data may include a customer's name, date of birth, driver's license number and expiration date, address, phone number(s), email address(es), social security number, employment information, and/or income. In some examples, the customer also provides payment data to the asset exchange 104 or other entity in order to be considered for the whitelist. Payment data may include bank account information, credit card information, contactless payment data (e.g., Apple Pay® or Android Pay® user name and passwords), existing cryptocurrency wallet key, and/or other payment processing information (e.g., user name and password for PayPal® or WhatsApp®). The customer device 102 may transmit the identity data and the payment data associated with the customer to the issuer of the token or other entity using a secure transfer protocol, for example.” (Para. 0038); “Method 300 optionally proceeds with rejecting purchase of the token into the target transaction address when the at least one of the target transaction address or the target public key associated with the target transaction address is not both: (1) associated with the target transaction address associated with the private key and (2) whitelisted to purchase the token (block 312). In some examples, this includes sending a failure message to the remotely located computing device. The message can identify which requirement was the point of failure for the transaction. For example, when the customer's transaction address or public key is not whitelisted, the message can notify the customer that the target transaction address and the target public key associated with the target transaction address are not on the appropriate whitelist. In such examples, the message may also include directions regarding how to be added to the required whitelist (such as, for example, using a process similar to that described above with respect to FIG. 1). When the transaction address or the public key is not associated with the private key, the message can notify the customer that the target transaction address and the target public key associated with the target transaction address are not associated with the private key.” (Para. 0053)
a fixed list of destination cryptocurrency addresses; (“The whitelist(s) can be updated periodically to ensure that the customers associated with the public keys or transaction addresses comply with the particular rules for the whitelist. The whitelist(s) can be modified over time based on a number of factors. For example, the status of an individual or entity that qualifies as an “accredited investor” may change over time based on the value of assets owned, net worth, or income level of individual or entity. Another example is where a particular regulation that the whitelist is intended to implement has time-based restrictions. For example, Regulation S limits the sale of certain securities during the first 40 days following the commencement of an offer, so after the first 40 days, additional addresses may be whitelisted that were previously ineligible due to the location of the purchaser/seller. Accordingly, in some examples, the whitelist is modified or implemented using an oracle or other entity that operates as a data feed for providing verified information to the smart contract for the token.” (Para. 0052); “Since the token is a tradable asset, the initial purchaser of the token may desire to sell or exchange the token with a subsequent purchaser. As discussed above, a problem can arise when a subsequent purchaser of a regulated token with whitelisting functionality tries to withdraw the token. In particular, the withdrawal of the regulated token may be restricted to certain public keys or transaction addresses included in a smart contract implementing the whitelist. If the subsequent purchaser's public key or transaction address is not on the necessary whitelist(s), then the subsequent purchaser will not be able to withdraw the token, e.g., for fiat currency, cryptocurrency, services, etc.” (Para. 0043).
said secure data processing module of the secure module being configured to: check if the relative destination cryptocurrency address associated to the unsigned cryptocurrency transaction belongs to the fixed list of destination cryptocurrency addresses stored in the secure data storage module of the secure module of the device; in the case the relative destination cryptocurrency address associated to the unsigned cryptocurrency transaction does not belong to the fixed list of destination cryptocurrency addresses stored in the secure data storage module of the secure module of the device, cause a failure of the unsigned cryptocurrency transaction; in the case the relative destination cryptocurrency address associated to the unsigned cryptocurrency transaction belongs to the fixed list of destination cryptocurrency addresses stored in the secure data storage module of the secure module of the device, sign, via a relative digital signature, the unsigned cryptocurrency transaction using a private key of said deterministic list of private keys, generating a signed cryptocurrency transaction, wherein the device is configured to be operatively connected to an electronic calculator of a user, (“the customer device 102 may be a mobile device, e.g., using the Android® or iOS® operating systems. A customer may download, to the customer device 102, an application corresponding to the asset exchange 104. The application may present a user interface on the customer device 102, and the customer may provide input using the user interface. Based at least in part on the user input, the application on the customer device 102 may send and receive instructions and/or other data to the asset exchange 104. In some examples, the application on the customer device 102 may only communicate directly with the asset exchange 104, which communicates with other devices in the system 100, i.e., the asset exchange 104 may be a gateway to other devices in the system 100. Alternatively, the application on the customer device 102 may communicate directly with the asset exchange 104 and/or other devices in the system 100.” (Para. 0023); “Method 300 proceeds with allowing purchase of the token into the target transaction address when the at least one of the target transaction address or the target public key associated with the target transaction address is both: (1) associated with the target transaction address associated with the private key and (2) whitelisted to purchase the token (block 314). If the purchase of the token is allowed, the transfer of the tokens to the target address will be executed upon receipt of the agreed upon payment..” (Para. 0054); “In some examples, method 300 optionally proceeds with communicating data to the remotely located computing device to be signed by the remotely located computing device using the private key to create the signed data in response to the intent to purchase a token into a target transaction address being received from the remotely located computing device (block 303). For example, the data sent to the remotely located computing device can include a string that is to be modified by the computing device with the private key.” (Para. 0046).
said electronic calculator being configured to be used by the user to: send the unsigned cryptocurrency transaction to the device; and broadcast a signed cryptocurrency transaction received from the device to a cryptocurrency communication network. (“Method 300 begins with receiving an intent to purchase a token into a target transaction address from a remotely located computing device (block 302). In some examples, the intent to purchase a token includes the remotely located computing device sending a submission of a request or some other type of communication to communicate interest in purchasing the token. In some examples, the token represents at least one of a security, a currency, a commodity, a bond, a fund, or a combination thereof. In some examples, the token is implemented using a smart contract. For example, the token is a self-regulating token implemented as an extension of Ethereum Request for Comment 20 (ERC20).” (Para. 0045).
Black does not disclose:
• “that is a hardware security module” (claim 8).
However, as per Claim 8, Sadrizadeh in the analogous art of blockchain transaction security, teaches: “that is a hardware security module”. (See “The hardware encryption device 22 generates and stores the private key in a secure microcontroller (secure element).” (Para. 0025); “The Secure Element used in the hardware encryption device 22 is also talking on a TLS secured SPI bus only to the ARM processor. This thwarts any replay attacks. During the initial hardware encryption device 22 initialization process in manufacturing, the ARM processor generates a unique random key which is then sent to the Secure Element. The Secure Element stores this key and from that point on will require all messages over the SPI bus to be signed by that unique immutable key. This protects from an attack where the Secure Element is removed from the original hardware encryption device 22 and is then placed in another hardware key in an attempt to bypass the biometric authentication.” (Para. 0040)
It would have been obvious to one of ordinary skill in the art before the effective filing date to combine the method of Black, which controls whether a cryptocurrency transaction proceeds based on destination-address authorization logic and related signing flow, with the technique of Sadrizadeh, which teaches generating/storing private keys in a secure microcontroller/secure element and using that protected hardware to perform signing, to include implementing private-key storage and signing operations within a hardware security module. Therefore, the incentives of improving private-key isolation and reducing exposure of signing keys to compromise in the host processor/software environment provided a reason to make an adaptation, and the invention resulted from application of the prior knowledge in a predictable manner.
As per Claim 9, Black teaches:
The system of claim 8, wherein the electronic calculator of the user is configured to receive via a data communication network an authorized unsigned cryptocurrency transaction authorized by at least one third-party authority. (“As part of the whitelisting process, or as a separate process, the issuer of the token may transmit the identity data to the identity services provider 106. The identity services provider 106 may be one or more computing devices that provide anti-money laundering (AML) and/or know-your-customer (KYC) services. AML, services may include one or more steps to ensure that a potential (or current) customer is not in violation of relevant laws and regulations designed to combat money laundering, i.e., AML services seek to ensure that a potential (or current) customer is not taking steps to obscure the source of funds that were received from illegal or unethical activities. KYC services may include one or more steps to gather, review, and monitor information related to the identity and/or financial dealings of a potential (or current) customer. In some examples, KYC services may include collecting basic identity data (e.g., name, contact information, etc.), verifying that the customer is who they say they are, and/or ensuring that the customer is not on any law enforcement watch lists. KYC services may also include performing a soft credit check (e.g., based on the customer's basic identity data), analyzing a customer's transactional behavior, and/or monitoring the customer's account for fraudulent behavior based on the customer's transaction behavior. AML and KYC may be required under various federal, state, and/or local laws.” (Para. 0039); “When the AML and/or KYC procedures are complete, the identity services provider 106 may transmit a notification to the issuer of the token. The notification may indicate the success or failure of the AML and/or KYC procedures for the customer. In some examples, the identity services provider 106 may transmit a report indicating all AML and KYC checks that it performed.” (Para. 0040)
As per Claim 10, Black teaches:
A method for managing cryptocurrency transactions, the method comprising: receiving, by a data processing unit of a device for managing cryptocurrency transactions, an unsigned cryptocurrency transaction, said unsigned cryptocurrency transaction having associated a relative destination cryptocurrency address; (“Method 300 begins with receiving an intent to purchase a token into a target transaction address from a remotely located computing device (block 302). In some examples, the intent to purchase a token includes the remotely located computing device sending a submission of a request or some other type of communication to communicate interest in purchasing the token. In some examples, the token represents at least one of a security, a currency, a commodity, a bond, a fund, or a combination thereof. In some examples, the token is implemented using a smart contract. For example, the token is a self-regulating token implemented as an extension of Ethereum Request for Comment 20 (ERC20).” (Para. 0045)
checking, by a secure data processing module of a secure module of the device, if the relative destination cryptocurrency address associated to the unsigned cryptocurrency transaction belongs to a fixed list of destination cryptocurrency addresses stored in a secure data storage module . . . of the secure module of the device; (“the potential customer provides identity data to the issuer of the token or other entity in order to be considered for the whitelist. Identity data may include a customer's name, date of birth, driver's license number and expiration date, address, phone number(s), email address(es), social security number, employment information, and/or income. In some examples, the customer also provides payment data to the asset exchange 104 or other entity in order to be considered for the whitelist. Payment data may include bank account information, credit card information, contactless payment data (e.g., Apple Pay® or Android Pay® user name and passwords), existing cryptocurrency wallet key, and/or other payment processing information (e.g., user name and password for PayPal® or WhatsApp®). The customer device 102 may transmit the identity data and the payment data associated with the customer to the issuer of the token or other entity using a secure transfer protocol, for example.” (Para. 0038); “Method 300 optionally proceeds with rejecting purchase of the token into the target transaction address when the at least one of the target transaction address or the target public key associated with the target transaction address is not both: (1) associated with the target transaction address associated with the private key and (2) whitelisted to purchase the token (block 312). In some examples, this includes sending a failure message to the remotely located computing device. The message can identify which requirement was the point of failure for the transaction. For example, when the customer's transaction address or public key is not whitelisted, the message can notify the customer that the target transaction address and the target public key associated with the target transaction address are not on the appropriate whitelist. In such examples, the message may also include directions regarding how to be added to the required whitelist (such as, for example, using a process similar to that described above with respect to FIG. 1). When the transaction address or the public key is not associated with the private key, the message can notify the customer that the target transaction address and the target public key associated with the target transaction address are not associated with the private key.” (Para. 0053)
in the case the relative destination cryptocurrency address associated to the unsigned cryptocurrency transaction does not belong to the fixed list of destination cryptocurrency addresses stored in the secure data storage module of the secure module of the device, causing, by the secure data processing module of the secure module of the device, a failure of the unsigned cryptocurrency transaction; (“The whitelist(s) can be updated periodically to ensure that the customers associated with the public keys or transaction addresses comply with the particular rules for the whitelist. The whitelist(s) can be modified over time based on a number of factors. For example, the status of an individual or entity that qualifies as an “accredited investor” may change over time based on the value of assets owned, net worth, or income level of individual or entity. Another example is where a particular regulation that the whitelist is intended to implement has time-based restrictions. For example, Regulation S limits the sale of certain securities during the first 40 days following the commencement of an offer, so after the first 40 days, additional addresses may be whitelisted that were previously ineligible due to the location of the purchaser/seller. Accordingly, in some examples, the whitelist is modified or implemented using an oracle or other entity that operates as a data feed for providing verified information to the smart contract for the token.” (Para. 0052); “Since the token is a tradable asset, the initial purchaser of the token may desire to sell or exchange the token with a subsequent purchaser. As discussed above, a problem can arise when a subsequent purchaser of a regulated token with whitelisting functionality tries to withdraw the token. In particular, the withdrawal of the regulated token may be restricted to certain public keys or transaction addresses included in a smart contract implementing the whitelist. If the subsequent purchaser's public key or transaction address is not on the necessary whitelist(s), then the subsequent purchaser will not be able to withdraw the token, e.g., for fiat currency, cryptocurrency, services, etc.” (Para. 0043).
in the case the relative destination cryptocurrency address associated to the unsigned cryptocurrency transaction belongs to the fixed list of destination cryptocurrency addresses stored in the secure data storage module of the secure module of the device, signing, by the secure data processing module of the secure module of the device, via a relative digital signature, the unsigned cryptocurrency transaction using a private key of a deterministic list of private keys stored in the secure data storage module of the secure module of the device, generating a signed cryptocurrency transaction. (“Method 300 proceeds with allowing purchase of the token into the target transaction address when the at least one of the target transaction address or the target public key associated with the target transaction address is both: (1) associated with the target transaction address associated with the private key and (2) whitelisted to purchase the token (block 314). If the purchase of the token is allowed, the transfer of the tokens to the target address will be executed upon receipt of the agreed upon payment..” (Para. 0054); “In some examples, method 300 optionally proceeds with communicating data to the remotely located computing device to be signed by the remotely located computing device using the private key to create the signed data in response to the intent to purchase a token into a target transaction address being received from the remotely located computing device (block 303). For example, the data sent to the remotely located computing device can include a string that is to be modified by the computing device with the private key.” (Para. 0046).
Black does not disclose:
• “that is a hardware security module” (claim 10).
However, as per Claim 10, Sadrizadeh in the analogous art of blockchain transaction security, teaches: “that is a hardware security module”. (See “The hardware encryption device 22 generates and stores the private key in a secure microcontroller (secure element).” (Para. 0025); “The Secure Element used in the hardware encryption device 22 is also talking on a TLS secured SPI bus only to the ARM processor. This thwarts any replay attacks. During the initial hardware encryption device 22 initialization process in manufacturing, the ARM processor generates a unique random key which is then sent to the Secure Element. The Secure Element stores this key and from that point on will require all messages over the SPI bus to be signed by that unique immutable key. This protects from an attack where the Secure Element is removed from the original hardware encryption device 22 and is then placed in another hardware key in an attempt to bypass the biometric authentication.” (Para. 0040)
It would have been obvious to one of ordinary skill in the art before the effective filing date to combine the method of Black, which controls whether a cryptocurrency transaction proceeds based on destination-address authorization logic and related signing flow, with the technique of Sadrizadeh, which teaches generating/storing private keys in a secure microcontroller/secure element and using that protected hardware to perform signing, to include implementing private-key storage and signing operations within a hardware security module. Therefore, the incentives of improving private-key isolation and reducing exposure of signing keys to compromise in the host processor/software environment provided a reason to make an adaptation, and the invention resulted from application of the prior knowledge in a predictable manner.
As per Claim 11, Black teaches:
The method of claim 10, further comprising sending, by an electronic calculator of a user, the received unsigned cryptocurrency transaction to the device. (“Method 300 begins with receiving an intent to purchase a token into a target transaction address from a remotely located computing device (block 302). In some examples, the intent to purchase a token includes the remotely located computing device sending a submission of a request or some other type of communication to communicate interest in purchasing the token. In some examples, the token represents at least one of a security, a currency, a commodity, a bond, a fund, or a combination thereof. In some examples, the token is implemented using a smart contract. For example, the token is a self-regulating token implemented as an extension of Ethereum Request for Comment 20 (ERC20).” (Para. 0045); “the customer device 102 may be a mobile device, e.g., using the Android® or iOS® operating systems. A customer may download, to the customer device 102, an application corresponding to the asset exchange 104. The application may present a user interface on the customer device 102, and the customer may provide input using the user interface. Based at least in part on the user input, the application on the customer device 102 may send and receive instructions and/or other data to the asset exchange 104. In some examples, the application on the customer device 102 may only communicate directly with the asset exchange 104, which communicates with other devices in the system 100, i.e., the asset exchange 104 may be a gateway to other devices in the system 100. Alternatively, the application on the customer device 102 may communicate directly with the asset exchange 104 and/or other devices in the system 100.” (Para. 0023).
As per Claim 12, Black teaches:
The method of claim 11, further comprising sending, by the data processing unit of the device, the signed cryptocurrency transaction to the electronic calculator of the user. (“Method 300 proceeds with allowing purchase of the token into the target transaction address when the at least one of the target transaction address or the target public key associated with the target transaction address is both: (1) associated with the target transaction address associated with the private key and (2) whitelisted to purchase the token (block 314). If the purchase of the token is allowed, the transfer of the tokens to the target address will be executed upon receipt of the agreed upon payment.” (Para. 0054); “the examples described herein implement validation/verification of a particular transaction address being on the whitelist before allowing a transaction of the token to occur. In one example, the verification can be implemented by an asset exchange (such as, for example, asset exchange 104). The verification includes requiring a potential purchaser of the regulated tokens (that require the user to be whitelisted) to send signed data to a system, where the data is signed with a private key corresponding to the particular transaction address the potential purchaser wants to transact into. The asset exchange verifies that the data was signed with the private key that corresponds to the transaction address the user indicated was the intended destination for the regulated token and that the transaction address is on the appropriate whitelist. In some examples, the asset exchange could verify that the data was signed with the private key that corresponds to a public key associated with the transaction address. The asset exchange allows the transfer to proceed when the private key corresponds to the target transaction address or target public key and the target transaction address or the target public key is on the whitelist. If these conditions are not met, the asset exchange rejects or otherwise denies the transfer.” (Para. 0016); “Method 300 optionally proceeds with rejecting purchase of the token into the target transaction address when the at least one of the target transaction address or the target public key associated with the target transaction address is not both: (1) associated with the target transaction address associated with the private key and (2) whitelisted to purchase the token (block 312). In some examples, this includes sending a failure message to the remotely located computing device. The message can identify which requirement was the point of failure for the transaction. For example, when the customer's transaction address or public key is not whitelisted, the message can notify the customer that the target transaction address and the target public key associated with the target transaction address are not on the appropriate whitelist. In such examples, the message may also include directions regarding how to be added to the required whitelist (such as, for example, using a process similar to that described above with respect to FIG. 1). When the transaction address or the public key is not associated with the private key, the message can notify the customer that the target transaction address and the target public key associated with the target transaction address are not associated with the private key.” (Para. 0053)
As per Claim 13, Black teaches:
The method of claim 10, wherein said unsigned cryptocurrency transaction is authorized with at least M1 digital signatures generated using M1 authorization private keys from a set of N1 authorization private keys, wherein 0<M1≤N1 and M1, N1 are integers, said authorization private key being associated to a relative authorization public key, the method further comprising, before having checked, by the secure data processing module of the secure module of the device, if the relative destination cryptocurrency address associated to the authorized unsigned cryptocurrency transaction belongs to the fixed list of destination cryptocurrency addresses stored in the secure data storage module of the secure module of the device: checking, by the secure data processing module of the secure module of the device, using an algorithm of digital signature validity verification, if verification of validity of the at least M1 digital signatures used as authorization in the authorized unsigned cryptocurrency transaction succeeds using M1 different keys in a list of N1 authorization public keys stored in the secure data storage module of the secure module of the device; in the case the verification of the validity of the at least M1 digital signatures used to authorize the authorized unsigned cryptocurrency transaction does not succeed using all combinations of M1 different keys in the list of N1 authorization public keys stored in the secure data storage module of the secure module of the device, causing, by the secure data processing module of the secure module of the device, a failure of the cryptocurrency transaction, the step of checking if the relative destination cryptocurrency address associated to the authorized unsigned cryptocurrency transaction belongs to the fixed list of destination cryptocurrency addresses stored in the secure data storage module of the secure module of the device being performed, by said secure data processing module of the secure module, only in the case the verification of the validity of the at least M1 digital signatures used to authorize the authorized unsigned cryptocurrency transaction succeeds using M1 different keys in the list of N1 authorization public keys stored in the secure data storage module of the secure module of the device. (“the examples described herein implement validation/verification of a particular transaction address being on the whitelist before allowing a transaction of the token to occur. In one example, the verification can be implemented by an asset exchange (such as, for example, asset exchange 104). The verification includes requiring a potential purchaser of the regulated tokens (that require the user to be whitelisted) to send signed data to a system, where the data is signed with a private key corresponding to the particular transaction address the potential purchaser wants to transact into. The asset exchange verifies that the data was signed with the private key that corresponds to the transaction address the user indicated was the intended destination for the regulated token and that the transaction address is on the appropriate whitelist. In some examples, the asset exchange could verify that the data was signed with the private key that corresponds to a public key associated with the transaction address. The asset exchange allows the transfer to proceed when the private key corresponds to the target transaction address or target public key and the target transaction address or the target public key is on the whitelist. If these conditions are not met, the asset exchange rejects or otherwise denies the transfer.” (Para. 0016); “Method 300 proceeds with verifying that at least one of the target transaction address or the target public key associated with the target transaction address is associated with the private key (block 308). In some examples, verifying that the at least one of the target transaction address or the target public key associated with the target transaction address is associated with the private key is performed at least in part by: verifying that the at least one of the target transaction address or the target public key associated with the target transaction address is derivable from the private key used to sign the signed data. When the target public key is provided, the verification/validation can be performed using a verification algorithm that takes the string, the signature, and the target public key and returns a determination of whether the private key matches the target public key.” (Para. 0050).
As per Claim 14, Black teaches:
The method of claim 13, further comprising receiving, by the data processing unit, the authorized unsigned cryptocurrency transaction from a third-party authority, said authorized unsigned cryptocurrency transaction having been authorized by the third party authority starting from the unsigned cryptocurrency transaction received by the third party authority, using the relative digital signature generated using a relative authorization private key, said unsigned cryptocurrency transaction having associated the relative destination cryptocurrency address. (“When the AML and/or KYC procedures are complete, the identity services provider 106 may transmit a notification to the issuer of the token. The notification may indicate the success or failure of the AML and/or KYC procedures for the customer. In some examples, the identity services provider 106 may transmit a report indicating all AML and KYC checks that it performed.” (Para. 0040); “a whitelisting functionality can be incorporated into the token contract. In order to be considered for the initial regulated token sale or offering, a potential purchaser (customer) of the token goes through a whitelisting process to ensure that they satisfy certain requirements for the purchase. For example, the whitelisting process may be implemented for token sales complying with Regulation D, and require that the potential purchaser qualify as an accredited investor as defined in Rule 501 of Regulation D. The issuer of the token verifies that the customer satisfies the criteria for purchasing a regulated token and then a public key or transaction address provided by the customer is added to the whitelist. In some examples, the whitelist is implemented on a smart contract that is different than the token contract. In such examples, the token contract includes a function call to the different smart contract implementing the whitelist. In some examples, the token contract includes a function call to multiple smart contracts implementing different whitelists, where each different whitelist verifies that the customers satisfy criteria for different regulations. For example, one whitelist may implement compliance with Regulation D while another whitelist may implement compliance with Regulation S or Regulation A.” (Para. 0037); “The whitelist(s) can be updated periodically to ensure that the customers associated with the public keys or transaction addresses comply with the particular rules for the whitelist. The whitelist(s) can be modified over time based on a number of factors. For example, the status of an individual or entity that qualifies as an “accredited investor” may change over time based on the value of assets owned, net worth, or income level of individual or entity. Another example is where a particular regulation that the whitelist is intended to implement has time-based restrictions. For example, Regulation S limits the sale of certain securities during the first 40 days following the commencement of an offer, so after the first 40 days, additional addresses may be whitelisted that were previously ineligible due to the location of the purchaser/seller. Accordingly, in some examples, the whitelist is modified or implemented using an oracle or other entity that operates as a data feed for providing verified information to the smart contract for the token.” (Para. 0052).
Claim 5 is rejected under 35 U.S.C. 103 as being unpatentable over Black in view of Sadrizadeh in further view of Van de Ruit et al. (US20190121988) (hereinafter “Van de Ruit”).
As per Claim 5, Van de Ruit teaches:
The device of claim 2, wherein the . . . the electronic calculator of the user (“Method 300 begins with receiving an intent to purchase a token into a target transaction address from a remotely located computing device (block 302). In some examples, the intent to purchase a token includes the remotely located computing device sending a submission of a request or some other type of communication to communicate interest in purchasing the token. In some examples, the token represents at least one of a security, a currency, a commodity, a bond, a fund, or a combination thereof. In some examples, the token is implemented using a smart contract. For example, the token is a self-regulating token implemented as an extension of Ethereum Request for Comment 20 (ERC20). In some examples, the token is self-regulating in the sense that it implements commands for compliance as a security or an asset under SEC regulations.” (Para. 0045); “the customer device 102 may be a mobile device, e.g., using the Android® or iOS® operating systems. A customer may download, to the customer device 102, an application corresponding to the asset exchange 104. The application may present a user interface on the customer device 102, and the customer may provide input using the user interface. Based at least in part on the user input, the application on the customer device 102 may send and receive instructions and/or other data to the asset exchange 104. In some examples, the application on the customer device 102 may only communicate directly with the asset exchange 104, which communicates with other devices in the system 100, i.e., the asset exchange 104 may be a gateway to other devices in the system 100. Alternatively, the application on the customer device 102 may communicate directly with the asset exchange 104 and/or other devices in the system 100.” (Para. 0023).
Black does not disclose:
• “device is embedded within.” (claim 5).
However, as per Claim 5, Van de Ruit in the analogous art of blockchain transaction security, teaches: “. . . device is embedded within. .”. (See “The hardware element may be a so-called ‘secure element’. Examples of a secure element in phones include the chip directly embedded into the phone's hardware, a SIM/UICC card provided by your network operator, and an SD card that can be inserted into the mobile phone.” (Para. 0017); “a phone 202 and a SIM card 201. SIM card 201 comprises an integrated circuit 203. The integrated circuit implements memory 210 and circuit 220. In an embodiment, access to the SIM card is restricted. Memory 110 and circuit 120 may be implemented in phone 202. When card 201 is inserted in phone 202, the full functionality of the blockchain transaction device is obtained.” (Para. 0113); “In hybrid embodiments, functional units are implemented partially in hardware, e.g., as coprocessors, e.g., crypto coprocessors, and partially in software stored and executed on device 300.” (Para. 0124).
It would have been obvious to one of ordinary skill in the art before the effective filing date to combine the method of Black with the technique of Van de Ruit to utilize a secure element to manage cryptographic assets. Therefore, the incentives of providing increased security for the user provided a reason to make an adaptation, and the invention resulted from application of the prior knowledge in a predictable manner.
Conclusion
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a). A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
The following prior art made of record and not relied upon is considered pertinent to applicant's disclosure: US Patent 9722790 (Ebrahimi), discussing methods for “managing the identity of users and of identifying those users to third parties. . . [where] logic on a first remote device receives a first transaction number and personal data transmitted from a second remote device. The first transaction number was received from a distributed public database in response to a transmission, from the second remote device, of a signed hash value and a first public key associated with a first private key on the second remote device.”
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Justin A. Jimenez whose telephone number is (571) 270-3080. The examiner can normally be reached on 8:30 AM - 5:00 PM.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, John W. Hayes can be reached on 571-272-6708. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/Justin Jimenez/
Patent Examiner, Art Unit 3697
/ARI SHAHABI/Primary Examiner, Art Unit 3697