Prosecution Insights
Last updated: July 17, 2026
Application No. 19/191,178

AUTOMOTIVE DATA SHARING AND CONSENT MANAGEMENT PLATFORM

Non-Final OA §103§112
Filed
Apr 28, 2025
Priority
Aug 14, 2020 — provisional 63/065,559 +2 more
Examiner
STRAUB, D'ARCY WINSTON
Art Unit
Tech Center
Assignee
Aiden Automotive Technologies Inc.
OA Round
1 (Non-Final)
77%
Grant Probability
Favorable
1-2
OA Rounds
1y 9m
Est. Remaining
96%
With Interview

Examiner Intelligence

Grants 77% — above average
77%
Career Allowance Rate
176 granted / 228 resolved
+17.2% vs TC avg
Strong +19% interview lift
Without
With
+18.7%
Interview Lift
resolved cases with interview
Typical timeline
2y 11m
Avg Prosecution
26 currently pending
Career history
251
Total Applications
across all art units

Statute-Specific Performance

§101
1.9%
-38.1% vs TC avg
§103
91.9%
+51.9% vs TC avg
§102
2.3%
-37.7% vs TC avg
§112
3.1%
-36.9% vs TC avg
Black line = Tech Center average estimate • Based on career data from 228 resolved cases

Office Action

