WO2003048974A1 - Method and arrangement in a communication system - Google Patents

Method and arrangement in a communication system Download PDF

Info

Publication number
WO2003048974A1
WO2003048974A1 PCT/SE2002/002174 SE0202174W WO03048974A1 WO 2003048974 A1 WO2003048974 A1 WO 2003048974A1 SE 0202174 W SE0202174 W SE 0202174W WO 03048974 A1 WO03048974 A1 WO 03048974A1
Authority
WO
WIPO (PCT)
Prior art keywords
media stream
client
information
server
random access
Prior art date
Application number
PCT/SE2002/002174
Other languages
French (fr)
Inventor
Björn ELENFORS
Anders Svensson
Mikael Dahlgren
Johan GÖRSJÖ
Original Assignee
Elenfors Bjoern
Anders Svensson
Mikael Dahlgren
Goersjoe Johan
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 Elenfors Bjoern, Anders Svensson, Mikael Dahlgren, Goersjoe Johan filed Critical Elenfors Bjoern
Priority to AU2002365744A priority Critical patent/AU2002365744A1/en
Publication of WO2003048974A1 publication Critical patent/WO2003048974A1/en

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/235—Processing of additional data, e.g. scrambling of additional data or processing content descriptors
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/70—Media network packetisation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/75—Media network packet handling
    • H04L65/762—Media network packet handling at the source 
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/432—Content retrieval operation from a local storage medium, e.g. hard-disk
    • H04N21/4325—Content retrieval operation from a local storage medium, e.g. hard-disk by playing back content from the storage medium
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/435—Processing of additional data, e.g. decrypting of additional data, reconstructing software from modules extracted from the transport stream
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/83—Generation or processing of protective or descriptive data associated with content; Content structuring
    • H04N21/845—Structuring of content, e.g. decomposing content into time segments
    • H04N21/8455—Structuring of content, e.g. decomposing content into time segments involving pointers to the content, e.g. pointers to the I-frames of the video stream

