JPWO2012056783A1 - コンテンツ共有システム、携帯端末、プロトコル切換方法およびプログラム - Google Patents

Abstract

【課題】端末における電力消費を低減すると共に、サーバリソースの消費を少なく抑制することを可能とするコンテンツ共有システム等を提供する。【解決手段】相互に音声通話およびデータ通信が可能な複数台の端末装置２０と、音声通話を仲介する交換機４０と、データ通信を仲介するコンテンツ共有サーバ１０とが相互に接続されたコンテンツ共有システム１で、端末装置２０が各々、音声通話手段２３と、同一のコンテンツに対する一方のユーザの操作に応じて差分更新コマンドを作成してもう一方の端末装置に送信するコンテンツ共有アプリケーション３２と、第１および第２の通信プロトコルでデータ通信を行う第１および第２の通信制御部３３〜３４と、端末装置の状態に応じて希望プロトコルをコンテンツ共有サーバに送信すると共に決定プロトコルを受信して通信プロトコルをこれに切り替えるプロトコル選択部３７とを有する。【選択図】図１

Description

本発明は、コンテンツ共有システム、携帯端末、プロトコル切換方法およびプログラムに関し、特に電力消費を低減しつつ、サーバリソースの消費を少なく抑制することを可能とするコンテンツ共有システム等に関する。より詳しくは、サーバを介して端末間でコミュニケーションを行うコンテンツ共有システムにおいて、音声通信が開始されたか否かの状態、通信の発生頻度や利用者が要求するリアルタイム性、電池の残存容量などに応じて、通信に利用するプロトコルを（ＭＳＲＰなど、プッシュ型の通信が可能な）第１のプロトコル（ＨＴＴＰなど、ポーリングを必要とする）と、第２のプロトコルとを、動的に切り替えることを可能とするコンテンツ共有システム等に関する。

電池によって動作する携帯電話端末などによるモバイル通信を利用したコンテンツ共有システムでは、通信を行っている当該携帯電話端末同士で、双方に記憶されている同一コンテンツに対して双方の端末からの操作を反映させることが可能である。より具体的には、例えば、文字によるチャットサービスや、掲示板サービス、写真を相互に送付して共有するサービス、写真に相互に手書き文字などの書き込みを行うサービスなどが、当該コンテンツ共有システムによって可能となる。

この種のサービスにおいては特に、１対１または多人数のコミュニケーションで、携帯電話端末を介した双方向操作のリアルタイム性を高めることが求められている。たとえば、端末間で共有される同一コンテンツが写真などのような静止画像である場合に、このコンテンツ共有システムでは、画像に対する一方の端末から行われる手書き文字の書き込みや拡大縮小などの操作を差分更新コマンドとして他方の端末にもリアルタイムに送信し、その操作の結果を他方の端末に記憶された同一コンテンツに反映させる。この差分更新の動作を、リアルタイムに行えるようにすることが求められるが、これには双方の端末がセッション（接続）を確立してこれを維持するか、もしくは定期的なポーリングを高頻度で行う必要がある。

図１９は、既存のコンテンツ共有システム１００１の構成について示す説明図である。コンテンツ共有システム１００１は、端末１０２０ａおよび１０２０ｂ、コンテンツ共有サーバ１０１０、および交換機１０４０が、ネットワーク１００２を介して相互に接続可能なように構成されている。端末１０２０ａおよび１０２０ｂは、より具体的には携帯電話端末、スマートフォン端末、パーソナルコンピュータ端末などである。

端末１０２０ａおよび１０２０ｂは、ネットワーク１００２を介して音声通話とデータ通信とを同時に行うことが可能であり、コンテンツ共有サーバ１０１０は端末間のデータ通信を、交換機１０４０は端末間の音声通話を、それぞれ仲介する。なお、音声通話はデータ通信と同一のネットワーク１００２を使用するものであってもよいし、それとは別の電話網を使用してもよい。

端末１０２０ａおよび１０２０ｂではそれぞれ、コンテンツ共有アプリケーション１０３２が動作し、また同一のデータであるコンテンツ１０３１が双方に記憶されている。コンテンツ１０３１は、たとえば静止画像、動画、音楽、ワープロ文書、スプレッドシートなど、端末１０２０ａおよび１０２０ｂで何らかの操作ができるデータであれば何でもよい。

端末１０２０ａおよび１０２０ｂのうち一方で、ユーザがコンテンツ共有アプリケーション１０３２を介してコンテンツ１０３１に対して何かの操作を行うと、コンテンツ共有アプリケーション１０３２はその操作の内容を示す差分更新コマンドを生成し、この差分更新コマンドを一方の端末からコンテンツ共有サーバ１０１０を介してもう一方の端末に送信する。その結果、一方の端末でコンテンツ１０３１に対して行われた操作の内容は、もう一方の端末に記憶されたコンテンツ１０３１にも反映される。

コンテンツ共有システム１００１では、端末１０２０ａおよび１０２０ｂが相互間で音声通話をしながら、以上で説明した動作を行うことができる。このコンテンツ共有システム１００１は、ＩＭＳ（Internet protocol Multimedia Subsystem）を利用して音声通話とデータ通信とを融合したマルチメディア通信サービスの一例であり、たとえばテレビ会議、ボイスチャットなどのような目的に適用可能である。このようなマルチメディア通信サービスに利用可能な技術の開発は、現在活発に行われている。

これに関連する技術文献として、たとえば次の各々がある。その中でも特許文献１には、ＳＩＰ（Session Initiation Protocol）と「独自プロトコル」との間で相互に通信プロトコルの変換を行うというＳＩＰトンネリング装置が記載されている。特許文献２には、アプリケーションがＨＴＴＰ（HyperText Transfer Protocol）で通信しているデータをデータ取得部が中継する際に、データの種類などの「適切な条件」に応じてこれをＳＩＰに変換するというプロトコル変換装置が記載されている。

特許文献３には、特定の通信方式に対応していない端末にサービスを提供できるよう、あらかじめ定められた優先順位に基づいて使用するプロトコルを切り替えるというＳＩＰアプリケーションサーバなどが記載されている。特許文献４には、ＳＩＰの通信データをＨＴＴＰを使用する端末装置でも利用可能なように変換するというプロトコル変換装置が記載されている。非特許文献１には、ＩＭＳについての既存の技術の概要について記載されている。

特開２００２−２４７１３０号公報 特開２０１０−０５０６１７号公報 特開２０１０−０５６６３２号公報 特許第４２７３８９９号公報

中澤他「ＩＭＳサービス実現のための端末アプリケーションプラットフォーム」、ＯＫＩテクニカルレビュー第２１０号、２００７年４月、沖電気株式会社

図１９に示したコンテンツ共有システム１００１で一般的に使用される通信プロトコルは、主にＨＴＴＰ（HyperText Transfer Protocol）とＳＩＰ（Session Initiation Protocol）という２種類である。ＨＴＴＰは、ネットワーク上のウェブサイトなどで、コンテンツの転送において最も頻繁に使用される通信プロトコルであるが、コンテンツ共有システムにおいても多く利用される。これは、通信を行っている端末１０２０ａおよび１０２０ｂの相互間のセッション（接続）を確立しておく必要がないので、コンテンツ共有サーバ１０１０のサーバリソース（メモリ残量などのサーバ資源）の消費が少ないからである。

ただし、ＨＴＴＰでは一方の端末１０２０ａからもう一方の端末１０２０ｂに直接データを送信する（プッシュ型通信）ことはできない。そのため、端末１０２０ａおよび１０２０ｂは各々、定期的にコンテンツ共有サーバ１０１０に接続して、自分宛の通信の有無を確認する必要がある。これをポーリング（Polling）という。ポーリングを定期的に行う必要があるので、各端末１０２０ａおよび１０２０ｂは、データ通信を行っていない場合にも定常的に電力を消費することになる。

一方、ＳＩＰは、テレビ会議やインターネット電話などのような用途に多く使われる通信プロトコルである。ＳＩＰでは、一方の端末１０２０ａからもう一方の端末１０２０ｂに、ＭＳＲＰ（Message Session Relay Protocol）などのようなプッシュ型通信を利用して、直接データを送信することができるので、定期的なポーリングを行う必要はない。

従って、ＳＩＰを利用すれば、各端末１０２０ａおよび１０２０ｂの電力消費は、ＨＴＴＰの場合と比べて少なく済む。そのかわり、コンテンツ共有サーバ１０１０内で、各端末１０２０ａおよび１０２０ｂの相互間のセッションを確立しておく必要があるので、サーバリソースを多量に消費する。

一方、上記のコンテンツ共有システム１００１では、各端末１０２０ａおよび１０２０ｂの消費電力を低く抑える必要があるのはもちろん、なるべく多くの端末が通信に参加できるよう、コンテンツ共有サーバ１０１０のサーバリソースの消費も可能な限り少なく抑えることが望ましい。その意味で、ＳＩＰとＨＴＴＰは、端末における消費電力およびコンテンツ共有サーバにおけるサーバリソースの消費において、両立が難しいトレードオフの関係にある。

しかしながら、前述した特許文献１〜４、および非特許文献１には、端末における消費電力およびコンテンツ共有サーバにおけるサーバリソースの消費の両方を低減することを可能にする技術は記載されていない。特許文献１〜２、および特許文献４に記載されている技術は、プロトコルの「変換」であり、プロトコルの「切換」ではないので、通信プロトコルを切り替えて消費電力やサーバリソースの消費を抑制することはできない。

プロトコルの「切換」については特許文献３に記載されているが、これは「優先度」に応じてプロトコルを切り替えるというものであり、差分更新コマンドの発生する頻度に応じて切り替えるものではない。さらに、この技術は消費電力を抑制するものでもない。

本発明の目的は、端末における消費電力を低減すると共に、サーバリソースを有効に利用することを可能とする、コンテンツ共有システム、携帯端末、プロトコル切換方法およびプログラムを提供することにある。

上記目的を達成するため、本発明に係るコンテンツ共有システムは、相互に音声通話およびデータ通信が可能な複数台の端末装置と、端末装置相互間の音声通話を仲介する交換機と、端末装置相互間のデータ通信を仲介するコンテンツ共有サーバとが相互に接続されて構成されるコンテンツ共有システムであって、端末装置が各々、音声通話を行う音声通話手段と、双方の内部に記憶された同一のコンテンツに対する一方の端末装置でのユーザの操作に応じて該操作の内容を他方の端末装置上の同一コンテンツに反映させるための差分更新コマンドを作成すると共にこれをもう一方の端末装置に送信するコンテンツ共有アプリケーションと、第１および第２の通信プロトコルのうちいずれか一方でデータ通信を行う第１および第２の通信制御部と、各端末装置の状態に応じて第１および第２の通信プロトコルのうちのいずれか一方を選択してこれを希望プロトコルとしてコンテンツ共有サーバに送信すると共に、コンテンツ共有サーバから受信した決定プロトコルを通信プロトコルとして採用するプロトコル選択部と、を有することを特徴とする。

