DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claims 1-20 are pending.
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.
Claims 1, 8 and 15 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1, 8 and 15 of U.S. Patent No. 12,306,921. Although the claims at issue are not identical, they are not patentably distinct from each other because the claims of the present application are anticipated by the ‘921 patent.
19/211,582
U.S. Patent No. 12,306,921
1. A method, comprising:
receiving, by a computing system and from a first resource, an authorization to permit a second resource to access a certificate for verifying an identity;
granting, by the computing system and based at least in part on the authorization, permission to the second resource to access the certificate, wherein the second resource is configured to verify the identity based at least in part on accessing the certificate;
receiving, by the computing system and based at least in part on the grant, a second request from the second resource to generate an association object between the second resource and the certificate; and
generating, by the computing system and based at least in part on the second request, the association object.
1. A method, comprising:
receiving, by a computing device and from a first resource, a first request for permission to access a certificate to verify a requestor's identity;
transmitting, by the computing device and based at least in part on the first request, a second request to a second resource to authorize permitting access to the certificate;
receiving, by the computing device and based at least in part on the second request, a response from the second resource comprising an authorization to permit access to the certificate; granting, by the computing device and based at least in part on the response, permission to the first resource to access the certificate, wherein the first resource is configured to verify the requestor's identity based on accessing the certificate;
receiving, by the computing device and based at least in part on the grant, a third request from the first resource to generate an association object between the first resource and the certificate; and
generating, by the computing device and based at least in part on the third request, the association object,
wherein the association object associates the first resource and the certificate.
8. A computing system, comprising: one or more processors; and one or more non-transitory, computer-readable media comprising instructions that, when executed, cause the one or more processors to:
receive, from a first resource, an authorization to permit a second resource to access a certificate for verifying an identity;
grant, based at least in part on the authorization, permission to the second resource to access the certificate, wherein the second resource is configured to verify the identity based at least in part on accessing the certificate;
receive, based at least in part on the grant, a second request from the second resource to generate an association object between the second resource and the certificate; and generate, at least in part on the second request, the association object.
8. A computing device, comprising: one or more processors; and one or more non-transitory, computer-readable media comprising instructions that, when executed, cause the one or more processors to perform operations comprising:
receiving, from a first resource, a first request for permission to access a certificate to verify a requestor's identity;
transmitting, based at least in part on the first request, a second request to a second resource to authorize permitting access to the certificate; receiving, based at least in part on the second request, a response from the second resource comprising an authorization to permit access to the certificate;
granting, based at least in part on the response, permission to the first resource to access the certificate, wherein the first resource is configured to verify the requestor's identity based on accessing the certificate;
receiving, based at least in part on the grant, a third request from the first resource to generate an association object between the first resource and the certificate; and
generating, based at least in part on the third request, the association object,
wherein the association object associates the first resource and the certificate.
15. One or more non-transitory, computer-readable media including stored thereon a sequence of instructions that, when executed, one or more processors to perform operations comprising:
receive, from a first resource, an authorization to permit a second resource to access a certificate for verifying an identity;
grant, based at least in part on the authorization, permission to the second resource to access the certificate, wherein the second resource is configured to verify the identity based at least in part on accessing the certificate;
receive, based at least in part on the grant, a second request from the second resource to
generate an association object between the second resource and the certificate; and generate, at least in part on the second request, the association object.
15. One or more non-transitory computer-readable media including stored thereon a sequence of instructions that, when executed, one or more processors to perform operations comprising:
receiving, from a first resource, a first request for permission to access a certificate to verify a requestor's identity;
transmitting, based at least in part on the first request, a second request to a second resource to authorize permitting access to the certificate;
receiving, based at least in part on the second request, a response from the second resource comprising an authorization to permit access to the certificate;
granting, based at least in part on the response, permission to the first resource to access the certificate, wherein the first resource is configured to verify the requestor's identity based on accessing the certificate;
receiving, based at least in part on the grant, a third request from the first resource to generate an association object between the first resource and the certificate; and
generating, based at least in part on the third request, the association object, wherein the association object associates the first resource and the certificate.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
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.
Claims 1-20 are rejected under 35 U.S.C. 103 as being unpatentable over Popoveniuc et al, US 10,263,789 and further in view of Keselman et al., US 2020/0382323.
Regarding claim 1, Popoveniuc discloses a method, comprising:
receiving, by a computing system and from a first resource, an authorization to permit a second resource to access a certificate for verifying an identity (0034-0035: a certificate manager (computing system) receiving an authenticated request from a customer/management console (first resource) to permit a Load Balancer (second resource) to access an SSL certificate);
granting, by the computing system and based at least in part on the authorization, permission to the second resource to access the certificate, wherein the second resource is configured to verify the identity based at least in part on accessing the certificate (0011, 0035: the Certificate Manager granting the Load Balancer permission to use the certificate. The Load Balancer provides this certificate to client browsers to verify identity and secure the connection);
receiving, by the computing system and based at least in part on the grant, a second request from the second resource to generate an association object between the second resource and the certificate (0035: the Load Balancer submitting a request to the Certificate Manager to “bind the certificate and private key to the load balancer).
Popoveniuc describes this as a concurrent action with the initial authentication. It lacks or fails to expressly disclose a bifurcated sequence where a distinct “second request” is sent specifically to generate the binding after the initial permission grant. However, Keselman teaches separating the cloud identity authorization (via generating signed temporary tokens) from the subsequent execution of certificate provisioning. It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to modify the concurrent binding request of Popveniuc with the sequential, token based API workflow of Kesselman in order to decouple authentication logic from persistent state management. By requiring the resource to execute a distinct second request to form the persistent “association object” the architecture allows the certificate service to cache the authorization locally. This reduces API latency by preventing repetitive polling for subsequent traffic.
Popoveniuc, as modified above further discloses
generating, by the computing system and based at least in part on the second request, the association object (0035: generating the association object by “writing an identifier (or other type of relation value) of the service into the database entry…creating an association in the database between the certificate and the load balancer).
Regarding claim 2, Popoveniuc lacks or does not expressly disclose transmitting the token to the first resource for authentication. However, Kesselman further discloses receiving, from the second resource, a message comprising a request for permission for the second resource to access the certificate and a token; and transmitting the token to the first resource, wherein the authorization is received based at least in part on transmitting the token to the first resource (0051, 0064: passing signed tokens (e.g. JSON Web Tokens, JWT) between the client, the central identity authority and the certificate manager).
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to apply Keselman’s JWT token exchange to Popoveniuc’s authentication step to facilitate stateless, cryptographically secure identity verification across distributed microservices.
Regarding claim 3, Popoveniuc, as modified above further discloses the method of claim 1, wherein the method further comprises: receiving, from the second resource, a request to access the certificate; and granting access to the certificate, based at least in part on the association object (0012, 0035: once the binding (relation value) is stored in the database, the load balancer uses this persistent association to continually access and utilize the decrypted private key for ongoing client traffic without needing to re-authenticate the initial setup request).
Regarding claim 4, Popoveniuc, lacks or fails to expressly disclose determine a second certificate. However, Keselman discloses certificate is a first certificate associated with a first identifier, and wherein the method further comprises: determining a second identifier; comparing the first identifier and the second identifier; determining a second certificate associated with the second identifier based at least on part on comparing the first identifier and the second identifier; and verifying the identity based at least in part on the second certificate (0045, 0061: resolving specific certificates by matching input parameters (such as an AWS Role ARN or client UUID) against policy ID data to determine which exact certificate a virtual machine is eligible to receive.).
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to integrate Keselmans’s identifier matching logic into Popoveniuc’s load balancer to support multi-tenant or Server Name Indication (SNI) environments, where single load balancer must dynamically select between multiple hosted certificates based on the incoming request header (the second identity).
Regarding claim 5, Popoveniuc, as modified above further discloses the method of claim 1, wherein the method further comprises: receiving a request from a computing service to determine whether the certificate has been revoked; determining whether the certificate has been revoked based at least in part on the request; and transmitting an indication of whether the certificate has been revoked based at least in part on determining whether the certificate has been revoked (0036: when a certificate is no longer to be used, the load balancer submits a message to the certificate manager to remove the binding (effectively checking and enforcing revocation status), causing the manager to delete the relation value and revoke permission to decrypt the private key).
Regarding claim 6, Popoveniuc lacks or fails to expressly disclose determine if the certificate is revokes. However, Kesleman teaches determining that a first request from the second resource to access the certificate is transmitted from an entity that authorized generation of the certificate; and transmitting a second request to the first resource for authorization to permit the second resource to access to the certificate based at least in part on determining that the first request from the second resource to access the certificate is transmitted from the entity that authorized generation of the certificate (0032-0035: an administrator (the authorizing entity) establishes the policies at the central authority. When runtime access requests occur, the certificate manager queries the central authority (first resource) to ensure the request strictly aligns with the entity’s established policy configuration).
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to incorporate the secondary validation loop to ensure the dynamic certificate requests issued by the automated cloud resources still conform to the security boundaries originally set by the human administrator.
Regarding claim 7, Popoveniuc, as modified above further discloses the method of claim 1, wherein the method further comprises generating the certificate based at least in part on the authorization from the first resource (0032-0033: the Certificate Manager automatically generating the Certificate Singing Request (CSR) and obtaining the certificate from the Certificate Authority directly on behalf of the customer, triggered by the initial authorization request).
As per claims 8-14 and 15-20, this is a device and medium version of the claimed method discussed above in claims 1-7 wherein all claimed limitations have also been addressed and/or cited as set forth above.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
US 12,470,387 teaches a manager instance receiving a first request for a first token to access a computing resource. The manager instance can determine an identity of the service account and generate a second request for the first token based at least in part on the authentication. The manager instance can transmit the second request to a token issuance service of the computing system. The token issuance service can generate a third request for the first token, the third request comprising the identity of the service account and a token issuance service signature. The token issuance service can transmit the third request to an identity service of the computing system. The identity service can generate the first token based at least in part on determining whether to generate the first token.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to AUBREY H WYSZYNSKI whose telephone number is (571)272-8155. The examiner can normally be reached M-F 9-5.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, ALI SHAYANFAR can be reached at 571-270-1050. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/AUBREY H WYSZYNSKI/Primary Examiner, Art Unit 2434
Prosecution Insights