JP2017138941A - 情報処理装置、プログラム、課金方法 - Google Patents

Abstract

【課題】残高が少なくなっても料金を徴収して会議などの通信を継続できる情報処理装置を提供すること。【解決手段】伝送端末１０ａａが複数の伝送端末１０とコンテンツデータの伝送を行なう場合、少なくとも前記伝送端末の口座から伝送に関する使用料金を引き落とす情報処理装置５０であって、前記使用料金を算出する料金算出手段５８と、前記料金算出手段が算出した前記使用料金を前記伝送端末の前記口座から引き落とすことができるか否かを判定する残高判定手段６２と、前記使用料金を引き落とすことができないと前記残高判定手段が判定した場合、前記使用料金を引き落とすことができない前記伝送端末に関係する複数の他の伝送端末の内１つの伝送端末の口座の残高を用いて、前記伝送端末の前記使用料金を徴収する課金手段５９と、を有する。【選択図】図１

Description

本発明は、情報処理装置、プログラム及び課金方法に関する。

インターネット等の通信ネットワークを介して複数の拠点に設置された端末装置同士が通信して、遠隔地に存在する参加者同士が会議を行う伝送システムが知られている。この伝送システムの使用例として伝送システムが会議に使用される場合を説明する。参加者の一方がいる会議室などに設置された端末装置が参加者等を撮像し、また、参加者が発言した音声を収集する。端末装置は、参加者等の画像データや発言内容の音声データを他方の参加者がいる拠点に設置された端末装置に送信する。画像データや音声データを受信した端末装置はディスプレイに画像を表示し、スピーカから音声を出力する。これにより、実際の会議に近い状態で遠隔地の複数の拠点間で参加者が会議を行うことができる。

このような伝送システムに対する課金方法として、毎月、一定料金が課金される方式やタイムチャージにより使用した分だけが課金される方式の他、プリペイド方式がある。ユーザは予め自分の口座に対して任意の金額をチャージ(入金)しておく。伝送システムは各ユーザの伝送システムの使用時間等に応じて、口座から使用料金を引き落とす。プリペイド方式では、残高がゼロなどの閾値未満になった場合、ユーザは伝送システムを利用することができなくなり、会議中であれば会議から退出させられる（他の拠点と通信できなくなる）。

急に会議に参加できなくなることは業務に支障が出るなどの不都合があるため、会議を継続するための技術が考案されている（例えば、特許文献１参照。）。特許文献１には、残高が少なくなると音声や画像の品質を低下させることでユーザに課金の必要性を認識させ、課金残高がゼロになっても会話の継続が可能なシステムが開示されている。

しかしながら、特許文献１に記載されている会議システムでは、残高がゼロでも会議の継続は可能なので、会議システムの提供者側としては会議を無料で継続されてしまい、収益が得られにくいという問題があった。

本発明は、上記課題に鑑み、残高が少なくなっても料金を徴収して会議などの通信を継続できる情報処理装置を提供することを目的とする。

上記課題に鑑み、本発明は、伝送端末が１つ以上の他の伝送端末とコンテンツデータの伝送を行なう場合、少なくとも前記伝送端末の口座から伝送に関する使用料金を引き落とす情報処理装置であって、前記使用料金を算出する料金算出手段と、前記料金算出手段が算出した前記使用料金を前記伝送端末の前記口座から引き落とすことができるか否かを判定する残高判定手段と、前記使用料金を引き落とすことができないと前記残高判定手段が判定した場合、前記使用料金を引き落とすことができない前記伝送端末に関係する複数の他の伝送端末の内１つの伝送端末の口座の残高を用いて、前記伝送端末の前記使用料金を徴収する課金手段と、を有する。

残高が少なくなっても料金を徴収して会議などの通信を継続できる情報処理装置を提供することができる。

本実施例の会議システムの概略的な動作を説明する図の一例である。 本実施例に係る伝送システムの一例の概略図である。 伝送端末のハードウェア構成図の一例である。 伝送管理システムのハードウェア構成図の一例である。 伝送システムに含まれる伝送管理システム及び伝送端末の機能ブロック図の一例である。 複数の伝送端末の間で通信を開始する準備段階の処理を示したシーケンス図の一例である。 複数の伝送端末の間でセッションを確立する処理の一例のシーケンス図である。 会議開始前に伝送端末のユーザが臨時請求先の承認依頼を行なうフローチャート図の一例である。 伝送端末のディスプレイに表示される画面の一例を示す図である。 課金する請求先を一時的に変更して会議を継続するフローチャート図の一例である。 会議中に伝送端末が請求先となることの承認依頼を受信した場合に臨時請求先承認部がディスプレイに表示する承認依頼画面の一例である。 伝送システムに含まれる伝送管理システム及び伝送端末の機能ブロック図の一例である。 伝送端末１０ａｂの残高を伝送端末１０ａａの残高に移転して伝送端末１０ａａが会議を継続するフローチャート図の一例である。 会議中に伝送端末が残高の移転に対する承認依頼を受信した場合にディスプレイに表示する承認依頼画面の一例である。 伝送システムに含まれる伝送管理システム及び伝送端末の機能ブロック図の一例である（実施例３）。 伝送端末が複数の臨時請求先候補に対し、１つの通信ＩＤごとに順番に承認依頼を送信し、課金する請求先を一時的に変更して会議を継続するフローチャート図の一例である。 伝送システムに含まれる伝送管理システム及び伝送端末の機能ブロック図の一例である（実施例４）。 伝送端末が複数の臨時請求先候補の伝送端末に対し、いっせいに承認依頼を送信し、課金する請求先を一時的に変更して会議を継続するフローチャート図の一例である。

以下、本発明を実施するための形態について説明する。

図１は、本実施例の会議システムの概略的な動作を説明する図の一例である。異なる拠点にそれぞれ設置された伝送端末１０ａａ（後述する通信ＩＤは０１ａａ）と伝送端末１０ａｂ（通信ＩＤは０１ａｂ）が通信し、参加者によるテレビ会議が行われている。参加者は予め伝送端末１０に関連付けられている口座にポイントをチャージ(入金)している。課金を行う伝送管理システム５０は口座から使用料金を引き落としたり残高が十分かどうかなどを管理している。伝送管理システム５０は単位時間ごとに例えば５０ポイントを引き落とすものとして説明する。
（１）伝送端末１０ａａの残高が１５０ポイント、伝送端末１０ａｂの残高が２０５０ポイントの状態で単位時間が経過すると、伝送管理システム５０は伝送端末１０ａａと１０ａｂからそれぞれ５０ポイントを引き落とす。
（２）さらに単位時間が経過したが、伝送端末１０ａａの残高が１００ポイントであるため予め定めた閾値（例えば１１０）未満になっている。これにより伝送管理システム５０は伝送端末１０ａａの口座から使用料金を引き落とせないと判定する。
（３）このため伝送管理システム５０は、伝送端末１０ａａのテレビ会議の相手である伝送端末１０ａｂのユーザに、伝送端末１０ａｂの口座から引き落としてよいかどうかの承認を求める。
（４）伝送端末１０ａｂのユーザが承認すると、伝送管理システム５０は伝送端末１０ａｂの口座から伝送端末１０ａａの使用料金を引き落とす。したがって、伝送端末１０ａｂの口座の残高から２台の伝送端末１０ａａ、１０ａｂの使用料金の合計である１００ポイントが引き落とされる。

このように、本実施例の伝送システムでは、残高が閾値を下回った場合、テレビ会議の相手のユーザの口座から使用料金を引き落とす。したがって、伝送システムの提供者側は使用料金を確実に徴収することができる。また、口座の残高が少なくなっても音声や画像の品質が落とされないため、テレビ会議の参加者は高画質の画像かつすぐれた音質でテレビ会議を行うことができる。

＜用語について＞
伝送端末１０を使用する者をユーザという。ユーザが伝送端末１０でテレビ会議に参加する場合、ユーザは参加者と呼ばれる。本実施例ではユーザと参加者を厳密には区別しない。

伝送端末１０の使用料金は伝送システム１の提供者側により課金又は徴収される。具体的には、口座から引き落とされたり決済されたりする。本実施例では、徴収、課金、引き落とし又は決済を厳密には区別しない。

本実施例においてＩＤとは、複数の対象からある特定の対象を一意的に区別するために用いられる名称、符号、文字列、数値又はこれらの組み合わせをいう。ＩＤを識別情報や識別子と称してもよい。

口座から使用料金を引き落とすことができないとは、口座の残高を使用料金に使用できないことをいう。何らかの理由で口座の残高を使用料金に使用できない場合を含む。具体的には、上記のように口座の残高が足りない場合、口座が凍結されているなどにより引き落としができない場合、課金に関するサーバがメンテナンス中である場合などである。

＜システム構成例＞
図２は、本実施例に係る伝送システム１の一例の概略図である。伝送システム１は、伝送管理システム５０を介して複数の伝送端末間で情報や感情等を相互に伝達するためのコミュニケーションシステムである。伝送システム１の具体的なシステム例として、テレビ会議システム、テレビ電話システム、音声会議システム、音声電話システム、ＰＣ（Personal Computer）画面共有システム、テキストチャットシステム等が例として挙げられる。また、伝送システム１には、伝送管理システム５０を介して一方の伝送端末から他方の伝送端末に一方向でコンテンツデータを伝送するデータ提供システムが含まれる。

本実施例では、コミュニケーションシステムの一例としてのテレビ会議を行うことができるシステムを想定して説明する。

図２に示されている伝送システム１は、複数の伝送端末（１０ａａ，１０ａｂ，・・・）、複数の携帯端末（２０ａａ，２０ａｂ，・・・）、各伝送端末（１０ａａ，１０ａｂ，・・・）用のディスプレイ（１２０ａａ，１２０ａｂ，・・・）、複数の中継装置（３０ａ，３０ｂ，・・・）、伝送管理システム５０、及び、プログラム提供システム９０によって構築されている。

複数の伝送端末１０は、コンテンツデータの一例としての画像データ及び音声データの送受信を行う。すなわち、複数の伝送端末１０は、テレビ会議サービスを利用することができるテレビ会議端末（テレビ会議に専用の端末）である。

他方、複数の携帯端末２０は、コンテンツデータの一例としての画像データ及び音声データの送受信を行う。携帯端末２０はテキストデータを送受信可能であってもよい。すなわち、複数の携帯端末２０は、テレビ会議だけでなく、テキストチャットを利用できてもよい。本実施例では、携帯端末２０は、特に断らない限り、タブレット型端末、携帯電話、スマートフォン、ＰＤＡ（Personal Digital Assistant）、ウェアラブルＰＣ、ゲーム機器、汎用ＰＣ端末、カーナビゲーション端末、電子ホワイトボード、プロジェクタ、監視カメラ、通信機能を備えた産業用機器などであってもよい。また、産業用機器には、ＭＦＰ（Multifunction Peripheral/Printer/Product）等のオフィス機器、内視鏡等の医療用機器、耕耘機等の農業用機器などが含まれる。ウェアラブルＰＣには腕時計やヘッドマウントディスプレイ等が含まれる。なお、携帯端末２０は、例えば携帯電話通信網やＷｉＦｉ（Wireless Fidelity）などを介して通信ネットワーク２に無線で接続されている。

後述するハードウェア構成から明らかなように伝送端末１０及び携帯端末２０は情報処理装置としての機能を有している。

なお、以下では、複数の伝送端末（１０ａａ，１０ａｂ，・・・）のうちの任意の伝送端末は「伝送端末１０」と表され、複数の携帯端末（２０ａａ，２０ａｂ，・・・）のうちの任意の携帯端末は「携帯端末２０」と表されている。ディスプレイ１２０、中継装置３０、ルータ７０についても同様とする。

また、一方の伝送端末１０又は携帯端末２０から他方の伝送端末１０又は携帯端末２０へテレビ会議の開始を要求する伝送端末は「要求元端末」と表され、要求先である宛先としての端末は「宛先端末」と表されている。

伝送端末１０及び携帯端末２０は、伝送システム１の呼制御を管理する伝送管理システム５０により管理される。伝送システム１において、要求元端末と宛先端末との間では、伝送管理システム５０を介して、各種の管理情報を送受信するための管理情報用セッションが確立される。また、要求元端末と宛先端末との間では、中継装置３０を介して、コンテンツデータを送受信するためのセッションが確立される。なお、コンテンツデータのセッションでは、必ず中継装置３０を介する必要はなく、伝送管理システム５０を介して通信してもよいし、要求元端末と宛先端末とが直接、通信してもよい。

中継装置３０は、上記のように、複数の伝送端末１０と携帯端末２０との間で、コンテンツデータの中継を行う。

伝送管理システム５０は、伝送端末１０又は携帯端末２０の間で呼制御を行う。その他、伝送端末１０及び携帯端末２０のログイン認証、通話状況の管理、宛先リストの管理、及び、中継装置３０に対しコンテンツデータの送信先を通知したり、通話状況を管理させたりする等を行う。

伝送管理システム５０は情報処理装置であるが、又は、監視カメラ、通信機能を備えた産業用機器、ウェアラブルＰＣ等であってもよい。また、産業用機器には、ＭＦＰ等のオフィス機器、内視鏡等の医療用機器、耕耘機等の農業用機器などが含まれる。ウェアラブルＰＣには腕時計やヘッドマウントディスプレイ等が含まれる。

