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 .
Claims 1-20 have been examined.
P = paragraph e.g. P[0001] = paragraph[0001]
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-4, 7, 9, 12-14 and 16-20 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1, 3, 5 and 8-10 of U.S. Patent No. 10,607,296. Although the claims at issue are not identical, they are not patentably distinct from each other because:
Claim 1 is fully encompassed by Claims 1, 3 and 9 of U.S. Patent No. 10,607,296, which will be referred to as Patent ‘296. While Claims 1, 3 and 9 of Patent ‘296 do not recite “a most recent value”, because the “higher-level vehicle data” is based on streaming vehicle data (as seen in Claim 3 of Patent ‘296), a person having ordinary skill in the art before the effective filing date of the claimed invention would find it obvious that streamed data would include the most recent data. Furthermore, “most recent” is a relative term, and Claim 1 of the present application does not provide any context as to what defines a “most recent value” in terms of time or events, meaning “most recent” encompasses simply most recent with respect to a data streaming event, where even a single data streaming event would then provide a “most recent” data set corresponding to that data streaming event. Furthermore, Claims 1, 3 and 9 of Patent ‘296 do not recite that the “response” to the “vehicle request” includes “the most recent value” as claimed in Claim 1 of the present application, however, Claim 1 of Patent ‘296 is directed to “A method for processing requests for vehicular data”, and a person having ordinary skill in the art before the effective filing date of the claimed invention would find it obvious that if the “higher-level vehicle data stored in the standardized database” is used to generate the response to a request for “vehicular data”, then the response should include the vehicle data itself, in order to fulfill the request.
Claim 2 is encompassed by Claims 1, 3 and 9 of Patent ‘296, where a person having ordinary skill in the art before the effective filing date of the claimed invention would find it obvious that requested vehicle data could include “vehicle data associated with one or more OEM partners” as in Claim 1 of Patent ‘296, in order to obtain all available vehicle data from all “OEM partners”.
Claim 3 is encompassed by Claims 1, 3 and 9 of Patent ‘296, where any data or value is “indicative of” a “respective data sampling time at which the value was sampled”, as any sampled data must be sampled at a particular time.
Claim 4 is encompassed by Claims 1, 3, 5 and 9 of Patent ‘296.
Claim 7 is encompassed by Claims 1, 3 and 9 of Patent ‘296.
Claim 9 is encompassed by Claims 1, 3 and 9 of Patent ‘296, as Claim 9 is directed to simply performing the steps of Claim 1 for a second vehicle, where clearly the invention of Claims 1, 3 and 9 of Patent ‘296 does not exclude the steps being performed for two different vehicles, and a person having ordinary skill in the art before the effective filing date of the claimed invention would find it obvious that a request directed to a second vehicle could be generated.
Claim 12 is encompassed by Claims 1, 5 and 8-10 of Patent ‘296. Claims 1, 5 and 8-10 of Patent ‘296 do not recite that the “response” to the “vehicle request” includes a “value from the set of values” as claimed in Claim 12 of the present application, however, Claim 1 of Patent ‘296 is directed to “A method for processing requests for vehicular data”, and a person having ordinary skill in the art before the effective filing date of the claimed invention would find it obvious that if the “higher-level vehicle data stored in the standardized database” is used to generate the response to a request for “vehicular data”, then the response should include the vehicle data itself, in order to fulfill the request.
Claim 13 is encompassed by Claims 1, 5 and 8-10 of Patent ‘296, where a person having ordinary skill in the art before the effective filing date of the claimed invention would find it obvious that requested vehicle data could include “vehicle data associated with one or more OEM partners” as in Claim 1 of Patent ‘296, in order to obtain all available vehicle data from all “OEM partners”.
Claim 14 is encompassed by Claims 1, 5 and 8-10 of Patent ‘296.
Claim 16 is encompassed by Claims 1, 3, 5 and 8-10 of Patent ‘296. While Claims 1, 3, 5 and 8-10 of Patent ‘296 do not recite “a most recent value”, because the “higher-level vehicle data” is based on streaming vehicle data (as seen in Claim 3 of Patent ‘296), a person having ordinary skill in the art before the effective filing date of the claimed invention would find it obvious that streamed data would include the most recent data. Furthermore, “most recent” is a relative term, and Claim 16 of the present application does not provide any context as to what defines a “most recent value” in terms of time or events, meaning “most recent” encompasses simply most recent with respect to a data streaming event, where even a single data streaming event would then provide a “most recent” data set corresponding to that data streaming event.
Claim 17 is encompassed by Claims 1, 3, 5 and 8-10 of Patent ‘296.
Claim 18 is encompassed by Claims 1, 3, 5 and 8-10 of Patent ‘296, as Claim 18 is directed to simply performing the steps of Claim 12 for a second vehicle, where clearly the invention of Claims 1, 5 and 8-10 of Patent ‘296 does not exclude the steps being performed for two different vehicles, and a person having ordinary skill in the art before the effective filing date of the claimed invention would find it obvious that a request directed to a second vehicle could be generated.
Claim 19 is encompassed by Claims 1, 5 and 8-10 of Patent ‘296.
Claim 20 is encompassed by Claims 1, 5 and 8-10 of Patent ‘296, where the invention of Claims 1, 5 and 8-10 of Patent ‘296 does not exclude multiple requests directed to a single “vehicle identifier”, and a person having ordinary skill in the art before the effective filing date of the claimed invention would find it obvious that any number of requests directed to a “first endpoint identifier” could be generated, such as when a requestor wishes to obtain an update to any vehicle data.
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 an abstract idea without significantly more. See below.
Claim 1 is rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
101 Analysis – Step 1
Claim 1 is directed to a method (i.e., a process). Therefore, claim 1 is within at least one of the four statutory categories.
101 Analysis – Step 2A, Prong I
Regarding Prong I of the Step 2A analysis in the 2019 PEG, the claims are to be analyzed to determine whether they recite subject matter that falls within one of the follow groups of abstract ideas: a) mathematical concepts, b) certain methods of organizing human activity, and/or c) mental processes.
Independent claim 1 includes limitations that recite an abstract idea (emphasized below) and will be used as a representative claim for the remainder of the 101 rejection. Claim 1 recites:
A method for processing requests for vehicular data, the method comprising, at a remote system:
receiving, from a first vehicle, streaming data indicative of a set of values of a first vehicle parameter of the first vehicle, comprising receiving a most recent value of the set of values;
after receiving the most recent value, receiving, from a third party application, a vehicle request for the first vehicle parameter, the vehicle request comprising a first vehicle identifier, wherein the first vehicle identifier is associated with the first vehicle;
in response to receiving the vehicle request, verifying the vehicle request; and
in response to verifying the vehicle request, transmitting the most recent value to the third-party application.
The examiner submits that the foregoing bolded limitation(s) constitute a “mental process” because under its broadest reasonable interpretation, the claim covers performance of the limitation in the human mind. Specifically, regarding the “in response to receiving the vehicle request, verifying the vehicle request” limitation, a user may mentally verify the vehicle request. Also, a user may mentally determine if the “vehicle request” has been received.
Accordingly, the claim recites at least one abstract idea.
101 Analysis – Step 2A, Prong II
Regarding Prong II of the Step 2A analysis in the 2019 PEG, the claims are to be analyzed to determine whether the claim, as a whole, integrates the abstract into a practical application. As noted in the 2019 PEG, it must be determined whether any additional elements in the claim beyond the abstract idea integrate the exception into a practical application in a manner that imposes a meaningful limit on the judicial exception. The courts have indicated that additional elements merely using a computer to implement an abstract idea, adding insignificant extra solution activity, or generally linking use of a judicial exception to a particular technological environment or field of use do not integrate a judicial exception into a “practical application.”
In the present case, the additional limitations beyond the above-noted abstract idea are as follows (where the underlined portions are the “additional limitations” while the bolded portions continue to represent the “abstract idea”):
A method for processing requests for vehicular data, the method comprising, at a remote system:
receiving, from a first vehicle, streaming data indicative of a set of values of a first vehicle parameter of the first vehicle, comprising receiving a most recent value of the set of values;
after receiving the most recent value, receiving, from a third party application, a vehicle request for the first vehicle parameter, the vehicle request comprising a first vehicle identifier, wherein the first vehicle identifier is associated with the first vehicle;
in response to receiving the vehicle request, verifying the vehicle request; and
in response to verifying the vehicle request, transmitting the most recent value to the third-party application.
For the following reason(s), the examiner submits that the above identified additional limitations do not integrate the above-noted abstract idea into a practical application.
Regarding the additional limitation “at a remote system”, the “remote system” is recited at a high level of generality and amounts to nothing more than a generic computer used to apply the exception. The additional limitation “receiving, from a first vehicle, streaming data indicative of a set of values of a first vehicle parameter of the first vehicle, comprising receiving a most recent value of the set of values” amounts to mere data gathering, which is a form of insignificant extra-solution activity. The additional limitation “after receiving the most recent value, receiving, from a third party application, a vehicle request for the first vehicle parameter, the vehicle request comprising a first vehicle identifier, wherein the first vehicle identifier is associated with the first vehicle" amounts to mere data gathering, which is a form of insignificant extra-solution activity. The additional limitation “in response to verifying the vehicle request, transmitting the most recent value to the third-party application” amounts to an insignificant extra-solution activity of transmitting data, where the courts have determined that transmission of data does not show an improvement in computer-functionality, see MPEP 2016.05(a), TLI Communications, 823 F.3d at 611-12, 118 USPQ2d at 1747, where the Examiner notes that the limitation “in response to” encompasses merely a timing of the “transmitting”, which does not amount to significantly more than the judicial exception.
Thus, taken alone, the additional elements do not integrate the abstract idea into a practical application. Further, looking at the additional limitation(s) as an ordered combination or as a whole, the limitation(s) add nothing that is not already present when looking at the elements taken individually. For instance, there is no indication that the additional elements, when considered as a whole, reflect an improvement in the functioning of a computer or an improvement to another technology or technical field, apply or use the above-noted judicial exception to effect a particular treatment or prophylaxis for a disease or medical condition, implement/use the above-noted judicial exception with a particular machine or manufacture that is integral to the claim, effect a transformation or reduction of a particular article to a different state or thing, or apply or use the judicial exception in some other meaningful way beyond generally linking the use of the judicial exception to a particular technological environment, such that the claim as a whole is not more than a drafting effort designed to monopolize the exception (MPEP § 2106.05). Accordingly, the additional limitation(s) do/does not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea.
101 Analysis – Step 2B
Regarding Step 2B of the Revised Guidance, representative independent claim 1 does not include additional elements (considered both individually and as an ordered combination) that are sufficient to amount to significantly more than the judicial exception for the same reasons to those discussed above with respect to determining that the claim does not integrate the abstract idea into a practical application. As discussed above with respect to integration of the abstract idea into a practical application, the “remote system” is recited at a high level of generality and amounts to nothing more than a generic computer used to apply the exception, the additional limitation “receiving, from a first vehicle, streaming data indicative of a set of values of a first vehicle parameter of the first vehicle, comprising receiving a most recent value of the set of values” amounts to mere data gathering, which is a form of insignificant extra-solution activity, the additional limitation “after receiving the most recent value, receiving, from a third party application, a vehicle request for the first vehicle parameter, the vehicle request comprising a first vehicle identifier, wherein the first vehicle identifier is associated with the first vehicle" amounts to mere data gathering, which is a form of insignificant extra-solution activity, and the additional limitation “in response to verifying the vehicle request, transmitting the most recent value to the third-party application” amounts to an insignificant extra-solution activity of transmitting data, where the courts have determined that transmission of data does not show an improvement in computer-functionality. Mere instructions to apply an exception using a generic computer component cannot provide an inventive concept. Hence, the claim is not patent eligible.
Dependent claim(s) 2-11 do not recite any further limitations that cause the claim(s) to be patent eligible. Rather, the limitations of dependent claims 2-11 are directed toward additional aspects of the judicial exception and/or well-understood, routine and conventional additional elements that do not integrate the judicial exception into a practical application. Therefore, dependent claims 2-11 are similarly rejected as being directed towards non-statutory subject matter.
Therefore, claim(s) 1-11 are ineligible under 35 USC §101.
See below regarding the dependent claims.
As per Claim 2, said claim is rejected as it fails to correct the deficiency of Claim 1. The claim describes a request, which does not amount to significantly more than the judicial exception.
As per Claim 3, said claim is rejected as it fails to correct the deficiency of Claim 1. The claim describes what “streaming data” is “indicative of”, which does not amount to significantly more than the judicial exception.
As per Claim 4, said claim is rejected as it fails to correct the deficiency of Claim 1. The claim amounts to mere data gathering, which is a form of insignificant extra-solution activity, which does not amount to significantly more than the judicial exception.
As per Claim 5, said claim is rejected as it fails to correct the deficiency of Claim 1. The claim amounts to mere data gathering, which is a form of insignificant extra-solution activity, which does not amount to significantly more than the judicial exception.
As per Claim 6, said claim is rejected as it fails to correct the deficiency of Claim 1. The claim is directed to an generic step of data deletion, which is an insignificant extra-solution activity of data management that may be performed by a generic computer, therefore, does not amount to significantly more than the judicial exception.
As per Claim 7, said claim is rejected as it fails to correct the deficiency of Claim 1. The claim describes a request, which does not amount to significantly more than the judicial exception.
As per Claim 8, said claim is rejected as it fails to correct the deficiency of Claim 1. A user may mentally authenticate a redirection URI associated with the access token and verify that the redirection URI corresponds to a permitted domain for the third party application. Therefore, the claim does not amount to significantly more than the judicial exception.
As per Claim 9, said claim is rejected as it fails to correct the deficiency of Claim 1. The limitation “before receiving the vehicle request, receiving, from a second vehicle, second streaming data indicative of a second set of values of a second vehicle parameter of the second vehicle” amounts to mere data gathering, which is a form of insignificant extra-solution activity, and the limitation “in response to verifying the vehicle request, transmitting at least one value of the second set of values to the third-party application, wherein the vehicle request further comprises a second vehicle identifier, wherein the second vehicle identifier is associated with the second vehicle” amounts to an insignificant extra-solution activity of transmitting data, where the courts have determined that transmission of data does not show an improvement in computer-functionality. Therefore, the claim does not amount to significantly more than the judicial exception.
As per Claim 10, said claim is rejected as it fails to correct the deficiency of Claim 1. A user may mentally verify that the third-party application is authorized to access information associated with the first vehicle and is authorized to access information associated with the second vehicle. Therefore, the claim does not amount to significantly more than the judicial exception.
As per Claim 11, said claim is rejected as it fails to correct the deficiency of Claim 1. The limitation “receiving a plurality of streaming data, comprising receiving, from each vehicle of a plurality of vehicles: respective streaming data indicative of a respective set of values of a respective vehicle parameter of the respective vehicle” amounts to mere data gathering, which is a form of insignificant extra-solution activity. Furthermore, a user may mentally determine, based on the plurality of streaming data, a population-level operational metric for the plurality of vehicles, wherein the population-level operational metric is associated with at least one of: average vehicle range, total active vehicles, or geographic distribution. Additionally, the limitation “transmitting the population-level operational metric to the second third- party application” amounts to an insignificant extra-solution activity of transmitting data, where the courts have determined that transmission of data does not show an improvement in computer-functionality. Therefore, the claim does not amount to significantly more than the judicial exception.
Claim 12 is rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
101 Analysis – Step 1
Claim 12 is directed to a method (i.e., a process). Therefore, claim 12 is within at least one of the four statutory categories.
101 Analysis – Step 2A, Prong I
Regarding Prong I of the Step 2A analysis in the 2019 PEG, the claims are to be analyzed to determine whether they recite subject matter that falls within one of the follow groups of abstract ideas: a) mathematical concepts, b) certain methods of organizing human activity, and/or c) mental processes.
Independent claim 12 includes limitations that recite an abstract idea (emphasized below). Claim 12 recites:
A method for processing requests for vehicular data, the method comprising, at a remote system:
receiving, from a vehicle, a set of values for a set of vehicle parameters associated with the vehicle;
caching the set of values in association with a first endpoint identifier indicative of the vehicle;
receiving a batch of vehicle requests from a third party application, the batch of vehicle requests comprising a set of endpoint identifiers, the set comprising the first endpoint identifier;
in response receiving to the request, verifying the vehicle request, comprising mapping the vehicle request to a user identifier stored in association with a client identifier identifying the third party application; and
based on the request, transmitting a response to the third party application, the response comprising a value from the set of values.
The examiner submits that the foregoing bolded limitation(s) constitute a “mental process” because under its broadest reasonable interpretation, the claim covers performance of the limitation in the human mind. Specifically, regarding the “in response receiving to the request, verifying the vehicle request, comprising mapping the vehicle request to a user identifier stored in association with a client identifier identifying the third party application” limitation, a user may mentally verify the vehicle request, comprising mapping the vehicle request to a user identifier stored in association with a client identifier identifying the third party application. Also, a user may mentally determine if the “vehicle request” has been received.
Accordingly, the claim recites at least one abstract idea.
101 Analysis – Step 2A, Prong II
Regarding Prong II of the Step 2A analysis in the 2019 PEG, the claims are to be analyzed to determine whether the claim, as a whole, integrates the abstract into a practical application. As noted in the 2019 PEG, it must be determined whether any additional elements in the claim beyond the abstract idea integrate the exception into a practical application in a manner that imposes a meaningful limit on the judicial exception. The courts have indicated that additional elements merely using a computer to implement an abstract idea, adding insignificant extra solution activity, or generally linking use of a judicial exception to a particular technological environment or field of use do not integrate a judicial exception into a “practical application.”
In the present case, the additional limitations beyond the above-noted abstract idea are as follows (where the underlined portions are the “additional limitations” while the bolded portions continue to represent the “abstract idea”):
A method for processing requests for vehicular data, the method comprising, at a remote system:
receiving, from a vehicle, a set of values for a set of vehicle parameters associated with the vehicle;
caching the set of values in association with a first endpoint identifier indicative of the vehicle;
receiving a batch of vehicle requests from a third party application, the batch of vehicle requests comprising a set of endpoint identifiers, the set comprising the first endpoint identifier;
in response receiving to the request, verifying the vehicle request, comprising mapping the vehicle request to a user identifier stored in association with a client identifier identifying the third party application; and
based on the request, transmitting a response to the third party application, the response comprising a value from the set of values.
For the following reason(s), the examiner submits that the above identified additional limitations do not integrate the above-noted abstract idea into a practical application.
Regarding the additional limitation “at a remote system”, the “remote system” is recited at a high level of generality and amounts to nothing more than a generic computer used to apply the exception. The additional limitation “receiving, from a vehicle, a set of values for a set of vehicle parameters associated with the vehicle” amounts to mere data gathering, which is a form of insignificant extra-solution activity. The additional limitation “caching the set of values in association with a first endpoint identifier indicative of the vehicle” amounts to mere data gathering, which is a form of insignificant extra-solution activity. The additional limitation “receiving a batch of vehicle requests from a third party application, the batch of vehicle requests comprising a set of endpoint identifiers, the set comprising the first endpoint identifier" amounts to mere data gathering, which is a form of insignificant extra-solution activity. The additional limitation “based on the request, transmitting a response to the third party application, the response comprising a value from the set of values” amounts to an insignificant extra-solution activity of transmitting data, where the courts have determined that transmission of data does not show an improvement in computer-functionality, see MPEP 2016.05(a), TLI Communications, 823 F.3d at 611-12, 118 USPQ2d at 1747.
Thus, taken alone, the additional elements do not integrate the abstract idea into a practical application. Further, looking at the additional limitation(s) as an ordered combination or as a whole, the limitation(s) add nothing that is not already present when looking at the elements taken individually. For instance, there is no indication that the additional elements, when considered as a whole, reflect an improvement in the functioning of a computer or an improvement to another technology or technical field, apply or use the above-noted judicial exception to effect a particular treatment or prophylaxis for a disease or medical condition, implement/use the above-noted judicial exception with a particular machine or manufacture that is integral to the claim, effect a transformation or reduction of a particular article to a different state or thing, or apply or use the judicial exception in some other meaningful way beyond generally linking the use of the judicial exception to a particular technological environment, such that the claim as a whole is not more than a drafting effort designed to monopolize the exception (MPEP § 2106.05). Accordingly, the additional limitation(s) do/does not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea.
101 Analysis – Step 2B
Regarding Step 2B of the Revised Guidance, independent claim 12 does not include additional elements (considered both individually and as an ordered combination) that are sufficient to amount to significantly more than the judicial exception for the same reasons to those discussed above with respect to determining that the claim does not integrate the abstract idea into a practical application. As discussed above with respect to integration of the abstract idea into a practical application, the “remote system” is recited at a high level of generality and amounts to nothing more than a generic computer used to apply the exception, the additional limitation “receiving, from a vehicle, a set of values for a set of vehicle parameters associated with the vehicle” amounts to mere data gathering, which is a form of insignificant extra-solution activity, the additional limitation “caching the set of values in association with a first endpoint identifier indicative of the vehicle” amounts to mere data gathering, which is a form of insignificant extra-solution activity, the additional limitation “receiving a batch of vehicle requests from a third party application, the batch of vehicle requests comprising a set of endpoint identifiers, the set comprising the first endpoint identifier" amounts to mere data gathering, which is a form of insignificant extra-solution activity, and the additional limitation “based on the request, transmitting a response to the third party application, the response comprising a value from the set of values” amounts to an insignificant extra-solution activity of transmitting data, where the courts have determined that transmission of data does not show an improvement in computer-functionality. Mere instructions to apply an exception using a generic computer component cannot provide an inventive concept. Hence, the claim is not patent eligible.
Dependent claim(s) 13-20 do not recite any further limitations that cause the claim(s) to be patent eligible. Rather, the limitations of dependent claims 13-20 are directed toward additional aspects of the judicial exception and/or well-understood, routine and conventional additional elements that do not integrate the judicial exception into a practical application. Therefore, dependent claims 13-20 are similarly rejected as being directed towards non-statutory subject matter.
Therefore, claim(s) 12-20 are ineligible under 35 USC §101.
See below regarding the dependent claims.
As per Claim 13, said claim is rejected as it fails to correct the deficiency of Claim 12. The claim describes a request, which does not amount to significantly more than the judicial exception.
As per Claim 14, said claim is rejected as it fails to correct the deficiency of Claim 12. The claim describes a set of identifiers, which does not amount to significantly more than the judicial exception.
As per Claim 15, said claim is rejected as it fails to correct the deficiency of Claim 12. The claim amounts to mere data gathering, which is a form of insignificant extra-solution activity, which does not amount to significantly more than the judicial exception.
As per Claim 16, said claim is rejected as it fails to correct the deficiency of Claim 12. The claim amounts to mere data gathering, which is a form of insignificant extra-solution activity, which does not amount to significantly more than the judicial exception.
As per Claim 17, said claim is rejected as it fails to correct the deficiency of Claim 12. The “transmitting” limitation amounts to an insignificant extra-solution activity of transmitting data, where the courts have determined that transmission of data does not show an improvement in computer-functionality, and the “retrieving” limitation amounts to mere data gathering, which is a form of insignificant extra-solution activity. Therefore, the claim does not amount to significantly more than the judicial exception.
As per Claim 18, said claim is rejected as it fails to correct the deficiency of Claim 12. The limitation “receiving, from a second vehicle manufactured by a second OEM different from the first OEM, a second set of values for a second set of vehicle parameters associated with the second vehicle, the second set of vehicle parameters different from the set of vehicle parameters, the second set of vehicle parameters consistent with a second set of OEM rules associated with the second OEM” amounts to mere data gathering, which is a form of insignificant extra-solution activity, and the limitation “caching the second set of values in association with a second endpoint identifier indicative of the second vehicle” amounts to mere data gathering, which is a form of insignificant extra-solution activity. The limitation “the vehicle was manufactured by a first original equipment manufacturer (OEM)” describes a vehicle, which does not amount to significantly more than the judicial exception. The limitation “the set of vehicle parameters are consistent with a first set of OEM rules associated with the first OEM” describes parameters, which does not amount to significantly more than the judicial exception. The limitation “the set of endpoint identifiers further comprises the second endpoint identifier” describes a set of identifiers, which does not amount to significantly more than the judicial exception. Therefore, the claim does not amount to significantly more than the judicial exception.
As per Claim 19, said claim is rejected as it fails to correct the deficiency of Claim 12. The limitation “receiving authentication information, associated with the vehicle, for a platform of an original equipment manufacturer (OEM), wherein the vehicle was manufactured by the first OEM” amounts to mere data gathering, which is a form of insignificant extra-solution activity. The limitation “before receiving the set of values, in response to receiving the authentication information, providing the authentication information to the platform” amounts to an insignificant extra-solution activity of transmitting data, where the courts have determined that transmission of data does not show an improvement in computer-functionality. Therefore, the claim does not amount to significantly more than the judicial exception.
As per Claim 20, said claim is rejected as it fails to correct the deficiency of Claim 12. The claim describes requests, which does not amount to significantly more than the judicial exception.
Claim Rejections - 35 USC § 102
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claims 1-3 and 9-11 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Duri et al. (2004/0267410).
Regarding Claim 1, Duri et al. teaches the claimed method for processing requests for vehicular data, the method comprising, at a remote system:
receiving, from a first vehicle, streaming data indicative of a set of values of a first vehicle parameter of the first vehicle, comprising receiving a most recent value of the set of values (“As the TSP receives updated telematics data, the profile corresponding to the source of any received information can be updated”, see P[0044], also see P[0035]);
after receiving the most recent value, receiving, from a third party application, a vehicle request for the first vehicle parameter (“If a publish request is received by the request processor 425 from an agent, such as agent 415, the request processor can authenticate the requestor…”, see P[0061] and “The agents 335 can be third party application programs configured to interact with the data protection manager. For example, each ASP can provide an agent which can operate as a trusted application within the vehicle computing environment”, see P[0051] and “The agents 405 and 415 are deployed by an ASP or the TSP. Agents are signed by trusted third parties…”, see P[0058]), the vehicle request comprising a first vehicle identifier, wherein the first vehicle identifier is associated with the first vehicle (“If a request for telematics information is received, then either a specific vehicle can be identified from the request for information, or more than one vehicle can be identified from the request”, see [0076]);
in response to receiving the vehicle request, verifying the vehicle request (“The PAD 210 serves several functions. In particular, the PAD 210 can be tasked with requestor verification, whether the requestor is a data owner or an authorized data user”, see P[0041] and “…the PERM 215 can first obtain authorization from the PAD 210 prior to accessing information. In that case, the PERM 215 can be restricted in that only the information that the PERM 215 is authorized to access is retrieved or read. Alternatively, the PERM 215 can be configured to retrieve all data pertaining to a vehicle. Accordingly, the PERM 215 can submit the retrieved or read data from the profile data store 225 to the PAD 210. The PAD 210 then can remove any data that the requester is not authorized to receive”, see P[0047]); and
in response to verifying the vehicle request, transmitting the most recent value to the third-party application (“The repository manager 435 can receive requests for user information, telematics information, and ASP information stored in the data repository 455 and provide requested information to the requestor via the request processor 425”, see P[0060] and “…the telematics data can be continually received and updated”, see P[0073]).
Regarding Claim 2, Duri et al. teaches the claimed method of Claim 1, wherein the vehicle request comprises a multi-parameter request for a plurality of vehicle parameters associated with a plurality of vehicles (“…ASP 155 can subscribe or receive information for vehicles within a particular geographic region, as was the case with ASP 150”, see P[0037]).
Regarding Claim 3, Duri et al. teaches the claimed method of Claim 1, wherein the streaming data is further indicative of, for each value of the set of values, a respective data sampling time at which the value was sampled (“…the telematics data can be continually received and updated”, see P[0073]).
Regarding Claim 9, Duri et al. teaches the claimed method of Claim 1, further comprising, at the remote system:
before receiving the vehicle request, receiving, from a second vehicle, second streaming data indicative of a second set of values of a second vehicle parameter of the second vehicle (“…the TSP 140 can include one or more privacy policies corresponding to vehicles such as vehicle 105 and ASP's 145-160”, see P[0034] and “…ASP 155 can subscribe or receive information for vehicles within a particular geographic region…”, see P[0037] and “If a request for telematics information is received, then either a specific vehicle can be identified from the request for information, or more than one vehicle can be identified from the request”, see [0076]); and
in response to verifying the vehicle request, transmitting at least one value of the second set of values to the third-party application, wherein the vehicle request further comprises a second vehicle identifier, wherein the second vehicle identifier is associated with the second vehicle (“The PAD 210 serves several functions. In particular, the PAD 210 can be tasked with requestor verification, whether the requestor is a data owner or an authorized data user”, see P[0041] and “…the PERM 215 can first obtain authorization from the PAD 210 prior to accessing information. In that case, the PERM 215 can be restricted in that only the information that the PERM 215 is authorized to access is retrieved or read. Alternatively, the PERM 215 can be configured to retrieve all data pertaining to a vehicle. Accordingly, the PERM 215 can submit the retrieved or read data from the profile data store 225 to the PAD 210. The PAD 210 then can remove any data that the requester is not authorized to receive”, see P[0047]).
Regarding Claim 10, Duri et al. teaches the claimed method of Claim 9, wherein verifying the vehicle request comprises verifying that the third-party application is authorized to access information associated with the first vehicle and is authorized to access information associated with the second vehicle (“…the TSP 140 can include one or more privacy policies corresponding to vehicles such as vehicle 105 and ASP's 145-160”, see P[0034] and “…ASP 155 can subscribe or receive information for vehicles within a particular geographic region…”, see P[0037] and “If a request for telematics information is received, then either a specific vehicle can be identified from the request for information, or more than one vehicle can be identified from the request”, see [0076] and “The PAD 210 serves several functions. In particular, the PAD 210 can be tasked with requestor verification, whether the requestor is a data owner or an authorized data user”, see P[0041] and “…the PERM 215 can first obtain authorization from the PAD 210 prior to accessing information. In that case, the PERM 215 can be restricted in that only the information that the PERM 215 is authorized to access is retrieved or read. Alternatively, the PERM 215 can be configured to retrieve all data pertaining to a vehicle. Accordingly, the PERM 215 can submit the retrieved or read data from the profile data store 225 to the PAD 210. The PAD 210 then can remove any data that the requester is not authorized to receive”, see P[0047]).
Regarding Claim 11, Duri et al. teaches the claimed method of Claim 1, further comprising, at the remote system:
receiving a plurality of streaming data, comprising receiving, from each vehicle of a plurality of vehicles: respective streaming data indicative of a respective set of values of a respective vehicle parameter of the respective vehicle (“…the TSP 140 can include one or more privacy policies corresponding to vehicles such as vehicle 105 and ASP's 145-160”, see P[0034] and “…ASP 155 can subscribe or receive information for vehicles within a particular geographic region…”, see P[0037]);
determining, based on the plurality of streaming data, a population-level operational metric for the plurality of vehicles, wherein the population-level operational metric is associated with at least one of: average vehicle range, total active vehicles, or geographic distribution (“ASP 155 can be a diagnostics and roadside assistance ASP that can provide location and event-based services. For example, ASP 155 can subscribe or receive information for vehicles within a particular geographic region, as was the case with ASP 150. Alternatively, ASP 155 need only be aware of a vehicle within the service region when the vehicle is in need of assistance”, see P[0037]); and
transmitting the population-level operational metric to the second third- party application (“For example, an ASP that tracks mileage information can request such information from the TSP data protection manager 340”, see P[0054]).
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.
Claims 4 and 5 are rejected under 35 U.S.C. 103 as being unpatentable over Duri et al. (2004/0267410) in view of Foladare et al. (2011/0196571).
Regarding Claim 4, Duri et al. does not expressly recite “caching” as in the claimed method of Claim 1, further comprising caching the streaming data in storage, wherein caching the streaming data comprises caching the most recent value, wherein transmitting the most recent value to the third-party application comprises retrieving the most recent value from the storage.
However, to cache data is conventional in the art, as seen in Foladare et al. (2011/0196571) (Foladare et al.; see P[0024]).
Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Duri et al. with the teachings of Foladare et al., and the method of Claim 1, further comprising caching the streaming data in storage, wherein caching the streaming data comprises caching the most recent value, wherein transmitting the most recent value to the third-party application comprises retrieving the most recent value from the storage, as rendered obvious by Foladare et al., so that the vehicle data may be “cached for future use” (Foladare et al.; see P[0024]).
Regarding Claim 5, Duri et al. teaches the claimed method of Claim 4, wherein the streaming data is cached based on at least one of:
temporal parameters, data parameters, request rules, permission settings, or access tokens (“…the telematics data can be continually received and updated”, see P[0073], where telematics data is equivalent to “data parameters”).
Claim 6 is rejected under 35 U.S.C. 103 as being unpatentable over Duri et al. (2004/0267410) in view of Foladare et al. (2011/0196571) further in view of Moser et al. (8,438,238).
Regarding Claim 6, Duri et al. teaches the claimed method of Claim 4, further comprising, after caching the most recent value and retrieving the most recent value from the storage, in response to a scheduled data retention time period elapsing, deleting the most recent value from the storage.
However, Moser et al. (8,438,238) teaches deleting old entries from a cache based on a time of last access (Moser et al.; see col.21, particularly lines 42-44).
Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Duri et al. with the teachings of Moser et al., and the method of Claim 4, further comprising, after caching the most recent value and retrieving the most recent value from the storage, in response to a scheduled data retention time period elapsing, deleting the most recent value from the storage, as rendered obvious by Moser et al., “so that old entries can be deleted from the cache” (Moser et al.; see col.21, lines 42-44).
Claims 7 and 8 are rejected under 35 U.S.C. 103 as being unpatentable over Duri et al. (2004/0267410) in view of Haidar et al. (2016/0071333).
Regarding Claim 7, Duri et al. does not expressly recite the claimed method of Claim 1, wherein the vehicle request further comprises an access token associated with the third party application.
However, the use of a token to allow access to vehicle data is conventional in the art, as seen in Haidar et al. (2016/0071333), where Haidar et al. teaches allowing an application to access vehicle data by validating a token provided by the application (Haidar et al.; see P[0126]-P[0129]).
Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Duri et al. with the teachings of Moser et al., and wherein the vehicle request further comprises an access token associated with the third party application, as rendered obvious by Haidar et al., in order to provide for “authorizing a vehicle information platform application” (Haidar et al.; see P[0018]).
Regarding Claim 8, Duri et al. does not expressly recite the claimed method of Claim 7, wherein verifying the vehicle request comprises:
authenticating a redirection URI associated with the access token; and
verifying that the redirection URI corresponds to a permitted domain for the third party application.
However, Haidar et al. (2016/0071333), teaches a redirection URI associated with an access token, where a redirect URI may match a redirect URI registered for the client (Haidar et al.; see P[0140]-P[0142]), where this matching process is equivalent to a “verifying” of the redirect URI, and where the clamed “permitted domain” is equivalent to the redirect URI itself.
Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Duri et al. with the teachings of Moser et al., and wherein verifying the vehicle request comprises: authenticating a redirection URI associated with the access token; and verifying that the redirection URI corresponds to a permitted domain for the third party application, as rendered obvious by Haidar et al., in order to provide for “authorizing a vehicle information platform application” (Haidar et al.; see P[0018]).
Claims 12-20 are rejected under 35 U.S.C. 103 as being unpatentable over Madhok et al. (2014/0189888) in view of Foladare et al. (2011/0196571) further in view of Laghrari et al. (2009/0012675).
Regarding Claim 12, Madhok et al. teaches the claimed method for processing requests for vehicular data, the method comprising, at a remote system:
receiving, from a vehicle, a set of values for a set of vehicle parameters associated with the vehicle (“…a secure data container…reifies the vehicle as a digital identity in its own right and provides mechanisms to unify vehicle related data and associated relationships in a linked data cloud…enable unified vehicle and driver data to be linked to the vehicle via the cloud...the unified data can include: status attributes of the vehicle, such as its make, model, year, vehicle identification number (VIN), etc.; usage data, such as mileage, fuel level, oil level, etc.; real-time performance data, such as speed, location, traffic, torque, fuel efficiency, bumps jumped over/pothole encountered, etc.”, see P[0010] and “A user can configure an embodiment to automatically send a vehicle-based Distributed Shared Data Object to their vehicle dealer and OEM whenever the vehicle detects an abnormality with the operation or status of the vehicle”, see P[0026]);
storing the set of values in association with a first endpoint identifier indicative of the vehicle (“All of the static attributes of the vehicle, such as the make, model year color, brand, VIN, etc, as well as the vehicle's dynamic attributes, such as mileage, speed, location, destination, rating, emissions, resale value, registration, insurance data, and the like can be associated with the persistent digital identifier of the vehicle”, see P[0057] and P[0078]);
receiving…vehicle requests from a third party application (“…the data aggregator 226 can link data objects from the Vehicle X collection of information with data objects from other vehicle information collections or information collections from other endpoints”, see P[0076] and “The Vehicle Reification and Digital Vehicle Registry Service of an example embodiment provides all of the services required to reify vehicles as digital endpoints…”, see P[0058] and “This standard or common representation can be used for a plurality of collections of information from a plurality of vehicles”, see P[0074] and “If the Vehicle-based Distributed Shared Data Object Service Module 240 can validate the requesting endpoint 282, the Vehicle-based Distributed Shared Data Object Service Module 240 can generate a secure access token, which can be used by the requesting endpoint 282 to obtain access to the shared data set of vehicle 280 and its associated user(s) via an associated secure container…once the Vehicle-based Distributed Shared Data Object Service Module 240 validates the requesting endpoint 282. the Vehicle-based Distributed Shared Data Object Service Module 240 can transmit a secure access token to the requesting endpoint 282 via network 105”, see P[0082]), the…vehicle requests comprising a set of endpoint identifiers, the set comprising the first endpoint identifier (“The secure access token is a data structure that retains information that identities the associated secure container and retains access control information that defines the access rights over the associated secure container and thus the access rights to the shared data approved by the originating user”, see P[0082]);
in response receiving to the request, verifying the vehicle request, comprising mapping the vehicle request to a user identifier stored in association with a client identifier identifying the third party application (“The Data Access/Sharing Control Enforcement Service Module 250 can identify the presenting endpoint 284 and validate the secure access token against the access controls established for the corresponding secure container and the sharing controls established for the shared data set by the originating user associated with vehicle 280”, see P[0083]); and
based on the request, transmitting a response to the third party application, the response comprising a value from the set of values (“If the Data Access/Sharing Control Enforcement Service Module 250 can validate the presenting endpoint 284 based on the presented secure access token. the Data Access/Sharing Control Enforcement Service Module 250 can enable the endpoint 284 to obtain access to the shared data set of vehicle 280 and its associated user(s) via an associated secure container”, see P[0083] and P[0084] as cited above).
Madhok et al. does not expressly recite the bolded portions of the claimed
caching the set of values in association with a first endpoint identifier indicative of the vehicle
and
receiving a batch of vehicle requests from a third party application, the batch of vehicle requests comprising a set of endpoint identifiers, the set comprising the first endpoint identifier.
However, to cache data is conventional in the art, as seen in Foladare et al. (2011/0196571) (Foladare et al.; see P[0024]).
Furthermore, to simply batch requests for data into a batch data request and to generate a set of data in response to receiving the batch data request was a conventional technique in the art, as seen in Laghrari et al. (2009/0012675) (Laghrari et al.; see P[0022]-P[0029]).
Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Madhok et al. with the teachings of Foladare et al. and Laghrari et al., and caching the set of values in association with a first endpoint identifier indicative of the vehicle, and receiving a batch of vehicle requests from a third party application, the batch of vehicle requests comprising a set of endpoint identifiers, the set comprising the first endpoint identifier, as rendered obvious by Foladare et al. and Laghrari et al., so that the vehicle data may be “cached for future use” (Foladare et al.; see P[0024]), and in order to perform steps of “sending a status request message” and “receiving a status response message” (Laghrari et al.; see P[0004]).
Regarding Claim 13, Madhok et al. teaches the claimed method of Claim 12, wherein the…vehicle requests comprises a multi-parameter request, the multi-parameter request comprising a plurality of vehicle parameters associated with a plurality of vehicles (“…a secure data container…reifies the vehicle as a digital identity in its own right and provides mechanisms to unify vehicle related data and associated relationships in a linked data cloud…enable unified vehicle and driver data to be linked to the vehicle via the cloud...the unified data can include: status attributes of the vehicle, such as its make, model, year, vehicle identification number (VIN), etc.; usage data, such as mileage, fuel level, oil level, etc.; real-time performance data, such as speed, location, traffic, torque, fuel efficiency, bumps jumped over/pothole encountered, etc.”, see P[0010] and “A user can configure an embodiment to automatically send a vehicle-based Distributed Shared Data Object to their vehicle dealer and OEM whenever the vehicle detects an abnormality with the operation or status of the vehicle”, see P[0026]).
Madhok et al. does not expressly recite the bolded portions of the claimed
wherein the batch of vehicle requests comprises a multi-parameter request, the multi-parameter request comprising a plurality of vehicle parameters associated with a plurality of vehicles.
However, to simply batch requests for data into a batch data request and to generate a set of data in response to receiving the batch data request was a conventional technique in the art, as seen in Laghrari et al. (2009/0012675) (Laghrari et al.; see P[0022]-P[0029]).
Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Madhok et al. with the teachings of Foladare et al. and Laghrari et al., and wherein the batch of vehicle requests comprises a multi-parameter request, the multi-parameter request comprising a plurality of vehicle parameters associated with a plurality of vehicles, as rendered obvious by Laghrari et al., in order to perform steps of “sending a status request message” and “receiving a status response message” (Laghrari et al.; see P[0004]).
Regarding Claim 14, Madhok et al. teaches the claimed method of Claim 12, wherein the set of endpoint identifiers comprises at least one of: a vehicle identifier, a user identifier, or a vehicle population identifier (“The Data Access/Sharing Control Enforcement Service Module 250 can identify the presenting endpoint 284 and validate the secure access token against the access controls established for the corresponding secure container and the sharing controls established for the shared data set by the originating user associated with vehicle 280”, see P[0083]).
Regarding Claim 15, Madhok et al. teaches the claimed method of Claim 12, further comprising, at the remote system, receiving, from the vehicle, for each value of the set of values, a respective data sampling time at which the value was sampled (“In another embodiment, the VIN number can be concatenated (or otherwise combined with) with a user name/identifier, a time/date stamp, a location identifier, a random number, or other information to generate a unique persistent digital identity. This persistent digital identity can be linked to, associated with, combined with, or used to index the assembled collection of information corresponding to the vehicle 280 from which the persistent digital identity was derived”, see P[0073]).
Regarding Claim 16, Madhok et al. teaches the claimed method of Claim 12, further comprising, in response to receiving the streaming data, storing at least a subset of the streaming data in a storage, comprising, in response to receiving the most recent value, storing the most recent value in the storage (“A user can configure an embodiment to automatically send a vehicle-based Distributed Shared Data Object to their vehicle dealer and OEM whenever the vehicle detects an abnormality with the operation or status of the vehicle”, see P[0026]).
Regarding Claim 17, Madhok et al. teaches the claimed method of Claim 16, wherein transmitting the most recent value to the third-party application comprises retrieving the most recent value from the storage (“The data sharing controls can include Synchronization controls enabling the recipient to get a copy of the latest data as it changes in real-time”, see P[0030]).
Regarding Claim 18, Madhok et al. teaches the claimed method of Claim 12, wherein:
the vehicle was manufactured by a first original equipment manufacturer (OEM) (see P[0025]-P[0026]);
the set of vehicle parameters are consistent with a first set of OEM rules associated with the first OEM (“…the vehicle-based Distributed Shared Data Object of an example embodiment can be used to send problem reports and diagnostics data back to the vehicle dealer and/or OEM so the problem/condition can be reported in real-time and analyzed individually or as a whole (aggregated problem/issue data across all cars of a certain model, make, year, etc.)”, see P[0026]);
the method further comprises:
receiving, from a second vehicle manufactured by a second OEM different from the first OEM, a second set of values for a second set of vehicle parameters associated with the second vehicle, the second set of vehicle parameters different from the set of vehicle parameters, the second set of vehicle parameters consistent with a second set of OEM rules associated with the second OEM (“The Vehicle Reification and Digital Vehicle Registry Service of an example embodiment provides all of the services required to reify vehicles as digital endpoints and the services required to register the digital endpoints with the digital vehicle registry in the network cloud”, see P[0058] and “…the vehicle-based Distributed Shared Data Object of an example embodiment can be used to send problem reports and diagnostics data back to the vehicle dealer and/or OEM so the problem/condition can be reported in real-time and analyzed individually or as a whole (aggregated problem/issue data across all cars of a certain model, make, year, etc.)”, see P[0026]); and
storing the second set of values in association with a second endpoint identifier indicative of the second vehicle (“All of the static attributes of the vehicle, such as the make, model year color, brand, VIN, etc, as well as the vehicle's dynamic attributes, such as mileage, speed, location, destination, rating, emissions, resale value, registration, insurance data, and the like can be associated with the persistent digital identifier of the vehicle”, see P[0057]);
the set of endpoint identifiers further comprises the second endpoint identifier (“The secure access token is a data structure that retains information that identities the associated secure container and retains access control information that defines the access rights over the associated secure container and thus the access rights to the shared data approved by the originating user”, see P[0082]); and
the response further comprises a second value from the second set of values (“If the Data Access/Sharing Control Enforcement Service Module 250 can validate the presenting endpoint 284 based on the presented secure access token. the Data Access/Sharing Control Enforcement Service Module 250 can enable the endpoint 284 to obtain access to the shared data set of vehicle 280 and its associated user(s) via an associated secure container”, see P[0083] and P[0084] as cited above).
Madhok et al. does not expressly recite the bolded portions of the claimed
caching the second set of values in association with a second endpoint identifier indicative of the second vehicle.
However, to cache data is conventional in the art, as seen in Foladare et al. (2011/0196571) (Foladare et al.; see P[0024]).
Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Madhok et al. with the teachings of Foladare et al. and Laghrari et al., and caching the second set of values in association with a second endpoint identifier indicative of the second vehicle, as rendered obvious by Foladare et al., so that the vehicle data may be “cached for future use” (Foladare et al.; see P[0024]).
Regarding Claim 19, Madhok et al. teaches the claimed method of Claim 12, further comprising, at the remote system:
receiving authentication information, associated with the vehicle, for a platform of an original equipment manufacturer (OEM), wherein the vehicle was manufactured by the first OEM (“The Vehicle Reification and Digital Vehicle Registry Service of an example embodiment provides all of the services required to reify vehicles as digital endpoints and the services required to register the digital endpoints with the digital vehicle registry in the network cloud. The registration of the digital endpoints and an associated secure data container enables users (e.g., drivers, dealers, resellers, and the like), mobile apps, and services to access, update and share data sets of the secure data container linked to the digital endpoints under the explicit control of the user and/or the original equipment manufacturer (OEM)”, see P[0058] and P[0026], and “…when a vehicle-based Distributed Shared Data Object is shared, the recipient receives a secure access token as an encrypted link. When the recipient de-references the secure access token (e.g., the user clicks on the link), an embodiment presents the secure access token to the vehicle-based Distributed Shared Data Object delivery gateway (e.g., a content delivery network), which authenticates that the user who is presenting the secure access token is indeed the user to whom the secure access token was sent, authorizes the data to be shared with the recipient (e.g., looks up the data sharing policy referenced by the secure access token)”, see P[0035] and all citations of the parent claim rejection); and
before receiving the set of values, in response to receiving the authentication information, providing the authentication information to the platform (“…when a vehicle-based Distributed Shared Data Object is shared, the recipient receives a secure access token as an encrypted link. When the recipient de-references the secure access token (e.g., the user clicks on the link), an embodiment presents the secure access token to the vehicle-based Distributed Shared Data Object delivery gateway (e.g., a content delivery network), which authenticates that the user who is presenting the secure access token is indeed the user to whom the secure access token was sent, authorizes the data to be shared with the recipient (e.g., looks up the data sharing policy referenced by the secure access token)”, see P[0035] and all citations of the parent claim rejection).
Regarding Claim 20, Madhok et al. in view of Laghrari et al. renders obvious the claimed method of Claim 12, wherein the batch of vehicle requests comprises:
a first request associated with the first endpoint identifier; and
a second request associated with the first endpoint identifier,
where it would have been obvious to a person having ordinary skill in the art before the filing date of the claimed invention to send any number of requests for data of a single vehicle, such as a request from each one of multiple “authorized endpoints” of Madhok et al. (see P[0083]), and where batching multiple requests is known from Laghrari et al. (2009/0012675) (Laghrari et al.; see P[0022]-P[0029]).
Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Madhok et al. with the teachings of Foladare et al. and Laghrari et al., and wherein the batch of vehicle requests comprises: a first request associated with the first endpoint identifier; and a second request associated with the first endpoint identifier, as rendered obvious by Laghrari et al., in order to perform steps of “sending a status request message” and “receiving a status response message” (Laghrari et al.; see P[0004]).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ISAAC G SMITH whose telephone number is (571)272-9593. The examiner can normally be reached Monday-Thursday, 8AM-5PM.
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, ANISS CHAD can be reached at 571-270-3832. 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.
/ISAAC G SMITH/ Primary Examiner, Art Unit 3662
Prosecution Insights