JP5167726B2 - コンテンツ課金システム、コンテンツ取得装置、コンテンツ取得方法およびそのプログラム、並びにコンテンツ提供装置、コンテンツ提供方法およびそのプログラム - Google Patents

Description

本発明は、コンテンツ課金システム、コンテンツ取得装置、コンテンツ取得方法およびそのプログラム、並びにコンテンツ提供装置、コンテンツ提供方法およびそのプログラムに関し、特に、電話サービスのようなリアルタイムコミュニケーションを利用したＰ２Ｐ（Peer to Peer）環境下で送受信されるコンテンツに課金する技術に係わる。

近年、インターネットなどの通信サービス上で行われるオークション、いわゆるネットオークション（オンラインオークションとも呼ばれる）を利用して、一般消費者同士が直接取引を行う「ＣｔｏＣ(Consumer to Consumer)」型の電子商取引が注目を集めている。このネットオークションでは、ユーザ間で課金レートの設定から決済までが可能である。また、コンテンツ配信サービスのように、パーソナルコンピュータ（ＰＣ）等へダウンロードする映像や音楽等のコンテンツに応じて課金を発生させる仕組みも広く認知されており、同サービスの加入者は爆発的に増加している。

このような通信サービスを利用したコンテンツ配信サービスにおいて、ユーザの気になるところはその料金である。例えば、本出願人は、実時間のコミュニケーションシステム内にあってサービス提供者が設定した課金レートに対して、サービス利用者側で料金を予測できるような通信管理を行う実時間通信システムの課金方法を提案している（特許文献１を参照。）。この課金方法によれば、サービス利用者が想像以上の多額の料金請求を受けるという虞がなくなるという効果がある。

特開２００５−１３６６２７号公報

ところで、特許文献１において提案された技術は、サービス利用者が想像以上の多額の料金請求を受けるという虞がなくなるという効果があるものの、一方で、電話サービスのような実時間のコミュニケーションシステムにおいて、通信中にユーザ間で動的および柔軟に課金レートの設定、承認および支払（決済）を行うことができなかった。また、課金レートの設定および承認と連動して、有料情報（コンテンツ）の録音録画を行うことはできなかった。したがって、ＰＣ等の端末装置の扱いに不慣れでネットワークから課金レートを簡単に取得できないユーザにとっては、利便性が高いものではなかった。

本発明は斯かる点に鑑みてなされたものであり、ユーザ同士のコンテンツの取引において、ユーザの利便性を向上させることを目的とする。

上記課題を解決するため、本発明は、接続管理サーバを介して、リアルタイムコミュニケーションのための通信のセッションを確立する第１端末と第２端末との間で提供されるコンテンツに課金を行う課金システムにおいて、第１端末の第１ユーザから通話により提供依頼を受けたコンテンツに対する課金レート情報を、第２端末の第２ユーザの指示に基づいて接続管理サーバを介して第１端末へ送信する。さらに、第１端末は、提供依頼をしたコンテンツに対する課金レート情報を受信した後、第１ユーザによる課金レート情報の承認操作を受けて承認情報を、接続管理サーバを介して第２端末へ向けて送信する。ここで、接続管理サーバは、承認情報を受けて課金レート情報を課金サーバへ通知するとともに、承認情報を第２端末へ送信する。第２端末は、課金レート情報に対する承認情報を受信した後、接続管理サーバを介して第１端末へコンテンツの提供許可情報を送信するとともに、コンテンツを第１端末へ送信する。そして、第１端末は、コンテンツの提供許可情報を受信した後、第２端末からコンテンツを取得することを特徴とする。

上記構成によれば、ユーザ同士がそれぞれ第１端末と第２端末を利用して通信中に、リアルタイムに課金レートの設定、有料情報の提供および有料録音・録画を実現できる。

本発明によれば、ユーザ同士のコンテンツの取引において、ユーザの利便性を向上させることができる。

以下、添付図面を参照しながら、本発明の一実施の形態の例を説明する。本実施の形態は、本発明のコンテンツ課金システムを、ＮＧＮ（Next Generation Network）を利用して行われるユーザ端末間のコンテンツの取引に対する課金に適用した場合の例としてある。

図１は、本実施の形態によるネットワークの構成図である。図１に示すユーザ端末１およびユーザ端末２は、ＮＧＮ３の呼制御サーバ４（接続管理サーバ）と接続している。その呼制御サーバ４は、ユーザ端末間で送受信されるコンテンツの課金情報を管理する管理サーバ５と接続している。これらのユーザ端末１，２、呼制御サーバ４および課金サーバ５によるセッションの確立には、ＳＩＰプロトコルが使用される。

ＮＧＮ３は、ＳＩＰ（Session Initiation Protocol）プロトコルによる呼制御が可能なネットワークである。ＮＧＮは、現在別々に構築されているインターネットサービス用ＩＰネットワークと電話サービス用の電話網を、ＩＰ技術を用いてＱｏＳ（Quality of Service）やュリティを向上させたＩＰ通信網として統合し、現行の公衆網を代替する次世代ＩＰネットワークである。電話だけでなくテレビ放送もＩＰネットワークで統一的に提供しようとする動きも進められている。現在、ＩＴＵ−Ｔ（国際電気通信連合 電気通信標準化部門）などを中心にＮＧＮの標準化が進んでおり、日本でも通信事業者各社のＮＧＮ構築へ照準を合わせた動きが活発化している。既に一部の通信事業者はフィールド・トライアルを実施している。

ＩＴＵ−ＴのＹ．２００１勧告では、ＮＧＮが備えるべき様々な特徴を規定している。重要なものとしてはまず、エンド・ツー・エンドＱｏＳ保証の提供が挙げられる。ＮＧＮでは多様なアクセス網(ｘＤＳＬやＷｉＦｉ（Wireless Fidelity）、携帯電話端末など)や端末(電話機やＰＣ、情報家電など)、多様なアプリケーションが使われる。この環境下で端末と網とがＱｏＳをネゴシエーションし、上位アプリケーションに提供できる。次がモビリティのサポートである。一台のＰＣを携帯して例えば家庭内ではｘＤＳＬ、外出先ではＷｉＦｉ、オフィスではＦＴＴＨ（Fiber To The Home）と様々なアクセス網経由で通信したり、オフィス内の移動や出張などにより多数のＰＣから通信したりしてもサービスが受けられることが求められる。詳細な説明は省略するが、この他に、網の転送機能と制御機能の分離、多様なアクセス網のサポート、固定網と移動網の融合（ＦＭＣ）、緊急通信や合法的盗聴などの規制への適合などが規定されている。

