JP2017011496A - 情報処理システム、情報処理装置、および情報処理プログラム - Google Patents

Abstract

【課題】通信の開始を要求する側の通信端末の数と、着信に応答する側の通信端末の数との不均衡が大きくなっても、通信端末間の接続を適切に管理する。【解決手段】第１のグループに分類される通信端末の識別情報を管理する第１の管理手段と、第２のグループに分類される通信端末の識別情報を管理する第２の管理手段と、管理される識別情報を更新する情報更新手段と、第２のグループに分類される複数の通信端末の識別情報の各々と、時間を示す情報とを関連付けて記憶するスケジュール管理ＤＢとを有する。情報更新手段は、第２のグループに分類される通信端末が応答可能な状態となったときに、第１の管理手段において識別情報が管理されていない場合には、第２の管理手段において、該応答可能な状態となった通信端末の識別情報を追加し、また、スケジュール管理ＤＢにおける時間に基づいて、第２の管理手段において管理される識別情報を維持又は削除する。【選択図】図４

Description

本発明は、情報処理システムに関する。

テレビ会議システムが用いられているコールセンタが知られている。例えば、着信可能なオペレータ端末を管理する管理装置が、テレビ電話からの通信を開始する要求に応じて、接続する端末を選択する（例えば、特許文献１参照）。この方法では、管理装置によって選択されたオペレータ端末に対して、オペレータが着信を受ける操作を行うことで、管理装置は、該オペレータ端末とテレビ電話との間に映像および音声の通信チャネルを開設する。

しかし、コールセンタなどで用いられるテレビ会議システムにおいて、通信の開始を要求する側の通信端末の数と、着信に応答する側の通信端末の数とが均衡していない場合には、通信の開始を要求する側に待ち時間が生じたり、着信に応答する側に待ち時間（空き時間）が生じたりする。この場合、一方の側のキューに基づいて、通信端末間の接続を管理した場合には、他方の側に待ちが発生したときに通信端末間の接続を管理することが困難になる問題がある。

この問題は、テレビ会議システムに限らず、着信に応答する側（オペレータ）の通信端末、及び通信の開始を要求する側（ゲスト）の通信端末を有する情報処理システムにも当てはまる。そして、この問題は、いずれか一方又は双方の通信端末が増加する程あるいは不均衡が大きくなる程大きくなる。特に、オペレータ側に待ち時間が多くある場合に、オペレータ側は、長時間待ちの状態となるが、長時間待ちの間に対応可能の状態が変化し、対応できない場合が生じる可能性が高まる。

そこで、本発明は、通信端末の数が増加しても、又は通信の開始を要求する側の通信端末の数と着信に応答する側の通信端末の数との不均衡、特に着信側に応答する側の通信端末の数が大きくなることによる不均衡が大きくなっても、通信端末間の接続を適切に管理することを目的とする。

開示の一実施形態に係る情報処理システムは、
第１のグループに分類される複数の通信端末の識別情報を管理する第１の管理手段と、
第２のグループに分類される複数の通信端末の識別情報を管理する第２の管理手段と、
前記第１の管理手段又は前記第２の管理手段において管理される識別情報を更新する情報更新手段と、
前記第２のグループに分類される複数の通信端末の識別情報の各々と、前記第２の管理手段において通信端末の識別情報を管理する時間を示す情報とを関連付けて記憶するスケジュール管理ＤＢと
を有し、
前記情報更新手段は、
前記第２のグループに分類される通信端末が、通信の開始の要求を行った通信端末に対して応答可能な状態となったときに、前記第１の管理手段において識別情報が管理されていない場合には、前記第２の管理手段において、該応答可能な状態となった通信端末の識別情報を追加し、
前記スケジュール管理ＤＢに記憶される通信端末の識別情報を管理する時間に基づいて、第２の管理手段において管理される識別情報を維持又は削除する。

以上説明したように本実施形態によれば、通信端末の数が増加しても、又は通信の開始を要求する側の通信端末の数と着信に応答する側の通信端末の数との不均衡、特に着信側に応答する側の通信端末の数が大きくなることによる不均衡が大きくなっても、通信端末間の接続を適切に管理することができる。

一実施形態に係る通信システムの全体構成図である。 一実施形態に係る端末のハードウェア構成図である。 一実施形態に係る制御装置、管理装置、ストレージサービス、及び中継装置のハードウェア構成図である。 一実施形態に係る端末、制御装置、及び管理装置の各機能ブロック図である。 待機端末管理テーブルを示す概念図である。 スケジュール管理テーブルを示す概念図である。 端末が状態情報を送信する処理を示したシーケンス図である。 端末が通信の開始要求を送信する処理を示したシーケンス図である。 通信の開始を待機する端末１０のキューを管理する処理を示したフロー図である。 通信の開始を待機する端末１０のキューを管理する処理を示したフロー図である。 セッションを確立する処理を示したシーケンス図である。

次に、本発明を実施するための形態を、以下の実施例に基づき図面を参照しつつ説明する。以下で説明する実施例は一例に過ぎず、本発明が適用される実施形態は、以下の実施例に限られない。
なお、実施例を説明するための全図において、同一機能を有するものは同一符号を用い、繰り返しの説明は省略する。

＜通信システムの全体構成＞
まず、図１を用いて、本発明の一実施形態に係る通信システムの全体構成について説明する。図１は、一実施形態に係る通信システムの全体構成図である。以下、通信端末を、単に「端末」と略して説明する。

一実施形態に係る通信システム１は、複数の端末（１０ａａ，１０ｂｂ，１０ｃｃ，１０ｄｄ，１０ｅｅ，１０ｆｆ）、中継装置３０、及び、管理システム５により構築される。管理システム５は、制御装置５０、管理装置６０、及びストレージサービス７０を備えている。以下、複数の端末（１０ａａ，１０ｂｂ，１０ｃｃ，１０ｄｄ，１０ｅｅ，１０ｆｆ）等のうち、任意の端末は「端末１０」と表されている。端末１０、中継装置３０、制御装置５０、管理装置６０、及びストレージサービス７０は、それぞれ、通信ネットワーク２を介して、他の端末、装置との間で通信可能に接続されている。通信ネットワーク２は、ＬＡＮ(Local Area Network)、インターネット、携帯電話網、あるいは専用線等を含んでいても良い。

