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 .
Status of Claims
Claims 1-20 were rejected in the Non-Final Office action mailed on 09/18/2025. Applicant’s amended claimset, entered on 12/17/2025, amended Claims 1, 14-15, and 17-18 and canceled Claim 16. Herein this Final Office Action, Claims 1-15 and 17-20 are rejected.
Priority
Acknowledgment is made of applicant’s claim for domestic benefit to Provisional Application # 63/621519, filed on 01/16/2024.
Response to Arguments
Applicant’s arguments filed 12/17/2025, with respect to Rejections under 35 U.S.C. 112(b) for Claims 13, have been fully considered and are persuasive.
Applicant’s arguments filed 12/17/2025, with respect to Rejections under 35 U.S.C. 101 for Claims 1-15 and 17-20, have been fully considered and are not persuasive.
On Pages 8-11, Applicant argues that the claims are not directed to an abstract idea in Step 2A, focusing on Prong Two without conceding recitation of an abstract idea in Prong One. Applicant argues that Claim 1 integrates the recited abstract idea into a practical application by providing an improvement to technology. Specifically, “Claim 1 improves the functioning of known roadway maintenance workflows through automated detection, classification, routing, and communication implemented by vehicle-based systems and server-side processing.” Applicant cites Specification ¶27, ¶37, ¶39, ¶23, and ¶47 as support for the argument that “Claim 1 provides a concrete technical improvement by automating the end-to-end detection, classification, routing, and reporting of a repair request while also incentivizing a user to allow the vehicle to participate in the roadway maintenance system.” Additionally, Applicant references PEG Example 42 as an analogous improvement to technology (“. . . allowing remote user to share information in real time in a standardized format regardless of the format in which the information was input by the user.”). Examiner does not agree.
As outlined in MPEP 2106.05(a) a patent eligible improvement must be an improvement in the technology “itself,” not an improvement in the abstract idea itself. Thus, for the instant claims, Examiner must distinguish between an improvement in the functioning of the vehicle/computer system and an improvement in the business operations and administration of roadway repairs. MPEP 2106.05(a) further requires a “technical explanation” in the original disclosure that demonstrates the asserted improvement to the technology.
Specification ¶27 outlines the problem that the purported invention solves, i.e. drivers may not want to take time to report road damage and may not know who to report it to. This is directed to a business administration problem, similar to a business wanting more customer feedback on the quality of their product. Thus, this is not a technical problem, but a business problem a part of the abstract idea.
Specification ¶47 provides a solution of providing an incentive/reward or statement of appreciation for reporting roadway issue. This is a business solution to a business problem, and therefore is an improvement in the abstract idea itself.
Specification ¶23, ¶37, and ¶39 discuss computer automation of reporting the roadway issue, determining the entity responsible for the repair, and sending a repair request to that entity. Thus, a solution is provided by using a computer to automate manual tasks. However, MPEP 2106.50(a).I lists “iii. Mere automation of manual processes” as an example that may “may not be sufficient to show an improvement in computer-functionality.” Alternatively, MPEP 2106.05(a)II states “In McRO, the Federal Circuit held claimed methods of automatic lip synchronization and facial expression animation using computer-implemented rules to be patent eligible under 35 U.S.C. 101, because they were not directed to an abstract idea. McRO, 837 F.3d at 1316, 120 USPQ2d at 1103. The basis for the McRO court's decision was that the claims were directed to an improvement in computer animation and thus did not recite a concept similar to previously identified abstract ideas. Id. The court relied on the specification's explanation of how the claimed rules enabled the automation of specific animation tasks that previously could not be automated. 837 F.3d at 1313, 120 USPQ2d at 1101.” (Emphasis added).
In the instant application, Specification ¶23, ¶37, and ¶39 use generic computer capabilities, such as accessing databases, and transmitting messages based on rules. The disclosure does not provide sufficient technical explanation that demonstrates a technical improvement, but instead uses known computer components (i.e. additional elements) to apply the claimed abstract idea per MPEP 2106.05(f).
Similarly, the original disclosure does not provide a technical explanation as to how the converting of data to a certain format (i.e. email, text, or voicemail), similar to PEG Example 42, provides an improvement to the technology itself. Instead, the disclosure makes no mention of converting of formats, or how that could provide an improvement to technology. Thus, the rejection remains.
On Page 11, Applicant notes that one pathway to show “significantly more” in Step 2B is “well-understood, routine, [and] conventional activity” per MPEP 2106.05(i)(A)(v). Applicant argues that “the pending claims clearly recite more than well-understood, routine, or conventional functionality of systems for identifying and reporting roadway issues. The fact that the pending claims overcome the cited art, as explained further herein, strengthens the conclusion that these steps are not well understood, routine, and conventional.” Examiner does not agree.
MPEP 2106.05.I states “lack of novelty under 35 U.S.C. 102 or obviousness under 35 U.S.C. 103 of a claimed invention does not necessarily indicate that additional elements are well-understood, routine, conventional elements.” MPEP 2106.05.I.A provides six pathways of when courts have found “significantly more,” and four pathways of when courts have found not enough to qualify as “significantly more” (See “The Supreme Court has identified a number of considerations as relevant to the evaluation of whether the claimed additional elements amount to an inventive concept. The list of considerations here is not intended to be exclusive or limiting. Additional elements can often be analyzed based on more than one type of consideration and the type of consideration is of no import to the eligibility analysis. Additional discussion of these considerations, and how they were applied in particular judicial decisions, is provided in in MPEP § 2106.05(a) through (h).”).
Examiner responds that determining whether the claims are “well-understood, routine, or conventional” is not the stand alone test for determining whether the claims recite significantly more. Examiner further responds that withdrawal of art rejection does not demand patent eligible subject matter, i.e. a novel and non-obvious abstract idea is still an abstract idea.
The claims are determined to not recite significantly more because Examiner held that the claims (1) merely use the recited additional elements to apply the recited abstract idea (MPEP 2106.05(f), (2) merely link the abstract idea to a particular field of use (MPEP 2106.05(h)), and (3) does not provide an improvement to technology (MPEP 2106.05(a)). Therefore, the claims fail to provide “significantly more.”
Applicant’s arguments filed 10/10/2023, with respect to Rejections under 35 U.S.C. 103 for Claims 1-15 and 17-20, have been fully considered and are persuasive.
The prior art of record does not teach “ . . . generate roadway issue data including roadway issue classification data and the GPS location data associated with the roadway issue; transmit the roadway issue data to a remote server . . . that is communicatively coupled to the first controller, . . . cause the remote server, responsive to the roadway issue data, to automatically: . . . generate and transmit a repair request including at least a portion of the roadway issue data to the roadway related entity by converting the portion of the roadway issue data into at least one of a voicemail message, a text message, and an email message; . . .” (emphasis added) in representative Claim 1, as discussed in greater detail below.
Examiner notes that this limitation is rejected under 35 U.S.C. 112(a).
Claim Interpretation
Regarding independent Claims 1 and 14-15, representative Claim 1 recites “cause the remote server, responsive to the roadway issue data, to automatically: . . . generate and transmit a repair request including at least a portion of the roadway issue data to the roadway related entity by converting the portion of the roadway issue data into at least one of a voicemail message, a text message, and an email message” at paragraphs 8 and 10 (Emphasis added). The plain meaning of “converting [certain data] into at least one of a voicemail message, a text message, and an email message,” to a person of ordinary skill in the art, is more narrow than merely creating the “at least one of a voicemail message, a text message, and an email message” based on, as a result of, or using the “[certain data].” This limitation is more narrow than merely using “[certain data]” as an input, and outputting “at least one of a voicemail message, a text message, and an email message.” A person of ordinary skill in the art would understand “converting” data, i.e. data conversion, as including converting the format of the data, e.g. decoding the data, and encoding into a different format.
Thus, the instant limitation of “converting the portion of the roadway issue data into at least one of a voicemail message, a text message, and an email message” would include converting “the portion of the roadway issue data” in a certain formation, into the format of at least one of “a voicemail message, a text message, and an email message.” However, merely providing “the portion of the roadway issue data” as an input to a computer operation that outputs “a voicemail message, a text message, and an email message” is more broad than the scope of the claimed limitation.
Regarding independent Claim 14, Claim 14 recites “A vehicle comprising: . . . a first vehicle controller communicatively coupled to the plurality of sensors and the input/output device, wherein the first vehicle controller is configured to: . . . [(1)] transmit the roadway issue data to a remote server that is communicatively coupled to the first vehicle controller, . . . [(2)] cause the remote server, responsive to the roadway issue data, to automatically: [(2a)] determine, based on the roadway issue classification data and the GPS location data and using the roadway entity database, a roadway related entity responsible for addressing the roadway issue at the corresponding location; and [(2b)] generate and transmit a repair request including at least a portion of the roadway issue data to the roadway related entity by converting the portion of the roadway issue data into at least one of a voicemail message, a text message, and an email message; [(3)] receive confirmation data from the remote server; and [(4)] transmit the confirmation data to the input/output device.” (Emphasis added). Because the “first vehicle controller” “cause[s]” the operations of the “remote server” using the “roadway entity database,” a functional relationship exists between the “vehicle” and “remote server” under MPEP 2111. Thus, the limitations related to the “remote server” have patentable weight.
Regarding Claim 20, Claim 20 recites “A roadway issue reporting system in accordance with Claim 15, wherein the confirmation data includes at least one of: an indication of a reward presented to the user as an incentive for the user’s vehicle reporting the roadway issue; and a rating selection to be presented to the user, wherein the rating selection allows the user to provide feedback corresponding to the roadway related entity,” and depended upon Claim 15 recites “A roadway issue reporting system comprising: at least one memory device . . . ; and a server communicatively coupled to the at least one memory device and comprising at least one processor, wherein the server is configured to: . . . store the confirmation data as user account data.” The interpretation of “the user” recited in Claim 20 refers to the user of the “user account” recited in Claim 15. Thus, there is sufficient antecedent basis for the limitations of Claim 20.
Examiner notes that independent Claim 1 limits the “confirmation data” to data “corresponding to” certain messages, and dependent Claim 10 limits the “confirmation data” to the messages themselves. Thus, Claim 10 complies with 35 U.S.C. 112(d).
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
Claims 1-15 and 17-20 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention.
Representative independent Claim 1 states “the first controller [(of the vehicle)] is programmed to: . . . [(1)] generate roadway issue data . . .; [(2)] transmit the roadway issue data to a remote server . . .; [(3)] cause the remote server, responsive to the roadway issue data, to automatically: . . . generate and transmit a repair request including at least a portion of the roadway issue data to the roadway related entity by converting the portion of the roadway issue data into at least one of a voicemail message, a text message, and an email message; . . .” (Emphasis added).
Specification ¶39 states “For example, transmitting the repair request to the proper roadway related entity may include, but is not limited to, transmitting an automatically generated email message to the proper roadway related entity, transmitting an automatically generated voicemail message to the proper roadway related entity, and transmitting an automatically generated SMS text message to the proper roadway related entity.” (Emphasis added).
Specification ¶52 states “In at least some embodiments, the remote server 140 determines 414 the proper roadway related entity to send a repair request and then transmits 416 the roadway issue data to that entity. Transmitting 416 the roadway issue data may include transmitting a repair request to the proper roadway related entity. That may include, for example, at least one of transmitting an automatically generated email message to the proper roadway related entity, transmitting an automatically generated voicemail message to the proper roadway related entity, and transmitting an automatically generated SMS text message to the proper roadway related entity.” (Emphasis added).
Therefore, the Specification discloses transmitting the “roadway issue data” including “a repair request,” which may include the automatic generation of an email, text, or voicemail message.
Applicant’s disclosure makes no mention of the format of the “roadway issue data,” converting data, or how the email, text, or voicemail message is “automatically generated.” Thus, Examiner finds that the limitation of automatically generating the email, text, or voicemail message “by converting the portion of the roadway issue data into at least one of a voicemail message, a text message, and an email message” is not supported by the disclosure. Therefore, this limitation is rejected under 35 U.S.C. 112(a).
Independent Claims 14-15 recite a similar limitation of “by converting the portion of the roadway issue data into at least one of a voicemail message, a text message, and an email message,” and therefore are rejected under 35 U.S.C. 112(a) by similar justification to Claim 1 discussed above.
Claims 2-13 and 17-20 are rejected under 35 U.S.C. 112(a) via dependency.
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
Claims 1-13 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.
Claim 1 recites the limitation ". . . data corresponding to an acknowledgement or reward associated with the vehicle reporting the roadway issue.” There is insufficient antecedent basis for this limitation in the claim as no “a vehicle” is introduced prior. Solely for purposes of compact prosecution, further examination herein will interpret this limitation as stating “". . . data corresponding to an acknowledgement or reward associated with the reporting of the roadway issue.”
Claims 2-13 are rejected under 35 U.S.C. 112(b) via dependency.
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-15 and 17-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
Step 1
Claims 1-13 recite a system (i.e. a machine or manufacture), Claim 14 recite a vehicle (i.e. a machine or manufacture), and Claims 15 and 17-20 recite a system (i.e. a machine or manufacture). Therefore, Claims 1-15 and 17-20 all fall within the one of the four statutory categories of invention of 35 U.S.C. 101.
Step 2A, Prong One
Independent Claim 1 recites the abstract idea of:
“. . . receive roadway data and GPS location data . . . ;
detect a roadway issue based on the roadway data and a corresponding location based on the GPS location data;
generate roadway issue data including roadway issue classification data and the GPS location data associated with the roadway issue;
transmit the roadway issue data . . . ;
storing a roadway entity [information] that correlates, for each of a plurality of roadway related entities, (i) roadway issue classification data and (ii) roadway locations or roadway segments for which the roadway related entity is responsible;
cause . . . , responsive to the roadway issue data, to automatically:
determine, based on the roadway issue classification data and the GPS location data and using the roadway entity [information], a roadway related entity responsible for addressing the roadway issue at the corresponding location; and
generate and transmit a repair request including at least a portion of the roadway issue data to the roadway related entity by converting the portion of the roadway issue data into at least one of a [certain message format];
receive confirmation data . . . ; and
present the confirmation data to a user, wherein the confirmation data includes at least one of data corresponding to a message confirming receipt of the roadway issue data, and data corresponding to an acknowledgement or reward associated with the vehicle reporting the roadway issue.”
The limitations stated above are processes/ functions that under broadest reasonable interpretation covers (1) receiving roadway and location data, (2) detecting roadway issues based on received data, (3) generating and transmitting roadway issue data that classifies the roadway issue, (4) storing information that correlates entities and their responsibilities for certain issues and locations, (5) determining which entity is responsible based on certain information, (6) generating and transmitting a repair request by converting a portion of the issue data into a certain format, and (7) receiving and presenting confirmation data which represents certain information, all of which are recitations of: commercial or legal interactions (i.e. generating and receiving roadway issue data, determining an entity responsible for a repair, generating a repair request, and sending confirmation data including a reward are at least “sales activities or behaviors” and information that correlates an entity with its repair responsibility and using that to determine responsibility are at least “agreements in the form of contracts,” “legal obligations,” or “business relations”) and managing personal behavior or relationships or interactions between people (i.e. converting the format of messages is at least “social activities” and “following rules or instructions”), which are certain methods of organizing human activity, an abstract idea, under MPEP 2106.04(a)(2)II, and observations (i.e. receiving roadway data and location data to detect a roadway issue) and evaluations and judgments (i.e. detecting a roadway issue based on roadway data and location data and classifying the roadway issue), which are mental processes, an abstract idea, under MPEP 2106.04(a)(2)III.
The mere the recitation of generic computer components (i.e., the “roadway issue detecting and reporting system,” “plurality of sensors,” “global positioning system (GPS) sensor,” “roadway observing sensor,” “first controller,” “remote server,” “memory,” “database,” and “at least one of a voicemail message, a text message, and an email message”) implementing the identified abstract idea does not take the claim out of the certain methods of organizing human activity and mental processes groupings. MPEP 2106.04(d). If a claim limitation, under its broadest reasonable interpretation, covers “commercial or legal interactions,” “managing personal behavior or relationships or interactions between people,” “observations,” “evaluations,” and “judgements,” but for the recitation of generic computer components, then it falls in the certain methods of organizing human activity or mental processes groupings of abstract ideas. MPEP 2106.04. Therefore, Claim 1 recites an abstract idea.
Step 2A, Prong Two
The judicial exception is not integrated into a practical application. Claim 1 as a whole amounts to: (i) merely invoking generic components as a tool to perform the abstract idea or “apply it” (or an equivalent) and (ii) generally links the use of a judicial exception to a particular technological environment or field of use. The claim recites the additional elements of:
(i) roadway issue detecting and reporting system,
(ii) plurality of sensors including
(iii) global positioning system (GPS) sensor and
(iv) roadway observing sensor,
(v) first controller,
(vi) remote server,
(vii) memory,
(viii) database, and
(ix) at least one of a voicemail message, a text message, and an email message.
The additional elements of (i) roadway issue detecting and reporting system (Fig. 3 and ¶38 shows “roadway issue detecting and reporting system 200.”), (ii) plurality of sensors including (iii) global positioning system (GPS) sensor and (iv) roadway observing sensor (Fig. 1 and ¶33 shows “the plurality of sensors 105 includes at least one roadway observing sensor and a Global Positioning System (GPS) sensor/receiver.” See also ¶34 further showing “sensors 105.”), (v) first controller (Fig. 1 and ¶33 shows “In the exemplary embodiment, the first controller 110 is a vehicle controller integrated within vehicle 100. In alternative embodiments, first controller 110 is included in a device or devices positioned within or on vehicle 100.”), (vi) remote server (Fig. 3 and ¶39 shows “remote server 140.”), (vii) memory (Fig. 3 and ¶39 shows “memory 142”), (viii) database (Fig. 3 and ¶39 shows “database 144.”), and (ix) at least one of a voicemail message, a text message, and an email message (¶39 shows generation of voicemail, text, and email messages), are recited at a high-level of generality, such that, when viewed as whole/ordered combination (Fig. 1 and 3, ¶33, and ¶¶38-39 shows elements in combination.), they amount to no more than mere instruction to apply the judicial exception using generic computer components or “apply it” (See MPEP 2106.05(f)).
The (i) roadway issue detecting and reporting system, (ii) plurality of sensors including (iii) global positioning system (GPS) sensor and (iv) roadway observing sensor, (v) first controller, (vi) remote server, (vii) memory, (viii) database, and (ix) at least one of a voicemail message, a text message, and an email message, when viewed as whole/ordered combination (Fig. 1 and 3, ¶33, and ¶¶38-39 shows elements in combination.), does no more than generally link the use of the judicial exception to a particular technological environment or field of use (i.e. vehicular computing) (See MPEP 2106.05(h)).
Accordingly, these additional elements, when viewed as a whole/ordered combination (Fig. 1 and 3, ¶33, and ¶¶38-39 shows elements in combination.), do not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea. Thus, the claim is directed to an abstract idea.
Step 2B
As discussed above with respect to Step 2A Prong Two, the additional elements amount to no more than: (i) “apply it” (or an equivalent) and (ii) generally link the use of a judicial exception to a particular technological environment or field of use, and are not a practical application of the abstract idea. The same analysis applies here in Step 2B, i.e., (i) merely invoking the generic components as a tool to perform the abstract idea or “apply it” (See MPEP 2106.05(f)) and (ii) generally linking the use of a judicial exception to a particular technological environment or field of use (See MPEP 2106.05(h)), does not integrate the abstract idea into a practical application at Step 2A or provide an inventive concept at Step 2B.
Therefore, the additional elements of the (i) roadway issue detecting and reporting system, (ii) plurality of sensors including (iii) global positioning system (GPS) sensor and (iv) roadway observing sensor, (v) first controller, (vi) remote server, (vii) memory, (viii) database, and (ix) at least one of a voicemail message, a text message, and an email message, do not integrate the abstract idea into a practical application at Step 2A or provide an inventive concept at Step 2B. Thus, even when viewed as a whole/ordered combination (Fig. 1 and 3, ¶33, and ¶¶38-39 shows elements in combination.), nothing in the claims adds significantly more (i.e., an inventive concept) to the abstract idea. Thus, the claim is ineligible.
Dependent Claims 2-13 recite the abstract idea of:
“. . . to receive user identification data.” (Claim 2);
“. . . , wherein receive user identification data includes receiving data, . . . , identifying a driver and/or owner of the vehicle.” (Claim 3);
“. . ., wherein receiving data identifying the driver and/or owner of the vehicle comprises receiving a username and password associated with the driver and/or owner of the vehicle, wherein the username and password are configured to prove enrollment in a roadway issue reporting service.” (Claim 4);
“. . . , wherein detect a roadway issue comprises analyzing the roadway data to detect roadway issues identifiable within the roadway data.” (Claim 7);
“. . . , wherein the roadway issue classification data defines a type of roadway issue detected, and wherein the type of roadway issue includes at least one of a stationary hazard, a temporary hazards, a pothole, debris in the roadway, a damaged and/or illegible street sign, an unlit streetlight, a downed power line, and a damaged roadway barrier.” (Claim 8);
“. . . wherein present the confirmation data to the user includes outputting, . . . , a visual and/or auditory representation of the confirmation data.” (Claim 9);
“. . . , wherein the confirmation data includes at least one of a message confirming receipt of the roadway issue data, a message including information identifying a roadway related entity in receipt of the roadway issue data, a message including a statement of appreciation for reporting the roadway issue, and a message indicating a repair schedule, a repair status, and completion of a repair corresponding to the roadway issue.” (Claim 10);
“. . . , wherein the confirmation data includes an indication of a reward presented to the user as an incentive for the vehicle reporting the roadway issue.” (Claim 11);
“. . . , wherein the reward is at least one of a proprietary token, benefits, discounts, and an improved rating either sharable among predefined friends or publicly.” (Claim 12); and
“. . . present a rating selection to the user, wherein the rating selection allows the user to provide feedback corresponding to the roadway related entity.” (Claim 13).
Dependent Claims 2-13, have been given the full two-prong analysis including analyzing the further elements and limitations, both individually and in combination. When analyzed individually and in combination, these claims are also held to be patent ineligible under 35 U.S.C. 101. The further limitation of Claims 2-13 fail to establish claims that are not directed to an abstract idea because the further limitations include (1) receiving identification data including a username and password that identify the driver and prove enrollment in reporting service, (2) the roadway issue classification classifies the type of issue which includes certain types of issues, (3) presenting confirmation data includes outputting visual and/or auditory representation, (4) confirmation data includes a message of certain information, and (5) presenting rating selection to the user, as part of the abstract idea. The further elements of Claims 2-13 (i.e. “first controller” of Claims 2, 5, and 13, “at least one of an input device of a vehicle and a smartphone communicatively coupled to the vehicle” of Claim 3, “a vehicle controller included within a vehicle” of Claim 5, “the roadway observing sensor includes at least one of a camera, a radar, and a LIDAR” of Claim 6, “a display device communicatively coupled to the first controller, wherein the display device comprises at least one of a display screen and an audio output device” of Claim 9) fails to establish claims that are not directed to an abstract idea because the elements merely recite additional generic computer hardware similar to the generic computer components of Claim 1 (Fig. 1 and 3.) or generally link the abstract idea to a particular technology or field of use (i.e. vehicular computing) just as in Claim 1. The organization of the further limitations of Claims 2-13 fail to integrate an abstract idea into a practical application just as discussed above for Claim 1. Additionally, performing the abstract idea of Claim 1 as recited in each of the further limitations of Claims 2-13, individually or in combination, does not (1) impose any meaningful limits on practicing the abstract ideas, or (2) provide improvements to the functioning of computing systems or to another technology or technical field, just as discussed above regarding Claim 1. Therefore, Claims 2-13 amount to mere instructions to implement the abstract idea (1) using generic computer components—using the computer, in its ordinary capacity, as a tool to perform the abstract idea, and (2) generally linked to a particular technology or field of use. Because the claims merely use a computer, in its ordinary capacity in a particular field of use, as a tool to perform the abstract idea cannot provide an inventive concept, the elements and limitations of Claims 2-13 fail to establish that the claims provide an inventive concept, just as in Claim 1. Therefore, Claims 2-13 fails the Subject Matter Eligibility Test and are consequently rejected under 35 U.S.C. 101.
Step 2A, Prong One
Independent Claim 14 recites the abstract idea of:
“. . . receive roadway data and GPS location data . . . ;
detect a roadway issue based on the roadway data and a corresponding location based on the GPS location data;
generate roadway issue data including roadway issue classification data and the GPS location data associated with the roadway issue;
transmit the roadway issue data . . . ;
storing a roadway entity [information] that correlates, for each of a plurality of roadway related entities, (i) roadway issue classification data and (ii) roadway locations or roadway segments for which the roadway related entity is responsible;
cause . . . , responsive to the roadway issue data, to automatically:
determine, based on the roadway issue classification data and the GPS location data and using the roadway entity [information], a roadway related entity responsible for addressing the roadway issue at the corresponding location; and
generate and transmit a repair request including at least a portion of the roadway issue data to the roadway related entity by converting the portion of the roadway issue data into at least one of a [certain message format];
receive confirmation data . . . ; and
transmit the confirmation data . . .”
The limitations stated above are processes/ functions that under broadest reasonable interpretation covers (1) receiving roadway and location data, (2) detecting roadway issues based on received data, (3) generating and transmitting roadway issue data that classifies the roadway issue, (4) storing information that correlates entities and their responsibilities for certain issues and locations, (5) determining which entity is responsible based on certain information, (6) generating and transmitting a repair request by converting a portion of the issue data into a certain format, and (7) receiving and transmitting confirmation data, all of which are recitations of: commercial or legal interactions (i.e. generating and receiving roadway issue data, determining an entity responsible for a repair, generating a repair request, and sending confirmation data are at least “sales activities or behaviors” and information that correlates an entity with its repair responsibility and using that to determine responsibility are at least “agreements in the form of contracts,” “legal obligations,” or “business relations”) and managing personal behavior or relationships or interactions between people (i.e. converting the format of messages is at least “social activities” and “following rules or instructions”), which are certain methods of organizing human activity, an abstract idea, under MPEP 2106.04(a)(2)II, and observations (i.e. receiving roadway data and location data to detect a roadway issue) and evaluations and judgments (i.e. detecting a roadway issue based on roadway data and location data and classifying the roadway issue), which are mental processes, an abstract idea, under MPEP 2106.04(a)(2)III.
The mere the recitation of generic computer components (i.e., the “vehicle,” “plurality of sensors,” “global positioning system (GPS) sensor,” “roadway observing sensor,” “input/output device,” “first controller,” “remote server,” “memory,” “database,” and “at least one of a voicemail message, a text message, and an email message”) implementing the identified abstract idea does not take the claim out of the certain methods of organizing human activity and mental processes groupings. MPEP 2106.04(d). If a claim limitation, under its broadest reasonable interpretation, covers “commercial or legal interactions,” “managing personal behavior or relationships or interactions between people,” “observations,” “evaluations,” and “judgements,” but for the recitation of generic computer components, then it falls in the certain methods of organizing human activity or mental processes groupings of abstract ideas. MPEP 2106.04. Therefore, Claim 14 recites an abstract idea.
Step 2A, Prong Two
The judicial exception is not integrated into a practical application. Claim 14 as a whole amounts to: (i) merely invoking generic components as a tool to perform the abstract idea or “apply it” (or an equivalent) and (ii) generally links the use of a judicial exception to a particular technological environment or field of use. The claim recites the additional elements of:
(i) vehicle,
(ii) plurality of sensors including
(iii) global positioning system (GPS) sensor and
(iv) roadway observing sensor,
(v) input/output device,
(vi) first controller,
(vii) remote server,
(viii) memory,
(ix) database, and
(x) at least one of a voicemail message, a text message, and an email message.
The additional elements of (i) vehicle (Fig. 1 and ¶32 shows “vehicle 100.”), (ii) plurality of sensors including (iii) global positioning system (GPS) sensor and (iv) roadway observing sensor (Fig. 1 and ¶33 shows “the plurality of sensors 105 includes at least one roadway observing sensor and a Global Positioning System (GPS) sensor/receiver.” See also ¶34 further showing “sensors 105.”), (v) input/output device (Fig. 1 and ¶35 shows “an input/output device, for example, an infotainment panel 120 and/or one or more portable computer devices, such as a mobile device 125.”), (vi) first controller (Fig. 1 and ¶33 shows “In the exemplary embodiment, the first controller 110 is a vehicle controller integrated within vehicle 100. In alternative embodiments, first controller 110 is included in a device or devices positioned within or on vehicle 100.”), (vii) remote server (Fig. 3 and ¶39 shows “remote server 140.”), (viii) memory (Fig. 3 and ¶39 shows “memory 142”), (ix) database (Fig. 3 and ¶39 shows “database 144.”), and (x) at least one of a voicemail message, a text message, and an email message (¶39 shows generation of voicemail, text, and email messages), are recited at a high-level of generality, such that, when viewed as whole/ordered combination (Fig. 1 and 3, ¶33, and ¶¶38-39 shows elements in combination.), they amount to no more than mere instruction to apply the judicial exception using generic computer components or “apply it” (See MPEP 2106.05(f)).
The (i) roadway issue detecting and reporting system, (ii) plurality of sensors including (iii) global positioning system (GPS) sensor and (iv) roadway observing sensor, (v) input/output device, (vi) first controller, (vii) remote server, (viii) memory, (ix) database, and (x) at least one of a voicemail message, a text message, and an email message, when viewed as whole/ordered combination (Fig. 1 and 3, ¶33, and ¶¶38-39 shows elements in combination.), does no more than generally link the use of the judicial exception to a particular technological environment or field of use (i.e. vehicular computing) (See MPEP 2106.05(h)).
Accordingly, these additional elements, when viewed as a whole/ordered combination (Fig. 1 and 3, ¶33, and ¶¶38-39 shows elements in combination.), do not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea. Thus, the claim is directed to an abstract idea.
Step 2B
As discussed above with respect to Step 2A Prong Two, the additional elements amount to no more than: (i) “apply it” (or an equivalent) and (ii) generally link the use of a judicial exception to a particular technological environment or field of use, and are not a practical application of the abstract idea. The same analysis applies here in Step 2B, i.e., (i) merely invoking the generic components as a tool to perform the abstract idea or “apply it” (See MPEP 2106.05(f)) and (ii) generally linking the use of a judicial exception to a particular technological environment or field of use (See MPEP 2106.05(h)), does not integrate the abstract idea into a practical application at Step 2A or provide an inventive concept at Step 2B.
Therefore, the additional elements of the (i) roadway issue detecting and reporting system, (ii) plurality of sensors including (iii) global positioning system (GPS) sensor and (iv) roadway observing sensor, (v) input/output device, (vi) first controller, (vii) remote server, (viii) memory, (ix) database, and (x) at least one of a voicemail message, a text message, and an email message, do not integrate the abstract idea into a practical application at Step 2A or provide an inventive concept at Step 2B. Thus, even when viewed as a whole/ordered combination (Fig. 1 and 3, ¶33, and ¶¶38-39 shows elements in combination.), nothing in the claims adds significantly more (i.e., an inventive concept) to the abstract idea. Thus, the claim is ineligible.
Step 2A, Prong One
Independent Claim 15 recites the abstract idea of:
“. . . storing a roadway entity [information] that correlates, for each of a plurality of roadway related entities, (i) roadway issue classification data and (ii) roadway locations or roadway segments for which the roadway related entity is responsible; and
. . .
receive roadway issue data from a vehicle, wherein the roadway issue data includes roadway issue classification data and GPS location data corresponding to a location of the roadway issue;
determine , based on the roadway issue classification data and the GPS location data and using the roadway entity [information], a roadway related entity responsible for addressing the roadway issue at the corresponding location;
generate a repair request including at least a portion of the roadway issue data by converting the portion of the roadway issue data into at least one of [certain message format];
transmit [[a]] the repair request to the proper roadway related entity;
receive confirmation data from the proper roadway related entity; and
store the confirmation data as user account data.”
The limitations stated above are processes/ functions that under broadest reasonable interpretation covers (1) receiving roadway and location data, (2) storing information that correlates entities and their responsibilities for certain issues and locations, (3) determining which entity is responsible based on certain information, (4) generating and transmitting a repair request by converting a portion of the issue data into a certain format, and (5) receive and store confirmation data, all of which are recitations of: commercial or legal interactions (i.e. receiving roadway issue data, determining an entity responsible for a repair, generating a repair request, and receiving and storing confirmation data are at least “sales activities or behaviors” and information that correlates an entity with its repair responsibility and using that to determine responsibility are at least “agreements in the form of contracts,” “legal obligations,” or “business relations”) and managing personal behavior or relationships or interactions between people (i.e. converting the format of messages is at least “social activities” and “following rules or instructions”), which are certain methods of organizing human activity, an abstract idea, under MPEP 2106.04(a)(2)II, and observations (i.e. receiving roadway data and location data to detect a roadway issue) and evaluations and judgments (i.e. determining proper roadway entity and classifying the roadway issue), which are mental processes, an abstract idea, under MPEP 2106.04(a)(2)III.
The mere the recitation of generic computer components (i.e., the “roadway issue reporting system,” “server,” “at least one memory device,” “at least one processor,” “database,” and “at least one of a voicemail message, a text message, and an email message”) implementing the identified abstract idea does not take the claim out of the certain methods of organizing human activity and mental processes groupings. MPEP 2106.04(d). If a claim limitation, under its broadest reasonable interpretation, covers “commercial or legal interactions,” “managing personal behavior or relationships or interactions between people,” “observations,” “evaluations,” and “judgements,” but for the recitation of generic computer components, then it falls in the certain methods of organizing human activity or mental processes groupings of abstract ideas. MPEP 2106.04. Therefore, Claim 15 recites an abstract idea.
Step 2A, Prong Two
The judicial exception is not integrated into a practical application. Claim 15 as a whole amounts to: (i) merely invoking generic components as a tool to perform the abstract idea or “apply it” (or an equivalent) and (ii) generally links the use of a judicial exception to a particular technological environment or field of use. The claim recites the additional elements of:
(i) roadway issue reporting system,
(ii) server,
(iii) memory device,
(iv) processor, and
(v) database, and
(vi) at least one of a voicemail message, a text message, and an email message.
The additional elements of (i) roadway issue reporting system (Fig. 3 and ¶38 shows “roadway issue detecting and reporting system 200.” Fig. 3 and ¶39 shows “remote server 140.” Fig. 8 and ¶66 shows “configuration 700 of a server computer device 701.”), (ii) server (Fig. 3 and ¶39 shows “remote server 140.” Fig. 8 and ¶66 shows “configuration 700 of a server computer device 701.”), (iii) memory (Fig. 3 and ¶39 shows “memory 142.” Fig. 8 and ¶¶68-71 shows “storage device 734.”), (iv) processor (Fig. 8 and ¶¶66-71 shows “processor 705.”), (v) database (Fig. 3 and ¶39 shows “database 144.”), and (vi) at least one of a voicemail message, a text message, and an email message (¶39 shows generation of voicemail, text, and email messages), are recited at a high-level of generality, such that, when viewed as whole/ordered combination (Fig. 3, 8, ¶¶38-39, and ¶¶66-71 shows elements in combination.), they amount to no more than mere instruction to apply the judicial exception using generic computer components or “apply it” (See MPEP 2106.05(f)).
The (i) roadway issue reporting system, (ii) server, (iii) memory device, (iv) processor, (v) database, and (vi) at least one of a voicemail message, a text message, and an email message, when viewed as whole/ordered combination (Fig. 3, 8, ¶¶38-39, and ¶¶66-71 shows elements in combination.), does no more than generally link the use of the judicial exception to a particular technological environment or field of use (i.e. online computing environment) (See MPEP 2106.05(h)).
Accordingly, these additional elements, when viewed as a whole/ordered combination (Fig. 3, 8, ¶¶38-39, and ¶¶66-71 shows elements in combination.), do not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea. Thus, the claim is directed to an abstract idea.
Step 2B
As discussed above with respect to Step 2A Prong Two, the additional elements amount to no more than: (i) “apply it” (or an equivalent) and (ii) generally link the use of a judicial exception to a particular technological environment or field of use, and are not a practical application of the abstract idea. The same analysis applies here in Step 2B, i.e., (i) merely invoking the generic components as a tool to perform the abstract idea or “apply it” (See MPEP 2106.05(f)) and (ii) generally linking the use of a judicial exception to a particular technological environment or field of use (See MPEP 2106.05(h)), does not integrate the abstract idea into a practical application at Step 2A or provide an inventive concept at Step 2B.
Therefore, the additional elements of the (i) roadway issue reporting system, (ii) server, (iii) memory device, (iv) processor, (v) database, and (vi) at least one of a voicemail message, a text message, and an email message, do not integrate the abstract idea into a practical application at Step 2A or provide an inventive concept at Step 2B. Thus, even when viewed as a whole/ordered combination (Fig. 3, 8, ¶¶38-39, and ¶¶66-71 shows elements in combination.), nothing in the claims adds significantly more (i.e., an inventive concept) to the abstract idea. Thus, the claim is ineligible.
Dependent Claims 16-20 recite the abstract idea of:
“. . . , wherein the roadway entity [information] includes: types of roadway issues the roadway related entity is responsible for addressing; the roadways, and specific locations along the roadways, that the roadway related entity is responsible for maintaining; and contact information for the roadway related entity.” (Claim 17);
“. . . , wherein transmit a repair request to the proper roadway related entity includes transmitting the roadway issue data corresponding to the roadway issue and GPS location to the proper roadway related entity.” (Claim 18);
“. . . , wherein store the confirmation data as user account data includes storing at least one of a message confirming receipt of the data corresponding to the roadway issue, a message including information identifying a roadway related entity in receipt of the data corresponding to the roadway issue, a message including a statement of appreciation for reporting the roadway issue, and a message indicating a status of a repair corresponding to the roadway issue.” (Claim 19); and
“. . . , wherein the confirmation data includes at least one of: an indication of a reward presented to the user as an incentive for the user’s vehicle reporting the roadway issue; and a rating selection to be presented to the user, wherein the rating selection allows the user to provide feedback corresponding to the roadway related entity.” (Claim 20).
Dependent Claims 17-20, have been given the full two-prong analysis including analyzing the further elements and limitations, both individually and in combination. When analyzed individually and in combination, these claims are also held to be patent ineligible under 35 U.S.C. 101. The further limitation of Claims 17-20 fail to establish claims that are not directed to an abstract idea because the further limitations include (1) determining a roadway corresponding to the location of the issue and accessing entity data which includes certain information, (2) the repair request includes the issue and location, (3) storing the confirmation data as user account data includes storing certain information including certain messages, and (4) the confirmation data includes certain information including a reward or feedback opportunity, as part of the abstract idea. The elements of Claims 17-20 (i.e. elements of Claim 15) fails to establish claims that are not directed to an abstract idea because the elements merely recite generic computer components of Claim 15 or generally link the abstract idea to a particular technology and field of use (i.e. online computing environment) just as in Claim 15. The organization of the further limitations of Claims 17-20 fail to integrate an abstract idea into a practical application just as discussed above for Claim 15. Additionally, performing the abstract idea of Claim 15 as recited in each of the further limitations of Claims 17-20, individually or in combination, does not (1) impose any meaningful limits on practicing the abstract ideas, or (2) provide improvements to the functioning of computing systems or to another technology or technical field, just as discussed above regarding Claim 15. Therefore, Claims 17-20 amount to mere instructions to implement the abstract idea (1) using generic computer components—using the computer, in its ordinary capacity, as a tool to perform the abstract idea, and (2) generally linked to a particular technology or field of use. Because the claims merely use a computer, in its ordinary capacity in a particular field of use, as a tool to perform the abstract idea cannot provide an inventive concept, the elements and limitations of Claims 17-20 fail to establish that the claims provide an inventive concept, just as in Claim 15. Therefore, Claims 17-20 fails the Subject Matter Eligibility Test and are consequently rejected under 35 U.S.C. 101.
Reasons for No Art Rejection
Claims 1-15 and 17-20 are not rejected over the prior art of record.
The Closest prior art of record is:
US-20230099178-A1 (“Selbie”);
US-20200394725-A1 (“Bharti”);
US-20210344484-A1 (“Pasquali”);
US-20150161540-A1 (“Akselrod”);
US-20240152876-A1 (“Kimura”);
US-20180073208-A1 (“Wilson”);
US-20180286246-A1 (“Baca”);
US-20180364722-A1 (“Schlesinger”);
US-20200262438-A1 (“Bai”);
“Roads are a public utility” (“Rabe” 06/28/2017, Letters to the editor The Oregonian, https://www.oregonlive.com/opinion/2017/06/roads_are_a_public_utility_let.html);
“Asheville Public Works crews cleaning up debris after storm” (“CAPE” 09/12/2017, The City of Asheville, https://www.ashevillenc.gov/news/asheville-public-works-crews-cleaning-up-debris-after-storm/);
US-20050065711-A1 (“Dahlgren”);
US-20100162364-A1 (“Roth”);
US-20060047543-A1 (“Moses”);
US-20160343087-A1 (“Dange”);
US-20140196529-A1 (“Cronin”);
WO-2014172325-A1 (“Ricci”);
US-20120296683-A1 (“Groeneweg”);
US-20160275404-A1 (“Abraham”)
US-20220242337-A1 (“Garg”);
US-20140160295-A1 (“Kyomitsu”);
KR-102136576-B1 (“Choi”).
The Following is an examiner’s statement of reasons for no art rejection:
Selbie shows using vehicle sensors to collect roadway data and update a map of roadway issues and damage including incentives for reporting road conditions for certain areas. Selbie shows a feedback loop such that repair crews can mark the issue as resolved and another vehicle can verify that the issue has been fixed. However, Selbie does not teach specific details as to how the repair crew would utilize the map as claimed.
Bharti shows an asset monitoring system that receives damage data from agents, and then broadcasts a message for the issue to be fixed. Bharti shows some data is parsed and tokenized to trigger an event text-based message. However, Bharti does not teach that the parsed data is data received from the vehicle and that the received data is converted to an email, text, or voicemail message.
Pasquali shows a road condition reporting system that uses sensors to detect road damage, and provides notifications to interested subscribers. Although the subscribers are provided with a data stream, Pasquali does not explicitly teach converting formats to an email, text, or voicemail message for a request for repair.
Akselrod shows determining what road maintenance resources are needed to fix a detected road maintenance issue. Additionally, Akselrod shows use of a phone text or message as a means for communication. However, Akselrod does not teach that a portion of the received repair issue data is converted to an email, text, or voicemail message.
Kimura shows detecting road damage, notifying the business operator responsible for that section of road, who dispatches a worker to first confirm the road damage and then repair the road damage. However, Kimura does not discuss the format or form, or conversion thereof, of the communications.
Wilson shows collecting road quality indicators by a vehicle. Upon the quality indicator exceeding a threshold, transmitting location of road issue to a server. Upon multiple vehicles reporting the road issue, transmitting a road maintenance request. However, Wilson does not discuss the format or form, or conversion thereto, of the maintenance request message.
Baca shows that vehicles detect road hazards and transmit road hazard and location data to a cloud-based server. The server notifies the maintenance authority responsible for the roadway including details of the road hazard and the location of the hazard. Upon clearing the road hazard, an update is transmitted to the cloud-based server. Although the message to the maintenance authorities includes the hazard and location, Baca does not discuss the format or form, or conversion thereto, of the message.
Schlesinger shows a Road Hazard Detection (RHD) app that connects to a vehicle. The app receives and analyzes signal data to determine the existence of a road hazard, and then transmits the nature of the hazard to an RHD server to report the hazard. Although Schlesinger shows that the hazard map may be further communicated to other users, including authorities, Schlesinger does not discuss the specifics of which users, what format, and how those subsequent communications are generated.
Bai shows vehicles that capture roadway data and classify the condition of the road, and then transmitting data to a roadway manager. Maintenance providers can pay for the data using a calculated price or a bid systems. Roadway manager vehicles can be dispatched and provide feedback regarding the remedy of the roadway issue. However, Bai does not discuss the format or form, or conversion thereto, of the maintenance request message.
Rabe shows that roads can be considered public utilities.
CAPE shows that downed power lines and trees can block roads.
Dahlgren shows using vehicle sensors to detect unacceptable roadway conditions, and a centralized facility that notifies the relevant authority, i.e. roadway maintenance authorities or local, state, or federal governmental authorities. However, Dahlgren does not discuss the format or form, or conversion thereto, of the notification to authorities.
Roth shows a push notification system that converts a generated message to a specific format such a email, sms text, or via telephone. This system can be used by a local government to send a repair request to public works employees, while excluding other city employees. However, Roth does not show that the message is generated from a portion of the claimed “roadway issue data.”
Moses shows an emergency response database that allocates a response based on each response vehicle’s capabilities. The dispatching alert can take the form of an email, voice, or text message. However, Moses only broadly relates to sensors that detect “road conditions.” Further, Moses does not show that a portion of the event report is converted to the alert email, voice, or text message.
Dange shows posting an image, text description, and location of a roadway issue on a social media platform. Dange shows that the platform classifies the issue by extracting n-grams from the text of the post. Then based on the classification, Dange shows the platform assigning the post to the agency responsible. Dange shows that the platform includes a mail server for messaging functionality. Dange shows use of monetary incentives for users engaging in civic activity. However, Dange shows the classification being done on the platform, and therefore does teach that the received information (including classification) is converted to the claimed message formats.
Cronin shows detecting a pothole or other roadway damage, then outputting the identified pothole information in the format desired by the user. However, Cronin does not teach that the message is generated from a portion of the claimed “roadway issue data.”
Ricci shows a system for a vehicle communicating a vehicle’s profile with third parties. This profile includes safety information of road hazards detected by sensors, including GPS coordinates, and categorized by the vehicle. The vehicle then forwards a message of the safety information to a third party. The message could be a text message or e-mail. However, Ricci does not teach the use of a remote server that receives the issue data, and converts a portion of that data to an email, text, or voicemail message for a request for repair
Groeneweg shows that mobile sources can provide data that indicates a roadway issue, which after being analyzed by the remote server, can result in the issuing of an alert. Groeneweg shows that alerts can be in the form of email, text message, or voice alert via telephone or cell phone. However, Groeneweg does not does not teach the use of a remote server that receives the issue data (including classification), and converts a portion of that data to an email, text, or voicemail message for a request for repair.
Abraham shows identification of a road problem based on sensors, determination of the resources required to repair the road problem (e.g. three laborers, one traffic control person, pavement grinder, plastic orange cones, and four hours), optimize a road repair plan, and then issue an alert in the form of text message or email. However, the “alert” in Abraham is to notify the public of the hazard, not a request to the entity responsible.
Garg shows the detection of a road issue with sensors of a vehicle and the transmission of that data to a server. The server identifies an entity to receives instructions based on classification and a recipients database, and then determines the repair instructions to be sent to the entity’s device from a database of actions. However, Garg does not discuss the details of the form of the generated repair instruction message.
Kyomitsu shows detecting a roadway issue from sensors on vehicles, then providing a notification of that issue. However, Kyomitsu does not teach a repair request generated by converting the reported road issue data into a certain format.
Choi shows detecting and classifying road condition, converting the road data, and then having the road repaired. However, Choi does not teach a repair request generated by converting the reported road issue data into a certain format.
Generally, the closest prior art teaches (1) detecting roadway issues (Selbie, Bharti, Pasquali, Akselrod, Kimura, Wilson, Baca, Schlesinger, Bai, Dahlgren, Cronin, Ricci, Groeneweg, Abraham, Garg, Kyomitsu, and Choi), communicating with the authority responsible (Kimura, Bharti, Akselrod, Wilson, Baca, Bai, Dahlgren, Roth, Moses, Dange, and Garg), (3) using messages in a certain format without the specific claimed application (Pasquali, Akselrod, Roth, Moses, Dange, Cronin, Ricci, Groeneweg, and Abraham), and (4) broadly discuss roads and issues without specific computer system architecture (Rabe and CAPE).
With respect to independent Claims 1 and 14-15, the closest prior art, taken individually and in an ordered combination, does not explicitly or implicitly disclose the specific ordered combination of elements that include the limitation of representative Claim 1 of “generate and transmit a repair request including at least a portion of the roadway issue data [that is generated and transmitted by the first controller, e.g. vehicle, and includes classification and location data associated with the issue] to the roadway related entity by converting the portion of the roadway issue data into at least one of a voicemail message, a text message, and an email message.” Although the prior art of record teaches receiving roadway issue data and notifying the responsible entity, as discussed above, the prior art does not teach converting a portion of the received roadway issue data into a voicemail, text, or email, which is included in the repair request, as claimed by Applicant. Independent Claims 14-15 recite a similar limitation. Therefore, independent Claims 1 and 14-15 are held to be novel and nonobvious.
Dependent Claims 2-13 depend on Claim 1, and Dependent Claims 17-20 depends on Claim 15, and therefore are also not rejected via dependency.
Conclusion
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.
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure and is as follows:
“data conversion” (“GIS Dictionary” 09/29/2023, https://web.archive.org/web/20230929143355/https://support.esri.com/en-us/gis-dictionary/data-conversion) defines “data conversion” as “The process of translating data from one format to another.”
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MATTHEW PARKER GOODMAN whose telephone number is (571) 272-5698. The examiner can normally be reached on Monday-Thursday from 9:30 AM ET to 6:00 PM ET. If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Jeffrey Zimmerman, can be reached at telephone number (571) 272-4602. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://portal.uspto.gov/external/portal. Should you have questions about access to the Private PAIR
system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free).
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
/MATTHEW PARKER GOODMAN/Examiner, Art Unit 3628
/JEFF ZIMMERMAN/Supervisory Patent Examiner, Art Unit 3628
Prosecution Insights