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 .
Election/Restrictions
The Election/Restriction requirement of 16 December 2025 has been withdrawn in light of the amendments filed 4 February 2026 because the distinct groupings are no longer present based on the changed dependencies and independent claims.
Claim Objections
Claims 12, 13, and 15 are objected to because of the following informalities: the claims recite "wherein for a cases". This is not proper grammar and does not make logical sense. Applicant is encouraged to review all the claim language for additional grammatical errors similar to the ones identified. Appropriate correction is required.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. In the instant case, claim 1 is directed to a “position and paying method based on internet of vehicles applied to an in-vehicle client having a first digital currency wallet”.
Claim 1 is directed to the concept of “paying for a service” which is grouped under “organizing human activity… fundamental economic practice, commercial or legal interactions, and managing personal behavior or relationships” in prong one of step 2A (See MPEP 2106.04(a)(2)). Claim 1 recites sending a service request to a service provider, and receiving a service entity identifier sent by the service provider with regard to the service request; in cases where the first [digital] currency wallet completes payment authorization with regard to the service entity identifier, receiving fee deduction information sent by the service provider, and generating a payment [digital] currency string matching the fee deduction information by means of the first [digital] currency wallet; and transmitting the payment [digital] currency string to a second [digital] currency wallet included in the service provider. Accordingly, the claim recites an abstract idea (See MPEP 2106.04(a)(2)). Notably, claims 1-6 contain no disclosure on what or who is performing the method steps, which under the broadest reasonable interpretation, a human is performing all the steps which can also be considered a mental process.
This judicial exception is not integrated into a practical application because, when analyzed under prong two of step 2A (See MPEP 2106.04(d)), the additional elements of the claim such as a management server, a service entity client, one or more processors, a storage device represent the use of a computer as a tool to perform an abstract idea and/or does no more than ‘Apply it’ the abstract idea to a particular field of use (MPEP 2106.05(f)&(h)). The digital currency is an additional element and does not integrate the abstract idea into a practical application because the limitation generally links the use of the abstract idea (paying for a service) to a particular technological environment or field of use (MPEP 2106.05(h)), that of digital currency. Therefore, the additional elements do not integrate the abstract idea into a practical application as they do no more than represent a computer performing functions that correspond to (i.e. implement) the acts of paying for a service.
When analyzed under step 2B (See MPEP 2106.05), the claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception itself. The digital currency is an additional element and does not integrate the abstract idea into a practical application because the limitation generally links the use of the abstract idea (paying for a service) to a particular technological environment or field of use (MPEP 2106.05(h)), that of digital currency. Viewed as a whole, the combination of elements recited in the claims merely describe the concept of paying for a service using computer technology (e.g. one or more processors, an in-vehicle client, a management server, and a service entity client). Therefore, the use of these additional elements does no more than employ a computer as a tool to automate and/or implement the abstract idea, which cannot provide significantly more than the abstract idea itself (MPEP 2106.05(I)(A)(f) & (h)).
Dependent claims 2-16 and 18-19 do not remedy the deficiencies of the independent claims and are rejected accordingly. The dependent claims further refine the abstract idea of the independent claims and do not integrate the abstract idea into a practical application In this case, all claims have been reviewed and are found to be substantially similar and linked to the same abstract idea (see Content Extraction and Transmission LLC v. Wells Fargo (Fed. Cir. 2014)).
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.
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claim(s) 1-4, and 7-20 is/are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Nokia EP 3416117.
As per claim 1:
Nokia discloses a positioning and paying method based on Internet of Vehicles, applied to an in-vehicle client having a first digital currency wallet (Fig 2 ‘23’, ¶¶ [0040]-[0041], [0044]-[0047], [0107]), comprising:
sending a service request to a service provider (¶ [0065]), and receiving a service entity identifier sent by the service provider with regard to the service request (¶¶ [0066]-[0070], [0104], [0111]);
in cases where the first digital currency wallet completes payment authorization with regard to the service entity identifier, receiving fee deduction information sent by the service provider (¶¶ [0106], [0109]-[0115]), and
generating a payment digital currency string matching the fee deduction information by means of the first digital currency wallet (¶¶ [0106], [0109]-[0115]); and
transmitting the payment digital currency string to a second digital currency wallet included in the service provider (¶¶ [0044], [0109]-[0115]).
As per claim 2:
Nokia further discloses the method as claimed in claim 1, wherein the service request comprises position information and a service type (¶¶ [0068]-[0069]);
the receiving a service entity identifier sent by the service provider with regard to the service request comprises:
receiving the service entity identifier sent by the service provider and corresponding to the position information and the service type (¶¶ [0068]-[0070]).
As per claim 3:
Nokia further discloses the method as claimed in claim 2, further comprising:
calculating, in response to receiving a service trigger, position information by means of any one or more of Internet of Vehicles distance information, map information of a vehicle where the in-vehicle client is located, image information of the vehicle, and geographical information indicated by a positioning system (¶¶ [0045]-[0047]); and
encapsulating the position information into the service request (¶¶ [0045]-[0047]).
As per claim 4:
Nokia further discloses the method as claimed in claim 1, after the receiving a service entity identifier sent by the service provider with regard to the service request, the method further comprising: generating authorization prompt information including the service entity identifier (Fig 3, ¶¶ [0061]-[0069]); and
determining, in response to authorization processing with regard to the authorization prompt information, that the first digital currency wallet completes payment authorization with regard to the service entity identifier (Fig 3, ¶¶ [0061]-[0069]).
As per claim 7:
Nokia further discloses the method as claimed in claim 1 further comprising:
in response to receiving a service request from an in-vehicle client (¶ [0065]), a management server (¶¶ [0036]-[0037] ‘server’) determining a service entity identifier according to position information and a service type which are indicated by the service request (¶¶ [0009], [0066]-[0068]);
the management server sending the service entity identifier to the in-vehicle client, so that a first digital currency wallet comprised in the in-vehicle client performs a payment authorization operation with regard to the service entity identifier (¶¶ [0066]-[0070], [0104], [0111]); and
after a service entity corresponding to the service entity identifier completes a service, the management server determining a payment status of the first digital currency wallet (¶¶ [0053]-[0054], see also ¶¶ [0044], [0109]-[0115]).
As per claim 8:
Nokia further discloses the method as claimed in claim 7, wherein the management server determining a service entity identifier according to position information and a service type which are indicated by the service request comprises:
the management server determining position information of one or more service entities according to the position information of the vehicle; and on the basis of a preset policy, the management server selecting, from position information of the one or more service entities, the service entity identifier for providing a service for a vehicle where the in-vehicle client is located (¶¶ [0066]-[0068]).
As per claim 9:
Nokia further discloses the method as claimed in claim 8, wherein the preset policy comprises: acquiring coordinate information indicated by a map including various service entities(¶¶ [0066]-[0068]); calculating distance values on the basis of the coordinate information of the service entities and coordinate information included in the position information of the vehicle where the in-vehicle client is located (¶¶ [0066]-[0068]); and selecting a service entity corresponding to a minimum distance value as a service entity corresponding to the vehicle (¶¶ [0066]-[0068]).
As per claim 10:
Nokia further discloses the method as claimed in claim 8, wherein the preset policy comprises: determining whether a service entity is an optional service entity which is able to provide a service for the vehicle according to the position information of the vehicle where the in-vehicle client is located and the image data of various service entities (¶¶ [0066]-[0068], [0079]); and selecting, from optional service entities, an optional service entity with a minimum distance value from the vehicle as a service entity corresponding to the vehicle (¶¶ [0066]-[0068]).
As per claim 11:
Nokia further discloses the method as claimed in claim 8, wherein the preset policy comprises: on the basis of sensors included in the service entities, acquiring distance values between various service entities and the vehicle where the in-vehicle client is located; and selecting a service entity with a minimum distance value as a service entity corresponding to the vehicle (Figs 6 ‘67’, 7A-E, ¶¶ [0092]-[0101]).
As per claim 12: Nokia further discloses the method as claimed in claim 7, wherein for a cases where a second digital currency wallet is provided in the management server, the management server determining a payment status of the first digital currency wallet, comprises: the management server verifying the payment digital currency string after the second digital currency wallet receives the payment digital currency string sent from the first digital currency wallet (¶¶ [0072]-[0075]); and
after the verification is passed, the management server determining that the first digital currency wallet completes payment (¶¶ [0072]-[0075]).
As per claim 13:
Nokia further discloses the method as claimed in claim 7, wherein for a cases where the second digital currency wallet is provided in the service entity client, the management server determining a payment status of the first digital currency wallet, comprises: the management server receiving a payment status sent by the server entity client with regard to the first digital currency wallet (¶¶ [0072]-[0075]).
As per claim 14:
Nokia further discloses the method as claimed in claim 1 further comprising: in response to a service entity initiating a service, a service entity client metering and charging the service of the service entity (Figs 7A-E, ¶ [0094], see also [0106]);
the service entity client determining a service fee in response to the service entity completing the service (¶ [0106] agreement between mobile entity and transaction entity on terms of a transaction comprising a price would include a fee or be considered a fee); and
the service entity client sending the service fee to an in-vehicle serving end, so that the in-vehicle serving end pays the service fee by means of the first digital currency wallet (Fig 8, ¶ [0108]-[0110]).
As per claim 15:
Nokia further discloses the method as claimed in claim 14, wherein for a cases where a second digital currency wallet is provided in the service entity client,
the service entity client receiving, by means of the second digital currency wallet, the service fee paid by the in-vehicle serving end by means of the first digital currency wallet (¶¶ [0044], [0109]-[0115]).
As per claim 16:
Nokia further discloses the method as claimed in claim 14, further comprising:
the service entity client acquiring, from a management server, a wallet identifier of the first digital currency wallet included in the in-vehicle client that is served (¶¶ [0044], [0109]-[0115]); and
the service entity client generating a page including the wallet identifier to enable a user to initiate a service using the page (¶¶ [0044], [0109]-[0115]).
As per claim 17: Claim 17 is rejected under the rationale of claim 1.As per claim 18: Claim 18 is rejected under the rationale of claim 7.As per claim 19: Claim 19 is rejected under the rationale of claim 14.
As per claim 20:
Claim 20 is rejected under the rationales of claims 1, 7, and 14.
Claim Rejections - 35 USC § 103
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 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim(s) 5-6 is/are rejected under 35 U.S.C. 103 as being unpatentable over Nokia EP 3416117 in view of Patil US 2018/0374126.
As per claim 5:
Nokia further discloses the method as claimed in claim 4,
if the verification is passed, determining that the first digital currency wallet completes payment authorization with regard to the service entity identifier (¶ [0086]).
Nokia fails to explicitly disclose but Patil does disclose wherein the authorization prompt information comprises: a password control, wherein the password control instructs to input a payment password of the first digital currency wallet (¶¶ [0193]-[0194]);
the determining, in response to authorization processing with regard to the authorization prompt information, that the first digital currency wallet completes payment authorization with regard to the service entity identifier comprises:
in response to receiving the payment password, verifying the payment password by using the first digital currency wallet (¶¶ [0193]-[0194]);
It would have been obvious to one of ordinary skill in the art before the effective filing date to include the features as taught in Patil in Nokia since the claimed invention is merely a combination of old elements, and in combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable. Both are in the art of in vehicle transaction and it would have been obvious to a person skilled in the art to combine the art to improve security and including password control or access control to a computer system is widely practiced which would yield predictable results.
As per claim 6:
Nokia further discloses the method as claimed in claim 5, further comprising:
the first digital currency wallet communicating with the second digital currency wallet by means of a direct communication interface (Figs 7A-E, ¶ [0094]);
the transmitting the payment digital currency string to a second digital currency wallet included in the service provider comprises:
transmitting, by the first digital currency wallet, the payment digital currency string to the second digital currency wallet by means of the direct communication interface (¶¶ [0032], [0048]).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Chen US 2025/0315813 Gyllenram US 2023/0169497 Isaacson US 2019/0230070 Rao US 2020/0134592
Any inquiry concerning this communication or earlier communications from the examiner should be directed to DAVID P SHARVIN whose telephone number is (571)272-9863. The examiner can normally be reached M-F 9 am - 5 pm EST.
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, Ryan Donlon can be reached at 571-270-3602. 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.
/DAVID P SHARVIN/Primary Examiner, Art Unit 3692
Prosecution Insights