WO2002043345A1 - Improvement in electronical transaction security - Google Patents
Improvement in electronical transaction security Download PDFInfo
- Publication number
- WO2002043345A1 WO2002043345A1 PCT/EP2001/000983 EP0100983W WO0243345A1 WO 2002043345 A1 WO2002043345 A1 WO 2002043345A1 EP 0100983 W EP0100983 W EP 0100983W WO 0243345 A1 WO0243345 A1 WO 0243345A1
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- terminal
- server
- data
- access
- request
- Prior art date
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
- H04L63/0823—Network architectures or network communication protocols for network security for authentication of entities using certificates
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q30/00—Commerce
- G06Q30/06—Buying, selling or leasing transactions
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
- H04L63/0884—Network architectures or network communication protocols for network security for authentication of entities by delegation of authentication, e.g. a proxy authenticates an entity to be authenticated on behalf of this entity vis-à-vis an authentication entity
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L2463/00—Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00
- H04L2463/102—Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00 applying security measure for e-commerce
Definitions
- the present invention relates to transaction security, particularly, although not exclusively, in electronic commerce.
- the vendor has the difficulty of receiving many requests from people unknown to him all of whom purport to have legitimate means for making payment.
- the approach adopted to resolve the problem has depended largely on the nature of the business relationship with the purchaser.
- the purchaser is a customer of a bank with which she wishes to carry out a transaction
- one approach has been to provide the purchaser with passwords in the form of shared secrets. Accordingly, such passwords need to be supplied before a transaction takes place.
- the provision of passwords before the transaction takes place is clearly not feasible where the transaction is between parties having no pre-existing or continuing relationship. In such case, the vendor may be forced simply to carry out off-line checks on the validity of credit cards and the like.
- a transaction security device for connection to a network including at least one terminal, the device comprising a server operable to validate data provided by a terminal over said connection in order to establish a secure session and a controller providing access to at least one application over said secure session, the device being operable to respond to a request from said terminal to access an application by obtaining at least part of said previously validated data from said server and forwarding said data to said controller, wherein access to an application is determined by said controller in accordance with said data.
- this merging of the security approach with a mechanism for selection of an application results in increased confidence for both parties to a transaction.
- the purchaser is no longer reliant merely on the assumption that the vendor is the party behind the session and the vendor has greater confidence in the identity of the purchaser and furthermore in the case of the pre-existing customer relationship, is able to dispense with the overheads and complexity involved in administering a separate security solution.
- a transaction security system comprising a server connected to a network including at least one terminal, the server being operable to validate data provided by a terminal over said connection in order to establish a secure session therewith, said server being further operable to respond to a request from said terminal for access to an application by providing at least part of said validated data to a controller, such that a determination on whether to permit access by said terminal is made by said controller in response to said validated data.
- the validation of the data by the server removes the requirement for the extensive data-entry required by application level security. This has the benefit of both reducing the amount of data-entry required from the user cutting down on log-in time and the possibility of error. It also removes a perceived barrier to the adoption of electronic commerce, namely that of complexity namely, if the user believes that too many steps are required to access a service, she will not use it.
- a transaction security method for a server connected to a network comprising the server acting on a request to establish a secure session over a network connection by validating data received in said request and, following establishment of said session, determining whether to allow a request to access an application by reference to at least part of said previously validated data.
- the data on which the application is selected will include details of URL and privileges which may pertain to a particular user or class of user as identified by the relevant certificate. The fact that this data may easily be modified enhances the value of the gateway to application owners.
- a trust server connectable to a gateway server controlling access to a remote server, the trust server comprising a validator, and data storage, wherein the validator is responsive to a first request from said gateway server to deliver status information relating to data received by said gateway server and to store said data in said storage such that said data is retrievable by said gateway server, said gateway server being operable to determine from said retrieved data and status information whether to allow a request to access said remote server.
- Figure 1 is a diagrammatic view of a transaction security system according to the present invention
- Figure 2a is a more detailed view of the system of Figure 1 with the intermediate infrastructure omitted for clarity;
- Figure 2b is a similar view to Figure 2b with elements of a gateway server omitted for clarity;
- Figure 3 is a signal diagram illustrating a method according to the present invention
- Figure 4 is a similar view illustrating further steps in the method of Figure 3;
- Figure 5 is a diagrammatic view of the system of Figure 1 in accordance with a further aspect of the invention
- Figure 6 is a similar view of the system of Figure 1 in accordance with a still further aspect of the invention.
- terminal 1 having a display 3 and a set of keys 5 including alphanumeric keys. Through these keys 5, a user is able, via a user interface, to operate the terminal 1.
- the terminal 1 forms a mobile element of a Public Land Mobile Network (PLMN) 7 the operation of which will be well known to those skilled in the art. It will noted that the PLMN 7 provides access to external networks including a Public Switched Telephone Network (PSTN) 9.
- PSTN Public Switched Telephone Network
- the terminal 1 provides its user U with access to the Internet 11 via a gateway server 13.
- the gateway server 13 may be operated by a service provider or perhaps a particular organisation such as a bank which for security reasons wishes to keep control over the gateway server 13.
- a pool of modems 15 connected to the PSTN 9 provides dial-up access from the terminal side to the gateway server 13.
- Other access routes may be employed depending on the capability of the terminal 1 and PLMN 7.
- an organisation such as a bank B allows transactions such as money transfers, share dealing and so on to be carried out electronically using a terminal 1 and an Internet 11 connection.
- Software through which the transactions are carried out is provided by various so-called back-end applications resident on an applications server 17.
- the applications server is located in premises of the bank B.
- access to a back-end application is provided via the gateway server 13.
- the gateway server 13 is located on the premises of the bank B although there is nothing to prevent locating the gateway server 13 anywhere there is access to the Internet 11.
- the gateway server 13 facilitates the exchange of information between the terminal 1 and a remote server connected to the Internet and/or intranet, in this case the bank's own back-end applications server 17.
- the gateway server 13 comprises a number of functional elements. Firstly, a transport layer block 19 with which the terminal 1 initially negotiates access; secondly, a session data store 21 ; thirdly, a request handler 23 and fourthly an http-connector 25. Furthermore, these elements have a number of external connections. Thus the transport layer block 19 and request handler 23 are connected 27, 29 to elements of a trust server 30. These elements include a signature validator 31 and a certificate validator 33. In addition to the external connections 27,29, with the gateway server 13, the trust server 30 has internal connections 35 between the two validators 31 ,33 and to a configuration store 37 and an external connection 39 between the trust server 30 and the Internet 11. This latter connection 39 permits the trust server 30 to determine the status of information presented to it by the gateway server 13.
- the http-connector 25 is also provided with an external connection 41 to the Internet 11. Through this connection 41 web servers including an application server 17 providing back- end applications may be reached.
- the terminal 1 together with the constituent elements of the gateway server 13 each makes use of the wireless Public Key Infrastructure (wPKI).
- the trust server 30 includes a local cache for both certificates and Certificate Revocation Lists (CRL) 43,45. Regular downloads of CRL are made to the cache from a public directory 47 connected to the Internet 11. The CRLs are signed by appropriate Certification Authority (CA).
- CA Certification Authority
- the terminal 1 Before the terminal 1 can be employed by the user in electronic transactions a number of processes are necessary to establish the security necessary to satisfy both the user and the organisation, in this case the bank B, with which she is carrying out her transactions.
- the terminal 1 is provided with a tamperproof smart card or token 49 which acts as a carrier for data used to substantiate the identity of the terminal user U.
- the terminal 1 acts as a conduit for the data stored on the token 49 which is used in securely accessing the relevant back-end application.
- the token 49 is manufactured by a card manufacturer which is then delivered to a service provider perhaps the operator of the PLMN, Following delivery, the service provider SP, in this case the operator of the PLMN 7, commences personalisation of the token 49 by generating and then storing two unique private/public key pairs on the token 49.
- the service provider root certificate, and URLs pointing to the service provider's SP certificates of the public keys are stored on the token 49.
- the URLs are formed using an identifier of the token 49 as key data. At this stage however, no certificates yet exist. Thus, the URLs on the card are void and therefore unusable.
- the user U completes personalisation during acquisition of the token 49.
- the user U personally identifies herself to an authorised employee of the service provider SP using a passport or the like.
- the employee confirms the completed strong identification of the user with his own digital signature, which is then stored by the service provider.
- the token 49 is then physically handed over to the user U who may now insert it into her terminal 1 for normal mobile telephony purposes.
- the service provider SP associates the identifier of the token 49 with the user's subscription.
- the service provider SP further requests its own Certification Authority (CA) to create certificates for the two public keys on the user's token.
- CA Certification Authority
- the CA generates the certificates, stores them on the private certificate Directory 47 of the service provider SP, and returns an OK response to the service provider SP.
- the service provider SP prints from its database the authentication objects or PINs for the two private keys on the token 49, and sends them through the post to the user U.
- the user U is now in a position to be able to register herself as a certified user of the organisation, in this case the bank B, with which she wishes to carry out electronic transactions.
- the user U firstly initiates a call 101 to the access number of a registration service.
- the terminal 1 physically connects to the dedicated gateway server 13 located in the bank's B premises and then attempts to set up a secure session between the terminal 1 and the gateway server 13.
- the transport layer block 19 of the gateway server 13 responds 103 by identifying itself with its server certificate and requesting the authentication of the User U.
- Information identifying the bank B is derived by the terminal 1 from the gateway server certificate and delivered 104 to the user U via the display 3.
- the Terminal 1 requests a response from the user U in the form of an authentication PIN1.
- the user U Using the keypad 5, the user U enters 105 her PIN1.
- Providing the correct PIN1 has been entered the terminal 1 then sends 106 a response to the transport layer block 19 containing the URL of the service provider's certificate of the authentication key, the response having been signed using the authentication key stored on user's token 49.
- the transport layer block 19 of the Gateway server 13 forwards the authentication response to request handler 23 which passes it to the certificate validator 33 of the Trust Server 30.
- the certificate validator 33 comprises time critical 51 and non-time critical 53 elements, the first of which, namely the time critical element 51 is activated on receipt of the forwarded authentication response.
- the validator 33 identifies the URL containing the service provider's certificate and contacts 108 a corresponding Directory 47 to check the validity of the service provider's certificate for the user U.
- the Directory 47 responds 109 to the Trust Server 30 with information about the certificate and its status such as its validity period. The outcome of the check is reported 110 to the transport layer block 19 of the trust server.
- a "session secured" message is sent 111 to the terminal 1 and a secure session is initiated 113, furthermore, the contents of the certificate are stored for the duration of the session in the secure session data store 21.
- the certificate validator 33 carries out the non-time critical element 53 and accesses the CRL cache 45 in an attempt to determine the revocation status of the certificate. If no certificate is present in the cache 45, a CRL fetch for the information from the CRL directory 47 is initiated. In either case, the revocation status of the certificate is obtained. If the CRL reveals that the certificate has been revoked, a message to this effect is displayed to inform the user U. The message may include details of the revoked certificate.
- the terminal 1 In the event that the certificate has been revoked, the session is terminated. However, should the certificate be in force then the terminal 1 can complete negotiation of the session in accordance with the selected protocol. This may include the generation of shared secrets such as would be understood by those skilled in the art. Whereupon, the terminal 1 is able to send 114 a user authentication request to the registration service of the organisation, in this case the bank B.
- the request is passed by the transport layer block 19 to the request handler 23 which retrieves the contents of the service provider's certificate from the data store 21 and includes them in a header attached to the request.
- the request, including its header, is then routed by the http-connector 25 via the Internet 11 to the bank registration service which is running on a backend server 17.
- the bank registration service recognises the request as being for registration of a user and extracts the certificate data from the request header.
- the bank registration service compares the certificate data and in particular the token identity with a customer record directory and seeks to make a match with a previously created record. In the event that no match is found a message to that effect is delivered to the terminal and the session is closed. However, if a match is made the bank registration service responds by sending 115 an acknowledgement text together with a request that the user U enters her non- repudiation PIN2 at the Terminal 1 to confirm her identity (see Figure 2b).
- the terminal 1 displays 116 the text and the user U duly enters 117 her non- repudiation PIN2 using the keypad 5 of the terminal 1. Assuming the PIN2 is correctly entered, the terminal 1 uses the private non-repudiation key on the token 49 to sign the response in the manner known to those skilled in the art of asymmetric cryptography.
- the response is sent 118 via the gateway server 13 (not shown) to the backend server 17 running the bank registration service.
- the bank registration service receives the response and forwards 119 it to the Trust Server 30 for the authentication of the signature by the signature validator 31.
- the signature validator checks the signature in the received message using the public certificate of the non-repudiation key in the manner well known to those skilled in the art of asymmetric cryptography.
- the trust server obtains the certificate by requesting 120 it from the Directory 47containing the non-repudiation public key.
- the Directory 47 provides 121 the trust server 30 with the certificate details and the trust server 30 returns 122 the results of its analysis of the signature to the bank registration service.
- the bank registration service requests 123 that the Trust Server 30 checks whether there already exist Bank certificates for the user's token 49.
- the Trust Server 30 interrogates 124 the Bank's certificate Directory 47 to determine whether there are certificates associated with the token 49.
- the token identifier contained in the header with the original registration request from the terminal 1 is thus used as the search term in this query.
- the directory 47 returns 125 its data to the trust server 30.
- the trust server 30 informs 126 the bank registration service that there were already certificates associated with the user's token 49 in the Bank's certificate Directory 47, the terminal is informed 127 and a corresponding message is displayed 128 by the terminal 1 and the user U is informed that the registration has already been done and the registration session is closed. Otherwise, the bank registration service requests an update 128 of the Customer record directory with the information that a token 49 holding the certificates of the Bank is a valid authentication method for the user U.
- the bank registration service causes an "authentication successful" message to be delivered to the terminal 1.
- the user is then able to read 131 a message generated 130 on the display 5 informing the user that registration was successful and that it will be completed after the Bank's certificates have been sent to the user's terminal 1.
- Delivery of the certificates may take place by any suitable method including over the air using a SMS route, by a push session either originated by the bank registration service or indeed whilst the registration session is still active.
- the user U is now in a position to be able to access the transactional facilities made available to her by the bank B, but using the bank's certificates to establish a secure session over the gateway server 13 to the backend transaction application of the bank B.
- the transaction application may, as a further security step, request that a transaction acknowledgement be signed by the User U using her non-repudiation PIN2 to cause the terminal 1 to sign the acknowledgement using the non-repudiation key which may then be checked by the trust server 1 as previously described above including checking the CRL to determine the revocation status of the certificate relating to the non- repudiation key.
- a gateway server 13 is required to provide access to a plurality of applications operated by different organisations ( Figure 6).
- the owner of the gateway server 13 could be an organisation such as a bank which could provide the facility to other organisations reluctant or enable to invest in establishing their own gateway.
- the server 13 is required to provide access not only to applications corresponding to those already described but also to so-called legacy applications.
- Such a legacy application may be incapable of extracting certificate information from the header of a request passed to it by the http-connector module 25.
- the gateway server 13 further includes an access control module 55 which interprets the received request from a terminal 1 and queries the session data store 21 which may also hold details of access rights and the like for the applications accessible from the gateway 13.
- the access rights are stored permanently outside of the session data store 21. This information may be pre-stored, or could be created dynamically following a failure to communicate certificate information to an application in the manner previously described.
- the access control module 55 which establishes firstly whether authorisation of the user is required as might be the case for the abovementioned legacy applications. If not, the access control module then passes to the next stage of identifying the access rights including the URLs necessary to access the application on the back-end server 17. As previously described, the request handler then places the certificate information together with any information intended to be included from the data store in a header to the request. The subsequent processing of the request then follows the steps previously described including the CRL check and the optional non-repudiation step.
- the access module 55 optionally initiates an authorisation step. Whether such a step is required is determined by the access control module 55 which has access to the data store 21 and the particular records for that application.
- the records may include, in the form of a profile, how the owner of an application wishes particular requests to be handled.
- a request is sent to the terminal 1 which displays a message asking the user to enter her non- repudiation PIN2.
- the terminal 1 signs the response using the non-repudiation private key and sends the response to the gateway server 13 where it is intercepted by the access control module 55.
- the access control module 55 asks the request handler 23 to contact the trust server 30 whose signature validator 31 validates the signature against the relevant certificate. Assuming the signature is validated then the access control module 55 allows the original request from the terminal to be passed to the http-connector 25 and thus to the back-end server 17' on which the legacy application is resident, but not before the certificate has been checked against the CRL cache as described above.
Abstract
Description
Claims
Priority Applications (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
AU2001242359A AU2001242359A1 (en) | 2000-11-24 | 2001-01-31 | Improvement in electronical transaction security |
EP01915179A EP1346539A1 (en) | 2000-11-24 | 2001-01-31 | Improvement in electronical transaction security |
US10/442,321 US20030236985A1 (en) | 2000-11-24 | 2003-05-20 | Transaction security in electronic commerce |
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
GB0028730A GB0028730D0 (en) | 2000-11-24 | 2000-11-24 | Improvement in and relating to transaction security |
GB0028730.0 | 2000-11-24 |
Related Child Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US10/442,321 Continuation US20030236985A1 (en) | 2000-11-24 | 2003-05-20 | Transaction security in electronic commerce |
Publications (1)
Publication Number | Publication Date |
---|---|
WO2002043345A1 true WO2002043345A1 (en) | 2002-05-30 |
Family
ID=9903840
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
PCT/EP2001/000983 WO2002043345A1 (en) | 2000-11-24 | 2001-01-31 | Improvement in electronical transaction security |
Country Status (4)
Country | Link |
---|---|
EP (1) | EP1346539A1 (en) |
AU (1) | AU2001242359A1 (en) |
GB (1) | GB0028730D0 (en) |
WO (1) | WO2002043345A1 (en) |
Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5903721A (en) * | 1997-03-13 | 1999-05-11 | cha|Technologies Services, Inc. | Method and system for secure online transaction processing |
WO2000002406A2 (en) * | 1998-07-07 | 2000-01-13 | Nokia Networks Oy | System and method for authentication in a mobile communications system |
WO2000002358A1 (en) * | 1998-07-03 | 2000-01-13 | Nokia Mobile Phones Limited | Secure session set up based on the wireless application protocol |
WO2000059225A1 (en) * | 1999-03-26 | 2000-10-05 | Motorola Inc. | Secure wireless electronic-commerce system with wireless network domain |
US6151628A (en) * | 1997-07-03 | 2000-11-21 | 3Com Corporation | Network access methods, including direct wireless to internet access |
-
2000
- 2000-11-24 GB GB0028730A patent/GB0028730D0/en not_active Ceased
-
2001
- 2001-01-31 EP EP01915179A patent/EP1346539A1/en not_active Withdrawn
- 2001-01-31 WO PCT/EP2001/000983 patent/WO2002043345A1/en not_active Application Discontinuation
- 2001-01-31 AU AU2001242359A patent/AU2001242359A1/en not_active Abandoned
Patent Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5903721A (en) * | 1997-03-13 | 1999-05-11 | cha|Technologies Services, Inc. | Method and system for secure online transaction processing |
US6151628A (en) * | 1997-07-03 | 2000-11-21 | 3Com Corporation | Network access methods, including direct wireless to internet access |
WO2000002358A1 (en) * | 1998-07-03 | 2000-01-13 | Nokia Mobile Phones Limited | Secure session set up based on the wireless application protocol |
WO2000002406A2 (en) * | 1998-07-07 | 2000-01-13 | Nokia Networks Oy | System and method for authentication in a mobile communications system |
WO2000059225A1 (en) * | 1999-03-26 | 2000-10-05 | Motorola Inc. | Secure wireless electronic-commerce system with wireless network domain |
Also Published As
Publication number | Publication date |
---|---|
AU2001242359A1 (en) | 2002-06-03 |
EP1346539A1 (en) | 2003-09-24 |
GB0028730D0 (en) | 2001-01-10 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US20030236985A1 (en) | Transaction security in electronic commerce | |
EP1212732B1 (en) | Methods and apparatus for conducting electronic transactions | |
US20180114206A1 (en) | Methods and apparatus for conducting electronic transactions | |
US5649118A (en) | Smart card with multiple charge accounts and product item tables designating the account to debit | |
US20020073046A1 (en) | System and method for secure network purchasing | |
JP2011123902A (en) | Method of and system for authorizing purchase made over computer network | |
KR100822985B1 (en) | System for Processing Payment by Using Nickname | |
JP2001331646A (en) | System and method for financial transaction using fingerprint matching | |
WO2002043346A1 (en) | Method, device and system relating to transaction security | |
EP1346539A1 (en) | Improvement in electronical transaction security | |
KR100822939B1 (en) | System and Method for Providing Unfaced Channel User Interface by Using Nickname and Recording Medium | |
EP1340130A1 (en) | Improvement in and relating to transaction security | |
KR20080022826A (en) | System and method for providing security information by non faced channel and program recording medium | |
AU2004231226B2 (en) | Methods and apparatus for conducting electronic transactions | |
KR20080023230A (en) | Method for account information classified by non-faced channel | |
KR100963921B1 (en) | System and Method for Providing Information of Loan Approval Customer and Program Recording Medium | |
KR20080022825A (en) | System and method for providing non-faced channel initial display and program recording medium | |
WO2001016828A1 (en) | System and method for conducting financial transactions on an internet enabled electronic funds transfer device | |
KR20090009364A (en) | System and method for integrated payment of trade transaction service and program recording medium | |
KR20050019670A (en) | Method For Safely Drawing from Bank Using Mobile Terminal | |
KR20090019030A (en) | System and method for managing direct planning model intranet of enterprise officer and staff and program recording medium | |
KR20080031716A (en) | Method for providing security information by non faced channel |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AK | Designated states |
Kind code of ref document: A1 Designated state(s): AE AG AL AM AT AT AU AZ BA BB BG BR BY BZ CA CH CN CR CU CZ CZ DE DE DK DK DM DZ EE EE ES FI 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 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: A1 Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG 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 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: 2001915179 Country of ref document: EP |
|
WWP | Wipo information: published in national office |
Ref document number: 2001915179 Country of ref document: EP |
|
REG | Reference to national code |
Ref country code: DE Ref legal event code: 8642 |
|
NENP | Non-entry into the national phase |
Ref country code: JP |
|
WWW | Wipo information: withdrawn in national office |
Ref document number: 2001915179 Country of ref document: EP |