DETAILED ACTION
This action is responsive to the Applicant’s response filed 8/19/26.
As indicated in Applicant’s response, claims 21, 24-25, 34, 40, 43-44 have been amended. Claims 21-27, 29, 32-36, 40-44 are pending prosecution.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 21-27, 29, 32-36, 40-44 is/are rejected under § 35 U.S.C. 103 as being unpatentable over Gomes USPubN: 2019/0205115 (herein Gomes) in view of Lin et al, USPubN: 2019/0391800 (herein Lin) and Riemer et al, USPubN: 2010/0216509 (herein Riemer) further in view of Edwards John, AU 2016340028, 05-10-2018, 84 pgs (herein Edwards), David et al, USPubN: 2020/0174779 (herein David), and Teraoka et al, EP 3273350A1, 01-24-2018, 36 pgs (herein Teraoka).
As per claim 21, Gomes discloses an apparatus in a vehicle, comprising a memory configured to store instructions; and a processor coupled to the memory and configured to:
receive, from a software server, a notification message (e.g. receive by the on-board unit
information that identifies information update comprising metadata that specifies update version
information - claim 21, pg. 32; receiving from a cloud-based system information update
comprising metadata that specified update version information - para 0219; update 901 hold
information used in the process of receiving, applying, reporting notifications regarding updates - para 0197) comprising a software package identifier (update version, update metadata - para 0183; update identifier element 902 - para 0196) and that indicates a first software package on the vehicle includes a first software update (Fig. 7; para 0142-0143; enable AVs to maintain updated
software/firmware and data sets relied upon by the AV - para 0060);
request, from the software server (see Note1 from below) in response to receiving the notification message, first upgrade requirement information (para 0191; 0196-0197; Conditions required for Update 910 - Fig. 9 - Note1: collected meta-information obtained from various users or stakeholders - para 0190; step 804, Fig. 8 - by the cloud-based NW system for distribution upon request sent – see para 0193 - to other end-users, vehicle-owners or stakeholders in association report notification - para 0189, 0197 - and request of the operator/owner of the first AV- - para 0154, 0193 - for vehicle context information of the relevant metadata or update notification, that is then distributed with or without the actual update - para 0193-0194- to the requesting user/stakeholders - para 0193-0194 - whereby the distributed meta-information - e.g. profiles number of metadata items/elements – para 0155 - can instruct the users with a) information indicative of forked version updates or family of updates - para 0196 - b) on how a vehicle or functional part of a vehicle - control, navigation, entertainment, braking, air conditioning - can be affected by the update, c) a policy or conditions by which update can be applied to the operating state of the vehicle system, d) a specific physical location within which update can be provided - para 0196 - e) speed at which a moving vehicle would enable the vehicle to be updated -para 0191; “parked” or travelling – para 0184 - reads on requesting from the cloud service requirement information - including a, b, c, d, e from above - pertinent to an update identified with ID - see version and update identifier element 902 - para 0196) that is associated with the software package identifier (see above),
wherein the first upgrade requirement information indicates upgrade conditions (refer to conditions c) d) and e) from Note1 above) associated with a vehicle status (see braking state in b) location status in d) and speed state in e) from Note1; “parked” or travelling, specific physical/geographic region, geofence – para 0184) for starting a first over-the-air (OTA) upgrade using the first software package (see above; over-the-air … updates– para 0088),
wherein the upgrade conditions comprise a first status (status of speed at which the vehicle moves, parked/brake-on conditions with which update can be applied from conditions b), d),
or e) from above; conditions required for operating state in which the software application .. to be applied, within a certain … distance of a specific physical location … a.k.a. a geofence – para 0196) in which a software upgrade is allowed to be started (e.g. period of time when the AV is parked for planning, scheduling, coordinating the downloading of data from the Cloud- para 0104; within of a defined logical boundary – para 0196) and a second status in which a software upgrade is not allowed to be started (outside of a defined logical boundary or ‘geofence’ – para 0196; vehicle conditions for application of the … update had not been met – para 0203; Conditions met? No [Wingdings font/0xE0] 1022 - Fig. 10B),
receive, in a response message and without receiving the first software package, the first upgrade requirement information (receive user input identified update metadata with or without update data - para 0193; system may distribute an information identified in a request to components or systems that the stakeholder identifies at vehicles to be updated - para 0194; step 806 - Fig. 8) associated with the first software package in response to the request (Note2: returned identification
of vehicle in need for update and user request via a stakeholder to be sent from the cloud/provider
system, in terms of "update metadata" or update policy - para 0199 - with or without SW download
for a vehicle identified for such update reads on receiving as a response to the initial request,
upgrade requirement information - distributed 1004, Fig. 10A - contained in the metadata - see para
0183, 0196-0197; Conditions required for Update 910 - Fig. 9 - depicting conditions for updating a
specific update version being notified/indicated, without any accompanying SW download);
determine, based on a current vehicle status (see first status from above) of the vehicle obtained from one or more sensors (geo-location capabilities, motion detection sensors, position information, velocity information - para 0030, 0033) of the vehicle, that the vehicle is currently on the first status (1020: vehicle Conditions Met? Yes[Wingdings font/0xE0] 1024 – Fig. 10B; determine that the vehicle conditions for … information update had been met – para 0203);
start, based on confirmation the vehicle meeting a first status (Conditions Met? Yes[Wingdings font/0xE0] 1024 – Fig. 10B), the first OTA upgrade by obtaining the first software package from the software server (step 1024, 1026, 1028 – Fig. 10B).
Gomes does not explicitly disclose first and second upgrade requirement information in terms of upgrade conditions comprising:
(i) first field indicating a first status in which a software upgrade is allowed to be started and a second field indicating a second status in which a software upgrade is not allowed to be started,
(ii) wherein the first field and the second field, each comprises at least one of a geographical location of the vehicle, an environment in which the vehicle is located, and a driving status of the vehicle.
Lin discloses provision of a interchange structure to carry information between mobility clients in connection with a OTA mobility update service platform (MSP) for real time support/processing, remote data retrieving data ingestion and storage management and software update (para 0004-0012; Fig. 3B), the mobility client being a self-driving vehicle to provide sensor data to the OTA services platform, the transmitted data in form of a “digital twin” structure (para 0025) having field to specify identification as well as update/control state/info generated from the vehicle side (para 0094-0095; Fig. 2) including real-time data like vehicle speed (para 0163-0164; field indicator, RPM, speed – para 0203) such that, as structured, some extended data fields (fields 208f) can be configured for providing the MSP with personal information like history data, navigation data (destination locations) associated with operator of the vehicle client (para 0098), location data (latitude longitude, LiDAR, Global Navigation Satellite) as well as information as to whether a mobility client has entered or exited a geofence to trigger a SW package download (para 0100-0101; Fig. 5). Hence, real-time information implemented with fields of a structure to inform a MSP server with current state of a vehicle in terms of fields identifying the vehicle, a SW update, time stamp and the vehicle location information and fields specifying status on its GPS coordinates fulfilling geofence requirement for a OTA Software download entails structured fields for respectively indicating geofence entering status for permitting (or geofence exiting status for not permitting) a update and latest location of the vehicle to which the OTA update is to be applied or downloaded.
Riemer discloses information provided from a portable device user via a dashboard tracking real-time state of a vehicle via use of a communication message provided with fields by which information can be sent to external entities/sites associated with request for a status updates, the message fields provided by the tracking mobile user including latest of current speed, GPS data (para 0089, 0104) and visual relationship of the vehicle to a map (para 0148) as well as start location, target destination (para 0121); hence provision of communication from a vehicle monitoring user to a remote sites requiring such updates in form of message fields informing on location on a map, driving status or current speed of the vehicle is recognized.
Based on a remote site capture of condition fulfilling data (vehicle Conditions Met? Yes[Wingdings font/0xE0] 1024 – Fig. 10B; determine that the vehicle conditions for … information update had been met – para 0203) provided from the vehicle via an on-board unit (para 0198) based on sensor data and updates on latest positioning of the vehicle (para 0151, 0184, 0196) within/outside boundaries of a geofence in Gomes, it would have been obvious for one of ordinary skill in the art before the effective filing date of the invention to configure information updates provided to the server side regarding conditions or requirements to fulfill from the vehicle side so that the latest updates in meeting the OTA update conditions would be configured via a particular structure or message including fields according to which
1) a first field is provided with the structure for indicating a first in which a software upgrade is allowed to be started – field indicating the vehicle has established within a geofence boundaries – as in Lin use of extended data field - and/or a second field for indicating a second status in which a software upgrade is not allowed to be started, indicative that the vehicle location is not within coordinate of the geofence - as per the extended field in Lin,
2) wherein the first field and the second field, can each be linked to or include a geographical location of the vehicle, an environment in which the vehicle is located -as per a location or GPS data field in Lin - and a driving status of the vehicle – as per a field indicator in Lin; or field in Riemer message on a vehicle speed data; because
real-time update information obtained from a vehicle sensors to be collected into a message or transmission structure to respond to a OTA server/service platform request in order to inform the server with latest state of the vehicle in regard to a established condition fulfilling status as well as information about a most current physical location and driving/speed status of the vehicle as set forth above via a respective field included with the message or response structure generated from the vehicle side would facilitate the a OTA service with recognition and confirmation over the latest state on the vehicle complying to all conditions required for the OTA update so to allow the specific software update initiated from the server to be gathered and prepared for transmission to the vehicle, using field information as set forth above to match identification of the vehicle with information on its geographical location and physical state pre-established as requirements for the update to be dispatched and installed, the secure aspect of the OTA update paradigm optimizing network transmission bandwidth and rendering the overall vehicle software maintenance much more efficient in a long run.
Nor does Gomes explicitly disclose processor after determining the vehicle is currently on the first status to
(i) request, an upgrade decision and receive an instruction input indicating that the user confirms an upgrade of the first OTA upgrade in response to requesting the upgrade decision; and
(ii) start, based on confirmation of the first OTA upgrade, the first OTA upgrade (by obtaining the update package from the SW server).
As of (i)
Teraoka discloses OTA upgrade with checking of a current version would match element of
a vehicle coupled with interactive communication with the user (Fig. 8a) in form of pre-check for a
possible or non-necessary user approval, followed by a confirmation per a post-check performed subsequent to an update unit determining that an identified software version matches (Yes in S204 - para 0093) an element (e.g. ECU) of the vehicle, such that when user approval is necessary, a reply to this post-check confirms approval by user (S208, S209, S210 - para 0093; Fig. 8a) being received by the control unit in order for the control unit to proceed with the upgrade; hence human-computer
interaction interface after determining the vehicle is currently on the acceptable update status so to
enable receiving via a user/computer interaction, input indicative that the user confirms an upgrade
in the response to requesting a decision on an OTA upgrade is recognized; i.e. the update status
indicative of a vehicle status in which a SW upgrade is allowed to be performed.
Edwards discloses up-to-date notification/input provided to a remote service/administrator from a vehicle user after the vehicle is properly positioned in a parked area based on which the user can confirm/deny (para 0010, 0045) on the vehicle status and accordingly resolve any charge asked by the service, the latter resulting from confirmation received from the user (para 0032, 0186-0187) on said parked status, where determining the vehicle status is based on output of sensors (para 0034) monitoring accelerometer, gyroscope of the vehicle (para 0044)
As for (ii)
Gomes teaches that once update information is available, and made known on the vehicle side - On-Board-Unit information (para 0198-0199), the OBU module completes gathering the
information update as distributed by a cloud-based system, based on which the OBU module
validates components states raised by the requirements and obtain the update once the validation is
proper or satisfying (Fig. 10A, 10B, 10C); hence, obtaining vehicle status via a check on a fulfilment to requirement information by the vehicle thereby to obtain upgrade package then start the
first OTA upgrade by obtaining the first software package using a OBU from the vehicle side is
recognized.
In line with the above conditions to meet, David discloses OTA updater determining on save
state of an update on basis of vehicle status that meets a threshold of battery charge (para 0058) or a
condition that indicates a parked or moving state of the vehicle (para 0046-0047), all deemed
conditions acceptable for installing a SW update to the vehicle ECU (Fig. 4); hence remote update able to carry out a update upon receiving update to a parked or moving state of a target vehicle is recognized.
Analogous to Gomes setting of constraints on geophysical location/state of vehicle, examples of OTA upgrades for vehicle being dependent on mobility information indicative of a state of constraint or condition fed into a OTA service platform as specific location data are shown in Lin, wherein constraints on geofence associated with real-time geographical state (para 0134) of the target vehicle constitute part of the mobility requirement data SO to allow update by a OTA service to be carried out (para 0004, 0007-0008; para 0100-0101; Fig. 5, para 0139), according to which, preventive maintenance can be set on basis of certain vehicle component state and update information inputted by a mobility user in preparing fields of a structure that includes updated information including state of the vehicle, of the software update, speed and location information (Fig. 2; para 0098, 0100, 0203), according to which, vehicle-mounted sensors are arranged to communicate with the OTA service can relate information on types like temperature, pressure, light as well as Global positioning coordinates (para 0226-0227) being basis by which OTA updates can be applied to the subscribing clients (para 0233-0234).
Therefore, based on role/contribution by the vehicle owner and vehicle-side OBU as shown
above, it would have been obvious for one of ordinary skill in the art before the effective filing date
of the invention to coordinate information exchange between the cloud provider in response to
request for update by the vehicle in Gomes so that, after determining that vehicle is currently on the first status, the server side would further
1) request, an upgrade decision confirming a vehicle status – as in Edwards - and accordingly receive an input indicating that the user confirms an upgrade of the first OTA upgrade in response to requesting the user decision/confirmation- as per Teraoka and Edwards, and
2) start the update - as set forth in David and Lin - on basis of acknowledging that the vehicle is indeed in a first status - a geophysical location or a moving or parked status as shown in Edwards; because
server-side receipt of an explicit approval/consent deemed necessary from interactively
communicating with a vehicle user just prior to deploying the vehicle update can preclude litigation
issue caused by bypassing consent of a user or un-consulted modification of the user property,
thereby inflicting unnecessary detriment to the quality and SLA obligation of the cloud or OTA
service whereas meta-information or update profiles collected at a cloud service layer for SW
packages or version update as pre-established profile information for use by users or owners of
vehicle in terms of specific policy, constraints by which an intended update can be serviced or
provided to the vehicle on basis of a meta-requirement of a condition or status being met as set forth
above, would signify a server-client communication interaction where the user or vehicle side’s communication unit would return a user approval - as in Teraoka - or confirmation – as in Edwards - to the remote service with a real-time state of the vehicle as part of the user fulfilling a requirement/update condition pre-established from the received requirement metadata; and so, in the sense that only after the real-time status or physical, geographical state of the vehicle is being made known to the update provider/service, can the update be initiated by the server end for dispatch or deployment to the vehicle - as shown in the paradigm of update by Lin and David; that is, the most up-to-date status sent from the vehicle end (as in Edwards) instructing the update server on whether some criteria, condition has been fulfilled, the returned status being a condition of a fast-moving vehicle not permitting a update to be installed or state of a parked vehicle within a specific location enabling a particular version of update previously notified to be installed, i.e. a particular functional part of the vehicle initiated from remote to receive with a corrective package per an Over-the-Air distribution technique.
As per claim 22, Gomes discloses apparatus of claim 21, wherein the processor is further
configured to start, in response to the vehicle status of the vehicle being the first status (refer to
rationale B(ii) of claim 21), the first OTA upgrade (Gomes: over-the-air - para 0088, 0099) for the
vehicle using the first software package.
As per claim 23, Gomes discloses apparatus of claim 21, wherein the upgrade conditions
comprise a second status (physical location, identified physical/geographic regions, defined logical
boundary - para 0196; boundary of a "geofence", geographic location - para 0202), and wherein the
processor is further configured to determine not to start (one or more conditions that must exist or be
present before update may be applied - para 0196 - Note3: determination that a vehicle is not in a
very specific location or a geofence specified boundary - para 0202 - to grant an update reads on a
processor determination not to start a upgrade on basis of a second status information indicative of a
non- parked or moving state - see rationale B using David, and Lin), in response to the vehicle status
of the vehicle being associated with the second status, the first OTA upgrade (para 0088, 0099) for
the vehicle using the first software.
As per claim 24, Gomes discloses apparatus of claim 22, wherein the vehicle status being associated with the first status comprises the vehicle status being similar to the first status (relative state of the vehicle with respect to speed or stop - refer to claim 21; para 0184; vehicle is stopped traveling less than a certain threshold speed - para 0202).
As per claim 25, Gomes discloses apparatus of claim 23, wherein the vehicle being associated with the second status comprises the vehicle status being similar to the second status (para 0196; physical region defined by boundary of a geofence - para 0202; communication range surrounding the current physical location of the vehicle – para 0215).
As per claim 26, Gomes discloses apparatus of claim 22,
wherein the first status is a first status set comprising a plurality of statuses (parked, moving - para 0215; stopped, traveling less than a certain threshold speed, out of service, charging its batteries, traveling with no passengers, no cargo, traveling using autonomous propulsion, using collision avoidance - para 0202), and
wherein the vehicle status being associated with the first status comprises:
the vehicle status being associated with a third status (any one of the statuses from the set) in
the first status set (stopped, traveling less than a certain threshold speed, out of service, charging its
batteries, traveling with no passengers no cargo, traveling using autonomous propulsion, using
collision avoidance - para 0202);
the vehicle status being associated with all statuses (see para 0202) in the first status set; or
a quantity of statuses (traveling with no passengers, no cargo, with autonomous propulsion – see above) associated with the vehicle status in the first status set exceeds a quantity threshold (Note4: traveling with a certain speed or propulsion reads on a quantity of statuses that exceeds a threshold speed limit such as zero).
As per claim 27, Gomes discloses apparatus of claim 23, wherein the second status is a
second status set comprising a plurality of statuses, certain distance from a physical location or
within a geofence - para 0184, 0202 - Note5: multitude of locations considered relative to a specified
spot or situated within a boundary reads on plurality of statuses or set thereof bearing effect of the
second status), and
wherein the vehicle status being associated with the second status comprises:
the vehicle status being associated with a fourth status (see any location relative to a spot or
within a boundary from above) in the second status set (see Note5);
the vehicle status being associated with all statuses ( see any locations defined relative to a
physical sport or a boundary - see Note5) in the second status set; or
a quantity of statuses associated with the vehicle status in the status set exceeds a quantity threshold (see para 0184 - Note6: statuses associated with a vehicle outside a geofence reads on quantity of statuses that exceed a physio- geographic quantity threshold, the latter being the boundary of the fence)
As per claim 29, Gomes discloses apparatus of claim 21, wherein the geographical location
is a parking lot (parking location - para 0152), an urban road (para 0068, para 0109), a traffic control
road section (para 0072), or a high-speed road section (highway - para 0082),
wherein the environment is a daytime (a day - para 0122), a nighttime (end of the day - para
0109), a congested road section (congested road - para 0110), or a body temperature (temperature of
the interior of the vehicle - claims 3, 10, 17 pg. 32-33) of the vehicle, and
wherein the driving status is a braking state(driving-related update such as a braking system - para 0185), a moving state, a high-speed state, a low-speed state, or a parking state (parked, moving, stopped - para 0215; stopped and parked to permit the updates to be safely performed - para 0216)
As per claims 32-33, Gomes does not explicitly disclose apparatus of claim 21, wherein the processor is further configured to
(i)obtain the first upgrade requirement information based on the software package identifier,
upgrade requirement information, or description information in the first software package after obtaining the first software package.
(ii) obtain the first upgrade requirement information by requesting the software server based on the notification message from the software server.
As for (i)
The AV system in Gomes needs access to network-related information and requirements
thereof which the AV can take into consideration in order to prioritize application needs according to throughput and latency state of the network (para 0135; access to relevant context information require levels of connectivity network bandwidth requirements regarding network latency the AVs are able to tolerate - para 0138; para 0140, 0143) as requirements to fulfill or meet (para 0150) in order to properly conduct a service or an emergency need, where configuration information for deploying updates to the AV include awareness over requirements set by stakeholder and security type requirements (para 0176, 0178, 0181; level of security required for any AV application and/or
service - para 0091) that would enable operating the service platform in a safe manner, as well as environment’s requirements (para 0021) and regulatory requirement that facilitate enforcement of a update (para 0217). Gomes also discloses family-related information or metadata on order policy element and versioning associated with an update ID, which include conditions under which a update can be permitted (para 0196), including stopped or propelled status of the vehicle.
As for (ii)
Obtaining information for properly updating a client device or vehicle via a request directed
at cloud server is shown in Gomes where the cloud service has at its disposition a collection of
information that helps the services to help configuration, implementing and monitoring of software
updates (para 0039-0040) including backbone infrastructure for provisioning information on modes
of operation (para 0044), the server entities - herein referred as (*) - configured to communicate
information about received software and firmware as well as configuration data corresponding to
received SW or firmware (para 0215) as well as restriction type data that would disallow/permit a
vehicle to have a update (para 0216)
Therefore, based on the OTA support for vehicle update and notification of update thereby in
Gomes server system, it would have been obvious for one of ordinary skill in the art before the
effective filing date of the invention to implement gathering of requirement at the AV system in the
context of an update version (ID) to consider by the AV processor for updating in Gomes approach
so that the vehicle processing system would be configured to
1) obtain the first upgrade requirement information based on the software package identifier
(as set forth above), upgrade requirement information (as state of a vehicle being parked or in
motion as set forth above) as well as conditions on NW latency, throughput or security state for safe
configuration of an AV deployment), or description information - order policy information as from
above - in the first software package after obtaining the first software package; the vehicle system
2) obtain the first upgrade requirement information by requesting the software server - as set
forth above in (*) - based on the notification message from the software server regarding availability
of a update ID; because
capability of an update process and manager to be aware of environment, security conditions
or network performance, BW and latency would facilitate prioritization of I/O settings and
deployment configuration that best suit to the NW and traffic conditions in order to optimize NW
and security- related deployment of an update or most likely match to safe operation or environment
requirement of a host platform, whereas for a given update ID the related requirement such as a
required state of a vehicle or policy-related metainformation obtained from a server entity as set
forth above would enable a update manager to authorize or deny a update that can only be safe when
the vehicle is in a stationary state, while ensuring that server-stored security policy associated with
deploying the update would not be infringed upon, and so, in conjunction with configuring deployment of an update version for AV installation.
As per claim 34, Gomes discloses a method for a vehicle, comprising:
receiving, from a software server, a notification message comprising a software package
identifier and indicating that a first software package on the vehicle includes a software update;
requesting, from the software server in response to receiving the notification message, first upgrade requirement information that is associated with the software package identifier,
wherein the first upgrade requirement information indicates upgrade conditions associated with a vehicle status for starting a first over-the-air (OTA) upgrade using the first software package,
wherein the upgrade conditions comprise a first field indicating a first status in which a software upgrade is allowed to be started and a second field indicating a second status in which a software upgrade is not allowed to be started, and
wherein the first field and the second field, each comprises a geographical location of the vehicle, an environment in which the vehicle is located, and a driving status of the vehicle;
receiving, in a response message and without receiving the first software package, the first upgrade requirement information associated with the first software package and in response to the request;
determining, based on a current vehicle status of the vehicle obtained from one or more sensors of the vehicle, that the vehicle is currently on the first status;
requesting, after determining the vehicle is currently on the first status, an upgrade decision;
receiving an instruction input indicating that the user confirms an upgrade of the first OTA upgrade in response to requesting the upgrade decision; and
starting, based on confirmation of the first OTA upgrade, the first OTA upgrade by obtaining the first software package from the software server.
( All of which having been addressed in claim 21)
As per claims 35-36, refer to rejection of claims 22-23 respectively
As per claim 40, Gomes discloses a computer program product comprising computer-executable instructions that are stored on a non-transitory computer readable medium and that, when executed by a processor, cause an apparatus of a vehicle to:
receive, from a software server, a notification message comprising a software package identifier and that indicates a first software package on the vehicle includes a software update;
request, from the software server in response to receiving the notification message, first upgrade requirement information that is associated with the software package identifier,
wherein the first upgrade requirement information indicates upgrade conditions associated with a vehicle status for starting a first over-the-air (OTA) upgrade using the first software package, wherein the upgrade conditions comprise a first field indicating a first status in which a software upgrade is allowed to be started and a second field indicating a second status in which a software upgrade is not allowed to be started, and
wherein the first field and the second field each comprises a geographical location of the vehicle, an environment in which the vehicle is located, and a driving status of the vehicle;
receive, in a response message and without receiving the first software package, the first upgrade requirement information associated with the first software package in response to receiving the request;
determine, based on a current vehicle status of the vehicle obtained from one or more sensors of the vehicle, that the vehicle is currently on the first status;
request, after determining the vehicle is currently on the first status, an upgrade decision;
receive an instruction input indicating that the user confirms an upgrade of the first OTA
upgrade in response to requesting the upgrade decision; and
start, based on confirmation of the first OTA upgrade, the first OTA upgrade by obtaining the first software package from the software server.
( All of which having been addressed in claim 1)
As per claims 41-42, refer to rejection of claims 22-23 respectively.
As per claim 43, Gomes discloses computer program product of claim 41, wherein the vehicle status (“parked” or travelling – para 0184) being associated with the first status comprises:
the vehicle status being in a status range (threshold distance of a specified location - para
0196; threshold speed - para 0202) in which the first status is used as a reference (see distance of a
specified location - para 0184; threshold speed - para 0202; physical location, velocity of the vehicle
- para 0220; sensors in the region within range surrounding a current location - para 0215; stopped
and parked to permit the updates to be safely performed - para 0216) and a preset status threshold is
used as an offset (e.g. within a certain distance of a specified location - para 0184; level of charge
drops below a certain threshold - para 0114) .
As per claim 44, Gomes discloses computer program product of claim 42, wherein the vehicle being associated with the second status (physical region defined by boundary of a geofence - para 0202) comprises: the vehicle status being in a status range (range surrounding a current location - para 0215) in which the second status is used as a reference (specified location – para 0184) and a preset status threshold is used as an offset (e.g. within a certain distance of a specified location - para 0184)
Response to Arguments
Applicant's arguments filed 8/19/26 have been fully considered but they are not persuasive. Following are the Examiner’s observations in regard thereto.
The Applicant has submitted that Teraoka fails to remedy to the deficiency of Gomes in regard to the feature recited as “after determining, based on … vehicle status from one or more sensors …that the vehicle is currently on the first status” since the confirmation in Teraoka is based on version-match determination, not input received after determining that the vehicle has entered a first status (Applicant's Remarks pg. 14-15). The Teraoka reference is to show the update provided remotely can be carried out only after user confirmation, when the feature recited as “ after determining, based on … vehicle status from one or more sensors …that the vehicle is currently on the first status” has not been addressed using the confirmation feature by Teraoka. The argument is deemed largely non-persuasive in demonstrating the Teraoka fails to teach a alleged missing feature in Gomes.
Further, the added limitations in claim 1 has been addressed with a adjusted ground of rejection that does not solely rely on Teraoka as alleged from above; rendering any discussion about any flaw of the Office action using Teraoka largely misplaced.
(B) The Applicant has submitted that David and Lin cannot make up to the deficiencies by Gomes in that neither David and Lin use sensors to determine first status of the vehicle thereby to request that the update be started (Applicant's Remarks pg. 16 bottom). It is clear from the teachings by David and Lin as used in the last office action, that a update start can be approved upon receipt of vehicle status on speed or parked condition; or on positioning within a predetermined location. However, the amendment to claim 1, for instance, has triggered another 103 ground of rejection that extends beyond the teaching of David and Lin to address the latest limitations (emphasis here) to this claimed scenario of “start an upgrade” based on “obtained first status”. The Applicant’s remark on David and Lin is therefore deemed largely not commensurate with the most current state of prosecution.
(C ) The Applicant has submitted that Teraoka, David, Lin and Gomes (Applicant's Remarks pg. 17) fail to teach upgrade conditions provided as first and second field in which software is allowed to be started; notably when Gomes provides metadata in form of a generalized list of pre-requisites, which is not first field and second field as currently claimed (Applicant's Remarks pg. 20-21). Relying on merits of newly added limitations is deemed largely MOOT and otherwise statutorily untenable.
(D) The Applicant has submitted that Teraoka, David and Lin do not make up for Gomes in teaching upgrade conditions as comprising first field and second field as now expressed in the claimed language (Applicant's Remarks pg. 21 bottom). ). Relying on merits of newly added limitations is deemed largely MOOT.
In all, the claims as amended stand rejected as set forth above.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Tuan A Vu whose telephone number is (571) 272-3735. The examiner can normally be reached on 8AM-4:30PM/Mon-Fri.
If attempts to reach the examiner by telephone are unsuccessful, the examiner's supervisor, Chat Do can be reached on (571)272-3721.
The fax phone number for the organization where this application or proceeding is assigned is (571) 273-3735 ( for non-official correspondence - please consult Examiner before using) or 571-273-8300 ( for official correspondence) or redirected to customer service at 571-272-3609.
Any inquiry of a general nature or relating to the status of this application should be directed to the TC 2100 Group receptionist: 571-272-2100.
/Tuan A Vu/
Primary Examiner, Art Unit 2193
Septembre 5, 2026
Prosecution Insights