WO2024056132A1 - Rest state mode for smart cards - Google Patents

Rest state mode for smart cards Download PDF

Info

Publication number
WO2024056132A1
WO2024056132A1 PCT/DE2023/100684 DE2023100684W WO2024056132A1 WO 2024056132 A1 WO2024056132 A1 WO 2024056132A1 DE 2023100684 W DE2023100684 W DE 2023100684W WO 2024056132 A1 WO2024056132 A1 WO 2024056132A1
Authority
WO
WIPO (PCT)
Prior art keywords
smart card
terminal
sleep
maximum
command
Prior art date
Application number
PCT/DE2023/100684
Other languages
German (de)
French (fr)
Inventor
Rushikesh SHINGNAPURKAR
Martin RÖSNER
Original Assignee
Giesecke+Devrient Mobile Security Germany Gmbh
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Giesecke+Devrient Mobile Security Germany Gmbh filed Critical Giesecke+Devrient Mobile Security Germany Gmbh
Publication of WO2024056132A1 publication Critical patent/WO2024056132A1/en

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W52/00—Power management, e.g. TPC [Transmission Power Control], power saving or power classes
    • H04W52/02—Power saving arrangements
    • H04W52/0209—Power saving arrangements in terminal devices
    • H04W52/0225—Power saving arrangements in terminal devices using monitoring of external events, e.g. the presence of a signal
    • H04W52/0229—Power saving arrangements in terminal devices using monitoring of external events, e.g. the presence of a signal where the received signal is a wanted signal
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F1/00—Details not covered by groups G06F3/00 - G06F13/00 and G06F21/00
    • G06F1/26—Power supply means, e.g. regulation thereof
    • G06F1/32—Means for saving power
    • G06F1/3203—Power management, i.e. event-based initiation of a power-saving mode
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F1/00—Details not covered by groups G06F3/00 - G06F13/00 and G06F21/00
    • G06F1/26—Power supply means, e.g. regulation thereof
    • G06F1/32—Means for saving power
    • G06F1/3203—Power management, i.e. event-based initiation of a power-saving mode
    • G06F1/3206—Monitoring of events, devices or parameters that trigger a change in power modality
    • G06F1/3209—Monitoring remote activity, e.g. over telephone lines or network connections
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F1/00—Details not covered by groups G06F3/00 - G06F13/00 and G06F21/00
    • G06F1/26—Power supply means, e.g. regulation thereof
    • G06F1/32—Means for saving power
    • G06F1/3203—Power management, i.e. event-based initiation of a power-saving mode
    • G06F1/3234—Power saving characterised by the action undertaken
    • G06F1/325—Power saving in peripheral device
    • G06F1/3278—Power saving in modem or I/O interface
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W52/00—Power management, e.g. TPC [Transmission Power Control], power saving or power classes
    • H04W52/02—Power saving arrangements
    • H04W52/0209—Power saving arrangements in terminal devices
    • H04W52/0225—Power saving arrangements in terminal devices using monitoring of external events, e.g. the presence of a signal
    • H04W52/0235—Power saving arrangements in terminal devices using monitoring of external events, e.g. the presence of a signal where the received signal is a power saving command
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W52/00—Power management, e.g. TPC [Transmission Power Control], power saving or power classes
    • H04W52/02—Power saving arrangements
    • H04W52/0209—Power saving arrangements in terminal devices
    • H04W52/0261—Power saving arrangements in terminal devices managing power supply demand, e.g. depending on battery level
    • H04W52/0274—Power saving arrangements in terminal devices managing power supply demand, e.g. depending on battery level by switching on or off the equipment or parts thereof
    • H04W52/028—Power saving arrangements in terminal devices managing power supply demand, e.g. depending on battery level by switching on or off the equipment or parts thereof switching on or off only a part of the equipment circuit blocks