Definitions

  • the present invention relates to a method according to the pre-characterising clause of claim 1.
  • the invention also relates to an arrangement according to the pre-characterising clause of claim 5.
  • the first method may be defined as "pull”, that is to say the receiver, for example a client, controls the transfer of information.
  • the second method may be defined as "push”, that is to say the transmitter, for example a server, controls the transfer of information or puts out data to the client.
  • the first method is used, for example, by a web server, a client explicitly retrieving the media stream that the client wants and downloading this.
  • the client can begin to decode this concurrently as the stream is being downloaded.
  • the second method is used by a conventional video server.
  • a client wishes to have a media stream sent to him, the video server beginning to send the media stream at the same rate at which it assumes playback is to take place.
  • the client stores the stream in an input buffer and then begins to play it back.
  • a media stream for example a video stream, comprises a limited number of sequences between which it is possible to intervene and begin to decode the stream, so-called random access sequences. It is not possible to decode the stream correctly if the decoding commences midway through such a sequence, since important information will then be missing.
  • MPEG-2 Moving Picture Expert Group
  • RTSP Real Time Streaming Protocol
  • the server at all times knows where the client is in the stream and can therefore respond in order to send the correct information from the media stream at the correct rate to the client.
  • a client may wish to start transferring the media stream at a given point, for example a number of seconds into the stream.
  • the server will then begin to search directly for the nearest legal random access point and commence the transfer from there.
  • the client is simple but the server is all the more complicated. Since the server is responsible for sending data at precisely the right rate to all its clients, this makes it very resource-hungry and errors easily occur.
  • the client retrieves the stream. This means that server and client do not have such a strong link with one another as in the second method.
  • the client itself is responsible for the transfer, that is to say for reading data at the required rate. This gives a reduced risk of error, especially so-called “single point of failure" and improved scalability.
  • a major disadvantage to a "pull"-based solution is that it normally only affords the facility for reading the media stream from beginning to end. It is not possible for a client to effectively find the random access points, which is of interest, for example, in being able to spool rapidly in the media stream. The reason is that, for the client, there is no known relationship, for example, between "playback time" in the media stream and the binary position therein.
  • the client In order to allow a client to move to a given random access point, the client must search in the media stream in order to find this. This can be done, for example, by guessing how far forwards the point lies, reading a partial quantity of the media stream around the estimated point, and decoding this information in order to find the point. If the point did not occur in the partial quantity read, the procedure must be repeated. Since the network is a limited resource with regard to the transmission speed, such a procedure is more expensive and slower than necessary.
  • the object of the present invention is partly to provide an improved method according to the pre-characterising clause of claim 1, and partly to provide an improved arrangement according to the pre-characterising clause of claim 5. This is achieved by the method according to the invention having the characteristic features specified in the characterising part of claim 1. The characteristic features of the arrangement according to the invention are set forth by the characterising part of claim 5.
  • Fig. 1 shows a block diagram of a communications system according to the invention.
  • Fig. 2 shows a generalised media stream comprising a number of sequences which are legal random access objectives.
  • the communications system in Fig. 1 comprises a user side 10, consisting of at least one client 4 which reads a media stream 12 (shown in Fig. 2) with the object of storing it or playing it back, an operator side 9 comprising at least one server 2, which makes one or more stored media streams 8 accessible for transfer to clients 4, and a network situated between the user side 10 and the operator side 9.
  • each client 4 comprises a communications client 5, a decoder 6 and a display unit 7.
  • the function of the communications client 5 is to request the stored media stream 8 and an index file 11 (described in more detail below) from the server 2, and to perform the necessary preliminary decoding before relaying suitable packets of the media stream 12 to the decoder 6.
  • the decoder 6 decodes the media stream 12 and allows the display unit 7 to display it for the user.
  • the client may be constructed in some way other than that shown in the preferred embodiment.
  • the operator side 9 comprises the server 2 and a data store 1 containing the stored media streams 8 and the index files 11.
  • the server 2 sends the stored media streams 8 and the index files 11 over the network 3 to the communications client 5 according to a Hyper Text Transfer Protocol (http).
  • the network 5 may be any type of network familiar to the person skilled in the art, for example the Internet, and this will not be discussed further here.
  • the http protocol enables the communications client 5 to read the sequences 14 of the media stream 12 in random order. In this description and in the figures a distinction is made between the stored media stream 8 and the transferred media stream 12; depending on coding etc. these streams need not be exactly identical.
  • a media stream 12 comprises a limited number of sub-sequences 14, shown in Fig. 2.
  • a media stream is stored in the server 2, it is analysed and the points 13 which are legal random access sub-sequences 14 are saved to the index file 11.
  • the file 11 describes the stream from a random access perspective, that is to say what legal random access sub-sequences 14 it contains.
  • the binary starting point 13 and time in the media stream of each such sub-sequence are stored to the index file 11.
  • the client 4 When the client 4 wishes to use random access it retrieves the index file 11 from the server 2.
  • the client 4 By having access to this index file 11 the client 4 will know where all random access points 13 are located at any juncture during the playback, and can then effectively read such random access sub-sequences 14 if so required. This is done, for example, when spooling rapidly forwards and backwards in media files such as MPEG films where the media stream is a video stream.
  • the client uses this index information in order to come directly to a legal sub-sequence, which in the preferred embodiment of the invention can be sent to the decoder without searching through the stream and requesting too much information from the server.

Abstract

Method and arrangement for the transfer of a media stream (12) from a server (2) to a client (4) coupled to the server (2) over a network (3), in which the media stream (12) is divided up into sequences (14) of unknown length. The media stream (12) is analysed, each sequence (14) being marked for legal random access. Information on how the media stream (12) is divided up is retrieved and this information is used in transferring the media stream (12) in order to locate the legal random access sequences (14).

Description