プログラム提供システム９０は、後述のＨＤ（Hard Disk）２０４に、伝送端末１０や携帯端末２０に各種機能を実現させるための端末用プログラムを記憶しており、伝送端末１０や携帯端末２０に端末用プログラムを送信することができる。プログラム提供システム９０は後述するＨＤ３０４に、伝送管理システム５０に各種機能を実現させるための管理装置用プログラムをも記憶しており、伝送管理システム５０に管理装置用プログラムを送信することができる。

伝送端末（１０ａａ，１０ａｂ，１０ａｃ，・・・）、中継装置３０ａ、及びルータ７０ａは、ＬＡＮ２ａによって通信可能に接続されている。伝送端末（１０ａｄ，１０ｂｂ，１０ｂｃ，・・・）、携帯端末（２０ａａ、２０ａｂ、…）、中継装置３０ｂ、及びルータ７０ｂは、ＬＡＮ２ｂによって通信可能に接続されている。また、ＬＡＮ２ａ及びＬＡＮ２ｂは、ルータ７０ａｂが含まれた専用線２ａｂによって通信可能に接続されており、所定の地域Ａ内で構築されている。例えば、地域Ａは日本であり、ＬＡＮ２ａは東京の事業所内で構築されており、ＬＡＮ２ｂは大阪の事業所内で構築されている。また、携帯端末（２０ａａ，２０ａｂ，・・・）は、地域Ａで利用されている。

一方、伝送端末（１０ｃａ，１０ｃｂ，１０ｃｃ，・・・）、中継装置３０ｃ、及びルータ７０ｃは、ＬＡＮ２ｃによって通信可能に接続されている。伝送端末（１０ｄａ，１０ｄｂ，１０ｄｃ，・・・）、携帯端末（２０ａｃ、２０ａｄ、…）、中継装置３０ｄ、及びルータ７０ｄは、ＬＡＮ２ｄによって通信可能に接続されている。また、ＬＡＮ２ｃ及びＬＡＮ２ｄは、ルータ７０ｃｄが含まれた専用線２ｃｄによって通信可能に接続されており、所定の地域Ｂ内で構築されている。例えば、地域Ｂはアメリカ合衆国であり、ＬＡＮ２ｃはニューヨークの事業所内で構築されており、ＬＡＮ２ｄはワシントンＤ．Ｃ．の事業所内で構築されている。また、携帯端末（２０ａｃ，２０ａｄ，・・・）は、地域Ｂで利用されている。

また、伝送管理システム５０及びプログラム提供システム９０は、インターネット２ｉを介して、伝送端末１０、携帯端末２０及び中継装置３０と通信可能に接続されている。伝送管理システム５０又はプログラム提供システム９０は、地域Ａ又は地域Ｂに設置されていてもよいし、これら以外の地域に設置されていてもよい。

また、図２において、各伝送端末１０、各携帯端末２０、各中継装置３０、伝送管理システム５０、各ルータ７０、及び、プログラム提供システム９０の下に示されている４組の数字は、一般的なＩＰｖ４におけるＩＰアドレスを簡易的に示している。

＜ハードウェア構成＞
<<伝送端末>>
次に、図３を用いて、伝送端末１０のハードウェア構成について説明する。図３は、本実施例に係る伝送端末のハードウェア構成図の一例である。図３に示されているように、本実施例の伝送端末１０は、伝送端末１０全体の動作を制御するＣＰＵ（Central Processing Unit）１０１を有する。また、ＩＰＬ（Initial Program Loader）等のＣＰＵ１０１の駆動に用いられるプログラムを記憶したＲＯＭ（Read Only Memory）１０２、及び、ＣＰＵ１０１のワークエリアとして使用されるＲＡＭ（Random Access Memory）１０３を有する。また、端末用プログラム、画像データ、及び音声データ等の各種データを記憶するフラッシュメモリ１０４を有する。また、ＣＰＵ１０１の制御にしたがってフラッシュメモリ１０４に対する各種データの読み出し又は書き込みを制御するＳＳＤ（Solid State Drive）１０５を有する。また、フラッシュメモリ等の記録メディア１０６に対するデータの読み出し又は書き込み（記憶）を制御するメディアドライブ１０７、及び、伝送端末１０の宛先を選択する場合などに操作される操作ボタン１０８を有する。また、伝送端末１０の電源のＯＮ／ＯＦＦを切り換えるための電源スイッチ１０９、及び、通信ネットワーク２を利用してデータ伝送をするためのネットワークＩ／Ｆ（Interface）１１１を備えている。

また、伝送端末１０は、ＣＰＵ１０１の制御にしたがって被写体を撮像して画像データを得る内蔵型のカメラ１１２、このカメラ１１２の駆動を制御する撮像素子Ｉ／Ｆ１１３、及び、音声を入力する内蔵型のマイク１１４を有する。また、音声を出力する内蔵型のスピーカ１１５、及び、ＣＰＵ１０１の制御にしたがってマイク１１４及びスピーカ１１５との間で音声信号の入出力を処理する音声入出力Ｉ／Ｆ１１６を有する。また、ＣＰＵ１０１の制御にしたがって外付けのディスプレイ１２０に画像データを伝送するディスプレイＩ／Ｆ１１７、及び、各種の外部機器を接続するための外部機器接続Ｉ／Ｆ１１８を有する。また、認証受付Ｉ／Ｆ１１９、及び、上記各構成要素を図３に示されているように電気的に接続するためのアドレスバスやデータバス等のバスライン１１０を備えている。

ディスプレイ１２０は、被写体の画像や操作用アイコン等を表示する液晶や有機ＥＬによって構成された表示装置である。また、ディスプレイ１２０は、ケーブル１２０ｃによってディスプレイＩ／Ｆ１１７に接続される。伝送端末１０のディスプレイ１２０は、ケーブル１２０ｃによってディスプレイＩ／Ｆ１１７に接続されているが、これに限られず、ディスプレイ１２０は、伝送端末１０に内蔵されていてもよい。

外部機器接続Ｉ／Ｆ１１８には、ＵＳＢ（Universal Serial Bus）ケーブル等によって、外付けカメラ、外付けマイク、及び外付けスピーカ等の外部機器がそれぞれ接続可能である。

認証受付Ｉ／Ｆ１１９は、ユーザから認証情報の入力を受け付けるインタフェースであり、具体的には、ＩＣカードリーダや（例えばＮＦＣ（Near field communication））、ＳＤカードやＳＩＭカード等の読み取り器が該当する。

さらに、端末用プログラムは、インストール可能な形式又は実行可能な形式のファイルで、上記記録メディア１０６等の、コンピュータで読み取り可能な記録媒体に記録して流通させるようにしてもよい。また、端末用プログラムは、フラッシュメモリ１０４ではなくＲＯＭ１０２に記憶させるようにしてもよい。

携帯端末２０のハードウェア構成については伝送端末１０のハードウェア構成と重複しているものとする。また、その相違があるとしても伝送システム１を構築する上で支障がないものとする。

≪伝送管理システム、中継装置、プログラム提供システム≫
次に、図４を用いて、伝送管理システム５０のハードウェア構成について説明する。図４は、本実施例に係る伝送管理システム５０のハードウェア構成図の一例である。

なお、図示する伝送管理システム５０等のハードウェア構成は、１つの筐体に収納されていたりひとまとまりの装置として備えられていたりする必要はなく、伝送管理システム５０等が備えていることが好ましいハード的な要素を示す。また、クラウドコンピューティングに対応するため、本実施例の伝送管理システム５０等の物理的な構成は固定的でなくてもよく、負荷に応じてハード的なリソースが動的に接続・切断されることで構成されてよい。

伝送管理システム５０は、伝送管理システム５０全体の動作を制御するＣＰＵ３０１、ＩＰＬ等のＣＰＵ３０１の駆動に用いられるプログラムを記憶したＲＯＭ３０２、及び、ＣＰＵ３０１のワークエリアとして使用されるＲＡＭ３０３を有する。また、管理装置用プログラム等の各種データを記憶するＨＤ３０４、及び、ＣＰＵ３０１の制御にしたがってＨＤ３０４に対する各種データの読み出し又は書き込みを制御するＨＤＤ(Hard Disk Drive)３０５を有する。また、フラッシュメモリ等の記録メディア３０６に対するデータの読み出し又は書き込み（記憶）を制御するメディアドライブ３０７、及び、カーソル、メニュー、ウィンドウ、文字、又は画像などの各種情報を表示するディスプレイ３０８を有する。また、通信ネットワーク２を利用してデータ伝送をするためのネットワークＩ／Ｆ３０９、文字、数値、各種指示などの入力のための複数のキーを備えたキーボード３１１、及び、各種指示の選択や実行、処理対象の選択、カーソルの移動などを行うマウス３１２を有する。また、着脱可能な記録媒体の一例としてのＣＤ−ＲＯＭ(Compact Disc Read Only Memory)３１３に対する各種データの読み出し又は書き込みを制御するＣＤ−ＲＯＭドライブ３１４を有する。さらに、上記各構成要素を図４に示されているように電気的に接続するためのアドレスバスやデータバス等のバスライン３１０を備えている。

なお、管理装置用プログラムは、インストール可能な形式又は実行可能な形式のファイルで、上記記録メディア３０６やＣＤ−ＲＯＭ３１３等のコンピュータで読み取り可能な記録媒体に記録して流通させるようにしてもよい。また、管理装置用プログラムは、ＨＤ３０４ではなくＲＯＭ３０２に記憶されるようにしてもよい。

また、中継装置３０及びプログラム提供システム９０は、上記の伝送管理システム５０と同様のハードウェア構成を有しているため、その説明を省略する。

＜伝送システムの機能構成＞
次に、図５を用いて本実施例の伝送システム１の機能構成について説明する。図５は、本実施例の伝送システム１に含まれる伝送管理システム５０及び伝送端末１０の機能ブロック図の一例である。図５では、伝送端末１０及び伝送管理システム５０が通信ネットワーク２を介してデータ通信することができるように接続されている。図２に示されている中継装置３０とプログラム提供システム９０は、テレビ会議の通信において直接関係ないため、図５では省略されている。

<<伝送端末の各機能構成>>
伝送端末１０は、送受信部１１、操作入力受付部１２、ログイン要求部１３、撮像部１４、表示制御部１５、音声入力部１６、音声出力部１７、宛先リスト作成部１８、臨時請求先承認依頼部１９、臨時請求先承認部２１、及び、記憶・読出処理部２９を有している。これら各部は、図３に示されている各構成要素のいずれかが、フラッシュメモリ１０４からＲＡＭ１０３上に展開された端末用プログラム１０１０に従ったＣＰＵ１０１からの命令によって動作することで実現される機能、又は提供される手段である。

また、伝送端末１０は、図３に示されているＲＡＭ１０３、ＲＯＭ１０２及びフラッシュメモリ１０４によって構築される記憶部１０００を有している。記憶部１０００には、端末用プログラム１０１０が記憶されている。

（伝送端末の各機能構成）
次に、伝送端末１０の各機能構成について詳細に説明する。伝送端末１０の送受信部１１は、図３に示されているＣＰＵ１０１からの命令、及び図３に示されているネットワークＩ／Ｆ１１１によって実現され、通信ネットワーク２を介して中継装置３０及び伝送管理システム５０と各種データの送受信を行う。送受信部１１は、所望の宛先端末と通信を開始する前から、伝送管理システム５０と宛先候補としての各端末の状態を示す各状態情報の受信を開始する。なお、この状態情報は、各伝送端末１０の稼動状態（オンラインかオフラインかの状態）だけでなく、オンラインであってもさらに通話中であるか、離籍中であるか等の詳細な状態を示す。送受信部１１は受信手段の一例である。

操作入力受付部１２は、図３に示されているＣＰＵ１０１からの命令、操作ボタン１０８及び電源スイッチ１０９等によって実現され、ユーザによる各種入力を受け付ける。例えば、ユーザが、図３に示されている電源スイッチ１０９をＯＮにすると、図３に示されている操作入力受付部１２が電源ＯＮを受け付けて、電源をＯＮにする。

ログイン要求部１３は、図３に示されているＣＰＵ１０１からの命令等によって実現され、電源ＯＮの受け付けを契機として、送受信部１１から通信ネットワーク２を介して伝送管理システム５０に、ログインを要求する旨を示すログイン要求情報、及び要求元端末の現時点のＩＰアドレスを自動的に送信する。また、ユーザが電源スイッチ１０９をＯＮの状態からＯＦＦにすると、送受信部１１が伝送管理システム５０へ電源をＯＦＦする旨の状態情報を送信した後に、操作入力受付部１２が電源を完全にＯＦＦにする。これにより、伝送管理システム５０側では、伝送端末１０が電源ＯＮから電源ＯＦＦになったことを把握することができる。

撮像部１４は、図３に示されているＣＰＵ１０１からの命令、カメラ１１２及び撮像素子Ｉ／Ｆ１１３等によって実現され、被写体を撮像して、この撮像して得た画像データを出力する。

