JP2017028347A - 情報処理装置、通信システム、プログラム - Google Patents

Abstract

【課題】通信プラットフォームを切り替える際に通信の途絶が生じることを抑制する情報処理装置を提供すること。
【解決手段】複数の通信プラットフォームに対応した通信端末と他の通信端末との通信確立を制御する情報処理装置５０であって、第一セッションによる通信が確立している状態で第二セッションによる通信を確立させる通信確立手段５４と、前記複数の通信端末の間で前記第二セッションによる通信が確立したことを確認した場合、前記第二セッションを用いた通信を前記複数の通信端末に開始させる通信開始手段５６と、を有する。
【選択図】図１

Description

本発明は、情報処理装置、通信システム及びプログラムに関する。

インターネット等の通信ネットワークを介して複数の端末装置間でテレビ会議を行う伝送システムの一例としてテレビ会議システムが知られている。ところで、複数の伝送端末間で画像データ及び音声データを送信するための通信プラットフォーム（通信を行うための基盤システムや仕組み）の多様化が進んでいる。このため、同じ拠点同士でテレビ会議を行う場合でも、サービス提供者やユーザは複数の通信プラットフォームのうち２つ以上を採用しうる状況が生じることがある。

従来から、複数の通信プラットフォームのうち適切なプラットフォームを選択する技術が考案されている（例えば、特許文献１参照。）。特許文献１には、セキュリティ上のリスクの少ない形でビデオ会議を実施する目的で、システムが対応する複数のプラットフォームから自動的にビデオ会議を実施するプラットフォームを選択する技術が開示されている。

しかしながら、従来の通信プラットフォームの切り替え技術では、一方の通信プラットフォームから他方の通信プラットフォームへの切り替えの際に生じうる通信の途絶について考慮されていないという問題がある。すなわち、一方の通信プラットフォームを終了させてから他方の通信プラットフォームによる通信を開始するまでの間に、通信が途絶してしまうおそれがある。

本発明は、上記課題に鑑み、通信プラットフォームを切り替える際に通信の途絶が生じることを抑制する情報処理装置を提供することを目的とする。

上記課題に鑑み、本発明は、通信端末と他の通信端末との通信確立を制御する情報処理装置であって、第一セッションによる通信が確立している状態で第二セッションによる通信を確立させる通信確立手段と、前記複数の通信端末の間で前記第二セッションによる通信が確立したことを確認した場合、前記第二セッションを用いた通信を前記複数の通信端末に開始させる通信開始手段とを有する。

通信プラットフォームを切り替える際に通信の途絶が生じることを抑制する情報処理装置を提供することができる。

通信プラットフォームの切り替えを説明する図の一例である。 伝送システムの一例の概略図である。 伝送端末のハードウェア構成図の一例である。 伝送管理システムのハードウェア構成図の一例である。 伝送端末及び伝送管理システムの機能ブロック図の一例である。 伝送システムがＸの通信ＰＦからＹの通信ＰＦに切り替える際のシーケンス図の一例である。 伝送端末が２台から３台に増加した場合に、伝送システムがαの通信ＰＦからβの通信ＰＦに切り替える際のシーケンス図の一例である。 ＰＦ切替判定部が通信ＰＦを切り替えるか否かを判定する処理を説明するフローチャート図の一例である。 ＰＦ切替開始判定部が通信ＰＦの切り替えを開始するか否かを判定する処理を説明するフローチャート図の一例である。 伝送端末及び伝送管理システムの機能ブロック図の一例である（実施例２）。 伝送管理システムが通信ＰＦを切り替えるか否かを判定する手順を示すシーケンス図の一例である。

以下、本発明を実施するための形態について図面を参照しながら実施例を挙げて説明する。

＜通信プラットフォームの切り替えの概略＞
図１は、本実施例における通信プラットフォームの切り替えを説明する図の一例である。図１（ａ）では、通信ネットワーク２に伝送端末１０ａａ、１０ａｂ（通信端末の一例）及び伝送管理システム５０が接続されている。伝送管理システム５０は伝送端末１０ａａと１０ａｂの通信接続を制御するサーバである。伝送管理システム５０は伝送端末１０ａａと１０ａｂに対し両者の存在を互いに通知して（シグナリングして）、伝送端末１０ａａと１０ａｂに通信を開始させている。伝送端末１０ａａと１０ａｂは例えばＷｅｂＲＴＣ（Web Real-Time Communication）というＡＰＩ（Application Interface）を用いて１対１（Peer To Peer）の通信態様でコンテンツデータＣＤ（画像データ及び音声データ）を送受信する。あるいは、中継装置を介して通信してもよい。この通信プラットフォームをＸの通信プラットフォーム（以下、通信ＰＦという）と称することにする。

次に、伝送端末１０ａａ又は１０ａｂが通信状況の変化（例えば、通信帯域の変更、拠点数の変更など）を検出したものとする。伝送管理システム５０は通信状況の変化に対し、通信ＰＦを切り替えると判定する。そこで、まず、伝送端末１０ａａと１０ａｂの間でＹという通信ＰＦのセッションを確立させる。図１０（ｂ）に示すように、伝送端末１０ａａと１０ａｂは、Ｘの通信ＰＦでコンテンツデータＣＤを送受信したまま、Ｙの通信ＰＦのセッションを確立する。なお、Ｘ（第一セッション）とＹ（第二セッション）の通信ＰＦは、音声や映像の圧縮方式が異なっていたり、通信経路が異なっていたりする。

セッションを確立させると伝送端末１０ａａ、１０ａｂはそれぞれセッション確立通知３を伝送管理システム５０に送信する。これにより、伝送管理システム５０は通信ＰＦを切り替える準備ができたことを確認する。

次に、図１（ｃ）に示すように、伝送管理システム５０は伝送端末１０ａａ、１０ａｂに対し、Ｙの通信ＰＦへの切り替えを指示し、Ｘの通信ＰＦのセッションを切断する。

このように、本実施例の伝送システム１は、通信ＰＦの切り替えを行なう際、切り替え前の通信ＰＦにおける通信を維持したまま、切り替え後の通信ＰＦのセッションを確立する。全ての伝送端末１０でセッションが確立すると（通信の準備が整うと）通信ＰＦを切り替えるので、通信ＰＦの切り替えに要する時間は短くなり、ユーザから見ると通信の途絶を感じにくくなる。

＜通信ＰＦ＞
本実施例で用いる通信ＰＦについて説明する。通信ＰＦとは、呼制御の方式、通信経路、及び、映像や音声の圧縮方式等の１つ以上を組み合わせて得られる通信のための基盤システムや仕組みをいう。例えば、図１（ａ）の例では、ＷｅｂＲＴＣというＡＰＩを用いて呼制御し伝送端末１０が互いに通信する通信ＰＦが使用されていた場合、図１（ｂ）（ｃ）では、伝送端末１０ａａ，１０ａｂが中継装置を介する通信に切り替わるか、又は、同じくＷｅｂＲＴＣというＡＰＩのまま、音声や映像の圧縮方式が変更される。