Definitions

  • a smart card is a card with an embedded integrated circuit (IC), often referred to as a chip or microprocessor.
  • IC embedded integrated circuit
  • Embedded IC is used for products such as credit and debit cards, transportation cards, SIM cards, ID cards, etc., providing data storage, additional security and functionality.
  • a smart card is also called a Universal Integrated Circuit Card/Integrated SIM (UICC/iUICC/iSIM).
  • the UICC has a Card Application Toolkit (CAT) that provides a set of applications and procedures that can be used during a card session with the UICC.
  • CAT Card Application Toolkit
  • An example of a CAT is described in technical specification 102 223 of the ETSI (European Telecommunications Standards Institute).
  • the CAT enables the applications present in the UICC to interact and operate with any terminal, user equipment or other mobile network device that supports the specific mechanisms required by the applications running on the smart card.
  • mobile network devices such as B. smart meters, trackers, wearable devices and smartphones, it is desirable to keep energy consumption low in order to extend the useful life of such devices.
  • Conventional solutions implement a UICC suppression mechanism that allows the end device to suppress the UICC when access is not required.
  • a method for implementing a sleep mode for the smart card is provided on a smart card, the smart card being communicatively coupled to a terminal device.
  • the method includes the steps of receiving a sleep trigger command from the terminal, determining a maximum sleep time, providing the maximum sleep time to the terminal, and entering a sleep mode.
  • a method for implementing a sleep mode for a smart card is provided at a terminal, the smart card being communicatively coupled to the terminal.
  • the method includes the steps of sending a sleep trigger command to the smart card, receiving a maximum sleep time from the smart card, storing the maximum sleep time, and sending a power-on or wake-up command to the smart card after the maximum sleep time has elapsed.
  • the end device obtains the maximum sleep time allowed for a smart card and, in the event of a long duration trigger event, sends the smart card to sleep for the maximum allowed duration, thereby providing optimal power management to the end device. Since the smart card sets the length of time it remains in sleep mode itself, it expects the After waking up, the smart card does not receive a resumption command from the end device to resume operation.
  • the sleep trigger command is a parameterized Application Protocol Data Unit (APDU) command that includes a parameter to indicate the sleep mode.
  • APDU Application Protocol Data Unit
  • the hibernate trigger command is a modified UICC SUSPEND command that includes a plurality of parameters, with a particular parameter of the plurality of parameters being set to indicate the suspend mode. This enables a standardized way to support hibernation through the CAT tool set.
  • the smart card includes a variety of applications.
  • the smart card determines the maximum sleep time by obtaining a maximum sleep time from each of the plurality of applications, where the maximum sleep time of an application indicates the length of time the application is allowed to sleep, and by obtaining the lowest value from the plurality of maximum sleep times as the maximum sleep time. This ensures that no application, in particular no critical application, is active that would require processing while the smart card remains in idle mode.
  • memory contents and CPU registers of the smart card are securely stored before the smart card enters sleep mode. By backing up the memory contents and CPU registers, the state of the smart card can be safely saved before it enters sleep, so that the smart card or its operating system can immediately resume operation from the saved state upon waking without having to receive a resume command from the end device.
  • the contents of the memory and the CPU registers are encrypted and decrypted using firmware that is provided by the terminal device, in particular by a modem of the terminal device, via an interface between the terminal device and the smart card.
  • firmware that is provided by the terminal device, in particular by a modem of the terminal device, via an interface between the terminal device and the smart card.
  • the smart card or its operating system starts from the state in which it was put into hibernation, hibernation would also work in the case of an iUICC, since part of the main memory (RAM) is shared with the end device's modem and the iUICC so that the shared memory benefits from battery backup. In this case, RAM recovery would be done by the modem.
  • the terminal sends a power-on or wake-up command to the smart card after the maximum sleep time has elapsed.
  • the smart card After the smart card receives the power-on or wake-up command from the end device, it decrypts the memory contents and the CPU registers and restores them. The smart card can thus resume operation immediately without requiring another resume command from the terminal, as no resume feature is required as in the traditional SUSPEND/RESUME-based CAT implementation becomes. By encrypting and decrypting the secured content, neither the end device nor the smart card needs to carry out an additional verification step after operations are resumed. Preferably, the smart card decrypts the contents of the memory and CPU registers and restores them using the firmware provided by the terminal modem.
  • the smart card sends a request to the terminal to extend a preset polling interval based on the maximum sleep time, the polling interval indicating a frequency of receiving a status command from the terminal.
  • the terminal extends the polling interval to a new value that corresponds to the maximum idle time.
  • the terminal sends a modified SUSPEND command that indicates a terminal-defined sleep time to the plurality of applications on the smart card.
  • the modified SUSPEND command includes a plurality of parameters, with a particular parameter from the plurality of parameters being set to indicate the defined sleep time. This allows the smart card to enter subsequent sleep modes as needed without having to re-determine the maximum sleep time from scratch.
  • an apparatus for implementing a sleep mode for a smart card is provided, the smart card being communicatively coupled to a terminal and having a plurality of applications running thereon.
  • the device includes a receiving unit, a processing unit and a memory.
  • the receiving unit is configured to receive a sleep trigger command from the terminal.
  • the processing unit is configured to determine a maximum sleep time by obtaining a maximum sleep time from each of the plurality of applications, where the maximum sleep time of an application indicates a duration that the application is allowed to sleep for select the lowest value from the plurality of maximum sleep times as the maximum sleep time to provide the maximum sleep time to the terminal and to cause the smart card to enter a sleep mode.
  • the processing unit is configured to encrypt and secure the contents of the smart card's memory and CPU registers before entering sleep mode.
  • the processing unit is configured to send to the terminal a request to extend a preset polling interval based on the maximum sleep time, the polling interval being the frequency of receiving a status command from the terminal at the Smart card indicates.
  • a smart card which includes the device according to the third aspect.
  • the smart card carries out the method according to the first aspect when it is connected to a terminal according to the second aspect.
  • FIG. 1 shows a block diagram of a CAT framework for implementing a sleep mode for a smart card, according to an embodiment of the invention
  • 2 shows a flowchart of a method for implementing a sleep mode for a smart card, according to an embodiment of the invention
  • FIGS.3 to 5 show preferred implementations of steps of the method in FIG.2, according to various embodiments of the invention
  • 6 shows a schematic diagram of the three embodiments of the method for implementing a sleep mode in a smart card
  • FIG.7 shows the communication flow between the terminal and the smart card according to embodiments of the invention in comparison to the suppression method defined by ETSI.
  • DETAILED DESCRIPTION Detailed explanations of the present invention are given below with reference to the accompanying drawings which illustrate specific embodiments of the present invention.
  • FIG. 1 shows a block diagram of a CAT framework for implementing a sleep mode for a smart card according to an embodiment of the invention.
  • the CAT framework allows applications present on the UICC or smart card 20 to interact and work with a terminal 10.
  • the communication between the UICC 20 and the terminal 10 can be implemented via a modem 12 of the terminal 10.
  • the UICC 20 can be connected to the modem 12 via the terminal UICC interface 14, via which CAT commands are transmitted between the terminal and the UICC.
  • a device 200 is located within the UICC 20 to implement a sleep mode for the UICC.
  • the device 200 includes a receiving unit 201, a processing unit 202 and a memory 202.
  • the receiving unit 201 is configured to receive various commands, notifications and/or events from the terminal 10 via the interface 14.
  • the receiving unit 201 can be configured to function as a transmitting unit and Sends control data to the end device.
  • An example of such control data that the device 200 can make available to the terminal 10 is the maximum idle state time of the UICC 20, as described further below in connection with FIG. 2.
  • FIG.2 shows a flowchart of a method for implementing a sleep mode for a smart card, such as the UICC 20 in FIG.1, according to an embodiment of the invention.
  • the smart card 20 is connected/coupled to the terminal 10 either by being in the terminal 10 or by other means, such as. B.
  • the smart card 20 receives a sleep state trigger command from the terminal.
  • the terminal 10 sends the sleep trigger command to inform the smart card 20 of a long-duration event during which the smart card does not perform any activity and may enter a sleep mode. That is, the sleep trigger command can be viewed as a trigger event to put the smart card into a sleep state.
  • the sleep trigger is sent via a parameterized Application Protocol Data Unit (APDU) command that includes a parameter to indicate the sleep mode.
  • APDU Application Protocol Data Unit
  • the suspend command can be implemented by modifying the SUSPEND UICC command specified in ETSI TS 102221 V16.3.0 as follows: TABLE 1.
  • the present invention proposes to use the bits of Use P1 to indicate to the smart card that it should enter sleep mode.
  • P1 is set to the hexadecimal value “80”, but any other flag value can be used as long as it is supported by both the terminal and the UICC.
  • the UICC 20 determines the maximum sleep time that the smart card is allowed to remain in sleep mode in step S2. The maximum allowable sleep time of the smart card depends on the requirements of the applications running on it. Some applications may have business logic that requires predefined execution that must run after a specified time.
  • an IoT device may only connect to the network once a month and send back little data, e.g. B. an intelligent measuring device (SmartMeter) for gas or water. Therefore, the UICC collects the maximum duration of all of these applications for which applications are allowed to sleep and selects the minimum of these Time spans as the maximum allowable sleep time for the smart card to serve all applications running on it.
  • a preferred implementation for determining the maximum idle time is shown in FIG.3. Referring to FIG. 3, in step S21, after receiving the sleep trigger command in step S1, the UICC 20 determines all applications running on the UICC. For each of the identified applications, the UICC determines the maximum sleep time in a subsequent step S22, ie the respective maximum time that the application is allowed to sleep.
  • the maximum sleep time of an application generally depends on the type of application and can be preset/preconfigured when the application is loaded onto the smart card.
  • the UICC selects the sleep time with the lowest value as the maximum sleep time MHT from all the sleep times determined in step S22.
  • the maximum sleep time, MHT is then sent to the terminal 10 in step S3 of FIG. 2.
  • the sleep time or the maximum sleep time can also be configurable on the UICC, e.g. B. in applets, in the file system and/or in objects.
  • the terminal stores the received maximum idle time, MHT, in memory. After the UICC 20 has informed the terminal of the maximum idle time, it switches to the idle mode in step S8.
  • the UICC 20 may request the terminal 10 to set a polling interval previously negotiated between the terminal and the UICC.
  • the polling interval is defined in ETSI TS 102223 V14.0.0 and indicates how often the terminal device sends STATUS commands to the UICC during an idle mode.
  • Polling interval negotiations as currently specified in the ETSI TS 102223 V14.0.0 standard specification, support a maximum duration of four hours. In contrast, hibernation can last up to a few days. Therefore, the available CAT mechanism for negotiating the polling interval using the proactive POLL INTERVAL command based on ETSI TS 102223 V14.0.0 does not support the default sleep time exceeding four hours.
  • the UICC 20 is configured such that it checks the polling interval in step S4 and requests the terminal in step S6 to extend the polling interval to the duration of the idle state.
  • a preferred embodiment of this method is shown in FIG.4.
  • the UICC checks whether a polling interval has already been negotiated with the terminal and checks whether the preset value of the polling interval is below the maximum idle time. If the value of the polling interval is below the maximum idle time, PI ⁇ MHT, the UICC sends the request to the terminal in step S6 to extend the standard polling interval.
  • the UICC prepares to transition to sleep mode.
  • FIG.5(a) A preferred one Embodiment for implementing the sleep preparation steps is shown in FIG.5(a).
  • the UICC saves the internal random access memory (RAM) contents and the CPU registers, which are stored in, for example, a retention RAM (step S82).
  • RAM random access memory
  • the main memory contents and the CPU registers are encrypted before the backup is carried out (step S81).
  • the Advanced Encryption Standard Galois/Counter Mode (AES-GCM) algorithm can be used for this purpose.
  • the encryption and security operations are performed via the firmware of the modem 12.
  • the encryption/decryption step is optional.
  • Other means of securely storing memory contents and CPU registers can also be used, such as: B. the use of MRAM. If the internal memory is backed up by a battery, encryption/decryption may become unnecessary.
  • the UICC During hibernation mode, the UICC is turned off or has very low power. This makes the hibernation mode different from the standard SUSPEND mode of a smart card. While the smart card still consumes power in standard suppression mode, the smart card consumes no energy at all when in idle mode, which reduces the overall energy consumption of the end device. If the smart card is a passive device, it must be woken up by the end device after the sleep time has expired. For this purpose, the terminal 10 sends a switch-on/wake-up notification, as shown in step S9 in FIG.2. The wake-up notification can be sent to the UICC encapsulated in an APDU command. If the UICC was switched off during the idle state, the terminal 10 sends a switch-on command instead in step S9.
  • the UICC 20 After receiving the wake-up or power-on command, the UICC 20 performs a wake-up step S10. A preferred implementation of the wake-up step is shown in FIG.5(b).
  • the UICC 20 retrieves the content stored in step S82 from memory in step S91, decrypts the retrieved content in step S92, and restores the memory content and CPU registers to the pre-sleep state in step S93. These steps can be carried out with the firmware provided by the modem 12 of the terminal 10. By restoring the smart card to its pre-hibernation state, the context of the smart card operating system can be restored to resume operation in the same pre-hibernation state. No additional steps are required, such as: B.
  • the smart card is an integrated UICC (iUICC), its main memory (RAM) is shared with the terminal modem, so battery backup of the main memory is a way to save the contents of the smart card before it goes into sleep mode is relocated.
  • the smart card can instruct the modem to perform state recovery.
  • the smart card is an active device, the smart card can automatically wake up after the sleep time expires without requiring a command from the terminal modem.
  • Embodiments of the method for implementing a sleep mode in a smart card or UICC may be performed by a device 200 within the UICC 20, as shown in FIG. 1.
  • the device comprises at least a receiving unit 201, a processing unit 202 and a memory 203.
  • the receiving unit 201 is configured so that it receives the idle state trigger command from the terminal 10 via the interface 14 (step S1 in FIG. 2).
  • the processing unit 202 is configured to process the received command and perform the steps described above in connection with Figures 2 to 5 to cause the smart card to enter sleep mode.
  • the processing unit 202 has access to the firmware provided by the modem 12 and is configured to encrypt and decrypt the contents of the memory 203 for the pre- and post-hibernation backup and restore process.
  • the processing unit 202 is configured to send the request to the terminal 10 to extend the preset polling interval based on the maximum sleep time.
  • FIG. 6 shows a schematic diagram of an overview of embodiments of the method for implementing a hibernation mode in a smart card or UICC.
  • the terminal 10 preferably via its modem 12, notifies the smart card 20 of a trigger event that has a long duration.
  • a trigger event include an ENVELOPE command (CAT event, ETSI 102223), e.g. E.g. extending a standard event or using a proprietary flag/event.
  • the notification may be provided to the smart card in the form of the sleep trigger command in step S1 of FIG.2.
  • the event allows the SIM card to enter sleep mode during this time.
  • the smart card 20 returns the maximum sleep time (FIG.2, step S3) after which the smart card wakes up/is woken up (FIG.2, steps S9, S10).
  • FIG. 6(b) shows an embodiment for extending a standard POLL INTERVAL command beyond four hours as shown in steps S4 and S6 in FIG. 2 and steps S41 and S42 in FIG. 4 is implemented.
  • the terminal 10 Upon receipt of the request to extend the polling interval, stores the new polling interval to cover the maximum sleep time provided by the smart card. This prevents the end device from sending STATUS commands while the smart card is in idle state, as the smart card sends them cannot process commands during sleep mode, further reducing the energy consumption of the end device.
  • FIG.2 shows an embodiment for extending a standard POLL INTERVAL command beyond four hours as shown in steps S4 and S6 in FIG. 2 and steps S41 and S42 in FIG. 4 is implemented.
  • 6(c) shows an embodiment of the implementation of the extended SUSPEND command to specify the maximum sleep time for the variety of applications on the smart card.
  • the P1 bits can be used to communicate the maximum idle time.
  • the command only specifies the sleep duration to customer applications and does not trigger any operations related to suspend and resume.
  • This command can also be used to instruct the smart card to initiate subsequent sleep modes as needed, without requiring the smart card to determine the maximum sleep time from scratch. This avoids unnecessary calculation steps on the smart card, which further reduces the energy consumption of the end device.
  • FIG.7 shows a comparison of the communication flow between the terminal and the UICC in the conventional suppression method, as described in ETSI TS 102241 V16.1.0 (FIG.7(b)), with the communication flow for implementing the idle state method according to of the present invention (FIG. 7(a)).
  • Step 120 “UICC Suspend*”: This is the sleep trigger command implemented as a modified SUSPEND command of the UICC.
  • the expected process within the UICC is briefly shown in TABLE 2. This command puts the smart card/UICC into sleep mode. It indicates the sleep mode as in step S1 of FIG.2. This command can also be used to specify an idle state time defined by the terminal device.
  • - Step 130 “OK/Max. Sleep time”: Response from the UICC to the end device. The UICC informs the end device of the maximum idle time, MHT. If the modified SUSPEND command that the UICC received in step 120 already specifies a sleep time, the UICC simply returns OK in step 130.
  • - Step 140 “Power Off/Sleep Period”: Based on the device-specific mechanism, the UICC is turned off during the specified sleep time, MHT.
  • Step 150 “Power On*”: In addition to the traditional power on operation for each UICC, this power on command returns the UICC to the previous state before sleep. That is, this command causes the UICC to perform the wake-up steps shown in FIG.5(b).
  • - Step 160 “Usual exchange of commands”: After switching on the UICC and restoring the pre-idle state, the usual communication process between the end device and UICC can take place.
  • the aspects and embodiments described herein may be implemented with the assistance of a modem designer or chip vendor or other entity to which the UICC is coupled.
  • the provision of battery-backed memory and the memory mechanism to implement sleep mode are therefore device specific.
  • the hibernation state is transparent to the operating system (OS).
  • Hibernation mode suspends the running operating system, saves the system state and data, and resumes operation of the operating system after waking up.
  • low-level drivers can process the sleep request and resume operation transparently to the operating system.
  • Additional functions to support the idle state can be implemented on the modem.
  • the modem may not start a sleep request during the execution of an open USAT procedure, ie a USIM/SIM Application Toolkit according to ETSI/3GPP. Additionally, the modem may decide to start the sleep request even if a time event is pending.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Power Sources (AREA)

Abstract

Exemplary embodiments of a method and a device for implementing a rest state mode for a smart card are provided. A rest state trigger command is received on the smart card by a terminal with which the smart card is in communicative connection. On the smart card, a maximum rest state time is determined and transmitted to the terminal, as a result of which the smart card transitions to the rest state mode.

Description

