WO2025014530A1

WO2025014530A1 - Secure interaction method utilizing encrypted digital certificate

Info

Publication number: WO2025014530A1
Application number: PCT/US2023/070125
Authority: WO
Inventors: Gregory Miller
Original assignee: Visa International Service Association
Current assignee: Visa International Service Association
Priority date: 2023-07-13
Filing date: 2023-07-13
Publication date: 2025-01-16
Anticipated expiration: 2026-01-13

Abstract

A method is disclosed. The method includes receiving, by a user device operated by a user from an authentication computer, an encrypted, signed digital certificate, the encrypted, signed digital certificate comprising a digital certificate including interaction details signed by an authentication computer private key, and then encrypted using an access device public key associated with an access device. The method also includes transmitting, by the user device, a message comprising the encrypted, signed digital certificate to the access device. The access device decrypts the encrypted signed digital certificate with an access device private key associated with an access device, verifies the signed digital certificate using an authentication computer public key, analyzes the interaction details, and then provides a resource to the user or the user device.

Description

PATENT Attorney Docket No.: 079900-1381238 Client Reference No.: 6789WO01 SECURE INTERACTION METHOD UTILIZING ENCRYPTED DIGITAL CERTIFICATE CROSS-REFERENCES TO RELATED APPLICATIONS [0001] None. BACKGROUND [0002] There are a number of circumstances where a user wishes to obtain a resource from an access device, but the access device may not have networking capabilities or may be temporarily unable to connect to a network. It would be desirable to provide for secure and convenient methods and systems that can allow a user to access a resource under such circumstances. [0003] Further, in the area of supplying energy to vehicles, various methods have been developed. Such methods often require a user to provide a credential to an energy supply terminal. For example, to purchase gasoline from a gasoline supply terminal (e.g., a gas pump) or to purchase electricity from an electric power terminal, the user needs to provide a secure credential such as a credit or debit card number to the terminal. [0004] Providing the secure credential to the energy supply terminal increases the risk that the secure credential can be stolen by an unauthorized user. For example, some unauthorized users can put skimmers on card readers at the energy supply terminals, and/or can intercept wireless data transmissions between an authorized user device and the energy supply terminal. Further, hackers can hack into the energy supply terminals to obtain the secure credentials. Still further, unscrupulous employees that may have access to the secure credentials can also steal the secure credentials obtained by the energy supply terminals. [0005] Another problem that is present is that there can be many different energy supply terminals. As more payment methods become available, each energy supply terminal needs to be specifically programmed or adapted to process the

1 77549200V.1 different payment methods. This situation can be difficult to implement and maintain. Still further, if card credentials are received at an energy supply terminal, the energy supply terminal needs to be PCI-DSS (payments card industry – data security standard) complaint. Maintaining such security compliance across many different types of energy supply terminals is also difficult to implement and maintain. [0006] Another problem is that the current charging infrastructure needs to keep up with continued demand for electric vehicles. The number of electric charging stations needs to increase. Conventional electric charging stations often need expensive components (e.g., card readers) and specialized software (e.g., cryptographic keys to sure payment data) to process payment transactions. [0007] Embodiments of the invention address these and other problems, individually and collectively. SUMMARY [0008] One embodiment of the invention includes a method comprising: receiving, by a user device operated by a user from an authentication computer, an encrypted, signed digital certificate, the encrypted, signed digital certificate comprising a digital certificate comprising interaction details signed by an authentication computer private key, and then encrypted using an access device public key associated with an access device; and transmitting, by the user device, a message comprising the encrypted, signed digital certificate to the access device, wherein the access device decrypts the encrypted signed digital certificate with an access device private key associated with an access device, verifies the signed digital certificate using an authentication computer public key, analyzes the interaction details, and then provides a resource to a user or the user device. [0009] Another embodiment of the invention includes a user device comprising: a processor; and a computer readable medium, the computer readable medium comprising code executable by the processor to cause the processor to perform operations including: receiving, from an authentication computer, an encrypted, signed digital certificate, the encrypted, signed digital certificate comprising a digital certificate comprising interaction details signed by an authentication computer private key, and then encrypted using an access device

2 77549200V.1 public key associated with an access device, and transmitting a message comprising the encrypted, signed digital certificate to the access device, wherein the access device decrypts the encrypted signed digital certificate with an access device private key associated with an access device, verifies the signed digital certificate using an authentication computer public key, analyzes the interaction details, and then provides a resource to a user or the user device. [0010] Another embodiment of the invention include a method comprising: receiving, by an access device from a user device, a message comprising an encrypted signed digital certificate, wherein the encrypted signed digital certificate comprises a digital certificate comprising interaction details signed by an authentication computer private key, and then encrypted using an access device public key associated with an access device; decrypting, by the access device, the encrypted signed digital certificate with an access device private key to obtain the signed digital certificate; verifying, by the access device, the signed digital certificate using an authentication computer public key; analyzing, by the access device, the interaction details; and providing, by the access device, a resource to the user or the user device. [0011] Another embodiment includes an access device comprising: a processor; and a computer readable medium, the computer readable medium comprising code executable by the processor for performing operations comprising: receiving, from a user device, a message comprising an encrypted signed digital certificate, wherein the encrypted signed digital certificate comprises a digital certificate comprising interaction details signed by an authentication computer private key, and then encrypted using an access device public key; decrypting the encrypted signed digital certificate with an access device private key to obtain the signed digital certificate; verifying the signed digital certificate using an authentication computer public key; analyzing the interaction details; and providing a resource to the user or the user device. [0012] A better understanding of the nature and advantages of embodiments of the invention may be gained with reference to the following detailed description and accompanying drawings. BRIEF DESCRIPTION OF THE DRAWINGS

3 77549200V.1 [0013] FIG.1 shows a block diagram showing components of a system according to an embodiment. [0014] FIG.2 shows a block diagram showing components of a vehicle according to an embodiment. [0015] FIG.3 shows a block diagram showing components of an energy supply terminal according to an embodiment. [0016] FIG.4 shows a block diagram showing components of an authentication computer according to an embodiment. [0017] FIG.5 shows a block diagram showing components of a communication device according to an embodiment. [0018] FIG.6 shows a flow diagram illustrating methods according to embodiments. DETAILED DESCRIPTION [0019] Prior to discussing embodiments of the disclosure, some terms can be described in further detail. [0020] A “user” may include an individual. In some embodiments, a user may be associated with one or more personal accounts and/or mobile devices. The user may also be referred to as a cardholder, account holder, or consumer in some embodiments. [0021] A “user device” may be a device that is operated by a user. Examples of user devices may include a mobile phone, a smart phone, a card, a personal digital assistant (PDA), a laptop computer, a desktop computer, a server computer, a thin-client device, a tablet PC, etc. Additionally, user devices may be any type of wearable technology device, such as a watch, earpiece, rings, bracelets, glasses, a vehicle such as an electric vehicle, etc. The user device may include one or more processors capable of processing user input. The user device may also include one or more input sensors for receiving user input. There are a variety of input sensors capable of detecting user input, such as accelerometers, cameras, microphones, etc. The user input obtained by the input sensors may be from a variety of data input types, including, but not limited to, audio data, visual data, or biometric data. The

