[go: up one dir, main page]

WO2002049730A1 - Jeu aux courses piloté par des données financières - Google Patents

Jeu aux courses piloté par des données financières Download PDF

Info

Publication number
WO2002049730A1
WO2002049730A1 PCT/US2001/050430 US0150430W WO0249730A1 WO 2002049730 A1 WO2002049730 A1 WO 2002049730A1 US 0150430 W US0150430 W US 0150430W WO 0249730 A1 WO0249730 A1 WO 0249730A1
Authority
WO
WIPO (PCT)
Prior art keywords
race
financial data
stock
stocks
player
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
PCT/US2001/050430
Other languages
English (en)
Inventor
Paul A. Adao E. Silva B.C.
Robert I. Howard
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
GFE GLOBAL FINANCING Ltd
Original Assignee
GFE GLOBAL FINANCING Ltd
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 GFE GLOBAL FINANCING Ltd filed Critical GFE GLOBAL FINANCING Ltd
Priority to AU2002231284A priority Critical patent/AU2002231284A1/en
Publication of WO2002049730A1 publication Critical patent/WO2002049730A1/fr
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Classifications

    • A—HUMAN NECESSITIES
    • A63—SPORTS; GAMES; AMUSEMENTS
    • A63F—CARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F3/00—Board games; Raffle games
    • A63F3/08—Raffle games that can be played by a fairly large number of people
    • A63F3/081—Raffle games that can be played by a fairly large number of people electric
    • A—HUMAN NECESSITIES
    • A63—SPORTS; GAMES; AMUSEMENTS
    • A63F—CARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F3/00—Board games; Raffle games
    • A63F3/00003—Types of board games
    • A63F3/00063—Board games concerning economics or finance, e.g. trading
    • A—HUMAN NECESSITIES
    • A63—SPORTS; GAMES; AMUSEMENTS
    • A63F—CARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F3/00—Board games; Raffle games
    • A63F3/00003—Types of board games
    • A63F3/00082—Racing games

