Abstract: In general, in one aspect, the invention relates to a method for executing applications. The method includes accessing a secure storage element via a host device including a computer processor; executing, by the computer processor, a hosted execution runtime environment (HERE) on the host device; identifying a persistent memory image of the HERE within the secure storage element; executing, by the computer processor, an application using the HERE; and applying, based on executing the application, a first set of changes to the persistent memory image.

Abstract: In general, in one aspect, the invention relates to a method for executing applications. The method includes accessing a secure storage element via a host device including a computer processor; executing, by the computer processor, a hosted execution runtime environment (HERE) on the host device; identifying a persistent memory image of the HERE within the secure storage element; executing, by the computer processor, an application using the HERE; and applying, based on executing the application, a first set of changes to the persistent memory image.

Abstract: An authentication mechanism is provided to authenticate both client and user of a portable computing device when the user causes a client to request a protected resource on the portable computing device. Upon receiving a request a protected resource by the client, the authentication mechanism determines which authentication method is specified for authentication of the client, and authenticates the client accordingly. Upon a determination that the client is authentic, the authentication mechanism invokes a user interface that is separate and distinct from the client to solicit input from the user. Based on the input solicited from the user, the authentication mechanism determines whether the user is an authentic user of the portable computing device. If it is determined that the user is an authentic user, the authentication mechanism determines based on an indication from the user whether the client should be authorized to access the protected resource requested.

Abstract: To execute legacy smart card applications in a next generation smart card environment, a mechanism converts the applications into a format executable by the next generation smart card platforms. For instance, in a Java-based environment, a normalizer tool translates a CAP file into a Java Class file. Additional mechanisms recreate, on next generation smart cards, a specialized environment that allows the legacy applications to execute without impacting legacy and non-legacy application performance. For example, mechanisms create new instances of previously shared objects so that legacy applications can continue to expect exclusive access to those objects. Moreover, mechanisms manage the communication between a legacy application and non-legacy applications by controlling how and when calls are sent to the legacy application.

Abstract: A access control mechanism is provided on a computing device to allow an application provider to set up a declarative security policy specific to an application module. When a runtime environment of the computing device receives a request from a second application instance in a second execution context to access a protected resource in a first application instance, the runtime environment invokes the access control mechanism to determine, based on a protection-domain-level domain security policy, whether the second application instance is allowed to access protected resources in the first execution context. If so, the runtime environment invokes the access control mechanism to determine, based on a declarative security policy for a first application module associated with the first application instance, whether the second application instance is allowed to access the protected resource. If so, the runtime environment allows the second application instance access to the protected resource requested.

Abstract: In a smart card system in which applications executing in different execution contexts are allowed to communicate with each other only through shareable interface objects (SIO's), a registry mechanism is provided to mediate in inter-application communication between legacy applets, extended applets and servlets. A request by a client application for a SIO of a server application in a different execution context is routed to the registry mechanism by the system. Dependent on what types the client and server applications are, the registry mechanism provides call interfaces as would be expected by the applications to enable passing the SIO from the server application to the client application. In one embodiment, servlets and extended applets may also register and unregister their SIOs dynamically with the registration mechanism.

Abstract: To execute legacy smart card applications in a next generation smart card environment, a mechanism converts the applications into a format executable by the next generation smart card platforms. For instance, in a Java-based environment, a normalizer tool translates a CAP file into a Java Class file. Additional mechanisms recreate, on next generation smart cards, a specialized environment that allows the legacy applications to execute without impacting legacy and non-legacy application performance. For example, mechanisms create new instances of previously shared objects so that legacy applications can continue to expect exclusive access to those objects. Moreover, mechanisms manage the communication between a legacy application and non-legacy applications by controlling how and when calls are sent to the legacy application.

Abstract: A method for transaction approval includes submitting a transaction approval request from a transaction site to a clearing agency; submitting a user authorization request from the clearing agency to a user device; receiving a response to the user authorization request; and sending a response to the transaction approval request from the clearing agency to the transaction site. Another method for transaction approval includes submitting a transaction approval request from a transaction site to a clearing agency; determining whether a trusted transaction is elected; submitting a user authorization request from the clearing agency to a user device, if a trusted transaction is determined to be elected; receiving a response to the user authorization request from the user device, if the user authentification request was submitted; and sending a response to the transaction approval request from the clearing agency to the transaction site.