Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Arguments
Applicant’s arguments with respect to 35 U.S.C. 102/103 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Claim Interpretation
The claims as amended are no longer being interpreted under 35 U.S.C. 112(f).
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 16-17 and 19-20 are rejected under 35 U.S.C. 103 as being unpatentable over US20170264691 by Bai et al. (hereinafter “Bai”), further in view of US20190132424 by Jeong et al. (hereinafter “Jeong”).
Regarding claim 16, Bai teaches A vehicle system comprising: an in-vehicle device including a computer configured to communicate with a cloud server configured to manage vehicle data via a communication device; see for example paragraphs [0036]-[0037], describing an add-on device. See also paragraph [0132], where the system can communicate with a remote server. Further, see paragraphs [0121]-[0123] describe how the vehicle itself can communicate with a server.
an expansion unit that is detachably attached to the in-vehicle device; see again paragraphs [0036]-[0037], describing the add-on device.
and an electronic control unit configured to output data to the expansion unit, see for example paragraph [0093], where the add-on communicates with the vehicle.
wherein the expansion unit includes: at least one input line that is provided for each communication protocol of input data that is data transmitted from the electronic control unit and receives the input data; see for example paragraphs [0099]-[0100], where the add-on receives sensor data from the sensors.
at least one output line that is provided for each communication protocol of output data and outputs the output data; in addition to paragraph [0093], see for example paragraph [0060], where the add-on communicates sensor data to the vehicle.
at least one connector for connecting the output line to the in-vehicle device; see again paragraphs [0093] and [0060], where the system communicates sensor data to the vehicle wirelessly or over a wired connection.
a processing unit configured to perform processing on the input data and cause the output line to output the output data according to the input data; see for example paragraph [0140], where the add-on includes its own processor for processing the data input from the sensors.
the in-vehicle device includes: a controller configured to generate the vehicle data based on the received output data; see for example paragraph [0043], where the add-on communicates with a vehicle’s ECU. See also paragraph [0068], where the sensor data is used by the vehicle for adaptive cruise control or autonomous driving.
and a communication unit configured to transmit the vehicle data to the cloud server via a communication device, the electronic control unit includes a relay unit configured to relay, to the expansion unit, data transmitted from a different electronic control unit, see for example paragraphs [0053]-[0063], where the vehicle can communicates with other vehicles and vehicle devices.
Bai does not explicitly teach a table that defines determination of whether to cause the processing unit to perform the processing on the input data for each communication protocol or each data type, nor does Bai explicitly teach the table includes information for determining a plurality of protocols including each communication protocol or a plurality of data types including each data type, in order to define whether to perform the processing on the input data, and the processing unit is configured to determine each communication protocol of the input data or each data type of the input data based on the table.
However, Jeong teaches a table that defines determination of whether to cause the processing unit to perform the processing on the input data for each communication protocol or each data type, [wherein] the table includes information for determining a plurality of protocols including each communication protocol or a plurality of data types including each data type, in order to define whether to perform the processing on the input data, and the processing unit is configured to determine each communication protocol of the input data or each data type of the input data based on the table. See for example Figure 3 and paragraphs [0053]-[0066], where the system determines that data protocol conversion is necessary, calls a table for the appropriate conversion, and converts data according to its data type.
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the sensor add-on system of Bai with the communication protocol conversion table of Jeong with a reasonable expectation of success. Doing so allows the system to convert data from one format to a more standardized, compatible format.
Claim 17 has similar limitations to claim 16 above, and is therefore rejected using a similar rationale.
Regarding claim 19, Bai teaches wherein the expansion unit further includes an expansion . Bai teaches determining whether the system has the appropriate drivers for the sensors, and downloading the corresponding drivers (see paragraphs [0140]-[0175]), and teaches mapping the capabilities of the vehicle to understand the sensor data. See also paragraph [0132], where the operations are performed either on the vehicle processor or the add-on’s processor.
Bai does not explicitly teach using a table for determining whether normalization or data structuring on the input data is necessary.
However, Jeong teaches using a table for determining whether normalization or data structuring on the input data is necessary. See for example Figure 3 and paragraphs [0053]-[0066], where the system determines that data protocol conversion is necessary, calls a table for the appropriate conversion, and converts data according to its data type.
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the sensor add-on system of Bai with the communication protocol conversion table of Jeong with a reasonable expectation of success. Doing so allows the system to convert data from one format to a more standardized, compatible format.
Claim 20 has similar limitations to claim 19 above, and is therefore rejected using a similar rationale.
Claims 1-15, 18, and 21-22 are rejected under 35 U.S.C. 103 as being unpatentable over Bai, further in view of US20230085381 by Zhou (hereinafter “Zhou”), and further in view of Jeong.
Regarding claim 1, Bai teaches An expansion unit configured to be detachably attached to an in-vehicle device including a computer configured to communicate with a cloud server configured to manage vehicle data via a communication device, see for example paragraphs [0036]-[0037], describing an add-on device. See also paragraph [0132], where the system can communicate with a remote server. Further, see paragraphs [0121]-[0123] describe how the vehicle itself can communicate with a server.
the expansion unit comprising: at least one input line that is provided for each communication protocol of input data that is data transmitted from an instrument of a vehicle and receives the input data; see for example paragraphs [0099]-[0100], where the add-on receives sensor data from the sensors.
at least one output line that is provided for each communication protocol of output data and outputs the output data; see for example paragraph [0093], where the add-on communicates with the vehicle; see also paragraph [0060], where the add-on communicates sensor data to the vehicle.
at least one connector for connecting the output line to the in-vehicle device; see again paragraphs [0093] and [0060], where the system communicates sensor data to the vehicle wirelessly or over a wired connection.
a processing unit configured to perform processing on the input data and cause the output line to output the output data according to the input data; see for example paragraph [0140], where the add-on includes its own processor for processing the data input from the sensors.
;
Bai does not explicitly teach a table that defines determination of whether to cause the processing unit to perform the processing on the input data for each communication protocol or each data type, wherein the processing unit performs the processing on the input data when the processing is performed according to the table, and the processing unit causes the output line to output, as the output data, the input data without performing the processing on the input data when the processing is not performed according to the table. Bai teaches determining whether the system has the appropriate drivers for the sensors, and downloading the corresponding drivers (see paragraphs [0140]-[0175]), and teaches mapping the capabilities of the vehicle to understand the sensor data. See also paragraph [0132], where the operations are performed either on the vehicle processor or the add-on’s processor. Neither does Bai explicitly teach the table includes information for determining a plurality of protocols including each communication protocol or a plurality of data types including each data type, in order to define whether to perform the processing on the input data, and the processing unit is configured to determine each communication protocol of the input data or each data type of the input data based on the table.
However, Zhou does teach a system including a . Zhou teaches a system which outputs raw or processed sensor data based on the vehicle capabilities. See for example paragraphs [0066]-[0067], where the sensors determine whether to output raw or “first target” data to the vehicle based on the capabilities of the vehicle to process the data.
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the sensor add-on system of Bai with the external processing decision step of Zhou with a reasonable expectation of success. Doing so allows the system to determine when to send pre-processed data to the vehicle, or instead when to send raw data to the vehicle.
Zhou does not explicitly teach a table that defines determination of whether to cause the processing unit to perform the processing on the input data for each communication protocol or each data type, nor does Zhou explicitly teach that the table includes information for determining a plurality of protocols including each communication protocol or a plurality of data types including each data type, in order to define whether to perform the processing on the input data, and the processing unit is configured to determine each communication protocol of the input data or each data type of the input data based on the table.
However, Jeong teaches a table that defines determination of whether to cause the processing unit to perform the processing on the input data for each communication protocol or each data type, wherein the processing unit performs the processing on the input data when the processing is performed according to the table, and the processing unit causes the output line to output, as the output data, the input data without performing the processing on the input data when the processing is not performed according to the table; see for example Figure 3 and paragraphs [0053]-[0066], where the system determines that data protocol conversion is necessary, calls a table for the appropriate conversion, and converts data according to its data type.
Jeong also teaches the table includes information for determining a plurality of protocols including each communication protocol or a plurality of data types including each data type, in order to define whether to perform the processing on the input data, and the processing unit is configured to determine each communication protocol of the input data or each data type of the input data based on the table. In addition to Figure 3 and paragraphs [0053]-[0066] above, see also paragraphs [0071]-[0074] and Table 1, where the system determines the communication protocol based on a table.
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the sensor add-on system of Bai, modified by the external processing decision step of Zhou, with the communication protocol conversion table of Jeong with a reasonable expectation of success. Doing so allows the system to convert data from one format to a more standardized, compatible format.
Regarding claim 2, Bai teaches wherein the processing unit is configured to perform first processing that is processing of reducing a data amount of the input data. See for example paragraph [0171], where the vehicle can negotiate with the add-on the reduce the amount of data to be transmitted to the vehicle.
Regarding claim 3, Bai teaches wherein the processing unit is configured to acquire, as the input data, capture data by a camera, and perform, as the first processing, processing of recognizing an object from the capture data. See for example paragraph [0061], where the system can use the add-on camera.
Regarding claim 4, Bai teaches wherein the processing unit is configured to acquire, as the input data, audio data, and perform, as the first processing, processing of recognizing a content of audio from the audio data. See for example paragraph [0103], where the add-on can include a microphone.
Regarding claim 5, Bai teaches wherein the processing unit is configured to acquire, as the input data, obstacle data by an obstacle sensor that detects an obstacle in a periphery of the vehicle, and perform, as the first processing, processing of recognizing a position of at least a position of the obstacle from the obstacle data. See for example paragraph [0103], where the add-on can include sensors used to detect obstacles, such as a camera or 3D camera.
Regarding claim 6, Bai teaches wherein the processing unit is configured to acquire, as the input data, device data from a short distance device, and perform, as the first processing, processing of extracting, from the input data, the device data obtained from the short distance device that is preset. See for example paragraph [0060], where the vehicle can communicate with a smart phone, and in paragraph [0093] this can be done via wire or wirelessly.
Regarding claim 7, Bai teaches wherein the processing unit is configured to acquire, as the input data, cloud data from the cloud server, and perform, as the first processing, processing of extracting, from the input data, the cloud data obtained from the cloud server that is preset. See for example paragraph [0063], where a user’s phone can be used to communicate with a control center, such as OnStar.
Regarding claim 8, Bai teaches wherein the processing unit is configured to acquire, as the input data, . See again paragraph [0093], where the system can communicate via wired or wireless connection, and in paragraph [0100] can send or receive sensor data.
Bai does not explicitly teach communication via controller area network (CAN) protocol.
However, Jeong teaches communication via controller area network (CAN) protocol. See for example paragraph [0010], where the system can communicate via CAN data and convert the data to the appropriate protocol. See also for example Figure 3 and paragraphs [0053]-[0066], where the system determines that data protocol conversion is necessary, calls a table for the appropriate conversion, and converts data according to its data type, including to/from CAN data.
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the sensor add-on system of Bai, modified by the external processing decision step of Zhou, with the communication protocol conversion table of Jeong with a reasonable expectation of success. Doing so allows the system to convert data from one format to a more standardized, compatible format.
Regarding claim 9, Bai teaches wherein the processing unit is configured to perform second processing of converting data obtained by the first processing into data in a preset format configured to be handled by the in-vehicle device, and send data obtained by the second processing to the output line as output data. See paragraphs [0093]-[0100], where the system communicates via shared protocols.
Regarding claim 10, Bai teaches wherein the processing unit is configured to perform, as the second processing, processing of converting the data obtained by the first processing into a common data format including at least a payload and identification information of the payload. See paragraphs [0093]-[0100], where the system communicates via shared protocols.
Regarding claim 11, Bai teaches wherein a numerical number of the output line for the input data having a same type is less than a numerical number of the input line. See for example paragraph [0171], where the input data is reduced before being sent to the vehicle.
Regarding claim 12, Bai teaches wherein a numerical number of the output line for the input data having a same type is more than a numerical number of the input line. See for example paragraph [0172], where the system can upscale the sensor data before sending it to the vehicle.
Regarding claim 13, Bai teaches wherein the input line is provided for each data type of the input data. See for example paragraph [0077], where the input/output is organized by type (e.g. cameras, range sensors, IMUS, etc.).
Regarding claim 14, Bai teaches An in-vehicle device unit comprising: an in-vehicle device configured to communicate with a cloud server configured to manage vehicle data via a communication device; and a plurality of expansion units configured to serve as the expansion unit according to claim 1. See for example paragraphs [0036]-[0037], describing an add-on device. See also paragraph [0132], where the system can communicate with a remote server. Further, see paragraphs [0121]-[0123] describe how the vehicle itself can communicate with a server.
Regarding claim 15, Bai teaches wherein the plurality of expansion units include: a first expansion unit configured to set data obtained from a communication instrument located outside a vehicle to input data; and a second expansion unit configured to set data obtained from a vehicle side instrument located inside the vehicle, wherein the first expansion unit and the second expansion unit include a processing unit configured to perform processing on the input data and output output data according to the input data to the in-vehicle device. See for example paragraph [0046], where the system includes multiple processors and multiple machines. See also paragraph [0230], suggesting multiple add-on devices can be added. See also paragraph [0035] where the system connects to multiple devices.
Regarding claim 18, Bai teaches wherein the expansion unit further includes an expansion the normalization or the data structuring on the input data. Bai teaches determining whether the system has the appropriate drivers for the sensors, and downloading the corresponding drivers (see paragraphs [0140]-[0175]), and teaches mapping the capabilities of the vehicle to understand the sensor data. See also paragraph [0132], where the operations are performed either on the vehicle processor or the add-on’s processor.
Bai does not explicitly teach using a table for determining whether normalization or data structuring on the input data is necessary.
However, Jeong teaches using a table for determining whether normalization or data structuring on the input data is necessary. See for example Figure 3 and paragraphs [0053]-[0066], where the system determines that data protocol conversion is necessary, calls a table for the appropriate conversion, and converts data according to its data type.
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the sensor add-on system of Bai, modified by the external processing decision step of Zhou, with the communication protocol conversion table of Jeong with a reasonable expectation of success. Doing so allows the system to convert data from one format to a more standardized, compatible format.
Regarding claim 21, Bai teaches wherein when the normalization on the input data is performed to generate normalization information, . Bai teaches determining whether the system has the appropriate drivers for the sensors, and downloading the corresponding drivers (see paragraphs [0140]-[0175]), and teaches mapping the capabilities of the vehicle to understand the sensor data. See also paragraph [0132], where the operations are performed either on the vehicle processor or the add-on’s processor.
Bai does not explicitly teach that the generated normalization information includes at least one of identification information indicating a transmission source of the input data, position information indication data position in a data field of the input data, or control label information indicating at least one of an intake air temperature, an engine rotation speed, resolution, or an offset amount.
However, Jeong teaches that the generated normalization information includes at least one of identification information indicating a transmission source of the input data, position information indication data position in a data field of the input data, or control label information indicating at least one of an intake air temperature, an engine rotation speed, resolution, or an offset amount. See for example paragraphs [0076]-[0079], where the system includes data fields in its packets in predetermined positions. See also for example paragraph [0068], where the data packets include a source address (reading on transmission source of the input data).
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the sensor add-on system of Bai, modified by the external processing decision step of Zhou, with the communication protocol conversion table of Jeong with a reasonable expectation of success. Doing so allows the system to convert data from one format to a more standardized, compatible format.
Regarding claim 22, Bai teaches wherein when the input data is an image data, a first output line among the at least one output line outputs the image data, . See for example paragraph [0112], where the add-on sensor device include add-on-device cameras. See again paragraphs [0093] and [0060], where the system communicates sensor data to the vehicle wirelessly or over a wired connection.
Bai does not explicitly teach the processing unit executes image recognition on the image data input via the at least one input line to generate a standard format of target objection information, and a second output line among the at least one output line outputs the standard format information.
However, Zhou teaches the processing unit executes image recognition on the image data input via the at least one input line to generate a standard format of target objection information, and a second output line among the at least one output line outputs the standard format information. Zhou teaches a system which outputs raw or processed sensor data. See for example paragraphs [0066]-[0067], where the sensors determine whether to output raw or “first target” data to the vehicle based on the capabilities of the vehicle to process the data, where converting the input raw data into output “first target” data reads on executes image recognition on the image data input via the at least one input line to generate a standard format of target objection information, and a second output line among the at least one output line outputs the standard format information.
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the sensor add-on system of Bai with the external processing decision step of Zhou with a reasonable expectation of success. Doing so allows the system to determine when to send pre-processed data to the vehicle, or instead when to send raw data to the vehicle.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
US20110055292 by Madau et al. teaching a gateway that extracts vehicle data and converts it into standard form.
US20150087356 by Kobayashi teaching a system that converts data output into a more usable form.
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 JORDAN THOMAS SMITH whose telephone number is (571)272-0522. The examiner can normally be reached Monday - Friday, 9am - 5pm.
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, Anne Antonucci can be reached at (313) 446-6519. 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.
/JORDAN T SMITH/Examiner, Art Unit 3666
/ANNE MARIE ANTONUCCI/Supervisory Patent Examiner, Art Unit 3666