4 77549200V.1 user device may comprise any electronic device that may be operated by a user, which may also provide remote communication capabilities to a network. Examples of remote communication capabilities include using a mobile phone (wireless) network, wireless data network (e.g., 3G, 4G or similar networks), Wi-Fi, Wi-Max, or any other communication medium that may provide access to a network such as the Internet or a private network. A user device may also be a payment device such as a credit, debit, or prepaid card. [0022] An “application” may be computer code or other data stored on a computer readable medium (e.g., memory element or secure element) that may be executable by a processor to complete a task. [0023] A “key” may include a piece of information that is used in a cryptographic algorithm to transform input data into another representation. A cryptographic algorithm can be an encryption algorithm that transforms original data into an alternate representation, or a decryption algorithm that transforms encrypted information back to the original data. Examples of cryptographic algorithms may include triple data encryption standard (TDES), data encryption standard (DES), advanced encryption standard (AES), etc. [0024] A "public key" may include an encryption key that may be shared openly and publicly. The public key may be designed to be shared and may be configured such that any information encrypted with the public key may only be decrypted using a private key associated with the public key (i.e., a public/private key pair). [0025] A "private key" may include any encryption key that may be protected and secure. A private key may be securely stored at an entity and may be used to decrypt any information that has been encrypted with an associated public key of a public/private key pair associated with the private key. [0026] A “public/private key pair” may refer to a pair of linked cryptographic keys generated by an entity. The public key may be used for public functions such as encrypting a message to send to the entity or for verifying a digital signature which was supposedly made by the entity. The private key, on the other hand may be used for private functions such as decrypting a received message or applying a digital signature. In some embodiments, the public key may be authorized by a body known

5 77549200V.1 as a Certification Authority (CA) which stores the public key in a database and distributes it to any other entity which requests it. The private key can typically be kept in a secure storage medium and will usually only be known to the entity. Public and private keys may be in any suitable format, including those based on Rivest- Shamir-Adleman (RSA) or elliptic curve cryptography (ECC). [0027] An “interaction” may include a reciprocal action or influence. An interaction can include a communication, contact, or exchange between parties, devices, and/or entities. Example interactions include a transaction between two parties and a data exchange between two devices. In some embodiments, an interaction can include a user requesting access to power delivery. [0028] “Credentials” may comprise any evidence of authority, rights, or entitlement to privileges. For example, access credentials may comprise permissions to access certain tangible or intangible assets, such as a building or a file. Examples of credentials may include passwords, account numbers, passcodes, or secret messages. [0029] “Payment credentials” may include any suitable information associated with an account (e.g., a payment account and/or payment device associated with the account). Such information may be directly related to the account or may be derived from information related to the account. Examples of account information may include a PAN (primary account number or “account number”), username, expiration date, CVV (card verification value), dCVV (dynamic card verification value), CVV2 (card verification value 2), CVC3 card verification values, etc. CVV2 is generally understood to be a static verification value associated with a payment device. CVV2 values are generally visible to a user (e.g., a consumer), whereas CVV and dCVV values are typically embedded in memory or authorization request messages and are not readily known to the user (although they are known to the issuer and payment processors). Payment credentials may be any information that identifies or is associated with a payment account. Payment credentials may be provided to make a payment from a payment account. Payment credentials can also include a username, an expiration date, a gift card number or code, and any other suitable information.

6 77549200V.1 [0030] A "digital signature" may include a type of electronic signature. A digital signature may encrypt documents with digital codes that can be difficult to duplicate. In some embodiments, a digital signature may refer to the result of applying an algorithm based on a public/private key pair, which allows a signing party to manifest, and a verifying party to verify, the authenticity and integrity of a document. The signing party acts by means of the private key and the verifying party acts by means of the public key. This process certifies the authenticity of the sender, the integrity of the signed document and the so-called principle of nonrepudiation, which does not allow disowning what has been signed. A certificate or other data that includes a digital signature by a signing party is said to be "signed" by the signing party. [0031] A "certificate" or "digital certificate" may include an electronic document and/or data file. In some cases, the certificate or the digital certificate may be a device certificate. In some embodiments, a digital certificate may use a digital signature to bind a public key with data associated with an identity. A digital certificate may be used to prove the ownership of a public key. The certificate may include one or more data fields, such as the legal name of the identity, a serial number of the certificate, a valid-from and valid-to date for the certificate, certificate related permissions, etc. A certificate may contain a "valid-from" date indicating the first date the certificate is valid, and a "valid-to" date indicating the last date the certificate is valid. A certificate may also contain a hash of the data in the certificate including the data fields. A certificate can be signed by a certificate authority. The certificate or digital certificate can also include interaction data such as one or more access device identifiers, one or more user device identifiers (e.g., VIN numbers), a timestamp of when the certificate was created, a validity period, an authentication computer public key, etc. [0032] A "certificate authority" may include an entity that issues digital certificates. A certificate authority may prove its identity using a certificate authority certificate, which includes the certificate authority’s public key. A certificate authority certificate may be signed by another certificate authority’s private key or may be signed by the same certificate authority’s private key. The latter is known as a self- signed certificate. The certificate authority may maintain a database of all certificates issued by the certificate authority. The certificate authority may maintain a list of