表示制御部１５は、図３に示されているＣＰＵ１０１からの命令、及びディスプレイＩ／Ｆ１１７等によって実現され、他の拠点から送信された画像データを画像として表示するための画像処理を行ってディスプレイ１２０に画面として表示する。

音声入力部１６は、図３に示されているＣＰＵ１０１からの命令、及び音声入出力Ｉ／Ｆ１１６等によって実現され、マイク１１４によってユーザの音声が音声信号に変換された後、この音声信号に係る音声データを入力する。

音声出力部１７は、図３に示されているＣＰＵ１０１からの命令、及び音声入出力Ｉ／Ｆ１１６等によって実現され、音声データに係る音声信号をスピーカに出力し、スピーカ１１５から音声を出力させる。

宛先リスト作成部１８は、図３に示されているＣＰＵ１０１からの命令等により実現され、伝送管理システム５０から受信した、各宛先候補としての伝送端末１０の状態情報に基づいて、宛先候補の伝送端末１０の状態がアイコンで示された宛先リストの作成及び更新を行う。

臨時請求先承認依頼部１９は、図３に示されているＣＰＵ１０１からの命令等により実現され、臨時請求先となる伝送端末１０の選択を受け付け、臨時請求先となることの承認依頼を、ユーザが選択した伝送端末１０に送信する。

臨時請求先承認部２１は、図３に示されているＣＰＵ１０１からの命令等により実現され、伝送端末１０が臨時請求先の承認依頼を取得した場合に、後述するメッセージ等をディスプレイ１２０に表示し、ユーザから承認依頼を了承するか否かを受け付ける。

記憶・読出処理部２９は、図３に示されているＣＰＵ１０１からの命令、及びＳＳＤ１０５によって実行され、記憶部１０００に各種データを記憶したり、記憶部１０００に記憶された各種データを読み出したりする処理を行う。なお、記憶部１０００には、図示されるものの他、宛先端末との通話を行う際に受信される画像データ及び音声データが受信される度に上書き記憶される。

<<伝送管理システムの機能構成>>
伝送管理システム５０は、送受信部５１、端末認証部５２、状態管理部５３、端末抽出部５４、端末状態取得部５５、セッション管理部５６、中継装置決定部５７、料金計算部５８、課金部５９、臨時請求先設定部６０、臨時請求先判定部６１、残高判定部６２、及び、記憶・読出処理部６９を有している。これら各部は、図４に示されている各構成要素のいずれかが、ＨＤ３０４からＲＡＭ３０３上に展開された管理装置用プログラム５０１０に従ったＣＰＵ３０１からの命令によって動作することで実現される機能又は提供される手段である。

また、伝送管理システム５０は、図４に示されているＨＤＤ３０５、ＲＡＭ３０３、ＲＯＭ３０２等により構築される記憶部５０００を有している。以下、記憶部５０００に記憶されている各種データベースについて説明する。

記憶部５０００には、中継装置管理テーブルを保持する中継装置管理ＤＢ（Data Base）５００１が構築されている。この中継装置管理テーブルでは、各中継装置３０の中継装置ＩＤ毎に、各中継装置３０の稼動状態、稼動状態が伝送管理システム５０で受信された受信日時、中継装置３０のＩＰアドレス、及び中継装置３０における最大データ伝送速度（Ｍｂｐｓ）が関連付けられて管理される。

また、記憶部５０００には、端末認証管理テーブルを保持する端末認証管理ＤＢ５００２が構築されている。この端末認証管理テーブルでは、伝送管理システム５０によって管理される全ての伝送端末１０の通信ＩＤに対して、各パスワードが関連付けられて管理される。なお、ＩＣカードや生体認証情報によりユーザが認証されてもよい。

また、記憶部５０００には、通信ＩＤ管理テーブルを保持する通信ＩＤ管理ＤＢ５００３が構築されている。この通信ＩＤ管理テーブルでは、各伝送端末１０の通信ＩＤ毎に、各伝送端末１０を宛先とした場合の名称（宛先名）、伝送端末１０のＩＰアドレス、各伝送端末１０の稼動状態、料金情報、請求先、及び臨時請求先が関連付けられて管理される。通信ＩＤ、名称、料金情報及び請求先は、伝送端末１０の管理者などが予め登録している。稼動状態は、例えば、オンラインとオフラインとがあり、伝送管理システム５０による監視結果が登録される。料金情報は伝送端末１０ごとの単位時間当たりの料金を示し詳細は料金情報管理ＤＢ５００４に登録されている。請求先は伝送端末１０の口座に関する情報であり詳細は料金請求先管理ＤＢ５００８に登録されている。臨時請求先は、請求先が示す伝送端末１０の口座の残高が足りなくなった場合に臨時の請求先となる口座である。

また、記憶部５０００には、料金情報管理テーブルを保持する料金情報管理ＤＢ５００４が構築されている。この料金情報管理テーブルでは、料金情報ＩＤに対応付けて料金請求時間と料金が対応付けられている。料金情報ＩＤにより通信ＩＤ管理ＤＢ５００３の料金情報と対応付けられる。料金請求時間は使用料金を算出する単位時間である。料金は単位時間当たりの課金額である。例えば、料金情報ＩＤがfe_001と対応付けられている伝送端末１０は、会議開始後、１分ごとに使用料金が算出され、１分あたり１０円が引き落とされる。料金情報管理ＤＢ５００４の情報は、伝送端末１０の管理者やユーザが設定できる。

また、記憶部５０００には、セッション管理テーブルを保持するセッション管理ＤＢ５００５が構築されている。セッション管理ＤＢ５００５には、セッションを識別するためのセッションＩＤ毎に、通信ＩＤ、料金請求先ＩＤ、会議開始時刻及び料金引落し時間が対応付けて管理される。セッションＩＤと通信ＩＤは、どの伝送端末１０とどの伝送端末１０がテレビ会議を行っているか示す。つまり、同じテレビ会議に参加している伝送端末１０を示す。料金請求先ＩＤは伝送端末１０の使用料金がどの口座から引き落とされるかを示す。会議開始時刻は、伝送端末１０がテレビ会議を開始した時刻である。テレビ会議を開始するとは、伝送端末１０がログインに成功し、ユーザが指定した宛先端末とコンテンツデータの伝送を開始することをいう。料金引き落とし時刻は、最後に料金が引き落とされた時刻である。料金引き落とし時刻は単位時間の測定の起点として使用される。なお、セッション管理テーブルの情報は動的に更新される。

表５の例では、セッションＩＤがse1のテレビ会議では、通信ＩＤが01aa、01abの伝送端末１０がテレビ会議を行なっており、テレビ会議の開始時刻は2015/03/25 15:30:30、料金が引き落とされた最新の日時は2015/03/25 16:20:30である。

また、記憶部５０００には、宛先リスト管理テーブルを保持する宛先リスト管理ＤＢ５００６が構築されている。この宛先リスト管理テーブルでは、テレビ会議における通話の開始を要求する要求元端末の通信ＩＤに対して、宛先端末の候補として登録されている宛先端末の通信ＩＤが全て関連付けられて管理される。

表６に示されている宛先リスト管理テーブルでは、通信ＩＤが「０１ａａ」である要求元端末から通信の開始を要求することができる宛先端末の候補は、通信ＩＤが「０１ａｂ」、「０１ａｃ」、及び「０１ａｄ」の端末である。この宛先端末の候補は、任意の要求元端末から伝送管理システム５０に対する追加又は削除の要請により、追加又は削除されることで更新される。

また、記憶部５０００には、閾値金額管理テーブルを保持する閾値金額管理ＤＢ５００７が構築されている。閾値金額管理テーブルでは、閾値金額ＩＤに閾値金額が対応付けられている。閾値金額は、チャージされている残高がこの金額未満になった場合に伝送管理システム５０が料金請求先の変更判定を行なうための閾値である。閾値金額は、ユーザや伝送端末１０の管理者が設定できる。表７において閾値金額がゼロでないのは、完全にゼロになる前に残高が少なくなっていることをユーザが把握できるようにするためである。ただし、閾値金額はゼロでもよいし、また、全ての伝送端末１０に共通でもよい。

また、記憶部５０００には、料金請求先管理テーブルを保持する料金請求先管理ＤＢ５００８が構築されている。料金請求先管理テーブルでは、請求先ＩＤに残高と閾値金額が対応付けられている。請求先ＩＤとは使用料金が引き落とされる口座（又は、アカウント、勘定など）の識別情報である。閾値金額には閾値金額管理ＤＢ５００７の閾値金額ＩＤが設定されている。

料金請求先管理テーブルによって、請求先ＩＤが示す口座の残高はどのくらいか（伝送端末１０に対応付けられている残高がどのくらいか）、閾値金額がいくらなのかが管理される。使用料金が引き落とされると残高が減少し、入金されると増加する。

なお、以上の説明で、ＤＢやテーブルと称したのは説明の便宜のためであって、記憶部５０００に記憶されている情報がＤＢやテーブルの形態で記憶されている必要はない。また、ＤＢやテーブルと称されていなくてもよい。

（伝送管理システムの各機能構成）
次に、伝送管理システム５０の各機能構成について詳細に説明する。送受信部５１は、図４に示されているＣＰＵ３０１からの命令及びネットワークＩ／Ｆ３０９によって実行され、通信ネットワーク２を介して伝送端末１０又は中継装置３０と各種データの送受信を行う。

端末認証部５２は、図４に示されているＣＰＵ３０１からの命令によって実現され、送受信部５１を介して受信されたログイン要求情報に含まれている通信ＩＤ及びパスワードを検索キーとし伝送端末１０を認証する。すなわち、端末認証管理ＤＢ５００２を検索し、端末認証管理ＤＢ５００２に同一の通信ＩＤ及びパスワードが管理されているかを判定することによって端末認証を行う。なお、認証方法はこれに限られず、クライアント証明書（公開鍵と秘密鍵を用いた認証方法）を用いてもよい。

状態管理部５３は、図４に示されているＣＰＵ３０１からの命令等によって実現され、ログイン要求してきた要求元端末の稼動状態を管理すべく、通信ＩＤ管理ＤＢ５００３にこの要求元端末の通信ＩＤ、要求元端末の稼動状態、及び要求元端末のＩＰアドレスを関連付けて記憶して管理する。ログインにより要求元端末の稼動状態はオンラインとなる。

また、状態管理部５３は、ユーザが伝送端末１０の電源スイッチ１０９をＯＮの状態からＯＦＦにすることで、伝送端末１０から送られてきた、電源をＯＦＦする旨の状態情報に基づいて、通信ＩＤ管理ＤＢ５００３のオンラインを示す稼動状態をオフラインに変更する。

端末抽出部５４は、図４に示されているＣＰＵ３０１からの命令等によって実現され、ログイン要求した要求元端末の通信ＩＤをキーとして宛先リスト管理ＤＢ５００６を検索し、要求元端末と通話することができる宛先端末の候補の通信ＩＤを読み出す。また、端末抽出部５４は、ログイン要求してきた要求元端末の通信ＩＤをキーとして宛先リスト管理ＤＢ５００６を検索し、要求元端末の通信ＩＤを宛先端末の候補として登録している他の要求元端末の通信ＩＤも抽出する。

端末状態取得部５５は、図４に示されているＣＰＵ３０１からの命令等によって実現され、端末抽出部５４によって抽出された宛先端末の候補の通信ＩＤを検索キーとして、通信ＩＤ管理ＤＢ５００３を検索し、端末抽出部５４によって抽出された通信ＩＤ毎に稼動状態を読み出す。これにより、端末状態取得部５５は、ログイン要求してきた要求元端末と通話することができる宛先端末の候補の稼動状態を取得することができる。

セッション管理部５６は、図４に示されているＣＰＵ３０１からの命令等によって実現され、セッション管理ＤＢ５００５に、セッションＩＤ、要求元端末の通信ＩＤ、宛先端末の通信ＩＤ、料金請求先ＩＤ、会議開始時刻、及び、料金引落し時刻を関連付けて記憶して管理する。

中継装置決定部５７は、図４に示されているＣＰＵ３０１からの命令等によって実現され、テレビ会議が行われるセッションごとに適切な１台以上の中継装置を決定する。中継装置管理ＤＢ５００１のＩＰアドレスに基づいて伝送端末に１０に近い中継装置を決定したり、最大データ伝送速度が最も高い中継装置を決定したりする。

料金計算部５８は、図４に示されているＣＰＵ３０１からの命令等によって実現され、料金情報管理ＤＢ５００４を参照して、伝送端末１０が伝送システム１を使用した使用料金を算出する。

課金部５９は、図４に示されているＣＰＵ３０１からの命令等によって実現され、料金計算部５８が算出した使用料金を料金請求先管理ＤＢ５００８の残高から引き落とす。

残高判定部６２は、図４に示されているＣＰＵ３０１からの命令等によって実現され、使用料金の引き落としにより残高が閾値金額未満（閾値未満）になるかどうかを判定する。

臨時請求先判定部６１は、図４に示されているＣＰＵ３０１からの命令等によって実現され、残高が足りないと判定された場合、通信ＩＤ管理ＤＢ５００３に残高が足りないと判定された伝送端末１０の臨時請求先が設定されているか否かを判定する。

