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 application filed on April 15, 2024.
Claims 1-28 are pending.
Claims 13 and 26 are objected to because of the following informalities:
Claims 13 and 16 state “the API” in line 1. In the interest of consistency, it is recommended that this be amended to “the one or more APIs”.
Appropriate correction is required.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 27-28 are rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter. The claim(s) does/do not fall within at least one of the four categories of patent eligible subject matter.
Claims 27-28 are directed to a machine-readable medium. The specification does not describe such a medium. The specification describes a computer-readable storage medium as a non-transitory computer-readable storage medium that excludes transitory signals (Paragraph 437). However, a machine-readable medium is not necessarily a computer-readable storage medium. Therefore, given its broadest, reasonable interpretation, a machine-readable medium can encompass transmission mediums such as a carrier wave from a network. Consequently, the carrier wave can be reasonably interpreted as carrying electrical signals.
Claims that recite nothing but the physical characteristics of a form of energy, such as a frequency, voltage, or the strength of a magnetic field, define energy or magnetism per se, and as such as non-statutory natural phenomena. O’Reilly v. Morse, 56 U.S. (15 How.) 62, 112-14 (1853). Moreover, it does not appear that a claim reciting a wave encoded with functional descriptive material falls within any of the categories of patentable subject matter set forth in §101.
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, 14-15 and 27-28 are rejected under 35 U.S.C. 103 as being unpatentable over Khayat et al. (US 2024/0406201) in view of Szigeti et al. (US 2024/0403437).
With respect to Claim 1, Khayat et al. disclose:
dynamically creating at least one scanner for at least one category of application programming interface (“API”) identified in computer code; (establishing a separate application instance (dynamically creating) for each collector of the one or more collectors (scanner) wherein the one or more collectors are each specific to a different API of the one or more APIs (at least one category of APIs), Paragraph 88)
generating a risk score for the computer code based at least in part on data collected by the at least one scanner related to usage of one or more APIs within the at least one category; (The security system determines 540 security information that identifies a security risk using the reconstruction of the API network traffic. The security system may use the security related information (e.g., risk score and exposure) along with network information (e.g., traffic information) (data collected by that at least one scanner related to usage of one or more APIs) to calculate a risk factor (e.g., high risk, low risk) (risk score) that is specific to each connection entry., Paragraph 91)
and [alert/mitigate risk] based at least in part on a comparison of the risk score and a threshold value. (if the security risk is above a threshold level and/or of a particular type, the security module 260 may push the alert to a device associated with the administrator. In some embodiments, the alert may also include a recommended course of action to mitigate the security risk. The administrator may take action based on security risks described by the security information., Paragraphs 60 and 92-93)
Khayat et al. do not disclose:
[alert/mitigate risk] includes modifying an executable data file associated with the computer code.
However, Szigeti et al. disclose:
[alert/mitigate risk] includes modifying an executable data file associated with the computer code. (The one or more mitigation actions may include sending an alert regarding the external application programming interface, sending a report regarding the external application programming interface, blocking certain components of the external application programming interface, blocking the external application programming interface, blocking the application, and/or redirecting calls to the external application programming interface., Paragraph 88)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teaching of Szigeti et al. into the teaching of Khayat et al. to include [alert/mitigate risk] includes modifying an executable data file associated with the computer code in order to help mitigate vulnerabilities and threats in external APIs.
With respect to Claim 2, all the limitations of Claim 1 have been addressed above; and Khayat et al. further disclose:
wherein the computer code comprises a plurality of APIs in the at least one category (a different API of the one or more APIs (at least one category of APIs), Paragraph 88) and dynamically creating the at least one scanner comprises creating a first scanner for a first of the plurality of APIs based at least in part on one or more parameters of the first API and creating a second scanner for a second of the plurality of APIs based at least in part on one or more parameters of the second API. (establishing a separate application instance (dynamically creating) for each collector of the one or more collectors wherein the one or more collectors (first/second scanner) are each specific to a different API (one or more parameters) of the one or more APIs, Paragraph 88)
Claims 14-15 are system claims corresponding to the method claims above (Claims 1-2) and, therefore, are rejected for the same reasons set forth in the rejections of Claims 1-2.
Claims 27-28 are machine-readable medium claims corresponding to the method claims above (Claims 1-2) and, therefore, are rejected for the same reasons set forth in the rejections of Claims 1-2.
Claims 3 and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Khayat et al. (US 2024/0406201) in view of Szigeti et al. (US 2024/0403437) and in further view of Velur et al. (US 2020/0242254).
With respect to Claim 3, all the limitations of Claim 1 have been addressed above; and Khayat et al. and Szigeti et al. do not disclose:
wherein the one or more APIs are each associated with a weight value used to generate the risk score.
However, Velur et al. disclose:
wherein the one or more APIs are each associated with a weight value used to generate the risk score. (a risk score of an API can be multiplied to assign more weight to that specific API as compared to other APIs, Paragraph 60)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teaching of Velur et al. into the teaching of Khayat et al. and Szigeti et al. to include wherein the one or more APIs are each associated with a weight value used to generate the risk score in order to allow certain API functionalities to be prioritized over other APIs depending on the context of the application. (Velur et al., Paragraph 60)
Claim 16 is a system claim corresponding to the method claim above (Claim 3) and, therefore, is rejected for the same reasons set forth in the rejection of Claims 3.
Claims 4, 6, 17 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Khayat et al. (US 2024/0406201) in view of Szigeti et al. (US 2024/0403437) and in further view of Hecht et al. (US 10,607,015).
With respect to Claim 4, all the limitations of Claim 1 have been addressed above; and Khayat et al. and Szigeti et al. do not disclose:
wherein generating the risk score comprises generating an enhanced score based at least in part on a use environment, generating a base score based at least in part on a number of instances of each of the one or more APIs, and combining the enhanced score and the base score.
However, Hecht et al. disclose:
wherein generating the risk score comprises generating an enhanced score based at least in part on a use environment, (the resource risk score (enhanced score) may indicate the number of resources targeted in the code segment (use environment), Column 23, lines 14-16) generating a base score based at least in part on a number of instances of each of the one or more APIs, (The determined API risk score may represent the number and type of API calls (number of instances) included in the code segment, Column 23, lines 10-12) and combining the enhanced score and the base score. (the risk scores determined in steps 930 (API risk score), 940, and 950 (resource risk score) may be combined according to one or more algorithms and/or formulas, Column 23, lines 21-25)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teaching of Hecht et al. into the teaching of Khayat et al. and Szigeti et al. to include wherein generating the risk score comprises generating an enhanced score based at least in part on a use environment, generating a base score based at least in part on a number of instances of each of the one or more APIs, and combining the enhanced score and the base score in order to determine an overall security risk presented by a code segment based on various risk scores. (Hecht et al., Column 23, lines 32-35)
With respect to Claim 6, all the limitations of Claim 1 have been addressed above; and Khayat et al. and Szigeti et al. further disclose:
wherein the at least one scanner is created during the first build time, (Khayat et al., The one or more collectors may be of different types. For example, a collector may be a standalone collector that uses HTTP-based clients to connect to remote applications and retrieve information via APIs of cloud applications. In another example, a collector (at least one scanner) is a module that is installed as an extension within a cloud application. (created during the first build time) In another example, a collector is a man-in-the-middle collector that redirects traffic between two cloud applications. In another example, a collector is a third-party aggregator that has access to traffic from other applications and can push the network traffic information to the correlation module 250., Paragraph 45; collector must have been created at some point (first build time)) the at least one scanner is used to collect the data during runtime (Khayat et al., The security system determines 540 security information that identifies a security risk using the reconstruction of the API network traffic. The security system may use the security related information (e.g., risk score and exposure) along with network information (e.g., traffic information) (data collected by that at least one scanner related to usage of one or more APIs) to calculate a risk factor (e.g., high risk, low risk) (risk score) that is specific to each connection entry., Paragraph 91)
Khayat et al. and Szigeti et al. do not disclose:
further comprising:
analyzing the computer code at a first build time to identify the at least one category of API in the computer code, and modification of the executable data file is performed at a second build time after the first build time.
However, Hecht et al. disclose:
analyzing the computer code at a first build time to identify the at least one category of API in the computer code, (accessing one or more code segments based on creation or modification of the code segment (build time) and determining the number and type of API calls (category) included in the code segment(s), Columns 22 and 23, lines 63-67 and 1-12 respectively) and modification of the executable data file is performed at a second build time after the first build time. (Accordingly, code segment monitor 120 may take a control action, which may include flagging or reporting the anomaly, quarantining or disabling code segment 723, (modification of the executable data file at a second build time) mitigating or addressing harm that may be caused by code segment 723, (modification of the executable data file at a second build time) reporting or restricting further actions by user 703, or various other control actions, Column 17, lines 35-41)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teaching of Hecht et al. into the teaching of Khayat et al. and Szigeti et al. to include analyzing the computer code at a first build time to identify the at least one category of API in the computer code, and modification of the executable data file is performed at a second build time after the first build time in order to determine help determine an API risk score and to determine when control actions need to be taken to mitigate and/or address a risk. (Hecht et al., Columns 17 and 23, lines 35-41 and 1-12 respectively)
Claims 17 and 19 are system claims corresponding to the method claims above (Claims 4 and 6) and, therefore, are rejected for the same reasons set forth in the rejections of Claims 4 and 6.
Claims 7-8, 10, 20-21 and 23 are rejected under 35 U.S.C. 103 as being unpatentable over Khayat et al. (US 2024/0406201) in view of Szigeti et al. (US 2024/0403437) and in further view of Jian Lin et al. (“Executable Program Code Segment Address Randomization”, 2015).
With respect to Claim 7, all the limitations of Claim 1 have been addressed above; and Khayat et al. and Szigeti et al. do not disclose:
wherein modifying the executable data file comprises moving portions of the executable data file to less vulnerable data segments to reduce a vulnerability of the executable data file.
However, Jian Lin et al. disclose:
wherein modifying the executable data file comprises moving portions of the executable data file to less vulnerable data segments to reduce a vulnerability of the executable data file. (identify the instructions which need relocation in the ELF executable program (executable data file) using EPCSAR which modifies the ELF loader to map the code segment to a random address and relocates the code segment (moving portions of the executable file to less vulnerable data segments), 1. Introduction, Paragraph 5, lines 1-8)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teaching of Jian Lin et al. into the teaching of Khayat et al. and Szigeti et al. to include wherein modifying the executable data file comprises moving portions of the executable data file to less vulnerable data segments to reduce a vulnerability of the executable data file in order to help mitigate exploits by increasing the difficulty to predict code location. (Jian Lin et al., 1. Introduction, Paragraph 1, lines 1-12)
With respect to Claim 8, all the limitations of Claim 7 have been addressed above; and Khayat et al. and Szigeti et al. do not disclose:
wherein the executable data file is an Executable and Linkable Format (ELF) data file and the portions of the executable data file moved to the less vulnerable data segments comprises at least one of a read-only data segment or a read-write data segment.
However, Jian Lin et al. disclose:
wherein the executable data file is an Executable and Linkable Format (ELF) data file (identify the instructions which need relocation in the ELF executable program, 1. Introduction, Paragraph 5, lines 1-5) and the portions of the executable data file moved to the less vulnerable data segments comprises at least one of a read-only data segment or a read-write data segment. (In the executable program code segment, in addition to part of the really execute code, read-only data are also located in code segment. (portions of the executable data file), III. Design and Impletement, Paragraph 3, lines 1-3)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teaching of Jian Lin et al. into the teaching of Khayat et al. and Szigeti et al. to include wherein the executable data file is an Executable and Linkable Format (ELF) data file and the portions of the executable data file moved to the less vulnerable data segments comprises at least one of a read-only data segment or a read-write data segment in order to help mitigate exploits by increasing the difficulty to predict code location in Elf files. (Jian Lin et al., 1. Introduction, Paragraph 1, lines 1-12)
With respect to Claim 10, all the limitations of Claim 1 have been addressed above; and Khayat et al. and Szigeti et al. do not disclose:
wherein modifying the executable data file comprises moving at least a portion of the data file from a first data segment within the executable data file to a second data segment within the executable data file.
However, Jian Lin et al. disclose:
wherein modifying the executable data file comprises moving at least a portion of the data file from a first data segment within the executable data file to a second data segment within the executable data file. (identify the instructions which need relocation in the ELF executable program (executable data file) using EPCSAR which modifies the ELF loader to map the code segment to a random address and relocates (move) the code segment (moving at least a portion of the data file from a first data segment within the executable data file to a second data segment within the executable data file), 1. Introduction, Paragraph 5, lines 1-8)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teaching of Jian Lin et al. into the teaching of Khayat et al. and Szigeti et al. to include wherein modifying the executable data file comprises moving at least a portion of the data file from a first data segment within the executable data file to a second data segment within the executable data file in order to help mitigate exploits by increasing the difficulty to predict code location. (Jian Lin et al., 1. Introduction, Paragraph 1, lines 1-12)
Claims 20-21 and 23 are system claims corresponding to the method claims above (Claims 7-8 and 10) and, therefore, are rejected for the same reasons set forth in the rejections of Claims 7-8 and 10.
Claims 9 and 22 are rejected under 35 U.S.C. 103 as being unpatentable over Khayat et al. (US 2024/0406201) in view of Szigeti et al. (US 2024/0403437) and in further view of Hen et al. (2022/0400127).
With respect to Claim 9, all the limitations of Claim 1 have been addressed above; and Khayat et al. and Szigeti et al. do not disclose:
further comprising:
adjusting the threshold value based on historical risk data associated with the executable data file.
However, Hen discloses:
adjusting the threshold value based on historical risk data (the predefined threshold value may be determined through a determination of historical risk scores, Paragraph 26)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teaching of Hen et al. into threshold value associated with the executable data file as taught by Khayat et al. and Szigeti et al. to include adjusting the threshold value based on historical risk data in order to help set/predefine threshold values used in risk/anomaly detection.
Claim 22 is a system claim corresponding to the method claim above (Claim 9) and, therefore, is rejected for the same reasons set forth in the rejection of Claims 9.
Claims 11 and 24 are rejected under 35 U.S.C. 103 as being unpatentable over Khayat et al. (US 2024/0406201) in view of Szigeti et al. (US 2024/0403437) in view of Jian Lin et al. (“Executable Program Code Segment Address Randomization”, 2015) and in further view of Larsen et al. (US 6,154,819).
With respect to Claim 11, all the limitations of Claim 10 have been addressed above; and Khayat et al., Szigeti et al. and Jian Lin et al. do not disclose:
wherein the second data segment is a hardware-protected data segment.
However, Larsen et al. disclose:
wherein the second data segment is a hardware-protected data segment. (One present method of block protection for flash memory includes protecting a pre-determined number of blocks through a lock/unlock hardware pin. This requires the user to determine which blocks of memory are hardware protectable and reserve those blocks for critical data or program code, Columns 1 and 2, lines 65-67 and 1-2 respectively)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teaching of Larsen et al. into the teaching of Khayat et al., Szigeti et al. and Jian Lin et al. to include wherein the second data segment is a hardware-protected data segment in order to protect a pre-determined number of blocks that contain critical data or program code. (Larsen et al., Columns 1 and 2, lines 65-6 and 1-2 respectively)
Claim 24 is a system claim corresponding to the method claim above (Claim 11) and, therefore, is rejected for the same reasons set forth in the rejection of Claims 11.
Claims 12 and 25 are rejected under 35 U.S.C. 103 as being unpatentable over Khayat et al. (US 2024/0406201) in view of Szigeti et al. (US 2024/0403437) in view of Jian Lin et al. (“Executable Program Code Segment Address Randomization”, 2015) and in further view of Li et al. (US 2024/0176914).
With respect to Claim 12, all the limitations of Claim 10 have been addressed above; and Khayat et al., Szigeti et al. and Jian Lin et al. do not disclose:
wherein the second data segment is a read-only data segment.
However, Li et al. disclose:
wherein the second data segment is a read-only data segment. Generally, the application program includes three components: a code segment, a data segment, and a read-only data segment, Paragraph 3)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teaching of Larsen et al. into the teaching of Khayat et al., Szigeti et al. and Jian Lin et al. to include wherein the second data segment is a read-only data segment in order to configurate a data segment that is write-protected such that tampering of read-only data can be prevented. (Li et al., Paragraph 3)
Claim 25 is a system claim corresponding to the method claim above (Claim 12) and, therefore, is rejected for the same reasons set forth in the rejection of Claims 12.
Allowable Subject Matter
Claims 5, 13, 18 and 26 are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Collins et al. (US 10,528,741) disclose automatically assessing and mitigating operational risks associated with using a software component in a software application.
Vlahovic et al. (US 2021/0352097) disclose application risk assessment in an authentication service.
Mierezuk et al. (US 2024/0176893) disclose analyzing a web browser extension.
Leigh et al. (US 2025/0159013) disclose a clous service security risk assessment.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to LANNY N UNG whose telephone number is (571)270-7708. The examiner can normally be reached Mon-Thurs 6am-4pm.
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, Bradley Teets can be reached at 571-272-3338. 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.
/LANNY N UNG/Examiner, Art Unit 2197