上記目的を達成するため、本発明に係る携帯端末は、音声通話およびデータ通信が可能であり、かつ他装置との音声通話を仲介する交換機および他装置とのデータ通信を仲介するコンテンツ共有サーバと相互に接続されてコンテンツ共有システムを構成する端末装置であって、音声通話を行う音声通話手段と、内部に記憶されたコンテンツに対するユーザの操作に応じて該操作の内容を他装置上の同一コンテンツに反映させるため差分更新コマンドを作成すると共にこれを他装置に送信するコンテンツ共有アプリケーションと、第１および第２の通信プロトコルのうちいずれか一方でデータ通信を行う第１および第２の通信制御部と、自らの状態に応じて第１および第２の通信プロトコルのうちのいずれか一方を選択してこれを希望プロトコルとしてコンテンツ共有サーバに送信すると共に、コンテンツ共有サーバから受信した決定プロトコルを通信プロトコルとして採用するプロトコル選択部と、を有することを特徴とする。

上記目的を達成するため、本発明に係るプロトコル切換方法は、相互に音声通話およびデータ通信が可能な複数台の端末装置と、交換機と、コンテンツ共有サーバとが相互に接続されて構成されるコンテンツ共有システムにあって、同一のコンテンツが双方の端末装置内部に予め記憶されており、端末装置相互間の音声通話を交換機が仲介し、端末装置相互間のデータ通信をコンテンツ共有サーバが仲介し、一方の端末装置で、コンテンツに対するユーザの操作に応じて該操作の内容を他の端末装置上の同一コンテンツに反映させるための差分更新コマンドをコンテンツ共有アプリケーションが作成し且つこれを他の端末装置に送信し、一方の端末装置で、端末装置の状態に応じて第１および第２の通信プロトコルのうちのいずれでデータ通信を行うかをプロトコル選択部が選択してこれを希望プロトコルとしてコンテンツ共有サーバに送信し、全ての端末装置から受信した希望プロトコルの中からコンテンツ共有サーバのプロトコル決定部が決定プロトコルを決定すると共にこれを全ての端末装置に送信し、全ての端末装置で、コンテンツ共有サーバから決定プロトコルをプロトコル選択部が受信すると共にこの決定プロトコルを通信プロトコルとして採用することを特徴とする。

上記目的を達成するため、本発明に係るプロトコル切換プログラムは、相互に音声通話およびデータ通信が可能な複数台の端末装置と、交換機と、コンテンツ共有サーバとが相互に接続されて構成されるコンテンツ共有システムにあって、端末装置の各々が備えるコンピュータに、他の端末装置と同一のコンテンツを予め記憶する手順、コンテンツに対するユーザの操作に応じて他の端末装置上の同一コンテンツに反映させるための差分更新コマンドを作成し且つこれを他の端末装置に送信する手順、端末装置の状態に応じて第１および第２の通信プロトコルのうちのいずれでデータ通信を行うかを選択してこれを希望プロトコルとしてコンテンツ共有サーバに送信する手順、およびコンテンツ共有サーバから決定プロトコルを受信すると共にこの決定プロトコルを通信プロトコルとして採用する手順を実行させることを特徴とする。

本発明は、上述した通り、端末装置の状態に応じて第１および第２の通信プロトコルのうちのいずれでデータ通信を行うかを選択してこのプロトコルで通信を行うように構成したので、通信などの状態に応じて最適なプロトコルを選択できる。これによって、端末における消費電力を低減すると共に、サーバリソースを有効に利用することが可能であるという、優れた特徴を持つコンテンツ共有システム、携帯端末、プロトコル切換方法およびプログラムを提供することができる。

図２に示した携帯電話端末のより詳細な構成について示す説明図である。 本発明の第１の実施形態に係るコンテンツ共有システムの構成について示す説明図である。 図２に示したプロトコル選択データの内容の一例について示す説明図である。 図１〜図２に示した携帯電話端末の、コンテンツ共有の際の動作について示すフローチャートである。 図２に示したコンテンツ共有サーバおよび交換機のより詳しい構成について示す説明図である。図５（Ａ）はコンテンツ共有サーバ、図５（Ｂ）は交換機について各々示す。 図５（Ａ）に示したプロトコル決定データの内容の一例について示す説明図である。 図５（Ａ）に示したプロトコル決定部の動作について示すフローチャートである。 図１に示したコンテンツ共有システムで、携帯電話端末が同一のコンテンツを共有している場合の音声通話と連携してのプロトコル切換の動作の一例について示す説明図である。 図１に示したコンテンツ共有システムで、携帯電話端末が同一のコンテンツを共有している場合の、コンテンツに対する更新頻度に連動してのプロトコル切換の動作の一例について示す説明図である。 図１に示したコンテンツ共有システムで、携帯電話端末が同一のコンテンツを共有している場合の、一方の携帯電話端末の電源状態に連動してのプロトコル切換の動作の一例について示す説明図である。 本発明の第２の実施形態に係るコンテンツ共有システムの構成について示す説明図である。 図１１で示したコンテンツ共有サーバおよび交換機の構成について示す説明図である。 図１１で示したノートＰＣおよび電話機の構成について示す説明図である。図１３（Ａ）はノートＰＣ、図１３（Ｂ）は電話機について各々示す。 図１１に示したコンテンツ共有システムで、ノートＰＣが同一のコンテンツを共有している場合の、電話器間の通話状態を取得する動作の一例について示す説明図である。 本発明の第３の実施形態に係るコンテンツ共有システムの構成について示す説明図である。 図１５で説明したコンテンツ共有サーバのより詳細な構成について示す説明図である。 図１６で説明したプロトコル決定データの内容の一例について示す説明図である。 図１６で説明したプロトコル決定部の動作について示すフローチャートである。 既存のコンテンツ共有システムの構成について示す説明図である。

（第１の実施形態）
以下、本発明の第１の実施形態の構成について添付図１〜２、および５に基づいて説明する。
最初に、本実施形態の基本的な内容について説明し、その後でより具体的な内容について説明する。
本実施形態に係るコンテンツ共有システム１は、相互に音声通話およびデータ通信が可能な複数台の端末装置２０と、端末装置相互間の音声通話を仲介する交換機４０と、端末装置相互間のデータ通信を仲介するコンテンツ共有サーバ１０とが相互に接続されて構成されるコンテンツ共有システムである。端末装置（携帯電話端末２０）は各々、音声通話を行う音声通話手段２３と、双方の内部に記憶された同一のコンテンツに対する一方の端末装置でのユーザの操作に応じて該操作の内容を他方の端末装置上の同一コンテンツに反映させるための差分更新コマンドを作成すると共にこれをもう一方の端末装置に送信するコンテンツ共有アプリケーション（共有ＡＰ３２）と、第１および第２の通信プロトコルのうちいずれか一方でデータ通信を行う第１および第２の通信制御部（ＳＩＰ通信制御部３３、ＨＴＴＰ差分更新通信制御部３４）と、各端末装置の状態に応じて第１および第２の通信プロトコルのうちのいずれか一方を選択してこれを希望プロトコルとしてコンテンツ共有サーバに送信すると共に、コンテンツ共有サーバから受信した決定プロトコルを通信プロトコルとして採用するプロトコル選択部３７とを有する。

ここで、端末装置（携帯電話端末２０）のプロトコル選択部３７は、音声通話が開始もしくは終了したことを検出して第１および第２の通信プロトコルのうちのいずれか一方の選択を行う。より具体的には、音声通話が開始した場合に第１の通信プロトコルを選択し、音声通話が終了した場合に第２の通信プロトコルを選択する。

また、端末装置（携帯電話端末２０）のプロトコル選択部３７は、コンテンツ共有アプリケーション（共有ＡＰ３２）による差分更新コマンドの送信頻度を検出して第１および第２の通信プロトコルのうちのいずれか一方の選択を行う。より具体的には、差分更新コマンドの送信頻度が予め与えられた閾値より高い場合に第１の通信プロトコルを選択し、差分更新コマンドの送信頻度が閾値より低い場合に第２の通信プロトコルを選択する。

そして、端末装置（携帯電話端末２０）のプロトコル選択部３７は、自らに備えられた電源装置（電力供給手段２６）内部の電池（充電池２６ａ）の残量を検出して第１および第２の通信プロトコルのうちのいずれか一方の選択を行う。より具体的には、電池の残量が予め与えられた閾値より低い場合に第１の通信プロトコルを選択し、電池の残量が閾値より高い場合、もしくは端末装置が商用電源（ＡＣアダプタ２６ｂ）に接続されている場合に第２の通信プロトコルを選択する。

一方のコンテンツ共有サーバ１０は、第１および第２の通信プロトコルによる端末装置相互間のデータ通信を仲介する第１および第２の通信仲介部（ＳＩＰ通信仲介部５１、ＨＴＴＰ通信仲介部５２）と、端末装置から希望プロトコルを受信し、全ての各端末装置の希望プロトコルの中から決定プロトコルを決定してこれを全ての各端末装置に送信するプロトコル決定部５３を有する。ここで、第１および第２の通信プロトコルとは、各々ＳＩＰ（Session Initiation Protocol）およびＨＴＴＰ（HyperText Transfer Protocol）である。

以上の構成を備えることにより、コンテンツ共有システム１は端末装置（携帯電話端末２０）の状態に応じて通信プロトコルを切り替えることができ、これによって端末における電力消費を低減すると共に、サーバリソースの消費を少なく抑制することが可能となる。
以下、これをより詳細に説明する。

図２は、本発明の第１の実施形態に係るコンテンツ共有システム１の構成について示す説明図である。コンテンツ共有システム１は、複数台の携帯電話端末２０ａ、２０ｂ、２０ｃ…の各々が、音声通話用の交換機４０およびデータ通信用のコンテンツ共有サーバ１０に無線通信を含む公衆通信網２で接続可能なように構成されている。携帯電話端末は何台であってもよいが、ここでは説明を平易にするため、携帯電話端末２０ａおよび２０ｂの２台に注目する。

もちろん、各々の携帯電話端末２０ａ、２０ｂ、２０ｃ…を、携帯電話以外の種類の端末（たとえばスマートフォン端末、パーソナルコンピュータ端末など）に置換することも可能であるし、また種類の異なる端末が混在していてもよい。

携帯電話端末２０ａおよび２０ｂは、交換機４０を介して音声通話をしつつ、コンテンツ共有サーバ１０を介してウェブページ、写真、音楽、動画、ワープロ文書、スプレッドシートなどのようなコンテンツへの操作を共有することができる。

携帯電話端末２０ａおよび２０ｂには各々同一のコンテンツが保存されていて、携帯電話端末２０ａの操作者が該コンテンツに対して何らかの操作を行うと、その操作の内容が差分更新コマンドとして携帯電話端末２０ｂにも送信され、携帯電話端末２０ｂ側の同一コンテンツにもその操作の内容が反映される。携帯電話端末２０ｂの側からも、該コンテンツに対して同様の操作が可能である。

コンテンツ共有サーバ１０は、ＳＩＰサーバとしての機能とＨＴＴＰサーバの機能としての機能とを併せ持つ。そのため、携帯電話端末２０ａもしくは２０ｂとコンテンツ共有サーバ１０の間は、ＳＩＰとＨＴＴＰという２種類のプロトコルのいずれでも接続可能である。

ＳＩＰを利用した接続の場合、コンテンツに対する操作の内容を一方の携帯電話端末から他方に中継する場合には、データを他方の携帯電話端末に送信できるプッシュ型のプロトコルであるＭＳＲＰを利用することができる。

しかしながら、ＨＴＴＰを利用した接続の場合には、ＨＴＴＰはプッシュ型のプロトコルではないので、データを他方に送信することができない。このため、数秒〜数分程度の予め定められた間隔で端末からサーバに対して問い合わせを行い、端末に送るべき操作データがサーバに存在するかを確認する必要がある。このような通信をポーリング（polling）という。