K 94733-7 G+D EM 5243 Ruhezustandsmodus für Smartcards Die vorliegende Erfindung bezieht sich allgemein auf Smartcards (Chipkar- ten) und insbesondere auf beispielhafte Ausführungsformen zur Implemen- tierung eines Ruhezustandsmodus für Smartcards. HINTERGRUND DER ERFINDUNG Smartcards werden weltweit in einer Vielzahl von Anwendungen eingesetzt. Eine Smartcard ist eine Karte mit einer eingebetteten integrierten Schaltung (IC), die oft auch als Chip oder Mikroprozessor bezeichnet wird. Die einge- bettete IC wird für Produkte wie Kredit- und Debitkarten, Transportkarten, SIM-Karten, Ausweiskarten usw. verwendet und bietet Datenspeicherung, zusätzliche Sicherheit und Funktionalität. Eine Smartcard wird auch als Uni- versal Integrated Circuit Card/Integrated SIM (UICC/iUICC/iSIM) bezeich- net. Die UICC verfügt über einen Kartenanwendungswerkzeugsatz (Card Appli- cation Toolkit - CAT), der eine Reihe von Anwendungen und Verfahren be- reitstellt, die während einer Kartensitzung mit der UICC verwendet werden können. Ein Beispiel für einen CAT ist in der technischen Spezifikation 102 223 des ETSI (European Telecommunications Standards Institute) beschrie- ben. Der CAT ermöglicht den in der UICC vorhandenen Anwendungen die Interaktion und den Betrieb mit allen Endgeräten, Benutzerausrüstungen oder anderen Mobilfunknetzgeräten, die die spezifischen Mechanismen un- terstützen, die von den auf der Smartcard laufenden Anwendungen benötigt werden. Bei Mobilfunknetzgeräten, wie z. B. intelligenten Zählern, Trackern, Wearab- les (tragbaren Geräten) und Smartphones, ist es wünschenswert, den Ener- gieverbrauch niedrig zu halten, um die Nutzungsdauer solcher Geräte zu verlängern. Herkömmliche Lösungen implementieren einen UICC-Unterdrückungsme- chanismus, der es dem Endgerät ermöglicht, die UICC zu unterdrücken, wenn ein Zugriff nicht erforderlich ist. Es gibt jedoch keine standardisierten UICC-Befehle, die ein Modem-Chipsatz eines Endgeräts unterstützen sollte, um einen optimierten Energieverbrauch als Voraussetzung für eine lange Lebensdauer der Gerätebatterie zu errei- chen. Bestehende UICC/SIM-Funktionen sind nur begrenzt oder gar nicht verfügbar, um einen sehr geringen oder gar keinen Energieverbrauch wäh- rend der Unterdrückung zu ermöglichen. Darüber hinaus ist der derzeit vom CAT-Werkzeugsatz unterstützte Unterdrückungsmechanismus weniger fle- xibel, da er auf eine feste, voreingestellte Unterdrückungsdauer beschränkt ist, die längere Zeiten von Inaktivität nicht berücksichtigt, was dazu führt, dass die Smartcard auch dann mit Energie versorgt wird, wenn sie nicht ak- tiv genutzt wird. Es ist daher wünschenswert, eine Lösung zu finden, die die oben genannten Defizite bei der Optimierung des Energieverbrauchs einer Smartcard in einer Vorrichtung behebt. BESCHREIBUNG DER ERFINDUNG Die vorliegende Erfindung löst die oben genannte Aufgabe durch den Ge- genstand der unabhängigen Ansprüche. Bevorzugte Ausführungsformen der Erfindung sind in den abhängigen Ansprüchen definiert. Gemäß einem ersten Aspekt der vorliegenden Erfindung wird an einer Smartcard ein Verfahren zum Implementieren eines Ruhezustandsmodus für die Smartcard bereitgestellt, wobei die Smartcard kommunikativ mit einem Endgerät gekoppelt ist. Das Verfahren umfasst die Schritte des Empfangens eines Ruhezustandsauslösebefehls von dem Endgerät, des Bestimmens einer maximalen Ruhezustandszeit, des Bereitstellens der maximalen Ruhezu- standszeit für das Endgerät und des Eintretens in einen Ruhezustandsmo- dus. Gemäß einem zweiten Aspekt der vorliegenden Erfindung wird an einem Endgerät ein Verfahren zum Implementieren eines Ruhezustandsmodus für eine Smartcard bereitgestellt, wobei die Smartcard kommunikativ mit dem Endgerät gekoppelt ist. Das Verfahren umfasst die Schritte des Sendens eines Ruhezustandsauslösebefehls an die Smartcard, des Empfangens einer maxi- malen Ruhezustandszeit von der Smartcard, des Speicherns der maximalen Ruhezustandszeit und des Sendens eines Einschalt- oder Aufweckbefehls an die Smartcard, nachdem die maximale Ruhezustandszeit abgelaufen ist. Durch die Verwendung des Ruhezustandsauslösebefehls erhält das Endgerät die maximale für eine Smartcard zulässige Ruhezustandszeit und schickt die Smartcard im Falle eines Auslöseereignisses von langer Dauer für die maxi- mal zulässige Dauer in den Ruhezustand, wodurch eine optimale Energie- verwaltung dem Endgerät bereitgestellt wird. Da die Smartcard die Dauer des Verweilens im Ruhezustandsmodus selbst einstellt, erwartet die Smartcard nach dem Aufwachen keinen Wiederaufnahmebefehl von dem Endgerät, um den Betrieb wieder aufzunehmen. In einigen Ausführungsformen der vorliegenden Erfindung ist der Ruhezu- standsauslösebefehl ein parametrisierter Anwendungsprotokoll-Datenein- heit (APDU - Application Protocol Data Unit) -Befehl, der einen Parameter zur Angabe des Ruhezustandsmodus umfasst. Vorzugsweise ist der Ruhezustandsauslösebefehl ein modifizierter UICC- UNTERDRÜCKUNG (SUSPEND) -Befehl, der eine Vielzahl von Parametern umfasst, wobei ein spezieller Parameter aus der Vielzahl von Parametern eingestellt wird, um den Ruhezustandsmodus anzuzeigen. Dies ermöglicht einen standardisierten Weg zur Unterstützung des Ruhezu- stands durch den CAT-Werkzeugsatz. In einigen Ausführungsformen der vorliegenden Erfindung umfasst die Smartcard eine Vielzahl von Anwendungen. Die Smartcard bestimmt die maximale Ruhezustandszeit, indem sie von jeder der Vielzahl von Anwen- dungen eine maximale Schlafzeit erhält, wobei die maximale Schlafzeit einer Anwendung die Dauer angibt, die die Anwendung schlafen darf, und indem sie den niedrigsten Wert aus der Vielzahl der maximalen Schlafzeiten als die maximale Ruhezustandszeit auswählt. Dadurch wird sichergestellt, dass für die Dauer des Verweilens im Ruhezu- standsmodus der Smartcard keine Anwendung, insbesondere keine kritische Anwendung, aktiv ist, die eine Verarbeitung erfordern würde. In einigen Ausführungsformen der vorliegenden Erfindung werden ein Spei- cherinhalt und CPU-Register der Smartcard sicher gespeichert, bevor die Smartcard in den Ruhezustandsmodus übergeht. Durch die Sicherung des Speicherinhalts und der CPU-Register kann der Zu- stand der Smartcard vor dem Eintreten in den Ruhezustand auf sichere Weise gespeichert werden, so dass die Smartcard bzw. ihr Betriebssystem nach dem Aufwachen sofort den Betrieb aus dem gespeicherten Zustand wieder aufnehmen kann, ohne dass ein Wiederaufnahmebefehl vom Endge- rät empfangen werden muss. Vorzugsweise wird der Inhalt des Speichers und der CPU-Register mit Hilfe von Firmware verschlüsselt und entschlüsselt, die vom Endgerät, insbeson- dere von einem Modem des Endgeräts, über eine Schnittstelle zwischen dem Endgerät und der Smartcard bereitgestellt wird. Da die Smartcard bzw. ihr Betriebssystem von dem Zustand aus startet, in dem sie in den Ruhezustand versetzt wurde, würde der Ruhezustand auch im Falle einer iUICC funktionieren, da ein Teil des Arbeitsspeichers (RAM) gemeinsam mit dem Modem des Endgeräts und der iUICC genutzt wird, so dass der gemeinsam genutzte Arbeitsspeicher von der Batteriesicherung pro- fitiert. In diesem Fall würde die Wiederherstellung des Arbeitsspeichers durch das Modem erfolgen. In einigen Ausführungsformen der vorliegenden Erfindung sendet das End- gerät nach Ablauf der maximalen Ruhezustandszeit einen Einschalt- oder Aufweckbefehl an die Smartcard. Nachdem die Smartcard den Einschalt- oder Aufweckbefehl vom Endgerät erhalten hat, entschlüsselt sie den Spei- cherinhalt und die CPU-Register und stellt sie wieder her. Die Smartcard kann somit den Betrieb sofort wieder aufnehmen, ohne dass ein weiterer Wiederaufnahmebefehl vom Endgerät erforderlich ist, da kein Wiederauf- nahme-Merkmal wie bei der herkömmlichen UNTERDRÜCKUNGS-/WIE- DERAUFNAHME-basierten (SUSPEND/RESUME -basierten) CAT-Imple- mentierung benötigt wird. Durch das Ver- und Entschlüsseln der gesicherten Inhalte muss weder vom Endgerät noch von der Smartcard nach der Wiederaufnahme des Betriebs ein zusätzlicher Verifikationsschritt durchgeführt werden. Vorzugsweise entschlüsselt die Smartcard den Inhalt des Speichers und der CPU-Register und stellt ihn mithilfe der vom Endgerätmodem bereitgestell- ten Firmware wieder her. In einigen Ausführungsformen der vorliegenden Erfindung sendet die Smartcard eine Anfrage an das Endgerät, ein voreingestelltes Abfrageinter- vall basierend auf der maximalen Ruhezustandszeit zu verlängern, wobei das Abfrageintervall eine Häufigkeit des Empfangs eines Statusbefehls vom Endgerät angibt. Vorzugsweise verlängert das Endgerät das Abfrageintervall auf einen neuen Wert, der der maximalen Ruhezustandszeit entspricht. In einigen Ausführungsformen der vorliegenden Erfindung sendet das End- gerät einen modifizierten UNTERDRÜCKUNG (SUSPEND) -Befehl, der eine vom Endgerät definierte Ruhezustandszeit an die Vielzahl von Anwendun- gen auf der Smartcard anzeigt. Vorzugsweise umfasst der modifizierte UN- TERDRÜCKUNG (SUSPEND) -Befehl eine Vielzahl von Parametern, wobei ein bestimmter Parameter aus der Vielzahl von Parametern so eingestellt wird, dass er die definierte Ruhezustandszeit anzeigt. Dadurch kann die Smartcard bei Bedarf in nachfolgende Ruhezustandsmodi eintreten, ohne dass die maximale Ruhezustandszeit von Grund auf neu be- stimmt werden muss. Unnötige Berechnungsschritte auf der Smartcard wer- den damit vermieden, was den Energieverbrauch des Endgeräts weiter redu- ziert. Das Endgerät kann die Ruhezustandszeit basierend auf der zuvor von der Smartcard empfangenen maximalen Ruhezustandszeit definieren oder einen neuen Wert für die Ruhezustandszeit einstellen, um alle zuvor gespei- cherten Werte zu überschreiben. Gemäß einem dritten Aspekt der vorliegenden Erfindung wird eine Vorrich- tung zum Implementieren eines Ruhezustandsmodus für eine Smartcard be- reitgestellt, wobei die Smartcard kommunikativ mit einem Endgerät gekop- pelt ist und eine Vielzahl von darauf laufenden Anwendungen aufweist. Die Vorrichtung umfasst eine Empfangseinheit, eine Verarbeitungseinheit und einen Speicher. Die Empfangseinheit ist so konfiguriert, dass sie von dem Endgerät einen Ruhezustandsauslösebefehl empfängt. Die Verarbeitungsein- heit ist so konfiguriert, dass sie eine maximale Ruhezustandszeit bestimmt, indem sie von jeder der Vielzahl von Anwendungen eine maximale Schlaf- zeit erhält, wobei die maximale Schlafzeit einer Anwendung eine Dauer an- gibt, die die Anwendung schlafen darf, um den niedrigsten Wert aus der Vielzahl von maximalen Schlafzeiten als die maximale Ruhezustandszeit auszuwählen, um die maximale Ruhezustandszeit an das Endgerät bereitzu- stellen und um zu bewirken, dass die Smartcard in einen Ruhezustandsmo- dus eintritt. In einigen Ausführungsformen der vorliegenden Erfindung ist die Verarbei- tungseinheit so konfiguriert, dass sie den Inhalt des Speichers und der CPU- Register der Smartcard verschlüsselt und sichert, bevor sie in den Ruhezu- standsmodus übergeht. In einigen Ausführungsformen der vorliegenden Erfindung ist die Verarbei- tungseinheit so konfiguriert, dass sie an das Endgerät eine Anfrage zur Ver- längerung eines voreingestellten Abfrageintervalls basierend auf der maxi- malen Ruhezustandszeit sendet, wobei das Abfrageintervall die Häufigkeit des Empfangs eines Statusbefehls vom Endgerät an der Smartcard angibt. Gemäß einem vierten Aspekt der vorliegenden Erfindung wird eine Smart- card bereitgestellt, die die Vorrichtung gemäß dem dritten Aspekt umfasst. Vorzugsweise führt die Smartcard das Verfahren gemäß dem ersten Aspekt aus, wenn sie mit einem Endgerät gemäß dem zweiten Aspekt verbunden ist. Weitere Aspekte, Merkmale und Vorteile der vorliegenden Erfindung wer- den dem Fachmann bei der Durchsicht der folgenden detaillierten Beschrei- bung der bevorzugten Ausführungsformen und Varianten der vorliegenden Erfindung in Verbindung mit den beigefügten Figuren ersichtlich. KURZE BESCHREIBUNG DER ZEICHNUNGEN Es wird nun auf die beigefügten Figuren verwiesen, in denen: FIG.1 ein Blockdiagramm eines CAT-Rahmenwerks zur Implementierung eines Ruhezustandsmodus für eine Smartcard zeigt, gemäß einer Ausfüh- rungsform der Erfindung; FIG.2 ein Flussdiagramm eines Verfahrens zur Implementierung eines Ru- hezustandsmodus für eine Smartcard zeigt, gemäß einer Ausführungsform der Erfindung; FIGs.3 bis 5 bevorzugte Implementierungen von Schritten des Verfahrens in FIG.2 zeigen, gemäß verschiedenen Ausführungsformen der Erfindung; FIG.6 ein schematisches Diagramm der drei Ausführungsformen des Ver- fahrens zur Implementierung eines Ruhezustandsmodus in einer Smartcard zeigt; und FIG.7 den Kommunikationsfluss zwischen dem Endgerät und der Smartcard gemäß Ausführungsformen der Erfindung im Vergleich zu dem von ETSI definierten Unterdrückungsverfahren zeigt. AUSFÜHRLICHE BESCHREIBUNG Detaillierte Erläuterungen zur vorliegenden Erfindung werden im Folgenden unter Bezugnahme auf die beigefügten Zeichnungen gegeben, die spezifische Ausführungsbeispiele der vorliegenden Erfindung veranschaulichen. Diese Ausführungsformen sind ausreichend detailliert beschrieben, um dem Fach- mann die Möglichkeit zu geben, die Erfindung zu praktizieren. Es ist zu ver- stehen, dass die verschiedenen Ausführungsformen der vorliegenden Erfin- dung, obwohl sie unterschiedlich sind, sich nicht unbedingt gegenseitig aus- schließen. So kann zum Beispiel ein bestimmtes Merkmal, eine bestimmte Struktur oder eine bestimmte Eigenschaft, die hierin in Verbindung mit einer Ausführungsform beschrieben werden, in anderen Ausführungsformen im- plementiert werden, ohne dass dies vom Umfang der vorliegenden Erfin- dung abweicht. Darüber hinaus ist es zu verstehen, dass die Position oder die Anordnung einzelner Elemente innerhalb jeder offenbarten Ausfüh- rungsform modifiziert werden kann, ohne vom Umfang der vorliegenden Erfindung abzuweichen. Die folgende detaillierte Beschreibung ist daher nicht in einem einschränkenden Sinne zu verstehen, und der Umfang der vorliegenden Erfindung wird nur durch die beigefügten Ansprüche defi- niert, die angemessen interpretiert werden, zusammen mit dem gesamten Bereich der Äquivalente, auf die sich die Ansprüche beziehen. In den Zeich- nungen beziehen sich gleiche Ziffern auf die gleiche oder ähnliche Funktio- nalität in den verschiedenen Ansichten. Im Folgenden bezeichnen die Ausdrücke „UICC“, „iUICC“, „SIM“, „iSIM“, „Smartcard“ dieselbe Einheit und werden austauschbar verwendet. FIG.1 zeigt ein Blockdiagramm eines CAT-Rahmenwerks zur Implementie- rung eines Ruhezustandsmodus für eine Smartcard gemäß einer Ausfüh- rungsform der Erfindung. Das CAT- Rahmenwerk ermöglicht es Anwendungen, die auf der UICC oder der Smartcard 20 vorhanden sind, mit einem Endgerät 10 zu interagieren und zu arbeiten. Die Kommunikation zwischen der UICC 20 und dem End- gerät 10 kann über ein Modem 12 des Endgeräts 10 realisiert werden. Die UICC 20 kann mit dem Modem 12 über die Endgerät-UICC-Schnittstelle 14 verbunden werden, über die CAT-Befehle zwischen dem Endgerät und der UICC übertragen werden. Eine Vorrichtung 200 ist innerhalb der UICC 20 angeordnet, um einen Ruhe- zustandsmodus für die UICC zu implementieren. Die Vorrichtung 200 um- fasst eine Empfangseinheit 201, eine Verarbeitungseinheit 202 und einen Speicher 202. Die Empfangseinheit 201 ist so konfiguriert, dass sie von dem Endgerät 10 über die Schnittstelle 14 verschiedene Befehle, Benachrichtigun- gen und/oder Ereignisse empfängt. Darüber hinaus kann die Empfangsein- heit 201 so konfiguriert sein, dass sie als Sendeeinheit fungiert und Steuerdaten an das Endgerät sendet. Ein Beispiel für solche Steuerdaten, die die Vorrichtung 200 dem Endgerät 10 zur Verfügung stellen kann, ist die ma- ximale Ruhezustandszeit der UICC 20, wie weiter unten in Verbindung mit FIG.2 beschrieben wird. FIG.2 zeigt ein Flussdiagramm eines Verfahrens zur Implementierung eines Ruhezustandsmodus für eine Smartcard, wie die UICC 20 in FIG.1, gemäß einer Ausführungsform der Erfindung. Die Smartcard 20 ist mit dem Endge- rät 10 verbunden/gekoppelt, indem sie sich entweder im Endgerät 10 befin- det oder durch andere Mittel, wie z. B. einen zwischengeschalteten Kartenle- ser. In einem Schritt S1 empfängt die Smartcard 20 vom Endgerät einen Ruhezu- standsauslösebefehl. Das Endgerät 10 sendet den Ruhezustandsauslösebe- fehl, um die Smartcard 20 über ein Ereignis von langer Dauer zu informieren, während dessen die Smartcard keine Aktivitäten ausführt und in einen Schlafmodus übergehen kann. Das heißt, der Ruhezustandsauslösebefehl kann als Auslöseereignis betrachtet werden, um die Smartcard in einen Ru- hezustand zu versetzen. Vorzugsweise wird der Ruhezustandsauslöser über einen parametrisierten Anwendungsprotokoll-Dateneinheit (APDU - Application Protocol Data Unit) -Befehl gesendet, der einen Parameter zur Angabe des Ruhezustands- modus enthält. Vorzugsweise kann der Ruhezustandsbefehl durch Abänderung des in ETSI TS 102221 V16.3.0 spezifizierten UNTERDRÜCKUNG (SUSPEND) -UICC- Befehls wie folgt implementiert werden:
Figure imgf000014_0001
TABELLE 1. Ruhezustandsbefehl Im Gegensatz zum herkömmlichen UNTERDRÜCKUNG (SUSPEND) -Be- fehl gemäß ETSI TS 102221, bei dem kein Wert für den Parameter P1 gesetzt wird, sondern dieser für die künftige Verwendung reserviert bleibt, schlägt die vorliegende Erfindung vor, die Bits von P1 zu verwenden, um der Smart- card anzuzeigen, dass sie in den Ruhezustandsmodus eintreten soll. Im obi- gen Beispiel ist P1 auf den hexadezimalen Wert „80“ gesetzt, es kann jedoch auch jeder andere Kennzeichen-Wert verwendet werden, solange er sowohl vom Endgerät als auch von der UICC unterstützt wird. Nach Erhalt des Ruhezustandsauslösebefehls bestimmt die UICC 20 in Schritt S2 die maximale Ruhezustandszeit, die die Smartcard im Ruhezu- standsmodus bleiben darf. Die maximal zulässige Ruhezustandszeit der Smartcard hängt von den An- forderungen ab, die von den darauf laufenden Anwendungen gestellt wer- den. Einige Anwendungen verfügen möglicherweise über eine Geschäftslo- gik, die eine vordefinierte Ausführung benötigen, die nach einer festgelegten Zeit ausgeführt werden muss. Eine IoT-Vorrichtung mag sich beispielsweise nur einmal im Monat mit dem Netzwerk verbinden und wenige Daten zu- rücksenden, z. B. ein intelligentes Messgerät (SmartMeter) für Gas oder Was- ser. Daher sammelt die UICC die maximale Dauer aller dieser Anwendun- gen, für die Anwendungen schlafen dürfen, und wählt das Minimum dieser Zeitspannen als maximal zulässige Ruhezustandszeit für die Smartcard, um alle darauf laufenden Anwendungen zu bedienen. Eine bevorzugte Implementierung zur Bestimmung der maximalen Ruhezu- standszeit ist in FIG.3 dargestellt. Mit Bezug auf FIG.3 bestimmt die UICC 20 in Schritt S21 nach dem Empfan- gen des Ruhezustandsauslösebefehls in Schritt S1 alle auf der UICC laufen- den Anwendungen. Für jede der identifizierten Anwendungen bestimmt die UICC in einem nachfolgenden Schritt S22 die maximale Schlafzeit, d. h. die jeweilige maximale Zeit, die die Anwendung schlafen darf. Die maximale Schlafzeit einer Anwendung hängt im Allgemeinen von der Art der Anwen- dung ab und kann beim Laden der Anwendung auf die Smartcard voreinge- stellt/vorkonfiguriert werden. In Schritt S23 wählt die UICC aus allen in Schritt S22 bestimmten Schlafzeiten die Schlafzeit mit dem niedrigsten Wert als maximale Ruhezustandszeit MHT aus. Die maximale Ruhezustandszeit, MHT, wird dann in Schritt S3 von FIG.2 an das Endgerät 10 gesendet. Die Ruhezustandszeit bzw. die maximale Ruhezustandszeit kann auch auf der UICC konfigurierbar sein, z. B. in Applets, im Dateisystem und/oder in Objekten. Zurück zu FIG.2, speichert das Endgerät in Schritt S5 die empfangene maxi- male Ruhezustandszeit, MHT, im Speicher. Nachdem die UICC 20 dem Endgerät die maximale Ruhezustandszeit mitge- teilt hat, geht sie in Schritt S8 in den Ruhezustandsmodus über. Optional kann die UICC 20 vor dem Eintritt in den Ruhezustandsmodus das Endgerät 10 auffordern, ein zuvor zwischen dem Endgerät und der UICC ausgehandeltes Abfrageintervall einzustellen. Das Abfrageintervall ist in ETSI TS 102223 V14.0.0 definiert und gibt an, wie oft das Endgerät während eines Leerlaufmodus STATUS-Befehle an die UICC sendet. Abfrageintervall- Verhandlungen, wie sie derzeit in der Standardspezifikation ETSI TS 102223 V14.0.0 festgelegt sind, unterstützen eine maximale Dauer von vier Stunden. Im Gegensatz dazu kann der Ruhezustand bis zu einigen Tagen dauern. Da- her unterstützt der verfügbare CAT-Mechanismus für die Aushandlung des Abfrageintervalls unter Verwendung des proaktiven Befehls ABFRAGEIN- TERVALL (POLL INTERVALL) auf der Grundlage von ETSI TS 102223 V14.0.0 nicht die Voreinstellung einer Ruhezustandszeit, die vier Stunden überschreitet. Um diesen Mangel zu beheben, ist die UICC 20 so konfiguriert, dass sie in Schritt S4 das Abfrageintervall überprüft und in Schritt S6 das Endgerät auf- fordert, das Abfrageintervall auf die Dauer des Ruhezustands zu verlängern. Eine bevorzugte Ausführungsform dieses Verfahrens ist in FIG.4 dargestellt. In Schritt S41 prüft die UICC, ob bereits ein Abfrageintervall mit dem Endge- rät ausgehandelt wurde, und prüft, ob der voreingestellte Wert des Abfra- geintervalls unter der maximalen Ruhezustandszeit liegt. Liegt der Wert des Abfrageintervalls unter der maximalen Ruhezustandszeit, PI < MHT, sendet die UICC in Schritt S6 die Anfrage an das Endgerät, das Standardabfragein- tervall zu verlängern. Unter Bezugnahme auf FIG.2 bereitet sich die UICC in Schritt S8 auf den Übergang in den Ruhezustandsmodus vor. Eine bevorzugte Ausführungsform für die Implementierung der Vorbereitungsschritte für den Ruhezustand ist in FIG.5(a) dargestellt. Unter Bezugnahme auf FIG.5(a) sichert die UICC vor dem Übergang in den Ruhezustand den internen Arbeitsspeicher (RAM - Random Access Memory) -Inhalt und die CPU-Register, die beispielsweise in einem Zurückbehaltungs- Arbeitsspeicher gespeichert werden (Schritt S82). Vorzugsweise werden der Arbeitsspeicher-Inhalt und die CPU-Register vor der Durchführung der Si- cherung verschlüsselt (Schritt S81). Zu diesem Zweck kann der Algorithmus Advanced Encryption Standard Galois/Counter Mode (AES-GCM) verwen- det werden. Vorzugsweise werden die Verschlüsselungs- und Sicherungsvorgänge über die Firmware des Modems 12 durchgeführt. Der Schritt der Verschlüsselung/Entschlüsselung ist optional. Es können auch andere Mittel zur sicheren Speicherung von Speicherinhalten und CPU- Registern eingesetzt werden, wie z. B. die Verwendung von MRAM. Wenn der interne Arbeitsspeicher durch eine Batterie gesichert ist, kann die Ver- schlüsselung/Entschlüsselung überflüssig werden. Während des Ruhezustandsmodus ist die UICC ausgeschaltet oder wird nur mit sehr geringer Energie versorgt. Damit unterscheidet sich der Ruhezu- standsmodus vom Standard-UNTERDRÜCKUNG (SUSPEND) -Modus einer Smartcard. Während die Smartcard im Standard-Unterdrückung-Modus noch Strom verbraucht, verbraucht die Smartcard im Ruhezustand über- haupt keine Energie, was den Gesamtenergieverbrauch des Endgeräts redu- ziert. Handelt es sich bei der Smartcard um eine passive Vorrichtung, muss sie nach Ablauf der Ruhezustandszeit vom Endgerät aufgeweckt werden. Zu diesem Zweck sendet das Endgerät 10 eine Einschalt-/Aufweckbenachrichti- gung, wie in Schritt S9 in FIG.2 dargestellt. Die Aufweckbenachrichtigung kann in einem APDU-Befehl gekapselt an die UICC gesendet werden. Wenn die UICC während des Ruhezustands ausgeschaltet war, sendet das Endge- rät 10 in Schritt S9 stattdessen einen Einschaltbefehl. Nach Erhalt des Aufweck- oder Einschaltbefehls führt die UICC 20 einen Aufweckschritt S10 durch. Eine bevorzugte Implementierung des Aufweck- schritts ist in FIG.5(b) dargestellt. Die UICC 20 ruft in Schritt S91 den in Schritt S82 gespeicherten Inhalt aus dem Speicher ab, entschlüsselt in Schritt S92 den abgerufenen Inhalt und stellt in Schritt S93 den Arbeitsspeicher-In- halt und die CPU-Register des Zustands vor dem Ruhezustand wieder her. Diese Schritte können mit der vom Modem 12 des Endgeräts 10 bereitgestell- ten Firmware durchgeführt werden. Durch die Wiederherstellung des Zu- stands der Smartcard vor dem Eintritt in den Ruhezustand kann der Kontext des Smartcard-Betriebssystems wiederhergestellt werden, um den Betrieb in demselben Zustand vor dem Eintritt in den Ruhezustand wieder aufzuneh- men. Es sind keine zusätzlichen Schritte erforderlich, wie z. B. ein Verifizie- rungsschritt, der weder vom Endgerät noch von der Smartcard durchgeführt werden muss. Handelt es sich bei der Smartcard um eine integrierte UICC (iUICC), wird ihr Arbeitsspeicher (RAM) gemeinsam mit dem Endgerätmodem genutzt, so dass eine Batteriepufferung des Arbeitsspeichers eine Möglichkeit ist, den In- halt der Smartcard zu speichern, bevor sie in den Ruhezustand versetzt wird. Nach Erhalt des Aufweckbefehls kann die Smartcard das Modem anweisen, die Wiederherstellung des Zustands durchzuführen. Wenn die Smartcard eine aktive Vorrichtung ist, kann die Smartcard nach Ablauf der Ruhezustandszeit automatisch aufwachen, ohne dass ein Befehl vom Endgerätmodem erforderlich ist. Ausführungsformen des Verfahrens zur Implementierung eines Ruhezu- standsmodus in einer Smartcard oder UICC können von einer Vorrichtung 200 innerhalb der UICC 20 durchgeführt werden, wie in FIG.1 dargestellt. Die Vorrichtung umfasst mindestens eine Empfangseinheit 201, eine Verar- beitungseinheit 202 und einen Speicher 203. Die Empfangseinheit 201 ist so konfiguriert, dass sie über die Schnittstelle 14 vom Endgerät 10 den Ruhezustandsauslösebefehl empfängt (Schritt S1 in FIG.2). Die Verarbeitungseinheit 202 ist so konfiguriert, dass sie den empfangenen Befehl verarbeitet und die oben in Verbindung mit den Figuren 2 bis 5 be- schriebenen Schritte durchführt, um die Smartcard zu veranlassen, in den Ruhezustandsmodus einzutreten. Die Verarbeitungseinheit 202 hat Zugriff auf die vom Modem 12 bereitge- stellte Firmware und ist so konfiguriert, dass sie den Inhalt des Speichers 203 für den Sicherungs- und Wiederherstellungsprozess vor und nach dem Ru- hezustand verschlüsselt und entschlüsselt. Außerdem ist die Verarbeitungseinheit 202 so konfiguriert, dass sie die An- frage zur Verlängerung des voreingestellten Abfrageintervalls basierend auf der maximalen Ruhezustandszeit an das Endgerät 10 sendet. FIG.6 zeigt in einem schematischen Diagramm eine Übersicht über Ausfüh- rungsformen des Verfahrens zur Implementierung eines Ruhezustandsmo- dus in einer Smartcard oder UICC. Unter Bezugnahme auf FIG.6(a) benachrichtigt das Endgerät 10, vorzugs- weise über sein Modem 12, die Smartcard 20 über ein Auslöseereignis, das eine lange Dauer hat. Beispiele für ein Auslöseereignis sind ein UMSCHLAG (ENVELOPE) -Befehl (CAT-Ereignis, ETSI 102223), z. B. die Erweiterung ei- nes Standardereignisses oder die Verwendung eines proprietären Kennzei- chens/Ereignisses. Die Benachrichtigung kann der Smartcard in Form des Ruhezustandsauslösebefehls in Schritt S1 von FIG.2 übermittelt werden. Das Ereignis ermöglicht es der SIM-Karte, während dieser Zeit in den Ruhezu- standsmodus überzugehen. Die Smartcard 20 gibt die maximale Ruhezu- standszeit zurück (FIG.2, Schritt S3), nach der die Smartcard aufwacht/auf- geweckt wird (FIG.2, Schritte S9, S10). FIG.6(b) zeigt eine Ausführungsform zur Verlängerung eines Standard-AB- FRAGEINTEVALL (POLL INTERVAL) -Befehls über vier Stunden hinaus, wie sie in den Schritten S4 und S6 in FIG.2 sowie in den Schritten S41 und S42 in FIG.4 implementiert ist. Nach Erhalt der Anfrage, das Abfrageinter- vall zu verlängern, speichert das Endgerät 10 das neue Abfrageintervall, um die von der Smartcard vorgesehene maximale Ruhezustandszeit abzude- cken. Dadurch wird verhindert, dass das Endgerät während des Ruhezu- stands der Smartcard STATUS-Befehle sendet, da die Smartcard diese Befehle während des Ruhezustands nicht verarbeiten kann, wodurch der Energieverbrauch des Endgeräts weiter gesenkt wird. FIG.6(c) zeigt eine Ausführungsform der Implementierung des erweiterten UNTERDRÜCKUNG (SUSPEND) -Befehls zur Angabe der maximalen Ruhe- zustandszeit für die Vielzahl von Anwendungen auf der Smartcard. Auch hier können die P1-Bits verwendet werden, um die maximale Ruhezustands- zeit mitzuteilen. In dieser Ausführungsform gibt der Befehl den Kundenan- wendungen nur die Dauer des Ruhezustands an und löst keine Vorgänge aus, die mit dem Aussetzen und Wiederaufnehmen zusammenhängen. Mit diesem Befehl kann die Smartcard auch angewiesen werden, bei Bedarf nachfolgende Ruhezustandsmodi einzuleiten, ohne dass die Smartcard die maximale Ruhezustandszeit von Grund auf neu bestimmen muss. Unnötige Berechnungsschritte auf der Smartcard werden damit vermieden, was den Energieverbrauch des Endgeräts weiter reduziert. FIG.7 zeigt einen Vergleich des Kommunikationsflusses zwischen dem End- gerät und der UICC im konventionellen Unterdrückungsverfahren, wie es in ETSI TS 102241 V16.1.0 beschrieben ist (FIG.7(b)), mit dem Kommunikati- onsfluss zur Implementierung des Ruhzustandsverfahrens gemäß der vorlie- genden Erfindung (FIG.7(a)). K 94733-7 G+D EM 5243 Sleep mode for smart cards The present invention relates generally to smart cards (chip cards) and in particular to exemplary embodiments for implementing a sleep mode for smart cards. BACKGROUND OF THE INVENTION Smart cards are used worldwide in a variety of applications. A smart card is a card with an embedded integrated circuit (IC), often referred to as a chip or microprocessor. Embedded IC is used for products such as credit and debit cards, transportation cards, SIM cards, ID cards, etc., providing data storage, additional security and functionality. A smart card is also called a Universal Integrated Circuit Card/Integrated SIM (UICC/iUICC/iSIM). The UICC has a Card Application Toolkit (CAT) that provides a set of applications and procedures that can be used during a card session with the UICC. An example of a CAT is described in technical specification 102 223 of the ETSI (European Telecommunications Standards Institute). The CAT enables the applications present in the UICC to interact and operate with any terminal, user equipment or other mobile network device that supports the specific mechanisms required by the applications running on the smart card. For mobile network devices, such as B. smart meters, trackers, wearable devices and smartphones, it is desirable to keep energy consumption low in order to extend the useful life of such devices. Conventional solutions implement a UICC suppression mechanism that allows the end device to suppress the UICC when access is not required. However, there are no standardized UICC commands that a modem chipset of a terminal device should support in order to achieve optimized energy consumption as a prerequisite for a long service life of the device battery. Existing UICC/SIM functions are limited or not available at all to enable very low or no power consumption during suppression. Additionally, the suppression mechanism currently supported by the CAT toolset is less flexible as it is limited to a fixed, preset suppression duration that does not take into account extended periods of inactivity, resulting in the smart card being powered even when it is not actively used. It is therefore desirable to find a solution that addresses the above-mentioned deficiencies in optimizing the energy consumption of a smart card in a device. DESCRIPTION OF THE INVENTION The present invention solves the above-mentioned problem through the subject matter of the independent claims. Preferred embodiments of the invention are defined in the dependent claims. According to a first aspect of the present invention, a method for implementing a sleep mode for the smart card is provided on a smart card, the smart card being communicatively coupled to a terminal device. The method includes the steps of receiving a sleep trigger command from the terminal, determining a maximum sleep time, providing the maximum sleep time to the terminal, and entering a sleep mode. According to a second aspect of the present invention, a method for implementing a sleep mode for a smart card is provided at a terminal, the smart card being communicatively coupled to the terminal. The method includes the steps of sending a sleep trigger command to the smart card, receiving a maximum sleep time from the smart card, storing the maximum sleep time, and sending a power-on or wake-up command to the smart card after the maximum sleep time has elapsed. By using the sleep trigger command, the end device obtains the maximum sleep time allowed for a smart card and, in the event of a long duration trigger event, sends the smart card to sleep for the maximum allowed duration, thereby providing optimal power management to the end device. Since the smart card sets the length of time it remains in sleep mode itself, it expects the After waking up, the smart card does not receive a resumption command from the end device to resume operation. In some embodiments of the present invention, the sleep trigger command is a parameterized Application Protocol Data Unit (APDU) command that includes a parameter to indicate the sleep mode. Preferably, the hibernate trigger command is a modified UICC SUSPEND command that includes a plurality of parameters, with a particular parameter of the plurality of parameters being set to indicate the suspend mode. This enables a standardized way to support hibernation through the CAT tool set. In some embodiments of the present invention, the smart card includes a variety of applications. The smart card determines the maximum sleep time by obtaining a maximum sleep time from each of the plurality of applications, where the maximum sleep time of an application indicates the length of time the application is allowed to sleep, and by obtaining the lowest value from the plurality of maximum sleep times as the maximum sleep time. This ensures that no application, in particular no critical application, is active that would require processing while the smart card remains in idle mode. In some embodiments of the present invention, memory contents and CPU registers of the smart card are securely stored before the smart card enters sleep mode. By backing up the memory contents and CPU registers, the state of the smart card can be safely saved before it enters sleep, so that the smart card or its operating system can immediately resume operation from the saved state upon waking without having to receive a resume command from the end device. Preferably, the contents of the memory and the CPU registers are encrypted and decrypted using firmware that is provided by the terminal device, in particular by a modem of the terminal device, via an interface between the terminal device and the smart card. Since the smart card or its operating system starts from the state in which it was put into hibernation, hibernation would also work in the case of an iUICC, since part of the main memory (RAM) is shared with the end device's modem and the iUICC so that the shared memory benefits from battery backup. In this case, RAM recovery would be done by the modem. In some embodiments of the present invention, the terminal sends a power-on or wake-up command to the smart card after the maximum sleep time has elapsed. After the smart card receives the power-on or wake-up command from the end device, it decrypts the memory contents and the CPU registers and restores them. The smart card can thus resume operation immediately without requiring another resume command from the terminal, as no resume feature is required as in the traditional SUSPEND/RESUME-based CAT implementation becomes. By encrypting and decrypting the secured content, neither the end device nor the smart card needs to carry out an additional verification step after operations are resumed. Preferably, the smart card decrypts the contents of the memory and CPU registers and restores them using the firmware provided by the terminal modem. In some embodiments of the present invention, the smart card sends a request to the terminal to extend a preset polling interval based on the maximum sleep time, the polling interval indicating a frequency of receiving a status command from the terminal. Preferably, the terminal extends the polling interval to a new value that corresponds to the maximum idle time. In some embodiments of the present invention, the terminal sends a modified SUSPEND command that indicates a terminal-defined sleep time to the plurality of applications on the smart card. Preferably, the modified SUSPEND command includes a plurality of parameters, with a particular parameter from the plurality of parameters being set to indicate the defined sleep time. This allows the smart card to enter subsequent sleep modes as needed without having to re-determine the maximum sleep time from scratch. This avoids unnecessary calculation steps on the smart card, which further reduces the energy consumption of the end device. The end device can define the sleep time based on the maximum sleep time previously received from the smart card or set a new value for the sleep time to overwrite any previously stored values. According to a third aspect of the present invention, an apparatus for implementing a sleep mode for a smart card is provided, the smart card being communicatively coupled to a terminal and having a plurality of applications running thereon. The device includes a receiving unit, a processing unit and a memory. The receiving unit is configured to receive a sleep trigger command from the terminal. The processing unit is configured to determine a maximum sleep time by obtaining a maximum sleep time from each of the plurality of applications, where the maximum sleep time of an application indicates a duration that the application is allowed to sleep for select the lowest value from the plurality of maximum sleep times as the maximum sleep time to provide the maximum sleep time to the terminal and to cause the smart card to enter a sleep mode. In some embodiments of the present invention, the processing unit is configured to encrypt and secure the contents of the smart card's memory and CPU registers before entering sleep mode. In some embodiments of the present invention, the processing unit is configured to send to the terminal a request to extend a preset polling interval based on the maximum sleep time, the polling interval being the frequency of receiving a status command from the terminal at the Smart card indicates. According to a fourth aspect of the present invention, a smart card is provided which includes the device according to the third aspect. Preferably, the smart card carries out the method according to the first aspect when it is connected to a terminal according to the second aspect. Further aspects, features and advantages of the present invention will become apparent to those skilled in the art upon review of the following detailed description of the preferred embodiments and variants of the present invention in conjunction with the accompanying figures. BRIEF DESCRIPTION OF THE DRAWINGS Reference is now made to the accompanying figures, in which: FIG. 1 shows a block diagram of a CAT framework for implementing a sleep mode for a smart card, according to an embodiment of the invention; 2 shows a flowchart of a method for implementing a sleep mode for a smart card, according to an embodiment of the invention; FIGS.3 to 5 show preferred implementations of steps of the method in FIG.2, according to various embodiments of the invention; 6 shows a schematic diagram of the three embodiments of the method for implementing a sleep mode in a smart card; and FIG.7 shows the communication flow between the terminal and the smart card according to embodiments of the invention in comparison to the suppression method defined by ETSI. DETAILED DESCRIPTION Detailed explanations of the present invention are given below with reference to the accompanying drawings which illustrate specific embodiments of the present invention. These embodiments are described in sufficient detail to enable those skilled in the art to practice the invention. It is to be understood that the various embodiments of the present invention, although different, are not necessarily mutually exclusive. For example, a particular feature, structure, or property described herein in connection with one embodiment may be implemented in other embodiments without departing from the scope of the present invention. Furthermore, it is to be understood that the position or arrangement of individual elements may be modified within each disclosed embodiment without departing from the scope of the present invention. The following detailed description is therefore should not be construed in a limiting sense, and the scope of the present invention is defined only by the appended claims, which shall be reasonably interpreted, together with the full range of equivalents to which the claims refer. In the drawings, the same numbers refer to the same or similar functionality in the different views. Hereinafter, the terms “UICC”, “iUICC”, “SIM”, “iSIM”, “Smartcard” refer to the same entity and are used interchangeably. 1 shows a block diagram of a CAT framework for implementing a sleep mode for a smart card according to an embodiment of the invention. The CAT framework allows applications present on the UICC or smart card 20 to interact and work with a terminal 10. The communication between the UICC 20 and the terminal 10 can be implemented via a modem 12 of the terminal 10. The UICC 20 can be connected to the modem 12 via the terminal UICC interface 14, via which CAT commands are transmitted between the terminal and the UICC. A device 200 is located within the UICC 20 to implement a sleep mode for the UICC. The device 200 includes a receiving unit 201, a processing unit 202 and a memory 202. The receiving unit 201 is configured to receive various commands, notifications and/or events from the terminal 10 via the interface 14. In addition, the receiving unit 201 can be configured to function as a transmitting unit and Sends control data to the end device. An example of such control data that the device 200 can make available to the terminal 10 is the maximum idle state time of the UICC 20, as described further below in connection with FIG. 2. FIG.2 shows a flowchart of a method for implementing a sleep mode for a smart card, such as the UICC 20 in FIG.1, according to an embodiment of the invention. The smart card 20 is connected/coupled to the terminal 10 either by being in the terminal 10 or by other means, such as. B. an intermediate card reader. In a step S1, the smart card 20 receives a sleep state trigger command from the terminal. The terminal 10 sends the sleep trigger command to inform the smart card 20 of a long-duration event during which the smart card does not perform any activity and may enter a sleep mode. That is, the sleep trigger command can be viewed as a trigger event to put the smart card into a sleep state. Preferably, the sleep trigger is sent via a parameterized Application Protocol Data Unit (APDU) command that includes a parameter to indicate the sleep mode. Preferably, the suspend command can be implemented by modifying the SUSPEND UICC command specified in ETSI TS 102221 V16.3.0 as follows:
Figure imgf000014_0001
TABLE 1. Suspend Command In contrast to the traditional SUSPEND command according to ETSI TS 102221, where no value is set for the parameter P1 but it is reserved for future use, the present invention proposes to use the bits of Use P1 to indicate to the smart card that it should enter sleep mode. In the example above, P1 is set to the hexadecimal value “80”, but any other flag value can be used as long as it is supported by both the terminal and the UICC. After receiving the sleep trigger command, the UICC 20 determines the maximum sleep time that the smart card is allowed to remain in sleep mode in step S2. The maximum allowable sleep time of the smart card depends on the requirements of the applications running on it. Some applications may have business logic that requires predefined execution that must run after a specified time. For example, an IoT device may only connect to the network once a month and send back little data, e.g. B. an intelligent measuring device (SmartMeter) for gas or water. Therefore, the UICC collects the maximum duration of all of these applications for which applications are allowed to sleep and selects the minimum of these Time spans as the maximum allowable sleep time for the smart card to serve all applications running on it. A preferred implementation for determining the maximum idle time is shown in FIG.3. Referring to FIG. 3, in step S21, after receiving the sleep trigger command in step S1, the UICC 20 determines all applications running on the UICC. For each of the identified applications, the UICC determines the maximum sleep time in a subsequent step S22, ie the respective maximum time that the application is allowed to sleep. The maximum sleep time of an application generally depends on the type of application and can be preset/preconfigured when the application is loaded onto the smart card. In step S23, the UICC selects the sleep time with the lowest value as the maximum sleep time MHT from all the sleep times determined in step S22. The maximum sleep time, MHT, is then sent to the terminal 10 in step S3 of FIG. 2. The sleep time or the maximum sleep time can also be configurable on the UICC, e.g. B. in applets, in the file system and/or in objects. Back to FIG. 2, in step S5 the terminal stores the received maximum idle time, MHT, in memory. After the UICC 20 has informed the terminal of the maximum idle time, it switches to the idle mode in step S8. Optionally, before entering sleep mode, the UICC 20 may request the terminal 10 to set a polling interval previously negotiated between the terminal and the UICC. The polling interval is defined in ETSI TS 102223 V14.0.0 and indicates how often the terminal device sends STATUS commands to the UICC during an idle mode. Polling interval negotiations, as currently specified in the ETSI TS 102223 V14.0.0 standard specification, support a maximum duration of four hours. In contrast, hibernation can last up to a few days. Therefore, the available CAT mechanism for negotiating the polling interval using the proactive POLL INTERVAL command based on ETSI TS 102223 V14.0.0 does not support the default sleep time exceeding four hours. In order to remedy this deficiency, the UICC 20 is configured such that it checks the polling interval in step S4 and requests the terminal in step S6 to extend the polling interval to the duration of the idle state. A preferred embodiment of this method is shown in FIG.4. In step S41, the UICC checks whether a polling interval has already been negotiated with the terminal and checks whether the preset value of the polling interval is below the maximum idle time. If the value of the polling interval is below the maximum idle time, PI < MHT, the UICC sends the request to the terminal in step S6 to extend the standard polling interval. Referring to FIG.2, in step S8, the UICC prepares to transition to sleep mode. A preferred one Embodiment for implementing the sleep preparation steps is shown in FIG.5(a). Referring to FIG. 5(a), before entering the sleep state, the UICC saves the internal random access memory (RAM) contents and the CPU registers, which are stored in, for example, a retention RAM (step S82). Preferably, the main memory contents and the CPU registers are encrypted before the backup is carried out (step S81). The Advanced Encryption Standard Galois/Counter Mode (AES-GCM) algorithm can be used for this purpose. Preferably, the encryption and security operations are performed via the firmware of the modem 12. The encryption/decryption step is optional. Other means of securely storing memory contents and CPU registers can also be used, such as: B. the use of MRAM. If the internal memory is backed up by a battery, encryption/decryption may become unnecessary. During hibernation mode, the UICC is turned off or has very low power. This makes the hibernation mode different from the standard SUSPEND mode of a smart card. While the smart card still consumes power in standard suppression mode, the smart card consumes no energy at all when in idle mode, which reduces the overall energy consumption of the end device. If the smart card is a passive device, it must be woken up by the end device after the sleep time has expired. For this purpose, the terminal 10 sends a switch-on/wake-up notification, as shown in step S9 in FIG.2. The wake-up notification can be sent to the UICC encapsulated in an APDU command. If the UICC was switched off during the idle state, the terminal 10 sends a switch-on command instead in step S9. After receiving the wake-up or power-on command, the UICC 20 performs a wake-up step S10. A preferred implementation of the wake-up step is shown in FIG.5(b). The UICC 20 retrieves the content stored in step S82 from memory in step S91, decrypts the retrieved content in step S92, and restores the memory content and CPU registers to the pre-sleep state in step S93. These steps can be carried out with the firmware provided by the modem 12 of the terminal 10. By restoring the smart card to its pre-hibernation state, the context of the smart card operating system can be restored to resume operation in the same pre-hibernation state. No additional steps are required, such as: B. a verification step that does not have to be carried out by the end device or the smart card. If the smart card is an integrated UICC (iUICC), its main memory (RAM) is shared with the terminal modem, so battery backup of the main memory is a way to save the contents of the smart card before it goes into sleep mode is relocated. After receiving the wake-up command, the smart card can instruct the modem to perform state recovery. If the smart card is an active device, the smart card can automatically wake up after the sleep time expires without requiring a command from the terminal modem. Embodiments of the method for implementing a sleep mode in a smart card or UICC may be performed by a device 200 within the UICC 20, as shown in FIG. 1. The device comprises at least a receiving unit 201, a processing unit 202 and a memory 203. The receiving unit 201 is configured so that it receives the idle state trigger command from the terminal 10 via the interface 14 (step S1 in FIG. 2). The processing unit 202 is configured to process the received command and perform the steps described above in connection with Figures 2 to 5 to cause the smart card to enter sleep mode. The processing unit 202 has access to the firmware provided by the modem 12 and is configured to encrypt and decrypt the contents of the memory 203 for the pre- and post-hibernation backup and restore process. In addition, the processing unit 202 is configured to send the request to the terminal 10 to extend the preset polling interval based on the maximum sleep time. 6 shows a schematic diagram of an overview of embodiments of the method for implementing a hibernation mode in a smart card or UICC. Referring to FIG. 6(a), the terminal 10, preferably via its modem 12, notifies the smart card 20 of a trigger event that has a long duration. Examples of a trigger event include an ENVELOPE command (CAT event, ETSI 102223), e.g. E.g. extending a standard event or using a proprietary flag/event. The notification may be provided to the smart card in the form of the sleep trigger command in step S1 of FIG.2. The event allows the SIM card to enter sleep mode during this time. The smart card 20 returns the maximum sleep time (FIG.2, step S3) after which the smart card wakes up/is woken up (FIG.2, steps S9, S10). FIG. 6(b) shows an embodiment for extending a standard POLL INTERVAL command beyond four hours as shown in steps S4 and S6 in FIG. 2 and steps S41 and S42 in FIG. 4 is implemented. Upon receipt of the request to extend the polling interval, the terminal 10 stores the new polling interval to cover the maximum sleep time provided by the smart card. This prevents the end device from sending STATUS commands while the smart card is in idle state, as the smart card sends them cannot process commands during sleep mode, further reducing the energy consumption of the end device. FIG. 6(c) shows an embodiment of the implementation of the extended SUSPEND command to specify the maximum sleep time for the variety of applications on the smart card. Here too, the P1 bits can be used to communicate the maximum idle time. In this embodiment, the command only specifies the sleep duration to customer applications and does not trigger any operations related to suspend and resume. This command can also be used to instruct the smart card to initiate subsequent sleep modes as needed, without requiring the smart card to determine the maximum sleep time from scratch. This avoids unnecessary calculation steps on the smart card, which further reduces the energy consumption of the end device. FIG.7 shows a comparison of the communication flow between the terminal and the UICC in the conventional suppression method, as described in ETSI TS 102241 V16.1.0 (FIG.7(b)), with the communication flow for implementing the idle state method according to of the present invention (FIG. 7(a)).
Figure imgf000022_0001
TABELLE 2. Standard-UNTERDRÜCKUNG (SUSPEND) -Befehl versus Ru- hezustandsbefehl Unter Bezugnahme auf FIG.7(a) kann der Ablauf von Ereignissen innerhalb einer UICC, die zum Ruhezustand fähig ist, d.h. einer UICC, die eine Vor- richtung 200 zur Implementierung eines Ruhezustandsverfahrens gemäß den unter Bezugnahme auf die Figuren 2 bis 5 beschriebenen Ausführungsfor- men umfasst, die folgenden Schritte umfassen: - Schritt 100: „Einschalten“: Dies ist der konventionelle Einschaltbefehl für das Endgerät, um eine Sitzung mit einer UICC zu aktivieren und zu initiieren. Alle internen Endgeräte der UICC werden gemäß den Standards eingestellt. - Schritt 110: „Üblicher Austausch von Befehlen“: Dies bezeichnet den herkömmlichen Kommunikationsprozess zwischen dem Endgerät und der UICC. - Schritt 120: „UICC Unterdrückung*“: Dies ist der Ruhezustandsauslö- sebefehl, der als modifizierter UNTERDRÜCKUNG (SUSPEND) -Be- fehl der UICC implementiert ist. Der erwartete Ablauf innerhalb der UICC ist in TABELLE 2 kurz dargestellt. Mit diesem Befehl wird die Smartcard/UICC in den Ruhezustandsmodus versetzt. Er zeigt den Ruhezustandsmodus an, wie in Schritt S1 von FIG.2. Mit diesem Be- fehl kann ferner eine vom Endgerät definierte Ruhezustandszeit ange- geben werden. - Schritt 130: „OK/Max. Ruhezustandszeit“: Antwort der UICC an das Endgerät. Die UICC teilt dem Endgerät die maximale Ruhezustands- zeit, MHT, mit. Wenn der geänderte UNTERDRÜCKUNG (SUS- PEND) -Befehl, den die UICC in Schritt 120 erhalten hat, bereits eine Ruhezustandszeit angibt, gibt die UICC in Schritt 130 lediglich OK zu- rück. - Schritt 140: „Ausschalten / Ruhezustandsperiode“: Basierend auf dem vorrichtungsspezifischen Mechanismus wird die UICC während der angegebenen Ruhezustandszeit, MHT, ausgeschaltet. - Schritt 150: „Einschalten*“: Zusätzlich zum herkömmlichen Einschalt- vorgang für jede UICC versetzt dieser Einschaltbefehl die UICC in den vorherigen Zustand vor dem Ruhezustand zurück. Das heißt, die- ser Befehl veranlasst die UICC, die in FIG.5(b) dargestellten Schritte zum Aufwachen durchzuführen. - Schritt 160: „Üblicher Austausch von Befehlen“: Nach dem Einschal- ten der UICC und der Wiederherstellung des Vor-Ruhezustands kann der übliche Kommunikationsprozess zwischen Endgerät und UICC erfolgen. Die hier beschriebenen Aspekte und Ausführungsformen können mit Hilfe eines Modementwicklers oder Chip-Anbieters oder einer anderen Einheit, mit der die UICC gekoppelt ist, umgesetzt werden. Die Bereitstellung eines batteriegepufferten Speichers und der Speichermechanismus zur Implemen- tierung des Ruhezustandsmodus sind daher vorrichtungsspezifisch. Der Ru- hezustand ist für das Betriebssystem (OS) transparent. Der Ruhezustandsmo- dus unterbricht das laufende Betriebssystem, sichert den Systemzustand und die Daten und setzt den Betrieb des Betriebssystems nach dem Aufwachen fort. Insbesondere können Niedrig-Level-Treiber die Ruhezustandsanfrage verarbeiten und den Betrieb transparent für das Betriebssystem wieder auf- nehmen. Am Modem können weitere Funktionen zur Unterstützung des Ruhezu- stands implementiert werden. So mag das Modem beispielsweise während der Ausführung einer offenen USAT-Prozedur, d. h. eines USIM/SIM Appli- cation Toolkit gemäß ETSI/3GPP, keine Ruhezustandsanfrage starten. Dar- über hinaus kann das Modem beschließen, die Ruhezustandsanfrage auch dann zu starten, wenn ein Zeitereignis anhängig ist. Das heißt, wenn es eine Anwendung gibt, die eine Zeitgeberfunktion des Modems nutzt, kann der Ruhezustandsmodus die Ausführung des Betriebssystems/der Anwendung unterbrechen. Die Anwendung, die auf die Freigabe des Zeitgebers wartet, wird nach dem Aufwachen der SIM wieder aufgenommen. Die hier beschriebenen Aspekte und Ausführungsformen optimieren den Energieverbrauch einer Smartcard (UICC/iUICC/SIM/iSIM) in einem End- gerät oder einer Vorrichtung (z. B. IoT, tragbares Gerät usw.) und ermögli- chen so eine Verlängerung der Batterielebensdauer solcher Vorrichtungen. In der vorstehenden Beschreibung ist die Erfindung unter Bezugnahme auf bestimmte Ausführungsformen beschrieben worden. Es wird jedoch deut- lich, dass verschiedene Modifikationen und Änderungen daran vorgenom- men werden können, ohne vom breiteren Umfang der Erfindung abzuwei- chen. Zum Beispiel werden die oben beschriebenen Prozessabläufe unter Be- zugnahme auf eine bestimmte Reihenfolge der Verfahrensvorgänge beschrie- ben. Die Reihenfolge vieler der beschriebenen Verfahrensvorgänge kann je- doch geändert werden, ohne den Umfang oder die Funktionsweise der Erfin- dung zu beeinträchtigen. Die Beschreibung und die Zeichnungen sind dem- entsprechend eher illustrativ als einschränkend zu verstehen.
Figure imgf000022_0001
TABLE 2. Standard SUSPEND Command versus Suspend Command Referring to FIG. 7(a), the flow of events within a UICC capable of hibernation, ie a UICC that includes a device 200, can be viewed Implementation of a sleep mode method according to the embodiments described with reference to Figures 2 to 5, comprising the following steps: - Step 100: “Power on”: This is the conventional power-on command for the terminal to activate a session with a UICC and to initiate. All UICC internal terminal devices are set according to the standards. - Step 110: “Normal exchange of commands”: This refers to the usual communication process between the terminal and the UICC. - Step 120: “UICC Suspend*”: This is the sleep trigger command implemented as a modified SUSPEND command of the UICC. The expected process within the UICC is briefly shown in TABLE 2. This command puts the smart card/UICC into sleep mode. It indicates the sleep mode as in step S1 of FIG.2. This command can also be used to specify an idle state time defined by the terminal device. - Step 130: “OK/Max. Sleep time”: Response from the UICC to the end device. The UICC informs the end device of the maximum idle time, MHT. If the modified SUSPEND command that the UICC received in step 120 already specifies a sleep time, the UICC simply returns OK in step 130. - Step 140: “Power Off/Sleep Period”: Based on the device-specific mechanism, the UICC is turned off during the specified sleep time, MHT. - Step 150: “Power On*”: In addition to the traditional power on operation for each UICC, this power on command returns the UICC to the previous state before sleep. That is, this command causes the UICC to perform the wake-up steps shown in FIG.5(b). - Step 160: “Usual exchange of commands”: After switching on the UICC and restoring the pre-idle state, the usual communication process between the end device and UICC can take place. The aspects and embodiments described herein may be implemented with the assistance of a modem designer or chip vendor or other entity to which the UICC is coupled. The provision of battery-backed memory and the memory mechanism to implement sleep mode are therefore device specific. The hibernation state is transparent to the operating system (OS). Hibernation mode suspends the running operating system, saves the system state and data, and resumes operation of the operating system after waking up. In particular, low-level drivers can process the sleep request and resume operation transparently to the operating system. Additional functions to support the idle state can be implemented on the modem. For example, the modem may not start a sleep request during the execution of an open USAT procedure, ie a USIM/SIM Application Toolkit according to ETSI/3GPP. Additionally, the modem may decide to start the sleep request even if a time event is pending. That is, if there is an application that uses a timer function of the modem, sleep mode may interrupt the execution of the operating system/application. The application waiting for the timer to be released will resume after the SIM wakes up. The aspects and embodiments described herein optimize the power consumption of a smart card (UICC/iUICC/SIM/iSIM) in a terminal or device (e.g., IoT, wearable device, etc.), thereby enabling an extension of the battery life thereof Devices. In the foregoing description, the invention has been described with reference to specific embodiments. However, it will be appreciated that various modifications and changes may be made therein without departing from the broader scope of the invention. For example, the process flows described above are described with reference to a specific order of process operations. However, the order of many of the process operations described can be changed without affecting the scope or functionality of the invention. The description and drawings are therefore to be understood as illustrative rather than restrictive.

