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 .
The present application, filed on June 07, 2024, is accepted.
Claims 1 – 20 are being considered on the merits.
Drawings
The drawings, filed on June 07, 2024, are accepted.
Specification
The specification, filed on June 07, 2024, is accepted.
Double Patenting
No rejection warranted at application’s initial filling time of filling for a patent.
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 1 – 20 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 1, Yamamoto teaches a system comprising: a processor; [Yamamoto, col. 2 lines 60 – 67 to col. 3 lines 1 – 2 discloses an apparatus includes a memory and a processor operatively coupled to the memory. The processor is configured to generate a derived private key by inputting, to an internal key derivation function, a timestamp and an ascendant private key. The processor is configured to post an ascendant public key associated with the ascendant private key as related to the timestamp in a public ledger. The processor is configured to sign a message using a signature associated with the derived private key to define a signed message.] a ledger database comprising a set of public keys associated with a first user account, a first public key of the set of public keys indicated as an active key; [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).] and a memory that stores program code executable by the processor circuit, [Yamamoto, col. 2 lines 44 – 52 discloses a non-transitory processor-readable medium stores code representing instructions configured to be executed by a processor. The code includes code to cause the processor to receive, at a first compute device, (1) a message signed using a signature associated with a derived private key of a second compute device, and (2) an identifier. The code further includes code to cause the processor to retrieve, using the identifier, an ascendant public key associated with the second compute device.] the program code comprising: a ledger manager that: responsive to receiving a first active key request from a first application, causes a first cryptographic operation to be performed on first data accessible to the first application using the first public key, causes a result of the first cryptographic operation to be provided to a second application associated with the first user account; [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)], but Yamamoto does not teach responsive to receiving an update key request from the second application, updates the active key to a second public key of the set of public keys, and responsive to receiving a second active key request from the first application, causes a second cryptographic operation to be performed on second data accessible to the first application using the second public key; and causes a result of the second cryptographic operation to be provided to the second application.
However, Ornelas does teach responsive to receiving an update key request from the second application, [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).] updates 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).] and responsive to receiving a second active key request from the first application, causes a second cryptographic operation to be performed on second data accessible to the first application using the second public key; [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).] and causes a result of the second cryptographic operation to be provided to the second application. [Ornelas, col. 33 lines 58 – 67 to col. 34 lines 1 – 10 discloses key rotation can be automated, e.g., where it is triggered periodically. In examples, the HSM 511 may generate the new public key 562-1 and new private key 561-1 at periodic intervals and/or based on the expiry for the old public key 562-2 having passed. Alternatively, the HSM 511 may generate the new public key 562-1 and new private key 561-1 in response to a request, e.g., sent from the first HSM client 566A. Once the new public key 562-1 and new private key 561-1 are generated, the HSM 511 may apply a signature 572 to the new public key 562-1 using the old private key 561-2, which can only be validated using the old public key 562-2. The new public key 562-1 and the signature of the new public key 572 may be transmitted to the first computing device 516 then optionally transferred to the second computing device 504 (e.g., via removable media when the first computing device 516 is air-gapped). The new public key 562-1 and the signature of the new public key 572 may then be transmitted to the distributed ledger 108 (e.g., via a special file separate from any minting requests 336) for storage.]
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 2, modified Yamamoto teaches the system of claim 1, wherein the ledger comprises a set of key pairs comprising: the set of public keys; and a set of private keys, wherein each private key of the set of private keys corresponds to a respective public key of the set of public keys. [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).]
As per claim 3, modified Yamamoto teaches the system of claim 1, wherein the first and second public keys are generated 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.]
Regarding claim 4, modified Yamamoto teaches the system of claim 3, but Yamamoto does not teach wherein the program code further comprises a key validator that: receives an undetermined public key; and determines 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 wherein the program code further comprises a key validator that: receives an undetermined public key; and determines 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 5, modified Yamamoto teaches the system of claim 4, wherein to determine whether the undetermined public key is part of the set of public keys, the key validator: utilizes a zero-knowledge protocol to verify the public key. [Yamamoto, col. 9 lines 29 – 40 discloses the key authenticator 163 can be configured to authenticate a compute device (e.g., trusted party compute device 110) by verifying a signature using a derived public key (e.g., generated by key generator 161). The signature can be or include the signature associated with the derived private key (e.g., generated via key generator 141) that was used (e.g., by key generator 141) to define the signed message. In some implementations, the key authenticator 163 can be configured to authenticate and verify one or more of an identity of the compute device (e.g., trusted party compute device 110) and/or an authenticity of the signature.]
As per claim 6, modified Yamamoto teaches the system of claim 3, wherein the program code further comprises a key generator that: generates the set of public keys based on the 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.] and stores the set of public keys in the ledger database. [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).]
As per claim 7, modified Yamamoto teaches the system of claim 6, wherein the key generator further: receives, from the second application, the seed value; [Yamamoto, col. 6 lines 24 – 33 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).] and generates the set of public keys based on the 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.]
As per claim 8, modified Yamamoto teaches the system of claim 1, 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 to update the active key, the ledger manager: increments 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 9, modified Yamamoto teaches the system of claim 1, but Yamamoto does not teach wherein the ledger manager: determines a number of unused keys in the set of public keys satisfies a key generation criterion; and causes 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 wherein the ledger manager: determines 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 causes 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]
As per claim 10, modified Yamamoto teaches the system of claim 1, wherein the second cryptographic operation comprises utilizing the second public key to encrypt the second data, [Yamamoto, col. 12 lines 40 – 52 discloses the processor (e.g., processor 160) can be configured to sign a second message using a signature associated with the second derived private key to define a second signed message, the processor is configured to send the second signed message and the second timestamp to a second relying compute device (not shown in FIG. 4) such that the second relying compute device retrieves the ascendant public key from the public ledger using the second timestamp, derives a second derived public key that is paired with the second derived private key, and uses the second derived public key to authenticate the signature associated with the second derived private key] and to cause the encrypted second data to be provided to the second application, ledger further: provides the encrypted second data to the first application; or provides the encrypted second data to the second application on behalf of the first application. [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 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)], but Yamamoto does not teach responsive to receiving 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; and responsive to receiving an active key request from a second computing device on behalf of a second user account, causing a cryptographic operation to be performed using the second public key.
However, Ornelas does teach responsive to receiving 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).] and responsive to receiving an active key request from a second computing device on behalf of a second user account, causing a cryptographic operation to be performed using the second public key. [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).]
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 12, modified Yamamoto teaches the method of claim 11, wherein said causing the cryptographic operation to be performed comprises: causing data accessible to the second computing device to be encrypted 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)).]
As per claim 13, modified Yamamoto teaches the method of claim 12, wherein said causing the data to be encrypted comprises: providing the second computing device access to the second public key; or utilizing the second public key to encrypt the data and causing the encrypted data to be provided to the first 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).]
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]
Regarding claims 15 – 16, they recite feature similar to feature within claims 8 – 9, therefore, they are rejected in a similar manner.
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 said causing a cryptographic operation to be performed using the second public key comprises: providing a 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.] utilizing the second public key to verify integrity of first data; or utilizing the second public key to encrypt second data accessible to the second computing device and causing the encrypted data to be provided to the first 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).]
Regarding claim 19, it recites features similar to features within claim 8, therefore, it is rejected in a similar manner.
Regarding claim 20, modified Yamamoto teaches the computer readable storage medium of claim 11, the method further comprising: providing a 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]
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.”
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