ＩＴＵ−ＴによるＮＧＮ標準化は、技術的な側面において他の標準化機関との連携が重視されている。ＮＧＮの重要な構成要素であるＩＭＳ（IP Multimedia Subsystem）は第３世代携帯電話の標準化団体である３ＧＰＰが開発したものであり、そこで使われるＳＩＰおよび他のプロトコルの多くはＩＥＴＦ（Internet Engineering Task Force）で開発されたものである。

ＮＧＮの標準化において採用された上記ＩＭＳは、固定電話網や移動体通信網など、これまで回路スイッチやパケットスイッチが異なっていた公衆通信サービスを、ＩＰ技術やインターネット電話で使われるプロトコルであるＳＩＰで統合し、マルチメディア・サービスを実現させる通信方式である。

以下、ＩＭＳの役割・機能を簡単に説明する。第１の役割・機能は、マルチメディア・セッションの確立のサポートである。マルチメディア端末間のエンド・ツー・エンドの通信を確立する技術が、マルチメディア・セッション制御である。ＩＭＳでは、ＩＥＴＦで定義されているＳＩＰなどのセッション制御のためのプロトコルをベースに、ＩＰ伝送網をベアラ（伝達網）として使用し、ＩＰ伝送網内あるいは自ＩＰ網と他ＩＰ網間、他ＩＭＳ網間やＰＳＴＮ（固定電話網）網間においてマルチメディア・セッションを提供する。

第２の役割・機能は、エンド・ツー・エンドの通信において、一定の伝送品質を維持し、必要な伝送帯域を確保した通信を保証・実現する機能（ＱｏＳ制御）である。ＩＭＳでは、発着信ユーザ端末の契約条件や通信種別（音声、映像、データなど）に応じて、ＩＰパケット伝送網上のネットワーク・ノードを制御し、品質クラスの指定と必要帯域を確保した上で、通信を確立する。

第３の役割・機能は、ＩＰ（パケット）網と回線交換網上のインターワーク（協調動作）のサポートである。ＩＭＳは、ＩＰベースのマルチメディア・サービスを携帯電話や無線ＬＡＮ端末など、アクセス網に依存せずに提供するだけでなく、既存の電話網や他のＩＰパケット伝送網と接続しサービスを提供することも可能である。

その他、ＩＭＳにはローミングのサポート、迅速なアプリケーションサービス作成のサポート、およびＧＰＲＳ（General Packet Radio Service）以外のネットワークからのアクセスに対する新たなサポート等の役割・機能がある。

なお、ＩＭＳ以外でネットワークの伝送帯域を指示できるプロトコルとしては、Ｄｉａｍｅｔｅｒ（ダイアメータ）や従来のＩＰネットワークでＱｏＳに使用されているＲＳＶＰ（Resource reSerVation Protocol）がある。

一方、ＳＩＰは、セッションを開設するため、通信相手を特定する機能と、発信／着信／切断の機能を提供している。ＳＩＰはメッセージすなわち通信データをテキスト形式で表現する。このＳＩＰを用いたシステムは、大きくユーザ・エージェントとＳＩＰサーバから構成される。ユーザ・エージェントは、ＩＰ電話機能を持つＰＣなどのユーザ端末のことである。ユーザ・エージェントは、リクエストを送信する機能を持つユーザ・エージェント・クライアントと、リクエストに応答する機能を持つユーザ・エージェント・サーバにより構成される。本実施の形態では、ユーザ端末１がユーザ・エージェント・クライアントであり、ユーザ端末２がユーザ・エージェント・サーバに相当する。

ＳＩＰサーバは、プロキシ・サーバ、リダイレクト・サーバ、レジストラ、およびロケーション・サーバを総称したものである。以下、各サーバの機能を簡単に説明する。

プロキシ・サーバは、ユーザ・エージェント・クライアントからのＳＩＰリクエストを、次のサーバに中継するサーバである。プロキシ・サーバでは、認証、許可、ネットワーク・アクセス制御、ルーティング、ＳＩＰリクエスト転送、セキュリティなどの機能も提供する。

またリダイレクト・サーバは、リクエストを受け取り、着信側ユーザ・エージェントの現在のアドレスを発信側ユーザ・エージェントに知らせる役割を持つ。ユーザ・エージェント・クライアントは、リダイレクト・サーバから返された着信側アドレスに発信し直す。プロキシ・サーバとは異なり、ＳＩＰリクエストは転送しない。

またレジストラは、ユーザ・エージェント・クライアントの現在位置を登録するリクエスト（ＲＥＧＩＳＴＥＲリクエスト）を受けるサーバである。レジストラは、通常プロキシ・サーバやリダイレクト・サーバと同じホスト・コンピュータ上で動作する。

さらにロケーション・サーバは、レジストラ・サーバからの登録情報を保管し、リダイレクト・サーバやプロキシ・サーバによる着信ＵＲＩ（Uniform Resource Identifier）の参照要求に応答するサーバである。ロケーション・サーバは、ＳＩＰサーバと同じ場所に設置できる。

これらのサーバ（機能）は必ずしも一台のホスト・コンピュータ上に実装される必要はない。また、必ずしも同じ場所に設置する必要もない。本実施の形態では、これらを一つにまとめ呼制御サーバ４として表現している。

なお、ＩＰネットワーク上では、ＳＩＰによってセッション（接続）制御を行うサーバをＳＩＰサーバと呼ぶが、ＩＭＳではこれをＣＳＣＦ（Call Session Control Function）と呼んでいる。ＣＳＣＦは、ネットワーク内の役割に応じて、Ｐ−ＣＳＣＦ（Proxy- Call Session Control Function）、Ｉ−ＣＳＣＦ（Interrogating Call Session Control Function）、Ｓ−ＣＳＣＦ（Serving- Call Session Control Function）の３つのＣＳＣＦにわけられ、それぞれ異なる機能を提供している。

上述のＳＩＰは、電話ネットワークをＩＰネットワークに統合するために必要な技術として検討されてきた経緯がある。したがって、ＳＩＰのシステムの重要な機能として、ＩＰ電話を始めとする様々なＩＰネットワーク・アプリケーションで従来の電話番号を利用できるＥＮＵＭ（E.164 Number Mapping）がある。

