DETAILED ACTION
The present application, filed on 5/16/2024 is being examined under the AIA first inventor to file provisions.
The following is a FINAL Office Action in response to Applicant’s amendments filed on 2/27/2026.
a. Claims 1, 11-13, 16, 18 are amended
Overall, Claims 1-20 are pending and have been considered below.
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-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-10 are directed to a computer implemented method, claims 11-15 are directed to system stored on a non-transitory storage medium, and claims 16-20 are directed to a computer implemented method.
Thus, on its face, each independent claim and the associated dependent claims are directed to a statutory category of invention.
[INDEPENDENT CLAIMS]
Per Step 2A.1. Independent claim 1, is rejected under 35 USC 101 because the independent 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 below:
[A] A method comprising
[B] generating, by a key device, an address to enable transfer of one or more cryptographic tokens as part of a digital transaction;
[C] signing, by the key device, the address for authorizing the transfer;
[D] receiving the signed address by a wallet application executing on an edge device associated with the key device;
[E] verifying, by a wallet server, that the signed address received via the wallet application originated from the key device;
[F] receiving, by the wallet server from the wallet application, an identifier of a supplemental interface selected via a user interface of the edge device;
[G] establishing, by the wallet server, an encrypted communication via a network to the supplemental interface identified by the identifier, the supplemental interface being a device separate from the edge device and separate from the key device;
[H] displaying, by the supplemental interface, the communication having an option that is selectable to generate a confirmation to authorize the transfer;
[I] receiving, by the wallet server, the confirmation from the supplemental interface that the transfer of the one or more cryptographic tokens is permitted; and
[J] initiating, by the wallet server, the transfer of the one or more cryptographic tokens using the address responsive to the receiving of the confirmation.
Independent claim 1 recites: generating an address and signing the address ([B], [C]), receiving the address and verifying it ([D], [E]), receiving a supplemental interface identifier and identifying the identifier as being for a different edge device ([F], [G]), displaying an option to generate a transfer authorization ([H]), receiving the token transfer conformation and initiating the transfer ([I], [J]), which, based on the claim language and in view of the application disclosure, represents a process aimed at: “transferring cryptographic tokens as part of a digital transaction, based on a multisig authorization scheme”.
This is a combination that, under its broadest reasonable interpretation, covers agreements in the form of contracts, legal obligations, sales activities or behaviors, business relationships (e-commerce), which falls under Certain Methods of Organizing Human Activity, i.e., Commercial or Legal Interactions grouping of abstract ideas (see MPEP 2106.04(a)(2)).
Accordingly, it is concluded that independent claim 1 recites an abstract idea that corresponds to a judicial exception.
[INDEPENDENT CLAIMS – Additional Elements]
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 “by a key device,” “by a wallet server,” recite computing elements at a high level of generality, generally linking the use of a judicial exception to a particular technological environment (see MPEP 2106.05(h)), or merely using a computer as a tool to perform an abstract idea (MPEP 2106.05(f)).
These additional elements of the independent claims do not preclude from carrying out the identified abstract idea “transferring cryptographic tokens as part of a digital transaction, based on a multisig scheme”, and do not serve to integrate the identified abstract idea into a practical application.
Therefore, the additional elements of independent claim 1 do not integrate the identified abstract idea into a practical application and the claims remain a judicial exception.
Per Step 2B. Independent 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.
Overall, it is concluded that independent claim 1 is deemed ineligible.
Per Step 2A.1. Independent claim 11, is rejected under 35 USC 101 because the independent 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 11 recite an abstract idea, shown in bold below:
[A] A wallet server comprising: a processing device; and a computer-readable storage medium storing instructions that, responsive to execution by the processing device
[B] receiving a signed address from an edge device, the signed address signed by a key device associated with the edge device to enable transfer of one or more cryptographic tokens as part of a digital transaction;
[C] verifying that the signed address originated from the key device;
[D] establishing an encrypted communication based on the address for receipt by a supplemental interface comprising an independent device distinct from the edge device;
[E] receiving a confirmation from the interactive supplemental interface that the transfer of the one or more cryptographic tokens is permitted; and
[F] wherein the confirmation corresponds to an interaction with the interactive supplemental interface to select an option presented via the communication;
[G] initiating the transfer of the one or more cryptographic tokens as part of the digital transaction using the address responsive to the receiving of the confirmation.
Independent claim 11 recites: receiving a signed address from an edge device and verifying the origin of the signed address ([B], [C]), establishing a communication and obtaining transfer authorization for cryptographic tokens ([D], [E]), initiating the transfer of tokens ([G]), which, based on the claim language and in view of the application disclosure, represents a process aimed at: “transferring cryptographic tokens as part of a digital transaction, based on a multisig scheme”.
This is a combination that, under its broadest reasonable interpretation, covers agreements in the form of contracts, legal obligations, sales activities or behaviors, business relationships (e-commerce), which falls under Certain Methods of Organizing Human Activity, i.e., Commercial or Legal Interactions grouping of abstract ideas (see MPEP 2106.04(a)(2)).
Accordingly, it is concluded that independent claim 11 recites an abstract idea that corresponds to a judicial exception.
[INDEPENDENT CLAIMS – Additional Elements]
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 “wherein the confirmation corresponds to an interaction with the interactive supplemental interface to select an option presented via the communication;” as applied to the confirmation, are nothing more than (a) descriptive limitations of claim elements, such as describing the nature, structure and/or content of other claim elements, or (b) general links to the computing environment, which amount to instructions to “apply it,” or equivalent (MPEP 2106.05(f)).
These additional elements of the independent claims do not preclude from carrying out the identified abstract idea and do not serve to integrate the identified abstract idea into a practical application.
Therefore, the additional steps of independent claim 11 do not integrate the identified abstract idea into a practical application and the claims remain a judicial exception.
Per Step 2B. Independent claim 11 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.
Overall, it is concluded that independent claim 11 is deemed ineligible.
Per Step 2A.1. Independent claim 16, is rejected under 35 USC 101 because the independent 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 16 recite an abstract idea, shown in bold below:
[A] A method comprising:
[B] receiving, by a wallet server, transaction details from an edge device that are proposed for a transfer of one or more cryptographic tokens as part of a digital transaction;
[C] forming, by the wallet server, an encrypted communication for display by an interactive supplemental interface comprising an independent device distinct from the edge device associated with an address that is to participate in the transfer;
[D] receiving, by the wallet server, a confirmation from the supplemental interface that the transfer of the one or more cryptographic tokens is permitted;
[E] generating, by the wallet server, a signed authorization confirming the transaction details using at least one cryptographic key; and
[F] wherein the confirmation corresponds to an interaction with the interactive supplemental interface to select an option;
[G] transmitting, by the wallet server, the signed authorization for receipt by a key device that is configured to determine that the signed authorization originated from the wallet server and is configured to participate in the transfer as part of the digital transaction.
Independent claim 16 recites: receiving transaction details and establishing an encrypted communication ([B], [C]), receiving a confirmation for a token and generating a signed transaction authorization ([D], [E]), transmitting the signed authorization ([G]), which, based on the claim language and in view of the application disclosure, represents a process aimed at: “transferring cryptographic tokens as part of a digital transaction, based on a multisig scheme”.
This is a combination that, under its broadest reasonable interpretation, covers agreements in the form of contracts, legal obligations, sales activities or behaviors, business relationships (e-commerce), which falls under Certain Methods of Organizing Human Activity, i.e., Commercial or Legal Interactions grouping of abstract ideas (see MPEP 2106.04(a)(2)).
Accordingly, it is concluded that independent claim 16 recites an abstract idea that corresponds to a judicial exception.
[INDEPENDENT CLAIMS – Additional Elements]
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 “by a wallet” recite computing elements at a high level of generality, generally linking the use of a judicial exception to a particular technological environment (see MPEP 2106.05(h)), or merely using a computer as a tool to perform an abstract idea (MPEP 2106.05(f)). Further, the additional elements “wherein the confirmation corresponds to an interaction with the interactive supplemental interface to select an option;” as applied to the confirmation, are nothing more than (a) descriptive limitations of claim elements, such as describing the nature, structure and/or content of other claim elements, or (b) general links to the computing environment, which amount to instructions to “apply it,” or equivalent (MPEP 2106.05(f)).
These qualifiers of the independent claims do not preclude from carrying out the identified abstract idea “transferring cryptographic tokens as part of a digital transaction, based on a multisig scheme”, and do not serve to integrate the identified abstract idea into a practical application.
Therefore, the additional steps of independent claim 16 do not integrate the identified abstract idea into a practical application and the claims remain a judicial exception.
Per Step 2B. Independent claim 16 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.
Overall, it is concluded that independent claim 16 is deemed ineligible.
[DEPENDENT CLAIMS]
Dependent claim 5 recites:
displaying the address and an amount involved in the transfer of the one or more cryptographic tokens as part of the digital transaction in a user interface along with the option that is user selectable to cause generation of the confirmation and transmission of the confirmation back to the wallet server.
When considered individually, these added claim elements further elaborate on the abstract idea identified in the independent claims, because the dependent claim continues to recite the identified abstract idea: “transferring cryptographic tokens as part of a digital transaction, based on a multisig scheme”. The elements in this dependent claim are comparable to “receiving or transmitting data over a network, e.g., using the Internet to gather or provide data”, which has been recognized by a controlling court as "well-understood, routine and conventional computing functions" when claimed generically as they are in these dependent claims. Thus, it is concluded that these claim elements do not integrate the identified abstract idea (“transferring cryptographic tokens as part of a digital transaction, based on a multisig scheme”) into a practical application (see MPEP 2106.05(d) II)).
The dependent claim elements have the same relationship to the underlying abstract idea (“transferring cryptographic tokens as part of a digital transaction, based on a multisig scheme”) as outlined in the independent claims analysis above. Thus, it is readily apparent that the dependent claim elements are not directed to any specific improvements of the independent claims and do not practically or significantly alter how the identified abstract idea would be performed. When considered as a whole, as an ordered combination, the dependent claim further elaborates on the previously identified abstract idea (“transferring cryptographic tokens as part of a digital transaction, based on a multisig scheme”).
Therefore, dependent claim 5 is deemed ineligible.
Dependent claim 6 recites:
displaying a user interface at the edge device that is configured to specify the supplemental interface that is to receive the communication.
When considered individually, these added claim elements further elaborate on the abstract idea identified in the independent claims, because the dependent claim continues to recite the identified abstract idea: “transferring cryptographic tokens as part of a digital transaction, based on a multisig scheme”. The elements in this dependent claim are comparable to “receiving or transmitting data over a network, e.g., using the Internet to gather or provide data”, which has been recognized by a controlling court as "well-understood, routine and conventional computing functions" when claimed generically as they are in these dependent claims. Thus, it is concluded that these claim elements do not integrate the identified abstract idea (“transferring cryptographic tokens as part of a digital transaction, based on a multisig scheme”) into a practical application (see MPEP 2106.05(d) II)).
The dependent claim elements have the same relationship to the underlying abstract idea (“transferring cryptographic tokens as part of a digital transaction, based on a multisig scheme”) as outlined in the independent claims analysis above. Thus, it is readily apparent that the dependent claim elements are not directed to any specific improvements of the independent claims and do not practically or significantly alter how the identified abstract idea would be performed. When considered as a whole, as an ordered combination, the dependent claim further elaborates on the previously identified abstract idea (“transferring cryptographic tokens as part of a digital transaction, based on a multisig scheme”).
Therefore, dependent claim 6 is deemed ineligible.
Dependent claim 7 recites:
displaying the address that is to participate in the transfer of the one or more cryptographic tokens as part of the digital transaction.
When considered individually, these added claim elements further elaborate on the abstract idea identified in the independent claims, because the dependent claim continues to recite the identified abstract idea: “transferring cryptographic tokens as part of a digital transaction, based on a multisig scheme”. The elements in this dependent claim are comparable to “receiving or transmitting data over a network, e.g., using the Internet to gather or provide data”, which has been recognized by a controlling court as "well-understood, routine and conventional computing functions" when claimed generically as they are in these dependent claims. Thus, it is concluded that these claim elements do not integrate the identified abstract idea (“transferring cryptographic tokens as part of a digital transaction, based on a multisig scheme”) into a practical application (see MPEP 2106.05(d) II)).
The dependent claim elements have the same relationship to the underlying abstract idea (“transferring cryptographic tokens as part of a digital transaction, based on a multisig scheme”) as outlined in the independent claims analysis above. Thus, it is readily apparent that the dependent claim elements are not directed to any specific improvements of the independent claims and do not practically or significantly alter how the identified abstract idea would be performed. When considered as a whole, as an ordered combination, the dependent claim further elaborates on the previously identified abstract idea (“transferring cryptographic tokens as part of a digital transaction, based on a multisig scheme”).
Therefore, dependent claim 7 is deemed ineligible.
Dependent claim 12 recites:
receiving an identifier of the interactive supplemental interface that is to confirm the transfer of the one or more cryptographic tokens as part of the transaction.
When considered individually, these added claim elements further elaborate on the abstract idea identified in the independent claims, because the dependent claim continues to recite the identified abstract idea: “transferring cryptographic tokens as part of a digital transaction, based on a multisig scheme”. The elements in this dependent claim are comparable to “receiving or transmitting data over a network, e.g., using the Internet to gather or provide data”, which has been recognized by a controlling court as "well-understood, routine and conventional computing functions" when claimed generically as they are in these dependent claims. Thus, it is concluded that these claim elements do not integrate the identified abstract idea (“transferring cryptographic tokens as part of a digital transaction, based on a multisig scheme”) into a practical application (see MPEP 2106.05(d) II)).
The dependent claim elements have the same relationship to the underlying abstract idea (“transferring cryptographic tokens as part of a digital transaction, based on a multisig scheme”) as outlined in the independent claims analysis above. Thus, it is readily apparent that the dependent claim elements are not directed to any specific improvements of the independent claims and do not practically or significantly alter how the identified abstract idea would be performed. When considered as a whole, as an ordered combination, the dependent claim further elaborates on the previously identified abstract idea (“transferring cryptographic tokens as part of a digital transaction, based on a multisig scheme”).
Therefore, dependent claim 12 is deemed ineligible.
Dependent claim 13 recites:
identifying the interactive supplemental interface based on a user account maintained at the wallet server, the user account associated with an entity that is to participate in the digital transaction.
When considered individually, these added claim elements further elaborate on the abstract idea identified in the independent claims, because the dependent claim continues to recite the identified abstract idea: “transferring cryptographic tokens as part of a digital transaction, based on a multisig scheme”. The elements in this dependent claim are comparable to “sorting information” i.e. comparing data, which has been recognized by a controlling court as "well-understood, routine and conventional computing functions" when claimed generically as they are in these dependent claims. Thus, it is concluded that these claim elements do not integrate the identified abstract idea (“transferring cryptographic tokens as part of a digital transaction, based on a multisig scheme”) into a practical application (see MPEP 2106.05(d) II)).
The dependent claim elements have the same relationship to the underlying abstract idea (“transferring cryptographic tokens as part of a digital transaction, based on a multisig scheme”) as outlined in the independent claims analysis above. Thus, it is readily apparent that the dependent claim elements are not directed to any specific improvements of the independent claims and do not practically or significantly alter how the identified abstract idea would be performed. When considered as a whole, as an ordered combination, the dependent claim further elaborates on the previously identified abstract idea (“transferring cryptographic tokens as part of a digital transaction, based on a multisig scheme”).
Therefore, dependent claim 13 is deemed ineligible.
Dependent claim 17 recites:
transmitting the signed authorization for receipt by the edge device, the signed authorization configured to cause the edge device to communicate the signed authorization for receipt by the key device.
When considered individually, these added claim elements further elaborate on the abstract idea identified in the independent claims, because the dependent claim continues to recite the identified abstract idea: “transferring cryptographic tokens as part of a digital transaction, based on a multisig scheme”. The elements in this dependent claim are comparable to “receiving or transmitting data over a network, e.g., using the Internet to gather or provide data”, which has been recognized by a controlling court as "well-understood, routine and conventional computing functions" when claimed generically as they are in these dependent claims. Thus, it is concluded that these claim elements do not integrate the identified abstract idea (“transferring cryptographic tokens as part of a digital transaction, based on a multisig scheme”) into a practical application (see MPEP 2106.05(d) II)).
The dependent claim elements have the same relationship to the underlying abstract idea (“transferring cryptographic tokens as part of a digital transaction, based on a multisig scheme”) as outlined in the independent claims analysis above. Thus, it is readily apparent that the dependent claim elements are not directed to any specific improvements of the independent claims and do not practically or significantly alter how the identified abstract idea would be performed. When considered as a whole, as an ordered combination, the dependent claim further elaborates on the previously identified abstract idea (“transferring cryptographic tokens as part of a digital transaction, based on a multisig scheme”).
Therefore, dependent claim 17 is deemed ineligible.
Dependent claims 2-4, 8-10, 14-15, 18-20 recite:
wherein the key device is a wallet hardware key device that is displayless.
wherein the wallet hardware key device includes one or more sensors usable to verify access of an entity to a cryptographic key maintained locally in storage that is usable to sign the address for authorizing the transfer.
wherein the verifying by the wallet server employs a public key associated with a private key used by the key device to sign the address.
wherein the user interface includes representations of a plurality of supplemental interfaces that are permitted to receive the communication.
wherein the plurality of supplemental interfaces is associated with a user account of an entity that is to participate in the digital transaction.
wherein the transfer of the one or more cryptographic tokens as part of the digital transaction is performed using a blockchain.
wherein the verifying is performed using a public key associated with a private key maintained as a cryptographic key at the key device.
wherein the key device is a wallet hardware key device that includes one or more sensors usable to verify access of an entity to a cryptographic key maintained locally in storage that is usable to sign the address for authorizing the transfer.
wherein the transaction details identify the interactive supplemental interface.
wherein the transaction details are entered through interaction with the key device and transmitted by the key device to the edge device for communication to the wallet server.
wherein the signed authorization is transmitted to the edge device for subsequent communication to the key device.
These further elements in the dependent claims do not perform any claimed method steps. They describe the nature, structure and/or content of other claim elements – the key device; the wallet server; the verifying; the suer interface; the supplemental interfaces; the transfer of tokens; the key device; the transaction details; the signed authorization – and as such, cannot change the nature of the identified abstract idea (“transferring cryptographic tokens as part of a digital transaction, based on a multisig scheme”), from a judicial exception into eligible subject matter, because they do not represent significantly more (see MPEP 2106.07). The nature, form or structure of the other claim elements themselves do not practically or significantly alter how the identified abstract idea would be performed and do not provide more than a general link to a technological environment.
Therefore, dependent claims 2-4, 8-10, 14-15, 18-20 are deemed ineligible.
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. The most significant elements, which form the abstract concept, are set forth in the independent claims. The fact that the computing devices and the dependent claims are facilitating the abstract concept is not enough to confer statutory subject matter eligibility, since their individual and combined significance do not transform the identified abstract concept at the core of the claimed invention into eligible subject matter. Therefore, it is concluded that the dependent claims of the instant application, considered individually, or as a as a whole, as an ordered combination, do not amount to significantly more (see MPEP 2106.07(a)II).
In sum, Claims 1-20 are rejected under 35 USC 101 as being directed to non-statutory subject matter.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the difference 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 the invention was made.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103(a) are summarized as follows:
i. Determining the scope and contents of the prior art.
ii. Ascertaining the differences between the prior art and the claims at issue.
iii. Resolving the level of ordinary skill in the pertinent art.
iv. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1-2, 4-14, 16-20 are rejected under 35 U.S.C. 103 as being unpatentable over Krasnyansky (US 2021/0383334), in view of Gupta et al (US 2012/0066617).
Regarding Claim 1: Krasnyansky discloses: A method comprising:
generating, by a key device, an address to enable transfer of one or more cryptographic tokens as part of a digital transaction; {see at least fig1, rc106, [0026] resource provider reads on key device) generates address for sending/receiving funds}
signing, by the key device, the address for authorizing the transfer; {see at least fig1, rc106, [0029] recommendation with 2-of-3 authorization scheme (reads on signing)}
receiving the signed address by a wallet application executing on an edge device associated with the key device; {see at least fig1, rc102, [0048] client device (reads on edge device); fig2, rc206, [0051] wallet application}
verifying, by a wallet server, that the signed address received via the wallet application originated from the key device; {see at least fig1, rc102, [0048] client device (reads on edge device); fig2, rc206, [0051] wallet application}
displaying, by
receiving, by the wallet server, the confirmation from
initiating, by the wallet server, the transfer of the one or more cryptographic tokens using the address responsive to the receiving of the confirmation. {see at least fig8B, rc842, [0131]-[0132] transfer virtual currency payment (based on BRI (MPEP 2111), reads on initiating transfer}
Krasnyansky does not disclose, however, Gupta discloses: discloses:
establishing, by the wallet server, an encrypted communication via a network to the supplemental interface identified by the identifier, the supplemental interface being a device separate from the edge device and separate from the key device; {see at least [abstract] user display, second display (reads on supplemental interface); fig1A, fig1B, rc130, [0018] user interface device (reads on independent device). The reference does not disclose the term “encrypted”. However, this difference is only found in the non-functional descriptive material and does not affect how the claimed invention functions (i.e., the descriptive material does not have any claim function in the claimed method; see MPEP 2111.05). Thus, this descriptive material will not distinguish the claimed invention from the prior art in terms of patentability.}
receiving, by the wallet server from the wallet application, an identifier of a supplemental interface selected via a user interface of the edge device; {see at least fig4, rc440, [0031] generating a display screen at a display interface (based on the BRI (MPEP 2111), implicitly reads on identifier of an interface because generating the screen implies knowing the identifier upfront)}
… the supplemental interface … {see at least [abstract] user display, second display (reads on supplemental interface)}
It would have been obvious to one of ordinary skill in the art, at the time of filing, to modify Krasnyansky to include the elements of Gupta. One would have been motivated to do so, in order to provide user with means to communicate with the system. In the instant case, Krasnyansky evidently discloses transferring cryptographic tokens based on a multisig scheme. Gupta is merely relied upon to illustrate the functionality of a supplemental interface in the same or similar context. Since both transferring cryptographic tokens based on a multisig scheme, as well as a supplemental interface are implemented through well-known computer technologies in the same or similar context, combining their features as outlined above using such well-known computer technologies (i.e., conventional software/hardware configurations), would be reasonable, according to one of ordinary skill in the art. Moreover, since the elements disclosed by Krasnyansky, as well as Gupta would function in the same manner in combination as they do in their separate embodiments, it would be concluded that their resulting combination would be predictable. Accordingly, the claimed subject matter is obvious over Krasnyansky / Gupta.
Regarding Claim 2: Krasnyansky; Gupta discloses the limitations of Claim 1. Krasnyansky further discloses:
wherein the key device is a wallet hardware key device that is displayless. {see at least fig1, rc106, [0029] webserver, application server (reads on displayless equipment)}
Regarding Claim 4: Krasnyansky; Gupta discloses the limitations of Claim 1. Krasnyansky further discloses:
wherein the verifying by the wallet server employs a public key associated with a private key used by the key device to sign the address. {see at least [0018]-[0020] public key, public key}
Regarding Claim 5: Krasnyansky; Gupta discloses the limitations of Claim 1. Krasnyansky further discloses: wherein the displaying includes
displaying the address and an amount involved in the transfer of the one or more cryptographic tokens as part of the digital transaction in a user interface along with the option that is user selectable to cause generation of the confirmation and transmission of the confirmation back to the wallet server. {see at least fig1, rc218, [0052] contingency contract with address and with amount; Fiat $35,000 (based on BRI (MPEP 2111), reads on token}
Regarding Claim 6: Krasnyansky; Gupta discloses the limitations of Claim 1. Gupta further discloses:
displaying a user interface at the edge device that is configured to specify the supplemental interface that is to receive the communication. {see at least [abstract] user display, second display (reads on supplemental interface)}
It would have been obvious to one of ordinary skill in the art, at the time of filing, to modify Krasnyansky, Gupta to include additional elements of Gupta. One would have been motivated to do so, in order to provide user with more flexibility to communicate with the system. In the instant case, Krasnyansky, Gupta evidently discloses transferring cryptographic tokens based on a multisig scheme. Gupta is merely relied upon to illustrate the additional functionality of a supplemental user interface in the same or similar context. Since the subject matter is merely a combination of old elements, 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: Krasnyansky, Gupta discloses the limitations of Claim 6. Krasnyansky further discloses: wherein the displaying of the user interface at the edge device further includes
displaying the address that is to participate in the transfer of the one or more cryptographic tokens as part of the digital transaction. {see at least fig1, rc106, [0026] resource provider reads on key device) generates address for sending/receiving funds}
Regarding Claim 8: Krasnyansky, Gupta discloses the limitations of Claim 6. Krasnyansky further discloses:
wherein the user interface includes representations of a plurality of supplemental interfaces that are permitted to receive the communication. {see at least fig2, rc206, rc210, rc214, [0059] “subtree” or other wallets (reads on receiving the same communication)}
Regarding Claim 9: Krasnyansky, Gupta discloses the limitations of Claim 8. Krasnyansky further discloses:
wherein the plurality of supplemental interfaces is associated with a user account of an entity that is to participate in the digital transaction. {see at least fig2, rc206, rc210, rc214, rc216. [0059] “subtree” or other wallets (reads on receiving the same communication and user account)}
Regarding Claim 10: Krasnyansky discloses the limitations of Claim 1. Krasnyansky further discloses:
wherein the transfer of the one or more cryptographic tokens as part of the digital transaction is performed using a blockchain. {see at least [0030]-[0033] transactions on blockchain}
Regarding Claim 11: Krasnyansky discloses: A wallet server comprising: a processing device; and a computer-readable storage medium storing instructions that, responsive to execution by the processing device, causes the processing device to perform operations including:
receiving a signed address from an edge device, the signed address signed by a key device associated with the edge device to enable transfer of one or more cryptographic tokens as part of a digital transaction; {see at least fig1, rc102, [0048] client device (reads on edge device); fig2, rc206, [0051] wallet application}
verifying that the signed address originated from the key device; {see at least fig1, rc102, [0048] client device (reads on edge device); fig2, rc206, [0051] wallet application}
receiving a confirmation from
wherein the confirmation corresponds to an interaction with the interactive supplemental interface to select an option presented via the communication; and {see at least fig3, rc302, rc310, rc312, [0067] selecting an option}
initiating the transfer of the one or more cryptographic tokens as part of the digital transaction using the address responsive to the receiving of the confirmation. {see at least fig8B, rc842, [0131]-[0132] transfer virtual currency payment (based on BRI (MPEP 2111), reads on initiating transfer}
Krasnyansky does not disclose, however, Gupta discloses: discloses:
establishing an encrypted communication based on the address for receipt by an interactive supplemental interface comprising an independent device distinct from the edge device; {see at least [abstract] user display, second display (reads on supplemental interface); fig1A, fig1B, rc130, [0018] user interface device (reads on independent device). The reference does not disclose the term “encrypted”. However, this difference is only found in the non-functional descriptive material and does not affect how the claimed invention functions (i.e., the descriptive material does not have any claim function in the claimed method; see MPEP 2111.05). Thus, this descriptive material will not distinguish the claimed invention from the prior art in terms of patentability.}
… the supplemental interactive interface … {see at least [abstract] user display, second display (reads on supplemental interface)}
It would have been obvious to one of ordinary skill in the art, at the time of filing, to modify Krasnyansky to include the elements of Gupta. In the instant case, Krasnyansky evidently discloses transferring cryptographic tokens based on a multisig scheme. Gupta is merely relied upon to illustrate the functionality of a supplemental interface in the same or similar context. Since both transferring cryptographic tokens based on a multisig scheme, as well as a supplemental interface are implemented through well-known computer technologies in the same or similar context, combining their features as outlined above using such well-known computer technologies (i.e., conventional software/hardware configurations), would be reasonable, according to one of ordinary skill in the art. Moreover, since the elements disclosed by Krasnyansky, as well as Gupta would function in the same manner in combination as they do in their separate embodiments, it would be concluded that their resulting combination would be predictable. Accordingly, the claimed subject matter is obvious over Krasnyansky / Gupta.
Regarding Claim 12: Krasnyansky, Gupta discloses the limitations of Claim 11. Gupta further discloses: wherein the operations further comprise
receiving an identifier of the interactive supplemental interface that is to confirm the transfer of the one or more cryptographic tokens as part of the transaction. {see at least fig4, rc440, [0031] generating a display screen at a display interface (based on the BRI (MPEP 2111), implicitly reads on identifier of an interface because confirming a transfer implies knowing the identifier upfront)}
It would have been obvious to one of ordinary skill in the art, at the time of filing, to modify Krasnyansky, Gupta to include additional elements of Gupta. One would have been motivated to do so, in order to provide user with more flexibility to communicate with the system. In the instant case, Krasnyansky, Gupta evidently discloses transferring cryptographic tokens based on a multisig scheme. Gupta is merely relied upon to illustrate the additional functionality of a supplemental user interface in the same or similar context. Since the subject matter is merely a combination of old elements, 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 13: Krasnyansky, Gupta discloses the limitations of Claim 11. Gupta further discloses: wherein the operations further comprise
identifying the interactive supplemental interface based on a user account maintained at the wallet server, the user account associated with an entity that is to participate in the digital transaction. {see at least fig4, rc440, [0031] generating a display screen at a display interface (based on the BRI (MPEP 2111), implicitly reads on identifier of an interface because identifying the supplemental interface implies knowing the identifier upfront)}
It would have been obvious to one of ordinary skill in the art, at the time of filing, to modify Krasnyansky, Gupta to include additional elements of Gupta. One would have been motivated to do so, in order to provide user with more flexibility to communicate with the system. In the instant case, Krasnyansky, Gupta evidently discloses transferring cryptographic tokens based on a multisig scheme. Gupta is merely relied upon to illustrate the additional functionality of a supplemental user interface in the same or similar context. Since the subject matter is merely a combination of old elements, 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 14: Krasnyansky, Gupta discloses the limitations of Claim 11. Krasnyansky further discloses:
wherein the verifying is performed using a public key associated with a private key maintained as a cryptographic key at the key device. {see at least [0018]-[0020] public key, public key}
Regarding Claim 16: Krasnyansky discloses: A method comprising:
receiving, by a wallet server, transaction details from an edge device that are proposed for a transfer of one or more cryptographic tokens as part of a digital transaction; {see at least fig1, rc102, [0048] client device (reads on edge device); fig2, rc206, [0051] wallet application}
receiving, by the wallet server, a confirmation from
wherein the confirmation corresponds to an interaction with the interactive supplemental interface to select an option; {see at least fig3, rc302, rc310, rc312, [0067] selecting an option}
generating, by the wallet server, a signed authorization confirming the transaction details using at least one cryptographic key; and {see at least fig7, rc706, [0110]-[0111] verification component (reads on signed authorization)}
transmitting, by the wallet server, the signed authorization for receipt by a key device that is configured to determine that the signed authorization originated from the wallet server and is configured to participate in the transfer as part of the digital transaction. {see at least fig7, rc706, [0110]-[0111] verification component (reads on confirmation)}
Krasnyansky does not disclose, however, Gupta discloses: discloses:
forming, by the wallet server, an encrypted communication for display by a supplemental interface associated with an address that is to participate in the transfer; {see at least [abstract] user display, second display (reads on supplemental interface)}
… the interactive supplemental interface … {see at least [abstract] user display, second display (reads on supplemental interface)}
It would have been obvious to one of ordinary skill in the art, at the time of filing, to modify Krasnyansky to include the elements of Gupta. One would have been motivated to do so, in order to provide user with more flexibility to communicate with the system. In the instant case, Krasnyansky evidently discloses transferring cryptographic tokens based on a multisig scheme. Gupta is merely relied upon to illustrate the functionality of a supplemental interface in the same or similar context. Since both transferring cryptographic tokens based on a multisig scheme, as well as a supplemental interface are implemented through well-known computer technologies in the same or similar context, combining their features as outlined above using such well-known computer technologies (i.e., conventional software/hardware configurations), would be reasonable, according to one of ordinary skill in the art. Moreover, since the elements disclosed by Krasnyansky, as well as Gupta would function in the same manner in combination as they do in their separate embodiments, it would be concluded that their resulting combination would be predictable. Accordingly, the claimed subject matter is obvious over Krasnyansky / Gupta.
Regarding Claim 17: Krasnyansky, Gupta discloses the limitations of Claim 16. Krasnyansky further discloses: wherein the transmitting includes
transmitting the signed authorization for receipt by the edge device, the signed authorization configured to cause the edge device to communicate the signed authorization for receipt by the key device. {see at least fig7, rc706, [0110]-[0111] verification component (reads on confirmation)}
Regarding Claim 18: Krasnyansky, Gupta discloses the limitations of Claim 16. Gupta further discloses:
wherein the transaction details identify the interactive supplemental interface. {see at least [abstract] user display, second display (reads on supplemental interface)}
It would have been obvious to one of ordinary skill in the art, at the time of filing, to modify Krasnyansky, Gupta to include additional elements of Gupta. One would have been motivated to do so, in order to provide user with more flexibility to communicate with the system. In the instant case, Krasnyansky, Gupta evidently discloses transferring cryptographic tokens based on a multisig scheme. Gupta is merely relied upon to illustrate the additional functionality of supplemental interface in the same or similar context. Since the subject matter is merely a combination of old elements, 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 19: Krasnyansky, Gupta discloses the limitations of Claim 16. Krasnyansky further discloses:
wherein the transaction details are entered through interaction with the key device and transmitted by the key device to the edge device for communication to the wallet server. {see at least [0064] wallet inputs (reads on entering transaction details}
Regarding Claim 20: Krasnyansky, Gupta discloses the limitations of Claim 16. Krasnyansky further discloses:
wherein the signed authorization is transmitted to the edge device for subsequent communication to the key device. {see at least [0055] authorization scheme passed to owner}
Claims 3, 15 are rejected under 35 U.S.C. 103 as being unpatentable over Krasnyansky (US 2021/0383334), in view of Gupta et al (US 2012/0066617), in further view of Safal et al (US 2006/0107067).
Regarding Claim 3: Krasnyansky, Gupta discloses the limitations of Claim 1. Krasnyansky, Gupta does not disclose, however, Safal discloses:
wherein the wallet hardware key device includes one or more sensors usable to verify access of an entity to a cryptographic key maintained locally in storage that is usable to sign the address for authorizing the transfer. {see at least fig1, fig2, fig7, [0019], [0022]-[0024], [0055] sensors for bio identification}
It would have been obvious to one of ordinary skill in the art, at the time of filing, to modify Krasnyansky, Gupta to include the elements of Safal. One would have been motivated to do so, in order to improve system security. In the instant case, Krasnyansky, Gupta evidently discloses transferring cryptographic tokens based on a multisig scheme. Safal is merely relied upon to illustrate the functionality of bio-identification for the user in the same or similar context. Since both transferring cryptographic tokens based on a multisig scheme, as well as bio-identification for the user are implemented through well-known computer technologies in the same or similar context, combining their features as outlined above using such well-known computer technologies (i.e., conventional software/hardware configurations), would be reasonable, according to one of ordinary skill in the art. Moreover, since the elements disclosed by Krasnyansky, Gupta, as well as Safal would function in the same manner in combination as they do in their separate embodiments, it would be concluded that their resulting combination would be predictable. Accordingly, the claimed subject matter is obvious over Krasnyansky, Gupta / Safal.
Regarding Claim 15: Krasnyansky, Gupta discloses the limitations of Claim 11. Krasnyansky, Gupta does not disclose, however, Safal discloses:
wherein the key device is a wallet hardware key device that includes one or more sensors usable to verify access of an entity to a cryptographic key maintained locally in storage that is usable to sign the address for authorizing the transfer. {see at least fig1, fig2, fig7, [0019], [0022]-[0024], [0055] sensors for bio identification}
It would have been obvious to one of ordinary skill in the art, at the time of filing, to modify Krasnyansky, Gupta to include the elements of Safal. One would have been motivated to do so, in order to improve system security. In the instant case, Krasnyansky, Gupta evidently discloses transferring cryptographic tokens based on a multisig scheme. Safal is merely relied upon to illustrate the functionality of bio-identification for the user in the same or similar context. Since both transferring cryptographic tokens based on a multisig scheme, as well as bio-identification for the user are implemented through well-known computer technologies in the same or similar context, combining their features as outlined above using such well-known computer technologies (i.e., conventional software/hardware configurations), would be reasonable, according to one of ordinary skill in the art. Moreover, since the elements disclosed by Krasnyansky, Gupta, as well as Safal would function in the same manner in combination as they do in their separate embodiments, it would be concluded that their resulting combination would be predictable. Accordingly, the claimed subject matter is obvious over Krasnyansky, Gupta / Safal.
The prior art made of record and not relied upon which, however, is considered pertinent to applicant's disclosure:
US 20230409400 A1 Balderas; Carlos et al. SYSTEM FOR RESOURCE ALLOCATION AND MONITORING A system for operating a distributed ledger implementation for tracking and monitoring entity resources receives a resource configuration control and configures a distributed ledger that includes multiple gateway nodes to record resource transfer activity of resource rights allocations between the entity, the user account, and combinations thereof in a blockchain. The system communicates with an oracle service to verify resource transfer requirements for each resource rights allocation. The system transfers entity resources to a first party in response to the oracle service verifying that the resource transfer requirements were met by the first party and the entity. The system writes a resource transfer record into the blockchain in response to the oracle service verifying that the resource transfer requirements were met.
US 20190164221 A1 Hill; Matthew et al. Incrementally Perfected Digital Asset Collateral Wallet A multisig digital asset wallet stores collateral for a loan between a borrower and a lender. The borrower and lender agree to loan terms including collateralization requirements. Over the course of the loan repayment period, a Loan-to-Value (LTV) ratio between the digital asset collateral and the loan principal balance will change due to fluctuations in the market exchange value of the digital asset and a declining loan principal balance due to regular loan repayments by the borrower. If the LTV exceeds the collateral requirements by an overage amount, then the borrower may sign a transaction and request signatures from other participants to withdraw funds from the multisig collateral wallet. If the LTV fails to satisfy the collateral requirements, participants may spend funds from the multisig collateral wallet to improve the LTV, catch up after a missed payment by the borrower, or pay down the loan principal.
US 20220327525 A1 Tsitrin; Vladimir et al. Address Verification, Seed Splitting and Firmware Extension for Secure Cryptocurrency Key Backup, Restore, and Transaction Signing Platform Apparatuses, Methods and Systems The Address Verification, Seed Splitting and Firmware Extension for Secure Cryptocurrency Key Backup, Restore, and Transaction Signing Platform Apparatuses, Methods and Systems (“SFTSP”) transforms contract deployment request, transaction signing request, key backup request, key recovery request inputs via SFTSP components into contract deployment response, transaction signing response, key backup response, key recovery response outputs. A transaction signing request message data structure associated with a transaction is obtained. Owner key identification parameters associated with an owner data structure associated with a verified address wallet data structure are determined. A contract address for the verified address wallet data structure is calculated as a function of a deployment factory address, a salt value for the smart contract, contract code for the smart contract, and an owner address generated using the owner key identification parameters. A contract deployment signature is validated. A transaction hash for the transaction is calculated and a transaction signature is generated and returned.
US 20190229921 A1 Pulsifer; Allen Private Multi-Secret Cryptographic Transaction System This invention is in the field of private cryptographic transactions and discloses a method to create completely private “multi-signature” transactions using a private or “zero knowledge” proving system. The method includes multiple provers, each of which create one or more proofs with completely private hidden inputs. The proofs may require that a private value must be the same in more than one proof. The invention discloses a method of ensuring this by encrypting the private input and using this as a public input to the proofs.
US 20190378119 A1 HYUGA; Masahiko et al. WALLET DEVICE FOR CRYPTOCURRENCY AND METHOD OF SIGNATURE FOR THE USE THEREOF A wallet device comprising, a central control server device to accept a trading request data from external, a transaction manage device, a hot wallet server device, a cold wallet server device and a remote signature device, the transaction manager device comprising unit to create/output transaction data conforming to the bitcoin network in the internet, is located in-between the central server device creating internal format model transaction and other devices group of hot wallet server device, cold wallet server device and the remote signature device performing to sign multi-signatures, providing more secured wallet device for cryptocurrency.
US 20240089091 A1 FERGUSON; Dexter et al. SECURE CRYPTOGRAPHIC TRANSFER USING MULTIPARTY COMPUTATION Methods and systems are disclosed herein for cryptographically secured transfer of an item. In some embodiments, the system may cause generation of multiple key shares of a private key from which a blockchain address on a blockchain is derived. The system may generate a cryptographic representation of a physical item to be transferred from the first user to the second user, the physical item corresponding to the first item. The system may cause a first amount of the first item to be transferred to the blockchain address. The system may obtain a candidate cryptographic representation from the second user. The system may generate, based on the candidate hash matching the hash of the feature vector representing the physical item, a signed message using a partial signature of the second user and another partial signature derived from the third key share.
US 20160277374 A1 REID; Thomas Alan et al. SYSTEM AND METHOD FOR SECURELY STORING AND SHARING INFORMATION The present application generally relates to systems, devices, and methods to conduct the secure exchange of encrypted data using a three-element-core mechanism consisting of the key masters, the registries and the cloud lockboxes with application programming, interfaces providing interaction with a wide variety of user-facing software applications. Together the mechanism provides full lifecycle encryption enabling cross-platform sharing of encrypted data within and between organizations, individuals, applications and devices. Control of the private key required for decryption is maintained by the information owner. More specifically, the mechanism establishes unique identities, verifies authenticity, generates and securely exchanges asymmetric encryption key pairs, encrypts, transmits, receives and decrypts data to/from cloud lockboxes; creates and appends metadata specific to the applications and retrieves and/or act upon metadata.
US 20210304197 A1 POMASSL; Rene et al. PROCESSING SYSTEM FOR PROCESSING CRYPTOCURRENCIES AND METHOD FOR PROCESSING CRYPTOCURRENCIES The present disclosure provides a processing system for processing a number of cryptocurrencies, the processing system comprising a merchant terminal configured to generate transaction information as a basis for the generation of transactions with one of the cryptocurrencies, and an automatic transaction handling processor configured to process transactions generated based on the transaction information and to automatically split and/or redistribute transferred coins and/or assets based on a predetermined transfer policy. Further, the present disclosure provides a respective method.
US 20210097528 A1 Wang; Rui BLOCKCHAIN HOT WALLET BASED ON SECURE ENCLAVE AND MULTI-SIGNATURE AUTHORIZATION Techniques to implement system and methods in which a blockchain hot wallet based on secure enclave and multi-signature authorization. A computer system may obtain, within a protected execution environment, at least a plurality of approver digital signatures, a message, and a raw blockchain transaction, verify validity of at least a subset of the plurality of approver digital signatures, verify that the message and the raw blockchain transaction match, on a condition that at least the subset of approver digital signatures are valid and that the message matches the raw blockchain transaction, use a private key to generate a digital signature over the raw blockchain transaction, and make at least the digital signature generated over the raw blockchain transaction available outside of the protected execution environment. Techniques described herein may utilize secure enclaves to implement protected execution environments.
US 20220321340 A1 Tsitrin; Vladimir et al. Address Verification, Seed Splitting and Firmware Extension for Secure Cryptocurrency Key Backup, Restore, and Transaction Signing Platform Apparatuses, Methods and Systems - The Address Verification, Seed Splitting and Firmware Extension for Secure Cryptocurrency Key Backup, Restore, and Transaction Signing Platform Apparatuses, Methods and Systems (“SFTSP”) transforms contract deployment request, transaction signing request, key backup request, key recovery request inputs via SFTSP components into contract deployment response, transaction signing response, key backup response, key recovery response outputs. A contract deployment request message data structure is obtained. Owner key identification parameters are determined. An owner public key is determined using the owner key identification parameters. An owner address is generated using the owner public key. A salt value is generated. A contract address for the smart contract is calculated as a function of the deployment factory address, the salt value, the contract code, and the owner address. An owner private key is determined using the owner key identification parameters and used to sign the contract address. A contract deployment data data structure is provided.
US 20240414004 A1 D. M. Machado; Leonardo et al. DYNAMIC KEY MANAGEMENT Methods, systems, and devices for data management are described. A custodial token platform may communicate with a client to support a multi-party computation (MPC) signature for a message. A central coordinator may receive, from the client, a request to sign a message using respective key shares generated by MPC nodes. The key shares may be generated in accordance with an access structure, where the access structure is configured based on a respective set of parameters for the MPC nodes. The central coordinator may transmit a request to execute a MPC signature using a respective key share. The central coordinator may maintain data associated with execution of the MPC signature function by a subset of the MPC nodes using the respective key shares. Additionally, the central coordinator may transmit, to the client, a result of execution of the MPC signature function by the subset of the MPC nodes.
Response to Amendments/Arguments
Applicant’s submitted remarks and arguments have been fully considered.
Applicant disagrees with the Office Action conclusions and asserts that the presented claims fully comply with the requirements of 35 U.S.C. § 101 regrading judicial exceptions. Further, Applicant is of the opinion that the prior art fails to teach Applicant’s invention.
Examiner respectfully disagrees in both regards.
With respect to Applicant’s Remarks as to the claims being rejected under 35 USC § 101.
Applicant submits:
a. The pending claims are not directed to an abstract idea.
b. The identified abstract idea is integrated into a practical application.
c. The pending claims amount to significantly more.
Furthermore, Applicant asserts that the Office has failed to meet its burden to identify the abstract idea and to establish that the identified abstract idea is not integrated into a practical application and that the pending claims do not amount to significantly more.
Examiner responds – The arguments have been considered in light of Applicants’ amendments to the claims. The arguments ARE NOT PERSUASIVE. Therefore, the rejection is maintained.
The pending claims, as a whole, are directed to an abstract idea not integrated into a practical application. This is because (1) they do not effect improvements to the functioning of a computer, or to any other technology or technical field (see MPEP 2106.05 (a)); (2) they do not apply or use the abstract idea to effect a particular treatment or prophylaxis for a disease or a medical condition (see the Vanda memo); (3) they do not apply the abstract idea with, or by use of, a particular machine (see MPEP 2106.05 (b)); (4) they do not effect a transformation or reduction of a particular article to a different state or thing (see MPEP 2106.05 (c)); (5) they do not apply or use the abstract idea in some other meaningful way beyond generally linking the use of the identified abstract idea to a particular technological environment, such that the claim as a whole is more than a drafting effort designated to monopolize the exception (see MPEP 2106.05 (e) and the Vanda memo).
In addition, the pending claims do not amount to significantly more than the abstract idea itself.
As such, the pending claims, when considered as a whole, are directed to an abstract idea not integrated into a practical application and not amounting to significantly more.
More specific:
Applicant submits “The claims are directed to a technological solution to a technological problem …”
Examiner has carefully considered, but doesn’t find Applicant’s arguments persuasive.
Identifying a technological solution to a technological problem is not an eligibility criterion (see MPEP 2106.04-07).
Thus, the rejection is proper and has been maintained.
Applicant submits “The Office Action's "transferring tokens" abstraction does not reflect what the claims are actually focused on "as a whole" in light of the specification.”
Examiner has carefully considered, but doesn’t find Applicant’s arguments persuasive.
Based on the claim language (“verifying, by a wallet server, that the signed address received via the wallet application originated from the key device; receiving, by the wallet server from the wallet application, an identifier of a supplemental interface selected via a user interface of the edge device; establishing, by the wallet server, an encrypted communication via a network to the supplemental interface identified by the identifier, the supplemental interface being a device separate from the edge device and separate from the key device; displaying, by the supplemental interface, the communication having an option that is selectable to generate a confirmation to authorize the transfer; receiving, by the wallet server, the confirmation from the supplemental interface that the transfer of the one or more cryptographic tokens is permitted; and initiating, by the wallet server, the transfer of the one or more cryptographic tokens using the address responsive to the receiving of the confirmation”) and in light of the application disclosure ([0020]-[0031], [0049]-[0050]), the claims are unambiguously directed to “transferring cryptographic tokens as part of a digital transaction, based on a multisig authorization scheme”. This is a combination that, under its broadest reasonable interpretation, covers agreements in the form of contracts, legal obligations, sales activities or behaviors, business relationships (e-commerce), which falls under Certain Methods of Organizing Human Activity, i.e., Commercial or Legal Interactions grouping of abstract ideas (see MPEP 2106.04(a)(2)).
Thus, the rejection is proper and has been maintained.
Applicant submits “Step One requires evaluation of what the claim "as a whole" is directed to and cautions against describing claims "at a high level of abstraction" that strips out the claimed technical solution”
Examiner has carefully considered, but doesn’t find Applicant’s arguments persuasive.
An examiner can describe an abstract idea at different levels of generality without affecting the patent-eligibility analysis. Cf Apple, Inc. v. Ameranth, Inc., 842 F.3d 1229, 1240--41 (Fed. Cir. 2016) ("An abstract idea can generally be described at different levels of abstraction .... The Board's slight revision of its abstract idea analysis does not impact the patentability analysis."). That is the case here. Regardless of the level of generality used to describe the abstract idea recited in claim 1, the result is the same – claim 1 recites an abstract idea. Cf Accenture Glob. Servs., GmbH v. Guidewire Software, Inc., 728 F.3d 1336, 1344 (Fed. Cir. 2013) ("Although not as broad as the district court's abstract idea of organizing data, it is nonetheless an abstract concept.").
Thus, the rejection is proper and has been maintained.
Applicant submits “Here, the specification squarely identifies a computer-security problem that arises uniquely in modem cryptographic-wallet architectures: edge devices (e.g., phones/laptops running wallet applications) may be compromised (e.g., by malware), and therefore, cannot be trusted to display or confirm transaction details accurately. Spec. [0032], [0040].”
Examiner has carefully considered, but doesn’t find Applicant’s arguments persuasive.
The quoted paragraphs disclose: “[0032] Computing devices that implement the environment 100 and the devices within the environment 100 are configurable in a variety of ways. A computing device, for instance, is configurable as a server, a desktop computer, a laptop computer, a mobile device (e.g., assuming a handheld configuration such as a tablet or mobile phone), an IoT device, a wearable device (e.g., a smart watch), an AR/VR device, and so forth. Thus, a computing device ranges from full resource devices with substantial memory and processor resources to low-resource devices with limited memory and/or processing resources. Although in instances in the following discussion reference is made to a computing device in the singular, a computing device may also represent any number of different computing devices, such as multiple servers of a server farm utilized to perform operations “over the cloud” as further described below. [0040] In an implementation, the wallet server 126 further includes functionality of a decentralized service provider that runs as a node that peers directly with a node that is executed as part of a digital wallet on an edge device. The wallet server 126 is configured to route payments on the entity’s behalf through the decentralized network 102 of FIG. 1, e.g., a blockchain network. Accordingly, the wallet server 126 may be executed as part of the decentralized network 102 or separately by a third-party system. Signing and transaction features are implemented by the wallet server 126.”
No references whatsoever to computer-security problems are disclosed.
Thus, the rejection is proper and has been maintained.
Applicant submits “The Office Action's characterization is overbroad”
Examiner has carefully considered, but doesn’t find Applicant’s arguments persuasive.
An examiner can describe an abstract idea at different levels of generality without affecting the patent-eligibility analysis. Cf Apple, Inc. v. Ameranth, Inc., 842 F.3d 1229, 1240--41 (Fed. Cir. 2016) ("An abstract idea can generally be described at different levels of abstraction .... The Board's slight revision of its abstract idea analysis does not impact the patentability analysis."). That is the case here. Regardless of the level of generality used to describe the abstract idea recited in claim 1, the result is the same – claim 1 recites an abstract idea. Cf Accenture Glob. Servs., GmbH v. Guidewire Software, Inc., 728 F.3d 1336, 1344 (Fed. Cir. 2013) ("Although not as broad as the district court's abstract idea of organizing data, it is nonetheless an abstract concept.").
Thus, the rejection is proper and has been maintained.
Applicant submits “But eligibility analysis must avoid describing claims "at a high level of abstraction, divorced from the claim language itself," and instead must evaluate whether the claims are directed to "a specific means or method that improves the relevant technology." Contour IP Holding LLC v. GoPro, Inc., slip op. at 9-10 (Fed. Cir. Sept. 9, 2024). Here, the claims recite a specific security architecture that combines cryptographic provenance verification with an encrypted, out-of-band confirmation channel to an independent device that gates the initiation of the transfer, thereby improving transaction-authorization security in the presence of an untrusted edge device. See, e.g., amended claim 1; Spec. [0032], [0040]-[004 l ], [0065], [0069].”
Examiner has carefully considered, but doesn’t find Applicant’s arguments persuasive.
See response immediately above.
Thus, the rejection is proper and has been maintained.
Applicant submits “The claims are not a "mental process"”
Examiner has carefully considered, but doesn’t find Applicant’s arguments persuasive.
The eligibility analysis in the instant office action does not make such an allegation.
Thus, the rejection is proper and has been maintained.
Applicant submits “The claims integrate the concept into a practical application – The claims provide a concrete technological improvement in secure authorization architecture.”
Examiner has carefully considered, but doesn’t find Applicant’s arguments persuasive.
First, MPEP 2106.05(a) discloses that the additional claim elements bring about “improvements to the functioning of a computer, or any other technology or technical field.”Transferring cryptographic tokens as part of a digital transaction is a pure BUSINESS problem, rather than a technology or technical field problem. As such, the limitations which have not been deemed as being part of the identified abstract idea, i.e., the “additional elements,” do not integrate the identified abstract idea into a practical application, as disclosed by MPEP 2106.05(a).
Second, MPEP 2106.04(d)(1) discloses:
An important consideration to evaluate when determining whether the claim as a whole integrates a judicial exception into a practical application is whether the claimed invention improves the functioning of a computer or other technology .... In short, first the specification should be evaluated to determine if the disclosure provides sufficient details such that one of ordinary skill in the art would recognize the claimed invention as providing an improvement. The specification need not explicitly set forth the improvement, but it must describe the invention such that the improvement would be apparent to one of ordinary skill in the art .... Second, if the specification sets forth an improvement in technology. the claim must be evaluated to ensure that the claim itself reflects the disclosed improvement. (Emphasis added)
That is, the claimed invention may integrate the judicial exception into a practical application by demonstrating that it improves the relevant existing technology although it may not be an improvement over well-understood, routine, conventional activity. (Emphasis added)
Thus, the rejection is proper and has been maintained.
Applicant submits “Here, the claims do not merely say "verify a transaction" or "authorize a transfer." They propose a specific, security-centric architecture for authorization when the edge device cannot be trusted, exactly the problem the specification identifies. Spec. [0032], [0040].”
Examiner has carefully considered, but doesn’t find Applicant’s arguments persuasive.
The quoted paragraphs disclose: “[0032] Computing devices that implement the environment 100 and the devices within the environment 100 are configurable in a variety of ways. A computing device, for instance, is configurable as a server, a desktop computer, a laptop computer, a mobile device (e.g., assuming a handheld configuration such as a tablet or mobile phone), an IoT device, a wearable device (e.g., a smart watch), an AR/VR device, and so forth. Thus, a computing device ranges from full resource devices with substantial memory and processor resources to low-resource devices with limited memory and/or processing resources. Although in instances in the following discussion reference is made to a computing device in the singular, a computing device may also represent any number of different computing devices, such as multiple servers of a server farm utilized to perform operations “over the cloud” as further described below. [0040] In an implementation, the wallet server 126 further includes functionality of a decentralized service provider that runs as a node that peers directly with a node that is executed as part of a digital wallet on an edge device. The wallet server 126 is configured to route payments on the entity’s behalf through the decentralized network 102 of FIG. 1, e.g., a blockchain network. Accordingly, the wallet server 126 may be executed as part of the decentralized network 102 or separately by a third-party system. Signing and transaction features are implemented by the wallet server 126.”
No references whatsoever to computer-security problems are disclosed.
Thus, the rejection is proper and has been maintained.
Applicant submits “These are not "insignificant extra-solution activity" recitations …”
Examiner has carefully considered, but doesn’t find Applicant’s arguments persuasive.
The eligibility analysis in the instant office action does not make such an allegation.
Thus, the rejection is proper and has been maintained.
Applicant submits “Likewise, USPTO July 2024 Example 47 recognizes eligibility where the claim as a whole improves the technical field of intrusion or anomaly detection by applying outputs to concrete network-security actions. July 2024 Subject Matter Eligibility Examples, Example 47, claim 3. Here, similarly, the claims pertain to secure communications and confirmations within a concrete architecture that prevents a compromised edge device from silently authorizing or misrepresenting a token transfer. Spec. [0032], [0040].”
Examiner has carefully considered, but doesn’t find Applicant’s arguments persuasive.
It is not proper practice to go and find a particular Example from the Office published material and use the specific arguments from that Example to determine eligibility of a particular claimed invention, unless the particular claimed invention uniquely matches (i.e. a case that involves identical or similar facts or similar legal issues) the subject matter claimed in that particular Example, which in the instant situation it does not. The Office periodically publishes Examples with detailed analyses only to serve as rational and argumentation models to determine eligibility. Each application has to be considered on its own merits. Examples provided by the Office are nothing more than the name suggests: EXAMPLES, that are to be considered or not, as they are neither laws, nor rules, nor regulations.
Thus, the rejection is proper and has been maintained.
Applicant submits “The Office Action asserts that elements such as "by a key device" and "by a wallet server" are merely generic qualifiers, and that the additional steps of receiving/processing/transmitting data are merely generic. Office Action at pp. 4-8. That analysis does not consider how the features of the claims interact as an ordered combination to address the compromised-edge-device problem identified in the specification. Spec. [0032], [0040].”
Examiner has carefully considered, but doesn’t find Applicant’s arguments persuasive.
The claims are not directed to a “key device” and a “wallet server.” The claims are directed to transferring cryptographic tokens and invoke a “key device” and a “wallet server” as tools to facilitate the transfer.
Thus, the rejection is proper and has been maintained.
Applicant submits “THE ORDERED COMBINATION RECITES AN INVENTIVE CONCEPT THAT IS NOT SHOWN TO BE WELL-UNDERSTOOD, ROUTINE, OR CONVENTIONAL.”
Examiner has carefully considered, but doesn’t find Applicant’s arguments persuasive.
Applicant appears to refer to the provisions of the Berkheimer Memo. In essence, the Berkheimer Memo requires that, if an Examiner finds that certain claim feature are “well-known, routine or conventional,” the conclusion has to be accompanied by factual proof. Because the eligibility analysis in the instant Office Action has not arrived at such a conclusion, no factual proof is required (see MPEP 2106.05(d); MPEP 2106.07(a); MPEP 2106.04(a)(2)).
The eligibility analysis in the instant office action has not made such a determination.
Thus, the rejection is proper and has been maintained.
Applicant submits “To the extent the Office disagrees with the above analysis, the claims recite "significantly more" under Step 2B.”
Examiner has carefully considered, but doesn’t find Applicant’s arguments persuasive.
The eligibility analysis in the instant office action has determined at Step 2B:
Per Step 2B. Independent claims 1, 11,16 do 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.
Overall, it is concluded that independent claims 1, 11, 16 are deemed ineligible.
Thus, the rejection is proper and has been maintained.
Applicant submits “Here, the ordered combination is not a generic "token transfer" implementation.”
Examiner has carefully considered, but doesn’t find Applicant’s arguments persuasive.
The eligibility analysis in the instant office action does not make such an allegation.
Thus, the rejection is proper and has been maintained.
Applicant submits “The Office Action does not cite evidence establishing that the ordered combination, i.e., an encrypted, out-of-band server communication to a selected independent device for interactive confirmation that gates initiation of the transfer, is well-understood, routine, or conventional.”
Examiner has carefully considered, but doesn’t find Applicant’s arguments persuasive.
Applicant appears to refer to the provisions of the Berkheimer Memo. In essence, the Berkheimer Memo requires that, if an Examiner finds that certain claim feature are “well-known, routine or conventional,” the conclusion has to be accompanied by factual proof. Because the eligibility analysis in the instant Office Action has not arrived at such a conclusion, no factual proof is required (see MPEP 2106.05(d); MPEP 2106.07(a); MPEP 2106.04(a)(2)).
The eligibility analysis in the instant office action has not made such a determination.
Thus, the rejection is proper and has been maintained.
Applicant submits “Instead, it characterizes the claimed features at a high level as generic "receiving/transmitting data over a network."”
Examiner has carefully considered, but doesn’t find Applicant’s arguments persuasive.
An examiner can describe an abstract idea at different levels of generality without affecting the patent-eligibility analysis. Cf Apple, Inc. v. Ameranth, Inc., 842 F.3d 1229, 1240--41 (Fed. Cir. 2016) ("An abstract idea can generally be described at different levels of abstraction .... The Board's slight revision of its abstract idea analysis does not impact the patentability analysis."). That is the case here. Regardless of the level of generality used to describe the abstract idea recited in claim 1, the result is the same – claim 1 recites an abstract idea. Cf Accenture Glob. Servs., GmbH v. Guidewire Software, Inc., 728 F.3d 1336, 1344 (Fed. Cir. 2013) ("Although not as broad as the district court's abstract idea of organizing data, it is nonetheless an abstract concept.").
Thus, the rejection is proper and has been maintained.
Applicant submits “Furthermore, the dependent claims further reinforce that the claimed subject matter is rooted in technical security (e.g., displayless wallet hardware key device; sensors to verify access to cryptographic keys; public-key verification; whitelisting permitted supplemental interfaces; blockchain transfer), which are not mere "labels," …”
Examiner has carefully considered, but doesn’t find Applicant’s arguments persuasive.
The eligibility analysis in the instant office action does not make such an allegation.
Thus, the rejection is proper and has been maintained.
It follows from the above that there are no meaningful limitations in the claims that transform the judicial exception into a patent eligible application such that the claims amount to significantly more than the judicial exception itself. Therefore, the rejection under 35 U.S.C. § 101 is maintained.
With respect to Applicant’s Remarks as to the claims being rejected under 35 USC § 112(b).
The rejection is withdrawn, as a result of the amendments.
With respect to Applicant’s Remarks as to the claims being rejected under 35 USC § 103.
Applicant submits that the prior art of record does not disclose “receiving, by the wallet server, the confirmation from the supplemental interface that the transfer of the one or more cryptographic tokens is permitted”
Examiner has carefully considered, but doesn’t find Applicant’s arguments persuasive.
Krasnyansky discloses:
receiving, by the wallet server, the confirmation from
Therefore, Krasnyansky discloses the claim limitation. Thus, the rejection is proper and has been maintained.
Applicant submits that the prior art of record does not disclose “receiving, by the wallet server from the wallet application, an identifier of a supplemental interface selected via a user interface of the edge device;”
Examiner has carefully considered, but doesn’t find Applicant’s arguments persuasive.
Gupta discloses:
receiving, by the wallet server from the wallet application, an identifier of a supplemental interface selected via a user interface of the edge device; {see at least fig4, rc440, [0031] generating a display screen at a display interface (based on the BRI (MPEP 2111), implicitly reads on identifier of an interface because generating the screen implies knowing the identifier upfront)}
Therefore, Gupta discloses the claim limitation. Thus, the rejection is proper and has been maintained.
Applicant submits that the prior art of record does not disclose “establishing, by the wallet server, an encrypted communication via a network to the supplemental interface identified by the identifier, the supplemental interface being a device separate from the edge device and separate from the key device”
Examiner has carefully considered, but doesn’t find Applicant’s arguments persuasive.
Gupta discloses:
establishing, by the wallet server, an encrypted communication via a network to the supplemental interface identified by the identifier, the supplemental interface being a device separate from the edge device and separate from the key device; {see at least [abstract] user display, second display (reads on supplemental interface); fig1A, fig1B, rc130, [0018] user interface device (reads on independent device). The reference does not disclose the term “encrypted”. However, this difference is only found in the non-functional descriptive material and does not affect how the claimed invention functions (i.e., the descriptive material does not have any claim function in the claimed method; see MPEP 2111.05). Thus, this descriptive material will not distinguish the claimed invention from the prior art in terms of patentability.}
Therefore, Gupta discloses the claim limitation. Thus, the rejection is proper and has been maintained.
The other arguments presented by Applicant continually point back to the above arguments as being the basis for the arguments against the other 103 rejections, as the other arguments are presented only because those claims depend from the independent claims, and the main argument above is presented against the independent claims. Therefore, it is believed that all arguments put forth have been addressed by the points above.
Examiner has reviewed and considered all of Applicant’s remarks. The changes of the grounds for rejection, if any, have been necessitated by Applicant’s extensive amendments to the claims. Therefore, the rejection is maintained, necessitated by the extensive amendments and by the fact that the rejection of the claims under 35 USC § 101 has not been overcome.
Conclusion
THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any extension fee pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Inquiries
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Radu Andrei whose telephone number is 313.446.4948. The examiner can normally be reached on Monday – Friday 8:30am – 5pm EST. 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.
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.
As disclosed in MPEP 502.03, communications via Internet e-mail are at the discretion of the applicant. Without a written authorization by applicant in place, the USPTO will not respond via Internet e-mail to any Internet correspondence which contains information subject to the confidentiality requirement as set forth in 35 U.S.C. 122. A paper copy of such correspondence will be placed in the appropriate patent application. The following is a sample authorization form which may be used by applicant:
“Recognizing that Internet communications are not secure, I hereby authorize the USPTO to communicate with me concerning any subject matter of this application by electronic mail. I understand that a copy of these communications will be made of record in the application file.”
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Status information for published applications may be obtained from Patent Center information webpage. Status information for unpublished applications is available to registered users through Patent Center information webpage only.
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.
Any response to this action should be mailed to:
Commissioner of Patents and Trademarks
P.O. Box 1450
Alexandria, VA 22313-1450
or faxed to 571-273-8300
/Radu Andrei/
Primary Examiner, AU 3698
Prosecution Insights