DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
This action is in response to the Preliminary Amendment filed on February 05, 2025. Claim 16 is amended. Claims 1-20 are pending.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on January 12, 2025, May 26,
2025, and August 27, 2025 have been considered by the examiner.
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 17-20 are rejected under 35 U.S.C. § 101 because the claimed invention is
directed to non-statutory subject matter.
The claim(s) does/do not fall within at least one of the four categories of patent eligible subject matter because claim 17 recites “a computer-readable storage medium comprising instructions stored thereon ...” However, the claim does not expressly recite that the computer-readable storage medium is non-transitory. Further, while the specification describes computer-readable media and storage media at paragraphs [0131], [0132], [0139], [0144], and [0145], these paragraphs do not explicitly limit the recited computer-readable storage medium to a non-transitory medium or expressly exclude transitory propagating signals.
For example, paragraph [0131] states that a computer program may be embodied on a computer-readable medium, such as a storage medium, and provides examples including RAM, ROM, EPROM, EEPROM, registers, hard disk, removable disk, CD-ROM, DVD-ROM, or other storage medium. Paragraph [0132] describes a storage medium coupled to or integral with a processor. Paragraph [0139] states that aspects may be embodied as a computer program product in one or more computer-readable media having computer-readable program code. Paragraphs [0144] and [0145] further describe modules, executable code, and computer-readable media. However, none of these paragraphs expressly state that the computer-readable medium is limited to non-transitory embodiments.
Accordingly, under the broadest reasonable interpretation, the claimed computer-readable storage medium encompasses transitory forms of signal transmission, such as propagating electrical or electromagnetic signals.
Therefore since transitory signals are not statutory subject matter under 35 U.S.C. § 101, claims 17-20 are rejected.
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 forms 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 filling date of the claimed invention.
Claims 1, 4, 9, 12, 17, and 20 are rejected under 35 U.S.C. § 102 as being anticipated by Gaudin
et al. (US 11,948,138 B2, hereinafter “Gaudin”).
Regarding Claim 1, Gaudin teaches, An apparatus comprising: “the vehicle head unit 14 may include one or more processor(s) such as a microprocessor coupled to a memory” [Col. 7, lines 42-44]
a communication interface, “the vehicle head unit 14 may communicate with a portable device 10 within the vehicle via a communication link, which may be wired (e.g., wired Universal Serial Bus (USB)) or wireless (e.g., Bluetooth, Wi-Fi Direct, wireless USB).” [Col. 7, lines 27-31]
a memory; and, “the vehicle head unit 14 may include one or more processor(s) such as a microprocessor coupled to a memory” [Col. 7, lines 42-44]
a processor coupled to the communication interface and the memory, “the vehicle head unit 14 may include one or more processor(s).” [Col. 7, lines 42].
the processor configured to:
establish a link between a mobile device and a head unit within a vehicle, “the vehicle head unit 14 may communicate with a portable device 10 within the vehicle via a communication link, which may be wired (e.g., wired Universal Serial Bus (USB)) or wireless (e.g., Bluetooth, Wi-Fi Direct, 30 wireless USB).” [Col. 7, lines 27-31]
retrieve, by the head unit, one or more data routing tokens from a secure element stored on the mobile device via the link, “the vehicle head unit 14 may communicate with a portable device 10 within the vehicle via a communication link, which may be wired (e.g., wired Universal Serial Bus (USB)) or wireless (e.g., Bluetooth, Wi-Fi Direct, wireless USB).” [Col. 7, lines 27-31], and “the portable device 10 may store indications of financial cards, tokens, and/or financial data which may be transmitted to the vehicle head unit 14 when a user adds a new financial card to the vehicle payment application” [Col. 7, lines 31-35], and “The portable device 10 may be a tablet computer, a cell phone, a personal digital assistant (PDA), a smart-phone, a laptop computer, a portable media player (not shown), a pager, a wearable computing device, smart glasses, smart watches or bracelets, phablets, other smart devices, devices configured for wired or wireless RF (Radio Frequency) communication, etc.” [Col. 7, lines 35-41].
(The claimed “secure element” is inherently disclosed because Gaudin teaches storage and transmission of sensitive payment tokens and financial data on the portable/mobile device for secure payment processing through the communication link).
display identifiers of the one or more data routing tokens on a user interface of the head unit in association with a data exchange, “The vehicle payment application may present indications of each of the stored financial cards on the display 18 of the vehicle head unit 14 and one or more user controls for allowing the user to select one of the financial cards.” [Col. 7, lines 59-63]
receive an input from the user interface of the head unit which selects a target data routing token from among the one or more data routing tokens, (“When the user is authenticated, the vehicle payment application 266 may receive a selection of a financial card (block 410), for example via a financial card selection screen” [Col. 25, lines 30-33], and “The financial card selection screen may include indications of one or several financial cards stored at the vehicle payment application 266, and the user may select one of the financial cards displayed on the financial card selection screen.” [Col. 25, lines 33-37]).
and, transmit a request for the data exchange that includes the target data routing token and the data exchange, (“Upon receiving a selection of one of the financial cards and a request to make payment, the vehicle payment application may transmit the token representing financial data for the selected financial data via a short-range communication link 120 (or radio frequency link) to the POS terminal 20” [Col. 7-8, lines 63-67]).
Regarding Claim 4, Gaudin discloses the limitations of claim 4 as recited above in the rejection of claim 1. In addition, Gaudin further teaches, wherein the processor is configured to pair the mobile device with the head unit through wireless communication, (“For example, the vehicle head unit and the electronic circuitry may be paired together via a Bluetooth pairing” [Col. 5, lines 56-57], and “the electronic circuitry 50 may be paired with the vehicle head unit 14 via a Bluetooth connection.” [Col. 8, lines 27-28], and “the vehicle head unit 14 and the electronic circuitry 50 may be paired using Bluetooth, and the data may be transmitted over the Bluetooth communication protocol.” [Col. 25, lines 44-47]).
Regarding Claim 9, Gaudin teaches, a method comprising:
establishing a link between a mobile device and a head unit within a vehicle, “(the vehicle head unit 14 may communicate with a portable device 10 within the vehicle via a communication link, which may be wired (e.g., wired Universal Serial Bus (USB)) or wireless (e.g., Bluetooth, Wi-Fi Direct, wireless USB).” [Col. 7, lines 27-31].
retrieving, by the head unit, one or more data routing tokens from a secure element stored on the mobile device via the link, “the vehicle head unit 14 may communicate with a portable device 10 within the vehicle via a communication link, which may be wired (e.g., wired Universal Serial Bus (USB)) or wireless (e.g., Bluetooth, Wi-Fi Direct, wireless USB).” [Col. 7, lines 27-31], and “the portable device 10 may store indications of financial cards, tokens, and/or financial data which may be transmitted to the vehicle head unit 14 when a user adds a new financial card to the vehicle payment application” [Col. 7, lines 31-35], and “The portable device 10 may be a tablet computer, a cell phone, a personal digital assistant (PDA), a smart-phone, a laptop computer, a portable media player (not shown), a pager, a wearable computing device, smart glasses, smart watches or bracelets, phablets, other smart devices, devices configured for wired or wireless RF (Radio Frequency) communication, etc.” [Col. 7, lines 35-41];
(The claimed “secure element” is inherently disclosed because Gaudin teaches storage and transmission of sensitive payment tokens and financial data on the portable/mobile device for secure payment processing through the communication link).
displaying identifiers of the one or more data routing tokens on a user interface of the head unit in association with a data exchange, “The vehicle payment application may present indications of each of the stored financial cards on the display 18 of the vehicle head unit 14 and one or more user controls for allowing the user to select one of the financial cards.” [Col. 7, lines 59-63],
receiving an input from the user interface of the head unit which selects a target data routing token from among the one or more data routing tokens, “When the user is authenticated, the vehicle payment application 266 may receive a selection of a financial card (block 410), for example via a financial card selection screen” [Col. 25, lines 30-33], and “The financial card selection screen may include indications of one or several financial cards stored at the vehicle payment application 266, and the user may select one of the financial cards displayed on the financial card selection screen.” [Col. 25, lines 33-37].
and transmitting a request for the data exchange that includes the target data routing token and the data exchange, “Upon receiving a selection of one of the financial cards and a request to make payment, the vehicle payment application may transmit the token representing financial data for the selected financial data via a short-range communication link 120 (or radio frequency link) to the POS terminal 20” [Col. 7-8, lines 63-67].
Regarding Claim 12, Gaudin discloses the limitation of claim 12 as recited above in the rejection of claim 9. In addition, Gaudin further teaches, wherein the establishing the link comprises pairing the mobile device with the head unit through wireless communication, “For example, the vehicle head unit and the electronic circuitry may be paired together via a Bluetooth pairing” [Col. 5, lines 56-57], and “the electronic circuitry 50 may be paired with the vehicle head unit 14 via a Bluetooth connection.” [Col. 8, lines 27-28], and “the vehicle head unit 14 and the electronic circuitry 50 may be paired using Bluetooth, and the data may be transmitted over the Bluetooth communication protocol.” [Col. 25, lines 44-47].
Regarding Claim 17, Gaudin teaches, a computer-readable storage medium comprising
instructions stored therein which when executed by a processor cause the processor to perform:
establishing a link between a mobile device and a head unit within a vehicle, “the vehicle head unit 14 may communicate with a portable device 10 within the vehicle via a communication link, which may be wired (e.g., wired Universal Serial Bus (USB)) or wireless (e.g., Bluetooth, Wi-Fi Direct, wireless USB).” [Col. 7, lines 27-31].
retrieving, by the head unit, one or more data routing tokens from a secure element stored on the mobile device via the link, “the vehicle head unit 14 may communicate with a portable device 10 within the vehicle via a communication link, which may be wired (e.g., wired Universal Serial Bus (USB)) or wireless (e.g., Bluetooth, Wi-Fi Direct, wireless USB).” [Col. 7, lines 27-31], and “the portable device 10 may store indications of financial cards, tokens, and/or financial data which may be transmitted to the vehicle head unit 14 when a user adds a new financial card to the vehicle payment application” [Col. 7, lines 31-35], and “The portable device 10 may be a tablet computer, a cell phone, a personal digital assistant (PDA), a smart-phone, a laptop computer, a portable media player (not shown), a pager, a wearable computing device, smart glasses, smart watches or bracelets, phablets, other smart devices, devices configured for wired or wireless RF (Radio Frequency) communication, etc.” [Col. 7, lines 35-41].
(The claimed “secure element” is inherently disclosed because Gaudin teaches storage and transmission of sensitive payment tokens and financial data on the portable/mobile device for secure payment processing through the communication link.)
displaying identifiers of the one or more data routing tokens on a user interface of the head unit in association with a data exchange, “The vehicle payment application may present indications of each of the stored financial cards on the display 18 of the vehicle head unit 14 and one or more user controls for allowing the user to select one of the financial cards.” [Col. 7, lines 59-63].
receiving an input from the user interface of the head unit which selects a data routing token from among the one or more data routing tokens, “When the user is authenticated, the vehicle payment application 266 may receive a selection of a financial card (block 410), for example via a financial card selection screen” [Col. 25, lines 30-33], and “The financial card selection screen may include indications of one or several financial cards stored at the vehicle payment application 266, and the user may select one of the financial cards displayed on the financial card selection screen.” [Col. 25, lines 33-37].
and transmitting a request for the data exchange that includes the target data routing token and the data exchange, “Upon receiving a selection of one of the financial cards and a request to make payment, the vehicle payment application may transmit the token representing financial data for the selected financial data via a short-range communication link 120 (or radio frequency link) to the POS terminal 20” [Col. 7-8, lines 63-67].
Regarding Claim 20, Gaudin discloses the limitations of claim 20 as recited above in the rejection of claim 17. In addition, Gaudin further teaches, wherein the establishing the link comprises pairing the mobile device with the head unit through wireless communication, “For example, the vehicle head unit and the electronic circuitry may be paired together via a Bluetooth pairing” [Col. 5, lines 56-57], and “the electronic circuitry 50 may be paired with the vehicle head unit 14 via a Bluetooth connection.” [Col. 8, lines 27-28], and “the vehicle head unit 14 and the electronic circuitry 50 may be paired using Bluetooth, and the data may be transmitted over the Bluetooth communication protocol.” [Col. 25, lines 44-47].
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 2, 3, 8, 10, 11 and 18 are rejected under 35 U.S.C. § 103 as being unpatentable over
Gaudin et al. (US 11,948,138 B2, hereinafter “Gaudin”), in view of Ortiz et al. (US 20200034830 A1, hereinafter “Ortiz”).
Regarding Claim 2, Gaudin discloses the limitations of claim 2 as recited above in the rejection of claim 1. In addition, Gaudin further teaches, wherein the processor is configured to
execute a disbursement process for the data exchange with the data routing tokens via the head unit, “Upon receiving a selection of one of the financial cards and a request to make payment, the vehicle payment application may transmit the token representing financial data for the selected financial data via a short-range communication link 120 (or radio frequency link) to the POS terminal 20” [Col. 7-8, lines 63-67], and “the token may be transmitted from the vehicle head unit to the electronic circuitry once, when a new financial card or financial account is added. Subsequently, when the user authorizes payment for a selected financial card or financial account, an indication of the financial card or financial account may be transmitted to the electronic circuitry, which may in tum retrieve and/or transmit the token to the POS terminal.” [Col. 6, lines 13-20].
However, Gaudin does not teach, receive authorization from an issuing system via a computer network.
Ortiz teaches, receive authorization from an issuing system via a computer network, “(110) represents an authentication or adjudication server configured to authenticate the user 10, PDA “Device” 102, and application or other information such as an account number, and thereby authorize or otherwise enable secure access by the Device 102 to FI services hosted by 110 over the web or other network 250” [0093], and “transaction data may also be transmitted via one of potentially many different payment networks for processing, authorization, and settlement with a bank or financial institution” [0009]
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to incorporate the authorization processing and network communication of Ortiz into the vehicle payment system of Gaudin in order to authorize token-based vehicle transactions through a computer network.
Regarding Claim 3, Gaudin and Ortiz disclose the limitations of claim 3 as recited above in the rejection of claim 2. In addition Gaudin further teaches, wherein the processor is further configured to pre-authorize the disbursement process in response to receiving the input from the user interface of the head unit, “Upon receiving a selection of one of the financial cards and a request to make payment, the vehicle payment application may transmit the token representing financial data for the selected financial data via a short-range communication link 120 (or radio frequency link) to the POS terminal 20” [Col. 7-8, lines 63-67], and “when the user authorizes payment for a selected financial card or financial account, an indication of the financial card or financial account may be transmitted to the electronic circuitry, which may in turn retrieve and/or transmit the token to the POS terminal” [Col. 6, lines 16-20], and “When the user is authenticated, the vehicle payment application 266 may receive a selection of a financial card (block 410), for example via a financial card selection screen.” [Col. 25, lines 30-33], and “The financial card selection screen may include indications of one or several financial cards stored at the vehicle payment application 266, and the user may select one of the financial cards displayed on the financial card selection screen” [Col. 25, lines 33-37].
Regarding Claim 8, Gaudin discloses the limitations of claim 8 as recited in the rejection above of claim 1. In addition, Gaudin further teaches, wherein the processor is configured to transmit a disbursement request authorization message from the head unit of the vehicle to an issuing system with the request to authorize the data exchange, “Upon receiving a selection of one of the financial cards and a request to make payment, the vehicle payment application may transmit the token representing financial data for the selected financial data via a short-range communication link 120 (or radio frequency link) to the POS terminal 20” [Col. 7-8, lines 63-67], and “ the vehicle payment application 266 may authenticate the user to ensure she is authorized to use stored financial cards to make payments (block 408).” [Col. 25, lines 11-13].
However, Gaudin does not expressly teach, wherein the processor is configured to transmit a disbursement request authorization message with a card present indicator from the head unit of the vehicle to an issuing system with the request to authorize the data exchange.
Ortiz teaches, wherein the processor is configured to transmit a disbursement request authorization message with a card present indicator from the head unit of the vehicle to an issuing system with the request to authorize the data exchange, “In alternative embodiments, as explained more fully below, “card present” and other transactions can be conducted, or otherwise implemented, using SEs provided in the form of encrypted and/or otherwise secure, pre-authorized payment tokens stored on mobile devices such as smart phones, tablet computers, and other PDAs.” [0080].
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to implement the card-present token authorization techniques of Ortiz within the vehicle payment environment of Gaudin in order to support secure authorization processing for vehicle-based payment transactions.
Regarding Claim 10, Gaudin discloses the limitation of claim 10 as recited in the rejection above of claim 9. In addition, Gaudin teaches, wherein the method further comprises
executing a disbursement process for the data exchange with the data routing token via the head unit, “Upon receiving a selection of one of the financial cards and a request to make payment, the vehicle payment application may transmit the token representing financial data for the selected financial data via a short-range communication link 120 (or radio frequency link) to the POS terminal 20” [Col. 7-8, lines 63-67], and “the token may be transmitted from the vehicle head unit to the electronic circuitry once, when a new financial card or financial account is added. Subsequently, when the user authorizes payment for a selected financial card or financial account, an indication of the financial card or financial account may be transmitted to the electronic circuitry, which may in tum retrieve and/or transmit the token to the POS terminal.” [Col. 6, lines 13-20].
However, Gaudin does not teach, receiving authorization from an issuing system via a computer network.
Ortiz teaches, receiving authorization from an issuing system via a computer network, “(110) represents an authentication or adjudication server configured to authenticate the user 10, PDA “Device” 102, and application or other information such as an account number, and thereby authorize or otherwise enable secure access by the Device 102 to FI services hosted by 110 over the web or other network 250” [0093], and “transaction data may also be transmitted via one of potentially many different payment networks for processing, authorization, and settlement with a bank or financial institution” [0009]
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to incorporate the authorization processing and network communication of Ortiz into the vehicle payment system of Gaudin in order to authorize token-based vehicle transactions through a computer network.
Regarding Claim 11, Gaudin and Ortiz disclose all the limitations of claim 11 as recited above in the rejection of claim 10. In addition, Gaudin further teaches, wherein the method further comprises pre-authorizing the disbursement process in response to receiving the input from the user interface of the head unit, “Upon receiving a selection of one of the financial cards and a request to make payment, the vehicle payment application may transmit the token representing financial data for the selected financial data via a short-range communication link 120 (or radio frequency link) to the POS terminal 20” [Col. 7-8, lines 63-67], and “when the user authorizes payment for a selected financial card or financial account, an indication of the financial card or financial account may be transmitted to the electronic circuitry, which may in turn retrieve and/or transmit the token to the POS terminal” [Col. 6, lines 16-20], and “When the user is authenticated, the vehicle payment application 266 may receive a selection of a financial card (block 410), for example via a financial card selection screen.” [Col. 25, lines 30-33], and “The financial card selection screen may include indications of one or several financial cards stored at the vehicle payment application 266, and the user may select one of the financial cards displayed on the financial card selection screen” [Col. 25, lines 33-37].
Regarding Claim 18, Gaudin discloses the limitations of claim 18 as recited above in the rejection of claim 17. In addition, Gaudin further teaches, wherein the processor is further configured to perform
executing a disbursement process for the data exchange with the data routing tokens via the head unit, “Upon receiving a selection of one of the financial cards and a request to make payment, the vehicle payment application may transmit the token representing financial data for the selected financial data via a short-range communication link 120 (or radio frequency link) to the POS terminal 20” [Col. 7-8, lines 63-67], and “the token may be transmitted from the vehicle head unit to the electronic circuitry once, when a new financial card or financial account is added. Subsequently, when the user authorizes payment for a selected financial card or financial account, an indication of the financial card or financial account may be transmitted to the electronic circuitry, which may in tum retrieve and/or transmit the token to the POS terminal.” [Col. 6, lines 13-20].
However, Gaudin does not teach, receiving authorization from an issuing system via a computer network.
Ortiz teaches, receiving authorization from an issuing system via a computer network, “(110) represents an authentication or adjudication server configured to authenticate the user 10, PDA “Device” 102, and application or other information such as an account number, and thereby authorize or otherwise enable secure access by the Device 102 to FI services hosted by 110 over the web or other network 250” [0093], and “transaction data may also be transmitted via one of potentially many different payment networks for processing, authorization, and settlement with a bank or financial institution” [0009]
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to incorporate the authorization processing and network communication of Ortiz into the vehicle payment system of Gaudin in order to authorize token-based vehicle transactions through a computer network.
Claims 5, 6, 13, 14, and 19 are rejected under 35 U.S.C. § 103 as being unpatentable over
Gaudin et al. (US 11,948,138 B2, hereinafter “Gaudin”), in view of Singh et al. (US 20230196374 A1, hereinafter “Singh”)
Regarding Claim 5, Gaudin discloses the limitations of claim 5 as recited above in the rejection of claim 1. However, Gaudin does not teach, wherein the processor is further configured to display a multi-factor authentication request (MFA) window on the mobile device with a request to authorize the data routing tokens, receive validation data from the MFA window on the mobile device, and transmit the authorization request from the head unit to an issuing system in response to receiving the validation data from the MFA window on the mobile device.
In the same field of endeavor, Singh teaches, display a multi-factor authentication request (MFA) window on the mobile device with a request to authorize the data routing tokens, “ the server system 108 is configured to provide a user interface (UI) to the cardholder 102 to register the user device 104 a for device behavioral analyzer service to facilitate more secure payment transactions in MFA methods.” [0061], and “The ACS 120 generates an OTP message that is enabled with a read-receipt request flag and sends the OTP message to the associated email account of cardholder 102 and/or text message on the registered mobile phone number of the cardholder 102.” [0094], and “The term “multi-factor authentication (MFA)”, used throughout the description, herein refers to an authentication process in which a cardholder needs to provide at least two or more pieces of evidence or authentication factors to authenticate a payment transaction.” [0027].
receive validation data from the MFA window on the mobile device, “To perform the MFA, the cardholder 102 enters the OTP and then, the cardholder 102 submits the payment transaction to the merchant 106” [0095], and “The payment server 118 sends the payment transaction details to the ACS 120 associated with the issuer server 114 to perform the MFA for the payment transaction” [0095].
and transmit the authorization request from the head unit to an issuing system in response to receiving the validation data from the MFA window on the mobile device, “The payment server 118 sends the payment transaction details to the ACS 120 associated with the issuer server 114 to perform the MFA for the payment transaction” [0094], and “In one embodiment, the server system is configured to receive an authentication request including the MFA token from an issuer server for validating the MFA token for the payment transaction.” [0042]
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to incorporate the MFA authentication techniques of Singh into the vehicle payment system of Gaudin in order to improve authentication security and authorization validation for vehicle-based payment transactions.
Regarding Claim 6, Gaudin and Singh disclose the limitations of claim 6 as recited above in the rejection of claim 5. However, Gaudin does not expressly teach, wherein the processor is configured to receive a biometric input from a user via the MFA window on the mobile device, and determine the data routing token is authorized based on the biometric input.
Singh further teaches, receive a biometric input from a user via the MFA window on the mobile device, “The user can prove he is who he claims to be by providing information only he knows, like a password or answers to challenge questions (e.g., a single-factor authentication), by entering a One-Time Password (OTP) (e.g., a two-factor authentication), and by providing a characteristic unique to who he is, such as a fingerprint, a retina scan, or a voice recognition (e.g., a three-factor authentication)” [0027], and “the server system 108 is configured to provide a user interface (UI) to the cardholder 102 to register the user device 104 a for device behavioral analyzer service to facilitate more secure payment transactions in MFA methods” [0061].
determine the data routing token is authorized based on the biometric input, “Upon successful verification of the OTP entered by the cardholder 102, the ACS 120 sends an authentication flag indicating the successful verification of the OTP entered by the cardholder 102 for the MFA of the payment transaction” [0095], and “the server system is configured to transmit the MFA token to the payment server” [0042].
However, the combination of Gaudin and Singh does not expressly teach, compare the biometric input to a previously stored reference biometric input.
Further, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention that biometric authentication system inherently compare received biometric information with previously stored reference biometric information in order to authenticate a user prior to authorizing access or a transaction.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to incorporate the biometric MFA authentication techniques of Singh into the vehicle payment system of Gaudin in order to improve authentication security and authorization validation for vehicle-based payment transactions.
Regarding Claim 13, Gaudin discloses the limitations of the method claim 13 as recited above in the rejection of the method of claim 9. However, Gaudin does not teach, wherein the method further comprises displaying a multi-factor authentication request (MFA) window on the mobile device with a request to authorize the data routing token, receiving validation data from the MFA window on the mobile device, and transmitting an authorization request from the head unit to an issuing system in response to receiving the validation data from the MFA window on the mobile device.
In the same field of endeavor, Singh teaches, displaying a multi-factor authentication request (MFA) window on the mobile device with a request to authorize the data routing token, “ the server system 108 is configured to provide a user interface (UI) to the cardholder 102 to register the user device 104 a for device behavioral analyzer service to facilitate more secure payment transactions in MFA methods.” [0061], and “The ACS 120 generates an OTP message that is enabled with a read-receipt request flag and sends the OTP message to the associated email account of cardholder 102 and/or text message on the registered mobile phone number of the cardholder 102.” [0094], and “The term “multi-factor authentication (MFA)”, used throughout the description, herein refers to an authentication process in which a cardholder needs to provide at least two or more pieces of evidence or authentication factors to authenticate a payment transaction.” [0027].
receiving validation data from the MFA window on the mobile device, “To perform the MFA, the cardholder 102 enters the OTP and then, the cardholder 102 submits the payment transaction to the merchant 106” [0095], and “The payment server 118 sends the payment transaction details to the ACS 120 associated with the issuer server 114 to perform the MFA for the payment transaction” [0095].
and transmitting an authorization request from the head unit to an issuing system in response to receiving the validation data from the MFA window on the mobile device, “The payment server 118 sends the payment transaction details to the ACS 120 associated with the issuer server 114 to perform the MFA for the payment transaction” [0094], and “In one embodiment, the server system is configured to receive an authentication request including the MFA token from an issuer server for validating the MFA token for the payment transaction.” [0042]
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to incorporate the MFA authentication techniques of Singh into the vehicle payment system of Gaudin in order to improve authentication security and authorization validation for vehicle-based payment transactions.
Regarding Claim 14, Gaudin and Singh disclose the limitations of claim 14 as recited above in the rejection of claim 13. However, Gaudin does not expressly teach, wherein the receiving the validation data comprises receiving a biometric input from a user via the MFA window on the mobile device, comparing the biometric input to a previously stored reference biometric input, and determining the data routing token is authorized based on the biometric input.
Singh further teaches, receiving a biometric input from a user via the MFA window on the mobile device, “The user can prove he is who he claims to be by providing information only he knows, like a password or answers to challenge questions (e.g., a single-factor authentication), by entering a One-Time Password (OTP) (e.g., a two-factor authentication), and by providing a characteristic unique to who he is, such as a fingerprint, a retina scan, or a voice recognition (e.g., a three-factor authentication)” [0027], and “the server system 108 is configured to provide a user interface (UI) to the cardholder 102 to register the user device 104 a for device behavioral analyzer service to facilitate more secure payment transactions in MFA methods” [0061].
and determining the data routing token is authorized based on the biometric input, “Upon successful verification of the OTP entered by the cardholder 102, the ACS 120 sends an authentication flag indicating the successful verification of the OTP entered by the cardholder 102 for the MFA of the payment transaction” [0095], and “the server system is configured to transmit the MFA token to the payment server” [0042].
However, the combination of Gaudin and Singh does not expressly teach, comparing the biometric input to a previously stored reference biometric input.
Further, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention that biometric authentication system inherently compare received biometric information with previously stored reference biometric information in order to authenticate a user prior to authorizing access or a transaction.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to incorporate the biometric MFA authentication techniques of Singh into the vehicle payment system of Gaudin in order to improve authentication security and authorization validation for vehicle-based payment transactions.
Regarding Claim 19, Gaudin and Ortiz disclose the limitations of claim 19 as recited above in the rejection of claim 18. However, Gaudin does not teach, wherein the processor is further configured to perform displaying a multi-factor authentication request (MFA) window on the mobile device with a request to authorize the data routing token, receiving validation data from the MFA window on the mobile device, and transmitting the authorization request from the head unit to the issuing system in response to receiving the validation data from the MFA window on the mobile device.
In the same field of endeavor, Singh teaches, displaying a multi-factor authentication request (MFA) window on the mobile device with a request to authorize the data routing token, “ the server system 108 is configured to provide a user interface (UI) to the cardholder 102 to register the user device 104 a for device behavioral analyzer service to facilitate more secure payment transactions in MFA methods.” [0061], and “The ACS 120 generates an OTP message that is enabled with a read-receipt request flag and sends the OTP message to the associated email account of cardholder 102 and/or text message on the registered mobile phone number of the cardholder 102.” [0094], and “The term “multi-factor authentication (MFA)”, used throughout the description, herein refers to an authentication process in which a cardholder needs to provide at least two or more pieces of evidence or authentication factors to authenticate a payment transaction.” [0027].
receiving validation data from the MFA window on the mobile device, “To perform the MFA, the cardholder 102 enters the OTP and then, the cardholder 102 submits the payment transaction to the merchant 106” [0095], and “The payment server 118 sends the payment transaction details to the ACS 120 associated with the issuer server 114 to perform the MFA for the payment transaction” [0095].
and transmitting the authorization request from the head unit to the issuing system in response to receiving the validation data from the MFA window on the mobile device, “The payment server 118 sends the payment transaction details to the ACS 120 associated with the issuer server 114 to perform the MFA for the payment transaction” [0094], and “In one embodiment, the server system is configured to receive an authentication request including the MFA token from an issuer server for validating the MFA token for the payment transaction.” [0042]
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to incorporate the MFA authentication techniques of Singh into the vehicle payment system of Gaudin in order to improve authentication security and authorization validation for vehicle-based payment transactions.
Claims 7 and 15 are rejected under 35 U.S.C. § 103 as being unpatentable over Gaudin et al.
(US 11,948,138 B2, hereinafter “Gaudin”), in view of Ikavalko et al. (US 20160069689 A1, hereinafter “Ikavalko”)
Regarding Claim 7, Gaudin discloses the limitations of claim 7 as recited above in the rejection of claim 1. However, Gaudin does not teach, wherein the processor is further configured to identify a destination of the vehicle as the vehicle is travelling along a route, identify an item of interest based on the destination, and display an identifier of the item with the identifiers of the one or more data routing tokens on the user interface.
In the same field of endeavor, Ikavalko teaches, identify a destination of the vehicle as the vehicle is travelling along a route, “The system may then estimate the additional travel time needed to get through the traffic congestion and arrive at the desired destination” [0010], and “The system may also access the user's calendar to determine when the user may need to be at a certain location or destination” [0012].
identify an item of interest based on the destination, “the system may analyze the user's purchase history, to-do-list, search history, watch list, wish list, calendar, or the like to determine items or services the user may desire to purchase. The system may find merchants that offer the desired items or services that are located near the traffic congestion or in-route to the final destination.” [0011]
and display an identifier of the item with the identifiers of the one or more data routing tokens on the user interface, “merchant server 140 also may include a marketplace application 150 which may be configured to serve information over network 160 to browser 115 of user device 110. In one embodiment, user 105 may interact with marketplace application 150 through browser applications over network 160 in order to view various products, food items, or services identified in database 145” [0022], and “The user may select and accept a shopping detour and the system may provide recommended directions to the user to take for the one or more shopping destinations” [0011]
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to incorporate the destination-based shopping detour and merchant presentation techniques of Ikavalko into the vehicle payment environment of Gaudin in order to provide destination-aware item selection and user-interface presentation during vehicle travel.
Regarding Claim 15, Gaudin discloses the limitations of claim 15 as recited above in the rejection of claim 9. However, Gaudin does not teach, wherein the method further comprises identifying a destination of the vehicle as the vehicle is travelling along a route, and identifying an item of interest based on the destination, wherein the displaying the identifiers of the one or more data routing tokens further comprises displaying an identifier of the item.
In the same field of endeavor, Ikavalko teaches, identifying a destination of the vehicle as the vehicle is travelling along a route, “The system may then estimate the additional travel time needed to get through the traffic congestion and arrive at the desired destination” [0010], and “The system may also access the user's calendar to determine when the user may need to be at a certain location or destination” [0012].
and identifying an item of interest based on the destination, “the system may analyze the user's purchase history, to-do-list, search history, watch list, wish list, calendar, or the like to determine items or services the user may desire to purchase. The system may find merchants that offer the desired items or services that are located near the traffic congestion or in-route to the final destination.” [0011]
wherein the displaying the identifiers of the one or more data routing tokens further comprises displaying an identifier of the item, “merchant server 140 also may include a marketplace application 150 which may be configured to serve information over network 160 to browser 115 of user device 110. In one embodiment, user 105 may interact with marketplace application 150 through browser applications over network 160 in order to view various products, food items, or services identified in database 145” [0022], and “The user may select and accept a shopping detour and the system may provide recommended directions to the user to take for the one or more shopping destinations” [0011]
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to incorporate the destination-based shopping detour and merchant presentation techniques of Ikavalko into the vehicle payment environment of Gaudin in order to provide destination-aware item selection and user-interface presentation during vehicle travel.
Claim 16 is rejected under 35 U.S.C. § 103 as being unpatentable over Gaudin et al. (US
11,948,138 B2, hereinafter “Gaudin”), in view of Ortiz et al. (US 20200034830 A1, hereinafter “Ortiz”), and further in view of Dong (US 11308497 B2, hereinafter “Dong”).
Regarding Claim 16, Gaudin discloses the limitations of claim 16 as recited above in the rejection of claim 9. In addition, Gaudin further teaches, wherein the transmitting the authorization request from the head unit to an issuing system of the data routing token comprises transmitting a disbursement request authorization message, “Upon receiving a selection of one of the financial cards and a request to make payment, the vehicle payment application may transmit the token representing financial data for the selected financial data via a short-range communication link 120 (or radio frequency link) to the POS terminal 20” [Col. 7-8, lines 63-67], and “ the vehicle payment application 266 may authenticate the user to ensure she is authorized to use stored financial cards to make payments (block 408).” [Col. 25, lines 11-13].
However, Gaudin does not expressly teach, wherein the transmitting the authorization request from the head unit to an issuing system of the data routing token comprises transmitting a disbursement request authorization message with a card present indicator.
Ortiz teaches, wherein the transmitting the authorization request from the head unit to an issuing system of the data routing token comprises transmitting a disbursement request authorization message with a card present indicator, “In alternative embodiments, as explained more fully below, “card present” and other transactions can be conducted, or otherwise implemented, using SEs provided in the form of encrypted and/or otherwise secure, pre-authorized payment tokens stored on mobile devices such as smart phones, tablet computers, and other PDAs.” [0080].
It would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to implement the card-present token authorization techniques of Ortiz within the vehicle payment environment of Gaudin in order to support secure authorization processing for vehicle-based payment transactions.
The combination of Gaudin and Ortiz does not teach, wherein the authorization request is based on at least one of training an artificial intelligence (AI) model or executing the AI model.
Dong teaches, wherein the authorization request is based on at least one of training an artificial intelligence (AI) model or executing the AI model, “computer system 100 receives request 134 and evaluates it using a machine learning model (e.g., fraud detection model 104) designed and trained to recognize the patterns in fraudulent attempts” [Col. 6, lines 60-63], and “Training algorithm 400 (and the various mathematical operations contained therein) is implemented using computer system 100 to initialize and train the fraud detection model” [Col. 9, lines 27-30], and “Equation 506 produces a final output value of fraud detection model 104 for an incoming request 134 that is used to determine whether the incoming request 134 is fraudulent or legitimate” [Col. 11, lines 41-44].
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to modify the combination of Gaudin and Ortiz to incorporate the machine-leaning fraud evaluation techniques of Dong in order to improve fraud detection and authorization security for payment authorization requests transmitted form the vehicle head unit.
Conclusion
The prior art made of record not relied upon and considered pertinent to Applicant’s disclosure:
Bust et al. (US 20190244191 A1, hereinafter ”Bush”), discloses systems, methods, and computer program products for providing a contactless protocol, for contactless commerce transactions involving mobile devices and transaction authorization.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SANG PHUOC LE whose telephone number is (571)272-3659. The examiner can normally be reached Monday - Thursday 7:00 am - 5:30 pm.
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, Charles Appiah can be reached at 571-272-7904. 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.
SANG PHUOC. LE
Examiner
Art Unit 2641
/SANG PHUOC LE/Examiner, Art Unit 2641
/CHARLES N APPIAH/Supervisory Patent Examiner, Art Unit 2641
Prosecution Insights