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 .
DETAILED ACTION
Claims 1-8 are pending.
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.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 5/19/2025 is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Claim Objections
Claim 3 recites, “access levels granted by the AI policy engine.” Claim 3 does not depend from claim 2 where the AI policy engine was introduced. Appropriate correction is required.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-8 are rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter.
Claims 1-8 are directed systems that when interpreted in light of the specification may read on software alone which is non- statutory. In order to comply, the claimed systems must explicitly comprise hardware (e.g. a processor, memory) so they may not be reasonably be interpreted as software alone.
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.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claim 1 and 5-8 are rejected under 35 U.S.C. 103 as being unpatentable over Sondhi et al (US Pub. No. 2015/0089623), hereafter, “Sondhi,” in view of Boydstun et al (US Pub. No. 7,571,473), hereafter, “Boydstun.”
As to claim 1, Sondhi discloses an identity and access management system comprising:
a master data management store configured to store user attributes of a plurality of users ([0082], particularly, “In an embodiment, a particular policy engine has access to the user identity store of each tenant that subscribes to a service that is provided by the resource server that executes that particular policy engine. Thus, the policy engine can obtain, from the user identity store, the attributes of the client or user specified in the authorization token request.”);
an authentication service configured to receive an identity corresponding to a login to an application for a user of the plurality of users ([0098], particularly, “When a client application makes a request, the client supplies, to the OAuth authorization server, an identifier and a password that can be used to authenticate that client application prior to the performance of authorization procedures.”), and to query the master data management store according to the identity to identify a user attribute set relevant to the application ([0081]-[0082], particularly, “In response to receiving an authorization token request that cloud-wide OAuth authorization server 502 forwarded through Internet 514, the recipient resource server can invoke its policy engine to determine a particular set of policies that applies to the identity domain of the particular client (or user) specified in that authorization token request…In an embodiment, a particular policy engine has access to the user identity store of each tenant that subscribes to a service that is provided by the resource server that executes that particular policy engine. Thus, the policy engine can obtain, from the user identity store, the attributes of the client or user specified in the authorization token request. The policy engine can then select, from the set of policies determined to be pertinent to the authorization token request, policies that are applicable to the service specified in the authorization token request. These selected policies can specify various scopes of access relative to various client or user attributes. The policy engine can evaluate the selected policies relative to the attributes that are associated with the identity read from the user identity store.”); and
an authorization service configured to determine permissions and access levels of the user for the application according to one or more user attributes in the user attribute set of the user ([0082], particularly, “The policy engine can then select, from the set of policies determined to be pertinent to the authorization token request, policies that are applicable to the service specified in the authorization token request. These selected policies can specify various scopes of access relative to various client or user attributes. The policy engine can evaluate the selected policies relative to the attributes that are associated with the identity read from the user identity store.”), wherein the authorization service comprises a logic policy engine configured to:
generate an authorization policy according to one or more application functions and application requirements of the application ([0082], particularly, “As a result of the evaluation, the policy engine can determine a scope of access (e.g., which operations are permissible relative to which resources) that the requesting client (and its user) are permitted when utilizing the service specified in the authorization token request.”);
associate one or more user attribute types to the authorization policy ([0082], particularly, “These selected policies can specify various scopes of access relative to various client or user attributes. The policy engine can evaluate the selected policies relative to the attributes that are associated with the identity read from the user identity store. As a result of the evaluation, the policy engine can determine a scope of access (e.g., which operations are permissible relative to which resources) that the requesting client (and its user) are permitted when utilizing the service specified in the authorization token request.”); and
generate an authorization token according to the authorization policy, the authorization token being configured to enable the one or more application functions of the application for the user ([0082]-[0083], particularly, “Cloud-wide OAuth authorization server 502 can generate authorization tokens that specify that certain clients or users have the corresponding scopes of access relative to services provided by the resource servers from which those scopes of access were received.”)
However, Sondhi does not disclose an identity token corresponding to a login to an application for a user of the plurality of users.
But, Boydstun discloses an authentication service configured to receive an identity token corresponding to a login to an application for a user of the plurality of users, and to query a master data management store according to the identity token to identify a user attribute set relevant to the application (column 6, lines 1-12, “In other embodiments, information other than passwords and user IDs may be used, such as tokens, cookies, or other information. The authentication interface 30 then consults the identity management data store 60 to determine if the user 20 is authorized to access the requested application 40. If the user 20 is authorized, a user-to-role map within the identity management data store 60 is consulted to determine the roles the user 20 can hold within the requested application 40. A list of roles the user 20 can hold is then returned to the application 40 and the application 40 maps these roles to specific functions within the application 40.”)
Therefore it would have been obvious to one of ordinary skill in the art prior to the effective filing date of the application to combine the teachings of Sondhi and Boydstun in order to provide a known and reliable means of managing user authentications/authorizations securely and efficiently.
As to claim 5, the teachings of Sondhi and Boydstun as combined for the same reasons set forth in claim 1’s rejection further disclose the logic policy engine is configured to generate an application profile for the application corresponding to a mapping of the one or more user attribute types to the authorization policy (Sondhi, [0082]-[0083] and Boydstun, column 6, lines 1-12).
As to claim 6, the teachings of Sondhi and Boydstun as combined for the same reasons set forth in claim 1’s rejection further disclose the authentication service is configured to: query the master data management store according to identity information of the user included in the identity token to retrieve the user attributes associated with the user; and filter the user attributes associated with the user according to the application profile for the application to identify the user attribute set of the user relevant to the application (Sondhi, [0082]-[0083] and Boydstun, column 6, lines 1-12).
As to claim 7, the teachings of Sondhi and Boydstun as combined for the same reasons set forth in claim 1’s rejection further disclose the authorization service is configured to: identify the authorization policy from among a plurality of tiered authorization policies in response to the one or more user attributes in the user attribute set of the user corresponding to the one or more user attribute types associated with the authorization policy; and execute the authorization policy to generate the authorization token (Sondhi, [0082]-[0083] and Boydstun, column 6, lines 1-12).
As to claim 8, the teachings of Sondhi and Boydstun as combined for the same reasons set forth in claim 1’s rejection further disclose the authorization service is configured to: identify a different authentication requirement from the authorization policy than the one used to authenticate the user; and request a different authentication mechanism based on the different authentication requirement to generate the authorization token (Sondhi, [0082]-[0083] and Boydstun, column 6, lines 1-12).
Claims 2-4 are rejected under 35 U.S.C. 103 as being unpatentable over Sondhi and Boydstun in further view of Pugalia et al (US Pub. No. 2022/0201043), hereafter, “Pugulia.”
As to claim 2, the teachings of Sondhi and Boydstun disclose the parent claim but do not disclose the authorization service comprises an artificial intelligence (AI) policy engine trained to adjust the permissions and access levels granted by the logic policy engine according to a supervised learning model. However, Pugulia discloses an authorization service comprises an artificial intelligence (AI) policy engine trained to adjust the permissions and access levels granted by a logic policy engine according to a supervised learning model ([0045], particularly, “As discussed below with regard to FIG. 8, suggestion machine learning (ML) model 532 can also be applied to determine suggested corrections. For instance, ML training system 560 can be implemented to deploy or update ML model 532 based the information collected from numerous policies and edits performed, such as by using edits in response to recommended corrections 562 (or identified errors 524), train suggestion ML model 532. In various embodiments, data privacy rules and/or other safeguards may be implemented in order to ensure that data collection is limited to scenarios in which policy consent is actively given. For example, prior to saving edits or changes, a request to opt-in to data collection to improve validation suggestions may be provided, which may allow a user to affirm or deny consent to the collection of edits for the purposes of training ML model 532.” and [0058], particularly, “As indicated at 820, a supervised learning technique may be applied to the recorded modifications to train a machine learning (ML) model to produce suggested corrections for access management policies, in some embodiments.”)
Therefore it would have been obvious to one of ordinary skill in the art prior to the effective filing date of the application to combine the teachings of Sondhi and Boydstun with Pugulia in order to provide a means to allow the system to adjust automatically to changing conditions.
As to claim 3, the teachings of Sondhi and Boydstun disclose the parent claim but does not disclose the authorization service comprises a human policy engine configured to verify the permissions and access levels granted by the AI policy engine. However, Pugulia discloses an authorization service comprises a human policy engine configured to verify the permissions and access levels granted by the AI policy engine ([0033]-[0034] and [0056])
Therefore it would have been obvious to one of ordinary skill in the art prior to the effective filing date of the application to combine the teachings of Sondhi and Boydstun with Pugulia in order to provide a means to allow the system to adjust automatically to changing conditions while still providing user oversight.
As to claim 4, the teachings of Sondhi, Boydstun, and Pugulia as combined for the same reasons set forth in claim 3’s rejection further disclose the human policy engine is configured to modify the permissions and access levels granted by the logic policy engine, and the AI policy engine is configured to observe the modifications of the human policy engine as a labeled dataset for training (Pugulia, [0057]-[0058], particularly, “For example, a data collection system implemented as part of a machine learning system or other component of an identity and access management system (or external system) can pair modifications to portions of policies along with other features like suggested corrections, error indications, or other information about the policy or prior response generated by a policy validator. These modifications may be treated as truth labels, in some embodiments.”)
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to THOMAS J DAILEY whose telephone number is (571)270-1246. The examiner can normally be reached 9:30am-6:00pm.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Umar Cheema can be reached on 571-270-3037. 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.
/THOMAS J DAILEY/ Primary Examiner, Art Unit 2458
Prosecution Insights