Patent Description:
Over the last decade, members of the mobile phone industry, including mobile handset manufacturers, Subscriber Identification Module (SIM) card manufacturers, and Mobile Network Operators (MNOs), have developed standards for related technologies: embedded SIM (eSIM) cards and embedded universal integrated circuit cards (eUICCs). These components, when integrated into a mobile handset, provide an interface for receiving and responding to network and handset requests. These standards define use, format, functionality, and associated profiles for the eSIM/eUICC. A secure element chip is capable of storing more than one of these profiles, but only one profile is able to be active at any given time, allowing the active profile to respond to network and/or terminal requests while inactive profile(s) are prevented from handling network and/or terminal requests.

In addition, for many years now, handset manufacturers have produced handsets that include at least one (and often multiple) physical expansion slots for using multiple removable SIM/UICCs. Integrating more than one physical slot for a SIM card is a large cost factor for the handset manufacturers, whether it is an expansion slot or an embedded physical slot.

<CIT> relates to a method and an apparatus for downloading at least one communication service to a terminal and installing and enabling the same in a wireless communication system such that communication connection is established. <CIT> relates to a recording medium and method of preparing a recording medium. <NPL>, relates to work on the definition of a mechanism that allows the terminal to access multiple logical secure elements over one single physical interface based on ISO/IEC <NUM> specifications.

A terminal may be configured to receive messages from various interfaces and forward them in a same message stream. One or more embodiments generate a message stream configured to indicate a source of the various messages within the message stream without each message identifying the source. The terminal, that forwards messages received from various interfaces, inserts interface switch indicators into the message stream such that the interface switch indicators are inserted between sets of messages received from different interfaces.

In one or more embodiments, a smart card (e.g., of the mobile handset) receives a message stream that includes sets of messages and interface switch indicators therein. The smart card delivers messages from the message stream to a particular logical partition of the smart card up until an interface switch indicator is identified in the message stream. From that point, the smart card delivers messages from the message stream to a different logical partition of the smart card up until another interface switch indicator is identified in the message stream.

According to one or more embodiments, a smart card may host multiple logical partitions, each logical partition being configured to receive messages received at a certain interface of a terminal. The smart card prevents access to data corresponding to the first logical partition from any process corresponding to the second logical partition while also preventing access to data corresponding to the second logical partition from any process corresponding to the first logical partition.

Mobile handset manufacturers benefit from removing physical expansion slots from mobile handsets while still allowing the mobile handsets to host multiple enabled profiles to respond to network and terminal requests. In one or more embodiments, the multiple enabled profiles may be hosted on a physical embedded secure element or smart card integrated with the mobile handset. Mobile handset manufacturers have started to define a way of hosting interface profiles (e.g., eUICC profiles) on a logical secure element that communicates over logical interfaces sharing one physical interface with the mobile handset. In this way, multiple enabled interface profiles may be active at any given time, and capable of responding to terminal and network requests of the mobile handset.

<FIG> illustrates a block diagram of an example system <NUM> in accordance with one or more embodiments. As illustrated in <FIG>, system <NUM> includes a terminal <NUM> and a smart card <NUM>. Terminal <NUM> is configured to generate a message stream <NUM>, which is transmitted to smart card <NUM> in association with receiving messages <NUM> (e.g., first messages 116a, second messages 116b, etc.) at terminal <NUM>. Interfaces <NUM> and messages <NUM> may include any type of data and information for processing by smart card <NUM>, such as data commands, control commands, etc..

In one embodiment, terminal <NUM> may be a mobile handset, such as a mobile telephone device, or some other device configured to connect to one or more data communication networks, which may include wired and/or wireless data communication networks. Terminal <NUM> includes a plurality of interfaces <NUM> (e.g., interface 104a, interface 104b, etc.) configured to communicate via a particular data communications network. Interfaces <NUM> may be configured to send and/or receive data via any data communications network. Some example data communications networks include, but are not limited to, Global Systems for Mobile (GSM), Code Division Multiple Access (CDMA), Universal Mobile Telecommunication System (UMTS), Long Term Evolution (LTE), General Packet Radio Service (GPRS), Universal Mobile Telecommunications System (UMTS), Broadband Global Area Network (BGAN), wireless local area network (WLAN), Ethernet, etc..

In one or more embodiments, interface 104a may be configured to communicate using a first type of data communications network, while interface 104b may be configured to communicate using the same type of data communications network as interface 104a, or a different type of data communications network. In one embodiment, terminal <NUM> may include one or more interfaces <NUM> configured to communicate via a wired data communications network. In an embodiment, terminal <NUM> may include one or more interfaces <NUM> configured to communicate via a wireless data communications network. In one embodiment, terminal <NUM> may include one or more interfaces <NUM> configured to communicate via a satellite data communications network.

Smart card <NUM> may be a computing device configured to securely receive and respond to commands and/or messages across the various networks to which terminal <NUM> is in communication. In one embodiment, smart card <NUM> may be a UICC. In another embodiment, smart card may be a secure element.

In one or more embodiment, smart card <NUM> includes multiple interface profiles <NUM> (e.g., interface profile 114a, interface profile 114b, etc.). When smart card <NUM> is a physical UICC, each of the interface profiles <NUM> may be eUICC profiles, according to an approach.

Although only two interface profiles <NUM> are shown in <FIG>, any number of different profiles may be supported by a single smart card <NUM>. A maximum number of supported interface profiles <NUM> may be determined based on an amount of memory available to smart card <NUM>, and a number of interfaces <NUM> on terminal <NUM>. In some examples, the maximum number of supported profiles may be two, three, four, five, ten, etc..

Terminal <NUM> generates message stream <NUM> based at least on messages <NUM> received via interfaces <NUM>. In some approaches, message stream <NUM> may include commands and/or responses from the smart card <NUM>. The various interface profiles <NUM> on smart card are configured, in one or more embodiments, to process messages received on a single interface (e.g., first messages 116a received via interface 104a, second messages 116b received via interface 104b, etc.), not all messages <NUM> received by terminal <NUM>. For the remainder of this discussion, interface profile 114a is assumed to be configured to process first messages 116a received by interface 104a, and interface profile 114b is assumed to be configured to process second messages 116b received by interface 104b. However, any arrangement may be used when implementing the techniques described herein, including but not limited to having more than two interface profiles <NUM> corresponding to more than two interfaces <NUM>.

