DETAILED ACTION
Status of the Application
This Final Office Action is in response to Application Serial 18/186,407. In response to Examiner’s action that is mail dated April 16, 2026, Applicant provided amendments and arguments that are mail dated July 10, 2026. Applicant amended claims 1, 2, 9. 10, and 16. Claims 1-20 are pending. Examiner notes the Application was suspended for three years.
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 . 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 (i.e., changing from AIA to pre-AIA ) 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.
Information Disclosure Statement
Applicant did not submit an information disclosure statements (IDS) to be considered by the examiner.
Response to Amendments
Regarding June 30, 2026, interview, Examiner submits there were no agreements made during the interview. Interviews are generally opportunities to clarify interpretations. Furthermore, Examiner urges the Applicant to correct the Markush claims, so that the embodiment of the inventions are clear.
Applicant has not corrected the Markush claims. Examiner’s rejection for the unamended claims remains the same. See rejection below.
Claims 1-20 are pending in this application. Claims 1, 2, 9. 10, and 16 are amended.
Regarding the 35 U.S.C. 101 rejection, the amendments are not persuasive. The claims 1-20 are rejected under 35 U.S.C. 101, see below.
Regarding the 35 U.S.C. 102 rejection, the amendments are considered below.
Regarding the 35 U.S.C. 103 rejection, the amendments are considered below.
Response to Arguments
Applicant’s arguments filed on July 10, 2026, have been fully considered but they are not persuasive and/or are moot in view of the revised rejections. Applicant’s arguments will be addressed herein below.
Claim Rejections under 35 U.S.C. 101
On pages 13-19 of the Applicant’s 35 U.S.C. 101 arguments, Applicant traverses Examiner’s 35 U.S.C. 101 arguments.
On pages 13-15, Applicant submits the currently amended claims are not directed to an abstract idea under Alice Step 2A Prong one. Applicant’s arguments rely on amendments. Applicant submits the asserted an abstract idea does not accurately reflect what the currently amended claims actually recite when evaluated in their entirety under Alice Step 2A, prong one.
Examiner respectfully disagrees. Examiner submits the claims, under the broadest reasonable interpretation, recite the abstract concept of gathering information and matching transportation. This is a commercial activity, and thus, is grouped as a certain method of organizing human activity. Furthermore, the claims suggest vehicle maintenance, use of a personal vehicle, or a rideshare. This is a decision process, which is a mental concept. The claims recite certain methods of organizing human activity and mental concepts, and therefore, which are abstract groupings, so the claims are directed to a judicial exception.
On pages 15-27 of the Applicant’s argument, the Applicant submits the claims are eligible under Step 2A, Prong Two of the revised eligibility guidance. Applicant’s arguments include Example 48 ( Speech Separation). Applicant traverses the notification model and the prediction model are integrated into a practical application that improves the operation of the transportation matching application features, and the interaction probability, rather than merely calculating or displaying an abstract analytical result.
Examiner respectfully disagrees with Applicant’s Step 2A, prong two arguments. At Step 2A, prong two, the claims are evaluated for integration into a practical application. The additional elements are examined for integration into a practical application The claims are examined for an improvement.
The Examiner submits the claims are not integrated into a practical application. The claims recite are merely applying a computer to conduct judicial exception. See MPEP 2106.05(f).
Furthermore, the Applicant’s amendments are similar to SME Example 47 rather than Example 48. Example 47 considers a neural network. The Applicant amended the claims to recite a notification model, a prediction model, and machine learning model. These models are recited as apply it. MPEP 2106.05(f). Examiner points Applicant to specification [037]-[038].
Examiner submits, Applicant did not provide a Step 2B argument.
Examiner points the Applicant to the pending 35 U.S.C. 101 arguments. Furthermore, the Applicant is encouraged to look at all of the Examiner rejections and make amendments that will aid in moving prosecution forward should the Applicant decide to continue examination.
Examiner recommends an interview to discuss the models.
Claim Rejections under 35 U.S.C. 102 and 35 U.S.C. 103
On pages 19-27 of the Applicant’s prior art arguments, Applicant traverses the cited prior art.
Regarding the pending 35 U.S.C. 102 rejection, Applicant submits Hinduja, does not anticipate the amended independent claim 1, 9, and 16. Hinduja, does not anticipate the dependent claims 2-8, 10-15, 17-19.
Regarding the pending 35 U.S.C. 103 rejection Applicant submits the prior art Hinduja inview of McClintric are not obvious. Applicant submits the prior does not teach or suggest the amended limitations. Applicant submits the pending claims are allowable.
Examiner respectfully disagrees with Applicant’s prior art arguments. Examiner first submits the amendments necessitate grounds for a new rejection. Second, the Examiner encourages Applicant to review the Markush rejection. Examiner submits the metes and bounds of the claims are not clear. Examiner has maintained the prior art rejection. Examiner puts additional prior art to teach the amendments.
Furthermore, Examiner points Applicant to specification [061].
Claim Rejections - 35 USC § 112, First Paragraph
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims 1-8 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for pre-AIA the inventor(s), at the time the application was filed, had possession of the claimed invention.
Claim 1 recites “vehicle service features from monitoring data packets of a plurality of service management computing devices,” However, Applicant’s specification does not in expressly or inherently require data packets as required by the claims.
In order to satisfy the written description requirement, each claim limitation must be expressly or inherently supported by the disclosure. MPEP 2163 (emphasis added). "The 'written description' requirement implements the principle that a patent must describe the technology that is sought to be patented; the requirement serves both to satisfy the inventor's obligation to disclose the technologic knowledge upon which the patent is based, and to demonstrate that the patentee was in possession of the invention that is claimed.” Capon v. Eshhar, 76 USPQ2d 1078, 1084 (Fed. Cir. 2005) (emphasis added). Further, the written description requirement promotes the progress of the useful arts by ensuring that patentees adequately describe their inventions in their patent specifications in exchange for the right to exclude others from practicing the invention for the duration of the patent's term. See MPEP 2163 (emphasis added).
For claims directed toward computer-implemented functions, like the presently claimed invention, “[i]f the specification does not provide a disclosure of the computer and algorithm in sufficient detail to demonstrate to one of ordinary skill in the art that the inventor possessed the invention including how to program the disclosed computer to perform the claimed function, a rejection under 35 U.S.C. 112(a) or pre-AIA 35 U.S.C. 112, first paragraph, for lack of written description must be made.” MPEP 2161.01 (emphasis added). It is not enough that one skilled in the art could write a program to achieve the claimed function because the written description requirement requires that the specification explains how the inventor intends to achieve the claimed function. Examining Claims for Compliance with 35 USC 112(a) - PowerPoint of Computer Based Training, Slides 20 & 21, (emphasis added) available at http://www.uspto.gov/ sites/default/files/documents/uspto_112a_ part1_17aug2015.pptx. The ability of one skilled in the art to make and use the claimed invention does not satisfy the written description requirement if details of how the function is to be performed are not disclosed. Id. at Slide 20.
With respect to the recitation of “vehicle service features from monitoring data packets of a plurality of service management computing devices …,” the specification does not expressly or inherently require “… monitoring of data packet…”.
In various portions of the specification, the specification discusses monitoring the system 400, monitoring transportation matching, and monitoring various client applicants [074], [076], [078]. Accordingly, although the specification discloses that a monitoring, the specification does not expressly or inherently require “monitoring data packets” as claimed.
Claims 2-8 depend on claim 1 and do not cure the aforementioned deficiencies, and thus, claims 2-8 are rejected for the reasons set forth above for claim 1. Claim 1-8 are rejected under 35 U.S.C. 112.
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.
Claim(s) 1, 4, 5, 7, 9, 12, 13, 15, 16, 17, and 20 are rejected on the basis that it contains an improper Markush grouping of alternatives. See In re Harnisch, 631 F.2d 716, 721-22 (CCPA 1980) and Ex parte Hozumi, 3 USPQ2d 1059, 1060 (Bd. Pat. App. & Int. 1984). A Markush grouping is proper if the alternatives defined by the Markush group (i.e., alternatives from which a selection is to be made in the context of a combination or process, or alternative chemical compounds as a whole) share a “single structural similarity” and a common use. A Markush grouping meets these requirements in two situations. First, a Markush grouping is proper if the alternatives are all members of the same recognized physical or chemical class or the same art-recognized class, and are disclosed in the specification or known in the art to be functionally equivalent and have a common use. Second, where a Markush grouping describes alternative chemical compounds, whether by words or chemical formulas, and the alternatives do not belong to a recognized class as set forth above, the members of the Markush grouping may be considered to share a “single structural similarity” and common use where the alternatives share both a substantial structural feature and a common use that flows from the substantial structural feature. See MPEP § 2117.
The Markush grouping of those described in claims 1, 4, 5, 7, 9, 12, 13, 15, 16, 17, and 20 is/are improper because the alternatives defined by the Markush grouping provide alternatives to the invention and therefore, is unclear what the current claims are requiring.
To overcome this rejection, Applicant may set forth each alternative (or grouping of patentably indistinct alternatives) within an improper Markush grouping in a series of independent or dependent claims and/or present convincing arguments that the group members recited in the alternative within a single claim in fact share a single structural similarity as well as a common use.
Examiner recommends an interview to discuss the Markush claims.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claim(s) 1-8 is/are process.
Claim(s) 9-15 is/are machine.
Claim(s) 16-20 is/are manufacture.
The claims (claim 1 and similarly claim 9 and claim 16) recite, “… … determining monitoring vehicle service features from monitoring data packets of … wherein the vehicle service features are based on vehicle data captured… ; determining transportation matching features from monitoring… to determine transportation matching features… , wherein the transportation matching features comprises a number of provider computing devices within a geographic region based on GPS location data of the number of provider computing devices; generating, utilizing … to analyze the vehicle service features and the transportation matching features for the plurality of provider computing devices comprising the number of provider computing devices within the geographic region, a notification for … based on the vehicle service features … and the transportation matching features… ; generating, utilizing… , an interaction probability based on the vehicle service features, the transportation matching features, and the notification generated …analyzing the vehicle service features and the transportation matching features; and providing, based on the interaction probability, the notification for display… wherein the notification comprises at least one of: a vehicle management notification, a transportation recommendation, or a transportation match notification indicating a transportation match … .” T recite the abstract concept of gathering information and matching transportation. This is a commercial activity, and thus, is grouped as a certain method of organizing human activity. Furthermore, the claims suggest vehicle maintenance, use of a personal vehicle, or a rideshare. This is a decision process, which is a mental concept. The claims recite certain methods of organizing human activity and mental concepts, and therefore, which are abstract groupings, so the claims are directed to a judicial exception at Step 2A, prong one.
The judicial exception is not integrated into a practical application under the second prong of Step 2A. In particular, the claims recite the additional elements beyond the recited abstract idea of, “A computer-implemented method comprising :”, “a plurality of service management computing devices, ”, “by the plurality of service management computing devices”, “ a plurality of provider computing devices, via a transportation matching application,” “for the plurality of provider computing devices”, “a notification model”, “a transportation application of a client device ”, “from the plurality of service management computing devices”, “for the plurality of provider computing devices”, “a prediction model”, “ via a graphical user interface of the transportation application on the client device”; however, when viewed as an ordered combination, and pursuant to the broadest reasonable interpretation, each of the additional elements are computing elements recite adding the words “apply it” (or an equivalent) with the judicial exception, or mere instructions to implement an abstract idea on a computer or merely uses a computer as a tool to perform an abstract idea – see MPEP 2106.05 (f).
The dependent claims do not recite additional elements
Machine learning model (claim 2, 10)
(Regarding the limitations that recite … region based on GPS location data of the number of provider computing devices; … and … the number of provider computing devices within the geographic region,.. these are data inputs/outputs).
Accordingly, the additional elements do not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea. The claims also fails to recite any improvements to another technology or technical field, improvements to the functioning of the computer itself, use of a particular machine, effecting transformation or reduction of a particular article to a different state or thing, and/or an additional element applies or uses the judicial exception in some other meaningful way beyond generally linking the use of the judicial exception to a particular technological environment, such that the claim as a whole is more than a drafting effort designed to monopolize the exception.
The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above, because the additional elements when considered both individually and as an ordered combination do not amount to significantly more. (See MPEP 2106.05 (f) Mere Instruction to Apply an Exception – Thus, for example, claims that amount to nothing more than an instruction to apply the abstract idea using a generic computer do not render an abstract idea eligible.” Alice Corp., 134 S. Ct at 235).
At Step 2B, it is MPEP 2106.05 (d) – Receiving or transmitting data over a network, e.g., using the Internet to gather data, Symantec, 838 F.3d at 1321, 120 USPQ2d at 1362 (utilizing an intermediary computer to forward information).
Examiner concludes that the additional elements in combination fail to amount to significantly more than the abstract idea based on findings that each element merely performs the same function (s) in combination as each element performs separately. The claim is not patent eligible. Thus, taken alone, the additional elements do not amount to significantly more than the above-identified exception (the abstract idea). Looking at the limitation as an ordered combination adds nothing that is not already present when looking at the elements taken individually.
Dependent claims 2-8 further narrow the abstract idea of independent claim 1. The claims 1-8 are not patent eligible.
Dependent claims 10-15 further narrow the abstract idea of independent claim 9. The claims 9-15 are not patent eligible.
Dependent claims 17-20 further narrow the abstract idea of independent claim 9. The claims 16-20 are not patent eligible.
Moreover, aside from the aforementioned additional elements, the remaining elements of dependent claims 2-8, 10 -15, 17-20 do not transform the recited abstract idea into a patent eligible invention because these claims merely recite further limitations that provide no more than simply narrowing the recited abstract idea.
Since there are no limitations in these claims that transform the exception into a patent eligible application such that these claims amount to significantly more than the exception itself, claims 1-20 are rejected under 35 U.S.C. 101 as being directed to non-statutory subject matter.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The text of those sections of Title 35, U.S. Code not included in this action can be found in a prior Office action.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claim(s) 1, 2, 4, 5, 7, 9, 10, 12, 13, 16, 17 and 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Hinduja (WO 2022/0,911,120 A1) in view of Rong (CN 109670703 B).
Regarding Claim 1, (Currently Amended)
A computer-implemented method comprising: determining vehicle service features from monitoring data packets of a plurality of service management computing devices, wherein the vehicle service features are based on vehicle data captured by the plurality of service management computing devices;
Hinduja [abstract] teaches a method for dynamic maintenance scheduling includes receiving, by a server, first maintenance data, first vehicle data, first booking data, and a plurality of maintenance plans associated with a plurality of vehicles., Hinduja [abstract],
Hinduja [p.3 lines 16-19] discloses the server is further configured to determine a plurality of features and a corresponding plurality of feature values for each of the plurality of vehicles based on the first maintenance data, the first vehicle data, the first booking data, and the plurality of maintenance plans. The server is further configured to train a prediction model based on the plurality of features and the corresponding plurality of feature values.
Hinduja [p.4 lines 9-20] teaches features include a meantime between consecutive failures of a vehicle, a count of major accidents, a count of non-scheduled maintenance, and thus, Hinduja teaches vehicle service features.
Hinduja [p.8 lines 24-30] teaches the booking data may be further indicative of utilization and inactivity period of each vehicle 102a-102d. For example, the booking data of a vehicle may indicate whether the vehicle is overutilized, under-utilized, or as expected utilized. Over-utilization of the vehicle may negatively impact the health of the vehicle and may warrant unnecessary scheduled maintenances.
determining transportation matching features from monitoring a plurality of provider computing devices, via a transportation matching application, ….
Hinduja [p. 5 lines 6-10] disclose FIG. 1A is a block diagram that illustrates a system environment 100A for dynamic maintenance scheduling for vehicles. The system environment 100 A includes a plurality of vehicles 102a-102d, an application server 104, a database server 106, a maintenance center 108 having a maintenance system 110, and a communication network 112., Hinduja [Figure 1A], [Figure 2A], [p. 5 lines 6-10].
Hinduja [p.8 lines 20-23] teaches driver device may include a mobile phone, a smartphone, a laptop, a tablet, a phablet, or the like. The database server 106 may receive the first booking data from the transportation service provider associated with the plurality of vehicles 102a-102d. Hinduja [p.8 lines 20-23], and thus, Hinduja teaches transportation matching application.
Hinduja [p.8 lines 9-20] teaches booking one or more passenger for rides. Database server 106 may receive real-time booking data of the plurality of vehicles 102a-102d., Hinduja [Figure 1A]. Hinduja teaches database server 106, and thus, Hinduja teaches transportation matching.
generating, utilizing a notification model to analyze the vehicle service features and the transportation matching features for the plurality of provider computing devices comprising the number of provider computing devices within the geographic region, a notification for a transportation application of a client device;
Hindjua teaches transportation matching. See above.
Hinduja [abstract] teaches the method includes training a prediction model based on the plurality of features and the corresponding feature values.
Hinduja [p.3 lines 19-24] teaches a prediction model based on the plurality of features and the corresponding plurality of feature values. The server is further configured to determine a maintenance criterion for a target vehicle based on the trained prediction model and a target dataset associated with the target vehicle. Hinduja teaches a prediction model, and thus, Hinduja teaches a notification model.
the notification for display via a graphical user interface of the transportation application on the client device, wherein the notification comprises at least one of: a vehicle management notification, a transportation recommendation, or a transportation match notification indicating a transportation match with a provider computing device.
Hinduja [p. 33 lines 22-26] teaches the processing circuitry 206 may be further configured to communicate the scheduled maintenance ticket to the driver device 218 of the target vehicle 216. Hinduja [Figure 2B item 218], Hinduja [p. 33 lines 22-26].
Although highly suggested by Hinduja, Examiner relies on Rong to teach:
…
wherein the transportation matching features comprises a number of provider computing devices within a geographic region based on GPS location data of the number of provider computing devices;
generating, utilizing a prediction model, an interaction probability based on the vehicle service features, the transportation matching features, and the notification generated by the notification model analyzing the vehicle service features and the transportation matching features; and providing, based on the interaction probability,
Rong teaches Markov Decision Process and rewards. The MDP is a model for solving the optimal solution, it will recommend a total reward value of the largest action sequence to the mobile, it is using the value function to obtain the action sequence, the value function will obtain the total return value of a certain action sequence. Rong [abstract], [p.4]
Hinduja teaches a prediction model that may learn occurring scheduled and non-scheduled maintained. Rong relates to passenger and other taxi optimization. It would have been obvious to combine before the effective filing date, a count of times the vehicle undergoes scheduled maintenance in a fixed time-period, as taught by Hinduja, with using Markov decision models, as taught by Rong, to optimize taxi services., Rong [p.1].
Within claim 1, Hinduja discloses booking and a vehicle communication with a transportation database server, and thus, vehicle management notification, a transportation recommendation, or a transportation match notification indicating a transportation match with a provider computing device. Claim 1 a "Markush" claim recites a list of alternatively useable members. In re Harnisch, 631 F.2d 716, 719-20, 206 USPQ 300, 303 (CCPA 1980); Ex parte Markush, 1925 Dec. Comm'r Pat. 126, 127 (1924). The listing of specified alternatives within a Markush claim is referred to as a Markush group or a Markush grouping. Abbott Labs v. Baxter Pharmaceutical Products, Inc., 334 F.3d 1274, 1280-81, 67 USPQ2d 1191, 1196 (Fed. Cir. 2003) (citing to several sources that describe Markush groups)- See MPEP 706.03.
Regarding Claim 2, (Currently Amended)
The computer-implemented method of claim 1, wherein generating, utilizing the notification model, the notification further comprises: generating, utilizing a machine learning model, vehicle service feature vector mappings from the vehicle service features determined from monitoring the data packets of the plurality of service management computing devices; generating, utilizing the machine learning model, transportation matching feature vector mappings from the transportation matching features; and generating, utilizing the machine learning model, to generate the notification based on the vehicle service feature vector mappings and the transportation matching feature vector mappings vehicle service features and the transportation matching features.
Similar to claim 1. Hinduja [p.3 lines 19-24] teaches a prediction model based on the plurality of features and the corresponding plurality of feature values. The server is further configured to determine a maintenance criterion for a target vehicle based on the trained prediction model and a target dataset associated with the target vehicle. Hinduja teaches a prediction model, and thus, Hinduja teaches a notification model. Hinduja [p.3 lines 19-24], [abstract].
Rong teaches Markov Decision Process and rewards. The MDP is a model for solving the optimal solution, it will recommend a total reward value of the largest action sequence to the mobile, it is using the value function to obtain the action sequence, the value function will obtain the total return value of a certain action sequence. Rong [abstract], [p.4]
Hinduja teaches a prediction model that may learn occurring scheduled and non-scheduled maintained. Rong relates to passenger and other taxi optimization. It would have been obvious to combine before the effective filing date, a count of times the vehicle undergoes scheduled maintenance in a fixed time-period, as taught by Hinduja, with using Markov decision models, as taught by Rong, to optimize taxi servces. Rong [p.1].
Regarding Claim 4, (Original)
The computer-implemented method of claim 1, further comprising: determining, the vehicle service features by determining at least one of vehicle maintenance patterns, vehicle maintenance costs, vehicle repair down-times, service vehicle types, vehicle accident information, or vehicle service station availability.
Hinduja [abstract] teaches a method for dynamic maintenance scheduling includes receiving, by a server, first maintenance data, first vehicle data, first booking data, and a plurality of maintenance plans associated with a plurality of vehicles., Hinduja [abstract],
Hinduja [p.3 lines 16-19] discloses the server is further configured to determine a plurality of features and a corresponding plurality of feature values for each of the plurality of vehicles based on the first maintenance data, the first vehicle data, the first booking data, and the plurality of maintenance plans. The server is further configured to train a prediction model based on the plurality of features and the corresponding plurality of feature values.
(Hinduja teaches first maintenance data, the first vehicle data, the first booking data, and the plurality of maintenance plans.); (The labels maintenance patterns, vehicle maintenance costs, vehicle repair down-times, service vehicle types, vehicle accident information, or vehicle service station availability are merely names and labels indicating a particular function and do not alter the structure or function of the claimed invention, accordingly these limitations (names and labels) do not patentability distinguish the claims from the cited prior art.)
Within claim 4, Hinduja discloses first maintenance data, the first vehicle data, the first booking data, and the plurality of maintenance plans, and thus, disclose at least one of vehicle maintenance patterns, vehicle maintenance costs, vehicle repair down-times, service vehicle types, vehicle accident information, or vehicle service station availability. Claim 4 a "Markush" claim recites a list of alternatively useable members. In re Harnisch, 631 F.2d 716, 719-20, 206 USPQ 300, 303 (CCPA 1980); Ex parte Markush, 1925 Dec. Comm'r Pat. 126, 127 (1924). The listing of specified alternatives within a Markush claim is referred to as a Markush group or a Markush grouping. Abbott Labs v. Baxter Pharmaceutical Products, Inc., 334 F.3d 1274, 1280-81, 67 USPQ2d 1191, 1196 (Fed. Cir. 2003) (citing to several sources that describe Markush groups)- See MPEP 706.03.
Regarding Claim 5, (Original)
The computer-implemented method of claim 1, wherein monitoring a plurality of provider computing devices to determine transportation matching features further comprises monitoring at least one of transportation matching vehicle telematics data, transportation matching driver ratings, transportation matching vehicle types transportation matching driving route patterns, number of transportation matching provider devices for a geographic region, number of transportation matching requester devices for a geographic region, or provider transportation matching schedules.
Hinduja [p. 9 line 15-16] discloses the vehicle data of the plurality of vehicles 102a-102d may be indicative of information pertaining a region of operation of each vehicle 102a-102 and [p.10 lines 23-26] the database server 106 may receive the vehicle data from a corresponding driver device, the telematics device., Hinduja [p. 9 line 15-16], [p.10 lines 23-26].
Hinduja [p. 17 line 5-24] teaches the count of non-scheduled maintenance sessions of the vehicle may be further indicative of an additional cost that is being borne by the transportation service provider due to poor health and additional downtime of the vehicle. In one example, the vehicle 102a may be two years old and may have undergone 6 scheduled maintenance sessions in the two years of use. However as per the maintenance data or records of the vehicle 102a, the vehicle 102a has undergone 10 maintenance sessions., Hinduja [p. 17 lines 5-24], [p.20 lines 12-15].
Within claim 5, Hinduja discloses a region of operation and receive the vehicle data from a corresponding driver device, the telematics device, count of repairs, and thus, discloses geographic region of operation and matching vehicle telematics data, and provider transportation matching schedules. Claim 5 a "Markush" claim recites a list of alternatively useable members. In re Harnisch, 631 F.2d 716, 719-20, 206 USPQ 300, 303 (CCPA 1980); Ex parte Markush, 1925 Dec. Comm'r Pat. 126, 127 (1924). The listing of specified alternatives within a Markush claim is referred to as a Markush group or a Markush grouping. Abbott Labs v. Baxter Pharmaceutical Products, Inc., 334 F.3d 1274, 1280-81, 67 USPQ2d 1191, 1196 (Fed. Cir. 2003) (citing to several sources that describe Markush groups)- See MPEP 706.03
Regarding Claim 7, (Original)
The computer-implemented method of claim 1, wherein generating the notification comprises generating the transportation recommendation by selecting between a personal vehicle corresponding to the client device or a set of transportation matching vehicles based on the vehicle service features from the plurality of service management computing devices and the transportation matching features for the plurality of provider computing devices.
Similar to claim 1. Hinduja [p. 17 line 5-24], [p.8 lines 10-23], [Figure 1A ], [Figure 2A] teaches booking transportation service.
Within claim 7, Hinduja discloses booking and a vehicle communication with a transportation database server, and thus, discloses a set of transportation matching vehicles based on the vehicle service features from the plurality of service management computing devices and the transportation matching features for the plurality of provider computing devices. Claim 7 a "Markush" claim recites a list of alternatively useable members. In re Harnisch, 631 F.2d 716, 719-20, 206 USPQ 300, 303 (CCPA 1980); Ex parte Markush, 1925 Dec. Comm'r Pat. 126, 127 (1924). The listing of specified alternatives within a Markush claim is referred to as a Markush group or a Markush grouping. Abbott Labs v. Baxter Pharmaceutical Products, Inc., 334 F.3d 1274, 1280-81, 67 USPQ2d 1191, 1196 (Fed. Cir. 2003) (citing to several sources that describe Markush groups)- See MPEP 706.03.
Regarding Claim 9, (Currently Amended)
A system comprising: at least one processor; and a non-transitory computer readable storage medium comprising instructions that, when executed by the at least one processor, cause the system to: determine, vehicle service features from monitoring data packets of a plurality of service management computing devices, wherein the vehicle service features are based on vehicle data captured by the plurality of service management computing devices; determine transportation matching features from monitoring a plurality of provider computing devices, via a transportation matching application, wherein the transportation matching features comprises a number of provider computing devices within a geographic region based on GPS location data of the number of provider computing devices; generate, utilizing a notification model to analyze the vehicle service features and the transportation matching features for the plurality of provider computing devices comprising the number of provider computing devices within the geographic region, a notification for a transportation application of a client device; generate, utilizing a prediction model, an interaction probability based on the vehicle service features, the transportation matching features, and the notification generated by the notification model analyzing the vehicle service features and the transportation matching features; select the notification from a plurality of candidate notifications based on the interaction probability; and provide the notification for display via a graphical user interface of the transportation application on the client device, wherein the notification comprises at least one of: a vehicle management notification, a transportation recommendation, or a transportation match notification indicating a transportation match with a provider computing device.
Similar to Claim 1.
Hinduja [abstract] , [p.3 lines 16-24] , [p.4 lines 9-20] , [p.8 lines 8-30], [p. 5 lines 6-10], [Figure 1A], [Figure 2A]., Hinduja [p. 33 lines 22-26], [Figure 2B item 218].
Rong teaches Markov Decision Process and rewards. The MDP is a model for solving the optimal solution, it will recommend a total reward value of the largest action sequence to the mobile, it is using the value function to obtain the action sequence, the value function will obtain the total return value of a certain action sequence. Rong [abstract], [p.4]
Hinduja teaches a prediction model that may learn occurring scheduled and non-scheduled maintained. Rong relates to passenger and other taxi optimization. It would have been obvious to combine before the effective filing date, a count of times the vehicle undergoes scheduled maintenance in a fixed time-period, as taught by Hinduja, with using Markov decision models, as taught by Rong, to optimize taxi services. Rong [p.1].
Within claim 9, Hinduja discloses booking and a vehicle communication with a transportation database server, and thus, vehicle management notification, a transportation recommendation, or a transportation match notification indicating a transportation match with a provider computing device. Claim 9 a "Markush" claim recites a list of alternatively useable members. In re Harnisch, 631 F.2d 716, 719-20, 206 USPQ 300, 303 (CCPA 1980); Ex parte Markush, 1925 Dec. Comm'r Pat. 126, 127 (1924). The listing of specified alternatives within a Markush claim is referred to as a Markush group or a Markush grouping. Abbott Labs v. Baxter Pharmaceutical Products, Inc., 334 F.3d 1274, 1280-81, 67 USPQ2d 1191, 1196 (Fed. Cir. 2003) (citing to several sources that describe Markush groups)- See MPEP 706.03.
Regarding Claim 10, (Currently Amended)
The system of claim 9, further comprises instructions that, when executed by the at least one processor, cause the system to: utilize Markov Decision Process to generate the notification generating a reward corresponding to the notification based on the vehicle service features and the transportation matching features; generating an additional reward corresponding to an additional notification of the plurality of candidate notifications based on the vehicle service features and the transportation matching features; and providing the notification for display via the graphical user interface of the transportation application on the client device based on the reward corresponding to the notification being greater than the reward corresponding to the additional notification.
Similar to claim 10. Hinduja [p.3 lines 19-24], [abstract].
Rong teaches Markov Decision Process and rewards. The MDP is a model for solving the optimal solution, it will recommend a total reward value of the largest action sequence to the mobile, it is using the value function to obtain the action sequence, the value function will obtain the total return value of a certain action sequence.
Hinduja teaches a prediction model that may learn occurring scheduled and non-scheduled maintained. Rong relates to passenger and other taxi optimization. It would have been obvious to combine before the effective filing date, a count of times the vehicle undergoes scheduled maintenance in a fixed time-period, as taught by Hinduja, with using Markov decision models, as taught by Rong, to optimize taxi services. Rong [p,1].
Regarding Claim 12, (Original)
The system of claim 9, further comprising instructions that, when executed by the at least one processor, cause the system to determine, the vehicle service features by determining at least one of vehicle maintenance patterns, vehicle maintenance costs, vehicle repair down-times, determining, vehicle service features further comprises determining at least one of service vehicle types, vehicle accident information, or vehicle service station availability.
Hinduja [abstract], [p.3 lines 16-19].
(Hinduja teaches first maintenance data, the first vehicle data, the first booking data, and the plurality of maintenance plans.); (The labels maintenance patterns, vehicle maintenance costs, vehicle repair down-times, service vehicle types, vehicle accident information, or vehicle service station availability are merely names and labels indicating a particular function and do not alter the structure or function of the claimed invention, accordingly these limitations (names and labels) do not patentability distinguish the claims from the cited prior art.)
Within claim 4, Hinduja discloses first maintenance data, the first vehicle data, the first booking data, and the plurality of maintenance plans, and thus, disclose at least one of vehicle maintenance patterns, vehicle maintenance costs, vehicle repair down-times, service vehicle types, vehicle accident information, or vehicle service station availability. Claim 4 a "Markush" claim recites a list of alternatively useable members. In re Harnisch, 631 F.2d 716, 719-20, 206 USPQ 300, 303 (CCPA 1980); Ex parte Markush, 1925 Dec. Comm'r Pat. 126, 127 (1924). The listing of specified alternatives within a Markush claim is referred to as a Markush group or a Markush grouping. Abbott Labs v. Baxter Pharmaceutical Products, Inc., 334 F.3d 1274, 1280-81, 67 USPQ2d 1191, 1196 (Fed. Cir. 2003) (citing to several sources that describe Markush groups)- See MPEP 706.03.
Regarding Claim 13, (Original)
The system of claim 9, further comprising instructions that, when executed by the at least one processor, cause the system to monitor a plurality of provider computing devices to determine transportation matching features further comprises monitoring at least one of transportation matching vehicle telematics data, transportation matching driver ratings, transportation matching vehicle types transportation matching driving route patterns, number of transportation matching provider devices for a geographic region, number of transportation matching requester devices for a geographic region, or provider transportation matching schedules.
Hinduja [p. 9 line 15-16], [p.10 lines 23-26], [p. 17 lines 5-24], [p.20 lines 12-15].
Within claim 13, Hinduja discloses a region of operation and receive the vehicle data from a corresponding driver device, the telematics device, count of repairs, and thus, discloses geographic region of operation and matching vehicle telematics data, and provider transportation matching schedules. Claim 13, a "Markush" claim recites a list of alternatively useable members. In re Harnisch, 631 F.2d 716, 719-20, 206 USPQ 300, 303 (CCPA 1980); Ex parte Markush, 1925 Dec. Comm'r Pat. 126, 127 (1924). The listing of specified alternatives within a Markush claim is referred to as a Markush group or a Markush grouping. Abbott Labs v. Baxter Pharmaceutical Products, Inc., 334 F.3d 1274, 1280-81, 67 USPQ2d 1191, 1196 (Fed. Cir. 2003) (citing to several sources that describe Markush groups)- See MPEP 706.03
Regarding Claim 16, (Currently Amended)
A non-transitory computer readable storage medium comprising instructions that, when executed by at least one processor, cause the at least one processor to: determine, vehicle service features from monitoring data packets of a plurality of service management computing devices, wherein the vehicle service features are based on vehicle data captured by the plurality of service management computing devices; determine transportation matching features from monitoring a plurality of provider computing devices, via a transportation matching application, where the transportation matching features comprises a number of provider computing devices within a geographic region based on GPS location data of the number of provider computing devices; generate, utilizing a notification model to analyze the vehicle service features and the transportation matching features for the plurality of provider computing devices comprising the number of provider computing devices within the geographic region, a notification for a transportation application of a client device generate, utilizing a prediction model, an interaction probability based on the vehicle service features, the transportation matching features, and the notification generated by the notification model analyzing the vehicle service features and the transportation matching features; and provide, based on the interaction probability, the notification for display via a graphical user interface of the transportation application on the client device, wherein the notification comprises at least one of: a vehicle management notification, a transportation recommendation, or a transportation match notification indicating a transportation match with a provider computing device.
Similar to Claim 1. Hinduja [abstract] , [p.3 lines 16-24] , [p.4 lines 9-20] , [p.8 lines 8-30], [p. 5 lines 6-10], [Figure 1A], [Figure 2A]., Hinduja [p. 33 lines 22-26], [Figure 2B item 218], Rong [see above.]
Within claim 16, Hinduja discloses booking and a vehicle communication with a transportation database server, and thus, vehicle management notification, a transportation recommendation, or a transportation match notification indicating a transportation match with a provider computing device. Claim 16, a "Markush" claim recites a list of alternatively useable members. In re Harnisch, 631 F.2d 716, 719-20, 206 USPQ 300, 303 (CCPA 1980); Ex parte Markush, 1925 Dec. Comm'r Pat. 126, 127 (1924). The listing of specified alternatives within a Markush claim is referred to as a Markush group or a Markush grouping. Abbott Labs v. Baxter Pharmaceutical Products, Inc., 334 F.3d 1274, 1280-81, 67 USPQ2d 1191, 1196 (Fed. Cir. 2003) (citing to several sources that describe Markush groups)- See MPEP 706.03.
Regarding Claim 20, (Original)
The non-transitory computer readable storage medium of claim 16, further comprising instructions that, when executed by the at least one processor, cause the at least one processor to monitor at least one of transportation matching vehicle telematics data, transportation matching driver ratings, transportation matching vehicle types transportation matching driving route patterns, number of transportation matching provider devices for a geographic region, number of transportation matching requester devices for a geographic region, or provider transportation matching schedules.
Similar to claim 5. Hinduja [p. 9 line 15-16], [p.10 lines 23-26], [p. 17 lines 5-24], [p.20 lines 12-15].
Within claim 20, Hinduja discloses a region of operation and receive the vehicle data from a corresponding driver device, the telematics device, count of repairs, and thus, discloses geographic region of operation and matching vehicle telematics data, and provider transportation matching schedules. Claim 20, a "Markush" claim recites a list of alternatively useable members. In re Harnisch, 631 F.2d 716, 719-20, 206 USPQ 300, 303 (CCPA 1980); Ex parte Markush, 1925 Dec. Comm'r Pat. 126, 127 (1924). The listing of specified alternatives within a Markush claim is referred to as a Markush group or a Markush grouping. Abbott Labs v. Baxter Pharmaceutical Products, Inc., 334 F.3d 1274, 1280-81, 67 USPQ2d 1191, 1196 (Fed. Cir. 2003) (citing to several sources that describe Markush groups)- See MPEP 706.03
Claim(s) 3, 6, 8, 11, 14, 15, 18, and 19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Hinduja (WO 2022/0,911,120 A1) in view of Rong (CN 109670703 B) and in further of McClintic (US 2016/0,078,695 A1).
Regarding Claim 3, (Original)
The computer-implemented method of claim 1, further comprising: monitoring a plurality of requester computing devices to determine the transportation matching features by determining a number of requester computing devices at a particular time;
monitoring the vehicle service features by determining vehicle service station availability at the particular time;
and generating the notification by generating the vehicle management notification based on the number of requester computing devices and the vehicle service station availability at the particular time.
Hinduja [p.20 lines 23-28] disclose features 212 may further include a count of dormant days of a vehicle, a count of active days of a vehicle, and a deviation in a count of active days between consecutive scheduled maintenance sessions of a vehicle. In such an embodiment, the plurality of feature values 214 may include the count of dormant days of each vehicle 102a and 102b, the count of active days of each vehicle 102a and 102b, the deviation in the count of active days between consecutive scheduled maintenance sessions of each vehicle 102a and 102b.
Although Hinduja matches vehicle for bookings and counts downtown of vehicles, Hinjuda does not explicitly teach:
determining vehicle service station availability at the particular time … the vehicle service station availability….
McClintic teaches:
determining vehicle service station availability at the particular time … the vehicle service station availability….
McClintic [009] planning of maintenance activities may include the selection of an optimal time and/or location for performing the work, with consideration given to trends in the operating data, the availability of necessary repair resources., McClintic [009], [045], [096].
McClintic [093] discloses the data center or service personnel may evaluate the most logical repair location in terms of various criteria, such as train proximity, parts, repair equipment availability, manpower availability, etc. The service recommendation automatically triggers the creation of an electronic work order.
Hinduja teaches a prediction model that may learn occurring scheduled and non-scheduled maintained. McClintic relate to indicating a repair to perform on an asset based on historic data related to a repair on the asset and/or sensor data associated with the asset. It would have been obvious to combine before the effective filing date, a count of times the vehicle undergoes scheduled maintenance in a fixed time-period, as taught by Hinduja, with service recommendations, and availability of shops, as taught by McClintic, to higher utilization levels in a given asset., Hinduja [034].
Regarding Claim 6, (Original)
The computer-implemented method of claim 1, wherein: determining the transportation matching features comprises determining a provider transportation matching schedule corresponding with a provider computing device; determining vehicle service features comprises …; and generating the notification comprises generating the vehicle management notification based on the provider transportation ….
Hinduja [p.20 lines 3-10] discloses learning repair downtime of a vehicle refers to a time-interval for which the vehicle has been out of service due to repair and maintenance actions. The repair downtime may be indicative of one of occurrence of one or more major or minor performance issues associated with the vehicle and a time spent on repair and maintenance of the vehicle for correcting those performance issues. For example, the vehicle 102a may have been put to use on March 30, 2012. Further, on March 30, 2013, the vehicle 102a is brought to the maintenance center 108 for maintenance and repair. The vehicle 102a is again put to use on April 30, 2013. Thus, the repair downtime of the vehicle 102a is one month.
Although Hinduja matches vehicle for bookings and counts downtown of vehicles, Hinjuda does not explicitly teach:
determining vehicle service station availability at the particular time … the vehicle service station availability….
McClintic teaches:
determining vehicle service station availability at the particular time … the vehicle service station availability….
McClintic [009] planning of maintenance activities and the availability of necessary repair resources., McClintic [009], [045], [096], [093].
Hinduja teaches a prediction model that may learn occurring scheduled and non-scheduled maintained. McClintic relate to indicating a repair to perform on an asset based on historic data related to a repair on the asset and/or sensor data associated with the asset. It would have been obvious to combine before the effective filing date, a count of times the vehicle undergoes scheduled maintenance in a fixed time-period, as taught by Hinduja, with service recommendations, and availability of shops, as taught by McClintic, to higher utilization levels in a given asset., Hinduja [034].
Regarding Claim 8, (Original)
The computer-implemented method of claim 1, wherein generating the notification comprises generating the transportation match notification by selecting a provider computing device from a pool of provider computing devices based on the vehicle service features from the plurality of service management computing devices and the transportation matching features for the plurality of provider computing devices.
Hinduja [Figure 4 and the associated text] disclose FIG. 4 is a flowchart 400 that illustrates a method for dynamic maintenance scheduling of a vehicle, in accordance with an exemplary embodiment of the disclosure.
McClintic further teaches:
selecting a provider computing device from a pool of provider ….
McClintic [008] discloses systems and methods are described herein for effectively integrating the diverse elements involved in the management of remote assets, e.g., a fleet of mobile assets.
Hinduja teaches a prediction model that may learn occurring scheduled and non-scheduled maintained. McClintic relate to indicating a repair to perform on an asset based on historic data related to a repair on the asset and/or sensor data associated with the asset. It would have been obvious to combine before the effective filing date, a count of times the vehicle undergoes scheduled maintenance in a fixed time-period, as taught by Hinduja, with service recommendations, and availability of shops, as taught by McClintic, to higher utilization levels in a given asset., Hinduja [034].
Regarding, Claim 11, (Original)
The system of claim 9, further comprising instructions that, when executed by the at least one processor, cause the system to: monitor a plurality of requester computing devices to determine the transportation matching features by determining a number of requester computing devices at a particular time; monitor the vehicle service features by determining vehicle service station availability at the particular time; and generate the notification by generating the vehicle management notification based on the number of requester computing devices and the vehicle service station availability at the particular time.
Hinduja [p.20 lines 23-28], McClintic [009], [045], [093], [096].
Hinduja teaches a prediction model that may learn occurring scheduled and non-scheduled maintained. McClintic relate to indicating a repair to perform on an asset based on historic data related to a repair on the asset and/or sensor data associated with the asset. It would have been obvious to combine before the effective filing date, a count of times the vehicle undergoes scheduled maintenance in a fixed time-period, as taught by Hinduja, with service recommendations, and availability of shops, as taught by McClintic, to higher utilization levels in a given asset., Hinduja [034].
Regarding Claim 14, (Original)
The system of claim 11, further comprising instructions that, when executed by the at least one processor, cause the system to: determine a provider transportation matching schedule corresponding with a provider computing device; determine vehicle station availability; and generate the vehicle management notification based on the provider transportation matching schedule and the vehicle service station availability.
Similar to claim 6. Hinduja [p.20 lines 3-10], McClintic [009], [045], [096], [093].
Hinduja teaches a prediction model that may learn occurring scheduled and non-scheduled maintained. McClintic relate to indicating a repair to perform on an asset based on historic data related to a repair on the asset and/or sensor data associated with the asset. It would have been obvious to combine before the effective filing date, a count of times the vehicle undergoes scheduled maintenance in a fixed time-period, as taught by Hinduja, with service recommendations, and availability of shops, as taught by McClintic, to higher utilization levels in a given asset., Hinduja [034].
Regarding Claim 15, (Original)
The system of claim 11, further comprising instructions that, when executed by the at least one processor, cause the system to generate the transportation recommendation by selecting between a personal vehicle corresponding to the client device or a set of transportation matching vehicles based on the vehicle service features from the plurality of service management computing devices and the transportation matching features for the plurality of provider computing devices.
Similar to claim 1 and claim 7. Hinduja [p. 17 line 5-24], [p.8 lines 10-23], [Figure 1A ], [Figure 2A].
Within claim 7, Hinduja discloses booking and a vehicle communication with a transportation database server, and thus, discloses a set of transportation matching vehicles based on the vehicle service features from the plurality of service management computing devices and the transportation matching features for the plurality of provider computing devices. Claim 7 a "Markush" claim recites a list of alternatively useable members. In re Harnisch, 631 F.2d 716, 719-20, 206 USPQ 300, 303 (CCPA 1980); Ex parte Markush, 1925 Dec. Comm'r Pat. 126, 127 (1924). The listing of specified alternatives within a Markush claim is referred to as a Markush group or a Markush grouping. Abbott Labs v. Baxter Pharmaceutical Products, Inc., 334 F.3d 1274, 1280-81, 67 USPQ2d 1191, 1196 (Fed. Cir. 2003) (citing to several sources that describe Markush groups)- See MPEP 706.03.
Regarding Claim 18, (Original)
The non-transitory computer readable storage medium of claim 16, further comprising instructions that, when executed by the at least one processor, cause the at least one processor to: monitor a plurality of requester computing devices to determine the transportation matching features by determining a number of requester computing devices at a particular time; monitor the vehicle service features by determining vehicle service station availability at the particular time; and generate the notification by generating the vehicle management notification based on the number of requester computing devices and the vehicle service station availability at the particular time.
Hinduja [p.20 lines 23-28]. McClintic [009], [045], [093], [096].
Hinduja teaches a prediction model that may learn occurring scheduled and non-scheduled maintained. McClintic relate to indicating a repair to perform on an asset based on historic data related to a repair on the asset and/or sensor data associated with the asset. It would have been obvious to combine before the effective filing date, a count of times the vehicle undergoes scheduled maintenance in a fixed time-period, as taught by Hinduja, with service recommendations, and availability of shops, as taught by McClintic, to higher utilization levels in a given asset., Hinduja [034].
Regarding Claim 19, (Original)
The non-transitory computer readable storage medium of claim 16, further comprising instructions that, when executed by the at least one processor, cause the at least one processor to determine, the vehicle service features by determining at least one of vehicle maintenance patterns, vehicle maintenance costs, vehicle repair down-times, determining, vehicle service features further comprises determining at least one of service vehicle types, vehicle accident information, or vehicle service station availability.
Similar to claim 4. Hinduja [abstract], [p.3 lines 16-19]. McClintic [009], [045], [093], [096].
Hinduja teaches a prediction model that may learn occurring scheduled and non-scheduled maintained. McClintic relate to indicating a repair to perform on an asset based on historic data related to a repair on the asset and/or sensor data associated with the asset. It would have been obvious to combine before the effective filing date, a count of times the vehicle undergoes scheduled maintenance in a fixed time-period, as taught by Hinduja, with service recommendations, and availability of shops, as taught by McClintic, to higher utilization levels in a given asset., Hinduja [034].
(Hinduja teaches first maintenance data, the first vehicle data, the first booking data, and the plurality of maintenance plans.); (The labels maintenance patterns, vehicle maintenance costs, vehicle repair down-times, service vehicle types, vehicle accident information, or vehicle service station availability are merely names and labels indicating a particular function and do not alter the structure or function of the claimed invention, accordingly these limitations (names and labels) do not patentability distinguish the claims from the cited prior art.)
Within claim 19, Hinduja discloses first maintenance data, the first vehicle data, the first booking data, and the plurality of maintenance plans, and thus, disclose at least one of vehicle maintenance patterns, vehicle maintenance costs, vehicle repair down-times, service vehicle types, vehicle accident information, or vehicle service station availability. Claim 4 a "Markush" claim recites a list of alternatively useable members. In re Harnisch, 631 F.2d 716, 719-20, 206 USPQ 300, 303 (CCPA 1980); Ex parte Markush, 1925 Dec. Comm'r Pat. 126, 127 (1924). The listing of specified alternatives within a Markush claim is referred to as a Markush group or a Markush grouping. Abbott Labs v. Baxter Pharmaceutical Products, Inc., 334 F.3d 1274, 1280-81, 67 USPQ2d 1191, 1196 (Fed. Cir. 2003) (citing to several sources that describe Markush groups)- See MPEP 706.03.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Wang (2019, Vehicle Fleet Maintenance Scheduling Optimization by Multi-objective Evolutionary Algorithms).
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). 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 THEA LABOGIN whose telephone number is (571)272-9149. The examiner can normally be reached Monday -Friday, 8am-5pm.
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, Patricia Munson can be reached at 571-270- 5396. 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.
/THEA LABOGIN/Examiner, Art Unit 3624
Prosecution Insights