DETAILED ACTION
Status of the Application
In response filed on November 12, 2025, the Applicant amended claims 1, 11-16, 19, and 20; added claim 23; and cancelled claim 17. Claims 8 and 18 were previously cancelled. Claims 1-7, 9-16, and 19-23 are pending and currently under consideration for patentability.
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 .
Response to Amendments and Arguments
v Applicant’s arguments, with respect to the rejection of claims 1-7, 9-16, and 19-23 under 35 U.S.C. 101 have been fully considered and are not persuasive. The rejections of claims 1-7, 9-16, and 19-23 under 35 U.S.C. 101 have been maintained accordingly.
Applicant specifically argues that
“Applicant respectfully submits that the amendments to claim 1 establish a specific structural arrangement that integrates any alleged abstract idea into a practical application and provides significantly more than any alleged judicial exception…. This distributed architecture creates a concrete technological arrangement wherein a remote server performs computationally intensive machine learning operations to generate action values, while an in-vehicle display presents the results to the user at an appropriate time (i.e., when the vehicle is at rest).This structural configuration addresses the technical problem of coordinating data processing and user interaction across physically separated components in a car sharing platform, and represents a specific implementation that improves upon generic computer systems. The claimed arrangement is analogous to the distributed network architecture found patent-eligible in DDR Holdings, LLC v. Hotels.com, L.P., 773 F.3d 1245 (Fed. Cir. 2014), where the court held that claims directed to a specific way of automating the creation of composite web pages were patent-eligible because they were "necessarily rooted in computer technology in order to overcome a problem specifically arising in the realm of computer networks." Here, the claimed distributed architecture between the remote server and the in- vehicle display is necessarily rooted in the car sharing platform technology and addresses the problem of how to efficiently process telematics data and coordinate action messaging across a fleet of vehicles while ensuring safe presentation of information to users.
Examiner respectfully disagrees with Applicant’s first argument.
The required combination of “one or more processors of a server” and “a display within the vehicle” is not very specific (e.g., merely requires use of any server anywhere to process data, and any sort of display device that happens to be within a vehicle to display information). These high-level recitations amount to “apply it” using computers and/or mere field of use limitations (e.g., do it on the internet with a distributed computers). Applicant’s suggestion that this “specific structural arrangement” addresses a technical problem is not persuasive. Applicant’s specification does not suggest there is a “problem of coordinating data processing and user interaction across physically separate components in a car sharing platform”. The specification does not appear to suggest there is any technical problem related to where certain aspects of the process are implemented, or that a certain inventive configuration addresses any technical problem. Instead, Applicant’s disclosure explains that the specific computing configuration is flexible (i.e., multiple equivalent configurations able to be chosen by the implementer of the process), and that any number of configurations may be used to implement the claimed steps/features. (see published disclosure at [0081]-[0082] “In general, the techniques herein (e.g., the method 600) may be implemented using a combination of one or more clients and/or one or more server devices. For example, depending on the hardware and software implementation chosen by an implementer, the method 600 may be entirely implemented using a single computing device (e.g., the telematics system 104)… may be entirely contained within a module of the telematics system 104 of FIG. 1. For example, the user interface framework may be included in a mobile application (e.g., Android or iPhone application) downloadable from an application store which is stored in the memory 122 and is executed by the processor 120.”, see also [0022] “referred to herein as a "server," the server 108 may, in some implementations, include multiple servers and/or other computing devices. Moreover, the server 108 may include multiple servers and/or other computing devices distributed over a large geographic area (e.g., including devices at one or more data centers), and any of the operations, computations, etc., described below may be performed in by remote computing devices in a distributed manner.” & [0023] “some or all of the components of the telematics system 104 may be built into the dash of the vehicle 102 or affixed elsewhere within the vehicle 102 ( e.g., via an onboard diagnostics port of the vehicle 102). In an embodiment, a portion of the telematics system 104 may be implemented using a mobile computing device (e.g., a smart phone of the user)” & [0026] “some embodiments, the telematics system 104 may include multiple different implementations of the display 124 (e.g., a first display 124 associated with the vehicle 102 and a second display 124 associated with a mobile computing device of the user).” & [0030] “The sensor 134 may include one or more sensors associated with the vehicle 102 (e.g., a speedometer sensor) and/or a mobile device of the user (e.g., an accelerometer in a smartphone)” & [0031] “The database 136 may be any suitable database” & [0052] “computer-implemented methods discussed herein may include additional, fewer, or alternate actions, including those discussed elsewhere herein. The methods may be implemented via one or more local or remote processors, transceivers, servers, and/or sensors (such as processors, transceivers, servers, and/or sensors mounted on drones, vehicles or mobile devices, or associated with smart infrastructure or remote servers), and/or via computer-executable instructions stored on non-transitory computer readable media or medium” & [0064] “The device 202 may correspond to a mobile computing device of the user, such as a smart phone, tablet, etc. In some embodiments, the device 202 may be a laptop or other suitable connected computing device. In still further embodiments, the device 202 may be a device of the CSP that is integral to the vehicle”
Applicant’s suggestion that the instant claims are similar to DDR Holdings is not persuasive. As discussed above, Applicant’s disclosure does not suggest to a PHOSITA that the invention relates to a particular inventive configuration used to address any technical problem. Applicant has instead appeared to merely select one potential embodiment involving use of remote servers and argued ex post facto that it addresses a technical problem.
Examiner maintains that being safer for the user if the messages are displayed when the vehicle is at rest is a non-technical and subjective problem/advantage. An improvement to the level of distraction or possible safety of the human is not an improvement to computer functionality/capabilities, an improvement to a computer-related technology or technological environment, and do not amount to a technology-based solution to a technology-based problem.
Applicant specifically argues that
“In addition, new claim 23, supported in the specification at least at paragraph 0071, recites: ...automatically verifying, by the one or more processors of the server, completion of each respective action by analyzing vehicle telematics data received from one or more vehicle sensors to determine a location of the vehicle, and releasing the respective action value only in response to the vehicle being relocated to a predetermined location. This limitation reflects a specific technical process for verifying action completion using sensor data analysis, rather than relying on manual verification. The specification explains that the system may “periodically check additional data (e.g., the location of the vehicle 102, data received from the sensor 134, vehicle telematics data, etc.) to determine whether a change to the vehicle imperative corresponding to the accepted action has occurred.” See specification, para. 0078. This automatic verification process using sensor data analysis is a technical solution that improves the efficiency and reliability of the car sharing platform by eliminating the need for manual verification of completed actions. Consideration of new claim 23 is respectfully requested.”
Examiner respectfully disagrees with Applicant’s second argument.
The method involves analyzing data to determine whether something has occurred. This is part of the abstract idea. That the telematics data is described as having been received from one or more vehicle sensors merely describes elements (the sensors themselves) external to the scope of the claimed invention, similar to the claims in Electric Power Group (e.g., where the claims describe the data being analyzed as having been collected from various locations in the power grid). The receiving of the data, which is also recited at a high level of generality (and arguably not as part of the claimed method) amounts to data gathering. Any efficiency or convenience realized via use of computers rather than relying on manual techniques is merely a result of “applying it” using general purpose computers. This is not a technical solution to a technical problem.
v Applicant’s arguments, with respect to the rejection of amended independent claims 1, 11, and 20 (as well as each of the respective dependent claims) under 35 U.S.C. §103 have been considered, but are not persuasive.
Applicant argues “Applicant respectfully submits that even if the individual elements were present in the prior art, a person of ordinary skill in the art would not have been motivated to combine the teachings of Tanuma, Shah, and Uenohara in the manner claimed.”
More specifically, Applicant argues that “Shah is directed to a ride-sharing system (not a car-sharing system) that uses machine learning to optimize driver incentives for vehicle relocation. Uenohara is directed to a vehicle safety system that controls the display of text messages based on vehicle state. These references address different problems in different contexts.” And that with respect to the combination of Tanuma and Shah “this reasoning is conclusory and does not explain why a person of ordinary skill would have looked to Shah's ride-sharing system when designing Tanuma's car-sharing maintenance system. The two systems operate in fundamentally different contexts: Shah's system involves drivers who own their vehicles and are incentivized to relocate them, while Tanuma's system involves a fleet of vehicles owned by the car sharing company where users are customers, not vehicle owners…. statement is conclusory and does not account for the specific technical challenges of the claimed invention. That is, the Office Action does not explain what results would be predictable or how the combination would address the specific problem solved by the claimed invention… These technical challenges are not addressed by the cited references, and the Office Action has not explained how a person of ordinary skill would have predictably overcome them by combining the references”. Examiner respectfully disagrees with Applicant’s argument. First, Applicant’s assertion that “Shah's system involves drivers who own their vehicles “or that “Tanuma's system involves a fleet of vehicles owned by the car sharing company where users are customers, not vehicle owners” is conclusory and not necessarily true. There is no basis for this assertion. Furthermore, Examiner disagrees that ride-sharing and car-sharing are very different from one another
Generally arguing that the prior art references involve “different contexts” or do not address the “problem solved by the claimed invention” is not persuasive. MPEP 2141 explicitly states that “In determining obviousness, neither the particular motivation to make the claimed invention nor the problem the inventor is solving controls”. In fact, the Supreme Court in KSR stressed that the Federal Circuit had errored by holding that Examiner’s should be looking only at the problem the patentee was trying to solve. Applicant’s repeated argument regarding the references “different contexts” or different “problems” is therefore not persuasive. These arguments appear to be loosely related to whether or not these references qualify as analogous art. So does Applicant’s argument that the Examiner’s rejection does not explain why a person of ordinary skill would have looked to Shah when designing Tanuma’s car-sharing maintenance system. However, Applicant has not explicitly argued that neither reference qualifies as analogous art. As such, the Examiner need not address this hypothetical argument. Examiner notes, however, that both prior art references are in the field of the inventor’s endeavor and/or are reasonably pertinent to the particular problem with which the inventor was concerned (managing vehicle operation/actions and/or motivating drivers to perform certain actions). Examiner further notes that the Examiner’s rejection need to “explain why a person of ordinary skill would have looked to Shah”. This is not a requirement for making a rejection using prior art. Applicant’s suggestion that the rejection does not explains what results would be predictable is not true or persuasive. The Examiner indicated that it would have been recognized that “applying the action value optimization technique of Shah to the method/system of Tanuma would have been recognized by one of ordinary skill in the art as resulting in an improved system that would allow more optimal incentivization. In other words, Shah demonstrates that one skilled in the art at the effective filing date of the invention would have been able to train a plurality of different machine learning models to output action values given sets of inputs, that different models could be used for different contexts (e.g., users, vehicle requirements), and that one skilled in the art would have recognized that it would be advantageous to do so because then the incentivization would be optimized based on expense to the operator and probability of acceptance by the user.” Applicant’s argument is therefore not accurate or persuasive. Examiner further notes that presenting a message while the vehicle is at rest is merely one aspect of the claimed invention, and is not the sole “problem” being addressed by the claimed invention.
Applicant’s argument against combining Uenohara with Tanuma in view of Shah is similarity not persuasive. Applicant argues that “The Office Actions reasoning for combining…is that ‘doing so can ensure the safety of the driver and provide safeguards preventing the user's interaction/distraction with information while the vehicle is in motion." See Office Action, p. 26. However, this reasoning does not explain why a person of ordinary skill would have been motivated to integrate Uenohara's text message safety system into a car sharing maintenance platform.”. The Examiner is not arguing that it would have been obvious to integrate all of Uenohara's system with Tanuma’s system. The Examiner merely argues that it would have been obvious to modify the system of Tanuma to determine that the user is operating the vehicle at rest, and displaying the information on a display within the vehicle in response to determining that the user is operating the vehicle at rest. The Examiner’s reasoning does explain why a person of ordinary skill would have been motivated to do this. Specifically, the Examiner stated that a PHOSITA would have been motivation to do so because doing so can ensure the safety of the driver and provide safeguards preventing the user's interaction/distraction with information while the vehicle is in motion. Again, Uenohara need not be concerned specifically with displaying maintenance action messages in a car sharing context to qualify as prior art.
Applicant further argues that the “applied references do not teach the claimed databinding”. Examiner respectfully disagrees. Applicant’s suggestion that the claimed feature includes “where the framework automatically updates graphical representations when data with matching identifiers is received. The specification explains that "Components may include an identifier that allows them to be bound, styled, and unambiguously referenced by the user interface framework" and that "whenever data with the label 'destination-name' is received, the value of the text area depicting the destination name is always updated." Specification, para. 0086.” is incommensurate with what is actually claimed. The instant claims do not require that the framework automatically updates graphical representations when data with matching identifiers is received. The claims merely suggest that each data element has a data type and is associated with an identifier that enables automatic updating (of a graphical representation of a corresponding data element) upon receipt of update data. Suggesting an identifier enables something to happen is different from actually claiming that thing happening. The claimed high-level suggestion also hardly defines the claimed “user interface framework”, other than suggesting it generally comprises logically programming (“binding”) certain corresponding location of the interface (e.g., a button, an overlay, an element of the interface – i.e., a component of the interface corresponding to the particular information element) in a data structure to correspond to a particular information element (e.g., an information element indicative of a respective action), where each element has a data type and associated identifier. Applicant’s assertion that HTML scripting or combinations of Javascript and XML do not read on this is conclusory and not persuasive. Applicant’s own published disclosure at [0090] explains that the “framework” and “data binding” may comprise rendering information as “one or more an HTML output file” and “may be performed by calling a render function of the user interface framework which outputs complete or partial HTML/Javascript/CSS files corresponding to the mobile application”. Applicant is attempting to manufacture a difference between the “HTML/Javascript” framework of Applicant’s own specification and the “HTML scripting or combinations of Javascript and XML” of Shah based on the fact that Applicant’s specification describes details of how these “frameworks” operation. Not only does Shah disclose use HTML/Javascript framework, a PHOSITA would understand that HTML/Javascript implementations of the application GUI described as displaying certain information at certain locations and also that describes certain data elements of the application GUI as being dynamically updated in real involves programming language that involves data element tagging (i.e., logically programming (“binding”) certain corresponding locations of the interface (e.g., a button, an overlay, an element of the interface) to a particular information elements and where each element has a data type and associated identifier.
For example, Shah Fig 12 tags 110 & 1210 & 1214 & Figs 13E and 13F show a user interface with a current location element (tag 1314) and a current action value element (tag 1318) and various zone elements (tags 1310 and 1312) that are each “components” on the display that are dynamically updated in real time (6:49-60 “The accumulation interface portion includes an incremental bonus metric (i.e., accumulation metric) that increases as the provider approaches the target area and/or based on the time that the provider stays in each of the zones…as the provider moves, the mapping interface portions update…”). The current location element (tag 1314) and/or a current action value element (tag 1318) and or the target area zone to which the user should relocate are all “components indicative of the one or more respective actions” (e.g., because they relate to and/or are indicative of a relocation action). Shah further discloses that these component are binded to corresponding data element of a data structure that has a data type and is associated with an identifier (e.g., 47:25-60 “the transportation matching system 102 inputs the selected providers 912 and the offered incentives 914 to the interface generator 110. In some embodiments, the selected providers 912 include the identifier of each selected provider (e.g., provider_id), the current location of the provider, and an identifier of the target area to which the provider is being attracted (e.g., target_area_id)…. the interface generator 110 generate a separate map for each provider that shows the provider and 45 the target area. In some embodiments, the target area is the epicenter of the map 1208…interface generator 110 generates a single zone matching at least the boundaries of the target area identified from the 60selected providers 912.” & 48:54-62 “the interface generator 110 creates a zone by identifying the area identifier (e.g., area_id) that belongs in a zone. For example, the interface generator 110 creates an inner zone table that includes the identifier of the target area. In addition, the interface generator 110 creates an outer zone table that includes identifiers of areas surrounding the target zone. Then, using the tables, the interface generator 110 creates an overlay for the map 1208.” & 50:1-14 “can continually update a provider's customized interface…as the provider travels toward and lingers in the target area, the interface generator 110 updates the provider's current location on the map as well as increases the incremental accumulation metric (until the maximum incentive is reached)…”). As such, Shah discloses “binding” user interface components indicative of one or more respective actions (e.g., a target zone component corresponding to a relocation action) to corresponding data element (e.g., target zone data element) that has a data type and associated identifier (e.g., “target_area_id” data element) via a user interface “framework” (e.g., a programming language – such as HTML scripting or combinations of Javascript and XML) and that enables the system to dynamically update the graphical representation of the corresponding data element as data is updated.
Examiner further notes that Applicant appears to suggest that two different mobile application frameworks (e.g., React.js, Angular) were known at the effective filing date, and that these frameworks are not invented by Applicant. This appears to be an admission of prior art that discloses the claimed frameworks as well.
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.
v Claim(s) 1-7, 9-16, and 19-23 is/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.
Step 1:
Claim(s) 1-7, 9, 10, 22, and 23 is/are drawn to methods (i.e., a process), while claim(s) 11-16 and 19-21 is/are drawn to systems (i.e., a machine/manufacture). As such, claims 1-7, 9-16, and 19-23 is/are drawn to one of the statutory categories of invention (Step 1: YES).
Step 2A - Prong One:
In prong one of step 2A, the claim(s) is/are analyzed to evaluate whether it/they recite(s) a judicial exception.
Claim 1 (representative of independent claim(s) 11 and 20) recites/describes the following steps;
analyzing… a first data set to determine one or more vehicle imperatives, each comprising one or more respective actions;
generating…a respective action value for each of the one or more respective actions corresponding to the determined one or more vehicle imperatives by analyzing each of the one or more respective actions using a respective one of a plurality of trained models according to a vehicle imperative type associated with each of the one or more respective actions, each model having been trained to generate respective action values for actions corresponding to respective vehicle imperative types, at least one of the plurality of models trained to generate action values for actions corresponding to a non-relocation vehicle imperative type;
analyzing…a second data set to identify changes to the one or more determined vehicle imperatives indicating one or more completed actions;
releasing…based upon the analyzing of the second data set, the respective action value to the user for each of the one or more completed actions
determining that the user is operating the vehicle at rest; and in response to determining that the user is operating the vehicle at rest, displaying the one or more respective actions
These steps, under its broadest reasonable interpretation, describe or set-forth analyzing data associated with a vehicle to determine required task(s) (e.g., vehicle maintenance/service requirements) and using respective models to determine respective incentive(s) (i.e., “action values”) to offer a user to perform the required task(s) based on the type of task, analyzing subsequent data to determine whether or not the task(s) was/were completed, providing the user with the inventive(s) for each completed task, and displaying the one or more respective actions to the user in response to determining that the user is operating the vehicle at rest, which amounts to a commercial or legal interactions (specifically, an advertising, marketing or sales activity or behavior; business relations). These limitations therefore fall within the “certain methods of organizing human activity” subject matter grouping of abstract ideas.
Each of these steps, additionally and/or alternatively encompass a human manually (e.g., in their mind, or using paper and pen) analyzing data associated with a vehicle to determine required task(s) (e.g., maintenance/service requirements) and using respective models to determine respective incentive(s) (i.e., “action values”) to offer a user to perform the required task(s) based on the type of task, analyzing subsequent data to determine whether or not the task(s) was/were completed, providing the user with the inventive(s) for each completed task, and displaying the one or more respective actions to the user in response to determining that the user is operating the vehicle at rest (i.e., one or more concepts performed in the human mind, such as one or more observations, evaluations, judgments, opinions), but for the recitation of generic computer components. If one or more claim limitations, under their broadest reasonable interpretation, covers performance of the limitation(s) in the mind but for the recitation of generic computer components, then it falls within the “mental processes” subject matter grouping of abstract ideas.
As such, the Examiner concludes that claim 1 recites an abstract idea (Step 2A – Prong One: YES).
Independent claim(s) 11 and 20 recite/describe nearly identical steps (and therefore also recite limitations that fall within this subject matter grouping of abstract ideas), and this/these claim(s) is/are therefore determined to recite an abstract idea under the same analysis.
Each of the depending claims likewise recite/describe these steps (by incorporation - and therefore also recite limitations that fall within this subject matter grouping of abstract ideas), and this/these claim(s) is/are therefore determined to recite an abstract idea under the same analysis. Any element(s) recited in a dependent claim that are not specifically identified/addressed by the Examiner under step 2A (prong two) or step 2B of this analysis shall be understood to be an additional part of the abstract idea recited by that particular claim. The same reasoning is similarly applicable to the limitations in the remaining dependent claims, and their respective limitations are not reproduced here for the sake of brevity.
Step 2A - Prong Two:
In prong two of step 2A, an evaluation is made whether a claim recites any additional element, or combination of additional elements, that integrate the exception into a practical application of that exception. An “addition element” is an element that is recited in the claim in addition to (beyond) the judicial exception (i.e., an element/limitation that sets forth an abstract idea is not an additional element). The phrase “integration into a practical application” is defined as requiring an additional element or a combination of additional elements in the claim to apply, rely on, or use the judicial exception in a manner that imposes a meaningful limit on the judicial exception, such that it is more than a drafting effort designed to monopolize the exception.
The claim(s) recite the additional elements/limitations of
“computer-implemented…by one or more processors of a server remote from the vehicle…by the one or more processors of the server……by the one or more processors of the server…by the one or more processors of the server…by the one or more processors of the server” (claim 1)
“a system…including, a non-transitory computer-readable medium containing program instructions that when executed, cause a server remote from the vehicle to…” (claim 11)
“a computing system…comprising: one or more processors of a server remote from the vehicle configured to” (claim 20)
“on a display within the vehicle, wherein the displaying comprises binding, via a user interface framework, components indicative of the one or more respective actions to corresponding data elements of a data structure, wherein each data element has a data type and is associated with an identifier that enables automatic updating of a graphical representation of the corresponding data element upon receipt of updated data” (claims 1 and 20)
“machine learning models” (claims 1, 11, and 20)
“transmitting the one or more actions to a mobile computing device of the user via a push message” (claims 9 and 19)
“by the one or more processors” (claim 22)
“by the one or more processors of the server” (claim 23)
“updating… a structured query language (SQL) database to indicate…wherein the SQL database stores” (claim 22)
The requirement to execute the claimed steps/functions via a method that is “computer-implemented…by one or more processors of a server remote from the vehicle…by the one or more processors of the server……by the one or more processors of the server…by the one or more processors of the server…by the one or more processors of the server” (claim 1) or “a system…including, a non-transitory computer-readable medium containing program instructions that when executed, cause a server remote from the vehicle to…” (claim 11) or “a computing system…comprising: one or more processors of a server remote from the vehicle configured to” (claim 20) and/or “on a display within the vehicle” (claims 1, 11, and 20) and/or “by the one or more processors” (claim 22) and/or “by the one or more processors of the server” (claim 23) is equivalent to adding the words “apply it” on a generic computer and/or mere instructions to implement the abstract idea on a generic computer. Applicant’s own disclosure explains that the above-identified components may be embodied as a general-purpose computer (e.g., paragraphs [0022] & [0032]-[0033] & [0052] & [0093] of the published specification). Examiner notes that the recitation of using “machine learning models” (claims 1, 11, and 20) provides nothing more than mere instructions to implement an abstract idea on a generic computer. See MPEP 2106.05(f) and the July 2024 Subject Matter Eligibility Examples and corresponding analysis. MPEP 2106.05(f) provides the following considerations for determining whether a claim simply recites a judicial exception with the words “apply it” (or an equivalent), such as mere instructions to implement an abstract idea on a computer: (1) whether the claim recites only the idea of a solution or outcome i.e., the claim fails to recite details of how a solution to a problem is accomplished; (2) whether the claim invokes computers or other machinery merely as a tool to perform an existing process; and (3) the particularity or generality of the application of the judicial exception. The machine learning models are used to generally apply the abstract idea without placing any limits on how the machine learning models functions. Rather, these limitations only recite the outcome of “generating…a respective action value…by analyzing each of the respective actions” and do not include any details about how the “generating” is accomplished. See MPEP 2106.05(f) and the July 2024 Subject Matter Eligibility Examples and corresponding analysis. Furthermore, the recited “on a display” (claims 1 and 20) are conventional computers or other machinery that are invoked merely as a tool to perform an existing process (i.e., display information) and that are being used in their ordinary capacity. In other words, the claims invoke the display merely as tools to execute the abstract idea. This/these limitation(s) do/does not impose any meaningful limits on practicing the abstract idea, and therefore do/does not integrate the abstract idea into a practical application (see MPEP 2106.05(f)).
The recited additional element(s) of “on a display within the vehicle, wherein the displaying comprises binding, via a user interface framework, components indicative of the one or more respective actions to corresponding data elements of a data structure, wherein each data element has a data type and is associated with an identifier that enables automatic updating of a graphical representation of the corresponding data element upon receipt of updated data” (claims 1 and 20) additionally/alternatively serves merely to generally link the use of the judicial exception to a particular technological environment or field of use. Applicant’s disclosure suggests in paragraph [0081] of the published disclosure that “Increasingly, software developers are using user interface frameworks to build applications that allow application data, structure, state, behavior, and styling to be independently designed and managed. React.js and Angular are two popular application platforms for creating mobile applications, for example.” More generally, Applicant’s claims refer broadly to a “user interface framework” and “binding” and “data type” and “identifiers”. Even apart from mobile application user interface frameworks (e.g., React.js, Angular), these high-level requirements could be interpreted as describing how web-pages function to load certain data elements, where html data elements/tags are used to retrieve/update and embed different information into certain scripted portions of a web-pages. The requirement of “wherein the displaying comprises binding, via a user interface framework, components indicative of the one or more respective actions to corresponding data elements of a data structure, wherein each data element has a data type and is associated with an identifier that enables automatic updating of a graphical representation of the corresponding data element upon receipt of updated data” does not amount to an inventive “solution” to which the claims are directed, and instead serves merely to generally link the use of the judicial exception to a particular technological environment or field of use. Specifically, it/they serve(s) to limit the application of the abstract idea to computing environments, such as the internet and or web-based interfaces (or, at most, an interface using a particular known and available mobile application platform). This reasoning was demonstrated in Intellectual Ventures I LLC v. Capital One Bank (Fed. Cir. 2015), where the court determined "an abstract idea does not become nonabstract by limiting the invention to a particular field of use or technological environment, such as the Internet [or] a computer"). This/these limitation(s) do/does not impose any meaningful limits on practicing the abstract idea, and therefore do/does not integrate the abstract idea into a practical application (see MPEP 2106.05(g)).
The recited additional element(s) of “transmitting the one or more actions to a mobile computing device of the user via a push message” (claims 9 and 19) serves merely to generally link the use of the judicial exception to a particular technological environment or field of use. Specifically, it/they serve(s) to limit the application of the abstract idea to computing environments, such as distributed computing environments and/or the internet, where information is represented digitally, exchanged between computers over a network (e.g., via a push message), and presented using graphical user interfaces. This reasoning was demonstrated in Intellectual Ventures I LLC v. Capital One Bank (Fed. Cir. 2015), where the court determined "an abstract idea does not become nonabstract by limiting the invention to a particular field of use or technological environment, such as the Internet [or] a computer"). This/these limitation(s) do/does not impose any meaningful limits on practicing the abstract idea, and therefore do/does not integrate the abstract idea into a practical application (see MPEP 2106.05(g)).
The recited additional element(s) of “updating… a structured query language (SQL) database to indicate…wherein the SQL database stores” (claim 22) serves merely to generally link the use of the judicial exception to a particular technological environment or field of use. The SQL is non-inventive (Applicant did not invent an SQL database), and Applicant’s disclosure suggests this is merely one of multiple types of databases that may be used. Applicant’s published disclosure at paragraph [0031] explicitly states that “the database 136 may be any suitable database” and mentions SQL as merely one exemplary type of database. Requiring use of an SQL databased in the claims does not mean the claimed invention is directed to an improvement to computer functionality/capabilities, an improvement to a computer-related technology or technological environment, and/or a technology-based solution to a technology-based problem. The SQL database is recited at an “apply it” level, any advantages associated with an SQL database are purely resulting from use of this conventional type of database (i.e., it is non-inventive), and the requirement to use an SQL database serves merely to generally link the use of the judicial exception to a particular technological environment or field of use. Specifically, it/they serve(s) to limit the application of the abstract idea to computing environments where information is stored in an SQL database. This reasoning was demonstrated in Intellectual Ventures I LLC v. Capital One Bank (Fed. Cir. 2015), where the court determined "an abstract idea does not become nonabstract by limiting the invention to a particular field of use or technological environment, such as the Internet [or] a computer"). This/these limitation(s) do/does not impose any meaningful limits on practicing the abstract idea, and therefore do/does not integrate the abstract idea into a practical application (see MPEP 2106.05(g)).
The recitation of using “machine learning models” (claims 1, 11, and 20) also merely indicates a field of use or technological environment in which the judicial exception is performed. Although the additional element “machine learning models” (claims 1, 11, and 20) limits the identified judicial exceptions “generating…using a respective one of a plurality of trained machine learning models” (claims 1, 11, and 20), this type of limitation merely confines the use of the abstract idea to a particular technological environment (machine learning models) and thus fails to add an inventive concept to the claims. See MPEP 2106.05(h) and the July 2024 Subject Matter Eligibility Examples and corresponding analysis. This/these limitation(s) do/does not impose any meaningful limits on practicing the abstract idea, and therefore do/does not integrate the abstract idea into a practical application (see MPEP 2106.05(g)).
Furthermore, although the claims recite a specific sequence of computer-implemented functions, and although the specification suggests certain functions may be advantageous for various reasons (e.g., business reasons), the Examiner has determined that the ordered combination of claim elements (i.e., the claims as a whole) are not directed to an improvement to computer functionality/capabilities, an improvement to a computer-related technology or technological environment, and do not amount to a technology-based solution to a technology-based problem. For example, Applicant’s as-filed specification suggests that it is advantageous for advertisers/business to perform the abstract idea identified above because it can help ensure a fleet of vehicles are properly maintained by incentivizing customers/users to facilitate vehicle servicing without requiring dedicated staff/technicians to facilitate the vehicle servicing (subjective business purpose) (see, for example, paragraphs [0006]-[0008] & [0066] & [0079]-[0080] of Applicant’s published disclosure). These are non-technical business advantages/improvements. At most, the ordered combination of claim elements is directed to a non-technical improvement to an abstract idea itself (e.g., a method of incentivizing vehicle maintenance).
Dependent claims 2-7, 10, 12-17, and 21 fail to include any additional elements. In other words, each of the limitations/elements recited in respective dependent claims 2-7, 10, 12-17, and 21 is/are further part of the abstract idea as identified by the Examiner for each respective dependent claim (i.e. they are part of the abstract idea recited in each respective claim). For example, claim 2 recites “wherein the first data set is a vehicle telematics data set”. This merely describes the type of data being analyzed. This is an abstract limitation which further sets forth the abstract idea encompassed by claim 2. This limitation is not an “additional element”, and therefore it is not subject to further analysis under Step 2A- Prong Two or Step 2B. The same logic applies to each of the other dependent claims, whose limitations are not being repeated here for the sake of brevity and clarity.
The Examiner has therefore determined that the additional elements, or combination of additional elements, do not integrate the abstract idea into a practical application. Accordingly, the claim(s) is/are directed to an abstract idea (Step 2A – Prong two: NO).
Step 2B:
In step 2B, the claims are analyzed to determine whether any additional element, or combination of additional elements, is/are sufficient to ensure that the claims amount to significantly more than the judicial exception. This analysis is also termed a search for an "inventive concept." An "inventive concept" is furnished by an element or combination of elements that is recited in the claim in addition to (beyond) the judicial exception, and is sufficient to ensure that the claim as a whole amounts to significantly more than the judicial exception itself. Alice Corp., 134 S. Ct. at 2355, 110 USPQ2d at 1981 (citing Mayo, 566 U.S. at 72-73, 101 USPQ2d at 1966)
As discussed above in “Step 2A – Prong 2”, the requirement to execute the claimed steps/functions via a method that is “computer-implemented…by one or more processors of a server remote from the vehicle…by the one or more processors of the server……by the one or more processors of the server…by the one or more processors of the server…by the one or more processors of the server” (claim 1) or “a system…including, a non-transitory computer-readable medium containing program instructions that when executed, cause a server remote from the vehicle to…” (claim 11) or “a computing system…comprising: one or more processors of a server remote from the vehicle configured to” (claim 20) and/or using “machine learning models” (claims 1, 11, and 20) and/or “by the one or more processors” (claim 22) and/or “on a display” (claims 1 and 20) or “by the one or more processors of the server” (claim 23) is equivalent to adding the words “apply it” on a generic computer and/or mere instructions to implement the abstract idea on a generic computer. These limitations therefore do not qualify as “significantly more” (see MPEP 2106.05(f)).
As discussed above in “Step 2A – Prong 2”, the recited additional element(s) of “transmitting the one or more actions to a mobile computing device of the user via a push message” (claims 9 and 19) and/or using “machine learning models” (claims 1, 11, and 20) and/or “on a display, wherein the displaying comprises binding, via a user interface framework, components indicative of the one or more respective actions to corresponding data elements of a data structure, wherein each data element has a data type and is associated with an identifier that enables automatic updating of a graphical representation of the corresponding data element upon receipt of updated data” (claims 1 and 20) and/or “updating… a structured query language (SQL) database to indicate…wherein the SQL database stores” (claim 22) serves merely to generally link the use of the judicial exception to a particular technological environment or field of use. These limitations therefore do not qualify as “significantly more” (see MPEP 2106.05(g)).
Viewing the additional limitations in combination also shows that they fail to ensure the claims amount to significantly more than the abstract idea. When considered as an ordered combination, the additional components of the claims add nothing that is not already present when considered separately, and thus simply append the abstract idea with words equivalent to “apply it” on a generic computer and/or mere instructions to implement the abstract idea on a generic computer, and generally link the abstract idea to a particular technological environment or field of use.
Dependent claims 2-7, 10, 12-17, and 21 fail to include any additional elements. In other words, each of the limitations/elements recited in respective dependent claims 2-7, 10, 12-17, and 21 is/are further part of the abstract idea as identified by the Examiner for each respective dependent claim (i.e. they are part of the abstract idea identified by the Examiner to which each respective claim is directed).
The Examiner has therefore determined that no additional element, or combination of additional claims elements is/are sufficient to ensure the claim(s) amount to significantly more than the abstract idea identified above (Step 2B: NO).
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102 of this title, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
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.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
v Claims 1-7, 9, 11-16, 19-21, and 23 are rejected under 35 U.S.C. 103 as being unpatentable over Tanuma et al. (U.S. PG Pub No. 2020/0126320 April 23, 2020 - hereinafter "Tanuma”) in view of in view of Shah et al. (U.S. Patent No. 10,552,773 February 4, 2020 - hereinafter "Shah”) in view of in view of Uenohara et al. (U.S. PG Pub No. 2020/0174261 June 4, 2020 - hereinafter "Uenohara”)
With respect to claim 1, 11, and 20, Tanuma teaches a computer-implemented method of causing a user of a car shar