携帯電話端末２０ａおよび２０ｂとの間の音声通話は、任意の方式を利用することができる。たとえば、データ通信を利用しない回線接続型の通話であってもよいし、またＳＩＰを利用したＶｏＩＰ（Voice Over Intenet Protocol）であってもよい。

（携帯電話端末の構成と動作）
図１は、図２に示した携帯電話端末２０ａおよび２０ｂのより詳細な構成について示す説明図である。携帯電話端末２０ａ、２０ｂ、および２０ｃ以降…は全て同一の構成を有するので、これらを総称して携帯電話端末２０という。携帯電話端末２０は、コンピュータとしての基本的な構成と、音声通話に必要な構成とを有している。

即ち、携帯電話端末２０は、コンピュータプログラムを実行する主体となる主演算制御手段（ＣＰＵ: Central Processing Unit）２１と、データを記憶する記憶手段２２と、他の携帯電話端末との間で音声通話を行う音声通話手段２３と、他の携帯電話端末との間でデータ通信を行うデータ通信手段２４と、ユーザからの操作を受け付け、またユーザに処理結果を提示する入出力手段２５と、以上の各部に動作に必要な電力を供給する電力供給手段２６を備える。

電力供給手段２６は、充電池２６ａを内蔵し、また商用交流電源を携帯電話端末２０が動作可能な直流に変換するＡＣアダプタ２６ｂを着脱可能である。ＡＣアダプタ２６ｂが電力供給手段２６に接続されている間は、携帯電話端末２０はＡＣアダプタ２６ｂから供給される直流で動作すると同時に、充電池２６ａもこの直流によって充電される。

主演算制御手段２１では、音声通話制御部３１、コンテンツ共有アプリケーション３２、ＳＩＰ通信制御部３３、ＨＴＴＰ差分更新通信制御部３４、通信頻度計測部３５、電源状態確認部３６、およびプロトコル選択部３７が、各々コンピュータプログラムとして後述するそれぞれの機能を実行されるように構成されている。また、記憶手段２２には、携帯電話端末２０が現在行っている通信の状況を示すデータであるプロトコル選択データ３８と、携帯電話端末２０ａおよび２０ｂが共有する対象であるコンテンツ３９が記憶されている。この詳細についても後述する。

音声通話制御部３１は、音声通話手段２３を制御して、各々の携帯電話端末２０の相互間での交換機４０を介した音声通話の動作を行わせる。また音声通話制御部３１は、通話セッション情報を音声通話手段２３もしくはコンテンツ共有サーバ１０から取得して、これを後述の通話状況３８ａとしてプロトコル選択データ３８に記録する機能を持つ。

コンテンツ共有アプリケーション３２（以後共有ＡＰ３２という）は、ウェブページ、写真、音楽、動画、ワープロ文書、スプレッドシートなどのようなコンテンツ３９を複数の端末間でリアルタイムに共有するためのアプリケーションである。コンテンツ３９は携帯電話端末２０ａおよび２０ｂのうちの少なくとも一方に予め記憶されていて、他方に同一のコンテンツ３９が無い場合には操作が開始される際に送付される。即ち、携帯電話端末２０ａおよび２０ｂの双方に同一のコンテンツ３９が記憶されていることが、本発明の動作の前提となる。

ここでいう「リアルタイム」とは、コンテンツ３９を一方から他方に送付して携帯電話端末２０ａおよび２０ｂの両方に記憶するというだけではなく、送付後も携帯電話端末２０ａおよび２０ｂ間での音声通話およびデータ通信を継続し、コンテンツ３９に対して一方のユーザが行った操作が他方の携帯電話端末２０上のコンテンツ３９にも即時に反映されるということを意味する。

コンテンツ３９に対して（入出力手段２５を介して）ユーザが行う操作とは、より具体的に言うなら、たとえばコンテンツ３９が静止画像である場合には、これに対する文字や描画データの書き込み、画面サイズの変更、表示位置の移動、ページめくりなどである。また、コンテンツ３９が動画である場合には、これに対する再生、停止、巻き戻しなどである。

さらに、コンテンツ３９がウェブページである場合には、これに対するＵＲＬの変更、スクロール、テキストボックスへの書き込み、ボタンの押下などである。コンテンツ３９がワープロ文書やスプレッドシートである場合には、これに対する文章やグラフなどの編集、コメントの追加、画面表示の移動、カーソルの移動などである。

共有ＡＰ３２は、継続した通信を通じてこの操作の内容をコンテンツ共有サーバ１０を介して対抗の端末に送信するために、ユーザの操作内容に応じて差分更新コマンドを生成してプロトコル選択部３７に送付する。また、プロトコル選択部３７を介して他端末から受信した差分更新コマンドを受け取り、その内容を入出力手段２５に表示されている共有ＡＰ３２の画面に反映させる。さらに、共有ＡＰ３２は音声通話中には、その音声通話の相手とコンテンツ３９を共有するために、音声通話制御部３１と連動して対向端末を決定する。

ここで、差分更新コマンドは、入出力手段２５を介してのユーザの操作によって発生するものであるので、この差分更新コマンドが発生するタイミングは不定期的である。たとえばユーザがコンテンツ３９に対する書き込み操作に夢中になっている状態では連続して差分更新コマンドが発生するが、画面に見入っている状態では発生の頻度が低下する、などのような特性がある。

ＳＩＰ通信制御部３３は、プロトコル選択部３７に渡された差分更新コマンドをＭＳＲＰ（Message Session Relay Protocol）などのようなプッシュ型プロトコルを利用して、データ通信手段２４を介してコンテンツ共有サーバ１０に送信する。また逆に、コンテンツ共有サーバ１０から（データ通信手段２４を介して）プッシュ型プロトコルで送られて来た差分更新コマンドをプロトコル選択部３７に渡す。

ＳＩＰ通信制御部３３は、コンテンツ共有サーバ１０を経由して、音声通話と同一の端末を通信相手として接続する。ＭＳＲＰを利用することで、差分更新コマンドを相手の端末に即座に送信することができ、即時性が高く、データの送受信の頻度が少ない場合には電力の消費が少ないという利点がある。ただし、通信を行う携帯電話端末２０ａおよび２０ｂは、通信に先立って相互にセッションを確立する必要がある。このため、コンテンツ共有サーバ１０のサーバリソースを多量に消費する。

ＨＴＴＰ差分更新通信制御部３４は、プロトコル選択部３７に渡された差分更新コマンドを、ＨＴＴＰのポーリングのプロトコルを利用して、データ通信手段２４を介してコンテンツ共有サーバ１０に送信する。また逆に、コンテンツ共有サーバ１０から（データ通信手段２４を介して）ＨＴＴＰのポーリングのタイミングで送られて来た差分更新コマンドをプロトコル選択部３７に渡す。

ＨＴＴＰ差分更新通信制御部３４は、コンテンツ共有サーバ１０を経由して、音声通話と同一の端末を通信相手として接続する。ＨＴＴＰを利用することで、ＳＩＰサーバのリソースを消費することなく、ベストエフォートな通信ができる。このため通信コストが少なく済み、かつＳＩＰの機能がない端末からでも利用できるという利点がある。一方で、ポーリングの動作のために定期的なデータ通信が発生する。このため、定常的に電力を消費する。

通信頻度計測部３５は、携帯電話端末２０が一定時間内に送信する差分更新コマンドの回数が所定の閾値より「高い」か「低い」を、共有ＡＰ３２から取得して後述の更新頻度３８ｄとして後述のプロトコル選択データ３８に記録する。

電源状態確認部３６は、電力供給手段２６内部の充電池２６ａの残量が所定の閾値より「高い」か「低い」か、およびＡＣアダプタ２６ｂが携帯電話端末２０に「接続されている」か「接続されていない」かを電力供給手段２６から取得し、後述の電池残量３８ｂおよび充電器接続３８ｃとして後述のプロトコル選択データ３８に記録する。

プロトコル選択部３７は、対向端末との通信に際して使用する通信プロトコルを決定し、そのプロトコルに応じて、共有ＡＰ３２から送信された差分更新コマンドをＳＩＰ通信制御部３３およびＨＴＴＰ差分更新通信制御部３４のいずれかに渡す。また逆にＳＩＰ通信制御部３３またはＨＴＴＰ差分更新通信制御部３４から送られて来た差分更新コマンドを共有ＡＰ３２に渡す。

プロトコル選択部３７は、利用する通信プロトコルを決定するため、プロトコル選択データ３８に記憶された情報を利用する。図３は、図２に示したプロトコル選択データ３８の内容の一例について示す説明図である。プロトコル選択データ３８は、通話状況３８ａ、電池残量３８ｂ、充電器接続３８ｃ、更新頻度３８ｄ、および希望プロトコル３８ｅの各データを含む。

通話状況３８ａは、音声通話の状況が「通話中」であるかもしくは「待機中」であるかを示す２値データであり、音声通話制御部３１が音声通話手段２３から取得する通話セッション情報から判定してプロトコル選択データ３８に記録する。

電池残量３８ｂは、電力供給手段２６内部の充電池２６ａの残量が所定の閾値より「高い」か「低い」かを示す２値データであり、電力供給手段２６から電源状態確認部３６が取得してプロトコル選択データ３８に記録する。

充電器接続３８ｃは、ＡＣアダプタ２６ｂが携帯電話端末２０に「接続されている」か「接続されていない」かを示す２値データであり、電力供給手段２６から電源状態確認部３６が取得してプロトコル選択データ３８に記録する。充電器接続３８ｃが「接続されている」状態であれば、自動的に電池残量３８ｂは「高い」状態となる。

更新頻度３８ｄは、携帯電話端末２０が一定時間内に送信する差分更新コマンドの回数が所定の閾値より「高い」か「低い」を示す２値データであり、通信頻度計測部３５が共有ＡＰ３２から取得してプロトコル選択データ３８に記録する。そして希望プロトコル３８ｅは、通話状況３８ａ、電池残量３８ｂ、充電器接続３８ｃ、更新頻度３８ｄの各々の情報から各々の携帯電話端末２０ごとにプロトコル選択部３７が決定する通信プロトコルであり、ＳＩＰまたはＨＴＴＰのうちいずれかである。

プロトコル選択部３７は、通話状況３８ａが「待機中」であれば、希望プロトコル３８ｅとして「ＨＴＴＰ」を選択する。通話状況３８ａが「通話中」であれば、希望プロトコル３８ｅを「ＳＩＰ」と「ＨＴＴＰ」のいずれを選択してもよい。

プロトコル選択部３７は、通話を開始した直後の初期状態における希望プロトコル３８ｅは、ユーザの初期設定に応じて「ＳＩＰ」と「ＨＴＴＰ」のいずれかを選択する。そしてプロトコル選択部３７は、通信中に電池残量３８ｂと更新頻度３８ｄに応じて通信プロトコルを切換が可能である。電池残量３８ｂが「低い」場合、もしくは更新頻度３８ｄが「高い」場合には希望プロトコルを「ＳＩＰ」に決定する。それ以外の場合、即ち電池残量３８ｂが「高い」場合でかつ更新頻度３８ｄが「低い」には希望プロトコルを「ＨＴＴＰ」に決定する。

