AN APPLIANCE

BACKGROUND OF THE INVENTION

1 . Field of the Invention

[0001] Disclosed embodiments relate generally to a system and method for providing an appliance with an original personal account number, and, in one particular embodiment, to a system and method for authorizing and provisioning a token to an appliance for conducting transactions.

2. Technical Considerations

[0002] Technological developments in the Internet of Things have enabled smart appliances to transact with merchants over a network. However, currently such smart appliances must make use of the owner’s financial instrument, such as a credit card, for transacting with merchants. In other words, the owner makes the payment through digital credentials provisioned on the appliances, which are mapped to financial instruments issued to the owner.

[0003] Currently, smart appliances enabled to transact with merchants have a token, corresponding to a personal account number (PAN) issued to the device owner, provisioned on the device, which the device forwards to acquirers and, in turn, to a transaction service provider. At the transaction service provider, the token and a PAN are mapped in a token vault to authorize or decline the transaction.

[0004] However, the current model poses a number of major disadvantages. First, a user needs to provision a token associated with the user’s own PAN to the appliance, thereby exposing the owner’s financial information, potentially across multiple appliances and to numerous merchants or acquirers. Second, with the rise in the sharing economy model, a single person no longer uses one appliance continuously, or exclusively, for long periods, and the current model of providing an owner’s PAN on the appliance is not suitable. Moreover, the current model is not feasible for appliances that do not have a single“owner,” e.g., rental cars. Further, improvements in technology and business models have given rise to appliances that are intelligent and have decision-making ability. However, an appliance owner may not wish to allow the appliance to make purchases autonomously, which has the potential to disseminate the owner’s financial information widely. [0005] Accordingly, there is a need in the art for a method and system for enabling commerce from appliances without relying on financial instruments issued to the appliance owner. Such a solution is possible when appliances are issued on their own financial instruments, e.g., credit/debit cards, which can be tokenized and associated with an owner’s financial information, and then used to conduct transactions.

SUMMARY OF THE INVENTION

[0006] According to a non-limiting embodiment or aspect, provided is a computer- implemented method for provisioning a token to an appliance, including the steps of registering, with at least one processor, an original account identifier to at least one appliance, wherein the original account identifier is not associated with any user; associating, with at least one processor, a device token to the original account identifier, wherein the device token is stored by the at least one appliance; associating, with at least one processor, a user account identifier for a user to at least one of the device token and the original account identifier registered to the at least one appliance; receiving, from the at least one appliance, a transaction request for a transaction, the transaction request comprising the device token; identifying, with at least one processor, the user account identifier based on the device token; determining, with at least one processor, that the transaction is authorized based at least partially on the user account identifier and the original account identifier registered to the at least one appliance; and in response to determining that the transaction is authorized, processing the transaction.

[0007] According to another non-limiting embodiment or aspect, provided herein is a system for provisioning a token to an appliance, including at least one processor programmed and/or configured to register an original account identifier to at least one appliance, wherein the original account identifier is not associated with any user associated with a device token to the original account identifier, wherein the device token is stored by the at least one appliance; associate a user account identifier for a user to at least one of the device token and the original account identifier registered to the at least one appliance; receive, from the at least one appliance, a transaction request for a transaction, the transaction request comprising the device token; identify the user account identifier based on the device token; determine that the transaction is authorized based at least partially on the user account identifier and the original account identifier registered to the at least one appliance; and in response to determining that the transaction is authorized, process the transaction. [0008] According to another non-limiting embodiment or aspect, provided herein is a computer-implemented method for interacting with at least one appliance to process a transaction, including the steps of registering, with at least one processor, an original account identifier to at least one appliance, wherein the original account identifier is not associated with any user; receiving, from the at least one appliance, a transaction request comprising at least one of the original account identifier and a token uniquely identifying the original account identifier; generating, with at least one processor, an authorization request comprising the original account identifier; and communicating the authorization request to an issuer system associated with the original account identifier.

[0009] According to another non-limiting embodiment or aspect, provided herein is an appliance for conducting transactions without a user-specific account, including a memory internal to the appliance, the memory including a device account identifier not associated with any user and a device token uniquely associated with the device account identifier; a communication device; and a processor in communication with the memory and the communication device, the processor programmed or configured to generate a transaction request comprising at least one of the device account identifier and the device token.

[0010] Further embodiments or aspects are set forth in the following numbered clauses:

[0011 ] Clause 1 : A computer-implemented method for authorizing and provisioning a token to an appliance, comprising: registering, with at least one processor, an original account identifier to at least one appliance, wherein the original account identifier is not associated with any user; associating, with at least one processor, a device token to the original account identifier, wherein the device token is stored by the at least one appliance; associating, with at least one processor, a user account identifier for a user to at least one of the device token and the original account identifier registered to the at least one appliance; receiving, from the at least one appliance, a transaction request for a transaction, the transaction request comprising the device token; identifying, with at least one processor, the user account identifier based on the device token; determining, with at least one processor, that the transaction is authorized based at least partially on the user account identifier and the original account identifier registered to the at least one appliance; and in response to determining that the transaction is authorized, processing the transaction. [0012] Clause 2: The computer-implemented method of clause 1 , wherein determining that the transaction is authorized comprises: communicating an authorization request to an issuer system associated with the original account identifier registered to the at least one appliance; communicating an authorization request to an issuer system associated with the user account identifier; and receiving at least one authorization response message from at least one of the issuer system associated with the user account identifier and the issuer system associated with the original account identifier registered to the at least one appliance.

[0013] Clause 3: The computer-implemented method of clause 1 or clause 2, wherein registering the original account identifier to the at least one appliance comprises associating at least one device identifier unique to the at least one appliance with the original account identifier.

[0014] Clause 4: The computer-implemented method of any of clauses 1 -3, further comprising: aggregating transaction values from the transaction and at least one other transaction initiated by the at least one appliance within a time period to calculate an aggregated transaction value; and generating an authorization request to deduct the aggregated transaction value from a user account corresponding to the user account identifier.

[0015] Clause 5: The computer-implemented method of any of clauses 1 -4, further comprising generating a device profile for the at least one appliance based at least partially on at least one of the following appliance parameters: model, manufacturer, transaction history, age, service history, or any combination thereof.

[0016] Clause 6: The computer-implemented method of any of clauses 1 -5, further comprising generating a credit/debit limit value for the at least one appliance based at least partially on the device profile.

