DETAILED ACTION
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 2/2/2026 has been entered.
-Claims 1, 14 and 18 are amended.
-Claim 17 is cancelled.
-Rejections under 112(a) are withdrawn based on the claim amendments.
-Claims 1-16 and 18-20 are pending.
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 .
Response to Arguments
Applicant’s Remarks filed on 2/2/2026 have been fully considered, however they are moot in view of the new grounds of rejection.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-16 and 18-20 are rejected under 35 U.S.C. 103 as being unpatentable over Talwar et al (US pub.No.2023/0022134) in view of Tuggle (US Pub.No.2019/0147068) and further in view of Siddabathuni (WO 2022011944), hereinafter Sidda.
Re Claim 1. Talwar discloses a method for implementing policies within a multi-tenant cloud environment (i.e. The network policy evaluation framework is network provider agnostic and can evaluate network policies from various network providers (e.g., CNI plugins) along with the network policies of the container orchestration platform and/or the network policies of the underlying infrastructure, which can include a virtual computing infrastructure and/or a physical computing infrastructure…………………….. The network policy evaluation framework 140 can perform similar evaluations and troubleshooting on other types of applications hosted in other types of environments, e.g., by other types of cloud computing platforms, that have multiple network policies that may conflict. The container orchestration platform 110 can include virtual and physical computing infrastructure to host container orchestration clusters 120) [Talwar, para.0013, 0025], the method comprising: receiving, by a policy manager platform, a pending policy for controlling a cloud-based service (i.e. The cluster 120 also includes network policies 128, which can be stored in a network policy data storage device 129, that manage the network traffic for the cluster 120 and its containers 122. A network policy 128 can include one or more rules, e.g., firewall rules, for managing the network traffic for the cluster 120. These rules can define network traffic that is to be allowed or blocked. For example, a rule can define that traffic from a particular IP address is blocked from entering the cluster or reaching a particular container) [Talwar, para.0027] that is associated with a tenant of the multi-tenant cloud environment (i.e. In stage B, the network policy evaluation framework 140 can obtain any new network policies, e.g., from a client device of a user that is providing new network policies for evaluation by the network policy evaluation framework……………. The deployment automation framework obtains planned network policies (702). For example, a user can specify the planned network policies and provide the planned network policies to the deployment automation framework) [Talwar, 0042, 0080], wherein the pending policy comprises at least one action to be executed when at least one tenant-specific condition is met (i.e. A canonical rule model is a data structure that defines, for a network rule, an action that is performed on network traffic that is being transmitted from a particular source to a particular destination. …….. As the policies differ for different network traffic managers, the rule extractor 142 can process the policies to extract the rules and put them in the canonical rule models for evaluation by the rule analyzer) [Talwar, para.0038, Fig.1]; deploying the pending policy in a test environment to analyze a performance of the pending policy (i.e. The network policy evaluation framework 140 identifies any conflicts between the network rules of the active network policies and the planned network policies (710). For example, the network policy evaluation framework 140 can perform the processes 200, 500, and 600 or the process 800 to identify any conflicts………………. if a network policy of the container orchestration platform 110 blocks traffic to a particular IP address that a container 122 needs to send data, the container 122 may be blocked from getting the data to the device at the particular IP address, resulting in a loss of service. This evaluation can be used to troubleshoot errors that may be caused by blocked data, e.g., due to conflicting network policies …………………… The network policy evaluation framework introduces a network provider agnostic framework which encapsulates the core tenets of firewall functionality, thereby allowing a simplified and unified experience when debugging, analyzing, or performing diagnosis of network policy rule configuration anomalies across different CNI providers …………..the network policy evaluation framework can be integrated with other solutions, e.g., Sonobuoy, for Network Policy Conformance Testing to troubleshoot and diagnose network policy rule failures) [Talwar, para.0083, 0036, 0011-0012] [by executing a simulation of use of the pending policy within the tenant]; receiving an indication that the pending policy is approved based on the performance of the pending policy in the test environment, wherein a status of the pending policy changes from pending to active (i.e. If there are no conflicts, the deployment automation framework can deploy the planned network policies to the cluster (718)) [Talwar, para.0086]; transmitting the active policy to a policy subscriber associated with the tenant (i.e. If no conflicts are detected, the network policy evaluation framework 140 can consider the network policies validated and output, to a user or application that manages the deployment of network policies and/or clusters of containers, data specifying that the network policies have been validated) [Talwar, para.0033];
Talwar does not explicitly disclose whereas Tuggle does: by executing a simulation of use of the pending policy within the tenant (i.e. the automated development engine 126 may automatically perform validations at the development database and create a change set that captures the new or modified metadata, object data, workflows and the like implemented at the development database and dependent components, and then utilize the change set to deploy the selected solution for the new functionality from the development database up to a production database. For example, the automated development engine 126 may first utilize the change set to update a testing database to include the new or modified metadata, object data, workflows, and the like and perform validations at the testing database to ensure the new customizations do not generate errors or conflicts when applied to a replicated version of the production database before deploying the selected solution to the production database………………automatically deploy the new custom object type and new workflow rule at a testing database, automatically validate the modifications at the testing database, and then automatically deploy the new custom object type and new workflow rule to the production database 104 after validation at the testing database…………… multi-tenant system 500 of FIG. 5 includes a server 502, such as server 102, that dynamically creates and supports virtual applications 528 based upon data from a common database that is shared between multiple tenants, alternatively referred to herein as a multi-tenant database) [Tuggle, para.0032, 0037-0038 Note: deploying and testing workflows in a development environment is interpreted as a simulation], and wherein active policies associated with the tenant are made unavailable to other tenants within the multi-tenant cloud environment (i.e. Although multiple tenants may share access to the server 502 and the database 530, the particular data and services provided from the server to each tenant can be securely isolated from those provided to other tenants (e.g. by restricting other tenants from accessing a particular tenant's data using that tenant's unique organization identifier as a filtering criterion). The multi-tenant architecture therefore allows different sets of users to share functionality and hardware resources without necessarily sharing any of the data belonging to or otherwise associated with other tenants) [Tuggle, para.0039, also 0047].
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to modify Talwar with Tuggle because different users, tenants and/or organizations often have different types of data and/or different relationships between data that they would like to maintain in the multi-tenant system, along with different types of operations they would like to be able to perform on their data to achieve different business objectives [Tuggle, para.0004].
Talwar in view of Tuggle do not explicitly disclose whereas Sidda does: and monitoring the active policy transmitted to the policy subscriber and automatically reverting the active policy to a last-known-good version in response to the active policy failing a performance test (i.e. if there is a fault in a current configuration of network device 104, FAS agent 108 may determine if a rollback is necessary. If so, FAS agent 108 may cause the network device to rollback to a previous configuration that may be known to be a good configuration) [Sidda, para.0031].
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to modify Talwar in view of Tuggle with Sidda because it can automatically synchronize configuration changes through the network to prevent mismatching configurations and to ensure communications continue to propagate through the network when configurations are updated [Sidda, para.0029].
Re Claim 2. Talwar in view of Tuggle and Sidda discloses the method of claim 1, wherein receiving the pending policy comprises receiving a policy definition, wherein the policy definition comprises at least one of: a policy description (i.e. The rule extractor 142 obtains the active network policies and any new network policies (e.g., if a what if analysis is being performed) and extracts network rules from network policies and generates canonical rule models based on the extracted rules. A canonical rule model is a data structure that defines, for a network rule, an action that is performed on network traffic that is being transmitted from a particular source to a particular destination) [Talwar, para.0038]; an effective date of the pending policy; an expiration date of the pending policy; at least one attribute associated with the pending policy; a category that corresponds to the pending policy; or a sub-category that corresponds to the pending policy.
Re Claim 3. Talwar in view of Tuggle and Sidda discloses the method of claim 1, wherein the test environment is a non-production test environment for testing the pending policy (i.e. automated customizations can be validated and migrated from a development environment to a production environment) [Tuggle, para.0033]. The same motivation to modify with Tuggle, as in claim 1, applies.
Re Claim 4. Talwar in view of Tuggle and Sidda discloses the method of claim 1, further comprising: generating a prototype of the pending policy; exporting the prototype in a subscriber environment for testing; and monitoring the performance of the pending policy in the subscriber environment (i.e. the automated development engine 126 may automatically perform validations at the development database and create a change set that captures the new or modified metadata, object data, workflows and the like implemented at the development database and dependent components, and then utilize the change set to deploy the selected solution for the new functionality from the development database up to a production database. For example, the automated development engine 126 may first utilize the change set to update a testing database to include the new or modified metadata, object data, workflows, and the like and perform validations at the testing database to ensure the new customizations do not generate errors or conflicts when applied to a replicated version of the production database before deploying the selected solution to the production database) [Tuggle, para.0032].
The same motivation to modify with Tuggle, as in claim 1, applies.
Re Claim 5. Talwar in view of Tuggle and Sidda discloses the method of claim 1, Tuggle further discloses: further comprising storing the active policy in a scalable database (i.e. the tenant's existing customizations are identified or obtained from each different type of database supported within the database system 100, including any customizations implemented at development or testing databases in addition to the existing customizations implemented at the production database 104.) [Tuggle, para.0034], The same motivation to modify with Tuggle, as in claim 1, applies.
Talwar further discloses: wherein active policies associated with the tenant are made available to the policy subscriber (i.e. If no conflicts are detected, the network policy evaluation framework 140 can consider the network policies validated and output, to a user or application that manages the deployment of network policies and/or clusters of containers, data specifying that the network policies have been validated) [Talwar, para.0033].
Re Claim 6. Talwar in view of Tuggle and Sidda discloses the method of claim 1, further comprising updating the active policy based on approving one or more updates to the active policy (i.e. the network policy evaluation framework 140 can recommend actions to a user and receive, from the user, a selection to approve or deny the recommendation. For example, if a network policy of the network provider allows traffic between two pods but a network policy of the container orchestration platform 110 blocks the traffic, e.g., as a default setting, the network policy evaluation framework 140 can recommend removing the network policy of the container orchestration platform 110. The network policy evaluation framework 140 can also provide a user interface control that enables the user to confirm the recommended action or deny the recommended action. If the user confirms the recommendation action, the network policy evaluation framework 140 can apply the recommended action to the appropriate network policies) [Talwar, para.0046].
Re Claim 7. Talwar in view of Tuggle and Sidda discloses the method of claim 6, wherein updating the active policy comprises updating a scalable database where the active policy is stored (i.e. automatically validate the modifications at the testing database, and then automatically deploy the new custom object type and new workflow rule to the production database 104 after validation at the testing database) [Tuggle, para.0037].
The same motivation to modify with Tuggle, as in claim 1, applies.
Re Claim 8. Talwar in view of Tuggle and Sidda discloses the method of claim 6, further comprising transmitting, to the policy subscriber, updates to the active policy (i.e. After validating the implementation of the selected solution at the testing database, the automated development engine 126 may automatically create a change set that captures the new or modified metadata, object data, workflows, and the like from the testing database and then utilize the change set to deploy the new or modified metadata, object data, workflows, and the like at the production database 104) [Tuggle, para.0032], (i.e. the new custom object type and new workflow rule are deployed automatically and without any manual interaction once the card 402 corresponding to that automated development solution is selected; however, in alternative embodiments, deployment and migration of an automated development solution across different databases may be subject to additional approval, verification, or other manual interaction by the user or an administrator) [Tuggle, para.0037].
The same motivation to modify with Tuggle, as in claim 1, applies.
Re Claim 9. Talwar in view of Tuggle and Sidda discloses the method of claim 1, further comprising managing requests from users within the tenant to subscribe to one or more active policies associated with the tenant (i.e. administrator user may review the implementation information presented within the cards 402, 404, 406 to determine which solution is believed to be most preferable or beneficial for his or her tenant given the administrator's understanding of the tenant's business processes, existing customizations, potential future customizations, and the like…………… and in response to selection of one of the cards 402, 404, 406, the automated development engine 126 automatically implements the selected solution in the development database (e.g., task 216). In exemplary embodiments, the automated development engine 126 also automatically migrates the solution from the development database to the production database) [Tuggle, para.0035-0036].
The same motivation to modify with Tuggle, as in claim 1, applies.
Re Claim 10. Talwar in view of Tuggle and Sidda discloses the method of claim 1, wherein the active policy is transmitted to the policy subscriber associated with the tenant via at least one of an application programming interface (API), (i.e. FIG. 3 depicts a setup GUI display 300 that may be presented by a virtual application within a browser application 107 on a client device 106 to an administrator user associated with a particular tenant or user group supported by the database system 100. In response to selection of a selectable GUI element within the setup GUI display 300 to add new functionality to instances of the virtual application associated with that tenant or user group, the automated development engine 126 generates or otherwise provides a text box, a window overlay, or similar GUI element 302 that may be utilized by the administrator user of the client device 106 to provide input indicative of a new functionality that the administrator would like to be supported) [Tuggle, para.0033], an email, or a config transfer mechanism.
The same motivation to modify with Tuggle, as in claim 1, applies.
Re Claim 11. Talwar in view of Tuggle and Sidda discloses the method of claim 1, further comprising receiving a request from the policy subscriber to search for a particular active policy, wherein the request includes at least one component of a policy definition (i.e. The automated development engine 126 analyzes the user input provided via the GUI element 302 to determine the new functionality to be added to the database system…………………The runtime application generator 520 suitably interacts with the query generator 514 to efficiently obtain multi-tenant data 532 from the database 530 as needed in response to input queries initiated or otherwise provided by users of the client devices 540. In a typical embodiment, the query generator 514 considers the identity of the user requesting a particular function (along with the user's associated tenant), and then builds and executes queries to the database 530 using system-wide metadata 536, tenant specific metadata 538, pivot tables 534, and/or any other available resources. The query generator 514 in this example therefore maintains security of the common database 530 by ensuring that queries are consistent with access privileges granted to the user and/or tenant that initiated the request. In this manner, the query generator 514 suitably obtains requested subsets of data 532 accessible to a user and/or tenant from the database 530 as needed to populate the tables, reports or other features of the particular virtual application 528 for that user and/or tenant) [Tuggle, para.0033, 0045, see Fig. 3, item 302].
The same motivation to modify with Tuggle, as in claim 1, applies.
Re Claim 12. Talwar in view of Tuggle and Sidda discloses the method of claim 1, further comprising preventing duplicate policy creation based on flagging the pending policy when a metadata mapping associated with the pending policy is the same as a metadata mapping associated with the active policy (i.e. the automated development engine also automatically creates a corresponding data field associated with the custom object (if it did not already exist)) [Tuggle, para.0014, Note: this implies that if it did already exist, it is not created thus preventing duplicates].
The same motivation to modify with Tuggle, as in claim 1, applies.
Re Claim 13. Talwar in view of Tuggle and Sidda discloses the method of claim 1, further comprising reverting the active policy to a previous version of the active policy based on the active policy failing at least one performance test while deployed in the test environment (i.e. if there is a fault in a current configuration of network device 104, FAS agent 108 may determine if a rollback is necessary. If so, FAS agent 108 may cause the network device to rollback to a previous configuration that may be known to be a good configuration) [Sidda, para.0031].
The same motivation to modify with Sidda, as in claim 1, applies.
Re Claims 14 and 18. These claims recite features similar to those in claim 1, therefore they are rejected in a similar manner. Tuggle further teaches simulation…. to generate performance metrics (i.e. perform validations at the testing database to ensure the new customizations do not generate errors or conflicts when applied to a replicated version of the production database before deploying the selected solution to the production database………………) [Tuggle, para.0032].
The same motivation to modify with Tuggle, as in claim 1, applies.
Re Claims 15-16. These claims recite features similar to those in claims 4 and 12, respectively, therefore they are rejected in a similar manner.
Re Claims 19-20. These claims recite features similar to those in claims 2-3, respectively, therefore they are rejected in a similar manner.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to NOURA ZOUBAIR whose telephone number is (571)270-7285. The examiner can normally be reached Monday - Friday.
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, Kambiz Zand can be reached at 571-272-3811. 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.
/NOURA ZOUBAIR/Primary Examiner, Art Unit 2434