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 . The present office action is responsive to communication received 3/26/2025. Claims 1-20 are pending.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 3/26/2025 was filed after the mailing date of the application no. 19/090,570 on 3/26/2025. The submission is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Allowable subject matter
Claim 9 and 18 recite allowable subject matter.
Regarding claim 9 and substantially claim 18,
Dykes in view of Brandwine discloses the method of claim 1, but fails to explicitly disclose configuring the first prompt such that the pre-deployed security policy is included in the first prompt when there is a pre-deployed security policy corresponding to the first service, wherein the generating of the first security policy comprises generating the first security policy by reflecting an updated security policy according to an update of the first service to the pre-deployed security policy.
Claim 9 is objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
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, 3-4, 10, 12-13, and 19 are rejected under 35 U.S.C. 103 as being unpatentable over by Dykes et al. (US 20190213326) in view of Brandwine et al. (US 12513189).
Regarding claim 1,
Dykes teaches a processor-implemented method that automatically generates a communication security policy among multiple services constituting an application running in a cloud system with a computing device, the method comprising:
collecting an application programming interface (API) remote call list for related services of a first service among the multiple services;
[the local data receptors 62 can be implemented as light-weight software components that can be deployed at various network locations to monitor network transaction data and to capture API call data (Dykes et al., paragraph 53; also paragraph 51)]
Although Dykes discloses generating a first security policy for a remote call of the first service (paragraph 53, 92: command to generate password policies), Dykes does not explicitly teach configuring a first prompt, based on the remote call list, and generating a first security policy for a remote call of the first service by implementing an artificial intelligence model, based on the first prompt.
In an analogous art of generating security polices, Brandwine discloses:
configuring a first prompt, based on the remote call list; [receiving a request (column 12, lines 21-28), … via API calls … (column 4, lines 19-27) generating the security policy comprises prompting the first machine learning model for the security policy based at least in part on a description of the task. (Brandwine et al., column 12, lines 52-54)]
and generating a first security policy for a remote call of the first service by implementing an artificial intelligence model, based on the first prompt.
[generating, by the interaction agent based at least in part on use of the first machine learning model, a task-specific security policy to govern execution of the task. (Brandwine et al., column 12, lines 48-51); an example of security policy (column 12, lines 55-60) ]
Dykes and Brandwine are considered to be analogous to the claimed invention because they are in the same field of policy creation. Therefore, it would have been obvious to one of ordinary skill in the art before the instant application effective filing date of the claimed invention to have modified the teachings of Dykes to incorporate the teachings of Brandwine et al. to include configuring a first prompt, based on the remote call list, and generating a first security policy for a remote call of the first service by implementing an artificial intelligence model, based on the first prompt, in order to identify the type of data that can be provided to an untrusted entity limiting personal data of a user that the interaction agent can access. (Brandwine et al., column 12, lines 55-59)
Regarding claim 10,
Dykes teaches an apparatus that automatically generates a communication security policy among multiple services constituting an application running in a cloud system, the apparatus comprising: one or more processors;
[The computer system includes at least one processing unit and memory. The processing unit executes computer-executable instructions and may be a hardware processor or a virtual processor. (Dykes et al., paragraph 98)]
and a memory storing instructions that, when executed by the one or more processors cause the apparatus to
[The storage may be removable or non-removable, and includes magnetic disks, magnetic tapes or cassettes, compact disc-read only memories (CD-ROMs), compact disc rewritable (CD-RWs), digital video discs (DVDs), or any other medium which may be used to store information, and which may be accessed within the computer system. In various embodiments of the present invention, the storage may store instructions for the software implementing various embodiments of the present invention. (Dykes et al., paragraph 99)]
The claim recites substantially the same content as claim 1 and is rejected with the rationales set forth for claim 1.
Regarding claim 19,
Dykes A non-transitory computer-readable storage medium storing instructions that, when executed by one or more processors, cause an apparatus that automatically generates a communication security policy among multiple services constituting an application running in a cloud system
[The storage may be removable or non-removable, and includes magnetic disks, magnetic tapes or cassettes, compact disc-read only memories (CD-ROMs), compact disc rewritables (CD-RWs), digital video discs (DVDs), or any other medium which may be used to store information, and which may be accessed within the computer system. In various embodiments of the present invention, the storage may store instructions for the software implementing various embodiments of the present invention. (Dykes et al., paragraph 99)]
The claim recites substantially the same content as claim 1 and is rejected with the rationales set forth for claim 1.
Regarding claims 3 and 12,
Dykes in view of Brandwine discloses the method according to claim 1 and the apparatus of claim 10, wherein the collecting comprises: deploying a first workload in which the first service is operated (Dykes paragraph 53);
collecting the remote call list for the related services of the first service; and collecting metadata about a workload in which the multiple services are operated in the cloud system.
[the local data receptors 62 can be implemented as light-weight software components that can be deployed at various network locations to monitor network transaction data and to capture API call data (Dykes et al., paragraph 53; also paragraph 51)]
Regarding claims 4 and 13,
Dykes in view of Brandwine discloses the method according to claim 1 and the apparatus of claim 10, wherein the collecting comprises collecting metadata about related services that are remotely called by the first service.
[the local data receptors 62 can be implemented as light-weight software components that can be deployed at various network locations to monitor network transaction data and to capture API call data (Dykes et al., paragraph 53); metadata see paragraph 55]
Claims 2, 11, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over by Dykes et al. (US 20190213326) in view of Brandwine et al. (US 12513189) in further view of Mathews et al., (US 20250080558).
Regarding claims 2, 11, and 20,
Dykes in view of Brandwine discloses the method according to claim 1, the apparatus of claim 10, and the non-transitory computer-readable storage medium of claim 19, but fails to explicitly disclose generating the application programming interface (API) remote call list for the related services by performing static analysis of source code of the first service.
However in an analogous art Mathews discloses generating the application programming interface (API) remote call list for the related services by performing static analysis of source code of the first service.
[In some instances, a source code analysis module examines each source code file to identify function calls, e.g., class instantiation, API calls, software library calls, or other function calls that are known to be used for cryptographic operations. Further analysis of the source code is performed to determine if the operation being performed by the software matches any of the security characteristics deemed to be risky, weak, or broken by the cryptography usage analysis agent. (Mathews et al., paragraph 66)]
Dykes, Brandwine, and Mathews are considered to be analogous to the claimed invention because they are in the same field of API calls. Therefore, it would have been obvious to one of ordinary skill in the art before the instant application effective filing date of the claimed invention to have modified the teachings of Dykes and Brandwine to incorporate the teachings of Mathews et al. to include generating the application programming interface (API) remote call list for the related services by performing static analysis of source code of the first service, in order to determine if the operation being performed by the software matches any of the security characteristics deemed to be risk, weak, or broken. (Mathews et al., paragraph 66)
Claims 5-7 and 14-16 are rejected under 35 U.S.C. 103 as being unpatentable over by Dykes et al. (US 20190213326) in view of Brandwine et al. (US 12513189) in further view of Ramatchandirane et al., (US 20150278810).
Regarding claims 5 and 14,
Dykes in view of Brandwine discloses the method according to claim 1 and the apparatus of claim 10, discloses a loop in which the polices are fed back to the system.
[the API sensor 20 can be deployed as proxy extensions (Dykes et al., paragraph 36)]
[the API sensor 20 may be deployed as an additional sidecar container as part of the target pod 22 containing containerized applications. The API sensor 20 may be deployed inside or outside the pod (Dykes et al., paragraph 37, we can see in Fig. 2 that the API sensor (interceptors are located within the entities, the interceptors are proxies to the entities involved in transactions. Dykes teaches a loop in which the polices are fed back to the system)]
However in an analogous art Ramatchandirane discloses applying the first security policy to a second workload in which a second service that is remotely called by the first service is operated, to control a remote call from the first service.
[The business logic unit 302 can include, for example, a workflow adaptor layer 306 for applying business-related rules to received transactions and an enterprise back-end 308 that serves as a back-end to the workflow adaptor layer 306. (Ramatchandirane et al., paragraph 50, policy added to both ends)]
Dykes, Brandwine, and Ramatchandirane are considered to be analogous to the claimed invention because they are in the same field of security policies. Therefore, it would have been obvious to one of ordinary skill in the art before the instant application effective filing date of the claimed invention to have modified the teachings of Dykes and Brandwine to incorporate the teachings of Ramatchandirane et al. to include applying the first security policy to a second workload in which a second service that is remotely called by the first service is operated, to control a remote call from the first service, in order to provide more security to transactions taking place. (Ramatchandirane et al., paragraph 40)
Regarding claims 6 and 15,
Dykes in view of Brandwine in further view of Ramatchandirane discloses the method according to claim 5 and the apparatus of claim 14, deploying and applying the first security policy to the second workload in real time when the first workload in which the first service is operated is deployed.
[the API sensor 20 can be deployed as proxy extensions (Dykes et al., paragraph 36)]
[the API sensor 20 may be deployed as an additional sidecar container as part of the target pod 22 containing containerized applications. The API sensor 20 may be deployed inside or outside the pod (Dykes et al., paragraph 37, we can see in Fig. 2 that the API sensor (interceptors are located within the entities, the interceptors are proxies to the entities involved in transactions. Dykes teaches a loop in which the polices are fed back to the system)]
[The business logic unit 302 can include, for example, a workflow adaptor layer 306 for applying business-related rules to received transactions and an enterprise back-end 308 that serves as a back-end to the workflow adaptor layer 306. (Ramatchandirane et al., paragraph 50, policy added to both ends)]
Dykes, Brandwine, and Ramatchandirane are considered to be analogous to the claimed invention because they are in the same field of security policies. Therefore, it would have been obvious to one of ordinary skill in the art before the instant application effective filing date of the claimed invention to have modified the teachings of Dykes and Brandwine to incorporate the teachings of Ramatchandirane et al. to include deploying and applying the first security policy to the second workload in real time when the first workload in which the first service is operated is deployed, in order to provide more security to transactions taking place. (Ramatchandirane et al., paragraph 40)
Regarding claims 7 and 16,
Dykes in view of Brandwine in further view of Ramatchandirane discloses the method according to claim 5 and the apparatus of claim 14, applying the first security policy to a proxy device corresponding to the second workload.
[API sensors 20 for capturing API call data can be deployed at various locations to monitor and secure the applications by providing end-to-end API security. (Dykes et al., paragraph 35)]
[the API sensor 20 can be deployed as proxy extensions (Dykes et al., paragraph 36)]
[the sensor 20 can be implemented as a local data receptor 21 configured to capture API call data (Dykes et al., paragraph 43, sensor can be local data receptor)]
[The central security data processor 65 provides the API spec and any security policy rules to the local data receptors 62. (Dykes et al., paragraph 53, policies being applied to local data receptors)]
Claims 8 and 17 are rejected under 35 U.S.C. 103 as being unpatentable over by Dykes et al. (US 20190213326) in view of Brandwine et al. (US 12513189) in further view of Jin et al. (US 20250158940).
Regarding claims 8 and 17,
Dykes in view of Brandwine discloses the method according to claim 1 and the apparatus of claim 10, but fails to explicitly disclose wherein the configuring of the first prompt comprises adding some or all of the content of the remote call list and the metadata to a predetermined prompt template, to configure the first prompt.
However in an analogous art Jin discloses wherein the configuring of the first prompt comprises adding some or all of the content of the remote call list and the metadata to a predetermined prompt template, to configure the first prompt.
[generating the plurality of AI-powered reply suggestions involves constructing a prompt based on a predefined prompt template, the identified media attributes, and the gathered contextual information. For example, the system may maintain a set of prompt templates for different media types and contexts (Jin et al., paragraph 21)]
Dykes, Brandwine, and Jin are considered to be analogous to the claimed invention because they are in the same field of policy creation. Therefore, it would have been obvious to one of ordinary skill in the art before the instant application effective filing date of the claimed invention to have modified the teachings of Dykes and Brandwine to incorporate the teachings of Jin et al. to include wherein the configuring of the first prompt comprises adding some or all of the content of the remote call list and the metadata to a predetermined prompt template, to configure the first prompt, in order to provide the AI with the information needed to output relevant replies. (Jin et al., paragraph 21)
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Kulshreshtha et al. (US 20220083644) discloses a method for implementing security polices at software call stack level by generating a call stack classification scheme for an application, detecting a call stack during deployment of the application. Using the call stack classification scheme during runtime of the application, classifying the detected call stack as one of an authorized call stack or an unauthorized call stack to yield a classification, then applying a security policy based on the classification.
Wang et al. (US 20230128064) discloses analyzing information relating to data traffic associated with a group of resources associated with a tenant. The analysis can comprise an artificial intelligence analysis. Ingress/egress of the data traffic to/from resources of the group of resources initially can be controlled based on a group of security rules selected by the tenant. Based on a result of the analyzing, then can determine a modified group of security rules to apply to the group of resources to control ingress/egress of subsequent data traffic to/from the resources
Chandramouli et al. (US 12401622) discloses an administrator specifying a firewall policy that includes rules and traffic description, and specifies accounts, isolated virtual networks (IVNs) and/or subnets for firewall deployment. For automated traffic route configuration, the manager provisions and configures firewalls for the specified networks.
Visoky et al. (US 20250291327) discloses a LLM generating security policy based on system characteristics.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to DANIEL ELAHIAN whose telephone number is (703) 756-1284. The examiner can normally be reached on Monday – Friday from 7:30am to 5pm.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Catherine Thiaw can be reached at telephone number 571-270-1138. 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 Patent Center and the Private Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from Patent Center or Private PAIR. Status information for unpublished applications is available through Patent Center and Private PAIR for authorized users only. Should you have questions about access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free).
/D.E./DANIEL ELAHIAN, Examiner, Art Unit 2407
/Catherine Thiaw/Supervisory Patent Examiner, Art Unit 2407 8/6/2026
Prosecution Insights