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 .
Information Disclosure Statement
The information disclosure statements (IDS) submitted on 09/10/2025 and 09/19/2025 are in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Claim Objections
Claim(s) 11 is/are objected to because of the following informalities: “from the request initiator to a third-party service carries” should read “from the request initiator to a third-party service.” Appropriate correction is required.
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, 5 and 16-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Gunaratne et al., US- 20200133737-A1 (hereinafter “Gunaratne ‘737”) in view of Chang et al., US-20090288136-A1 (hereinafter “Chang ‘136”) and Shiralkar et al., US-20220124098-A1 (hereinafter “Shiralkar ‘098”).
Per claim 1 (independent):
Gunaratne ‘737 discloses: A method comprising:
sending, by a request initiator in a cloud and to a third-party service in the cloud, an access request; and
receiving, by the third-party service, the access request
(FIG. 1, [0024], an example system 100 having an independent services platform 110. The independent services platform 110 (a third-party service) hosts service instances 112 that can be consumed by computing tasks hosted on two different software platforms 120 and 130 (a request initiator in a cloud, which corresponds to the underlying cloud computing infrastructure 170); [0029], the system controller 140 uses the deployment manager 150 to provision resources in the underlying cloud computing infrastructure 170 (the cloud) to host the service instances to implement the selected services in the independent services platform 110; [0030], the system controller 140 can use the deployment manager 150 to provision 4 service instances (a third-party service in the cloud) to manage queries into the database management system; [0032], The system controller can then use the deployment manager 150 to provision resources for hosting multiple instances of the computing tasks 122 in the first software platform 120. The application developer 142 can then issue a command to the system controller 140 to bind the service to the computing tasks 122. As shown in FIG. 1, this allows the computing tasks 122 to consume the service by communicating with the service instances 112 (receiving, by the third-party service, the access request) provisioned in the independent services platform 110; note that the computing tasks 122/132 send an access request to the service instances 112, for example, a database management system, to consume the service).
Gunaratne ‘737 does not disclose but Chang ‘136 discloses: an access request comprising subject attribute information and environment attribute information, wherein the subject attribute information indicates identity information of the request initiator, and wherein the environment attribute information indicates environment information of the request initiator
(FIG. 1, [0020], network configuration 100 includes one or more clients 101-102 (the request initiator) communicatively coupled to an application service gateway or appliance device 103 in order to access one or more application servers 104-105; [0021], device 103 is configured to perform attribute (i.e., access request) based authentication and/or authorization of clients 101-102 to determine whether a particular client is eligible to access application servers 104-105; [0007], in response to a request (an access request) received from a client (the request initiator) for accessing a resource of an application server of a datacenter having a plurality of servers, attributes are extracted from the request. The extracted attributes (an access request comprising subject attribute information and environment attribute information) include at least one of a user attribute identifying a user of the client (identity information of the request initiator) and an environment attribute identifying an environment associated with the user (environment information of the request initiator); FIG. 4, [0049], an example of operations by a rule engine ... given multiple attributes 401 (e.g., URL, time, document, action, source IP address – environment information, access method, user ID – identity information, and role, etc.) associated with a request for accessing a resource ... Individual search results at the rule level 406 and policy level 407 are combined to generate a single final result 408 which is used to determine whether the request should be permitted or denied, etc.);
extracting, by the service from the access request, the subject attribute information and the environment attribute information; and
performing, by the service, based on an access control policy, and using the subject attribute information and the environment attribute information, a calculation to determine whether to grant the access request
(FIG. 3, [0036], rule engine architecture ... system 300 may be implemented as part of components 108-109 (the service) of FIG. 1. Referring to FIG. 3, when a packet 301 representing a client request (the access request) for a resource is received by logic 302 which may be a policy enforcement point (PEP), a policy decision point (PDP), or a combination of both, certain attributes associated with the packet 301 are extracted (extracting the subject attribute information and the environment attribute information). For each attribute, an individual search is performed via search logic 305-307 in parallel in rules and policies 312 (an access control policy) stored in policy store 308. Individual search results are then combined by combination logic 304 which generates a final search result or final decision to be used to determine whether packet 301 is eligible to access the requested resource – performing a calculation to determine whether to grant the access request; FIG. 4, [0049], an example of operations by a rule engine ... given multiple attributes 401 (e.g., URL, time, document, action, source IP address – the environment attribute information, access method, user ID – the subject attribute information, and role, etc.) associated with a request for accessing a resource ... Individual search results at the rule level 406 and policy level 407 are combined to generate a single final result 408 which is used to determine whether the request should be permitted or denied, etc. – performing a calculation to determine whether to grant the access request).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have modified Gunaratne ‘737 with the centralized, attribute-based access control through application service gateway, such that access to application servers can be selectively permitted based on XACML policies as taught by Chang ‘136 because the access control process can be performed in a significantly higher efficiency [0030]. Additionally, Chang ‘136 is analogous to the claimed invention because it teaches highly parallel evaluation of XACML (extensible access control markup language) policies [0007].
Chang ‘136 does not clearly teach whether the application service gateway 103, corresponding to the service, is a “third-party service” but Shiralkar ‘098 discloses: extracting, by the third-party service, the subject attribute information and the environment attribute information; and
performing, by the third-party service, based on an access control policy, and using the subject attribute information and the environment attribute information, a calculation to determine whether to grant the access request
(FIG. 4, [0040], interactions between the third-party service provider 110, the client device 120, and the identity provider 130 – from the perspective of client device 120, the third-party service provider 110 and the identity provider 130 may collectively be regarded as the “third-party service”; [0041], the client device 120 submitting 410 an access request (the access request) to the third-party service provider 110; [0042], Based on the request for authentication of the access request, the identity provider 130 collects 430 device signals from the client device 120. For instance, the identity provider 130 (the third-party service) may collect device signals (from which the subject attribute information and the environment attribute information is to be extracted) specified in a custom access policy (based on an access control policy) for the third-party service provider 110 ... Using the collected device signals, the identity provider 130 determines 440 a device trust score for the client device 120 (performing a calculation to determine whether to grant the access request based on an access control policy (i.e., custom access control policy store 330 of FIG. 3; also see para [0036]), and using the subject attribute information and the environment attribute information); [0043], Using the authentication response, the third-party service provider 110 determines 460 an access level for the client device 120 from a set of access levels described by the custom access policy for the third-party service provider 110; [0021], Device signals can include various characteristics of the client device 120, such as a geographic location of the client device 120 (e.g., GPS coordinates), an Internet Protocol (IP) address of the client device 120 (the environment attribute information) ... an authentication credential type of the client device 120 ( e.g., certificate, secret, enrollment identifier, unknown, etc.; the subject attribute 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 have modified Gunaratne ‘737 in view of Chang ‘136 with the context-aware access control by allowing the identity provider to authenticate an access request based on device-specific signals as taught by Shiralkar ‘098 because the system may provide a variable level of access based on the trustworthiness and context of the requesting client device. Additionally, Shiralkar ‘098 is analogous to the claimed invention because it teaches a service provider provides flexible access to services using an identity provider [ABSTRACT].
Per claim 5 (dependent on claim 1):
Gunaratne ‘737 in view of Chang ‘136 and Shiralkar ‘098 discloses the elements detailed in the rejection of claim 1 above, incorporated herein by reference.
Gunaratne ‘737 in view of Shiralkar ‘098 does not disclose but Chang ‘136 discloses: The method of claim 1, wherein the subject attribute information comprises an identity of the request initiator (FIG. 1, [0020], network configuration 100 includes one or more clients 101-102 (the request initiator) communicatively coupled to an application service gateway or appliance device 103 in order to access one or more application servers 104-105; [0021], device 103 is configured to perform attribute based authentication and/or authorization of clients 101-102 to determine whether a particular client is eligible to access application servers 104-105; [0007], in response to a request received from a client (the request initiator) for accessing a resource of an application server of a datacenter having a plurality of servers, attributes are extracted from the request. The extracted attributes include at least one of a user attribute identifying a user of the client (an identity of the request initiator) and an environment attribute identifying an environment associated with the user; FIG. 4, [0049], an example of operations by a rule engine ... given multiple attributes 401 (e.g., URL, time, document, action, source IP address, access method, user ID – an identity, and role, etc.) associated with a request for accessing a resource ... Individual search results at the rule level 406 and policy level 407 are combined to generate a single final result 408 which is used to determine whether the request should be permitted or denied, etc.);
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have modified Gunaratne ‘737 in view of Shiralkar ‘098 with the centralized, attribute-based access control through application service gateway, such that access to application servers can be selectively permitted based on XACML policies as taught by Chang ‘136 because the access control process can be performed in a significantly higher efficiency [0030].
Per claim 16 (dependent on claim 1):
Gunaratne ‘737 in view of Chang ‘136 and Shiralkar ‘098 discloses the elements detailed in the rejection of claim 1 above, incorporated herein by reference.
Gunaratne ‘737 in view of Chang ‘136 does not disclose but Shiralkar ‘098 discloses: The method of claim 1, wherein the subject attribute information comprises an account of an identity of the request initiator (FIG. 1, [0021], The identity provider 130 can further obtain one or more device signals for the client device 120 (the request initiator) in order to authenticate the received access request. Device signals can include various characteristics of the client device 120, such as a geographic location of the client device 120 (e.g., GPS coordinates), an Internet Protocol (IP) address of the client device 120, anti-malware software version installed on the client device 120, an operating system version of the client device 120, a management status of the client device 120 (e.g., managed or unmanaged), an authentication credential type of the client device 120 ( e.g., certificate, secret, enrollment identifier, unknown, etc.; an account of an identity of the request initiator)).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have modified Gunaratne ‘737 in view of Chang ‘136 with the context-aware access control by allowing the identity provider to authenticate an access request based on device-specific signals as taught by Shiralkar ‘098 because the system may provide a variable level of access based on the trustworthiness and context of the requesting client device.
Per claim 17 (dependent on claim 1):
Gunaratne ‘737 in view of Chang ‘136 and Shiralkar ‘098 discloses the elements detailed in the rejection of claim 1 above, incorporated herein by reference.
Gunaratne ‘737 in view of Chang ‘136 does not disclose but Shiralkar ‘098 discloses: The method of claim 1, wherein the subject attribute information comprises an organization of an identity of the request initiator (FIG. 1, [0021], The identity provider 130 can further obtain one or more device signals for the client device 120 (the request initiator) in order to authenticate the received access request. Device signals can include various characteristics of the client device 120, such as a geographic location of the client device 120 (e.g., GPS coordinates) (an organization of an identity of the request initiator), an Internet Protocol (IP) address of the client device 120, anti-malware software version installed on the client device 120, an operating system version of the client device 120, a management status of the client device 120 (e.g., managed or unmanaged), an authentication credential type of the client device 120 ( e.g., certificate, secret, enrollment identifier, unknown, etc.; an identity of the request initiator)).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have modified Gunaratne ‘737 in view of Chang ‘136 with the context-aware access control by allowing the identity provider to authenticate an access request based on device-specific signals as taught by Shiralkar ‘098 because the system may provide a variable level of access based on the trustworthiness and context of the requesting client device.
Per claim 18 (dependent on claim 1):
Gunaratne ‘737 in view of Chang ‘136 and Shiralkar ‘098 discloses the elements detailed in the rejection of claim 1 above, incorporated herein by reference.
Gunaratne ‘737 in view of Chang ‘136 does not disclose but Shiralkar ‘098 discloses: The method of claim 1, wherein the environment attribute information comprises an identifier of a network of the request initiator (FIG. 1, [0021], The identity provider 130 can further obtain one or more device signals for the client device 120 (the request initiator) in order to authenticate the received access request. Device signals can include various characteristics of the client device 120, such as a geographic location of the client device 120 (e.g., GPS coordinates), an Internet Protocol (IP) address of the client device 120 (an identifier of a network of the request initiator), anti-malware software version installed on the client device 120, an operating system version of the client device 120, a management status of the client device 120 (e.g., managed or unmanaged), an authentication credential type of the client device 120 ( e.g., certificate, secret, enrollment identifier, unknown, etc.)).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have modified Gunaratne ‘737 in view of Chang ‘136 with the context-aware access control by allowing the identity provider to authenticate an access request based on device-specific signals as taught by Shiralkar ‘098 because the system may provide a variable level of access based on the trustworthiness and context of the requesting client device.
Per claim 19 (dependent on claim 1):
Gunaratne ‘737 in view of Chang ‘136 and Shiralkar ‘098 discloses the elements detailed in the rejection of claim 1 above, incorporated herein by reference.
Gunaratne ‘737 in view of Chang ‘136 does not disclose but Shiralkar ‘098 discloses: The method of claim 1, wherein the environment attribute information comprises an Internet Protocol (IP) address of a network of the request initiator (FIG. 1, [0021], The identity provider 130 can further obtain one or more device signals for the client device 120 (the request initiator) in order to authenticate the received access request. Device signals can include various characteristics of the client device 120, such as a geographic location of the client device 120 (e.g., GPS coordinates), an Internet Protocol (IP) address of the client device 120 (an Internet Protocol (IP) address of a network of the request initiator), anti-malware software version installed on the client device 120, an operating system version of the client device 120, a management status of the client device 120 (e.g., managed or unmanaged), an authentication credential type of the client device 120 ( e.g., certificate, secret, enrollment identifier, unknown, etc.)).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have modified Gunaratne ‘737 in view of Chang ‘136 with the context-aware access control by allowing the identity provider to authenticate an access request based on device-specific signals as taught by Shiralkar ‘098 because the system may provide a variable level of access based on the trustworthiness and context of the requesting client device.
Per claim 20 (dependent on claim 1):
Gunaratne ‘737 in view of Chang ‘136 and Shiralkar ‘098 discloses the elements detailed in the rejection of claim 1 above, incorporated herein by reference.
Gunaratne ‘737 in view of Chang ‘136 does not disclose but Shiralkar ‘098 discloses: The method of claim 1, wherein the environment attribute information comprises an execution environment in which the request initiator is (FIG. 1, [0021], The identity provider 130 can further obtain one or more device signals for the client device 120 (the request initiator) in order to authenticate the received access request. Device signals can include various characteristics of the client device 120, such as a geographic location of the client device 120 (e.g., GPS coordinates), an Internet Protocol (IP) address of the client device 120, anti-malware software version installed on the client device 120, an operating system version of the client device 120 (an execution environment in which the request initiator is), a management status of the client device 120 (e.g., managed or unmanaged), an authentication credential type of the client device 120 ( e.g., certificate, secret, enrollment identifier, unknown, etc.)).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have modified Gunaratne ‘737 in view of Chang ‘136 with the context-aware access control by allowing the identity provider to authenticate an access request based on device-specific signals as taught by Shiralkar ‘098 because the system may provide a variable level of access based on the trustworthiness and context of the requesting client device.
Allowable Subject Matter
Claim(s) 7-15 is/are allowed.
The following is a statement of reasons for the indication of allowable subject matter:
Regarding claim 7, the prior art of record (Gunaratne ‘737 in view of Chang ‘136 and Shiralkar ‘098) does not disclose: “receive, from a request initiator, a first request comprising an identity credential of the request initiator in a cloud; and
issue, to the request initiator, in response to the first request, and after verification of the identity credential is successful, attribute token data comprising subject attribute information and environment attribute information for provision in an access request from the request initiator to a third-party service” in the recited context.
Rather, Gunaratne ‘737 discloses a computing environment in which an application workload (a request initiator) operates on a software platform and accesses a service hosted by a separate independent services platform. The application workload may be instantiated as one or more of computing tasks within the cloud environment (a cloud). A service binding may provide the computing tasks with information, including a service location and credentials (an identity credential), for accessing the corresponding service. The computing tasks may thereafter communicate with the service instances and send service or access requests. This architecture permits application workloads and independently managed services to remain separately hosted while communicating within the same overall cloud computing environment. Although the reference discloses receiving credentials for service binding, it is unclear whether such credentials constitute “an identity credential of the request initiator.” It further does not disclose “after verification of the credentials and issuing attribute token data.”
To this, Chang ‘136 adds that the application service gateway is positioned between clients (a request initiator) and application servers to provide attribute-based authentication and authorization for access requests (access request). The gateway receives a client request directed to an application service and identifies attributes (attribute token data) associated with the request. Such attributes may include a user ID (an identity credential), role, source IP address, access method, time, and requested source information. The attributes are individually evaluated against applicable access-control rules and policies The resulting rule and policy determinations are combined to generate a final access-control result. Based on the final result, the gateway determines whether the client request should be permitted or denied. Chang ‘136 does not clearly teach that the disclosed system is implemented in a cloud. Further, although this reference teaches “an identity credential and attribute token data,” it does not teach “issuing attribute token data after verification of the identity credential is successful.”
To this, Shiralkar ‘098 adds a flexible access-control process involving a client device (a request initiator), a third-party service provider (a third-party service), and an identity provider (a third-party service). The client device requests access to a service provided by the third-party service provider, and the identity provider performs authentication in connection with that request. The identity provider may obtain device signals associated with the client device, including contextual and security-related information, and determine a trust level based on those signals. The authentication result may then be provided to the third-party service provider, which determines an appropriate level of access for the client device. The reference adequately teaches providing an “access request to a third-party service”; however, it likewise fails to teach or suggest “issue, to the request initiator, in response to the first request, and after verification of the identity credential is successful, attribute token data.”
For the reasons described above, the prior art of record does not disclose, with respect to claim(s) 11, features corresponding to those of claim 7 in the respective context(s).
Dependent claims 8-10 and 12-15 are allowed in view of their respective dependence from claims.
Claim(s) 2-4 and 6 is/are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Maes, US-20110167479-A1 – a requestor submits an access request, including associated context information, to an authorization enabler having a policy enforcement module. The authorization enabler evaluates the request and context information against applicable policies to determine whether access to the requested resource should be granted.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SANGSEOK PARK whose telephone number is (571)272-4332. The examiner can normally be reached Monday-Friday 7:30-5:30 and Alternate Fridays 9:00 am-5:00 pm.
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, PHILIP CHEA can be reached at (571)272-3951. 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.
/SANGSEOK PARK/Primary Examiner, Art Unit 2499
Prosecution Insights