Method and arrangement in a communication1.; system
The present invention relates to a method according to the pre-characterising clause of claim 1.
The invention also relates to an arrangement according to the pre-characterising clause of claim 5.
There are at present two primary methods of transmitting media streams, such as sound and video, for example, over a network. The first method may be defined as "pull", that is to say the receiver, for example a client, controls the transfer of information. The second method may be defined as "push", that is to say the transmitter, for example a server, controls the transfer of information or puts out data to the client.
The first method is used, for example, by a web server, a client explicitly retrieving the media stream that the client wants and downloading this. The client can begin to decode this concurrently as the stream is being downloaded.
The second method is used by a conventional video server. A client wishes to have a media stream sent to him, the video server beginning to send the media stream at the same rate at which it assumes playback is to take place. The client stores the stream in an input buffer and then begins to play it back.
A media stream, for example a video stream, comprises a limited number of sequences between which it is possible to intervene and begin to decode the stream, so-called random access sequences. It is not possible to decode the stream correctly if the decoding commences midway through such a sequence, since important information will then be missing. In a media format such as Moving Picture Expert Group (MPEG-2), for example, there are typically 1 to 2 such sequences every second.
The second method described above, exemplified by a video server solution, traditionally involves complex and expensive systems comprising an advanced server and simple clients. A determining factor in this is the fact that most architectures developed from the early to the mid-nineties, when computing power and network capacity were limited.
In a conventional video server based on Real Time Streaming Protocol (RTSP) the server at all times knows where the client is in the stream and can therefore respond in order to send the correct information from the media stream at the correct rate to the client. A client may wish to start transferring the media stream at a given point, for example a number of seconds into the stream. The server will then begin to search directly for the nearest legal random access point and commence the transfer from there. The client is simple but the server is all the more complicated. Since the server is responsible for sending data at precisely the right rate to all its clients, this makes it very resource-hungry and errors easily occur.
In the first method, where a "pull" solution is used for transferring the media stream, the client retrieves the stream. This means that server and client do not have such a strong link with one another as in the second method. The client itself is responsible for the transfer, that is to say for reading data at the required rate. This gives a reduced risk of error, especially so-called "single point of failure" and improved scalability.
A major disadvantage to a "pull"-based solution, however, is that it normally only affords the facility for reading the media stream from beginning to end. It is not possible for a client to effectively find the random access points, which is of interest, for example, in being able to spool rapidly in the media stream. The reason is that, for the client, there is no known relationship, for example, between "playback time" in the media stream and the binary position therein.
In order to allow a client to move to a given random access point, the client must search in the media stream in order to find this. This can be done, for example, by guessing how far forwards the point lies, reading a partial quantity of the media stream around the estimated point, and decoding this information in order to find the point. If the point did not occur in the partial quantity read, the procedure must be repeated. Since the network is a limited resource with regard to the transmission speed, such a procedure is more expensive and slower than necessary.
One of the main reasons why complex video servers instead of "pull" solutions are currently used, for example as web servers, is precisely this lack of effective random access.
Being able to use simpler web servers rather than video servers is a very interesting prospect, however, one of many examples being the ability to show trailers for films stored on web servers without the need for supplementary video servers.
There is consequently a need for an improved method and arrangement for random access in media streams, in which the client using "pull" methods represents the prime mover. The object of the present invention is partly to provide an improved method according to the pre-characterising clause of claim 1, and partly to provide an improved arrangement according to the pre-characterising clause of claim 5. This is achieved by the method according to the invention having the characteristic features specified in the characterising part of claim 1. The characteristic features of the arrangement according to the invention are set forth by the characterising part of claim 5.
In applying the invention, the method and the arrangement according to the invention each have the features specified in the characterising part of claims 2-4 and 6-8 respectively.
The invention will be explained in more detail below with reference to the drawing attached of which Fig. 1 shows a block diagram of a communications system according to the invention. Fig. 2 shows a generalised media stream comprising a number of sequences which are legal random access objectives.
The communications system in Fig. 1 comprises a user side 10, consisting of at least one client 4 which reads a media stream 12 (shown in Fig. 2) with the object of storing it or playing it back, an operator side 9 comprising at least one server 2, which makes one or more stored media streams 8 accessible for transfer to clients 4, and a network situated between the user side 10 and the operator side 9.
In a preferred embodiment of the invention each client 4 comprises a communications client 5, a decoder 6 and a display unit 7. The function of the communications client 5 is to request the stored media stream 8 and an index file 11 (described in more detail below) from the server 2, and to perform the necessary preliminary decoding before relaying suitable packets of the media stream 12 to the decoder 6. The decoder 6 decodes the media stream 12 and allows the display unit 7 to display it for the user. The person skilled in the art will appreciate that without departing from the scope of the idea of the invention the client may be constructed in some way other than that shown in the preferred embodiment.
In the preferred embodiment of the invention the operator side 9 comprises the server 2 and a data store 1 containing the stored media streams 8 and the index files 11. The server 2 sends the stored media streams 8 and the index files 11 over the network 3 to the communications client 5 according to a Hyper Text Transfer Protocol (http). The network 5 may be any type of network familiar to the person skilled in the art, for example the Internet, and this will not be discussed further here. The http protocol enables the communications client 5 to read the sequences 14 of the media stream 12 in random order. In this description and in the figures a distinction is made between the stored media stream 8 and the transferred media stream 12; depending on coding etc. these streams need not be exactly identical.
A media stream 12 comprises a limited number of sub-sequences 14, shown in Fig. 2. Before a media stream is stored in the server 2, it is analysed and the points 13 which are legal random access sub-sequences 14 are saved to the index file 11. The file 11 describes the stream from a random access perspective, that is to say what legal random access sub-sequences 14 it contains. The binary starting point 13 and time in the media stream of each such sub-sequence are stored to the index file 11.
When the client 4 wishes to use random access it retrieves the index file 11 from the server 2.
By having access to this index file 11 the client 4 will know where all random access points 13 are located at any juncture during the playback, and can then effectively read such random access sub-sequences 14 if so required. This is done, for example, when spooling rapidly forwards and backwards in media files such as MPEG films where the media stream is a video stream.
In response to a user request to start playback from some point other than the beginning of the stream and to move to another part of the stream, the client uses this index information in order to come directly to a legal sub-sequence, which in the preferred embodiment of the invention can be sent to the decoder without searching through the stream and requesting too much information from the server.

