DETAILED ACTION
This action is in response to the claims filed October 20, 2023. Claims 1-20 are pending. Claims 1 and 14 are independent claims.
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 Objections
Claims 6, 7, 12, 13, and 14 are objected to because of the following informalities:
- Claim 6 reads “a inter-processor communication (IPC) framework”. This should likely read “an inter-processor communication (IPC) framework”.
- Claim 7 reads “[t]]he system of claim 6”. This should likely read “[t]he method of claim 6”.
- Claim 12 reads “[t]]he system of claim 1”. This should likely read “[t]he method of claim 1”.
- Claim 13 reads “[t]]he system of claim 1”. This should likely read “[t]he method of claim 1”.
- Claim 13 reads “the platform”. This should likely read “the computer-based platform”.
- Claim 14 reads “conceal a specific hardware configuration of the the plurality…”. This should likely read “conceal a specific hardware configuration of the plurality…”.
- Claim 14 reads “configured to enables the iteration of the architecture agnostic software”. This should likely read “configured to enable the iteration of the architecture agnostic software”.
Appropriate correction is required.
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 4, 5, 11, and 17-20 are 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 4, 11, 19, and 20 recite “the plurality”. It is unclear what “the plurality” should refer to. For the purposes of examination, “the plurality” is interpreted to mean “the plurality of ECUs”. Claim 5 is rejected by merit of its dependency on claim 4.
Claim 17 recites “the system of clam 1”. Claim 1 does not recite a system. For the purposes of examination, the claim is interpreted to read “the system of claim 14”. Claims 18-20 are rejected by merit of their dependency on claim 17.
Claim 20 recites “the system of claim 9”. Claim 9 does not recite a system. For the purposes of examination, the claim is interpreted to read “the system of claim 19”.
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 (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 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-20 are rejected under 35 U.S.C. 103 as being unpatentable over “System-level Development of Embedded Software” by Schirner et. al (hereinafter “Schirner”), in view of US 20210129842 A1 (hereinafter “Wang”) and US 20190324806 A1 (hereinafter “Javre”).
Regarding claim 1, Schirner discloses:
A method of programming a programmable unit of a vehicle, wherein the programmable unit interfaces [embedded systems], the method comprising (Page 904, “Electronic System Level (ESL) design addresses the complexity challenges of designing a modern embedded system by raising the abstraction level for design and development. Figure 1 outlines our ESL flow that is implemented in the System-on-Chip Environment (SCE) [8]. Our flow uses a two step approach of first generating a system TLM for detailed performance estimation and early validation, and then using the same TLM in a second step for automatic generation of a SW and HW implementation”):
… wherein the computer-based platform comprises a hardware abstraction layer, a transport layer, and a service layer, wherein developing the software comprises: interfacing, via the hardware abstraction layer, with the [embedded system] (Page 905, “The processor model’s next layer, the Hardware Abstraction Layer (HAL) contains a representation of the necessary drivers for external communication. The driver includes marshalling and demarshalling of user data to translate to and from a common untyped network data format. It furthermore includes low level drivers that implement external bus communication and synchronize with external sources [interfacing, via the hardware abstraction layer, with the [embedded system]]”) [Examiner’s Remarks: The hardware abstraction layer provides integration of drivers for communication from the embedded device.];
- concealing, via the hardware abstraction layer, a [system]-specific configuration of the [embedded system] (Page 904, “The input to the system design flow is the specification model, shown on top. The specification is an untimed and platform-agnostic description of the system’s algorithms and their dependencies captured in the C-based SLDL SpecC [13]”; “A second input to our design flow contains the designer’s architecture decisions describing the target platform as shown on the left of Figure 1. The architecture decisions include the allocation of processing elements (PEs), such as processors, and HW components, and the mapping of behaviors to PEs [concealing, via the hardware abstraction layer, a vehicle-specific configuration of the [embedded system]]”) [Examiner’s remarks: The system-specific configuration of the embedded system is concealed in the specification of the algorithms behaviors. The architecture is only introduces later on when creating the program via the architecture decisions.];
- eliminating, via the hardware abstraction layer, [embedded device]-specific dependencies for the software (Page 904, “The input to the system design flow is the specification model, shown on top. The specification is an untimed and platform-agnostic description of the system’s algorithms and their dependencies captured in the C-based SLDL SpecC [13]”; “A second input to our design flow contains the designer’s architecture decisions describing the target platform as shown on the left of Figure 1. The architecture decisions include the allocation of processing elements (PEs), such as processors, and HW components, and the mapping of behaviors to Pes…The behaviors B1, B2, and B3 are mapped to the processor. These behaviors are later wrapped into tasks and the designer can select important task parameters, such as priority and stack size [eliminating, via the hardware abstraction layer, [embedded device]-specific dependencies for the software]”) [Examiner’s Remarks: Specific dependencies for the embedded device architecture are not considered in the initial specification of behaviors, but only introduced later on.];
- integrating, via the transport layer, a first [device] communication protocol associated with the software with a second [device] communication protocol associated with the [embedded system] (Page 905, “The SCE engine instantiates and connects components out of the component data base and populates them with the computation captured in the specification model. It refines the communication between processing elements from the standardized abstract channels to a communication based on the selected medium”; “The processor model’s next layer, the Hardware Abstraction Layer (HAL) contains a representation of the necessary drivers for external communication. The driver includes marshalling and demarshalling of user data to translate to and from a common untyped network data format. It furthermore includes low level drivers that implement external bus communication and synchronize with external sources [integrating, via the transport layer, a first [device] communication protocol associated with the software with a second [device] communication protocol associated with the [embedded system]]”) [Examiner’s Remarks: Standard channels are integrated between the specified communication layers which includes external bus communications with external sources and internal communication channels.]; and
- developing, via the service layer, the software via a plurality of application programming interfaces ("APIs") (Page 906, “HdS generation reads the decisions captured in the system TLM, and implements those on the target system. As such, it generates code for processor internal and external communication, including bus access drivers and synchronization code (polling or interrupt). HdS generation also creates code to execute multiple tasks on the same processor, e.g. by targeting an off-the-shelf RTOS. Finally, it generates configuration and build files (e.g. Makefile) that control the cross compilation process to produce the final target binary”; “To support multiple tasks executing on the same processor, HdS generation can adjust the task code to run on top of an off the-shelf RTOS. It replaces the abstract calls for task management in the TLM, with corresponding target implementations. To limit the interdependency between the code generation and the particular OS’s API we introduce a very thin RTOS Abstract Layer (RAL) that implements a common canonical API on top of the actual RTOS’s API [developing, via the service layer, the software via a plurality of application programming interfaces ("APIs")]”); and
- after developing the software, deploying the developed software to the [device] for installation on the programmable unit (Page 906, “As such, it generates code for processor internal and external communication, including bus access drivers and synchronization code (polling or interrupt). HdS generation also creates code to execute multiple tasks on the same processor, e.g. by targeting an off-the-shelf RTOS. Finally, it generates configuration and build files (e.g. Makefile) that control the cross compilation process to produce the final target binary [after developing the software, deploying the developed software to the [device] for installation on the programmable unit]”) [Examiner’s remarks: A program is generated to be deployed and run on a specific device.].
Schirner discloses a method of updating embedded systems. Schirner does not disclose a plurality of ECUs or vehicles. However, Wang discloses communication with a plurality of ECUs and Vehicles (Paragraph [0021]; “The network connection interface 34 enables the vehicle hardware 16 to send and receive signals with each other and with various systems and subsystems both within or “resident” to the vehicle body 12 and outside or “remote” from the vehicle body 12. This allows the vehicle 10 to perform various vehicle functions, such as controlling vehicle steering, governing operation of the vehicle's transmission, modulating engine throttle and/or motor output, engaging/disengaging the brake system, and other automated driving functions. For instance, telematics unit 14 receives and/or transmits data to/from an autonomous systems control module (ACM) 52, an engine control module (ECM) 54, a powertrain control module (PCM) 56, a sensor system interface module (SSIM) 58, a brake system control module (BSCM) 60, and assorted other vehicle ECUs, such as a transmission control module (TCM), a climate control module (CCM), etc”) [Examiner’s remarks: Wang discloses a communication system with a plurality of electronic control units as part of a vehicle which is able to interface with outside networks. Electronic control units are a subset of embedded devices used for vehicles. Therefore, one of ordinary skill in the art may apply update ECUs using a method created for embedded devices.]
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Wang into the teachings of Schirner to include “ECUs” and “vehicles”. As stated in Wang, “Independently operating multiple ECUs and sensor arrays to produce and process the same data is inherently inefficient, resulting in superfluous component and function redundancies, amplified computational complexity and burden, and increased system hardware and software costs” (Paragraph [0005]). Allowing and encouraging ECU communication lessens inefficiencies. Furthermore, ECUs are a type of embedded system which may be combined with the update process for embedded systems described in Schirner. Therefore, it would be obvious to one of ordinary skill in the art to combine embedded system updates with ECUs in vehicles.
The combination of Schirner and Wang does not explicitly disclose:
- developing with a computer-based platform hosted on a server remote from the vehicle, software to be deployed on the programmable unit of the vehicle, …:
However, Javre discloses:
- developing with a computer-based platform hosted on a server remote from the vehicle, software to be deployed on the programmable unit of the vehicle, … (Paragraph [0023], “ System 100 is an example of computer hardware that may be used to implement a computer, a server, a portable computer such as a laptop or a tablet computer, or other data processing system. A system or a device implemented using computer hardware is capable of performing the various operations described herein relating to creating and isolating multiple domains within an SoC and/or processing a circuit design for implementation within an SoC [developing with a computer-based platform hosted on a server remote from the vehicle, software to be deployed on the programmable unit of the vehicle]”) [Examiner’s remarks: Javre teaches implementing operations of a system on chip in a server or other device separate from the chip. Combined with Schirner and Wang, a remote server may be used to update a vehicle from outside.]:
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Javre into the combined teachings of Schirner and Wang to include “developing with a computer-based platform hosted on a server remote from the vehicle, software to be deployed on the programmable unit of the vehicle”. As stated in Javre, “A system or a device implemented using computer hardware is capable of performing the various operations described herein relating to creating and isolating multiple domains within an SoC and/or processing a circuit design for implementation within an SoC” (Paragraph [0023]). Updated code from a server separate from the chip allows for more flexible editing and storage before implementing the system in vehicle. Therefore, it would be obvious to one of ordinary skill in the art to combine embedded system updates with units capable of executing different types of code.
Regarding claim 2, the rejection of claim 1 is incorporated; and the combination of Schirner and Wang does not explicitly disclose:
- wherein the server comprises a real-time response unit and an application unit configured to host the computer-based platform.
However, Javre discloses:
- wherein the server comprises a real-time response unit and an application unit configured to host the computer-based platform (Paragraph [0023], “ System 100 is an example of computer hardware that may be used to implement a computer, a server, a portable computer such as a laptop or a tablet computer, or other data processing system. A system or a device implemented using computer hardware is capable of performing the various operations described herein relating to creating and isolating multiple domains within an SoC and/or processing a circuit design for implementation within an SoC [wherein the server comprises]”; Paragraph [0040], “ In another aspect, the different processors of processor system 202 are physically distinct instances and utilize two or more different architectures (e.g., utilize different instruction sets). In the example of FIG. 2, processor system 202 includes an application processing unit (APU) 206, a real-time processing unit (RPU) 208, and/or processor 210 [a real-time response unit and an application unit configured to host the computer-based platform]”).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Javre into the combined teachings of Schirner and Wang to include “wherein the server comprises a real-time response unit and an application unit configured to host the computer-based platform”. As stated in Javre, “APU 206 may include one or more cores. For purposes of discussion within this disclosure, a core is considered a “processor” that is configured to execute program code. RPU 208 may include one or more cores… Both APU 206 and RPU 208 may be directly connected to programmable circuitry 204 through isolation circuits 230-1 and 230-5, respectively.” (Paragraph [0041]). Both real-time response units and application units are well known in the art for executing program code. Therefore, it would be obvious to one of ordinary skill in the art to combine embedded system updates with units capable of executing different types of code.
Regarding claim 3, the rejection of claim 2 is incorporated; and the combination of Schirner and Javre does not explicitly disclose:
- wherein the hardware abstraction layer comprises a plurality of vehicle-bus drivers, wherein the plurality of vehicle-bus drivers comprises a first subset of vehicle-bus drivers hosted on the real-time response unit and a second subset of vehicle-bus drivers hosted on the application unit.
However, Wang discloses vehicle-bus (Paragraph [0021], “Communicatively coupled to the telematics unit 14 is a network connection interface 34, suitable examples of which include twisted pair/fiber optic Ethernet switch, internal/external parallel/serial communication bus, a local area network (LAN) interface, a controller area network (CAN), a media-oriented system transfer (MOST), a local interconnection network (LIN) interface, and the like”).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Wang into the combined teachings of Schirner and Javre to include “vehicle-bus”. As stated in Wang, “Independently operating multiple ECUs and sensor arrays to produce and process the same data is inherently inefficient, resulting in superfluous component and function redundancies, amplified computational complexity and burden, and increased system hardware and software costs” (Paragraph [0005]). Allowing and encouraging ECU communication lessens inefficiencies. Furthermore, ECUs are a type of embedded system which may be combined with the update process for embedded systems described in Schirner. Therefore, it would be obvious to one of ordinary skill in the art to combine system updates with cross-ECU interaction.
The combination of Schirner and Wang does not explicitly disclose:
- wherein the hardware abstraction layer comprises a plurality of vehicle-bus drivers, wherein the plurality of vehicle-bus drivers comprises a first subset of vehicle-bus drivers hosted on the real-time response unit and a second subset of vehicle-bus drivers hosted on the application unit.
However, Javre discloses:
- wherein the hardware abstraction layer comprises a plurality of [drivers], wherein the plurality of [drivers] comprises a first subset of [drivers] hosted on the real-time response unit and a second subset of [drivers] hosted on the application unit (Paragraph [0040], “ In another aspect, the different processors of processor system 202 are physically distinct instances and utilize two or more different architectures (e.g., utilize different instruction sets). In the example of FIG. 2, processor system 202 includes an application processing unit (APU) 206, a real-time processing unit (RPU) 208, and/or processor 210”; Paragraph [0066], “Examples of different types of operating systems that may be selected for use in the domain include, but are not limited to, Linux, a Real-time Operating System (RTOS) such as Free RTOS, or any other operating system that is suitable for execution by a processor or an embedded processor [wherein the plurality of [drivers] comprises a first subset of [drivers] hosted on the real-time response unit and a second subset of [drivers] hosted on the application unit]”; Paragraph [0067], “The software developer may experiment with different operating system/processor pairings and/or different operating system configurations (e.g., different address space mappings, different drivers, etc. per block 725 below) [comprises a plurality of [drivers]]”).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Javre into the combined teachings of Schirner and Wang to include “wherein the hardware abstraction layer comprises a plurality of vehicle-bus drivers, wherein the plurality of vehicle-bus drivers comprises a first subset of vehicle-bus drivers hosted on the real-time response unit and a second subset of vehicle-bus drivers hosted on the application unit”. As stated in Javre, “APU 206 may include one or more cores. For purposes of discussion within this disclosure, a core is considered a “processor” that is configured to execute program code. RPU 208 may include one or more cores… Both APU 206 and RPU 208 may be directly connected to programmable circuitry 204 through isolation circuits 230-1 and 230-5, respectively.” (Paragraph [0041]). Both real-time response units and application units are well known in the art for executing program code. Drivers are well known in the art for facilitating communication and integrating different devices. Therefore, it would be obvious to one of ordinary skill in the art to combine embedded system updates with different device drivers split by function.
Regarding claim 4, the rejection of claim 3 is incorporated; and Schirner further discloses:
wherein the vehicle-specific configuration of the [embedded devices] is one of a plurality of [embedded device] configurations the hardware abstraction layer is configured to interface with, and wherein developing the software further comprises (Page 906, “HdS generation reads the decisions captured in the system TLM, and implements those on the target system. As such, it generates code for processor internal and external communication, including bus access drivers and synchronization code (polling or interrupt). HdS generation also creates code to execute multiple tasks on the same processor, e.g. by targeting an off-the-shelf RTOS. Finally, it generates configuration and build files (e.g. Makefile) that control the cross compilation process to produce the final target binary”):
- detecting, via the plurality of [device]-bus drivers, a similarity between the [device]- specific configuration of the [embedded system] and other [embedded system] configurations of the plurality (Page 905, “The SCE engine instantiates and connects components out of the component data base and populates them with the computation captured in the specification model. It refines the communication between processing elements from the standardized abstract channels to a communication based on the selected medium”; “The processor model’s next layer, the Hardware Abstraction Layer (HAL) contains a representation of the necessary drivers for external communication. The driver includes marshalling and demarshalling of user data to translate to and from a common untyped network data format. It furthermore includes low level drivers that implement external bus communication and synchronize with external sources”; Page 906, “HdS generation reads the decisions captured in the system TLM, and implements those on the target system. As such, it generates code for processor internal and external communication, including bus access drivers and synchronization code (polling or interrupt). HdS generation also creates code to execute multiple tasks on the same processor, e.g. by targeting an off-the-shelf RTOS. Finally, it generates configuration and build files (e.g. Makefile) that control the cross compilation process to produce the final target binary [detecting, via the plurality of [device]-bus drivers, a similarity between the [device]- specific configuration of the [embedded system] and other [embedded system] configurations of the plurality]”) ; and
- mapping, via the plurality of [device]-bus drivers, the developed software to an [embedded device] of the plurality based on the similarity (Page 905, “The SCE engine instantiates and connects components out of the component data base and populates them with the computation captured in the specification model. It refines the communication between processing elements from the standardized abstract channels to a communication based on the selected medium”; “The processor model’s next layer, the Hardware Abstraction Layer (HAL) contains a representation of the necessary drivers for external communication. The driver includes marshalling and demarshalling of user data to translate to and from a common untyped network data format. It furthermore includes low level drivers that implement external bus communication and synchronize with external sources”; Page 906, “HdS generation reads the decisions captured in the system TLM, and implements those on the target system. As such, it generates code for processor internal and external communication, including bus access drivers and synchronization code (polling or interrupt). HdS generation also creates code to execute multiple tasks on the same processor, e.g. by targeting an off-the-shelf RTOS. Finally, it generates configuration and build files (e.g. Makefile) that control the cross compilation process to produce the final target binary [mapping, via the plurality of [device]-bus drivers, the developed software to an [embedded device] of the plurality based on the similarity]”).
Schirner discloses a method of updating embedded systems. Schirner does not disclose a plurality of ECUs or vehicles. However, Wang discloses communication with a plurality of ECUs and Vehicles (Paragraph [0021]; “The network connection interface 34 enables the vehicle hardware 16 to send and receive signals with each other and with various systems and subsystems both within or “resident” to the vehicle body 12 and outside or “remote” from the vehicle body 12. This allows the vehicle 10 to perform various vehicle functions, such as controlling vehicle steering, governing operation of the vehicle's transmission, modulating engine throttle and/or motor output, engaging/disengaging the brake system, and other automated driving functions. For instance, telematics unit 14 receives and/or transmits data to/from an autonomous systems control module (ACM) 52, an engine control module (ECM) 54, a powertrain control module (PCM) 56, a sensor system interface module (SSIM) 58, a brake system control module (BSCM) 60, and assorted other vehicle ECUs, such as a transmission control module (TCM), a climate control module (CCM), etc”) [Examiner’s remarks: Wang discloses a communication system with a plurality of electronic control units as part of a vehicle which is able to interface with outside networks. Electronic control units are a subset of embedded devices used for vehicles. Therefore, one of ordinary skill in the art may apply update ECUs using a method created for embedded devices.]
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Wang into the combined teachings of Schirner and Javre to include “ECUs” and “vehicles”. As stated in Wang, “Independently operating multiple ECUs and sensor arrays to produce and process the same data is inherently inefficient, resulting in superfluous component and function redundancies, amplified computational complexity and burden, and increased system hardware and software costs” (Paragraph [0005]). Allowing and encouraging ECU communication lessens inefficiencies. Furthermore, ECUs are a type of embedded system which may be combined with the update process for embedded systems described in Schirner. Therefore, it would be obvious to one of ordinary skill in the art to combine embedded system updates with ECUs in vehicles.
Regarding claim 5, the rejection of claim 4 is incorporated; and the combination of Schirner and Javre does not explicitly disclose:
- wherein developing the software further comprises multiplexing, via the hardware abstraction layer, a plurality of messages simultaneously to the plurality of ECUs of the vehicle via a plurality of interfacing channels.
However, Wang discloses:
- wherein developing the software further comprises multiplexing, via the hardware abstraction layer, a plurality of messages simultaneously to the plurality of ECUs of the vehicle via a plurality of interfacing channels (Paragraph [0021], “The network connection interface 34 enables the vehicle hardware 16 to send and receive signals with each other and with various systems and subsystems both within or “resident” to the vehicle body 12 and outside or “remote” from the vehicle body 12. This allows the vehicle 10 to perform various vehicle functions, such as controlling vehicle steering, governing operation of the vehicle's transmission, modulating engine throttle and/or motor output, engaging/disengaging the brake system, and other automated driving functions. For instance, telematics unit 14 receives and/or transmits data to/from an autonomous systems control module (ACM) 52, an engine control module (ECM) 54, a powertrain control module (PCM) 56, a sensor system interface module (SSIM) 58, a brake system control module (BSCM) 60, and assorted other vehicle ECUs, such as a transmission control module (TCM), a climate control module (CCM), etc”; Paragraph [0027], “While shown with two sensors 102, 104 communicating with two ECUs 108, 110 across a single CAN bus 106, it will be appreciated that the embedded control system 100 may comprise any two or more sensing devices communicating with any two or more control devices across multiple communication interfaces within the scope of this disclosure. [wherein developing the software further comprises multiplexing, via the hardware abstraction layer, a plurality of messages simultaneously to the plurality of ECUs of the vehicle via a plurality of interfacing channels]”).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Wang into the combined teachings of Schirner and Javre to include “wherein developing the software further comprises multiplexing, via the hardware abstraction layer, a plurality of messages simultaneously to the plurality of ECUs of the vehicle via a plurality of interfacing channels”. As stated in Wang, “Independently operating multiple ECUs and sensor arrays to produce and process the same data is inherently inefficient, resulting in superfluous component and function redundancies, amplified computational complexity and burden, and increased system hardware and software costs” (Paragraph [0005]). Allowing and encouraging ECU communication lessens inefficiencies. Furthermore, ECUs are a type of embedded system which may be combined with the update process for embedded systems described in Schirner. Therefore, it would be obvious to one of ordinary skill in the art to combine system updates with cross-ECU interaction.
Regarding claim 6, the rejection of claim 3 is incorporated; and Schirner discloses drivers (Abstract, “It generates the application code, communication drivers, and an adaptation to a chosen RTOS.”).
The combination of Schirner and Javre does not explicitly disclose:
- wherein the first subset of vehicle-bus drivers comprises at least one of a inter-processor communication (IPC) framework, a functional safety framework, an Ethernet driver, a control area network (CAN) driver, and a local interconnect network (LIN) driver, or combinations thereof.
However, Wang discloses:
- wherein the first subset of vehicle-bus drivers comprises at least one of a inter-processor communication (IPC) framework, a functional safety framework, an Ethernet driver, a control area network (CAN) driver, and a local interconnect network (LIN) driver, or combinations thereof (Paragraph [0021], “Communicatively coupled to the telematics unit 14 is a network connection interface 34, suitable examples of which include twisted pair/fiber optic Ethernet switch, internal/external parallel/serial communication bus, a local area network (LAN) interface, a controller area network (CAN), a media-oriented system transfer (MOST), a local interconnection network (LIN) interface, and the like”).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Wang into the combined teachings of Schirner and Javre to include “wherein the first subset of vehicle-bus drivers comprises at least one of a inter-processor communication (IPC) framework, a functional safety framework, an Ethernet driver, a control area network (CAN) driver, and a local interconnect network (LIN) driver, or combinations thereof”. As stated in Wang, “Independently operating multiple ECUs and sensor arrays to produce and process the same data is inherently inefficient, resulting in superfluous component and function redundancies, amplified computational complexity and burden, and increased system hardware and software costs” (Paragraph [0005]). Allowing and encouraging ECU communication lessens inefficiencies. Furthermore, ECUs are a type of embedded system which may be combined with the update process for embedded systems described in Schirner. Therefore, it would be obvious to one of ordinary skill in the art to combine system updates with cross-ECU interaction.
Regarding claim 7, the rejection of claim 6 is incorporated; and the combination of Schirner and Wang does not explicitly disclose:
- wherein the second subset of vehicle-bus drivers comprises at least one of a second inter-processor communication (IPC) framework, a second functional safety framework, and a second Ethernet driver, or combinations thereof.
However, Javre discloses:
- wherein the second subset of vehicle-bus drivers comprises at least one of a second inter-processor communication (IPC) framework, a second functional safety framework, and a second Ethernet driver, or combinations thereof (Paragraph [0066], “Examples of different types of operating systems that may be selected for use in the domain include, but are not limited to, Linux, a Real-time Operating System (RTOS) such as Free RTOS, or any other operating system that is suitable for execution by a processor or an embedded processor”) [Examiner’s remarks: Operating systems are a type of IPC framework.].
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Javre into the combined teachings of Schirner and Wang to include “wherein the second subset of vehicle-bus drivers comprises at least one of a second inter-processor communication (IPC) framework, a second functional safety framework, and a second Ethernet driver, or combinations thereof”. As stated in Javre, “APU 206 may include one or more cores. For purposes of discussion within this disclosure, a core is considered a “processor” that is configured to execute program code. RPU 208 may include one or more cores… Both APU 206 and RPU 208 may be directly connected to programmable circuitry 204 through isolation circuits 230-1 and 230-5, respectively.” (Paragraph [0041]). Both real-time response units and application units are well known in the art for executing program code. Drivers are well known in the art for facilitating communication and integrating different devices. Therefore, it would be obvious to one of ordinary skill in the art to combine embedded system updates with different device drivers split by function.
Regarding claim 8, the rejection of claim 1 is incorporated; and the combination of Schirner and Javre does not explicitly disclose:
- wherein the first vehicle communication protocol is a heritage vehicle communication protocol comprising at least one of a protocol used by a CAN bus, a protocol used by a LIN bus, and a protocol used by a FlexRay bus, or combinations thereof.
However, Wang discloses:
- wherein the first vehicle communication protocol is a heritage vehicle communication protocol comprising at least one of a protocol used by a CAN bus, a protocol used by a LIN bus, and a protocol used by a FlexRay bus, or combinations thereof (Paragraph [0021], “Communicatively coupled to the telematics unit 14 is a network connection interface 34, suitable examples of which include twisted pair/fiber optic Ethernet switch, internal/external parallel/serial communication bus, a local area network (LAN) interface, a controller area network (CAN), a media-oriented system transfer (MOST), a local interconnection network (LIN) interface, and the like”; Paragraph [0027], “While shown with two sensors 102, 104 communicating with two ECUs 108, 110 across a single CAN bus 106, it will be appreciated that the embedded control system 100 may comprise any two or more sensing devices communicating with any two or more control devices across multiple communication interfaces within the scope of this disclosure.”).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Wang into the combined teachings of Schirner and Javre to include “wherein the first vehicle communication protocol is a heritage vehicle communication protocol comprising at least one of a protocol used by a CAN bus, a protocol used by a LIN bus, and a protocol used by a FlexRay bus, or combinations thereof”. As stated in Wang, “Independently operating multiple ECUs and sensor arrays to produce and process the same data is inherently inefficient, resulting in superfluous component and function redundancies, amplified computational complexity and burden, and increased system hardware and software costs” (Paragraph [0005]). Allowing and encouraging ECU communication lessens inefficiencies. Furthermore, ECUs are a type of embedded system which may be combined with the update process for embedded systems described in Schirner. Therefore, it would be obvious to one of ordinary skill in the art to combine system updates with cross-ECU interaction.
Regarding claim 9, the rejection of claim 6 is incorporated; and the combination of Schirner and Javre does not explicitly disclose:
- wherein the second vehicle communication protocol is a newer vehicle communication protocol relative to the first vehicle communication protocol and comprises at least one of a Data Distribution Services (DDS) protocol, an Ethernet protocol, and a Time Sensitive Network (TSN) protocol, or combinations thereof.
However, Wang discloses:
- wherein the second vehicle communication protocol is a newer vehicle communication protocol relative to the first vehicle communication protocol and comprises at least one of a Data Distribution Services (DDS) protocol, an Ethernet protocol, and a Time Sensitive Network (TSN) protocol, or combinations thereof (Paragraph [0021], “Communicatively coupled to the telematics unit 14 is a network connection interface 34, suitable examples of which include twisted pair/fiber optic Ethernet switch, internal/external parallel/serial communication bus, a local area network (LAN) interface, a controller area network (CAN), a media-oriented system transfer (MOST), a local interconnection network (LIN) interface, and the like”; Paragraph [0027], “While shown with two sensors 102, 104 communicating with two ECUs 108, 110 across a single CAN bus 106, it will be appreciated that the embedded control system 100 may comprise any two or more sensing devices communicating with any two or more control devices across multiple communication interfaces within the scope of this disclosure.”).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Wang into the combined teachings of Schirner and Javre to include “wherein the second vehicle communication protocol is a newer vehicle communication protocol relative to the first vehicle communication protocol and comprises at least one of a Data Distribution Services (DDS) protocol, an Ethernet protocol, and a Time Sensitive Network (TSN) protocol, or combinations thereof”. As stated in Wang, “Independently operating multiple ECUs and sensor arrays to produce and process the same data is inherently inefficient, resulting in superfluous component and function redundancies, amplified computational complexity and burden, and increased system hardware and software costs” (Paragraph [0005]). Allowing and encouraging ECU communication lessens inefficiencies. Furthermore, ECUs are a type of embedded system which may be combined with the update process for embedded systems described in Schirner. Therefore, it would be obvious to one of ordinary skill in the art to combine system updates with cross-ECU interaction.
Regarding claim 10, the rejection of claim 7 is incorporated; and the combination of Schirner and Javre does not explicitly disclose:
- wherein the second vehicle communication protocol can be configured for use with a vehicle configured for autonomous driving.
However, Wang discloses:
- wherein the second vehicle communication protocol can be configured for use with a vehicle configured for autonomous driving (Paragraph [0003], “Original equipment manufacturers (OEM) are moving towards vehicle-to-vehicle (V2V) and vehicle-to-infrastructure (V2I) “talking” cars with higher-level driving automation that employ autonomous control systems to enable vehicle routing with steering, lane changing, scenario planning, etc”).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Wang into the combined teachings of Schirner and Javre to include “wherein the second vehicle communication protocol can be configured for use with a vehicle configured for autonomous driving”. As stated in Wang, “Current production motor vehicles, such as the modern-day automobile, are originally equipped with or retrofit to include a network of onboard electronic devices that provide automated driving capabilities that help to minimize driver effort” (Paragraph [0002]). Autonomous functions in vehicles are increasingly common in modern vehicles, lessening the impacts of human error. Allowing and encouraging ECU communication lessens inefficiencies. Furthermore, ECUs are a type of embedded system which may be combined with the update process for embedded systems described in Schirner. Therefore, it would be obvious to one of ordinary skill in the art to combine system updates with autonomous vehicles.
Regarding claim 11, the rejection of claim 1 is incorporated; and the combination of Schirner and Javre does not explicitly disclose:
- wherein a first ECU of the plurality comprises a sensor and a second ECU of the plurality comprises an automotive computational and communications engine, and wherein the method further comprises transferring, via the developed software, data generated by the sensor to the automotive computational and communications engine prior to transferring the data to other ECUs of the plurality.
However, Wang discloses:
- wherein a first ECU of the plurality comprises a sensor and a second ECU of the plurality comprises an automotive computational and communications engine, and wherein the method further comprises transferring, via the developed software, data generated by the sensor to the automotive computational and communications engine prior to transferring the data to other ECUs of the plurality (Paragraph [0007], “This representative method includes, in any order and in any combination with any of the above and below disclosed options and features: receiving a first data stream from a set of sensors via a first embedded controller; storing the first data stream with a respective timestamp and data lifespan via a shared data buffer in a resident memory device; receiving a second data stream from the set of sensors via a second embedded controller; … Responsive to the timing impact not violating the timing constraint, skipping the second sensor data reading of the set of sensors”).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Wang into the combined teachings of Schirner and Javre to include “wherein a first ECU of the plurality comprises a sensor and a second ECU of the plurality comprises an automotive computational and communications engine, and wherein the method further comprises transferring, via the developed software, data generated by the sensor to the automotive computational and communications engine prior to transferring the data to other ECUs of the plurality”. As stated in Wang, “Independently operating multiple ECUs and sensor arrays to produce and process the same data is inherently inefficient, resulting in superfluous component and function redundancies, amplified computational complexity and burden, and increased system hardware and software costs” (Paragraph [0005]). Allowing and encouraging ECU communication lessens inefficiencies. Furthermore, ECUs are a type of embedded system which may be combined with the update process for embedded systems described in Schirner. Therefore, it would be obvious to one of ordinary skill in the art to combine system updates with cross-ECU interaction.
Regarding claim 12, the rejection of claim 1 is incorporated; and Schirner further discloses:
- wherein the plurality of APIs comprises at least one of a data logging utility, a data analytics utility, a communication service utility, timing service utility, a security service utility, a cloud service utility, a diagnostic stack utility, a data distribution services utility, and an edge computing utility, or combinations thereof (Page 906, “To limit the interdependency between the code generation and the particular OS’s API we introduce a very thin RTOS Abstract Layer (RAL) that implements a common canonical API on top of the actual RTOS’s API”).
Regarding claim 13, the rejection of claim 1 is incorporated; and Schirner further discloses:
- wherein the platform further comprises a message conversion software engine, and wherein developing the software further comprises (Page 905, “The driver includes marshalling and demarshalling of user data to translate to and from a common untyped network data format”):
- receiving, via the message conversion software engine, files of varying formats from the plurality of [devices] (Page 905, “The driver includes marshalling and demarshalling of user data to translate to and from a common untyped network data format”) [Examiner’s remarks: The files (user data) is received in a variety of formats necessitating translation.]; and
- converting, via the message conversion software engine, the files into a universal format for development via the APIs of the service layer (Page 905, “The driver includes marshalling and demarshalling of user data to translate to and from a common untyped network data format”; Page 906, “To support multiple tasks executing on the same processor, HdS generation can adjust the task code to run on top of an off the-shelf RTOS. It replaces the abstract calls for task management in the TLM, with corresponding target implementations. To limit the interdependency between the code generation and the particular OS’s API we introduce a very thin RTOS Abstract Layer (RAL) that implements a common canonical API on top of the actual RTOS’s API”) [Examiner’s remarks: The files are translated into a universal format (common untyped network data format).].
Schirner discloses a method of updating embedded systems. Schirner does not disclose a plurality of ECUs or vehicles. However, Wang discloses communication with a plurality of ECUs (Paragraph [0021]; “The network connection interface 34 enables the vehicle hardware 16 to send and receive signals with each other and with various systems and subsyst