各々の携帯電話端末２０ごとに決定された希望プロトコル３８ｅは、現在利用している通信プロトコルを利用してコンテンツ共有サーバ１０に送られる。そしてプロトコル選択部３７は、コンテンツ共有サーバ１０の側で決定された通信プロトコルである決定プロトコルを受信して、これを最終的に採用する通信プロトコルとし、このプロトコルで通信を行う。

即ち、通信を行う相互の携帯電話端末２０は、コンテンツ共有サーバ１０で決定した同一の決定プロトコルを受信して、これによって同一のプロトコルを選択して通信を行う。通信経路上でプロトコルを変換する構成は特にないので、通信を行う相互の携帯電話端末２０は必ず、同時に同一のプロトコルを選択する必要がある。

図４は、図１〜図２に示した携帯電話端末２０の、コンテンツ共有の際の動作について示すフローチャートである。まず共有ＡＰ３２が起動して携帯電話端末２０ａおよび２０ｂでの通信を確立させ（ステップＳ１０１）、コンテンツ３９を一方の携帯電話端末２０から他方の携帯電話端末２０に送付し、双方に同一のコンテンツ３９が記憶されている状態とする。

そして音声通話制御部３１が、携帯電話端末２０ａおよび２０ｂ相互間での音声通話を開始する（ステップＳ１０２）。これで携帯電話端末２０ａおよび２０ｂは、相互間でコンテンツ３９を共有して操作することが可能となる。

ここで、コンテンツ共有サーバ１０から決定プロトコルを受信した場合（ステップＳ１０３がイエス）、プロトコル選択部３７はこれに応じて通信プロトコルの切換を行う（ステップＳ１０４）。決定プロトコルを受信しない場合（ステップＳ１０３がノー）はそのままステップＳ１０５の処理に進む。

そして、プロトコル選択部３７はプロトコル選択データ３８の通話状況３８ａ、電池残量３８ｂ、充電器接続３８ｃ、更新頻度３８ｄの各データを監視し、通信プロトコルの切換が必要か否かを判断する（ステップＳ１０５）。より具体的には、電池残量３８ｂが「低い」場合、もしくは更新頻度３８ｄが「高い」場合には希望プロトコル３８ｅは「ＳＩＰ」となる。にそれ以外の場合、即ち電池残量３８ｂが「高い」場合でかつ更新頻度３８ｄが「低い」には希望プロトコル３８ｅは「ＨＴＴＰ」となる。この選択基準で決定される希望プロトコル３８ｅが、現在の通信で使用されている通信プロトコルと異なっていれば、通信プロトコルの切換が必要であるということになる。

通信プロトコルの切換が必要な場合（ステップＳ１０５がイエス）には、これをプロトコル選択データ３８に記憶すると共に、希望プロトコル３８ｅをコンテンツ共有サーバ１０を介して他の携帯電話端末２０に送信し（ステップＳ１０６）、そしてコンテンツ共有サーバ１０から決定プロトコルを受信した（即ち、相手側の端末にも決定プロトコルが送信された）ことを確認してから（ステップＳ１０７）この決定プロトコルを自らの通信に使用する通信プロトコルとする（ステップＳ１０８）。以後、このステップＳ１０３〜１０８の動作を繰り返す。

（コンテンツ共有サーバおよび交換機の構成と動作）
図５は、図２に示したコンテンツ共有サーバ１０および交換機４０のより詳しい構成について示す説明図である。図５（Ａ）はコンテンツ共有サーバ１０、図５（Ｂ）は交換機４０について各々示す。図５（Ａ）に示したコンテンツ共有サーバ１０は、コンピュータとしての基本的な構成を有している。即ち、コンテンツ共有サーバ１０、コンピュータプログラムを実行する主体となる主演算制御手段（ＣＰＵ: Central Processing Unit）１１と、データを記憶する記憶手段１２と、他の携帯電話端末との間でデータ通信を行うデータ通信手段１３とを備える。

主演算制御手段１１では、データ通信手段１３を介して各々の携帯電話端末２０のＳＩＰによる通信を仲介するＳＩＰ通信仲介部５１、データ通信手段１３を介して各々の携帯電話端末２０のＨＴＴＰによる通信を仲介するＨＴＴＰ通信仲介部５２、各々の携帯電話端末２０とＳＩＰとＨＴＴＰのいずれのプロトコルで通信を行うかを決定するプロトコル決定部５３が、各々コンピュータプログラムとしてそれぞれの機能を実行されるように構成されている。また、記憶手段１２には、各々の携帯電話端末２０が現在行っている通信の状況を示すデータであるプロトコル決定データ５４が記憶されている。

ＳＩＰ通信仲介部５１およびＨＴＴＰ通信仲介部５２は、各々の通信プロトコルによって、一方の携帯電話端末２０から送られる通信データ（差分更新コマンドなど）を他方の携帯電話端末２０に中継する。プロトコル決定部５３は、現在通信を行っている各々の携帯電話端末２０から希望プロトコル３８ｅを受信し、これをプロトコル決定データ５４として記憶する。そしてプロトコル決定部５３は、実際に通信に使用するプロトコルを決定して、これを決定プロトコルとして当該携帯電話端末２０に通知し、またプロトコル決定データ５４に記憶する。

図５（Ｂ）に示した交換機４０は、携帯電話端末２０相互間の音声通話を交換して仲介する交換手段４０ａを備える。本実施形態では、交換手段４０ａはコンテンツ共有サーバ１０と連携して動作する必要は特にない。

図６は、図５（Ａ）に示したプロトコル決定データ５４の内容の一例について示す説明図である。図６に示す例では、図１に示した携帯電話端末２０ａおよび２０ｂが現在通信を行っている状態を示している。この場合、プロトコル決定データ５４は、携帯電話端末２０ａの希望プロトコル５４ａと、携帯電話端末２０ｂの希望プロトコル５４ｂと、そこからプロトコル決定部５３が決定した決定プロトコル５４ｃが含まれる。

図７は、図５（Ａ）に示したプロトコル決定部５３の動作について示すフローチャートである。プロトコル決定部５３は、現在通信を行っている一方の携帯電話端末２０から希望プロトコル３８ｅを受信した場合に（ステップＳ２０１がイエス）、それを該携帯電話端末２０およびこれと通信している対象の携帯電話端末２０に決定プロトコル５４ｃとして送信する（ステップＳ２０２）。これと同時に、プロトコル決定部５３は、プロトコル決定データ５４にも希望プロトコル５４ａまたは５４ｂ、および決定プロトコル５４ｃを記憶する。

本実施例では、一方の携帯電話端末２０が希望プロトコル３８ｅを送信した場合、それが自動的に決定プロトコル５４ｃとなって他方の携帯電話端末２０に送信される。３つ以上の携帯電話端末２０が同時に音声通話しつつ同一のコンテンツ３９を共有している場合については後述する。

（プロトコル切換の動作）
図８は、図１に示したコンテンツ共有システム１で、携帯電話端末２０ａおよび２０ｂが同一のコンテンツ３９を共有している場合の音声通話と連携してのプロトコル切換の動作の一例について示す説明図である。まず一方の携帯電話端末２０ａで、共有ＡＰ３２を起動して待機状態とする（ステップＳ３０１、図４のステップＳ１０１に該当）。これと並行して、もう一方の携帯電話端末２０ｂでも、共有ＡＰ３２を起動して待機状態とする（ステップＳ３１１、図４のステップＳ１０１に該当）。

携帯電話端末２０ａおよび２０ｂのうち一方にのみ共有対象となるコンテンツ３９が存在し、もう一方に同一のコンテンツ３９が存在しない場合には、一方から他方にコンテンツ３９が送信され、双方に同一のコンテンツ３９が記憶されている状態となる。これは、共有ＡＰ３２が動作している間であれば図８の工程中のどのタイミングで行われてもよい動作であるので、音声通話などの状態の変化とは特に関係なく行われることができる。従って、図８にはこの動作について図示していない。後述の図９および図１０についても同様である。

ステップＳ３０１および３１１では、音声通話が行われていないので、通話状況３８ａは「待機中」となり、選択されるプロトコルは「ＨＴＴＰ」となる。ここで、コンテンツ共有サーバ１０で、プロトコル決定データ５４として登録されている双方の希望プロトコル５４ａおよび５４ｂ、そして決定プロトコル５４ｃの初期値は「ＨＴＴＰ」である。

一方の携帯電話端末２０ａで、音声通話制御部３１がもう一方の携帯電話端末２０ｂを呼び出して音声通話を開始しようとする（ステップＳ３０２、図４のステップＳ１０２に該当）。もう一方の携帯電話端末２０ｂがこの呼び出しに応じれば音声通話が開始される（ステップＳ３１２、図４のステップＳ１０２に該当）。

ここで、共有ＡＰ３２の通話開始時の初期状態として希望プロトコル３８ｅ＝「ＳＩＰ」が設定されていた場合、現在選択されている通信のプロトコル「ＨＴＴＰ」はこの希望プロトコル３８ｅと異なるので、一方の携帯電話端末２０ａで図４のステップＳ１０５がイエス、即ち「通信プロトコルの切換が必要」と判断される。この判断は、携帯電話端末２０ｂの側で行われてもよい。

このため、一方の携帯電話端末２０ａから、希望プロトコル３８ｅ＝「ＳＩＰ」がコンテンツ共有サーバ１０に送信される（ステップＳ３０３、図４のステップＳ１０６に該当）。これを受けたコンテンツ共有サーバ１０では、この携帯電話端末２０ａの希望プロトコル３８ｅ（５４ａ）＝「ＳＩＰ」を決定プロトコル５４ｃとして、携帯電話端末２０ａおよび２０ｂの双方に送信する（ステップＳ３２１、図７のステップＳ２０２に該当）。

決定プロトコル５４ｃ＝「ＳＩＰ」を受けた携帯電話端末２０ａは（ステップＳ３０４、図４のステップＳ１０７に該当）、これに反応して通信プロトコルを「ＳＩＰ」に切り替える（ステップＳ３０５、図４のステップＳ１０８に該当）。そして決定プロトコル５４ｃ＝「ＳＩＰ」を受けた携帯電話端末２０ｂも（ステップＳ３１４、図４のステップＳ１０３に該当）、これに反応して通信プロトコルを「ＳＩＰ」に切り替える（ステップＳ３１５、図４のステップＳ１０４に該当）。

携帯電話端末２０ａおよび２０ｂの間で音声通話が終了すると（ステップＳ３０６および３１６）、双方の端末で通話状況３８ａは「待機中」に戻るので、現在行われている通信のプロトコル「ＳＩＰ」はこの希望プロトコル３８ｅと異なるので、一方の携帯電話端末２０ａで図４のステップＳ１０５がイエス、即ち「通信プロトコルの（ＨＴＴＰへの）切換が必要」と判断される。

このため、双方の携帯電話端末２０ａおよび２０ｂから、希望プロトコル３８ｅ＝「ＨＴＴＰ」がコンテンツ共有サーバ１０に送信される（ステップＳ３０７および３１７）。これを受けたコンテンツ共有サーバ１０では、この携帯電話端末２０ａの希望プロトコル３８ｅ（５４ａおよび５４ｂ）＝「ＨＴＴＰ」を決定プロトコル５４ｃとして、携帯電話端末２０ａおよび２０ｂの双方に送信する（ステップＳ３２２）。