7 77549200V.1 revoked certificates. The certificate authority may be operated by an entity, for example, a processing network entity, an issuer, an acquirer, a central bank etc. In some cases, a certificate authority can maintain an authentication computer. [0033] An “access device” may be any suitable device that provides access to a resource. An access device may be in any suitable form. Some examples of access devices include an energy supply terminal (e.g., an electric charger at a charging station), gasoline pumps, vending machines, kiosks, POS or point of sale devices (e.g., POS terminals), cellular phones, PDAs, personal computers (PCs), tablet PCs, hand-held specialized readers, set-top boxes, electronic cash registers (ECRs), automated teller machines (ATMs), virtual cash registers (VCRs), and the like. An access device may use any suitable contact or contactless mode of operation to send or receive data from, or associated with, a user mobile communication device. In some embodiments, an access device may include a reader, a processor, and a computer-readable medium. A reader may include any suitable contact or contactless mode of operation. For example, exemplary readers can include radio frequency (RF) antennas, optical scanners, bar code readers, or magnetic stripe readers to interact with a payment device and/or mobile communication device. [0034] Embodiments provide improved secure and convenient ways to obtain resources from access devices. [0035] As noted above, as an example, some energy supply terminals (e.g., electric charging stations) do not have networking capabilities, do not have long range communication capabilities, and/or can be temporarily unable to access a network. Embodiments can allow users to prepay for energy supplied by an energy supply terminal in a secure and convenient manner. In specific embodiment, the energy may be electricity, the energy supply terminal may be an electric charging station. The electric charging station can charge electric vehicles. [0036] In embodiments of the invention, each charging station in a charging network can be provisioned with its own unique ID and be part of a PKI (public key infrastructure). If provisioned by a central authority (e.g., a charging station operator), the PKI in the charging station can be updated or managed via a secure element of an electric vehicle or directly with a server computer (e.g., an authentication

8 77549200V.1 computer) authorized by the central authority. In the former example, when the electric vehicle connects to the charging station to receive a charge, the electric vehicle can also communicate with an authentication computer operated by the central authority. The authentication computer can provide any updates to the PKI associated with the charging station. In some cases, the charging station can communicate with the authentication computer via a secure element in the electric vehicle. By using the secure element of the electric vehicle, the user of the electric vehicle will not have access to the charging station private key. [0037] In alternative embodiments, the use of a secure element in an electric vehicle is not required, since the charging station can verify a digital signature associated with a digital certificate. In such embodiments, the electric vehicle may not have a secure element, or if it has one, it need not be used when transferring data between the charging station and the authentication computer. [0038] In some embodiments, the charging station can generate its own public/private key pair. For example, when the charging station is initialized, it can generate a public/private key pair. The charging station PKI can be updated at a later date if fraud has been detected (e.g., a determination has been made that the secret key has been compromised). Any generated public key and associated digital certificates can be stored at an authentication computer. [0039] In embodiments of the invention, rather than paying to charge their electric vehicle at the time of the charging, the user of the electric vehicle can prepay for the anticipated amount of electricity to be obtained. The user can obtain a signed certificate from the authentication computer, which authorizes the charging of a particular amount of electricity for a particular charging station(s). For example, the user can top up an account associated with the authentication computer. The account can hold value that can be used to generate the digital certificates that can be used to obtain electricity at the charging station(s) associated with the authentication computer. The topping up of the account can occur using any suitable payment process including a credit, debit, or prepaid card transaction, a cryptocurrency transaction, or a cash transaction. [0040] Once the authentication computer has received an indication that the user’s account has funds, the authentication computer can generate a signed digital

9 77549200V.1 certificate. The digital certificate can include information including, but not limited to: a monetary amount and/or an amount of electricity (e.g., in KWh) that is allowed to be obtained by the user or the user’s electric vehicle, a date, an expiration date, an authentication computer digital signature, one or more charging station identifiers for charging stations that the user anticipates using, etc. In embodiments of the invention, the user of the electric vehicle can select a particular charging station ahead of time and the corresponding charging station identifier can be included in the digital certificate. In some embodiments, when the electric vehicle connects to the charging station, the electric vehicle can communicate with the authentication computer, and the charging station can provide a charging station identifier to the authentication computer at that time. In such embodiments, the digital certificate need not have a charging station identifier. [0041] The authentication computer can then generate the above-described signed digital certificate and encrypt it using a charging station public key. In other embodiments, a secret key/secret key infrastructure can be used to protect the signed digital certificate. As noted above, the signed digital certificate can include an amount of funds or electricity prepaid by the user. [0042] The electric vehicle can send the signed digital certificate to the charging station when the electric vehicle obtains electricity from the charging station. The charging station can use its corresponding private key (or symmetric key in the case where symmetric cryptography is used) to decrypt the encrypted digital certificate to obtain the digital certificate. Once decrypted, the charging station can analyze the digital certificate and can determine the funds available for charging by the user or the amount of charge that the user can obtain. If the total charge needed to fully charge the electric vehicle and the corresponding monetary amount exceeds what is authorized by the digital certificate, then the charging station can stop charging the electric vehicle. After charging is completed, in some embodiments, the charging station can generate a second digital certificate or a new message with an indication of how much charge was received by electric vehicle, the value of the received charge, and/or the remaining balance (if any) relative to the amount in the received first digital certificate. The charging station can sign the data in the second digital certificate with a charging station private key to create a signed second digital certificate. The charging station can then encrypt the signed second digital certificate

10 77549200V.1 using an authentication computer public key. The encrypted second signed digital certificate can then be provided by the charging station to the electric vehicle. The electric vehicle can then provide (e.g., via a secure element in the electric vehicle) the encrypted signed second digital certificate to the authentication computer. The authentication computer can then decrypt the encrypted signed second digital certificate to obtain the signed second digital certificate. The authentication computer can verify the digital signature in the signed second digital certificate using a charging station public key. Once verified, the authentication computer can analyze the data in the second digital certificate and can adjust any balance on the account of the user. [0043] In some embodiments, if the amount needed to charge the electric vehicle is less than the total amount available on the first digital certificate, the authentication computer can then generate a third digital certificate based on the remaining balance. If the user adds more funds to their account with the authentication computer, the first digital certificate can be invalidated and deleted, and a new digital certificate can be generated by the authentication computer based on the new amount. Alternatively, digital certificates can be used until there is no value left in them. Thus, when charging, the electric vehicle can first use up any value associated with a first digital certificate, and then use other digital certificates to pay for any additional charging of the electric vehicle. [0044] In some embodiments, digital certificates passing between the charging station and an authentication computer via the electric vehicle can be signed by a secure element in the electric vehicle. This can ensure that the digital certificates were not altered during transmission between the charging station and the authentication computer. [0045] In some embodiments, the charging station can use the electric vehicle’s secure element to communicate with the authentication computer to authenticate a received digital certificate and validate the funds associated with the received digital certificate. In such a scenario, the electric vehicle can obtain updated information from the authentication computer about any remaining balance associated with the user’s account and/or the digital certificate.

11 77549200V.1 [0046] In some embodiments, the charging station first validates the digital certificate based on unique information associated with charging station. The charging station can then contact a certifying authority (e.g., the authentication computer) to confirm that the digital certificate is authentic. This can all be done through the secure element of the electric vehicle to ensure that any non-secure areas of the electric vehicle are not capable of interfering with communications between the charging station and the certifying authority (e.g., the authentication computer). [0047] In some cases, the certifying authority that generates the digital certificate can also verify it. The charging station knows who the certifying authority should be. If charging station contacts the certifying authority but the certifying authority is unable to certify the digital certificate, then the charging station can determine that a potentially fraudulent transaction is taking place and it will not charge the electric vehicle. [0048] One potential problem with pre-authorizing a digital certificate for charging can involve a nefarious actor breaking the encryption scheme and obtaining a copy of the digital certificate. Once the nefarious actor has possession of the digital certificate, they could potentially use it to fraudulently charge their electric vehicle. [0049] However, in embodiments of the invention, each charging station can have unique information. If a nefarious actor is able to spoof the system, they may be able to access only the particular charging station(s) specified in the digital certificate. This can limit any potential fraud. Additionally, to determine if there is a problem, the charging station and the authentication computer can both maintain a log of the amount of charge dispensed for a given period of time. Further, in some cases, the charging station can also include a camera to obtain a photo of each electric vehicle being charged. Still further, the electric vehicle can digitally provide its license plate number and/or VIN to the charging station to identify it during each charging session. In some embodiments, the digital certificate can also include information (e.g., the license plate number or VIN) identifying the electric vehicle. The charging station can match the electric vehicle information obtained from the camera (or other means) to the electric vehicle information in the digital certificate to determine if they match before it provides electricity to the electric vehicle.