臨時請求先設定部６０は、図４に示されているＣＰＵ３０１からの命令等によって実現され、承認依頼を受けた伝送端末１０が臨時請求先となることを了承した場合、通信ＩＤ管理ＤＢ５００３の臨時請求先に承認した伝送端末１０の請求先（ac_00１等で示される口座）を設定する。

記憶・読出処理部６９は、図４に示されているＣＰＵ３０１からの命令及びＨＤＤ３０５によって実行され、記憶部５０００に各種データを記憶したり、記憶部５０００に記憶された各種データを読み出したりする処理を行う。

＜通信の開始からセッションの確立まで＞
図６は、複数の伝送端末１０の間で通信を開始する準備段階の処理を示したシーケンス図の一例である。図６では伝送端末１０ａａが伝送端末１０ａｂ，１０ａｄと通信を開始する準備の処理を説明する。

まず、ユーザが電源スイッチ１０９をＯＮにすると伝送端末１０ａａの操作入力受付部１２が電源ＯＮを受け付けて、電源をＯＮにする（ステップＳ２１）。

そして、伝送端末１０ａａのログイン要求部１３は電源ＯＮの受信を契機とし、送受信部１１から通信ネットワーク２を介して伝送管理システム５０に、ログイン要求を示すログイン要求情報を自動的に送信する（ステップＳ２２）。ログイン要求は電源ＯＮ時だけでなくユーザ操作によって任意のタイミングで送信されることができる。このログイン要求情報には、要求元である伝送端末１０ａａを識別するための要求元端末の通信ＩＤ、及びパスワードが含まれている。なお、伝送端末１０ａａから伝送管理システム５０へログイン要求情報が送信される際、受信側である伝送管理システム５０は伝送端末１０ａａの「ＩＰアドレス」を把握することができる。

次に、伝送管理システム５０の端末認証部５２は、送受信部５１を介して受信したログイン要求情報に含まれている通信ＩＤ及びパスワードと同一の通信ＩＤ及びパスワードが管理されているかを判定することによって端末認証を行う（ステップＳ２３）。本実施例では、認証が成立したものとして説明する。

端末認証部５２によって、伝送端末１０の認証が成立した場合、状態管理部５３は通信ＩＤ管理テーブルに、伝送端末１０ａａの通信ＩＤ、伝送端末１０ａａの「ＩＰアドレス」、「稼動状態（オンライン）」を関連付けて記憶する（ステップＳ２４）。なお、通信ＩＤは予め設定されていてもよい。

伝送管理システム５０の送受信部５１は、端末認証部５２によって得られた認証結果が示された認証結果情報を、通信ネットワーク２を介してログイン要求してきた伝送端末１０ａａに送信する（ステップＳ２５）。

伝送管理システム５０の端末抽出部５４は、ログイン要求した伝送端末１０ａａの通信ＩＤである"０１ａａ"を検索キーとして宛先リスト管理テーブルを検索し、伝送端末１０ａａと通信することができる伝送端末の候補の通信ＩＤを読み出すことによって抽出する（ステップＳ２６）。ここでは、伝送端末１０ａａの通信ＩＤである"０１ａａ"に対応する宛先端末（１０ａｂ，１０ａｃ、１０ａｄ）のそれぞれの通信ＩＤである"０１ａｂ"、"０１ａｃ"、"０１ａｄ"が抽出されることになる。

次に、端末状態取得部５５は、端末抽出部５４によって抽出された伝送端末１０ａｂ、１０ａｃ、１０ａｄの通信ＩＤ（"０１ａｂ"、"０１ａｃ"、"０１ａｄ"）を検索キーとして通信ＩＤ管理テーブルを検索し、通信ＩＤ毎に「稼動状態」を読み出す（Ｓ２７）。ここでは説明のため、伝送端末１０ａｂ、１０ａｄが"オンライン"、伝送端末１０ａｃが"オフライン"であるとする。

次に、送受信部５１は、端末抽出部５４が抽出した通信ＩＤ（"０１ａｂ"、"０１ａｃ"、"０１ａｄ"）と「稼動状態」とが含まれた宛先状態情報を、通信ネットワーク２を介して伝送端末１０ａａに送信する（ステップＳ２８）。これにより、伝送端末１０ａａは、伝送端末１０ａａと通信することができる伝送端末（１０ａｂ，１０ａｃ、１０ａｄ）の現時点のそれぞれの「稼動状態」を把握することができる。

さらに、伝送管理システム５０の端末抽出部５４は、ログイン要求してきた伝送端末１０ａａの通信ＩＤである"０１ａａ"を検索キーとして宛先リスト管理テーブルを検索し、通信ＩＤである"０１ａａ"を宛先端末の候補として登録している伝送端末１０の通信ＩＤを抽出する（ステップＳ２９）。ここでは説明のため、抽出される他の伝送端末１０の通信ＩＤは"０１ａｂ""０１ａｃ""０１ａｄ"であるとする。

次に、伝送管理システム５０の端末状態取得部５５は、ログイン要求して来た伝送端末１０ａａの通信ＩＤである"０１ａａ"を検索キーとして、通信ＩＤ管理テーブルを検索し伝送端末１０ａａの「稼動状態」を取得する（ステップＳ３０）。

そして、送受信部５１は、上記ステップＳ２９で抽出された通信ＩＤ（"０１ａｂ"、"０１ａｃ""０１ａｄ"）に係る伝送端末１０のうち、通信ＩＤ管理ＤＢ５００３で「稼動状態」が"オンライン"となっている伝送端末１０に、上記ステップＳ３０で取得された伝送端末１０ａａの通信ＩＤである"０１ａａ"と「稼動状態」として"オンライン"が含まれる宛先状態情報を送信する（ステップＳ３１、Ｓ３２）。したがって、伝送端末１０ａｂ、１０ａｄに宛先状態情報が送信される。

次に、伝送端末１０ａａの宛先リスト作成部１８は、ステップＳ２８で宛先状態情報を受け取ると、宛先リスト画面を作成し、表示装置２０３に表示させる（ステップＳ３３）。この場合の宛先リスト画面には、伝送端末１０ａｂ、１０ａｄの名称と「稼動状態」として"オンライン"が表示され、伝送端末１０ａｃの名称と「稼動状態」として"オフライン"が表示される。

一方、他の伝送端末１０ａｂ、１０ａｄでも、図６と同様の処理を行うことで、各伝送端末１０ａｂ、１０ａｄが宛先候補の伝送端末１０のディスプレイ１２０に宛先リスト画面が表示される。

図７は、本実施例に係る複数の伝送端末１０の間でセッションを確立する処理の一例のシーケンス図である。

ユーザが伝送端末１０ａａの操作ボタン１０８から宛先リスト画面に表示された通信ＩＤとして例えば"０１ａｂ"の宛先端末を選択すると、操作入力受付部１２は、接続を開始する要求を受け付ける（ステップＳ４１）。

伝送端末１０ａａの送受信部１１は、伝送端末１０ａａの通信ＩＤである"０１ａａ"と、「宛先端末の通信ＩＤ」である"０１ａｂ"とが含まれ、接続を開始したい旨を示す開始要求情報を伝送管理システム５０に送信する（ステップＳ４２）。これにより、伝送管理システム５０は要求元端末（伝送端末１０ａａ）の「ＩＰアドレス」を把握する。

次に、伝送管理システム５０のセッション管理部５６は「セッションＩＤ」を生成する（ステップＳ４３）。「セッションＩＤ」としては重複しないＩＤが生成される。

そして、この生成した「セッションＩＤ」と、要求元端末（伝送端末１０ａａ）の通信ＩＤである"０１ａａ"と、宛先端末（伝送端末１０ａｂ）の通信ＩＤである"０１ａｂ"とをセッション管理ＤＢ５００５に関連付けて記憶して管理する（ステップＳ４４）。また、セッション管理部５６は通信ＩＤである"０１ａａ"をキーにして通信ＩＤ管理ＤＢ５００３を検索し、請求先を読み出す。そして、読み出した請求先を生成したセッションＩＤに対応付けてセッション管理ＤＢ５００５の料金請求先ＩＤに設定する。

さらに、伝送管理システム５０の中継装置決定部５７は、要求元端末と宛先端末とが通信するのに適切な中継装置３０を決定する（ステップＳ４５）。中継装置３０を決定するための方法は、例えば受信と送信の帯域が最も広い通信ネットワーク２上にある中継装置３０を選択する等の方法が考えられる。

なお、中継装置３０を選択せずに、要求元端末及び宛先端末間で直接セッションを確立してもよいし、伝送管理システム５０を介したセッションを確立してもよい。

そして、伝送管理システム５０の送受信部５１は、ステップＳ４３で生成した「セッションＩＤ」と、ステップＳ４５で決定した中継装置３０の「ＩＰアドレス」とを要求元端末（伝送端末１０ａａ）及び宛先端末（伝送端末１０ａｂ）に送信する（ステップＳ４６，４７）。

伝送端末１０ａｂの表示制御部１５は要求元端末（伝送端末１０ａａ）の通信ＩＤや名称をディスプレイ１２０に表示するなどして、操作入力受付部１２がユーザによるテレビ会議の許可を受け付ける。そして、伝送端末１０ａｂの送受信部１１は開始許可を伝送管理システム５０に送信する（ステップＳ４７−１）。

次に、伝送管理システム５０の状態管理部５３は、中継開始要求情報として、要求元端末（伝送端末１０ａａ）の「ＩＰアドレス」と通信ＩＤ、宛先端末（伝送端末１０ａｂ）の「ＩＰアドレス」と通信ＩＤ、及び、セッションＩＤを中継装置３０に送信する（ステップＳ４８）。

中継装置３０はセッションＩＤ、通信ＩＤ及びＩＰアドレスを対応づけて管理する。伝送端末１０がコンテンツデータを中継装置３０に送信すると、中継装置３０はＩＰアドレス等に基づき伝送端末１０を識別しコンテンツデータを、同じセッションＩＤに対応付けられている伝送端末１０に送信する。あるいは、中継装置３０がセッションＩＤに対応付けられている伝送端末１０にデータＩＤを通知してもよい。この場合、伝送端末１０はコンテンツデータにデータＩＤを付与して中継装置３０に送信するので、中継装置３０は同じデータＩＤの伝送端末１０にコンテンツデータを送信する。

中継装置３０は伝送管理システム５０から中継開始要求情報を受信すると、伝送端末１０ａａと１０ａｂが送信する通信ＩＤを元にこれらがコンテンツデータの送信先であることを検出する。これにより、要求元端末（伝送端末１０ａａ）と宛先端末（伝送端末１０ａｃ）との間でセッションが確立される（ステップＳ４９）。セッションが確立することで、伝送端末１０ａａは中継装置３０を介してコンテンツデータを伝送端末１０ａｂに送信し、伝送端末１０ａｂは中継装置３０を介してコンテンツデータを伝送端末１０ａａに送信する。セッションが確立することで、伝送管理システム５０のセッション管理部５６はセッション管理ＤＢ５００５のセッションＩＤに対応付けて会議開始時刻を登録する。

次に、伝送端末１０ａａのユーザが招待通知を伝送管理システム５０に送信する（ステップＳ５０）。招待通知とは、すでにセッションが確立されているテレビ会議に別の伝送端末１０を参加させるための通知である。招待通知には招待通知を送信した伝送端末１０ａａの通信ＩＤである"０１ａａ"、招待される伝送端末１０の通信ＩＤが含まれる。招待される伝送端末１０は宛先リスト管理ＤＢ５００６において"０１ａａ"の通信ＩＤに対応付けられている宛先通信ＩＤの伝送端末１０のうち稼動状態がオンラインの伝送端末１０である。したがって、伝送端末１０ａｄの通信ＩＤ"０１ａｄ"が送信される。

伝送管理システム５０の送受信部５１が招待通知を受信すると、伝送管理システム５０の端末状態取得部５５は通信ＩＤ管理ＤＢ５００３から招待される伝送端末１０ａｄの「ＩＰアドレス」を取得する。これにより、伝送管理システム５０の送受信部５１は伝送端末１０ａｄに招待通知を送信する（ステップＳ５１）。

伝送端末１０ａｄの表示制御部１５は要求元端末（伝送端末１０ａａ）の通信ＩＤや名称をディスプレイ１２０に表示するなどして、操作入力受付部１２がユーザによるテレビ会議への招待に対する応答を受け付ける。ここではユーザは招待を受諾したものとする。そして、伝送端末１０ａｄの送受信部１１は招待受諾を伝送管理システム５０に送信する（ステップＳ５２）。

伝送管理システム５０の送受信部５１は招待通知を送信した伝送端末１０ａａに招待受諾を送信する（ステップＳ５３）。

この後、伝送管理システム５０の送受信部５１は招待された伝送端末１０ａｄに関し、ステップＳ４７、Ｓ４８の処理を行うことで、伝送端末１０ａａと１０ａｂのセッションに伝送端末１０ａｄが参加することができる。伝送管理システム５０のセッション管理部５６は伝送端末１０ａｄに伝送端末１０ａａ、１０ａｂと同じセッションＩＤに対応付けてセッション管理ＤＢ５００５に通信ＩＤを登録する。招待受諾によりセッションが確立するので、セッション管理部５６は料金請求先ＩＤと会議開始時刻をセッション管理ＤＢ５００５に登録する。中継装置３０は同じセッションＩＤの伝送端末１０ａａ、１０ａｂ、１０ａｄの間でコンテンツデータを送信（転送）する。

