EP1702465A1 - Procede d'enregistrement de contenus audio-visuels dans un reseau de communication - Google Patents

Procede d'enregistrement de contenus audio-visuels dans un reseau de communication

Info

Publication number
EP1702465A1
EP1702465A1 EP04817600A EP04817600A EP1702465A1 EP 1702465 A1 EP1702465 A1 EP 1702465A1 EP 04817600 A EP04817600 A EP 04817600A EP 04817600 A EP04817600 A EP 04817600A EP 1702465 A1 EP1702465 A1 EP 1702465A1
Authority
EP
European Patent Office
Prior art keywords
content
network
recorder
command
recording
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
EP04817600A
Other languages
German (de)
English (en)
Inventor
Christian Bertin
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.)
Orange SA
Original Assignee
France Telecom SA
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 France Telecom SA filed Critical France Telecom SA
Publication of EP1702465A1 publication Critical patent/EP1702465A1/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N5/00Details of television systems
    • H04N5/76Television signal recording
    • H04N5/765Interface circuits between an apparatus for recording and another apparatus
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/41Structure of client; Structure of client peripherals
    • H04N21/414Specialised client platforms, e.g. receiver in car or embedded in a mobile appliance
    • H04N21/4147PVR [Personal Video Recorder]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/239Interfacing the upstream path of the transmission network, e.g. prioritizing client content requests
    • H04N21/2393Interfacing the upstream path of the transmission network, e.g. prioritizing client content requests involving handling client requests
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/25Management operations performed by the server for facilitating the content distribution or administrating data related to end-users or client devices, e.g. end-user or client device authentication, learning user preferences for recommending movies
    • H04N21/258Client or end-user data management, e.g. managing client capabilities, user preferences or demographics, processing of multiple end-users preferences to derive collaborative data
    • H04N21/25866Management of end-user data
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/27Server based end-user applications
    • H04N21/274Storing end-user multimedia data in response to end-user request, e.g. network recorder
    • H04N21/2747Remote storage of video programmes received via the downstream path, e.g. from the server
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43Processing 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/433Content storage operation, e.g. storage operation in response to a pause request, caching operations
    • H04N21/4334Recording operations
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/47End-user applications
    • H04N21/472End-user interface for requesting content, additional data or services; End-user interface for interacting with content, e.g. for content reservation or setting reminders, for requesting event notification, for manipulating displayed content
    • H04N21/47214End-user interface for requesting content, additional data or services; End-user interface for interacting with content, e.g. for content reservation or setting reminders, for requesting event notification, for manipulating displayed content for content reservation or setting reminders; for requesting event notification, e.g. of sport results or stock market
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/47End-user applications
    • H04N21/482End-user interface for programme selection
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/65Transmission of management data between client and server
    • H04N21/658Transmission by the client directed to the server
    • H04N21/6581Reference data, e.g. a movie identifier for ordering a movie or a product identifier in a home shopping application
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N7/00Television systems
    • H04N7/16Analogue secrecy systems; Analogue subscription systems
    • H04N7/173Analogue secrecy systems; Analogue subscription systems with two-way working, e.g. subscriber sending a programme selection signal
    • H04N7/17309Transmission or handling of upstream communications
    • H04N7/17318Direct or substantially direct transmission and handling of requests

