DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA . Claims 1-19 are pending.
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.
Claims 8 and 15-19 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 applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
In claim 8, applicant recites: “storing the obtained charging information in the storage medium in association with the corresponding vehicle; in response to obtaining updated charging information for the corresponding vehicle, updating the charging information stored in the storage medium in association with the corresponding vehicle with the updated charging information.”
However, applicant’s claim 8 recites a first and a second storage mediums, and it’s unclear to which storage medium applicant is referring in these limitations. Given the ambiguity, the metes and bounds are unclear.
The dependent claims are rejected by virtue of their dependency. Appropriate correction is required.
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-19 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception without significantly more.
Step 1 (The Statutory Categories): Is the claim to a process, machine, manufacture or composition of matter? MPEP 2106.03.
Per Step 1, claims 1 and 8 are directed to a statutory category of invention (i.e., a machine). However, the claims are rejected under 35 U.S.C. 101 because they are directed to an abstract idea, a judicial exception, without reciting additional elements that integrate the judicial exception into a practical application.
The analysis proceeds to Step 2A Prong One.
Step 2A Prong One: Does the claim recite an abstract idea, law of nature, or natural phenomenon? MPEP 2106.04.
The abstract idea of claim 1 is:
obtaining charging information, the charging information comprising information on a respective on-board battery level and charging cost information pertaining to charging the respective on-board battery of a corresponding vehicle of the vehicles, the charging cost being a cost required to accumulate a predetermined unit power in the respective on-board batteries of the vehicles, wherein the charging information is transmitted;
storing the obtained charging information in association with the corresponding vehicle;
in response to obtaining updated charging information for the corresponding vehicle, updating the charging information stored in association with the corresponding vehicle with the updated charging information;
receiving a rescue request when [determining] that a condition for transmitting a rescue request has been met, the rescue request comprising rescue content pertaining to resolving the malfunction, wherein the condition for transmitting a rescue request is when [detecting] at least one of:
(i) an operation performed by a user of the malfunctioning vehicle to transmit the rescue request, or
(ii) an on-board battery of the malfunctioning vehicle is depleted and there is no charging station within a predetermined distance from the malfunctioning vehicle, wherein the rescue request is transmitted when the on-board battery is depleted and there is no charging station within the predetermined distance;
extracting, based on (i) the rescue content, (ii) the information on the respective on-board battery level, and (iii) the charging cost information pertaining to charging the respective on-board battery of a corresponding vehicle of the vehicles, one or more vehicles capable of resolving the malfunction as one or more potential rescue vehicles from among the vehicles;
calculating a reward based on (i) the rescue content, (ii) the information on the respective on-board battery level, and (iii) the charging cost information pertaining to charging the respective on-board battery for each of the one or more potential rescue vehicles;
presenting each of the one or more potential rescue vehicles and the reward to a user of the malfunctioning vehicle;
identifying a vehicle selected by the user of the malfunctioning vehicle from among the one or more potential rescue vehicles as a rescue vehicle to rescue the malfunctioning vehicle; and
notifying a user of the rescue vehicle of the rescue request by [presenting] (i) map information and a route from a current location of the rescue vehicle to a current location of the malfunctioning vehicle and travel time to reach the malfunctioning vehicle, and (ii) selecting whether to accept the rescue request; and
in response to receiving an acceptance indicating that the user of the rescue vehicle has accepted the rescue request, notifying the user of the malfunctioning vehicle that the rescue vehicle has been determined to rescue the malfunctioning vehicle, wherein the acceptance is transmitted when [detecting] an acceptance operation within a predetermined time period, and wherein a non-acceptance result is transmitted in response to failure to detect the acceptance operation within the predetermined time period, the non-acceptance result indicating that the rescue request is not accepted by the rescue vehicle.
The abstract idea of claim 8 is:
obtaining charging information, the charging information comprising information on a respective on-board battery level and charging cost information pertaining to charging the respective on-board battery of a corresponding vehicle of the vehicles, the charging cost being a cost required to accumulate a predetermined unit power in the respective on-board batteries of the vehicles, wherein the charging information is transmitted;
storing the obtained charging information in association with the corresponding vehicle;
in response to obtaining updated charging information for the corresponding vehicle, updating the charging information stored in association with the corresponding vehicle with the updated charging information;
receiving a rescue request when [determining] that a condition for transmitting a rescue request has been met, the rescue request comprising rescue content pertaining to resolving the malfunction;
extracting, based on (i) the rescue content, (ii) the information on the respective on-board battery level, and (iii) the charging cost information pertaining to charging the respective on-board battery of a corresponding vehicle of the vehicles, one or more vehicles capable of resolving the malfunction as one or more potential rescue vehicles from among the vehicles;
calculating a reward based on (i) the rescue content, (ii) the information on the respective on-board battery level, and (iii) charging cost information pertaining to charging the respective on-board battery for each of the one or more potential rescue vehicles;
presenting each of the one or more potential rescue vehicles and the reward to a user of the malfunctioning vehicle;
identifying a vehicle selected by the user of the malfunctioning vehicle from among the one or more potential rescue vehicles as a rescue vehicle to rescue the malfunctioning vehicle; and
notifying a user of the rescue vehicle of the rescue request by transmitting (i) map information and a route from a current location of the rescue vehicle to a current location of the malfunctioning vehicle and travel time to reach the malfunctioning vehicle, and (ii) selecting whether to accept the rescue request; and
in response to receiving an acceptance indicating that the user of the rescue vehicle has accepted the rescue request, notifying the user of the malfunctioning vehicle that the rescue vehicle has been determined to rescue the malfunctioning vehicle,
transmitting the charging cost information, wherein the charging information is transmitted;
determining whether a malfunction has occurred in the associated vehicle by determining whether a condition for transmitting a rescue request has been met, wherein the condition for transmitting a rescue request is met when [detecting] at least one of:
(i) an operation performed by a user of the malfunctioning vehicle to transmit the rescue request, or
(ii) an on-board battery of the malfunctioning vehicle is depleted and there is no charging station within a predetermined distance from the malfunctioning vehicle, wherein the rescue request is transmitted when the on-board battery is depleted and there is no charging station within the predetermined distance;
notifying when it is determined that the malfunction has occurred;
displaying each of the one or more potential rescue vehicles and the reward;
transmitting information for identifying a vehicle selected from among the one or more potential rescue vehicles;
receiving the rescue request;
[presenting] (i) map information and a route from a current location of the associated vehicle to a current location of the malfunctioning vehicle and travel time to reach the malfunctioning vehicle, and (ii) selecting whether to accept the rescue request; and
transmitting an acceptance when [detecting] an acceptance operation within a predetermined time period and transmitting a non-acceptance result in response to failure to detect the acceptance operation within the predetermined time period, the non-acceptance result indicating that the rescue request is not accepted by the rescue vehicle.
The abstract idea steps italicized above relate to the selection of rescue vehicles and assignment of rewards based on rules or instructions communicated between parties, e.g., between a dispatcher, an individual requesting rescue, and an individual assisting with rescue, which constitutes a process that, under its broadest reasonable interpretation, covers managing personal behavior relationships, interactions between people. If a claim limitation, under its broadest reasonable interpretation, covers managing personal behavior relationships, interactions between people, including social activities, teaching, and/or following rules or instructions, then it falls within the Certain Methods of Organizing Human Activity – Managing Personal Behavior Relationships, Interactions Between People grouping of abstract ideas. Accordingly, the claim recites an abstract idea.
(Examiner notes that the extracting step entails no more than selecting a particular vehicle based on criteria. This is still an abstract step and part of the certain method of organizing human activity.)
Step 2A Prong Two: Does the claim recite additional elements that integrate the judicial exception into a practical application? MPEP 2106.04.
Claim 1 recites the following additional elements:
one or more processors; a storage medium on which a program to be executed by the one or more processors is stored, the program comprising one or more instructions; in the storage medium; causing a display on a display of the rescue vehicle; an operation element; automatically.
from vehicles; transmitted from a malfunctioning vehicle in which a malfunction has occurred; from the rescue vehicle; the malfunctioning vehicle [detects]; the rescue vehicle [detects]; from each of the vehicles to the information processing apparatus when the respective on-board battery of each of the vehicles is being charged; from the malfunctioning vehicle without user intervention; from the rescue vehicle to the information processing apparatus.
Claim 8 recites the following additional elements:
a first information processing apparatus on a server side; a second information processing apparatus associated with a vehicle; one or more first processors; a first storage medium on which a first program to be executed by the one or more first processors is stored, the first program comprising one or more first instructions; in the storage medium; one or more second processors; a second storage medium on which a second program to be executed by the one or more second processors is stored, the second program comprising one or more second instructions; extracted by the first information processing apparatus; performing display in accordance with reception of the rescue request; to the first information processing apparatus [without human intervention]; an operation element; automatically.
from vehicles; transmitted from a malfunctioning vehicle in which a malfunction has occurred; from the rescue vehicle; the malfunctioning vehicle [detects]; from each of the vehicles to the first information processing apparatus when the respective on-board battery of each of the vehicles is being charged; to the rescue vehicle; when the on-board battery of the associated vehicle is being charged.
The additional elements in category A are generically recited computers and machinery that are being used in their ordinary capacity to facilitate the tasks of the abstract idea, per MPEP 2106.05(f). Applicant has only described generic computing elements and machinery in their specification, as seen in the configuration of server apparatus 1, illustrated in Fig. 2 of applicant’s specification as filed, for example. Simply appending generic computing components to perform the tasks of the abstract idea doesn’t integrate said abstract idea into practical application. The additional elements in category B merely serve to generally link the abstract idea to a field of use, i.e., vehicles, per MPEP 2106.05(h). Similar to Flook, which limited the abstract idea to the petrochemical and oil-refining industries, the limitations describing the field of use don’t meaningfully limit or integrate the abstract idea into practical application.
Further, the combination of these elements is nothing more than a generic computing system tied to a field of use. Because the additional elements are merely instructions to apply the abstract idea to a computer, as described in MPEP 2106.05(f), and/or generally link to a field of use, as described in MPEP 2106.05(h), they do not integrate the abstract idea into a practical application.
Therefore, per Step 2A Prong Two, the additional elements, alone and in combination, do not integrate the judicial exception into a practical application. The claim is directed to an abstract idea.
Step 2B (The Inventive Concept): Does the claim recite additional elements that amount to significantly more than the judicial exception? MPEP 2106.05.
Step 2B involves evaluating the additional elements to determine whether they amount to significantly more than the judicial exception itself.
The examination process involves carrying over identification of the additional element(s) in the claim from Step 2A Prong Two and carrying over conclusions from Step 2A Prong Two pertaining to MPEP 2106.05(f), (h).
The additional elements and their analysis are therefore carried over: applicant has generically described computers and machinery that are being used in their ordinary capacity to facilitate the tasks of the abstract idea, as described in MPEP 2106.05(f), and/or generally link to a field of use, as described in MPEP 2106.05(h).
Further, the combination of these elements is nothing more than a generic computing system tied to a field of use. When the claim elements above are considered, alone and in combination, they do not amount to significantly more.
Therefore, per Step 2B, the additional elements, alone and in combination, are not significantly more. The claims are not patent eligible.
The analysis takes into consideration all dependent claims as well:
Claims 2-7 and 9-19 further narrow the abstract idea. There are no additional elements to consider, beyond those highlighted above. This narrowing of the abstract idea does not integrate into practical application and does not add significantly more. (Examiner notes that the extracting step in dependent claims entails no more than selecting a particular vehicle based on criteria. This is still an abstract step and part of the method of organizing human activity.)
Accordingly, claims 1-19 are rejected under 35 USC § 101 as being directed to non-statutory subject matter.
Response to Arguments
Applicant's arguments filed 7/02/26 have been carefully considered. Examiner’s response follows, with applicant’s headings used for consistency.
II. Objections to the Claims
Applicant’s amendments overcome the previous claim objections. These are withdrawn.
III. Rejections under 35 U.S.C. 101
Applicant offers, regarding the rejections under 35 U.S.C. 101, after restating examiner’s position:
Applicant respectfully disagrees but nevertheless has amended the claims in the interest of expediting prosecution of the present application. Upon entry of the foregoing amendments, Applicant respectfully submits that under Prong One of Step 2A in the 2019 Revised Patent Subject Matter Eligibility Guidance ("2019 PEG"), the claims as a whole are properly characterized as being directed to a specific improvement in vehicle telematics-based rescue coordination, rather than to the abstract ideas identified by the Office. To the extent any high-level aspect of the claims could be characterized as "managing personal behavior or relationships or interactions between people," that characterization does not capture what the claims are "directed to" under the 2019 PEG, because the core of the claimed invention is a particular technical architecture and control logic implemented in networked vehicles and a server.
Specifically, Applicant submits that amended independent claims 1 and 8 do not recite a method of organizing human activity, a category used by the Office to describe concepts relating to (1) fundamental economic principles or practices (including hedging, insurance, mitigating risk); (2) commercial or legal interactions (including agreements in the form of contracts, legal obligations, advertising, marketing or sales activities or behaviors, and business relations); and (3) managing personal behavior or relationships or interactions between people (including social activities, teaching, and following rules or instructions). MPEP 2106.04(a)(2)(II). Instead, the claims are directed to improving the operation of networked electric vehicles and their telematics systems by implementing event-driven vehicle-to-server and server-to-vehicle communications and specific on-board control behaviors for coordinating rescue operations.
While well taken, applicant appears to have conflated the abstract idea, identified at Step 2A Prong One, with the additional elements, identified at Step 2A Prong Two. While applicant may potentially arrive at an improved abstract idea, the claimed invention doesn’t represent an improvement to “the operation of networked electric vehicles and their telematics systems [accomplished] by implementing event-driven vehicle-to-server and server-to-vehicle communications and specific on-board control behaviors for coordinating rescue operations,” as argued by applicant.
Examiner identified the following abstract idea at Step 2A Prong One (claim 1 being representative):
obtaining charging information, the charging information comprising information on a respective on-board battery level and charging cost information pertaining to charging the respective on-board battery of a corresponding vehicle of the vehicles, the charging cost being a cost required to accumulate a predetermined unit power in the respective on-board batteries of the vehicles, wherein the charging information is transmitted;
storing the obtained charging information in association with the corresponding vehicle;
in response to obtaining updated charging information for the corresponding vehicle, updating the charging information stored in association with the corresponding vehicle with the updated charging information;
receiving a rescue request when [determining] that a condition for transmitting a rescue request has been met, the rescue request comprising rescue content pertaining to resolving the malfunction, wherein the condition for transmitting a rescue request is when [detecting] at least one of:
(i) an operation performed by a user of the malfunctioning vehicle to transmit the rescue request, or
(ii) an on-board battery of the malfunctioning vehicle is depleted and there is no charging station within a predetermined distance from the malfunctioning vehicle, wherein the rescue request is transmitted when the on-board battery is depleted and there is no charging station within the predetermined distance;
extracting, based on (i) the rescue content, (ii) the information on the respective on-board battery level, and (iii) the charging cost information pertaining to charging the respective on-board battery of a corresponding vehicle of the vehicles, one or more vehicles capable of resolving the malfunction as one or more potential rescue vehicles from among the vehicles;
calculating a reward based on (i) the rescue content, (ii) the information on the respective on-board battery level, and (iii) the charging cost information pertaining to charging the respective on-board battery for each of the one or more potential rescue vehicles;
presenting each of the one or more potential rescue vehicles and the reward to a user of the malfunctioning vehicle;
identifying a vehicle selected by the user of the malfunctioning vehicle from among the one or more potential rescue vehicles as a rescue vehicle to rescue the malfunctioning vehicle; and
notifying a user of the rescue vehicle of the rescue request by [presenting] (i) map information and a route from a current location of the rescue vehicle to a current location of the malfunctioning vehicle and travel time to reach the malfunctioning vehicle, and (ii) selecting whether to accept the rescue request; and
in response to receiving an acceptance indicating that the user of the rescue vehicle has accepted the rescue request, notifying the user of the malfunctioning vehicle that the rescue vehicle has been determined to rescue the malfunctioning vehicle, wherein the acceptance is transmitted when [detecting] an acceptance operation within a predetermined time period, and wherein a non-acceptance result is transmitted in response to failure to detect the acceptance operation within the predetermined time period, the non-acceptance result indicating that the rescue request is not accepted by the rescue vehicle.
Examiner notes that there’s nothing inherently technical about these steps. While they do contain reference to obtaining battery charging information, extracting (i.e., selecting) a potential rescue vehicle, calculating a reward associated with the rescue, and presenting options, examiner contends that these are steps an administrator could perform, in communication with the party in need of rescue and/or central dispatch. (Obtaining battery charging information, for example, could entail no more than an administrator referencing a vehicle status printout.)
That the steps of the abstract idea are being facilitated by additional elements – e.g., one or more processors, a storage medium on which a program to be executed by the one or more processors is stored, from vehicles, etc. – does not translate into patent eligibility. Simple using generic computing elements to perform the tasks of the abstract idea is equivalent to “apply it,” per MPEP 2106.05(f). Further, merely linking an abstract idea to a field of use doesn’t meaningfully limit the claim, per MPEP 2106.05(h). These sections of the MPEP are clear that this does not integrate the abstract idea into practical application and/or add significantly more.
Applicant continues (brackets indicate portions of applicant’s response omitted for brevity):
Applicant amends claims 1 and 8 by adding additional technical elements that demonstrate specific technical implementations beyond generic data processing. In particular, the amendments add: […]
From a technical perspective, the present invention addresses the problem that conventional networked electric vehicle systems cannot reliably and promptly coordinate rescue operations when a vehicle unexpectedly depletes its battery, particularly in regions with sparse charging infrastructure and dynamically changing charging costs. As described in, for example, paragraphs [0062]-[0063], [0068], [0094]-[0095], [0100], [0102], [0115], and [0187] of the Specification, the claimed architecture improves the operation of the vehicles and telematics server by implementing event-driven communication and automatic control logic that reduce latency, maintain up-to-date charging cost information, and prevent failed rescues due to missed or delayed responses. The system also ensures reward accuracy by storing the obtained charging information in association with the corresponding vehicle and updating that stored vehicle-specific information when updated charging information is obtained, so that the reward calculation is based on the charging cost at the time of the most recent charge.
Under Step 2A, Prong Two, even if certain high-level aspects of the claims could be characterized as involving management of rescue assignments or rewards, Applicant submits that the amended claims, taken as a whole, do not recite an abstract idea because any such judicial exception is integrated into a specific practical application in a distributed vehicle-server rescue coordination system. The Office characterized the claims as "managing personal behavior relationships, interactions between people." However, several of the newly added limitations cannot practically be performed in the human mind or through human organization. For example, automatic detection of battery depletion combined with charging station proximity analysis to trigger rescue requests without user intervention is not something "an administrator could perform," as the Office suggested-it requires real-time integration of vehicle battery monitoring systems with charging infrastructure data. Similarly, automatic push-based transmission of charging data during charging events is an event-driven machine-to-machine communication protocol-because the vehicles automatically transmit this data when charging occurs, the server can maintain up-to-date charging cost information without the need for continuous polling. Furthermore, automatic transmission of a non-acceptance result when no user operation is detected within a time period is a fail-safe control behavior triggered by absence of input-this cannot be characterized as "following rules or instructions" between people. Additionally, the storing of the obtained charging information in the storage medium in association with the corresponding vehicle and updating it with updated charging information for that vehicle is a concrete data management operation on the server's storage medium that ensures the reward calculation is based on the most current charging cost for each vehicle-this is not abstract data manipulation but a specific technical action on the server's storage that maintains data currency for accurate downstream calculations.
Even if some claim elements could be characterized as abstract, and solely for purposes of analysis under Step 2A, Prong Two, Applicant submits that the claims as a whole integrate any alleged abstract idea into a practical application through "other meaningful limitations" per MPEP 2106.04(d)(2). The amended claims recite a specific, multi-device rescue coordination protocol with concrete technical actions on vehicle systems that go far beyond generic data processing. The claims employ the results of the analysis (rescue vehicle selection, reward calculation) to control vehicle-side systems in specific ways: […] These are not merely "notifying" in the abstract-they are specific control actions on vehicle display systems and communication systems that produce tangible technical outcomes.
Applicant continues to conflate the abstract idea, identified at Step 2A Prong One, with the additional elements, identified at Step 2A Prong Two. Examiner identified the following additional elements at Step 2A Prong Two (claim 1 being representative):
one or more processors; a storage medium on which a program to be executed by the one or more processors is stored, the program comprising one or more instructions; in the storage medium; causing a display on a display of the rescue vehicle; an operation element; automatically.
from vehicles; transmitted from a malfunctioning vehicle in which a malfunction has occurred; from the rescue vehicle; the malfunctioning vehicle [detects]; the rescue vehicle [detects]; from each of the vehicles to the information processing apparatus when the respective on-board battery of each of the vehicles is being charged; from the malfunctioning vehicle without user intervention; from the rescue vehicle to the information processing apparatus.
Examiner’s position is that these elements, whether viewed alone or in combination, do not integrate the abstract idea into practical application and do not represent a “specific technological implementations,” as suggested by applicant. MPEP 2106.05(f), cited above, is clear that, unless there’s a “technological solution to a technological problem” described in the specification and reflected in the claimed invention, the mere recitation of computing elements is equivalent to “apply it”:
(2) Whether the claim invokes computers or other machinery merely as a tool to perform an existing process. Use of a computer or other machinery in its ordinary capacity for economic or other tasks (e.g., to receive, store, or transmit data) or simply adding a general purpose computer or computer components after the fact to an abstract idea (e.g., a fundamental economic practice or mathematical equation) does not integrate a judicial exception into a practical application or provide significantly more. See Affinity Labs v. DirecTV, 838 F.3d 1253, 1262, 120 USPQ2d 1201, 1207 (Fed. Cir. 2016) (cellular telephone); TLI Communications LLC v. AV Auto, LLC, 823 F.3d 607, 613, 118 USPQ2d 1744, 1748 (Fed. Cir. 2016) (computer server and telephone unit). Similarly, "claiming the improved speed or efficiency inherent with applying the abstract idea on a computer" does not integrate a judicial exception into a practical application or provide an inventive concept. Intellectual Ventures I LLC v. Capital One Bank (USA), 792 F.3d 1363, 1367, 115 USPQ2d 1636, 1639 (Fed. Cir. 2015). In contrast, a claim that purports to improve computer capabilities or to improve an existing technology may integrate a judicial exception into a practical application or provide significantly more. McRO, Inc. v. Bandai Namco Games Am. Inc., 837 F.3d 1299, 1314-15, 120 USPQ2d 1091, 1101-02 (Fed. Cir. 2016); Enfish, LLC v. Microsoft Corp., 822 F.3d 1327, 1335-36, 118 USPQ2d 1684, 1688-89 (Fed. Cir. 2016). See MPEP §§ 2106.04(d)(1) and 2106.05(a) for a discussion of improvements to the functioning of a computer or to another technology or technical field.
MPEP 2106.05(h) is also supportive of examiner’s position:
Another consideration when determining whether a claim integrates the judicial exception into a practical application in Step 2A Prong Two or recites significantly more than a judicial exception in Step 2B is whether the additional elements amount to more than generally linking the use of a judicial exception to a particular technological environment or field of use. As explained by the Supreme Court, a claim directed to a judicial exception cannot be made eligible “simply by having the applicant acquiesce to limiting the reach of the patent for the formula to a particular technological use.” Diamond v. Diehr, 450 U.S. 175, 192 n.14, 209 USPQ 1, 10 n. 14 (1981). Thus, limitations that amount to merely indicating a field of use or technological environment in which to apply a judicial exception do not amount to significantly more than the exception itself, and cannot integrate a judicial exception into a practical application.
Based on MPEP 2106.05(f) and 2106.05(h), the additional elements, whether viewed alone or in combination, do not integrate the abstract idea into practical application or meaningfully limit the claim. Applicant’s specification and claimed invention describe improvements to identifying and selecting rescue vehicles, i.e., a business process. This is not a technological solution, as applicant argues.
Applicant continues:
In the 2019 PEG, Example 42 (Medical Record Updates) presents an analogous situation. In Example 42, Claim 1 was found eligible because it recited "a specific improvement over prior art systems by allowing remote users to share information in real time in a standardized format regardless of the format in which the information was input by the user." Similarly, amended claims 1 and 8 recite a specific improvement in EV rescue coordination technology: vehicles automatically push charging data during charging events (ensuring up-to-date cost information without polling), the system automatically detects rescue conditions based on battery state and charging infrastructure proximity, and the rescue vehicle's display is controlled to present a specialized rescue-operation interface with map and route information. This is a specific distributed architecture for real-time EV rescue coordination, not merely a generic notification system. In particular, by limiting communications to event-triggered transmissions and by defining specific automatic control responses to technical conditions (such as battery depletion and absence of nearby charging stations), the claimed system reduces unnecessary network traffic and latency compared to conventional polling-based or manually initiated systems.
In the 2019 PEG, Example 46 (Livestock Management) presents an analogous situation to the present claims. In Example 46, claims 2 and 3 were found eligible because they used the result of abstract analysis to control another machine (a feed dispenser or sorting gate) in a particular way, which was an "other meaningful limitation." The USPTO found that "limitation (d) does not merely link the judicial exceptions to a technical field, but instead adds a meaningful limitation in that it can employ the information provided by the judicial exception to operate the feed dispenser." Similarly, amended claims 1 and 8 use the results of the rescue vehicle selection and reward calculation to control vehicle-side systems: the rescue vehicle's display is caused to present specific map/route information, and the system automatically transmits non-acceptance when no user operation is detected. These are genuine vehicle-side control functions analogous to Example 46's control of the feed dispenser.
In the 2019 PEG, Example 40 (Network Traffic Monitoring) also provides relevant guidance. In Example 40, Claim 1 was found eligible because it limited collection of additional data to when initially collected data reflected an abnormal condition, providing "a specific improvement over prior systems, resulting in improved network monitoring." Similarly, amended claims 1 and 8 implement event-driven data collection: charging information is automatically transmitted when the vehicle is being charged, which enables the server to maintain up-to-date information without continuous polling, and rescue requests are automatically triggered only when specific technical conditions are met (battery depleted AND no charging station nearby). This adaptive, condition-based communication architecture provides a specific improvement in EV fleet management.
The Office characterized the additional elements as generic computing components under MPEP 2106.05(f) and field-of-use limitations under MPEP 2106.05(h). However, the amended claims go well beyond generic computing. The automatic push-based charging data transmission, the environment-dependent automatic rescue triggering (battery depletion combined with no charging station), the specialized rescue-vehicle HMI (map/route), and the timeout-based automatic non-acceptance are not generic computer functions-they are specific technical behaviors of a distributed vehicle-server system. Per MPEP 2106.04(d)(1), "the specification need not explicitly set forth the improvement, but it must describe the invention such that the improvement would be apparent to one of ordinary skill in the art." The Specification describes these improvements in detail at paragraphs [0062]-[0063], [0094]-[0095], [0100], [0102], and [0187].
The Office stated that "Applicant's specification and claimed invention describe improvements to identifying and selecting rescue vehicles, i.e., a business process." However, the amended claims now go beyond mere selection-they recite specific technical control actions on vehicle systems (automatic rescue triggering based on battery/infrastructure state, specialized HMI control, timeout-based fail-safe communication). These are improvements to the technical field of networked EV rescue coordination, not merely improvements to a business process.
Applicant submits that amended claims 1 and 8 recite a complete rescue coordination process that culminates in a tangible end result. The amended claims now recite a complete vehicle-to-server-to-vehicle communication loop. In such a communication loop, the server notifies the rescue vehicle of the rescue request with specific map/route information, the server receives an acceptance or automatic non-acceptance transmitted from the rescue vehicle, and the server then notifies the malfunctioning vehicle that a rescue vehicle has been determined to perform the rescue. This closed-loop communication results in a concrete technological outcome-the malfunctioning vehicle's system receives confirmation that rescue has been arranged, thus the rescue coordination is completed thereby triggering and initiating the rescue.
The claims do not merely recite data processing steps, but additionally they recite a specific technological implementation that coordinates communications between multiple vehicle systems and a server to achieve a practical result. In particular, the amended claims 1 and 8 recite that the notifying step causes a display of the rescue vehicle to present map information and a route from the rescue vehicle's current location to the malfunctioning vehicle, which is a tangible control action on the rescue vehicle's display system.
In the 2019 PEG, Example 35 (ATM Transactions) also presents a similar situation. In Example 35, Claim 3 was found eligible because it included "automatically sending a control signal to an input for the automated teller machine to provide access to a keypad when a match from the analysis verifies the authenticity of the customer's identity." Similarly, amended claims 1 and 8 include responsive actions (notifying the malfunctioning vehicle and causing a display of the rescue vehicle to present specific information, or automatically transmitting non-acceptance) that are triggered in response to specific conditions. This is analogous to the ATM sending a control signal in response to verifying identity.
Amended claims 1 and 8 collect technical state data (battery level, charging cost per kWh, equipment, distance/time) and rescue content, analyze that data to identify suitable rescue vehicles and compute rewards, and then use the result to control a distributed technical system through a closed-loop rescue protocol. Specifically, the amended claims now recite that: (i) the charging information is automatically transmitted from vehicles when the on-board battery is being charged, enabling the server to maintain current charging cost data; (ii) the malfunctioning vehicle automatically transmits a rescue request when the on-board battery is depleted and there is no charging station within a predetermined distance; (iii) the rescue vehicle's display presents map information and a route, and an operation element for accepting or rejecting the rescue request; and (iv) the rescue vehicle automatically transmits a non-acceptance result when no acceptance operation is detected within a predetermined time period. These are genuine vehicle-side control functions that use the result of the server's analysis to control the behavior of the vehicle-side apparatuses.
Applicant’s attempt to draw parallels to the USPTO’s Eligibility Examples, while appreciated, is also not persuasive, given that these examples reflect an improvement to technology. This is distinct from applicant’s invention reflected in claims 1 and 8, which seek to improve the management of rescue operations. Applicant’s specification is generally supportive of examiner’s position, as seen in para. [0020]-[0024]. Rather than detailing shortcomings with battery and/or telematics technology, the problems articulated by applicant (i.e., “cost of charging on-board batteries,” “electricity rates,” “rescuers may end up incurring losses,” “[presenting] appropriate rewards to rescuers”) are associated with rescue management. Additionally, unlike the cited examples, the combination of elements – e.g., one or more processors, a storage medium on which a program to be executed by the one or more processors is stored, from vehicles, etc. – are merely facilitating the tasks of the abstract idea and/or generally linking to the field of use. Simply using generic computing elements to perform the tasks of the abstract idea is equivalent to “apply it,” per MPEP 2106.05(f). Further, merely linking an abstract idea to a field of use doesn’t meaningfully limit the claim, per MPEP 2106.05(h). These sections of the MPEP are clear that this does not integrate the abstract idea into practical application and/or add significantly more.
Applicant continues, regarding Step 2B:
Even assuming, arguendo, for purposes of Step 2B of the Alice/Mayo framework, that the claims are directed to an abstract idea, Applicant submits that the claims recite additional elements that, individually and as an ordered combination, amount to significantly more than the alleged judicial exception under Step 2B.
The same additional elements that integrate the abstract idea into a practical application under Step 2A Prong Two also provide an inventive concept under Step 2B. Specifically, the amended claims recite: (i) automatic push-based transmission of charging information from vehicles during charging events; (ii) automatic rescue request transmission triggered by the combination of battery depletion and absence of a charging station within a predetermined distance; (iii) causing the rescue vehicle's display to present map information and a route from the rescue vehicle's current location to the malfunctioning vehicle; (iv) automatic transmission of a non-acceptance result when no acceptance operation is detected within the predetermined time period; and (v) storing the obtained charging information in association with the corresponding vehicle and updating it with updated charging information for that vehicle to ensure the reward reflects the most current charging cost. These elements, when considered in combination, reflect a specific, non-conventional arrangement of technical components in a distributed vehicle-server rescue coordination system.
In BASCOM Global Internet v. AT&T Mobility LLC, 827 F.3d 1341, 1350 (Fed. Cir. 2016), the Federal Circuit held that "when combined, an inventive concept may be found in the non- conventional and non-generic arrangement of the additional elements." Even if individual elements such as processors, storage media, displays, and vehicles are conventional, the particular arrangement recited in amended claims 1 and 8-where vehicles automatically push charging data during charging events, the vehicle-side apparatus automatically detects a rescue condition based on battery state and charging infrastructure proximity and transmits a rescue request without user intervention, the server causes the rescue vehicle's display to present map/route information, and the rescue vehicle automatically transmits a non-acceptance result upon timeout-constitutes a non-conventional and non-generic arrangement that provides an inventive concept. Moreover, the Office has not identified, and cannot rely on, any evidence that this specific arrangement of vehicle-side sensing, event-driven communication, server-side processing, and rescue-vehicle HMI control is well-understood, routine, and conventional, as required by MPEP 2106.07(a).
The Office stated that "novelty is not equivalent to eligibility" and that "an improved abstract idea is still an abstract idea." Applicant does not conflate novelty with eligibility. However, the novelty point is relevant at Step 2B because the Office bears the burden of establishing that the additional elements, individually and in combination, are well-understood, routine, and conventional. The Office has not made such a showing for the specific combination of technical features now recited in amended claims 1 and 8. Moreover, the Office has indicated that all pending claims are in condition for allowance over the prior art of record, which supports a conclusion that the claimed subject matter is not well-understood, routine, or conventional in the field. While novelty alone does not establish eligibility, the absence of prior art teaching the claimed combination is consistent with, and supports, a conclusion that the combination of additional elements is not well-understood, routine, and conventional activity. Accordingly, the Office's recognition of the claims' patentable distinction over the prior art supports a finding under Step 2B of the Alice/Mayo framework that the additional elements, individually and in combination, amount to "significantly more" than any alleged judicial exception, and that the claims recite patent-eligible subject matter under 101.
Examiner first notes that the phrase “well-understood, routine, and conventional” was not used to describe the additional elements. Instead, per MPEP 2106, examiner “carried over” the analysis from Step 2A Prong Two, where it was determined that the additional elements, alone and in combination, merely facilitate the tasks of the abstract idea and/or generally link the abstract idea to a field of use.
The comparison to BASCOM isn’t apt, given that the court recognized a technological solution provided via the combination of elements in its decision, where the combination of elements solved a particular technological problem. The same cannot be said about applicant’s claimed invention.
Lastly, there is no basis in the MPEP regarding applicant’s assertion that “the absence of prior art teaching the claimed combination is consistent with, and supports, a conclusion that the combination of additional elements is not well-understood, routine, and conventional activity.” Examiner therefore maintains that the claims are ineligible.
In summary, examiner has responded to all of applicant arguments concerning the rejections under 35 U.S.C. 101. The rejections are maintained.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
US 20190392367, which teaches rewarding rescue vehicles: [0089] Generally, the roadside assistance service provider system 600 may include a collection module 610, an assignment module 620, and a feedback module 630. In the collection module 610 (or gathering/collection module), sensors on a tow truck or other similar vehicles (e.g. whether the flatbed is down, GPS location monitoring, etc.), smartphone user interfaces, and historical statistics about roadside assistance services (e.g. the historical average time for changing a flat tire, for jumping a dead battery, etc.) may be collected from the real world and stored in a data store, then analyzed using particular rules and/or formats. In the assignment module 620, particular roadside assistance service providers may be assigned to particular distressed vehicles/drivers based on one or more characteristics, including characteristics/rules from the collection module 610. For example, the assignment module 620 may match/assign a driver that only speaks Polish with a tow truck driver that understands Polish. Other characteristics/criteria utilized by the assignment module 620 may include proximity in location, prior user ratings, equipment on the tow truck, skillset/expertise of the driver of the tow truck, price/cost of the tow truck roadside assistance services, etc. The feedback/display module 630 may provide near real-time cues to the tow truck driver's mobile device, such as alerting when the amount of time spent on a task exceeds a predefined threshold, flagging high priority tasks/assignments, providing a technical reference for the repair, etc., and award points/score to the tow truck driver.
US 20230053196, which teaches a reward module for rescue vehicles: [0108] The reward module 640 may be configured to provide a reward to an individual driver or roadside assistance service provider or roadside assistance service provider company if particular times are met. For example, the reward may allow a driver to move up in a queue in a definitive way if the roadside assistance service provider beats the estimate time or suggested times. Additionally, the reward module 640 may provide an individual driver or roadside assistance service provider an additional award if the job or tasks are done more quickly. The reward module 640 may provide awards based on accurate estimates and not necessarily doing a job or task more quickly.
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 nonprovisional extension fee (37 CFR 1.17(a)) 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 JOHN SAMUEL WASAFF whose telephone number is (571)270-5091. The examiner can normally be reached Monday through Friday 8:00 am to 6:00 pm.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, SARAH MONFELDT can be reached at (571) 270-1833. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
JOHN SAMUEL WASAFF
Primary Examiner
Art Unit 3629
/JOHN S. WASAFF/ Primary Examiner, Art Unit 3629
Prosecution Insights