この他、通信ＰＦの構成要素となりうるものには以下のようなものがある。ただし、これらには限られない。
・呼制御… (1)H.323（中継装置を介して通信する）、(2)ＷｅｂＲＴＣ（上記）、(3)SIP(Session Initiation Protocol)、(4)SIPを拡張したプロトコル、(5)インスタントメッセンジャーのプロトコル、(6)SIPのMESSAGEメソッドを利用したプロトコル、(7)インターネットリレーチャットのプロトコル(IRC(Internet Relay Chat))、(8)インスタントメッセンジャーのプロトコルを拡張したプロトコル等が挙げられる。
・通信経路…中継装置３０の有無、中継装置３０の切り替え、同じ中継装置３０内の機能（インタフェース）の切り替え等。
・映像圧縮方式…Ｈ．２６４、Ｈ．２６４／ＡＶＣ、Ｈ．２６４／ＳＶＣ、Ｈ．２６５／ＨＥＶＣ、ＭＰＥＧ４等。
・音声圧縮方式…Ｇ．７１１/Ｇ．７２２、Ｓｐｅｅｘ、Ｏｐｕｓ、ｉＳＡＣ／ｉＬＢＣ等。

なお、映像圧縮方式と音声圧縮方式は独立に切り替えてもよいし、映像圧縮方式と音声圧縮方式はセットで切り替えられてもよい。例えば、呼制御や通信経路の切り替えが映像圧縮方式と音声圧縮方式の切り替えを伴う場合はセットで切り替えられる。呼制御や通信経路の切り替えが映像圧縮方式と音声圧縮方式の切り替えを伴わない場合は、映像圧縮方式と音声圧縮方式のどちらも切り替える必要はないし両方又は一方を切り替えてもよい。また、呼制御や通信経路に関係なく映像圧縮方式と音声圧縮方式のいずれかを独立に切り替えることも可能である。

なお、呼制御の例えばＳＩＰはアプリケーション層の通信プロトコルに分類される場合がある。また、ＲＴＰ（Real-time Transport Protocol）、ＨＴＴＰ、ＨＴＴＰｓ、ＴＣＰ／ＩＰ、ＵＤＰ／ＩＰ等の通信プロトコルについては、各呼制御に適切なものが用いられる。このため呼制御と共に切り替えられるとしてもよいし、呼制御が切り替わっても同じ通信プロトコルが使用されてもよい。

＜用語について＞
２つ以上の伝送端末１０の間でコンテンツデータＣＤの送受信の準備ができることを、セッションが確立したと称する。セッションの厳密な定義はないが、例えば内容につながりがある一連の通信などがセッションと呼ばれる。セッション確立を通信確立と称する場合がある。

また、本実施例ではセッションが確立した状態で、２つ以上の伝送端末１０の間でコンテンツデータＣＤが送受信される。コンテンツデータＣＤには伝送端末１０に接続された情報処理装置が表示する文書ファイル等の表示データも含まれる。

なお、本実施例の通信ＩＤは、それぞれ伝送端末若しくはこの伝送端末を利用するユーザを一意に識別するために使われる言語、文字、記号、又は各種のしるし等の識別情報を示す。また、通信ＩＤは、上記言語、文字、記号、及び各種のしるしのうち、少なくとも２つが組み合わされた識別情報であってもよい。

＜伝送システム１の構成例＞
図２は、本実施例に係る伝送システム１の一例の概略図である。伝送システム１（通信システムの一例）は、伝送管理システム５０を介して複数の伝送端末間で情報や感情等を相互に伝達するためのコミュニケーションシステムである。伝送システム１には、テレビ会議システム、テレビ電話システム、音声会議システム、音声電話システム、ＰＣ（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)３１３に対する各種データの読み出し又は書き込みを制御するＣＤ−ＲＯＭドライブ３１４を有する。さらに、上記各構成要素を図４に示されているように電気的に接続するためのアドレスバスやデータバス等のバスライン３１０を備えている。

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

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

＜機能構成＞
次に、図５を用いて、伝送端末１０，及び、伝送管理システム５０の機能構成について説明する。図５は、伝送端末１０，及び、伝送管理システム５０の機能ブロック図の一例である。なお、プログラム提供システム９０は、本実施例では直接関係ないため、図５では省略されている。また、携帯端末２０は伝送端末１０とほぼ同様の機能を備え、相違があるとしても本実施例を実現する上で支障がないものとする。

<<伝送端末の各機能構成>>
伝送端末１０は、送受信部１１、表示制御部１２、撮像部１３、音声入力部１４ａ、音声出力部１４ｂ、宛先リスト作成部１５、操作入力受付部１６、ログイン要求部１７、状況変化通知部１８、通信ＰＦ管理部２１、及び、記憶・読出処理部１９を有している。

伝送端末１０が有する各部は、図３に示されている各構成要素のいずれかが、フラッシュメモリ１０４からＲＡＭ１０３上に展開された端末用プログラム１３０に従ったＣＰＵ１０１からの命令によって動作することで実現される機能、又は機能される手段である。

また、伝送端末１０は、図３に示されているフラッシュメモリ１０４によって構築される不揮発性記憶部１０００を有している。

伝送端末１０の送受信部１１は、図３に示されているＣＰＵ１０１からの命令、及び図３に示されているネットワークＩ／Ｆ１１１によって実現され、通信ネットワーク２を介して他の伝送端末１０、伝送管理システム５０，及び中継装置３０等と各種データの送受信を行う。

送受信部１１にはα用機能部１１ａ、β用機能部１１ｂ、Ｘ用機能部１１ｃ、及び、Ｙ用機能部１１ｄが接続されている。α用機能部１１ａはαの通信ＰＦに必要な処理を行い、β用機能部１１ｂはβの通信ＰＦに必要な処理を行う。αの通信ＰＦは第一通信プラットフォームの一例であり、βの通信ＰＦは第二通信プラットフォームの一例である。

α用機能部１１ａは、例えば、ＷｅｂＲＴＣで用いられるグローバルＩＰアドレスとポート番号を宛先に通信を行い、β用機能部１１ｂは、中継装置３０のＩＰアドレス（グローバルＩＰアドレスでもプライベートＩＰアドレスでもよい）を宛先に通信を行う。また、αの通信ＰＦとβの通信ＰＦの通信プロトコルが異なる場合は、α用機能部１１ａはαの通信ＰＦに用いられる通信プロトコルで通信し、β用機能部１１ｂはβの通信ＰＦに用いられる通信プロトコルで通信する。さらに、αの通信ＰＦとβの通信ＰＦの映像や音声の圧縮方式が異なる場合、α用機能部１１ａはαの通信ＰＦに用いられる圧縮方式で圧縮された映像や音声を圧縮・伸張し、β用機能部１１ｂはβの通信ＰＦに用いられる圧縮方式で圧縮された映像や音声を圧縮・伸張する。Ｘ用機能部１１ｃとＹ用機能部１１ｄについても同様であり、Ｘ用機能部１１ｃはＸの通信ＰＦに必要な処理を行い、Ｙ用機能部１１ｄはＹの通信ＰＦに必要な処理を行う。

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

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

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

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

宛先リスト作成部１５は、図３に示されているＣＰＵ１０１からの命令によって実現され、伝送管理システム５０から受信した宛先状態情報（宛先候補端末及び宛先候補の伝送端末１０及び携帯端末２０の稼動状態）に基づいて、宛先リストの作成及び更新を行う。

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