Definitions

  • the network recorders must declare themselves in the communication network. This can be done directly through a website of the recorder or through a directory, for example UDDI (Universal Description, Discovery and Integration) associated with SOAP (Simple Object Access Protocol) exchange technology. In the latter case, the directory must create a specific section corresponding to the “Network recorders” activity and register the network recorders which have declared themselves in this directory and for this section.
  • UDDI Universal Description, Discovery and Integration
  • SOAP Simple Object Access Protocol

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Databases & Information Systems (AREA)
  • Human Computer Interaction (AREA)
  • Computer Graphics (AREA)
  • Business, Economics & Management (AREA)
  • Finance (AREA)
  • Strategic Management (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
  • Television Signal Processing For Recording (AREA)
  • Signal Processing For Digital Recording And Reproducing (AREA)

Abstract

Procédé d'enregistrement de contenus audio-visuels dans un réseau de communication. Selon l'invention, ledit réseau de communication comprenant au moins un enregistreur de réseau apte à enregistrer des contenus audio-visuels diffusés sur une pluralité de canaux de diffusion, l'enregistrement desdits contenus audio-visuels étant effectué à la demande d'un utilisateur muni d'un terminal de communication avec au moins un enregistreur de réseau, ledit procédé comporte les étapes suivantes : - pour l'enregistreur de réseau, s'identifier en indiquant au moins : * un moyen d'accès audit enregistreur, * une liste de canaux de diffusion, - pour l'utilisateur, choisir un enregistreur de réseau apte à enregistrer au moins un contenu audio-visuel souhaité et s'y connecter à l'aide dudit moyen d'accès afin de commander l'enregistrement dudit au moins un contenu audio­visuel, ladite commande comprenant une identification du contenu audio­ visuel à enregistrer, - pour l'enregistreur de réseau, émettre une réponse à la commande d'enregistrement de l'utilisateur contenant pour chaque contenu à enregistrer une identification de la commande d'enregistrement acceptée, en cas d'acceptation de la commande. Application à l'enregistrement à distance de contenus audio-visuels.

Description

PROCEDE D'ENREGISTREMENT DE CONTENUS AUDIO-VISUELS DANS UN RESEAU DE COMMUNICATION
La présente invention concerne un procédé d'enregistrement de contenus audio-visuels dans un réseau de communication. L'invention trouve une application particulièrement avantageuse dans le domaine de l'enregistrement à distance de contenus audio-visuels. On connaît de l'état de la technique des procédés d'enregistrement à distance de contenus audio-visuels diffusés par des canaux de diffusion à travers un réseau de communication qui consistent à requérir auprès d'un canal de diffusion qu'il diffuse un contenu choisi par l'utilisateur sur un enregistreur numérique personnel (PDR pour Personal Digital Recorder) situé par exemple au domicile de l'utilisateur. Le recours à de tels procédés d'enregistrement à distance est rendu nécessaire lorsque, par exemple, un utilisateur se trouvant éloigné de son domicile s'aperçoit qu'il a oublié de programmer un enregistrement sur son PDR alors qu'il était encore chez lui. L'utilisateur peut alors au moyen de son ordinateur de bureau, de son téléphone mobile ou de son assistant personnel (PDA) programmer à distance cet enregistrement par une requête auprès du canal de diffusion concerné. Cependant, s'ils répondent bien à ce type de besoin, les procédés d'enregistrement à distance connus ne permettent pas de résoudre d'autres problèmes liés à l'enregistrement de contenus audio-visuels. C'est le cas, en particulier, lorsque le canal de diffusion dont l'utilisateur souhaiterait enregistrer un contenu ne peut être reçu du fait que ce canal ne fait pas partie de l'abonnement souscrit par l'utilisateur, ou encore lorsque le récepteur de l'utilisateur ne peut recevoir un seul canal à la fois et qu'il est utilisé, par exemple par une autre personne, sur un autre canal de diffusion au moment de la diffusion du contenu que l'utilisateur souhaite enregistrer. Aussi, le problème technique à résoudre par l'objet de la présente invention est de proposer un procédé d'enregistrement de contenus audiovisuels dans un réseau de communication, qui permettrait à un utilisateur d'enregistrer des contenus audio-visuels qu'il ne peut directement enregistrer sur son récepteur, soit parce qu'ils ne peuvent être reçus sur son récepteur, soit parce que le récepteur n'est pas prévu pour recevoir plusieurs canaux de diffusion à la fois. La solution au problème technique posé consiste, selon la présente invention, en ce que, ledit réseau de communication comprenant au moins un enregistreur de réseau apte à enregistrer des contenus audio-visuels diffusés sur une pluralité de canaux de diffusion, l'enregistrement desdits contenus audio-visuels par un enregistreur de réseau étant effectué à la demande d'un utilisateur muni d'un terminal de communication apte à échanger des informations avec au moins un enregistreur de réseau à travers ledit réseau de communication, ledit procédé comporte les étapes suivantes :
- pour l'enregistreur de réseau, se déclarer dans le réseau , la déclaration indiquant au moins : * un moyen d'accès audit enregistreur, * une liste de canaux de diffusion dont les contenus audio-visuels diffusés sont aptes à être enregistrés par l'enregistreur de réseau,
- pour l'utilisateur, choisir au moyen de son terminal un enregistreur de réseau apte à enregistrer au moins un contenu audio-visuel souhaité et s'y connecter à l'aide dudit moyen d'accès afin de commander l'enregistrement dudit au moins un contenu audio-visuel, ladite commande comprenant une identification dudit au moins un contenu audio-visuel à enregistrer à choisir, séparément ou en combinaison, entre une référence unique dudit contenu et une identification d'une instance dudit contenu constituée d'au moins l'identification du canal de diffusion de ladite instance accompagnée de l'indication d'une plage horaire de diffusion, - pour l'enregistreur de réseau, émettre une réponse à la commande d'enregistrement de l'utilisateur contenant pour chaque contenu à enregistrer une identification de la commande d'enregistrement acceptée, en cas d'acceptation de la commande. Ainsi, l'utilisateur peut à tout moment depuis son PDR, mais aussi depuis son ordinateur personnel, son téléphone mobile ou son assistant personnel, commander à l'enregistreur de réseau d'enregistrer pour lui un contenu audio-visuel sur n'importe quel canal de diffusion , même ceux auxquels il n'a pas directement accès, afin de le transférer ensuite sur le récepteur de son choix (PDR, ordinateur personnel, PDA) et le regarder à un moment où le récepteur est disponible. Selon l'invention, ladite indication de plage horaire comporte l'heure de début de diffusion et l'heure de fin ou la durée de diffusion sur le canal de diffusion de ladite instance. L'invention prévoit deux moyens d'accès principaux à un enregistreur de réseau. En effet, selon un mode de réalisation, ledit moyen d'accès à un enregistreur de réseau consiste en une adresse dudit enregistreur dans le réseau, alors que, selon un autre mode de réalisation, ledit moyen d'accès à un enregistreur de réseau consiste en un annuaire comprenant une inscription des opérations particulières aux enregistreurs de réseau, chaque enregistreur de réseau étant identifié par ladite opération. De manière plus précise, selon l'invention, ladite liste des canaux de diffusion dont les contenus audio-visuels diffusés sont aptes à être enregistrés par l'enregistreur de réseau comporte l'adresse de chacun des canaux de diffusion, accompagnée optionnellement du tarif pratiqué par l'enregistreur de réseau pour chacun des canaux de diffusion. On entend par « adresse d'un canal de diffusion » un identifiant tel que codifié par un consortium rassemblant des organismes et des sociétés intéressés, comme le forum TV- Anytime. Par ailleurs, afin de permettre à l'utilisateur de recevoir dans des conditions techniques compatibles avec son récepteur l'enregistrement du contenu audio-visuel effectué par l'enregistreur de réseau, il est prévu par l'invention que la déclaration de l'enregistreur de réseau dans le réseau contient les capacités de conversion dudit enregistreur. Plus particulièrement, lesdites capacités de conversion concernent la réduction en débit et/ou le transcodage des contenus audio-visuels. Il faut également signaler que les contraintes concernant le débit et le transcodage du contenu audio-visuel émanent de l'utilisateur lui-même puisque l'invention préconise que ladite commande contient les capacités de conversion exigées par l'utilisateur pour le transfert de l'enregistrement vers son terminal. De même, selon l'invention, la déclaration de l'enregistreur de réseau dans le réseau contient les protocoles de transfert du contenu audio-visuel enregistré vers le terminal de l'utilisateur aptes à être mis en œuvre par l'enregistreur de réseau. En d'autres termes, cette disposition permet à l'utilisateur de choisir soit un mode de transfert direct, de type « streaming », soit un mode par téléchargement, en différé par rapport à l'enregistrement dans le réseau. Après avoir reçu une commande d'enregistrement, l'enregistreur de réseau fournit une réponse à l'utilisateur qui a émis la commande. Dans le cas d'un refus, la réponse de l'enregistreur de réseau à la commande d'enregistrement de l'utilisateur contient une identification de contenu refusé, en cas de pluralité de contenus commandés. De même, la réponse de l'enregistreur contient la raison du refus. Un refus peut provenir par exemple du fait que l'enregistreur de réseau n'a pas accès au contenu demandé par l'utilisateur. Dans le cas d'une acceptation de la commande, l'invention envisage plusieurs options possibles en plus de l'identification de la commande acceptée, à savoir : la réponse de l'enregistreur de réseau contient ladite référence unique du contenu audio-visuel commandé, la réponse de l'enregistreur de réseau contient l'heure de fin programmée de l'enregistrement et/ou le coût dudit enregistrement, ou encore la réponse de l'enregistreur de réseau contient la durée de conservation de l'enregistrement par l'enregistreur de réseau. Egalement, le procédé d'enregistrement, objet de l'invention, offre à l'utilisateur la possibilité de se raviser et de revoir sa commande, puisqu'il est prévu que ledit procédé comporte également les étapes consistant pour l'utilisateur à formuler une requête d'annulation d'une commande d'enregistrement acceptée ou de suppression d'un contenu enregistré par l'enregistreur de réseau, en indiquant au moins l'identification de la commande d'enregistrement acceptée. De manière à permettre à l'utilisateur de savoir à tout moment à quel stade de traitement par l'enregistreur de réseau se trouve sa commande, le procédé d'enregistrement selon l'invention comporte également les étapes consistant :
- pour l'utilisateur, en cas d'acceptation de la commande, à formuler vers l'enregistreur de réseau une requête sur l'état de la commande d'enregistrement en indiquant au moins ladite identification de la commande d'enregistrement acceptée,
- pour l'enregistreur de réseau, à émettre une réponse à la requête sur l'état de la commande d'enregistrement contenant au moins l'identification de la commande d'enregistrement acceptée et l'état de la commande. De préférence, ladite requête sur l'état de la commande d'enregistrement contient ladite référence unique du contenu et/ou l'identification de l'utilisateur. Selon les situations, la réponse de l'enregistreur à la requête sur l'état de la commande peut prendre plusieurs formes : - la réponse à la requête sur l'état de la commande d'enregistrement contient, en cas de commande non encore exécutée, la référence unique du contenu et/ou la date et l'heure de fin programmée. - la réponse à la requête sur l'état de la commande d'enregistrement contient, en cas de commande inconnue, la référence unique du contenu. - la réponse à la requête sur l'état de la commande d'enregistrement contient, en cas d'échec de la commande, la référence unique du contenu. - la réponse à la requête sur l'état de la commande d'enregistrement contient, lorsque le contenu est disponible, une adresse où le contenu enregistré est disponible. Dans ce dernier cas, la réponse contient la référence unique du contenu et/ou la durée de conservation de l'enregistrement par l'enregistreur de réseau. La description qui va suivre en regard des figures annexées, données à titre d'exemples non limitatifs, fera bien comprendre en quoi consiste l'invention et comment elle peut être réalisée. La figure 1 est un organigramme général du procédé d'enregistrement selon l'invention. La figure 2 est un organigramme du procédé d'enregistrement selon l'invention dans le cas d'une commande d'enregistrement réussie. La figure 3 est un organigramme du procédé d'enregistrement selon l'invention dans le cas d'une commande d'enregistrement refusée. La figure 4 est un organigramme du procédé d'enregistrement selon l'invention dans le cas d'une commande d'enregistrement réussie avec délai supplémentaire. La figure 5 est un organigramme du procédé d'enregistrement selon l'invention dans le cas d'une commande d'enregistrement réussie suivie d'une annulation. La figure 6 est un organigramme du procédé d'enregistrement selon l'invention dans le cas d'une commande d'enregistrement réussie suivie d'un échec d'enregistrement. La figure 7 est un organigramme du procédé d'enregistrement selon l'invention dans le cas d'une commande d'enregistrement inconnue. Sur la figurel est représenté de manière générale un organigramme d'un procédé d'enregistrement de contenus audio-visuels (AV) dans un réseau de communication. Ce procédé implique au moins un enregistreur de réseau, correspondant à la partie droite de la figure 1 , apte à enregistrer des contenus audio-visuels diffusés sur des canaux de diffusion. Les enregistreurs de réseau sont des opérateurs qui offrent à des utilisateurs la possibilité d'enregistrer à leur place et pour leur compte des contenus audio-visuels qu'ils ne peuvent enregistrer eux-même du fait par exemple qu'il ne leur est pas possible, par faute d'abonnement adéquat, d'accéder au canal de diffusion diffusant le contenu AV recherché ou encore du fait que leur récepteur est déjà utilisé par une autre personne sur un autre canal de diffusion. Les enregistreurs de réseau peuvent être des opérateurs spécialisés dans ce type de service ou les canaux de diffusion (chaînes de télévision) eux-même. L'enregistrement d'un contenu audio-visuel par l'enregistreur de réseau est effectué à la demande d'un utilisateur, correspondant à la partie gauche de la figure 1 , muni d'un terminal apte à échanger des informations concernant la commande d'enregistrement avec des enregistreurs de réseau à travers un réseau de communication. Dans un premier temps, les enregistreurs de réseau doivent se déclarer dans le réseau de communication . Ceci peut se faire directement à travers un site Web de l'enregistreur ou par l'intermédiaire d'un annuaire, par exemple UDDI (Universal Description, Discovery and Intégration) associé à la technologie d'échange SOAP (Simple Object Access Protocol). Dans ce dernier cas, l'annuaire doit créer une rubrique particulière correspondant à l'activité « Enregistreurs de réseau » et y inscrire les enregistreurs de réseau qui se seront déclarés dans cette annuaire et pour cette rubrique. La déclaration de chaque enregistreur de réseau de son existence dans le réseau (structure de données <TV_Record_Service_Declaration>) indique : - de préférence, une adresse de l'enregistreur de réseau (élément <RecordServiceAddress>) que ce soit celle d'un site Web ou d'une une rubrique d'annuaire, il s'agit de l'adresse à laquelle la commande d'enregistrement devra être envoyée, - de préférence, la liste des canaux de diffusion qu'il peut enregistrer (élément <DeliveryServiceList>) pouvant contenir pour chaque canal : * de préférence, l'adresse du canal de diffusion telle que définie, par exemple, par le forum TV Anytime (attribut "serviceURL"), * optionnellement, le tarif pratiqué par l'enregistreur pour ce canal de diffusion (élément <ChargingPolicy>), - optionnellement, les capacités de conversion de l'enregistreur (élément <ConversionCapabilities>) qui se décomposent en : * possibilité de réduction en débit (élément <BitrateConversionCapability>), passage de 4 à 2 Mbits par exemple. * possibilité de transcoder les contenus audiovisuels (élément <TranscodingCapability>) dans différents formats de codage audiovisuel, tel que le transcodage MPEG2 en MPEG4. - optionnellement, les protocoles supportés pour le transfert du contenu AV une fois l'enregistrement effectué vers le récepteur de l'utilisateur : mode FTP, « streaming » ou téléchargement différé. Corrélativement, l'utilisateur doit être en mesure de découvrir l'existence des enregistreurs de réseau de manière à pouvoir sélectionner celui qui sera susceptible d'enregistrer le contenu AV souhaité dans les meilleures conditions techniques, économiques et ergonomiques. Ceci peut se faire : - soit par la définition d'un type MIME (Multipurpose Internet Mail Extensions) particulier (ex. : "application/x-TV-Record-Service-Declaration"), ce qui permet à la réception d'un fichier de ce type, en provenance d'un site Web, d'activer sur le récepteur de l'utilisateur un logiciel d'interprétation de la structure de données <TV_Record_Service_Declaration> définie ci-dessus, - soit par l'utilisation d'un annuaire UDDI avec la définition d'un nouveau "tModel" pour les services d'enregistrement de contenus audiovisuels permettant à tout enregistreur de déclarer son existence et ses capacités à cette annuaire par la structure de données <TV_Record_Service_Declaration> définie ci-dessus. Après avoir choisi, à partir d'un site Web ou d'un annuaire, l'enregistreur de réseau qui lui convient le mieux pour l'enregistrement du contenu AV souhaité, l'utilisateur adresse à cet enregistreur une commande d'enregistrement (structure de données <TV_Record_Service_Request>) comprenant : - de préférence, l'identification de l'utilisateur (attribut <Userld>) si ce dernier n'a pas été identifié d'une autre manière comme par exemple au moment de sa connexion avec l'enregistreur (connexion du type identifiant- mot de passe), - de préférence, une identification du contenu AV à enregistrer qui peut être : * soit une référence unique dudit contenu (attribut "CRID"), essentiellement une simple identification du contenu en tant que tel, * soit l'identification faite par l'utilisateur lui-même d'une instance de ce contenu constituée de : . de préférence, l'identification du canal de diffusion (attribut "serviceURL"), . de préférence, l'heure de début (attribut "start"), . de préférence, l'heure de fin (attribut "end") ou la durée (attribut "duration"), optionnellement, l'identification d'une instance particulière (attribut "instanceMetadatald"). - optionnellement, les capacités de conversion exigées par l'utilisateur. La réponse de l'enregistreur de réseau à la commande d'enregistrement de l'utilisateur (structure de données
<TV_Record_Service_Request_Response>) contient pour chaque contenu à enregistrer : - soit une acceptation de la commande d'enregistrement (élément <RecordRequestSuccess>) contenant : * de préférence, l'identification de la commande d'enregistrement acceptée (attribut "requestld"), * optionnellement, l'identification du contenu demandé (attribut "CRID"), * optionnellement, l'heure de fin programmée d'enregistrement (attribut "recordEndTime"), * optionnellement, la durée de conservation du contenu enregistré (attribut "keepDuration"), * optionnellement, le coût de l'enregistrement (attributs "recordCost" et "currency"). - soit un refus de commande d'enregistrement (élément <RecordRequestFailure>) contenant : * de préférence, l'identification du contenu demandé (attribut "CRID' * optionnellement, la raison du refus (attribut "KOreason"). En cas d'acceptation de sa commande, l'utilisateur peut suivre l'état de sa commande d'enregistrement (structure de données
<TV_Record_Request_Status_Request>) en indiquant : - de préférence, l'identification de la commande d'enregistrement acceptée (attribut "requestld"), - optionnellement, l'identification du contenu à enregistrer (attribut "CRID"), - optionnellement, l'identification de l'utilisateur (attribut <Userld>). A cette requête sur l'état de la commande, l'enregistreur de réseau émet une réponse (structure de données
TV_Record_Request_Status_Response>) contenant : - en cas de commande non encore exécutée : * de préférence, l'identification de la commande d'enregistrement acceptée (attribut "requestld"), * de préférence, l'état de la commande (attribut "status", valeur "runnningRequest"), * optionnellement, l'identification du contenu à enregistrer (attribut "CRID"), * optionnellement, la date et l'heure de fin programmée (attribut "callAfter"). - en cas de commande inconnue (l'attribut « requestlD » n'est pas reconnue) : * de préférence, l'identification de la commande d'enregistrement acceptée (attribut "requestld"), * de préférence, l'état de la commande (attribut "status", valeur "unknownRequest"), * optionnellement, l'identification du contenu à enregistrer (attribut "CRID"). - en cas de commande terminée sur échec (cas d'une panne par exemple) : * de préférence, l'identification de la commande d'enregistrement acceptée (attribut "requestld"), * de préférence, l'état de la commande (attribut "status", valeur "failedRequest"), * optionnellement l'identification du contenu à enregistrer (attribut "CRID"). - en cas de commande terminée avec contenu disponible : * de préférence, l'identification de la commande d'enregistrement acceptée (attribut "requestld"), * de préférence, l'état de la commande (attribut "status", valeur "contentAvailable"), * de préférence, le moyen de récupérer le contenu enregistré (attribut "contentURL"), * optionnellement, l'identification du contenu à enregistrer (attribut "CRID"), * optionnellement, la durée de conservation du contenu enregistré dans l'enregistreur (attribut "keepDuration"). L'utilisateur dispose également de la faculté, s'il change d'avis, de requérir l'annulation de sa commande d'enregistrement (structure de données <TV_Record_Request_Cancel>) en indiquant : - de préférence, l'identification de la commande d'enregistrement acceptée (attribut "requestld"), - optionnellement, l'identification du contenu à enregistrer (attribut "CRID'1), - optionnellement, l'identification de l'utilisateur (attribut <Userld>). L'utilisateur peut aussi demander la suppression d'un contenu AV déjà enregistré dans le réseau (structure de données
<Recorded_Content_Delete>) en indiquant : - de préférence, l'identification de la commande d'enregistrement acceptée (attribut "requestld"), - optionnellement, l'identification du contenu à enregistrer (attribut
"CRID"), - optionnellement, l'identification de l'utilisateur (attribut <Userld>).
Les étapes du procédé d'enregistrement qui viennent d'être présentées de manière générale en regard de la figure 1 vont maintenant être décrites plus en détail en référence aux figures 2 à 7. 1. Enregistrement de contenus audio-visuels dans le réseau à partir d'un site Web d'un enregistreur de réseau.
1.1. Découverte d'un enregistreur de réseau par site Web. Un enregistreur de contenus audiovisuels peut se faire connaître au moyen d'une page HTML sur son site Web. En cliquant sur un lien indiqué sur la page Web, le terminal de l'utilisateur reçoit un fichier avec un type MIME particulier : "application/x-TV- Record-Service-Declaration ". Le fichier obtenu en retour contient les informations suivantes : - de préférence, l'adresse de l'enregistreur sur le réseau (élément <RecordServiceAddress>), - de préférence, la liste des chaînes qu'il peut enregistrer (élément <DeliveryServiceList>) contenant pour chaque chaîne : * de préférence, l'adresse de la chaîne telle que définie par le forum TV Anytime (attribut "serviceURL"), * optionnellement, le tarif pratiqué par l'enregistreur pour cette chaîne (élément <ChargingPolicy>) , - optionnellement, les capacités de conversion de l'enregistreur (élément <ConversionCapabilities>) qui se décomposent en : * possibilité de réduction en débit (élément <Bitrate Conversion Capability>) , * possibilité de transcoder les contenus audiovisuels (élément <TranscodingCapability>) dans différents formats de codage audiovisuel, - optionnellement, les protocoles supportés pour le transfert du contenu une fois l'enregistrement effectué vers le poste client (par défaut, on pourrait considérer que seul le mode FTP ou un autre est toujours proposé).
Exemple d'un fichier de déclaration d'enregistreur dans le réseau <TV_Record_Service_Declaration xmlns:xsi="http://w w.w3.org/2001/X LSchema-instance" xsi:noNamespaceSchemaLocation="TVRecServ.xsd" version="1"> <RecordServiceAddress>http://www.voila.fr/RecordRequest.rr</RecordServiceAddress> <ConversionCapabilities> <BitratθConversionCapability>true</BitrateConversionCapability> <TranscodingCapability>MPEG-1</TranscodingCapability> <TranscodingCapability> PEG-4< TranscodingCapability> </ConversionCapabilities> <SupportedTransferProtocols> <SupportedTransferProtocol value="FTP"/> <SupportedTransferProtocol value="HTTP"/> </SupportedTransferProtocols> <DeliveryServiceList> <DeliveryService serviceURL="dvb://1.2.a"> <ChargingPolicy xml:lang="en">3 USD for AV contents produced in the last 3 months, 1 USD for the other contents</ChargingPolicy> </DeliveryService> <DeliveryService serviceURL- 'dvb://1.2.b"/> <DeliveryService serviceURL="dvb://1.2.c"/> </DeliveryServiceϋst>
<tTV_Record_Service_Declaration>
Cette table permet de déclarer un enregistreur de contenus audiovisuels diffusés que l'on peut commander à l'adresse indiquée par l'élément <RecordServiceAddress> pour les services de livraison de contenus, ou canaux de diffusion (canaux de télévision) indiqués par les éléments
<De//VerySen /ceL/RL>. Ainsi, lorsque l'utilisateur désire enregistrer un contenu diffusé par l'un des canaux de diffusion ainsi déclarés, le terminal de l'utilisateur peut, s'il ne reçoit pas directement le canal de diffusion du contenu sélectionné ou s'il est dans l'impossibilité de le recevoir à l'heure de diffusion du contenu, commander l'enregistrement de ce contenu à l'adresse indiquée dans l'élément
<RecordServiceAddress>. 1.2. Commande par l'utilisateur d'un enregistrement dans le réseau. Quand un utilisateur désire faire appel à un enregistreur de réseau parce qu'il a découvert dans l'étape précédente que celui-ci pouvait lui enregistrer les contenus audiovisuels diffusés par un canal de diffusion particulier, il doit lui envoyer, à l'adresse indiquée par l'élément <RecordServiceAddress> de la table définie ci-dessus, la commande <TV_Record_Service_Request> avec les informations suivantes : - de préférence, l'identification de l'utilisateur (attribut "Userld"), - optionnellement, l'identification du protocole à utiliser pour le transfert du contenu après enregistrement, - optionnellement, l'identification du codage désiré pour le contenu à enregistrer (ce qui peut demander un transcodage dans l'enregistreur), - de préférence, l'identification du contenu à enregistrer (attribut "CRID11), - optionnellement, l'identification d'une instance de ce contenu constituée de : * de préférence, l'identification de la chaîne de télévision (attribut "serviceURL"), * de préférence, l'heure de début (attribut "start"), * de préférence, l'heure de fin (attribut "end") ou la durée (attribut "duration' , * optionnellement, l'identification d'une instance particulière (attribut "instanceMetadatald").
Exemple d'un fichier de commande d'enregistrement de deux contenus dans le réseau avec protocole de récupération du contenu enregistré en FTP, transcodage en MPEG-4 avec un débit maximal de 1500 kbit/s pour le contenu "crid://hbc.com/foxes/episode11" sur le canal de télévision "dvb:// 1.4ee2.3f5/" et le contenu "crid://ch1.com/serie/ep12" sur le canal "dvb://1.4ee2.3f4;4f5/" : <TV_Record_Service_Request xmlns:xsi="http://www. 3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="TVRecServ.xsd" userId="X3YZDFdeGH49"> <RequestedTransferProtocol>FTP</RequestedTransferProtocol> <Transcoding> PEG-4</Transcoding> <MaxBitRate>1500</MaxBitRate> <Contentldentification crid="crid://hbc.com/foxes/episode11" serviceURL-'dvb:// 1.4ee2.3f5/" start="2001- 04-07T19:00:00.00+01 :00" duration="PT1 H30M7> <Contentldentification crid="crid://ch1.com/serie/ep12" serviceURL="dvb://1.4ee2.3f4;4f5/" start="2003-06- 27T12:30:00.00+01 :00" duration="PT0H30M" instanceMetadatald="imi:broadcast/1"/> < TV_Record_Service_Request>
Chaque contenu à enregistrer est identifié par son CRID, par le serviceURL qui va délivrer le contenu, par son heure de début et sa durée (ou son heure de fin) et éventuellement son identification d'instance. En retour la réponse <TV_Record_Service_Request_Response> contient pour chaque contenu dont l'enregistrement a été commandé : - soit une acceptation de commande d'enregistrement (élément <RecordRequestSuccess>) (figure 2) contenant : * de préférence, l'identification de la commande d'enregistrement acceptée (attribut "requestld"), * de préférence, l'identification du contenu commandé (attribut "CRID"), en cas de pluralité de contenus commandés dans la même commande, * optionnellement, l'identification du contenu commandé (attribut "CRID"), dans le cas d'un contenu unique commandé, * optionnellement, l'heure de fin programmée d'enregistrement (attribut "record EndTime") * optionnellement, la durée de conservation du contenu enregistré (attribut "keepDuration"), * optionnellement, le coût de l'enregistrement (attributs "recordCost" et "currency"), - soit un refus de la commande d'enregistrement (élément <RecordRequestFailure>) (figure 3) contenant : * de préférence, l'identification du contenu demandé (attribut "CRID") refusé, en cas de pluralité de contenus commandés dans la même commande, * optionnellement, l'identification du contenu commandé (attribut "CRID") en cas d'un seul contenu commandé, * optionnellement, la raison du refus (attribut "KOreason").
Exemple de réponse à une commande d'enregistrement avec acceptation pour deux contenus (le deuxième avec indication de durée de conservation et coût à payer) et refus pour deux autres :
<TV_Record_Service_Request_Response xmlns:xsi=''http://www.w3.org/2001/XMLSchema-instance'' xsi:noNamespaceSchemaLocation="TVRecServ.xsd"> <RecordRequestSuccess crid="crid://hbc.com/foxes/episode11" requestld="12456XD34" recordEndTime="2003-04-07T20:30:00.00+01:00"/>
<RecordRequestSuccess crid="crid://zzz.com/movie/title1" requestld="156WQ77" recordEndTime="2003-04-
07T20:30:00.00+01:00" keepDuration="PT24H" recordCost="2" currency="USD7>
<RecordRequestFailure crid="crid://ch1.com/serie/ep12" KOreason="unknownCRID7> <RecordRequestFailure crid="crid://chaine5.com/film15" Oreason="unavailableServiceURL7>
</TV_Record_Service_Request_Response>
1 .3. Gestion d'une commande d'enregistrement dans le réseau. Après acceptation d'une commande d'enregistrement dans le réseau, l'enregistreur de réseau a les moyens de se tenir informé des changements d'horaire pouvant intervenir dans la diffusion des contenus AV et de reprogrammer l'enregistrement des contenus commandés en conséquence. Après acceptation d'une commande d'enregistrement dans le réseau, l'utilisateur a plusieurs possibilités : - annuler sa commande d'enregistrement (si le coût est trop élevé ou s'il change d'avis), - interroger sur l'état de sa commande d'enregistrement (pour savoir si le contenu a été reprogrammé à une autre date ou heure ou si l'enregistrement est terminé) Pour annuler une commande d'enregistrement, l'utilisateur doit envoyer la commande "annuler une commande d'enregistrement" (structure de données <TV_Record_Request_Cancel>) (figure 5) contenant : - de préférence, l'identification de la commande d'enregistrement acceptée (attribut "requestld"), - optionnellement, l'identification du contenu à enregistrer (attribut "CRID"), - optionnellement, l'identification de l'utilisateur (attribut <Userld>).
Exemple de commande d'annulation de demande d'enregistrement :
<TV_Record_Request_Cancel xmlns:xsi="http://w w.w3.org/2001/X LSchema-instance" xsi:noNamespaceSchemaLocation="TVRecServ.xsd" crid="crid://hbc.com/foxes/episode11" requestld="12456XD347>
Il n'est pas attendu de réponse de l'enregistreur.
Pour connaître l'état d'une commande d'enregistrement, l'utilisateur doit envoyer la requête "demande d'état d'enregistrement" (structure de données <TV_Record_Request_Status_Request>) (figure 2) contenant : - de préférence, l'identification de la commande d'enregistrement acceptée (attribut "requestld"), - optionnellement, l'identification du contenu à enregistrer (attribut "CRID"), - optionnellement, l'identification de l'utilisateur (attribut <Userld>). Exemple de requête de "demande d'état d'enregistrement" : <TV_Record_Request_Status_Request xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="TVRecServ.xsd" crid="crid://hbc.com/foxes/episode11" requestld="12456XD347> Plusieurs réponses sont possibles. Dans le cas où le contenu n'est pas encore enregistré (figure 4), la réponse de l'enregistreur contiendra : - de préférence, l'identification de la commande d'enregistrement acceptée (attribut "requestld"), - de préférence, l'état de la commande (attribut "status", valeur "runnningRequest"), - optionnellement, l'identification du contenu à enregistrer (attribut "CRID"), - optionnellement, la date et l'heure de fin programmée (attribut "callAfter").
Exemple d'une réponse "contenu non encore enregistré"
<TV_Record_Request_Status_Response xmlns:xsi="http://www. 3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="TVRecServ.xsd" crid="crid://hbc.com/foxes/episode11" requestld="12456XD34" status="runningRequest" callAfter="2003-06-27T14:30:00.00+01 :007>
L'attribut "callAfter" permet au terminal de programmer un temporisateur pour refaire une requête d'état d'enregistrement lorsque celle-ci aura des chances d'obtenir une réponse différente. C'est le cas lorsque l'heure de diffusion d'un contenu a changé.
Dans le cas où la requête n'est pas reconnue comme valide (figure 7), la réponse de l'enregistreur contiendra : - de préférence, l'identification de la commande d'enregistrement acceptée (attribut "requestld"), - de préférence, l'état de la commande (attribut "status", valeur "unknownRequest"), - optionnellement, l'identification du contenu à enregistrer (attribut "CRID").
Exemple de réponse de l'enregistreur pour une commande d'enregistrement inconnue :
<TV_Record_Request_Status_Response xmlns:xsi- 'http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="TVRecServ.xsd" crid="crid://hbc.com/foxes/episode11" requestld="12456XD34" status- 'unknownRequest7>
Cela pourra se produire si le terminal de l'utilisateur interroge l'enregistreur de réseau après la date d'expiration de la conservation d'un contenu enregistré. Dans le cas où la requête a échoué pour une raison ou une autre
(figure 6), l'enregistreur répondra par : - de préférence, l'identification de la commande d'enregistrement acceptée (attribut "requestld"), - de préférence, l'état de la commande (attribut "status", valeur "failedRequest") - optionnellement, l'identification du contenu à enregistrer (attribut "CRID").
Exemple de réponse de l'enregistreur pour une commande d'enregistrement terminée sur échec :
<TV_Record_Request_Status_Response xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="TVRecServ.xsd" crid="crid://hbc.com/foxes/episode11" requestld="12456XD34" status="failedRequest7> Dans le cas où l'enregistrement est terminé et le contenu disponible, la réponse de l'enregistreur contient : - de préférence, l'identification de la commande d'enregistrement acceptée (attribut "requestld"), - de préférence, l'état de la commande (attribut "status", valeur "content A vailable"), - optionnellement, l'identification du contenu à enregistrer (attribut "CRID"), - optionnellement, la durée de conservation du contenu enregistré dans l'enregistreur (attribut "keepDuration"), - de préférence, le moyen de récupérer le contenu enregistré (attribut "contentURL") Exemple de réponse de l'enregistreur pour contenu enregistré dans l'enregistreur :
<TV_Record_Request_Status_Response xmlns:xsi="http://www.w3.org/2001/Xl 1LSchema-instance" xsi:noNamespaceSchemaLocation="TVRecServ.xsd" crid="crid://hbc.com/foxes/episode11" requestld="12456XD34" status="contentAvailable" contentURL="ftp://login:password@ftp.tvrs.fr/user1/av12.mpg7>
1.4. Transfert et suppression d'un contenu enregistré dans le réseau Lorsque l'enregistreur répond à une requête d'état d'une commande d'enregistrement de contenu en indiquant que le contenu est disponible, le terminal de l'utilisateur peut alors récupérer ce contenu par téléchargement, son adresse est indiquée par l'attribut <content(JRL> de la réponse de l'enregistreur. L'enregistrement dans le réseau sera supprimé automatiquement après un certain délai de conservation ou par une commande explicite du terminal contenant : - de préférence, l'identification de la commande d'enregistrement acceptée (attribut "requestld"), - optionnellement, l'identification du contenu à enregistrer (attribut "CRID"), - optionnellement, l'identification de l'utilisateur (attribut <Userld>). Exemple de commande de suppression d'enregistrement dans le réseau :
<Recorded_Content_Delete xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="TVRecServ.xsd" crid="crid://hbc.com/foxes/episode11" requestld="12456XD347>
Il n'est pas attendu de réponse de l'enregistreur.
2. Enregistrement d'un contenu audio-visuel par un enregistreur de réseau par UDDI et SOAP.
2.1. Déclaration de l'enregistreur de réseau par UDDI (service Web) La technologie des services Web et en particulier UDDI (Universal Description, Discovery and Intégration) peut permettre aux enregistreurs de contenus audiovisuels diffusés dans le réseau par des canaux de diffusion de s'inscrire dans un annuaire : l'annuaire d'affaires UDDI. La technologie SOAP (Simple Object Access Protocol) permet d'échanger des structures de données de type XML. Il faut pouvoir enregistrer dans cet annuaire UDDI : - une nouvelle catégorie (ou rubrique) de service : le service d'enregistrement de contenus audiovisuels dans le réseau avec son point d'accès et les opérations qu'ils acceptent des terminaux utilisateurs, - un critère de recherche : l'identificateur de chaque canal de diffusion (chaîne de télévision). Ainsi, un terminal utilisateur qui cherche un enregistreur de réseau pourra interroger l'annuaire en fournissant un ou plusieurs identificateurs de canaux de diffusion (chaînes de télévision) et en demandant en retour un moyen de s'adresser directement aux enregistreurs qui répondent aux critères de recherche. Le nouveau critère de recherche dans l'annuaire UDDI que constitue l'identificateur de chaîne de télévision, par exemple, doit faire l'objet de la définition d'un nouveau tModel UDDI appelé ici "serviceURL" (en conformité avec la section 1 .6.4 des spécifications UDDI relative à la définition de "tModel") pour déclarer les canaux de diffusion de contenus audiovisuels. On lui donnera le nom de "tv-record-org:serviceURL". C'est une autorité qui doit demander l'enregistrement de ce nouveau "tModel". L'entité "tv-record-org" est quelconque, cela pourrait être "tv-anytime-org" ou une autre. Ceci a pour conséquence de déclarer une clé du même nom "uddi:tv- record. org service URL ". La déclaration de cette clé contient également des références aux spécifications de ce "tModel" par l'organisme demandant son introduction "<overviewDoc><overviewURL>" et l'élément "<categoryBag> contient des informations standards de toute déclaration de "tModel".
<tModel tModelKey="uddi:tv-record.org:serviceURL"> <name>tv-record-org:serviceURL</name> description xml:lang="en">Category System for each delivery service handled by a recording service</description> <overviewDoc> <overviewU L useType-'text"> tp://pub:pub@ftp.francetelecom.fr/pub/Spec/Record_tModel.zip </overviewURL> </overviewDoc> <categoryBag> <keyedReference keyName="uddi-org:types:categorization" keyValue-'categorization" tModeIKey="uddi:uddi.org:categorization:types"/> <keyedReference keyName="uddi-org:types:unchecked" keyValue-'unchecked" tModelKey="uddi:uddi.org:categorization:types7> </categoryBag> </tModel> II est également nécessaire de définir un "tModel port" pour l'envoi de requête à l'enregistreur de contenus audiovisuels comme suit :ce « tModel » décrit le service de transfert de commande à l'enregistreur de contenus dans le réseau "submit_Data" dont l'usage sera illustré plus loin : <tModel tModelKey="uddi:tv-record.org:submit_Data_v10"> <name>tv-record-org:submit_Data_v10</name> <description xml:lang="en">TV Record WSDL interface for submit_Data port</description> <overviewDoc> <overviewURL useType=" sdllnterface"> http://www.tv-record.Org/wsdl/tvr_transport_v10.wsdl#submit_Data_SOAP </overviewURL> </overviewDoc> <overviewDoc> <overviewURL useType="text"> ftp://tvr:tvr@ftp. voila.fr/spec/tvr_xxV10.zip </overviewURL> </overviewDoc> <categoryBag> <keyed Référence keyName="uddi-org:types:wsdl" keyValue-'wsdISpec" tModelKey="uddi:uddi.org:categorization:types7> <keyedReference keyName="uddi-org:types:soap" keyValue="soapSpec" tModelKey="uddi:uddi.org:categorization:types7> <keyedReference keyName="uddi-org:types:xml" keyValue="xmlSpec" tModelKey="uddi:uddi.org:categorization:types7> <keyedReference keyName="uddi-org:types:specification" keyValue="specification" tModelKey="uddi:uddi.org:categorization:types7> </categoryBag> </tModel>
Un enregistreur de contenus audiovisuels diffusés, pour se faire connaître, doit déclarer ses possibilités d'enregistrement en utilisant la méthode (de l'API de publication UDDI) appelée "save_binding" (en supposant que les structures parentales appropriées "businessEntity" et "businessSen/ice" ont déjà été déclarées) en faisant référence au « tModel » défini précédemment :
<save_binding xmlns="urn:uddi-org:api_v3"> <bindingTemplate> description xml:lang="fr">Déclaration d'un service d'enregistrement de contenus audiovisuels pour une (ou plusieurs) chaîne(s) de télévision</description> occessPoint useType="endPoint"> http://www.voila.fr/movies </accessPoint> <tModellnstanceDetails> <tModellnstancelnfo tModelKey="uddi:tv-record.org:submit_Data_v10"> <instanceDetails> <instanceParms><![CDATA[ <?xml version="1.0" encoding="utf-8"?> <describe_submit_Data_Result serviceVersion="3" xmlns="http://www.tv-anytime.org/2002/11/transport"> <ConversionCapabilities> <BitrateConversionCapability>true</BitrateConversionCapability> <TranscodingCapability>MPEG-1</TranscodingCapability> <TranscodingCapability>MPEG-4</TranscodingCapability> </ConversionCapabilities> <SupportedTransferProtocols> <SupportedTransferProtocol value="FTP7> <SupportedTransferProtocol value="HTTP"/> </SupportedTransferProtocols> <DeliveryServiceList> <DeliveryService serviceURL="dvb://1.2.a"> <ChargingPolicy xml:lang="en">3 USD for AV contents produced in the last 3 months, 1 USD for the other contents</ChargingPolicy> </DeliveryService> <DeliveryService serviceURL="dvb://1.2.b"/> <DeliveryService serviceURL="dvb://1.2.c'7> </DeliveryServiceList> </describe_submit_Data_Result> ]]></instanceParms> </instanceDetails> </tModellnstancelnfo> </tModellnstanceDetails> <categoryBag> <keyedReference tModelKey="uddi:tv-record.org:serviceURL" keyValue="dvb://1.2.a"/> <keyedReference tModelKey="uddi:tv-record.org:serviceURL" keyValue="dvb://1.2.b > <keyedReference tModelKey="uddi:tv-record.org:serviceURL" keyValue="dvb://1.2.c"/> </categoryBag> </bindingTemplate> </save_binding>
L'élément <accessPoint> fournit l'adresse http de l'enregistreur où devra être envoyée la requête "submiiJData". L'élément <instanceParms> contient la déclaration de ce que l'on peut attendre de l'enregistreur (contenu de la structure de données <TV_Record_Service_Declaration> définie pour le premier mode de réalisation) qui définit les possibilités de transcodage, de réduction de débit, de protocole de transfert, la liste des canaux de diffusion enregistrables et les conditions tarifaires. L'élément <categoryBag> contient la liste des canaux de diffusion que l'enregistreur est capable d'enregistrer. 2.2. Découverte de l'enregistreur de réseau par service Web La technologie des services Web et en particulier UDDI (Universal
Description, Discovery and Intégration) offre également la possibilité aux terminaux, disposant d'une connexion à l'Internet, de découvrir des enregistreurs de contenus audiovisuels diffusés, sans connaissance préalable, en interrogeant cet annuaire. Ainsi, tout terminal peut utiliser un nœud de l'annuaire d'affaires UDDI (qui a des adresses bien connues) pour trouver des enregistreurs de contenus audiovisuels diffusés par la commande <find_binding> comme illustré ci- dessous :
<find_binding xmlns="urn:uddi-org:api_v3"> <tModelBag> <t odelKey>uddi:tv-record.org:submi t_Data_v10</tModeI Key> </tModelBag> <categoryBag> <keyed Référence t odelKey="uddi:tv-record.org:serviceU RL" keyValue="dvb://1.2.a7> <keyedReference tModeIKey- 'uddi:tv-record.org:serviceU RL" keyValue="dvb://1.2.c'7> </categoryBag> </find_binding>
Dans cet exemple, le terminal recherche un enregistreur de réseau pour les canaux, ou chaînes de télévision, référencés "dvb://1.2.a" et "dvb:/1.2.c". En réponse, le terminal va recevoir une liste de <bindingTemplate> (enregistrés dans l'annuaire des services par la commande <save_binding>) qui répondent à sa requête.
2.3. Commande d'enregistrement dans le réseau Après avoir choisi un enregistreur de contenus audiovisuels, le terminal peut envoyer la requête suivante en utilisant SOAP (Simple Object Access
Protocol) pour commander l'enregistrement d'un contenu (en encapsulant la commande <TV_Record_Service_Request> définie dans le mode de réalisation précédent) :
POST Λvr/md-service HTTP/1.0
Host: www.voila.fr
Content-Type: text xml; charset="utf-8" Content-Length: nnnn Accept-Encoding: deflate SOAPAction: "submit_Data"
<?xml version="1.0" encoding="UTF-8"?> <Envelope xmlns=" http://schemas.xmlsoap.org/soap/envelope/"> <Body> <submit_Data xmlns="http://www.tv-record.org/2002/11/transport"> <TV_Record_Service_Request xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="TVRecServ.xsd" userld="XcGHJ63DX"> <RequestedTransferProtocol>FTP</RequestedTransferProtocol> <Transcoding>MPEG-4</Transcoding> <MaxBitRate>1500</MaxBitRate> <Contentldentification crid="crid://hbc.com/foxes/episode11" serviceURL="dvb:// 1.4ee2.3f5/" start="2001-04-07T19:00:00.00+01 :00" duration="PT1 H30M"/> <Contentldentification crid="crid://ch1.com/serie/ep12" serviceURL="dvb://1.4ee2.3f4;4f5/" start="2003-06-27T12:30:00.00+01 :00" duration="PT0H30M" instanceMetadatald="imi:broadcast/17> </TV_Record_Service_Request> </submit_Data> </Body> </Envelope>
En retour le terminal va recevoir la réponse suivante avec des commandes d'enregistrement acceptées et d'autres refusées :
HTTP/1.1 200 OK Content-Type: text/xml; charset="utf-8"
Content-Length: nnnn Content-Encoding: deflate <"?xml versιon="1 0" encodιng="UTF-8'"?> <Envelope xmlns-'http //www w3 org/2002/06/soap-envelope"> <Body> <submιt_Data_Result xmlns=" http //schémas xmlsoap org/soap/envelope/"> <TV_Record_Servιce_Request_Response xmlns xsι="http //www w3 org/2001/XMLSchema-ιnstance" xsi noNamespaceSchemaLocatιon="TVRecServ xsd"> <RecordRequestSuccess cπd="crιd //hbc com/foxes/epιsode11" requestld="12456XD34" recordEndTιme="2003-04-07T20 30 00 00+01 007> <RecordRequestSuccess cπd="cπd //zzz com/movιe/tιtle1" requestld="156WQ77" recordEndTιme="2003-04-07T20 30 00 00+01 00" keepDuratιon="PT24H" recordCost="2" currency="USD"/> <RecordRequestFaιlure crιd="crιd //ch1 com/seπe/ep12" KOreason="unknownCRID7> <RecordRequestFaιlure cπd="cπd //chameδ com/fιlm15" KOreason="unavaιlableServιceURL7> </TV_Record_Servιce_Request_Response> </submιt_Data_Result> </Body> </Envelope>
Il est procédé de la même façon pour encapsuler les autres commandes définies dans le mode de réalisation précédent pour les autres étapes de l'enregistrement de contenus audiovisuels dans le réseau.

