Detailed Office Action
Status of Claims
This Office Action is in response to the Applicant’s amendments and remarks filed 02/23/2026. The applicant has amended claims 1, 2, 6, 8-14, and 17. Claims 1-17 are presently pending and are presented for examination.
Response to Amendment
The amendment filed 02/23/2026 has been entered. Claims 1-17 remain pending in the application.
Reply to Applicant’s Remarks
Applicant’s remarks filed 02/23/2026 have been fully considered and are addressed as follows:
Claim Interpretation Under U.S.C. 112(f):
Applicant’s amendments to the claims filed 02/23/2026 have overcome the 35 U.S.C. 112(f) interpretation previously set forth. Therefore the Claims are no longer invoke 112(f).
Claim Rejections Under 35 U.S.C. 101:
Applicant’s amendments to the claims filed 02/23/2026 have overcome the 35 U.S.C. 101 rejections previously set forth. Therefore, the rejection has been withdrawn.
Claim Rejections Under 35 U.S.C. 103:
Applicant’s arguments, see Arguments/Remarks, filed 02/23/2026, with regard to the rejections of Claims 1, 11, 12, 13, and 17 under 35 U.S.C. 103 have been fully considered and are persuasive. Therefore, the rejection has been withdrawn. However, upon further consideration, a new ground(s) of rejection is made in view of newly found prior art reference(s).
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.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1, 11, 12, 13, 14 and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Mason et al (US 20130338855 A1) in view of Hiroki et al (JP 6414457 B2) and Rust et al (US 20170192423 A1). Hereafter referred to as Mason, Hiroki, and Rust respectively.
Regarding Claim 1, Mason teaches an in-vehicle device mounted in a vehicle, the in-vehicle device comprising: at least one first processor; and at least one first memory storing first computer program code (see at least Mason [¶ 88] FIG. 2 illustrates an embodiment of a gateway module 205. The gateway module 205 is a more detailed embodiment of an in-vehicle device 104 described above and includes all the features thereof. The gateway module 205 can be a vehicle based data acquisition and transmission sub-system. In the depicted embodiment, the gateway module 205 has a processor 210, memory 215, a wireless adapter 220, and one or more sensors 225)
a normalization portion that is configured to normalize a plurality of pieces of vehicle data acquired from...the vehicle (see at least Mason [¶ 21, 25, 92, 93] the raw measurement data can be processed to standardize or normalize the data into a format that the various components of the vehicle management system can decode and process, and this standardized measurement data can be stored...The gateway module 205 can, among other things, analyze, categorize, compress, or otherwise process the data before transmitting it to the vehicle management system 110...The gateway module 205 can be in communication with some or all of the in-vehicle sensors 230. For example, the gateway module 205 can be coupled to an OBDII or CAN bus in the vehicle to thereby receive in-vehicle sensor information from the engine computer. In some embodiments, one or more in-vehicle sensors can be directly coupled to the gateway module 205, or the gateway module 205 can be configured to communicate wirelessly with the in-vehicle sensors) The gateway module may process the data before transmitting it to the vehicle management system. Mason, additionally describes how the processing of data can be used to standardize or normalize data into a format that the vehicle management system can decode and process. Therefore the gateway module is analogous to the in-vehicle normalization portion and the vehicle management system is analogous to the center
a data structuring portion that is configured to structure the plurality of pieces of the vehicle data that are normalized by the normalization portion into a predetermined data structure (see at least Mason [¶ 75, 93] multiple types of data structures can be used to organize the ranking of measurements. The data structures used can, for instance, be any hierarchical data structure. In some embodiments, a dependency tree data structure is used to organize the ranking of potential measurements for a given piece of information.....The gateway module 205 can, among other things, analyze, categorize, compress, or otherwise process the data before transmitting it to the vehicle management system 110. By preprocessing the data prior to sending the information to the vehicle management system 110, the gateway module 205 can determine what data to send to the vehicle management system 110, which can reduce redundant processing and bandwidth used to continually transmit vehicle data) The gateway module categorizes and processes data before sending it to the vehicle management system, which is analogous to structuring pieces of data. Mason additionally discusses the use of multiple types of predetermined data structures specifically used to organize ranking of measurements
a data transmission portion that is configured to transmit the plurality of pieces of the vehicle data that are structured by the data structuring portion to a center configured to manage the plurality of pieces of the vehicle data through a communicator (see at least Mason [¶ 25, 89, 93] one or more in-vehicle devices 104 and management devices 106 communicate with the vehicle management system 110 over a network 108. The in-vehicle devices 104 can include computing devices installed in fleet vehicles…The radio 240 can transmit data received from the gateway module 205 to the vehicle management system 110. The radio 240 can also communicate vehicle positioning data received from the GPS module 245 to the vehicle management system 110. In one embodiment, the radio 240 communicates with the vehicle management system by placing a cell phone call to a server of the vehicle management system 110. The radio 240 can also communicate with the server at the vehicle management system 110 by connecting to the network 108 using TCP/IP/UDP protocols. By sending data frequently or periodically, the radio 240 can maintain the connection to the server open, which can guarantee or help to guarantee data reliability....The gateway module 205 can, among other things, analyze, categorize, compress, or otherwise process the data before transmitting it to the vehicle management system 110. By preprocessing the data prior to sending the information to the vehicle management system 110, the gateway module 205 can determine what data to send to the vehicle management system 110, which can reduce redundant processing and bandwidth used to continually transmit vehicle data).
However, while Mason teaches a normalization portion that is configured to normalize a plurality of pieces of the vehicle data acquired from...the vehicle (see at least Mason [¶ 21, 93, 92]) it does not explicitly teach wherein the vehicle data is acquired from an electronic control unit mounted in the vehicle.
Hiroki, in the same field as the endeavor teaches a normalization portion that is configured to normalize a plurality of pieces of the vehicle data acquired from an electronic control unit mounted in the vehicle (see at least Hiroki [English Translation pg.16 para.6] When the vehicle-mounted device (3) indicates that the state of the vehicle (4) transmitted from the vehicle ECU (23) is abnormal, the vehicle-mounted device (3) normalizes the state of the vehicle (4) based on the abnormal state information)
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention to have modified the system set forth in Mason to contain a system for acquiring vehicle data from an ECU mounted in the vehicle with reasonable expectation of success. One of ordinary skill in the art would have been motivated to make such a modification for benefit of including a conventional and reliable way to access vehicle data using hardware that is commonplace in the art.
Further, Mason does not explicitly teach wherein the center includes at least one second processor and at least one second memory storing second computer program code that, when executed by the at least one second processor, causes the at least one second processor to:
receive a control instruction from a service providing server and to control the vehicle by sending the control instruction to the in-vehicle device, the control instruction being generated by the service providing server based on at least one of the plurality of pieces of the vehicle data stored by the center; and
the at least one first processor controls the vehicle based on the control instruction received from the center.
Rust, in the same field as the endeavor, teaches wherein the center includes at least one second processor and at least one second memory storing second computer program code (see at least Rust [¶ 13-18, 100] As shown in FIG. 1, a system 100 for remotely assisting autonomous vehicle operation includes an onboard computer 110...The system 100 functions to enable remote assistance to augment the intelligence of the onboard computer of an autonomous vehicle....The system 100 enables the onboard computer 110 to request assistance from another source...an artificially-intelligent expert 140… a system 300 for remotely assisting autonomous vehicle operation and updating operation systems of a fleet of autonomous vehicles is illustrated. System 300 includes a plurality of autonomous vehicles 310, a remote assistance server (e.g., expert mode server) 320, a global server (e.g., fleet server) 330, an artificial intelligence server 340)…global server 330 and the artificial intelligence server 340 may be combined to enable additional processing efficiencies) The remote assistance server/artificial intelligence server are analogous to a remote center that includes at least one processor and one memory
that, when executed by the at least one second processor, causes the at least one second processor to:
receive a control instruction from a service providing server and to control the vehicle by sending the control instruction to the in-vehicle device, the control instruction being generated by the service providing server based on at least one of the plurality of pieces of the vehicle data stored by the center (see at least Rust [¶ 18, 33, 102-103, 110] A remote assistance subsystem of the system 300 includes the primary components including a computing client (e.g., client code executed by an onboard computer) operating on each autonomous vehicle 310, the remote assistance server 320, and a human expert interface 120 (e.g., a human expert terminal). The remote assistance subsystem optionally includes the artificial intelligence server 340 and AI expert 140....The computing client functions to aggregated data from the operation systems of the autonomous vehicle information and communicate the aggregated data to the remote assistance server 320 in various circumstances including during an assistance-desired scenario. Additionally, the computing client functions to receive commands from the remote assistance server including commands for controlling one or more operations of the vehicle (e.g., remote driving of the autonomous vehicle)....any rerouting calculated by the…AI expert 140 must be done in light of the blacklist information; meaning, that during rerouting calculating a mapping or routing database will generally indicate a list of lanes, routes, or traveling paths as blacklisted or otherwise, unavailable for traveling by the autonomous vehicle) The onboard computing client may receive commands for controlling the driving of the vehicle when assistance is required, the commands are based on data stored in the servers such as databases for blacklisted paths
the at least one first processor controls the vehicle based on the control instruction received from the center (see at least Rust [¶ 21, 102, 103] The onboard computer no functions to control an autonomous vehicle…the onboard computer 110 preferably modifies or controls behavior of the autonomous vehicle....remote assistance subsystem of the system 300 includes the primary components including a computing client (e.g., client code executed by an onboard computer) operating on each autonomous vehicle 310...the computing client functions to receive commands from the remote assistance server including commands for controlling one or more operations of the vehicle (e.g., remote driving of the autonomous vehicle)).
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention to have modified the system set forth in Mason to contain a system for wherein the center includes at least one second processor and at least one second memory storing second computer program code that, when executed by the at least one second processor, causes the at least one second processor to: receive a control instruction from a service providing server and to control the vehicle by sending the control instruction to the in-vehicle device, the control instruction being generated by the service providing server based on at least one of the plurality of pieces of the vehicle data stored by the center; and the at least one first processor controls the vehicle based on the control instruction received from the center with reasonable expectation of success. One of ordinary skill in the art would have been motivated to make such a modification for benefit of improving safety of the vehicle by augmenting its control using remote computing power as discussed in Rust (see at least Rust [¶ 43] The method 200 functions to enable onboard computing systems of autonomous vehicles to identify scenarios in which vehicle operation may be improved and/or made safer by remote assistance, and to efficiently request and receive remote assistance in these scenarios).
Regarding Claim 11, Mason teaches A data generation method implemented by an in-vehicle device that is mounted in a vehicle and includes a unit that is configured to communicate data with a center configured to manage vehicle data (see at least Mason [¶ 88, 25] FIG. 2 illustrates an embodiment of a gateway module 205. The gateway module 205 is a more detailed embodiment of an in-vehicle device 104 described above and includes all the features thereof. The gateway module 205 can be a vehicle based data acquisition and transmission sub-system. In the depicted embodiment, the gateway module 205 has a processor 210, memory 215, a wireless adapter 220, and one or more sensors 225…one or more in-vehicle devices 104 and management devices 106 communicate with the vehicle management system 110 over a network 108. The in-vehicle devices 104 can include computing devices installed in fleet vehicles)
the method comprising:
normalizing a plurality of pieces of the vehicle data acquired from…the vehicle (see at least Mason [¶ 21, 92, 93] the raw measurement data can be processed to standardize or normalize the data into a format that the various components of the vehicle management system can decode and process, and this standardized measurement data can be stored...The gateway module 205 can, among other things, analyze, categorize, compress, or otherwise process the data before transmitting it to the vehicle management system 110...The gateway module 205 can be in communication with some or all of the in-vehicle sensors 230. For example, the gateway module 205 can be coupled to an OBDII or CAN bus in the vehicle to thereby receive in-vehicle sensor information from the engine computer. In some embodiments, one or more in-vehicle sensors can be directly coupled to the gateway module 205, or the gateway module 205 can be configured to communicate wirelessly with the in-vehicle sensors) The gateway module may process the data before transmitting it to the vehicle management system. Mason, additionally describes how the processing of data can be used to standardize or normalize data into a format that the vehicle management system can decode and process. Therefore the gateway module is analogous to the in-vehicle normalization portion and the vehicle management system is analogous to the center
structuring the plurality of pieces of the vehicle data that are normalized into a predetermined data structure (see at least Mason [¶ 75, 93] multiple types of data structures can be used to organize the ranking of measurements. The data structures used can, for instance, be any hierarchical data structure. In some embodiments, a dependency tree data structure is used to organize the ranking of potential measurements for a given piece of information.....The gateway module 205 can, among other things, analyze, categorize, compress, or otherwise process the data before transmitting it to the vehicle management system 110. By preprocessing the data prior to sending the information to the vehicle management system 110, the gateway module 205 can determine what data to send to the vehicle management system 110, which can reduce redundant processing and bandwidth used to continually transmit vehicle data) The gateway module categorizes and processes data before sending it to the vehicle management system, which is analogous to structuring pieces of data. Mason additionally discusses the use of multiple types of predetermined data structures specifically used to organize ranking of measurements
transmitting, with the unit, the plurality of pieces of the vehicle data that are structured to the center through a communicator (see at least Mason [¶ 89, 93] The radio 240 can transmit data received from the gateway module 205 to the vehicle management system 110. The radio 240 can also communicate vehicle positioning data received from the GPS module 245 to the vehicle management system 110. In one embodiment, the radio 240 communicates with the vehicle management system by placing a cell phone call to a server of the vehicle management system 110. The radio 240 can also communicate with the server at the vehicle management system 110 by connecting to the network 108 using TCP/IP/UDP protocols. By sending data frequently or periodically, the radio 240 can maintain the connection to the server open, which can guarantee or help to guarantee data reliability....The gateway module 205 can, among other things, analyze, categorize, compress, or otherwise process the data before transmitting it to the vehicle management system 110. By preprocessing the data prior to sending the information to the vehicle management system 110, the gateway module 205 can determine what data to send to the vehicle management system 110, which can reduce redundant processing and bandwidth used to continually transmit vehicle data).
However, while Mason teaches normalizing a plurality of pieces of the vehicle data acquired from...the vehicle (see at least Mason [¶ 21, 93, 92]) it does not explicitly teach wherein the vehicle data is acquired from an electronic control unit mounted in the vehicle.
Hiroki, in the same field as the endeavor teaches normalizing a plurality of pieces of the vehicle data acquired from an electronic control unit mounted in the vehicle (see at least Hiroki [English Translation pg.16 para.6] When the vehicle-mounted device (3) indicates that the state of the vehicle (4) transmitted from the vehicle ECU (23) is abnormal, the vehicle-mounted device (3) normalizes the state of the vehicle (4) based on the abnormal state information)
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention to have modified the system set forth in Mason to contain a system for acquiring vehicle data from an ECU mounted in the vehicle with reasonable expectation of success. One of ordinary skill in the art would have been motivated to make such a modification for benefit of including a conventional and reliable way to access vehicle data using hardware that is commonplace in the art.
Further, Mason does not explicitly teach wherein:
the center receives a control instruction from a service providing server and controls the vehicle by sending the control instruction to the in-vehicle device, the control instruction being generated by the service providing server based on at least one of the plurality of pieces of the vehicle data stored by the center; and
the in-vehicle device controls the vehicle based on the control instruction received from the center.
Rust, in the same field as the endeavor, teaches wherein the center receives a control instruction from a service providing server and controls the vehicle by sending the control instruction to the in-vehicle device, the control instruction being generated by the service providing server based on at least one of the plurality of pieces of the vehicle data stored by the center (see at least Rust [¶ 18, 33, 102-103, 110] A remote assistance subsystem of the system 300 includes the primary components including a computing client (e.g., client code executed by an onboard computer) operating on each autonomous vehicle 310, the remote assistance server 320, and a human expert interface 120 (e.g., a human expert terminal). The remote assistance subsystem optionally includes the artificial intelligence server 340 and AI expert 140....The computing client functions to aggregated data from the operation systems of the autonomous vehicle information and communicate the aggregated data to the remote assistance server 320 in various circumstances including during an assistance-desired scenario. Additionally, the computing client functions to receive commands from the remote assistance server including commands for controlling one or more operations of the vehicle (e.g., remote driving of the autonomous vehicle)....any rerouting calculated by the…AI expert 140 must be done in light of the blacklist information; meaning, that during rerouting calculating a mapping or routing database will generally indicate a list of lanes, routes, or traveling paths as blacklisted or otherwise, unavailable for traveling by the autonomous vehicle) The onboard computing client may receive commands for controlling the driving of the vehicle when assistance is required, the commands are based on data stored in the servers such as databases for blacklisted paths
the in-vehicle device controls the vehicle based on the control instruction received from the center (see at least Rust [¶ 21, 102, 103] The onboard computer no functions to control an autonomous vehicle…the onboard computer 110 preferably modifies or controls behavior of the autonomous vehicle....remote assistance subsystem of the system 300 includes the primary components including a computing client (e.g., client code executed by an onboard computer) operating on each autonomous vehicle 310...the computing client functions to receive commands from the remote assistance server including commands for controlling one or more operations of the vehicle (e.g., remote driving of the autonomous vehicle)).
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention to have modified the system set forth in Mason to contain a system for wherein: the center receives a control instruction from a service providing server and controls the vehicle by sending the control instruction to the in-vehicle device, the control instruction being generated by the service providing server based on at least one of the plurality of pieces of the vehicle data stored by the center; and the in-vehicle device controls the vehicle based on the control instruction received from the center with reasonable expectation of success. One of ordinary skill in the art would have been motivated to make such a modification for benefit of improving safety of the vehicle by augmenting its control using remote computing power as discussed in Rust (see at least Rust [¶ 43] The method 200 functions to enable onboard computing systems of autonomous vehicles to identify scenarios in which vehicle operation may be improved and/or made safer by remote assistance, and to efficiently request and receive remote assistance in these scenarios).
Regarding Claim 12, Mason teaches a non-transitory, tangible storage medium for storing a data generation program for an in-vehicle device that is mounted in a vehicle and includes a unit that is configured to communicate data with a center configured to manage vehicle data (see at least Mason [¶ 08, 88, 25] non-transitory physical computer storage including instructions stored thereon for implementing, in one or more processors, a method for presenting fleet vehicle operation information in standardized forms, the method including: accessing measurements related to operation of a plurality of vehicles in a fleet of vehicles; using a first technique, estimating a first value for a parameter for at least one vehicle of the plurality of vehicles based at least on one or more of the measurements, the parameter indicative of diagnostic information… FIG. 2 illustrates an embodiment of a gateway module 205. The gateway module 205 is a more detailed embodiment of an in-vehicle device 104 described above and includes all the features thereof. The gateway module 205 can be a vehicle based data acquisition and transmission sub-system. In the depicted embodiment, the gateway module 205 has a processor 210, memory 215, a wireless adapter 220, and one or more sensors 225…one or more in-vehicle devices 104 and management devices 106 communicate with the vehicle management system 110 over a network 108. The in-vehicle devices 104 can include computing devices installed in fleet vehicles)
the data generation program, when executed by a computer of the in-vehicle device, causing the computer to:
normalize a plurality of pieces of the vehicle data acquired from…the vehicle (see at least Mason [¶ 21, 92, 93] the raw measurement data can be processed to standardize or normalize the data into a format that the various components of the vehicle management system can decode and process, and this standardized measurement data can be stored...The gateway module 205 can, among other things, analyze, categorize, compress, or otherwise process the data before transmitting it to the vehicle management system 110...The gateway module 205 can be in communication with some or all of the in-vehicle sensors 230. For example, the gateway module 205 can be coupled to an OBDII or CAN bus in the vehicle to thereby receive in-vehicle sensor information from the engine computer. In some embodiments, one or more in-vehicle sensors can be directly coupled to the gateway module 205, or the gateway module 205 can be configured to communicate wirelessly with the in-vehicle sensors) The gateway module may process the data before transmitting it to the vehicle management system. Mason, additionally describes how the processing of data can be used to standardize or normalize data into a format that the vehicle management system can decode and process. Therefore the gateway module is analogous to the in-vehicle normalization portion and the vehicle management system is analogous to the center
structure the plurality of pieces of the vehicle data that are normalized into a predetermined data structure (see at least Mason [¶ 75, 93] multiple types of data structures can be used to organize the ranking of measurements. The data structures used can, for instance, be any hierarchical data structure. In some embodiments, a dependency tree data structure is used to organize the ranking of potential measurements for a given piece of information.....The gateway module 205 can, among other things, analyze, categorize, compress, or otherwise process the data before transmitting it to the vehicle management system 110. By preprocessing the data prior to sending the information to the vehicle management system 110, the gateway module 205 can determine what data to send to the vehicle management system 110, which can reduce redundant processing and bandwidth used to continually transmit vehicle data) The gateway module categorizes and processes data before sending it to the vehicle management system, which is analogous to structuring pieces of data. Mason additionally discusses the use of multiple types of predetermined data structures specifically used to organize ranking of measurements
cause the unit to transmit the plurality of pieces of the vehicle data that are structured to the center through a communicator (see at least Mason [¶ 89, 93] The radio 240 can transmit data received from the gateway module 205 to the vehicle management system 110. The radio 240 can also communicate vehicle positioning data received from the GPS module 245 to the vehicle management system 110. In one embodiment, the radio 240 communicates with the vehicle management system by placing a cell phone call to a server of the vehicle management system 110. The radio 240 can also communicate with the server at the vehicle management system 110 by connecting to the network 108 using TCP/IP/UDP protocols. By sending data frequently or periodically, the radio 240 can maintain the connection to the server open, which can guarantee or help to guarantee data reliability....The gateway module 205 can, among other things, analyze, categorize, compress, or otherwise process the data before transmitting it to the vehicle management system 110. By preprocessing the data prior to sending the information to the vehicle management system 110, the gateway module 205 can determine what data to send to the vehicle management system 110, which can reduce redundant processing and bandwidth used to continually transmit vehicle data).
However, while Mason teaches normalizing a plurality of pieces of the vehicle data acquired from...the vehicle (see at least Mason [¶ 21, 93, 92]) it does not explicitly teach wherein the vehicle data is acquired from an electronic control unit mounted in the vehicle.
Hiroki, in the same field as the endeavor teaches normalizing a plurality of pieces of the vehicle data acquired from an electronic control unit mounted in the vehicle (see at least Hiroki [English Translation pg.16 para.6] When the vehicle-mounted device (3) indicates that the state of the vehicle (4) transmitted from the vehicle ECU (23) is abnormal, the vehicle-mounted device (3) normalizes the state of the vehicle (4) based on the abnormal state information)
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention to have modified the system set forth in Mason to contain a system for acquiring vehicle data from an ECU mounted in the vehicle with reasonable expectation of success. One of ordinary skill in the art would have been motivated to make such a modification for benefit of including a conventional and reliable way to access vehicle data using hardware that is commonplace in the art.
Further, Mason does not explicitly teach wherein:
the center receives a control instruction from a service providing server and controls the vehicle by sending the control instruction to the in-vehicle device, the control instruction being generated by the service providing server based on at least one of the plurality of pieces of the vehicle data stored by the center; and
the in-vehicle device controls the vehicle based on the control instruction received from the center.
Rust, in the same field as the endeavor, teaches wherein the center receives a control instruction from a service providing server and controls the vehicle by sending the control instruction to the in-vehicle device, the control instruction being generated by the service providing server based on at least one of the plurality of pieces of the vehicle data stored by the center (see at least Rust [¶ 18, 33, 102-103, 110] A remote assistance subsystem of the system 300 includes the primary components including a computing client (e.g., client code executed by an onboard computer) operating on each autonomous vehicle 310, the remote assistance server 320, and a human expert interface 120 (e.g., a human expert terminal). The remote assistance subsystem optionally includes the artificial intelligence server 340 and AI expert 140....The computing client functions to aggregated data from the operation systems of the autonomous vehicle information and communicate the aggregated data to the remote assistance server 320 in various circumstances including during an assistance-desired scenario. Additionally, the computing client functions to receive commands from the remote assistance server including commands for controlling one or more operations of the vehicle (e.g., remote driving of the autonomous vehicle)....any rerouting calculated by the…AI expert 140 must be done in light of the blacklist information; meaning, that during rerouting calculating a mapping or routing database will generally indicate a list of lanes, routes, or traveling paths as blacklisted or otherwise, unavailable for traveling by the autonomous vehicle) The onboard computing client may receive commands for controlling the driving of the vehicle when assistance is required, the commands are based on data stored in the servers such as databases for blacklisted paths
the in-vehicle device controls the vehicle based on the control instruction received from the center (see at least Rust [¶ 21, 102, 103] The onboard computer no functions to control an autonomous vehicle…the onboard computer 110 preferably modifies or controls behavior of the autonomous vehicle....remote assistance subsystem of the system 300 includes the primary components including a computing client (e.g., client code executed by an onboard computer) operating on each autonomous vehicle 310...the computing client functions to receive commands from the remote assistance server including commands for controlling one or more operations of the vehicle (e.g., remote driving of the autonomous vehicle)).
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention to have modified the system set forth in Mason to contain a system for wherein: the center receives a control instruction from a service providing server and controls the vehicle by sending the control instruction to the in-vehicle device, the control instruction being generated by the service providing server based on at least one of the plurality of pieces of the vehicle data stored by the center; and the in-vehicle device controls the vehicle based on the control instruction received from the center with reasonable expectation of success. One of ordinary skill in the art would have been motivated to make such a modification for benefit of improving safety of the vehicle by augmenting its control using remote computing power as discussed in Rust (see at least Rust [¶ 43] The method 200 functions to enable onboard computing systems of autonomous vehicles to identify scenarios in which vehicle operation may be improved and/or made safer by remote assistance, and to efficiently request and receive remote assistance in these scenarios).
Regarding Claim 13, Mason teaches a vehicle system comprising:
a center that is configured to manage vehicle data transmitted from a plurality of vehicles and a plurality of in-vehicle devices that are configured to wirelessly communicate with the center through a communicator (see at least Mason [¶ 24-25] the example vehicle management system 110 shown includes a telematics module 132, a data standardizing module 134, and a measurement selection module 136 that can receive and analyze vehicle data to provide vehicle operation information and configure the collection of measurement data related to the operation of fleet vehicles…one or more in-vehicle devices 104 and management devices 106 communicate with the vehicle management system 110 over a network 108. The in-vehicle devices 104 can include computing devices installed in fleet vehicles)
wherein each of the plurality of in-vehicle devices includes: at least one first processor; and at least one first memory storing first computer program code (see at least Mason [¶ 88] FIG. 2 illustrates an embodiment of a gateway module 205. The gateway module 205 is a more detailed embodiment of an in-vehicle device 104 described above and includes all the features thereof. The gateway module 205 can be a vehicle based data acquisition and transmission sub-system. In the depicted embodiment, the gateway module 205 has a processor 210, memory 215, a wireless adapter 220, and one or more sensors 225)
the first computer program code, when executed by the at least one first processor, causes the at least one first processor to implement:
a normalization portion that is configured to normalize a plurality of pieces of the vehicle data acquired from…the respective vehicle (see at least Mason [¶ 21, 92, 93] the raw measurement data can be processed to standardize or normalize the data into a format that the various components of the vehicle management system can decode and process, and this standardized measurement data can be stored...The gateway module 205 can, among other things, analyze, categorize, compress, or otherwise process the data before transmitting it to the vehicle management system 110...The gateway module 205 can be in communication with some or all of the in-vehicle sensors 230. For example, the gateway module 205 can be coupled to an OBDII or CAN bus in the vehicle to thereby receive in-vehicle sensor information from the engine computer. In some embodiments, one or more in-vehicle sensors can be directly coupled to the gateway module 205, or the gateway module 205 can be configured to communicate wirelessly with the in-vehicle sensors) The gateway module may process the data before transmitting it to the vehicle management system. Mason, additionally describes how the processing of data can be used to standardize or normalize data into a format that the vehicle management system can decode and process. Therefore the gateway module is analogous to the in-vehicle normalization portion and the vehicle management system is analogous to the center
a data structuring portion that is configured to structure the plurality of pieces of the vehicle data that are normalized by the normalization portion into a predetermined data structure (see at least Mason [¶ 75, 93] multiple types of data structures can be used to organize the ranking of measurements. The data structures used can, for instance, be any hierarchical data structure. In some embodiments, a dependency tree data structure is used to organize the ranking of potential measurements for a given piece of information.....The gateway module 205 can, among other things, analyze, categorize, compress, or otherwise process the data before transmitting it to the vehicle management system 110. By preprocessing the data prior to sending the information to the vehicle management system 110, the gateway module 205 can determine what data to send to the vehicle management system 110, which can reduce redundant processing and bandwidth used to continually transmit vehicle data) The gateway module categorizes and processes data before sending it to the vehicle management system, which is analogous to structuring pieces of data. Mason additionally discusses the use of multiple types of predetermined data structures specifically used to organize ranking of measurements
a data transmission portion that is configured to transmit the plurality of pieces of the vehicle data that are structured by the data structuring portion to the center through a communicator (see at least Mason [¶ 89, 93] The radio 240 can transmit data received from the gateway module 205 to the vehicle management system 110. The radio 240 can also communicate vehicle positioning data received from the GPS module 245 to the vehicle management system 110. In one embodiment, the radio 240 communicates with the vehicle management system by placing a cell phone call to a server of the vehicle management system 110. The radio 240 can also communicate with the server at the vehicle management system 110 by connecting to the network 108 using TCP/IP/UDP protocols. By sending data frequently or periodically, the radio 240 can maintain the connection to the server open, which can guarantee or help to guarantee data reliability....The gateway module 205 can, among other things, analyze, categorize, compress, or otherwise process the data before transmitting it to the vehicle management system 110. By preprocessing the data prior to sending the information to the vehicle management system 110, the gateway module 205 can determine what data to send to the vehicle management system 110, which can reduce redundant processing and bandwidth used to continually transmit vehicle data).
the center includes at least one second processor and at least one second memory storing second computer program code (see at least Mason [¶ 24 68])
that, when executed by the at least one second processor causes the at least one second processor to implement:
a data receiving portion that is configured to receive the plurality of pieces of the structured vehicle data transmitted from the plurality of in-vehicle devices (see at least Mason [¶ 25, 26, 89] one or more in-vehicle devices 104 and management devices 106 communicate with the vehicle management system 110 over a network 108. The in-vehicle devices 104 can include computing devices installed in fleet vehicles….The illustrated network 108 may be a LAN, a WAN, the Internet, combinations of the same… The radio 240 can transmit data received from the gateway module 205 to the vehicle management system 110)
a vehicle data storage portion that is configured to store, for each of the plurality of vehicles, the plurality of pieces of the vehicle data that are structured by the data structuring portion and received by the data receiving portion (see at least Mason [¶ 68] memory in the vehicle management system 110).
However, while Mason teaches a normalization portion that is configured to normalize a plurality of pieces of the vehicle data acquired from...the vehicle (see at least Mason [¶ 21, 93, 92]) it does not explicitly teach wherein the vehicle data is acquired from an electronic control unit mounted in the vehicle.
Hiroki, in the same field as the endeavor teaches a normalization portion that is configured to normalize a plurality of pieces of the vehicle data acquired from an electronic control unit mounted in the vehicle (see at least Hiroki [English Translation pg.16 para.6] When the vehicle-mounted device (3) indicates that the state of the vehicle (4) transmitted from the vehicle ECU (23) is abnormal, the vehicle-mounted device (3) normalizes the state of the vehicle (4) based on the abnormal state information)
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention to have modified the system set forth in Mason to contain a system for acquiring vehicle data from an ECU mounted in the vehicle with reasonable expectation of success. One of ordinary skill in the art would have been motivated to make such a modification for benefit of including a conventional and reliable way to access vehicle data using hardware that is commonplace in the art.
Further, Mason does not explicitly teach wherein the second computer program code, when executed by the at least one second processor, further causes the at least one second processor to receive a control instruction from a service providing server and to control the respective vehicle by sending the control instruction to the in-vehicle device, the control instruction being generated by the service providing server based on at least one of the plurality of pieces of the vehicle data stored by the center and the at least one first processor controls the respective vehicle based on the control instruction received from the center.
Rust, in the same field as the endeavor, teaches wherein the second computer program code, when executed by the at least one second processor, further causes the at least one second processor to receive a control instruction from a service providing server and to control the respective vehicle by sending the control instruction to the in-vehicle device, the control instruction being generated by the service providing server based on at least one of the plurality of pieces of the vehicle data stored by the center and the at least one first processor controls the respective vehicle based on the control instruction received from the center (see at least Rust [¶ 18, 33, 102-103, 110] A remote assistance subsystem of the system 300 includes the primary components including a computing client (e.g., client code executed by an onboard computer) operating on each autonomous vehicle 310, the remote assistance server 320, and a human expert interface 120 (e.g., a human expert terminal). The remote assistance subsystem optionally includes the artificial intelligence server 340 and AI expert 140....The computing client functions to aggregated data from the operation systems of the autonomous vehicle information and communicate the aggregated data to the remote assistance server 320 in various circumstances including during an assistance-desired scenario. Additionally, the computing client functions to receive commands from the remote assistance server including commands for controlling one or more operations of the vehicle (e.g., remote driving of the autonomous vehicle)....any rerouting calculated by the…AI expert 140 must be done in light of the blacklist information; meaning, that during rerouting calculating a mapping or routing database will generally indicate a list of lanes, routes, or traveling paths as blacklisted or otherwise, unavailable for traveling by the autonomous vehicle) The onboard computing client may receive commands for controlling the driving of the vehicle when assistance is required, the commands are based on data stored in the servers such as databases for blacklisted paths.
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention to have modified the system set forth in Mason to contain a system for wherein the second computer program code, when executed by the at least one second processor, further causes the at least one second processor to receive a control instruction from a service providing server and to control the respective vehicle by sending the control instruction to the in-vehicle device, the control instruction being generated by the service providing server based on at least one of the plurality of pieces of the vehicle data stored by the center and the at least one first processor controls the respective vehicle based on the control instruction received from the center with reasonable expectation of success. One of ordinary skill in the art would have been motivated to make such a modification for benefit of improving safety of the vehicle by augmenting its control using remote computing power as discussed in Rust (see at least Rust [¶ 43] The method 200 functions to enable onboard computing systems of autonomous vehicles to identify scenarios in which vehicle operation may be improved and/or made safer by remote assistance, and to efficiently request and receive remote assistance in these scenarios).
Regarding Claim 14, Mason in view of Hiroki and Rust teaches all limitations of Claim 13 as set forth above. Mason further teaches wherein the first computer program code, when executed by the at least one first processor, further causes the at least one first processor to implement a storage portion that is configured to store the plurality of pieces of the vehicle data that are structured by the data structuring portion (see at least Mason [¶ 68, 86] The data standardizing module 134 can access information from a memory in the vehicle management system 110 regarding how the different makes, models, and years report the measurements so that the data standardizing module 134 can standardize the estimated RPM information into a common form....he vehicle management system 110 can acquire, transport, store, and retrieve custom measurements and data alongside standard fleet management information without incorporating additional custom descriptions and translations into the standard fleet management products and data flow. A user can define aspects of the custom measurements and data in a way that lets the vehicle management system 110 acquire, store, and present it in ways that are meaningful to the user without the vehicle management system understanding or interpreting the data in one or more ways as would be done with standard vehicle management system data).
Regarding Claim 17, Mason teaches an in-vehicle device that is configured to acquire the vehicle data (see at least Mason [¶ 92] The gateway module 205 can, among other things, analyze, categorize, compress, or otherwise process the data before transmitting it to the vehicle management system 110...The gateway module 205 can be in communication with some or all of the in-vehicle sensors 230. For example, the gateway module 205 can be coupled to an OBDII or CAN bus in the vehicle to thereby receive in-vehicle sensor information from the engine computer. In some embodiments, one or more in-vehicle sensors can be directly coupled to the gateway module 205, or the gateway module 205 can be configured to communicate wirelessly with the in-vehicle sensors)
the in-vehicle device includes: at least one first processor; and at least one first memory storing first computer program code (see at least Mason [¶ 88] FIG. 2 illustrates an embodiment of a gateway module 205. The gateway module 205 is a more detailed embodiment of an in-vehicle device 104 described above and includes all the features thereof. The gateway module 205 can be a vehicle based data acquisition and transmission sub-system. In the depicted embodiment, the gateway module 205 has a processor 210, memory 215, a wireless adapter 220, and one or more sensors 225)
wherein the first computer program code, when executed by the at least one first processor, causes the at least one first processor to implement:
a normalization portion that is configured to normalize a plurality of pieces of the vehicle data acquired from…the vehicle (see at least Mason [¶ 21, 92, 93] the raw measurement data can be processed to standardize or normalize the data into a format that the various components of the vehicle management system can decode and process, and this standardized measurement data can be stored...The gateway module 205 can, among other things, analyze, categorize, compress, or otherwise process the data before transmitting it to the vehicle management system 110...The gateway module 205 can be in communication with some or all of the in-vehicle sensors 230. For example, the gateway module 205 can be coupled to an OBDII or CAN bus in the vehicle to thereby receive in-vehicle sensor information from the engine computer. In some embodiments, one or more in-vehicle sensors can be directly coupled to the gateway module 205, or the gateway module 205 can be configured to communicate wirelessly with the in-vehicle sensors) The gateway module may process the data before transmitting it to the vehicle management system. Mason, additionally describes how the processing of data can be used to standardize or normalize data into a format that the vehicle management system can decode and process. Therefore the gateway module is analogous to the in-vehicle normalization portion and the vehicle management system is analogous to the center
a data structuring portion that is configured to structure the plurality of pieces of the vehicle data that are normalized by the normalization portion into a predetermined data structure (see at least Mason [¶ 75, 93] multiple types of data structures can be used to organize the ranking of measurements. The data structures used can, for instance, be any hierarchical data structure. In some embodiments, a dependency tree data structure is used to organize the ranking of potential measurements for a given piece of information.....The gateway module 205 can, among other things, analyze, categorize, compress, or otherwise process the data before transmitting it to the vehicle management system 110. By preprocessing the data prior to sending the information to the vehicle management system 110, the gateway module 205 can determine what data to send to the vehicle management system 110, which can reduce redundant processing and bandwidth used to continually transmit vehicle data) The gateway module categorizes and processes data before sending it to the vehicle management system, which is analogous to structuring pieces of data. Mason additionally discusses the use of multiple types of predetermined data structures specifically used to organize ranking of measurements
a data transmission portion that is configured to transmit the plurality of pieces of the vehicle data that are structured by the data structuring portion to a center configured to manage vehicle data through a communicator (see at least Mason [¶ 25, 89, 93] one or more in-vehicle devices 104 and management devices 106 communicate with the vehicle management system 110 over a network 108. The in-vehicle devices 104 can include computing devices installed in fleet vehicles…The radio 240 can transmit data received from the gateway module 205 to the vehicle management system 110. The radio 240 can also communicate vehicle positioning data received from the GPS module 245 to the vehicle management system 110. In one embodiment, the radio 240 communicates with the vehicle management system by placing a cell phone call to a server of the vehicle management system 110. The radio 240 can also communicate with the server at the vehicle management system 110 by connecting to the network 108 using TCP/IP/UDP protocols. By sending data frequently or periodically, the radio 240 can maintain the connection to the server open, which can guarantee or help to guarantee data reliability....The gateway module 205 can, among other things, analyze, categorize, compress, or otherwise process the data before transmitting it to the vehicle management system 110. By preprocessing the data prior to sending the information to the vehicle management system 110, the gateway module 205 can determine what data to send to the vehicle management system 110, which can reduce redundant processing and bandwidth used to continually transmit vehicle data).
However, while Mason teaches a normalization portion that is configured to normalize a plurality of pieces of the vehicle data acquired from...the vehicle and an in-vehicle device configured to acquire vehicle data (see at least Mason [¶ 21, 93, 92]) it does not explicitly teach
an electronic control unit that is mounted in a vehicle and is configured to transmit vehicle data
and wherein the vehicle data is transmitted from an electronic control unit mounted in the vehicle.
Hiroki, in the same field as the endeavor teaches an electronic control unit that is mounted in a vehicle and is configured to transmit vehicle data (see at least Hiroki [English Translation pg.3 para.2, pg.16 para.6] ECUs 23 mounted on the vehicle 4…When the vehicle-mounted device (3) indicates that the state of the vehicle (4) transmitted from the vehicle ECU (23) is abnormal, the vehicle-mounted device (3) normalizes the state of the vehicle (4) based on the abnormal state information
an in-vehicle device that is configured to acquire the vehicle data transmitted from the electronic control unit (see at least Hiroki [English Translation pg.16 para.6] When the vehicle-mounted device (3) indicates that the state of the vehicle (4) transmitted from the vehicle ECU (23) is abnormal, the vehicle-mounted device (3) normalizes the state of the vehicle (4) based on the abnormal state information)
a normalization portion that is configured to normalize a plurality of pieces of the vehicle data acquired from an electronic control unit mounted in the vehicle (see at least Hiroki [English Translation pg.16 para.6] When the vehicle-mounted device (3) indicates that the state of the vehicle (4) transmitted from the vehicle ECU (23) is abnormal, the vehicle-mounted device (3) normalizes the state of the vehicle (4) based on the abnormal state information)
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention to have modified the system set forth in Mason to contain a system for acquiring vehicle data from an ECU mounted in the vehicle with reasonable expectation of success. One of ordinary skill in the art would have been motivated to make such a modification for benefit of including a conventional and reliable way to access vehicle data using hardware that is commonplace in the art.
Further, Mason does not explicitly teach wherein the center includes at least one second processor and at least one second memory storing second computer program code that, when executed by the at least one second processor, causes the at least one second processor to receive a control instruction from a service providing server and to control the vehicle by sending the control instruction to the in-vehicle device, the control instruction being generated by the service providing server based on at least one of the plurality of pieces of the vehicle data stored by the center: and the at least one first processor controls the vehicle based on the control instruction received from the center.
Rust, in the same field as the endeavor, teaches wherein the center includes at least one second processor and at least one second memory storing second computer program code that, when executed by the at least one second processor, causes the at least one second processor to receive a control instruction from a service providing server and to control the vehicle by sending the control instruction to the in-vehicle device, the control instruction being generated by the service providing server based on at least one of the plurality of pieces of the vehicle data stored by the center: and the at least one first processor controls the vehicle based on the control instruction received from the center (see at least Rust [¶ 18, 33, 102-103, 110] A remote assistance subsystem of the system 300 includes the primary components including a computing client (e.g., client code executed by an onboard computer) operating on each autonomous vehicle 310, the remote assistance server 320, and a human expert interface 120 (e.g., a human expert terminal). The remote assistance subsystem optionally includes the artificial intelligence server 340 and AI expert 140....The computing client functions to aggregated data from the operation systems of the autonomous vehicle information and communicate the aggregated data to the remote assistance server 320 in various circumstances including during an assistance-desired scenario. Additionally, the computing client functions to receive commands from the remote assistance server including commands for controlling one or more operations of the vehicle (e.g., remote driving of the autonomous vehicle)....any rerouting calculated by the…AI expert 140 must be done in light of the blacklist information; meaning, that during rerouting calculating a mapping or routing database will generally indicate a list of lanes, routes, or traveling paths as blacklisted or otherwise, unavailable for traveling by the autonomous vehicle) The onboard computing client may receive commands for controlling the driving of the vehicle when assistance is required, the commands are based on data stored in the servers such as databases for blacklisted paths.
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention to have modified the system set forth in Mason to contain a system for wherein the center includes at least one second processor and at least one second memory storing second computer program code that, when executed by the at least one second processor, causes the at least one second processor to receive a control instruction from a service providing server and to control the vehicle by sending the control instruction to the in-vehicle device, the control instruction being generated by the service providing server based on at least one of the plurality of pieces of the vehicle data stored by the center: and the at least one first processor controls the vehicle based on the control instruction received from the center with reasonable expectation of success. One of ordinary skill in the art would have been motivated to make such a modification for benefit of improving safety of the vehicle by augmenting its control using remote computing power as discussed in Rust (see at least Rust [¶ 43] The method 200 functions to enable onboard computing systems of autonomous vehicles to identify scenarios in which vehicle operation may be improved and/or made safer by remote assistance, and to efficiently request and receive remote assistance in these scenarios).
Claims 2, 8, and 9 are rejected under 35 U.S.C. 103 as being unpatentable over Mason et al (US 20130338855 A1) in view of Hiroki et al (JP 6414457 B2), Rust et al (US 20170192423 A1), and Gianisis et al (US 20130179528 A1). Hereafter referred to as Mason, Hiroki, Rust, and Gianisis respectively.
Regarding Claim 2, Mason in view of Hiroki teaches all limitations of Claim 1 as set forth above. However, Mason does not explicitly teach wherein
the at least one first processor includes a first core and a second core,
the first computer program code, when executed by the first core, further causes the first core to acquire the plurality of pieces of the vehicle data…,
the in-vehicle device further comprises a shared memory accessible to the first core and the second core,
the first core is configured to store the plurality of pieces of the acquired vehicle data on the shared memory, and
the second core is configured to acquire the plurality of pieces of the vehicle data from the shared memory.
Gianisis, in the same field as the endeavor, teaches wherein
the at least one first processor includes a first core and a second core (see at least Gianisis [¶ 27] the control system uses a multicore processor to perform network communication with a device, and wherein the multicore processor includes at least a first core and a second core)
the first computer program code, when executed by the first core, further causes the first core to acquire the plurality of pieces of the vehicle data… (see at least Gianisis [¶ 46] at least some network data associated with the network communication is made available in the Shared Memory 407D by the third core (Core n --409C); wherein each of the first core (Core 1--409A) and the second core (Core 2 --409B) has access to at least some of the network communication data made available in the Shared Memory 407D by the third core)
the in-vehicle device further comprises a shared memory accessible to the first core and the second core (see at least Gianisis [¶ 26] wherein the control system uses a multicore processor to perform network communication with a first device and a second device. The control system of this embodiment further comprises a shared memory...wherein the machine-readable instructions of the first control application are stored at a first memory location accessible (and/or used) by the first core, and wherein the shared memory is accessible (and/or used) by the first core....wherein the machine-readable instructions of the second control application are stored at a second memory location accessible (and/or used) by the second core; and wherein the shared memory is accessible (and/or used) by the second core)
the first core is configured to store the plurality of pieces of the acquired vehicle data on the shared memory and the second core is configured to acquire the plurality of pieces of the vehicle data from the shared memory (see at least Gianisis [¶ 26, 53] at least some network data associated with the network communication is made available in the shared memory by the third core; wherein each of the first core and the second core has access to at least some of the network communication data made available in the shared memory by the third core; wherein the first core is in operative communication with the third core and the network communication associated with the third core controls the first device based at least in part upon at least one command from the first control application associated with the first core; and wherein the second core is in operative communication with the third core and the network communication associated with the third core controls the second device based at least in part upon at least one command from the second control application associated with the second core... in a design architecture according to an embodiment of the present invention the communication bus data may be exchanged (e.g., exchanged essentially instantly) between cores using shared memory such as DDR or L2 Cache).
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention to have modified the system set forth in Mason to contain a system for wherein the processor contains a first core and a second core to act as multiple processing units with reasonable expectation of success. One of ordinary skill in the art would have been motivated to make such a modification for benefit of improving the efficiency of the system by distributing the computing load between multiple cores/units.
However, Mason does not explicitly teach wherein the vehicle data is acquired from an electronic control unit mounted in the vehicle.
Hiroki, in the same field as the endeavor teaches vehicle data acquired from an electronic control unit mounted in the vehicle (see at least Hiroki [English Translation pg.16 para.6] When the vehicle-mounted device (3) indicates that the state of the vehicle (4) transmitted from the vehicle ECU (23) is abnormal, the vehicle-mounted device (3) normalizes the state of the vehicle (4) based on the abnormal state information)
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention to have modified the system set forth in Mason to contain a system for acquiring vehicle data from an ECU mounted in the vehicle with reasonable expectation of success. One of ordinary skill in the art would have been motivated to make such a modification for benefit of including a conventional and reliable way to access vehicle data using hardware that is commonplace in the art.
Regarding Claim 8, Mason in view of Hiroki teaches all limitations of Claim 1 as set forth above. However, Mason does not explicitly teach wherein
the at least one first processor includes a first core and a second core,
the first computer program code, when executed by the first core, further causes the first core to acquire the plurality of pieces of the vehicle data…,
the in-vehicle device further comprises a shared memory accessible to which the first core and the second core,
the first core includes a first application that is configured to execute a process to control the vehicle,
the second core includes a second application that is configured to execute a process related to a service provided by a service providing unit that is communicably connected to the center,
the plurality of pieces of the vehicle data that are structured by the data structuring portion are stored on the shared memory, and
the first application and the second application are accessible to the shared memory.
Gianisis, in the same field as the endeavor, teaches wherein
the at least one first processor includes a first core and a second core (see at least Gianisis [¶ 27] the control system uses a multicore processor to perform network communication with a device, and wherein the multicore processor includes at least a first core and a second core)
the first computer program code, when executed by the first core, further causes the first core to acquire the plurality of pieces of the vehicle data…(see at least Gianisis [¶ 46] at least some network data associated with the network communication is made available in the Shared Memory 407D by the third core (Core n --409C); wherein each of the first core (Core 1--409A) and the second core (Core 2 --409B) has access to at least some of the network communication data made available in the Shared Memory 407D by the third core)
the in-vehicle device further comprises a shared memory accessible to which the first core and the second core (see at least Gianisis [¶ 26] wherein the control system uses a multicore processor to perform network communication with a first device and a second device. The control system of this embodiment further comprises a shared memory...wherein the machine-readable instructions of the first control application are stored at a first memory location accessible (and/or used) by the first core, and wherein the shared memory is accessible (and/or used) by the first core....wherein the machine-readable instructions of the second control application are stored at a second memory location accessible (and/or used) by the second core; and wherein the shared memory is accessible (and/or used) by the second core)
the first core includes a first application that is configured to execute a process to control the vehicle (see at least Gianisis [¶ 25-26] The control system of this embodiment further comprises at least a first core for executing a control application, wherein the first core is part of the multicore processor, wherein the control application comprises a plurality of machine-readable instructions, wherein the machine-readable instructions of the control application are stored at the first memory location and are accessible (and/or used) by the first core)
the plurality of pieces of the vehicle data that are structured by the data structuring portion are stored on the shared memory (see at least Gianisis [¶ 26] at least some network data associated with the network communication is made available in the shared memory by the third core; wherein each of the first core and the second core has access to at least some of the network communication data made available in the shared memory)
the first application and the second application are accessible to the shared memory (see at least Gianisis [¶ 26] wherein the control system uses a multicore processor to perform network communication with a first device and a second device. The control system of this embodiment further comprises a shared memory...wherein the machine-readable instructions of the first control application are stored at a first memory location accessible (and/or used) by the first core, and wherein the shared memory is accessible (and/or used) by the first core....wherein the machine-readable instructions of the second control application are stored at a second memory location accessible (and/or used) by the second core; and wherein the shared memory is accessible (and/or used) by the second core).
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention to have modified the system set forth in Mason to contain a system for wherein the processor contains a first core and a second core to act as multiple processing units with reasonable expectation of success. One of ordinary skill in the art would have been motivated to make such a modification for benefit of improving the efficiency of the system by distributing the computing load between multiple cores/units.
However, Mason does not explicitly teach wherein the vehicle data is acquired from an electronic control unit mounted in the vehicle.
Hiroki, in the same field as the endeavor teaches vehicle data acquired from an electronic control unit mounted in the vehicle (see at least Hiroki [English Translation pg.16 para.6] When the vehicle-mounted device (3) indicates that the state of the vehicle (4) transmitted from the vehicle ECU (23) is abnormal, the vehicle-mounted device (3) normalizes the state of the vehicle (4) based on the abnormal state information)
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention to have modified the system set forth in Mason to contain a system for acquiring vehicle data from an ECU mounted in the vehicle with reasonable expectation of success. One of ordinary skill in the art would have been motivated to make such a modification for benefit of including a conventional and reliable way to access vehicle data using hardware that is commonplace in the art.
Further, while Mason teaches an application that is configured to execute a process related to a service provided by a service providing unit that is communicably connected to the center (see at least Mason [¶ 28] the vehicle management system 110 includes a fleet management module 126, a mapping module 114, a telematics module 132, a routing module 112, a dispatch module 124, an integration module 122, a data standardizing module 134, and a measurement selection module 136. These components can, but need not, be integrated together on a common software or hardware platform) it does not explicitly teach an application that is executed by a second application in a second core.
Gianisis, in the same field as the endeavor teaches wherein the second core includes a second application that is configured to execute a process… (see at least Gianisis [¶ 43] Control System 300 includes Multicore Processor 303 to perform network communication with a Device 305...described herein, the network communication associated with the second core (Core 2 --309B) controls the Device 305 based at least in part upon at least one command from the vehicle control application associated with the first core (Core 1 --309A))
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention to have modified the system set forth in Mason to contain a system for second processing unit that includes a second application that can be configured to execute such processes included within the vehicle management system with reasonable expectation of success. One of ordinary skill in the art would have been motivated to make such a modification for benefit of allowing different applications and processes to be run by different processing cores/units to allow for improved processing efficiency of the system.
Regarding Claim 9, Mason in view of Hiroki teaches all limitations of Claim 1 as set forth above. However, Mason does not explicitly teach wherein
the at least one first processor includes a first core and a second core,
the first computer program code, when executed by the first core, further causes the first core to acquire the plurality of pieces of the vehicle data from the electronic control unit,
the first core is configured to acquire the plurality of pieces of the vehicle data from a relaying device that is communicably connected to the electronic control unit.
Gianisis, in the same field as the endeavor, teaches
the at least one first processor includes a first core and a second core (see at least Gianisis [¶ 27] the control system uses a multicore processor to perform network communication with a device, and wherein the multicore processor includes at least a first core and a second core)
the first computer program code, when executed by the first core, further causes the first core to acquire the plurality of pieces of the vehicle data…(see at least Gianisis [¶ 46] at least some network data associated with the network communication is made available in the Shared Memory 407D by the third core (Core n --409C); wherein each of the first core (Core 1--409A) and the second core (Core 2 --409B) has access to at least some of the network communication data made available in the Shared Memory 407D by the third core)
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention to have modified the system set forth in Mason to contain a system for wherein the processor contains a first core and a second core to act as multiple processing units with reasonable expectation of success. One of ordinary skill in the art would have been motivated to make such a modification for benefit of improving the efficiency of the system by distributing the computing load between multiple cores/units.
However, Mason does not explicitly teach wherein the vehicle data is acquired from an electronic control unit mounted in the vehicle and wherein the first unit is configured to acquire the plurality of the vehicle data from a relaying device that is communicably connected to the electronic control unit.
Hiroki, in the same field as the endeavor teaches vehicle data acquired from an electronic control unit mounted in the vehicle and wherein the first unit is configured to acquire the plurality of the vehicle data from a relaying device that is communicably connected to the electronic control unit (see at least Hiroki [English Translation pg.16 para.6] When the vehicle-mounted device (3) indicates that the state of the vehicle (4) transmitted from the vehicle ECU (23) is abnormal, the vehicle-mounted device (3) normalizes the state of the vehicle (4) based on the abnormal state information)
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention to have modified the system set forth in Mason to contain a system for acquiring vehicle data from an ECU mounted in the vehicle with reasonable expectation of success. One of ordinary skill in the art would have been motivated to make such a modification for benefit of including a conventional and reliable way to access vehicle data using hardware that is commonplace in the art.
Claims 3 and 4 are rejected under 35 U.S.C. 103 as being unpatentable over Mason et al (US 20130338855 A1) in view of Hiroki et al (JP 6414457 B2), Rust et al (US 20170192423 A1), and Kim (KR 101857554 B1). Hereafter referred to as Mason, Hiroki, Rust and Kim respectively.
Regarding Claim 3, Mason in view of Hiroki and Rust teaches all limitations of Claim 1 as set forth above. However, Mason does not explicitly teach the normalization portion is further configured to normalize the plurality of pieces of the vehicle data by referring to a vehicle data conversion table in which “resolution” and “offset” are set as normalization information.
Kim, in the same field as the endeavor, teaches the normalization portion is further configured to normalize the plurality of pieces of the vehicle data by referring to a vehicle data conversion table (see at least Kim [English Translation pg.4 para.10] the data normalization unit 117 receives the plurality of first driving data 'current speed of the vehicle', 'steering direction of the vehicle', 'acceleration and deceleration signal' generated by the first driving data generating unit 112, The current data of the vehicle, the current speed of the vehicle, the vehicle speed of the vehicle, and the vehicle speed of the vehicle, which are obtained by the second travel data acquiring unit 113, Steering direction ',' acceleration and deceleration signal 'with 8-bit size data with reference to the replacement table, thereby converting the plurality of first running data and the plurality of second running data into an 8-bit size).
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention to have modified the system set forth in Mason to contain a system for wherein the normalization portion is further configured to normalize the plurality of pieces of the vehicle data by referring to a vehicle data conversion table with reasonable expectation of success. One of ordinary skill in the art would have been motivated to make such a modification for benefit of improving the conversion of the data by using an conversion method that was well known in the art.
However, Mason does not teach a vehicle data conversion table in which “resolution” and “offset” are set as normalization information.
However, Kim teaches the use of a conversion table to normalize a plurality of pieces of the vehicle data (see at least Kim [English Translation pg.4 para.10]).
Therefore, the combination of Mason, Hiroki, and Kim discloses the claimed invention except for wherein the conversion table specifically includes “resolution” and “offset” as set normalization information. It would have been obvious to anyone of ordinary skill in the art before the effective filing date of the claimed invention to have included “resolution” and “offset” as set normalization information since it has been held to be within the general skill of a worker in the art to select information based on its suitability for the intended use as a matter of design choice.
Regarding Claim 4, Mason in view of Hiroki, Rust, and Kim teaches all limitations of Claim 3 as set forth above. However, Mason does not explicitly teach wherein the vehicle data conversion table further includes meaning-giving information that is generated using the plurality of pieces of the vehicle data that are normalized, the meaning-giving information is used for conversion into the vehicle data, the normalization portion is further configured to generate, using the meaning-giving information, meaning-given vehicle data from the plurality of pieces of the normalized vehicle data.
Kim, in the same field as the endeavor, teaches wherein the vehicle data conversion table further includes meaning-giving information that is generated using the plurality of pieces of the vehicle data that are normalized, the meaning-giving information is used for conversion into the vehicle data, the normalization portion is further configured to generate, using the meaning-giving information, meaning-given vehicle data from the plurality of pieces of the normalized vehicle data (see at least Kim [English Translation pg.5 para.7-9] when the first format is a real-valued data format, the data normalization unit 117 normalizes the plurality of first running data and the plurality of second running data The plurality of first running data and the plurality of second running data may be normalized to real values by performing data replacement with reference to the replacement table according to the type of each running data…it is assumed that 'current speed of the vehicle', 'steering direction of the vehicle', 'acceleration and deceleration signal' are stored on the information storage unit 111 as kinds of travel data representing the traveling state of the vehicle, If it is assumed that the first format is a real value format, information may be recorded in the replacement table as shown in Table 2 below…The type of travel data stored in the information storage unit 111 Data value of running data Substitution data (real number value) Current speed of the vehicle 0 to 5 km / h 0 5 to 10 km / h One 10 to 15 km / h 2).
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention to have modified the system set forth in Mason to contain a system for the vehicle data conversion table further includes meaning-giving information that is generated using the plurality of pieces of the vehicle data that are normalized, the meaning-giving information is used for conversion into the vehicle data, the normalization portion is further configured to generate, using the meaning-giving information, meaning-given vehicle data from the plurality of pieces of the normalized vehicle data with reasonable expectation of success. One of ordinary skill in the art would have been motivated to make such a modification for benefit of improving the usability of the system by a user by including a method for converting the normalized data back to values that are understandable to a user and have real world applications.
Claim 5 is rejected under 35 U.S.C. 103 as being unpatentable over Mason et al (US 20130338855 A1) in view of Hiroki et al (JP 6414457 B2), Rust et al (US 20170192423 A1), and Davis et al (US 20200162252 A1). Hereafter referred to as Mason, Hiroki, Rust, and Davis respectively.
Regarding Claim 5, Mason in view of Hiroki and Rust teaches all limitations of Claim 1 as set forth above. However, Mason does not explicitly teach wherein the data structuring portion is further configured to structure the plurality of pieces of the vehicle data that are normalized into the data structure classified with a plurality of categories.
Davis, in the same field as the endeavor, teaches wherein the data structuring portion is further configured to structure the plurality of pieces of the vehicle data that are normalized into the data structure classified with a plurality of categories (see at least David [¶ 37] data from each data source (a priori data and active environmental sensor data) will be processed through an associated one of a plurality of process and classify modules 230a-e, each of which performs operations on the data sets it receives from its associated data source to normalize the data sets, and, in some aspects, also to classify elements within the received data sets).
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention to have modified the system set forth in Mason to contain a system for wherein the data structuring portion is further configured to structure the plurality of pieces of the vehicle data that are normalized into the data structure classified with a plurality of categories with reasonable expectation of success. One of ordinary skill in the art would have been motivated to make such a modification for benefit of improving the simplicity and effectiveness of system by keeping data structures organized based on classification.
Claim 6 is rejected under 35 U.S.C. 103 as being unpatentable over Mason et al (US 20130338855 A1) in view of Hiroki et al (JP 6414457 B2), Rust et al (US 20170192423 A1), Gianisis et al (US 20130179528 A1), and Giannopoulos (US 20190098047 A1). Hereafter referred to as Mason, Hiroki, Rust, Gianisis, and Giannopoulos respectively.
Regarding Claim 6, Mason in view of Hiroki and Rust teaches all limitations of Claim 1 as set forth above. However Mason does not explicitly teach wherein
the at least one first processor includes a first core and a second core,
the first computer program code, when executed by the first core, further causes the first core to acquire the plurality of pieces of the vehicle data from the electronic control unit,
the in-vehicle device further comprises a shared memory accessible to the first core and the second core, and
upon receiving a communication frame storing at least one of the plurality of pieces of the vehicle data from the electronic control unit, the first core is further configured to:
extract frame identification information and the vehicle data from the received communication frame;
generate standard format data formed of the extracted frame identification information and the extracted vehicle data; and
store the vehicle data in the standard format data on the shared memory.
Gianisis, in the same field as the endeavor, teaches
the at least one first processor includes a first core and a second core (see at least Gianisis [¶ 27] the control system uses a multicore processor to perform network communication with a device, and wherein the multicore processor includes at least a first core and a second core)
the first computer program code, when executed by the first core, further causes the first core to acquire the plurality of pieces of the vehicle data…(see at least Gianisis [¶ 46] at least some network data associated with the network communication is made available in the Shared Memory 407D by the third core (Core n --409C); wherein each of the first core (Core 1--409A) and the second core (Core 2 --409B) has access to at least some of the network communication data made available in the Shared Memory 407D by the third core)
the in-vehicle device further comprises a shared memory accessible to the first core and the second core (see at least Gianisis [¶ 26] wherein the control system uses a multicore processor to perform network communication with a first device and a second device. The control system of this embodiment further comprises a shared memory...wherein the machine-readable instructions of the first control application are stored at a first memory location accessible (and/or used) by the first core, and wherein the shared memory is accessible (and/or used) by the first core....wherein the machine-readable instructions of the second control application are stored at a second memory location accessible (and/or used) by the second core; and wherein the shared memory is accessible (and/or used) by the second core)
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention to have modified the system set forth in Mason to contain a system for wherein the processor contains a first core and a second core to act as multiple processing units with reasonable expectation of success. One of ordinary skill in the art would have been motivated to make such a modification for benefit of improving the efficiency of the system by distributing the computing load between multiple cores/units.
However, Mason does not explicitly teach wherein the vehicle data is acquired from an electronic control unit mounted in the vehicle.
Hiroki, in the same field as the endeavor teaches vehicle data acquired from an electronic control unit mounted in the vehicle (see at least Hiroki [English Translation pg.16 para.6] When the vehicle-mounted device (3) indicates that the state of the vehicle (4) transmitted from the vehicle ECU (23) is abnormal, the vehicle-mounted device (3) normalizes the state of the vehicle (4) based on the abnormal state information)
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention to have modified the system set forth in Mason to contain a system for acquiring vehicle data from an ECU mounted in the vehicle with reasonable expectation of success. One of ordinary skill in the art would have been motivated to make such a modification for benefit of including a conventional and reliable way to access vehicle data using hardware that is commonplace in the art.
Giannopoulos, in the same field as the endeavor, teaches wherein upon receiving a communication frame storing at least one of the plurality of pieces of the vehicle data from the electronic control unit, the first unit is configured to:
extract frame identification information and the vehicle data from the received communication frame (see at least Giannopoulos [¶ 16, 6, 47] a CAN frame may be formed to include a plurality of fields such as an arbitration identification (ID) field, a data length code (DLC) field, a data field, and a cyclic redundancy check (CRC) field among other fields...determining when a frame arrives at a CAN bus; receiving, from the CAN bus, an arbitration identification (ID) of the frame; determining whether to override the frame based on the arbitration ID; in response to determining to override the frame, transmitting a predetermined sequence of bits on the CAN bus during transmission of a data length code (DLC) field in the frame; generating a message to complete the frame based on the predetermined sequence of bits; and transmitting the message on the CAN bus....the override ECU receives a plurality of statuses of a vehicle housing the CAN bus. The plurality of statuses may include data gathered by sensors within the vehicle. For example, the plurality of statuses may include a speed of the vehicle, an engine temperature, fuel data, etc. In these embodiments, the override ECU determines whether to override the frame based on the arbitration ID and whether the plurality of statuses matches a plurality of criteria associated with the arbitration ID)
generate standard format data formed of the extracted frame identification information and the extracted vehicle data (see at least Giannopoulos [¶ 16] a CAN frame may be formed to include a plurality of fields such as an arbitration identification (ID) field, a data length code (DLC) field, a data field, and a cyclic redundancy check (CRC) field among other fields)
store the vehicle data in the standard format data on the shared memory (see at least Giannopoulos [¶ 7] a system…on a Controller Area Network (CAN) bus comprises: one or more processors; memory; and one or more programs, wherein the one or more programs are stored in the memory and configured to be executed by the one or more processors, the one or more programs including instructions for: determining when a frame arrives at a CAN bus; receiving, from the CAN bus, an arbitration identification (ID) of the frame).
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention to have modified the system set forth in Mason to contain a system for extract frame identification information and the vehicle data from the received communication frame, generate standard format data formed of the extracted frame identification information and the extracted vehicle data, and store the vehicle data in the standard format data on the shared memory with reasonable expectation of success. One of ordinary skill in the art would have been motivated to make such a modification for benefit of improving the data transfer by using unique frame identification to organize and process collected vehicle data, a method that is well known in the art.
Claim 7 is rejected under 35 U.S.C. 103 as being unpatentable over Mason et al (US 20130338855 A1) in view of Hiroki et al (JP 6414457 B2), Rust et al (US 20170192423 A1), and Al-Stouhi et al (US 20190069051 A1). Hereafter referred to as Mason, Hiroki, and Al-Stouhi respectively.
Regarding Claim 7, Mason in view of Hiroki and Rust teaches all limitations of Claim 7 as set forth above. However, Mason does not explicitly teach wherein each of a plurality of mutually different transmission timings is set for a respective one of the plurality of pieces of the vehicle data that are structured, and the data transmission portion is further configured to transmit each of the plurality of pieces of the structured vehicle data at a corresponding one of the plurality of mutually different transmission timings.
Al-Stouhi, in the same field as the endeavor, teaches wherein each of a plurality of mutually different transmission timings is set for a respective one of the plurality of pieces of the vehicle data that are structured, and the data transmission portion is further configured to transmit each of the plurality of pieces of the structured vehicle data at a corresponding one of the plurality of mutually different transmission timings (see at least Al-Stouhi [¶ 79, 67, 95] method 200 can also include determining a transmission interval. A transmission interval, as used within this description, is a period of time between transmission and/or communication of sensor data from the sensor unit 126 to the second vehicle 108, and from the sensor unit 154 to the first vehicle 106. In other embodiments, the transmission interval can be a period of time from transmission of a sensor trigger pulse that actuates the sensor unit 126 and a period of time from transmission of a sensor trigger pulse that actuates the sensor unit 154… the first vehicle 106 captures frame 1 at 0 ms and transmits the results of frame 1 (e.g., after processing of frame 1) at 100 ms to the second vehicle 108. Similarly, the second vehicle 108 captures frame 1 at 50 ms and transmits the results of frame 1 (e.g., after processing of frame 1) at 150 ms to the first vehicle 106…Computer-readable storage media can include volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information such as computer readable instructions, data structures).
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention to have modified the system set forth in Mason to contain a system for wherein each of a plurality of mutually different transmission timings is set for a respective one of the plurality of pieces of the vehicle data that are structured, and the data transmission portion is further configured to transmit each of the plurality of pieces of the structured vehicle data at a corresponding one of the plurality of mutually different transmission timings with reasonable expectation of success. One of ordinary skill in the art would have been motivated to make such a modification for benefit of improving the data capture by determining when data transmission happen, allowing the system to process data more effectively.
Claim 10 is rejected under 35 U.S.C. 103 as being unpatentable over Mason et al (US 20130338855 A1) in view of Hiroki et al (JP 6414457 B2), Rust et al (US 20170192423 A1), Gianisis et al (US 20130179528 A1), and Way et al (US 20190110174 A1). Hereafter referred to as Mason, Hiroki, Rust, Gianisis, and Way respectively.
Regarding Claim 10, Mason in view of Hiroki, Rust, and Gianisis teaches all limitations of Claim 8 as set forth above. Mason further teaches wherein the first computer program code, when executed by the at least one first processor, further causes the at least one first processor to implement: a storage portion that is configured to store the plurality of pieces of the vehicle data that are structured by the data structuring portion (see at least Mason [¶ 68, 86] The data standardizing module 134 can access information from a memory in the vehicle management system 110 regarding how the different makes, models, and years report the measurements so that the data standardizing module 134 can standardize the estimated RPM information into a common form....he vehicle management system 110 can acquire, transport, store, and retrieve custom measurements and data alongside standard fleet management information without incorporating additional custom descriptions and translations into the standard fleet management products and data flow. A user can define aspects of the custom measurements and data in a way that lets the vehicle management system 110 acquire, store, and present it in ways that are meaningful to the user without the vehicle management system understanding or interpreting the data in one or more ways as would be done with standard vehicle management system data).
However, Mason does not explicitly teach the second application is configured to acquire the vehicle data stored in the storage portion through an in-vehicle device access API provided in the second core.
Way, in the same field as the endeavor, teaches the second application is configured to acquire the vehicle data stored in the storage portion through an in-vehicle device access API provided in the second core (see at least Way [¶ 66] the operations computing system 202 can include a Vehicle API platform that can provide for a translation/transport layer as an interface between vehicle computing systems onboard vehicles within an entity's fleet and one or more remote clients and/or applications operating within the entity's operations/control center. For example, the Vehicle API platform can receive data from a vehicle over a communications pipeline established between the Vehicle API and the vehicle (e.g., the vehicle computing system) and provide for different means of classifying the data).
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention to have modified the system set forth in Mason to contain a system for the second application is configured to acquire the vehicle data stored in the storage portion through an in-vehicle device access API provided in the second core with reasonable expectation of success. One of ordinary skill in the art would have been motivated to make such a modification for benefit of improving the data acquisition of the system by implementing an API, a method well known in the art.
Claims 15 and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Mason et al (US 20130338855 A1) in view of Hiroki et al (JP 6414457 B2), Rust et al (US 20170192423 A1), and Way et al (US 20190110174 A1). Hereafter referred to as Mason, Hiroki, Rust, and Way respectively.
Regarding Claim 15, Mason in view of Hiroki and Rust teaches all limitations of Claim 14 as set forth above. However, Mason does not explicitly teach each of the plurality of in-vehicle devices has an application that is configured to acquire the plurality of pieces of the vehicle data stored in the storage portion through an in-vehicle device access API provided in each of the plurality of in-vehicle devices.
Way, in the same field as the endeavor, teaches each of the plurality of in-vehicle devices has an application that is configured to acquire the plurality of pieces of the vehicle data stored in the storage portion through an in-vehicle device access API provided in each of the plurality of in-vehicle devices (see at last Way [¶ 66] the operations computing system 202 can include a Vehicle API platform that can provide for a translation/transport layer as an interface between vehicle computing systems onboard vehicles within an entity's fleet and one or more remote clients and/or applications operating within the entity's operations/control center. For example, the Vehicle API platform can receive data from a vehicle over a communications pipeline established between the Vehicle API and the vehicle (e.g., the vehicle computing system) and provide for different means of classifying the data).
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention to have modified the system set forth in Mason to contain a system for the second application is configured to acquire the vehicle data stored in the storage portion through an in-vehicle device access API provided in the second unit with reasonable expectation of success. One of ordinary skill in the art would have been motivated to make such a modification for benefit of improving the data acquisition of the system by implementing an API, a method well known in the art.
Regarding Claim 16, Mason in view of Hiroki and Rust teaches all limitations of Claim 13 as set forth above. However, Mason does not explicitly teach wherein the center is further configured to: accept a request from a service providing unit communicably connected to the center through a center access API provided in the center and transmit, to the service providing unit, the plurality of pieces of the vehicle data, which are stored in the vehicle data storage portion and each of which corresponds to a respective one of the plurality of vehicles.
Way, in the same field as the endeavor, teaches wherein the center is further configured to: accept a request from a service providing unit communicably connected to the center through a center access API provided in the center and transmit, to the service providing unit, the plurality of pieces of the vehicle data, which are stored in the vehicle data storage portion and each of which corresponds to a respective one of the plurality of vehicles (see at least Way [¶ 17, 5, 27] The Vehicle API platform can provide for communicating vehicle data to the operations/control center in a secure manner that allows for expanded processing of vehicle data off the vehicle, analyzing such data in real time, and/or the like. According to example aspects of the present disclosure, a Vehicle API platform can be vehicle agnostic, allowing for any autonomous vehicle and/or compute-capable vehicle to interact with an entity's operations/control center by providing a consistent communication pipeline that any vehicle computing system would be able to use to report vehicle data (e.g., telemetry, video, etc.) and/or receive messages (e.g., command/control messages, configuration messages, alerts, advisories, etc.) from one or more clients (e.g., fleet reporting, fleet management, fleet services/maintenance, remote vehicle assistance, routing, scheduling, etc.) associated with an entity's operations system... The method includes obtaining, by a computing system comprising one or more computing devices, a request to establish communication from a vehicle computing system....in some implementations, the Vehicle API platform can provide for a vehicle sending a request for assistance to the service provider system).
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention to have modified the system set forth in Mason to contain a system for wherein the center is further configured to: accept a request from a service providing unit communicably connected to the center through a center access API provided in the center and transmit, to the service providing unit, the plurality of pieces of the vehicle data, which are stored in the vehicle data storage portion and each of which corresponds to a respective one of the plurality of vehicles with reasonable expectation of success. One of ordinary skill in the art would have been motivated to make such a modification for benefit of improving the communication system between the in-vehicle devices and the centers by establishing an API system that allows them to communicate, a communication method well known in the art.
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 JOSEPH A YANOSKA whose telephone number is (703)756-5891. The examiner can normally be reached M-F 9:00am to 5:00pm (Pacific Time).
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, Rachid Bendidi can be reached on (571) 272-4896. 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.
/JOSEPH ANDERSON YANOSKA/Examiner, Art Unit 3664
/RACHID BENDIDI/ Supervisory Patent Examiner, Art Unit 3664