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 .
DETAILED ACTION
1. This Final Office action is in reply to the Applicant amendment filed on 27 October 2025.
2. Claims 1, 7, 10, 11, 18, 19 have been amended.
3. Claims 1-20 are currently pending and have been examined.
Response to Amendment
It appears the proposed inventor filed the current application “pro se” (i.e., without the benefit of representation by a registered patent practitioner). While inventors named as applicants in a patent application may prosecute the application pro se, lack of familiarity with patent examination practice and procedure may result in missed opportunities in obtaining optimal protection for the invention disclosed. The inventor(s) may wish to secure the services of a registered patent practitioner to prosecute the application, because the value of a patent is largely dependent upon skilled preparation and prosecution. The Office cannot aid in selecting a patent practitioner.
A listing of registered patent practitioners is available at https://oedci.uspto.gov/OEDCI/. Applicants may also obtain a list of registered patent practitioners located in their area by writing to Mail Stop OED, Director of the U.S. Patent and Trademark Office, P.O. Box 1450, Alexandria, VA 22313-1450.
In the previous office action, Claims 1-20 were rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter (abstract idea). Applicant has not amended Claims 1-20 to provide statutory support and the rejection is maintained.
Applicant’s amendments necessitated the new grounds of rejection.
Response to Arguments
Applicant’s arguments filed 27 October 2025 have been fully considered but they are not persuasive. In the remarks regarding the 35 USC § 101 rejection for Claims 1-20, Applicant argues that: (1) the claims are not directed to an abstract idea, and even if they were, they would amount to significantly more than the abstract idea. Examiner respectfully disagrees. Still commensurate to the two-part subject matter eligibility framework decision in the Federal court decision in Alice Corp. Pty. Ltd. V. CLS Bank International et al., (Alice), 2019 revised patent subject matter eligibility guidance (2019 PEG) and the October 2019 Update: Subject Matter Eligibility (“October 2019 Update), and the new “July 2024 Guidance Update on Patent Subject Matter Eligibility Examples, including on Artificial Intelligence”, and the Examiner details the maintained rejection under 35 U.S.C. 101 in the below rejection with further explanation. Applicant argues that as amended, Applicant states: “that the claims do not comprise a judicial exception, an abstract idea concept as alleged by the Examiner. The claims are instead a practical and hardware-intensive and detailed solution to a complicated real-world problem, a solution enabled by a specific technical structure to a problem that has existed since the advent of commerce” (see Remarks/Arguments pages 8-12). However the Examiner respectfully disagrees. For brief clarification in response to this argument and detailed below in bolded in the maintained rejection, the Examiner submits the claims still recite abstract idea limitations identified under their broadest reasonable interpretation of the claims as a whole, cover performance of their limitations as: The 2019 PEG explains that the abstract idea exception includes the following groupings of subject matter:
Mathematical concepts – [mathematical relationships, mathematical formulas or equations, mathematical calculations]. The algorithm for calculating and weighing factors (distance, queue size, certificate count, estimated time) represents a mathematical formula, calculation, or algorithm. The weighing of multiple, disparate data points (distance, time, queue size) to create a final ranking involves mathematical operations.
Certain methods of organizing human activity – [marketing or sales activities or behaviors; business relations; Commercial/Legal Interaction); managing personal behavior or relationships or interactions between people]. The steps described (receiving a service request, identifying technician locations, ranking technicians based on variables, and assigning a weight/score to generate a final ranking) represent a method of organizing human activity. The service scheduling, dispatching, and managing of personnel (technicians) based on qualification (certificates) and workload (queue size) represent Commercial/Legal Interaction.
Mental Process: The process of taking data (location, skill set) and performing a ranking could theoretically be performed in the human mind or with a pen and paper, despite the implementation of technician devices.
See MPEP § 2106.04(a) II C. Hence, the claims are ineligible under Step 2A Prong one. Furthermore, the dependent claims are merely directed to the particulars of the abstract idea and likewise do not add significantly more to the above-identified judicial exception. The limitations of the claims do not transform the abstract idea that they recite into patent-eligible subject matter because the claims simply instruct the practitioner to implement the abstract idea using generally-recited computer components.
Prong Two: Claims 1-20: With regard to this step of the analysis (as explained in MPEP § 2106.04(d)), the judicial exception is not integrated into a practical application. The claims are "directed to" these abstract ideas because the core invention is the method of selecting a technician requesting onsite service via service providers is not a specific, non-conventional improvement to the functionality of the computer/server itself. Independent Claims 1, 10, 15 recite additional elements directed to “computer; device(s); application” (e.g., see Applicants’ published Specification ¶’s 69-89). Therefore, the claims contain computer components that are cited at a high level of generality and are merely invoked as a tool to perform the abstract idea. Simply implementing an abstract idea on a computer is not a practical application of the abstract idea. Furthermore, the dependent claims are merely directed to the particulars of the abstract idea and likewise do not add significantly more to the above-identified judicial exception. The limitations of the claims do not transform the abstract idea that they recite into patent-eligible subject matter because the claims simply instruct the practitioner to implement the abstract idea using generally-recited computer components, and furthermore do not amount to an improvement to a computer or any other technology, and thus are ineligible. See MPEP § 2106.05(f) (h).
Step 2B: As explained in MPEP § 2106.05, Claims 1-20 do not include additional elements that are sufficient to amount to significantly more than the judicial exception because the additional elements when considered both individually and as an ordered combination do not amount to significantly more than the abstract idea nor recites additional elements that integrate the judicial exception into a practical application. The additional elements of “computer; device(s); application” etc. are generically-recited computer-related elements that amount to a mere instruction to “apply it” (the abstract idea) on the computer-related elements (see MPEP § 2106.05 (f) – Mere Instructions to Apply an Exception). These additional elements in the claims are recited at a high level of generality and are merely limiting the field of use of the judicial exception (see MPEP §2106.05 (h) – Field of Use and Technological Environment). There is no indication that the combination of elements improves the function of a computer or improves any other technology. Furthermore, the dependent claims are merely directed to the particulars of the abstract idea and likewise do not add significantly more to the above-identified judicial exception. The limitations of the claims do not transform the abstract idea that they recite into patent-eligible subject matter because the claims simply instruct the practitioner to implement the abstract idea using generally-recited computer components, and furthermore do not amount to an improvement to a computer or any other technology, and thus are ineligible.
The Examiner interprets that the steps of the claimed invention both individually and as an ordered combination result in Mere Instructions to Apply a Judicial Exception (see MPEP §2106.05 (f)). These claims recite only the idea of a solution or outcome with no restriction on how the result is accomplished and no description of the mechanism used for accomplishing the result. Here, the claims utilize a computer or other machinery (e.g., see Applicants’ published Specification ¶’s 69-89) regarding using existing computer processors as well as program products comprising machine-readable media for carrying or having machine-executable instructions or data structures stored. “System 600” in its ordinary capacity for performing tasks (e.g., to receive, analyze, transmit and display data) and/or use computer components after the fact to an abstract idea (e.g., a fundamental economic practice and certain methods of organization human activities) and does not provide significantly more. See Affinity Labs v. DirecTV, 838 F.3d 1253, 1262, 120 USPQ2d 1201, 1207 (Fed. Cir. 2016)). Software implementations are accomplished with standard programming techniques with logic to perform connection steps, processing steps, comparison steps and decisions steps. These claims are directed to being a commonplace business method being applied on a general-purpose computer (see Alice Corp. Pty, Ltd. V. CLS Bank Int’l, 134 S. Ct. 2347, 1357, 110 USPQ2d 1976, 1983 (2014)); Versata Dev. Group, Inc., v. SAP Am., Inc., 793 D.3d 1306, 1334, 115 USPQ2d 1681, 1701 (Fed. Cir. 2015)) and require the use of software such as via a server to tailor information and provide it to the user on a generic computer. Based on all these, Examiner finds that when viewed either individually or in combination, these additional claim element(s) do not provide meaningful limitation(s) that raise to the high standards of eligibility to transform the abstract idea(s) into a patent eligible application of the abstract idea(s) such that the claim(s) amounts to significantly more than the abstract idea(s) itself. In summary as indicated below through Steps 1-2B, the recitation of a computer (one or more processors) to perform the claim limitations amount to no more that mere instruction to apply the exception using a generic computer component (x). Even when considered in combination, these additional elements represent mere instructions to implement an abstract idea or other exception on a computer and insignificant extra-solution activity, which do not provide an inventive concept. For at least these reasons, the rejection is maintained.
Applicant submits that: (2) Gara et al. (Gara) (US 2019/0392367 does not teach or suggest in amended Claim 1: basically the new amendments for Claims 1-20 [see Remarks pages 13-20]. With regard to argument (2), the Examiner respectfully disagrees. Applicant’s amendments have necessitated new grounds of rejection under 35 U.S.C. 112(b) for recited indefinite claim language and also as being unpatentable over Gara et al. (Gara) (US 2019/0392367 in view of Blomberg et al. (Blomberg) (US 2018/0114173) and the arguments for amended Claims 1-20 are moot. See below additional rejections for further clarification. It is noted that any citations to specific, pages, columns, paragraphs, lines, or figures in the prior art references and any interpretation of the reference should not be considered to be limiting in any way. A reference is relevant for all it contains and may be relied upon for all that it would have reasonably suggested to one having ordinary skill in the art. See MPEP 2123. The Examiner has a duty and responsibility to the public and to Applicant to interpret the claims as broadly as reasonably possible during prosecution. In re Prater, 415 F.2d 1 393, 1404-05, 162 USPQ 541, 550-51 (CCPA 1969).
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1-9 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. Independent Claim 1 recites the limitation "the OEM/model family or error code". There is insufficient antecedent basis for this limitation in the claim. For examination purposes, the Examiner will interpret these two different claim limitations as reciting "an OEM/model family or error code ". If broadly and reasonably interpreted as "an OEM/model family or error code ", the Examiner has no specific further definition of what specifically is “OEM/model family” separated by the indefinite phrase limitation of “or” and then what specifically is defined as “error code”. Thus making it difficult for the Examiner to distinguish between the two indefinite phrase limitations as to specifically what is being claimed within the relationship of the claim step limitations. The Examiner will interpret these indefinite phrase limitations as broadly and reasonably best interpreted towards the prior art. Clarification/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-20 are rejected under 35 U.S.C. §101 because the claimed invention is directed to a judicial exception (i.e., a law of nature, natural phenomenon, or an abstract idea) because the claimed invention is directed to a judicial exception (i.e., a law of nature, natural phenomenon, or an abstract idea) without significantly more. The claims as a whole recite certain grouping of an abstract idea and are analyzed in the following step process:
Step 1: Claims 1-20 are each focused to a statutory category of invention, namely “system; method” sets.
Step 2A: Prong One: Claims 1-20 recite limitations that set forth the abstract ideas, namely, the claims as a whole recite the claimed invention is directed to an abstract idea without significantly more. Example Claims 1, 15 encompass processing information by requesting onsite service via service providers by:
“receives a service request from a customer device, the request comprising at least a location of a service need, determines a service area associated with the location, identifies locations of technician devices associated with technicians presently located in the service area, the technicians identified as qualified to address the service need, ranks the technicians by parameters comprising:
a) distance of the technician devices to the location of the service need,
b) technician queue size by quantity of pending service calls,
c) status of technician comprising one of online and offline,
d) estimated time to reach the location of service need, and
e) number of certificates associated with each technician in the service area,
f) queue size as an integer count
g) certificate count for the OEM/model family or error code
assigns weights to each parameter for each technician, based at least on the assigned weights, generates a final ranking for the technicians, and
based at least on the ranking, dispatches a first technician to the location of service need,
wherein the application enables direct chatting by the customer device with the website administrators of a serve provider associated with the computer, application, and algorithm, and further enables direct interaction by the customer device with technician devices”
as noted in example Claim 1.
These abstract idea limitations identified above in bolded under their broadest reasonable interpretation of the claims as a whole, cover performance of their limitations as: The 2019 PEG explains that the abstract idea exception includes the following groupings of subject matter:
Mathematical concepts – [mathematical relationships, mathematical formulas or equations, mathematical calculations]. The algorithm for calculating and weighing factors (distance, queue size, certificate count, estimated time) represents a mathematical formula, calculation, or algorithm. The weighing of multiple, disparate data points (distance, time, queue size) to create a final ranking involves mathematical operations.
Certain methods of organizing human activity – [marketing or sales activities or behaviors; business relations; Commercial/Legal Interaction); managing personal behavior or relationships or interactions between people]. The steps described (receiving a service request, identifying technician locations, ranking technicians based on variables, and assigning a weight/score to generate a final ranking) represent a method of organizing human activity. The service scheduling, dispatching, and managing of personnel (technicians) based on qualification (certificates) and workload (queue size) represent Commercial/Legal Interaction.
Mental Process: The process of taking data (location, skill set) and performing a ranking could theoretically be performed in the human mind or with a pen and paper, despite the implementation of technician devices.
See MPEP § 2106.04(a) II C. Hence, the claims are ineligible under Step 2A Prong one. Furthermore, the dependent claims are merely directed to the particulars of the abstract idea and likewise do not add significantly more to the above-identified judicial exception. The limitations of the claims do not transform the abstract idea that they recite into patent-eligible subject matter because the claims simply instruct the practitioner to implement the abstract idea using generally-recited computer components.
Prong Two: Claims 1-20: With regard to this step of the analysis (as explained in MPEP § 2106.04(d)), the judicial exception is not integrated into a practical application. The claims are "directed to" these abstract ideas because the core invention is the method of selecting a technician requesting onsite service via service providers , is not a specific, non-conventional improvement to the functionality of the computer/server itself. Independent Claims 1, 10, 15 recite additional elements directed to “computer; device(s); application” (e.g., see Applicants’ published Specification ¶’s 69-89). Therefore, the claims contain computer components that are cited at a high level of generality and are merely invoked as a tool to perform the abstract idea. Simply implementing an abstract idea on a computer is not a practical application of the abstract idea. Furthermore, the dependent claims are merely directed to the particulars of the abstract idea and likewise do not add significantly more to the above-identified judicial exception. The limitations of the claims do not transform the abstract idea that they recite into patent-eligible subject matter because the claims simply instruct the practitioner to implement the abstract idea using generally-recited computer components, and furthermore do not amount to an improvement to a computer or any other technology, and thus are ineligible. See MPEP § 2106.05(f) (h).
Step 2B: As explained in MPEP § 2106.05, Claims 1-20 do not include additional elements that are sufficient to amount to significantly more than the judicial exception because the additional elements when considered both individually and as an ordered combination do not amount to significantly more than the abstract idea nor recites additional elements that integrate the judicial exception into a practical application. The additional elements of “computer; device(s); application” etc. are generically-recited computer-related elements that amount to a mere instruction to “apply it” (the abstract idea) on the computer-related elements (see MPEP § 2106.05 (f) – Mere Instructions to Apply an Exception). These additional elements in the claims are recited at a high level of generality and are merely limiting the field of use of the judicial exception (see MPEP §2106.05 (h) – Field of Use and Technological Environment). There is no indication that the combination of elements improves the function of a computer or improves any other technology. Furthermore, the dependent claims are merely directed to the particulars of the abstract idea and likewise do not add significantly more to the above-identified judicial exception. The limitations of the claims do not transform the abstract idea that they recite into patent-eligible subject matter because the claims simply instruct the practitioner to implement the abstract idea using generally-recited computer components, and furthermore do not amount to an improvement to a computer or any other technology, and thus are ineligible.
The Examiner interprets that the steps of the claimed invention both individually and as an ordered combination result in Mere Instructions to Apply a Judicial Exception (see MPEP §2106.05 (f)). These claims recite only the idea of a solution or outcome with no restriction on how the result is accomplished and no description of the mechanism used for accomplishing the result. Here, the claims utilize a computer or other machinery (e.g., see Applicants’ published Specification ¶’s 69-89) regarding using existing computer processors as well as program products comprising machine-readable media for carrying or having machine-executable instructions or data structures stored. “System 600” in its ordinary capacity for performing tasks (e.g., to receive, analyze, transmit and display data) and/or use computer components after the fact to an abstract idea (e.g., a fundamental economic practice and certain methods of organization human activities) and does not provide significantly more. See Affinity Labs v. DirecTV, 838 F.3d 1253, 1262, 120 USPQ2d 1201, 1207 (Fed. Cir. 2016)). Software implementations are accomplished with standard programming techniques with logic to perform connection steps, processing steps, comparison steps and decisions steps. These claims are directed to being a commonplace business method being applied on a general-purpose computer (see Alice Corp. Pty, Ltd. V. CLS Bank Int’l, 134 S. Ct. 2347, 1357, 110 USPQ2d 1976, 1983 (2014)); Versata Dev. Group, Inc., v. SAP Am., Inc., 793 D.3d 1306, 1334, 115 USPQ2d 1681, 1701 (Fed. Cir. 2015)) and require the use of software such as via a server to tailor information and provide it to the user on a generic computer. Based on all these, Examiner finds that when viewed either individually or in combination, these additional claim element(s) do not provide meaningful limitation(s) that raise to the high standards of eligibility to transform the abstract idea(s) into a patent eligible application of the abstract idea(s) such that the claim(s) amounts to significantly more than the abstract idea(s) itself. Accordingly, Claims 1-20 are rejected under 35 U.S.C. §101 because the claimed invention is directed to a judicial exception (i.e. abstract idea exception) without significantly more.
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 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.
Claims 1-20 are rejected under 35 U.S.C. 103 as being unpatentable over Gara et al. (Gara) (US 2019/0392367 in view of Blomberg et al. (Blomberg) (US 2018/0114173).
With regard to Claim 1, Gara teaches a system of a mobile (mobile device) service request application and algorithm (The roadside assistance service provider application upon execution of computer-executable instructions from the roadside assistance service provider server is configured to perform the following steps: receive, by the roadside assistance service provider server, a roadside assistance service request from a driver of the distressed vehicle) (see at least paragraphs 6-8, 90), comprising: a computer, and an application comprising an algorithm (telematics information; This information may then be analyzed using particular rules and formulas to determine the roadside assistance service providers) (see at least paragraphs 23-30, 91-94) that:
receives a service request from a customer device (receive, by the roadside assistance service provider server, a roadside assistance service request from a driver of the distressed vehicle), the request comprising at least a location of a service need (determine, by the roadside assistance service provider server, the selected service provider based on a proximity in location between the distressed vehicle and the selected service provider), determines a service area associated with the location (determine, by the roadside assistance service provider server, the selected service provider based on a set of factors that include: proximity in location between the distressed vehicle and the selected service provider), identifies locations of technician devices associated with technicians presently located in the service area, the technicians identified as qualified to address the service need (The roadside assistance service provider may be selected service provider from a crowdsourced group of individuals who are service providers, have registered with the roadside assistance system, and have been trained to provide roadside assistance services including the following services: jump start, flat tire change, fuel the distressed vehicle, tow the distressed vehicle, and unlock a locked-out vehicle), ranks the technicians by parameters comprising (receive telematics information, and analyze this information to provide a prioritized ranking of service providers to fulfill the service request) (see at least paragraphs 6-8, 26):
a) distance of the technician devices to the location of the service need (The telematics module 315 may further calculate and provide information regarding distance from nearest service provider to location of the service, time to travel (with or without traffic) from the service provider to location of the service, route information for selected service providers) (see at least paragraphs 46, 97),
b) technician queue size by quantity of pending service calls (The assignment module 615 may compare the existing workload, timelines, and distances for each of the various roadside assistance service providers and the requested service. The assignment module 615 may utilize many factors, such as considering the current queue and the amount of time to complete tasks in the queue. The assignment module 615 may also consider and factor the skill levels required to complete a given task, for example a skill level 1 may use a factor of 2 for time estimates) (see at least paragraphs 46, 97-99),
c) status of technician comprising one of online and offline (The mobile service provider system 100 may utilize various information to assist with matching the service providers and the user. The mobile service provider system 100 may search and identify any available professional service providers. The mobile service provider system 100 may search and identify any available service providers; The collection module 610 may also verify the roadside assistance service providers that are logged-in and available) (see at least paragraphs 55, 92),
d) estimated time to reach the location of service need (the assignment module 615 may facilitate and allow the user to view the service provider's specific information. The service provider's specific information may include contact details and estimated time of arrival) (see at least paragraph 100), and
e) number of certificates associated with each technician in the service area (The roadside assistance service provider may require validation and certification to become registered in the roadside assistance service provider system 900. In the assignment module 930, particular roadside assistance service providers may be assigned to particular distressed vehicles/drivers based on one or more characteristics, including characteristics/rules from the service provider module 920),
f) queue size as an integer count (The assignment module 615 may compare the existing workload, timelines, and distances for each of the various roadside assistance service providers and the requested service. The assignment module 615 may utilize many factors, such as considering the current queue and the amount of time to complete tasks in the queue. The assignment module 615 may also consider and factor the skill levels required to complete a given task, for example a skill level 1 may use a factor of 2 for time estimates. The assignment module 615 may also consider and factor the skill level and whether a driver or roadside assistance service provider is allowed and/or capable of working on a specific job or task, utilizing it as a qualifier) (see at least paragraphs 96-99, 128),
g) certificate count (The potential roadside assistance service provider may then be qualified, validated, or verified. This qualification, validation, and/or verification may provide a pre-screening tool for the users to ensure a quality and safe service provider. The potential roadside assistance service provider may be required to demonstrate technical and customer service skills in roadside assistance. The potential roadside assistance service provider may have an audition or certification to show that the service provider can engage in the required roadside assistance skills), assigns weights to each parameter for each technician (characteristics/criteria utilized by the assignment module 930 may include estimated time of arrival, proximity in location, prior user ratings, available equipment, skillset/expertise of the service provider, or price/cost of the service provider; characteristics/rules), based at least on the assigned weights, generates a final ranking for the technicians (The system may determine a prioritized ranking of service provider based on one or more of the following: the telematics information, insurance information, and the service request), and based at least on the ranking (prioritized ranking), dispatches a first technician to the location of service need (a dispatcher may assign and select a particular roadside assistance service providers to particular distressed vehicles/drivers based on one or more characteristics, including characteristics/rules) (see at least paragraphs 58, 77, 102, 138, 141-146);
wherein the application enables direct chatting by the customer device with the website administrators of a serve provider associated with the computer, application, and algorithm (rules and formulas), and further enables direct interaction by the customer device with technician devices (Input/Output (I/O) 109 may include a microphone, keypad, touch screen, and/or stylus through which a user of the mobile service provider server or roadside assistance service provider server 101 may provide input, and may also include one or more of a speaker for providing audio output and a video display device for providing textual, audiovisual and/or graphical output. Additionally, a hands-free or voice aspect may be utilized to provide input for the mobile service provider server or roadside assistance service provider server 101. Software may be stored within memory 115 and/or storage to provide instructions to processor 103 for enabling the mobile service provider server or roadside assistance service provider server 101 to perform various functions. For example, the memory 115 may store software used by the mobile service provider server or roadside assistance service provider server 101, such as an operating system 117, application programs 119, and an associated database 121. The processor 103 and its associated components may allow the mobile service provider server or roadside assistance service provider server 101 to run a series of computer-readable instructions to receive service requests from a user, receive telematics information, and analyze this information to provide a prioritized ranking of service providers to fulfill the service request. Additionally, the processor 103 and its associated components may allow the mobile service provider server or roadside assistance service provider server 101 to provide service provider information, and transmit a selected service provider to a user or service provider. Additionally, the processor 103 and its associated components may allow the mobile service provider server or roadside assistance service provider server 101 to run a series of computer-readable instructions to provide an electronic payment for the service provided, receive confirmation of the order, and provide rewards to the user. In addition, the processor 103 may receive insurance information in order to enhance and improve the service providing process. Further still, the processor 103 may derive insurance rating factors for insurance coverage and premiums based on the service provider, specific service request, and the frequency of the service requests) (see at least paragraphs 26, 38, 89, 91);
Gara does not specifically teach for an OEM/model family or error code. Blomberg teaches for an OEM/model family or error code (FIG. 3 is a flow diagram illustrating a method of learning a cognitive dependency model for cognitive dispatching in one embodiment of the present disclosure. The method shown in FIG. 3 may be performed during off-line learning. At 302, a list of service requests is obtained. A service request, for example, may be a request to perform a service in information technology (IT) systems, for example, solving a computer error or problem occurring in a computer system) in analogous art of service requests assigned to service agents for the purposes of: “A service request, for example, may be a request to perform a service in information technology (IT) systems, for example, solving a computer error or problem occurring in a computer system; the service requests are assigned to the service agents randomly here, for example, to have more variability in modeling data for building a cognitive dependency model” (see at least paragraphs 20-33).
It would have been obvious to one of ordinary skill in the art at the time of the invention to include cognitive service request dispatching as taught by Blomberg in the system of Gara, since the claimed invention is merely a combination of old elements, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable.
With regard to Claim 2, Gara teaches wherein the received service request from the customer device further comprises customer identifying information, applicable error code, description of problem, and services needed (see at least paragraphs 6-8, 31).
With regard to Claim 3, Gara teaches wherein the algorithm processes each step leading to generation of the final ranking without intervention by an administrator of the system (see at least paragraphs 58, 77, 102, 138, 146).
With regard to Claim 4, Gara teaches wherein portions of the algorithm may be disabled and replaced by administrator intervention, the intervention comprising at least manually changing the first technician to a second technician (see at least paragraphs 86, 94).
With regard to Claim 5, Gara teaches wherein technician devices and customer devices access the application and algorithm using separate client portions of the application (see at least paragraphs 58, 77, 94, 102, 138, 146).
With regard to Claim 6, Gara teaches wherein dispatched technicians are provided options to decline a dispatching (see at least paragraph 86).
With regard to Claim 7, Gara teaches wherein the system enables technician devices to access CRM and ERP sources to access certain information about customers associated with service calls (see at least paragraphs 6-8, 26, 38, 89).
With regard to Claim 8, Gara teaches wherein the system accepts feedback from technician devices about completed requests (see at least paragraph 50).
With regard to Claim 9, Gara teaches wherein administrators of the system communicate directly with customer devices and technician devices from a backend of the system (see at least paragraphs 50-51).
With regard to Claim 10, Gara teaches a system of handling service requests at field locations (The roadside assistance service provider application upon execution of computer-executable instructions from the roadside assistance service provider server is configured to perform the following steps: receive, by the roadside assistance service provider server, a roadside assistance service request from a driver of the distressed vehicle) (see at least paragraphs 6-8), comprising:
a technician device (mobile device; telematics device) (see at least paragraphs 6-8);
and a technician portion of a mobile application that: accesses an application and algorithm executing on a remote server (telematics information; This information may then be analyzed using particular rules and formulas to determine the roadside assistance service providers) hosting an Internet website (mobile service provider application 300 may also be able to be utilized via any internet connection on a given website or through an internet application), reports location of the device and availability of an associated technician to the remote server, receives assignment of a service call at a remote location requiring travel (a roadside assistance service provider server having at least one processor; a roadside assistance service provider application for use on a mobile device and executing on the roadside assistance service provider server; a plurality of sensors positioned on a vehicle of a roadside assistance service provider, and a telematics device in communication with a distressed vehicle and in communication with the roadside assistance service provider application. The plurality of sensors may collect roadside assistance service provider information for a roadside assistance service provider. The roadside assistance service provider may be a selected service provider from a crowdsourced group of individuals who are service providers, have registered with the roadside assistance system, and have been validated and/or verified to provide roadside assistance services including one or more of the following services: jump start, flat tire change, fuel the distressed vehicle, tow the distressed vehicle, or unlock a locked-out vehicle. The telematics device may provide telematics information to the roadside assistance service provider application and the roadside assistance service provider server), and one of accepts and declines the assignment (the service provider may review the service request and provide a bid for completing the service request. If the user has requested a specific price or price range, the service provider will either accept or reject the service request) (see at least paragraphs 6-8, 51, 57, 94);
wherein the device accesses applications and algorithms executing on remote servers (The mobile service provider server or roadside assistance service provider server 101 may operate in a networked environment supporting connections to one or more remote computers, such as terminals 141 and 151. The terminals 141 and 151 may be personal computers or servers that include many or all of the elements described above relative to the mobile service provider server or roadside assistance service provider server 101) for a plurality of product and service vendors, wherein the technician is qualified to provide field service for the vendors’ products and services (The methods and systems may include the use of an application on a mobile device that provides telematics information, service provider information to locate the service providers; prioritizes the service providers based on the user preferences, telematics information, and service provider information; and facilitates the service provider request and the electronic payment for the services. A system may allow the individual to register as a service provider and include their skills and qualifications. The system may provide a performance rating and/or user comments for the service providers. When a user needs services, such as a tire repair, the system may notify the service providers that meet predetermined criteria and allows them to bid on the services. The system may then select a service provider or allows the user to select the service provider. The system can include roadside services, automobile services, home services, and personal services)) (see at least paragraphs 23-30, 91-94).
With regard to Claim 11, Gara teaches wherein when a planned route of a technician associated with the technician device is observed by a customer device associated with the service request, the technician device receives a message from the customer device to travel by a different route (see at least paragraphs 6-8, 46, 51, 57, 70, 94).
With regard to Claim 12, Gara teaches wherein the device accesses CRM and ERP sources to access certain information about customers associated with service calls (see at least paragraphs 6-8, 51, 57, 94).
With regard to Claim 13, Gara teaches wherein the device auto populates technician data comprising at least one of drive time, average time on site, completed calls for a given day, first call fix average, and parts usage per call (see at least paragraphs 6-8, 51, 57, 94).
With regard to Claim 14, Gara teaches wherein the device auto populates customer data comprising customer contact information, contractual details, and service history (see at least paragraphs 6-8, 51, 57, 94).
With regard to Claim 15, Gara teaches a method for requesting onsite service (The roadside assistance service provider may be a selected service provider from a crowdsourced group of individuals who are service providers) have registered with the roadside assistance system) (see at least paragraphs 6-8, 51, 57, 94), comprising:
a customer device initiating a service request to a remote server hosting a website associated with a service provider (the process described with respect to FIG. 4 may be provided by a mobile service provider application 300 executing on a device such as a user's mobile communication device 215, through the internet or on a webpage, or a user's vehicle computer or navigation system), the service request seeking onsite service (a roadside assistance service provider server having at least one processor; a roadside assistance service provider application for use on a mobile device and executing on the roadside assistance service provider server; a plurality of sensors positioned on a vehicle of a roadside assistance service provider, and a telematics device in communication with a distressed vehicle and in communication with the roadside assistance service provider application. The plurality of sensors may collect roadside assistance service provider information for a roadside assistance service provider. The roadside assistance service provider may be a selected service provider from a crowdsourced group of individuals who are service providers, have registered with the roadside assistance system, and have been validated and/or verified to provide roadside assistance services including one or more of the following services: jump start, flat tire change, fuel the distressed vehicle, tow the distressed vehicle, or unlock a locked-out vehicle. The telematics device may provide telematics information to the roadside assistance service provider application and the roadside assistance service provider server) (see at least paragraphs 6-8, 51, 57, 65, 94);
the device including identifying information (The individuals may identify their qualifications, the types of services they can perform and their location. The computer-implemented method and system may determine a safety rating of the service provider based on various parameters such as a driving score, car insurance information, and payment history), location (determine, by the roadside assistance service provider server, the selected service provider based on a proximity in location between the distressed vehicle and the selected service provider), applicable error code (The application development environment 205 may further be used to validate the integrity of applications before deployment through one or more distribution channels such as application store/repository 210. Validating the integrity of an application may include executing the application against multiple data sets to insure correct operation, verifying security and privacy protections, verifying that the application adheres to one or more requirements or regulations (e.g., industry requirements, government regulations, privacy guidelines/requirements)), description of problem, and services needed in the service request (see at least paragraphs 6-8, 31);
the device receiving notification of a service request identification number and identifying information of a technician dispatched to the location, the technician associated with the service provider (The roadside assistance service provider system 600 may include 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.) that may be collected from the real world and stored in a data store, and analyzed using particular rules and/or formats. Particular roadside assistance service providers may be assigned to particular distressed vehicles/drivers based on one or more characteristics, including characteristics/rules. Other characteristics/criteria may include proximity in location, prior user ratings, equipment on the tow truck, skillset/expertise of the driver of the tow truck, price of the tow truck, etc. Additionally, the roadside assistance service provider system 600 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. The computer-implemented method and system may utilize insurance information to provide additional features and to enhance the mobile service provider methods and systems by providing known and safe routes and recommendations to the user);
wherein the device accesses multiple service providers for onsite service and wherein each of the multiple service providers is associated with a different manufacturer of goods (mobile service provider system 100 may utilize the bid price of the service and timing of the starting and completing the service request when selecting the service provider. Additionally, the mobile service provider system 100 may provide the user with a number of different options of service providers, such as three service providers and allow the user to select which service provider they would like. The user may be given different pricing and timing based on different potential service providers. In different situations, cost may be less significant and convenience or timing may become more significant. The user may be able to select these features to assist with selecting the service provider) (see at least paragraphs 6-8, 31, 59, 110-112).
With regard to Claim 16, Gara teaches further comprising the device initiating the service request via a downloadable application executing on the device (see at least paragraphs 6-8, 32).
With regard to Claim 17, Gara teaches further comprising the device tracking via global positioning system (GPS) movement of the first technician as the first technician travels to the location (see at least paragraph 33).
With regard to Claim 18, Gara teaches further comprising the device ordering supplies associated with the service request (see at least paragraphs 6-8, 32, 82, 86).
With regard to Claim 19, Gara teaches the device receiving updates on status of ordered supplies and updating tracking information for estimated time of arrival of the ordered supplies (see at least paragraphs 3, 6-8, 105).
With regard to Claim 20, Gara teaches further comprising the device communicating on a real time basis with website administrators of the service provider (see at least paragraphs 6-8, 38).
Conclusion
The prior art made of record and not relied upon is considered pertinent to Applicant's disclosure:
Vanderleek et al. (US 2021/0241340)
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 extension fee pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to THOMAS L MANSFIELD whose telephone number is (571)270-1904. The examiner can normally be reached M-Thurs, alt. Fri. (9-6).
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.
THOMAS L. MANSFIELD
Examiner
Art Unit 3623
/THOMAS L MANSFIELD/Primary Examiner, Art Unit 3624