Definitions

  • the present invention relates generally to gaming systems and, more specifically, to games driven by real world financial data.
  • each player of the simulated race may select and bet on any of a number of stocks.
  • the simulated race includes a display of racers, each associated with a player. The finish position of a player's racer is based on financial data associated with the stock selected by that player. Payout may be based on odds assigned to each stock and the amount bet.
  • the system providing the simulated race includes a system server and one or more client servers.
  • the client servers are configured to gather players' bets, simulate the race and apprise players of odds and winnings.
  • the system server provides the financial data, either current or historical, to the client servers and calculates odds and winnings.
  • Figure la is a schematic block diagram illustrating the components of a system according to one embodiment of the present invention.
  • Figure lb is an illustration of the player interface and display according to one embodiment of the present invention.
  • Figures 2 and 2a-c are flow charts of the operation of the main client system according to one embodiment of the present invention.
  • Figures 3 and 3a-d are flow charts illustrating the operation of the bedding subsystem according to one embodiment of the present invention.
  • Figures 4 and 4a-c are flow charts illustrating the operation of the main racing- phase routine of one embodiment of the present invention.
  • Figures 5 and 5a-d are flow charts illustrating the operation of the post-race phase according to one embodiment of the present invention.
  • Figures 6 and 6a-c are flow charts illustrating the operation of the system server according to one embodiment of the present invention.
  • Figures 7a-e are flow charts illustrating the response to client request handlers according to one embodiment of the present invention.
  • the system of the present embodiment is one in which a simulated race (e.g. horses, dogs, cars, etc.) is driven not solely by pseudo-random or stochastic algorithms but by real world financial data. This data may be obtained in real-time or represent historical financial data.
  • the present embodiment of the invention includes a client/server system, as illustrated in figure la, with clients that are Web browsers and custom, point of sale terminals. The system also implements coordinated, para-mutuel betting among all connected clients. On-site systems at casinos or betting parlors are also possible. As illustrated in Figure la, the system server and client each comprise multiple software components or servers providing the functionality described herein.
  • the game is based on players betting on stocks (or other securities, hereinafter stocks), from a finite set of, e.g., 5-10 or 20 stocks.
  • Bets can include any of the individual (win, place, show) type bets of a horse race and even combination bets such as trifacta bets.
  • Betting is then closed and the performance of the stocks is calculated over some predetermined period of time, such as within the range of 15 seconds to 2 minutes, preferably over 30 seconds.
  • the finish positions (and in certain embodiments, the interim positions) of the characters is based on how well the stocks performed during the time period.
  • the client portion of the system is responsible for the simulation of the race, gathering the user's bets and apprising the user of the changing status of odds and their individual winnings. Other than in gathering bets, all information can be obtained from the server portion by sending requests and waiting for responses.
  • the client software can be logically divided into three sequential phases: 1. Betting Phase; 2. Racing
  • Figures la and lb shows the user interface of the initial client implementation in each of these three phases of play.
  • a "core" system performs setup tasks such as memory allocation, server connection, event handler setup, etc. and advances the simulation through the three phases on a timed basis. It should be understood that one preferred implementation requires the presence of an event dispatch/handler mechanism. These are intrinsic to many modem windowing libraries or can easily be built.
  • FIG. 2 and 2a-c illustrate the flow of the main client system.
  • the main routine sends a connection request that incorporates encrypted client identification data. Step
  • the application sends a request to the server for the current "official" time.
  • Requests to the server can be accompanied by the encrypted ID of the application instance that is validated on receipt before any response is sent. All instances advantageously have their clocks synchronized in order to insure that cooperating players cannot cheat by transmitting race results from an instance with an earlier clock to one with a later clock.
  • Storage is preferably allocated, for each racer, sufficient to hold one stock value for each second that the race will last. Step 208. Then, a request is sent to the server for the stock data for the next race. Step 210.
  • the scoreboard display is created. Step 212.
  • the scoreboard can display current odds, time till the next race, amount bet worldwide, final odds and racer positions, depending on which state, Betting, Racing or Post-Race, the system is in.
  • Figure 2a shows the handler that responds to the message that the system's state needs to change. This function is triggered by each of three subsystems (Betting (B),
  • Step 214 If the Post-race phase is the caller, or at system startup, the race number is incremented. Step 216. In all three cases, the appropriate phase implementation function is called.
  • Figure 2b illustrates the client's method of synchronizing to server time.
  • the routine Triggered on the receipt of the time synchronization packet, previously requested from the server, the routine simply updates the client's clock to reflect the same time as the server's. Step 218.
  • the method is essentially identical to that used in the standard Internet time synchronization protocol.
  • Figure 2c shows the system's response to the arrival of race data. This routine is triggered on receipt of the next race's encrypted stock data from the server. The data, comprising a set of prices for each racer, is stored to disk in its encrypted form. Step 220.
  • the betting phase involves both betting itself and the display of sufficient information to guide the betting process.
  • the software collects bets from the user, forwards them to the server and obtains updated odds on a regular basis.
  • Figure 3 outlines the flow of the main betting-phase routine that is invoked in
  • FIG 2a First, betting "panels" are created (displayed) to represent different types of bets.
  • Step 302. In a horseracing scenario, three panels would be created to represent "Win,”
  • This routine also preferably installs the following four event handlers that will respond to all user interaction with the betting phase of the simulation:
  • F Fiigure 3 a shows the functionality of the betting handler. This component is invoked whenever the user increases or decreases any bet by pressing the panels' buttons. First, whether the bet will increase or decrease is determined. Step 306. Depending on the answer, the bet for the specific type and racer is incremented or decremented. Steps 308, 310. The display for that racer (e.g., horse) is updated to show the new value (Step 312) and a packet is sent to the server apprising it of the change. Step 314. [0048] 2.2.3 Request Odds Update
  • Figure 3b shows a request for odds update.
  • odds are calculated based on the betting of the patrons, not on the relative merits of the racers. This requires continuous update of the odds during the betting phase.
  • the system periodically, (e.g., every 10 seconds) invokes this handler and sends an encrypted request to the server for the latest odds calculations. Step 316.
  • Figure 3 c shows what happens when the odds are received from the server.
  • the routine updates the scoreboard display with the latest odds for each racer, and optionally, with the monetary value of all bets on that racer. Step 318.
  • Step 320 the function first decrements the time-till-race counter that it maintains (Step 320) and updates the scoreboard so the user knows when to hurry their betting. Step 322. A check is performed to determine whether the countdown has expired. Step 324. If it has, the betting panels are destroyed. Step 326.
  • the racing phase displays the race simulation to the user. It initializes the animation mechanisms and translates each financial data point, previously stored, into the relative speeds of the racers. This can be displayed on a user's computer screen or on a large display at a betting parlor. In other embodiments of the invention, the race simulation can be mechanical.
  • Figure 4 outlines the flow of the main racing-phase routine that is invoked in
  • Step 402. This view displays a moving background and all of the racing characters, such as horses, during the course of the race.
  • the sprites that will represent the racers are created.
  • the sprites are instructed to load their animation frames from bitmaps stored on the client's disk (Step 406) and their initial positions, within the race view, are set.
  • Step 408 Three event handlers are installed to conduct the race itself:
  • Figure 4a illustrates the process that drives the sprites animation.
  • horseracing for example, this would animate the legs and the jockeys' bouncing.
  • this would animate the cars' wheels.
  • the routine is advantageously invoked every 0.2 seconds or less, preferably every 0.05 seconds or more often and first advances each sprite's frame pointer.
  • Step 412. If the frame index has passed the last frame (Step 414), it is reset to the first frame.
  • the sprites' images are then bitblt'd to memory, overlaying the background bitmap.
  • Step 418 the areas of the race view that need update are bitblt'd from memory to the racing view.
  • Step 420 illustrates the process that drives the sprites animation.
  • Figure 4b outlines the procedure for moving the racers based on the stored financial data. This routine is invoked at least once every 5 seconds, preferably at least once every second, based on the resolution of the data stream available. Since this is a gaming system, looks are very important. The greatest loss and greatest gain of the stock (in the current period) are calculated and are scaled, arbitrarily or otherwise, into a positive range of pixels. Each racer's position is advanced by the number of pixels obtained from scaling its price's percentage change into that range. Step 422.
  • Step 424 If it has, the Set System State handler (S) (see 2.1.2) is invoked so that the post- , race phase can begin. If not, the system sets the sprite position positions. Step 426.
  • S Set System State handler
  • the post-race phase displays the final odds, shows the user any winnings they may have accrued and gives them sufficient time to view their results. It is during this phase that we request the next set of financial data from the server, ensuring that it will be available by the time the next race starts.
  • Figure 5 outlines the flow of the main post-race-phase routine that is invoked in Figure 2a.
  • the system installs the four handlers that will control the phase's action:
  • the system requests final odds and the user's winnings/losses from the server (Step 504) and requests another time synch packet. Step 506. Finally, the request is made for the next set of race data values. Step 508.
  • Figure 5a describes the response to receipt of final odds and winnings from the server.
  • the scoreboard is updated to reflect the odds that were calculated after all bets were received and the individual user's winnings as calculated from those odds and their bets.
  • Step 510
  • Figure 5b illustrates the client's method of synchronizing to server time.
  • the routine Triggered on the receipt of the time synchronization packet, previously requested from the server, the routine updates the client's clock to reflect the same time as the servers. Step 512.
  • Figure 5c shows the system's response to the arrival of race data. This routine is triggered on receipt of the next race's encrypted stock data from the server. The data, comprising a set of prices for each racer (i.e., stock) is stored to disk in its encrypted form. Step 514.
  • Figure 5d shows the handler that is triggered once every second.
  • a stored counter is used to delay the start of the next betting period for whatever time seems appropriate.
  • the function decrements the counter (Step 516) and then checks if it has reached zero. Step 518. If it has, the race view is destroyed. Step 520. Finally, the Set System State handler (S) (see 2.1.2) is invoked so that the next betting phase can begin.
  • S Set System State handler
  • the server of the system is very similar in design (but not functionality) to many Internet servers (e.g. Web Servers).
  • a connection manager process receives requests from qualified clients and spawns a separate process for each of them. These "child" processes service the requests of the clients that they are connected to.
  • a second primary process manages the connection to the broker's real time data feed. If, in other embodiments of the invention, historical data for the simulation can be chosen, the same design can be employed, with the second primary process accessing data from fixed storage rather than over the Internet.
  • the server begins by initializing its real-time feed from the chosen broker. The nature of these connections varies from provider to provider.
  • the server registers with the broker's server and waits for packets on a particular port.
  • the server spawns two processes. The first waits on the real-time data feed's port for financial data packets from the provider. Step 604. The second waits on the port that is used by the clients to communicate with their server and services requests for client connections.
  • Step 606. [0091 ] 3.1.2 Store Financial Data Process
  • Figure 6a shows the response to received packets of financial data.
  • the system periodically checks for received stock data. Steps 608, 610.
  • the system encrypts and stores the received data until sufficient data has been stored to handle the next race.
  • the information is encrj ⁇ ted once before it is stored. Step 612. This removes the overhead of communicating through a Secure Socket Layer (SSL), which re-encrypts the data each time it is requested.
  • SSL Secure Socket Layer
  • Figure 6b shows the Server's response to a client request for connection.
  • Step 616 the server consults its database of authorized clients. If the client doesn't have authorization (as determined in Steps 618, 620), it waits for the next request. If it does have authorization, the server spawns a separate process (see 3.1.4) to handle that client. Step 622. Then, it returns to waiting for the next connection request. Step 616. [0095] 3.1.4 Service Client Requests
  • Figure 6c illustrates the functionality of the process that is spawned to service each client's connection.
  • the process establishes five event handlers, corresponding to each of the five possible client requests:
  • Figure 7a shows the server's response to a time synchronization request.
  • the server sends a time synchronization packet to the client.
  • Step 702. The formats of the packet, and the nature of the algorithms on either end, are simply an implementation of the standard Internet Network Time Protocol (NTP) whose specifications are laid out in RFCl 119 and RFCl 129, incorporated herein by reference.
  • NTP Internet Network Time Protocol
  • the handler detailed in figure 7b is triggered. The function simply retrieves the current odds from storage and sends them to the connected client. Step 704.
  • Figure 7c shows the response to a client's request for the data that will drive the next race.
  • the routine transmits the previously encrypted race data to the client. Step 706.
  • Figure 7d is triggered.
  • details of the bet e.g. client ID, bet category, bet amount, racer
  • the handler updates the betting totals store.
  • the odds are calculated based on the current totals for each racer.
  • the total bets from all clients for a given category e.g., "Win" are divided by the total bets from all clients for each horse.
  • Figure 7e As illustrated by the arrow between Figures 7d and 7e, the final odds are retrieved from the current odds store and transmitted to the client in encrypted form. To calculate the client's winnings, the individual client's bets are retrieved and multiplied by the associated odds, after the house's "take” has been reserved. Step 714. The resulting winnings are encrypted and sent to the client. Step 716.
  • the system is used to simulate a ski race, in which the progression of each skier down a mountain is based upon the decrease (or increase) in a stock's performance.
  • stocks refers to any security or other financial instrument, including equities, debt instruments, interest rates, foreign exchange currency rates, commodity contracts, futures and the like.
  • progression of racers may be based on any measured variable associated with such stocks, including, for example, volatility, the aggregate of the stock's volatility in each of multiple time periods comprising the race (e.g., aggregate of the trading ranges in each minute of a race lasting several minutes), total volatility over the course of a period corresponding to a race (e.g., absolute price change over a several minute period), price (either increase or decrease), trading volume, trading volume as compared to the stock's average volume, and the like.
  • volatility the aggregate of the stock's volatility in each of multiple time periods comprising the race
  • total volatility over the course of a period corresponding to a race e.g., absolute price change over a several minute period
  • price either increase or decrease
  • trading volume trading volume as compared to the stock's average volume, and the like.
  • the present invention is directed to simulated racing games whose outcome is based on financial data, it is within the scope of the present invention to use other information or factors, in addition to financial data, as the basis for determining the outcome of the simulated race.
  • information and factors may include pseudo-random and/or stochastic algorithms.
  • the pseudo-random and/or stochastic algorithm includes randomly assigning a multiple to be applied to the financial data.

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