この決定プロトコル５４ｃの配信に応じて、双方の携帯電話端末２０ａおよび２０ｂで、前述のステップＳ３０４〜３０５、およびＳ３１４〜３１５と同様にして、通信プロトコルを「ＨＴＴＰ」に切り替える操作が行われる（ステップＳ３０８〜３０９、およびＳ３１８〜３１９）。以後、携帯電話端末２０ａおよび２０ｂとコンテンツ共有サーバ１０の各々で、同様の動作が継続される。

図９は、図１に示したコンテンツ共有システム１で、携帯電話端末２０ａおよび２０ｂが同一のコンテンツ３９を共有している場合の、コンテンツ３９に対する更新頻度に連動してのプロトコル切換の動作の一例について示す説明図である。まず一方の携帯電話端末２０ａで、共有ＡＰ３２を起動して待機状態とする（ステップＳ４０１、図４のステップＳ１０１に該当）。これと並行して、もう一方の携帯電話端末２０ｂでも、共有ＡＰ３２を起動して待機状態とする（ステップＳ４１１、図４のステップＳ１０１に該当）。

ステップＳ４０１および４１１では、図８の場合と同様に音声通話が行われていないので、通話状況３８ａは「待機中」となり、選択されるプロトコルは「ＨＴＴＰ」となる。コンテンツ共有サーバ１０でも、プロトコル決定データ５４として登録されている双方の希望プロトコル５４ａおよび５４ｂ、そして決定プロトコル５４ｃの初期値は「ＨＴＴＰ」である。

一方の携帯電話端末２０ａで、音声通話制御部３１がもう一方の携帯電話端末２０ｂを呼び出して音声通話を開始しようとする（ステップＳ４０２、図４のステップＳ１０２に該当）。もう一方の携帯電話端末２０ｂがこの呼び出しに応じれば音声通話が開始される（ステップＳ４１２、図４のステップＳ１０２に該当）。

ただし、図８で示した例と違って、ここでは共有ＡＰ３２の通話開始時の初期状態として希望プロトコル３８ｅ＝「ＨＴＴＰ」が設定されているので、携帯電話端末２０ａおよび２０ｂで「通信プロトコルの切換が必要」と判断されることはないので、そのまま「ＨＴＴＰ」を通信プロトコルとしての通信の動作が継続される。

通信が続いていくうちに、コンテンツ３９に対して携帯電話端末２０ａが一定時間内に送信する差分更新コマンドの回数が所定の閾値を越えたことを携帯電話端末２０ａの通信頻度計測部３５が検出して更新頻度３８ｄを「低い」から「高い」に更新した場合、携帯電話端末２０ａのプロトコル選択部３７がこのことを検出して（ステップＳ４０３）、希望プロトコル３８ｅ＝「ＳＩＰ」をコンテンツ共有サーバ１０に送信する（ステップＳ４０４、図４のステップＳ１０６に該当）。

これを受けたコンテンツ共有サーバ１０では、この携帯電話端末２０ａの希望プロトコル３８ｅ（５４ａ）＝「ＳＩＰ」を決定プロトコル５４ｃとして、携帯電話端末２０ａおよび２０ｂの双方に送信する（ステップＳ４２１、図７のステップＳ２０２に該当）。

決定プロトコル５４ｃ＝「ＳＩＰ」を受けた携帯電話端末２０ａは（ステップＳ４０５、図４のステップＳ１０７に該当）、これに反応して通信プロトコルを「ＳＩＰ」に切り替える（ステップＳ４０６、図４のステップＳ１０８に該当）。そして決定プロトコル５４ｃ＝「ＳＩＰ」を受けた携帯電話端末２０ｂも（ステップＳ４１５、図４のステップＳ１０３に該当）、これに反応して通信プロトコルを「ＳＩＰ」に切り替える（ステップＳ４１６、図４のステップＳ１０４に該当）。

さらに通信が続いていくうちに、コンテンツ３９に対して携帯電話端末２０ａが一定時間内に送信する差分更新コマンドの回数が所定の閾値を下回ったことを携帯電話端末２０ａの通信頻度計測部３５が検出して更新頻度３８ｄを「高い」から「低い」に更新した場合、携帯電話端末２０ａのプロトコル選択部３７がこのことを検出して（ステップＳ４０７）、希望プロトコル３８ｅ＝「ＨＴＴＰ」をコンテンツ共有サーバ１０に送信する（ステップＳ４０８、図４のステップＳ１０６に該当）。

これを受けたコンテンツ共有サーバ１０では、この携帯電話端末２０ａの希望プロトコル３８ｅ（５４ａ）＝「ＨＴＴＰ」を決定プロトコル５４ｃとして、携帯電話端末２０ａおよび２０ｂの双方に送信する（ステップＳ４２２、図７のステップＳ２０２に該当）。

決定プロトコル５４ｃ＝「ＨＴＴＰ」を受けた携帯電話端末２０ａは（ステップＳ４０９、図４のステップＳ１０７に該当）、これに反応して通信プロトコルを「ＨＴＴＰ」に切り替える（ステップＳ４１０、図４のステップＳ１０８に該当）。そして決定プロトコル５４ｃ＝「ＨＴＴＰ」を受けた携帯電話端末２０ｂも（ステップＳ４１９、図４のステップＳ１０３に該当）、これに反応して通信プロトコルを「ＨＴＴＰ」に切り替える（ステップＳ４２０、図４のステップＳ１０４に該当）。以後、携帯電話端末２０ａおよび２０ｂとコンテンツ共有サーバ１０の各々で、同様の動作が継続される。

図１０は、図１に示したコンテンツ共有システム１で、携帯電話端末２０ａおよび２０ｂが同一のコンテンツ３９を共有している場合の、一方の携帯電話端末２０ａの電源状態に連動してのプロトコル切換の動作の一例について示す説明図である。まず一方の携帯電話端末２０ａで、共有ＡＰ３２を起動して待機状態とする（ステップＳ５０１、図４のステップＳ１０１に該当）。これと並行して、もう一方の携帯電話端末２０ｂでも、共有ＡＰ３２を起動して待機状態とする（ステップＳ５１１、図４のステップＳ１０１に該当）。

ステップＳ５０１および５１１では、図８の場合と同様に音声通話が行われていないので、通話状況３８ａは「待機中」となり、選択されるプロトコルは「ＨＴＴＰ」となる。コンテンツ共有サーバ１０でも、プロトコル決定データ５４として登録されている双方の希望プロトコル５４ａおよび５４ｂ、そして決定プロトコル５４ｃの初期値は「ＨＴＴＰ」である。

一方の携帯電話端末２０ａで、音声通話制御部３１がもう一方の携帯電話端末２０ｂを呼び出して音声通話を開始しようとする（ステップＳ５０２、図４のステップＳ１０２に該当）。もう一方の携帯電話端末２０ｂがこの呼び出しに応じれば音声通話が開始される（ステップＳ５１２、図４のステップＳ１０２に該当）。図８で示した例と同様に、共有ＡＰ３２の通話開始時の初期状態として希望プロトコル３８ｅ＝「ＨＴＴＰ」が設定されているので、そのまま「ＨＴＴＰ」を通信プロトコルとしての通信の動作が継続される。

通信が続いていくうちに、一方の携帯電話端末２０ａの充電池２６ａの残量が減少して所定の閾値を越えたことを携帯電話端末２０ａの電源状態確認部３６が検出して電池残量３８ｂを「高い」から「低い」に更新し、かつ充電器接続３８ｃが「接続されていない」状態である場合、携帯電話端末２０ａのプロトコル選択部３７がこのことを検出して（ステップＳ５０３）、希望プロトコル３８ｅ＝「ＳＩＰ」をコンテンツ共有サーバ１０に送信する（ステップＳ５０４、図４のステップＳ１０６に該当）。

これを受けたコンテンツ共有サーバ１０では、この携帯電話端末２０ａの希望プロトコル３８ｅ（５４ａ）＝「ＳＩＰ」を決定プロトコル５４ｃとして、携帯電話端末２０ａおよび２０ｂの双方に送信する（ステップＳ５２１、図７のステップＳ２０２に該当）。

決定プロトコル５４ｃ＝「ＳＩＰ」を受けた携帯電話端末２０ａは（ステップＳ５０５、図４のステップＳ１０７に該当）、これに反応して通信プロトコルを「ＳＩＰ」に切り替える（ステップＳ５０６、図４のステップＳ１０８に該当）。そして決定プロトコル５４ｃ＝「ＳＩＰ」を受けた携帯電話端末２０ｂも（ステップＳ５１５、図４のステップＳ１０３に該当）、これに反応して通信プロトコルを「ＳＩＰ」に切り替える（ステップＳ５１６、図４のステップＳ１０４に該当）。

さらに通信が続いていくうちに、携帯電話端末２０ａの充電池２６ａが交換されて電池残量３８ｂが「高い」状態になった場合、もしくは携帯電話端末２０ａにＡＣアダプタ２６ｂが接続されて充電器接続３８ｃが「接続されている」状態になった場合、これらのことを電源状態確認部３６が取得して、プロトコル選択データ３８の対応する部分を更新する。

そして、この更新を携帯電話端末２０ａのプロトコル選択部３７がこのことを検出して（ステップＳ５０７）、希望プロトコル３８ｅ＝「ＨＴＴＰ」をコンテンツ共有サーバ１０に送信する（ステップＳ５０８、図４のステップＳ１０６に該当）。

これを受けたコンテンツ共有サーバ１０では、この携帯電話端末２０ａの希望プロトコル３８ｅ（５４ａ）＝「ＨＴＴＰ」を決定プロトコル５４ｃとして、携帯電話端末２０ａおよび２０ｂの双方に送信する（ステップＳ５２２、図７のステップＳ２０２に該当）。

決定プロトコル５４ｃ＝「ＨＴＴＰ」を受けた携帯電話端末２０ａは（ステップＳ５０９、図４のステップＳ１０７に該当）、これに反応して通信プロトコルを「ＨＴＴＰ」に切り替える（ステップＳ５１０、図４のステップＳ１０８に該当）。そして決定プロトコル５４ｃ＝「ＨＴＴＰ」を受けた携帯電話端末２０ｂも（ステップＳ５１９、図４のステップＳ１０３に該当）、これに反応して通信プロトコルを「ＨＴＴＰ」に切り替える（ステップＳ５２０、図４のステップＳ１０４に該当）。以後、携帯電話端末２０ａおよび２０ｂとコンテンツ共有サーバ１０の各々で、同様の動作が継続される。

（第１の実施形態の全体的な動作）
次に、上記の実施形態の全体的な動作について説明する。本実施形態に係るプロトコル切換方法は、相互に音声通話およびデータ通信が可能な複数台の端末装置（携帯電話端末２０）と、交換機４０と、コンテンツ共有サーバ１０とが相互に接続されて構成されるコンテンツ共有システム１にあって、同一のコンテンツが双方の端末装置内部に予め記憶されており、端末装置相互間のデータ通信をコンテンツ共有サーバ１０が仲介し（図４・ステップＳ１０１）、端末装置相互間の音声通話を交換機４０が仲介し（図４・ステップＳ１０２）、一方の端末装置で、コンテンツに対するユーザの操作に応じて該操作の内容を他の端末装置上の同一コンテンツに反映させるための差分更新コマンドをコンテンツ共有アプリケーションが作成し且つこれを他の端末装置に送信し、端末装置の状態に応じて第１および第２の通信プロトコルのうちのいずれでデータ通信を行うかをプロトコル選択部が選択してこれを希望プロトコルとしてコンテンツ共有サーバに送信し（図４・ステップＳ１０６）、全ての端末装置から受信した希望プロトコルの中からコンテンツ共有サーバのプロトコル決定部が決定プロトコルを決定すると共にこれを全ての端末装置に送信し（図７・ステップＳ２０１〜２０２）、全ての端末装置で、コンテンツ共有サーバから決定プロトコルをプロトコル選択部が受信する（図４・ステップＳ１０７）と共にこの決定プロトコルを通信プロトコルとして採用する（図４・ステップＳ１０８）。