Claims

Claims
1. Method for the transfer of a media stream (12) from a server (2) to a client (4) coupled to the server (2) over a network (3), in which the media stream (12) is divided up into sequences (14) of unknown length, characterised in that the media stream (12) is analysed, each sequence (14) being marked for legal random access, that information on how the media stream (12) is divided up is retrieved and that this information is used in transferring the media stream (12) in order to locate the legal random access sequences (14).
2. Method according to Claim 1, characterised in that the information that is retrieved comprises the start time in the media stream (12) of all random access sequences together with their binary position, that the information is stored in an index file (11), and that the information is used in order to retrieve data from the correct position in the media stream (12) if the media stream (12) is to be played back from a point in time other than the starting point or if there is to be any movement through the media stream (12).
3. Method according to Claim 1 or 2, characterised in that the start time of all random access sequences and their binary positions are stored in a table in a memory in the client (4) with the object of being able to refer effectively to the binary position of each ransom access point.
4. Method according to Claim 1 or 2, characterised in that sequences (14) of the media stream (12) are read by the client (4) in random order.
5. Arrangement for the transfer of a media stream (12) from a server (2) to a client (4) coupled to the server (2) over a network (3), in which the media stream (12) is divided up into sequences (14) of unknown length, characterised in that the server (2) is designed to analyse the media stream (12), and to mark each sequence (14) for legal random access, that the client (4) is designed to retrieve information on how the media stream (12) is divided up and to use this information in transferring the media stream (12) in order to locate the legal random access sequences (14).
6. Arrangement according to Claim 5, characterised in that at least one media stream (8) is stored in a data store (1) coupled to the server (2), which is designed to analyse the media stream (8) once initially before it is stored in the data store (1).
7. Arrangement according to Claim 5 or 6, characterised in that the information which the client (4) is designed to retrieve comprises the start time in the media stream (12) of all random access sequences, together with their binary position and that this information is stored in an index file (11).
8. Arrangement according to Claim 7, characterised in that the client (4) is designed to use the index file (1 1) in order to retrieve data from the correct position in the media stream (12) if the media stream (12) is to be played back from a point in time other than the starting point or if there is to be any movement through the media stream (12).
PCT/SE2002/002174 2001-12-06 2002-11-27 Method and arrangement in a communication system WO2003048974A1 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
AU2002365744A AU2002365744A1 (en) 2001-12-06 2002-11-27 Method and arrangement in a communication system

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
SE0104114A SE520246C2 (en) 2001-12-06 2001-12-06 Method and device in a communication system
SE0104114-4 2001-12-06

Publications (1)

Publication Number Publication Date
WO2003048974A1 true WO2003048974A1 (en) 2003-06-12

Family

ID=20286233

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/SE2002/002174 WO2003048974A1 (en) 2001-12-06 2002-11-27 Method and arrangement in a communication system

Country Status (3)