Message stream <NUM> includes a first set of messages 108a which may include one or more messages received via one of the interfaces (e.g., one or more first messages received via interface 104a) separated from the next set of messages 108b by an interface switch indicator 110a. Interface switch indicator 110a denotes that the messages included in message stream <NUM> prior to the interface switch indicator 110a are received via a different interface as compared to messages 108b included in message stream <NUM> after the interface switch indicator 110a. The next set of messages 108b are received via a different one of the interfaces (e.g., one or more second messages received via interface 104b). Messages 108b in message stream <NUM> are followed by another switch interface indicator 110b, denoting another switch in the interface which received the following messages. Switch interface indicators <NUM> are positioned between each set of messages <NUM> in the message stream <NUM> in order to group the messages <NUM> by the interface <NUM> on which they were received. In another words, message(s) 108a are selected from first messages 116a, while message(s) 108b are selected from second messages 116b, and separated by interface switch indicators <NUM> within all of message stream <NUM>. If additional interfaces <NUM> are present on terminal <NUM>, the interface switch indicators <NUM> will be configured to indicate a switch to this interface type, as well as indicating a switch to interface 104a and 104b.

Terminal <NUM> may place messages received via interfaces <NUM> into message stream <NUM> in sequential order according to when the messages were received at terminal <NUM> in one or more embodiments. In one approach, bursts of messages may be placed in message stream <NUM> in an attempt to minimize the number of interface switch indicators <NUM> that are needed to indicate switching between interfaces <NUM>, even if one or more messages are placed in the message stream <NUM> out of an order of receipt at the interfaces <NUM>. If a string or burst of messages is being received at a first interface (e.g., interface 104a), all of these messages 116a may be placed into the message stream <NUM> in order prior to any messages 116b received at another interface (e.g., interface 104b) until there is a break or pause in the flow of messages 116a being received at the first interface 104a. Then, any accumulated messages 116b received at the other interface 104b may be placed into the message stream <NUM> according to the order of receipt.

In other words, the messages <NUM> may be ordered within the message stream <NUM> in a chronological order based, at least in part, on a respective time at which each of the messages <NUM> are received at the terminal <NUM> (specifically, at the interfaces <NUM> of terminal <NUM>).

For example, some of the messages 116a received in a first period of time may be grouped into a first group of messages 108a in the message stream <NUM>. Moreover, some of the messages 116b received in a second period of time may be grouped into a second group of messages 108b in the message stream <NUM>. In this example, a start time of the second period of time is later than a start time of the first period of time, and the first group of messages 108a are ordered prior to the second group of messages 108b in the message stream <NUM>.

However, at least one message in the second group of messages 108b may have been received prior to at least one message in the first group of messages 108a, since the first period of time may overlap with the second period of time even though the second period of time starts after the first period of time. The amount of switching between messages received at different interfaces <NUM> on terminal <NUM> will be minimized, as much as possible, by generating bursts of messages received at one interface within the message stream <NUM>. These bursts may have a minimum size (e.g., <NUM> bits, <NUM> bits, <NUM> bytes, <NUM> bytes, 1KB, etc.) or duration (<NUM>, <NUM>, <NUM>, <NUM> second, etc.) in one embodiment. In another embodiment, these bursts or strings of messages from the same interface in the message stream <NUM> may have a maximum size or duration to ensure that messages are not unnecessarily delayed at terminal <NUM> while still minimizing the number of interface switch indicators <NUM> utilized in the message stream <NUM>.

Interface switch indicators <NUM> may be short, representational strings or codes that corresponds to one of the various interfaces <NUM> present on terminal <NUM>, and which are understood by smart card <NUM>, so that smart card <NUM> is able to determine which interface profile <NUM> to send the corresponding message(s). Interface switch indicators <NUM> may include a marker, flag, or some other binary mechanism that denotes a switch between interface types on terminal <NUM> for the next message or set of messages.

<FIG> illustrates an example system <NUM> having multiple logical partitions <NUM> hosted by a platform environment <NUM>, in accordance with one or more embodiments. The various modules show in <FIG> are described as being performed by a "system," but any combination of hardware and software may be utilized to perform the various functionality of the system <NUM> shown in <FIG>.

System <NUM> includes a platform environment <NUM> that operates an expandable set of functions. In one or more embodiments, platform environment <NUM> may be implemented on a secure element, UICC, or smart card, such as smart card <NUM> in <FIG>, or some other component of system <NUM>, in order to provide appropriate portions of the message stream <NUM> from terminal <NUM> to the various interface profiles <NUM>.

Referring again to <FIG>, in an embodiment, platform environment <NUM> is configured to install, instantiate, and/or provide one or more packages to various logical partitions <NUM> (e.g., logical partition 204a, logical partition 204b,. , logical partition 204n) hosted by the platform environment <NUM>. Any desired package(s) <NUM> may be installed and/or provided by platform environment <NUM>. When the platform environment <NUM> is a JCRE, some example packages <NUM> that may be used include, but are not limited to, Java Card (JC) packages that provide core and expanded Java Card functionality for the various logical partitions <NUM>; Global Platform (GP) packages that allow an issuer security domain (ISD) to act as an installer within a logical partition and as the root of all security domains in that logical partition; European Telecommunications Standards Institute (ETSI) packages that provide structure, format, protocols, and communication standards for UICC and SIM cards, etc..

In one or more embodiments, platform environment <NUM> may initialize and/or install any of the various packages on one of the logical partitions (e.g., logical partition 204a) to provide corresponding functionality to logical partition 204a without initializing and/or installing the same package on another logical partition (e.g., logical partition 204b). As shown in <FIG>, each of the logical partitions <NUM> have been provided with the same package functionality, but system <NUM> is not limited to this embodiment, and any combination of package installation/provision across the various logical partitions <NUM> is possible, in one or more embodiments.

Platform environment <NUM> includes a message dispatcher <NUM> configured to determine which of the various logical partitions <NUM> to send messages from a message stream received by smart card. Message dispatcher <NUM>, in one or more embodiments, may be configured to recognize interface switch indicators from the message stream in order to determine which logical partition <NUM> to send the next set of messages form the message stream. The message dispatcher <NUM> is described in more detail in <FIG>.

Referring again to <FIG>, in one embodiment, platform environment <NUM> provides and manages a partition firewall mechanism <NUM> which may provide firewall protection (e.g., partition firewall mechanism 222a,. , partition firewall mechanism 222n-<NUM>) between the various logical partitions <NUM> (e.g., partition firewall mechanism 222a separates logical partition 204a from logical partition 204b). Platform environment <NUM> operates the partition firewall mechanism <NUM> to completely prevent sharing of data and objects between the various logical partitions <NUM>.