[0017] Clause 7: The computer-implemented method of any of clauses 1 -6, wherein processing the transaction comprises: determining that a transaction value associated with the transaction satisfies the credit limit value; in response to determining that the transaction value does not satisfy the credit limit value, communicating a rejection of the transaction to the at least one appliance or to an acquirer system; receiving, from the at least one appliance and/or at least one other appliance, a new transaction request for the transaction, the new transaction request comprising the device token and at least one other device token associated with the at least one other appliance; and in response to determining that the new transaction is authorized, processing the new transaction by charging a first portion of the transaction value to an account corresponding to the device token and a second portion of the transaction value to an account corresponding to the at least one other device token.

[0018] Clause 8: The computer-implemented method of any of clauses 1 -7, wherein registering the original account identifier to the at least one appliance comprises generating the credit limit value.

[0019] Clause 9: The computer-implemented method of any of clauses 1 -8, further comprising altering, with at least one processor and based at least partially on the device profile, the credit limit value.

[0020] Clause 10: The computer-implemented method of any of clauses 1 -9, further comprising associating a merchant domain restriction with the device token based at least partially on the at least one device profile.

[0021] Clause 1 1 : The computer-implemented method of any of clauses 1 -10, wherein processing the transaction comprises: determining, based on the device token and the merchant domain restriction, that a transaction is authorized; and in response to determining that the transaction is authorized, processing the transaction.

[0022] Clause 12: A system for authorizing and provisioning a token to an appliance, comprising at least one processor programmed and/or configured to: register an original account identifier to at least one appliance, wherein the original account identifier is not associated with any user; associate a device token to the original account identifier, wherein the device token is stored by the at least one appliance; associate a user account identifier for a user to at least one of the device token and the original account identifier registered to the at least one appliance; receive, from the at least one appliance, a transaction request for a transaction, the transaction request comprising the device token; identify the user account identifier based on the device token; determine that the transaction is authorized based at least partially on the user account identifier and the original account identifier registered to the at least one appliance; and in response to determining that the transaction is authorized, process the transaction.

[0023] Clause 13: The system of clause 12, wherein the at least one processor is programmed and/or configured to determine that the transaction is authorized by: communicating an authorization request to an issuer system associated with the original account identifier registered to the at least one appliance; communicating an authorization request to an issuer system associated with the user account identifier; and receiving at least one authorization response message from at least one of the issuer system associated with the user account identifier and the issuer system associated with the original account identifier registered to the at least one appliance.

[0024] Clause 14: The system of clause 12 or clause 13, wherein the at least one processor is programmed and/or configured to register the original account identifier to the at least one appliance by associating at least one device identifier unique to the at least one appliance with the original account identifier.

[0025] Clause 15: The system of any of clauses 12-14, wherein the at least one processor is further programmed and/or configured to: aggregate transaction values from the transaction and at least one other transaction initiated by the at least one appliance within a time period to calculate an aggregated transaction value; and generate an authorization request to deduct the aggregated transaction value from a user account corresponding to the user account identifier.

[0026] Clause 16: The system of any of clauses 12-15, wherein the at least one processor is further programmed and/or configured to generate a device profile for the at least one appliance based at least partially on at least one of the following appliance parameters: model, manufacturer, transaction history, age, service history, or any combination thereof.

[0027] Clause 17: The system of any of clauses 12-16, wherein the at least one processor is further programmed and/or configured to generate a credit limit value for the at least one appliance based at least partially on the device profile.

[0028] Clause 18: The system of any of clauses 12-17, wherein the at least one processor is programmed and/or configured to process the transaction by: determining that a transaction value associated with the transaction satisfies the credit limit value; in response to determining that the transaction value does not satisfy the credit limit value, communicating a rejection of the transaction to the at least one appliance; receiving, from the at least one appliance and/or at least one other appliance, a new transaction request for the transaction, the new transaction request comprising the device token and at least one other device token associated with the at least one other appliance; and in response to determining that the new transaction is authorized, processing the new transaction by charging a first portion of the transaction value to an account corresponding to the device token and a second portion of the transaction value to an account corresponding to the at least one other device token. [0029] Clause 19: The system of any of clauses 12-18, wherein registering the original account identifier to the at least one appliance comprises generating a credit limit value.

[0030] Clause 20: The system of any of clauses 12-19, wherein the at least one processor is further programmed and/or configured to alter, based at least partially on the device profile, the credit limit value.

[0031] Clause 21 : The system of any of clauses 12-20, wherein the at least one processor is programmed and/or configured to alter the credit limit value when the user account identifier is associated to the device token or the original account identifier is registered to the at least one appliance.

[0032] Clause 22: The system of any of clauses 12-21 , wherein the at least one processor is programmed or configured to associate a merchant domain restriction with the device token based at least partially on the device profile.

[0033] Clause 23: The system of any of clauses 12-22, wherein the at least one processor is programmed and/or configured to process the transaction by: determining, based on the device token and the associated merchant domain restriction, whether a transaction is authorized; and in response to determining that the transaction is not authorized, communicating a rejection of the transaction to the at least one appliance; or in response to determining that the transaction is authorized, processing the transaction.

[0034] Clause 24: A computer-implemented method for authorizing an appliance to process a transaction, comprising: registering, with at least one processor, an original account identifier to at least one appliance, wherein the original account identifier is not associated with any user; receiving, from the at least one appliance, a transaction request comprising at least one of the original account identifier and a token uniquely identifying the original account identifier; generating, with at least one processor, an authorization request comprising the original account identifier; and communicating the authorization request to an issuer system associated with the original account identifier.

[0035] Clause 25: The computer-implemented method of clause 24, further comprising generating a device profile for the at least one appliance based at least partially on at least one of the following appliance parameters: model, manufacturer, transaction history, age, service history, or any combination thereof. [0036] Clause 26: The computer-implemented method of clause 24 or clause 25, further comprising generating a credit limit value for the at least one appliance based at least partially on the device profile.

[0037] Clause 27: The computer-implemented method of any of clauses 24-26, further comprising: determining that a transaction value associated with the transaction request satisfies the credit limit value; in response to determining that the transaction value does not satisfy the credit limit value, communicate a rejection of the transaction to the at least one appliance; receiving, from the at least one appliance and/or at least one other appliance, a new transaction request for the transaction, the new transaction request comprising the device token and at least one other device token associated with the at least one other appliance; and in response to determining that the new transaction is authorized, processing the new transaction by charging a first portion of the transaction value to an account corresponding to the device token and a second portion of the transaction value to an account corresponding to the at least one other device token.

[0038] Clause 28: The computer-implemented method of any of clauses 24-27, wherein the credit limit value is generated during the step of registering the original account identifier to the least one appliance.

[0039] Clause 29: The computer-implemented method of any of clauses 24-28, further comprising altering, with at least one processor and based at least partially on the at least one device profile, the credit limit value.

