DETAILED ACTION
This communication is in respond to applicant' s Request for Continued Examination (RCE) filed on 02/03/2026. Claims 1-9, 11-20, are pending. Claim 10 is cancelled.
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 .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 02/03/2026 has been entered.
Response to Arguments
This communication is in respond to applicant’s filing of 02/03/2026. Claims 1-9, 11-20, are pending. Applicant’s arguments with respect to amended claim(s) have been considered but are moot because the new ground of rejection below.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim(s) (1-6, 8-9, 11-14) and (15-20) are rejected under 35 U.S.C. 103 as being unpatentable over HINRICHS (US 11853463 B1) in view of GUPTA (US 11816236 B1).
Regarding claim 1, HINRICHS teaches:
A system for dynamic cybersecurity rule and protocol management through soft-coded rules in non-persistent run-time files (HINRICHS col 4; lines33-38 “Some embodiments of the invention provide a system for defining, distributing and enforcing policies for authorizing API (Application Programming Interface) calls to applications executing on one or more sets of associated machines (e.g., virtual machines, containers, computers, etc.) in one or more datacenters.”, HINRICHS col 5; lines 1-11 & 20-24 “The collected parameters in some embodiments are specific to each set of related machines (e.g., for each tenant in a multi-tenant datacenter or each department or division of a multi-department or multi-division entity) for which the server set defines and distributes policies. The server set in some embodiments updates these parameters dynamically in real time. Accordingly, in some embodiments, the server set uses, collects, and updates parameters for resolving policies dynamically and in a deployment specific manner (i.e., in a manner that can be context specific for each set of associated machines for which the server set is deployed).", “For each set of related machines, the server set in some embodiments stores the defined API-authorization policies, and collected parameters needed to resolve these policies, in a single hierarchical storage structure (such as a namespace) that can be accessed as a single runtime storage construct.”),
the system comprising: one or more processors; and a non-transitory, computer readable medium comprising instructions that, when executed by the one or more processors (HINRICHS col 30; lines 17-25 “Many of the above-described features and applications are implemented as software processes that are specified as a set of instructions recorded on a computer readable storage medium (also referred to as computer readable medium). When these instructions are executed by one or more processing unit(s) (e.g., one or more processors, cores of processors, or other processing units), they cause the processing unit(s) to perform the actions indicated in the instructions."),
causes operations comprising: storing a plurality of versions of a first rule in a persistent memory database(HINRICHS col 23; lines 4-13 “This interface includes (1) a download API that provides the functionality to download a bundle of policies and related data, and then request its next version, if a new version is available, and (2) an upload API that provides the functionality for the agents to report back any policy decisions they have made. The download API accesses the document database underneath to compile the policies and any of their dependencies (whether they are data or other policies) into a bundle.”), wherein the first rule comprises a first security protocol validation requirement(HINRICHS col 3; lines 24-31 “Kerberos is a common authentication protocol with older enterprise applications. For such an authentication protocol, the API-authorization system of some embodiments applies similar principles to make it policy-aware as well. Specifically, by becoming a Kerberos Authentication Server and using customer policy to control the authorization tickets issued by the server, the API-authorization system can control access to the services the Kerberos client can access.”); receiving a first request to process first input data using the first rule to determine whether the first input data conforms to the first security protocol validation requirement(HINRICHS col 5; lines 56-58 “From an associated application, a local agent receives API-authorization requests to determine whether API calls received by the application are authorized.”); determining, based on the first request, a first version of the plurality of versions to process the first input data (HINRICHS col 23; lines 32-39 “The server set copy of the policy and content database 1035 in some embodiments can save all versions of the data and policies over time for an entity. When either a data or policy is updated, its previous version is not removed but archived in some embodiments. This allows time traversal: the server set can inspect the state of policies and their related data at any point in time by simply defining the time of interest when accessing the namespace.”, HINRICHS col 24; lines 31-36 “This combined with versioning allows the system to provide versioned snapshots of the entire datacenter state, if needed. For example, in some embodiments, the local agents identify the namespace versions that they use to process the API-authorization requests and provide this version information to the server set to store in the decision logs 1042.”);
in response to the first request: retrieving a first rule template, and initiating a first rule engine session (HINRICHS col 2; lines 13-20 “Typically, the servers also query for group information to identify the group membership of the users. Applications have then configured (or hardcoded) the group names and the permissions to which the groups map. As a result, after authentication these systems know the group that the user belongs to and hence the permissions that he/she should be given.”, HINRICHS col 17; lines 32-41 “The service 1220 receives the modified reply 1325 and grants access to the user 1210 with the admin role instead of the member role. The RBAC system 1235 (not shown) of the service 1220 then assigns access permissions to the user 1210 based on the admin role instead of the member role. As a result, anytime the user logs in to the system while on call, the system 1225 can automatically assign them to the administrator group. If the user logs on while not on call, then they are not granted admin privileges, as per their default role.”);
upon initiating the first rule engine session, generating, in a non-persistent memory database, a first non-persistent run-time file for validating the first input data using the first rule template and the first version; validating the first input data using the first non-persistent run-time file (HINRICHS col 17; lines 32-39 “On the other hand, when the evaluation engine determines (at 515) that the cache storage does not store a reference to a previously defined rule structure for the API call identified in the received request, the evaluation engine directs (at 525) the policy and data fetcher 415 to retrieve from the local namespace portion 425 the policy opcode and operands applicable to the identified API call.”, HINRICHS col 17; lines 53-64 “After retrieving the policy opcode and one or more associated operands, the fetcher 415 directs (at 530) the rule compiler 430 to create a more optimal runtime rule and parameter structure 435 for the evaluation engine to process. As described above, the policy opcode for an API call includes one or more rules, with each rule expressing one or more conditions for rejecting (or allowing) the API call. In some embodiments, the optimal runtime rule and parameter 435 structure includes “prepared rules” that are generated by the compiler. Prepared rules are rules that are parsed from the retrieved, compiled and optimized policy opcode that is retrieved by the fetcher for the API call.”, HINRICHS col 18; lines 9-16 “Once the rule compiler creates (at 530) the more optimal rule structure, it notifies (at 535) the evaluation engine 410 directly or through the fetcher 415. The evaluation engine then processes (at 535) the rules in this rule structure. In some embodiments, the evaluation engine uses the parameters retrieved from the namespace and/or received with the API request to resolve these rules (e.g., conditions specified by the rules).”);
upon validating the first input data using the first non-persistent run-time file, after initiating the first rule engine session, and prior to ending the first rule engine session: receiving a version update to the first rule, and storing, in the plurality of versions of the first rule in the persistent memory database, a second version of the plurality of versions based on the version update(HINRICHS col 5; lines 5-11 & 32-38 “The server set in some embodiments updates these parameters dynamically in real time. Accordingly, in some embodiments, the server set uses, collects, and updates parameters for resolving policies dynamically and in a deployment specific manner (i.e., in a manner that can be context specific for each set of associated machines for which the server set is deployed).”, “The server set in some embodiments identifies updates to parameters for evaluating the policies and stores these updates in this storage structure along with the authorization policies. In some embodiments, the runtime storage structure (e.g., the namespace) stores the policy for authorizing each API call as one or more lines of opcode (as one or more opcode expressions/statements).”, HINRICHS col 8-9; lines 65-7 “For instance, in these embodiments, once a local agent initializes, it queries the server set for policies and parameters relevant to it. In these embodiments, the local agent also periodically polls the server set to determine whether policies or parameters that the local agent previously received have been updated on the server set and thereby need to be copied on the local agent's portion of the namespace. When such updates exist, the local agent retrieves them from the server set or receives them as part of its querying poll.”, HINRICHS col 23; lines 4-16 “This interface includes (1) a download API that provides the functionality to download a bundle of policies and related data, and then request its next version, if a new version is available… In some embodiments, the agent interface 1025 provides local namespace portions and updates to these portions in response to queries for the namespaces and updates to the namespaces.”);
Further regarding claim 1, HINRICHS teaches the limitations previously demonstrated; HINRICHS does not teach but in related art GUPTA teaches:
generating for display, on a user interface, a validation confirmation for the first input data; and ending the first rule engine session (GUPTA (col 9, lines 57-65) "If the infrastructure component is verified (e.g., the cloud computing user is satisfied with the verification operations), then the cloud computing user can generate and transmit a remote attestation on-boarding request for the infrastructure component to the remote attester 102 (block 306). On the other hand, if the infrastructure component is unverified, then the cloud computing user can transmit a notification (e.g., to the cloud computing environment 120) indicating that the infrastructure component has failed verification.").
Since both HINRICHS and GUPTA are from the same field of endeavor as both are directed to network security and surveilling traffic present on a computer network - which is within the same field of endeavor as the claimed invention. It would have been obvious to one skilled in the art before the effective filing date of the claimed invention to modify and combine the teachings of HINRICHS and GUPTA by incorporating the teachings of GUPTA into HINRICHS for network security and surveillance as claimed. The motivation to combine is to improve the security and analysis thereof for computer networks (HINRICHS, [AB]; GUPTA, [AB]).
Regarding claim 2, HINRICHS-GUPTA teaches the system of claim 1, and claim 2 recites substantially the same limitations as claim 1 respectfully in the form of a method. HINRICHS further teaches (HINRICHS abstract “Some embodiments provide a method for enforcing policies for authorizing API (Application Programming Interface) calls to an application operating on a host machine.”)
Therefore, claim 2 is rejected under the same rationale.
Regarding claim 3, HINRICHS-GUPTA teaches the method of claim 2, HINRICHS-GUPTA also teaches:
Wherein receiving the first request to process the first input data using the first rule comprises: receiving a first user input selecting a first validation set for the first input data (HINRICHS col 2-3; lines 59-3 "In SAML, as the user accesses the application, and has no open authentication session, the application redirects the user (his browser) to the Identity Provider (IDP). IDP then authenticates the user and as a result, send a SAML response back to the user browser which then delivers it to the original application. Now application, as it trusts the IDP, can open and verify the response and extract the user identity stored inside the response. Identity provider can also provide additional “claims” inside the response that give more details about the user, for instance the group(s) he is member of (or roles he has).", HINRICHS col 27; lines 21-28 “The reply contains additional authentication field parameters that will be interpreted by the service 1220. The policy 1320 states that the user 1210 is assigned a role of admin on Mondays. Accordingly, the API-authorization system 1225 evaluates the policy, determines that today is Monday, and modifies the authentication field parameters in the reply 1325 to reflect the changed role.”);
determining, based on the first validation set, a first when condition, wherein the first when condition indicates one first condition for executing the first rule (GUPTA (col. 9, lines 2-8) "Here, a cloud computing user can choose to rotate an attestation policy for an infrastructure component on a periodic basis (e.g., hourly, daily, weekly, or some other time frame) by selecting periodic option 440) or on a trigger-basis (e.g., receive an indication that a security event has occurred) by selecting trigger-based option 442.");
and determining, based on the first input data, that the first when condition is satisfied (GUPTA (col 9, lines 9-17) The validation configuration 436 generally specifies the conditions under which an attestation policy for an infrastructure component should be validated by a remote attester 102. Here, a cloud computing user can choose to validate an attestation policy for an infrastructure component on a periodic basis (e.g., hourly, daily, or some other time frame) by selecting periodic option 444 and/or selecting event-based options (e.g., code deployment 446, incoming request 448, etc.).).
Regarding claim 4, HINRICHS-GUPTA teaches the method of claim 3, HINRICHS-GUPTA also teaches:
Wherein determining, based on the first validation set, a first when condition, comprises: retrieving, from the persistent memory database, a first database record (HINRICHS col 23; lines 18-31 “As mentioned above, the policy and content document database 1035 in some embodiments is a custom namespace database. This database can persist both policies and any data the policies need in their evaluation. In some embodiments, the database saves policies as plain source code, while storing the data as JSON documents. The policy and content database 1035 in some embodiments includes a hierarchical namespace for each entity in one or more datacenters for which the server set defines and distributes API-authorization policies. As this database 1035 merges the data and policies into one global hierarchical namespace layout, database clients can access a nested portion of the namespaces simply by requesting policy operands by their fully qualified names”),
wherein the first database record indicates a plurality of when conditions corresponding to the first validation set (HINRICHS col 28 lines 59-63 “That is, the API-authorization system 1225 can use the policies to decide which pre-existing groups the client 1210 is a member of, at given times, for given applications. These decisions can use any context available in the system's services.”);
retrieving, from the first database record, the plurality of when conditions (HINRICHS col 2; lines 21-32 "Therefore, by acting as an LDAP server at a protocol level, that operates over a virtual directory—its contents defined by policies—the API-authorization system of some embodiments can not only decide whether to let the user in to a particular application but more importantly construct the group contents based on policies. That is, the API-authorization system can let the policies decide which groups the user is member of, at given times, for given applications. These decisions can use any context available in the system's services. For instance, the system could easily include users to an admin group if they are operations on-call this week. ");
and storing the plurality of when conditions in the non-persistent memory database (HINRICHS col 23; lines 3-10 “The local agents 220 communicate with server modules 1010 by using APIs of the server's agent interface 1025. This interface includes (1) a download API that provides the functionality to download a bundle of policies and related data, and then request its next version, if a new version is available, and (2) an upload API that provides the functionality for the agents to report back any policy decisions they have made.”).
Regarding claim 5, HINRICHS-GUPTA teaches the method of claim 3, HINRICHS-GUPTA also teaches:
wherein determining, based on the first validation set, a first when condition, comprises: retrieving, from the persistent memory database, a first database record, wherein the first database record indicates a plurality of rules corresponding to the first validation set (GUPTA (col 2, lines 30-40) "In general, a cloud computing user can perform remote attestation to determine a level of trust in a cloud computing environment. Remote attestation generally refers to a method (or technique) in which a cloud host (or attestator) authenticates its computing resources (or infrastructure components) to a remote server (cloud computing user or challenger). A remote attestation protocol generally involves the exchange of security information (e.g., cryptographic keys or hashes) between the cloud host and cloud computing user in order to assure the integrity of the cloud host to the remote server.");
and filtering the plurality of rules based on the first rule template to select the first when condition (HINRICHS col 2; lines 14-20 " Typically, the servers also query for group information to identify the group membership of the users. Applications have then configured (or hardcoded) the group names and the permissions to which the groups map. As a result, after authentication these systems know the group that the user belongs to and hence the permissions that he/she should be given.", HINRICHS col 25-26; lines 66-4 “These protocols provide at minimum a means to authenticate the user and permit or deny access. These protocols also may include group and role information of a user, which then indirectly controls the permissions available to the user in a more fine-grained manner.”).
Regarding claim 6, HINRICHS-GUPTA teaches the method of claim 3, HINRICHS-GUPTA also teaches:
Wherein validating the first input data using the first non-persistent run-time file comprises: determining, based on the first validation set, a first then condition, wherein the first then condition indicates a process executed by the first rule; and processing, based on the first then condition, the first input data to generate a first result (HINRICHS col 2; lines 14-20 " Typically, the servers also query for group information to identify the group membership of the users. Applications have then configured (or hardcoded) the group names and the permissions to which the groups map. As a result, after authentication these systems know the group that the user belongs to and hence the permissions that he/she should be given.", HINRICHS col 25-26; lines 66-4 “These protocols provide at minimum a means to authenticate the user and permit or deny access. These protocols also may include group and role information of a user, which then indirectly controls the permissions available to the user in a more fine-grained manner.”).
Regarding claim 8, HINRICHS-GUPTA teaches the method of claim 2, HINRICHS-GUPTA also teaches:
receiving a second request to process second input data using the first rule (HINRICHS col 2; lines 13-20 "Typically, the servers also query for group information to identify the group membership of the users. Applications have then configured (or hardcoded) the group names and the permissions to which the groups map. As a result, after authentication these systems know the group that the user belongs to and hence the permissions that he/she should be given.", col 8; lines 33-45 “In some embodiments, the server set distributes the defined policies and parameters to local agents 120 that enforce these API-authorization policies for the applications 115, and these local agents 120 store the distributed policies and parameters in their local policy/parameter store 150. In some of the embodiments that store the policies and parameters in a namespace, the server set distributes different portions of the namespace to different host computers based on the policies that are relevant to the API-authorization processing for the first set of applications 115 executing on the different host computers. The different portions that are distributed to the different host computers can be overlapping in some embodiments.”);
in response to the second request: retrieving the first rule template, and initiating a second rule engine session (HINRICHS col 2; lines 13-20 “Typically, the servers also query for group information to identify the group membership of the users. Applications have then configured (or hardcoded) the group names and the permissions to which the groups map. As a result, after authentication these systems know the group that the user belongs to and hence the permissions that he/she should be given.”, HINRICHS col 17; lines 32-41 “The service 1220 receives the modified reply 1325 and grants access to the user 1210 with the admin role instead of the member role. The RBAC system 1235 (not shown) of the service 1220 then assigns access permissions to the user 1210 based on the admin role instead of the member role. As a result, anytime the user logs in to the system while on call, the system 1225 can automatically assign them to the administrator group. If the user logs on while not on call, then they are not granted admin privileges, as per their default role.”);
upon initiating the second rule engine session, generating, in the non-persistent memory database, a second non-persistent run-time file for validating the second input data using the first rule template (HINRICHS col 17; lines 32-39 “On the other hand, when the evaluation engine determines (at 515) that the cache storage does not store a reference to a previously defined rule structure for the API call identified in the received request, the evaluation engine directs (at 525) the policy and data fetcher 415 to retrieve from the local namespace portion 425 the policy opcode and operands applicable to the identified API call.”, HINRICHS col 17; lines 53-64 “After retrieving the policy opcode and one or more associated operands, the fetcher 415 directs (at 530) the rule compiler 430 to create a more optimal runtime rule and parameter structure 435 for the evaluation engine to process. As described above, the policy opcode for an API call includes one or more rules, with each rule expressing one or more conditions for rejecting (or allowing) the API call. In some embodiments, the optimal runtime rule and parameter 435 structure includes “prepared rules” that are generated by the compiler. Prepared rules are rules that are parsed from the retrieved, compiled and optimized policy opcode that is retrieved by the fetcher for the API call.”, HINRICHS col 18; lines 9-16 “Once the rule compiler creates (at 530) the more optimal rule structure, it notifies (at 535) the evaluation engine 410 directly or through the fetcher 415. The evaluation engine then processes (at 535) the rules in this rule structure. In some embodiments, the evaluation engine uses the parameters retrieved from the namespace and/or received with the API request to resolve these rules (e.g., conditions specified by the rules).” col 8; lines 33-45 “In some embodiments, the server set distributes the defined policies and parameters to local agents 120 that enforce these API-authorization policies for the applications 115, and these local agents 120 store the distributed policies and parameters in their local policy/parameter store 150. In some of the embodiments that store the policies and parameters in a namespace, the server set distributes different portions of the namespace to different host computers based on the policies that are relevant to the API-authorization processing for the first set of applications 115 executing on the different host computers. The different portions that are distributed to the different host computers can be overlapping in some embodiments.”);
and validating the second input data using the second non-persistent run-time file (HINRICHS col 18; lines 9-16 “Once the rule compiler creates (at 530) the more optimal rule structure, it notifies (at 535) the evaluation engine 410 directly or through the fetcher 415. The evaluation engine then processes (at 535) the rules in this rule structure. In some embodiments, the evaluation engine uses the parameters retrieved from the namespace and/or received with the API request to resolve these rules (e.g., conditions specified by the rules).”).
Regarding claim 9, HINRICHS-GUPTA teaches the method of claim 2, HINRICHS-GUPTA also teaches:
Wherein storing the first rule comprises: storing a plurality of versions of the first rule in the persistent memory database (HINRICHS col 23; lines 32-34 " The server set copy of the policy and content database 1035 in some embodiments can save all versions of the data and policies over time for an entity.");
determining, in response to receiving the first request to process the first input data using the first rule, a first version of the plurality of versions (HINRICHS col 23; lines 32-39 “The server set copy of the policy and content database 1035 in some embodiments can save all versions of the data and policies over time for an entity. When either a data or policy is updated, its previous version is not removed but archived in some embodiments. This allows time traversal: the server set can inspect the state of policies and their related data at any point in time by simply defining the time of interest when accessing the namespace.”, HINRICHS col 24; lines 31-36 “This combined with versioning allows the system to provide versioned snapshots of the entire datacenter state, if needed. For example, in some embodiments, the local agents identify the namespace versions that they use to process the API-authorization requests and provide this version information to the server set to store in the decision logs 1042.”);
and using the first version to process the first input data (HINRICHS col 23; lines 32-39 “The server set copy of the policy and content database 1035 in some embodiments can save all versions of the data and policies over time for an entity. When either a data or policy is updated, its previous version is not removed but archived in some embodiments. This allows time traversal: the server set can inspect the state of policies and their related data at any point in time by simply defining the time of interest when accessing the namespace.”, HINRICHS col 24; lines 31-36 “This combined with versioning allows the system to provide versioned snapshots of the entire datacenter state, if needed. For example, in some embodiments, the local agents identify the namespace versions that they use to process the API-authorization requests and provide this version information to the server set to store in the decision logs 1042.”).
Regarding claim 11, HINRICHS-GUPTA teaches the method of claim 2, HINRICHS-GUPTA also teaches:
after initiating the first rule engine session, and prior to ending the first rule engine session, receiving a second request to process second input data using the first rule (HINRICHS col 2; lines 13-20 “Typically, the servers also query for group information to identify the group membership of the users. Applications have then configured (or hardcoded) the group names and the permissions to which the groups map. As a result, after authentication these systems know the group that the user belongs to and hence the permissions that he/she should be given.”, col 9; lines 8-13 “The local agent 120, executing on a host computer 110, receives requests to determine whether API calls received by one or more applications 115 executing on the host computer are authorized. The local agent in some embodiments receives each request to authorize an API call to an application from an authorization module of that application.”);
in response to the second request: retrieving the first rule template, and initiating a second rule engine session (HINRICHS col 2; lines 13-20 “Typically, the servers also query for group information to identify the group membership of the users. Applications have then configured (or hardcoded) the group names and the permissions to which the groups map. As a result, after authentication these systems know the group that the user belongs to and hence the permissions that he/she should be given.”, HINRICHS col 17; lines 32-41 “The service 1220 receives the modified reply 1325 and grants access to the user 1210 with the admin role instead of the member role. The RBAC system 1235 (not shown) of the service 1220 then assigns access permissions to the user 1210 based on the admin role instead of the member role. As a result, anytime the user logs in to the system while on call, the system 1225 can automatically assign them to the administrator group. If the user logs on while not on call, then they are not granted admin privileges, as per their default role.”);
upon initiating the second rule engine session, generating, in the non-persistent memory database, a second non-persistent run-time file for validating the second input data using the first rule template and the second version (HINRICHS col 17; lines 32-39 “On the other hand, when the evaluation engine determines (at 515) that the cache storage does not store a reference to a previously defined rule structure for the API call identified in the received request, the evaluation engine directs (at 525) the policy and data fetcher 415 to retrieve from the local namespace portion 425 the policy opcode and operands applicable to the identified API call.”, HINRICHS col 17; lines 53-64 “After retrieving the policy opcode and one or more associated operands, the fetcher 415 directs (at 530) the rule compiler 430 to create a more optimal runtime rule and parameter structure 435 for the evaluation engine to process. As described above, the policy opcode for an API call includes one or more rules, with each rule expressing one or more conditions for rejecting (or allowing) the API call. In some embodiments, the optimal runtime rule and parameter 435 structure includes “prepared rules” that are generated by the compiler. Prepared rules are rules that are parsed from the retrieved, compiled and optimized policy opcode that is retrieved by the fetcher for the API call.”, HINRICHS col 18; lines 9-16 “Once the rule compiler creates (at 530) the more optimal rule structure, it notifies (at 535) the evaluation engine 410 directly or through the fetcher 415. The evaluation engine then processes (at 535) the rules in this rule structure. In some embodiments, the evaluation engine uses the parameters retrieved from the namespace and/or received with the API request to resolve these rules (e.g., conditions specified by the rules).”, col 8-9; lines 66-7 “once a local agent initializes, it queries the server set for policies and parameters relevant to it. In these embodiments, the local agent also periodically polls the server set to determine whether policies or parameters that the local agent previously received have been updated on the server set and thereby need to be copied on the local agent's portion of the namespace. When such updates exist, the local agent retrieves them from the server set or receives them as part of its querying poll.”);
and validating the first input data using the second non-persistent run-time file (HINRICHS col 18; lines 9-16 “Once the rule compiler creates (at 530) the more optimal rule structure, it notifies (at 535) the evaluation engine 410 directly or through the fetcher 415. The evaluation engine then processes (at 535) the rules in this rule structure. In some embodiments, the evaluation engine uses the parameters retrieved from the namespace and/or received with the API request to resolve these rules (e.g., conditions specified by the rules).”).
Regarding claim 12, HINRICHS-GUPTA teaches the method of claim 2, HINRICHS-GUPTA also teaches:
determining, based on the first request, a first version of the plurality of versions to process the first input data (HINRICHS col 23; lines 32-39 “The server set copy of the policy and content database 1035 in some embodiments can save all versions of the data and policies over time for an entity. When either a data or policy is updated, its previous version is not removed but archived in some embodiments. This allows time traversal: the server set can inspect the state of policies and their related data at any point in time by simply defining the time of interest when accessing the namespace.”, HINRICHS col 24; lines 31-36 “This combined with versioning allows the system to provide versioned snapshots of the entire datacenter state, if needed. For example, in some embodiments, the local agents identify the namespace versions that they use to process the API-authorization requests and provide this version information to the server set to store in the decision logs 1042.”).
Regarding claim 13, HINRICHS-GUPTA teaches the method of claim 12, HINRICHS-GUPTA also teaches:
The method of claim 12, further comprising: upon validating the first input data using the first non-persistent run-time file: receiving the version update to the first rule, and storing, in the plurality of versions of the first rule in the persistent memory database, the second version of the plurality of versions (HINRICHS col 5; lines 5-11 & 32-38 “The server set in some embodiments updates these parameters dynamically in real time. Accordingly, in some embodiments, the server set uses, collects, and updates parameters for resolving policies dynamically and in a deployment specific manner (i.e., in a manner that can be context specific for each set of associated machines for which the server set is deployed).”, “The server set in some embodiments identifies updates to parameters for evaluating the policies and stores these updates in this storage structure along with the authorization policies. In some embodiments, the runtime storage structure (e.g., the namespace) stores the policy for authorizing each API call as one or more lines of opcode (as one or more opcode expressions/statements).”, HINRICHS col 8-9; lines 65-7 “For instance, in these embodiments, once a local agent initializes, it queries the server set for policies and parameters relevant to it. In these embodiments, the local agent also periodically polls the server set to determine whether policies or parameters that the local agent previously received have been updated on the server set and thereby need to be copied on the local agent's portion of the namespace. When such updates exist, the local agent retrieves them from the server set or receives them as part of its querying poll.”, HINRICHS col 23; lines 4-16 “This interface includes (1) a download API that provides the functionality to download a bundle of policies and related data, and then request its next version, if a new version is available… In some embodiments, the agent interface 1025 provides local namespace portions and updates to these portions in response to queries for the namespaces and updates to the namespaces.”).
Regarding claim 14, HINRICHS-GUPTA teaches the method of claim 13, HINRICHS-GUPTA also teaches:
Upon validating the first input data using the first non-persistent run-time file: receiving a second request to process second input data using the first rule (HINRICHS col 25-26; lines 58-4 “The third interface in some embodiments uses authentication protocols 1130 to piggyback authorization information to an Internet-based application or service 1135 (e.g. Dropbox, etc.) at the time of user authentication. Examples of such authentication protocols include Security Assertion Markup Language (SAML), OpenID Connect (OIDC), Remote Authentication Dial-In Service (RADIUS), Kerberos, and Lightweight Directory Access Protocol (LDAP) (including Microsoft Active Directory). These protocols provide at minimum a means to authenticate the user and permit or deny access. These protocols also may include group and role information of a user, which then indirectly controls the permissions available to the user in a more fine-grained manner.”);
In response to the second request: retrieving the first rule template, and initiating a second rule engine session (HINRICHS col 2; lines 13-20 “Typically, the servers also query for group information to identify the group membership of the users. Applications have then configured (or hardcoded) the group names and the permissions to which the groups map. As a result, after authentication these systems know the group that the user belongs to and hence the permissions that he/she should be given.”, HINRICHS col 17; lines 32-41 “The service 1220 receives the modified reply 1325 and grants access to the user 1210 with the admin role instead of the member role. The RBAC system 1235 (not shown) of the service 1220 then assigns access permissions to the user 1210 based on the admin role instead of the member role. As a result, anytime the user logs in to the system while on call, the system 1225 can automatically assign them to the administrator group. If the user logs on while not on call, then they are not granted admin privileges, as per their default role.”);
Upon initiating the second rule engine session, generating, in the non-persistent memory database, a second non-persistent run-time file for validating the second input data using the first rule template and the second version (HINRICHS col 17; lines 32-39 “On the other hand, when the evaluation engine determines (at 515) that the cache storage does not store a reference to a previously defined rule structure for the API call identified in the received request, the evaluation engine directs (at 525) the policy and data fetcher 415 to retrieve from the local namespace portion 425 the policy opcode and operands applicable to the identified API call.”, HINRICHS col 17; lines 53-64 “After retrieving the policy opcode and one or more associated operands, the fetcher 415 directs (at 530) the rule compiler 430 to create a more optimal runtime rule and parameter structure 435 for the evaluation engine to process. As described above, the policy opcode for an API call includes one or more rules, with each rule expressing one or more conditions for rejecting (or allowing) the API call. In some embodiments, the optimal runtime rule and parameter 435 structure includes “prepared rules” that are generated by the compiler. Prepared rules are rules that are parsed from the retrieved, compiled and optimized policy opcode that is retrieved by the fetcher for the API call.”, HINRICHS col 18; lines 9-16 “Once the rule compiler creates (at 530) the more optimal rule structure, it notifies (at 535) the evaluation engine 410 directly or through the fetcher 415. The evaluation engine then processes (at 535) the rules in this rule structure. In some embodiments, the evaluation engine uses the parameters retrieved from the namespace and/or received with the API request to resolve these rules (e.g., conditions specified by the rules).” col 8; lines 33-45 “In some embodiments, the server set distributes the defined policies and parameters to local agents 120 that enforce these API-authorization policies for the applications 115, and these local agents 120 store the distributed policies and parameters in their local policy/parameter store 150. In some of the embodiments that store the policies and parameters in a namespace, the server set distributes different portions of the namespace to different host computers based on the policies that are relevant to the API-authorization processing for the first set of applications 115 executing on the different host computers. The different portions that are distributed to the different host computers can be overlapping in some embodiments.”);
and validating the first input data using the second non-persistent run-time file (HINRICHS col 18; lines 9-16 “Once the rule compiler creates (at 530) the more optimal rule structure, it notifies (at 535) the evaluation engine 410 directly or through the fetcher 415. The evaluation engine then processes (at 535) the rules in this rule structure. In some embodiments, the evaluation engine uses the parameters retrieved from the namespace and/or received with the API request to resolve these rules (e.g., conditions specified by the rules).”).
Regarding claims 15-20, HINRICHS-GUPTA teaches the system of claims (1, 3-7, 9) and claims 15-20 recites substantially the same limitations as claims (1, 3-7, 9) respectfully in the form of a non-transitory, computer readable medium. HINRICHS further teaches (HINRICHS col 32 lines 15-22 “As used in this specification, the terms “computer readable medium,” “computer readable media,” and “machine readable medium” are entirely restricted to tangible, physical objects that store information in a form that is readable by a computer. These terms exclude any wireless signals, wired download signals, and any other ephemeral or transitory signals.”)
Therefore, claims 15-20 are rejected under the same rationale.
Claim(s) (7) is rejected under 35 U.S.C. 103 as being unpatentable over HINRICHS in view of GUPTA as applied to claims 1 and 2 above, and further in view of LARGMAN (US 20040236874 A1).
Regarding claim 7, HINRICHS-GUPTA teaches the method of claim 2; HINRICHS-GUPTA does not teach but in related art LARGMAN teaches:
determining, based on the first rule template, a first format for the first input data ([0292] “In one embodiment, the logic of a CE may trigger an event associated with a repair process. The repair process may perform a comparison between a master template of the working system and state of the current working system. Any differences between them could trigger a subsequent repair process in which some or all data that is different is deleted from the working system.”); and reformatting the first input data into the first format ([0302] “In one embodiment, a repair process may be conducted which may consist of or include, for example, one or more of the following: (a) making software in the CE identical and/or partially identical to all or part of a Master Template, (b) deleting and/or repairing the computing environment or portion thereof such as the computing environment storage ("explosion room"), and/or switching to a secondary CE, (c) reformatting and/or repairing one or more data storage devices, master boot records, partition tables, or the like,”).
Since both HINRICHS-GUPTA and LARGMAN are from the same field of endeavor as both are directed to network security and surveilling activity present on a computer network - which is within the same field of endeavor as the claimed invention. It would have been obvious to one skilled in the art before the effective filing date of the claimed invention to modify and combine the teachings of HINRICHS-GUPTA and LARGMAN by incorporating the teachings of LARGMAN into HINRICHS-GUPTA for network security and surveillance as claimed. The motivation to combine is to improve the security and analysis thereof for computer networks (HINRICHS, [AB]; LARGMAN, [AB]).
Conclusion
The prior art made of record and not relied upon is considered pertinent to the applicant’s disclosure:
Mueller; Julius US 20230117867 A1 SYSTEM AND METHOD FOR PROVIDING TRANSITIVE BOOTSTRAPPING OF AN EMBEDDED SUBSCRIBER IDENTIFICATION MODULE ([AB] “A system and method for establishing a bootstrap bridge via a network interface device at an information handling system to provide a transitive bootstrapping process for an untrusted (new) information handling system, wherein the bootstrap bridge comprises a temporary network enabler for communicating with the untrusted (new) information handling system and a secure gateway for communicating with a trusted core network, and wherein the bootstrap bridge receives an authentication request from the untrusted (new) information handling system via the temporary network enabler, wherein the authentication request includes an untrusted (new) information handling system identification (ID) with temporary authentication data loaded to the untrusted (new) information handling system upon manufacture, and the network interface device to transmit a request for challenge for the untrusted (new) information handling system ID to the trusted core network via the secure gateway on behalf of the untrusted (new) information handling system.”)
KURA; Tsuneko US 20230015273 A1 VERIFICATION INFORMATION REVISING DEVICE, VERIFICATION INFORMATION REVISING METHOD, AND VERIFICATION INFORMATION REVISING PROGRAM ([AB] “A verification information modification device includes processing circuitry configured to acquire, from each verification device that uses verification information of software to verify a file forming the software, an error log relating to erroneous detection that has occurred in the verification device, when it is determined that a same error has occurred in a predetermined number or more of verification devices based on the acquired error log, extract an error log of the error from acquired error logs and create information indicating verification information that has caused the erroneous detection and candidates for modification details of the verification information based on the extracted error log, and output the information indicating verification information that has caused the erroneous detection and candidates for modification details of the verification information.”)
Hefley; Kendall L. US 20200021560 A1 POLICY ENGINE FOR CYBER ANOMALY DETECTION ([AB] “An industrial control system (ICS) communicates via ICS protocols. A model is deployed in an information technology (IT) and operation technology (OT) network. Security policies are dynamically updated as the particular IT and OT network are used, patched, and modified. A deep packet inspection is used to enforce ICS constraints and ICS behaviors defined by the initial model. A state of the deep packet inspection is reported for situational awareness and debugging purposes. An alert is transmitted when anomalies are detected when ICS protocol traffic traverses ICS firewall network paths that execute ICS policies.”)
Carson; James A. US 20190386817 A1 Dynamic Blockchain System And Method For Providing Efficient And Secure Distributed Data Access, Data Storage And Data Transport([AB] “A dynamic blockchain system includes: at least one complete asset node server, including a complete asset manager and a complete asset storage; a plurality of hash asset node servers, each including a hash asset manager and an asset blockchain and; a dynamic blockchain management server, including a blockchain manager, a representation calculation function, and an asset map with a plurality of map records; and a blockchain management device; such that the dynamic blockchain management server validates a digital asset by lookup in the at least one complete asset node server and by verification of the digital asset by a random sampling in a statistically representative number of hash asset node servers in the plurality of hash asset node servers.”)
TOBIAS; Eric US 20190205317 A1 SYSTEMS AND METHODS FOR SECURE STORAGE AND RETRIEVAL OF DATA OBJECTS([AB] “Systems and methods for storing, accessing and management a data object are provided. The systems comprise: a trusted file manager system comprising a plurality of data repositories corresponding to a plurality of storage locations configured to store encrypted data fragments; a secure server; and a client device comprising and an application running on the client device and one or more processors, the application communicatively coupled to the secure platform and the trusted file manager system.”)
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Kamryn Gillespie whose telephone number is 703-756-5498. The examiner can normally be reached on Monday through Thursday from 9am to 6pm.
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, Linglan Edwards can be reached on (571) 270-5440. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
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.
/K.J.G./Examiner, Art Unit 2408
/LINGLAN EDWARDS/Supervisory Patent Examiner, Art Unit 2408