DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1, 3-7, 9, 10, and 13-24 rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claims 1, 9, and 10 recite the terms “a data link layer,” “a physical layer,” “a transport layer,” and “a network layer.” However, the instant Specification does not provide any details as to the nature of these layers. This leaves the scope of the claims unclear because it is unclear as to what structure would or would not read on these limitations.
The dependent claims are rejected based on their dependence from the independent claims.
Claim Rejections - 35 USC § 102
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 (i.e., changing from AIA to pre-AIA ) 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 the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claim(s) 1, 3-7, 9, 10, and 13-24 is/are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Lekidis et al., Model-based simulation and threat analysis of in-vehicle networks, IEEE, 2019 [hereinafter “Lekidis”].
Regarding Claims 1, 9, and 10, Lekidis discloses a multi-electronic control unit (ECU) simulation test method (and, inherently, corresponding computer device, processor, memory, and storage medium including computer programs for performing the simulation)[Abstract – “In this paper we present a new method, based on OMNET++, for testing new in-vehicle features and assessing security risks through network simulation.”Page 4, first column – “4) Network simulation: Once built, the network model is simulated using OMNET++. Testing of the network architecture can be accomplished using the interactive time line to achieve low-level message scheduling between the individual ECUs. While the simulation is active the network traffic is logged into a packet capture (i.e. PCAP) file that is stored in individual ECUs or in special data logging components as diagnostic ECUs or gateways.”], comprising:
obtaining a pre-developed application applied to a target ECU [See the model development per Section III, steps 1-3];
inputting the application into a pre-built multi-ECU simulation environment [Page 4, first column – “4) Network simulation: Once built, the network model is simulated using OMNET++. Testing of the network architecture can be accomplished using the interactive time line to achieve low-level message scheduling between the individual ECUs. While the simulation is active the network traffic is logged into a packet capture (i.e. PCAP) file that is stored in individual ECUs or in special data logging components as diagnostic ECUs or gateways.”];
querying a simulated vehicle-mounted ECU having a unique identifier the same as the target ECU from a plurality of simulated vehicle-mounted ECUs in the multi-ECU simulation environment as a target simulated ECU [Page 4, first column – “4) Network simulation: Once built, the network model is simulated using OMNET++. Testing of the network architecture can be accomplished using the interactive time line to achieve low-level message scheduling between the individual ECUs. While the simulation is active the network traffic is logged into a packet capture (i.e. PCAP) file that is stored in individual ECUs or in special data logging components as diagnostic ECUs or gateways.”Page 4, first column – “5) Model validation: The logged network data file from the in-vehicle network simulation of Step 4 undergoes an offline comparison against the vehicle data logged of Step 1 using the tool of Section III-C.”Page 5, second column – “C. Model validationTo validate the accuracy of the simulated vehicle network model in OMNET++ against logged data from the same vehicle, we sought to develop an automatic validation tool. The reason for its development was that the state-of-the-art tools are not tailored for in-vehicle networks. The tool core is using the packet serialization utility of Python to 1) parse network data in PCAP format captured from the vehicle under-study and the output of the data logger (i.e. DLC) CAN node module from the OMNET++ simulation in the same format and 2) examine the differences per individual packet.”Page 6, second column – “The data in this model are logged through the DLC component (Fig. 5) in the form of PCAP file. Hence, this component is connected to all the ECUs of the model to receive data through its input buffer component.”]; and
simulating a communication process of the target simulated ECU via a simulated controller area network (CAN) or a simulated Internet network in the multi-ECU simulation environment, running the application based on the target simulated ECU [Page 5, second column – “C. Model validationTo validate the accuracy of the simulated vehicle network model in OMNET++ against logged data from the same vehicle, we sought to develop an automatic validation tool. The reason for its development was that the state-of-the-art tools are not tailored for in-vehicle networks. The tool core is using the packet serialization utility of Python to 1) parse network data in PCAP format captured from the vehicle under-study and the output of the data logger (i.e. DLC) CAN node module from the OMNET++ simulation in the same format and 2) examine the differences per individual packet.”], and
outputting a running result of the application [Pages 5-6 – “At the end of the evaluation the tool provides a verdict for the percentage of the total packets number that match according to a user-defined threshold. When the percentage is higher than the given threshold the verdict is successful, otherwise fail. Moreover, sufficiently high thresholds (i.e. >90%) ensure that the model is accurate according to the vehicle network it analyzes, because it reflects its core network behavior. The tool also outputs the spotted differences per packet. The differences can then be used to provide feedback to the data and functional model of Fig. 3 for improving their accuracy with respect to the real vehicle-under-study.”];
wherein the method further comprises pre-building the multi-ECU simulation environment [See the model development per Section III, steps 1-3 which is inherently performed using computer commands (i.e., the recited “instructions”)], comprising:
configuring a data link layer and a physical layer of the simulated Internet network based on a received first instruction [Pages 3-4 – “1) Data model learning: This step is necessary for the characterization of network data, as the protocols of the in-vehicle architecture lack addressing schemes. This characterization involves behavioral learning of the in vehicle network data, such as the employed protocols as well as the main commands that are exchanged periodically by the ECUs (i.e. cyclic messages) or from event-triggered user actions on the vehicle (i.e. dynamic messages).”];
configuring a transport layer and a network layer of the simulated Internet network based on a received second instruction [Page 4, first column – “3) Translation for the construction of the network model: The functional model is afterwards systematically translated in order to produce all the necessary configuration files for the creation of the network simulation model in OMNET++ (Section III-B). These files relate to NED module files containing the main modules of the compound network components as well as the INI file for the initial parameterization of the network components.”] and an Internet protocol stack [Page 8, second column – “we will build our data model based on the central gateway of the in-vehicle architecture and analyzing further in-vehicle protocols, such as FlexRay, MOST and also Automotive Ethernet”];
simulating a CAN bus communication based on a received third instruction and data distribution service [Page 4 – “The CAN network consists of multiple CAN nodes, which are defined as the components modeling the vehicle ECUs.”]; and
configuring virtual networks corresponding respectively to Internet protocol simulation addresses where the plurality of simulated vehicle-mounted ECUs are located based on a received fourth instruction [Page 4, first column – “4) Network simulation: Once built, the network model is simulated using OMNET++.”Page 4 – “As an initial step of our method, we gather and analyze vehicle data, to characterize network communication and exchanged commands. First, we build a generic model that represents the data flow in in-vehicle networks and later tailor it to the vehicle-under-study by populating it with data gathered from the DLC (Section II-A) of the real vehicle. The data model that is considered for our method is based on the CAN network data. Each CAN network consists of a number of ECUs that are responsible for computations and physical actions inside a vehicle. Each ECU has an associated number of messages that are used to exchange information with other ECU’s. Messages have an address (i.e. message identifier), a length and a cycle time, which defines their periodicity on the network.”].
Regarding Claims 3, 13, and 18, Lekidis discloses that, when there are a plurality of target ECUs to which the application is applied, and there is one Internet protocol address for the plurality of target ECUs [Page 4 – “As an initial step of our method, we gather and analyze vehicle data, to characterize network communication and exchanged commands. First, we build a generic model that represents the data flow in in-vehicle networks and later tailor it to the vehicle-under-study by populating it with data gathered from the DLC (Section II-A) of the real vehicle. The data model that is considered for our method is based on the CAN network data. Each CAN network consists of a number of ECUs that are responsible for computations and physical actions inside a vehicle. Each ECU has an associated number of messages that are used to exchange information with other ECU’s. Messages have an address (i.e. message identifier), a length and a cycle time, which defines their periodicity on the network.”], running the application based on the target simulated ECU, comprises:
obtaining a first message sent to the simulated CAN; obtaining a simulated ECU of a transmitter of the first message from the first message; and replacing the first message with a source transmit code of a topic to which the simulated ECU of the transmitter belongs [Page 4, first column – “6) Network and threat analysis: Once the model is validated, we proceed on the real-time analysis of network performance aspects as well as operational errors or security aspects. This is done by introducing faulty or malicious modules respectively in the simulation. The analysis outcome allows to quantify the impact of such aspects on the overall network and provides feedback for enhancements in the in-vehicle architecture”See the different attacks and corresponding description in Table II, such as frame injection, ECU spoofing, and fuzzing.].
Regarding Claims 4, 14, and 19, Lekidis discloses that, when there are a plurality of target ECUs to which the application is applied, and there are two or more Internet protocol addresses for the plurality of target ECUs [Page 4 – “As an initial step of our method, we gather and analyze vehicle data, to characterize network communication and exchanged commands. First, we build a generic model that represents the data flow in in-vehicle networks and later tailor it to the vehicle-under-study by populating it with data gathered from the DLC (Section II-A) of the real vehicle. The data model that is considered for our method is based on the CAN network data. Each CAN network consists of a number of ECUs that are responsible for computations and physical actions inside a vehicle. Each ECU has an associated number of messages that are used to exchange information with other ECU’s. Messages have an address (i.e. message identifier), a length and a cycle time, which defines their periodicity on the network.”Page 4, second column – “OMNET++ provides support for in-vehicle network protocol simulation through the Fieldbus Communication For OMNeT (FiCo4OMNeT) library [5]. FiCo4OMNeT allows the simulation of CAN and FlexRay network architectures.”], running the application based on the target simulated ECU, comprises:
obtaining a destination address of a second target simulated ECU in a simulated Internet network message sent by a first target simulated ECU; converting the destination address to a target Internet protocol simulation address in the simulated Internet network; and sending the simulated Internet network message to the second target simulated ECU corresponding to the target Internet protocol simulation address [Page 4, first column – “6) Network and threat analysis: Once the model is validated, we proceed on the real-time analysis of network performance aspects as well as operational errors or security aspects. This is done by introducing faulty or malicious modules respectively in the simulation. The analysis outcome allows to quantify the impact of such aspects on the overall network and provides feedback for enhancements in the in-vehicle architecture”See the different attacks and corresponding description in Table II, such as frame injection, ECU spoofing, and fuzzing.].
Regarding Claims 5, 15, 20, 23, and 24, Lekidis discloses that the application comprises a diagnostic file, running the application based on the target simulated ECU and outputting the running result of the application, comprises: importing the diagnostic file into the target simulated ECU; obtaining an execution result of executing the diagnostic file by the target simulated ECU; determining whether the execution result contains a diagnostic fault code or a corresponding error text; and determining that the target simulated ECU is operating abnormally in response determining that the execution result contains a diagnostic fault code or a corresponding error text [Page 5, first column – “An example of a component port is the canNodePort illustrated in the left part of Fig. 5. This port allows the DLC CAN node component (Section II-A) to receive diagnostic information from the in-vehicle architecture.”Page 7, second column – “We simulate the scenario that the vehicle is in drive mode, when, as of the 4th second of Fig. 9, a malicious node initiates the transmission of cyclic CAN messages with CANID 0x4 to set the vehicle into neutral mode. However, since the gear transmission message is also cyclic, we observe a fluctuating behavior as a result in the DLC node (yellow line). This creates a confusing indicator in the dashboard ECU, which is receiving all these messages. The dashboard ECU indicates this fault by generating error frames (Section II) on the Bus and accordingly switching to error active and afterwards error passive mode [19], resulting eventually to a suspension attack (Table II). Eventually the number of errors on the Bus set it to OFF state [4], which terminates the simulation as can be shown after the 14th second of Fig. 9”].
Regarding Claims 6, 16, and 21, Lekidis discloses that running the application based on the target simulated ECU and outputting the running result of the application, comprises: importing the application into the target simulated ECU [Page 4, first column – “4) Network simulation: Once built, the network model is simulated using OMNET++. Testing of the network architecture can be accomplished using the interactive time line to achieve low-level message scheduling between the individual ECUs. While the simulation is active the network traffic is logged into a packet capture (i.e. PCAP) file that is stored in individual ECUs or in special data logging components as diagnostic ECUs or gateways.”];
obtaining an execution result of executing the application by the target simulated ECU; and outputting a function status parameter of the target simulated ECU carried in the execution result [Page 5, second column – “C. Model validationTo validate the accuracy of the simulated vehicle network model in OMNET++ against logged data from the same vehicle, we sought to develop an automatic validation tool. The reason for its development was that the state-of-the-art tools are not tailored for in-vehicle networks. The tool core is using the packet serialization utility of Python to 1) parse network data in PCAP format captured from the vehicle under-study and the output of the data logger (i.e. DLC) CAN node module from the OMNET++ simulation in the same format and 2) examine the differences per individual packet.”Pages 5-6 – “At the end of the evaluation the tool provides a verdict for the percentage of the total packets number that match according to a user-defined threshold. When the percentage is higher than the given threshold the verdict is successful, otherwise fail. Moreover, sufficiently high thresholds (i.e. >90%) ensure that the model is accurate according to the vehicle network it analyzes, because it reflects its core network behavior. The tool also outputs the spotted differences per packet. The differences can then be used to provide feedback to the data and functional model of Fig. 3 for improving their accuracy with respect to the real vehicle-under-study.”].
Regarding Claims 7, 17, and 22, Lekidis discloses that running the application based on the target simulated ECU, comprises: parsing a first file in a Database CAN (DBC) format generated by the target simulated ECU based on the application [Page 5, second column – “C. Model validationTo validate the accuracy of the simulated vehicle network model in OMNET++ against logged data from the same vehicle, we sought to develop an automatic validation tool. The reason for its development was that the state-of-the-art tools are not tailored for in-vehicle networks. The tool core is using the packet serialization utility of Python to 1) parse network data in PCAP format captured from the vehicle under-study and the output of the data logger (i.e. DLC) CAN node module from the OMNET++ simulation in the same format and 2) examine the differences per individual packet.”]; and
broadcasting a message generated based on the first file in the simulated CAN in accordance with an information cycle recorded in the first file [Page 4, first column – “6) Network and threat analysis: Once the model is validated, we proceed on the real-time analysis of network performance aspects as well as operational errors or security aspects. This is done by introducing faulty or malicious modules respectively in the simulation. The analysis outcome allows to quantify the impact of such aspects on the overall network and provides feedback for enhancements in the in-vehicle architecture”].
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
Baronti et al., Design and Verification of Hardware Building Blocks for High-Speed and Fault-Tolerant In-Vehicle Networks, IEEE, 2011
Guo et al., Model checking of in-vehicle networking systems with CAN and FlexRay, Elsevier, 2019
Lazar et al., Simulator for the Automotive Diagnosis System on CAN using Vector CANoe Environment, IEEE, 2020
Varshney et al., Automated Testing of Faults of an Automotive System, IEEE, 2019
Any inquiry concerning this communication or earlier communications from the examiner should be directed to KYLE ROBERT QUIGLEY whose telephone number is (313)446-4879. The examiner can normally be reached 9AM-5PM 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, Arleen Vazquez can be reached at (571) 272-2619. 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.
/KYLE R QUIGLEY/Primary Examiner, Art Unit 2857
Prosecution Insights