ログイン要求部１７は、図３に示されているＣＰＵ１０１からの命令によって実現され、上記電源ＯＮの受け付けを契機として（又はユーザの認証操作を契機として）動作する。すなわち、送受信部１１から通信ネットワーク２を介して伝送管理システム５０に、ログインを要求する旨を示すログイン要求情報、及び要求元端末の現時点のＩＰアドレスを自動的に送信する。

状況変化通知部１８は図３に示されているＣＰＵ１０１からの命令、及び図３に示されているネットワークＩ／Ｆ１１１によって実現され、通信帯域の変更など通信状況の変化を伝送管理システム５０に通知する。

通信ＰＦ管理部２１は、図３に示されているＣＰＵ１０１からの命令等により実現され、伝送管理システム５０からの指示に応じて伝送端末１０が使用すべき通信ＰＦを管理する。

記憶・読出処理部１９は、図３に示されているＣＰＵ１０１からの命令、及び図３に示すＳＳＤ１０５によって実現され、不揮発性記憶部１０００に各種データを記憶したり、不揮発性記憶部１０００に記憶された各種データを読み出したりする処理を行う。この不揮発性記憶部１０００には、通信先としての伝送端末１０の端末又はユーザを識別するための通信ＩＤ（Identification）、タイプ識別情報（伝送端末１０や携帯端末２０の区別を示す情報）、及びパスワード等が記憶される。なお、通信ＩＤ及びパスワードは不揮発性記憶部１０００に記憶されていなくてもよく、例えば伝送管理システム５０に対してログイン要求を行う際に都度、ユーザが入力するようにしてもよい。

＜＜伝送管理システムの機能構成＞＞
伝送管理システム５０は、送受信部５１、ＰＦ切替判定部５２、認証部５３、セッション管理部５４、通信状況検出部５５、ＰＦ切替開始判定部５６、及び、記憶・読出処理部５９を有している。これら各部は、図４に示されている各構成要素のいずれかが、ＨＤ３０４からＲＡＭ３０３上に展開された伝送管理用プログラム３２０に従ったＣＰＵ３０１からの命令によって動作することで実現される機能又は機能される手段である。また、伝送管理システム５０は、伝送管理システム５０の電源をＯＦＦにしても各種データの記憶が維持される不揮発性記憶部５０００を有しており、この不揮発性記憶部５０００は図４に示されているＨＤ３０４により構築されている。

以下、不揮発性記憶部５０００に記憶された各データベースについて説明する。なお、切替制限条件管理ＤＢ５００６については後述する。

不揮発性記憶部５０００には、表１に示されているようなセッション管理テーブルによって構成されているセッション管理ＤＢ５００１が構築されている。このセッション管理テーブルでは、セッションを識別するセッションＩＤ毎に、同じセッションに参加している伝送端末１０の端末ＩＤ、通信ＰＦが関連付けられて管理される。

表１（ａ）のセッション管理テーブルは、通信ＰＦが切り替わる前のセッション管理テーブルを示し、表１（ｂ）のセッション管理テーブルは、通信ＰＦが切り替わった後のセッション管理テーブルを示している。詳細は後述するが、表１（ａ）でセッションＩＤ＝「Se_001」のＸの通信ＰＦが、表１（ｂ）でセッションＩＤ＝「Se_003」のセッションとして登録されている。そして、通信ＰＦがＸからＹに切り替わっている。

不揮発性記憶部５０００には、表２に示されているような宛先情報を管理する宛先リスト管理テーブルによって構成されている宛先リスト管理ＤＢ５００２が構築されている。宛先リスト管理テーブルでは、テレビ会議における接続の開始（発呼）を要求する要求元端末の通信ＩＤに対して、全ての宛先候補の伝送端末１０又は携帯端末２０の通信ＩＤが関連付けられて管理される。この宛先候補の通信ＩＤは、要求元端末が通信を開始できる伝送端末１０又は携帯端末２０である。

不揮発性記憶部５０００には、表３に示されているような端末管理テーブルによって構成されている端末管理ＤＢ５００３が構築されている。この端末管理テーブルでは、伝送端末１０の通信ＩＤ毎に、各伝送端末の稼動状態、各通信ＩＤを宛先とした場合の名称、及び、端末のＩＰアドレス、が関連付けられて管理される。

不揮発性記憶部５０００には、表４に示されているような認証管理テーブルによって構成されている認証管理ＤＢ５００４が構築されている。この認証管理テーブルでは、伝送端末１０又はユーザの通信ＩＤ毎に、各伝送端末１０又はユーザのパスワードが関連付けられて管理される。

不揮発性記憶部５０００には、表５（ａ）に示されているようなＰＦ判定テーブルによって構成されているＰＦ判定管理ＤＢ５００５が構築されている。表５（ａ）のＰＦ判定テーブルでは、１つでも通信帯域が所定以下（例えば１Ｍｂｐｓ）の伝送端末１０があるか否かに応じて通信ＰＦが関連付けられて管理される。Ｘの通信ＰＦは、ＷｅｂＲＴＣを用いるが例えば映像や音声の圧縮率が高い通信ＰＦであり、Ｙの通信ＰＦは映像や音声の圧縮率が相対的に低い通信ＰＦを意味する。

また、ＰＦ判定テーブルには種々のものが考えられ、その一例として表５（ｂ）のＰＦ判定テーブルでは、拠点数に応じて通信ＰＦが関連付けられて管理される。αの通信ＰＦは例えばＷｅｂＲＴＣを用いた通信を意味し、βの通信ＰＦは中継装置３０を介する通信を意味する。

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

認証部５３は、図４に示されているＣＰＵ３０１からの命令等によって実現される。認証部５３は送受信部５１を介して受信されたログイン要求情報に含まれている通信ＩＤ及びパスワードの組み合わせが認証管理ＤＢ５００４に登録されているものと一致するか否かに応じて伝送端末１０又はユーザを認証する。なお、認証方法はこれに限られず、クライアント証明書（公開鍵と秘密鍵を用いた認証方法）を用いてもよい。

セッション管理部５４は、図４に示されているＣＰＵ３０１からの命令によって実現される。セッション管理部５４は、認証部５３により認証が成立した伝送端末１０から宛先端末との接続を要求されると（開始要求情報を取得すると）、セッション管理ＤＢ５００１に、セッションＩＤ、セッションに参加している伝送端末１０の通信ＩＤ（要求元端末の通信ＩＤ、宛先端末の通信ＩＤ）、及び、通信ＰＦを関連付けて記憶して管理する。セッション管理部５４は通信ＰＦごとに適切なセッションを確立する。

通信状況検出部５５は、図４に示されているＣＰＵ３０１からの命令によって実現され、伝送端末１０同士及び伝送端末１０と伝送管理システム５０間の通信状況を検出する。本実施例の通信状況の一例としては通信帯域や拠点数が上げられる。つまり、伝送端末１０の状況変化通知部１８が通信情報の変化を通知する場合も、伝送管理システム５０の通信状況検出部５５が通信状況の変化を検出する場合もある。