La présente invention concerne un procédé et un système permettant de mettre en oeuvre une simulation de jeu aux courses à base de données financières. Selon un mode de réalisation, on propose aux joueurs des actions en bourse. Chaque joueur peut choisir et miser sur une action. La simulation de course fait intervenir une représentation de chevaux de courses associés chacun à un joueur. Le classement à l'arrivée du cheval de course d'un joueur repose sur des données financières associées à l'action choisie par le joueur considéré. Les gains peuvent reposer sur la cote affectée à chaque action et sur le montant des mises. Selon un mode de réalisation, le système réalisant la simulation de course comporte un serveur système et au moins un serveur client. Les serveurs clients sont configurés de façon à réunir les paris des joueurs, à simuler la course et à notifier aux joueurs les cotes et les gains. Le serveur système fournit aux serveurs clients les données financières, soit courantes, soit en historique, et calcule les cotes et les gains.
PCT/US2001/050430 2000-12-20 2001-12-20 Jeu aux courses piloté par des données financières Ceased WO2002049730A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
AU2002231284A AU2002231284A1 (en) 2000-12-20 2001-12-20 Financial data driven racing game

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US25708600P 2000-12-20 2000-12-20
US60/257,086 2000-12-20

Publications (1)

Publication Number Publication Date
WO2002049730A1 true WO2002049730A1 (fr) 2002-06-27

