DETAILED ACTION
This Office action is in response to the applicant's filing of 08/27/2024.
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Status of Claims
Claims 1-20 are pending and have been examined.
Information Disclosure Statement
The information disclosure statement(s) (IDS) submitted on 08/27/2024 and 09/13/2024 have been considered by the examiner.
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP §§ 706.02(l)(1) - 706.02(l)(3) for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/process/file/efs/guidance/eTD-info-I.jsp.
Claims 1-20 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-36 of U.S. Patent No. 12,211,009 because the patent and the application under examination name the same inventive entity. Although the claims at issue are not identical, they are not patentably distinct from each other because the claims in Patent No. 12,211,009 recite the entirety of limitations of claims 1-20 of the instant application. For example, application claims 1, 11, and 20 are anticipated by patent claims 1, 35, and 36 because patent claims 1, 35, and 36 recite additional features such as “determining, by the computing system, the first vehicle history session has ended and completing storage of the report regarding the first vehicle history session within the memory local to the computing system, wherein completing storage of the report includes adding into the report a line indicating completion of the report; automatically transmitting, by the computing system after completing storage of the report, the report over an off-board communication network for storage at a remote cloud-based non-transitory computer- readable memory, wherein the report transmitted after completing storage of the report includes the line indicating completion of the report, a first report input, and at least a portion of the metadata regarding the first vehicle history session, wherein the first report input includes the first action identifier, the first time stamp, and at least a summary of the first detail corresponding to the first action identifier; and displaying, on a display, a graphical user interface to show at least a portion of the report for assessing how the vehicle has performed” wherein application claims 1, 11, and 20 do not recite these features and are essentially broader than patent claims 1, 35, and 36. Therefore patent claim 1 of Patent No. 12,211,009 is in essence a “species” of the generic invention of application claim 1. It has been held that a generic invention is “anticipated” by a “species” within the scope of the generic invention. See In re Goodman, 29 USPQ2d 2010 (Fed. Cir. 1993). Claims 2-10 (Dependent on Claim 1) and claims 12-19 (Dependent on Claim 11) do not cure the deficiencies of the independent claims. Appropriate correction is required.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter. The claims are directed to a judicial exception (i.e., a law of nature, natural phenomenon, or abstract idea) without significantly more.
Step 1: In a test for patent subject matter eligibility, claims 1-20 are found to be in accordance with Step 1 (see 2019 Revised Patent Subject Matter Eligibility), as they are related to a process, machine, manufacture, or composition of matter. Claims 1-10 recite a method; and claims 11-19 recite a system; and claim 20 recites a computer-readable medium. When assessed under Step 2A, Prong I, they are found to be directed towards an abstract idea. The rationale for this finding is explained below:
Step 2A, Prong I: Under Step 2A, Prong I, independent claims 1, 11, and 20 are directed to an abstract idea without significantly more, as they all recite a judicial exception. Claims 1, 11, and 20 recite limitations directed to the abstract idea including “determining a vehicle identifier for a particular vehicle; initiating a vehicle history session for the particular vehicle; performing, during performance of the vehicle history session, a first user-requested action of the vehicle history session, wherein performing the first user-requested action includes transmitting at least a first vehicle data message (VDM) and receiving at least a second VDM in response to at least the first VDM; receiving, during the performance of the vehicle history session, broadcast vehicle data message sent automatically rather than in response to user-requested action; determining an action identifier corresponding to the first user-requested action, a time stamp corresponding to the first user-requested action, and first details corresponding to a performance of the first user-requested action; generating a file for storing a report regarding the vehicle history session; storing, within the report, report inputs regarding the first user-requested action without storing the broadcast vehicle data message sent automatically rather than in response to user-requested actions; and displaying to show at least a portion of the report for assessing how the particular vehicle has performed.” These further limitations are not seen as any more than the judicial exception. Claims 1, 11, and 20 recite additional limitations including “at/connected to the computing system; by/to/from the particular vehicle; within a non-transitory memory; and on a display, a graphical user interface.” The claims are considered to be an abstract idea under certain methods of organizing human activity because the claims are directed to commercial or legal interactions (including agreements in the form of contracts; legal obligations; advertising, marketing or sales activities or behaviors; business relations) and managing personal behavior or relationships or interactions between people (including social activities, teaching, and following rules or instructions) such as displaying a report regarding vehicle history session based on first/second vehicle data message and broadcast vehicle data message. The claims are also considered to be an abstract idea under mental processes because the claims are directed to concepts performed in the human mind (including an observation, evaluation, judgment, opinion) such as determining data (i.e. vehicle identifier), transmitting data (i.e. first vehicle data message), receiving data (i.e. second vehicle data message), receiving data automatically (i.e. broadcast vehicle data message), determining data (i.e. action identifier, time stamp, and first details corresponding to a performance), generating data (i.e. a file for storing a report), storing data within the report (i.e. report inputs) without storing other data (i.e. broadcast vehicle data), and displaying report for performance. Therefore, under Step 2A, Prong I, claims 1, 11, and 20 are directed towards an abstract idea.
Step 2A, Prong II: Step 2A, Prong II is to determine whether any claim recites any additional element that integrate the judicial exception (abstract idea) into a practical application. Claims 1, 11, and 20 recite additional limitations including “at/connected to the computing system; by/to/from the particular vehicle; within a non-transitory memory; and on a display, a graphical user interface.” The limitations reciting – “at/connected to the computing system; by/to/from the particular vehicle; within a non-transitory memory; and on a display, a graphical user interface” are seen as adding the words “apply it” (or an equivalent) with the judicial exception, or mere instructions to implement an abstract idea on a computer, or merely uses a computer as a tool to perform an abstract idea - see MPEP 2106.05(f). Accordingly, alone, and in combination, these additional elements are seen as using a computer or tool to perform an abstract idea, adding insignificant-extra-solution activity to the judicial exception. They do no more than link the judicial exception to a particular technological environment or field of use, i.e. computing system/vehicle/memory/GUI, and therefore do not integrate the abstract idea into a practical application. The courts decided that although the additional elements did limit the use of the abstract idea, the court explained that this type of limitation merely confines the use of the abstract idea to a particular technological environment and this fails to add an inventive concept to the claims (See Affinity Labs of Texas v. DirecTV, LLC,). Under Step 2A, Prong II, these claims remain directed towards an abstract idea.
Step 2B: Claims 1, 11, and 20 recite additional limitations including “at/connected to the computing system; by/to/from the particular vehicle; within a non-transitory memory; and on a display, a graphical user interface.” The limitations reciting – “at/connected to the computing system; by/to/from the particular vehicle; within a non-transitory memory; and on a display, a graphical user interface” do not integrate the judicial exception (abstract idea) into a practical application because of the analysis provided in Step 2A, Prong II. Claims 1, 11, and 20 do not include additional elements or a combination of elements that result in the claims amount to significantly more than the judicial exception. As discussed above with respect to integration of the abstract idea into a practical application, the additional elements listed amount to no more than mere instructions to apply an exception using a generic computer component. In addition, the applicant’s specifications describe a “general purpose computer”/“general-purpose processor”, ¶ [0055], for implementing the system, which do not amount to significantly more than the abstract idea of itself, which is not enough to transform an abstract idea into eligible subject matter. Furthermore, there is no improvement in the functioning of the computer or technological field, and there is no transformation of subject matter into a different state. Under Step 2B in a test for patent subject matter eligibility, these claims are not patent eligible.
Dependent claims 2-10 and 12-19 further recite the method and system of claims 1 and 11, respectively. Dependent claims 2-10 and 12-19 when analyzed as a whole are held to be patent ineligible under 35 U.S.C. 101 because the additional recited limitation fail to establish that the claims are not directed to an abstract idea:
Under Step 2A, Prong I, these additional claims only further narrow the abstract idea set forth in claims 1, 11, and 20. For example, claims 2-10 and 12-19 describe the limitations for displaying a report regarding vehicle history session based on first/second vehicle data message and broadcast vehicle data message – which is only further narrowing the scope of the abstract idea recited in the independent claims.
Under Step 2A, Prong II, for dependent claims 2-10 and 12-19, there are no additional elements introduced. Thus, they do not present integration into a practical application, or amount to significantly more.
Under Step 2B, the dependent claims do not include any additional elements that are sufficient to amount to significantly more than the judicial exception. Additionally, there is no improvement in the functioning of the computer or technological field, and there is no transformation of subject matter into a different state. As discussed above with respect to integration of the abstract idea into a practical application, the additional claims do not provide any additional elements that would amount to significantly more than the judicial exception. Under Step 2B, these claims are not patent eligible.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim(s) 1-20 are rejected under 35 U.S.C. 103 as being unpatentable over U.S. Patent 9,426,225 to Penilla in view of U.S. Patent 9,818,120 to Lesesky.
Claims 1-10, 11-19, and 20 are method, system, and computer-readable medium claims, respectively, with substantially indistinguishable features between each group. For purposes of compact prosecution, the Office has grouped the common method, system and non-transitory computer readable storage medium claims in applying applicable prior art.
With respect to Claim 1:
Penilla teaches:
A method comprising: determining, at a computing system, a vehicle identifier for a particular vehicle connected to the computing system (i.e. determining identifier assigned to car) (Penilla: Col. 18 Lines 33-38 “Also shown in cloud services 120 is the car database 116/115. The car database can then be provided with information from the car sharing company 210 that identifies the cars that the company owns and that are shared with the service. The car data including assigned IDs to the vehicles and cars can be stored in the car database 116/115.”);
initiating, at the computing system, a vehicle history session for the particular vehicle (i.e. initiating sessions with historical information for the vehicle) (Penilla: Col. 17 Lines 1-12 “FIG. 6 illustrates an example of utilizing a profile of the user, to access cloud services 120, and a database 115, in accordance with one embodiment of the present invention. In this example, a user may utilize a connected device 110 to access cloud services 120. Using the connected device 110, the user, in this case Bob, is accessing his universal profile settings. His profile settings may include settings that have been selected before in earlier sessions, or default settings implemented by a vehicle manufacturer, or another user such as an administrator. In the example, the user may access particular active settings managed by cloud services 120 which can cause Bob's profile in database 115 to be updated.” Furthermore, as cited in Col. 12 Lines 27-40 “The user profile may contain settings, such as selections of the user interface components associated with the system of the vehicle, as well as user interface is provided by third-party applications. In addition, the user profile can contain and store settings provided by the user. The settings provided by the user, as mentioned is this disclosure can also be learned settings based on use. The settings can further include remote access settings, as well as settings allow the user to control vehicle components from a remote location or a remote computer. The setting can also include providing access to the user account to view historical driving patterns, recent driving activities, the performance of the vehicle during specific driving sessions, the performance of specific vehicle components, etc.”);
performing, during performance of the vehicle history session, a first user-requested action of the vehicle history session, wherein performing the first user-requested action includes the computing system transmitting at least a first vehicle data message (VDM) to the particular vehicle and receiving at least a second VDM from the particular vehicle in response to at least the first VDM (i.e. receiving inputs during session and transmitting data in response to the inputs) (Penilla: Col. 19 Lines 47-55 “In operation 372, the settings that are made by the user when in the vehicle or adjustment settings can be sent back to the user profile. Thus, when the user offering the vehicle and making changes to his or her profile, those changes can also be communicated back to the profile database in cloud services 120. This provides for a continuous feedback loop over time, to allow the users profile settings to be managed and maintained current to the users best liked preferences. The operation then proceeds to B in FIG. 9B.” Furthermore, as cited in Col. 24 Lines 12-30 “FIG. 13A describes how vehicle on board computer with input output system 1900 useful for accepting input, processing input and displaying results in conjunction with stored computer readable programs or functions in the forms of APPs 104 may be structured. Although system 1900 describes one way to provide vehicle on board computing power to run APPs 104, the arrangement of the vehicle computer 1906 may be altered or arranged in differing fashions with differing connection routing in order to achieve the same. In this example, vehicle on board computer 1906 may be comprised of components such as the network interface 1910, memory 1912, a central processing unit 1914, an input output buffer useful for streaming data 1916, storage 1908 having the ability to store computer data in long term or short term fashion useful for stored computer code procedures in the form of an operating system 129, intermediary stored procedure code in the form of APis 130, stored subsets of computer code procedures APPs 104 interacting with API 130 as an intermediary to the operating system 129.”);
receiving, at the computing system […], broadcast vehicle data message sent by the particular vehicle automatically rather than in response to user-requested action (i.e. receiving broadcast vehicle data or pairing request sent by particular vehicle automatically) (Penilla: Col. 17 Lines 57-65 “The pairing request may be automatically sent by the users device to cloud services 120. The pairing request can include sending the model of the vehicle 200, that may have been obtained by the users mobile device from the vehicle 200 directly. In the illustrated example, the pairing request by the users mobile device can include identification of the vehicle that the user has come in close proximity to. A pairing module 170, can then communicate with a mapping engine 118 that determines information associated with car 200.” Furthermore, as cited in Col. 18 Lines 49-60 “In this example, Bob is identified to be proximate to the car having an ID 1528ABC. In one embodiment, when the user comes in proximity to the car 200, the car can beep or light up when enabled, it can open the doors to allow the user to access the vehicle when the logic has paired the user to the vehicle, the profile of the user can be transferred to the vehicle, the use of the vehicle is managed by the user's online account (storing historical use data and any billing information), automatic payment for use can be made from predefined payment arrangements stored in the profile, and use of the vehicle can be restricted to predefined rules, based on the profile.”);
determining, by the computing system, an action identifier corresponding to the first user-requested action, a time stamp corresponding to the first user-requested action, and first details corresponding to a performance of the first user-requested action (i.e. determining action identifier and time stamp or identifiers associated with past actions and time, first details corresponding to performance of action such as how many times action was taken and for how long) (Penilla: Col. 31 Lines 12-22 “Past actions 2210 are logged into a database either locally on the vehicle computer or remotely which are fed into to module 2216. In this example, data about when the user's actions are stored, along with unique identifiers that will allow assumptions to be made in the future. These identifiers include times, dates, rates, capacities, temperatures, frequency, degrees, distance, etc. In this example, the system has been keeping track of when the user has been starting his or her engine in the morning on weekday sand weekends. The system harvests all data points associated with given events.” Furthermore, as cited in Col. 32 Lines 12-23 “The metadata can include identification of when the action was taken, can include counters to identify how many times actions were taken, date parameters for when actions are taken, durations of actions, frequency of actions, time of day, user identification, and other metrics. For example, inaction can be turning on the heater in the vehicle. The metadata can identify the frequency of when the heaters turned on, patterns for turning on the heater, settings for the heater, time of day, time of year, metrics associated with external conditions measured when the heater was activated (weather), etc.”);
generating, within a non-transitory memory, a file for storing a report regarding the vehicle history session (i.e. generating, within memory/server, a report regarding vehicle performance) (Penilla: Cols. 19-20 Lines 64-6 “In operation 378, a report sent back to the server regarding the use of the vehicle and the charges to the users account for the use. In one embodiment, the use reporting can occur continuously while the user is driving vehicle. In operation 380, the drivers session log can be saved user profile, keeping a history of the user's travels. In operation 382, survey data can be requested of the user regarding the vehicle use. Because the user was utilizing a shared vehicle, feedback from the user can be helpful to potential future users that may want to rent or utilize vehicles from the same company.”);
storing, within the report, report inputs regarding the first user-requested action without storing the broadcast vehicle data message sent by the particular vehicle automatically rather than in response to user-requested actions (i.e. storing the report associated with user session and corresponding actions without storing the pairing request or beep/alarm emitted by vehicle) (Penilla: Cols. 19-20 Lines 64-6 “In operation 378, a report sent back to the server regarding the use of the vehicle and the charges to the users account for the use. In one embodiment, the use reporting can occur continuously while the user is driving vehicle. In operation 380, the drivers session log can be saved user profile, keeping a history of the user's travels. In operation 382, survey data can be requested of the user regarding the vehicle use. Because the user was utilizing a shared vehicle, feedback from the user can be helpful to potential future users that may want to rent or utilize vehicles from the same company.”); and
displaying, on a display, a graphical user interface to show at least a portion of the report for assessing how the particular vehicle has performed (i.e. displaying, via GUI, report for events/incidents or how the vehicle performed) (Penilla: Col. 26 Lines 38-48 “Some of the inputs and results 2102 that an APP can take and produce locally or remotely include but are not limited to the set 2104 that can receive an action, react to an action, control an action, manipulate data models, report changes to a view or GUI, record events or incidents, learn the types of requests being submitted, learn the times of request being submitted over time, learn the days of the year the requests are being submitted over time, generalize and interpret requests, assume user intent in order to automatically invoke changes, automatically and pre-emptively act on behalf of a user, fine tune learned user behavior etc.”).
Penilla does not explicitly disclose receiving, at the computing system during the performance of the vehicle history session, broadcast vehicle data message sent by the particular vehicle automatically rather than in response to user-requested action.
However, Lesesky further discloses receiving, at the computing system during the performance of the vehicle history session, broadcast vehicle data message sent by the particular vehicle automatically rather than in response to user-requested action (i.e. receiving broadcasted HOS compliance status during performance automatically rather than by the driver) (Lesesky: Col. 16 Lines 11-22 “Device 800 can be powered from a law enforcement officer's vehicle (such as plugged into a cigarette lighter), or battery, and can be a handheld device that is used to monitor passing and nearby vehicles for HOS compliance status. Recorder 200 can have a short range RF transmitter which broadcasts the driver's HOS compliance status, electronic vehicle license plate, drivers risk factor based on past records, etc. The receiver can be an RF receiver distributed to state, local, and federal authorities providing snapshot monitoring of the status of drivers (HOS compliant or non-compliant), high risk drivers and vehicles at toll gates and border crossings.”).
Therefore, it would have been obvious to one of ordinary skill in the art, at the time the invention was made, to add Lesesky’s receiving, at the computing system during the performance of the vehicle history session, broadcast vehicle data message sent by the particular vehicle automatically rather than in response to user-requested action to Penilla’s displaying, on a display, a graphical user interface to show at least a portion of the report for assessing how the particular vehicle has performed. One of ordinary skill in the art would have been motivated to do so in order “for diagnosing and managing vehicle faults.” (Lesesky: Col. 21 Lines 47-62).
With respect to Claims 11 and 20:
All limitations as recited have been analyzed and rejected to claim 1. Claim 11 recites “A computing system comprising: one or more processors; and a non-transitory computer-readable memory containing executable instructions, wherein execution of the executable instructions by the one or more processors causes the computing system to perform functions comprising:” (Penilla: Col. 36 Lines 25-42) the steps of method claim 1. Claim 20 recites “A non-transitory computer readable memory having stored therein instructions executable by one or more processors to cause a computing system to perform functions comprising:” (Penilla: Col. 36 Lines 25-42) the steps of method claim 1. Claims 11 and 20 do not teach or define any new limitations beyond claim 1. Therefore they are rejected under the same rationale.
With respect to Claim 2:
Penilla teaches:
The method of claim 1, further comprising: transmitting, by the computing system to the particular vehicle, one or more VDMs to perform a scan of the particular vehicle (i.e. transmitting diagnostic request to the sensors of the particular vehicle to perform scan) (Penilla: Col. 24 Lines 52-57 “All data streams generated by APPs 104 stored on the vehicle's computer may also be triggered by wired devices such as vehicle sensors 1918, vehicle electrical systems 1920, vehicle electrical systems 1922, engine control systems 1924, vehicle diagnostics systems 1926, user input as well as environmental input.”);
determining, at the computing system, electronic control units (ECUs) disposed within the particular vehicle based on data the computing system receives from the particular vehicle during the scan of the particular vehicle (i.e. determining triggered routines or functions of the vehicle’s api system based on diagnostic scan) (Penilla: Col. 23 Lines 23-60 “FIG. 12 describes a system in which a user interacts with a model view controller software environment 1800 useful for processing APPS using APis 130 on vehicles with vehicle operating systems 129 capable of processing computer code. The APPS can execute profile retrieval, updates, and sync operations. The model view controller paradigm 1800 shows basic interaction, control, processing, and updating of data useful for manipulating and viewing resulting actions by to vehicle running an APP in such a system. Such a system useful for running APPS on vehicle operating systems will accept inputs by a user 121, cloud services 120 via data streams, vehicle systems feedback and data streams 1812 used by a controller 1804 that may constantly poll electrical, capacitive and physical sensors, and input streams to detect if interactions 1808 such as network passive updates, network active updates, user touch, user speech, user input, user selection among others has been triggered. Each input 1804 will then trigger manipulation of the system's model 1802 portion of the APP software paradigm thus invoking stored routines within APPS 104 which then in turn interact with the vehicle's API system 130 built upon the vehicle's operating system 129. Depending on the app presented to the user 121, the input may trigger stored routines or functions on APP software or operating system level restricted stored routines or functions. After the processing of stored procedure code is manipulated with arguments provided by the controller 1804 inputs, visual and or sensory results are presented to the user in the view 1806 portion of the model view controller paradigm. These sensory outputs, data streams, electrical signals may all be translated as additional options, results, dynamic updating, audio or visual graphical user interface changes 1810 on any of the user's connected display devices. The user will notice these results visually or audibly but may also feel or detect changes in the vehicle's mechanical systems. Updates from the model 1802 may also be used to toggle vehicle settings 1814 which in turn may invoke changes in the vehicle's physical, mechanical and electrical systems 128.”);
receiving, at the computing system, a selection of a set of ECUs, wherein the set of ECUs includes some or all of the ECUs determined to be disposed within the particular vehicle (i.e. receiving selection of triggered routines or functions of the vehicle’s api system) (Penilla: Col. 23 Lines 23-60 “FIG. 12 describes a system in which a user interacts with a model view controller software environment 1800 useful for processing APPS using APis 130 on vehicles with vehicle operating systems 129 capable of processing computer code. The APPS can execute profile retrieval, updates, and sync operations. The model view controller paradigm 1800 shows basic interaction, control, processing, and updating of data useful for manipulating and viewing resulting actions by to vehicle running an APP in such a system. Such a system useful for running APPS on vehicle operating systems will accept inputs by a user 121, cloud services 120 via data streams, vehicle systems feedback and data streams 1812 used by a controller 1804 that may constantly poll electrical, capacitive and physical sensors, and input streams to detect if interactions 1808 such as network passive updates, network active updates, user touch, user speech, user input, user selection among others has been triggered. Each input 1804 will then trigger manipulation of the system's model 1802 portion of the APP software paradigm thus invoking stored routines within APPS 104 which then in turn interact with the vehicle's API system 130 built upon the vehicle's operating system 129. Depending on the app presented to the user 121, the input may trigger stored routines or functions on APP software or operating system level restricted stored routines or functions. After the processing of stored procedure code is manipulated with arguments provided by the controller 1804 inputs, visual and or sensory results are presented to the user in the view 1806 portion of the model view controller paradigm. These sensory outputs, data streams, electrical signals may all be translated as additional options, results, dynamic updating, audio or visual graphical user interface changes 1810 on any of the user's connected display devices. The user will notice these results visually or audibly but may also feel or detect changes in the vehicle's mechanical systems. Updates from the model 1802 may also be used to toggle vehicle settings 1814 which in turn may invoke changes in the vehicle's physical, mechanical and electrical systems 128.”); and
transmitting, by the computing system, vehicle data messages to the set of ECUs as part of additional actions of the vehicle history session (i.e. transmitting vehicle data as recommended actions such as manipulating vehicle HVAC system) (Penilla: Col. 25 Lines 10-28 “FIG. 13B describes one example of how stored data and function declarations may be compiled to provided intermediary access to a vehicle's computer controlling vehicle systems 1950. Such routines, data and functions may be arranged in such a way that limited access is given to third party code on APPs 104 to manipulate certain unrestricted operating system functions and vehicle systems. Such a method of providing the intermediary allowed stored function set to third party code can be referred to as an API 130. In this example of an API 130, computer readable code is arranged in such a fashion that the type of API is described and in this case, an API that allows third party control of the vehicle's HAVC system is declared. A declaration may be useful for reserving the vehicle's computer long term and short-term memory in order to run stored procedures. The shown declaration 1954 describes an example set of data that may reference memory locations and their contents. The contents of these memory location may be modified by stored procedures 1956 or functions.”).
With respect to Claim 12:
All limitations as recited have been analyzed and rejected to claim 2. Claim 12 does not teach or define any new limitations beyond claim 2. Therefore it is rejected under the same rationale.
With respect to Claim 3:
Penilla does not explicitly disclose the method of claim 2, further comprising: determining, at the computing system based on the data the computing system receives from the particular vehicle during the scan of the particular vehicle, any diagnostic trouble codes set within the ECUs disposed within the particular vehicle; and storing, within the non-transitory memory, data regarding the diagnostic trouble codes set within the ECUs disposed within the particular vehicle.
However, Lesesky further discloses:
determining, at the computing system based on the data the computing system receives from the particular vehicle during the scan of the particular vehicle, any diagnostic trouble codes set within the ECUs disposed within the particular vehicle (i.e. determining diagnostic fault codes based on vehicle data during scan or bump data transfer) (Lesesky: Col. 20 Lines 39-49 “The driver then uses the Mobile Device 910, as indicated at 925 in FIG. 11, to capture vehicle data communicated via NFC/RFID transmission (e.g., using "bump data transfer") from the data communications adapter 902 connected to the vehicle data bus 903. The vehicle data may comprise, for example, current fuel level, mileage, trailer identification, engine VIN, engine oil level, oil analysis, and diagnostic fault codes. As shown in FIG. 10, after capturing the vehicle data, the driver carries the Mobile Device 910 to a fuel control terminal "P" located at the fuel pump of station "S".” Furthermore, as cited in Col. 22 Lines 4-13 “After receiving the diagnostic data transmitted by the adapter, the !BUTTON® device can be conveniently carried by the driver or other user to any remote terminal location ( e.g., corporate office, vehicle parts store, vehicle service facility), and the diagnostic data transferred to the remote terminal to process the vehicle fault codes. The vehicle faults may also be transmitted from the !BUTTON® device directly to the vehicle's EOBR via NFC bump data transfer or other communication means.”); and
storing, within the non-transitory memory, data regarding the diagnostic trouble codes set within the ECUs disposed within the particular vehicle (i.e. storing the vehicle fault codes via terminal/memory) (Lesesky: Col. 20 Lines 39-49 “The driver then uses the Mobile Device 910, as indicated at 925 in FIG. 11, to capture vehicle data communicated via NFC/RFID transmission (e.g., using "bump data transfer") from the data communications adapter 902 connected to the vehicle data bus 903. The vehicle data may comprise, for example, current fuel level, mileage, trailer identification, engine VIN, engine oil level, oil analysis, and diagnostic fault codes. As shown in FIG. 10, after capturing the vehicle data, the driver carries the Mobile Device 910 to a fuel control terminal "P" located at the fuel pump of station "S".” Furthermore, as cited in Col. 22 Lines 4-13 “After receiving the diagnostic data transmitted by the adapter, the !BUTTON® device can be conveniently carried by the driver or other user to any remote terminal location ( e.g., corporate office, vehicle parts store, vehicle service facility), and the diagnostic data transferred to the remote terminal to process the vehicle fault codes. The vehicle faults may also be transmitted from the !BUTTON® device directly to the vehicle's EOBR via NFC bump data transfer or other communication means.”).
Therefore, it would have been obvious to one of ordinary skill in the art, at the time the invention was made, to add Lesesky’s determining, at the computing system based on the data the computing system receives from the particular vehicle during the scan of the particular vehicle, any diagnostic trouble codes set within the ECUs disposed within the particular vehicle; and storing, within the non-transitory memory, data regarding the diagnostic trouble codes set within the ECUs disposed within the particular vehicle to Penilla’s displaying, on a display, a graphical user interface to show at least a portion of the report for assessing how the particular vehicle has performed. One of ordinary skill in the art would have been motivated to do so in order “for diagnosing and managing vehicle faults.” (Lesesky: Col. 21 Lines 47-62).
With respect to Claim 13:
All limitations as recited have been analyzed and rejected to claim 3. Claim 13 does not teach or define any new limitations beyond claim 3. Therefore it is rejected under the same rationale.
With respect to Claim 4:
Penilla teaches:
The method of claim 2, wherein: the one or more VDMs to scan the particular vehicle include a first vehicle data message (VDM) arranged according to a first VDM protocol and a first VDM arranged according to a second VDM protocol different than the first VDM protocol (i.e. vehicle data messages are arranged or received via wireless protocol such as retrieving data via remote server or wired communication protocol such as receiving data via sensors or vehicle computer) (Penilla: Col. 24 Lines 12-57 “FIG. 13A describes how vehicle on board computer with input output system 1900 useful for accepting input, processing input and displaying results in conjunction with stored computer readable programs or functions in the forms of APPs 104 may be structured. Although system 1900 describes one way to provide vehicle on board computing power to run APPs 104, the arrangement of the vehicle computer 1906 may be altered or arranged in differing fashions with differing connection routing in order to achieve the same. In this example, vehicle on board computer 1906 may be comprised of components such as the network interface 1910, memory 1912, a central processing unit 1914, an input output buffer useful for streaming data 1916, storage 1908 having the ability to store computer data in long term or short term fashion useful for stored computer code procedures in the form of an operating system 129, intermediary stored procedure code in the form of APis 130, stored subsets of computer code procedures APPs 104 interacting with API 130 as an intermediary to the operating system 129. In this example, the vehicle computer 1906 has the ability to transmit, receive and process information using wired or wireless connections. One such wireless connection is provided by a wireless data sending and receiving antenna 1928 connected to a network interface 1910 useful for pairing with and communicating data with portable or stationary wireless devices which may or may not be part of a network 1902. Such wireless devices include but are not limited to wireless displays 210b, portable smart phones 210a, portable computers, 210c and even stationary objects, structures, buildings, toll bridges, other vehicles etc. The vehicle's network interface 1910 through antenna 1928 may also communicate with cloud services 120 to receive instructions from a remote location that invokes stored programs such as APPs 104 on the vehicle's computer. The vehicle may also send and receive data wirelessly in order to establish a connection with a peer-to-peer ad-hoc network. Invocations may result in output data streams interpreted by wireless devices 210b, 210a, 210c as well as wired devices such as wired displays 210d or vehicle integrated display devices such as windshield heads up projected display or integrated glass displays 210e. All data streams generated by APPs 104 stored on the vehicle's computer may also be triggered by wired devices such as vehicle sensors 1918, vehicle electrical systems 1920, vehicle electrical systems 1922, engine control systems 1924, vehicle diagnostics systems 1926, user input as well as environmental input.”),
the VDMs received during the scan of the particular vehicle include a second VDM arranged according to the first VDM protocol and a second VDM arranged according to the second VDM protocol (i.e. vehicle data messages are arranged or received via wireless protocol such as retrieving data via remote server or wired communication protocol such as receiving data via sensors or vehicle computer) (Penilla: Col. 24 Lines 12-57 “FIG. 13A describes how vehicle on board computer with input output system 1900 useful for accepting input, processing input and displaying results in conjunction with stored computer readable programs or functions in the forms of APPs 104 may be structured. Although system 1900 describes one way to provide vehicle on board computing power to run APPs 104, the arrangement of the vehicle computer 1906 may be altered or arranged in differing fashions with differing connection routing in order to achieve the same. In this example, vehicle on board computer 1906 may be comprised of components such as the network interface 1910, memory 1912, a central processing unit 1914, an input output buffer useful for streaming data 1916, storage 1908 having the ability to store computer data in long term or short term fashion useful for stored computer code procedures in the form of an operating system 129, intermediary stored procedure code in the form of APis 130, stored subsets of computer code procedures APPs 104 interacting with API 130 as an intermediary to the operating system 129. In this example, the vehicle computer 1906 has the ability to transmit, receive and process information using wired or wireless connections. One such wireless connection is provided by a wireless data sending and receiving antenna 1928 connected to a network interface 1910 useful for pairing with and communicating data with portable or stationary wireless devices which may or may not be part of a network 1902. Such wireless devices include but are not limited to wireless displays 210b, portable smart phones 210a, portable computers, 210c and even stationary objects, structures, buildings, toll bridges, other vehicles etc. The vehicle's network interface 1910 through antenna 1928 may also communicate with cloud services 120 to receive instructions from a remote location that invokes stored programs such as APPs 104 on the vehicle's computer. The vehicle may also send and receive data wirelessly in order to establish a connection with a peer-to-peer ad-hoc network. Invocations may result in output data streams interpreted by wireless devices 210b, 210a, 210c as well as wired devices such as wired displays 210d or vehicle integrated display devices such as windshield heads up projected display or integrated glass displays 210e. All data streams generated by APPs 104 stored on the vehicle's computer may also be triggered by wired devices such as vehicle sensors 1918, vehicle electrical systems 1920, vehicle electrical systems 1922, engine control systems 1924, vehicle diagnostics systems 1926, user input as well as environmental input.”), and
determining the electronic control units disposed within the particular vehicle includes determining a first electronic control unit that communicates according to the first VDM protocol and a second electronic control unit that communicates according to the second VDM protocol (i.e. determining a declaration of which procedure to run such as determining if the vehicle’s HVAC system is declared or another electronic control unit and to communicate the VDM according to the declared procedure or protocol) (Penilla: Col. 25 Lines 10-28 “FIG. 13B describes one example of how stored data and function declarations may be compiled to provided intermediary access to a vehicle's computer controlling vehicle systems 1950. Such routines, data and functions may be arranged in such a way that limited access is given to third party code on APPs 104 to manipulate certain unrestricted operating system functions and vehicle systems. Such a method of providing the intermediary allowed stored function set to third party code can be referred to as an API 130. In this example of an API 130, computer readable code is arranged in such a fashion that the type of API is described and in this case, an API that allows third party control of the vehicle's HAVC system is declared. A declaration may be useful for reserving the vehicle's computer long term and short-term memory in order to run stored procedures. The shown declaration 1954 describes an example set of data that may reference memory locations and their contents. The contents of these memory location may be modified by stored procedures 1956 or functions.”).
With respect to Claim 14:
All limitations as recited have been analyzed and rejected to claim 4. Claim 14 does not teach or define any new limitations beyond claim 4. Therefore it is rejected under the same rationale.
With respect to Claim 5:
Penilla teaches:
The method of claim 1, wherein the non-transitory memory is local to a server remote from the computing system (i.e. cloud services is local to the server remote from the computing system) (Penilla: Col. 19 Lines 12-24 “Cloud services can also maintain a vehicle inventory database 310 for the shared vehicle network. Servers 350, which operate cloud services 120, and therefore managing access database 160 and 310, as well as provide logic for providing access to vehicles, unlocking vehicles, and transferring user profiles to specific vehicles. In operation 360, the servers 350 may receive a request to locate a vehicle on a map from a computing device. The request may be provided with reference to the user's current location, using GPS or the like. The request is then processed by servers 350, and servers 350 communicate the forward a list of available vehicles proximate to the user or for the users identified area in operation 362.” Furthermore, as cited in Col. 9 Lines 9-18 “The user's electronics can include, for example mobile devices that include smartphones, tablet computers, laptop computers, general-purpose computers, special purpose computers, etc. The various computing devices of the vehicle, and or the computing devices of