Deferred Executor for Secure Element Command Latency
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing Java Card Applet execution in Secure Elements is inefficient due to time-consuming operations, leading to increased Secure Element command handling time, host wait time, and power consumption, as they are single-threaded and cannot parallelize tasks, limiting performance improvements.
Innovation Solution
Implementing a deferred procedure execution mechanism within the Secure Element's Java Card Runtime Environment, where time-consuming operations are grouped and scheduled for execution during idle or standby times, using a software module called the Deferred Executor, which creates a Deferred Procedure object to execute tasks after initial task completion and status reporting to the host.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If Java Card Applet execution processes all operations synchronously in single-threaded environment, then security and simplicity are maintained, but command handling time and host wait time increase significantly
Solution Approach 1:
The patent applies preliminary action by executing time-consuming operations (such as cryptographic computations) in advance during idle periods before they are actually needed. The Deferred Executor schedules and performs these operations during standby times, so that when the host needs the results, they are already available, thus reducing command handling time without compromising security.
Solution Approach 2:
The patent implements periodic action by utilizing idle or standby periods periodically to execute deferred operations. The system alternates between active command processing and idle periods, using the idle periods to perform time-consuming tasks. This periodic execution pattern optimizes resource utilization and reduces overall processing time while maintaining the single-threaded secure environment.
2Device complexity
If Java Card Applet execution processes all operations synchronously in single-threaded environment, then system simplicity is maintained, but host wait time increases
Solution Approach 1:
The patent introduces an intermediary component called the Deferred Executor that acts as a mediator between the host and the applet operations. This intermediary schedules and executes time-consuming operations during idle periods, shielding the host from waiting delays while maintaining the simplicity of the existing Java Card API and single-threaded architecture. The host interacts with the same simple interface, but the intermediary optimizes execution timing in the background.
3Speed
If Secure Element processes commands immediately without deferral, then real-time responsiveness is maintained, but power consumption increases due to continuous active processing
Solution Approach 1:
The patent applies periodic action by alternating between active processing and idle/standby states. Time-consuming operations are scheduled to execute during idle periods when the Secure Element would otherwise be inactive. This allows the system to enter low-power states more frequently while still completing necessary computations, thereby reducing overall power consumption without significantly impacting real-time responsiveness for critical operations.
Solution Approach 2:
The Deferred Executor enables the Secure Element to perform self-service by autonomously scheduling and executing time-consuming operations during its own idle periods without requiring continuous host intervention. This self-managed execution allows the system to optimize its own power consumption by performing computations when energy resources are available, rather than maintaining continuous active processing.
4Productivity
If time-consuming operations are executed immediately upon receiving APDU command, then operational throughput is maintained, but idle time is wasted and performance is limited
Solution Approach 1:
The patent implements continuity of useful action by eliminating idle time through the Deferred Executor, which continuously utilizes available processing capacity. Instead of leaving the Secure Element idle during standby periods, the system continuously performs useful computations by scheduling time-consuming operations during these periods. This ensures that every moment of processing capacity contributes to productive work, maximizing operational throughput without extending overall command handling time.
Data Source
AI summary
Described is a method for performing the execution of an application in a Secure Element (SE), comprising a host sending an APDU command to the SE comprising the application, processing at the SE the APDU command for execution by the application, performing a determined plurality of operations of the application commanded by the APDU command, the application determining among the plurality of application operations commanded by the APDU command a first set of operations to be executed by the application upon receiving the APDU command and at least a second set of operations. The SE performs the first set of operations to be executed by the application upon receiving the APDU command, performing a deferred execution of a second set of operations upon communication of completion of the execution of the first set of operations from the SE to the host.