ＥＮＵＭの標準化は、ＩＥＴＦとＩＴＵ−Ｔが共同して作業を進めている。ＥＮＵＭとＳＩＰの連携ということでは、ＳＩＰ端末（ユーザ端末１，２）によるＥＮＵＭ検索と、ＳＩＰサーバ（呼制御サーバ４）によるＥＮＵＭ検索がある。

ＥＮＵＭは、電話番号をネット上のアドレスやサービスと対応づけ、アクセス手段として利用する技術である。ＩＴＵ−Ｔ(国際電気通信連合)が定めた国際的に一意な電話番号体系(「Ｅ１６４」と呼ばれる)と特殊なドメイン領域(「.e164.arpa」のサブドメイン)をＤＮＳ（Domain Name System）で対応させることにより、電話番号とネットワーク上のサービスやアドレスを対応させている。１つの番号に対応させるアドレスなどは複数でもよい。例えば、自分の電話番号をＥＮＵＭで電子メールアドレスやＦＡＸ番号、ＷｅｂサイトのＵＲＬなどと対応させておけば、電話番号が自分へのアクセス手段の統一的な識別番号として利用できるようになる。例えば「03-1234-5678」という電話番号に対応するＥＮＵＭ（Ｅ１６４番号）のドメイン名は、先頭の０を日本の国番号８１で置換して逆順に並べた「8.7.6.5.4.3.2.1.3.1.8.e164.arpa」となる。このＤＮＳレコードに対応するアドレスなどを、ユーザ端末１，２または呼制御サーバ４に保管しておくのである。

このようなＥＮＵＭの機能によって、ユーザは特に意識することなく従来の電話番号を使用して、様々なＩＰネットワーク・アプリケーションを利用することができる。

次に、図１に示すユーザ端末１，２の構成を説明する。図２はユーザ端末１のブロック構成例を示し、また図３はユーザ端末２のブロック構成例を示している。図３において、図２に対応する部分については、同一符号を付し詳細な説明を省略する。

まず図２に示すユーザ端末１は、上記のとおりユーザ・エージェント・クライアントであり、ユーザの操作に応じてユーザ端末２にコンテンツの提供を依頼するものである。このユーザ端末１としては、ＮＧＮ接続用ＴＶ（Television）電話専用端末とテレビジョン受像機をコンパクトボディに集約したオールインワンタイプの端末を使用することができる。これに限らず、その他、テレビ電話機能を備えたＰＣやＮＧＮ対応無線通信端末等を適用できる。ユーザ端末１は、制御部としてのＣＰＵ１２Ａを備え、そのＣＰＵ１２Ａと接続するバス１１に、各種のコンピュータソフトウェアのプログラムやデータが書き込まれたＲＯＭ１３、およびプログラムやデータが展開されるＲＡＭ１４が接続される。

ＣＰＵ１２Ａ（制御部）は、プログラムに従って、メニュー取得部１２ａ１と、提供依頼通知部１２ａ２と、課金レート受信部１２ａ３と、承認通知部１２ａ４と、コンテンツ取得部１２ａ５として機能する。

メニュー取得部１２ａ１は、相手端末からコンテンツメニュー情報を取得する機能である。このメニュー取得部１２ａ１は、例えばプロバイダが運営するコンテンツ配信サーバ等にアクセスしてコンテンツの配信を希望する場合などに使用し、下記の個人ユーザ同士などのＰ２Ｐ通信には使用されない。提供依頼通知部１２ａ２は、ユーザにより選択されたコンテンツの提供依頼情報を、相手端末へ送信する機能である。課金レート受信部１２ａ３は、選択したコンテンツに対する課金レート情報を、相手端末から受信する機能である。承認通知部１２ａ４は、ユーザによる課金レートの承認操作を受けて承認情報を相手端末へ送信する機能である。そして、コンテンツ取得部１２ａ５は、承認情報を受信した相手端末からコンテンツの提供許可情報を受信し、相手端末から選択されたコンテンツを取得する機能である。

また、バス１１には、外部記憶装置１５がインタフェース（Ｉ／Ｆ）１６を介して接続される。外部記憶装置１５は、ユーザ端末１に内臓のハードディスクや半導体メモリである。光ディスク記録媒体やメモリカードなどのリムーバブルメディアであってもよい。外部記憶装置１５には、音声や映像、データなどの各種コンテンツが記録される。

また、バス１１には、操作部１７がインタフェース１８を介して接続されている。また、バス１１には、マイクロフォン１９が音声処理部２０を介して接続されるとともに、音声処理部２１を介して音声出力部２２が接続され、さらに、表示制御部２３を介して液晶表示部２４が接続される。

音声処理部２０は、マイクロフォン１９からのアナログ音声信号をデジタル音声データに変換し、必要に応じて圧縮するものであり、音声処理部２１は、バス１１に送出されたデジタル音声データを、圧縮されているものについては伸長して、アナログ音声信号に変換するものであり、音声出力部２２には、スピーカやヘッドフォン等が使用される。

また、バス１１には、ＮＧＮ３に接続してコンテンツの送受信を行うためのインタフェースとして通信部２５が接続される。さらに、リモートコントローラ装置（以下、「リモコン装置」と称す。）１ａを備え、ユーザ端末１の図示しないリモコン信号受信部を介して、リモコン装置１ａとユーザ端末１との間でリモコン信号の送受信が可能な構成としてある。

一方、図３に示すユーザ端末２は、上記のとおりユーザ・エージェント・サーバであり、ユーザ端末１とのネゴシエーションの結果に応じてユーザ端末１にコンテンツを提供する。このユーザ端末２としては、ユーザ端末１と同様に、例えばＮＧＮ接続用ＴＶ（Television）電話専用端末とテレビジョン受像機をコンパクトボディに集約したオールインワンタイプの端末を使用することができる。これに限らず、その他、テレビ電話機能を備えたＰＣやＮＧＮ対応無線通信端末等を適用できる。ユーザ端末２は、ＣＰＵ１２Ｂを備え、そのＣＰＵ１２Ｂと接続するバス１１に、各種のコンピュータソフトウェアのプログラムやデータが書き込まれたＲＯＭ１３、およびプログラムやデータが展開されるＲＡＭ１４が接続される。

