DETAILED ACTION
Acknowledgements
This office action is in response to the claims filed 04/03/2026.
Claims 1-3, 6, 8, 10, 12-16, 18, 19 and 23-26 are amended.
Claims 7, 9, 11, 17, 21 and 22 are canceled.
Claims 1-6, 8, 10, 12-16, 18-20 and 23-26 are pending.
Claims 1-6, 8, 10, 12-16, 18-20 and 23-26 have been examined.
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Arguments
Applicant's arguments filed 04/03/2026 have been fully considered but they are not persuasive.
101
Based on the newly entered claim amendments, the 101 rejection is withdrawn.
103
Regarding claim 1, Applicant’s arguments rely on language recited in preamble recitations in claim(s).The system claim consists solely of wherein clauses with descriptions about the “networked custody server” and a “custody server”. It is unclear what structural elements are part of the system or whether it is solely the “networked custody server” and if that is different from the multiple references to the “custody server”. The body of the claim describes a complete invention and the language recited solely in the preamble does not provide any distinct definition of any of the claimed invention’s limitations. Thus, the preamble of the claim(s) is not considered a limitation and is of no significance to claim construction. See Pitney Bowes, Inc. v. Hewlett-Packard Co., 182 F.3d 1298, 1305, 51 USPQ2d 1161, 1165 (Fed. Cir. 1999). See MPEP § 2111.02.
Sprague teaches wherein the custody server is further configured to use the processor to: access, from within the one or more encrypted enclaves of the trusted execution environment, the encrypted policy data defining the access policy for the transaction-signing cryptographic key pair associated with the user; decrypt, using the processor, within the trusted execution environment, the encrypted policy data defining the access policy for the transaction-signing cryptographic key pair associated with the user (¶ 14, 38, 39, 43, 58-68, 79, 106-110, 123; claim 26);
Sprague - By storing the public keys of the service provider 204 at the TEE, the TEE applet 208 of the user device 205 can validate the origin of an instruction received from the service provider 204, and if needed, decrypt the contents of a received instruction from the service provider 210. (¶ 60)
determine, using a policy engine executing within the trusted execution environment, whether the user-authentication data satisfies the access policy for the transaction-signing cryptographic key pair associated with the user; and (¶ 38, 67, 70, 72, 91);
Sprague - The authentication website 206 may also generate an access control list (also referred to as a trusted execution list) through an access control application, where controls related to the execution of a received instruction within the pairing can be configured and verified. The digital cryptographic keys that have been previously registered with the TEE applet 208 may be stored in an access control list. Specific controls may be associated with a particular registered cryptographic key. For example, the access control list may indicate the authorized period of time for executing an instruction, whether the instruction is within a limit on the number of executions, and whether the instruction is associated with an external condition (factor) that must be verified prior to execution of the instruction. … The authentication website 206 is able to conduct the pairing because it can confirm the integrity and identity of both the user device 205 and the service provider 204 using their device registration records…. the unique device identifier and block chain account key are stored in another secure memory location accessible to the registration agent. (¶ 59, 60, 62)
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims 1-6, 8, 10, 12-16, 18-20 and 23-26 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention.
Claims 1, 25 and 26 recite “a memory configured to store encrypted software code and encrypted data within one or more encrypted enclaves of the trusted execution environment; wherein the trusted execution environment is configured to securely decrypt and execute software instructions that are stored in an encrypted enclave of the one or more encrypted enclaves of the trusted execution environment,…”, “encrypted cryptographic private keys” and “encrypted policy data”. Similarly, claims 2, and 3 recite “encrypted cryptographic private keys”. According to the disclosure(¶ 15-29, 35, 65, 76, 100, 155), “The user-authentication data may comprise a user identifier (e.g. a unique user ID). It may comprise a signed or encrypted user identifier, …Enrolling the new user may comprise the custody server generating a transaction-signing key pair for the new user and storing the key pair in an encrypted enclave…The custody server 4 provides a Trusted Execution Environment (TEE) for storing data and software code securely in one or more encrypted enclaves in a memory of the custody server 4, and for executing the software securely. …encrypted TEE enclave”. The disclosure recites encrypted enclaves with stored data and an encrypted user identifier, but the data in the encrypted enclave is never encrypted or decrypted. The entirety of the disclosure makes no mention of “a memory configured to store encrypted software code and encrypted data within one or more encrypted enclaves”, “wherein the trusted execution environment is configured to securely decrypt and execute software instructions that are stored in an encrypted enclave”, “encrypted cryptographic private keys” or “encrypted policy data”. There is no written description for any of the recited limitations. Dependent claims 2-6, 8, 10, 12-16, 18-20, 23 and 24 are also rejected.
Claims 1, 25 and 26 recite “wherein the custody server is further configured to use the processor to: access, from within the one or more encrypted enclaves of the trusted execution environment, the encrypted policy data defining the access policy for the transaction-signing cryptographic key pair associated with the user; decrypt, using the processor, within the trusted execution environment, the encrypted policy data defining the access policy for the transaction-signing cryptographic key pair associated with the user. According to the disclosure(¶ 41-49, 77, 178-181), “The custody server may be configured to determine whether further user-authentication data satisfies a recovery policy for the user. It may be configured to store new device-authentication data for a new device associated with the user in response to determining that the further authentication data satisfies the recovery policy for the user… wherein the networked custody server comprises a processor configured to provide a trusted execution environment for securely decrypting and executing software instructions that are stored in an encrypted enclave of the custody server”. The disclosure makes no mention of accessing encrypted policy data and decrypting encrypted policy data. There is no written description of the recited limitations “wherein the custody server is further configured to use the processor to: access, from within the one or more encrypted enclaves of the trusted execution environment, the encrypted policy data defining the access policy for the transaction-signing cryptographic key pair associated with the user; decrypt, using the processor, within the trusted execution environment, the encrypted policy data defining the access policy for the transaction-signing cryptographic key pair associated with the user”. Dependent claims 2-6, 8, 10, 12-16, 18-20, 23 and 24 are also rejected.
Claims 1, 25 and 26 recite ” when the user-authentication data satisfies the access policy; - access the encrypted cryptographic private key of the transaction-signing cryptographic key pair associated with the user; -decrypt, within the trusted execution environment, the encrypted cryptographic private key of the transaction-signing cryptographic key pair associated with the user”. According to the disclosure(¶ 41-49, 84, 178-181), “Assuming the user-authentication data, and any other required conditions for the requested transaction, satisfy the access policy, the CS 4 builds and signs the transaction with the wallet private key, using the transaction signing module 42 executing within the TEE enclave associated with the user 20 (step 5). It sends the signed transaction back to the DAB 3 as byte array (step 6).” The disclosure makes no mention of accessing an encrypted key or decrypting the encrypted key within the trusted execution environment when the user- authentication data satisfies the access policy. There is no written description for the limitations “when the user-authentication data satisfies the access policy; - access the encrypted cryptographic private key of the transaction-signing cryptographic key pair associated with the user; -decrypt, within the trusted execution environment, the encrypted cryptographic private key of the transaction-signing cryptographic key pair associated with the user”. Dependent claims 2-6, 8, 10, 12-16, 18-20, 23 and 24 are also rejected.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-6, 8, 10, 12-16, 18-20 and 23-26 are rejected under 35 U.S.C. 103 as being unpatentable over Guan et al. (US 20200153626) (“Guan”), and further in view of Sprague et al. (US20180254898) (“Sprague”).
Regarding claims 1, 25 and 26, Guan discloses A computer system comprising a networked custody server for signing transactions on behalf of a plurality of users, wherein the networked custody server comprises: a processor configured to provide a trusted execution environment; and a memory configured to store encrypted software code and encrypted data within one or more encrypted enclaves of the trusted execution environment, wherein the trusted execution environment is configured to securely decrypt and execute software instructions that are stored in an encrypted enclave of the one or more encrypted enclaves of the trusted execution environment, and wherein the custody server is configured to: (¶ 18, 60-63, 80-90; claim 10)
Guan - The system 610 may comprise one or more processors and one or more non-transitory computer-readable storage media (e.g., one or more memories) coupled to the one or more processors and configured with instructions executable by the one or more processors to cause the system or device (e.g., the processor) to perform the methods and operations described above, e.g., the method 510. The system 610 may comprise various units/modules corresponding to the instructions (e.g., software instructions)…decrypting the retrieved one or more private keys in the encrypted form and correspondingly signing the one or more updated blockchain transactions with the one or more private keys in the decrypted form comprises: in a Trusted Execution Environment (TEE), decrypting the retrieved one or more private keys in the encrypted form and correspondingly signing the one or more updated blockchain transactions with the one or more private keys in the decrypted form… The TEE may be a part of the server 405 or disposed outside of the server 405. In general terms, the TEE offers an execution space that provides a higher level of security. In one embodiment, a TEE is a secure area of a main processor. It may guarantee code and data loaded inside to be protected with respect to confidentiality and integrity…Such instructions may be read into main memory 706 from another storage medium, such as storage device 710. Execution of the sequences of instructions contained in main memory 706 causes processor(s) 704 to perform the process steps described herein. (¶ 18, 62, 84, 89)
store a plurality of encrypted cryptographic private keys of a respective plurality of transaction-signing cryptographic key pairs, associated with a plurality of respective users, in the one or more encrypted enclaves of the trusted execution environment of the custody server (¶ 17, 26, 40, 41, 55-70, 76-78, 82, 88-90);
Guan -the server end 118 may obtain one or more blockchain addresses associated with the one or more local accounts and one or more private keys correspondingly associated with the one or more blockchain addresses (step 412 and step 413);… in the database 406 of the server end 118, the server end 118 may store mapping relationships among the local accounts, the blockchain addresses created in association with the local accounts, corresponding KMS directories, and blockchain identifications for the blockchain addresses. … the server 405 may obtain, from a client (e.g., the user-side system server 403 of the client 111), one or more local accounts (e.g., in the form of local account IDs, email addresses, phone numbers, etc.), one or more unsigned blockchain transactions to be executed for correspondingly updating the plurality of pieces of data associated with the one or more local accounts, information of the plurality of pieces of data, and one or more identifications of the one or more blockchains corresponding to the one or more blockchain transactions (step 411). The information of the plurality of pieces of data comprises: new data to add to the one or more blockchains or changes (e.g., deletion, modification, or similar operations) to existing data in the one or more blockchains….to retrieve the one or more private keys in the encrypted form, the server end 118 may retrieve the one or more private keys in the encrypted form from a Key Management System (KMS) (e.g., KMS 409 of the server end 118) according to one or more KMS directories in one or more mapping relationships (step 412). The KMS may be a part of the server 405 …Moreover, batch processing is enabled for multiple blockchain data updates in multiple blockchains for multiple users. (¶ 26, 56, 58, 60, 61)
store encrypted policy data defining a respective access policy for each transaction- signing cryptographic key pair in the one or more encrypted enclaves of the trusted execution environment (¶ 41, 45, 48, 49, 66, 70, 82);
Guan - the server end 118 may construct one or more blockchain contracts based on information obtained from Node C for execution in a blockchain transaction (e.g., the master blockchain transaction). The blockchain nodes may execute blockchain transaction to deploy the blockchain contract or invoke a deployed blockchain contract. The blockchain contract may or may not involve a financial exchange. The blockchain contracts may include contractual terms between users written in lines of code. (¶ 41)
receive a request to digitally sign a transaction on behalf of a user of the plurality of users; and (¶ 19, 23, 46, 47, 50, 64, 68, 72-76);
Guan -the client 111 may transmit information (e.g., a request with relevant information for updating blockchain data, an unsigned blockchain transaction for updating blockchain data) to the server end 118 for the server end 118 to update blockchain data. Updating blockchain data may include adding new data to a blockchain or deleting or modifying existing blockchain data. To this end, the server end 118 may sign the blockchain transaction for the client 111, compile the request with other blockchain data update requests, and/or perform other operations. (¶ 46)
receive user-authentication data for the user (¶ 37, 58, 62, 63);
Guan -The server end 118 may provide Blockchain-as-a-Service (BaaS) and be referred to as a BaaS end. In one embodiment, BaaS is a cloud service model in which clients or developers outsource behind-the-scenes aspects of a web or mobile application. BaaS may provide pre-written software for activities that take place on blockchains, such as user authentication, database management, and remote updating… the server 405 may obtain, from a client (e.g., the user-side system server 403 of the client 111), one or more local accounts (e.g., in the form of local account IDs, email addresses, phone numbers, etc.), one or more unsigned blockchain transactions to be executed for correspondingly updating the plurality of pieces of data associated with the one or more local accounts, information of the plurality of pieces of data, and one or more identifications of the one or more blockchains corresponding to the one or more blockchain transactions (step 411). (¶ 37, 58)
when the user-authentication data satisfies the access policy (¶ 16-18, 40, 46-48, 55-65, 78, 79, 81, 83);
Claim Interpretation – The limitations following “ when the user-authentication data does/ does not satisfy …. ”, “in response to determining that the user-authentication data does/ does not satisfy” recite optional and conditional language, and therefore do not have patentable weight. See MPEP 2103(I)(c).
- access the encrypted cryptographic private key of the transaction-signing cryptographic key pair associated with the user; -decrypt, within the trusted execution environment, the encrypted cryptographic private key of the transaction-signing cryptographic key pair associated with the user; use a transaction signing module executing within the trusted execution environment to digitally sign the transaction on behalf of the user, using the cryptographic private key of the transaction-signing cryptographic key pair associated with the user and -output data representative of the signed transaction; and (¶ 16-18, 40, 46-48, 55-65, 78, 79, 81, 83);
Guan - the director(ies) will lead to the encrypted private key(s) stored in the KMS, which can be decrypted in a Trusted Execution Environment (TEE). The TEE may be a part of the server 405 …To correspondingly sign the one or more updated blockchain transactions with the one or more private keys, the server end 118 may decrypt the retrieved one or more private keys in the encrypted form and correspondingly sign the one or more updated blockchain transactions with the one or more private keys in a decrypted form (steps 414-416)….transmit the signed one or more blockchain transactions to one or more blockchain nodes of the one or more blockchains for execution (step 417). (¶ 58, 59, 62)
when the user-authentication data does not satisfy the access policy, decline the request to digitally sign the transaction or issue a request to receive further user-authentication data (¶ 44)
Claim Interpretation – The limitations following “ when the user-authentication data does/ does not satisfy …. ”, “in response to determining that the user-authentication data does/ does not satisfy” recite optional and conditional language, and therefore do not have patentable weight. See MPEP 2103(I)(c).
Guan - If the verification fails at some point, the blockchain transaction is rejected. (¶ 44)
Guan does not disclose wherein the custody server is further configured to use the processor to: access, from within the one or more encrypted enclaves of the trusted execution environment, the encrypted policy data defining the access policy for the transaction-signing cryptographic key pair associated with the user; decrypt, using the processor, within the trusted execution environment, the encrypted policy data defining the access policy for the transaction-signing cryptographic key pair associated with the user; determine, using a policy engine executing within the trusted execution environment, whether the user-authentication data satisfies the access policy for the transaction-signing cryptographic key pair associated with the user; and.
Sprague teaches wherein the custody server is further configured to use the processor to: access, from within the one or more encrypted enclaves of the trusted execution environment, the encrypted policy data defining the access policy for the transaction-signing cryptographic key pair associated with the user; decrypt, using the processor, within the trusted execution environment, the encrypted policy data defining the access policy for the transaction-signing cryptographic key pair associated with the user (¶ 14, 38, 39, 43, 58-68, 79, 106-110, 123; claim 26);
Sprague - By storing the public keys of the service provider 204 at the TEE, the TEE applet 208 of the user device 205 can validate the origin of an instruction received from the service provider 204, and if needed, decrypt the contents of a received instruction from the service provider 210. (¶ 60)
determine, using a policy engine executing within the trusted execution environment, whether the user-authentication data satisfies the access policy for the transaction-signing cryptographic key pair associated with the user; and (¶ 38, 67, 70, 72, 91);
Sprague - The authentication website 206 may also generate an access control list (also referred to as a trusted execution list) through an access control application, where controls related to the execution of a received instruction within the pairing can be configured and verified. The digital cryptographic keys that have been previously registered with the TEE applet 208 may be stored in an access control list. Specific controls may be associated with a particular registered cryptographic key. For example, the access control list may indicate the authorized period of time for executing an instruction, whether the instruction is within a limit on the number of executions, and whether the instruction is associated with an external condition (factor) that must be verified prior to execution of the instruction. … The authentication website 206 is able to conduct the pairing because it can confirm the integrity and identity of both the user device 205 and the service provider 204 using their device registration records…. the unique device identifier and block chain account key are stored in another secure memory location accessible to the registration agent. (¶ 59, 60, 62)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Guan(¶ 6, 26) which teaches “ the client has to store and manage the local account's blockchain address and public-private keys, which puts burden on the client for maintaining storage and security” and Sprague (¶ 4) which teaches “it is paramount that the keys (particularly the private keys) be secured for use in transfers of value” in order to enhance security and privacy (Sprague; ¶ 2-4).
Regarding claim 2, Guan discloses wherein the networked custody server is configured to store the plurality of encrypted cryptographic private keys in a common encrypted enclave of the one or more encrypted enclaves of the trusted execution environment (¶ 17, 26, 40, 41, 55-70, 76-78, 82).
Regarding claim 3, Guan discloses wherein the custody server is configured to store each of the plurality of encrypted cryptographic private keys in a different respective encrypted enclave of the one or more encrypted enclaves of the trusted execution environment (¶ 17, 26, 40, 41, 55-70, 76-78, 82).
Regarding claim 4, Sprague teaches wherein the custody server is configured to receive the user-authentication data from a user device, and is further configured to receive device-authentication data for the user device, and wherein the access policy depends on the device-authentication data, and the custody server is configured to determine whether the received device-authentication data satisfies the access policy (¶ 38, 67, 70, 72, 91).
Regarding claim 5, Sprague teaches wherein the custody server is configured to store a public key of a client access key pair for the user, and is configured to receive user-authentication data that is cryptographically generated using a private key of the client access key pair, and to use the public key of the client access key pair when determining whether the received user-authentication data satisfies the respective access policy (¶ 38, 59-67, 70, 72, 91).
Regarding claim 6, Sprague teaches wherein: the custody server is configured to store mapping data associating a public key of a client access key pair of a user device with the cryptographic transaction-signing key pair associated with the user; the user-authentication data is received by the custody server from the user device, and is cryptographically generated by the user device using a private key of the client access key pair; and the custody server is configured to use the mapping data and the public key of the client access key pair when determining whether the user-authentication data satisfies the access policy(¶ 38, 59-67, 70, 72, 78. 79, 91).
Regarding claim 8, Guan discloses wherein each access policy specifies a respective authentication attribute, and wherein the custody server is configured to determine, within the trusted execution environment, whether the received user- authentication data satisfies the authentication attribute specified by the access policy for the transaction-signing cryptographic key pair associated with the user, and to use the cryptographic private key to digitally sign the transaction, on behalf of the user, at least in part in response to determining that the user- authentication data satisfies the authentication attribute (¶ 16-18, 40, 46-48, 55-65, 78, 79, 81, 83).
Regarding claim 10, Sprague teaches wherein the access policy for the transaction-signing cryptographic key pair associated with the user specifies a transaction attribute, and wherein the custody server is configured to determine, within the trusted execution environment, whether the transaction attribute specified by the access policy is met by the transaction, and to use the cryptographic private key to digitally sign the transaction, on behalf of the user, at least in part in response to determining that the transaction satisfies the transaction attribute (¶ 38, 59-67, 70, 72, 91).
Regarding claim 12, Guan discloses wherein the access policy for the transaction-signing cryptographic key pair associated with the user specifies a plurality of transaction attributes and a plurality of authentication attributes, and further associates each transaction attribute of the plurality of transaction attributes with at least one authentication attribute of the plurality of authentication attributes, and wherein the custody server is further configured to determine whether the received user-authentication data satisfies an authentication attribute associated with a transaction attribute of the transaction, and to use the cryptographic private key to digitally sign the transaction, on behalf of the user, at least in part in response to determining that the received user-authentication data satisfies every authentication attribute associated with every transaction attribute of the transaction (¶ 41, 45, 48, 49, 55-66, 70, 82).
Regarding claim 13, Guan discloses wherein the transaction is a cryptocurrency transaction having an associated value, and wherein the access policy for the transaction-signing cryptographic key pair associated with the user specifies a type of user- authentication data that the received user-authentication data must satisfy, selected from a plurality of types in dependence on the value of the transaction (¶ 41, 45-66, 70, 82).
Regarding claim 14, Sprague teaches wherein the custody server is configured to store user-specific policy data associated with respective users of the plurality of users, and is further configured to store system-wide policy data associated with all of the plurality of users, and wherein the custody server is configured to determine whether to digitally sign a transaction, on behalf of a user, at least partly in dependence on whether received user- authentication data satisfies user-specific policy data and also satisfies system-wide policy data (¶ 38, 67, 70, 72, 91).
Regarding claim 15, Sprague teaches wherein the access policy for the transaction-signing cryptographic key pair associated with the user requires a plurality of authenticating users to authenticate a single transaction, and wherein the custody server is configured to receive user-authentication data for each of the plurality of authenticating users and to determine, within the trusted execution environment, whether the user-authentication data of each of the authenticating users satisfies the access policy (¶ 38, 44, 50, 51, 67-70, 72, 91).
Regarding claim 16, Sprague teaches wherein the request to digitally sign a transaction on behalf of the user comprises a user identifier for the user, and wherein the custody server is configured to store data mapping user identifiers, for the plurality of users, to real-world or digital identity data associated with the respective users (¶ 38, 57-58, , 63, 64, 70-72).
Regarding claim 18, Guan discloses wherein the custody server is configured to store policy data defining a plurality of access policies for the transaction-signing cryptographic key pair associated with the user, and is further configured to deactivate a policy for the transaction-signing cryptographic key pair in response to receiving a deactivation command (¶ 44, 45).
Regarding claim 19, Sprague teaches wherein the custody server is configured to enrol a new user by: receiving a user identifier for the new user; receiving a public key of a client access key pair for the new user; storing the user identifier and the public key; generating a transaction-signing cryptographic key pair for the new user; and storing the generated transaction-signing cryptographic key pair in an encrypted enclave of the one or more encrypted enclaves of the trusted execution environment (¶ 38, 44, 50, 51-65, 67-72, 85-91).
Regarding claim 20, Sprague teaches wherein the custody server is configured to provide a recovery mechanism for enabling a user to authorise a transaction when a user device associated with the user is unavailable, wherein the custody server is configured to determine whether further user-authentication data received from the user satisfies a recovery policy for the user, and to store new device-authentication data for a new device associated with the user in response to determining that the further authentication data satisfies the recovery policy for the user (¶ 91, 92).
Regarding claim 23, Guan discloses further comprising a transaction-processing system for performing the transaction on behalf of the user, wherein the custody server is configured to send the data representative of the digitally signed transaction to the transaction-processing system (¶ 16-18, 40, 46-48, 55-65, 78, 79, 81, 83).
Regarding claim 24, Guan discloses wherein the custody server is configured to receive the request to digitally sign a transaction on behalf of the user, over a network connection, from a transaction-processing system (¶ 19, 23, 46, 47, 50, 64, 68, 72-76).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Kadinsky et al., (WO 2021127577) teaches authentication server verifying transaction data from a user, with policies that are enforced.
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ILSE I IMMANUEL whose telephone number is (469)295-9094. The examiner can normally be reached Monday-Friday 9:00 am to 5:00pm.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, NEHA H PATEL can be reached on (571) 270-1492. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/ILSE I IMMANUEL/Primary Examiner, Art Unit 3699
Prosecution Insights