DETAILED ACTION
Acknowledgements
This action is in response to Applicant’s filing on Aug. 1, 2025, and is made Non-Final. This action is being examined by James H. Miller, who is in the eastern time zone (EST), and who can be reached by email at James.Miller1@uspto.gov or by telephone at (469) 295-9082.
Interviews
Examiner interviews are available by telephone or, preferably, by video conferencing using the USPTO’s web-based collaboration platform. Applicants are strongly encouraged to schedule via the USPTO Automated Interview Request (AIR) portal at http://www.uspto.gov/interviewpractice. Each AIR should specifically explain how the interview will advance prosecution—for example, by identifying targeted arguments responsive to the rejection of record, alleged defects in the examiner’s analysis, proposed claim amendments, or another concrete basis for discussion. See MPEP § 713. “Sounding out” the examiner is not permitted. See MPEP § 713.03. The Office is strictly enforcing interview practice.
The examiner is generally available Monday through Friday, 10:00 a.m. to 4:00 p.m. Eastern Time. For any GRANTED Interview Request, the applicant can expect an email within 24 hours confirming an interview slot from the dates/times proposed and providing collaboration tool access instructions. For any DENIED Interview Request, the record will include a communication explaining the reason for denial.
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 .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on Aug. 1, 2025, has been entered.
Claim Status
The status of claims is as follows:
Claims 1, 3, 6, 7, 10, 12, 15, 16, 19, 20, 21, 22, and 23 are now pending and examined with Claims 1, 10, and 19 in independent form.
Claims 1, 3, 6, 7, 10, 12, 15, 16, 19,and 20 are presently amended.
Claims 2, 8, 9, 11, 17, and 18 are presently cancelled.
Claims 21, 22, and 23, are presently added.
Response to Amendment
Applicant's Amendment has been reviewed against Applicant’s Specification filed Aug. 16, 2023, [“Applicant’s Specification”] and accepted for examination.
Applicant's Amendment to address the rejection under 35 U.S.C. § 112(a) has been reviewed and has overcome each and every rejection under § 112(a) previously set forth in the Final Office Action mailed Apr. 1, 2025 [“Final Office Action"]. The rejection of Claims 1–3, 6–12, and 15–20 under § 112(a) is withdrawn.
Response to Arguments
35 U.S.C. § 101 Argument
Applicant’s arguments have been fully considered and are persuasive. Applicant’s Reply 18 (practical application). The rejection of Claims 1, 3, 6, 7, 10, 12, 15, 16, 19, 20, 21, 22, and 23 under § 101 is withdrawn. The claims are eligible under 35 USC § 101. Independent Claims are directed to a statutory category, recite an abstract idea exception, but integrate the abstract idea exception into a practical application in some other meaningful way through additional meaningful limitations when viewed as an ordered combination. MPEP § 2106.05(e) In combination, the additional meaningful limitations of exemplary Claim 1 are:
1. A system mounted within a vehicle comprising: a processor of the vehicle; and a memory in communication with the processor, the memory containing instructions that, when executed by the processor, cause the processor tothe location of the vehicle and the operating state of the vehicle; detect an entry of the vehicle into a predetermined geo-fenced location based on the sensor data, the predetermined geo-fenced location comprising a point of interest; automatically control a display device to show a welcome interface upon detecting entry into the geo-fenced location, thereby indicating the presence of the vehicle at the point of interest further detect whether the vehicle has moved to a predetermined specialized region within the geo-fenced location, and is currently located at the predetermined specialized region, the predetermined specialized region comprising a vehicle parking location of the point of interest; further automatically control the display device to show information about the vehicle parking location and payment details upon detecting the vehicle at the parking location, based at least on detecting the vehicle is currently located at the vehicle parking location of the point of interest; and through the screen of the display device of the vehicle, at least partly process the payment details for the use of the vehicle parking location, thereby displaying the status of the parking use and, upon completion of payment, details of the payment.
These are meaningful limitations that are more than applying the use of the abstract idea to a computer. These limitations, in combination, are indicative of practical application. MPEP § 2106.05(e). Claims 1, 3, 6, 7, 10, 12, 15, 16, 19, 20, 21, 22, and 23, in ordered combination, are integrated into a practical application by specifying a vehicle system that monitors and updates the location of the vehicle and the operating state of the vehicle over time to detect an entry of the vehicle into a predetermined geo-fenced location, automatically control the vehicle display device to show information about the vehicle parking location and payment details, and at least partly process the payment details for the use of the vehicle parking location without exiting the vehicle. MPEP § 2106.05(e). Furthermore, as an ordered combination, the clam limitations are also not well-understood routine or conventional.
35 U.S.C. § 103 Argument
Applicant’s arguments with respect to Claims 1, 3, 6, 7, 10, 12, 15, 16, 19, 20, 21, 22, and 23 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
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.
Claims 1, 3, 6, 7, 10, 12, 15, 16, 19, 20, 21, and 23 are rejected under 35 U.S.C. 103 as being unpatentable over Enriquez et al. (U.S. Pat. Pub. No. 2017/0127230) [“Enriquez”] in view of Lee et al. (U.S. Pat. Pub. No. 2022/0005017) [“Lee”].
Regarding Claim 1, Enriquez discloses
A system mounted within a vehicle comprising: a processor of the vehicle; and a memory in communication with the processor, the memory containing instructions that, when executed by the processor, cause the processor to
(See at least ¶ 3, “an in-vehicle computing system may include a user interface, a processor, and a memory coupled to the processor. The memory may store a set of computer executable instructions including an in-vehicle access application that has a proximity mode of operation and a tolling mode of operation.” See also ¶¶ 51, 52)
control one or more sensors to determine a location of the vehicle and
(See at least ¶ 46, “vehicle 100 may include a positioning satellite receiver 170 such as a GPS receiver to receive satellite signals that can be demodulated and decoded to determine the location of vehicle 100.” See also, ¶ 58.)
an operating state of the vehicle, in which the vehicle operating state indicates at least whether the vehicle is stationary;
(See at least ¶ 59, “in-vehicle computing system 150 can determine that vehicle 100 is in a stopped position when the vehicle status signal indicates that a transmission mode of the vehicle is in park, and that vehicle 100 is moving when the vehicle status signal indicates that a transmission mode of the vehicle is in drive … in-vehicle computing system 150 can determine that vehicle 100 is in a stopped position when the vehicle status signal indicates that vehicle 100 has been motionless (e.g., zero or near-zero speed such as less than 5 mph, etc.) for over a threshold amount of time (e.g., 15 seconds, 30 seconds, 1 minute, etc.).”
monitor and update the location of the vehicle and the operating state of the vehicle over time based on sensor data obtained by controlling the one or more sensors to determine the location of the vehicle and the operating state of the vehicle;
(See at least ¶ 20, “The in-vehicle computing system may monitor the state of the vehicle. Depending on the state of the vehicle, the in-vehicle access application can be activated into different modes of operation.” “Process 200 may begin at block 202 by receiving a vehicle status signal from a vehicle communication bus. The vehicle status signal may include vehicle information from the ECUs of the vehicle and/or information from various sensors of the vehicle. In some embodiments, the vehicle status signal may include information indicating the speed of the vehicle and/or the transmission mode that the vehicle is in.” ¶ 65. “At block 204, process 200 may determine, based on a first state of the vehicle status signal at a first point in time, that the vehicle is in a stopped position.” ¶ 66. “At block 208, process 200 may determine, based on a second state of the vehicle status signal at a second point in time, that the vehicle is moving or in motion.” ¶ 68. “When a vehicle is determined to be in a stopped position, a first mode of operation of the in-vehicle access application can be activated. When a vehicle is determined to be moving, a second mode of operation of the in-vehicle access application can be activated.” Abstract.)
detect an entry of the vehicle into a predetermined geo-fenced location based on the sensor data, the predetermined geo-fenced location comprising a point of interest;
(See at least ¶ 60, “In some embodiments, geo-fencing (e.g., via use of GPS or beacons), visual awareness (e.g., using a camera of vehicle 100), and/or location of vehicle 100 can be used to detect a nearby access device.” “As vehicle 910 approaches the refueling station, the vehicle's navigation subsystem may recognize that the location of vehicle 910 coincides with or is near the location of the refueling station.” ¶ 106. “At block 1402, the current location of the vehicle is determined, for example, by a navigation subsystem of the vehicle. In some embodiments, a merchant at the location of or nearby the vehicle can be identified based on geo-fencing or location of the vehicle.” ¶ 121. “Navigation application 164 may also display nearby places of interests and/or nearby merchants on user interface 154.”)
automatically control a display device to show a welcome interface upon detecting entry into the geo-fenced location, thereby indicating the presence of the vehicle at the point of interest
(See at least Fig. 14 and associated text ¶ 121, “At block 1402, the current location of the vehicle is determined, for example, by a navigation subsystem of the vehicle. In some embodiments, a merchant at the location of or nearby the vehicle can be identified based on geo-fencing or location of the vehicle …At block 1404, merchant information associated with the merchant is retrieved.” “At block 1406, the in-vehicle access application may display the retrieved merchant information (e.g., merchant name, location, point-of-sale terminal information, goods and/or services and associated prices offered by the merchant, etc.) on a user interface of the in-vehicle computing system. For example, the in-vehicle access application may generate a graphical user interface with the merchant information, and display the merchant information on the touchscreen of the in-vehicle computing system to allow a user to choose which goods and/or services to purchase [welcome screen].” “When vehicle 1110 arrives at the parking area, the vehicle's navigation subsystem may recognize that the location of vehicle 1110 coincides with or is nearby the location of the parking area.” ¶ 114. “Based on this information, the in-vehicle access application may generate a parking menu 1126 that can be displayed on the screen of the vehicle infosystem.” ¶ 115. See also ¶¶ 106, 107, 108 (automatic menu generation for a fuel station); ¶ 111 (automatic menu generation for a drive-thru restaurant)).
further detect whether the vehicle has moved to a predetermined specialized region [parking space number] within the geo-fenced location [parking area], and is currently located at the predetermined specialized region, the predetermined specialized region comprising a vehicle parking location of the point of interest [merchant];
(Enriquez discloses parking spaces within a parking area. See at least ¶ 114 “When vehicle 1110 arrives at the parking area, the vehicle's navigation subsystem may recognize that the location of vehicle 1110 coincides with or is nearby the location of the parking area. Using the location of vehicle 1110, the in-vehicle access application may retrieve merchant information about the parking area … The merchant information may include, for example, the number of spaces in the parking area and the monetary amount per time unit to park in the parking area. [0115] Based on this information, the in-vehicle access application may generate a parking menu 1126 that can be displayed on the screen of the vehicle infosystem. For example, parking menu 1126 may allow the user to enter the parking space number and select the amount of time the user intends to park at this location. Once a user has entered the parking space number and the amount of time, the in-vehicle access application may request the user to select a transaction method (e.g., transaction account) to complete the transaction.” See also, ¶¶ 105, 106, 108, Fig. 9 (fuel pumps within gas station); ¶¶ 110, 111, 112, Fig. 10 (drive-thru stations within restaurant).
further automatically control the display device to show information about the vehicle parking location and payment details upon detecting the vehicle at the parking location, based at least on detecting the vehicle is currently located at the vehicle parking location of the point of interest; and
(See at least ¶ 114, “When vehicle 1110 arrives at the parking area, the vehicle's navigation subsystem may recognize that the location of vehicle 1110 coincides with or is nearby the location of the parking area. Using the location of vehicle 1110, the in-vehicle access application may retrieve merchant information about the parking area.” “parking menu 1126 may allow the user to enter the parking space number and select the amount of time the user intends to park at this location. Once a user has entered the parking space number and the amount of time, the in-vehicle access application may request the user to select a transaction method (e.g., transaction account) to complete the transaction. In some embodiments, the in-vehicle access application may require additional verification via a consumer verification method (e.g., pin, password, biometric, etc.) to authenticate the transaction. Transact ion information including account credentials (e.g., PAN or token, transaction cryptogram, etc.) as well as location information can be transmitted to parking meter station 1120 to purchase parking credits for vehicle 1110.” ¶ 115. “The in-vehicle computing system can display the transaction amount and request authentication information (e.g., PIN, passcode, biometric data, etc.) from the user to complete the transaction.”) ¶ 117. “PIN entry menu 1226 may display the transaction amount and a keypad on a touch screen that a user can engage with to enter the user's PIN.” ¶ 118.)
through the screen of the display device of the vehicle, at least partly process the payment details for the use of the vehicle parking location,
(See at least ¶ 115, “Once a user has entered the parking space number and the amount of time, the in-vehicle access application may request the user to select a transaction method (e.g., transaction account) to complete the transaction … Transaction information including account credentials (e.g., PAN or token, transaction cryptogram, etc.) as well as location information can be transmitted to parking meter station 1120 to purchase parking credits for vehicle 1110.” See also, ¶¶ 112, 118, Figs. 11, 12, 13.)
thereby displaying the status of the parking use [PIN entry menu 11226] and, [… Lee, infra].
(Examiner interprets “displaying the status of the parking use” in view of the specification as displaying an “authorization screen”. Spec. ¶ 47.
See at least ¶ 117, “The in-vehicle computing system can display the transaction amount and request authentication information (e.g., PIN, passcode, biometric data, etc.) from the user to complete the transaction. Once the user has provided the authentication information requested by the consumer verification method, the in-vehicle access application can send account credentials to the access device to complete the transaction.” “[T]he in-vehicle access application may display a PIN entry menu 1226 on the user interface (e.g., touchscreen) of the in-vehicle computing system. PIN entry menu 1226 can be displayed after the user has placed an order with a merchant via the in-vehicle access application, or in response to receiving a transaction amount from an access device.” ¶ 118.)
Enriquez discloses displaying the status of the parking use and transaction completion. ¶ 117. Enriquez does not explicitly disclose upon completion of payment, details of the payment. Thus, Enrique does not disclose but Lee discloses:
thereby displaying … upon completion of payment, details of the payment.
(See at least ¶ 74, Interface 503 may display an amount spent, a discount amount, and an amount paid.” “When the received input result for payment indicates an instruction to make an in-vehicle payment, server 200 may perform an automatic payment for the fee to be paid based on automatic payment information registered in advance in relation to the user corresponding to the payment information and the vehicle plate number of the outgoing vehicle. Server 200 may transmit a notification of payment completion to vehicle access control system 140 and/or local server 130 when confirming the completion of automatic payment.” See also, Claim 15.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, to have combined displaying upon completion of payment, details of the payment, as explained in Lee, with the automatic location-based merchant interface display system of Enriquez, in the same field of in-vehicle payment invention, with the motivation to provide a compete in-vehicle payment experience to improve user convenience and encourage adoption of automated payment systems.
Regarding Claim 3, Enriquez and Lee disclose:
The system of claim 1 and memory including instructions that, when executed by the processor, cause the processor to:
Enriquez further discloses
wherein the memory further includes instructions that, when executed by the processor, cause the processor to: use an in-vehicle payment centralized server of the vehicle [in-vehicle computing system 150] to initiate a payment facilitator server [access device/remote server] that electronically collects payment under an authorized payment vendor [“transaction processing network”].
(See at least ¶ 50, “In-vehicle computing system 150 can be mounted in the center console, dashboard, rear console, or other locations in vehicle 100.” “In-vehicle access application 162 enables in-vehicle computing system 150 to interact with an access device. The access device can be nearby or in proximity to vehicle 100 or can be remote at some distance away from vehicle 100 (e.g., a remote server).” ¶ 54. “The in-vehicle access application may request the user to select a transaction method (e.g., transaction account) to complete the transaction. … Once the user has confirmed the transaction, transaction information including account credentials (e.g., PAN or token, transaction cryptogram, etc.) can be transmitted to the access device [remote server] … Upon receiving the transaction information, the access device may verify the user's account credentials and confirm the transaction.” ¶ 112. “A "transaction processing network" may include a network that can process and route transaction request messages. An exemplary transaction processing network may include data processing subsystems, networks, and operations used to support and deliver authorization services, exception file services, transaction scoring services, and clearing and settlement services.” ¶ 40; see also ¶ 55.)
Regarding Claim 6, Enriquez and Lee disclose:
The system of claim 1 and instructions that, when executed by the processor, cause the processor to monitor and update the operating state of the vehicle based on controlling the one or more sensors over time
Enriquez further discloses
wherein the instructions, when executed by the processor, further cause the processor to monitor and update the operating state of the vehicle based on controlling the one or more sensors over time to determine that a gear selector of the vehicle has been placed into park.
(See at least ¶ 59, “in-vehicle computing system 150 can determine that vehicle 100 is in a stopped position when the vehicle status signal indicates that a transmission mode of the vehicle is in park, and that vehicle 100 is moving when the vehicle status signal indicates that a transmission mode of the vehicle is in drive … in-vehicle computing system 150 can determine that vehicle 100 is in a stopped position when the vehicle status signal indicates that vehicle 100 has been motionless (e.g., zero or near-zero speed such as less than 5 mph, etc.) for over a threshold amount of time (e.g., 15 seconds, 30 seconds, 1 minute, etc.).” See also, ¶¶ 66, 116 (parked).)
Regarding Claim 7, Enriquez and Lee disclose:
The system of claim 1 and instructions that, when executed by the processor, cause the processor to monitor and update the operating state of the vehicle based on controlling the one or more sensors over time
Enriquez further discloses
wherein instructions, when executed by the processor, further cause the processor to monitor and update the operating state of the vehicle based on controlling the one or more sensors over time to determine that that the vehicle is stationary.
(See at least ¶¶ 59, in-vehicle computing system 150 can determine that vehicle 100 is in a stopped position when the vehicle status signal indicates that vehicle 100 has been motionless (e.g., zero or near-zero speed such as less than 5 mph, etc.) for over a threshold amount of time (e.g., 15 seconds, 30 seconds, 1 minute, etc.).” See also, ¶¶ 66, 116 (parked).)
Regarding Claim 10, Enriquez discloses
A method for operating a system within a vehicle, the method comprising steps of:
(See at least ¶ 4, Fig. 14 (method).
The remaining limitations of Claim 10 are not substantively different than those presented in Claim 1 and are therefore, rejected, mutatis mutandis, based on Enriquez and Lee for the same rationale presented in Claim 1 supra.
The resolution of the remaining Graham factual inquiries to support a conclusion of obviousness that a particular known technique was recognized as part of the ordinary skill in the pertinent art is substantively the same as that presented in Claim 1 supra, and is incorporated in its entirety herein, mutatis mutandis, to support the rejection of Claim 10.
Regarding Claim 12, Enriquez and Lee disclose:
The method of claim 10
Enrique further discloses
further comprising initiating a call using an in-vehicle payment centralized server of the vehicle [“in-vehicle computing system 150”] to a backend service to authorize a transaction that sends an authorized payment token from the vehicle to a payment facilitator server that electronically collects payment under an authorized payment vendor.
(See at least ¶ 50, “In-vehicle computing system 150 can be mounted in the center console, dashboard, rear console, or other locations in vehicle 100.” “In-vehicle access application 162 enables in-vehicle computing system 150 to interact with an access device. The access device can be nearby or in proximity to vehicle 100 or can be remote at some distance away from vehicle 100 (e.g., a remote server).” ¶ 54. “The in-vehicle access application may request the user to select a transaction method (e.g., transaction account) to complete the transaction. … Once the user has confirmed the transaction, transaction information including account credentials (e.g., PAN or token, transaction cryptogram, etc.) can be transmitted to the access device [remote server] … Upon receiving the transaction information, the access device may verify the user's account credentials and confirm the transaction.” ¶ 112. “A "transaction processing network" may include a network that can process and route transaction request messages. An exemplary transaction processing network may include data processing subsystems, networks, and operations used to support and deliver authorization services, exception file services, transaction scoring services, and clearing and settlement services.” ¶ 40. “The account credentials may include account parameters such as an account identifier or a token associated with an account that can be used as a substitute for the account identifier.” ¶ 55; see also ¶¶ 31, 55.)
Regarding Claims 15 and 16, Enriquez and Lee disclose:
The method of claim 10.
The remaining limitations of Claims 15 and 16 are not substantively different than those presented in Claims 6 and 7, respectively, and are therefore, rejected, mutatis mutandis, based on Enriquez and Lee for the same rationale presented in Claims 6 and 7, respectively, supra.
Regarding Claim 19, Enriquez discloses
A non-transitory computer-readable medium including instructions that, when executed by a processor of a vehicle system, cause the processor to
(See at least ¶ 125)
The remaining limitations of Claim 19 are not substantively different than those presented in Claim 1 and are therefore, rejected, mutatis mutandis, based on Enriquez and Lee for the same rationale presented in Claim 1 supra.
The resolution of the remaining Graham factual inquiries to support a conclusion of obviousness that a particular known technique was recognized as part of the ordinary skill in the pertinent art is substantively the same as that presented in Claim 1 supra, and is incorporated in its entirety herein, mutatis mutandis, to support the rejection of Claim 19.
Regarding Claim 20, Enriquez and Lee disclose:
The non-transitory computer-readable medium of claim 19
The remaining limitations of Claim 20 is not substantively different than those presented in Claim 12 and is therefore, rejected, mutatis mutandis, based on Enriquez and Lee for the same rationale presented in Claim 12, supra.
Regarding Claim 21, Enriquez and Lee disclose:
The system of claim 1 and instructions, when executed by the processor, further cause the processor to
Enriquez further discloses
wherein the instructions, when executed by the processor, further cause the processor to
detect, based at least on any of monitoring and updating the location, the entry of the vehicle into the predetermined geo-fenced location
(See at least ¶ 78, “When vehicle 410 establishes network connectivity, the in-vehicle access application of vehicle 410 may send the vehicle's location 472 to remote tolling server 450. Upon receiving location 472, remote tolling server 450 may use location information 474 of vehicle 410 to query a toll authority database 455 to obtain toll road information about toll roads within a geographic area of vehicle 410 (e.g., within a 5 mile radius, 10 mile radius, 20 mile radius, 50 mile radius, 100 mile radius, etc.).” See also, ¶¶ 46, 77, 106.
detect … by controlling transmission, from the vehicle, to an external server and
(See at least ¶ 49, “Vehicle 100 may also include a wireless communication subsystem 190 to enable network connectivity for vehicle 100. Wireless communication subsystem 190 may include one or more wireless transceivers that use WiFi, WiMax, or other types of wireless network communication protocols to connect vehicle 100 to an external network (e.g., the Internet) such that vehicle 100 can communicate with remote servers.” “When vehicle 410 establishes network connectivity, the in-vehicle access application of vehicle 410 may send the vehicle's location 472 to remote tolling server 450.” ¶ 78.)
to receive, from the external server, an indication whether the vehicle has entered into the predetermined geo-fenced location,
(See at least ¶ 82, “Upon determining that the registered transaction method of the user has sufficient funds to cover the toll amounts, remote tolling server 450 may then send the communication protocol information 484 to vehicle 410 to enable the in-vehicle access application of vehicle 410 to configure the vehicle's tunable transponder for the appropriate toll roads.” “Upon authorization, remote tolling server 450 may send a verification code to the in-vehicle access application of vehicle 410” ¶ 84. “Upon receiving location 472, remote tolling server 450 may use location information 474 of vehicle 410 to query a toll authority database 455 to obtain toll road information about toll roads within a geographic area of vehicle 410 (e.g., within a 5 mile radius, 10 mile radius, 20 mile radius, 50 mile radius, 100 mile radius, etc.).” ¶ 78; see also, Fig. 8.
the external server is external to the vehicle.
(See at least ¶ 78, “When vehicle 410 establishes network connectivity, the in-vehicle access application of vehicle 410 may send the vehicle's location 472 to remote tolling server 450.”)
Regarding Claim 23, Enriquez and Lee disclose:
The system of claim 1 and he point of interest and the vehicle parking location
Enriquez further discloses
wherein the point of interest is at a gas station and the vehicle parking location is at a fuel pump.
(See at least Fig. 9, ¶¶ 105, 106, 107, 108.)
Claim 22 is rejected under 35 U.S.C. 103 as being unpatentable over Enriquez and Lee and further in view of Macfarlane et al. (U.S. Pat. Pub. No. 2011/0072368) [“Macfarlane”].
Regarding Claim 22, Enriquez and Lee disclose:
The system of claim 1
Enriquez discloses automatically controlling, based on detecting entry of the vehicle into the predetermined geo-fenced location, the display device of the vehicle to show the welcome interface … by the display device. Enriquez does not disclose “show the welcome interface overlapped over a display of a map.” Thus, Enriquez does not disclose but Macfarlane discloses:
the display device … to show [markup language content] overlapped over a display of a map by the display device
(See at least Abstract, “overlaying the markup language content received by the markup language renderer on the map data output by the map display program”. See also, Claims 1, 5.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, to have combined to showing markup language content (welcome screen) overlapped over a display of a map by the display device, as explained in Macfarlane, with the known in-vehicle payment and merchant interface system of Enriquez, in the same field of in-vehicle payment invention, with the motivation to provide a unified infotainment interface to improve user experience and convenience by reducing interface switching and enhance map data in a personal navigation device. Macfarlane, ¶¶ 2, 3.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JAMES H MILLER whose telephone number is (469)295-9082. The examiner can normally be reached M-F: 10- 4 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, Bennett M Sigmond can be reached at (303) 297-4411. 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.
/JAMES H MILLER/Examiner, Art Unit 3694