Claims

REVENDICATIONS
1. Procédé d'enregistrement de contenus audio-visuels dans un réseau de communication, caractérisé en ce que, ledit réseau de communication comprenant au moins un enregistreur de réseau apte à enregistrer des contenus audio-visuels diffusés sur une pluralité de canaux de diffusion, l'enregistrement desdits contenus audio-visuels par un enregistreur de réseau étant effectué à la demande d'un utilisateur muni d'un terminal de communication apte à échanger des informations avec au moins un enregistreur de réseau à travers ledit réseau de communication, ledit procédé comporte les étapes suivantes :
- pour l'enregistreur de réseau, se déclarer dans le réseau, la déclaration indiquant au moins : * un moyen d'accès audit enregistreur, * une liste de canaux de diffusion dont les contenus audio-visuels diffusés sont aptes à être enregistrés par l'enregistreur de réseau,
- pour l'utilisateur, choisir au moyen de son terminal un enregistreur de réseau apte à enregistrer au moins un contenu audio-visuel souhaité et s'y connecter à l'aide dudit moyen d'accès afin de commander l'enregistrement dudit au moins un contenu audio-visuel, ladite commande comprenant une identification dudit au moins un contenu audio-visuel à enregistrer à choisir, séparément ou en combinaison, entre une référence unique dudit contenu et une identification d'une instance dudit contenu constituée d'au moins l'identification du canal de diffusion de ladite instance accompagnée de l'indication d'une plage horaire de diffusion,
- pour l'enregistreur de réseau, émettre une réponse à la commande d'enregistrement de l'utilisateur contenant pour chaque contenu à enregistrer une identification de la commande d'enregistrement acceptée, en cas d'acceptation de la commande.
2. Procédé selon la revendication 1 , caractérisé en ce qu'il comporte également les étapes consistant : - pour l'utilisateur, en cas d'acceptation de la commande, à formuler vers l'enregistreur de réseau une requête sur l'état de la commande d'enregistrement en indiquant au moins ladite identification de la commande d'enregistrement acceptée, - pour l'enregistreur de réseau, à émettre une réponse à la requête sur l'état de la commande d'enregistrement contenant au moins l'identification de la commande d'enregistrement acceptée et l'état de la commande.
3. Procédé selon la revendication 1 , caractérisé en ce qu'il comporte également les étapes consistant pour l'utilisateur à formuler une requête d'annulation d'une commande d'enregistrement acceptée ou de suppression d'un contenu enregistré par l'enregistreur de réseau, en indiquant au moins l'identification de la commande d'enregistrement acceptée.
4. Procédé selon l'une quelconque des revendications 1 à 3, caractérisé en ce que ledit moyen d'accès à un enregistreur de réseau consiste en une adresse dudit enregistreur dans le réseau.
5. Procédé selon l'une quelconque des revendications 1 à 3, caractérisé en ce que ledit moyen d'accès à un enregistreur de réseau consiste en un annuaire comprenant une inscription d'opérations particulières aux enregistreurs de réseau, chaque enregistreur de réseau étant identifié par ladite opération.
6. Procédé selon l'une quelconque des revendications 1 à 5, caractérisé en ce que ladite liste des canaux de diffusion dont les contenus audio-visuels diffusés sont aptes à être enregistrés par l'enregistreur de réseau comporte l'adresse de chacun des canaux de diffusion, accompagnée optionnellement du tarif pratiqué par l'enregistreur de réseau pour chacun des canaux de diffusion.
7. Procédé selon l'une quelconque des revendications 1 à 6, caractérisé en ce que la déclaration de l'enregistreur de réseau dans le réseau contient les capacités de conversion dudit enregistreur.
8. Procédé selon la revendication 7, caractérisé en ce que lesdites capacités de conversion concernent la réduction en débit et/ou le transcodage des contenus audio-visuels.
9. Procédé selon l'une quelconque des revendications 1 à 8, caractérisé en ce que la déclaration de l'enregistreur de réseau dans le réseau contient les protocoles de transfert d contenu audio-visuel enregistré vers le terminal de l'utilisateur aptes à être mis en oeuvre par l'enregistreur de réseau.
10. Procédé selon l'une quelconque des revendications 1 à 9, caractérisé en ce que ladite indication de plage horaire comporte l'heure de début de diffusion et l'heure de fin ou la durée de diffusion sur le canal de diffusion de ladite instance.
11. Procédé selon l'une quelconque des revendications 7 à 10, caractérisé en ce que ladite commande contient les capacités de conversion exigées par l'utilisateur pour le transfert de l'enregistrement vers son terminal.
12. Procédé selon l'une quelconque des revendications 1 à 11 , caractérisé en ce que la réponse de l'enregistreur de réseau contient, en cas d'acceptation de la commande, ladite référence unique du contenu audio-visuel commandé.
13. Procédé selon l'une quelconque des revendications 1 à 12, caractérisé en ce que la réponse de l'enregistreur de réseau contient, en cas d'acceptation de la commande, l'heure de fin programmée de l'enregistrement et/ou le coût dudit enregistrement.
14. Procédé selon l'une quelconque des revendications 1 à 13, caractérisé en ce que la réponse de l'enregistreur de réseau contient, en cas d'acceptation de la commande, la durée de conservation de l'enregistrement par l'enregistreur de réseau.
15. Procédé selon l'une quelconque des revendications 1 à 14, caractérisé en ce que la réponse de l'enregistreur de réseau contient, en cas de refus de la commande, la raison du refus.
16. Procédé selon l'une quelconque des revendications 2 à 15, caractérisé en ce que ladite requête sur l'état de la commande d'enregistrement contient ladite référence unique du contenu et/ou l'identification de l'utilisateur.
17. Procédé selon l'une quelconque des revendications 2 à 16, caractérisé en ce que la réponse à la requête sur l'état de la commande d'enregistrement contient, en cas de commande non encore exécutée, la référence unique du contenu et/ou la date et l'heure de fin programmée.
18. Procédé selon l'une quelconque des revendications 2 à 16, caractérisé en ce que la réponse à la requête sur l'état de la commande d'enregistrement contient, en cas de commande i nconnue, la référence unique du contenu.
19. Procédé selon l'une quelconque des revendications 2 à 16, caractérisé en ce que la réponse à la requête sur l'état de la commande d'enregistrement contient, en cas d'échec de la commande, la référence unique du contenu.
20. Procédé selon l'une quelconque des revendications 2 à 16, caractérisé en ce que la réponse à la requête sur l'état de la commande d'enregistrement contient, lorsque le contenu est disponible, une adresse où le contenu enregistré est disponible
21. Procédé selon la revendication 20, caractérisé en ce que ladite réponse contient la référence unique du contenu et/ou la durée de conservation de l'enregistrement par l'enregistreur de réseau.
22. Procédé selon l'une quelconque des revendications 3 à 21 , caractérisé en ce que ladite requête d'annulation de commande ou de suppression de contenu enregistré contient la référence unique du contenu et/ou l'identification de l'utilisateur.
23. Procédé selon l'une quelconque des revendications 1 à 22, caractérisé en ce que ladite commande comporte une identification de l'utilisateur.
24. Procédé selon l'une quelconque des revendications 1 à 23, caractérisé en ce que la réponse de l'enregistreur de réseau à la commande d'enregistrement de l'utilisateur contient une identification de contenu refusé, en cas de refus et de pluralité de contenus commandés.
EP04817600A 2004-01-05 2004-12-24 Procede d'enregistrement de contenus audio-visuels dans un reseau de communication Withdrawn EP1702465A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR0450011A FR2864875A1 (fr) 2004-01-05 2004-01-05 Procede d'enregistrement de contenus audio-visuels dans un reseau de communication
PCT/FR2004/003388 WO2005076606A1 (fr) 2004-01-05 2004-12-24 Procede d’enregistrement de contenus audio-visuels dans un reseau de communication

