DETAILED ACTION
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 18 February 2026 has been entered.
Response to Arguments
Applicant’s arguments (“REMARKS”) filed 18 February 2026 have been fully considered, and they are partially persuasive as to the previous grounds of rejection.
Claims 1, 3, and 9 were amended. Claims 2 and 10 were canceled. Claims 1, 9, and 16 are independent. Claims 1, 3-9, and 11-20 are currently pending.
Re: Claim Rejections Under 35 U.S.C. §101
In view of the amendments, as indicated on pp.11-15 of the REMARKS, the rejection of claims 1, 3-9, and 11-15 under 35 U.S.C. §101 is withdrawn.
Independent claim 16 and dependent claims 17-20 have not been amended. The rejection of claims 16-20 under 35 U.S.C. §101, however, is maintained, on the reasoning set forth below.
With respect to Step 2A, Prone One, Applicant argues that the Examiner has applied the mental process grouping too broadly, arguing that ‘[u]nder the Examiner’s assertion, every function performed by any computer can be a ‘mental process’, because computers are digital calculators that can only perform data collection, analysis, and organization.’ Applicant cites Finjan, Inc. v. Blue Coat Systems, Inc., 879 F.3d 1299 (Fed. Cir. 2018).
The Examiner respectfully disagrees. This argument is not persuasive. The Prong One finding is maintained as to all pending claims.
The Examiner does not assert that every operation performed by a computer is a mental process. The finding is specific to the limitations recited. Identifying a request within code, separating that request into its constituent parts, determining which libraries a program uses, and assembling the results into a list are acts of recognition, evaluation, and organization that a person can perform upon a listing of code. They fall within the “Mental Processes” grouping under MPEP § 2106.04(a)(2)(III) whether or not a computer is used.
Applicant further argues that ‘Applicant’s specification specifically describes why the operations of Applicant’s claims cannot practically be performed by the human mind’. The Applicant, however, does not identify where in the Specification. The Examiner has reviewed the Specification and finds that the paragraph associated with this issue states the opposite: ‘Performing a manual audit of a business ecosystem or supply chain may be extremely difficult, time-consuming, and prone to errors, and infeasible to perform on a constant basis …’ (Specification, ¶12). According to the Specification, while manual audits are difficult, slow, and error-prone, manual audits are possible and can be practically performed by the human mind. The Specification describes an advantage in speed and accuracy obtained by automating audits, not an incapacity to perform audits using the human mind. The ability of a computer to perform an analysis more efficiently than a person does not remove the analysis from the mental process grouping.
With respect to Step 2A, Prone Two, Applicant requests withdrawal of all rejections under 35 U.S.C. §101 but presents no argument directed to the language of independent claim 16, which was not amended. Applicant’s arguments are directed to limitations appearing only in independent claims 1 and 9. Claim 16 recites no operation where the information analyzed is acquired. Claim 16 only recites “a target entity of a service request from the client computing system” and then recites identifying a third party vendor based upon it, determining an executable code library, determining an operating system library, and generating the catalog to include those items. Claim 16 does not recite a scan of the client computing system or any monitoring of its data traffic. Its only additional elements are a “memory device storing instructions”, a “processor”, a “software security discovery system”, and a “client computing system”, each recited at a high level of generality and invoked merely as a tool. The arrangement of discovery operations found to integrate the exception in claims 1 and 9 is absent from claim 16.
With respect to Step 2B, Applicant argues that the Examiner’s finding that the recited operations are well-understood, routine, and conventional was not supported by any of the four categories of evidence required by MPEP § 2106.05(d)(I).
This argument is persuasive.
The additional elements found to be well-understood, routine, and conventional are: (i) determining code libraries and operating system libraries used by a computing system; (ii) recording identified components and targets in a catalog; (iii) scanning a directory of a computing system for executable code (claim 17); (iv) monitoring outgoing data traffic of a computing system (claim 18); and (v) executing a command to invoke an operating system function and examining the response (claim 20). Support is provided as follows.
Applicant’s specification refers to the claimed output by an established term of art, stating that the process generates ‘a catalog of components and their interactions, sometimes referred to as a software bill of materials (SBOM)’ (Specification, ¶0014). Applicant’s use of a recognized industry designation for the recited catalog (SBOM), without further explanation, indicates that generation of such a catalog was an activity recognized and named in the field. The Specification further describes the recited operations only in general functional terms, without disclosing any particular algorithm for performing them, which is consistent with those operations being so well known that they need not be described in detail.
Furthermore, the following references of record, issued to unrelated entities over a period of more than fifteen years preceding the effective filing date, demonstrate that each identified operation was in common use in the field of software security analysis:
Determining code libraries and operating system libraries used by a computing system: a component extraction tool determining what components the application comprises where the searched components may comprise libraries used by the application (Hayrynen et al., US 2014/0215620 A1, ¶¶43, 46); scanning object code to determine libraries used by the object code (Zhou et al., US 2022/0366047 A1, ¶¶42, 63-67); identifying operating system dynamic link libraries invoked by an application (Khazan et al., US 2005/0108562 A1, ¶¶73-74).
Recording identified components and targets in a catalog or report: storing in a test result database information elements indicating the libraries the application comprises, together with network activity and accessed sites, and providing the resulting report to the client device (Hayrynen ‘620, ¶¶43, 52 and Table 1); compiling a list of identified libraries within a feature set (Zhou ‘047, ¶¶63-67).
Scanning a directory or file system for executable code: a detection tool running as a background process, scanning a file system for different executables that may be stored on particular devices or located in particular directories within the system (Khazan ‘562, ¶¶110, 112); (Khairetdinov, US 9,104,878 B1, Col.5 lines 35-45)
Monitoring outgoing data traffic to identify targets contacted by the system: test routines monitoring the network activity of an application, monitoring the URLs accessed by the application and the ports and IP addresses used, and monitoring the dependency of the application on external web services (Hayrynen ‘620, ¶¶33, 34, 38).
Executing a command to invoke an operating system function and examining the response: instrumenting operating system libraries and invoking operating system routines to identify the dynamic link library associated with a call (Khazan ‘562, ¶¶41, 73-74).
Applicant further argues that the Examiner addressed only the individual elements and not the elements as arranged in the claims. As to claims 16-20, the ordered combination is addressed in the rejection below. The elements are performed in the order in which their outputs are required by the analysis, and no element is used in an unconventional manner by virtue of its position in that sequence.
Finally, Applicant argues that ‘the same logic as applies to obviousness rejections would apply here (logically, because unless something is ‘obvious’, it would not be well-understood, routine, and conventional)’. This argument is not persuasive. MPEP § 2106.05(d) provides that the question whether an additional element represents well-understood, routine, conventional activity is distinct from the question of patentability over the prior art.
Accordingly, while the rejection of claims 1, 3-9, and 11-15 under 35 U.S.C. §101 is withdrawn in view of the amendments to independent claims 1 and 9, the rejection of claims 16-20 under 35 U.S.C. §101 is maintained for the reasons stated above.
See Claim Rejections – 35 USC §101 below for further details.
Re: Claim Rejections Under 35 U.S.C. §103
Applicant’s amendments and arguments, indicated on pp.9-23 of the REMARKS, in response to the rejection of the claims under 35 U.S.C. §103 with respect to Wagner, US 10,831,898 B1 (hereinafter, “Wagner ‘898”) and Khazan et al., US 2005/0108562 A1 (hereinafter, “Khazan ‘562”) have been fully considered, and they are partially persuasive as to the previous grounds of rejection. Specifically, with respect to the independent claims, Applicant argues that:
Wagner ‘898’s Service Datastore 168 is pre-populated
Khazan ‘562 does not disclose “monitoring outgoing data traffic from the client computing system to identify an additional target external to the client computing system”, as amended.
In Response to Argument A
Applicant argues that Wagner ‘898’s service datastore 168 is a pre-populated reference used during static analysis, and that the phrase ‘may be stored’ in Wagner ‘898 is ‘not an active storing operation, but a description that the information is (optionally) stored in the datastore - as in, stored already’. Applicant further argues that Wagner ‘898’s system ‘would have no way of knowing what information should be passed on a service call that it does not recognize’, and that the datastore must therefore be fully populated in advance for Wagner ‘898 to function.
The Examiner respectfully disagrees. This argument is not persuasive.
Wagner ‘898, at Col.20 lines 17-25 discloses that ‘[t]he information within the service datastore 168 may be populated, for example, by the service analyzer 166, which may correspond to a computing device configured to determine service information for a given service. In one embodiment, the service analyzer 166 functions based on direct interaction with a service, such as by sending a request for information to the service and interpreting a response (e.g., XML data) including service information for the service”. Thus, Wagner ‘898 expressly discloses the population of the service datastore 168 as an affirmative operation performed by the system. The phrase ‘may be populated … by the service analyzer 166’ describes an operation performed by an element of the system upon the datastore. It cannot be interpreted, as Applicant proposes, as a pre-existing state. Furthermore, Wagner ‘898 discloses two specific methods (a direct method and an indirect method) by which the service analyzer 166 performs the population operation. For example, Wagner ‘898, at Col.20 lines 25-31 discloses ‘… by monitoring invocations of the service made during past task executions on the on-demand code execution system 110 and responses to such invocations.’
Fig.3 of Wagner ‘898 also supports that the population operation occurs after the analysis of the code under review. At interaction 4), the code analysis system 160 reviews the code to detect a service invocation (Wagner ‘898, Col.22 lines 20-24). At interaction 5), the code analysis system 160, via the service analyzer 166, transmits to the invoked auxiliary service 106 a query for service information (Wagner ‘898, Col.22 lines 35-38). At interaction 6), the auxiliary service 106 returns the requested service information (Wagner ‘898, Col.22 lines 44-46). Moreover, Wagner ‘898. at Col.22 lines 46-51, discloses ‘[i]n some instances, service information for the auxiliary service 106 may have been previously generated or retrieved by the code analysis system 160 (e.g., and stored in the service datastore 168). In such instances, interactions (5) and (6) may not be required’. Thus, Wagner ‘898 expressly distinguishes the case in which the service information was previously stored (where interactions 5) and 6) are omitted) from the case in which it was not (where interactions 5) and 6) are performed and the information is acquired and stored). Applicant’s argument that the datastore must be fully pre-populated for Wagner ‘898 to function is therefore not persuasive since Wagner ‘898 discloses what the system does when the information is not already present.
The statement that the datastore 168 ‘may be prepopulated with one or more code segments indicating a service invocation of a given service’ (Wagner ‘898, Col.22 lines 27-31) is associated with the code segments used to recognize that an invocation is present in the code being analyzed. This statement is not associated with the service information subsequently acquired about the invoked service. Wagner ‘898 discloses both that certain recognition data may be pre-populated and that service information is acquired and stored in response to detected invocations.
Accordingly, Wagner ‘898 discloses populating the datastore 168 with entries generated in response to service invocations identified during analysis of the code.
In Response to Argument B
Applicant argues that the calls monitored by Khazan ‘562 are internal calls made by a client system to its own libraries, and that even where Khazan ‘562 refers to “external” targets, it refers to code libraries that are part of the client system. Applicant has amended independent claims 1 and 9 to recite that the additional target identified from the outgoing data traffic is “external to the client computing system.”
This argument is persuasive as to the previous grounds of rejection.
With respect to the independent claims, Applicant's arguments and amendments have necessitated new ground(s) of rejection presented in this Office Action. A new ground of rejection has been asserted over Hayrynen et al., US 2014/0215620 A1 (hereinafter, “Hayrynen ‘620”). Hayrynen ‘620 is already of record in this application. Hayrynen ‘620 was previously applied to claims 5-8, 13, 15, and 19.
Hayrynen ‘620 discloses two scanning embodiments. A first static embodiment is directed to extracting the components of an application from its program code (Hayrynen ‘620, Fig.7), and a second dynamic embodiment is directed to monitoring the application’s network activity during execution (Hayrynen ‘620, Figs.5-6). The dynamic embodiment discloses monitoring outgoing data traffic to identify targets external to the system (Hayrynen ‘620, ¶33).
Hayrynen ‘620 further discloses monitoring ‘the contents of the network traffic transferred by the application’ (Hayrynen ‘620, ¶34); monitoring ‘the dependency of the application on external web services’ and storing ‘in the test result database the web services used by the application’ (Hayrynen ‘620, ¶38); and detecting that ‘the tested application attempts establishment of a connection to a host’, where ‘[t]he connection may be a network connection through the Internet … e.g., a transport control protocol/Internet protocol (TCP/IP) connection, universal datagram protocol (UDP) link, or a real-time protocol (RTP) connection’ (Hayrynen ‘620, ¶40).
The hosts, URLs, IP addresses, and external web services identified by Hayrynen ‘620’s dynamic test routines are targets situated outside the system executing the application and reached over a network. They are therefore targets “external” to the client computing system, as recited in amended claims 1 and 9.
See Claim Rejections – 35 USC §103 below for further details.
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.
Claim 16-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
As per claim 16:
Claim 16 has not been amended. Under step 2A, prong one of the Alice/Mayo revised framework, the claim recites “identifying a third party vendor for the client computing system based on a target entity of a service request from the client computing system”, “determining an executable code library of the client computing system”, “determining an operating system (OS) library of the client computing system”, and “generating the catalog to include the third party vendor, the executable code library, and the OS library”. These limitations, under their broadest reasonable interpretation, cover performance in the human mind but for the recitation of generic computer components. A person can determine from a service request which outside party is being contacted, can determine from a listing which libraries a program uses, and can write those items on a list. If a claim limitation, under its broadest reasonable interpretation, covers performance of the limitation in the mind but for the recitation of generic computer components, then it falls within the “Mental Processes” grouping of abstract ideas. MPEP § 2106.04(a)(2)(III). Accordingly, the claim recites an abstract idea.
Under step 2A, prong two, this judicial exception is not integrated into a practical application. The only additional elements recited are a “memory device storing instructions”, a “processor”, a “software security discovery system”, and a “client computing system”. Each is recited at a high level of generality, with no structure, configuration, or manner of operation specified beyond its ordinary function, and each is invoked merely as a tool to carry out the recited analysis. The memory device and processor are recited only as the generic medium on which instructions are stored and the generic hardware by which they are executed. Using a computer as a tool to perform an abstract idea does not integrate the exception into a practical application. MPEP § 2106.05(f).
Claim 16 recites no operation by which the information analyzed is obtained. It recites neither a scan of the client computing system for executable code nor any monitoring of the data traffic of that system, and it does not require that the recited catalog be generated on the basis of results obtained from the operations. The claim therefore does not recite the arrangement of discovery operations found to integrate the judicial exception in amended claims 1 and 9. The claim as a whole merely applies the concept of assembling a catalog of identified items using generic computer components, and the claims do not recite any improvement to the functioning of a computer or to any other technology or technical field. MPEP § 2106.05(a). Accordingly, the judicial exception is not integrated into a practical application.
Under step 2B, the claim does not include additional elements sufficient to amount to significantly more than the judicial exception. The determination of code libraries and operating system libraries used by a computing system, and the recording of identified components in a catalog, are well-understood, routine, and conventional activities in the relevant field, as demonstrated by the evidence in Re: Claim Rejections Under 35 U.S.C. §101 above. The remaining elements are generic computing components performing their ordinary functions, which amount to no more than mere instructions to apply the exception and cannot provide an inventive concept. MPEP § 2106.05(f). Considered as an ordered combination, the elements are arranged in the order in which their outputs are required by the analysis (the vendor and libraries are identified, then recorded) and no element is used in any unconventional manner by virtue of its position in that sequence. The combination adds nothing beyond the sum of the individual steps. Thus, the claim is not patent eligible.
As per claim 17:
The claim is rejected for at least the same reasons as claim 16. Additionally, the claim recites “identifying the service request within the executable code” and “decomposing the service request to identify the target entity of the service request”, which are acts of recognition and separation that may be performed in the human mind, and thus the claim recites a mental process. The claim further recites “performing a scan on a directory of the client computing system for executable code”, which is treated as an additional element. That step is insignificant extra-solution activity in the nature of data gathering, as it merely supplies the code upon which the recited analysis is performed and imposes no limit on how that analysis is carried out. MPEP § 2106.05(g); see Electric Power Group, 830 F.3d at 1354-55. Claim 17 recites no monitoring of outgoing data traffic and does not require that the catalog be generated on the basis of both a scan and monitored traffic, and therefore does not recite the arrangement found to integrate the judicial exception in amended claims 1 and 9. The scanning of a directory for executable code is further well-understood, routine, and conventional in the relevant field. Thus, the claim does not integrate the judicial exception into a practical application, does not amount to significantly more, and is not patent eligible.
As per claim 18:
The claim is rejected for at least the same reasons as claim 16. Additionally, the claim recites “determine the target entity from the outgoing data traffic”, which is an act of evaluation that may be performed in the human mind, and thus the claim recites a mental process. The claim further recites “monitoring outgoing data traffic from the client computing system to identify the service request”, which is treated as an additional element. The Examiner does not find that this step may itself be performed in the human mind. It is nevertheless insignificant extra-solution activity in the nature of data gathering, as it merely supplies the transmissions from which the target entity is then determined and imposes no limit on how that determination is carried out. MPEP § 2106.05(g); see Electric Power Group, 830 F.3d at 1354-55. Claim 18 recites no scan of a directory of the client computing system for executable code and does not require that the catalog be generated on the basis of both a scan and monitored traffic, and therefore does not recite the arrangement found to integrate the judicial exception in amended claims 1 and 9. The monitoring of outgoing data traffic to identify targets contacted by a system is further well-understood, routine, and conventional in the relevant field. Thus, the claim does not integrate the judicial exception into a practical application, does not amount to significantly more, and is not patent eligible.
As per claim 19:
The claim is rejected for at least the same reasons as claims 16 and 17. Additionally, the claim recites identifying the computer language from located text strings, identifying the executable code library from located text strings, and “identifying the service request within executable code of the client computing system based on the computer language and the executable code library”. Each is an act of recognition or evaluation that may be performed in the human mind; a regular expression anchor, as described in Applicant’s Specification, is a means of searching ‘for certain text strings at the beginning or ending of words or text elements’ (Specification, ¶17), and a person can look for a given text string at the beginning or end of a term appearing in a listing. Thus, the claim recites a mental process. The recited scanning of a directory and of the files is an additional element in the nature of data gathering and is insignificant extra-solution activity, as it merely supplies the text upon which the identification is performed. Claim 19 recites no monitoring of outgoing data traffic and therefore does not recite the arrangement found to integrate the judicial exception in amended claims 1 and 9. Thus, the claim does not integrate the judicial exception into a practical application, does not amount to significantly more, and is not patent eligible.
As per claim 20:
The claim is rejected for at least the same reasons as claim 16. Additionally, the claim recites “identifying the OS library based on a response to the command from the OS function”, which is an act of evaluation that may be performed in the human mind, and thus the claim recites a mental process. The Examiner does not find that “executing a command on the client computing system known to invoke an OS function” may be performed in the human mind; that limitation is treated as an additional element. It is nevertheless insignificant extra-solution activity in the nature of data gathering, as it serves only to elicit the response from which the library is then identified and imposes no limit on how that identification is carried out or on how the catalog is assembled. Claim 20 recites a single acquisition operation directed to the identification of an operating system library; it recites no monitoring of outgoing data traffic and does not require that the catalog be generated on the basis of results obtained from two discovery operations, and therefore does not recite the arrangement found to integrate the judicial exception in amended claims 1 and 9. The invocation of an operating system function by executing a command and the examination of the resulting response are further well-understood, routine, and conventional in the relevant field. Thus, the claim does not integrate the judicial exception into a practical application, does not amount to significantly more, and is not patent eligible.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
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.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claims 1, 9, and 15 are rejected under 35 U.S.C. 103 as being unpatentable over Wagner, US 10,831,898 B1 (hereinafter, “Wagner ‘898”), in view of Khazan et al., US 2005/0108562 A1 (hereinafter, “Khazan ‘562”), and further in view of Hayrynen et al., US 2014/0215620 A1 (hereinafter, “Hayrynen ‘620”).
As per claim 1: Wagner ‘898 discloses:
A method comprising: executing a software security discovery system (executing an on-demand code execution system 110 [Wagner ‘898, Col.3 line 57-Col.4 line 7, Col.6 lines 28-57, Col.23 lines 47-59; Fig.1, Fig.3]), including:
(receiving executable code from user device 102 [Wagner ‘898, Col.2 lines 1-34; Fig.3]);
identifying a service request within the executable code (identifying service invocation requests within the executable code [Wagner ‘898, Abstract, Col.22 lines 14-34, Col.23 lines 47-59; Figs.3-4]);
decomposing the service request into constituent parts, including a target entity of the service request externa; to the client computing system (decomposing the service invocation request in parts, such as input parameters, privilege, characteristics, security, information, network location, URI, and the specific target service that is being invoked, where the invoked service is an auxiliary service 106 that corresponds to a network-connected computing device separate from the user computing device 102 and reached by the user computing device 102 over the network 104, and where the auxiliary services 106 may be web services associated with third parties [Wagner ‘898, Col.3 line 33-Col.4 line 7, Col.6 line 57-Col.7 line 25, Col.22 lines 14-50; Fig.1]);
and generating a catalog (the code-analysis system 160 reviews executable code to detect service invocations and the resulting associations between detected code segments and corresponding services ‘may be stored … in the service datastore 168 for use by the code analysis system’ [Wagner ‘898, Col.23 lines 47-59]; furthermore, the information within the service datastore 168 ‘may be populated, for example, by the service analyzer 166’, either by direct interaction with a service or by monitoring invocations of the service made during past task executions and analyzing those invocations and responses [Wagner ‘898, Col.20 lines 17-31], indicating that the datastore contains information produced through analysis of the code under review)
of (a service datastore 168 is generated and maintained by the code analysis system 160, where the service datastore 168 comprises information associated with auxiliary services 108, and where the auxiliary services 108 may be third party services that correspond to the invoked services by the user device 102 identified in the executable code; for example, Col.3 line 60 discloses ‘a datastore of information regarding services … may include … information mapping the inputs into an output (e.g., as a write to a particular network location, another service invocation, etc.) …’, and Col.23 line 54 discloses ‘… each service may be associated with one or more function calls, URIs, or other identifiers that, when detected within code of the task, indicates an invocation of the service. These associations may be stored, for example, in the service information datastore 168 …’ [Wagner ‘898, Col.3 line 57-Col.4 line 7, Col.6 line 58-Col.7 line 25, Col.20 lines 17-31, Col.22 lines 14-50, Col.23 lines 47-59; Fig.3]).
As stated above, Wagner ‘898 does not explicitly disclose the limitation “… performing a scan on a directory of a client computing system for executable code … monitoring outgoing data traffic from the client computing system to identify an additional target external to the client computing system; and generating a catalog of software components of the client computing system … based on the scan, the target entity, and the additional target.”
Khazan ‘562, however, discloses:
… performing a scan on a directory of a client computing system for executable code (a method for detection of malicious code by verifying that an application executes in accordance with calls to a predetermined set of targets, where a detection tool may be used to scan a file system for different executable code that may be located in particular directories within the system [Khazan ‘562, ¶¶Abstract, 110-111, 113]) …
…
and generating a catalog of software components of the client computing system … based on the scan, the target entity, (a detection system that scans a file system of a client computing system to locate executable files and libraries for analysis, thereby identifying the software components of the client system. Khazan ’562 teaches that a detection tool may scan directories within a client system to locate different executable code for security evaluation [Khazan ’562, ¶¶110-113], where the executables and libraries identified in this scan correspond to the “software components of the client computing system”).
Wagner ‘898 and Khazan ‘562 are analogous art because they are from the same field of endeavor, namely that of identifying potentially vulnerable portions of code associated with external service calls. Prior to the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art, having the teachings of Wagner ‘898 and Khazan ‘562 before them, to modify the method in Wagner ‘898 to include the teachings of Khazan ‘562, namely to modify the on-demand code execution system 110 of Wagner ‘898 to include the scanning functionality of Khazan ‘562 such that Wagner ‘898’s code-analysis system obtains executable code by scanning the client computing system for software components located in particular directories, and generates a catalog identifying those components together with their corresponding target entities and third-party vendors, based on both the scan and the target entities. A motivation for doing so would be to improve the thoroughness and automation of code acquisition and analysis, as Khazan ‘562 expressly teaches scanning directories to ensure complete discovery of executable code for evaluation (see Khazan ‘562, ¶¶111, 113).
As stated above, Wagner ‘898 in view of Khazan ‘562 does not explicitly disclose the limitation “… monitoring outgoing data traffic from the client computing system to identify an additional target external to the client computing system; and generating a catalog … based on … the target entity, and the additional target.”
Hayrynen ‘620, however, discloses:
… monitoring outgoing data traffic from the client computing system to identify an additional target external to the client computing system (a test routine that monitors the network activity of an application of the system, where the test routine monitors the URLs accessed by the application and stores the accessed URLs in a test result database, and where the same or a different test routine monitors the network and/or application ports opened by the application and stores the used ports and/or IP addresses in the test result database [Hayrynen ‘620, ¶33]; a test routine monitoring the contents of the network traffic transferred by the application [Hayrynen ‘620, ¶34]; a test routine monitoring the dependency of the application on external web services and storing in the test result database the web services used by the application [Hayrynen ‘620, ¶38]; a test routine detecting that the application attempts establishment of a connection to a host, where the connection may be a network connection through the Internet, such as a transport control protocol/Internet protocol (TCP/IP) connection [Hayrynen ‘620, ¶40; Fig.6]);
and generating a catalog … based on … the target entity, and the additional target (upon acquiring the application, a component extraction tool is launched to determine what components the application comprises, where the searched components comprise libraries used by the application, and where, upon detecting a string matching a reference string, the component extraction tool stores in a test result database an information element indicating that the application comprises the detected library [Hayrynen ‘620, ¶43; Fig.7]; the library database stores in association with each library an author of the library and a reputation status of the author, and network addresses used by the library [Hayrynen ‘620, ¶47]; a dynamic test engine 14 and a static test engine 16 update the same test result database 26 as they test the application, where the test engines store in the test result database 26 information describing the operation and the components of the application, including network activity and accessed sites [Hayrynen ‘620, ¶52]).
Wagner ‘898 (modified by Khazan ‘562) and Hayrynen ‘620 are analogous art because they are from the same field of endeavor, namely that of identifying potentially vulnerable portions of code associated with external service calls. Prior to the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art, having the teachings of Wagner ‘898 (modified by Khazan ‘562) and Hayrynen ‘620 before them, to modify the method in Wagner ‘898 (modified by Khazan ‘562) to include the teachings of Hayrynen ‘620, namely to modify the code analysis system 160 of Wagner ‘898 such that, in addition to detecting service invocations within the scanned executable code, the system further monitors the outgoing network activity of the client computing system in order to identify additional hosts, URLs, ports, and external web services contacted during operation, as disclosed in Hayrynen ‘620; and further to modify the datastore of Wagner ‘898 such that the components determined from the scan, the authors associated with those components, and the additional targets identified from the monitored network activity are recorded together in a single result database corresponding to the client computing system, as disclosed in Hayrynen ‘620. A motivation for doing so would be to identify targets and components that are not apparent from a static scan of the code alone, and to provide the client device with an up-to-date record of the components and external services upon which the client computing system depends (see Hayrynen ‘620, ¶¶27, 33, 38, 52).
As per claim 9: Claim 9 defines a system that recites substantially similar subject matter as the method of claim 1. Specifically, claim 9 is directed to a system comprising a processor configured to implement the software security discovery process of claim 1. Thus, the rejection of claim 1 is equally applicable to claim 9.
As per claim 15: Wagner ‘898 in view of Khazan ‘562, and further in view of Hayrynen ‘620 discloses all limitations of claim 9, as stated above, from which claim 15 is dependent upon. Furthermore, Wagner ‘898 discloses:
further configured to: (detecting changes in the system, such as changes in code characteristics [Wagner ‘898, Col.23 lines 19-33, Col.29 lines 32-64]); and update the catalog (updating information in the datastore based on information provided by the auxiliary service [Wagner ’898, Col.20 lines 17-31, Col.22 lines 14-50, Col.23 lines 47-59)
As stated above, Wagner ‘898 does not explicitly disclose the limitation “… perform a periodic scan to identify a change … update the in real time based on the change.”
Hayrynen ‘620, however, discloses:
… perform a periodic scan to identify a change … update the … in real time based on the change (after a given time has elapsed after the provision of the test report, the server computer may detect a change in the testing configuration of the application, where the test report is updated by taking into account the changes in the testing configuration, and where the up-to-date report is provided to the client device [Hayrynen ‘620, ¶¶26-29, 48]).
Wagner ‘898 (modified by Khazan ‘562) and Hayrynen ‘620 are analogous art because they are from the same field of endeavor, namely that of identifying potentially vulnerable portions of code. Prior to the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art, having the teachings of Wagner ‘898 (modified by Khazan ‘562) and Hayrynen ‘620 before them, to modify the method in Wagner ‘898 (modified by Khazan ‘562) to include the teachings of Hayrynen ‘620, namely to modify the process in which change is detected in Wagner ‘898, where the system is scanned after a given time has elapsed to detect changes, as disclosed in Hayrynen ‘620, and where the up-to-date changes are stored in the datastore of Wagner ‘898. A motivation for doing so would be to ensure that an end user device is able to receive the most up-to-date information based on changes to the system such that vulnerabilities associated with said changes may be avoided (see Hayrynen ‘620, ¶¶26-27).
Claims 3 and 11 are rejected under 35 U.S.C. 103 as being unpatentable over Wagner ‘898, in view of Khazan ‘562, and further in view of Hayrynen ‘620, and further in view of Rioux et al., US 2022/0075876 A1 (hereinafter, “Rioux ‘876”).
As per claim 3: Wagner ‘898 in view of Khazan ‘562, and further in view of Hayrynen ‘620, discloses all limitations of claims 1, as stated above, from which claim 3 is dependent upon. Furthermore, Wagner ‘898 discloses:
further comprising: identifying a computer language corresponding to the executable code (identifying the computer language of the executable based on the metadata included submitted task [Wagner ‘898, Col.10 line 32-Col.11 line 3]); and identifying the service request within the executable code based on the (identifying the service invocation request within the executable code based on recognizing a specific code segment within the executable code [Wagner ‘898, Col.22 lines 14-34, Col.23 lines 47-59]).
As stated above, Wagner ‘898 does not explicitly disclose the limitation “… identifying the service request … based on the computer language.”
Rioux ‘876, however, discloses:
… identifying the service request … based on the computer language (an agent determines the language associated with a runtime engine and its API. The agent maintains a listing of language and API function calls for which the agent is to monitor. The agent can determine the associations of events (i.e., target function invocations) for which to monitor with the corresponding executable code. The agent then monitors for the API function calls. When the agent detects an event during execution of the executable code based on invocations of the runtime engine API, the agent can monitor and analyze the executable code [Rioux ‘876, ¶¶11-12, 29, 31-32]).
Wagner ‘898 (modified by Khazan ‘562 and Hayrynen ‘620) and Rioux ‘876 are analogous art because they are from the same field of endeavor, namely that of identifying potentially vulnerable portions of code associated with external service calls. Prior to the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art, having the teachings of Wagner ‘898 (modified by Khazan ‘562 and Hayrynen ‘620) and Rioux ‘876 before them, to modify the method in Wagner ‘898 (modified by Khazan ‘562 and Hayrynen ‘620) to include the teachings of Rioux ‘876, namely to modify the service request detection process of Wagner ‘898 such that it not only uses a specific code segment to recognize service requests within the executable code, but also uses the specific computer language of the executable code obtained from the metadata, as disclosed in Rioux ‘876. A motivation for doing so would be to reduce the overhead of analyzing and monitoring executable code for an application by implementing a language-agnostic universal agent that can detect the programming language used (see Rioux ‘876, ¶¶11-12).
As per claim 11: Claim 11 defines a system that recites substantially similar subject matter as the method claim 3. Specifically, claim 11 is directed to a system comprising a processor configured to implement the software security discovery method of claim 3. Thus, the rejection of claim 3 is equally applicable to claim 11.
Claims 4 and 12 are rejected under 35 U.S.C. 103 as being unpatentable over Wagner ‘898, in view of Khazan ‘562, and further in view of Hayrynen ‘620, and further in view of Rioux ‘876, and further in view of Zhou et al., US 2022/0366047 A1 (hereinafter, “Zhou ‘047”).
As per claim 4: Wagner ‘898 in view of Khazan ‘562, and further in view of Hayrynen ‘620, and further in view of Rioux ‘876, discloses all limitations of claims 1 and 3, as stated above, from which claim 4 is dependent upon. Furthermore, Wagner ‘898 discloses:
further comprising: determining an executable code library at the client computing system based on the scan (the on-demand code execution system 110 determining the library of the executable code based on the received task info [Wagner ‘898, Col.10 line 31-Col.11 line 3]); and including the (the datastore comprises information regarding the services and executable code, where the information may include security information for the service, execution capacity for the service, code characteristics of the service, expected inputs into an invocation of the service, and information mapping the inputs into an output (e.g., as a write to a particular network location, another service invocation, etc.) [Wagner ‘898, Col.3 line 57-Col.4 line 7]).
As stated above, Wagner ‘898 does not explicitly disclose the limitation “… and including the executable code library in the catalog.”
Zhou ‘047, however, discloses:
… and including the executable code library in the catalog (a method of analyzing object code, where the object code is scanned to determine libraries used by the object code, and where a list, within a feature set, is compiled with the identified libraries [Zhou ‘047, ¶¶42, 63-67, Claim 6]).
Wagner ‘898 (modified by Khazan ‘562, Hayrynen ‘620, and Rioux ‘876) and Zhou ‘047 are analogous art because they are from the same field of endeavor, namely that of identifying potentially vulnerable portions of code. Prior to the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art, having the teachings of Wagner ‘898 (modified by Khazan ‘562, Hayrynen ‘620, and Rioux ‘876) and Zhou ‘047 before them, to modify the method in Wagner ‘898 (modified by Khazan ‘562, Hayrynen ‘620, and Rioux ‘876) to include the teachings of Zhou ‘047, namely to modify the datastore of Wagner ‘898 such that it also stores libraries associated with the corresponding executable code, as disclosed in Zhou ‘047. A motivation for doing so would be to increase the efficiency of detecting vulnerable code by using a collection of associated data, such as libraries, in analyzing the object code (see Zhou ‘047, ¶¶7, 14, 63-64).
As per claim 12: Claim 12 defines a system that recites substantially similar subject matter as the method claim 4. Specifically, claim 12 is directed to a system comprising a processor configured to implement the software security discovery method of claim 4. Thus, the rejection of claim 4 is equally applicable to claim 12.
Claim 5 is rejected under 35 U.S.C. 103 as being unpatentable over Wagner ‘898, in view of Khazan ‘562, and further in view of Hayrynen ‘620, and further in view of Rioux ‘876, and further in view of Zhou ‘047, and further in view of Khairetdinov et al., US 9,104,878 A1 (hereinafter, “Khairetdinov ‘878”).
As per claim 5: Wagner ‘898 in view of Khazan ‘562, and further in view of Hayrynen ‘620, and further in view of Rioux ‘876, and further in view of Zhou ‘047 discloses all limitations of claims 1 and 3-4, as stated above, from which claim 5 is dependent upon. Furthermore, Wagner ‘898 discloses:
further comprising: identifying the computer language and the executable code library (identifying the computer language and library of the executable code based on the metadata included submitted task [Wagner ‘898, Col.10 line 32-Col.11 line 3])
As stated above, Wagner ‘898 does not explicitly disclose the limitation “… identifying the computer language and the executable code library based on performing a search for regular expression anchors.”
Khairetdinov ‘878, however, discloses:
… identifying the computer language and based on performing a search for regular expression anchors (a source code scanner in which file accessors are used to scan a file system and obtain files that match ‘include’ and do not match ‘exclude’ regular expressions specified for a base directory, and in which the programming language for application of a particular pattern is detected by file extensions, where registered extensions are maintained for each of a plurality of programming languages [Khairetdinov ‘878, Col.4 line 61-Col.5 line 5, Col.5 lines 35-50; Fig.4]; and where the pattern definition language of the scanner permits a stored token text to be checked using a regular expression that is constrained at its beginning and at its ending, for example a regular expression that ‘starts with R, ends with t and has one or more symbols in between’ [Khairetdinov ‘878, Col.7 lines 41-45, Col.8 lines 44-52]) …
Examiner’s Note: Applicant’s Specification describes “regular expression anchors” as permitting ‘for searching for certain text strings at the beginning or ending of words or text elements’ (Specification, ¶17). Khairetdinov ‘878’s disclosure of a regular expression that ‘starts with R, ends with t’ is a search for a text string constrained at its beginning and at its ending, and therefore reads on a “regular expression anchor” as that term is used in the present application.
Wagner ‘898 (modified by Khazan ‘562, Hayrynen ‘620, Rioux ‘876, and Zhou ‘047) and Khairetdinov ‘878 are analogous art because they are from the same field of endeavor, namely that of identifying potentially vulnerable portions of code. Prior to the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art, having the teachings of Wagner ‘898 (modified by Khazan ‘562, Hayrynen ‘620, Rioux ‘876, and Zhou ‘047) and Khairetdinov ‘878 before them, to modify the method in Wagner ‘898 (modified by Khazan ‘562, Hayrynen ‘620, Rioux ‘876, and Zhou ‘047) to include the teachings of Khairetdinov ‘878, namely to modify the process in which the computer language type is determined in Wagner ‘898, where the language type is determined via an automatic scan of the file system using anchored regular expressions and file extensions, as disclosed in Khairetdinov ‘878, instead of being provided by the user device. A motivation for doing so would be to allow the source code scanner to be automatically adjusted to work with any computing language (see Khairetdinov ‘878, Col.1 lines 40-64).
As stated above, Wagner ‘898 in view of Khairetdinov ‘878 does not explicitly disclose the limitation: “… identifying the computer language and the executable code library based on performing a search for regular expression anchors.”
Hayrynen ‘620, however, discloses:
… identifying the computer language and the executable code library based on performing a search for regular expression anchors (a library database stores a reference list of libraries the component extraction tool is configured to search, where the library database may comprise for each library reference strings that distinguish the library from other libraries; the component extraction tool may then scan the computer program code of the application for these reference strings and, upon detecting a string matching with a reference string, the component extraction tool may store in a test result database an information element indicating that the application comprises the detected library [Hayrynen ‘620, ¶¶43, 46; Fig.7]).
Wagner ‘898 (modified by Khazan ‘562, Rioux ‘876, Zhou ‘047, and Khairetdinov ‘878) and Hayrynen ‘620 are analogous art because they are from the same field of endeavor, namely that of scanning computer program code against a stored database of patterns to identify components and security vulnerabilities within the code. Prior to the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art, having the teachings of Wagner ‘898 (modified by Khazan ‘562, Rioux ‘876, Zhou ‘047, and Khairetdinov ‘878) and Hayrynen ‘620 before them, to modify the method in Wagner ‘898 (modified by Khazan ‘562, Rioux ‘876, Zhou ‘047, and Khairetdinov ‘878) to include the teachings of Hayrynen ‘620, namely to modify the process in which the libraries for the executable code are determined in Wagner ‘898, where the libraries are determined by scanning the computer program code for stored patterns that distinguish each of a plurality of known libraries, as disclosed in Hayrynen ‘620, instead of being provided by the user device; and further, such that the stored patterns are expressed and matched as anchored regular expressions, as disclosed in Khairetdinov ‘878. Khairetdinov ‘878 itself establishes that literal token-text matching and anchored regular-expression matching are alternative, interchangeable mechanisms for matching a scanned file against a stored pattern database, both implemented within the same scanner core (see Khairetdinov ‘878, Col.7 lines 41-45, Col.8 lines 44-52). A motivation for doing so would be to increase the security of the device by detecting and analyzing all aspects, including libraries, associated with executable code, and further to reduce the size and maintenance burden of the library database (see Hayrynen ‘620, ¶¶2, 43, 46-47).
Claims 14, 16-18, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Wagner ‘898, in view of Khazan ‘562, further in view of Hayrynen ‘620, and further in view of Zhou ‘047.
As per claim 14: Wagner ‘898 in view of Khazan ‘562, and further in view of Hayrynen ‘620, discloses all limitations of claim 9, as stated above, from which claim 14 is dependent upon. Wagner ‘898 does not explicitly disclose the limitations of claim 14. Khazan ‘562, however, discloses:
further configured to: identify an operating system (OS) library of the client computing system, including: execute a command on the client computing system known to invoke an OS function (identifying an operating system library, such as a dynamic link library (DLL) by invoking an operating system routine [Khazan ‘562, ¶¶41, 73-74, 77, 80]); identify the OS library based on a response to the command from the OS function; and include the OS library (identifying the corresponding DLL based on the response to the operating system routine [Khazan ‘562, ¶¶61-62, 73-74, 90])
Wagner ‘898 (modified by Hayrynen ‘620) and Khazan ‘562 are analogous art because they are from the same field of endeavor, namely that of identifying potentially vulnerable portions of code associated with external service calls. Prior to the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art, having the teachings of Wagner ‘898 (modified by Hayrynen ‘620) and Khazan ‘562 before them, to modify the method in Wagner ‘898 (modified by Hayrynen ‘620) to include the teachings of Khazan ‘562, namely to modify the library acquisition process of Wagner ‘898, in particular the OS library acquisition process, such that the library is identified by invoking an operating system routine and analyzing the response, as disclosed in Khazan ‘562, instead of having the library being provided by the user device. A motivation for doing so would be to increase the security of a system by analyzing all aspects associated with an executable code, including OS libraries such as DLLs (see Khazan ‘562, ¶¶61-62, 64).
As stated above, Wagner ‘898 in view of Khazan ‘562 does not explicitly disclose the limitation “… include the OS library in the catalog.”
Zhou ‘047, however, discloses:
… include the OS library in the catalog (a method of analyzing object code, where the object code is scanned to determine libraries used by the object code, and where a list, within a feature set, is compiled with the identified libraries [Zhou ‘047, ¶¶42, 63-67, Claim 6]).
Wagner ‘898 (modified by Khazan ‘562 and Hayrynen ‘620) and Zhou ‘047 are analogous art because they are from the same field of endeavor, namely that of identifying potentially vulnerable portions of code. For the reasons stated in claim 4, prior to the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art, having the teachings of Wagner ‘898 (modified by Khazan ‘562 and Hayrynen ‘620) and Zhou ‘047 before them, to modify the method in Wagner ‘898 (modified by Khazan ‘562 and Hayrynen ‘620) to include the teachings of Zhou ‘047.
As per claim 16: Wagner ‘898 discloses:
A memory device storing instructions that, when executed, cause a processor to perform a method (all of the methods and processes described above may be embodied in, and fully automated via, software code modules executed by one or more computers or processors, where the code modules may be stored in any type of non-transitory computer-readable medium or other computer storage device [Wagner ‘898, Col.32 lines 21-27]) comprising:
executing a software security discovery system to generate a catalog of (a service datastore 168 is generated and maintained by the code analysis system 160, where the service datastore 168 comprises information associated with auxiliary services 108, and where the auxiliary services 108 may be third party services that correspond to the invoked services by the user device 102 identified in the executable code [Wagner ‘898, Col.3 line 57-Col.4 line 7, Col.6 line 58-Col.7 line 25, Col.20 lines 17-31, Col.22 lines 14-50, Col.23 lines 47-59; Fig.1, Fig.3]), including:
identifying a third party vendor for the client computing system based on a target entity of a service request from the client computing system (decomposing the service invocation request in parts, such as input parameters, privilege, characteristics, security, information, network location, URI, and the specific target service that is being invoked, where the invoked auxiliary services 106 may be web services associated with third parties [Wagner ‘898, Col.3 line 33-Col.4 line 7, Col.6 line 57-Col.7 line 25, Col.22 lines 14-50]);
determining an executable code library of the client computing system (the on-demand code execution system 110 determining the library of the executable code based on the received task info [Wagner ‘898, Col.10 line 31-Col.11 line 3]);
generating the catalog (the code-analysis system 160 reviews executable code to detect service invocations and the resulting associations between detected code segments and corresponding services ‘may be stored … in the service datastore 168 for use by the code analysis system’ [Wagner ‘898, Col.23 lines 47-59]; furthermore, the information within the service datastore 168 ‘may be populated, for example, by the service analyzer 166’ [Wagner ‘898, Col.20 lines 17-25], indicating that the datastore contains information produced through analysis of the code under review)
to include the third party vendor (the service datastore 168 comprises information associated with auxiliary services 108, where the auxiliary services 108 may be third party services that correspond to the invoked services by the user device 102 identified in the executable code [Wagner ‘898, Col.3 line 57-Col.4 line 7, Col.6 line 58-Col.7 line 25, Col.22 lines 14-50, Col.23 lines 47-59; Fig.3]),
As stated above, Wagner ‘898 does not explicitly disclose the limitation: “…executing a software security discovery system to generate a catalog of components of a client computing system … determining an operating system (OS) library of the client computing system; and … generating the catalog to include the third party vendor, the executable code library, and the OS library.”
Khazan ‘562, however, discloses:
… executing a software security discovery system to generate a catalog of … determining an operating system (OS) library of the client computing system; and … generating the catalog to include the third party vendor,,and the OS library (identifying an operating system library, such as a dynamic link library (DLL) by invoking an operating system routine [Khazan ‘562, ¶¶41, 73-74, 77, 80]; identifying the corresponding DLL based on the response to the operating system routine [Khazan ‘562, ¶¶61-62, 73-74, 90]).
Wagner ‘898 and Khazan ‘562 are analogous art because they are from the same field of endeavor, namely that of identifying potentially vulnerable portions of code associated with external service calls. For the reasons stated in claim 14, prior to the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art, having the teachings of Wagner ‘898 and Khazan ‘562 before them, to modify the method in Wagner ’898 to include the teachings of Khazan ‘562.
As stated above, Wagner ‘898 in view of Khazan ‘562 does not explicitly disclose the limitations: “… executing a software security discovery system to generate a catalog of components of a client computing system … generating the catalog to include the third party vendor, the executable code library, and the OS library.
Hayrynen ‘620, however, discloses:
… executing a software security discovery system to generate a catalog of components of a client computing system … generating the catalog to include the third party vendor, , and the OS library (a component extraction tool is launched to determine what components the application comprises, where the searched components comprise libraries used by the application, and where, upon detecting a string matching a reference string, the component extraction tool stores in a test result database an information element indicating that the application comprises the detected library [Hayrynen ‘620, ¶43; Fig.7]; the test result database is maintained per application and per user, where a subscription database stores associations between the applications and the users that have requested to test their applications, and where the resulting test report is communicated to the requesting client device [Hayrynen ‘620, ¶¶26, 52]) …
Wagner ‘898 (modified by Khazan ‘562) and Hayrynen ‘620 are analogous art because they are from the same field of endeavor, namely that of identifying potentially vulnerable portions of code associated with external service calls. Prior to the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art, having the teachings of Wagner ‘898 (modified by Khazan ‘562) and Hayrynen ‘620 before them, to modify the method in Wagner ’898 (modified by Khazan ‘562) to include the teachings of Hayrynen ‘620, namely to modify the datastore of Wagner ‘898 such that the components determined for a given client computing system are recorded in a result record maintained in association with that client, and such that the resulting record is provided to the client device, as disclosed in Hayrynen ‘620. A motivation for doing so would be to provide the client device with a record of the components upon which its own application depends, such that the client may act upon the identified components and their associated suspicious features (see Hayrynen ‘620, ¶¶26-27, 43).
As stated above, Wagner ‘898 in view of Khazan ‘562, and further in view of Hayrynen ‘620 does not explicitly disclose the limitation “… generating the catalog to include the third party vendor, the executable code library, and the OS library.”
Zhou ‘047, however, discloses:
… generating the catalog to include the third party vendor, the executable code library, and the OS library (a method of analyzing object code, where the object code is scanned to determine libraries used by the object code, and where a list, within a feature set, is compiled with the identified libraries [Zhou ‘047, ¶¶42, 63-67, Claim 6]).
Wagner ‘898 (modified by Khazan ‘562 and Hayrynen ‘620) and Zhou ‘047 are analogous art because they are from the same field of endeavor, namely that of identifying potentially vulnerable portions of code. For the reasons stated in claim 4, prior to the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art, having the teachings of Wagner ‘898 (modified by Khazan ‘562 and Hayrynen ‘620) and Zhou ‘047 before them, to modify the method in Wagner ‘898 (modified by Khazan ‘562 and Hayrynen ‘620) to include the teachings of Zhou ‘047.
As per claim 17: Wagner ‘898 in view of Khazan ‘562, further in view of Hayrynen ’620, and further in view of Zhou ‘047 discloses all limitations of claim 16, as stated above, from which claim 17 is dependent upon. Furthermore, Wagner ‘898 discloses:
further comprising: (receiving executable code from user device 102 [Wagner ‘898, Col.2 lines 1-34; Fig.3]); identifying the service request within the executable code (identifying service invocation requests within the executable code [Wagner ‘898, Abstract, Col.22 lines 14-34, Col.23 lines 47-59; Figs.3-4]); and decomposing the service request to identify the target entity of the service request (decomposing the service invocation request in parts, such as input parameters, privilege, characteristics, security, information, network location, URI, and the specific target service that is being invoked [Wagner ‘898, Col.3 line 33-Col.4 line 7, Col.22 lines 14-50]).
As stated above, Wagner ‘898 does not explicitly disclose the limitation “… performing a scan on a directory of a client computing system for executable code …”
Khazan ‘562, however, discloses:
… performing a scan on a directory of a client computing system for executable code (a method for detection of malicious code by verifying that an application executes in accordance with calls to a predetermined set of targets, where a detection tool may be used to scan a file system for different executable code that may be located in particular directories within the system [Khazan ‘562, ¶¶Abstract, 110-111, 113]) …
Wagner ‘898 (modified by Hayrynen ‘620 and Zhou ‘047) and Khazan ‘562 are analogous art because they are from the same field of endeavor, namely that of identifying potentially vulnerable portions of code associated with external service calls. For the reasons stated in claim 1, prior to the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art, having the teachings of Wagner ‘898 (modified by Hayrynen ‘620 and Zhou ‘047) and Khazan ‘562 before them, to modify the method in Wagner ‘898 (modified by Hayrynen ‘620 and Zhou ‘047) to include the teachings of Khazan ‘562.
As per claim 18: Wagner ‘898 in view of Khazan ‘562, further in view of Hayrynen ‘620, and further in view of Zhou ‘047 discloses all limitations of claim 16, as stated above, from which claim 18 is dependent upon. Furthermore, Wagner ‘898 discloses:
further comprising: (analyzing code to detect service invocations to additional services, which may include additional instances of the task, other tasks, or auxiliary services 106 [Wagner ‘898, Col.19 line 55-Col.20 line 41, Col.22 lines 1-13]); and determine the target entity from the (a service datastore 168 is generated and maintained by the code analysis system 160, where the service datastore 168 comprises information associated with auxiliary services 108, and where the auxiliary services 108 may be third party services that correspond to the additional invoked services by the user device 102 identified in the executable code [Wagner ‘898, Col.3 line 57-Col.4 line 7, Col.6 line 58-Col.7 line 25, Col.20 lines 17-31, Col.22 lines 14-50, Col.23 lines 47-59; Fig.3])
As stated above, Wagner ‘898 does not explicitly disclose the limitation “monitoring outgoing data traffic from the client computing system to identify the service request; and determine the target entity from the outgoing data traffic.”
Hayrynen ‘620, however, discloses:
… monitoring outgoing data traffic from the client computing system to identify the service request; and determine the target entity from the outgoing data traffic (a test routine that monitors the network activity of an application of the system, where the test routine monitors the URLs accessed by the application and stores the accessed URLs in a test result database, and where the same or a different test routine monitors the network and/or application ports opened by the application and stores the used ports and/or IP addresses in the test result database [Hayrynen ‘620, ¶33]; a test routine monitoring the contents of the network traffic transferred by the application [Hayrynen ‘620, ¶34]; a test routine monitoring the dependency of the application on external web services and storing in the test result database the web services used by the application [Hayrynen ‘620, ¶38]) …
Wagner ‘898 (modified by Khazan ‘562 and Zhou ‘047) and Hayrynen ‘620 are analogous art because they are from the same field of endeavor, namely that of identifying potentially vulnerable portions of code associated with external service calls. For the reasons stated in claim 1, prior to the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art, having the teachings of Wagner ‘898 (modified by Khazan ‘562 and Zhou ‘047) and Hayrynen ‘620 before them, to modify the method in Wagner ‘898 (modified by Khazan ‘562 and Zhou ‘047) to include the teachings of Hayrynen ‘620.
As per claim 20: Wagner ‘898 in view of Khazan ‘562, further in view of Hayrynen ‘620, and further in view of Zhou ‘047 discloses all limitations of claim 16, as stated above, from which claim 20 is dependent upon. Wagner ‘898 does not explicitly disclose the limitations of claim 20. Khazan ‘562, however, discloses:
further comprising: identifying the OS library of the client computing system, including: executing a command on the client computing system known to invoke an OS function (identifying an operating system library, such as a dynamic link library (DLL) by invoking an operating system routine [Khazan ‘562, ¶¶41, 73-74, 77, 80]); and identifying the OS library based on a response to the command from the OS function (identifying the corresponding DLL based on the response to the operating system routine [Khazan ‘562, ¶¶61-62, 73-74, 90]).
Wagner ‘898 (modified by Hayrynen ‘620 and Zhou ‘047) and Khazan ‘562 are analogous art because they are from the same field of endeavor, namely that of identifying potentially vulnerable portions of code associated with external service calls. For the reasons stated in claim 14, prior to the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art, having the teachings of Wagner ‘898 (modified by Hayrynen ‘620 and Zhou ‘047) and Khazan ‘562 before them, to modify the method in Wagner ‘898 (modified by Hayrynen ‘620 and Zhou ‘047) to include the teachings of Khazan ‘562.
Allowable Subject Matter
Claims 6-8 and 13 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.
Claim 19 is dependent upon a rejected base claim but may be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims, as well as rewritten to overcome the rejection(s) under 35 U.S.C. 101 set forth in this Office action. See Claim Rejections - 35 USC § 101 above.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
Shukla, US 20210099483 A1: preventing attacks on a web application server by monitoring and validating the API calls executed by the dynamic language code of web application is provided. Scanning the computer system for web applications and the location of dynamic language code or script files used by the web applications.
Youngberg, US 10534912 B1: A system for performing code security scan. Storing a plurality of identifiers each identifying a software security analysis tool of one of several categories, including SAST, DAST and OSA tools. Receive identifiers to identify software security analysis tools for execution on the identified code.
McCorkendale et al., US 9230099 B1: 1) identifying executable code that is to be analyzed to determine whether the executable code is capable of leaking sensitive data, 2) performing a static analysis of the executable code to identify one or more objects which the executable code may use to transfer sensitive data.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ALAN L KONG whose telephone number is (571)272-2646. The examiner can normally be reached Monday-Friday 9:00am-5:30pm EST.
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, JUNG (JAY) KIM can be reached on (571)272-3804. 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.
/ALAN L KONG/Examiner, Art Unit 2494
/KAVEH ABRISHAMKAR/Primary Examiner, Art Unit 2494
Prosecution Insights