Classifications

• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F9/00—Arrangements for program control, e.g. control units
  • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
  • G06F9/44—Arrangements for executing specific programs
  • G06F9/4401—Bootstrapping
  • G06F9/4406—Loading of operating system
  • G06F9/441—Multiboot arrangements, i.e. selecting an operating system to be loaded
• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
  • G06F12/02—Addressing or allocation; Relocation
  • G06F12/0223—User address space allocation, e.g. contiguous or non contiguous base addressing
  • G06F12/0284—Multiple user address space allocation, e.g. using different base addresses
• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
  • G06F21/70—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer
  • G06F21/78—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer to assure secure storage of data
• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F9/00—Arrangements for program control, e.g. control units
  • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
  • G06F9/46—Multiprogramming arrangements
  • G06F9/52—Program synchronisation; Mutual exclusion, e.g. by means of semaphores
• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F2212/00—Indexing scheme relating to accessing, addressing or allocation within memory systems or architectures
  • G06F2212/20—Employing a main memory using a specific memory technology
  • G06F2212/205—Hybrid memory, e.g. using both volatile and non-volatile memory
• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
  • G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
  • G06F2221/2149—Restricted operating environment

Definitions

• the present disclosure generally concerns electronic systems and, more particularly, embedded electronic systems.
• the present disclosure more particularly concerns the use of memories in an embedded electronic system.
• An embedded electronic system is a self-contained electronic and software system capable of being embedded in an electronic device and/or electronic equipment.
• the design issues of an embedded system are frequently due to management constraints of memories internal or external to the embedded system.
• the system may comprise non-volatile memories, rewritable or not, and volatile memories, each capable of storing data of different types with the constraints and assets specific to each type of memory.
• the management of these memories generates constraints in terms of data security, particularly when the system is used for different applications.
• US 2018/0113817 discloses a virtualization-based platform protection technology in which two memories are used for different applications.
• US 2018/0165008 discloses a memory transaction prioritization technology.
• US 2015/ 0113257 discloses a system and method for dual OS memory switching, in which an application replaces the other in volatile memory .
• device firmware saves content of overlapped memory location being used for the first OS in volatile memory to nonvolatile memory and loads contents of second OS to overlapped memory locations in volatile memory .
• EP 1 524 597 discloses a method for managing threads in a memory-constrained system .
• An embodiment of a first aspect provides an embedded electronic system comprising :
• said volatile memory comprises : at least a first portion reserved to execution data of a first application; and at least a second portion intended to store execution data of at least a second application, the execution data of the first application remaining in the volatile memory in case of a deactivation or of a setting to standby of this first application .
• An embodiment of the first aspect provides a method implemented by an embedded electronic system comprising :
• said volatile memory comprises : at least a first portion reserved to execution data of a first application; and at least a second portion intended to store execution data of at least a second application, the execution data of the first application remaining in the volatile memory in case of a deactivation or of a setting to standby of this first application .
• data of execution of one of a plurality of tasks of an application are partly trans ferred, by the low-level operating system, from said volatile memory to a nonvolatile memory when the execution of said task is interrupted by the execution of at least one task of another application .
• a volatile memory area is allocated to the second application while the second application is not executed, the execution data of this second application being trans ferred into the non-volatile memory i f the available volatile memory si ze is not suf ficient for the execution of a third application .
• An embodiment of a second aspect provides an embedded electronic system comprising :
• At least one low-level operating system managing the allocation of volatile memory areas to a plurality of high- level operating systems , each comprising one or a plurality of applications , wherein execution data of one or a plurality of tasks of said first application are partly trans ferred, by the low-level operating system, from said volatile memory to a non-volatile memory when the execution of said task of the first application is interrupted by the execution of at least one task of a second application .
• An embodiment of the second aspect provides a method implemented in an embedded electronic system comprising :
• At least one low-level operating system managing the allocation of volatile memory areas to a plurality of high- level operating systems , each comprising one or a plurality of applications , wherein execution data of one or a plurality of tasks of said first application are partly trans ferred, by the low-level operating system, from said volatile memory to an area of a non-volatile memory when the execution of said task of the first application is interrupted by the execution of at least one task of a second application .
• the applications of a high-level operating system do not have access to the volatile memory areas allocated to the applications of another high-level operating system.
• a memory management function or unit executed by the low-level operating system forbids the access of the execution data of an application to other applications.
• the memory management function or unit adapts the size of the first and second portions of the volatile memory according to the needs of the different applications.
• the execution data of a plurality of applications are simultaneously present in the volatile memory.
• the non-volatile memory is external to the embedded electronic system.
• an execution code of an application is transferred to the volatile memory for its execution.
• the non-volatile memory is internal to the embedded electronic system.
• an execution code of an applications remains in the non-volatile memory during the execution of a task.
• a non-volatile memory area allocated to a high- level operating system is seen by the latter as a volatile working memory.
• the high-level operating systems manage a virtual image of the memories where the volatile and non-volatile memories are one and the same.
• a main task of an application is allocated a volatile memory area.
• part of its execution data if transferred into the volatile memory when the application need specifically of the one that are not yet loaded into the volatile memory.
• An embodiment provides an embedded secure element, configured for the implementation of the described system or method.
• Figure 1 schematically shows in the form of blocks an embodiment of hardware components of an embedded secure element or embedded electronic system
• Figure 2 very schematically shows in the form of blocks a software architecture of an embedded electronic system
• Figure 3 shows views (a) , (b) , and (c) schematically illustrating in the form of blocks the implementation of a method of execution of applications of the embedded electronic system of Figures 1 and 2;
• Figure 4 shows views (a) , (b) , and (c) schematically illustrating in the form of blocks an implementation mode of a method of execution of applications of the embedded electronic system of Figures 1 and 2;
• Figure 5 shows views (a) , (b) , and (c) schematically illustrating in the form of blocks the implementation of a method of execution of applications of the embedded electronic system of Figures 1 and 2;
• Figure 6 shows views (a) , (b) , and (c) schematically illustrating in the form of blocks another implementation mode of a method of execution of applications of the embedded electronic system of Figures 1 and 2.
• FIG 1 very schematically shows in the form of blocks an embodiment of hardware components HW (Hardware) of an embedded secure element E or embedded electronic system.
• HW Hardware
• Element E is made in the form of an electronic circuit comprising, in hardware form:
• PU digital processing units
• CPU central processing unit
• programmable logic circuit etc .
• PU digital processing units
• RAM volatile
• NVM nonvolatile
• circuit 1 - one or a plurality of data, address, and/or control buses 14 between the different elements internal to circuit 1;
• circuit 1 - one or a plurality of input/output interfaces 15, (I/O) of wired or wireless communication with the outside of circuit 1;
• NFC near-field communication circuit 16
• FCT short distance communication device
• Bluetooth standard for example using the Bluetooth standard, biometric sensors, etc.
• Figure 2 schematically shows in the form of blocks a software architecture 100 of an embedded secure element E, or secure embedded electronic system.
• Software architecture 100 is implemented by the hardware components HW of the secure element E described in Figure 1.
• Architecture 100 comprises a primary platform 110, generally called virtual primary platform (VPP) comprising the access to the electronic components 111 (HW) of secure element E and comprising one or a plurality of low-level operating systems 113 (LLOS) .
• VPP virtual primary platform
• HW electronic components 111
• LLOS low-level operating systems 113
• Low-level operating systems 113 are operating systems enabling to ease the communication between one or a plurality of high-level operating systems (HLOS1, HLOS2, HLOS) 124A, 124B (two high-level operating systems in the case illustrated in Figure 1) of secure element E and the components 111 of element E.
• the low-level operating systems comprise software driving components 111.
• a low-level operating system 113 is formed of an execution code (or executable code) and of execution data.
• the execution code contains instructions enabling to execute functions of the program. By definition, the instructions are invariable for a given program, except for an update of the program, which then modifies the instructions.
• the execution data are used by the execution code to contextualize the execution and perform the desired function.
• the execution data may be distributed in two categories. So-called “temporary” execution data and so- called “permanent" or "fixed” execution data.
• the execution code contains instructions of verification of the PIN code while the permanent execution data contain the reference PIN code and the number of remaining tests and the temporary execution data contain the PIN code submitted to the verification.
• the low-level system manages the memory components of the element, that is, the physical memories, volatile 12 ( Figure 1) and non-volatile (13 (rewritable or not) .
• High-level operating systems 124A and 124B use virtual images of the memories available for the management of the execution codes and of the execution data. Due to this technique, high-level operating systems do not have a direct access to the management of physical memories, be they volatile or non-volatile. In other words, in the described embodiments, high-level operating systems manage a virtual image of the memories where the volatile and nonvolatile memories are confounded. The management of the physical distribution in the volatile and non-volatile memories is ensured by the low-level operating system (s) .
• Platform 110 has, according to the described embodiments, particularly the roles of;
• HW hardware components
• Low-level operating system 113 uses a memory management function (MMF) 115 to control or manage the access of the high-level operating systems to the physical memories by linking the virtual memories and the physical memories according to the needs and requests of high-level operating systems 124A and 124B . More particularly, low- level operating systems 113 , by using memory management function 115 (MMF) , implement the isolation of high-level operating systems 124A and 124B from one another and manage the access of high-level operating systems 124A, 124B to the di f ferent memories .
• MMF memory management function
• low-level operating systems 113 may manage data stored in the memories and more particularly manage the access to these data, especially in the case where a plurality of high-level operating systems are present in secure element E .
• Low-level operating systems 113 may for example forbid the access to certain data to a high-level operating system .
• Architecture 100 further comprises applications capable of being implemented by primary platform 110 .
• Such applications are for example capable of processing control signals originating from communication interfaces , such as for example a bank transaction using a near- field communication device .
• Each of these applications is implemented by means of fixed data forming the application, for example , instructions , code lines , or permanent data such as user data such as an identi bomb, and of temporary data, execution data, or variable data such as data stacks , temporary cipher keys .
• the execution data of an application are data used by the application only during its execution and which are not kept once the execution of the application has ended .
• an application implements one or a plurality of tasks, each task for example being a succession of instructions. The implementation of a task generates execution data. Certain execution data may be used by different tasks of the application while other may only be used by a single task. It is considered that an application may only implement a single task at a time.
• main task the task which is being executed by the application
• secondary tasks the other tasks of the application which are not being executed.
• the execution tasks are for example tasks which have not been implemented yet and which have not enabled to generate execution data, or tasks which have already been implemented but which have been, for example, interrupted (and paused) , and which thus have already enabled to generate execution data.
• execution data relative to the main task can be distinguished from execution data relative to the secondary tasks.
• the applications may be of different types, for example, a SIM (Subscriber Identity Module) application, a payment application, an application enabling to validate a public transport ticket, etc.
• SIM Subscriber Identity Module
• payment application an application enabling to validate a public transport ticket, etc.
• an application 121 is capable of being directly implemented by primary platform 110.
• Application 121 is for example an application enabling to perform payments by communicating with a near-field communication (NFC) device.
• NFC near-field communication
• an application 122 is capable of sending control signals to primary platform 110 via one of the high-level operating systems, for example, operating system 124B.
• This high-level operating system may for example be one of the operating systems of secure element E exchanging control signals with primary platform 110 .
• the high-level operating system as well as all the applications attached thereto are an application adapted to being implemented by primary platform 110 .
• an application 123 is adapted to sending commands to primary platform 110 via an execution environment 125 (ENV) and one of the high-level operating systems , for example operating system 124A.
• the operating environment is for example of Java or JavaCard type .
• the operating system, as well as all the applications which are attached thereto are an application capable of being implemented by primary platform 110 .
• the components 111 of secure element E more particularly comprise at least one non-volatile memory and at least one volatile memory .
• the non-volatile memory is generally used to store fixed data and the execution code of one or a plurality of applications .
• the volatile memory is generally used to store the execution data of one or a plurality of applications .
• a protection for example , a protection software and/or a firewall mechanism, enabling to prevent an application from accessing the fixed data and the execution data of another application .
• This function is , as previously indicated, implemented by a memory management function 115 MME or memory management unit (MMU) .
• Function 115 enables to link the "virtual" memory known by the application and the physical memories (volatiles and non-volatile ) .
• the high-level operating systems ( 124A and 124B ) do not "directly" have access to the physical memory management . They use a virtual image of this memory .
• the management of this virtual image or virtual memory is divided to enable the high-level operating systems ( 124A and 124B ) to manage the execution codes , as well as the fixed data or the execution data according to their nature .
• the high-level operating systems are indeed those which manage their data and not the low- level operating systems .
• the low-level operating systems and the memory management function achieve the correspondence between the virtual execution data ( the virtual memory) and their storage in the physical memory .
• At least one area or portion of the non-volatile memory is used as a working memory .
• this area of the non-volatile memory operates , as seen from the high-level applications , as a volatile memory, to store temporary data used by the applications during their operation .
• the non-volati le memory may be internal or external to secure element E ( internal or external to circuit HW) . According to whether the non-volatile memory ( its area used as a working memory by the high-level operating systems ) is internal or external to the secure element , the management of this memory di f fers during the execution of a high-level operating system .
• the high-level operating system may be directly executed from the memory where the operating system is located ( is loaded) . It is spoken of an " in place” execution (XIP ) .
• XIP " in place" execution
• the low-level operating systems then enable to manage the execution of a plurality of high- level operating systems.
• the instruction portion (the execution code) of the application remains in the nonvolatile memory; the execution data (permanent and temporary) may then be displaced into the working memory (non-volatile memory) .
• an application may be in at least three different states:
• an active or state of execution (running) by primary platform 110 an active or state of execution (running) by primary platform 110; a standby state, that is, its execution is interrupted but it can be resumed at any time; and an inactive or deactivated state, that is, its execution cannot be restarted without one or a plurality of previous operations.
• all or part of the data relative to its main task are stored in the volatile memory of the circuit and are used for the implementation of the application .
• the data relative to secondary tasks of the application may be stored in the volatile memory or in the working memory (non-volatile ) .
• certain execution data (permanent or temporary) relative to the main task may be located in the working memory (non-volatile ) and be loaded into the volatile memory when the main task requires it .
• This management is performed by memory management function 115 .
• the temporary data are in a working memory assimilated, by the virtual image used by this operating system, to a volatile memory .
• the execution data of a plurality of di f ferent applications of a plurality of di f ferent high- level operating systems are located at the same time in the volatile memory .
• each application only has access to its own data and does not have access to the data of the other application ( s ) .
• the applications are not aware of the presence of data of other applications in the volatile memory .
• Figures 3 to 6 illustrate di f ferent implementations of applications of secure element E , and more particularly the use of the volatile and non-volatile physical (working) memories .
• Figure 3 comprises three views ( a ) , (b ) , and ( c ) , each illustrating a phase of an implementation of a method of execution of applications App20 and App21 of the secure element E described in relation with Figures 1 and 2 . These three views more particularly illustrate the use of working memory WM using the non-volatile memory ( Physical NVM) , considered by the applications as a volatile memory, and of the real volatile memory RAM ( Physical RAM) , of secure element E during the execution of applications App20 and App21 .
• Applications App20 and App21 may be located in a same high-level operating system or in two different high-level operating systems .
• Application App20 is also deactivated but has never been started. It thus has not generated execution data yet.
• application App20 is started by secure element E. More particularly, application App20 is started by low-level operating system 113. Application App20 is then running. Execution data, relative to the main task of application App20, are downloaded or loaded into volatile memory RAM.
• application App20 stores its execution data in volatile memory RAM.
• application App21 keeps on running, and modifies in volatile memory RAM its execution data relative to its main task and, possibly, to secondary tasks. Data are for this purpose transferred from non-volatile working memory WM to volatile memory RAM.
• Figure 4 comprises three views (a) , (b) , and (c) , each illustrating applications App30 and App31 of the secure element E described in relation with Figures 1 and 2. These three views more particularly illustrate the use of nonvolatile working memory WM and of a volatile memory RAM of secure element E during the activation of applications App30 and App31.
• Applications App30 and App31 may be located in a same high-level operating system or in two different high-level operating systems .
• application App30 is a frequent-use application, or resident application, or implements a frequent-use task, or resident task.
• the fact of considering an application as being "frequent" is decided, requested, and/or indicated by the high-level operating system which hosts the application.
• the execution data relative to resident application App30 are stored in a reserved area PRAM30 of volatile memory RAM.
• the area (or physical address range) PRAM30 of memory RAM is always available to store the execution data of application App30, and the execution data of one or of other applications cannot be stored therein.
• application App30 is set to standby. Execution data relative to the main task of application App30 are stored in area PRAM30.
• the main task of application App30 is for example a resident task.
• Application App31 is then started by secure element E. Execution data, relative to the main task and, possibly, to secondary tasks, of application App31 are downloaded or loaded into an area PRAM31 of volatile memory RAM. Area PRAM31 is distinct from area PRAM30. Application App31 is then running.
• application App31 stores its execution data in area PRAM31 of volatile memory RAM.
• An advantage of this embodiment is that a frequent- use application, or resident application, is guaranteed to have space in physical volatile memory PRAM to store its execution data therein.
• a frequent- use application, or resident application is guaranteed to have space in physical volatile memory PRAM to store its execution data therein.
• the size of the resident volatile memory requested by a new resident application which should be activated would be greater than the size of physical volatile memory PRAM, its activation would be denied until memory PRAM is freed, or the available size of memory PRAM is sufficient, or the size of the so- called resident memory requested by the application to be activated is compatible with the available size of memory PRAM. This case may occur if a plurality of resident applications is activated.
• both applications are running in a secure environment (both are executed by the secure element -
• data may be copied into an external non-volatile memory for the application that are not executed, but the execution is always inside the secure element) .
• application App30 which is considered as frequently used or resident benefits from an allocated or reserved area in volatile memory.
• an application here App30
• an application which is considered as a priority application, can claim the fact not to be unloaded from the physical volatile memory and that its execution data ( or part of them) stay in this physical volatile memory, even in standby and when another application (here App 31 ) needs to be executed .
• the management by the low-level operating system, of the allocation of a dedicated portion of the volatile memory to a given application is configured based on a request sent by this given application at first loading ( or in its mapping definition or its memory image ) .
• This information related to this App30 may be unloaded from this physical volatile memory only i f the application is deactivated ( or deleted) .
• An advantage is to avoid downloading the execution data of the priority application from the volatile memory to the non-volatile memory, which allows a fast activation of the priority application, while allowing another application to use the rest of the volatile memory .
• Figure 5 comprises three views ( a ) , (b ) , and ( c ) , each illustrating a phase of an implementation of a method of execution of applications App40 and App41 of the secure element E described in relation with Figures 1 and 2 . These three views more particularly illustrate the use of the non-volatile working memory WM and of the volatile memory RAM of secure element E during the activation of applications App40 and App41 .
• App40 and App41 might be located in a same high-level operating system or in two di f ferent high-level operating systems .
• a first phase application App40 requests being run by secure element E, and then becomes "running". Starting and operation execution data relative to application App40 are transferred, downloaded, or loaded into an area PRAM40 of volatile memory RAM, from area WM40 of non-volatile working memory WM, when the main task of application App40 needs it.
• application App41 requests in turn being run by secure element E.
• the execution data relative to the main task of application App41 are transferred, downloaded, or loaded into an area PRAM41 of volatile memory RAM, from area WM41 of nonvolatile working memory WM.
• the data are stored after the execution data relative to application App40 in volatile memory RAM.
• Application App41 then is running, and application App40 is then at standby.
• Figure 6 comprises three views (a) , (b) , and (c) , each illustrating a phase of an implementation mode of a method of execution of applications App50 and App51 of the secure element E described in relation with Figure 1.
• the three views more particularly illustrate the use of the nonvolatile working memory WM and of the volatile memory RAM of secure element E during the activation of applications App50 and App51.
• App50 and App51 might be located in a same high-level operating system or in two different high-level operating systems .
• application App50 is a frequent-use application, called resident application hereafter, also described in relation with Figure 4.
• resident application App50 requests being run by secure element E .
• Execution, starting, and operating data relative to application App50 are trans ferred, downloaded, or loaded into a reserved area PRAM50 of volatile memory RAM, from area WM50 of nonvolatile working memory WM .
• Area PRAM50 is an area of volatile memory RAM always available to store the execution data of application App50 , and which cannot be used to store execution data of other applications .
• Application App50 is then running .
• application App51 requests being executed by secure element E .
• Execution, starting, and operating data relative application App51 are trans ferred, downloaded, or loaded into an area PRAM51 of volatile memory RAM, from area WM51 of non-volatile working memory WM . These data are stored after the execution data relative to application App50 in volatile memory RAM .
• Application App51 is then running, and application App50 is then at standby .
• An advantage of the described embodiments is that all the applications are loaded into a memory seen, by the high-level operating systems of these applications , as a volatile memory . This allows a fast restarting of each application . Furthermore, when an application claims not to be unloaded from its dedicated area of the phys ical volatile memory, this further speeds up its restarting .
• Another advantage of the described embodiments is that a frequent-use application is guaranteed to have space in the voltage memory RAM of the circuit to store its operation execution data therein .
• the low-level operating systems 113 described in relation with Figure 2 manage the allocation of the memory areas and their filling with the execution data of the applications ( resident or not ) . More particularly, the low-level operating systems are capable of detecting whether an application is a resident application or not .
• a secure element E may comprise a plurality of resident applications .
• Low-level operating systems 113 are further capable of denying the installation of an application as a resident application, for example , i f secure element E comprises too many resident applications , particularly when too large a portion, for example , more than hal f , of volatile memory RAM is reserved to execution data of resident applications .
• low-level operating systems 113 are capable of configuring the si zes of the portions of volatile memory RAM reserved for execution data of resident applications .
• low level operating systems 113 are capable of configuring the si ze of a portion of the volatile memory RAM reserved for execution data of a resident application, to make it equal to zero .
• the secure element comprises a plurality of resident applications , then the execution data of these resident applications are all stored in a same " resident" portion of volatile memory RAM . When this " resident" portion is full , the execution data relative to secondary tasks of the resident applications are displaced towards non-volatile working memory WM .
• the execution data of an application which is inactive or at standby which are stored in working memory WM are only trans ferred into the volatile memory, during a new activation of this application, as and when needed by the application .
• This action is performed by the low-level operating system and is transparent for the application and the corresponding high-level operating system . Indeed, data displacements between the volatile memory and the non-volatile working memory and conversely are not seen by the high-level operating systems .
• the low-level operating system previously displaces , towards the working memory, execution data which are considered as the oldest ( those which have been used less recently) or the less often used .
• An advantage of the disclosed embodiments is that several applications stay present in the volatile memory even when non active . This allows fast toggling from one application of another .
• Another advantage of the disclosed embodiments is that the allocation of the volatile memory is "dynamic" , i . e . , used from an application or another . In other words , execution data of an application are trans ferred into the non-volatile memory only when space in the volatile memory is needed by a second application .
• an application might be divided into one or a plurality of resident sub-applications and one or a plurality of non-resident sub-applications .
• the resident application might be a portion of another application .

Landscapes

• Engineering & Computer Science (AREA)
• Theoretical Computer Science (AREA)
• Software Systems (AREA)
• Physics & Mathematics (AREA)
• General Engineering & Computer Science (AREA)
• General Physics & Mathematics (AREA)
• Computer Security & Cryptography (AREA)
• Computer Hardware Design (AREA)
• Techniques For Improving Reliability Of Storages (AREA)

Applications Claiming Priority (3)

Publications (1)

Family

ID=77750308

Family Applications (2)

Family Applications After (1)

Country Status (3)

Citations (1)

Family Cites Families (13)

• 2021
  • 2021-09-20 EP EP21770041.8A patent/EP4217864A1/de active Pending
  • 2021-09-20 CN CN202180066115.9A patent/CN116235147A/zh active Pending
  • 2021-09-20 WO PCT/EP2021/075778 patent/WO2022063720A1/en not_active Ceased
  • 2021-09-20 EP EP21770040.0A patent/EP4217861A1/de active Pending
  • 2021-09-20 WO PCT/EP2021/075780 patent/WO2022063721A1/en not_active Ceased
  • 2021-09-20 CN CN202180066011.8A patent/CN116209982A/zh active Pending

Patent Citations (1)

Also Published As

Similar Documents

Legal Events