ＰＦ切替判定部５２は、図４に示されているＣＰＵ３０１からの命令によって実現され、通信状況に応じてＰＦ判定テーブルを参照して適切な通信ＰＦを選択する（決定する）。通信ＰＦの決定や切り替えの判定について詳細は後述する。通信ＰＦを切り替えると判定した場合、セッション管理部５４に切り替え後の通信ＰＦを通知してセッションの確立を要求する。

ＰＦ切替開始判定部５６は、図４に示されているＣＰＵ３０１からの命令によって実現され、通信ＰＦの切り替えを伝送端末１０に開始させるか否かを判定する。ＰＦ切替開始判定部５６は、全ての伝送端末１０が通信ＰＦを切り替える準備ができたことを確認すると、通信ＰＦの切り替えを伝送端末１０に開始させる。

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

＜セッションの確立から通信ＰＦの切り替えの動作手順＞
<<伝送端末１０が２台の場合>>
まず、図６を用いて伝送端末１０が２台のまま伝送システム１が通信ＰＦを切り替える手順を説明する。図６は、伝送システム１がＸの通信ＰＦからＹの通信ＰＦに切り替える際のシーケンス図の一例である。

S1：まず、ユーザが電源スイッチ１０９をＯＮにすると、操作入力受付部１６が電源ＯＮを受け付けて、伝送端末１０ａａを起動させる。

S2：ログイン要求部１７は上記電源ＯＮを契機とし、送受信部１１を介して伝送管理システム５０にログイン要求を示すログイン要求情報を自動的に送信する。ログイン要求は電源ＯＮ時だけでなくユーザ操作によって任意のタイミングで送信されることができる。ログイン要求情報には、要求元である伝送端末１０ａａを識別するための通信ＩＤ、及びパスワードが含まれている。

なお、伝送端末１０ａｂも同様に伝送管理システム５０に対しログインしているため、伝送管理システム５０は伝送端末１０ａａ、１０ａｂのＩＰアドレスとポート番号等を検出する。伝送管理システム５０が互いのＩＰアドレスとポート番号等を互いに通知することで伝送端末１０ａａ、１０ａｂが通信可能になる。伝送管理システム５０はＸの通信ＰＦを伝送端末１０ａａ，ａｂに指示する。伝送端末１０ａａ，ａｂの通信ＰＦ管理部２１はＸの通信ＰＦで通信することを検出する。

S3：伝送端末１０ａａの送受信部１１は伝送端末１０ａｂに対し発呼し、伝送端末１０ａｂの送受信部１１はこの発呼を受信して着信音を吹鳴させる。
S4：伝送端末１０ａｂのユーザがオフフック操作を行うと操作入力受付部１６がそれを受け付けて、伝送端末１０ａａと１０ａｂでＸの通信ＰＦによる通信が可能になる。すなわち、伝送端末１０ａａと１０ａｂの間でＸの通信ＰＦのセッションが確立する。伝送端末１０ａａと１０ａｂはＸの通信ＰＦを利用して通信（コンテンツデータＣＤの送受信）を行う。

そして、Ｘの通信ＰＦのセッションが確立したまま（通信したまま）、通信ＰＦの切り替えの契機となる状態変化が生じたものとする。例えば、通信帯域が１Ｍｂｐｓを超えるようになったものとする。

S5：伝送端末１０ａａの状況変化通知部１８は通信状況が変化すると伝送管理システム５０に状況変化通知を送信する。伝送管理システム５０の通信状況検出部５５は状況変化通知を取得する。本実施例では通信帯域の変化が検知されたものとし、状況変化通知には変化後の通信帯域が含まれる。

S5.1：状況変化通知を取得すると、伝送管理システム５０のＰＦ切替判定部５２は通信ＰＦを切り替えるか否かを判定する。すなわち、ＰＦ切替判定部５２はＰＦ判定テーブルを参照して、伝送端末１０ａａの通信帯域に基づき通信ＰＦを決定する。ここでは、伝送端末１０ａａの通信帯域が１Ｍｂｐｓを超えたため、Ｙの通信ＰＦへ切り替える必要があると判定されたものとする。

S5.2：伝送管理システム５０のＰＦ切替判定部５２はＹの通信ＰＦへのＰＦ切替指示を伝送端末１０ａａに通知する。

S5.3：伝送管理システム５０のＰＦ切替判定部５２はＹの通信ＰＦへのＰＦ切替指示を伝送端末１０ａｂに通知する。

S5.2.1：伝送端末１０ａａの送受信部１１は伝送端末１０ａｂに対し発呼し、伝送端末１０ａｂの送受信部１１はこの発呼を受信して着信音を吹鳴させる。

S5.2.1.1：伝送端末１０ａｂのユーザがオフフック操作を行うと操作入力受付部１６がそれを受け付けて、伝送端末１０ａａと１０ａｂでＹの通信ＰＦのセッションが確立する。つまり、伝送端末１０ａａと１０ａｂはＹの通信ＰＦで通信が可能な状態になる。この状態では、まだ、伝送端末１０ａａと１０ａｂはＹの通信ＰＦで通信を行わない。

このように、Ｘの通信ＰＦで通信したまま、伝送管理システム５０は切り替え後のＹの通信ＰＦでのセッションを確立する。なお、伝送管理システム５０のセッション管理部５４は、セッション管理テーブルにＹの通信ＰＦに関するセッションＩＤ、伝送端末１０の通信ＩＤ、通信ＰＦを登録する（表１（ｂ））。

S5.2.1.2：Ｙの通信ＰＦのセッションを確立した伝送端末１０ａｂは、通信ＰＦの切り替え準備が完了したことを知らせるセッション確立通知を伝送管理システム５０に送信する。

S5.2.1.1.1：Ｙの通信ＰＦのセッションを確立した伝送端末１０ａａは、セッション確立通知を伝送管理システム５０に送信する。

S5.2.1.1.1.1：伝送管理システム５０のＰＦ切替開始判定部５６は、通信ＰＦの切り替えを開始するか否かを判定する。判定の基準は、Ｙの通信ＰＦのセッションが確立されたかどうか（セッション確立通知を全ての伝送端末１０ａａ、１０ａｂから受け取ったかどうか）である。セッション確立通知を全ての伝送端末１０から受け取ったか否かの判定には、表１（ｂ）のセッション管理テーブルを使用する。新たに確立されたＹの通信ＰＦに登録されている全ての伝送端末１０からセッション確立通知を受け取ったか否かを判定する。

S5.2.1.1.1.1.1：セッション確立通知を全ての伝送端末１０から受け取ったことを確認すると、伝送管理システム５０のＰＦ切替開始判定部５６は、ＰＦ切替開始通知を伝送端末１０ａｂに指示する。ＰＦ切替開始通知は、新たな通信ＰＦへの切替を行わせる通知である。

S5.2.1.1.1.1.2：伝送管理システム５０のＰＦ切替開始判定部５６は、ＰＦ切替開始通知を伝送端末１０ａａに指示する。

これにより、伝送端末１０ａａ、１０ａｂの通信ＰＦ管理部２１はＹの通信ＰＦで通信することを検出する。これにより、通信ＰＦの切り替えを行う。なお、ＰＦ切替開始通知の送り先の伝送端末１０は、セッション管理テーブルで新たに確立されたＹの通信ＰＦに登録されている全ての伝送端末１０である。