12 77549200V.1 [0050] After the charging station is finished charging the electric vehicle, a handshake can take place between the charging station and the authentication computer. This can occur before the charging station disconnects with the electric vehicle. The authentication computer can compare the amount of charge dispensed prior to the charging of the current electric vehicle. If there is a discrepancy, the authentication computer and the charging station will know that there is fraud. The next time a legitimate charging session takes place, the authentication computer can allow the charging station to finish charging and will not disrupt the legitimate charging session, but then the unique information associated with the charging station can be modified (e.g., a new key pair can be generated). Thus, at best, any nefarious actor can only gain access to unauthorized charging for a short amount of time, and the fraud can be limited in embodiments of the invention. [0051] FIG.1 shows a system according to embodiments. The system can comprise a user 100 that operates a communication device 102 and a vehicle 103 comprising an electric vehicle processor 104 (which can be an example of a first processor). In some embodiments, the electric vehicle processor 104 can be an electric vehicle communication controller (EVCC). [0052] Although FIG.1 and some of the description below specifically relates to charging electric vehicles with an energy supply terminal, it is understood that other embodiments of the invention may not relate to charging an electric vehicle. In some embodiments, the supply terminal can be a gasoline pump. In other embodiments, another type of user device such as a mobile phone can be used to access a resource from an access device such as a vending machine or a gate access device at a transit station. [0053] The system in FIG.1 can also include an energy supply terminal 105 (e.g., an electric vehicle charging station) comprising an energy supply terminal processor 106 (which can be an example of a second processor). In some embodiments, the energy supply terminal processor 106 can be a supply equipment communication controller (SECC). [0054] The terms “electric vehicle communication controller (EVCC)” and “supply equipment communication controller (SECC)” are from ISO 15118. ISO 15118 is one of the International Electrotechnical Commission's (IEC) group of

13 77549200V.1 standards for electric road vehicles and electric industrial trucks. ISO 15118 is a proposed international standard defining a vehicle to grid (V2G) communication interface for bi-directional charging/discharging of electric vehicles. [0055] A cable 120 can be attached to the energy supply terminal 105 and can physically and communicatively connect the electric vehicle 103 and the energy supply terminal 105. In some embodiments, the cable 120 is an electric charging cable adapted to charge an electric car or other vehicle 103. In some embodiments, the energy supply terminal 105 and the vehicle 103 can communicate through a protocol such as ISO 15118. [0056] In other embodiments, the cable 120 is not necessary where other energy supply mechanisms can be used. For example, the vehicle 103 can receive energy (e.g., electricity) from the energy supply terminal 105 via induction, which would not require the use of a physical charging cable. Communications passing between the energy supply terminal 105 and the vehicle 103 can occur via another wireless protocol such as Bluetooth™ or Wi-Fi™. [0057] The system can further include an authentication computer 108 operated by a service provider. The service provider can be a certificate authority in some embodiments. The system may further include a transaction processing subsystem which can include a processing network computer 112 in a processing network such as a payment processing network, and an authorizing entity computer 114, which may be in communication with the authentication computer 108. [0058] The electrical components (e.g., the computers) in the system of FIG.1 and any of the following figures can be in operative communication with each other through any suitable communications medium 150. Suitable examples of the communications medium 150 may be any one and/or the combination of the following: a direct interconnection; the Internet; a Local Area Network (LAN); a Metropolitan Area Network (MAN); an Operating Missions as Nodes on the Internet (OMNI); a secured custom connection; a Wide Area Network (WAN); a wireless network (e.g., employing protocols such as, but not limited to a Wireless Application Protocol (WAP), I-mode, and/or the like); and/or the like. Messages between the computers, networks, and devices of FIG.1 may be transmitted using a secure communications protocol such as, but not limited to, File Transfer Protocol (FTP);

14 77549200V.1 HyperText Transfer Protocol (HTTP); and Secure Hypertext Transfer Protocol (HTTPS). In some embodiments, however, as noted above, the energy supply terminal 105 may not have direct to or may be temporarily unable to access the communications medium 150. [0059] In some embodiments, the service provider operating the authentication computer 108 may be one that can provide charging services to users. It may alternatively be an entity (e.g., a payment processor) that performs services on behalf of the service provider that provides charging services. Examples of the service providers can include charge point operators, electric vehicle manufacturers, payment processors such as payment service providers, etc. The service provider operating the authentication computer 108 can also be a certificate authority. [0060] In some embodiments, the user 100 may communicate with the authentication computer 108 to establish a service provider account if the user 110 has a preexisting relationship with the service provider. In some cases, the service provider account may be used to obtain electricity from the energy supply terminal 105. In some embodiments, the service provider account may be identified by a service provider account number such as eMobility account ID (eMAID). In other embodiments, the service provider operating the authentication computer 108 may not have a pre-existing relationship with the user 100. [0061] FIG.2 illustrates a block diagram of a vehicle 200, according to some embodiments. Vehicle 200 can be, for example, an electric vehicle. Although vehicle 200 may be described as an automobile, it should be understood that in some embodiments, the techniques described herein can also be applied to other types of vehicles such as motorcycles, boats, aircrafts, or other types of powered machines that are used to transport a user from one location to another. The vehicle 200 is an example of a user device. [0062] Vehicle 200 may include various electronic control units (ECUs) to operate and control the electrical system or other subsystems of vehicle 200, and may include sensors 235 that the ECUs can monitor. Each ECU may include a microcontroller and one or more memories (e.g., any combination of SRAM, EEPROM, Flash memories, etc.) to store one or more executable programs for the

