Prosecution Insights
Last updated: April 19, 2026
Application No. 18/100,517

DYNAMIC INHERITANCE OF SECURITY POLICIES ACROSS DIFFERENT VIRTUAL SECURITY ZONES

Non-Final OA §103
Filed
Jan 23, 2023
Examiner
GRACIA, GARY S
Art Unit
2499
Tech Center
2400 — Computer Networks
Assignee
International Business Machines Corporation
OA Round
1 (Non-Final)
71%
Grant Probability
Favorable
1-2
OA Rounds
3y 0m
To Grant
99%
With Interview

Examiner Intelligence

Grants 71% — above average
71%
Career Allow Rate
390 granted / 551 resolved
+12.8% vs TC avg
Strong +50% interview lift
Without
With
+50.3%
Interview Lift
resolved cases with interview
Typical timeline
3y 0m
Avg Prosecution
29 currently pending
Career history
580
Total Applications
across all art units

Statute-Specific Performance

§101
11.3%
-28.7% vs TC avg
§103
60.9%
+20.9% vs TC avg
§102
11.8%
-28.2% vs TC avg
§112
9.3%
-30.7% vs TC avg
Black line = Tech Center average estimate • Based on career data from 551 resolved cases

Office Action

§103
CTNF 18/100,517 CTNF 86984 Notice of Pre-AIA or AIA Status 07-03-aia AIA 15-10-aia 1. The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA. Election/Restrictions 2. NO restrictions warranted at initial time of filing for patent. Information Disclosure Statement 06-52 3. The information disclosure statement (IDS) submitted on 01/23/2023, the submission is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner. Oath/Declaration 4. Applicant’s Oath was filed on 01/27/2023. Drawings 5. Applicant’s drawings filed on 01/23/2023 has been inspected and is in compliance with MPEP 608.01. Specification 6. Applicant’s specification filed on 01/23/2023 has been inspected and is in compliance with MPEP 608.02. Claim Objections 7. NO objections warranted at initial time of filing for patent. Remarks 8. Examiner request Applicant review relevant prior art under the conclusion of this office action. Claim Rejections - 35 USC § 103 07-20-aia AIA 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. 07-23-aia AIA The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows: 1. Determining the scope and contents of the prior art. 2. Ascertaining the differences between the prior art and the claims at issue. 3. Resolving the level of ordinary skill in the pertinent art. 4. Considering objective evidence present in the application indicating obviousness or nonobviousness. 07-21-aia AIA 9. Claims 1-20 are r ejected under 35 U.S.C. 103 as being unpatentable over U. S. Publication No. 20230108031 hereinafter Rohatgi in view of U.S. Publication No. 20220060517 hereinafter Dozorets, U.S. Publication No. 20200053091 hereinafter Childress. A s per claim 1, Rohatgi discloses: A computer-implemented method ( para 0026 “Accordingly, in one aspect, disclosed herein is a method that involves a computing system that defines a first zone of a multi-zone computing platform.”), comprising: determining whether a first user ( para 0120 “FIG. 6 depicts one example of the interactions that may occur between different zones of an example multi-zone computing platform , such as the MCP 300 , in order to process a data access request that is received by the MCP 300 . In the example of FIG. 6 , at 602 , a user may input a request to access certain user data, which may comprise one or more data objects , at a client station using a front-end interface of the SaaS application hosted by the MCP 300.” ), the first user being associated with a first virtual security zone that includes a first group of security policies has a need for a first security policy included in a second virtual security zone associated with a second user ( Fig. 4, Para 0107 “Further, the connected graph of FIG. 4 includes links 416 - 430 that embody the relationships (e.g., the logical connections) between the nodes 402 - 414 . FIG. 4 depicts a portion of the connected graph that embodies the various relationships between nodes 402 - 414 . For instance, node 402 for GC 1 is connected to node 410 for User 1, node 412 for User 2 and node 406 for Project 1 as shown by links 416 , 418 , and 420 , respectively, indicating a logical relationship between GC1 and each of User 1, User 2, and Project 1. For example, User 1 and User 2 may be users that are associated with GC 1 by virtue of being employees of GC 1, and Project 1 may be associated with GC 1 by virtue of GC 1 managing that project .” Fig. 5, Para 0114 “As shown in FIG. 5 , a solid double arrow 501 represents a direct access path between Zone 4 and the global representation 400 , indicating that Zone 4 is the designated zone of MCP 300 at which the global representation 400 is stored. When Zone 4 needs to obtain information from the global representation 400 , it may do so by directly accessing the global representation 400 .” Fig. 6, para 0121 “At 604 , the MCP 300 may receive the data access request from the client station. As mentioned above, the MCP 300 may receive the data access request at one particular receiving zone, which may be a zone that is physically nearest to the location of the client station (or at least in the same geographic region as the client station ).” Para 0128 “As another possibility, the one or more validation operations may include a permissions check that determines whether the user has permission to access the user data. To perform the permissions check, Zone 7 may use information included in the data access request received from the client station at 604 and/or the set(s) of metadata received from Zone 4 at 606 , among other possibilities . In one implementation, for instance, the set(s) of metadata received from Zone 4 at 606 may include relationship metadata—which, as previously discussed, may include information about the relationship between the user requesting access to the user data and the user data as well as information about the user's access permissions with respect to the user data. Such relationship information may be used by Zone 7 to determine if the user has the permission to access the user data .”), in response to a determination that the first user has a need for the first security policy included in the second virtual security zone, determining whether the first user is authorized to at least access the first security policy from the second virtual security zone ( Fig. 6, para 0124 “As another example, i f that information relating to the data access request includes one or more parameters, Zone 4 may conduct a query within the global representation using the query parameters and the relevant relationship metadata in order to obtain the set(s) of metadata . For example, if the query includes a request for information regarding all projects associated with a given user identifier, Zone 4 may (i) look up the given user identifier, (ii) determine, based on available relationship metadata for the given user, each project data object with which the given user has a relationship, (iii) obtain, from the global representation, a respective set of metadata for each project data object that is associated with the given user, and then (iv) return the obtained respective set(s) of metadata to Zone 7 .” Para 0129 “As yet another possibility, the one or more validation operations may include a data export regulations check that determines whether allowing the requested access to the user data would violate any relevant data export regulations. T o perform the data export regulations check, Zone 7 may use information included in the data access request received from the client station at 604 and/or the set(s) of metadata received from Zone 4 at 606 , among other possibilities . In one implementation, for instance, Zone 7 may determine the physical location of the client station and the physical location of the particular zone where the user data is stored, determine if any regional data export regulations apply to the user data based on the physical location of the particular zone, and then determine if allowing the client station to access the user data from the particular zone would violate any applicable regulations .” Para 0132 “To illustrate with an example based on FIG. 6 , as part of performing the data export regulations check at 608 , Zone 7 may determine that (i) based on the routing address included in the metadata received from Zone 4, the user data resides at Zone 1 located in the United States, (ii) based on information included in the data access request received from the client station, the client station is located in the same geographical region as Zone 7 located in Europe, and (iii) United States data export regulations do not impose any restrictions on data stored in the United States being exported to Europe. Therefore, Zone 7 may determine that allowing the client station to access the user data will not violate any applicable data export regulations, and thus, the data export regulations check has succeeded .”); Rohatgi does not disclose: determining whether the first user is authorized to at least temporarily inherit the first security policy from the second virtual security zone and in response to a determination that the first user is authorized to at least temporarily inherit the first security policy, causing the first security policy to be inherited by the first virtual security zone from the second virtual security zone Dozorets discloses: determining whether the first user is authorized to at least inherit the first security policy from the second virtual security zone, and in response to a determination that the first user is authorized to at least inherit the first security policy, causing the first security policy to be inherited by the first virtual security zone from the second virtual security zone ( para 0077 “The processing depicted in FIG. 4 is initiated at block 402 when the security zone policy validation subsystem 118 receives a request to perform an operation on a resource. For instance, the request may identify an operation (e.g., a “launch instance” operation) to be performed on an “instance” (i.e., virtual machine instance) to create a virtual machine instance in the user's tenancy using a public IP address . At block 404 , the security zone policy validation subsystem 118 determines a compartment associated with the resource. At block 406 , the security zone policy validation subsystem 118 determines, based on the compartment identified in block 404 , a set of compartment policies that are applicable to the resource. The compartment policies applicable to the resource may include compartment policies associated with the compartment in addition to the compartment policies of one or more parent compartments that are hierarchically related to the compartment . At block 408 , the security zone policy validation subsystem 118 determines if the operation on the resource is permitted based on the compartment policies determined in block 406 . For instance, the compartment policies applicable to the resource may permit the user to create the virtual machine instance so that it is publicly accessible from a public network (i.e., the Internet), i.e., permit the virtual machine instance to be created using a public IP address .” Para 0080 “FIG. 5A is an exemplary illustration of the inheritance of compartment policies by a compartment created by a user of a tenant of the CSPI shown in FIG. 1, according to certain embodiments. In the example depicted in FIG. 5A, c ompartment C 1 502 , compartment C 2 504 and compartment C 3 506 are hierarchically related to one another, where compartment C 1 502 is a parent compartment of compartment C 2 504 and compartment C 2 504 is a parent compartment of compartment C 3 506 . Compartment C 1 502 is associated with a set of compartment policies 508 that allow an operation O 1 to be performed on a set of resources residing in the compartment. Compartment C 2 504 is associated with a set of compartment policies 510 that allow an operation O 2 to be performed on a set of resources residing in the compartment. Because compartment C 2 504 is a child compartment of compartment C 1 502 , it automatically inherits the compartment policies 508 of compartment C 1 502 . Compartment C 3 506 is associated with a set of compartment policies 512 that allows an operation O 3 to be performed on a set of resources residing in the compartment. Because, compartment C 3 506 is a child compartment of both compartment C 2 504 and compartment C 1 502 , it automatically inherits the compartment policies 510 of compartment C 2 504 as well as those of compartment C 1 502 .” Para 0081 “FIG. 5B is an exemplary illustration of the inheritance of security zone policies associated with a security zone by a compartment created by a tenant of the CSPI shown in FIG. 1 , according to certain embodiments. The example depicted in FIG. 5B illustrates the compartment C 1 502 , compartment C 2 504 and compartment C 3 506 depicted in FIG. 5A along with their associated compartment policies 508 , 510 and 512 . In certain examples, w hen a compartment (e.g., compartment C 3 506 ) becomes associated with a security zone (security zone- 1 514 ), the security zone policies 516 associated with the security zone- 1 514 are applied to the compartment . Due to the association of the compartment C 3 506 with the security zone policies 516 , the set of operations (O 1 , O 2 , O 3 ) that were originally allowed to be performed on a resource R 1 residing in the compartment is now reduced to a subset of operations (O 1 ). Thus, the security zone policies represent an additional layer of security policies that may be enforced on a set of resources residing in the compartment in addition to the compartment policies associated with the compartment.”) Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the computing system that defines a first zone of a multi-zone computing platform of Rohatgi to include determining whether the first user is authorized to at least inherit the first security policy from the second virtual security zone, and in response to a determination that the first user is authorized to at least inherit the first security policy, causing the first security policy to be inherited by the first virtual security zone from the second virtual security zone, as taught by Dozorets. The motivation would have been to provide a robust and secure framework for managing and enforcing security policies related to various resources managed in the cloud (Dozorets para 0004). Rohatgi in view of Dozorets do not disclose: temporarily inherit the first security policy Childress discloses: temporarily inherit the first security policy ( para 0010 “After an authentication of the first user, the application can determine a set of default access permissions for the first user based on the permanent access permissions . The application can store the default access permissions as the temporary access permissions in memory. T he application can dynamically modify the temporary access permission for the first user by applying a granular access permission to the first user. The granular access permissions can be a scope limited access permission or a temporally limited access permission . The scope limited access permission can limit actions associated with an object, a component, an application, a program, a system, or a project. The temporally limited access permission can limit actions for the first user before, during, or after a time period. The permanent access permissions can include security groups of users . The users in each security group can have the same set of the access permissions. The security group can have sub-groups that inherit the access permissions of the security group. The application can be further configured to dynamically modify at least one of the temporary access permissions of a user of a respective security group. The application can be further configured to remove the user from the security group when the dynamic modification of the temporary access permissions is inconsistent with the security group. The application can be further configured to determine the temporary access permission for an action requested by the first user before executing the action . The application can be further configured to provide a user interface including only actions that are permitted for the first user. The actions can be modified on the user interface due to a temporal limitation.”) Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the computing system that defines a first zone of a multi-zone computing platform of Rohatgi in view of Dozorets to include temporarily inherit the first security policy, as taught by Childress. The motivation would have been to dynamic granular user access permissions for a first user while an application is executing. As per claim 2, Rohatgi in view of Dozorets and Childress discloses: The computer-implemented method of claim 1, wherein the second virtual security zone includes the first security policy for a duration that the first security policy is inherited by the first virtual security zone ( Rohatgi para 0110 and 0132 “ Finally, node 408 for RFI 1 is further connected to node 410 for User 1 and node 412 for User 2 as shown by links 430 and 432 , respectively, indicating a logical relationship between RFI 1 and each of User 1 and User 2. For example, Users 1 and 2 may be users that are associated with RFI 1 by virtue of having been invited to edit RFI 1. Although not shown, the connected graph of FIG. 4 may also include, as part of the respective relationship metadata for User 1 and User 2, permissions data that indicates access permissions for each of User 1 and User 2 with respect to RFI 1 .”). As per claim 3, Rohatgi in view of Dozorets and Childress discloses: The computer-implemented method of claim 1, wherein the second virtual security zone does not include the first security policy for a duration that the first security policy is inherited by the first virtual security zone ( Rohatgi para 0108 “Node 404 for SC 1 is connected to node 406 for Project 1 and node 414 for User 3, as shown by links 422 and 424 , respectively, indicating a logical relationship between SC 1 and each of Project 1 and User 3. For example, User 3 may be a user that is associated with SC 1 by virtue of being an employee of SC 1, and Project 1 may be associated with SC 1 by virtue of SC 1 being contracted to work on that project..” Para 0132 “n another example not shown in FIG. 6 , the receiving zone may be, for example, Zone 1, and while performing the data export regulations check, the receiving zone may determine that (i) based on the routing address included in the metadata obtained from Zone 4, the user data resides at Zone 7 located in Europe, (ii) based on information included in the data access request received from the client station, the client station is located in the same geographical region as Zone 1 located in the United States, and (iii) European data export regulations do not permit data stored in Europe to be exported to the United States. Therefore, the receiving Zone 1 may determine that allowing the client station to access the user data will violate data export regulations, and thus, the data export regulations check has failed .”). As per claim 4, Rohatgi in view of Dozorets and Childress discloses: The computer-implemented method of claim 1, wherein the security policies are selected from the group consisting of: electronic access to at least some logical partitions of a predetermined server, access to predetermined processing resources, access to a predetermined collection of secured data, access to a predetermined network security key ( Rohatgi para 0093, 0105, 0106, and 0107 ). As per claim 5, Rohatgi in view of Dozorets and Childress discloses: The computer-implemented method of claim 1, comprising: outputting a query to a user device of a third user associated with a third virtual security zone, wherein the query is output to determine whether the first user is endorsed for inheriting the first security policy, wherein the determination of whether the first user is authorized to at least temporarily inherit the first security policy from the second virtual security zone is based on user experience of the first user and endorsements of the first user ( Rohatgi para 0137 “ As another possibility, in the event that a validation operation fails, the receiving zone may apply one or more exceptions that enable the validation operation to succeed based on some additional action, thus allowing the receiving zone to continue processing the data access request. For instance, in some implementations, if certain one or more validation operations fail, the receiving zone may prompt the client station for additional information that may enable the failed validation operation(s) to be re-validated . For example, if the security check fails and the receiving zone determines that the data access request is indicative of potential malicious activity (e.g., user authentication and user permissions checks succeed, but the receiving zone determines during the security check that the location of the client station is not a location typically associated with the user), the receiving zone may temporarily pause processing the request and transmit a prompt to a client station (which may be the same client station that transmitted the data access request or a different client station associated with a different user, such as the user's supervisor or a designated security officer associated with the user's employer that is responsible for reviewing malicious activity) indicating that the data access request has been identified as suspicious activity, along with an indication of the reasons why the request was flagged as suspicious, and perhaps also a request to confirm the requested access (e.g., t he MCP 300 may cause the client station to display a notification at the front-end user interface indicating that the MCP 300 has detected an unusual location for the user and prompting the user to confirm the request to access the user data ).” Sending a query to the general contractor element 402 in Fig. 4. ). As per claim 6, Rohatgi in view of Dozorets and Childress discloses: The computer-implemented method of claim 1, wherein the determination of whether the first user has a need for the first security policy is based on information obtained by a predetermined inspector daemon that is configured to monitor actions of the first user ( Rohatgi Fig. 6, para 0089, 0127 and 0128 ). As per claim 7, Rohatgi in view of Dozorets and Childress discloses: The computer-implemented method of claim 6, wherein the information is selected from the group consisting of: a history of actions initiated by the first user with respect to satisfying predetermined security protocols of a network associated with the security policies, the first security policies, and a scheduled workload associated with the first user ( Rohatgi para 0101 “As another possibility, relationship metadata may additionally include permissions data that defines information about permitted access to user data. For example, permissions data may define, for each data object that is related to a given user, whether the given user has permission to access that data object, and if so, to what extent (e.g., what are the given user's permissible actions with respect to that data object). For instance, permissions data may indicate that a given user's access permissions for a first data object include read and edit permissions for the first data object and the given user's access permissions for a second data object include read-only permissions for the second data object. As another example, permissions data may define, for each data object, whether the data object is subject to any data export regulations that may impact access to that data object by certain users .”). As per claim 8, Rohatgi in view of Dozorets and Childress discloses: The computer-implemented method of claim 1, comprising: in response to a determination that the first user is authorized to at least temporarily inherit the first security policy (Childress para 0010, Though Rohatgi in view of Dozorets discloses inherit a policy, Childress discloses determination that the first user is authorized to at least temporarily inherit the first security policy The motivation would have been to dynamic granular user access permissions for a first user while an application is executing.) outputting a proposal of the first virtual security zone inheriting the first security policy to a predetermined inspector daemon that is configured to authorize and/or deny proposed inheritances of security policies; and receiving an answer from the predetermined inspector daemon that indicates whether the first virtual security zone is authorized to at least temporarily inherit the first security policy from the second virtual security zone, wherein the first security policy is caused to be inherited by the first virtual security zone from the second virtual security zone in response to a determination that the answer indicates that the first virtual security zone is authorized to inherit the first security policy from the second virtual security zone ( para 0133 “Still, as another possibility, the one or more validation operations may include a security check that determines whether the request for access is indicative of suspicious activity (e.g., malicious or erroneous behavior). Such suspicious activity may be identified based on various factors, which may include, as some non-limiting examples, the type of access that is requested (e.g., deletion of confidential data, etc.) and/or the number of access requests made in a given amount of time (e.g., multiple requests from a same user within a short amount of time to delete a large amount of data, etc.), among other possibilities.” Para 0137 “As another possibility, in the event that a validation operation fails, the receiving zone may apply one or more exceptions that enable the validation operation to succeed based on some additional action , thus allowing the receiving zone to continue processing the data access request. For instance, in some implementations, if certain one or more validation operations fail, the receiving zone may prompt the client station for additional information that may enable the failed validation operation(s) to be re-validated. For example, if the security check fails and the receiving zone determines that the data access request is indicative of potential malicious activity (e.g., user authentication and user permissions checks succeed, but the receiving zone determines during the security check that the location of the client station is not a location typically associated with the user) , the receiving zone may temporarily pause processing the request and transmit a prompt to a client station (which may be the same client station that transmitted the data access request or a different client station associated with a different user, such as the user's supervisor or a designated security officer associated with the user's employer that is responsible for reviewing malicious activity) indicating that the data access request has been identified as suspicious activity, along with an indication of the reasons why the request was flagged as suspicious, and perhaps also a request to confirm the requested access (e.g., the MCP 300 may cause the client station to display a notification at the front-end user interface indicating that the MCP 300 has detected an unusual location for the user and prompting the user to confirm the request to access the user data).” ). As per claim 9, Rohatgi in view of Dozorets and Childress discloses: The computer-implemented method of claim 1, comprising: causing the first security policy to be withdrawn from the first virtual security zone in response to a determination that a predetermined condition is met, wherein the predetermined condition is selected from the group consisting of: a predetermined amount of time passing, a determination being made that the first user no longer has the need for the first security policy, and in response to a determination being made that a scheduled workload associated with the first user has been completed ( Dozorets para 0049 “ A compartment that is associated with a security zone automatically inherits a set of security zone policies associated with the security zone.” para 0051 “By way of example, the user may interact with the security zone policy enforcement system 112 to create compartments, associate a compartment with a security zone, add resources to a compartment, view security zone policies associated with a security zone, delete a compartment, create sub-compartments within a compartment, move a compartment to a different parent compartment within the same tenancy, designate a security zone as a “maximum security zone” and so on.” Although, Rohatgi discloses permissions associated with zone, Dozorets discloses causing the first security policy to be withdrawn from the first virtual security zone in response to a determination that a predetermined condition is met wherein a determination being made that the first user no longer has the need for the first security policy. The motivation would have been to provide a robust and secure framework for managing and enforcing security policies related to various resources managed in the cloud (Dozorets para 0004). ). As per claim 10, the implementation of the computer-implemented method of claim 1 will execute the computer program product (Rohatgi paragraph 0027) of claim 10. The claim is analyzed with respect to claim 1. As per claim 11, the claim is analyzed with respect to claim 2. As per claim 12, the claim is analyzed with respect to claim 3. As per claim 13, the claim is analyzed with respect to claim 4. As per claim 14, the claim is analyzed with respect to claim 5. As per claim 15, the claim is analyzed with respect to claim 6. As per claim 16, the claim is analyzed with respect to claim 7. As per claim 17, the claim is analyzed with respect to claim 8. As per claim 18, the claim is analyzed with respect to claim 9. As per claim 19, the implementation of the computer-implemented method of claim 1 will execute the system of claim 19. The claim is analyzed with respect to claim 1. As per claim 20, the claim is analyzed with respect to claim 2 . Conclusion 07-96 AIA 10. The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. U.S. Publication No. 20170329957 discloses Para 0153 “For example, a client that belongs to “tenant 1 ” may execute a request to get a token for “tenant 2 ” specifying a user in “tenant 3 .” As another example, a user living in “tenant 1 ” may need to perform an action in an application owned by “tenant 2 ”. Thus, the user needs to go to the resource namespace of “tenant 2 ” and request a token for themselves. Accordingly, delegation of authority is accomplished by identifying “who” can do “what” to “whom.” As yet another example, a first user working for a first organization (“tenant 1 ”) may allow a second user working for a second organization (“tenant 2 ”) to have access to a document hosted by a third organization (“tenant 3 ”). “ Para 0166 “In one embodiment, various tokens codify different tenancies. A URL token may identify the tenancy of the application that requests a service. An identity token may codify the identity of a user that is to be authenticated. An access token may identify multiple tenancies. For example, an access token may codify the tenancy that is the target of such access (e.g., an application tenancy) as well as the user tenancy of the user that is given access. A client assertion token may identify a client ID and the client tenancy. A user-assertion token may identify the user and the user tenancy.” Para 272 “FIG. 16 illustrates how the requested scope from the OAuth Access Token Request is handled by OAuth/Authorization Engine, and the allowed scope are computed. In one embodiment, all the permission set names defined as part of policies exactly match with the allowed values of requested scopes. The input to the functionality of FIG. 16 are principal(s) and requested scope. The principal refers to the identity of the Client and the User during OAuthTokenReuest flow. It provides information about the client/user such as Name, Tenancy, App roles they possess, etc. The output is the allowed scope.” Any inquiry concerning this communication or earlier communications from the examiner should be directed to GARY S GRACIA whose telephone number is (571)270-5192. The examiner can normally be reached Monday-Friday 9am-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, Philip Chea can be reached at 5712723951. 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. /GARY S GRACIA/Primary Examiner, Art Unit 2499 Application/Control Number: 18/100,517 Page 2 Art Unit: 2499 Application/Control Number: 18/100,517 Page 3 Art Unit: 2499 Application/Control Number: 18/100,517 Page 4 Art Unit: 2499 Application/Control Number: 18/100,517 Page 5 Art Unit: 2499 Application/Control Number: 18/100,517 Page 6 Art Unit: 2499 Application/Control Number: 18/100,517 Page 7 Art Unit: 2499 Application/Control Number: 18/100,517 Page 8 Art Unit: 2499 Application/Control Number: 18/100,517 Page 9 Art Unit: 2499 Application/Control Number: 18/100,517 Page 10 Art Unit: 2499 Application/Control Number: 18/100,517 Page 11 Art Unit: 2499 Application/Control Number: 18/100,517 Page 12 Art Unit: 2499 Application/Control Number: 18/100,517 Page 13 Art Unit: 2499 Application/Control Number: 18/100,517 Page 14 Art Unit: 2499 Application/Control Number: 18/100,517 Page 15 Art Unit: 2499 Application/Control Number: 18/100,517 Page 16 Art Unit: 2499 Application/Control Number: 18/100,517 Page 17 Art Unit: 2499 Application/Control Number: 18/100,517 Page 18 Art Unit: 2499 Application/Control Number: 18/100,517 Page 19 Art Unit: 2499 Application/Control Number: 18/100,517 Page 20 Art Unit: 2499 Application/Control Number: 18/100,517 Page 21 Art Unit: 2499 Application/Control Number: 18/100,517 Page 22 Art Unit: 2499
Read full office action

Prosecution Timeline

Jan 23, 2023
Application Filed
Feb 25, 2026
Non-Final Rejection — §103
Mar 25, 2026
Response Filed

Precedent Cases

Applications granted by this same examiner with similar technology

Patent 12591702
PERMISSION TRANSLATOR
2y 5m to grant Granted Mar 31, 2026
Patent 12580962
0-RTT CAPABLE, TUNNEL-LESS, MULTI-TENANT POLICY ARCHITECTURE
2y 5m to grant Granted Mar 17, 2026
Patent 12566869
Retention Policy-based Protection of Data Written to a Data Store
2y 5m to grant Granted Mar 03, 2026
Patent 12561428
Remote Analysis of Potentially Corrupt Data Written to a Storage System
2y 5m to grant Granted Feb 24, 2026
Patent 12554874
SYSTEMS AND METHODS FOR RESPONSIBLE AI
2y 5m to grant Granted Feb 17, 2026
Study what changed to get past this examiner. Based on 5 most recent grants.

AI Strategy Recommendation

Get an AI-powered prosecution strategy using examiner precedents, rejection analysis, and claim mapping.
Powered by AI — typically takes 5-10 seconds

Prosecution Projections

1-2
Expected OA Rounds
71%
Grant Probability
99%
With Interview (+50.3%)
3y 0m
Median Time to Grant
Low
PTA Risk
Based on 551 resolved cases by this examiner. Grant probability derived from career allow rate.

Sign in with your work email

Enter your email to receive a magic link. No password needed.

Personal email addresses (Gmail, Yahoo, etc.) are not accepted.

Free tier: 3 strategy analyses per month