(57)【要約】  本発明は、コンテンツサーバデバイスと、コンテンツ受信器デバイスと、前記デバイスにおいてロバストモードでコンテンツを送信する方法とに関する。特に、本発明は、ピア・ツー・ピアクライアントにおいて、サーバからコンテンツを受信する方法に関する。該方法は、マルチキャストモードでサーバからコンテンツを受信する段階と、正しく受信したコンテンツを前記サーバに知らせる段階と、各ピアにおいて利用できるコンテンツを示すコンテンツ利用可否マップを、前記サーバからマルチキャストモードで受信する段階と、前記コンテンツ利用可否マップに示されたピアに欠けているコンテンツを要求する段階とを有する。
2011521369.tif 000002
【特許請求の範囲】
【請求項１】
クライアントにおけるコンテンツを受信する方法であって、
マルチキャストモードで第１のサーバから複数のコンテンツを受信する段階と、
正しく受信したコンテンツを、第２のサーバに知らせる段階と、
各ピアクライアントにおいて利用できるコンテンツを示すコンテンツ利用可否マップを、第３のサーバからマルチキャストモードで受信する段階と、
前記コンテンツ利用可否マップに示された、前記コンテンツが利用可能なピアクライアントに、欠けているコンテンツを要求する段階と、
を有する方法。
【請求項２】
前記クライアントはその所在を前記サーバに知らせる、
請求項１に記載の方法。
【請求項３】
前記コンテンツ利用可否マップは各ピアクライアントの所在を示す、
請求項１または２に記載の方法。
【請求項４】
前記クライアントは、ピアクライアントに、近いピアクライアントから遠いものに階層的に、前記コンテンツを要求する、
請求項１乃至３いずれか一項に記載の方法。
【請求項５】
前記複数のコンテンツを受信した第１のサーバの識別子を、前記第２のサーバに知らせる段階をさらに有する、
請求項１乃至４いずれか一項に記載の方法。
【請求項６】
FLUTEプロトコルを用いて前記複数のコンテンツを受信する、
請求項１乃至５いずれか一項に記載の方法。
【請求項７】
FLUTEプロトコルを用いて前記コンテンツ利用可能マップを受信する、
請求項１乃至６いずれか一項に記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ビデオ・オン・デマンドの配信に関し、特にビデオ・オン・デマンドを複数の受信器に配信する方法に関する。
【背景技術】
【０００２】
このセクションは、以下に説明して特許を請求する本発明の様々な態様に関連する様々な態様の技術を読者に紹介することを意図するものである。この説明は、本発明の様々な態様の理解を容易にする背景情報を読者に提供する役に立つと思われる。従って、言うまでもなくこれらの記載は上記を考慮して読むべきであり、先行技術として認めるものではない。
【０００３】
DVB-IPコンテンツダウンロードシステムタスクフォースは、インターネットサービスプロバイダの管理の下に、DSLネットワークなどの管理されたIPネットワークにより、セットトップボックスやレジデンシャルホームゲートウェイなどのホームネットワークデバイスのローカル記憶へのコンテンツのダウンロードに基づく、ビデオ・オン・デマンドサービス用の標準策定をしている。CDS商用要件が編集され、DVB-CM  IPTVグループのCM-IPTV０１０２r１５「IPTVコンテンツのダウンロード及びローカル記憶の管理に関する商用要件」にまとめられた。CDS仕様書はDVB-IPTV仕様書に組み込まれており、これは次のETSI  TS  １０２  ０３４  v１．４．１文書の公開までは、DVBブルーブックA０８６  Rev．７  September  ２００８として入手可能である。
【０００４】
CDS仕様書の主な特徴は以下の通りである：
−２つのVODサービスモードを提供する：
−サービスプロバイダにより起動され、コンテンツ全体のダウンロードに基づくプッシュサービスモード；大ヒット作に適用される；
−ユーザ起動によるコンテンツダウンロードに基づくプルサービスモード；大ヒット作以外のすべてのコンテンツに適用される。
−これらの２つのサービスモードは３つの基本的なコンテンツダウンロードメカニズムに依存する：
−RFC３９２６で規定されたFile  Delivery  over  Unidirectional  Transport(FLUTE)プロトコルを用いるマルチキャスト；
−HTTPプロトコルを用いるユニキャスト；
−いくつかのピアクライアントによりコンテンツダウンロードを配信するために、これらのピアクライアントへのHTTPリクエストのリディレクションに基づく専用のプロトコルを用いるピア・ツー・ピア（Ｐ２Ｐと書く）。
−各サービスは複数のダウンロードメカニズムのいずれか、またはその組み合わせを用いることができる。例えば、プッシュサービスは、クライアントデバイスにコンテンツをプッシュするマルチキャストプロトコルと、マルチキャスト配信フェーズ中のエラーを回復するＰ２Ｐプロトコルとを用いて実現できる。プルサービスは、HTTPプロトコルを用い、１つのコンテンツに対するユーザ要求の数が大幅に増大した場合にマルチキャスト配信またはＰ２Ｐ配信にリディレクションして実現できる。
−SD&S/BCGを用いて、サービスタイプごとの利用できるコンテンツと、それをダウンロードするプロトコルとをアナウンスする。SD&S/BCGは、ユニキャスト(HTTP)またはマルチキャスト(DVB-STP)プロトコルベースの宣言をサポートする。CDSサービス宣言を許容するSD&S/BCG仕様は、DVBブルーブックA０８６  Rev．７  September  ２００８に記載されている。
【０００５】
CDS仕様書は、クライアントのローカル記憶へのコンテンツ全体のプロアクティブダウンロードに基づくプッシュサービスモードを提案している。かかるサービスモードによりユーザはコンテンツに瞬時にアクセスできるので、大ヒット作の配信に非常に適している。しかし、コンテンツ全体が各クライアントで複製されるので、このサービスモードはデバイス記憶の利用に関して制約がある。一方、CDSは、プロアクティブコンテンツダウンロードを伴わないプルサービスモードも提案している。プルサービスはすべてのコンテンツの配信に利用される。しかし、大ヒット作は、ユーザがコンテンツにアクセスできる前に、ダウンロード遅延時間が必要である。
【０００６】
目標を絞ったプロアクティブなコンテンツプッシュストラテジを伴うＰ２Ｐは、基本的に、ネットワーク上のピアにコンテンツフラグメントをプロアクティブに配信するユニキャストプロトコルを用いる。さらに、多くのＰ２Ｐプロトコルは、要求コンテンツを提供できるピアを探すフェーズにおいても、これらのピアから要求コンテンツをダウンロードするフェーズと同様に、ユニキャストプロトコルを用いる。(例えば、インターネットなどの管理されていない環境において)マルチキャストなど他のプロトコルが利用できない場合、またはソリューションの主な設計上の制約の１つがピア記憶の最適化であるが、それにより各ピアが異なるコンテンツフラグメントを記憶することとなり、結果としてマルチキャストプロトコルを利用することが効率的でないソリューションになってしまう場合には、ユニキャストプロトコルの利用は非常に妥当である。
【発明の概要】
【発明が解決しようとする課題】
【０００７】
本発明は、コンテンツ利用可否マップの配信方法を提供することにより、先行技術におけるコンテンツ配信に伴う問題の少なくとも一部を解消しようとするものである。
【課題を解決するための手段】
【０００８】
本発明は、サーバからコンテンツを受信するピア・ツー・ピアクライアントにおける方法である。該方法は、マルチキャストモードでサーバからコンテンツを受信する段階と、正しく受信したコンテンツを前記サーバに知らせる段階と、各ピアにおいて利用できるコンテンツを示すコンテンツ利用可否マップを、前記サーバからマルチキャストモードで受信する段階と、前記コンテンツ利用可否マップに示されたピアに欠けているコンテンツを要求する段階とを有する。
【０００９】
欠けているコンテンツをピア受信器から回復するために、受信器はピア受信器において利用できるコンテンツを知らされる。受信器は、欠けているファイルをサーバに要求する必要がない。受信器は、サーバに問い合わせせずに、正しいピアに直接問い合わせできる。
【００１０】
CDS仕様書は、マルチキャストプロトコルとＰ２Ｐプロトコルとを組み合わせる可能性をサポートしている。かかる組み合わせを用いて、「目標を絞ったプロアクティブなコンテンツプッシュを伴うＰ２Ｐ」配信モードに基づくCDSサービスを効率的に実現できる。かかるサービスは、適度に人気があるコンテンツの配信に適している。これによりサービスオペレータは、クライアントのローカル記憶をよりよく利用して、より多くのコンテンツを提供できる。オペレータが、より多くのコンテンツを含むサービスを提供する時、これは、CDSサービス展開の成功のための大きな問題である。
【００１１】
本発明の他の目的は、コンピュータで実行された時に本発明による方法のステップを実行するプログラムコード命令を有するコンピュータプログラム製品である。「コンピュータプログラム製品」とは、ディスケットやカセットなどの、プログラムを含む記憶スペースだけでなく、電気信号や光信号などの信号におけるコンピュータプログラムサポートを意味する。
【００１２】
開示した実施形態と同じ範囲の態様を以下に記載する。言うまでもなく、これらの態様は、読者に本発明が取り得る形態の簡単な概要を提供するためだけに記載するものであり、本発明の範囲を限定するものではない。実際、本発明は、以下に記載していない様々な態様を包含し得る。
【図面の簡単な説明】
【００１３】
本発明は、添付した図面を参照して以下の実施形態及び実施例により、よりよく理解でき、例示できるであろう。
【図１】実施形態によるネットワークアーキテクチャを示す図である。
【図２】実施形態による、ピアにおいて利用できるコンテンツを示す図である。
【図３】実施形態による、ローカルゾーンごとの、異なるタイプのクライアントデバイスのリパーティションを示す図である。                                      図１乃至３では、表示したブロックは純粋に機能的なものであり、必ずしも物理的なものとして分離していることを示すものではない。すなわち、これらのブロックは、ハードウェアやソフトウェアとして開発してもよいし、集積回路により実施してもよい。
【発明を実施するための形態】
【００１４】
例としての実施形態をCDSとFLUTEのフレームワークで説明するが、本発明はこの具体的な環境に限定されない。本発明は、複数の受信器にコンテンツを配信し、すべての受信器に各受信器で利用できるコンテンツマップを配信する他のフレームワークにも適用できる。受信器は、ピア受信器から、欠けているコンテンツを受信できる。
【００１５】
本発明の実施形態を、DVB-IP/CDSの要件を満たすコンテンツダウンロードシステムについて説明する。ネットワークアーキテクチャフレームワークは、図１に示した管理されたオペレータネットワークに基づく。そのフレームワークは次の構成要素よりなる：
−クライアントデバイスに対してコンテンツを効率的にプッシュできるマルチキャストコンテンツサーバ１
−クライアントデバイスに対して遠隔管理とレポート機能を提供する制御サーバ３
−サービスデリバリの詳細をクライアントにシグナリングする宣言サーバ２
−コンテンツを相互間で協調的に配信し、ユーザにオペレータサービスへのアクセスを提供できる複数のクライアントデバイス１１、１２、１３。
【００１６】
オペレータは、クライアントを登録し、各クライアントに「Client-Type」を割り当てる。クライアントタイプの数は「n」に制限される。この割り当ては、制御サーバとクライアントとの間で実現されるオペレータリモート管理システムにより行われる。
【００１７】
これらの条件では、「目標を絞ったプロアクティブコンテンツプッシュを伴うＰ２Ｐ」デリバリは次のステップで進められる：
ステップ１：コンテンツフラグメントのプロアクティブプッシュ
ステップ１．ａにおいて、このプロアクティブプッシュの各コンテンツは、クライアントタイプと同数のフラグメントに分割され、マルチキャストサーバを用いて、「Client-Type」が同じすべてのクライアントの各フラグメントをプッシュする。この「目標を絞ったプッシュ」は、すべてのタイプのクライアントにすべてのコンテンツフラグメントをトランスポートする１つのマルチキャストFLUTEセッションだけを用いて、またはクライアントタイプごとに１つのマルチキャストFLUTEセッションを用いて、実現できる。
【００１８】
各マルチキャストセッションは、RFC３９２６に記載されている、トランスポートされるコンテンツフラグメントを記述するFLUTEファイルデリバリテーブルインスタンス（FLUTE  FDT）を担う。各コンテンツフラグメントは、FDTインスタンスの「Content_Location」フィールドの「Content-Fragment-URI」により特定される。かかるFDTインスタンスの例を表１に示す。
【００１９】
欧州特許出願第１９０１５２５号に記載されたようなストラテジと、マルチキャストデリバリとＰ２Ｐデリバリとの組み合わせを用いて、このプロアクティブコンテンツフラグメントプッシュの信頼性を高くできる。表１は、マルチキャストセッションでトランスポートされるコンテンツフラグメントを記載するFDTインスタンスを示す。
【００２０】
【表１】
2011521369.tif 000003
2011521369.tif 000004
ステップ１．ｂにおいて、コンテンツフラグメントのダウンロード前に、宣言メカニズムを用いて、クライアントがコンテンツフラグメントにアクセスする詳細情報を、「Client-Type」に応じてマルチキャストセッションでクライアントにプッシュする。かかる宣言データの一例を、「目標を絞ったプッシュ」サービスのSD&S/BCG宣言を示す表２に示す。この宣言はSD&S/BCGプロトコルによりトランスポートされる。この例は、FLUTEマルチキャストデリバリを用い、「Client-Type」フィールドによりダウンロードしなければならないコンテンツフラグメントをクライアントが決定できるCDSサービスタイプの宣言に基づく。この表のその他のフィールドは、最新のCDS仕様書に記載されている。
【００２１】
【表２】
2011521369.tif 000005
2011521369.tif 000006
ステップ１．ｃにおいて、クライアントタイプに対応するフラグメントと、「目標を絞ったプッシュ」セッションのすべてのコンテンツアイテムのフラグメントとを正しく受信すると、各クライアントは、これらのフラグメントを受信したことを制御サーバにレポートしなければならない。バックオフタイミングを用いて、レポート手順の時間にわたり制御サーバの負荷を分散する。この情報により、制御サーバは(クライアントのIPアドレスやClient-Typeなどのパラメータで)クライアントを特定することができる。制御サーバは、クライアントがダウンロードしたコンテンツフラグメント(Content-Fragment-URI)を知ることができる。
【００２２】
コンテンツフラグメント受信レポートメッセージの一例を表３に示す。このメッセージは、CDS仕様書で規定されたレポートメッセージと非常に近いものである。この表のフィールド「Multicast-Delivery-Session-List」と「Recovery-Delivery-Server-Source-List」の利用方法については、CDS仕様書に記載されている。
【００２３】
複数のサーバベースのコンテンツデリバリの場合には、server_source_IDフィールドが、どのサーバがコンテンツをアップロードしたかを示す。
【００２４】
【表３】
2011521369.tif 000007
ステップ２：コンテンツ利用可否マップのプロアクティブプッシュ
ステップ２．ａにおいて、クライアントが「Client-Type」に対応するコンテンツフラグメントをダウンロードし、受信をレポートすると、オペレータは、他のマルチキャストセッションを開始し、または前のマルチキャストセッションを用いて、各クライアントに、他のクライアントにプッシュしたコンテンツフラグメントが利用可能であることを示す情報をプッシュする。これらのコンテンツ利用可能性情報は、レポート手順により関連情報をすべて有している制御サーバにより構成できる。これらのコンテンツ利用可能性情報は、一旦構成されると、マルチキャストサーバに送られ、クライアントデバイスにプッシュされる。
【００２５】
かかるコンテンツ利用可能性情報の例を表４に示す。この表は「CAM：Content  Availability  Map」と呼ぶ。この表は、フラグメントをプロアクティブにダウンロードした各コンテンツを記述している。各コンテンツに対して、この表は、コンテンツのフラグメントをダウンロードしたピアを示すピアのリスト(「Peer-List」)を含む。このピアリストは、コンテンツの同じフラグメントを記憶するピアからなるサブセット(「Peer-Subset」)に分割される。各ピアサブセットにおいて、ダウンロードされたコンテンツフラグメントは、利用できるコンテンツのチャンクを示す「Available-Chunk-List」フィールドにより示される。コンテンツアイテムごとのチャンクのサイズを、表の「Content-Map」フィールドに示す。
【００２６】
コンテンツフラグメントとコンテンツチャンクは、一般的には異なるものであり、その間の関係(フラグメントごとのチャンク数、最終フラグメント中のチャンク数など)はアプリオリに知られる。コンテンツフラグメントは、マルチキャストデリバリによるコンテンツの配信のためのものであり、コンテンツチャンクはＰ２Ｐデリバリによるコンテンツの配信のためのものである。一般的に、コンテンツフラグメントのサイズはコンテンツチャンクのサイズよりも大きく、コンテンツフラグメントは複数のコンテンツチャンクを連続または非連続につなげたものである。
【００２７】
【表４】
2011521369.tif 000008
ステップ２．ｂにおいて、CAMのプッシュに用いるマルチキャストセッションは、前出のSD&S/BCG宣言に、表５に示したマルチキャストセッション宣言を加えて、宣言される。この宣言には「Client-Type」フィールドはない。これは、各クライアントデバイスが、その「Client-Type」が何であってもこの「Content  Availability  Map」をダウンロードしなければならないことを意味する。
【００２８】
【表５】
2011521369.tif 000009
マルチキャストセッションでトランスポートされ、「Content  Availability  Map」を記述するFLUTE  FDTインスタンスを表６に示す。
【００２９】
【表６】
2011521369.tif 000010
ステップ３：コンテンツ要求
ステップ３．ａにおいて、クライアントデバイスは、「Content  Availability  Map」を受け取ると、ダウンロードを要求できるユーザにコンテンツを提案できる。
【００３０】
ステップ３．ｂにおいて、要求するクライアントデバイスは、必要なコンテンツフラグメントをすべては記憶していないので、他のクライアントデバイスに記憶されている、欠けているフラグメントを読み出す必要がある。これらのピアクライアントデバイスを特定するため、要求するクライアントは、中央サーバまたは他のピアに問いあわせずに、直接「Content  Availability  Map」を用いる。この表を用いて、要求するクライアントは、それが事前に記憶しているコンテンツチャンクと、欠けているコンテンツチャンクを提供できるピアのリストを知ることができる。
【００３１】
実施形態を図２に示した。この図は、コンテンツフラグメントとコンテンツ利用可否マップ(CAM)のプッシュ後のピアの状態を示す。クライアントデバイス「Peer  １b」は、コンテンツ「B」のダウンロードを望むが、「Content  Availability  Map」を用いて：
−すでにダウンロードしたコンテンツチャンク(Chk２、Chk３)を判断する、
−ダウンロードしなければならないコンテンツチャンク(ChkO、Chk１、Chk４．．．Chk１１)を判断する、
−ピアを選択してコンテンツチャンクをダウンロードする(例えば、POa→ChkO、POb→Chk１、P２a→Chk４．．．、P５b→Chk１１)。
【００３２】
ローカルに行われ、DSLネットワークにおけるDSLAMで行われる場合があるＰ２Ｐによる情報交換を制限するために、実施形態を改良する。
【００３３】
「Content  Availability  Map」は各ローカルエリアで異なる。「Local  Content  Availability  Map」(LCAM)は、「Client-Locality-Id」により特定されるすべてのクライアントデバイスにプッシュされる。この識別子は、「Client-Type」識別子と同様に、オペレータリモートシステム制御により管理される。図３は、ローカルゾーン(「Client-Locality-Id」)ごとの、異なるタイプ(「Client-Type」)のクライアントデバイスのリパーティションを示す図である。
【００３４】
制御サーバによる「LCAM」の構成をする方法は、下表に示したように、コンテンツフラグメント受信レポートメッセージにローカリティ識別子(「Client-Locality-Id」)を加えることである。
【００３５】
【表７】
2011521369.tif 000011
各「Local  Content  Availability  Map」は、クライアントデバイスにコンテンツフラグメントをプッシュするために用いるのと同じ、目標を絞ったマルチキャストセッションにおいて、「Client-Locality-Id」識別子に基づき、ローカルにプッシュされる。
【００３６】
この場合に「Local  Content  Availability  Map」をプッシュするマルチキャストセッション宣言の例を下表に示す：
【００３７】
【表８】
2011521369.tif 000012
2011521369.tif 000013
マルチキャストセッションでトランスポートされ、「Local  Content  Availability  Map」を記述するFLUTE  FDTインスタンスを表６に示す。ここで「Content-Location」を「LCAM-URI」に設定されている。
【００３８】
実施形態の第１の変形例では、CAMはアプリオリに求められ、コンテンツフラグメントとともにFLUTEセッションに送られる。ネットワークオペレータはそのネットワークトポロジを熟知している。このトポロジに基づき、クライアントからの受信レポートメッセージを待たずに、理論的に理想的なCAMを構成することができる。このCAMを、１つのFLUTEセッションで、対応するすべてのコンテンツフラグメントとともに、プッシュできる。
【００３９】
この変形例は、SD&Sを介した１つの宣言と、(２つではなく)１つのFLUTEセッションのみを用いる。クライアントＰ２Ｐダウンロードを確実にするための集中制御サーバへのクライアント受信レポートは、必要なくなる。他の目的のためにレポートが必要であれば、CDSには完了ポーリングメカニズム（completion  polling  mechanism）があり、クライアントのサブセットのみが集中制御サーバに正しく受信できたことをレポートする。
【００４０】
実施形態の第２の変形例では、ピア間の近接性情報を導入する。「Client-Locality-Id」は、ピアリストの記載の一部、すなわちローカリティが同じピアであり、ピアは自分の近くのピアを特定し、それだけにコンタクトして、他のすべてのフラグメントをダウンロードできる。
【００４１】
近傍の概念を拡張して領域すなわちローカリティが近いもののリストを生成する。これらの新しいフィールドを下表８に示すように、CAMに挿入する：
【００４２】
【表９】
2011521369.tif 000014
2011521369.tif 000015
領域を用いて、ネットワークトポロジに近づき、必要に応じて(接続やCPU負荷などの点でクライアントにアクセスできない場合など)、クライアントデバイスが近いクライアントから遠いクライアントに階層的にアクセスすることを可能とする。
【００４３】
一般的に、この階層には２つより多いレベルがあり、オペレータにより構成されたレベルにおけるネットワークトポロジを抽象化したものを表すツリー状のデータ構造となるであろう。「Region」フィールドは、表８では「Region-Level-１」という名称になっている。
【００４４】
CAMを拡張して、各ローカリティの特性、上記のすべての質的データ（ダウンロードとアップロード用の平均ビットレートキャパシティ）、貴重な情報を含み、必要な時に、クライアントが最良のローカリティを選択できるようにしてもよい。
【００４５】
CAMは定期的に更新され、ネットワークにおけるダウンロードの進行状況を反映する。オペレータは、チャンクレベルで精密に、または(完全なフラグメントを有するピアについてのみ)フラグメントレベルでマクロ的に、更新のレベルを選択して、ピアをその接続状態に応じてCAMに追加したり削除したりできる。この更新は元のCAMが理論的なものであってもなくても適用できる。
【００４６】
明細書、特許請求の範囲、及び図面に開示した内容（references）は、独立に設けることもできるし、適切に組み合わせて設けることもできる。必要に応じて、ハードウェア、ソフトウェア、またはこれらの組み合わせで機能を実施することができる。
【００４７】
本明細書において「一実施形態」とは、その実施形態に関して説明する具体的な機能、構造、特徴などが本発明の少なくとも１つの実施形態に含まれ得ることを意味している。本明細書ではいろいろな箇所で「一実施形態とは」と記載するが、必ずしも同じ実施形態を指すものではなく、別の、または代替的な実施形態は、必ずしも他の実施形態と互いに排他的なものではない。
【００４８】
特許請求の範囲に示す参照符号は例示であり、請求項の範囲を限定するものではない。
【図１】
2011521369.tif 000016
【図２】
2011521369.tif 000017
【図３】
2011521369.tif 000018
【手続補正書】
【提出日】平成22年11月24日(2010.11.24)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
クライアントにおけるコンテンツを受信する方法であって、
マルチキャストモードで第１のサーバから複数のコンテンツを受信する段階と、
正しく受信したコンテンツを、第２のサーバに知らせる段階と、
各ピアクライアントにおいて利用できるコンテンツを示すコンテンツ利用可否マップを、第３のサーバからマルチキャストモードで受信する段階と、
前記コンテンツ利用可否マップに示された、前記コンテンツが利用可能なピアクライアントに、欠けているコンテンツを要求する段階と、
を有する方法。
【請求項２】
前記クライアントはその所在を前記サーバに知らせる、
請求項１に記載の方法。
【請求項３】
前記複数のコンテンツを受信した第１のサーバの識別子を、前記第２のサーバに知らせる段階をさらに有する、
請求項１に記載の方法。
【国際調査報告】
2011521369.tif 000019
2011521369.tif 000020
2011521369.tif 000021
2011521369.tif 000022