以降は、要求元端末（伝送端末１０ａａ）、宛先端末（伝送端末１０ａｂ）、及び、招待された伝送端末１０ａｄとの間で、中継装置３０を介してコンテンツデータが送受信される。

＜会議開始前の承認依頼＞
まず、テレビ会議の開始前の承認依頼と臨時請求先の登録について説明する。
図８は、会議開始前に伝送端末１０のユーザが臨時請求先の承認依頼を行なうフローチャート図の一例である。図８の処理は、会議開始前（セッションの確立前）の任意のタイミングで実行される。図８では、通信ＩＤが０１ａｃの伝送端末１０ａｃが、通信ＩＤが０１ａｄの伝送端末１０ａｄに対して承認依頼を出す場合を例にして説明する。また、図９は伝送端末１０のディスプレイ１２０に表示される画面の一例を示す図である。

まず、伝送端末１０ａｃの臨時請求先承認依頼部１９は、図９（ａ）の承認依頼送信画面をディスプレイ１２０ａｃに表示する。承認依頼送信画面の表示の契機はユーザの操作でもよいし、伝送端末１０ａｃの残高が閾値金額を下回るか又は閾値金額に近い場合に伝送管理システム５０が指示することでもよい。

伝送端末１０ａｃの送受信部１１は、臨時請求先として登録したいユーザが選択した伝送端末１０ａｄの通信ＩＤ（０１ａｄ）を指定して、伝送管理システム５０に臨時請求先の承認依頼を送信する(S1101)。

伝送管理システム５０の送受信部５１は承認依頼を受信し、臨時請求先設定部６０が伝送端末１０ａｄに承認依頼を送信する。伝送端末１０ａｄの送受信部１１は承認依頼を受信するので、伝送端末１０ａｄの臨時請求先承認部２１は図９（ｂ）の承認依頼画面を表示する。これにより、伝送端末１０ａｄのユーザは承認するかどうかを判断し、承認ボタン５１３又は否認ボタン５１４を押下する。承認ボタン５１３又は否認ボタン５１４のいずれかが押下されたという回答結果が伝送管理システム５０に送信される。

伝送管理システム５０の送受信部５１は回答結果を受信し、臨時請求先設定部６０は承認されたか否かを判定する(S1102)。

承認された場合（S1102のＹｅｓ）、伝送管理システム５０の臨時請求先設定部６０は伝送端末１０ａｃの通信ＩＤである０１ａｃに対応付けて、通信ＩＤ管理ＤＢ５００３の臨時請求先に伝送端末１０ａｄの口座を示すac_004という請求先ＩＤを登録する（S1103）。

ステップS1103に続き、及び、承認されなかった場合（S1102のＮｏ）、伝送管理システム５０の臨時請求先設定部６０は承認の可否を伝送端末１０ａｃに通知する。これにより、伝送端末１０ａｃのユーザは臨時請求先が設定されたか否かを把握できる。

画面について説明する。図９（ａ）は伝送端末１０ａｃのディスプレイ１２０ａｃに表示される承認依頼送信画面５０１の一例を示す図である。承認依頼送信画面５０１は、臨時請求先プルダウンボタン５０２、決定ボタン５０４及びキャンセルボタン５０５を有する。ユーザは操作ボタン１０８を操作して臨時請求先プルダウンボタン５０２を押下する。伝送端末１０ａｃの操作入力受付部１２は臨時請求先プルダウンボタン５０２の押下を受け付け、臨時請求先承認依頼部１９は臨時請求先選択欄５０３を表示する。臨時請求先選択欄５０３には、宛先リスト管理ＤＢ５００６に登録されている伝送端末１０ａｃの宛先端末の候補の名称が表示される。伝送管理システム５０の臨時請求先設定部６０は予め宛先リスト管理ＤＢ５００６と通信ＩＤ管理ＤＢ５００３を参照して、伝送端末１０ａｃの宛先端末の候補の名称を伝送端末１０ａｃに送信しておく。これにより、伝送管理システム５０は承認依頼の候補を伝送端末１０ａｃの宛先端末の候補に制限できるため、伝送端末１０ａｃのユーザがテレビ会議を行う相手とならない伝送端末１０に承認依頼を送信してしまうことを抑制できる。伝送端末１０ａｃの宛先端末の候補は、伝送端末１０ａｃに関係する伝送端末の一例である。

さらに、伝送管理システム５０の臨時請求先設定部６０は通信ＩＤ管理ＤＢ５００３において稼動状態がオンラインの伝送端末１０の名称のみを伝送端末１０ａｃに送信してもよい。これにより、伝送端末１０ａｃのユーザが選択した伝送端末１０に、伝送管理システム５０が承認依頼を送信できない事態が生じることを抑制できる。ただし、伝送端末１０ａｃのユーザが選択した伝送端末１０がオフラインでも、伝送管理システム５０は伝送端末１０がオンラインになったタイミングで承認依頼を送信できる。

なお、伝送管理システム５０は、臨時請求先選択欄５０３に表示される名称を伝送端末１０ａｃの宛先端末の候補に限定しなくてもよい。非常に多くの伝送端末１０を管理している企業などでは、宛先端末の候補に制限しなくても臨時請求先に設定可能な伝送端末１０があるためである。一方で、伝送端末１０が何ら関係のない伝送端末１０に承認依頼を送信しても承認される可能性が低いので、承認依頼を送信する伝送端末１０と何らかの関係がある伝送端末１０の名称のみを伝送管理システム５０が表示させることが好ましい。例えば、宛先端末の候補の他、伝送端末１０の管理者が所属、部署、グループ、地域、職責等に応じて予め関連付けている伝送端末１０などである。当然ながら、会議中の伝送端末１０は、互いに関係する伝送端末１０に含まれる。

ユーザは操作ボタン１０８を操作して臨時請求先選択欄５０３から臨時請求先としたい伝送端末１０の名称を選択する。伝送端末１０ａｃの臨時請求先承認依頼部１９は名称の選択を受け付ける。ユーザが決定ボタン５０４を押下すると操作入力受付部１２は決定ボタン５０４の押下を受け付け、伝送端末１０ａｃの送受信部１１は名称として表示されている伝送端末１０の通信ＩＤを伝送管理システム５０に送信する。

図９（ｂ）は、伝送端末１０ａｄが臨時請求先の承認依頼を受信した場合に臨時請求先承認部２１がディスプレイ１２０ａｄに表示する承認依頼画面５１１の一例である。図９（ｂ）の承認依頼画面５１１には、「「大阪事業所」さんから緊急時の請求先に登録する承認依頼が来ています。」というメッセージ５１２、承認ボタン５１３、及び、否認ボタン５１４が表示されている。「大阪事業所」は通信ＩＤ管理ＤＢ５００３に登録されている伝送端末１０ａｃの名称である。伝送管理システム５０の臨時請求先設定部６０は伝送端末１０ａｃの名称を通信ＩＤ管理ＤＢ５００３から読み出して、メッセージ５１２を生成して伝送端末１０ａｄに送信する。

伝送端末１０ａｄのユーザが承認ボタン５１３又は否認ボタン５１４のどちらを押下すると、伝送端末１０ａｄの臨時請求先承認部２１が押下を受け付ける。そして、伝送端末１０ａｄの臨時請求先承認部２１は送受信部１１を介して承認ボタン５１３又は否認ボタン５１４のどちらが押下されたという回答結果を伝送管理システム５０に送信する。この回答結果が図８のステップS1102の判定で使用される。

このようにして、通信ＩＤ管理ＤＢ５００３の臨時請求先が登録されると、テレビ会議の開催中にテレビ会議の相手に承認依頼する必要がない。したがって、臨時請求先の承認のためにテレビ会議が中断されることがない。

＜会議中における引き落とし処理＞
図８，９ではテレビ会議の開始前の臨時請求先の登録について説明したが、臨時請求先が登録されていない伝送端末１０の残高がテレビ会議の開始後に足りなくなることも少なくない。以下では、テレビ会議の開始後に残高が足りない場合にも対応した、使用料金の引き落とし方法（課金方法）について説明する。

伝送端末１０ａａと１０ａｂがテレビ会議を行っている場合に、セッション管理ＤＢ５００５において伝送端末１０ａａの料金請求先ＩＤに対応付けられている残高が閾値金額を下回ったものとする。伝送端末１０ａａは伝送端末１０ａｂの口座（ac_002）を請求先に変更し、使用料金を支払うことによりテレビ会議を継続する。なお、伝送端末１０ａａの通信ＩＤは"０１ａａ"、伝送端末１０ａｂの通信ＩＤは"０１ａｂ"である。

図１０は、使用料金の引落先を一時的に変更してテレビ会議を継続するフローチャート図の一例である。この例では、伝送端末１０ａａが請求先を変更するための承認依頼を会議中に行なう。会議中とはコンテンツデータの伝送中である。伝送端末１０ａａから見て伝送端末１０ａｂがコンテンツデータの伝送先である。

テレビ会議の開始後、まず、伝送管理システム５０の料金計算部５８は必要な使用料金を算出する(S1001)。使用料金の算出はセッション管理ＤＢ５００５の会議開始時刻から開始される。通信ＩＤ管理ＤＢ５００３によれば、伝送端末１０ａａの料金情報はfe_001となっている。また、料金情報管理ＤＢ５００４によればfe_001の料金請求時間は１分、料金は１０円である。したがって、料金計算部５８は１分ごとに１０円の使用料金を算出する。

次に、伝送管理システム５０の残高判定部６２はセッション管理ＤＢ５００５において伝送端末１０ａａの料金請求先ＩＤ（ac_001）が示す残高から使用料金を引き落とせるか否かを判定する(S1002)。料金請求先管理ＤＢ５００８によればac_001の残高は１０５円である。また、ac_001に紐付く閾値金額はth_001であるが、閾値金額管理ＤＢ５００７によればth_001の閾値金額は１００円である。

伝送管理システム５０の残高判定部６２は、
判定式１＝(対象端末の請求先の残高 - 使用料金)＜閾値金額
を満たすか否かを判定する。具体的には「１０５−１０＜１００」が成立するので、処理はステップS1003へ進む。つまり、伝送端末１０ａａは使用料金を引き落とすと残金が足りない状態になると判定される。

ステップS1003以降の処理を説明する。伝送管理システム５０の臨時請求先判定部６１は通信ＩＤ管理ＤＢ５００３において０１ａａの通信ＩＤに臨時請求先が登録されているか否かを判定する(S1003)。表４の通信ＩＤ管理ＤＢ５００３の通信ＩＤ"０１ａａ"に臨時請求先としてac_002が登録されているが、臨時請求先が登録されている場合はテレビ会議の開始前に臨時請求先の口座から使用料金を引き落とすという承認が得られている。このため、臨時請求先が登録されている場合（S1003のＹｅｓ）、処理はステップS1006に進む。

表４の通信ＩＤ管理ＤＢ５００３において通信ＩＤ"０１ａａ"に仮に臨時請求先が登録されていない場合、伝送端末１０ａａはテレビ会議を継続できなくなる。

そこで、臨時請求先が登録されていない場合（S1003のＮｏ）、伝送管理システム５０の臨時請求先設定部６０は請求先を変更するための承認依頼の処理を行う(S1004)。すなわち、伝送管理システム５０の臨時請求先設定部６０はテレビ会議をしている伝送端末１０ａｂに対し伝送端末１０ａｂの口座から使用料金を引き落としていいかどうかを問い合わせる承認依頼を行なう。具体的には、伝送管理システム５０の臨時請求先設定部６０は伝送端末１０ａａの通信ＩＤをキーに通信ＩＤ管理ＤＢ５００３の名称「本社」を読み出し、図１１の画面に表示されるメッセージ５１５を作成する。また、伝送端末１０ａａと同じセッションＩＤに対応付けられている通信ＩＤを読み取り、この通信ＩＤの伝送端末１０ａｂにメッセージ５１５を含む画面データ送信する。これにより、伝送端末１０ａｂのディスプレイ１２０ａｂには図１１のような画面が表示される。

伝送端末１０ａｂのユーザは承認依頼に回答するので、回答結果が伝送管理システム５０に送信される。

伝送管理システム５０の臨時請求先設定部６０は回答結果に基づいて承認されたか否かを判定する（S1005)。

承認されなかった場合（S1005のＮｏ）、伝送管理システム５０は伝送端末１０ａａをテレビ会議から退出させる(S1012)。すなわち、中継装置３０に伝送端末１０ａａと伝送端末１０ａｂのセッションを切断させる。より具体的には、伝送端末１０ａａから送信される画像データと音声データの中継を中止させ、伝送端末１０ａｂから送信された画像データと音声データの中継を中止させる。

承認された場合（S1005のＹｅｓ）、又は、ステップS1003でＹｅｓと判定された場合、伝送管理システム５０の臨時請求先設定部６０はセッション管理ＤＢ５００５の通信ＩＤ"０１ａａ"の料金請求先ＩＤを変更する。すなわち、臨時請求先(ac_002)又は通信ＩＤ管理ＤＢ５００３において通信ＩＤが"０１ａｂ"の請求先(ac_002)に変更する(S1006)。これにより、伝送管理システム５０の課金部５９は伝送端末１０ａａの使用料金を伝送端末１０ａｂの口座から引き落とすことができる。