S5.2.1.1.1.1.1.1：ＰＦ切替開始通知を受け取った伝送端末１０ａｂの通信ＰＦ管理部２１は通信ＰＦを切り替える。すなわち、伝送端末１０ａｂは送受信部１１とＸ用機能部１１ｃによる通信を終了し、送受信部１１とＹ用機能部１１ｄによる通信を開始する。

S5.2.1.1.1.1.2.1：ＰＦ切替開始通知を受け取った伝送端末１０ａａの通信ＰＦ管理部２１は通信ＰＦを切り替える。すなわち、伝送端末１０ａａは送受信部１１とＸ用機能部１１ｃによる通信を終了し、送受信部１１とＹ用機能部１１ｄによる通信を開始する。

このようにして、伝送端末１０ａａと１０ａｂはＹの通信ＰＦによる通信を開始する。

S5.2.1.1.1.1.3：次に、伝送管理システム５０のＰＦ切替開始判定部５６は切り替え前のＸの通信ＰＦのセッションを切断する。このため、ＰＦ切替開始判定部５６は伝送端末１０ａｂにセッション切断通知を送信する。

S5.2.1.1.1.1.4：伝送管理システム５０のＰＦ切替開始判定部５６は伝送端末１０ａａにセッション切断通知を送信する。

S5.2.1.1.1.1.3.1：伝送端末１０ａｂの通信ＰＦ管理部２１は、Ｘの通信ＰＦのセッションを切断させる。

S5.2.1.1.1.1.4.1：伝送端末１０ａａの通信ＰＦ管理部２１は、Ｙの通信ＰＦのセッションを切断させる。なお、セッションを切断させるとは、例えば、コンテンツデータＣＤの送受信に関係なく行う定期的な死活通知を含む一切の通信を終了することをいう。また、通信相手のＩＰアドレスやポート番号などの通信に必要な情報も破棄される。

このように、本実施例の伝送システム１は、区間Ｔ３でＸの通信ＰＦでコンテンツデータＣＤを送受信したまま、区間Ｔ３で切り替え後のＹの通信ＰＦのセッションが確立している。この状態で、区間Ｔ３でＹの通信ＰＦで通信を開始し（通信ＰＦを切り替える）、また、通信ＰＦの切り替えの後に区間Ｔ４でＸの通信ＰＦのセッションを切断するため、通信ＰＦの切り替えの際に、音声や画像が途絶することを抑制できる。

また、全ての伝送端末１０からセッション確立通知が送信されると、通信ＰＦの切り替えが開始されるので、全ての伝送端末１０が新しい通信ＰＦによる通信の準備をできると、通信ＰＦを切り替える。したがって、全ての伝送端末１０において音声や画像が途絶することを抑制できる。

コンテンツデータＣＤの送受信に用いられる通信ＰＦは、ステップS5.2.1.1.1.1.1.1とステップS5.2.1.1.1.1.2.1で切り替えられるので、同じ音声と画像が重複して送信されることもない。

<<伝送端末１０が２台から３台に増加する場合>>
次に、伝送端末１０が２台から３台に増加する場合を説明する。まず、この例で使用するセッション管理テーブルを説明する。

表１と同様に、表６（ａ）のセッション管理テーブルは、通信ＰＦが切り替わる前のセッション管理テーブルを示し、表６（ｂ）のセッション管理テーブルは、通信ＰＦが切り替わった後のセッション管理テーブルを示している。表６（ａ）でセッションＩＤ＝「Se_001」のαの通信ＰＦが、表６（ｂ）ではセッションＩＤ＝「Se_003」のセッションとして登録されている。そして、表６（ｂ）で伝送端末１０の数が３つに増え、通信ＰＦがβに切り替わっている。

図７は、伝送端末１０が２台から３台に増加した場合に、伝送システム１がαの通信ＰＦからβの通信ＰＦに切り替える際のシーケンス図の一例である。

S1〜S4：図６と同様である。これにより、まず伝送端末１０ａａと１０ａｂの間でαの通信ＰＦによる通信が行われている。

S5：次に、伝送端末１０ａｃの送受信部１１が伝送端末１０ａａ又は１０ａｂに対する通信の開始要求を伝送管理システム５０に送信する。伝送管理システム５０はこれを状況変化通知として取得する。

S5.1：状況変化通知を取得すると、伝送管理システム５０のＰＦ切替判定部５２は通信ＰＦを切り替えるか否かを判定する。すなわち、ＰＦ切替判定部５２はＰＦ判定テーブルを参照して、セッションに参加する伝送端末１０の数に基づき通信ＰＦを決定する。ここでは、セッションに参加する伝送端末１０の数が３台に増加したため、βの通信ＰＦへ切り替えると判定されたものとする（表５（ｂ））。

S5.2：伝送管理システム５０のＰＦ切替判定部５２はβの通信ＰＦへのＰＦ切替指示を伝送端末１０ａａに通知する。

S5.3：伝送管理システム５０のＰＦ切替判定部５２はβの通信ＰＦへのＰＦ切替指示を伝送端末１０ａｂに通知する。

なお、伝送端末１０ａｃは、βの通信ＰＦで伝送端末１０ａｂと通信するための情報（ＩＰアドレス、ポート番号等）を伝送管理システム５０から取得している。

S5.2.1：伝送端末１０ａａの送受信部１１は伝送端末１０ａｂに対し発呼し、伝送端末１０ａｂの送受信部１１はこの発呼を受信して着信音を吹鳴させる。

S5.2.1.1：伝送端末１０ａｂのユーザがオフフック操作を行うと操作入力受付部１６がそれを受け付けて、伝送端末１０ａａと１０ａｂでβの通信ＰＦのセッションが確立する。

S6：伝送端末１０ａｃの送受信部１１は伝送端末１０ａｂに対し発呼し、伝送端末１０ａｂの送受信部１１はこの発呼を受信して着信音を吹鳴させる。

S5.2.1.2：伝送端末１０ａｂのユーザがオフフック操作を行うと操作入力受付部１６がそれを受け付けて、伝送端末１０ａｃと１０ａｂでβの通信ＰＦのセッションが確立する。

このように、αの通信ＰＦを確立したまま、伝送端末１０ａａと１０ａｂ、伝送端末１０ａｃと１０ａｂが切り替え後のβの通信ＰＦでのセッションを確立する。なお、伝送管理システム５０のセッション管理部５４は、セッション管理テーブルに新たに確立したβの通信ＰＦに関し、セッションＩＤ、伝送端末１０の通信ＩＤ、及び、通信ＰＦを登録する（表６（ｂ））。

S5.2.1.3：βの通信ＰＦのセッションを確立した伝送端末１０ａｂは、通信ＰＦの切り替えを知らせるセッション確立通知を伝送管理システム５０に送信する。

S7：βの通信ＰＦのセッションを確立した伝送端末１０ａｃは、通信ＰＦの切り替えを知らせるセッション確立通知を伝送管理システム５０に送信する。

S5.2.1.1.1：βの通信ＰＦのセッションを確立した伝送端末１０ａａは、通信ＰＦの切り替えを知らせるセッション確立通知を伝送管理システム５０に送信する。

