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 .
Claims 1-24 are pending in this application.
No IDS was submitted by the Applicant.
Claim Objections
Claims 1, 3 and 7 are objected to because of the following:
Claim 1 recites “User Aand the User Bin context” which should be rewritten as “User A and the User B in context”.
Claim 3 recites “the user Aand a public-private key pair … the user Bbased on the parameters of RLWE” which should be rewritten as “the user A and a public-private key pair … the user B based on the parameters of RLWE”
Claim 7 recites “the user Aby homomorphically encrypting” which should be rewritten as “the user A by homomorphically encrypting”
Appropriate correction is required.
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-24 are rejected under 35 U.S.C. 101 because the claims as a whole considering all claim elements both individually and in combination, do not amount to significantly more than an abstract idea.
Under Prong One of Step 2A, upon examination, the claims are determined to be directed to an abstract idea. Specifically, independent claim 1 recites a series of steps involving: generating, splitting, encrypting, re-encrypting, and decrypting cryptographic shares; homomorphic addition of encrypted values; partial decryption and recombination of cryptographic shares; and reconstructing a shared secret and using the shared secret to create and verify a digital signature.
These steps collectively amount to mathematical concepts, including cryptographic algorithms, encryption, decryption, hashing, key generation, and modular arithmetic, which are forms of mathematical relationships and calculations. Such concepts fall within the category of abstract ideas identified by the courts and the USPTO, including mental processes and mathematical operations that can be performed by a human using pen and paper or by a generic computer.
Further, the claims are also directed to fundamental practices of secure communication and identity verification, which constitute methods of organizing human activity (e.g., authentication, verification, and trust establishment).
Accordingly, claim 1 recites a judicial exception, and claims 2–24, which depend therefrom and add further cryptographic calculations and protocol steps, likewise recite the same abstract idea.
Under Prong Two of Step 2A, the claims do not integrate the judicial exception into a practical application. Although the claims recite terms such as “quantum safe,” “RLWE,” “homomorphic encryption,” and “collective identity,” these terms merely describe the abstract cryptographic techniques used, rather than how the techniques are applied in a manner that improves the functioning of a computer or other technology. The claims: do not recite a specific improvement to computer architecture, processor operation, memory structure, or network functionality; do not require any particular machine configuration, specialized hardware, or unconventional computing component; do not provide a technical solution rooted in a computer problem, but instead use generic computing devices to perform cryptographic calculations. Rather, the claims merely apply cryptographic mathematics to achieve the result of secure communication and digital signature verification, which is an abstract goal. Merely labeling the cryptographic scheme as “quantum safe” does not render the claim non-abstract, as the claims still rely on generic mathematical processing performed by conventional computing devices. Therefore, the claims fail to integrate the abstract idea into a practical application.
Under Step 2B, the claims do not recite an inventive concept sufficient to transform the abstract idea into patent-eligible subject matter.
The additional elements recited in the claims—including encryption, homomorphic addition, partial decryption, share splitting, hashing, and key reconstruction—are well-understood, routine, and conventional cryptographic techniques used in the field of secure communications. The claims do not recite any unconventional or non-generic arrangement of components, nor do they require a specific technical implementation that goes beyond applying known cryptographic techniques using a generic computing environment.
Further, the claims are largely result-oriented, reciting functional outcomes such as “re-creating the same secret key,” “creating the collective identity,” and “enabling secure communication,” without specifying a particular technical mechanism that constitutes an inventive concept.
Accordingly, the claims amount to no more than instructions to apply an abstract idea using generic computer technology, which is insufficient to confer eligibility under 35 U.S.C. 101.
Claims 1–24 are therefore directed to an abstract idea and do not recite significantly more than the abstract idea itself. As such, claims 1–24 are rejected under 35 U.S.C. §101.
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.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1-24 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.
Claim 1 recites a list of steps that are unclear whether these steps are sequential steps of the method, parallel actions, or optional features. The structure lacks clear transitions, antecedents, and logical flow, rendering the scope ambiguous. For example:
"re-encrypting, the plurality of the shares to obtain the encrypted plurality of shares by the platform;" – it is unclear what is being re-encrypted (previously encrypted shares?) and by whom initially.
"decrypting, the plurality of shares shared by the User B;" – unclear who performs this decryption.
Multiple actors (User A, User B, platform) perform actions without clear delineation.
The final steps shift to creating a "collective ID" for secure communication, but it is unclear if this is part of signature creation/verification.
Claim 1 also has Inconsistencies and lack of antecedent basis:
"the plurality of encrypted shares associated with the User A" lacks clear basis for how they are "associated."
"the same secret key which is the “collective identity”" – unclear if this is a new key or previously mentioned.
"the collective ID between the User A and the User B" – differs from "collective identity"; unclear if the same.
Claim 1 in preamble recites “quantum safe method for creation and verification of digital signature”. However, the ultimate output is a shared key used for symmetric encryption of messages, not a standard asymmetric digital signature; unclear if it meets the preamble.
Dependent claims 2-24 recite mathematical formulas and equations without defining the variables included in these formulas or equations.
Moreover, dependent claims 2-24 are indefinite by dependence on claim 1 and for similar structural/antecedent issues.
Claims may be amended to a clear series of ordered method steps with proper transitions, antecedents, and consistent terminology.
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.
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.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1-24 are rejected under 35 U.S.C. 103 as being unpatentable over POLYAKOV et al. (US 2021/0399874 A1) (hereinafter, “POLYAKOV”) in view of Ding (US 2015/0067336 A1).
As to claim 1, POLYAKOV teaches a quantum safe method for creation and verification of digital signature (“… based on the hardness of the Ring LWE problem” -e.g., see, [0041]), comprising:
encrypting, a plurality of shares associated with a User A, by using an encryption scheme to obtain encrypted plurality of shares (“In FIG. 1, each data owner 140, 150, 160, . . . has its own secret key share s.sub.j (a portion of the full joint public key pk). Data owners 140, 150, 160, . . . collaboratively interact to combine their secret key shares s.sub.j to generate a common public key pk=s=Σ.sub.js.sub.j and associated common evaluation key. One or more data owners 140, 150, 160, . . . encrypt their respective data D.sub.i 180 with the common public key pk and send the encrypted data and associated common evaluation key to a computational host 210.” -e.g., see, [0050]; see also: “… the common public key for multiple parties is a linear key generated by summing up the multiple parties' respective public key share. For example, each jth party with a secret share s.sub.j may generate a corresponding public key share pk.sub.j=as.sub.j+e.sub.j, where all parameters may be e.g., cyclotomic ring elements, such as in Z.sub.q [x]/(x.sup.n+1), where q is a modulus, n is a power-of-two ring dimension, a is a uniform ring element, s.sub.i is a uniform (typically ternary) ring element, and e.sub.i is a Gaussian error ring element.” -e.g., see, [0014]; herein, each party (e.g., user A) generates secret shares s.sub.i and encrypts with public key shares pk.sub.j; shares are encryted and contributed; see also, [0003], [0032], [0033], [0060]);
passing, the plurality of encrypted shares associated with the User A, to the platform (“One or more data owners 140, 150, 160, . . . encrypt their respective data D.sub.i 180 with the common public key pk and send the encrypted data and associated common evaluation key to a computational host 210.” -e.g., see, [0050]; herein, computational host is a platform/server distinct from the users);
re-encrypting, the plurality of the shares to obtain the encrypted plurality of shares by the platform (“…the computational host may re-encrypt a non-linear ciphertext result with a re-linearization key (c,d) to generate a linear ciphertext result that may be collaboratively decrypted by the multiple data owners 140, 150, 160, . . . without exposing the common secret key.” -e.g., see, [0050]; herein, Polyakov teaches platform-side-re-encryption (relinearization key switching), which reads on “re-encrypting … by the platform; see also: “The computational host 210 performs the HE model computations, using the common evaluation key, on the HE data 180, all in HE space, without access to the unencrypted data or model, to generate a multiparty computational result. In some embodiment, the HE computations may include re-encrypting a non-linear ciphertext result with a HE re-linearization key (c,d) to generate a linear ciphertext result that may be collaboratively decrypted by the multiple parties 140 and 170 without exposing the common secret key. Additionally or alternatively, the HE computations may include re-encrypting a ciphertext with a HE rotation/automorphism key (a,b) to rotate or permute the ciphertext. The re-linearized or rotated/permuted result may be collaboratively decrypted by the multiple parties 140 and 170, where the data owner 140 and model owner 170 each performs a partial layer of decryption using its respective secret key share s.sub.j to yield the fully decrypted result.” -e.g., see, [0051]; herein, key switching and relinearization are standard forms of ciphertext re-encryption, performed by the platform without learning plaintext values, see also, [0049], [0050], [0063]; herein teaches re-encrypt the result ciphertext with a re-linearization key to swap encryption keys from the non-linear public key to a linear public key);
decrypting, the plurality of shares shared by the User B (“… each party contributing a partial decryption using its secret key share …” -e.g., see, [0003]; see also: “The re-linearized or rotated/permuted computational result may be collaboratively decrypted by the multiple parties 140, 150, 160, . . . , where each data owner performs its respective partial decryption using its secret key share s.sub.j and the decrypted results are combined to generate the decryption of each party's data D.sub.i.” -e.g. see, [0050]; see also: “…each of the plurality of parties, one or more processors (e.g., 146, 156, 166, 176, . . . ) may partially decrypt the re-encrypted result ciphertext by the linear secret key share associated with the party” -e.g., see, [0067]);
receiving, the plurality of shares associated with the User B from the User B by the User A (“… distribute the re-encrypted result ciphertext to the plurality of parties.” -e.g. see, [0066]; herein, each party (e.g., user A) receives distributed ciphertext/results/partial decryption for collaborative operation);
sharing, by the platform, half of the plurality of shares encrypted for the User A, with the User A and the other half of the plurality of shares encrypted for the User B, with User B (“The re-encrypted result ciphertext may be distributed to the plurality of parties to each partially decrypt the re-encrypted result ciphertext by a linear secret key share associated with the party, which in combination with partial decryptions of the re-encrypted result ciphertext by each of the other parties, fully decrypts the result by a linear common secret key that is a sum of the secret key shares of the respective plurality of parties. Thus the initial result ciphertext encrypted by the non-linear public key, which would require decryption by a non-linear common secret key that could only be generated by exposing the linear common secret key, is transformed to the re-encrypted result ciphertext encrypted by the linear public key, which is decrypted collaboratively by each party independently partially decrypting with their respective secret key share so as not to expose the full linear common secret key.” -e.g., see, [0006]; herein, each party receives encrypted shares which is less than the full liner shares to make sure no single party has the full secret; This reads on dividing shares among user A and User B -a half/half partitioning would be a design choice; see also, [0050], [0051], [0064]);
independently combining, by the User A, the plurality of shares associated with the User A with the plurality of shares associated with the User B, received from the User B (“Each party has a secret key share and a corresponding public key share. Linear key shares are used for their linear additive property so that the common public key is equal to the sum of the public key shares of the multiple parties and the common secret key is equal to the sum of the secret key shares of the multiple parties. The common public key may thus be generated collaboratively by the multiple parties, where each party individually and sequentially adds its public key share, which is cumulatively equivalent to complete common public key. The common public key may then be shared with all parties and used to encrypt data as ciphertexts. Computations may be performed on the encrypted data (ciphertexts) using FHE. An encrypted computational result may be decrypted using a similar interactive procedure where all parties collaborate, each party contributing a partial decryption using its secret key share, until the entire result is decrypted. Thus, the underlying complete secret key is never revealed to any individual party.” -e.g., see, [0003]; see also: [0014]; herein teaches, the re-linearized ciphertext product may thus be decrypted collaboratively by each party individually and sequentially contributing a partial decryption using their respective secret key shares, until the entire result is decrypted. With the re-linearized key, no secret key shares have to be combined as with a non-linear secret key.);
independently combining, by the User B, the plurality of shares associated with the User B with the plurality of shares associated with the User A, received from the User A (“Each party has a secret key share and a corresponding public key share. Linear key shares are used for their linear additive property so that the common public key is equal to the sum of the public key shares of the multiple parties and the common secret key is equal to the sum of the secret key shares of the multiple parties. The common public key may thus be generated collaboratively by the multiple parties, where each party individually and sequentially adds its public key share, which is cumulatively equivalent to complete common public key. The common public key may then be shared with all parties and used to encrypt data as ciphertexts. Computations may be performed on the encrypted data (ciphertexts) using FHE. An encrypted computational result may be decrypted using a similar interactive procedure where all parties collaborate, each party contributing a partial decryption using its secret key share, until the entire result is decrypted. Thus, the underlying complete secret key is never revealed to any individual party.” -e.g., see, [0003]; see also: [0014]; herein teaches, the re-linearized ciphertext product may thus be decrypted collaboratively by each party individually and sequentially contributing a partial decryption using their respective secret key shares, until the entire result is decrypted. With the re-linearized key, no secret key shares have to be combined as with a non-linear secret key.);
re-creating, the same secret key which is the “collective identity” for the User A and the User Bin context (“… each jth party with a secret share s.sub.j may generate a corresponding public key share pk.sub.j=as.sub.j+e.sub.j, where all parameters may be e.g., cyclotomic ring elements, such as in Z.sub.q [x]/(x.sup.n+1), where q is a modulus, n is a power-of-two ring dimension, a is a uniform ring element, s.sub.i is a uniform (typically ternary) ring element, and e.sub.i is a Gaussian error ring element. The common public key is pk=(α, Σ.sub.j pk.sub.j). Threshold FHE ring constructions may use this procedure for generating a common public key. Similarly, in threshold FHE, the common secret key for multiple parties is a linear key generated by summing up the multiple parties' respective secret key shares such that s=Σ.sub.js.sub.j.” -e.g., see, [0014]; see also, [0016], [0064], [0067]);
POLYAKOV doesn’t explicitly disclose creating, the collective ID between the User A and the User B to enable establishing secure communication between the user A, the User B, and the platform.
However, in an analogous art, Ding discloses the collective ID between the User A and the User B to enable establishing secure communication between the user A, the User B, and the platform (“…key distribution (KD) system … any two users can derive a shared key” -e.g., see, [0003]; see also: “… build a KD system with a central server. …” -e.g., see, [0009]; see also, [0096], [0117]; Ding teaches a system involving a central server/authority enabling two users to derive a shared key used for secure communications. Combining this purpose with Polyakov’s platform-assisted threshold HE key material handling provides the claimed “collective ID … in enable establishing secure communication between User A, User B, and the platform”).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention was to modify the teaching of POLYAKOV as taught by Ding in order to obtain a shared secret/collective identity for secure communications while preserving the security goal that the full secret key is not exposed to any single party or the host.
As to claim 2, POLYAKOV in view of Ding discloses the quantum safe method for creation and verification of digital signature as claimed in claim 1, Ding further discloses comprises creating or generating, by the platform, a unique key K.sub.A for the User A, and another unique key K.sub.B for the User B (“… the central server or authority assigns each user i a public ID as a matrix A.sub.i with small entries or establish the ID of each user as a matrix A.sub.i with small entries following certain error distributions with the information that can identify the user uniquely, and, in a secure way, gives each user a private key …” -e.g., see, Ding: [0009], see also, Ding: [0010]).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention was to modify the teaching of POLYAKOV as taught by Ding in order to obtain a shared secret/collective identity for secure communications while preserving the security goal that the full secret key is not exposed to any single party or the host.
As to claim 3, POLYAKOV in view of Ding discloses the quantum safe method for creation and verification of digital signature as claimed in claim 1, Ding further discloses comprises generating, public-private key pair (pk.sub.A, sk.sub.A) for the user A and a public-private key pair (pk.sub.B, sk.sub.B) for the user B based on the parameters of RLWE (“… ring learning with errors (RLWE problem …” -e.g., see, [0015], [0057], see also, [0090]).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention was to modify the teaching of POLYAKOV as taught by Ding in order to obtain a shared secret/collective identity for secure communications while preserving the security goal that the full secret key is not exposed to any single party or the host.
As to claim 4, POLYAKOV in view of Ding discloses the quantum safe method for creation and verification of digital signature as claimed in claim 1, POLYAKOV further discloses comprises splitting, a randomly generated cryptographically secure pseudo random number S.sub.A associated with User A, into a plurality of shares [a.sub.1, a.sub.2, a.sub.3, a.sub.4 . . . a.sub.n] (e.g., see, POLYAKOV: [0014]; herein, POLYSKOV teaches splitting secrets into shares that combine additively; see also: POLYAKOV: [0040], [0055] – [0057]).
As to claim 5, POLYAKOV in view of Ding discloses the quantum safe method for creation and verification of digital signature as claimed in claim 1, POLYAKOV further discloses comprises splitting, a randomly generated cryptographically secure pseudo random number Sp associated with User B, into a plurality of shares [b.sub.1, b.sub.2, b.sub.3, b.sub.4 . . . b.sub.n] (POLYAKOV: [0003]; herein, POLYAKOV teaches secret key shares of the multiple parties; see also: POLYAKOV: [0040], [0055] – [0057]).
As to claim 6, POLYAKOV in view of Ding discloses the quantum safe method for creation and verification of digital signature as claimed in claim 1, POLYAKOV further discloses comprises splitting, a randomly generated cryptographically secure pseudo random number S.sub.G associated with the platform, into a plurality of shares [g.sub.1, g.sub.2, g.sub.3, g.sub.4 . . . g.sub.n] (POLYAKOV: [0050]; herein, computational host participates without learning full secret; see also: POLYAKOV: [0040], [0055] – [0057]).
As to claim 7, POLYAKOV in view of Ding discloses the quantum safe method for creation and verification of digital signature as claimed in claim 1, POLYAKOV further discloses comprises receiving, by the platform, at least partial shares [a.sub.1, a.sub.2] and [a.sub.3, a.sub.4] from the plurality of shares [a.sub.1, a.sub.2, a.sub.3, a.sub.4 . . . a.sub.n] from the User A by homomorphically encrypting using the key pk.sub.A (“Threshold Fully Homomorphic Encryption (FHE) is a secure multiparty computation protocol where all parties interact to generate a common public key and a common secret key. Each party has a secret key share and a corresponding public key share. Linear key shares are used for their linear additive property so that the common public key is equal to the sum of the public key shares of the multiple parties and the common secret key is equal to the sum of the secret key shares of the multiple parties. The common public key may thus be generated collaboratively by the multiple parties, where each party individually and sequentially adds its public key share, which is cumulatively equivalent to complete common public key.” -e.g., see, POLYAKOV: [0003]; see also, [0041] – [0043], [0058]).
As to claim 8, POLYAKOV in view of Ding discloses the quantum safe method for creation and verification of digital signature as claimed in claim 1, POLYAKOV further discloses comprises receiving, by the platform, at least partial shares [b.sub.1, b.sub.2] and [b.sub.3, b.sub.4] from the plurality of shares [b.sub.1, b.sub.2, b.sub.3, b.sub.4 . . . b.sub.n] from the User B by homomorphically encrypting using the key pk.sub.B (“…each party has a… public key share” -e.g., see, [0003]; see also, [0041] – [0043], [0058]).
As to claim 9, POLYAKOV in view of Ding discloses the quantum safe method for creation and verification of digital signature as claimed in claim 1, POLYAKOV further discloses comprises homomorphic addition, by the platform, of the at least encrypted partial shares A.sub.1=HEnc(a.sub.1, a.sub.2, pk.sub.A) and A.sub.2=HEnc(b.sub.1, b.sub.2, pk.sub.A) and [g.sub.1, g.sub.2] (“… liner additive property” -e.g., see, [0003]; see also, “… sum of the secret key shares …” -e.g., see, [0014]).
As to claim 10, POLYAKOV in view of Ding discloses the quantum safe method for creation and verification of digital signature as claimed in claim 1, POLYAKOV further discloses comprises homomorphic addition, by the platform, of the at least encrypted partial shares A.sub.2=HEnc(a.sub.3, a.sub.4, pk.sub.A) and B.sub.2=HEnc(b.sub.3, b.sub.4, pk.sub.A) and [g.sub.3, g.sub.4] (“… liner key generated by summing up …” -e.g., see, [0014]).
As to claim 11, POLYAKOV in view of Ding discloses the quantum safe method for creation and verification of digital signature as claimed in claim 1, POLYAKOV further discloses comprises receiving, by the User B encrypted sum and partially decrypting it to get pd.sub.B=S.sub.1[0]+sk.sub.B.Math.S.sub.1[1]−sk.sub.B.Math.A.sub.1[1] (“… each party contributing a partial decryption …” -e.g., see, [0003]).
As to claim 12, POLYAKOV in view of Ding discloses the quantum safe method for creation and verification of digital signature as claimed in claim 1, POLYAKOV further discloses comprises sharing, with the User A the partially decrypted sum after encrypting it as PD.sub.B=HEnc(pd.sub.B, pk.sub.A) (“…distributed to the plurality of parties” -e.g., see, [0006]).
As to claim 13, POLYAKOV in view of Ding discloses the quantum safe method for creation and verification of digital signature as claimed in claim 1, POLYAKOV further discloses comprises receiving, by the User A encrypted sum and partially decrypting it decrypting to get pd.sub.A=S.sub.2[0]+sk.sub.A.Math.S.sub.2[1]−sk.sub.A.Math.B.sub.2[1] (“… partially decrypt… using its secret key share ..” -e.g., see, [0067]).
As to claim 14, POLYAKOV in view of Ding discloses the quantum safe method for creation and verification of digital signature as claimed in claim 1, POLYAKOV further discloses comprises sharing, with the User B the partially decrypted sum after encrypting it as PD.sub.A=HEnc(pd.sub.A, pk.sub.B) (“… distribute the re-encrypted result ciphertext” -e.g., see, [0066]).
As to claim 15, POLYAKOV in view of Ding discloses the quantum safe method for creation and verification of digital signature as claimed in claim 1, POLYAKOV further discloses comprises receiving, by the User A from the User B, the encrypted partially decrypted sum and decrypt it as PD.sub.B[0]+sk.sub.A.Math.PD.sub.B[1]−u.sub.1.Math.pk.sub.A to get the combined shares [z.sub.1, z.sub.2]=[a.sub.1+b.sub.1+g.sub.1, a.sub.2+b.sub.2+g.sub.2] (“… common secret key… sum of the secret key shares…” -e.g., see, [0003], see also, [0014]).
As to claim 16, POLYAKOV in view of Ding discloses the quantum safe method for creation and verification of digital signature as claimed in claim 1, POLYAKOV further discloses comprises receiving, by the User B from the User A, the encrypted partially decrypted sum and decrypt it as PD.sub.A[0]+sk.sub.B.Math.PD.sub.A[1]−v.sub.2.Math.pk.sub.B to get the combined shares [z.sub.3, z.sub.4]=[a.sub.3+b.sub.3+g.sub.3, a.sub.4+b.sub.4+g.sub.4] (“Threshold FHE ring constructions may use this procedure for generating a common public key. Similarly, in threshold FHE, the common secret key for multiple parties is a linear key generated by summing up the multiple parties' respective secret key shares such that s=Σ.sub.js.sub.j.” -e.g., see, [0014]).
As to claim 17, POLYAKOV in view of Ding discloses the quantum safe method for creation and verification of digital signature as claimed in claim 1, POLYAKOV further discloses comprises sharing, via the platform 102, z.sub.2 to User B, and z.sub.3 to User A (“… distributed to the plurality of parties…” -e.g., see, [0006]; herein, POLYAKOV supports selective distribution of cryptographic outputs).
As to claim 18, POLYAKOV in view of Ding discloses the quantum safe method for creation and verification of digital signature as claimed in claim 1, POLYAKOV further discloses comprises reconstructing, shared key K.sub.AB=S.sub.A+S.sub.B+S.sub.G by the User A, and the User B independent of each other and oblivious to the platform (“… collaboratively decrypted … without exposing the common secret key” -e.g., see, [0067]; herein POLYAKOV teaches platform obliviousness to the final secret since collaboratively decrypted each party).
As to claim 19, POLYAKOV in view of Ding discloses the quantum safe method for creation and verification of digital signature as claimed in claim 1, POLYAKOV further discloses comprises creating or generating, by the platform, a unique key K.sub.A for the User A (signer), and another unique key K.sub.B for the User B (verifier), and a shared secret key the “collective identity” between the signer and the verifier (“… common secret key…” -e.g., see, [0003], see also, [0014], [0067]).
As to claim 20, POLYAKOV in view of Ding discloses the quantum safe method for creation and verification of digital signature as claimed in claim 1, Ding further discloses comprises sharing with the signer, a salted hash of the verifier id K.sub.B by the verifier after encrypting it with K.sub.AB (“… identity … identify the user uniquely …” -e.g., see, Ding: [0005], see also: Ding: [0003], [0010]).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention was to modify the teaching of POLYAKOV as taught by Ding in order to obtain a shared secret/collective identity for secure communications while preserving the security goal that the full secret key is not exposed to any single party or the host.
As to claim 21, POLYAKOV in view of Ding discloses the quantum safe method for creation and verification of digital signature as claimed in claim 1, Ding further discloses comprises decryption by the signer, the received hash from the verifier (“… receiver decrypts the message using the private key…” -e.g.., see, Ding: [0004]).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention was to modify the teaching of POLYAKOV as taught by Ding in order to obtain a shared secret/collective identity for secure communications while preserving the security goal that the full secret key is not exposed to any single party or the host.
As to claim 22, POLYAKOV in view of Ding discloses the quantum safe method for creation and verification of digital signature as claimed in claim 1, Ding further discloses comprises signer sharing a re-hash with the verifier, by adding the id K.sub.A by the signer to the received hash from the verifier (“… digital signature … verify that the public key belongs to the legitimate user” -e.g., see, Ding: [0004]).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention was to modify the teaching of POLYAKOV as taught by Ding in order to obtain a shared secret/collective identity for secure communications while preserving the security goal that the full secret key is not exposed to any single party or the host.
As to claim 23, POLYAKOV in view of Ding discloses the quantum safe method for creation and verification of digital signature as claimed in claim 1, Ding further discloses comprises signer signing and sharing signature with verifier, by adding the re-hash to the document/message and encrypt with K.sub.AB (“… encrypt the message using the encryption system …” -e.g., see, Ding: [0010]).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention was to modify the teaching of POLYAKOV as taught by Ding in order to obtain a shared secret/collective identity for secure communications while preserving the security goal that the full secret key is not exposed to any single party or the host.
As to claim 24, POLYAKOV in view of Ding discloses the quantum safe method for creation and verification of digital signature as claimed in claim 1, Ding further discloses comprises verifier validating, received signature against his document/message added to the received re-hash from the signer (“… verify that the public key belongs to the legitimate user …” -e.g., see, Ding: [0004]).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention was to modify the teaching of POLYAKOV as taught by Ding in order to obtain a shared secret/collective identity for secure communications while preserving the security goal that the full secret key is not exposed to any single party or the host.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SUMAN DEBNATH whose telephone number is (571)270-1256. The examiner can normally be reached Mon-Fri; 9:00am-5:00pm.
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, Farid Homayounmehr can be reached at 571-272-3739. 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.
SUMAN DEBNATH
Patent Examiner
Art Unit 2495
/S.D/Examiner, Art Unit 2495
/FARID HOMAYOUNMEHR/Supervisory Patent Examiner, Art Unit 2495