Abstract: Techniques are described herein for applying access controls to logical secure elements (LSEs) running on the same secure element hardware platform. Embodiments include a firmware component that determines whether a message targeting an LSE is authorized to trigger an operation. For example, the firmware component may verify a signature of the received message using a public key, shared secret, or other access control key. Additionally or alternatively, access control policies may be defined to constrain the load of the LSEs on the SE platform hardware and/or to prioritize LSE access. For example, the access control policies may define usage thresholds, such as maximum threshold memory and/or processor utilization rates. As another example, the access controls may restrict the active time for an LSE to a threshold duration. If access constraints are violated or the message cannot be verified, then the firmware component may delay or deny the operation.

Abstract: Techniques are described herein for running multiple logical secure elements (LSEs) on the same physical secure element (SE) hardware. For example, embodiments may include running multiple logical Subscriber Identification Modules (SIM) cards on the same physical SIM card or universal integrated circuit card (UICC). Additionally or alternatively, embodiments may include running other secure element applications and services on the same SE hardware. The techniques allow for mobile devices users to access multiple security services, which may originate from different security service providers (SSPs), in a secure manner using the same SE hardware without requiring the integration of multiple physical slots on a mobile device or the physical exchange of different cards within the same slot.

Abstract: Techniques are disclosed for generating a message stream configured to indicate a source of the various messages within the message stream. In particular, the indicators identify which interface the messages were received at a terminal (e.g., of a mobile handset). The terminal receives messages on various interfaces, and separates the messages received via different interfaces with interface switch indicators within the message stream. In one embodiment, the smart card 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 single 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.

Abstract: Suspending and resuming a card runtime environment for a card computing device are disclosed. A card computing device obtains a suspension request. The suspension request includes a proposed value for a minimum suspension interval and/or a proposed value for a maximum suspension interval. The suspension request is accepted or rejected, by the card computing device, based on the proposed value for the minimum suspension interval and/or the proposed value for the maximum suspension interval. The card computing device may negotiate a different value for the maximum suspension interval. Additionally, a card computing device obtains a resumption request. The resumption request includes a resume token. The card computing device determines whether the resume token in the resumption request is valid. The card computing device determines whether the suspension interval is valid. The card computing device resumes the state that was associated with the card computing device at the time of suspension.

Abstract: Suspending and resuming a card runtime environment for a card computing device are disclosed. A card computing device obtains a suspension request. The suspension request includes a proposed value for a minimum suspension interval and/or a proposed value for a maximum suspension interval. The suspension request is accepted or rejected, by the card computing device, based on the proposed value for the minimum suspension interval and/or the proposed value for the maximum suspension interval. The card computing device may negotiate a different value for the maximum suspension interval. Additionally, a card computing device obtains a resumption request. The resumption request includes a resume token. The card computing device determines whether the resume token in the resumption request is valid. The card computing device determines whether the suspension interval is valid. The card computing device resumes the state that was associated with the card computing device at the time of suspension.

Abstract: A CAS device receives streaming media content encrypted utilizing a CAS, decrypts the received streaming media content utilizing a CAS module associated with the CAS, and transmits the unencrypted streaming media content to a rendering device. The CAS device may be operable to receive and store an additional CAS module associated with an additional CAS. The CAS device may also be operable to receive unencrypted streaming media content, encrypt the streaming media content utilizing a CAS module, and transmit the encrypted streaming media content. In another embodiment, the CAS device receives streaming media content encrypted utilizing a first CAS, decrypts the received streaming media content utilizing a first CAS module, transmits the unencrypted streaming media content from the first CAS module to a second CAS module, encrypts the unencrypted streaming media content utilizing the second CAS module, and transmits the encrypted streaming media content to a rendering device.

Abstract: A persistence management system facilitates porting servlet-based applications, such as Web applications, to an extremely mobile/nomadic system such as a resource-constrained device platform, e.g., a smart card, where sessions on a card acceptance device are intermittent by nature. Persistence management system (i) minimizes the startup time, and (ii) restores applications in a consistent state. The persistent management system supports: a) selective persistence of servlet model objects: both container-managed objects and application-managed objects; b) optional persistence of threads; and c) optional persistence of connection objects.

Abstract: A generic event notification service for a resource-constrained device is provided. One method includes receiving an event having a unique event identifier, and determining whether an event-producing application is authorized to fire the event. Upon a determination of authorization to fire the event, a determination is made whether any event-consuming applications are authorized by the event-producing application to receive the event. Upon a determination of authorization to receive the event, the event is forwarded to each authorized event-consuming application. In this manner, secure, flexible, generic, and uniform application interaction is facilitated.