ＣＰＵ１２Ｂ（制御部）は、プログラムに従って、メニュー提供部１２ｂ１と、提供依頼受信部１２ｂ２と、課金レート通知部１２ｂ３と、承認受信部１２ｂ４と、提供許可部１２ｂ５として機能する。

メニュー提供部１２ｂ１は、相手端末と通話中に、相手端末にコンテンツメニュー情報を提供する機能である。このメニュー提供部１２ｂ１は、例えば不特定多数のユーザ端末にコンテンツメニューを通知するプロバイダなどが運営するコンテンツ配信サーバ等にアクセスしてコンテンツの配信を希望する場合などに使用し、下記の個人ユーザ同士などのＰ２Ｐ通信には使用されない。提供依頼受信部１２ｂ２は、相手端末からコンテンツの提供依頼情報を受信する機能である。課金レート通知部１２ｂ３は、提供依頼を受けたコンテンツに対する課金レート情報を送信する機能である。承認受信部１２ｂ４は、相手端末から課金レート情報に対する承認情報を受信する機能である。そして、提供許可部１２ｂ５は、承認情報を受信後、相手端末に前記コンテンツの提供許可情報を送信するとともにコンテンツを送信する機能である。

また、リモートコントローラ装置（以下、「リモコン装置」と称す。）２ａを備え、ユーザ端末２の図示しないリモコン信号受信部を介して、リモコン装置２ａとユーザ端末２との間でリモコン信号の送受信が可能な構成としてある。ユーザ端末２のその他の構成は、ユーザ端末１と同じであるので説明を割愛する。

なお、説明の便宜上、ユーザ端末１をユーザ・エージェント・クライアントとし、ユーザ端末２をユーザ・エージェント・サーバとして説明したが、テレビ電話機やテレビ電話機能を備えたＰＣ等では通常、双方の機能を合わせ持っており、ユーザの操作等に応じてその役割・位置づけが切り替わる。

次に、本実施の形態における動的および柔軟なユーザ間の課金レート設定およびコンテンツ取得について説明する。本実施の形態は、ＮＧＮ網において、通信中にユーザ（端末）同士が有料情報（コンテンツ）を取引する際に、ユーザ間で動的および柔軟に課金レートの設定、承認および支払（決済）を行うことができるＰ２Ｐ課金方式であり、決済承認された場合にのみコンテンツの録音録画が可能である。図４は、課金レート設定およびコンテンツ取得のシーケンス図である。この図４について、図５〜図１１を参照して説明する。

図４のシーケンスにおいて、まず、ユーザ端末１とユーザ端末２が呼制御サーバ４を介して通信（セッション）を確立する（ステップＳ１）。このステップＳ１におけるセッション確立のシーケンスを、図５に示す。

図５のセッション確立のシーケンスにおいて、まずユーザ端末１のＣＰＵ１２Ａはユーザの電話操作を受け付けて、図６に示すような接続要求を表す「ＩＮＶＩＴＥ」リクエストを呼制御サーバ４に発信する（ステップＳ１１）。

ＳＩＰは、図６に示すように、メッセージすなわち通信データをテキスト形式で表現する。ＳＩＰのメッセージは大きく、「スタートライン」「ヘッダ」「ボディ」に分けられる。

スタートラインは、ＳＩＰメッセージの先頭の行であり、そのＳＩＰメッセージがどのようなもの目的のものなのかを表している。ＩＮＶＩＴＥなどのメソッド名は、リクエストとなるＳＩＰメッセージがどのような制御を要求するものであるかを示し、ＲＦＣ３２６１，２９７６，３３１１等の規格で規定されている。このスタートラインは、ユーザ・エージェント・クライアントからのリクエストまたはユーザ・エージェント・サーバからのレスポンスに応じて、それぞれスタートラインまたはリクエストラインと呼ばれる。

ヘッダは、ＳＩＰメッセージの制御内容について詳細を記したものであり、それぞれ予め規定された意味を持つ複数のヘッダ行により構成される。

ボディは、ＳＩＰメッセージによって運ばれるデータである。この例では、セッションを開設する際のメディアの情報が、ＳＤＰ（Session Description Protocol）という形式で表されている。ＳＤＰで記述される各レコードは、セッション記述、時間記述、メディア記述に分類されるタイプによって、その内容と形式が定められている。

例えば、ｍ行はメディア種別、ポート番号、トランスポート・プロトコル、フォーマットを示している。また、ｂ行は帯域情報を示す。図６に示す例では、ｍ行に「video」、ｂ行に「AS:1024」とあり、映像通信で使用する帯域を１０２４ｋｂｐｓで申告している。また、その下の行に記述されているｍ行には「audio」、ｂ行には「AS:64」とあり、音声通信で使用する帯域を６４ｋｂｐｓで申告している。

図５のセッション確立のフローチャートの説明に戻る。ユーザ端末１からの「ＩＮＶＩＴＥ」リクエストを受け付けた呼制御サーバ４は、その「ＩＮＶＩＴＥリ」クエストをユーザ端末２に転送する（ステップＳ１２）とともに、試行中を意味する「１００ Ｔｒｙｉｎｇ」のステータスコードを含むレスポンスをユーザ端末１へ送る（ステップＳ１３）。「ＩＮＶＩＴＥ」リクエストを受け付けたユーザ端末２は、「１００ Ｔｒｙｉｎｇ」のステータスコードを含むレスポンスを呼制御サーバ４へ返信する（ステップＳ１４）。

さらにユーザ端末２は、セッションの進捗状況を示す「１８３ Ｓｅｓｓｉｏｎ Ｐｒｏｇｒｅｓｓ」のステータスコードを含むレスポンスを、呼制御サーバ４を介してユーザ端末１へ返信する（ステップＳ１５，Ｓ１６）。

ユーザ端末２からの「１８３ Ｓｅｓｓｉｏｎ Ｐｒｏｇｒｅｓｓ」のステータスコードを含むレスポンスを受け付けたユーザ端末１は、暫定応答の確認を意味する「ＰＲＡＣＫ」リクエストを、呼制御サーバ４を介してユーザ端末２へ送信する（ステップＳ１７，Ｓ１８）。