The number of logical partitions <NUM> that can be hosted and/or reside on platform environment <NUM> may be limited due to memory constraints on the secure element/smart card/UICC on which the platform environment <NUM> is executed. However, by using a component that has sufficient memory to host a large number of logical partitions <NUM> (e.g., greater than <NUM> such partitions), this constraint may be effectively overcome.

In one embodiment, when the platform environment <NUM> is a JCRE, the logical partitions <NUM> are logical JCREs (L-JCREs). In this embodiment, each L-JCRE provides and/or hosts an applet space <NUM> (e.g., applet space 206a on L-JCRE 204a, applet space 206b on L-JCRE 204b,. , applet space 206n on L-JCRE 204n, etc.). Each applet space <NUM> allows for one or more converted applet (CAP) files (e.g., CAP file <NUM>, CAP file <NUM>, CAP file <NUM>) to be used. A CAP file may include one or more contexts in which a number of applets may be called and/or used. For example, CAP file <NUM> supports context <NUM> with applets <NUM> (e.g., applet 214a, applet 214b,. , applet 214n, etc.). Similarly, CAP file <NUM> supports context <NUM> with applets <NUM> (e.g., applet 220a, applet 220b,. , applet 220n, etc.). Although only a single context is shown for each CAP file, a CAP file may include multiple contexts in some embodiments. In one or more embodiments, the same CAP file may be installed and/or provided to multiple different applet spaces <NUM>.

Applets provided by the various CAP files are separated from one another by applet firewalls <NUM> within a corresponding applet space <NUM> (e.g., applet firewall 208a separates applets <NUM> provided by CAP file <NUM> from applets <NUM> provided by CAP file <NUM> in applet space <NUM>, applet firewall 208b separates applets <NUM> provided by CAP file <NUM> from applets <NUM> provided by CAP file <NUM> in applet space 206b, etc.). Applet firewalls <NUM> are security mechanisms typically implemented in a JCRE. The applet firewalls <NUM> each perform checks at runtime to prevent applets from accessing (reading or writing) data of other applets (i.e., of applets in a different security context). For every object, its context is recorded, and for any field or method access, the applet firewall <NUM> checks if it is allowed. In other words, applets are only allowed to access data and objects in their own context, or by using an object sharing mechanism, while the platform environment (e.g., JCRE) has the ability to access anything within system <NUM>. In addition, each logical partition (e.g., L-JCRE) has a context and is able to access anything in that context.

In one or more embodiments, platform environment <NUM> supports a fixed number or a variable number of logical interfaces (e.g., corresponding to the number of interfaces <NUM> on terminal <NUM>). A same number of logical partitions <NUM> are enabled by platform environment <NUM>, on a one-to-one basis to the number of interfaces <NUM>. In one or more embodiments, terminal <NUM> and/or platform environment <NUM> may determine a default logical interface that is opened after a smart card/UICC/SIM card reset.

In one or more embodiments, platform environment <NUM> manages and handles all commands and/or messages that are configured/defined for managing the logical interfaces (e.g., open, switch, reset). When a logical interface is in use, all commands and/or messages in a message stream <NUM> will be forwarded to the logical partition <NUM> that is associated to the active logical interface (e.g., when interface 104a is in use, all messages in message stream <NUM> will be forwarded to interface profile 114a corresponding to a logical interface represented by logical partition 204a). Once delivered to the appropriate interface profile <NUM>, the commands and/or messages will be handled according to existing rules of the packages installed on the logical partition <NUM> associated with the interface profile <NUM> (e.g., rules in the Java Card specification).

Additional embodiments and/or examples relating to computer networks are described below in the section titled "Computer Networks and Cloud Networks.

In one or more embodiments, one or more components of system <NUM> and/or system <NUM> may be implemented on one or more digital devices. The term "digital device" generally refers to any hardware device that includes a processor. A digital device may refer to a physical device executing an application or a virtual machine. Examples of digital devices include a computer, a tablet, a laptop, a desktop, a netbook, a server, a web server, a network policy server, a proxy server, a generic machine, a function-specific hardware device, a hardware router, a hardware switch, a hardware firewall, a hardware firewall, a hardware network address translator (NAT), a hardware load balancer, a mainframe, a television, a content receiver, a set-top box, a printer, a mobile handset, a smartphone, a personal digital assistant (PDA), a wireless receiver and/or transmitter, a base station, a communication management device, a router, a switch, a controller, an access point, and/or a client device.

In one or more embodiments, system <NUM> and/or system <NUM> may include a data repository (not shown in <FIG> and <FIG>). A data repository is any type of storage unit and/or device (e.g., a file system, database, collection of tables, and/or any other storage mechanism) for storing data. The data repository may include multiple different storage units and/or devices. The multiple different storage units and/or devices may or may not be of the same type or located at the same physical site. The data repository may be implemented or executed on the same computing system as one or more other components illustrated in <FIG> and <FIG> and/or on a separate computing system. The data repository may be communicatively coupled to one or more other components via a direct connection or via a network. Information may be implemented across any of the components of the platform other than the data repository.

In one or more embodiments, system <NUM> and/or system <NUM> may include a user interface. A user interface refers to hardware and/or software configured to facilitate communications between a user and one or more components of system <NUM> and/or system <NUM>. The interface renders user interface elements and receives input via user interface elements. Examples of interfaces include a graphical user interface (GUI), a command line interface (CLI), a haptic interface, and a voice command interface. Examples of user interface elements include checkboxes, radio buttons, dropdown lists, list boxes, buttons, toggles, text fields, date and time selectors, command lines, sliders, pages, and forms. Different components of the interface may be specified in different languages. For example, the behavior of user interface elements may be specified in a dynamic programming language, such as JavaScript. The content of user interface elements may be specified in a markup language, such as hypertext markup language (HTML) or XML User Interface Language (XUL). The layout of user interface elements may be specified in a style sheet language, such as Cascading Style Sheets (CSS). Alternatively, the interface may be specified in one or more other languages, such as Java, Python, C, or C++.

<FIG> illustrates use of a message dispatcher <NUM> by a platform environment <NUM>, in accordance with one or more embodiments. Platform environment <NUM> operates and manages the message dispatcher <NUM> in order to properly direct commands and/or messages from a message stream <NUM> to their intended destination, which in some embodiments is based on which logical interface <NUM> received the message(s) at the terminal <NUM>.