ステップS1006で料金請求先ＩＤが更新されたので、伝送管理システム５０の残高判定部６２は変更後の請求先から使用料金を引き落とせるか否かを判定する（S1007）。伝送管理システム５０の残高判定部６２は、
判定式２＝(変更後の請求先の残高 - 必要な使用料金)＜閾値金額
を満たすか否かを判定する。具体的には「５０００−１０＜１００」が成立しないので、処理はステップS1008へ進む。つまり、伝送端末１０ａａは伝送端末１０ａｂのac_002の口座から使用料金を引き落としてもらうことができる。

この場合、伝送管理システム５０の課金部５９は一定時間が経過するまで待機する（S1008）。これは、使用料金が引き落とされるタイミングよりも前にステップS1001で使用料金が算出されているためである。したがって、この一定時間とは料金情報管理ＤＢ５００４の料金請求時間とほぼ同じである。

そして、一定時間が経過するとステップS1001で算出された使用料金を伝送管理システム５０の課金部５９が徴収することとなる（S1009）。このため、伝送管理システム５０のセッション管理部５６はセッション管理ＤＢ５００５の料金引落し時刻を更新する。次回のステップS1001の使用料金の算出とステップS1009の引落しは料金引落し時刻を基準に行われる。

なお、ステップS1007の判定がＹｅｓの場合、残高が閾値金額未満になるので伝送管理システム５０は伝送端末１０ａａをテレビ会議から退出させる(S1012)。

伝送管理システム５０は以上説明された図１０の処理をテレビ会議が継続されている間、繰り返す。伝送端末１０ａａの請求先が変更されたので伝送端末１０ａｂの残高が閾値金額以上の間、ステップS1002でＮｏと判定される。したがって、伝送端末１０ａbの口座から伝送端末１０ａａの使用料金を引き落とすことができる。

なお、テレビ会議が終了するとセッション管理テーブルが削除されるので、セッション管理ＤＢ５００５の料金請求先ＩＤが変更されていても、次回のテレビ会議には支障がない。

ステップS1002でＮｏと判定された場合を説明する。この場合、残高判定部６２は料金請求先管理テーブルの伝送端末１０ａａの残高が閾値金額以上かどうかを判定する（S1010）。使用料金を考慮して閾値金額＋αを閾値としてもよい。ステップS1002でＮｏと判定されるのはセッション管理テーブルの料金請求先ＩＤに対応付けられている請求先の残高から使用料金を支払える場合である。しかし、伝送端末１０ａａのユーザが会議中に自分の口座（料金請求先管理テーブルの請求先ＩＤで特定される口座）に入金する場合がある。このため、ステップS1010で伝送端末１０ａａのユーザが会議中に口座に入金したか否かを判定し、セッション管理テーブルの料金請求先ＩＤを元に戻すことを可能にする。

したがって、ステップS1010でＹｅｓと判定されると、臨時請求先設定部６０はセッション管理ＤＢ５００５の通信ＩＤ"０１ａａ"の料金請求先ＩＤに、通信ＩＤ管理テーブルで伝送端末１０ａａに対応付けられている請求先を設定する（S1011）。すなわち、ステップS1006で請求先が変更されている場合は元に戻す。ステップS1002でＮｏと判定される場合には、請求先が変更されていない場も含まれるがステップS1010でＹｅｓと判定されてもセッション管理テーブルの料金請求先ＩＤは元のままで変更されないので不都合はない。

次に、処理はステップS1008に進む。この場合、使用料金を引き落としても残高が閾値以上であるので、課金部５９は一定時間経過後にステップS1001で算出した使用料金を請求先ＩＤ（ac_001）が示す口座から引き落とす（S1009）。

このような処理によれば、臨時請求先の口座から使用料金を引き落としてもらうためにテレビ会議を行っている相手のユーザの承認が必要なので、相手のユーザが知らないうちに使用料金が引き落とされることがない。例えば、家族などでスマートフォン等の通信容量を分け合う通信キャリアの利用形態が知られているが、この利用形態では家族間の承認がないまま家族の各メンバーが通信容量を消費してしまう。これに対し本実施例の伝送システム１は、請求先の変更にこの請求先を口座とする伝送端末１０のユーザの承認が必要なので不測の事態が生じることがほとんどない。また、テレビ会議の相手から承認を受ける場合、テレビ会議の相手もテレビ会議を継続したいはずなので、請求先の変更が受け入れられやすい。

<<承認依頼を受信した伝送端末１０が表示する画面>>
図１１は、会議中に伝送端末１０ａｂが請求先となることの承認依頼を受信した場合に臨時請求先承認部２１がディスプレイ１２０ａｂに表示する承認依頼画面の一例である。なお、図１１の説明では図９（ｂ）との相違を主に説明する。承認依頼画面５１１は、「「本社」さんから緊急時の請求先に登録する承認依頼が来ています。」というメッセージ５１５、承認ボタン５１３、及び、否認ボタン５１４が表示されている。

伝送端末１０ａｂのユーザはメッセージ５１５を確認して承認ボタン５１３又は否認ボタン５１４を押下する。伝送端末１０ａｂの臨時請求先承認部２１は承認ボタン５１３又は否認ボタン５１４の押下を受け付ける。伝送端末１０ａｂの送受信部１１は承認ボタン５１３又は否認ボタン５１４のどちらが押下されたかを示す回答結果を伝送管理システム５０に送信する。

伝送端末１０ａｂのユーザが承認ボタン５１３を押下した場合、承認ボタン５１３が押下されたという回答結果が伝送管理システム５０に送信される。これにより、伝送管理システム５０の臨時請求先設定部６０は伝送端末１０ａａの通信ＩＤである０１ａａに対応付けて、セッション管理ＤＢ５００５の料金請求先ＩＤに伝送端末１０ａｂの口座を示すac_002を登録する。

以上説明したように、本実施例の伝送システム１は、テレビ会議の開始前及びテレビ会議の開始後のいずれの場合も口座を使用する伝送端末１０のユーザの承認を得て、口座の残高が足りなくなったユーザの使用料金を引き落とすことができる。このため、伝送システム１の提供者はユーザから使用料金を徴収でき、口座の残高が足りなくなったユーザもテレビ会議の継続することができる。また、画像や音声の品質が低下することもない。

実施例１では、臨時請求先又は変更後の請求先の口座に残高がある限り、伝送端末１０がテレビ会議を継続できる。しかし、会議開催中は臨時請求先又は変更後の請求先の口座の残高が減り続けてしまう。そこで、本実施例では、テレビ会議の開始前及びテレビ会議の開始後に、残高が足りない伝送端末１０がテレビ会議の所定時間分の残高を移転してもらう伝送システム１について説明する。

図１２は、本実施例の伝送システム１に含まれる伝送管理システム５０及び伝送端末１０の機能ブロック図である。本実施例において、図５において同一の符号を付した構成要素は同様の機能を果たすので、主に本実施例の主要な構成要素についてのみ説明する場合がある。図１２の伝送管理システム５０は残高移転部６３を有している。残高移転部６３は、図３に示されているＣＰＵ１０１からの命令等によって実現され、請求先となることをユーザが承認した伝送端末１０の口座から所定時間分の残高を、残高が足りない伝送端末１０の口座に移転する。

＜会議開始前の承認依頼＞
本実施例においてもテレビ会議の開始前に臨時請求先が登録され、テレビ会議中に臨時請求先の有無が判定されるのは同様である。したがって、図８の処理が行われたものとする。

＜会議中における引き落とし処理＞
図１３を用いて、所定時間分の残高の移転について説明する。なお、図１３の処理では図１０と同様に、伝送端末１０ａａと１０ａｂがテレビ会議を行っている場合に、セッション管理ＤＢ５００５の伝送端末１０ａａの料金請求先ＩＤに対応付けられている口座の残高が閾値金額を下回ったものとする。

図１３は、伝送端末１０ａｂの残高を伝送端末１０ａａの残高に移転して伝送端末１０ａａがテレビ会議を継続するフローチャート図の一例である。この例では、伝送端末１０ａａが伝送端末１０ａｂに残高を移転してもらうための承認依頼を会議中に行なう。まず、ステップS1001〜S1003、S1005、S1008,S1009、及び、S1012については図１０と同様である。また、図１３では図１０のステップS1010、S1011は不要になる。

ステップS1003においてＮｏと判定された場合、伝送管理システム５０の臨時請求先設定部６０は承認依頼を会議中の伝送端末１０ａｂに送信する(S10041)。伝送端末１０ａｂは承認依頼画面５１１を表示するが、この承認依頼画面５１１については図１４で説明する。

ステップS1005において承認された場合（S1005のＹｅｓ）、伝送管理システム５０の残高判定部６２は伝送端末１０ａｂの口座の残高を伝送端末１０ａａの口座に移転できるかどうかを判定する(S10051)。これは、移転することで伝送端末１０ａｂの口座の残高が閾値金額未満になると伝送端末１０ａｂがテレビ会議を継続できなくなるため、残高を移転すべきでないためである。具体的には、伝送管理システム５０の残高判定部６２は、
判定式３＝（移転元の請求先の残高-一定金額）＜閾値金額
を満たすか否かを判定する。一定金額は、例えば１０分などの所定時間分の使用料金に相当する金額である。料金情報管理ＤＢ５００４によれば伝送端末１０ａａの料金は１０（円／分）なので、１０（円／分）×１０分＝１００円が一定金額になる。

なお、判定式３の閾値金額は閾値金額管理ＤＢ５００７の閾値金額でなくてもよい。閾値金額管理ＤＢ５００７の閾値金額はテレビ会議の継続が困難となる閾値なので、閾値金額管理ＤＢ５００７の閾値金額よりも判定式３の閾値金額を大きくすることで、伝送端末１０ａｂがテレビ会議を所定時間以上、継続できる範囲で残高を移転できる。

ステップS10051の判定がＹｅｓの場合、残高を移転すべきでないので処理はステップS1012に進む。したがって、伝送端末１０ａａは退出させられる。

ステップS10051の判定がＮｏの場合、伝送管理システム５０の残高移転部６３は、承認依頼を出した伝送端末１０ａａの口座に、承認した伝送端末１０ａｂの口座から所定時間分の残高を移転する(S10052)。例えば、請求先ＩＤがac_001で示される伝送端末１０ａａの口座の残高が１０５円、請求先ＩＤがac_002で示される伝送端末１０ａｂの口座の残高が５０００円であるとする。一定金額が１００円なので、伝送端末１０ａａの口座の残高は２０５円、伝送端末１０ａｂの口座の残高は４９００円となる。

なお、ステップS10052の処理は、ステップS1003において臨時請求先が設定されていると判定された場合も行われる。この場合、会議前に承認されているので会議中には承認されていなくも、残高が移転される。

実施例１と異なりセッション管理ＤＢ５００５の料金請求先ＩＤには変更がないので、処理はステップS1008、S1009に進み、伝送端末１０ａａの口座から使用料金が引き落とされる。

このような処理によれば、臨時の請求先となることを承認したユーザが使用する伝送端末１０ａｂの口座から無制限に使用料金が引き落とされることを防止できる。例えば、何回も承認要求された伝送端末１０ａｂのユーザは承認要求に対し否認すればよい。

<<承認依頼を受信した伝送端末１０が表示する画面>>
図１４（ａ）は、会議中に伝送端末１０ａｂが残高の移転に対する承認依頼を受信した場合にディスプレイ１２０ａｂに表示する承認依頼画面の一例である。なお、図１４（ａ）では主に図１１との相違点を説明する。図１４（ａ）の承認依頼画面は、「「本社」さんから残高の移転について承認依頼が来ています。」というメッセージ５１６、承認ボタン５１３、及び、否認ボタン５１４が表示されている。伝送端末１０ａｂのユーザは会議中に残高を移転するかどうかを判断できる。

また、図１４（ｂ）に示すように、伝送端末１０ａｂの残高と移転される一定金額を表示してもよい。図１４（ｂ）では、「移転される金額は１００円（１０分）、移転後のあなたの残高は４９００円です」というメッセージ５１６が表示されている。これにより、伝送端末１０ａｂのユーザは自分の残高を考慮して移転を承認するか否かを判断できる。１００円や４９００円の算出は、図１３のステップS10051、S10052の処理を伝送管理システム５０の残高判定部６２が行う。なお、図１４（ｂ）のようなメッセージの表示は実施例１でも可能である。

また、図１４（ｃ）に示すように、伝送端末１０ａｂのユーザが移転する金額を入力可能でもよい。図１４（ｃ）では、「現在のあなたの残高は５０００円です。承認する場合は移転金額を入力してください。」というメッセージ５１７、移転金額選択欄５１８が表示されている。ユーザが操作ボタン１０８を操作して移転金額選択欄５１８を押下することで選択欄５１９が表示される。したがって、伝送端末１０ａｂのユーザは自分の現在の残高を考慮して、移転する金額を入力できる。

なお、伝送管理システム５０の臨時請求先設定部６０は料金請求先管理ＤＢ５００８から残高を読み出しメッセージ５１７を生成する。また、移転金額選択欄５１８及び選択欄５１９を表示させる画面データを生成し、伝送端末１０ａｂに送信する。

