Prosecution Insights
Last updated: April 19, 2026
Application No. 19/286,616

GENERATING CONSOLIDATED GRAPHICAL USER INTERFACES FOR DISPLAYING DIRECTIVES OF DEVICES OF A DYNAMIC TRANSPORTATION NETWORK

Non-Final OA §101§103§112
Filed
Jul 31, 2025
Examiner
CHONG CRUZ, NADJA N
Art Unit
3623
Tech Center
3600 — Transportation & Electronic Commerce
Assignee
Lyft Inc.
OA Round
1 (Non-Final)
28%
Grant Probability
At Risk
1-2
OA Rounds
4y 2m
To Grant
71%
With Interview

Examiner Intelligence

Grants only 28% of cases
28%
Career Allow Rate
104 granted / 370 resolved
-23.9% vs TC avg
Strong +43% interview lift
Without
With
+43.3%
Interview Lift
resolved cases with interview
Typical timeline
4y 2m
Avg Prosecution
23 currently pending
Career history
393
Total Applications
across all art units

Statute-Specific Performance

§101
32.1%
-7.9% vs TC avg
§103
34.3%
-5.7% vs TC avg
§102
7.3%
-32.7% vs TC avg
§112
21.3%
-18.7% vs TC avg
Black line = Tech Center average estimate • Based on career data from 370 resolved cases

Office Action