S5.2.1.1.1.1：伝送管理システム５０のＰＦ切替開始判定部５６は、通信ＰＦの切り替えを開始するか否かを判定する。判定の基準は、図６と同様である。

S5.2.1.1.1.1.1：セッション確立通知を全ての伝送端末１０から受け取ったことを確認すると、伝送管理システム５０のＰＦ切替開始判定部５６は、ＰＦ切替開始通知を伝送端末１０ａｂに指示する。これにより、伝送端末１０ａｂの通信ＰＦ管理部２１はβの通信ＰＦで通信することを検出する。

S5.2.1.1.1.1.2：伝送管理システム５０のＰＦ切替開始判定部５６は、ＰＦ切替開始通知を伝送端末１０ａａに指示する。これにより、伝送端末１０ａａの通信ＰＦ管理部２１はβの通信ＰＦで通信することを検出する。

S5.2.1.1.1.1.1.1：ＰＦ切替開始通知を受け取った伝送端末１０ａｂの通信ＰＦ管理部２１は通信ＰＦを切り替える。すなわち、伝送端末１０ａｂは送受信部１１とβ用機能部１１ｂによる通信を開始する。

S5.2.1.1.1.1.2.1：ＰＦ切替開始通知を受け取った伝送端末１０ａａの通信ＰＦ管理部２１は通信ＰＦを切り替える。すなわち、伝送端末１０ａａは送受信部１１とβ用機能部１１ｂによる通信を開始する。

S5.2.1.1.1.1.3：伝送管理システム５０のＰＦ切替開始判定部５６は、ＰＦ切替開始通知を伝送端末１０ａｃに指示する。これにより、伝送端末１０ａｃの通信ＰＦ管理部２１はβの通信ＰＦで通信することを検出する。

このようにして、伝送端末１０ａａ、１０ａｂ、１０ａｃはβの通信ＰＦによる通信を開始することができる。

S5.2.1.1.1.1.4：次に、伝送管理システム５０のＰＦ切替開始判定部５６は切り替え前のαの通信ＰＦのセッションを切断する。このため、ＰＦ切替開始判定部５６は伝送端末１０ａｂにセッション切断通知を送信する。

S5.2.1.1.1.1.5：伝送管理システム５０のＰＦ切替開始判定部５６は伝送端末１０ａａにセッション切断通知を送信する。

S5.2.1.1.1.1.4.1：伝送端末１０ａｂの通信ＰＦ管理部２１は、αの通信ＰＦのセッションを切断させる。

S5.2.1.1.1.1.5.1：伝送端末１０ａａの通信ＰＦ管理部２１は、αの通信ＰＦのセッションを切断させる。

このように、セッションに参加する伝送端末１０の台数が増える場合も、通信ＰＦの切り替えに伴う通信の途絶を抑制することができる。

<<通信ＰＦの切り替えの判定>>
図８は、ＰＦ切替判定部５２が通信ＰＦを切り替えるか否かを判定する処理を説明するフローチャート図の一例である。

まず、伝送管理システム５０の送受信部１１は状態変更通知を伝送端末１０から受信する（Ｓ１０）。状態変更通知を送信する伝送端末１０は主に端末管理テーブルに登録されている伝送端末１０であるが、これに限られない。状態変更通知には、ＰＦ判定テーブルに基づく判定を行うための情報が含まれる。すなわち、上記の通信帯域やセッションに参加する伝送端末１０の数に関する情報である。また、伝送管理システム５０の通信状況検出部５５が通信状況の変化を検出する場合がある。

次に、伝送管理システム５０のＰＦ切替判定部５２はＰＦ判定テーブルを参照し、通信ＰＦを切り替えるか否かを判定する（Ｓ２０）。

ステップＳ２０の判定がＹｅｓの場合、ＰＦ切替判定部５２はＰＦ切替指示を各伝送端末１０に指示する（Ｓ３０）。

ステップＳ２０の判定がＮｏの場合、ＰＦ切替判定部５２は通信ＰＦを切り替えないので、現在の通信ＰＦが維持される。

<<通信ＰＦ切替開始判定>>
図９は、ＰＦ切替開始判定部５６が通信ＰＦの切り替えを開始するか否かを判定する処理を説明するフローチャート図の一例である。図９は、図６，７のＳ5.2.1.1.1.1の処理を詳細に説明するフローチャート図である。

セッションが確立され複数の伝送端末１０が通信（会議）を行っている（Ｓ１０）。

この状態で伝送管理システム５０のＰＦ切替開始判定部５６は、セッション確立通知を待ち受ける状態となる（Ｓ２０）。

その後、セッションの確立を要求された各伝送端末からセッション確立通知を受信する（Ｓ３０）。

セッション確立通知を受け取ったら、ＰＦ切替開始判定部５６は同じセッションに参加している全ての伝送端末１０からセッション確立通知を受信したか否かを判定する（Ｓ４０）。すなわち、セッション管理テーブルの切り替え前の通信ＰＦ（表１（ａ）、表６（ａ）のSe_001のレコード）に対応づけられている全ての伝送端末１０からセッション確立通知を受信したか否かを判定する。

ステップＳ４０の判定がＹｅｓの場合、ＰＦ切替開始判定部５６はＰＦ切替開始通知を各伝送端末１０に送信する（Ｓ５０）。すなわち、セッション管理テーブルの切り替え後の通信ＰＦ（表１（ｂ）、表６（ｂ）のSe_003のレコード）に対応づけられている全ての伝送端末１０にＰＦ切替開始通知を送信する。

次に、ＰＦ切替開始判定部５６は切り替え前の通信ＰＦのセッション切断を各伝送端末１０に送信する（Ｓ６０）。すなわち、セッション管理テーブルの切り替え前の通信ＰＦ（表１（ａ）、表６（ａ）のSe_001のレコード）に対応づけられている全ての伝送端末１０にセッション切断を送信する。

ＰＦ切替開始判定部５６は会議が終了するまで図９の処理を繰り返す（Ｓ７０）。会議が終了するとは、ログアウトや伝送端末１０の電源ＯＦＦなどによりセッションに参加する伝送端末１０がゼロになることをいう。

このように、本実施例の伝送管理システム５０は、全ての伝送端末１０からセッション確立通知を受信すると通信ＰＦを切り替えさせるので、全ての伝送端末１０が切り替え後の通信ＰＦで通信する準備ができた場合に、通信ＰＦを切り替えることができる。

＜その他のＰＦ判定テーブルの例 切り替えの制限＞
続いて、上記以外の好適なＰＦ判定テーブルや切り替えの制限について説明する。

このＰＦ判定テーブルでは、６つの条件に通信ＰＦが対応づけられている。条件１は拠点数が少ないという条件を含むため、ＷｅｂＲＴＣ・高レートで通信するαの通信ＰＦが対応づけられている。条件２は利用可能帯域が大きいという条件を含むため、高レート・高解像度の通信であるδの通信ＰＦが対応づけられている。条件３は移動体通信網を利用しているという条件を含むため、通信帯域の変動に対応しやすいように低品質な通信であるεの通信ＰＦが対応づけられている。条件４は相互に宛先リストに載っていない伝送端末があるという条件を含むため、ＷｅｂＲＴＣ・低レートの通信であるδの通信ＰＦが対応づけられている。条件５は全ての伝送端末１０が有線接続であるという条件を含むため、高レート・低から中解像度の通信であるηの通信ＰＦが対応づけられている。

