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 .
Response to Amendment
This action is in response to amendments and remarks filed on 10/27/2025. Claims 1-5 and 7-20 are considered in this office action. Claims 1 and 17 have been amended. Claims 1-5 and 7-20 are pending examination. Applicant's amendment necessitated new grounds of rejection therefore, claims 1-5 and 7-20 are rejected.
Response to Arguments
Applicant presents the following arguments regarding the previous office action:
Acharya and Teshler do not disclose, the SOA converter is configured to receive each of a configurable data and an implemented data in parallel, wherein the SOA converter is configured to receive each of data based on Controller Area Network (CAN) communication and configurable file data in the configurable data in parallel.
Regarding argument A with respect to the claims has been fully considered and is moot in light of new grounds for rejection below.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-5 and 6-20 are rejected as being unpatentable over Teshler et al. (US20190155650A1) in view of Acharya et al. (US20190268420A1), further in view of Dejarnatt et al. (EP1688836A1), further in view of EE Times (Vehicle bus analyzer decodes CAN in symbolic format).
Regarding claim 1, Teshler discloses, a vehicle communication device comprising: a gateway (Abstract, a service oriented architecture (SOA ECU), where the SOA ECU includes: at least one exemplary inventive SOA server; where the SOA ECU is located within a vehicle) … (0056, the exemplary inventive SOA ECU can be configured to also serve as a gateway between interconnected networks by running a gateway service), configured to perform data communication with a plurality of zone electronic control devices (Abstract, where the at least one SOA server is configured to provide at least one service to at least one client ECU that is located within the vehicle) based on a first communication scheme (0057, an Ethernet interface can connect the server to one vehicle network, such as the infotainment network which is based on Ethernet communication through a built in Gigabit Ethernet controller); and a service orchestrator (0015, the SOA ECU), configured to transmit data provided by a first zone electronic control device, which is a service provider (0045, in some embodiments the exemplary inventive SOA ECU can be used to securely collect, process store and/or transmit data from the vehicle to a service provider), among the plurality of zone electronic control devices to a second zone electronic control device, which is a service consumer (0023, the at least one SOA server is configured to provide at least one service to at least one client ECU). However, Teshler does not explicitly disclose, the service orchestrator includes a Service Oriented Architecture (SOA) converter for transmitting endpoint information in a configuration file format or in a stream format, wherein the SOA converter is configured to receive each of a configurable data and an implemented data in parallel, wherein the SOA converter is configured to receive each of data based on Controller Area Network (CAN) communication and configurable file data in the configurable data in parallel.
Nevertheless, Acharya who is in the same field of endeavor of multi-client architecture discloses, the stream format (0097, with regard to normal frames, streams may be used to separate data between different messages. In particular, the low level protocol may use streams to separate the data).
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 have modified Teshler’s disclosure to incorporate teachings of Acharya for the benefit of having a broker/coordinator that matches the provided and required service list, hands out endpoint addresses, and fails-over to a backup provider. The hardware disclosed in Teshler such as the CAN to Ethernet and LTE links, paired with the software logic of Acharya yields the predictable benefit of requiring fewer ECU’s therefore reducing cost.
Further justification for combining Teshler and Acharya’s disclosure not only come from the state-of-the-art but from Teshler (0076, in this regard, those of ordinary skill in the art are well versed in the type of computer hardware that may be used, the type of computer programming techniques that may be used (e.g., object oriented programming), and the type of computer programming languages that may be used (e.g., C++, Basic, AJAX, JavaScript). The aforementioned examples are, of course, illustrative and not restrictive) … (0098, many modifications may become apparent to those of ordinary skill in the art, including that the inventive).
Additionally, Dejarnatt who is in the same field of endeavor of configuring service and client runtimes discloses, the service orchestrator includes a Service Oriented Architecture (SOA) converter for transmitting endpoint information in a configuration file format (0007, in some environments, such as, for example, a service oriented architecture environment, connection endpoints (often and hereinafter referred to as "services") communicate with one another to implement desired functionality) … (0062, Service contract generator 113 can also store corresponding service configuration information, such as, for example, service endpoints, endpoint addresses, bindings, channel behaviors, in a service configuration file), wherein the SOA converter is configured to receive each of a configurable data (0040, Service loader 104 can also be configured to receive corresponding optional service configuration information), and an implemented data in parallel (0040, Generally, service loader 104 is configured to receive a service type (e.g., a Common Language Runtime ("CLR") type) or other object-oriented programming model object representing a network-based service).
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 have modified the combination of Teshler and Acharya disclosures to incorporate teachings of Dejarnatt for the benefit of automated endpoint provisioning, reduced manual integration, and improved interoperability of vehicle deployment. In the combined system the SOA services ECU would include an SOA converter that takes implemented service definition and configurable data in parallel .
Further justification for combining the combination of Teshler and Acharya with Dejarnatt not only come from the state-of-the-art but from Dejarnatt (0038, Those skilled in the art will appreciate that the invention may be practiced in network computing environments with many types of computer system configurations, including, personal computers, laptop computers, hand-held devices, multi-processor systems, microprocessor-based or programmable consumer electronics, network PCs, minicomputers, mainframe computers, mobile telephones, PDAs, pagers, and the like. The invention may also be practiced in distributed system environments where local and remote computer systems, which are linked).
Furthermore, EE Time who is in the same field of endeavor of vehicle bus analysis discloses, the SOA converter is configured to receive each of data based on Controller Area Network (CAN) communication and configurable file data in the configurable data (CAN Symbolic Triggering, Using a DBC database file that contains information pertinent to an operator's CAN messages and signals, you can now symbolically select a specific CAN message (such as ID) or signal (ID and DATA), and then apply a data condition for triggering), in parallel (Multi-Lane Decoding, it can decode up to four different CAN buses simultaneously).
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 have modified the combination of Teshler, Acharya, and Dejarnatt to incorporate teachings of EE Times, for the benefit of allowing the orchestrator to bridge CAN originated data into the SOA domain using configurable file driven interpretation which improves operability with the existing CAN based ECU’s, keeping the mapping flexible through configuration rather than coded logic.
Further justification for combining the combination of Teshler and Acharya with Dejarnatt not only come from the state-of-the-art but from Teshler (0098, many modifications may become apparent to those of ordinary skill in).
Regarding claim 2, Teshler, Acharya, Dejarnatt and EE Times disclose, the vehicle communication device of claim 1, as discussed supra. Additionally, Acharya discloses, in response to receiving a necessary service list from a first electronic control device and an available service list from a plurality of electronic control devices, the service orchestrator is configured to transmit a service, provided by any one of the plurality of electronic control devices, to the first electronic control device (0045, for example, responsive to receiving a message that is an “alert message”, the broker may determine, based on the one or more tables, the non-address indications (e.g., “ECU1”, “ECU2”, etc.) for all of the electronic devices that are registered to receive an “alert message”. The broker may then send the list of non-address indications (e.g., “ECU1”, “ECU2”, etc.) to the sender device).
Regarding claim 3, Teshler, Acharya, Dejarnatt and EE Times disclose, the vehicle communication device of claim 2, as discussed supra. Additionally, Teshler discloses the service orchestrator is configured to transmit a first configuration file to the first electronic control device (0063, these targeted ECU(s) would return the status of the operation (e.g. success, failure, errors, etc.) to the OTA service. The OTA service could combine all responses into a single list and send it back to the OEM server through the infotainment ECU), and transmit a second configuration file to any one of the plurality of electronic control devices (0063, after the update file would be validated, the OTA service would distribute it to all target ECU(s) to apply the update).
Regarding claim 4, Teshler, Acharya, Dejarnatt and EE Times disclose, the vehicle communication device of claim 2, as discussed supra. Additionally, Acharya discloses, in response to a service, provided by any one of the electronic control devices, being terminated (0252, at 1062, the broker acknowledges the disconnect request sent from the client device. At 1063, the broker terminates the connection. The termination of the connection may comprise any one or all of: removing the client device from lists managed by the broker for delivering messages; and sending a presence message indicating that the client device has terminated the connection), the service orchestrator is configured to transmit a service, provided by another one of the plurality of electronic control devices, to the first electronic control device (0040, the presence message may comprise: (1) a listing of the electronic devices that have registered with the broker (e.g., the non-address designation of the electronic device as indicated by the certificate associated with the electronic device).
Regarding claim 5, Teshler, Acharya, Dejarnatt and EE Times disclose, the vehicle communication device of claim 1, as discussed supra. Additionally, Acharya discloses, in response to receiving a request for information from the first electronic control device connected to the first zone electronic control device, and receiving information from the second electronic control device connected to the second zone electronic control device, the service orchestrator is configured to transmit endpoint information to the first electronic control device (0344, send, to the sender electronic device, the non-address indications for each of the electronic devices in the subset) … (0037, the broker, in response to receipt of the message, may identify the addresses of the electronic devices that are entitled to receive the type of message, and route accordingly).
Regarding claim 7, Teshler, Acharya, Dejarnatt and EE Times disclose, the vehicle communication device of claim 5, as discussed supra. Additionally, Acharya discloses, the first electronic control device directly receives the information based on the endpoint information (0037, the broker, in response to receipt of the message, may identify the addresses of the electronic devices that are entitled to receive the type of message, and route accordingly).
Regarding claim 8, Teshler, Acharya, Dejarnatt and EE Times disclose, the vehicle communication device of claim 5, as discussed supra. Additionally, Acharya discloses, the service orchestrator is configured to monitor whether the second electronic control device periodically provides the information or data to the first electronic control device (0086, with regard to connectivity testing, the client, within certain intervals, may conduct a connection test (e.g., when underlying connection requires so). The connectivity testing is not required; however, the client may incur a higher risk of encountering a dead connection when a message needs to be sent. In this regard, the connectivity testing may be performed in advance of sending a message in order to determine whether the connection is active).
Regarding claim 9, Teshler, Acharya, Dejarnatt and EE Times disclose, the vehicle communication device of claim 5, as discussed supra. Additionally, Acharya discloses, the information comprises vehicle speed data (0325, as another example, the driver may be traveling at 55 MPH. The weather is partly cloudy, with good visibility and good traffic conditions. Given the increase in speed of the vehicle, the controller may determine that the car safe level is 6 (e.g., indicative of acceptable driving conditions). In response to the eSync Client device determining that the car safe level is 6, the eSync Client device may determine to temporarily delay performing the update), or camera data (0177, various devices with vehicle 501 may communicate with Gateway—1 (540) including: headunit 512, 1Gb camera 514).
Regarding claim 10, Teshler, Acharya, Dejarnatt and EE Times disclose, the vehicle communication device of claim 5, as discussed supra. Additionally, Acharya discloses, the second zone electronic control device is configured to process information received from the second electronic control device (0177, gateway—1 (540) acts as a conduit to the OTA server 402, relaying communications to different devices, such as Gateway—2 (550). Various devices with vehicle 501 may communicate with Gateway—1 (540)), and transmit the processed information to the first electronic control device (0172, ECU 10 (334) does not include an update agent, and may thus rely on update agent 344 in DoIP gateway 342 to perform a software update for software resident in ECU 10 (334)).
Regarding claim 11, Teshler, Acharya, Dejarnatt and EE Times disclose, the vehicle communication device of claim 5, as discussed supra. Additionally, Teshler discloses, the first communication scheme which is faster than the second communication scheme (0057, such exemplary set-up can have 1 GB of DDR3 RAM and 4GB of flash SSD, providing the operational and storage memory for the inventive system. An Ethernet interface can connect the server to one vehicle network, such as the infotainment network which is based on Ethernet communication) … (0057, CAN with Flexible Data-Rate (CAN FD - ISO 11898-1:2015) with support for high speed communication above 1 Mbps). However Teshler does not explicitly disclose, the second electronic control device is configured to receive the information from a sensor device based on a second communication scheme, and transmit the received information to the second zone electronic control device based on the first communication scheme wherein the second zone electronic control device is configured to transmit the received information to the gateway based on the first communication scheme.
Nevertheless, Acharya discloses, the second electronic control device is configured to receive the information from a sensor device based on a second communication scheme, (0177, various devices with vehicle 501 may communicate with Gateway—1 (540) including … one or more sensors (e.g., for Radar) 544, and one or more CAN ECUs 546, 548), and transmit the received information to the second zone electronic control device based on the first communication scheme (0047, the eSync bus protocol enables inter-device (such as inter-ECU or ECU to eSync Client Module) communication across buses of different types (e.g., one or more devices sitting on the CAN bus communicating with one or more devices sitting on the Ethernet bus), wherein the second zone electronic control device is configured to transmit the received information to the gateway based on the first communication scheme (0179, smart antenna or telematics control unit (TCU) 612 may communicate with an Ethernet gateway 630, which in turn may communicate with other devices, such as … vehicle body CAN gateway 670 (which in turn is in communication with body control ECU 680 and engine control ECU 690)).
Regarding claim 12, Teshler, Acharya, Dejarnatt and EE Times disclose, the vehicle communication device of claim 11, as discussed supra. Additionally, Teshler discloses, the gateway performs data communication with a cloud or server based on a third communication scheme which is a wireless communication scheme (0059, OTA updates can be communicated (from the automotive OEM remote update server) via an external wireless communication interface (e.g., 3G cellular) which would be connected to the infotainment ECU (or the infotainment head unit ECU), and is different from the first and second communication schemes which are wired communication schemes (0059, updates can be received by the OTA service and disseminated to the other interconnected networks (according to the set of ECUs which are relevant to the specific update)).
Regarding claim 13, Teshler, Acharya, Dejarnatt and EE Times, disclose, the vehicle communication device of claim 1, as discussed supra. Additionally Teshler discloses, the service orchestrator is configured to manage network configuration for the plurality of zone electronic control devices (0059, in some embodiments, the exemplary inventive computer system with the exemplary inventive SOA ECU can be configured to utilize any suitable communication protocol to communicate with other ECUs (e.g., LIN, FlexRay, MOST, etc.). In some embodiments, the exemplary inventive SOA ECU can be configured such that the microkernel secures access to hardware resources (e.g. communication interfaces, cryptographic co-processor, etc.)).
Regarding claim 14, Teshler, Acharya, Dejarnatt and EE Times disclose, the vehicle communication device of claim 1, as discussed supra. Additionally Teshler discloses, the service orchestrator is configured to: dynamically control services which are necessary or available between the service provider and the service consumer in the plurality of zone electronic control devices; (0015, in some embodiments, the SOA ECU is further configured to allow for at least one of: i) introducing at least one real-time first approved software change into the SOA ECU, ii) introducing at least one real-time second approved change into the at least one SOA server, and iii) introducing at least one real-time third approved change in the at least one service), or scan and adjust all services within a network domain, (0016, in some embodiments, the at least one real-time second approved change is at least one of: 1) adding, in real-time, at least one new service to the at least one SOA server)), and provide a new or changed service (0016, 2) replacing, in real-time, the at least one service with the at least one new service, 3) removing, in real-time, the at least one service from the at least one SOA server, and 4) changing, in real-time, the configuration of the at least one SOA server).
Regarding claim 15, Teshler, Acharya, Dejarnatt and EE Times disclose, the vehicle communication device of claim 1, as discussed supra. Additionally, Acharya discloses, in response to receiving vehicle speed data from the second electronic control device connected to the second zone electronic control device, and receiving a request for the vehicle speed data from the first electronic control device connected to the first zone electronic control device, the service orchestrator is configured to transmit the endpoint information to the first electronic control device (0325, as another example, the driver may be traveling at 55 MPH. The weather is partly cloudy, with good visibility and good traffic conditions. Given the increase in speed of the vehicle, the controller may determine that the car safe level is 6 (e.g., indicative of acceptable driving conditions). In response to the eSync Client device determining that the car safe level is 6, the eSync Client device may determine to temporarily delay performing the update) … (0240, at 1010, the sender requests destinations from the broker. As discussed above, different address types are contemplated, such as special addresses, update agent addresses, group addresses, etc.) … (0241, responsive to sending the destination request, the broker may send the destinations).
Regarding claim 16, Teshler, Acharya, Dejarnatt and EE Times disclose, the vehicle communication device of claim 1, as discussed supra. Additionally, Acharya discloses, in response to receiving camera data, radar data, or lidar data from the second electronic control device connected to the second zone electronic control device, and receiving a request for the camera data, radar data, or lidar data from the first electronic control device connected to the first zone electronic control device, the service orchestrator is configured to transmit the endpoint information to the first electronic control device (0177, various devices with vehicle 501 may communicate with Gateway—1 (540) including: headunit 512, 1Gb camera 514) … (0240, at 1010, the sender requests destinations from the broker. As discussed above, different address types are contemplated, such as special addresses, update agent addresses, group addresses, etc.) … (0241, responsive to sending the destination request, the broker may send the destinations).
Regarding claim 17, Teshler, Acharya, Dejarnatt and EE Times disclose, a vehicle comprising a vehicle communication device (0004, the SOA ECU is located within a vehicle), wherein the vehicle communication device comprises: a gateway configured to perform data communication with a plurality of zone electronic control devices (0056, SOA ECU can be configured to also serve as a gateway between interconnected networks by running a gateway service. In some embodiments, the exemplary inventive SOA ECU can be configured to connect directly to the gateway ECU (as if it is a separate subnetwork)), based on a first communication scheme (0057, an Ethernet interface can connect the server to one vehicle network), and a service orchestrator configured to transmit data provided by a first zone electronic control device (0004, the at least one SOA server is configured to provide at least one service), which is a service provider, among the plurality of zone electronic control devices to a second zone electronic control device, which is a service consumer (0004, to at least one client ECU that is located within the vehicle; and where the at least one SOA server is configured to assign at least one dedicated processing resource and at least one dedicated memory resource to provide the at least one service).
However, Teshler does not explicitly disclose, the service orchestrator includes a Service Oriented Architecture (SOA) converter for transmitting endpoint information in a configuration file format or in a stream format, wherein the SOA converter is configured to receive each of a configurable data and an implemented data in parallel, wherein the SOA converter is configured to receive each of data based on Controller Area Network (CAN) communication and configurable file data in the configurable data in parallel.
Nevertheless, Acharya discloses, the stream format (0097, with regard to normal frames, streams may be used to separate data between different messages. In particular, the low level protocol may use streams to separate the data).
Additionally, Dejarnatt discloses, the service orchestrator includes a Service Oriented Architecture (SOA) converter for transmitting endpoint information in a configuration file format (0007, in some environments, such as, for example, a service oriented architecture environment, connection endpoints (often and hereinafter referred to as "services") communicate with one another to implement desired functionality) … (0062, Service contract generator 113 can also store corresponding service configuration information, such as, for example, service endpoints, endpoint addresses, bindings, channel behaviors, in a service configuration file), wherein the SOA converter is configured to receive each of a configurable data (0040, Service loader 104 can also be configured to receive corresponding optional service configuration information), and an implemented data in parallel (0040, Generally, service loader 104 is configured to receive a service type (e.g., a Common Language Runtime ("CLR") type) or other object-oriented programming model object representing a network-based service).
Furthermore, EE Times discloses, the SOA converter is configured to receive each of data based on Controller Area Network (CAN) communication and configurable file data in the configurable data (CAN Symbolic Triggering, Using a DBC database file that contains information pertinent to an operator's CAN messages and signals, you can now symbolically select a specific CAN message (such as ID) or signal (ID and DATA), and then apply a data condition for triggering), in parallel (Multi-Lane Decoding, it can decode up to four different CAN buses simultaneously).
Regarding claim 18, Teshler, Acharya, Dejarnatt and EE Times disclose, the vehicle of claim 17, as discussed supra. Additionally, Acharya discloses, in response to receiving a necessary service list from a first electronic control device and an available service list from a plurality of electronic control devices, the service orchestrator is configured to transmit a service (0077, the following is one example of a sequence for communications between the sender and the broker when sending a message: sender requests destinations from the broker), provided by any one of the plurality of electronic control devices, to the first electronic control device (0043, the broker may send the non-address indications of the recipients (e.g., “ECU1”, “ECU2”, etc.) back to the sender, with the sender then sending subsequent messages with the non-address indications for later routing).
Regarding claim 19, Teshler, Acharya, Dejarnatt and EE Times disclose, the vehicle of claim 17, as discussed supra. Additionally, Acharya discloses, in response to receiving a request for information from the first electronic control device connected to the first zone electronic control device, and receiving information from the second electronic control device connected to the second zone electronic control device, (0241, the sender may request the certificate from another device, such as a certification authority. Responsive to receiving/accessing the certificate details, at 1012, the sender may authenticate at least one aspect of the certificate. As one example, the sender may authenticate the certificates for each of the destination addresses), the service orchestrator is configured to transmit endpoint information to the first electronic control device (0043, in a second implementation, the broker may send the non-address indications of the recipients (e.g., “ECU1”, “ECU2”, etc.) back to the sender, with the sender then sending subsequent messages with the non-address indications for later routing).
Regarding claim 20, Teshler, Acharya, Dejarnatt and EE Times disclose, the vehicle of claim 17, as discussed supra. Additionally, Acharya discloses, in response to receiving vehicle speed data from the second electronic control device connected to the second zone electronic control device, and receiving a request for the vehicle speed data from the first electronic control device connected to the first zone electronic control device, the service orchestrator is configured to transmit the endpoint information to the first electronic control device (0325, as another example, the driver may be traveling at 55 MPH. The weather is partly cloudy, with good visibility and good traffic conditions. Given the increase in speed of the vehicle, the controller may determine that the car safe level is 6 (e.g., indicative of acceptable driving conditions). In response to the eSync Client device determining that the car safe level is 6, the eSync Client device may determine to temporarily delay performing the update) … (0240, at 1010, the sender requests destinations from the broker. As discussed above, different address types are contemplated, such as special addresses, update agent addresses, group addresses, etc.) … (0241, responsive to sending the destination request, the broker may send the destinations).
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SHANE E DOUGLAS whose telephone number is (703)756-1417. The examiner can normally be reached Monday - Friday 7:30AM - 5:00PM.
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, Christian Chace can be reached on (571) 272-4190. 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.
/S.E.D./Examiner, Art Unit 3665
/CHRISTIAN CHACE/Supervisory Patent Examiner, Art Unit 3665