ここで、上記各動作ステップについては、これをコンピュータで実行可能にプログラム化し、これらを前記各ステップを直接実行するコンピュータである携帯電話端末２０およびコンテンツ共有サーバ１０の主演算制御手段２１および１１に実行させるようにしてもよい。本プログラムは、非一時的な記録媒体、例えば、ＤＶＤ、ＣＤ、フラッシュメモリ等に記録されてもよい。その場合、本プログラムは、記録媒体からコンピュータによって読み出され、実行される。
この動作により、本実施形態は以下のような効果を奏する。

本実施形態によれば、携帯電話端末２０相互間の動作状態、より具体的には通話状態や充電池の残量などの状況に応じて、最適な通信プロトコルを選択することができる。これによって、端末における電力消費の低減と、サーバリソースの消費の抑制とを両立することができる。

（第２の実施形態）
本発明の第２の実施形態では、端末装置を各々、音声通話手段のみを備えた電話機６２１と、音声通話手段を除く端末装置の構成を備えたコンピュータ装置（ノートＰＣ６２０）との組によって構成した。これと共に、交換機６４０が、電話機の相互間で音声通話が開始されたことをコンテンツ共有サーバ６１０に対して通知する通話状態通知手段６４０ｂを備える構成とした。

この構成によれば、相互に連動していないノートＰＣ６２０と電話機６２１との組み合わせを使用しても、第１の実施形態と同一の効果を得ることができる。
以下、これをより詳細に説明する。

図１１は、本発明の第２の実施形態に係るコンテンツ共有システム６０１の構成について示す説明図である。コンテンツ共有システム６０１は、前述の第１の実施形態に係るコンテンツ共有システム１の携帯電話端末２０ａ、２０ｂ、２０ｃ…の各々が、ノートブック型パーソナルコンピュータ（ノートＰＣ）６２０ａ、６２０ｂ、６２０ｃ…と電話器６２１ａ、６２１ｂ、６２１ｃ…とに置き換えられている。また、第１の実施形態に係るコンテンツ共有システム１のコンテンツ共有サーバ１０および交換機４０が、それぞれ別のコンテンツ共有サーバ６１０および交換機６４０に置き換えられている。

ノートＰＣ６２０ａ、６２０ｂ、６２０ｃ…は、コンテンツ共有サーバ１０を介して第１の実施形態と同様に、コンテンツの共有に係る操作が可能である。電話器６２１ａ、６２１ｂ、６２１ｃ…は、交換機６４０を介して第１の実施形態と同様に音声通話が可能である。以後、第１の実施形態と同様に、ノートＰＣ６２０ａ、６２０ｂ、６２０ｃ…を総称してノートＰＣ６２０といい、また電話器６２１ａ、６２１ｂ、６２１ｃ…総称して電話器６２１という。もちろん、ノートＰＣ６２０と電話器６２１は、各々他の種類の端末であってもよい。

ノートＰＣ６２０ａと電話器６２１ａ、ノートＰＣ６２０ｂと電話器６２１ｂ、ノートＰＣ６２０ｃと電話器６２１ｃ…が各々同一ユーザに対応する。ノートＰＣ６２０と電話器６２１は、各々独立して動作して使用されるものである。しかしながら、同一ユーザに対応するノートＰＣ６２０と電話器６２１は、相互の動作状態を把握するための手段を持たないので、このままでは第１の実施形態のような動作を行うことはできない。そこで、本実施形態では、後述のようにコンテンツ共有サーバ６１０および交換機６４０が連携して、ノートＰＣ６２０と電話器６２１の相互の動作状態を把握することを可能にしている。

図１２は、図１１で示したコンテンツ共有サーバ６１０および交換機６４０の構成について示す説明図である。本実施形態に係る交換機６４０は、各電話器６２１相互間の音声通話を交換して仲介する交換手段６４０ａと共に、当該電話器６２１相互間で音声通話が開始されたことを公衆通信網２を介してコンテンツ共有サーバ６１０に通知する通話状態通知手段６４０ｂを備える。

コンテンツ共有サーバ６１０は、ハードウェア的には図５（Ａ）で示した第１の実施形態に係るコンテンツ共有サーバ１０と同一であるが、唯一の相違点は主演算制御手段１１で動作するプロトコル決定部５３が別のプロトコル決定部６５３に置き換えられている点である。プロトコル決定部６５３は、交換機６４０の通話状態通知手段６４０ｂから、電話器６２１相互間での音声通話の状態を取得し、これに応じてＳＩＰとＨＴＴＰのいずれのプロトコルで通信を行うかを決定する。

図１３は、図１１で示したノートＰＣ６２０および電話機６２１の構成について示す説明図である。図１３（Ａ）はノートＰＣ６２０、図１３（Ｂ）は電話機６２１について各々示す。図１３（Ａ）に示したノートＰＣ６２０は、コンピュータとしての基本的な構成を有するものであり、かつ第１の実施形態に係る携帯電話端末２０から音声通話に係る機能を図１３（Ｂ）に示した電話機６２１として独立させたものであるとも言える。

即ち、ノートＰＣ６２０は、コンピュータプログラムを実行する主体となる主演算制御手段２１と、データを記憶する記憶手段２２と、他のノートＰＣとの間でデータ通信を行うデータ通信手段２４と、ユーザからの操作を受け付け、またユーザに処理結果を提示する入出力手段２５と、以上の各部に動作に必要な電力を供給する電力供給手段２６を備える。また電話機６２１は、音声通話手段２３を備える。

電力供給手段２６は、充電池２６ａを内蔵し、また商用交流電源をノートＰＣ６２０が動作可能な直流に変換するＡＣアダプタ２６ｂを着脱可能である。ＡＣアダプタ２６ｂが電力供給手段２６に接続されている間は、ノートＰＣ６２０はＡＣアダプタ２６ｂから供給される直流で動作すると同時に、充電池２６ａもこの直流によって充電される。

主演算制御手段２１では、コンテンツ共有アプリケーション３２、ＳＩＰ通信制御部３３、ＨＴＴＰ差分更新通信制御部３４、通信頻度計測部３５、電源状態確認部３６、およびプロトコル選択部３７が、コンピュータプログラムとして各々の機能を実行されるように構成されている。また、記憶手段２２には、プロトコル選択データ３８と、ノートＰＣ６２０ａおよび６２０ｂが共有する対象であるコンテンツ３９が記憶されている。

以上の各部および各データは、第１の実施形態に係る携帯電話端末２０について説明したものと同一である。従って、同一の名称および参照番号で呼ぶものとする。これらの動作の内容、およびそれによって得られる効果も、第１の実施形態に係る携帯電話端末２０について説明したものと同一である。

ノートＰＣ６２０の主演算制御手段２１では、これらに加えて、音声通話状態取得部６３１がコンピュータプログラムとしてその機能を実行可能なように構成されている。音声通話状態取得部６３１は、コンテンツ共有サーバ６１０から（ノートＰＣ６２０に対応する）電話器６２１の通話状態（「通話中」もしくは「待機中」）を取得して、それに応じてプロトコル選択データ３８の通話状況３８ａの値を更新する。これによって、プロトコル選択部３７は第１の実施形態と同一の動作を行うことが可能となる。

図１４は、図１１に示したコンテンツ共有システム６０１で、ノートＰＣ６２０ａおよび６２０ｂが同一のコンテンツ３９を共有している場合の、電話器６２１ａおよび６２１ｂ間の通話状態を取得する動作の一例について示す説明図である。まず一方のノートＰＣ６２０ａで、共有ＡＰ３２を起動して待機状態とする（ステップＳ７０１、図８のステップＳ３０１に該当）。これと並行して、もう一方のノートＰＣ６２０ｂでも、共有ＡＰ３２を起動して待機状態とする（ステップＳ７１１、図８のステップＳ３１１に該当）。

ステップＳ７０１および７１１では、音声通話が行われていないので、通話状況３８ａは「待機中」となり、選択されるプロトコルは「ＨＴＴＰ」となる。ここで、コンテンツ共有サーバ６１０のプロトコル決定データ５４として登録されている双方の希望プロトコル５４ａおよび５４ｂ、そして決定プロトコル５４ｃの初期値は「ＨＴＴＰ」である。

ここで、一方の電話器６２１がもう一方の電話器６２１ｂを呼び出して音声通話を開始しようとする（ステップＳ７０２、図８のステップＳ３０２に該当）。もう一方の電話器６２１ｂがこの呼び出しに応じれば音声通話が開始される（ステップＳ７１２、図８のステップＳ３１２に該当）。

すると、通話状態通知手段６４０ｂが電話器６２１ａおよび６２１ｂの音声通話開始を検出して、この音声通話が開始されたことをコンテンツ共有サーバ６１０に通知する（ステップＳ７２１）。この通知を受けたコンテンツ共有サーバ６１０のプロトコル決定部６５３は、電話器６２１ａおよび６２１ｂの各々に対応するノートＰＣ６２０ａおよび６２０ｂに、音声通話が開始されたことを通知する（ステップＳ７３１）。

ノートＰＣ６２０ａおよび６２０ｂでは、この音声通話開始の通知を音声通話状態取得部６３１が受信して、各々プロトコル選択データ３８の通話状況３８ａの値を「通話中」に更新する（ステップＳ７０３および７１３）。これに応じて、図８のステップＳ３０３および３１４以降と同様に、音声通話の開始と終了に応じて通信プロトコルを「ＳＩＰ」もしくは「ＨＴＴＰ」に変更する動作が行われる。

このように、電話器６２１ａおよび６２１ｂの通話状態を交換機６４０からコンテンツ共有サーバ６１０を介して各々のノートＰＣ６２０に通知する構成とすれば、ノートＰＣ６２０と電話器６２１が連動せず、各々独立したものであっても、第１の実施形態と同様に動作させるものとすることができ、同一の効果を得ることができる。

（第３の実施形態）
本発明の第３の実施形態では、コンテンツ共有サーバ８１０のプロトコル決定部８５３が、複数台の端末装置２０の中で希望プロトコルが第１の通信プロトコルである端末装置が１台以上存在する場合に第１の通信プロトコルを決定プロトコルとし、全ての端末装置の希望プロトコルが第２の通信プロトコルである場合に第２の通信プロトコルを決定プロトコルとするものとした。

この構成によれば、第１の実施形態と同一の端末装置を３台以上でコンテンツ共有の動作を行う際にも、第１の実施形態と同一の効果を得ることができる。
以下、これをより詳細に説明する。

図１５は、本発明の第３の実施形態に係るコンテンツ共有システム８０１の構成について示す説明図である。コンテンツ共有システム８０１は、前述した第１の実施形態に係るコンテンツ共有システム１と同一の複数台の携帯電話端末２０ａ、２０ｂ、２０ｃ…の各々が、音声通話用の交換機４０およびデータ通信用のコンテンツ共有サーバ８１０に無線通信を含む公衆通信網２で接続可能なように構成されている。コンテンツ共有システム１との相違点は、コンテンツ共有サーバ１０が別のコンテンツ共有サーバ８１０に置換されている点のみである。