条件１について補足する。全拠点が社内ネットワークに接続されていることは遅延も少ないため、拠点数が少なければＷｅｂＲＴＣを用いてもストレスの少ない通信を期待できる。条件２について補足する。利用可能帯域が大きいという条件は全ての伝送端末１０に当てはまる場合に成り立つものとする。また、利用可能帯域は伝送端末１０が伝送管理システム５０に通知しても、伝送管理システム５０が判定してもよい。

条件３について補足する。移動体通信網があるかどうかは伝送端末１０や携帯端末２０が伝送管理システム５０に通知するものとする。伝送端末１０のタイプ識別情報や携帯端末２０のＯＳから判別してもよい。

条件４について補足する。本実施例の伝送管理システム５０では宛先リストに載っていない伝送端末１０を相手にして伝送端末１０が接続要求することはできない。例えば、伝送端末１０ａａと伝送端末１０ａｂは相互に宛先リストに登録され、伝送端末１０ａｂと伝送端末１０ａｃは相互に宛先リストに登録されているとする。この場合、伝送端末１０ａａと伝送端末１０ａｂは通信でき、伝送端末１０ａｂと伝送端末１０ａｃは通信できる。しかし、伝送端末１０ａａと１０ａｃは相互に宛先リストに登録されていないので通信できない。伝送端末１０ａａ、１０ａｂ、１０ａｃによるテレビ会議を可能とするため、伝送端末１０ａｂから見て通信可能な伝送端末１０ａａと１０ａｃの間の通信をＷｅｂＲＴＣにより通信できるようにするための条件が条件４である。伝送管理システム５０は、セッション管理テーブルにおいて２つのセッションに共通する伝送端末１０がある場合、条件４が成立すると判定する。条件４を満たす場合、伝送管理システム５０が伝送端末１０ａｂに通信ＰＦを切り替えるか問い合わせてもよいし、伝送端末１０ａｂのユーザが通信ＰＦの切り替えを要求してもよい。切り替える場合、セッション管理部５４は伝送端末１０ａａ、１０ａｂ、１０ａｃに対し新たに１つのセッションＩＤを割り当てる。

条件５について補足する。伝送端末１０の全てが有線接続であるかどうかは、伝送端末１０や携帯端末２０が伝送管理システム５０に通知することが好ましい。なお、携帯端末２０が伝送管理システム５０に接続されている場合は有線接続でないと判定できる。

不揮発性記憶部５０００には、表８に示されているような切替制限条件テーブルによって構成されている切替制限条件管理ＤＢ５００６が構築されている。この切替制限条件テーブルでは、ＰＦ切替テーブルの条件を満たしてもＰＦを切り替えることができない制限内容が登録されている。

ユーザがテレビ会議を行っている最中に通信ＰＦが切り替えられることは、長いタイムスパンでは通信をより効果的に実施することを可能にする。しかし、短期的には画面レイアウトが更新されるなどのデメリットが生じる可能性がある。このため、本実施例のように、高頻度な通信ＰＦの切り替えを抑制したり（切替制限条件テーブルの２，３の制限種別）、大きな効果が見込まれない通信ＰＦへの切り替え（切替制限条件テーブルの１の制限種別）を実施したりしない、等の制限があることが有効である。

伝送システム１が対応する通信ＰＦの種類が多い場合、表８の切替制限条件テーブルに登録すべき制限種別（切替制限条件テーブルの１の制限種別）が肥大化する場合が生じ得る。これは、多くの通信ＰＦがあるとその分、制限内容も増えるためであり、また、切替制限条件テーブルに不備があり切替先の通信ＰＦが存在しない場合に制限内容の追加が必要になるためである。

そこで、表９のようなＰＦ切替テーブルを用いることが有効である。表９はＰＦ切替テーブルの別の一例を示す。表９のＰＦ切替テーブルでは、現在の通信ＰＦに対し切替条件と切替先の通信ＰＦが対応づけて管理されている。すなわち、ＰＦ切替判定部５２は現在の通信ＰＦをキーとして、切替条件が揃った場合に切替先の通信ＰＦに切り替えると判定する。ＰＦ切替テーブルを先頭から走査して現在の通信ＰＦの切替条件に適合する場合に限って通信ＰＦを切り替えることで、切替制限条件テーブルが肥大化することを抑制できる。

本実施例では、ユーザごとに別々のＰＦ切替テーブルを用いて通信ＰＦを切り替える伝送システム１について説明する。

実施例１では、伝送管理システム５０がＰＦ切替テーブルを管理していた。しかし、ユーザによっては異なる切り替え条件を適用したい場合もあると考えられる。これを実現するには、伝送端末１０が独自のＰＦ切替テーブルを保持しておくか、各伝送端末１０の通信ＩＤに対して伝送管理システム５０がそれぞれのＰＦ切替テーブルを保持しておく（伝送端末１０は例えばログイン時にＰＦ切替テーブルを伝送管理システム５０から取得する。）。各伝送端末１０は、自分のＰＦ切替テーブルに基づいて個別に切り替えの是非を判定することでユーザごとに異なる切り替え条件を適用することができる。

しかし、それぞれの伝送端末１０が同じ通信ＰＦに切り替えると判定するとは限らないという不都合が生じる。

そこで、本実施例では、多数決方式で通信ＰＦを切り替えるか否かを決定することで、上記不都合を解消する。

図１０は、伝送端末１０及び伝送管理システム５０の機能ブロック図の一例である。なお、図１０において、図５と同一の符号を付した構成要素については、一度説明した構成要素の説明を省略あるいは相違点についてのみ説明する場合がある。

本実施例では伝送端末１０がＰＦ切替判定部５２を有している。ＰＦ切替判定部５２の機能は実施例１と同様である。また、不揮発性記憶部１０００にはＰＦ切替テーブルにより構成されるＰＦ判定管理ＤＢ５００５が構築されている。ＰＦ切替テーブルの内容も実施例１と同様である。

さらに、本実施例の伝送管理システム５０は多数決判定部５７を有している。多数決判定部５７は、図４に示されているＣＰＵ３０１からの命令等によって実現され、伝送端末１０から通信ＰＦの切り替えのリクエスト（切替要求）を取得した場合に、多数決で通信ＰＦの切り替えを行うかどうかを決定する。

