Patent ID: 12197974

DETAILED DESCRIPTION

In the following description, for the purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding. One or more embodiments may be practiced without these specific details. Features described in one embodiment may be combined with features described in a different embodiment. In some examples, well-known structures and devices are described with reference to a block diagram form in order to avoid unnecessarily obscuring the present invention.1. GENERAL OVERVIEW2. SYSTEM ARCHITECTURE3. MESSAGE DISPATCHER4. PLATFORM REGISTRY5. LOGICAL PARTITION SUPPORT6. EXAMPLE EMBODIMENTS7. COMPUTER NETWORKS AND CLOUD NETWORKS8. HARDWARE OVERVIEW9. MISCELLANEOUS; EXTENSIONS

1. GENERAL OVERVIEW

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.

One or more embodiments described in this Specification and/or recited in the claims may not be included in this General Overview section.

2. SYSTEM ARCHITECTURE

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.1illustrates a block diagram of an example system100in accordance with one or more embodiments. As illustrated inFIG.1, system100includes a terminal102and a smart card112. Terminal102is configured to generate a message stream106, which is transmitted to smart card112in association with receiving messages116(e.g., first messages116a,second messages116b,etc.) at terminal102. Interfaces104and messages116may include any type of data and information for processing by smart card112, such as data commands, control commands, etc.

In one embodiment, terminal102may 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. Terminal102includes a plurality of interfaces104(e.g., interface104a,interface104b,etc.) configured to communicate via a particular data communications network. Interfaces104may 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, interface104amay be configured to communicate using a first type of data communications network, while interface104bmay be configured to communicate using the same type of data communications network as interface104a,or a different type of data communications network. In one embodiment, terminal102may include one or more interfaces104configured to communicate via a wired data communications network. In an embodiment, terminal102may include one or more interfaces104configured to communicate via a wireless data communications network. In one embodiment, terminal102may include one or more interfaces104configured to communicate via a satellite data communications network.

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

In one or more embodiment, smart card112includes multiple interface profiles114(e.g., interface profile114a,interface profile114b,etc.). When smart card112is a physical UICC, each of the interface profiles114may be eUICC profiles, according to an approach.

Although only two interface profiles114are shown inFIG.1, any number of different profiles may be supported by a single smart card112. A maximum number of supported interface profiles114may be determined based on an amount of memory available to smart card112, and a number of interfaces104on terminal102. In some examples, the maximum number of supported profiles may be two, three, four, five, ten, etc.

Terminal102generates message stream106based at least on messages116received via interfaces104. In some approaches, message stream106may include commands and/or responses from the smart card112. The various interface profiles114on smart card are configured, in one or more embodiments, to process messages received on a single interface (e.g., first messages116areceived via interface104a,second messages116breceived via interface104b,etc.), not all messages116received by terminal102. For the remainder of this discussion, interface profile114ais assumed to be configured to process first messages116areceived by interface104a,and interface profile114bis assumed to be configured to process second messages116breceived by interface104b.However, any arrangement may be used when implementing the techniques described herein, including but not limited to having more than two interface profiles114corresponding to more than two interfaces104.

Message stream106includes a first set of messages108awhich may include one or more messages received via one of the interfaces (e.g., one or more first messages received via interface104a) separated from the next set of messages108bby an interface switch indicator110a.Interface switch indicator110adenotes that the messages included in message stream106prior to the interface switch indicator110aare received via a different interface as compared to messages108bincluded in message stream106after the interface switch indicator110a.The next set of messages108bare received via a different one of the interfaces (e.g., one or more second messages received via interface104b). Messages108bin message stream106are followed by another switch interface indicator110b,denoting another switch in the interface which received the following messages. Switch interface indicators110are positioned between each set of messages108in the message stream106in order to group the messages108by the interface104on which they were received. In another words, message(s)108aare selected from first messages116a,while message(s)108bare selected from second messages116b,and separated by interface switch indicators110within all of message stream106. If additional interfaces104are present on terminal102, the interface switch indicators110will be configured to indicate a switch to this interface type, as well as indicating a switch to interface104aand104b.

Terminal102may place messages received via interfaces104into message stream106in sequential order according to when the messages were received at terminal102in one or more embodiments. In one approach, bursts of messages may be placed in message stream106in an attempt to minimize the number of interface switch indicators110that are needed to indicate switching between interfaces104, even if one or more messages are placed in the message stream106out of an order of receipt at the interfaces104. If a string or burst of messages is being received at a first interface (e.g., interface104a), all of these messages116amay be placed into the message stream106in order prior to any messages116breceived at another interface (e.g., interface104b) until there is a break or pause in the flow of messages116abeing received at the first interface104a.Then, any accumulated messages116breceived at the other interface104bmay be placed into the message stream106according to the order of receipt.