15 77549200V.1 ECU. Examples of ECUs may include engine / motor control unit 210, transmission control unit 220, etc. In some embodiments, vehicle 200 may include additional ECU(s) not specifically shown, omit one or more ECUs, and/or integrate any of the functionalities of different ECUs into a single ECU. [0063] Vehicle 200 can also include a battery system 230 comprising one or more batteries and a charge interface 233 for charging the one or more batteries. The battery system 230 and the charge interface 233 can be in communication with and coupled to the in-vehicle computing system 250 and its processor 252. [0064] Engine / motor control unit 210 may control the actuators, valves, motor, and/or other components of the engine of vehicle 200, or an electric motor of the vehicle 200. Transmission control unit 220 may control the gear shifting and the transmission modes (e.g., park, drive, neutral, reverse) of vehicle 200. Battery system 230 may include electronics that can control the electrical voltage and current supplied by its one or more batteries to the various components of vehicle 200. Sensors 235 may include vehicle speed sensors (e.g., wheel sensors) to detect the speed of vehicle 200, temperature sensors to detect the operating temperature of the vehicle’s various components, air sensors to detect oxygen level in the engine, sensors to detect the amount of energy currently (e.g., electricity, gas, etc.) present with the vehicle or the available capacity of any energy storage devices such batteries, cameras to observe the surroundings of vehicle 200, etc. The various ECUs, devices, and sensors may communicate with one another via a vehicle communication bus 240. Examples of vehicle communication bus 240 may include a controller area network (CAN) bus, a local interconnect network (LIN) bus, a vehicle area network (VAN) bus, or other suitable signal buses for vehicle communication. [0065] Vehicle 200 may also include various radio frequency (RF) transceivers to allow vehicle 200 to receive and transmit RF signals with other devices. For example, vehicle 200 may include a positioning satellite receiver 270 such as a GPS receiver to receive satellite signals that can be demodulated and decoded to determine the location of vehicle 200. The positioning satellite receiver 270 can be used by a positioning or navigation subsystem of vehicle 200 to perform routing and mapping functions.

16 77549200V.1 [0066] Vehicle 200 may also include a wireless communication subsystem 290 to enable network connectivity for vehicle 200. Wireless communication subsystem 290 may include one or more wireless transceivers that use WiFi, WiMax, or other types of wireless network communication protocols to connect vehicle 200 to an external network (e.g., the Internet) such that vehicle 200 can communicate with remote servers. Wireless communication subsystem 290 may also include one or more short or near range wireless transceivers such as RFID, Bluetooth or Bluetooth Low Energy, NFC, beacon, infrared transmitters and/or receivers that can be used to communicate with an access device in proximity to vehicle 200. [0067] Vehicle 200 may also include an in-vehicle computing system 250 with which a user of vehicle 200 can interact. In some embodiments, in-vehicle computing system 250 can be coupled to vehicle communication bus 240 to receive vehicle status information from the ECUs and sensors 235. [0068] In-vehicle computing system 250 may include a processor 252, a memory 260, and user interface 254. User interface 254 may include an input interface such as any number of buttons, knobs, microphone and/or a touchscreen that can receive user input, and an output interface such as a display (may be part of a touchscreen) and/or speakers. The display of user interface 254 can be integrated with the housing of in-vehicle computing system 250, or can be a separate component coupled to in-vehicle computing system 250 but mounted at a different location than in-vehicle computing system 250. For example, the display of user interface 254 can be mounted on the surface of the center console, on the dashboard, on the surface of the rear console, behind the headrest, on the interior ceiling, on the visor, or other suitable location in vehicle, and may display various types of information including information such as vehicle status information (e.g., speed, fuel economy, engine temperature, etc.), environmental information (e.g., inside/outside temperature, weather, etc.), navigation information (e.g., maps, routes, places of interests, etc.), entertainment such as videos or titles of audio selections or radio stations, energy level information (e.g., amount of charge present and needed to fill to capacity, amount of gas present and needed to fill to capacity), transaction information, energy terminal information, etc.

17 77549200V.1 [0069] Memory 260 may include any combination of SRAM, DRAM, EEPROM, Flash, and/or other types of memories, etc. Memory 260 may store a number of applications such as in-vehicle access application 262, navigation application 264, and/or other applications not specifically shown such as a climate control application. [0070] Navigation application 264 can be part of a positioning or navigation subsystem of vehicle 200, and may provide navigation functionalities such as mapping and routing functions. A user of vehicle 200 may input a desired location into in-vehicle computing system 250, and navigation application 264 can determine a current location of vehicle 200 using a positioning satellite receive 270, and provide directions to travel to the desired location. Navigation application 264 may display a map on user interface 254 and highlight a route to a desired destination. Navigation application 264 may also display nearby places of interests and/or nearby merchants on user interface 254. [0071] In-vehicle access application 262 enables in-vehicle computing system 250 to access resources for the vehicle 200. In some scenarios, in-vehicle access application 262 may allow a user of vehicle 200 to execute a transaction with a resource provider computer without requiring the user to exit vehicle 200, and without requiring the user to use another device such as the user’s payment card or mobile device. [0072] The vehicle 200 can also include a secure element 261. The secure element 261 can be in communication with the processor 252 and can provide a secure environment for the storage or transmission of any data or for performing computations. The secure element 261 can be include a secure operating system (OS) in a tamper resistant processor chip or secure component. It can protect assets (root of trust, sensitive data, keys, certificates, applications) against high level software and hardware attacks. Applications that process this sensitive data on an SE are isolated and so operate within a controlled environment not impacted by software (including possible malware) found elsewhere on the operating system of the vehicle 200. The secure element 261 may store account credentials 266 or tokens, or reference identifiers thereof for various accounts. The secure element 261 can also comprise cryptographic keys 268, which can be used to encrypt data, sign

18 77549200V.1 data, verify data, etc. The secure element 261 can also comprise a cryptography module which may include signing, encryption and/or decryption algorithms. [0073] The memory 260 can comprise a computer readable medium. The computer readable medium may comprise code, executable by the processor 252 to perform operations comprising: receiving, by a user device operated by a user from an authentication computer, an encrypted, signed digital certificate, the encrypted signed digital certificate comprising a digital certificate comprising interaction details signed by an authentication computer private key, and then encrypted using an access device public key; and transmitting, by the user device, a message comprising the encrypted, signed digital certificate to the access device, wherein the access device decrypts the encrypted signed digital certificate with an access device private key, verifies the signed digital certificate using an authentication computer public key, analyzes the interaction details, and then provides a resource to the user or the user device. [0074] FIG.3 shows a block diagram of an energy supply terminal 300 according to an embodiment. The energy supply terminal 300 can comprise a processor 302. The energy supply terminal may also comprise a computer readable medium 304, a short range communication interface 306, an actuator 308, a vehicle interface 310, and a long range communication interface 314 coupled to the processor 302. An energy source 312 can be coupled to the actuator 308 and the vehicle interface 310. The actuator 308 may be a pump or switch (e.g., an electrical or mechanical switch) that allows the energy source 312 to provide energy to the vehicle interface 310 and then to a connected vehicle. The energy source 312 could be an electrical line or conduit, or it could be a fuel tank. [0075] The computer readable medium 304 may further comprises a communication module 304A, an energy regulation module 304B, an authentication module 304C, a cryptography module 304D, and keys 304E. The communication module 304A can include code, executable by the processor 302 to allow the energy supply terminal 300 to communicate with external devices such as a vehicle or remote computer such as the previously described terminal support computer 70. The energy regulation module 304B and the processor 302 can determine how much energy is needed or should be provided to a vehicle, and can control the actuator