Publications (1)

Publication Number Publication Date
EP1702465A1 true EP1702465A1 (fr) 2006-09-20

Family

ID=34673920

Family Applications (1)

Application Number Title Priority Date Filing Date
EP04817600A Withdrawn EP1702465A1 (fr) 2004-01-05 2004-12-24 Procede d'enregistrement de contenus audio-visuels dans un reseau de communication

Country Status (9)

Country Link
US (1) US20070162947A1 (fr)
EP (1) EP1702465A1 (fr)
JP (1) JP2007527151A (fr)
KR (1) KR20060123519A (fr)
CN (1) CN1926854A (fr)
BR (1) BRPI0418357A (fr)
CA (1) CA2552470A1 (fr)
FR (1) FR2864875A1 (fr)
WO (1) WO2005076606A1 (fr)

Families Citing this family (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20060101496A1 (en) * 2004-11-05 2006-05-11 Cable Television Laboratories, Inc. Targeted messaging for a content distribution network
US8386126B2 (en) * 2006-11-06 2013-02-26 The Directv Group, Inc. Method and apparatus for providing independent content to multiple terminals within a vehicle
US20080109558A1 (en) * 2006-11-06 2008-05-08 The Directv Group, Inc. Method and apparatus for providing independent content to multiple terminals within a vehicle with modifiable playback stream features
US7974293B2 (en) * 2006-11-06 2011-07-05 The Directv Group, Inc. Method and apparatus for transcrypting or transcoding content for a terminal within a vehicle
US20080106376A1 (en) * 2006-11-06 2008-05-08 The Directv Group, Inc. Method and apparatus for purchasing content from a terminal within a vehicle
US8079053B2 (en) * 2007-05-15 2011-12-13 At&T Intellectual Property, I, L.P. System and method of deferring multimedia content delivery
KR101443632B1 (ko) * 2008-04-11 2014-11-03 엘지전자 주식회사 녹화/재생 장치, 콘텐츠 위치 관리 서버, 정보저장매체,콘텐츠 정보 관리 방법 및 콘텐츠 정보 관리 방법을 기록한기록매체
US9667918B2 (en) * 2009-02-20 2017-05-30 At&T Intellectual Property I, L.P. Network recording system
KR101805427B1 (ko) 2011-04-19 2017-12-08 삼성전자주식회사 예약녹화된 방송을 출력하는 장치 및 그 제어 방법
US20130007240A1 (en) * 2011-06-30 2013-01-03 At&T Intellectual Property I, L.P. Systems and methods to provide availability notifications for denied content requests
US9298827B2 (en) * 2011-07-12 2016-03-29 Facebook, Inc. Media recorder
BR102014011263B1 (pt) * 2014-05-09 2019-07-02 Tqtvd Software Ltda Método para encapsular streams de conteúdo audiovisual em mpeg2-private-sections, dispositivo para encapsular conteúdo audiovisual em mpeg2-private-sections para sermultiplexados em um mpeg2-transport-stream, protocolo de comunicação em redes e método para transmissão de conteúdo audiovisual e/ou dados para dispositivos do usuário sem recursos para sintonizar um broadcast de sinal de tv digital através de um broadcast de sinal de tv digital
US20170097893A1 (en) * 2015-10-01 2017-04-06 Tridib Chakravarty Systems and methods for tape data access

Family Cites Families (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE69937919T9 (de) * 1998-02-25 2009-04-30 Nec Corp. Netz mit einem Netzverwaltungssystem, zur Verbindung mehrerer Vorrichtungen zur Speicherung und Wiedergabe von Fernsehprogrammen
US7143430B1 (en) * 1999-11-15 2006-11-28 Lucent Technologies Inc. Method and apparatus for remote audiovisual signal recording service
US6499054B1 (en) * 1999-12-02 2002-12-24 Senvid, Inc. Control and observation of physical devices, equipment and processes by multiple users over computer networks
WO2001061997A1 (fr) * 2000-02-18 2001-08-23 Alexander Franco Utilisation de pages web pour programmer a distance un systeme d'enregistrement de contenu
JP2001346141A (ja) * 2000-05-31 2001-12-14 Nippon Telegr & Teleph Corp <Ntt> ネットワークビデオレコーダ
SE522365C2 (sv) * 2000-06-08 2004-02-03 Mikael Laangberg Anordning och förfarande för att spela in och spela upp videosignaler
US7028329B1 (en) * 2000-10-13 2006-04-11 Seiko Epson Corporation Remote accessible programming
US20020147687A1 (en) * 2001-04-06 2002-10-10 International Business Machines Corporation Method and computer system for program recording service
US20020184635A1 (en) * 2001-05-31 2002-12-05 Istvan Anthony F. Setting events for a set-top box using a browser-enabled device
FR2832014A1 (fr) * 2001-11-08 2003-05-09 Thomson Licensing Sa Module et procede de communication inter-utilisateurs et produits correspondants
JP2003199000A (ja) * 2001-12-26 2003-07-11 Toshiba Corp テレビジョン受信機、ネットワークサーバー、サーバ・クライアントシステム、及び番組録画再生方法
US20030190149A1 (en) * 2002-03-21 2003-10-09 Chieh-Chung Chang Server-based programming of appliances via an information network

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
None *
See also references of WO2005076606A1 *

Also Published As

Publication number Publication date
WO2005076606A1 (fr) 2005-08-18
CN1926854A (zh) 2007-03-07
KR20060123519A (ko) 2006-12-01
CA2552470A1 (fr) 2005-08-18
FR2864875A1 (fr) 2005-07-08
JP2007527151A (ja) 2007-09-20
BRPI0418357A (pt) 2007-05-08
US20070162947A1 (en) 2007-07-12

Similar Documents

Publication Publication Date Title
US7987490B2 (en) System and method to acquire, aggregate, manage, and distribute media
EP1702465A1 (fr) Procede d&#39;enregistrement de contenus audio-visuels dans un reseau de communication
US20140289814A1 (en) Personal video channels
US20050076092A1 (en) User shared virtual channel via media storage
US7721315B2 (en) Method and system for on-demand delivery of personalized internet-based content to television viewers
US9894127B2 (en) Tiered service resell mechanism for IPTV
US20060277272A1 (en) Protocol for enabling digital media navigation, selection and mobile remote control of DVR devices
US8577348B2 (en) System architecture, and method for scheduled downloading services
JP4704156B2 (ja) Soapオペレーションによって非匿名ユーザメタデータを伝送する方法
EP4315961A1 (fr) Procédés de gestion, de découverte, d&#39;enregistrement et de communication et entités configurées pour mettre en oeuvre ces procédés
EP2589202B1 (fr) Procédé et système de gestion de sessions de communication
WO2006108838A1 (fr) Appareil et procede de gestion des services reçus au sein d&#39;un reseau local
MXPA06007702A (en) Method of recording audio-visual content in a communication network
WO2011124810A1 (fr) Gestion de service personnalisee dans un reseau ip
EP3235255B1 (fr) Dispositif et procede de gestion des priorites pour le telechargement de contenus multimedia
FR2964523A1 (fr) Mise a disposition d&#39;informations par un terminal mobile dans un reseau.
FR2879873A1 (fr) Procede et dispositif de transfert de donnees numeriques
FR2857191A1 (fr) Systeme de transmission de parametres caracteristiques d&#39;une session de communication d&#39;un terminal vers un serveur distant
FR3121562A1 (fr) Procédés de souscription et de notifications, et entités configurées pour mettre en œuvre ces procédés.
FR3155327A1 (fr) téléchargement d’une page web optimisé pour des pics de trafic événementiels
FR3148887A1 (fr) Procédé de gestion du traitement d’un flux vidéo dans un réseau local.
FR3155328A1 (fr) téléchargement d’une page web optimisé pour des pics de trafic événementiels
Sur et al. 4 Service Layer for
Moustafa et al. IPTV Services Personalization
EP1705868A2 (fr) Procédé et système de partage d&#39;attributs personnels

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: 20060704

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LI LT LU MC NL PL PT RO SE SI SK TR

17Q First examination report despatched

Effective date: 20061228

DAX Request for extension of the european patent (deleted)
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: 20100701