Invented by Ayman Hammad, Julian Hua, Robert Rutherford, Visa International Service Association
The Visa International Service Association invention works as followsThe AUTOMOBILE MOBILE INTERACTION PLATFORM APPARATUSES METHODS, AND SYSTEMS” (?AMIP?) AMIP converts cloud-based settings for automobiles and wallets into outputs that are used in transactions. In certain embodiments, the user can request to link an electronic wallet to an automobile interface. Once the user’s credentials have been authenticated, the automobile interface may request and receive from a remote server automobile-related and payment-method-related settings. The interface can then adjust its settings based on the information received.
Background for Automobile mobile-interaction Platform Apparatus, Methods and Systems
Vehicles today are autonomous units that operate independently of the digital world. There are many instances in which passengers of a vehicle can engage in financial transactions in the vehicle. For instance, they may go through a tollbooth. RFID-enabled transceivers, like E-ZPass, can be used by drivers to automate the payment of tolls. These RFID transmitters, however, are linked to the account of the user, so even if another driver drives through the toll booth in the user’s vehicle, they will be charged. The toll cannot be charged to more than two passengers at one time.
There are many other examples of inflexibility in vehicles. Some vehicles are equipped with LCD displays and microprocessors on board. Some vehicles allow the user to customize certain features, including radio stations, temperature settings, seat position and mirror positions. These programmable settings, however, are not easily transferable and stored on the vehicle. “When a person rents an automobile, he will have to adjust and configure the settings manually, just as he did for his own vehicle.
FIG. The block diagram in Figure 1a illustrates an example embodiment of the Automobile Mobile-Interaction Platform. In some implementations a user may want to connect his electronic wallet or electronic wallet-enabled devices with his smart automobile 102. In some implementations a smart vehicle may be any type of vehicle (e.g. A car, motorcycle or truck equipped with a display and capable of connecting to an electronic wallet can be considered a smart automobile. The user might want to save her automobile settings into her wallet, use her wallet for transactions on the smart interface of the automobile, or something similar. The user may want to be able to connect several electronic wallets to the interface of the smart automobile at the same time, or may wish to create a number of profiles for automobile settings. AMIP can allow a user to connect their wallet to the smart car’s internal display interface. It may also allow them to save multiple automobile settings in the wallet.
FIG. The AMIP system is shown in FIG. 1b. A vehicle interface 114 may be used by one or more users (e.g. 110, 111, and 112). The connection can be wireless (e.g. via Bluetooth, NFC etc.). or via cables (e.g., USB). The automobile interface 114 can communicate with the AMIP Server 116, and any number merchants (e.g. 117 and 118), via a network 115 such as Intent. The Automobile Interface 114 can communicate via satellite, 3G or LTE telecommunications systems. In some embodiments the Automobile Interface 114 can connect to the Network 115 using a mobile device’s wireless connectivity (e.g. via WiFi, USB or Bluetooth tethering).
FIG. The AMIP system is shown in FIG. 1c. The automobile interface 134 can be accessed by one or more users using their mobile devices, such as smart phones (e.g. 130 and 132). The automobile interface 134 can be used by more than one person at once. The automobile interface 134 and user devices can communicate via Bluetooth, NFC or Wifi. The user devices can also communicate with automobile interface 134 through wired connections such as USB, Firewire etc.
The automobile interface (134) may communicate directly or indirectly with an AMIP 135 via a network, either through the mobile device of the user (e.g. 131 or 133).” The AMIP Server 135 has access to or stores a wide range of information. The AMIP server 135 can store account information. In FIG. In FIG. The user accounts may contain information, such as the automobile profiles (e.g. 141 and 146) which can include the user’s favorite automobile settings (e.g. seat position, mirror angles, radio station presets etc.). In some implementations the user may have a profile for an automobile (e.g. the user’s primary car), a vehicle type (e.g. SUV), rental vehicles, or other types of vehicles.
A user’s account can also include one or multiple payment method profiles (e.g. 142 and 147) that are each associated with a PayPal account, credit card, or debit account. A user account can also include a wish list, shopping list, or other items (e.g. 143 and 148) and/or similar. AMIP Server 135 may transmit the user account information to the automobile interface 135 via the AMIP Server. The automobile interface 134 can adjust/change settings in accordance to the information provided by the user account, as described below. The automobile interface 134, for example, may adjust the seating positions, mirror angle, radio stations or temperature of the vehicle associated with it. According to an automobile profile (e.g. 141 and 146) received. The automobile interface may also temporarily store (e.g. until the automobile is shut down) the user’s payment method (e.g. 142 and 147) to pay for purchases made in the vehicle (e.g. at a drive through window). The automobile interface can store complete payment information, such as the 16 digits of the credit card number and the expiration date. The automobile interface 134 may store the complete payment information (e.g. the 16 digits of a credit card number, expiration date, etc.) or a reference code (e.g. an identifier given by the AMIP Server) for storing the user’s payment method. This can be used by AMIP Server in order to retrieve all the payment method details. The automobile interface 134 can also store local settings/information, such as vehicle profiles, payment methods and shopping lists.
The automobile interface 134 may, in certain embodiments, support features like the shopping and mapping feature shown in FIGS. 7a-c . In some implementations the AMIP server may store map information 161, which can be sent to the automobile interface to create a visual map with navigation instructions. The AMIP 135 can also store merchant data 162, including a merchant?s name, address and contact information. It may also include inventory data 163. The AMIP server 135 can automatically collect merchant information from the Internet in some cases, or it may offer merchants an interface to enter information (e.g. via a website). Inventory data 163 for a merchant can be provided by their computer system 170. The merchant, for example, may have an Information Server from which the AMIP 135 can query the current inventory data 163 of the merchant. In another implementation, AMIP server 135, may provide a web interface that allows merchants to enter their inventory data 163 either automatically (by the merchant system 170- or manually). The AMIP server 135, upon request, may send the map data 161, the merchant information 162, or the inventory data 163 from the AMIP to the automobile interface. In other implementations the automobile interface may obtain the inventory data of a particular merchant directly from the merchant system, when the automobile 134 interacts with that merchant. The merchant system may also communicate with a user’s mobile devices (e.g. 131 and 133).
FIGS. Data flow diagrams 2a-b illustrate an embodiment of connecting an electronic wallet with an automobile interface. In some implementations the user 202 can walk 206 near her smart automobile, 210, with an electronic device, and the electronic device will communicate with the automobile. In other implementations the user 202 can physically connect her electronic devices 204 with her smart automobile 210 by using a USB cable. The electronic device may be asked to send an automobile login message 208 from the wallet to the smart vehicle 210. The prompt can be triggered in some cases by an NFC or RFID tag, Bluetooth, GPS location of the device and automobile, or the like. In some implementations the wallet login message 208 can be an XML encoded message that may look like the following:
POST /wallet_login_message.php HTTP/1.1\nHost: www.AMIPproccess.com\nContent-Type: Application/XML\nContent-Length: 788\n
In certain implementations, an automobile 210 can transmit to the AMIP server, a wallet log-in request 212 generated from the wallet log-in message 208. In other implementations the electronic device 204 may send a wallet request directly to the AMIP Server 214. The AMIP server may authenticate the request 216 by executing a login query to the AMIP database 210 and retrieve automobile preference profiles (e.g. which can include the user’s preferences for payment, automobile settings, etc.). The wallet account 220a corresponds to the AMIP server 214’s configuration for use with an automobile interface. In certain implementations, AMIP database may send a login 222 result to the AMIP Server 214. The login result may include a reference to a wallet ID, automobile preference profiles and/or similar information. AMIP server may send the retrieved information to the smart vehicle 210 or to the electronic device 204 via a user automobile preferences message 224. The user automobile preference messages 224 can be encoded in XML and take a similar form to this:
POST /auto_pref_message.php HTTP/1.1\nHost: www.AMIPproccess.com\nContent-Type: Application/XML\nContent-Length: 788\n
The smart car can then store the preferences (e.g., temperature, mirrors, radios, playlists, etc.). The computer system of the vehicle 226 can be used to store wallet data and/or other information.
In some implementations, a user can update their automobile preferences, wallet information and/or other similar items via the interface of the automobile 228. The automobile can update its settings based on the inputs of the user 230 and send updated information via an automobile preferences update message 232 to the AMIP server. In some implementations, an automobile preference message 232 can be encoded in XML and take a similar form to:
POST /auto_pref_message.php HTTP/1.1\nHost: www.AMIPproccess.com\nContent-Type: Application/XML\nContent-Length: 788\n
In some implementations the server may update the preferences via a database query to AMIP. In some implementations the automobile can also receive wallet input from the user (such as transactions requests, adding payment methods, adding payment devices to already-connected wallets, and/or similar input) 235. It may then process 236 this input in the automobile interface or push the processing to the user?s default electronic wallet enabled mobile device and/or another device external to the automobile.
In some implementations, users may want to connect their electronic wallets with the automobile interface. Referring to FIG. In some implementations, users 252a and 252b may want to connect their electronic wallets with the automobile 258, as shown in FIG. User 252a can use her electronic device, 252c, while user 252b may use his, 252d, to send wallet login messages, respectively 256a and 256b, to automobile interface 258. In some implementations the wallet login messages may look similar to wallet log-in message 208 of FIG. 2a . In some implementations the automobile interface can process each user’s login (see FIG. The AMIP database can be accessed to retrieve wallet information for each user. The wallet information that is retrieved from AMIP may include wish lists, shopping lists, or other similar lists. The interface for the automobile may import 262 wallet information into its own system.
In some embodiments, an automobile interface can provide users (e.g. 252a and 252b) with assistance in locating products/services listed on their shopping list, and/or targeted advertisements and suggestions from merchants nearby. The automobile interface, for example, may create a dynamic map that shows the 258 location of the automobile and its surroundings along with indicators (e.g. graphical icons or audible notifications). Nearby merchants may be of interest to users. The automobile interface, for example, may use the location of nearby merchants in order to determine how close the automobile is to the merchant. It can then overlay icons on the map that represent the location. In one implementation, a user’s shopping (or merchant) list is displayed. In one implementation, the user’s shopping list (or merchant list, etc.) may include product or merchant information. The automobile interface can use this information to find nearby merchants that fit the description. If the shopping list contains a name of a merchant (e.g. Target), then the automobile interface can search for merchants nearby (e.g. within a 5-mile radius from the automobile’s current location) that match the name. If the shopping list contains a specific category of merchants (e.g. supermarket), then the automobile interface can refer to a repository of known retailers included in that particular category (e.g. by performing a query on a database for merchants within the “supermarket” category). category). The automobile interface can use a look-up table if the user’s list includes only a name or type of product/service to determine general merchant types, or merchants who may provide the product/service. “A person with ordinary knowledge of the art would know that the above process of determining merchants may be performed remotely by an AMIP server 214.
In some implementations, an automobile interface can determine the location and availability of products from the user’s shopping or wish list by sending an inventory request 266 via the AMIP server to determine which merchants are located near the automobile. The inventory request 266 can include a list containing products or merchants that are of interest to the users. The inventory request can also include information about the 258 geographical location of the automobile, such as the 258 GPS unit. The AMIP server can search its database to find merchants that are within a specific distance of the automobile’s location (258), and that have a merchant description that matches (e.g. merchant name such as Target or merchant type such as supermarket), or offer a product/service listed (e.g. milk).
In some implementations the AMIP server will query the servers of merchants associated with identified products to determine their availability, price and other relevant information. If the user wants to know about the price, availability and brand of milk available, the AMIP Server may contact each supermarket in the area.
The AMIP server can send a store-injection response 268 to the automobile (see FIG. The AMIP server will send a store injection response 268 (see FIG. 9c-d) back to your automobile, which will identify the merchants that have been located. Merchants on the user?s list of preferred merchants, or merchants who sell an item from the user?s wish-list and/or shopping list), their product inventories and other relevant information (e.g. prices, store hours etc.). In some implementations the store injection response may look similar to the user’s automobile preference message (see FIG. 2a may include information about each merchant along a specific route. The interface of the automobile may analyze the store injection responses 268 to select merchants. The selection can be made based on the user’s preferences, the distance between the merchant and automobile, the product price, reviews from users, or whether the merchant sponsors AMIP. The AMIP server may perform the selection process. In this case, the automobile interface will display all merchants included in the AMIP store injection response 268, which is provided by the AMIP Server 214. The automobile interface can update the map to show the location of the selected merchants (e.g. The merchant may be selected because it has a particular item on a user’s wish list or shopping list, is listed in the user?s preferred merchant list and/or is similar.Click here to view the patent on Google Patents.