[0040] Clause 30: The computer-implemented method of any of clauses 24-29, wherein the credit limit value is altered during the step of associating the user account identifier to the device token or the original account identifier registered to the at least one appliance.

[0041] Clause 31 : The computer-implemented method of any of clauses 24-30, further comprising associating a merchant domain restriction with the device token based at least partially on the device profile.

[0042] Clause 32: The computer-implemented method of any of clauses 24-31 , further comprising: determining, based on the device token and the associated merchant domain restriction, whether a transaction is authorized; and in response to determining that the transaction is not authorized, communicating a rejection of the transaction to the at least one appliance; or in response to determining that the transaction is authorized, generating, with at least one processor, an authorization request comprising the original account identifier; and communicating the authorization request to an issuer system associated with the original account identifier.

[0043] Clause 33: An appliance for conducting transactions without a user-specific account, comprising: a memory internal to the appliance, the memory comprising a device account identifier not associated with any user and a device token uniquely associated with the device account identifier; a communication device; and a processor in communication with the memory and the communication device, the processor programmed or configured to generate a transaction request comprising at least one of the device account identifier and the device token.

[0044] Clause 34: The appliance of clause 33, wherein the processor is further programmed or configured to: communicate the transaction request to a transaction processing system; receive a rejection of the transaction request from the transaction processing system; in response to receiving the rejection of the transaction request, generate a new transaction request for the transaction, the new transaction request comprising: at least one of the device account identifier and the device token; and at least one other device account identifier and/or device token associated with at least one other appliance; and communicate the new transaction request to the transaction processing system.

[0045] These and other features and characteristics of the present invention, as well as the methods of operation and functions of the related elements of structures and the combination of parts and economies of manufacture, will become more apparent upon consideration of the following description and the appended claims with reference to the accompanying drawings, all of which form a part of this specification, wherein like reference numerals designate corresponding parts in the various figures. It is to be expressly understood, however, that the drawings are for the purpose of illustration and description only and are not intended as a definition of the limits of the invention. As used in the specification and the claims, the singular form of “a,”“an,” and“the” includes plural referents unless the context clearly dictates otherwise.

BRIEF DESCRIPTION OF THE DRAWINGS

[0046] Additional advantages and details of the invention are explained in greater detail below with reference to the exemplary embodiments and aspects that are illustrated in the accompanying schematic figures, in which: [0047] FIG. 1 is a schematic diagram of one embodiment or aspect of a method and system for authorizing and provisioning a token to an appliance;

[0048] FIG. 2 is a process diagram of one embodiment or aspect of a method for authorizing and provisioning a token to an appliance;

[0049] FIG. 3 is a schematic diagram of one embodiment or aspect of a method and system for authorizing and provisioning a token to an appliance to process a transaction;

[0050] FIG. 4 is a process diagram of one embodiment or aspect of a method for authorizing and provisioning a token to an appliance to process a transaction; and

[0051] FIG. 5 is a process diagram of one embodiment or aspect of a method for authorizing and provisioning a token to an appliance to process a transaction.

DETAILED DESCRIPTION OF THE INVENTION

[0052] For purposes of the description hereinafter, the terms “upper,” “lower,” “right,” “left,” “vertical,” “horizontal,” “top,” “bottom,” “lateral,” “longitudinal,” and derivatives thereof shall relate to the invention as it is oriented in the drawing figures. However, it is to be understood that the invention may assume various alternative variations and step sequences, except where expressly specified to the contrary. It is also to be understood that the specific devices and the method illustrated in the attached drawings, and described in the following specification, are simply exemplary embodiments of the invention. Hence, specific dimensions and other physical characteristics related to the embodiments disclosed herein are not to be considered as limiting. Also, it should be understood that any numerical range recited herein is intended to include all sub-ranges subsumed therein. For example, a range of “1 to 10” is intended to include all sub-ranges between (and including) the recited minimum value of 1 and the recited maximum value of 10, that is, having a minimum value equal to or greater than 1 and a maximum value of equal to or less than 10.

[0053] As used herein, the term“appliance” refers to a consumer device including a processor, memory, and communication device configured to communicate with one or more networks. For example, and without limitation, an appliance may include a network-connected automobile, refrigerator, television, washer/dryer machine, coffee maker, thermostat, and/or the like.

[0054] As used herein, the terms“communication” and“communicate” refer to the receipt or transfer of one or more signals, messages, commands, or other type of data. For one unit (e.g., any device, system, or component thereof) to be in communication with another unit means that the one unit is able to directly or indirectly receive data from and/or transmit data to the other unit. This may refer to a direct or indirect connection that is wired and/or wireless in nature. Additionally, two units may be in communication with each other even though the data transmitted may be modified, processed, relayed, and/or routed between the first and second unit. For example, a first unit may be in communication with a second unit even though the first unit passively receives data and does not actively transmit data to the second unit. As another example, a first unit may be in communication with a second unit if an intermediary unit processes data from one unit and transmits processed data to the second unit. It will be appreciated that numerous other arrangements are possible.

[0055] As used herein, the term“issuer institution” may refer to one or more entities, such as a bank, that provides accounts to customers for conducting payment transactions, such as initiating credit and/or debit payments. For example, an issuer institution may provide an account identifier, such as a personal account number (PAN), to a customer or appliance that uniquely identifies one or more accounts associated with that customer or appliance. The account identifier may be embodied on a physical financial instrument, such as a payment card, and/or may be electronic and used for electronic payments. As used herein, the term“account identifier” may include one or more PANs, tokens, or other identifiers associated with a customer account. An account identifier may be directly or indirectly associated with an issuer institution, such that an account identifier may be a token that maps to a PAN or other type of account identifier. The term“token” may refer to an identifier that is used as a substitute or replacement identifier for an original account identifier, such as a PAN. Account identifiers may be alphanumeric or any combination of characters and/or symbols. Tokens may be associated with a PAN or other original account identifiers in one or more databases such that they can be used to conduct a transaction without directly using the original account identifier. In some examples, an original account identifier, such as a PAN, may be associated with a plurality of tokens for different individuals or purposes. An issuer institution may be associated with a bank identification number (BIN) or other unique identifier that uniquely identifies it among other issuer institutions. The terms “issuer institution,” “issuer bank,” and “issuer system” may also refer to one or more computer systems operated by or on behalf of an issuer institution, such as a server computer executing one or more software applications. For example, an issuer system may include one or more authorization servers for authorizing a payment transaction.

[0056] As used herein, the term“merchant” refers to any individual or entity that provides goods and/or services, or access to goods and/or services, to customers based on a transaction, such as a payment transaction. Merchants may include, but are not limited to, restaurants, food trucks, clubs, gymnasiums, retail stores, professional services providers (e.g., dentists, doctors, plumbers, etc.), parks, museums, attractions, sporting venues, and/or the like. It will be appreciated that numerous other types of merchants are within the scope of this invention.