In other words, the messages108may be ordered within the message stream106in a chronological order based, at least in part, on a respective time at which each of the messages116are received at the terminal102(specifically, at the interfaces104of terminal102).

For example, some of the messages116areceived in a first period of time may be grouped into a first group of messages108ain the message stream106. Moreover, some of the messages116breceived in a second period of time may be grouped into a second group of messages108bin the message stream106. 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 messages108aare ordered prior to the second group of messages108bin the message stream106.

However, at least one message in the second group of messages108bmay have been received prior to at least one message in the first group of messages108a,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 interfaces104on terminal102will be minimized, as much as possible, by generating bursts of messages received at one interface within the message stream106. These bursts may have a minimum size (e.g., 10 bits, 100 bits, 10 bytes, 100 bytes, 1 KB, etc.) or duration (1 ms, 10 ms, 100 ms, 1 second, etc.) in one embodiment. In another embodiment, these bursts or strings of messages from the same interface in the message stream106may have a maximum size or duration to ensure that messages are not unnecessarily delayed at terminal102while still minimizing the number of interface switch indicators110utilized in the message stream106.

Interface switch indicators110may be short, representational strings or codes that corresponds to one of the various interfaces104present on terminal102, and which are understood by smart card112, so that smart card112is able to determine which interface profile114to send the corresponding message(s). Interface switch indicators110may include a marker, flag, or some other binary mechanism that denotes a switch between interface types on terminal102for the next message or set of messages.

FIG.2illustrates an example system200having multiple logical partitions204hosted by a platform environment202, in accordance with one or more embodiments. The various modules show inFIG.2are described as being performed by a “system,” but any combination of hardware and software may be utilized to perform the various functionality of the system200shown inFIG.2.

System200includes a platform environment202that operates an expandable set of functions. In one or more embodiments, platform environment202may be implemented on a secure element, UICC, or smart card, such as smart card112inFIG.1, or some other component of system100, in order to provide appropriate portions of the message stream106from terminal102to the various interface profiles114.

Referring again toFIG.2, in an embodiment, platform environment202is configured to install, instantiate, and/or provide one or more packages to various logical partitions204(e.g., logical partition204a,logical partition204b,. . . , logical partition204n) hosted by the platform environment202. Any desired package(s)232may be installed and/or provided by platform environment202. When the platform environment202is a JCRE, some example packages232that 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 partitions204; 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 environment202may initialize and/or install any of the various packages on one of the logical partitions (e.g., logical partition204a) to provide corresponding functionality to logical partition204awithout initializing and/or installing the same package on another logical partition (e.g., logical partition204b). As shown inFIG.2, each of the logical partitions204have been provided with the same package functionality, but system200is not limited to this embodiment, and any combination of package installation/provision across the various logical partitions204is possible, in one or more embodiments.

Platform environment202includes a message dispatcher230configured to determine which of the various logical partitions204to send messages from a message stream received by smart card. Message dispatcher230, in one or more embodiments, may be configured to recognize interface switch indicators from the message stream in order to determine which logical partition204to send the next set of messages form the message stream. The message dispatcher230is described in more detail inFIG.3.

Referring again toFIG.2, in one embodiment, platform environment202provides and manages a partition firewall mechanism222which may provide firewall protection (e.g., partition firewall mechanism222a,. . . , partition firewall mechanism222n-1) between the various logical partitions204(e.g., partition firewall mechanism222aseparates logical partition204afrom logical partition204b). Platform environment202operates the partition firewall mechanism222to completely prevent sharing of data and objects between the various logical partitions204.

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

