DETAILED ACTION
Notice of Pre-AIA or AIA Status
[1] The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Notice to Applicant
[2] This communication is in response to the amendment filed 27 January 2026. It is noted that this application benefits from Provisional Patent Application Serial No. 63/487,776 filed 1 March 2023. Claims 1, 4-5, 7-8, 11-12, 15, and 18-20 have been amended. Claims 1-20 are pending.
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:
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.
[3] Claim(s) 1-3, 5, 8-10, 12, 15-17, and 19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Kumar et al. (United States Patent Application Publication No. 2024/0137368 hereinafter ‘Kumar’) in view of in view of Zhang et al. (United States Patent Application Publication No. 2023/0145130 hereinafter ‘Zhang’).
With respect to (currently amended) claim 1, Kumar discloses a computer-implemented method comprising: receiving, by a processor via an application programming interface (API) from a remote computing device, a request for a risk report associated with a target entity, wherein the target entity is associated with an identifier (Kumar et al.; paragraphs [0022] [0036]-[0038] [0045]; See at least user and device identifiers. See privileged access review form, i.e., a form of risk report. See interactions via API); responsive to receipt of the request, generating, by the processor, a first trigger event associated with the request and communicating the first trigger event to an external system (Kumar et al.; paragraphs [0049]-[0051] [0059]; See at least triggers to initiate at least transmission of authorization); retrieving, by the processor from a database, a set of records associated with the target entity based on the identifier, wherein each record of the set of records is associated with one or more states of the target entity (Kumar et al.; paragraphs [0042] [0052] [0061] [0072]; See at least parameters and state or status information by fields with respect to devices and users associated with identifiers. The status information fields are reasonably a form of state information associated with the user and devices); generating, by the processor, a first graphical user interface (GUI) that is displayed to a user via the remote computing device, wherein the first GUI comprises a selectable list of states associated with each record of the set of records (Kumar et al.; paragraphs [0061]-[0063] [0072]-[0073] Fig. 5 and 6; See at least interface and selectable status indicators); receiving, by the processor via the API, a selection of a first subset of the states selected by the user via the first GUI (Kumar et al.; paragraphs [0076]-[0079]; See at least modifications to selected status indicators via API/GUI); transmitting, by the processor to the remote computing device, the risk report comprising at least the risk indicator (Kumar et al.; paragraphs [0042] [0110] [0115]; See at least authorization transmitted and/or received), wherein the risk report is associated with the first trigger event and is useable for controlling access of the target entity to one or more interactive computing environments (Kumar et al.; paragraphs [0114] [0121] [0129]; See at least triggering approval or denial of access/login requests based on determined risk level and authorizations).
With respect to the recited “one or more states of the target entity”, claim 1 has been amended to further include “…identifying, by the processor and based on the set of records, a set of the one or more states of the target entity…”. Kumar discloses the amended limitation. Specifically, Kumar discloses determinations of user access states and device status associated with a user access request including retrieving and displaying a list of status on a GUI (Kumar et al.; paragraphs [0036] [0045]-[0048] [0061] [0066]; See at least system accesses and presents on the user interface user role and access permissions, device identifiers, user and device status and risks associated with a request. The collective user permissions and status associated with the requesting user/entity are reasonably a set of one or more states of the entity).
With respect to the previously recited “selectable list of states”, claim 1 has been amended to further specify “…wherein the first GUI comprises a selectable list of states, wherein the selectable list of states includes the set of the one or more states of the target entity…”. Kumar discloses the amended limitation. Specifically, Kumar discloses interfaces presenting user and device states/status in which a review/user is able to select, modify, or adjust user and device profile status/states (Kumar et al.; paragraphs [0081] [0088] [0095]; See at least GUIs for role review and device risk review. The attributes/states of each the user and the device are adjustable via the interface, i.e., selectable).
Kumar further discloses the amendments to the previously recited “receiving a selection of a first subset of states” to further specify “…, wherein the first subset of states is selected from the set of the one or more states of the target entity;” (Kumar et al.; paragraphs [0081] [0088] [0095]; See at least GUIs for role review and device risk review. The attributes/states of each the user and the device are adjustable via the interface, i.e., selectable).
Claim 1 has been further amended to recite “…determining, by the processor, a risk indicator associated with the target entity, wherein the risk indicator is based on a degree of matching among the entity-provided state data and retrieved state data included in a first subset of records associated with the first subset of states and transmitting, by the processor to the remote computing device, the risk report comprising at least the risk indicator…”.
With respect to this element, Kumar discloses generation of user and device states or status associated with a privileged access request. Kumar further discloses comparing the listed user role permissions and device state or status (e.g., status or states) to the privileged access request to generate role and impact risk indicators which are selectable/modifiable by the user a which are compared to the access request to assign a risk level for role and device risk (i.e., role and device state or status as selected on the interface). The risks are assigned levels of high, medium, and low which are indicated in colors on the interface (Kumar et al.; paragraphs [0088]-[0093] [0095]-[0098]; See at least assess risk levels associated with the role/permissions-selectable states of the user. The assessed risk levels are reasonably a form of measuring/quantifying the degree of match of the adjustable user role risk and device risk to the access request).
With respect to the user identifier and the comparison/match directed to “entity-provided state data”, while the status associated with the privileged access request are reasonably forms of entity state data to which the request in matched, Kumar fail to expressly state that the user state data is provided by the user/entity.
However, as evidenced by Zhang, it is well-known in the art to utilize identifier data such as government ID provided by a user/entity associated with access control to secure data and further applied a threshold, i.e., degree of matching, to determine if identification of the requestor is sufficient to grant privileged access for a defined time period (Zhang et al.; paragraphs [0032]-[0033] [0048]-[0050] [0069]; See at least user provided identifying data, i.e., entity-provided state data, and threshold matching for purposes of controlling data access).
It would have been obvious to one of ordinary skill in the art at the time the invention was made to have modified the risk assessment of data access requests based on comparative role risk and device risk associated with requests of Kumar by further including the well-known practice of threshold-based matching of user-provided identifying data to control access to secure data as taught by Zhang. The instant invention is directed to a system and method of controlling computing access based on a determined risk level. As Kumar disclose the use of risk assessment of data access requests based on comparative role risk and device risk associated with requests in the context of a system and method for controlling computing access based on a determined risk level and Zhang similarly discloses the utility of threshold-based matching of user-provided identifying data to control access to secure data in the context of a system and method for controlling computing access based on a determined risk level, the teachings are reasonably considered to have been derived from analogous references and applied in the manner disclosed by the respective references. Accordingly, one of ordinary skill in the art would have been motivated to make the noted combination/modification as rationalized by combining prior art elements accordingly to known methods to yield the predictable results of ensuring secure data is processed by designated responsible persons thereby providing a flexible, safer, and more controllable mechanism of secure data access (Zhang et al.; paragraph [0002]).
With respect to claim 2, Kumar discloses a computer-implemented method wherein the first GUI further comprises a selectable list of data fields from each record to include in the risk report (Kumar et al.; paragraphs [0045] [0052] [0061]; See at least first set of GUIs and selectable data fields).
With respect to claim 3, Kumar discloses a computer-implemented method further comprising: retrieving, by the processor from a management service, a configuration associated with the user, the configuration comprising a set of permissions; and generating, by the processor, the selectable list of data fields based at least in part on the set of permissions (Kumar et al.; paragraphs [0045] [0052] [0061]; See at least first set of GUIs and selectable data fields).
With respect to (currently amended) claim 5, Kumar discloses a computer-implemented method further comprising: generating, by the processor, a second GUI comprising information from the first subset of records and the selectable list of states; receiving, by the processor, a selection of a second subset of states from the selectable list of states via the second GUI (Kumar et al.; paragraphs [0095] [0100]; See at least Fig. 9 and impact risk states status); responsive to the selection of the second subset of states, generating, by the processor, a second trigger event based on the selection of the second subset of states and communicating the second trigger event to the external system, wherein the first trigger event and the second trigger event are associated with a session and wherein the session is associated with the request for the risk report (Kumar et al.; paragraphs [0114] [0121] [0129]; See at least triggering approval or denial of access/login requests based on determined risk level and authorizations. See further trigger of actions associated with each risk category and impact risk, i.e., multiple trigger actions related to an access/session); and transmitting, by the processor to the remote computing device, an updated risk report comprising at least information from the first subset of records associated with the first subset of states and a second subset of records associated with the second subset of states and wherein the risk report is associated with the first trigger event and the second trigger event (Kumar et al.; paragraphs [0114] [0121] [0129]; See at least triggering approval or denial of access/login requests based on determined risk level and authorizations).
Claims, as presented by amendment, 8-10, 12, 15-17, and 19 substantially repeat the subject matter addressed above with respect to claims 1-3 and 5 as directed to the enabling system and computer-readable medium storing computer-executable instructions. With respect to these elements, Kumar discloses enabling the disclosed method employing analogous systems and executable instructions. Accordingly, claims 8-10, 12, 15-17, and 19 are rejected under the applied teachings as discussed above with respect to claims 1-3 and 5.
[4] Claim(s) 4, 6-7, 11, 13-14, 18, and 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Kumar et al. (United States Patent Application Publication No. 2024/0137368 hereinafter ‘Kumar’) in view of Zhang et al. (United States Patent Application Publication No. 2023/0145130 hereinafter ‘Zhang’), as applied to claim 1 above, and further in view of Shua et al. (United States Patent Application Publication No. 2023/0306127 hereinafter ‘Shua’).
With respect to claim 4, while Kumar discloses request, status modification interfaces, and approval transmissions in multiple formats and, by extension, it is clear that a formatted risk assessment and authorization transmission would be formatted to be compatible with the receiving system, Kumar does not expressly state that the format is adjusted based on standardization or options.
However, as evidenced by Shua, it is well-known in the art to provide transforming functionality including formatting of permissions to access systems and for the creation of audit logs (Shua et al.; paragraphs [0073] [0148] [0159]-[0161]; See at least formatting of data and permission setting for access purposes to ensure a uniform data structure for storing data in audit logs).
It would have been obvious to one of ordinary skill in the art at the time the invention was made to have modified the storage of permission and status modifications related to access approvals in a desired format of Kumar by further including the well-known practice of enabling active formatting of data and transmitted information including instructional code and audit data as taught Shua. The instant invention is directed to a system and method of controlling computing access based on a determined risk level. As Kumar disclose the use of storage of permission and status modifications related to access approvals in a desired format in the context of a system and method for controlling computing access based on a determined risk level and Shua similarly discloses the utility of enabling active formatting of data and transmitted information including instructional code and audit data in the context of a system and method for controlling computing access based on a determined risk level, the teachings are reasonably considered to have been derived from analogous references and applied in the manner disclosed by the respective references. Accordingly, one of ordinary skill in the art would have been motivated to make the noted combination/modification as rationalized by combining prior art elements accordingly to known methods to yield the predictable results of ensuring uniform and therefore universally accessible data and instructional code for purposes of enabling access to disparate system and ensuring consistency in data for audit purposes.
With respect to claims 6 and 7, while Kumar discloses storing and tracking all changes to permissions, device status, and role status of entities access record, Kumar fails to expressly state that the stored settings are stored as audit logs.
However, as evidenced by Shua, it is well-known in the art to store data relevant to access status in the form of uniformly formatted audit logs (Shua et al.; paragraphs [0073] [0148] [0159]-[0161]; See at least formatting of data and permission setting for access purposes to ensure a uniform data structure for storing data in audit logs).
Regarding claims 6 and 7, the conclusions of obviousness and rationale to modify as established for claim 4 above are applicable to claim 6 and 7 and are hereby incorporated by reference.
Claims 11, 13-14, 18, and 20 substantially repeat the subject matter addressed above with respect to claims 4, 6, and 7 as directed to the enabling system and computer-readable medium storing computer-executable instructions. With respect to these elements, Kumar discloses enabling the disclosed method employing analogous systems and executable instructions. Accordingly, claims 11, 13-14, 18, and 20 are rejected under the applied teachings, conclusions obviousness, and rationale to modify as discussed above with respect to claims 4, 6, and 7.
Response to Remarks/Amendment
[5] Applicant's remarks filed 27 January 2026 have been fully considered and are addressed as follows:
[i] Applicant’s remarks directed to previous rejection(s) of claim(s) 1-20 under 35 U.S.C. 103 as being unpatentable as set forth in the previous Office Action mailed 2 October 2026 have been fully considered and are moot in light of newly added grounds of rejection responsive to the amendments to the subject claims. See revised rejection under 35 U.S.C. 103 presented below.
NOTE: With respect to the determination that the claims are directed to statutory subject matter under 35 U.S.C. 101, Examiner notes that the claimed invention is directed to the dynamic control of access to computing environments based on functionality to modify inputs to a risk assessment and a resultant risk indicator. As noted previously, claims 8 and 15 omit the terminal application of the indicator to controlling user access to the interactive computing environments. As discussed, Examiner assumes a typographical error or oversight to be corrected on the next response to align the claims with the requisite control element recited in claim 1.
Conclusion
[6] The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Cited NON-PATENT Literature:
Nakamura et al., Risk-Based Attributed Access Control Modelling in a Health Platform: Results from Project CityZen, 2019-10-01, 2019 International Conference on Cyber-Enabled Distributed Computing and Knowledge Discovery (CyberC) (2019, Page(s): 391-398): Relevant Teachings: Nakamura establishes that utilization of blockchain ledgers to track and control access conditions associated with elements including specified tasks, groups, and roles is common practice in the art.
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ROBERT D RINES whose telephone number is (571)272-5585. The examiner can normally be reached M-F 9am - 5pm.
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, Beth V Boswell can be reached at 571-272-6737. 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.
/ROBERT D RINES/Primary Examiner, Art Unit 3625
Prosecution Insights