一実施形態において、端末１０は、管理システム５側によって提供されるオペレータサービスを利用することができる。例えば、端末（１０ａａ，１０ｂｂ，１０ｅｅ）は、ゲストによって利用される。一方、端末（１０ｃｃ，１０ｄｄ，１０ｆｆ）は、オペレータによって利用される。端末（１０ａａ，１０ｂｂ，１０ｅｅ）と、端末（１０ｃｃ，１０ｄｄ，１０ｆｆ）との間では、コンテンツデータの送受信による通信が行なわれ、これによりゲストとオペレータとの間で通話することができる。なお、図１に示されている一実施形態の通信システム１において、ゲスト側の端末（１０ａａ，１０ｂｂ）は、操作性を考慮して、端末（１０ｃｃ，１０ｄｄ）と同じハードウェア構成を有する端末本体がキャビネットに収容されている。

ストレージサービス７０は、管理装置６０へアクセスための情報を管理する。この情報は、例えば、管理装置６０へアクセスためのＧＵＩ（graphical user interface）表示用のファイルである。このファイルは、例えば、HTML（HyperText Markup Language）によって記述されていても良い。また、このファイルは、PC(Personal Computer)等からストレージサービス７０にアクセスして、PC側からストレージサービス側に新たなファイルをアップロードすることによって更新される。ストレージサービス７０は、上記のファイルを端末１０へ送信することで、端末１０を管理装置６０へアクセスさせる。

管理装置６０は、通信の開始を待機している端末１０のキュー（待ち行列）を管理する。管理装置６０は、キューに基づいて端末１０間の接続を管理する。制御装置５０は、端末１０間でコンテンツデータを送信するためのセッションを確立するための制御を行う。各端末１０は、同じセッションに参加している他の端末１０へコンテンツデータを送信する。なお、一実施形態において、セッションは、中継装置３０が、複数の端末１０間で画像データ、及び音データを含むコンテンツデータを中継することで実現される。

本実施形態では、コミュニケーションシステムの一例としてのビデオ会議システム、コミュニケーション管理システムの一例としてのビデオ会議管理システム、及びコミュニケーション端末の一例としてのビデオ会議端末を想定し、通信システム１、管理システム５、及び端末１０について説明する。即ち、端末１０及び管理システム５は、ビデオ会議システムに適用されるだけでなく、他のコミュニケーションシステムにも適用される。例えば、通信システム１は電話システムであり、端末１０は、ＩＰ(Internet Protocol)電話機、インターネット電話機、ＰＣ(Personal Computer)、ノートＰＣ（Personal Computer）、スマートフォンやタブレット端末等のモバイル端末等であってもよい。

なお、実施形態において、「ビデオ会議」は、「テレビ会議」と置き換え可能に用いられる。更に、以下、ビデオ会議端末（下位概念）等の端末（中位概念）によって、通話を行うことに関して説明するが、これに限るものではなく、通話を含めたより広い概念として通信を行うことができればよい。

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

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

ディスプレイ１２０は、被写体の画像や操作用等を表示する液晶や有機ＥＬ(Organic Electroluminescence)によって構成された表示部である。また、ディスプレイ１２０は、ケーブル１２０ｃによってディスプレイＩ／Ｆ１１７に接続される。このケーブル１２０ｃは、アナログＲＧＢ（ＶＧＡ）信号用のケーブルであってもよいし、コンポーネントビデオ用のケーブルであってもよいし、ＨＤＭＩ（登録商標）(High-Definition Multimedia Interface)やＤＶＩ(Digital Video Interactive)信号用のケーブルであってもよい。

カメラ１１２は、レンズや、光を電荷に変換して被写体の画像（映像）を電子化する固体撮像素子を含み、固体撮像素子として、ＣＭＯＳ(Complementary Metal Oxide Semiconductor)や、ＣＣＤ（Charge Coupled Device）等が用いられる。

外部機器接続Ｉ／Ｆ１１８には、筐体１１００の接続口１１３２に差し込まれたＵＳＢ(Universal Serial Bus)ケーブル等によって、外付けカメラ、外付けマイク、及び外付けスピーカ等の外部機器がそれぞれ電気的に接続可能である。外付けカメラが接続された場合には、ＣＰＵ１０１の制御に従って、内蔵型のカメラ１１２に優先して、外付けカメラが駆動する。同じく、外付けマイクが接続された場合や、外付けスピーカが接続された場合には、ＣＰＵ１０１の制御に従って、それぞれが内蔵型のマイク１１４や内蔵型のスピーカ１１５に優先して、外付けマイクや外付けスピーカが駆動する。

なお、記録メディア１０６は、端末１０に対して着脱自在な構成となっている。また、ＣＰＵ１０１の制御にしたがってデータの読み出し又は書き込みを行う不揮発性メモリであれば、フラッシュメモリ１０４に限らず、ＥＥＰＲＯＭ（Electrically Erasable and Programmable ROM）等を用いてもよい。

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

中継装置３０、管理装置６０、及びストレージサービス７０は、制御装置５０と同様のハードウェア構成を有しているため、その説明を省略する。

なお、端末１０、中継装置３０、制御装置５０、管理装置６０、及びストレージサービス７０用の各プログラムは、インストール可能な形式又は実行可能な形式のファイルによって、コンピュータで読み取り可能な記録メディアに記録されて流通されるようにしてもよい。また、上記記録メディアの例として、ＣＤ−Ｒ(Compact Disc Recordable)、ＤＶＤ(Digital Versatile Disk)、ブルーレイディスク等が挙げられる。また、各プログラムが記憶されたＣＤ−ＲＯＭ等の記録メディア、並びに、これらプログラムが記憶されたＨＤ５０４は、プログラム製品(Program Product)として、国内又は国外へ提供されることができる。

＜実施形態の機能構成＞
次に、図２、図３及び図４を用いて、本実施形態の機能構成について説明する。図４は、一実施形態に係る通信システムの機能ブロック図である。以下、「アプリケーション」を「アプリ」と略して説明する。

＜端末の機能構成＞
端末１０は、送受信部１１、受付部１２、通信制御部１３、表示制御部１７、及び記憶・読出部１９を有している。これら各部は、図２に示されている各構成要素のいずれかが、フラッシュメモリ１０４からＲＡＭ１０３上に展開された端末用プログラムに従ったＣＰＵ１０１からの命令によって動作することで実現される機能、又は機能する手段である。端末（１０ａａ，１０ｂｂ，１０ｅｅ）には、端末用プログラムとして、オペレータサービスにおけるゲスト側へ提供されるサービスを実現するためのアプリケーションであるゲストアプリがインストールされている。端末（１０ｃｃ，１０ｄｄ，１０ｆｆ）には、端末用プログラムとして、オペレータサービスにおけるオペレータ側へのサービスを実現するためのアプリケーションであるオペレータアプリがインストールされている。即ち、端末１０（１０ａａ，１０ｂｂ，１０ｅｅ）の機能はＣＰＵ１０１がゲストアプリを実行することによって実現され、端末１０（１０ｃｃ，１０ｄｄ，１０ｆｆ）の機能はＣＰＵ１０１がオペレータアプリを実行することによって実現される。

