DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Status of Claims
This is the first office action on the merits in response to the application filed on 10/28/2024.
Claims 1-20 are currently pending and have been examined.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more.
Subject Matter Eligibility Criteria – Step 1:
Claims 1-13 are directed to a method, claims 14-19 are directed to a system, and claim 20 is directed an article of manufacture. Therefore, these claims fall within the four statutory categories of invention.
Subject Matter Eligibility Criteria – Step 2A – Prong One:
Regarding Prong One of Step 2A of the Alice/Mayo test, the claim limitations are to be analyzed to determine whether, under their broadest reasonable interpretation, they “recite” a judicial exception or in other words whether a judicial exception is “set forth” or “described” in the claims. MPEP 2106.04(II)(A)(1). An “abstract idea” judicial exception is subject matter that falls within at least one of the following groups: a) certain methods of organizing human activity, b) mental processes, and/or c) mathematical concepts. MPEP 2106.04(a).
Representative independents claims 1, 14, and 20 include limitations that recite at least one abstract idea.
Claims 1, 14, and 20 are directed to the abstract idea of “ presenting, at a client device associated with a user, a user interface for a non-custodial wallet application configured for managing cryptographic keys associated with user-held assets on the client device; establishing, at the client device, a policy threshold condition within the non-custodial wallet to facilitate rule-based control over transactions involving the user-held assets; enabling, at the client device, a user of the non-custodial wallet to define and configure rules governing the spending of the user-held assets, the rules including predefined conditions for transaction approval; verifying the rules independently at both the client device and a server backend for the non-custodial wallet application during a transaction initiation process, wherein the server backend hosts verification code for the rules; initiating, at the client device, a transaction request involving the user-held assets, subject to the predefined conditions; transmitting the transaction request to the server backend for rule verification, the server backend performing an authorization process based on the rules without signing the transaction; and in response to successful rule verification at the server backend, transmitting a secure portion of a cryptographic key from the server backend to the client device, the secure portion enabling cryptographic transaction signing.” Under its broadest reasonable interpretation, this claim is managing and controlling financial transactions with predefined rules, and hence falls under organizing human activity (i.e., as fundamental economic practices).
Dependent Claims:
Claims 2 and 15 recites: wherein the predefined conditions include a policy threshold condition that establishes the required level of authorization for executing transactions involving the user-held assets; further describes the abstract idea of organizing human activity (i.e., as fundamental economic practices).
Claims 3 and 16 recites: recording transaction details and behavioral data associated with the user-held assets, wherein the recorded behavioral data contributes to the generation of user-specific non-fungible tokens (NFTs) representing user activity within the non-custodial wallet application; further describes the abstract idea of organizing human activity (i.e., as fundamental economic practices).
Claims 4 and 17 recites: synchronizing the rules between the client device and the server backend, and enabling rule changes to be exclusively applied through the client device; further describes the abstract idea of organizing human activity (i.e., as fundamental economic practices).
Claims 5 and 18 recites: enforcing the policy threshold condition to ensure secure and customizable transactions involving the user-held assets within the non-custodial wallet application; further describes the abstract idea of organizing human activity (i.e., as fundamental economic practices).
Claims 6 and 19 recites: wherein the cryptographic key is securely decrypted on the client device using user-specific authentication credentials before signing the transaction; further describes the abstract idea of organizing human activity (i.e., as fundamental economic practices).
Claim 7 recites: wherein the non-custodial wallet application operates across various blockchain networks, enabling the customization of transactions on a wide range of blockchain-based assets; further describes the abstract idea of organizing human activity (i.e., as fundamental economic practices).
Claims 8 recites: wherein the user-held assets comprise cryptocurrency assets, and the non-custodial wallet application is specifically configured for managing transactions involving cryptocurrency holdings; further describes the abstract idea of organizing human activity (i.e., as fundamental economic practices).
Claims 9 recites: wherein the non-custodial wallet application further comprises a secure authentication mechanism for verifying the identity of the user before allowing access to cryptographic keys and transaction functionalities; further describes the abstract idea of organizing human activity (i.e., as fundamental economic practices).
Claims 10 recites: providing a user interface within the non-custodial wallet application to enable the user to define and configure rules; further describes the abstract idea of organizing human activity (i.e., as fundamental economic practices).
Claims 11 recites: wherein the server backend performs additional security checks and fraud prevention measures to detect and prevent unauthorized or fraudulent transactions; further describes the abstract idea of organizing human activity (i.e., as fundamental economic practices).
Claim 12 recites: enabling users to generate, manage, and restore cryptographic key backups securely, ensuring access to assets even in the event of device loss or failure; further describes the abstract idea of organizing human activity (i.e., as fundamental economic practices).
Claim 13 recites: wherein the non-custodial wallet application supports multi-signature transactions, allowing multiple authorized parties to collectively approve and execute transactions involving user-held assets; further describes the abstract idea of organizing human activity (i.e., as fundamental economic practices).
Subject Matter Eligibility Criteria – Step 2A – Prong Two:
Claim 1, 14, and 20 recites to a generic computer as an additional element to the judicial exception in the preamble. Viewed individually and in combination, this additional element to the identified judicial exception of Step 2A.1, amounts to no more than mere instructions for managing and controlling financial transactions with predefined rules on a generic computer. Therefore, at Step 2A.2, these additional elements do not act in combination to integrate the abstract idea into a practical application. The additional elements of claims 1, 14, and 20 considered both individually and as an ordered combination, do not amount to significantly more than the judicial exception because the additional element of a generic computer does no more than “[s]imply appending well-understood, routine, conventional activities previously known to the industry, specified at a high level of generality, to the judicial exception, e.g., a claim to an abstract idea requiring no more than a generic computer to perform generic computer functions that are well-understood, routine and conventional activities previously known to the industry.” See MPEP 2106.05 (citing to Alice Corp. Pty. Ltd. v. CLS Bank Int'l, 573 U.S. 208, 225 (2014)).
Therefore claims 1, 14, and 20 is found ineligible under 35 U.S.C. 101.
Step 2B:
Viewed as a whole, instructions/method claims recite the concept of “organizing human activity” (i.e., as fundamental economic practices) in managing and controlling financial transactions with predefined rules are performed by a generic computer. The method claims do not, for example, purport to improve the functioning of the computer itself. Nor do they effect an improvement in any other technology or technical field. Instead, the claims at issue amount to nothing significantly more than an instruction to apply the abstract idea using some unspecified, generic computer. See Alice Corp. Pty. Ltd., 573 U.S. 208. Mere instructions to apply the exception using a generic computer component and limitations to a particular field of use or technological environment cannot integrate a judicial exception into a practical application at Step 2A or provide an inventive concept in Step 2B. The use of a computer server is to merely automate and/or implement the abstract idea cannot provide significantly more than the abstract idea itself (MPEP 2106.05(I)(A)(f) & (h)). Therefore, the claim is not patent eligible.
Claim Rejections - 35 USC § 103
5. The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The 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 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1-20 are rejected under 35 U.S.C. 103 as being unpatentable over Schaffner et al. (US 20150324787 A1), in view of Schouppe et al. (US 20200162246 A1).
7. Regarding claim 1, 14, and 20, Schaffner discloses method (system for facilitating a non-custodial wallet application at a client device, the system comprising one or more processors configured to perform the operations, A non-transitory computer-readable medium containing instructions for facilitating a non-custodial wallet application at a client device, comprising), (Para. 0010-003)),
presenting, at a client device associated with a user, a user interface for a non-custodial wallet application configured for managing cryptographic keys associated with user-held assets on the client device; (Para. 0012, The system is used to secure cryptocurrency ownership to assure that the keys to the currency are under the control of the rightful owner, A given user or owning entity's electronic coins can be accessed and used via digital “wallets” that contain linkages of specific coins to that owner's private key(s) that represent coin ownership. Here, a “wallet” may be any user space application or software or hardware entity that has such linkages to the owners private keys or otherwise manages the set of owned coins for the owner. It is the private key ownership that is desired by owners to be as secure as possible, since unauthorized access to the private key(s) associated with an electronic coin exposes the coin to potential theft and other unauthorized uses.; and Para. 0014, The present invention therefore places the private keys (101) of electronic coin wallets in such secure areas (102) on computing devices, or on secure removable media. The wallets themselves (103), having a need for user viewing and input, can reside in less secure areas, but having carefully limited access to the private keys held in secure storage for use in authorized wallet viewing and authorized transactions. Such access itself may separately be secured by a requirement to have possession of a separate private key (104) that secures the containing hardware and private key file storage area for the owned coins associated with the wallet. This is represented in FIG. 1.)
establishing, at the client device, a policy threshold condition within the non-custodial wallet to facilitate rule-based control over transactions involving the user-held assets; (Para. 0006, Cryptocurrency systems are advantageous because they facilitate electronic transactions without the need for currency or for a trusted third party, however they lack flexibility. Current cyptocurrency systems concern themselves only with the verification of the currency itself, not with the transaction the currency is to be used for. The present invention addresses this shortcoming by inserting a policy-based system at the endpoints of each transaction with the ability to embed policy concerning the transaction into the coin itself that is transmitted from endpoint to endpoint. The system can be used for simple, point to point transactions with one buyer and one seller, or it can be used for more complex transactions where multiple approvals might be needed. Furthermore, the policy system is extensible such that any parameter can be used as part of the approval process to include, time of transaction, place of transaction, context of the sale, or approved vendor.; and Para. 0016, First, the cryptocurrency system and protocol can be extended to embed policy within it (see FIG. 3). A given wallet application of a user (301) or a supplementary application could be used to specify one or more payment policies (302), and then the policy could be signed and embedded in a given payment transaction of an electronic coin (303), with said policy or policies being held by the cryptocurreney network or system. The policies can be embedded by compiling them into the electronic coin, appended to the electronic coin, or encrypted with the electronic coin. Then, a given payment could only be sent if the policy or set of policies was successfully implemented. The policy set becomes an enforcement requirement for payment (304). In this manner, the embedded policy also adds complexity and desirable processor node work items to the cryptocurrency system.)
enabling, at the client device, a user of the non-custodial wallet to define and configure rules governing the spending of the user-held assets, the rules including predefined conditions for transaction approval; (Para. 0017, policies could specify that a given coin could only be used for the purchase of office supplies or other specific items, or that only specific vendors may be purchased from, or that only approved nontoxic materials may be purchased with the coin. Policies may also be enforced wallet-wide by reproduction of policy elements across all coins in the wallet at purchase time.)
initiating, at the client device, a transaction request involving the user-held assets, subject to the predefined conditions; (Para. 0009, FIG. 3 shows a sender(initiator of a transaction) using the policy control system to embed policy in the coin transmission to the receiver. There, the policy is implemented and the transaction is adjudicated resulting in execution or rejection of the transaction.; and Para. 0015, a system for policy-based. access control and management for mobile computing devices, The basic system presented in that application is depicted in FIG. 2, The system described therein provides extensive granularity of control over permitted operations, plus network, file system, and device access on devices controlled by the system. Furthermore, the system utilizes one or more policy decision point (PDP) servers which respond to encrypted queries from computing devices controlled by a given instance of the system. These PDP servers may be remote from the computing device, or may even be hosted within the computing device. The queries typically encapsulate requests for use of specific device or network-accessible assets, and the PDP response to such a request is then received by the querying device, with subsequent decisions made by the PDP then enforced at the Policy Enforcement Points (PEPs) on the device. Such a secure policy-based system can be used to augment and enhance a cryptocurrency system in the following ways.)
Schaffner does not explicitly disclose verifying the rules independently at both the client device and a server backend for the non-custodial wallet application during a transaction initiation process, wherein the server backend hosts verification code for the rules; transmitting the transaction request to the server backend for rule verification, the server backend performing an authorization process based on the rules without signing the transaction.
However, Schouppe teaches verifying the rules independently at both the client device and a server backend for the non-custodial wallet application during a transaction initiation process, wherein the server backend hosts verification code for the rules; transmitting the transaction request to the server backend for rule verification, the server backend performing an authorization process based on the rules without signing the transaction, (Para. 0005, the present disclosure is directed to a method of providing a key management service with a key management device for transferring control of an asset private key. The method includes receiving, at the key management device, an asset private key splitting request from an initiating user computing device; and sending, from the key management device to the initiating user computing device, key splitting instructions for execution in a web browser of the initiating user computing device, wherein the key splitting instructions includes splitting the asset private key into a plurality of subkeys with a key splitting algorithm; identifying a first portion of the subkeys for distribution to a plurality of users; identifying a second portion of the subkeys, the second portion including at least one validator subkey; storing ones of the first portion of the subkeys on a plurality of cold storage devices for transfer to the plurality of users; randomly generating a validator asymmetric public-private key pair and passphrase; encrypting the at least one validator subkey with the validator private key; and transmitting the at least one encrypted validator subkey to the key management device for storage on a blockchain platform.; and Para. 0014, Key management device 106 may be configured to provide a key management service and to communicate with user computing devices 102 to cause the user devices to perform one or more functions of key management as described herein. Key management device 106 may include a database 120 for storage of certain information associated with users 103 in connection with providing key management services. In some examples, key management device 106 is configured to provide a decentralized key management service, where neither the asset private key 110 or subkeys 116 are accessed or stored by the key management device or associated database 120. Instead, the key management device 106 may only store minimal group mapping information to facilitate the key management service while providing instructions to one or more of user devices 102 to perform functions of key splitting, encryption, and storage. As described more below, key management device 106 may be configured to identify, or cause a user device 102 executing key distribution protocol 114 to identify, a first portion 122 of subkeys 116 as user subkeys and a second portion 124 of subkeys 116 as validator subkeys 125 and in some examples, backup subkeys 126, wherein a number of subkeys 116 in the first portion 122 of subkeys is less than the threshold, T, so that the users cannot restore the asset private key without access to the second portion 124 of subkeys 116. The first portion 122 of subkeys 116 can be distributed to one or more of users 103 for storage on user computing devices 102 and/or cold storage devices 118. For example, in a case where user 103_1 is an initiating user that initially owns and/or controls asset private key 110, the first portion 122 of subkeys 116 may be transferred to one or more of the other users 103 so that if the initiating user 103_1 loses the asset private key 110 or if the initiating user 103_1 dies or becomes incapacitated, the other users 103 can use system 100 to restore the asset private key 110 to gain access to the asset 111.)
One of ordinary skill in the art would have recognized that applying the known technique of Schouppe to the known invention of Schaffner would have been recognized that the application of the technique would have yielded predictable results because the level of ordinary skill in the art demonstrated by the references applied shows the ability to incorporate authorization process features into a similar invention. Further, it would have been recognized by those of ordinary skill in the art that modifying the method to include verifying the rules independently at both the client device and a server backend for the non-custodial wallet application during a transaction initiation process, wherein the server backend hosts verification code for the rules; transmitting the transaction request to the server backend for rule verification, the server backend performing an authorization process based on the rules without signing the transaction result in an improved invention because applying said technique will ensure that the wallets are verified by the server backend before transmitting the cryptographic keys, thus improving the overall security of the invention.
Schaffner does not explicitly disclose in response to successful rule verification at the server backend, transmitting a secure portion of a cryptographic key from the server backend to the client device, the secure portion enabling cryptographic transaction signing.
However, Schouppe teaches in response to successful rule verification at the server backend, transmitting a secure portion of a cryptographic key from the server backend to the client device, the secure portion enabling cryptographic transaction signing, (Para. 0040, In one example, storage and control of the encrypted validator subkeys 128 and validator key pair and passphrase 127 may vary according to the key management protection plan selected by the initiating user. For example, if the initiating user opts to use a trusted third party, such as a law firm, or one of the users 103, such as the oldest or most responsible child, to be the validator, then the validator key pair and passphrase 127 may be stored on the validator cold storage device 208 and/or validator computing device 212. At 238, the initiating user may connect the validator cold storage device 208 to the initiating user computing device 202 and after connection, the validator cold storage device and initiating user computing device may initiate a secure communication session using any protocol known in the art, such as authenticating the browser, and providing cold storage device credentials or other authentication information for identifying and authenticating the validator cold storage device to the browser. The cold storage device credentials may include or be based on a cold storage device public key of an asymmetric public-private key pair 119. At 240, in cases where there is more than one validator, the initiating user may be prompted to select one of the validators previously defined at step 220 and 222 as the owner of the validator cold storage device 208. At 242, the initiating user device may transfer the asymmetric public/private validator key pair and passphrase 127 and the hash of the validator subkeys 125 to the validator cold storage device 208 for secure long term storage for future use to decrypt the encrypted validator subkeys 128 stored on blockchain platform 210 as described below. In other examples, only the validator key pair 127 may be transferred to the validator cold storage device 208 and the passphrase for decrypting and using the private key of the key pair 127 may be transferred to key management device 204 so that control of the encrypted validator subkeys 128 is split between the validator and the key management device.
One of ordinary skill in the art would have recognized that applying the known technique of Schouppe to the known invention of Schaffner would have been recognized that the application of the technique would have yielded predictable results because the level of ordinary skill in the art demonstrated by the references applied shows the ability to incorporate cryptographic keys features into a similar invention. Further, it would have been recognized by those of ordinary skill in the art that modifying the method to include in response to successful rule verification at the server backend, transmitting a secure portion of a cryptographic key from the server backend to the client device, the secure portion enabling cryptographic transaction signing result in an improved invention because applying said technique will prevent unauthorized users from gaining access, thus improving the overall performance of the invention.
Regarding claims 2 and 15, Schaffner discloses wherein the predefined conditions include a policy threshold condition that establishes the required level of authorization for executing transactions involving the user-held assets. (Para. 0006, Cryptocurrency systems are advantageous because they facilitate electronic transactions without the need for currency or for a trusted third party, however they lack flexibility. Current cyptocurrency systems concern themselves only with the verification of the currency itself, not with the transaction the currency is to be used for. The present invention addresses this shortcoming by inserting a policy-based system at the endpoints of each transaction with the ability to embed policy concerning the transaction into the coin itself that is transmitted from endpoint to endpoint. The system can be used for simple, point to point transactions with one buyer and one seller, or it can be used for more complex transactions where multiple approvals might be needed. Furthermore, the policy system is extensible such that any parameter can be used as part of the approval process to include, time of transaction, place of transaction, context of the sale, or approved vendor.; and Para. 0016, First, the cryptocurrency system and protocol can be extended to embed policy within it (see FIG. 3). A given wallet application of a user (301) or a supplementary application could be used to specify one or more payment policies (302), and then the policy could be signed and embedded in a given payment transaction of an electronic coin (303), with said policy or policies being held by the cryptocurreney network or system. The policies can be embedded by compiling them into the electronic coin, appended to the electronic coin, or encrypted with the electronic coin. Then, a given payment could only be sent if the policy or set of policies was successfully implemented. The policy set becomes an enforcement requirement for payment (304). In this manner, the embedded policy also adds complexity and desirable processor node work items to the cryptocurrency system. )
9. Regarding claims 3 and 16, Schaffner discloses further comprising: recording transaction details and behavioral data associated with the user-held assets, wherein the recorded behavioral data contributes to the generation of user-specific non-fungible tokens (NFTs) representing user activity within the non-custodial wallet application, (Para. 0017- 0018, As non-limiting examples, policies could specify that a given coin could only be used for the purchase of office supplies or other specific items, or that only specific vendors may be purchased from, or that only approved nontoxic materials may be purchased with the coin. Policies may also be enforced wallet-wide by reproduction of policy elements across all coins in the wallet at purchase time. Second, a network with policy built or compiled into it could have event-driven protections native to the network itself. These inherent protections might make it possible to effectively manage a widely disparate, peer-to-peer network. For a cryptocurrency network, such embedded policy can provide additional security controls, for example, in the form of policies that limit or halt transactions, or notify appropriate administrative parties, if transaction frequencies from a specific party exceed some specified threshold at which suspicion of undesired activity is warranted.)
10. Regarding claims 4 and 17, Schaffner discloses further comprising: synchronizing the rules between the client device and the server backend, and enabling rule changes to be exclusively applied through the client device. (Para. 0014-0015,The present invention therefore places the private keys (101) of electronic coin wallets in such secure areas (102) on computing devices, or on secure removable media. The wallets themselves (103), having a need for user viewing and input, can reside in less secure areas, but having carefully limited access to the private keys held in secure storage for use in authorized wallet viewing and authorized transactions. Such access itself may separately be secured by a requirement to have possession of a separate private key (104) that secures the containing hardware and private key file storage area for the owned coins associated with the wallet. This is represented in FIG. 1…a system for policy-based. access control and management for mobile computing devices, The basic system presented in that application is depicted in FIG. 2, The system described therein provides extensive granularity of control over permitted operations, plus network, file system, and device access on devices controlled by the system. Furthermore, the system utilizes one or more policy decision point (PDP) servers which respond to encrypted queries from computing devices controlled by a given instance of the system. These PDP servers may be remote from the computing device, or may even be hosted within the computing device. The queries typically encapsulate requests for use of specific device or network-accessible assets, and the PDP response to such a request is then received by the querying device, with subsequent decisions made by the PDP then enforced at the Policy Enforcement Points (PEPs) on the device. Such a secure policy-based system can be used to augment and enhance a cryptocurrency system in the following ways.)
11. Regarding claims 5 and 18, Schaffner discloses further comprising: enforcing the policy threshold condition to ensure secure and customizable transactions involving the user-held assets within the non-custodial wallet application. (Para. 0016-0017, First, the cryptocurrency system and protocol can be extended to embed policy within it (see FIG. 3). A given wallet application of a user (301) or a supplementary application could be used to specify one or more payment policies (302), and then the policy could be signed and embedded in a given payment transaction of an electronic coin (303), with said policy or policies being held by the cryptocurreney network or system. The policies can be embedded by compiling them into the electronic coin, appended to the electronic coin, or encrypted with the electronic coin. Then, a given payment could only be sent if the policy or set of policies was successfully implemented. The policy set becomes an enforcement requirement for payment (304). In this manner, the embedded policy also adds complexity and desirable processor node work items to the cryptocurrency system. As non-limiting examples, policies could specify that a given coin could only be used for the purchase of office supplies or other specific items, or that only specific vendors may be purchased from, or that only approved nontoxic materials may be purchased with the coin. Policies may also be enforced wallet-wide by reproduction of policy elements across all coins in the wallet at purchase time.)
12. Regarding claims 6 and 19, Schaffner does not explicitly disclose wherein the cryptographic key is securely decrypted on the client device using user-specific authentication credentials before signing the transaction.
However, Schouppe teaches wherein the cryptographic key is securely decrypted on the client device using user-specific authentication credentials before signing the transaction (Claim 29. The method of claim 28, the method further comprising receiving at the validator computing device from the key management device a passphrase for decrypting the validator private key.; and Claim 27. The method of claim 25, wherein the key management device decrypts the encrypted validator subkey with a passphrase and private key stored in key management device memory.; and Claim 28. The method of claim 25, wherein the validator subkey received from the key management device is encrypted, the method further comprising, at the validator computing device: connecting to a cold storage device and accessing a validator private key stored on the cold storage device; and decrypting the encrypted validator subkey with the validator private key.)
One of ordinary skill in the art would have recognized that applying the known technique of Schouppe to the known invention of Schaffner would have been recognized that the application of the technique would have yielded predictable results because the level of ordinary skill in the art demonstrated by the references applied shows the ability to incorporate user-specific authentication credentials features into a similar invention. Further, it would have been recognized by those of ordinary skill in the art that modifying the method to include wherein the cryptographic key is securely decrypted on the client device using user-specific authentication credentials before signing the transaction result in an improved invention because applying said technique will ensure that cryptographic keys are securely decrypted on the user’s device, thus improving the overall security of the invention.
13. Regarding claim 7, Schaffner discloses wherein the non-custodial wallet application operates across various blockchain networks, enabling the customization of transactions on a wide range of blockchain-based assets.
However, Schouppe teaches wherein the non-custodial wallet application operates across various blockchain networks, enabling the customization of transactions on a wide range of blockchain-based assets,(Para. 0012-0013 Aspects of the present disclosure include key management systems configured to provide web-based (also referred to as cloud-based) key management services for the secure and decentralized control and storage of private cryptographic keys and/or other information. As described more below, asset private keys, seeds, passphrases, or any other digital data string or data set may be split into a plurality of subkeys and distributed to a group of people that may gain control of the asset private key in the event a specified condition has occurred. In some examples, the group of people receive less than a threshold number of the subkeys required to restore the asset private key and one or more of the subkeys required to restore the asset private key are defined as validator subkeys and separately and securely stored. In some examples, the validator subkeys are encrypted and the encrypted validator subkeys stored on a blockchain platform. An initiating user can select from a plurality of key management programs to determine how the asset private key will be split and how the validator subkey will be stored and accessed. FIG. 1 shows an architecture diagram of an example key management system 100 made in accordance with the present disclosure. System 100 includes a plurality of user computing devices 102_1, 102_2, 102_n of users 103_1-103n, the user computing devices 102 communicatively coupled via a network 104 to a key management device 106 that provides a key management service to users 103 for the secure storage and transfer of assets. System 100 is designed and configured to securely store an asset private key 110, which is a cryptographic key, seed, passphrase, or other digital data string that is used to gain access to an asset 111, to ensure the asset private key is never permanently lost and that it is only accessed under authorized conditions. System 100 may also be used to securely store any type of information, such as any secret that is used to secure an asset, for example, a private key of a cryptographic asymmetric public-private key pair, a password, passphrase, or any other digital data string, including any word or combination of words, or other digital data file, such as a digital image, etc.)
One of ordinary skill in the art would have recognized that applying the known technique of Schouppe to the known invention of Schaffner would have been recognized that the application of the technique would have yielded predictable results because the level of ordinary skill in the art demonstrated by the references applied shows the ability to incorporate blockchain-based assets features into a similar invention. Further, it would have been recognized by those of ordinary skill in the art that modifying the method to include wherein the non-custodial wallet application operates across various blockchain networks, enabling the customization of transactions on a wide range of blockchain-based assets result in an improved invention because applying said technique will allow users to manage and operate transactions from their wallet, thus improving the overall performance of the invention.
14. Regarding claim 8, Schaffner discloses wherein the user-held assets comprise cryptocurrency assets, and the non-custodial wallet application is specifically configured for managing transactions involving cryptocurrency holdings. (Para. 0012, The system is used to secure cryptocurrency ownership to assure that the keys to the currency are under the control of the rightful owner, A given user or owning entity's electronic coins can be accessed and used via digital “wallets” that contain linkages of specific coins to that owner's private key(s) that represent coin ownership. Here, a “wallet” may be any user space application or software or hardware entity that has such linkages to the owners private keys or otherwise manages the set of owned coins for the owner. It is the private key ownership that is desired by owners to be as secure as possible, since unauthorized access to the private key(s) associated with an electronic coin exposes the coin to potential theft and other unauthorized uses.; and Para. 0006, Cryptocurrency systems are advantageous because they facilitate electronic transactions without the need for currency or for a trusted third party, however they lack flexibility. Current cyptocurrency systems concern themselves only with the verification of the currency itself, not with the transaction the currency is to be used for. The present invention addresses this shortcoming by inserting a policy-based system at the endpoints of each transaction with the ability to embed policy concerning the transaction into the coin itself that is transmitted from endpoint to endpoint. The system can be used for simple, point to point transactions with one buyer and one seller, or it can be used for more complex transactions where multiple approvals might be needed. Furthermore, the policy system is extensible such that any parameter can be used as part of the approval process to include, time of transaction, place of transaction, context of the sale, or approved vendor.)
15. Regarding claim 9, Schaffner discloses wherein the non-custodial wallet application further comprises a secure authentication mechanism for verifying the identity of the user before allowing access to cryptographic keys and transaction functionalities, (Para. 0009-0010, FIG. 3 shows a sender(initiator of a transaction) using the policy control system to embed policy in the coin transmission to the receiver. There, the policy is implemented and the transaction is adjudicated resulting in execution or rejection of the transaction. FIG. 4 shows the policy-controlled cloud-based wallet for cryptocurrency. The originator initiates a transaction that must be verified by a secondary key according to the policy. The receiver implements the policy to verify that both keys are present before approving the transaction.; and Para. 0014] The present invention therefore places the private keys (101) of electronic coin wallets in such secure areas (102) on computing devices, or on secure removable media. The wallets themselves (103), having a need for user viewing and input, can reside in less secure areas, but having carefully limited access to the private keys held in secure storage for use in authorized wallet viewing and authorized transactions. Such access itself may separately be secured by a requirement to have possession of a separate private key (104) that secures the containing hardware and private key file storage area for the owned coins associated with the wallet. This is represented in FIG. 1.)
16. Regarding claim 10, Schaffner discloses further comprising: providing a user interface within the non-custodial wallet application to enable the user to define and configure rules, (Para. 0016-0017, First, the cryptocurrency system and protocol can be extended to embed policy within it (see FIG. 3). A given wallet application of a user (301) or a supplementary application could be used to specify one or more payment policies (302), and then the policy could be signed and embedded in a given payment transaction of an electronic coin (303), with said policy or policies being held by the cryptocurreney network or system. The policies can be embedded by compiling them into the electronic coin, appended to the electronic coin, or encrypted with the electronic coin. Then, a given payment could only be sent if the policy or set of policies was successfully implemented. The policy set becomes an enforcement requirement for payment (304). In this manner, the embedded policy also adds complexity and desirable processor node work items to the cryptocurrency system. As non-limiting examples, policies could specify that a given coin could only be used for the purchase of office supplies or other specific items, or that only specific vendors may be purchased from, or that only approved nontoxic materials may be purchased with the coin. Policies may also be enforced wallet-wide by reproduction of policy elements across all coins in the wallet at purchase time.)
17. Regarding claim 11, Schaffner discloses wherein the server backend performs additional security checks and fraud prevention measures to detect and prevent unauthorized or fraudulent transactions, (Para. 0018, Second, a network with policy built or compiled into it could have event-driven protections native to the network itself. These inherent protections might make it possible to effectively manage a widely disparate, peer-to-peer network. For a cryptocurrency network, such embedded policy can provide additional security controls, for example, in the form of policies that limit or halt transactions, or notify appropriate administrative parties, if transaction frequencies from a specific party exceed some specified threshold at which suspicion of undesired activity is warranted.; and Para. 0012-0013, The system is used to secure cryptocurrency ownership to assure that the keys to the currency are under the control of the rightful owner, A given user or owning entity's electronic coins can be accessed and used via digital “wallets” that contain linkages of specific coins to that owner's private key(s) that represent coin ownership. Here, a “wallet” may be any user space application or software or hardware entity that has such linkages to the owners private keys or otherwise manages the set of owned coins for the owner. It is the private key ownership that is desired by owners to be as secure as possible, since unauthorized access to the private key(s) associated with an electronic coin exposes the coin to potential theft and other unauthorized uses. One approach to defending security-related systems and components from malicious attack is to have all or part of them reside within especially secure areas, partitions, or environments on device hardware that are inaccessible to unauthorized parties and/or for unauthorized purposes, and are separated from the main device operating system, file system, and, in some cases, from certain of its resources. A further degree of security can be provided if such secure partitions or areas are also invisible and undetectable to the greatest degrees possible, under unauthorized circumstances and by unauthorized parties.)
18. Regarding claim 12, Schaffner does not explicitly disclose further comprising: enabling users to generate, manage, and restore cryptographic key backups securely, ensuring access to assets even in the event of device loss or failure.
However, Schouppe teaches further comprising: enabling users to generate, manage, and restore cryptographic key backups securely, ensuring access to assets even in the event of device loss or failure, (Para. 0007, a method of providing a key management service with a key management device for restoring an asset private key from a plurality of subkeys. The method includes receiving, at the key management device, a restoration request from a validator computing device to restore the asset private key from the plurality of subkeys, the restoration request including a user ID; receiving, from the validator computing device, subkey information for confirming the validator computing device has access to a first number of the subkeys; accessing, with the key management device, group mapping information associated with the user ID; determining whether the group mapping information matches the received subkey information; accessing at least one validator subkey and sending the at least one validator subkey to the validator computing device in response to determining the group mapping information matches the received subkey information; and sending instructions to the validator computing device for restoring the asset private key; wherein the at least one validator subkey is required to restore the asset private key, wherein the accessing the at least one validator subkey includes using the group mapping information for locating and accessing an encrypted version of the at least one validator subkey from a blockchain platform.; and Para. 0012, Aspects of the present disclosure include key management systems configured to provide web-based (also referred to as cloud-based) key management services for the secure and decentralized control and storage of private cryptographic keys and/or other information. As described more below, asset private keys, seeds, passphrases, or any other digital data string or data set may be split into a plurality of subkeys and distributed to a group of people that may gain control of the asset private key in the event a specified condition has occurred. In some examples, the group of people receive less than a threshold number of the subkeys required to restore the asset private key and one or more of the subkeys required to restore the asset private key are defined as validator subkeys and separately and securely stored. In some examples, the validator subkeys are encrypted and the encrypted validator subkeys stored on a blockchain platform. An initiating user can select from a plurality of key management programs to determine how the asset private key will be split and how the validator subkey will be stored and accessed.)
One of ordinary skill in the art would have recognized that applying the known technique of Schouppe to the known invention of Schaffner would have been recognized that the application of the technique would have yielded predictable results because the level of ordinary skill in the art demonstrated by the references applied shows the ability to incorporate cryptographic keys features into a similar invention. Further, it would have been recognized by those of ordinary skill in the art that modifying the method to include enabling users to generate, manage, and restore cryptographic key backups securely, ensuring access to assets even in the event of device loss or failure result in an improved invention because applying said technique will ensure that users can have access to their assets if the device fails, thus improving the overall user convenience of the invention.
19. Regarding claim 13, Schaffner discloses wherein the non-custodial wallet application supports multi-signature transactions, allowing mult