(57)【要約】【課題】自分の受信機で受信できないとか、受信機が一度に複数の配信チャンネルを受信できるようになっていない等の理由で、自分の受信機で直接には記録できない視聴覚コンテンツの記録をユーザーができるようにするような、通信網での視聴覚コンテンツの記録方法を提案する。【解決手段】通信網に、複数の配信チャンネル上で配信される視聴覚コンテンツを記録可能なネットワークレコーダーを少なくとも一つ付け、一つのネットワークレコーダーによるそのような視聴覚コンテンツの記録を、その通信網を通して少なくとも一つのネットワークレコーダーで情報の交換が可能な手元の通信端末でのユーザーの注文に応じて行う。【選択図】図１
2007527151.tif 000002
【特許請求の範囲】
【請求項１】
通信網の内部で視聴覚コンテンツを記録する方法であって、その通信網に、複数の配信チャンネル上で配信される視聴覚コンテンツを記録可能なネットワークレコーダーを少なくとも一つ付け、一つのネットワークレコーダーによる視聴覚コンテンツの記録を、その通信網を通して少なくとも一つのネットワークレコーダーで情報の交換が可能な手元の通信端末でのユーザーの注文に応じて行い、
その解決方法の手順は、
・ネットワークレコーダーが、ネットワーク内で、少なくとも
＊そのレコーダーへのアクセス手段、
＊ネットワークレコーダーでの記録に適した視聴覚コンテンツを配信する配信チャンネルの一覧表、
とを示す宣言を行い、
・ユーザーが、そのユーザーの端末を用いて、望みの視聴覚コンテンツを少なくとも一つ記録することのできるネットワークレコーダーを選び、そのアクセス手段を用いてそこに接続することにより、その少なくとも一つの視聴覚コンテンツを記録することを注文し、その注文には、そのコンテンツだけの参照記号と、配信時間帯の表示の付いたそのインスタンスの配信チャンネルの少なくとも一つの識別記号で構成されたそのコンテンツのインスタンスの識別記号とを、別々に、または組み合わせた、記録することを選択したその少なくとも一つの視聴覚コンテンツの識別記号が含まれており、
・ネットワークレコーダーが、記録対象の各コンテンツにつき、その注文が受け入れられた場合には、受け入れられた記録注文の識別記号を内容とする応答を、ユーザーの記録注文に対して送信する、
というものであることを特徴とする、視聴覚コンテンツの記録方法。
【請求項２】
・ユーザーは、注文が受け入れられた場合には、ネットワークレコーダーに向けて、受け入れられた記録注文の少なくとも前記識別記号を示して、その記録注文の現状についての問い合わせを表明し、
・ネットワークレコーダーは、受け入れられた記録注文の少なくとも識別記号を内容とするその記録注文の現状についての問い合わせへの回答と、その注文の現状とを送信する、
という手順も含むことを特徴とする、請求項１に記載の方法。
【請求項３】
ユーザーが、既に受け入れられた記録注文の少なくとも識別記号を表示して、既に受け入れられた記録注文の取り消しや、あるいは、ネットワークレコーダーが記録したコンテンツの削除の要求を伝える手順も含まれていることを特徴とする、請求項１に記載の方法。
【請求項４】
一つのネットワークレコーダーへの前記アクセス手段は、ネットワークにおけるそのレコーダーのアドレスであることを特徴とする、請求項１から３のいずれか一つに記載の方法。
【請求項５】
一つのネットワークレコーダーへの前記アクセス手段は、各ネットワークレコーダーを識別する根拠となる、ネットワークレコーダーに特有の作業の登録を含むレジストリであることを特徴とする、請求項１から３のいずれか一つに記載の方法。
【請求項６】
ネットワークレコーダーでの記録に適した視聴覚コンテンツを配信する配信チャンネルの一覧表には、配信チャンネルそれぞれのアドレスが記載されており、任意の選択肢として、配信チャンネルそれぞれにつきネットワークレコーダーから請求される料金が付記されていてもよいことを特徴とする、請求項１から５のいずれか一つに記載の方法。
【請求項７】
ネットワークレコーダーがそのネットワークで行う宣言の中に、そのレコーダーの変換能力も含めることを特徴とする、請求項１から６のいずれか一つに記載の方法。
【請求項８】
前記変換能力は、視聴覚コンテンツのビットレートの削減および／またはコード変換に関するものであることを特徴とする、請求項７に記載の方法。
【請求項９】
ネットワークでネットワークレコーダーが行う宣言の内容に、記録された視聴覚コンテンツをユーザーの端末に向かって転送するためのプロトコルが含まれており、そのプロトコルは、ネットワークレコーダーが活用するのに適したものであることを特徴とする、請求項１から８のいずれか一つに記載の方法。
【請求項１０】
前記時間帯の表示には、配信開始時刻と終了時刻または、配信チャンネルでの、そのインスタンスの配信継続時間とが含まれていることを特徴とする、請求項１から９のいずれか一つに記載の方法。
【請求項１１】
記録内容をユーザーの端末に転送するためにそのユーザーが要求する変換能力も前記注文に記載されていることを特徴とする、請求項７から１０のいずれか一つに記載の方法。
【請求項１２】
注文を受け入れる場合には、ネットワークレコーダーからの回答の内容に、注文した視聴覚コンテンツに一意の前記参照記号が含まれることを特徴とする、請求項１から１１のいずれか一つに記載の方法。
【請求項１３】
注文を受け入れる場合には、ネットワークレコーダーからの回答の内容に、記録の終了設定時刻および／またはその記録の費用を含めることを特徴とする、請求項１から１２のいずれか一つに記載の方法。
【請求項１４】
注文を受け入れる場合には、ネットワークレコーダーからの回答の内容に、ネットワークレコーダーによる記録の保存継続時間を含めることを特徴とする、請求項１から１３のいずれか一つに記載の方法。
【請求項１５】
注文を断る場合には、ネットワークレコーダーからの回答が、その断りの理由を含むことを特徴とする、請求項１から１４のいずれか一つに記載の方法。
【請求項１６】
その記録注文の現状についての問い合わせには、そのコンテンツに一意の前記参照記号および／またはユーザーの識別記号が含まれていることを特徴とする、請求項２から１５のいずれか一つに記載の方法。
【請求項１７】
注文がまだ実行されていない場合には、記録注文の現状についての問い合わせへの回答には、そのコンテンツに一意の参照記号および／または設定された終了の日付と時刻が含まれていることを特徴とする、請求項２から１６のいずれか一つに記載の方法。
【請求項１８】
注文が未知のものである場合には、記録注文の現状についての問い合わせへの回答には、そのコンテンツに一意の参照記号が含まれていることを特徴とする、請求項２から１６のいずれか一つに記載の方法。
【請求項１９】
注文が失敗した場合には、記録注文の現状についての問い合わせへの回答には、そのコンテンツに一意の参照記号が含まれていることを特徴とする、請求項２から１６のいずれか一つに記載の方法。
【請求項２０】
コンテンツが入手可能な場合には、記録注文の現状についての問い合わせへの回答には、記録されたコンテンツが入手可能なアドレスが含まれていることを特徴とする、請求項２から１６のいずれか一つに記載の方法。
【請求項２１】
その回答には、そのコンテンツに一意の参照記号および／またはそのネットワークレコーダーによる記録の保存継続時間が含まれていることを特徴とする、請求項２０に記載の方法。
【請求項２２】
その注文の取り消しまたは記録されたコンテンツの削除を依頼する前記要求の内容には、そのコンテンツに一意の参照記号および／またはユーザーの識別記号が含まれていることを特徴とする、請求項３から２１のいずれか一つに記載の方法。
【請求項２３】
前記注文にはユーザーの識別記号が付いていることを特徴とする、請求項１から２２のいずれか一つに記載の方法。
【請求項２４】
ユーザーからの記録の注文へのネットワークレコーダーからの回答の内容には、注文を断る場合、そして注文したコンテンツが複数ある場合には、断るコンテンツの識別記号が含まれることを特徴とする、請求項１から２３のいずれか一つに記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、通信網での視聴覚コンテンツの記録方法に関するものである。
【０００２】
本発明を特に有利に応用できるのは視聴覚コンテンツの遠隔記録の分野である。
【背景技術】
【０００３】
現行技術においても、配信チャンネルが通信網を通して配信する視聴覚コンテンツを遠隔記録する方法が知られているが、その方法は、例えばユーザーの住居にあるパーソナル・デジタル・レコーダー（ＰＤＲ）にユーザーが選んだコンテンツを配信してくれるように、ある配信チャンネルにリクエストするというものである。
【０００４】
そのような遠隔記録方法を用いる必要が生じるのは、例えば、自宅から遠いところにいるユーザーが、まだ自宅にいた時にＰＤＲに記録をセットすることを忘れたのに気づいたというような場合である。
【０００５】
その場合、ユーザーは、自分のデスクトップパソコンや、自分の携帯電話や、自分の携帯情報端末（ＰＤＡ）を用いて、当該配信チャンネルにリクエストをして、その記録を遠隔で行うように設定することができる。
【０００６】
しかしながら、既に知られている遠隔記録方法は、この種の必要性によく対応できてはいるが、視聴覚コンテンツの記録にまつわるその他の問題を解決できていない。それが特に言えるのが、ユーザーがあるコンテンツを記録したいと思う配信チャンネルが、ユーザーの加入している契約外であるために、そのチャンネルが受信できないとか、あるいはユーザーの受信機が、一度に一つのチャンネルしか受信できないのに、そのユーザーが記録したいコンテンツの配信時には、例えば、他の人が他の配信チャンネルで使っているような場合である。
【発明の開示】
【発明が解決しようとする課題】
【０００７】
したがって、本発明の対象により解決すべき技術的課題は、自分の受信機で受信できないとか、受信機が一度に複数の配信チャンネルを受信できるようになっていないとかの理由で、自分の受信機で直接には記録できない視聴覚コンテンツの記録をユーザーができるようにするような、通信網での視聴覚コンテンツの記録方法を提案することである。
【課題を解決するための手段】
【０００８】
提起された技術的課題への、本発明による解決は、その通信網に、複数の配信チャンネル上で配信される視聴覚コンテンツを記録可能なネットワークレコーダーを少なくとも一つ付け、一つのネットワークレコーダーによるそのような視聴覚コンテンツの記録を、その通信網を通して少なくとも一つのネットワークレコーダーでの情報の交換が可能な手元の通信端末でのユーザーの注文に応じて行うというものであり、その方法の手順は以下の通りである。
・ネットワークレコーダーは、そのネットワーク内で、少なくとも
＊そのレコーダーへのアクセス手段、
＊ネットワークレコーダーでの記録に適した視聴覚コンテンツを配信する配信チャンネルの一覧表、
を示す宣言を行い、
・ユーザーは、ユーザーの端末を用いて、望みの視聴覚コンテンツを少なくとも一つ記録することのできるネットワークレコーダーを選び、そのアクセス手段を用いてそこに接続することにより、その少なくとも一つの視聴覚コンテンツを記録することを注文し、その注文には、そのコンテンツだけの参照記号と、配信時間帯の表示の付いた、インスタンスの配信チャンネルの少なくとも一つの識別記号で構成されたそのコンテンツのインスタンスの識別記号とを、別々に、または組み合わせた、記録することを選択したその少なくとも一つの視聴覚コンテンツの識別記号が含まれており、
・ネットワークレコーダーは、記録対象の各コンテンツにつき、注文が受け入れられた場合には、その受け入れられた記録注文の識別記号を内容とする応答を、ユーザーからの記録注文に対して送信する。
【０００９】
そのようにして、ユーザーはいつでも、自分のＰＤＲや、自分のパソコン、携帯電話あるいは携帯情報端末から、どの配信チャンネルのものかを問わず、自分が直接にはアクセスできないものであっても、ネットワークレコーダーに自分のために視聴覚コンテンツを記録することを注文できるのであり、それにより、そのコンテンツを、自分の選んだ（ＰＤＲ、パソコン、ＰＤＡなどの）受信機に転送して、その受信機が使える時間にそれを見ることができる。
【００１０】
本発明によれば、その時間帯の表示には、配信開始時刻と終了時刻または、そのインスタンスの配信チャンネルでの配信時間とが含まれている。
【００１１】
本発明では、一つのネットワークレコーダーに主に二つのアクセス手段が用意されている。実際、一つの実施態様においては、一つのネットワークレコーダーへのアクセス手段は、ネットワークにおけるそのレコーダーのアドレスであり、一方、別の実施態様においては、一つのネットワークレコーダーへのアクセス手段は、各ネットワークレコーダーを識別する根拠となる、複数のネットワークレコーダーに特有の作業の登録を含むレジストリである。
【００１２】
さらに詳細に述べると、本発明によれば、ネットワークレコーダーでの記録に適した視聴覚コンテンツを配信する配信チャンネルのそのような一覧表には、配信チャンネルそれぞれのアドレスが記載されており、任意の選択肢として、配信チャンネルそれぞれにつきネットワークレコーダーから請求される料金が付記されていてもよい。ここで、「配信チャンネルのアドレス」というのは、ＴＶ−Ａｎｙｔｉｍｅフォーラムのような、関係機関や団体を集めたコンソーシアムでコード化されたような識別記号を言う。
【００１３】
また、ユーザーが、ネットワークレコーダーが行う視聴覚コンテンツの記録の受信を、自分の受信機と互換性のある技術条件で行えるようにするために、本発明で用意しているのは、ネットワークレコーダーがそのネットワークで行う宣言の中に、そのレコーダーの変換能力を含めるということである。さらに具体的に言うと、そのような変換能力は、そのような視聴覚コンテンツのビットレートの削減および／またはコード変換に関するものである。
【００１４】
また特筆すべきは、その視聴覚コンテンツのビットレートとコード変換に関する制約は、ユーザー本人に由来するものであるということである。というのは、本発明において強く推奨されているのは、その記録内容をユーザーの端末に転送するためにユーザーが要求する変換能力もその注文に含まれていることだからである。
【００１５】
同様に、本発明では、ネットワークレコーダーがそのネットワークで行う宣言の内容に、記録された視聴覚コンテンツをユーザーの端末に向かって転送するためのプロトコルが含まれており、そのプロトコルは、そのネットワークレコーダーが活用するのに適したものである。言い換えれば、このような準備によって、ユーザーは、「ストリーミング」というタイプの直接転送方式とか、バッチダウンロードする方式とかを、そのネットワークでどのような記録をするかに応じて選択することができるのである。
【００１６】
記録の注文を受けた後、ネットワークレコーダーから、注文を出したユーザーに回答が送られる。
【００１７】
その注文を断る場合には、ユーザーの記録の注文に対するネットワークレコーダーからの回答は、そのように注文したコンテンツが複数である場合には、断るコンテンツの識別記号を内容とするものになる。同様に、ネットワークレコーダーからの回答には、その断りの理由も内容となる。断る理由は、例えば、ネットワークレコーダーがユーザーが注文したコンテンツにアクセスできないからということも考えられる。
【００１８】
注文を受け入れる場合には、本発明で用意されている選択肢には、受け入れた注文の識別記号に加えて、幾つもの選択肢が可能である。つまり、ネットワークレコーダーからの回答の内容に、注文された視聴覚コンテンツに一意の前記参照記号を含め、ネットワークレコーダーからの回答の内容に、その記録の終了設定時刻および／またはその記録の費用を含めたり、あるいはさらにそのネットワークレコーダーからの回答の内容に、ネットワークレコーダーによるその記録の保存継続時間を含めるなどである。
【００１９】
また同様に、本発明の対象である記録方法により、ユーザーは、自分の注文を思いなおしたり、再検討したりすることができるようになる。というのは、この方法にはまた、ユーザーが、既に受け入れられた記録注文の少なくとも識別記号を表示して、既に受け入れられた記録注文の取り消しや、あるいは、ネットワークレコーダーが記録したコンテンツの削除の要求を伝える手順も含まれているからである。
【００２０】
自分の注文がそのネットワークレコーダーの処理のどの段階にあるかを、ユーザーがいつでも知りうるように、本発明の記録方法にはまた、以下のような手順が含まれている。
・ユーザーは、注文が受け入れられた場合には、ネットワークレコーダーに向けて、受け入れられた記録注文の少なくとも前記識別記号を示して、その記録注文の現状についての問い合わせを表明し、
・ネットワークレコーダーは、受け入れられた記録注文の少なくとも前記識別記号を内容とする記録注文の現状についての問い合わせへの回答と、その注文の現状とを送信する。
【００２１】
好ましくは、その記録注文の現状についての問い合わせには、コンテンツに一意の前記参照記号および／またはユーザーの識別記号が含まれているのが望ましい。
【００２２】
状況に応じて、注文の現状についての問い合わせへのレコーダーからの回答には、以下のような幾つもの形式がありうる。
・注文がまだ実行されていない場合は、注文の現状についての問い合わせへの回答には、そのコンテンツに一意の参照記号および／または設定された終了の日付と時刻が含まれている。
・注文が未知のものである場合は、注文の現状についての問い合わせへの回答には、そのコンテンツに一意の参照記号が含まれている。
・注文が失敗した場合は、注文の現状についての問い合わせへの回答には、そのコンテンツに一意の参照記号が含まれている。
・コンテンツが入手可能な場合は、注文の現状についての問い合わせへの回答には、そのコンテンツを記録したものが入手可能なアドレスが含まれている。この場合には、その回答には、そのコンテンツに一意の参照記号および／またはネットワークレコーダーによるその記録の保存継続時間が含まれている。
【発明を実施するための最良の形態】
【００２３】
添付図面を参照しつつ行う以下の説明は、限定する趣旨のものではなく、例示に過ぎないが、本発明の構成と実施可能な方法がよく理解できるようになっている。
【００２４】
図１は、本発明の記録方法の全体的なフローチャートである。
図２は、記録の注文がうまくいった場合の本発明の記録方法のフローチャートである。
図３は、記録の注文が断られた場合の本発明の記録方法のフローチャートである。
図４は、期限を延ばして記録の注文がうまくいった場合の本発明の記録方法のフローチャートである。
図５は、取り消した後で記録の注文がうまくいった場合の本発明の記録方法のフローチャートである。
図６は、記録が失敗した後で記録の注文がうまくいった場合の本発明の記録方法のフローチャートである。
図７は、記録の注文が未知のものである場合の本発明の記録方法のフローチャートである。
【００２５】
図１には、一つの通信網において視聴覚（ＡＶ）コンテンツを記録する方法のフローチャート全体が示されている。
【００２６】
この方法は、少なくとも一つのネットワークレコーダーがあることを前提としており、それは図１の右の部分に対応しており、配信チャンネル上で配信される視聴覚コンテンツを記録するに適したものである。ネットワークレコーダーは、例えば、ユーザーが、適切な加入契約をしていないために、あるいはまた、ユーザーの受信機が既に他の人に他の配信チャンネルで使用中であるために、所望のＡＶコンテンツを配信している配信チャンネルにアクセスすることができないという理由でユーザーが自分では記録できない視聴覚コンテンツを、ユーザーに代わって、ユーザーの名義で、記録できるようにするオペレータである。そのようなネットワークレコーダーは、その種のサービスを専門とするオペレータでもよいし、あるいはまた、彼ら自身が、配信チャンネル（テレビのチャンネル）を専門とするオペレータでもよい。
【００２７】
ネットワークレコーダーが視聴覚コンテンツを記録するのは、図１の左の部分に相当するユーザーの依頼により行うのであり、そのユーザーがもつ端末は、通信網を通してネットワークレコーダーと記録の注文に関する情報の交換をするのに適したものである。
【００２８】
最初に、ネットワークレコーダーはその通信網で宣言を行わなければならない。これはレコーダーのウェブ・サイトを通して直接やってもよいし、あるいは、ＳＯＡＰ（Ｓｉｍｐｌｅ  Ｏｂｊｅｃｔ  Ａｃｃｅｓｓ  Ｐｒｏｔｏｃｏｌ）交換技術と結びついたＵＤＤＩ（Ｕｎｉｖｅｒｓａｌ  Ｄｅｓｃｒｉｐｔｉｏｎ，Ｄｉｓｃｏｖｅｒｙ  ａｎｄ  Ｉｎｔｅｇｒａｔｉｏｎ）のようなレジストリを介して行ってもよい。この後者の場合には、レジストリに、「ネットワークレコーダー」の機能に対応する特別のエントリを設けて、そこにレジストリとエントリに宣言しておくことになるネットワークレコーダーを登録しておかなければならない。
【００２９】
各ネットワークレコーダーがその通信網での自分の存在の宣言（データ構造＜ＴＶ＿Ｒｅｃｏｒｄ＿Ｓｅｒｖｉｃｅ＿Ｄｅｃｌａｒａｔｉｏｎ＞）を行うについては以下のことを表記する。
・好ましくは、ウェブ・サイトのものであれ、レジストリのエントリのものであれ、そのネットワークレコーダーのアドレス（要素＜ＲｅｃｏｒｄＳｅｒｖｉｃｅＡｄｄｒｅｓｓ＞）を表記するのが望ましく、それは、その記録注文が送られることになるアドレスである。
・好ましくは、記録可能な配信チャンネルの一覧表（要素＜ＤｅｌｉｖｅｒｙＳｅｒｖｉｃｅＬｉｓｔ＞）を表記するのが望ましく、それは、各チャンネルにつき
＊好ましくは、例えばＴＶ−Ａｎｙｔｉｍｅフォーラム（属性“ｓｅｒｖｉｃｅＵＲＬ”）により規定された通りのその配信チャンネルのアドレスを内容として含むことが望ましく、
＊任意の選択肢として、その配信チャンネルについてレコーダーから請求される料金（要素＜ＣｈａｒｇｉｎｇＰｏｌｉｃｙ＞）を内容として含んでもよく、
・任意の選択肢として、そのレコーダーの変換能力（要素＜ＣｏｎｖｅｒｓｉｏｎＣａｐａｂｉｌｉｔｉｅｓ＞）を表記してもよく、その能力というのは分解すると、
＊例えば４Ｍビットから２Ｍビットに移行するなどして、ビットレートを削減できる可能性（要素＜ＢｉｔｒａｔｅＣｏｎｖｅｒｓｉｏｎＣａｐａｂｉｌｉｔｙ＞）と、
＊ＭＰＥＧ２をＭＰＥＧ４にコード変換するように、視聴覚コンテンツを様々な視聴覚コード化フォーマットに変換することのできる可能性（要素＜ＴｒａｎｓｃｏｄｉｎｇＣａｐａｂｉｌｉｔｙ＞）とに分かれる。
・任意の選択肢として、記録が行われるとすぐに、ＡＶコンテンツをユーザーの受信機に向けて転送するためにサポートされているプロトコル：ＦＴＰモード、「ストリーミング」またはバッチダウンロード。
【００３０】
それと相互に関連して、ユーザーは、最良の技術的、経済的かつ人間工学的条件で希望のＡＶコンテンツを記録できるであろうレコーダーを選択できるように、そのようなネットワークレコーダーの存在を発見できることができなければならない。それは以下のようにして行うことが考えられる。
・ある特定のＭＩＭＥ（Ｍｕｌｔｉｐｕｒｐｏｓｅ  Ｉｎｔｅｒｎｅｔ  Ｍａｉｌ  Ｅｘｔｅｎｓｉｏｎｓ）タイプ（例えば、“ａｐｐｌｉｃａｔｉｏｎ／ｘ−ＴＶ−Ｒｅｃｏｒｄ−Ｓｅｒｖｉｃｅ−Ｄｅｃｌａｒａｔｉｏｎ”）を規定することによる。こうすると、ウェブ・サイトからの、このタイプのファイルを受信することで、ユーザーの受信機において、上記に規定されたデータ構造＜ＴＶ＿Ｒｅｃｏｒｄ＿Ｓｅｒｖｉｃｅ＿Ｄｅｃｌａｒａｔｉｏｎ＞を解釈するソフトウェアを起動することができるようになる。
・あるいは、視聴覚コンテンツの記録サービス用の新しい「ｔＭｏｄｅｌ」を規定したＵＤＤＩレジストリを用いることで、それにより、どのようなレコーダーも、その存在と能力をそのレジストリに、上記に規定されたデータ構造＜ＴＶ＿Ｒｅｃｏｒｄ＿Ｓｅｒｖｉｃｅ＿Ｄｅｃｌａｒａｔｉｏｎ＞により宣言することができる。
【００３１】
希望のＡＶコンテンツの記録にユーザーにとって最も都合のよいネットワークレコーダーを、ウェブ・サイトまたはレジストリから、選んだ後で、ユーザーは、そのレコーダーに記録注文（データ構造＜ＴＶ＿Ｒｅｃｏｒｄ＿Ｓｅｒｖｉｃｅ＿Ｒｅｑｕｅｓｔ＞）を出すが、その注文には、
・好ましくは、ユーザーの識別記号（属性＜ＵｓｅｒＩｄ＞）が付いていることが望ましいが、それは、例えば、そのレコーダーに（識別記号−パスワード式の接続で）接続した際などのように他の方法で既に識別されていない場合である。
・好ましくは、記録対象のＡＶコンテンツの識別記号が付いていることが望ましいが、その識別記号として考えられるのは、
＊読んで字の如しというような基本的に単純な識別記号のような、（属性＜ＣＲＩＤ＞の）そのコンテンツに一意の参照記号であるとか、
＊そのコンテンツのインスタンスにユーザー自身が付けた識別記号などで、その識別記号を構成するのは、
−好ましくは、配信チャンネルの識別記号（属性“ｓｅｒｖｉｃｅＵＲＬ”）と、
−好ましくは、開始時刻（属性“ｓｔａｒｔ”）と、
−好ましくは、終了時刻（属性“ｅｎｄ”）あるいは継続時間（属性“ｄｕｒａｔｉｏｎ”）と、
−任意の選択肢として、特別のインスタンスの識別記号（属性“ｉｎｓｔａｎｃｅＭｅｔａｄａｔａＩｄ”）とであり、
・任意の選択肢として、ユーザーが要求する変換能力が付いていてもよい。
【００３２】
ユーザーの記録注文へのネットワークレコーダーからの回答（データ構造＜ＴＶ＿Ｒｅｃｏｒｄ＿Ｓｅｒｖｉｃｅ＿Ｒｅｑｕｅｓｔ＿Ｒｅｓｐｏｎｓｅ＞）には、記録対象の各コンテンツにつき、以下のことが内容となる。
・記録注文を受け入れた旨の意思表示（要素＜ＲｅｃｏｒｄＲｅｑｕｅｓｔＳｕｃｃｅｓｓ＞）で、以下のことを内容とするもの、
＊好ましくは、受け入れた記録注文の識別記号（属性“ｒｅｑｕｅｓｔＩｄ”）、
＊任意の選択肢として、求められたコンテンツの識別記号（属性“ＣＲＩＤ”）、
＊任意の選択肢として、記録の終了設定時刻（属性“ｒｅｃｏｒｄＥｎｄＴｉｍｅ”）、
＊任意の選択肢として、記録されたコンテンツの保存継続期間（属性“ｋｅｅｐＤｕｒａｔｉｏｎ”）、
＊任意の選択肢として、記録費用（属性“ｒｅｃｏｒｄＣｏｓｔ”と“ｃｕｒｒｅｎｃｙ”）、
＊任意の選択肢として、記録されたコンテンツの保存継続期間（属性“ｋｅｅｐＤｕｒａｔｉｏｎ”＞）、
・あるいは、記録注文を断る旨の意思表示（要素＜ＲｅｃｏｒｄＲｅｑｕｅｓｔＦａｉｌｕｒｅ＞）で、以下のことを内容とするもの、
＊好ましくは、求められたコンテンツの識別記号（属性“ＣＲＩＤ”）、
＊任意の選択肢として、断る理由（属性“ＫＯｒｅａｓｏｎ”）。
【００３３】
自分の注文が受け入れられた場合には、ユーザーは、自分の記録注文の現状を追跡調査することができ（データ構造＜ＴＶ＿Ｒｅｃｏｒｄ＿Ｒｅｑｕｅｓｔ＿Ｓｔａｔｕｓ＿Ｒｅｑｕｅｓｔ＞）、その際に以下のことを示す。
・好ましくは、受け入れた記録注文の識別記号（属性“ｒｅｑｕｅｓｔＩｄ”）、
・任意の選択肢として、記録対象のコンテンツの識別記号（属性“ＣＲＩＤ”）、
・任意の選択肢として、ユーザーの識別記号（属性“ＵｓｅｒＩｄ”）。
【００３４】
この注文の現状についての問い合わせに、ネットワークレコーダーが送信する回答（データ構造＜ＴＶ＿Ｒｅｃｏｒｄ＿Ｒｅｑｕｅｓｔ＿Ｓｔａｔｕｓ＿Ｒｅｓｐｏｎｓｅ＞）の内容は、
・注文がまだ実行されていない場合には、
＊好ましくは、受け入れた記録注文の識別記号（属性“ｒｅｑｕｅｓｔＩｄ”）、
＊好ましくは、注文の現状（属性“ｓｔａｔｕｓ”、値“ｒｕｎｎｉｎｇＲｅｑｕｅｓｔ”）、
＊任意の選択肢として、記録対象のコンテンツの識別記号（属性“ＣＲＩＤ”）、
＊任意の選択肢として、終了が設定されている日付と時刻（属性“ｃａｌｌＡｆｔｅｒ”）、
・（属性《ｒｅｑｕｅｓｔＩＤ》が認識されておらず）注文が不明の場合には、
＊好ましくは、受け入れた記録注文の識別記号（属性“ｒｅｑｕｅｓｔＩｄ”）、
＊好ましくは、注文の現状（属性“ｓｔａｔｕｓ”、値“ｕｎｋｎｏｗｎＲｅｑｕｅｓｔ”）、
＊任意の選択肢として、記録対象のコンテンツの識別記号（属性“ＣＲＩＤ”）、
・注文が失敗に終わった場合（例えば故障の場合）には、
＊好ましくは、受け入れた記録注文の識別記号（属性“ｒｅｑｕｅｓｔＩｄ”）、
＊好ましくは、注文の現状（属性“ｓｔａｔｕｓ”，値“ｆａｉｌｅｄＲｅｑｕｅｓｔ”）、
＊任意の選択肢として、記録対象のコンテンツの識別記号（属性“ＣＲＩＤ”）。
・注文されたコンテンツが入手可能だと判明した場合には、
＊好ましくは、受け入れた記録注文の識別記号（属性“ｒｅｑｕｅｓｔＩｄ”）、
＊好ましくは、注文の現状（属性“ｓｔａｔｕｓ”，値“ｃｏｎｔｅｎｔＡｖａｉｌａｂｌｅ”）、
＊好ましくは、記録されたコンテンツの回収手段（属性“ｃｏｎｔｅｎｔＵＲＬ”）、
＊任意の選択肢として、記録対象のコンテンツの識別記号（属性“ＣＲＩＤ”）、
＊任意の選択肢として、記録されたコンテンツのレコーダーへの保存継続期間（属性“ｋｅｅｐＤｕｒａｔｉｏｎ”）。
【００３５】
ユーザーはまた、気が変わった場合には、自分の記録注文を取り消すように求めることができ（データ構造＜ＴＶ＿Ｒｅｃｏｒｄ＿Ｒｅｑｕｅｓｔ＿Ｃａｎｃｅｌ＞）、その際には以下のことを表記する。
・好ましくは、受け入れた記録注文の識別記号（属性“ｒｅｑｕｅｓｔＩｄ”）、
・任意の選択肢として、記録対象のコンテンツの識別記号（属性“ＣＲＩＤ”）、
・任意の選択肢として、ユーザーの識別記号（属性＜ＵｓｅｒＩｄ＞）。
【００３６】
ユーザーはまた、ネットワークで既に記録されたＡＶコンテンツの削除を求めることもでき（データ構造＜Ｒｅｃｏｒｄｅｄ＿Ｃｏｎｔｅｎｔ＿Ｄｅｌｅｔｅ＞）、その際には以下のことを表記する。
・好ましくは、受け入れた記録注文の識別記号（属性“ｒｅｑｕｅｓｔＩｄ”）、
・任意の選択肢として、記録対象のコンテンツの識別記号（属性“ＣＲＩＤ”）、
・任意の選択肢として、ユーザーの識別記号（属性＜ＵｓｅｒＩｄ＞）。
【００３７】
図１を参照しつつ全体として以上に示した記録方法の手順を、これからさらに詳細に図２から７を参照しつつ説明していく。
【００３８】
１．あるネットワークレコーダーのウェブ・サイトからの、ネットワークでの視聴覚コンテンツの記録。
【００３９】
１．１．ウェブ・サイトでネットワークレコーダーを見つける。
【００４０】
視聴覚コンテンツのレコーダーは、そのレコーダーのウェブ・サイトでＨＴＭＬページにより知ることができる。
【００４１】
そのウェブ・ページ上に表記されたリンクをクリックすると、ユーザーの端末がある特定のＭＩＭＥタイプが付いているファイルを受信する：“ａｐｐｌｉｃａｔｉｏｎ／ｘ−ＴＶ−Ｒｅｃｏｒｄ−Ｓｅｒｖｉｃｅ−Ｄｅｃｌａｒａｔｉｏｎ”。
【００４２】
その代わりに得られるファイルの内容となる情報は以下のようなものである。
・好ましくは、ネットワーク上のそのレコーダーのアドレス（要素＜ＲｅｃｏｒｄＳｅｒｖｉｃｅＡｄｄｒｅｓｓ＞）、
・好ましくは、記録可能な配信チャンネルの一覧表（要素＜ＤｅｌｉｖｅｒｙＳｅｒｖｉｃｅＬｉｓｔ＞）で、各チャンネルにつき以下のことを内容とするもの。
＊好ましくは、ＴＶ−Ａｎｙｔｉｍｅフォーラム（属性“ｓｅｒｖｉｃｅＵＲＬ”）により規定された通りの配信チャンネルのアドレス、
＊任意の選択肢として、その配信チャンネルにつきレコーダーが請求する料金（要素＜ＣｈａｒｇｉｎｇＰｏｌｉｃｙ＞）、
・任意の選択肢として、レコーダーの変換能力（要素＜ＣｏｎｖｅｒｓｉｏｎＣａｐａｂｉｌｉｔｉｅｓ＞）で、その能力というのは分解すると、
＊ビットレートを削減できる可能性（要素＜ＢｉｔｒａｔｅＣｏｎｖｅｒｓｉｏｎＣａｐａｂｉｌｉｔｙ＞）と、
＊視聴覚コンテンツを様々な視聴覚のコード化フォーマットに変換することのできる可能性（要素＜ＴｒａｎｓｃｏｄｉｎｇＣａｐａｂｉｌｉｔｙ＞）とに分かれる。
・任意の選択肢として、いったん記録が行われると、コンテンツをユーザーの端末に向けて転送するためにサポートされているプロトコル（初期状態では、ＦＴＰモードか他にもう一つだけが常に提案されることになることが考えうる）。
【００４３】
ネットワークでのレコーダーの宣言のファイルの例は以下の通り。<TV＿Record＿Service＿Declaration xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="TVRecServ.xsd" version="1">
<RecordServiceAddress>http://www.voila.fr/RecordRequest.rr</RecordServiceAddress>
<ConversionCapabilities>
<BitrateConversionCapability>true</BitrateConversionCapability>
<TranscodingCapability>MPEG-1</TranscodingCapability>
<TranscodingCapability>MPEG-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"/>
</DeliveryServiceList>
</TV＿Record＿Service＿Declaration>
【００４４】
この表により、コンテンツの配達サービスについて要素＜ＲｅｃｏｒｄＳｅｒｖｉｃｅＡｄｄｒｅｓｓ＞で表記されたアドレスに注文することのできる配信視聴覚コンテンツのレコーダーか、要素＜ＤｅｌｉｖｅｒｙＳｅｒｖｉｃｅＵＲＬ＞で表記される配信チャンネル（テレビ・チャンネル）を宣言することができる。
【００４５】
そういうわけで、ユーザーが、そのように宣言された配信チャンネルの一つで配信されるコンテンツの記録を望む場合には、選んだコンテンツを配信するチャンネルを直接受信できない場合、あるいは、コンテンツが配信される時刻には受信することができない場合には、ユーザーの端末で、要素＜ＲｅｃｏｒｄＳｅｒｖｉｃｅＡｄｄｒｅｓｓ＞の中に表記されたアドレスに、そのコンテンツの記録を注文することができる。
【００４６】
１．２．ネットワークでの記録をユーザーが注文する。
【００４７】
あるユーザーがあるネットワークレコーダーに頼みたいと思う理由が、前の段階で、ある特定の配信チャンネルが配信する視聴覚コンテンツをそのネットワークレコーダーが自分のために記録することができることを知ったからであるという場合には、そのユーザーは、その業者に、上記に規定した一覧表の要素＜ＲｅｃｏｒｄＳｅｒｖｉｃｅＡｄｄｒｅｓｓ＞で表記されたアドレスに、注文＜ＴＶ＿Ｒｅｃｏｒｄ＿Ｓｅｒｖｉｃｅ＿Ｒｅｑｕｅｓｔ＞を、以下の情報を添えて送らなければならない。
・好ましくは、ユーザーの識別記号（属性“ＵｓｅｒＩｄ”）、
・任意の選択肢として、記録後のコンテンツを転送するために使用すべきプロトコルの識別記号、
・任意の選択肢として、記録対象のコンテンツのために希望するコード化の識別記号（これによりレコーダーの内部でコード変換を頼むことができる）、
・好ましくは、記録対象のコンテンツの識別記号（属性“ＣＲＩＤ”）、
・任意の選択肢として、そのコンテンツのインスタンスの識別記号で、それは以下のものから構成される。
＊好ましくは、そのテレビ・チャンネルの識別記号（属性“ｓｅｒｖｉｃｅＵＲＬ”）と、
＊好ましくは、開始時刻（属性“ｓｔａｒｔ”）と、
＊好ましくは、終了時刻（属性“ｅｎｄ”）あるいは継続時間（属性“ｄｕｒａｔｉｏｎ”）と、
＊任意の選択肢として、特別のインスタンスの識別記号（属性“ｉｎｓｔａｎｃｅＭｅｔａｄａｔａＩｄ”）
【００４８】
二つのコンテンツをネットワークで記録する注文のファイルで、ＦＴＰで記録されたコンテンツを回収するプロトコルを用い、テレビ・チャンネル“ｄｖｂ：／／１．４ｅｅ２．３ｆ５／”でのコンテンツ“ｃｒｉｄ：／／ｈｂｃ．ｃｏｍ／ｆｏｘｅｓ／ｅｐｉｓｏｄｅ１１”と、チャンネル“ｄｖｂ：／／１．４ｅｅ２．３ｆ４；４ｆ５／”でのコンテンツ“ｃｒｉｄ：／／ｃｈ１．ｃｏｍ／ｓｅｒｉｅ／ｅｐ１２”について、最大ビットレートが毎秒１５００ｋｂｉｔでＭＰＥＧ−４にコード変換する例を以下に示す。
<TV＿Record＿Service＿Request xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="TVRecServ.xsd" userId="X3YZDFdeGH49">
<RequestedTransferProtocol>FTP</RequestedTransferProtocol>
<Transcoding>MPEG-4</Transcoding>
<MaxBitRate>1500</MaxBitRate>
<ContentIdentification crid="crid://hbc.com/foxes/episode11" serviceURL="dvb:// 1. 4ee2.3f5/" start="2001-04-07T19:00:00.00+01:00" duration="PT1H30M"/>
<ContentIdentification crid="crid://ch1.com/serie/ep12" serviceURL="dvb://1.4ee2. 3f4;4f5/" start="2003-06-27T12:30:00.00+01:00" duration="PT0H30M" instanceMetadataId="imi:broadcast/1"/>
</TV＿Record＿Service＿Request>
【００４９】
記録対象の各コンテンツの識別は、コンテンツのＣＲＩＤ、コンテンツを届けることになるｓｅｒｖｉｃｅＵＲＬ、その開始時刻と継続時間（または終了時刻）そして場合によってはそのインスタンスの識別記号で行う。
【００５０】
代わりに記録を注文した各コンテンツにつき回答＜ＴＶ＿Ｒｅｃｏｒｄ＿Ｓｅｒｖｉｃｅ＿Ｒｅｑｕｅｓｔ＿Ｒｅｓｐｏｎｓｅ＞は以下のことを内容とする。
・記録注文を受け入れた旨の意思表示（要素＜ＲｅｃｏｒｄＲｅｑｕｅｓｔＳｕｃｃｅｓｓ＞）（図２）で、以下のことを内容とするもの。
＊好ましくは、受け入れた記録注文の識別記号（属性“ｒｅｑｕｅｓｔＩｄ”）、
＊同一の注文で複数のコンテンツを注文した場合、好ましくは、注文したコンテンツの識別記号（属性“ＣＲＩＤ”）、
＊コンテンツを一つだけ注文した場合、任意の選択肢として、注文したコンテンツの識別記号（属性“ＣＲＩＤ”）、
＊任意の選択肢として、記録の終了設定時刻（属性“ｒｅｃｏｒｄＥｎｄＴｉｍｅ”）、
＊任意の選択肢として、記録されたコンテンツの保存継続期間（属性“ｋｅｅｐＤｕｒａｔｉｏｎ”）、
＊任意の選択肢として、記録費用（属性“ｒｅｃｏｒｄＣｏｓｔ”と“Ｃｕｒｒｅｎｃｙ”）、
・あるいは、記録注文を断る旨の意思表示（要素＜ＲｅｃｏｒｄＲｅｑｕｅｓｔＦａｉｌｕｒｅ＞）（図３）で、以下のことを内容とするもの。
＊同一の注文で複数のコンテンツを注文した場合、好ましくは、求められたコンテンツで断られたものの識別記号（属性“ＣＲＩＤ”）、
＊コンテンツを一つだけ注文した場合、任意の選択肢として、注文したコンテンツの識別記号（属性“ＣＲＩＤ”）、
＊任意の選択肢として、断る理由（属性“ＫＯｒｅａｓｏｎ”）。
【００５１】
ある記録注文に対し、二つのコンテンツについて（二番目のものには保存継続期間と支払うべき費用の表示をつけて）受け入れ、他の二つについては断る旨の回答の例を以下に示す。
<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" requestId="12456XD34"
recordEndTime="2003-04-07T20:30:00.00+01:00"/>
<RecordRequestSuccess crid="crid://zzz.com/movie/title1" requestId="156WQ77" recordEndTime="2003-04-07T20:30:00.00+01:00" keepDuration="PT24H" recordCost="2" currency="USD"/>
<RecordRequestFailure crid="crid://ch1.com/serie/ep12" KOreason="unknownCRID"/>
<RecordRequestFailure crid="crid://chaine5.com/film15" KOreason="unavailableServiceURL"/>
</TV＿Record＿Service＿Request＿Response>
【００５２】
１．３．ネットワークでの記録注文の管理。
【００５３】
ネットワークである記録注文を受け入れた後、ネットワークレコーダーは、ＡＶコンテンツの配信のスケジュールに発生する可能性のある変更について知っておき、それに応じて注文されたコンテンツの記録を組み直す手段をもっている。
【００５４】
ネットワークで記録注文が受け入れられた後、ユーザーには以下のように幾つかの選択肢が可能である。
・（費用があまりに高額であったり、気が変わったりした場合）自分の出した記録注文を取り消す、
・（そのコンテンツが他の日付や時刻に組み直されたかどうか、あるいはその記録が完了したかどうかを知るために）自分の出した記録注文の現状について問い合わせる。
【００５５】
記録注文を取り消すには、ユーザーは「注文を取り消す」という注文（データ構造＜ＴＶ＿Ｒｅｃｏｒｄ＿Ｒｅｑｕｅｓｔ＿Ｃａｎｃｅｌ＞）（図５）を送らなければならないが、その内容は以下のものである。
・好ましくは、受け入れた記録注文の識別記号（属性“ｒｅｑｕｅｓｔＩｄ”）、
・任意の選択肢として、記録対象のコンテンツの識別記号（属性“ＣＲＩＤ”）、
・任意の選択肢として、ユーザーの識別記号（属性＜ＵｓｅｒＩｄ＞）。
【００５６】
記録依頼の取り消しの注文の例を以下に示す。
<TV＿Record＿Request＿Cancel xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="TVRecServ.xsd" crid="crid://hbc. com/foxes/episode11" requestId="12456XD34"/>
レコーダーからの回答は予定されていない。
【００５７】
記録注文の現状を知るためには、ユーザーが「記録状態の問い合わせ」というリクエスト（データ構造＜ＴＶ＿Ｒｅｃｏｒｄ＿Ｒｅｑｕｅｓｔ＿Ｓｔａｔｕｓ＿Ｒｅｑｕｅｓｔ  ＞）（図２）を送らなければならないが、そのリクエストの内容は以下のものである。
・好ましくは、受け入れた記録注文の識別記号（属性“ｒｅｑｕｅｓｔＩｄ”）、
・任意の選択肢として、記録対象のコンテンツの識別記号（属性“ＣＲＩＤ”）、
・任意の選択肢として、ユーザーの識別記号（属性＜ＵｓｅｒＩｄ＞）。
【００５８】
「記録状態の問い合わせ」というリクエストの例を以下に示す。
<TV＿Record＿Request＿Status＿Request xmlns:xsi="http://www.w3. org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="TVRecServ.xsd" crid="crid://hbc. com/foxes/episode11" requestId="12456XD34"/>
【００５９】
いくつもの回答が可能である。コンテンツがまだ記録されていない場合（図４）、レコーダーからの回答の内容は以下のようになる。
・好ましくは、受け入れた記録注文の識別記号（属性“ｒｅｑｕｅｓｔＩｄ”）、
・好ましくは、注文の現状（属性“ｓｔａｔｕｓ”、値“ｒｕｎｎｉｎｇＲｅｑｕｅｓｔ”）、
・任意の選択肢として、記録対象のコンテンツの識別記号（属性“ＣＲＩＤ”）、
・任意の選択肢として、終了が設定されている日付と時刻（属性“ｃａｌｌＡｆｔｅｒ”）。
【００６０】
「コンテンツがまだ記録されていない」という回答の一例は以下の通り。
<TV＿Record＿Request＿Status＿Response xmlns:xsi="http://www.w3. org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="TVRecServ.xsd" crid="crid://hbc. com/foxes/episode11"
requestId="12456XD34" status="runningRequest" callAfter="2003-06-27T14:30: 00.00+01:00"/>
【００６１】
属性“ｃａｌｌＡｆｔｅｒ”により、端末でタイマーの設定をすることができ、リクエストへの回答が異なったものになる可能性がある場合には、それにより、記録状態についてのリクエストをやり直すことができる。コンテンツの配信時間が変更された場合がそれに当てはまる。
【００６２】
そのリクエストが有効なものと認識されない場合には（図７）、そのレコーダーからの回答の内容は以下のようなものになる。
・好ましくは、受け入れた記録注文の識別記号（属性“ｒｅｑｕｅｓｔＩｄ”）、
・好ましくは、注文の現状（属性“Ｓｔａｔｕｓ”、値“ｕｎｋｎｏｗｎＲｅｑｕｅｓｔ”）、
・任意の選択肢として、記録対象のコンテンツの識別記号（属性“ＣＲＩＤ”）。
【００６３】
不明な記録注文についてのレコーダーからの回答の一例は以下の通り。
<TV＿Record＿Request＿Status＿Response xmlns:xsi="http://www.w3. org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="TVRecServ.xsd" crid="crid://hbc. com/foxes/episode11"
requestId="12456XD34" status="unknownRequest"/>
【００６４】
それが発生しうるのは、記録されたコンテンツの保存期限満了の日付後に、ユーザーの端末からネットワークレコーダーに問い合わせがあった場合である。
【００６５】
そのリクエストがなんらかの理由で失敗した場合には、レコーダーはそれに応えて、
・好ましくは、受け入れた記録注文の識別記号（属性“ｒｅｑｕｅｓｔＩｄ”）、
・好ましくは、注文の現状（属性“ｓｔａｔｕｓ”、値“ｆａｉｌｅｄＲｅｑｕｅｓｔ”）、
・任意の選択肢として、記録対象のコンテンツの識別記号（属性“ＣＲＩＤ”）。
【００６６】
失敗に終わった記録注文についてのレコーダーからの回答の一例は以下の通り。
<TV＿Record＿Request＿Status＿Response xmlns:xsi="http://www.w3. org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="TVRecServ.xsd" crid="crid://hbc. com/foxes/episode11"
requestId="12456XD34" status="failedRequest"/>
【００６７】
記録が終了し、コンテンツが入手可能な場合には、レコーダーからの回答の内容は以下のようなものになる。
・好ましくは、受け入れた記録注文の識別記号（属性“ｒｅｑｕｅｓｔＩｄ”）、
・好ましくは、注文の現状（属性“ｓｔａｔｕｓ”、値“ｃｏｎｔｅｎｔＡｖａｉｌａｂｌｅ”）、
・任意の選択肢として、記録対象のコンテンツの識別記号（属性“ＣＲＩＤ”）、
・任意の選択肢として、レコーダーに記録されたコンテンツの保存継続期間（属性“ｋｅｅｐＤｕｒａｔｉｏｎ”）、
・好ましくは、記録されたコンテンツの回収手段（属性“ｃｏｎｔｅｎｔＵＲＬ”）。
【００６８】
レコーダーに記録されたコンテンツについてのレコーダーからの回答の一例は以下の通りである。
<TV＿Record＿Request＿Status＿Response xmlns:xsi="http://www.w3. org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="TVRecServ.xsd" crid="crid://hbc. com/foxes/episode11"
requestId="12456XD34" status="contentAvailable"
contentURL="ftp://login:password@ftp.tvrs.fr/user1/av12.mpg"/>
【００６９】
１．４．ネットワークで記録したコンテンツの転送と削除
【００７０】
レコーダーが、コンテンツ記録の注文の現状についてのリクエストに応えて、コンテンツが入手可能であることを示す場合には、ユーザーの端末は、そのコンテンツをダウンロードで回収することができ、レコーダーからの回答からそのアドレスが属性＜ｃｏｎｔｅｎｔＵＲＬ＞により示される。
【００７１】
ネットワークにおける記録は、一定期間保存された後、自動的に削除されるか、あるいは、以下のような内容の端末からの明示の注文により、削除される。
・好ましくは、受け入れた記録注文の識別記号（属性“ｒｅｑｕｅｓｔＩｄ”）、
・任意の選択肢として、記録対象のコンテンツの識別記号（属性“ＣＲＩＤ”）、
・任意の選択肢として、ユーザーの識別記号（属性“ＵｓｅｒＩｄ”）。
【００７２】
ネットワークでの記録の削除の注文の一例は以下の通り。
<Recorded＿Content＿Delete xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="TVRecServ.xsd" crid="crid://hbc. com/foxes/episode11"
requestId="12456XD34"/>
レコーダーからの回答は予定されていない。
【００７３】
２．ＵＤＤＩとＳＯＡＰによりネットワークレコーダーが視聴覚コンテンツを記録する。
【００７４】
２．１．ＵＤＤＩによるネットワークレコーダーの宣言（ウェブ・サービス）
【００７５】
ウェブ・サービスの技術と特にＵＤＤＩ（Ｕｎｉｖｅｒｓａｌ  Ｄｅｓｃｒｉｐｔｉｏｎ，Ｄｉｓｃｏｖｅｒｙ  ａｎｄ  Ｉｎｔｅｇｒａｔｉｏｎ）により、配信チャンネルによりネットワークで配信される視聴覚コンテンツのレコーダーは、ＵＤＤＩビジネスレジストリというレジストリに登録できるようになっている。
【００７６】
ＳＯＡＰ（Ｓｉｍｐｌｅ  Ｏｂｊｅｃｔ  Ａｃｃｅｓｓ  Ｐｒｏｔｏｃｏｌ）技術によりＸＭＬタイプのデータ構造の交換が可能となる。
【００７７】
このＵＤＤＩレジストリに登録することができなければならないのは、
・新しいカテゴリ（またはそのエントリ）のサービス：アクセス・ポイントと、そこで受け入れるユーザー端末の操作を付記したネットワークでの視聴覚コンテンツの記録サービスと、
・検索の基準：各配信チャンネル（テレビ・チャンネル）の識別記号
である。
【００７８】
そういうわけで、ネットワークレコーダーを探し求めるユーザー端末は、レジストリへの問い合わせに際して、一つまたは複数の配信チャンネル（テレビ・チャンネル）の識別記号を示し、その代わりに検索の基準に対応するレコーダーに直接問い合わせる手段を求める。
【００７９】
ＵＤＤＩレジストリの中の新しい検索基準を構成するのはテレビ・チャンネルの識別記号なのだが、それは、例えば、（“ｔＭｏｄｅｌ”を規定したＵＤＤＩ仕様書のセクション１．６．４に則って）ここでは“ｓｅｒｖｉｃｅＵＲＬ”と呼ばれる新しいＵＤＤＩｔＭｏｄｅｌの規定の対象とならなければならず、それにより、視聴覚コンテンツの配信チャンネルを宣言することになる。それに“ｔｖ−ｒｅｃｏｒｄ−ｏｒｇ：ｓｅｒｖｉｃｅＵＲＬ”の名称を与えることになる。それは、この新しい“ｔＭｏｄｅｌ”の記録を求めるはずの機関である。“ｔｖ−ｒｅｃｏｒｄ−ｏｒｇ”という構成要素は、どんなものでもよくて、“ｔｖ−ａｎｙｔｉｍｅ−ｏｒｇ”でもその他でもよい。これは、結果として、同一の名称“ｕｄｄｉ：ｔｖ−ｒｅｃｏｒｄ．ｏｒｇ：ｓｅｒｖｉｃｅＵＲＬ”のキーを宣言するものである。
【００８０】
このキーを宣言することにはまた、その内容として、その紹介を求める機構によるこの“ｔＭｏｄｅｌ”の仕様書に付された参照記号“＜ｏｖｅｒｖｉｅｗＤｏｃ＞＜ｏｖｅｒｖｉｅｗＵＲＬ＞”も含み、要素“＜ｃａｔｅｇｏｒｙＢａｇ＞”には、“ｔＭｏｄｅｌ”のどんな宣言にもある標準的な情報が含まれる。
<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>
<overviewURL useType="text">
ftp://pub:pub@ftp.francetelecom.fr/pub/Spec/Record＿tModel.zip
</overviewURL>
</overviewDoc>
<categoryBag>
<keyedReference keyName="uddi-org:types:categorization"
keyValue="categorization" tModelKey="uddi:uddi.org:categorization:types"/>
<keyedReference keyName="uddi-org:types:unchecked"
keyValue="unchecked" tModelKey="uddi:uddi.org:categorization:types"/>
</categoryBag>
</tModel>
【００８１】
視聴覚コンテンツのレコーダーにリクエストを送付するために“ｔＭｏｄｅｌ  ｐｏｒｔ”を規定することも必要であり、それは次のようなものである。この「ｔＭｏｄｅｌ」は、注文をネットワークでコンテンツレコーダーに転送するサービス“ｓｕｂｍｉｔ＿Ｄａｔａ”を記述するものであり、その用途は後に図解することになる。
<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="wsdlInterface">
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>
<keyedReference keyName="uddi-org:types:wsdl" keyValue="wsdlSpec"
tModelKey="uddi:uddi.org:categorization:types"/>
<keyedReference keyName="uddi-org:types:soap" keyValue="soapSpec"
tModelKey="uddi:uddi.org:categorization:types"/>
<keyedReference keyName="uddi-org:types:xml" keyValue="xmlSpec"
tModelKey="uddi:uddi.org:categorization:types"/>
<keyedReference keyName="uddi-org:types:specification"
keyValue="specification" tModelKey="uddi:uddi.org:categorization:types"/>
</categoryBag>
</tModel>
【００８２】
配信される視聴覚コンテンツのレコーダーは、自己の存在を知らしめるために、前記に規定した「ｔＭｏｄｅｌ」を参照しつつ、（適切な母体となる構造“ｂｕｓｉｎｅｓｓＥｎｔｉｔｙ”と“ｂｕｓｉｎｅｓｓＳｅｒｖｉｃｅ”とが既に宣言されていることを前提として）“ｓａｖｅ＿ｂｉｎｄｉｎｇ”と呼ばれる（ＵＤＤＩ発行ＡＰＩの）方法を用いて記録を行う上での可能な選択肢を宣言しなければならない。
【００８３】
<save＿binding xmlns="urn:uddi-org:api＿v3">
<bindingTemplate>
【００８４】
【表１】
2007527151.tif 000003
【００８５】
<accessPoint useType="endPoint">
http://www.voila.fr/movies
</accessPoint>
<tModelInstanceDetails>
<tModelInstanceInfo 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="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"/>
</DeliveryServiceList>
</describe＿submit＿Data＿Result>
]]></instanceParms>
</instanceDetails>
</tModelInstanceInfo>
</tModelInstanceDetails>
<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>
【００８６】
要素＜ａｃｃｅｓｓＰｏｉｎｔ＞がもたらすレコーダーのｈｔｔｐアドレスは、リクエスト“ｓｕｂｍｉｔ＿Ｄａｔａ”の送付先となるはずのアドレスである。
【００８７】
要素＜ｉｎｓｔａｎｃｅＰａｒｍｓ＞の内容となる宣言は、レコーダーから何を期待できるのか（第一の実施態様のために規定されたデータ構造＜ＴＶ＿Ｒｅｃｏｒｄ＿Ｓｅｒｖｉｃｅ＿Ｄｅｃｌａｒａｔｉｏｎ＞の内容）を宣言するものであり、それが規定するのは、コード変換、ビットレート削減、転送プロトコルの様々な可能性、記録可能な配信チャンネルの一覧表と料金に関する条件である。
【００８８】
要素＜ｃａｔｅｇｏｒｙＢａｇ＞の内容は、レコーダーが記録可能な配信チャンネルの一覧表である。
【００８９】
２．２．ウェブ・サービスでそのネットワークレコーダーを見つける。
【００９０】
ウェブ・サービスの技術と特にＵＤＤＩ（Ｕｎｉｖｅｒｓａｌ  Ｄｅｓｃｒｉｐｔｉｏｎ，  Ｄｉｓｃｏｖｅｒｙ  ａｎｄ  Ｉｎｔｅｇｒａｔｉｏｎ）により、端末で、インターネットへの接続を利用して、前もって知らなくても、このレジストリに問い合わせて、配信されている視聴覚コンテンツのレコーダーを見つけることもできるようになっている。
【００９１】
従って、どんな端末でも、（よく知られたアドレスの載っている）ＵＤＤＩビジネスレジストリのノードを利用して、以下に図解されたような注文＜ｆｉｎｄ＿ｂｉｎｄｉｎｇ＞により、配信されている視聴覚コンテンツのレコーダーを見つけることができる。
<find＿binding xmlns="urn:uddi-org:api＿v3">
<tModelBag>
<tModelKey>uddi:tv-record.org:submit＿Data＿v10</tModelKey>
</tModelBag>
<categoryBag>
<keyedReference tModelKey="uddi:tv-record.org:serviceURL"
keyValue="dvb://1.2.a"/>
<keyedReference tModelKey="uddi:tv-record.org:serviceURL"
keyValue="dvb://1.2.c"/>
</categoryBag>
</find＿binding>
【００９２】
この例では、端末が検索するネットワークレコーダーは、“ｄｖｂ：／／１．２．ａ”と“ｄｖｂ：／１．２．ｃ”という参照記号の付いた配信チャンネルかテレビ・チャンネル用のものである。
【００９３】
それに応答して、端末が受信することになる（注文＜ｓａｖｅ＿ｂｉｎｄｉｎｇ＞でサービスレジストリに記録された）＜ｂｉｎｄｉｎｇＴｅｍｐｌａｔｅ＞の一覧表がそのリクエストに応える。
【００９４】
２．３．ネットワークでの記録注文
【００９５】
視聴覚コンテンツのレコーダーを一つ選んだ後、端末から以下のリクエストをＳＯＡＰ（Ｓｉｍｐｌｅ  Ｏｂｊｅｃｔ  Ａｃｃｅｓｓ  Ｐｒｏｔｏｃｏｌ）を用いて送ることができ、それにより、（前述の実施態様における注文＜ＴＶ＿Ｒｅｃｏｒｄ＿Ｓｅｒｖｉｃｅ＿Ｒｅｑｕｅｓｔ＞を封入して）コンテンツの記録を注文することができる。
POST /tvr/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" userId="XcGHJ63DX">
<RequestedTransferProtocol>FTP</RequestedTransferProtocol>
<Transcoding>MPEG-4</Transcoding>
<MaxBitRate>1500</MaxBitRate>
<ContentIdentification crid="crid://hbc.com/foxes/episode11"
serviceURL="dvb:// 1.4ee2.3f5/"
start="2001-04-07T19:00:00.00+01:00" duration="PT1H30M"/>
<ContentIdentification crid="crid://ch1.com/serie/ep12"
serviceURL="dvb://1.4ee2.3f4;4f5/"
start="2003-06-27T12:30:00.00+01:00" duration="PT0H30M"
instanceMetadataId="imi:broadcast/1"/>
</TV＿Record＿Service＿Request>
</submit＿Data>
</Body>
</Envelope>
【００９６】
その代わりに、端末は、受け入れられた記録注文と、その他の断られた注文とともに、以下の回答を受け取ることになる。
HTTP/1.1 200 OK
Content-Type: text/xml; charset="utf-8"
Content-Length: nnnn
Content-Encoding: deflate
<?xml version="1.0" encoding="UTF-8"?>
<Envelope xmlns="http://www.w3.org/2002/06/soap-envelope">
<Body>
<submit＿Data＿Result xmlns=" http://schemas.xmlsoap.org/soap/envelope/">
<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"
requestId="12456XD34"
recordEndTime="2003-04-07T20:30:00.00+01:00"/>
<RecordRequestSuccess crid="crid://zzz.com/movie/title1"
requestId="156WQ77"
recordEndTime="2003-04-07T20:30:00.00+01:00"
keepDuration="PT24H" recordCost="2" currency="USD"/>
<RecordRequestFailure crid="crid://ch1.com/serie/ep12"
KOreason="unknownCRID"/>
<RecordRequestFailure crid="crid://chaine5.com/film15"
KOreason="unavailableServiceURL"/>
</TV＿Record＿Service＿Request＿Response>
</submit＿Data＿Result>
</Body>
</Envelope>
【００９７】
同様の方法で、ネットワークで視聴覚コンテンツを記録するその他の手順についても、前記実施態様において規定された他の注文の封入も実行していく。
【図面の簡単な説明】
【００９８】
【図１】本発明の記録方法の全体的なフローチャートである。
【図２】記録の注文がうまくいった場合の本発明の記録方法のフローチャートである。
【図３】記録の注文が断られた場合の本発明の記録方法のフローチャートである。
【図４】記録の注文が断られた場合の本発明の記録方法のフローチャートである。
【図５】取り消した後で記録の注文がうまくいった場合の本発明の記録方法のフローチャートである。
【図６】記録が失敗した後で記録の注文がうまくいった場合の本発明の記録方法のフローチャートである。
【図７】記録の注文が未知のものである場合の本発明の記録方法のフローチャートである。
【図１】
2007527151.tif 000004
【図２】
2007527151.tif 000005
【図３】
2007527151.tif 000006
【図４】
2007527151.tif 000007
【図５】
2007527151.tif 000008
【図６】
2007527151.tif 000009
【図７】
2007527151.tif 000010
【国際調査報告】
2007527151.tif 000011
2007527151.tif 000012
2007527151.tif 000013
2007527151.tif 000014
2007527151.tif 000015
2007527151.tif 000016