DETAILED ACTION
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 .
Status of Claims
This office action is in response to application number 19/181,278 filed on 04/16/2025, in which Claims 1-13 are presented for examination.
Priority
Acknowledgment is made of applicant's claim for foreign priority based on an application filed in Germany on 4/22/2024. It is noted, however, that applicant has not filed a certified copy of the DE-10 2024 203 733.8 application as required by 37 CFR 1.55.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 4/16/2025 and the IDS submitted on 5/28/2025 has been received and considered by the examiner.
Drawings
The drawings are objected to because:
FIGs. 6 and 7, pg. 22: the “availability zones” are shown using a box and a reference character, but they do not a have label with text clearly defining it as, for example, a “first availability zone,” (for comparison, the “first data processing device” and “second processing device” have the text and reference characters).
FIG. 6 and 7: the drawing would be more clear if more space was provided between the components and the flow arrows, or connecting lines, used line jumps to more clearly differentiate lines passing over each other and lines intersecting each other.
FIGs. 6 and 7, pg. 25, lines 4-12: FIG. 6 is described as the data processing devices sending infrastructure assistance data 635 to the vehicle, but the drawing does not include any arrows to indicate this data flow.
Corrected drawing sheets in compliance with 37 CFR 1.121(d) are required in reply to the Office action to avoid abandonment of the application. Any amended replacement drawing sheet should include all of the figures appearing on the immediate prior version of the sheet, even if only one figure is being amended. The figure or figure number of an amended drawing should not be labeled as “amended.” If a drawing figure is to be canceled, the appropriate figure must be removed from the replacement sheet, and where necessary, the remaining figures must be renumbered and appropriate changes made to the brief description of the several views of the drawings for consistency. Additional replacement sheets may be necessary to show the renumbering of the remaining figures. Each drawing sheet submitted after the filing date of an application must be labeled in the top margin as either “Replacement Sheet” or “New Sheet” pursuant to 37 CFR 1.121(d). If the changes are not accepted by the examiner, the applicant will be notified and informed of any required corrective action in the next Office action. The objection to the drawings will not be held in abeyance.
The drawings are objected to as failing to comply with 37 CFR 1.84(p)(4) because reference character “623” has been used to designate every comparison step in FIGs. 6 and 7, where each comparison step is not necessarily performing the same comparison. Examiner recommends using unique numbers for each comparison type or using sub-reference characters of 623 (for example: FIG. 6 first data processing device 617 is comparing first and third data, while second data processing device 619 is comparing first and second data and therefore, for example, would respectively be 623a and 623b. Corrected drawing sheets in compliance with 37 CFR 1.121(d) are required in reply to the Office action to avoid abandonment of the application. Any amended replacement drawing sheet should include all of the figures appearing on the immediate prior version of the sheet, even if only one figure is being amended. Each drawing sheet submitted after the filing date of an application must be labeled in the top margin as either “Replacement Sheet” or “New Sheet” pursuant to 37 CFR 1.121(d). If the changes are not accepted by the examiner, the applicant will be notified and informed of any required corrective action in the next Office action. The objection to the drawings will not be held in abeyance.
Specification
The disclosure is objected to because of the following informalities:
pg. 12, line 22: “automated manner, for example,.” needs clarification and correction,
pg. 20, line 21: “receiving 201 infrastructure assistance” should be “receiving 203 infrastructure assistance”, and
pg. 22, lines 23-24: “a third data processing device is implemented in the third availability zone 615” for consistency should be “third data processing device 621 is implemented in the third availability zone 615.”
Appropriate correction is required.
The use of the term "Wi-Fi”, which is a trade name or a mark used in commerce, has been noted in this application. The term should be accompanied by the generic terminology; furthermore the term should be capitalized wherever it appears or, where appropriate, include a proper symbol indicating use in commerce such as ™, SM , or ® following the term.
Although the use of trade names and marks used in commerce (i.e., trademarks, service marks, certification marks, and collective marks) are permissible in patent applications, the proprietary nature of the marks should be respected and every effort made to prevent their use in any manner which might adversely affect their validity as commercial marks.
Claim Objections
Claims 1, 3-8, and 11-13 are objected to because of the following informalities:
Claim 1 (lines 7, 10, 12, 14, 17, 18, and 20) recites “respectively” and “respective.” It is unclear what “respective[ly]” is being used to convey and should be removed, or further clarified. For example, if multiple sets of surroundings data or different infrastructure assistance data is calculated per each data processing device, it would be more clear if terms like “first data processing device,” first received surroundings data,” “second data processing device,” or “second self-ascertained infrastructure data,” were used. These are provided as examples, if amendments are made they should be consistently made to all impacted claims and limitation. Dependent Claims 5-7 and Independent Claims 8, 11, 12, and 13 should also be addressed.
Claim 3: “that at least at least three” should be “that at least three.”
Claim 4 (lines 1-2): “two of the data processing devices” should be “two of the at least three data processing devices.”
Claim 4 (line 3): “the wherein” should be “wherein.”
Appropriate correction is required.
Claim Interpretation
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The following is a quotation of pre-AIA 35 U.S.C. 112, sixth paragraph:
An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The claims in this application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the specification as it would be understood by one of ordinary skill in the art. The broadest reasonable interpretation of a claim element (also commonly referred to as a claim limitation) is limited by the description in the specification when 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is invoked.
As explained in MPEP § 2181, subsection I, claim limitations that meet the following three-prong test will be interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph:
(A) the claim limitation uses the term “means” or “step” or a term used as a substitute for “means” that is a generic placeholder (also called a nonce term or a non-structural term having no specific structural meaning) for performing the claimed function;
(B) the term “means” or “step” or the generic placeholder is modified by functional language, typically, but not always linked by the transition word “for” (e.g., “means for”) or another linking word or phrase, such as “configured to” or “so that”; and
(C) the term “means” or “step” or the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function.
Use of the word “means” (or “step”) in a claim with functional language creates a rebuttable presumption that the claim limitation is to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites sufficient structure, material, or acts to entirely perform the recited function.
Absence of the word “means” (or “step”) in a claim creates a rebuttable presumption that the claim limitation is not to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is not interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites function without reciting sufficient structure, material or acts to entirely perform the recited function.
Claim limitations in this application that use the word “means” (or “step”) are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action. Conversely, claim limitations in this application that do not use the word “means” (or “step”) are not being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action.
This application includes one or more claim limitations that do not use the word “means,” but are nonetheless being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, because the claim limitation(s) uses a generic placeholder that is coupled with functional language without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier. Such claim limitation(s) is/are:
“devices […] configured to” in Claims 11 and 12.
Corresponding structure is identified in the specification. The specification describes the data processing devices as devices with different hardware and software configurations and includes devices implemented in a cloud infrastructure in communication with a communication device. For example, [pg. 13] discusses the device’s hardware independence of each other, [pg. 13,lines 22-26], “In the case of two data processing devices, it is provided that one of the data processing devices is implemented in the availability zone of the other data processing device, for instance, but is implemented independently of the other of the two data processing devices in terms of hardware.” Further, [pg. 15] discusses different configurations, which include hardware and software features and, [pg. 18, lines 17-18] states, “A data processing device within the meaning of the description is implemented in a cloud infrastructure, for example.” For examination purposes, the data processing devices will be interpreted as devices with hardware and software, such as a computer or control module.
Because this/these claim limitation(s) is/are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, it/they is/are being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof.
If applicant does not intend to have this/these limitation(s) interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, applicant may: (1) amend the claim limitation(s) to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph (e.g., by reciting sufficient structure to perform the claimed function); or (2) present a sufficient showing that the claim limitation(s) recite(s) sufficient structure to perform the claimed function so as to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph.
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- 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.
Claim 1 and Claim 11 recite “the data processing devices.” There is insufficient antecedent basis for the limitation of the claims.
Claim 1 (lines 4-5) and Claim 11 (line 4) recites “receive[ing] […] same surroundings data,” whereas Claim 1 (lines 9-10) and Claim 11 (lines 9-10) recites “the respective received surroundings data.” There is insufficient antecedent basis for “the respective received surroundings data” as recited in the claims.
Claim 1 (lines 11-12) and Claim 11 (lines 12-13) recite “the respective self-ascertained infrastructure assistance data.” There is insufficient antecedent basis for the limitation of the claims.
In light of the objections, the above-cited rejections, and the language found in the specification, the following interpretations are made, including interpretations to language made for a consistent, proper antecedent basis. Please note these are intended as interpretations, not Examiner’s Amendments.
Claim 1 (lines 4-11): receiving, using the at least two data processing devices, same surroundings data […];
Claim 1 (lines 7-10): calculating, using the at least two data processing devices, infrastructure assistance data […] based on the same received surroundings data, including at least first infrastructure assistance data calculated using a first data processing device and second infrastructure data calculated using a second data processing device;
Claim 1 (line 11): comparing, using the at least two data processing devices, at least the first infrastructure assistance data and the second infrastructure to calculate a comparison result;
Claim 1 (lines 16-18): applying, using the at least two data processing devices, a same hash function to the comparison result to calculate a hash value;
Claim 1 (lines 19-21): sending, using the at least two data processing devices, the hash value […]; and
Claim 1 (lines 23-24): sending, using the at least two data processing devices, the first infrastructure assistance data or the second infrastructure assistance data […].
For examination purposes, Claim 11 is interpretated in a similar way to the interpretation provided above for Claim 1.
In line with the rejections and interpretations stated above, the following rejections and interpretations are made:
Claim 2 (lines 1-2) recites “the data processing devices.” There is insufficient antecedent basis for the limitation of the claim. For examination purposes, this will be interpreted as “the at least two data processing devices.”
Claim 4 (line 1) recites “[two of] the data processing devices.” There is insufficient antecedent basis for the limitation of the claim. For examination purposes, this will be interpreted as “[two of] the at least three data processing devices.”
Claim 4 (lines 4-6) “[of one of] the two data processing devices.” There is insufficient antecedent basis for the limitation of the claim. For examination purposes, this will be interpreted as “[one of] the first data processing device or the second data processing device.”
Claim 5 (lines 1-2) recites “the respective calculation of the infrastructure assistance data.” There is insufficient antecedent basis for the limitation of the claim. For examination purposes, this will be interpreted as “the calculation of the infrastructure assistance data.”
Claim 5 (lines 3-4) “the same source code. ” There is insufficient antecedent basis for the limitation of the claim. For examination purposes, this will be interpreted as “same source code.”
Claim 6 (lines 2-4) recites “[a configuration of] the data processing devices.” There is insufficient antecedent basis for the limitation of the claim. For examination purposes, this will be interpreted as “[a configuration of] the at least two data processing devices.”
Claim 7 (lines 2-3) recites “the following group of configuration parameters. ” There is insufficient antecedent basis for the limitation of the claim. For examination purposes, this will be interpreted as “a group of configuration parameters comprising: […].”
Claim 7 recites “the data processing device.” For examination purposes, this will be interpreted as “the at least two data processing devices.”
Claims 8 (lines 9-10), 12 (line 10), and 13 (lines 13-14) recite “the received hash values.” There is insufficient antecedent basis for the limitation of the claim. For examination purposes, Claims 8 (line 3), 12 (lines 3-4), and 13 (line 6), will be read as “receive[ing] a hash value,” in line with the objection recited above to remove “respective[ly]” from the claim language.
Similarly, Claim 9 (line 4) recites “the hash values.” There is insufficient antecedent basis for the limitation of the claim. For examination purposes, Claim 9 (line 4) will be read as “the received hash values.”
Claims 8 (line 6), 12 (line 6), and 13 (line 9) “the data processing devices.” There is insufficient antecedent basis for the limitation of the claim. For examination purposes, this will be interpreted as “the at least two data processing devices.”
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 8-10, 12, and 13 are rejected under 35 U.S.C. 101 because the claimed invention is directed to abstract idea without significantly more.
Claim 8. A method for at least partially automated guidance of a motor vehicle, the method comprising the following steps:
receiving a respective hash value [data gathering] from at least two data processing devices [apply it];
receiving infrastructure assistance data [data gathering] from one of the data processing devices [apply it];
determining that the received infrastructure assistance data can be used for at least partially automated guidance of the motor vehicle based on the received hash values [mental process].
101 Analysis
Step 1: Statutory Category – Yes
The claim recites a method for receiving infrastructure assistance data and a hash value and determining if the data can be used for automated guidance of a vehicle, using the hash values.
Step 2A Prong One Evaluation: Judicial Exception – Yes – Mental Process
The claim recites the mental processes, as bolded above. These limitations, as drafted, are simple processes that, under their broadest reasonable interpretation, could be performed in the human mind. For example, a person can review data to determine if the data is valid or usable, for example, based on a criteria.
Step 2A Prong Two Evaluation: Practical Application – No
This judicial exception is not integrated into a practical application because the additional elements (underlined above) do not impose any meaningful limit on the judicial exception.
Receiving infrastructure assistance data and a hash value are recited at a high level, and amount to mere data gathering, which is a form of insignificant extra-solution activity.
Data processing devices act merely as a means for applying the abstract idea.
Step 2B Evaluation:
The claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception because the additional claim elements, as stated for Step 2A Prong Two, do no more than provide application of the abstract idea and add extra-solution activity. And therefore, does not provide an inventive concept.
Independent Claims 12 and 13 do not recite any further limitations that cause the claims to be patent eligible. Rather, the limitations of the claims are direct towards an apparatus and a medium for performing the method of Claim 8, and do not integrate the judicial exception into a practical application. Therefore, Claim 12 and 13 are not patent eligible under the same rational as provided for Claim 8.
Dependent Claims 9-10 do not recite any further limitations that cause the claims to be patent eligible. The limitations of the dependent claims further narrow the abstract idea, and thus can also be performed as a mental process, in the human mind. These limitations do no more than provide additional means for applying the abstract idea. Therefore, Claims 9-10 are not patent eligible under the same rational as provided for Claim 8.
Therefore, Claims 8-10, 12, and 13 are rejected under 35 U.S.C. § 101 as being directed to a judicial exception, without amounting to significantly more.
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 (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 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 8-10 and 12-13 are rejected under 35 U.S.C. 103 as being unpatentable over Ditty et al., PG Pub US-2019/0258251-A1 (herein "Ditty") in view of Schuerman et al., PG Pub US-2023/0358568-A1 (herein "Schuerman").
Regarding Claim 8, Ditty discloses: A method for at least partially automated guidance of a motor vehicle, the method comprising the following steps: […]; receiving infrastructure assistance data from one of the data processing devices; determining that the received infrastructure assistance data can be used for at least partially automated guidance of the motor vehicle […]. See [Ditty, pg. 73, para 0171], which explains that infrastructure data generated from deep learning is compared with vehicle data, “[0171] The deep-learning infrastructure is capable of fast, real-time inferencing, and may use that capability to evaluate and verify the health of the processors, software, and associated hardware in Vehicle (50). For example, deep-learning infrastructure preferably receives periodic updates from Vehicle (50) including a sequence of images and the objects that the Vehicle (50) located (via computer vision or other machine learning object classification techniques) in that sequence of images. Deep-learning infrastructure runs its own neural network to identify the objects and compare them with the objects identified by Vehicle (50); if the results do not match and the infrastructure concludes that the AI in the Vehicle (50) is malfunctioning, it can send a signal to Vehicle (50) instructing the fail-safe computer to assume control, notify the passengers, and complete a safe parking maneuver.” See also [Ditty, pg. 87, paras 0319-0325], which explains that a supervisory MCU receives input commands from a primary and secondary computer to evaluate the inputs to pass the correct input commands to the vehicle for control, “[0319] […]. As shown in FIG. 26, the system includes a Primary Computer (On-Board Computer) (100) and a Secondary or Backup Computer (On-Board Computer) (200). […]. [0320] […]. [0321] […]. [0322] The Primary Computer (100) contains mission/primary control functions. In certain preferred embodiments, the Primary Computer (100) executes an autonomous driving software stack from NVIDIA, which provides functions including perception, planning, and control. As discussed above, Perception Module (101), takes sensor input and produces a world model, or occupancy grid, predicts the behavior of objects in that world model, produces the best plan for the driving situation, and formulates actuator commands to implement that plan. […]. The Perception Module (101) instructs a Driving Module (102) to perform a dynamic driving task. [0323] In preferred embodiments, especially when Secondary Computer (200) comprises the same or similar hardware as Primary Computer (100), Secondary Computer (200) runs redundant diverse software to detect faults in perception and dynamic driving task. It also includes a Perception Module (201), which takes sensor input and produces a world model and produces the best plan for the driving situation and implements it. In embodiments where the Secondary Computer (200) comprises a plurality of ADAS systems, the Secondary Computer independently operates the plurality of ADAS systems and provides output comprises of potential warnings […]. [0324] The system includes a Supervisory MCU (600), which receives input from the Primary Computer (100) the Secondary Computer (200). The Supervisory MCU (600) evaluates the input, arbitrates any conflicts, and passes commands to the actuators. The key parameters under the Supervisory MCU's control include the (1) throttle, (2) brake, (3) applied steering torque, and (4) transmission drive-gear selection. [0325] The Supervisory MCU (600) monitors shared resources and compares results at multiple stages in pipeline; it compares the input from the Primary Computer (100) the Secondary Computer (200) to determine whether the two computers are sufficiently aligned, such that the command from the primary computer should be obeyed.” Finally see [Ditty, pg. 35, para 0484], which explains that the perception can include cloud mapping, remote to the vehicle and accessible via a network, “In example non-limiting embodiments, aspects of map perception 3016 are provided to a cloud mapping application 3022 that may be remotely located from the ego-vehicle and accessible via a network 3024. In this context, “ego-vehicle” refers to the perspective and/or instance of a vehicle that uses the FIG. 41 platform (to actuate its own steering, braking, navigation, decision-making) in combination with other systems to accomplish autonomous driving. Perception for mapping 3016 and localization 3026 is communicated through the cloud 3024 between drives of the ego-vehicle to bring affordance estimates from previous drives of the ego-vehicle into the present. Perception for mapping 3016 and localization 3026 may also communicate through the cloud 3024 to bring affordance estimates for past and present drives of vehicles other than the ego-vehicle. Cloud mapping 3022 may receive inputs from a number of different contemporaneously and/or previously operating autonomous vehicles and other information sources, for example. The cloud mapping 3022 provides mapping outputs which are localized by localization 3026 based e.g., upon the particular location of the ego-vehicle, with the localized output used to help generate and/or update the world model 3002. The world model 3002 so developed and maintained in real-time is used for autonomous vehicle planning 3004, control 3006 and actuation 3008.”
Ditty does not disclose: receiving a respective hash value from at least two data processing devices.
However, Schuerman teaches: receiving a respective hash value from at least two data processing devices; […]; [determining …] based on the received hash values. See [Schuerman, pg. 1, para 0009], which explains that map data can be received by a vehicle for use by AD/ADAS applications, “Such requests are typically handled by a suitable client application (interface) executing on the vehicle. The client application (interface) receives the map tile(s) and then processes these accordingly to extract the relevant map data. The client application (interface) can then distribute the map data to any, e.g., AD/ADAS applications, as desired. This has typically been done with reference to a suitable “horizon” generated by considering the predicted upcoming driving path, e.g. based on the current vehicle position, the driving conditions, and road data. The horizon can then be associated with a set of map tiles representing a sub-map in the area leading up to the horizon onto which dynamic (e.g. sensor) data can be added, e.g., to implement the AD/ADAS functionality. Typically a plurality of horizons are generated for a corresponding plurality of predicted driving paths to be able to better account and adjust for the vehicle deviating from any one of the predicted driving paths.” See [Schuerman, pgs. 2-3, paras 0013-0016 and 0021], which explains that the map data can be generated by a server and transmitted to a vehicle along with associated security data, “[0013] According to a first aspect of the present invention there is provided a method of verifying map data that is being transmitted from a remote server to one or more map-based application(s) executing on an electronic control unit (ECU) of a vehicle traversing a navigable network covered by a digital map, wherein the digital map is represented as a set of plural map tiles, each tile representing a particular geographical area including a portion of the navigable network, the method comprising: [0014] generating, at the server, a data structure for a map tile, wherein the data structure includes object data indicative of a set of one or more object(s) falling at least partially within the geographical area covered by the tile and/or within the geographical area covered by another one or more of the tile(s) representing the digital map, [0015] wherein, for at least one object in the set of one or more object(s) for which object data is included in the map tile data structure, associated security data is included within the map tile data structure along with the object data for the at least one object, the security data being usable for verifying the integrity of its associated object data; and [0016] transmitting the map tile data structure for the tile including the object data and associated security data from the server to a client application executing on one or more processing unit(s) of the vehicle. […] [0021] Part of ensuring the reliability of the map data, and enhancing the functional safety for applications relying on the map data, is being able to verify the integrity and authenticity of the data that is being delivered to the vehicle. To this end, the tile data structures may be (and in preferred embodiments are) digitally signed so that it can be checked that the tile data structure received by the client application (interface) matches what was transmitted from the original server(s). Thus, in embodiments, after the tile data structures been compiled at a first server, each tile data structure may then be digitally signed at the (or another) server before it is delivered to a vehicle. […]. Thus, when a tile data structure is transmitted from the server to an appropriate client application (interface) executing on the vehicle, before the client application (interface) attempts to use, or distribute, the map object data stored for the tile, the client application (interface) can check the digital signature to verify the integrity of the tile data structure,” where [Schuerman, pg. 5, paras 0035-0036], the associated security data can be in the form of a digital signature, such as a hash value or code, or other error detecting code such as a check sum or parity code, “[0035] The security data associated with an object may take any suitable form, as desired. Various techniques for verifying the integrity and/or authenticity of data are well established and may be used, as desired. In particularly preferred embodiments, the security data comprises a 64-bit truncated SHA-256 hash value (or hash ‘code’). […]. Thus, in embodiments, for at least some of the objects (and preferably for each of the objects) in a tile data structure for which security data is stored, the security data may be provided in the form of a security hash (value) for the object data that is calculated at the server. The object data may thus be verified at the client application (interface) by the client application (interface) re-calculating the hash value based (at least) on the object data and comparing this to the hash value contained within the security data. […]. [0036] However other arrangements for authenticating the object data and metadata would of course be possible and it is not necessary to use security hashes. For instance, it will be appreciated that the security data may in other embodiments alternatively, or additionally, comprise any suitable error detecting code (e.g. a minimum distance code, hash code, checksum code, parity code, cyclic redundancy check, etc.), error correcting code (block code, convolutional code, Hamming code, Viterbi code, etc.), message authentication code, digital signature, or the like.”
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the invention, to modify Ditty with Schuerman to include receiving a hash value for verifying assistance data. Doing so provides a more efficient method for ensuring the functional safety of the data, which can be complex [Schuerman, pg. 2, paras 0010-0012], where a hash value provides a reliable, but simple and efficient, in terms of storage and network usage, method for implementation at various functional safety levels [Schuerman, pg. 5, para 0035].
Regarding Claim 9, Ditty as modified discloses the limitations of Claim 8.
Ditty further discloses: wherein it is determined that the received infrastructure assistance data can be used for at least partially automated guidance of the motor vehicle when the […] values match. See again [Ditty, pg. 73, para 0171], which explains that infrastructure data generated from deep learning is compared with vehicle data. Also see again [Ditty, pg. 87, paras 0319-0326], which explains that a supervisory MCU receives input commands from a primary and secondary computer to evaluate the inputs to pass the correct input commands to the vehicle for control, where the evaluation includes determining if the inputs are sufficiently aligned or different, “[0325] The Supervisory MCU (600) monitors shared resources and compares results at multiple stages in pipeline; it compares the input from the Primary Computer (100) the Secondary Computer (200) to determine whether the two computers are sufficiently aligned, such that the command from the primary computer should be obeyed. […]. [0326] When the results provided by the first computer and second computer different, the Supervisory MCU (600) must arbitrate between them, for example, as illustrated in FIG. 25.”
Dity does not disclose: […] hash values match […].
However, Schuerman teaches: […] hash values match […]. See again [Schuerman, pg. 1, para 0009], which explains that map data can be received by a vehicle for use by AD/ADAS applications. Also see again [Schuerman, pgs. 2-3, paras 0013-0016 and 0021], which explains that the map data can be generated by a server and transmitted to a vehicle along with associated security data, where [Schuerman, pg. 5, paras 0035-0036], the associated security data can be in the form of a digital signature, such as a hash value or code, or other error detecting code such as a check sum or parity code.
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the invention, to modify Ditty with Schuerman to include using a hash value for verifying assistance data. Doing so provides a more efficient method for ensuring the functional safety of the data, which can be complex [Schuerman, pg. 2, paras 0010-0012], where a hash value provides a reliable, but simple and efficient, in terms of storage and network usage, method for implementation at various functional safety levels [Schuerman, pg. 5, para 0035].
Regarding Claim 10, Ditty as modified discloses the limitations of Claim 8.
Ditty further discloses: wherein said determination is carried out by a watchdog. See [Ditty, pg. 28, para 0369], which explains that operations can also be performed on a virtual platform, where a watchdog is used for safety monitoring of the functions across various CPUs, “Virtualized platform 4000 may further include any number of virtual servers such as a resource manager (RM) server 4010(1), communications server 4010(2), and other servers 4010(3) . . . 4010(L). Such servers may comprise virtualized hardware without direct hardware support, to support any or all of virtual machines 4002. […]. [0375] a security server 4010(8) for managing the security engine; [0376] a debug server 4010(9) for use in debugging; [0377] a safety monitor (watchdog) server 4010(10) that monitors all of the other functions running on the CPU cores 4006 and reports status to on-chip hardware or other resources; and/or [0378] other.” See also [Ditty, pgs. 30-31, paras 0421-0423], which further explains that the driving control functions require redundancy and safety monitoring, which can be performed by a watchdog of the virtual system for monitoring the control functions of the autonomous vehicle, “[0421] The safety framework operates independently of the driving control functions it is monitoring such that failure of driving control hardware/software functions does not cause the safety framework to also fail. […] by providing a resilient multilevel/multilayered safety framework structure in which some safety framework components watch and monitor other safety framework components executing on different hardware. […]. [0422] For example, an application watchdog monitoring function running within the virtual machine/partition of high-performance drive application processors may be responsible for monitoring intricate details of the operation of those application processes. [..]. [0423] In some example embodiments, the safety framework provides features that streamline collection/dispatch for structured handling of safety relevant hardware and software errors. An autonomous driving operating system layered over a safety supervision framework designed for ASIL-D systematics provides strong isolation/foreign function interface (FFI) for safety.”
Regarding Claim 12, Ditty discloses: An apparatus for at least partially automated guidance of a motor vehicle, comprising: a communication device configured to receive […] infrastructure assistance data from one of the data processing devices; and a processor device configured to determine that the received infrastructure assistance data can be used for at least partially automated guidance of the motor vehicle […]. See [Ditty, pg. 2 paras 0017-0018 and 0022], which explains that the ADAS systems, such as adaptive cruise control, can utilize wireless data through a vehicle-to-vehicle or infrastructure-to-vehicle system, “[0022] Cooperative Adaptive Cruise Control (“CACC”) uses information from other vehicles. This information may be received through an antenna and a modem directly from other vehicles (in proximity), via wireless link, or indirectly, from a network connection. Direct links may be provided by vehicle-to-vehicle (“V2V”) communication link, while indirect links are often referred to as infrastructure-to-vehicle (“I2V”) links. In general, the V2V communication concept provides information about the immediately preceding vehicles (i.e., vehicles immediately ahead of and in the same lane as the ego vehicle), while the I2V communication concept provides information about traffic further ahead. CACC systems can include either or both I2V and V2V information sources. Given the information of the vehicles ahead of the host vehicle, CACC can be more reliable and it has potential to improve traffic flow smoothness and reduce congestion on the road,” where [Ditty pgs.7-8, para 0127] the vehicle collects the data using a modem for communicating with the wireless network, “Vehicle (50) collects data that is preferably used to help train and refine the neural networks used for self-driving. The vehicle includes modem (103), preferably a system-on-a-chip that provides modulation and demodulation functionality and allows the controller (100) to communicate over the wireless network (1100).” See also [Ditty, pg. 2, para 0020 and FIGs. 15-19 and pgs. 19-21, paras 0275-0290], which discuss that the vehicle functions system includes the MCU and a non-transitory memory for storing program instructions to perform tasks, “[0020] The most common ACC systems use a single RADAR, though other combinations (multiple RADARs, such as one long range RADAR coupled with two short range RADARs, or combinations of LIDAR and cameras) are possible. Longitudinal ACC systems use algorithms that can be divided into two main groups: rule-based and model-based approaches. Rule-based longitudinal ACC approaches use if—then rules, which may be executed on any processor, including an FPGA, CPU, or ASIC,” where [Ditty, pg. 19, para 0280] the MCU is a microcontroller using processors, “As illustrated in FIG. 17, the Advanced SoCs (100) are each connected to a Microcontroller (“MCU”) (803). MCU may comprise an SoC, stand-alone ASIC, or other processor. Commercially-available MCUs include microcontrollers. In a typical embodiment, the MCU is designed for an ASIL D functional safety level,” and [Ditty, pg. 23, paras 0315-0317] the primary and secondary computers also use processors for performing the requirements of the ADAS systems, “[0315] The system may include one or more LIDAR sensors, (300), as well as a plurality of other sensors, (400), including RADAR, Cameras, Ultrasonic, and other sensors. The LIDAR sensors, (300), and the other sensors, (400), provide inputs to the Primary Computer (On-Board Computer) (100). The plurality of other sensors, (400), also provide input to the Backup Computer (On-Board Computer) (200). […]. [0316] The Primary Computer (On-Board Computer) (100) and the Backup Computer (On-Board Computer) (200) may each be configured according to FIG. 17, FIG. 18, or FIG. 19. Alternatively, the Primary Computer (On-Board Computer) (100) may include one more Advanced SoCs as in FIG. 17, FIG. 18, or FIG. 19, […]. […]. [0317] […]. Similarly, in embodiments the plurality of discrete ADAS system comprising Secondary Computer (200) may rely on different discrete sensors and processors, including CPUs, FPGAs, SoCs, and ASICs from various ADAS suppliers and/or semiconductor manufacturers. In such embodiments, the technology provides greater ASIL functional safety by combining redundant and independent subsystems of lower ASIL, such as two ASIL B subsystems, or one ASIL C subsystem and a second subsystem of ASIL A, B, or C.” See also [Ditty, FIGs. 41-42 and pg. 36, paras 0511-0512] which provides a detailed illustration of the architecture for communicating with cloud and determining the control, where the architecture includes memory and processing modules, “[0511] More Detailed Example Architecture [0512] FIG. 42 shows a more detailed breakdown of an example platform 3000. In FIG. 42, blocks with darker lines indicate data structures (typically stored in non-transitory memory) and the other boxes indicate processing modules or functions (typically implemented by one or more processors executing instructions that may include—for example and without limitation—deployments of one or more trained neural networks).” Finally see again [Ditty, pg. 73, para 0171], which explains that infrastructure data generated from deep learning is compared with vehicle data and [Ditty, pg. 87, paras 0319-0326], which explains that a supervisory MCU receives input commands from a primary and secondary computer to evaluate the inputs to pass the correct input commands to the vehicle for control, where the evaluation includes determining if the inputs are sufficiently aligned or different.
Ditty does not disclose: […] a communication device configured to receive a respective hash value from at least two data processing devices […]; and a processor device [configured to determine that the received infrastructure assistance data can be used …] based on the received hash values.
However, Schuerman teaches: [… a communication device configured to] receive a respective hash value from at least two data processing devices […]; [and a processor device configured to determine that the received infrastructure assistance data can be used …] based on the received hash values. See again [Schuerman, pg. 1, para 0009], which explains that map data can be received by a vehicle for use by AD/ADAS applications. Also see again [Schuerman, pgs. 2-3, paras 0013-0016 and 0021], which explains that the map data can be generated by a server and transmitted to a vehicle ECU along with associated security data, where [Schuerman, pg. 5, paras 0035-0036], the associated security data can be in the form of a digital signature, such as a hash value or code, or other error detecting code such as a check sum or parity code. Finally see [Schuerman, pg. 2, para 0020 and 0084-0085], which explain that the processor and non-transitory memory of the ECU on-board the vehicle is used to extract data, “[0020] The use of such a tile-based approach may help provide a more efficient transmission and distribution of the map data from the various map data sources to the vehicles requiring the map data. For instance, an advantage of the tile-based approach is that it is possible to readily compile map data from different sources at the server (or at a plurality of servers) into a set of respective tiles, and then deliver or provide relevant map data, e.g. on a tile-by-tile basis, to vehicles requiring map data for the regions covered by the tiles. The tile data structure(s) can then be unpacked, e.g., by a suitable client application (interface) executing on one or more processor(s) on-board the vehicle in order to extract the desired (map) object data which can then be distributed to various map-based applications running within the in-vehicle environment, as required. […] [0084] […]. The vehicle includes one or more processor(s) that execute various client applications that handle the map tile data structures as well as one or more map-based application(s) running on an engine control unit (ECU) of the vehicle requiring the map data. Such systems may be arranged to perform any (or all) of the method steps herein described. […]. [0085] The various functions of the technology described herein can be carried out in any desired and suitable manner. For example, the steps and functions of the technology described herein can be implemented in hardware or software, as desired. Thus, for example, unless otherwise indicated, the various processors, functional elements, stages, and “means” of the techniques described herein may comprise any suitable processor or processors, controller or controllers, functional units, circuitry, processing logic, microprocessor arrangements, etc., that are operable to perform the various steps or functions, etc., such as appropriately dedicated hardware elements (processing circuitry) and/or programmable hardware elements (processing circuitry) that can be programmed to operate in the desired manner. For example, the means for carrying out any of the steps of the method according to any of the aspects or embodiments described herein may generally comprise a set of one or more processors (or processing circuitry) configured, e.g. programmed with a set of computer readable instructions, for doing so. A given step may be carried out using the same or a different set of processors to any other step. Any given step may be carried out using a combination of sets of processors. The system may further comprise data storage means, such as computer memory, for storing, for example, the at least one repository including the instructive and informative data. Any of the methods in accordance with the present invention may be implemented at least partially using software, e.g. computer programs. The present invention thus also extends to a computer program product comprising computer readable instructions executable to perform, or to cause a system and/or server to perform a method according to any of the aspects or embodiments of the invention. Thus, the present invention extends to a, preferably non-transitory, computer program product comprising computer readable instructions executable when run on a system in accordance with any of the embodiments of the invention to cause a set of one or processors of the system to perform the steps of any of the aspects or embodiments of the method described herein.”
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the invention, to modify Ditty with Schuerman to include using a hash value for verifying assistance data. Doing so provides a more efficient method for ensuring the functional safety of the data, which can be complex [Schuerman, pg. 2, paras 0010-0012], where a hash value provides a reliable, but simple and efficient, in terms of storage and network usage, method for implementation at various functional safety levels [Schuerman, pg. 5, para 0035].
Regarding Claim 13, Ditty discloses: A non-transitory machine-readable storage medium on which is stored a computer program for at least partially automated guidance of a motor vehicle, the computer program, when executed by a computer, causing the computer to perform the following steps: […]; receiving infrastructure assistance data from one of the data processing devices; and determining that the received infrastructure assistance data can be used for at least partially automated guidance of the motor vehicle […]. See again [Ditty, pg. 2 paras 0017-0018 and 0022], which explains that the ADAS systems, such as adaptive cruise control, can utilize wireless data through a vehicle-to-vehicle or infrastructure-to-vehicle system, where [Ditty pgs.7-8, para 0127] the vehicle collects the data using a modem for communicating with the wireless network. Also see again [Ditty, pg. 2, para 0020 and FIGs. 15-19 and pgs. 19-21, paras 0275-0290], which discuss that the vehicle functions system includes the MCU and a non-transitory memory for storing program instructions to perform tasks, where [Ditty, pg. 19, para 0280] the MCU is a microcontroller using processors, and [Ditty, pg. 23, paras 0315-0317] the primary and secondary computers also use processors for performing the requirements of the ADAS systems. Also see again [Ditty, FIGs. 41-42 and pg. 36, paras 0511-0512] which provides a detailed illustration of the architecture for communicating with cloud and determining the control, where the architecture includes memory and processing modules. Finally see again [Ditty, pg. 73, para 0171], which explains that infrastructure data generated from deep learning is compared with vehicle data and [Ditty, pg. 87, paras 0319-0326], which explains that a supervisory MCU receives input commands from a primary and secondary computer to evaluate the inputs to pass the correct input commands to the vehicle for control, where the evaluation includes determining if the inputs are sufficiently aligned or different.
Ditty does not disclose: receiving a respective hash value from at least two data processing devices; […]; [determining…] based on the received hash values.
However, Schuerman teaches: receiving a respective hash value from at least two data processing devices; […]; [determining…] based on the received hash values. See again [Schuerman, pg. 1, para 0009], which explains that map data can be received by a vehicle for use by AD/ADAS applications. Also see again [Schuerman, pgs. 2-3, paras 0013-0016 and 0021], which explains that the map data can be generated by a server and transmitted to a vehicle ECU along with associated security data, where [Schuerman, pg. 5, paras 0035-0036], the associated security data can be in the form of a digital signature, such as a hash value or code, or other error detecting code such as a check sum or parity code. Finally see again [Schuerman, pg. 2, para 0020 and 0084-0085], which explain that the processor and non-transitory memory of the ECU on-board the vehicle is used to extract data.
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the invention, to modify Ditty with Schuerman to include using a hash value for verifying assistance data. Doing so provides a more efficient method for ensuring the functional safety of the data, which can be complex [Schuerman, pg. 2, paras 0010-0012], where a hash value provides a reliable, but simple and efficient, in terms of storage and network usage, method for implementation at various functional safety levels [Schuerman, pg. 5, para 0035].
Allowable Subject Matter
Claims 1-7 and 11 contain allowable subject matter.
Claims 1- would be allowable if rewritten or amended to overcome the rejection(s) under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), 2nd paragraph, set forth in this Office action and where Claims 2 and 4-7 would be allowable by dependency on Claim 1.
Claim 3 is objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims or by dependency on Claim 1, where Claim 1 was rewritten or amended to overcome the rejection(s) under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), 2nd paragraph, as stated above.
As allowable subject matter has been indicated, applicant's reply must either comply with all formal requirements or specifically traverse each requirement not complied with. See 37 CFR 1.111(b) and MPEP § 707.07(a).
The following is a statement of reasons for the indication of allowable subject matter:
The arts of record, especially, Ramamurthy et al., PG Pub US-2023/0316907-A1, and Schuerman et al., PG Pub US-2023/0358568-A1, do not singularly or in combination disclose the method and system for infrastructure-supported assistance of a motor vehicle using at least two data processing devices which receive same surroundings data representing the surroundings of the motor vehicle, calculate infrastructure assistance data for infrastructure-supported assistance of the motor vehicle based on the same received surroundings data and including at least first infrastructure assistance data calculated using a first data processing device and second infrastructure data calculated using a second data processing device, comparing at least the first infrastructure assistance data and the second infrastructure to calculate a comparison result and applying a same hash function to the comparison result to calculate a hash value, and sending the hash value and the first infrastructure assistance data or the second infrastructure assistance data to the motor vehicle, as recited in independent Claims 1 and 11.
The uniqueness of the claimed invention is, as recited in Claims 1 and 11, comparing at least the first infrastructure assistance data and the second infrastructure to calculate a comparison result and applying a same hash function to the comparison result to calculate a hash value.
Ramamurthy being one of the closest prior art discloses a remote station that receives road obstruction information to update and transmit trajectory paths to a vehicle, where the remote station generates paths based on sensor data, compares the paths to paths stored in memory, and updates the paths in memory based on the comparison, and finally, in the comparison of the dynamically generated paths to the baseline historical paths, the remote station determines a statistical significance and either sends the dynamic path data based on a statistical significance or sends the baseline path data based on a statistical insignificance. Schuerman being one of the closest prior arts discloses a technique for generating digital map data and transmitting the digital map data to a vehicle along with an associated hash value for the vehicle to use to verify the integrity of the data. However, there are no teachings in Ramamurthy or Schuerman pertaining to the claimed comparing at least the first infrastructure assistance data and the second infrastructure to calculate a comparison result and applying a same hash function to the comparison result to calculate a hash value.
Therefore, the allowable subject matter found in the claims that has not been found to have been taught or disclosed in the prior art found at this time is all the claimed limitations of independent Claim 1 and 11. All the dependent claims, Claims 2-7, also contain allowable subject matter by virtue of their dependency on their base claim.
Therefore, Claims 2-7 are allowable by dependency on Claim 1.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Reference D, Schvey et al., PG Pub US-2021/0165890-A1, discusses a decentralized computing platform that uses different centers or different on-premise collections of computing hardware for managing data.
Reference N, Ri et al., JP-3904485-B2, discusses a system for developing a vehicle control program including creating unique code from a same source code, where the vehicle control program storage and system can be distributed within a network.
Reference O, Moller, EP-3422267-A1, discusses tracking information in a heterogenous network comprised of a plurality of different types of devices from different manufacturer or component integrators.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ERIN MARIE HARTMANN whose telephone number is (571)272-5309. The examiner can normally be reached M-F 7-5.
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, Kito Robinson can be reached at (571) 270-3921. 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.
/E.M.H./Examiner, Art Unit 3664
/KITO R ROBINSON/Supervisory Patent Examiner, Art Unit 3664
Prosecution Insights