DETAILED ACTION
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
This office action is in response to communication filed on April 20, 2026.
Status of claims within the present application:
Claims 1 – 11 and 13 – 21 are pending.
Claims 1 – 2, 7, 10 – 11, 13, 17 – 18, and 20 are amended.
Claim 12 is cancelled.
Claim 21 is new.
Response to Arguments
With respect to claims 1 – 10 that were rejected under 35 U.S.C. 103 as being unpatentable over US 10491404 B1 to Yamamoto in view of US 11887072 B2 to Ornelas et al., (hereinafter, “Ornelas”), Applicant’s remarks, see page [8 – 9], filed April 20, 2026, have been fully considered and are persuasive. Therefore, the rejection is withdrawn.
With respect to claims 11 – 21 that were rejected under 35 U.S.C. 103 as being unpatentable over US 10491404 B1 to Yamamoto in view of US 11887072 B2 to Ornelas et al., (hereinafter, “Ornelas”), Applicant’s remarks, see page [8 – 9], filed April 20, 2026, have been fully considered, but are moot because of the new interpretation the previously reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument. Examiner further noted that independent claims 11 and 17 would be allowable if they amended similar to the limitation of independent claim 1.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 11 and 13 – 21 are rejected under 35 U.S.C. 103 as being unpatentable over US 10491404 B1 to Yamamoto in view of US 11887072 B2 to Ornelas et al., (hereinafter, “Ornelas”).
Regarding claim 11, Yamamoto teaches a method comprising: storing, in a ledger database, a set of public keys associated with a first user account; [Yamamoto, col. 7 lines 39 – 51 discloses the public ledger is configured to store a set of ascendant public keys associated with a compute device (e.g., trusted party compute device 110) or a user (e.g., a trusted party) of the trusted party compute device 110. In some implementations, each ascendant public key from the set of ascendant public keys is associated with a unique and associated identifier (e.g., timestamp). In some implementations, the ledger can be or include, for example, a public ledger, a public ascendant ledger, and the like (“ascendant key ledger” or “public ledger” or “ascendant key ledger” or “ledger”). The ascendant public key can include or be associated with, for example, an ascendant key from which an associated derived private key is generated (e.g., via key generator 141).] assigning a first public key of the set of public keys as an active key; [Yamamoto, col. 7 lines 14 – 31 discloses The ledger manager 145 is configured to post, such as in a ledger (e.g., owned or controlled by a trusted party), an ascendant public key. In some implementations, the ledger manager 145 is configured to post the ascendant public key with an associated identifier (e.g., timestamp). For example, the ascendant public key can be posted in the ledger in association with an identifier, such as for (later) retrieval by a relying party (e.g., with which the trusted party is or will transact or interact) from the ledger using the timestamp. Once retrieved, the relying party can use the ascendant public key to generate (e.g., by derivation from the ascendant public key) an associated, linked, paired, or otherwise related derived public key. Accordingly, the derived public key (generated based on the retrieved ascendant public key and the timestamp) can be used, such as by the relying party, to, for example, authenticate a signature (of or from the trusted party), such as can be attached to a signed message (e.g., generated by key signer 143)] and causing, by the ledger manager, the encrypted data to be provided to the first computing device by or on behalf of the second computing device [Yamamoto, col. 22 lines 22 – 41 discloses the method 400A proceeds at step 404 where at least one first-level signature is applied to the currency request 330 using at least one first-level private key, e.g., at the financial institution 112. In examples, a first signature 332 may be applied by hashing the currency request 330, encrypting the hash with a first private key, and attaching the encrypted hash to the currency request 330. The singly-signed currency request 352 may optionally be recorded in the distributed ledger 108. Optionally, a second signature 334 may be applied by hashing the payload (the currency request 330 and the first signature 332), encrypting the hash with a second private key, and attaching the encrypted hash to the payload (the currency request 330 and the first signature 332). The doubly-signed currency request 354 may optionally be recorded in the distributed ledger 108. In examples, the first-level signature(s) are added to the currency request 330, which is already on in the distributed ledger 108, by simply recording the first-level signature(s) on the distributed ledger 108 (instead of downloading the currency request 330 and re-recording it in the distributed ledger 108).], but Yamamoto does not teach responsive to receiving, by a ledger manager, an update key request from a first computing device on behalf of the first user account, updating the active key to a second public key of the set of public keys; responsive to receiving, by a ledger manager, an active key request from a second computing device on behalf of a second user account, causing a cryptographic operation to be performed on data accessible to the second computing device using the second public key;
However, Ornelas does teach responsive to receiving, by a ledger manager, an update key request from a first computing device on behalf of the first user account, [Ornelas, col. 36 lines 48 – 56 discloses where the at least one processor (e.g., in the first computing device 516) adds a subsequent signature to a subsequent minting request 336 using the new private key 561-1 and sends (e.g., via the second computing device 104) the subsequent signature to a subsequent minting request 336 to a second node 102 implementing the distributed ledger 108 (where the second node 102 is the same or different than the first node 102).] updating the active key to a second public key of the set of public keys; [Ornelas, col. 16 lines 40 – 45 discloses the active keys 348 in the distributed ledger 108 can be rotated at which point the previously-active key is now designated as “previous” or “inactive”. The previous/inactive keys 350 are still stored in the distributed ledger 108 (to prove historical minting requests went through the appropriate verification).] responsive to receiving, by a ledger manager, an active key request from a second computing device on behalf of a second user account, [Ornelas, col. 36 lines 57 – 63 discloses the method 600 proceeds at optional step 620 where the at least one processor (e.g., in the second node 102 implementing the distributed ledger 108) mints subsequent digital currency only in response to at least successfully verifying the subsequent signature using the new public key 562-1 (and optionally verifying any other signatures sent in or with the subsequent minting request 336).] causing a cryptographic operation to be performed on data accessible to the second computing device using the second public key; [Yamamoto, col. 36 lines 31 – 41 discloses the method 600 proceeds at optional step 614 where the at least one processor attempts to verify the signature 572, received at the first node 102, using the public key 562. In order to verify the signature 572, a smart contract may: (1) decrypt the signature 572 using the old public key 562-2 corresponding to the old private key 561-2 used for signing; (2) determine a hash of the original new public key 562-1; and (3) compare the decrypted hash from (1) with the hash (from (2)) to determine if both are the same. The signature is verified only if the decrypted hash from (1) is the same as the hash (from (2)).]
Therefore, it would have been obvious to one of ordinary skill within the art before the effective filling date to combine Ornelas’s system with Yamamoto’s system, with a motivation for as long as that first public key 562 recorded on the distributed ledger 108 is clean (came from a trusted source, such as a financial institution 112, a currency management department 110, or a director's office 120), then an auditor can verify whether every subsequent public key 562 also came from the same trusted source. [Ornelas, col. 31 lines 40 – 46]
As per claim 13, modified Yamamoto teaches the method of claim 11, wherein causing the data accessible to the second computing device to be encrypted comprises: providing the second computing device access to the second public key; [Yamamoto, col. 22 lines 22 – 41 discloses the method 400A proceeds at step 404 where at least one first-level signature is applied to the currency request 330 using at least one first-level private key, e.g., at the financial institution 112. In examples, a first signature 332 may be applied by hashing the currency request 330, encrypting the hash with a first private key, and attaching the encrypted hash to the currency request 330. The singly-signed currency request 352 may optionally be recorded in the distributed ledger 108. Optionally, a second signature 334 may be applied by hashing the payload (the currency request 330 and the first signature 332), encrypting the hash with a second private key, and attaching the encrypted hash to the payload (the currency request 330 and the first signature 332). The doubly-signed currency request 354 may optionally be recorded in the distributed ledger 108. In examples, the first-level signature(s) are added to the currency request 330, which is already on in the distributed ledger 108, by simply recording the first-level signature(s) on the distributed ledger 108 (instead of downloading the currency request 330 and re-recording it in the distributed ledger 108).]
Regarding claim 14, modified Yamamoto teaches the method of claim 11, further comprising: generating the set of public keys based on a seed value; [Yamamoto, col. 4 lines 51 – 55 discloses The key generator 141 can be configured to generate or produce linked or associated cryptographic keys. For example, the key generator 141 can be configured to implement one or more key derivation functions to generate one or more derived keys based on a root key. Col. 4 lines 62 – 67 to col. 5 lines 1 – 6 discloses the key generator 141 can be configured to selectively implement one or more key derivation functions to generate a derived key based on a root key (e.g., based on a desired or intended use of the derived key to be generated). An intended use, or trusted party key usage, of a derived key can be, for example, to represent an identity of an entity, subject, person, user, or trusted party (collectively, “trusted party(ies)”), and further, to provide for authentication, integrity, and/or non-repudiation of the identity, or relying party key usage, as such can be used, for example, in an interaction or transaction between the trusted party and a relying party, such as described herein.], but Yamamoto does not teach receiving an undetermined public key; and determining whether the undetermined public key is part of the set of public keys based on the seed value and the undetermined public key.
However, Ornelas does teach receiving an undetermined public key; and determining whether the undetermined public key is part of the set of public keys based on the seed value and the undetermined public key. [Ornelas, col. 36 lines 31 – 41 discloses the method 600 proceeds at optional step 614 where the at least one processor attempts to verify the signature 572, received at the first node 102, using the public key 562. In order to verify the signature 572, a smart contract may: (1) decrypt the signature 572 using the old public key 562-2 corresponding to the old private key 561-2 used for signing; (2) determine a hash of the original new public key 562-1; and (3) compare the decrypted hash from (1) with the hash (from (2)) to determine if both are the same. The signature is verified only if the decrypted hash from (1) is the same as the hash (from (2)).]
Therefore, it would have been obvious to one of ordinary skill within the art before the effective filling date to combine Ornelas’s system with Yamamoto’s system, with a motivation for as long as that first public key 562 recorded on the distributed ledger 108 is clean (came from a trusted source, such as a financial institution 112, a currency management department 110, or a director's office 120), then an auditor can verify whether every subsequent public key 562 also came from the same trusted source. [Ornelas, col. 31 lines 40 – 46]
As per claim 15, modified Yamamoto teaches the method of claim 11, wherein the first public key is associated with a first count value in a sequence of count values, the second public key is associated with a second count value in the sequence of count values subsequent to the first count value, an active count is set to the first count value, and said updating the active key comprises: incrementing the active count to the second count value. [Yamamoto, col. 6 lines 17 – 23 discloses the timestamping system or technique can otherwise be or include any suitable incrementing method, such as a continually incrementing method, or the like, that can be represented by an integer (e.g., an integer value) or converted to an integer of any size (e.g., 32-bit, 64-bit, 96-bit), in accordance with embodiments of the present disclosure. Col. 6 lines 24 – 39 discloses inputting a timestamp to the key derivation function to generate the derived private key can include, for example, combining or amalgamating the timestamp with an ascendant private key (e.g., paired with an ascendant public key) to derive the derived private key (e.g., using a predefined hash algorithm or method). For example, in some instances, a timestamp can be input (with an ascendant private key) to a key derivation function to thereby generate the derived private key as a function of the timestamp (and an ascendant private key). Since the derived private key (e.g., a value of the derived private key) is generated so as to be dependent on the timestamp (e.g., a time at which the derived private key is generated), the timestamp cannot be separated, altered, or otherwise dissociated from the derived private key without also changing the value of the derived private key. Col. 6 lines 40 – 45 discloses that is, every new timestamp that is applied to the same parent key (e.g., a root key, a parent key) and chain code will produce a unique child key (e.g., a derived private key). As such, the timestamp can be used, for example, as a variable input (e.g., to a key derivation function) by which to produce multiple different child keys from the same parent key.]
Regarding claim 16, modified Yamamoto teaches the method of claim 11, but Yamamoto does not teach further comprising: determining a number of unused keys in the set of public keys satisfies a key generation criterion; and causing a new set of public keys to be generated, the new set of public keys comprising the unused keys, the active key, and a new public key.
However, Ornelas does teach further comprising: determining a number of unused keys in the set of public keys satisfies a key generation criterion; [Ornelas, col. 35 lines 8 – 21 discloses The method 600 begins at optional step 602 where the at least one processor determine whether a public key 562 in the system 500 has expired. In examples, the public key 562 corresponds to a private key 561 where only the public key 562 can validate digital signatures generated using the corresponding private key 561. In examples, the public key 562 may be identified as the public key 562 most recently stored in a key database 568. Optionally, the private key 561 (corresponding to the public key 562) may also be stored in the key database 568. In examples, the first computing device 516 may perform step 602 when a minting request 336 needs to be signed or when the public key 562 is otherwise needed to perform some action, e.g., encrypting data or validating a signature.] and causing a new set of public keys to be generated, the new set of public keys comprising the unused keys, the active key, and a new public key. [Ornelas, col. 35 lines 40 – 58 discloses the method 600 proceeds at step 604 where the at least one processor (e.g., in response to determining that the public key 562 has expired) generates a new private key 561-1 and a new public key 562-1. In examples, the first computing device 116 may send a request to a hardware security module (HSM) 511 to generate the new private key 561-1 and new public key 562-1 and receive the new public key 562-1 from the first computing device 116. In this scenario the original public key 562 (that is expired) should no longer be used and can be considered an old public key 562-2, assuming the new public key 562-1 is stored on the distributed ledger 108 as an active key. In examples, the HSM 511 is communicatively coupled to the first computing device 516 via a wired connection, e.g., USB, etc. Alternatively, the new keys could be generated and stored in a secure enclave on the first computing device 516 (e.g., using iOS® KEYCHAIN® or ANDROID® Keystore) where the new private key 561-1 never leaves the secure enclave on the first computing device 516.]
Therefore, it would have been obvious to one of ordinary skill within the art before the effective filling date to combine Ornelas’s system with Yamamoto’s system, with a motivation for as long as that first public key 562 recorded on the distributed ledger 108 is clean (came from a trusted source, such as a financial institution 112, a currency management department 110, or a director's office 120), then an auditor can verify whether every subsequent public key 562 also came from the same trusted source. [Ornelas, col. 31 lines 40 – 46]
Regarding claim 17, it recites features similar to features within claim 11, therefore, it is rejected in a similar manner.
As per claim 18, modified Yamamoto teaches the computer readable storage medium of claim 17, wherein causing a cryptographic operation to be performed using the second public key further comprises: providing the second computing device access to the second public key; [Yamamoto, col. 36 lines 31 – 41 discloses the method 600 proceeds at optional step 614 where the at least one processor attempts to verify the signature 572, received at the first node 102, using the public key 562. In order to verify the signature 572, a smart contract may: (1) decrypt the signature 572 using the old public key 562-2 corresponding to the old private key 561-2 used for signing; (2) determine a hash of the original new public key 562-1; and (3) compare the decrypted hash from (1) with the hash (from (2)) to determine if both are the same. The signature is verified only if the decrypted hash from (1) is the same as the hash (from (2)).] utilizing the second public key to authenticate a signature; [Yamamoto, col. 33 lines 50 – 57 discloses an auditor could use take a new public key 562-1 and the signature of the new public key 562-1 in the key database 568-2 and validate the signature to cryptographically prove that it was made using an old private key 561-2 that corresponds with an old public key 562-2 used to verify. This process could be repeated for each public key 562 in the key database 568-2 using the immediately prior private key 561 and public key 562.] or utilizing the second public key to verify integrity of first data. [Yamamoto, col. 22 lines 22 – 41 discloses the method 400A proceeds at step 404 where at least one first-level signature is applied to the currency request 330 using at least one first-level private key, e.g., at the financial institution 112. In examples, a first signature 332 may be applied by hashing the currency request 330, encrypting the hash with a first private key, and attaching the encrypted hash to the currency request 330. The singly-signed currency request 352 may optionally be recorded in the distributed ledger 108. Optionally, a second signature 334 may be applied by hashing the payload (the currency request 330 and the first signature 332), encrypting the hash with a second private key, and attaching the encrypted hash to the payload (the currency request 330 and the first signature 332). The doubly-signed currency request 354 may optionally be recorded in the distributed ledger 108. In examples, the first-level signature(s) are added to the currency request 330, which is already on in the distributed ledger 108, by simply recording the first-level signature(s) on the distributed ledger 108 (instead of downloading the currency request 330 and re-recording it in the distributed ledger 108).]
Regarding claim 19, it recites features similar to features within claim 15, therefore, it is rejected in a similar manner.
Regarding claim 20, modified Yamamoto teaches the computer readable storage medium of claim 17, the method further comprising: providing the second computing device, associated with a second user account, [Yamamoto, col. 36 lines 31 – 41 discloses the method 600 proceeds at optional step 614 where the at least one processor attempts to verify the signature 572, received at the first node 102, using the public key 562. In order to verify the signature 572, a smart contract may: (1) decrypt the signature 572 using the old public key 562-2 corresponding to the old private key 561-2 used for signing; (2) determine a hash of the original new public key 562-1; and (3) compare the decrypted hash from (1) with the hash (from (2)) to determine if both are the same. The signature is verified only if the decrypted hash from (1) is the same as the hash (from (2)).], but Yamamoto does not teach a third computing device associated with a third user account access to the second public key.
However, Ornelas does teach a third computing device associated with a third user account access to the second public key. [Ornelas, col. 39 lines 28 – 42 discloses at least a third computing device at a director's office, the third computing device configured to apply at least one third-level signature to the signed minting request using at least one third-level private key; and a plurality of network nodes communicatively coupled in a peer-to-peer network of network nodes implementing a distributed ledger, at least one of the network nodes configured to: verify the at least one first-level signature, the at least one second-level signature, and the at least one third-level signature using at least one first-level public key, at least one second-level public key, and at least one third-level public key, respectively; and mint the digital currency when the at least one first-level signature, the at least one second-level signature, and the at least one third-level signature are successfully verified.]
Therefore, it would have been obvious to one of ordinary skill within the art before the effective filling date to combine Ornelas’s system with Yamamoto’s system, with a motivation for as long as that first public key 562 recorded on the distributed ledger 108 is clean (came from a trusted source, such as a financial institution 112, a currency management department 110, or a director's office 120), then an auditor can verify whether every subsequent public key 562 also came from the same trusted source. [Ornelas, col. 31 lines 40 – 46]
As per claim 21, modified Yamamoto teaches he computer readable storage medium of claim 17, wherein the first public key and the second public key are generated based by the first computing device based on a seed value. [Yamamoto, col. 4 lines 51 – 55 discloses the key generator 141 can be configured to generate or produce linked or associated cryptographic keys. For example, the key generator 141 can be configured to implement one or more key derivation functions to generate one or more derived keys based on a root key. Col. 4 lines 62 – 67 to col. 5 lines 1 – 6 discloses the key generator 141 can be configured to selectively implement one or more key derivation functions to generate a derived key based on a root key (e.g., based on a desired or intended use of the derived key to be generated). An intended use, or trusted party key usage, of a derived key can be, for example, to represent an identity of an entity, subject, person, user, or trusted party (collectively, “trusted party(ies)”), and further, to provide for authentication, integrity, and/or non-repudiation of the identity, or relying party key usage, as such can be used, for example, in an interaction or transaction between the trusted party and a relying party, such as described herein.]
Allowable Subject Matter
Claims 1 – 10 are allowed.
Conclusion
Pertinent prior art made of record however not relied upon:
US 20180343114 A1 to Ben-Ari
“System and method for executing cryptographically secure transactions in a network comprising a public ledger, comprising associating a first proposed transaction with a public keys smart contract and associating at least a second transaction including private data and public data in said network with a cryptographically secure transaction.”
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any 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 Phuc Pham whose telephone number is (571)272-8893. The examiner can normally be reached Monday - Thursday 7:30 AM - 4:30 PM; Friday 8:00 AM - 12:00 PM.
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, Linglan Edwards can be reached at (571) 270-5440. 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.
/P.P./Patent Examiner, Art Unit 2408
/LINGLAN EDWARDS/Supervisory Patent Examiner, Art Unit 2408
Prosecution Insights