Global secure service provider directory

RELATED APPLICATIONS

0001The present application claims priority to U.S. Provisional Patent Application Ser. No. 61/251,231, entitled GLOBAL SECURE SERVICE PROVIDER DIRECTORY, filed on Oct. 13, 2009.

FIELD OF THE INVENTION

0002The present invention relates generally to mobile payment systems, and more particularly to a directory for determining the identity of a service provider for a mobile payment capable device.

BACKGROUND

0003Mobile computing devices, such as cellular phones, may be used to execute various secure transactions, such as paying for a purchase at a retailer. A mobile device may be linked to a credit card, so that any payments made by the mobile device are debited to the appropriate account. Mobile devices may be used for a variety of monetary transactions, such as ATM withdrawals, managing transit accounts, or purchasing sports and entertainment tickets that may be stored on the device for redemption at an electronic terminal.

0004Secure transactions, such as credit card payments, typically take place within a highly secure network. Each device within the network must be trusted to enforce certain security measures, including smart credit cards, point-of-sale terminals (e.g., credit card readers), network switches, and bank servers. The level of security required to operate some networks may preclude a computing device from being a trusted network element if the device can also be used for non-secure purposes, such as browsing web pages or playing games.

0005In order to allow a general purpose computer to be a trusted member of a secure network, some computing devices may utilize a secure subsystem. Many personal computer (PC) workstations include a Trusted Platform Module® implementation for securely storing cryptographic keys. Similarly, mobile computing devices may include a secure subsystem capable of executing a secure transaction, such as providing credit card account information to a point of sale terminal Such a secure subsystem may include a secure element, which may be implemented as an integrated circuit (“chip”) with a microprocessor and onboard persistent storage. In order to enforce security measures, the secure element may be configured to interact only with other trusted members. Within some secure transaction networks, a particular mobile handset cannot function as a mobile payment device unless a trusted member provides the secure element within the mobile device with a credit card account number, as well as software code allowing the secure element to properly interact with a point-of-sale terminal. A trusted member capable of provisioning secure elements in mobile devices is known as a Trusted Service Manager.

SUMMARY

0006Various aspects provide a method for identifying a trusted service manager (TSM) provider that includes determining a secure element identifier corresponding to a secure element of a computing device, determining an application identifier corresponding to a security domain within the secure element, providing the secure element identifier and the application identifier to a first repository of TSM providers, and receiving, from the first repository, an identifier of the TSM provider that corresponds to the security domain. In an aspect, the method may further include providing the secure element identifier to a second repository of TSM providers, and receiving, from the second repository, an identifier of the first repository. In the method, determining a secure element identifier corresponding to a secure element may include sending a query to the secure element via a system bus connecting a central processor of the computing device to the secure element, and receiving the identifier from the secure element via the system bus. In an aspect of the method, determining a secure element identifier corresponding to a secure element may include sending a query to the secure element via a near field communication (NFC) communication link, and receiving the identifier from the secure element via the NFC communication link. In another aspect of the method, determining an application identifier corresponding to a security domain within the secure element may include sending a query to the secure element via the system bus, and receiving the identifier from the secure element via the system bus. In another aspect of the method, determining an application identifier corresponding to a security domain within the secure element may include sending a query to the secure element via the NFC communication link, and receiving the identifier from the secure element via the NFC communication link. In an aspect of the method, providing the secure element identifier and the application identifier to a first repository of TSM providers may include sending, from the mobile device, a query to the first repository of TSM providers in which the query includes the secure element identifier and the application identifier. In another aspect, the method may further include sending, from the mobile device to a server corresponding to a secure service provider, the identifier of the TSM provider that corresponds to the security domain. In another aspect of the method, providing the secure element identifier and the application identifier to a first repository of TSM providers may include sending, from a server corresponding to a secure service provider, a query to the first repository of TSM providers, in which the query includes the secure element identifier and the application identifier.

0007In another aspect, a transaction system includes one or more mobile devices, a bank server, a central trust repository server, and a TSM server, wherein the mobile devices, the bank server, the central trust repository server, and the TSM server are configured with executable instructions to perform the operations of the foregoing methods.

0008In an aspect, a mobile device may include a processor, a memory including a secure element coupled to the processor, and a transceiver coupled to the processor, in which the processor is configured with executable instructions to perform operations of the foregoing methods.

0009In an aspect, a server may include a processor, a memory including a secure element coupled to the processor, and a transceiver coupled to the processor, in which the processor is configured with executable instructions to perform operations of the foregoing methods.

0010In another aspect, a system may include means for accomplishing the functions of the foregoing methods.