In one embodiment, when the platform environment202is a JCRE, the logical partitions204are logical JCREs (L-JCREs). In this embodiment, each L-JCRE provides and/or hosts an applet space206(e.g., applet space206aon L-JCRE204a,applet space206bon L-JCRE204b,. . . , applet space206non L-JCRE204n,etc.). Each applet space206allows for one or more converted applet (CAP) files (e.g., CAP file210, CAP file216, CAP file224) 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 file210supports context212with applets214(e.g., applet214a,applet214b,. . . , applet214n,etc.). Similarly, CAP file216supports context218with applets220(e.g., applet220a,applet220b,. . . , applet220n,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 spaces206.

Applets provided by the various CAP files are separated from one another by applet firewalls208within a corresponding applet space206(e.g., applet firewall208aseparates applets214provided by CAP file210from applets220provided by CAP file216in applet space206, applet firewall208bseparates applets214provided by CAP file210from applets228provided by CAP file224in applet space206b,etc.). Applet firewalls208are security mechanisms typically implemented in a JCRE. The applet firewalls208each 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 firewall208checks 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 system200. 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 environment202supports a fixed number or a variable number of logical interfaces (e.g., corresponding to the number of interfaces104on terminal102). A same number of logical partitions204are enabled by platform environment202, on a one-to-one basis to the number of interfaces104. In one or more embodiments, terminal102and/or platform environment202may determine a default logical interface that is opened after a smart card/UICC/SIM card reset.

In one or more embodiments, platform environment202manages 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 stream106will be forwarded to the logical partition204that is associated to the active logical interface (e.g., when interface104ais in use, all messages in message stream106will be forwarded to interface profile114acorresponding to a logical interface represented by logical partition204a). Once delivered to the appropriate interface profile114, the commands and/or messages will be handled according to existing rules of the packages installed on the logical partition204associated with the interface profile114(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 system100and/or system200may 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, system100and/or system200may include a data repository (not shown inFIGS.1and2). 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 inFIGS.1and2and/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, system100and/or system200may 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 system100and/or system200. 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++.

3. MESSAGE DISPATCHER

FIG.3illustrates use of a message dispatcher230by a platform environment202, in accordance with one or more embodiments. Platform environment202operates and manages the message dispatcher230in order to properly direct commands and/or messages from a message stream106to their intended destination, which in some embodiments is based on which logical interface104received the message(s) at the terminal102.

In one embodiment, message dispatcher230analyzes a message stream106and directs each message, instruction, request, and/or command included in message stream106to a logical partition204via a logical secure-element interface (LSI). Each LSI logically couples the terminal102with one of the logical partitions204within the platform environment202. which corresponds to a particular logical interface (e.g., directs messages to logical partition204aresponsive to logical interface104abeing the particular logical interface). The messages are sent to this particular logical interface until an interface switch indicator110is read from message stream106. Once the interface switch indicator110is identified, message dispatcher230determines the next logical partition204to send a next set of messages from message stream106. In other words, the next set of messages in message stream106are sent to logical partition204bwhich corresponds to logical interface104bindicated by the interface switch indicator110when the previous messages were directed to logical partition204awhich corresponds to logical interface104a.

In one embodiment, when there are only two logical partitions204, an interface switch indicator110may be a simple flag or marker that indicates to switch to the other logical partition for directing messages that follow the interface switch indictor110in message stream106.

In another embodiment, when more than two logical interfaces104exist on terminal102, which correspond to more than two logical partition204, then an interface switch indicator110may designate which logical interface104received the messages that will follow and/or an associated logical partition204, so that the following messages may be directed to the appropriate logical partition204that will handle the messages for the particular logical interface104. Platform environment202and/or message dispatcher230may identify and maintain correlations between logical interfaces104on terminal102and interface profiles114in the smart card112corresponding to logical partitions204, in one or more embodiments. These correlations may be stored to memory that is accessible to the platform environment202and/or smart card112.

In an embodiment, smart card112may receive message stream106that includes multiple messages108and interface switch indicators110dispersed therein. The message dispatcher230transmits a first subset of messages108afrom message stream106to a first logical partition (e.g., logical partition204a) of the smart card112. Prior to receiving the message stream106, terminal102orders the first subset of messages108ain the message stream106to be received at message dispatcher230prior to a first interface switch indicator110a.Responsive to the message dispatcher230detecting the first interface switch indicator110ain the message stream, message dispatcher230transmits a second subset of messages108bin the message stream106to a second logical partition (e.g., logical partition204b) of the smart card112. Prior to receiving the message stream106, terminal102orders the second subset of messages108bin the message stream106between the first interface switch indicator110aand a second interface switch indicator110b.In response to message dispatcher230detecting the second interface switch indicator110bin the message stream106, message dispatcher230transmits a third subset of messages108cin the message stream106to the first logical partition204aof the smart card112. As shown, the third subset of messages108care ordered in the message stream106by terminal102between the second interface switch indicator110band a third interface switch indicator110c.This switching back and forth between delivering messages to the first logical partition204aand second logical partition204bwill continue as the message dispatcher230processes through the message stream106.

When more than two logical partitions204are present on platform environment202, message dispatcher230will analyze the various interface switch indicators110included in the message stream106to determine which logical partition204to transmit the next subset of messages in the message stream106, up until a next interface switch indicator110is identified.

4. PLATFORM REGISTRY

FIG.4illustrates use of a platform registry402by a platform environment202, in accordance with one or more embodiments. The platform environment202maintains a platform registry402that includes, in a format readable by platform environment202, descriptions of all packages232resident on platform environment202in an embodiment. In addition, every package232installed on the logical partitions204are included in the platform registry402. When the platform environment202is a JCRE and the logical partitions are L-JCREs, the packages232available may include, but are not limited to, JC packages, GP packages, ETSI packages, etc. Platform environment202is configured to selectively make any or all of these various packages232available to the various logical partitions204.

A logical partition204behaves at the applet level in the applet space206and to external devices like an existing platform environment (e.g., a logical partition acts and appears like a platform environment). When the platform environment202is a JCRE, each of the logical partitions204are L-JCREs that appear like their own JCREs to other devices. The platform JCRE202tracks which logical interface is active at any given time. By “active” interface, what is meant is that the message dispatcher230is 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 JCRE202isolates the different L-JCREs204, so that the platform JCRE202operating with any given L-JCRE204behave like a single JCRE instance on a chip. Each L-JCRE204is associated with a logical interface, and this connection is maintained by the platform JCRE202.

According to one embodiment, each logical partition (e.g., L-JCRE)204has a dedicated logical registry406(e.g., logical partition204ahas logical registry406a,logical partition204bhas logical registry406b). In this embodiment, each logical registry view408(e.g., logical registry view408aon logical partition204a,logical registry view408bon logical partition204b) may be obtained as a merge between the platform registry402and the corresponding dedicated logical registry406on the logical partition. In this approach, the platform registry402includes the packages for the platform environment202(e.g., P-JCRE packages) and not any of the packages for the logical partitions204(e.g., L-JCRE packages).

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

Each logical partition204relies on the local logical registry view408to determine which packages232resident on platform environment202may be needed and/or used by the logical partition204to perform some task or operation, in order to get that package and/or installed on the logical partition204. In one embodiment, installer410aon logical partition204ais used to install all packages for logical partition204a.Installer410amay be an instance of platform installer404and/or provided by host platform202based on platform installer404. Similarly, in one embodiment, installer410bon logical partition204bmay be used to install all packages on logical partition204b.Installer410bmay be an instance of platform installer404and/or provided by host platform202based on platform installer404.

Every L-JCRE204has an installer410as the root of all installed packages and applet instances in that L-JCRE204. In cases where an L-JCRE204implements Global Platform, it has an issuer security domain (ISD) as the installer and acting as the root of all security domains in that L-JCRE204.

Every package232that is loaded and applets that are installed in applet space206for a particular L-JCRE204are only associated with the installer410or the ISD of this L-JCRE204(e.g., installer/ISD410on L-JCRE204a). The registry of the L-JCRE204that the ISD can see and that an applet can access, is a combination of the package registry of the platform JCRE202and the package, and the applet's instance registry of the L-JCRE204. In this way, it is possible to have in an L-JCRE204an applet instance or package with the same applet identifier (AID) as in a second L-JCRE204.

5. LOGICAL PARTITION SUPPORT

FIG.5illustrates an example system500that supports logical partitions, in accordance with one or more embodiments. System500includes the platform environment (e.g., JCRE)202on which a plurality of logical partitions (L-JCREs)204a,204b,etc., are supported. Each logical partition204operates its own card application toolkit (CAT) Runtime Environment (CAT-RTE)526(e.g., CAT RTE526aon L-JCRE204a,CAT RTE526bon L-JCRE204b,etc.) and UICC Runtime Environment (UICC RTE)518(e.g., UICC RTE518aon L-JCRE204a,UICC RTE518bon L-JCRE204b,etc.). Above these layers, a number of packages are supported for implementation in each of the logical partitions204. These packages include, but are not limited to, various Java Card Packages510, the UICC.Access Package512, the UICC.Toolkit Package514, and the UICC.System Package516.

Above this layer, each logical partition204also operates a file system and various applications/packages. For example, inFIG.5, each logical partition204is running a UICC file system server502(e.g., UICC file system server502aon L-JCRE204a,UICC file system server502bon L-JCRE204b,etc.), some applications based on ETSI102221(such as SIM applet, USIM applet, etc.) along with an ADF file system server504(e.g., ADF file system server504aon L-JCRE204a,ADF file system server504bon L-JCRE204b,etc.), some other applications506(not based on ETSI102221) (e.g., other apps506aon L-JCRE204a,other apps506bon L-JCRE204b,etc.), and a toolkit applet508(e.g., toolkit applet508aon L-JCRE204a,toolkit applet508bon L-JCRE204b,etc.) such as toolkit service, remote management applications, browser applications, etc.

If an L-JCRE204also implements the CAT RTE526according to ETSI standards, it also maintains a logical Toolkit Registry522, 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-JCRE204. The combination of the UICC RTE518and CAT RTE526comprises a logical interface for a particular logical partition204in one or more embodiments. For example, UICC RTE518aand CAT RTE526awhich includes Toolkit handler520a,Toolkit registry522a,and trigger entity524acomprise the logical interface for logical partition (L-JCRE)204a.

Each UICC RTE518store 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-JCRE204, and makes the handler available to the applets on the L-JCRE204if the associated LSI is the currently opened interface by the terminal102. An LSI is a logical connection between an endpoint in the terminal and one logical partition204within the platform environment202.

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

On a UICC, each L-JCRE204and its specific extension of the CAT-RTE526will ensure that FileView object can only access files that are associated by the UICC operating system to the same logical interface that the L-JCRE204is 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-JCRE204. Therefore, in one embodiment, the platform JCRE202tracks which applet from which L-JCRE204is 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-JCRE204and only under the control of the L-JCRE204relieving the platform JCRE202from 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 JCRE202ensures that only an applet from the same L-JCRE204can access this sensitive data, such as by utilizing partition firewalls.

During any time interval in which no communication occurs (message stream106is empty, connection is interrupted, etc.) over a logical interface, the L-JCRE204will behave like a card that waits for the next command. The L-JCRE204stores the context of the L-JCRE204at 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.

5. EXAMPLE EMBODIMENTS

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

In Operations602and604, the system receives a plurality of messages at a terminal. In Operation602, 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 Operation604, 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 Operations606and608, the system generates a message stream that includes the plurality of messages. In Operation606, 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 Operation608, 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 10 ms to 20 ms 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 15 ms to 25 ms 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 15 ms is sent later than a message received the first subset at 17 ms, but it prevents numerous interface switch indicators from being added to the message stream to switch all messages received from 15 ms to 20 ms across both interfaces.

In Operation610, 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.

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

In Operation702, 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 Operation704, 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 Operation706, 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 Operation708the 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 Operation708, 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 Operation710the 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.

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 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.8illustrates an example set of operations800for applying partition firewalls to multiple logical partitions of a smart card, in accordance with one or more embodiments. One or more operations illustrated inFIG.8may be modified, rearranged, or omitted all together. Accordingly, the particular sequence of operations illustrated inFIG.8should not be construed as limiting the scope of one or more embodiments. Although the operations are described inFIG.8as being executed by a system, any hardware, software, or combination thereof may be used to execute the set of operations800in one or more embodiments.

In Operation802, 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 Operation804, the system hosts a second logical partition of the smart card configured to receive messages received at a second wireless interface.

In Operation806, 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 Operation808, 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.

6. COMPUTER NETWORKS AND CLOUD NETWORKS

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.

7. HARDWARE OVERVIEW

According to one embodiment, the techniques described herein are implemented by one or more special-purpose computing devices. 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. The special-purpose computing devices may be desktop computer systems, portable computer systems, handheld devices, networking devices or any other device that incorporates hard-wired and/or program logic to implement the techniques.

For example,FIG.9is a block diagram that illustrates a computer system900upon which an embodiment of the invention may be implemented. Computer system900includes a bus902or other communication mechanism for communicating information, and a hardware processor904coupled with bus902for processing information. Hardware processor904may be, for example, a general purpose microprocessor.

Computer system900also includes a main memory906, such as a random access memory (RAM) or other dynamic storage device, coupled to bus902for storing information and instructions to be executed by processor904. Main memory906also may be used for storing temporary variables or other intermediate information during execution of instructions to be executed by processor904. Such instructions, when stored in non-transitory storage media accessible to processor904, render computer system900into a special-purpose machine that is customized to perform the operations specified in the instructions.

Computer system900further includes a read only memory (ROM)908or other static storage device coupled to bus902for storing static information and instructions for processor904. A storage device910, such as a magnetic disk or optical disk, is provided and coupled to bus902for storing information and instructions.

Computer system900may be coupled via bus902to a display912, such as a cathode ray tube (CRT), for displaying information to a computer user. An input device914, including alphanumeric and other keys, is coupled to bus902for communicating information and command selections to processor904. Another type of user input device is cursor control916, such as a mouse, a trackball, or cursor direction keys for communicating direction information and command selections to processor904and for controlling cursor movement on display912. This input device typically has two degrees of freedom in two axes, a first axis (e.g., x) and a second axis (e.g., y), that allows the device to specify positions in a plane.

Computer system900may implement the techniques described herein using customized hard-wired logic, one or more ASICs or FPGAs, firmware and/or program logic which in combination with the computer system causes or programs computer system900to be a special-purpose machine. According to one embodiment, the techniques herein are performed by computer system900in response to processor904executing one or more sequences of one or more instructions contained in main memory906. Such instructions may be read into main memory906from another storage medium, such as storage device910. Execution of the sequences of instructions contained in main memory906causes processor904to perform the process steps described herein. In alternative embodiments, hard-wired circuitry may be used in place of or in combination with software instructions.

The term “storage media” as used herein refers to any non-transitory media that store data and/or instructions that cause a machine to operate in a specific fashion. Such storage media may comprise non-volatile media and/or volatile media. Non-volatile media includes, for example, optical or magnetic disks, such as storage device910. Volatile media includes dynamic memory, such as main memory906. 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).

Storage media is distinct from but may be used in conjunction with transmission media. Transmission media participates in transferring information between storage media. For example, transmission media includes coaxial cables, copper wire and fiber optics, including the wires that comprise bus902. Transmission media can also take the form of acoustic or light waves, such as those generated during radio-wave and infra-red data communications.

Various forms of media may be involved in carrying one or more sequences of one or more instructions to processor904for execution. For example, the instructions may initially be carried on a magnetic disk or solid state drive of a remote computer. The remote computer can load the instructions into its dynamic memory and send the instructions over a telephone line using a modem. A modem local to computer system900can receive the data on the telephone line and use an infra-red transmitter to convert the data to an infra-red signal. An infra-red detector can receive the data carried in the infra-red signal and appropriate circuitry can place the data on bus902. Bus902carries the data to main memory906, from which processor904retrieves and executes the instructions. The instructions received by main memory906may optionally be stored on storage device910either before or after execution by processor904.

Computer system900also includes a communication interface918coupled to bus902. Communication interface918provides a two-way data communication coupling to a network link920that is connected to a local network922. For example, communication interface918may be an integrated services digital network (ISDN) card, cable modem, satellite modem, or a modem to provide a data communication connection to a corresponding type of telephone line. As another example, communication interface918may be a local area network (LAN) card to provide a data communication connection to a compatible LAN. Wireless links may also be implemented. In any such implementation, communication interface918sends and receives electrical, electromagnetic or optical signals that carry digital data streams representing various types of information.

Network link920typically provides data communication through one or more networks to other data devices. For example, network link920may provide a connection through local network922to a host computer924or to data equipment operated by an Internet Service Provider (ISP)926. ISP926in turn provides data communication services through the world wide packet data communication network now commonly referred to as the “Internet”928. Local network922and Internet928both use electrical, electromagnetic or optical signals that carry digital data streams. The signals through the various networks and the signals on network link920and through communication interface918, which carry the digital data to and from computer system900, are example forms of transmission media.

Computer system900can send messages and receive data, including program code, through the network(s), network link920and communication interface918. In the Internet example, a server930might transmit a requested code for an application program through Internet928, ISP926, local network922and communication interface918.

The received code may be executed by processor904as it is received, and/or stored in storage device910, or other non-volatile storage for later execution.

8. MISCELLANEOUS; EXTENSIONS

Embodiments 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 and/or recited in any of the claims below.

In an embodiment, 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 and/or recited in any of the claims.

Any combination of the features and functionalities described herein may be used in accordance with one or more embodiments. In the foregoing specification, embodiments have been described with reference to numerous specific details that may vary from implementation to implementation. The specification and drawings are, accordingly, to be regarded in an illustrative rather than a restrictive sense. The sole and exclusive indicator of the scope of the invention, and what is intended by the applicants to be the scope of the invention, is the literal and equivalent scope of the set of claims that issue from this application, in the specific form in which such claims issue, including any subsequent correction.