[go: up one dir, main page]

WO2002008865A2 - Systeme de monnaie electronique a pieces transparentes - Google Patents

Systeme de monnaie electronique a pieces transparentes Download PDF

Info

Publication number
WO2002008865A2
WO2002008865A2 PCT/US2001/023264 US0123264W WO0208865A2 WO 2002008865 A2 WO2002008865 A2 WO 2002008865A2 US 0123264 W US0123264 W US 0123264W WO 0208865 A2 WO0208865 A2 WO 0208865A2
Authority
WO
WIPO (PCT)
Prior art keywords
value
party
transacting
issuer
parties
Prior art date
Application number
PCT/US2001/023264
Other languages
English (en)
Other versions
WO2002008865A3 (fr
Inventor
David Chaum
Original Assignee
David Chaum
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 David Chaum filed Critical David Chaum
Priority to AU2001280735A priority Critical patent/AU2001280735A1/en
Publication of WO2002008865A2 publication Critical patent/WO2002008865A2/fr
Publication of WO2002008865A3 publication Critical patent/WO2002008865A3/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/04—Payment circuits
    • G06Q20/06—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3825—Use of electronic signatures

Definitions

  • the present invention relates generally to digital transactions, and more specifically to secure and/or privacy protecting techniques for exchange of value.
  • a second example is the hierarchical schemes of Okamoto and Ohta, such as those described in US Patent 5,224,162, titled 7 "Electronic cash system” and issued 6/29/93. Although they improve the ability to spend all cash held, this is achieved only by using impressive and so far impractical cryptography as well providing various new sources of linking information, not all of which are believed readily addressed. Additionally, various so-called “tick” payment systems have been proposed (and re-proposed) for limited applications typically including only small amount payments, though they do not claim to practically address the general case of arbitrary amounts of payment.
  • a fundamental problem introduced by many of the above mentioned systems is their facilitation of, and inability to limit, so-called “payee anonymity". This has been argued elsewhere to allow criminal use of payments without payer accountability. The ability to restrict payee anonymity can be expected to be a legislated requirement for such systems that come into widespread use.
  • the present invention aims to overcome these problems and limitations of the prior art and has among its obj'ects the following: • Providing complete fungibility, thereby neither requiring payers to hold extra value nor preventing them from making payments for which they hold sufficient value;
  • Fig. la shows a combined block, functional, and flow diagram of interactions between a pair of parties for an exemplary embodiment in accordance with the teachings of the present invention.
  • Fig. lb shows a combined block, functional, and flow diagram of interactions between a triple of parties for an exemplary embodiment in accordance with the teachings of the present invention.
  • Fig. 2 shows a combined block, functional, flow, and cryptographic-protocol diagram of interactions between a payer and a bank for an exemplary embodiment of a "maybemerge" transaction in accordance with the teachings of the present invention.
  • Fig. 3 shows a combined block, functional, flow, and cryptographic-protocol diagram of interactions between a payer and a bank for an exemplary embodiment of a "maybesplit" transaction in accordance with the teachings of the present invention.
  • Fig. lb shows a combined block, functional, and flow diagram of interactions between a triple of parties for an exemplary embodiment in accordance with the teachings of the present invention.
  • Fig. 2 shows a combined block, functional, flow, and cryptographic-protocol diagram of interactions between a payer and a bank for an exemplary embodiment of a "maybemerge"
  • FIG. 4 shows a combined block, functional, flow, and cryptographic-protocol diagram of interactions between a payer and a bank for an exemplary embodiment of a general merge and/or split transaction in accordance with the teachings of the present invention.
  • Fig. 5 shows a combined block, functional, flow, and cryptographic-protocol diagram of interactions between a payer and a bank for an exemplary embodiment of a preparatory transaction in accordance with the teachings of the present invention.
  • Fig. 6 shows a combined block, functional, flow, and cryptographic-protocol diagram of interactions between a payer and a bank for an exemplary embodiment in a "maybesplit" transaction, related to a preparatory transaction, in accordance with the teachings of the present invention.
  • two underlying innovative example transactions are the "maybemerge” and "maybesplit."
  • the Maybemerge interaction either has no effect or it cancels the validity of two coins of the same denomination and validates a new coin with double that denomination. Only the payer can know whether it changes nothing or is actually a merge yielding a new coin in exchange for two. In either case, the total value remains the same.
  • a maybesplit is either a "no-op" or changes a single coin of one value into two, each of half the value of the split coin — without the bank learning whether it resulted in a split or was merely a dummy.
  • a transaction can accomplish one of plural potential transformations between sets of coins having equivalent aggregate value without the bank learning which transformation(s) occurred.
  • the bank can prevent so-called “payee anonymity" by ensuring that all coins involved in an actual transformation are related to the same payer.
  • An exemplary illustrative way to realize a maybemerge is as follows: The user provides two unauthenticated digital coins to the bank along with a blinded coin. If the maybemerge is to have no effect, then the payer can simply create all these values at random; in the other case, however, where an actual merge is wanted, the values provided are genuine and the user knows the authenticated form of the two coins revealed and is prepared to remove the blinding on the third number. What the bank does is first make sure that the coins have not been, and cannot later be, spent. When this is successfully done, the bank signs or otherwise authenticates the blinded number, but "combines" it with the authenticator values for the two coins.
  • This combining preferably resists various attacks, such as the user being able to learn authenticators for any coin, except when the authenticators are known for both merged coins, and then only for the one new coin.
  • an exemplary combining technique would apply independent one-way functions to the authenticators to be merged before multiplying them (in a homomorphic signature scheme) with the authenticator value to result from the merger.
  • An exemplary maybesplit can work similarly, although it can typically be expected to be conducted while, for instance, cryptographically tunneling through a payee to a bank.
  • An unauthenticated coin and two blinded coins are supplied to the bank. Much as with a maybemerge, the bank cancels the coin to be split and returns appropriate signatures on the two blinded coins, each combined preferably independently with the authenticator of the unauthenticated coin values supplied.
  • One example way to use these primitives allows the user to conveniently maintain the coins held in a single "canonical" form and conduct withdrawal and payment transactions each in a uniform way.
  • a binary denomination scheme where each denomination is worth twice that of the next lower denomination, at most one coin of each denomination is held in the canonical form.
  • the two coins can be merged.
  • a sequence of merges from the smallest to largest denomination suffices to integrate a withdrawal amount that is itself in canonical form.
  • certain denominations are needed, they can be formed by splitting the next larger denomination that is held.
  • the bank can require that any blinded coins used have been committed to previously because the have been previously supplied, such as by looking them up or requiring the user to supply an authenticated receipt. But when the user is preferably not identified to the bank, such as is preferable when the transaction tunnels through a payee, such a technique ⁇ is not applicable.
  • the bank supplies for each of the two singles an authenticator that can 2 be opened only when a special authenticator is known for the double.
  • the bank supplies the special authenticator on the unblinded double cancelled as well as partial authenticators on the blinded singles. These partials can only be opened using the authenticator for the double and they provide the missing complementary part giving the singles s the combined authenticators of the appropriate value.
  • issuer of value transacting party, and receiver of value
  • setup relates generally to any data or derivative/precursor or related data that is pre-existing at a time after it has been established. 7
  • coin will be used to refer to any digitally encoded bearer form of value, no matter how encoded, what type of value, or what is required to issuer or redeem it.
  • Transactions can, for instance, be between the user and bank directly or between them through the payee. Many 0 other arrangements are possible and would be in keeping with the present invention. For instance, but without limitation, the user could communicate with the bank substantially at the time of payment without going through the payee. If the transaction is related to a particular payment, temporal proximity of the transactions can, however, suggest a linking that 3 can undermine privacy of the transaction. If an untraceable channel, such as might generally be provided or be provided through other parties is used, these issues can be addressed without tunneling through the payer.
  • Transaction flows for each user can in one example be comprised of a series of interactions of two types: withdrawal of value from the bank and payment to merchants. In between these transactions, the user holds at most one
  • Binary denomination schemes are used in the examples for clarity.
  • a wide variety of denomination schemes can, 5 however, be used with the present inventive concepts.
  • a tertiary scheme for instance without limitation, would work in a similar way as would be appreciated, except that instead of pairs of coins, triples would be used. Less homogenous schemes can of course also be used, as would be appreciated by those of ordinary skill in the art. 8
  • FIG. 1 shows a withdrawal transaction in accordance with the 1 teachings of the present invention.
  • a user 11 is shown on the left interacting through data communication means with a bank party 12 on the right.
  • a single transmission shift is shown because it is preferred for all the carry sub-protocols to be conducted in parallel, as would be appreciated by those of skill in the art. In general, however, whatever patterns of 4 interaction between parties can be used.
  • Fig. lb shows a payment interaction involving three parties, a user 11 making a payment to a payee 13 and additionally communicating with a bank 12.
  • the payee 13 contacts the bank 12 after 7 receiving information from the user 11, returns the result to the payer 13, and upon receiving a response from the user 11, is able to verify the payment.
  • the user 11 has first supplied preferably all the possible borrow sub-protocol messages to the payee 13, who forwards these to the bank 12. Also forwarded can be the actual money numbers for the payment to the 0 payee 13, but the authenticators are supplied by the user 11 only after receiving from the payee 13 the results of the payee's interaction with the bank 12.
  • the payee name could be built into these money numbers in known ways so that the authenticators and a way to re-create the money numbers would be 3 sufficiently convincing to the payee 13.
  • the bank 12 might provide the payee 13 with a (possibly signed) image under a one-way function of the authenticator corresponding to a particular money number. This would then allow the payee 13 to become convinced upon receiving the authenticator from the user 11. 6
  • Fig. 2 a detailed exemplary combination flow, functional, and protocol diagram of a maybemerge transaction is presented, in accordance with the teachings of the present invention. The arrow notation shown is well known in the art and used in subsequent figures.
  • the words "user” and "bank” serve to label the parties shown on their respective sides (although the reference numerals from Fig. 1 will not be cited for clarity).
  • the upper, right-pointing 3 arrow is labeled (as are all labels in this notation) with the essential message content communicated by the payment system user to the bank.
  • the lower, left-pointing arrow shows messages returned in the opposite direction.
  • the upper arrow shows three components being sent. If the user does not wish to do the merge, then all three can ⁇ be chosen by the user as random numbers — such as pseudorandom, physically random, or some combination. If the user does, however, wish to do the merge, then each of the three is preferably properly formed as follows: The first two are
  • money numbers or unauthenticated identifiers of electronic coins, as are well known in the art.
  • these 9 could be the output of a one-way function applied to various values, numbers of a particular agreed and preferably standardized redundant format, or one of many other forms known in the signature and/or authenticator art, any identification of the coin being applicable.
  • the first is denoted r ⁇ - and the second m 2 .
  • the third and final value transferred 2 is a blinded money number. It is shown as a blinding function "b" applied to a money number m 3 , but any blinding scheme or functional equivalent could be used.
  • a check and preferably atomically combined database 5 update is performed on the money number m, and m 2 .
  • the check is to ensure that the money number has not been previously spent; the update is to ensure that it cannot be spent later.
  • These two operations are preferably performed as a single atomic action or in another way to provide that the number cannot be used between the time that it is checked and s when it is blocked for further use.
  • Such checks and atomic updates being well known in the art of electronic money as the process steps needed to ensure that coins cannot be spent more than once in an online transaction. If the check indicates that the number has been spent or the blocking does not succeed, then the bank will return an error, otherwise the bank 1 will return the value shown on the arrow.
  • This single value shown returned by the second arrow is again for clarity in the example paradigm of the original blind signatures, but without limitation. It comprises three factors in a multiplicative group type of cryptosystem, as are 4 well known in the art.
  • the first and second factors are the images under two distinct one-way functions, f andf 2 , with their respective pre-images being the authenticator for mj, shown as ⁇ (/» ⁇ ) and the authenticator for m 2 , shown similarly.
  • the third factor is the authenticator function V, in this case preferably having twice the value of a, applied to the blinded form of m 3 , also as already described.
  • the user When the user obtains this number, it will be useless if the original input supplied by the user was random, as 0 mentioned above. This is the case when no merge takes place. As will be appreciated, however, the bank does not know which case the user has chosen. Now when the user has formed the message properly, as described above, then the user will be able to recover the authenticator function applied to the result of the blinding function applied to m 3 , or the 3 functional equivalent in any blinding-like signature or authenticator scheme. For instance, in the scheme shown, the user knows the two authenticators, ⁇ (m ⁇ ) and ⁇ (m 2 ), as already mentioned, and so is able to apply the respective one-way functions to them.
  • the bank checks and blocks the single money number /»-,, and if no error computes the two different and preferably independent one-way functions/ ! and/ 2 applied to the authenticator ⁇ it calculates for »?-.
  • the bank returns the two authenticators that if forms for m 2 and m 3 , each is multiplied by the respective one-way function image. Again, random input gives the payer nothing, although the bank won't know.
  • FIG. 4 a detailed exemplary combination flow, functional, and protocol diagram of a general
  • q s which is a unique s one-way function applied to a collection of authenticators and, in general, other labels q.
  • the q's each represent a composition of one-way functions applied to various money numbers.
  • the values sent back, in general, each are a product of a q and a signing function applied to a blinded money number.
  • any combination of the input money numbers can s be sufficient to yield each corresponding particular signature.
  • Fig. 5 a detailed exemplary combination flow, functional, and protocol diagram of a preparatory transaction is presented, in accordance with the teachings of the present invention.
  • the user is shown supplying a triple of 1 blinded values, C, D and E.
  • Each of these is subscripted by i to indicate that in general a number of such triples would be supplied, in whatever order. For instance, they might be supplied initially when an account is set up or to refill it periodically.
  • the lower-case variable names without subscript are also used here in 4 describing particular instances of the transactions, without loss of generality.
  • the first value that for c, comprises the product of two values in some suitable structure, such as that substantially comprising a group in 7 which the group operation and at least inverses are readily computed.
  • the first value is the application of a suitable transformation, shown as one-way function/], to an x authenticator of the supplied blinded e.
  • the other is the u authenticator of the supplied blinded c.
  • the second part of the returned message is the product of two 0 parts, one being/ ⁇ applied to the x authentication of the blinded e and the other being the u authentication of the blinded d.
  • Fig. 6 a detailed exemplary combination flow, functional, and protocol diagram of a maybesplit transaction using prepared coins is presented, in accordance with the teachings of the present invention.
  • the first message shown is form the user to the bank, envisioned for instance to be through the payee during a payment transactions. In one ⁇ case, as will be appreciated, it simply comprises random dummy values, except that e has the required redundancy or other property making it a potential coin apart from its authenticator.
  • this first message comprises differently blinded forms of the two result coins c and d as well as the unblinded form of e.
  • the blinding is preferably substantially independent of that used in the corresponding preparatory instance of Fig. 5, so that the bank cannot readily link the two transactions.
  • the returned value shown in the second arrow being from the bank to the user, comprises three components. All three components are formed including an encryption of the w authenticator of the e, each shown using a different version of/ as indicated by the subscripts 3, 4, and 5.
  • the first component is the x authenticator of e, which allows the two components returned, as already described with reference to Fig. 5, to be opened.
  • the second and third components allow the v authenticator of d and c, respectively, to be recovered. It is the combination of the u and v authenticators that are considered to be the proper authenticator for each of the split coin values.
  • the user can combine the two authenticators into one, such as by multiplying them in a discrete-log based system, yielding the sum of the exponents, and this sum is also the same authenticator used to issue coins of this denomination.
  • Anticipated are all manner of re-arrangements and cryptographic variations, exploiting equivalent forms of information and cryptographic techniques.
  • an invertible cryptographic operation to the authenticator protected before X-OR'ing in a plaintext version of the unlocking authenticator.
  • various ways to condense the locking-factors and share variants of them across instances are possible, such as having the basic authenticator determine the seed of a sequence whose values are used as the locking parameters.
  • Self-authenticating as well as merely authenticating techniques can be variously applied.
  • Other basic approaches to preventing payee anonymity can be applied.
  • some sort of tax could be assessed during at least some transformation transactions that applies only when the transaction is actually consumated. While these descriptions of the present invention have been given as examples, it will be appreciated by those of ordinary skill in the art that various modifications, alternate configurations and equivalents may be employed without departing from the spirit and scope of the present invention.