このように、本実施例の伝送システム１では、所定時間分の金額だけを移転できるので、承認依頼されたユーザも移転を承認しやすくなる。

実施例１では、残高が足りなくなったユーザの変わりに料金が徴収されるユーザが一人しかいない。このため、複数の拠点で会議を行なっている場合でも、残金が足りなくなった伝送端末１０は会議参加者の一人にしか料金の臨時請求を依頼できない。このため、会議を継続できる可能性が必ずしも高くないという問題があった。

そこで、本実施例では、会議参加者のうち複数の参加者に料金の臨時請求の承認を依頼できる伝送システム１について説明する。

図１５は、本実施例の伝送システム１に含まれる伝送管理システム５０及び伝送端末１０の機能ブロック図の一例である。本実施例において、図５において同一の符号を付した構成要素は同様の機能を果たすので、主に本実施例の主要な構成要素についてのみ説明する場合がある。

まず、本実施例の伝送管理システム５０は図５の記憶部５０００に示したデータベースに加え、グループ管理ＤＢ５０１１、承認依頼先範囲管理ＤＢ５０１２、承認依頼順決定条件管理ＤＢ５０１３、及び、臨時請求先履歴管理ＤＢ５０１４を有している。以下、記憶部５０００に記憶されている各種データベースについて説明する。

本実施例の通信ＩＤ管理テーブルは、表３の通信ＩＤ管理テーブルに加え、通信ＩＤに対応付けてグループ、臨時請求先承認依頼範囲、及び、臨時請求先承認依頼順決定条件を関連付けて管理している。グループは、伝送端末が属しているグループを表し、後述する表１０のグループ管理テーブルに詳細が登録されている。グループは例えば、同じ部署に所属する複数の伝送端末１０であったり、同じ管理者が管理する複数の伝送端末１０である。臨時請求先承認依頼範囲は、残高が足りなくなった伝送端末１０が会議中に臨時請求先として複数の伝送端末１０に登録承認依頼を送信する際、登録承認依頼を出す範囲を示す。詳細は表１１の承認依頼先範囲管理テーブルに登録されている。臨時請求先承認依頼順決定条件は、残高が足りなくなった伝送端末１０が会議中に複数の伝送端末１０に臨時請求先への登録承認依頼を送信する際に、どの順番で承認依頼を出していくかを示し、詳細は表１２の承認依頼順決定条件管理テーブルに登録されている。

記憶部５０００には、表１０に示すグループ管理テーブルを保持するグループ管理ＤＢ５０１１が構築されている。このグループ管理テーブルでは、グループＩＤに好ましくは複数の通信ＩＤが対応付けられている。なお、１つの通信ＩＤは複数のグループＩＤと対応付けられていてもよい。

また、記憶部５０００には、表１１に示す承認依頼先範囲管理テーブルを保持する承認依頼先範囲管理ＤＢ５０１２が構築されている。この承認依頼先範囲管理テーブルでは、範囲ＩＤに依頼先範囲が対応付けられている。依頼先範囲は、複数の臨時請求先候補がある場合、１つの臨時請求先候補ごとに順番に承認依頼を送信し、課金する請求先を一時的に変更して会議を継続する処理を伝送管理システム５０が行う際に、承認依頼先候補の順序を決定するために使われる。臨時請求先候補とは、課金の請求先に一時的に変更される候補の伝送端末１０である。

依頼先範囲には「全員」「同じグループ」「残高（所定以上の残高を有する伝送端末１０）」が登録されている。依頼先範囲が「全員」であれば、会議を行なっている全ての伝送端末１０が臨時請求先候補となる。「同じグループ」であれば、表１０で定義されているグループＩＤと紐付く通信ＩＤが臨時請求先候補の通信ＩＤとなる。ただし、同じ会議を行なっている伝送端末に限る。「残金1000円以上」であれば、同じ会議を行なっている伝送端末１０の内、表８の料金請求先管理テーブルで管理されている残高が1000円以上の伝送端末１０が臨時請求先候補となる。

また、記憶部５０００には、表１２に示す承認依頼順決定条件管理テーブルを保持する承認依頼順決定条件管理ＤＢ５０１３が構築されている。この承認依頼順決定条件管理テーブルでは、依頼順ＩＤと依頼順決定条件が対応付けられている。承認依頼順決定条件は、複数の臨時請求先候補から課金する請求先を一時的に選択して会議を継続する処理を伝送管理システム５０が行う際に、どの順番で承認依頼を出していくかを定める。例えば、「残高が多い」であれば、複数の伝送端末１０の内、残高が高い順に承認依頼を送信することを規定する。「臨時請求先に設定した日時が近い」であれば、後述する表１３の臨時請求先履歴管理テーブルで、臨時請求先候補の内、最も最近に臨時請求先として設定された伝送端末１０から順に承認依頼を送信する「臨時請求先にした回数が多い」であれば、表１３の臨時請求先履歴管理テーブルで、最も多く臨時請求先になった伝送端末１０から順に承認依頼を送信する。

また、記憶部５０００には、表１３に示す臨時請求先履歴管理テーブルを保持する臨時請求先履歴管理ＤＢ５０１４が構築されている。この臨時請求先履歴管理テーブルでは、日時と臨時請求先通信ＩＤが対応付けられている。臨時請求先通信ＩＤとは、課金の請求先に一時的に変更された伝送端末１０の通信ＩＤである。通信ＩＤごとに臨時請求先履歴管理テーブルが存在し、表１３の例は通信ＩＤが０１ａａの伝送端末１０ａａの履歴を表す。

（伝送管理システム５０の機能について）
図１５の伝送管理システム５０は図５と比較して、承認依頼先選出部６４、及び、承認依頼順決定部６５を有している。

承認依頼先選出部６４は、図３に示されているＣＰＵ１０１からの命令等によって実現され、臨時請求先への登録の承認依頼を送信する臨時請求先候補を選出する。臨時請求先候補は複数の場合もある。

承認依頼順決定部６５は、図３に示されているＣＰＵ１０１からの命令等によって実現され、複数の臨時請求先候補の中からどの順番で承認依頼を送信するかを決定する。

＜動作手順＞
図１６は、伝送端末１０が複数の臨時請求先候補に対し、１つの通信ＩＤごとに順番に承認依頼を送信し、課金する請求先を一時的に変更して会議を継続するフローチャート図の一例である。なお、ステップS3001、S3002は図１０のステップS1001、S1002と同様であり、ステップS3010以降は図１０のステップS1010以降と同様である。

本実施例では、通信ＩＤ が「０１ａａ,０１ａｂ,０１ａｃ,０１ａｄ」の伝送端末１０ａａ、１０ａｂ、１０ａｃ、１０ａｄがテレビ会議を行なっている際に、通信ＩＤが０１ａａの残高が閾値金額を下回った場合について説明する。

ステップS3003でＹｅｓと判定された場合、処理はステップS3006に進み、その後の処理は図１０のフローチャート図と同様でよい。

ステップS3003でＮｏと判定された場合、処理はステップS3003-2に進み、伝送管理システム５０の承認依頼先選出部６４は表９の通信ＩＤ管理テーブルから通信ＩＤ（０１ａａ）と対応付けられている臨時請求先承認依頼範囲(ra_002)を読み出し、臨時請求先候補の伝送端末１０を選出する。表１１の承認依頼先範囲管理テーブルによれば範囲ＩＤが「ra_002」の依頼先範囲は「同じグループ」である。そして、表９で通信ＩＤ（０１ａａ）と対応付けられているグループは「gr_001」である。承認依頼先選出部６４はgr_001に属している通信ＩＤと会議を行なっている通信ＩＤの双方に属している通信ＩＤを選出する。表１０のグループ管理テーブルでグループ「gr_001」に対応付けられている通信ＩＤは０１ａａ、０１ａｂ、０１ａｄ、０１ｂｂなので、臨時請求先候補の通信ＩＤとして０１ａｂ、０１ａｄが選出される。仮に、通信ＩＤが０１ａａの臨時請求先承認依頼範囲がra_001(全員)であれば、01ab, 01ac, 01adが選出されることとなる。

次にステップS3003-3では、承認依頼順決定部６５は、S3003-2にて選出された臨時請求先候補の内、どの順番で承認依頼を行うかを決定する(S3003-3)。表９で通信ＩＤが０１ａａに対応付けられている臨時請求先承認依頼順決定条件はso_001なので、表１２の承認依頼順決定管理テーブルより、「残高が多い」順となる。承認依頼順決定部６５は、表８の料金請求先管理テーブルを参照し、通信ＩＤが０１ａｂの請求先ＩＤ「ac_002」と、通信ＩＤが０１ａｄの請求先ＩＤ「ac_004」の残高を比較すると、ac_002の残高の方が多い（5000 > 3000）。したがって、承認依頼を出す順番は01ab、01adの順となる。

次に、ステップS3004では、ステップS3003-3で決定された順番にしたがって臨時請求先設定部６０は臨時請求先に登録することの承認を求める承認依頼を送信する。ステップS3003-3で決定された順番によると、まず、通信ＩＤが０１ａｂの伝送端末１０ａｂに承認依頼を送信し、ステップS3005へ進む。

ステップS3005では、臨時請求先設定部６０は通信ＩＤが０１ａｂの伝送端末１０ａｂが承認したかどうかを判定する(S3005)。

承認された場合、処理はステップS3006へ進む。ステップS3006以降の処理は図１０と同様でよいが、ステップS3007でＹｅｓの場合、処理はステップS3003-2に進む。これは、ステップS3007でＹｅｓと判定されても承認依頼先の候補が残っている可能性があるためである。

承認されなかった場合、処理はステップS3005-2へ進む。ステップS3005-2では、臨時請求先候補の伝送端末１０が残っているか否かを臨時請求先設定部６０は判定する（S3005-2）。ステップS3003-2では通信ＩＤが０１ａｂと０１ａｄの伝送端末１０ａｂ、１０ａｄが選出され、通信ＩＤが０１ａｂの伝送端末１０ａｂに否認されても、伝送端末１０ａｄが残っているため、処理はステップS3004へ進む。したがって、臨時請求先設定部６０は伝送端末１０ａｄに対し承認依頼を送信する。

臨時請求先候補の伝送端末１０が残っていなければ、処理はステップS3012へと進み、伝送端末１０ａａは退出させられる（会議は終了する）。退出とは、セッションが切断されることをいう。

図１６の処理は、臨時請求先候補となっている伝送端末１０の内、いずれかの伝送端末１０が承認するか、又は、臨時請求先候補となっている全ての伝送端末１０が否認するまで実行される。

図１０の処理と比較すると、図１０のステップS1007でYesと判定されるとその時点で伝送端末１０ａａは会議から退出させられてしまう。図１６の処理では、ステップS1007に対応するステップS3007で臨時請求先候補となっているいずれかの伝送端末１０が許可すれば、処理はステップS3008へと進み、伝送管理システム５０は他の伝送端末１０を臨時請求先として登録できる。このため、会議を継続しやすくなる。

以上のように、本実施例の伝送システム１は、テレビ会議に参加している複数の伝送端末１０に順番に承認依頼を送信するので、会議を継続できる可能性を増大させることができる。

本実施例では、実施例３と同様に会議を継続できる可能性を増大させることを目的にするが、承認依頼を臨時請求先候補の伝送端末１０に対しいっせいに送信する伝送システム１について説明する。

図１７は、本実施例の伝送システム１に含まれる伝送管理システム５０及び伝送端末１０の機能ブロック図である。本実施例において、図１５において同一の符号を付した構成要素は同様の機能を果たすので、主に本実施例の主要な構成要素についてのみ説明する場合がある。

図１７に示すように、図１５の承認依頼順決定条件管理ＤＢ５０１３の代わりに臨時請求先決定条件管理ＤＢ５０１５を有する。また、本実施例では通信ＩＤ管理テーブルが実施例３と異なっている。まず、これらのデータベースについて説明する。

表１４は、本実施例の通信ＩＤ管理テーブルを示す。表１４では表９との相違を説明する。表１４では、表９の臨時請求先承認依頼順決定条件に替えて臨時請求先決定条件が通信ＩＤに関連付けて管理されている。臨時請求先決定条件は、伝送端末１０が会議中に複数の臨時請求先候補の伝送端末１０に承認依頼をいっせいに送信し、複数の伝送端末１０が承認した場合にその中からどの伝送端末１０を臨時請求先に登録するかの条件を示す。詳細は表１５の臨時請求先決定条件管理テーブルに登録されている。

また、記憶部５０００には、表１５に示す臨時請求先決定条件管理テーブルを保持する臨時請求先決定条件管理ＤＢ５０１５が構築されている。この臨時請求先決定条件管理テーブルでは、決定条件ＩＤと臨時請求先決定条件が対応付けられている。臨時請求先決定条件は、複数の臨時請求先候補に対し、臨時請求先候補の全員にいっせいに承認依頼を出し、課金する請求先を一時的に変更して会議を継続する際、複数の伝送端末１０が承認した場合に、どの伝送端末１０を臨時請求先とするかを定める。例えば、決定条件ＩＤがdc_001, dc_002, dc_003については表１２の説明と同様である。dc_004の「承認が一番早い」については、臨時請求先決定部６６は、承認した伝送端末１０の内、一番承認が早かった伝送端末１０を臨時請求先に登録する。

