CTNF 18/648,000 CTNF 90685 DETAILED ACTION Notice of Pre-AIA or AIA Status 07-03-aia AIA 15-10-aia The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA. 07-06 AIA 15-10-15 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. Information Disclosure Statement The information disclosure statement (IDS) submitted on 08/25/2025 is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner. Claim Rejections - 35 USC § 101 07-04-01 AIA 07-04 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 1-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. Applying the subject matter eligibility test, as outlined in MPEP 2106: Step 1: Statutory Category The claims fall within a statutory category. Claims 1-10 and 17-20 are considered “machines” based claims and claims 11-16 are considered “processes”. Both machines and processes are members of the statutory categories. Thus, the analysis moves towards step 2A, prong one of the subject matter eligibility test. Step 2A, Prong One: Judicial Exception The claims recite a judicial exception, specifically an abstract idea. For example, claims 1, 11 and 17 recite determine a first threat risk for an asset, wherein the asset defines a property of an item; compare the first threat risk with an acceptable level of risk; in response to determining the first threat risk exceeds the acceptable level of risk, determine a modification of the asset to reduce the first threat risk to a second threat risk; and recommend the modification of the asset to reduce the first threat risk to the second threat risk at the item. Such processes are akin to a mental process or methods of organizing human activity, which have been recognized as abstract ideas. Thus, the analysis moves towards step 2A, prong two. Step 2A, Prong Two: Integration into a Practical Application The claims do not integrate the abstract idea into a practical application. The additional elements, such as a processor, memory do not impose any meaningful limits of on the abstract idea. Applying generic computer techniques to a specific field without improving the underlying technology does not constitute a practical application. Thus, the analysis moves towards step 2B. Step 2B: Inventive concept Finally, the claims do not recite an inventive concept that transforms the abstract idea into a patent-eligible application. The use of computer components in a generic manner, without specifying a novel algorithm or unique methodologies, fails to add significantly more to the abstract idea. Mere instructions to apply an exception using a generic computer component cannot provide an inventive concept. Claims 2-10, 12-16 and 18-20 merely add details to the generic off-shelf components that were already disclosed in claims 1, 11 and 17, but do not alter the outcome of the analysis above. Claim Rejections - 35 USC § 103 07-20-aia AIA 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 of this title, 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. 07-23-aia AIA The factual inquiries set forth in Graham v. John Deere Co. , 383 U.S. 1, 148 USPQ 459 (1966), that are applied 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. 07-21-aia AIA Claim s 1-7 and 9-20 are rejected under 35 U.S.C. 103 as being unpatentable over SORANI et al. (Pub. No.: US 2022/0394053, hereinafter SORANI) . Regarding claim 1 : SORANI discloses A system, comprising: a memory that stores computer executable components ( SORANI - [0062-63] ); and a processor that executes the computer executable components stored in the memory ( SORANI - [0066] ), wherein the computer executable components comprise: a threat analysis and risk assessment (TARA) tool configured to: determine a first threat risk for an asset, wherein the asset defines a property of an item ( SORANI - [0043]: obtaining a configuration of vehicle 110, the configuration comprising descriptions 211 i of plurality of units 111, 112; obtaining specifications of plurality of vulnerabilities 230; automatically 501, 504 matching 302 at least one of the vulnerabilities 231 with plurality of units 111, 112, included in the configuration; automatically simulating an attack on the vehicle's plurality of units 111, 112 according to the matched vulnerabilities 330, and the descriptions 211 i of the plurality of units 111, 112, thereby identifying 306 compromised units 340 ); compare the first threat risk with an acceptable level of risk ( SORANI - [0053]: retrieving known vulnerabilities is matched against various units (e.g., ECUs) by, for example, exploiting the vulnerability under normal operating conditions for the particular unit ) ; in response to determining the first threat risk exceeds the acceptable level of risk, determine a modification of the asset to reduce the first threat risk to a second threat risk; and recommend the modification of the asset to reduce the first threat risk to the second threat risk at the item ( SORANI - [0071]: the severity is modified based on public information, wherein (xv) the at least one action based on the first risk level value selected is: a configuration modification, the method further comprising: determining the modification of the configuration such that the first risk level value is decreased and suggesting the configuration modification to a user, or alternatively, automatically implementing the proposed configuration modification, and (xvi) automatically generating and updating the configuration of the vehicle by automatically identifying at least one of: a software unit and a hardware unit in a vehicle and modifying the software and/or firmware ). SORANI discloses the above features in different embodiments. However, it would have been obvious to a person of ordinary skill in the art at the time the invention was made to combine the teachings in these embodiments in different ways. The motivation to do so would be to efficiently enhance security. Regarding claim 2 : SORANI discloses wherein the TARA tool is further configured to: determine an impact rating of the first threat; and determine an attack feasibility rating of the first threat, wherein the first threat risk is a combination of the impact rating and the attack feasibility rating ( SORANI - [0048]: Risk levels can be assessed based on several factors, for example, a vulnerability type, an exploit type, an impact, a remediation complexity, and a likelihood of occurrence ). Regarding claim 3 : SORANI discloses wherein the impact rating of the first threat identifies an impact of the first threat on an operational condition of the property of the item defined by the asset ( SORANI - [0028]: risk assessment of vehicle functions (gear, brake, power, connected-car) (see e.g., FIG. 2 ), which are present in the asset, and (the module), is operable to use the information of the criticality of the various component in the system's architecture, the potential impact (for example safety) of malfunction of each component ). Regarding claim 4 : SORANI discloses wherein the attack feasibility rating of the first threat identifies a feasibility of the first threat being implemented against the asset ( SORANI - [0045]: generating and, using the display module-presenting a sorted (e.g., by criticality index) list of threats associated with the plurality of units determined to be compromised in simulation 350 ). Regarding claim 5 : SORANI discloses wherein the item is located on a vehicle ( SORANI - [0043]: automatically simulating an attack on the vehicle's plurality of units 111 ). Regarding claim 6 : SORANI discloses wherein the vehicle is a software-defined vehicle ( SORANI - [0006]: more and more key vehicle functions rely also on software rather mainly on hardware ). Regarding claim 7 : SORANI discloses wherein the item is one of a software implemented on the vehicle, an electronic control unit located on the vehicle, or a communication network located on the vehicle ( SORANI - [0051]: description of the plurality of units 211 i relates to at least one of: a manufacture (e.g., 2111 etc.), a software module and version ). Regarding claim 9 : SORANI discloses wherein the first threat risk and the second threat risk are determined in accordance with one or more risks defined by ISO 21434 ( SORANI - [0036]: Prioritization of relevant vulnerabilities based on total damage class score (essentially, a vulnerability index) Compliance to risk management regulation and standards, e.g. ISO/IEC/SAE 21434 ). Regarding claim 10 : SORANI discloses wherein the item is a first item, the TARA tool is further configured to: in response to receiving approval to modify the asset to reduce the first threat risk to the second threat risk at the first item, modifying the asset; determine an effect of modifying the asset on an operating condition of a second item ( SORANI - [0049]: selectively modifying attributes of at least one of the plurality of unit (nodes, e.g., ECU3, 310, FIG. 1 ) to overcome at least one identified vulnerability (e.g., in identified compromised ECU3); simulating an attack on the vehicle incorporating the now-modified attribute used to overcome the identified vulnerability; and recording a second risk level value (e.g., 331, FIG. 1 )); and in response to determining the operating condition of the second item is negatively affected by modifying the asset of the first item, cancel modification of the asset of the first item ( SORANI - [0049]: if the second risk level value is lower than the first risk level value, either, providing a recommendation for improving the safety of the vehicle based on the modification of the at least one unit, or automatically modifying that attribute, wherein the at least one vulnerability sought to be overcome by modifying of attribute, is selected based on a set of scores 330, 331, associated with a respective set of vulnerabilities ). Regarding claim 11: this claim defines a method claim that corresponds to system claim 1 and does not define beyond limitations of claim 1. Therefore, claim 11 is rejected with the same rational as in the rejection of claim 1. Regarding claim 12 : SORANI discloses wherein the item is included in a design of a computer-system, wherein the computer-system pertains to a software-defined vehicle ( SORANI - [0043]: obtaining a configuration of vehicle 110, the configuration comprising descriptions 211 i of plurality of units 111, 112. [0006]: more and more key vehicle functions rely also on software rather mainly on hardware ). Regarding claim 13 : SORANI discloses wherein the device is included in a threat analysis and risk assessment (TARA) system and the asset is a first asset defining a first property of the item, the computer-implemented method further comprising: in response to receiving approval, implementing, by the device, the modification of the first asset to reduce the first threat risk to a second threat risk; determining, by the device, a third threat risk for a second asset defining a second property of the item; comparing, by the device, the third threat risk with the acceptable level of risk; in response to determining the third threat risk exceeds the acceptable level of risk, determining, by the device, a second modification of the second asset to reduce the third threat risk to a fourth threat risk; implementing, by the device, the second modification of the second asset; and determining, by the device, an effect of the second modification of the second asset on an operating condition of the first property of the item modified in accordance with the second threat risk ( SORANI - [0049]: the methods implemented using the systems described herein further comprise, iteratively (in other words, in a cyclic manner): selectively modifying attributes of at least one of the plurality of unit (nodes, e.g., ECU3, 310, FIG. 1 ) to overcome at least one identified vulnerability (e.g., in identified compromised ECU3); simulating an attack on the vehicle incorporating the now-modified attribute used to overcome the identified vulnerability; and recording a second risk level value (e.g., 331, FIG. 1 ); and if the second risk level value is lower than the first risk level value, either, providing a recommendation for improving the safety of the vehicle based on the modification of the at least one unit, or automatically modifying that attribute, wherein the at least one vulnerability sought to be overcome by modifying of attribute, is selected based on a set of scores 330, 331, associated with a respective set of vulnerabilities ). Regarding claim 14 : SORANI discloses wherein the item is one of a software function, an electronic control unit, or a network device ( SORANI - [0044]: In the context of the disclosure, the term “asset service module” refers to a “node” meaning any active device (e.g., host machine, server, switch, port, ECU, or the like) attached to a local computer network or telecommunication network (e.g., cellular, wide area network, or the internet) . See also [0028] ). Regarding claim 15 : SORANI discloses wherein, the software function is configured to be implemented on an electronic control unit located on a software-defined vehicle ( SORANI - [0020]: providing continuous and systematic monitoring of the software used in different car configurations ). Regarding claim 16 : SORANI discloses wherein the device is located at a centralized system ( SORANI - [0021]: The processes used within the manufacturer's organization to manage cyber security ), and at least one of the asset or the item are retrieved from a product design database communicatively coupled to the centralized system ( SORANI - [0058]: the client server 210 (which can be the same or different than server 110) can comprise CVE description 211 i, with specific CVEs 2111, and 2112 that are continuously fed 213 into backend management server's vulnerability monitoring module 2311 and from there 504 undergo matching function 302 to known ECU's monitored in the fleet's vehicles ). Regarding claims 17-19 : Claims are directed to computer readable medium claims and do not teach or further define over the limitations recited in claims 1, 5-6 and 9. Therefore, claims 17-19 are also rejected for similar reasons set forth in claims 1, 5-6 and 9. Furthermore, SORANI in para. [0067] discloses a non-transitory computer-readable storage medium. Regarding claim 20 : SORANI discloses wherein modification of the asset comprises re-coding software, reconfiguring an electronic control unit, or reconfiguring a network architecture ( SORANI - [0050]: automatically modifying the attributes to reduce the risk of units (nodes) associated with telematics for example (see e.g., FIG. 2 ), may comprise in certain exemplary implementations, at least one of: secure the boot and software attestation process, debugging port authentication, performing over-the-air (OTA) software updates (reprogramming, both FOTA and SOTA) ) . 07-21-aia AIA Claim 8 is rejected under 35 U.S.C. 103 as being unpatentable over SORANI et al. (Pub. No.: US 2022/0394053, hereinafter SORANI) in view of Konrardy et al. (Patent No.: US 10,824,145) . Regarding claim 8 : SORANI discloses wherein the system is communicatively coupled to a product design database, and the TARA tool is further configured to: identify the item in the product design database, wherein the item is included in a design of a computer system to be implemented on vehicle; retrieve the item from the product design database ( SORANI - [0058]: the client server 210 (which can be the same or different than server 110) can comprise CVE description 211 i, with specific CVEs 2111, and 2112 that are continuously fed 213 into backend management server's vulnerability monitoring module 2311 and from there 504 undergo matching function 302 to known ECU's monitored in the fleet's vehicles ); update the item in accordance with the modified asset ( SORANI - [0051]: modifying attributes of at least one of the plurality of units comprises modifying at least one of: an attribute of a software module in the unit, an attribute of a hardware component in the unit, an operational mode of the unit, a physical connection related to the unit, and a logical connection (in other words, operable coupling) related to the unit ); However, SORANI doesn’t explicitly teach but Konrardy teaches add the updated item to the product design database ( Konrardy - [Col. 49, Line 12-13]: the map database may be updated by adding new data regarding the anomaly to the database ). It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the method of SORANI with Konrardy so that the updated item can be added to the database. The modification would have allowed the system to persistent updated data. Conclusion Any inquiry concerning this communication or earlier communications from the examiner should be directed to MENG LI whose telephone number is (571)272-8729. The examiner can normally be reached M-F 8:30-5:30. 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, Alexander Lagor can be reached on (571) 270-5143. 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. /MENG LI/ Primary Examiner, Art Unit 2437 Application/Control Number: 18/648,000 Page 2 Art Unit: 2437 Application/Control Number: 18/648,000 Page 3 Art Unit: 2437 Application/Control Number: 18/648,000 Page 4 Art Unit: 2437 Application/Control Number: 18/648,000 Page 5 Art Unit: 2437 Application/Control Number: 18/648,000 Page 6 Art Unit: 2437 Application/Control Number: 18/648,000 Page 7 Art Unit: 2437 Application/Control Number: 18/648,000 Page 8 Art Unit: 2437
Prosecution Insights