DETAILED ACTION
This action is responsive to the Applicant’s response filed 2/25/26.
As indicated in Applicant’s response, claims 1, 6, 11-14 have been amended, and claims 2-5, 7-9 cancelled. Claims 1, 6, 10-14 are pending a next office action.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claim 1 is/are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more. Claim(s) 1 is/are directed to an Abstract Idea. The claim(s) does/do not include additional elements that are sufficient to amount to significantly more than the judicial exception because of the following 2-step (Alice/Mayo) analysis.
Step I:
Claim 1 statutorily belongs a process/method category.
Step IIA:
Prong One:
The limitations recited in a highly general expression such as “determine” (whether the software … is a specific update); “having determined that” ( the … update is not specific…), “having determined that” ( the update … is specific) are viewed as activities that can be performed by a human via a mental process or use of pen/paper; as a human can make mental determination based on received information obtained via a computer or UI. Thus, the method is directed to a Judicial Exception of a Abstract Idea type that is founded on activities of a mental process.- MPEP 2106.04(a)
Prong Two:
The elements recited as “receive” ( from the vehicle a request); “transmit update data” , “not transmit the update data” and “instead, transmit … request information”, “receive … the download request again”, “transmit the update data” are generally understood as extra-solution routines being either pre-activities known to obtain, gather, collect information for enabling the mental process of determining, judging, assessing or re-organizing the data being collected, or post-activities that are well-understood routines to send, display, recompile or restructure derivation or data generated from the mental process. These activities (collecting and sending) do not meaningfully transform a technical field (vehicle update) or specifically improve a technical issue in the field of application (such as vehicle update) in which the mental process operates; hence, these extra-solution activities cannot integrate the Abstract Idea per prong One into a practical application. MPEP 2106.05(a), (c), (g)
Step II B:
The additional elements such as “receive” ( from the vehicle a request); “transmit update data” , “not transmit the update data” and “instead, transmit … request information”, “receive … the download request again”, “transmit the update data” are re-evaluated with the additional concepts of “data related to software update”, “download”, “specific software update”, “information based on which the vehicle is to be guided … by a navigation system”, “predetermined place … where a vehicle service is receivable”, and it found the linking between the additional elements of “receive”, “transmit”, “not transmit”, “receive … request again”, “transmit” and the additional concepts from above only depict a field of use in which pre-activity of receiving or post-activities of receiving again or transmitting support the mental process of “determining” as set forth in step IIA. For instance, the generic transmitting of update data (interpreted without any internal coordination by a computer) - as basis to guide a vehicle - does not actually transform computer functionality associated with vehicle/SW update field; nor does this transmitting improve efficiency of a computer domain respective to endeavor to resolve a technical issue related to update installation. Likewise, the ‘receiving” of request understood as a pre-activity cannot be viewed as an explicit, sub-normal transformation to the computer in the field of SW update; hence the additional elements of “receive” and “transmit” fail to render the Abstract Idea from stepIIA in a way for it to amount significantly more than itself. MPEP 2106.05(a)(c),(e ) and (g)
Claim 1 is deemed non-eligible under the 35 USC § 101 statute.
Claim 6 is/are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more. Claim(s) 6 is/are directed to an Abstract Idea. The claim(s) does/do not include additional elements that are sufficient to amount to significantly more than the judicial exception because of the following 2-step (Alice/Mayo) analysis
Step I:
Claim 6 recites a vehicle/apparatus category of subject matter
Step IIA
Prong One: the elements recited in a high level of generality such as “when the software update … is determined … not to be specific”, “when the … update to be executed is determined”, “determine whether the vehicle has moved”, “when the vehicle has been determined … predetermined place” are all construed as activities that can be performed by a human via a mental process or pen/paper. Thus, the apparatus claim is directed to a Judicial Exception of a Abstract Idea type that is founded on activities of a mental process.- MPEP 2106.04(a)
Prong Two: the limitations such as “transmit a download request” “receive the update data from the center”, “receive … request information based on which …vehicle is to be guided”, “guide the vehicle”, “transmit the … request again”, “receive update data”, and “execute the software update” at predetermined place being “a service area” are viewed as mere pre-activities to gather data for a process of determining, or post-activities relying of data resulting from a mental process of determining, the post-activities not recited as limitation that particularly constrain the update process via use of a computer in the field of use or NW service to support a vehicle update, or would further enhance the mental process of determining as set forth above. The step “guiding” and “executing the software update” when construed from a broad claim language are mere well-understood extra-solution activities that support a mental process of determining that a vehicle “is to be guided” to a area of service. Hence, these well-understood post-activities following state of a abstracted determination made in a vehicle update field of use does not add more to the mental process in this field of use; nor can they integrate the Abstract Idea into a practical application. MPEP 2106.05(a), (c), (g)
Step IIB:
The additional elements such as “transmit a download request” “receive the update data from the center”, “receive … request information based on which …vehicle is to be guided”, “guide the vehicle”, “transmit the … request again”, “receive update data”, and “execute the software update” in light of the high-level of generality of their expression in the claim are at best viewed as extra-solution activities to the Abstract Idea of step IIA, the latter construed as pre-activity (transmit a request, receive update data) to a determining step, or post-activity (receive request information; guide the vehicle, transmit … request again; receive update data; execute update) that are subsequent to a determining step. When considering these extra-solution activities for any particular linking with the SW update field, “vehicle service area”, the use of processors, and execution of update, the additional elements do not appear to put forth a useful transformation to this field of use when they are only provided to assist or make use of a determining step (or mental process) in form of pre or post activities; thus, the additional elements as identified above do not add significantly more to the Abstract Idea itself. MPEP 2106.05(a), (c), (g)
Claim 6 is deemed non-eligible a subject matter under the 35 USC § 101 statute.
Step IIB analysis of dependent claims.
Claim 10: recites displayof a predetermined place from received request information; and this constitute a insignificant post activity that cannot particularly innovate the Abstract Idea in the field of use where it operates.
Claim 11: describe content of a regulation information as guidance from effect of guiding the vehicle; but effect of guiding is after the fact that the regulation information is received; hence the regulation information is dependent of a mental (determining) process (software update is to be executed); which cannot be viewed as rendering the Abstract Idea significantly more than itself.
Claims 12-13 relate to nature of a service area and a required face-to-face explanation for a OTA campaign; and this additional static, extra-curriculum type of information fails to add significantly more to the Abstract Idea operating in the SW update field of use.
Claim 14: recites possibilities for predetermined places to be provided on display and use of processor(s) to receive user selection from the displayed places and to set route by which the vehicle can be moved. These activities (display, route via use of a generic computer) are deemed extra-solution activities that rely of result from a determining step in the base claim; hence, cannot amount significantly more to the Abstract Idea of step IIA itself.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claim 1 is/are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention.
In fact, the feature recited as “when having determined that the software update to be executed is not the specific software update, transmit the update data to the vehicle” is not found as having reasonable description in the Specifications to convey that the inventor is in possession of this limitation when the invention was filed. Scanning the Disclosure, it is found that in case that specific software update determination is positive, “request information” is transmitted to the OTA master of the vehicle (para 0007-0008) whereas transmitting of “update data” is based on whether a vehicle is positioned at a predetermined place (para 0007, 0010-0011). Para 0023-0024 describes activation phase (e.g. verifying update version) subsequent to receiving the update data downloaded from the OTA center. No description is about transmitting update data being based on, responsive to any determination that software update is not the specific update. One skill in the art would not be able to make use of the invention and reproducing the above feature, necessarily when the Disclosure has not provided reasonable teaching for this feature.
Claim 1 is rejected as not fulfilling the description requirement under 35 U.S.C. 112(a) ruling. For prosecution of merits, the transmitting of update data is construed as based on determination that the vehicle is fulfilling requirement for the SW download to be permitted.
Claim 6 is also rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention.
In fact, claim 6 recites “when software update to be executed is determined … not to be a specific software update, receive the update data from the center” and as set forth above, this transmitting and receiving of “update data” into a vehicle is nowhere described as responsive to determination that software update is not a specific software update as recited.
Claim 6 is rejected as not fulfilling the description requirement under 35 U.S.C. 112(a) ruling
Dependent claims analysis in regard to the 112(a) rejection.
Claim 10: recites display of a predetermined place from received request information; and this does not remedy to the lack of description incurred by the base claim 6.
Claim 11: describe content of a regulation information as guidance from effect of guiding the vehicle; but effect of guiding using this regulation information does not remedy to the lack of description deficiency in claim 6.
Claims 12-13 relate to nature of a service area and a required face-to-face explanation for a OTA campaign; and this additional static, extra-curriculum type of information fails to cure to the disclosure deficiency of claim 6.
Claim 14: recites possibilities for predetermined places to be provided on display and use of processor(s) to receive user selection from the displayed places and to set route by which the vehicle can be moved. These activities (display, route via use of a generic computer) cannot be construed as overcoming the lack of description deficiency in claim 6.
Hence, claims 1 and 6 are rejected under 35 USC § 112(a) statute for not fulfilling the description requirement.
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 1, 6 is/are rejected under § 35 U.S.C. 103 as being unpatentable over Gomes, USPubN: 2019/0205115 (herein Gomes) in view of Ju et al, USPubN: 2020/0409678 (herein Ju) and Turley, USPubN: 2020/0139929 (hereinTurley)
As per claim 1, Gomes discloses a center (Cloud service component DevCenter manage implementation of software updates - para 0040) configured to transmit update data (information update comprising metadata that specified update version information - para 0219; scheduling and/or coordinating the downloading by the AV of data from the Cloud - para 0104; make the operation of service "over-the-air" update mechanisms while enabling deployment, configuration functions as managed services - para 0099; distributes information update 806, 808 - Figure 8; update pushed from the cloud - para 0183) related to a software update (e.g. update that is to be distributed to software, firmware and/or configuration for components and/or systems of vehicles - para 0191) of an in-vehicle device (in-vehicle devices - para 0181; vehicle components 1018- Fig. 10A; updates for one or more of software, firmware, data for components and/or systems of the vehicle - para 0215; receive by the on-board unit information that identifies information update comprising metadata that specifies update version information - claim 21, pg. 32; in-vehicle systems device or system of a vehicle that requests an update the element, device may comprise a camera, engine control unit (ECU, a sensor - para 0184) mounted in a vehicle (para 0142-0143; Fig. 7; vehicles that are under management by stakeholder - para 0191; software, firmware applied to the identified vehicles to which the update is to be applied - para 0192),
the center (Cloud services and DevCenter, Figure 1) comprising one or more processors configured to:
receive, from the vehicle, a download request (requests of information update 806 -Fig. 8;
information updates, update metadata and update data for vehicles - para 0010; Update ID, Update
Version, Affected Vehicle application 906; conditions required for Update 910(e.g. Vehicle/system
state, location, velocity or speed, AV capacities - Fig. 9; requests of an information update, that the
stakeholder identifies as vehicles to be updated - para 0193-0194; update an affected vehicle - para 0196) for the update data related to the software update;
determine, based on stored regulation information (e.g. policy element 908 define an order and conditions required for update element define operating state in which the software application vehicle system must be for information to be applied, conditions required for update available via the OBU certain type of environment characteristics must be present amounts of local storage must be available particular software application or vehicle system may not be present - para 0196) that indicates one or more characteristics (e.g. context parameters such as wired/wireless communication technologies and methodologies to be used to download the update to be used in the software or firmware, data configuration update mechanism update order policy update order defined by the responsible stakeholder maintenance of the defined order because updates distributed later in time may depend on updates distributed earlier update internal data representation must be applied before all updates which use the newer internal data representation - para 0183; metadata may indicate the capabilities that must be available on the AV in order to support functionality of the particular update when the firmware is running, metadata that requires Internet access particular services must be present on the AV- para 0184; per-software-application permission policy may be subject to both metadata used to define the relative order in performing updates so that some software application updates may preempt other updates - para 0185; update order policy version element of the metadata of the information update must be later in time or order of a particular version identifier of the firmware – para 0201) of the software update itself, whether the software update to be executed is a specific software update (update version - Fig. 9; version of update - para 0192; update version element 904 – para 0196; version of update metadata - para 0199);
when having determined that the software update to be executed is not the specific software update (refer to USC 112(a) rejection), transmit the update data to the vehicle (refer to transmit the update data from below; see distributes 1024 – Fig. 10B);
when having determined that the software update to be executed is the specific software update (update version - Fig. 9; version of update - para 0192; update version element 904 – para 0196; version of update metadata - para 0199), not transmit the update data (see request information as following) to the vehicle and instead transmit to the vehicle (distributed to the vehicle … with update metadata 802, distribution 806, 808 – Fig. 8) request information (e.g. update metadata 901 conditions required vehicle system must be for update to be applied such as state of a vehicle physical location within distance of the specific physical location within/outside of a boundary "geofence" – para 0196 ) based upon which (e.g. vehicle navigation one or more conditions such as location within a certain threshold distance of a specific location a defined logical boundary (aka "geofence") - para 0197; step 1018 – Fig. 10A; step 1020 – Fig. 10B – Note1: policy-related and update metadata
indicating that vehicle must be parked or operating within a boundaries or physical separation
threshold from a geofence or geographical location, physical location on basis of navigation systems
applications stored on the AV reads on distributed request/guidance information to the vehicle as metadata depicting or prescribing that the vehicle be in a predetermined place as provided/instructed under a navigation system or GPS app - see Mobile App geo-location capabilities e.g. GPS - para 0030; mobile AP - para 0035; services supported by a system of the present disclosure Global Positioning system – para 0084) the vehicle is to be guided to a predetermined place by a navigation system (see GPS app per Note1) included in the vehicle; and then
transmit the update data (sending the information update - para 0219; receive the information update from the cloud-based system - para 0220; distributes 1024 – Fig. 10B; apply information update 1026, 1028 – Fig. 10B) to the vehicle, wherein the predetermined place is a vehicle service area, which is an area where a vehicle service is receivable (Note2: update metadata from the cloud service specifying requirement for the AV to be parked within specific physical location within/outside of a boundary "geofence" para 0196 - specifying a geographic location within whose distance or boundaries a vehicle is to park/stop for permitting a update service to be safely performed or delivered reads on predetermined service area having geophysical properties or boundaries for a vehicle to comply to in order to receive the update service) or a network connection area (service 507, 508, 509,510 - Fig. 5; connection manager block 506 – para 0146-0147; cellular service, CDMA, TDMA, GSM, 3G, 4G, LTE, 5G - para 0151).
A) Gomes does not explicitly disclose center configured to
receive, from the vehicle and when the vehicle has moved to the predetermined place based
on the request information, the download request again; and then transmit the update data to the
vehicle.
Gomes disclose on-board unit of a given vehicle operatively sending notification to the
cloud-based system about operating conditions of a first or second vehicle such as condition including a physical location of the vehicle or whether one system is providing service to occupant of a vehicle (para 0220); hence real-time notification sent from the vehicle on-board unit in updating a remote system with state of applying an update or latest physical state or location of the vehicle is recognized - referred herein as (*).
Further, Gomes discloses cloud-based system communicating with the vehicle via the on-board unit SO to be able to determine if operating conditions of the vehicle that are required for application of the update are met (para 0219; claim 1, 8, pg. 32); e.g. based on the on-board unit transmitting to the cloud system notification about result in applying information update; hence, being informed via a on-board unit of latest conditions such as those indicating that the vehicle is parked or located in accordance to location requirement - e.g. within geofence boundaries – as prescribed for the update metadata can be equivalent to receiving update information from the vehicle instructing the cloud-based system on the latest requirement being met including notifying on geophysical location of the vehicle as set forth in (*) from above.
Use of a GPS as installed on a vehicle to repeatedly sent vehicle location updates to a remote
server configured for tracking the latest or current location of the vehicle is shown in Ju software
update network; that is, Ju discloses continual tracking of vehicle locations by a enterprise NW (para
0021-0023) based on multicasting of location signal via plural cooperating access points, using navigation-related services in form of GPS (para 0037-0038) as an on-vehicle module to provide real-time position-related data to a telematics unit of the vehicle (Fig. 2) as a form of confirmation thereby to coordinate download of navigation map (para 0039) or software update from remote server to the
vehicle (para 0006, 0045); hence continual signaling by on-vehicle navigation system module directed to a enterprise update center entails resending notification signal to a center about a most current position of a vehicle via navigation system unit operating as on-vehicle module.
Further, Turley discloses automobile tracking (para 0051-0052) in terms of sustaining operations of vehicle location in tracking devices such as embedded GPS that continues to monitor
location of the vehicle whether parked or running at defined intervals and sends location updates to a
tracking system at periodic intervals (para 0066), as a notification means (e.g. through mobile app) to inform on state (real-time location updates - see Abstract; para 0092) of the vehicle by which remedial action or service can be dispatched by back-end services in accordance to notification settings between a back-end system and the vehicle using notification signal or report from an on-board GPS (para 0099-0101); hence, repeated signaling or notification messages received from a location tracking devices reporting on state of a vehicle for a central service to dispatch a remedial action.
Thus, as location requirement can be reported from a vehicle in response to receiving update
requirement, repeated signals from an on-board unit - i.e. using on-vehicle GPS module – as per a continual reporting in real-time of geo-locations of the vehicle can be recognized as periodically transmitted notifications to a central server in regard to indicating that the vehicle after fulfilling location requirements would request that the update be completed or granted.
Therefore, it would have been obvious for one of ordinary skill in the art before the effective
filing date of the invention to implement use on on-board unit and on-vehicle GPS operation in
Gomes system so that granting completion of a vehicle update by a update center would include actions from the OTA center in terms of
1) receiving, from the vehicle and when the vehicle has moved to the predetermined place
based on the request information, the download request again - as set forth per repeated report on
location by Ju and Turley via use of on-vehicle GPS; and then
2) transmitting the update data to the vehicle based on location requirement condition being
met as per (*) from above; because
repeated signals or notification reports as tracked by an on-vehicle GPS unit on dynamic state
of a vehicle location can either establish a moving state of the vehicle or affirm that the vehicle has been actually parked or is anchored at a given geolocation, which, when analyzed by a update center, can signify that a prescribed location requirement for vehicle to obtain update service has been fulfilled or met, whereas repeated notifications on location state of the vehicle, when analyzed by a update center would not only enable the update center to establish confirmation from the vehicle in regard to intent/desire to follow through with the request for update, but would also affirm about the veracity of such location status, thereby consolidating decision making at the update center to the effect of granting completion of the update operation, which has been suspended to await whether the vehicle has moved and/or parked in a designated geolocation as required by the update information metadata; i.e. and agreeing the intent of the vehicle/owner to accept activation of the update.
As per claim 6, Gomes discloses a vehicle configured to execute a software update of an
in-vehicle device mounted (refer to claim 1) in the vehicle, the vehicle comprising one or more processors configured to:
transmit, to a center (refer to claim 1), a download request (refer to claim 1) for update data related to the software update;
when the software update to be executed is determined, based on the stored regulation information that indicates one or characteristics of the software update itself not to be a specific software update (refer to USC 112(a) rejection), receive the update data (refer to receive update data from below; see distributes 1024 – Fig. 10B) from the center;
when the software update to be executed is determined (information update are met - claim
1, claim 8 - pg. 32; information update are met - para 0219; OBU may determine whether
current operating conditions as defined in respective metadata are currently met - para 0212;
update metadata are currently met - para 0202), based on the stored regulation information (refer to claim 1) to be the specific software update, receive (distributed to the vehicle … with update metadata 802, distribution 806, 808 – Fig. 8) from the center, instead of (see receive request information) the update data, request information (see update metadata per claim 1; update metadata 901 – para 0196) based upon which (see Note1) the vehicle is to be guided to a predetermined place (refer to claim 1) by a navigation system (see Note1) included in the vehicle;
guide(refer to GPS app – para 0030) the vehicle to the predetermined place (see using the car navigation system and Note2; that is update metadata from the cloud service specifying requirement for the AV to be parked within specific physical location within/outside of a boundary "geofence" para 0196 - specifying a geographic location within whose distance or boundaries a vehicle is to park/stop for permitting a update service to be safely performed or delivered reads on predetermined service area having geophysical properties or boundaries for a vehicle to comply to in order to receive the update service);
determine whether the vehicle has moved to the predetermined place (refer to claim 1; step 1020: Yes – Fig. 10B);
when the vehicle has been determined to be at the predetermined place, transmit the download request to the center again (refer to rationale A of claim 1);
then receive the update data from the center (refer to claim 1); and execute the software update (apply information update 1026, 1028 – Fig. 10B) on a condition that the vehicle is located at the predetermined place (refer to claim 1),
wherein the predetermined place is a vehicle service area (refer to claim 1), which is an area where a vehicle service is receivable, or a network connection area (refer to claim 1).
Claims 10, 14 is/are rejected under § 35 U.S.C. 103 as being unpatentable over Gomes, USPubN: 2019/0205115 (herein Gomes) in view of Ju et al, USPubN: 2020/0409678 (herein Ju) and Turley, USPubN: 2020/0139929 (hereinTurley)further in view of Weston et al, USPubN: 2019/0364381 (herein Weston)
As per claim 10, Gomes discloses the vehicle receiving request information that requests for
updates from a center (in-vehicle systems, device of a vehicle that requests for updates - para
0184)
Gomes does not explicitly disclose the vehicle according to claim 6, wherein the one or more
processors are further configured to
display the predetermined place on a display mounted in the vehicle (when receiving the
request information from the center)
Weston discloses use of vehicle display whereby boundaries of the geofence can be visually
defined and adaptively manipulated to handle changes observed or out of range situations (para
0046)
Thus, based on the conditions requiring that the vehicle be located within a particular
location for update to be permitted (para 0184, 0196, 0215-0216), it would have been obvious for
one of ordinary skill in the art before the effective filing date of the invention to implement Gomes
service system in conjunction with the vehicle-mounted devices and electronic components thereon
so that upon receipt of a update requests at a remote center, conditions requiring location of the
vehicle can be provided as geo-locations sent from the update center, whereby a predetermined
location can be visualized on a display mounted in the vehicle - as in Weston - when the vehicle
receives request information returned from the update center in association with permission
indication for a in-vehicle device mounted in the vehicle to obtain an update to be executed at the
predetermined location; because
capability of a administrator to visually observe boundaries and extent of a geo-location and
readjust its representation metrics - as per a map as set forth above - would enable a manipulation
from a displayed geo-fence coordinates for improving network connectivity, which that in turn
would also make it easier for vehicles to reach or be rerouted toward an area of designated as a point
service, whereas a vehicle owner in considering the coordinates of a geo-fence from within a on-
board display would be assisted by the geographical data thereon in conjunction with help of a on-
board navigation unit so that a dedicated location predetermined by the central system administrator
-as a geo-fence area in Gomes - can be reached whereby chance for the vehicle to obtain a service maintenance or repair operation can substantially improve in accordance with the intended benefit in
using this geo-fence methodology as part of Gomes's service provision.
As per claim 14, Gomes discloses vehicle according to claim telaim 10, wherein:
the predetermined place is one of a plurality of possible predetermined places
displayed (refer to rationale of claim 10) on the display, the software update being executable at each of the possible predetermined places (refer to service area of claim 6);
the one or more processors are configured to receive a selection by a user (mobile App
equipped with environment sensors sensor associated with users, vehicle operators associated with on-board diagnostic units comprise positioning sensors, GPS sensor – para 0035; present disclosure
employ a variety of characteristics or parameters for each AV contexts support entry, collection parameters of a geographic regions available access points used in selecting the routes of Avs information about the geographic locations of end-user demands that may be placed upon AVs to meet end-user demand for transportation at the locations - para 0108; may use such information to direct AV's to move to a traditional parking space demand information in terms of end-users - para 0112; take into account such information in a AV selection function as one or more end-user preferences - para 0115-0116) of the vehicle of the predetermined place from among the plurality of predetermined places; and
the one or more processors are further configured to set a movement route (see para 0108 from above; para 0112; take into account such information in a AV selection function as one or more end-user preferences - para 0116) to the predetermined place after the selection by the user.
Claims 11-13 is/are rejected under § 35 U.S.C. 103 as being unpatentable over Gomes, USPubN: 2019/0205115 (herein Gomes) in view of Ju et al, USPubN: 2020/0409678 (herein Ju) and Turley, USPubN: 2020/0139929 (hereinTurley) further in view of Rosenthal et al, USPN:
7,162,428 (herein Rosenthal), Hyde et al, USPubN: 2015/0094957 (herein Hyde), and Reines,
USPubN: 2015/0302415 (herein Reines)
As per claims 11-13, Gomes does not explicitly disclose vehicle according to claim 6, wherein the regulation information includes
(i) first information indicating whether making a face-to-face explanation
of an OTA campaign to a user of the vehicle is necessary at a time of the execution of the
software update, and
(ii) second information indicating whether replacement of parts of the vehicle is necessary at the time of the execution of the software update, and
(iii) the one or more processors are further configured to guide the vehicle to the vehicle service area when either the first information indicates that the face-to-face explanation is necessary or the second information indicates that the replacement of parts is necessary.
(iv) wherein the vehicle service area is a vehicle dealer.
(v) wherein the vehicle service is a face-to-face explanation of an OTA campaign to a user of
the vehicle, or the vehicle service is replacement of parts of the vehicle.
As for (i), (ii), (iv) and (v),
Gomes discloses a OTA paradigm provided with meta-information stored on a cloud central
as requirements that govern how a OTA distribution of software and updates is being carried out or
should be regulated so that authorization for delivering the updates can be permitted, the
requirements provided as accessible information (Fig. 9) descriptive of conditions to obtain a OTA
distribution of service to a user of the vehicle, where parts of the vehicle can be subjected to an
updates or repair operation advertised under a corresponding campaign (para 0084, 0088); hence
information regulating a OTA type of distribution campaign is recognized
Prospective use information communicated to prospect users of electric vehicles in regard to
electric energy therefor as commercial packages, equipment, installation and financing sold via or
from vehicle dealers is shown in Hyde (para 0078-0080) as information communicated via audible
electronic means or recordings (para 0259-0262); e.g. in-person conversation capture (para 0129,
0263); hence, support for prospect buyers associated with vehicle dealerships that also provide or
make available prospective information on service provider availability (para 0324) and usage
information in form of in-person conversation as a form of tutorial for potential buyers considered
necessary.
Rosenthal discloses the well-known practice of scheduling or arranging by a service using
rules and procedures governing matters on how and who the service can serve, through the service of
paper, mail, courier as well as through a face-to-face presentation by a server process (col. 1 li. 28-
46) as well as via tools to dispatch online information about the service such as online dissemination
and process papers (col. 3 li. 15-47; Figs 6); hence arranging by a service on governing matters and
information about what the service offers using face-to-face presentation is recognized.
Reines discloses front-end support by a service or sales transaction to a customer SO the
customer can contact to resolve various manners or preferences via interacting with such service
(para 0027) per effect of a backend customer relationship module that includes a communication
manager (para 0029) configured to arrange phone call, live chat or video conference or in-person
meeting (face-to-face) between the engaging parties (para 0030) by which a customer can be
presented with options so that he/she can finalize a given selection (para 0035; in-person meeting at
a store - para 0036; Fig. 2A-2F) to resolve a dissatisfied issue. Thus, arrangement by a customer
service behind a frontend service or sales so that live chat or conference, voice call or in-person
meeting can be provided to a customer for the latter be offered options by which to finalize a
preference or a selected issue can be viewed as back-end support where face-to-face explanation of
options or preferences alternatives represent a necessary support feature for users/buyer to be able
resolve selection issues or make decision on a service or sales campaign.
Therefore, as front-end support receives request or prospects for a receiving a service and
purchasing a sale and backend support operates as an additional layer to a front-end users to provide
tutorial and usage information to the users in order to facilitate, enhance a product or service buyer
toward a decision making or selection of option or preferences, it would have been obvious at the
time of the invention for one skill in the art to implement backend support service associated with
the OTA campaign or methodology to provide update service to vehicle owners in Gomes so that
(1) the regulation information includes, for each OTA campaign to which a user is engaged,
information indicating whether making a face-to-face explanation of the OTA campaign as
advertised in Gomes to a user of the vehicle is necessary at a time of the execution of the software
update, the face-to-face explanation deemed necessary as shown in Reines and Rosenthal, or in-
person tutorial session as in Hydes; i.e. the regulation information describing requirements or
conditions on whether replacement of parts of the vehicle is necessary at the time of the execution of
the software update; as set forth in rationale A from above.
(2) the regulation information pertains to the vehicle service area such as a vehicle dealer as
shown in Hydes; and
(3) the vehicle service to render being one to administer a face-to-face explanation - as in
Reines or Rosenthal - about regulating internals of an OTA campaign to a user of the vehicle, or one
to provide replacement of parts of the vehicle as in Gomes; because
arrangement per a backend support to a frontend sale or service for vehicle users so that for a
given sale or OTA distribution campaign to which a user or a service buyer is registered, tutorial
data or explanation of a planned service can be accessible to the prospect user or buyer in form of
online or live chat, in person conference or face-to-face presentation would furnish the prospect
buyer or consumer of a service such as car sales, maintenance or updates as set forth above, with
sufficient learning, straight audio assistance from an expert (service personnel) in terms of listing,
explanation of options and operations to select, by which the user can contemplate the most
beneficial alternatives, make up or consolidate his/her decision or preferences about what and how to
receive or purchase as part of obtaining service features from the OTA distribution methodology in
accordance with regulation information support; i.e. as support delivered through front and back end
assistance from vehicle dealerships and service areas as set forth above.
As for (iii)
Determination that an update service or replacement of vehicle parts necessitate a face-to-
face explanation to the owner of the vehicle, necessarily when update or service is to be performed within a predetermined area or dealership premises was a known practice, as set forth above with the
teachings by Reines, Rosenthal and Hide, notably when the explanation and replacement of parts
support OTA campaign as intended in Gomes.
Therefore, it would have been obvious for one of ordinary skill in the art before the effective
filing date of the invention to implement OTA type of distribution campaign and expression of the
campaign information intended for vehicle owners of concern in Gomes system so that it is
imperative to consider use of update requirement information and dissemination thereof to the
vehicle owners in regard to arranging a predetermined location by which to implement a service or
update to the vehicle, which in turn necessitate additional accommodation to inform the user,
including guidance information such as organizing a face-to-face discussion with the users or
explanation of specific parts replacement to the users as set forth with the teachings by Reines,
Rosenthal and Hide from above; because
of the same reasons set forth with obviousness of the features (i), (ii) (iv) and (v) as presented
above.
Response to Arguments
Applicant's arguments filed 1/27/26 have been fully considered but they are moot in light of the adjusted grounds of rejection which have been necessitated by (emphasis here) the amendments (notably in claims 1 and 6).
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
April 18, 2026
Prosecution Insights