DETAILED ACTION
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 .
This office action is in response to Applicant’s communication filed on 10/23/2025. Claims 1-2,4-11, 13-17,19-23 have been examined. Claims 3,12,18 are cancelled. Claims 21-23 are new.
Response to Argument
Applicant’s arguments, see Remarks – Pages 8-9, filed on 10/23/2025 with respect to the rejections of claims 1,10,16 under 102 have been fully considered and are persuasive. Therefore, the rejection has been withdrawn. However, upon further consideration, a new grounds of rejection is made in view of Morrison.
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-2,5,6,9-11,14-17,20 are rejected under 35 U.S.C. 103 as being unpatentable over Greene et al. Publication No. US 2023/0222225 A1 ( Greene hereinafter) in view of Morrison et al. Publication No. US 2015/0213449 A1 ( Morrison hereinafter) .
Regarding claim 1,
Greene teaches a computer-implemented method comprising:
analyzing a call stack in relation to an incoming application programming interface (API) request to identify one or more application components of the call stack that relate to the API request. (¶ 0018 - service requests generated in a computing system such as third party- and internal-facing API (application program interface) calls, ¶0015 - The SASPM 114 may therefore scan and evaluate the software components installed at and running on the client machines 116 without being installed as an agent on client machines 116. ¶ 0017 - The client may be able to configure whether to use the SASP as a proxy, at either the local modules 112, 114 or through a remote system 102, for outbound service requests from the client's systems. The client may be able to set up multiple optional outbound proxies for third party service request calls based on the target, the software or system component from where the call is originating, the number of service request calls, the latency requirements, and more parameters. ¶ 0032 - the proxy module 318 may allow for monitoring proxied service requests for unusual or unexpected data within the request, unusual frequency or patterns (e.g., a spike in a number of calls to a target), or otherwise monitor data traffic – ¶ 0033 - The analysis module may compare the data of the SBOM against the known vulnerabilities, privacy concerns, or compliance requirements of database to determine if any of the client systems conflicts with the database information. Based on the comparison, the analysis module 320 may determine which elements present a security or compliance risk. the known vulnerabilities database may identify that Example Software vl .3 includes a security vulnerability, and that SBOM identifies that two client computing systems are running Example Software vl .3. The analysis module 320 may generate one or more suggestions or advice based on the security analysis, e.g., via user interface 308. Suggestions may be based on recommendations included with the known vulnerabilities in the known vulnerability database 315, based on factors included in the SBOM 314, or based on other factors).
obtaining a software bill of materials for each of the one or more application components (¶ 0025 - the SBOM system may have metadata associated with the various computer ecosystem components in the SBOM identifying how those components are used by the particular business, how important they are, or how externally vulnerable they are. For example, some code elements may be external facing and accessible via the internet, while other components may be internal-facing and are less exposed to illicit access, or some components may be fundamental to business operations, while other components are of secondary importance. The SASP may be configured to use this metadata to prioritize corrective recommendations to the client business – ¶ 0029 - Processing system may be linked to communication interface and user interface 308. Processing system can include processing circuitry and memory device 312. Memory device can store executable instructions or other operating software, a catalog of system components or software bill of materials (SBOM) 314 – ¶ 0030 - The analysis module 320 may compare data of the SBOM 314 against the known vulnerabilities, privacy concerns, or compliance requirements of database to determine if any of the client systems conflicts with the database information – Note: the analysis module has to obtain the SBOM in order to compare the data),
analyzing risk metadata associated with each software bill of materials, determining whether the API request satisfies one or more risk criteria; and responding to the API request (¶ 0025 - Based on the evaluation of the software components and service requests used in the client business' computer ecosystem or SBOM, the method may include generating a risk scoring report or risk mitigation advice, The method may include generating risk profiles or scores for all third party vendors or software involved in the business ecosystem. Recommendations may include identifying software to update, quarantine, or remove from the system, among other operations. In an example, risks identified in a CVE database may include risk level indicators or corrective recommendations which recommendations may be noted for each element in the SBOM, or may be used as a factor in generating more business-specific recommendations. In some embodiments, the SBOM system may have metadata associated with the various computer ecosystem components in the SBOM identifying how those components are used by the particular business, how important they are, or how externally vulnerable they are - ¶ 0033 - The analysis module 320 may compare the data of the SBOM against the known vulnerabilities, privacy concerns, or compliance requirements of database to determine if any of the client systems conflicts with the database information. Based on the comparison, the analysis module may determine which elements present a security or compliance risk. the known vulnerabilities database may identify that Example Software vl.3 includes a security vulnerability, and that SBOM identifies that two client computing systems are running Example Software vl .3. The analysis module 320 may generate one or more suggestions or advice based on the security analysis, e.g., via user interface. Suggestions may be based on recommendations included with the known vulnerabilities in the known vulnerability database, based on factors included in the SBOM, or based on other factors).
However, Greene does not explicitly teach
wherein the risk metadata includes a risk score for the one or more application components; determining whether the API request satisfies one or more risk criteria based on a comparison of the risk score to a threshold value;
Morrison teaches
risk metadata includes a risk score for the one or more application components; determining whether the API request satisfies one or more risk criteria based on a comparison of the risk score to a threshold value (¶ 0003 - application interface (API) transaction risk assessment equipment that receives an API transaction request through a data network from an application processed by a source node, and generates a risk assessment score based on context information that characterizes the API transaction request. The risk assessment score indicates a level of trustworthiness of the API transaction request for processing by an application on a destination node. The API transaction risk assessment equipment then controls deliverability of the API transaction request through the data network to the destination node for processing based on the risk assessment score- ¶ 0018 - a risk assessment score of zero indicates a lowest potential risk of the API transaction causing undesired operation when processed by the application servers 110, while in contrast a risk assessment score of 100 indicates a highest potential risk of the API transaction causing such undesired operation. Various types of undesirable operations that an API transaction may be assessed for as possibly causing risks can include, but are not limited to, attempting to obtain information from application servers for delivery to a falsely identified API client application – ¶ 0033 – ¶ 0034 - an administrator can define policies that cause API transaction requests having a score greater than the first defined threshold (e.g., 50) to be discarded (e.g. blocked), cause API transaction requests having a score less than a second defined threshold (e.g., 20) to be allowed to pass through to the destination node 110 for processing, and cause API transaction requests having a score between the first and second defined thresholds to properly complete further authentication before being allowed to pass through to the destination node 110 for processing – See Claims 1 & 2).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Greene to include the teachings of Morrison. The motivation for doing so is to allow the system to control deliverability of the API transaction request through the data network to the destination node for processing based on the risk assessment score (¶ 0003 – Morrison).
Regarding claim 2,
Greene further teaches
wherein the risk metadata indicates a presence of a vulnerability (¶ 0025 - the SBOM system may have metadata associated with the various compute ecosystem components in the SBOM identifying how those components are used by the particular business, how important they are, or how externally vulnerable they are. For example, some code elements may be external facing and accessible via the internet, while other components may be internal-facing and are less exposed to illicit access, or some components may be fundamental to business operations, while other components are of secondary importance. The SASP may be configured to use this metadata to prioritize corrective recommendations to the client business, either based on the metadata alone or in combination with risk factors and recommendations from other sources. Based on risk indicators and how elements are used by the business, a corrective priority list may be generated, which may identify what elements within the ecosystem should be corrected or replaced in order of importance to the business).
Regarding claim 5,
Greene further teaches
presenting the call stack in a user interface in which each of the one or more application components of the call stack is labeled with respect to an identity of each application component (¶ 0033 - The analysis module 320 may generate one or more suggestions or advice based on the security analysis, e.g., via user interface 308. Suggestions may be based on recommendations included with the known vulnerabilities in the known vulnerability database 315, based on factors included in the SBOM 314, or based on other factors. For example, the known vulnerability database 315 may suggest that the security vulnerability in Example Software vl .3 is a high-risk vulnerability, and that Example Software should be updated to vl .4).
Regarding claim 6,
Greene further teaches
wherein each of the one or more application components of the call stack is further labeled with respect to risk ¶ 0033 - The analysis module may generate one or more suggestions or advice based on the security analysis, e.g., via user interface 308. Suggestions may be based on recommendations included with the known vulnerabilities in the known vulnerability database, based on factors included in the SBOM 314, or based on other factors. For example, the known vulnerability database may suggest that the security vulnerability in Example Software vl .3 is a high-risk vulnerability, and that Example Software should be updated to vl .4).
Regarding claim 9,
Greene further teaches
providing the risk metadata to a computing device from which the incoming API request is received (¶ 0032 - The proxy module 318 may include instructions to freeze or quarantine certain data traffic, generate notifications to a client regarding data traffic (e.g., provided via communication interface 306 or user interface 308), wait for 2FA or other approval from a client before forwarding traffic to its original target, or perform other data traffic monitoring operations – ¶ 0033 - The analysis module 320 may generate one or more suggestions or advice based on the security analysis, e.g., via user interface 308 – ¶ 0034 – the analysis module 320 may identify this issue. The analysis module 320 may generate notifications or logs of compliance or security issues that have been identified. This analysis module 320 may produce a warning indication, e.g., via user interface 308, or may store a log file that can be accessed by a system administrator or other user).
Regarding claim 10,
Greene teaches a system comprising:
one or more computer processors; one or more computer readable storage media; and program instructions stored on the one or more computer readable storage media for execution by at least one of the one or more computer processors, the program instructions comprising instructions to: analyze a call stack in relation to an incoming application programming interface (API) request to identify one or more application components of the call stack that relate to the API request (¶ 0018 - service requests generated in a computing system such as third party- and internal-facing API (application program interface) calls, ¶0015 - The SASPM may therefore scan and evaluate the software components installed at and running on the client machines 116 without being installed as an agent on client machines. ¶ 0017 - The client may be able to configure whether to use the SASP as a proxy, at either the local modules 112, 114 or through a remote system, for outbound service requests from the client's systems. The client may be able to set up multiple optional outbound proxies for third party service request calls based on the target, the software or system component from where the call is originating, the number of service request calls, the latency requirements, and more parameters. ¶ 0032 - the proxy module 318 may allow for monitoring proxied service requests for unusual or unexpected data within the request, unusual frequency or patterns (e.g., a spike in a number of calls to a target), or otherwise monitor data traffic – ¶ 0033 - The analysis module may compare the data of the SBOM against the known vulnerabilities, privacy concerns, or compliance requirements of database to determine if any of the client systems conflicts with the database information. Based on the comparison, the analysis module 320 may determine which elements present a security or compliance risk. the known vulnerabilities database may identify that Example Software vl .3 includes a security vulnerability, and that SBOM identifies that two client computing systems are running Example Software vl .3. The analysis module 320 may generate one or more suggestions or advice based on the security analysis, e.g., via user interface 308. Suggestions may be based on recommendations included with the known vulnerabilities in the known vulnerability database 315, based on factors included in the SBOM 314, or based on other factors).
obtain a software bill of materials for each of the one or more application components (¶ 0025 - the SBOM system may have metadata associated with the various computer ecosystem components in the SBOM identifying how those components are used by the particular business, how important they are, or how externally vulnerable they are. For example, some code elements may be external facing and accessible via the internet, while other components may be internal-facing and are less exposed to illicit access, or some components may be fundamental to business operations, while other components are of secondary importance. The SASP may be configured to use this metadata to prioritize corrective recommendations to the client business – ¶ 0029 - Processing system may be linked to communication interface and user interface 308. Processing system can include processing circuitry and memory device 312. Memory device can store executable instructions or other operating software, a catalog of system components or software bill of materials (SBOM) 314 – ¶ 0030 - The analysis module 320 may compare data of the SBOM 314 against the known vulnerabilities, privacy concerns, or compliance requirements of database to determine if any of the client systems conflicts with the database information – Note: the analysis module has to obtain the SBOM in order to compare the data),
analyze risk metadata associated with each software bill of materials , determine whether the API request satisfies one or more risk criteria; and responding to the API request (¶ 0025 - Based on the evaluation of the software components and service requests used in the client business' computer ecosystem or SBOM, the method may include generating a risk scoring report or risk mitigation advice, The method may include generating risk profiles or scores for all third party vendors or software involved in the business ecosystem. Recommendations may include identifying software to update, quarantine, or remove from the system, among other operations. In an example, risks identified in a CVE database may include risk level indicators or corrective recommendations which recommendations may be noted for each element in the SBOM, or may be used as a factor in generating more business-specific recommendations. In some embodiments, the SBOM system may have metadata associated with the various computer ecosystem components in the SBOM identifying how those components are used by the particular business, how important they are, or how externally vulnerable they are - ¶ 0033 - The analysis module 320 may compare the data of the SBOM 314 against the known vulnerabilities, privacy concerns, or compliance requirements of database to determine if any of the client systems conflicts with the database information. Based on the comparison, the analysis module 320 may determine which elements present a security or compliance risk. the known vulnerabilities database 315 may identify that Example Software vl .3 includes a security vulnerability, and that SBOM 314 identifies that two client computing systems are running Example Software. The analysis module may generate one or more suggestions or advice based on the security analysis, e.g., via user interface 308. Suggestions may be based on recommendations included with the known vulnerabilities in the known vulnerability database 315, based on factors included in the SBOM 314, or based on other factors).
However, Greene does not explicitly teach
wherein the risk metadata includes a risk score for the one or more application components; determine whether the API request satisfies one or more risk criteria based on a comparison of the risk score to a threshold value;
Morrison teaches
risk metadata includes a risk score for the one or more application components; determining whether the API request satisfies one or more risk criteria based on a comparison of the risk score to a threshold value (¶ 0003 - application interface (API) transaction risk assessment equipment that receives an API transaction request through a data network from an application processed by a source node, and generates a risk assessment score based on context information that characterizes the API transaction request. The risk assessment score indicates a level of trustworthiness of the API transaction request for processing by an application on a destination node. The API transaction risk assessment equipment then controls deliverability of the API transaction request through the data network to the destination node for processing based on the risk assessment score- ¶ 0018 - a risk assessment score of zero indicates a lowest potential risk of the API transaction causing undesired operation when processed by the application servers 110, while in contrast a risk assessment score of 100 indicates a highest potential risk of the API transaction causing such undesired operation. Various types of undesirable operations that an API transaction may be assessed for as possibly causing risks can include, but are not limited to, attempting to obtain information from application servers for delivery to a falsely identified API client application – ¶ 0033 – ¶ 0034 - an administrator can define policies that cause API transaction requests having a score greater than the first defined threshold (e.g., 50) to be discarded (e.g. blocked), cause API transaction requests having a score less than a second defined threshold (e.g., 20) to be allowed to pass through to the destination node 110 for processing, and cause API transaction requests having a score between the first and second defined thresholds to properly complete further authentication before being allowed to pass through to the destination node 110 for processing – See Claims 1 & 2).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Greene to include the teachings of Morrison. The motivation for doing so is to allow the system to control deliverability of the API transaction request through the data network to the destination node for processing based on the risk assessment score (¶ 0003 – Morrison).
Regarding claim 11,
Greene further teaches
wherein the risk metadata indicates a presence of a vulnerability (¶ 0025 - the SBOM system may have metadata associated with the various compute ecosystem components in the SBOM identifying how those components are used by the particular business, how important they are, or how externally vulnerable they are. For example, some code elements may be external facing and accessible via the internet, while other components may be internal-facing and are less exposed to illicit access, or some components may be fundamental to business operations, while other components are of secondary importance. The SASP may be configured to use this metadata to prioritize corrective recommendations to the client business, either based on the metadata alone or in combination with risk factors and recommendations from other sources. Based on risk indicators and how elements are used by the business, a corrective priority list may be generated, which may identify what elements within the ecosystem should be corrected or replaced in order of importance to the business).
Regarding claim 14,
Greene further teaches
wherein the program instructions further comprise instructions to: present the call stack in a user interface in which each of the one or more application components of the call stack is labeled with respect to an identity of each application component (¶ 0033 - The analysis module 320 may generate one or more suggestions or advice based on the security analysis, e.g., via user interface 308. Suggestions may be based on recommendations included with the known vulnerabilities in the known vulnerability database 315, based on factors included in the SBOM 314, or based on other factors. For example, the known vulnerability database 315 may suggest that the security vulnerability in Example Software vl .3 is a high-risk vulnerability, and that Example Software should be updated to vl .4).
Regarding claim 15,
Greene further teaches
wherein each of the one or more application components of the call stack is further labeled with respect to risk (¶ 0033 - The analysis module 320 may generate one or more suggestions or advice based on the security analysis, e.g., via user interface 308. Suggestions may be based on recommendations included with the known vulnerabilities in the known vulnerability database 315, based on factors included in the SBOM 314, or based on other factors. For example, the known vulnerability database 315 may suggest that the security vulnerability in Example Software vl .3 is a high-risk vulnerability, and that Example Software should be updated to vl .4).
Regarding claim 16,
Greene teaches One or more non-transitory computer readable storage media having program instructions embodied therewith, the program instructions executable by a computer to cause the computer to perform operations including
analyzing a call stack in relation to an incoming application programming interface (API) request to identify one or more application components of the call stack that relate to the API request. . (¶ 0018 - service requests generated in a computing system such as third party- and internal-facing API (application program interface) calls, ¶0015 - The SASPM 114 may therefore scan and evaluate the software components installed at and running on the client machines 116 without being installed as an agent on client machines. ¶ 0017 - The client may be able to configure whether to use the SASP as a proxy, at either the local modules 112, 114 or through a remote system 102, for outbound service requests from the client's systems. The client may be able to set up multiple optional outbound proxies for third party service request calls based on the target, the software or system component from where the call is originating, the number of service request calls, the latency requirements, and more parameters. ¶ 0032 - the proxy module 318 may allow for monitoring proxied service requests for unusual or unexpected data within the request, unusual frequency or patterns (e.g., a spike in a number of calls to a target), or otherwise monitor data traffic – ¶ 0033 - The analysis module may compare the data of the SBOM against the known vulnerabilities, privacy concerns, or compliance requirements of database to determine if any of the client systems conflicts with the database information. Based on the comparison, the analysis module may determine which elements present a security or compliance risk. the known vulnerabilities database may identify that Example Software vl .3 includes a security vulnerability, and that SBOM identifies that two client computing systems are running Example Software vl .3. The analysis module 320 may generate one or more suggestions or advice based on the security analysis, e.g., via user interface 308. Suggestions may be based on recommendations included with the known vulnerabilities in the known vulnerability database 315, based on factors included in the SBOM 314, or based on other factors).
obtaining a software bill of materials for each of the one or more application components (¶ 0025 - the SBOM system may have metadata associated with the various computer ecosystem components in the SBOM identifying how those components are used by the particular business, how important they are, or how externally vulnerable they are. For example, some code elements may be external facing and accessible via the internet, while other components may be internal-facing and are less exposed to illicit access, or some components may be fundamental to business operations, while other components are of secondary importance. The SASP may be configured to use this metadata to prioritize corrective recommendations to the client business – ¶ 0029 - Processing system may be linked to communication interface and user interface 308. Processing system can include processing circuitry and memory device 312. Memory device can store executable instructions or other operating software, a catalog of system components or software bill of materials (SBOM) 314 – ¶ 0030 - The analysis module 320 may compare data of the SBOM 314 against the known vulnerabilities, privacy concerns, or compliance requirements of database to determine if any of the client systems conflicts with the database information – Note: the analysis module has to obtain the SBOM in order to compare the data),
analyzing risk metadata associated with each software bill of materials, determining whether the API request satisfies one or more risk criteria; and responding to the API request (¶ 0025 - Based on the evaluation of the software components and service requests used in the client business' computer ecosystem or SBOM, the method may include generating a risk scoring report or risk mitigation advice, The method may include generating risk profiles or scores for all third party vendors or software involved in the business ecosystem. Recommendations may include identifying software to update, quarantine, or remove from the system, among other operations. In an example, risks identified in a CVE database may include risk level indicators or corrective recommendations which recommendations may be noted for each element in the SBOM, or may be used as a factor in generating more business-specific recommendations. In some embodiments, the SBOM system may have metadata associated with the various computer ecosystem components in the SBOM identifying how those components are used by the particular business, how important they are, or how externally vulnerable they are - ¶ 0033 - The analysis module may compare the data of the SBOM against the known vulnerabilities, privacy concerns, or compliance requirements of database to determine if any of the client systems conflicts with the database information. Based on the comparison, the analysis module may determine which elements present a security or compliance risk. the known vulnerabilities database may identify that Example Software vl .3 includes a security vulnerability, and that SBOM 314 identifies that two client computing systems are running Example Software vl .3. The analysis module may generate one or more suggestions or advice based on the security analysis, e.g., via user interface 308. Suggestions may be based on recommendations included with the known vulnerabilities in the known vulnerability database, based on factors included in the SBOM 314, or based on other factors).
However, Greene does not explicitly teach
wherein the risk metadata includes a risk score for the one or more application components; determining whether the API request satisfies one or more risk criteria based on a comparison of the risk score to a threshold value;
Morrison teaches
risk metadata includes a risk score for the one or more application components; determining whether the API request satisfies one or more risk criteria based on a comparison of the risk score to a threshold value (¶ 0003 - application interface (API) transaction risk assessment equipment that receives an API transaction request through a data network from an application processed by a source node, and generates a risk assessment score based on context information that characterizes the API transaction request. The risk assessment score indicates a level of trustworthiness of the API transaction request for processing by an application on a destination node. The API transaction risk assessment equipment then controls deliverability of the API transaction request through the data network to the destination node for processing based on the risk assessment score- ¶ 0018 - a risk assessment score of zero indicates a lowest potential risk of the API transaction causing undesired operation when processed by the application servers 110, while in contrast a risk assessment score of 100 indicates a highest potential risk of the API transaction causing such undesired operation. Various types of undesirable operations that an API transaction may be assessed for as possibly causing risks can include, but are not limited to, attempting to obtain information from application servers for delivery to a falsely identified API client application – ¶ 0033 – ¶ 0034 - an administrator can define policies that cause API transaction requests having a score greater than the first defined threshold (e.g., 50) to be discarded (e.g. blocked), cause API transaction requests having a score less than a second defined threshold (e.g., 20) to be allowed to pass through to the destination node 110 for processing, and cause API transaction requests having a score between the first and second defined thresholds to properly complete further authentication before being allowed to pass through to the destination node 110 for processing – See Claims 1 & 2).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Greene to include the teachings of Morrison. The motivation for doing so is to allow the system to control deliverability of the API transaction request through the data network to the destination node for processing based on the risk assessment score (¶ 0003 – Morrison).
Regarding claim 17,
Greene further teaches
wherein the risk metadata indicates a presence of a vulnerability (¶ 0025 - the SBOM system may have metadata associated with the various compute ecosystem components in the SBOM identifying how those components are used by the particular business, how important they are, or how externally vulnerable they are. For example, some code elements may be external facing and accessible via the internet, while other components may be internal-facing and are less exposed to illicit access, or some components may be fundamental to business operations, while other components are of secondary importance. The SASP may be configured to use this metadata to prioritize corrective recommendations to the client business, either based on the metadata alone or in combination with risk factors and recommendations from other sources. Based on risk indicators and how elements are used by the business, a corrective priority list may be generated, which may identify what elements within the ecosystem should be corrected or replaced in order of importance to the business).
Regarding claim 20,
Greene further teaches
wherein the program instructions further cause the computer to: present the call stack in a user interface in which each of the one or more application components of the call stack is labeled with respect to an identity of each application component (¶ 0033 - The analysis module 320 may generate one or more suggestions or advice based on the security analysis, e.g., via user interface 308. Suggestions may be based on recommendations included with the known vulnerabilities in the known vulnerability database 315, based on factors included in the SBOM 314, or based on other factors. For example, the known vulnerability database 315 may suggest that the security vulnerability in Example Software vl .3 is a high-risk vulnerability, and that Example Software should be updated to vl .4).
Claims 4,13,19 are rejected under 35 U.S.C. 103 as being unpatentable over Greene in view of Morrison further in view of Arvanites et al. Publication No.US 2019/0334943 A1 ( Arvanites hereinafter)
Regarding claim 4,
Greene further teaches
wherein the one or more risk criteria are based on a trusted list of external calls made when responding to the API request (¶ 0024 - At 210, the method may include adjusting, freezing, or quarantining messages at the SASP if they appear to violate known security risks, contain incorrect information, exhibit unusual transmission patterns or frequencies, or otherwise appear unreliable or unsafe. For example, the SASP system may compare outgoing service request calls to a list of security issues from OWASP® API security project. Some issues may be flagged, while other issues may be corrected. d – the SASP system may parse through all fields in service request calls identified within a client's code, and generate a list, chart, or table of what type of data the system believes each field should be (e. g., l.name=last name). A client may then go through and update or correct incorrect assumptions. When actual service request calls are made, the SASP system may use the list to compare the data actually being passed to what is expected to be passed - When actual service request calls are made, the SASP
system may use the list to compare the data actually being passed to what is expected to be passed ) .
Greene does not explicitly teach
wherein the one or more risk criteria are based on a trusted API source list, and on a list of permitted operations with regard to responding to the API request
Arvanites teaches
wherein the one or more risk criteria are based on a trusted API source list,, and on a list of permitted operations with regard to responding to the API request (¶ 0030 - The scoring module may be configured to evaluate whether a network address of the transmitting source node is associated with a specific location, may be configured to evaluate a network address threat type, and/or may be configured to compare a network address of the transmitting source node against a network list, e.g. blacklist or whitelist. The scoring module may be configured to evaluate whether the API request by a digital identity or a number of digital identities, individually or in combination, meets an acceptable level of trust based upon previous interactions with the system. The scoring module may compare content within the data packet of the API request from the transmitting source node, may compare content within the data packet of the API response from the transmitting source node, and/or may make an overall assessment of threat level based on multiple weighted factors, matching the overall assessment to an action set indicating actions to be taken with respect to the API request. The transmission module may drop the API request under certain circumstances or in some instances may pass the API request unaltered – ¶0046 - Third level evaluation 403 consists of the system determining whether, in the case of a bot threat from an allowed location, the network address belongs to a specified list of network addresses, typically, but not limited, to act as a whitelist or blacklist. A whitelist is a list of approved network addresses while a blacklist is a list of expressly disapproved network addresses. If the network address matches the network address in the network address whitelist or blacklist, the system may execute an action set specific to that network address- ¶ 0047 - Different action sets may be provided based on the evaluations presented. Further, in operation, the information needed to make the evaluations, such as a network list ( e.g. whitelist or blacklist), list of locations)
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Greene to include the teachings of Arvanites. The motivation for doing so is to allow the system to reduce risk associated with API transactions with minimal effect to overall system performance. ( ¶ 0001 – Arvanites) .
Regarding claim 13,
Greene further teaches
wherein the one or more risk criteria are based on a trusted list of external calls made when responding to the API request (¶0024 - At 210, the method may include adjusting, freezing, or quarantining messages at the SASP if they appear to violate known security risks, contain incorrect information, exhibit unusual transmission patterns or frequencies, or otherwise appear unreliable or unsafe. For example, the SASP system may compare outgoing service request calls to a list of security issues from OWASP® API security project. Some issues may be flagged, while other issues may be corrected. – the SASP system may parse through all fields in service request calls identified within a client's code, and generate a list, chart, or table of what type of data the system believes each field should be (e. g., l.name=last name). A client may then go through and update or correct incorrect assumptions. When actual service request calls are made, the SASP system may use the list to compare the data actually being passed to what is expected to be passed - When actual service request calls are made, the SASP
system may use the list to compare the data actually being passed to what is expected to be passed ) .
Greene does not explicitly teach
wherein the one or more risk criteria are based on a trusted API source list, and on a list of permitted operations with regard to responding to the API request
Arvanites teaches
wherein the one or more risk criteria are based on a trusted API source list, and on a list of permitted operations with regard to responding to the API request (¶ 0030 - The scoring module may be configured to evaluate whether a network address of the transmitting source node is associated with a specific location, may be configured to evaluate a network address threat type, and/or may be configured to compare a network address of the transmitting source node against a network list, e.g. blacklist or whitelist. The scoring module may be configured to evaluate whether the API request by a digital identity or a number of digital identities, individually or in combination, meets an acceptable level of trust based upon previous interactions with the system. The scoring module may compare content within the data packet of the API request from the transmitting source node, may compare content within the data packet of the API response from the transmitting source node, and/or may make an overall assessment of threat level based on multiple weighted factors, matching the overall assessment to an action set indicating actions to be taken with respect to the API request. The transmission module may drop the API request under certain circumstances or in some instances may pass the API request unaltered – ¶0046 - Third level evaluation 403 consists of the system determining whether, in the case of a bot threat from an allowed location, the network address belongs to a specified list of network addresses, typically, but not limited, to act as a whitelist or blacklist. A whitelist is a list of approved network addresses while a blacklist is a list of expressly disapproved network addresses. If the network address matches the network address in the network address whitelist or blacklist, the system may execute an action set specific to that network address- ¶ 0047 - Different action sets may be provided based on the evaluations presented. Further, in operation, the information needed to make the evaluations, such as a network list ( e.g. whitelist or blacklist), list of locations)
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Greene to include the teachings of Arvanites. The motivation for doing so is to allow the system to reduce risk associated with API transactions with minimal effect to overall system performance. ( ¶ 0001 – Arvanites) .
Regarding claim 19,
Greene further teaches
wherein the one or more risk criteria are based on a trusted list of external calls made when responding to the API request (¶0024 - At 210, the method may include adjusting, freezing, or quarantining messages at the SASP if they appear to violate known security risks, contain incorrect information, exhibit unusual transmission patterns or frequencies, or otherwise appear unreliable or unsafe. For example, the SASP system may compare outgoing service request calls to a list of security issues from OWASP® API security project. Some issues may be flagged, while other issues may be corrected – the SASP system may parse through all fields in service request calls identified within a client's code, and generate a list, chart, or table of what type of data the system believes each field should be (e. g., l.name=last name). A client may then go through and update or correct incorrect assumptions. When actual service request calls are made, the SASP system may use the list to compare the data actually being passed to what is expected to be passed - When actual service request calls are made, the SASP
system may use the list to compare the data actually being passed to what is expected to be passed ) .
However, Greene does not explicitly teach
wherein the one or more risk criteria are based on a trusted API source list, and on a list of permitted operations with regard to responding to the API request
Arvanites teaches
wherein the one or more risk criteria are based on a trusted API source list, and on a list of permitted operations with regard to responding to the API request (request (¶ 0030 - The scoring module may be configured to evaluate whether a network address of the transmitting source node is associated with a specific location, may be configured to evaluate a network address threat type, and/or may be configured to compare a network address of the transmitting source node against a network list, e.g. blacklist or whitelist. The scoring module may be configured to evaluate whether the API request by a digital identity or a number of digital identities, individually or in combination, meets an acceptable level of trust based upon previous interactions with the system. The scoring module may compare content within the data packet of the API request from the transmitting source node, may compare content within the data packet of the API response from the transmitting source node, and/or may make an overall assessment of threat level based on multiple weighted factors, matching the overall assessment to an action set indicating actions to be taken with respect to the API request. The transmission module may drop the API request under certain circumstances or in some instances may pass the API request unaltered – ¶0046 - Third level evaluation 403 consists of the system determining whether, in the case of a bot threat from an allowed location, the network address belongs to a specified list of network addresses, typically, but not limited, to act as a whitelist or blacklist. A whitelist is a list of approved network addresses while a blacklist is a list of expressly disapproved network addresses. If the network address matches the network address in the network address whitelist or blacklist, the system may execute an action set specific to that network address- ¶ 0047 - Different action sets may be provided based on the evaluations presented. Further, in operation, the information needed to make the evaluations, such as a network list ( e.g. whitelist or blacklist), list of locations)
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Greene to include the teachings of Arvanites. The motivation for doing so is to allow the system to reduce risk associated with API transactions with minimal effect to overall system performance. ( ¶ 0001 – Arvanites) .
Claims 7,8 are rejected under 35 U.S.C. 103 as being unpatentable over Greene in view of Morrison further in view of Choi et al. WO2024122904A1 (Choi hereinafter)
Regarding claim 7,
Greene does not explicitly teach
wherein the software bill of materials is specific to a particular API
However, Choi teaches
software bill of materials is specific to a particular API (Abstract a reference information DB which stores software bill of materials (SBOM) information about the type of API function for executing an installation file installed in a client terminal and the parameters of the API function at the time of API function calling as previous component information,-Description - generate SBOM information about the type and parameters of the API function for which the SBOM parameters were confirmed as the following component information to use as a standard. API information extraction module stored in information DB).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Greene to include the teachings of Choi. The motivation for doing so is to allow the system to identify the presence of malicious code by analyzing software patch files. ( Description– Choi) .
Regarding claim 8,
Greene does not explicitly teach
mapping additional application components of the call stack to an additional one or more software bills of material.
However, Choi teaches
mapping additional application components of the call stack to an additional one or more software bills of material (Abstract - generates SBOM information about the type and parameters of API function having the identified parameter as the next component information and stores the SBOM information in the reference information DB; and a comparison analysis module which compares the next component information generated by the API information extraction module with the previous component information of the API function to determine whether the next component information matches the previous component information – Description – The detection system 10 and detection method of the present invention extract the SBOM (Software Bill of Materials) of the previous component information for the SBOM previous patch file installed on the client terminal (C) of the user corresponding to the demand of the application, and then extract the SBOM (Software Bill of Materials) SBOM from the client terminal. When installation of the patch file to be confirmed is attempted in (C), the SBOM of the following component information for the patch file to be SBOM confirmed is extracted and compared to enable active metadata comparison from the consumer (user) perspective ).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Greene to include the teachings of Choi. The motivation for doing so is to allow the system to prevent infection of the client terminal in advance by proactively identifying abnormalities in the patch file rather than relying solely on the supplier's judgment of whether the patch file is dangerous. ( Abstract – Choi) .
Claims 21-22 are rejected under 35 U.S.C. 103 as being unpatentable over Greene in view of Morrison further in view of Dwivedi et al. Publication No. US 2025/0053660 A1 (Dwivedi hereinafter)
Regarding claim 21,
Greene does not explicitly teach
wherein the risk score is determined based on one or more factors each associated with a respective weight of one or more weights, and wherein the one or more factors include a number of vulnerabilities associated with the one or more application components.
However, Dwivedi teaches
wherein the risk score is determined based on one or more factors each associated with a respective weight of one or more weights, and wherein the one or more factors include a number of vulnerabilities associated with the one or more application components (¶0027 – ¶0028 -The agent can monitor components of the device other than user-installed applications, such as device
drivers, services, firmware, middleware, plug-ins and extensions, etc. By monitoring the device activity, the agent can gather vulnerability-related metrics that are related to the applications hosted by the device and/or other components running on the device. The agent can determine a risk score of the device by calculating a particular statistic (e.g., the weighted average, the weighted sum, etc.) of the vulnerability-related metrics. Examples of the vulnerability-related metrics can include, for example, websites accessed, network activity, current location of the device, and/or other current vulnerabilities (e.g., outdated operating system version, outdated applications, outdated security updates, device is rooted, presence of known malware, etc.). The vulnerability-related metrics can reflect the status of the user device at a point in time (e.g., when the metric is collected). In some embodiments, the vulnerability-related metrics can reflect device activity that occurred over a period of time. The period of time can be, for example, the time period since the vulnerability-related metric was last calculated, or can be a specified time period (e.g., the last two minutes - Each vulnerability-related metric can have a corresponding weighting value. The weighting value can represent the seriousness of the vulnerability, and can be set by the organization that supports the device. That is, an organization can set the weights of each vulnerability-related metric -See ¶ 0012)
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Greene to include the teachings of Dwivedi. The motivation for doing so is to allow the system to measure the risk level, and implementing security-based actions in view of the measured risk level (Abstract – Dwivedi).
Regarding claim 22,
Greene does not explicitly teach
wherein the risk metadata further includes a number of vulnerabilities associated with one or more previous versions of an application that includes the one or more application components or historical data indicating how quickly a known vulnerability of the application was remediated
However, Dwivedi teaches
risk metadata further includes a number of vulnerabilities associated with one or more previous versions of an application that includes the one or more application components or historical data indicating how quickly a known vulnerability of the application was remediated(¶0027 – ¶0028 -The agent can monitor components of the device other than user-installed applications, such as device drivers, services, firmware, middleware, plug-ins and extensions, etc. By monitoring the device activity, the agent can gather vulnerability-related metrics that are related to the applications hosted by the device and/or other components running on the device. The agent can determine a risk score of the device by calculating a particular statistic (e.g., the weighted average, the weighted sum, etc.) of the vulnerability-related metrics. Examples of the vulnerability-related metrics can include, for example, websites accessed, network activity, current location of the device, and/or other current vulnerabilities (e.g., outdated operating system version, outdated applications, outdated security updates, device is rooted, presence of known malware, etc.). The vulnerability-related metrics can reflect the status of the user device at a point in time (e.g., when the metric is collected). In some embodiments, the vulnerability-related metrics can reflect device activity that occurred over a period of time. The period of time can be, for example, the time period since the vulnerability-related metric was last calculated, or can be a specified time period (e.g., the last two minutes - Each vulnerability-related metric can have a corresponding weighting value. The weighting value can represent the seriousness of the vulnerability, and can be set by the organization that supports the device. That is, an organization can set the weights of each vulnerability-related metric).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Greene to include the teachings of Dwivedi. The motivation for doing so is to allow the system to measure the risk level, and implementing security-based actions in view of the measured risk level (Abstract – Dwivedi).
Claim 23 is rejected under 35 U.S.C. 103 as being unpatentable over Greene in view of Morrison further in view of Wang et al. “ Understanding Real World Data Corruption in Cloud Systems”– 2015 IEEE – International Conference on Cloud Engineering (Wang hereinafter)
Regarding claim 23,
Greene does not explicitly teach
wherein the risk metadata further includes one or more concurrency issues associated with an application that includes the one or more application components, and wherein the one or more concurrency issues include a race condition or data corruption.
However, Wang teaches
risk metadata further includes one or more concurrency issues associated with an application that includes the one or more application components, and wherein the one or more concurrency issues include a race condition or data corruption (Section I - Data corruption impact: Data corruption impact is not limited to data integrity. If corrupted blocks are not handled correctly, the data they store could be completely lost. Corrupted metadata prevents data from being accessed, which might cause wrong data deletion – Cloud computing has become increasingly popular recently. Massive data processing systems such as Hadoop are most commonly used cloud applications. 1) what impact can data corruption have on the application and system? 2) how is data corruption detected? 3) what is the causes of the data corruption? and 4) what problems can occur while attempting to handle data corruption Section III - Metadata corruption: Block metadata is another frequently mentioned type of data in the studied data corruption incidents. In general, the DN creates a metadata file for each block stored on it. The metadata file records a lot of block information. Section B – Data Corruption Sample Collection - Data corruption causes: For data corruption causes, we use the following categories: 1) improper runtime checking which means data corruptions of this type can be fixed by checking inputs to Hadoop or by checking resources usages of Hadoop; 2) race condition which means multiple threads are changing the same variable value or are writing to the same file -See Also Section V)
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Greene to include the teachings of Wang. The motivation for doing so is to allow the system to classify data corruption problems that can occur in distributed file system designed for use in cloud computing system ( Section IV – Wang).
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to YOUNES NAJI whose telephone number is (571)272-2659. The examiner can normally be reached Monday - Friday 8:30 AM -5:30 PM.
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, Oscar A Louie can be reached at (571) 270-1684. 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.
/YOUNES NAJI/Primary Examiner, Art Unit 2445