§101 §103 §112
DETAILED ACTION Status of Claims This is a non-final action in reply to the application filed on July 31, 2025. Claims 1-20 are currently pending and have been examined. 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 . Information Disclosure Statement The Information Disclosure Statements filed on 8/7/2025 has been considered. Initialed copies of the Form 1449 are enclosed herewith. 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-20 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. As per claim 1 recites “based on determining a measure of relevance between the contextual data and the performance data”. Examiner is not clear how to measure a relevance between the contextual data and the performance data. How relevant is the contextual data for the performance data? Applicant’s disclosure describe in paragraphs 0015, 0019, 0020, 0021, 0044. 0056 and 0064 “that the performance data is relevant to the context” but does not describe any measurement of how much relevant the context is for the performance data. Applicant disclosure does not describe how a measure of relevance between the contextual data and the performance data is determined. The same rationales applies to claims 11 and 16. Appropriate correction is required. As per claim 1 recites “collecting, by one or more server devices, performance data associated with a performance of a provider computing device within a dynamic transportation network; generating, utilizing the one or more server devices, a provider computing device rating based on the performance data” Examiner is not clear, is the performance data from the performance of a provider computing device? is the computing device of the provider doing the performance or is the provider i.e., driver? The same rationale applies to the generation of rating, is the rating for the provider i.e., driver or the provider computing device? The same rationales applies to claims 11 and 16. Appropriate correction is required. Examiner interpreted the claims as the performance and rating of a provider i.e., driver. 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, a natural phenomenon, or an abstract idea) without significantly more. Per MPEP 2106.03 Eligibility Step 1: The Four Categories of Statutory Subject Matter [R-07.2022]. Step 1 is directed to determining whether or not the claims fall within a statutory class. Herein, claims 1-10 falls within statutory class of a process, claims 11-15 falls within statutory class of a machine and claims 16-20 falls within statutory class of an article of manufacturing. Hence, the claims qualify as potentially eligible subject matter under 35 U.S.C §101. With Step 1 being directed to a statutory category, per MPEP 2106.04 Eligibility Step 2A: Whether a Claim is Directed to a Judicial Exception [R-07.2022]. Step 2 is the two-part analysis from Alice Corp. (also called the Mayo test). The 2019 PEG makes two changes in Step 2A: It sets forth new procedure for Step 2A (called “revised Step 2A”) under which a claim is not “directed to” a judicial exception unless the claim satisfies a two-prong inquiry. The two-prong inquiry is as follows: Prong One: evaluate whether the claim recites a judicial exception. If claim recites an exception, then Prong Two: evaluate whether the claim recites additional elements that integrate the exception into a practical application of the exception. The claim(s) recite(s) the following abstract idea indicated by non-boldface font and additional limitations indicated by boldface font: Claim 1: collecting, by one or more server devices, performance data associated with a performance of a provider computing device within a dynamic transportation network; generating, utilizing the one or more server devices, a provider computing device rating based on the performance data; monitoring, via the one or more server devices from the provider computing device or a requester computing device, contextual data indicating a context of a digital service request received from the requester computing device; providing, for display within a user interface of the provider computing device, a status message based on the provider computing device rating; and based on determining a measure of relevance between the contextual data and the performance data, providing, for display within the user interface of the provider computing device simultaneously with the status message, a notification message comprising a modification directive corresponding to the performance data. Claim 11: at least one processor; and a non-transitory computer readable storage medium comprising instructions that, when executed by the at least one processor, cause the system to: collect, by one or more server devices, performance data associated with a performance of a provider computing device within a dynamic transportation network; generate, utilizing the one or more server devices, a provider computing device rating based on the performance data; monitor, via the one or more server devices from the provider computing device or a requester computing device, contextual data indicating a context of a digital service request received from the requester computing device; provide, for display within a user interface of the provider computing device, a status message based on the provider computing device rating; and based on determining a measure of relevance between the contextual data and the performance data, provide, for display within the user interface of the provider computing device simultaneously with the status message, a notification message comprising a modification directive corresponding to the performance data. Claim 16: collect, by one or more server devices, performance data associated with a performance of a provider computing device within a dynamic transportation network; generate, utilizing the one or more server devices, a provider computing device rating based on the performance data; monitor, via the one or more server devices from the provider computing device or a requester computing device, contextual data indicating a context of a digital service request received from the requester computing device; provide, for display within a user interface of the provider computing device, a status message based on the provider computing device rating; and based on determining a measure of relevance between the contextual data and the performance data, provide, for display within the user interface of the provider computing device simultaneously with the status message, a notification message comprising a modification directive corresponding to the performance data. Per Prong One of Step 2A, the identified recitation of an abstract idea falls within at least one of the Abstract Idea Groupings consisting of: Mathematical Concepts, Mental Processes, or Certain Methods of Organizing Human Activity. Particularly, the identified recitation falls within Mental Processes: concepts performed in the human mind including an observation, evaluation, judgment and opinion, and Certain Methods of Organizing Human Activity such as managing personal behavior or relationships or interaction between people including social activities, teaching and following rules or instructions. Per Prong Two of Step 2A, this judicial exception is not integrated into a practical application because the claim as a whole does not integrate the identified abstract idea into a practical application. The processor, non-transitory computer-readable storage medium, one or more server devices, the provider and requester computing devices is recited at a high level of generality, i.e., as a generic computing and processing system. This processor, non-transitory computer-readable storage medium, one or more server devices, the provider and requester computing devices is no more than mere instructions to apply the exception using a generic computing devices each comprising at least a processor, memory and display device. Further, processor configured to cause receiving/determining/transmitting data is mere instruction to apply an exception using a generic computer component which cannot integrate a judicial exception into a practical application. Accordingly, this/these additional element(s) does/do not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea. Thus, since the claims are directed to the determined judicial exception in view of the two prongs of Step 2A, MPEP 2106.05 Eligibility Step 2B: Whether a Claim Amounts to Significantly More [R-07.2022] is directed to Step 2B. Therein, per Step 2B the additional elements and combinations therewith are examined in the claims to determine whether the claims as a whole amounts to significantly more than the judicial exception. It is noted here that the additional elements are to be considered both individually and as an ordered combination. In this case, the claims each at most comprise additional elements of processor, non-transitory computer-readable storage medium, one or more server devices, the provider and requester computing devices. Taken individually, the additional limitations each are generically recited and thus does not add significantly more to the respective limitations. Further, executing all the steps/functions by a user/service subsystem is mere instruction to apply an exception using a generic computer component which cannot provide an inventive concept in Step 2B (or, looking back to Step 2A, cannot integrate a judicial exception into a practical application). For further support, the Applicant’s specification supports the claims being directed to use of a generic processor, non-transitory computer-readable storage medium, one or more server devices, the provider and requester computing devices type structure at ¶ 0026: “ transportation provider device 280 (e.g., a smartphone); ¶ 0035: “transportation requestor device 260 (e.g., a smartphone); ¶ 0065: “The transportation management system may be implemented on various platforms, including a requestor-owned mobile device, a computing system installed in a vehicle, a requestor-owned mobile device, a server computer system, or any other hardware platform capable of providing transportation matching services to one or more requestors and/or providers.” ¶ 0066 “transportation management system 1002 may include one or more general purpose computers, server computers, clustered computing systems, cloudbased computing systems, and/or any other computing systems or arrangements of computing systems. Transportation management system 1002 may be configured to run any or all of the services and/or software components described herein. In some embodiments, the transportation management system 1002 may include an appropriate operating system and/or various server applications, such as web servers capable of handling hypertext transport protocol (HTTP) requests, file transfer protocol (FTP) servers, database servers, etc.”; ¶ 0078-0079: “the term “memory device” generally refers to any type or form of volatile or non-volatile storage device or medium capable of storing data and/or computer-readable instructions. In one example, a memory device may store, load, and/or maintain one or more of the modules described herein. Examples of memory devices include, without limitation, Random Access Memory (RAM), Read Only Memory (ROM), flash memory, Hard Disk Drives (HDDs), Solid-State Drives (SSDs), optical disk drives, caches, variations or combinations of one or more of the same, or any other suitable storage memory. […] the term “physical processor” generally refers to any type or form of hardware-implemented processing unit capable of interpreting and/or executing computer-readable instructions. In one example, a physical processor may access and/or modify one or more modules stored in the above-described memory device. Examples of physical processors include, without limitation, microprocessors, microcontrollers, Central Processing Units (CPUs), Field-Programmable Gate Arrays (FPGAs) that implement softcore processors, Application-Specific Integrated Circuits (ASICs), portions of one or more of the same, variations or combinations of one or more of the same, or any other suitable physical processor.” See also figure 1. Taken as an ordered combination, the claim(s) does/do not include additional elements that are sufficient to amount to significantly more than the judicial exception because the limitations are directed to limitations referenced in Alice Corp. that are not enough to qualify as significantly more when recited in a claim with an abstract idea include, as a non-limiting or non-exclusive examples: i. Adding the words "apply it" (or an equivalent) with the judicial exception, or mere instructions to implement an abstract idea on a computer, e.g., a limitation indicating that a particular function such as creating and maintaining electronic records is performed by a computer, as discussed in Alice Corp., 134 S. Ct. at 2360, 110 USPQ2d at 1984 (see MPEP § 2106.05(f)); ii. Simply appending well-understood, routine, conventional activities previously known to the industry, specified at a high level of generality, to the judicial exception, e.g., a claim to an abstract idea requiring no more than a generic computer to perform generic computer functions that are well-understood, routine and conventional activities previously known to the industry, as discussed in Alice Corp., 134 S. Ct. at 2359-60, 110 USPQ2d at 1984 (see MPEP § 2106.05(d)); iii. Adding insignificant extra-solution activity to the judicial exception, e.g., mere data gathering in conjunction with a law of nature or abstract idea such as a step of obtaining information about credit card transactions so that the information can be analyzed by an abstract mental process, as discussed in CyberSource v. Retail Decisions, Inc., 654 F.3d 1366, 1375, 99 USPQ2d 1690, 1694 (Fed. Cir. 2011) (see MPEP § 2106.05(g)); or v. Generally linking the use of the judicial exception to a particular technological environment or field of use, e.g., a claim describing how the abstract idea of hedging could be used in the commodities and energy markets, as discussed in Bilski v. Kappos, 561 U.S. 593, 595, 95 USPQ2d 1001, 1010 (2010) or a claim limiting the use of a mathematical formula to the petrochemical and oil-refining fields, as discussed in Parker v. Flook. The courts have recognized the following computer functions inter alia to be well-understood, routine, and conventional functions when they are claimed in a merely generic manner: performing repetitive calculations; receiving, processing, and storing data (e.g., the present claims); electronically scanning or extracting data; electronic recordkeeping; automating mental tasks (e.g., process/machine for performing the present claims); and receiving or transmitting data (e.g., the present claims). The dependent claims 2-10, 12-15 and 17-20 do not cure the above stated deficiencies, and in particular, the dependent claims further narrow the abstract idea without reciting additional elements that integrate the exception into a practical application of the exception or providing significantly more than the abstract idea. Claims 2 and 12 further limit the abstract idea by providing, for display via user interfaces of requester computing devices matched to the provider computing device, a plurality of digital compliment elements; monitoring, via the one or more server devices, interactions with digital compliment elements at the requester computing devices matched to the provider computing device; and providing, for display on the user interface of the provider computing device simultaneously with the status message and the notification message, a digital compliments counter element based on the interactions with the digital compliment elements at the requester computing devices matched to the provider computing device (a more detailed abstract idea remains an abstract idea). Claims 3 and 13 further limit the abstract idea that collecting the performance data associated with the performance of the provider computing device includes collecting data from at least one of a requester computing device associated with the digital service request, sensor data from a vehicle of the provider computing device, or a data server (a more detailed abstract idea remains an abstract idea). Claims 4 and 14 further limit the abstract idea that monitoring the contextual data includes monitoring at least one of a type of digital service request, a pickup location of the digital service request, a drop-off location of the digital service request, a digital service request history of the provider computing device, or a preference of the requester computing device. (a more detailed abstract idea remains an abstract idea). Claims 5 and 15 further limit the abstract idea that providing the status message further comprises: determining a provider tier based on the provider computing device rating; providing, for display within the user interface of the provider computing device, a summary text corresponding to the provider tier; and providing the provider computing device rating for display within the user interface of the provider computing device simultaneously with the summary text, the status message, and the notification message (a more detailed abstract idea remains an abstract idea). Claims 6 and 17 further limit the abstract idea that by prioritizing a plurality of notification messages; and displaying the plurality of notification messages in the user interface of the provider computing device in a consolidated view (a more detailed abstract idea remains an abstract idea). Claim 7 further limit the abstract idea by monitoring, via the one or more server devices, interactions with requester computing devices matched to the provider computing device to determine instances of feedback (a more detailed abstract idea remains an abstract idea). Claim 8 further limit the abstract idea by providing, for display within the user interface of the provider computing device simultaneously with the status message and the notification message, a feedback feed comprising the instances of feedback from the requester computing devices matched to the provider computing device (a more detailed abstract idea remains an abstract idea). Claims 9 and 19 further limit the abstract idea by providing, for display via a user interface of the requester computing device, one or more selectable binary interactive elements; and receiving a selection of a selectable binary interactive element of the one or more selectable binary interactive elements (a more detailed abstract idea remains an abstract idea). Claims 10 and 20 further limit the abstract idea that based on receiving the selection of the selectable binary interactive element, generating a feedback message; and providing, for display on a user interface of the provider computing device, the feedback message simultaneously with the status message and the notification message (a more detailed abstract idea remains an abstract idea). And claim 18 further limit the abstract idea to monitor, via the one or more server devices, interactions with requester devices matched to the provider computing device to determine instances of feedback; and provide, for display within the user interface of the provider computing device simultaneously with the status message and the notification message, a feedback feed comprising the instances of feedback from the requester devices matched to the provider computing device (a more detailed abstract idea remains an abstract idea). The identified recitation of the dependents claims falls within the Mental Processes: concepts performed in the human mind including an observation, evaluation, judgment and opinion, and Certain Methods of Organizing Human Activity such as managing personal behavior or relationships or interaction between people including social activities, teaching and following rules or instructions. Since there are no elements or ordered combination of elements that amount to significantly more than the judicial exception, the claims are not eligible subject matter under 35 USC §101. Thus, viewed as a whole, these additional claim element(s) do not provide meaningful limitation(s) to transform the abstract idea into a patent eligible application of the abstract idea such that the claim(s) amounts to significantly more than the abstract idea itself. Therefore, the claim(s) are rejected under 35 U.S.C. 101 as being directed to non-statutory subject matter. Claim Rejections - 35 USC § 103 In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status. 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. Claims 1, 3-4, 7, 9, 11, 13-14, 16 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Radhakrishnan et al., (US 2013/0246301 A1), hereinafter “Radhakrishnan” in view of Cohen et al., (US 2019/0287040 A1) hereinafter “Cohen”. Claim 1: Radhakrishnan as shown discloses a computer-implemented method, the method comprising: collecting, by one or more servers, (¶ 0046: “a transport service (e.g. service 120 of (FIG. 1) is implemented on server (or servers) 300 to arrange transport for customers by pairing drivers to customers.”) performance data associated with a performance of a provider computing device within a dynamic transportation network (¶ 0065-0066: “The rating interface 384 may include an overall rating feature in order to record feedback 385. The overall rating feature may correspond to the user's evaluation of the ride. For example, the overall rating feature may correspond to a number or quantitative evaluation which describes the user's overall experience with the transportation service. The overall rating feature may be used to generate a driver rating update 387. Other forms of feedback may also be collected in addition to, for example, overall ratings. For example, the transport service may prompt the customer to answer a series of yes or no questions as a means of evaluating the performance of a particular driver. The questions may ask, for example, whether the driver was courteous, whether the driver opened the door or assisted the customer in entering the vehicle, the manner in which the driver drove the vehicle, and the driver's response time. The user's questionnaire feedback may be recorded for the particular driver and/or the company or operator that provided the driver.” See also Figure 3, reference character 310, “Customer Device Interface” and reference characters 384 “Rating Interface” and 385 “Cust-Driver Rating”); generating, utilizing the one or more server devices, a provider computing device rating based on the performance data (¶ 0066: “Other forms of feedback may also be collected in addition to, for example, overall ratings. For example, the transport service may prompt the customer to answer a series of yes or no questions as a means of evaluating the performance of a particular driver. The questions may ask, for example, whether the driver was courteous, whether the driver opened the door or assisted the customer in entering the vehicle, the manner in which the driver drove the vehicle, and the driver's response time. The user's questionnaire feedback may be recorded for the particular driver and/or the company or operator that provided the driver.” See also ¶ 0064: “The user can select features on the rating interface 384 so that the user can provide feedback about the rendered service or the service provider (e.g., the driver for a transport service) to the transport service.”); monitoring, via the one or more server devices from the provider computing device or a requester computing device, contextual data indicating a context of a digital service request received from the requester computing device (Figure 3, note the Customer Rating Interface 384 and the Profile/Transaction Log Store 350, where Driver Rating Update 387 is stored. Data is received and transmitted to Dispatch 320. ¶ 0063: “a rating interface 384, 388 may be provided for each of the customer and the driver. The rating interface 384 of the customer enables the customer to record feedback 385 about a driver, or more generally, about the transport party (e.g. driver or the taxi or limousine company that provided the transport). […] The rating information of each participant may be recorded as part of that user's profile information, and thus stored in the profile store 350. Thus, each feedback results in a respective driver rating update 387 (provided by the customer) or customer rating update 391 (provided from the driver).” ¶ 0065: “The rating interface 384 may include an overall rating feature in order to record feedback 385. The overall rating feature may correspond to the user's evaluation of the ride.” ¶ 0072: “From the recorded information, various kinds of analysis can be performed. An analysis component 390 may analyze information from the log 394 to identify information for users (customers and drivers) of the transport service, as well as to direct users who may research based on information recorded by the transport service.” And ¶ 0088: “The transport service may evaluate the quality and kind of the transport that the customer received from the driver. The evaluation may be based on criteria such as (i) the response time of the driver to arrive at the pickup location, (ii) the transport time, (iii) whether the driver elected the fastest or best route to the drop-off location. Other considerations include whether amenities were provided to the customer (or whether the customer actual used the amenities), as well as feedback by the customer as to specifics of the transport (e.g. the driver was courteous, opened the door, the car was clean, the driver obeyed driving laws etc.).”); providing for display within a user interface of the provider computing device, a status message based on the provider computing device rating; and (Figure 8E, note the status message “Oscar (3.0 stars)” and “Oscar Salazar” (3.8 stars) which reflect the performance data i.e., a status message based on the provider computing device rating); Radhakrishnan teaches in Figure 9A and ¶ 0116: “the user may be enabled to provide qualitative comments in response to the user selection. For example, in the embodiment of FIG. 9A, in response to the quantitative user rating 915 being at five stars, a text box 940 is provided into which a user may input text. The qualitative comments may be integrated into the use of the selectable features 920. For example, the qualitative comments may be incorporated into a pre-generated message as described above to be sent using the network or communication function, and the qualitative comments may then be sent to a provider of the transportation service. The user may then select a confirmation button 950 (“Submit”) to cause the qualitative comments to be transmitted, such as to a service provider for the transportation service” see also Figure 9B and ¶ 0118-0120: “FIG. 9B, a user has selected three stars as the quantitative user rating 915. In response to the user having provided a quantitative user rating 915, a set of selectable category features 930 are displayed as part of the rating user interface. Each of the selectable features of the set of selectable category features 930 indicates a category or relevant aspect of a transportation service provided by a service provider. in order to display the status summary message on the transportation provider device Fig. 8E and the performance data of the transportation provider in ¶ 0062: “each participant (customer and driver) can provide feedback that includes a rating or other quantative metric. Additionally, a user can provide qualitative statements, such as sentences or paragraph-formed commentary about his experience with the driver.” Radhakrishnan is silent with regard to the following limitations. However Cohen in an analogous art of feedback/performance management for the purpose of providing the following limitations as shown does: based on determining a measure of relevance between the contextual data and the performance data, providing for display within the user interface of the provider computing device simultaneously with the status message, a notification message comprising a modification directive corresponding to the performance data (Figures 7 and 8, figure 7 illustrates ¶ 0065 “a developer scorecard 700, for a developer named David, for a metric named expertise, and recommendation generated for the developer David, […] The upper part may represent the performance scoring related to the expertise metric, and each row may represent the performance scoring related to each measurement being included in the expertise metric. The lower part may represent the recommendation generated by the recommendation generator 130.” And ¶ 0066 “FIG. 8 illustrates one embodiment of a developer scorecard 800, for a developer named Barbara, for a metric named productivity, and recommendation generated for the developer Barbara, […]. The upper part may represent the performance scoring related to the productivity metric, each row may represent the performance scoring related to each measurement being included in the productivity metric. The lower part may represent the recommendation generated by the recommendation generator 130.” Cohen teaches simultaneously displaying the status message and notification messages comprising a modification directive i.e., improvement corresponding to the performance data); Both Radhakrishnan and Cohen teach feedback/performance management. Radhakrishnan teaches in the Abstract: “providing feedback for a transportation service.” And ¶ 0066: “evaluating the performance of a particular driver”. Cohen teaches in the Abstract: “generating a performance rating.” Thus, they are deemed to be analogous references as they are reasonably pertinent to each other and are directed towards solving similar problems within the same environment. One of ordinary skill in the art would have recognized that applying the known technique of Cohen would have yielded predictable results and resulted in an improved system. It would have been recognized that applying the technique of Cohen to the teaching of Radhakrishnan would have yielded predictable results because the level of ordinary skill in the art demonstrated by the references applied shows the ability to incorporate such as based on determining a measure of relevance between the contextual data and the performance data, providing for display within the user interface of the provider computing device simultaneously with the status message, a notification message comprising a modification directive corresponding to the performance data into similar systems. Further, as noted by Cohen “The closer an employee is to a target, the more motivated he or she will be to achieve the target. In addition, employees who are far above or below a target should be provided with an incentive to continue improving because the organization will benefit from their efforts.” (Cohen, ¶ 0005). Claims 11 and 16: The limitations of claims 11 and 26 encompass substantially the same scope as claim 1. Accordingly, those similar limitations are rejected in substantially the same manner as claim 1, as described above. The following limitations differs from claim 1: Claim 11: Radhakrishnan as shown discloses a system, the system comprising: at least one processor; and at least one non-transitory computer readable storage medium storing instructions that, when executed by the at least one processor (¶ 0025: “the numerous machines shown with embodiments of the invention include processor(s) and various forms of memory for holding data and instructions.”); Claim 16: Radhakrishnan as shown discloses a system, the system comprising: a non-transitory computer readable storage medium comprising instructions that, when executed by the at least one processor (¶ 0025: “the numerous machines shown with embodiments of the invention include processor(s) and various forms of memory for holding data and instructions.”); Claim 3: Radhakrishnan as shown discloses the following limitations: wherein collecting the performance data associated with the performance of the provider computing device includes collecting data from at least one of a requester computing device associated with the digital service request, sensor data from a vehicle of the provider computing device, or a data server (Figures 9A and 9B, see also figure 2, note the Accelerometer); Claim 13: The limitations of claim 13 encompasses substantially the same scope as claim 3. Accordingly, those similar limitations are rejected in substantially the same manner as claim 3, as described above. Claim 4: Radhakrishnan as shown discloses the following limitations: wherein monitoring the contextual data includes monitoring at least one of a type of digital service request, a pickup location of the digital service request, a drop-off location of the digital service request, a digital service request history of the provider computing device, or a preference of the requester computing device (Figure 7A describes the type of digital service request and a pick up location, see also ¶ 0100: “ instances of customer pickups and drop-offs may be recorded, including recording the pickup locations (610) and drop-offs (620). The information may be recorded in the log 394. In some embodiments, the information may be recorded in real-time, although the information may be stored for use as historical data.”); Claim 14: The limitations of claim 14 encompasses substantially the same scope as claim 4. Accordingly, those similar limitations are rejected in substantially the same manner as claim 4, as described above. Claim 7: Radhakrishnan as shown discloses the following limitations: further comprising monitoring, via the one or more server devices, interactions with requester computing devices matched to the provider computing devices to determine instances of feedback (Figure 3, note the Customer Rating Interface 384 and the Profile/Transaction Log Store 350, where Driver Rating Update 387 is stored. Data is received and transmitted to Dispatch 320. ¶ 0063: “a rating interface 384, 388 may be provided for each of the customer and the driver. The rating interface 384 of the customer enables the customer to record feedback 385 about a driver, or more generally, about the transport party (e.g. driver or the taxi or limousine company that provided the transport). […] The rating information of each participant may be recorded as part of that user's profile information, and thus stored in the profile store 350. Thus, each feedback results in a respective driver rating update 387 (provided by the customer) or customer rating update 391 (provided from the driver).” See also figures 8A- 8E and 9A-9B); Claim 9: Radhakrishnan as shown discloses the following limitations: further comprising collecting the performance data by: providing, for display via a user interface of the requester computing device, one or more selectable binary interactive elements; and receiving a selection of selectable binary interactive element of the one or more selectable binary interactive elements (¶ 0066: “the transport service may prompt the customer to answer a series of yes or no questions as a means of evaluating the performance of a particular driver. The questions may ask, for example, whether the driver was courteous, whether the driver opened the door or assisted the customer in entering the vehicle, the manner in which the driver drove the vehicle, and the driver's response time. The user's questionnaire feedback may be recorded for the particular driver and/or the company or operator that provided the driver.”); Claim 19: The limitations of claim 19 encompasses substantially the same scope as claim 9. Accordingly, those similar limitations are rejected in substantially the same manner as claim 9, as described above. Claims 2 and 12 are rejected under 35 U.S.C. 103 as being unpatentable over Radhakrishnan et al., (US 2013/0246301 A1), hereinafter “Radhakrishnan” and Cohen et al., (US 2019/0287040 A1) hereinafter “Cohen” as applied to claims 1 and 11 above further in view of Rachel Youngblade, Compliments: They’re free. Give them! https://blog.yelp.com/news/compliments-theyre-free-give-them/ March 1, 2013. Claim 2: Radhakrishnan as shown discloses the following limitations: providing, for display via user interfaces of requester computing device matched to the provider computing device, [a plurality of digital compliment elements] (¶ 0118: “FIG. 9B illustrates another rating user interface that is displayed to a user for providing feedback about a service. In FIG. 9B, an overall user rating 910 is provided to a customer for providing a quantitative user rating 915 (e.g., similar to that of the rating user interface in the example described in FIG. 9A). In the example of FIG. 9B, a user has selected three stars as the quantitative user rating 915. In response to the user having provided a quantitative user rating 915, a set of selectable category features 930 are displayed as part of the rating user interface. Each of the selectable features of the set of selectable category features 930 indicates a category or relevant aspect of a transportation service provided by a service provider.” Figure 4 illustrates when a requester computing device is matched to the provider computing device) monitoring, via the one or more server devices, interactions with [digital compliment elements] at the requester computing devices matched to the provider computing device; (¶ 0116: “The user may then select a confirmation button 950 (“Submit”) to cause the qualitative comments to be transmitted, such as to a service provider for the transportation service.” See also figures 9A and 9B); Radhakrishnan as explained above teaches an interface of the requester computing device to input rating/feedback and the results are displayed in the provider computing device. Cohen as explained above display simultaneously the status message and the notification message as shown in figures 7 and 8. Radhakrishnan in view of Cohen is silent with regard to the plurality of digital elements and the digital compliments counter element. However Youngblade in an analogous art of feedback/rating management for the purpose of providing the following limitations as shown does: a plurality of digital compliments elements (page 2, note the “Choose Your Compliment Type” box see also page 3, the plurality of digital compliments elements such as “Useful”, “Funny” and “Cool”); and providing, for display on the user interface of the provider computing device simultaneously with the status message and the notification message, a digital compliments counter element based on the interactions with the digital compliment elements at the requester computing devices matched to the provider computing device (page 2, note the digital compliments counter element for Useful (5), Funny (1) and Cool (4). See also page 2, note the 249 compliments in the user profile); Both Radhakrishnan and Youngblade teach feedback/rating management. Radhakrishnan teaches in the Abstract: “providing feedback for a transportation service.” Youngblade teaches in page 1: “We find that many Yelpers are the same: they love when their peers take a quick second to give them heartfelt kudos for a well-written review, a can’t-believe-it’s-not-pro photo or a saucy looking profile pic.” Thus, they are deemed to be analogous references as they are reasonably pertinent to each other and are directed towards solving similar problems within the same environment. One of ordinary skill in the art would have recognized that applying the known technique of Youngblade would have yielded predictable results and resulted in an improved system. It would have been recognized that applying the technique of Youngblade to the teaching of Radhakrishnan in view of Cohen would have yielded predictable results because the level of ordinary skill in the art demonstrated by the references applied shows the ability to incorporate such as a plurality of digital compliments elements and providing, for display on the user interface of the provider computing device simultaneously with the status message and the notification message, a digital compliments counter element based on the interactions with the digital compliment elements at the requester computing devices matched to the provider computing device into similar systems. Further, as noted by Youngblade “we invite you to take a few seconds to make someone’s day a little brighter with a compliment on Yelp.” (Youngblade page 2). Claim 15: The limitations of claim 15 encompasses substantially the same scope as claim 2. Accordingly, those similar limitations are rejected in substantially the same manner as claim 2, as described above. Claims 5, 8, 10, 15, 18 and 20 are rejected under 35 U.S.C. 103(a) as being unpatentable over Radhakrishnan et al., (US 2013/0246301 A1), hereinafter “Radhakrishnan” and Cohen et al., (US 2019/0287040 A1) hereinafter “Cohen”, as applied to claims 7 and 16, further in view of Kim et al., (US 2020/0265365 A1), hereinafter “Kim”. Claim 5: Radhakrishnan in view of Cohen as explained above teaches the displaying of the status message. Radhakrishnan teaches in ¶ 0067: “the invite 314 may first be sent to proximate drivers with highest ratings, then proximate drivers with middle tier ratings. Radhakrishnan in view of Cohen is silent with regard to the following limitations. However Kim in an analogous art of feedback/comment management for the purpose of providing the following limitations as shown does: wherein providing the status message further comprises: determining a provider tier based on the provider computing device rating; providing, for display within the user interface of the provider computer device, a summary text corresponding to the provider tier; (Figure 8, note the provider tier 1, 2, 3 and 4 with a summary text i.e., Below, Meets, Exceeds, Far Exceeds, corresponding to the provider tier); Both Radhakrishnan and Kim teach feedback/comment management. Radhakrishnan teaches in the Abstract: “providing feedback for a transportation service.” Kim teaches in the Abstract: “involve a feedback application, a feedback processing application, an analytics application, and an event moderating application.” Thus, they are deemed to be analogous references as they are reasonably pertinent to each other and are directed towards solving similar problems within the same environment. One of ordinary skill in the art would have recognized that applying the known technique of Kim would have yielded predictable results and resulted in an improved system. It would have been recognized that applying the technique of Kim to the teaching of Radhakrishnan in view of Cohen would have yielded predictable results because the level of ordinary skill in the art demonstrated by the references applied shows the ability to incorporate such as providing the status message further comprises: determining a provider tier based on the provider computing device rating; providing, for display within the user interface of the provider computer device, a summary text corresponding to the provider tier into similar systems. Further, as noted by Kim “The analytics application examines user's feedback giving and receiving behavior and evaluate their feedback empathy and authenticity and their learning behavior.” (Kim, Abstract). Radhakrishnan teaches in Figure 8E, note the status summary message “Oscar (3.0 stars)” and “Oscar Salazar” (3.8 stars) which reflect the rating of the provider computing device. Kim teaches in Figure Radhakrishnan is silent with regard to the following limitations. However Cohen in an analogous art of feedback/performance management for the purpose of providing the following limitations as shown does: and providing the provider computing device rating for display within the user interface of the provider computing device simultaneously with the summary text, the status message, and the notification message (Figures 7 and 8, figure 7 illustrates ¶ 0065 “a developer scorecard 700, for a developer named David, for a metric named expertise, and recommendation generated for the developer David, […] The upper part may represent the performance scoring related to the expertise metric, and each row may represent the performance scoring related to each measurement being included in the expertise metric. The lower part may represent the recommendation generated by the recommendation generator 130.” And ¶ 0066 “FIG. 8 illustrates one embodiment of a developer scorecard 800, for a developer named Barbara, for a metric named productivity, and recommendation generated for the developer Barbara, […]. The upper part may represent the performance scoring related to the productivity metric, each row may represent the performance scoring related to each measurement being included in the productivity metric. The lower part may represent the recommendation generated by the recommendation generator 130.” Cohen teaches simultaneously displaying the summary text note “High Index”, the status message and notification messages); Both Radhakrishnan and Cohen teach feedback/performance management. Radhakrishnan teaches in the Abstract: “providing feedback for a transportation service.” And ¶ 0066: “evaluating the performance of a particular driver”. Cohen teaches in the Abstract: “generating a performance rating.” Thus, they are deemed to be analogous references as they are reasonably pertinent to each other and are directed towards solving similar problems within the same environment. One of ordinary skill in the art would have recognized that applying the known technique of Cohen would have yielded predictable results and resulted in an improved system. It would have been recognized that applying the technique of Cohen to the teaching of Radhakrishnan would have yielded predictable results because the level of ordinary skill in the art demonstrated by the references applied shows the ability to incorporate such as providing the provider computing device rating for display within the user interface of the provider computing device simultaneously with the summary text, the status message, and the notification message into similar systems. Further, as noted by Cohen “The closer an employee is to a target, the more motivated he or she will be to achieve the target. In addition, employees who are far above or below a target should be provided with an incentive to continue improving because the organization will benefit from their efforts.” (Cohen, ¶ 0005). Claim 15: The limitations of claim 15 encompasses substantially the same scope as claim 5. Accordingly, those similar limitations are rejected in substantially the same manner as claim 5, as described above. Claim 8: Radhakrishnan as explained above collect feedback messages (Figures 9A-9B) from the requester computing device matched to the provider computing device. Radhakrishnan in view of Cohen as explained above display simultaneously the status message and the notification message. Radhakrishnan in view of Cohen is silent with regard to the following limitations. However Kim in an analogous art of feedback/comment management for the purpose of providing the following limitations as shown does: further comprising providing, for display within the user interface of the provider computing device simultaneously with the status message and the notification message, a feedback feed comprising the feedback messages from the requestor devices matched to the provider computing device (¶ 0157: “The respective users (feedback giver and/or feedback recipient) see the feedback message and average feedback rating in the public feed, the received feed, and the sent feed immediately after the feedback giver selects the send commend. For example, the respective users may see the feedback message and average feedback rating in the feeds in seconds, such as in 2, 5, or 10 seconds or less (including milliseconds), after the feedback giver clicks on the send button.” See also figure 8, note the feedback feed received and a rating i.e., status message); Both Radhakrishnan and Kim teach feedback/comment management. Radhakrishnan teaches in the Abstract: “providing feedback for a transportation service.” Kim teaches in the Abstract: “involve a feedback application, a feedback processing application, an analytics application, and an event moderating application.” Thus, they are deemed to be analogous references as they are reasonably pertinent to each other and are directed towards solving similar problems within the same environment. One of ordinary skill in the art would have recognized that applying the known technique of Kim would have yielded predictable results and resulted in an improved system. It would have been recognized that applying the technique of Kim to the teaching of Radhakrishnan in view of Cohen would have yielded predictable results because the level of ordinary skill in the art demonstrated by the references applied shows the ability to incorporate such as providing, for display within the user interface of the provider computing device simultaneously with the status message and the notification message, a feedback feed comprising the feedback messages from the requestor devices matched to the transportation provider into similar systems. Further, as noted by Kim “The analytics application examines user's feedback giving and receiving behavior and evaluate their feedback empathy and authenticity and their learning behavior.” (Kim, Abstract). Claim 18: The limitations of claim 18 encompasses substantially the same scope as claims 7 and 8. Accordingly, those similar limitations are rejected in substantially the same manner as claims 7 and 8, as described above. Claim 10: Radhakrishnan as shown discloses the following limitations: further comprising: generating, based on receiving the selection of the selectable binary interactive element, generating a feedback message (¶ 0066: “the transport service may prompt the customer to answer a series of yes or no questions as a means of evaluating the performance of a particular driver. The questions may ask, for example, whether the driver was courteous, whether the driver opened the door or assisted the customer in entering the vehicle, the manner in which the driver drove the vehicle, and the driver's response time. The user's questionnaire feedback may be recorded for the particular driver and/or the company or operator that provided the driver.”); Radhakrishnan as explained above collect comments feedback messages (Figures 9A-9B). Radhakrishnan in view of Cohen as explained above display simultaneously the status message and the notification message. Radhakrishnan in view of Cohen is silent with regard to the following limitations. However Kim in an analogous art of feedback/comment management for the purpose of providing the following limitations as shown does: and providing, for display on a user interface of the provider computing device, the feedback message simultaneously with the status summary message and the notification message (¶ 0157: “The respective users (feedback giver and/or feedback recipient) see the feedback message and average feedback rating in the public feed, the received feed, and the sent feed immediately after the feedback giver selects the send commend. For example, the respective users may see the feedback message and average feedback rating in the feeds in seconds, such as in 2, 5, or 10 seconds or less (including milliseconds), after the feedback giver clicks on the send button.” See also figure 8, note the feedback message received and a rating i.e., status message); Both Radhakrishnan and Kim teach feedback/comment management. Radhakrishnan teaches in the Abstract: “providing feedback for a transportation service.” Kim teaches in the Abstract: “involve a feedback application, a feedback processing application, an analytics application, and an event moderating application.” Thus, they are deemed to be analogous references as they are reasonably pertinent to each other and are directed towards solving similar problems within the same environment. One of ordinary skill in the art would have recognized that applying the known technique of Kim would have yielded predictable results and resulted in an improved system. It would have been recognized that applying the technique of Kim to the teaching of Radhakrishnan in view of Cohen would have yielded predictable results because the level of ordinary skill in the art demonstrated by the references applied shows the ability to incorporate such as providing, for display on a user interface of the provider computing device, the feedback message simultaneously with the status message and the notification message into similar systems. Further, as noted by Kim “The analytics application examines user's feedback giving and receiving behavior and evaluate their feedback empathy and authenticity and their learning behavior.” (Kim, Abstract). Claim 20: The limitations of claim 20 encompasses substantially the same scope as claim 10. Accordingly, those similar limitations are rejected in substantially the same manner as claim 10, as described above. Claims 6 and 17 are rejected under 35 U.S.C. 103(a) as being unpatentable over Radhakrishnan et al., (US 2013/0246301 A1), hereinafter “Radhakrishnan” and Cohen et al., (US 2019/0287040 A1) hereinafter “Cohen”, as applied to claims 1 and 16, further in view of Sundelin et al., (US 2011/0055196 A1), hereinafter “Sundelin”. Claim 6: Radhakrishnan in view of Cohen as explained above teaches the notification messages for the provider computing device. Radhakrishnan in view of Cohen is silent with regard to the following limitations. However Sundelin in an analogous art of message management for the purpose of providing the following limitations as shown does: prioritizing a plurality of notification messages (¶ 0018: “when analyzing the priority of a message, directory data on the sender may be requested to determine if he is a peer, report, or manager of the recipient. For another example, to determine topics of interest to a user, content extraction may determine key topics across key data types, such as e-mail messages, calendar items, IM messages, and/or forum posts.”); and displaying the plurality of notification messages in the user interface of provider computing device in a consolidated view (¶ 0043: “a user dashboard may be provided to give the user a consolidated view of communication items. The dashboard may allow the user to control which items appear and what prominence (e.g., highlighting and prioritizing) they have.”); Both Radhakrishnan and Sundelin teach message management. Radhakrishnan teaches in ¶ 0115 “The user may then be further enabled to communicate a message using the network or communication function. This message may describe the positive aspects of a transportation service.” Sundelin teaches in ¶ 0046: “The insight may be provided by creating a message processing rule, providing at least one new piece of information to the user, updating an application display, and/or adding at least one functionality to an application.” Thus, they are deemed to be analogous references as they are reasonably pertinent to each other and are directed towards solving similar problems within the same environment. One of ordinary skill in the art would have recognized that applying the known technique of Sundelin would have yielded predictable results and resulted in an improved system. It would have been recognized that applying the technique of Sundelin to the teaching of Radhakrishnan in view of Cohen would have yielded predictable results because the level of ordinary skill in the art demonstrated by the references applied shows the ability to incorporate such as prioritizing a plurality of notification messages; and displaying the plurality of notification messages in the user interface of the provider computing device in a consolidated view into similar systems. Further, as noted by Sundelin “Message processing rules may be created and applied to modify incoming communications that match properties used to derive the insight.” (Sundelin, ¶ 0046). Claim 17: The limitations of claim 17 encompasses substantially the same scope as claim 6. Accordingly, those similar limitations are rejected in substantially the same manner as claim 6, as described above. Conclusion Any inquiry concerning this communication or earlier communications from the examiner should be directed to NADJA CHONG whose telephone number is (571)270-3939. The examiner can normally be reached on Monday-Friday 8:00 am - 2:00 pm ET, 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, RUTAO WU can be reached on 571.272.6045. 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://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000. /NADJA N CHONG CRUZ/ Primary Examiner, Art Unit 3623
Read full office action

Prosecution Timeline

Jul 31, 2025
Application Filed
Dec 17, 2025
Non-Final Rejection — §101, §103, §112
Mar 05, 2026
Interview Requested
Mar 10, 2026
Interview Requested
Mar 17, 2026
Applicant Interview (Telephonic)
Mar 17, 2026
Examiner Interview Summary

Precedent Cases

Applications granted by this same examiner with similar technology

Patent 12591822
AUTOMATIC ADJUSTMENT OF CONSTRAINTS IN TASK SOLUTION GENERATION
2y 5m to grant Granted Mar 31, 2026
Patent 12541725
OPTIMIZING GREEN HOUSE GAS SUSTAINABILITY WITH PROGNOSTIC MAINTENANCE MANAGEMENT PLANS FOR AN ENTERPRISE
2y 5m to grant Granted Feb 03, 2026
Patent 12530638
METHOD AND SYSTEM FOR SCHEDULING OPERATION AND MAINTENANCE PERSONNEL BASED ON INTERNET OF THINGS (IOT) SYSTEM FOR SMART GAS INSTALLATION MANAGEMENT
2y 5m to grant Granted Jan 20, 2026
Patent 12340326
System and Method of an Attribute-Value Combination and Assortment Planner
2y 5m to grant Granted Jun 24, 2025
Patent 12315022
REAL-TIME VALIDATION OF DISTRIBUTED ENERGY RESOURCE DEVICE COMMITMENTS
2y 5m to grant Granted May 27, 2025
Study what changed to get past this examiner. Based on 5 most recent grants.

AI Strategy Recommendation

Get an AI-powered prosecution strategy using examiner precedents, rejection analysis, and claim mapping.
Powered by AI — typically takes 5-10 seconds

Prosecution Projections

1-2
Expected OA Rounds
28%
Grant Probability
71%
With Interview (+43.3%)
4y 2m
Median Time to Grant
Low
PTA Risk
Based on 370 resolved cases by this examiner. Grant probability derived from career allow rate.

Sign in with your work email

Enter your email to receive a magic link. No password needed.

Personal email addresses (Gmail, Yahoo, etc.) are not accepted.

Free tier: 3 strategy analyses per month