[0057] As used herein, the term“acquirer institution” may refer to an entity licensed by the transaction service provider and approved by the transaction service provider to originate transactions using a portable financial device of the transaction service provider. The transactions may include original credit transactions (OCTs) and account funding transactions (AFTs). The acquirer institution may be authorized by the transaction service provider to originate transactions using a portable financial device of the transaction service provider. The acquirer institution may contract with a payment gateway to enable the facilitators to sponsor merchants. An acquirer institution may be a financial institution, such as a bank. The terms “acquirer institution,”“acquirer bank,” and“acquirer system” may also refer to one or more computer systems operated by or on behalf of an acquirer institution, such as a server computer executing one or more software applications.

[0058] As used herein, the term“financial device” may refer to a portable (e.g., physical) payment card, a gift card, a smartcard, a smart media, a payroll card, a healthcare card, a wrist band, a machine-readable medium containing account information, a keychain device, a supermarket discount card, a cellular phone, a mobile device, a personal digital assistant (PDA), a pager, a security card, a computer, an access card, a wireless terminal, or a transponder. The financial device may include volatile or non-volatile memory to store information, such as the account number or a name of the account holder. The term“financial device” may also refer to any unique identifier, physical or digital, associated with a financial transaction account that can be used to complete a transaction between a user of the financial device and another party, such as a merchant. For example, a financial device may be a financial transaction account number and confirmation code that may be entered into an online store payment interface. It will be appreciated that many other configurations and embodiments are possible.

[0059] As used herein, the term“merchant system” may refer to one or more server computers, point-of-sale devices, online interfaces, third-party hosted services, and/or the like that are used to complete transactions with one or more financial devices. The term merchant system may also refer to one or more server computers, processors, online interfaces, third-party hosted services, and/or the like that are used to transmit and/or receive communications with issuer institutions, transaction service providers, transaction processing servers, financial device holders, and/or the like.

[0060] As used herein, the term“transaction service provider” may refer to an entity that collects authorization requests from merchants and provides guarantees of payment, in some cases through an agreement between the transaction service provider and an issuer institution. As used herein, the term“recurring transactions” may refer to any series of repeated or patterned transactions between a financial device and a merchant. Recurring transactions are often regular and of a similar amount but do not need to be identical in cost or identical in purchased goods/services to be recurring.

[0061] As used herein, the term“transaction processing system” may refer to one or more computer systems operated by or on behalf of a transaction service provider, such as a transaction processing server executing one or more software applications. A transaction processing server may include one or more processors and, in some non-limiting embodiments, may be operated by or on behalf of a transaction service provider.

[0062] As used herein, the term“mobile device” may refer to one or more portable electronic devices that are configured to communicate with one or more networks. As an example, a mobile device may include a cellular phone (e.g., a smartphone or standard cellular phone), a portable computer, a wearable device (e.g., watches, glasses, lenses, clothing, and/or the like), a PDA, and/or other like devices.

[0063] Non-limiting embodiments of the invention provide for an improved system and method for conducting transactions with appliances by issuing an original account identifier to an appliance, provisioning a token to the appliance, and authorizing the appliance for processing a transaction request. By issuing an original account identifier to an appliance and provisioning a token corresponding to the account identifier to the appliance, non-limiting embodiments allow for such appliances to be provided to users, such as purchasers or lessees, without risking exposure of the users’ personal financial information that may be otherwise inputted into or associated with the appliance. Moreover, non-limiting embodiments provide for an improved appliance with memory including a device token and/or a device PAN that can be used to initiate and conduct transactions with various merchant systems. Such improved appliances provide for a more secure and efficient transaction flow, as well as other advantages described herein.

[0064] Provided herein are a system and method for provisioning a token to an appliance. Fig. 1 illustrates a system to provision a token to an appliance according to one non-limiting embodiment or aspect. In Fig. 1 , the system (1000) includes an appliance (102), an issuer system (1 14), and a transaction processing system (1 10). The components may communicate through a network (101 ). During the manufacture of the appliance, or thereafter, an original device personal account number (DPAN) (104) is registered to the appliance (102) by issuer system (1 14) and/or transaction processing system (1 10). The DPAN (104) is an original PAN that is not associated with a user or appliance owner at the time of issuance, such that the DPAN (104) is not issued to a human being, even though in some non-limiting embodiments the DPAN

(104) may be subsequently linked to a user PAN. In some non-limiting embodiments or aspects, both the issuer system (1 14) and the transaction processing system (1 10) collaborate to issue the DPAN (104) to the appliance. In some non-limiting embodiments or aspects, registering the original account identifier includes associating a unique device identifier specific to the appliance with the DPAN (104). The unique device identifier specific to the appliance may be encoded into memory

(105) of the appliance (102).

[0065] With further reference to Fig- 1 , in non-limiting embodiments or aspects, the appliance (102) may be provisioned with the DPAN (104) for making transactions. However, in other non-limiting embodiments, the appliance may be provisioned with a device token (D-roken) (106) instead of or in addition to the DPAN (104). For example, a D-r _oken (106) may be provisioned on the appliance (102) so as to not expose the DPAN (104) to any potential security vulnerabilities. It will be appreciated that, although Fig. 1 illustrates both the D-r _oken (106) and DPAN (104), non-limiting embodiments may include just the D-roken (106) or just the DPAN (104).

[0066] Still referring to Fig. 1 , in non-limiting embodiments in which the appliance (102) is provisioned with the D-roken (106), the transaction processing system (1 10) tokenizes the DPAN (104) by generating the D-roken (106) and associating the D-roken (106) with the DPAN (104). The associated DPAN (104) and D-roken (106) are stored in a token vault (1 18) which, in non-limiting embodiments, includes a secure database. At this stage, the DPAN (104) and D-roken (106) are not associated with any user or owner financial information, such as a user PAN (e.g., a Master PAN (MPAN)). A non-limiting embodiment or aspect of a token vault architecture is illustrated below:

The transaction processing system (1 10) communicates D-r _oken (106) to the appliance (102) for storage thereon. At this stage, the D-r _oken (106) resides on the appliance (102) in an inactive state.

[0067] Appliance (102) may then be purchased, rented, or leased by a user. With further reference to Fig. 1 , also illustrated is a user device (103). A user device (103) may be any type of client device that allows a user to interact with the appliance (102) and/or transaction processing system (1 10), for example, and without limitation, a smartphone, tablet, a computing device, a remote control, or the like. However, any action described as taking place through or using user device (103) should be understood to also be possible by direct interaction of the user with the appliance (102) itself, for example, through a user interface and input device disposed on appliance (102). The user device (103) may be used to activate D-r _oken (106) stored in appliance (102).