In one embodiment, message dispatcher <NUM> analyzes a message stream <NUM> and directs each message, instruction, request, and/or command included in message stream <NUM> to a logical partition <NUM> via a logical secure-element interface (LSI). Each LSI logically couples the terminal <NUM> with one of the logical partitions <NUM> within the platform environment <NUM>. which corresponds to a particular logical interface (e.g., directs messages to logical partition 204a responsive to logical interface 104a being the particular logical interface). The messages are sent to this particular logical interface until an interface switch indicator <NUM> is read from message stream <NUM>. Once the interface switch indicator <NUM> is identified, message dispatcher <NUM> determines the next logical partition <NUM> to send a next set of messages from message stream <NUM>. In other words, the next set of messages in message stream <NUM> are sent to logical partition 204b which corresponds to logical interface 104b indicated by the interface switch indicator <NUM> when the previous messages were directed to logical partition 204a which corresponds to logical interface 104a.

In one embodiment, when there are only two logical partitions <NUM>, an interface switch indicator <NUM> may be a simple flag or marker that indicates to switch to the other logical partition for directing messages that follow the interface switch indictor <NUM> in message stream <NUM>.

In another embodiment, when more than two logical interfaces <NUM> exist on terminal <NUM>, which correspond to more than two logical partition <NUM>, then an interface switch indicator <NUM> may designate which logical interface <NUM> received the messages that will follow and/or an associated logical partition <NUM>, so that the following messages may be directed to the appropriate logical partition <NUM> that will handle the messages for the particular logical interface <NUM>. Platform environment <NUM> and/or message dispatcher <NUM> may identify and maintain correlations between logical interfaces <NUM> on terminal <NUM> and interface profiles <NUM> in the smart card <NUM> corresponding to logical partitions <NUM>, in one or more embodiments. These correlations may be stored to memory that is accessible to the platform environment <NUM> and/or smart card <NUM>.

In an embodiment, smart card <NUM> may receive message stream <NUM> that includes multiple messages <NUM> and interface switch indicators <NUM> dispersed therein. The message dispatcher <NUM> transmits a first subset of messages 108a from message stream <NUM> to a first logical partition (e.g., logical partition 204a) of the smart card <NUM>. Prior to receiving the message stream <NUM>, terminal <NUM> orders the first subset of messages 108a in the message stream <NUM> to be received at message dispatcher <NUM> prior to a first interface switch indicator 110a. Responsive to the message dispatcher <NUM> detecting the first interface switch indicator 110a in the message stream, message dispatcher <NUM> transmits a second subset of messages 108b in the message stream <NUM> to a second logical partition (e.g., logical partition 204b) of the smart card <NUM>. Prior to receiving the message stream <NUM>, terminal <NUM> orders the second subset of messages 108b in the message stream <NUM> between the first interface switch indicator 110a and a second interface switch indicator 110b. In response to message dispatcher <NUM> detecting the second interface switch indicator 110b in the message stream <NUM>, message dispatcher <NUM> transmits a third subset of messages 108c in the message stream <NUM> to the first logical partition 204a of the smart card <NUM>. As shown, the third subset of messages 108c are ordered in the message stream <NUM> by terminal <NUM> between the second interface switch indicator 110b and a third interface switch indicator 110c. This switching back and forth between delivering messages to the first logical partition 204a and second logical partition 204b will continue as the message dispatcher <NUM> processes through the message stream <NUM>.

When more than two logical partitions <NUM> are present on platform environment <NUM>, message dispatcher <NUM> will analyze the various interface switch indicators <NUM> included in the message stream <NUM> to determine which logical partition <NUM> to transmit the next subset of messages in the message stream <NUM>, up until a next interface switch indicator <NUM> is identified.

<FIG> illustrates use of a platform registry <NUM> by a platform environment <NUM>, in accordance with one or more embodiments. The platform environment <NUM> maintains a platform registry <NUM> that includes, in a format readable by platform environment <NUM>, descriptions of all packages <NUM> resident on platform environment <NUM> in an embodiment. In addition, every package <NUM> installed on the logical partitions <NUM> are included in the platform registry <NUM>. When the platform environment <NUM> is a JCRE and the logical partitions are L-JCREs, the packages <NUM> available may include, but are not limited to, JC packages, GP packages, ETSI packages, etc. Platform environment <NUM> is configured to selectively make any or all of these various packages <NUM> available to the various logical partitions <NUM>.

A logical partition <NUM> behaves at the applet level in the applet space <NUM> and to external devices like an existing platform environment (e.g., a logical partition acts and appears like a platform environment). When the platform environment <NUM> is a JCRE, each of the logical partitions <NUM> are L-JCREs that appear like their own JCREs to other devices. The platform JCRE <NUM> tracks which logical interface is active at any given time. By "active" interface, what is meant is that the message dispatcher <NUM> is presently and actively directing messages to this logical interface, and not to some other "inactive" logical interface. The active interface may be determined based on some default setting or based on a received message indicating which interface is the active interface (e.g., an interface switch indicator). Also, in one or more embodiments, the platform JCRE <NUM> isolates the different L-JCREs <NUM>, so that the platform JCRE <NUM> operating with any given L-JCRE <NUM> behave like a single JCRE instance on a chip. Each L-JCRE <NUM> is associated with a logical interface, and this connection is maintained by the platform JCRE <NUM>.

According to one embodiment, each logical partition (e.g., L-JCRE) <NUM> has a dedicated logical registry <NUM> (e.g., logical partition 204a has logical registry 406a, logical partition 204b has logical registry 406b). In this embodiment, each logical registry view <NUM> (e.g., logical registry view 408a on logical partition 204a, logical registry view 408b on logical partition 204b) may be obtained as a merge between the platform registry <NUM> and the corresponding dedicated logical registry <NUM> on the logical partition. In this approach, the platform registry <NUM> includes the packages for the platform environment <NUM> (e.g., P-JCRE packages) and not any of the packages for the logical partitions <NUM> (e.g., L-JCRE packages).

