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 .
Claims 1-16, 18, 19, 31, and 32 are pending.
Priority
Acknowledgment is made of applicant’s claim for foreign priority under 35 U.S.C. 119 (a)-(d). The certified copy has been filed in parent Application No. 18/718,351, filed on December 17, 2021.
Claim Objections
Claims 11-13 are objected to because of the recitations of "second identify certificate" should be changed to "second identity certificate". Appropriate correction is required.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
Claims 1-16, 18, 19, 31, and 32 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claims 1, 7, 13, 15, 31, and 32 recite the feature “verifying that the zero knowledge proof is valid using the proof” which lacks antecedent basis. The terms “the proof” are interpreted as “the zero knowledge proof” for examination purposes. Claims 2-6, 8-12, 14, 16, 18, and 19 depend on claims 1 and 15 which means they inherit this rejection.
Claim 8 recites the feature “the parent key is a certified parent public key.” This claim depends on claim 6 which depends on claim 4 and claim 4 recites “the parent key is a private parent key.” This renders the claim ambiguous. Claims 9 and 10 depend on claim 8 therefore they inherit this rejection.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-16, 18, 19, 31, and 32 are rejected under 35 U.S.C. 101 under the 2019 PEG framework. The claim recites a judicial exception (an abstract idea falling within the “methods of organizing human activity” and “data analysis” groupings) that is not integrated into a practical application
Step 1: Statutory Category. Claims 1-16, 18, 19, 31, and 32 satisfy the statutory category requirement because they are directed to a “method” or “process” under 35 U.S.C. § 101(a). The claim recites a series of steps implemented with a computer that include obtaining a child key, receiving proof, validating the proof, and authenticating the key.
Step 2A, Prong 1: Identification of Judicial Exception. Claims 1, 15, 31, and 32 recites multiple judicial exceptions within the abstract idea category. First, the claim recites a process for authenticating a child public key: "obtaining the child public key," "receiving a zero-knowledge proof from a proving computing device," "verifying that the zero knowledge proof is valid…", and "determining the authenticity of the child key" constitute mental processes and data manipulation that could be performed in the human mind. Second, the claims recite obtaining keys and validating them which can be done through mathematical processes.
Step 2A, Prong 2: Integration into a Practical Application. Claims 1, 15, 31, and 32 fail integration analysis. The claims do not recite any specific technological improvement to computer functionality-no reduction in latency, improvement in detection accuracy, or optimization of memory utilization. The claims merely describe steps for obtaining keys, validating a zero-knowledge proof, and validating the key but does not describe the model's innovation or technological contribution, which is insufficient under Alice and Mayo. The claims recite that the method is performed on a computing device, but this is generic computer language; there is no claim to specialized hardware, FPGA, ASIC, or particular machine architecture. Per Alice, 537 U.S. at 221, merely implementing an abstract idea on a generic computer does not confer eligibility. The claims do not transform a tangible article into a different state or thing; data manipulation alone is not transformation. Per Bilski, 561 U.S. at 618 and PEG p. 56, transformation requires a change in physical properties or state of a tangible article.
Step 2B: Significantly More / WURC Analysis. The additional element, computing device, is well-understood, routine, and conventional (WURC) in the field of cybersecurity and application security testing as of the priority date of December 17, 2021. The specification provides no factual evidence demonstrating that these elements, individually or in combination, represent a non-conventional or inventive approach. Under Berkheimer v. HP, Inc., 881 F.3d 1360 (Fed. Cir. 2018), the examiner would need to establish a factual record that these elements are not WURC, and no such record exists. Therefore, the claims fail Step 2B as well.
Claims 2-14, 16, 18, and 19 recite limitations similar to those in claims 1 and 15, therefore they are similarly analyzed.
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claim(s) 1-4, 15, 16, 18, 31, and 32 is/are rejected under 35 U.S.C. 102(a)(2) as being anticipated by Ben-Reuven (US 20220278853 A1, hereinafter referred to as Ben-Reuven).
Regarding claim 1, Ben-Reuven discloses: A computer implemented method of verifying an authenticity of a child public key that is associated with an entity (Ben-Reuven: Paragraph [0212] states, "each influencer can compute the public key for the child and sign the new public key in addition to signing his own address using the parent private key. The converter supplies the signatures and the contract validates the first signature in the path using the stored public key used by the contractor. The contract then extracts from the signature the public address of the next step and uses it to validate the next signature and so on."), the method performed on a computing device and comprising: obtaining the child public key (Ben-Reuven: Paragraph [0212] states, "each influencer can compute the public key for the child and sign the new public key in addition to signing his own address using the parent private key. The converter supplies the signatures and the contract validates the first signature in the path using the stored public key used by the contractor. The contract then extracts from the signature the public address of the next step and uses it to validate the next signature and so on."); receiving a zero knowledge proof from a proving computing device (Ben-Reuven: Paragraph [0086] states, "a cryptographic signature or proof can be computed. In certain implementations, such a proof/signature can be, for example, a signature of the second public key (e.g., public key 214B as generated or retrieved at operation 320) and various parameter(s) associated with the second user (such as its address, e.g. on Ethereum, its weight, etc.). Additionally, in certain implementations such a proof/signature can be computed, for example, using the first secret/private key (e.g., secret/private key 216A, as received within link 250A at operation 310). In certain implementations, such a proof can be a zero-knowledge cryptographic proof, e.g., a proof that the second user (e.g., user 230B) received, knew, or otherwise had access to the first secret/private key (e.g., secret 216A)."); verifying that the zero knowledge proof is valid using the proof, the child public key, and a verification key, to determine that a key derivation protocol has been used to derive the child public key from a parent key (Ben-Reuven: Paragraph [0212] states, "each influencer can compute the public key for the child and sign the new public key in addition to signing his own address using the parent private key. The converter supplies the signatures and the contract validates the first signature in the path using the stored public key used by the contractor. The contract then extracts from the signature the public address of the next step and uses it to validate the next signature and so on." Paragraph [0214] states, "the signature done in every step can be repeated using the private key used by the user (contractor, influencer or converter) to interact with Ethereum. This signature proves that the user was the person who created the first signature that is based on the secret passed in the link. The converter can pass the additional signatures to the contract and the contract can validate the additional signatures and only then allow the purchase to happen."); and determining the authenticity of the child public key based on said verifying (Ben-Reuven: Paragraph [0212] states, "each influencer can compute the public key for the child and sign the new public key in addition to signing his own address using the parent private key. The converter supplies the signatures and the contract validates the first signature in the path using the stored public key used by the contractor. The contract then extracts from the signature the public address of the next step and uses it to validate the next signature and so on.").
Regarding claim 2, Ben-Reuven discloses: The computer implemented method of claim 1, wherein obtaining the child public key comprises receiving the child public key from the proving computing device (Ben-Reuven: Paragraph [0057] states, "upon accessing link 250A via a web browser, dApp 212 can execute on device 210B, as described herein." Paragraph [0086] states, "a proof/signature can be computed, for example, using the first secret/private key (e.g., secret/private key 216A, as received within link 250A at operation 310)." Paragraph [0212] states, "each influencer can compute the public key for the child and sign the new public key in addition to signing his own address using the parent private key.").
Regarding claim 3, Ben-Reuven discloses: The computer implemented method of claim 1, wherein the method comprises: transmitting a request to the proving computer device for a proof that the child public key is authentic (Ben-Reuven: Paragraph [0134] states, "a contract initiation request is received, e.g., from a first user. For example, as shown in FIG. 2A, user 230A can utilize device 210A to activate dApp 212 and interface with service 220 in order to initiate a contract. Such a contract initiation request can include various parameter(s) associated with the contract (e.g., the type of contract, length of time, maximum number of influencers, bounty, etc.), as described in detail herein. Additionally, the referenced contract initiation request (e.g., as received by service 220 from device 210A) can also include identifying parameter(s) associated with the first user, such as an address (e.g. on Ethereum) of the first user and/or a public key associated with the first user." Paragraph [0212] states, "each influencer can compute the public key for the child and sign the new public key in addition to signing his own address using the parent private key. The converter supplies the signatures and the contract validates the first signature in the path using the stored public key used by the contractor. The contract then extracts from the signature the public address of the next step and uses it to validate the next signature and so on."); wherein the zero knowledge proof is received in response to the request (Ben-Reuven: Paragraph [0055] states, "A link 250A can be generated which includes contract address 252 (e.g., the address of the smart contract on the blockchain, an Ethereum address, and/or an address at which service 220 maintains the details, parameters, etc. of the contract, campaign, etc.) and secret/private key 216A. User 230A can then disseminate link 250A (e.g., via social media, email, etc.). Additionally, in certain implementations the referenced first link further can also include a zero-knowledge cryptographic proof.").
Regarding claim 4, Ben-Reuven discloses: The computer implemented method of claim 1, wherein the parent key is a private parent key and the child public key is a hardened child public key (Ben-Reuven: Paragraph [0212] states, "each influencer can compute the public key for the child and sign the new public key in addition to signing his own address using the parent private key.").
Claims 15, 31, and 32 recite features similar to those in claim 1, therefore they are rejected in a similar manner.
Regarding claim 16, Ben-Reuven discloses: The computer implemented method of claim 15, wherein the parent key was generated using a first portion of a hash function output and the method comprises generating the zero knowledge proof using a remaining portion of the hash function output (Ben-Reuven: Paragraph [0237] states, "to enable the described aggregated signature, each influencer creates a secret (“f_secret”) and publishes its public key (as “f_public”). The SHA3 hash of the concatenation of new “cut”, new “f_public” and new “f_address” (“h”) can then be computed, as described above. The “sign” as computed up to now (e.g., as received from the previous influencer) can be multiplied with “h{circumflex over ( )}x” to generate a new “sign” (note that the contractor/first-influencer can just assign “sign” to his “h{circumflex over ( )}x”).").
Claim 18 recites features similar to those in claim 4, therefore it is rejected in a similar manner.
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.
Claim(s) 5-10, 19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Ben-Reuven (US 20220278853 A1, hereinafter referred to as Ben-Reuven) in view of Maletsky (US 20140281554 A1, hereinafter referred to as Maletsky).
Regarding claim 5, Ben-Reuven discloses: The computer implemented method of claim 1, but fails to explicitly disclose: wherein the parent key is a parent public key.
However, in the same field of endeavor, Maletsky discloses: wherein the parent key is a parent public key (Maletsky: Paragraph [0162] states, "the host device 330 receives the parent public key 524 and the parent certificate 525 from the client device 310, where the corresponding parent private key 323 is stored in the secure zone 322 of secure device 320.").
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention was made to modify the teaching of Ben-Reuven as modified by Ferenczi and include the above limitation with the teaching of Maletsky since "The host device may want to verify that the information provided by the client device is accurate, while the client device may want to confirm that it is connected to a compatible host device" (Maletsky: Paragraph [0002]).
Regarding claim 6, Ben-Reuven discloses: The computer implemented method of claim 4, but fails to explicitly disclose: further comprising: obtaining a copy of a parent public key corresponding to the private parent key; and verifying that the zero knowledge proof is valid additionally uses the parent public key.
However, Maletsky further discloses: further comprising: obtaining a copy of a parent public key corresponding to the private parent key (Maletsky: Paragraph [0162] states, "the host device 330 receives the parent public key 524 and the parent certificate 525 from the client device 310, where the corresponding parent private key 323 is stored in the secure zone 322 of secure device 320."); and verifying that the zero knowledge proof is valid additionally uses the parent public key (Maletsky: Paragraph [0124] states, "the client device 310 may send the child public key 328 along with a signature on the child public key 328 that is signed with the parent private key 323 to prove its authenticity. The host device 310 can verify the signature on the child public key 328 using the parent public key 324.").
The same motivation to modify with Maletsky, as in claim 5, applies.
Regarding claim 7, the combination of the combination of Ben-Reuven as modified by Maletsky discloses: The computer implemented method of claim 6.
Maletsky further discloses: further comprising: receiving, from the proving computer device, a parent public key used by the proving computer device to generate the proof (Maletsky: Paragraph [0124] states, "the client device 310 may send the child public key 328 along with a signature on the child public key 328 that is signed with the parent private key 323 to prove its authenticity. The host device 310 can verify the signature on the child public key 328 using the parent public key 324." Paragraph [0162] states, "the host device 330 receives the parent public key 524 and the parent certificate 525 from the client device 310, where the corresponding parent private key 323 is stored in the secure zone 322 of secure device 320."); and determining the authenticity of the child public key is further based on if the parent public key used by the proving computer device to generate the proof matches the obtained copy of the parent public key (Maletsky: Paragraph [0174] states, "if the signature computed by the host device 330 using the locally stored parent public key does not match the signature received from the client device 310, then the child public key received from the client device cannot be verified as valid.").
The same motivation to modify with Maletsky, as in claim 5, applies.
Regarding claim 8, the combination of Ben-Reuven as modified by Maletsky discloses: The computer implemented method of claim 6.
Maletsky further discloses: wherein the parent key is a certified parent public key of a signed digital certificate issued by a certificate authority (Maletsky: Paragraph [0105] states, "the vendor performs the role of a trusted Certificate Authority (CA) for all the client devices and host devices that are deployed by the vendor. Distinct parent private keys 323 may be stored in individual client devices 310 by the vendor. For each client device 310, the corresponding parent public key 324, which also may be distinct, is signed by the vendor using the root parent private key and the resulting parent certificate 325 is stored in its predetermined memory slot in the secure zone 322 of the secure device 320 that is embedded in the respective client device 310.").
The same motivation to modify with Maletsky, as in claim 5, applies.
Regarding claim 9, the combination of Ben-Reuven as modified by Maletsky discloses: The computer implemented method of claim 8.
Maletsky further discloses: wherein the signed digital certificate includes a unique identifier of the entity, and verifying that the zero knowledge proof is valid comprises checking that a public unique identifier of the entity matches the unique identifier of the entity in the signed digital certificate (Maletsky: Paragraph [0121] states, "The host device 330 verifies authenticity of the parent public key 324 by verifying the parent certificate 325 using the root public key 336. In this context, verifying the authenticity of the parent public key 324 indicates that the parent public key 324 is verified to be tied to a known identity of the client device 310 based on information included in the parent certificate 325. The parent certificate is signed by the root private key. Since the host device 330 stores the trusted root public key 336, the host device 330 can confirm that the parent certificate 325 is indeed signed by the CA using the root public key 336.").
The same motivation to modify with Maletsky, as in claim 5, applies.
Regarding claim 10, the combination of Ben-Reuven as modified by Maletsky discloses: The computer implemented method of claim 8.
Maletsky further discloses: wherein the signed digital certificate is signed using a private key of the certificate authority and verifying that the zero knowledge proof is valid comprises verifying a signature of the certificate authority using a public key of the certificate authority (Maletsky: Paragraph [0121] states, "The host device 330 verifies authenticity of the parent public key 324 by verifying the parent certificate 325 using the root public key 336. In this context, verifying the authenticity of the parent public key 324 indicates that the parent public key 324 is verified to be tied to a known identity of the client device 310 based on information included in the parent certificate 325. The parent certificate is signed by the root private key. Since the host device 330 stores the trusted root public key 336, the host device 330 can confirm that the parent certificate 325 is indeed signed by the CA using the root public key 336.").
The same motivation to modify with Maletsky, as in claim 5, applies.
Claim 19 recites features similar to those recited in claim 5, therefore it is rejected in a similar manner.
Claim(s) 11-12 is/are rejected under 35 U.S.C. 103 as being unpatentable over Ben-Reuven (US 20220278853 A1, hereinafter referred to as Ben-Reuven) in view of Ezell (US 8312518 B1, hereinafter referred to as Ezell).
Regarding claim 11, Ben-Reuven discloses: The computer implemented method of claim 1, but fails to explicitly disclose: wherein the method comprises: receiving a first identity certificate associated with a signing authority, the first identity certificate comprising a first signature of a certificate authority; receiving a second identify certificate associated with the entity, the second identify certificate comprising a second signature of a signing authority and a message, the message comprising an obfuscated version of the parent key and a unique identifier of the entity; and verifying that the zero knowledge proof is valid additionally uses the message.
However, in the same field of endeavor, Ezell discloses: wherein the method comprises: receiving a first identity certificate associated with a signing authority, the first identity certificate comprising a first signature of a certificate authority (Ezell: Col 6 lines 44-55 states, "The memory 116 of the enterprise server 104 includes first Certificate Authority ("CA") issued sets of certificates 120a-k, a (server-side) authentication module 124, second CA issued set of certificates 128, server application 132, issuing authority (or second CA) 156, and permissions list 160. The first sets of CA issued certificates each include a chain of trust having a root certificate issued by the first CA and a digital certificate digitally signed by the first CA while the second CA issued set of certificates includes a chain of trust having a root certificate issued by the second CA and a digital certificate issued or signed by a second CA (which is different from the first CA)." Examiner's note: the issuing authority is mapped to the signing authority.); receiving a second identify certificate associated with the entity, the second identify certificate comprising a second signature of a signing authority and a message, the message comprising an obfuscated version of the [parent] key and a unique identifier of the entity (Ezell: Col 6 lines 44-55 states, "The memory 116 of the enterprise server 104 includes first Certificate Authority ("CA") issued sets of certificates 120a-k, a (server-side) authentication module 124, second CA issued set of certificates 128, server application 132, issuing authority (or second CA) 156, and permissions list 160. The first sets of CA issued certificates each include a chain of trust having a root certificate issued by the first CA and a digital certificate digitally signed by the first CA while the second CA issued set of certificates includes a chain of trust having a root certificate issued by the second CA and a digital certificate issued or signed by a second CA (which is different from the first CA)." Col 7 lines 55-66 states, "the second certificate information (or second set of credentials) 152 includes an encoded copy of the corresponding client's private key 312. The private key is asymmetrically related to a public key in the client certificate 308. The certificate information 152 is embedded in the code of the client application 148 in a manner that is difficult to compromise. In one configuration, the certificate information 152 is encrypted with a, typically symmetric, key and included in the code. The symmetric key, which may be the symmetric key used to encrypt the private key 312, is obfuscated in the code." Examiner's note: the issuing authority is mapped to the signing authority.); and verifying that the zero knowledge proof is valid additionally uses the message (Ezell: Col 9 lines 30-36 states, "the authentication module 124 and/or server application 124 in the server 104 validates that the client certificate 308 was signed by the issuing authority 156, the client's identity is or is not on the permissions list 160, the timestamp is relatively close to the nonce value is one sent by the server 104, and the signature on the message is valid.").
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention was made to modify the teaching of Ben-Reuven and include the above limitation with the teaching of Ezell in order to establish "an island of trust using credentials issued by a manufacturer or service provider and protecting the credentials by embedding them in application code" (Ezell: abstract).
Ezell fails to explicitly disclose: parent key.
However, Ben-Reuven discloses: parent key (Ben-Reuven: Paragraph [0134] states, "The signature can be generated with the parent private key extracted from the link.").
Regarding claim 12, the combination of Ben-Reuven as modified by Ezell discloses: The computer implemented method of claim 11.
Ezell further discloses: wherein determining the authenticity of the child public key is further based on: verifying an integrity of the [obfuscated version of the parent] key [in the second identify certificate] by verifying the first signature using a public key of the certificate authority and verifying the second signature using a public key of the signing authority (Ezell: Col 5 lines 24-28 states, "A digital signature is commonly encrypted with a private or secret key. The recipient decrypts the signature with the corresponding public key to verify that the digital signatory has the correct private key." Col 8 lines 4-10 states, "the root CA and/or issuing authority certificates 300 and 304 may be encrypted and embedded in a like manner in the code of the server application 132. The integrity and security of the certificates can thus be maintained. These certificates are used to verify that the client certificate 308 proffered by a given client was properly issued ultimately by the provider enterprise's root CA.").
The same motivation to modify with Ezell, as in claim 11, applies.
This motivation applies to the remainder of the claim.
Ezell further discloses: obfuscated version of the [parent] key in the second identify certificate (Ezell: Col 9 lines 30-36 states, "the authentication module 124 and/or server application 124 in the server 104 validates that the client certificate 308 was signed by the issuing authority 156, the client's identity is or is not on the permissions list 160, the timestamp is relatively close to the nonce value is one sent by the server 104, and the signature on the message is valid."), but fails to explicitly disclose: parent key.
However, Ben-Reuven further discloses: parent key (Ben-Reuven: Paragraph [0134] states, "The signature can be generated with the parent private key extracted from the link.").
Claim(s) 13-14 is/are rejected under 35 U.S.C. 103 as being unpatentable over Ben-Reuven (US 20220278853 A1, hereinafter referred to as Ben-Reuven) in view of Ezell (US 8312518 B1, hereinafter referred to as Ezell) in further view of Le Saint (WO 2017004470 A1, hereinafter referred to as Le Saint).
Regarding claim 13, the combination of Ben-Reuven as modified by Ezell discloses: The computer implemented method of claim 11, but fails to explicitly disclose: further comprising: obtaining a message used by the proving computer device to generate the proof; and determining the authenticity of the child public key is further based on verifying that the message used by the proving computer device to generate the proof matches the message in the second identify certificate.
However, in the same field of endeavor, Le Saint discloses: further comprising: obtaining a message used by the proving computer device to generate the proof (Le Saint: Paragraph [0102] states, "At 517, the client computer 520 may verify the blinded server public key received from the server computer 560. The client computer 520 may verify the blinded server public key by generating a generated blinded server public key using the server public key 564 (e.g., of the server certificate 572) and the server blinding factor 568 and comparing the generated server blinded public key to the server blinded public key received from the server computer 560. The client computer may authenticate the server computer based on verifying the server blinded public key. In some embodiments, the client computer may verify the signature using the server public key 564. The client computer 520 may authenticate the server computer 560 based on the verification of the signature. In some embodiments, the client computer 520 may generate the generated blinded server public key using the server public key 564 (e.g., of the server certificate), the server blinding factor remainder, and the counter value of the counter stored at the client computer 520."); and determining the authenticity of the child public key is further based on verifying that the message used by the proving computer device to generate the proof matches the message in the second identify certificate (Le Saint: Paragraph [0102] states, "At 517, the client computer 520 may verify the blinded server public key received from the server computer 560. The client computer 520 may verify the blinded server public key by generating a generated blinded server public key using the server public key 564 (e.g., of the server certificate 572) and the server blinding factor 568 and comparing the generated server blinded public key to the server blinded public key received from the server computer 560. The client computer may authenticate the server computer based on verifying the server blinded public key. In some embodiments, the client computer may verify the signature using the server public key 564. The client computer 520 may authenticate the server computer 560 based on the verification of the signature. In some embodiments, the client computer 520 may generate the generated blinded server public key using the server public key 564 (e.g., of the server certificate), the server blinding factor remainder, and the counter value of the counter stored at the client computer 520.").
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention was made to modify the teaching of Ben-Reuven as modified by Ezell and include the above limitation with the teaching of Le Saint in order to ensure "that data is securely communicated between computers" (Le Saint: Paragraph [0002]).
Regarding claim 14, the combination of Ben-Reuven as modified by Ezell discloses: The computer implemented method of claim 11.
Ben-Reuven further discloses: wherein the method comprises: transmitting a request to the proving computer device, the request requesting the [child] public key (Ben-Reuven: Paragraph [0134] states, "a contract initiation request is received, e.g., from a first user. For example, as shown in FIG. 2A, user 230A can utilize device 210A to activate dApp 212 and interface with service 220 in order to initiate a contract. Such a contract initiation request can include various parameter(s) associated with the contract (e.g., the type of contract, length of time, maximum number of influencers, bounty, etc.), as described in detail herein. Additionally, the referenced contract initiation request (e.g., as received by service 220 from device 210A) can also include identifying parameter(s) associated with the first user, such as an address (e.g. on Ethereum) of the first user and/or a public key associated with the first user").
Ben-Reuven further discloses: child public key (Ben-Reuven: Paragraph [0212] states, "each influencer can compute the public key for the child and sign the new public key in addition to signing his own address using the parent private key. The converter supplies the signatures and the contract validates the first signature in the path using the stored public key used by the contractor. The contract then extracts from the signature the public address of the next step and uses it to validate the next signature and so on."); and in response to the request, receiving the child public key, the zero knowledge proof, [the first identity certificate and the second identity certificate] (Ben-Reuven: Paragraph [0055] states, "A link 250A can be generated which includes contract address 252 (e.g., the address of the smart contract on the blockchain, an Ethereum address, and/or an address at which service 220 maintains the details, parameters, etc. of the contract, campaign, etc.) and secret/private key 216A. User 230A can then disseminate link 250A (e.g., via social media, email, etc.). Additionally, in certain implementations the referenced first link further can also include a zero-knowledge cryptographic proof."), but fails to explicitly disclose: receiving…the first identity certificate and the second identity certificate.
However, Ezell discloses: receiving…the first identity certificate and the second identity certificate. (Ezell: Col 6 lines 44-55 states, "The memory 116 of the enterprise server 104 includes first Certificate Authority ("CA") issued sets of certificates 120a-k, a (server-side) authentication module 124, second CA issued set of certificates 128, server application 132, issuing authority (or second CA) 156, and permissions list 160. The first sets of CA issued certificates each include a chain of trust having a root certificate issued by the first CA and a digital certificate digitally signed by the first CA while the second CA issued set of certificates includes a chain of trust having a root certificate issued by the second CA and a digital certificate issued or signed by a second CA (which is different from the first CA).").
The same motivation to modify with Ezell, as in claim 11, applies.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SHREYAJ RAM BHANDARI whose telephone number is (571)272-0727. The examiner can normally be reached 7:30-5:00.
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, Ali Shayanfar can be reached at (571) 270-1050. 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.
/SHREYAJ RAM BHANDARI/ Examiner, Art Unit 2434
/NOURA ZOUBAIR/ Primary Examiner, Art Unit 2434
Prosecution Insights