Family

ID=22974812

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2001/050430 Ceased WO2002049730A1 (fr) 2000-12-20 2001-12-20 Jeu aux courses piloté par des données financières

Country Status (2)

Country Link
AU (1) AU2002231284A1 (fr)
WO (1) WO2002049730A1 (fr)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2004040495A1 (fr) * 2002-10-31 2004-05-13 Cheol-Hee Jang Procede permettant de fournir un jeu d'investissement en bourse sur un serveur web
JP2014509005A (ja) * 2011-02-15 2014-04-10 ストリート ヒーツ エルエルシー オンラインゲームシステムおよび方法
US10395471B2 (en) 2013-03-13 2019-08-27 Exacta Systems, Llc Apparatus, system and method for electronic gaming
US10997825B2 (en) 2015-01-06 2021-05-04 Exacta Systems, Llc System and method of wagering on a plurality of events

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5564701A (en) * 1995-04-28 1996-10-15 Dettor; Michael K. Casino oriented gaming apparatus and method incorporating randomly generated numbers
US6191799B1 (en) * 1998-08-07 2001-02-20 Quid Novi, S.A. Method apparatus and computer-readable medium for altering the appearance of an animated object
US6272332B1 (en) * 1996-07-19 2001-08-07 Pioneer Electronic Corporation Information presentation system and portable telephone apparatus with information displaying function

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5564701A (en) * 1995-04-28 1996-10-15 Dettor; Michael K. Casino oriented gaming apparatus and method incorporating randomly generated numbers
US6272332B1 (en) * 1996-07-19 2001-08-07 Pioneer Electronic Corporation Information presentation system and portable telephone apparatus with information displaying function
US6191799B1 (en) * 1998-08-07 2001-02-20 Quid Novi, S.A. Method apparatus and computer-readable medium for altering the appearance of an animated object