In one or more embodiments, the platform environment <NUM> (e.g., platform JCRE) has a platform registry <NUM> with tags denoting which entries are applicable to which logical partition <NUM> (e.g., L-JCRE). Each logical registry view <NUM> may be obtained by filtering entries from entries in the platform registry <NUM> according to the tags. For example, entries tagged with an identifier corresponding with a particular logical partition <NUM> (e.g., L-JCRE) or tagged with an identifier that is assigned to the platform environment <NUM> (e.g., platform JCRE) may be made available and/or downloaded into the logical registry view <NUM>. This ensures that all common registry entries assigned to the platform environment <NUM> and logical partition-specific entries are included in the logical registry view <NUM>.

Each logical partition <NUM> relies on the local logical registry view <NUM> to determine which packages <NUM> resident on platform environment <NUM> may be needed and/or used by the logical partition <NUM> to perform some task or operation, in order to get that package and/or installed on the logical partition <NUM>. In one embodiment, installer 410a on logical partition 204a is used to install all packages for logical partition 204a. Installer 410a may be an instance of platform installer <NUM> and/or provided by host platform <NUM> based on platform installer <NUM>. Similarly, in one embodiment, installer 410b on logical partition 204b may be used to install all packages on logical partition 204b. Installer 410b may be an instance of platform installer <NUM> and/or provided by host platform <NUM> based on platform installer <NUM>.

Every L-JCRE <NUM> has an installer <NUM> as the root of all installed packages and applet instances in that L-JCRE <NUM>. In cases where an L-JCRE <NUM> implements Global Platform, it has an issuer security domain (ISD) as the installer and acting as the root of all security domains in that L-JCRE <NUM>.

Every package <NUM> that is loaded and applets that are installed in applet space <NUM> for a particular L-JCRE <NUM> are only associated with the installer <NUM> or the ISD of this L-JCRE <NUM> (e.g., installer/ISD <NUM> on L-JCRE 204a). The registry of the L-JCRE <NUM> that the ISD can see and that an applet can access, is a combination of the package registry of the platform JCRE <NUM> and the package, and the applet's instance registry of the L-JCRE <NUM>. In this way, it is possible to have in an L-JCRE <NUM> an applet instance or package with the same applet identifier (AID) as in a second L-JCRE <NUM>.

<FIG> illustrates an example system <NUM> that supports logical partitions, in accordance with one or more embodiments. System <NUM> includes the platform environment (e.g., JCRE) <NUM> on which a plurality of logical partitions (L-JCREs) 204a, 204b, etc., are supported. Each logical partition <NUM> operates its own card application toolkit (CAT) Runtime Environment (CAT-RTE) <NUM> (e.g., CAT RTE 526a on L-JCRE 204a, CAT RTE 526b on L-JCRE 204b, etc.) and UICC Runtime Environment (UICC RTE) <NUM> (e.g., UICC RTE 518a on L-JCRE 204a, UICC RTE 518b on L-JCRE 204b, etc.). Above these layers, a number of packages are supported for implementation in each of the logical partitions <NUM>. These packages include, but are not limited to, various Java Card Packages <NUM>, the UICC. Access Package <NUM>, the UICC. Toolkit Package <NUM>, and the UICC. System Package <NUM>.

Above this layer, each logical partition <NUM> also operates a file system and various applications/packages. For example, in <FIG>, each logical partition <NUM> is running a UICC file system server <NUM> (e.g., UICC file system server 502a on L-JCRE 204a, UICC file system server 502b on L-JCRE 204b, etc.), some applications based on ETSI <NUM><NUM> (such as SIM applet, USIM applet, etc.) along with an ADF file system server <NUM> (e.g., ADF file system server 504a on L-JCRE 204a, ADF file system server 504b on L-JCRE 204b, etc.), some other applications <NUM> (not based on ETSI <NUM><NUM>) (e.g., other apps 506a on L-JCRE 204a, other apps 506b on L-JCRE 204b, etc.), and a toolkit applet <NUM> (e.g., toolkit applet 508a on L-JCRE 204a, toolkit applet 508b on L-JCRE 204b, etc.) such as toolkit service, remote management applications, browser applications, etc..

If an L-JCRE <NUM> also implements the CAT RTE <NUM> according to ETSI standards, it also maintains a logical Toolkit Registry <NUM>, that is responsible to store the terminal profile, the event-list, and all other toolkit specific data related to the logical interface associated with that L-JCRE <NUM>. The combination of the UICC RTE <NUM> and CAT RTE <NUM> comprises a logical interface for a particular logical partition <NUM> in one or more embodiments. For example, UICC RTE 518a and CAT RTE 526a which includes Toolkit handler 520a, Toolkit registry 522a, and trigger entity 524a comprise the logical interface for logical partition (L-JCRE) 204a.

Each UICC RTE <NUM> store the Terminal Profile that it has received via an associated LSI, stores all the toolkit registry events that applets have registered on the associated L-JCRE <NUM>, and makes the handler available to the applets on the L-JCRE <NUM> if the associated LSI is the currently opened interface by the terminal <NUM>. An LSI is a logical connection between an endpoint in the terminal and one logical partition <NUM> within the platform environment <NUM>.

The filesystem of the secure element/smart card/UICC and how it is partitioned and associated with the logical interfaces is exposed to the CAT-RTE <NUM> and corresponding filesystem API. However, this information, in one approach, will not be visible to the application layer. The CAT-RTE <NUM>, as an extension to the platform JCRE <NUM>, ensures that an applet on a L-JCRE <NUM> only has access to the filesystem portion that is associated with the corresponding logical interface.

On a UICC, each L-JCRE <NUM> and its specific extension of the CAT-RTE <NUM> will ensure that FileView object can only access files that are associated by the UICC operating system to the same logical interface that the L-JCRE <NUM> is associated with. Global objects and so called "JCRE entry point objects" (like File View, Handlers, APDU buffer) are visible only in the context of its associated L-JCRE <NUM>. Therefore, in one embodiment, the platform JCRE <NUM> tracks which applet from which L-JCRE <NUM> is accessing a particular object and ensures that these particular objects are allocated on the platform JCRE level.

In another embodiment, particular objects are created for the L-JCRE <NUM> and only under the control of the L-JCRE <NUM> relieving the platform JCRE <NUM> from needing to track such interactions. The same applies with objects that the applets create and store persistently (e.g., crypto-keys, block-chain keys, encryption keys, etc.). The platform JCRE <NUM> ensures that only an applet from the same L-JCRE <NUM> can access this sensitive data, such as by utilizing partition firewalls.

