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 .
Response to Arguments
Applicant’s arguments, see page 8, filed 09/08/2025, with respect to the objection to claim 1 have been fully considered. The objection of claim 1 has been withdrawn.
Applicant's arguments, see pages 8-12, filed 09/08/2025, with respect to the rejection of claims 1-20 under 35 U.S.C. § 103 have been fully considered but they are not persuasive.
Applicant first attests that the URN taught in Basin is not described as being unique to a particular server that processes cryptographic/signature requests, but rather as a way to identify and locate keys or key providers in a networked environment, and further appears to attempt to quote Basin by stating “For example, Basin states: ‘A URN may be used to locate a PID or SID. A URN provides a method for searching to locate wither [sic] a PID or a SID.’ ‘The URN may be used to identify a key provider, not a specific server for routing signature requests, and the URN is not used in the manner claimed’” (see Applicant’s remarks, page 9).
The Examiner respectfully disagrees.
First and foremost, the alleged quote from the Basin reference does not seem to appear anywhere within the document. Specifically, the alleged quote “The URN may be used to identify a key provider, not a specific server for routing signature requests, and the URN is not used in the manner claimed” is not found within the Basin reference. Additionally, Applicant admits that the URN may be used to identify a PID, a SID, or a Key Provider. Basin Fig. 25, 31, and paragraph [0377] explicitly show that a key provider may be implemented as a server (Basin [0377] “In a preferred embodiment, a Key Provider may reside on a server located in the Cloud as is utilized by Cloud Computing” emphasis added, see also [0220] “Other platforms on which this method may be enabled include personal computers, servers, physical or virtual server appliances, virtual machines, laptops, mobile devices, smart phones, tablets, optical or magnetic disk drives, …”). Therefore, a URN being shown to identify a particular key provider, that may comprise a server, renders obvious the broadest reasonable interpretation of the claim at issue.
Applicant next attests that the server identifier in amended claim 1 is different than what is described in Basin, because the claimed server identifier is “cryptographically embedded”, and that the identifier is “verifiably unique”, and that there is allegedly “no disclosure in Basin of using a URN to direct a request to a particular server based on an identifier embedded in a key!”.
The Examiner respectfully disagrees.
First, the limitation “cryptographically embedded” was previously rejected under 35 U.S.C. § 112(b) in the Non-Final Rejection mailed 05/16/2024 (the first action on the merits), and will be reinstated below; and the limitation “verifiably unique” recites new matter and will be rejected on the ground that it recites elements without support in the original disclosure. The limitation of forwarding a request to a particular server was mapped to the previously presented Grubin reference. In response to applicant's arguments against the references individually, one cannot show nonobviousness by attacking references individually where the rejections are based on combinations of references. See In re Keller, 642 F.2d 413, 208 USPQ 871 (CCPA 1981); In re Merck & Co., 800 F.2d 1091, 231 USPQ 375 (Fed. Cir. 1986). Furthermore, paragraph [0170] of Basin explicitly teaches “The Key Provider Name may be a unique identifier that is used to identify a specific Key Provider. The Key Provider Data 1850 may be a URN that includes network address information that allows a network connection to be established with the key provider identified by the Key Provider Name 1840”. Applicant on page 10 admits that the URN taught by Basin may be used to identify key providers and that a URN may be unique to a key provider, and as discussed above, key providers may be implemented as servers. Lastly, the amended limitation “cryptographically embedded” appears to introduce new written description issues, and the amended limitation “verifiably unique” appears to raise new indefiniteness issues and will be presented in the rejection below.
Applicant then attests that Basin’s URN is not embedded in the key as recited in claim 1, and that the URN of Basin is not used for failover or redundancy or for failover or redundancy in server selection or routing.
The Examiner respectfully disagrees.
The limitation of forwarding a request to a particular server was mapped to the previously presented Grubin reference. In response to applicant's arguments against the references individually, one cannot show nonobviousness by attacking references individually where the rejections are based on combinations of references. See In re Keller, 642 F.2d 413, 208 USPQ 871 (CCPA 1981); In re Merck & Co., 800 F.2d 1091, 231 USPQ 375 (Fed. Cir. 1986). Secondly, Applicant’s arguments here amount to arguing over an intended use. In response to applicant's argument that the URN of Basin is not allegedly used for failover or redundancy, a recitation of the intended use of the claimed invention must result in a structural difference between the claimed invention and the prior art in order to patentably distinguish the claimed invention from the prior art. If the prior art structure is capable of performing the intended use, then it meets the claim. Applicant’s further arguments that the mapping of Basin’s URN are overly broad and unsupported are further unpersuasive, as the Applicant already admitted that the URN may used to identify a unique key provider (which may be a server), Applicant already admits that Basin teaches embedding information in keys (thus, embedding the URN in the smart key renders obvious the claim limitations at issue), and the argued “dynamic server selection or redundancy” or “specific use of a server identifier” are further arguments regarding intended use.
Applicant then argues that claims 6 and 12 allegedly overcome the presented prior art for the reasons set forth for claim 1. Since applicant does not give any further explanation as to how the previously cited art differentiates from the claimed invention other than association with an allegedly allowable claim, the examiner defers to the rejection below as a response to this argument.
Applicant lastly alleges that new claim 21 provides cryptographic binding during key generation that is not provided by the cited references.
The Examiner respectfully submits that the entirety of the claim comprises new matter, and defers to the rejection under 35 U.S.C. § 112(a) and under 35 U.S.C. § 103 as a full response to this argument. The Examiner respectfully notes Applicant’s argument “the cited references do not disclose or suggest a certificate authority verifying that a server identifier is cryptographically bound to a public key, as opposed to simply issuing a certificate for a public key. Lastly, regarding enhanced security and integrity, by cryptographically binding the server identifier to the public key, the system ensures that the association cannot be tampered with or spoofed, and that the certificated authority can independently verify the association. This provides a level of assurance or verifiability that is not offered in the cited references. As can be seen, the embedding of the server identifier in claim 21 is performed using a particular cryptographic technique, and the identifier is not merely a label or metadata”; and the Examiner respectfully requests where such a binding technique may be found in the originally filed disclosure and how the inventor intended to achieve such desired results within the originally filed disclosure.
Claim Objections
Claim 1 is objected to because of the following informalities:
Claim 1 lines 22 and 27 recite “the total public key” and it is unclear if it’s referring to the first total public key or the second total public key.
Appropriate correction is required.
Drawings
Figure 2 should be designated by a legend such as --Prior Art-- because only that which is old is illustrated. See MPEP § 608.02(g). See paragraph [0034] of originally filed disclosure which states in part, “FIG. 2 illustrates a system that employs traditional asymmetric cryptography using a single private key, and generally, the system to verify a signature. A common asymmetric cryptography system (sometimes referred to as a "public key cryptosystem") used for digital signatures is Rivest-Shamir- Adleman (RSA). As illustrated in FIG. 2, the RSA cryptosystem uses four functions”. Corrected drawings in compliance with 37 CFR 1.121(d) are required in reply to the Office action to avoid abandonment of the application. The replacement sheet(s) should be labeled “Replacement Sheet” in the page header (as per 37 CFR 1.84(c)) so as not to obstruct any portion of the drawing figures. If the changes are not accepted by the examiner, the applicant will be notified and informed of any required corrective action in the next Office action. The objection to the drawings will not be held in abeyance.
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 limitations “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 verifiably unique to the first backend server… and the second server identifier is verifiably unique to the second backend server”. The originally filed disclosure is silent with respect to any recitation of a cryptographic embedding technique regarding server identifiers, and is silent with respect to the server identifiers being “verifiably unique” or recite any process that now verifies that the server identifier are unique. The original disclosure supports unique server identifiers as previously recited, but does not appear to recite any verification process of verifying that such identifiers are “verifiably unique”. This amended claim limitation, “verifiably unique” 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).
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.
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 “verifiably unique” in claims 1, 6, and 12 is a relative term which renders the claim indefinite. The term “verifiably unique” 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 term unique is given its plain meaning and is a definite term, however it has been amended to now be modified by the relative term “verifiably” to now be verifiably unique. The specification does not provide a standard for ascertaining the requisite degree for determining what makes the identifier verifiably unique as opposed to unique.
In addition, the recited function of being “verifiably unique” does not follow from the structure recited in the claim, so it is unclear whether the function requires some other structure or is simply a result of operating the “device” in a certain manner. Thus, one of ordinary skill in the art would not be able to draw a clear boundary between what is and is not covered by the claim. See MPEP 2173.05(g) for more information.
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 rout 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 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 verifiably unique to the first backend server, and the second server identifier is verifiably 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 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 verifiably unique to the first backend server, and the second server identifier is verifiably unique to the second backend server (Basin Fig. 2 Smartkey components, [0061], [0071-0076]; [0170], Fig. 25, 31, [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-0108] key encrypting key); generate the second signature based on the combined signature and a finalizing key (Basin [0107-0108] key encrypting key), the finalizing key being generated based on the server identifier of the backend server extracted from the total public key (Basin [0107-0108] key encrypting key, [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. Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a). A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action. 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