DETAILED ACTION
Response to Amendment
This action is in response to the response to the amendment filed on 04/16/2026. Claims 1-4, 7, 8, 10-14, 17, 18, and 20 have been amended. Claims 1-20 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 .
Inventorship
This application currently names joint inventors. In considering patentability of the claims under pre-AIA 35 U.S.C. 103(a), the examiner presumes that the subject matter of the various claims was commonly owned at the time any inventions covered therein were made absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and invention dates of each claim that was not commonly owned at the time a later invention was made in order for the examiner to consider the applicability of pre-AIA 35 U.S.C. 103(c) and potential pre-AIA 35 U.S.C. 102(e), (f) or (g) prior art under pre-AIA 35 U.S.C. 103(a).
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 communication interface of the computing system is connected to a vehicle…by receiving data electrically, and wherein the data received comprise a vehicle data message or the data indicate a user-selectable control was selected; initiating a vehicle history session in response to determining the vehicle communication interface is connected to the vehicle; determining a vehicle identifier corresponding to the vehicle is valid and responsively adding the vehicle identifier to the report; performing, after determining the vehicle identifier is valid and 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) to the vehicle and receiving at least a second VDM from the vehicle in response to at least the first VDM; receiving, during the performance of the vehicle history session, broadcast vehicle data messages sent in the vehicle automatically rather than in response to a 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; storing, within the report, report inputs regarding the first user-requested action without storing the broadcast vehicle data messages sent by the vehicle automatically; and displaying, on a display, to show at least a portion of the report for assessing how the 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 “by a processor of a computing system; by the vehicle over the wired network; from user interface / a graphical user interface; and wherein connection of the vehicle communication interface to the vehicle occurs at an onboard diagnostic connector within the vehicle, the onboard diagnostic connector being connected to a wired network within the vehicle, wherein the processor determines the vehicle communication interface is connected to the vehicle by receiving data electrically from the vehicle communication interface or from a user interface of the computing system; wherein initiating the vehicle history session includes generating a file within a non-transitory memory for storing a report regarding the vehicle history session.” 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. if interface is connected to vehicle by receiving data electrically), initiating a sessions (i.e. vehicle history session), determining data (i.e. vehicle identifier), performing user-requesting action comprising 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), 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 “by a processor of a computing system; by the vehicle over the wired network; from user interface / a graphical user interface; and wherein connection of the vehicle communication interface to the vehicle occurs at an onboard diagnostic connector within the vehicle, the onboard diagnostic connector being connected to a wired network within the vehicle, wherein the processor determines the vehicle communication interface is connected to the vehicle by receiving data electrically from the vehicle communication interface or from a user interface of the computing system; wherein initiating the vehicle history session includes generating a file within a non-transitory memory for storing a report regarding the vehicle history session.” The limitations reciting – “by a processor of a computing system; by the vehicle over the wired network; from user interface / 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. processor/computing system/vehicle/network/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 “by a processor of a computing system; by the vehicle over the wired network; from user interface / a graphical user interface; and wherein connection of the vehicle communication interface to the vehicle occurs at an onboard diagnostic connector within the vehicle, the onboard diagnostic connector being connected to a wired network within the vehicle, wherein the processor determines the vehicle communication interface is connected to the vehicle by receiving data electrically from the vehicle communication interface or from a user interface of the computing system; wherein initiating the vehicle history session includes generating a file within a non-transitory memory for storing a report regarding the vehicle history session.” The limitations reciting – “by a processor of a computing system; by the vehicle over the wired network; from user interface / 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 also recite additional limitations including “wherein connection of the vehicle communication interface to the vehicle occurs at an onboard diagnostic connector within the vehicle, the onboard diagnostic connector being connected to a wired network within the vehicle, wherein the processor determines the vehicle communication interface is connected to the vehicle by receiving data electrically from the vehicle communication interface or from a user interface of the computing system; wherein initiating the vehicle history session includes generating a file within a non-transitory memory for storing a report regarding the vehicle history session.” Merely receiving and transmitting data between the onboard diagnostic connector to the vehicle interface over a network and storing data in memory is seen as a computer function that is well-understood, routine, and conventional. For example, the courts have noted that “Receiving or transmitting data over a network, e.g., using the Internet to gather data” is seen as a computer function that is well-understood, routine, and conventional (See: Symantec, 838 F.3d at 1321, 120 USPQ2d at 1362 (utilizing an intermediary computer to forward information); TLI Communications LLC v. AV Auto. LLC, 823 F.3d 607, 610, 118 USPQ2d 1744, 1745 (Fed. Cir. 2016) (using a telephone for image transmission); OIP Techs., Inc., v. Amazon.com, Inc., 788 F.3d 1359, 1363, 115 USPQ2d 1090, 1093 (Fed. Cir. 2015) (sending messages over a network); buySAFE, Inc. v. Google, Inc., 765 F.3d 1350, 1355, 112 USPQ2d 1093, 1096 (Fed. Cir. 2014) (computer receives and sends information over a network); but see DDR Holdings, LLC v. Hotels.com, L.P., 773 F.3d 1245, 1258, 113 USPQ2d 1097, 1106 (Fed. Cir. 2014) ("Unlike the claims in Ultramercial, the claims at issue here specify how interactions with the Internet are manipulated to yield a desired result‐‐a result that overrides the routine and conventional sequence of events ordinarily triggered by the click of a hyperlink." (emphasis added)). The courts have also noted that “Storing and retrieving information in memory” (See: Versata Dev. Group, Inc. v. SAP Am., Inc., 793 F.3d 1306, 1334, 115 USPQ2d 1681, 1701 (Fed. Cir. 2015); OIP Techs., 788 F.3d at 1363, 115 USPQ2d at 1092-93). Furthermore, U.S. Publication 2015/0375695 to Grimm further discloses using an onboard diagnostic connector to transmit messages over the network is also a computer function that is well-understood, routine, and conventional (See: ¶¶ [0006] [0007] 0016]). 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, by a processor of a computing system, a vehicle communication interface of the computing system is connected to a vehicle (i.e. determining pairing request which indicates interface is connected to vehicle) (Penilla: Col. 17 Lines 42-65 “Users wishing to find a vehicle to use can access an application or website having access to an Internet connected application to find the vehicle closest to the particular user. Once the user has located a proximate vehicle, such as car 200, the user may approach the vehicle so as to utilize the vehicle 200. In one embodiment, when the user approaches the vehicle, and comes in close proximity to the vehicle as detected by the geo-location of the users mobile device, a pairing request can be detected. The pairing request may be triggered once the proximity zone of the car 200 and the proximity zone of the user substantially or partially overlap. The proximity zone's may overlap when the user comes in close proximity to the vehicle, such as within a few feet, within a mile, or the user has touched or bumped the vehicle. 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.”),
wherein connection of the vehicle communication interface to the vehicle occurs at an onboard diagnostic connector within the vehicle, the onboard diagnostic connector being connected to a wired network within the vehicle (i.e. interface allows communication between vehicle diagnostics via network connection) (Penilla: Col. 24 Lines 46-57 “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.”),
wherein the processor determines the vehicle communication interface is connected to the vehicle by receiving data electrically from the vehicle communication interface or from a user interface of the computing system (i.e. processor determines that pair request has been initiated/completed in order to establish connection between interface and vehicle) (Penilla: Col. 18 Lines 12-23 “The mapping engine 118 will the transfer Bob's profile to vehicle 200. At this point, the user, Bob, can be provided with an interface on a mobile device to allow access to the vehicle. The user interface can include a plurality of screens with instructions, check information, cost information, billing information, etc. As illustrated in FIG. 7, the users mobile device can provide various notifications, such as identifying to the user that the user standing next to a blue model M7 from maker C. The user interface can ask Bob if Bob wishes to pair settings to the specific vehicle 200. If Bob desires to actually utilize the shared vehicle 200, the pairing request may be initiated as mentioned above.” Furthermore, as cited in Cols. 22-23 Lines 63-22 “In one embodiment, user interfaces of a mobile device can share data with the vehicle's display and native apps. App unification allows EV system to display APPS on the user's smartphone device in an opt-in PAIR mode. In one embodiment, this allows one person to enter another's EV, share apps on the EV display while in the EV, and when the person leaves the EV, the Apps de-pair. This auto-sync facilitates sharing of data and also allows users to unify their settings across any number of vehicles the user may drive. In one embodiment, the synchronization will enable users to universally transfer settings from portable devices to electronics of a vehicle. In some embodiments, the vehicle that the user wishes to drive is not his vehicle. For instance, the vehicle may be a friend's vehicle, a rented vehicle or a shared vehicle. If the user has programmed settings in his or her device, the settings that are useful for the vehicle will be transferred to the vehicle. Settings can include travel speed restrictions, car seat settings, mirror settings, remote access to home controls (e.g., lighting, garage doors, etc.), radio settings, satellite radio settings, internet settings, etc. In some cases, only some settings are directly transferable. In other embodiments, a database can be accessed to find a translation metric. The translation metric can include mapping tables that allow for settings to be transferred between functions of one vehicle to other vehicles. In one embodiment, vehicle makers can upload their translation metric for each model and the mapping tables can be used to provide the sync operation.”), and
wherein the data received from the vehicle communication interface comprise a vehicle data message or the data from user interface indicate a user-selectable control of the user interface was selected (i.e. user provides opt-in input to establish pair connection) (Penilla: Col. 18 Lines 12-23 “The mapping engine 118 will the transfer Bob's profile to vehicle 200. At this point, the user, Bob, can be provided with an interface on a mobile device to allow access to the vehicle. The user interface can include a plurality of screens with instructions, check information, cost information, billing information, etc. As illustrated in FIG. 7, the users mobile device can provide various notifications, such as identifying to the user that the user standing next to a blue model M7 from maker C. The user interface can ask Bob if Bob wishes to pair settings to the specific vehicle 200. If Bob desires to actually utilize the shared vehicle 200, the pairing request may be initiated as mentioned above.” Furthermore, as cited in Cols. 22-23 Lines 63-22 “In one embodiment, user interfaces of a mobile device can share data with the vehicle's display and native apps. App unification allows EV system to display APPS on the user's smartphone device in an opt-in PAIR mode. In one embodiment, this allows one person to enter another's EV, share apps on the EV display while in the EV, and when the person leaves the EV, the Apps de-pair. This auto-sync facilitates sharing of data and also allows users to unify their settings across any number of vehicles the user may drive. In one embodiment, the synchronization will enable users to universally transfer settings from portable devices to electronics of a vehicle. In some embodiments, the vehicle that the user wishes to drive is not his vehicle. For instance, the vehicle may be a friend's vehicle, a rented vehicle or a shared vehicle. If the user has programmed settings in his or her device, the settings that are useful for the vehicle will be transferred to the vehicle. Settings can include travel speed restrictions, car seat settings, mirror settings, remote access to home controls (e.g., lighting, garage doors, etc.), radio settings, satellite radio settings, internet settings, etc. In some cases, only some settings are directly transferable. In other embodiments, a database can be accessed to find a translation metric. The translation metric can include mapping tables that allow for settings to be transferred between functions of one vehicle to other vehicles. In one embodiment, vehicle makers can upload their translation metric for each model and the mapping tables can be used to provide the sync operation.”);
initiating, by the processor, a vehicle history session in response to determining the vehicle communication interface is connected to the vehicle (i.e. initiating sessions with historical information for the vehicle in response to pairing request being completed) (Penilla: Col. 17 Lines 1-56 “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… Users wishing to find a vehicle to use can access an application or website having access to an Internet connected application to find the vehicle closest to the particular user. Once the user has located a proximate vehicle, such as car 200, the user may approach the vehicle so as to utilize the vehicle 200. In one embodiment, when the user approaches the vehicle, and comes in close proximity to the vehicle as detected by the geo-location of the users mobile device, a pairing request can be detected. The pairing request may be triggered once the proximity zone of the car 200 and the proximity zone of the user substantially or partially overlap. The proximity zone's may overlap when the user comes in close proximity to the vehicle, such as within a few feet, within a mile, or the user has touched or bumped the vehicle.” Furthermore, as cited in Col. 18 Lines 12-23 “The mapping engine 118 will the transfer Bob's profile to vehicle 200. At this point, the user, Bob, can be provided with an interface on a mobile device to allow access to the vehicle. The user interface can include a plurality of screens with instructions, check information, cost information, billing information, etc. As illustrated in FIG. 7, the users mobile device can provide various notifications, such as identifying to the user that the user standing next to a blue model M7 from maker C. The user interface can ask Bob if Bob wishes to pair settings to the specific vehicle 200. If Bob desires to actually utilize the shared vehicle 200, the pairing request may be initiated as mentioned above.” 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.”),
wherein initiating the vehicle history session includes generating a file within a non-transitory memory 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.”);
determining, by the processor, a vehicle identifier corresponding to the vehicle is valid and responsively adding the vehicle identifier to the report (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.”);
performing, after determining the vehicle identifier is valid and 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 processor transmitting at least a first vehicle data message (VDM) to the vehicle and receiving at least a second VDM from the 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, by the processor […], broadcast vehicle data message sent by the vehicle over the wired network in the vehicle automatically rather than in response to a user-requested action (i.e. receiving broadcast vehicle data or pairing request sent by 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 processor, 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.”);
storing, within the report, report inputs regarding the first user-requested action without storing the broadcast vehicle data message sent by the vehicle automatically (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 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, by the processor during the performance of the vehicle history session, broadcast vehicle data message sent by the vehicle over the wired network in the vehicle automatically rather than in response to a user-requested action.
However, Lesesky further discloses receiving, by the processor during the performance of the vehicle history session, broadcast vehicle data message sent by the vehicle over the wired network in the vehicle automatically rather than in response to a 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, by the processor during the performance of the vehicle history session, broadcast vehicle data message sent by the vehicle over the wired network in the vehicle automatically rather than in response to a 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 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 vehicle, one or more VDMs to perform a scan of the vehicle (i.e. transmitting diagnostic request to the sensors of the 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 vehicle based on data the computing system receives from the vehicle during the scan of the 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 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 vehicle during the scan of the vehicle, any diagnostic trouble codes set within the ECUs disposed within the vehicle; and storing, within the non-transitory memory, data regarding the diagnostic trouble codes set within the ECUs disposed within the vehicle.
However, Lesesky further discloses:
determining, at the computing system based on the data the computing system receives from the vehicle during the scan of the vehicle, any diagnostic trouble codes set within the ECUs disposed within the 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 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 vehicle during the scan of the vehicle, any diagnostic trouble codes set within the ECUs disposed within the vehicle; and storing, within the non-transitory memory, data regarding the diagnostic trouble codes set within the ECUs disposed within the 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 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 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 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 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 the user (smart devices) can be connected to the Internet or to each other. Provided that a user has access or account access to the cloud service, the cloud processing services on the Internet can provide additional processing information to the electronics of the vehicle.”).
With respect to Claim 15:
All limitations as recited have been analyzed and rejected to claim 5. Claim 15 does not teach or define any new limitations beyond claim 5. Therefore it is rejected under the same rationale.
With respect to Claim 6:
Penilla teaches:
The method of claim 1, wherein the non-transitory memory is local to the computing system (i.e. cloud services is local to 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 the user (smart devices) can be connected to the Internet or to each other. Provided that a user has access or account access to the cloud service, the cloud processing services on the Internet can provide additional processing information to the electronics of the vehicle.”).
With respect to Claim 16:
All limitations as recited have been analyzed and rejected to claim 6. Claim 16 does not teach or define any new limitations beyond claim 6. Therefore it is rejected under the same rationale.
With respect to Claim 7:
Penilla teaches:
The method of claim 1, further comprising: confirming, at the computing system, the vehicle identifier for the vehicle connected to the computing system comprises a valid vehicle identification number (i.e. confirming vehicle is the correct vehicle having the corresponding identification number) (Penilla: Col. 18 Lines 33-50 “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. Additional data can be supplemented from vehicle manufacturers 212. The cloud services 120, in accordance with one embodiment, can include logic for profile identification for vehicles 224, logic for proximity detection 222, user request logic 220, and other managing logic for receiving request from users, managing databases from a car sharing database, managing data from vehicle manufacturers, and receiving request to manage profiles an axis vehicles. As illustrated, when the user Bob approaches the vehicle 200, the Bob's mobile device 110a can identify the closest car, which may be car A. In this example, Bob is identified to be proximate to the car having an ID 1528ABC.”); and
storing the valid vehicle identification number within the report regarding the vehicle history session (i.e. storing the vehicle identification number in vehicle database) (Penilla: Col. 18 Lines 33-50 “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. Additional data can be supplemented from vehicle manufacturers 212. The cloud services 120, in accordance with one embodiment, can include logic for profile identification for vehicles 224, logic for proximity detection 222, user request logic 220, and other managing logic for receiving request from users, managing databases from a car sharing database, managing data from vehicle manufacturers, and receiving request to manage profiles an axis vehicles. As illustrated, when the user Bob approaches the vehicle 200, the Bob's mobile device 110a can identify the closest car, which may be car A. In this example, Bob is identified to be proximate to the car having an ID 1528ABC.”).
With respect to Claim 17:
All limitations as recited have been analyzed and rejected to claim 7. Claim 17 does not teach or define any new limitations beyond claim 7. Therefore it is rejected under the same rationale.
With respect to Claim 8:
Penilla teaches:
The method of claim 1, wherein initiating the vehicle history session for the vehicle includes the computing system performing one or more of the following steps: (i) transitioning from a state in which the computing system is not waiting for performance of a vehicle history session action to a state in which the computing system is waiting for performance of a vehicle history session action (i.e. configuration state transitions from a turned off state to a turned on state when the user is detected indicating the start of a vehicle session) (Penilla: Cols. 10-11 Lines 59-6 “When the user is not using the vehicle, the custom configuration can be turned off or locked out for another session. Once the user wants to start a new session, the user can log back in and the custom configuration returns. In other embodiments, the custom configuration will automatically turn off when the user is not driving the vehicle or has not logged into the vehicle. In other embodiments, the custom configuration can be automatically turned on when the user is detected. The user can be detected using biometrics, login credentials, image detection of the face, fingerprint detection, retina scans, etc. In some embodiments, biometrics can include data used to identify the user, such as face recognition, fingerprint reading, retina scans, voice detection, or combinations thereof. Still further, the custom configuration can be transferred to other vehicles.”),
(ii) generating the file for storing the report regarding the vehicle history session (i.e. generating a file for storing the report for the vehicle session in the server) (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.”),
(iii) generating an identifier of the vehicle history session for the vehicle (i.e. generating an identifier for the vehicle used for the vehicle session) (Penilla: Col. 18 Lines 33-50 “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. Additional data can be supplemented from vehicle manufacturers 212. The cloud services 120, in accordance with one embodiment, can include logic for profile identification for vehicles 224, logic for proximity detection 222, user request logic 220, and other managing logic for receiving request from users, managing databases from a car sharing database, managing data from vehicle manufacturers, and receiving request to manage profiles an axis vehicles. As illustrated, when the user Bob approaches the vehicle 200, the Bob's mobile device 110a can identify the closest car, which may be car A. In this example, Bob is identified to be proximate to the car having an ID 1528ABC.” Furthermore, as cited in Col. 31 Lines 14-21 “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.”), or
(iii) generating a time stamp indicating when the vehicle history session for the vehicle, was initiated (i.e. generating a record of time for each event or when the vehicle session was initiated) (Penilla: Col. 28 Lines 37-42 “In some embodiment, the meta data of each action includes a record of a time and date of each occurrence and for actions that show a repeating pattern of occurrences will have an increased confidence score. The threshold is predefined to require a set number of occurrences of the actions to occur so that the repeating pattern is identifiable.” Furthermore, as cited in Col. 31 Lines 14-21 “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.”).
With respect to Claim 18:
All limitations as recited have been analyzed and rejected to claim 8. Claim 18 does not teach or define any new limitations beyond claim 8. Therefore it is rejected under the same rationale.
With respect to Claim 9:
Penilla teaches:
The method of claim 1, further comprising: performing, during performance of the vehicle history session, a second action of the vehicle history session, wherein the second action of the vehicle history session occurs automatically without a user request to perform the second action (i.e. automatically displaying information via dashboard of vehicle without user having to request to display information via dashboard) (Penilla: Col. 10 Lines 12-25 “For example, content being displayed in the center panel display of the vehicle, can be automatically shown in the dashboard display region of the vehicle, such as in front of the steering wheel. In still other embodiments, some content or display data can be moved from the center console or the display in front of the steering wheel to the windshield of the vehicle in a heads-up display area. Accordingly, algorithms executed by the applications and applications of the manufacturer, can cooperate to provide functionality to the application features and interfaces, while maintaining safety parameters defined by rules. The safety parameters will therefore allow content of the user interface to be shifted around to various displays of the vehicle, or translated to voice or audio at certain points in time.”).
With respect to Claim 19:
All limitations as recited have been analyzed and rejected to claim 9. Claim 19 does not teach or define any new limitations beyond claim 9. Therefore it is rejected under the same rationale.
With respect to Claim 10:
Penilla teaches:
The method of claim 9, wherein: performing the second action includes the processor transmitting one or more VDMs to request life or trip data from the vehicle and receiving one or more VDMs including life or trip data from the vehicle (i.e. display includes VDM to request trip data and displaying VDM or trip data) (Penilla: Col. 10 Lines 12-25 “For example, content being displayed in the center panel display of the vehicle, can be automatically shown in the dashboard display region of the vehicle, such as in front of the steering wheel. In still other embodiments, some content or display data can be moved from the center console or the display in front of the steering wheel to the windshield of the vehicle in a heads-up display area. Accordingly, algorithms executed by the applications and applications of the manufacturer, can cooperate to provide functionality to the application features and interfaces, while maintaining safety parameters defined by rules. The safety parameters will therefore allow content of the user interface to be shifted around to various displays of the vehicle, or translated to voice or audio at certain points in time.” Furthermore, as cited in Col. 22 Lines 13-19 “This can include settings of the seats, the mirrors, the temperature, the radio stations, and the Internet apps to display on the car's display, etc. Custom information, such as prior uses of the car, cost for driving, etc., can be displayed on the car's display, via the sync data from the user's portable device. The sync data can be obtained at any time, such as by using the user's portable Internet link, etc.”); and
storing, within the file, report inputs including the life or trip data the computing system received from the vehicle in response to transmitting a request for life or trip data (i.e. storing report which includes trip or survey data in response to request for report) (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.”).
Response to Arguments
Applicant’s arguments see pages 18-19 of the Remarks disclosed, filed on 04/16/2026, with respect to the nonstatutory double patenting rejection(s) of claim(s) 1-20 have been considered and are persuasive. The Applicant has stated “As noted above, the Examiner rejected claims 1-20 on the ground of nonstatutory double patenting as allegedly being unpatentable over claims 1-36 of U.S. Patent No. 12,211,009. Without acquiescing in the rejection and to expedite prosecution, Applicant filed a terminal disclaimer on April 16, 2026, with respect to U.S. Patent No. 12,211,009. The terminal disclaimer was approved by the Patent Office. Accordingly, Applicant respectfully requests withdrawal of the nonstatutory double patenting rejection of claims 1-20.” The Examiner agrees and therefore, the nonstatutory double patenting rejection(s) of claim(s) 1-20 has been withdrawn.
Applicant’s arguments see pages 19-23 of the Remarks disclosed, filed on 04/16/2026, with respect to the 35 U.S.C. § 101 rejection(s) of claim(s) 1-20 have been considered but are not persuasive:
The Applicant asserts “These limitations are rooted in vehicle communication technology and diagnostic systems, and cannot practically be performed in the human mind. In particular, the claimed method requires: detecting a connection via a vehicle communication interface and an OBD connector; transmitting and receiving vehicle data messages over a wired vehicle network; and managing different types of vehicle data messages (user-requested vs. broadcast) during a session. Such operations necessarily involve electronic communication with vehicle systems and computer processing, and therefore do not recite a mental process or other judicial exception. Accordingly, claim 1 is not directed to an abstract idea under Step 2A, Prong One.” The Examiner respectfully disagrees. The limitations are not rooted in vehicle communication technology but merely use the diagnostic system to describe the computing environment in which to implement the abstract idea (i.e. receiving/transmitting data of vehicle diagnostics in order to compile a performance report of the vehicle). Furthermore, Claims 1, 11, and 20 recite limitations directed to the abstract idea including “determining a vehicle communication interface of the computing system is connected to a vehicle…by receiving data electrically, and wherein the data received comprise a vehicle data message or the data indicate a user-selectable control was selected; initiating a vehicle history session in response to determining the vehicle communication interface is connected to the vehicle; determining a vehicle identifier corresponding to the vehicle is valid and responsively adding the vehicle identifier to the report; performing, after determining the vehicle identifier is valid and 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) to the vehicle and receiving at least a second VDM from the vehicle in response to at least the first VDM; receiving, during the performance of the vehicle history session, broadcast vehicle data messages sent in the vehicle automatically rather than in response to a 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; storing, within the report, report inputs regarding the first user-requested action without storing the broadcast vehicle data messages sent by the vehicle automatically; and displaying, on a display, to show at least a portion of the report for assessing how the 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 “by a processor of a computing system; by the vehicle over the wired network; from user interface / a graphical user interface; and wherein connection of the vehicle communication interface to the vehicle occurs at an onboard diagnostic connector within the vehicle, the onboard diagnostic connector being connected to a wired network within the vehicle, wherein the processor determines the vehicle communication interface is connected to the vehicle by receiving data electrically from the vehicle communication interface or from a user interface of the computing system; wherein initiating the vehicle history session includes generating a file within a non-transitory memory for storing a report regarding the vehicle history session.” 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. if interface is connected to vehicle by receiving data electrically), initiating a sessions (i.e. vehicle history session), determining data (i.e. vehicle identifier), performing user-requesting action comprising 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), storing data within the report (i.e. report inputs) without storing other data (i.e. broadcast vehicle data), and displaying report for performance.
The Applicant also asserts “Claim 1 requires determining that a vehicle communication interface is connected to a vehicle at an onboard diagnostic connector based on data received electrically from the vehicle communication interface or from a user interface…These limitations provide a technical improvement to vehicle diagnostic systems. In particular: initiating the session based on connection ensures that the session is tied to an actual, connected vehicle; validating the vehicle identifier improves reliability of generated reports; and excluding broadcast vehicle data messages from storage improves data storage efficiency and processing performance. Thus, the claim applies any alleged abstract idea in a meaningful way that is integral to a technological system, and imposes meaningful limits beyond merely linking the alleged abstract idea to a general technological environment.” The Examiner respectfully disagrees. Determining that a vehicle is connected to the network by receiving data electrically, initiating history sessions of the vehicle in response to determining the vehicle communication interface is connected to the vehicle, determining that the vehicle identifier is valid, and excluding data from storage do not impose meaningful limits beyond merely linking the alleged abstract idea to a general technological environment because a person with the necessary information can determine if the vehicle interface is connected by receiving data, can determine if a vehicle identifier is valid, and can also initiate a history a session of a vehicle in response to determining the vehicle communication interface is connected to the vehicle. The “excluding broadcast vehicle data messages from storage” does not improve “data storage efficiency and processing performance” but at most has an ancillary or secondary effect on storage efficiency or processing performance because the claims do not take into account or rely on storage efficiency/processing performance. Furthermore, Claims 1, 11, and 20 recite additional limitations including “by a processor of a computing system; by the vehicle over the wired network; from user interface / a graphical user interface; and wherein connection of the vehicle communication interface to the vehicle occurs at an onboard diagnostic connector within the vehicle, the onboard diagnostic connector being connected to a wired network within the vehicle, wherein the processor determines the vehicle communication interface is connected to the vehicle by receiving data electrically from the vehicle communication interface or from a user interface of the computing system; wherein initiating the vehicle history session includes generating a file within a non-transitory memory for storing a report regarding the vehicle history session.” The limitations reciting – “by a processor of a computing system; by the vehicle over the wired network; from user interface / 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. processor/computing system/vehicle/network/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,).
The Applicant finally asserts “This combination of limitations provides a coordinated and non-conventional approach to vehicle diagnostics that: ensures association of data with a valid vehicle; and improves efficiency of computing systems by reducing unnecessary data storage and processing. The Examiner has not identified any evidence that this ordered combination of features was well-understood, routine, or conventional at the time of the invention. Accordingly, claim 1 recites an inventive concept sufficient to confer patent eligibility. The Examiner respectfully disagrees. The “reducing unnecessary data storage and processing” does not improve “efficiency of computing systems” but at most has an ancillary or secondary effect on storage efficiency or processing performance because the claims do not take into account or rely on storage efficiency/processing performance. Furthermore, Claims 1, 11, and 20 recite additional limitations including “by a processor of a computing system; by the vehicle over the wired network; from user interface / a graphical user interface; and wherein connection of the vehicle communication interface to the vehicle occurs at an onboard diagnostic connector within the vehicle, the onboard diagnostic connector being connected to a wired network within the vehicle, wherein the processor determines the vehicle communication interface is connected to the vehicle by receiving data electrically from the vehicle communication interface or from a user interface of the computing system; wherein initiating the vehicle history session includes generating a file within a non-transitory memory for storing a report regarding the vehicle history session.” The limitations reciting – “by a processor of a computing system; by the vehicle over the wired network; from user interface / 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 also recite additional limitations including “wherein connection of the vehicle communication interface to the vehicle occurs at an onboard diagnostic connector within the vehicle, the onboard diagnostic connector being connected to a wired network within the vehicle, wherein the processor determines the vehicle communication interface is connected to the vehicle by receiving data electrically from the vehicle communication interface or from a user interface of the computing system; wherein initiating the vehicle history session includes generating a file within a non-transitory memory for storing a report regarding the vehicle history session.” Merely receiving and transmitting data between the onboard diagnostic connector to the vehicle interface over a network and storing data in memory is seen as a computer function that is well-understood, routine, and conventional. For example, the courts have noted that “Receiving or transmitting data over a network, e.g., using the Internet to gather data” is seen as a computer function that is well-understood, routine, and conventional (See: Symantec, 838 F.3d at 1321, 120 USPQ2d at 1362 (utilizing an intermediary computer to forward information); TLI Communications LLC v. AV Auto. LLC, 823 F.3d 607, 610, 118 USPQ2d 1744, 1745 (Fed. Cir. 2016) (using a telephone for image transmission); OIP Techs., Inc., v. Amazon.com, Inc., 788 F.3d 1359, 1363, 115 USPQ2d 1090, 1093 (Fed. Cir. 2015) (sending messages over a network); buySAFE, Inc. v. Google, Inc., 765 F.3d 1350, 1355, 112 USPQ2d 1093, 1096 (Fed. Cir. 2014) (computer receives and sends information over a network); but see DDR Holdings, LLC v. Hotels.com, L.P., 773 F.3d 1245, 1258, 113 USPQ2d 1097, 1106 (Fed. Cir. 2014) ("Unlike the claims in Ultramercial, the claims at issue here specify how interactions with the Internet are manipulated to yield a desired result‐‐a result that overrides the routine and conventional sequence of events ordinarily triggered by the click of a hyperlink." (emphasis added)). The courts have also noted that “Storing and retrieving information in memory” (See: Versata Dev. Group, Inc. v. SAP Am., Inc., 793 F.3d 1306, 1334, 115 USPQ2d 1681, 1701 (Fed. Cir. 2015); OIP Techs., 788 F.3d at 1363, 115 USPQ2d at 1092-93). Furthermore, U.S. Publication 2015/0375695 to Grimm further discloses using an onboard diagnostic connector to transmit messages over the network is also a computer function that is well-understood, routine, and conventional (See: ¶¶ [0006] [0007] 0016]). 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. Therefore, the rejection(s) of claim(s) 1-20 under 35 U.S.C. § 101 is maintained above with an updated analysis.
Applicant’s arguments see pages 23-26 of the Remarks disclosed, filed on 04/16/2026, with respect to the 35 U.S.C. § 103 rejection(s) of claim(s) 1-20 over Penilla in view of Lesesky have been considered but are not persuasive. The Applicant asserts “The Examiner cited portions of Penilla referring to "earlier sessions" and "specific driving sessions." However, these disclosures relate to user profiles and historical data, not to initiating a vehicle history session in response to detecting a connection between a vehicle communication interface and a vehicle. At most, Penilla discloses that a user may "start a new session" by logging in. This user-initiated login does not teach or suggest: detecting a physical or electrical connection between a vehicle communication interface and a vehicle, or initiating a vehicle history session in response to such detection, including based on electrical data or user interface input indicating connection. Accordingly, Penilla does not teach or suggest the claimed initiation of a vehicle history session.” The Examiner respectfully disagrees. The Examiner would like to refer the Applicant to Cols. 17-18 Lines 42-23 “Users wishing to find a vehicle to use can access an application or website having access to an Internet connected application to find the vehicle closest to the particular user. Once the user has located a proximate vehicle, such as car 200, the user may approach the vehicle so as to utilize the vehicle 200. In one embodiment, when the user approaches the vehicle, and comes in close proximity to the vehicle as detected by the geo-location of the users mobile device, a pairing request can be detected. The pairing request may be triggered once the proximity zone of the car 200 and the proximity zone of the user substantially or partially overlap. The proximity zone's may overlap when the user comes in close proximity to the vehicle, such as within a few feet, within a mile, or the user has touched or bumped the vehicle. 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… The mapping engine 118 will the transfer Bob's profile to vehicle 200. At this point, the user, Bob, can be provided with an interface on a mobile device to allow access to the vehicle. The user interface can include a plurality of screens with instructions, check information, cost information, billing information, etc. As illustrated in FIG. 7, the users mobile device can provide various notifications, such as identifying to the user that the user standing next to a blue model M7 from maker C. The user interface can ask Bob if Bob wishes to pair settings to the specific vehicle 200. If Bob desires to actually utilize the shared vehicle 200, the pairing request may be initiated as mentioned above.” It is clear from the disclosure above that the Penilla reference teaches starting sessions by user logging in which includes a pair request process in which the pair request detects a physical or electrical connection between a vehicle communication interface and a vehicle. Therefore, the rejection(s) of claim(s) 1-20 under 35 U.S.C. § 103 is provided above with updated citations.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. The following references are cited to further show the state of the art:
U.S. Publication 2018/0232959 to Thornburg for disclosing a central gateway of a vehicle includes a processor and a storage connected to a plurality of vehicle buses. The gateway receives raw data from an electronic control unit (ECU) via one of the vehicle buses, augments the raw data with availability, classification, and context information, publishes the raw data to a publish/subscribe topic hosted to the storage, and subscribes at least a second ECU of the vehicle to the topic. A database of the central gateway is accessed, according to a determined type of raw data received by a central gateway of a vehicle from an electronic control unit (ECU) via a vehicle bus, for augmenting the raw data with availability, classification, and context information. The augmented data is provided to a publish/subscribe topic hosted by the gateway for accessing over a communication network by a service external to the vehicle.
U.S. Publication 2016/0306690 to Underseth for disclosing performing integrated test design, automation, and analysis. Such features could be used to provide efficient test planning, execution, and results analysis for multiple sites. The integrated testing interface may obtain test plan data, provide test configurations to hardware or software test runners, and process results from the testing. The integrated interface provides a full-circle testing platform from requirements collection to design to execution to analysis.
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any extension fee pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Azam Ansari, whose telephone number is (571) 272-7047. The examiner can normally be reached from Monday to Friday between 8 AM and 4:30 PM.
If any attempt to reach the examiner by telephone is unsuccessful, the examiner's supervisor, Waseem Ashraf, can be reached at (571) 270-3948.
Another resource that is available to applicants is the Patent Application Information Retrieval (PAIR). Information regarding the status of an application can be obtained from the (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAX. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pairdirect.uspto.gov. Should you have questions on access to the Private PAIR system, please feel free to contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free).
Applicants are invited to contact the Office to schedule either an in-person or a telephonic interview to discuss and resolve the issues set forth in this Office Action. Although an interview is not required, the Office believes that an interview can be of use to resolve any issues related to a patent application in an efficient and prompt manner.
/AZAM A ANSARI/
Primary Examiner, Art Unit 3621
June 4, 2026
Prosecution Insights