WO2002075589A2 - Systeme de banque de donnees - Google Patents

Systeme de banque de donnees Download PDF

Info

Publication number
WO2002075589A2
WO2002075589A2 PCT/DE2002/000945 DE0200945W WO02075589A2 WO 2002075589 A2 WO2002075589 A2 WO 2002075589A2 DE 0200945 W DE0200945 W DE 0200945W WO 02075589 A2 WO02075589 A2 WO 02075589A2
Authority
WO
WIPO (PCT)
Prior art keywords
data
entry
database system
column
database
Prior art date
Application number
PCT/DE2002/000945
Other languages
German (de)
English (en)
Other versions
WO2002075589A3 (fr
Inventor
Martin GÖTTMANN
Original Assignee
Bfm Building + Facility Management 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 Bfm Building + Facility Management Gmbh filed Critical Bfm Building + Facility Management Gmbh
Priority to EP02729794A priority Critical patent/EP1374100A2/fr
Publication of WO2002075589A2 publication Critical patent/WO2002075589A2/fr
Publication of WO2002075589A3 publication Critical patent/WO2002075589A3/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/28—Databases characterised by their database models, e.g. relational or object models
    • G06F16/289—Object oriented databases
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/28—Databases characterised by their database models, e.g. relational or object models
    • G06F16/284—Relational databases

Definitions

  • the present invention relates to a database system which is based in particular on a relational database in which a database consisting of a multiplicity of data fields is stored, and a method for storing, changing and displaying the database.
  • the term database is understood to have been published by DTV Verlag in its original meaning as a structured, content-related database, such as addresses, customer or employee data.
  • a database is usually used to refer to the application program that is used to manage the database.
  • the data itself is called the database or database.
  • a so-called database management system accesses this database, displays components of the database, and is able to modify the database and search for components.
  • a database consists of a series of data records, each of which in turn is composed of a series of data fields.
  • each address corresponds to a record and each part of the address corresponds to a field.
  • FIG. 1 shows a conventional data record 100 that comes from an address database.
  • the data record 100 consists of the data fields 110 last name, first name, street, city and telephone.
  • the last name field contains the name Huber
  • the first name field contains Henriette, etc.
  • These data field details 120 are also referred to below as data field contents or merely contents.
  • the structure of the data records is determined when the database is created. To do this, you specify which data fields make up a data record and how much space should be reserved for each data field. The structure of some programs can be changed later. You can insert data fields or enlarge or reduce the space reserved for a data field. Depending on the definition of the database structure, the data for the individual data records are then entered.
  • This type of structured storage of the data means that for each storage or storage of a data record it is assumed that the structure of the data record to be stored or saved corresponds at least to a substructure of the database. However, if a data record is to be saved that does not correspond in its structure to the existing data structures or parts thereof, the database itself must be expanded by the new structural element (field / fields) before the data record can be saved, i.e. columns are added to the table. This can lead to redundancies, since the "old" data records may not have any information regarding the new columns.
  • a special problem is the storage of data records with a new data record structure. This data record structure must be defined by the user. This requires changes in the database management system and in the application programs that work with this database.
  • FIGS. 2 and 3 show examples of such conventional databases displayed in tabular form, FIG. 2 showing a database in which customer addresses are stored, and FIG. 3 a further database in which individual orders are stored and which is related to the customer database are.
  • FIG. 2 there are several vertical ones Records 200 shown.
  • each data record 300 is on its own line, the data of the individual fields are arranged in columns.
  • the meaning of the column is interchanged with that of the row.
  • the conventional database can be searched for individual data records or for those data records that meet one or more criteria.
  • the data records found can be displayed or printed out in list or form form. Only one record is displayed in form mode.
  • the data records can be sorted according to one or more fields for display or printing.
  • a so-called index must be created for the fields to be sorted.
  • the index is usually saved in a separate file and speeds up sorting and
  • Some database programs allow very complex databases to be created that can be used by other users, even though these users do not have the database program at all.
  • Databases that are based on a fixed structure are well suited for managing data that is always the same or at least very similar. They are hardly suitable for managing unstructured data or data with an inhomogeneous structure. Even a database with data of different lengths cannot be created with every data program. Some conventional programs offer so-called memo fields, the lengths of which can usually be several KB. If several fields of this type are required or if structuring is not possible, a text-oriented database program, a so-called full-text database, is required allows unstructured data entry and still enables the selection and linking of data records.
  • An alternative for such tasks are object-oriented databases.
  • An important distinguishing criterion for databases and at the same time decisive for the performance of the program is the database model used, which is also referred to as the data model and defines the relationships of the individual data. Two data models are described in more detail below.
  • the hierarchical data model In such a database, the individual data records are stored in a tree structure, similar to a hierarchical file system. This data model is widely used. If two data are linked, you can assign exactly one data record from the other database to each data record from one database; multiple links existing at the same time are not permitted.
  • the hierarchical data model is difficult to reconcile with typical data structures that occur in practice. For example, the individual employees - broken down by departments and projects - could be stored in a database. In practice, however, it often happens that individual employees work for different departments and on several projects.
  • the basis of this model is a table-like structure. Each row of the table represents a data record, which is also called a tuple; the individual columns contain the data fields.
  • a relationship that is, a relationship, between different databases.
  • a customer database could be linked to a database in which the orders received are stored (see FIGS. 2 and 3), and the address and the respective orders are displayed for each or for selected customers.
  • Such databases are indispensable for more complex applications, for example in order processing in companies. Problems arise when introducing additional data values or
  • An object of the invention is to provide a database system which has no restriction with regard to the content and with regard to extensions of the data structures and the portability to other relational
  • Another task is to completely avoid redundancies.
  • Figure 1 shows a conventional data set from a
  • FIG. 2 shows a conventional tabular database in which customer addresses are stored.
  • FIG. 3 shows a further conventional database in which individual orders are stored and which is related to
  • FIG. 4 shows an embodiment of the present invention.
  • Figure 5 shows a four-column table of values according to the present
  • Figure 6 shows an object table according to the present invention.
  • Figure 7 shows an attribute table according to the present invention.
  • Figure 8 shows a table of contents according to the present invention.
  • Figure 9 shows hierarchically structured local references.
  • Figure 4 illustrates an embodiment of the present invention.
  • a data field of an object In the database system according to the invention, several tables are used to define a data field of an object. Note that this is a data field of an object and not a data field of a data record.
  • an object is equivalent to one or more conventional data records.
  • the conventional data record was characterized in that it corresponded, for example, to a line in a relational (tabular) database base, the number of data fields belonging to the data record being determined by the number of columns in the database.
  • the possible content, the order and the data format of a Data field was determined by the column, the column order and the column unit.
  • a large library wants to store its inventory electronically in the form of a relational database. But not only the books of the library, but also every other object such as chairs, tables, shelves, etc. should be recorded. Contracts that the library has concluded with other libraries on the loan of books are even conceivable as additional items. All of these objects are objects.
  • the objects can be assigned to different object types, which can be created as desired by the user of the database according to the invention. For example, all paperbacks, lexicons, novels, non-fiction books or the like could belong as objects to the object type book. Tables, chairs and shelves could belong to the object type of furniture.
  • the object type furniture can be characterized by properties such as price, width, height, depth or the like.
  • each data record would contain all the properties of all possible objects in the form of a data field, i.e. a column would have to be created in the conventional tabular database for each different object property, this would result in a table of considerable size to lead. This is the only way to ensure that any object, no matter what Object types he heard can be recorded in the database. This also leads to a considerable number of redundancies.
  • Another possibility to solve this problem would be to create different database tables, whereby a separate table would have to be created for each object type.
  • Each conventional data field (i.e. property of an object) is stored in the database according to one embodiment as a row in a four-column so-called value table.
  • the table of values 400 is shown in the middle in FIG.
  • the four columns of the value table 400 are illustrated schematically by the four references WertID 472, txt 463, tag 433 and obj 443.
  • Column 463, designated “txt” references a content table 460, which also has two columns 461 and 462, which are designated "TXT" and "TxtlD”.
  • Column 433 labeled "tag” references an attribute table 430 that has two columns 431 and 432 that are labeled "TAG" and "TagID”.
  • FIG. 5 shows a value table 500 which corresponds in structure to the value table 400 from FIG. 4 in greater detail.
  • the value table 500 is formed from four columns.
  • Column 572 labeled "WertID” contains sequential numbers. The serial numbers uniquely identify a data field, ie each data field is assigned a single number and vice versa.
  • Column 563 designated “txt”, contains content references that can be assigned several times to different data fields and each clearly refer to an entry in content table 460 in FIG. 4. Simply put, there are pointers in the respective fields of this column, that point to the content of the respective data field, such as the first name Max. However, this first name can be assigned to several people who are stored in the database. "Max" could just as well be used as a surname, company name or other name.
  • a column 533 labeled "tag" contains attribute references that can be assigned several times to different data fields and also uniquely refer to an entry in the attribute table 430 in FIG.
  • the fields in the third column are equivalent to pointers that reference data field or object properties (ie, for example, field names 110 of FIG. 1) or attributes.
  • a table of contents is shown in detail in FIG. 8, which will be discussed in more detail later.
  • the attributes of different objects which, however, belong to the same object type, can occur more than once, which means that, figuratively speaking, several pointers from the third column can point to an identical entry in the attribute table.
  • obj contains object references which can be assigned several times to different data fields and each clearly refer to an entry in the object table 440 in FIG. Similar to the two previous columns, the fields of the "obj" column are pointers that point to an object stored in the object table. Again, multiple pointers can point to the same object. This becomes clear when you consider that an object can have several different properties, ie several combinations of one and the same element of the "obj" column 543 with several different elements of the third column "tag" 533 such as book - author, book - Year of publication or similar are conceivable.
  • FIG. 6 shows an object table 640 which contains example values and whose functionality corresponds to the object table 440 of FIG. 4.
  • the object table 640 is constructed in two columns.
  • a first column 641 is labeled "OBJ”.
  • a second column 642 is called "ObjID”.
  • the entries in the object table 640 consist of two entry parts, namely a first entry part corresponding to an element of the first column "OBJ", which represents a reference to another object, and a second entry part belonging to this first entry part corresponding to the "ObjID” column.
  • the functionality of the first entry part, corresponding to column 641 "OBJ" will be discussed in more detail below.
  • the object table 640 not only uniquely identifies an object (in the sense of any object in the example of the library), but also at the same time a reference to a hierarchically arranged one
  • This hierarchically arranged reference system can, for example, be based on a spatial reference system such as the
  • the location reference system could also be the building of the library as such.
  • the building in turn can be divided into individual floors. These floors can be divided into individual rooms. The breakdown just carried out has to the next smaller local area
  • the location references are a hierarchical structure of a location that provides information about the "who” and "where", i.e. which object is in which location.
  • each object has exactly one location reference, i.e. a father to be referred
  • the attribute table 730 contains example entries suitable for FIGS. 5 and 6. Like the object table 640 of FIG. 6, it is also arranged in two columns.
  • the first column 731 is labeled "TAG”.
  • the second column 732 is labeled "TagID”.
  • An entry (i.e. a row) in the attribute table 730 thus consists of two parts.
  • the first entry part TAG is basically divided into three parts, which are separated by a period. These three components designate the first - the already mentioned - object type, the second a data field name and the third an attribute that can be understood as a unit in this context.
  • the data field name corresponds to the field names or column headings.
  • the third component of the first entry part represents a unit size that describes the content of the associated data field in more detail. Possible unit sizes are, for example, "Text”, “Number”, “Currency”, or "Date”.
  • a second entry part TagID belonging to the first entry part corresponds to one of the entries in column 533 of the value table 500 in FIG. 5 and represents the target of the pointer designated there. The TagID changes from the value table 500 in FIG. 5 to the attribute table 730 in FIG referenced.
  • the first entry part of an entry in the attribute table 730 can thus have a structure of the type "object type._object ID ._. ID_" (see also TAG for TagID 362).
  • a content table 860 is shown in FIG. 8, the functionality of which corresponds to the content table 460 of FIG. 4.
  • the content table 860 also has two columns.
  • the first column 861 is labeled "TXT”.
  • the second column 862 is called "TxtlD”.
  • the entries in the content table 860 in FIG. 8 are exemplary and match the entries shown in FIGS. 5, 6 and 7.
  • the content references contained in column 563 of value table 500 in FIG. 5 refer to a second entry part (TxtID) of an entry in content table 860.
  • a first entry part belonging to the second part represents the content of the data field. For example, the data field with the value ID "12" from FIG.
  • FIG. 9 the relationship between the objects in the form of a location reference given in connection with FIG. 6 is once again illustrated by way of example.
  • the location reference organizes information hierarchically according to the location it concerns or where it occurs.
  • a further embodiment of the invention allows the time assignment of objects. For example, one might be interested - to stay in the picture of the example above - where a book XY from the library, which is currently in room Z on the first floor, was previously located before being placed in this room. To do this, it would be necessary to also include temporal information from the value table 500 in FIG can see. This is achieved by defining an additional column that contains time references. Similar to the location references, these time references refer to a time table (not shown). This time table is also created in two columns. The first column again contains references between objects, the second column contains the associated time references (time ID, not shown), to which the time pointers from the further column of the value table point.
  • Object types For example, a paperback ABC - as mentioned at the beginning - belongs to the object type book. No associated object exists yet
  • Databases are subject to freely definable access rights. A distinction is made between the access rights “write &read”,”read” and “no access”. The rights are organized in so-called user groups. A user is always associated with at least one user group. An object or location reference is only then visible to a user group , if the "Write &Read” or "Read” right has been assigned to the object concerned. As soon as one object is open for write access, all others receive read and Authorized users only have the "Read” right during this time. As soon as the write access has ended, the write rights are also available to other users.
  • Search language can be used, for example, SQL (Structured Query Language).
  • the search enables the targeted finding of objects, for example in relation to location.
  • the location reference can be limited by navigating into the desired location reference (as shown for example in FIG. 9).
  • the advanced search also offers the possibility to search for specific information within objects, i.e. for example, to search for a specific property. All properties of the object are shown. If no object is selected in the advanced search, the field entries of all objects are available to refine the search.
  • the database system itself works with indexes of the tables wherever possible, which is favorable for data processing systems.
  • An advantageous aspect is the avoidance of redundancies.
  • Object-oriented data access is possible. No additional tables are created when adding new object types. There are detailed or combined search options up to full-text searches.
  • the data model according to the present invention is based on the standardized, relational database model, which represents considerable advantages with regard to the importability of data, since it can be used independently of the respective software manufacturer. Data export to XML is also possible.
  • Another advantage is that objects can be linked together using a standardized mechanism. It is clear to a person skilled in the field of software engineering that the table of values can be transposed, ie rows can be exchanged with columns and vice versa, without changing the functionality of the invention. The same applies to the structure of the three or further tables.
  • a computer program product can be represented by any suitable storage medium on which the computer program that carries out the method according to the present invention is stored.

Abstract

L'invention concerne un système de banque de données et un procédé permettant de conduire des opérations dans un système de banque de données, dans lequel une pluralité de jeux de données peuvent être mémorisés dans une mémoire d'ordinateur. Chaque jeu de données comprend un nombre quelconque de champs de données. L'invention se caractérise en ce qu'une base de données du système de banque de données présente une table de valeurs à plusieurs colonnes avec un nombre quelconque de lignes, une table des matières pour mémoriser les contenus des champs de données, une table d'attributs pour mémoriser des attributs de champs de données et une table d'objets pour mémoriser des rapports entre des objets. Dans la table de valeurs, chaque ligne correspond à un champ de données d'un jeu de données ; une colonne (txt) contient des références de contenu (TxtID) qui peuvent être attribuées de manière multiple pour différents champs de données et font dans chaque cas référence de manière univoque à un enregistrement (TXT, TxtlD) de la table des matières ; une autre colonne (tag) contient des références d'attributs (TagID) qui peuvent être attribuées de manière multiple pour différents champs de données et font dans chaque cas référence de manière univoque à un enregistrement (TAG, TagID) de la table d'attributs ; ainsi qu'une autre colonne (obj) contenant des références d'objet (ObjID) qui peuvent être attribuées de manière multiple pour différents champs de données. Les champs de données qui appartiennent dans chaque cas à une référence d'objet forment chacun un jeu de données et les références d'objet (ObjID) font référence de manière univoque à un enregistrement (OBJ, ObjID) de la table d'objets.
PCT/DE2002/000945 2001-03-20 2002-03-15 Systeme de banque de donnees WO2002075589A2 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
EP02729794A EP1374100A2 (fr) 2001-03-20 2002-03-15 Systeme de banque de donnees

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE10113515A DE10113515A1 (de) 2001-03-20 2001-03-20 Datenbanksystem
DE10113515.7 2001-03-20

Publications (2)

Publication Number Publication Date
WO2002075589A2 true WO2002075589A2 (fr) 2002-09-26
WO2002075589A3 WO2002075589A3 (fr) 2003-10-09

Family

ID=7678227

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/DE2002/000945 WO2002075589A2 (fr) 2001-03-20 2002-03-15 Systeme de banque de donnees

Country Status (3)

Country Link
EP (1) EP1374100A2 (fr)
DE (1) DE10113515A1 (fr)
WO (1) WO2002075589A2 (fr)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102005009014A1 (de) * 2005-02-28 2006-09-07 Vodafone Holding Gmbh Verfahren und System zur Verwaltung von Objekten eines mobilen Endgerätes
DE102011087843B4 (de) 2011-12-06 2013-07-11 Continental Automotive Gmbh Verfahren und System zur Auswahl mindestens eines Datensatzes aus einer relationalen Datenbank

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1998001808A1 (fr) * 1996-07-08 1998-01-15 Ser Systeme Ag Produkte Und Anwendungen Der Datenverarbeitung Systeme de banque de donnees
US5857195A (en) * 1990-08-31 1999-01-05 Fujitsu Limited Method of developing and modifying self-describing database management system to generate a new database management system from an existing database management system
WO2002103573A1 (fr) * 2001-06-14 2002-12-27 Ubs Ag Systeme de base de donnees virtuel flexible comportant un referentiel de parametres d'application hierarchique

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6112209A (en) * 1998-06-17 2000-08-29 Gusack; Mark David Associative database model for electronic-based informational assemblies

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5857195A (en) * 1990-08-31 1999-01-05 Fujitsu Limited Method of developing and modifying self-describing database management system to generate a new database management system from an existing database management system
WO1998001808A1 (fr) * 1996-07-08 1998-01-15 Ser Systeme Ag Produkte Und Anwendungen Der Datenverarbeitung Systeme de banque de donnees
WO2002103573A1 (fr) * 2001-06-14 2002-12-27 Ubs Ag Systeme de base de donnees virtuel flexible comportant un referentiel de parametres d'application hierarchique

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
BERGAMASCHI S ET AL: "Object Wrapper: an object-oriented interface for relational databases" EUROMICRO 97. NEW FRONTIERS OF INFORMATION TECHNOLOGY., PROCEEDINGS OF THE 23RD EUROMICRO CONFERENCE BUDAPEST, HUNGARY 1-4 SEPT. 1997, LOS ALAMITOS, CA, USA,IEEE COMPUT. SOC, US, 1. September 1997 (1997-09-01), Seiten 41-46, XP010243952 ISBN: 0-8186-8129-2 *
NADKARNI P M: "QAV: QUERYING ENTITY-ATTRIBUTE-VALUE METADATA IN A BIOMEDICAL DATABASE" COMPUTER METHODS AND PROGRAMS IN BIOMEDICINE, ELSEVIER, AMSTERDAM, NL, Bd. 53, Nr. 2, Juni 1997 (1997-06), Seiten 93-103, XP000889755 ISSN: 0169-2607 *

Also Published As

Publication number Publication date
EP1374100A2 (fr) 2004-01-02
DE10113515A1 (de) 2002-10-02
WO2002075589A3 (fr) 2003-10-09

Similar Documents

Publication Publication Date Title
EP0855062B1 (fr) Systeme d'informations et procede de memorisation de donnees dans un systeme d'informations
EP0910829B1 (fr) Systeme de banque de donnees
DE19960043B4 (de) Verfahren zum Navigieren in einer Baumstruktur
DE60035432T2 (de) System zur verwaltung der rdbm fragmentierungen
EP0523269A1 (fr) Système informatique pour la gestion de données
DE102013015355A1 (de) Nutzergesteuerte Findemaschine
DE19947136A1 (de) Verfahren und Vorrichtung zum Erstellen und Verteilen von Berichten
EP1276056B1 (fr) Méthode pour administrer une base de données
WO2007137308A1 (fr) Procédé de commande d'un système de gestion de banque de données relationnelle
WO2000054167A2 (fr) Dispositif de detection et de navigation pour documents hypertexte
DE19715723A1 (de) Array-Verfahren
EP1941395A1 (fr) Procede pour commander un systeme de banque de donnees relationnelle
EP1502211B1 (fr) Procede et dispositif de commande d'acces dans des reseaux de savoirs
EP1374100A2 (fr) Systeme de banque de donnees
EP0856176A1 (fr) Systeme de gestion de banque de donnees et procede de transmission de donnees
DE102010064167A1 (de) Dynamische Berichtserstellung
DE19729911A1 (de) System zur Verbesserung der Organisation von Daten einer Dokumentation
DE102008062830B3 (de) Vorrichtung und Verfahren zum Speichern, Suchen und Darstellen von Informationen
DE10025219A1 (de) Verfahren, Computerprogrammprodukt und Vorrichtung zum automatischen Verknüpfen von Datensätzen aus zumindest einer Datenquelle sowie System zum Abrufen von verknüpften Datensätzen aus zumindest einer Datenquelle
DE19951756B4 (de) Verfahren zur Datenverwaltung sowie Computerprogramm und -system zu dessen Ausführung
EP1239377A1 (fr) Système de gestion de données et procédé de gestion de la synchronisation de structures de données
DE19914454A1 (de) Rechnergestütztes System und Verfahren zum Aufbauen einer Datenbank
DE10037639A1 (de) Verfahren zum Organisieren von Datenbeständen auf einem Speichermedium durch hierarchisches Clustering u. Computerprogramm
WO2008131465A1 (fr) Procédé de commande d'un système de banque de données relationnelle
EP3877866A1 (fr) Procédé et dispositif de mémorisation de données et de relations entre ces dernières

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A2

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY BZ CA CH CN CR CU CZ DK DM DZ EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NO NZ PL PT RO RU SD SE SG SI SK SL TJ TM TR TT TZ UA UG US UZ VN YU ZA ZW

AL Designated countries for regional patents

Kind code of ref document: A2

Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
WWE Wipo information: entry into national phase

Ref document number: 2002729794

Country of ref document: EP

WWP Wipo information: published in national office

Ref document number: 2002729794

Country of ref document: EP

WWR Wipo information: refused in national office

Ref document number: 2002729794

Country of ref document: EP

WWW Wipo information: withdrawn in national office

Ref document number: 2002729794

Country of ref document: EP

NENP Non-entry into the national phase

Ref country code: JP

WWW Wipo information: withdrawn in national office

Country of ref document: JP