図１６は、図１５で説明したコンテンツ共有サーバ８１０のより詳細な構成について示す説明図である。コンテンツ共有サーバ８１０は、ハードウェア的には図５で示した第１の実施形態に係るコンテンツ共有サーバ１０と同一であるが、相違点は主演算制御手段１１で動作するプロトコル決定部５３が別のプロトコル決定部８５３に、そしてプロトコル決定データ５４が別のプロトコル決定データ８５４に、各々置き換えられている点である。

図１７は、図１６で説明したプロトコル決定データ８５４の内容の一例について示す説明図である。図１７に示す例では、図１に示した携帯電話端末２０ａ、２０ｂ、２０ｃの３台が現在通信を行っている状態を示している。この場合、プロトコル決定データ８５４は、携帯電話端末２０ａ〜２０ｃの各々の希望プロトコル８５４ａ〜８５４ｃと、そこからプロトコル決定部８５３が決定した決定プロトコル８５４ｄが含まれる。

コンテンツ共有システム８０１では、３台以上の携帯電話端末２０ａ、２０ｂ、２０ｃ…と、第１および第２の実施形態と同様のコンテンツ共有の動作が可能である。コンテンツ共有の動作そのものは、既に説明した２台の携帯電話端末２０ａおよび２０ｂの場合と同一である。

しかしながら、２台の携帯電話端末２０ａおよび２０ｂの場合は、その一方が現在の通信プロトコルと異なる希望プロトコルを送信した場合、それをそのまま決定プロトコルとして他方に送信すればよかった。これに対して、３台以上の携帯電話端末２０ａ、２０ｂ、２０ｃ…が相互にコンテンツ共有の動作を行っている場合には、消費電力とネットワークに対する負荷を低く抑えるという効果を発揮するための通信プロトコルの判断基準が必要となる。

図１８は、図１６で説明したプロトコル決定部８５３の動作について示すフローチャートである。プロトコル決定部８５３は、現在通信を行っているうちいずれかの携帯電話端末２０から希望プロトコル３８ｅを受信した場合に（ステップＳ９０１がイエス）、３台以上の携帯電話端末のうち希望プロトコル＝「ＳＩＰ」であるものが１つ以上存在するか否かを判定する（ステップＳ９０２）。

希望プロトコル＝「ＳＩＰ」であるものが１つ以上存在する場合には（ステップＳ９０２がイエス）決定プロトコル８５４ｄ＝「ＳＩＰ」とする（ステップＳ９０３）。相互に通信を行っている携帯電話端末の全てが希望プロトコル＝「ＨＴＴＰ」である場合には（ステップＳ９０２がノー）決定プロトコル８５４ｄ＝「ＨＴＴＰ」とする（ステップＳ９０４）。

そして、ステップＳ９０３もしくはＳ９０４で決定された決定プロトコル８５４ｄを、各々の携帯電話端末２０に送信する（ステップＳ９０５）。これと同時にプロトコル決定部８５３は、プロトコル決定データ８５４にも希望プロトコル８５４ａ〜８５４ｃ、および決定プロトコル８５４ｄを記憶する。

前述のように、各端末の消費電力を低減する効果を発揮するためには、ＨＴＴＰよりもＳＩＰを使用して通信することが有効である。従って、１台でも希望プロトコル＝「ＳＩＰ」である携帯電話端末２０があるなら、全体がこれに従って通信を行うことが望ましい。

図１８のステップＳ９０２で説明した、３台以上の携帯電話端末２０でコンテンツ共有の動作を行う際に決定プロトコルを決定する基準は、上記した以外にも、各々のコンテンツ共有システムに固有の事情などに応じた基準を当業者が任意に選択してルールとして設定することが可能である。

たとえば、３台以上の携帯電話端末２０の中で多数決を行って、「ＳＩＰ」と「ＨＴＴＰ」のうちより多くの携帯電話端末２０が希望している方の通信プロトコルを決定プロトコルとしてもよい。

あるいは、希望プロトコル＝「ＨＴＴＰ」である携帯電話端末の台数の、相互に通信を行っている携帯電話端末全体の台数に対する比率をあらかじめ与えられた特定の閾値と比較して、前者が後者より多ければ「ＨＴＴＰ」を、そうでない場合には「ＳＩＰ」を決定プロトコルとしてもよい。

これは、特に多くの台数の携帯電話端末がコンテンツ共有の動作を行っている場合に、電池残量が少ないごく少数の端末が存在した場合に全体の通信プロトコルを「ＳＩＰ」とすると、コンテンツ共有サーバ８１０において多くのサーバリソースを消費して、コンテンツ共有システム全体としての動作コストを高めてしまう可能性があるからである。

また、第２の実施形態で説明した、連動していないノートＰＣと電話機を利用したコンテンツ共有システムにおいても、この基準によって決定プロトコルを決定することによって、ノートＰＣと電話機との組が３組以上でコンテンツ共有の動作を行う際にも、第１の実施形態と同一の効果を得ることができる。

これまで本発明について図面に示した特定の実施形態をもって説明してきたが、本発明は図面に示した実施形態に限定されるものではなく、本発明の効果を奏する限り、これまで知られたいかなる構成であっても採用することができる。

上述した各々の実施形態について、その新規な技術内容の要点をまとめると、以下のようになる。なお、上記実施形態の一部または全部は、新規な技術として以下のようにまとめられるが、本発明は必ずしもこれに限定されるものではない。

（付記１） 相互に音声通話およびデータ通信が可能な複数台の端末装置と、前記端末装置相互間の前記音声通話を仲介する交換機と、前記端末装置相互間の前記データ通信を仲介するコンテンツ共有サーバとが相互に接続されて構成されるコンテンツ共有システムであって、
前記端末装置が各々、
前記音声通話を行う音声通話手段と、
双方の内部に記憶された同一のコンテンツに対する一方の端末装置でのユーザの操作に応じて該操作の内容を他方の端末装置上の前記同一コンテンツに反映させるための差分更新コマンドを作成すると共にこれをもう一方の端末装置に送信するコンテンツ共有アプリケーションと、
第１および第２の通信プロトコルのうちいずれか一方で前記データ通信を行う第１および第２の通信制御部と、
前記各端末装置の状態に応じて前記第１および第２の通信プロトコルのうちのいずれか一方を選択してこれを希望プロトコルとして前記コンテンツ共有サーバに送信すると共に、前記コンテンツ共有サーバから受信した決定プロトコルを前記通信プロトコルとして採用するプロトコル選択部と、
を有することを特徴とするコンテンツ共有システム。

（付記２） 前記各端末装置の前記プロトコル選択部が、前記音声通話が開始もしくは終了したことを検出して前記第１および第２の通信プロトコルのうちのいずれか一方の選択を行うことを特徴とする、付記１に記載のコンテンツ共有システム。

（付記３） 前記端末装置の前記プロトコル選択部が、前記音声通話が開始した場合に前記第１の通信プロトコルを選択し、前記音声通話が終了した場合に前記第２の通信プロトコルを選択することを特徴とする、付記２に記載のコンテンツ共有システム。

（付記４） 前記各端末装置の前記プロトコル選択部が、前記コンテンツ共有アプリケーションによる前記差分更新コマンドの送信頻度を検出して前記第１および第２の通信プロトコルのうちのいずれか一方の選択を行うことを特徴とする、付記２に記載のコンテンツ共有システム。

（付記５） 前記端末装置の前記プロトコル選択部が、前記差分更新コマンドの送信頻度が予め与えられた閾値より高い場合に前記第１の通信プロトコルを選択し、前記差分更新コマンドの送信頻度が前記閾値より低い場合に前記第２の通信プロトコルを選択することを特徴とする、付記４に記載のコンテンツ共有システム。

（付記６） 前記各端末装置の前記プロトコル選択部が、自らに備えられた電源装置内部の電池の残量を検出して前記第１および第２の通信プロトコルのうちのいずれか一方の選択を行うことを特徴とする、付記２に記載のコンテンツ共有システム。

（付記７） 前記端末装置の前記プロトコル選択部が、前記電池の残量が予め与えられた閾値より低い場合に前記第１の通信プロトコルを選択し、前記電池の残量が前記閾値より高い場合、もしくは前記端末装置が商用電源に接続されている場合に前記第２の通信プロトコルを選択することを特徴とする、付記６に記載のコンテンツ共有システム。

（付記８） 前記端末装置を各々、前記音声通話手段のみを備えた電話機と、前記音声通話手段を除く前記端末装置の構成を備えたコンピュータ装置との組によって構成すると共に、
前記交換機が、前記電話機の相互間で前記音声通話が開始されたことを前記コンテンツ共有サーバに対して通知する通話状態通知手段を備えたことを特徴とする、付記１ないし付記７のうちいずれか１項に記載のコンテンツ共有システム。

（付記９） 前記コンテンツ共有サーバが、
前記第１および第２の通信プロトコルによる前記各端末装置相互間の前記データ通信を仲介する第１および第２の通信仲介部と、
前記各端末装置から前記希望プロトコルを受信し、全ての前記各端末装置の前記希望プロトコルの中から前記決定プロトコルを決定してこれを全ての前記各端末装置に送信するプロトコル決定部を有することを特徴とする、付記１ないし付記８のうちいずれか１項に記載のコンテンツ共有システム。

（付記１０） 前記コンテンツ共有サーバの前記プロトコル決定部が、複数台の前記各端末装置の中で前記希望プロトコルが前記第１の通信プロトコルである端末装置が１台以上存在する場合に前記第１の通信プロトコルを前記決定プロトコルとし、全ての前記端末装置の前記希望プロトコルが前記第２の通信プロトコルである場合に前記第２の通信プロトコルを前記決定プロトコルとすることを特徴とする、付記９に記載のコンテンツ共有システム。

（付記１１） 前記第１および第２の通信プロトコルが、各々ＳＩＰ（Session Initiation Protocol）およびＨＴＴＰ（HyperText Transfer Protocol）であることを特徴とする、付記１ないし付記１０のうちいずれか１項に記載のコンテンツ共有システム。

（付記１２） 音声通話およびデータ通信が可能であり、かつ他装置との前記音声通話を仲介する交換機および前記他装置との前記データ通信を仲介するコンテンツ共有サーバと相互に接続されてコンテンツ共有システムを構成する端末装置であって、
前記音声通話を行う音声通話手段と、
内部に記憶されたコンテンツに対するユーザの操作に応じて該操作の内容を他装置上の前記同一コンテンツに反映させるため差分更新コマンドを作成すると共にこれを他装置に送信するコンテンツ共有アプリケーションと、
第１および第２の通信プロトコルのうちいずれか一方で前記データ通信を行う第１および第２の通信制御部と、
自らの状態に応じて前記第１および第２の通信プロトコルのうちのいずれか一方を選択してこれを希望プロトコルとして前記コンテンツ共有サーバに送信すると共に、前記コンテンツ共有サーバから受信した決定プロトコルを前記通信プロトコルとして採用するプロトコル選択部と、
を有することを特徴とする端末装置。