ユーザ端末１からの「ＰＲＡＣＫ」リクエストを受け付けたユーザ端末２は、「ＰＲＡＣＫ」リクエストに対する処理が成功したことを意味する「２００ ＯＫ（ＰＲＡＣＫ）」のステータスコードを含むレスポンスを、呼制御サーバ４を介してユーザ端末１へ返信する（ステップＳ１９，Ｓ２０）。

ユーザ端末２からの「２００ ＯＫ（ＰＲＡＣＫ）」のステータスコードを含むレスポンスを受け付けたユーザ端末１は、セッションの変更を意味する「ＵＰＤＡＴＥ」リクエストを、呼制御サーバ４を介してユーザ端末２へ送信する（ステップＳ２１，Ｓ２２）。

ユーザ端末１からの「ＵＰＤＡＴＥ」リクエストを受け付けたユーザ端末２は、「ＵＰＤＡＴＥ」リクエストに対する処理が成功したことを意味する「２００ ＯＫ（ＵＰＤＡＴＥ）」のステータスコードを含むレスポンスを、呼制御サーバ４を介してユーザ端末１へ返信する（ステップＳ２３，Ｓ２４）。

また、ユーザ端末２は、上記「２００ ＯＫ（ＵＰＤＡＴＥ）」のステータスコードを含むレスポンスを返信した後、ユーザに電話に出るように促している（呼び出しベルを鳴らすなど）ことを意味する「１８０ Ｒｉｎｇｉｎｇ」のステータスコードを含むレスポンスを、呼制御サーバ４を介してユーザ端末１へ送信する（ステップＳ２５，Ｓ２６）。

ユーザ端末２からの「２００ ＯＫ（ＵＰＤＡＴＥ）」のステータスコードを含むレスポンスを受け付けたユーザ端末１は、暫定応答の確認を意味する「ＰＲＡＣＫ」リクエストを、呼制御サーバ４を介してユーザ端末２へ送信する（ステップＳ２７，Ｓ２８）。

ユーザ端末１からの「ＰＲＡＣＫ」リクエストを受け付けたユーザ端末２は、「ＰＲＡＣＫ」リクエストに対する処理、すなわちユーザの呼び出しが成功したことを意味する「２００ ＯＫ（ＰＲＡＣＫ）」のステータスコードを含むレスポンスを、呼制御サーバ４を介してユーザ端末１へ返信する（ステップＳ２９，Ｓ３０）。

さらに、ユーザ端末２は、上記「２００ ＯＫ（ＰＲＡＣＫ）」のステータスコードを含むレスポンスを返信した後、ステップＳ１２の「ＩＮＶＩＴＥ」リクエストに対する処理が成功したこと、すなわちユーザが電話に応答したことを意味する「２００ ＯＫ（ＩＮＶＩＴＥ）」のステータスコードを含むレスポンスを、呼制御サーバ４を介してユーザ端末１へ返信する（ステップＳ３１，Ｓ３２）。

これに対し、「２００ ＯＫ（ＩＮＶＩＴＥ）」のステータスコードを含むレスポンスを受けたユーザ端末１は、セッションの確立を最終的に確認したことを示す「ＡＣＫ」リクエストを、呼制御サーバ４を介してユーザ端末１へ送信する（ステップＳ３３，Ｓ３４）。このような一連の処理によりユーザ端末１とユーザ端末２との間のセッションが確立し、ユーザ端末１とユーザ端末２がリアルタイムコミュニケーションの通信を行うことができる。なお、ユーザ端末１とユーザ端末２との間のセッション確立のシーケンスは一例であり、この例に限られない。

また、図５のシーケンス図において、セッションの終了（切断）処理を記載したので、簡単に説明をしておく。ユーザ端末１からセッションの終了を行う場合、ユーザ端末１のユーザが例えばグラフィカル・ユーザ・インタフェース（GUI: Graphical User Interface）上で通信を切断する操作を行う。するとユーザ端末１は、セッションの終了（切断）を示す「ＢＹＥ」リクエストを、呼制御サーバ４を介してユーザ端末１へ送信する（ステップＳ４１，Ｓ４２）。

ユーザ端末１からの「ＢＹＥ」リクエストを受け付けたユーザ端末２は、「ＢＹＥ」リクエストに対する処理が成功したことを意味する「２００ ＯＫ（ＢＹＥ）」のステータスコードを含むレスポンスを、呼制御サーバ４を介してユーザ端末１へ返信する（ステップＳ４３，Ｓ４４）。これにより、セッションが終了する。

ここで、図４のシーケンスの説明に戻る。ステップＳ１の処理が終了後、ユーザ端末１のユーザは、ユーザ端末２のユーザとのリアルタイムコミュニケーションを通してユーザ端末２に保存されているコンテンツ（有料情報）の提供を要求する（ステップＳ２）。例えば、リアルタイムコミュニケーションの一例としてテレビ電話をしながら、話をする中で気に入ったコンテンツがあればそのコンテンツの提供を依頼する。または、ユーザ端末１のユーザは、ユーザ端末２のユーザにお願いして、ユーザ端末２に保存されているコンテンツの一部を視聴させてもらう。例えば、ユーザ端末２のユーザが推奨する映像、音楽、コンピュータプログラム、データ等に対するメタデータを見たり、映像のサムネイルを見たり、楽曲の試聴版を聞いたりする。そして、ユーザ端末１のユーザは気に入ったコンテンツがあれば、ユーザ端末２のユーザに対しそのコンテンツ（情報）の提供をテレビ電話の会話の中で依頼する。

なお、ユーザが提供を希望できる有料情報は、映像、音楽、コンピュータプログラム、データ等、予め相手側端末の記録手段に記録されているものに限らず、例えば占い師による占いの言葉（内容）などのようにリアルタイムサービスも含まれる。

以下、提供を希望する有料情報を占いの内容とした場合について説明する。
ユーザ端末１のユーザとユーザ端末２のユーザがテレビ電話通信中に、ユーザ端末１のユーザが、ユーザ端末２のユーザに対して音声で「ちょっと占って」と依頼する。ユーザ端末２側のユーザは、「では、１００円をいただきます」と答える。

同時に、ユーザ端末１のユーザからコンテンツの提供依頼を受けたユーザ端末２のユーザは、リモコン装置２ａまたはユーザ端末２を操作して、対象コンテンツの課金レートを液晶表示部２４に表示させる。ユーザ端末２のユーザは、画面上にリモコン装置２ａを操作して金額を入力する。

