DETAILED ACTION
This action is responsive to the Applicant’s response filed 3/31/26
As indicated in Applicant’s response, claims 21, 27, 34, 40 have been amended, and claims 1-20, 28, 30-31, 37-39 cancelled. Claims 21-27, 29, 32-36, 40-44 are pending a next office action.
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 David et al, USPubN: 2020/0174779 (herein David), further in view of 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 - 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,
wherein the first upgrade requirement information indicates upgrade conditions (refer to conditions c), d) and f) from above) associated with a vehicle status (see braking state in b) location status in d) and speed state in e) from Note1) for starting a first over-the-air (OTA) upgrade using the first software package (see above),
wherein the upgrade conditions comprise a first status (refer to 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) that indicates the vehicle status in which a software upgrade is allowed (e.g. period of time when the AV is parked for planning, scheduling, coordinating the downloading of data from the Cloud- para 0104) to be started and comprises at least one of a geographical location (a location in the network of moving things at which the update data may be accessed - para 0183; update to be applied vehicle physical location, identified physical/geographic regions, defined logical boundary - para 0196) of the vehicle, an environment in which the vehicle is located (area in which AV system is installed - para 0166; specified physical location - para 0184; particular geo-fence or distance of a specified physical location - para 0184), or a driving status of the vehicle (AV is parked, charging mode - para 0154; … to perform the particular update vehicle must be in a particular "state", parked or traveling, or below a specified speed - para 0184; parked mode, moving mode - para 0152; see upgrade conditions from above);
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)
A) Gomes does not explicitly disclose obtaining upgrade information associated the first
software package in terms processor configured to:
(i) request an upgrade decision from a user using an output of a human-computer interaction interface after determining the vehicle is currently on the first status;
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 first software package from the software server.
As for (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 subsequent to
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.
As for (ii)
Gomes teaches that once, on the vehicle side, On-Board-Unit information is made known and update information is available (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 check in regard to compliant fulfilment to requirement information 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 an update software of the vehicle ECU (Fig. 4)
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 which includes state of tire, spark plugs, battery, transmission, cooling or steering system, such that 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).
That is, requirement conditions that vary from one type of update to a next type based on the
above is recognized to trigger an OTA maintenance/update service to be deployed.
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 meta-information for dispatch by the cloud provider in response to
received request for update requirement by the vehicle owners/users in Gomes so that responsive to
1) confirmation by the user received via the upgrade control interface as set forth in Teraoka OTA upgrade, after determining that the vehicle has entered a first status, and
2) receipt of the vehicle state meeting this requirement information as part of the
requirement or conditions by which the vehicle can be granted an update service or first OTA upgrade, the update provider can start a first OTA upgrade in terms of obtaining the first software package from the software server based on the received vehicle status and deploying the package thereto, on basis of acknowledging that the vehicle is being in a first status such a geophysical location or a moving or parked status - as set forth in David and Lin; 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 preestablished 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
communication unit would return a user approval - as in Teraoka - or respond to the remote service
with a state of the vehicle as part of the user fulfilling a requirement set or learned 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 as meeting a condition,
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 status sent from the vehicle end 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 A(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 A 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 (see 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);
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) ; or the vehicle status being the first status (see above).
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); the vehicle status being in a status range in which the second
status is used as a reference and a preset status threshold is used as an offset (e.g. within a certain
distance of a specified location - para 0184); or the vehicle status being the second status (see above).
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 do need access to network-related information and requirements
thereof the AV can tolerate 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) in order to operate the service platform in a safe manner, as well as environment
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 condition 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 help 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 1/0 setting and
deployment configuration that best suits to the NW and traffic conditions in order to optimize NW
and security- related deployment of a 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 in the course of configuring deployment of a
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 status that indicates the vehicle status in which a software upgrade is allowed to be started and comprises at least one of a geographical location of the vehicle, an environment in which the vehicle is located, or 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 without receiving the first software package and in response to the request;
requesting an upgrade decision from a user using an output of a human-computer interaction interface after determining the vehicle is currently on the first status;
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 status that indicates the vehicle status in which a software upgrade is allowed to be started and comprises at least one of a geographical location of the vehicle, an environment in which the vehicle is located, or 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;
request an upgrade decision from a user using an output of a human-computer interaction interface after determining the vehicle is currently on the first status;
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 21)
As per claim 41, refer to rejection of claim 22.
As per claim 42, refer to rejection of claim 23.
As per claim 43, refer to rejection of claim 24.
As per claim 44, refer to rejection of claim 25.
Response to Arguments
Applicant's arguments filed 3/31/26 have been fully considered but they are not persuasive. Following are the Examiner’s observations in regard thereto.
(A) Applicants have submitted that Teraoka does not remedy to Gomes in that receiving a confirmation from a user as cited by the Office Action is not performed “after determining that the vehicle is currently on the first status” (Applicants Remarks pg. 14), particularly in terms of an user approval based on state of the vehicle determined as being parked, in a geofence or traveling below a speed limit (Applicants Remarks pg. 14). Gomes has been cited as teaching determination of first status of the vehicle in a parked state, in a geofence or in a moving speed. The rationale using Teraoka is to render obvious the limitation “confirmation by the user received via the upgrade control interface, after determining that the vehicle is currently on the first status”. In this language the first status of the vehicle being based upon includes that of matching a version destined for upgrade, in that the update status is indicative of a vehicle being in a status in which a SW upgrade is allowed to be carried out. Thus, interacting with user to obtain the user approval subsequent to determining that the vehicle is currently set with a first status is recognized in Teraoka, especially when an explicit language of the claim recites “upgrade conditions comprise a first status that indicates the vehicle status in which a software upgrade is allowed to be started” (emphasis here). Hence, the teachings provided from Teraoka in terms of determining a SW version to be proper matches with the first status as described in the claim. The Applicant’s argument to dismiss Teraoka regarding the obviousness of the user-confirmation limitation being received “after determining that the vehicle is currently on the first status” is thus deemed largely inconclusive.
(B) Applicants have submitted that Gomes via Figl 8, 10A-10C discloses distribution of information update identified by stakeholder, whereas claim 21 recites SW package is not obtained until after (i) a requirement is received, (ii) the vehicle fulfills a first status, and (iii) after a user confirms, and that makes the gathering of information update by Gomes different from user-confirmation triggering a download, based on which to start the first OTA upgrade as claimed (Applicants Remarks bottom pg. 16 top pg. 17).
It is abundantly unclear as to which part of the claim recites not obtaining SW package into a vehicle only until after conditions (i), (ii) and (iii) have been fulfilled. The argument appears to be fetching information from outside the actual language of the claim; thus, no merits can be properly ascribed to the argument. The obviousness in obtaining a user confirmation interactively upon determination of a first status by which the vehicle is deemed appropriate to receive an upgrade has been set forth in claim 1 with a 103 rejection. As the claim language recites “request an upgrade decision from a user using an interaction interface after determining the vehicle is currently on the first status” and in view of how the concept of “first status” has been described in claim 1, the arguments directed at Teraoka to dismiss validity of the rationale A in claim 1 has been set forth in section A (from above) as non-persuasive.
(C ) Applicants have submitted that Lin, David, Teraoka do not make up for the shortcomings of Gomes, as no part in the Examiner action evidences that the user confirmation is being triggered based on vehicle status as dictated by the chaining of claim elements construction. The feature being rendered obvious revolves mainly around the language of “request an upgrade decision from a user using a interaction interface after determining the vehicle is currently on the first status” whereas the first status has been described via “upgrade conditions comprise a first status that indicates the vehicle status in which a software upgrade is allowed to be started” “. The alleged chaining of claim elements by the argument is deemed insufficiently grounded.
The allegation that Lin, David and notably Teraoka fail to teach (Applicants Remarks pg. 17) this user confirmation (being subsequent to determining a vehicle being in a first status) has been addressed in section A, where it is determined that Teraoka reasonably teaches that obtaining the user confirmation is subsequent to determining that a first status for the vehicle has been fulfilled.
Therefore, the obviousness rationale as set forth in claim 1 will stand.
Conclusion
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any extension fee pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
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
April 21, 2026
Prosecution Insights