Cited By (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2004040495A1 (fr) * 2002-10-31 2004-05-13 Cheol-Hee Jang Procede permettant de fournir un jeu d'investissement en bourse sur un serveur web
JP2014509005A (ja) * 2011-02-15 2014-04-10 ストリート ヒーツ エルエルシー オンラインゲームシステムおよび方法
US10395471B2 (en) 2013-03-13 2019-08-27 Exacta Systems, Llc Apparatus, system and method for electronic gaming
US11069184B2 (en) 2013-03-13 2021-07-20 Exacta Systems, Llc Apparatus, system and method for electronic gaming
US11651649B2 (en) 2013-03-13 2023-05-16 Exacta Systems, Llc Apparatus, system and method for electronic gaming
US12315334B2 (en) 2013-03-13 2025-05-27 Exacta Systems, Llc Apparatus, system and method for electronic gaming
US10997825B2 (en) 2015-01-06 2021-05-04 Exacta Systems, Llc System and method of wagering on a plurality of events
US11189134B2 (en) 2015-01-06 2021-11-30 Exacta Systems, Llc System and method of wagering on a plurality of events
US11189133B2 (en) 2015-01-06 2021-11-30 Exacta Systems, Llc System and method of wagering on a plurality of events
US11514759B2 (en) 2015-01-06 2022-11-29 Exacta Systems, Llc System and method of wagering on a plurality of events
US12091422B2 (en) 2015-01-06 2024-09-17 Exacta Systems, Llc System and method of wagering on a plurality of events

Also Published As

Publication number Publication date
AU2002231284A1 (en) 2002-07-01

Similar Documents

Publication Publication Date Title
US11699325B2 (en) Real-time interactive wagering on event outcomes
JP4926948B2 (ja) 金融市場の動きに基づく賭けシステム及び方法
AU2004227808B2 (en) System and method for wagering-based transferable financial instruments
AU780285B2 (en) Multimedia wagering system
KR101736754B1 (ko) 웨이저링 장치， 방법들 및 시스템들
AU2021204225A1 (en) Pool wagering apparatus, methods and systems
WO2002049730A1 (fr) Jeu aux courses piloté par des données financières
RU73217U1 (ru) Игровая система
KR101726203B1 (ko) 웨이저링 장치， 방법들 및 시스템들
AU2022283649A1 (en) System and method for wagering-based transferable financial instruments
AU2020256293A1 (en) System and method for wagering-based transferable financial instruments
AU2012204029A1 (en) System and method for wagering based on the movement of financial markets
AU2015238779A1 (en) System and method for wagering based on the movement of financial markets
AU2012247034A1 (en) System and method for wagering-based transferable financial instruments

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

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

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)
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: NOTING OF LOSS OF RIGHTS PURSUANT TO RULE 69(1)EPC(EPO F1205A DATED 081203)

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

Ref country code: JP

WWW Wipo information: withdrawn in national office

Country of ref document: JP