19 77549200V.1 308 to control the flow of energy to the vehicle interface 310 and to the connected vehicle. The authentication module 304C and the processor 302 can be used to authenticate a user and/or a vehicle that may be connected to the energy supply terminal 300. The cryptography module 304D and the processor 302 can include algorithms and programs to perform cryptographic operations including signing, encryption, decryption, hashing, etc. The keys 304E can be cryptographic keys such as symmetric or asymmetric keys. [0076] The computer readable medium 304 may further comprise code, which when executed by the processor 302, causes the processor to perform operations comprising: receiving, from a user device operated by a user, an encrypted, signed digital certificate, the encrypted signed digital certificate comprising a digital certificate comprising interaction details signed by an authentication computer private key, and then encrypted using an access device public key; decrypting the encrypted signed digital certificate with an access device private key; verifying the signed digital certificate using an authentication computer public key; and analyzing the interaction details; and providing a resource to the user or the user device. [0077] FIG.4 shows a block diagram of an authentication computer 400 according to an embodiment. The authentication computer 400 can comprise a processor 402, which may be coupled to a data storage 406 and a network interface 408. A computer readable medium 404 may also be operatively coupled to the processor 402. The data storage 406 can store any suitable data including but not limited to credentials and/or tokens, references to credentials and/or tokens, user data (e.g., usernames) or vehicle data (e.g., VINs) associated with the credentials or tokens, interaction data for interactions, digital certificates, user account data, etc. [0078] The computer readable medium 404 may comprise a number of software modules and/or data including a credential / token management module 404A, an authentication module 404B, an authorization processing module 404C, a cryptography module 404D, and keys 404E. [0079] The credential / token management module 404A may comprise code that causes the processor 402 to retrieve credentials or tokens from the data storage 406 in response to receiving credential or token identifiers. The credential / token

20 77549200V.1 management module 404A may also comprise code that causes the processor 402 to receive and store credentials and/or tokens in the data storage 406. [0080] The authentication module 404B may comprise code that causes the processor 402 to authenticate users, user devices, or vehicles used by users, before processing transactions. [0081] The authorization processing module 404C may comprise code that causes the processor 402 to perform authorization processing. Authorization processing can include generating and transmitting authorization request messages or providing instructions to generate and transmit authorization request messages, receive authorization response messages, and generate notifications relating to transaction authorizations or declines. Authorizing processing can also including gathering data for an authorization and transmitting it to another computer. [0082] The cryptography module 404D may comprise code that causes the processor 402 to perform cryptographic operations including encryption, decryption, hashing, signing, signature verification, key generation, etc. The cryptography module 404D and the processor 402 can also generate encrypted, signed digital certificates. [0083] The keys 404E can be cryptographic keys such as symmetric or asymmetric cryptographic keys. [0084] The computer readable medium 404 may also comprise code, executable by the processor 402 to perform operations comprising: generating a message comprising an encrypted signed digital certificate, wherein the encrypted signed digital certificate comprises a digital certificate comprising interaction details signed by an authentication computer private key, and then encrypted using an access device public key; and transmitting the message comprising the encrypted, signed digital certificate to a vehicle, which provides the message to an access device, which decrypts the encrypted signed digital certificate with an access device private key, verifies the signed digital certificate using an authentication computer public key; and analyzes the interaction details, and provides a resource to the user or the user device

21 77549200V.1 [0085] FIG.5 shows a block diagram of a communication device 500 in according to an embodiment. The communication device 500 may include device hardware 504 coupled to a system memory 502. In some embodiments, the communication device 500 can be a mobile phone of a user that operates an electric vehicle. [0086] Device hardware 504 may include a processor 506, a short range antenna 514, a long range antenna 516, input elements 510, a user interface 508, and output elements 512 (which may be part of the user interface 508). Examples of input elements may include microphones, keypads, touchscreens, sensors, etc. Examples of output elements may include speakers, display screens, and tactile devices. [0087] The long range antenna 516 may include one or more RF transceivers and/or connectors that can be used by communication device 500 to communicate with other devices and/or to connect with external networks. The user interface 508 can include any combination of input and output elements to allow a user to interact with and invoke the functionalities of communication device 500. The short range antenna 509 may be configured to communicate with external entities through a short range communication medium (e.g., using Bluetooth, Wi-Fi, infrared, NFC, etc.). The long range antenna 819 may be configured to communicate with a remote base station and a remote cellular or data network, over the air. [0088] The system memory 502 can be implemented using any combination of any number of non-volatile memories (e.g., flash memory) and volatile memories (e.g., DRAM, SRAM), or any other non-transitory storage medium, or a combination thereof media. [0089] The system memory 502 may also store a transaction initiation module 502A, a voice assistant module 502B, an authentication module 502C, credentials and/or tokens 502D, and an operating system 502E, The transaction initiation module 502A may include instructions or code initiating and conducting a transaction with an external device such as an access device, an authentication computer, or a processing computer. It may include code, executable by the processor 506, for generating and transmitting authorization request messages, as well as receiving and forwarding authorization response messages. It may also include code,

22 77549200V.1 executable by the processor 506, for forming a local connection or otherwise interacting with an external device. The voice assistant module 502B may comprise code, executable by the processor 506, to receive voice segments, and generate and analyze data corresponding to the voice segments. The authentication module 502C may comprise code, executable by the processor 506, to authenticate a user. This can be performed using user secrets (e.g., passwords) or user biometrics. System memory 502 may also store credentials and/or tokens or references to credentials and/or tokens 502D. [0090] FIG.6 shows a flow diagram illustrating methods according to embodiments. The flow is described with respect to the previously described communication device 102, the authentication computer 108, the vehicle 103, and the energy supply terminal 105. [0091] In step S602, a user operating the communication device 102 can contact the authentication computer 108 to prepay for an anticipated charge of the vehicle 103, which is also operated by the user. For example, the user can use an application or browser on the communication device 102 to communicate with the authentication computer 108. The user can provide data of the identity of the energy supply terminal 105 at a location that the user anticipates using in the near future, and optionally an amount or limit of what the user is willing to pay for the anticipated charging at the energy supply terminal 105. The user can also identify the vehicle 103 to the authentication computer 108 by providing a vehicle identifier and/or a vehicle address (e.g., an IP address or a phone number) associated with the vehicle 103. The user may also provide the identities of other energy supply terminals that they expect to use in the near future. For example, the user may anticipate driving from San Francisco to Los Angeles, and may anticipate charging their electric car at least two times during that trip so the identities of at least two electric charging stations can be provided to the authentication computer 108. [0092] In step S604, the authentication computer 108 can receive the information from the communication device 102 in step S602, and can then perform a number of processing steps. [0093] First, the user of the communication device 102 may have an account with the authentication computer 108, and the authentication computer 108 may first