[0068] In non-limiting embodiments or aspects, once the DPAN (104) and/or D-roken (106) are provisioned on the appliance (102), the appliance (102) may be used to initiate transaction requests using the DPAN (104) and/or D-roken (106). However, in some non-limiting embodiments, the DPAN (104) and/or D-roken (106) may need to be activated before being used. As an example, the DPAN (104) and/or D-roken (106) may be activated by a user associating his or her MPAN with the DPAN (104) and/or D-roken (106), such that the user is ultimately responsible for the transactions initiated using the DPAN (104) and/or D-roken (106) while activated for that particular user.

[0069] In non-limiting embodiments or aspects, D-r _oken (106) is activated upon initial use of appliance (102) or upon a user selection to undergo an activation process. The user may be prompted to, through appliance (102) or user device (103), communicate ownership or possession of appliance (102) to transaction processing system (1 10). Transaction processing system (1 10), in response to an activation request initiated by the owner, then associates an account identifier associated with a portable financial device issued to the user (e.g., a credit or debit card), such as MPAN, with the appliance (102). In some non-limiting embodiments or aspects, an activation request to associate the MPAN with DPAN (104) and/or D-r _oken (106) is communicated through appliance (102) to transaction processing system (1 10). In some non-limiting embodiments or aspects, the user or appliance (102) provides identifying information for the appliance (102) to allow user to, through user device (103), communicate the association request to the transaction processing system (1 10). Identifying information may be any type of information that identifies the appliance (102), such as a unique device identifier. A unique device identifier may include, for example and without limitation, a serial number, a randomly generated alphanumeric identifier, a unique appliance attribute, and/or the like. In non-limiting embodiments or aspects, the identifying information may be provided as machine-readable indicia, such as a barcode (e.g., a two-dimensional barcode, a three-dimensional barcode, a QR code, or the like), an RFID transponder, or the like that user device (103) can read and transmit to transaction processing system (1 10).

[0070] The user may also provide the MPAN through the user device (103), appliance (102), point-of-sale (POS) system, or through another device. As an example, a user may scan his or her portable financial device through a mobile application on the user device (103), which analyzes an image of the portable financial device and determines the MPAN and other information from the image, such as expiration date and security code. In other examples, the user may manually input the MPAN and other information. It will be appreciated that the user may provide the MPAN in any number of ways and, in some non-limiting examples, the transaction processing system (1 10) and/or issuer system (1 14) may already have the MPAN and can identify it based on an identification of the user. In other non-limiting embodiments, the user may present his or her portable financial device at a POS system at the time of purchasing or leasing the appliance (102) such that the MPAN is communicated to the transaction processing system (1 10) from the POS system. In still further examples, the user may provide the MPAN by logging into an existing bank account or electronic wallet. It will be appreciated that the MPAN may be provided in various other ways.

[0071] In response to transaction processing system (1 10) receiving an activation request initiated by the user, through appliance (102) or user device (103) as examples, the transaction processing system (1 10) may retrieve, identify, or receive the MPAN as explained above. Transaction processing system (1 10), in response to the activation request and/or obtaining the MPAN, then associates the MPAN with the DPAN (1 04) and/or D-roken (1 06) in the token vault (1 1 8):

[0072] In some non-limiting embodiments or aspects, a device profile may be generated for appliance (102). The device profile may be based on, for example and without limitation, one or more appliance parameters such as a unique identifier (e.g., a device identifier), an appliance type, an appliance model, an appliance manufacturer, an appliance transaction history, an appliance age, an appliance use time, an appliance service history, and/or combinations thereof. The device profile may be associated with the D-roken (104) and/or DPAN (106) in a database, such as but not limited to the token vault (1 18). The device profile may be generated by the issuer system (1 14), the transaction processing system (1 10), the appliance itself (102), or any other device or system. In some non-limiting examples, the device profile may be a set of appliance parameters, a score or rating generated from a set of appliance parameters, or a predefined profile category.

[0073] In some non-limiting embodiments or aspects, domain restrictions may be generated for the appliance (102). In non-limiting embodiments or aspects, the domain restrictions may be based at least partially on the device profile. Non-limiting examples of domain restrictions include credit/debit limit values, transaction limit values, restrictions on the number of transactions, duration (lifespan) of the D-roken, and/or merchant domain restrictions, such as merchant category restrictions or merchant location restrictions, and merchant loyalty or reward point program restrictions. As an example, in non-limiting embodiments, an appliance provisioned with a D-roken and/or DPAN may be restricted to making purchases for items and/or content usable by the appliance (e.g., streaming media for televisions, fuel for automobiles, and/or the like).

[0074] In non-limiting embodiments or aspects, the domain restriction may be modified at varying times of the appliance’s lifespan. For example, and without limitation, an appliance may be restricted to a certain credit/debit limit value prior to the D-roken (106) and/or DPAN (104) being associated with an MPAN. In non-limiting embodiments, the credit/debit limit value may be increased with increasing duration of ownership and/or association with an MPAN. In other non-limiting embodiments or aspects, an appliance user may manually request modification of the credit/debit limit value for an appliance.

[0075] In non-limiting embodiments, the device profile may be used to implement targeted promotional recommendations, offers, and/or merchant loyalty or reward point program restrictions. Because an appliance’s DPAN may be restricted for use with certain merchants and/or for the purchase of certain products/services or classes of products/services, a merchant may provide targeted promotions and offers to the appliance. As a result, loyalty rewards or points may accumulate more quickly given the specific field of use of the DPAN. In some non-limiting examples, an appliance with a high balance of loyalty rewards or points may maintain a higher resale or residual value for a user/owner, should the user offer the appliance for sale, end a lease, or otherwise provide the appliance to someone else.

[0076] With continuing reference to Fig. 1 , when a user of appliance (102) (e.g., owner of the appliance, user/lessee of the appliance, etc.) sells, returns, or otherwise relinquishes ownership, possession, and/or control of appliance (102), the user and/or user device (103) may communicate with transaction processing system (1 10) in a similar manner as described above for associating an MPAN to the DPAN (104) and/or D-r _oken (106) (e.g., through user device (103) or directly through appliance (102)) to disassociate the owner’s MPAN from the DPAN (104) and/or D-roken (106). Transaction processing system (1 10) then disassociates the MPAN from the DPAN (104) and D-roken (106) in token vault (1 18) as shown in the following table:

[0077] With no corresponding MPAN associated with the DPAN (104) and/or D-roken (106) in token vault (1 18), no transaction may be validated or authorized. In addition, in some non-limiting embodiments or aspects, a credit/debit limit value can be decreased when a DPAN is disassociated from an MPAN, reducing the potential loss due to any errors in validating/authorizing transactions. In some non-limiting embodiments or aspects, the MPAN may be disassociated from the DPAN and/or D-roken in response to an activation request from another user or the same user with a different MPAN. [0078] With reference to Fig. 2, illustrated is a method of provisioning a token to an appliance according to a non-limiting embodiment. In step (s1 ), the appliance manufacturer, distributor, or reseller includes in the appliance (102) memory for storing a DPAN and D-roken. In some non-limiting embodiments or aspects, the memory includes a secure and/or encrypted memory space. In some non-limiting embodiments or aspects, a D-roken that is unassociated with a DPAN may be stored in memory at this time. In step (s2), a DPAN is issued to the appliance. The DPAN is issued by issuer system (1 14) in step (s2a), by transaction processing system (1 10) in step (s2b), or both. In embodiments or aspects, for example and without limitation, those in which transaction processing system (1 10) is not involved in issuing a DPAN and a D-roken has not already been stored in the appliance, in step (s3), DPAN is communicated to transaction processing system to be tokenized. Transaction processing system tokenizes DPAN step (s4), thereby generating D-roken. The D-roken is then communicated to the appliance (102) in step (s5), where it is stored, inactive until purchased, rented, leased, or other form of possession by a user.

[0079] After D-roken is provisioned to the appliance (102), and with further reference to Fig. 2, D-roken may be activated by a user. In step (s6) via user device (103) or the appliance (102) provides identifying information that owner communicates in step (s7) to transaction processing system (1 10) to allow transaction processing system (1 10) to associate the user’s portable financial device, including the MPAN, with the DPAN and/or D-r _oken in step (s8).

[0080] Fig. 3 illustrates a system (2000) to process a transaction using a D-r _oken according to a non-limiting embodiment or aspect. In Fig. 3, the system (2000) includes an appliance (102), a merchant system (108), an acquirer system (1 12), an issuer system (1 14), and a transaction processing system (1 10). The components may communicate through network (101 ). When making a transaction, the appliance (102) communicates a transaction request, which may include D-r _oken (106) and/or DPAN (104), and optionally, transaction data, to the merchant system (108), which then communicates the transaction request to the acquirer system (1 12), such as an acquiring bank’s system. The transaction data may include, for example and without limitation, transaction value, transaction date, transaction time, transaction location, merchant identifier(s), identification of product(s)/service(s) being purchased, appliance information (e.g., a unique device identifier, a device profile, etc.) and/or the like. The acquirer system (1 12) then communicates the transaction request to the transaction processing system (1 10) to validate the transaction request and receive authorization to process the transaction. Such authorization may proceed in a two- step process.

[0081] First, in non-limiting embodiments or aspects, the transaction processing system (1 10) may conduct a check of the D-r _oken (106) and/or DPAN (1 04) in the token vault (1 18), and, in response to determining that the D-r _oken (106) and/or DPAN (1 04) are associated with an MPAN in the token vault (1 18), the transaction processing system (1 10) may determine that the transaction is authorized. Determining that the transaction is authorized may also include checking any domain restrictions associated with the D-r _oken (106) and/or DPAN (104), verifying that the MPAN is valid and can be used for the transaction and/or the like. In some non-limiting embodiments, determining that the transaction is authorized includes checking if a unique device identifier included in the transaction request matches a unique identifier associated with the DToken (106) and/or DPAN (104). If the transaction is determined to be authorized, transaction processing system (1 10) processes the transaction.

[0082] In non-limiting embodiments or aspects, a second step of authorization may include the transaction processing system (1 10) determining that the transaction is authorized by communicating the DPAN (1 04) and, optionally in some embodiments or aspects, transaction data, to issuer system (1 14) for authorization of the transaction. If issuer system (1 14) authorizes the transaction, an authorization response message is generated and communicated to the transaction processing system (1 10), which then processes the transaction.

[0083] In non-limiting embodiments or aspects, the transaction processing system (1 10) determines that the transaction is authorized based at least partially on the device profile of the appliance (102). For example, in non-limiting embodiments or aspects, the transaction processing system (1 10) may determine that the transaction is authorized based at least partially on a domain restriction specified in a device profile of the appliance (102). If the transaction processing system (1 10) determines that a transaction request satisfies the domain restriction, the transaction may be authorized and processed. Likewise, in response to determining that a transaction request does not satisfy the domain restriction, the transaction processing system (1 10) may communicate a rejection to the acquirer system (1 12), merchant system (108), appliance (102), and/or user device (103) (not shown). [0084] In non-limiting embodiments or aspects, multiple appliances and/or multiple device tokens may be used to engage in a transaction. For example, if a transaction request communicated from the appliance (102) is determined to not satisfy a domain restriction (e.g., the transaction value exceeds a credit limit or transaction limit), credit limits (or other domain restrictions) for multiple appliances associated with the user may be aggregated to allow for the transaction to take place. In such embodiments or aspects, transaction processing system (1 10) charges a first portion of the transaction value to D-r _oken (106) by sending an authorization request including DPAN (104) to issuer system (1 14) for authorization, and charges a second portion of the transaction value to one or more D-r _okens associated with one or more additional appliances. In non limiting embodiments, the appliances themselves may determine whether a domain restriction is satisfied. For example, the appliances may be in communication with one another such that an additional appliance (i.e., an appliance other than the originally requesting appliance (102)) may communicate its domain restrictions to the appliance (102) in response to the appliance (102) determining that it is unable to request the transaction based on its domain restrictions or receiving a rejection. In other non-limiting embodiments, the domain restrictions may be determined to be applicable or not applicable by the transaction processing system (1 10), issuer system (1 14), or some other system.

[0085] In some non-limiting embodiments or aspects, the transaction processing system (1 10) determines that the transaction is authorized by communicating MPAN and, optionally in some embodiments or aspects, the transaction data to an issuer system (1 16) associated with the MPAN. If issuer system (1 16) authorizes the transaction, an authorization response is communicated to the transaction processing system (1 10), which then processes the transaction.