§103 §112
DETAILED ACTION 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 . This Office Action is responsive to application 19/191,178 that the Applicant filed on April 28, 2025 and presented 20 claims. Original claims 1-20 remain pending in the application. Double Patenting The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969). A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b). The filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13. The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer. Claims 1-3 and 6-14 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-3, 6-9, and 12-16 of U.S. Patent No. 12,314,448. Although the claims at issue are not identical, they are not patentably distinct from each other because the claims overlap in scope as detailed below by the claim-by-claim comparison table. Instant Application US Patent No. 12,314,448 1. An automotive data sharing system, comprising: a cloud system comprising a processor and a memory storing instructions that when executed by the processor cause the processor to: via a consumer portal, receive a request from an entity for requested output data from a vehicle of a plurality of vehicles each coupled to the cloud system and running a data collection application; generate a consent form in response to the received request and based on the requested output data; communicate the consent form to the vehicle via a vehicle user interface of the data collection application; receive an affirmative consent form response or a negative consent form response from the vehicle via the vehicle user interface of the data collection application; and in response to receiving the affirmative consent form response from the vehicle, receive input data from the vehicle at the cloud system and provide the input data from the vehicle to the entity through the cloud system as the requested output data; wherein the input data received from the vehicle at the cloud system and provided to the entity through the cloud system is subject to a specific data element of one or more of the request, the consent form, the affirmative consent form response, and an original equipment manufacturer limitation or term received via an original equipment manufacturer portal. 1. An automotive data sharing system, comprising: a cloud system comprising a processor and a memory storing instructions that when executed by the processor cause the processor to: receive a request from an entity for requested output data from a vehicle of a plurality of vehicles each coupled to the cloud system and running a same data collection application on a same operating system; generate a consent form in response to the received request and based on the requested output data; communicate the consent form to the vehicle via the data collection application; receive an affirmative consent form response or a negative consent form response from the vehicle via the data collection application; and in response to receiving the affirmative consent form response from the vehicle at the cloud system, receive input data from the vehicle at the cloud system and provide the input data from the vehicle to the entity through the cloud system as the requested output data via an application programming interface of the cloud system, wherein the input data received from the vehicle at the cloud system is limited by specific data elements of each of the request, the consent form, and the affirmative consent form response. 2. The automotive data sharing system of claim 1, wherein one or more of: the cloud system is coupled to each of the plurality of vehicles via a wireless two-way communications link; and the cloud system is coupled to the entity via a two-way communications link. 2. The automotive data sharing system of claim 1, wherein one or more of: the cloud system is coupled to each of the plurality of vehicles via a wireless two-way communications link; and the cloud system is coupled to the entity via a two-way communications link. 3. The automotive data sharing system of claim 1, wherein the cloud system is further configured to: in response to receiving the negative consent form response from the vehicle, decline to receive the input data from the vehicle at the cloud system and decline to provide the input data from the vehicle to the entity through the cloud system as the requested output data 3. The automotive data sharing system of claim 1, wherein the cloud system is further configured to: in response to receiving the negative consent form response from the vehicle at the data collection application, decline to receive the input data from the vehicle at the cloud system and decline to provide the input data from the vehicle to the entity through the cloud system as the requested output data via the application programming interface of the cloud system. 6. The automotive data sharing system of claim 1, wherein the consent form is communicated to a user interface of a display of the vehicle via the data collection application. 6. The automotive data sharing system of claim 1, wherein the consent form is communicated to a user interface of a display of the vehicle via the data collection application, and the consent form response is received from the display of the vehicle. 7. The automotive data sharing system of claim 1, wherein the input data is encrypted by the vehicle utilizing the data collection application and subsequently decrypted as the requested output data by one of the cloud system and the entity. 7. The automotive data sharing system of claim 1, wherein the input data is encrypted by the vehicle utilizing the data collection application in response to a request for encryption by the entity and using a public key received from the entity through the cloud system, and the associated output data is subsequently decrypted by the entity using a corresponding private key. 8. The automotive data sharing system of claim 1, wherein the input data is provided as the requested output data periodically or when the input data indicates that an event threshold has been satisfied. 8. The automotive data sharing system of claim 1, wherein the output data is provided at least one of periodically or when the input data indicates an event threshold has been satisfied and based on the request from the entity. 9. The automotive data sharing platform of claim 1, wherein the cloud system is further configured to transmit one or more of a command, a push notification, and a web link from the entity to the vehicle. 9. The automotive data sharing platform of claim 1, wherein the cloud system is configured to transmit one or more of a command, a push notification, and a web link from the entity to the vehicle. 10. The automotive data sharing system of claim 1, wherein the cloud system is further configured to: communicate from the entity, which has been given consent to access the requested output data, to the vehicle a command or user interface notification configured to selectively grant access to the entity to remotely control aspects of operation of the vehicle, to facilitate a two-way communication between the entity and the vehicle, or both. 12. The automotive data sharing system of claim 1, wherein the cloud system is further configured to: communicate from the entity, which has been given consent to access the output data, to the vehicle at least one of a command or user interface notification configured to selectively grant access to the entity to remotely control aspects of the vehicle, to facilitate a two-way communication between the entity and the vehicle, or both. 11. The automotive data sharing system of claim 1, wherein the cloud system is further configured to receive at least one vehicle identification number (VIN) from the entity identifying the vehicle of the plurality of vehicles. 13. The automotive data sharing system of claim 1, wherein the cloud system is further configured to receive at least one vehicle identification number (VIN) from the entity identifying the vehicle of the plurality of vehicles. 12. The automotive data sharing system of claim 1, wherein the cloud system is further configured to: communicate the consent form request to the original equipment manufacturer; and receive approval of the original equipment manufacturer; wherein the requested output data is provided to the entity in response to receiving the approval of the original equipment manufacturer. 14. The automotive data sharing system of claim 1, wherein the cloud system is further configured to: communicate the consent form request to an original equipment manufacturer (OEM) of the vehicle of the plurality of vehicles; receive approval of the OEM; wherein the output data is provided to the entity in response to receiving approval of the entity from the OEM. 13. The automotive data sharing system of claim 1, wherein the consent form include sat least one of a web link or a universal resource locator from the entity, and wherein the consent form is configured to, while being acted upon by the vehicle, display content associated with at least one of the web link or the universal resource locator to an operator of the vehicle. 15. The automotive data sharing system of claim 1, wherein the request and the consent form each include at least one of a web link or a universal resource locator from the entity, and wherein the consent form is configured to, while being acted upon by the vehicle, display content associated with at least one of the web link or the universal resource locator to an associated operator of the vehicle. 14. The automotive data sharing system of claim 1, wherein the vehicle is configured to generate the input data by compressing vehicle data via the data collection application. 16. The automotive data sharing system of claim 1, wherein the vehicle is configured to generate the input data by compressing vehicle data via the data collection application. Claim Objections Claim 11 is objected to because of the following informalities: “include sat least one” should read “includes at least one.” Appropriate correction is required. Claim Rejections - 35 USC § 112 The following is a quotation of 35 U.S.C. 112(b): (b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention. The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph: The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention. Independent claims 1, 17, and 19 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention. The claims recite “…and running a data collection application,” and the claim fails to clearly identify what feature, i.e., the cloud system, vehicle, or processor (or any combination thereof), is running the application, leading to the issue of indefiniteness. This amendment can be overcome with an appropriate wherein clause or a more clearly worded claim. The associated dependent claims are similarly rejected under § 112(b) because the depend upon the independent claims and fail to cure the issue of indefiniteness. 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. The following conventions apply to the mapping of the prior art to the claims: Italicized text – claim language. Parenthetical plain text – Examiner’s citation and explanation. Citation without an explanation – an explanation has been previously provided for the respective limitation(s). Quotation marks – language quoted from a prior art reference. Underlining – language quoted from a claim. Brackets – material altered from either a prior art reference or a claim, which includes the Examiner’s explanation that relates a claim limitation to the quoted material of a reference. Braces – a limitation taught by another reference, but the limitation is presented with the mapping of the instant reference for context. Numbered superscript – a first phrase to be moved upwards to the primary reference analysis. Lettered superscript – a second phrase to be moved after the movement of the first phrase from which it was lifted, or more succinctly, move numbered material first, lettered material last. A. Claims 1, 3-6, 8-9, 13-14, and 16-20 are rejected under 35 U.S.C. 103 as being unpatentable over Cropp et al. (US 2021/0357528, “Cropp”) in view of Glickman et al. (US 2021/0084104, “Glickman”). Regarding Claim 1 Cropp discloses An…1 data sharing system (Fig. 2, abstract), comprising: a…2 system (Fig. 2, ¶ [0040], “FIG. 2 is a diagram illustrating an example environment 200 in which a system 202 operated by a data aggregator 204...”; and ¶ [0007], “Network entities that develop and offer [cloud computing] services to the users may be referred to herein as “data aggregators”., i.e., Cropp only suggests a cloud system that provides services to the users of vehicles and data consumers, and implementing a cloud system would be obvious in view of Glickman that teaches a cloud system; see also Glickman Fig. 1A, ¶ [0030]) comprising a processor and a memory storing instructions that when executed by the processor cause the processor (Fig. 7, ¶¶ [0073]-[0074]) to: via a consumer portal, receive a request from an entity for requested output data…3 and running a data collection application (Fig. 2, ¶¶ [0046]-[0047], “Accordingly, the analysis module 236 retrieves the data set 226 and executes the data query [as a received request] on, or against, the data set 226 to produce an anonymous result 242 that is provided [as output data] to the third party data consumer [entity] 208 via the API [consumer portal that couples the “data aggregator” to the “third party data consumer”/entity] 238.”, with the “data aggregrator” running a data collection application in order to collect the data that is disseminated to the “third party”/entity); generate a consent form in response to the received request and based on the requested output data (Fig. 3C, ¶ [0060], “FIG. 3C is an example graphical UI 310 [representing a generated consent form] illustrating a message indicating that an entity would like to use a user's data on behalf of third party data consumers [who submitted the data query, and thus the generated consent form is in response to the received request for output data] and UI elements 312, 314, 316, 318 [which serves as the basis for the output data and generated consent form] associated with functionality that allows or prevents use of the user data in association with different data categories (e.g., browsing data, search data, location data, payment data). Accordingly, the user is provided with functionality to manage and control data use [that is output as output data to the “third party”/entity] at a more granular level compared to the general authorization provided in FIG. 3A.”); communicate the consent form to the vehicle via a {vehicle (Glickman ¶ [0124])} user interface of the data collection application (Fig. 3C, ¶ [0060], “FIG. 3C is an example graphical UI [of a user interface, with implementing the user interface within a vehicle to create a vehicle user interface being obvious to one skilled in the art and in view of Glickman ¶ [0124]] 310 illustrating a message [communicating the consent form] indicating that an entity would like to use a user's data”; and Fig. 2, ¶ [0040] and Smith ¶ [0024], i.e., the data collection application is required to implement the data aggregation system); receive an affirmative consent form response or a negative consent form response from the vehicle via the vehicle user interface of the data collection application (Fig. 4, ¶ [0063], “As shown, Entity ABC is asking the user [via the vehicle user interface] if her data can be used to provide Entity XYZ with an average amount of online money spent by females, between ages of 35 and 44, on clothes in the months of April and May. The user can provide input [via the vehicle user interface] allowing [as affirmative consent] or preventing [as negative consent] the use of her data via the graphical UI element [vehicle interface of the data collection application] 404.”); and in response to receiving the affirmative consent form response from the vehicle (Fig. 3A, ¶ [0059], “This content can be displayed if the user allows his or her data to be used (e.g., based on a ‘yes’ [affirmative consent] input to the UI element 304 in FIG. 3A).”), receive input data from the vehicle at the cloud system (Fig. 5, ¶ [0067], “At operation 506, the user data is collected [received from the vehicle] via the use of one or more [cloud computing] services [of the cloud system].”; see also Glickman Fig. 1A, ¶ [0030]) and provide the input data from the vehicle to the entity through the cloud system as the requested output data (Fig. 2, ¶¶ [0045]-[0046], “Accordingly, the analysis module 236 retrieves the data set 226 [as the input data] and executes the data query on, or against, the data set 226 to produce an anonymous result 242 that is provided [as output data] to the third party data consumer 208 [entity] via the API 238.”); wherein the input data received from the vehicle at the cloud system and provided to the entity through the cloud system is subject to a specific data element of one or more of the request, the consent form, the affirmative consent form response, and an original equipment manufacturer limitation or term received via an original equipment manufacturer portal (¶ [0044], “This general authorization can apply to data queries [that produce the output data] that have already been received and are currently being executed by the data aggregator 204 [to output the data to the entity] or to future data queries that have not yet been received. Alternatively, the general authorization can be provided at a more granular level [that is determined by a specific data element]. For example, a user may allow use [via the consent form] of data collected [as input data] via one service (e.g., a searching service), yet prevent use of data collected via another service (e.g., a payment service). Or, a user may allow use of data [by implementing the specific data element] that belongs to one data category (e.g., browsing data), yet prevent use of data that belongs to another data category (e.g., health/exercise data).”; and Fig. 3B that illustrates specific data elements, such as gender, i.e., “Female” as illustrated). Cropp doesn’t disclose 1 …automotive {data sharing}… 2 …cloud {system}… 3 … from a vehicle of a plurality of vehicles each coupled to the cloud system… Glickman, however, discloses 1 …automotive {data sharing}… (¶ [0124], “As an example and not by way of limitation, Entity A may be a data collection company [via the methods taught by Cropp] that has collected and analyzed the consuming habits of millions of individuals in several different categories. Their data sets may include data in the following categories: online shopping, video streaming, electricity consumption, automobile usage, internet usage, clothing purchases, mobile application purchases, club memberships, and online subscription services.”) 2 …cloud {system}… (Fig. 1A, ¶ [0030], “The cloud computing platform 110 may host a cloud computing service [system] 112 that facilitates storage of data on the cloud computing platform 110 (e.g. data management and access) and analysis functions (e.g. SQL queries, analysis), as well as other computation capabilities (e.g., secure data sharing between users of the cloud computing platform 110). The cloud computing platform 110 may include a three-tier architecture: data storage 140, query processing 130, and cloud services 120.”) 3 … from a vehicle of a plurality of vehicles each coupled to the cloud system… (¶ [0124], “As an example and not by way of limitation, Entity A may be a data collection company [via the methods taught by Cropp] that has collected and analyzed the consuming habits of millions of individuals [associated with a plurality of vehicles] in several different categories. Their data sets may include data in the following categories: online shopping, video streaming, electricity consumption, automobile usage, internet usage, clothing purchases, mobile application purchases, club memberships, and online subscription services.”) Regarding the combination of Cropp and Glickman, it would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Cropp to have included cloud architecture to aggregate vehicle data of Glickman. One of ordinary skill in the art would have been motivated to incorporate cloud architecture to aggregate vehicle data because Glickman teaches, “cloud-based storage resources offer significant storage capacity available on-demand at a low cost.” See Glickman ¶ [0027]. Regarding Claim 3 Cropp in view of Glickman (“Cropp-Glickman”) discloses the automotive data sharing system of claim 1, and Cropp further discloses wherein the {cloud system (Glickman Fig. 1A, ¶ [0030])} is further configured to: in response to receiving the negative consent form response from the vehicle (Fig. 4, ¶ [0063]), decline to receive the input data from the vehicle at the cloud system and decline to provide the input data from the vehicle to the entity through the cloud system as the requested output data¶ [0044], “Alternatively, the general authorization can be provided at a more granular level [i.e., some aspect of data consent for the input data is declined or possess a response in the negative]. For example, a user may allow use of data collected via one service (e.g., a searching service), yet prevent [decline] use of data collected via another service (e.g., a payment service). Or, a user may allow use of data that belongs to one data category (e.g., browsing data), yet prevent [decline] use of data that belongs to another data category [and thereby not provide the input data from the vehicle to the entity] (e.g., health/exercise data).”, noting that it would be obvious to one skilled in the art that providing a vehicle/user providing a negative consent would not allow the associated data to be received from the vehicle at the cloud system, as no reason would exist for the cloud system to possess the data and it exposes the data to misuse and against the negative consent]. Regarding Claim 4 Cropp-Glickman discloses the automotive data sharing system of claim 1, and Cropp further discloses wherein the specific data element of the one or more of the request, the consent form, the affirmative consent form response, and the original equipment manufacturer limitation or term received via the original equipment manufacturer portal limits the input data received from the vehicle at the cloud system and provided to the entity through the cloud system in terms of one or more of data type, data collection frequency, data collection duration, data collection purpose, and data collection trigger (¶ [0044], “This general authorization [of the consent form] can apply to data queries that have already been received and are currently being executed by the data aggregator 204 or to future data queries that have not yet been received. Alternatively, the general authorization can be provided at a more granular level [that is determined by a specific data element]. For example, a user may allow use [via the consent form] of data collected [as input data] via one service (e.g., a searching service), yet prevent use of data collected via another service (e.g., a payment service). Or, a user may allow use of data [by implementing the specific data element] that belongs to one data [type] category (e.g., browsing data), yet prevent use of data that belongs to another data category (e.g., health/exercise data).”; and Fig. 3B that illustrates specific data elements, such as gender, i.e., “Female” as illustrated). Regarding Claim 5 Cropp-Glickman discloses the automotive data sharing system of claim 1, and Cropp further discloses wherein the affirmative consent form response (Fig. 4, ¶ [0063]) is a modified consent form response limiting the input data received from the vehicle at the cloud system and provided to the entity through the cloud system in terms of one or more of data type, data collection frequency, data collection duration, and data collection purpose (¶¶ [0048]-[0049], “In various examples, the system 202 is configured to notify the user of a specific data query 240 [to provide an opportunity to modify a consent] and/or an identification of a third party data consumer 208 that submitted the data query 240 when the user's data is set to be used in the data query 240 based on previous user input. The notification can include, or provide access to, an option for the user to opt out [thereby imposing a data collection duration] or prevent use of his or her data for the data query 240.”). Regarding Claim 6 Cropp-Glickman discloses the automotive data sharing system of claim 1, and Cropp further discloses wherein the consent form is communicated to a user interface of a display of the vehicle via the data collection application (¶ [0039], “As further described herein, various graphical user interfaces (UIs) can be displayed [via a display of the vehicle] that enable the users 102 to provide input that controls the extent to which their data is used by the data aggregators 108 on behalf of the third party data consumers 128.”). Regarding Claim 8 Cropp-Glickman discloses the automotive data sharing system of claim 1, and Cropp further discloses wherein the input data is provided as the requested output data periodically or when the input data indicates that an event threshold has been satisfied (¶ [0049], “For instance, the user may define a setting indicating that a user would like to be asked [upon identifying a threshold/criterion] whether his or her data can be used on a query-by-query basis [that is based upon an event that precipitates the interest in the query]. Accordingly, the prompt can inform the user of the data query 240 [that satisfies and event threshold/criterion], identify the third party data consumer [entity] 208 that is the source of the data query [that acts as a request] 240, describe the data query 240, and/or ask the user for approval to use his or her data for the data query 240 [that provides the output data].”). Regarding Claim 9 Cropp-Glickman discloses the automotive data sharing system of claim 1, and Cropp further discloses wherein the cloud system is further configured to transmit one or more of a command, a push notification, and a web link from the entity to the vehicle (¶¶ [0050]-[0051], “In various embodiments, the system 202 is configured to offer [or transmit] an incentive 244 [via a push notification] for the user to allow the use of his or her user data by third party data consumers.;” and “In further examples, the incentive 244 is provided [via a push notification] by the third party data consumer 208 [entity]. For instance, in exchange for a user allowing his or her data to be used, the third party data consumer may inform the system 202 to offer a free or a discounted subscription to a service offered by the third party data consumer 208.”). Regarding Claim 13 Cropp-Glickman discloses the automotive data sharing system of claim 1, and Cropp further discloses wherein the consent form includes at least one of a web link or a universal resource locator from the entity, and wherein the consent form is configured to, while being acted upon by the vehicle, display content associated with at least one of the web link or the universal resource locator to an operator of the vehicle (Fig. 3D, ¶ [0061], “FIG. 3D is an example graphical UI 320 illustrating an incentive offered to the user for allowing the use of user data on behalf of third party data consumers. For example, Entity ABC may offer a free digital subscription to the ‘News Service’ in exchange for the user allowing his or her data to be used. In another example, Entity ABC may offer 5% off all purchases implemented via advertisements [associated with URL] displayed in the aforementioned services (of FIG. 3A).”). Regarding Claim 14 Cropp-Glickman discloses the automotive data sharing system of claim 1, and Cropp further discloses wherein the vehicle is configured to generate the input data by compressing vehicle data via the data collection application (¶ [0075], “Transmitting the requested personal data from the secure personal data store may include reading an encrypted [compressed] version of the requested personal data from the secure personal data store, decrypting the personal data, and then forwarding (e.g., over a network connection or pipe, via an output parameter or return value, via a message) the decrypted personal data to the personal data subscriber. In a typical embodiment, the communication link between the personal data manager and the personal data subscriber is itself encrypted, so as to prevent eavesdropping and/or interception of personal data items. The routine then proceeds to step 408.”). Regarding Claim 16 Cropp-Glickman discloses the automotive data sharing system of claim 1, and Cropp further discloses wherein the cloud system (Glickman ¶ [0030]) is further configured to receive the input data from the vehicle at the cloud system in response to the occurrence of a trigger event at the vehicle and provide the input data from the vehicle to the entity through the cloud system as the requested output data (¶ [0048], “In various examples, the system 202 is configured to notify the user [the notification serving as a trigger event at the vehicle] of a specific data query 240 and/or an identification of a third party data consumer 208 that submitted the data query 240 when the user's [input] data is set to be used in the data query 240 based on previous user input. The notification can include, or provide access to, an option for the user to opt out or prevent use of his or her data for the data query 240.”, noting the Cropp teaches the input data has already provided the input data through the cloud system, but it would be obvious to one skilled in the art to provide the input data from the vehicle to the cloud system to satisfy the request of the entity and enable the receipt of the output data). Regarding Independent Claims 17 and 19 and Dependent Claims 18 and 20 With respect to claims 17-20, a corresponding reasoning as given earlier for independent claim 1 and dependent claim 3 applies, mutatis mutandis, to the subject matter of claims 17-20. Therefore, claims 17-20 are rejected, for similar reasons, under the grounds set forth for claims 1 and 3. B. Claim 2 is rejected under 35 U.S.C. 103 as being unpatentable over Cropp in view of Glickman, and further in view of Parikh et al. (WO 2020/205514, “Parikh”). Regarding Claim 2 Cropp-Glickman discloses the automotive data sharing system of claim 1, and Glickman further discloses wherein one or more of: the cloud system is…1 Cropp-Glickman doesn’t disclose 1 …coupled to each of the plurality of vehicles via a wireless two-way communications link; and the cloud system is coupled to the entity via a two-way communications link. Parik, however, discloses 1 …coupled to each of the plurality of vehicles via a wireless two-way communications link (Fig. 17, ¶¶ [0111]-[0114], “The traffic control group 1706, or other subgroups, may be in [two-way] communication with the cloud 1700 through wired or wireless links 1708, such as LPWA links, optical links, and the like. Further, a wired or wireless sub -network 1712 may allow the IoT devices to communicate with each other, such as through a local area network, a wireless local area network, and the like.;” and “Other example groups of IoT devices may include … moving vehicles, such as emergency vehicles 1724 or other vehicles 1726, among many others;” see also Fig. 15, ¶¶ [0093]-[0094], “The backbone links 1502 may include any number of wired or wireless technologies, including optical networks, and may be part of a local area network (LAN), a wide area network (WAN), or the Internet”); and the cloud system is coupled to the entity via a two-way communications link (Fig. 17, ¶¶ [0111]-[0114], “The IoT devices may use another device, such as a gateway 1710 or 1728 to communicate with remote locations such as the cloud 1700 [via a wired connection where wireless communication would not be appropriate]; the IoT devices may also use one or more servers 1730 [of the entities] to facilitate [two-way] communication with the cloud 1700 or with the gateway 1710. For example, the one or more servers 1730 may operate as an intermediate network node to support a local edge cloud or fog implementation among a local area network.”). Regarding the combination of Cropp-Glickman and Parikh, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the data aggregation system of Cropp-Glickman to arrive at the claimed invention. KSR establishes that a rationale for obviousness is proven by showing a “use of [a] known technique to improve similar devices in the same way.” See MPEP § 2143(I)(C). To substantiate the conclusion of obviousness under this KSR rationale, the Examiner finds pursuant to MPEP § 2143(I)(C): 1) the prior art contained a base system, namely the data aggregation system of Cropp-Glickman, upon which the claimed invention can be seen as an “improvement” through the use of two-way communication links; 2) the prior art contained a “comparable” system, namely the cloud system of Parikh, that has been improved in the same way as the claimed invention through the use of two-way communication links; and 3) one of ordinary skill in the art could have applied the known improvement technique of applying the use of two-way communication links to the base data aggregation system of Cropp-Glickman, and the results would have been predictable to one of ordinary skill in the art. C. Claim 7 is rejected under 35 U.S.C. 103 as being unpatentable over Cropp in view of Glickman, and further in view of Winstrom (US 2021/0359835, “Winstrom,” see also provisional patent application no. 63/023,251 to which US 2021/0359835 claims priority). Regarding Claim 7 Cropp-Glickman discloses the automotive data sharing system of claim 1, and Cropp further discloses wherein the input data (Fig. 2, ¶¶ [0041]-[0043]) is…1 and…2. Cropp-Glickman doesn’t disclose 1 …encrypted by the vehicle utilizing the data collection application, 2 subsequently decrypted as the requested output data by one of the cloud system and the entity. Winstrom, however, discloses 1 …encrypted by the vehicle utilizing the data collection application (Fig. 1, ¶¶ [0025]-[0026], “In an embodiment, the data requesting party (e.g., a third party requesting server 108) [as an entity for which a request for encryption comprises the entity arranging for the production of a public/private key pair] may generate a participant encryption key (e.g., a homomorphic public/private key pair) with a key generation service 107 which is provided to the set of participant devices [vehicles] in device groups 110, 111, and 112.”; and “A participant device 110 a may encrypt the requested [input] data for the participant device 110 a with the received participant encryption key [employed by the data collection application to secure the data] and send the data to the aggregation service 106 (e.g., at the aggregation service server 102);” “In an embodiment, the data requesting party (e.g., a third party requesting server 108) may generate a participant encryption key (e.g., a homomorphic public/private key pair) with a key generation service 107 which is provided [via the cloud system, further noting Fig. 1 illustrates a direct delivery of the key from the “third-party server 108”/entity to the “device groups 110-112”/vehicles, but it would be an obvious variation for the “aggregation service 102”/cloud system to deliver the public key via the network 120] to the set of participant devices in device groups 110, 111, and 112;”), 2 subsequently decrypted as the requested output data by one of the cloud system and the entity (Fig. 1, ¶¶ [0025]-[0026], “The aggregation service 106 sends the encrypted aggregated [output] result 140 to the requesting server 108 (e.g., third party) [entity] and the requesting server 108 can use a decryption key (e.g., a stored private key corresponding to the public key used for encryption) to decrypt the aggregated [output] result 140...”). Regarding the combination of Cropp-Glickman and Winstrom, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the data aggregation system of Cropp-Glickman to arrive at the claimed invention. KSR establishes that a rationale for obviousness is proven by showing a “use of [a] known technique to improve similar devices in the same way.” See MPEP § 2143(I)(C). To substantiate the conclusion of obviousness under this KSR rationale, the Examiner finds pursuant to MPEP § 2143(I)(C): 1) the prior art contained a base system, namely the data aggregation system of Cropp-Glickman, upon which the claimed invention can be seen as an “improvement” through the use of a encryption and decryption feature; 2) the prior art contained a “comparable” system, namely the aggregation system of Winstrom, that has been improved in the same way as the claimed invention through the use of the encryption and decryption feature; and 3) one of ordinary skill in the art could have applied the known improvement technique of applying the use of the encryption and decryption feature to the base data aggregation system of Cropp-Glickman, and the results would have been predictable to one of ordinary skill in the art. D. Claim 10 is rejected under 35 U.S.C. 103 as being unpatentable over Cropp in view of Glickman, and further in view of Kim et al. (US 10,203,699, “Kim”). Regarding Claim 10 Cropp-Glickman discloses the automotive data sharing system of claim 1, and Cropp further discloses wherein the cloud system (Glickman ¶ [0030]) is further configured to: 1 …. Cropp-Glickman doesn’t disclose 1 communicate from the {entity, which has been given consent to access the requested output data, to the vehicle (Cropp Fig. 3C, ¶ [0060, Fig. 4, ¶ [0063])} a command or user interface notification configured to selectively grant access to the entity to remotely control aspects of operation of the vehicle, to facilitate a two-way communication between the entity and the vehicle, or both (Col. 19:30-55, “In the override response in operation 426, the override confirmation provided by the local ADAS controller 120 may reflect whether or not the cost of the remote ADAS [advanced drive assistance system] control is been accepted (e.g., if it has, then the override response consents to the remote control, if it has not, then the override response does not consent to the remote control). The remote ADAS controller 122, when receiving the override confirmation in operation 426, also receives an acceptance or denial of the cost [collected by the entity] of the remote ADAS control. If the cost is accepted, the remote ADAS controller 122 will proceed to provide the remote ADAS control service.”). Regarding the combination of Cropp-Glickman and Kim, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the data aggregation system of Cropp--Glickman to arrive at the claimed invention. KSR establishes that a rationale for obviousness is proven by showing a “use of [a] known technique to improve similar devices in the same way.” See MPEP § 2143(I)(C). To substantiate the conclusion of obviousness under this KSR rationale, the Examiner finds pursuant to MPEP § 2143(I)(C): 1) the prior art contained a base system, namely the data aggregation system of Cropp-Glickman, upon which the claimed invention can be seen as an “improvement” through the use of a remote-control feature; 2) the prior art contained a “comparable” system, namely the vehicle system of Kim, that has been improved in the same way as the claimed invention through the remote-control feature; and 3) one of ordinary skill in the art could have applied the known improvement technique of applying the remote-control feature to the base data aggregation system of Cropp-Glickman, and the results would have been predictable to one of ordinary skill in the art. E. Claim 11 is rejected under 35 U.S.C. 103 as being unpatentable over Cropp in view of Glickman, and further in view of Pollard (US 2010/0185656, “Pollard”). Regarding Claim 11 Cropp-Glickman discloses the automotive data sharing system of claim 1, and Cropp further discloses wherein the {cloud system (Glickman ¶ [0030])} is further configured to…1 Cropp-Glickman doesn’t disclose 1 …receive at least one vehicle identification number (VIN) from the entity identifying the vehicle of the plurality of vehicles. Pollard, however, discloses 1 …receive at least one vehicle identification number (VIN) from the entity identifying the vehicle of the plurality of vehicles (¶ [0137], “As another example, a car insurance personal data item may include name of the insured, insurance policy number, insurer identification, and vehicle information (e.g., vehicle identification number, make, model). Each personal data item may have associated attributes, such as type, permissions (e.g., read, write, read/write, execute), size (e.g., maximum number of characters), etc.”). Regarding the combination of Cropp-Glickman and Pollard, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the data aggregation system of Cropp-Glickman to arrive at the claimed invention. KSR establishes that a rationale for obviousness is proven by showing a “use of [a] known technique to improve similar devices in the same way.” See MPEP § 2143(I)(C). To substantiate the conclusion of obviousness under this KSR rationale, the Examiner finds pursuant to MPEP § 2143(I)(C): 1) the prior art contained a base system, namely the data aggregation system of Cropp-Glickman, upon which the claimed invention can be seen as an “improvement” through the use of a VIN identification feature; 2) the prior art contained a “comparable” system, namely the data management system of Pollard, that has been improved in the same way as the claimed invention through the VIN identification feature; and 3) one of ordinary skill in the art could have applied the known improvement technique of applying the VIN identification feature to the base data aggregation system of Cropp-Glickman, and the results would have been predictable to one of ordinary skill in the art. F. Claim 12 is rejected under 35 U.S.C. 103 as being unpatentable over Cropp in view of Glickman, and further in view of Tarnutzer (US 2012/0173051, “Tarnutzer”). Regarding Claim 12 Cropp-Glickman discloses the automotive data sharing system of claim 1, and Cropp further discloses wherein the cloud system (Glickman ¶ [0030]) is further configured to: 1 …. Cropp-Glickman doesn’t disclose 1 communicate the consent form request to the original equipment manufacturer; and receive approval of the original equipment manufacturer; wherein the requested output data is provided to the entity in response to receiving the approval of the original equipment manufacturer. Tarnutzer, however, discloses 1 communicate the consent form request to an original equipment manufacturer (OEM) of the vehicle of the plurality of vehicles (Fig. 2, ¶ [0012], “What is needed is an OEM safe aftermarket gateway to provide the aftermarket devices and systems with a means to safely and with the consent of the OEM to control certain OEM features and functions such as, but not limited to, opening power sliding doors, unlock or lock doors, and remote start.”); receive approval of the OEM (¶ [0022], “FIG. 2 discloses a simplified schematic process or flow-method of the OEM safe aftermarket gateway of FIG. 1, whereby an OEM sign-off [approval that is received by the entity/supplier] and OEM vehicle warranty apply to a system or device supplied by an aftermarket supplier.”); wherein the output data is provided to the entity in response to receiving approval of the entity from the OEM (¶ [0012], “What is needed is an OEM safe aftermarket gateway to provide the aftermarket devices and systems with a means to safely and with the consent of the OEM to control certain OEM features and functions such as, but not limited to, opening power sliding doors, unlock or lock doors, and remote start.”, i.e., the output data that originates as input data from vehicles comprises information that the user enters regarding the functionality of the aftermarket device, such as a “remote start”). Regarding the combination of Cropp-Glickman and Tarnutzer, it would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the data aggregation system of Cropp-Glickman to have included the OEM feature of Tarnutzer. One of ordinary skill in the art would have been motivated to incorporate the OEM feature because Tarnutzer teaches that such an OEM feature enables aftermarket device to be “safely” implemented. See Tarnutzer ¶ [0012]. G. Claim 15 is rejected under 35 U.S.C. 103 as being unpatentable over Cropp in view of Glickman, and further in view of Freund (US 11,544,396, “Freund”). Regarding Claim 15 Cropp-Glickman discloses the automotive data sharing system of claim 1, and Cropp further discloses wherein the cloud system (Glickman ¶ [0030]) is further configured to: communicate the consent form request (Fig. 3C, ¶ [0060]) to…1 Cropp-Glickman doesn’t disclose 1 a fleet manager associated with the vehicle; and receive approval of the fleet manager; wherein the requested output data is provided to the entity in response to receiving the approval of the fleet manager. Freund, however, discloses 1 a fleet manager associated with the vehicle; and receive approval of the fleet manager; wherein the requested output data is provided to the entity in response to receiving the approval of the fleet manager (Col. 4:8-16, “When a data consumer requests the sharing of aggregate data [requested output data] from a specific fleet [and fleet manager thereof] or an original equipment manufacturer (OEM), the data consumer does not know in advance which vehicles will be included [after receiving approval of the fleet manager].”). Regarding the combination of Cropp-Glickman and Freund, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the data aggregation system of Cropp-Glickman to arrive at the claimed invention. KSR establishes that a rationale for obviousness is proven by showing a “use of [a] known technique to improve similar devices in the same way.” See MPEP § 2143(I)(C). To substantiate the conclusion of obviousness under this KSR rationale, the Examiner finds pursuant to MPEP § 2143(I)(C): 1) the prior art contained a base system, namely the data aggregation system of Cropp-Glickman, upon which the claimed invention can be seen as an “improvement” through the use of a fleet management feature; 2) the prior art contained a “comparable” system, namely the data management system of Freund, that has been improved in the same way as the claimed invention through the fleet management feature; and 3) one of ordinary skill in the art could have applied the known improvement technique of applying the fleet management feature to the base data aggregation system of Cropp-Glickman, and the results would have been predictable to one of ordinary skill in the art. Conclusion Any inquiry concerning this communication or earlier communications from the examiner should be directed to D'ARCY WINSTON STRAUB whose telephone number is (303)297-4405. The examiner can normally be reached Monday-Friday 9:00-5:00 Mountain Time. Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice. If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, WILLIAM KORZUCH can be reached at (571)272-7589. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300. Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000. /D'Arcy Winston Straub/Primary Examiner, Art Unit 2491
Read full office action