Claims

Ansprüche 1. Verfahren zum Implementieren eines Ruhezustandsmodus für eine Smartcard (20), die kommunikativ mit einem Endgerät (10) gekoppelt ist, wobei das Verfahren an der Smartcard (20) umfasst: - Empfangen (S1) eines Ruhezustandsauslösebefehls von dem End- gerät (10); - Bestimmen (S2) einer maximalen Ruhezustandszeit; - Bereitstellen (S3) der maximalen Ruhezustandszeit an das Endge- rät (10); und - Eintreten (S8) in einen Ruhezustandsmodus. 2. Verfahren nach Anspruch 1, wobei der Ruhezustandsauslösebefehl ein parametrisierter Anwendungsprotokoll-Dateneinheit (ADPU - Appli- cation Protocol Data Unit) -Befehl ist, der einen Parameter zur Angabe des Ruhezustandsmodus umfasst. 3. Verfahren nach Anspruch 1 oder 2, wobei der Ruhezustandsauslöse- befehl ein modifizierter UICC-UNTERDRÜCKUNG (UICC-SUS- PEND) -Befehl ist, der eine Vielzahl von Parametern umfasst, wobei ein spezieller Parameter aus der Vielzahl von Parametern eingestellt wird, um den Ruhezustandsmodus anzuzeigen. 4. Verfahren nach einem der Ansprüche 1 bis 3, wobei die Smartcard (20) eine Vielzahl von Anwendungen umfasst und die maximale Ruhezu- standszeit bestimmt durch: - Erhalten (S22) einer maximalen Schlafzeit von jeder der Vielzahl von Anwendungen, wobei die maximale Schlafzeit einer Anwen- dung eine Dauer angibt, die die Anwendung schlafen darf; und - Auswählen (S23) des niedrigsten Wertes aus der Vielzahl der ma- ximalen Schlafzeiten als die maximale Ruhezustandszeit. 5. Verfahren nach einem der Ansprüche 1 bis 4, ferner umfassend das Speichern (S82) von Speicherinhalt und CPU-Registern in einem siche- ren Modus vor dem Eintreten in den Ruhezustandsmodus. 6. Verfahren nach Anspruch 5, ferner umfassend, dass nach Ablauf der maximalen Ruhezustandszeit bei Empfangen (S9) eines Einschalt- oder Aufweckbefehls von dem Endgerät (10) der Speicherinhalt und die CPU-Register wiederhergestellt werden (S93). 7. Verfahren nach Anspruch 6, ferner umfassend das Verschlüsseln (S81) des Speicherinhalts und der CPU-Register der Smartcard (20) vor dem Speichern und das Entschlüsseln des gespeicherten Speicherinhalts und der CPU-Register vor dem Wiederherstellen, vorzugsweise unter Verwendung von Firmware, die von dem Endgerät (10), insbesondere von einem Modem (12) des Endgeräts (10), über eine Schnittstelle (14) zwischen dem Endgerät (10) und der Smartcard (20) bereitgestellt wird. 8. Verfahren nach einem der Ansprüche 1 bis 7, ferner umfassend: - Senden (S6) einer Anfrage an das Endgerät (10), ein voreingestell- tes Abfrageintervall basierend auf der maximalen Ruhezustands- zeit zu verlängern, wobei das Abfrageintervall eine Häufigkeit des Empfangens eines Statusbefehls von dem Endgerät (10) angibt. 9. Verfahren zum Implementieren eines Ruhezustandsmodus für eine Smartcard (20), die kommunikativ mit einem Endgerät (10) gekoppelt ist, wobei das Verfahren am Endgerät (10) umfasst: - Senden (S1) eines Ruhezustandsauslösebefehls an die Smartcard (20); - Empfangen (S3) einer maximalen Ruhezustandszeit von der Smart- card (20); - Speichern (S5) der maximalen Ruhezustandszeit; und - nach Ablauf der maximalen Ruhezustandszeit, Senden (S9) eines Einschalt- oder Aufweckbefehls an die Smartcard (20). 10. Verfahren nach Anspruch 9, ferner umfassend das Empfangen (S6) ei- ner Anfrage von der Smartcard (20), ein voreingestelltes Abfrageinter- vall basierend auf der maximalen Ruhezustandszeit zu verlängern, wobei das Abfrageintervall eine Häufigkeit des Endgeräts (10) zum Senden eines Statusbefehls an die Smartcard (20) angibt; Verlängern und Speichern (S7) des verlängerten Abfrageintervalls. 11. Verfahren nach Anspruch 9 oder 10, ferner umfassend das Senden ei- nes modifizierten UNTERDRÜCKUNG (SUSPEND) -Befehls, der eine vom Endgerät definierte Ruhezustandszeit angibt, an die Vielzahl von Anwendungen auf der Smartcard (20), wobei der modifizierte UN- TERDRÜCKUNG (SUSPEND) -Befehl eine Vielzahl von Parametern umfasst, wobei ein spezieller Parameter aus der Vielzahl von Parame- tern eingestellt wird, um die definierte Ruhezustandszeit anzuzeigen. 12. Vorrichtung (200) zum Implementieren eines Ruhezustandsmodus für eine Smartcard (200), wobei die Smartcard (20) kommunikativ mit ei- nem Endgerät (10) gekoppelt ist und eine Vielzahl von darauf laufen- den Anwendungen aufweist, wobei die Vorrichtung umfasst: - eine Empfangseinheit (201), die so konfiguriert ist, dass sie von dem Endgerät (10) einen Ruhezustandsauslösebefehl empfängt; - eine Verarbeitungseinheit (202), die so konfiguriert ist, dass sie: - eine maximale Ruhezustandszeit bestimmt, indem von jeder der Vielzahl von Anwendungen eine maximale Schlafzeit erhalten wird, wobei die maximale Schlafzeit einer Anwen- dung eine Dauer angibt, die die Anwendung schlafen darf; - den niedrigsten Wert aus der Vielzahl von maximalen Schlafzeiten als die maximale Ruhezustandszeit auswählt; - dem Endgerät (10) die maximale Ruhezustandszeit bereit- stellt; und - die Smartcard (20) veranlasst, in einen Ruhezustandsmodus einzutreten. 13. Vorrichtung (200) nach Anspruch 12, wobei die Verarbeitungseinheit (202) ferner so konfiguriert ist, dass sie einen Inhalt eines Speichers (203) und CPU-Register der Smartcard (20) verschlüsselt und sichert, bevor sie in den Ruhezustandsmodus eintritt. 14. Vorrichtung (200) nach Anspruch 12 oder 13, wobei die Verarbei- tungseinheit (202) ferner so konfiguriert ist, dass sie an das Endgerät (10) eine Anfrage sendet, ein voreingestelltes Abfrageintervall basie- rend auf der maximalen Ruhezustandszeit zu verlängern, wobei das Abfrageintervall eine Häufigkeit des Empfangs eines Statusbefehls von dem Endgerät (10) an der Smartcard (20) angibt. 15. Smartcard (200), wobei die Smartcard (200) die Vorrichtung (200) nach einem der Ansprüche 12 bis 14 umfasst. Claims 1. Method for implementing a hibernation mode for a smart card (20) which is communicatively coupled to a terminal (10), the method comprising on the smart card (20): - receiving (S1) a hibernation trigger command from the terminal ( 10); - Determine (S2) a maximum sleep time; - Providing (S3) the maximum idle time to the end device (10); and - entering (S8) into a sleep mode. 2. The method of claim 1, wherein the sleep trigger command is a parameterized Application Protocol Data Unit (ADPU) command that includes a parameter to indicate the sleep mode. 3. The method of claim 1 or 2, wherein the sleep trigger command is a modified UICC SUPPRESSION (UICC-SUS-PEND) command comprising a plurality of parameters, a particular parameter of the plurality of parameters being set to to display hibernation mode. 4. The method according to any one of claims 1 to 3, wherein the smart card (20) comprises a plurality of applications and the maximum sleep time is determined by: - Obtaining (S22) a maximum sleep time from each of the plurality of applications, where the maximum sleep time specifies an application's length of time for which the application is allowed to sleep; and - Selecting (S23) the lowest value from the plurality of maximum sleep times as the maximum sleep time. 5. The method according to any one of claims 1 to 4, further comprising storing (S82) memory contents and CPU registers in a secure mode before entering the sleep mode. 6. The method according to claim 5, further comprising that after the maximum sleep time has elapsed upon receipt (S9) of a switch-on or wake-up command from the terminal (10), the memory contents and the CPU registers are restored (S93). 7. The method according to claim 6, further comprising encrypting (S81) the memory contents and the CPU registers of the smart card (20) before saving and decrypting the stored memory contents and the CPU registers before restoring, preferably using firmware, which is provided by the terminal (10), in particular by a modem (12) of the terminal (10), via an interface (14) between the terminal (10) and the smart card (20). 8. The method according to any one of claims 1 to 7, further comprising: - sending (S6) a request to the terminal (10) to extend a preset polling interval based on the maximum idle time, the polling interval being a frequency of reception a status command from the terminal (10). 9. Method for implementing an idle mode for a smart card (20) which is communicatively coupled to a terminal (10), the method on the terminal (10) comprising: - Sending (S1) a sleep trigger command to the smart card (20); - Receiving (S3) a maximum idle time from the smart card (20); - Save (S5) the maximum sleep time; and - after the maximum sleep time has elapsed, sending (S9) a switch-on or wake-up command to the smart card (20). 10. The method of claim 9, further comprising receiving (S6) a request from the smart card (20) to extend a preset polling interval based on the maximum sleep time, the polling interval being a frequency of the terminal (10) for transmitting a status command to the smart card (20); Extend and save (S7) the extended polling interval. 11. The method of claim 9 or 10, further comprising sending a modified SUSPEND command specifying a terminal-defined sleep time to the plurality of applications on the smart card (20), the modified SUSPEND (SUSPEND) command includes a variety of parameters, where a specific parameter from the variety of parameters is set to indicate the defined sleep time. 12. Device (200) for implementing a sleep mode for a smart card (200), the smart card (20) being communicatively coupled to a terminal (10) and having a plurality of applications running thereon, the device comprising: - a receiving unit (201) configured to receive a sleep trigger command from the terminal (10); - a processing unit (202) configured to: - determine a maximum sleep time by obtaining a maximum sleep time from each of the plurality of applications, the maximum sleep time of an application indicating a duration that the application sleeps may; - selects the lowest value from the plurality of maximum sleep times as the maximum sleep time; - provides the terminal (10) with the maximum idle time; and - causes the smart card (20) to enter a sleep mode. 13. The device (200) of claim 12, wherein the processing unit (202) is further configured to encrypt and secure a contents of a memory (203) and CPU registers of the smart card (20) before entering the sleep mode. 14. The device (200) according to claim 12 or 13, wherein the processing unit (202) is further configured to send to the terminal (10) a request to extend a preset polling interval based on the maximum sleep time, wherein the polling interval indicates a frequency of receiving a status command from the terminal (10) to the smart card (20). 15. Smart card (200), wherein the smart card (200) comprises the device (200) according to one of claims 12 to 14.
PCT/DE2023/100684 2022-09-14 2023-09-13 Rest state mode for smart cards WO2024056132A1 (en)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102022003387.9A DE102022003387A1 (en) 2022-09-14 2022-09-14 Sleep mode for smart cards
DE102022003387.9 2022-09-14