図７（ａ）〜（ｃ）に、提供を希望された情報に対する課金レート指示画面の一例を示す。図７（ａ）に示すように、まずユーザ２に対し課金レートの入力操作を行うか否かの指示を要求するメッセージが、ユーザ端末２に表示される。課金レートの入力操作を行う場合、例えばリモコン装置２ａの「緑」ボタンを押下する。次に、図７（ｂ）に示すように、ユーザから要求された情報に対して課金レート（課金金額、価格でもよい）を入力するよう指示するメッセージがユーザ端末２に表示される。課金レートを入力する場合、例えばリモコン装置２ａの「緑」ボタンを押下した後、図７（ｃ）の画面に遷移し、「１＋０＋０＋決定（緑）」を押下する。

ユーザは入力した課金レートでよければＯＫボタン（緑）をクリックする。課金レートを指示されたユーザ端末２の課金レート通知部１２ｂ３は、課金レート通知メッセージを呼制御サーバ４へ送信する（ステップＳ３）。

図８に、課金レート通知メッセージの一例を示す。この課金レート通知メッセージは、ＳＩＰメッセージのスタートラインに、セッション中の情報通知を意味するＩＮＦＯメソッドを記述したものである。図８に示す例では、最終行の課金レートラインに「FeeCollectionRate=100」と記述されており、課金レートは１００［円］であることを示している。

図４のシーケンス図に戻って、呼制御サーバ４は、ユーザ端末２から送られてきた課金レートを主記憶装置に記憶すると、課金レート通知メッセージをユーザ端末１へ送信する（ステップＳ４）。ユーザ端末１では、呼制御サーバ４から送られた課金レート通知メッセージを課金レート受信部１２ａ３が受信し、その最終行に記述されている課金レートラインを読み出して液晶表示部２４に表示する。

ユーザ端末１の承認通知部１２ａ４は、表示された課金レートの承認をユーザから指示されると、承認メッセージを呼制御サーバ４へ送信する（ステップＳ５）。

図９に、課金レート表示および承認画面の一例を示す。ユーザ端末１の画面上に、ユーザ端末２から通知された課金レート（１００円）が表示される。併せて通知された課金レートを承認するか否かをユーザに問い合わせるメッセージが表示される。ユーザ端末１のユーザが「了解しました」と言って、リモコン装置１ａのＯＫボタン（緑）を押下すると、承認メッセージがユーザ端末２へ送信される。反対する場合にはＮＯボタン（赤）を押下する。

図１０に、承認メッセージの一例を示す。この承認メッセージは、ＳＩＰメッセージのスタートラインに、セッション中の情報通知を意味するＩＮＦＯメソッドを記述したものである。図１０に示す例では、最終行の承認ラインに「PaymentRecognized=1」と記述されている。この例では、フラグ１を立てることにより承認の意を示している。

図４のシーケンス図に戻って、呼制御サーバ４は、ユーザ端末１から承認メッセージを受信すると、主記憶装置に記憶した課金レート情報を課金サーバ５へ通知し（ステップＳ６）、承認メッセージをユーザ端末２へ送信する（ステップＳ７）。課金レート情報を受信した課金サーバ５は、呼制御サーバ４から入力された課金レート情報を、ユーザ端末対応課金データのＰ２Ｐ課金情報ｎに記憶する。

図１１は、ユーザ端末対応課金データの一例を示すものである。課金サーバ５は、ユーザ端末番号（電話番号）と課金データを対応づけて管理している。図１１に示す例は、通信相手ごとに課金データ１〜ｎまでの情報が蓄積されている。一つの課金データは、通信相手（電話番号）、通信時間、Ｐ２Ｐ課金情報１〜ｎまでの情報を蓄積している。一つのＰ２Ｐ課金情報は、主記憶装置に記憶しておいた任意のユーザ端末の取得コンテンツに係る課金レートと通信時間を乗じたものであり、セッションごとにＰ２Ｐ課金情報１〜ｎが算出され記憶される。なお、図１１に示した例では、ユーザ端末番号ごとに通信料金の総計を算出して課金データとともに記憶しているが、通信相手ごとに通信料金を計算し、コンテンツ取得に係るＰ２Ｐ課金情報とともに課金情報を蓄積するようにしてもよい。

図４のシーケンス図に戻って、ユーザ端末２では、呼制御サーバ４から送られた承認メッセージを承認受信部１２ｂ４が受信し、その最終行に記述された承認情報を読み出して液晶表示部２４に表示する。

図１２に、承認表示画面の一例を示す。ユーザ端末２の画面上に、ユーザ端末２が通知した課金レートをユーザ端末１が承認したことを示すメッセージが表示される。この例では、課金サーバ５に対し１００円の課金が行われた旨の表示がなされる。ユーザ端末２のユーザが入金額を確認してリモコン装置２ａのＯＫボタン（緑）を押下すると、画面表示が録音録画許可画面に遷移する。

図１３に、録音録画許可画面の一例を示す。この画面では、ユーザ端末２のユーザに対し、相手（ユーザ端末１側）に録画（録音）をさせるか否かの最終判断を促すメッセージが表示される。承認する場合には、リモコン装置２ａのＯＫボタン（緑）を、反対する場合にはＮＯボタン（赤）を押下する。

そして、ＯＫボタン（緑）が押下された場合、ユーザ端末２の提供許可部１２ｂ５は、録音録画許可メッセージを呼制御サーバ４に送信する（ステップＳ８）。さらに呼制御サーバ４は、録音録画許可メッセージをユーザ端末１へ送信する（ステップＳ９）。

図１４に録音録画許可メッセージの一例を示す。この録音録画許可メッセージは、ＳＩＰメッセージのスタートラインに、セッション中の情報通知を意味するＩＮＦＯメソッドを記述したものである。図１４に示す例では、最終行の録音録画許可ラインに「RecPropriety＝1」と記述されている。この例では、フラグ１を立てることにより録音録画許可の意を示している。

ユーザ端末１において、コンテンツ取得部１２ａ５が録音録画許可メッセージを受信すると、録音録画が可能である旨を液晶表示部２４に表示する。あるいはユーザ端末１の所定位置に表示灯を設置し、この表示灯を点灯させる。

図１５に、録音録画可能（コンテンツ取得可能）通知画面の一例を示す。ユーザ端末１の画面上には、例えば録画可能な旨をユーザに知らせるとともに、録画を開始するか否かの指示を促すメッセージが表示される。リモコン装置２ａのＯＫボタン（緑）が押下されると、有料情報の録画（録音）が可能となる。

