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 .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 04/21/2026 has been entered.
Claims 1-2,4-11, 13-17,19-23 have been examined. Claims 3,12,18 are cancelled.
Response to Argument
Applicant’s arguments, see Remarks – Pages 8-9, filed on 04/21/2026 with respect to the rejections of claims 1,10,16 under 103 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 Duggan.
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) further in view of Duggan et al. Publication No. US 2023/0359744 Al (Duggan 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 and historical data indicating how quickly a known vulnerability of the application was remediated ; 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).
Duggan teaches
wherein the risk metadata includes historical data indicating how quickly a known vulnerability of the application was remediated (¶ 0002 - the SBOM can include a list of the software components used to create the software code and metadata associated with each software – ¶0009 – the techniques can detect software supply chain attacks occurred to one or more software components used by the software code, and thus can enhance security of the software code. Further, the techniques can look for information beyond the simple vulnerability levels documented in the SBOM and collect the metadata about the software components from external sources. The comprehensive information enables the server to produce a more accurate result of the vulnerability level of a software component. As well as detecting deliberate software supply chain attacks, the techniques also lend themselves to detecting cases where a software component has not been deliberately compromised but is still vulnerable – ¶0038 - the at least one metric can include response time of one or more reported issues. For example, the response time can be the time taken to make fixes for significant reported issues. If the response time exceeds a predetermined threshold, the library can be potentially vulnerable – Claim 1 - generating, by the server, a risk assessment based on at least one metric corresponding to the library, wherein the at least one metric is associated with one or more maintainers of the library).
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 Duggan. The motivation for doing so is to allow the system to identify security risks in software code based on software bill of materials (SBOM) (Abstract – Duggan).
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 and historical data indicating how quickly a known vulnerability of the application was remediated; 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).
Duggan teaches
wherein the risk metadata includes historical data indicating how quickly a known vulnerability of the application was remediated (¶0002 - the SBOM can include a list of the software components used to create the software code and metadata associated with each software – ¶0009 – the techniques can detect software supply chain attacks occurred to one or more software components used by the software code, and thus can enhance security of the software code. Further, the techniques can look for information beyond the simple vulnerability levels documented in the SBOM and collect the metadata about the software components from external sources. The comprehensive information enables the server to produce a more accurate result of the vulnerability level of a software component. As well as detecting deliberate software supply chain attacks, the techniques also lend themselves to detecting cases where a software component has not been deliberately compromised but is still vulnerable – ¶ 0038 - the at least one metric can include response time of one or more reported issues. For example, the response time can be the time taken to make fixes for significant reported issues. If the response time exceeds a predetermined threshold, the library can be potentially vulnerable – Claim 1 - generating, by the server, a risk assessment based on at least one metric corresponding to the library, wherein the at least one metric is associated with one or more maintainers of the library).
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 Duggan. The motivation for doing so is to allow the system to identify security risks in software code based on software bill of materials (SBOM) (Abstract – Duggan).
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 and historical data indicating how quickly a known vulnerability of the application was remediated; 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).
Duggan teaches
wherein the risk metadata includes historical data indicating how quickly a known vulnerability of the application was remediated (¶0002 - the SBOM can include a list of the software components used to create the software code and metadata associated with each software –¶0009 – the techniques can detect software supply chain attacks occurred to one or more software components used by the software code, and thus can enhance security of the software code. Further, the techniques can look for information beyond the simple vulnerability levels documented in the SBOM and collect the metadata about the software components from external sources. The comprehensive information enables the server to produce a more accurate result of the vulnerability level of a software component. As well as detecting deliberate software supply chain attacks, the techniques also lend themselves to detecting cases where a software component has not been deliberately compromised but is still vulnerable – ¶0038 - the at least one metric can include response time of one or more reported issues. For example, the response time can be the time taken to make fixes for significant reported issues. If the response time exceeds a predetermined threshold, the library can be potentially vulnerable – Claim 1 - generating, by the server, a risk assessment based on at least one metric corresponding to the library, wherein the at least one metric is associated with one or more maintainers of the library).
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 Duggan. The motivation for doing so is to allow the system to identify security risks in software code based on software bill of materials (SBOM) (Abstract – Duggan).
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 Duggan 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 Duggan 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) .
Claim 21 is rejected under 35 U.S.C. 103 as being unpatentable over Greene in view of Morrison further in view of Duggan further in view of Ting et al. Publication No. US 2023/0134122 A1 ( Ting hereinafter)
Regarding claim 21,
Greene does not explicitly teach
wherein the risk score is determined based on a plurality of factors each associated with a respective weight of one or more weights, and wherein the plurality of factors include two or more of: an indication of whether the API request involves public data or confidential data, one or more software defects caused by an API transaction associated with the API request, one or more system resources consumed by the API transaction, one or more configuration issues caused by the API transaction, one or more scalability issues caused by the API transaction, and one or more incompatibilities between the API transaction and another system.
However, Ting teaches
wherein the risk score is determined based on a plurality of factors each associated with a respective weight of one or more weights (¶0020 - risk scores may be generated at a device level by an agent running on the node. A risk
score obtained as described herein may be a weighted (and normalized) average of individual risks to confidentiality, integrity and availability).
wherein the plurality of factors include two or more of: an indication of whether the API request involves public data or confidential data, one or more software defects caused by an API transaction associated with the API request, one or more system resources consumed by the API transaction, one or more configuration issues caused by the API transaction, one or more scalability issues caused by the API transaction, and one or more incompatibilities between the API transaction and another system (¶0020 - the ePHI security score reflects how well an organization can be expected to secure ePHI data based on a comprehensive and automated assessment of internal risks This approach leverages intelligent agents running on some or all nodes of the system to identify how and what ePHI content passes between an application and system services (e.g., network services or files services), so a dynamic risk model can be utilized and updated to characterize threats and vulnerabilities to security and integrity controls from users, applications and system resources that interact with ePHI – ¶ 0067 - Each risk model defines a set of conditions which, if some subset (i.e., the minimum cut set) is met, would result in an actionable risk level ( e.g., a high likelihood that one or more system resources have been compromised leading to the likelihood of an ePHI incident) - Each risk model defines a set of conditions which, if some subset (i.e., the minimum cut set) is met, would result in an actionable risk level ( e.g., a high likelihood that one or more system resources have been compromised leading to the likelihood of an ePHI incident) – ¶0034 - The vulnerability would be "Known CVE software vulnerability," which would be true in the AND-OR diagram when the version of the module is listed in the CVE database. Another vulnerability can be, "Module is different from previous inventory version"-this would be true if a new version of a library that was not used before is now being loaded and used. These and other vulnerability conditions are stored in the vulnerability database 155 and in evaluating risk – ¶0039 - Characterizing what resources an application 137
uses and how it uses them provides an effective approach to determining whether the application can have a detrimental effect on the device 100. The more requests for resources that an application 137 makes, the greater the risk it represents;
this applies to trusted enterprise applications as well as newly installed applications – See Also ¶0044);
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 Ting. The motivation for doing so is to allow the system to continuously and quantitatively assess the risk to data confidentiality, integrity, and availability on identified on endpoints, servers, medical devices, and "Internet of things" devices in a networked healthcare environment monitor resource requests by user applications running on the various device (Abstract – Ting).
Claim 22 is rejected under 35 U.S.C. 103 as being unpatentable over Greene in view of Morrison further in view of Duggan further in Dwivedi et al. Publication No. US 2025/0053660 A1 (Dwivedi hereinafter)
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 and wherein the historical data indicates how quickly the known vulnerability of the application was remediated by a developer
Duggan teaches
wherein historical data indicating how quickly a known vulnerability of the application was remediated by a developer (Para 0002 - the SBOM can include a list of the software components used to create the software code and metadata associated with each software – Para 0009 – the techniques can detect software supply chain attacks occurred to one or more software components used by the software code, and thus can enhance security of the software code. Further, the techniques can look for information beyond the simple vulnerability levels documented in the SBOM and collect the metadata about the software components from external sources. The comprehensive information enables the server to produce a more accurate result of the vulnerability level of a software component. As well as detecting deliberate software supply chain attacks, the techniques also lend themselves to detecting cases where a software component has not been deliberately compromised but is still vulnerable – Para 0038 - the at least one metric can include response time of one or more reported issues. For example, the response time can be the time taken to make fixes for significant reported issues. If the response time exceeds a predetermined threshold, the library can be potentially vulnerable – Claim 1 - generating, by the server, a risk assessment based on at least one metric corresponding to the library, wherein the at least one metric is associated with one or more maintainers of the library - A maintainer can be a person who builds source code into a binary package for distribution, commits patches, or organizes code in a source repository).
However, Green in view of Duggan 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
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 (¶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 Duggan further in view of Jeong et al. Publication No. KR 101978685 B1 ( Jeong hereinafter) 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
inserting the risk metadata into a Hypertext Transfer Protocol (HTTP) response header,
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, Jeong teaches
inserting the risk metadata into a Hypertext Transfer Protocol (HTTP) response header (Abstract - the security policy synchronization method of a 3-tier CASB service system according to an embodiment of the present invention is a method of security policy synchronization of a 3-tier CASB service system by inserting policy related metadata into an HTTP header when a security policy is set in a private CASB or a public CASB, Receiving a security policy received by the public CASB; A security policy checking step of receiving packet data from the public CASB and confirming the security policy of the private CASB by checking the policy related metadata inserted in the HTTP header of the packet data; A response step of transmitting, to the private CASB, confirmation packet data indicating that the security policy has been normally received in response to the confirmed private CASB security policy; And the private CASB compares the security policy version information included in the confirmation packet data received from the public CASB with the version information of the security policy set in the private CASB, and when the version of the security setting policy of the public CASB is the latest version, And a policy re-setting step of modifying and reflecting the security policy according to the security setting policy attached to the version information of the version information – Claim 17 - The private cloud service can be provided only by an authenticated user, and is secured according to a predetermined security policy through a private CASB, Setting a security policy in the private CASB, inserting policy related metadata in the HTTP header, transmitting the HTTP packet data to the network, receiving the security policy received by the public CASB. )
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 Jeong. The motivation for doing so is to allow the system synchronize security policy between public and private service( Abstract – Jeong).
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
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
Prosecution Insights