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 .
This is the initial office action that has been issued in response to patent application, 18/762,541, filed on 07/02/2024. Claims 21-40, as originally filed, are currently pending and have been considered below. Claim 21, 29 and 37 are independent claim.
Priority
This application is a CON of 17/161,491 filed on 01/28/2021 (US PAT No. 12,058,176 B1).
Drawing
The drawings filed on 07/02/2024 are accepted by the examiner.
Information Disclosure Statement
The information disclosure statements (IDS's) submitted on 07/02/2024, are in compliance with provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
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 obviousness-type 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); and 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 a nonstatutory double patenting ground provided the conflicting application or patent either is shown to be commonly owned with this application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The USPTO internet Web site contains terminal disclaimer forms which may be used. Please visit http://www.uspto.gov/forms/. The filing date of the application will determine what form 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 http://www.uspto.gov/patents/process/file/efs/guidance/eTD-info-I.jsp.
Claims 21, 29 and 37 are non-provisionally rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1 of application No 17/161,491 (US Patent No. 12,058,176 B1). Although the claims at issue are not identical, they are not patentably distinct from each other because the claims in the co-pending application contains every element of claims of the instant application. A later patent claim is not patentably distinct from an earlier patent claim if the later claim is obvious over, or anticipated by, the earlier claim. In re Longi, 759 F.2d at 896, 225 USPQ at 651 (affirming a holding of obviousness-type double patenting because the claims at issue were obvious over claims in four prior art patents); In re Berg, 140 F.3d at 1437, 46 USPQ2d at 1233 (Fed. Cir. 1998) (affirming a holding of obviousness-type double patenting where a patent application claim to a genus is anticipated by a 35 patent claim to a species within that genus). “ELI LILLY AND COMPANY v BARR LABORATORIES, INC., United States Court of Appeals for the Federal Circuit, ON PETITION FOR REHEARING EN BANC (DECIDED: May 30, 2001).
Claims 21, 29 and 37 are non-provisionally rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1 of application 17/161,491 (US Patent No 12,058,176 B1) in view of Behm (US Patent No 9,225,744 B1) and Baer (US Patent No 8,955,149 B1). This is a nonstatutory obviousness type double patenting rejection.
This is a non-provisional non-statutory double patenting rejection because the conflicting claims have been patented.
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 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 of this title, 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 21-23, 26, 28-31, 34, 37-38 and 40 are rejected under 35 U.S.C. 103 as being unpatentable over Behm (US Patent No 9,225,744 B1) in view of Baer (US Patent No 8,955,149 B1).
Regarding Claim 21, Behm discloses a system, comprising:
one or more computers comprising one or more respective processors and memory and configured to implement a request-based security agent to (Behm, Fig-1):
responsive to a call from a client over an established connection for a service operation, wherein the call does not include a credential for authorizing the service operation (Behm, Col 5, line 10-30, a client requests an access control service 122 to allow a servicer to perform a set of actions on its behalf. The service may receive with the request servicer credentials and a claim that includes a client identifier. If authorized, the servicer may perform the action using a context of a client as if the client requested the action);
determine, based on a stored binding of the client to the established connection, a client ID for the established connection (Behm, col 5, line 10-20, the access control service may store the grant as associated with the servicer and an identity of the client. Col 7, line 15-30, if approved, the access control service may provide bearer credentials. The bearer credentials are returned to the client and forwarded to the servicer. The servicer may send a request to perform an action. The request may be accompanied by the bearer credential and servicer credential to determine if the servicer is authorized);
use an impersonation credential for the client ID to perform an authorization operation, based on the impersonation credential, for the requested service operation (Behm, col 6, line 10-30, a client may send a request for impersonation that includes a service identity. The access control service may then create impersonation credentials. During the distribution, a servicer may retrieve the impersonation credential from the access control service by providing its servicer credentials. Col 6, line 30-50, impersonation credential may be created in multiple ways Col 8, line 45-65, the impersonation credential is signed with a private key that may be verified with a public key from the access control service); and
Behm does not explicitly discuss the following limitation that Baer teaches:
return a success or failure of the authorization operation (Baer, col 10, line 10-20, the impersonation request succeeds, the service provider environment issues a credential to the trouble ticket representative and the representative uses the credential to access the customer’s computing resources. Col 11, line 15-25);
Behm in view of Baer are analogous art because they are from the “same field of endeavor” and are from the same “problem solving area”. Namely, they pertain to the field of “a user granting permission to another user to impersonate the user”. It would have been obvious to a person of ordinary skill in the art before the effective filing date of the invention to modify the invention of Behm in view of Baer to include the idea of providing access to a user request where user identification and authentication service defines access rights for users (impersonation rights, right to access another user’s data). Allow for the user to grant a permission allowing the support representative to impersonate the user for a specified period while interacting with the network-based resource to attempt to recreate the problem for his or her own viewing (Baer, col 1, line 60-65, col 6, line 15-25).
Regarding Claim 22, Behm in view of Baer discloses the system of claim 21, further comprising:
one or more computers comprising one or more respective processors and memory and configured to implement a remote request-based security service configured to:
manage request-based credentials for the client (Behm, col 4, line 55-65, the API call may receive servicer credentials that are associated with a prior impersonation grant requested by a client. The impersonation credentials may include two credentials, client credentials associated with the service providing proof of the client being authorized to access the service and client credentials associated with the access control service providing proof the servicer has been authorized to act within the context of the client. Also Baer, col 5, line 10-25); and
generate, based on authentication of credentials extracted from connection- session credentials based on the request-based credentials and provided during creation of the established connection, the impersonation credentials for the client ID (Behm, col 4, line 55-65, the API call may receive servicer credentials that are associated with a prior impersonation grant requested by a client. The impersonation credentials may include two credentials, client credentials associated with the service providing proof of the client being authorized to access the service and client credentials associated with the access control service providing proof the servicer has been authorized to act within the context of the client. Also Baer, col 5, line 10-25).
Regarding claim 23, Behm in view of Baer discloses the system of claim 22, wherein to perform said authorization operation, based on the impersonation credential, for the requested service operation the request- based security agent is configured to call the request-based security service to authorize the requested service operation in the call using the impersonation credential (Behm, col 6, line 10-30, a client may send a request for impersonation that includes a service identity. The access control service may then create impersonation credentials. During the distribution, a servicer may retrieve the impersonation credential from the access control service by providing its servicer credentials. Also Baer, col 10, line 10-20, the impersonation request succeeds, the service provider environment issues a credential to the trouble ticket representative and the representative uses the credential to access the customer’s computing resources).
Regarding Claim 26, Behm in view of Baer discloses the system of claim 21, wherein the request-based security agent is configured to:
determine the impersonation credential, used by the request-based security agent to perform the authorization operation, from a data store of mappings of clients to impersonation credentials (Behm, col 6, line 10-30, a client may send a request for impersonation that includes a service identity. The access control service may then create impersonation credentials. During the distribution, a servicer may retrieve the impersonation credential from the access control service by providing its servicer credentials. Also Baer, col 10, line 10-20, the impersonation request succeeds, the service provider environment issues a credential to the trouble ticket representative and the representative uses the credential to access the customer’s computing resources).
Regarding Claim 28, Behm in view of Baer discloses the system of claim 21, wherein:
the call from a client comprises a request for an operation (Behm, col 6, line 10-30, a client may send a request for impersonation that includes a service identity. The access control service may then create impersonation credentials. During the distribution, a servicer may retrieve the impersonation credential from the access control service by providing its servicer credentials. Also Baer, col 10, line 10-20, the impersonation request succeeds, the service provider environment issues a credential to the trouble ticket representative and the representative uses the credential to access the customer’s computing resources);
said return a success or failure of the authorization operation comprises return, by the request-based security agent, the success or failure of the authorization to a connection-based security mechanism or service logic of a connection- based service to which the connection with the client is established (Baer, col 10, line 10-20, the impersonation request succeeds, the service provider environment issues a credential to the trouble ticket representative and the representative uses the credential to access the customer’s computing resources. Col 11, line 15-25).
Regarding Claim 29, Behm discloses a method, comprising:
performing by one or more computing devices (Behm, Fig-1):
receiving a call from a client over an established connection for a service operation, wherein the call does not include a credential for authorizing the service operation (Behm, Col 5, line 10-30, a client requests an access control service 122 to allow a servicer to perform a set of actions on its behalf. The service may receive with the request servicer credentials and a claim that includes a client identifier. If authorized, the servicer may perform the action using a context of a client as if the client requested the action);
determining, by a request-based security agent and based on a stored binding of the client to the established connection, a client ID for the established connection (Behm, col 5, line 10-20, the access control service may store the grant as associated with the servicer and an identity of the client. Col 7, line 15-30, if approved, the access control service may provide bearer credentials. The bearer credentials are returned to the client and forwarded to the servicer. The servicer may send a request to perform an action. The request may be accompanied by the bearer credential and servicer credential to determine if the servicer is authorized);
using, by the request-based security agent, an impersonation credential for the client ID to perform an authorization operation, based on the impersonation credential, for the requested service operation (Behm, col 6, line 10-30, a client may send a request for impersonation that includes a service identity. The access control service may then create impersonation credentials. During the distribution, a servicer may retrieve the impersonation credential from the access control service by providing its servicer credentials. Col 6, line 30-50, impersonation credential may be created in multiple ways Col 8, line 45-65, the impersonation credential is signed with a private key that may be verified with a public key from the access control service); and
Behm does not explicitly discuss the following limitation that Baer teaches:
returning a success or failure of the authorization operation (Baer, col 10, line 10-20, the impersonation request succeeds, the service provider environment issues a credential to the trouble ticket representative and the representative uses the credential to access the customer’s computing resources. Col 11, line 15-25).
Behm in view of Baer are analogous art because they are from the “same field of endeavor” and are from the same “problem solving area”. Namely, they pertain to the field of “a user granting permission to another user to impersonate the user”. It would have been obvious to a person of ordinary skill in the art before the effective filing date of the invention to modify the invention of Behm in view of Baer to include the idea of providing access to a user request where user identification and authentication service defines access rights for users (impersonation rights, right to access another user’s data). Allow for the user to grant a permission allowing the support representative to impersonate the user for a specified period while interacting with the network-based resource to attempt to recreate the problem for his or her own viewing (Baer, col 1, line 60-65, col 6, line 15-25).
Regarding Claim 30, Behm in view of Baer, discloses the method of claim 29,
wherein the impersonation credential for the client ID is generated by a remote request-based security service based on authentication of credentials extracted from connection-session credentials provided during creation of the established connection (Behm, col 4, line 55-65, the API call may receive servicer credentials that are associated with a prior impersonation grant requested by a client. The impersonation credentials may include two credentials, client credentials associated with the service providing proof of the client being authorized to access the service and client credentials associated with the access control service providing proof the servicer has been authorized to act within the context of the client. Also Baer, col 5, line 10-25); and
wherein the connection session credentials are based on request-based credentials managed by the remote request-based security service for the client (Behm, col 4, line 55-65, the API call may receive servicer credentials that are associated with a prior impersonation grant requested by a client. The impersonation credentials may include two credentials, client credentials associated with the service providing proof of the client being authorized to access the service and client credentials associated with the access control service providing proof the servicer has been authorized to act within the context of the client. Also Baer, col 5, line 10-25).
Regarding Claim 31, Behm in view of Baer discloses the method of claim 30, wherein said perform an authorization operation, based on the impersonation credential, for the requested service operation comprises:
calling, by the request-based security agent, the request-based security service to authorize a requested operation in the call using the impersonation credential (Behm, col 6, line 10-30, a client may send a request for impersonation that includes a service identity. The access control service may then create impersonation credentials. During the distribution, a servicer may retrieve the impersonation credential from the access control service by providing its servicer credentials. Also Baer, col 10, line 10-20, the impersonation request succeeds, the service provider environment issues a credential to the trouble ticket representative and the representative uses the credential to access the customer’s computing resources).
Regarding Claim 34, Behm in view of Baer discloses the method of claim 29, further comprising:
determining the impersonation credential, used by the request-based security agent to perform the authorization operation, from a data store of mappings of clients to impersonation credentials (Behm, col 6, line 10-30, a client may send a request for impersonation that includes a service identity. The access control service may then create impersonation credentials. During the distribution, a servicer may retrieve the impersonation credential from the access control service by providing its servicer credentials. Also Baer, col 10, line 10-20, the impersonation request succeeds, the service provider environment issues a credential to the trouble ticket representative and the representative uses the credential to access the customer’s computing resources).
Regarding Claim 37, Behm discloses one or more non-transitory computer-readable media storing program instructions executable on or across one or more processors to perform (Behm, Fig-1):
responsive to a call from a client over an established connection for a service operation, wherein the call does not include a credential for authorizing the service operation (Behm, Col 5, line 10-30, a client requests an access control service 122 to allow a servicer to perform a set of actions on its behalf. The service may receive with the request servicer credentials and a claim that includes a client identifier. If authorized, the servicer may perform the action using a context of a client as if the client requested the action):
determining, by a request-based security agent and based on a stored binding of the client to the established connection, a client ID for the established connection (Behm, col 5, line 10-20, the access control service may store the grant as associated with the servicer and an identity of the client. Col 7, line 15-30, if approved, the access control service may provide bearer credentials. The bearer credentials are returned to the client and forwarded to the servicer. The servicer may send a request to perform an action. The request may be accompanied by the bearer credential and servicer credential to determine if the servicer is authorized);
using, by the request-based security agent, an impersonation credential for the client ID to perform an authorization operation, based on the impersonation credential, for the requested service operation (Behm, col 6, line 10-30, a client may send a request for impersonation that includes a service identity. The access control service may then create impersonation credentials. During the distribution, a servicer may retrieve the impersonation credential from the access control service by providing its servicer credentials. Col 6, line 30-50, impersonation credential may be created in multiple ways Col 8, line 45-65, the impersonation credential is signed with a private key that may be verified with a public key from the access control service); and
Behm does not explicitly discuss the following limitation that Baer teaches:
returning a success or failure of the authorization operation (Baer, col 10, line 10-20, the impersonation request succeeds, the service provider environment issues a credential to the trouble ticket representative and the representative uses the credential to access the customer’s computing resources. Col 11, line 15-25).
Behm in view of Baer are analogous art because they are from the “same field of endeavor” and are from the same “problem solving area”. Namely, they pertain to the field of “a user granting permission to another user to impersonate the user”. It would have been obvious to a person of ordinary skill in the art before the effective filing date of the invention to modify the invention of Behm in view of Baer to include the idea of providing access to a user request where user identification and authentication service defines access rights for users (impersonation rights, right to access another user’s data). Allow for the user to grant a permission allowing the support representative to impersonate the user for a specified period while interacting with the network-based resource to attempt to recreate the problem for his or her own viewing (Baer, col 1, line 60-65, col 6, line 15-25).
Regarding Claim 38, Behm in view of Baer discloses the one or more non-transitory computer-readable media of claim 37,
wherein the impersonation credential for the client ID is generated by a remote request-based security service based on authentication of credentials extracted from connection-session credentials provided during creation of the established connection (Behm, col 4, line 55-65, the API call may receive servicer credentials that are associated with a prior impersonation grant requested by a client. The impersonation credentials may include two credentials, client credentials associated with the service providing proof of the client being authorized to access the service and client credentials associated with the access control service providing proof the servicer has been authorized to act within the context of the client. Also Baer, col 5, line 10-25); and
wherein the connection session credentials are based on request-based credentials, managed by the remote request-based security service, for the client (Behm, col 4, line 55-65, the API call may receive servicer credentials that are associated with a prior impersonation grant requested by a client. The impersonation credentials may include two credentials, client credentials associated with the service providing proof of the client being authorized to access the service and client credentials associated with the access control service providing proof the servicer has been authorized to act within the context of the client. Also Baer, col 5, line 10-25).
Regarding Claim 40, Behm in view of Baer discloses the one or more non-transitory computer-readable media of claim 37, wherein:
the call from a client comprises a request for an operation (Behm, Col 5, line 10-30, a client requests an access control service 122 to allow a servicer to perform a set of actions on its behalf. The service may receive with the request servicer credentials and a claim that includes a client identifier. If authorized, the servicer may perform the action using a context of a client as if the client requested the action);
to perform said returning a success or failure of the authorization operation the program instructions are executable to perform:
returning, by the request-based security agent, the success or failure of the authorization to a connection-based security mechanism or service logic of a connection-based service to which the connection with the client is established (Baer, col 10, line 10-20, the impersonation request succeeds, the service provider environment issues a credential to the trouble ticket representative and the representative uses the credential to access the customer’s computing resources. Col 11, line 15-25); and
for a successful authorization, performing the operation requested by the client (Baer, col 10, line 10-20, the impersonation request succeeds, the service provider environment issues a credential to the trouble ticket representative and the representative uses the credential to access the customer’s computing resources. Col 11, line 15-25); and
for a failed authorization, not performing the operation requested by the client (Baer, col 10, line 10-20, the impersonation request succeeds, the service provider environment issues a credential to the trouble ticket representative and the representative uses the credential to access the customer’s computing resources. Col 11, line 15-25).
Claim 27, 35-36 and 39 are rejected under 35 U.S.C. 103 as being unpatentable over Behm (US Patent No 9,225,744 B1) in view of Baer (US Patent No 8,955,149 B1) and further in view of Kumar (US Patent Application Publication No 2012/0216244 A1).
Regarding Claim 27, Behm in view of Baer does not disclose the following limitation that Kumar teaches:
the system of claim 21, wherein:
the established connection is established according to the Secure Authentication and Security Layer (SASL) framework (Kumar, ¶[0029], a method of monitoring and attesting a simple authentication and security layer (SASL) enabled client and server application. ¶[0069], using SASL protocol a mutual attestation handshake may be defined by an integrity exchange profile, before initiating an authentication handshake with proof of possession of credentials); and
wherein the binding of the client to the established connection is stored during establishment of the connection (Kumar, ¶[0105], any application layer protocol between client-server and peer to peer applications may be extended and used to provide the functions of the client application).
Behm in view of Baer and further in view of Kumar are analogous art because they are from the “same field of endeavor” and are from the same “problem solving area”. Namely, they pertain to the field of “a user granting permission to another user to impersonate the user”. It would have been obvious to a person of ordinary skill in the art before the effective filing date of the invention to modify the invention of Behm in view of Baer and Kumar to include the idea of authorizing data exchange in an established connection (Kumar, ¶[0009]).
Regarding Claim 35, Behm in view of Baer and Kumar discloses the method of claim 29, wherein:
the established connection is established according to the Secure Authentication and Security Layer (SASL) framework (Kumar, ¶[0029], a method of monitoring and attesting a simple authentication and security layer (SASL) enabled client and server application. ¶[0069], using SASL protocol a mutual attestation handshake may be defined by an integrity exchange profile, before initiating an authentication handshake with proof of possession of credentials); and wherein
the binding of the client to the established connection is stored, during establishment of the connection (Kumar, ¶[0105], any application layer protocol between client-server and peer to peer applications may be extended and used to provide the functions of the client application).
Regarding Claim 36, Behm in view of Baer and Kumar discloses the method of claim 29, wherein:
the call from a client comprises a request for an operation (Behm, Col 5, line 10-30, a client requests an access control service 122 to allow a servicer to perform a set of actions on its behalf. The service may receive with the request servicer credentials and a claim that includes a client identifier. If authorized, the servicer may perform the action using a context of a client as if the client requested the action);
said returning a success or failure of the authorization operation comprises returning, by the request-based security agent, the success or failure of the authorization to a connection-based security mechanism or service logic of a connection-based service to which the connection with the client is established (Baer, col 10, line 10-20, the impersonation request succeeds, the service provider environment issues a credential to the trouble ticket representative and the representative uses the credential to access the customer’s computing resources. Col 11, line 15-25);
the method comprises determining, by the service logic and based on the success or failure of the authorization, whether to perform the operation requested by the client (Baer, col 10, line 10-20, the impersonation request succeeds, the service provider environment issues a credential to the trouble ticket representative and the representative uses the credential to access the customer’s computing resources. Col 11, line 15-25).
Regarding Claim 39, Behm in view of Baer and Kumar discloses the one or more non-transitory computer-readable media of claim 37, wherein the program instructions are executable to perform:
establishing the connection according to the Secure Authentication and Security Layer (SASL) framework (Kumar, ¶[0029], a method of monitoring and attesting a simple authentication and security layer (SASL) enabled client and server application. ¶[0069], using SASL protocol a mutual attestation handshake may be defined by an integrity exchange profile, before initiating an authentication handshake with proof of possession of credentials); and
storing, during said establishing the connection, the binding of the client to the established connection (Kumar, ¶[0105], any application layer protocol between client-server and peer to peer applications may be extended and used to provide the functions of the client application).
Allowable subject matter
Claim 24-25 and 32-33 are allowable when they are re-written in independent form with independent claims.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure (see PTO-Form 892).
Any inquiry concerning this communication or earlier communications from the examiner should be directed to WASIKA NIPA whose telephone number is (571)272-8923. The examiner can normally be reached on M-F, 8 am to 5 pm. If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Jeffrey Pwu can be reached on 571-272-6798. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
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.
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.
/WASIKA NIPA/ Primary Examiner, Art Unit 2433