（伝送管理システム５０の機能について）
図１７の伝送管理システム５０は図１５と比較して、臨時請求先決定部６６を有している。臨時請求先決定部６６は、図３に示されているＣＰＵ１０１からの命令等によって実現され、複数の伝送端末１０が臨時請求先となることを了承した場合、どの伝送端末１０を臨時請求先として登録するかを決定する。

＜動作手順＞
図１８は、伝送端末１０が複数の臨時請求先候補の伝送端末１０に対し、いっせいに承認依頼を送信し、課金する請求先を一時的に変更して会議を継続するフローチャート図の一例である。なお、ステップS4001〜S4003は、図１６のステップS3001〜S3003と同様であり、ステップS4010以降は図１６のステップS3010以降と同様である。

本実施例も通信ＩＤ が「０１ａａ,０１ａｂ,０１ａｃ,０１ａｄ」の伝送端末１０ａａ、１０ａｂ、１０ａｃ、１０ａｄがテレビ会議を行なっている際に、通信ＩＤが０１ａａの残高が閾値金額を下回った場合について説明する。

まず、ステップS4003-2では、通信ＩＤが０１ａｂ, ０１ａｄの伝送端末１０ａｂ、１０ａｄが承認依頼先候補に選出されたものとする。

ステップS4004では、臨時請求先設定部６０はステップS4003-2で選出された伝送端末１０ａｂ、１０ａｄに対し臨時請求先に登録することを依頼する承認依頼をいっせいに送信する(S4005)。

次に、ステップS4005では、臨時請求先決定部６６が承認した臨時請求先があるか否かを判定する（S4005）。承認した伝送端末１０が存在しなければ、処理はステップS4012へと進み伝送端末１０ａａはテレビ会議から退出させられる。

承認した伝送端末１０が１つ以上存在した場合、処理はステップS4005-2へ進む。ステップS4005-2では、臨時請求先決定部６６は承認した伝送端末１０の内、どの伝送端末１０を臨時請求先として登録するかを臨時請求先決定条件にしたがって決定する。表１４の通信ＩＤ管理テーブルを参照すれば、通信ＩＤが０１ａａに対応する臨時請求先決定条件は「dc_001」である。また、表１５の臨時請求先決定条件管理テーブルによれば臨時請求先決定条件が「dc_001」の臨時請求先決定条件は「一番残高が多い」である。臨時請求先決定部６６は残高が一番多い伝送端末１０を臨時請求先として登録する。表８の料金請求先管理テーブルを参照すると、通信ＩＤが０１ａｂに対応付けられた請求先ＩＤの ac_002と、通信ＩＤが０１ａｄに対応付けられた請求先ＩＤのac_002の残高を比較すると、ac_002の残高の方が多い（5000 > 3000）。したがって、臨時請求先決定部６６は伝送端末１０ａｂを臨時請求先に決定する。

ステップS4006以降の手順は図１６と同様でよい。

本実施例によれば、実施例３の効果に加え、複数の臨時請求先候補にいっせいに承認依頼を送信するので、実施例３よりも短時間に臨時請求先の伝送端末１０を決定しやすい。

＜その他の適用例＞
以上、本発明を実施するための最良の形態について実施例を用いて説明したが、本発明はこうした実施例に何等限定されるものではなく、本発明の要旨を逸脱しない範囲内において種々の変形及び置換を加えることができる。

例えば、本実施例では、セッションを確立している伝送端末１０の数について説明していないが、セッションを確立している伝送端末１０は３台以上でもよい。

また、本実施例では、会議に参加した全ての伝送端末１０から使用料金が徴収されたが、一般の電話のように要求元端末の伝送端末１０の口座だけから使用料金が徴収されてもよい。この場合も要求元端末の伝送端末１０の口座の残高が足りなくなれば、宛先端末の伝送端末１０の口座から使用料金が徴収される。

また、本実施例では、中継装置３０を介して伝送端末１０が通信しているが、伝送端末１０は中継装置を介さずに通信してもよい。このような通信の通信プロトコルとして例えばＷｅｂＲＴＣ（Web Real-Time Communication）が知られている。

また、図５などの構成例は、伝送管理システム５０及び伝送端末１０による処理の理解を容易にするために、主な機能に応じて分割したものである。処理単位の分割の仕方や名称によって本願発明が制限されることはない。伝送管理システム５０及び伝送端末１０の処理は、処理内容に応じてさらに多くの処理単位に分割することもできる。また、１つの処理単位がさらに多くの処理を含むように分割することもできる。

また、本実施例では説明の都合上、伝送管理システム５０と中継装置３０を別々の装置として説明したが、両者の機能が統合された装置が伝送管理システム５０と中継装置３０の機能を提供してもよい。

また、伝送システム１が複数の伝送管理システム５０を有していてもよく、伝送管理システム５０の機能が複数のサーバに分散して設置されていてもよい。

また、伝送管理システム５０が記憶部５０００に有する各データベースの１つ以上は通信ネットワーク２上に存在していてもよい。伝送端末１０が記憶部１０００に有するデータベースについても同様である。

また、記憶部１０００に示されたデータベースの構成は一例に過ぎない。例えば、表８の料金請求先管理ＤＢ５００８では、各請求先ＩＤに閾値金額が設定されているが、閾値金額が通信ＩＤ管理ＤＢに登録されていてもよい。

なお、上記の伝送端末１０ａａは伝送端末の一例であり、伝送端末１０ａｂは他の伝送端末の一例である。料金計算部５８は料金算出手段の一例であり、残高判定部６２は残高判定手段の一例であり、課金部５９は課金手段の一例であり、臨時請求先設定部６０は請求承認手段の一例であり、宛先リスト管理ＤＢ５００６は伝送端末リスト情報の一例である。宛先リスト管理ＤＢ５００６の宛先端末の候補は候補伝送端末の一例であり、残高移転部６３は金額移転手段の一例である。承認依頼順決定部６５は順番決定手段の一例であり、臨時請求先決定部６６は引落先決定手段の一例である。依頼順決定管理テーブルは順番決定情報の一例であり、臨時請求先決定条件管理テーブルは引落先決定情報の一例である。

１ ：伝送システム
１０ ：伝送端末
１９ ：臨時請求先承認依頼部
２１ ：臨時請求先承認部
５０ ：伝送管理システム
５８ ：料金計算部
５９ ：課金部
６０ ：臨時請求先設定部
６１ ：臨時請求先判定部
６２ ：残高判定部
６３ ：残高移転部

特開２００８−０６０２７０号公報

Claims (12)

1. 伝送端末が１つ以上の他の伝送端末とコンテンツデータの伝送を行なう場合、少なくとも前記伝送端末の口座から伝送に関する使用料金を引き落とす情報処理装置であって、
   前記使用料金を算出する料金算出手段と、
   前記料金算出手段が算出した前記使用料金を前記伝送端末の前記口座から引き落とすことができるか否かを判定する残高判定手段と、
   前記使用料金を引き落とすことができないと前記残高判定手段が判定した場合、前記使用料金を引き落とすことができない前記伝送端末に関係する前記他の伝送端末のうち１つの伝送端末の口座の残高を用いて、前記伝送端末の前記使用料金を徴収する課金手段と、を有する情報処理装置。
2. 前記使用料金を引き落とすことができないと前記残高判定手段が判定した場合、
   前記伝送端末の前記使用料金を引き落としてよいか否かを、前記コンテンツデータの伝送先の前記他の伝送端末に問い合わせる請求承認手段を有し、
   前記請求承認手段が引き落としを承認するという回答結果を取得した場合、前記課金手段は、前記伝送端末の前記使用料金を、前記他の伝送端末の口座から引き落とす請求項１に記載の情報処理装置。
3. 前記請求承認手段は、前記伝送端末が前記コンテンツデータの伝送を開始する前に、前記伝送端末の前記使用料金を引き落としてよいか否かを、前記伝送端末により指定された前記他の伝送端末に問い合わせ、
   引き落としを承認するという回答結果を取得した場合、前記伝送端末に該伝送端末により指定された前記他の伝送端末の口座を対応付けておき、
   前記コンテンツデータの伝送中に、前記使用料金を引き落とすことができないと前記残高判定手段が判定した場合、前記課金手段は、前記コンテンツデータの伝送先の前記他の伝送端末に問い合わせることなく、前記伝送端末に対応付けられている前記他の伝送端末の口座から、前記伝送端末の前記使用料金を引き落とす請求項２に記載の情報処理装置。
4. 前記課金手段は、前記伝送端末に前記他の伝送端末の口座が対応付けられているか否かを判定し、
   前記伝送端末に前記他の伝送端末の口座が対応付けられていない場合に、前記伝送端末の前記使用料金を引き落としてよいか否かを前記コンテンツデータの伝送先の前記他の伝送端末に問い合わせる請求項３に記載の情報処理装置。
5. 前記伝送端末が前記コンテンツデータを伝送する伝送先の候補となる候補伝送端末が登録された伝送端末リスト情報を前記請求承認手段が参照して、前記候補伝送端末を前記コンテンツデータの伝送を開始する前の前記伝送端末に送信し、
   前記請求承認手段は、前記伝送端末が選択を受け付けた前記候補伝送端末を前記伝送端末により指定された前記他の伝送端末として、該伝送端末の口座を前記伝送端末に対応付けておく請求項３に記載の情報処理装置。
6. 前記使用料金を引き落とすことができないと前記残高判定手段が判定した場合、
   前記伝送端末の前記使用料金を引き落としてよいか否かを、前記他の伝送端末に問い合わせる請求承認手段を有し、
   前記請求承認手段が引き落としを承認するという回答結果を取得した場合、前記伝送端末の口座に、前記他の伝送端末の口座から、所定時間分の前記コンテンツデータの伝送に必要な金額を移転する金額移転手段を有する請求項１に記載の情報処理装置。
7. 前記金額移転手段は、前記コンテンツデータの伝送先の前記他の伝送端末がユーザから受け付けた金額を前記伝送端末の口座に移転する請求項６に記載の情報処理装置。
8. 前記伝送端末リスト情報には１つの伝送端末に対し複数の前記候補伝送端末が登録されており、
   前記伝送端末の前記使用料金を引き落としてよいか否かの問い合わせを複数の前記候補伝送端末に行う際の順番を決定するための順番決定情報を参照して、前記順番を決定する順番決定手段を有し、
   前記請求承認手段は、引き落としを承認するという回答結果を前記候補伝送端末から取得するか、又は、前記候補伝送端末がなくなるまで、前記順番で、前記伝送端末の前記使用料金を引き落としてよいか否かの問い合わせ行う請求項５に記載の情報処理装置。
9. 前記伝送端末リスト情報には１つの伝送端末に対し複数の前記候補伝送端末が登録されており、
   前記請求承認手段は、前記伝送端末の前記使用料金を引き落としてよいか否かの問い合わせを複数の前記候補伝送端末に対しいっせいに行い、
   引き落としを承認するという回答結果を複数の前記候補伝送端末から取得した場合、複数の前記候補伝送端末から前記使用料金の引落先を決定するための引落先決定情報を参照して、前記引落先を決定する引落先決定手段、を有する請求項５に記載の情報処理装置。
10. 伝送端末が１つ以上の他の伝送端末とコンテンツデータの伝送を行なう場合、少なくとも前記伝送端末の口座から伝送に関する使用料金を引き落とす情報処理装置を、
    前記使用料金を算出する料金算出手段と、
    前記料金算出手段が算出した前記使用料金を前記伝送端末の前記口座から引き落とすことができるか否かを判定する残高判定手段と、
    前記使用料金を引き落とすことができないと前記残高判定手段が判定した場合、前記使用料金を引き落とすことができない前記伝送端末に関係する前記他の伝送端末の内１つの伝送端末の口座の残高を用いて、前記伝送端末の前記使用料金を徴収する課金手段として機能させるためのプログラム。
11. 前記使用料金を引き落とすことができないと前記残高判定手段が判定した場合、
    前記情報処理装置を、さらに、
    前記伝送端末の前記使用料金を引き落としてよいか否かを、前記コンテンツデータの伝送先の前記他の伝送端末に問い合わせる請求承認手段として機能させ、
    前記請求承認手段が引き落としを承認するという回答結果を取得した場合だけ、前記課金手段は、前記伝送端末の前記使用料金を、前記他の伝送端末の口座から引き落とす請求項１０に記載のプログラム。
12. 伝送端末が１つ以上の他の伝送端末とコンテンツデータの伝送を行なう場合、少なくとも前記伝送端末の口座から伝送に関する使用料金を引き落とす情報処理装置が行う課金方法であって、
    料金算出手段が、前記使用料金を算出するステップと、
    残高判定手段が、前記料金算出手段が算出した前記使用料金を前記伝送端末の前記口座から引き落とすことができるか否かを判定するステップと、
    前記使用料金を引き落とすことができないと前記残高判定手段が判定した場合、前記使用料金を引き落とすことができない前記伝送端末に関係する前記他の伝送端末の内１つの伝送端末の口座の残高を用いて、前記伝送端末の前記使用料金を徴収するステップと、を有する課金方法。

Images