Country Link
AU (1) AU2002365744A1 (en)
SE (1) SE520246C2 (en)
WO (1) WO2003048974A1 (en)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2323390A2 (en) * 2008-09-04 2011-05-18 Sk Telecom Co., LTD Media transmission system and method

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1996017313A1 (en) * 1994-11-18 1996-06-06 Oracle Corporation Method and apparatus for indexing multimedia information streams
US6101547A (en) * 1998-07-14 2000-08-08 Panasonic Technologies, Inc. Inexpensive, scalable and open-architecture media server
US6167083A (en) * 1997-04-04 2000-12-26 Avid Technology, Inc. Computer system and process for capture editing and playback of motion video compressed using interframe and intraframe techniques
WO2001041000A1 (en) * 1999-11-30 2001-06-07 New Media Technology, Corp. System and method for computer-assisted manual and automatic logging of time-based media
US6282549B1 (en) * 1996-05-24 2001-08-28 Magnifi, Inc. Indexing of media content on a network
EP1193920A2 (en) * 2000-09-29 2002-04-03 Microsoft Corporation Improved media streaming methods and arrangements

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1996017313A1 (en) * 1994-11-18 1996-06-06 Oracle Corporation Method and apparatus for indexing multimedia information streams
US6282549B1 (en) * 1996-05-24 2001-08-28 Magnifi, Inc. Indexing of media content on a network
US6167083A (en) * 1997-04-04 2000-12-26 Avid Technology, Inc. Computer system and process for capture editing and playback of motion video compressed using interframe and intraframe techniques
US6101547A (en) * 1998-07-14 2000-08-08 Panasonic Technologies, Inc. Inexpensive, scalable and open-architecture media server
WO2001041000A1 (en) * 1999-11-30 2001-06-07 New Media Technology, Corp. System and method for computer-assisted manual and automatic logging of time-based media
EP1193920A2 (en) * 2000-09-29 2002-04-03 Microsoft Corporation Improved media streaming methods and arrangements

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2323390A2 (en) * 2008-09-04 2011-05-18 Sk Telecom Co., LTD Media transmission system and method
CN102144390A (en) * 2008-09-04 2011-08-03 Sk电信有限公司 Media transmission system and method
EP2323390A4 (en) * 2008-09-04 2012-03-21 Sk Telecom Co Ltd Media transmission system and method
US8549164B2 (en) 2008-09-04 2013-10-01 Sk Planet Co., Ltd. Media transmission system and method
EP3169065A1 (en) * 2008-09-04 2017-05-17 SK Planet Co., Ltd. Media transmission system and method
EP3169066A1 (en) * 2008-09-04 2017-05-17 SK Planet Co., Ltd. Media transmission system and method

Also Published As

Publication number Publication date
SE520246C2 (en) 2003-06-17
AU2002365744A1 (en) 2003-06-17
SE0104114D0 (en) 2001-12-06
SE0104114L (en) 2003-06-07

Similar Documents

Publication Publication Date Title
US7548948B2 (en) Client-side caching of streaming media content
US10277956B2 (en) Method and apparatus for streaming digital media content and a communication system
USRE48360E1 (en) Method and apparatus for providing trick play service
CN101107828B (en) Method and system for broadcasting multimedia data
CA2965484C (en) Adaptive bitrate streaming latency reduction
JP5894220B2 (en) Video distribution system including progressive playback
JP4313268B2 (en) A VCR-like feature that renders video on demand
KR20040098119A (en) Http-based video streaming apparatus and method for a mobile communication system
CN107071511B (en) Method and computer system for providing rewinding of broadcast video stream received by client
CN100551043C (en) A kind of method of fast forwarding and fast rewinding playing video data and streaming media server
US5771335A (en) Fast forward/reverse travel controlling method for video on demand system
US7558760B2 (en) Real-time key frame generation
RU2551111C2 (en) Apparatus and method for downloading movie file
CN109348251B (en) Method and device for video playing, computer readable medium and electronic equipment
EP2046044A1 (en) A method and apparatus for streaming digital media content and a communication system
US20110191803A1 (en) Trick Mode Support for VOD with Long Intra-Frame Intervals
US20090049491A1 (en) Resolution Video File Retrieval
KR20070020727A (en) Apparatus and method of using pseudo streaming download with partially progressive download in terminal
US10277927B2 (en) Movie package file format
US8886765B2 (en) System and method for predicitive trick play using adaptive video streaming
RU2598805C2 (en) Method for dynamic adaptation of repetition frequency of bits when receiving and appropriate receiver
WO2004015550A2 (en) Data streaming system and method
JP4315914B2 (en) Image reproducing apparatus and image reproducing method
CN1765103B (en) Transmitting over a network
WO2018014546A1 (en) Method and device for processing video data

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 OM PH PL PT RO RU SD SE SG SI SK SL TJ TM TN TR TT TZ UA UG US UZ VC VN YU ZA ZM 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 BG CH CY CZ DE DK EE ES FI FR GB GR IE IT LU MC NL PT SE SK TR BF BJ CF CG CI CM GA GN GQ 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
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