Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1 - 17 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor, or for pre-AIA the applicant regards as the invention.
Regarding claim 1, claim limitations “acquisition unit configured to execute”,
“application execution unit configured to execute”,
“management unit configured to extract”, and “routing unit configured to provide” have been interpreted under 35 U.S.C. 112(f) or 35 U.S.C. 112 (pre-AIA ), sixth paragraph, because said limitations use the non-structural term “unit” coupled with functional language “configured to execute”, “extract”, or “provide”, without reciting sufficient structure to achieve the function. Furthermore, the non-structural term is not preceded by a structural modifier.
Since this claim limitation invokes 35 U.S.C. 112(f) or 35 U.S.C. 112 (pre-AIA ), sixth paragraph, claim 1 is interpreted to cover the corresponding structure described in the specification that achieves the claimed function, and equivalents thereof.
While Fig. 1 units 44 and 45 are described in [145] of Applicant’s specification as corresponding to a data acquisition unit, unit 41 is described as corresponding to an application execution unit,
units 21 and 22 are described as each being types of management units, and
unit 43 is described a routing unit,
Applicant is reminded that if a claim function is a specific function to be performed by a special purpose computer, then the corresponding structure in the specification must be more than a mere reference to a general purpose computer, microprocessor, specialized computer, or an unidentified component of a computer system, software, logic, code or black box element. If applicant wishes to provide further explanation or dispute the examiner’s interpretation of the corresponding structure, applicant must identify the corresponding structure with reference to the specification by page and line number, and to the drawing, if any, by reference characters in response to this Office action.
If applicant does not wish to have the claim limitation treated under 35 U.S.C. 112(f) or 35 U.S.C. 112 (pre-AIA ), sixth paragraph, applicant may amend the claim so that it will clearly not invoke 35 U.S.C. 112(f) or 35 U.S.C. 112 (pre-AIA ), sixth paragraph (e.g., by incorporating sufficient structure into the claim language to achieve the claimed functionality), or present a sufficient showing that the claim recites sufficient structure, material, or acts for performing the claimed function to preclude application of 35 U.S.C. 112(f) or 35 U.S.C. 112 (pre-AIA ), sixth paragraph.
For more information, see MPEP § 2173 et seq. and Supplementary Examination Guidelines for Determining Compliance with 35 U.S.C. § 112 and for Treatment of Related Issues in Patent Applications, 76 FR 7162, 7167 (Feb. 9, 2011).
Regarding claim 6, said claim suffers from issues corresponding to those of claim 1, while also reciting a “peripheral information acquisition unit”. Regarding claim 2 – 5 and 7 - 17, said claim suffers from issues corresponding to those of claim 1.
Claims 1 - 19 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Regarding claim 1, said claim recites “one application program” on lines 4 – 5 and then “a requesting application that is the application program to be a request source” on lines 10 – 11. It is unclear if the second recited “application program” of lines 10 – 11 is intended to correspond to the “one application program” of lines 4 – 5, or if the additional details in the second recited application program (that it is “a requesting application . . . to be a request source”) is intended to differentiate the two recitations.
Further regarding claim 1, said claim recites on lines 6 – 7 “a transmission target command that is a command” and on line 8 “the command indicated”. Similar to the “application program” noted above, it is unclear if these three recited commands are all intended to reference the same item or if some (or all) of the recitations are intended to be distinct.
Claim 1 continues on lines 9 – 10 to recite “the command used to acquire”. This introduces a fourth recitation of a command, which suffers from issues analogous to the command recitations noted above on lines 6 - 8.
Claim 1 next recites, on lines 11 – 12, “the acquisition condition of the vehicle data”. The claim lacks antecedent basis for this language.
Regarding claim 2, said claim recites, on lines 2 – 3 “to repeatedly execute the transmission process at a preset execution cycle”. There is no antecedent basis for “execution cycle” and thus a reference to a particular execution cycle (i.e., “a preset execution cycle”) is unclear and indefinite given the claims lack of context for the cycle.
Claim 2 continues on line 5 to recite “a next and subsequent execution cycles”. However, as noted above, there is no antecedent basis for something corresponding to a “current” cycle, and thus reference to either a “next” or “subsequent” cycle is rendered unclear and indefinite. It is additionally unclear if “next and subsequent” is intended to reference a singular cycle that occurs “next” and thus is also “subsequent” to the current/present cycle, or if the recitation is intended to specify both a “next” cycle and all cycles that are “subsequent” to the current/present cycle.
Further regarding claim 2, said claim recites “the management information” on line 6 of. However, parent claim 1 two possible recitations provide antecedent basis for “management information”; line 8 recites “management information that meets”, and line 9 recites “one or more management information indicating”. It is unclear which (if either) of these recitations the “management information” recitation in line 2 is intended to further specify.
Regarding claim 3, said claim continues and references “the application program” on lines 2, 3, and 4. As noted above when discussing claim 1, there are two recitations of “application program” that these three recitations could be further limiting. The correspondence between these “application program” recitations in claim 3 and the antecedent basis provided in claim 1 render the claim unclear and indefinite. Claim 3 next references “the vehicle data requested” on lines 2 – 3. There is a lack of antecedent basis for “vehicle data requested”. However, there are multiple recitations of “vehicle data”. It is unclear if this recitation is intended to specify a new particular “vehicle data”, or if some particular prior recitation of “vehicle data” is being further limited. Claim 3 then references “the management information” on lines 4 – 5. This suffers from the same issues as “the management information” recitation of claim 2.
Regarding claim 4, said claim recites a “manifest”. This manifest is claimed as including “periodic drive”, “application derive”, and “event drive”. The dictionary definition that appears most applicable to this recitation of a “manifest” would be that of a “record” such as a record of data (e.g., a ship’s travel manifest, or a textual description of software). However, the three “drive” recitations appear to correspond to software functions/methods (e.g., those that could be invoked via an API call). It is unclear how a “manifest” can include such items based on the standard English language definitions of “manifest”. It is additionally unclear how the “manifest” can include three different “drive” items given each “drive” appears to provide overlapping but conflicting functionality. This lack of clarity is exacerbated by the unclear scope of the claimed “manifest”.
Regarding claim 5, said claim further limits the “manifest” of claim 4 and fails to clarify the issues noted above, while introducing two new items (a “name designation” and “command designation”). These two new “designation” items suffer from the same issues as the “drive” items of claim 4. Further regarding claim 5, Lines 4 – 5 recite “a name designation, which specifies the type of the vehicle data using a standardized name representing meaning”. Specifying a “type” and specifying a “meaning” are not the same thing, and thus it is unclear how one can clarify the scope of “type” by noting it represents “meaning”. A corresponding issue exists in lines 6 – 7, which claims “a command designation, which specifies the type of the vehicle data in a format”. Specifying a type of data “in a format” does not correspond to standard grammatical English and is unclear and indefinite.
Regarding claim 6, said claim recites “the in-vehicle network of a vehicle” in lines 3 – 4. It is unclear if this is intended to rely on “an in-vehicle network” introduced one line 3 of claim 1. Claim 6 continues on line 5 to recite “indicating a list of a command”. A “list of” a singular item is not grammatical English as a list is defined as a “series” of items. A singular “command” cannot be said to be a list by virtue of being a single item. Line 5 in claim 6 also recites “through wireless communication”. It is unclear if this is intended to further specify the “command usable” of line 5 or the “obtain” of line 2 (or some other aspect of claim 6). Claim 6 then continues on page 3. Lines 2 – 3 on page 3 recite “the management information”. However, there are multiple “management information” recitations that this particular reference could be further limiting (e.g., claim 1 line 8 and claim 1 line 9). The “in-vehicle network” referenced on lines 3 – 4 and lines 4 – 5 of page 3 suffers from the same issues as the “in-vehicle network” recitation on page 2. Regarding claim 7, said claim recites on lines 3 – 6 a exclusion step “to
prevent overload . . . in the transmission process may cause overload”. This is non-standard, ungrammatical English and is unclear and indefinite. Claim 7 additionally references “the management information”. Parent claim 1 includes two distinct recitations of “management information”, and thus it is unclear which of these the recitation in claim 7 is intended to further limit.
Regarding claim 8, said claim recites “when a traffic exceeds”. This is non-standard, ungrammatical English and is unclear and indefinite.
Regarding claim 9, said claim recites “the transmission target command” on lines 2 – 3. However, claim 9 depends on both claims 1 and 2. Each of said claims introduce “a transmission target command”, and thus which of these claim 9’s recitation is intended to further specify is rendered unclear and indefinite.
Further regarding claim 9, said claim recites on lines 3 – 6 a exclusion step “to
prevent overload . . . in the transmission process may cause overload”. This is non-standard, ungrammatical English and is unclear and indefinite.
Claim 9 continues to rely on an evaluation of “a total turnaround time of the transmission target command”. However, there is no antecedent basis for this “total turnaround time” and thus no basis for establishing context of the recitation as a whole. The scope “total turnaround time” is unclear given the lack of any antecedent basis, and thus a reliance on an evaluation of this time is rendered unclear and indefinite. Claim 9 next references “the execution cycle” in lines 9 - 10. A “preset execution cycle” is recited in parent claim 2, as is “next and subsequent execution cycles”. However, what is intended to reference this “execution cycle” is unclear and indefinite for the same reasons given above when discussing these cycles of claim 2.
Claim 10 references “the turnaround time”. Claim 9 provides antecedent basis for a “total turnaround time”. It is unclear if this is intended to further reference this time (and thus this recitation would inherent the issues noted in claim 9) or if “the turnaround time” is intended to introduce a new “turnaround time” (in which case there is a lack of antecedent basis for the recitation). Claim 11 references “the turnaround time”, which suffers from the same issues as the recitation in claim 10. Claim 12 references “the transmission target command” in line 3 and on lines 8 – 9. Claim 12 depends on claim 2, and thus there are multiple possible “transmission target command” recitations that the recitation in claim 12 could be further limiting (3 recitations in claim 1 and a 4th in claim 2).
Claim 12 recites on lines 3 – 6 a exclusion step “to prevent overload . . . in the transmission process may cause overload”. This is non-standard, ungrammatical English and is unclear and indefinite. Claim 12 recites “the management information” in line 8. Claim 12 depends on claim 2, and thus suffers from the same issues as the recitation of “the management information” in claim 2.
Claim 12 additionally references “the management information excluded” in line 9. There is no antecedent basis for “management information excluded”.
Claim 12 references “an execution cycle” in lines 10 and 11. There is no context established for “an execution cycle”, thus the relationship to the claim as a whole and the execution cycle (e.g., how an extraction of a “a transmission target command” can be performing during such a cycle) is unclear and indefinite. Claim 12 concludes with the recitation “an execution cycle after an execution cycle in which the management information excluded from the transmission target command is excluded”. This is non-standard, ungrammatical English and is unclear and indefinite.
Regarding claim 13, line 2 and 4 additionally references “the management information”. Parent claim 1 includes two distinct recitations of “management information”, and claim 7 includes a reference to “the management information” . It is unclear which of these the recitations in claim 13 is intended to further limit. Claim 13 further limits “the command” in line 3. However, as discussed in the above rejection of claim 1, said claim provides basis multiple “command” recitations. Which of these recitations claim 13 is intended to further limit is unclear. Claim 13 references “the transmission target command” in lines 5 – 6. It is unclear if this command recitation is related to the recitation in line 3 or is referencing a distinct command. Regarding claim 14, said claim references “the command” in line 3, and suffers from analogous issues to the above discussed recitations in claim 13.
Regarding claim 15, said claim references “the command” in line 3, and suffers from analogous issues to the above discussed recitations in claim 13.
Regarding claim 17, said claim references “a vehicle” in line 3. It is unclear what relationship this newly introduced “a vehicle” has to the “vehicle” of claim 1 (via the repeated references “vehicle data” in said claim).
Claim 17 also introduces “a diagnostic command” in line 4 and then references “the command” in line 5. It is unclear if “the command’ of line 5 is intended to further limit one of the “command” references of claim 1 or is further limiting the “diagnostic command” in line 4 of claim 17. Additionally, claim 17 further limits a “diagnostic command” to one “used in diagnostic communication as the command”. It is unclear what the “used in diagnostic communication” is intended to further specify beyond what the presence of “diagnostic command” already requires.
Regarding claim 18, said claim recites “A data provision method in an onboard device that executes a transmission process to send a command used to acquire vehicle data to an in-vehicle network and provides the vehicle data acquired by the transmission process
to at least one application program” on page 5 (emphasis added). It is unclear what part of this language “and provides” is intended to further reference; e.g., if it is further specifying what the “data provision method” does, whether it is a more specific recitation specifying what the “transmission process” does, or alternatively if it is further specifying what the sent “command” is used to achieve. Claim 18 continues to recite on line 4 of page 5 through line 2 on page 6 “the vehicle data is provided to a requesting application that is the application program to be a request source of the vehicle data”. This is non-standard, ungrammatical English and is unclear and indefinite. Lines 1 – 2 of claim 18 on page 5 recite a “an onboard device” that sends “a command used to acquire vehicle data”. However, line 1 on page 6 recites a “requesting application” that is a “request source”. This recitation on page 6 appears to conflict with the recitation on page 5 regarding who/what is the source of the command used to acquire / request. Lines 3 – 5 on page 6 recites “using one or more management information indicating a type of command used to acquire the vehicle data, the requesting application that is a request source of the vehicle data, and an acquisition condition of the vehicle data”. This clause, however, is missing required articles to be grammatical English. It fails to recite what the “using” is for, and “one or more management information” is ungrammatical. Lines 6 – 7 then recite “extracting, as a transmission target command that is a command to be a transmission target in the transmission process,” (emphasis added). The emphasized language appears redundant; what it is intended to further specify is unclear and indefinite.
Lines 11 – 12 next recite “providing the vehicle data acquired . . .”. While the claim has established a command for such acquisition, no actual vehicle data has been positively recited as being required at this point in the claim. Thus, as there is no antecedent basis for “the vehicle data acquired”, this recitation is rendered unclear and indefinite. Lines 11 recite to “provide the vehicle data acquired by executing the transmission process to. . .”. It is unclear if the “by executing the transmission process” is further specifying the ”provide” step, or is further specifying the context of “the vehicle data acquired” (i.e., does the “provide” step occur “by executing the transmission process”, or is the “vehicle data acquired by executing the transmission process”?). The lack of antecedent basis for “the vehicle data acquired” exacerbates this lack of clarity.
Regarding claim 19, said claim contains language corresponding to claim 18, and thus suffers from issues analogous to those in claim 18.
In order to perform a complete examination, the above claims have been interpreted broadly.
Claim Rejections - 35 USC § 102
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claims 1, 16, 18, and 19 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Ohmert (US-11373459-B2).
Regarding claim 1, Ohmert shows an onboard device (col. 4 lines 29-34) comprising: a data acquisition unit configured to execute a transmission process to send a command used to acquire vehicle data (col. 3 lines 46-65 discussing CAN commands to “collect and process telemetry”) to an in-vehicle network (Fig. 2 item 212, Fig. 16, col. 4 lines 39-47); an application execution unit configured to execute at least one application program that utilizes the vehicle data acquired by the data acquisition unit (col. 4 lines 5-16 discussing a “vehicle profile” used to facilitate communications and provide “translation functionality”); a schedule management unit configured to extract, as a transmission target command that is a command to be a transmission target in the transmission process (col. 3 lines 46-53), the command indicated by management information that meets an acquisition condition (col. 4 line 61 – col. 5 line 10 discussing features that program access to data, e.g., “the program can access or is restricted from accessing”), using one or more management information (e.g., a profile as discussed in col. 4 lines 5-20) indicating a type of the command used to acquire the vehicle data, a requesting (col. 6 lines 1-12, see the “data acquisition request”) application that is the application program to be a request source of the vehicle data (Fig. 2 steps 206 -> 216, col. 4 lines 15-20, col. 4 lines 48-50) and the acquisition condition of the vehicle data (the condition limited by the requesting program’s identity and the vehicle profile, as discussed in col. 4 lines 61-65), and to generate routing information associating the transmission target command with the requesting application (col. 6 lines 1-18 discussing comparing the requesting program to a profile containing access rights/permissions; further discussion in col. 7 lines 34-44); and a routing unit configured to provide the vehicle data acquired (col. 5 lines 11-15) by the data acquisition unit through execution of the transmission process to the requesting application using the routing information (col. 5 lines 35-38, col. 5 lines 47-53, col. 6 lines 8-16, col. 7 lines 36-41; note that routing information is interpreted broadly in accordance with the terms use in the specification, which discusses utilizing information such as an application name for routing).
Regarding claim 16, Ohmert shows onboard device according to claim 1, wherein: the vehicle data acquired by the data acquisition unit includes at least one of: vehicle speed (Ohmert, col. 5 lines 10-15, see “vehicle speed data from the vehicle”); total traveled distance; vehicle body acceleration; vehicle body angular velocity; GPS position information; gear position; battery charge state; fuel tank capacity; remaining fuel amount; average fuel consumption; light status; interior and exterior temperature; air conditioner operation status; door and window open/close status; door and window lock status; seatbelt status; airbag status; tire pressure (Ohmert, col. 6 lines 30-38, see “monitor tire pressure of the vehicle”); parking brake status; accelerator pedal position; brake pedal position; brake pressure; or diagnostic trouble code list.
Regarding claim 18, Ohmert shows a data provision method in an onboard device (col. 4 lines 29-34) that executes a transmission process to send a command used to acquire vehicle data (col. 3 lines 46-65) to an in-vehicle network (Fig. 2 item 212, Fig. 16, col. 4 lines 39-47) and provides the vehicle data acquired by the transmission process to at least one application program (col. 4 lines 5-16), wherein the vehicle data is provided to a requesting application that is the application program (col. 4 lines 5-10) to be a request source of the vehicle data (Fig. 2 steps 206 -> 216, col. 4 lines 15-20, col. 4 lines 48-50), the method comprising: using one or more management information (col. 4 lines 5-20 discussing a vehicle profile) indicating a type of command (col. 4 lines 34-42) used to acquire the vehicle data, the requesting application that is a request source of the vehicle data (col. 6 lines 1-12), and an acquisition condition of the vehicle data (the condition limited by the requesting program’s identity and the vehicle profile, as discussed in col. 4 lines 61-65); extracting, as a transmission target command that is a command to be a transmission target in the transmission process, the command indicated by the management information that meets the acquisition condition (col. 4 line 61-col. 5 line 10); generating routing information associating the transmission target command with the requesting application (col. 6 lines 1-18 discussing comparing the requesting program to a profile containing access rights/permissions; further discussion in col. 7 lines 34-44); and providing the vehicle data acquired (col. 5 lines 11-15) by executing the transmission process to the requesting application using the routing information (col. 5 lines 35-38, col. 5 lines 47-53, col. 6 lines 8-16, col. 7 lines 36-41; note that routing information is interpreted broadly in accordance with the terms use in the specification, which discusses utilizing information such as an application name for routing).
Regarding claim 19, the limitations of said claim are addressed in the rejection of claim 18.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 2, 3, and 6 are rejected under 35 U.S.C. 103 as being unpatentable over Ohmert in view of Wada (US-20210258187-A1).
Regarding claim 2, Ohmert shows claim 1. Ohmert does not show: wherein the data acquisition unit is configured to repeatedly execute the transmission process at a preset execution cycle; and the schedule management unit is configured to extract, as a transmission target command to be transmitted in a next and subsequent execution cycles, the command indicated by the management information that meets the acquisition condition. Wada shows wherein the data acquisition unit is configured to repeatedly execute the transmission process at a preset execution cycle ([60,71]); and the schedule management unit is configured to extract, as a transmission target command ([71-73,83]) to be transmitted in a next and subsequent execution cycles ([74-75] discussing continuing processing while anomalies persist), the command indicated by the management information that meets the acquisition condition ([75] discussing where a lack of an anomaly present stops the process, and [84] discussing that continued anomaly presence results in continued control updates).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the vehicle communication techniques of Ohmert with the event processing and anomaly responses of Wada in order to ensure the most important commands traversing the vehicle network are prioritized, and thus that safety critical controls are reliably executed (Wada, [6-8,22]).
Regarding claim 3, Ohmert shows claim 1. Ohmert does not show: wherein the schedule management unit is configured to obtain a manifest associated with the application program, which describes a type of the vehicle data requested by the application program and the acquisition condition of the vehicle data, from a distribution source of the application program, and to generate the management information according to the manifest. Wada shows wherein the schedule management unit is configured to obtain a manifest associated with the application program ([161]), which describes a type of the vehicle data requested by the application program and the acquisition condition of the vehicle data ([164-165] discussing a data consumer of a vehicle when the vehicle is stopped), from a distribution source of the application program ([164] discussing “a server that offers the service”), and to generate the management information according to the manifest ([161,172] discussing updating permissions based on the manifest).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the vehicle communication techniques of Ohmert with the event processing and anomaly responses of Wada in order to ensure the most important commands traversing the vehicle network are prioritized (said determinations based on a consideration and awareness of the vehicles state) and thus that safety critical controls are reliably executed (Wada, [6-8,22]).
Regarding claim 6, Ohmert in view of Wada further show a peripheral information acquisition unit configured to obtain peripheral information, including information for interpreting a frame received from the in-vehicle network of a vehicle to which the onboard device is connected (Ohmert, col. 4 lines 5 – 20 and lines 60-65 discussing vehicle profile information including “translation functionality”), and information indicating a list of a command usable in the vehicle (Ohmert, Figs. 2 and Fig. 4 step 406), through wireless communication with a server provided outside the vehicle (Ohmert, Abstract, discussing communication with a remote cloud service or external devices as discussed din col. 4 lines 30-48), wherein the data acquisition unit is configured to convert the management information based on the manifest into a format transmittable on the in-vehicle network using the peripheral information, and to interpret a response from the in- vehicle network using the peripheral information (Ohmert, col. 4 lines 5 – 20 and lines 60-65 discussing vehicle profile information including “translation functionality” and Fig. 4 step 408).
Claim 4 is rejected under 35 U.S.C. 103 as being unpatentable over Ohmert in view of Wada as applied to claim 3 above, further in view of Sedar (Sedar, Roshan, et al. "Standards-compliant multi-protocol on-board unit for the evaluation of connected and automated mobility services in multi-vendor environments." Sensors 21.6: 2090. (Year: 2021)).
Regarding claim 4, the above combination shows claim 1 including wherein the manifest includes, as a method for specifying the acquisition condition of the vehicle data (Wada, [161,164-165] discussing the manifest and acquisition conditions for vehicle data). The above combination does not show: periodic drive, which repeatedly acquires data at a fixed interval; application drive, which acquires data in response to a request from the application program; and event drive, which acquires data when a specified event occurs. Sedar shows: periodic drive, which repeatedly acquires data at a fixed interval (pg. 14 lines 12-17, pg. 16 lines 1-16, pg. 18 lines 16-21); application drive, which acquires data in response to a request from the application program (pg. 10 lines 3-56); and event drive, which acquires data when a specified event occurs (pg. 6 lines 20-49, pg. 11 lines 9-21).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the vehicle communication techniques of the above combination with the data gathering options of Sedar in order to ensure that specifics regarding when data is needed or when data available for provision is refreshed is considered when data request mechanisms are specified, thus enabling more efficient resource utilization in the resultant vehicle network.
Claim 5 is rejected under 35 U.S.C. 103 as being unpatentable over Ohmert in view of Wada as applied to claim 3 above, further in view of Li (US-20210067948-A1). Regarding claim 5, the above combination shows claim 3, including the manifest (Wada, [161-165]). The above combination does not show including: a name designation, which specifies the type of the vehicle data using a standardized name representing meaning of the vehicle data; and a command designation, which specifies the type of the vehicle data in a format transmitted and received on the in-vehicle network. Li shows including: a name designation, which specifies the type of the vehicle data using a standardized name representing meaning of the vehicle data; and a command designation, which specifies the type of the vehicle data in a format transmitted and received on the in-vehicle network ([28-34]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the vehicle communication techniques of the above combination with the data descriptors of Li in order to better ensure the communication between the various modules connected to the CAN bus operates reliably.
Claim 7 is rejected under 35 U.S.C. 103 as being unpatentable over Ohmert in view of Cena (Cena, Gianluca, and Adriano Valenzano. "An improved CAN fieldbus for industrial applications." IEEE transactions on industrial electronics 44.4: 553-564. (Year: 1997)).
Regarding claim 7, Ohmert shows claim 1. Ohmert does not show: wherein the schedule management unit is configured to exclude a part of the transmission target command from a processing target of the transmission process to prevent overload of the in-vehicle network when transmitting all transmission target commands extracted from the management information in the transmission process may cause overload. Cena shows wherein the schedule management unit is configured to exclude a part of the transmission target command from a processing target of the transmission process (e.g., based on priority ordering, as discussed on pg. 1 R52-R55 and pg. 2 L22-L26) to prevent overload of the in-vehicle network when transmitting all transmission target commands extracted from the management information in the transmission process may cause overload (note that the limitations regarding what the execution is intended to achieve (i.e., the language starting with “to prevent . . . ”) is interpreted as an intended result implicitly achieved by showing the preceding claim language (and thus analogous to an intended use recitation)).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the vehicle communication techniques of Ohmert with the exclusion techniques of Cena in order to ensure consistent and reliable operation of the resultant vehicle network.
Claim 8 is rejected under 35 U.S.C. 103 as being unpatentable over Ohmert in view of Cena as applied to claim 7 above, further in view of Buczek (US-20190097932-A1).
Regarding claim 8, the above combination shows claim 7. The above combination does not show: wherein the schedule management unit is configured to determine overload when a traffic on the in-vehicle network exceeds an allowable value. Buczek shows wherein the schedule management unit is configured to determine overload when a traffic on the in-vehicle network exceeds an allowable value ([93]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the vehicle communication techniques of the above combination with the overload detection of Buczek in order to ensure network administrators can preset awareness of conditions where the system may not respond as desired, thus enabling a predictable response (such as a countermeasure) when such conditions occur.
Claim 9 is rejected under 35 U.S.C. 103 as being unpatentable over Ohmert in view of Wada as applied to claim 2 above, further in view of Cena and Ballew (US-20230208874-A1).
Regarding claim 9, the above combination shows claim 2. The above combination does not show: wherein the schedule management unit is configured to exclude a part of the transmission target command from a processing target of the transmission process to prevent overload of the in-vehicle network when transmitting all transmission target commands extracted from the management information in the transmission process may cause overload. Cena shows wherein the schedule management unit is configured to exclude a part of the transmission target command from a processing target of the transmission process (e.g., based on priority ordering, as discussed on pg. 1 R52-R55 and pg. 2 L22-L26) to prevent overload of the in-vehicle network when transmitting all transmission target commands extracted from the management information in the transmission process may cause overload (note that the limitations regarding what the execution is intended to achieve (i.e., the language starting with “to prevent . . . ”) is interpreted as an intended result implicitly achieved by showing the preceding claim language (and thus analogous to an intended use recitation)).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the vehicle communication techniques of Ohmert with the exclusion techniques of Cena in order to ensure consistent and reliable operation of the resultant vehicle network.
The above combination does not show wherein, the schedule management unit is configured to determine overload when a total turnaround time of the transmission target command exceeds a period of the execution cycle. Ballew suggests wherein, the schedule management unit is configured to determine overload when a total turnaround time of the transmission target command exceeds a period of the execution cycle ([48]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the vehicle communication techniques of the above combination with the network responsiveness awareness of Ballew in order to enable timely triggering of remediation measures when network performance drops below an acceptable level, thus further improving the likelihood of reliably network operation.
Claim 10 is rejected under 35 U.S.C. 103 as being unpatentable over Ohmert in view of Wada, Cena, and Ballew as applied to claim 9 above, further in view of Maeda (US-20160294855-A1).
Regarding claim 10, the above combination shows claim 9. The above combination does not show where the turnaround time is measured at the startup of the onboard device. Maeda shows where the turnaround time is measured at the startup of the onboard device ([63]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the vehicle communication techniques of the above combination with time tracking of Maeda in order to ensure the tracked time intervals are consistently measured and evaluated, better ensuring consistent and reliable operation of the applicable vehicle.
Claim 11 is rejected under 35 U.S.C. 103 as being unpatentable over Ohmert in view of Wada, Cena, and Ballew as applied to claim 9 above, further in view of Schmitt (Schmitt, W. English translation of DE 102014218882 A1. (Year: 2014)).
Regarding claim 11, the above combination shows claim 9, including measurement of turnaround time ([48]). The above combination does not show wherein the time is measured when there is a change in a hardware configuration connected to the onboard device or there is a change in a software configuration of the application program executed by the application execution unit. Schmitt shows wherein the time is measured when there is a change in a hardware configuration connected to the onboard device or there is a change in a software configuration of the application program executed by the application execution unit (pg. 3 lines 10-15).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the vehicle communication techniques of the above combination with time tracking of Schmitt in order to ensure the tracked time intervals are consistently measured and evaluated, and that only values gathered under comparable circumstances are compared, thus better ensuring consistent and reliable operation of the applicable vehicle.
Claim 17 is rejected under 35 U.S.C. 103 as being unpatentable over Ohmert in view of Bolt (US-11024102-B2).
Regarding claim 17, Ohmert shows where the data acquisition unit is configured to use a diagnostic command used in diagnostic communication as the command (col. 1 line 35 – col. 2 line 60, col. 8 lines 9-27, Fig. 5). Ohmert does not show: wherein the onboard device is connected to the in-vehicle network via a diagnostic port provided in a vehicle. Bolt shows wherein the onboard device is connected to the in-vehicle network via a diagnostic port provided in a vehicle (col. 5 lines 51-60 discussing use of an OBD port).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the vehicle communication techniques of Ohmert with the port use of Bolt in order to utilize a industry standard (the OBD port) for its intended purpose (to communicate with the vehicle network) and thus enable improved diagnostic gathering and vehicle control capabilities.
Subject Matter Allowable over Prior Art
Claims 12 and 13 - 15 would be allowable, absent the pending rejections made under 35 USC 112.
Based on the Examiner’s present understanding of the scope of claims 12 and 13 (with claims 14 and 15 dependent on claim 13), the prior art fails to teach or suggest the execution cycle-based management exclusion functionality of claim 12 (when evaluated in full context of parent claim 2) as well as the command priority consideration features of claim 13 (when evaluated in full context of parent claim 7). While these claims are not presently rejected utilizing prior art, the Examiner notes that adjustments to these claims or the parent claims upon which they depend (e.g., to address issues under 35 USC 112) would require further consideration of these otherwise objected-to claims.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. This includes:
Aliwa (Aliwa, Emad, et al. "Cyberattacks and countermeasures for in-vehicle networks." ACM computing surveys (CSUR) 54.1: 1-37. (Year: 2021)) and Kishikawa (US-20210314336-A1).
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JOHN M MACILWINEN whose telephone number is (571)272-9686. The examiner can normally be reached Monday - Friday, 9:00 - 5:00.
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, Glenton B Burgess can be reached at (571) 272 - 3949. 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.
JOHN MACILWINEN
Primary Examiner
Art Unit 2442
/JOHN M MACILWINEN/Primary Examiner, Art Unit 2454
Prosecution Insights