Landscapes

  • Business, Economics & Management (AREA)
  • Engineering & Computer Science (AREA)
  • Accounting & Taxation (AREA)
  • Strategic Management (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Finance (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

L'invention concerne des systèmes de transaction numériques qui permettent, dans certains modes de réalisation donnés à titre d'exemples, le transfert de valeur d'au moins une partie à au moins une autre partie, par l'intermédiaire d'une partie d'une pluralité de parties intermédiaires. Pendant la transaction entre une partie intermédiaire et une autre partie du système, l'intermédiaire peut changer la façon dont la valeur retenue est dénommée sans révéler si une telle transformation a véritablement eu lieu. Dans certains exemples, l'intermédiaire peut diviser une « pièce électronique » d'une certaine valeur en deux parties, chacune d'elles ayant ensuite la moitié de cette valeur. L'intermédiaire peut toutefois choisir si la valeur est réellement divisée ou pas ou si la transaction est factice, et ce choix peut être caché aux autres parties. De façon similaire, un intermédiaire peut éventuellement combiner deux jetons d'une certaine valeur en un seul jeton du double de cette valeur, sans révéler si la transaction a été réellement réalisée avec des éléments de valeur ou simplement avec des nombres aléatoires. Dans certains systèmes de monnaie électronique on veut que chaque payeur ne puisse donner à la valeur que des formes dont on peut retrouver la trace. De telles restrictions existent dans des modes de réalisation qui assurent que n'importe quel nouvel élément de valeur provient d'éléments pré-engagés.
PCT/US2001/023264 2000-07-24 2001-07-24 Systeme de monnaie electronique a pieces transparentes WO2002008865A2 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
AU2001280735A AU2001280735A1 (en) 2000-07-24 2001-07-24 Transparent-coin electronic money system

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US22026500P 2000-07-24 2000-07-24
US60/220,265 2000-07-24

Publications (2)

Publication Number Publication Date
WO2002008865A2 true WO2002008865A2 (fr) 2002-01-31
WO2002008865A3 WO2002008865A3 (fr) 2002-06-13

Family

ID=22822820

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2001/023264 WO2002008865A2 (fr) 2000-07-24 2001-07-24 Systeme de monnaie electronique a pieces transparentes

Country Status (2)

Country Link
AU (1) AU2001280735A1 (fr)
WO (1) WO2002008865A2 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10149129B2 (en) 2001-10-24 2018-12-04 Sipco, Llc Systems and methods for providing emergency messages to a mobile device

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5839119A (en) * 1996-09-27 1998-11-17 Xerox Corporation Method of electronic payments that prevents double-spending
US6029150A (en) * 1996-10-04 2000-02-22 Certco, Llc Payment and transactions in electronic commerce system
CA2259089C (fr) * 1999-01-15 2013-03-12 Robert J. Lambert Methode et appareillage de masquage des operations cryptographiques

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10149129B2 (en) 2001-10-24 2018-12-04 Sipco, Llc Systems and methods for providing emergency messages to a mobile device

Also Published As

Publication number Publication date
AU2001280735A1 (en) 2002-02-05
WO2002008865A3 (fr) 2002-06-13

Similar Documents

Publication Publication Date Title
Franklin et al. Secure and efficient off-line digital money
US5999625A (en) Method for electronic payment system with issuer control
AU723946B2 (en) Key replacement in a public key cryptosystem
US5963648A (en) Electronic-monetary system
KR100329802B1 (ko) 수탁 대리 기관들을 사용하는 상업 지불을 위한 시스템 및 방법
Schoenmakers Basic security of the ecash payment system
Asokan et al. State of the art in electronic payment systems
Wang et al. Untraceable off-line electronic cash flow in e-commerce
Schoenmakers Security aspects of the Ecash™ payment system
Sander et al. Flow control: A new approach for anonymity control in electronic cash systems
Fujisaki et al. Practical escrow cash systems
US7434726B2 (en) Method and system for postdating of financial transactions
Claessens et al. Anonymity controlled electronic payment systems
Luo et al. Offline transferable E-cash mechanism
JP2006048153A (ja) 量子現金システム及び装置
Radu et al. Efficient electronic cash with restricted privacy
CN113923015B (zh) 一种基于区块链支付通道的匿名多跳数据传输方法
Schoenmakers Security aspects of the Ecash™ payment system
WO2002008865A2 (fr) Systeme de monnaie electronique a pieces transparentes
Tewari et al. Reusable off-line electronic cash using secret splitting
Isern-Deyà et al. Untraceable, anonymous and fair micropayment scheme
Bo et al. An anonymity-revoking e-payment system with a smart card
Luo et al. An e-cash Scheme with Multiple Denominations and Transferability
Tewari T-Cash: Transferable fiat backed coins
Friis Digicash implementation

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 DE 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 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
AK Designated states

Kind code of ref document: A3

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY BZ CA CH CN CR CU CZ DE 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: A3

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 GQ GW ML MR NE SN TD TG

REG Reference to national code

Ref country code: DE

Ref legal event code: 8642

32PN Ep: public notification in the ep bulletin as address of the adressee cannot be established

Free format text: COMMUNICATION UNDER RULE 69 EPC (EPO FORM 1205A DATED 24.06.03)

122 Ep: pct application non-entry in european phase
NENP Non-entry into the national phase

Ref country code: JP