CTNF 19/069,822 CTNF 96343 DETAILED ACTION Notice of Pre-AIA or AIA Status 07-03-aia AIA 15-10-aia The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA. 12-151 AIA 26-51 12-51 Status of Claims This action is in reply to the patent application filed on March 4, 2025. Claims 1-12 are currently pending and have been examined. This action is made Non-FINAL. The examiner would like to note that this application is being handled by examiner Christine Huynh. 07-30-03-h AIA Claim Interpretation 07-30-03 AIA 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. 07-30-05 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 use the word “means” or “step” but are nonetheless not being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph because the claim limitation(s) recite(s) sufficient structure, materials, or acts to entirely perform the recited function. Such claim limitation(s) is/are: “ Electronic control unit ”, “ request reception unit ”, “ data collection unit ”, “ insufficiency detection unit ”, “vehicle communication unit ”, and “ supplement unit ”, which is interpreted in light of the instant specification (“The electronic control unit includes a request reception unit, a data collection unit, an insufficiency detection unit, a vehicle communication unit, and a supplement unit .” [0021], “In detail, the vehicle network system 150 includes the server device 500, multiple electronic control units (hereinafter, ECUs) mounted on each of the first to fifth vehicles 10 to 50” [0023], “As shown in FIG. 3A, the first ECU 100 includes a controller 110, a vehicle I/F 120, a storage 140, and a communication unit 130. As shown in FIG. 3B, the second to sixth ECUs 200 to 600 each include the controller 110, the vehicle I/F 120, and the storage 140.” [0027]), where these units are part of the vehicle ECU. “ Application execution unit ”, which is interpreted in light of the instant specification, (“As shown in FIG. 2, the first to sixth ECUs 100 to 600 collectively have the functions of the data transmission reception unit 11, a data collection distribution unit 12, a data supplement unit 13, a first functional unit 16, a second functional unit 17, a third functional unit 21, a fourth functional unit 22, a first vehicle interior application execution unit 25, a second vehicle interior application execution unit 26, and a third vehicle interior application execution unit 27. As shown in FIG. 1, in the present embodiment, the first ECU 100 has a function of the data transmission reception unit 11.” [0032]), where the unit is part of the vehicle ECU. “ Server communication unit ” which is interpreted in light of the instant specification, (“As shown in FIG. 4, the server device 500 includes a controller 510, a communication unit 520 , and a storage 530. The controller 510 includes a CPU 511, a ROM 512 and a RAM 513. Various functions of the controller 510 are implemented by the CPU 511 executing a program stored in a non-transitory tangible storage medium. In this example, the ROM 512 corresponds to a non-transitory tangible storage medium storing programs. Further, by executing this program, a method corresponding to the program is executed.” [0043-0044]), as part of the vehicle computer. Because this/these claim limitation(s) is/are not being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, it/they is/are not being interpreted to cover only the corresponding structure, material, or acts described in the specification as performing the claimed function, and equivalents thereof. If applicant intends 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 remove the structure, materials, or acts that performs the claimed function; or (2) present a sufficient showing that the claim limitation(s) does/do not recite sufficient structure, materials, or acts to perform the claimed function. Claim Rejections - 35 USC § 101 07-04-01 AIA 07-04 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 1-12 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. 101 Analysis – Step 1 Claim 1 is directed to a data management device for a vehicle, claim 9 is directed to a data management method, claim 10 is directed to a non-transitory tangible storage medium, and claim 11 is directed to a data management system for a vehicle. Therefore, claims 1 and 9-11 are within at least one of the four statutory categories. 101 Analysis – Step 2A, Prong I Regarding Prong I of the Step 2A analysis in the 2019 PEG, the claims are to be analyzed to determine whether they recite subject matter that falls within one of the follow groups of abstract ideas: a) mathematical concepts, b) certain methods of organizing human activity, and/or c) mental processes. Independent claim 1 includes limitations that recite an abstract idea (emphasized below) and will be used as a representative claim for the remainder of the 101 rejection. Claim 1 recites: A data management device for a vehicle, the device comprising: a request reception unit configured to receive a data request from an application execution unit configured to execute an application program; a data collection unit configured to collect vehicle data transmitted from at least one device mounted on the vehicle, and by normalizing the collected vehicle data to represent a same physical quantity in a same unit regardless of a vehicle type and a vehicle model, generate standard data ; an insufficiency detection unit configured to compare the data request received by the request reception unit with the standard data generated by the data collection unit to detect insufficient data that is insufficient from the data request ; and a supplement unit configured to supplement the insufficient data detected by the insufficiency detection unit using different vehicle data that is the standard data of at least one different vehicle different from the vehicle. The examiner submits that the foregoing bolded limitation(s) constitute a “mental process” because under its broadest reasonable interpretation, the claim covers performance of the limitation in the human mind. For example, “ normalizing the collected vehicle data to represent a same physical quantity in a same unit regardless of a vehicle type and a vehicle model, generate standard data …” in the context of this claim encompasses a person (driver) calculating normalized values mathematically from the data given, and “ compare the data request received by the request reception unit with the standard data generated by the data collection unit to detect insufficient data that is insufficient from the data request ” in the context of this claim encompasses a person (driver) looking at data collected and forming a simple judgement between different data. Accordingly, the claim recites at least one abstract idea. 101 Analysis – Step 2A, Prong II Regarding Prong II of the Step 2A analysis in the 2019 PEG, the claims are to be analyzed to determine whether the claim, as a whole, integrates the abstract idea into a practical application. As noted in the 2019 PEG, it must be determined whether any additional elements in the claim beyond the abstract idea integrate the exception into a practical application in a manner that imposes a meaningful limit on the judicial exception. The courts have indicated that additional elements merely using a computer to implement an abstract idea, adding insignificant extra solution activity, or generally linking use of a judicial exception to a particular technological environment or field of use do not integrate a judicial exception into a “practical application.” In the present case, the additional limitations beyond the above-noted abstract idea are as follows (where the underlined portions are the “additional limitations” while the bolded portions continue to represent the “abstract idea”): A data management device for a vehicle, the device comprising: a request reception unit configured to receive a data request from an application execution unit configured to execute an application program ; a data collection unit configured to collect vehicle data transmitted from at least one device mounted on the vehicle , and by normalizing the collected vehicle data to represent a same physical quantity in a same unit regardless of a vehicle type and a vehicle model, generate standard data ; an insufficiency detection unit configured to compare the data request received by the request reception unit with the standard data generated by the data collection unit to detect insufficient data that is insufficient from the data request ; and a supplement unit configured to supplement the insufficient data detected by the insufficiency detection unit using different vehicle data that is the standard data of at least one different vehicle different from the vehicle . For the following reason(s), the examiner submits that the above identified additional limitations do not integrate the above-noted abstract idea into a practical application. Regarding the additional limitations of “ receive a data request …,” “ collect vehicle data …”, and “ supplement the insufficient data …”, the examiner submits that these limitations are insignificant extra-solution activities that merely use a computer (vehicle controller) to perform the process. In particular, the receiving steps from the sensors and from the external source are recited at a high level of generality (i.e. as a general means of gathering vehicle and road condition data for use in the evaluating step), and amounts to mere data gathering, which is a form of insignificant extra-solution activity. Lastly, the vehicle units are recited at a high-level of generality (i.e., as a generic processor performing a generic computer function of ranking information based on a determined amount of use) such that it amounts no more than mere instructions to apply the exception using a generic computer component. Thus, taken alone, the additional elements do not integrate the abstract idea into a practical application. Further, looking at the additional limitation(s) as an ordered combination or as a whole, the limitation(s) add nothing that is not already present when looking at the elements taken individually. For instance, there is no indication that the additional elements, when considered as a whole, reflect an improvement in the functioning of a computer or an improvement to another technology or technical field, apply or use the above-noted judicial exception to effect a particular treatment or prophylaxis for a disease or medical condition, implement/use the above-noted judicial exception with a particular machine or manufacture that is integral to the claim, effect a transformation or reduction of a particular article to a different state or thing, or apply or use the judicial exception in some other meaningful way beyond generally linking the use of the judicial exception to a particular technological environment, such that the claim as a whole is not more than a drafting effort designed to monopolize the exception (MPEP § 2106.05). Accordingly, the additional limitation(s) do/does not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea. 101 Analysis – Step 2B Regarding Step 2B of the Revised Guidance, representative independent claim 1 does not include additional elements (considered both individually and as an ordered combination) that are sufficient to amount to significantly more than the judicial exception for the same reasons to those discussed above with respect to determining that the claim does not integrate the abstract idea into a practical application. As discussed above with respect to integration of the abstract idea into a practical application, the additional element of using a vehicle controller to perform the evaluating… amounts to nothing more than mere instructions to apply the exception using a generic computer component. Mere instructions to apply an exception using a generic computer component cannot provide an inventive concept. And as discussed above, the additional limitations of “ receive a data request …,” “ collect vehicle data …”, and “ supplement the insufficient data …”, the examiner submits that these limitations are insignificant extra-solution activities. Hence, the claim is not patent eligible. Dependent claim(s) 2-8 and 12 do not recite any further limitations that cause the claims to be directed towards statutory subject matter. The claims merely recite: [repeat the judicial exception]. Each of the further limitations expound upon the [repeat judicial exception] and do not recite additional elements integrating the [repeat judicial exception] into a practical application or additional elements that are not well-understood, routine or conventional. Therefore, dependent claims 2-8 and 12 are similarly rejected as being directed towards non-statutory subject matter. Therefore, claim(s) 1-12 is/are ineligible under 35 USC §101. Claim Rejections - 35 USC § 103 07-06 AIA 15-10-15 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. 07-20-aia AIA 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. 07-23-aia AIA 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. 07-20-02-aia AIA This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention. 07-21-aia AIA Claim(s ) 1-12 is /are rejected under 35 U.S.C. 103 as being unpatentable over Re iter et al. (US 20220284746 A1) and Carver et al. (US 20200334762 A1). Wi th respect to claims 1 and 9-10 , Reiter teaches: a request reception unit configured to receive a data request from an application execution unit configured to execute an application program ; (“receiving request data in the vehicle that describe at least one data record missing in an existing field data record.” [0002], “In a step 100, request data that describe at least one data record missing in an existing field data record are received in the vehicle. For example, request data may be transmitted to the vehicle (and received therefrom) at certain intervals or triggered by certain events.” [0022]), where a data request is received. a data collection unit configured to collect vehicle data transmitted from at least one device mounted on the vehicle , (“In addition, sensor data for the vehicle are continuously recorded while the vehicle is in operation and then stored in a short-term memory 110. The sensor data, for instance, may be present in the form of time series data. For example, the sensor data can include camera data (e.g., in the visible or infrared spectral range), lidar sensor data, radar sensor data, temperature sensor data and/or ultrasound sensor data. Alternatively or additionally, the sensor data may describe position data (such as GPS data), for instance, or vehicle data describing an operating state of the vehicle (e.g., steering angle, rotational speed, operating mode, loading, etc.).” [0028]), where vehicle data is collected from the vehicle sensors. Reiter does not teach, but Carver teaches: by normalizing the collected vehicle data to represent a same physical quantity in a same unit regardless of a vehicle type and a vehicle model, generate standard data ; (“Using these various sensors, including their multiple GNSS sensors, weighted based on differential readings from peered devices, creates a filter for vehicle dynamics which can be used to cross correlate asynchronous location reports. The resultant driving data not only helps identify a driver associated with driving data but also provides a smoothing function for the normalization of the data.” [0036], “The deep learning method, or mining method, described herein begins with a fundamentally different method of data search. Rather than a forward convolution scheme, the method searches backwards from the point of an exceedance for similar data patterns to correlate and then normalizes these patterns for vehicles of, for example, equivalent weight, driving environment and regional profile to derive weights to apply to each of the three indices (DSI, VRI and CLI) at the vehicle level.” [0038]), where the collected vehicle data can be normalized. It would have been obvious to one of ordinary skill in the art before the effective filling date of the instant application to have combined Reiter’s data management with Carver’s normalized data in order to (“(1) maximize the accuracy of onboard hardware sensor data collection, (2) deliver onboard usable peer-based analytics and (3) analyze data from different vehicles having dissimilar sensors. In summary, an innovation of an embodiment described herein includes the asynchronous data delivery and collection methods for the same driver in different vehicles to achieve a normalized result.” See Carver [0027]). Reiter further teaches: an insufficiency detection unit configured to compare the data request received by the request reception unit with the standard data generated by the data collection unit to detect insufficient data that is insufficient from the data request ; (“If the acknowledge signal is generated automatically (or at least partly automatically), then the method may include a check whether certain recorded sensor data correspond to the missing data record based on the received request data, and the generation of the acknowledge signal in the event that the check reveals that the certain recorded sensor data correspond to the missing data record.” [0031], “For example, the check may include an automatic comparison of the request data with the recorded sensor data. As described earlier, the request data may assume any form that makes it possible to identify sensor data for a missing data record (e.g., for a certain operating scenario). For that reason, the step of checking may also be carried out in different ways. It is merely required that it can be determined that sensor data corresponding to the missing data record (e.g., that a certain operating scenario has occurred) have been recorded for the vehicle at a certain moment.” [0032]), where the data request is compared with the standard data to determine what data is missing to determine the insufficient data. a supplement unit configured to supplement the insufficient data detected by the insufficiency detection unit using different vehicle data that is the standard data of at least one different vehicle different from the vehicle ; (“In these examples, the same request data are able to be made available to multiple vehicles. In other examples, at least partly different request data can be made available to different vehicles of the multiple vehicles. The different request data may be randomly distributed or distributed according to a predefined pattern (e.g., under consideration of available information about the individual vehicles such as typical driving routes, vehicle type and so on).” [0045], “The field data record may include field data collected by vehicles in the past (and in some instances also data from simulators and/or synthetic field data).” [0050], “In a further step, request data are able to be generated 330 (the content and the structure of the request data were described above) based on the detected missing data records. For instance, it may result that data records for certain operating scenarios (such as for certain route segments and/or for certain driving maneuvers and/or certain environment situations) are missing in the existing field data record. The request data will then be generated in such a way that a comparison with currently recorded sensor data is able to be carried out during the operation of the vehicle (that is to say, computationally intense steps are performed while the request data is generated so that a check is able to be performed in the vehicle with limited resources and/or an available time and/or by the user).” [0054]), which shows that the insufficient data can be supplemented using different vehicle data. With respect to claim 11 , Reiter teaches: an electronic control unit mounted on a vehicle ; (“The incorporation of the sensor data in short-term memory 209 is able to be controlled by a control unit 211 of vehicle 201.” [0070]). a server device includes : a server storage configured to store standard data obtained by normalizing a plurality of vehicle data received from each vehicle to represent a same physical quantity in a same unit regardless of a vehicle type and a vehicle model ; (“Database 217 is able to be coupled with a computer system 221 in which the described steps of checking which data records are missing in the field data record and/or the generating of the request data are carried out.” [0085]). Reiter does not teach normalizing data, but Carver teaches, (“Using these various sensors, including their multiple GNSS sensors, weighted based on differential readings from peered devices, creates a filter for vehicle dynamics which can be used to cross correlate asynchronous location reports. The resultant driving data not only helps identify a driver associated with driving data but also provides a smoothing function for the normalization of the data.” [0036], “The deep learning method, or mining method, described herein begins with a fundamentally different method of data search. Rather than a forward convolution scheme, the method searches backwards from the point of an exceedance for similar data patterns to correlate and then normalizes these patterns for vehicles of, for example, equivalent weight, driving environment and regional profile to derive weights to apply to each of the three indices (DSI, VRI and CLI) at the vehicle level.” [0038]), where the collected vehicle data can be normalized. a server controller configured to select the standard data from the server storage ; (“As described earlier, the vehicle or vehicles store(s) (and possibly transmit(s)) sensor data (continuously or at certain intervals) if it has been detected that they correspond to a missing data record described in the request data. These sensor data are able to be updated in the existing field data record (in some examples after one or more processing step(s)). This makes it possible to close gaps in the field data record.” [0058]), which shows that sensor data has been detected to correspond to a missing data record can be chosen to update the existing field data record. a server communication unit configured to communicate with the vehicle and transmit the standard data selected by the server controller to the vehicle , (“As described earlier, the vehicle or vehicles store(s) (and possibly transmit(s)) sensor data (continuously or at certain intervals) if it has been detected that they correspond to a missing data record described in the request data. These sensor data are able to be updated in the existing field data record (in some examples after one or more processing step(s)). This makes it possible to close gaps in the field data record.” [0058]), where other vehicle data can be transmitted. a request reception unit configured to receive a data request from an application execution unit configured to execute an application program ; (“receiving request data in the vehicle that describe at least one data record missing in an existing field data record.” [0002], “In a step 100, request data that describe at least one data record missing in an existing field data record are received in the vehicle. For example, request data may be transmitted to the vehicle (and received therefrom) at certain intervals or triggered by certain events.” [0022]), where a data request is received. a data collection unit configured to collect vehicle data transmitted from at least one device mounted on the vehicle , (“In addition, sensor data for the vehicle are continuously recorded while the vehicle is in operation and then stored in a short-term memory 110. The sensor data, for instance, may be present in the form of time series data. For example, the sensor data can include camera data (e.g., in the visible or infrared spectral range), lidar sensor data, radar sensor data, temperature sensor data and/or ultrasound sensor data. Alternatively or additionally, the sensor data may describe position data (such as GPS data), for instance, or vehicle data describing an operating state of the vehicle (e.g., steering angle, rotational speed, operating mode, loading, etc.).” [0028]), where vehicle data is collected from the vehicle sensors. Reiter does not teach, but Carver teaches: by normalizing the collected vehicle data to represent the same physical quantity in the same unit regardless of the vehicle type and the vehicle model, generate standard data ; (“Using these various sensors, including their multiple GNSS sensors, weighted based on differential readings from peered devices, creates a filter for vehicle dynamics which can be used to cross correlate asynchronous location reports. The resultant driving data not only helps identify a driver associated with driving data but also provides a smoothing function for the normalization of the data.” [0036], “The deep learning method, or mining method, described herein begins with a fundamentally different method of data search. Rather than a forward convolution scheme, the method searches backwards from the point of an exceedance for similar data patterns to correlate and then normalizes these patterns for vehicles of, for example, equivalent weight, driving environment and regional profile to derive weights to apply to each of the three indices (DSI, VRI and CLI) at the vehicle level.” [0038]), where the collected vehicle data can be normalized. It would have been obvious to one of ordinary skill in the art before the effective filling date of the instant application to have combined Reiter’s data management with Carver’s normalized data in order to (“(1) maximize the accuracy of onboard hardware sensor data collection, (2) deliver onboard usable peer-based analytics and (3) analyze data from different vehicles having dissimilar sensors. In summary, an innovation of an embodiment described herein includes the asynchronous data delivery and collection methods for the same driver in different vehicles to achieve a normalized result.” See Carver [0027]). Reiter further teaches: an insufficiency detection unit configured to compare the data request received by the request reception unit with the standard data generated by the data collection unit to detect insufficient data that is insufficient from the data request ; (“If the acknowledge signal is generated automatically (or at least partly automatically), then the method may include a check whether certain recorded sensor data correspond to the missing data record based on the received request data, and the generation of the acknowledge signal in the event that the check reveals that the certain recorded sensor data correspond to the missing data record.” [0031], “For example, the check may include an automatic comparison of the request data with the recorded sensor data. As described earlier, the request data may assume any form that makes it possible to identify sensor data for a missing data record (e.g., for a certain operating scenario). For that reason, the step of checking may also be carried out in different ways. It is merely required that it can be determined that sensor data corresponding to the missing data record (e.g., that a certain operating scenario has occurred) have been recorded for the vehicle at a certain moment.” [0032]), where the data request is compared with the standard data to determine what data is missing to determine the insufficient data. a vehicle communication unit configured to receive different vehicle data that is the standard data of at least one different vehicle different from the vehicle, and is transmitted from the server communication unit ; (“In the latter paragraphs, the techniques of the present disclosure were described based on a single vehicle. The techniques of the present disclosure are carried out using multiple vehicles in some examples (e.g., a fleet of 100 or more or 1000 or more). For instance, request data can be sent to multiple vehicles. In addition or as an alternative, sensor data from multiple vehicles are able to be stored (and further processed). The sensor data from the multiple vehicles can be jointly used for closing gaps in field data (that is to say, be fused into its data record).” [0044], “As described earlier, the vehicle or vehicles store(s) (and possibly transmit(s)) sensor data (continuously or at certain intervals) if it has been detected that they correspond to a missing data record described in the request data. These sensor data are able to be updated in the existing field data record (in some examples after one or more processing step(s)). This makes it possible to close gaps in the field data record.” [0058]), different vehicle data can be stored and transmitted. a supplement unit configured to supplement the insufficient data detected by the insufficiency detection unit using the different vehicle data received by the vehicle communication unit ; (“In these examples, the same request data are able to be made available to multiple vehicles. In other examples, at least partly different request data can be made available to different vehicles of the multiple vehicles. The different request data may be randomly distributed or distributed according to a predefined pattern (e.g., under consideration of available information about the individual vehicles such as typical driving routes, vehicle type and so on).” [0045], “The field data record may include field data collected by vehicles in the past (and in some instances also data from simulators and/or synthetic field data).” [0050], “In a further step, request data are able to be generated 330 (the content and the structure of the request data were described above) based on the detected missing data records. For instance, it may result that data records for certain operating scenarios (such as for certain route segments and/or for certain driving maneuvers and/or certain environment situations) are missing in the existing field data record. The request data will then be generated in such a way that a comparison with currently recorded sensor data is able to be carried out during the operation of the vehicle (that is to say, computationally intense steps are performed while the request data is generated so that a check is able to be performed in the vehicle with limited resources and/or an available time and/or by the user).” [0054]), which shows that the insufficient data can be supplemented using different vehicle data. With respect to claim 2 , Reiter in combination with Carver, as shown in the rejection above, discloses the limitations of claim 1. The combination of Reiter and Carver teaches data management of claim 1. Reiter further teaches: the different vehicle includes a plurality of different vehicles , (“the techniques of the present disclosure were described based on a single vehicle. The techniques of the present disclosure are carried out using multiple vehicles in some examples (e.g., a fleet of 100 or more or 1000 or more). For instance, request data can be sent to multiple vehicles. In addition or as an alternative, sensor data from multiple vehicles are able to be stored (and further processed). The sensor data from the multiple vehicles can be jointly used for closing gaps in field data (that is to say, be fused into its data record).” [0044]), where the collected data from a different vehicle can include a plurality of vehicles. the supplement unit is configured to supplement the insufficient data with the different vehicle data of, among the plurality of different vehicles, a different vehicle that has an environment closest to an environment of the vehicle ; (“In these examples, the same request data are able to be made available to multiple vehicles. In other examples, at least partly different request data can be made available to different vehicles of the multiple vehicles. The different request data may be randomly distributed or distributed according to a predefined pattern (e.g., under consideration of available information about the individual vehicles such as typical driving routes, vehicle type and so on) .” [0045], “In a further step, request data are able to be generated 330 (the content and the structure of the request data were described above) based on the detected missing data records. For instance, it may result that data records for certain operating scenarios (such as for certain route segments and/or for certain driving maneuvers and/or certain environment situations) are missing in the existing field data record. The request data will then be generated in such a way that a comparison with currently recorded sensor data is able to be carried out during the operation of the vehicle (that is to say, computationally intense steps are performed while the request data is generated so that a check is able to be performed in the vehicle with limited resources and/or an available time and/or by the user).” [0054]), where the insufficient data can be supplemented from a different vehicle that has an environment similar to an environment of the vehicle. With respect to claim 3 , Reiter in combination with Carver, as shown in the rejection above, discloses the limitations of claim 1. The combination of Reiter and Carver teaches data management of claim 1. Reiter further teaches: the different vehicle includes a plurality of different vehicles , (“the techniques of the present disclosure were described based on a single vehicle. The techniques of the present disclosure are carried out using multiple vehicles in some examples (e.g., a fleet of 100 or more or 1000 or more). For instance, request data can be sent to multiple vehicles. In addition or as an alternative, sensor data from multiple vehicles are able to be stored (and further processed). The sensor data from the multiple vehicles can be jointly used for closing gaps in field data (that is to say, be fused into its data record).” [0044]), where the collected data from a different vehicle can include a plurality of vehicles. Reiter does not teach, but Carver teaches: the supplement unit is configured to supplement the insufficient data with a statistical value calculated by statistically processing the different vehicle data of the plurality of different vehicles ; (“Using these various sensors, including their multiple GNSS sensors, weighted based on differential readings from peered devices, creates a filter for vehicle dynamics which can be used to cross correlate asynchronous location reports. The resultant driving data not only helps identify a driver associated with driving data but also provides a smoothing function for the normalization of the data.” [0036], “The deep learning method, or mining method, described herein begins with a fundamentally different method of data search. Rather than a forward convolution scheme, the method searches backwards from the point of an exceedance for similar data patterns to correlate and then normalizes these patterns for vehicles of, for example, equivalent weight, driving environment and regional profile to derive weights to apply to each of the three indices (DSI, VRI and CLI) at the vehicle level.” [0038], “The machine learning engine for the scoring database 107 performs the machine learning and then classifies, clusters, ranks, and/or predicts data states for the scoring result from given input data. Classification of driving variables varies by sampling frequency of the source data and therefore must be performed using a plurality of statistical classification techniques” [0082]), where the collected vehicle data, which can be from a plurality of different vehicles, can be statistically processed by normalization. It would have been obvious to one of ordinary skill in the art before the effective filling date of the instant application to have combined Reiter’s data management with Carver’s normalized data in order to (“(1) maximize the accuracy of onboard hardware sensor data collection, (2) deliver onboard usable peer-based analytics and (3) analyze data from different vehicles having dissimilar sensors. In summary, an innovation of an embodiment described herein includes the asynchronous data delivery and collection methods for the same driver in different vehicles to achieve a normalized result.” See Carver [0027]). With respect to claim 4 , Reiter in combination with Carver, as shown in the rejection above, discloses the limitations of claim 1. The combination of Reiter and Carver teaches data management of claim 1. Reiter further teaches: the supplement unit is configured to acquire the different vehicle data from the at least one different vehicle or a database of a server device via network communication ; (“An existing field data record is able to be stored in a database 400 (here, the term ‘database’ also includes situations where the field data record is made up of different partial data records that are stored at different locations and/or stored using different schemata). The field data record may include field data collected by vehicles in the past (and in some instances also data from simulators and/or synthetic field data).” [0049-0050]), “The request data are finally transmitted 340 to a vehicle or multiple vehicles (via a suitable network link). The transmittal may take place repeatedly (e.g., as soon as new request data are available).” [0055]), where different vehicle data can be acquired using a database of a server device via network communication. With respect to claim 5 , Reiter in combination with Carver, as shown in the rejection above, discloses the limitations of claim 1. The combination of Reiter and Carver teaches data management of claim 1. Reiter does not teach, but Carver teaches: the supplement unit is configured to acquire the different vehicle data from the at least one different vehicle via vehicle-to-vehicle communication ; (“The system 100 gathers data for use by a Driver Scoring Processor/Database 107 in calculating a Driver Score to be included in the Driver Scoring Processor/Database. The Driver Scoring Processor/Database 107, which may be referred to herein simply as database 107, may be functionally equivalent or at least similar to server 1070 or computer system 1065 discussed with reference to FIG. 10. The driving data 105 is forwarded to the Driver scoring database 107 along with environmental data 104 and location specific data 106 via communication interfaces/devices, such as a modem or other conventional network-connection device, as generally indicated in FIG. 1 by arrows… The location specific data 106 (from one or more GNSS sensor, or other radio telemetry system) may include geometry of terrain, speed limit of the road, vehicle to infrastructure (“V2I”) information, and vehicle to vehicle (“V2V”) data exchanges.” [0037]), where different vehicle data can be acquired via vehicle-to-vehicle communication. It would have been obvious to one of ordinary skill in the art before the effective filling date of the instant application to have combined Reiter’s data management with Carver’s vehicle-to-vehicle data in order to (“(1) maximize the accuracy of onboard hardware sensor data collection, (2) deliver onboard usable peer-based analytics and (3) analyze data from different vehicles having dissimilar sensors. In summary, an innovation of an embodiment described herein includes the asynchronous data delivery and collection methods for the same driver in different vehicles to achieve a normalized result.” See Carver [0027]), to collect more different vehicle data. With respect to claim 6 , Reiter in combination with Carver, as shown in the rejection above, discloses the limitations of claim 1. The combination of Reiter and Carver teaches data management of claim 1. Reiter further teaches: the supplement unit is further configured to acquire input data that is input in response to a manual operation by a user, and supplement the insufficient data with the acquired input data ; (“further information pertaining to the missing data record is able to be provided to the user. A brief text and/or visual description of the missing data record (e.g., the operating situation) may be given, for example. This text and/or visual description can be included in the request data or be generated therefrom. In one illustrative example, the description may read: ‘Object X encountered!’. The conveying of information may allow the user to check whether the current sensor data do indeed correspond to a missing data record (for instance so that erroneously classified sensor data are able to be discarded). In other cases—as described above—information regarding the missing data record from the request data may be conveyed to the user for a check whether the recorded sensor data correspond to a missing data record.” [0041]), where input data that is input in response to a manual operation by a user can be used to supplement insufficient data. With respect to claim 7 , Reiter in combination with Carver, as shown in the rejection above, discloses the limitations of claim 1. The combination of Reiter and Carver teaches data management of claim 1. Reiter does not teach, but Carver teaches: a storage configured to store a supplement policy in which a supplement means for supplementing the insufficient data is described , (“FIG. 1 illustrates a system that may collect data used to assign and validate driver or vehicle safety scores. The system 100 of FIG. 1 includes onboard devices configured to provide telemetric data such as telematics service providers (“TSPs”) 103, that collect driving data 105 from individual vehicles or fleets of vehicles.” [0036], “The system 100 gathers data for use by a Driver Scoring Processor/Database 107 in calculating a Driver Score to be included in the Driver Scoring Processor/Database. The Driver Scoring Processor/Database 107, which may be referred to herein simply as database 107, may be functionally equivalent or at least similar to server 1070 or computer system 1065 discussed with reference to FIG. 10. The driving data 105 is forwarded to the Driver scoring database 107 along with environmental data 104 and location specific data 106 via communication interfaces/devices, such as a modem or other conventional network-connection device, as generally indicated in FIG. 1 by arrows.” [0037]), which shows the process for collecting vehicle data and storing vehicle data, which can be used for supplementing insufficient data. the supplement unit is configured to supplement the insufficient data based on the supplement policy stored in the storage ; (“Rather than a forward convolution scheme, the method searches backwards from the point of an exceedance for similar data patterns to correlate and then normalizes these patterns for vehicles of, for example, equivalent weight, driving environment and regional profile to derive weights to apply to each of the three indices (DSI, VRI and CLI) at the vehicle level. On roads where there is insufficient data on collisions, speeding and incidents to provide a common reference for the CLI, a convolution scheme based on historically similar peer vehicles (same weight class and territory). These indices are then summed for a common group of trips, or period of time using a time weighted average (proportional to exposure) to produce the fleet level score stored, along with the individual scores, by VIN number in the results database 101, again using a temporal database structure for storing and summing these elements, to bias the results to the most recent events, or time series data because it has been shown that recent events are much more predictive of risk factors than historical patterns when the pattern sequence is changing.” [0038]), which shows a way of selecting and calculating supplement data when there is a plurality of candidates that can be used to supplement the insufficient data, including vehicle type, trips, environment, or other normalized data. It would have been obvious to one of ordinary skill in the art before the effective filling date of the instant application to have combined Reiter’s data management with Carver’s data collection and communication in order to (“(1) maximize the accuracy of onboard hardware sensor data collection, (2) deliver onboard usable peer-based analytics and (3) analyze data from different vehicles having dissimilar sensors. In summary, an innovation of an embodiment described herein includes the asynchronous data delivery and collection methods for the same driver in different vehicles to achieve a normalized result.” See Carver [0027]), to collect different vehicle data for different situations. With respect to claim 8 , Reiter in combination with Carver, as shown in the rejection above, discloses the limitations of claim 7. The combination of Reiter and Carver teaches data management of claim 7. Reiter does not teach, but Carver teaches, the supplement policy specifies : (i) a method for selecting and calculating supplement data when there are a plurality of candidates for the supplement data that supplements the insufficient data , (“Rather than a forward convolution scheme, the method searches backwards from the point of an exceedance for similar data patterns to correlate and then normalizes these patterns for vehicles of, for example, equivalent weight, driving environment and regional profile to derive weights to apply to each of the three indices (DSI, VRI and CLI) at the vehicle level. On roads where there is insufficient data on collisions, speeding and incidents to provide a common reference for the CLI, a convolution scheme based on historically similar peer vehicles (same weight class and territory). These indices are then summed for a common group of trips, or period of time using a time weighted average (proportional to exposure) to produce the fleet level score stored, along with the individual scores, by VIN number in the results database 101, again using a temporal database structure for storing and summing these elements, to bias the results to the most recent events, or time series data because it has been shown that recent events are much more predictive of risk factors than historical patterns when the pattern sequence is changing.” [0038]), which shows a way of selecting and calculating supplement data when there is a plurality of candidates that can be used to supplement the insufficient data, including vehicle type, trips, environment, or other normalized data. (ii) a means for acquiring the different vehicle data when communication is possible , (“The system 100 gathers data for use by a Driver Scoring Processor/Database 107 in calculating a Driver Score to be included in the Driver Scoring Processor/Database. The Driver Scoring Processor/Database 107, which may be referred to herein simply as database 107, may be functionally equivalent or at least similar to server 1070 or computer system 1065 discussed with reference to FIG. 10… The location specific data 106 (from one or more GNSS sensor, or other radio telemetry system) may include geometry of terrain, speed limit of the road, vehicle to infrastructure (“V2I”) information, and vehicle to vehicle (“V2V”) data exchanges.” [0037], which shows a plurality of means for acquiring the different vehicle data when communication is possible. (iii) a substitute means when the communication is not possible ; (“The resulting data set can also be utilized to infer data that is not in the database, or cannot be accessed for a particular trip segment. For example, the application may not have access to location data for a mobile platform during a trip. However, the application could request the machine-learning service to predict the traffic density based on location. The machine-learning service need only provide the predictions, not the locations, to the driver safety index creation algorithm. As such, the machine-learning service can encapsulate the use of sensitive data.” [0072]), which shows that vehicle data can be inferred when communication is not possible. It would have been obvious to one of ordinary skill in the art before the effective filling date of the instant application to have combined Reiter’s data management with Carver’s data collection and communication in order to (“(1) maximize the accuracy of onboard hardware sensor data collection, (2) deliver onboard usable peer-based analytics and (3) analyze data from different vehicles having dissimilar sensors. In summary, an innovation of an embodiment described herein includes the asynchronous data delivery and collection methods for the same driver in different vehicles to achieve a normalized result.” See Carver [0027]), to collect different vehicle data for different situations. With respect to claim 12 , Reiter in combination with Carver, as shown in the rejection above, discloses the limitations of claim 11. The combination of Reiter and Carver teaches data management of claim 11. Reiter further teaches: the server controller is configured to select, from the standard data stored in the server storage, standard data obtained by normalizing data of, among a plurality of different vehicles, a different vehicle that has an environment closest to an environment of the vehicle , (“In these examples, the same request data are able to be made available to multiple vehicles. In other examples, at least partly different request data can be made available to different vehicles of the multiple vehicles. The different request data may be randomly distributed or distributed according to a predefined pattern (e.g., under consideration of available information about the individual vehicles such as typical driving routes, vehicle type and so on) .” [0045], “In a further step, request data are able to be generated 330 (the content and the structure of the request data were described above) based on the detected missing data records. For instance, it may result that data records for certain operating scenarios (such as for certain route segments and/or for certain driving maneuvers and/or certain environment situations) are missing in the existing field data record. The request data will then be generated in such a way that a comparison with currently recorded sensor data is able to be carried out during the operation of the vehicle (that is to say, computationally intense steps are performed while the request data is generated so that a check is able to be performed in the vehicle with limited resources and/or an available time and/or by the user).” [0054]), where the insufficient data can be supplemented from a different vehicle that has an environment similar to an environment of the vehicle. Reiter does not teach normalizing data, but Carver teaches, (“Using these various sensors, including their multiple GNSS sensors, weighted based on differential readings from peered devices, creates a filter for vehicle dynamics which can be used to cross correlate asynchronous location reports. The resultant driving data not only helps identify a driver associated with driving data but also provides a smoothing function for the normalization of the data.” [0036], “The deep learning method, or mining method, described herein begins with a fundamentally different method of data search. Rather than a forward convolution scheme, the method searches backwards from the point of an exceedance for similar data patterns to correlate and then normalizes these patterns for vehicles of, for example, equivalent weight, driving environment and regional profile to derive weights to apply to each of the three indices (DSI, VRI and CLI) at the vehicle level.” [0038]), where the collected vehicle data can be normalized. It would have been obvious to one of ordinary skill in the art before the effective filling date of the instant application to have combined Reiter’s data management with Carver’s normalized data in order to (“(1) maximize the accuracy of onboard hardware sensor data collection, (2) deliver onboard usable peer-based analytics and (3) analyze data from different vehicles having dissimilar sensors. In summary, an innovation of an embodiment described herein includes the asynchronous data delivery and collection methods for the same driver in different vehicles to achieve a normalized result.” See Carver [0027]). the server communication unit is configured to transmit the standard data selected by the server controller to the vehicle ; (“As described earlier, the vehicle or vehicles store(s) (and possibly transmit(s)) sensor data (continuously or at certain intervals) if it has been detected that they correspond to a missing data record described in the request data. These sensor data are able to be updated in the existing field data record (in some examples after one or more processing step(s)). This makes it possible to close gaps in the field data record.” [0058]), where other vehicle data can be transmitted. Conclusion 07-96 The prior art made of record and not relied upon is considered pertinent to applicants disclosure. Cao et al. (US 20190222982 A1) is pertinent because (“Using V2V communication as an example, as shown in FIG. 1, V2V data packets for communication between a vehicle A and a vehicle B include data packets of different service types, such as a cooperative awareness message (CAM) type, a decentralized environmental notification message (DENM) type, and a basic safety message (BSM) type. Specifically, a V2X data packet of the CAM type includes basic travel information of a vehicle, such as a current location, a current speed, and a current direction of the vehicle, and a V2X data packet of the DENM type includes information about some emergency states currently triggered by the vehicle, such as emergency braking”), which pertains to transmitting vehicle data using vehicle to vehicle communication. Any inquiry concerning this communication or earlier communications from the examiner should be directed to Christine N Huynh whose telephone number is (571)272-9980. The examiner can normally be reached Monday - Friday 8 am - 4 pm. Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice. If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Aniss Chad can be reached at (571)270-3832. 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. /CHRISTINE NGUYEN HUYNH/Examiner, Art Unit 3662 /ANISS CHAD/Supervisory Patent Examiner, Art Unit 3662 Application/Control Number: 19/069,822 Page 2 Art Unit: 3662 Application/Control Number: 19/069,822 Page 3 Art Unit: 3662 Application/Control Number: 19/069,822 Page 4 Art Unit: 3662 Application/Control Number: 19/069,822 Page 5 Art Unit: 3662 Application/Control Number: 19/069,822 Page 6 Art Unit: 3662 Application/Control Number: 19/069,822 Page 7 Art Unit: 3662 Application/Control Number: 19/069,822 Page 8 Art Unit: 3662 Application/Control Number: 19/069,822 Page 9 Art Unit: 3662 Application/Control Number: 19/069,822 Page 10 Art Unit: 3662 Application/Control Number: 19/069,822 Page 11 Art Unit: 3662 Application/Control Number: 19/069,822 Page 12 Art Unit: 3662 Application/Control Number: 19/069,822 Page 13 Art Unit: 3662 Application/Control Number: 19/069,822 Page 14 Art Unit: 3662 Application/Control Number: 19/069,822 Page 15 Art Unit: 3662 Application/Control Number: 19/069,822 Page 16 Art Unit: 3662 Application/Control Number: 19/069,822 Page 17 Art Unit: 3662 Application/Control Number: 19/069,822 Page 18 Art Unit: 3662 Application/Control Number: 19/069,822 Page 19 Art Unit: 3662 Application/Control Number: 19/069,822 Page 20 Art Unit: 3662 Application/Control Number: 19/069,822 Page 21 Art Unit: 3662 Application/Control Number: 19/069,822 Page 22 Art Unit: 3662 Application/Control Number: 19/069,822 Page 23 Art Unit: 3662 Application/Control Number: 19/069,822 Page 24 Art Unit: 3662 Application/Control Number: 19/069,822 Page 25 Art Unit: 3662 Application/Control Number: 19/069,822 Page 26 Art Unit: 3662 Application/Control Number: 19/069,822 Page 27 Art Unit: 3662 Application/Control Number: 19/069,822 Page 28 Art Unit: 3662 Application/Control Number: 19/069,822 Page 29 Art Unit: 3662 Application/Control Number: 19/069,822 Page 30 Art Unit: 3662 Application/Control Number: 19/069,822 Page 31 Art Unit: 3662
Prosecution Insights