0011In another aspect, a tangible computer-readable storage medium includes software instructions configured to cause a programmable processor to perform operations of the foregoing methods. The tangible computer-readable storage medium may be configured to be read by a server computer with the software instructions configured to cause a server to perform the server-based operations of the foregoing methods. Also, the tangible computer-readable storage medium may be configured to be read by a mobile device processor with the software instructions configured to cause a processor to perform the mobile device-based operations of the foregoing methods.

BRIEF DESCRIPTION OF THE DRAWINGS

0012The accompanying drawings, which are incorporated herein and constitute part of this specification, illustrate exemplary aspects of the invention, and, together with the general description given above and the detailed description given below, serve to explain features of the invention.

0013<figref idrefs="DRAWINGS">FIGS. 1A and 1B</figref> are component block diagram of a communication system suitable for use with the various aspects.

0014<figref idrefs="DRAWINGS">FIG. 2</figref> is a process flow diagram of an aspect method for enabling secure service providers to discover the identity of a TSM server.

0015<figref idrefs="DRAWINGS">FIG. 3</figref> shows a data structure suitable for use with the aspect illustrated in <figref idrefs="DRAWINGS">FIG. 2</figref>.

0016<figref idrefs="DRAWINGS">FIG. 4</figref> is a component block diagram of a communication system suitable for use with another aspect.

0017<figref idrefs="DRAWINGS">FIG. 5</figref> is a process flow diagram of an aspect method for enabling secure service providers to discover the identity of a TSM server making use of a centralized directory of TSM accounts.

0018<figref idrefs="DRAWINGS">FIG. 6</figref> shows a data structure suitable for use with the aspect illustrated in <figref idrefs="DRAWINGS">FIG. 5</figref>.

0019<figref idrefs="DRAWINGS">FIG. 7</figref> is a component block diagram of a communication system suitable for use with another aspect.

0020<figref idrefs="DRAWINGS">FIG. 8A</figref> which continues onto <b>8</b>B is a process flow diagram of another aspect method for discovering the identity of a TSM server.

0021<figref idrefs="DRAWINGS">FIGS. 9A and 9B</figref> show to data structures suitable for use with the aspect illustrated in <figref idrefs="DRAWINGS">FIG. 7</figref>.

0022<figref idrefs="DRAWINGS">FIG. 10</figref> is a component block diagram illustrating example components of a mobile device suitable for use in the various aspects.

0023<figref idrefs="DRAWINGS">FIG. 11</figref> is a component block diagram illustrating example components of a server suitable for use in the various aspects.

DETAILED DESCRIPTION

0024The various aspects will be described in detail with reference to the accompanying drawings. Wherever possible, the same reference numbers will be used throughout the drawings to refer to the same or like parts. References made to particular examples and implementations are for illustrative purposes, and are not intended to limit the scope of the invention or the claims.

