DETAILED ACTION
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA . This office action is in response to communication filed 5/4/2026.
The instant application having application No. 18/517,912 filed on November 22, 2023, claims priority to KR10-2023-0071284, filed 6/7/2023.
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 5/4/2026 has been entered.
Status of the Claims
Claims 1, 5, 8-10, 14, 17, 18, and 20 are amended, claims 3-4, 6, 12-13, and 15 are canceled, claims 2, 11, and 19 were previously canceled, claims 21-24 are added. Accordingly, claims 1, 5, 7-10, 14, 16-18, and 20-24 are currently pending in the application.
Response to Amendment
(A). Regarding 35 U.S.C. § 101 rejection: The amended claims are still abstract idea without significantly more, the rejections are maintained as set forth in the office action below.
(B). Regarding art rejection: In regards to pending claims, Applicant's amendments necessitated further search, and new grounds of rejections are presented in the following art rejection.
Examiner Notes
Examiner cites particular columns, paragraphs, figures and line numbers in the references as applied to the claims below for the convenience of the applicant. Although the specified citations are representative of the teachings in the art and are applied to the specific limitations within the individual claim, other passages and figures may apply as well. It is respectfully requested that, in preparing responses, the applicant fully consider the references in their entirety as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior art or disclosed by the examiner.
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1, 5, 7-10, 14, 16-18, and 20-24 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor, or for pre-AIA the applicant regards as the invention.
The term "the vehicle number" in lines 22-23 of claim 1 is not clear whether it refers to “a vehicle number” in lines 7-8 or in line 13 of claim 1. Similarly, "the vehicle number" in claim 7 is not clear whether it refers to “a vehicle number” in lines 7-8 or in line 13 of claim 1.
Claim 10 has the same issue as claim 1, and is rejected for the same reason. Claim 16 has the same issue as claim 7, and is rejected for the same reason.
Claim 20 has the same issue as claim 1, and is rejected for the same reason. Claim 22 has the same issue as claim 7, and is rejected for the same reason.
Dependent claims 5, 7-9, 14, 16-18, and 21-24 are rejected for the same reason because they depend from their respective independent claim 1, or 10, or 20.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1, 5, 7-10, 14, 16-18, and 20-24 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
With respect to claim 10, This claim is within at least one of the four categories of patent eligible subject matter as it is directed to a method claim under Step 1.
Under Prong 1, Step 2A:
However, the limitations of claim 10,
“ determining whether an Over The Air (OTA) update of vehicle software is required based on the location information of the vehicle and a preset update environment, the preset update environment including a geofence area set for each vehicle; and wherein the preset update environment includes, for each vehicle, a vehicle number, update status information indicating whether an update is required, update schedule information including an update schedule, (…);
determining that the OTA update is required based on: (i) the location information of the vehicle indicating that the vehicle is located within the garage area or the parking lot area, (ii) the parking state of the vehicle being the engine-off state or the electronic alert mode state, (iii) the update status information indicating that the update is required, and (iv) a current time being included in the update schedule; and
wherein the OTA update is performed by:
validating the safety-related firmware for fleet-wide distribution based on the received update result signal indicating a successful firmware installation without a reported failure for a predetermined time, and
wherein the OTA update is remaining vehicles among the plurality of vehicles only after the validation of the safety-related firmware.”
as drafted, are functions that, under its broadest reasonable interpretation, recite the abstract idea of a mental process. The limitations encompass a human mind carrying out the functions through observation, evaluation, judgment and /or opinion, or even with the aid of pen and paper. e.g. human can manually determine whether OTA update of vehicle software is required based on the available information as defined in the claim. Similarly, human can manually determine whether the OTA update is required based on the conditions as defined in the claim, can manually validate the safety-related firmware as defined in the claim, and can manually determine whether to perform the update to the remaining vehicles based on the condition as defined in the claim. Thus these claim limitations fall within the “Mental Processes” grouping of abstract ideas under Prong 1 Step 2A.
Under Prong 2, Step 2A:
The judicial exception is not integrated into a practical application. The claim recites the following additional elements
“a computing device”, “one or more processors”, “a memory”,
“receiving vehicle information including a vehicle number, location information of the vehicle, and a parking state of the vehicle indicating an engine-off state or an electronic alert mode state of the vehicle;”
“…a geofence area comprising a garage area or a parking lot area set for each vehicle;” and
“transmitting, based on a determination that the OTA update is required, an OTA update request of safety-related firmware for the vehicle software for the vehicle having the vehicle number to an OTA server,”
“receiving an update result signal from a subset of vehicles among a plurality of vehicles,”
The computing device, processors and memory are recited at a high-level of generality (i.e. as a generic computer or computer component performing generic computer functions) such that they amount to no more than mere instructions to apply the judicial exception using a generic computer component. Accordingly, these additional elements do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea. The “receiving” and “transmitting” processes are insignificant extra-solution activity such as gathering and transmitting data, according to MPEP 2106.05(g); thus, not indicative of an integration into a practical application. “…a geofence area comprising a garage area or a parking lot area set for each vehicle;” as drafted, is merely indicating a field of use or technological environment in which to apply a judicial exception, and does not integrate a judicial exception into a practical application. See MPEP § 2106.05(h).
Under Step 2B:
The claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration of the abstract idea into a practical application, the additional elements, the computing device, processors and memory are recited at a high-level of generality (i.e. as a generic computer component) such that it amounts to no more than mere instructions to apply the judicial exception using a generic computer component, and is not an inventive concept. “receiving …;” and “transmitting …” are insignificant extra-solution activity such as gathering and transmitting data which is recognized as well-understood, routine, and conventional activity, see MPEP § 2106.05(d)(II), Symantec for receiving and transmitting data. “…a geofence area comprising a garage area or a parking lot area set for each vehicle;” as drafted, is merely indicating a field of use or technological environment in which to apply a judicial exception, and does not amount to significantly more than the exception itself. See MPEP § 2106.05(h). Accordingly, even viewed as a whole, the claim does not appear to be patent eligible under 35 USC 101.
With respect to claim 1, This claim is within at least one of the four categories of patent eligible subject matter as it is directed to a fleet server (system) under Step 1.
This claim recites a fleet server to implement a method that is disclosed in claim 10 and therefore recites the same abstract idea as claim 10, please see the office action analysis regarding claim 10.
Claim 1 recites more additional elements that are not recited in claim 10, i.e. “A fleet server”, and “a communication interface”, but these elements are recited at a high-level of generality (i.e. as a generic computer component) such that it amounts to no more than mere instructions to apply the judicial exception using a generic computer component.
With respect to claim 20, This claim is within at least one of the four categories of patent eligible subject matter as it is directed to A non-transitory computer-readable medium (product) under Step 1.
This claim recites A non-transitory computer-readable medium to implement a method that is disclosed in claim 10 and therefore recites the same abstract idea as claim 10, please see the office action analysis regarding claim 10.
Claim 20 recites more additional elements that are not recited in claim 10, i.e. “A non-transitory computer-readable medium storing a program” and “a computer”, but these elements are recited at a high-level of generality (i.e. as a generic computer or computer component) such that it amounts to no more than mere instructions to apply the judicial exception using a generic computer component.
With respect to claims 5, 14 and 21, “wherein the geofence area is an area expanded from a boundary of a garage area by a predetermined distance.” as drafted, is merely indicating a field of use or technological environment in which to apply a judicial exception, and does not amount to significantly more than the exception itself, and cannot integrate the judicial exception into a practical application. See MPEP § 2106.05(h).
With respect to claims 7, 16 and 22, “wherein the OTA update request is transmitted to the OTA server,
wherein the OTA server transmits a latest version of the vehicle software to the vehicle having the vehicle number, and
wherein the vehicle having the vehicle number is configured to update the vehicle software from a prior version to the latest version.”
Wherein the “transmits” and “transmitted” processes are insignificant extra-solution activity such as transmitting data which is recognized as well-understood, routine, and conventional activity, see MPEP § 2106.05(d)(II), Symantec for receiving and transmitting data. “update the vehicle software from a prior version to the latest version” is like retrieving and storing data which is insignificant extra-solution activity and is recognized as well-understood, routine, and conventional activity, see MPEP § 2106.05(d)(II), Versata Dev. Group, Inc. v. SAP Am., Inc. for retrieving and storing data. The OTA server and the vehicle are recited at a high-level of generality (i.e. as a generic computer system) such that it amounts to no more than mere instructions to apply the judicial exception using a generic computer system.
With respect to claims 8, 17 and 23, “wherein the one or more processors are further configured to, based on the update status information indicating that the update is not required, block transmission of the OTA update request.”
as drafted, are functions that, under its broadest reasonable interpretation, cover performance of the limitation in the mind. E.g. the user can manually make the decision, i.e. do not transmit the OTA update request based on the update status information.
With respect to claims 9, 18 and 24, “wherein the one or more processors are further configured to:
transmit a response request according to the received update result.”
the “transmit” process is insignificant extra-solution activity such as gathering and transmitting data which is recognized as well-understood, routine, and conventional activity, see MPEP § 2106.05(d)(II),Symantec for receiving and transmitting data.
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 of this title, 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, 5, 7, 10, 14, 16, and 20-22 are rejected under 35 U.S.C. 103 as being unpatentable over CAUSHI et al. (US 20180024826 A1, hereinafter “CAUSHI”) in view of Sharma et al. (US 20230094805 A1, hereinafter “Sharma”), WITHUN et al. (US 20200117438 A1, hereinafter “WITHUN”), AUST (US 20200125355 A1, hereinafter “AUST”) and Silakov et al. (US 11768672 B1, hereinafter “Silakov”).
With respect to claim 1 (Currently Amended), CAUSHI discloses A fleet server configured to perform a software update for a vehicle based on geofence (e.g. Fig. 2, 202 In-Vehicle Software Update Server), comprising:
a communication interface;
one or more processors; and
a memory storing instructions that, when executed by the one or more processors, cause the one or more processors to (e.g. para [0030], “… the computing platform 104 may communicate with the IVSU 202 via the network 156 to establish an account. ... The IVSU 202 may receive these communications from the vehicles 102, and may maintain a data store of the hardware configurations and software (e.g., firmware, etc.) versions linked to identifiers of the vehicles 102, e.g., linked to VIN of the vehicle 102. The IVSU 202 may further maintain a data store of the stored region identifier 228 defining the previously-determined region 210 associated with the vehicle 102.” The paragraph indicates that the sever IVSU comprises a communication interface, one or more processors, and a memory):
receive, through the communication interface, vehicle information including a vehicle number (e.g. para [0030], “… the computing platform 104 may send the IVSU 202 the interrogator log 212 that includes information identifying the specific vehicle 102 and information related to a current software version of the controllers of the vehicle 102. …” para [0028], “… The interrogator log 212 may include information identifying the specific vehicle 102 as well as one or more of the vehicle controllers 148 using parameters and values such as, but not limited to, controller name, controller serial number, VIN, hardware part number, …”), location information of the vehicle, and [a parking state of the vehicle indicating an engine-off state or an electronic alert mode state of the vehicle] (e.g. Fig. 3, steps A-D, wherein region reads on location information),
determine whether an Over The Air (OTA) update of vehicle software is required based on the location information of the vehicle and a preset update environment, (e.g. Fig. 4, steps A-D, para [0048], “… the IVSU 202 determines the software updates 220 and creates the instructions 216 at time index (D). …”), wherein the preset update environment includes, for each vehicle, a vehicle number, update status information indicating whether an update is required, [update schedule information including an update schedule], and a geofence area comprising [a garage area or a parking lot area] set for each vehicle (e.g. para [0030] as cited above, discloses providing a vehicle number. Figs. 3 and 4, where steps Update? or Determine Updates determines whether an update is required. Para [0042] discloses collecting current location information including geofence),
determine that the OTA update is required based on: [(i) the location information of the vehicle indicating that the vehicle is located within the garage area or the parking lot area, (ii) the parking state of the vehicle being the engine-off state or the electronic alert mode state,] (iii) the update status information indicating that the update is required (e.g. Figs. 3 and 4, where steps Update? or Determine Updates determines the update status, whether an update is required.), and [(iv) a current time being included in the update schedule], and
transmit, based on a determination that the OTA update is required, an OTA update request of[[ the]] [safety-related firmware] (e.g. Fig. 4, Step B to Step E. para [0046], “At time index (B), the computing platform 104 sends an update request, e.g., sends the interrogator log 212, to the IVSU 202. …” para [0050], “The IVSU 202 sends the instructions 216 to the vehicle 102 at time index (E). …”),
CAUSHI does not appear to explicitly disclose
(receive, through the communication interface, vehicle information including …), and a parking state of the vehicle indicating an engine-off state or an electronic alert mode state of the vehicle;
(…, wherein the preset update environment includes, for each vehicle, …), update schedule information including an update schedule, (and a geofence area comprising) a garage area or a parking lot area (set for each vehicle);
determine that the OTA update is required based on: (i) the location information of the vehicle indicating that the vehicle is located within the garage area or the parking lot area, (ii) the parking state of the vehicle being the engine-off state or the electronic alert mode state, (…), and (iv) a current time being included in the update schedule,
(transmit, …) [safety-related firmware] (….,)
wherein the one or more processors are further configured to:
receive an update result signal from a subset of vehicles among a plurality of vehicles, and
validate the safety-related firmware for fleet-wide distribution based on the received update result signal indicating a successful firmware installation without a reported failure for a predetermined time, and
wherein the one or more processors are configured to perform the OTA update on remaining vehicles the plurality of vehicles only after the validation of the safety-related firmware.
However, in analogous art, Sharma discloses
(receive, through the communication interface, vehicle information including …), and a parking state of the vehicle indicating an engine-off state or an electronic alert mode state of the vehicle (e.g. para [0007], “Determining that the at least one vehicle operating condition allows the firmware update may comprise determining that a parking brake of the vehicle is engaged.”, para [0009], discloses engine-off state for update.)
determine that the OTA update is required based on: [(i) the location information of the vehicle indicating that the vehicle is located within the garage area or the parking lot area,] (ii) the parking state of the vehicle being the engine-off state or the electronic alert mode state (e.g. para [0007, 0009] as cited above.), (…), [and (iv) a current time being included in the update schedule,]
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the invention of CAUSHI with the invention of Sharma because it provides techniques for safe over-the-air update of electronic control units in vehicles. A person having ordinary skill in the art would have been motivated to make this combination, with a reasonable expectation of success, for the purpose of providing techniques for safe over-the-air update of electronic control units in vehicles as suggested by Sharma (see Abstract, para [0134, 0142]).
CAUSHI as modified by Sharma does not appear to explicitly disclose
(…, wherein the preset update environment includes, for each vehicle, …), update schedule information including an update schedule, (and a geofence area comprising) a garage area or a parking lot area (set for each vehicle);
determine that the OTA update is required based on: (i) the location information of the vehicle indicating that the vehicle is located within the garage area or the parking lot area, (...), (…), and (iv) a current time being included in the update schedule,
(transmit, …) [safety-related firmware] (….,)
wherein the one or more processors are further configured to:
receive an update result signal from a subset of vehicles among a plurality of vehicles, and
validate the safety-related firmware for fleet-wide distribution based on the received update result signal indicating a successful firmware installation without a reported failure for a predetermined time, and
wherein the one or more processors are configured to perform the OTA update on remaining vehicles the plurality of vehicles only after the validation of the safety-related firmware
However, in analogous art, WITHUN discloses
(…, wherein the preset update environment includes, for each vehicle, …), update schedule information including an update schedule (e.g. para [0035], “If so, then the vehicle 102 may further confirm whether the current time is within the times allowed for installation of software updates 116. …” wherein times allowed for installation of software updates indicates update schedule), (and a geofence area comprising) [a garage area or a parking lot area] (set for each vehicle);
determine that the OTA update is required based on: [(i) the location information of the vehicle indicating that the vehicle is located within the garage area or the parking lot area,] (...), (…), and (iv) a current time being included in the update schedule (e.g. para [0035], “If so, then the vehicle 102 may further confirm whether the current time is within the times allowed for installation of software updates 116. …” wherein times allowed for installation of software updates indicates update schedule),
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the invention of WITHUN because it provides techniques for simplifying scheduling of vehicle operations such as software updates. A person having ordinary skill in the art would have been motivated to make this combination, with a reasonable expectation of success, for the purpose of providing techniques for simplifying scheduling of vehicle operations such as software updates as suggested by WITHUN (see para [0001-0005]).
CAUSHI as modified by Sharma and WITHUN does not appear to explicitly disclose
(…, wherein the preset update environment includes, for each vehicle, …), (…), (and a geofence area comprising) a garage area or a parking lot area (set for each vehicle);
determine that the OTA update is required based on: (i) the location information of the vehicle indicating that the vehicle is located within the garage area or the parking lot area, (...), (…), and (…),
(transmit, …) [safety-related firmware] (….,)
wherein the one or more processors are further configured to:
receive an update result signal from a subset of vehicles among a plurality of vehicles, and
validate the safety-related firmware for fleet-wide distribution based on the received update result signal indicating a successful firmware installation without a reported failure for a predetermined time, and
wherein the one or more processors are configured to perform the OTA update on remaining vehicles the plurality of vehicles only after the validation of the safety-related firmware
However, in analogous art, AUST discloses
(…, wherein the preset update environment includes, for each vehicle, …), (…), (and a geofence area comprising) a garage area or a parking lot area (set for each vehicle) (e.g. para [0004], “… In the second related art, a condition for software update by wireless communication is that a vehicle is present at a predetermine location such as near home (home parking, for example), a dealer, a repair shop, or the like.. …”);
determine that the OTA update is required based on: (i) the location information of the vehicle indicating that the vehicle is located within the garage area or the parking lot area (e.g. para [0004] as cited above), (...), (…), and (…),
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the invention of AUST because it improves the security of OTA software update for a vehicle. A person having ordinary skill in the art would have been motivated to make this combination, with a reasonable expectation of success, for the purpose of improving the security of OTA software update for a vehicle as suggested by AUST (see para [0074]).
CAUSHI as modified by Sharma, WITHUN and AUST does not appear to explicitly disclose
(transmit, …) [safety-related firmware] (….,)
wherein the one or more processors are further configured to:
receive an update result signal from a subset of vehicles among a plurality of vehicles, and
validate the safety-related firmware for fleet-wide distribution based on the received update result signal indicating a successful firmware installation without a reported failure for a predetermined time, and
wherein the one or more processors are configured to perform the OTA update on remaining vehicles the plurality of vehicles only after the validation of the safety-related firmware
However, in analogous art, Silakov discloses
(transmit, …) safety-related firmware (e.g. col 8, lines 7-20, discloses security update which reads on safety-related firmware) (….,)
wherein the one or more processors are further configured to:
receive an update result signal from a subset of vehicles among a plurality of vehicles (e.g., Col 6, lines 45-54, “In some aspects, when an updated instance or node is determined to have a health (e.g., functionality or performance) issue, …. In one aspect, before launching next update wave, the controller performs a “health check” to ensure that current (and previous) update went fine.”. Col 6, lines 55-58, “Health checks may be performed by update controller 104 once an update has been completed on a node or after a some predefined time.” wherein updating computing nodes is analogous to updating software on vehicles, hence Silakov renders the claim feature obvious.), and
validate the safety-related firmware for fleet-wide distribution based on the received update result signal indicating a successful firmware installation without a reported failure for a predetermined time (e.g., Col 6, lines 45-54, “…. In one aspect, before launching next update wave, the controller performs a “health check” to ensure that current (and previous) update went fine.”. Col 6, lines 55-58, “Health checks may be performed by update controller 104 once an update has been completed on a node or after a some predefined time.” wherein updating computing nodes is analogous to updating software on vehicles, hence Silakov renders the claim feature obvious.), and
wherein the one or more processors are configured to perform the OTA update on remaining vehicles the plurality of vehicles only after the validation of the safety-related firmware (e.g., Col 6, lines 45-54, “…. In one aspect, before launching next update wave, the controller performs a “health check” to ensure that current (and previous) update went fine.”. Col 6, lines 55-58, “Health checks may be performed by update controller 104 once an update has been completed on a node or after a some predefined time.” wherein updating computing nodes is analogous to updating software on vehicles, hence Silakov renders the claim feature obvious.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the invention of Silakov because it provides techniques for automatic user-controlled deployment of software updates.. A person having ordinary skill in the art would have been motivated to make this combination, with a reasonable expectation of success, for the purpose of providing techniques for automatic user-controlled deployment of software updates as suggested by Silakov (see col 1, lines 36-57).
With respect to claim 5 (Currently Amended), CAUSHI as modified by Sharma, WITHUN, AUST and Silakov discloses The fleet server of claim 1, AUST discloses wherein the geofence area is an area expanded from a boundary of [[a]] the garage area by a predetermined distance (e.g. para [0004], “… In the second related art, a condition for software update by wireless communication is that a vehicle is present at a predetermine location such as near home (home parking, for example), a dealer, a repair shop, or the like.. …” wherein near home parking reads on an area expanded from a boundary of a garage area by a predetermined distance. For motivation to combine, please refer to office action regarding claim 1.)
With respect to claim 7 (Previously Presented), CAUSHI as modified by Sharma, WITHUN, AUST and Silakov discloses The fleet server of claim 1, CAUSHI further discloses
wherein the OTA server transmits a latest version of the vehicle software to the vehicle having the vehicle number (e.g. Fig. 4, step G, wherein the RSDN reads on OTA server), and
wherein the vehicle having the vehicle number is configured to update the vehicle software from a prior version to the latest version (e.g. Fig. 4, step H).
Sharma discloses wherein the OTA update request is transmitted to the OTA server (e.g. Fig. 10A, step 1220. For motivation to combine, please refer to office action regarding claim 1 above).
With respect to claim 10 (Currently Amended), it is directed to a method disclosed in claim 1, please see the rejections directed to claim 1 above which also cover the limitations recited in claim 10.
With respect to claim 14 (Currently Amended), it recites same features as claim 5, and is rejected for the same reason.
With respect to claim 16 (Previously Presented), it recites same features as claim 7, and is rejected for the same reason.
With respect to claim 20 (Currently Amended), it is directed to A non-transitory computer-readable medium to implement the method disclosed in claim 1, please see the rejections directed to claim 1 above which also cover the limitations recited in claim 20. The memory storing instructions of claim 1 reads on non-transitory computer-readable medium storing a program of claim 20.
With respect to claim 21 (New), it recites same features as claim 5, and is rejected for the same reason.
With respect to claim 22 (New), it recites same features as claim 7, and is rejected for the same reason.
Claims 8, 17 and 23 are rejected under 35 U.S.C. 103 as being unpatentable over CAUSHI in view of Sharma, WITHUN, AUST and Silakov as applied to claims 1, 10 and 20 respectively, in further view of Patil (US 10437581 B1, hereinafter “Patil”).
With respect to claim 8 (Currently Amended), CAUSHI as modified by Sharma, WITHUN, AUST and Silakov discloses The fleet server of claim [[3]] 1, but does not appear to explicitly disclose wherein the one or more processors are further configured to, based on the update status information indicating that the update is not required, block transmission of the OTA update request. However, this is taught in analogous art, Patil (e.g. col 17 line 26 to col 18 line 13 “… For example, the platform application 138 can create a withhold command 166 that identifies the M2M device 102B and commands
the firmware scheduler server 170 to prohibit the scheduling of a firmware update by instructing the firmware scheduler server 170 not to send the firmware update
request 178 to the FOTA server 180 until instructed by the platform application 138. …”)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the invention of Patil because it can help to prevent and/or mitigate potential congestion of the network 124 by disallowing
firmware updates to multiple M2M devices 102 unless certain conditions are met (e.g., exceeding the usage threshold 158). A person having ordinary skill in the art would have been motivated to make this combination, with a reasonable expectation of success, for the purpose of helping to prevent and/or mitigate potential congestion of the network 124 by disallowing firmware updates to multiple M2M devices 102 unless certain conditions are met (e.g., exceeding the usage threshold 158) as suggested by Patil (see col 17 line 26 to col 18 line 13).
With respect to claim 17, it recites same features as claim 8, and is rejected for the same reason.
With respect to claim 23 (New), it recites same features as claim 8, and is rejected for the same reason.
Claims 9, 18 and 24 are rejected under 35 U.S.C. 103 as being unpatentable over CAUSHI in view of Sharma, WITHUN, AUST and Silakov as applied to claims 1, 10 and 20 respectively, in further view of KOTANI et al. (US 20150113520 A1, hereinafter “KOTANI”).
With respect to claim 9 (Currently Amended), CAUSHI as modified by Sharma, WITHUN, AUST and Silakov discloses The fleet server of claim 1, but does not appear to explicitly disclose wherein the one or more processors are further configured to:
transmit a response request according to the received update result. However, this is taught in analogous art, KOTANI (e.g. para [0049], “… After that, the update server 22 receives from the in-vehicle equipment 23 the configuration information after applying the update software, …, and when deciding that the update of the software has failed, the update server 22 instructs the in-vehicle equipment 23 to roll back the update processing.”)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the invention of KOTANI because he success or failure in the update of the software is decided by the update server 22, a reliability of the ECU 24 after the update is improved and any defect of the ECU 24 after the update may be prevented beforehand. Further, since the update server 22 selects the appropriate update software, a load for the ECU 24 and the in-vehicle equipment 23 caused by the update of the software of each ECU 24 of the automobile 21 may be reduced. A person having ordinary skill in the art would have been motivated to make this combination, with a reasonable expectation of success, for the purpose of improving reliability of the ECU 24 after the update and reducing load for the ECU 24 and the in-vehicle equipment 23 caused by the update of the software of each ECU 24 of the automobile as suggested by KOTANI (see para [0051]).
With respect to claim 18, it recites same features as claim 9, and is rejected for the same reason.
With respect to claim 24 (New), it recites same features as claim 9, and is rejected for the same reason.
Response to Arguments
Applicant's arguments filed 5/4/2026 have been fully considered but they are not persuasive.
At p1 under title “Claim Rejections - 35 U.S.C. § 101” to p3 of the Remarks, Applicant argued with respect to 101 rejections. Particularly, at p2 first full paragraph of the Remarks, Applicant argued that “the amended claims do not recite a mental process. For example, the claims recite a specific computational analysis of machine-perceived data, including internal "alert mode" bit-states and precise GPS-based geofence proximity, that cannot be reasonably performed in the human mind. A human cannot mentally perceive or process the internal digital state of a remote vehicle's ECU to determine if it is in an "electronic alert mode." …. Therefore, the claims do not recite a judicial exception under Prong One.”
Examiner respectfully disagrees, because, as set forth in the office action, the determine processes and the validate process can be manually performed by human, i.e. are mental processes. Processing of “alert mode” bit-states and GPS-based geofence proximity involve computing devices, but the activities are extra-solution activities such as retrieving, receiving and transmitting data which are recognized as well understood, routine, and conventional activities in MPEP.
At p2 second full paragraph of the Remarks, Applicant argued that “Further, even assuming the claims involve "mental processes," as asserted by the Office Action, under Prong Two, the claims integrate the concept into a practical application. …. The claims provide a technical improvement over conventional technology by enabling a real-world application of remote safety-critical hardware maintenance through the automated use of geofences as a technical constraint for hardware recoverability. This specific integration of machine telemetry and staged validation into a localized diagnostic tool constitutes a significant improvement in the functioning of automotive fleet management infrastructure.”
Examiner respectfully disagrees, because, as explained above, processing of machine telemetry may involve computing devices, but the activities are extra-solution activities such as retrieving, receiving and transmitting data which are recognized as well understood, routine, and conventional activities in MPEP, thus the claims do not affect technology, i.e. the functioning of automotive fleet management infrastructure is not affected; the automotive fleet management infrastructure is merely used to implement the abstract idea of mental processes. The claims do not integrate the judicial exception into a practical application.
At p2 third full paragraph to p3 second paragraph of the Remarks, Applicant argued that “Using this improved diagnostic method, the system can perform safety-related updates with high reliability by validating the safety-related firmware based on a subset of the fleet before full deployment. By anchoring the claim in machine-perceived data (alert mode signals) and infrastructure requirements (garage proximity), the claim provides a substantial technical advantage by allowing safety-related firmware to be updated without the hassle of visiting a service center separately. See id. at [0040]. Therefore, the pending claims integrate any alleged abstract ideas into a practical application of automated automotive safety-interlock systems.”
Examiner respectfully disagrees, because, the solution to the practical problem of forcing drivers to invest time in visiting a service center for firmware update is abstract idea without significantly more. Defining the geofence as a garage area or parking lot area is mental process because human can manually perform the process. Similarly, the staged update and validation are mental processes because human can manually perform the processes. As explained above, processing of alert mode signals involve computing devices, but the activities are extra-solution activities such as retrieving, receiving and transmitting data which are recognized as well understood, routine, and conventional activities in MPEP. Thus, the pending claims do not integrate the judicial exception into a practical application.
At p3 third and fourth paragraphs of the Remarks, Applicant argued with respect to Step 2B that “the specific automated correlation of internal ECU bit-states with geofenced maintenance infrastructure to trigger a staged, validated firmware rollout is not well-understood, routine, or conventional. This unconventional combination of technical data domains allows a fleet server to safely deploy critical firmware, a technical capability not found in the prior art. Moreover, these features were not disclosed or suggested by the cited references, as indicated during the examiner interview. Therefore, the combination of features described above is not well-understood, routine, or conventional such that amended claim 1 recites "significantly more" than any alleged abstract idea.”
Examiner respectfully disagrees, as explained above, processing of internal ECU bit-states may involve computing devices, but the activities are extra-solution activities such as retrieving, receiving and transmitting data which are recognized as well understood, routine, and conventional activities in MPEP. The staged update and validation are mental processes because human can manually perform the processes. Not all of the claim processes are well-understood, routine, or conventional, but as explained above and as set forth in the office action, the claims recite abstract idea of mental processes, and the additional elements are either extra-solution activities which are recognized as well-understood, routine, and conventional or are generic computer components. The claims do not recite significantly more than the identified abstract idea. As set forth in the office action above, the claims are obvious over prior art although obviousness is not the basis for 101 abstract idea rejections.
At p3 last paragraph of the Remarks, Applicant argued that “For these reasons, amended claim 1 is not "directed to" an abstract idea and, even if it is, the claim integrates the alleged abstract idea into a practical application that involves automotive diagnostic technology and recites "significantly more" than any alleged abstract idea. Independent claims 10 and 20 are similarly directed, as are their dependent claims. Accordingly, Applicant respectfully requests reconsideration and withdrawal of the rejections under § 101.”
Examiner respectfully disagrees, because, as explained above, the claims are abstract idea without significantly more, the 101 rejections are maintained.
At p4-p5, Applicant argued with respect to art rejections, these arguments are moot upon new ground of rejections made in the office action above.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. For example, Ullman et al., US 20210191714 A1 teaches Vehicle Software Deployment System.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Zengpu Wei whose telephone number is 571-270-1302. The examiner can normally be reached on Monday to Friday from 8:00AM to 5:00 PM.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Bradley Teets, can be reached on 571-272-3338. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://portal.uspto.gov/external/portal. Should you have questions about access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free).
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
/ZENGPU WEI/
Examiner, Art Unit 2197
Prosecution Insights