[0086] In some non-limiting embodiments or aspects, when transaction processing system (1 10) processes a transaction initiated by appliance (102), the transaction processing system (1 10) generates an authorization request to deduct an amount corresponding to the transaction value and communicates the authorization request to issuer system (1 16). In other non-limiting embodiments or aspects, transaction processing system (1 10) aggregates transaction data for transactions initiated by appliance (102) over a certain time period, and generates and communicates to issuer system (1 16) a single authorization request to deduct an amount corresponding to the aggregated transaction amount. [0087] Returning to Fig. 2, also illustrated is a method of processing a transaction initiated by appliance (102) according to a non-limiting embodiment or aspect. In step (s9), appliance (102) communicates a transaction request to a merchant system (108) (not shown) or acquirer system (1 12). The transaction request includes transaction data, the D-r _oken, and in some non-limiting examples, the DPAN. In step (s10), the acquirer system (1 12) communicates the transaction data, the D-r _oken and, in some non-limiting examples the DPAN, to the transaction processing system (1 10) for validation and authorization. In step (s1 1 ), transaction processing system (1 10) checks token vault to verify that the D-r _oken and/or DPAN is/are associated with an MPAN. If the D-r _oken and/or DPAN are associated with an MPAN, in step (s12) an authorization request, including the DPAN and, in some non-limiting embodiments, transaction data, is sent to issuer system (1 14). If the transaction is authorized, issuer system (1 14) communicates an authorization response to transaction processing system (1 10) in step (s13). If authorized, transaction processing system (1 10) processes the transaction and, in step (s14), communicates an authorization response to merchant acquirer system (1 12) and, in some non-limiting examples, to appliance (102) and/or appliance user, for example, through a notification communicated to user device (103).

[0088] Referring now to Fig. 4, shown is a flow diagram of a non-limiting embodiment or aspect of a method (4000) for authorizing and provisioning a token to an appliance. One or more steps of the method (4000) may be performed partially or completely by a transaction processing system, such as described herein, although it will be appreciated that other devices and/or systems may perform one or more steps in non-limiting embodiments. As shown in Fig. 4, at step (402), an original account identifier is issued to an appliance. As described herein, the original account identifier (DPAN) is not associated with any user or appliance owner at the time of issuance. In step (404), a device token (D-roken) is associated to the original account identifier (DPAN). The D-r _oken may be generated or may already exist. The D-r _oken may be stored in memory on the appliance. In step (406), a user account identifier (MPAN) is associated with the D-r _oken and/or the DPAN. AS described above, this association can be stored in a token vault. The MPAN may be a distinct original account identifier for a user that exists independently of the DPAN.

[0089] With continued reference to Fig. 4, in step (408), a transaction request, including the D-r _oken , is received from the appliance. In step (410), a user account, such as MPAN or a corresponding token, is identified based at least partially on the D-roken. Thereafter, in step (412), a determination is made as to whether the transaction is authorized. This determination is based at least partially on the DPAN and, in some non-limiting embodiments, at least partially on the DPAN and the MPAN. In step (414), in response to determining that the transaction is authorized, the transaction is processed. For example, in response to determining that the transaction is initially authorized because the DPAN is associated with an MPAN, the transaction processing system may generate and communicate an authorization request to an issuer system to obtain final authorization that the transaction can be completed.

[0090] Referring now to Fig. 5, shown is a flow diagram of a non-limiting embodiment or aspect of a method (5000) for authorizing an appliance to process a transaction. One or more steps of the method (5000) may be performed partially or completely by a transaction processing system, although it will be appreciated that other devices and/or systems may perform one or more steps in non-limiting embodiments .As shown in Fig. 5, at step (502), an original account identifier is issued and registered to an appliance. As described herein, the original account identifier (DPAN) is not associated with any user or appliance owner at the time of issuance. In step (504), a transaction request is received directly or indirectly from the appliance. The transaction request includes the D-roken and/or DPAN associated with the appliance. In step (506), an authorization request, including the DPAN, is generated. In step (508), the authorization request is communicated to an issuer system associated with the DPAN-

[0091] Also provided herein are a system and method for authorizing an appliance to receive a payment. Such a system is shown in Fig. 1 and Fig. 3 according to non limiting embodiments and aspects. The system and method may utilize the same components as described above, including an appliance (102), an issuer system (1 14), and a transaction processing system (1 10). The components may communicate through network (101 ). An original DPAN (104) is registered to the appliance (102) by issuer system (1 14) and/or transaction processing system (1 10). The DPAN (104) is an original PAN that is not associated with a user or appliance owner at the time of issuance, such that the DPAN (104) is not issued to a human being, even though in some non-limiting embodiments the DPAN (104) may be subsequently linked to a user PAN. In some non-limiting embodiments or aspects, both the issuer system (1 14) and the transaction processing system (1 10) collaborate to issue the DPAN (104) to the appliance. In some non-limiting embodiments or aspects, registering the original account identifier includes associating a unique device identifier specific to the appliance with the DPAN (104). The unique device identifier specific to the appliance may be encoded into memory (105) of the appliance (102).

[0092] A method for authorizing a transaction is described above. The same components useful for authorizing a transaction may be useful for authorizing acceptance of a payment by the appliance (102). For example, and without limitation, a user may interact with appliance (102) through a user device (103), or through appliance (102) itself, to submit a payment for, e.g., rental/leasing of the appliance, or the like. As with traditional payment methods, this may involve the user, through user device (103) or directly through appliance (102) itself, communicating a payment request, including an account identifier associated with the user (i.e., an UPAN or UToken), to appliance (102). A payment request may include DPAN, D-roken, UPAN, and/or UToken. In addition, the payment request may include payment data, such as, for example and without limitation, payment amount, payment date, payment time, payment location, merchant identifier(s), identification of product(s)/service(s) being purchased, appliance information (e.g., a unique device identifier, a device profile, etc.) and/or the like.

[0093] Appliance (102) communicates the payment request to merchant system (108) and/or acquirer system (1 12), which may be, for example and without limitation, associated with a rental car company or other leasing or rental agency. The acquirer system (1 12) then communicates the payment request to the transaction processing system (1 10) to validate the payment request and receive authorization to process the payment. The transaction processing system (1 10) determines that the payment is authorized by communicating UPAN and/or U _Token and, optionally in some embodiments or aspects the payment data, to an issuer system (1 16) associated with the UPAN and/or U _Token . If issuer system (1 16) authorizes the payment, an authorization response is communicated to the transaction processing system (1 10), which then processes the payment. In non-limiting embodiments or aspects, transaction processing system (1 10) communicates the authorization to appliance (102), merchant system (108), acquirer system (1 12), and/or user device (103). As described above, in non-limiting embodiments or aspects, the authorization by the transaction processing system may be a two-step authorization, whereby in a first step the transaction processing system (1 10) may conduct a check of the D _Token (106) and/or DPAN (1 04) in the token vault (1 18), and, in response to determining that the DToken (106) and/or DPAN (104) are associated with an MPAN (e.g., an account identifier associated with a rental car company, leasing agency, or the like) in the token vault (1 18), the transaction processing system (1 10) may determine that the payment is authorized. In a second authorizing step, the transaction processing system may communicate the UPAN and/or ll-roken and, optionally in some embodiments or aspects the payment data, to an issuer system (1 16) associated with the UPAN and/or U-roken, as described above. In further non-limiting embodiments or aspects, the transaction processing system (1 10), issuer system (1 14), and/or appliance (102) itself, determine that a payment request satisfies a domain restriction associated with the appliance prior to authorization and processing of the payment by the transaction processing system (1 10).