ユーザ端末２の提供許可部１２ｂ５は、ユーザ端末１からの承認メッセージを受信し、ユーザが録音録画の開始指示を出したことを確認すると、ユーザ端末１へ有料情報（コンテンツ）を提供する（ステップＳ１０）。本例においては、例えばユーザ端末２側の占い師は、テレビ電話のカメラを自分の顔、水晶玉、カードなどに向けて、ユーザ端末１側のユーザとコミュニケーションをとる。

ユーザ端末１のコンテンツ取得部１２ａ５は、ユーザ端末２から送信されてくる有料情報（コンテンツ）の録音録画を実行し提供を要求したコンテンツを外部記憶装置１５に記憶する。ユーザ端末１において、有料情報の録画（録音）が終了すると、図１６に示すような録画（録音）終了画面が表示される。録画（録音）を終了する場合は、リモコン装置１ａのＯＫボタン（緑）を、反対する場合にはＮＯボタン（赤）を押下する。

コンテンツの録音録画が終了後、セッションを終了する場合は図５に示したステップＳ４１〜Ｓ４３の処理を実行することでセッションが切断される。さらにユーザ端末１のユーザから有料情報提供の要求がなされたときは、上記一連の手順を繰り返す。

このように、会話上の成り行きから有料情報の提供および決済が行われる。本例の占いの場合、コミュニケーションの中で、何に関して（例えば恋愛など）、どういう手法で（例えば星占い,手相占いなど）占うのかなど、リアルタイムで変化する有料情報を把握することができる。これは、占いに限らずその他、映像、音楽、コンピュータプログラム、データ等においても、テレビ電話上で有料情報の把握、変更など種々の要求に応えることができる。

なお、実際の通信相手同士のパケット（映像パケット、音声パケット）は、呼制御サーバ４を介さずに端末同士で直接やり取りがなされる。つまり、上述の有料情報提供の依頼（ステップＳ２）および有料情報提供（ステップＳ１０）はＳＩＰメッセージではなく、音声パケットや映像パケットそのものなので、直接端末間で通信される。

以上説明したように、上述した実施の形態によれば、電話番号のインタフェースで有料情報を取得可能なネットワーク例えばＮＧＮ網において、ユーザ同士が電話などのリアルタイムコミュニケーション通信中に、相手端末に有料情報（コンテンツ）を提供する場合、課金レート情報、承認情報、決済情報（Ｐ２Ｐ課金通知）、録音録画許可情報をＩＰコミュニケーションメッセージにて相手端末または課金サーバに通知することにより、リアルタイムに課金レートの設定、有料情報の提供および有料録音・録画を実現できる。また、ユーザ同士で通信を行いながら、課金レートの設定および承認と連動して、有料情報（コンテンツ）を取得することができる。

したがって、電話サービスのようなリアルタイムコミュニケーション通信中に、ダイナミック（動的および柔軟）に有料情報を取得でき、これまでＰＣなどの端末装置の操作が苦手でネットワークから情報を取得できなかった人達も安易にその場で有料情報を取得でき、ユーザの利便性の向上に大きく寄与する。

なお、上記実施の形態では、課金サーバに蓄積されたユーザ端末対応課金データに基づく決済処理は、既存の方式を利用して実施することができる。例えば、コンテンツ取得に係る課金データに基づく料金を、銀行等に開設されたユーザの口座から通常の通信料金と一緒にして引き落とすようにしてもよい。あるいは、コンテンツ取得に係る課金データに基づく料金を通常の通信料金と別にして、別途他の口座からの引き落し、オンラインバンキング、振り込み等により決済を行うようにしてもよい。

その他、本発明は、上述した実施の形態の例に限定されるものではなく、本発明の要旨を逸脱しない範囲において、種々の変形、変更が可能であることは勿論である。

本発明の一実施形態に係るネットワーク構成図である。 本発明の一実施形態に係るユーザ端末（コンテンツ依頼側）の構成例を示すブロック図である。 本発明の一実施形態に係るユーザ端末（コンテンツ提供側）の構成例を示すブロック図である。 本発明の一実施形態に係る課金レート設定およびコンテンツ取得のシーケンス図である。 本発明の一実施形態に係るセッション確立の一例を示すシーケンス図である。 本発明の一実施形態に係るＩＮＶＩＴＥメッセージの一例の説明図である。 本発明の一実施形態に係る課金レート指示画面の一例を示す説明図である。 本発明の一実施形態に係る課金レート通知メッセージの一例の説明図である。 本発明の一実施形態に係る課金レート表示および承認画面の一例を示す説明図である。 本発明の一実施形態に係る承認メッセージの一例の説明図である。 本発明の一実施形態に係るユーザ端末対応課金データ例を示す構成図である。 本発明の一実施形態に係る承認表示画面の一例を示す説明図である。 本発明の一実施形態に係る録音録画許可画面の一例を示す説明図である。 本発明の一実施形態に係る録音録画許可メッセージの一例の説明図である。 本発明の一実施形態に係る録音録画可能通知画面の一例を示す説明図である。 本発明の一実施形態による録画終了画面の一例を示す説明図である。

符号の説明

１，２…ユーザ端末、１ａ，２ａ…リモコン装置、３…ＮＧＮ、４…呼制御サーバ、５…課金サーバ、１２Ａ・・・ＣＰＵ、１２ａ１…メニュー取得部、１２ａ２…提供依頼通知部、１２ａ３…課金レート受信部、１２ａ４…承認通知部、１２ａ５…コンテンツ取得部、１２Ｂ…ＣＰＵ、１２ｂ１…メニュー提供部、１２ｂ２…提供依頼受信部、１２ｂ３…課金レート通知部、１２ｂ４…承認受信部、１２ｂ５…提供許可部、１３…ＲＯＭ、１４…ＲＡＭ、１５…外部記憶装置、１７…操作部、１９…マイクロフォン、２２…音声出力部、２４…液晶表示部

Claims (12)