0025As used herein, the terms “mobile handsets” and “mobile devices” are used interchangeably and refer to any one of various cellular telephones, personal data assistants (PDA's), palm-top computers, laptop computers, wireless electronic mail receivers (e.g., the Blackberry° and Treo® devices), and multimedia Internet enabled cellular telephones (e.g., the Blackberry Storm®), and similar personal electronic devices. A mobile device may include a programmable processor and memory as described more fully below with reference to <figref idrefs="DRAWINGS">FIG. 11</figref>. The term “computing device” is used herein to refer to any device including a programmable processor and memory, including mobile devices, desktop computers, workstations, mainframe computers, and embedded computer systems.

0026As used herein, the term “secure element” refers to an integrated circuit (“chip”) with a microprocessor and onboard persistent storage that may be included in the mobile device and configured to enable communications in a secure network.

0027In some cellular networks with mobile devices capable of secure transactions, a trusted party that manages the various secure elements may be known as a Trusted Service Manager, which is typically referred to as a “TSM”. A TSM may be capable of configuring a secure element over the cellular network without being inhibited by a malicious user or malicious code executing within the main operating system of the mobile device. A secure element may be managed by a single TSM, or it may be managed by a plurality of different TSMs. The various applications and data stored on the secure element may be divided into a hierarchy of security domains, with each security domain managed by a TSM. In order to establish a new SSD (e.g., configuring a mobile handset as a mobile payment device), the service provider (e.g., a bank) may need to determine which TSM manages the parent security domain (i.e., the security domain within which the new SSD will be established). As more secure services are capable of being implemented on a mobile device, more TSMs will be established. As more TSM are established, finding the proper TSM for a particular task will become increasingly difficult.

0028The various aspects provide systems and methods for enabling members of a secure transaction network to readily identify the appropriate TSM to support a particular transaction. In particular, the various aspects provide methods that a secure service provider can use for determining which TSM provider is the authorized manager of a security domain for a particular transaction by using a global directory of TSM providers.

0029The aspects may operate in conjunction with mobile devices configured to support secure transactions, such as mobile payments. In some aspects, a mobile device may include a secure element as part of a secure subsystem. The secure element may be configured to send and receive messages via a cellular network using a cellular telephone transceiver, to send and receive messages from the mobile device operating system via a system bus, and to send and receive messages from other devices via a near field communication (NFC) transceiver.

0030As part of a secure system, the secure element may not be significantly altered via messages that fall outside a strict set of rules. For example, the secure element may set up a new service (e.g., configuring itself for credit card transactions) only in response to a trusted message received via a cellular telephone network. Further, to determine whether a message is trusted, a secure element may utilize one or more cryptographic keys to verify the message. The various aspects may utilize one of the many well known key-based trust schemes. Simply put, some aspects may use a scheme whereby a message received is not trusted unless the message is encoded in a way that proves that the sender of the message possesses a specific cryptographic key. In such an aspect, the security of the entire system is largely based on preventing the various keys from being known to malicious users. Accordingly, the various aspects may utilize one or more trusted TSM servers dedicated to managing the various secure elements including maintaining the secret keys. A TSM provider may be a commercial entity that manages one or more TSM servers.

0031TSM providers may perform a variety of services related to enabling secure transactions. In some aspects, a TSM provider is capable of provisioning a new service. For example, a mobile device with a secure element may be at first managed solely by a first TSM. In order to configure the mobile device for a specific transaction, such as Visa® credit card purchases, the first TSM may send a message to the mobile device including one or more cryptographic keys which allows the mobile device to trust a second TSM server related to a bank that maintains Visa® credit card accounts. The first TSM may also send a message to the second TSM server including one or more cryptographic keys which allows the second TSM server to communicate with and verify itself to the mobile device. The second TSM server may send a message to the mobile device which includes the software that enables the secure element to communicate with point of sale devices within the Visa® network, such as via an NFC transceiver, as well as user specific data, such as a Visa® credit card account number or a set of cryptographic keys corresponding to the credit card account. Additionally, a TSM provider may “personalize” an existing service. For example, a mobile device may be configured with software that enables the secure element to communicate with point of sale devices via an NFC transceiver. A TSM may establish or update the user-specific account data, which may be a credit card number or one or more cryptographic keys.

0032In some aspects, the relationship between TSM providers and secure elements may be hierarchical and organized according to security domains. For example there may be a primary TSM that manages a primary security domain. The primary TSM may create one or more supplemental security domains (“SSD”) and grant authority over each SSD to another TSM. Each TSM, if granted proper permissions by the primary TSM, may further create an SSD within its own SSD and grant authority to another TSM. In some aspects, there may involve a one-to-one correspondence between each SSD and a single TSM.

0033The arrangement of supplemental security domains within a secure element may vary among different mobile devices, even for two mobile devices with the same capabilities. Additionally, the specific TSM providers may vary across among mobile devices due to market competition, as well as other factors.

0034The various aspects may be employed in a variety of wired and wireless networks, including for example a wireless network employing cellular data communication links. By way of example, <figref idrefs="DRAWINGS">FIG. 1A</figref> shows a block diagram of a communication network <b>20</b> including a cellular network <b>10</b> in which some mobile cellular devices <b>5</b> have the additional ability to communicate using short range wireless communications <b>3</b>, such as NFC. The network <b>20</b> may include a mobile device <b>5</b>, which in the illustrated system is configured with a network antenna and transceiver for transmitting and receiving cellular signals <b>2</b> from/to a cellular base site or base station (BS) <b>7</b>. In this example network <b>20</b>, the base station <b>7</b> is a part of a cellular network <b>20</b> that includes elements required to operate the network, such as a mobile switching center (MSC) <b>8</b>. In operation, the MSC <b>8</b> is capable of routing calls and messages to and from the mobile device <b>5</b> via the base station <b>7</b> when the mobile device <b>5</b> is making and receiving cellular data calls. The MSC <b>8</b> may also provide a connection to telephone landline trunks (not shown) when the mobile device <b>5</b> is involved in a call. Further, the MSC may be coupled to an Internet gateway server <b>9</b> coupled to the Internet <b>24</b>, for providing Internet access to the mobile device <b>5</b>.

0035The mobile device <b>5</b> may be further equipped to make mobile payments over a short range communications protocol, such as NFC. The mobile device <b>5</b> may engage in mobile payments by sending and receiving short range communication link RF signals <b>3</b> between the mobile device <b>5</b> and a mobile payment point-of-sale (POS) terminal <b>4</b>. The mobile payment POS terminal <b>4</b> may be connected via a transaction authorization network <b>22</b> to a bank server <b>15</b> corresponding to a bank with which a user of the mobile device <b>5</b> maintains a credit card account. <figref idrefs="DRAWINGS">FIG. 1A</figref> presents but one example of electronic commerce transaction networks and systems which are well known.

0036The mobile device <b>5</b> may further include a secure element for storing data such as a credit card number. The secure element may also store and execute instructions sufficient to complete a mobile payment with a POS terminal <b>4</b> via RF signals <b>3</b>. The network <b>20</b> may also include a primary TSM server <b>11</b> for sending commands to the secure element of the mobile device <b>5</b> via data packets sent over cellular signals <b>2</b>. The network <b>20</b> may include additional TSM servers capable of managing the secure element of the mobile device <b>5</b> such as a bank TSM server <b>12</b>, which in this example is configured to receive credit card account numbers from a bank server <b>15</b> and forward such numbers to the secure element via the Internet <b>24</b> and a cellular telephone network <b>10</b> to the mobile device <b>5</b>.

0037In some aspects, the secure transaction communication network <b>20</b> may include a plurality of cellular service providers, as well as a plurality of transaction authorization networks <b>22</b> and other secure service providers. By way of example, <figref idrefs="DRAWINGS">FIG. 1B</figref> shows a block diagram of a communication network <b>21</b> including a plurality of cellular networks <b>10</b><i>a</i>-<b>10</b><i>c</i>, each supporting cellular communications with a plurality of mobile handsets <b>5</b> (not shown) capable of engaging in secure transactions by utilizing a secure element. The communication network <b>21</b> may also include a plurality of bank servers <b>15</b><i>a</i>-<b>15</b><i>d </i>connected to a transaction authorization network <b>22</b>. The bank servers <b>15</b><i>a</i>-<b>15</b><i>d </i>may also be connected to the various cellular networks <b>10</b><i>a</i>-<b>10</b><i>c </i>via one or more TSM servers <b>12</b><i>a</i>-<b>12</b><i>c</i>. Additionally, the various mobile handsets <b>5</b> on the various cellular networks may be capable of conducting a plurality of different secure transactions other than credit card authorizations. In an aspect, one or more TSM servers <b>12</b><i>a</i>-<b>12</b><i>c </i>provide mobile devices <b>5</b> with the ability to link to gift card accounts managed by retail servers <b>16</b>.

0038The various aspects enable secure service providers to discover the identity of a TSM server that can configure a certain mobile handset for a certain secure service. An overview of how such a service can be configured is illustrated in <figref idrefs="DRAWINGS">FIG. 2</figref>, which shows a method <b>40</b> that may be implemented on computing devices. A user of a mobile device <b>5</b> equipped with a secure element may want to enable the mobile device <b>5</b> to make credit card payments. The mobile device <b>5</b> may be equipped with a mobile wallet application and corresponding mobile wallet SSD capable of transacting with a credit card point-of-sale terminal. In order to use the mobile device <b>5</b> as a credit card, the mobile wallet application may be updated with the user's credit card account information.

0039In method <b>40</b> at block <b>42</b>, the user may launch a mobile payment setup application on the mobile device. At block <b>60</b>, the setup application may query the secure element to determine whether the mobile device <b>5</b> is equipped with a suitable mobile wallet application for mobile credit card payments, and if so, which TSM provider manages the mobile wallet. This query (block <b>60</b>) may also determine the serial number of the secure element, which may also be referred to as the secure element identifier. At block <b>61</b>, the setup application may transmit the secure element identifier and the TSM provider identifier to the bank server <b>15</b>. At block <b>62</b>, the bank server <b>15</b> may receive the secure element identifier and the TSM provider identifier. In some aspects, the setup application may be provided to the mobile device <b>5</b> as an Internet download from the website of the bank where the user has an account, and the setup application may communicate with the bank server <b>15</b> via the Internet. Alternately, the setup application may be provided to the mobile device <b>5</b> via an NFC link with an NFC terminal. In some aspects, the secure element identifier and the TSM provider identifier may be transmitted from the mobile device <b>5</b> to the bank server <b>15</b> via the NFC terminal. In another aspect, there may not be a setup application. Instead, the mobile device <b>5</b> may receive a query directly from an NFC terminal and respond with the secure element identifier and the TSM provider identifier.

0040Based on the TSM provider identifier, at block <b>46</b> the bank server <b>15</b> may locate the TSM server <b>12</b> corresponding to the TSM provider and send a request to link the mobile device <b>5</b> to a credit card including the secure element identifier and the credit card number. In some aspects, the TSM provider identifier may be an IP address or domain name. In other aspects, the process of locating a TSM server based on a TSM server identifier may involve a broadcast message sent over one or more private networks of TSM servers. At block <b>47</b>, the TSM server <b>12</b> may receive the request from the bank server <b>15</b>. At block <b>48</b>, the TSM server <b>12</b> may transmit a message to the mobile device <b>5</b> instructing it to update the mobile wallet with the specific credit card information. The message may be received by the mobile device <b>5</b> and the mobile wallet may be updated at block <b>49</b>. In some aspects, the mobile wallet may determine that the message is properly encoded with a cryptographic key corresponding only to that particular mobile wallet SSD.

0041In the foregoing example, the mobile device may be responsible for maintaining the identity of its TSM providers. An example of a data table for storing such data in the secure element is presented in <figref idrefs="DRAWINGS">FIG. 3</figref>, which shows a data structure that may be implemented on a computing device, such as a mobile device <b>5</b>. The secure element of a mobile device <b>5</b> may include data storage (e.g., FLASH memory), including a security domain data table <b>90</b> that stores information about the various security domains in a plurality of data records (shown as rows) <b>95</b>, <b>96</b>, <b>97</b>, <b>98</b>, each including a plurality of data fields <b>91</b>, <b>92</b>, <b>93</b>, <b>94</b>. Each security domain has an identifier that is unique to the secure element, which may be stored in a data field <b>91</b>. In an implementation in which the security domains are arranged hierarchically, the security domain data table <b>90</b> may include a data field <b>92</b> storing the identifier of a parent security domain. The security domain data table <b>90</b> may also store an identifier of a TSM provider in a third data field <b>93</b>. The security domain data table <b>90</b> may further include additional data fields <b>94</b> for storing other data relevant to the security domains, such as the granted permissions or the assigned cryptographic keys.

0042In some aspects, a mobile device may not keep a record of the various TSM managing its security domains. In a key-based network, a mobile device may operate under the presumption that any properly encoded message is from the TSM. In such aspects, control over a security domain may be transferred by transferring the cryptographic key corresponding to that security domain. Accordingly, a central repository may store data mapping TSM providers to security domains. An overview of how such a directory may exist is shown in <figref idrefs="DRAWINGS">FIG. 4</figref>, which shows a diagram of a communication network in which a plurality of TSM servers <b>12</b><i>a</i>-<b>12</b><i>d </i>have communication links to a central repository <b>110</b>. The central repository <b>110</b> may be a database storage device coupled to a server providing connectivity and addressability via a secure network and/or the Internet. When a TSM provider provisions a new service on a mobile device, the TSM provider may create a directory listing uniquely identifying the security domain and mapping it to the TSM, and store this directory listing in the central repository <b>110</b> so that it may be accessed by any of the of TSM servers <b>12</b><i>a</i>-<b>12</b><i>d. </i>

0043An overview of how a secure service provider may utilize a central repository of TSM providers is illustrated in <figref idrefs="DRAWINGS">FIG. 5</figref>, which shows a method <b>50</b> that may be implemented on computing devices. In method <b>50</b> at block <b>42</b>, the mobile device <b>5</b> may start a mobile payment setup application. The setup application may query the secure element and discover the secure element identifier (i.e., the unique identifier of the secure element) and the application identifier (“AID”) of the mobile wallet SSD at block <b>82</b>. At block <b>83</b> the mobile device <b>5</b> may send a message with the secure element identifier and the mobile wallet AID to the bank server <b>15</b>, and the message may be received by the bank server <b>15</b> at block <b>84</b>. As previously discussed with reference to <figref idrefs="DRAWINGS">FIG. 2</figref>, messages communicating the various identifiers to the bank server <b>15</b> may be routed through an NFC terminal rather than a cellular network.

0044At block <b>85</b> the bank server <b>15</b> may send the secure element identifier and mobile wallet AID to the central repository <b>110</b>, where it is received at block <b>86</b>. At block <b>87</b> the central repository <b>110</b> may determine the TSM provider corresponding to the mobile wallet application on the mobile device <b>5</b> using the combination of secure element identifier, which is unique across all mobile devices, and the mobile wallet AID, which is unique for a given mobile device. At block <b>88</b> the central repository may send the TSM provider identity to the bank server <b>15</b>, where it is received at block <b>89</b>.

0045Based on the TSM provider identifier, at block <b>46</b> the bank server <b>15</b> may locate the TSM server <b>12</b> corresponding to the TSM provider and send a request to link the mobile device <b>5</b> to a credit card including the secure element identifier and the credit card number. In some aspects, the TSM provider identifier may be an IP address or domain name. In other aspects, the process of locating a TSM server based on a TSM server identifier may involve a broadcast message sent over one or more private networks of TSM servers. At block <b>47</b> the TSM server <b>12</b> may receive the request from the bank server <b>15</b>. At block <b>48</b> the TSM server <b>12</b> may transmit a message for the mobile device <b>5</b> instructing it to update the mobile wallet with the specific credit card information. The message may be received by the mobile device <b>5</b> and the mobile wallet may be updated at block <b>49</b>. In some aspects, the mobile wallet may verify the message by determining that it is properly encoded with a cryptographic key corresponding only to that particular mobile wallet SSD.

0046As previously discussed, the combination of a secure element identifier and security domain AID may serve as a unique identifier for any SSD across all mobile devices. A suitable data structure for mapping such a combination to a TSM provider is shown in <figref idrefs="DRAWINGS">FIG. 6</figref>, which shows a data table <b>111</b> that may be implemented in the central repository <b>110</b>. The central repository <b>110</b> may store a data table <b>111</b> configured in the form of a plurality of data records (illustrated as rows) <b>113</b>, <b>114</b>, <b>115</b>, and <b>116</b>, with each data record comprising a plurality of data fields <b>91</b>, <b>112</b>, <b>93</b>. For example, the data table <b>111</b> may contain a data field <b>91</b> for storing a security domain AID, a data field <b>112</b> for storing a secure element identifier, and a data field <b>93</b> for storing a TSM provider identifier.

0047In an alternative to a centralized repository <b>110</b>, some aspects may utilize a distributed repository system. An overview of such an aspect is illustrated in <figref idrefs="DRAWINGS">FIG. 7</figref>, which shows a diagram of a communication network <b>20</b> including a distributed repository. A plurality of secondary repositories <b>118</b><i>a</i>-<b>118</b><i>c </i>may be configured to store a mapping of TSM providers to security domains, while a primary repository <b>114</b> is configured to store a mapping of secure elements to the secondary repositories <b>118</b><i>a</i>-<b>118</b><i>c</i>. Each of the primary and secondary repositories may include a server coupled In an aspect, the secondary repositories will correspond one-to-one with a cellular service provider, represented by mobile switching stations <b>10</b><i>a</i>-<b>10</b><i>c</i>. In another aspect, the secondary repositories may correspond one-to-one with a primary TSM. When a new secure element is issued (e.g., when a phone is activated on a cellular network), the secure element may be assigned to a secondary repository and an entry in the primary repository <b>114</b> may be stored to map the secure element to a specific secondary repository <b>118</b><i>a</i>-<b>118</b><i>c</i>. When a new service is provisioned on the secure element, the specific secondary repository <b>118</b><i>a</i>-<b>118</b><i>c </i>may be updated to include a mapping of the new service to a TSM provider, represented by TSM servers <b>12</b><i>a</i>-<b>12</b><i>d. </i>

0048An overview of how a secure service provider may utilize a distributed repository of TSM providers is illustrated in <figref idrefs="DRAWINGS">FIG. 8</figref>, which shows a method <b>55</b> that may be implemented on computing devices. In method <b>55</b> at block <b>42</b> the mobile device <b>5</b> may start a mobile payment setup application. At block <b>82</b> the setup application may query the secure element and discover the secure element identifier (i.e., the unique identifier of the secure element) and the application identifier (“AID”) of the mobile wallet SSD. At block <b>83</b> the mobile device <b>5</b> may send a message with the secure element identifier and the mobile wallet AID to the bank server <b>15</b>, and the message may be received by the bank server <b>15</b> at block <b>84</b>. As previously discussed with reference to <figref idrefs="DRAWINGS">FIG. 2</figref>, messages communicating the various identifiers with the bank server <b>15</b> may be routed through an NFC terminal rather than a cellular network.

0049At block <b>71</b> the bank server <b>15</b> may send the secure element identifier to a primary repository <b>114</b>, where it is received at block <b>72</b>. At block <b>73</b> the primary repository may determine which secondary repository tracks the TSM providers for the given secure element. At block <b>74</b> the identifier of the secondary repository is sent to the bank server <b>15</b>, where it is received at block <b>75</b>.

0050At block <b>85</b> the bank server <b>15</b> may locate the appropriate secondary repository <b>118</b> based on the identifier received at block <b>75</b> and send the secure element identifier and mobile wallet AID to that secondary repository <b>118</b>, where it is received at block <b>86</b>. At block <b>87</b> the secondary repository <b>118</b> may determine the TSM provider corresponding to the mobile wallet application on the mobile device <b>5</b> using the combination of secure element identifier, which is unique across all mobile devices, and the mobile wallet AID, which is unique for a given mobile device. At block <b>88</b> the central repository may send the TSM provider identity to the bank server <b>15</b>, where it is received at block <b>89</b>.

0051Based on the TSM provider identifier, at block <b>46</b> the bank server <b>15</b> may locate the TSM server <b>12</b> corresponding to the TSM provider and send a request to link the mobile device <b>5</b> to a credit card including the secure element identifier and the credit card number. In some aspects, the TSM provider identifier may be an IP address or domain name. In other aspects, the process of locating a TSM server based on a TSM server identifier may involve a broadcast message sent over one or more private networks of TSM servers. At block <b>47</b> the TSM server <b>12</b> may receive the request from the bank server <b>15</b>. At block <b>48</b> the TSM server <b>12</b> may transmit a message for the mobile device <b>5</b> instructing it to update the mobile wallet with the specific credit card information. At block <b>49</b> the message may be received by the mobile device <b>5</b> and the mobile wallet may be updated. In some aspects, the mobile wallet may determine that the message is properly encoded with a cryptographic key corresponding only to that particular mobile wallet SSD.

0052The distributed repositories may utilize a series of data tables, such as those seen in <figref idrefs="DRAWINGS">FIGS. 9A and 9B</figref>, which shows data structures that may be implemented on a computing device. The primary repository <b>114</b> may store a data table <b>115</b> shown in <figref idrefs="DRAWINGS">FIG. 9A</figref> which may be composed of a plurality of data records (shown as rows) <b>121</b>, <b>122</b>, <b>123</b> and <b>124</b> each made up of at least two data fields <b>112</b>, <b>116</b>. The primary repository data table <b>114</b> may contain a data field <b>112</b> for storing a secure element identifier and a data field <b>116</b> for storing a secondary repository identifier. The various secondary repositories <b>118</b> may store a data table <b>119</b> shown in <figref idrefs="DRAWINGS">FIG. 9B</figref> which may be composed of a plurality of data records (shown as rows) <b>125</b>, <b>126</b>, <b>127</b>, and <b>128</b> each made up of a plurality of data fields <b>99</b>, <b>112</b>, <b>93</b>. The secondary repository data table <b>119</b> may contain a data field <b>91</b> for storing a security domain AID, a data field <b>112</b> for storing a secure element identifier, and a data field <b>93</b> for storing a TSM provider identifier.

0053Typical mobile devices suitable for use with the various aspects may have in common the components illustrated in <figref idrefs="DRAWINGS">FIG. 10</figref>. For example, a mobile device <b>400</b> may include a processor <b>401</b> coupled to internal memory <b>402</b>, and a display <b>403</b>. Mobile devices typically also include a key pad <b>406</b>, a miniature keyboard, or a touch screen device, as well as menu selection buttons or rocker switches <b>407</b> for receiving user inputs.

0054Additionally, the mobile device <b>400</b> may have a long range antenna <b>404</b> for sending and receiving electromagnetic radiation that is connected to a wireless data link and/or cellular telephone transceiver <b>405</b> coupled to the processor <b>401</b>. In some implementations, the cellular transceiver <b>405</b> and portions of the processor <b>401</b> and memory <b>402</b> used for cellular telephone communications are collectively referred to as the air interface since it provides a data interface via a wireless data link.

0055Additionally, the mobile device <b>400</b> may have a short range antenna <b>409</b> for sending and receiving short range RF signals that is connected to a wireless data link transceiver <b>408</b> coupled to the processor <b>401</b>. For example, the wireless data link transceiver <b>408</b> may be a NFC transceiver, a Bluetooth® transceiver or a ZigBee® transceiver all of which are well known in the electronic communication arts.

0056The mobile device <b>400</b> may also include a secure element <b>410</b>, which may be coupled to the processor <b>401</b>. As described above, the secure element <b>410</b> may include a processor <b>411</b> that is configured with executable instructions to perform the functions of the secure element. The secure element <b>410</b> may also be coupled to the cellular transceiver <b>405</b> and be configured to send and receive cellular data messages without assistance or interference from the processor <b>401</b>. The secure element <b>410</b> may further be coupled to the NFC transceiver <b>408</b> and be configured to send and receive NFC messages without assistance or interference from the processor <b>401</b>.

0057The mobile device processor <b>401</b> and secure element processor <b>411</b> may be any programmable microprocessor, microcomputer or multiple processor chip or chips that can be configured by software instructions (applications) to perform a variety of functions, including the functions of the various aspects described herein. In some mobile devices, multiple processors <b>401</b> may be provided, such as one processor dedicated to wireless communication functions and one processor dedicated to running other applications. Typically, software applications may be stored in the internal memory <b>402</b> before they are accessed and loaded into the processor <b>401</b>. In some mobile devices, the processor <b>401</b> may include internal memory sufficient to store the application software instructions. The internal memory of the processor may include a secure memory <b>412</b> which is not directly accessible by users or applications and that is capable of recording MDINs and SIM IDs as described in the various aspects. As part of the processor, such a secure memory <b>412</b> may not be replaced or accessed without damaging or replacing the processor. In some mobile devices, additional memory chips (e.g., a Secure Data (SD) card) may be plugged into the device <b>400</b> and coupled to the processor <b>401</b>. In many mobile devices, the internal memory <b>402</b> may be a volatile or nonvolatile memory, such as flash memory, or a mixture of both. For the purposes of this description, a general reference to memory refers to all memory accessible by the processor <b>401</b>, including internal memory <b>402</b>, removable memory plugged into the mobile device, and memory within the processor <b>401</b> itself, the secure memory <b>412</b>, and portions of the secure element <b>410</b> such as the memory storing the serial number (i.e., the secure element identifier).

0058A number of the aspects described above may also be implemented with any of a variety of remote server devices, such as the server <b>2700</b> illustrated in <figref idrefs="DRAWINGS">FIG. 11</figref>. Such a server <b>2700</b> typically includes a processor <b>2701</b> coupled to volatile memory <b>2702</b> and a large capacity nonvolatile memory, such as a disk drive <b>2703</b>. The server <b>210</b> may also include a floppy disc drive and/or a compact disc (CD) drive <b>2706</b> coupled to the processor <b>2701</b>. The server <b>210</b> may also include a number of network ports <b>2704</b> coupled to the processor <b>2701</b> for establishing data connections with network circuits <b>2705</b>, such as the Internet or secure transaction networks.

0059The foregoing method descriptions and the process flow diagrams are provided merely as illustrative examples and are not intended to require or imply that the steps of the various aspects must be performed in the order presented. As will be appreciated by one of skill in the art the order of steps in the foregoing aspects may be performed in any order. Words such as “thereafter,” “then,” “next,” etc. are not intended to limit the order of the steps; these words are simply used to guide the reader through the description of the methods. Further, any reference to claim elements in the singular, for example, using the articles “a,” “an” or “the” is not to be construed as limiting the element to the singular.

0060The various illustrative logical blocks, modules, circuits, and algorithm steps described in connection with the aspects disclosed herein may be implemented as electronic hardware, computer software, or combinations of both. To clearly illustrate this interchangeability of hardware and software, various illustrative components, blocks, modules, circuits, and steps have been described above generally in terms of their functionality. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the overall system. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present invention.

0061The hardware used to implement the various illustrative logics, logical blocks, modules, and circuits described in connection with the aspects disclosed herein may be implemented or performed with a general purpose processor, a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. A general-purpose processor may be a microprocessor, but, in the alternative, the processor may be any conventional processor, controller, microcontroller, or state machine A processor may also be implemented as a combination of computing devices, e.g., a combination of a DSP and a microprocessor, a plurality of microprocessors, one or more microprocessors in conjunction with a DSP core, or any other such configuration. Alternatively, some steps or methods may be performed by circuitry that is specific to a given function.

0062In one or more exemplary aspects, the functions described may be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, the functions may be stored on or transmitted over as one or more instructions or code on a computer-readable medium. The steps of a method or algorithm disclosed herein may be embodied in a processor-executable software module executed which may reside on a computer-readable medium. Computer-readable media includes both computer storage media and communication media including any medium that facilitates transfer of a computer program from one place to another. A storage media may be any available media that may be accessed by a computer. By way of example, and not limitation, such computer-readable media may comprise RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other medium that may be used to carry or store desired program code in the form of instructions or data structures and that may be accessed by a computer. Also, any connection is properly termed a computer-readable medium. For example, if the software is transmitted from a website, server, or other remote source using a coaxial cable, fiber optic cable, twisted pair, digital subscriber line (DSL), or wireless technologies such as infrared, radio, and microwave, then the coaxial cable, fiber optic cable, twisted pair, DSL, or wireless technologies such as infrared, radio, and microwave are included in the definition of medium. Disk and disc, as used herein, includes compact disc (CD), laser disc, optical disc, digital versatile disc (DVD), floppy disk, and blu-ray disc where disks usually reproduce data magnetically, while discs reproduce data optically with lasers. Combinations of the above should also be included within the scope of computer-readable media. Additionally, the operations of a method or algorithm may reside as one or any combination or set of codes and/or instructions on a machine readable medium and/or computer-readable medium, which may be incorporated into a computer program product.

0063The preceding description of the disclosed aspects is provided to enable any person skilled in the art to make or use the present invention. Various modifications to these aspects will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other aspects without departing from the spirit or scope of the invention. Thus, the present invention is not intended to be limited to the aspects shown herein but is to be accorded the widest scope consistent with the following claims and the principles and novel features disclosed herein.