(57)【要約】  ネットワークベースのコンテンツサーバからバーストベースのサービスのセッションに参加している２つ以上のクライアントにメディアを配信する方法である。この方法は、このセッションの確立に続いて、さらに参加するクライアントとしてコンテンツサーバをセッションに参加させる工程と、コンテンツサーバにメディア許可を送信する工程と、コンテンツサーバから他の参加しているクライアントに要求されているメディアを配信する工程とを備える。【選択図】  なし
2009514277.tif 000002
【特許請求の範囲】
【請求項１】
ネットワークベースのコンテンツサーバから、バーストベースのサービスのセッションに参加している２つ以上のクライアントにメディアを配信する方法であって、
前記セッションの確立に続いて、さらに参加するクライアントとして、前記セッションに前記コンテンツサーバを参加させる工程と、
前記コンテンツサーバにメディア許可を送信する工程と、
要求されるメディアを前記コンテンツサーバから他の参加しているクライアントに配信する工程と
を備えることを特徴とする方法。
【請求項２】
前記バーストベースのサービスは、プッシュツートークオーバセルラーである
ことを特徴とする請求項１に記載の方法。
【請求項３】
前記バーストベースのサービスのセッションは、セッション開始プロトコル（ＳＩＰ）シグナリングを使用して確立され、
前記コンテンツサーバを、該コンテンツサーバにＳＩＰ  ＩＮＶＩＴＥを送信することによって、さらに参加するクライアントとして前記セッションに参加させる
ことを特徴とする請求項１または２に記載の方法。
【請求項４】
前記ＳＩＰ  ＩＮＶＩＴＥは、制御ＳＩＰアプリケーションサーバが前記参加しているクライアントの１つからＳＩＰ  ＲＥＦＥＲメッセージを受信した結果として、前記制御ＳＩＰアプリケーションサーバから送信される
ことを特徴とする請求項３に記載の方法。
【請求項５】
前記ＳＩＰ  ＲＥＦＥＲは、Ｒｅｆｅｒ−Ｔｏヘッダの中に前記コンテンツサーバを識別するＳＩＰ  ＵＲＩを有している
ことを特徴とする請求項４に記載の方法。
【請求項６】
前記メディアは、前記コンテンツサーバの前記ＵＲＩに付加されているＵＲＩパラメータによって識別される
ことを特徴とする請求項５に記載の方法。
【請求項７】
前記メディアは、前記ＳＩＰ  ＲＥＦＥＲメッセージの「ｅｓｃａｐｅｄ」ヘッダフィールドで識別される
ことを特徴とする請求項５に記載の方法。
【請求項８】
前記コンテンツサーバからのメディアの配信の完了後、該コンテンツサーバは進行中のセッションから取り除かれる工程を更に備える
ことを特徴とする請求項１乃至７のいずれか１項に記載の方法。
【請求項９】
請求項３に従属する場合、前記コンテンツサーバは、前記参加しているクライアントの１つが前記制御ＳＩＰサーバにＳＩＰ  ＲＥＦＥＲ（ＢＹＥ）要求を送信することで、取り除かれる
ことを特徴とする請求項８に記載の方法。
【請求項１０】
請求項３に従属する場合、前記コンテンツサーバは、当該コンテンツサーバが前記制御ＳＩＰサーバにＳＩＰ  ＢＹＥ要求を送信することで取り除かれる
ことを特徴とする請求項８に記載の方法。
【請求項１１】
１つ以上の他のクライアント端末とのバーストベースのサービスのセッションに参加できるクライアント端末であって、
前記１つ以上の他のクライアント端末とバーストベースのサービスのセッションを確立する手段と、
続いて、ネットワークベースのコンテンツサーバへ、進行中のセッションへの招待であって、参加しているクライアント端末と共有されるメディアを識別する招待を送信する手段と、
前記コンテンツサーバが、前記セッションに参加するクライアントとして参加した後、該コンテンツサーバから、前記識別されたメディアを受信する手段と
を備えることを特徴とするクライアント端末。
【請求項１２】
進行中のバーストベースのサービスのセッションに参加している２つ以上のクライアントへのメディア配信に使用するコンテンツサーバであって、
参加するクライアントとして、前記セッションにコンテンツサーバを参加させる手段と、
制御セッションサーバからメディア許可を受信する手段と、
他の参加しているクライアントへの配信用に要求されているメディアを送信する手段と
を備えることを特徴とするコンテンツサーバ。
【請求項１３】
ネットワークベースのコンテンツサーバから、セッション制御サーバによって制御されるバーストベースのサービスのセッションに参加している２つ以上のクライアントに、メディアを配信する方法であって、
前記セッションの確立に続いて、前記セッション制御サーバから前記コンテンツサーバへＨＴＴＰプロトコル要求を送信する工程と、
前記コンテンツサーバおいて、前記ＨＴＴＰプロトコル要求の受信時に、該ＨＴＴＰプロトコル要求で識別されるメディアを識別する工程と、
前記コンテンツサーバから前記参加しているクライアントへ、前記識別されたメディアを配信する工程と
を備えることを特徴とする方法。
【請求項１４】
前記バーストベースのサービスのセッションは、セッション開始プロトコル（ＳＩＰ）シグナリングを使用して確立される
ことを特徴とする請求項１３に記載の方法。
【請求項１５】
前記参加しているクライアントの１つが前記セッション制御サーバに、前記コンテンツサーバを識別するＨＴＴＰ  ＵＲＬを有するメディアバースト要求を送信する工程と、
前記メディアバースト要求の受信に応じて、前記セッション制御サーバで、前記ＨＴＴＰプロトコル要求を生成し、該ＨＴＴＰプロトコル要求を前記コンテンツサーバへ送信する工程と
を更に備えることを特徴とする請求項１３または１４に記載の方法。
【請求項１６】
前記ＨＴＴＰプロトコル要求は、ＨＴＴＰ  ＧＥＴである
ことを特徴とする請求項１３乃至１５のいずれか１項に記載の方法。
【請求項１７】
２つ以上の参加しているクライアントを含むバーストベースのサービスのセッションの制御に使用するセッション制御サーバであって、
２つ以上の参加しているクライアント間のセッションを確立する手段と、
前記クライアントの１つから、メディアが記憶されているコンテンツサーバを識別するＨＴＴＰ  ＵＲＬを含むメディアバースト要求を受信する手段と、
ＨＴＴＰ要求を生成し、該ＨＴＴＰ要求を前記コンテンツサーバに送信する手段と、
前記コンテンツサーバから前記メディアを受信し、前記参加しているクライアントに該メディアを配信する手段と
を備えることを特徴とするセッション制御サーバ。
【請求項１８】
１つ以上の他の参加しているクライアント端末を含むバーストベースのサービスのセッションで使用するユーザ端末であって、
１つ以上の他の参加しているクライアント端末とのセッション進行中に、メディアが記憶されているコンテンツサーバを識別するＨＴＴＰ  ＵＲＬを含むメディアバースト要求を制御サーバに送信する手段と、
前記制御サーバを介して、前記コンテンツサーバから前記メディアを受信する手段と
を備えることを特徴とするユーザ端末。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明の分野
本発明は、プッシュツートーク型セッションにおけるメディア共有のための方法および装置に関するものである。
【背景技術】
【０００２】
本発明の背景
トランシーバ（walkie-talkie：ウォーキートーキー）型サービスは、相互間で短いメッセージを簡単に通信したいと要望するユーザ間で長い間にわたり知られているものである。従来、このようなサービスは、無線スペクトラムの専用部分を利用する双方向携帯無線によって提供されているが、この双方向携帯無線は、同種の端末を利用し、かつ比較的短距離の無線の動作範囲内に存在する事前に選択された小グループのユーザと通信することだけを可能にする。最近になって、既設のセルラー電話インフラストラクチャに便乗する（piggy-back：ピギーバックする）サービスが、米国で導入されている。しかしながら、このサービスは本質的に独自仕様であり、ユーザが異なるオペレータネットワーク間で通信することは許容されていない。
トランシーバ型サービスの使用を拡大するための試みに、セルラーネットワーク上で提供されるトランシーバサービスのネットワーク間運用（operability：オペラビリティ）を可能にする適切なプロトコルの標準化を目的として、オープンモバイルアライアンス（ｗｗｗ．ｏｐｅｎｍｏｂｉｌｅａｌｌｉａｎｃｅ．ｏｒｇ）として知られる産業団体が設立されている。様々な標準によって確立されているサービスは、ＰｏＣ（Push to talk over Cellular：プッシュツートークオーバーセルラー）として知られている。ＰｏＣは、（ＳＩＰ  ＡＳとして動作する）ＰｏＣサーバを介してＰｏＣセッションのセットアップおよび制御を扱うために、ＩＰマルチメディアサブシステム（ＩＭＳ：IP Multimedia Subsystem）を使用する。このＰｏＣは、パケット交換アクセスネットワークを通じて関連音声データを転送することを提案している。ＧＳＭおよびＵＭＴＳの場合、これは、汎用パケット無線サービス（ＧＰＲＳ：General Packet Radio Service）アクセスネットワークまたは３Ｇアクセスネットワークである。他のネットワークアーキテクチャでは、類似のパケット交換アクセスネットワークは、トークデータ（talk data）を転送するために利用されることになる。プッシュツートークサービスは、回線交換アクセスネットワーク上でも提供されてもよいが、好ましい選択肢（オプション）ではない。
【０００３】
現在のＰｏＣの状態は、リリース１．０に提示されている。
【０００４】
ＰｏＣリリース２の要件が、現在提示されている。これらには、ＰｏＣセッションにおけるＰｏＣユーザ間のメディアコンテンツ共有、すなわち、プッシュツーウォッチ（push-to-watch）型サービスの要件を含んでいる。このメディアは、ユーザ装置（「ＰｏＣクライアント」）またはネットワークのコンテンツサーバに記憶することができる。
【発明の開示】
【発明が解決しようとする課題】
【０００５】
本発明の要約
本発明は、例えば、プッシュツートークオーバーセルラー（ＰｏＣ：Push to talk over Cellular）、およびバーストベースのサービスでもある関連拡張サービス等のプッシュツートーク型サービスに関するものである。
【課題を解決するための手段】
【０００６】
本発明の第１の態様に従えば、ネットワークベースのコンテンツサーバから、バーストベースのサービスセッションに参加している２つ以上のクライアントにメディアを配信する方法が提供される。この方法は、
このセッションの確立に続いて、さらに参加するクライアントとして、セッションにコンテンツサーバを参加させる工程と、
コンテンツサーバにメディア許可を送信する工程と、
要求されるメディアをコンテンツサーバから他の参加しているクライアントに配信する工程と
を備える。
【０００７】
本発明は、ＰｏＣリリース１．０、２．０または同一のプロトコルの将来の拡張に従って、ネットワークベースのコンテンツサーバからプッシュツートークオーバーセルラー（ＰｏＣ）セッションに参加するクライアントへの、メディア配信に特に適用可能である。
【０００８】
好ましくは、前述のバーストベースのサービスセッションは、セッション開始プロトコル（ＳＩＰ：Session Initiation Protocol）シグナリングを使用して確立され、前述のコンテンツサーバを、コンテンツサーバにＳＩＰ  ＩＮＶＩＴＥを送信することによって、さらに参加するクライアントとしてセッションに参加させる。このＳＩＰ  ＩＮＶＩＴＥは、制御ＳＩＰアプリケーションサーバが参加しているクライアントの１つからＳＩＰ  ＲＥＦＥＲメッセージを受信した結果として、その制御ＳＩＰアプリケーションサーバから送信されてもよい。より好ましくは、このＳＩＰ  ＲＥＦＥＲは、Ｒｅｆｅｒ−Ｔｏヘッダの中にコンテンツサーバを識別するＳＩＰ  ＵＲＩを含んでいる。
【０００９】
要求されているメディアは、コンテンツサーバのＵＲＩに付加されているＵＲＩパラメータによって識別されてもよい。選択的には、このメディアは、ＳＩＰ  ＲＥＦＥＲメッセージの「ｅｓｃａｐｅｄ」ヘッダフィールドで識別されてもよい。
【００１０】
好ましくは、コンテンツサーバからのメディアの配信の完了後、このコンテンツサーバは、進行中のセッションから取り除かれる。セッションを確立し、かつ参加しているクライアントとしてコンテンツサーバを追加するためにＳＩＰプロトコルが使用される場合、このコンテンツサーバは、参加しているクライアントの１つが制御サーバにＳＩＰ  ＲＥＦＥＲ（ＢＹＥ）要求を送信することで取り除かれてもよい。選択的には、このコンテンツサーバは、制御サーバにＳＩＰ  ＢＹＥ要求を送信することによって、自ら取り除いてもよい。
【００１１】
本発明の第２の態様に従えば、１つ以上の他のクライアント端末とのバーストベースのサービスのセッションに参加できるクライアント端末が提供される。このクライアント端末は、
１つ以上の他のクライアント端末とバーストベースのサービスのセッションを確立する手段と、
続いて、ネットワークベースのコンテンツサーバへ、進行中のセッションへの招待であって、参加しているクライアント端末と共有されるメディアを識別する招待を送信する手段と、
コンテンツサーバが参加するクライアントとしてセッションに参加した後、コンテンツサーバから、識別されたメディアを受信する手段と
を備える。
【００１２】
本発明の第３の態様に従えば、進行中のバーストベースのサービスセッションに参加している２つ以上のクライアントへのメディア配信に使用するコンテンツサーバが提供される。このサーバは、
参加するクライアントとして、進行中のセッションにコンテンツサーバを参加させる手段と、
制御セッションサーバからメディア許可を受信する手段と、
他の参加しているクライアントへの配信用に要求されているメディアを送信する手段と
を備える。
【００１３】
本発明の第４の態様に従えば、ネットワークベースのコンテンツサーバから、セッション制御サーバによって制御されるバーストベースのサービスのセッションに参加している２つ以上のクライアントに、メディアを配信する方法が提供される。この方法は、
このセッションの確立に続いて、セッション制御サーバからコンテンツサーバへＨＴＴＰ要求を送信する工程と、
コンテンツサーバおいて、この要求の受信時に、ＨＴＴＰ要求で識別されるメディアを識別する工程と、
コンテンツサーバから参加しているクライアントへ、識別されたメディアを配信する工程と
を備える。
【００１４】
好ましくは、前述のバーストベースのサービスセッションは、セッション開始プロトコル（ＳＩＰ：Session Initiation Protocol）シグナリングを使用して確立される。この方法は、参加しているクライアントの１つが前述の制御サーバにコンテンツサーバを識別するＨＴＴＰ  ＵＲＬを含むメディアバースト要求を送信する工程を備える。このメッセージの受信に応えて、セッション制御サーバは、前述のＨＴＴＰ要求を作成し送信する。コンテンツサーバによって識別されたメディアは、参加しているクライアントにそのメディアを配信するセッション制御サーバに返信される。
【００１５】
本発明の第５の態様に従えば、２つ以上の参加しているクライアントを含むバーストベースのサービスセッションの制御に使用するセッション制御サーバが提供される。このサーバは、
２つ以上の参加しているクライアント間のセッションを確立する手段と、
このクライアントの１つから、メディアが記憶されているコンテンツサーバを識別するＨＴＴＰ  ＵＲＬを含むメディアバースト要求を受信する手段と、
ＨＴＴＰ要求を生成し、このコンテンツサーバに送信する手段と、
このコンテンツサーバからメディアを受信し、参加しているクライアントにメディアを配信する手段と
を備える。
【００１６】
本発明の第６の態様に従えば、１つ以上の他の参加しているクライアント端末を含むバーストベースのサービスのセッションで使用するユーザ端末が提供される。この端末は、
１つ以上の他の参加しているクライアント端末とのセッション進行中に、メディアが記憶されているコンテンツサーバを識別するＨＴＴＰ  ＵＲＬを含むメディアバースト要求を制御サーバに送信する手段と、
この制御サーバを介して、このコンテンツサーバからメディアを受信する手段と
を備える。
【発明を実施するための最良の形態】
【００１７】
実施形態の詳細説明
以下の検討は、プッシュツートークオーバーセルラー（ＰｏＣ：Push-to-talk over Cellular）セッションで、コンテンツサーバから、参加者に１つ以上のメディアタイプを配信することを可能にする課題に関して、２つの解決策を提供する。このメディア共有を容易にするために、３つの主要な問題に取り組む必要がある。
【００１８】
ユーザがメディアを共有したいことを、ＰｏＣサーバはどのように理解するか？
ＰｏＣユーザは、メディアをどのように識別するか？
ＰｏＣセッションで何を共有するかを、ＰｏＣユーザはどのようにコンテンツサーバに知らせるか？
第１のアプローチは、コンテンツサーバをＰｏＣクライアントとしてＰｏＣセッションに追加することを含めることで、コンテンツサーバをＰｏＣセッションに（一時的に）追加させる。このアプローチを説明するために、ＰｏＣクライアントＡとＢとの間の進行中のＰｏＣセッションを検討する。このセッションでは、各ＰｏＣクライアントは、参加ＰｏＣサーバ（ＰｏＣサーバＡおよびＢ）を有し、このセッションは、制御ＰｏＣサーバ（ＰｏＣサーバＸ）によって制御されている。図１は、このアプローチに関連する主なＳＩＰ要求およびＳＩＰ応答を示している。ここで、ＰｏＣリリース１．０の呼び名「トークバースト要求（Talk Burst Request）」、「トークバーストアイドル（Talk Burst Idle）」等は、総称の「メディアバースト要求（Media Burst Request）」、「メディアバーストアイドル（Media Burst Idle）」等に変更している。メッセージシーケンスは、以下の通りである。
【００１９】
コンテンツサーバを進行中のＰｏＣセッションに追加する（ＩＮＶＩＴＥ）ために、ＰｏＣクライアントＡは、ＳＩＰ  ＲＥＦＥＲ要求を送信する。ＳＩＰ  ＲＥＦＥＲ要求は、「Ｒｅｆｅｒ−Ｔｏ」ヘッダの中に要求されるメディアを保持するコンテンツサーバのＵＲＩを含んでいる。このメディア自体は、コンテンツサーバのアドレスの中のユニバーサルリソースインジケータ（ＵＲＩ：Universal Resource Indicator）パラメータでも識別され、あるいは「ｅｓｃａｐｅｄ」ヘッダフィールド内でも識別される。
【００２０】
ＰｏＣサーバＸは、ＳＩＰ  ＲＥＦＥＲ（ＳＩＰ照会）要求を受信し、その結果、ＳＩＰ  ＩＮＶＩＴＥ（ＳＩＰ招待）を使用して、ＰｏＣコンテンツサーバが通常のＰｏＣユーザであるかのように、ＰｏＣコンテンツサーバを招待する。
【００２１】
コンテンツサーバは招待を受諾し、ＳＩＰ  ２００  ＯＫ（ＩＮＶＩＴＥ）応答を送信する。ＰｏＣサーバＸは、コンテンツサーバが受諾していることを指示するために、ＰｏＣクライアントにＳＩＰ  ＮＯＴＩＦＹ要求を送信する。
【００２２】
コンテンツサーバが招待を受諾していることを指示するＳＩＰ  ＮＯＴＩＦＹ要求の受信時、ＰｏＣクライアントＡは、コンテンツサーバに代わって、例えば、画像を送信する許可を要求することができる。これは、Ｍｅｄｉａ  Ｂｕｒｓｔ  Ｒｅｑｕｅｓｔ（メディアバースト要求）メッセージを使用して実行される。
【００２３】
ＰｏＣサーバＸは、要求を承諾し、ＰｏＣクライアントＡとコンテンツサーバの両方（Ｍｅｄｉａ  Ｂｕｒｓｔ  Ｇｒａｎｔｅｄ（メディアバースト許可）メッセージ）ならびにＰｏＣクライアントＢ（Ｍｅｄｉａ  Ｂｕｒｓｔ  Ｔａｋｅｎ（メディアバースト取得）メッセージ）に通知する。
【００２４】
コンテンツサーバは、ＰｏＣサーバＸにメディアを送信し（Ｍｅｄｉａ  Ｂｕｒｓｔ）、ＰｏＣサーバＸは、このタイプのメディアを受信することができる全参加者にそのメディアを配信する。
【００２５】
一旦メディアが送信されると、コンテンツサーバは、Ｍｅｄｉａ  Ｂｕｒｓｔ  Ｒｅｌｅａｓｅ（メディアバースト解放）メッセージを送信し、ＰｏＣサーバは、このメディアタイプに関してフロア（floor：発言権）が空いている（アイドル状態である）ことを示す情報（Ｍｅｄｉａ  Ｂｕｒｓｔ  Ｉｄｌｅ（メディアバーストアイドル））を配信する。
【００２６】
ＰｏＣクライアントＡは、Ｍｅｄｉａ  Ｂｕｒｓｔ  Ｉｄｌｅメッセージを受信する場合、ＳＩＰ  ＲＥＦＥＲ（ＢＹＥ）要求を用いてＰｏＣセッションからコンテンツサーバを除去することができる。同一の結果を達成する代替手段は、コンテンツサーバが、ＳＩＰ  ＢＹＥ要求を用いてＰｏＣセッションを去ることである。
【００２７】
図１に示される解決策が有する利点は、ＰｏＣクライアントもネットワークのＰｏＣサーバも、コンテンツサーバがＰｏＣクライアントであることを識別する必要がないことである。
【００２８】
ＰｏＣセッションでコンテンツサーバから参加者に１つ以上のメディアタイプを配信することを可能にする課題の代替解決策は、共有されるメディアを識別するために、ＳＩＰアドレスの代わりにＨＴＴＰ  ＵＲＬを使用する。例えば、ユーザがコンテンツサーバにいくつかのメディアを記憶している、またはインターネットを閲覧していて共有したい興味深いメディア（例えば、画像、オーディオクリップ、ビデオクリップ等）を見つけると想定する。図２は、このアプローチを実現する簡略化メッセージフローを示している。このメッセージフローは、以下の通りである。
【００２９】
ＰｏＣクライアントＡは、別のユーザのためにメディア（例えば、画像）を送信する許可を要求するＭｅｄｉａ  Ｂｕｒｓｔ  Ｒｅｑｕｅｓｔメッセージを送信する。他のユーザのアドレスは、ＨＴＴＰ  ＵＲＬで、例えば、「http://my-content-op.net/user/〜u29502467/pictures/vacation05/kalle.jpg」である。
【００３０】
ＰｏＣサーバＸは、ＨＴＴＰアドレス（ＳＩＰ  ＵＲＩの代わりに）を有するＭｅｄｉａ  Ｂｕｒｓｔ  Ｒｅｑｕｅｓｔメッセージを受信すると、ＰｏＣサーバＸは、コンテンツサーバにＨＴＴＰ  ＧＥＴ要求を送信する。
【００３１】
コンテンツサーバは、ＨＴＴＰ  ２００  「ＯＫ」応答でＨＴＴＰ  ＧＥＴ要求で識別されるファイルを返信する。
【００３２】
ＰｏＣサーバＸは、ＰｏＣクライアントＡにＭｅｄｉａ  Ｂｕｒｓｔ  Ｇｒａｎｔｅｄメッセージを送信し、ＰｏＣクライアントＢにＭｅｄｉａ  Ｂｕｒｓｔ  Ｔａｋｅｎメッセージを送信し、メディアの送信（Ｍｅｄｉａ  Ｂｕｒｓｔ）を開始する。
【００３３】
一旦メディアが配信されると、ＰｏＣサーバＸは、他の参加者がメディア送信の許可を依頼してもよいことを示すために、参加者（コンテンツサーバを含む）にＭｅｄｉａ  Ｂｕｒｓｔ  Ｉｄｌｅメッセージを送信する。
【００３４】
メディア共有プロセスは進行中であるが、ＰｏＣユーザのどちらかは、トークバースト中にＰｏＣクライアントＡのＰｏＣユーザがＰｏＣクライアントＢのＰｏＣユーザと共有画像について話すことができるように、トークバーストを送信する許可を制御ＰｏＣサーバＸに依頼することができる。この事例は、例示されていない。
【００３５】
（図２の）代替解決策は、シグナリング要件が最小であるという利点がある。別の利点は、（制御）ＰｏＣサーバがメディアをフェッチする権限が認可されている限り、この解決策は、どのＰｏＣ「とは気付かない（unaware）」ウェブサーバに記憶されているメディアを共有するために使用することができる。他方では、有限サイズのメディアを共有するためだけに使用することができる。例えば、ストリーミングビデオを共有するためにこの解決策を使用することは可能でない。
【００３６】
本発明の範囲から逸脱することなく、上述の実施形態に様々な修正を行い得ることは当業者なら理解するであろう。例えば、本発明を、ＰｏＣとの関連でこれまで説明しているが、本発明は、例えば、インスタントメッセージングサービス等の他のバースト型サービスにも適用可能である。
【図面の簡単な説明】
【００３７】
【図１】本発明の第１の実施形態による信号フローシーケンスを示す図である。
【図２】本発明の第２の実施形態による信号フローシーケンスを示す図である。
【図１】
2009514277.tif 000003
【図２】
2009514277.tif 000004
【国際調査報告】
2009514277.tif 000005
2009514277.tif 000006