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 .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 03/26/2026 has been entered.
Response to Arguments
Applicant's arguments, filed 04/01/2026, with respect to the declaration traversing the claim rejections under 35 U.S.C. § 112 and 103 have been fully considered.
The declaration under 37 CFR 1.132 filed 04/01/2026 first argues at paragraphs [0007-0008] that the rejection of claims 1-21 under 35 U.S.C. § 112(b) should be withdrawn. However, the rejection under 35 U.S.C. § 112(b) and arguments thereof have been made moot as the term “verifiably unique” has been removed from claims 1, 6, and 12.
The declaration under 37 CFR 1.132 filed 04/01/2026 next argues at paragraphs [0009-0014] that the rejection of claims 1-21 under 35 U.S.C. § 112(a) should be withdrawn.
The Examiner respectfully disagrees.
Amended independent claims 1, 6, and 12 recite the limitation “a first total public key with a cryptographically embedded first server identifier and a second total public key with a cryptographically embedded second server identifier, wherein the first server identifier is embedded during key generation such that it is cryptographically bound to the first total public key and verifiable by a certificate authority … and the second server identifier is embedded during key generation such that it is cryptographically bound to the second total public key and verifiable by a certificate authority”. The originally filed disclosure is silent with respect to the key generation process achieving the desired results of, “wherein the first server identifier is embedded during key generation such that it is cryptographically bound to the first total public key and verifiable by a certificate authority …” and “the second server identifier is embedded during key generation such that it is cryptographically bound to the second total public key”. This amended claim limitation constitutes new matter and is rejected on the ground that it recites elements without support in the original disclosure. See Waldemar Link, GmbH & Co. v. Osteonics Corp., 32 F.3d 556, 559, 31 USPQ2d 1855, 1857 (Fed. Cir. 1994); Vas-Cath Inc. v. Mahurkar, 935 F.2d 1555, 1560, 19 USPQ2d 1111, 1114 (Fed. Cir. 1991)(A written-description question often arises when an applicant, after filing a patent application, subsequently adds "new matter" not present in the original application.); In re Rasmussen, 650 F.2d 1212, 211 USPQ 323 (CCPA 1981).
Furthermore, the arguments presented in the declaration at paragraphs [0009-0014] regarding the written description support for the limitation “cryptographically embedded” appear to consist of opinion testimony on the ultimate legal conclusion. As in MPEP 716.01(c), "Although factual evidence is preferable to opinion testimony, such testimony is entitled to consideration and some weight so long as the opinion is not on the ultimate legal conclusion at issue. While an opinion as to a legal conclusion is not entitled to any weight, the underlying basis for the opinion may be persuasive. (expert opinion that an application meets the requirements of 35 U.S.C. 112 is not entitled to any weight; however, facts supporting a basis for deciding that the specification complies with 35 U.S.C. 112 are entitled to some weight); (Although an affiant’s or declarant’s opinion on the ultimate legal issue is not evidence in the case, "some weight ought to be given to a persuasively supported statement of one skilled in the art on what was not obvious to him." Although an affidavit or declaration which states only conclusions may have some probative value, such an affidavit or declaration may have little weight when considered in light of all the evidence of record in the application."
The declaration under 37 CFR 1.132 filed 04/01/2026 next argues at paragraphs [0015-0020] that the rejection of claims 1-21 under 35 U.S.C. § 103 should be withdrawn.
The Examiner respectfully disagrees.
Upon full consideration, the declaration filed appears to verbatim repeat the contents of the remarks filed 03/26/2026. The declaration under 37 CFR 1.132 filed 04/01/2026 is insufficient to overcome the rejection of claims 1-21 based upon 35 U.S.C. § 103 as set forth in the last Office action because: It refers only to the system described in the above referenced application and not to the individual claims of the application. As such the declaration does not show that the objective evidence of nonobviousness is commensurate in scope with the claims. See MPEP § 716.
Applicant’s arguments, see page 8, filed 03/26/2026, with respect to the objection to claim 1 have been fully considered. The Examiner defers to the rejection below as a response to this amendment.
Applicant’s arguments, see page 8, filed 03/26/2026, with respect to the objection to Figure 2 have been fully considered. The objection to Figure 2 has been withdrawn in response to Figure 2 being designated as Prior Art.
Applicant’s arguments with respect to the rejection of claim(s) 1-21 under 35 U.S.C. § 112(b) regarding the limitation “verifiably unique” have been fully considered but are moot as the limitation has been removed. Furthermore, the claim amendment introducing the limitations “wherein the first server identifier is embedded during key generation such that it is cryptographically bound to the first total public key and verifiable by a certificate authority …” and “the second server identifier is embedded during key generation such that it is cryptographically bound to the second total public key” presents new issues of new matter and will be addressed in the rejection below.
Applicant's arguments, see pages 10-11, filed 03/26/2026, with respect to the rejection of claims 1-21 under 35 U.S.C. § 112(a) have been fully considered but they are not persuasive.
Applicant first attests that the originally filed disclosure supports the claimed “total public key[s] with a cryptographically embedded” server identifier and the identifiers being “embedded during key generation such that it is cryptographically bound” are supported by paragraphs [0023] and [0044] of the originally filed disclosure.
The Examiner respectfully disagrees.
Paragraph [0023] of the originally filed disclosure only enumerates that “the backend servers then each create a total public key based on the composite public key and the BESID” (underline added). There is no embedding process enumerated. Paragraph [0044] states that the system embeds the BESID 506 into the total public key 502 and the finalizing key 504 without disclosing how the inventor intended to achieve the claimed “total public key[s] with a cryptographically embedded” server identifier. Furthermore, the originally filed disclosure is silent with respect to any cryptographic binding process as claimed in the desired results of the identifiers being “embedded during key generation such that it is cryptographically bound”. Additionally, neither paragraphs [0051-0053] nor [0060] support the claimed desired result the identifiers being “embedded during key generation such that it is cryptographically bound”.
Lastly, neither the declaration filed 04/01/2026, nor the remarks filed 03/26/2026 address the new matter rejection made under 35 U.S.C. § 112(a) in the Final Rejection mailed 11/26/2025 concerning dependent claim 21, and will be maintained in the rejection below.
Applicant's arguments, see pages 11-12, filed 03/26/2026, with respect to the rejection of claims 1-21 under 35 U.S.C. § 103 have been fully considered but they are not persuasive.
Applicant first argues that none of the prior art references teach or suggest “a total public key in which a backend server identifier is cryptographically embedded in the public key itself”.
The Examiner respectfully disagrees.
The claim only requires “a first total public key with a cryptographically embedded first server identifier and a second total public key with a cryptographically embedded second server identifier”. This limitation does not require the specific operation that allegedly modifies the cryptographic structure of the public key within the specification as Applicant argues. In response to applicant's argument that the references fail to show certain features of the invention, it is noted that the features upon which applicant relies (i.e., the particular identity-embedding function argued) are not recited in the rejected claim(s). Although the claims are interpreted in light of the specification, limitations from the specification are not read into the claims. See In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993).
Furthermore, Applicant’s characterization of Basin’s disclosed Smartkey components in Figure 2 as “external metadata” is incorrect as paragraph [0061] of the Basin reference reads “FIG. 2 illustrates an exemplary embodiment of a Smartkey 200. As shown in FIG. 2, the Smartkey 200 may include a Smartkey Name or Label 205 that identifies the Smartkey, a Smartkey Version Info 210 that provides version information about the Smartkey, one or more encrypted master keys 215, one or more access control information data structures 220, one or more characteristic signatures 225, one or more team or group keys 230, one or more private keys (SID) with shash 235, one or more public keys (PID/XPID) with Uniform Resource Names (URN) 240, one or more team or group names 250 which are the names associated with the team or group keys, and one or more user, device, or application names 260, which may be used to identify assets to which the Smartkey provides access”; this inclusion as explicitly disclosed, reads on the broadest reasonable interpretation of the total public keys “with a cryptographically embedded” server identifier, as the Smartkey of Basin has the embedded URN.
Applicant next argues that the “mapping of a ‘finalizing key’ to Basin’s ‘key encrypting key’ is inapposite” and that “mapping ‘embedded identifier’ to Basin’s URN conflates metadata association with the claimed cryptographic embedding within the public key”.
The Examiner respectfully disagrees.
For at least the reasons discussed above, the URN of Basin is not mere “metadata association” as argued, and reads on the broadest reasonable interpretation of the claimed “embedded”. Furthermore, Applicant’s argument that the mapping of the claimed “finalizing key” being “inapposite” is unpersuasive as the claim only requires that the second signature is generated “based on the combined signature and a finalizing key, the finalizing key being generated based on the server identifier of the backend server extracted from the corresponding total public key” (underline added). Upon further consideration, the inclusion of paragraphs [0109] and [0116] of Basin remedies the claim mapping, as paragraph [0109] includes at least the disclosure of each characteristic being placed into a Smartkey is preferably authenticated, including digital signatures; and [0116] disclosing that the signature “may be attached to the signed characteristic within a smartkey, or placed separately in the smartkey. Preferably a signature characteristic is attached. For example, an attached signature characteristic for a PID with URN characteristic may be formed as follows {“PID”: “bytes of PID with URN”, “Signature”:“<bytes of signature>”}”.
Applicant then argues that that Basin’s certificate binding of an owner identity to a public key is not a cryptographic embedding of a server identifier into the key itself, nor does it [the Basin reference] teach CA verification of such embedding as claimed.
The Examiner respectfully disagrees.
Basin expressly recites including the identifier into the key itself as described above, the currently amended claims including the limitations “wherein the first server identifier is embedded during key generation such that it is cryptographically bound to the first total public key and verifiable by a certificate authority …” and “the second server identifier is embedded during key generation such that it is cryptographically bound to the second total public key” introduce significant new matter issues, and Applicant’s argument that CA verification is not taught is moot as CA verification is not claimed. In response to applicant's argument that the references fail to show certain features of the invention, it is noted that the features upon which applicant relies (i.e., CA verification “of such embedding”) are not recited in the rejected claim(s). Although the claims are interpreted in light of the specification, limitations from the specification are not read into the claims. See In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993).
Applicant lastly argues that there are alleged deficiencies in the claim mappings for dependent claims 2-3, 7-8, 13-14, 4-5, 9-10, 15-16, 17-20.
The Examiner respectfully disagrees.
Applicant’s arguments fail to comply with 37 CFR 1.111(b) because they fail to distinctly and specifically point out the supposed errors in the examiner’s action.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims 1-21 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention.
Regarding Claims 1, 6, and 12:
Amended independent claims 1, 6, and 12 recite the limitation “a first total public key with a cryptographically embedded first server identifier and a second total public key with a cryptographically embedded second server identifier, wherein the first server identifier is embedded during key generation such that it is cryptographically bound to the first total public key and verifiable by a certificate authority … and the second server identifier is embedded during key generation such that it is cryptographically bound to the second total public key and verifiable by a certificate authority”. The originally filed disclosure is silent with respect to the key generation process achieving the desired results of, “wherein the first server identifier is embedded during key generation such that it is cryptographically bound to the first total public key and verifiable by a certificate authority …” and “the second server identifier is embedded during key generation such that it is cryptographically bound to the second total public key”. This amended claim limitation constitutes new matter and will be rejected on the ground that it recites elements without support in the original disclosure. See Waldemar Link, GmbH & Co. v. Osteonics Corp., 32 F.3d 556, 559, 31 USPQ2d 1855, 1857 (Fed. Cir. 1994); Vas-Cath Inc. v. Mahurkar, 935 F.2d 1555, 1560, 19 USPQ2d 1111, 1114 (Fed. Cir. 1991)(A written-description question often arises when an applicant, after filing a patent application, subsequently adds "new matter" not present in the original application.); In re Rasmussen, 650 F.2d 1212, 211 USPQ 323 (CCPA 1981).
In addition, the originally filed disclosure is not commensurate with the claimed “a first total public key with a cryptographically embedded first server identifier and a second total public key with a cryptographically embedded second server identifier”. Paragraph [0023] of the originally filed disclosure only enumerates that “the backend servers then each create a total public key based on the composite public key and the BESID” (underline added). There is no embedding process disclosed that is commensurate with the claimed “cryptographically embedded”. Paragraph [0044] states that the system embeds the BESID 506 into the total public key 502 and the finalizing key 504 without disclosing how the inventor intended to achieve the claimed “total public key[s] with a cryptographically embedded” server identifier.
Regarding Claim 21:
Claim 21 recites “wherein the first server identifier is embedded in the first total public key as part of the key generation process, such that the first server identifier is cryptographically bound to the first total public key and verifiable by a certificate authority; and the second server identifier is embedded in the second total public key as part of the key generation process, such that the second server identifier is cryptographically bound to the second total public key and verifiable by a certificate authority”. This amended claim limitation constitutes new matter and will be rejected on the ground that it recites elements without support in the original disclosure. See Waldemar Link, GmbH & Co. v. Osteonics Corp., 32 F.3d 556, 559, 31 USPQ2d 1855, 1857 (Fed. Cir. 1994); Vas-Cath Inc. v. Mahurkar, 935 F.2d 1555, 1560, 19 USPQ2d 1111, 1114 (Fed. Cir. 1991)(A written-description question often arises when an applicant, after filing a patent application, subsequently adds "new matter" not present in the original application.); In re Rasmussen, 650 F.2d 1212, 211 USPQ 323 (CCPA 1981).
The dependent claims do not disclose any details which cure the deficiencies found in the claims they depend upon and are therefore rejected as well.
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-21 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.
The term “cryptographically bound” in claims 1, 6, 12, and 21 is a relative term which renders the claim indefinite. The term “cryptographically bound” is not defined by the claim, the specification does not provide a standard for ascertaining the requisite degree, and one of ordinary skill in the art would not be reasonably apprised of the scope of the invention. The metes and bounds of what constitutes “cryptographically bound” is not discernible because it is not a term of the art, there is no standard for ascertaining what being “cryptographically bound” actually means or comprises, how such a cryptographic binding process is performed, and only the desired result is provided in the claims without any further explanation within the remainder of the claim or the originally filed disclosure.
Claims 1, 6, and 12 recite the limitation "the corresponding total public key" in lines 25 and 30, lines 32 and 37, and lines 21 and 28 respectively. There is insufficient antecedent basis for this limitation in the claim.
Respective dependent claims fall together accordingly.
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) 1-21 are rejected under 35 U.S.C. 103 as being unpatentable over Grubin et. al. (US Patent US 10,263,778 B1) hereinafter Grubin in view of Basin; Yuri (US Publication No. US 2017/0126642 A1) hereinafter Basin, and further in view of Kresina; Roman (US Patent US 8,046,579 B2) hereinafter Kresina.
Regarding Claims 1, 6, and 12:
Claim 1. Grubin discloses a system for generating a digital signature, the system including at least one computing device comprising (Grubin Fig. 1-2, Col. 3 lines 48-56): a first backend server (Grubin Fig. 4-5 cluster server 504, Col. 3 lines 28-30 and 36-46); a second backend server (Grubin Fig. 4-5 cluster server 504, Col. 3 lines 28-30 and 36-46; Fig. 1 cluster servers 118, 120 and 122, Col. 6 lines 47-48, 53-57 and 67 through Col. 7 lines 1-5 HSM, hardware security module, clusters may include multiple HSM servers connected to multiple HSMs); and a frontend server configured to: receive a signature request from a remote application server (Grubin Fig. 6 Cluster Client request reception 602, Col. 16 lines 30-33), and is used to by the frontend server to route the signature request, … and is used by the frontend server to route the signature request (Grubin Fig. 6 604 and 606 particular HSM preferred to fulfill task, Col. 16 lines 46-60)… forward the signature request to the first backend server that corresponds to the first server identifier (Grubin Fig. 6 604 and 606 particular HSM preferred to fulfill task, Col. 16 lines 46-60); … and forward the signature request to the second backend server that corresponds to the second server identifier (Grubin Fig. 6 604 and 606 particular HSM preferred to fulfill task, Col. 16 lines 46-60); and forward a second signature to the application server (Grubin Fig. 6 604 and 606 particular HSM preferred to fulfill task, Col. 16 lines 46-60), wherein the first and second backend servers are each configured to (Grubin Fig. 6 HSM cluster server): forward the signature request to a plurality of remote security devices associated with the corresponding total public key (Grubin Fig. 6 608 request forwarded to plurality of HSMs in the cluster, Col. 9 lines 1-11 cluster service forwards cryptographic requests from applications to HSMs); receive a first signature from each of the plurality of remote security devices (Grubin Col. 3 lines 48-56 HSM returns result to cluster server); … and forward the second signature to the frontend server (Grubin Fig. 6 step 614 returns results to HSM cluster client, Col. 17 lines 16-19).
Grubin does not disclose a system for generating a digital signature wherein the signature request including a first total public key with a cryptographically embedded first server identifier and a second total public key with a cryptographically embedded second server identifier, wherein the first identifier is embedded during key generation such that it is cryptographically bound to the first total public key and verifiable by a certificate authority, is unique to the first backend server, and the second server identifier is embedded during key generation such that it is cryptographically bound to the second total public key and verifiable by a certificate authority, is unique to the second backend server; extract the embedded first server identifier from the first total public key; … in response to determining that the first backend server is unavailable, extract the embedded second server identifier from the second total public key … generate a combined signature based on the first signatures; generate the second signature based on the combined signature and a finalizing key, the finalizing key being generated based on the server identifier of the backend server extracted from the corresponding total public key.
Basin teaches a system for generating a digital signature wherein the signature request including a first total public key with a cryptographically embedded first server identifier (Basin Fig. 2 Smartkey components 225, 260, 235 teaches embedding; [0061]; [0170], Fig. 25, 31, [0377]) and a second total public key with a cryptographically embedded second server identifier (Basin Fig. 2 Smartkey components 225, 260, 235 teaches embedding; [0061]; [0170], Fig. 25, 31, [0377]), wherein the first identifier is embedded during key generation such that it is cryptographically bound to the first total public key and verifiable by a certificate authority, is unique to the first backend server, and the second server identifier is embedded during key generation such that it is cryptographically bound to the second total public key and verifiable by a certificate authority, is unique to the second backend server (Basin Fig. 2 Smartkey components, [0061], [0071-0076]; [0170], Fig. 25, 31, [0259], [0360], [0377]); extract the embedded first server identifier from the first total public key (Basin Fig. 2 Smartkey components 225, 260, 235 teaches embedding; [0061]); … extract the embedded second server identifier from the second total public key (Basin Fig. 2 Smartkey components 225, 260, 235; [0061]) … generate a combined signature based on the first signatures (Basin Fig. 2, [0071-0076], [0097-0098], [0107-0109], [0116] “may be attached to the signed characteristic within a smartkey, or placed separately in the smartkey. Preferably a signature characteristic is attached. For example, an attached signature characteristic for a PID with URN characteristic may be formed as follows {“PID”: “bytes of PID with URN”, “Signature”:“<bytes of signature>”}”); generate the second signature based on the combined signature and a finalizing key (Basin [0107-0109], [0116] “may be attached to the signed characteristic within a smartkey, or placed separately in the smartkey. Preferably a signature characteristic is attached. For example, an attached signature characteristic for a PID with URN characteristic may be formed as follows {“PID”: “bytes of PID with URN”, “Signature”:“<bytes of signature>”}”), the finalizing key being generated based on the server identifier of the backend server extracted from the corresponding total public key (Basin [0107-0109], [0116] “may be attached to the signed characteristic within a smartkey, or placed separately in the smartkey. Preferably a signature characteristic is attached. For example, an attached signature characteristic for a PID with URN characteristic may be formed as follows {“PID”: “bytes of PID with URN”, “Signature”:“<bytes of signature>”}”, [0449] “A key encrypting key ID may include a Uniform Resource Name (URN) assigned by the Key Provider.”).
Basin does not teach a system for generating a digital signature that takes action in response to determining that the first backend server is unavailable.
Kresina teaches a system for generating a digital signature that takes action in response to determining that the first backend server is unavailable (Kresina Fig. 10 server machines 1010, 1015, 1020, 1025 for redundancy; Col 12 lines 45-60 secure communications use different keys to communicate to different redundant servers).
It would have been obvious to one having ordinary skill in the art at before the time the invention was effective filed to combine the digital signature system disclosed by Grubin with the key generation, management, and embedding taught by Basin.
The motivation for this combination would be to improve the security and integrity of the keys used by Grubin. The importance of key confidentiality is discussed by Grubin in Col. 16 lines 46-60. Grubin recognizes that a particular server may be desired in order to fulfill the request issued to the system. In Col. 4 lines 20-32 Grubin discloses a divergent method of key generation that still has identifiers involved in the generation process so that the HSM that created the key can be identified within the cluster by the cluster server or cluster client.
Additionally, it would have been obvious to one having ordinary skill in the art at before the time the invention was effective filed to combine the digital signature system disclosed by Grubin with the key generation, management, and embedding taught by Basin and further with the implementation of redundancy as taught by Kresina. The motivation for this combination would be to ensure redundancy and availability of the system as a whole as recognized by Grubin in Col. 2 lines 51-55.
Regarding claims 6 and 12, the claims recite substantially the same content as claim 1 and are rejected by the rationales set forth for claim 1. As an aside, the system recited in claim 6 can be mapped to Grubin Fig. 1-2 and Col. 3 lines 48-56; the method recited in claim 12 can be mapped to Grubin Fig. 1-2, Col. 3 lines 48-56, and Col. 32 lines 16-19.
Regarding Claims 2, 7, and 13:
Claim 2. The combination of Grubin, Basin, and Kresina further discloses the system of claim 1 (Grubin Fig. 1-2, Col. 3 lines 48-56), wherein the combined signature is generated using a composite signature function (Basin [0061-0076] smartkey and characteristic signatures can be created in a composition with numerous different key elements, Fig. 2, 6-9).
Regarding claims 7 and 13, the claims recite substantially the same content as claim 2 and are rejected by the rationales set forth for claim 2.
Regarding Claims 3, 8, and 14:
Claim 3. The combination of Grubin, Basin, and Kresina further discloses the system of claim 1 (Grubin Fig. 1-2, Col. 3 lines 48-56), wherein the combined signature is generated using a splitkey combiner function (Basin [0065-0075], Fig. 2, 6-9 combined key plus identifying data scheme).
Regarding claims 8 and 14, the claims recite substantially the same content as claim 3 and are rejected by the rationales set forth for claim 3.
Regarding Claims 4, 9, and 15:
Claim 4. The combination of Grubin, Basin, and Kresina further discloses the system of claim 1 (Grubin Fig. 1-2, Col. 3 lines 48-56), wherein the frontend server determines that the first backend server is unavailable when the frontend server fails to receive an acknowledgement from the first backend server in response to forwarding the signature request (Kresina claim 16, Col. 10 lines 58 through Col. 11 line 4, Col. 11 lines 14-26, Fig. 10).
Regarding claims 9 and 15, the claims recite substantially the same content as claim 4 and are rejected by the rationales set forth for claim 4.
Regarding Claims 5, 10, and 16:
Claim 5. The combination of Grubin, Basin, and Kresina further discloses the system of claim 1 (Grubin Fig. 1-2, Col. 3 lines 48-56), wherein the frontend server determines that the first backend server is unavailable when the frontend server fails to receive the second signature within a threshold period of time (Kresina claim 16, Col. 10 lines 58 through Col. 11 line 4, Col. 11 lines 14-26, Fig. 10).
Regarding claims 10 and 16, the claims recite substantially the same content as claim 5 and are rejected by the rationales set forth for claim 5.
Regarding Claim 11:
The combination of Grubin, Basin, and Kresina further discloses the system of claim 6 (Grubin Fig. 1-2, Col. 3 lines 48-56), wherein the certificate authority is further configured to, in response to determining that one of the first or second backend servers is not available, generate a third certificate associated with a third backend server based on the first certificate and the second certificate (Kresina claim 16, Col. 10 lines 58 through Col. 11 line 4, Col. 11 lines 14-26, Fig. 10, Col. 7 lines 40-53 generated certificate level may be root, middle, or device).
Regarding Claim 17:
The combination of Grubin, Basin, and Kresina further discloses the system of claim 1 (Grubin Fig. 1-2, Col. 3 lines 48-56), wherein the backend server generates the combined signature using the composite signature function (Basin [0061-0076] smartkey and characteristic signatures can be created in a composition with numerous different key elements, Fig. 2, 6-9), which incorporates the first signature received from one of the security devices modified by a public modulus of the first public key (Basin [0109-0111] each characteristic in the composition is authenticated using X.509 certificates; [0222-0223] public modulus is inherent to the RSA algorithm), and incorporates the first signature received from another one of the security devices modified by a second public modulus of the second public key as components of the combined signature (Basin [0109-0111] each characteristic in the composition is authenticated using X.509 certificates; [0222-0223] public modulus is inherent to the RSA algorithm).
Regarding Claim 18:
The combination of Grubin, Basin, and Kresina further discloses the system of claim 1 (Grubin Fig. 1-2, Col. 3 lines 48-56), wherein the backend server generates the combined signature using the splitkey combiner function (Basin [0065-0075], Fig. 2, 6-9 combined key plus identifying data scheme), which incorporates the first signature received from at least two of the security devices as components of the combined signature in additive or multiplicative sharing (Basin [0097] “Each PID within a smartkey may be signed using the public key of a PID than may be present for each user of the smartkey. The combined signatures may be used by a system such as a decryption application to verify the integrity of the PID information in the smartkey. Other characteristics of a smartkey may be digitally signed.”).
Regarding Claim 19:
The combination of Grubin, Basin, and Kresina further discloses the system of claim 1 (Grubin Fig. 1-2, Col. 3 lines 48-56), wherein the at least one computing device includes a first computing device that supports the first backend server (Grubin Col. 3 line 30-46), and a second computing device that supports the second backend server (Grubin Col. 3 line 30-46), wherein the first backend server is isolated from the second backend server in a breach event by a virtual machine (Grubin Col. 31 line 25-47 the devices in the environment can reside in a variety of locations such as local to the computer itself or remote from the computers, Col. 35 line 23-33, Col. 28 lines 61-63.
Regarding Claim 20:
The combination of Grubin, Basin, and Kresina further discloses the system of claim 1 (Grubin Fig. 1-2, Col. 3 lines 48-56), wherein the first or second backend server generates a composite public key using at least two independent public keys (Basin [0061-0076] smartkey can be created in a composition with numerous different key elements, Fig. 2, 6-9), and then generates the first or second total public key based on the composite public key (Basin [0061-0076] smartkey can be created in a composition with numerous different key elements, Fig. 2, 6-9).
Regarding Claim 21:
The combination of Grubin, Basin, and Kresina further discloses the system of claim 1 (Grubin Fig. 1-2, Col. 3 lines 48-56), wherein the first server identifier is embedded in the first total public key as part of the key generation process (Basin [0061-0076] smartkey can be created in a composition with numerous different key elements including URNs, Fig. 2, 6-9), such that the first server identifier is cryptographically bound to the first total public key and verifiable by a certificate authority (Basin [0259] “The public key of the pair is associated with a digital certificate, or other form of credential to uniquely identify an individual or organization. The digital certificate is used to bind the identity of the individual or organization with the public encryption key. The individual or organization whose identity is bound to the digital certificate is considered to be the owner of the key. The owner of the key is the individual or organization that is authorized to use the key for decrypting encrypted data. The private key of the pair is held in confidence by the owner. When encrypting data intended for the owner of a key, the public key is used within the encryption process to encrypt data for that owner. The data may only be decrypted by the owner using his/her private key.”; [0360]); and the second server identifier is embedded in the second total public key as part of the key generation process (Basin [0061-0076] smartkey can be created in a composition with numerous different key elements including URNs, Fig. 2, 6-9), such that the second server identifier is cryptographically bound to the second total public key and verifiable by a certificate authority (Basin [0259] “The public key of the pair is associated with a digital certificate, or other form of credential to uniquely identify an individual or organization. The digital certificate is used to bind the identity of the individual or organization with the public encryption key. The individual or organization whose identity is bound to the digital certificate is considered to be the owner of the key. The owner of the key is the individual or organization that is authorized to use the key for decrypting encrypted data. The private key of the pair is held in confidence by the owner. When encrypting data intended for the owner of a key, the public key is used within the encryption process to encrypt data for that owner. The data may only be decrypted by the owner using his/her private key.”; [0360]).
Conclusion
The prior art made of record in the submitted PTO-892 Notice of References Cited and not relied upon is considered pertinent to applicant’s disclosure.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MIGUEL A LOPEZ whose telephone number is (703)756-1241. The examiner can normally be reached 8: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, Jorge Ortiz-Criado can be reached on 5712727624. 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.
/M.A.L./ Examiner, Art Unit 2496 /JORGE L ORTIZ CRIADO/Supervisory Patent Examiner, Art Unit 2496
Prosecution Insights