EP1433065A1 - Procede et dispositif de verificateur de code optimise - Google Patents
Procede et dispositif de verificateur de code optimiseInfo
- Publication number
- EP1433065A1 EP1433065A1 EP02783198A EP02783198A EP1433065A1 EP 1433065 A1 EP1433065 A1 EP 1433065A1 EP 02783198 A EP02783198 A EP 02783198A EP 02783198 A EP02783198 A EP 02783198A EP 1433065 A1 EP1433065 A1 EP 1433065A1
- Authority
- EP
- European Patent Office
- Prior art keywords
- type
- patterns
- program
- types
- code
- Prior art date
- Legal status (The legal status 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 status listed.)
- Withdrawn
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/36—Preventing errors by testing or debugging software
- G06F11/3604—Software analysis for verifying properties of programs
Definitions
- the invention relates to the verification of program code loaded in an electronic device, for example - but not exclusively - a device with a limited memory such as a smart card or the like. More particularly, the invention is aimed at verifying programs which are organized according to types linked by parentage relationships, in accordance with current programming techniques in high-level language, and is based on a verification technique which implements a type unification process aimed at determining their common ascendancy.
- the goal is to ensure that the loaded program is consistent with the specificities expected at the level of the device that integrates it.
- an auditor is called upon, whose tasks are typically: to prohibit from: manufacturing and modifying pointers from explicit values;
- program 4 Once program 4 has been loaded into the map, it is necessary to carry out an integration phase in order to make it operational. Verification takes place during this phase, and is used to decide whether the card should integrate the program or, on the contrary, reject it.
- This task is carried out on the basis of an analysis of the byte code, or pseudocode, which will be designated below by the consecrated term of "byte code". It is performed by a byte code 6 checker, which constitutes a functional element of the virtual machine located upstream of the byte code 8 interpreter.
- the verifier 6 determines that the structure of the loaded program 4 is functionally integrated and compatible with what is expected at the level of the card 2. If the verifier validates the program, it transmits it to the byte interpreter code 8 in seen from its execution. Otherwise, either a fault detection likely to jeopardize the card, the verifier 6 controls a process (symbol identified by the number 10) intended to reject the loaded program 4.
- the implementation of such a verification process substantially demands the memory resources of the device in which the verification is carried out.
- the iterative nature of the verification requires numerous updates of the result data, and therefore of transitions of logical states in the storage cells.
- the memory space to be dedicated to the verification process can be considerable for a device with limited memory.
- a safety block 16 - a safety block 16; - a frozen memory 18, accessible in read only (of the type known as ROM (read only memory) in English terminology);
- a volatile working memory 20 (of the so-called RAM (radom access memory) or possibly FlashRAM type in English terminology);
- EEPROM electrically erasable programmable read only memory
- the micro-module 12 of the card 2 is better provided with persistent memory capacity 22 than with volatile memory 20
- persistent memories have a very slow registration time relative to a volatile memory (by a factor ranging from 1000 to 10000), which greatly penalizes the "card" programmer.
- the persistent memory 22 raises a reliability problem linked to its lifetime. Indeed, depending on the technology used, the logical transitions of the states of their memory cells during a writing cause wear which strongly depends on the direction of the transition; we then speak of "stressful" transitions, or operations. With each stressful writing of a value in persistent memory, there is an increasing probability that the memory cell used has a failure. In this case, the value that can be read later will not correspond to what has been written. For example, the founders guarantee a limited number of writes (between 10 4 and 10 6 ) for a persistent memory in EEPROM technology.
- a persistent memory of type EEPROM has four operations:
- - read to read a previously stored value
- - erasure which consists in carrying out a logical state transition from 0 to 1, the storage cells being by default at state 1;
- the erase operation is of the stressful type, and can lead to a failure of the associated memory cell.
- the communication model between the smart card 2 and the terminal with which it communicates is standardized.
- the card is considered as a server controlled by the terminal. Operation is carried out without any collision.
- Communication is of the "half-duplex" type (communication in one direction only allowed at a time). The card does not send an answer to the terminal until after the terminal has asked it a question.
- the “JavaCard” system we are based on an architecture in four layers, as represented in FIG. 3.
- the highest layer contains the user applications, called “embedded” 28 which rely on libraries.
- Java 30 dedicated to the card 2.
- These libraries are a subset of the Java APIs (from the English “Application Program Interface”, or application program interface) constitute the second layer of the “JavaCard” system.
- the applications code is expressed in a byte code which is interpreted by the virtual machine 32.
- the latter executes the application programs and is based on a basic operating system managing the writes in memory, the input-output, calls to cryptographic routines ensuring security, and finally support for the various ISO standards.
- the two lowest layers 32 and 34 are stored in the fixed memory ROM 18 of the card 2.
- Each method has its own execution stack containing the variables and parameters that it manipulates.
- the virtual machine uses registers to store the so-called local variables (variables allocated during the method as well as the parameters thereof).
- Security in a virtual machine 32 is an important problem, because it is a support for the execution of mobile code, the latter being able to come from various and uncertain sources. Thus, the virtual machine 32 may be required to execute a code which jeopardizes the reliability of the system or of other components.
- the defensive virtual machine is said to be "suspicious". During execution, it checks that each byte code element is not being used improperly (for example, it checks that each byte code has the right number of parameters on the execution stack, or also that each call to method is valid). This solution has the defect of severely straining the performance of the virtual machine.
- the Java specification defines a security model based on the analysis of the byte code when it is loaded. The purpose of this analysis is to prove the safety of the loaded program; otherwise, it is rejected. The smart card has capacities deemed too limited to carry out this analysis. This is why various solutions have been proposed.
- an external pre-processing is carried out enabling the code of additional information or proof to be provided allowing the card to verify the code during loading.
- Other approaches aim to integrate a byte code checker into the resources of the device with restricted memory.
- WO-A-01 14958 it has been proposed in patent document WO-A-01 14958 to make an "off-card" modification of the program code, so that the latter maintains its original meaning but becomes easier to verify. This simplifies the verification process by allowing one-pass verification.
- it has the disadvantage of requiring modifications to the program code, and excludes the implementation of certain optimization techniques.
- the verification consists in carrying out a pre-calculation, and in adding its result to the code. This added pre-calculation is then used by the byte code checker to allow the use of simpler algorithms. It is therefore a simplified version of the so-called verification code technique (also known by the term "PCC" from the English “Proof Carrying Code”, or code carrying proof).
- Type inference can be considered as a data flow analysis, the data being the memory cells manipulated by the instructions, expressed in byte code, of the virtual machine. Its purpose is to defend the virtual machine, as well as the basic system, but also user applications, by refusing any code that could harm their integrity.
- the main role of type inference is to make sure that each instruction that makes up a program manipulates the data (memory) and triggers the execution of other processes while respecting their specifications.
- Type inference is a static code analysis process that takes place during the loading phase of an application. It is reputed to be an expensive algorithm in terms of execution time, and also in memory consumption. This can severely penalize the process of loading code into virtual machine 32. Thus, type inference is normally executed by an external third party when the hardware constraints are deemed to be too great (as in a smart card for example).
- the invention proposes, according to a first aspect, a method of verifying a program during its phase of integration into an electronic device, the program being organized according to types linked by parentage relationships , each type being identified by a respective code, the method comprising a type unification phase aimed at determining their closest common ascendant, characterized in that the code is described in the form of a bit pattern according to a formalism which expresses the parentage of the type with which it is associated, and in that the unification phase comprises a logical combination of patterns attributed to the types to be unified, producing the pattern of the type which is their closest common ascendant.
- its pattern contains at least one bit which is identical in value and in position to a corresponding bit of the pattern of its direct ascendant.
- the pattern of a given type preferably comprises a number of bits in a predetermined logic state which is a function of the distance from the type of the common ascendant.
- the memory storage cells are initialized in the logical state from which the transition is in the opposite direction to the direction of the weary transition.
- the logical combination When the wear transition is in the direction from logical state 0 to logical state 1, the logical combination preferably consists in carrying out a logical operation of the AND type between each pair of bits of the same rank of the combined patterns.
- the logical combination When the wear transition is in the direction from logical state 1 to logical state 0, the logical combination preferably consists in carrying out a logical operation of the OR type between each pair of bits of the same rank of the combined patterns.
- the method can be implemented for a program which is in the form of a set of sections of code, each section being identified by a marking which corresponds to an instruction attainable from a connection, by carrying out the verification by sections in an order of sections given according to a determined heuristic.
- the order of the sections to be verified may be the order of succession of a verified section followed by its section which is its successor.
- a volatile memory is used as a cache for storing candidate patterns at the logical combining step, and the candidate patterns are chosen dynamically and by forecast as a function of connection points in the program to be checked. We can then select for storage in volatile memory those of the patterns which correspond to types likely to be the subject of a unification at a given time, and carry out this selection of the patterns to be stored by reference to a program control flow graph to verify.
- control flow graph is established from the markings determined beforehand and from the instructions which link to these markings.
- the verification process is carried out with the execution medium of the device intended to execute the code of the program being checked.
- the invention is particularly advantageous for carrying out verification in an electronic device of the smart card type.
- the invention relates to an electronic device for verifying a program during its phase of integration into an electronic device, the program being organized according to types linked by parentage relationships, each type being identified by a respective code, said device comprising means of type unification to determine their nearest common ascendant, characterized in that it comprises means of identification of type affiliation, the identification of a type being carried out on the base of a bit pattern which constitutes its code according to a determined formalism, and in that the unification means comprise means of logical combination of patterns attributed to the types to be unified, producing the pattern of the type which is their common ascendant. closer .
- This verification device can be made to be able to carry out the method according to the first aspect.
- the invention relates to an electronic device making it possible to load and execute a program organized according to types linked by parentage relationships, each type being identified by a respective code, characterized in that it incorporates a verification device according to the second aspect.
- this device is produced in the form of a smart card.
- - Figure 1 already described, is a diagram which illustrates the principle of integration of a code verifier in a portable device such as a smart card
- - Figure 2 already described, is a block diagram of the functional elements which constitute a micro-module of an open architecture smart card
- FIG. 4 is an example, presented in the form of a table, of a new trace of type inference after modification of the joining hypothesis
- FIG. 5 represents an example of encoding of a non-stressful unifying trellis, in accordance with the preferred embodiment
- FIG. 6 is an example illustrating the use of a control flow graph to speed up verification by means of a software cache.
- the Java virtual machine is a battery machine. It performs operations on working variables called local variables, as well as on a stack. The purpose of this process is to determine the type of each of the local variables and each of the cells in the stack for each point in the program. To do this, we take advantage of the fact that Java byte codes are typed.
- Type inference is based on a static analysis of the code.
- Each instruction in the Java byte code can be modeled as taking its parameters on the stack or in local variables, and generating a result on the top of the stack or in a local variable, if necessary.
- For Java objects and variables allocated during the method their types are determined using the byte code used for their creation.
- T is the root of the trellis; it is only compatible with itself. It is the largest element of the trellis.
- a variable of type T is an unusable variable.
- the type "null” is the element closing the part of the trellis containing the Java classes. It is the smallest element of this part. It is therefore compatible with all Java classes.
- the example of which the type inference trace is given in FIG. 4 illustrates another particularity of the type inference algorithm.
- the first solution is to mark it as being of type T, therefore not usable.
- the "must ()” method is a method defined in the "Father” class whose Java code is valid. Indeed, both "Filsl” and “Fils2" inherited this method.
- this operation consists in determining the common father of two nodes. This node is called the LUB (from English terminology "least-upper-bound").
- LUB from English terminology "least-upper-bound"
- the complexity of this operation increases rapidly as the depth of the trellis increases. It is therefore non-trivial to set it up in the context of a device with limited memory, such as a smart card.
- the local variable vl is of type "null".
- the reference algorithm comprises two successive phases, respectively designated “initialization” and “main loop", the main steps of which are summarized as follows
- Initialization - initialization of the information for each program instruction. Position all the instructions in the "unchanged” state, except for the first instruction which will be positioned in the state as "changed”; fill in the typing information of the latter using the signature, the variables having no type are initialized with T, initialize its TOS with the value 0;
- JavaCard language requires a suitable typing, which implies modifications and adaptations of the algorithms described above, in particular with regard to the lattice of types and subroutines.
- FIG. 5 An example of a JavaCard type lattice is shown in Figure 5.
- the description first addresses the accelerating mechanisms of unification, followed by an optimization of the management of fixed points based on the use of software caches.
- the embodiments address the problem posed by the complexity of inference by two solutions: a unification table and, optionally, an effective and non-stressful unifying coding for memories subject to wear by transitions in a certain direction. .
- a first solution used by the embodiment consists in pre-calculating the unification rules of the types. We then obtain a table with two entries (the two types tl and t2 to be unified), which provides the answer to the question that is worth tl n t2. There then arises the problem linked to the infinity of types available: it is indeed possible to load a large number of classes into the smart card. Adding a new class would therefore result in the creation of a new row or column in the unification table, as well as the calculation of the result of unification thereof with all the types already present in the map to this moment .
- Table 1 example of a portion of the unification acceleration table.
- the information handled during the inference is the types.
- a coding is established according to a formalism which expresses its filiation. This coding is used to achieve more efficient unification.
- a technique using a bijection of the operations on the trellis to the Boolean operations is used.
- the encodings used make it possible to find the common father of two elements of a trellis using a composition of logical functions.
- the result, which constitutes unification, then returns the code which corresponds, according to the established formalism, to the common father of two types.
- the typing information must, in most cases, be stored in persistent memory 22, in particular of the EEPROM type, because of their size.
- This type of memory is subject to stress. More particularly, the memory suffers from wear caused by a plurality of transitions of logical states in a particular direction, in this case from 0 to 1.
- FIG. 5 represents a case of non-stressful unifying lattice.
- Top for "top” in English.
- the formalism used in the embodiment adapted to avoid as much as possible the stressful transitions in the EEPROM memory 22 of the card 2, fixes as code for this common father a pattern formed by bits at state 0.
- the number of bits forming this pattern is chosen according to the maximum number of types in the trellis which share the same common ascendant. Any type is coded with a pattern comprising the same number of bits. In the example, six bits constitute a pattern, the common father T having the pattern "00 0000". We ensure in particular that this number of bits allows:
- its pattern comprises at least one bit which is identical in value and in position to the pattern of its direct ascendant.
- each bit at state 1 of this ascendant is found at the same position in the pattern of this given type. (The latter also includes an additional bit at state 1 which is specific to it, and makes it possible to distinguish it between other direct descendants of this direct common ascendant.)
- the most important property of this encoding is that it is particularly suitable for storage in EEPROM: we may have to store the typing information in the EEPROM in particular, because it can be large compared to the others memories available from the smart card.
- the stress of the EEPROM is limited when dropping bits (going from 1 to 0). Unification being reduced to a logical AND, by applying it to two types, we only change bits from 1 to 0 and never from 0 to 1. Thus, we considerably reduce stress and increase the lifespan of the EEPROM.
- Coding of this kind can be adapted to any type of EEPROM. Indeed, some have inverse properties for writing stress, ie a stressful transition caused by the passage 1 to 0. In this case, the coding is changed so that the unification is reduced to a logical OR. More particularly, the logical states of the patterns are systematically reversed with respect to those used for the AND combinations described above. To return to the example of FIG. 5, the common father T is then assigned the motif 11 1111, the motif 01 1111 of the "Int" type, etc. It can be easily verified on the basis of simple principles of Boolean logic that the same results are obtained in this case with the logical OR operation in place of the AND logical operation in the context of FIG. 5.
- the coding can be made more compact using a more complex Boolean function, by means of storage in EEPROM memory which can cause stressful transitions.
- a heuristic must make it possible to predict not only the patterns soon to be combined, but also, conversely, to predict those more likely to be combined in order to eliminate them. This implies dynamic and evolving management.
- heuristics are advantageously used which require little calculation so as not to burden the resources used.
- Marking selection heuristic to be checked The optimized type inference algorithm described above works at the connection points of JavaCard programs. During the inference, there may be several labels marked as being to be verified. This therefore leads to electing one of them and checking the corresponding code section. It is therefore necessary to have a selection criterion.
- This heuristic can be used for reference. It provides good results on an evaluation game. It consists in choosing at random the next marking to be checked among the types marked. - The "Next" heuristic.
- the "Next" heuristic is relatively simple. It consists in electing the marking which is the successor of the marking which has just been verified. The necessary number of linear verification passes are thus carried out.
- the "Lazy” heuristic is optimal in terms of efficiency and simplicity. It consists of taking as a mark to verify the first marked.
- JavaCard programs come from the conversion of Java code compiled using the Java development kit, known by the English term JDK from "Java Development Kit”. However, this generates fairly linear code. Program breakpoints are quite often found at the end of the byte code. This observation is exploited by therefore systematically using the first marking as being to be verified. Thus, we focus on the beginning of the program to never come back to it later.
- the "Lazy” heuristic makes it possible to obtain a value of 1.3 for the ratio r defined above.
- Fine-tuned heuristics can be implemented, in particular by using the flow control graph of the verified program.
- the graph can in particular be used to control software caches.
- a software cache is set up between the EEPROM and the RAM to better manipulate the type "frames". This implies a phase of electing the data to delete (destock) from the cache being verified, and therefore a cache management policy.
- control flow graph determines the cache management policy.
- the control flow graph is provided in accordance with the example illustrated with reference to FIG. 6.
- Table II shows a possible trace of the type inference for this example.
- Table II possible execution trace of the type inference for the example of FIG. 6.
- the preferred embodiment makes it possible to obtain simple verification systems which opens up the possibility of implementing a verifier fully embedded in a microprocessor card or other device with restricted memory.
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Software Systems (AREA)
- Computer Hardware Design (AREA)
- Quality & Reliability (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Devices For Executing Special Programs (AREA)
- Stored Programmes (AREA)
Abstract
Description
Claims
Applications Claiming Priority (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
FR0112278A FR2830095B1 (fr) | 2001-09-24 | 2001-09-24 | Procede et dispositif de verifieur de code optimise |
FR0112278 | 2001-09-24 | ||
PCT/FR2002/003249 WO2003027851A1 (fr) | 2001-09-24 | 2002-09-24 | Procede et dispositif de verifieur de code optimise |
Publications (1)
Publication Number | Publication Date |
---|---|
EP1433065A1 true EP1433065A1 (fr) | 2004-06-30 |
Family
ID=8867556
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
EP02783198A Withdrawn EP1433065A1 (fr) | 2001-09-24 | 2002-09-24 | Procede et dispositif de verificateur de code optimise |
Country Status (5)
Country | Link |
---|---|
US (1) | US20050044542A1 (fr) |
EP (1) | EP1433065A1 (fr) |
CN (1) | CN1589435A (fr) |
FR (1) | FR2830095B1 (fr) |
WO (1) | WO2003027851A1 (fr) |
Families Citing this family (8)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7320129B2 (en) * | 2003-05-14 | 2008-01-15 | Hewlett-Packard Development Company, L.P. | Native language verification system and method |
US7263690B1 (en) * | 2003-11-14 | 2007-08-28 | Sun Microsystems, Inc. | Mechanism for safe byte code in a tracing framework |
CN100465853C (zh) * | 2004-11-15 | 2009-03-04 | 南京大学 | 基于程序内部行为监控的软件安全保障的方法 |
US9286026B2 (en) | 2006-09-08 | 2016-03-15 | Aten International Co., Ltd. | System and method for recording and monitoring user interactions with a server |
US8120583B2 (en) * | 2006-09-08 | 2012-02-21 | Aten International Co., Ltd. | KVM switch capable of detecting keyword input and method thereof |
US8201155B2 (en) * | 2009-01-09 | 2012-06-12 | Microsoft Corporation | Handling multiple definition of types |
US8549502B2 (en) * | 2010-06-21 | 2013-10-01 | Microsoft Corporation | Compiler with user-defined type inference rules |
CN112487841A (zh) * | 2020-12-15 | 2021-03-12 | 北京爱创科技股份有限公司 | 一种快速验证包装关系的方法及装置 |
-
2001
- 2001-09-24 FR FR0112278A patent/FR2830095B1/fr not_active Expired - Fee Related
-
2002
- 2002-09-24 WO PCT/FR2002/003249 patent/WO2003027851A1/fr not_active Application Discontinuation
- 2002-09-24 US US10/490,415 patent/US20050044542A1/en not_active Abandoned
- 2002-09-24 CN CNA028232844A patent/CN1589435A/zh active Pending
- 2002-09-24 EP EP02783198A patent/EP1433065A1/fr not_active Withdrawn
Non-Patent Citations (1)
Title |
---|
See references of WO03027851A1 * |
Also Published As
Publication number | Publication date |
---|---|
US20050044542A1 (en) | 2005-02-24 |
WO2003027851A1 (fr) | 2003-04-03 |
CN1589435A (zh) | 2005-03-02 |
FR2830095A1 (fr) | 2003-03-28 |
FR2830095B1 (fr) | 2003-10-31 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
EP2299363B1 (fr) | Procédé de nivellement de l'usure dans une mémoire non volatile | |
EP1782191B1 (fr) | Procede de chargement d'un logiciel en langage intermediaire oriente objet dans un appareil portatif | |
FR2667171A1 (fr) | Support portable a micro-circuit facilement programmable et procede de programmation de ce micro-circuit. | |
EP1212678A2 (fr) | Protocole de gestion, procede de verification et de transformation d'un fragment de programme telecharge et systemes correspondants | |
EP1433065A1 (fr) | Procede et dispositif de verificateur de code optimise | |
WO2003010666A1 (fr) | Procede pour la compression d'un code interprete par analyse semantique | |
FR2864654A1 (fr) | Procede de determination de caracteristiques operationnelles d'un programme | |
EP1728354A1 (fr) | Procede d'authentification dynamique de programmes par un objet portable electronique | |
FR2823330A1 (fr) | Procede et systeme de gestion de donnees destinees a etre stockees dans une memoire, par exemple du code d'une application charge dans une carte a puce programmable | |
EP3246820A1 (fr) | Gestion du stockage dans une mémoire flash | |
EP1512071B1 (fr) | Procede de verification de codes pour microcircuits a ressources limitees | |
FR2748134A1 (fr) | Procede et dispositif permettant a un programme fige de pouvoir evoluer | |
WO2006048378A1 (fr) | Procede de chargement d'un code logiciel en langage intermediaire oriente objet dans un appareil portatif | |
FR2765362A1 (fr) | Module de securite comportant des moyens de creation de liens entre des fichiers principaux et des fichiers auxiliaires | |
EP3203405B1 (fr) | Procede d'execution d'instructions d'applications orientees objet par un interpreteur | |
FR2854261A1 (fr) | Procede d'execution d'une application logicielle par l'intermediaire d'un programme d'amorce logicielle et architecture informatique pour la mise en oeuvre du procede | |
EP4018313B1 (fr) | Récuperateur de données dans un dispositif électronique | |
EP2252978B1 (fr) | Carte a circuit integre ayant un programme d'exploitation modifiable et procede de modification correspondant | |
FR2950463A1 (fr) | Procede de lecture d'une memoire non volatile au moyen de metadonnees et d'une table de correspondance | |
EP4312128A1 (fr) | Procede de gestion d'une memoire d'un element securise | |
FR2935502A1 (fr) | Procede d'optimisation de la duree de vie d'une memoire non volatile reinscriptible. | |
FR3051575A1 (fr) | Gestion de l'effacement dans une memoire flash | |
FR2950464A1 (fr) | Procede de nivellement de l'usure dans une memoire non volatile |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PUAI | Public reference made under article 153(3) epc to a published international application that has entered the european phase |
Free format text: ORIGINAL CODE: 0009012 |
|
17P | Request for examination filed |
Effective date: 20040426 |
|
AK | Designated contracting states |
Kind code of ref document: A1 Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR IE IT LI LU MC NL PT SE SK TR |
|
AX | Request for extension of the european patent |
Extension state: AL LT LV MK RO SI |
|
17Q | First examination report despatched |
Effective date: 20080104 |
|
GRAP | Despatch of communication of intention to grant a patent |
Free format text: ORIGINAL CODE: EPIDOSNIGR1 |
|
GRAC | Information related to communication of intention to grant a patent modified |
Free format text: ORIGINAL CODE: EPIDOSCIGR1 |
|
STAA | Information on the status of an ep patent application or granted ep patent |
Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN |
|
18D | Application deemed to be withdrawn |
Effective date: 20110117 |