Publications (1)

Publication Number Publication Date
WO2024056132A1 true WO2024056132A1 (en) 2024-03-21

Family

ID=88241463

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/DE2023/100684 WO2024056132A1 (en) 2022-09-14 2023-09-13 Rest state mode for smart cards

Country Status (2)

Country Link
DE (1) DE102022003387A1 (en)
WO (1) WO2024056132A1 (en)

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5247164A (en) * 1989-01-26 1993-09-21 Hitachi Maxell, Ltd. IC card and portable terminal
US20090153236A1 (en) * 2004-10-20 2009-06-18 Koninklijke Philips Electronics, N.V. Power control circuit with low power consumption
US20100049987A1 (en) * 2006-12-19 2010-02-25 Telecom Italia S.P.A Method and arrangement for secure user authentication based on a biometric data detection device
DE102008016913B4 (en) * 2007-03-27 2019-05-09 Samsung Electronics Co., Ltd. Mobile electronic device and method for energy management
US20190208471A1 (en) * 2016-05-23 2019-07-04 Zte Corporation Smart card control method and device, terminal device and smart card

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5247164A (en) * 1989-01-26 1993-09-21 Hitachi Maxell, Ltd. IC card and portable terminal
US20090153236A1 (en) * 2004-10-20 2009-06-18 Koninklijke Philips Electronics, N.V. Power control circuit with low power consumption
US20100049987A1 (en) * 2006-12-19 2010-02-25 Telecom Italia S.P.A Method and arrangement for secure user authentication based on a biometric data detection device
DE102008016913B4 (en) * 2007-03-27 2019-05-09 Samsung Electronics Co., Ltd. Mobile electronic device and method for energy management
US20190208471A1 (en) * 2016-05-23 2019-07-04 Zte Corporation Smart card control method and device, terminal device and smart card