23 77549200V.1 authenticate the user. For example, the authentication computer 108 can provide a one-time password to the user via a communication device 102 of the user, and the user can input the one-time password into an appropriate application in the communication device 102 or the vehicle 103. In other embodiments, the user’s communication 102 can include an application that can communicate with the authentication computer 108, and the application can request a secret (e.g., a password) or biometric from the user to authenticate the user. [0094] Second, if the user is authenticated, the authentication computer 108 can determine if the user’s account has sufficient funds in their account to pay for the anticipated charging of the vehicle 103. If the user’s account does not have sufficient funds, the authentication computer 108 can retrieve a credential (e.g., a primary account number or PAN) or token and then perform a payment authorization process using the credential or the token. The credential or token may be received from the communication device 102 or may be retrieved from a database in the authentication computer 108. The authentication computer can generate and transmit an authorization request message to an authorizing entity computer via a processing network computer (see FIG.1). The authorizing entity computer can determine if the transaction is authorized. If the transaction is authorized, the authorizing entity computer can then generate and transmit an authorization response message approving of the transaction back to the authentication computer 108. A clearing and settlement process can occur between the authorizing entity computer 114 and an acquirer computer operated by an acquirer associated with the authentication computer 108. [0095] Third, the authentication computer 108 can then generate a digital certificate (e.g., a “charging certificate”). It can include data relating to the anticipated charge, an identifier of the energy supply terminal that the user intends to use to charge the vehicle 103, and the amount that the user has prepaid for the charge. The digital certificate can also include other information such as a validity period, a certificate number, a vehicle identification number, a user identifier, etc. The details in the digital certificate can be interaction details. The digital certificate can be signed by the authentication computer 108 using an authentication computer private key. The signed digital certificate can then be encrypted using an energy supply terminal public key to form an encrypted, signed digital certificate.

24 77549200V.1 [0096] In step S606, the authentication computer 108 can transmit a message comprising the signed the encrypted, signed digital certificate to the vehicle 103 directly or via the communication device 102, which may be in electronic communication with the vehicle 103. [0097] In step S608, the user can manipulate a charge cable attached to the energy supply terminal 105 and plug it into the vehicle 103. A communication session can then be established between the vehicle 103, which may comprise a first processor and the energy supply terminal 105, which may comprise a second processor via the charging cable. The charging cable is adapted to supply energy from the energy supply terminal 105 to the vehicle 103. The first processor in the vehicle 103 and the second processor in the energy supply terminal 105 can communicate using a protocol such as ISO 15118 (e.g., ISO 15118-2 or ISO 15118- 20). The actions described below with respect to the vehicle 103 and the energy supply terminal 105 can be performed by the first processor, and the second processor, respectively. [0098] The vehicle 103 can then transmit the message comprising the encrypted, signed digital certificate to the energy supply terminal 105. In some embodiments, the vehicle 103 can optionally sign the message with a vehicle private key before transmitting the signed message to the energy supply terminal 105. By doing so, the energy supply terminal 105 can verify the signed message using a vehicle public key and can have confidence that the message was not altered during transmission from the vehicle 103. [0099] In step S610, after receiving the message comprising the encrypted, signed digital certificate from the vehicle 103, the energy supply terminal 105 can perform several operations. The energy supply terminal 105 can decrypt the encrypted signed digital certificate with an energy supply terminal private key. Once decrypted, the energy supply terminal 105 can verify the signed digital certificate using an authentication computer public key. The energy supply terminal 105 also check the validity of the digital certificate and can confirm that the data therein permits the vehicle 103 to receive energy from the energy supply terminal 105 (e.g., a VIN in the digital certificate matches the VIN of the vehicle 103). Once the digital signature has been verified, it can analyze the interaction details, and then provide

25 77549200V.1 the electricity to the vehicle 103 in accordance with the interaction details in the digital certificate. For example, if the digital certificate has an amount that was prepaid by the user, then the energy supply terminal 105 can use a conversion factor or conversion table to determine the amount of electricity to supply to the vehicle 103. [0100] In step S612, the requested amount of electricity is provided from the energy supply terminal 105 to the vehicle 103. [0101] In step S614, an indication of the value of the electricity received by the vehicle 103 can be sent from the energy supply terminal 105 to the vehicle 103. In some embodiments, if the value of the amount electricity supplied from the energy supply terminal 105 to the vehicle 103 is less than the prepaid amount in the digital certificate, then the energy supply terminal 105 can generate a new digital certificate with many of the interactions details in the received digital certification, except that the amount in the digital certificate can be updated with the amount remaining after the charge. In some cases, the amount may be zero, and this can be used to notify the authentication computer 108 that all of the prepaid amount has been used. The new digital certificate can then be signed using the energy supply terminal private key and can be encrypted using the authentication computer public key. In some embodiments, the energy supply terminal 105 does not generate a new digital certificate. Instead, the energy supply terminal 105 can simply inform the authentication computer 108 via the vehicle 103 of any unused funds, and the authentication computer 108 can credit the account of the user accordingly. The information regarding the completion of the charging of the vehicle 103 can be provided by the energy supply terminal 105 in the form of a completion message, which can include the above-noted information. [0102] In step S616, in some embodiments, the vehicle 103 can transmit a message comprising the new certificate or other data regarding the value of energy received by the vehicle 103 from the energy supply terminal 105 to the authentication computer 108. The authentication computer 108 can verify the signature of the new digital certificate, and can analyze the updated interaction details including the remaining balance. The authentication computer 108 can then update the account of the user to reflect the transaction, and could issue yet another

26 77549200V.1 digital certificate to the vehicle 103 if there is a remaining balance (as in steps S604 and S606 above). [0103] Various other encryption schemes can be used in other embodiments of the invention. For example, in other embodiments, the digital certificate that is transmitted in steps S606 and S608 can be encrypted with the public keys of different charging stations to form a group of encrypted digital certificates. When the user attempts to charge their electric vehicle at one of the charging stations, the group of encrypted digital certificates can be provided to the charging station. When the group of encrypted digital certificates is received by a particular charging station, that charging station will only be able to decrypt the encrypted digital certificate that was encrypted with that charging station’s public key. Once that digital certificate has been used, that charging station can transmit a flag to the electric vehicle to indicate that the digital certificate from the group has been used. If the user attempts to use the digital certificate at a different charging station, the flag can be transmitted by the electric vehicle with the group of digital certificates to the different charging station. The different charging station may decline to charge the electric vehicle based on the flag. Such embodiments advantageously do not require a user to reissue the digital certificate if the user does know which charging station will be used on their journey. [0104] In yet other embodiments, a single digital certificate that can be encrypted and signed such that more than one charging station can access and use the single digital certificate. Subsequent charging stations would also be able to tell that previous digital certificates were opened and used, such that a user cannot copy and present the same certificate to multiple charging stations. For example, programming in the electric vehicle can mark the single digital certificate as being used upon transmission to a charging station, such that same digital certificate cannot be used at multiple charging stations. In another example, subsequent charging stations would also be able to tell that previous digital certificates were opened and used if a previous charging station decrypted the encrypted digital certificate. [0105] Embodiments of the invention provide for a number of technical advantages. Using embodiments of the invention, access devices (e.g., energy supply terminals) need not be retrofit with specialized hardware or software for a

