EP0916217A2 - Procede et appareil informatique pour l'enregistrement et la lecture d'objets en continu - Google Patents

Procede et appareil informatique pour l'enregistrement et la lecture d'objets en continu

Info

Publication number
EP0916217A2
EP0916217A2 EP97926667A EP97926667A EP0916217A2 EP 0916217 A2 EP0916217 A2 EP 0916217A2 EP 97926667 A EP97926667 A EP 97926667A EP 97926667 A EP97926667 A EP 97926667A EP 0916217 A2 EP0916217 A2 EP 0916217A2
Authority
EP
European Patent Office
Prior art keywords
objects
client
server
processor
request
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.)
Withdrawn
Application number
EP97926667A
Other languages
German (de)
English (en)
Inventor
Scott A. Kliger
Thomas M. Middleton, Iii
Gregory T. White
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.)
Narrative Communications Corp
Original Assignee
Narrative Communications Corp
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 Narrative Communications Corp filed Critical Narrative Communications Corp
Publication of EP0916217A2 publication Critical patent/EP0916217A2/fr
Withdrawn legal-status Critical Current

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/40—Network security protocols

Definitions

  • Distributed computing makes use of a computer network formed out of one or more computers loosely coupled together to allow processes on different computers to communicate with each other and to provide services for each other.
  • client-server model One of the most common paradigms of distributed computing is known as the "client-server model", in which consumers of services are called
  • servers make requests of service providers, called “servers”.
  • object oriented distributed computing there is a notion of computer entities called "objects".
  • Each object comprises a particular state and a set of defined behaviors.
  • the state is represented by data maintained by the object.
  • the behavior is specified in terms of operations that the object can perform with the operations, typically realized by executable code.
  • the data and the code are inextricably bound together in the object.
  • Objects may be "persistent", that is, they may continue to exist even though they are inactive or the computer on which they exist has failed or has been turned off. Further, objects may issue requests for services to other objects as well as supply services.
  • data is held in linear files on a server. When a client requests that data or a part thereof, a connection is formed between the data source (server) and delivery (client) point.
  • the first typically stores data files of a number of different types.
  • Web servers typically communicate with clients over a network such as the Internet using the well known TCP/IP protocol.
  • the second type of server known as a streaming media server, stores and transmits media files of various types.
  • HTML Hyper Text Markup Language
  • HTML permits the web servers to handle container files which reference other files of varying formats.
  • a given web document may include content information in various formats and may also refer to other files by including reference information known as a Uniform Reference Locator (URL).
  • URL's specify the location of remote servers at which files referenced in the HTML file may be located.
  • a client Upon receipt of an HTML file from the original web server, a client then must access each document referenced from its source. Each such request typically requires a full cycle of communication with a remote server, including opening a connection socket with the remote server, requesting that the file be transferred, waiting for the file to download, closing the connection, and then, finally parsing the file. To render a given web page may therefore require many such cycles.
  • the other type of server known as a streaming media server
  • Such servers may handle single data types, such as a RealAudioTM file, or may include mixed media types, in formats such as NetShowTM (RealAudioTM is a trademark of Progressive Networks, Inc., and NetShowTM is a trademark of Microsoft Corporation) .
  • NetShowTM RealAudioTM is a trademark of Progressive Networks, Inc.
  • media files are typically laid out in a linear fashion in a single file.
  • a socket is simply opened and delivery of data is begun.
  • the client may perform a caching or buffering operation prior to actual play back of the media file. This ensures that the media file is played back to the user of the client computer in a continuous stream.
  • the client may calculate in advance an amount of data that it must have on hand prior to actually beginning to render the media file, so that the user has an impression of continuous delivery of the media.
  • files may be formatted in advance with a specific communication transfer bandwidth in mind.
  • a Real Audio file may have been compressed for receipt at a baud rate such as 14.4 kilo bits per second (kbps) .
  • Another file would be made available for optimum playback at 28.8 kbps.
  • These different file formats provide for allowances in playing back data such that it is rendered in a continuous fashion at the respective rates.
  • streaming media server the connection remains open with the server during the full duration of the play back of the file.
  • the connection will remain open for ten minutes, even though the available information transfer rate on a Tl line is much greater than the audio bandwidth.
  • streaming media servers typically implement a lossy type of compression algorithm.
  • bits may be dropped and the quality of the presentation is adversely affected.
  • the content must typically be specific to each type of client at the targeted bit rate.
  • the streaming media server is occupied for the real time duration of the media clip, and the presentation may experience degradation based upon the amount of latency in the network.
  • the present invention rather than interpreting container objects that contain references to other objects that must be retrieved by the client opening multiple connections with various servers, and rather than specifying the streaming of data in a single access request, the present invention provides for transmission of data as a stream of objects.
  • the client in response to a user or application request for a file, issues a request for the file in the form of a sequence of desired objects.
  • the request is presented to the server as a single request that includes a list of multiple objects to be returned to the client.
  • the request is pulled together according to what the client has requested.
  • the requested objects are then sent together in a single stream to the client.
  • the server analyzes the request to locate the particular objects.
  • Objects that are available locally to the server are simply added to the outgoing stream, however, the server may also need to query back end file servers and other sources for objects that may be located at other computers in the network. The server then assembles these objects together and provides them to the client in a single object stream.
  • the server may analyze the reqeust and assemble objects based upon a predefined order, such as specified by an object map file located at the server.
  • the server may assemble objects "on-the-fly", based upon client- specific criteria.
  • the present invention thus also permits the mixture of different objects in an object stream, depending upon the particular client or client request.
  • the assembly of object streams may thus occur dynamically based upon any number of client-specific criteria, such as the objects already available to the client, the communication channel bandwidth, the desired presentation quality, client buffer capability, or other parameters associated with the client or the communications channel.
  • the server may maintain a log of objects already sent to the client, and send only those objects which are not already available at the client computer.
  • the client may also specify an object class together with information that enables the server to determine which member object of the class is to be placed in the stream.
  • Such information may include the communication bandwidth, graphical resolution, physical location, or other information which varies from client to client.
  • the server may also send objects of a particular quality targeted to particular clients. The selection of objects may depend upon client parameters such as observed network latency in real time or desired object quality.
  • the system may also include buffering, so that the rendering of the set of objects may be delayed until a sufficient amount of data is received at the client.
  • Fig. 1 is a block diagram of a computer network employing the present invention.
  • Fig. 2 is a schematic flow diagram of one embodiment of the present invention.
  • Fig. 3 illustrates how a server dynamically assembles an object stream in response to a client request.
  • FIG. 1 Illustrated in Fig. 1 is a block diagram of a general computer network 21.
  • a plurality of computers 13, 15, 17 are coupled across a communication channel 11 for communication amongst each other.
  • Various subsets of the computers may themselves form a local area network (LAN) or other local network 13, 15.
  • LAN local area network
  • Each of the various local networks are coupled through a respective router 12a, 12b to channel 11. This enables communication from one local network to another across the channel 11 to form what is known as an "internet".
  • the present invention is employed on what has become known as the Internet (an international computer network linking an estimated 35 million people to approximately 4.8 million host computers or information sources) .
  • the computers 13, 15, 17 or digital processors employing the present invention are of the PC or mini computer type, or the like, having processing capabilities of the Intel XX386 processing chip or better.
  • the communication channel 11 is a typical telephone line or other transmission/communication cable handling a 28,800 baud data rate or the like.
  • a sequence of steps are undertaken by the computers 13, 15, 17 to transfer data in the form of a stream of objects according to the present invention.
  • a given client computer 13a may issue a request for computer data to another computer 17, which acts as a server.
  • the client 13a is a computer that executes an application (or other user interaction) for which certain data needs to be made present.
  • the client receives an object stream request from the application that includes a global identification of an object map which indicates certain objects existing in the network 21 that the client application program seeks.
  • the object stream request includes a list, or linear sequence of objects identified a global object identification number.
  • the client 13a transmits the initial request to the server 17, which enters state 200 to transfer back a global identification of the object map listing subject objects.
  • the client next determines whether the object map is stored locally.
  • the client 13a checks multiple local memories such as hardware caches, working memory, CD-Rom's and local network memories for the object map in state 108.
  • the client analyzes the object map. If the object map is not found locally, then the client requests the object map from the server in state 106.
  • the server enters states 202, 203 and 204 to (i) initialize a log of object identifications for this client, (ii) initialize a steady state connection with the client, and (iii) transmit the object map identified by the client 13a.
  • the client 13a then analyzes the object map in state 108. This is accomplished by the client processing each object referred in on the object map, as indicated by the analyze loop of states 110,112 and 114.
  • the client For each such object, the client first determines, in state 110, whether the object is in local cache. If not, then the client 13a adds the identification of the object to a request block. As long as the block is not full, this loop continues with the client adding an identification of each object not found in local cache in state 112.
  • the client transmits a request to the server for the block of objects as a list of object identifications.
  • the server 17 Upon receipt of this request (i.e., a block of object indentifications) , the server 17 then initiates the assembly of a data stream and compiles the stream of objects based on (i) the sequence of requested objects and/or (ii) quality of the objects.
  • the server constructs blocks of objects to form the data stream, in states 206 through 214.
  • the server 17 maintains a log of objects being transmitted to fulfill the client's request. Specifically, in states 206 and 208, for each object in the block, the server 17 first determines from the log whether the object has previously been transmitted to the particular client 13a. If so, the server 17 ' enters state 214 to prevent that object from being placed in the current block. Therefore, states 110 and 212 are entered only for the objects that the client is actually in need of. In state 210, then, the server only fetches objects from remote servers which are actually needed by the client 13a. This provides a significant performance advantage, especially where the objects must be obtained elsewhere in the network 21. As such, the server 17 constructs blocks of data and hence compiles the stream of data for the client 13a in real time, i.e., on the fly, without duplication of any one object throughout the total data stream.
  • the client 13a receives the object stream in state 116. More accurately, the data of the object is then delivered to the requesting application of the client for further processing and use.
  • an object streaming type communication from the server 17 to client 13a is performed.
  • a request for a sequence of non-local objects is made by the client 13a and transmitted to the server 17.
  • the server 17 initializes a log of objects according to object identifications, and then fulfills the request for objects by transmitting the requested objects, in sequence order, which have not previously been transmitted to that client 13a as indicated by the log.
  • the objects may be computer data structures of various types and formats.
  • the objects may, for example, be compiled in any number of ways within the object oriented computing model well known in the art.
  • objects may include text, graphics, audio, video, and other types of digitized information.
  • objects may be complete data files or only portions of such files.
  • the objects themselves may be classes that consist of a number of objects grouped together. The object request must then typically include information to specify which member of the object class is desired by the client 13a.
  • an object class may consist of various versions of a particular graphic object.
  • the selected version may depend upon the desired quality of the final graphical rendering of the object desired by the client computer 13a. Quality may also have other meaning such as bandwidth, graphical resolution, number of colors, available client memory cache size, and other class criteria that depend upon the type of client computer 13a.
  • object classes may depend upon various other client-specific information such as domains, for example. In this scenario, when the client computer 13a is located in one area of the country, such as Massachusetts, a different object may be returned than when the client 13b is located in California, although each of the clients 13a, 13b actually requested the same global object.
  • Fig. 3 is a diagram illustrating how an example object stream 300 may be assembled by the streaming servers 17, and in particular showing how the object stream does not have to originate from a single source or a single file.
  • the client 13a requests and receives a particular object map 301 consisting of a list of object identifications such as the list (IDl,ID4,ID7,ID6,ID2, ID3) , where each object identification IDx indicates a global address for a particular object.
  • the client 13a first creates a request block 302 taking into account any local objects 303 which it may already have available. In the particular illustrated example, the client 13a already has local objects (Ol, 06) available locally.
  • the request block 302 is sent to the streaming server 17.
  • Streaming server 17 receives the request block 302 and then assembles a stream block 310a for the client 13a. It should be understood that other stream blocks 310b may also be constructed for other clients 13b at the same time as the block being constructed for client 13a.
  • the server 17 typically has a default data stream order regardless of user interaction on the client 18 side.
  • the server 17 may have available certain information concerning the client. Because the server 17 may compose the data stream on-the- fly, the default stream order may be changed in accordance with prior history of requests made on the server 17. That is, on the server processor, an analysis of multiple prior usage of server objects by other clients is made. The server 17 changes the default objects stream 300 order to the closest substitution (i.e., object map) based on demographics of clients 13a having prior server data/object usage. To accomplish such an analysis, a neural network may be employed. In yet another modification, the streaming server 17 may create the stream block 310a from information that is known about the specific client 13a.
  • the server 17 may maintain a log 311a of objects that have already been provided to client 13a as well as any available local objects 312 local to the server 17.
  • the log 31la indicates objects (ID1,ID6) as already having been provided to client 13a.
  • the available local objects 312 include (04,012) .
  • a particular object such as object 04 may actually consist of a class definition, as illustrated, wherein a number of objects comprise the class.
  • object 04 here is actually an object class (04a,Ob4, ...04x) .
  • the streaming server 17 thus also receives together with the object identification request block 302 information as to which particular member of class 04 is appropriately provided to the client 13a.
  • the streaming server 17 then assembles the stream block 310a as illustrated, which includes all of the objects that the client 13a has requested. In the illustrated example this includes objects (04a, 07, 02, 012, 03) . After assembly of the stream block 310a the streaming server 17 then provides the stream block 310a as a single object stream 300 to the client 13a.
  • the streaming server 17 may not have all the necessary objects available in the local object list 312. In such instances the streaming server 17 must query other remote server computers 15a, 15b connected to the network 21 in order to locate the objects. This is done in a manner which is well known in the art by the streaming server 17 making requests of the remote computers 15a, 15b to provide their respective objects that they have made available. In Fig. 3, objects (07, 02, 04) are located at computer 15a and object (03) at computer 15b.
  • An identical object map may be operated on in a different manner by server 17 for client 13b.
  • the object map 301b is the same as the objects map 301a, because a different list of object 303b is available to client 13b, the request block 302b created by client 13b will have different object identification numbers (ID4, ID6, ID3) .
  • the client parameter(s) provided with the request block by client 13b may very well be different for that provided by client 13a.
  • an object of a particular quality may be targeted to client 13b which is different than as that supplied to client 13a. For example, when clients 13a and 13b request that object 04 be provided to them, client 13a may actually receive object 04a and client 13b may receive object 04b, despite the fact that the reference 04 was a common global object identification.
  • the object classes may also be defined as bandwith selectable objects.
  • the resulting data stream 300 may be assembled based upon observed client bandwidth availability. Therefore, depending on a periodically calculated data transfer rate, the client 13a or server 17 may choose to request or transmit a data stream of different objects. That is, for a given requested object 04, a specific version 04a, 04b...04x may be selected for transfer from the server 17 to the client 13a as a function of available bandwidth. This function is termed "bandwidth scalability" of the object stream.
  • object specific compression is provided by the server, such that on an object by object basis, the object data stream 300 may be compressed one object at a time depending upon client criteria.
  • the server 17 determines which compressed object version to include in the object data stream 300 at the time of compilation.
  • the client 13a also manages the amount of data being delivered, i.e., throughput to a client 13a. In particular, this is useful to determine whether there is enough data being timely transferred; that is, whether data is being consumed on the client 13a end faster than the server 17 is delivering the requested objects.
  • the client 13a builds a map of uncompressed data consumption.
  • the map tells how fast data is being consumed (used by the client 13a application) .
  • the client measures the throughput (client receipt) of data in real time and contrasts that with the formulated map. Based on the comparison, the client 13a is able to determine how much of the object stream data 300 should be read by a buffer 320a at a time.
  • the client 13a effectively maps the physical compressed object data stream 300 and logical consumption of data at each point in time.
  • the client 13a continually monitors the real data throughput versus data consumption.
  • the client 13a wants the delivery-to-consumption ratio to be greater than one so that the throughput (supply) is keeping up with the consumption (demand) .
  • the delivery-to-consumption ratio is less than one, there is more data being consumed than the amount of data being delivered, such that there is a so-called "buffer debt" on the client 13a side.
  • the transmission of data needs to take advantage of pause points in the object data stream 300, so that for a period of time, data is not being transmitted over the communication channel 11.
  • the buffer 320a is allowed to fill up with the requested data and thus decrease or solve the "buffer debt", to assist with proper real time delivery of objects.
  • the pause points may be pre-defined by the author of the object content, or the pause points may be determined on the fly in accordance with the client's ability to consume data.
  • this latter implementation is accomplished as follows.
  • the client 13a at each time point, t computes object data consumption.
  • a running average of throughput such as number of bytes received divided by total time in seconds is employed.
  • An adaptive running average or weighted average or the like may also be used to compute the data consumption. This is also known as the physical throughput at a given time, i, (i.e., (ptj .
  • the total logical data (tld) optimally needed at a point in time t is calculated as follows:
  • the client 13a then calculates the buffer debt from time to time. For a buffer debt greater than 0 the client calculates a maximum wait time
  • the client 13a will then wait a minimum of the maxwait time or the maximum time allowed at that wait point. For a buffer debt of less than zero, the server 17 transmission of data is ahead of the consumption and thus no pausing during the transmission of the object data stream 300 is warranted.
  • the log maintained by the server 17 for preventing duplication of objects in the transmitted object data stream 300 to the requesting client may be implemented with tables, cache memory and the like.
  • caching a sparse representation of the most recent transmitted objects is maintained in the log.
  • Other caching or log implementations are suitable and are understood to be in the purview of one skilled in the art.
  • Another example is the term "local to the client". "Local" means in various memories including hard drives, cache memories, CD's and other working memories in the local network involving the client 13a.

Abstract

Dans un environnement DCE, un flux de données est formé d'une séquence d'objets demandés. L'ordre défini de la séquence d'objets est déterminé en fonction de la demande de données du client. L'ordre peut être un ordre par défaut ou, dans une variante, le serveur peut déterminer l'ordre en suivant les critères du client. Le serveur (17) peut, par exemple, rechercher des objets déjà transmis au client (13) dans le flux afin d'éviter le dédoublement d'objets. Dans d'autres cas, le serveur peut choisir un objet dans une classe d'objets en fonction de la qualité de l'objet, de sa largeur de bande, de l'emplacement du client et d'autres critères spécifiques au client. Le serveur compile et transmet le flux de données objet en temps réel ('à la volée') sur la base de ces critères. Le client assure la mise en mémoire tampon des données et les pauses nécessaires pour rectifier la dette de la mémoire tampon.
EP97926667A 1996-05-24 1997-05-22 Procede et appareil informatique pour l'enregistrement et la lecture d'objets en continu Withdrawn EP0916217A2 (fr)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US1825696P 1996-05-24 1996-05-24
US18256P 1996-05-24
PCT/US1997/008679 WO1997044942A2 (fr) 1996-05-24 1997-05-22 Procede et appareil informatique pour l'enregistrement et la lecture d'objets en continu

Publications (1)

Publication Number Publication Date
EP0916217A2 true EP0916217A2 (fr) 1999-05-19

Family

ID=21787022

Family Applications (1)

Application Number Title Priority Date Filing Date
EP97926667A Withdrawn EP0916217A2 (fr) 1996-05-24 1997-05-22 Procede et appareil informatique pour l'enregistrement et la lecture d'objets en continu

Country Status (4)

Country Link
EP (1) EP0916217A2 (fr)
AU (1) AU3137897A (fr)
CA (1) CA2256417A1 (fr)
WO (1) WO1997044942A2 (fr)

Families Citing this family (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20060195595A1 (en) 2003-12-19 2006-08-31 Mendez Daniel J System and method for globally and securely accessing unified information in a computer network
US6219694B1 (en) * 1998-05-29 2001-04-17 Research In Motion Limited System and method for pushing information from a host system to a mobile data communication device having a shared electronic address
US6463463B1 (en) 1998-05-29 2002-10-08 Research In Motion Limited System and method for pushing calendar event messages from a host system to a mobile data communication device
US7047309B2 (en) 2000-08-23 2006-05-16 International Business Machines Corporation Load balancing and dynamic control of multiple data streams in a network
US6772217B1 (en) 2000-08-23 2004-08-03 International Business Machines Corporation Internet backbone bandwidth enhancement by initiating an additional data stream when individual bandwidth are approximately equal to the backbone limit
US6766376B2 (en) 2000-09-12 2004-07-20 Sn Acquisition, L.L.C Streaming media buffering system
WO2002052798A2 (fr) 2000-12-22 2002-07-04 Research In Motion Limited Systeme de routeur sans fil et procede
CA2410118C (fr) 2001-10-26 2007-12-18 Research In Motion Limited Systeme et methode de surveillance des reglages de configuration pour dispositifs et services de communication mobile
CN100366025C (zh) 2001-12-07 2008-01-30 捷讯研究有限公司 从主服务到移动台分布信息的方法
US20080261633A1 (en) 2002-10-22 2008-10-23 Research In Motion Limited System and Method for Pushing Information from a Host System to a Mobile Data Communication Device
US8365240B2 (en) 2005-04-18 2013-01-29 Research In Motion Limited Method for providing wireless application privilege management
US8179872B2 (en) 2007-05-09 2012-05-15 Research In Motion Limited Wireless router system and method
CN102810065B (zh) 2011-05-31 2016-04-27 国际商业机器公司 用于加载程序模块的方法和系统

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5452299A (en) * 1993-10-14 1995-09-19 Intel Corporation Optimized transfer of large object data blocks in a teleconferencing system
DE69525556T2 (de) * 1994-03-21 2002-09-12 Avid Technology Inc Gerät und Verfahren ausgeführt auf einem Rechner für Echtzeit Multimedia Datenübertragung in einer verteilten Rechneranordnung
US5541638A (en) * 1994-06-28 1996-07-30 At&T Corp. User programmable entertainment method and apparatus

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See references of WO9744942A3 *

Also Published As

Publication number Publication date
AU3137897A (en) 1997-12-09
WO1997044942A3 (fr) 1997-12-31
CA2256417A1 (fr) 1997-11-27
WO1997044942A2 (fr) 1997-11-27

Similar Documents

Publication Publication Date Title
US7941554B2 (en) Sparse caching for streaming media
CN106878315B (zh) 可变速率媒体传送系统
JP4972409B2 (ja) ノード及びネットワークの特性を考慮したサービスロケーション管理を行うためのシステム
US7197570B2 (en) System and method to send predicted application streamlets to a client device
US7529806B1 (en) Partitioning of MP3 content file for emulating streaming
US7054911B1 (en) Streaming media bitrate switching methods and apparatus
JP3994057B2 (ja) エッジ・サーバ・コンピュータを選択する方法およびコンピュータ・システム
US5956729A (en) Multimedia file, supporting multiple instances of media types, and method for forming same
EP0961490A2 (fr) Serveur audio/vidéo Internet convolution
US8086750B2 (en) Method and system for delivering content over a network
US20040024900A1 (en) Method and system for enhancing streaming operation in a distributed communication system
WO1997044942A2 (fr) Procede et appareil informatique pour l'enregistrement et la lecture d'objets en continu
JP2009032270A (ja) メディアデータの利用を測定し、レポートするシステム
US7797441B1 (en) Methods and systems for streaming advertising content
JP4958951B2 (ja) コンテンツ収集
WO2001014981A1 (fr) Systeme et procede permettant de fournir la livraison d'un contenu audio/video sur un reseau
EP1627500B1 (fr) Gestion de service au moyen d'une pluralite de gestionnaires de localisation de service
US20020147827A1 (en) Method, system and computer program product for streaming of data
EP1627497B1 (fr) Systèmes et procédés dans lesquels un fournisseur est sélectionné pour la réalisation d'un service sur un contenu demandé par un dispositif client
US20040237097A1 (en) Method for adapting service location placement based on recent data received from service nodes and actions of the service location manager
EP1625724B1 (fr) Système et procédé permettant de selectionner un fournisseur de service
KR20060113678A (ko) 멀티미디어 콘텐츠 사용자의 구성을 원격 결정하는 시스템,방법 및 컴퓨터 프로그램 제품
JP2001184252A (ja) コンピュータネットワーク上のクライアントロケーションにおける情報オブジェクトの送信および受信のための方法、装置ならびにシステム
Pañeda et al. VIDEO-ON-DEMAND ENGINEERING USING AN EXTENSIBLE METHOD
Miller Netting Web Customers

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 19981208

AK Designated contracting states

Kind code of ref document: A2

Designated state(s): AT BE CH DE DK ES FI FR GB GR IE IT LI LU MC NL PT SE

17Q First examination report despatched

Effective date: 20010511

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20010922