Also Published As

Publication number Publication date
DE102022003387A1 (en) 2024-03-14

Similar Documents

Publication Publication Date Title
DE60128396T9 (en) COMPUTER PERIPHERAL DEVICE WHICH REMAINS OPEN WHEN THE OPERATIONS OF THE CENTRALIZED PROCESSOR WILL BE SUSPENDED
DE102008064368B4 (en) At least partially based on a power state of an integrated circuit supply voltage control
DE102012212441B4 (en) A method of entering and exiting a sleep mode in a graphics processing unit
DE102010019487B4 (en) Storage device, data processing device and method
DE60031404T2 (en) METHOD AND DEVICE FOR DYNAMICALLY MODIFYING THE SIZES OF POOLS THAT CONTROL THE PERFORMANCE OF STORES
DE102007048505B4 (en) Server configured to manage performance and performance
DE102009041723B4 (en) Processor power consumption control and voltage drop across a micro-architecture bandwidth limit
DE10159247B4 (en) Apparatus and method for performing power management of automotive multimedia systems
DE60220506T2 (en) PERFORMANCE CONTROL FOR PARTICIPANT IDENTITY MODULE
EP3663927B1 (en) Method for power-saving operation of a security element of a single-chip system device, and single-chip system device
DE102010013228B4 (en) Method and system to improve the operations of a registered memory module
DE202009011250U1 (en) Electronic Power Saving Device for Motherboards in Suspend Memory Status
DE102009060267A1 (en) Idle time report for a power management
DE10296549T5 (en) A method for determining transition points in microprocessors with multiple performance states
DE69631012T2 (en) Performance control in an information processing system
DE60129423T2 (en) METHOD AND DEVICE FOR CONTROLLING PROCESSOR POWER AND PROCESSOR PERFORMANCE FOR INDIVIDUAL PHASE CONTROLLER PROCESSOR SYSTEMS
DE112020001693T5 (en) AUTONOMOUS CORE PERIMETER FOR LOW POWER PROCESSOR STATES
DE69921880T2 (en) Chip card with a memory content transfer control unit and data storage method in a chip card
DE19717151A1 (en) Energy saving communication terminal e.g. for facsimile apparatus
EP2159667B1 (en) Computer system and method for energy-efficient operation of a computer system
EP1577738B1 (en) Pocket PC with several operating states
WO2024056132A1 (en) Rest state mode for smart cards
DE112018005673T5 (en) CONFIGURABLE EMPTYING OF DATA FROM A VOLATILE STORAGE TO A NON-VOLATILE STORAGE
DE102009031498B4 (en) Performance-optimized dynamic port assignment
DE112012006164T5 (en) Controlling power management in microservers

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 23783299

Country of ref document: EP

Kind code of ref document: A1