27 77549200V.1 user to conveniently obtain resources such as energy from energy supply terminals for users’ vehicles. Further, the access devices need not have the ability to access a remote computer to supply requested resources. Still further, contrary to conventional systems, account credentials are not passed between the user’s user device and the access device. This improves data security as such credentials are not exposed to malware, potential hackers or man-in-the-middle attacks. [0106] Any of the software components or functions described in this application may be implemented as software code to be executed by a processor using any suitable computer language such as, for example, Java, C, C++, C#, Objective-C, Swift, or scripting language such as Perl or Python using, for example, conventional or object-oriented techniques. The software code may be stored as a series of instructions or commands on a computer readable medium for storage and/or transmission, suitable media include random access memory (RAM), a read only memory (ROM), a magnetic medium such as a hard-drive or a floppy disk, or an optical medium such as a compact disk (CD) or DVD (digital versatile disk), flash memory, and the like. The computer readable medium may be any combination of such storage or transmission devices. [0107] Such programs may also be encoded and transmitted using carrier signals adapted for transmission via wired, optical, and/or wireless networks conforming to a variety of protocols, including the Internet. As such, a computer readable medium according to an embodiment of the present invention may be created using a data signal encoded with such programs. Computer readable media encoded with the program code may be packaged with a compatible device or provided separately from other devices (e.g., via Internet download). Any such computer readable medium may reside on or within a single computer product (e.g., a hard drive, a CD, or an entire computer system), and may be present on or within different computer products within a system or network. A computer system may include a monitor, printer, or other suitable display for providing any of the results mentioned herein to a user. [0108] The above description is illustrative and is not restrictive. Many variations of the invention will become apparent to those skilled in the art upon review of the disclosure. The scope of the invention should, therefore, be determined

28 77549200V.1 not with reference to the above description, but instead should be determined with reference to the pending claims along with their full scope or equivalents. For example, although the charging of electric vehicles is discussed in detail, embodiments of the invention are not limited thereto. Embodiments of the invention can include other types of access devices (e.g., vending machines) that can provide access to resources. [0109] One or more features from any embodiment may be combined with one or more features of any other embodiment without departing from the scope of the invention. [0110] As used herein, the use of "a," "an," or "the" is intended to mean "at least one," unless specifically indicated to the contrary.

29 77549200V.1

Claims

WHAT IS CLAIMED IS: 1. A method comprising: receiving, by a user device operated by a user from an authentication computer, an encrypted, signed digital certificate, the encrypted, signed digital certificate comprising a digital certificate comprising interaction details signed by an authentication computer private key, and then encrypted using an access device public key associated with an access device; and transmitting, by the user device, a message comprising the encrypted, signed digital certificate to the access device, wherein the access device decrypts the encrypted, signed digital certificate with an access device private key, verifies the signed digital certificate using an authentication computer public key, analyzes the interaction details, and then provides a resource to the user or the user device.

2. The method of claim 1, wherein the user device is an electric vehicle, the access device is a charging station, and the resource is electricity, which is provided to the electric vehicle.

3. The method of claim 2, wherein the digital certificate comprises a validity time period, an access device identifier, and a user identifier associated with the user.

4. The method of claim 2, wherein the charging station provides the electricity via a charging cable that electrically connects the electric vehicle and the charging station.

5. The method of claim 4, wherein after providing the electricity to the electric vehicle, the access device transmits a completion message to the authentication computer indicating that the electric vehicle was provided with the resource.

6. The method of claim 5, wherein the completion message comprises an amount of electricity provided to the electric vehicle, and was transmitted to the authentication computer via the electric vehicle.

30 77549200V.1

7. The method of claim 6, wherein the digital certificate is a first digital certificate that comprises a first value, and wherein the authentication computer generates a second digital certificate that comprises a second value, wherein the second value is based on the first value minus a value associated with the amount of electricity provided to the electric vehicle and transmits the second digital certificate to the electric vehicle, which stores the second digital certificate.

8. The method of claim 1, wherein the user device is a mobile phone.

9. The method of claim 1, wherein the user device stores a user device private key, and signs the message to form a signed message, and wherein the access device verifies the signed message using a user device public key.

10. The method of claim 1, wherein the access device is a vending machine.

11. The method of claim 1, wherein the resource is provided to the user.

12. The method of claim 11, wherein the method further comprises: after providing the resource to the user, the access device transmits a completion message comprising a resource value associated with the resource to the authentication computer indicating that the user was provided with the resource.

13. The method of claim 12, wherein the digital certificate is a first digital certificate that comprises a first value, and wherein the authentication computer generates a second digital certificate that comprises a second value, wherein the second value is based on the first value minus the resource value and transmits the second digital certificate to the user device, which stores the second digital certificate.

31 77549200V.1

14. The method of claim 1, wherein the access device does not have long range communication capabilities.

15. A user device comprising: a processor; and a computer readable medium, the computer readable medium comprising code executable by the processor to cause the processor to perform operations including: receiving, from an authentication computer, an encrypted, signed digital certificate, the encrypted, signed digital certificate comprising a digital certificate comprising interaction details signed by an authentication computer private key, and then encrypted using an access device public key associated with an access device, and transmitting a message comprising the encrypted, signed digital certificate to the access device, wherein the access device decrypts the encrypted signed digital certificate with an access device private key, verifies the signed digital certificate using an authentication computer public key, analyzes the interaction details, and then provides a resource to a user or the user device.

16. The user device of claim 15, wherein the user device is an electric vehicle, the resource is electricity, and the access device is an electric charging station.

17. A method comprising: receiving, by an access device from a user device, a message comprising an encrypted signed digital certificate, wherein the encrypted signed digital certificate comprises a digital certificate comprising interaction details signed by an authentication computer private key, and then encrypted using an access device public key; decrypting, by the access device, the encrypted signed digital certificate with an access device private key to obtain the signed digital certificate; verifying, by the access device, the signed digital certificate using an authentication computer public key; and analyzing, by the access device, the interaction details; and

32 77549200V.1 providing, by the access device, a resource to a user or the user device.

18. The method of claim 17, wherein the user device is an electric vehicle, the resource is electricity, and the access device is an electric charging station.

19. The method of claim 17, wherein the access device is an electric charging station does not have long range communication capabilities.

20. The method of claim 17, wherein the message is signed by a user device private key, and wherein the method further comprises: verifying, by the access device, the signed message using a user device public key.

33 77549200V.1