DETAILED ACTION
Response to Amendment
Applicant’s response to the last Office Action, filed on 4/2/2026 has been entered and made of record.
Response to Arguments
Applicant's arguments filed on 4/2/2026 have been fully considered but they are not persuasive.
Detailed analysis below is updated to reflect the recent amendments. See below.
Cella teaches a node of the vehicle shadow corresponding to the first data stream is updated at a frequency, wherein another node of the vehicle shadow corresponding to the second data stream is updated at a frequency and providing, for display, using a user interface, the updated version of the vehicle shadow (As above, Cella ¶ 0030 teaches the system receiving vehicle parameter data from many sensor inputs to determine the vehicle operating state and an graphical interface for the digital twin system to present the multi-sensor data. Fig. 4 and ¶ 0153 which shows a diagrammatic view of the input parameters such as vehicle sensor data and the high-level schema by which they are organized. Fig. 7 and ¶ 0156 also teach the system receiving data from a variety of sources and including sensor sets. Fig. 73 and ¶ 0551-0553 provides an example of the digital shadow which combines multiple vehicle data streams to characterize vehicle and driver behavior. Fig. 67 is the service & maintenance view of the digital twin, presenting maintenance related data. Fig. 61 and 63 show the selection of different digital twin views. The multi-dimensional data streams which populate these digital twin views are shown at Figs. 1, 3, 18, 27 and 48 which show the collecting of data related to vehicle operating states, sensor-based rider states, vision-based environmental states and safety states. ¶ 0524 teaches that the digital twin collects on-board data including real-time sensor data about components communicated through CAN network of the vehicle.)
Kim teaches receiving the streaming data from the vehicle, wherein the streaming data comprises a first data stream from a first sensor at a higher data update frequency of the vehicle and a second data stream from a second sensor of the vehicle at a lower data update frequency, and wherein the first data stream and the second data stream are disaggregated from each other and are received asynchronously at the one or more remote computing devices. (Kim teaches a robotic vehicle with a network-based digital shadow for communication between the robot and sensor, see Abstract. ¶ 0040-0041 teaches that the system performs both synchronous and asynchronous data transmission and ¶ 0041 notes that upstream communication such as outputs of the robot’s sensors to the server are performed asynchronously so as to reduce latency in communication the sensor data streams to the server. ¶ 0057-0063 provide detail on the upstream packet transmissions with ¶ 0061-0063 teaching using different intervals for different sensor types to optimize communication and bandwidth across the different sensor data which are transmitted independent of one another. This is an explicit teaching that the data of one sensor is sent and received at a higher frequency than the data of another sensor.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have combined the above combination’s digital vehicle shadow system with Kim’s digital vehicle shadow system. Kumar, Cella and Kim each teach systems for implementing digital shadows for a connected vehicle. Cella teaches receiving vehicle parameter data from many modalities of sensor inputs to generate a variety of views of the vehicle digital twin/shadow. Diverse data streams on all manner of vehicle, driver, maintenance and vehicle safety data are received from a variety of sensor sources. While there is no suggestion that any of this data collection would be synchronous collection in any way, Cella is missing an explicit teaching that it is specifically asynchronous. Kim provides explicit teaching that the communication with the vehicle is performed asynchronously. The combination constitutes the repeatable and predictable result of simply applying Kim’s teachings here for asynchronous communication of different vehicle sensors, for the purpose of enabling communication of different vehicle sensors at different rates, allowing very frequent communication from sensors such as proximity sensors while saving bandwidth by reducing frequency for sensors which don’t need frequent transmission. This cannot be considered a non-obvious improvement in view of the relevant prior art here. Using known engineering design, no “fundamental” operating principle of the teachings are changed; they continue to perform the same functions as originally taught prior to being combined.
Regarding arguments directed to claims 12 and 19, Examiner notes that Cella does provide teaching for a tree structure with leaves corresponding to nodes of the shadow. Cella ¶ 0030 teaches the system receiving vehicle parameter data from many sensor inputs to determine the vehicle operating state and an graphical interface for the digital twin system to present the multi-sensor data. Fig. 4 and ¶ 0153 which shows a diagrammatic view of the input parameters such as vehicle sensor data and the high-level schema by which they are organized. This is especially useful for visualizing Cella’s tree structure but the teachings here are also provided elsewhere. Fig. 7 and ¶ 0156 also teach the system receiving data from a variety of sources and including sensor sets. Fig. 73 and ¶ 0551-0553 provides an example of the digital shadow which combines multiple vehicle data streams to characterize vehicle and driver behavior. Fig. 67 is the service & maintenance view of the digital twin, presenting maintenance related data. Fig. 61 and 63 show the selection of different digital twin views. The multi-dimensional data streams which populate these digital twin views are shown at Figs. 1, 3, 18, 27 and 48 which show the collecting of data related to vehicle operating states, sensor-based rider states, vision-based environmental states and safety states.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim(s) 1-12 and 14-19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Kumar (“Field Notes: Implementing a Digital Shadow of a Connected Vehicle with AWS IoT”) in view of Cella (US PGPub 2021/0272394) and Kim (US PGPub 2006/0146776)
Regarding claim 1, Kumar discloses a system, comprising: (Kumar teaches a system for implementing a digital shadow for a connected vehicle with the Amazon Web Services AWS IoT system.)
one or more computing devices configured to implement a model builder for a vehicle shadow for a vehicle, the model builder configured to: (See steps 1-3 and the top of the pg. 2 and the figure on pg. 2, which both describe using the vehicle TCU, AWS IoT Core cloud server and a mobile device.)
receive a model to be used for the vehicle shadow; and (Pg. 3, Sections “Implementation” and “Create device” for creating and receiving the model in the AWS IoT system.)
generate, based on the received model and an associated schema, a mapping of respective elements of sensor data included in streaming data provided by the vehicle to one or more nodes of the vehicle shadow; and (Pg. 4, ¶ 1, teaches mapping the associated vehicle states to the virtual vehicle shadow, “AWS IoT Device Shadow is an important feature of AWS IoT core for remote command execution because it allows you to decouple the vehicle and the app which controls and commands the vehicle. A device’s shadow is a JSON document that is used to store and retrieve current state information for a device. Primarily we use state.desired and state.reported properties of a device’s shadow document.”)
one or more remote computing devices configured to implement a data storage system for the vehicle shadow, the data storage system configured to: (See AWS cloud database figure on pg. 2.)
receive the streaming data from the vehicle, wherein the streaming data comprises data streams from a plurality of sensors of the vehicle, and wherein the disaggregated data streams are received; and (Figure on pg. 2 notes that vehicle state streaming data is obtained as prompted by vehicle status change)
maintain an updated version of the vehicle shadow, wherein the updated version of the vehicle shadow is updated to reflect a current state of the vehicle based on the streaming data. (As noted above, Figure on pg. 2 notes that vehicle state streaming data updates are obtained as prompted by vehicle status change. Also see pg. 4, ¶ 2 which describes the real-time updates enabled by the vehicle shadow.)
provide, for display, using a user interface, the updated version of the vehicle shadow. (Pg. 3, step 5 teaches updating the UI user interface of the vehicle shadow to reflect changes)
In the field of digital vehicle shadow systems Cella teaches what Kumar does not expressly disclose, namely, an explicit associated schema mapping of respective elements of sensor data included in streaming data provided by the vehicle to one or more nodes of the vehicle shadow and wherein the associated schema maps elements of the first data stream and the second data stream to attributes of the schema and maps the attributes of the schema to nodes of the vehicle shadow the associated schema is user-defined and. (Cella teaches a system for creating digital twin/shadows shadows for vehicles to represent vehicle state information as transmitted to the shadow. Cella ¶ 0030 teaches the system receiving vehicle parameter data from one or more inputs to determine the vehicle operating state and an interface for the digital twin system to present the vehicle operating state. Also see Fig. 4 and ¶ 0153 which shows a diagrammatic view of the input parameters such as vehicle sensor data and the high-level schema by which they are organized. The schema is configurable based on adjustments of the user, see examples at Figs. 64, 65 and 66 and ¶ 0513-0515 which teaches various ways in which first and second data streams are organized in a digital twin/shadow. Figs. 61-64 also show examples of how the digital shadow is user-defined. Fig. 73 and ¶ 0551-0553 which provides another example of the digital shadow which combines multiple vehicle data streams to characterize vehicle and driver behavior. Fig. 0059 teaches that the digital twin can be hosted on a cloud computing platform.)
wherein a node of the vehicle shadow corresponding to the first data stream is updated at a frequency, wherein another node of the vehicle shadow corresponding to the second data stream is updated at a frequency and providing, for display, using a user interface, the updated version of the vehicle shadow (As above, Cella ¶ 0030 teaches the system receiving vehicle parameter data from many sensor inputs to determine the vehicle operating state and an graphical interface for the digital twin system to present the multi-sensor data. Fig. 4 and ¶ 0153 which shows a diagrammatic view of the input parameters such as vehicle sensor data and the high-level schema by which they are organized. Fig. 7 and ¶ 0156 also teach the system receiving data from a variety of sources and including sensor sets. Fig. 73 and ¶ 0551-0553 provides an example of the digital shadow which combines multiple vehicle data streams to characterize vehicle and driver behavior. Fig. 67 is the service & maintenance view of the digital twin, presenting maintenance related data. Fig. 61 and 63 show the selection of different digital twin views. The multi-dimensional data streams which populate these digital twin views are shown at Figs. 1, 3, 18, 27 and 48 which show the collecting of data related to vehicle operating states, sensor-based rider states, vision-based environmental states and safety states. ¶ 0524 teaches that the digital twin collects on-board data including real-time sensor data about components communicated through CAN network of the vehicle.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have combined Kumar’s digital vehicle shadow system with Cella’s digital vehicle shadow system. Kumar and Cella both teach systems for implementing digital shadows for a connected vehicle. Cella provides explicit teaching that the vehicle information is mapped into an information schema that contains multiple data streams and is user defined. The combination constitutes the repeatable and predictable result of simply applying Cella’s teachings here for providing basic organization of the vehicle information by such a software. This cannot be considered a non-obvious improvement in view of the relevant prior art here. Using known engineering design, no “fundamental” operating principle of the teachings are changed; they continue to perform the same functions as originally taught prior to being combined.
In the field of digital vehicle shadow systems Kim teaches receiving the streaming data from the vehicle, wherein the streaming data comprises a first data stream from a first sensor at a higher data update frequency of the vehicle and a second data stream from a second sensor of the vehicle at a lower data update frequency, and wherein the first data stream and the second data stream are disaggregated from each other and are received asynchronously at the one or more remote computing devices. (Kim teaches a robotic vehicle with a network-based digital shadow for communication between the robot and sensor, see Abstract. ¶ 0040-0041 teaches that the system performs both synchronous and asynchronous data transmission and ¶ 0041 notes that upstream communication such as outputs of the robot’s sensors to the server are performed asynchronously so as to reduce latency in communication the sensor data streams to the server. ¶ 0057-0063 provide detail on the upstream packet transmissions with ¶ 0061-0063 teaching using different intervals for different sensor types to optimize communication and bandwidth across the different sensor data which are transmitted independent of one another. This is an explicit teaching that the data of one sensor is sent and received at a higher frequency than the data of another sensor.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have combined the above combination’s digital vehicle shadow system with Kim’s digital vehicle shadow system. Kumar, Cella and Kim each teach systems for implementing digital shadows for a connected vehicle. Cella teaches receiving vehicle parameter data from many modalities of sensor inputs to generate a variety of views of the vehicle digital twin/shadow. Diverse data streams on all manner of vehicle, driver, maintenance and vehicle safety data are received from a variety of sensor sources. While there is no suggestion that any of this data collection would be synchronous collection in any way, Cella is missing an explicit teaching that it is specifically asynchronous. Kim provides explicit teaching that the communication with the vehicle is performed asynchronously. The combination constitutes the repeatable and predictable result of simply applying Kim’s teachings here for asynchronous communication of different vehicle sensors, for the purpose of enabling communication of different vehicle sensors at different rates, allowing very frequent communication from sensors such as proximity sensors while saving bandwidth by reducing frequency for sensors which don’t need frequent transmission. This cannot be considered a non-obvious improvement in view of the relevant prior art here. Using known engineering design, no “fundamental” operating principle of the teachings are changed; they continue to perform the same functions as originally taught prior to being combined.
Regarding claim 2, the above combination discloses the system of claim 1, wherein to generate the mapping, the model builder is further configured to:
map data included in the streaming data corresponding to respective sensors of the vehicle to attributes of the schema corresponding to the respective sensors; and (Cella Figs. 4, 64 and 73 teaches that the shadow uses a mapped hierarchical schema of the streamed vehicle sensor data.)
map the attributes of the schema to nodes of the vehicle shadow, wherein the nodes of the vehicle shadow are organized based on the received model. (As above, See Cella Figs. 4 and 10)
Regarding claim 3, the above combination discloses the system of claim 1, wherein the schema further defines one or more transformations to be applied to streaming data for one or more sensors mapped to one or more attributes of the schema. (Cella discloses a number of transformations of the mapped sensor data, for example see and ¶ 0551-0553 which provides another example of the digital shadow which combines multiple vehicle data streams to characterize vehicle and driver behavior.)
Regarding claim 4, the above combination discloses the system of claim 3, wherein for at least one attribute of the schema streaming data for two or more sensors is mapped to the at least one attribute, wherein a transformation is applied to the streaming data for the two or more sensors to generate an attribute value for the at least one attribute. (As above, Cella discloses a number of transformations of the mapped sensor data, for example see and ¶ 0551-0553 which provides another example of the digital shadow which combines multiple vehicle data streams to characterize vehicle and driver behavior.)
Regarding claim 5, the above combination discloses the system of claim 1, wherein data in the data stream for at least one sensor of the plurality of sensors of the vehicle is mapped to two or more attributes of the schema. (Cella Fig. 64 for example reports speed and Cella also teaches a number of transformations of the mapped sensor data, for example see and ¶ 0551-0553 which uses speed to compute a vehicle stability measure.)
Regarding claim 6, the above combination discloses the system of claim 1, wherein the data storage system for the vehicle shadow is further configured to: validate the received streaming data for conformance with the schema, wherein the updated version of the vehicle shadow is updated using the validated data conforming to the schema. (Cella ¶ 0453)
Regarding claim 7, the above combination discloses the method, comprising: receiving, from a vehicle, at a remote computing device, streaming data from the vehicle, wherein the streaming data comprises a first data stream from a first sensor of the vehicle at a higher data update frequency and a second data stream from a second sensor of the vehicle at a lower data update frequency, and wherein the first data stream and the second data stream are disaggregated from each other and are received asynchronously at the remote computing device; (See rejection of claim 1. Kumar, Kim and Cella teach systems for implementing digital shadows for a connected vehicle.)
and maintaining an updated version of a vehicle shadow for the vehicle, wherein the updated version of the vehicle shadow is updated to reflect a current state of the vehicle based on the streaming data. (See rejection of claim 1. Kim provides explicit teaching that the communication with the vehicle is performed asynchronously and that the vehicle information is mapped into information schema.)
wherein a node of the vehicle shadow corresponding to the first data stream is updated at the higher data update frequency, and wherein another node of the vehicle shadow corresponding to the second data stream is updated at the lower data update frequency; and providing, for display, using a user interface, the updated version of the vehicle shadow. (See rejection of claim 1.)
Regarding claim 8, the above combination discloses the method of claim 7, further comprising: receiving a model and associated schema to be used for the vehicle shadow; and generating, based on the received model and associated schema, a mapping of respective elements of sensor data included in the streaming data to one or more nodes of the vehicle shadow. (See rejection of claim 2)
Regarding claim 9, the above combination discloses the method of claim 8, wherein said generating the mapping comprises: mapping data included in the streaming data corresponding to respective sensors of the vehicle to attributes of the schema corresponding to the respective sensors; and mapping the attributes of the schema to nodes of the vehicle shadow, wherein the nodes of the vehicle shadow are organized based on the received model. (See rejection of claim 2.)
Regarding claim 10, the above combination discloses the method of claim 8, further comprising: providing a user interface for a vehicle shadow service, wherein the model is received from a user of the vehicle shadow service via the user interface. (See rejection of claim 1, Kumar pg. 3, Sections “Implementation” and “Create device” teaches creating and receiving the model in the AWS IoT system via user interface.)
Regarding claim 11, the above combination discloses the method of claim 10, wherein the schema is: received from the user via the user interface; or provided by the vehicle shadow service, based on the model received from the user via the user interface. (As above, Kumar pg. 3, Sections “Implementation” and “Create device” teaches creating and receiving the model in the AWS IoT system via user interface. Cella Fig. 4 and elsewhere teaches that the shadow uses a mapped hierarchical schema of the streamed vehicle sensor data. It follows from the combination of Kumar and Cella that it would have been obvious to receive the schema from a user interface.)
Regarding claim 12, the above combination discloses the method of claim 7, wherein the vehicle shadow is organized according to a tree-structure, wherein leaves of the tree-structure correspond to nodes of the vehicle shadow and are mapped to attributes of a schema for the vehicle shadow. (See rejection of claim 2. As above, Cella ¶ 0030 teaches the system receiving vehicle parameter data from many sensor inputs to determine the vehicle operating state and an graphical interface for the digital twin system to present the multi-sensor data. Fig. 4 and ¶ 0153 which shows a diagrammatic view of the input parameters such as vehicle sensor data and the high-level schema by which they are organized. Fig. 7 and ¶ 0156 also teach the system receiving data from a variety of sources and including sensor sets. Fig. 73 and ¶ 0551-0553 provides an example of the digital shadow which combines multiple vehicle data streams to characterize vehicle and driver behavior. Fig. 67 is the service & maintenance view of the digital twin, presenting maintenance related data. Fig. 61 and 63 show the selection of different digital twin views. The multi-dimensional data streams which populate these digital twin views are shown at Figs. 1, 3, 18, 27 and 48 which show the collecting of data related to vehicle operating states, sensor-based rider states, vision-based environmental states and safety states. ¶ 0524 teaches that the digital twin collects on-board data including real-time sensor data about components communicated through CAN network of the vehicle.)
Regarding claim 14, the above combination discloses the method of claim 7, further comprising the vehicle model, vehicle shadow, vehicle mapping of streaming data, and maintaining an updated version of the vehicle shadow and receiving a first model to be used for a first vehicle shadow representing a first view of the vehicle; receiving a second model to be used for a second vehicle shadow representing a second view of the vehicle; generating, based on the received first model, a first mapping of respective elements of sensor data included in the streaming data to one or more nodes of the first vehicle shadow; and generating, based on the received second model, a second mapping of at least some other respective elements of sensor data included in the streaming data to one or more nodes of the second vehicle shadow, wherein said maintaining an updated version of the vehicle shadow comprises maintaining updated versions of the first and second vehicle shadows for the vehicle. (Cella ¶ 0030 teaches a digital twin/shadow system receiving vehicle parameter data from one or more inputs to determine the vehicle operating state and an interface for the digital twin system to present the vehicle operating state. Cella teaches a number of ways for generating and displaying different first and second views of the vehicle within the digital twin system, as described in ¶ 0009 that the digital twin sensor data and mapping may be customized based on adjustments of the user. See examples at Figs. 64, 65 and 66 and ¶ 0513-0515.)
Regarding claim 15, the above combination discloses one or more non-transitory, computer-readable storage media storing program instructions that, when executed on or across one or more processors, cause the one or more processors to: (Cella ¶ 0589)
receive a model to be used for a vehicle shadow; (See rejection of claim 1)
generate, based on the received model and associated schema, a mapping of respective elements of sensor data included in streaming data provided by the vehicle to one or more nodes of the vehicle shadow, wherein the streaming data comprises a first data stream from a first sensor a higher data update frequency and a second data stream from a second sensor a lower data update frequency, wherein the first data stream and the second data stream are disaggregated from each other and are received asynchronously at a remote computing device; and (See rejection of claim 1)
maintain, at the remote computing device which receives the streaming data from the vehicle, an updated version of the vehicle shadow, wherein the updated version of the vehicle shadow is updated to reflect a current state of the vehicle based on the streaming data. (See rejection of claim 1)
wherein a node of the vehicle shadow corresponding to the first data stream is updated at the higher data update frequency, and wherein another node of the vehicle shadow corresponding to the second data stream is updated at the lower data update frequency; and provide, for display, using a user interface, the updated version of the vehicle shadow. (See rejection of claim 1)
Regarding claim 16, the above combination discloses the one or more non-transitory, computer-readable storage media of claim 15, wherein the streaming data comprises disaggregated data streams from a plurality of sensors of the vehicle, and wherein the disaggregated data streams are received asynchronously. (See rejection of claim 1)
Regarding claim 17, the above combination discloses the one or more non-transitory, computer-readable storage media of claim 15, wherein to generate the mapping, the program instructions, when executed on or across the one or more processors, further cause the one or more processors to: map sensor identifiers included in the streaming data corresponding to respective sensors of the vehicle to attributes of the schema corresponding to the respective sensors; and (See rejection of claim 2)
map the attributes of the schema to nodes of the vehicle shadow, wherein the nodes of the vehicle shadow are organized based on the received model. (See rejection of claim 2)
Regarding claim 18, the above combination discloses the one or more non-transitory, computer-readable storage media of claim 15, wherein the program instructions, when executed on or across the one or more processors, further cause the one or more processors to: provide a user interface for a vehicle shadow service, wherein the model is received from a user of the vehicle shadow service via the user interface. (See rejection of claim 10)
Regarding claim 19, the above combination discloses the one or more non-transitory, computer-readable storage media of claim 15, wherein the vehicle shadow is organized according to a tree-structure, wherein leaves of the tree- structure correspond to nodes of the vehicle shadow and are mapped to attributes of the schema for the vehicle shadow. (See rejection of claim 12)
Claim(s) 13 and 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Kumar (“Field Notes: Implementing a Digital Shadow of a Connected Vehicle with AWS IoT”) in view of, Kim (US PGPub 2006/0146776), Cella (US PGPub 2021/0272394) and Komiyama (US PGPub 2023/0206759)
Regarding claim 13, the above combination discloses the method of claim 7, but not the remaining limitations.
In the field of digital vehicle shadow integrations Komiyama teaches that the vehicle shadow is organized according to a graph-structure, wherein nodes of a graph of the vehicle shadow are mapped to attributes of a schema for the vehicle shadow, and wherein edges between the nodes of the graph indicate relationships between the attributes of the vehicle shadow. (As in rejection of claim 12, Komiyama Fig. 5 teaches that the shadow uses a mapped hierarchical graph tree-structure schema of the streamed vehicle sensor data. Here the individual data fields at the bottom of the hierarchy represent data nodes. The edges between nodes represent category inclusion relationships such as the battery state node being within an energy attribute schema.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have combined the above combination’s digital vehicle shadow system with Komiyama’s digital vehicle shadow system. The above combination teaches systems for implementing digital shadows for a connected vehicle including a schema for organizing vehicle parameters stored. Komiyama provides explicit teaching that the schema is organized in a graph structure. The combination constitutes the repeatable and predictable result of simply applying Komiyama’s teachings here for the purpose of using a well-known and widely-used method for organizing hierarchical information. This cannot be considered a non-obvious improvement in view of the relevant prior art here. Using known engineering design, no “fundamental” operating principle of the teachings are changed; they continue to perform the same functions as originally taught prior to being combined.
Regarding claim 20, the above combination discloses the one or more non-transitory, computer-readable storage media of claim 15, wherein the vehicle shadow is organized according to a graph-structure, wherein nodes of a graph of the vehicle shadow are mapped to attributes of the schema for the vehicle shadow, and wherein edges between the nodes indicate relationships between the attributes of the vehicle shadow. (See rejection of claim 13)
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Raphael Schwartz whose telephone number is (571)270-3822. The examiner can normally be reached Monday to Friday 9am-5pm CT.
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, Vincent Rudolph can be reached on (571) 272-8243. 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.
/RAPHAEL SCHWARTZ/Examiner, Art Unit 2671
Prosecution Insights