WO1999007104A1 - Securite des donnees dans un systeme de communication multipoints editeur/abonne - Google Patents

Securite des donnees dans un systeme de communication multipoints editeur/abonne Download PDF

Info

Publication number
WO1999007104A1
WO1999007104A1 PCT/US1998/016365 US9816365W WO9907104A1 WO 1999007104 A1 WO1999007104 A1 WO 1999007104A1 US 9816365 W US9816365 W US 9816365W WO 9907104 A1 WO9907104 A1 WO 9907104A1
Authority
WO
WIPO (PCT)
Prior art keywords
subscriber
publisher
message
key
article
Prior art date
Application number
PCT/US1998/016365
Other languages
English (en)
Other versions
WO1999007104B1 (fr
Inventor
Russell E. Selph
Dennis R. Page
Original Assignee
Tibco Software, Inc.
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 Tibco Software, Inc. filed Critical Tibco Software, Inc.
Priority to EP98940794A priority Critical patent/EP0998801A1/fr
Priority to AU88986/98A priority patent/AU8898698A/en
Priority to CA002299505A priority patent/CA2299505A1/fr
Priority to JP2000505708A priority patent/JP2001512923A/ja
Publication of WO1999007104A1 publication Critical patent/WO1999007104A1/fr
Publication of WO1999007104B1 publication Critical patent/WO1999007104B1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0838—Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these
    • H04L9/0841—Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these involving Diffie-Hellman or related key agreement protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures

Definitions

  • This invention relates to multipoint publish/subscribe communications and, more particularly, to secure encrypted communications between computer-based publisher and subscriber applications in a publish/subscribe communications system.
  • a publisher application publishes information to requesting or subscriber applications without having any knowledge of the number, identity or address of any such subscriber applications. In fact, no subscriber applications may exist. Instead of knowing about subscribers, a publisher will merely publish information applying a context or subject "label" to the published message. A subscriber then identifies desired messages by the content label and receives only those messages relevant to the desired content.
  • Publish/subscribe interactions are event-driven rather than demand-driven.
  • producers also called publishers
  • Publish/subscribe interactions are driven by events (usually the arrival or creation of data) in a producer. Consumers place a standing request for data by subscribing, but publishing events are independent of subscriptions. Communication is in one direction only, and is often one-to-many.
  • Example applications include:
  • Securities data feed handlers publish the latest stock prices to hundreds of traders on a trading floor simultaneously; Materials movement systems distribute data to various materials handlers, controllers and tracking systems on a factory floor;
  • a publish/subscribe interaction consists of only one broadcast message.
  • a subscription is an implicit request for messages.
  • producers are decoupled from consumers-they do not coordinate data transmission with each other.
  • Producers publish data to the network at large. Consumers can receive messages with any subject names. Any application can be both a producer and a consumer.
  • Event-driven paradigm is a natural and efficient style of computing for many applications, including data warehousing, Internet mirrors, incremental schedulers, just-in-time inventory management, real-time decision support, and data monitoring applications.
  • Event-driven computing is emerging as a dominant paradigm for many business applications.
  • this invention provides for secure/encrypted messaging that is applicable to point-to-point as well as other environments such as anonymous content-based, publish/subscribe, broadcast and bulletin board environments.
  • our invention is a method of and a program product for publishing encrypted data in a publish/subscribe communications system having a publisher and at least one subscriber (and preferably more).
  • the method includes the steps of initiating a key exchange between the subscriber and the publisher, publishing encrypted data to a subscriber; and thereafter decrypting the published data.
  • the subscriber cannot read it, so the unread, encrypted message is sent to a subscriber-side encrypting/decrypting responder associated with the subscriber.
  • the subscriber responder realizes that the message is encrypted and, using the publisher responder address attached to the encrypted message, sends a message to the publisher-side responder.
  • a subscriber receives it's first message from a given publisher, it will attempt to decrypt it, but will get a "not enough info" error. In response to this error, the subscriber will initiate a key exchange with the responder specified in the message.
  • the subscriber will be able to decrypt incoming data from the publisher, and can optionally now decrypt the original message that initiated the exchange. Once a key exchange has taken place, all subsequent messages from the publisher can be decrypted as they are received.
  • our invention can be used for authentication only.
  • authentication only When used only to authenticate messages, and not to encrypt them, many parts of the protocol are simplified. For instance, a full key-exchange requires two complete turn-arounds on the network (four messages).
  • authenticating a message only it may only be required to get a certificate from the sender. This is accomplished in one turnaround (two messages).
  • a publisher decides to publish its certificate along with the data stream, then subscribers can verify the identity of the sender without any interactions at all.
  • the encrypted message can be sent along non-data communication paths, using instead a more secure path.
  • the subscriber responder acknowledges receipt of the originally encrypted message and starts the process of confirmed and verified message exchanges using and receiving/checking a series of digital signatures. This process leads to the subscriber receiving the key to decipher the originally encrypted message and, in most cases, subsequent messages from the same publisher.
  • This inventive process has a number of advantages. It provides secure communications in multipoint environments by allowing communicating applications to authenticate messages by creating and checking digital signatures. It does this through two major functions:
  • a further advantage is that either or both endpoints can be anonymous ⁇ an endpoint that does not have a private key corresponding to a certificate is considered anonymous ⁇ although for maximum security this may not be appropriate.
  • Yet another advantage is that the invention imposes very little policy as to the actual encryption and signing algorithms used, or the key lengths employed. Thus algorithms can be added without changing any of the message formats.
  • SSL Secure Socket Layer protocol originally proposed by Netscape.
  • SSL implements the semantics of a TCP socket, with two endpoints and a continuous byte stream of data
  • this invention allows publish/subscribe semantics to be implemented, with many endpoints and discrete messages.
  • Figure 1 is a schematic representation of a typical publish subscribe environment illustrating the messages flow in the protocol of the invention.
  • Asymmetric Encryption involves the use of two keys, one public and one private.
  • the public key is derived from the private key, and can be distributed to anyone. Data encrypted with the public key can only be decrypted with the private key, and vice versa. This is especially useful for applications like secure e-mail: a message is encrypted with the recipients public key, and no one (except the owner of the private key) can decrypt it.
  • Digital signatures are a special application of asymmetric encryption.
  • a hash or 'fingerprint' of the message is calculated using a one-way hash function.
  • the signer then encrypts this hash with a private key.
  • This encrypted hash value is the signature. Any one can verify the signature by decrypting the signature with the signer's public key, and comparing it with a hash of the message that they calculated themselves.
  • Certificates provide a reasonably secure mechanism for verifying identity in a distributed and scaleable way.
  • a Certificate Authority signs copies of everyone's public keys, and makes these signed keys publicly available.
  • the CA also makes available a copy of its own public key. Client programs need only keep a copy of the CA's public key in order to verify any certificate they receive.
  • MACs Message Authentication Codes
  • MACs Message Authentication Codes
  • One-way Hash Functions A one-way hash function is much like a check-sum. The difference is that it is very difficult to 'invent' two messages that hash to the same value.
  • Symmetric Encryption is the most basic form of encryption.
  • a secret key is used to obscure data in such a way that it cannot be recovered without knowing the secret key.
  • This form of encryption is generally faster to perform on a large block of data than asymmetric encryption.
  • FIG 1 a publisher application 10 and a plurality of subscriber applications 20, 20' and 20" are shown.
  • the publisher and subscriber(s) are software applications based on one or more computers interconnected by a network providing a data path among the applications.
  • the publisher 10 and subscriber(s) 20 preferably implement a content-based communications protocol whereby a publisher publishes a message indicating only the content of the message and without knowing the identity or protocols used by the subscriber(s) 20.
  • These inter-application communications are established by communications daemons not shown in Fig. 1, but are well known in the art and described in many publications including the patents referred to above.
  • Each responder 12, 22 is a single encrypting or decrypting entity. Each responder also is responsible for keeping one key for data encryption and one key for signature creation.
  • Responders can have a definite identity, or they can be anonymous. In order to have an identity, the responder must have both a certificate, and the private key corresponding to that certificate's public key. In contrast, anonymous responders are useful for situations in which it is impractical for the endpoint code to obtain a private key without revealing it to adversaries.
  • the responders 12, 22 send messages to each other in order to accomplish key exchanges. These messages are encrypted using keys established via the Diffie-Hellman key exchange protocol.
  • the Diffie-Hellman key exchange protocol is described by Schneier, above. As described by Schneier, Diffie-Hellman gets its security from the difficulty of calculating discrete logarithms in a finite field, as compared with the ease of calculating exponentiation in the same field. Diffie-Hellman can be used for key distribution — For example, A and B can use this algorithm to generate a secret key — but it cannot be used to encrypt and decrypt messages.
  • Both k and k' are equal to g 3 ' mod n. No one listening on the channel can compute that value; they only know n, g, X, and Y. Unless they can compute the discrete logarithm and recover x or , they do not solve the problem. So, k is the secret key that both A and B computed independently.
  • a publisher 10 has great flexibility to assign responders to published subjects.
  • a single responder can be used for all messages published by the publisher 10, or a responder can be created for each subject published.
  • partitioning of security is determined by the mapping of responders to subjects. The best choice will vary according to the security needs of the publisher 10.
  • the encrypted message is then published (shown schematically as 30) on the normal data communications channel of the network.
  • the message will take the form of subj,resp [xxxxxj in which subj indicates the content/subject of the message; resp indicates the encrypting respondent 12 address; and [xxxxxj is the now-unreadable, encrypted message.
  • the encrypted message 30 would include the responder 12's Diffie-Hellman half- value DH-x and generically include information of the form E ⁇ ⁇ M, MIC ⁇ in which
  • E K is an encryption key
  • MIC is a message internal code typically including a hash function as follows:
  • This hash function will include a "signature" if authentication is required. Thus all hash functions are signed in authenticated communications.
  • Each subscriber 20, 20', 20" listens for and accesses messages based on the message its content/subject in the normal way. When the message is received, however, it is unreadable and is therefore passed to the appropriate subscriber-side responder 22.
  • the subscriber-side responder 22 then responds by communicating with the publisher- side responder 12 by way of a MAC-based message 32 to the address (resp) identified in the original message 30.
  • This message 32 is the start of a message decrypt function and typically takes the format:
  • SMAC sub_ resp; DH-y; E KE fri; signature Jnfo ⁇
  • sub resp is the subscriber-side responder 22's address
  • DH-y is responder 22's Diffie-Hellman half- value
  • rj is a first random number
  • signature Jnfo is a request for signature information/signed message.
  • the publisher side responder 12 responds with a fully signed message 36 of the form: SFULL (pub resp; EKE ⁇ 2,' r;; signature; signature Jnfo ⁇ ) in which pub_resp is the publisher-side responder 12's address; r / is an echo of the first random number; r 2 is a second random number; signature is responder 12's signature; and signature Jnfo is a request for signature information/a signed message from responder 22.
  • the subscriber-side responder 22 When the subscriber-side responder 22 receives this message 36, it calls back to the subscriber 20 (shown by arrow 38) to get the subscriber 20's approval. Once this approval is received, the responder 22 calls back to responder 12 with a fully signed message 40 of the form:
  • sub_resp is the subscriber-side responder 22's address
  • r 2 is an echo of the second random number
  • r 3 is a third random number
  • signature is responder 22's signature
  • key request is a request for the key to decipher the encrypted message and it could include a data payload from the subscriber.
  • the publisher-side responder 12 When the publisher-side responder 12 receives this message 40, it responds to the publisher 10 (shown by arrow 42) to get publisher 10 approval to transmit the key. Once this approval is received, the responder 12 calls back to responder 22 with MAC message 44 incorporating the encryption key as follows:
  • a challenge value that is, a random number
  • a responder 12 For all these communications when a challenge value, that is, a random number, it must be returned with additional information and a signature before the identity of the remote end is trusted. It is for similar reasons that the random numbers are echoed except that challenge values require signatures (at a minimum) in response while random number echoes are not always accompanied by signatures. Thus, only when identity of both parties has been established securely, a key request can be sent.
  • responders 12 and 22 communicate with each other to accomplish key exchanges.
  • the Diffie-Hellman protocol is used to establish a secure channel between the responders for the duration of the negotiation.
  • the actual protocol used is similar to the station-to-station protocol which is based on Diffie-Hellman. In most cases the entire exchange, including the transmission of key values, is accomplished in two turn-arounds (a total of four messages).
  • the default behavior is to supply the most current key value.
  • responders may cache old key values, and if asked for the key corresponding to a message with an old sequence number, will send the older key value.
  • the protocol of the invention allows the publisher to choose algorithms for both encrypting and signing data and a algorithms can be "plugged in” to any API incorporating this invention.
  • the choice of algorithm is usually a trade-off between efficiency and security.
  • a publisher can use any symmetric algorithm. Furthermore, many algorithms exist, offering varying key lengths and encryption speeds. For signing, the publisher must choose between an asymmetric algorithm, such as RSA or El-Gamal encryption, or using a MAC for authentication. The most secure choice is to use an asymmetric algorithm, with a certified copy of the public key. This allows recipients of the message to definitely verify the origin of the message.
  • all messages contain a sequence number in order to prevent replay attacks. If a message is received with an old sequence number it is flagged to the application as a potential replay. This is to prevent adversaries from grabbing whole, encrypted packets from the network and simply 'replaying' them at a later time.
  • a subscriber when a subscriber receives it's first message from a given publisher, it will attempt to decrypt it, but will get a "not enough info" error. In response to this error, the subscriber will initiate a key exchange with the responder specified in the message. Once the key exchange is complete, the subscriber will be able to decrypt incoming data from the publisher, and can optionally now decrypt the original message that initiated the exchange. Once a key exchange has taken place, all subsequent messages from the publisher can be decrypted as they are received.
  • This invention does, however, have broader implementation.
  • the request is usually published to a broadcast subject, and the reply information is returned to the publisher.
  • the servers are acting as subscribers in the previous scenario.
  • the first time a message is received from a given client the server must initiate a key exchange with that client. Once the key exchange is complete, the server can process the client message.
  • this invention can be used for authentication only.
  • a full key-exchange requires two complete turn-arounds on the network (four messages).
  • authenticating a message only it may only be required to get a certificate from the sender. This is accomplished in one turnaround (two messages).
  • a publisher decides to publish its certificate along with the data stream, then subscribers can verify the identity of the sender without any interactions at all.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer And Data Communications (AREA)
  • Storage Device Security (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Telephonic Communication Services (AREA)

Abstract

Procédé et programme présentant une grande utilité dans un système de communication édition/abonnement (30) comme, par exemple, un système comportant un éditeur (10) et au moins un abonné (20). Dans le procédé et le programme selon l'invention, les données codées sont éditées pour un ou plusieurs abonnés (20', 20''). L'abonné essaie en vain de décoder les données. Le procédé et le programme initialisent alors un échange de codes entre l'abonné (20', 20'') et l'éditeur (10), ce qui se traduit par une transmission de code, puis un décodage des données publiées.
PCT/US1998/016365 1997-08-04 1998-08-04 Securite des donnees dans un systeme de communication multipoints editeur/abonne WO1999007104A1 (fr)

Priority Applications (4)

Application Number Priority Date Filing Date Title
EP98940794A EP0998801A1 (fr) 1997-08-04 1998-08-04 Securite des donnees dans un systeme de communication multipoints editeur/abonne
AU88986/98A AU8898698A (en) 1997-08-04 1998-08-04 Data security in multipoint publish/subscribe communications
CA002299505A CA2299505A1 (fr) 1997-08-04 1998-08-04 Securite des donnees dans un systeme de communication multipoints editeur/abonne
JP2000505708A JP2001512923A (ja) 1997-08-04 1998-08-04 マルチポイント発行／申込通信におけるデータセキュリティ

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US5463697P 1997-08-04 1997-08-04
US60/054,636 1997-08-04

Publications (2)

Publication Number Publication Date
WO1999007104A1 true WO1999007104A1 (fr) 1999-02-11
WO1999007104B1 WO1999007104B1 (fr) 1999-04-15

Family

ID=21992475

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US1998/016365 WO1999007104A1 (fr) 1997-08-04 1998-08-04 Securite des donnees dans un systeme de communication multipoints editeur/abonne

Country Status (5)

Country Link
EP (1) EP0998801A1 (fr)
JP (1) JP2001512923A (fr)
AU (1) AU8898698A (fr)
CA (1) CA2299505A1 (fr)
WO (1) WO1999007104A1 (fr)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7895359B2 (en) 2003-05-01 2011-02-22 Goldman Sachs & Co. System and method for message processing and routing
US8787578B2 (en) 1999-09-30 2014-07-22 Qualcomm Incorporated Method and apparatus for encrypting transmissions in a communication system
CN110740150A (zh) * 2018-07-20 2020-01-31 阿里巴巴集团控股有限公司 消息交互方法及装置

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5539828A (en) * 1994-05-31 1996-07-23 Intel Corporation Apparatus and method for providing secured communications
US5677953A (en) * 1993-09-14 1997-10-14 Spyrus, Inc. System and method for access control for portable data storage media

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5677953A (en) * 1993-09-14 1997-10-14 Spyrus, Inc. System and method for access control for portable data storage media
US5539828A (en) * 1994-05-31 1996-07-23 Intel Corporation Apparatus and method for providing secured communications

Cited By (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8787578B2 (en) 1999-09-30 2014-07-22 Qualcomm Incorporated Method and apparatus for encrypting transmissions in a communication system
US7895359B2 (en) 2003-05-01 2011-02-22 Goldman Sachs & Co. System and method for message processing and routing
US7899931B2 (en) 2003-05-01 2011-03-01 Goldman Sachs & Co. System and method for message processing and routing
US8028087B2 (en) 2003-05-01 2011-09-27 Goldman Sachs & Co. System and method for message processing and routing
US8250162B2 (en) 2003-05-01 2012-08-21 Goldman, Sachs & Co. System and method for message processing and routing
US8255471B2 (en) 2003-05-01 2012-08-28 Goldman, Sachs & Co. System and method for message processing and routing
US8266229B2 (en) 2003-05-01 2012-09-11 Goldman, Sachs & Co. System and method for message processing and routing
US8458275B2 (en) 2003-05-01 2013-06-04 Goldman, Sachs & Co. System and method for message processing and routing
US8521906B2 (en) 2003-05-01 2013-08-27 Goldman, Sachs & Co. System and method for message processing and routing
US8775667B2 (en) 2003-05-01 2014-07-08 Goldman, Sachs & Co. System and method for message processing and routing
US9258351B2 (en) 2003-05-01 2016-02-09 Goldman, Sachs & Co. System and method for message processing and routing
CN110740150A (zh) * 2018-07-20 2020-01-31 阿里巴巴集团控股有限公司 消息交互方法及装置

Also Published As

Publication number Publication date
EP0998801A1 (fr) 2000-05-10
JP2001512923A (ja) 2001-08-28
WO1999007104B1 (fr) 1999-04-15
CA2299505A1 (fr) 1999-02-11
AU8898698A (en) 1999-02-22

Similar Documents

Publication Publication Date Title
US7181014B1 (en) Processing method for key exchange among broadcast or multicast groups that provides a more efficient substitute for Diffie-Hellman key exchange
EP1043864B1 (fr) Système et procédé de distribution de documents
EP1348152B1 (fr) Procede et appareil pour la gestion de transactions collaboratives protegees
US6987855B1 (en) Operational optimization of a shared secret Diffie-Hellman key exchange among broadcast or multicast groups
US6941457B1 (en) Establishing a new shared secret key over a broadcast channel for a multicast group based on an old shared secret key
AU2003202511B2 (en) Methods for authenticating potential members invited to join a group
US7149894B2 (en) Public-key certificate issuance request processing system and public-key certificate issuance request processing method
US6937726B1 (en) System and method for protecting data files by periodically refreshing a decryption key
US7346171B2 (en) Network system, terminal, and method for encryption and decryption
US6859533B1 (en) System and method for transferring the right to decode messages in a symmetric encoding scheme
US20020087862A1 (en) Trusted intermediary
Omote et al. A practical English auction with one-time registration
WO1995027355A1 (fr) Elements de preuve electroniques de reception
GB2419262A (en) Authentication Method and System
US20020106085A1 (en) Security breach management
Cui et al. Anonymous message authentication scheme for semitrusted edge-enabled IIoT
CN109905229B (zh) 基于群组非对称密钥池的抗量子计算Elgamal加解密方法和系统
EP1113617A2 (fr) Procédé et dispositif de transfert du droit de déchiffrer des messages
US7286665B1 (en) System and method for transferring the right to decode messages
AU2003304111A1 (en) Digital signature and verification system for conversational messages
Khurana et al. Sels: a secure e-mail list service
EP0998801A1 (fr) Securite des donnees dans un systeme de communication multipoints editeur/abonne
Saxena et al. A Lightweight and Efficient Scheme for e-Health Care System using Blockchain Technology
EP1130843B1 (fr) Système et procedé de transfer de droit de dechiffrer des messages dans un schema de décodage symmetrique
Chen et al. Building a privacy-preserving blockchain-based bidding system: A crypto approach

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

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

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): GH GM KE LS MW SD SZ 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 BF BJ CF CG CI CM GA GN GW ML MR NE SN TD TG

AK Designated states

Kind code of ref document: B1

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

AL Designated countries for regional patents

Kind code of ref document: B1

Designated state(s): GH GM KE LS MW SD SZ 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 BF BJ CF CG CI CM GA GN GW ML MR NE SN TD TG

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

Ref document number: 2299505

Country of ref document: CA

Ref country code: CA

Ref document number: 2299505

Kind code of ref document: A

Format of ref document f/p: F

NENP Non-entry into the national phase

Ref country code: KR

WWE Wipo information: entry into national phase

Ref document number: 1998940794

Country of ref document: EP

WWP Wipo information: published in national office

Ref document number: 1998940794

Country of ref document: EP

REG Reference to national code

Ref country code: DE

Ref legal event code: 8642

WWW Wipo information: withdrawn in national office

Ref document number: 1998940794

Country of ref document: EP