During any time interval in which no communication occurs (message stream <NUM> is empty, connection is interrupted, etc.) over a logical interface, the L-JCRE <NUM> will behave like a card that waits for the next command. The L-JCRE <NUM> stores the context of the L-JCRE <NUM> at the time it has sent the Status Word of the last response APDU, which applets are selected, the state of PIN's, etc. The context of the File View and the state of the Toolkit Registry is also preserved during a LSI switch.

Detailed examples are described below for purposes of clarity. Components and/or operations described below should be understood as one specific example which may not be applicable to certain embodiments. Accordingly, components and/or operations described below should not be construed as limiting the scope of any of the claims.

<FIG> illustrates an example set of operations <NUM> for generating a message stream for multiple logical partitions of a smart card, in accordance with one or more embodiments. One or more operations illustrated in <FIG> may be modified, rearranged, or omitted all together. Accordingly, the particular sequence of operations illustrated in <FIG> should not be construed as limiting the scope of one or more embodiments. Although the operations are described in <FIG> as being executed by a system, any hardware, software, or combination thereof may be used to execute the set of operations <NUM> in one or more embodiments.

In Operations <NUM> and <NUM>, the system receives a plurality of messages at a terminal. In Operation <NUM>, the system receives, at the terminal via a first interface, a first subset of the plurality of messages destined for a first logical partition of a smart card. The logical partitions of the smart card may be L-JCRE, as described herein in various embodiments. Moreover, the smart card may be a UICC, secure element, or some other communications chip device.

In Operation <NUM>, the system receives, at the terminal via a second interface, a second subset of the plurality of messages destined for a second logical partition of the smart card. The first and second interfaces may be wireless interfaces, wired interfaces, or direct connections with another component of the system, in various embodiments.

In one or more embodiments, the first logical partition may correspond to a first subscriber identification module (SIM) card profile and the second logical partition may correspond to a second SIM card profile.

According to some embodiments, the first logical partition may correspond to a first application executing on the smart card and the second logical partition may correspond to a second application executing on the smart card.

In an approach, the first and second partitions may correspond to a mix of different entities on the smart card, including SIM card profiles, applications, UICC profiles, secure element profiles, L-JCREs, etc..

In one or more embodiments, the smart card may be a UICC, an integrated smart card for a mobile handset, a removable smart card for a mobile handset, or some other suitable device described herein.

In Operations <NUM> and <NUM>, the system generates a message stream that includes the plurality of messages. In Operation <NUM>, the system orders the plurality of messages within the message stream in a chronological order based at least in part on a respective time at which each of the plurality of messages are received at the terminal. Although strict chronological order of the messages is not required within the message stream, it is one of the considerations in determining the order for the messages in the message stream. Other considerations include minimizing the number of interface switch indictors, reduction in resource use to generate and/or process the message stream, etc..

In Operation <NUM>, the system inserts interface switch indicators corresponding respectively to each switch between (a) messages from the first subset of the plurality of messages, and (b) messages from the second subset of the plurality of messages in the message stream. In this way, each time the destination for the messages in the message stream is changed, an interface switch indicator is inserted in the message stream to make a receiving device aware of this change.

According to one or more embodiments, the system may order the plurality of messages within the message stream in the chronological order by the following: grouping messages, from the first subset of the plurality of messages, received in a first period of time into a first group of messages; grouping messages, from the second subset of the plurality of messages, received in a second period of time into a second group of messages, wherein a start time of the second period of time is later than a start time of the first period of time; ordering the first group of messages prior to the second group of messages in the message stream, wherein at least one message in the second group of messages was received prior to at least one message in the first group of messages.

To avoid excessive back and forth and/or excessive interface switch indicators being included in the message stream, some grouping may be performed that supersedes strict chronological ordering of the messages. In one embodiment, the system may group messages together in sets of receipt time from one of the interfaces of the terminal, even when the receipt time periods for the different interfaces overlap.

For example, all messages received from <NUM> to <NUM> on the first interface may be added to the first subset of messages and sent to the smart card prior to all messages received from <NUM> to <NUM> on the second interface, which would be added to the second subset of messages. In this example, a message received in the second subset at <NUM> is sent later than a message received the first subset at <NUM>, but it prevents numerous interface switch indicators from being added to the message stream to switch all messages received from <NUM> to <NUM> across both interfaces.

In Operation <NUM>, the system transmits, by the terminal, the message stream that includes the ordered plurality of messages with the inserted interface switch indicators to the smart card.

Operations <NUM> may further include, once the message stream is generated and transmitted to the smart card, any of the following operations: the smart card receives the message stream comprising the ordered plurality of messages with the inserted interface switch indicators; transmitting a first group of the first subset of the plurality of messages to the first logical partition, the first group of the first subset of messages being ordered in the message stream prior to a first interface switch indicator; responsive to detecting the first interface switch indicator in the message stream: transmitting a first group of the second subset of messages in the plurality of messages to the second logical partition, the first group of the second subset of messages being ordered in the message stream between the first interface switch indicator and a second interface switch indicator; and responsive to detecting the second interface switch indicator in the message stream: transmitting a second group of the first subset of messages in the plurality of messages to the first logical partition, the second group of the first subset of messages being ordered in the message stream between the second interface switch indicator and a third interface switch indicator.

<FIG> illustrates an example set of operations <NUM> for processing a message stream for multiple logical partitions of a smart card, in accordance with one or more embodiments. One or more operations illustrated in <FIG> may be modified, rearranged, or omitted all together. Accordingly, the particular sequence of operations illustrated in <FIG> should not be construed as limiting the scope of one or more embodiments. Although the operations are described in <FIG> as being executed by a system, any hardware, software, or combination thereof may be used to execute the set of operations <NUM> in one or more embodiments.

In Operation <NUM>, the system receives a message stream that includes a plurality of messages and interface switch indicators. The message stream may be generated by a terminal of a mobile handset in one embodiment. Each interface switch indicator in the message stream denotes a change in which interface received the following messages in the message stream.

In Operation <NUM>, the system transmits a first subset of messages in the plurality of messages to a first logical partition of a smart card, the first subset of messages being ordered in the message stream prior to a first interface switch indicator.

In Operation <NUM>, the system identifies a first interface switch indicator in the message stream. Should no interface switch indicators be identified in the message stream, then the messages will continue to be transmitted to the first logical partition of the smart card. In response to detecting the first interface switch indicator in the message stream, in Operation <NUM> the system transmits a second subset of messages in the plurality of messages to a second logical partition of the smart card. The second subset of messages is ordered in the message stream between the first interface switch indicator and a second interface switch indicator.