[0094] In some non-limiting embodiments or aspects, when transaction processing system (1 10) processes a payment request received by appliance (102), the transaction processing system (1 10) generates an authorization request to deduct an amount corresponding to the payment value and communicates the authorization request to issuer system (1 14). This deducted amount is deposited with an issuer system associated with the MPAN stored in the token vault (1 18). In other non-limiting embodiments or aspects, transaction processing system (1 10) aggregates payment data for payments received by appliance (102) over a certain time period, and generates and communicates to issuer system (1 14) a single authorization request to deduct an amount corresponding to the aggregated payment amount, and to deposit the aggregated payment amount with an issuer system associated with the MPAN stored in the token vault (1 18).

[0095] Further provided herein is an appliance for conducting transactions without the need for a user-specific account. With reference back to Fig. 1 , the appliance (102) includes memory (105) internal to the appliance (102) storing a DPAN (104) not associated with any user and/or a D _Token (106) uniquely associated with the device account identifier, a communication device, and a processor in communication with the memory and the communication device, the processor being programmed or configured to generate a transaction request including at least one of the DPAN (104) and D _Token (106). In non-limiting embodiments or aspects, the appliance processor is programmed or configured to communicate a transaction request to a transaction processing system, receive a rejection of the transaction request, and in response, generate a new transaction request including at least one of the DPAN (104) and DToken (106), and at least one other DPAN or D-roken associated with at least one other appliance, and communicate the new transaction request to the transaction processing system.

Examples

Example 1 - Smart Home

[0096] In a smart home implementation incorporating a non-limiting embodiment of the invention described herein, one or more appliances, such as a washing machine, refrigerator, television, and/or the like, conduct transactions with providers of goods and/or services, utility companies, and/or device manufacturers, for example, and without limitation, to order supplies that are or are believed to be depleted, to schedule maintenance or repairs, to purchase media content or software, to purchase access to a service, and/or the like. The transaction is requested using one or more D-rokens and/or DPAN _S associated with the respective appliances. As described above, the DPAN provisioned on each device may have associated domain restrictions, such as, for example and without limitation, a permitted list of products, brands, and merchants along with credit/debit limit values and/or transaction limit values. The appliances may also be preconfigured with an initial credit limit/debit fund value (e.g., $20, $50, etc. depending on device model and/or manufacturer), which may be incorporated into the sales/rental/lease price of the appliance with or without a discount.

[0097] In addition to driving promotional recommendations and offers as described above, device profiles can also be used for relative profile ranking. Relative ranking of device profiles can be developed in a manner analogous to that for customer profiles with credit card issuers. The higher a device profile is ranked, the better the offers that can be availed using the DPAN issued to the device. Consequently, a better profile adds value to a device, which adds a premium to the resale value of the device. For example, and without limitation, a washing machine, which purchases primarily detergent and detergent-like products, can be limited to a specific merchant domain, may receive targeted promotions or offers, and may rapidly accumulate loyalty or reward points associated with the merchant. This accumulated value adds to resale value, as the accumulated loyalty or reward points can contribute to lower cost of operation in the future, which can be advertised by the appliance owner when attempting to sell the appliance. Identical appliances (in terms of manufacturer/model), but with different device profiles, could have different resale values owing to the difference in goods/services offer benefits available to the new owners.

[0098] An additional feature of a smart home solution includes splitting payments across a plurality of appliances with overlapping domain restrictions. For example, and without limitation, a refrigerator in which the DPAN is limited to a specific monthly, quarterly, or yearly credit/debit limit value may, when submitting a transaction request, combine its remaining credit/debit limit value with that of a microwave provisioned with a DPAN that maintains a sufficient amount of credit/debit limit value based on the microwave’s device profile. Moreover, appliances in a common household may seek permission to use offers (e.g., discounts) available on other devices with overlapping domain restrictions.

Example 2 - Smart Cars

[0099] In a rental car implementation incorporating a non-limiting embodiment of the invention described herein, one or more vehicles may conduct transactions with other appliances (e.g., toll booths, gas stations, other automobiles, or other like systems or service providers) and/or conduct transactions with individuals who rent/lease the vehicles.

[0100] In such an example, each car in a fleet of rental vehicles may have a financial account issued to it (DPAN), with a corresponding token (D-roken), with a mapping to the fleet owner PAN (MPAN) in a token vault. Each vehicle could accept direct payments from renters, and based on the mapping in the token vault, rather than authorization to deduct funds from the MPAN as described above, funds would be received by the appliance, through DPAN, from a user/renter account (based on a UPAN or UToken), and would be deposited to an account associated with the MPAN. In addition, similar to the process described above, a vehicle provisioned with a D-r _oken could make payments for its requirements such as fuel, tolls, maintenance, insurance, and the like. Domain restrictions could be applied at a car payment module to make purchases at specific merchants and/or for specific merchant categories. The vehicles in the rental car fleet may be further connected to each other to allow borrowing/aggregating credit/debit limit values, as described above, if required.

[0101 ] Such a system could also benefit a renter as certain loyalty or reward points, such as fuel reward points, associated with the DPAN, as described above, could result in better offers for fuel. Further, in an international location for a renter, the vehicle may pay in local currency, and the renter may therefore avoid multiple foreign currency transactions (including possible currency conversion surcharges) on a single user account identifier.

[0102] As explained above, as with all appliances, a vehicle may have a credit/debit limit value assigned based on the vehicle type, manufacturer, transaction history, rental location, and/or the associated credit score of the entity/institution that owns/operates the fleet. The initial credit/debit limit may be defined by the relationship between the automobile manufacturer and a bank/payment network. For example, and without limitation, Car Company A may link with Bank A and T ransaction Service Provider A to provision credit/debit cards having DPAN _S with a limit of $1000 USD for all SUVs manufactured by Car Company A.

[0103] Although the invention has been described in detail for the purpose of illustration based on what is currently considered to be the most practical and preferred embodiments, it is to be understood that such detail is solely for that purpose and that the invention is not limited to the disclosed embodiments, but on the contrary, is intended to cover modifications and equivalent arrangements that are within the spirit and scope of the appended claims. For example, it is to be understood that the present invention contemplates that, to the extent possible, one or more features of any embodiment can be combined with one or more features of any other embodiment.