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 .
Priority
The present application’s status as a continuation of U.S. Application No. 17/548,392 (filing date 12/10/2021) is acknowledged. The present application’s claim to priority with respect to Provisional U.S. Application No. 63/283,964 (filing date 11/29/2021) is acknowledged.
The later-filed application must be an application for a patent for an invention which is also disclosed in the prior application (the parent or original nonprovisional application or provisional application). The disclosure of the invention in the parent application and in the later-filed application must be sufficient to comply with the requirements of 35 U.S.C. 112(a) or the first paragraph of pre-AIA 35 U.S.C. 112, except for the best mode requirement. See Transco Products, Inc. v. Performance Contracting, Inc., 38 F.3d 551, 32 USPQ2d 1077 (Fed. Cir. 1994).
The disclosure of the prior-filed application, Application No. 17/548,392, fails to provide adequate support or enablement in the manner provided by 35 U.S.C. 112(a) or pre-AIA 35 U.S.C. 112, first paragraph for one or more claims of this application. Claims 22, 27, and 35 are each directed towards receiving, using a developer interface of the digital twin service, the first request; and providing, using the developer interface, a visualization of the digital twin and the decoded telemetry data. However, Application No. 17/548,392 makes no reference to the term “developer”, let alone a “developer interface”; the present application suffers from the same deficiency. While paragraph [0062] of Application No. 17/548,392 does discuss a management console with an analytics interface, this disclosure is largely directed towards the assignment of permissions and roles and merely provides “roles that enable development of new vehicle information extraction configurations” rather than the claimed features of claims 22, 27, and 35. It is not disclosed that the users provided with “roles that enable development” are users of the disclosed management console; in other words, management console 410 is not described as being a developer interface. Therefore, Application No. 17/548,392, fails to provide adequate support or enablement in the manner provided by 35 U.S.C. 112(a) or pre-AIA 35 U.S.C. 112, first paragraph for claims 22, 27, and 35 of the present application. Accordingly, claims 22, 27, and 35 are not entitled to the benefit of the prior application.
Information Disclosure Statement
The information disclosure statements (IDS) submitted on 11/07/2024, 12/12/2024, and 8/29/2025 are in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statements are being considered by the examiner. The Examiner notes that copies of foreign and NPL references are found in the prosecution history of parent U.S. Application No. 17/548,392.
Claim Objections
Claim 34 is objected to because of the following informalities:
In claim 34, the comma in “providing, an updated digital twin comprising decoded telemetry data…” should be removed.
Appropriate correction is required.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims 22, 27, and 35 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention.
Regarding claims 22, 27, and 35, these claims are each directed towards receiving, using a developer interface of the digital twin service, the first request; and providing, using the developer interface, a visualization of the digital twin and the decoded telemetry data. However, the written description fails to sufficiently describe such a developer interface. While paragraph [0062] of the written description does discuss a management console with an analytics interface, this disclosure is largely directed towards the assignment of permissions and roles and merely provides “roles that enable development of new vehicle information extraction configurations” rather than the claimed features of claims 22, 27, and 35. It is not disclosed that the users provided with “roles that enable development” are users of the disclosed management console; in other words, management console 410 is not described as being a developer interface. Therefore, claims 22, 27, and 35 fail to comply with the written description requirement.
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 22, 25, 27, 31, 35, and 39 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Regarding claims 22, 27, and 35, these claims are each directed towards receiving, using a developer interface of the digital twin service, the first request; and providing, using the developer interface, a visualization of the digital twin and the decoded telemetry data. As discussed above with respect to 35 USC 112(a), claims 22, 27, and 35 fail to comply with the written description requirement, as the written description fails to sufficiently describe such a developer interface. While paragraph [0062] of the written description does discuss a management console with an analytics interface, this disclosure is largely directed towards the assignment of permissions and roles and merely provides “roles that enable development of new vehicle information extraction configurations” rather than the claimed features of claims 22, 27, and 35. It is not disclosed that the users provided with “roles that enable development” are users of the disclosed management console; in other words, management console 410 is not described as being a developer interface. Therefore, the limitations of claims 22, 27, and 35 are rendered indefinite, as it is not possible to determine the scope of the limitations associated with the claimed developer interface.
Regarding claims 25, 31, and 39, each of these claims recite “the entity”. However, for each of claims 25, 31, and 39, antecedent basis with respect to “the entity” is indefinite. Claims 25, 31, and 39 each recite “telemetry data ingested from the respective entities”, and antecedent basis exists for “entities represented in the model” in each of independent claims 21, 26, and 34 (upon which claims 25, 31, and 39 respectively depend). Claims 25, 31, and 39 are therefore rendered indefinite, as it is unclear which entity of the plural respective entities is intended to be the singularly claimed “the entity”. For the purposes of this examination, “the entity” is being interpreted under broadest reasonable interpretation as one of the entities of the respective entities.
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 1-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
Claims 1-20 are directed to creating a model for a digital twin, and providing an updated digital twin. Decision-making processes fall within a subject matter grouping of abstract ideas which the Courts have considered ineligible (mental processes or concepts performed in the human mind: i.e., an observation, evaluation, judgement, or opinion). The claims do not integrate the abstract idea into a practical application, and do not include additional elements that provide an inventive concept (are sufficient to amount to significantly more than the abstract idea).
Under step 1 of the Alice/Mayo framework, it must be considered whether the claims are directed to one of the four statutory classes of invention. In the instant case, claims 21-25 recite an apparatus with one or more computing devices. Claims 26-33 recite a method with at least one step. Claims 34-40 recite one or more computer-readable storage media that are defined by the claim as non-transitory. Therefore, the claims are each directed to one of the four statutory categories of invention (apparatus, process, manufacture).
Under step 2 of the Alice/Mayo framework, it must be considered whether the claims are “directed to” an abstract idea. That is, whether the claims recite an abstract idea and fail to integrate the abstract idea into a practical application.
Regarding independent claim 21, the claim sets forth the abstract idea of creating a model for a digital twin, and providing an updated digital twin in the following limitations:
create, according to a first request… a model for a digital twin
ingest, from entities represented in the model, telemetry data,
wherein the telemetry data is decoded according to respective signal decoding rules for the entities,
and provide an updated digital twin comprising decoded telemetry data…
and wherein the updated digital twin comprises the data decoded from the heterogeneous signal formats using the respective signal decoding rules.
The above-recited limitations establish the use of generic computing devices (i.e., one or more computing devices) to perform a decision-making process. This arrangement amounts to using a computer as a tool to perform an abstract idea. This concept has been considered ineligible as a mental process by the Courts (see MPEP 2106.05(f)). A human being is capable of creating and updating, mentally or with the assistance of pen and paper, the broadly-claimed model for a digital twin. A human being is likewise capable of decoding telemetry data according to respective signal decoding rules (e.g., by applying signal decoding rules to the telemetry data mentally or with the assistance of pen and paper).
Claim 21 does recite additional elements:
A system for implementing a digital twin service
one or more computing devices configured to:
a first request received from a customer of the digital twin service,
and wherein the entities included in the digital twin use heterogeneous signal formats for a same property of the model;
… decoded telemetry data obtained from the entities,
wherein the decoded telemetry data is for the same property of the model,
These additional elements merely amount to reciting the words “apply it” (or an equivalent) with the judicial exception, or merely including instructions to implement an abstract idea on a computer, or merely using a computer as a tool to perform an abstract idea. The specification sets forth the general-purpose nature of the computing technology. Paragraph [0114] recites: “computing device 1500 may be a uniprocessor system including one processor or a multiprocessor system including several processors 1510A-1510N (e.g., two, four, eight, or another suitable number). Processors 1510A-1510N may include any suitable processors capable of executing instructions.” That is, the technology used to implement the invention is not specific or integral to the claim.
Accordingly, the Examiner concludes that the claim fails to integrate the abstract idea into a practical application, and is therefore “directed to” the abstract idea.
Under step 2B of the Alice/Mayo framework, it must finally be considered whether the claim includes any additional element or combination of elements that provide an inventive concept (i.e., whether the additional element or elements amount to significantly more than the abstract idea). In the instant case, the additional elements, considered both individually and as an ordered combination, merely generally link the use of the judicial exception to a particular technological environment and append well-understood, routine, conventional activities previously known to the industry, specified at a high level of generality, to the judicial exception (see MPEP 2106.05(f)). Receiving a fist request from a customer of the digital twin service and using heterogeneous signal formats amounts to a manner of receiving or transmitting data over a network, which has been repeatedly considered well-understood, routine, and conventional activity by the Courts (see MPEP 2106.05(d)). Accordingly, the Examiner asserts that the limitations do not provide an inventive concept, and the claim is ineligible for patent.
Independent claims 26 and 34 are parallel in scope to claim 21 and are ineligible for similar reasons.
Regarding claim 22, which sets forth:
the one or more computing devices are further configured to: receive, using a developer interface of the digital twin service, the first request;
and provide, using the developer interface, a visualization of the digital twin and the decoded telemetry data.
Such a recitation merely embellishes upon the additional elements of receiving or transmitting data over a network by further requiring receiving a first request using a developer interface, and providing, using the developer interface, a visualization of the digital twin and the decoded telemetry data. This arrangement amounts to a manner of receiving or transmitting data over a network, which has been repeatedly considered well-understood, routine, and conventional activity by the Courts (see MPEP 2106.05(d)). As such, it does not integrate the abstract idea into a practical application, and does not provide an inventive concept. Accordingly, the claim does not confer eligibility on the claimed invention and is ineligible for similar reasons to claim 21.
Claims 27 and 35 are parallel in scope to claim 22 and are ineligible for similar reasons.
Regarding claim 23, which sets forth:
the entities comprise a plurality of vehicles of a fleet,
and wherein at least a portion of the plurality of vehicles of the fleet use heterogeneous vehicle signal formats for the same property of the model.
Such a recitation merely embellishes upon the additional elements of “the entities” by further specifying that the entities comprise a plurality of vehicles in a fleet, wherein at least a portion of the plurality of vehicles of the fleet use heterogeneous vehicle signal formats for the same property of the model. The use of heterogeneous vehicle signal formats amounts to a manner of receiving or transmitting data over a network, which has been repeatedly considered well-understood, routine, and conventional activity by the Courts (see MPEP 2106.05(d)). As such, it does not integrate the abstract idea into a practical application, and does not provide an inventive concept. Accordingly, the claim does not confer eligibility on the claimed invention and is ineligible for similar reasons to claim 21.
Claims 28 and 36 are parallel in scope to claim 23 and are ineligible for similar reasons.
Regarding claim 24, which sets forth:
the one or more computing devices are further configured to: receive information describing signal properties of respective ones of a plurality of sensors from manufacturers or suppliers for the plurality of vehicles,
wherein the plurality of vehicles comprises vehicles having different in- vehicle communication signal configurations;
and create a signal catalog that includes instructions for converting the signal properties into a unified signal representation that represents a given property of the model.
Such a recitation merely embellishes upon the additional elements of receiving or transmitting data over a network by further requiring receiving information describing signal properties from manufacturers or suppliers for the plurality of vehicles. This arrangement amounts to a manner of receiving or transmitting data over a network, which has been repeatedly considered well-understood, routine, and conventional activity by the Courts (see MPEP 2106.05(d)). Further, a human being is capable of creating the claimed signal catalog mentally or with the assistance of pen and paper. As such, it does not integrate the abstract idea into a practical application, and does not provide an inventive concept. Accordingly, the claim does not confer eligibility on the claimed invention and is ineligible for similar reasons to claim 21.
Claims 29 and 37 are parallel in scope to claim 24 and are ineligible for similar reasons.
Regarding claim 25, which sets forth:
the one or more computing devices are further configured to: decode the telemetry data ingested from the respective entities using the respective signal decoding rules,
wherein the telemetry data ingested is decoded from a binary format used for signal representations at the entity into one or more sensor signal values used to populate one or more properties of the model.
Such a recitation merely embellishes upon the abstract idea of decoding the telemetry data using the respective signal decoding rules, and further requires that the telemetry data is decoded from a binary format into one or more sensor signal values. A human being is capable of decoding telemetry data using signal decoding rules mentally or with the assistance of pen and paper. As such, it does not integrate the abstract idea into a practical application, and does not provide an inventive concept. Accordingly, the claim does not confer eligibility on the claimed invention and is ineligible for similar reasons to claim 21.
Claims 31 and 39 are parallel in scope to claim 25 and are ineligible for similar reasons.
Regarding claim 30, which sets forth:
the telemetry data comprises one or more of: camera data; LiDar data; electronic control unit (ECU) data; or location sensor data.
Such a recitation merely embellishes upon the abstract idea of decoding the telemetry data by further specifying what the telemetry data comprises. A human being is capable of decoding telemetry data using signal decoding rules mentally or with the assistance of pen and paper. As such, it does not integrate the abstract idea into a practical application, and does not provide an inventive concept. Accordingly, the claim does not confer eligibility on the claimed invention and is ineligible for similar reasons to claim 21.
Claim 38 is parallel in scope to claim 30 and is ineligible for similar reasons.
Regarding claim 32, which sets forth:
sending to the entities the respective signal decoding rules for decoding the telemetry data for the entities that corresponds to properties included in the digital twin,
wherein the signal decoding rules enable decoding of in-vehicle communication signals comprising the telemetry data.
Such a recitation merely embellishes upon the abstract idea of decoding the telemetry data by further specifying what the telemetry data comprises. Further, the sending of respective signal decoding rules amounts to a manner of receiving or transmitting data over a network, which has been repeatedly considered well-understood, routine, and conventional activity by the Courts (see MPEP 2106.05(d)). As such, it does not integrate the abstract idea into a practical application, and does not provide an inventive concept. Accordingly, the claim does not confer eligibility on the claimed invention and is ineligible for similar reasons to claim 21.
Claim 40 is parallel in scope to claim 32 and is ineligible for similar reasons.
Regarding claim 33, which sets forth:
properties for the model comprise one or more static properties associated with a particular vehicle including one or more of: vehicle brand, vehicle body type, and vehicle engine model.
Such a recitation merely embellishes upon the abstract idea of creating a model of a digital twin by specifying what the properties for the model comprise. A human being is capable of considering/including one or more of vehicle brand, vehicle body type, and vehicle engine model when creating a model for a digital twin. As such, it does not integrate the abstract idea into a practical application, and does not provide an inventive concept. Accordingly, the claim does not confer eligibility on the claimed invention and is ineligible for similar reasons to claim 21.
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.
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.
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.
Claim(s) 21, 23, 26, 28, 30, 34, 36, and 38 is/are rejected under 35 U.S.C. 103 as being unpatentable over Jiang et al. (US 2019/0382003 A1), hereinafter Jiang, in view of Ponda et al. (US 2019/0206156 A1), hereinafter Ponda.
Regarding claim 21, Jiang teaches a system for implementing a digital twin service, comprising:
one or more computing devices configured to:
Jiang teaches ([0029]): "Described herein are embodiments of a digital behavioral twin system and a twin client. The digital behavioral twin system includes software that generates a digital behavioral twin. The digital behavioral twin system is installed in a cloud server. The twin client is installed in an onboard vehicle computer of an ego vehicle."
create, according to a first request received from a customer of the digital twin service, a model for a digital twin;
Jiang teaches ([0089]): "In some embodiments, the twin client 196 aggregates instances of sensor data 191 and ADAS data 192. The twin client 196 generates a wireless message that includes the sensor data 191 and the ADAS data 192 as a payload for the wireless message. The twin client 196 causes the communication unit 145 of the ego vehicle 123 to transmit the wireless message to the digital twin server 107 via the network. In this way, the digital behavioral twin system 199 of the digital twin server 107 has access to the sensor data 191 and the ADAS data 192 of the ego vehicle 123." Jiang further teaches ([0090]): "In some embodiments, the digital behavioral twin system 199 includes code and routines that are operable, when executed by the processor 125 of the digital twin server 107, to use the sensor data 191 and the ADAS data 192 of a particular vehicle (e.g., the ego vehicle 123) to generate a digital behavioral twin for that particular vehicle."
ingest, from entities represented in the model, telemetry data,
Jiang teaches ([0090]): "In some embodiments, the digital behavioral twin system 199 includes code and routines that are operable, when executed by the processor 125 of the digital twin server 107, to use the sensor data 191 and the ADAS data 192 of a particular vehicle (e.g., the ego vehicle 123) to generate a digital behavioral twin for that particular vehicle... Twin data is digital data that describes a digital behavioral twin for a particular vehicle, i.e., the digital behavioral twin for a particular driver of that particular vehicle. For example, ego twin data 175 is digital data that describes the digital behavioral twin for the ego vehicle 123 (i.e., the digital behavioral twin of the ego driver of the ego vehicle 123). First twin data 171 is digital data that describes the digital behavioral twin for the first remote vehicle 124A. Second twin data 172 is digital data that describes the digital behavioral twin for the second remote vehicle 124B. Third twin data 173 is digital data that describes the digital behavioral twin for the third remote vehicle 124C. Nth twin data 175 is digital data that describes the digital behavioral twin for the Nth remote vehicle 124N." Jiang further teaches ([0091]): "In some embodiments, the digital behavioral twin system 199 includes code and routines that are operable to transmit one or more of the ego twin data 175, the first twin data 171, the second twin data 172, the third twin data 173, and the Nth twin data 175 to the ego vehicle 123. For example, the twin client 196 of the ego vehicle 123 transmits the sensor data 191 and the ADAS data 192 for the ego vehicle 123 to the digital twin server 107. The digital behavioral twin system 199 determines that the remote vehicles 124 are geographically proximate to the ego vehicle 123 based on GPS information included in the sensor data 191 and then provides the ego twin data 175, the first twin data 171, the second twin data 172, the third twin data 173, and the Nth twin data 175 to the ego vehicle 123 via the network 105. In this way, the twin client 196 has access to the twin data for the ego vehicle 123 as well as the remote vehicles 124." Jiang even further teaches ([0092]): "The set of twin data 181 includes digital data that describes the digital behavioral twins of the ego vehicle 123 and the remote vehicles 124. The digital behavioral twin system 199 determines the twin data based on the sensor data 191 and the ADAS data 192 for each of the ego vehicle 123 and the remote vehicles 124."
and provide an updated digital twin comprising... telemetry data obtained from the entities,
Jiang teaches ([0089]): "In some embodiments, the twin client 196 repeats this process of reporting the sensor data 191 and the ADAS data 192 to the digital behavioral twin system 199 on a periodic basis. The remote vehicles 124 also include a twin client 196 that reports sensor data 191 and ADAS data 192 of the remote vehicles 124 to the digital twin server 107. In this way, the digital behavioral twin system 199 of the digital twin server 107 has access to sensor data 191 and ADAS data 192 of the remote vehicles 124 as well as sensor data 191 and ADAS data 192 of the ego vehicle 123." Jiang further teaches ([0090]): "In some embodiments, the digital behavioral twin system 199 includes code and routines that are operable, when executed by the processor 125 of the digital twin server 107, to use the sensor data 191 and the ADAS data 192 of a particular vehicle (e.g., the ego vehicle 123) to generate a digital behavioral twin for that particular vehicle."
wherein the... telemetry data is for the same property of the model,
Jiang teaches ([0089]): "In some embodiments, the twin client 196 repeats this process of reporting the sensor data 191 and the ADAS data 192 to the digital behavioral twin system 199 on a periodic basis. The remote vehicles 124 also include a twin client 196 that reports sensor data 191 and ADAS data 192 of the remote vehicles 124 to the digital twin server 107. In this way, the digital behavioral twin system 199 of the digital twin server 107 has access to sensor data 191 and ADAS data 192 of the remote vehicles 124 as well as sensor data 191 and ADAS data 192 of the ego vehicle 123."
However, while Jiang does teach encryption of telemetry data (see at least [0050]), Jiang does not outright teach that the telemetry data is decoded according to respective signal decoding rules for the entities, wherein the entities included in the digital twin use heterogeneous signal formats for a same property of the model, and wherein the updated digital twin comprises the data decoded from the heterogeneous signal formats using the respective signal decoding rules. Ponda teaches vehicle telemetry, comprising:
wherein the telemetry data is decoded according to respective signal decoding rules for the entities,
Ponda teaches ([0037]): "As shown in FIG. 2, the aerial vehicle 102 includes multiple sensors 128a through 128d (collectively, 128) that are configured to provide to the computing device 104 various types of sensor data (also referred to herein as telemetry data) during flight by way of the communication link 108." Ponda further teaches ([0042]): "At block 404, telemetry data is received from the sensors 128 by way of the communication link 108." Ponda even further teaches ([0050]): "If two aerial vehicles 102 have different sensors, a different data format, and/or other differences, the estimation graph can account for such variants, such as by using different estimator modules 202, reading different input channels, and/or the like, and can provide a normalized data output. This can be beneficial in facilitating operation of a heterogeneous fleet of aerial vehicles 102 by way of a single fleet control system, despite some of the aerial vehicles 102 of the fleet being older and/or different with respect to one another." The Examiner has interpreted the normalization of data formats based upon variations in the vehicles as decoding according to respective signal decoding rules for the entities.
and wherein the entities included in the digital twin use heterogeneous signal formats for a same property of the model;
Ponda teaches ([0037]): "As shown in FIG. 2, the aerial vehicle 102 includes multiple sensors 128a through 128d (collectively, 128) that are configured to provide to the computing device 104 various types of sensor data (also referred to herein as telemetry data) during flight by way of the communication link 108." Ponda further teaches ([0042]): "At block 404, telemetry data is received from the sensors 128 by way of the communication link 108." Ponda even further teaches ([0050]): "If two aerial vehicles 102 have different sensors, a different data format, and/or other differences, the estimation graph can account for such variants, such as by using different estimator modules 202, reading different input channels, and/or the like, and can provide a normalized data output. This can be beneficial in facilitating operation of a heterogeneous fleet of aerial vehicles 102 by way of a single fleet control system, despite some of the aerial vehicles 102 of the fleet being older and/or different with respect to one another."
and wherein the updated digital twin comprises the data decoded from the heterogeneous signal formats using the respective signal decoding rules.
Ponda teaches ([0037]): "As shown in FIG. 2, the aerial vehicle 102 includes multiple sensors 128a through 128d (collectively, 128) that are configured to provide to the computing device 104 various types of sensor data (also referred to herein as telemetry data) during flight by way of the communication link 108." Ponda further teaches ([0042]): "At block 404, telemetry data is received from the sensors 128 by way of the communication link 108." Ponda even further teaches ([0050]): "If two aerial vehicles 102 have different sensors, a different data format, and/or other differences, the estimation graph can account for such variants, such as by using different estimator modules 202, reading different input channels, and/or the like, and can provide a normalized data output. This can be beneficial in facilitating operation of a heterogeneous fleet of aerial vehicles 102 by way of a single fleet control system, despite some of the aerial vehicles 102 of the fleet being older and/or different with respect to one another." Ponda is modified such that the normalization of data formats is applied to the periodic reporting of the sensor data 191 and ADAS data 192, which are used in the creation of the updated digital twin.
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Jiang to incorporate the teachings of Ponda to provide that the telemetry data is decoded according to respective signal decoding rules for the entities, wherein the entities included in the digital twin use heterogeneous signal formats for a same property of the model, and wherein the updated digital twin comprises the data decoded from the heterogeneous signal formats using the respective signal decoding rules. Jiang and Ponda are each directed towards similar pursuits in the field of vehicle fleet monitoring, and each are concerned with telemetry data obtained from vehicles. Accordingly, one of ordinary skill in the art would find it advantageous to augment the digital twin modeling of Jiang with the telemetry data decoding of Ponda, as incorporating the decoding of Ponda beneficially enables normalization of data output, even if vehicles of the fleet have different sensors and/or a different data format, as recognized by Ponda (see at least [0050]).
Regarding claim 23, Jiang and Ponda teach the aforementioned limitations of claim 21. Jiang further teaches:
the entities comprise a plurality of vehicles of a fleet,
Jiang teaches ([0007]): "The cloud server is operable to provide digital data, referred to as “twin data,” describing the digital behavioral twins to vehicles that use a digital twin service that is provided by the digital behavioral twin system. Vehicles that use the digital twin service include a small software client stored in their electronic control unit, or some other onboard vehicle computer, referred to as a “twin client.”" The Examiner has interpreted the vehicles that use the digital twin service as a fleet of vehicles associated with the digital behavioral twin system.
However, Jiang does not outright teach that at least a portion of the plurality of vehicles of the fleet use heterogeneous vehicle signal formats for the same property of the model. Ponda further teaches:
and wherein at least a portion of the plurality of vehicles of the fleet use heterogeneous vehicle signal formats for the same property of the model.
Ponda teaches ([0037]): "As shown in FIG. 2, the aerial vehicle 102 includes multiple sensors 128a through 128d (collectively, 128) that are configured to provide to the computing device 104 various types of sensor data (also referred to herein as telemetry data) during flight by way of the communication link 108." Ponda further teaches ([0042]): "At block 404, telemetry data is received from the sensors 128 by way of the communication link 108." Ponda even further teaches ([0050]): "If two aerial vehicles 102 have different sensors, a different data format, and/or other differences, the estimation graph can account for such variants, such as by using different estimator modules 202, reading different input channels, and/or the like, and can provide a normalized data output. This can be beneficial in facilitating operation of a heterogeneous fleet of aerial vehicles 102 by way of a single fleet control system, despite some of the aerial vehicles 102 of the fleet being older and/or different with respect to one another."
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Jiang and Ponda to further incorporate the teachings of Ponda to provide that at least a portion of the plurality of vehicles of the fleet use heterogeneous vehicle signal formats for the same property of the model. Jiang and Ponda are each directed towards similar pursuits in the field of vehicle fleet monitoring, and each are concerned with telemetry data obtained from vehicles. Accordingly, one of ordinary skill in the art would find it advantageous to augment the digital twin modeling of Jiang with the telemetry data decoding of Ponda, as incorporating the decoding of Ponda beneficially enables normalization of data output, even if vehicles of the fleet have different sensors and/or a different data format, as recognized by Ponda (see at least [0050]).
Regarding claim 26, Jiang teaches a method, comprising:
creating, using a digital twin service, according to a first request received from a customer of the digital twin service, a model for a digital twin;
Jiang teaches ([0089]): "In some embodiments, the twin client 196 aggregates instances of sensor data 191 and ADAS data 192. The twin client 196 generates a wireless message that includes the sensor data 191 and the ADAS data 192 as a payload for the wireless message. The twin client 196 causes the communication unit 145 of the ego vehicle 123 to transmit the wireless message to the digital twin server 107 via the network. In this way, the digital behavioral twin system 199 of the digital twin server 107 has access to the sensor data 191 and the ADAS data 192 of the ego vehicle 123." Jiang further teaches ([0090]): "In some embodiments, the digital behavioral twin system 199 includes code and routines that are operable, when executed by the processor 125 of the digital twin server 107, to use the sensor data 191 and the ADAS data 192 of a particular vehicle (e.g., the ego vehicle 123) to generate a digital behavioral twin for that particular vehicle."
ingesting, from entities represented in the model, telemetry data,
Jiang teaches ([0090]): "In some embodiments, the digital behavioral twin system 199 includes code and routines that are operable, when executed by the processor 125 of the digital twin server 107, to use the sensor data 191 and the ADAS data 192 of a particular vehicle (e.g., the ego vehicle 123) to generate a digital behavioral twin for that particular vehicle... Twin data is digital data that describes a digital behavioral twin for a particular vehicle, i.e., the digital behavioral twin for a particular driver of that particular vehicle. For example, ego twin data 175 is digital data that describes the digital behavioral twin for the ego vehicle 123 (i.e., the digital behavioral twin of the ego driver of the ego vehicle 123). First twin data 171 is digital data that describes the digital behavioral twin for the first remote vehicle 124A. Second twin data 172 is digital data that describes the digital behavioral twin for the second remote vehicle 124B. Third twin data 173 is digital data that describes the digital behavioral twin for the third remote vehicle 124C. Nth twin data 175 is digital data that describes the digital behavioral twin for the Nth remote vehicle 124N." Jiang further teaches ([0091]): "In some embodiments, the digital behavioral twin system 199 includes code and routines that are operable to transmit one or more of the ego twin data 175, the first twin data 171, the second twin data 172, the third twin data 173, and the Nth twin data 175 to the ego vehicle 123. For example, the twin client 196 of the ego vehicle 123 transmits the sensor data 191 and the ADAS data 192 for the ego vehicle 123 to the digital twin server 107. The digital behavioral twin system 199 determines that the remote vehicles 124 are geographically proximate to the ego vehicle 123 based on GPS information included in the sensor data 191 and then provides the ego twin data 175, the first twin data 171, the second twin data 172, the third twin data 173, and the Nth twin data 175 to the ego vehicle 123 via the network 105. In this way, the twin client 196 has access to the twin data for the ego vehicle 123 as well as the remote vehicles 124." Jiang even further teaches ([0092]): "The set of twin data 181 includes digital data that describes the digital behavioral twins of the ego vehicle 123 and the remote vehicles 124. The digital behavioral twin system 199 determines the twin data based on the sensor data 191 and the ADAS data 192 for each of the ego vehicle 123 and the remote vehicles 124."
and providing, an updated digital twin comprising... telemetry data obtained from the entities,
Jiang teaches ([0089]): "In some embodiments, the twin client 196 repeats this process of reporting the sensor data 191 and the ADAS data 192 to the digital behavioral twin system 199 on a periodic basis. The remote vehicles 124 also include a twin client 196 that reports sensor data 191 and ADAS data 192 of the remote vehicles 124 to the digital twin server 107. In this way, the digital behavioral twin system 199 of the digital twin server 107 has access to sensor data 191 and ADAS data 192 of the remote vehicles 124 as well as sensor data 191 and ADAS data 192 of the ego vehicle 123." Jiang further teaches ([0090]): "In some embodiments, the digital behavioral twin system 199 includes code and routines that are operable, when executed by the processor 125 of the digital twin server 107, to use the sensor data 191 and the ADAS data 192 of a particular vehicle (e.g., the ego vehicle 123) to generate a digital behavioral twin for that particular vehicle."
wherein the... telemetry data is for the same property of the model,
Jiang teaches ([0089]): "In some embodiments, the twin client 196 repeats this process of reporting the sensor data 191 and the ADAS data 192 to the digital behavioral twin system 199 on a periodic basis. The remote vehicles 124 also include a twin client 196 that reports sensor data 191 and ADAS data 192 of the remote vehicles 124 to the digital twin server 107. In this way, the digital behavioral twin system 199 of the digital twin server 107 has access to sensor data 191 and ADAS data 192 of the remote vehicles 124 as well as sensor data 191 and ADAS data 192 of the ego vehicle 123."
However, while Jiang does teach encryption of telemetry data (see at least [0050]), Jiang does not outright teach that the telemetry data is decoded according to respective signal decoding rules for the entities, wherein the entities included in the digital twin use heterogeneous signal formats for a same property of the model, and wherein the updated digital twin comprises the data decoded from the heterogeneous signal formats using the respective signal decoding rules. Ponda teaches vehicle telemetry, comprising:
wherein the telemetry data is decoded according to respective signal decoding rules for the entities,
Ponda teaches ([0037]): "As shown in FIG. 2, the aerial vehicle 102 includes multiple sensors 128a through 128d (collectively, 128) that are configured to provide to the computing device 104 various types of sensor data (also referred to herein as telemetry data) during flight by way of the communication link 108." Ponda further teaches ([0042]): "At block 404, telemetry data is received from the sensors 128 by way of the communication link 108." Ponda even further teaches ([0050]): "If two aerial vehicles 102 have different sensors, a different data format, and/or other differences, the estimation graph can account for such variants, such as by using different estimator modules 202, reading different input channels, and/or the like, and can provide a normalized data output. This can be beneficial in facilitating operation of a heterogeneous fleet of aerial vehicles 102 by way of a single fleet control system, despite some of the aerial vehicles 102 of the fleet being older and/or different with respect to one another." The Examiner has interpreted the normalization of data formats based upon variations in the vehicles as decoding according to respective signal decoding rules for the entities.
and wherein the entities included in the digital twin use heterogeneous signal formats for a same property of the model;
Ponda teaches ([0037]): "As shown in FIG. 2, the aerial vehicle 102 includes multiple sensors 128a through 128d (collectively, 128) that are configured to provide to the computing device 104 various types of sensor data (also referred to herein as telemetry data) during flight by way of the communication link 108." Ponda further teaches ([0042]): "At block 404, telemetry data is received from the sensors 128 by way of the communication link 108." Ponda even further teaches ([0050]): "If two aerial vehicles 102 have different sensors, a different data format, and/or other differences, the estimation graph can account for such variants, such as by using different estimator modules 202, reading different input channels, and/or the like, and can provide a normalized data output. This can be beneficial in facilitating operation of a heterogeneous fleet of aerial vehicles 102 by way of a single fleet control system, despite some of the aerial vehicles 102 of the fleet being older and/or different with respect to one another."
and wherein the updated digital twin comprises the data decoded from the heterogeneous signal formats using the respective signal decoding rules.
Ponda teaches ([0037]): "As shown in FIG. 2, the aerial vehicle 102 includes multiple sensors 128a through 128d (collectively, 128) that are configured to provide to the computing device 104 various types of sensor data (also referred to herein as telemetry data) during flight by way of the communication link 108." Ponda further teaches ([0042]): "At block 404, telemetry data is received from the sensors 128 by way of the communication link 108." Ponda even further teaches ([0050]): "If two aerial vehicles 102 have different sensors, a different data format, and/or other differences, the estimation graph can account for such variants, such as by using different estimator modules 202, reading different input channels, and/or the like, and can provide a normalized data output. This can be beneficial in facilitating operation of a heterogeneous fleet of aerial vehicles 102 by way of a single fleet control system, despite some of the aerial vehicles 102 of the fleet being older and/or different with respect to one another." Ponda is modified such that the normalization of data formats is applied to the periodic reporting of the sensor data 191 and ADAS data 192, which are used in the creation of the updated digital twin.
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Jiang to incorporate the teachings of Ponda to provide that the telemetry data is decoded according to respective signal decoding rules for the entities, wherein the entities included in the digital twin use heterogeneous signal formats for a same property of the model, and wherein the updated digital twin comprises the data decoded from the heterogeneous signal formats using the respective signal decoding rules. Jiang and Ponda are each directed towards similar pursuits in the field of vehicle fleet monitoring, and each are concerned with telemetry data obtained from vehicles. Accordingly, one of ordinary skill in the art would find it advantageous to augment the digital twin modeling of Jiang with the telemetry data decoding of Ponda, as incorporating the decoding of Ponda beneficially enables normalization of data output, even if vehicles of the fleet have different sensors and/or a different data format, as recognized by Ponda (see at least [0050]).
Regarding claim 28, Jiang and Ponda teach the aforementioned limitations of claim 26. Jiang further teaches:
the entities comprise a plurality of vehicles of a fleet,
Jiang teaches ([0007]): "The cloud server is operable to provide digital data, referred to as “twin data,” describing the digital behavioral twins to vehicles that use a digital twin service that is provided by the digital behavioral twin system. Vehicles that use the digital twin service include a small software client stored in their electronic control unit, or some other onboard vehicle computer, referred to as a “twin client.”" The Examiner has interpreted the vehicles that use the digital twin service as a fleet of vehicles associated with the digital behavioral twin system.
However, Jiang does not outright teach that at least a portion of the plurality of vehicles of the fleet use heterogeneous vehicle signal formats for the same property of the model. Ponda further teaches:
and wherein at least a portion of the plurality of vehicles of the fleet use heterogeneous vehicle signal formats for the same property of the model.
Ponda teaches ([0037]): "As shown in FIG. 2, the aerial vehicle 102 includes multiple sensors 128a through 128d (collectively, 128) that are configured to provide to the computing device 104 various types of sensor data (also referred to herein as telemetry data) during flight by way of the communication link 108." Ponda further teaches ([0042]): "At block 404, telemetry data is received from the sensors 128 by way of the communication link 108." Ponda even further teaches ([0050]): "If two aerial vehicles 102 have different sensors, a different data format, and/or other differences, the estimation graph can account for such variants, such as by using different estimator modules 202, reading different input channels, and/or the like, and can provide a normalized data output. This can be beneficial in facilitating operation of a heterogeneous fleet of aerial vehicles 102 by way of a single fleet control system, despite some of the aerial vehicles 102 of the fleet being older and/or different with respect to one another."
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Jiang and Ponda to further incorporate the teachings of Ponda to provide that at least a portion of the plurality of vehicles of the fleet use heterogeneous vehicle signal formats for the same property of the model. Jiang and Ponda are each directed towards similar pursuits in the field of vehicle fleet monitoring, and each are concerned with telemetry data obtained from vehicles. Accordingly, one of ordinary skill in the art would find it advantageous to augment the digital twin modeling of Jiang with the telemetry data decoding of Ponda, as incorporating the decoding of Ponda beneficially enables normalization of data output, even if vehicles of the fleet have different sensors and/or a different data format, as recognized by Ponda (see at least [0050]).
Regarding claim 30. Jiang and Ponda teach the aforementioned limitations of claim 28. Jiang further teaches:
the telemetry data comprises one or more of: camera data; LiDar data; electronic control unit (ECU) data; or location sensor data.
Jiang teaches ([0079]): "The sensor data 191 describes the measurements of the roadway environment that are recorded by the onboard vehicle sensors that are included in the sensor set 195. In some embodiments, the sensor set 195 of the ego vehicle 123 includes one or more of the following onboard vehicle sensors: ... a camera (e.g., one or more of an internal camera and an external camera); ... a LIDAR sensor..." Jiang further teaches ([0089]): "In some embodiments, the twin client 196 repeats this process of reporting the sensor data 191 and the ADAS data 192 to the digital behavioral twin system 199 on a periodic basis. The remote vehicles 124 also include a twin client 196 that reports sensor data 191 and ADAS data 192 of the remote vehicles 124 to the digital twin server 107. In this way, the digital behavioral twin system 199 of the digital twin server 107 has access to sensor data 191 and ADAS data 192 of the remote vehicles 124 as well as sensor data 191 and ADAS data 192 of the ego vehicle 123." Jiang even further teaches ([0091]): "The digital behavioral twin system 199 determines that the remote vehicles 124 are geographically proximate to the ego vehicle 123 based on GPS information included in the sensor data 191..."
Regarding claim 34, Jiang teaches one or more non-transitory, computer-readable storage media (“a non-transitory memory”, [0013]), storing program instructions (“computer code”, [0013]) that when executed on or across one or more processors (“the processor”, [0013]) cause the one or more processors to implement a digital twin service that implements:
creating, according to a first request received from a customer of the digital twin service, a model for a digital twin;
Jiang teaches ([0089]): "In some embodiments, the twin client 196 aggregates instances of sensor data 191 and ADAS data 192. The twin client 196 generates a wireless message that includes the sensor data 191 and the ADAS data 192 as a payload for the wireless message. The twin client 196 causes the communication unit 145 of the ego vehicle 123 to transmit the wireless message to the digital twin server 107 via the network. In this way, the digital behavioral twin system 199 of the digital twin server 107 has access to the sensor data 191 and the ADAS data 192 of the ego vehicle 123." Jiang further teaches ([0090]): "In some embodiments, the digital behavioral twin system 199 includes code and routines that are operable, when executed by the processor 125 of the digital twin server 107, to use the sensor data 191 and the ADAS data 192 of a particular vehicle (e.g., the ego vehicle 123) to generate a digital behavioral twin for that particular vehicle."
ingesting, from entities represented in the model, telemetry data,
Jiang teaches ([0090]): "In some embodiments, the digital behavioral twin system 199 includes code and routines that are operable, when executed by the processor 125 of the digital twin server 107, to use the sensor data 191 and the ADAS data 192 of a particular vehicle (e.g., the ego vehicle 123) to generate a digital behavioral twin for that particular vehicle... Twin data is digital data that describes a digital behavioral twin for a particular vehicle, i.e., the digital behavioral twin for a particular driver of that particular vehicle. For example, ego twin data 175 is digital data that describes the digital behavioral twin for the ego vehicle 123 (i.e., the digital behavioral twin of the ego driver of the ego vehicle 123). First twin data 171 is digital data that describes the digital behavioral twin for the first remote vehicle 124A. Second twin data 172 is digital data that describes the digital behavioral twin for the second remote vehicle 124B. Third twin data 173 is digital data that describes the digital behavioral twin for the third remote vehicle 124C. Nth twin data 175 is digital data that describes the digital behavioral twin for the Nth remote vehicle 124N." Jiang further teaches ([0091]): "In some embodiments, the digital behavioral twin system 199 includes code and routines that are operable to transmit one or more of the ego twin data 175, the first twin data 171, the second twin data 172, the third twin data 173, and the Nth twin data 175 to the ego vehicle 123. For example, the twin client 196 of the ego vehicle 123 transmits the sensor data 191 and the ADAS data 192 for the ego vehicle 123 to the digital twin server 107. The digital behavioral twin system 199 determines that the remote vehicles 124 are geographically proximate to the ego vehicle 123 based on GPS information included in the sensor data 191 and then provides the ego twin data 175, the first twin data 171, the second twin data 172, the third twin data 173, and the Nth twin data 175 to the ego vehicle 123 via the network 105. In this way, the twin client 196 has access to the twin data for the ego vehicle 123 as well as the remote vehicles 124." Jiang even further teaches ([0092]): "The set of twin data 181 includes digital data that describes the digital behavioral twins of the ego vehicle 123 and the remote vehicles 124. The digital behavioral twin system 199 determines the twin data based on the sensor data 191 and the ADAS data 192 for each of the ego vehicle 123 and the remote vehicles 124."
and providing, an updated digital twin comprising... telemetry data obtained from the entities,
Jiang teaches ([0089]): "In some embodiments, the twin client 196 repeats this process of reporting the sensor data 191 and the ADAS data 192 to the digital behavioral twin system 199 on a periodic basis. The remote vehicles 124 also include a twin client 196 that reports sensor data 191 and ADAS data 192 of the remote vehicles 124 to the digital twin server 107. In this way, the digital behavioral twin system 199 of the digital twin server 107 has access to sensor data 191 and ADAS data 192 of the remote vehicles 124 as well as sensor data 191 and ADAS data 192 of the ego vehicle 123." Jiang further teaches ([0090]): "In some embodiments, the digital behavioral twin system 199 includes code and routines that are operable, when executed by the processor 125 of the digital twin server 107, to use the sensor data 191 and the ADAS data 192 of a particular vehicle (e.g., the ego vehicle 123) to generate a digital behavioral twin for that particular vehicle."
wherein the... telemetry data is for the same property of the model,
Jiang teaches ([0089]): "In some embodiments, the twin client 196 repeats this process of reporting the sensor data 191 and the ADAS data 192 to the digital behavioral twin system 199 on a periodic basis. The remote vehicles 124 also include a twin client 196 that reports sensor data 191 and ADAS data 192 of the remote vehicles 124 to the digital twin server 107. In this way, the digital behavioral twin system 199 of the digital twin server 107 has access to sensor data 191 and ADAS data 192 of the remote vehicles 124 as well as sensor data 191 and ADAS data 192 of the ego vehicle 123."
However, while Jiang does teach encryption of telemetry data (see at least [0050]), Jiang does not outright teach that the telemetry data is decoded according to respective signal decoding rules for the entities, wherein the entities included in the digital twin use heterogeneous signal formats for a same property of the model, and wherein the updated digital twin comprises the data decoded from the heterogeneous signal formats using the respective signal decoding rules. Ponda teaches vehicle telemetry, comprising:
wherein the telemetry data is decoded according to respective signal decoding rules for the entities,
Ponda teaches ([0037]): "As shown in FIG. 2, the aerial vehicle 102 includes multiple sensors 128a through 128d (collectively, 128) that are configured to provide to the computing device 104 various types of sensor data (also referred to herein as telemetry data) during flight by way of the communication link 108." Ponda further teaches ([0042]): "At block 404, telemetry data is received from the sensors 128 by way of the communication link 108." Ponda even further teaches ([0050]): "If two aerial vehicles 102 have different sensors, a different data format, and/or other differences, the estimation graph can account for such variants, such as by using different estimator modules 202, reading different input channels, and/or the like, and can provide a normalized data output. This can be beneficial in facilitating operation of a heterogeneous fleet of aerial vehicles 102 by way of a single fleet control system, despite some of the aerial vehicles 102 of the fleet being older and/or different with respect to one another." The Examiner has interpreted the normalization of data formats based upon variations in the vehicles as decoding according to respective signal decoding rules for the entities.
and wherein the entities included in the digital twin use heterogeneous signal formats for a same property of the model;
Ponda teaches ([0037]): "As shown in FIG. 2, the aerial vehicle 102 includes multiple sensors 128a through 128d (collectively, 128) that are configured to provide to the computing device 104 various types of sensor data (also referred to herein as telemetry data) during flight by way of the communication link 108." Ponda further teaches ([0042]): "At block 404, telemetry data is received from the sensors 128 by way of the communication link 108." Ponda even further teaches ([0050]): "If two aerial vehicles 102 have different sensors, a different data format, and/or other differences, the estimation graph can account for such variants, such as by using different estimator modules 202, reading different input channels, and/or the like, and can provide a normalized data output. This can be beneficial in facilitating operation of a heterogeneous fleet of aerial vehicles 102 by way of a single fleet control system, despite some of the aerial vehicles 102 of the fleet being older and/or different with respect to one another."
and wherein the updated digital twin comprises the data decoded from the heterogeneous signal formats using the respective signal decoding rules.
Ponda teaches ([0037]): "As shown in FIG. 2, the aerial vehicle 102 includes multiple sensors 128a through 128d (collectively, 128) that are configured to provide to the computing device 104 various types of sensor data (also referred to herein as telemetry data) during flight by way of the communication link 108." Ponda further teaches ([0042]): "At block 404, telemetry data is received from the sensors 128 by way of the communication link 108." Ponda even further teaches ([0050]): "If two aerial vehicles 102 have different sensors, a different data format, and/or other differences, the estimation graph can account for such variants, such as by using different estimator modules 202, reading different input channels, and/or the like, and can provide a normalized data output. This can be beneficial in facilitating operation of a heterogeneous fleet of aerial vehicles 102 by way of a single fleet control system, despite some of the aerial vehicles 102 of the fleet being older and/or different with respect to one another." Ponda is modified such that the normalization of data formats is applied to the periodic reporting of the sensor data 191 and ADAS data 192, which are used in the creation of the updated digital twin.
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Jiang to incorporate the teachings of Ponda to provide that the telemetry data is decoded according to respective signal decoding rules for the entities, wherein the entities included in the digital twin use heterogeneous signal formats for a same property of the model, and wherein the updated digital twin comprises the data decoded from the heterogeneous signal formats using the respective signal decoding rules. Jiang and Ponda are each directed towards similar pursuits in the field of vehicle fleet monitoring, and each are concerned with telemetry data obtained from vehicles. Accordingly, one of ordinary skill in the art would find it advantageous to augment the digital twin modeling of Jiang with the telemetry data decoding of Ponda, as incorporating the decoding of Ponda beneficially enables normalization of data output, even if vehicles of the fleet have different sensors and/or a different data format, as recognized by Ponda (see at least [0050]).
Regarding claim 36, Jiang and Ponda teach the aforementioned limitations of claim 34. Jiang further teaches:
the entities comprise a plurality of vehicles of a fleet,
Jiang teaches ([0007]): "The cloud server is operable to provide digital data, referred to as “twin data,” describing the digital behavioral twins to vehicles that use a digital twin service that is provided by the digital behavioral twin system. Vehicles that use the digital twin service include a small software client stored in their electronic control unit, or some other onboard vehicle computer, referred to as a “twin client.”" The Examiner has interpreted the vehicles that use the digital twin service as a fleet of vehicles associated with the digital behavioral twin system.
However, Jiang does not outright teach that at least a portion of the plurality of vehicles of the fleet use heterogeneous vehicle signal formats for the same property of the model. Ponda further teaches:
and wherein at least a portion of the plurality of vehicles of the fleet use heterogeneous vehicle signal formats for the same property of the model.
Ponda teaches ([0037]): "As shown in FIG. 2, the aerial vehicle 102 includes multiple sensors 128a through 128d (collectively, 128) that are configured to provide to the computing device 104 various types of sensor data (also referred to herein as telemetry data) during flight by way of the communication link 108." Ponda further teaches ([0042]): "At block 404, telemetry data is received from the sensors 128 by way of the communication link 108." Ponda even further teaches ([0050]): "If two aerial vehicles 102 have different sensors, a different data format, and/or other differences, the estimation graph can account for such variants, such as by using different estimator modules 202, reading different input channels, and/or the like, and can provide a normalized data output. This can be beneficial in facilitating operation of a heterogeneous fleet of aerial vehicles 102 by way of a single fleet control system, despite some of the aerial vehicles 102 of the fleet being older and/or different with respect to one another."
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Jiang and Ponda to further incorporate the teachings of Ponda to provide that at least a portion of the plurality of vehicles of the fleet use heterogeneous vehicle signal formats for the same property of the model. Jiang and Ponda are each directed towards similar pursuits in the field of vehicle fleet monitoring, and each are concerned with telemetry data obtained from vehicles. Accordingly, one of ordinary skill in the art would find it advantageous to augment the digital twin modeling of Jiang with the telemetry data decoding of Ponda, as incorporating the decoding of Ponda beneficially enables normalization of data output, even if vehicles of the fleet have different sensors and/or a different data format, as recognized by Ponda (see at least [0050]).
Regarding claim 38, Jiang and Ponda teach the aforementioned limitations of claim 36. Jiang further teaches:
the telemetry data comprises one or more of: camera data; LiDar data; electronic control unit (ECU) data; or location sensor data.
Jiang teaches ([0079]): "The sensor data 191 describes the measurements of the roadway environment that are recorded by the onboard vehicle sensors that are included in the sensor set 195. In some embodiments, the sensor set 195 of the ego vehicle 123 includes one or more of the following onboard vehicle sensors: ... a camera (e.g., one or more of an internal camera and an external camera); ... a LIDAR sensor..." Jiang further teaches ([0089]): "In some embodiments, the twin client 196 repeats this process of reporting the sensor data 191 and the ADAS data 192 to the digital behavioral twin system 199 on a periodic basis. The remote vehicles 124 also include a twin client 196 that reports sensor data 191 and ADAS data 192 of the remote vehicles 124 to the digital twin server 107. In this way, the digital behavioral twin system 199 of the digital twin server 107 has access to sensor data 191 and ADAS data 192 of the remote vehicles 124 as well as sensor data 191 and ADAS data 192 of the ego vehicle 123." Jiang even further teaches ([0091]): "The digital behavioral twin system 199 determines that the remote vehicles 124 are geographically proximate to the ego vehicle 123 based on GPS information included in the sensor data 191..."
Claim(s) 22, 27, and 35 is/are rejected under 35 U.S.C. 103 as being unpatentable over Jiang and Ponda in view of Koga et al. (US 2020/0265656 A1), hereinafter Koga.
Regarding claim 22, Jiang and Ponda teach the aforementioned limitations of claim 21. However, Jiang does not outright teach that the one or more computing devices are further configured to: receive, using a developer interface of the digital twin service, the first request; and provide, using the developer interface, a visualization of the digital twin and the decoded telemetry data. Koga teaches systems and methods for a digital twin of a refuse vehicle, comprising:
the one or more computing devices are further configured to: receive, using a developer interface of the digital twin service, the first request;
Koga teaches ([0004]): "Another embodiment relates to a method for displaying information of a refuse vehicle. The method includes obtaining multiple datasets from a sensor, a device, or a system of the refuse vehicle. The method also includes generating a digital twin of the refuse vehicle. The digital twin includes the multiple datasets and a graphical representation of the refuse vehicle. Each dataset is mapped to a corresponding sensor, device, or system. The method also includes receiving a request, at a user device, to display the digital twin of the refuse vehicle. The method also includes operating a display of the user device to provide the graphical representation of the refuse vehicle and one or more of the multiple datasets in response to the request."
and provide, using the developer interface, a visualization of the digital twin and the decoded telemetry data.
Koga teaches ([0004]): "Another embodiment relates to a method for displaying information of a refuse vehicle. The method includes obtaining multiple datasets from a sensor, a device, or a system of the refuse vehicle. The method also includes generating a digital twin of the refuse vehicle. The digital twin includes the multiple datasets and a graphical representation of the refuse vehicle. Each dataset is mapped to a corresponding sensor, device, or system. The method also includes receiving a request, at a user device, to display the digital twin of the refuse vehicle. The method also includes operating a display of the user device to provide the graphical representation of the refuse vehicle and one or more of the multiple datasets in response to the request." Koga is modified such that the datasets correspond to the decoded telemetry data of Jiang and Ponda.
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Jiang and Ponda to incorporate the teachings of Koga to provide that the one or more computing devices are further configured to: receive, using a developer interface of the digital twin service, the first request; and provide, using the developer interface, a visualization of the digital twin and the decoded telemetry data. Jiang and Koga are each directed towards similar pursuits in the field of digital twin modeling of vehicles. Accordingly, one of ordinary skill in the art would find it advantageous to incorporate the teachings of Koga, as doing so beneficially allows a user to monitor a present operational status of the digital twin, and enables the viewing of historical data of the digital twin, as recognized by Koga (see at least [0089]).
Regarding claim 27, Jiang and Ponda teach the aforementioned limitations of claim 26. However, Jiang does not outright teach receiving, using a developer interface of the digital twin service, the first request; and providing, using the developer interface, a visualization of the digital twin and the decoded telemetry data. Koga teaches systems and methods for a digital twin of a refuse vehicle, comprising:
receiving, using a developer interface of the digital twin service, the first request;
Koga teaches ([0004]): "Another embodiment relates to a method for displaying information of a refuse vehicle. The method includes obtaining multiple datasets from a sensor, a device, or a system of the refuse vehicle. The method also includes generating a digital twin of the refuse vehicle. The digital twin includes the multiple datasets and a graphical representation of the refuse vehicle. Each dataset is mapped to a corresponding sensor, device, or system. The method also includes receiving a request, at a user device, to display the digital twin of the refuse vehicle. The method also includes operating a display of the user device to provide the graphical representation of the refuse vehicle and one or more of the multiple datasets in response to the request."
and providing, using the developer interface, a visualization of the digital twin and the decoded telemetry data.
Koga teaches ([0004]): "Another embodiment relates to a method for displaying information of a refuse vehicle. The method includes obtaining multiple datasets from a sensor, a device, or a system of the refuse vehicle. The method also includes generating a digital twin of the refuse vehicle. The digital twin includes the multiple datasets and a graphical representation of the refuse vehicle. Each dataset is mapped to a corresponding sensor, device, or system. The method also includes receiving a request, at a user device, to display the digital twin of the refuse vehicle. The method also includes operating a display of the user device to provide the graphical representation of the refuse vehicle and one or more of the multiple datasets in response to the request." Koga is modified such that the datasets correspond to the decoded telemetry data of Jiang and Ponda.
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Jiang and Ponda to incorporate the teachings of Koga to provide receiving, using a developer interface of the digital twin service, the first request; and providing, using the developer interface, a visualization of the digital twin and the decoded telemetry data. Jiang and Koga are each directed towards similar pursuits in the field of digital twin modeling of vehicles. Accordingly, one of ordinary skill in the art would find it advantageous to incorporate the teachings of Koga, as doing so beneficially allows a user to monitor a present operational status of the digital twin, and enables the viewing of historical data of the digital twin, as recognized by Koga (see at least [0089]).
Regarding claim 35, Jiang and Ponda teach the aforementioned limitations of claim 34. However, Jiang does not outright teach receiving, using a developer interface of the digital twin service, the first request; and providing, using the developer interface, a visualization of the digital twin and the decoded telemetry data. Koga teaches systems and methods for a digital twin of a refuse vehicle, comprising:
the program instructions, when executed on or across the one or more processors, further cause the digital twin service to implement: receiving, using a developer interface of the digital twin service, the first request;
Koga teaches ([0004]): "Another embodiment relates to a method for displaying information of a refuse vehicle. The method includes obtaining multiple datasets from a sensor, a device, or a system of the refuse vehicle. The method also includes generating a digital twin of the refuse vehicle. The digital twin includes the multiple datasets and a graphical representation of the refuse vehicle. Each dataset is mapped to a corresponding sensor, device, or system. The method also includes receiving a request, at a user device, to display the digital twin of the refuse vehicle. The method also includes operating a display of the user device to provide the graphical representation of the refuse vehicle and one or more of the multiple datasets in response to the request."
and providing, using the developer interface, a visualization of the digital twin and the decoded telemetry data.
Koga teaches ([0004]): "Another embodiment relates to a method for displaying information of a refuse vehicle. The method includes obtaining multiple datasets from a sensor, a device, or a system of the refuse vehicle. The method also includes generating a digital twin of the refuse vehicle. The digital twin includes the multiple datasets and a graphical representation of the refuse vehicle. Each dataset is mapped to a corresponding sensor, device, or system. The method also includes receiving a request, at a user device, to display the digital twin of the refuse vehicle. The method also includes operating a display of the user device to provide the graphical representation of the refuse vehicle and one or more of the multiple datasets in response to the request." Koga is modified such that the datasets correspond to the decoded telemetry data of Jiang and Ponda.
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Jiang and Ponda to incorporate the teachings of Koga to provide receiving, using a developer interface of the digital twin service, the first request; and providing, using the developer interface, a visualization of the digital twin and the decoded telemetry data. Jiang and Koga are each directed towards similar pursuits in the field of digital twin modeling of vehicles. Accordingly, one of ordinary skill in the art would find it advantageous to incorporate the teachings of Koga, as doing so beneficially allows a user to monitor a present operational status of the digital twin, and enables the viewing of historical data of the digital twin, as recognized by Koga (see at least [0089]).
Claim(s) 24, 29, 32, 37, and 40 is/are rejected under 35 U.S.C. 103 as being unpatentable over Jiang and Ponda in view of Crewe et al. (US 2019/0088104 A1), hereinafter Crewe, and in further view of Zywicki et al. (US 2019/0140886 A1), hereinafter Zywicki.
Regarding claim 24, Jiang and Ponda teach the aforementioned limitations of claim 23. However, Jiang does not outright teach that the one or more computing devices are further configured to: receive information describing signal properties of respective ones of a plurality of sensors from manufacturers or suppliers for the plurality of vehicles. Crewe teaches a vehicle sensor system, comprising:
the one or more computing devices are further configured to: receive information describing signal properties of respective ones of a plurality of sensors from manufacturers or suppliers for the plurality of vehicles,
Crewe teaches ([0027]): "During its operation, the TMDS 100 monitors engine status through the device 110, and when the engine is shut off or fails, that data and information and other data and information is relayed to the TMDS 100… The device 110 includes decoders to decode or read signals broadcasted or carried according to the various protocols on the corresponding various wires and/or bus(es) and/or harness(es) electrically coupled or connected to, or wirelessly coupled or connected, through the connector 111 to send them to the control unit 101... The rules to decode these signals may be proprietary to the various vehicle manufacturers, but they may be licensed or reversed engineered, which, although may be difficult, can be accomplished, or they may be provided by the vehicle manufacturers in the interest of saving lives."
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Jiang and Ponda to incorporate the teachings of Crewe to provide that the one or more computing devices are further configured to: receive information describing signal properties of respective ones of a plurality of sensors from manufacturers or suppliers for the plurality of vehicles. Jiang, Ponda, and Crewe are each directed towards similar pursuits in the field of vehicle monitoring systems. Accordingly, one of ordinary skill in the art would find it advantageous to incorporate the signals and decoders of Crewe, as accounting for a variety of signal protocols and associated decoding rules beneficially serves to improve safety and follow rules associated with sovereignties that control the sale, use, and/or registration of vehicles located in their jurisdictions, as recognized by Crewe (see at least [0027]).
However, Jiang does not outright teach creating a signal catalog that includes instructions for converting the signal properties into a unified signal representation that represents a given property of the model. Zywicki teaches a vehicle telematics device, comprising:
wherein the plurality of vehicles comprises vehicles having different in- vehicle communication signal configurations;
Zywicki teaches ([0034]): "Fleets of vehicles are a core component of many industries such as logistics and personal transportation. In many cases, it can be beneficial to be able to monitor and track the status of vehicles within the fleet. As such, many vehicles are equipped with vehicle telematics devices. These vehicle telematics devices can obtain and/or measure a variety of data regarding the conditions and/or location of the vehicle along with receiving and transmitting data to telematics server systems." Zywicki further teaches ([0049]): "Process 300 further includes determining (320) available sensor devices. In numerous embodiments, the determination of available sensor devices include detecting what sensor devices are available via the vehicle data bus. In many embodiments, the available sensors devices is determined using a bus discovery process, such as those described in SAE J1978 and J1979 incorporated by reference above. The bus discovery process can provide a list of sensor devices in a variety of formats, including a bit string matching a standardized format, as appropriate... In a variety of embodiments, vehicle identification information such as, but not limited to, a vehicle identification number (VIN), are used to determine what sensor devices are available."
and create a signal catalog that includes instructions for converting the signal properties into a unified signal representation that represents a given property of the model.
Zywicki teaches ([0055]): "Process 400 can further include providing (440) requested data. In numerous embodiments, the requested data contains the newly requested sensor data... In numerous embodiments, identifying data about the vehicle and/or vehicle telematics device are stored in the message." Zywicki further teaches ([0058]): "Turning now to FIG. 5, a process for providing transcoded message data in accordance with an embodiment of the invention is illustrated. Process 500 includes obtaining (510) message data. In numerous embodiments, obtained message data is in a format that is typically not readable by vehicle telematics devices. Message data can be transcoded (520) into a usable format... In numerous embodiments, message data is transcoded by applying a set of rules describing transformations of instruction data stored within message data. In many embodiments, the instruction data provides requests for data such as, but not limited to, sensor data."
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Jiang, Ponda, and Crewe to incorporate the teachings of Zywicki to provide creating a signal catalog that includes instructions for converting the signal properties into a unified signal representation that represents a given property of the model. Jiang, Ponda, Crewe, and Zywicki are each directed towards similar pursuits in the field of vehicle monitoring systems. Accordingly, one of ordinary skill in the art would find it advantageous to incorporate the signal catalog of Zywicki, as doing so beneficially allows for transcoding of message data (including, for example, sensor data) into a usable format, as recognized by Zywicki (see at least [0058]).
Regarding claim 29, Jiang and Ponda teach the aforementioned limitations of claim 28. However, Jiang does not outright teach receiving information describing signal properties of respective ones of a plurality of sensors from manufacturers or suppliers for the plurality of vehicles. Crewe teaches a vehicle sensor system, comprising:
receiving information describing signal properties of respective ones of a plurality of sensors from manufacturers or suppliers for the plurality of vehicles,
Crewe teaches ([0027]): "During its operation, the TMDS 100 monitors engine status through the device 110, and when the engine is shut off or fails, that data and information and other data and information is relayed to the TMDS 100… The device 110 includes decoders to decode or read signals broadcasted or carried according to the various protocols on the corresponding various wires and/or bus(es) and/or harness(es) electrically coupled or connected to, or wirelessly coupled or connected, through the connector 111 to send them to the control unit 101... The rules to decode these signals may be proprietary to the various vehicle manufacturers, but they may be licensed or reversed engineered, which, although may be difficult, can be accomplished, or they may be provided by the vehicle manufacturers in the interest of saving lives."
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Jiang and Ponda to incorporate the teachings of Crewe to provide receiving information describing signal properties of respective ones of a plurality of sensors from manufacturers or suppliers for the plurality of vehicles. Jiang, Ponda, and Crewe are each directed towards similar pursuits in the field of vehicle monitoring systems. Accordingly, one of ordinary skill in the art would find it advantageous to incorporate the signals and decoders of Crewe, as accounting for a variety of signal protocols and associated decoding rules beneficially serves to improve safety and follow rules associated with sovereignties that control the sale, use, and/or registration of vehicles located in their jurisdictions, as recognized by Crewe (see at least [0027]).
However, Jiang does not outright teach creating a signal catalog that includes instructions for converting the signal properties into a unified signal representation that represents a given property of the model. Zywicki teaches a vehicle telematics device, comprising:
wherein the plurality of vehicles comprises vehicles having different in- vehicle communication signal configurations;
Zywicki teaches ([0034]): "Fleets of vehicles are a core component of many industries such as logistics and personal transportation. In many cases, it can be beneficial to be able to monitor and track the status of vehicles within the fleet. As such, many vehicles are equipped with vehicle telematics devices. These vehicle telematics devices can obtain and/or measure a variety of data regarding the conditions and/or location of the vehicle along with receiving and transmitting data to telematics server systems." Zywicki further teaches ([0049]): "Process 300 further includes determining (320) available sensor devices. In numerous embodiments, the determination of available sensor devices include detecting what sensor devices are available via the vehicle data bus. In many embodiments, the available sensors devices is determined using a bus discovery process, such as those described in SAE J1978 and J1979 incorporated by reference above. The bus discovery process can provide a list of sensor devices in a variety of formats, including a bit string matching a standardized format, as appropriate... In a variety of embodiments, vehicle identification information such as, but not limited to, a vehicle identification number (VIN), are used to determine what sensor devices are available."
and creating a signal catalog that includes instructions for converting the signal properties into a unified signal representation that represents a given property of the model.
Zywicki teaches ([0055]): "Process 400 can further include providing (440) requested data. In numerous embodiments, the requested data contains the newly requested sensor data... In numerous embodiments, identifying data about the vehicle and/or vehicle telematics device are stored in the message." Zywicki further teaches ([0058]): "Turning now to FIG. 5, a process for providing transcoded message data in accordance with an embodiment of the invention is illustrated. Process 500 includes obtaining (510) message data. In numerous embodiments, obtained message data is in a format that is typically not readable by vehicle telematics devices. Message data can be transcoded (520) into a usable format... In numerous embodiments, message data is transcoded by applying a set of rules describing transformations of instruction data stored within message data. In many embodiments, the instruction data provides requests for data such as, but not limited to, sensor data."
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Jiang, Ponda, and Crewe to incorporate the teachings of Zywicki to provide creating a signal catalog that includes instructions for converting the signal properties into a unified signal representation that represents a given property of the model. Jiang, Ponda, Crewe, and Zywicki are each directed towards similar pursuits in the field of vehicle monitoring systems. Accordingly, one of ordinary skill in the art would find it advantageous to incorporate the signal catalog of Zywicki, as doing so beneficially allows for transcoding of message data (including, for example, sensor data) into a usable format, as recognized by Zywicki (see at least [0058]).
Regarding claim 32, Jiang and Ponda teach the aforementioned limitations of claim 26. However, Jiang does not outright teach sending to the entities the respective signal decoding rules for decoding the telemetry data for the entities that corresponds to properties included in the digital twin. Crewe teaches a vehicle sensor system, comprising:
sending to the entities the respective signal decoding rules for decoding the telemetry data for the entities that corresponds to properties included in the digital twin,
Crewe teaches ([0027]): "During its operation, the TMDS 100 monitors engine status through the device 110, and when the engine is shut off or fails, that data and information and other data and information is relayed to the TMDS 100… The device 110 includes decoders to decode or read signals broadcasted or carried according to the various protocols on the corresponding various wires and/or bus(es) and/or harness(es) electrically coupled or connected to, or wirelessly coupled or connected, through the connector 111 to send them to the control unit 101... The rules to decode these signals may be proprietary to the various vehicle manufacturers, but they may be licensed or reversed engineered, which, although may be difficult, can be accomplished, or they may be provided by the vehicle manufacturers in the interest of saving lives."
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Jiang and Ponda to incorporate the teachings of Crewe to provide sending to the entities the respective signal decoding rules for decoding the telemetry data for the entities that corresponds to properties included in the digital twin. Jiang, Ponda, and Crewe are each directed towards similar pursuits in the field of vehicle monitoring systems. Accordingly, one of ordinary skill in the art would find it advantageous to incorporate the signals and decoders of Crewe, as accounting for a variety of signal protocols and associated decoding rules beneficially serves to improve safety and follow rules associated with sovereignties that control the sale, use, and/or registration of vehicles located in their jurisdictions, as recognized by Crewe (see at least [0027]).
However, Jiang does not outright teach that the signal decoding rules enable decoding of in-vehicle communication signals comprising the telemetry data. Zywicki teaches a vehicle telematics device, comprising:
wherein the signal decoding rules enable decoding of in- vehicle communication signals comprising the telemetry data.
Zywicki teaches ([0034]): "Fleets of vehicles are a core component of many industries such as logistics and personal transportation. In many cases, it can be beneficial to be able to monitor and track the status of vehicles within the fleet. As such, many vehicles are equipped with vehicle telematics devices. These vehicle telematics devices can obtain and/or measure a variety of data regarding the conditions and/or location of the vehicle along with receiving and transmitting data to telematics server systems." Zywicki further teaches ([0049]): "Process 300 further includes determining (320) available sensor devices. In numerous embodiments, the determination of available sensor devices include detecting what sensor devices are available via the vehicle data bus. In many embodiments, the available sensors devices is determined using a bus discovery process, such as those described in SAE J1978 and J1979 incorporated by reference above. The bus discovery process can provide a list of sensor devices in a variety of formats, including a bit string matching a standardized format, as appropriate... In a variety of embodiments, vehicle identification information such as, but not limited to, a vehicle identification number (VIN), are used to determine what sensor devices are available."
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Jiang, Ponda, and Crewe to incorporate the teachings of Zywicki to provide that the signal decoding rules enable decoding of in-vehicle communication signals comprising the telemetry data. Jiang, Ponda, Crewe, and Zywicki are each directed towards similar pursuits in the field of vehicle monitoring systems. Accordingly, one of ordinary skill in the art would find it advantageous to incorporate the signal catalog of Zywicki, as doing so beneficially allows for transcoding of message data (including, for example, sensor data) into a usable format, as recognized by Zywicki (see at least [0058]).
Regarding claim 37, Jiang and Ponda teach the aforementioned limitations of claim 36. However, Jiang does not outright teach receiving information describing signal properties of respective ones of a plurality of sensors from manufacturers or suppliers for the plurality of vehicles. Crewe teaches a vehicle sensor system, comprising:
the program instructions, when executed on or across the one or more processors, further cause the digital twin service to implement: receiving information describing signal properties of respective ones of a plurality of sensors from manufacturers or suppliers for the plurality of vehicles,
Crewe teaches ([0027]): "During its operation, the TMDS 100 monitors engine status through the device 110, and when the engine is shut off or fails, that data and information and other data and information is relayed to the TMDS 100… The device 110 includes decoders to decode or read signals broadcasted or carried according to the various protocols on the corresponding various wires and/or bus(es) and/or harness(es) electrically coupled or connected to, or wirelessly coupled or connected, through the connector 111 to send them to the control unit 101... The rules to decode these signals may be proprietary to the various vehicle manufacturers, but they may be licensed or reversed engineered, which, although may be difficult, can be accomplished, or they may be provided by the vehicle manufacturers in the interest of saving lives."
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Jiang and Ponda to incorporate the teachings of Crewe to provide receiving information describing signal properties of respective ones of a plurality of sensors from manufacturers or suppliers for the plurality of vehicles. Jiang, Ponda, and Crewe are each directed towards similar pursuits in the field of vehicle monitoring systems. Accordingly, one of ordinary skill in the art would find it advantageous to incorporate the signals and decoders of Crewe, as accounting for a variety of signal protocols and associated decoding rules beneficially serves to improve safety and follow rules associated with sovereignties that control the sale, use, and/or registration of vehicles located in their jurisdictions, as recognized by Crewe (see at least [0027]).
However, Jiang does not outright teach that the plurality of vehicles comprises vehicles having different in- vehicle communication signal configurations, and creating a signal catalog that includes instructions for converting the signal properties into a unified signal representation that represents a given property of the model. Zywicki teaches a vehicle telematics device, comprising:
wherein the plurality of vehicles comprises vehicles having different in- vehicle communication signal configurations;
Zywicki teaches ([0034]): "Fleets of vehicles are a core component of many industries such as logistics and personal transportation. In many cases, it can be beneficial to be able to monitor and track the status of vehicles within the fleet. As such, many vehicles are equipped with vehicle telematics devices. These vehicle telematics devices can obtain and/or measure a variety of data regarding the conditions and/or location of the vehicle along with receiving and transmitting data to telematics server systems." Zywicki further teaches ([0049]): "Process 300 further includes determining (320) available sensor devices. In numerous embodiments, the determination of available sensor devices include detecting what sensor devices are available via the vehicle data bus. In many embodiments, the available sensors devices is determined using a bus discovery process, such as those described in SAE J1978 and J1979 incorporated by reference above. The bus discovery process can provide a list of sensor devices in a variety of formats, including a bit string matching a standardized format, as appropriate... In a variety of embodiments, vehicle identification information such as, but not limited to, a vehicle identification number (VIN), are used to determine what sensor devices are available."
and creating a signal catalog that includes instructions for converting the signal properties into a unified signal representation that represents a given property of the model.
Zywicki teaches ([0055]): "Process 400 can further include providing (440) requested data. In numerous embodiments, the requested data contains the newly requested sensor data... In numerous embodiments, identifying data about the vehicle and/or vehicle telematics device are stored in the message." Zywicki further teaches ([0058]): "Turning now to FIG. 5, a process for providing transcoded message data in accordance with an embodiment of the invention is illustrated. Process 500 includes obtaining (510) message data. In numerous embodiments, obtained message data is in a format that is typically not readable by vehicle telematics devices. Message data can be transcoded (520) into a usable format... In numerous embodiments, message data is transcoded by applying a set of rules describing transformations of instruction data stored within message data. In many embodiments, the instruction data provides requests for data such as, but not limited to, sensor data."
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Jiang, Ponda, and Crewe to incorporate the teachings of Zywicki to provide creating a signal catalog that includes instructions for converting the signal properties into a unified signal representation that represents a given property of the model. Jiang, Ponda, Crewe, and Zywicki are each directed towards similar pursuits in the field of vehicle monitoring systems. Accordingly, one of ordinary skill in the art would find it advantageous to incorporate the signal catalog of Zywicki, as doing so beneficially allows for transcoding of message data (including, for example, sensor data) into a usable format, as recognized by Zywicki (see at least [0058]).
Regarding claim 40, Jiang and Ponda teach the aforementioned limitations of claim 34. However, Jiang does not outright teach sending to the entities the respective signal decoding rules for decoding the telemetry data for the entities that corresponds to properties included in the digital twin. Crewe teaches a vehicle sensor system, comprising:
the program instructions, when executed on or across the one or more processors, further cause the digital twin service to implement: sending to the entities the respective signal decoding rules for decoding the telemetry data for the entities that corresponds to properties included in the digital twin,
Crewe teaches ([0027]): "During its operation, the TMDS 100 monitors engine status through the device 110, and when the engine is shut off or fails, that data and information and other data and information is relayed to the TMDS 100… The device 110 includes decoders to decode or read signals broadcasted or carried according to the various protocols on the corresponding various wires and/or bus(es) and/or harness(es) electrically coupled or connected to, or wirelessly coupled or connected, through the connector 111 to send them to the control unit 101... The rules to decode these signals may be proprietary to the various vehicle manufacturers, but they may be licensed or reversed engineered, which, although may be difficult, can be accomplished, or they may be provided by the vehicle manufacturers in the interest of saving lives."
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Jiang and Ponda to incorporate the teachings of Crewe to provide sending to the entities the respective signal decoding rules for decoding the telemetry data for the entities that corresponds to properties included in the digital twin. Jiang, Ponda, and Crewe are each directed towards similar pursuits in the field of vehicle monitoring systems. Accordingly, one of ordinary skill in the art would find it advantageous to incorporate the signals and decoders of Crewe, as accounting for a variety of signal protocols and associated decoding rules beneficially serves to improve safety and follow rules associated with sovereignties that control the sale, use, and/or registration of vehicles located in their jurisdictions, as recognized by Crewe (see at least [0027]).
However, Jiang does not outright teach that the signal decoding rules enable decoding of in-vehicle communication signals comprising the telemetry data. Zywicki teaches a vehicle telematics device, comprising:
wherein the signal decoding rules enable decoding of in-vehicle communication signals comprising the telemetry data.
Zywicki teaches ([0034]): "Fleets of vehicles are a core component of many industries such as logistics and personal transportation. In many cases, it can be beneficial to be able to monitor and track the status of vehicles within the fleet. As such, many vehicles are equipped with vehicle telematics devices. These vehicle telematics devices can obtain and/or measure a variety of data regarding the conditions and/or location of the vehicle along with receiving and transmitting data to telematics server systems." Zywicki further teaches ([0049]): "Process 300 further includes determining (320) available sensor devices. In numerous embodiments, the determination of available sensor devices include detecting what sensor devices are available via the vehicle data bus. In many embodiments, the available sensors devices is determined using a bus discovery process, such as those described in SAE J1978 and J1979 incorporated by reference above. The bus discovery process can provide a list of sensor devices in a variety of formats, including a bit string matching a standardized format, as appropriate... In a variety of embodiments, vehicle identification information such as, but not limited to, a vehicle identification number (VIN), are used to determine what sensor devices are available."
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Jiang, Ponda, and Crewe to incorporate the teachings of Zywicki to provide that the signal decoding rules enable decoding of in-vehicle communication signals comprising the telemetry data. Jiang, Ponda, Crewe, and Zywicki are each directed towards similar pursuits in the field of vehicle monitoring systems. Accordingly, one of ordinary skill in the art would find it advantageous to incorporate the signal catalog of Zywicki, as doing so beneficially allows for transcoding of message data (including, for example, sensor data) into a usable format, as recognized by Zywicki (see at least [0058]).
Claim(s) 25, 31, and 39 is/are rejected under 35 U.S.C. 103 as being unpatentable over Jiang and Ponda in view of Simoudis (US 2020/0264953 A1).
Regarding claim 25, Jiang and Ponda teach the aforementioned limitations of claim 21. However, Jiang does not outright teach that the one or more computing devices are further configured to: decode the telemetry data ingested from the respective entities using the respective signal decoding rules. Ponda further teaches:
the one or more computing devices are further configured to: decode the telemetry data ingested from the respective entities using the respective signal decoding rules,
Ponda teaches ([0037]): "As shown in FIG. 2, the aerial vehicle 102 includes multiple sensors 128a through 128d (collectively, 128) that are configured to provide to the computing device 104 various types of sensor data (also referred to herein as telemetry data) during flight by way of the communication link 108." Ponda further teaches ([0042]): "At block 404, telemetry data is received from the sensors 128 by way of the communication link 108." Ponda further teaches ([0050]): "If two aerial vehicles 102 have different sensors, a different data format, and/or other differences, the estimation graph can account for such variants, such as by using different estimator modules 202, reading different input channels, and/or the like, and can provide a normalized data output. This can be beneficial in facilitating operation of a heterogeneous fleet of aerial vehicles 102 by way of a single fleet control system, despite some of the aerial vehicles 102 of the fleet being older and/or different with respect to one another." The Examiner has interpreted the normalization of data formats based upon variations in the vehicles as decoding according to respective signal decoding rules for the entities.
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Jiang and Ponda to further incorporate the teachings of Ponda to provide that the one or more computing devices are further configured to: decode the telemetry data ingested from the respective entities using the respective signal decoding rules. Jiang and Ponda are each directed towards similar pursuits in the field of vehicle fleet monitoring, and each are concerned with telemetry data obtained from vehicles. Accordingly, one of ordinary skill in the art would find it advantageous to augment the digital twin modeling of Jiang with the telemetry data decoding of Ponda, as incorporating the decoding of Ponda beneficially enables normalization of data output, even if vehicles of the fleet have different sensors and/or a different data format, as recognized by Ponda (see at least [0050]).
However, neither Jiang nor Ponda outright teach that the telemetry data ingested is decoded from a binary format used for signal representations at the entity into one or more sensor signal values used to populate one or more properties of the model. Simoudis teaches systems and methods for managing vehicle data, comprising:
wherein the telemetry data ingested is decoded from a binary format used for signal representations at the entity into one or more sensor signal values used to populate one or more properties of the model.
Simoudis teaches ([0116]): "In some cases, the data processing module may enrich the incoming data from the sensors by decoding the raw binary data into consumable data formats (such as JavaScript Object Notation) or also merging with additional necessary and useful metadata." Simoudis is modified such that consumable data formats output by the decoding of raw binary data correspond to the sensor data of Jiang and Ponda. The Examiner notes that sensor signal values are used to populate one or more properties of the model of Jiang (see at least [0090]-[0092] of Jiang as discussed above).
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Jiang and Ponda to incorporate the teachings of Simoudis to provide that the telemetry data ingested is decoded from a binary format used for signal representations at the entity into one or more sensor signal values used to populate one or more properties of the model. Jiang, Ponda, and Simoudis are each directed towards similar pursuits in the field of vehicle monitoring systems. Further, Ponda is already concerned with the decoding of sensor data (see at least [0050]). As such, one of ordinary skill in the art would find it advantageous to incorporate the teachings of Simoudis, as the teachings of Simoudis allows for conversion of raw binary data into a compatible data format (see at least [0116]) in a similar manner to that of Jiang and Ponda.
Regarding claim 31, Jiang and Ponda teach the aforementioned limitations of claim 26. However, Jiang does not outright teach decoding the telemetry data ingested from the respective entities using the respective signal decoding rules. Ponda further teaches:
decoding the telemetry data ingested from the respective entities using the respective signal decoding rules,
Ponda teaches ([0037]): "As shown in FIG. 2, the aerial vehicle 102 includes multiple sensors 128a through 128d (collectively, 128) that are configured to provide to the computing device 104 various types of sensor data (also referred to herein as telemetry data) during flight by way of the communication link 108." Ponda further teaches ([0042]): "At block 404, telemetry data is received from the sensors 128 by way of the communication link 108." Ponda further teaches ([0050]): "If two aerial vehicles 102 have different sensors, a different data format, and/or other differences, the estimation graph can account for such variants, such as by using different estimator modules 202, reading different input channels, and/or the like, and can provide a normalized data output. This can be beneficial in facilitating operation of a heterogeneous fleet of aerial vehicles 102 by way of a single fleet control system, despite some of the aerial vehicles 102 of the fleet being older and/or different with respect to one another." The Examiner has interpreted the normalization of data formats based upon variations in the vehicles as decoding according to respective signal decoding rules for the entities.
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Jiang and Ponda to further incorporate the teachings of Ponda to provide decoding the telemetry data ingested from the respective entities using the respective signal decoding rules. Jiang and Ponda are each directed towards similar pursuits in the field of vehicle fleet monitoring, and each are concerned with telemetry data obtained from vehicles. Accordingly, one of ordinary skill in the art would find it advantageous to augment the digital twin modeling of Jiang with the telemetry data decoding of Ponda, as incorporating the decoding of Ponda beneficially enables normalization of data output, even if vehicles of the fleet have different sensors and/or a different data format, as recognized by Ponda (see at least [0050]).
However, neither Jiang nor Ponda outright teach that the telemetry data ingested is decoded from a binary format used for signal representations at the entity into one or more sensor signal values used to populate one or more properties of the model. Simoudis teaches systems and methods for managing vehicle data, comprising:
wherein the telemetry data ingested is decoded from a binary format used for signal representations at the entity into one or more sensor signal values used to populate one or more properties of the model.
Simoudis teaches ([0116]): "In some cases, the data processing module may enrich the incoming data from the sensors by decoding the raw binary data into consumable data formats (such as JavaScript Object Notation) or also merging with additional necessary and useful metadata." Simoudis is modified such that consumable data formats output by the decoding of raw binary data correspond to the sensor data of Jiang and Ponda. The Examiner notes that sensor signal values are used to populate one or more properties of the model of Jiang (see at least [0090]-[0092] of Jiang as discussed above).
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Jiang and Ponda to incorporate the teachings of Simoudis to provide that the telemetry data ingested is decoded from a binary format used for signal representations at the entity into one or more sensor signal values used to populate one or more properties of the model. Jiang, Ponda, and Simoudis are each directed towards similar pursuits in the field of vehicle monitoring systems. Further, Ponda is already concerned with the decoding of sensor data (see at least [0050]). As such, one of ordinary skill in the art would find it advantageous to incorporate the teachings of Simoudis, as the teachings of Simoudis allows for conversion of raw binary data into a compatible data format (see at least [0116]) in a similar manner to that of Jiang and Ponda.
Regarding claim 39, Jiang and Ponda teach the aforementioned limitations of claim 34. However, Jiang does not outright teach decoding the telemetry data ingested from the respective entities using the respective signal decoding rules. Ponda further teaches:
the program instructions, when executed on or across the one or more processors, further cause the digital twin service to implement: decoding the telemetry data ingested from the respective entities using the respective signal decoding rules,
Ponda teaches ([0037]): "As shown in FIG. 2, the aerial vehicle 102 includes multiple sensors 128a through 128d (collectively, 128) that are configured to provide to the computing device 104 various types of sensor data (also referred to herein as telemetry data) during flight by way of the communication link 108." Ponda further teaches ([0042]): "At block 404, telemetry data is received from the sensors 128 by way of the communication link 108." Ponda further teaches ([0050]): "If two aerial vehicles 102 have different sensors, a different data format, and/or other differences, the estimation graph can account for such variants, such as by using different estimator modules 202, reading different input channels, and/or the like, and can provide a normalized data output. This can be beneficial in facilitating operation of a heterogeneous fleet of aerial vehicles 102 by way of a single fleet control system, despite some of the aerial vehicles 102 of the fleet being older and/or different with respect to one another." The Examiner has interpreted the normalization of data formats based upon variations in the vehicles as decoding according to respective signal decoding rules for the entities.
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Jiang and Ponda to further incorporate the teachings of Ponda to provide decoding the telemetry data ingested from the respective entities using the respective signal decoding rules. Jiang and Ponda are each directed towards similar pursuits in the field of vehicle fleet monitoring, and each are concerned with telemetry data obtained from vehicles. Accordingly, one of ordinary skill in the art would find it advantageous to augment the digital twin modeling of Jiang with the telemetry data decoding of Ponda, as incorporating the decoding of Ponda beneficially enables normalization of data output, even if vehicles of the fleet have different sensors and/or a different data format, as recognized by Ponda (see at least [0050]).
However, neither Jiang nor Ponda outright teach that the telemetry data ingested is decoded from a binary format used for signal representations at the entity into one or more sensor signal values used to populate one or more properties of the model. Simoudis teaches systems and methods for managing vehicle data, comprising:
wherein the telemetry data ingested is decoded from a binary format used for signal representations at the entity into one or more sensor signal values used to populate one or more properties of the model.
Simoudis teaches ([0116]): "In some cases, the data processing module may enrich the incoming data from the sensors by decoding the raw binary data into consumable data formats (such as JavaScript Object Notation) or also merging with additional necessary and useful metadata." Simoudis is modified such that consumable data formats output by the decoding of raw binary data correspond to the sensor data of Jiang and Ponda. The Examiner notes that sensor signal values are used to populate one or more properties of the model of Jiang (see at least [0090]-[0092] of Jiang as discussed above).
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Jiang and Ponda to incorporate the teachings of Simoudis to provide that the telemetry data ingested is decoded from a binary format used for signal representations at the entity into one or more sensor signal values used to populate one or more properties of the model. Jiang, Ponda, and Simoudis are each directed towards similar pursuits in the field of vehicle monitoring systems. Further, Ponda is already concerned with the decoding of sensor data (see at least [0050]). As such, one of ordinary skill in the art would find it advantageous to incorporate the teachings of Simoudis, as the teachings of Simoudis allows for conversion of raw binary data into a compatible data format (see at least [0116]) in a similar manner to that of Jiang and Ponda.
Claim(s) 33 is/are rejected under 35 U.S.C. 103 as being unpatentable over Jiang and Ponda in view of Hyde et al. (US 2009/0171548 A1), hereinafter Hyde.
Regarding claim 33, Jiang and Ponda teach the aforementioned limitations of claim 26. However, Jiang does not outright teach that properties for the model comprise one or more static properties associated with a particular vehicle including one or more of: vehicle brand, vehicle body type, and vehicle engine model. Hyde teaches a system and method for operating a vehicle, comprising:
properties for the model comprise one or more static properties associated with a particular vehicle including one or more of: vehicle brand, vehicle body type, and vehicle engine model.
Hyde teaches ([0002]): "The control system may further include a compliance transmitter configured to transmit information about the control signal or the acknowledgement signal to a remote compliance system. A control signal may be selected for broadcast responsive to one or more acknowledgement signals. The control system may include a vehicle identification units configured to determine a property of the vehicle, for example by receiving an identification signal, the control signal broadcast unit being configured to broadcast the control signal responsive to the determined vehicle property (e.g., car make, car model, engine type, exhaust type, vehicle identification number, license number, location, settings of the engine control unit, or fuel type). The control signal may include verifying information selected to allow the vehicle to determine authenticity of the control signal."
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Jiang and Ponda to incorporate the teachings of Hyde to provide that properties for the model comprise one or more static properties associated with a particular vehicle including one or more of: vehicle brand, vehicle body type, and vehicle engine model. Jiang, Ponda, and Hyde are each directed towards similar pursuits in the field of vehicle monitoring systems. Accordingly, one of ordinary skill in the art would find it advantageous to incorporate the teachings of Hyde, as doing so beneficially enables determining authenticity of a signal by verifying vehicle properties, as recognized by Hyde (see at least [0002]).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Kamini et al. (US 2019/0147743 A1) teaches vehicle guidance based a location spatial model, wherein vehicle sensor data including position, speed, and direction are used within an electronically-representative spatial model; one or more graphics are generated to display on a virtual display based on the vehicle position (see at least [0013]). Mavreas (US 2003/0093199 A1) teaches remote monitoring and control of motorized vehicles including performing message format and protocol conversions between messages sent over vehicle data communication systems, and teaches the ability to distribute program updates and protocol information from a data network for a fleet of vehicles.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to FRANK T GLENN III whose telephone number is (571)272-5078. The examiner can normally be reached M-F 7:30AM - 4:30PM EST.
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, Jelani Smith can be reached at 571-270-3969. 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.
/F.T.G./Examiner, Art Unit 3662
/DALE W HILGENDORF/Primary Examiner, Art Unit 3662