DETAILED ACTION
The present application, filed on 11/28/2023 is being examined under the AIA first inventor to file provisions.
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 11/25/2025 has been entered.
The following is a non-final Office Action on the Merits in response to Applicant’s submission.
a. Claims 1, 9, 12-14 are amended
b. Claims 8 are cancelled
Overall, Claims 1-7, 9-17 are pending and have been considered below.
Claim Rejections - 35 USC § 103
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
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-3, 5, 7, 9-17 are rejected under 35 U.S.C. 103 as being unpatentable over Davis et al (US 6,367,009), in view of Rapowitz et al (US 2023/0252456).
Regarding Claims 1, 9-17: Davis: A system for key recovery in delegated signing for recovering access in case of a compromised signing key, the system comprising one or more end user devices, one or more application provider servers and a signing system, wherein {see at least fig3, rc300, rc330, rc350, (12)/[9:24-48] client device, server, server (reads on application servers, signing system)}
(a) the one or more end user devices comprise one or more processors and one or more storage devices storing instructions that, when executed by the one or more processors, cause the one or more processors to perform operations for;
(a1) initiating a transaction associated with the end user device, {see at least (20)/[11:29-64] transaction being requested}
(a2) receiving from the application provider server an authentication challenge for the transaction, {see at least (27)/[13:16-26] client authentication process}
(a3) signing the authentication challenge, and {see at least (23)-(25)/[5:25-6:26] digital signature; signed delegate document; fig4, rc480, (24)/[12:40-58] signed document}
(a4) returning the signed authentication challenge to the application provider server, and {see at least fig6, rc603, (24)/[12:40-58] the authentication certificate is return to server}
wherein
(b) the one or more application provider servers comprise one or more processors and one or more storage devices storing instructions that, when executed by the one or more processors, cause the one or more processors to perform operations {see at least fig3, rc300, rc330, rc350, (12)/[9:24-48] client device, server, server (reads on processors with memory)}
(b1) obtaining transaction data describing the transaction, {see at least (20)/[11:29-64] transaction being requested}
(b2) forwarding the transaction data to the signing system for authentication and authorization, {see at least (43)/[15:45-16/15] limiting the value of a transaction (reads on transaction data)}
(b3) receiving the authentication challenge from the signing system, {see at least fig6, rc603, (24)/[12:40-58] the authentication certificate is return to server}
(b4) forwarding the authentication challenge to the end user device, {see at least fig6, rc602, rc603, (24)-(26)/[12:40-13:15] send authentication to device; receive reply}
(b5) receiving the signed authentication challenge from the end user device, and {see at least fig6, rc602, rc603, (24)-(26)/[12:40-13:15] send authentication to device; receive reply}
(b6) sending the signed authentication challenge to the signing system, and {see at least fig6, rc602, rc603, (24)-(26)/[12:40-13:15] send authentication to device; receive reply}
wherein
(c) the signing system comprises one or more processors and one or more storage devices storing instructions that, when executed by the one or more processors, cause the one or more processors to perform operations for: {see at least fig3, rc300, rc330, rc350, (12)/[9:24-48] client device, server, server (reads on processors with memory)}
(c1) receiving the transaction data from the application provider server, {see at least (20)/[11:29-64] transaction being requested}
(c2) sending the authentication challenge to the application provider server {see at least (43)/[15:45-16/15] limiting the value of a transaction (reads on transaction data)}
(c3) receiving the signed authentication challenge from the application provider server, {see at least fig6, rc603, (24)/[12:40-58] the authentication certificate is return to server}
(c4) verifying whether the authentication challenge is correctly signed, {see at least (24)/[12:40-58] signed delegate document (based on the broadest reasonable interpretation (MPEP 2111), reads on correctly signed}
(c5) verifying whether the end user device is authorized to perform the transaction, and {see at least (9)/[3:25-65] list with authorized users}
(c5) instructing a plurality of signing devices to sign a message derived from the transaction data with a private key corresponding to the end user device using a multi-party signing algorithm. {see at least (9)/[3:25-65] list with authorized users}
(2h) the application provider server replaces the first public key with the second public key, thereby recovering access for the end user device. {see at least (26)/[6:27-51] temporary public key (reads on replacing a first with a second public key}
Davies does not disclose, however, Rapowitz discloses:
an application provider server
stores a first public key associated with a first asymmetric key pair, used by an end user device for signing authentication challenges, {see at least fig5, [0043] storing the private keys}
wherein
(1) in a set-up phase:
(1a) the end user device is configured to encrypt a recovery private key using a recovery symmetric key created on the one or more end user devices, the recovery private key corresponding to a recovery asymmetric key pair, comprising a recovery private key and a recovery public key, and {see at least [0011] encrypt a recovery private key and a recovery public key.}
(1b) the application provider server is configured to store the encrypted recovery private key and the recovery public key, and {see at least fig5, [0043] storing the private keys}
(2) in a recovery phase, the application provider server and the end user device are configured for the following in order to recover access for the end user device in case of a compromised signing key of the end user device {The claim element “in order to recover access for the end user device in case of a compromised signing key of the end user device” consists entirely of language disclosing at most a reason to have performed earlier method steps (intended use or field of use), but does not affect the functions in a manipulative sense (see MPEP 2103 I C) and imparts neither structure nor functionality to the claimed method (see MPEP 2111.05, MPEP 2114 and authorities cited therein), so it is considered but given no patentable weight. The reference is provided for the purpose of compact prosecution.}
(2a) the application provider server shares the encrypted recovery private key with the end user device, {see at least fig1, rc102, [0025] server communicates with a user device}
(2b) the application provider server sends a recovery challenge to the end user device, {see at least fig4A, rc440, [0034]-[0039] authentication question (reads on recovery question) sent to user device (reads on recovery challenge)}
(2c) the end user device decrypts the recovery private key, using the recovery symmetric key, {see at least [0022] stored on a user device in order to decrypt stored seed phrases}
(2d) the end user device signs the recovery challenge using the decrypted recovery private key, {see at least [0020] These triggers can include receiving encryption keys from the user … receiving answers to knowledge-based authentication questions from the end user (reads on recovery challenge in connection with signature)}
(2e) the end user device signs a second public key associated with a second asymmetric key pair, used by the end user device for signing new authentication challenges, {see at least [0027] private keys for use with signing a transaction … used for signing transactions (“keys” points to more than one, e.g., a second key); fig2, rc208, rc210 more private keys reads on second key. The claim element “used by the end user device for signing new authentication challenges” consists entirely of language disclosing at most a reason to have performed earlier method steps (intended use or field of use), but does not affect the functions in a manipulative sense (see MPEP 2103 I C) and imparts neither structure nor functionality to the claimed method (see MPEP 2111.05, MPEP 2114 and authorities cited therein), so it is considered but given no patentable weight. The reference is provided for the purpose of compact prosecution.}
(2f) the end user device sends the signed recovery challenge and the second public key to the application provider server, {see at least fig1, rc102, [0025]-[0026] access recovery on the seed phrase; fig2, rc208, rc210 more private keys reads on second key}
(2g) the application provider server validates the signed recovery challenge, and {see at least [0010] The method can include comparing the answer with the account information (reads on validating the recovery challenge); [0022] authenticating user based on the answer on the authentication question (reads on validating the recovery challenge); fig1, rc102, rc110, [0038] comparing the answer (reads on recovery challenge) to account information (reads on validating); fig4, rc400, rc450, [0039] answer to request for confirmation); [0048] the answer is correct (reads on validating the recovery challenge); [0064], the answer (reads on recovery challenge) matches the account information}
It would have been obvious to one of ordinary skill in the art, at the time of filing, to modify Davis to include the elements of Rapowitz. One would have been motivated to do so, in order to allow the system to work in a recovery mode as well. In the instant case, Davis evidently discloses delegating signing. Rapowitz is merely relied upon to illustrate the functionality of generating and using recovery keys in the same or similar context. Since both delegating signing, as well as generating and using recovery keys 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 Davis, as well as Rapowitz, would function in the same manner in combination as they do in their separate embodiments, it is concluded that their resulting combination would be predictable. Accordingly, the claimed subject matter is obvious over Davis / Rapowitz.
Regarding Claim 2: Davis, Rapowitz discloses the limitations of Claim 1. Davis further discloses: wherein the one or more end user devices comprise a key storage in secure hardware storing a private key associated with an asymmetric key pair, and the one or more end user devices are further configured to
sign the authentication challenge using the private key. {see at least (9)/[3:25-65] list with authorized users}
Regarding Claim 3: Davis, Rapowitz discloses the limitations of Claim 1. Davis further discloses: wherein the end user device is configured to connect to an external signing device, and the end user device is further configured to
sign the authentication challenge using the external signing device. {see at least (25)/[12:58-64] creating a digital signature and sending it to the server}
Regarding Claim 5: Davis, Rapowitz discloses the limitations of Claim 1. Davis further discloses: wherein
the signing system is configured to
provide the signed authentication challenge to the plurality of signing devices, and {see at least (9)/[3:25-65] list with authorized users}
the signing devices are configured to
validate the signed authentication challenge. {see at least fig6, rc603, (24)/[12:40-58] the authentication certificate is return to server; (23)/[12:15-40] certificate is valid (reads on validating)}
Regarding Claim 7: Davis, Rapowitz discloses the limitations of Claim 1. Davis further discloses:
wherein if the challenge is not correctly signed according to the verifying whether the authentication challenge is correctly signed, the signing system rejects the transaction, and/or {Davis fails to explicitly disclose the conditional claim limitation; however, it is reasonable to assume that one of ordinary skills in the art will realize that an incorrect signature will lead to the denial of the request – see MPEP 2123 and MPEP 2144.01}
if the end user device is not authorized according to the verifying whether the end user device is authorized, the signing system rejects the transaction. {see at least (28)/13:27-43] request is rejected}
Claims 4, 6 are rejected under 35 U.S.C. 103 as being unpatentable over Davis et al (US 6,367,009), in view of Rapowitz et al (US 2023/0252456), in further view of Hammad et al (US 2008/0005937).
Regarding Claim 4: Davis, Rapowitz discloses the limitations of Claim 1. Davis, Rapowitz does not disclose, however, Lindell discloses: wherein
the signing system is configured to
execute in a set-up phase a distributed key generation, creating a plurality of key shares configured for a threshold signature scheme, and to {see at least [0040] key shares distributed among nodes}
distribute the plurality of key shares to the plurality of signing devices, {see at least [0040] key shares distributed among nodes}
a signing device comprises a key storage storing a key share of the plurality of key shares, one or more processors, and one or more storage devices storing instructions that, when executed by the one or more processors, cause the one or more processors to perform operations for: {see at least [0003] using key shares stored by nodes}
(i) retrieving the key share, and {see at least [0040] key shares distributed among nodes}
(ii) generating a signature share for the transaction data, and {see at least fig8, rc810, [0072] sending shares of a signature}
wherein the signing system is configured to
combine a plurality of signature shares generated by the plurality of signing devices into a combined signature according to the threshold signature scheme. {see at least [0004] combining the shares into decrypted signature}
It would have been obvious to one of ordinary skill in the art, at the time of filing, to modify Davis, Rapowitz to include the elements of Lindell. One would have been motivated to do so, in order to enhance the signing security. In the instant case, Davis, Rapowitz evidently discloses delegating signing. Lindell is merely relied upon to illustrate the functionality of combining signature shares in the same or similar context. Since both delegating signing, as well as combining signature shares 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 Davis, Rapowitz, as well as Lindell would function in the same manner in combination as they do in their separate embodiments, it is concluded that their resulting combination would be predictable. Accordingly, the claimed subject matter is obvious over Davis, Rapowitz / Lindell.
Regarding Claim 6: Davis, Rapowitz, Lindell discloses the limitations of Claim 4. Lindell further discloses:
wherein the combined signature is not returned to the end user device, and
wherein the signing system or the application provider server are configured to send the transaction data and the combined signature to an external service interface. {see at least fig8, rc810, [0072] sending shares of a signature}
It would have been obvious to one of ordinary skill in the art, at the time of filing, to modify Davis, Rapowitz, Lindell to include additional elements of Lindell. One would have been motivated to do so, in order to enhance the transaction security. In the instant case, Davis, Rapowitz, Lindell evidently discloses utilizing an external service. Lindell is merely relied upon to illustrate the additional functionality of utilizing an external service 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.
The prior art made of record and not relied upon which, however, is considered pertinent to applicant's disclosure:
US 20050120217 A1 Fifield, Davin et al. Apparatus, System, and Method for Electronically Signing Electronic Transcripts - A method for electronically signing an electronic transcript. The method includes obtaining an image of a court reporter's signature which may be incorporated into an electronic transcript. A hash operation performed on the electronic transcript to generate a representation of the contents of the electronic transcript. The representation of the contents of the electronic transcript is recorded/time stamped by a digital notary service, from which a notary record of the time stamping is obtained from the digital notary service. The notary record is digitally signed, and an electronically signed electronic transcript is formed by bundling the digitally signed notary record with the electronic transcript and with the data identifying the user. In this manner, an electronic transcript with an electronic signature is created. The electronic transcript may be viewed, with the image displayed in the viewer having an image of the court reporter's signature.
US 20040243811 A1 Frisch, Laurent et al. Electronic signature method with a delegation mechanism, and equipment and programs for implementing the method - A token of delegation from a first signatory to a second signatory is generated and the delegation token is associated with a document signed electronically by means of a cryptographic key of the second signatory. The delegation token contains delegation data signed electronically for the first signatory, in particular an identifier of the second signatory. It is generated by a server in response to a request relating to the signing of the document, sent by the second signatory.
US 20200019715 A1 MALLIAH; Avinash et al. SYSTEM AND METHOD FOR MULTI-PARTY ELECTRONIC SIGNING OF ELECTRONIC DOCUMENTS - A method for signing an electronic document is disclosed. The method includes: receiving, from a first client device: a first electronic document in a first state, the first electronic document containing first data in the first state; a first indication of approval for the first electronic document in the first state; and a selection of one or more second client devices; sending, to each of the one or more second client devices, an invite to access the first electronic document in the first state, each invite including a link to access the first electronic document; receiving, from at least one of the one or more second client devices, a second indication of approval for the first electronic document in the first state; validating the second indications of approval; in response to the validating, submitting a locked form version of the first electronic document to a virtual document signing ceremony.
US 20170083867 A1 Saxena; Neha et al. DOCUMENT DISTRIBUTION AND INTERACTION WITH DELEGATION OF SIGNATURE AUTHORITY - Improved workflows allow delegation of authority to electronically sign a document according to a delegation rule. The delegation rule specifies a document criterion and a delegate who is authorized to sign documents meeting the criterion. The criterion may be based on subject matter, document originator, or receipt time. Delegation rules can also be invoked in response to specified conditions or events, such as receipt of an automated out-of-office notification, or failure to receive any response to a signature request within a certain time. When an electronic signature system processes a document meeting the specified criterion, or detects one of the specified conditions or events, the document is sent to the delegate for signature instead of the originally intended signatory. The workflow initiator and delegator are optionally notified of such delegation before the document is sent to the delegate, thus giving him/her a degree of control over the delegation.
US 20230254167 A1 DUONG; Peter Thien et al. COMPUTING SYSTEMS FOR KEYING AND REKEYING CRYPTOGRAPHIC CREDENTIALS FOR ACCESSING A DATA CHAIN USING STRONG AUTHENTICATION - User accounts for blockchain technology are prone to security risks, such as account take-overs by malicious actors and lost or inaccessible wallets. A data access server system is herein provided to enable strong authentication credentials, such as FIDO2 public and private key pairs that adhere to Fast Identity Online (FIDO) protocols, to be used generate user account. The FIDO2 public key, also herein called a device authenticator public key, is embedded in a code script, and the code script is executed by the data access server system to verify the user using FIDO authentication. The data access server system also provides user tools to create credentials and associate one or more credentials with a blockchain user account. The user tools also enable rekeying of a blockchain user account with different credentials from another blockchain user account, with both accounts belonging to the same user.
US 11245514 B1 Mao; Zhihong et al. Blockchain delegation - Systems and methods that implement delegation on a blockchain network. A delegate blockchain transaction may be broadcasted to a blockchain network that encodes: a delegator blockchain user, a delegate blockchain user; information that indicates one or more permissions that the delegate blockchain user is authorized to perform, and an attestation that the delegator blockchain user authorizes the delegation. A delegate blockchain user may generate a blockchain transaction which is digitally signed using a delegate's private key in place of a delegator's private key.
US 5825880 Sudia; Frank W. et al. Multi-step digital signature method and system - A multi-step signing system and method uses multiple signing devices to affix a single signature which can be verified using a single public verification key. Each signing device possesses a share of the signature key and affixes a partial signature in response to authorization from a plurality of authorizing agents. In a serial embodiment, after a first partial signature has been affixed, a second signing device exponentiates the first partial signature. In a parallel embodiment, each signing device affixes a partial signature, and the plurality of partial signatures are multiplied together to form the final signature. Security of the system is enhanced by distributing capability to affix signatures among a plurality of signing devices and by distributing authority to affix a partial signature among a plurality of authorizing agents.
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 with the latter.
With respect to Applicant’s Remarks as to the claims being rejected under 35 USC § 101.
Applicant’s arguments are persuasive. A further review of the eligibility rejection, in light of Applicant’s arguments, reveals that the additional elements of the independent claims would integrate the identified abstract idea at Step 2A2, for they bring about an improvement to the technical field of advanced cryptography (see MPEP 2106.05(a)).
With respect to Applicant’s Remarks as to the claims being rejected under 35 USC § 103.
Applicant submits that “… Rapowitz et al. lacks any disclosure of any step in the key recovery process involving recovery challenges, as it does not disclose recovery challenges, but seed phrases, which are not compatible with the claimed system. Furthermore, Rapowitz et al is completely silent on delegated signing, or any element of such delegated signing system. So, there is no teaching on delegated signing, such a delegated signing system. or any improved key recovery protocol for such system disclosed in Rapowitz et al. Rapowitz only discussed seed phrases, of which the disadvantages and incompatibility with the claimed system are discussed in the application as filed.”
Examiner has carefully considered, but doesn’t find Applicant’s arguments persuasive.
Rapowitz discloses:
(2b) the application provider server sends a recovery challenge to the end user device, {see at least fig4A, rc440, [0034]-[0039] authentication question (reads on recovery question) sent to user device (reads on recovery challenge)}
(2d) the end user device signs the recovery challenge using the decrypted recovery private key, {see at least [0020] These triggers can include receiving encryption keys from the user … receiving answers to knowledge-based authentication questions from the end user (reads on recovery challenge in connection with signature)}
(2g) the application provider server validates the signed recovery challenge, and {see at least [0010] The method can include comparing the answer with the account information (reads on validating the recovery challenge); [0022] authenticating user based on the answer on the authentication question (reads on validating the recovery challenge); fig1, rc102, rc110, [0038] comparing the answer (reads on recovery challenge) to account information (reads on validating); fig4, rc400, rc450, [0039] answer to request for confirmation); [0048] the answer is correct (reads on validating the recovery challenge); [0064], the answer (reads on recovery challenge) matches the account information}
Therefore, it is concluded that Rapowitz discloses the claim limitations.
Thus, the rejection is proper and has been maintained.
Examiner remark: Hammand et al (US 2008/0005037) also discloses the limitations flagged by the applicant.
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 rejection is maintained, necessitated by the fact that the rejection of the claims under 35 USC § 103 has not been overcome.
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