DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013 is being examined under the AIA first inventor to file provisions.
Election/Restrictions
Restriction to one of the following inventions is required under 35 U.S.C. 121:
Claims 1-12 and 17-20, drawn to key management, classified in G06Q 20/3829.
Claims 13-17, drawn to authentication of entities, classified in HI4L 63/08.
The inventions are independent or distinct, each from the other because:
Inventions I and II are related as subcombinations disclosed as usable together in a single combination. The subcombinations are distinct if they do not overlap in scope and are not obvious variants, and if it is shown that at least one subcombination is separately usable. In the instant case, subcombination I has separate utility such as generating keys. Subcombination II has separate utility such as authenticating and storing data. See MPEP § 806.05(d).
The examiner has required restriction between subcombinations usable together. Where applicant elects a subcombination and claims thereto are subsequently found allowable, any claim(s) depending from or otherwise requiring all the limitations of the allowable subcombination will be examined for patentability in accordance with 37 CFR 1.104. See MPEP § 821.04(a). Applicant is advised that if any claim presented in a continuation or divisional application is anticipated by, or includes all the limitations of, a claim that is allowable in the present application, such claim may be subject to provisional statutory and/or non-statutory double patenting rejections over the claims of the instant application.
Restriction for examination purposes as indicated is proper because all the inventions listed in this action are independent or distinct for the reasons given above and there would be a serious search and/or examination burden if restriction were not required because one or more of the following reasons apply:
the inventions have acquired a separate status in the art in view of their different classification;
the inventions have acquired a separate status in the art due to their recognized divergent subject matter;
the inventions require a different field of search (for example, searching different classes/subclasses or electronic resources, or employing different search queries);
the prior art applicable to one invention would not likely be applicable to another invention;
the inventions are likely to raise different non-prior art issues under 35 U.S.C. § 101 and/or 35 U.S.C. § 112, first paragraph.
Applicant is advised that the reply to this requirement to be complete must include (i) an election of an invention to be examined even though the requirement may be traversed (37 CFR 1.143) and (ii) identification of the claims encompassing the elected invention.
The election of an invention may be made with or without traverse. To reserve a right to petition, the election must be made with traverse. If the reply does not distinctly and specifically point out supposed errors in the restriction requirement, the election shall be treated as an election without traverse. Traversal must be presented at the time of election in order to be considered timely. Failure to timely traverse the requirement will result in the loss of right to petition under 37 CFR 1.144. If claims are added after the election, applicant must indicate which of these claims are readable upon the elected invention.
Should applicant traverse on the ground that the inventions are not patentably distinct, applicant should submit evidence or identify such evidence now of record showing the inventions to be obvious variants or clearly admit on the record that this is the case. In either instance, if the examiner finds one of the inventions unpatentable over the prior art, the evidence or admission may be used in a rejection under 35 U.S.C. 103 or pre-AIA 35 U.S.C. 103(a) of the other invention.
A phone call was made.
The applicant’s attorney has elected group I (claims 1-12 and 17-20) set of claims without traverse.
Status of Claims
The following is a non-final First Office Action on the Merits is in reply to the application filed on 07/02/2024.
Claims 1-12 and 17-20 are elected
Claims 13-16 are non-elected
Overall, Claims 1-12 and 17-20 are pending and have been considered below.
Priority
The application claims priority to provisional application 63/308,469, filed on 02/09/2022. The priority is acknowledged.
Information Disclosure Statement (IDS)
The information disclosure statement (IDS) submitted on 07/02/2024 is in compliance with the provisions of 37 CFR 1.97. Accordingly, such IDS is being considered by Examiner.
Claim Rejections - 35 USC § 101
35 USC 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-12, 17-20 are rejected under 35 USC 101 because the claimed invention is not directed to patent eligible subject matter. The claimed matter is directed to a judicial exception, i.e. an abstract idea, not integrated into a practical application, and without significantly more.
Per Step 1 of the multi-step eligibility analysis, claims 1-12 are directed to a computer implemented method, and claims 17-20 are directed to a system.
Thus, on its face, each independent claim and the associated dependent claims are directed to a statutory category of invention.
Per Step 2A.1. Claim 1 is rejected under 35 USC 101 because the claim is directed to an abstract idea, a judicial exception, without reciting additional elements that integrate the judicial exception into a practical application. The limitations of the independent claim 1 recite an abstract idea, shown in bold, while the non-bolded claim elements recite additional element according to MPEP 2106.04(a).
[A] A method of configuring a hardware wallet for control, the method comprising:
[B] generating, by a first wallet controller, a master signing key pair comprising a private master signing key and a public master signing key;
[C] generating, by the first wallet controller, a first unlocking key pair comprising a private first unlocking key and a public first unlocking key;
[D] signing, by the first wallet controller, the public first unlocking key with the private master signing key to create a signed public first unlocking key;
[E] transmitting, from the first wallet controller to the hardware wallet, the public master signing key; and
[F] transmitting, from the first wallet controller to the hardware wallet, the signed public first unlocking key.
Claim 1 recites: generating key pairs ([B]-[C]); signing the key ([D]); and transmitting the key ([E]-[F]), which, based on the claim language and in view of the application disclosure, represents enabling a system for managing cryptographic credentials.
This overall combination, covers managing and authenticating digital information, including generating credentials, verifying credentials through signing and communicating credential data between devices and such activities can be performed by human using pen and paper. Such limitations expresses observation, evaluation, judgement, which falls under Mental Processes, i.e., Concepts Performed in the Human Mind grouping of abstract ideas (see MPEP 2106.04(a)(2)).
Accordingly, it is reasonable to conclude that claim 1 recites an abstract idea that represents a judicial exception.
Per Step 2A.2. The identified abstract idea is not integrated into a practical application because the additional elements in the independent claims only amount to instructions to apply the judicial exception to a computer, or are a general link to a technological environment (see MPEP 2106.05(f); MPEP 2106.05(h)). For example, the additional elements “hardware wallet,” “wallet controller,” “master signing,” “first unlocking,” recite computing elements at a high level of generality, which is equivalent to instructions to implement the abstract idea “by a computer” or “on a computer.” The additional elements do not preclude from carrying out the identified abstract idea of managing cryptographic credentials. Therefore, those additional elements do not serve to integrate the identified abstract idea into practical application.
The additional elements in the independent claims, shown not bolded above, recite: configuring a hardware wallet for control ([A]). When considered individually or as an ordered combination, they amount to nothing more than reception, transmission and/or general computation (i.e., not specific enough computation) of claim elements that serves merely to implement the abstract idea using computing components for performing computer functions (adding the words “apply it” or an equivalent), or merely uses a computer as a tool to perform the identified abstract idea.
Therefore, the additional elements of claim 1 do not integrate the identified abstract idea into a practical application and the claims remain a judicial exception.
Per Step 2B. Claim 1 does not include additional elements that are sufficient to amount to significantly more than the judicial exception because, when the independent claim is reevaluated as a whole, as an ordered combination under the considerations of Step 2B, the outcome is the same like under Step 2A.2.
Therefore, when considered as a whole and as an ordered combination, the additional elements in the claim amount to instructions to apply the abstract idea on a computer. Moreover, as noted above, there is nothing the computing and additional elements (limitation [A]), that is significant or meaningful to the underlying abstract idea because the identified abstract idea of managing cryptographic credentials could have been reasonably performed when provided with the relevant data and/or information. Therefore, it is concluded that independent claim 1 deemed ineligible.
Per Step 2A.1. Claim 17 is rejected under 35 USC 101 because the claim is directed to an abstract idea, a judicial exception, without reciting additional elements that integrate the judicial exception into a practical application.
The limitations of the independent claim 17 recite an abstract idea, shown in bold below:
[A] A cryptocurrency wallet controller to configure a hardware wallet for control by the cryptocurrency wallet controller, the cryptocurrency wallet controller comprising:
[B] a transceiver configured to electronically communicate with the hardware wallet to communicate cryptographic keys to the hardware wallet;
[C] a digital storage unit configured to securely store at least a portion of the cryptographic keys;
[D] a processor in electronic communication with the digital storage unit and the transceiver, wherein the processor is configured to:
[E] generate a master signing key pair comprising a private master signing key and a public master signing key;
[F] generate a first unlocking key pair comprising a private first unlocking key and a public first unlocking key;
[G] sign, the public first unlocking key with the private master signing key to create a signed public first unlocking key;
[H] transmit, by the transceiver, the public master signing key to the hardware wallet; and
[I] transmit, by the transceiver, the signed public first unlocking key to the hardware wallet,
[J] wherein the processor stores the private master signing key and the private first unlocking key in the digital storage unit, and
[K] wherein the private master signing key and the private first unlocking key are not transmitted from the cryptocurrency wallet controller to the hardware wallet.
Claim 17 recites: generating key pairs ([E]-[F]); signing the key ([G]); transmitting the key ([H]-[I]); storing keys ([J]); and, private keys are not transmitted to specific location ([K]), which, based on the claim language and in view of the application disclosure, represents enabling a system for managing cryptographic credentials.
This overall combination, covers managing and authenticating digital information, including generating credentials, verifying credentials through signing and communicating credential data between devices and such activities can be performed by human using pen and paper. Such limitations expresses observation, evaluation, judgement, which falls under Mental Processes, i.e., Concepts Performed in the Human Mind grouping of abstract ideas (see MPEP 2106.04(a)(2)).
Accordingly, it is reasonable to conclude that claim 1 recites an abstract idea that represents a judicial exception.
Per Step 2A.2. The identified abstract idea is not integrated into a practical application because the additional elements in the independent claims only amount to instructions to apply the judicial exception to a computer, or are a general link to a technological environment (see MPEP 2106.05(f); MPEP 2106.05(h)). For example, the added elements “processor,” “transceiver,” “hardware wallet,” “wallet controller,” “digital storage unit,” “master signing,” “first unlocking,” recite computing elements at a high level of generality, which is equivalent to instructions to implement the abstract idea “by a computer” or “on a computer.” The modifiers do not preclude from carrying out the identified abstract idea of enabling means of managing cryptographic credentials. Therefore, those modifiers do not serve to integrate the identified abstract idea into practical application.
The additional steps in the independent claims, shown not bolded above, recite: configuring a hardware wallet for control ([A]), electronically communicate ([B], [D]), digital storage unit to securely store ([C]). When considered individually or as an ordered combination, they amount to nothing more than reception, transmission and/or general computation (i.e., not specific enough computation) of claim elements that serves merely to implement the abstract idea using computing components for performing computer functions (adding the words “apply it” or an equivalent), or merely uses a computer as a tool to perform the identified abstract idea.
Therefore, the additional steps of claim 17 do not integrate the identified abstract idea into a practical application and the claims remain a judicial exception.
Per Step 2B. Claim 17 does not include additional elements that are sufficient to amount to significantly more than the judicial exception because, when the independent claim is reevaluated as a whole, as an ordered combination under the considerations of Step 2B, the outcome is the same like under Step 2A.2.
Therefore, when considered as a whole and as an ordered combination, the additional elements in the claim amount to instructions to apply the abstract idea on a computer. Moreover, as noted above, there is nothing the computing and additional step (limitations [A]-[D]), that is significant or meaningful to the underlying abstract idea because the identified abstract idea of
managing cryptographic credentials could have been reasonably performed when provided with the relevant data and/or information. Therefore, it is concluded that independent claim 17 deemed ineligible.
Dependent Claims: Claims 2-12, 18-20 are analyzed for subject matter eligibility. However, these claims fails to recite patent eligible subject matter for following reasons:
Claim 2, recites the following bolded claim elements as abstract ideas while the non-bolded claim elements recites additional elements according to MPEP 2106.04(a). The claim further recites:
[A] storing, by the hardware wallet, the public master signing key;
[B] storing, by the hardware wallet, the signed public first unlocking key;
[C] decrypting, from the signed public first unlocking key, the public first unlocking key, by the public master signing key master signing key; and
[D] storing, by the hardware wallet the public first unlocking key.
The claim further recites the abstract idea of storing and decrypting keys. In other words, it recites limitation grouped within the “mental process” grouping of abstract ideas. The non-bolded 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)).
Claim 3, recites the following bolded claim elements as abstract ideas while the non-bolded claim elements recites additional elements according to MPEP 2106.04(a). The claim further recites:
[A] setting, by a user input component of the hardware wallet, a first user personal identification number (PIN) and storing the first user PIN.
The claim further recites the abstract idea of setting and storing PIN. In other words, it recites limitation grouped within the “mental process” grouping of abstract ideas. The non-bolded 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)).
Claim 4, recites the following bolded claim elements as abstract ideas while the non-bolded claim elements recites additional elements according to MPEP 2106.04(a). The claim further recites:
[A] transmitting, from the first wallet controller, the private master signing key to a second wallet controller;
[B] generating, by the second wallet controller, a second unlocking key pair comprising a private second unlocking key and a public second unlocking key;
[C] signing, by the second wallet controller the public second unlocking key with the private master signing key to create a signed public second unlocking key; and
[D] transmitting, from the second wallet controller to the hardware wallet, the signed public second unlocking key.
The claim further recites the abstract idea of managing cryptographic credentials. In other words, it recites limitation grouped within the “mental process” grouping of abstract ideas. The non-bolded 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)).
Claim 5, recites the following bolded claim elements as abstract ideas while the non-bolded claim elements recites additional elements according to MPEP 2106.04(a). The claim further recites:
[A] wherein transmitting the private master signing key from the first wallet controller to the second wallet controller comprises accessing a same trusted execution environment (TEE) by the first wallet controller and the second wallet controller.
The claim further recites the abstract idea of accessing the same environment. In other words, it recites limitation grouped within the “mental process” grouping of abstract ideas. The non-bolded 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)).
Claim 6, recites the following bolded claim elements as abstract ideas while the non-bolded claim elements recites additional elements according to MPEP 2106.04(a). The claim further recites:
[A] storing, by the hardware wallet, the signed public second unlocking key;
[B] decrypting, from the signed public second unlocking key, the public second unlocking key, by the public master signing key; and
[C] storing, by the hardware wallet, the public second unlocking key.
The claim further recites the abstract idea of storing and decrypting keys. In other words, it recites limitation grouped within the “mental process” grouping of abstract ideas. The non-bolded 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)).
Claim 7, recites the following bolded claim elements as abstract ideas while the non-bolded claim elements recites additional elements according to MPEP 2106.04(a). The claim further recites:
[A] authorizing unlocking of the hardware wallet to allow access to secured data comprising cryptocurrency, the authorizing comprising:
[B] generating, by the first wallet controller, a first wallet unlocking command;
[C] signing, by the first wallet controller, the first wallet unlocking command with the private first unlocking key to generate a first signed wallet unlocking command; and
[D] transmitting, by the first wallet controller, the first signed wallet unlocking command to the hardware wallet.
The claim further recites the abstract idea of managing cryptographic credentials. In other words, it recites limitation grouped within the “mental process” grouping of abstract ideas. The non-bolded 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)).
Claim 8, recites the following bolded claim elements as abstract ideas while the non-bolded claim elements recites additional elements according to MPEP 2106.04(a). The claim further recites:
[A] accessing the secured data comprising cryptocurrency, the accessing occurring after the authorizing unlocking of the hardware wallet and comprising:
[B] prompting, by the hardware wallet, a user to enter a personal identification number;
[C] receiving, by the hardware wallet, the personal identification number;
[D] verifying, by the hardware wallet, that the received personal identification number is correct;
[E] in response to the verifying:
[F] decrypting, from the signed wallet unlocking command, the first wallet unlocking command, by the public first unlocking key to reveal the first wallet unlocking command; and
[G] executing, by the hardware wallet, the first wallet unlocking command.
The claim further recites the abstract idea of managing cryptographic credentials. In other words, it recites limitation grouped within the “mental process” grouping of abstract ideas. The non-bolded 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)).
Claim 9, recites the following bolded claim elements as abstract ideas while the non-bolded claim elements recites additional elements according to MPEP 2106.04(a). The claim further recites:
[A] authorizing unlocking of the hardware wallet to allow access to secured data comprising cryptocurrency, the authorizing comprising:
[B] generating, by the second wallet controller, a second wallet unlocking command;
[C] signing, by the second wallet controller the second wallet unlocking command with the private second unlocking key to generate a second signed wallet unlocking command; and
[D] transmitting, by the second wallet the second signed wallet unlocking command to the hardware wallet.
The claim further recites the abstract idea of managing cryptographic credentials. In other words, it recites limitation grouped within the “mental process ” grouping of abstract ideas. The non-bolded 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)).
Claim 10, recites the following bolded claim elements as abstract ideas while the non-bolded claim elements recites additional elements according to MPEP 2106.04(a). The claim further recites:
[A] accessing the secured data comprising cryptocurrency, the accessing occurring after the authorizing unlocking of the hardware wallet and comprising:
[B] prompting, by the hardware wallet, a user to enter a personal identification number;
[C] receiving, by the hardware wallet, the personal identification number;
[D] verifying, by the hardware wallet, that the received personal identification number is correct;
[E] in response to the verifying:
[F] decrypting, from the signed wallet unlocking command, the second wallet unlocking command, by the public second unlocking key to reveal the second wallet unlocking command; and
[G] executing, by the hardware wallet, the second wallet unlocking command.
The claim further recites the abstract idea of managing cryptographic credentials. In other words, it recites limitation grouped within the “mental process” grouping of abstract ideas. The non-bolded 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)).
Claim 11, recites the following bolded claim elements as abstract ideas while the non-bolded claim elements recites additional elements according to MPEP 2106.04(a). The claim further recites:
[A] revoking the first unlocking key pair, the revoking comprising:
[B] generating, by the first wallet controller, a first unlocking key pair revocation command;
[C] signing, by the first wallet controller, the first unlocking key pair revocation command with at least one of (i) the private master signing key and (ii) the private first unlocking key to generate a first signed unlocking key pair revocation command; and
[D] transmitting, by the first wallet controller, the first signed unlocking key pair revocation command to the hardware wallet.
The claim further recites the abstract idea of managing cryptographic credentials. In other words, it recites limitation grouped within the “mental process” grouping of abstract ideas. The non-bolded 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)).
Claim 12, recites the following bolded claim elements as abstract ideas while the non-bolded claim elements recites additional elements according to MPEP 2106.04(a). The claim further recites:
[A] receiving, by the hardware wallet the first signed unlocking key pair revocation command;
[B] decrypting, from the first signed unlocking key pair revocation command, the first unlocking key pair revocation command, by at least one of (i) the public master signing key and (ii) the public first unlocking key to reveal the first unlocking key pair revocation command; and
[C] deleting, by the hardware wallet, the public first unlocking key from the hardware wallet.
The claim further recites the abstract idea of managing cryptographic credentials. In other words, it recites limitation grouped within the “mental process” grouping of abstract ideas. The non-bolded 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)).
Claim 18, recites the following bolded claim elements as abstract ideas while the non-bolded claim elements recites additional elements according to MPEP 2106.04(a). The claim further recites:
[A] wherein the processor is further configured to transmit, from the first wallet controller, the private master signing key to a second wallet controller.
The claim further recites the abstract idea of managing cryptographic credentials. In other words, it recites limitation grouped within the “mental process” grouping of abstract ideas. The non-bolded 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)).
Claim 19, recites the following bolded claim elements as abstract ideas while the non-bolded claim elements recites additional elements according to MPEP 2106.04(a). The claim further recites:
[A] generates, by the second wallet controller, a second unlocking key pair comprising a private second unlocking key and a public second unlocking key;
[B] signs, by the second wallet controller, the public second unlocking key with the private master signing key to create a signed public second unlocking key; and
[C] transmits, from the second wallet controller to the hardware wallet, the signed public second unlocking key.
The claim further recites the abstract idea of managing cryptographic credentials. In other words, it recites limitation grouped within the “mental process” grouping of abstract ideas. The non-bolded 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)).
Claim 20, recites the following bolded claim elements as abstract ideas while the non-bolded claim elements recites additional elements according to MPEP 2106.04(a). The claim further recites:
[A] wherein both the first wallet controller and the second wallet controller are software applications running on a same device, wherein the transmitting from the first wallet controller the private master signing key to the second wallet controller comprises accessing a shared trusted execution environment containing the private master signing key by both the first wallet controller and the second wallet controller.
The non-bolded 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)).
When the dependent claims are considered as a whole, as an ordered combination, the claim elements noted above appear to merely apply the abstract concept to a technical environment in a very general sense, i.e., a computer receives information from another computer, processes that information and then sends a response based on processing results. The most significant elements of the claims, that is the elements that really outline the inventive elements of the claims, are set forth in the elements identified in the independent claims as an abstract idea. The fact that the computing devices are facilitating the abstract concept is not enough to confer subject matter eligibility. Overall, the further elements do not confer subject matter eligibility to the invention since their individual and combined significance are not changing the nature of the abstract concepts at the core of the claimed invention. Therefore, it is concluded that the dependent claims of the instant application do not amount to significantly more. (See MPEP 2106.05).
In sum, Claims 1-12, 17-20 are rejected under 35 USC 101 as being directed to non-statutory subject matter.
Claim Objection(s)
Claim 2 objected to because of the following informality: “decrypting, from the signed public first unlocking key, the public first unlocking key, by … the public master signing key master signing key …”, should read “decrypting, from the signed public first unlocking key, the public first unlocking key, by … the public master signing key …”. Appropriate correction is required.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
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.
The text of those sections of Title 35, U.S. Code not included in this action can be found in a prior Office action.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or non-obviousness.
Claim 1 is rejected under 35 U.S.C. 103 as being unpatentable over Lu (US 20200226586 A1), in view of Maheshwari (US 20200372495 A1), in further view of Black (US 20190220857 A1).
Regarding Claim 1 . Lu discloses:
generating, by a first wallet controller, a master signing key …; [see at least Fig. 1, (0037) generates the master key from the key seed via the first preset algorithm, stores the master key into the security storage area]
generating, by the first wallet controller, a first unlocking key pair comprising a private first unlocking key and a public first unlocking key; [see at least Fig. 1, (0033) the hardware wallet generates the sub key pair via the key deriving algorithm according to the master key in the security storage area and the sub key index in the transaction instruction]
signing, by the first wallet controller, … with the private master signing key to create a signed …; [see at least (0033) signs on the transaction data in the transaction instruction by using the sub private key in the subkey pair to obtain a signature result, generates a transaction credential according to the sub public key in the sub key pair and the signature result]
Lu discloses generating keys, however, Lu does not disclose:
signing, by the first wallet controller, the public first unlocking key with the private master signing key to create a signed public first unlocking key;
transmitting, from the first wallet controller to the hardware wallet, the public master signing key; and
transmitting, from the first wallet controller to the hardware wallet, the signed public first unlocking key.
Nonetheless, Maheshwari discloses signing keys:
signing, by the first wallet controller, the public first unlocking key with the private master signing key to create a signed public first unlocking key; [see at least (0052) the public key returned to the authentication server 110 is signed with the attestation (i.e. master) private key, and the authentication server 110 validates that the attestation signature over the new public key comes from the correct device.]
In addition, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art, to modify features of Lu to include the features of Maheshwari. The signing technique as taught by Maheshwari would have been readily available to the hardware wallet system of Lu. A person a having the ordinary skill in the art would have been motivated to sign the public unlocking key generated by Lu using a signing key as taught by Maheshwari, in order to cryptographically authenticate before allowing access to data. Maheshwari teaches digitally signing keys using private keys. Because both Lu, as well as Maheshwari are in the field of secure authentication and both references addresses establishing security between devices using public and private key cryptography. Moreover, since the features disclosed by Lu, as well as Maheshwari would function in the same manner in combination as they do in their separate embodiments, it would be reasonable to conclude that their resulting combination would be predictable. Accordingly, the claimed subject matter is obvious over Lu/Maheshwari.
The combination of Lu in view of Maheshwari discloses generating and singing keys, however, the above combination of Lu, Maheshwari does not disclose:
transmitting, from the first wallet controller to the hardware wallet, the public master signing key; and
transmitting, from the first wallet controller to the hardware wallet, the … public first unlocking key.
However, Black discloses transmitting keys:
a master signing key pair comprising a private master signing key and a public master signing key; [see at least (0093) The master private key 222 may be used to derive a master public key 223, which may be a parent public key to all public account keys 225A-B on the trusted third party 106]
transmitting, from the first wallet controller to the hardware wallet, the public master signing key; and [see at least (0074) the private transaction key(s) 206 and/or the public transaction key(s) 207 may be transmitted from the customer device 102 to the currency conversion system 104 and/or the trusted third party 106 for multi-approval transactions requiring M of N keys.]
transmitting, from the first wallet controller to the hardware wallet, the … public first unlocking key. [see at least (0074) the private transaction key(s) 206 and/or the public transaction key(s) 207 may be transmitted from the customer device 102 to the currency conversion system 104 and/or the trusted third party 106 for multi-approval transactions requiring M of N keys]
In addition, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art, to modify Lu, Maheshwari to include the features of Black. One would have been motivated to do so, in order to securely authenticate and authorize cryptographic keys to control access to data. Lu, Maheshwari discloses generating and signing keys. Black teaches transmitting keys. Because Lu, Maheshwari, as well as Black are implemented in cryptocurrency and blockchain environment, and the hardware wallet of Lu, Maheshwari is analogous to the cryptographic system of Black that performs the transmitting of keys and could themselves be programmed to carry out that function as taught by Black. Moreover, since the features disclosed by Lu, Maheshwari, as well as Black would function in the same manner in combination as they do in their separate embodiments, it would be reasonable to conclude that their resulting combination would be predictable. Accordingly, the claimed subject matter is obvious over Lu, Maheshwari/Black.
Claims 2-3, 7-8 are rejected under 35 U.S.C. 103 as being unpatentable over Lu in view of Maheshwari in view of Black, as applied to claim 1 above, and further in view of Rapowitz (US 20230252456 A1).
Regarding Claim 2. Lu, Maheshwari, Black discloses the limitations of Claim 1. Lu further discloses:
storing, by the hardware wallet, the public master signing key; [see at least (0013) a second sub key pair generating module which is configured to generate the sub key pair according to the sub key index in the transaction instruction and the master key stored in the security storage module via the key deriving algorithm when the receiving module receives the transaction instruction sent by the upper computer. (0017) a digital currency private key is stored in the hardware, in this way, the digital currency private key is safer.]
storing, by the hardware wallet, the … public first unlocking key; [see at least (0013) a second sub key pair generating module which is configured to generate the sub key pair according to the sub key index in the transaction instruction and the master key stored in the security storage module via the key deriving algorithm when the receiving module receives the transaction instruction sent by the upper computer. (0017) a digital currency private key is stored in the hardware, in this way, the digital currency private key is safer.]
storing, by the hardware wallet the public first unlocking key. [see at least (0013) a second sub key pair generating module which is configured to generate the sub key pair according to the sub key index in the transaction instruction and the master key stored in the security storage module via the key deriving algorithm when the receiving module receives the transaction instruction sent by the upper computer. (0017) a digital currency private key is stored in the hardware, in this way, the digital currency private key is safer.]
Maheshwari further discloses signing keys:
the signed public key [see at least (0052) the public key returned to the authentication server 110 is signed with the attestation private key, and the authentication server 110 validates that the attestation signature over the new public key comes from the correct device.]
In addition, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art, to modify Lu, Maheshwari, Black to include the additional features of Maheshwari. One would have been motivated to do so, in order to securely authenticate and authorize cryptographic keys to control access to data. Lu, Maheshwari, Black evidently discloses generating keys. Maheshwari teaches digitally signing keys using private keys. Because both Lu, Maheshwari, Black as well as Maheshwari are implemented through field of secure authentication and both references addresses establishing security between devices using public and private key cryptography, the signing technique as taught by Maheshwari would have been readily available to the hardware wallet system of Lu, Maheshwari, Black. A person a having the ordinary skill in the art would have been motivated to sign the public unlocking key generated by Lu, Maheshwari, Black, using a signing key as taught by Maheshwari, in order to cryptographically authenticate before allowing access to data. Moreover, since the subject matter is merely a combination of old features, and in the combination each element would have performed the same function it performed separately, one having ordinary skill in the art before the effective filing date would have recognized that the results of the combination were predictable.
The above combination of Lu in view of Maheshwari in view of Black discloses generating and singing keys, however, the above combination of Lu, Maheshwari, and Black does not disclose:
decrypting, from the signed public first unlocking key, the public first unlocking key, by the public master signing key master signing key; and
However, Rapowitz discloses decrypting key:
decrypting, from the signed public first unlocking key, the public first unlocking key, by the public master signing key master signing key; and [see at least (0040) An encrypted wallet private key and/or an encrypted seed phrase can be decrypted using the oracle public key. The user device 102 can encrypt 485 the wallet private key and/or the seed phrase using oracle public key prior to sending the oracle, and can decrypt the wallet private key and/or the seed phrase using oracle public key when it receives it from the oracle.]
In addition, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art, to modify Lu, Maheshwari, Black to include the features of Rapowitz. A person a having the ordinary skill in the art would have been motivated to decrypt the public unlocking key generated by Lu, Maheshwari, Black, using a decryption key as taught by Rapowitz, in order to store the key in a system. Rapowitz teaches decrypting keys. Because both Lu, Maheshwari, Black as well as Rapowitz are implemented through field of secure authentication and both references addresses establishing security between devices using public and private key cryptography, the decrypting technique as taught by Rapowitz would have been readily available to the hardware wallet system of Lu, Maheshwari, Black. Moreover, since the features disclosed by Lu, Maheshwari, Black, as well as Rapowitz would function in the same manner in combination as they do in their separate embodiments, it would be reasonable to conclude that their resulting combination would be predictable. Accordingly, the claimed subject matter is obvious over Lu, Maheshwari, Black/Rapowitz.
Regarding Claim 3. Lu, Maheshwari, Black, Rapowitz discloses the limitations of Claim 2. Maheshwari further discloses:
setting, by a user input component of the hardware wallet, a first user personal identification number (PIN) and storing the first user PIN. [see at least (0024) The user device 104 and/or wallet 109 use the authentication server 110 to authenticate the identity of the user 102 when the user uses the user device 104 based on one or more authenticators collected on the device (e.g., device-based user authenticators or authentication data). This identity authentication of the user 102 may be used to enhance the security of the user device 104. For instance, the authentication server 110 may be used to authenticate the user 102 in order to unlock the user device 104 (e.g., using a personal identification number (PIN) or password or facial recognition of the user 102 to unlock a mobile phone).]
Note: MPEP 2144.01 sets forth that it is proper to take into account not only specific teachings of the reference but also the inferences which one skilled in the art would reasonably be expected to draw therefrom. Here, it is reasonable to infer that in order for the user to use PIN, the user needs to create (i.e. setting) the PIN, and the PIN needs to be stored. And, therefore one of skill in the art would have understood the reference to teach the limitation.
In addition, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art, to modify Lu, Maheshwari, Black, Rapowitz to include the additional features of Maheshwari. A person a having the ordinary skill in the art would have been motivated to set the PIN on the device/wallet as disclosed by Lu, Maheshwari, Black, using authentication technique taught by Maheshwari, in order to authenticate before allowing access to data. Maheshwari teaches using PIN for user authentication. Because both Lu, Maheshwari, Black, Rapowitz as well as Maheshwari are implemented through field of secure authentication and both references addresses establishing security between devices using public and private key cryptography, the authentication technique as taught by Maheshwari would have been readily available to the hardware wallet system of Lu, Maheshwari, Black. Moreover, since the subject matter is merely a combination of old features, and in the combination each element would have performed the same function it performed separately, one having ordinary skill in the art before the effective filing date would have recognized that the results of the combination were predictable.
Regarding Claim 7. Lu, Maheshwari, Black, Rapowitz discloses the limitations of Claim 3. Rapowitz further discloses:
authorizing unlocking of the hardware wallet to allow access to secured data comprising cryptocurrency, the authorizing comprising: [see at least (0034) The oracle 110 can access 430 a decentralized ledger, e.g., blockchain 104, comprising data indicative of activity of the wallet. To do so, in certain implementations the recovery request can include a public key associated with addresses of particular assets/transactions within the wallet.]
generating, by the first wallet controller, a first wallet unlocking command; [see at least (0035) The oracle 110 can then transmit 440, to the user device 102, a request for confirmation that a client associated with the wallet completed the one or more transactions. This step can include the knowledge-based authentication steps described herein. The request for confirmation can include questions about prior transactions using the wallet or about general information related to the wallet.]
signing, by the first wallet controller, the first wallet unlocking command with the private first unlocking key to generate a first signed wallet unlocking command; and [see at least (0033) The oracle private key can be used to encrypt information transferred between the oracle 110 and the user device 102, including the seed phrases transmitted for account recovery.]
Note: MPEP 2144.01 sets forth that it is proper to take into account not only specific teachings of the reference but also the inferences which one skilled in the art would reasonably be expected to draw therefrom. Here, it is reasonable to infer that encrypting information is singing the command. And, therefore one of skill in the art would have understood the reference to teach the limitation.
transmitting, by the first wallet controller, the first signed wallet unlocking command to the hardware wallet. [see at least (0034) The recovery request can include the oracle private key generated and transmitted to the device in steps 415 and 420, respectively. At this point, the oracle 110 can review information related to the wallet that is being recovered. To do so, the oracle 110 can leverage the information about the account, which is information that can be used to authenticate the user]
Note: MPEP 2144.01 sets forth that it is proper to take into account not only specific teachings of the reference but also the inferences which one skilled in the art would reasonably be expected to draw therefrom. Here, it is reasonable to infer recovery request is the same as unlocking command that has been transmitted to the appropriate device for authentication. And, therefore one of skill in the art would have understood the reference to teach the limitation.
In addition, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art, to modify Lu, Maheshwari, Black, Rapowitz to include the additional features of Rapowitz. A person a having the ordinary skill in the art would have been motivated to authenticate the user to allow access to the wallet data as disclosed by Lu, Maheshwari, Black, Rapowitz, using authentication technique taught by Rapowitz, in order to authenticate before allowing access to data. Lu, Maheshwari, Black, Rapowitz evidently discloses generating keys. Rapowitz authorizing access to wallet data. Because both Lu, Maheshwari, Black, Rapowitz as well as Rapowitz are implemented through field of secure authentication and both references addresses establishing security between devices using public and private key cryptography, the authentication technique as taught by Rapowitz would have been readily available to the hardware wallet system of Lu, Maheshwari, Black, Rapowitz. Moreover, since the subject matter is merely a combination of old features, and in the combination each element would have performed the same function it performed separately, one having ordinary skill in the art before the effective filing date would have recognized that the results of the combination were predictable.
Regarding Claim 8. Lu, Maheshwari, Black, Rapowitz discloses the limitations of Claim 7. Lu further discloses:
accessing the secured data comprising cryptocurrency, the accessing occurring after the authorizing unlocking of the hardware wallet and comprising: [see at least Figs. 2-3 (0062) goes to Step 220 when an account balance inquiring instruction is received;]
Maheshwari further discloses entering PIN to verify user:
prompting, by the hardware wallet, a user to enter a personal identification number; [see at least (0038) Upon receiving the authentication request, the DAV service 116 verifies that the issuer 124 supports the authenticators included in the request (e.g., the types of authentication information, such as PIN/password information, fingerprint information, or facial recognition information) based on the issuer-approved authentication data 122 at 306.]
receiving, by the hardware wallet, the personal identification number; [see at least (0036) Authenticators may include biometric sensors (e.g., the fingerprint authenticator 234 and facial recognition authenticator 236) and/or PIN or password-based verification.]
verifying, by the hardware wallet, that the received personal identification number is correct; [see at least (0038) At 308, the DAV service 116 further verifies that the account with which the authentication request is associated is enrolled in the DAV service 116 based on the enrolled account data 120. If both verifications are successful, the DAV service 116 generates a DAV transaction ID (e.g., a DS transaction ID as defined in the EMV 3DS protocol) …the user identity at 310.]
in response to the verifying: decrypting, from the signed wallet unlocking command, the first wallet unlocking command, by the public first unlocking key to reveal the first wallet unlocking command; and executing, by the hardware wallet, the first wallet unlocking command. [see at least (0045) at 320, the issuer 124 sends a result request to the DAV service 116 and/or payment network 114 generally and the CNP authentication layer 112 to inform those parties that the authentication of the user was successful. The success of this authentication is required for the wallet 109 to proceed to the third step of the registration process (e.g., registration of the user's account and/or card and device authenticator with DAV service).]
Note: MPEP 2144.01 sets forth that it is proper to take into account not only specific teachings of the reference but also the inferences which one skilled in the art would reasonably be expected to draw therefrom. Here, it is reasonable to the process of registration would require same type of authentication process to access the wallet data. And, therefore one of skill in the art would have understood the reference to teach the limitation.
In addition, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art, to modify Lu, Maheshwari, Black, Rapowitz to include the additional features of Maheshwari. A person a having the ordinary skill in the art would have been motivated to set the PIN on the device/wallet as disclosed by Lu, Maheshwari, Black, using authentication technique taught by Maheshwari, in order to authenticate before allowing access to data. Maheshwari teaches using PIN for user authentication. Because both Lu, Maheshwari, Black, Rapowitz as well as Maheshwari are implemented through field of secure authentication and both references addresses establishing security between devices using public and private key cryptography, the authentication technique as taught by Maheshwari would have been readily available to the hardware wallet system of Lu, Maheshwari, Black. Moreover, since the subject matter is merely a combination of old features, and in the combination each element would have performed the same function it performed separately, one having ordinary skill in the art before the effective filing date would have recognized that the results of the combination were predictable.
Claims 4-6 are rejected under 35 U.S.C. 103 as being unpatentable over Lu in view of Maheshwari, in further view of Black as applied to claim 1 above, and further in view of Tian (US 11551207 B2).
Regarding Claim 4. Lu, Maheshwari, Black discloses the limitations of Claim 1. Lu further discloses:
generating, by the … wallet controller, a … unlocking key pair comprising a private … unlocking key and a public … unlocking key; [see at least Fig. 1, (0033) the hardware wallet generates the sub key pair via the key deriving algorithm according to the master key in the security storage area and the sub key index in the transaction instruction]
The combination of Lu in view of Maheshwari in further view of Black discloses generating keys, however, the above combination of Lu, Maheshwari, Black does not disclose:
signing, by the second wallet controller the public second unlocking key with the private master signing key to create a signed public second unlocking key; and
transmitting, from the second wallet controller to the hardware wallet, the signed public second unlocking key.
transmitting, from the first wallet controller, the private master signing key to a second wallet controller;
Nonetheless, Maheshwari discloses signing keys:
signing, by the … wallet controller the public second unlocking key with the private master signing key to create a signed public second unlocking key; and [see at least (0052) the public key returned to the authentication server 110 is signed with the attestation private key, and the authentication server 110 validates that the attestation signature over the new public key comes from the correct device.]
In addition, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art, to modify Lu to include the features of Maheshwari. A person a having the ordinary skill in the art would have been motivated to sign the public unlocking key generated by Lu using a signing key as taught by Maheshwari, in order to cryptographically authenticate before allowing access to data. Lu evidently discloses generating keys. Maheshwari teaches digitally signing keys using private keys. Because both Lu, as well as Maheshwari are implemented through field of secure authentication and both references addresses establishing security between devices using public and private key cryptography, the signing technique as taught by Maheshwari would have been readily available to the hardware wallet system of Lu. Moreover, since the subject matter is merely a combination of old features, and in the combination each element would have performed the same function it performed separately, one having ordinary skill in the art before the effective filing date would have recognized that the results of the combination were predictable.
The combination of Lu in view of Maheshwari, Black discloses generating and singing keys, however, the above combination of Lu, Maheshwari, Black does not disclose:
transmitting, from the second wallet controller to the hardware wallet, the signed public second unlocking key.
transmitting, from the first wallet controller, the private master signing key to a second wallet controller;
However, Black discloses transmitting keys:
transmitting, from the … wallet controller to the hardware wallet, the signed public second unlocking key. [see at least (0074) the private transaction key(s) 206 and/or the public transaction key(s) 207 may be transmitted from the customer device 102 to the currency conversion system 104 and/or the trusted third party 106 for multi-approval transactions requiring M of N keys.]
In addition, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art, to modify Lu, Maheshwari to include the features of Black. One would have been motivated to do so, in order to securely authenticate and authorize cryptographic keys to control access to data. Lu, Maheshwari evidently discloses generating and signing keys. Black teaches transmitting keys. Because Lu, Maheshwari, as well as Black are implemented in cryptocurrency and blockchain environment, and the hardware wallet of Lu, Maheshwari is analogous to the cryptographic system of Black that performs the transmitting of keys and could themselves be programmed to carry out that function as taught by Black. Moreover, since the subject matter is merely a combination of old features, and in the combination each element would have performed the same function it performed separately, one having ordinary skill in the art before the effective filing date would have recognized that the results of the combination were predictable.
The combination of Lu in view of Maheshwari, Black discloses generating, singing, transmitting keys, however, the above combination of Lu, Maheshwari, Black does not disclose:
transmitting, from the first wallet controller, the private master signing key to a second wallet controller;
However, Tian discloses transmitting to second wallet:
transmitting, from the first wallet controller, the private master signing key to a second wallet controller; [see at least (13/28-33) the transfer of the subset of first user secondary wallet private keys may be performed by first encrypting the subset of first user secondary wallet private keys to provide an encrypted subset of first user secondary wallet private keys, and then transmitting the encrypted subset of first user secondary wallet private keys to the second user device 412.]
In addition, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art, to modify Lu, Maheshwari, Black to include the features of Tian. A person a having the ordinary skill in the art would have been motivated to transmit the private master signing key generated by Lu, Maheshwari, Black, by encrypting and transmitting to a another wallet taught by Tian, in order to securely transmit the keys.. Lu, Maheshwari, Black evidently discloses generating keys. Tian teaches transmitting keys to a secondary wallet. Because both Lu, Maheshwari, Black as well as Tian are implemented through field of secure authentication and both references addresses establishing security between devices using public and private key cryptography, the transmitting technique as taught by Tian would have been readily available to the hardware wallet system of Lu, Maheshwari, Black. Moreover, since the features disclosed by Lu, Maheshwari, Black, as well as Tian would function in the same manner in combination as they do in their separate embodiments, it would be reasonable to conclude that their resulting combination would be predictable. Accordingly, the claimed subject matter is obvious over Lu, Maheshwari, Black/ Tian.
Regarding Claim 5. Lu, Maheshwari, Black discloses the limitations of Claim 4. Maheshwari further discloses:
wherein transmitting the private master signing key from the first wallet controller to the second wallet controller comprises accessing a same trusted execution environment (TEE) by the first wallet controller and the second wallet controller. [see at least (0037) The trusted execution environment (TEE) 228 is a secure area of the user device 204 (e.g., a secure area of the processor, memory, and/or other components of the device) that is configured to protect the integrity of the code and/or data processed and stored therein, including the authenticators 234, 236, and 238 and associated authentication keys 232. The key master 230 in the TEE 228 is configured to manage the authentication keys 232 and communicate with the wallet app 206 via the keystore service 226.]
In addition, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art, to modify Lu, Maheshwari, Black, Tian to include the features of Maheshwari. A person a having the ordinary skill in the art would have been motivated to use the TEE environment to transmit the key generated by Lu using a TEE environment key as taught by Maheshwari, in order to cryptographically authenticate before allowing access to data. Lu, Maheshwari, Black, Tian evidently discloses generating keys. Maheshwari teaches implementing TEE for secure interaction. Because both Lu, Maheshwari, Black, Tian, as well as Maheshwari are implemented through field of secure authentication and both references addresses establishing security between devices using public and private key cryptography, the TEE environment as taught by Maheshwari would have been readily available to the hardware wallet system of Lu, Maheshwari, Black, Tian. Moreover, since the subject matter is merely a combination of old features, and in the combination each element would have performed the same function it performed separately, one having ordinary skill in the art before the effective filing date would have recognized that the results of the combination were predictable.
Regarding Claim 6. Lu, Maheshwari, Black, Tian discloses the limitations of Claim 4. Lu further disclose:
storing, by the hardware wallet, the … public … unlocking key; [see at least (0013) a second sub key pair generating module which is configured to generate the sub key pair according to the sub key index in the transaction instruction and the master key stored in the security storage module via the key deriving algorithm when the receiving module receives the transaction instruction sent by the upper computer. (0017) a digital currency private key is stored in the hardware, in this way, the digital currency private key is safer.]
storing, by the hardware wallet, the public … unlocking key. [see at least (0013) a second sub key pair generating module which is configured to generate the sub key pair according to the sub key index in the transaction instruction and the master key stored in the security storage module via the key deriving algorithm when the receiving module receives the transaction instruction sent by the upper computer. (0017) a digital currency private key is stored in the hardware, in this way, the digital currency private key is safer.]
The combination of Lu, in view of Maheshwari, in further view of Black, in further view of Tian discloses storing keys, however, the above combination of Lu, Maheshwari, Black, Tian does not disclose: the signed public key
decrypting, from the signed public first unlocking key, the public first unlocking key, by the public master signing key master signing key;
However, Maheshwari discloses signing keys:
the signed public key [see at least (0052) the public key returned to the authentication server 110 is signed with the attestation private key, and the authentication server 110 validates that the attestation signature over the new public key comes from the correct device.]
In addition, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art, to modify Lu, Maheshwari, Black, Tian to include the additional features of Maheshwari. A person a having the ordinary skill in the art would have been motivated to sign the public unlocking key generated by Lu, Maheshwari, Black, Tian, using a signing key as taught by Maheshwari, in order to cryptographically authenticate before allowing access to data. Lu, Maheshwari, Black, Tian, evidently discloses generating keys. Maheshwari teaches digitally signing keys using private keys. Because both Lu, Maheshwari, Black, Tian as well as Maheshwari are implemented through field of secure authentication and both references addresses establishing security between devices using public and private key cryptography, the signing technique as taught by Maheshwari would have been readily available to the hardware wallet system of Lu, Maheshwari, Black, Tian. Moreover, since the subject matter is merely a combination of old features, and in the combination each element would have performed the same function it performed separately, one having ordinary skill in the art before the effective filing date would have recognized that the results of the combination were predictable.
The combination of Lu, in view of Maheshwari, in further view of Black, in further view of Tian discloses storing keys, and signing keys, however, the above combination of Lu, Maheshwari, Black, Tian does not disclose:
decrypting, from the … public … unlocking key, the public … unlocking key, by the public master signing key; and
However, Tian discloses decrypting key:
decrypting, from the … public … unlocking key, the public … unlocking key, by the public master signing key; and [see at least (13/63-67) the second user device 412 may operate to first decrypt the encrypted first user secondary wallet private keys using decryption techniques known in the art, and may then store the first user secondary wallet private keys in a storage]
In addition, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art, to modify Lu, Maheshwari, Black, Tian to include the additional features of Tian. One would have been motivated to do so, in order to securely authenticate and authorize cryptographic keys to control access to data. Lu, Maheshwari, Black, Tian evidently discloses generating keys. Tian teaches decrypting keys. Because both Lu, Maheshwari, Black, Tian as well as Tian are implemented through field of secure authentication and both references addresses establishing security between devices using public and private key cryptography, the decrypting technique as taught by Tian would have been readily available to the hardware wallet system of Lu, Maheshwari, Black, Tian. A person a having the ordinary skill in the art would have been motivated to decrypt the public unlocking key generated by Lu, Maheshwari, Black, Tian, using a decryption key as taught by Tian, in order to store the key in a system. Moreover, since the subject matter is merely a combination of old features, and in the combination each element would have performed the same function it performed separately, one having ordinary skill in the art before the effective filing date would have recognized that the results of the combination were predictable.
Claims 9-10 are rejected under 35 U.S.C. 103 as being unpatentable over Lu in view of Maheshwari, in further view of Black as applied to claim 1 above, and further in view of Tian, in further view of Rapowitz (US 20230252456 A1).
Regarding Claim 9. Lu, Maheshwari, Black, Tian discloses the limitations of Claim 6. Tian further discloses:
second wallet controller [see at least (13/28-33) the transfer of the subset of first user secondary wallet private keys may be performed by first encrypting the subset of first user secondary wallet private keys to provide an encrypted subset of first user secondary wallet private keys, and then transmitting the encrypted subset of first user secondary wallet private keys to the second user device 412.]
In addition, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art, to modify Lu, Maheshwari, Black, Tian to include the additional features of Tian. A person a having the ordinary skill in the art would have been motivated to transmit the private master signing key generated by Lu, Maheshwari, Black, Tian, by encrypting and transmitting to a another wallet taught by Tian, in order to securely transmit the keys. Lu, Maheshwari, Black, Tian evidently discloses generating keys. Tian teaches transmitting keys to a secondary wallet. Because both Lu, Maheshwari, Black, Tian as well as Tian are implemented through field of secure authentication and both references addresses establishing security between devices using public and private key cryptography, the transmitting technique as taught by Tian would have been readily available to the hardware wallet system of Lu, Maheshwari, Black, Tian. Moreover, since the subject matter is merely a combination of old features, and in the combination each element would have performed the same function it performed separately, one having ordinary skill in the art before the effective filing date would have recognized that the results of the combination were predictable.
The combination of Lu in view of Maheshwari, in further view of Black, in further view of Tian discloses accessing data, however, the above combination of Lu, Maheshwari, Black, Tian does not disclose:
authorizing unlocking of the hardware wallet to allow access to secured data comprising cryptocurrency, the authorizing comprising:
generating, by the second wallet controller, a second wallet unlocking command;
signing, by the second wallet controller the second wallet unlocking command with the private second unlocking key to generate a second signed wallet unlocking command; and
transmitting, by the second wallet the second signed wallet unlocking command to the hardware wallet.
However, Rapowitz discloses allowing access to data:
authorizing unlocking of the hardware wallet to allow access to secured data comprising cryptocurrency, the authorizing comprising: [see at least (0034) The oracle 110 can access 430 a decentralized ledger, e.g., blockchain 104, comprising data indicative of activity of the wallet. To do so, in certain implementations the recovery request can include a public key associated with addresses of particular assets/transactions within the wallet.]
generating, by the first wallet controller, a … wallet unlocking command; [see at least (0035) The oracle 110 can then transmit 440, to the user device 102, a request for confirmation that a client associated with the wallet completed the one or more transactions. This step can include the knowledge-based authentication steps described herein. The request for confirmation can include questions about prior transactions using the wallet or about general information related to the wallet.]
signing, by the … wallet controller, the … wallet unlocking command with the private first unlocking key to generate a first signed wallet unlocking command; and [see at least (0033) The oracle private key can be used to encrypt information transferred between the oracle 110 and the user device 102, including the seed phrases transmitted for account recovery.]
Note: MPEP 2144.01 sets forth that it is proper to take into account not only specific teachings of the reference but also the inferences which one skilled in the art would reasonably be expected to draw therefrom. Here, it is reasonable to infer that encrypting information is singing the command. And, therefore one of skill in the art would have understood the reference to teach the limitation.
transmitting, by the … wallet controller, the … signed wallet unlocking command to the hardware wallet. [see at least (0034) The recovery request can include the oracle private key generated and transmitted to the device in steps 415 and 420, respectively. At this point, the oracle 110 can review information related to the wallet that is being recovered. To do so, the oracle 110 can leverage the information about the account, which is information that can be used to authenticate the user]
Note: MPEP 2144.01 sets forth that it is proper to take into account not only specific teachings of the reference but also the inferences which one skilled in the art would reasonably be expected to draw therefrom. Here, it is reasonable to infer recovery request is the same as unlocking command that has been transmitted to the appropriate device for authentication. And, therefore one of skill in the art would have understood the reference to teach the limitation.
In addition, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art, to modify Lu, Maheshwari, Black, Tian to include the features of Rapowitz. A person a having the ordinary skill in the art would have been motivated to authenticate the user to allow access to the wallet data as disclosed by Lu, Maheshwari, Black, Tian, using authentication technique taught by Rapowitz, in order to authenticate before allowing access to data.. Lu, Maheshwari, Black, Tian evidently discloses generating keys. Rapowitz authorizing access to wallet data. Because both Lu, Maheshwari, Black, Tian as well as Rapowitz are implemented through field of secure authentication and both references addresses establishing security between devices using public and private key cryptography, the authentication technique as taught by Rapowitz would have been readily available to the hardware wallet system of Lu, Maheshwari, Black, Tian. Moreover, since the subject matter is merely a combination of old features, and in the combination each element would have performed the same function it performed separately, one having ordinary skill in the art before the effective filing date would have recognized that the results of the combination were predictable.
Regarding Claim 10. Lu, Maheshwari, Black, Tian, Rapowitz discloses the limitations of Claim 9. Lu further discloses:
accessing the secured data comprising cryptocurrency, the accessing occurring after the authorizing unlocking of the hardware wallet and comprising: [see at least Figs. 2-3 (0062) goes to Step 220 when an account balance inquiring instruction is received;]
The combination of Lu in view of Maheshwari, in further view of Black, in further view of Tian, in further view of Rapowitz discloses accessing data, however, the above combination of Lu, Maheshwari, Black, Tian, Rapowitz does not disclose:
prompting, by the hardware wallet, a user to enter a personal identification number;
receiving, by the hardware wallet, the personal identification number;
verifying, by the hardware wallet, that the received personal identification number is correct;
in response to the verifying: decrypting, from the signed wallet unlocking command, the second wallet unlocking command, by the public first unlocking key to reveal the second wallet unlocking command; and
executing, by the hardware wallet, the second wallet unlocking command.
Maheshwari discloses entering PIN to verify user:
prompting, by the hardware wallet, a user to enter a personal identification number; [see at least (0038) Upon receiving the authentication request, the DAV service 116 verifies that the issuer 124 supports the authenticators included in the request (e.g., the types of authentication information, such as PIN/password information, fingerprint information, or facial recognition information) based on the issuer-approved authentication data 122 at 306.]
receiving, by the hardware wallet, the personal identification number; [see at least (0036) Authenticators may include biometric sensors (e.g., the fingerprint authenticator 234 and facial recognition authenticator 236) and/or PIN or password-based verification.]
verifying, by the hardware wallet, that the received personal identification number is correct; [see at least (0038) At 308, the DAV service 116 further verifies that the account with which the authentication request is associated is enrolled in the DAV service 116 based on the enrolled account data 120. If both verifications are successful, the DAV service 116 generates a DAV transaction ID (e.g., a DS transaction ID as defined in the EMV 3DS protocol) …the user identity at 310.]
in response to the verifying: decrypting, from the signed wallet unlocking command, the … wallet unlocking command, by the public … unlocking key to reveal the first wallet unlocking command; and executing, by the hardware wallet, the … wallet unlocking command. [see at least (0045) at 320, the issuer 124 sends a result request to the DAV service 116 and/or payment network 114 generally and the CNP authentication layer 112 to inform those parties that the authentication of the user was successful. The success of this authentication is required for the wallet 109 to proceed to the third step of the registration process (e.g., registration of the user's account and/or card and device authenticator with DAV service).]
Note: MPEP 2144.01 sets forth that it is proper to take into account not only specific teachings of the reference but also the inferences which one skilled in the art would reasonably be expected to draw therefrom. Here, it is reasonable to the process of registration would require same type of authentication process to access the wallet data. And, therefore one of skill in the art would have understood the reference to teach the limitation.
In addition, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art, to modify Lu, Maheshwari, Black, Rapowitz to include the additional features of Maheshwari. A person a having the ordinary skill in the art would have been motivated to set the PIN on the device/wallet as disclosed by Lu, Maheshwari, Black, using authentication technique taught by Maheshwari, in order to authenticate before allowing access to data. Maheshwari teaches using PIN for user authentication. Because both Lu, Maheshwari, Black, Rapowitz as well as Maheshwari are implemented through field of secure authentication and both references addresses establishing security between devices using public and private key cryptography, the authentication technique as taught by Maheshwari would have been readily available to the hardware wallet system of Lu, Maheshwari, Black. Moreover, since the subject matter is merely a combination of old features, and in the combination each element would have performed the same function it performed separately, one having ordinary skill in the art before the effective filing date would have recognized that the results of the combination were predictable.
The combination of Lu in view of Maheshwari, in further view of Black, in further view of Tian, in further view of Rapowitz discloses accessing data, however, the above combination of Lu, Maheshwari, Black, Tian, Rapowitz does not disclose:
second wallet controller
However, Tian discloses second wallet:
second wallet controller [see at least (13/28-33) the transfer of the subset of first user secondary wallet private keys may be performed by first encrypting the subset of first user secondary wallet private keys to provide an encrypted subset of first user secondary wallet private keys, and then transmitting the encrypted subset of first user secondary wallet private keys to the second user device 412.]
In addition, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art, to modify Lu, Maheshwari, Black, Tian, Rapowitz to include the additional features of Tian. A person a having the ordinary skill in the art would have been motivated to transmit the private master signing key generated by Lu, Maheshwari, Black, Tian, Rapowitz, by encrypting and transmitting to a another wallet taught by Tian, in order to securely transmit the keys.. Lu, Maheshwari, Black, Tian, Rapowitz evidently discloses generating keys. Tian teaches transmitting keys to a secondary wallet. Because both Lu, Maheshwari, Black, Tian, Rapowitz as well as Tian are implemented through field of secure authentication and both references addresses establishing security between devices using public and private key cryptography, the transmitting technique as taught by Tian would have been readily available to the hardware wallet system of Lu, Maheshwari, Black, Tian, Rapowitz. Moreover, since the subject matter is merely a combination of old features, and in the combination each element would have performed the same function it performed separately, one having ordinary skill in the art before the effective filing date would have recognized that the results of the combination were predictable.
Claim(s) 11-12 are rejected under 35 U.S.C. 103 as being unpatentable over Lu in view of Maheshwari, in further view of Black as applied to claim 1 above, and further in view of Rapowitz, in further view of Hamann (US 20190215164 A1).
Regarding Claim 11. Lu, Maheshwari, Black, Rapowitz discloses the limitations of Claim 7. The combination of Lu in view of Maheshwari, in further view of Black as applied to claim 1 above, and further in view of Rapowitz discloses signing, and transmitting keys. However, the above combination of Lu, Maheshwari, Black, Rapowitz does not disclose:
revoking the first unlocking key pair, the revoking comprising:
generating, by the first wallet controller, a first unlocking key pair revocation command;
signing, by the first wallet controller, the first unlocking key pair revocation command with at least one of (i) the private master signing key and (ii) the private first unlocking key to generate a first signed unlocking key pair revocation command; and
transmitting, by the first wallet controller, the first signed unlocking key pair revocation command to the hardware wallet.
However, Hamann discloses revoking keys:
revoking the first unlocking key pair, the revoking comprising: [see at least Fig. 4 (0038) each service provider system 200 may be required to delete retrieved public keys every few minutes, few hours, few days, etc. as appropriate for a particular application. By way of example, should a private key be suspected of being compromised, then the user can send a signed request to revoke the stored public key 401. This request to revoke may be signed by the current or existing private key.]
generating, by the first wallet controller, a first unlocking key pair revocation command; [see at least (0038) then the user can send a signed request to revoke the stored public key 401.]
signing, by the first wallet controller, the first unlocking key pair revocation command with at least one of (i) the private master signing key and (ii) the private first unlocking key to generate a first signed unlocking key pair revocation command; and [see at least (0038) This request to revoke may be signed by the current or existing private key.]
transmitting, by the first wallet controller, the first signed unlocking key pair revocation command to the hardware wallet. [see at least (0038) Once validated, the public key may be marked as revoked]
Note: MPEP 2144.01 sets forth that it is proper to take into account not only specific teachings of the reference but also the inferences which one skilled in the art would reasonably be expected to draw therefrom. Here, it is reasonable to infer validating would require a system to validate the system before the key can be revoked. And, therefore one of skill in the art would have understood the reference to teach the limitation.
In addition, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art, to modify Lu, Maheshwari, Black, Rapowitz to include the features of Hamann. A person a having the ordinary skill in the art would have been motivated to revoke the key generated by Lu, Maheshwari, Black, Rapowitz, using a revoking key technique as taught by Hamann, in order to cryptographically authenticate before allowing access to data. Lu, Maheshwari, Black, Rapowitz, evidently discloses generating keys. Hamann teaches digitally revoking keys. Because both Lu, Maheshwari, Black, Rapowitz as well as Hamann are implemented through field of secure authentication and both references addresses establishing security between devices using public and private key cryptography, the revoking technique as taught by Maheshwari would have been readily available to the hardware wallet system of Lu, Maheshwari, Black, Rapowitz. Moreover, since the features disclosed by Lu, Maheshwari, Black, Rapowitz, as well as Hamann would function in the same manner in combination as they do in their separate embodiments, it would be reasonable to conclude that their resulting combination would be predictable. Accordingly, the claimed subject matter is obvious over Lu, Maheshwari, Black, Rapowitz/ Hamann.
Regarding Claim 12. Lu, Maheshwari, Black, Rapowitz, Hamann discloses the limitations of Claim 11. Hamann further discloses:
receiving, by the hardware wallet the first signed unlocking key pair revocation command; [see at least (0038) By way of example, should a private key be suspected of being compromised, then the user can send a signed request to revoke the stored public key 401. This request to revoke may be signed by the current or existing private key. Once validated, the public key may be marked as revoked, for instance, in the distributed datastore.]
decrypting, from the first signed unlocking key pair revocation command, the first unlocking key pair revocation command, by at least one of (i) the public master signing key and
(ii) the public first unlocking key to reveal the first unlocking key pair revocation command; and [see at least (0037) The service provider system receiving the signed request fetches the public key for the given identity from, for instance, internal storage 314 and uses the public key to decrypt the request 315. If the keys match, and the request can be decrypted, then the request is considered valid and the requested resource is fetched 317, for instance, via a resource controller 202.]
deleting, by the hardware wallet, the public first unlocking key from the hardware wallet. [see at least (0032) At this point, the public key and private key pair is discarded by the secure device, that is, they deleted from the secure device, and no longer available on the device.]
In addition, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art, to modify Lu, Maheshwari, Black, Rapowitz, Hamann to include the additional features of Hamann. A person a having the ordinary skill in the art would have been motivated to revoke the key generated by Lu, Maheshwari, Black, Rapowitz, Hamann, using a revoking key technique as taught by Hamann, in order to cryptographically authenticate before allowing access to data. Lu, Maheshwari, Black, Rapowitz, Hamann, evidently discloses generating keys. Hamann teaches digitally revoking keys. Because both Lu, Maheshwari, Black, Rapowitz, Hamann as well as Hamann are implemented through field of secure authentication and both references addresses establishing security between devices using public and private key cryptography, the revoking technique as taught by Hamann would have been readily available to the hardware wallet system of Lu, Maheshwari, Black, Rapowitz, Hamann. Moreover, since the subject matter is merely a combination of old features, and in the combination each element would have performed the same function it performed separately, one having ordinary skill in the art before the effective filing date would have recognized that the results of the combination were predictable.
Claim 17 is rejected under 35 U.S.C. 103 as being unpatentable over Lu (US 20200226586 A1), in view of Maheshwari (US 20200372495 A1), in further view of Black (US 20190220857 A1), in further view of Rapowitz (US 20230252456 A1).
Regarding claim 17. Lu discloses:
wherein the processor is configured to: generate a master signing key pair comprising a private master signing key and a public master signing key; [see at least Fig. 1, (0037) generates the master key from the key seed via the first preset algorithm, stores the master key into the security storage area]
generate a first unlocking key pair comprising a private first unlocking key and a public first unlocking key; [see at least Fig. 1, (0033) the hardware wallet generates the sub key pair via the key deriving algorithm according to the master key in the security storage area and the sub key index in the transaction instruction]
Lu discloses generating keys, however, Lu does not disclose:
a transceiver configured to electronically communicate with the hardware wallet to communicate cryptographic keys to the hardware wallet;
a digital storage unit configured to securely store at least a portion of the cryptographic keys;
a processor in electronic communication with the digital storage unit and the transceiver,
sign, the public first unlocking key with the private master signing key to create a signed public first unlocking key;
transmit, by the transceiver, the public master signing key to the hardware wallet; and
transmit, by the transceiver, the signed public first unlocking key to the hardware wallet,
wherein the processor stores the private master signing key and the private first unlocking key in the digital storage unit, and
wherein the private master signing key and the private first unlocking key are not transmitted from the cryptocurrency wallet controller to the hardware wallet.
Nonetheless, Maheshwari discloses signing keys:
sign, the public first unlocking key with the private master signing key to create a signed public first unlocking key; [see at least (0052) the public key returned to the authentication server 110 is signed with the attestation private key, and the authentication server 110 validates that the attestation signature over the new public key comes from the correct device.]
In addition, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art, to modify Lu to include the features of Maheshwari. A person a having the ordinary skill in the art would have been motivated to sign the public unlocking key generated by Lu using a signing key as taught by Maheshwari, in order to cryptographically authenticate before allowing access to data. Lu evidently discloses generating keys. Maheshwari teaches digitally signing keys using private keys. Because both Lu, as well as Maheshwari are implemented through field of secure authentication and both references addresses establishing security between devices using public and private key cryptography, the signing technique as taught by Maheshwari would have been readily available to the hardware wallet system of Lu. Moreover, since the features disclosed by Lu, as well as Maheshwari would function in the same manner in combination as they do in their separate embodiments, it would be reasonable to conclude that their resulting combination would be predictable. Accordingly, the claimed subject matter is obvious over Lu/Maheshwari.
The combination of Lu in view of Maheshwari discloses generating and singing keys, however, the above combination of Lu, Maheshwari does not disclose:
a transceiver configured to electronically communicate with the hardware wallet to communicate cryptographic keys to the hardware wallet;
a digital storage unit configured to securely store at least a portion of the cryptographic keys;
a processor in electronic communication with the digital storage unit and the transceiver,
transmit, by the transceiver, the public master signing key to the hardware wallet; and
transmit, by the transceiver, the public master signing key to the hardware wallet; and
transmit, by the transceiver, the signed public first unlocking key to the hardware wallet,
wherein the processor stores the private master signing key and the private first unlocking key in the digital storage unit, and
wherein the private master signing key and the private first unlocking key are not transmitted from the cryptocurrency wallet controller to the hardware wallet.
However, Black discloses transmitting keys:
transmit, by the transceiver, the public master signing key to the hardware wallet; and [see at least (0074) the private transaction key(s) 206 and/or the public transaction key(s) 207 may be transmitted from the customer device 102 to the currency conversion system 104 and/or the trusted third party 106 for multi-approval transactions requiring M of N keys.]
transmit, by the transceiver, the signed public first unlocking key to the hardware wallet, [see at least (0074) the private transaction key(s) 206 and/or the public transaction key(s) 207 may be transmitted from the customer device 102 to the currency conversion system 104 and/or the trusted third party 106 for multi-approval transactions requiring M of N keys.]
wherein the private master signing key and the private first unlocking key are not transmitted from the cryptocurrency wallet controller to the hardware wallet. [see at least (0074) the private transaction key(s) 206 and/or the public transaction key(s) 207 may be transmitted from the customer device 102 to the currency conversion system 104 and/or the trusted third party 106 for multi-approval transactions requiring M of N keys.]
Note: MPEP 2144.01 sets forth that it is proper to take into account not only specific teachings of the reference but also the inferences which one skilled in the art would reasonably be expected to draw therefrom. Here, it is reasonable to infer that one would be able to choose which keys gets transmitted, which reads onto the private master key may not be transmitted. And, therefore one of skill in the art would have understood the reference to teach the limitation.
The combination of Lu in view of Maheshwari, in further view of Black discloses generating, signing, and transmitting keys, however, the above combination of Lu, Maheshwari does not disclose:
a transceiver configured to electronically communicate with the hardware wallet to communicate cryptographic keys to the hardware wallet;
a digital storage unit configured to securely store at least a portion of the cryptographic keys;
a processor in electronic communication with the digital storage unit and the transceiver,
transmit, by the transceiver, the public master signing key to the hardware wallet; and
wherein the processor stores the private master signing key and the private first unlocking key in the digital storage unit, and
However, Rapowitz discloses storing keys:
a transceiver configured to electronically communicate with the hardware wallet to communicate cryptographic keys to the hardware wallet; [see at least (0028) The device 102 can also include a communication interface 316 that includes a transceiver 318. The communication interface 316 and/or transceiver 318 can be used to transmit and/or receive the data]
a digital storage unit configured to securely store at least a portion of the cryptographic keys; [see at least (0032) G. 4A, process 400 can begin with the oracle 110 receiving 405 a recovery request from a device to store a wallet private key and/or a seed phrase associated with the user wallet.]
a processor in electronic communication with the digital storage unit and the transceiver,
transmit, by the transceiver, the public master signing key to the hardware wallet; and [see at least (0027) FIG. 2 is a diagram of an example blockchain wallet environment, according to the present disclosure. A hierarchical deterministic wallet is a tree of public and private keys that are used to store data, such as cryptocurrency data. At the wallet 202 level, a seed phrase can generate a master private key 204, and the master private key 204 can generate additional branches of trees by generating private keys for use with signing a transaction. The chain node 206 branch includes the one or more private keys (e.g., key 208 and key 210) that can be used for signing transactions.]
wherein the processor stores the private master signing key and the private first unlocking key in the digital storage unit, and [see at least (0032) G. 4A, process 400 can begin with the oracle 110 receiving 405 a recovery request from a device to store a wallet private key and/or a seed phrase associated with the user wallet.]
In addition, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art, to modify Lu, Maheshwari, Black to include the features of Rapowitz. A person a having the ordinary skill in the art would have been motivated to decrypt the public unlocking key generated by Lu, Maheshwari, Black, using a decryption key as taught by Rapowitz, in order to store the key in a system. Lu, Maheshwari, Black evidently discloses generating keys. Rapowitz teaches decrypting keys. Because both Lu, Maheshwari, Black as well as Rapowitz are implemented through field of secure authentication and both references addresses establishing security between devices using public and private key cryptography, the decrypting technique as taught by Rapowitz would have been readily available to the hardware wallet system of Lu, Maheshwari, Black. Moreover, since the features disclosed by Lu, Maheshwari, Black, as well as Rapowitz would function in the same manner in combination as they do in their separate embodiments, it would be reasonable to conclude that their resulting combination would be predictable. Accordingly, the claimed subject matter is obvious over Lu, Maheshwari, Black/Rapowitz.
Claim 18-20 is rejected under 35 U.S.C. 103 as being unpatentable over Lu (US 20200226586 A1), in view of Maheshwari (US 20200372495 A1), in further view of Black (US 20190220857 A1), in further view of Rapowitz (US 20230252456 A1) as applied to Claim 17, in further view of Tian (US 11551207 B2).
Regarding Claim 18. Lu, Maheshwari, Black, Rapowitz discloses the limitations of Claim 17. The combination of Lu in view of Maheshwari, in further view of Black, in further view of Rapowitz, discloses generating, signing, transmitting, and storing keys. However, the above combination of Lu, Maheshwari, Black, Rapowitz does not disclose:
wherein the processor is further configured to transmit, from the first wallet controller, the private master signing key to a second wallet controller.
However, the Tian discloses transmitting keys to a second wallet controller:
wherein the processor is further configured to transmit, from the first wallet controller, the private master signing key to a second wallet controller. [see at least (13/28-33) the transfer of the subset of first user secondary wallet private keys may be performed by first encrypting the subset of first user secondary wallet private keys to provide an encrypted subset of first user secondary wallet private keys, and then transmitting the encrypted subset of first user secondary wallet private keys to the second user device 412.]
In addition, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art, to modify Lu, Maheshwari, Black, Rapowitz to include the features of Tian. A person a having the ordinary skill in the art would have been motivated to transmit the private master signing key generated by Lu, Maheshwari, Black, Rapowitz, by encrypting and transmitting to a another wallet taught by Tian, in order to securely transmit the keys. Lu, Maheshwari, Black, Rapowitz, evidently discloses generating keys. Tian teaches transmitting keys to a secondary wallet. Because both Lu, Maheshwari, Black, Rapowitz, as well as Tian are implemented through field of secure authentication and both references addresses establishing security between devices using public and private key cryptography, the transmitting technique as taught by Tian would have been readily available to the hardware wallet system of Lu, Maheshwari, Black, Rapowitz. Moreover, since the features disclosed by Lu, Maheshwari, Black, Rapowitz, as well as Tian would function in the same manner in combination as they do in their separate embodiments, it would be reasonable to conclude that their resulting combination would be predictable. Accordingly, the claimed subject matter is obvious over Lu, Maheshwari, Black, Rapowitz/ Tian.
Regarding Claim 19. Lu, Maheshwari, Black, Rapowitz, Tian discloses the limitations of Claim 18. Lu further discloses:
generating, by the … wallet controller, a second unlocking key pair comprising a private second unlocking key and a public second unlocking key; [see at least Fig. 1, (0033) the hardware wallet generates the sub key pair via the key deriving algorithm according to the master key in the security storage area and the sub key index in the transaction instruction]
The combination of Lu in view of Maheshwari, in further view of Black, in further view of Rapowitz, Tian, discloses generating keys. However, the above combination of Lu, Maheshwari, Black, Rapowitz, Tian does not disclose:
signing, by the second wallet controller the public second unlocking key with the private master signing key to create a signed public second unlocking key; and
transmitting, from the second wallet controller to the hardware wallet, the signed public second unlocking key.
transmitting, from the first wallet controller, the private master signing key to a second wallet controller;
Nonetheless, Maheshwari discloses signing keys:
signing, by the … wallet controller the public second unlocking key with the private master signing key to create a signed public second unlocking key; and [see at least (0052) the public key returned to the authentication server 110 is signed with the attestation private key, and the authentication server 110 validates that the attestation signature over the new public key comes from the correct device.]
In addition, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art, to modify Lu, Maheshwari, Black, Rapowitz, Tian to include additional the features of Maheshwari. A person a having the ordinary skill in the art would have been motivated to sign the public unlocking key generated by Lu, Maheshwari, Black, Rapowitz, Tian, using a signing key as taught by Maheshwari, in order to cryptographically authenticate before allowing access to data. Lu, Maheshwari, Black, Rapowitz, Tian evidently discloses generating keys. Maheshwari teaches digitally signing keys using private keys. Because both Lu, Maheshwari, Black, Rapowitz, Tian, as well as Maheshwari are implemented through field of secure authentication and both references addresses establishing security between devices using public and private key cryptography, the signing technique as taught by Maheshwari would have been readily available to the hardware wallet system of Lu, Maheshwari, Black, Rapowitz, Tian. Moreover, since the subject matter is merely a combination of old features, and in the combination each element would have performed the same function it performed separately, one having ordinary skill in the art before the effective filing date would have recognized that the results of the combination were predictable.
The combination of Lu in view of Maheshwari, in further view of Black, in further view of Rapowitz, Tian, discloses generating, signing keys. However, the above combination of Lu, Maheshwari, Black, Rapowitz, Tian does not disclose:
transmitting, from the second wallet controller to the hardware wallet, the signed public second unlocking key.
transmitting, from the first wallet controller, the private master signing key to a second wallet controller;
However, Black discloses transmitting keys:
transmitting, from the … wallet controller to the hardware wallet, the signed public second unlocking key. [see at least (0074) the private transaction key(s) 206 and/or the public transaction key(s) 207 may be transmitted from the customer device 102 to the currency conversion system 104 and/or the trusted third party 106 for multi-approval transactions requiring M of N keys.]
In addition, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art, to modify Lu, Maheshwari, Black, Rapowitz, Tian to include the additional features of Black. One would have been motivated to do so, in order to securely authenticate and authorize cryptographic keys to control access to data. Lu, Maheshwari, Black, Rapowitz, Tian evidently discloses generating and signing keys. Black teaches transmitting keys. Because Lu, Maheshwari, Black, Rapowitz, Tian, as well as Black are implemented in cryptocurrency and blockchain environment, and the hardware wallet of Lu, Maheshwari, Black, Rapowitz, Tian is analogous to the cryptographic system of Black that performs the transmitting of keys and could themselves be programmed to carry out that function as taught by Black. Moreover, since the subject matter is merely a combination of old features, and in the combination each element would have performed the same function it performed separately, one having ordinary skill in the art before the effective filing date would have recognized that the results of the combination were predictable.
The combination of Lu in view of Maheshwari, in further view of Black, in further view of Rapowitz, Tian, discloses generating, signing keys. However, the above combination of Lu, Maheshwari, Black, Rapowitz, Tian does not disclose:
transmitting, from the first wallet controller, the private master signing key to a second wallet controller;
However, Tian discloses transmitting to second wallet:
transmitting, from the first wallet controller, the private master signing key to a second wallet controller; [see at least (13/28-33) the transfer of the subset of first user secondary wallet private keys may be performed by first encrypting the subset of first user secondary wallet private keys to provide an encrypted subset of first user secondary wallet private keys, and then transmitting the encrypted subset of first user secondary wallet private keys to the second user device 412.]
In addition, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art, to modify Lu, Maheshwari, Black, Rapowitz, Tian to include the additional features of Tian. A person a having the ordinary skill in the art would have been motivated to transmit the private master signing key generated by Lu, Maheshwari, Black Rapowitz, Tian, by encrypting and transmitting to a another wallet taught by Tian, in order to securely transmit the keys. Tian teaches transmitting keys to a secondary wallet. Because both Lu, Maheshwari, Black, Rapowitz, Tian as well as Tian are implemented through field of secure authentication and both references addresses establishing security between devices using public and private key cryptography, the transmitting technique as taught by Tian would have been readily available to the hardware wallet system of Lu, Maheshwari, Black, Rapowitz, Tian. Moreover, since the subject matter is merely a combination of old features, and in the combination each element would have performed the same function it performed separately, one having ordinary skill in the art before the effective filing date would have recognized that the results of the combination were predictable.
Regarding Claim 20. Lu, Maheshwari, Black, Rapowitz, Tian discloses the limitations of Claim 19. Maheshwari further discloses:
Wherein both the first wallet controller and the second wallet controller are software applications running on a same device, wherein the transmitting from the first wallet controller the private master signing key to the second wallet controller comprises accessing a shared trusted execution environment containing the private master signing key by both the first wallet controller and the second wallet controller. [see at least (0037) The trusted execution environment (TEE) 228 is a secure area of the user device 204 (e.g., a secure area of the processor, memory, and/or other components of the device) that is configured to protect the integrity of the code and/or data processed and stored therein, including the authenticators 234, 236, and 238 and associated authentication keys 232. The key master 230 in the TEE 228 is configured to manage the authentication keys 232 and communicate with the wallet app 206 via the keystore service 226.]
In addition, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art, to modify Lu, Maheshwari, Black, Rapowitz, Tian to include the features of Maheshwari. A person a having the ordinary skill in the art would have been motivated to use the TEE environment to transmit the key generated by Lu, Maheshwari, Black, Rapowitz, Tian using a TEE environment key as taught by Maheshwari, in order to cryptographically authenticate before allowing access to data. . Maheshwari teaches implementing TEE for secure interaction. Because both Lu, Maheshwari, Black, Rapowitz, Tian, as well as Maheshwari are implemented through field of secure authentication and both references addresses establishing security between devices using public and private key cryptography, the TEE environment as taught by Maheshwari would have been readily available to the hardware wallet system of Lu, Maheshwari, Black, Rapowitz, Tian. Moreover, since the subject matter is merely a combination of old features, and in the combination each element would have performed the same function it performed separately, one having ordinary skill in the art before the effective filing date would have recognized that the results of the combination were predictable.
Relevant Prior Art Not Relied Upon
The prior art made of record and not relied upon which, however, is considered pertinent to applicant's disclosure:
US 20230344649 A1 Zamani; Mahdi et al. OFFLINE INTERACTION SYSTEM AND METHOD - A first device receiving, from a second device, an interaction request message comprising an amount and a second device certificate. The first device can verify the second device certificate using a server computer public key corresponding to a server computer private key. A trusted application in a secure element of the first device can determine whether or not the amount is less than an offline amount stored in the secure element. If the amount is less than the offline amount, the trusted application can determine an updated offline amount based on the amount. The trusted application can generate an interaction response message comprising the amount and a trusted application certificate. The first device can then provide the interaction response message to the second device.
US 20210399900 A1 Andreina; Sebastien et al. METHOD AND SYSTEM FOR A TRUSTED EXECUTION ENVIRONMENT-BASED PROOF OF STAKE PROTOCOL - A method prevents posterior-corruption long-range attacks in a proof of stake blockchain protocol in a blockchain network. The method includes: generating, by a blockchain node associated with a TEE device, a signing key pair, including a public key and a private key; remotely-attesting, by the blockchain node, a trusted enclave application, including generating an attestation certificate; and issuing, by the blockchain node, a registration transaction to distribute the attestation certificate; the registration transaction specifying an amount of mining stake purchased by the blockchain validator. Once the registration transaction is confirmed, the TEE device becomes enabled for mining blocks in the blockchain network.
US 20150052063 A1 Feraud; Alban Method for the Mutual Authentication of Entities Having Previously Initiated an Online Transaction - Devices for enabling authentication may include a first stage in which a first electronic device of the first entity communicates with a second electronic device of the second entity via a telecommunications network. During the first stage, the first electronic device generates a first token and transmits it from the first electronic device to the second electronic device via the network; and the second electronic device generates a third token and transmits the third token to the first electronic device via the network. During a second stage, authenticating a first non-authenticated entity as being the second entity as a function of a second token contained in a first portable electronic device of the first non-authenticated entity occurs; and authenticating a non-authenticated entity as being the first entity as a function of a fourth token contained in a second portable electronic device of the second non-authenticated entity also occurs.
US 20200067897 A1 Smirnoff; Sergey et al. HYBRID INTEGRATION OF SOFTWARE DEVELOPMENT KIT WITH SECURE EXECUTION ENVIRONMENT - A portable communication device may include a mobile application executing in an application execution environment and a secure application executing in a trusted execution environment. The secure application may receive, from the mobile application, a storage request to store sensitive data. The storage request may include an encrypted data type identifier and an encrypted sensitive data. The secure application may decrypt the encrypted data type identifier and the encrypted sensitive data using a transport key, and re-encrypt the sensitive data using a storage key. The re-encrypted sensitive data can then be stored in a memory of the portable communication device which is outside the trusted execution environment.
US 20240354753 A1 NESS; Benjamin J. et al. METHODS AND APPARATUS FOR PROVABLE BACKUP CONFIRMATION FOR DIGITAL WALLETS USING KEY SHARDS - An apparatus includes a custodial mechanism that receive, from each compute device from at a quorum, an encrypted shard associated with a private key of a digital wallet and a cryptographic proof. The encrypted shard can be generated using an encryption key for the compute device. The cryptographic proof indicates that the compute device can decrypt the encrypted shard using a decryption key associated with that compute device and without revealing a value of the private key for the digital wallet. The apparatus generates, for each compute device, a cryptographic proof verification based on the encrypted shard for that compute device and an encryption witness for the private key of the digital wallet. The cryptographic proof verification indicates that the set of shards decrypted from the set of encrypted shards can be combined to reconstruct the private key.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MD S HYDER whose telephone number is (571)270-1820. The examiner can normally be reached Monday - Friday 8:30am - 6:00pm.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Patrick McAtee can be reached at (571) 272-7575. 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.
/M.S.H./Examiner, Art Unit 3698 02/02/2026
/PATRICK MCATEE/Supervisory Patent Examiner, Art Unit 3698