In Operation <NUM>, the system identifies a second interface switch indicator in the message stream. Should no interface switch indicators after the first interface switch indicator be identified in the message stream, then the messages will continue to be transmitted to the second logical partition of the smart card. In response to detecting the second interface switch indicator in the message stream, in Operation <NUM> the system transmits a third subset of messages in the plurality of messages to the first logical partition of the smart card. The third subset of messages is ordered in the message stream between the second interface switch indicator and a third interface switch indicator.

According to one or more embodiments, the first logical partition may correspond to a first SIM card profile and the second logical partition may correspond to a second SIM card profile.

In one or more embodiments, the system may receive, at a terminal (e.g., of a mobile handset), the plurality of messages, which includes receiving, via a first interface, a first group of the plurality of messages destined for the first logical partition of the smart card and receiving, via a second interface, a second group of the plurality of messages destined for the second logical partition of the smart card. The system may generate the message stream comprising the plurality of messages by ordering the plurality of messages within the message stream in a chronological order based at least in part on a respective time at which each of the plurality of messages are received at the terminal and inserting interface switch indicators corresponding respectively to each switch between (a) messages from the first group of the plurality of messages, and (b) messages from the second group of the plurality of messages in the message stream. Thereafter, the system may transmit, by the terminal to the smart card, the message stream comprising the ordered plurality of messages with the inserted interface switch indicators.

<FIG> illustrates an example set of operations <NUM> for applying partition firewalls to multiple logical partitions of a smart card. One or more operations illustrated in <FIG> may be modified, rearranged, or omitted all together. Accordingly, the particular sequence of operations illustrated in <FIG> should not be construed as limiting the scope of one or more embodiments. Although the operations are described in <FIG> as being executed by a system, any hardware, software, or combination thereof may be used to execute the set of operations <NUM> in one or more embodiments.

In Operation <NUM>, the system hosts a first logical partition of a smart card configured to receive messages received at a first wireless interface (e.g., of a terminal of a mobile handset).

In Operation <NUM>, the system hosts a second logical partition of the smart card configured to receive messages received at a second wireless interface.

In Operation <NUM>, the system prevents access to data and processes corresponding to the first logical partition from any process corresponding to the second logical partition, e.g., applies a partition firewall between the first and second logical partitions. Additional partition firewalls may be applied between all other logical partitions of the smart card.

In Operation <NUM>, the system prevents access to data corresponding to the second logical partition from any process corresponding to the first logical partition.

In one or more embodiments, the system may also maintain a registry of platform packages for a JCRE, e.g., Java Card, GlobalPlatform, ETSI, etc. In addition, the system may selectively perform operations corresponding to at least one first platform package from the registry of platform packages for the first logical partition and/or install the at least one first platform package on the first logical partition for execution by the first logical partition. Also, the system may selectively perform operations corresponding to at least one second platform package from the registry of platform packages for the second logical partition and/or install the at least one second platform package on the second logical partition for execution by the second logical partition. In one or more embodiments, the first and second packages may be the same platform package or different platform packages.

In one embodiment, the system may perform operations corresponding to at least one platform package from the registry of platform packages for the first logical partition and the second logical partition.

In one or more embodiments, a computer network provides connectivity among a set of nodes. The nodes may be local to and/or remote from each other. The nodes are connected by a set of links. Examples of links include a coaxial cable, an unshielded twisted cable, a copper cable, an optical fiber, and a virtual link.

A subset of nodes implements the computer network. Examples of such nodes include a switch, a router, a firewall, and a network address translator (NAT). Another subset of nodes uses the computer network. Such nodes (also referred to as "hosts") may execute a client process and/or a server process. A client process makes a request for a computing service (such as, execution of a particular application, and/or storage of a particular amount of data). A server process responds by executing the requested service and/or returning corresponding data.

A computer network may be a physical network, including physical nodes connected by physical links. A physical node is any digital device. A physical node may be a function-specific hardware device, such as a hardware switch, a hardware router, a hardware firewall, and a hardware NAT. Additionally or alternatively, a physical node may be a generic machine that is configured to execute various virtual machines and/or applications performing respective functions. A physical link is a physical medium connecting two or more physical nodes. Examples of links include a coaxial cable, an unshielded twisted cable, a copper cable, and an optical fiber.

A computer network may be an overlay network. An overlay network is a logical network implemented on top of another network (such as, a physical network). Each node in an overlay network corresponds to a respective node in the underlying network. Hence, each node in an overlay network is associated with both an overlay address (to address to the overlay node) and an underlay address (to address the underlay node that implements the overlay node). An overlay node may be a digital device and/or a software process (such as, a virtual machine, an application instance, or a thread) A link that connects overlay nodes is implemented as a tunnel through the underlying network. The overlay nodes at either end of the tunnel treat the underlying multi-hop path between them as a single logical link. Tunneling is performed through encapsulation and decapsulation.

In an embodiment, a client may be local to and/or remote from a computer network. The client may access the computer network over other computer networks, such as a private network or the Internet. The client may communicate requests to the computer network using a communications protocol, such as Hypertext Transfer Protocol (HTTP). The requests are communicated through an interface, such as a client interface (such as a web browser), a program interface, or an application programming interface (API).

In an embodiment, a computer network provides connectivity between clients and network resources. Network resources include hardware and/or software configured to execute server processes. Examples of network resources include a processor, a data storage, a virtual machine, a container, and/or a software application. Network resources are shared amongst multiple clients. Clients request computing services from a computer network independently of each other. Network resources are dynamically assigned to the requests and/or clients on an on-demand basis. Network resources assigned to each request and/or client may be scaled up or down based on, for example, (a) the computing services requested by a particular client, (b) the aggregated computing services requested by a particular tenant, and/or (c) the aggregated computing services requested of the computer network. Such a computer network may be referred to as a "cloud network.

In an embodiment, a service provider provides a cloud network to one or more end users. Various service models may be implemented by the cloud network, including but not limited to Software-as-a-Service (SaaS), Platform-as-a-Service (PaaS), and Infrastructure-as-a-Service (IaaS). In SaaS, a service provider provides end users the capability to use the service provider's applications, which are executing on the network resources. In PaaS, the service provider provides end users the capability to deploy custom applications onto the network resources. The custom applications may be created using programming languages, libraries, services, and tools supported by the service provider. In IaaS, the service provider provides end users the capability to provision processing, storage, networks, and other fundamental computing resources provided by the network resources. Any arbitrary applications, including an operating system, may be deployed on the network resources.

