DETAILED ACTION
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
In response to the restriction requirement mailed on 10/07/2025, the Applicant has elected Group I, claims 1-8 and 16, without traverse, for prosecution. Claims 9-11 of Group II and claims 12-15 of Group III are currently withdrawn from consideration. Claims 1-8 and 16 have been examined and are pending in this application.
Priority
Acknowledgment is made of Applicant’s claim for foreign priority under 35 U.S.C. 119 (a)-(d) to parent Application No.: IL294869, filed on 07/19/2022.
Information Disclosure Statement
The information disclosure statements (IDS), submitted on 07/30/2025 and 08/03/2023, are in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statements are being considered by the examiner.
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.
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
Claim(s) 1-2 and 4 are rejected under 35 U.S.C. 103 as being unpatentable over Bacon et al. (US 11,601,288; Hereinafter “Bacon”) in view of Tate (US 2022/0116370).
Regarding claim 1, Bacon teaches a method of securing one or more defined artifacts, or one or more secure connections (Bacon: Col. 19, Lines 36-38, For obtaining a signed router web UI security certificate 140 for establishing the secure connection with the client), comprising:
generating a single-purpose public key and private key combination (Bacon: Col. 19, Lines 36-44, For obtaining a signed router web UI security certificate 140 for establishing the secure connection with the client, the router web server 132 may generate a router web UI security CSR (e.g., create a public and private key pair, add required and optional fields, add key usage details, and add any extensions to the certificate request) and send the CSR, including the created public key, to the local SCS 150 (represented as communication 224) for signing.);
sending the single-purpose public key to a certificate authority (Bacon: Col. 19, Lines 36-44, . For obtaining a signed router web UI security certificate 140 for establishing the secure connection with the client, the router web server 132 may generate a router web UI security CSR (e.g., create a public and private key pair, add required and optional fields, add key usage details, and add any extensions to the certificate request) and send the CSR, including the created public key, to the local SCS 150 (represented as communication 224) for signing. Col. 6, Lines 17-29, According to an example aspect, the router web server 132 may further provide information about the user's computing device 102a to the remote SCS 110 that can be utilized to generate the router web UI security certificate 140 that is particular to the user's computing device 102a. In an example aspect, computing device 102a information may be included in an extension in the router web UI security certificate 140. For example, the computing device 102a information may include information associated with the computer's operating system (OS), web browser 106 type, MAC address (which may include an Organization Unique Identifier (OUI), IP address, BLUETOOTH® address, cipher type, hash type, etc. Col. 18, Lines 1-25);
receiving from the certificate authority a single-purpose certificate that includes fields storing an identity of a signer, the set of hashes, metadata identifying the hashed unique information, and the single-purpose public key, wherein the single-purpose certificate is signed with a certificate authority private key (Bacon: Col. 2, Lines 66-67 to Col. 3, Lines 1-4, signs a router web UI security certificate for the router web UI, and then passes the signed web UI security certificate to the router web server. The router may pass the signed router web UI security certificate to the client to establish a secure channel for enabling the client to access the router web UI via the secure channel. Col. 6, Lines 38-50, Based on the CSR, the web UI security certificate 140 may comprise a set of fields that include data, such as a subject (i.e., the entity to which the certificate is issued), validity dates (i.e., when the certificate is valid), issuer (the entity that issued the certificate), the router web server's public key, and a signature. According to an aspect, the signature is a hash that is encrypted with a private key created by the remote SCS 110 using the key usage details included in the CSR. As will be described in further detail below, the web browser 106 is configured to recognize the remote SCS 110 as a trusted CA and comprises or has access to the public key of the remote SCS 110 (e.g., that corresponds to the SCS's private key).); and
publishing or sending the single-purpose certificate to a verifier, and, with the single- purpose certificate, at least one of (1) establishing one or more secure connections with the verifier or (2) sending the one or more artifacts to the verifier (Bacon: Col. 18, Lines 30-43, the router web server 132 may provide the signed router web UI security certificate 140 to the computing device 102. The computing device 102 may verify the router web UI security certificate 140 (e.g., verify the remote SCS's signature, verify the chain of trust, encrypt a premaster secret with the router web server's public key, which if the router web server 132 is able to successfully decode the premaster secret, verifies that the router web server knows the private key corresponding to the public key included in the router web UI security certificate) and complete the handshake operation (as described above with reference to FIG. 1A) for establishing a secure connection with the router web server 132.).
Bacon does not explicitly teach creating a set of hashes of unique information characterizing one or more specific connections or artifacts; and the set of hashes to a certificate authority.
In an analogous art, Tate teaches creating a set of hashes of unique information characterizing one or more specific connections or artifacts (Tate: Para. [0103], In addition, the attribute information of the device 100 included in the digital certificate 176 may be encrypted by a known irreversible cryptographic hash function or the like.);
sending the single-purpose public key and the set of hashes to a certificate authority (Tate: Para. [0103], As the attribute information of the device 100, for example, the version information of the OS 160 of the device 100 or the communication processing program 170 and the serial number of the hardware (for example, a processor or a storage) forming the device 100 can be used. In this case, the device 100 may transmit the attribute information of the device 100 to the certificate authority 200 when transmitting the public key 174 and the certificate signing request. In addition, the attribute information of the device 100 included in the digital certificate 176 may be encrypted by a known irreversible cryptographic hash function or the like.).
It would have been obvious to a person having ordinary skill in the art, before the effective filing date of the claimed invention, to combine the teachings of Tate with the system and method of Bacon to include creating a set of hashes of unique information characterizing one or more specific connections or artifacts; and the set of hashes to a certificate authority because this functionality improves confidentiality and provides the ability to authenticate that the digital certificate has been issued in response to the certificate signing request from the device itself (Tate: Para. [0103], [0042]).
Regarding claim 2, Bacon, in combination with Tate, teaches the method of claim 1, wherein the signer is a server, the verifier is a client, the method comprises establishing a secure connection between the server and the client under specific conditions, and the set of hashes includes a hash of unique information regarding the secure connection (Bacon: Col. 18, Lines 30-43, the router web server 132 may provide the signed router web UI security certificate 140 to the computing device 102. The computing device 102 may verify the router web UI security certificate 140 (e.g., verify the remote SCS's signature, verify the chain of trust, encrypt a premaster secret with the router web server's public key, which if the router web server 132 is able to successfully decode the premaster secret, verifies that the router web server knows the private key corresponding to the public key included in the router web UI security certificate) and complete the handshake operation (as described above with reference to FIG. 1A) for establishing a secure connection with the router web server 132. Tate: Para. [0008], a data transmission method in a network to which a plurality of devices are connected is provided. Para. [0014]-[0016], Para. [0012], a step of determining an IP address of the device itself based on a hash value calculated from the public key according to a hash function; a step of acquiring a digital certificate associated with the public key from a certificate authority; and a step of transmitting the public key and the digital certificate to another device. [Secure connection information may include attribute information such as serial number, MAC address, IP address, OS version] Para. [0042], More specifically, the “authenticated IP address” means an IP address that is generated by an irreversible cryptographic hash function and is directly or indirectly authenticated by the certificate authority (details thereof will be described later). By using such an “authenticated IP address”, it can be guaranteed that the IP address used by each device 100 for data communication is not spoofed.).
Regarding claim 4, Bacon, in combination with Tate, teaches the method of claim 1, wherein the sending step further comprises sending additional metadata to the certificate authority, said additional metadata including at least one of an identity of the one or more artifacts, an identity of a signing entity, and a time of transmission, and wherein the single purpose certificate comprises fields including said metadata (Bacon: Col. 14, Lines 3-12, According to an aspect, the remote SCS 110 may be configured to validate the identity of the router web server 132 based on identifying information (e.g., IP address, MAC address, or other unique identifiers) of the home router 104 stored in the ISP billing system 138. The remote SCS 110 may be configured to communicate with the billing system 138 of the user's ISP, which stores information about services and products (e.g., home router 104) subscribed to by the user.) Col. 14, Lines 17-35, According to an example aspect, the router web server 132 may further provide information about the user's computing device 102a to the remote SCS 110 that can be utilized to generate the router web UI security certificate 140 that is particular to the user's computing device 102a. In an example aspect, computing device 102a information may be included in an extension in the router web UI security certificate 140. For example, the computing device 102a information may include information associated with the computer's operating system (OS), web browser 106 type, MAC address (which may include an Organization Unique Identifier (OUI), IP address, BLUETOOTH® address, cipher type, hash type, etc. In some examples, at least a portion of the computing device 102 information may be provided to the home router 104 by the user's computing device 102 as part of a handshake operation when the user's computing device requests a secure connection to the router web server 132, or the information may be provided in a separate transaction.).
Claim(s) 3, 7, and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Bacon et al. (US 11,601,288; Hereinafter “Bacon”) in view of Tate (US 2022/0116370) in view of Suarez (US 2008/0016357).
Regarding claim 3, Bacon, in combination with Tate, teaches the method of claim 1. Bacon, in combination with Tate, does not explicitly teach wherein the method comprises publishing or sending an artifact, and the set of hashes includes a hash of the artifact.
In an analogous art, Suarez teaches wherein the method comprises publishing or sending an artifact, and the set of hashes includes a hash of the artifact (Claim 6, obtaining from a certificate authority a digital certificate by a user having a user private key and a user public key, hashing an artifact using a hashing algorithm to generate a hash, encrypting the hash with the user private key, attaching the encrypted hash to the signed artifact, attaching the digital certificate to the signed artifact. Claim 7, herein the artifact is a document, data, an image, music, a file, or other information).
It would have been obvious to a person having ordinary skill in the art, before the effective filing date of the claimed invention, to combine the teachings of Suarez with the system and method of Bacon and Tate to include wherein the method comprises publishing or sending an artifact, and the set of hashes includes a hash of the artifact because this functionality provides improved securing of a digital signature by use of a short-lived private key (Suarez: Para. [0001]).
Regarding claim 7, Bacon, in combination with Tate, teaches the method of claim 1. Bacon, in combination with Tate, does not explicitly teach further comprising revoking the single-purpose certificate following the establishing of the one or more secure connections or transmitting of the one or more artifacts.
In an analogous art, Suarez teaches further comprising revoking the single-purpose certificate following the establishing of the one or more secure connections or transmitting of the one or more artifacts (Suarez: Para. [0027], As a further safeguard, the digital certificate could be revoked and listed on a Certificate Revocation List (CRL) or Online Certificate Status Protocol (OSCP) server or any other form of certificate revocation.).
It would have been obvious to a person having ordinary skill in the art, before the effective filing date of the claimed invention, to combine the teachings of Suarez with the system and method of Bacon and Tate to include further comprising revoking the single-purpose certificate following the establishing of the one or more secure connections or transmitting of the one or more artifacts because this functionality provides improved securing of a digital signature by use of a short-lived private key that is revocable (Suarez: Para. [0001]).
Regarding claim 16, Bacon teaches a method of generating and revoking a signature (Bacon: Col. 19, Lines 36-38, For obtaining a signed router web UI security certificate 140 for establishing the secure connection with the client), comprising:
generating a single-purpose public key and private key combination (Bacon: Col. 19, Lines 36-44, For obtaining a signed router web UI security certificate 140 for establishing the secure connection with the client, the router web server 132 may generate a router web UI security CSR (e.g., create a public and private key pair, add required and optional fields, add key usage details, and add any extensions to the certificate request) and send the CSR, including the created public key, to the local SCS 150 (represented as communication 224) for signing.);
sending the single-purpose public key to a certificate authority (Bacon: Col. 19, Lines 36-44, . For obtaining a signed router web UI security certificate 140 for establishing the secure connection with the client, the router web server 132 may generate a router web UI security CSR (e.g., create a public and private key pair, add required and optional fields, add key usage details, and add any extensions to the certificate request) and send the CSR, including the created public key, to the local SCS 150 (represented as communication 224) for signing. Col. 6, Lines 17-29, According to an example aspect, the router web server 132 may further provide information about the user's computing device 102a to the remote SCS 110 that can be utilized to generate the router web UI security certificate 140 that is particular to the user's computing device 102a. In an example aspect, computing device 102a information may be included in an extension in the router web UI security certificate 140. For example, the computing device 102a information may include information associated with the computer's operating system (OS), web browser 106 type, MAC address (which may include an Organization Unique Identifier (OUI), IP address, BLUETOOTH® address, cipher type, hash type, etc. Col. 18, Lines 1-25);
receiving from the certificate authority a single-purpose certificate that includes fields storing an identity of a signer, the set of hashes, metadata identifying the hashed unique information, and the single-purpose public key, wherein the single-purpose certificate is signed with a certificate authority private key (Bacon: Col. 2, Lines 66-67 to Col. 3, Lines 1-4, signs a router web UI security certificate for the router web UI, and then passes the signed web UI security certificate to the router web server. The router may pass the signed router web UI security certificate to the client to establish a secure channel for enabling the client to access the router web UI via the secure channel. Col. 6, Lines 38-50, Based on the CSR, the web UI security certificate 140 may comprise a set of fields that include data, such as a subject (i.e., the entity to which the certificate is issued), validity dates (i.e., when the certificate is valid), issuer (the entity that issued the certificate), the router web server's public key, and a signature. According to an aspect, the signature is a hash that is encrypted with a private key created by the remote SCS 110 using the key usage details included in the CSR. As will be described in further detail below, the web browser 106 is configured to recognize the remote SCS 110 as a trusted CA and comprises or has access to the public key of the remote SCS 110 (e.g., that corresponds to the SCS's private key).).
Bacon does not explicitly teach creating a set of hashes of unique information characterizing one or more specific connections or artifacts; and the set of hashes to a certificate authority.
In an analogous art, Tate teaches creating a set of hashes of unique information characterizing one or more specific connections or artifacts (Tate: Para. [0103], In addition, the attribute information of the device 100 included in the digital certificate 176 may be encrypted by a known irreversible cryptographic hash function or the like.);
sending the single-purpose public key and the set of hashes to a certificate authority (Tate: Para. [0103], As the attribute information of the device 100, for example, the version information of the OS 160 of the device 100 or the communication processing program 170 and the serial number of the hardware (for example, a processor or a storage) forming the device 100 can be used. In this case, the device 100 may transmit the attribute information of the device 100 to the certificate authority 200 when transmitting the public key 174 and the certificate signing request. In addition, the attribute information of the device 100 included in the digital certificate 176 may be encrypted by a known irreversible cryptographic hash function or the like.).
It would have been obvious to a person having ordinary skill in the art, before the effective filing date of the claimed invention, to combine the teachings of Tate with the system and method of Bacon to include creating a set of hashes of unique information characterizing one or more specific connections or artifacts; and the set of hashes to a certificate authority because this functionality improves confidentiality and provides the ability to authenticate that the digital certificate has been issued in response to the certificate signing request from the device itself (Tate: Para. [0103], [0042]).
Bacon, in combination with Tate, does not explicitly teach signing an artifact with the private key; and revoking the single-purpose certificate.
In an analogous art, Suarez teaches signing an artifact with the private key (Suarez: Para. [0020], when a user 15 wants to sign an artifact or when a user is presented with an artifact for signing by the webserver 30, for example, the user 15 uses it private key to digitally sign the artifact. The act of signing comprises hashing the artifact using the hashing algorithm and encrypting the hash with the user private key.); and
revoking the single-purpose certificate (Suarez: Para. [0027], As a further safeguard, the digital certificate could be revoked and listed on a Certificate Revocation List (CRL) or Online Certificate Status Protocol (OSCP) server or any other form of certificate revocation.).
It would have been obvious to a person having ordinary skill in the art, before the effective filing date of the claimed invention, to combine the teachings of Suarez with the system and method of Bacon and Tate to include signing an artifact with the private key; and revoking the single-purpose certificate because this functionality provides improved securing of a digital signature by use of a short-lived private key that is revocable (Suarez: Para. [0001]).
Claim(s) 5 is rejected under 35 U.S.C. 103 as being unpatentable over Bacon et al. (US 11,601,288; Hereinafter “Bacon”) in view of Tate (US 2022/0116370) in view of Giffard-Burley et al. (US 2025/0131134; Hereinafter “Giffard”).
Regarding claim 5, Bacon, in combination with Tate, teaches the method of claim 4, and sending the signed set of hashes to the certificate authority for inclusion into the single-purpose certificate (Tate: Para. [0103], As the attribute information of the device 100, for example, the version information of the OS 160 of the device 100 or the communication processing program 170 and the serial number of the hardware (for example, a processor or a storage) forming the device 100 can be used. In this case, the device 100 may transmit the attribute information of the device 100 to the certificate authority 200 when transmitting the public key 174 and the certificate signing request. In addition, the attribute information of the device 100 included in the digital certificate 176 may be encrypted by a known irreversible cryptographic hash function or the like.).
Bacon, in combination with Tate, does not explicitly teach further comprising signing the hashes in the set of hashes using the single-purpose private key.
In an analogous art, Giffard teaches further comprising signing the hashes in the set of hashes using the single-purpose private key (Giffard: Claim 6, wherein the second electronic signature is generated by encrypting the hash value of the document file using a user private key that is a private key of the signatory. Para. [0038]-[0039], Para. [0045], Note that the electronic signature is generated by deriving, that is, calculating, a hash value of target electronic data (signed VC in this case) and using a predetermined encryption key (in this case, a host private key described later) to encrypt the hash value.).
It would have been obvious to a person having ordinary skill in the art, before the effective filing date of the claimed invention, to modify the signed set of hashes being transmitted to the certificate authority for incorporation into a single purpose certificate to include signing the hashes in the set of hashes using the single-purpose private key because such a modification is the result of applying a known technique to a known device ready for improvement to yield predictable results. More specifically, generating the signature by encrypting the hash value of the document file using a private key permits derivation of a hash value of a document and ensures that the document has not been tampered with (Giffard: Para. [0002]). This known benefit in Giffard is applicable to Tate’s inclusion of the signed set of hashes into the single purposes certificate as they both share characteristics and capabilities, namely, they are directed to authenticating and ensuring that the digital certificate has been issued in response to the certificate signing request from the rightful device and to reliably prevent device impersonation. As a result, it would have been recognized that modifying the signed set of hashes being transmitted to the certificate authority for incorporation into a single purpose certificate, as described in Tate, to include signing the hashes in the hash value of the document file using the single-purpose private key, would have yielded predictable results because (i) the level of ordinary skill in the art demonstrated by the references applied shows the ability to incorporate signing the hashes in the hash value of the document file using the single-purpose private key in authenticating and ensuring that the digital certificate has been issued in response to the certificate signing request from the rightful device and to reliably prevent device impersonation and (ii) the benefits of such a combination would have been recognized by those of ordinary skill in the art.
Claim(s) 6 is rejected under 35 U.S.C. 103 as being unpatentable over Bacon et al. (US 11,601,288; Hereinafter “Bacon”) in view of Tate (US 2022/0116370) in view of Giffard-Burley et al. (US 2025/00131134; Hereinafter “Giffard”) in view of Suarez (US 2008/0016357).
Regarding claim 6, Bacon, in combination with Tate and Giffard, teaches the method of claim 5.
Bacon, in combination with Tate and Giffard, does not explicitly further comprising publishing or sending the signed hash to the verifier together with the single-purpose certificate.
In an analogous art, Suarez teaches further comprising publishing or sending the signed hash to the verifier together with the single-purpose certificate (Suarez: Claim 6, obtaining from a certificate authority a digital certificate by a user having a user private key and a user public key, hashing an artifact using a hashing algorithm to generate a hash, encrypting the hash with the user private key, attaching the encrypted hash to the signed artifact, attaching the digital certificate to the signed artifact. Claim 7, herein the artifact is a document, data, an image, music, a file, or other information).
It would have been obvious to a person having ordinary skill in the art, before the effective filing date of the claimed invention, to combine the teachings of Suarez with the system and method of Bacon, Tate, and Giffard to include further comprising publishing or sending the signed hash to the verifier together with the single-purpose certificate because this functionality provides improved securing of a digital signature by use of a short-lived private key (Suarez: Para. [0001]).
Claim(s) 8 is rejected under 35 U.S.C. 103 as being unpatentable over Bacon et al. (US 11,601,288; Hereinafter “Bacon”) in view of Tate (US 2022/0116370) in view of Bruso et al. (US 2023/0353377; Hereinafter “Bruso”).
Regarding claim 8, Bacon, in combination with Tate, teaches the method of claim 1. Bacon, in combination with Tate, does not explicitly teach further comprising publishing or sending the single-purpose certificate to the verifier multiple times, and, each of said times, publishing or sending at least one of the artifacts or establishing one of the secure connections.
In an analogous art, Bruso teaches further comprising publishing or sending the single-purpose certificate to the verifier multiple times, and, each of said times, publishing or sending at least one of the artifacts or establishing one of the secure connections (Bruso: Para. [0082], At 1306 a private key, certificate identifier and a hash algorithm identifier are selected for the directory. This step may be repeated if method 1300 is carried out for more than one sub-directory in the directory, or if a user carrying out method 1300 desires to also use method 1100 to create signatures for files contained in the selected directory. At 1308, an encrypted hash of the directory selected is created with the hash algorithm and private key selected for the directory at 1306. The encrypted hash may be of an aggregate of the directory’s content or a concatenated string representing signatures of the directory’s content created using method 1100 (FIG. 11) or method 1200 (FIG. 12), or other representation of the directory’s content.).
It would have been obvious to a person having ordinary skill in the art, before the effective filing date of the claimed invention, to combine the teachings of Bruso with the system and method of Bacon and Tate to include further comprising publishing or sending the single-purpose certificate to the verifier multiple times, and, each of said times, publishing or sending at least one of the artifacts or establishing one of the secure connections because this functionality enables the production of multiple signature hashes for several directories and sub-directories (Bruso: [0042]).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
U.S. Patent Application Publication No. US 2014/0281503 by Mills
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Nelson Giddins whose telephone number is (571)272-7993. The examiner can normally be reached on Monday - Friday, 9:00 AM - 5:00 PM.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Linglan Edwards can be reached at (571) 270-5440. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/NELSON S. GIDDINS/ Primary Examiner, Art Unit 2408