また、端末１０は、ＲＡＭ１０３、及びフラッシュメモリ１０４によって構築される記憶部１０００を有している。更に、端末１０には、記録メディア１０６によって構築される記録媒体１０１０が挿入されており、記憶・読出部１９によって各種データの読み出し又は書き込みが行なわれる。

（端末の各機能構成）
次に、端末１０の各機能構成について詳細に説明する。なお、以下では、端末１０の各機能構成を説明するにあたって、図２に示されている各構成要素のうち、端末１０の各機能構成を実現させるための主な構成要素との関係も説明する。

送受信部１１は、ＣＰＵ１０１からの命令、及びネットワークＩ／Ｆ１１１によって実現され、通信ネットワーク２を介して他の端末、装置又はシステムと各種データ（または情報）の送受信を行う。

受付部１２は、ＣＰＵ１０１からの命令によって実現され、利用者による操作ボタン１０８の操作又は利用者による電源スイッチ１０９の押等の各種入力を受け付ける。

通信制御部１３は、ＣＰＵ１０１からの命令、並びにカメラ１１２及び撮像素子Ｉ／Ｆ１１３によって実現され、被写体を撮像して、この撮像によって得た画像データを出力する。また、通信制御部１３は、ＣＰＵ１０１からの命令、及び音声入出力Ｉ／Ｆ１１６によって実現され、マイク１１４によって利用者の音声が音声信号に変換された後、この音声信号に係る音データを入力する。更に、通信制御部１３は、ＣＰＵ１０１からの命令、及び音声入出力Ｉ／Ｆ１１６によって実現され、音データに係る音声信号をスピーカに出力し、スピーカ１１５から音声を出力させる。

表示制御部１７は、ＣＰＵ１０１からの命令、及びディスプレイＩ／Ｆ１１７によって実現され、受信された画像データをディスプレイ１２０に送信するための制御を行う。