1. 接続管理サーバを介して、リアルタイムコミュニケーションのための通信のセッションを確立する第１端末と第２端末との間で提供されるコンテンツに課金を行う課金システムにおいて、
   前記第１端末の第１ユーザから通話により提供依頼を受けたコンテンツに対する課金レート情報を、前記第２端末の第２ユーザの指示に基づいて前記接続管理サーバを介して前記第１端末へ送信し、
   前記第１端末は、前記提供依頼をしたコンテンツに対する課金レート情報を受信した後、前記第１ユーザによる前記課金レート情報の承認操作を受けて承認情報を、前記接続管理サーバを介して前記第２端末へ向けて送信し、
   前記接続管理サーバは、前記承認情報を受けて前記課金レート情報を課金サーバへ通知するとともに、前記承認情報を前記第２端末へ送信し、
   前記第２端末は、前記課金レート情報に対する承認情報を受信した後、前記接続管理サーバを介して前記第１端末へ前記コンテンツの録音録画許可情報を送信するとともに、前記コンテンツを前記第１端末へ送信し、
   前記第１端末は、前記コンテンツの録音録画許可情報を受信した後、前記第２端末から前記コンテンツを取得する
   コンテンツ課金システム。
2. 前記課金サーバは、端末の電話番号と課金情報を対応づけて蓄積している
   請求項１に記載のコンテンツ課金システム。
3. 相手端末とリアルタイムコミュニケーションのための通信のセッションを確立する通信部と、
   前記相手端末との通話を通じてコンテンツの提供依頼情報を、前記相手端末へ送信する提供依頼通知部と、
   前記コンテンツに対する課金レート情報を、前記相手端末から受信する課金レート受信部と、
   ユーザによる前記課金レート情報の承認操作を受けて承認情報を、前記相手端末へ送信する承認通知部と、
   前記承認情報を受信した前記相手端末から前記コンテンツの録音録画許可情報を受信し、前記相手端末から前記コンテンツを取得するコンテンツ取得部と
   を備えるコンテンツ取得装置。
4. 前記承認通知部から送信された前記承認情報は接続管理サーバを経由して前記相手端末へ送信され、前記接続管理サーバは、前記承認情報を受けて前記課金レート情報を課金サーバへ通知すると、前記承認情報を前記相手端末へ送信する
   請求項３に記載のコンテンツ取得装置。
5. 表示部に表示される画面の画像信号を生成する画像信号生成部を更に備え、
   前記画像信号生成部は、前記課金レート情報の表示とともに承認を行うための画面、並びに前記コンテンツの録音録画許可情報を表示する画面の画像信号を生成する
   請求項４に記載のコンテンツ取得装置。
6. コンテンツ取得装置が、相手端末とリアルタイムコミュニケーションのための通信のセッションを確立するステップと、
   前記コンテンツ取得装置が、前記相手端末との通話を通じてコンテンツの提供依頼情報を、前記相手端末へ送信するステップと、
   前記コンテンツ取得装置が、前記コンテンツに対する課金レート情報を、前記相手端末から受信するステップと、
   前記コンテンツ取得装置が、該コンテンツ取得装置のユーザによる前記課金レート情報の承認操作を受けて承認情報を、前記相手端末へ送信するステップと、
   前記コンテンツ取得装置が、前記承認情報を受信した前記相手端末から前記コンテンツの録音録画許可情報を受信し、前記相手端末から前記コンテンツを取得するステップと
   を備えるコンテンツ取得方法。
7. 相手端末とリアルタイムコミュニケーションのための通信のセッションを確立する手順と、
   前記相手端末との通話を通じてコンテンツの提供依頼情報を、前記相手端末へ送信する手順と、
   前記コンテンツに対する課金レート情報を、前記相手端末から受信する手順と、
   当該コンピュータのユーザによる前記課金レート情報の承認操作を受けて承認情報を、前記相手端末へ送信する手順と、
   前記承認情報を受信した前記相手端末から前記コンテンツの録音録画許可情報を受信し、前記相手端末から前記コンテンツを取得する手順と
   を備えるコンテンツ取得方法をコンピュータに実行させるためのプログラム。
8. 相手端末とリアルタイムコミュニケーションのための通信のセッションを確立する通信部と、
   前記相手端末との通話を通じて前記相手端末からコンテンツの提供依頼情報を受信する提供依頼受信部と、
   ユーザの指示に基づき前記提供依頼情報を受けたコンテンツに対する課金レート情報を送信する課金レート通知部と、
   前記相手端末から前記課金レート情報に対する承認情報を受信する承認受信部と、
   前記承認情報を受信後、前記相手端末に前記コンテンツの録音録画許可情報を送信するとともに前記コンテンツを送信する提供許可部と
   を備えるコンテンツ提供装置。
9. 前記課金レート通知部は、前記コンテンツに対して前記ユーザにより指示された課金レートを通知する
   請求項８に記載のコンテンツ提供装置。
10. 表示部に表示される画面の画像信号を生成する画像信号生成部を更に備え、
    前記画像信号生成部は、前記コンテンツに対する課金レートを表示する画面、並びに前記課金レートに対する承認情報を表示する画面の画像信号を生成する
    請求項９に記載のコンテンツ提供装置。
11. コンテンツ提供装置が、相手端末とリアルタイムコミュニケーションのための通信のセッションを確立するステップと、
    前記コンテンツ提供装置が、前記相手端末との通話を通じて前記相手端末からコンテンツの提供依頼情報を受信するステップと、
    前記コンテンツ提供装置が、該コンテンツ提供装置のユーザの指示に基づき前記提供依頼情報を受けたコンテンツに対する課金レート情報を送信するステップと、
    前記コンテンツ提供装置が、前記相手端末から前記課金レート情報に対する承認情報を受信するステップと、
    前記コンテンツ提供装置が、前記承認情報を受信後、前記相手端末に前記コンテンツの録音録画許可情報を送信するとともに前記コンテンツを送信するステップと
    を備えるコンテンツ提供方法。
12. 相手端末とリアルタイムコミュニケーションのための通信のセッションを確立する手順と、
    前記相手端末との通話を通じて前記相手端末からコンテンツの提供依頼情報を受信する手順と、
    当該コンピュータのユーザの指示に基づき前記提供依頼情報を受けたコンテンツに対する課金レート情報を送信する手順と、
    前記相手端末から前記課金レート情報に対する承認情報を受信する手順と、
    前記承認情報を受信後、前記相手端末に前記コンテンツの録音録画許可情報を送信するとともに前記コンテンツを送信する手順と
    を備えるコンテンツ提供方法をコンピュータに実行させるためのプログラム。

Images