DETAILED ACTION
1. This office action is a response to the Application/Control Number: 18/241,577 filed on 09/01/2023.
Claims Status
2. This office action is based upon claims received on 12/12/2025, which replace all prior or other submitted versions of the claims.
-Claims 10, 11, 12 are cancelled.
-Claims 1-9, 13-15 are pending.
-Claims 1-9, 13-15 are rejected.
Notice of Pre-AIA or AIA Status
3. The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Priority
4. Acknowledgment is made of applicant’s claim for foreign priority under 35 U.S.C. 119 (a)-(d). Receipt is acknowledged of certified copies of papers submitted under 35 U.S.C. 119(a)-(d), which papers have been placed of record in the file.
5. Acknowledgment is made of a continuation of CON of PCT/EP2022/054696 filed 02/24/2022.
Response to Amendments/Remarks
6. Applicant's remarks/arguments, see page 11, filed on 12/12/2025, with respect to Drawings have been considered in light of applicant’s amendments to the drawings including labels for the drawings as submitted. The drawing objections presented in the previous office action have been withdrawn.
7. Applicant's remarks/arguments, see pages 11-12, filed on 12/12/2025, with respect to 35 U.S.C. §112(f) have been noted in light of the requirements set forth in the 112 (f) interpretation provided in the previous office action. Regarding additional paragraphs and figures cited by applicant, a review indicates correspondence in these applicant cited paragraphs and figures, to the structures identified in the figures and paragraphs previously cited by the office in the previous office action.
8. Applicant's remarks/arguments, see page 12, filed on 12/12/2025, with respect to Claim objections have been considered in light of applicant’s amendments. The claim objections to claims 1, 2, 8, 9, 10, 12, 13, 14 as presented in the previous office action have been withdrawn.
9. Applicant's remarks/arguments, see page 12, filed on 12/12/2025, with respect to Claim Rejections – 35 USC § 112 (b) have been considered in light of applicant’s amendments and cancellation of claims 10-12. The claim rejections under 35 USC § 112 (b) for claim 1-15 as applicable and presented in the previous office action have been withdrawn.
10. Applicant's remarks/arguments, see pages 12-14, filed on 12/12/2025, with respect to REMARKS/ARGUMENTS, Claim Rejections – 35 USC § 103 have been considered but are not persuasive because the arguments do not apply to the grounds of rejection being used in the current rejection.
Furthermore, remarks with respect to any applicable Dependent Claims have been considered, and are not persuasive at least via dependency to the independent claims and via individual rejections addressing the specific claims.
The rejection has been revised and set forth below according to the amended claims (see Office Action).
A. To the extent this office action relies on REIDL CHRISTIAN et al (DE-102015104042-A1), i.e. “REIDL” 2015-09-24 in view of YAMAKOSHI et al. (US 20160059853 A1), i.e. “YAMAKOSHI” for rejection of claim 1 (used as an example representing claim 9 and claim 13) under 35 U.S.C. 103 , the office respectfully contends applicant’s remarks or arguments directed to REIDL and YAMAKOSHI are not persuasive.
B. Applicant in its remarks (See page 14 (ln 4-6, 11-12 ), utilizing independent claim 1, indicates: “there is no disclosure of the alleged receiver device 22 also utilizing the cyclic redundancy check (alleged calculation rule) of the sensor device, as required by claim 1" and “Yamakoshi fails to cure the above noted deficient teachings of Reidl”.
C. In response, utilizing portions of claim 1 (used as an example representing claim 9 and claim 13) upon which REIDL is relied upon i.e. for the rejection of claim 1 under 35 U.S.C. 103 over REIDL in view of YAMAKOSHI (See office action), the office presents the subject limitations of applicant’s contention where REIDL teaches:
calculating, by the receiver test value generator, a receiver test value with theat least one variable value (REIDL FIG. 4 & ¶0045 […] Figure 4 shows a trigger pulse 40 that can be sent from a master device to slave devices to specify a slave device to respond to the trip pulse; ¶0049 […] when the data is received, the receiving unit, such as a master device, includes the expected identity (which corresponds to the ID specified by the transmitted trigger pulse) in its own checksum calculation, e.g. a CRC calculation. If the checksum calculation does not match the received data (including the expected ID), the master device knows that the data was either not received correctly, the CRC was received incorrectly, or the ID is incorrect, which can happen, for example, if an "incorrect" slave device responds to the trigger pulse (e.g., due to incorrect decoding of the trigger pulse; FIG. 6 & ¶0054 […] on a receiver side, such as a master page, such as receiver 11 from Fig. 1 or the control device 22 from Fig. 2 When checking the checksum, such as the CRC, the recipient enters the expected information (such as the expected ID and/or the expected traversal counter) in the received data to calculate its own checksum and evaluate whether the checksum is correct. A method according to a corresponding embodiment is shown in Fig. 6 ; ¶0055 […] procedure from Fig. 6 determining whether the checksum received is correct, i.e. whether the checksum received matches a checksum calculated on the basis of the data received in conjunction with expected information, such as an ID and/or a meter value, such as a continuous meter value. If the checksum is correct (YES for reference 61), the procedure for reference 63 involves processing the received data. If the checksum received is incorrect (NO for reference 61), a reset of one or more consistent values may be indicated in an embodiment for reference 62);
Which the office action respectfully contends and notes discloses: per ¶0049 & FIG. 6 & ¶0055 […] procedure from Fig. 6 determining whether the checksum received is correct, i.e. whether the checksum received matches i.e. a checksum calculated on the basis of the data received reads on: calculating, by the receiver test value generator, a receiver test value , and furthermore at the receiver i.e. a checksum calculated on the basis of i.e. the data received in conjunction with expected information, such as an ID and/or a meter value reads on: with the selected at least one variable value i.e. an ID as in per ¶0047 applied by the slave sensor sending the i.e. calculation of the cyclic redundancy check including i.e. reference signs 46 in Fig. 4, as well as i.e. not only the actual data values sent, i.e. SCN, D1, D2, D3 and the passing counter RC, but also the ID of the sending sensor device. Therefore the receiver calculates the checksum using the data and ID taught.
and with the selected calculation rule from at (REIDL FIG. 4 & ¶0045 See above; ¶0049 See above; ¶0054 See above; ¶0055 See above);
Which the office action respectfully contends and notes discloses: Furthermore Per FIG. 6 & ¶0049, ¶0054 i.e. calculate its own checksum and evaluate whether the checksum is correct and per FIG. 6 & ¶0055 determining whether the checksum received is correct, i.e. whether the checksum received matches a checksum calculated on the basis of the data received in conjunction with expected information, such as an ID and/or a meter value i.e. receivers own check sum value from the CRC calculation rule matches the CRC check sum of the transmitter received i.e. correct match of CRC Check sum reads on: and with the selected calculation rule which is a match. Furthermore i.e. whether the checksum received matches a checksum calculated i.e. on the basis of the data received in conjunction with expected information, such as an ID and/or a meter value reads on: from at the sensor measurement information of the data section of the data packet , therefore i.e. the CRC checksum calculated at the receiver to be a match to the CRC check sum transmitted by applying the same input data, ID transmitted from the transmitter, the receiver’s CRC rule has to be a match to the CRC rule of the transmitter.
D. As such, the office action respectfully contends that applicant’s remarks or arguments as cited are not persuasive since REIDL as relied upon teaches and reads upon claim 1 elements of applicant’s contention as referenced. Furthermore, while applicant’s remarks referenced above point to features “utilizing the cyclic redundancy check (alleged calculation rule) of the sensor device” nothing in claims recite “utilizing the cyclic redundancy check (alleged calculation rule) of the sensor device” or how the claims as recited distinguish from the teachings of REIDL as presented. Rather, the claims recite “with the selected calculation rule from at ” which REIDL teaches as noted herein above. Furthermore the office action relies upon disclosures of REIDL in view of YAMAKOSHI in combination as presented in the 35 U.S.C. 103 rejection presented herein (See office action) for the rejection of the entirety of claim 1.
E. Furthermore with the rejection of claim 1 presented under 35 U.S.C. 103 as being unpatentable over REIDL in view of YAMAKOSHI (See office action) in combination, the office action respectfully contends that applicant’s arguments against prior art YAMAKOSHI are directed against the references individually, and one cannot show non-obviousness by attacking references individually where the rejections are based on combinations of references used to address the rejection of applicant’s claims (See In re Keller, 642 F.2d 413, 208 USPQ 871 (CCPA 1981); In re Merck & Co., 800 F.2d 1091, 231 USPQ 375 (Fed. Cir. 1986)).
F. Applicant is respectfully directed to the grounds of rejection of claims now presented under 35 U.S.C. 103 as being unpatentable over REIDL in view of YAMAKOSHI, where the disclosure of each and every limitation of the now presented Claim 1 is taught and rejected.
The rejection has been revised and set forth below according to the amended claims (see Office Action).
Claim Rejections - 35 USC § 112
11. The following is a quotation of 35 U.S.C. 112(a):
(a) IN GENERAL. The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), first paragraph:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same and shall set forth the best mode contemplated by the inventor of carrying out his invention.
12. Claim 9 is rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for pre-AIA the inventor(s), at the time the application was filed, had possession of the claimed invention.
Claim 9 recites “select a calculation rule received from the sensor device” and “with atthe calculation rule received from the sensor device”.
While application appears to indicate support in specification such as in ¶0009, ¶0057 for “a calculation rule for calculating a sensor test value from respective sensor measurement information that is communicated” as recited in other claims such as claim 1 and claim 13, nowhere in the specification is disclosed “a calculation rule received from the sensor device” and “the calculation rule received from the sensor device” i.e. the specification does not specifically disclose “calculation rule received from the sensor device” and the specification does not appear to clearly indicate how “a calculation rule” is “received from the sensor device” or how “the calculation rule” is “received from the sensor device”.
More particularly, both the present application and previous applications from which the current application claims continuity fail to disclose “a calculation rule received from the sensor device” and “the calculation rule received from the sensor device” as recited in Claim 9, i.e. there is no support in the current specification, and the limitation is not a part of original application.
In view of the above analysis, the instant specification fails to support an adequate written description of the current claim. Thus, the instant claim introduces elements or limitations which are not supported by the as-filed disclosure violate the written description requirement. Under 35 U.S.C. 119(e), the written description and drawing(s) (if any) of the provisional application must adequately support and enable the subject matter claimed in the nonprovisional application that claims the benefit of the provisional application. In New Railhead Mfg., L.L.C. v. Vermeer Mfg. Co., 298 F.3d 1290, 1294, 63 USPQ2d 1843, 1846 (Fed. Cir. 2002), the court held that for a nonprovisional application to be afforded the benefit date of the provisional application, “the specification of the provisional must ‘contain a written description of the invention and the manner and process of making and using it, in such full, clear, concise, and exact terms,’ 35 U.S.C. 112¶1, to enable an ordinarily skilled artisan to practice the invention claimed in the nonprovisional application.” See MPEP Section 211.05. Therefore, the claim must be rejected under 35 U.S.C. 112(a) or pre-AIA 35 U.S.C. 112, para. 1, for lack of adequate written description.
If Applicant can identify support for the limitations “a calculation rule received from the sensor device” and “the calculation rule received from the sensor device” in the spec, Examiner requests the Applicant to identify the exact location. If applicant is of the opinion that the written description of the specification already expressly discloses the corresponding acts perform the claimed function, applicant should clarify the record by “stating on the record what corresponding acts, which are expressly/implicitly/inherently set forth in the written description of the specification, perform the claimed function”.
For the purpose of examinations, the examiner will interpret the claims as best understood.
Claim Rejections - 35 USC § 103
13. 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.
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102
and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory
basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and
the rationale supporting the rejection, would be the same under either status.
This application currently names joint inventors. In considering patentability of the claims the
examiner presumes that the subject matter of the various claims was commonly owned as of the
effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised
of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that
was not commonly owned as of the effective filing date of the later invention in order for the examiner
to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art
against the later invention.
14. Claims 1, 3, 5, 8-15 are rejected under 35 U.S.C. 103 as being unpatentable over REIDL CHRISTIAN et al (DE-102015104042-A1), i.e. “REIDL” 2015-09-24 in view of YAMAKOSHI et al. (US 20160059853 A1), i.e. “YAMAKOSHI”
Regarding Claim 1. REIDL teaches: A method for a vehicle to communicate information between a sensor device of a system and a receiver device of the system (REIDL – FIG.2 & FIG. 3 & ¶0001 […] Various protocols are used for communication between devices, e.g. in automotive applications; ¶0037 […] Fig. 2, a receiver or other control device 22 (e.g. master) communicate with a large number of transmitters, such as sensors 24 and 26 in a system 20 […] System 20 can be part of a vehicle's electrical system ; ¶0040 […] The process from Fig. 3 can be used in devices and systems such as those referred to in Fig. 1 and Fig. 2; NOTE-DISCLOSURE & TEACHING: per ¶0040 i.e. process reads on: A method , per 0001 i.e. automotive applications & per ¶0037 System 20 can be part of a vehicle's electrical system reads on: for a vehicle, per ¶0040 i.e. used in used in devices and systems such as those referred to in Fig. 1 and Fig. 2 where per ¶0037 i.e. control device 22 (e.g. master) communicate with a large number of transmitters, such as sensors 24 and 26 in a system 20 reads on: to communicate information between a sensor device of a system and a receiver device of the system ),
wherein the system has at least two sensor devices (REIDL – FIG. 2 & ¶0037 See above; NOTE-DISCLOSURE & TEACHING: i.e. sensors 24 and 26 in a system 20 reads on: wherein the system has at least two sensor devices ),
wherein the two sensor devices each have a sensor test value generator with at least one variable value (REIDL – FIG. 4 & ¶0037 See above; ¶0047 […] After the trigger pulse, the slave device responds, as indicated by a curve section 44 , with a synchronization pulse and various values SCN, D1 to D3 and a continuous counter value (RC value), which are examples of sent data values, followed by a cyclic redundancy check CRC 45 as an example of a checksum [...] A calculation of the cyclic redundancy check includes, as with reference signs 46 in Fig. 4, not only the actual data values sent, i.e. SCN, D1, D2, D3 and the passing counter RC, but also the ID written as a 4-bit value (43 from Fig. 4); NOTE-DISCLOSURE & TEACHING: per ¶0047 for each sensor where FIG. 2 & ¶0037 i.e. sensors 24 and 26 in a system 20 reads on: wherein the two sensor devices , and per ¶0047 i.e. A calculation of the cyclic redundancy check includes not only the actual data values sent, i.e. SCN, D1, D2, D3 and the passing counter RC, but also the ID written as a 4-bit value reads on: each have a sensor test value generator that generates CRC and takes as input i.e. i.e. SCN, D1, D2, D3 and the passing counter RC, but also the ID written as a 4-bit value in which i.e. RC and ID reads on: with at least one variable value where RC is a value that can be incremented and ID is variable based upon Sensor)
and with a calculation rule for calculating a sensor test value from respective sensor measurement information that is communicated (REIDL – FIG. 4 & ¶0037 See above; ¶0042 […] After receiving the trip pulse, data is sent together with a checksum as in a cyclic redundancy check […] At reference sign 31, the procedure from Fig. 3 the inclusion of information, e.g. a feedback such as the ID mentioned above or a counter such as a continuous counter in the calculation of the checksum; ¶0043 […] reference sign 32 , data is transmitted together with the checksum, e.g. in a data frame ; ¶0045 […] Figure 4 shows a trigger pulse 40 that can be sent from a master device to slave devices to specify a slave device to respond to the trip pulse ; ¶0047 See above; NOTE-DISCLOSURE & TEACHING: per ¶0047 a cyclic redundancy check CRC 45 i.e. A calculation of the cyclic redundancy check reads on: and with a calculation rule as an example of i.e. CRC a checksum reads on: a sensor test value, and per ¶0047 i.e. A calculation of the cyclic redundancy check includes not only the actual data values sent, i.e. SCN, D1, D2, D3 and the passing counter RC, but also the ID written as a 4-bit value reads on: from respective sensor measurement information that generates CRC and takes as input i.e. i.e. SCN, D1, D2, D3 and the passing counter RC, but also the ID, where per ¶0043 i.e. 32 , data is transmitted together with the checksum, e.g. in a data frame and per ¶0047 fig. 4 D1, D2, D3 reads on that is communicated),
wherein the at least one variable value of the sensor test value generator rule of the sensor test valuegenerator of each of the two sensor devices are different (REIDL – FIG. 4 & ¶0037 See above; ¶0042 See above; ¶0043 see above; ¶0045 […] See above ; ¶0047 See above; NOTE-DISCLOSURE & TEACHING: per ¶0047 each sensor depends on the respective ID and RC value reads on: wherein the at least one variable value of the sensor test value generator of each of the two sensor devices are different since the sensors are different . Furthermore i.e. CRC checksum for each sensor depends on the respective ID and RC value reads on: and the calculation rule of the sensor test value generator of each of the two sensor devices are different i.e. as generated from the individually separate sensors with different ID and RC value),
and wherein the receiver device has a receiver test value generator with the at least one variablevalue of the sensor test value generator (REIDL FIG. 4 & ¶0049 […] when the data is received, the receiving unit, such as a master device, includes the expected identity (which corresponds to the ID specified by the transmitted trigger pulse) in its own checksum calculation, e.g. a CRC calculation. If the checksum calculation does not match the received data (including the expected ID), the master device knows that the data was either not received correctly, the CRC was received incorrectly, or the ID is incorrect, which can happen, for example, if an "incorrect" slave device responds to the trigger pulse (e.g., due to incorrect decoding of the trigger pulse; NOTE-DISCLOSURE & TEACHING: per ¶0049 i.e. a master device, includes the expected identity (which corresponds to the ID specified by the transmitted trigger pulse) in its own checksum calculation, e.g. a CRC calculation reads on: and wherein the receiver device has a receiver test value generator, where i.e. If the checksum calculation does not match the received data (including the expected ID), the master device knows that the data was either not received correctly, the CRC was received incorrectly, or the ID is incorrect reads on: with the at least one variable value of the sensor test value generator for which the result will incorrect for the wrong ID and correct for the matching ID, where per FIG. 2 & ¶0037 as applied to i.e. sensors 24 and 26 in a system 20 reads on: of each of the two sensor devices)
and with rule of the sensor test value generator of each of the two sensor devices (REIDL FIG. 4 & ¶0049 See above; FIG. 6 & ¶0054 […] on a receiver side, such as a master page, such as receiver 11 from Fig. 1 or the control device 22 from Fig. 2 When checking the checksum, such as the CRC, the recipient enters the expected information (such as the expected ID and/or the expected traversal counter) in the received data to calculate its own checksum and evaluate whether the checksum is correct. A method according to a corresponding embodiment is shown in Fig. 6 ; ¶0055 […] procedure from Fig. 6 determining whether the checksum received is correct, i.e. whether the checksum received matches a checksum calculated on the basis of the data received in conjunction with expected information, such as an ID and/or a meter value, such as a continuous meter value. If the checksum is correct (YES for reference 61), the procedure for reference 63 involves processing the received data. If the checksum received is incorrect (NO for reference 61), a reset of one or more consistent values may be indicated in an embodiment for reference 62 ; NOTE-DISCLOSURE & TEACHING: Per FIG. 6 & ¶0049, ¶0054 i.e. its own checksum and evaluate whether the checksum is correct and per FIG. 6 ¶0055 determining whether the checksum received is correct, i.e. whether the checksum received matches a checksum calculated on the basis of the data received in conjunction with expected information, such as an ID and/or a meter value reads on: and with the calculation rule of the sensor test value generator i.e. receivers own check sum value from the CRC calculation rule matches the CRC check sum of the transmitter included in the data transmitted and therefore the receivers own check sum is the same CRC rule as the transmitters. Furthermore per ¶0049 i.e. per ¶0049 & ¶0055 i.e. the expected identity ID of slave device applied to each of per FIG. 2 & ¶0037 i.e. sensors 24 and 26 in a system 20 reads on: of each of the two sensor devices ),
the method comprising: calculating by the sensor test value generator, the sensor test value as a function of the at least one variable value (REIDL – FIG. 4 & ¶0037 See above; ¶0042 See above; ¶0043 see above; ¶0045 […] See above ; ¶0047 See above; NOTE-DISCLOSURE & TEACHING: per ¶0047 i.e. a cyclic redundancy check CRC 45 as an example of i.e. a checksum reads on: the method comprising: calculating by the sensor test value generator, per ¶0047 i.e. a checksum reads on: the sensor test value [...] A calculation of the cyclic redundancy check i.e. includes, as with reference signs 46 in Fig. 4, not only the actual data values sent, i.e. SCN, D1, D2, D3 and the passing counter RC, but also i.e. the ID reads on: as a function of the at least one variable value )
and as a function of the calculation rule from (REIDL – FIG. 4 & ¶0037 See above; ¶0042 See above; ¶0043 see above; ¶0045 […] See above ; ¶0047 See above; NOTE-DISCLOSURE & TEACHING: per ¶0047 i.e. a cyclic redundancy check CRC 45 as an example of a checksum and i.e. A calculation of the cyclic redundancy check i.e. a check sum reads on: and as a function of the calculation rule i.e. the check sum value is calculated via CRC check calculation rule, where i.e. [...] A calculation of the cyclic redundancy check i.e. includes, as with reference signs 46 in Fig. 4, not only the actual data values sent, i.e. SCN, D1, D2, D3 reads on: from the sensor measurement information i.e. checksum determined as a function of CRC check utilizing or form sensor measurement information i.e. SCN, D1, D2, D3);
generating a data packet, wherein the data packet has at least a data section with the sensor measurement information (REIDL – FIG. 4 & ¶0037 See above; ¶0042 See above; ¶0043 see above; ¶0045 […] See above ; ¶0047 See above; NOTE-DISCLOSURE & TEACHING: per ¶0047 and FIG. 4 i.e. After the trigger pulse, the slave device responds, as indicated by a curve section 44 , with a synchronization pulse and i.e. various values SCN, D1 to D3 and a continuous counter value (RC value), which are examples of sent data values, followed by a cyclic redundancy check CRC 45 reads on: generating a data packet , where i.e. values SCN, D1 to D3 and a continuous counter value (RC value) reads on: wherein the data packet has at least a data section with the sensor measurement information, and per FIG. 4 & ¶0047 i.e. followed by a cyclic redundancy check CRC 45 as i.e. a checksum reads on: and a test section with the );
sending the data packet through a transmission channel to the receiver device (REIDL – FIG. 2 & ¶0037 […] Fig. 2, the electrical coupling of the control device 22 with a three-wire connection to the first sensor 24 and the second sensor 26 includes a VDD power supply line 28, a data line 25 and a reference line, such as a ground line 27; FIG. 4 & ¶0037 See above; ¶0042 See above; ¶0043 see above; ¶0045 […] See above ; ¶0047 See above; NOTE-DISCLOSURE & TEACHING: per ¶0047 and FIG. 4 i.e. After the trigger pulse, the slave device responds, as indicated by a curve section 44 , with a synchronization pulse and i.e. various values SCN, D1 to D3 and a continuous counter value (RC value), which are examples of sent data values reads on: sending the data packet , where per ¶0027 i.e. a data line 25 reads on: through a transmission channel to the receiver device via electrical coupling of the control device 22 with a three-wire connection to the first sensor 24 and the second sensor 26);
receiving, by the receiver device, the data packet from the sensor device (REIDL FIG. 4 & ¶0045 See above; ¶0049 See above; NOTE-DISCLOSURE & TEACHING: per ¶0045 i.e. a trigger pulse 40 that can be sent from a master device to slave devices to specify a slave device to respond to the trip pulse and in response per ¶0049 i.e. when the data is received reads on: receiving, by the receiver device, the data packet from the sensor device );
selecting, by the receiver device, the at least one variable value of the sensor test value generator as a function of the sensor device and selection by the receiver device of the calculation rule of the sensor test value generator as a function of the sensor device (REIDL FIG. 4 & ¶0045 See above; ¶0049 See above; ¶0054 See above; ¶0055 See above; NOTE-DISCLOSURE & TEACHING: per ¶0049 & FIG. 6 & ¶0055 […] procedure from Fig. 6 determining whether the checksum received is correct, i.e. whether the checksum received matches i.e. a checksum calculated on the basis of the data received in conjunction with expected information, i.e. such as an ID and/or a meter value, such as a continuous meter value reads on: selecting, by the receiver device, the at least one variable value of the sensor test value generator i.e. an ID as in per ¶0047 applied by the slave sensor sending the i.e. calculation of the cyclic redundancy check including i.e. reference signs 46 in Fig. 4, as well as i.e. not only the actual data values sent, i.e. SCN, D1, D2, D3 and the passing counter RC, but also the ID of the sending sensor device reads on: as a function of the sensor device. Furthermore Per FIG. 6 & ¶0049, ¶0054 i.e. its own checksum and evaluate whether the checksum is correct and per FIG. 6 ¶0055 determining whether the checksum received is correct, i.e. whether the checksum received matches a checksum calculated on the basis of the data received in conjunction with expected information, such as an ID and/or a meter value i.e. receivers own check sum value from the CRC calculation rule matches the CRC check sum of the transmitter reads on: and selection by the receiver device of the calculation rule of the sensor test value generator and therefore the receivers own check sum is the same CRC rule as the transmitters. Furthermore i.e. receivers own check sum value from the CRC calculation rule matches the CRC check sum of the transmitter included in the data transmitted by the sensor slave device reads on: as a function of the sensor device);
calculating, by the receiver test value generator, a receiver test value with theat least one variable value (REIDL FIG. 4 & ¶0045 See above; ¶0049 See above; ¶0054 See above; ¶0055 See above; NOTE-DISCLOSURE & TEACHING: per ¶0049 & FIG. 6 & ¶0055 […] procedure from Fig. 6 determining whether the checksum received is correct, i.e. whether the checksum received matches i.e. a checksum calculated on the basis of the data received reads on: calculating, by the receiver test value generator, a receiver test value , and furthermore at the receiver i.e. a checksum calculated on the basis of i.e. the data received in conjunction with expected information, such as an ID and/or a meter value reads on: with the selected at least one variable value i.e. an ID as in per ¶0047 applied by the slave sensor sending the i.e. calculation of the cyclic redundancy check including i.e. reference signs 46 in Fig. 4, as well as i.e. not only the actual data values sent, i.e. SCN, D1, D2, D3 and the passing counter RC, but also the ID of the sending sensor device).
and with the selected calculation rule from at (REIDL FIG. 4 & ¶0045 See above; ¶0049 See above; ¶0054 See above; ¶0055 See above; NOTE-DISCLOSURE & TEACHING: Furthermore Per FIG. 6 & ¶0049, ¶0054 i.e. its own checksum and evaluate whether the checksum is correct and per FIG. 6 ¶0055 determining whether the checksum received is correct, i.e. whether the checksum received matches a checksum calculated on the basis of the data received in conjunction with expected information, such as an ID and/or a meter value i.e. receivers own check sum value from the CRC calculation rule matches the CRC check sum of the transmitter received i.e. correct match reads on: and with the selected calculation rule which is a match. Furthermore i.e. whether the checksum received matches a checksum calculated i.e. on the basis of the data received in conjunction with expected information, such as an ID and/or a meter value reads on: from at the sensor measurement information of the data section of the data packet i.e. the CRC checksum calculated at the receiver to be a match to the CRC check sum transmitted by applying the same input data, ID transmitted from the transmitter (see FIG. 4 & ¶0047), the receiver’s CRC rule has to be a match to the CRC rule of the transmitter);
and checking the received sensor measurement information of the data section of the data packet for a transmission error based on the (REIDL - FIG. 4 & ¶0045 See above; ¶0047 see above; ¶0049 See above; ¶0054 See above; ¶0055 See above; NOTE-DISCLOSURE & TEACHING: per ¶0049 i.e. If the checksum calculation does not match the received data (including the expected ID) reads on: and checking the received sensor measurement information of the data section of the data packet , i.e. the master device knows that the data was either not received correctly, the CRC was received incorrectly, or the ID is incorrect reads on: for a transmission error , where per ¶0049 i.e. when the data is received and per Fig. 6 & ¶0055 i.e. determining whether the checksum received is correct, i.e. whether the checksum received reads on: based on the sensor test value,. Furthermore per ¶0049 i.e. the receiving unit, such as a master device, includes the expected identity (which corresponds to the ID specified by the transmitted trigger pulse) in its own checksum calculation, e.g. a CRC calculation such as per Fig. 6 & ¶0055 i.e. whether the checksum received matches i.e. a checksum calculated reads on: and the receiver test value per ¶0055 i.e. calculated on the basis of the data received in conjunction with expected information, such as an ID ).
REIDL does not appear to explicitly teach or strongly suggest (i.e. implies see italicized portions): data packet;
YAMAKOSHI teaches: generating a data packet, wherein the data packet has at least a data section with the sensor measurement information (YAMAKOSHI FIG. 1 & FIG. 2 & ¶0039 […] sensor domain 20 includes the front camera ECU 201 and the radar ECU 202. The front camera ECU 201 is connected with a front camera 211. The radar ECU 202 is connected with a radar 22; ¶0058 data frame includes an ID field, a control field, a data field and a CRC field; ¶0059 […] According to the CAN protocol, each ECU transmits the data frame to all of the other ECUs by way of broadcasting. When the frame ID included in the received data frame is a processing target frame ID, each ECU executes processing based on this data frame; ¶0060 […] each of the ECUs 201 and 202 of the sensor domain 20 includes the frame ID of sensor data in the ID field, and transmits data frame including sensor data in the data field […] different frame IDs are set to the object data transmitted from the front camera ECU 201 and calculated distance data transmitted from the radar ECU 202; ¶0065 A CRC field is a portion of the data frame including a CRC (Cyclic Redundancy Check) value for performing error detection. An ECU which transmits a data frame calculates and sets the CRC value based on data of a plurality of fields including ID fields and data fields. Thus, the ECU which has received the data frame can detect a data error by calculating the CRC value from this data frame and comparing the CRC value and a CRC value included in the data frame ; NOTE-DISCLOSURE & TEACHING: i.e. per ¶0039 sensor domain 20 includes The front camera ECU 201 is connected with a front camera 211. The radar ECU 202 is connected with a radar 22 which per ¶0060 i.e. each of the ECUs 201 and 202 of the sensor domain 20 i.e. includes the frame ID of sensor data in the ID field, and transmits data frame including sensor data in the data field reads on: generating a data packet, wherein the data packet has at least a data section with the sensor measurement information reads on: and a test section, where per ¶0065 i.e. the ECU which has received the data frame can detect a data error by calculating the CRC value from this data frame and comparing the CRC value and a CRC value included in the data frame reads on: with the );
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of REIDL with teachings of YAMAKOSHI, since YAMAKOSHI enables a redundant system to perform failure diagnosis, and procedures that detect a failure and notify the driver of an error and, consequently, improve function safety at a system level (YAMAKOSHI - ¶0132, ¶0163).
Regarding Claim 3. (Currently Amended) REIDL in view of YAMAKOSHI teaches: The method according to claim 1,
furthermore REIDL teaches: wherein the receiver device sends a query to at least one of (note: limitations subsequent to recitation “at least one of” are interpreted as presented in the alternative and not required together i.e. for the purposes of patentable weight) the two sensor devices to request at least one data packet from [[the]] at least one sensor device of the two sensor devices (REIDL – FIG. 4 & ¶0037 See Claim 1; ¶0042 See Claim 1; ¶0043 See Claim 1; ¶0045 […] See Claim 1 ; ¶0047 See Claim 1; NOTE-DISCLOSURE & TEACHING: ¶0045 […] Figure 4 shows a trigger pulse 40 that can be sent from a master device to slave devices reads on: wherein the receiver device sends a query to at least one of the two sensor devices to specify a slave device to respond to the trip pulse reads on: to request , where per ¶0047 i.e. After the trigger pulse, the slave device responds, as indicated by a curve section 44 , with a synchronization pulse and various values SCN, D1 to D3 and a continuous counter value (RC value), which are examples of sent data values reads on: at least one data packet from i.e. the slave device responds reads on: at least one sensor device where i.e. a trigger pulse 40 that can be sent from a master device i.e. to slave devices reads on: of the two sensor devices).
Regarding Claim 5. (Currently Amended) REIDL in view of YAMAKOSHI teaches: The method according to claim 1,
furthermore REIDL teaches: wherein the [[two]] sensor test value generator of each of the at least two sensor devices and the receiver test value generator of the receiver device have [[the]] a same calculation rule for calculation of the sensor test value (REIDL - FIG. 4 & ¶0045 See Claim 1; ¶0047 See Claim 1; ¶0049 See Claim 1; NOTE-DISCLOSURE & TEACHING: per ¶0047 for each sensor where FIG. 2 & ¶0037 i.e. sensors 24 and 26 in a system 20 reads on: wherein the [[two]] sensor test value and per ¶0049 i.e. a master device , includes the expected identity (which corresponds to the ID specified by the transmitted trigger pulse) in its own checksum calculation, e.g. a CRC calculation reads on: and the receiver test value generator of the receiver device, where i.e. If the checksum calculation does not match the received data (including the expected ID) reads on: have a same calculation rule for calculation of the sensor test value to determine i.e. the master device knows that the data was either not received correctly such as the CRC was received incorrectly or alternately if matches received correctly – the CRC calculation matches therefore rule matches also See FIG. 6 & ¶0054, ¶0055 in claim 1)
or (note: limitations separated by a recitation “or” are interpreted as presented in the alternative and not required together i.e. for the purposes of patentable weight)
for calculation of the receiver test value (note: limitations separated by a recitation “or” are interpreted as presented in the alternative and not required together i.e. for the purposes of patentable weight),
and wherein the receiver test value generator has only the one calculation rule (REIDL - FIG. 4 & ¶0045 See Claim 1; ¶0047 See Claim 1; ¶0049 See Claim 1; NOTE-DISCLOSURE & TEACHING: per ¶0049 i.e. a master device , includes the expected identity (which corresponds to the ID specified by the transmitted trigger pulse) in its own checksum calculation reads on: and wherein the receiver test value generator has only the one calculation rule applied to both sensors by matching IDs, such as i.e. If the checksum calculation does not match the received data (including the expected ID), the master device knows that the data was either not received correctly, the CRC was received incorrectly, or the ID is incorrect. Furthermore i.e. that the CRC calculation matches therefore rule matches also See FIG. 6 & ¶0054, ¶0055 in claim 1 there is one CRC applied ).
Regarding Claim 9. (currently amended) REIDL teaches: A receiver device (REIDL – FIG.2 & FIG. 3 & ¶0001 See claim 1; ¶0037 See claim 1; ¶0040 See claim 1; NOTE-DISCLOSURE & TEACHING: per ¶0037 i.e. a receiver or other control device 22 (e.g. master) reads on: A receiver device communicates with a large number of transmitters, such as sensors 24 and 26 in a system 20),
comprising: a selection unit (REIDL - ¶0034 […] receiver 11 is part of an integrated circuit chip and transmitter 12 is part of another integrated circuit chip. In other embodiments, receiver 11 and transmitter 12 can be part of the same integrated circuit chip. In one embodiment, receiver 11 may be a control device, such as an ECU. In some embodiments, the transmitter 12 may be a sensor or other device ; NOTE-DISCLOSURE & TEACHING: i.e. integrated circuit chip reads on: a selection unit) to select at least one variable value received from a sensor device and to select a calculation rule received from the sensor device (REIDL FIG. 4 & ¶0045 See Claim 1; ¶0049 See Claim 1; ¶0054 See Claim 1; ¶0055 See Claim 1; NOTE-DISCLOSURE & TEACHING: per ¶0049 & FIG. 6 & ¶0055 […] procedure from Fig. 6 determining whether the checksum received is correct, i.e. whether the checksum received matches i.e. a checksum calculated on the basis of the data received in conjunction with expected information, i.e. such as an ID and/or a meter value, such as a continuous meter value reads on: comprising: a selection unit to select at least one variable value i.e. an ID as in per ¶0047 applied by the slave sensor sending the i.e. calculation of the cyclic redundancy check including i.e. reference signs 46 in Fig. 4, as well as i.e. not only the actual data values sent, i.e. SCN, D1, D2, D3 and the passing counter RC, but also the ID of the sending sensor device reads on: received from a sensor device. Furthermore Per FIG. 6 & ¶0049, ¶0054 i.e. its own checksum and evaluate whether the checksum is correct and per FIG. 6 ¶0055 determining whether the checksum received is correct, i.e. whether the checksum received matches a checksum calculated on the basis of the data received in conjunction with expected information, such as an ID and/or a meter value i.e. receivers own check sum value from the CRC calculation rule matches the CRC check sum of the transmitter reads on: and to select a calculation rule that matches the transmitter CRC in generating the same CRC checksum. Furthermore per ¶0055 i.e. determining whether the checksum received is correct, i.e. whether the checksum received matches i.e. the CRC check sum received with data sent by transmitter reads on: received from the sensor device and therefore the receivers own check sum is the same CRC rule as the transmitters as matched with CRC check sum sent with data);
(REIDL - ¶0034 See above; NOTE-DISCLOSURE & TEACHING: i.e. integrated circuit chip reads on: a receiver test value generator)
that calculates a receiver test value with the at least [[two]] one variable value and with atthe calculation rule received from the sensor device (REIDL FIG. 4 & ¶0045 See Claim 1; ¶0049 See Claim 1; ¶0054 See Claim 1; ¶0055 See Claim 1; NOTE-DISCLOSURE & TEACHING: per ¶0049 & FIG. 6 & ¶0055 […] procedure from Fig. 6 determining whether the checksum received is correct, i.e. whether the checksum received matches i.e. a checksum calculated reads on: that calculates a receiver test value i.e. on the basis of the data received in conjunction with expected information, i.e. such as an ID and/or a meter value, such as a continuous meter value reads on: with the at least one variable value i.e. an ID as in per ¶0047 applied by the slave sensor sending the i.e. calculation of the cyclic redundancy check including i.e. reference signs 46 in Fig. 4, as well as i.e. not only the actual data values sent, i.e. SCN, D1, D2, D3 and the passing counter RC. Furthermore per FIG. 6 ¶0055 determining whether the checksum received is correct, i.e. whether the checksum received matches a checksum calculated on the basis of the data received in conjunction with expected information, such as an ID and/or a meter value i.e. receivers own check sum value from the CRC calculation rule matches the CRC check sum of the transmitter reads on: and with the calculation rule . Furthermore per ¶0055 i.e. Fig. 6 determining whether the checksum received is correct, i.e. whether the checksum received matches reads on: received from the sensor device );
and an error detection unit (REIDL - ¶0034 See above; NOTE-DISCLOSURE & TEACHING: i.e. integrated circuit chip reads on: an error detection unit) for checking sensor measurement information of a data section of a datapacket received from the sensor device based on a sensor test value of a test section of the data packet and the receiver test value(REIDL - FIG. 4 & ¶0045 See Claim 1; ¶0047 See Claim 1; ¶0049 See Claim 1; ¶0054 See Claim 1; ¶0055 See Claim 1; NOTE-DISCLOSURE & TEACHING: per ¶0049 i.e. If the checksum calculation does not match the received data (including the expected ID) reads on: for checking sensor measurement information of a data section of a datapacket received from the sensor device, i.e. the master device knows that the data was either not received correctly, the CRC was received incorrectly, or the ID is incorrect, where per ¶0049 i.e. when the data is received and per Fig. 6 & ¶0055 i.e. determining whether the checksum received is correct, i.e. whether the checksum received reads on: based on a sensor test value of a test section of the data packet,. Furthermore per ¶0049 i.e. the receiving unit, such as a master device, includes the expected identity (which corresponds to the ID specified by the transmitted trigger pulse) in its own checksum calculation, e.g. a CRC calculation such as per Fig. 6 & ¶0055 i.e. whether the checksum received matches i.e. a checksum calculated reads on: and the receiver test value per ¶0055 i.e. calculated on the basis of the data received in conjunction with expected information, such as an ID ).
REIDL does not appear to explicitly teach or strongly suggest (i.e. implies see italicized portions): data packet;
YAMAKOSHI teaches: an error detection unit for checking sensor measurement information of a data section of a datapacket received from the sensor device based on a sensor test value of a test section of the data packet and the receiver test value (YAMAKOSHI FIG. 1 & FIG. 2 & ¶0039 See Claim 1; ¶0058 See Claim 1; ¶ See Claim 1; ¶0060 See Claim 1; ¶0065 See Claim 1 ; NOTE-DISCLOSURE & TEACHING: i.e. per ¶0065 i.e. the ECU which has received the data frame can detect a data error reads on: an error detection unit for checking sensor measurement information . Per ¶0065 i.e. detect a data error of a data section of a datapacket reads on: of a data section of a datapacket where and i.e. per ¶0065 i.e. An ECU which transmits a data frame calculates and sets the CRC value based on data of a plurality of fields including ID fields and data fields reads on: received from the sensor device. Furthermore per ¶0058 i.e. data frame includes an ID field, a control field, a data field and a CRC field and per ¶0065 i.e. the ECU which has received the data frame can detect a data error by calculating the CRC value from this data frame and comparing the CRC value and i.e. a CRC value included in the data frame reads on: based on a sensor test value of a test section of the data packet where per ¶0058 the CRC field being the test section of the data packet comprising the CRC value. Furthermore i.e. the ECU that received i.e. by calculating the CRC value from this data frame and comparing the CRC value reads on: and the receiver test value i.e. the CRC value calculated by the receiving ECU);
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of REIDL with teachings of YAMAKOSHI, since YAMAKOSHI enables a redundant system to perform failure diagnosis, and procedures that detect a failure and notify the driver of an error and, consequently, improve function safety at a system level (YAMAKOSHI - ¶0132, ¶0163).
Regarding Claim 13. (Currently Amended) REIDL teaches: A system for a vehicle (REIDL FIG. 2 & ¶0037 See Claim 1; NOTE-DISCLOSURE & TEACHING: i.e. sensors 24 and 26 in i.e. a system 20 and i.e. System 20 can be part of a vehicle's electrical system reads on: A system for a vehicle),
the system comprising: a receiver device (REIDL FIG. 2 & ¶0037 See Claim 1; ¶0047 See claim 1; NOTE-DISCLOSURE & TEACHING: per ¶0037 i.e. a receiver or other control device 22 (e.g. master) reads on: the );
and at least two sensor devices to communicate information between theat least two sensor devices and the receiver device through a transmission channel of the system (REIDL FIG. 2 & ¶0037 See Claim 1; ¶0047 See claim 1; NOTE-DISCLOSURE & TEACHING: i.e. Control Device 22 can communicate with sensors 24 and 26, e.g. via an SPC protocol or other bidirectional PWM protocol based on edges reads on: and at least two , with the following additions. In the picture shown in Fig. 2, the electrical coupling of the control device 22 with a three-wire connection to the first sensor 24 and the second sensor 26 includes a VDD power supply line 28, a data line 25 reads on: through a transmission channel of the system and a reference line, such as a ground line 27),
(See Rejection of Claim 1, Claim 13 recites similar and parallel features to Claim 1, and the rationale for the rejection of Claim 1 applies similarly to Claim 13. Where applicable, minor differences between claims are noted as appropriate)
wherein a sensor test value generator of at least one sensor device of the at least two sensor devices calculates a sensor test value as a function of at least one variable value and as a function of a calculation rule from sensor measurement information,
wherein the at least one sensor device generates a data packet, the data packet having at least a data section with the sensor measurement information and a test section with the sensor test value,
wherein the at least one sensor device sends the data packet through the transmission channel to the receiver device,
wherein the receiver device selects the at least one variable value of the sensor test value generator as a function of the at least one sensor device and selects the calculation rule of the sensor test value generator as a function of the at least one sensor device,
wherein a receiver test value generator of the receiver device calculates a receiver test value with the at least one variable value and with the calculation rule from the sensor measurement information of the data section of the data packet,
and wherein an error detection unit of the receiver device checks the sensor measurement information of the data section of the data packet for a transmission error based on the sensor test value and the receiver test value (See Rejection of Claim 1, Claim 13 recites similar and parallel features to Claim 1, and the rationale for the rejection of Claim 1 applies similarly to Claim 13. Where applicable, minor differences between claims are noted as appropriate).
Regarding Claim 14. (Currently Amended) REIDL in view of YAMAKOSHI teaches: The system according to claim 13,
furthermore REIDL teaches: wherein the transmission channel has at least two electrical conductors, wherein the transmission channel has a supply signal conductor for supplying the at least two sensor devices with electric power and for transmitting information the data packet, as well as a ground conductor (note: limitations separated by a recitation “or” are interpreted as presented in the alternative and not required together i.e. for the purposes of patentable weight),
or (note: limitations separated by a recitation “or” are interpreted as presented in the alternative and not required together i.e. for the purposes of patentable weight)
wherein the transmission channel has at least three electrical conductors, wherein the transmission channel has a supply conductor for supplying the at least two sensor devices with electric power, a ground conductor, and at least one signal conductor for transmitting information the data packet (REIDL FIG. 2 & ¶0037 See Claim 1; ¶0047 See claim 1; NOTE-DISCLOSURE & TEACHING: i.e. Control Device 22 can communicate with sensors 24 and 26, e.g. via an SPC protocol or other bidirectional PWM protocol based on edges, with the following additions. In the picture shown in Fig. 2, the electrical coupling of the control device 22 with a three-wire connection to the first sensor 24 and the second sensor 26 reads on: wherein the transmission channel has at least three electrical conductors includes a VDD power supply line 28 reads on: wherein the transmission channel has a supply conductor for supplying the at least two sensor devices with electric power, I.e. and a reference line, such as a ground line 27 reads on: a ground conductor, i.e. a data line 25 reads on: and at least one signal conductor for transmitting information or for transmitting the data packet).
Regarding Claim 15. (Currently Amended) REIDL in view of YAMAKOSHI teaches: The system according to claim 13,
furthermore REIDL teaches: wherein the system has a common transmission channel for the receiver device and the at least two sensor devices, and wherein the receiver device and the at least two sensor devices each have a direct communication connection to the transmission channel (REIDL FIG. 2 & ¶0037 See Claim 1; ¶0047 See claim 1; NOTE-DISCLOSURE & TEACHING: i.e. Control Device 22 can communicate with sensors 24 and 26, e.g. via an SPC protocol or other bidirectional PWM protocol based on edges, with the following additions. In the picture shown in Fig. 2, the electrical coupling of the control device 22 with a three-wire connection to the first sensor 24 and the second sensor 26 includes a VDD power supply line 28, i.e. a data line 25 that is common ad depicted to the receiver and two sensors reads on: wherein the system has a common transmission channel for the receiver device and the at least two , and per FIG. 2 the sensors and receiver are depicted as directly coupled to the 25 reads on: and wherein the receiver device and the at least two ).
15. Claims 2, 8 are rejected under 35 U.S.C. 103 as being unpatentable over REIDL in view of YAMAKOSHI further in view of Cho et al. (US 20180091550 A1), i.e. “Cho”.
Regarding Claim 2. (Currently Amended) REIDL in view of YAMAKOSHI teaches: The method according to claim 1,
furthermore REIDL teaches: wherein the at least one variable value of the sensor test value generator and the calculation rule of the sensor test value generator reproduce
or (note: limitations separated by a recitation “or” are interpreted as presented in the alternative and not required together i.e. for the purposes of patentable weight)
represent at least one piece of information (REIDL - FIG. 4 & ¶0045 See Claim 1; ¶0047 See Claim 1; ¶0049 See Claim 1; NOTE-DISCLOSURE & TEACHING: per ¶0049 i.e. If the checksum calculation does not match the received data (including the expected ID) reads on: wherein the at least one variable value of the sensor test value generator the calculation rule of the sensor test value generator represent , i.e. the master device knows that the data was either not received correctly, the CRC was received incorrectly, or the ID is incorrect reads on: at least one piece of information associated with such as the CRC was received incorrectly or alternately if matches received correctly).
REIDL in view of YAMAKOSHI does not appear to explicitly teach or strongly suggest (note see italicized portions): and at least one status of the sensor device or at least one piece of information and at least one status of a sensor of the sensor device.
Cho teaches: wherein the at least one variable value of the sensor test value generator and the calculation rule of the sensor test value generator reproduce or (note: limitations separated by a recitation “or” are interpreted as presented in the alternative and not required together i.e. for the purposes of patentable weight) represent at least one piece of information (Cho FIG. 7 & ¶0083 […] determining whether or not the received message was legitimately transmitted by the identified transmitting ECU may include determining whether the reference ECU identifier matches a legitimate ECU identifier associated with a received message ID.; NOTE-DISCLOSURE & TEACHING: per ¶0083 i.e. determining whether the reference ECU identifier matches a legitimate ECU identifier associated with a received message ID reads on: wherein the at least one variable value of the sensor test value generator ECU identifier matches a legitimate ECU identifier reads on: and the calculation rule of the sensor test value generator. Furthermore per ¶0083 i.e. determining whether or not the received message was legitimately transmitted reads on: reproduce or represent at least one piece of information i.e. legitimate transmitted information)
and at least one status of the sensor device (Cho FIG. 7 & ¶0083 See above; ¶0084 If the received message was not legitimately transmitted by the identified transmitting ECU, then a possible fault may be notified at operation 716 ;NOTE-DISCLOSURE & TEACHING: per ¶0084 i.e. If the received message was not legitimately transmitted by the identified transmitting ECU, i.e. then a possible fault may be notified at operation 716 reads on: and at least one status of the sensor device comprising fault if not legitimately received or no fault if legitimately received )
or (note: limitations separated by a recitation “or” are interpreted as presented in the alternative and not required together i.e. for the purposes of patentable weight)
at least one piece of information and at least one status of a sensor of the sensor device (note: limitations separated by a recitation “or” are interpreted as presented in the alternative and not required together);
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of REIDL in view of YAMAKOSHI with teachings of Cho, since Cho enables determining whether or not a received message was legitimately transmitted by identified transmitting ECU (Cho - ¶0083).
Regarding Claim 8. (Currently Amended) REIDL in view of YAMAKOSHI teaches: The method according to claim 1,
furthermore REIDL teaches: wherein at least one sensor device of the two sensor devices generates and sends [[a]] the data packet (REIDL – FIG. 4 & ¶0037 See Claim 1; ¶0042 See Claim 1; ¶0043 See Claim 1; ¶0045 […] See Claim 1 ; ¶0047 See Claim 1; NOTE-DISCLOSURE & TEACHING: ¶0045 […] Figure 4 shows a trigger pulse 40 that can be sent from a master device to slave devices to specify a slave device to respond to the trip pulse , where per ¶0047 i.e. After the trigger pulse, the slave device responds, as indicated by a curve section 44 , with a synchronization pulse and various values SCN, D1 to D3 and a continuous counter value (RC value), which are examples of sent data values i.e. the slave device responds reads on: wherein at least one sensor device i.e. sent from a master device to slave devices reads on: of the two sensor devices i.e. the slave device responds reads on: sends [[a]] the data packet to the receiver device)
with the data section with the test section and with a count section with a counter value, wherein the counter value is changed or (note: limitations separated by a recitation “or” are interpreted as presented in the alternative and not required together i.e. for the purposes of patentable weight) increased for each sending of [[a]] the data packet by the at least one sensor device (REIDL - REIDL – FIG. 4 & ¶0037 See Claim 1; ¶0042 See Claim 1; ¶0043 See Claim 1; ¶0045 […] See Claim 1 ; ¶0047 See Claim 1; ¶0048 […] The traversing counter RC can be a 4-bit value that is incremented by one bit each time the corresponding slave device sends data that ends with a pause pulse; NOTE-DISCLOSURE & TEACHING: per ¶0047 and FIG. 4 i.e. After the trigger pulse, the slave device responds, as indicated by a curve section 44 , with a synchronization pulse and i.e. various values SCN, D1 to D3 reads on: with the data section , i.e. followed by a cyclic redundancy check CRC 45 reads on: with the test section per ¶0047 i.e. and a continuous counter value (RC value) reads on: and with a count section with a counter value where per ¶0048 i.e. The traversing counter RC can be a 4-bit value that is incremented by one bit each time the corresponding slave device sends data reads on: wherein the counter value is changed or increased for each sending of the data packet by the at least one sensor device ),
and with a serial section for serial transmission of sensor auxiliary information from the sensor device ((REIDL - REIDL – FIG. 4 & ¶0037 See Claim 1; ¶0042 See Claim 1; ¶0043 See Claim 1; ¶0045 […] See Claim 1 ; ¶0047 See Claim 1; ¶0048 […] The traversing counter RC can be a 4-bit value that is incremented by one bit each time the corresponding slave device sends data that ends with a pause pulse; NOTE-DISCLOSURE & TEACHING: per FIG. 2 depicts i.e. a data line 25 that is common as depicted to the receiver and two sensors and per ¶0047 and FIG. 4 i.e. After the trigger pulse, the slave device responds, as indicated by a curve section 44 , with a synchronization pulse and i.e. various values SCN, D1 to D3 shown communicated serially in time reads on: with a serial section for serial transmission, where per FIG. 4 ¶0047 D1-D3 ant one could reads on: of sensor auxiliary information from the sensor device).
REIDL in view of YAMAKOSHI does not appear to explicitly teach or strongly suggest (note see italicized portions): and with a status section for transmitting a status of the sensor device or a fault condition of the sensor device;
Cho teaches: wherein at least one sensor device of the two sensor devices generates and sends [[a]] the data packet with the data section with the test section (Cho FIG. 1 & ¶0021 […] each ECU, for example ECU 102A, may be configured to receive inputs from one or more sensor(s) and/or to provide control outputs to one or more actuators […] sensors may include temperature sensors, pressure sensors, accelerometers, etc. In one example, operation of a selected ECU may be in response to a message received from another ECU, the message communicated via bus 106. In another example, a selected ECU may be configured to transmit a message to another ECU via bus 106; ¶0026 (CAN) bus message format (i.e., “message frame”) 200A […] an arbitration field (that includes a message identifier (ID) 202) and […] message frame 200A may include a data field 204. Message frame 200A further includes a cyclic redundancy check (CRC) field 208; FIG. 7 & ¶¶0083 See Claim 2; ¶0084 See claim 2; NOTE-DISCLOSURE & TEACHING: per ¶0021 i.e. each ECU, for example ECU 102A, may be configured to receive inputs from one or more sensor(s) and/or to provide control outputs to one or more actuators reads on: wherein at least one sensor device of the two sensor devices generates and/or and sends [[a]] the data packet. Furthermore Per FIG. 2 A & ¶0026 (CAN) bus message format (i.e., “message frame”) 200A […] an arbitration field (that includes a message identifier (ID) 202) and […] message frame 200A may include a data field 204. Message frame 200A further includes a cyclic redundancy check (CRC) field 208 reads on: with the data section with the test section. )
and with a status section for transmitting a status of the sensor device or a fault condition of the sensor device (Cho FIG. 7 & ¶0083 See Claim 2; ¶0084 See claim 2 ;NOTE-DISCLOSURE & TEACHING: per ¶0084 i.e. If the received message was not legitimately transmitted by the identified transmitting ECU, i.e. then a possible fault may be notified at operation 716 i.e. identifier section for identification and fault indication reads on: with a status section for transmitting a status of the sensor device or a fault condition of the sensor device comprising fault if not legitimately received or no fault if legitimately received ).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of REIDL in view of YAMAKOSHI with teachings of Cho, since Cho enables determining whether or not a received message was legitimately transmitted by identified transmitting ECU (Cho - ¶0083).
16. Claim 4 is rejected under 35 U.S.C. 103 as being unpatentable over REIDL in view of YAMAKOSHI further in view of Skaaksrud (US 20200100115 A1), i.e. “Skaaksrud”.
Regarding Claim 4. (Currently Amended) REIDL in view of YAMAKOSHI teaches: The method according to claim 1,
furthermore REIDL teaches: wherein at least one sensor device of the two sensor devices sends [[a]] the data packet to the receiver device, at least at times (REIDL – FIG. 4 & ¶0037 See Claim 1; ¶0042 See Claim 1; ¶0043 See Claim 1; ¶0045 […] See Claim 1 ; ¶0047 See Claim 1; NOTE-DISCLOSURE & TEACHING: ¶0045 […] Figure 4 shows a trigger pulse 40 that can be sent from a master device to slave devices to specify a slave device to respond to the trip pulse , where per ¶0047 i.e. After the trigger pulse, the slave device responds, as indicated by a curve section 44 , with a synchronization pulse and various values SCN, D1 to D3 and a continuous counter value (RC value), which are examples of sent data values i.e. the slave device responds reads on: wherein at least one sensor device i.e. sent from a master device to slave devices reads on: of the two sensor devices i.e. the slave device responds reads on: sends [[a]] the data packet to the receiver device, at least at times);
REIDL in view of YAMAKOSHI does not appear to explicitly teach or strongly suggest (i.e. Note see italicized portions): automatically sends
Skaaksrud teaches: wherein at least one of the two sensor devices automatically sends a data packet to the receiver device, at least at times (Skaaksrud - ¶944allows for advantageous monitoring for environmental anomalies in an advantageous and novel manner (e.g., by a vehicle master node (or aircraft master node) that monitors sensor data from different node-enhanced batteries on board the aircraft and provides alert notifications ; ¶0973 the node processor of each of the sensor-based nodes may be programmatically configured to be operative to automatically trigger generation of the layered alert notification by being further operative to monitor the received status data over the time period to identify relative changes in the received status over the time period; NOTE-DISCLOSURE & TEACHING: i.e. per ¶0973 the sensor-based nodes may be programmatically configured to be operative to reads on: wherein at least one of the two sensor devices and i.e. be operative to automatically trigger generation of the layered alert notification by being further operative to monitor the received status data over the time period reads on: automatically sends a data packet per ¶0944 master node (or aircraft master node) that monitors sensor data reads on: to the receiver device, at least at times ).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of REIDL in view of YAMAKOSHI with teachings of Skaaksrud, since Skaaksrud enables allows for advantageous monitoring for environmental anomalies in an advantageous and novel manner (e.g., by a vehicle master node (or aircraft master node) that monitors sensor data from different node-enhanced batteries on board the aircraft and provides alert notifications to flight personnel relative to potential dangers (Skaaksrud - ¶944).
17. Claim 6 is rejected under 35 U.S.C. 103 as being unpatentable over REIDL in view of YAMAKOSHI further in view of NOMURA (US 20200213687 A1), i.e. “NOMURA”.
Regarding Claim 6. (Original) REIDL in view of YAMAKOSHI teaches: The method according to claim 1,
furthermore REIDL teaches: wherein at least one of the two sensor devices sends a data packet to the receiver device, at least at times (REIDL – FIG. 4 & ¶0037 See Claim 1; ¶0042 See Claim 1; ¶0043 See Claim 1; ¶0045 […] See Claim 1 ; ¶0047 See Claim 1; NOTE-DISCLOSURE & TEACHING: ¶0045 […] Figure 4 shows a trigger pulse 40 that can be sent from a master device to slave devices to specify a slave device to respond to the trip pulse , where per ¶0047 i.e. After the trigger pulse, the slave device responds, as indicated by a curve section 44 , with a synchronization pulse and various values SCN, D1 to D3 and a continuous counter value (RC value), which are examples of sent data values reads on: wherein at least one of the two sensor devices sends a data packet to the receiver device, at least at times);
REIDL in view of YAMAKOSHI does not appear to explicitly teach or strongly suggest (i.e. Note see italicized portions): send at least one data packet in time alternation
NOMURA teaches: wherein the two sensor devices each send at least one data packet to the receiver device in time alternation, at least at times (NOMURA ¶0014 In PDCM, the ECU, serving as a master, transmits a synchronous signal at a fixed interval. Then, when each sensor, serving as a slave, receives the synchronous signal from the ECU, the sensor transmits data to the ECU. A timing at which the data is transmitted after reception of the synchronous signal differs with each sensor. Data is successively transmitted to the ECU from the sensors; NOTE-DISCLOSURE & TEACHING: i.e. Data is successively transmitted to the ECU from the sensors reads on: wherein the two sensor devices each send at least one data packet to the receiver device , where i.e. the sensor transmits data to the ECU. A timing at which the data is transmitted after reception of the synchronous signal differs with each sensor reads on: in time alternation, at least at times ).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of REIDL in view of YAMAKOSHI, with teachings of NOMURA, since NOMURA enables a single sensor transmitting data using a plurality of time slots in this manner, communication density can be increased without length of the time slot being changed. Consequently, communication efficiency can be improved by a simple configuration (NOMURA - ¶0020).
18. Claim 7 is rejected under 35 U.S.C. 103 as being unpatentable over REIDL in view of YAMAKOSHI further in view of Boeck et al. (US 20140337550 A1) i.e. “Boeck”.
Regarding Claim 7. (Original) REIDL in view of YAMAKOSHI teaches: The method according to claim 1,
furthermore REIDL teaches: wherein the two sensor devices each send at least one data packet to the receiver device at least at times (REIDL – FIG. 4 & ¶0037 See Claim 1; ¶0042 See Claim 1; ¶0043 See Claim 1; ¶0045 […] See Claim 1 ; ¶0047 See Claim 1; NOTE-DISCLOSURE & TEACHING: ¶0045 […] Figure 4 shows a trigger pulse 40 that can be sent from a master device to slave devices to specify a slave device to respond to the trip pulse , where per ¶0047 i.e. After the trigger pulse, the slave device responds, as indicated by a curve section 44 , with a synchronization pulse and various values SCN, D1 to D3 and a continuous counter value (RC value), which are examples of sent data values reads on: wherein the two sensor devices each send at least one data packet to the receiver device at least at times);
REIDL in view of YAMAKOSHI does not appear to explicitly teach or strongly suggest (i.e. Note see italicized portions): send at least one data packet substantially simultaneously or overlapping in time
Boeck teaches: the two sensor devices each send at least one data packet to the receiver device substantially simultaneously at least at times (Boeck FIG. 2 & FIG. 3, ¶0048 […] If sensor transmission units 200.1, 200.2, . . . , 200.n detect the predetermined signaling data on data bus 220, which initializes a data transmission of payload data of sensors 230 of the different sensor units USS1, USS2, USSn, each of sensor transmission devices 200.1, 200.2, . . . , 200.n or the particular bus interface 250 may insert one byte of payload data into payload data block 135 of the payload data field of a bus data packet 100 which is reserved for the corresponding sensor transmission device 2001.1, 200.2, . . . , 200.n. […] Bus interface 250 of each sensor transmission device 200.1, 200.2, . . . , 200.n thus initially retrieves from assigned memory 260 the position information stored there, or determines an assignment rule from the action list stored in the memory, the position information being derived from the assignment rule, and inserts at least a portion of the payload data of the relevant sensor 230 into payload data block 135 defined by the position information. In this way a bus data packet 100 may be generated, which to bus control device 210 appears as if it originated from a single unit. Sensor units USS1, USS2, USSn are thus interconnected as a "virtual sensor."; NOTE-DISCLOSURE & TEACHING: i.e. Bus interface 250 of each sensor transmission device 200.1, 200.2, . . . , 200.n thus […]and inserts at least a portion of the payload data of the relevant sensor 230 into payload data block 135 defined by the position information. In this way a bus data packet 100 may be generated reads on: the two sensor devices each send at least one data packet to the receiver device i.e. In this way a bus data packet 100 may be generated, which to bus control device 210 appears as if it originated from a single unit reads on: substantially simultaneously at least at times generated substantially simultaneously at a single time at which bus packet 100 is generated as if from a single unit)
Or (note: limitations separated by a recitation “or” are interpreted as presented in the alternative and not required together i.e. for the purposes of patentable weight)
overlapping in time at least at times (note: limitations separated by a recitation “or” are interpreted as presented in the alternative and not required together i.e. for the purposes of patentable weight);
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of REIDL in view of YAMAKOSHI, with teachings of Boeck, since Boeck enables that the net data transmission rate in a network having multiple sensor transmission devices, which each send only small amounts of data and do not have data to send in each cycle, is improved, i.e., increased. (Boeck - ¶0019).
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 MALICK A SOHRAB whose telephone number is (571)272-4347. The examiner can normally be reached on Mo-Fri 9:00 am - 5:00 pm. 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, Edan Orgad can be reached on (571) 272-7884. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see https://ppair-my.uspto.gov/pair/PrivatePair. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/M.A.S./
Examiner, Art Unit 2414
02/27/2026
/EDAN ORGAD/Supervisory Patent Examiner, Art Unit 2414