記憶・読出部１９は、ＣＰＵ１０１からの命令及びＳＳＤ１０５によって実行され、又はＣＰＵ１０１からの命令によって実現され、記憶部１０００又は記録媒体１０１０に各種データを記憶したり、記憶部１０００又は記録媒体１０１０に記憶された各種データを読み出したりする処理を行う。記憶部１０００には、端末１０を識別するための端末ＩＤ(Identification）、及びパスワード等が記憶される。なお、端末ＩＤとパスワードの少なくとも一方は、記録媒体１０１０に記録されており、記憶・読出部１９によって読み出されるようにしてもよい。この場合の記録媒体１０１０は、ＳＩＭカード(Subscriber Identity Module Card)等のＩＣカード(Integrated circuit card)である。そして、端末１０の利用者は、記録媒体１０１０を購入することで、管理システム５の管理者から通信サービスの提供を受けることができる。

更に、記憶部１０００には、宛先端末との通話を行う際に受信される画像データ及び音データが、受信される度に上書き記憶される。このうち、上書きされる前の画像データによってディスプレイ１２０に画像が表示され、上書きされる前の音データによってスピーカ１１５から音声が出力される。

なお、本実施形態の端末ＩＤは、端末１０を一意に識別するために使われる言語、文字、記号、又は各種のしるし等の識別情報の一例を示す。また、端末ＩＤは、上記言語、文字、記号、及び各種のしるしのうち、少なくとも２つが組み合わされた識別情報であってもよい。また、端末ＩＤに代えて、端末１０の利用者を識別するための利用者ＩＤを利用してもよい。この場合、端末識別情報には、端末ＩＤだけでなく、利用者ＩＤも含まれる。

＜制御装置の機能構成＞
制御装置５０は、送受信部５１、セッション制御部５８、及び記憶・読出部５９を有している。これら各部は、図３に示されている各構成要素のいずれかが、ＨＤ５０４からＲＡＭ５０３上に展開された制御装置５０用のプログラムに従ったＣＰＵ５０１からの命令によって動作することで実現される機能又は手段である。また、制御装置５０は、ＨＤ５０４により構築される記憶部５０００を有している。

（制御装置の各機能構成）
次に、制御装置５０の各機能構成について詳細に説明する。なお、以下では、制御装置５０の各機能構成を説明するにあたって、図３に示されている各構成要素のうち、制御装置５０の各機能構成を実現させるための主な構成要素との関係も説明する。

送受信部５１は、ＣＰＵ５０１からの命令、及びネットワークＩ／Ｆ５０９によって実現され、通信ネットワーク２を介して各端末、装置又はシステムと各種データ（または情報）の送受信を行う。

セッション制御部５８は、ＣＰＵ５０１からの命令によって実現され、端末１０間でコンテンツデータを送信するセッションを制御する。上記の制御としては、セッションを確立するための制御、確立されたセッションに端末１０を参加させる制御、セッションを切断する制御等が含まれる。

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

＜管理装置の機能構成＞
管理装置６０は、送受信部６１、管理部６３、及び記憶・読出部６９を有している。これら各部は、図３に示されている各構成要素のいずれかが、ＨＤ５０４からＲＡＭ５０３上に展開された管理装置用のプログラムに従ったＣＰＵ５０１からの命令によって動作することで実現される機能又は手段である。また、管理装置６０は、ＨＤ５０４により構築される記憶部６０００を有している。この記憶部６０００には、各テーブルによって構成されている各ＤＢが構築されている。

（待機端末管理テーブル）
記憶部６０００には、待機端末管理テーブルによって構成される待機端末管理ＤＢ６００１が構築される。図５は、待機端末管理テーブルを示す概念図である。なお、図５（Ａ）乃至（Ｇ）は、一つの待機端末管理テーブルに記録される情報の遷移を示したものである。

待機端末管理テーブルにおけるゲストアプリのフィールドには、通信の開始を待機している端末１０のうちゲストアプリを起動している端末１０の端末ＩＤが記録される。待機端末管理テーブルにおけるオペレータアプリのフィールドには、通信の開始を待機している端末１０のうちオペレータアプリを起動している端末１０の端末ＩＤが記録される。待機端末管理テーブルの各フィールドは、通信の開始を待機する端末１０の待ち行列（キュー）を構成する。一実施形態において、各フィールドへの端末ＩＤの入出力は、原則として、先入れ先出し方式により行われる。すなわち、各フィールドに端末ＩＤを追加（エンキュー）するときには、そのフィールドにおける末尾のレコードに追加され、各フィールドから端末ＩＤを取り出す（デキューする）ときには、そのフィールドにおける先頭のレコードから取り出される。デキューされてから残っているレコードは先頭方向に繰り上げられる。

具体的には、待機端末管理テーブルのオペレータアプリのフィールドに追加された端末ＩＤ「０１ｃｃ」は、後から追加された端末ＩＤ「０１ｅｅ」よりも先に取り出される（図５（Ｅ）乃至（Ｆ）参照）。

例えば、待機端末管理テーブルが空（Empty）の状態であるときに、端末１０ｃｃから「応答可能」な状態を示す状態情報が送られてくると、オペレータアプリのフィールドに端末１０ｃｃの端末ＩＤ「０１ｃｃ」が追加される（図５（Ａ）参照）。

続いて、端末１０ｄｄから「応答可能」な状態を示す状態情報が送られてくると、オペレータアプリのフィールドにおける末尾のレコードに端末１０ｄｄの端末ＩＤ「０１ｄｄ」が追加される（図５（Ｂ）参照）。

続いて、端末１０ｅｅから「応答可能」な状態を示す状態情報が送られてくると、オペレータアプリのフィールドにおける末尾のレコードに端末１０ｅｅの端末ＩＤ「０１ｅｅ」が追加される（図５（Ｃ）参照）。

続いて、端末ＩＤ「０１ｄｄ」に関連付けられた端末１０ｄｄについて、待機端末管理テーブルのオペレータアプリのフィールドで管理する時間以外の時間となったことによって、待機端末管理テーブルのオペレータアプリのフィールドから端末１０ｄｄの端末ＩＤ「０１ｄｄ」が取り出される（デキューされる）ことによって削除される（図５（Ｄ）参照）。

続いて、待機端末管理テーブルのオペレータアプリのフィールドから端末１０ｄｄの端末ＩＤ「０１ｄｄ」が取り出された（デキューされた）結果、残っているレコードは先頭方向に繰り上げられる（図５（Ｅ）参照）。

続いて、任意の端末１０から通信の開始要求が送られてくると、オペレータアプリのフィールドの先頭のレコードから端末１０ｃｃの端末ＩＤ「０１ｃｃ」が取り出される（図５（Ｆ）参照）。

続いて、任意の端末１０から通信の開始要求が送られてくると、オペレータアプリのフィールドの先頭のレコードから端末１０ｅｅの端末ＩＤ「０１ｅｅ」が取り出される（図５（Ｇ）参照）。これにより、待機端末管理テーブルは再び空の状態になる。このとき、オペレータ側においてもゲスト側においても通信の開始を待機している端末１０がなくなる。
先入れ先出しに限らず、各フィールドに端末ＩＤを追加（エンキュー）するときには、そのフィールドにおいてランダムな順番に追加し、各フィールドから端末ＩＤを取り出す（デキューする）ときには、そのフィールドにおいてランダムに取り出すようにしてもよい。

なお、待機端末管理テーブルに入力される端末ＩＤは、通信先の端末１０を識別可能な識別情報であれば良い。従って、通信先の端末１０を識別可能なものであれば、端末ＩＤは、端末１０の識別情報に限られない。例えば、管理装置６０において各端末１０の識別情報とその端末１０のユーザのユーザＩＤを関連付けて管理している場合には、通信先の端末１０を識別可能な端末ＩＤとしてユーザＩＤを用いることもできる。また、管理装置６０において各端末１０の識別情報とその端末１０において起動しているアプリのアカウントを関連付けて管理している場合には、通信先の端末１０を識別可能な端末ＩＤとしてアカウントを用いることもできる。

（スケジュール管理テーブル）
記憶部６０００には、スケジュール管理テーブルによって構成されるスケジュール管理ＤＢ６００２が構築される。図６は、スケジュール管理テーブルを示す概念図である。スケジュール管理テーブルにおけるオペレータアプリのフィールドには、通信の開始を待機している端末１０のうちオペレータアプリを起動している端末１０の端末ＩＤが記録される。スケジュール管理テーブルにおけるスケジュール情報のフィールドには、オペレータアプリのフィールドに記録された端末ＩＤに関連付けられた端末１０について、待機端末管理テーブルのオペレータアプリのフィールドで管理する時間を示す。図６には、図５（ｃ）の時点におけるスケジュール管理テーブルが示され、オペレータアプリのフィールドに、端末１０ｃｃの端末ＩＤ「０１ｃｃ」、端末１０ｄｄの端末ＩＤ「０１ｄｄ」、および端末１０ｅｅの端末ＩＤ「０１ｅｅ」について、管理する時間としてそれぞれ「９：００−１３：００」、「１９：００−２４：００」、および「１０：００−１４：００」が示される。

（管理装置の各機能構成）
送受信部６１は、ＣＰＵ５０１からの命令、及びネットワークＩ／Ｆ５０９によって実現され、通信ネットワーク２を介して他の端末、装置又はシステムと各種データ（または情報）の送受信を行う。

管理部６３は、ＣＰＵ５０１からの命令によって実現され、待機端末管理テーブルにおいて、維持したり、識別情報を追加したりあるいは削除したりすることにより、待機端末管理テーブルを管理する。さらに、管理部６３は、スケジュール管理テーブルにおいて維持したり、識別情報を追加したりあるいは削除したりすることにより、スケジュール管理テーブルを管理する。

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

＜＜実施形態の処理または動作＞＞
続いて、通信システム１を構成する端末１０、中継装置３０、制御装置５０、管理装置６０、及びストレージサービス７０の処理または動作について詳細に説明する。

（状態情報の送信）
まず、図７を用いて、オペレータ側の端末（１０ｃｃ又は１０ｄｄ又は１０ｆｆ）が、通信の開始要求に対して応答可能な状態を示す状態情報を管理装置６０へ送信する処理について説明する。図７は、端末１０が状態情報を送信する処理を示したシーケンス図である。

端末（１０ｃｃ又は１０ｄｄ又は１０ｆｆ）の受付部１２は、利用者（オペレータ）による操作入力に基づいてオペレータアプリの起動要求を受け付けると、オペレータアプリを起動する（ステップＳ１）。以後、端末（１０ｃｃ又は１０ｄｄ又は１０ｆｆ）における各処理は、オペレータアプリによって実現される。

オペレータアプリが起動すると、送受信部１１は、管理装置６０へログイン要求を送信する（ステップＳ２）。このログイン要求には、ログイン要求元の端末（１０ｃｃ又は１０ｄｄ又は１０ｆｆ）の端末ＩＤ、端末（１０ｃｃ又は１０ｄｄ又は１０ｆｆ）において起動しているオペレータアプリのアプリＩＤ、及び認証用の情報等が含まれていても良い。認証用の情報には、端末ＩＤに対応するパスワード、アプリのアカウント、このアカウントに対応するパスワード等が含まれていても良い。これに応じて、管理装置６０が端末（１０ｃｃ又は１０ｄｄ又は１０ｆｆ）の認証に成功すると、端末（１０ｃｃ又は１０ｄｄ又は１０ｆｆ）は、管理装置６０と接続する。同様に、送受信部１１は、制御装置５０へログイン要求を送信する（ステップＳ３）。これに応じて、制御装置５０が端末（１０ｃｃ又は１０ｄｄ又は１０ｆｆ）の認証に成功すると、端末（１０ｃｃ又は１０ｄｄ又は１０ｆｆ）は、制御装置５０と接続する。上記のログイン処理を行うことで、端末１０側が情報送信の度に、端末ＩＤ、アプリＩＤ等を付さなくても、送信先の管理装置６０又は制御装置５０は、送信元の端末１０、或いは端末１０で起動しているアプリを特定できるようになる。なお、端末１０及び管理装置６０間の接続、或いは端末１０及び制御装置５０間の接続として、例えば、リアルタイム接続が用いられる。

続いて、端末（１０ｃｃ又は１０ｄｄ又は１０ｆｆ）の利用者は、ゲスト側との通話を開始できる状態となると、操作ボタン１０８を操作して待ち受けを開始する旨の情報、および「応答可能」である時間を示す情報であるスケジュール情報を入力する。これにより、受付部１２は、待受開始、およびスケジュール情報を受け付ける（ステップＳ４）。続いて、送受信部１１は、通信の開始要求に対して「応答可能」である状態を示す状態情報、および「応答可能」である時間を示す情報であるスケジュール情報を管理装置６０へ送信する（ステップＳ５）。これによって、「応答可能」であること、応答可能である時間が管理装置６０へ送信される。

端末（１０ｃｃ又は１０ｄｄ又は１０ｆｆ）は、待受開始を受け付けたとき以外でも、応答可能な状態になる度に状態情報、およびスケジュール情報を管理装置６０へ送信する。例えば、受付部１２が終話を受け付ける（ステップＳ６）と、端末（１０ｃｃ又は１０ｄｄ又は１０ｆｆ）の利用者は新たな通話を開始できるようになるため、送受信部１１は、自動的に通信の開始要求に対して「応答可能」である状態を示す状態情報、およびスケジュール情報を管理装置へ送信する（ステップＳ７）。

一方、端末（１０ｃｃ又は１０ｄｄ又は１０ｆｆ）の利用者は、一時的に席を離れる場合など、ゲスト側との通話を開始できない状態となると、操作ボタン１０８を操作して応答できない旨の情報を入力する。これにより、受付部１２は、応答できない旨を受け付ける（ステップＳ８）。この場合、送受信部１１は、通信の開始要求に対して「応答不可能」である状態を示す状態情報を管理装置６０へ送信する（ステップＳ９）。

端末（１０ｃｃ又は１０ｄｄ又は１０ｆｆ）から管理装置６０へスケジュール情報を送信するタイミングは、状態情報を送信するタイミングと同時である必要はなく、任意のタイミングで送信するようにしてもよい。

続いて、図８を用いて、ゲスト側の端末（１０ａａ又は１０ｂｂ又は１０ｅｅ）が、通信の開始要求を管理装置６０へ送信する処理について説明する。図８は、端末１０が通信の開始要求を送信する処理を示したシーケンス図である。

端末（１０ａａ又は１０ｂｂ又は１０ｅｅ）の受付部１２は、利用者（ゲスト）による操作入力に基づいてゲストアプリの起動要求を受け付けると、ゲストアプリを起動する（ステップＳ２１）。以後、端末（１０ａａ又は１０ｂｂ又は１０ｅｅ）における各処理はゲストアプリによって実現される。

ゲストアプリが起動すると、送受信部１１は、ストレージサービス７０へアクセスして通信の開始要求受付画面を要求する（ステップＳ２２）。これに応じて、ストレージサービス７０は、要求元の端末（１０ａａ又は１０ｂｂ又は１０ｅｅ）へ、通信の開始要求受付画面を公開する（ステップＳ２３）。端末（１０ａａ又は１０ｂｂ又は１０ｅｅ）では、表示制御部１７が通信の開始要求受付画面をディスプレイ１２０へ出力する制御を行う。

また、端末（１０ａａ又は１０ｂｂ又は１０ｅｅ）の送受信部１１は、ステップＳ２と同様にして、管理装置６０へログイン要求を送信する（ステップＳ２４）。但し、ログイン要求に含まれるアプリＩＤは、ゲストアプリのアプリＩＤである。ログイン要求に応じて、管理装置６０が端末（１０ａａ又は１０ｂｂ又は１０ｅｅ）の認証に成功すると、端末（１０ａａ又は１０ｂｂ又は１０ｅｅ）は、管理装置６０と接続する。続いて、送受信部１１は、ステップＳ３と同様にして、制御装置５０へログイン要求を送信する（ステップＳ２５）。ログイン要求に応じて、制御装置５０が端末（１０ａａ又は１０ｂｂ又は１０ｅｅ）の認証に成功すると、端末（１０ａａ又は１０ｂｂ又は１０ｅｅ）は、制御装置５０と接続する。

続いて、端末（１０ａａ又は１０ｂｂ又は１０ｅｅ）の利用者は、オペレータ側との通話を要求するときに、操作ボタン１０８を操作して開始要求受付画面から開始要求を入力する。これにより、受付部１２は、開始要求の入力を受け付ける（ステップＳ２６）。続いて、送受信部１１は、通信の開始要求を示す情報を管理装置６０へ送信する（ステップＳ２７）。

一方、端末（１０ａａ又は１０ｂｂ又は１０ｅｅ）の利用者は、開始要求後に開始要求をキャンセルする場合、操作ボタン１０８を操作して、開始要求受付画面からキャンセルする旨の情報を入力する。これにより、受付部１２は、キャンセルの入力を受け付ける（ステップＳ２８）。この場合、送受信部１１は、開始要求のキャンセルを示す情報を管理装置６０へ送信する（ステップＳ２９）。

（キュー管理）
続いて、図９を用いて、管理装置６０が、通信の開始を待機する端末１０のキューを管理する処理について説明する。図９は、通信の開始を待機する端末１０のキューを管理する処理を示したフロー図である。

管理装置６０の送受信部６１が端末１０から送られてきた状態情報又は開始要求を受信すると、管理部６３は、端末１０から送られてきた情報がオペレータアプリによって送信される「応答可能」な状態を示す状態情報であるか否かを判断する（ステップＳ４１）。

送られてきた情報が、「応答可能」な状態を示す状態情報である（ＹＥＳ）と判断された場合、管理部６３は、待機端末管理テーブルを参照して、ゲストアプリのフィールドが空（Empty）であるか否かを判断する（ステップＳ４２）。

ゲストアプリのフィールドが空である（ＹＥＳ）と判断された場合、管理部６３は、待機端末管理テーブルのオペレータアプリのフィールドにおける末尾のレコードに、「応答可能」な状態を示す状態情報の送信元の端末１０の端末ＩＤを追加（エンキュー）する（ステップＳ４３）。

ゲストアプリのフィールドが空ではない（ＮＯ）と判断された場合、管理部６３は、待機端末管理テーブルのゲストアプリのフィールドにおける先頭のレコードから、端末ＩＤを取り出す（デキューする）（ステップＳ４４）。

ステップＳ４１において端末１０から送られてきた情報が、「応答可能」な状態を示す状態情報ではない（ＮＯ）と判断された場合、管理部６３は、送られてきた情報が、ゲストアプリによって送信された通信の開始要求であるか否かを判断する（ステップＳ４５）。

送られてきた情報が通信の開始要求である（ＹＥＳ）と判断された場合、管理部６３は、待機端末管理テーブルを参照して、オペレータアプリのフィールドが空（Empty）であるか否かを判断する（ステップＳ４６）。

オペレータアプリのフィールドが空である（ＹＥＳ）と判断された場合、管理部６３は、待機端末管理テーブルのゲストアプリのフィールドにおける末尾のレコードに、通信の開始要求の送信元の端末１０の端末ＩＤを追加（エンキュー）する（ステップＳ４７）。

オペレータアプリのフィールドが空ではない（ＮＯ）と判断された場合、管理部６３は、待機端末管理テーブルのオペレータアプリのフィールドにおける先頭のレコードから、端末ＩＤを取り出す（デキューする）（ステップＳ４８）。

端末１０から送られてきた情報が通信の開始要求ではない（ＮＯ）と判断された場合、すなわち、送られてきた情報が「応答不可能」な状態を示す状態情報、あるいは開始要求のキャンセルを示す情報である場合、先入れ先出し処理の例外として、管理部６３は、待機端末管理テーブルから情報の送信元の端末１０の端末ＩＤを削除する（ステップＳ４９）。

例えば、端末１０から送られてきた情報が「応答不可能」な状態を示す状態情報である場合には、管理部６３は、待機端末管理テーブルのオペレータアプリのフィールドから、送信元の端末１０の端末ＩＤを削除する。端末１０から送られてきた情報が開始要求のキャンセルを示す情報である場合には、管理部６３は、待機端末管理テーブルのゲストアプリのフィールドから、送信元の端末１０の端末ＩＤを削除する。

このようにして、待機端末管理テーブルにおいて管理される端末ＩＤは、端末１０から送られてきた情報に基づいて更新される。

（スケジュール管理）
続いて、図１０を用いて、管理装置６０が、オペレータアプリのフィールドに記録されている端末１０のキューを管理する処理について説明する。図１０は、通信の開始を待機する端末１０のキューを管理する処理を示したフロー図である。

管理装置６０の管理部６３は、オペレータアプリの先頭レコードが空であるか否かを判断する。つまり、オペレータアプリのフィールドに記録されている端末ＩＤがあるか否かを判断する（ステップＳ５１）。

オペレータアプリのフィールドのフィールドが空である（ＹＥＳ）と判断された場合、所定の時間待機する（ステップＳ５２）。

オペレータアプリのフィールドのフィールドが空でない（ＮＯ）と判断された場合、管理部６３は、当該オペレータアプリのレコードに管理されている端末ＩＤのスケジューリング情報を参照する（ステップＳ５３）。

管理装置６０の管理部６３は、現在の時刻は、管理する時間の範囲内であるか否かを判断する（ステップＳ５４）。

現在の時刻が管理する時間の範囲内でない（ＮＯ）と判断された場合、管理部６３は、当該レコードに管理されている端末ＩＤを削除する（ステップＳ５５）。

現在の時刻が管理する時間の範囲内である（ＹＥＳ）と判断された場合、管理部６３は、当該レコードに管理されている端末ＩＤは維持し、当該レコードの次のレコードは空であるか否かを判断する（ステップＳ５６）。

当該レコードの次のレコードは空でない（ＮＯ）と判断された場合、ステップＳ５３に戻る。

当該レコードの次のレコードは空である（ＹＥＳ）と判断された場合、管理部６３は、オペレータアプリに残っている端末ＩＤを先頭方向に繰り上げることによって先頭から連続するように移動させ、ステップＳ５１に戻る。

例えば、待機端末管理テーブルが空（Empty）の状態であるときに、端末１０ｃｃから「応答可能」な状態を示す状態情報が送られてくると、ステップＳ４３の処理により、オペレータアプリのフィールドに端末１０ｃｃの端末ＩＤ「０１ｃｃ」が追加される（図５（Ａ）参照）。

続いて、端末１０ｄｄから「応答可能」な状態を示す状態情報が送られてくると、ステップＳ４３の処理により、オペレータアプリのフィールドにおける末尾のレコードに端末１０ｄｄの端末ＩＤ「０１ｄｄ」が追加される（図５（Ｂ）参照）。

続いて、端末１０ｅｅから「応答可能」な状態を示す状態情報が送られてくると、ステップＳ４３の処理により、オペレータアプリのフィールドにおける末尾のレコードに端末１０ｅｅの端末ＩＤ「０１ｅｅ」が追加される（図５（Ｃ）参照）。

続いて、端末ＩＤ「０１ｄｄ」に関連付けられた端末１０ｄｄについて、待機端末管理テーブルのオペレータアプリのフィールドに管理する時間以外の時間となったことによって、ステップＳ５５の処理により、待機端末管理テーブルのオペレータアプリのフィールドから端末１０ｄｄの端末ＩＤ「０１ｄｄ」が取り出される（デキューされる）（図５（Ｄ）参照）。

続いて、待機端末管理テーブルのオペレータアプリのフィールドから端末１０ｄｄの端末ＩＤ「０１ｄｄ」が取り出された（デキューされた）結果、ステップＳ５７の処理により、残っているレコードは先頭方向に繰り上げられる（図５（Ｅ）参照）。

続いて、任意の端末１０から通信の開始要求が送られてくると、ステップＳ４８の処理により、オペレータアプリのフィールドの先頭のレコードから端末１０ｃｃの端末ＩＤ「０１ｃｃ」が取り出される（図５（Ｆ）参照）。

続いて、任意の端末１０から通信の開始要求が送られてくると、ステップＳ４８の処理により、オペレータアプリのフィールドの先頭のレコードから端末１０ｅｅの端末ＩＤ「０１ｅｅ」が取り出される（図５（Ｇ）参照）。これにより、待機端末管理テーブルは再び空の状態になる。このとき、オペレータ側においてもゲスト側においても通信の開始を待機している端末１０がなくなる。

（セッション確立）
続いて、図１１を用いて、制御装置５０による制御に基づいて端末１０間のセッションを確立する処理について説明する。図１１は、セッションを確立する処理を示したシーケンス図である。

ステップ（Ｓ４４，Ｓ４８）において、待機端末管理テーブルから端末ＩＤが取り出される（デキューされる）と、管理システム５は、デキューされた端末１０が通信を開始するよう制御する。この制御として、一実施形態に係る管理装置６０の送受信部６１は、開始要求を発信させるため、宛先の端末１０の端末ＩＤをゲスト側の端末１０へ送信する（ステップＳ６１）。例えば、「応答可能」な状態を示す状態情報の受信を契機として、ゲストアプリのフィールドの端末ＩＤがデキューされた場合には（ステップＳ４４参照）、送受信部６１は、その「応答可能」な状態を示す状態情報を送信したオペレータ側の端末１０の端末ＩＤを、デキューされた端末ＩＤによって識別されるゲスト側の端末１０へ送信する。一方、開始要求の受信を契機として、オペレータアプリのフィールドの端末ＩＤがデキューされた場合には（ステップＳ４８参照）、送受信部６１は、デキューされたオペレータ側の端末１０の端末ＩＤを、開始要求を送信した開始要求元のゲスト側の端末１０へ送信する。

ゲスト側の端末１０の送受信部１１は、管理装置６０から送られてきた端末ＩＤを受信すると、自動的に、宛先を示す情報として受信した端末ＩＤを含む通信の開始要求を制御装置５０へ送信する（ステップＳ６２）。制御装置５０は、公知の呼制御方法により、開始要求元の端末１０と宛先の端末１０との間でコンテンツデータを送信するためのセッションを確立するための制御を行う。この場合、例えば、制御装置５０の送受信部５１は、ゲスト側の端末１０から送られてきた開始要求を、開始要求に含まれている端末ＩＤによって識別される宛先のオペレータ側の端末１０へ送信する（ステップＳ６３）。オペレータ側の端末１０の送受信部１１は、制御装置５０から送られてきた通信の開始要求を受信すると、自動的に、通信の開始を許可する旨の応答を制御装置５０へ送信する（ステップＳ６４）。

制御装置５０の送受信部５１が通信の開始を許可する旨の応答を受信すると、セッション制御部５８は、送受信部１１に、宛先の端末１０から送られてきた応答、及び、中継装置３０へ接続するための中継装置接続情報を開始要求元のゲスト側の端末１０へ送信させる（ステップＳ６５）。更に、セッション制御部５８は、送受信部１１に、中継装置３０へ接続するための中継装置接続情報を宛先のオペレータ側の端末１０へ送信させる（ステップＳ６６）。なお、上記の中継装置接続情報は、中継装置３０のＩＰアドレス、認証情報、ポート番号等を含んでいても良い。

ゲスト側の端末１０及びオペレータ側の端末１０の送受信部１１は、管理装置６０から送られてきた中継装置接続情報を中継装置３０へ送信する（ステップＳ６７，Ｓ６８）。これにより、ゲスト側の端末１０及びオペレータ側の端末１０がそれぞれ中継装置３０と接続することで、ゲスト側の端末１０とオペレータ側の端末１０との間のセッションが確立される。セッションが確立されてから、ゲスト側の端末１０及びオペレータ側の端末１０は、自端末１０において生成された画像データ及び音データを中継装置３０へ送信する。中継装置３０は、一方の端末１０から送られてきた画像データ及び音データを他方の端末１０へ送信する。これにより、ゲスト側の端末１０とオペレータ側の端末１０との間で相互に画像データ及び音データが送信されることになる。

上述した実施形態では、オペレータアプリのフィールドで、管理する時間に基づいて、通信端末を管理する場合について説明したが、曜日、日、月などに基づいて管理するようにしてもよい。

本実施形態に係る通信システムによれば、ゲスト側及びオペレータ側に対応するキューを設け、オペレータ側に対応するキューで管理される端末を、該端末に関連づけて記憶された管理する時間に基づいて管理する。これによって、オペレータ側に対応するキューで管理される各々の端末によって接続要求に対応可能な時間帯（や曜日）が異なる場合、各々の端末の対応可能な時間帯に合わせて端末間の接続を適切に管理することができる。

＜＜実施形態の補足＞＞
上記実施形態では、管理装置６０が、制御装置５０とは異なる装置である場合について
説明したが、本発明はこのような実施形態に限定されない。例えば、制御装置５０は、上
記の管理装置６０の各機能部を備えていても良い。

上記実施形態では、ゲスト側に分類される端末（１０ａａ，１０ｂｂ，１０ｅｅ）には、ゲストアプリがインストールされており、オペレータ側に分類される端末（１０ｃｃ，１０ｄｄ，１０ｆｆ）には、オペレータアプリがインストールされている例について説明したが、本発明はこのような実施形態に限定されない。例えば、端末（１０ａａ，１０ｂｂ，１０ｃｃ，１０ｄｄ，１０ｅｅ，１０ｆｆ）には、オペレータサービス用の同一のアプリがインストールされていても良い。この場合、端末１０にインストールされたアプリは、利用者による役割の選択、あるいは、着脱可能な記録媒体１０１０に記録された役割を示す情報等に基づいて、上記実施形態におけるゲストアプリによる機能又はオペレータアプリによる機能を選択的に実現する。

上述した実施形態において、管理システムは情報処理システムの一例であり、ゲストアプリは第１のグループの一例であり、通訳アプリは第２のグループの一例であり、管理部は第１の管理手段、第２の管理手段、更新手段の一例である。また、セッション制御部はセッション制御手段の一例であり、送受信部６１は開始要求受付手段、受信手段の一例であり、管理装置は情報処理装置の一例であり、制御装置５０用のプログラムは情報処理プログラムの一例である。

本発明は特定の実施例、変形例を参照しながら説明されてきたが、各実施例、変形例は単なる例示に過ぎず、当業者は様々な変形例、修正例、代替例、置換例等を理解するであろう。説明の便宜上、本発明の実施例に従った装置は機能的なブロック図を用いて説明されたが、そのような装置はハードウェアで、ソフトウエアでまたはそれらの組み合わせで実現されてもよい。本発明は上記実施例に限定されず、本発明の精神から逸脱することなく、様々な変形例、修正例、代替例、置換例等が包含される。

１ 通信システム
２ 通信ネットワーク
５ 管理システム
１０ 端末
１１ 送受信部
１２ 受付部
１３ 通信制御部
１７ 表示制御部
１９ 記憶・読出部
３０ 中継装置
５０ 制御装置
５１ 送受信部
５８ セッション制御部
５９ 記憶・読出部
６０ 管理装置
６１ 送受信部
６３ 管理部
６９ 記憶・読出部
７０ ストレージサービス
１０００ 記憶部
５０００ 記憶部
６０００ 記憶部
６００１ 待機端末管理ＤＢ
６００２ スケジュール管理ＤＢ

特開２００５−０６４８６０号公報

Claims (7)

1. 第１のグループに分類される複数の通信端末の識別情報を管理する第１の管理手段と、
   第２のグループに分類される複数の通信端末の識別情報を管理する第２の管理手段と、
   前記第１の管理手段又は前記第２の管理手段において管理される識別情報を更新する情報更新手段と、
   前記第２のグループに分類される複数の通信端末の識別情報の各々と、前記第２の管理手段において通信端末の識別情報を管理する時間を示す情報とを関連付けて記憶するスケジュール管理ＤＢと
   を有し、
   前記情報更新手段は、
   前記第２のグループに分類される通信端末が、通信の開始の要求を行った通信端末に対して応答可能な状態となったときに、前記第１の管理手段において識別情報が管理されていない場合には、前記第２の管理手段において、該応答可能な状態となった通信端末の識別情報を追加し、
   前記スケジュール管理ＤＢに記憶される通信端末の識別情報を管理する時間に基づいて、第２の管理手段において管理される識別情報を維持又は削除する
   ことを特徴とする情報処理システム。
2. 前記情報更新手段は、
   前記第１のグループに分類される通信端末が通信の開始を要求するときに、
   前記第２の管理手段において一以上の識別情報が管理されている場合には、該一以上の識別情報のいずれかの識別情報を該通信の開始の要求に対して応答する通信端末の識別情報として特定した後、当該特定した識別情報を削除し、
   前記第２の管理手段において識別情報が管理されていない場合には、前記第１の管理手段において、前記通信の開始を要求した通信端末の識別情報を追加し、
   前記第２のグループに分類される通信端末が通信の開始を要求した通信端末に対して応答可能な状態となったときに、
   前記第１の管理手段において一以上の識別情報が管理されている場合には、前記第１の管理手段において管理されているいずれかの識別情報を削除する、請求項１に記載の情報処理システム。
3. 前記情報更新手段によって前記識別情報が削除された場合に、通信の開始を要求した通信端末と、通信の開始要求に対して応答可能な状態となった通信端末と、の間でコンテンツデータを送信するためのセッションを確立させる制御を実行するセッション制御手段を有することを特徴とする請求項１または２に記載の情報処理システム。
4. 前記通信の開始の要求を受け付ける開始要求受付手段と、
   前記通信の開始の要求に対して応答可能である状態を示す状態情報を受信する受信手段と、を有し、
   前記情報更新手段は、前記開始要求受付手段によって前記通信の開始の要求が受け付けられてから、又は、前記受信手段によって前記状態情報が受信されてから、前記第１の管理手段又は前記第２の管理手段において管理される情報を更新することを特徴とする請求項１乃至３のいずれか１項に記載の情報処理システム。
5. 前記第１のグループ又は第２のグループにおいて複数の識別情報が管理されているときに、前記情報更新手段は、該複数の識別情報のうち最先に管理された識別情報を特定した後、当該特定した識別情報を削除することを特徴とする請求項２に記載の情報処理システム。
6. 第１のグループに分類される複数の通信端末の識別情報を管理する第１の管理手段と、
   第２のグループに分類される複数の通信端末の識別情報を管理する第２の管理手段と、
   前記第１の管理手段又は前記第２の管理手段において管理される識別情報を更新する情報更新手段と、
   前記第２のグループに分類される複数の通信端末の識別情報の各々と、前記第２の管理手段において通信端末の識別情報を管理する時間を示す情報とを関連付けて記憶するスケジュール管理ＤＢと
   を有し、
   前記情報更新手段は、
   前記第２のグループに分類される通信端末が、通信の開始の要求を行った通信端末に対して応答可能な状態となったときに、前記第１の管理手段において識別情報が管理されていない場合には、前記第２の管理手段において、該応答可能な状態となった通信端末の識別情報を追加し、
   前記スケジュール管理ＤＢに記憶される通信端末の識別情報を管理する時間に基づいて、第２の管理手段において管理される識別情報を維持又は削除する
   ことを特徴とする情報処理装置。
7. 情報処理装置に、
   第１のグループに分類される複数の通信端末の識別情報を管理する第１の管理ステップと、
   第２のグループに分類される複数の通信端末の識別情報を管理する第２の管理ステップと、
   前記第１の管理ステップ又は前記第２の管理ステップにおいて管理される識別情報を更新する情報更新ステップと
   を実行させ、
   前記情報更新ステップでは、
   前記第２のグループに分類される通信端末が、通信の開始の要求を行った通信端末に対して応答可能な状態となったときに、前記第１の管理ステップにおいて識別情報が管理されていない場合には、前記第２の管理ステップにおいて、該応答可能な状態となった通信端末の識別情報を追加し、
   前記第２のグループに分類される複数の通信端末の識別情報の各々と、前記第２の管理ステップにおいて通信端末の識別情報を管理する時間を示す情報とを関連付けて記憶するスケジュール管理ＤＢに記憶される通信端末の識別情報を管理する時間に基づいて、第２の管理ステップにおいて管理される識別情報を更新させる、情報処理プログラム。

Images