Abstract:
System, methods, and computer program products are provided for managing communications. A first applet and a second applet are operable receive and transmit application protocol data unit messages. The application protocol data unit messages include command-response message pairs. An application protocol data unit message is transmitted from the first applet to a second applet to trigger and establish a communication channel with a first device. Thus, messages may be comprehensively managed post-issuance. User experience is improved.

Description:
CROSS REFERENCE TO RELATED APPLICATION 
       [0001]    This application claims priority to U.S. Provisional Application No. 61/889,233, filed Oct. 10, 2013, and U.S. Provisional Application No. 61/901,662, filed on Nov. 8, 2013, the contents of which are incorporated herein by reference. 
     
    
     BACKGROUND 
       [0002]    1. Field 
         [0003]    The present invention relates to mobile networks, and more particularly to systems, methods, and computer program products for managing communications including establishing a communication channel. 
         [0004]    2. Related Art 
         [0005]    A service provider (SP) is a company, organization, entity, or the like, that provides services to customers or consumers. Examples of service providers include account-issuing entities such as merchants, card associations, banks, marketing companies, and transit authorities. A service may be an activity, capability, functionality, work, or use that is permitted or provided by a service provider such as a payment service, a ticketing service, a gift, offer or loyalty service, a transit pass service, and the like. A service may be used via a mobile device, for example, by utilizing one or more applets that make up that service. 
         [0006]    In a mobile environment that involves contactless transactions between mobile devices and service providers, information relating to the accounts and applets issued by the service providers is downloaded onto mobile devices in order to enable them to perform the contactless transactions. 
         [0007]    A trusted service manager (TSM) is typically an independent entity serving mobile network operators (MNOs) and account-issuing service providers, for example, by provisioning applets, such as contactless applets associated with the service providers, to mobile devices. Typical TSMs can distribute and manage the contactless applets remotely because they have access to secure elements (SEs) associated with a near field communication (NFC) enabled mobile device. 
         [0008]    A secure element is a platform onto which applets can be installed, upgraded, and managed. It consists of hardware, software, interfaces, and protocols that enable the secure storage of data such as credentials, and execution of applets for payment, authentication, and other services. An applet or set of applets may correspond to a service (e.g., payment, commerce, ticketing) offered by a service provider. 
         [0009]    The secure element may be implemented in different form factors such as a Universal Integrated Circuit Card (UICC), an embedded secure element, or NFC enablers such as a separate chip or secure device, which can be inserted into a slot on the mobile device. Typically a UICC is in the form of a subscriber identity module (SIM), which is controlled by the MNOs. An embedded secure element gives service providers the option to embed the secure element into the phone itself. One way in which secure element form factors are implemented is defined, for example, by GlobalPlatform, such as in GlobalPlatform Card Specification Versions 2.1.1, 2.2, and 2.2.1 (hereinafter “Global Platform”). 
         [0010]    A secure element may also be implemented outside of the mobile device with which it may be associated with. For example, such a secure element may be implemented in cloud-based, remote or virtual storage, and the like. 
         [0011]    A secure element may include one or more security domains (SDs), each of which includes a collection of data, such as packages, applets, and the like, that trust a common entity (e.g., are authenticated or managed by using a common security key or token). 
         [0012]    Security domains may be associated with service providers and may include service provider applets such as loyalty, couponing, credit card, and transit applets. 
         [0013]    A central TSM is a system for interfacing (e.g., communicating, beginning a dialog) service providers and secure elements, for example for service providers to upgrade services on a secure element, transmit scripts to be processed, and the like. An exemplary embodiment of a central TSM for managing communications between service providers and secure elements is described in more detail in U.S. patent application Ser. No. 13/653,160 entitled “Systems, Methods, and Computer Program Products for Interfacing Multiple Service Provider Trusted Service Managers and Secure Elements,” which is hereby incorporated by reference in its entirety. 
         [0014]    An enterprise service bus (ESB) is an architecture model for implementing the interactions and communications between entities (e.g., mobile device, SP TSMs, central TSM). 
         [0015]    Short Message Service (SMS) represents a way of communication by text message between communication systems such as mobile devices, using a standardized protocol such as Short Message Peer-to-Peer (SMPP). Using the SMPP protocol, SMS messages are sent through a Short Message Service Center (SMSC) of a subscriber&#39;s MNO, which acts as a center for storing, forwarding, converting, and delivering the messages. 
         [0016]    SMS may be used for multiple purposes including, for example, sending binary data content in messages, such as over-the-air (OTA) configuration messages for mobile device management purposes (e.g., phone configuration messages or notifications for voice mail, email, payments). 
         [0017]    Traditionally, OTA programming (e.g., communications using a wireless medium) capabilities include the ability to request certain action to be taken on a secure element associated with a mobile device through binary class 2 SMS messages (referred to sometimes simply as binary SMS messages). For example, requested actions may include commands to: remotely configure mobile devices, send software and operating system (OS) updates to mobile devices, remotely lock and wipe devices, and remotely troubleshoot mobile devices. 
         [0018]    The OTA commands are sent as binary class 2 SMS messages, for example, via Hypertext Transfer Protocol (HTTP) or Hypertext Transfer Protocol Secure (HTTPS). The binary SMS message has a maximum of 140 bytes of usable data. This amount of bytes is typically split into two components: a user data header (UDH) and actual content data. The UDH is used to inform mobile devices, for example, about the type of data being sent. 
         [0019]    Such binary SMS messaging is considered to be less reliable than other forms of communication due to, for example, low bandwidth and variable latency. Periodically, for instance, in a case of message delivery failure (e.g., due to an unreliable or slow SMS network), a user device must wait an extended period of time to receive feedback from a system requesting an action. Generally, users of such devices do not wish to depend on a slow, unreliable SMS network, particularly for business-critical processes. 
         [0020]    In addition, some operations performed by a secure element are not visible to the user of the device, making it difficult to track the operations of the secure element. For example, the class 2 SMS message is directly forwarded to a secure element, and is not displayed on the display of the mobile device. Therefore, a user has no way of knowing if the class 2 SMS message(s) sent OTA has been properly executed. 
         [0021]    That is, because the MNO carrier is in control, in OTA operations, it is difficult for the user to validate whether another device has received a message, or if an error or failure occurred during delivery of the message, for example. 
         [0022]    One technical challenge involves providing the user with increased visibility to the data arriving at the secure element and increased control over the components associated with establishing a secure communication channel. 
       BRIEF DESCRIPTION 
       [0023]    The present invention provides systems, methods, and computer program products for managing communications including establishing a communication channel and verifying secure channel establishment by using APDU commands. 
         [0024]    In one embodiment, a system (e.g., a secure element) for managing communications includes a processor coupled to a memory (e.g., on the secure element). The memory stores a first applet and a second applet. The first applet receives and transmits application protocol data unit (APDU) messages. The processor receives from a mobile device, by the first applet, a first APDU message, the first APDU message including payload data, transmits the first APDU message from the first applet to the second applet, and establishes, by the second applet, a communication channel with a first device. The payload data includes at least one of a host address, a recipient internes protocol address and an identification number. 
         [0025]    In another embodiment, a method for managing communications includes receiving from a mobile device, by a first applet, a first application protocol data unit (APDU) message, the first APDU message including payload data, transmitting the first APDU message from the first applet to a second applet, and establishing, by the second applet, a communication channel with a first device. The payload data includes at least one of a host address, a recipient internes protocol address and an identification number. 
         [0026]    In another embodiment, a non-transitory computer-readable medium having stored thereon sequences of instructions, the sequences of instructions including instructions, which, when executed by a computer system cause the computer to: receive from a mobile device, by a first applet, a first application protocol data unit (APDU) message, transmit the first APDU message from the first applet to a second applet, and establish, by the second applet, a communication channel with a first device. The payload data includes at least one of a host address, a recipient internet protocol address and an identification number. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0027]    The features and advantages of the present invention will become more apparent from the detailed description set forth below when taken in conjunction with the following drawings. 
           [0028]      FIG. 1  is a diagram of a system for interfacing between service providers and mobile devices having secure elements according to an exemplary embodiment. 
           [0029]      FIG. 2  is a diagram of a system for interfacing between a trusted service manager and a mobile device having a secure element according to an exemplary embodiment. 
           [0030]      FIG. 3  is a sequence diagram illustrating a sequence for providing establishing a communication channel according to an exemplary embodiment. 
           [0031]      FIG. 4  is a block diagram of an exemplary system useful for implementing the present invention. 
       
    
    
     DETAILED DESCRIPTION 
     Overview 
       [0032]    The example embodiments presented herein describe systems, methods, and computer program products for managing communications including establishing a communication channel, which are described herein in terms of an example system in a mobile commerce environment. 
         [0033]    Generally, a system such as an ESB, communicating with a TSM can be used to send the push notifications. 
         [0034]    The terms “applet,” “application,” and/or the plural form of these terms are used interchangeably herein to refer to an applet (functioning independently or in conjunction with other applets) or set or subset of instructions or code, which when executed by one or more processors (e.g., in a mobile device, card reader, terminal, point of sale (POS) system, or server) causes the processor(s) to perform specific tasks. It should be understood that “applets” as used herein refers to generic or instances of applets on a secure element. 
         [0035]    In one exemplary embodiment, the TSM may transmit a request to the ESB to trigger an action to be performed on a secure element. In response, the TSM transmits SMPP payload data with certain parameters included in the request (e.g., a host address, a recipient internet protocol address, and an identification number) to the ESB. The ESB in turn forwards the SMPP payload to an SMS aggregator, which sends a push notification to the mobile device. 
         [0036]    In another exemplary embodiment, the first applet queries the second applet to determine whether a communication channel has been established successfully, without the need to rely on intermediary sources such as an MNO carrier, for example, to send a push notification. 
         [0037]    As a result, visibility regarding the data arriving at the secure element and control over the components associated with establishing a secure communication channel in executing a requested action to be performed on the secure element is increased relative to, for example, a system waiting for a response from the MNO carrier. Moreover, message delays and losses can be minimized or eliminated. 
       System 
     A. System Overview 
       [0038]      FIG. 1  is a diagram of an exemplary system  100  for interfacing between service providers and mobile devices having secure elements according to an exemplary embodiment. As shown in  FIG. 1 , system  100  includes an ESB  101 , which is communicatively coupled to a server  102  (which may also be referred to as a “wallet server” or “mobile wallet server”) and a central TSM  103 . 
         [0039]    In exemplary embodiments described herein, the central TSM  103  includes a processor and a memory (e.g., a database) and handles, for example, the installation and upgrading of services on secure elements. 
         [0040]    The ESB  101  is communicatively coupled to SP systems  105 - 1 ,  105 - 2 , . . . ,  105 - n  (collectively “ 105 ”) via a communications network  107 . Communications network  107  may be a virtual private network (VPN), a network using Transmission Control Protocol/Internet Protocol (TCP/IP) standards, or the like. 
         [0041]    Generally, the ESB  101  manages interactions between SP systems  105  and mobile devices  104 - 1 ,  104 - 2 , . . . ,  104 - n  (collectively “ 104 ”), and grants the SP systems the ability to efficiently and securely communicate with the mobile devices  104  in order to, for example, upgrade a service without the need for directly communicating with each of the mobile devices  104 . 
         [0042]    In an example embodiment, the ESB  101  is hardware and/or software that is implemented to serve as an intermediary between SP systems  105  and mobile devices  104 , for example, for processing requests (e.g., to upgrade a service) within a mobile commerce system. 
         [0043]    In another example embodiment, the processes and functions described below with reference to an ESB (e.g., ESB  101 ) can be performed by a TSM (e.g., central TSM  103 ). 
         [0044]    The server  102  and the central TSM  103  are each communicatively coupled to mobile devices  104  via corresponding mobile networks  106 - 1 ,  106 - 2 , . . . ,  106 - n  (collectively “ 106 ”). Each of the mobile networks  106  is operated by a corresponding MNO  106   a - 1 ,  106   a - 2 , . . . ,  106   a - n  (collectively “ 106   a ”). 
         [0045]    The server  102  and the central TSM  103  communicate with mobile devices  104  via the mobile networks  106 , using security protocols such as Global Platform secure channel protocol, SSL, TLS, or the like. Mobile networks  106  may be mobile phone cellular networks, radio networks, or the like. 
         [0046]    In one exemplary embodiment, the ESB  101 , server  102  and central TSM  103  may be part of a single system architecture managed by a single provider, such as a mobile wallet provider. 
         [0047]    Each of the mobile devices  104  includes a corresponding secure element  104   a - 1 ,  104   a - 2 , . . . ,  104   a - n  (collectively “ 104   a ”), and a corresponding mobile wallet (not shown). 
         [0048]    A mobile wallet is an application stored in a non-transitory memory of a mobile device including instructions which, when executed by the processor of a mobile device, cause the mobile device to act as an instrument, for example, for processing contactless transactions or for processing commerce information such as offer or loyalty information. A mobile wallet and a corresponding secure element may communicate using International Organization for Standardization (ISO)  7816  commands, in order to conduct contactless transactions. 
         [0049]    Each of the mobile devices  104  may include a user interface such as a display for receiving inputs from and outputting data to a user. 
       B. Mobile Device 
       [0050]      FIG. 2  depicts a diagram  200  of a mobile device having a secure element for use in remote transactions according to an exemplary embodiment. It should be understood that the secure element may be implemented in different form factors, including as a cloud-based or virtual secure element external to the mobile device (e.g., host card emulation (HCE)). 
         [0051]    As shown in  FIG. 2 , mobile device  201  (e.g.,  FIG. 1 , mobile device  104 - 1 ) includes a mobile wallet  202 , secure element  207  (e.g.,  FIG. 1 , secure element  104   a - 1 ), an OpenMobile API  203 , a modem  204 , a memory  205 , and a processor  206 . 
         [0052]    In one exemplary embodiment, the mobile wallet  202  is a mobile wallet application that includes instructions which, when executed by the processor  206  of the mobile device  201 , cause the mobile device to act as an instrument, for example, for processing transactions such as contactless transactions (e.g., NFC contactless payments). The mobile wallet  202  provides an interface for receiving inputs and displaying outputs. The mobile wallet  202  communicates with the secure element  207  and applets stored on the secure element  207  using commands transmitted via interfaces such as application programming interfaces (APIs). 
         [0053]    The mobile wallet  202  also includes a secure element manager library (SE manager library)  202   a . The SE manager library  202   a  provides the mobile wallet  202  with means to communicate with other systems (e.g., server) using, for example, high-level APIs. 
         [0054]    OpenMobile API provides a set of service layer classes with high-level methods for secure element operations. OpenMobile API Specification (e.g., Version 3.0) specifies how mobile applications may access different secure elements in a mobile device, such as a UICC or an embedded secure element, and provides interface definitions and Unified Modeling Language (UML) diagrams to support implementation across a variety of mobile platforms and programming languages. In one example, a Secure Element Evaluation Kit (SEEK) layer may be used as the OpenMobile API. SEEK layer is a software layer that provides a mechanism for an application to communicate with secure elements, SIM cards, or other device encryption modules (e.g., secure element  207 ). 
         [0055]    Modem  204  is a cellular baseband modem that is used for wireless communications. Mobile devices typically support a number of cellular protocols including GSM, 3G, 4G and LTE. Often, these protocols require a significant amount of CPU power to interpret, process and generate packets which are transmitted to a network provider. This processing is handled by the modem  204 , which is a separate chip included in the mobile device that communicates with the main processor  206  and/or the memory  205  (e.g., a multimode LTE modem “SC9620,” designed for use in 4G smartphones). 
         [0056]    Modem  204  is responsible for setting up a connection to a secure element in a mobile device. This connection uses remote communication technology, such as GPRS (General Packet Radio Service), UMTS (Universal Mobile Telecommunications System), or CDMA (Code Division Multiple Access). 
         [0057]    Although not illustrated in  FIG. 2 , the mobile device  201  may also include a contactless frontend (CLF) and a user interface such as a display. A CLF is circuitry which handles the analog aspect of contactless or NFC communications and the communication protocol layers of a contactless transmission link. 
         [0058]    The secure element  207  includes or has stored thereon a first applet and a second applet. The first applet is used to communicate with the second applet. In one embodiment, the first applet is a Bearer Independent Protocol (BIP) applet  256 , and the second applet is an Admin Agent applet  260   b , which is stored in a Link Platform Operator Security Domain (LPO SD)  260   a  in the secure element  207 . 
         [0059]    The Administration Agent (Admin Agent)  260   b  is an applet that manages communications from the secure element  207  and other systems such as a TSM (e.g.,  FIG. 2 , TSM  208 ;  FIG. 1 , central TSM  103 ). The LPO SD  260   a  stores, manages and hosts keys for encrypting and/or decrypting data sent to and received from other systems, such as the TSM. It should be understood that the Admin Agent  260   b  and LPO SD  260   a  may act together or separately to manage a connection from the secure element  207  to other systems. It should also be understood that the Admin Agent  206   b  may be implemented within or outside of the LPO SD  260   a.    
         [0060]    The communication methods used by the LPO SD  260   a  typically are standardized by the European Telecommunications Standards Institute (ETSI). The ETSI prescribes a specification for the LPO SD  260   a  in which a communication channel is established using binary SMS messages, such as binary class 2 SMS messages. 
         [0061]    Binary class 2 SMS messages are messages directed to and/or received from secure elements, and may be stored on secure elements. The binary SMS message is provided to the secure element  207  using a card application toolkit (e.g., SIM Application Toolkit (STK)) command such as an ENVELOPE (e.g., SMS-PP DOWNLOAD) command sent over-the-air. An ENVELOPE is a communication used to inform a secure element of an event that is occurring. An external entity (e.g., TSM  208 ) has the ability to push the binary SMS message to the mobile device  201  to establish the connection. The user, mobile device, and/or system initiating the delivery of the binary SMs message is/are not notified of the receipt of the binary SMS message by the mobile device  201 . In addition, the LPO SD  260   a  do not establish channels of communication between the secure element  207  and other systems using APDUs (e.g., command APDU). 
         [0062]    The BIP applet  256  serves as a proxy between the mobile device  201  and LPO SD  260   a , via which APDU messages may be sent and received to establish communications channels between the secure element  207  and other systems. Unlike binary SMS messages (e.g., class 2 messages), a response message in the form of a response APDU is sent and/or returned to a system and/or entity that transmitted the APDU. That is, binary SMS messages do not provide for tracking, managing and/or receiving updates regarding the status of the SMS message and the information communicated therein. 
         [0063]    Although not illustrated in  FIG. 2 , the secure element  207  may also include additional applets such as one or more payment applets and commerce applets. A commerce applet may operate as a storage container and an interface for offer data management, and may be used, for example, to redeem an offer during a remote transaction. A payment applet corresponds to a service provider, and may store sensitive service provider data, such as transaction data (e.g., account number, account verification code, account holder name, expiration date) associated with a service provider account issued to a consumer. In one exemplary embodiment, a payment applet may be used to make contactless payments using a mobile wallet. 
       Process 
     C. Establishing Communication Channel 
       [0064]      FIG. 3  is a sequence diagram illustrating a sequence for establishing a communication channel according to an exemplary embodiment. 
         [0065]    When an action is to be performed on a secure element, a communication channel is established between the secure element and the system requesting the action. The secure element and system requesting the action in turn communicate over the established channel to perform the action. The action may include a number of different requests for processing such as installing a payment application, activating a mobile wallet, changing a passcode, and the like. 
         [0066]    In one exemplary embodiment shown in  FIG. 3 , a communication channel is established between a TSM  303  (e.g.,  FIG. 1 , central TSM  103 ) and a secure element  302  (e.g.,  FIG. 1 , secure element  104   a ;  FIG. 2 , secure element  207 ). The communication channel may be used to communicate a request for an action to be performed on the secure element  302 . 
         [0067]    At step  352 , the TSM  303  transmits a message to the ESB  304  (e.g.,  FIG. 1 , ESB  101 ). The message may be an SMPP message including payload data. The payload data includes at least a host address (e.g., an identifier or location in the LPO SD where the message is to be sent to), a recipient internet protocol (IP) address (e.g., an IP address of the TSM where the handset is to be connected to), and an identification number (e.g., an identifier for a workflow indicating that the TSM is ready). The payload data may also include, for example, the internet protocol to be used during the established connection (e.g., IPv4, IPv6). 
         [0068]    At step  354 , the ESB  304  receives the message from the TSM  303  and forwards the message including the payload data to a message aggregator such as an SMS aggregator  305 . Although not illustrated in  FIG. 3 , the ESB  304  may convert the message from SMPP format to HTTP format. 
         [0069]    In turn, an SMS aggregator  305  or similar administrative system sends, at step  356 , a push notification to the mobile wallet (e.g., mobile wallet application) deployed on the mobile device  301  (e.g.,  FIG. 1 , mobile device  104 - 1 ). The push notification sent at step  356  may include at least a portion of the payload data sent by the TSM  303  at step  352 . 
         [0070]    The SMS aggregator is used to aggregate SMS messages for transmission to one or more recipients. The SMS aggregator provides connectivity to a variety of systems or devices on a mobile network, and manages the sending and receiving of SMS messages to and from devices across a variety of different wireless service provider networks, each of which may be using a different communication protocol. 
         [0071]    The SMS aggregator may include one or more gateways that are each configured to communicate with cellular base stations operated by various service providers using the appropriate communication protocols for each service provider. 
         [0072]    The push notification sent at step  356  is used to transmit notifications and/or information to systems and/or users. Such notifications may be, for example, notifications regarding an action to be taken on the secure element. The push notification sent at step  356  includes information identifying the host address, the recipient internes protocol (IP) address, and the identification number. 
         [0073]    A notification of an action to be performed on the secure element  302  is received at the mobile wallet  301  either by a “push” or “pull” action. 
         [0074]    In a “push” action, a trusted service manager (e.g., TSM  303 ) initiates a transaction by sending a notification (e.g., pushing) to a wallet application (e.g.,  FIG. 3 , mobile wallet  301 ) on a consumer device (e.g., mobile device). In a “pull” action, the transaction is initiated by a mobile device transmitting a request for information (e.g., pulling). 
         [0075]    At step  358 , the mobile wallet  301  transmits, an APDU (e.g., trigger or command APDU) to a first applet (e.g.,  FIG. 3  at  302   a ) on the secure element (e.g.,  FIG. 3  at  302 ). 
         [0076]    APDUs are communication units used to exchange information between systems and secure elements (e.g., secure element  302 ). Generally, there are two categories of APDUs: a command APDU and a response APDU. The format and standards for APDUs are defined by ISO/IEC 7816 standards, managed jointly by the International Organization for Standardization (ISO) and the International Electrotechnical Commission (IEC). 
         [0077]    In an exemplary embodiment shown in  FIG. 3 , the first applet is a Bearer Independent Protocol (BIP) applet  302   a . A BIP is a technology in mobile communication, such an applet, which provides a secure element with access to data and/or services through any of (and independent of) the data bearers (e.g., 3G, 4G, LTE) supported by the mobile device. A bearer service is a service that allows transmission of information signals between network interfaces. Bearer services range from the transfer of low speed messages (e.g., 300 bps) to high speed data signals (e.g., 10+ Gbps). 
         [0078]    The APDU transmitted at step  360  includes instructions to establish a communication channel, such as an HTTP or HTTPS session with the TSM  303 . 
         [0079]    HTTP or HTTPS session status counters are maintained and or stored by the BIP applet  302   a  and/or the Admin Agent  302   b  to count the occurrence of certain events, including: (1) a number of times an HTTP or HTTPS session initiation is requested, (2) a number of times no error is reported when an HTTP or HTTPS session is requested, (3) a number of times an error is reported when an HTTP or HTTPS session is requested, and (4) a number of times no report is found at all when an HTTP or HTTPS session is requested. 
         [0080]    The information contained in an APDU (e.g., at step  358 ,  360 ) includes hexadecimal data representing a header (e.g., including CLA, INS) and a body of the message of variable length (e.g., including Lc, data, Le). 
         [0081]    An example structure of the APDU transmitted at step  360 , which establishes the HTTP or HTTPS Admin Session, including the parameters passed in the APDU sent step  358 , is described in more detail below in Table 1. 
         [0000]    
       
         
               
               
               
             
           
               
                   
                 TABLE 1 
               
               
                   
                   
               
               
                   
                 Field 
                   
               
               
                   
                 name 
                 Description 
               
               
                   
                   
               
             
             
               
                   
                 CLA 
                 Class of instruction - indicates the type of command 
               
               
                   
                 INS 
                 Instruction code - indicates the specific command 
               
               
                   
                   
                 For example: 
               
               
                   
                   
                 Establish communication channel 
               
               
                   
                   
                 Read HTTP or HTTPS status counter values 
               
               
                   
                 Command 
                 Information carried by or included in the command 
               
               
                   
                 Data 
               
               
                   
                 Lc 
                 Length of data body in hexadecimal bytes 
               
               
                   
                 Le 
                 Expected length of return data in hexadecimal bytes 
               
               
                   
                   
               
             
          
         
       
     
         [0082]    At step  360 , the BIP applet  302   a  transmits an APDU (e.g., HTTP or HTTPS Admin Session APDU) to the Admin Agent  302   b . The APDU transmitted at step  360  includes a request to establish an HTTP or HTTPS Admin Session and an HTTP or HTTPS session is triggered. The HTTP or HTTPS Admin Session APDU includes trigger parameters, which are passed to a second applet (e.g., Admin Agent applet) on the secure element (e.g.,  FIG. 3 , step  302 ). The HTTP or HTTPS Admin Session APDU may include one or more of the following parameters (e.g., trigger parameters): a host address, a recipient IP address, and an identification number, which are used to process the connection request at step  362 . 
         [0083]    In an exemplary embodiment, the Admin Agent and LPO SD  302   b  work concurrently. 
         [0084]    The Admin Agent is a component that is capable of managing an OTA, over HTTP or HTTPS, connection between a security domain (e.g., LPO SD  302   b ) and a first device (e.g., TSM  303 ). 
         [0085]    At step  362 , the Admin Agent  302   b  transmits a connection request including the trigger parameters to the TSM  303 . 
         [0086]    In turn, the TSM  303  performs an authentication process using an authentication protocol such as a SSL (Secure Sockets Layer) and/or a TLS (Transport Layer Security) handshake protocol. The authentication process includes a client sending a message to a server and the server responding with information needed to authenticate itself. The client and server agree on various parameters used to establish the security of the connection. 
         [0087]    At the conclusion of the authentication process, if successful, a handshake procedure is completed and session keys are exchanged between the secure element  302  and the TSM  303 , which can in turn communicate securely using agreed-upon session keys. This concludes the handshake and begins the secured connection. 
         [0088]    The TSM  303 , in turn, processes the connection request and transmits, at step  364 , a connection response to the Admin Agent  302   b . The connection response indicates, for example, whether the connection, channel and/or session requested at step  360  was successfully established. 
         [0089]    The Admin Agent  302   b  receives a connection response from the TSM  303  and, in turn, at step  366 , transmits a response APDU to the BIP applet  302   a  on the secure element  302 . The response APDU includes at least a portion of the connection response information received at step  364 . In turn, the BIP applet  302   a  transmits the response APDU, at step  368 , to the mobile wallet  301 . 
         [0090]    The APDU protocol used to create and transmit messages (e.g., requests, commands, responses) provides messages and information that can be used to track and or manage the progress of an action requested in an APDU. For example, the response APDU includes information in the form of data and status words (e.g., SW1, SW2) indicating the result (e.g., success, failure) of the execution of the command APDU (e.g., whether a communication channel was established successfully). 
         [0091]    The information contained in a response APDU (e.g., the response APDUs transmitted in steps  366  and  368 ) includes hexadecimal data representing a body of variable length and two following bytes (e.g., status bytes SW1 and SW2). 
         [0092]    An example structure of the response APDU is described in more detail below in Table 2. 
         [0000]    
       
         
               
               
             
           
               
                 TABLE 2 
               
               
                   
               
               
                 Field 
                   
               
               
                 Name 
                 Description 
               
               
                   
               
             
             
               
                 Response 
                 Information included in and/or carried by a response 
               
               
                 Data 
                 For example: 
               
               
                   
                 Applet version number 
               
               
                   
                 Count of times HTTP or HTTPS session is requested 
               
               
                   
                 Count of times HTTP or HTTPS Session No Error is reported 
               
               
                   
                 Count of times HTTP or HTTPS session Error is reported 
               
               
                   
                 Count of times no report for HTTP or HTTPS session is 
               
               
                   
                 found 
               
               
                 SW1, 
                 Command processing status 
               
               
                 SW2 
                 For example: 
               
               
                   
                 ‘90’ ‘00’: a successful execution of the APDU 
               
               
                   
                 ‘62’ ‘02’: an unsuccessful execution of the APDU 
               
               
                   
               
             
          
         
       
     
         [0093]    This command-response message pair (e.g., command APDU, response APDU) allows the mobile device  301  (or secure element  302 ) and the TSM  303  (or any other system seeking to establish a communication channel), via Admin Agent  302   b , to establish a secure communication channel). 
         [0094]    The communication channel may be established upon request, for example, by the Admin Agent  302   b  to a modem or other component (e.g., antenna) of the mobile device on which the Admin Agent  302   b  is deployed. Once the communication channel (e.g.,  FIG. 2  at  262 ) is established, at step  370 , between the secure element  302  and the TSM  303 , information (e.g., encrypted APDUs) may be transmitted securely between them. 
         [0095]    If the communication channel disconnects or an error occurs during delivery of the APDU message, the TSM  303  may reattempt to connect to the BIP applet  302   a  and resend any data by repeating steps  352  to  368 . 
         [0096]    If the session continues to disconnect or the error persists during the transmission of the data after a predetermined number (e.g., three) of tries, the TSM  303  will log the attempt as a failure and notification of the failure is sent to involved systems (e.g., SE  302 , mobile wallet  301 ). 
         [0097]    If the data is successfully received by the SE  302 , the Admin Agent  302   b  may transmit the data to the BIP applet  302   a , at step  366 , via a response APDU. The response APDU is provided, in turn, at step  368 , to the mobile wallet  301 . A response APDU is returned to the system and/or entity that transmitted the command APDU (e.g., to the secure element  302 ), either confirming that the communication channel was established successfully (e.g., with status words ‘90’ ‘00’ indicating a successful execution of the APDU), or informing the mobile device that the communication channel could not be established. 
         [0098]    The BIP applet  302   a  allows for content that is traditionally sent as a binary (e.g., class 2) SMS message, by an OTA operation, to be delivered via an APDU. By virtue of using APDUs, a system device can validate whether a message has arrived at the secure element  302 , for example, through the receipt of response APDUs. A system or device can also determine whether the Admin Agent and/or LPO SD  302   b  has successfully created a channel with the TSM  303 , or whether a problem occurred in the process. 
         [0099]    In one example embodiment, the BIP applet  302   a  is able to query the Admin Agent  302   b  to determine whether a communication channel was established successfully (e.g., with TSM  303 ) without the need to rely on intermediary sources such as an MNO carrier, for example, to send a push notification. 
       D. Push or Pull Actions 
       [0100]    A communication session can be initiated by either a “push” or “pull” action. 
         [0101]    Depending on the type of use case, either a push action from the TSM or a trigger from the mobile wallet (e.g., mobile wallet application) for a pull action is performed. 
         [0102]    For some use cases (e.g., wallet activation), fetching (e.g., pulling) trigger parameters from the wallet server is the preferred option. For other use cases (e.g., lost phone), the push option for receiving trigger parameters through a push notification server (e.g., Google Cloud Messaging (GCM) or Apple Push Notification Server (APNS)) may be preferable. 
         [0103]    Actionable items (e.g., uses cases) and their corresponding preferred triggering method are shown in more detail below in Table 3. 
         [0000]    
       
         
               
               
               
             
           
               
                   
                 TABLE 3 
               
               
                   
                   
               
               
                   
                 Use Case 
                 Preferred Action 
               
               
                   
                   
               
             
             
               
                   
                 Wallet activation 
                 Pull 
               
               
                   
                 Card provisioning (e.g., add card) 
                 Pull 
               
               
                   
                 Close card 
                 Push 
               
               
                   
                 Reset wallet PIN 
                 Pull 
               
               
                   
                 Reset consumer portal PIN 
                 Push 
               
               
                   
                 Handset and/or OS change 
                 Pull 
               
               
                   
                 Secure element change 
                 Push 
               
               
                   
                 Terminate wallet 
                 Push 
               
               
                   
                 Suspend wallet 
                 Push 
               
               
                   
                 Resume wallet 
                 Push 
               
               
                   
                 Applet update 
                 Pull 
               
               
                   
                 Suspend card 
                 Push 
               
               
                   
                 Resume card 
                 Push 
               
               
                   
                   
               
             
          
         
       
     
       E. Example Computer-Readable Implementation 
       [0104]    The example embodiments described above such as, for example, the systems and procedures depicted in or discussed in connection with  FIGS. 1-3  or any part or function thereof, may be implemented by using hardware, software or a combination of the two. The implementation may be in one or more computers or other processing systems. While manipulations performed by these example embodiments may have been referred to in terms commonly associated with mental operations performed by a human operator, no human operator is needed to perform any of the operations described herein. In other words, the operations may be completely implemented with machine operations. Useful machines for performing the operation of the example embodiments presented herein include general purpose digital computers or similar devices. 
         [0105]      FIG. 4  is a block diagram of a general and/or special purpose computer  400 , in accordance with some of the example embodiments of the invention. The computer  400  may be, for example, a user device, a user computer, a client computer and/or a server computer, among other things. 
         [0106]    The computer  400  may include without limitation a processor device  430 , a main memory  435 , and an interconnect bus  437 . The processor device  430  may include without limitation a single microprocessor, or may include a plurality of microprocessors for configuring the computer  400  as a multi-processor system. The main memory  435  stores, among other things, instructions and/or data for execution by the processor device  430 . The main memory  435  may include banks of dynamic random access memory (DRAM), as well as cache memory. 
         [0107]    The computer  400  may further include a mass storage device  440 , peripheral device(s)  442 , portable storage medium device(s)  446 , input control device(s)  444 , a graphics subsystem  448 , and/or an output display  449 . For explanatory purposes, all components in the computer  400  are shown in  FIG. 4  as being coupled via the bus  437 . However, the computer  400  is not so limited. Devices of the computer  400  may be coupled via one or more data transport means. For example, the processor device  430  and/or the main memory  435  may be coupled via a local microprocessor bus. The mass storage device,  440 , peripheral device(s)  442 , portable storage medium device(s)  446 , and/or graphics subsystem  448  may be coupled via one or more input/output (I/O) buses. The mass storage device  440  may be a nonvolatile storage device for storing data and/or instructions for use by the processor device  430 . The mass storage device  440  may be implemented, for example, with a magnetic disk drive or an optical disk drive. In a software embodiment, the mass storage device  440  is configured for loading contents of the mass storage device  440  into the main memory  435 . 
         [0108]    The portable storage medium device  446  operates in conjunction with a nonvolatile portable storage medium, such as, for example, a compact disc read only memory (CD-ROM), to input and output data and code to and from the computer  400 . In some embodiments, the software for storing an internal identifier in metadata may be stored on a portable storage medium, and may be inputted into the computer  400  via the portable storage medium device  446 . The peripheral device(s)  442  may include any type of computer support device, such as, for example, an input/output (I/O) interface configured to add additional functionality to the computer  400 . For example, the peripheral device(s)  442  may include a network interface card for interfacing the computer  400  with a network  439 . 
         [0109]    The input control device(s)  444  provide a portion of the user interface for a user of the computer  400 . The input control device(s)  444  may include a keypad and/or a cursor control device. The keypad may be configured for inputting alphanumeric characters and/or other key information. The cursor control device may include, for example, a mouse, a trackball, a stylus, and/or cursor direction keys. In order to display textual and graphical information, the computer  400  may include the graphics subsystem  448  and the output display  449 . The output display  449  may include a cathode ray tube (CRT) display and/or a liquid crystal display (LCD). The graphics subsystem  448  receives textual and graphical information, and processes the information for output to the output display  449 . 
         [0110]    Each component of the computer  400  may represent a broad category of a computer component of a general and/or special purpose computer. Components of the computer  400  are not limited to the specific implementations provided here. 
         [0111]    Portions of the example embodiments of the invention may be conveniently implemented by using a conventional general purpose computer, a specialized digital computer and/or a microprocessor programmed according to the teachings of the present disclosure, as is apparent to those skilled in the computer art. Appropriate software coding may readily be prepared by skilled programmers based on the teachings of the present disclosure. 
         [0112]    Some embodiments may also be implemented by the preparation of application-specific integrated circuits, field programmable gate arrays, or by interconnecting an appropriate network of conventional component circuits. 
         [0113]    Some embodiments include a computer program product. The computer program product may be a storage medium or media having instructions stored thereon or therein which can be used to control, or cause, a computer to perform any of the procedures of the example embodiments of the invention. The storage medium may include without limitation a floppy disk, a mini disk, an optical disc, a Blu-ray Disc, a DVD, a CD-ROM, a micro-drive, a magneto-optical disk, a ROM, a RAM, an EPROM, an EEPROM, a DRAM, a VRAM, a flash memory, a flash card, a magnetic card, an optical card, nanosystems, a molecular memory integrated circuit, a RAID, remote data storage/archive/warehousing, and/or any other type of device suitable for storing instructions and/or data. 
         [0114]    Stored on any one of the computer readable medium or media, some implementations include software for controlling both the hardware of the general and/or special computer or microprocessor, and for enabling the computer or microprocessor to interact with a human user or other mechanism utilizing the results of the example embodiments of the invention. Such software may include without limitation device drivers, operating systems, and user applications. Ultimately, such computer readable media further include software for performing example aspects of the invention, as described above. 
         [0115]    Included in the programming and/or software of the general and/or special purpose computer or microprocessor are software modules for implementing the procedures described above. 
         [0116]    While various example embodiments of the invention have been described above, it should be understood that they have been presented by way of example, and not limitation. It is apparent to persons skilled in the relevant arts) that various changes in form and detail can be made therein. Thus, the invention should not be limited by any of the above described example embodiments, but should be defined only in accordance with the following claims and their equivalents. 
         [0117]    In addition, it should be understood that the figures are presented for example purposes only. The architecture of the example embodiments presented herein is sufficiently flexible and configurable, such that it may be utilized and navigated in ways other than that shown in the accompanying figures. Further, the purpose of the Abstract is to enable the U.S. Patent and Trademark Office and the public generally, and especially the scientists, engineers and practitioners in the art who are not familiar with patent or legal terms or phraseology, to determine quickly from a cursory inspection the nature and essence of the technical disclosure of the application. The Abstract is not intended to be limiting as to the scope of the example embodiments presented herein in any way. It is also to be understood that the procedures recited in the claims need not be performed in the order presented.