DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
This written action is responding to the amendment dated on 12/29/2025.
Claims 1-7, 9-14 and 16-20 have been amended and all other Claims are previously presented.
Claims 1-20 are submitted for examination.
Claims 1-20 are pending.
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 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.
Priority
This application filed on December 04, 2023 claims priority of Provisional application 63/429,824 filed on December 02, 2022.
Response to Arguments
Applicant’s amendment, filed on December 29, 2025 has claims 1-7, 9-14 and 16-20 amended, and all other claims are previously presented. Among the amended claims, Claim 1 is an independent claim.
The prior objections to the claim 19 and claim 20 have been withdrawn in view of the applicant argument received in the amendment dated on December 29, 2025.
The prior 35 U.S.C. 112(b) rejection of Claims 1-7 have been withdrawn in view of the amendment received dated on December 29, 2025.
Applicant’s remark, filed on December 29, 2025 on the middle of page 8 regarding, “Applicant respectfully submits that claim 1 is not obvious over the cited references, for at least the reason that the cited references, either alone or in combination, do not teach or suggest all of the required limitations of claim. For instance, Applicant respectfully submits that the cited references, either alone or in combination, do not teach or suggest instructions to cause a key broker to:
generate a secret key based on the request;
generate the root certificate based on the secret key;
split the secret key into a plurality of shards;
provide a first shard of the plurality of shards to an agent;
as recited in independent claim 1”, and further remark, on bottom of page 8 regarding, “The cited references do not teach or suggest a key broker configured to "generate a secret key based on the request... [and] split the secret key into a plurality of shards," as recited in claim 1” has been considered, however is not found persuasive. Venable teaches, “At step 306, the at least three blockchain nodes 104 chosen at step 302 a CA private-public key pair 320 (see FIG. 3B). CA private-public key pair 320 is for the distributed CA 102 as a whole. Step 306 is described with reference to FIG. 3B. FIG. 3B depicts a block diagram of a CA private-public key pair 320, according to an embodiment. CA private-public key pair 320 comprises CA public key 118 and CA private key 325. CA public key 118 and CA private key 325 function similarly to private-public key pair 120. The CA private key 325 is generated in pieces (e.g., Distributed Key Generation), such that each of the at least three genesis blockchain nodes 104 generates a portion of the CA private key 325, and each of the at least three genesis blockchain nodes 104 is not aware of what are the other portions of the CA private key 325. As used herein, the portion of the generated private key may be referred to as “sharded CA private key” 114. Each sharded CA private key 114 is kept secret from every component of system 100 except the blockchain node 104 that generated that portion of the CA private key 325. Sharded CA private keys 114, when combined together, constitute the equivalent of CA private key 325. Each sharded CA private key 114 may be generated based on the Byzantine Fault Tolerance formula of step 302, such that only a “threshold number” of sharded CA private keys 114 are needed in order to issue a signature that is equivalent to a signature using CA private key 325. That is, in order to sign data (e.g., issue a certificate 116), the number genesis nodes 104 that need to sign using their respective sharded CA private keys 114 is the number of genesis blockchain nodes 104 minus “F” from the Byzantine Fault Tolerance formula of step 302. F is the number of genesis blockchain nodes 104 whose failure can be tolerated. F is the number of genesis blockchain nodes 104 whose sharded CA private keys 114 are not needed to issue a signature that is equivalent to signing with CA private key 325. The term “threshold number” of genesis blockchain nodes 104 is the minimum number of genesis blockchain nodes 104 that need to provide partial signatures using their respective sharded CA private keys 114. The combined partial signatures are used to issue a full signature that is equivalent to a signature using CA private key 325. The threshold number may be represented by the following formula:
Threshold number=number of genesis nodes−F”. (Fig. 3A, Fig. 3B, ¶39-¶42). “At step 308, distributed CA 102 issues a certificate 116 for each genesis node 104. As is known in the art, certificate 116, also known as a public key certificate, a digital certificate, or an identity certificate, is an electronic document used to prove the ownership of a public key of a private-public key pair 120, 320. The certificate may include information about the public key, information (e.g., identifier) about the identity of the owner of the public key, and a digital signature of the certificate issuer (e.g., distributed CA 102) that has verified the certificate's contents”. (¶47). Ramachandran teaches, “As shown, the system 10 comprises three components: a generator 20, a controller 40, and an injector 60. In many embodiments, each component is a separate machine and may be physically separate from the other components. In some embodiments, however, two or more components may be integrated into a single machine. Each node 2 may have its own unique instance of each component, or multiple nodes 2 may share one or more components between themselves. an injector 60 is installed at each node 2, a single controller 40 is associated with all nodes 2 operated by a single business unit of a participant in the blockchain network, and a single generator 20 services all controllers 40 associated with the business units of a single participant. Optionally, multiple business units may share one controller 40, or multiple participants (e.g. businesses) may share one generator 20. This architecture may have numerous advantages. For instance, as further described below, this architecture allows the system 10 to continue to substantially function even if a controller 40 or a generator 20 becomes unavailable. In such an instance, the injectors 60 may continue to function using the encryption information already stored in memory, the only limitation being that the injectors 60 may not be able to obtain new encryption information while the controller 40 or generator 20 is down. This architecture also allows for certain functions to be segregated, which may provide enhanced security. For instance, the generator 20 may be segregated so that it may be accessed by only controllers 40. This arrangement therefore adds a layer of security to limit access to the functions of the generator 20, which generates the secure encryption keys. Additionally, the injectors 60 may be segregated so that only they receive client communications (messages inbound and outbound from the blockchain node). Thus, the client communications never have access to the controller 40 or the generator 20”. (Fig. 2, ¶41-¶43). “The generator 20 generates encryption keys that the system 10 uses to encrypt the data stored on the blockchain. The generator 20 is communicatively coupled 30 to the controller 40 and includes a processor 22 and a seeder 24. The generator 20 may also include a key sharing module 26, and in some embodiments it optionally includes a memory 28 and an authorization module 34. FIG. 3 provides a block diagram of some components of the generator 20. The generator 20 is configured to be compatible with the specific encryption protocol used by the system 10, In an exemplary embodiment, the system 10 uses the Advanced Encryption Standard (“AES”) protocol. See, e.g., National Institute of Standards and Technology, Specification for the Advanced Encryption Standard (“FIPS PUB 197,” 2001), available at https://nvlpubs.nist.gov/nistpubs/fips/nist.fips.197.pdf (last visited Apr. 30, 2018). The AES protocol, and encryption protocols generally, are understood by persons having ordinary skill in the art and are not described in greater detail. In a preferred embodiment of the system using the AES protocol, the generator 20 is configured to generate AES-256 encryption keys. But in other embodiments, the generator 20 may be configured to generate a different size of encryption key that is compatible with the AES protocol. Likewise, the system 10 may employ other encryption protocols, and in such embodiments the generator 20 is configured to generate encryption keys compatible with such encryption protocol. Examples of other suitable encryption techniques and protocols include lattice-based cryptography, code-based cryptography, and multivariate cryptography, which may be more resistant to quantum computing. Other cryptography techniques may also be used too, including the RSA algorithm or elliptic-curve cryptography”. (¶46-¶47). “Once the new encryption key is generated (or after a previously generated encryption key is identified), the generator 20 transmits encryption information to the controller 40. In some embodiments, the encryption information is the encryption key itself. But in a preferred embodiment, the encryption information is not the encryption key itself but rather information based on the encryption key, such as portions of the encryption key or information derived from the encryption key (like the key shares discussed next). Advantageously, the generator 20 may include a key sharing module 26 that generates the encryption information that is shared with the controller 40. In a preferred embodiment, the key sharing module 26 uses Shamir's Secret Sharing Algorithm to generate “key shares” based on the encryption key, but other key sharing algorithms may be used to generate the key shares. In general terms, a key sharing algorithm derives n pieces of information from the encryption key, which are the key shares. The key shares are configured such that, if an entity knows or possess at least k of the key shares, it may use the key shares to assemble the encryption key, which may in turn be used to encrypt or decrypt data. But if an entity has k−1 (or fewer) key shares, it cannot assemble the encryption key nor may it encrypt or decrypt any data Shamir's Secret Sharing Algorithm, or a similar approach, is thus advantageous because no entity must possess the entire encryption key, an outsider cannot simply hack one message to obtain the information required to decrypt data, and the confidentiality of data is not compromised even if one or more (but less than k) key shares become compromised. Likewise, the key shares may be distributed to the injectors 60 so that the injectors 60 must cooperate to assemble an encryption key from the key shares before encrypted data may be injected into the blockchain. Both n and k are integers that may be dynamically set, and k must be less than or equal to n. In some embodiments, n and k are parameters that are included in the New Key Command. Of course, other embodiments may use other key sharing algorithms or protocols to protect the encryption key, and those other techniques may provide some benefits similar to those discussed above. For instance, Blakeley's sharing algorithm may be used”. (¶58-¶59). Thus Ramchandran teaches a generator (key broker) generating a key and splitting the key into number of shares. Hence a person having an ordinary skill in the art would have combined the teachings of Ramchandran with the teachings of Venable to teach the limitations, “generate a secret key based on the request;
generate the root certificate based on the secret key;
split the secret key into a plurality of shards;
provide a first shard of the plurality of shards to an agent”; The motivation/suggestion for doing is that a malicious user cannot issue or hijack a certificate.
Applicant’s remark, filed on December 29, 2025 on bottom of page 9 regarding, “Ramachandran does not solve the deficiencies of Venable. Thus, the cited references, either alone or combination, do not teach or suggest, a key broker configured to "generate a secret key based on the request; generate the root certificate based on the secret key; split the secret key into a plurality of shards; provide a first shard of the plurality of shards to an agent," as recited in claim 1 has been considered and addressed in above paragraph 11.
Applicant further recites similar remarks as listed above for dependent claims, 2-7, 9-14 and 16-20. Please see response for remarks in above paragraph 11 that clearly shows how the cited prior arts Venable, Ramchandran and Hoogh clearly teaches the claimed limitations.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-2, 7-9, 14-16 and 19-20 are rejected under 35 U.S.C. 103 as being unpatentable over Jeffrey C. Venable, Sr. (US PGPUB. # US 2021/0083882, hereinafter “Venable”), and further in view of Ramachandran et al. (US PGPUB. # US 2018/0316492, hereinafter “Ramachandran”).
Referring to Claims 1, 8 and 15:
Regarding Claim 1, Venable teaches,
A system comprising:
a processor; (¶94) and
a non-transitory machine-readable storage medium that provides instructions that, when executed by the processor, causes a key broker to: (¶94, Claim 8)
receive a request for a root certificate; (Fig. 3A, ¶29, “The distributed CA 102 created by the method 300 may be referred to as a “genesis” distributed CA 102”, i.e. Examiner submits that genesis is interpreted a root certificate and a root certificate is created indicates that a request was received)
generate a secret key based on the request; (Fig. 3A (306), ¶39, “CA private-public key pair 320 is for the distributed CA 102 as a whole. Step 306 is described with reference to FIG. 3B”, Fig. 3B, ¶40-¶42, i.e. a private key (secret key) is generated)
generate the root certificate based on the secret key; (Fig. 3A (308), ¶47, “distributed CA 102 issues a certificate 116 for each genesis node 104”, i.e. certificate is issued indicates that the certificate is generated and issued)
split the secret key into a plurality of shards; (Fig. 3A (306), Fig. 3B, ¶39- ¶41, “As used herein, the portion of the generated private key may be referred to as “sharded CA private key” 114. Each sharded CA private key 114 is kept secret from every component of system 100 except the blockchain node 104 that generated that portion of the CA private key 325”, ¶42)
provide a first shard of the plurality of shards to an agent; (Fig. 3B, ¶41, i.e. first shard of plurality of shards is provided to first blockchain node (agent))
receive a partially signed client certificate signed with the first shard; (Fig. 4(406, 408), ¶61, i.e. partially signed client certificate, signed with the first shard is received)
generate a fully signed client certificate based on the partially signed client certificate and a second shard of the plurality of shards; (Fig. 4(408, 412), ¶62, “combiner compares the partial signatures collected to the threshold number, and the combiner determines whether enough partial signatures have been collected to issue a full signature”, “If the number of partial signatures collected satisfies the threshold number”, ¶63, i.e. fully signed certificate is generated) and
issue the fully signed client certificate. (Fig. 4(412), ¶64, “At step 412, the distributed CA 102 issues a certificate 116 to entity 122”, i.e. fully signed certificate is issued).
Venable does not teach explicitly,
delete the first shard at the key broker;
However, Ramachandran teaches,
delete the first shard at the key broker; (¶77, “deletes the key shares or other encryption information after transmitting it to the respective injectors”, i.e. first shard is deleted at the controller (broker)).
As per KSR vs Teleflex, combining prior art elements according to known methods (device, product) to yield predictable results may be used to create a prima facie case of obviousness.
It would have been obvious to one of ordinary skill in the art before the effective filing date to have combined the teachings of Ramachandran with the invention of Venable.
Venable teaches, generating public-private key and a root certificate and splitting the private key in multiple shares. Ramachandran teaches, distributing key shares to different injectors and deleting the key shares at the controller. Therefore, it would have been obvious to have distributing key shares to different injectors and deleting the key shares at the controller of Ramachandran with generating public-private key and a root certificate and splitting the private key in multiple shares of Venable so a malicious user cannot issue or hijack a certificate.
KSR Int’l v. Teleflex Inc., 127 S. Ct. 1727, 1740-41, 82 USPQ2d 1385, 1396 (2007).
Regarding Claim 8, it is a method claim of above system claim 1 and therefore Claim 8 is rejected with the same rationale as applied against Claim 1 above.
Venable teaches,
receiving, at the key broker, a partially signed message signed with the first shard; generating, at the key broker, a fully signed message based on the partially signed message and a second shard of the plurality of shards; and issuing the fully signed message. (¶48-¶50, Fig. 4(408), ¶62, “the combiner compares the partial signatures collected to the threshold number, and the combiner determines whether enough partial signatures have been collected to issue a full signature”).
Regarding Claim 15, it is a memory device claim of above system claim 1 and therefore Claim 15 is rejected with the same rationale as applied against Claim 1 above.
Venable teaches,
receiving, at the key broker, a partially signed message signed with the first shard; generating, at the key broker, a fully signed message based on the partially signed message and a second shard of the plurality of shards; and issuing the fully signed message. (¶48-¶50, Fig. 4(408), ¶62, “the combiner compares the partial signatures collected to the threshold number, and the combiner determines whether enough partial signatures have been collected to issue a full signature”).
Referring to Claims 2, 9 and 16:
Regarding Claim 2 rejection of Claim 1 is included and for the same motivation Venable teaches,
The system of claim 1, wherein the instructions further cause the processor to:
generate a key pair including the secret key and a public key; (¶12, ¶21, ¶33, i.e. private key (secret key) and public key are created) and
generate the root certificate to include the public key. (¶21, Fig. 3A, ¶29, “The distributed CA 102 created by the method 300 may be referred to as a “genesis” distributed CA 102”, i.e. Examiner submits that genesis is interpreted a root certificate and a root certificate is created).
Regarding Claim 9 rejection of Claim 8 is included Claim 9 is rejected with the same rationale as applied against Claim 2 above.
Regarding Claim 16 rejection of Claim 15 is included Claim 16 is rejected with the same rationale as applied against Claim 2 above.
Referring to Claims 7 and 20:
Regarding Claim 7 rejection of Claim 2 is included and for the same motivation Venable teaches,
The system of claim 2, wherein the instructions further cause the processor to:
receive the partially signed client certificate from the agent operating within a domain of a target resource; (Fig. 4(406, 408), ¶61, i.e. partially signed client certificate, signed with the first shard is received) and
issue the fully signed client certificate to a client system seeking access to the target resource. (¶60, Fig. 4(412), ¶64, “At step 412, the distributed CA 102 issues a certificate 116 to entity 122”, i.e. fully signed certificate is issued).
Regarding Claim 20 rejection of Claim 15 is included Claim 20 is rejected with the same rationale as applied against Claim 7 above.
Referring to Claims 14 and 19:
Regarding Claim 14 rejection of Claim 8 is included and for the same motivation Venable teaches,
The method of claim 8, further comprising:
the partially signed message includes a partially signed client certificate for a client system seeking access to a target resource; (¶60, “Contents of the CSR may be at least in part based on whether the entity 122 is applying to join as a device 112 or as a blockchain node 104”, i.e. client system seeking access to a target resource)
receiving the partially signed client certificate from the agent operating within a domain of the target resource; (Fig. 4(406, 408), ¶61, i.e. partially signed client certificate, signed with the first shard is received) and
issuing the fully signed message to the agent. (Fig. 4(412), ¶64, “At step 412, the distributed CA 102 issues a certificate 116 to entity 122”, ¶84, i.e. fully signed certificate is issued).
Regarding Claim 19 rejection of Claim 15 is included Claim 19 is rejected with the same rationale as applied against Claim 14 above.
Claims 3-6, 10-13 and 17-18 are rejected under 35 U.S.C. 103 as being unpatentable over Jeffrey C. Venable, Sr. (US PGPUB. # US 2021/0083882, hereinafter “Venable”), and further in view of Ramachandran et al. (US PGPUB. # US 2018/0316492, hereinafter “Ramachandran”), and further in view of de Hoogh et al. (EP PUB. # EP 3496331, hereinafter “Hoogh”).
Referring to Claims 3 and 10:
Regarding Claim 3 rejection of Claim 2 is included and combination of Venable and Ramachandran does not teach explicitly,
The system of claim 2, wherein the instructions further cause the processor to:
split the secret key based on a multiplicative algorithm.
However, Hoogh teaches,
The system of claim 2, wherein the instructions further cause the processor to:
split the secret key based on a multiplicative algorithm. (¶2, “both multiplicative and additive ways to split an RSA key into multiple shares”, ¶4).
As per KSR vs Teleflex, combining prior art elements according to known methods (device, product) to yield predictable results may be used to create a prima facie case of obviousness.
It would have been obvious to one of ordinary skill in the art before the effective filing date to have combined the teachings of Hoogh with the invention of Venable in view of Ramachandran.
Venable in view of Ramachandran teaches, generating public-private key and a root certificate and splitting the private key in multiple shares and distributing key shares to different injectors and deleting the key shares at the controller. Hoogh teaches, splitting a secret key according to a multiplicative algorithm. Therefore, it would have been obvious to have splitting a secret key according to a multiplicative algorithm of Hoogh into the teachings of Venable in view of Ramachandran to provide secure signing and key generation phase which is also secured against memory scraping.
KSR Int’l v. Teleflex Inc., 127 S. Ct. 1727, 1740-41, 82 USPQ2d 1385, 1396 (2007).
Regarding Claim 10 rejection of Claim 8 is included Claim 10 is rejected with the same rationale as applied against Claim 3 above.
Referring to Claims 4 and 11:
Regarding Claim 4 rejection of Claim 3 is included and for the same motivation Venable teaches,
The system of claim 3, wherein the instructions further cause the processor to:
generate the fully signed client certificate (Fig. 4(412), ¶64, “At step 412, the distributed CA 102 issues a certificate 116 to entity 122”, i.e. fully signed certificate is issued) [using a multiplicative signing algorithm], including:
perform signing of a client certificate in a sequential order with the agent, includes applying signatures to the client certificate in a set order corresponding to the plurality of shards; (Fig. 4(406, 408), ¶61, i.e. partially signed client certificate, signed with the first shard) and
sign the partially signed client certificate using the second shard. (Fig. 4(408, 412), ¶62, “combiner compares the partial signatures collected to the threshold number, and the combiner determines whether enough partial signatures have been collected to issue a full signature”, “ If the number of partial signatures collected satisfies the threshold number”, ¶63, i.e. fully signed certificate is generated).
Combination of Venable and Ramachandran does not teach explicitly,
[generate the fully signed client certificate] using a multiplicative signing algorithm;
However, Hoogh teaches,
[generate the fully signed client certificate] using a multiplicative signing algorithm; (¶2, “both multiplicative and additive ways to split an RSA key into multiple shares”, ¶4).
Regarding Claim 11 rejection of Claim 10 is included Claim 11 is rejected with the same rationale as applied against Claim 4 above.
Regarding Claim 17 rejection of Claim 15 is included and Venable teaches,
The memory device of claim 15, storing instructions that, when executed, cause the processor to perform the method further comprising:
splitting the secret key based on a multiplicative algorithm; and
generating the fully signed message (Fig. 4(412), ¶64, “At step 412, the distributed CA 102 issues a certificate 116 to entity 122”, i.e. fully signed certificate is issued) [using a multiplicative signing algorithm], including:
performing signing of a message in a sequential order with the agent, includes applying signatures to the message in a set order corresponding to the plurality of shards; (Fig. 4(406, 408), ¶61, i.e. partially signed client certificate, signed with the first shard) and
signing the partially signed message at the key broker using the second shard. (Fig. 4(408, 412), ¶62, “combiner compares the partial signatures collected to the threshold number, and the combiner determines whether enough partial signatures have been collected to issue a full signature”, “ If the number of partial signatures collected satisfies the threshold number”, ¶63, i.e. fully signed certificate is generated).
Combination of Venable and Ramachandran does not teach explicitly,
splitting the secret key based on a multiplicative algorithm; and
[generating the fully signed message] using a multiplicative signing algorithm,
However, Hoogh teaches,
splitting the secret key based on a multiplicative algorithm; and (¶2, “both multiplicative and additive ways to split an RSA key into multiple shares”, ¶4)
[generating the fully signed message] using a multiplicative signing algorithm, (¶2, “both multiplicative and additive ways to split an RSA key into multiple shares”, ¶4).
As per KSR vs Teleflex, combining prior art elements according to known methods (device, product) to yield predictable results may be used to create a prima facie case of obviousness.
It would have been obvious to one of ordinary skill in the art before the effective filing date to have combined the teachings of Hoogh with the invention of Venable in view of Ramachandran.
Venable in view of Ramachandran teaches, generating public-private key and a root certificate and splitting the private key in multiple shares and distributing key shares to different injectors and deleting the key shares at the controller. Hoogh teaches, splitting a secret key according to a multiplicative algorithm. Therefore, it would have been obvious to have splitting a secret key according to a multiplicative algorithm of Hoogh into the teachings of Venable in view of Ramachandran to provide secure signing and key generation phase which is also secured against memory scraping.
KSR Int’l v. Teleflex Inc., 127 S. Ct. 1727, 1740-41, 82 USPQ2d 1385, 1396 (2007).
Referring to Claims 5 and 12:
Regarding Claim 5 rejection of Claim 2 is included and combination of Venable and Ramachandran does not teach explicitly,
The system of claim 2, wherein the instructions further cause the processor to:
split the secret key based on an additive algorithm.
However, Hoogh teaches,
The system of claim 2, wherein the instructions further cause the processor to:
split the secret key based on an additive algorithm. (¶2, “both multiplicative and additive ways to split an RSA key into multiple shares”, ¶4).
As per KSR vs Teleflex, combining prior art elements according to known methods (device, product) to yield predictable results may be used to create a prima facie case of obviousness.
It would have been obvious to one of ordinary skill in the art before the effective filing date to have combined the teachings of Hoogh with the invention of Venable in view of Ramachandran.
Venable in view of Ramachandran teaches, generating public-private key and a root certificate and splitting the private key in multiple shares and distributing key shares to different injectors and deleting the key shares at the controller. Hoogh teaches, splitting a secret key according to a multiplicative algorithm. Therefore, it would have been obvious to have splitting a secret key according to a multiplicative algorithm of Hoogh into the teachings of Venable in view of Ramachandran to provide secure signing and key generation phase which is also secured against memory scraping.
KSR Int’l v. Teleflex Inc., 127 S. Ct. 1727, 1740-41, 82 USPQ2d 1385, 1396 (2007).
Regarding Claim 12 rejection of Claim 8 is included Claim 12 is rejected with the same rationale as applied against Claim 5 above.
Referring to Claims 6 and 13:
Regarding Claim 6 rejection of Claim 5 is included and for the same motivation Venable teaches,
The system of claim 5, wherein the instructions further cause the processor to:
generate the fully signed client certificate (Fig. 4(412), ¶64, “At step 412, the distributed CA 102 issues a certificate 116 to entity 122”, i.e. fully signed certificate is issued) [using an additive signing algorithm], including:
perform signing of a client certificate by multiple parties individually, wherein: each party signs an unsigned copy of the client certificate using a corresponding one of the plurality of shards; (Fig. 4(406, 408), ¶61, i.e. partially signed client certificate, signed with the first shard)
a final party combines each individually signed client certificate; (Fig. 4(408, 412), ¶62, “combiner compares the partial signatures collected to the threshold number, and the combiner determines whether enough partial signatures have been collected to issue a full signature”, i.e. combiner is interpreted as a final party) and
sign a copy of the client certificate at the key broker using the second shard. (Fig. 4(408, 412), ¶62, “combiner compares the partial signatures collected to the threshold number, and the combiner determines whether enough partial signatures have been collected to issue a full signature”, “ If the number of partial signatures collected satisfies the threshold number”, ¶63, i.e. fully signed certificate is generated).
Combination of Venable and Ramachandran does not teach explicitly,
[generate the fully signed client certificate] using an additive signing algorithm,
However, Hoogh teaches,
[generate the fully signed client certificate] using an additive signing algorithm, (¶2, “both multiplicative and additive ways to split an RSA key into multiple shares”, ¶4).
Regarding Claim 13 rejection of Claim 12 is included Claim 13 is rejected with the same rationale as applied against Claim 6 above.
Regarding Claim 18 rejection of Claim 15 is included and Venable teaches,
The memory device of claim 15, storing instructions that, when executed, cause the processor to perform the method further comprising:
generating the fully signed message (Fig. 4(412), ¶64, “At step 412, the distributed CA 102 issues a certificate 116 to entity 122”, i.e. fully signed certificate is issued) [using an additive signing algorithm], including:
performing signing of a message by multiple parties individually, wherein: each party signs an unsigned copy of the message using a corresponding one of the plurality of shards; (Fig. 4(406, 408), ¶61, i.e. partially signed client certificate, signed with the first shard)
a final party combines each individually signed message; and signing a copy of the message at the key broker using the second shard. (Fig. 4(408, 412), ¶62, “combiner compares the partial signatures collected to the threshold number, and the combiner determines whether enough partial signatures have been collected to issue a full signature”, i.e. combiner is interpreted as a final party).
Combination of Venable and Ramachandran does not teach explicitly,
splitting the secret key based on an additive algorithm; and
[generating the fully signed message] using an additive signing algorithm,
However, Hoogh teaches,
splitting the secret key based on an additive algorithm; and (¶2, “both multiplicative and additive ways to split an RSA key into multiple shares”, ¶4)
[generating the fully signed message] using an additive signing algorithm, (¶2, “both multiplicative and additive ways to split an RSA key into multiple shares”, ¶4).
As per KSR vs Teleflex, combining prior art elements according to known methods (device, product) to yield predictable results may be used to create a prima facie case of obviousness.
It would have been obvious to one of ordinary skill in the art before the effective filing date to have combined the teachings of Hoogh with the invention of Venable in view of Ramachandran.
Venable in view of Ramachandran teaches, generating public-private key and a root certificate and splitting the private key in multiple shares and distributing key shares to different injectors and deleting the key shares at the controller. Hoogh teaches, splitting a secret key according to a multiplicative algorithm. Therefore, it would have been obvious to have splitting a secret key according to a multiplicative algorithm of Hoogh into the teachings of Venable in view of Ramachandran to provide secure signing and key generation phase which is also secured against memory scraping.
KSR Int’l v. Teleflex Inc., 127 S. Ct. 1727, 1740-41, 82 USPQ2d 1385, 1396 (2007).
Conclusion
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Refer to PTO-892, Notice of References Cited for a listing of analogous art.
Hess et al. (US # 2024/0356909) discloses, a method of signing messages using public key cryptography and certificate verification. The method includes generating a digital certificate based on a signed request. The method includes causing the digital certificate to be stored in a shared data storage available to a first client device. The method includes signing a message using a first private key associated with the first client device to generate a signed message. The first private key is inaccessible to the first client device.
Peddada et al. (US # 2023/0130121) discloses, In response to a key generation request from a client application, a security controller generates a cryptographic key pair and splits the private key portion into a first fragment and a second fragment. The first fragment, but not the second fragment, is encrypted using a symmetric wrapping key that is accessible to the security controller but not the client application. A key package with the encrypted first fragment is returned to the client application. When the client application needs to digitally sign a data value with the split private key, the client application generates a first partial Multiparty Computation (MPC) signature using the second fragment. The security controller generates a second partial MPC signature with the first fragment, which has been decrypted using the symmetric wrapping key. The first and second partial MPC signatures are combinable to digitally sign the data value.
Tysor et al. (US # 2021/0105138) discloses, tokenizing, at a first device, a search query; creating search requests and send to delegate devices, each search request including a public key encrypted message containing the tokenized search query and index identifiers of indices to be searched; computing search responses to the search requests, each search response comprising a partial trapdoor computed per token per identifier; transmitting the search responses to the first device; recombining, at the first device, the search responses per identifier per token; performing a ranked set of queries against the indices; and returning the search results in order of relevancy.
Wainblat et al. (US # 2020/0213135) discloses, a system for securing a process of manufacturing an article, comprising a facility security node located in a manufacturing facility where the article is manufactured, a security server located remotely from the manufacturing facility, said security server communicates with the facility security node and comprises a key generation module configured to generate a certificate authority (CA) private key in a split manner, one share of the CA private key is stored at the security server and another share of the CA private key is stored at the manufacturing facility. The server also comprises a server Multi-Party Computation (MPC) module configured to perform an MPC process with an article MPC module stored at the article, the output of the MPC process is signing the certificate without reconstructing the entire CA private key.
Ranellucci et al. (US # 2020/0153640) discloses, a method for signing a message, comprising performing a first Multi-Party Computation (MPC) process by multiple parties to compute a pseudorandom function, an input of the first MPC process comprises shares of a private signing key, each share is held by each party, the message is an input value to the pseudorandom function. The output of the first MPC process comprises multiple pairs of shares, each party holding a pair of shares, wherein each pair comprises a first value used for the MPC signing process and a second verifying value used for verifying correctness of the values provided by the multiple parties for the MPC signing process, and computing the signature on the message by performing an MPC signing protocol on the message, the MPC signing protocol receives as input shares of the output of the pseudorandom function from the multiple parties, and the message to be signed.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to DARSHAN I DHRUV whose telephone number is (571)272-4316. The examiner can normally be reached M-F 9:00 AM-5: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, Yin-Chen Shaw can be reached at 571-272-8878. 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.
/DARSHAN I DHRUV/Primary Examiner, Art Unit 2498