（付記１３） 音声通話およびデータ通信が可能な複数の端末装置の間の前記データ通信を仲介するコンテンツ共有サーバと相互に接続されてコンテンツ共有システムを構成するコンテンツ共有サーバであって、
第１および第２の通信プロトコルによる前記端末装置相互間の前記データ通信を仲介する第１および第２の通信仲介部と、
全ての前記端末装置から希望プロトコルを受信し、全ての前記各端末装置の前記希望プロトコルの中から決定プロトコルを決定してこれを全ての前記各端末装置に送信するプロトコル決定部を有することを特徴とするコンテンツ共有サーバ。

（付記１４） 相互に音声通話およびデータ通信が可能な複数台の端末装置と、交換機と、コンテンツ共有サーバとが相互に接続されて構成されるコンテンツ共有システムにあって、
同一のコンテンツが双方の前記端末装置内部に予め記憶されており、
前記端末装置相互間の前記音声通話を前記交換機が仲介し、
前記端末装置相互間の前記データ通信を前記コンテンツ共有サーバが仲介し、
一方の前記端末装置で、前記コンテンツに対するユーザの操作に応じて該操作の内容を他の端末装置上の前記同一コンテンツに反映させるための差分更新コマンドをコンテンツ共有アプリケーションが作成し且つこれを他の端末装置に送信し、
一方の前記端末装置で、前記端末装置の状態に応じて前記第１および第２の通信プロトコルのうちのいずれで前記データ通信を行うかをプロトコル選択部が選択してこれを希望プロトコルとして前記コンテンツ共有サーバに送信し、
全ての前記端末装置から受信した前記希望プロトコルの中から前記コンテンツ共有サーバのプロトコル決定部が決定プロトコルを決定すると共にこれを全ての前記端末装置に送信し、
全ての前記端末装置で、前記コンテンツ共有サーバから決定プロトコルを前記プロトコル選択部が受信すると共にこの決定プロトコルを通信プロトコルとして採用する
ことを特徴とするプロトコル切換方法。

（付記１５） 相互に音声通話およびデータ通信が可能な複数台の端末装置と、交換機と、コンテンツ共有サーバとが相互に接続されて構成されるコンテンツ共有システムにあって、
前記端末装置の各々が備えるコンピュータに、
他の端末装置と同一のコンテンツを予め記憶する手順、
前記コンテンツに対するユーザの操作に応じて他の端末装置上の前記同一コンテンツに反映させるための差分更新コマンドを作成し且つこれを他の端末装置に送信する手順、
前記端末装置の状態に応じて前記第１および第２の通信プロトコルのうちのいずれで前記データ通信を行うかを選択してこれを希望プロトコルとして前記コンテンツ共有サーバに送信する手順、
および前記コンテンツ共有サーバから決定プロトコルを受信すると共にこの決定プロトコルを通信プロトコルとして採用する手順
を実行させることを特徴とするプロトコル切換プログラム。

（付記１６） 音声通話およびデータ通信が可能な複数の端末装置と相互に接続されてコンテンツ共有システムにあって、
前記コンテンツ共有サーバが備えるコンピュータに、
第１および第２の通信プロトコルによる前記端末装置相互間の前記データ通信を仲介する手順、
全ての前記端末装置から希望プロトコルを受信してその中から決定プロトコルを決定する手順、
および決定した前記決定プロトコルを各々の前記端末装置に送信する手順
を実行させることを特徴とするプロトコル切換プログラム。

この出願は２０１０年１０月２５日に出願された日本出願特願２０１０−２３８２８６を基礎とする優先権を主張し、その開示の全てをここに取り込む。

本発明は、ＩＭＳ（Internet protocol Multimedia Subsystem）を利用したコンテンツ共有システムにおいて利用可能である。

１、６０１、８０１ コンテンツ共有システム
２ 公衆通信網
１０、６１０、８１０ コンテンツ共有サーバ
１１、２１ 主演算制御手段
１２、２２ 記憶手段
１３、２４ データ通信手段
２０、２０ａ、２０ｂ 携帯電話端末
２３ 音声通話手段
２５ 入出力手段
２６ 電力供給手段
２６ａ 充電池
２６ｂ ＡＣアダプタ
３１ 音声通話制御部
３２ 共有ＡＰ
３３ ＳＩＰ通信制御部
３４ ＨＴＴＰ差分更新通信制御部
３５ 通信頻度計測部
３６ 電源状態確認部
３７ プロトコル選択部
３８ プロトコル選択データ
３８ａ 通話状況
３８ｂ 電池残量
３８ｃ 充電器接続
３８ｄ 更新頻度
３８ｅ、５４ａ〜ｂ、８５４ａ〜ｃ 希望プロトコル
３９ コンテンツ
４０、６４０ 交換機
４０ａ、６４０ａ 交換手段
５１ ＳＩＰ通信仲介部
５２ ＨＴＴＰ通信仲介部
５３、６５３、８５３ プロトコル決定部
５４、８５４ プロトコル決定データ
５４ｃ、８５４ｄ 決定プロトコル
６２０、６２０ａ、６２０ｂ ノートＰＣ
６２１、６２１ａ、６２１ｂ 電話機
６３１ 音声通話状態取得部
６４０ｂ 通話状態通知手段

Claims (10)

1. 相互に音声通話およびデータ通信が可能な複数台の端末装置と、前記端末装置相互間の前記音声通話を仲介する交換機と、前記端末装置相互間の前記データ通信を仲介するコンテンツ共有サーバとが相互に接続されて構成されるコンテンツ共有システムであって、
   前記端末装置が各々、
   前記音声通話を行う音声通話手段と、
   双方の内部に記憶された同一のコンテンツに対する一方の端末装置でのユーザの操作に応じて該操作の内容を他方の端末装置上の前記同一コンテンツに反映させるための差分更新コマンドを作成すると共にこれをもう一方の端末装置に送信するコンテンツ共有アプリケーションと、
   第１および第２の通信プロトコルのうちいずれか一方で前記データ通信を行う第１および第２の通信制御部と、
   前記各端末装置の状態に応じて前記第１および第２の通信プロトコルのうちのいずれか一方を選択してこれを希望プロトコルとして前記コンテンツ共有サーバに送信すると共に、前記コンテンツ共有サーバから受信した決定プロトコルを前記通信プロトコルとして採用するプロトコル選択部と、
   を有することを特徴とするコンテンツ共有システム。
2. 前記各端末装置の前記プロトコル選択部が、前記音声通話が開始もしくは終了したことを検出して前記第１および第２の通信プロトコルのうちのいずれか一方の選択を行うことを特徴とする、請求項１に記載のコンテンツ共有システム。
3. 前記各端末装置の前記プロトコル選択部が、前記コンテンツ共有アプリケーションによる前記差分更新コマンドの送信頻度を検出して前記第１および第２の通信プロトコルのうちのいずれか一方の選択を行うことを特徴とする、請求項２に記載のコンテンツ共有システム。
4. 前記各端末装置の前記プロトコル選択部が、自らに備えられた電源装置内部の電池の残量を検出して前記第１および第２の通信プロトコルのうちのいずれか一方の選択を行うことを特徴とする、請求項２に記載のコンテンツ共有システム。
5. 前記コンテンツ共有サーバが、
   前記第１および第２の通信プロトコルによる前記各端末装置相互間の前記データ通信を仲介する第１および第２の通信仲介部と、
   前記各端末装置から前記希望プロトコルを受信し、全ての前記各端末装置の前記希望プロトコルの中から前記決定プロトコルを決定してこれを全ての前記各端末装置に送信するプロトコル決定部を有することを特徴とする、請求項１ないし請求項４のうちいずれか１項に記載のコンテンツ共有システム。
6. 前記コンテンツ共有サーバの前記プロトコル決定部が、複数台の前記各端末装置の中で前記希望プロトコルが前記第１の通信プロトコルである端末装置が１台以上存在する場合に前記第１の通信プロトコルを前記決定プロトコルとし、全ての前記端末装置の前記希望プロトコルが前記第２の通信プロトコルである場合に前記第２の通信プロトコルを前記決定プロトコルとすることを特徴とする、請求項５に記載のコンテンツ共有システム。
7. 前記第１および第２の通信プロトコルが、各々ＳＩＰ（Session Initiation Protocol）およびＨＴＴＰ（HyperText Transfer Protocol）であることを特徴とする、請求項１ないし請求項６のうちいずれか１項に記載のコンテンツ共有システム。
8. 音声通話およびデータ通信が可能であり、かつ他装置との前記音声通話を仲介する交換機および前記他装置との前記データ通信を仲介するコンテンツ共有サーバと相互に接続されてコンテンツ共有システムを構成する端末装置であって、
   前記音声通話を行う音声通話手段と、
   内部に記憶されたコンテンツに対するユーザの操作に応じて該操作の内容を他装置上の前記同一コンテンツに反映させるため差分更新コマンドを作成すると共にこれを他装置に送信するコンテンツ共有アプリケーションと、
   第１および第２の通信プロトコルのうちいずれか一方で前記データ通信を行う第１および第２の通信制御部と、
   自らの状態に応じて前記第１および第２の通信プロトコルのうちのいずれか一方を選択してこれを希望プロトコルとして前記コンテンツ共有サーバに送信すると共に、前記コンテンツ共有サーバから受信した決定プロトコルを前記通信プロトコルとして採用するプロトコル選択部と、
   を有することを特徴とする端末装置。
9. 相互に音声通話およびデータ通信が可能な複数台の端末装置と、交換機と、コンテンツ共有サーバとが相互に接続されて構成されるコンテンツ共有システムにあって、
   同一のコンテンツが双方の前記端末装置内部に予め記憶されており、
   前記端末装置相互間の前記音声通話を前記交換機が仲介し、
   前記端末装置相互間の前記データ通信を前記コンテンツ共有サーバが仲介し、
   一方の前記端末装置で、前記コンテンツに対するユーザの操作に応じて該操作の内容を他の端末装置上の前記同一コンテンツに反映させるための差分更新コマンドをコンテンツ共有アプリケーションが作成し且つこれを他の端末装置に送信し、
   一方の前記端末装置で、前記端末装置の状態に応じて前記第１および第２の通信プロトコルのうちのいずれで前記データ通信を行うかをプロトコル選択部が選択してこれを希望プロトコルとして前記コンテンツ共有サーバに送信し、
   全ての前記端末装置から受信した前記希望プロトコルの中から前記コンテンツ共有サーバのプロトコル決定部が決定プロトコルを決定すると共にこれを全ての前記端末装置に送信し、
   全ての前記端末装置で、前記コンテンツ共有サーバから決定プロトコルを前記プロトコル選択部が受信すると共にこの決定プロトコルを通信プロトコルとして採用する
   ことを特徴とするプロトコル切換方法。
10. 相互に音声通話およびデータ通信が可能な複数台の端末装置と、交換機と、コンテンツ共有サーバとが相互に接続されて構成されるコンテンツ共有システムにあって、
    前記端末装置の各々が備えるコンピュータに、
    他の端末装置と同一のコンテンツを予め記憶する手順、
    前記コンテンツに対するユーザの操作に応じて他の端末装置上の前記同一コンテンツに反映させるための差分更新コマンドを作成し且つこれを他の端末装置に送信する手順、
    前記端末装置の状態に応じて前記第１および第２の通信プロトコルのうちのいずれで前記データ通信を行うかを選択してこれを希望プロトコルとして前記コンテンツ共有サーバに送信する手順、
    および前記コンテンツ共有サーバから決定プロトコルを受信すると共にこの決定プロトコルを通信プロトコルとして採用する手順
    を実行させることを特徴とするプロトコル切換プログラム。

Images