Prosecution Timeline

Apr 28, 2025
Application Filed
Jun 17, 2026
Non-Final Rejection mailed — §103, §112 (current)

Precedent Cases

Applications granted by this same examiner with similar technology

Patent 12683790
A PROTOCOL FOR TRUSTWORTHY, PRIVACY PRESERVING GENOMIC DATABASE DISCOVERY
3y 11m to grant Granted Jul 14, 2026
Patent 12682107
SYSTEM AND METHOD FOR PROCESSING INSTRUCTIONS ASSOCIATED WITH ONE OR MORE DATA TRANSFERS
2y 4m to grant Granted Jul 14, 2026
Patent 12659734
METHOD, APPARATUS, AND SYSTEM FOR VEHICLE-TO-VEHICLE COMMUNICATIONS
3y 9m to grant Granted Jun 16, 2026
Patent 12619772
SENSITIVE INFORMATION DISCLOSURE PREDICTION SYSTEM FOR SOCIAL MEDIA USERS AND METHOD THEREOF
2y 8m to grant Granted May 05, 2026
Patent 12619755
ARTIFICIAL DATA GENERATION FOR DIFFERENTIAL PRIVACY
2y 6m to grant Granted May 05, 2026
Study what changed to get past this examiner. Based on 5 most recent grants.

Strategy Recommendation AI-generated — please review before filing

Get a prosecution strategy drawn from examiner precedents, rejection analysis, and claim mapping.
Typically takes 5-10 seconds — AI-generated, attorney review required before filing

Prosecution Projections

1-2
Expected OA Rounds
77%
Grant Probability
96%
With Interview (+18.7%)
2y 11m (~1y 9m remaining)
Median Time to Grant
Low
PTA Risk
Based on 228 resolved cases by this examiner. Grant probability derived from career allowance rate.

Sign in with your work email

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

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

Free tier: 3 strategy analyses per month