図１１は、伝送管理システム５０が通信ＰＦを切り替えるか否かを判定する手順を示すシーケンス図の一例である。なお、伝送端末１０ａａ、１０ａｂ、１０ａｃはαの通信ＰＦで通信中である。
S1：伝送端末１０ａａの状況変化通知部１８は何らかの通信状況の変化を検出する。例えば、通信帯域の変更、拠点数の変更などである。
S2：伝送端末１０ａａのＰＦ切替判定部５２は自分のＰＦ切替テーブルを参照して通信ＰＦをβに切り替えると判定する。このため、送受信部１１はβの通信ＰＦへの切り替えをリクエストする。
S3：伝送管理システム５０の多数決判定部５７は通信ＰＦを切り替えるか否かを判定する。ここでは、伝送端末１０ａｂ，１０ａｃは通信ＰＦの変更をリクエストしていないので、切り替えないと判定する。
S4：次に、伝送端末１０ａｂの状況変化通知部１８は何らかの通信状況の変化を検出する。例えば、通信帯域の変更、拠点数の変更などである。
S5：伝送端末１０ａｂのＰＦ切替判定部５２は自分のＰＦ切替テーブルを参照して通信ＰＦをγに切り替えると判定する。このため、送受信部１１はγの通信ＰＦへの切り替えをリクエストする。
S6：伝送管理システム５０の多数決判定部５７は通信ＰＦを切り替えるか否かを判定する。ここでは、γへのリクエストは１つしかないので、切り替えないと判定する。
S7：次に、伝送端末１０ａｃの状況変化通知部１８は何らかの通信状況の変化を検出する。例えば、通信帯域の変更、拠点数の変更などである。
S8：伝送端末１０ａｃのＰＦ切替判定部５２は自分のＰＦ切替テーブルを参照して通信ＰＦをβに切り替えると判定する。このため、送受信部１１はβの通信ＰＦへの切り替えをリクエストする。
S9：伝送管理システム５０の多数決判定部５７は、βへのリクエストが２つになりテレビ会議を行っている全端末数の過半数を超えたので、通信ＰＦをβに切り替えると判定する。なお、リクエストの数をカウントする期間を限定してもよいし（例えば、１０分ごとにリクエストの数が初期化される）、会議開始からの全てのリクエストを累積してカウントしてもよい。
S10〜S12：伝送管理システム５０の多数決判定部５７は伝送端末１０ａａ、１０ａｂ、１０ａｃにβの通信ＰＦへのプラットフォーム切替指示通知を送信する。すなわち、図６，７のステップＳ５．２，Ｓ５．３のプラットフォーム切替指示通知を送信する。以降の手順は図６，７と同様である。

これにより、通信の途絶を生じさせずに、伝送端末１０ａａ、１０ａｂ、１０ａｃは通信ＰＦをβに切り替えてテレビ会議を継続できる。

したがって、本実施例の伝送システム１又は通信方法によれば、ユーザごとに別々のＰＦ切替テーブルを用いてそれぞれが通信ＰＦの切り替えをリクエストできると共に、最もリクエストが多い通信ＰＦに切り替えることができる。

なお、多数決による決定の他、会議主催者からのリクエストを優先してもよい。また、通信ＰＦに優先度をつけておきリクエストされた通信ＰＦのうち最も優先度の高いものを選択してもよい。

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

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

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

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

なお、ＰＦ切替判定部５２は判定手段の一例である。通信状況検出部５５は状況検出手段の一例である。セッション管理部５４は通信確立手段の一例である。ＰＦ切替開始判定部５６は通信開始手段の一例である。

１ 伝送システム
２ 通信ネットワーク
１０ 伝送端末
１８ 状況変化通知部
２１ 通信ＰＦ管理部
５０ 伝送管理システム
５２ ＰＦ切替判定部
５４ セッション管理部
５５ 通信状況検出部
５６ ＰＦ切替開始判定部

米国特許第８８３８６９９号明細書

Claims (10)

1. 通信端末と他の通信端末との通信確立を制御する情報処理装置であって、
   複数の通信端末の間で第一セッションによる通信が確立している状態で、前記複数の通信端末の間で第二セッションによる通信を確立させる通信確立手段と、
   前記複数の通信端末の間で前記第二セッションによる通信が確立したことを確認した場合、前記第二セッションを用いた通信を前記複数の通信端末に開始させる通信開始手段と、を有する情報処理装置。
2. 前記第一セッションは第一通信プラットフォームを用いた通信のためのセッションであり、前記第二セッションは第二通信プラットフォームを用いた通信のためのセッションであり、
   前記第一通信プラットフォームを前記第二通信プラットフォームに切り替える際、前記通信開始手段は、前記複数の通信端末の間で前記第二通信プラットフォームを用いた通信が確立したことを確認した場合、前記第二通信プラットフォームを用いた通信を前記複数の通信端末に開始させる請求項１に記載の情報処理装置。
3. 前記通信開始手段は、前記第一通信プラットフォームを用いて通信している全ての通信端末から前記第二通信プラットフォームを用いた通信が確立したという通知を取得することで、前記複数の通信端末の間で前記第二通信プラットフォームを用いた通信が確立したことを確認する請求項２に記載の情報処理装置。
4. 前記複数の通信端末の間で前記第二通信プラットフォームを用いた通信が確立したことを確認した場合、前記通信開始手段は前記複数の通信端末に前記第一通信プラットフォームを用いたデータの通信から、前記第二通信プラットフォームを用いたデータの通信に切り替えさせる請求項２又は３に記載の情報処理装置。
5. 前記通信開始手段は前記複数の通信端末の間で前記第二通信プラットフォームを用いた通信が確立したことを確認した場合、
   前記複数の通信端末の間で確立している前記第一通信プラットフォームによる通信を切断させる請求項２〜４いずれか１項に記載の情報処理装置。
6. 前記複数の通信端末の間の通信状況又は通信端末と前記情報処理装置と間の通信状況を検出する状況検出手段と、
   前記通信状況が変化した場合、前記第一通信プラットフォームから前記第二通信プラットフォームに切り替えると判定する判定手段を有する請求項２〜４のいずれか１項に記載の情報処理装置。
7. 通信端末と他の通信端末とが通信する通信システムであって、
   複数の通信端末の間で第一セッションによる通信が確立している状態で第二セッションによる通信を確立させる通信確立手段と、
   前記複数の通信端末の間で前記第二セッションによる通信が確立したことを確認した場合、前記第二セッションを用いた通信を前記複数の通信端末に開始させる通信開始手段と、を有する通信システム。
8. 通信状況の変化を情報処理装置に対し通知するコンピュータにより実行可能なプログラムと、
   複数の通信端末の間で第一セッションによる通信が確立している状態で第二セッションによる通信を確立させる通信確立手段と、
   前記複数の通信端末の間で前記第二セッションによる通信が確立したことを確認した場合、前記第二セッションを用いた通信を前記複数の通信端末に開始させる通信開始手段と、を有する通信システム。
9. 情報処理装置にインストールされると、前記情報処理装置を、
   複数の通信端末の間で第一セッションによる通信が確立している状態で第二セッションによる通信を確立させる通信確立手段と、
   前記複数の通信端末の間で前記第二セッションによる通信が確立したことを確認した場合、前記第二セッションを用いた通信を前記複数の通信端末に開始させる通信開始手段と、として機能させるプログラム。
10. 通信端末と他の通信端末との通信確立を制御する情報処理装置が行う通信方法であって、
    通信確立手段が、複数の通信端末の間で第一セッションによる通信が確立している状態で、前記複数の通信端末の間で第二セッションによる通信を確立させるステップと、
    通信開始手段が、前記複数の通信端末の間で前記第二セッションによる通信が確立したことを確認した場合、前記第二セッションを用いた通信を前記複数の通信端末に開始させるステップと、を有する通信方法。

Images