In an embodiment, various deployment models may be implemented by a computer network, including but not limited to a private cloud, a public cloud, and a hybrid cloud. In a private cloud, network resources are provisioned for exclusive use by a particular group of one or more entities (the term "entity" as used herein refers to a corporation, organization, person, or other entity). The network resources may be local to and/or remote from the premises of the particular group of entities. In a public cloud, cloud resources are provisioned for multiple entities that are independent from each other (also referred to as "tenants" or "customers"). The computer network and the network resources thereof are accessed by clients corresponding to different tenants. Such a computer network may be referred to as a "multi-tenant computer network. " Several tenants may use a same particular network resource at different times and/or at the same time. The network resources may be local to and/or remote from the premises of the tenants. In a hybrid cloud, a computer network comprises a private cloud and a public cloud. An interface between the private cloud and the public cloud allows for data and application portability. Data stored at the private cloud and data stored at the public cloud may be exchanged through the interface. Applications implemented at the private cloud and applications implemented at the public cloud may have dependencies on each other. A call from an application at the private cloud to an application at the public cloud (and vice versa) may be executed through the interface.

In an embodiment, tenants of a multi-tenant computer network are independent of each other. For example, a business or operation of one tenant may be separate from a business or operation of another tenant. Different tenants may demand different network requirements for the computer network. Examples of network requirements include processing speed, amount of data storage, security requirements, performance requirements, throughput requirements, latency requirements, resiliency requirements, Quality of Service (QoS) requirements, tenant isolation, and/or consistency. The same computer network may need to implement different network requirements demanded by different tenants.

In one or more embodiments, in a multi-tenant computer network, tenant isolation is implemented to ensure that the applications and/or data of different tenants are not shared with each other. Various tenant isolation approaches may be used.

In an embodiment, each tenant is associated with a tenant ID. Each network resource of the multi-tenant computer network is tagged with a tenant ID. A tenant is permitted access to a particular network resource only if the tenant and the particular network resources are associated with a same tenant ID.

In an embodiment, each tenant is associated with a tenant ID. Each application, implemented by the computer network, is tagged with a tenant ID. Additionally or alternatively, each data structure and/or dataset, stored by the computer network, is tagged with a tenant ID. A tenant is permitted access to a particular application, data structure, and/or dataset only if the tenant and the particular application, data structure, and/or dataset are associated with a same tenant ID.

As an example, each database implemented by a multi-tenant computer network may be tagged with a tenant ID. Only a tenant associated with the corresponding tenant ID may access data of a particular database. As another example, each entry in a database implemented by a multi-tenant computer network may be tagged with a tenant ID. Only a tenant associated with the corresponding tenant ID may access data of a particular entry. However, the database may be shared by multiple tenants.

In an embodiment, a subscription list indicates which tenants have authorization to access which applications. For each application, a list of tenant IDs of tenants authorized to access the application is stored. A tenant is permitted access to a particular application only if the tenant ID of the tenant is included in the subscription list corresponding to the particular application.

In an embodiment, network resources (such as digital devices, virtual machines, application instances, and threads) corresponding to different tenants are isolated to tenant-specific overlay networks maintained by the multi-tenant computer network. As an example, packets from any source device in a tenant overlay network may only be transmitted to other devices within the same tenant overlay network. Encapsulation tunnels are used to prohibit any transmissions from a source device on a tenant overlay network to devices in other tenant overlay networks. Specifically, the packets, received from the source device, are encapsulated within an outer packet. The outer packet is transmitted from a first encapsulation tunnel endpoint (in communication with the source device in the tenant overlay network) to a second encapsulation tunnel endpoint (in communication with the destination device in the tenant overlay network). The second encapsulation tunnel endpoint decapsulates the outer packet to obtain the original packet transmitted by the source device. The original packet is transmitted from the second encapsulation tunnel endpoint to the destination device in the same particular overlay network.

The special-purpose computing devices may be hard-wired to perform the techniques, or may include digital electronic devices such as one or more application-specific integrated circuits (ASICs), field programmable gate arrays (FPGAs), or network processing units (NPUs) that are persistently programmed to perform the techniques, or may include one or more general purpose hardware processors programmed to perform the techniques pursuant to program instructions in firmware, memory, other storage, or a combination. Such special-purpose computing devices may also combine custom hard-wired logic, ASICs, FPGAs, or NPUs with custom programming to accomplish the techniques.

Common forms of storage media include, for example, a floppy disk, a flexible disk, hard disk, solid state drive, magnetic tape, or any other magnetic data storage medium, a CD-ROM, any other optical data storage medium, any physical medium with patterns of holes, a RAM, a PROM, and EPROM, a FLASH-EPROM, NVRAM, any other memory chip or cartridge, content-addressable memory (CAM), and ternary content-addressable memory (TCAM).

Examples are directed to a system with one or more devices that include a hardware processor and that are configured to perform any of the operations described herein.

In an example, a non-transitory computer readable storage medium comprises instructions which, when executed by one or more hardware processors, causes performance of any of the operations described herein.

Claim 1:
One or more non-transitory machine-readable media storing instructions which, when executed by one or more processors (<NUM>) of a terminal (<NUM>), cause the terminal (<NUM>) to perform actions comprising:
receiving, at a terminal (<NUM>), a plurality of messages (<NUM>), the receiving operation comprising:
receiving, at the terminal (<NUM>) via a first interface, a first subset of the plurality of messages destined for a first logical partition of a smart card (<NUM>);
receiving, at the terminal (<NUM>) via a second interface, a second subset of the plurality of messages destined for a second logical partition of the smart card (<NUM>);
generating a message stream (<NUM>) comprising the plurality of messages (<NUM>), the generating operation comprising:
ordering the plurality of messages (<NUM>) within the message stream (<NUM>) in a chronological order based at least in part on a respective time at which each of the plurality of messages (<NUM>) are received at the terminal (<NUM>); and
inserting interface switch indicators (<NUM>) corresponding respectively to each switch between (a) messages from the first subset of the plurality of messages, and (b) messages from the second subset of the plurality of messages in the message stream (<NUM>); and
transmitting, by the terminal (<NUM>) to the smart card (<NUM>), the message stream (<NUM>) comprising the ordered plurality of messages (<NUM>) with the inserted interface switch indicators (<NUM>).