(57)【要約】【課題】複数の端末にて情報を共有する場合に、配信された情報が各端末にて出力されるタイミングの同期性を向上させること。【解決手段】情報配信システムのＡｐｐサーバ１０は、制御部１３を有する。制御部１３は、複数の端末に対して複数の情報を順次配信する際に、当該複数の端末それぞれの情報処理完了状況（未完了情報数）と情報処理能力（下り伝送時間及び処理時間）とに基づいて、各端末への情報の配信時期を変更するように制御する。【選択図】図３
2012083805.tif 000002
【特許請求の範囲】
【請求項１】
配信された情報に対して処理を行なって利用者に出力する複数の端末に対して、情報提供装置から複数の情報を順次配信する際に、当該複数の端末それぞれの情報処理完了状況と情報処理能力とに基づいて、各端末への情報の配信時期を変更するように制御する、又は、各端末における情報の処理開始時期を変更するように制御する制御手段を備えたことを特徴とする情報配信システム。
【請求項２】
前記複数の端末それぞれの情報処理完了状況として、前記情報提供装置からの情報配信時における前記複数の端末それぞれの未処理の情報数である未完了情報数を取得し、当該取得した各端末の未完了情報数に基づいて、情報の配信を待機させる待機端末、又は、情報の処理開始を待機させる待機端末が存在するか否かを判定する判定手段をさらに備え、
前記制御手段は、前記判定手段により前記待機端末が存在すると判定された場合、前記複数の端末それぞれの情報処理能力として、前記情報提供装置から情報を端末に配信してから当該端末が当該情報に対する処理を完了するまでに要すると推定される推定時間を前記複数の端末ごとに取得し、前記待機端末の推定時間と当該待機端末以外の他の端末の推定時間との時間差に基づいて、前記待機端末に対する情報配信の待機時間、又は、前記待機端末における情報の処理開始の待機時間を設定することを特徴とする請求項１に記載の情報配信システム。
【請求項３】
前記推定時間を前記複数の端末ごとに記憶する推定時間記憶手段をさらに備え、
前記制御手段は、前記推定時間記憶手段から前記複数の端末それぞれの推定時間を取得することを特徴とする請求項２に記載の情報配信システム。
【請求項４】
前記推定時間は、前記情報提供装置の情報配信時から配信先の端末の情報受信時までの時間である伝送時間と、当該配信先の端末の情報受信時から当該配信先の端末における情報処理完了時までの時間である処理時間との合計時間であることを特徴とする請求項２または３に記載の情報配信システム。
【請求項５】
前記推定時間記憶手段は、情報の処理内容ごとの推定時間を記憶し、
前記制御手段は、前記情報提供装置から配信される情報に対する処理の内容に対応する推定時間を前記推定時間記憶手段から取得して前記待機時間を設定することを特徴とする請求項３または４に記載の情報配信システム。
【請求項６】
前記情報提供装置から配信される情報の属性を記憶する属性記憶手段をさらに備え、
前記判定手段は、前記情報提供装置からの情報配信時における前記複数の端末それぞれの未完了情報数を取得するとともに、前記情報提供装置から配信が予定される配信予定情報の属性を前記属性記憶手段から取得し、当該取得した各端末の未完了情報数と前記配信予定情報の属性とに基づいて、当該配信予定情報を配信しない配信不可端末が存在するか否かを判定し、
前記制御手段は、前記判定手段により前記配信不可端末が存在すると判定された場合、当該配信不可端末に対して、前記配信予定情報の配信を中止するように制御することを特徴とする請求項２〜５のいずれか一つに記載の情報配信システム。
【請求項７】
配信された情報に対して処理を行なって利用者に出力する複数の端末に対して、情報提供装置から複数の情報を順次配信する際に、当該複数の端末それぞれの情報処理完了状況と情報処理能力とに基づいて、各端末への情報の配信時期を変更するように制御する、又は、各端末における情報の処理開始時期を変更するように制御する制御ステップを含んだことを特徴とする情報配信方法。
【請求項８】
配信された情報に対して処理を行なって利用者に出力する複数の端末に対して、情報提供装置から複数の情報を順次配信する際に、当該複数の端末それぞれの情報処理完了状況と情報処理能力とに基づいて、各端末への情報の配信時期を変更するように制御する、又は、各端末における情報の処理開始時期を変更するように制御する制御手順をコンピュータに実行させることを特徴とする情報配信プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、情報配信システム、情報配信方法及び情報配信プログラムに関する。
【背景技術】
【０００２】
従来、ＩＰ（Internet Protocol）で制御されるネットワークに接続する端末に提供されるサービスとして、いわゆるＷｅｂサービスがある。Ｗｅｂサービスは、一般に、ＷＷＷ（World Wide Web）関連技術を適用することで、Ｗｅｂアプリケーションの機能をネットワーク経由で実現するサービスのことをいう。
【０００３】
ここで、Ｗｅｂサービスにおける情報の配信技術として、Ａｊａｘ（Asynchronous Java（登録商標）Script + XML）が知られている（例えば、非特許文献１を参照）。Ａｊａｘは、Ｊａｖａ（登録商標）ＳｃｒｉｐｔのＨＴＴＰ（Hypertext Transfer Protocol）通信機能を使って、端末に組み込まれたＷｅｂブラウザがＷｅｂサーバとＸＭＬ（Extensible Markup Language）形式のデータを非同期に通信して、その通信結果を動的に表示する技術である。Ａｊａｘを用いることで、Ｗｅｂサーバの存在を感じさせないシームレスなＷｅｂアプリケーションを実現することができる。また、Ａｊａｘを用いて、複数の端末間での双方向通信をリアルタイムで行なうＢａｙｅｕｘプロトコルも知られている（例えば、非特許文献２を参照）。
【０００４】
また、Ｗｅｂサービスにより提供された情報を端末にて出力する際に、サーバから端末へ配信された情報を蓄積しておき、所定の出力条件となったタイミング（例えば、指定された時刻となったタイミング）で、蓄積していた情報を端末の出力デバイスに出力する技術も知られている（例えば、特許文献１を参照）。
【０００５】
また、Ｗｅｂサービスには、利用者がサーバから能動的に情報を取得するのではなく、発信者が利用者にサーバから情報を提供するプッシュ型情報サービスがある。さらに、近年では、複数の利用者（端末）間でＷｅｂサービスを共有するシステムも登場している。プッシュ型サービスにＡｊａｘを適用したり、Ｗｅｂサービスの共有システムにＢａｙｅｕｘプロトコルを適用したりすることで、情報配信のリアルタイム性を確保することができる。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開２００６−３０９６１６号公報
【非特許文献】
【０００７】
【非特許文献１】“Ajax: A New Approach to Web Applications”、［online］、［平成２２年７月２２日検索］、インターネット＜http://www.adaptivepath.com/publications/essays/archives/000385.php＞
【非特許文献２】“The Bayeux Specification”、［online］、［平成２２年７月２２日検索］、インターネット＜http://svn.cometd.com/trunk/bayeux/bayeux.html＞
【発明の概要】
【発明が解決しようとする課題】
【０００８】
しかし、複数の端末にて情報を共有する場合、配信された情報が各端末にて出力されるタイミングが必ずしも同期しないという課題があった。すなわち、サーバからの情報の伝送速度や、配信された情報に対する端末の処理時間は、情報を共有する各端末間で異なる場合がある。伝送速度や処理時間が情報を共有する端末間で異なる場合、上記したＡｊａｘやＢａｙｅｕｘプロトコルのような配信技術を用いて情報配信のリアルタイム性を確保しても、配信された情報が各端末にて出力されるタイミングが異なってしまう。また、上記した出力条件を用いた技術は、一つの端末における情報が出力されるタイミングを制御するに過ぎない。
【０００９】
そこで、この発明は、上述した従来技術の課題を解決するためになされたものであり、複数の端末にて情報を共有する場合に、配信された情報が各端末にて出力されるタイミングの同期性を向上させることが可能となる情報配信システム、情報配信方法及び情報配信プログラムを提供することを目的とする。
【課題を解決するための手段】
【００１０】
上述した課題を解決し、目的を達成するために、本願の開示する情報配信システムは、配信された情報に対して処理を行なって利用者に出力する複数の端末に対して、情報提供装置から複数の情報を順次配信する際に、当該複数の端末それぞれの情報処理完了状況と情報処理能力とに基づいて、各端末への情報の配信時期を変更するように制御する、又は、各端末における情報の処理開始時期を変更するように制御する制御手段を備えたことを特徴とする。
【００１１】
また、本願の開示する情報配信方法は、配信された情報に対して処理を行なって利用者に出力する複数の端末に対して、情報提供装置から複数の情報を順次配信する際に、当該複数の端末それぞれの情報処理完了状況と情報処理能力とに基づいて、各端末への情報の配信時期を変更するように制御する、又は、各端末における情報の処理開始時期を変更するように制御する制御ステップを含んだことを特徴とする。
【００１２】
また、本願の開示する情報配信プログラムは、配信された情報に対して処理を行なって利用者に出力する複数の端末に対して、情報提供装置から複数の情報を順次配信する際に、当該複数の端末それぞれの情報処理完了状況と情報処理能力とに基づいて、各端末への情報の配信時期を変更するように制御する、又は、各端末における情報の処理開始時期を変更するように制御する制御手順をコンピュータに実行させることを特徴とする。
【発明の効果】
【００１３】
本願の開示する情報配信システム、情報配信方法及び情報配信プログラムによれば、複数の端末にて情報を共有する場合に、配信された情報が各端末にて出力されるタイミングの同期性を向上させることが可能となる。
【図面の簡単な説明】
【００１４】
【図１】図１は、実施例１に係る情報配信システムの概要を説明するための図（１）である。
【図２】図２は、実施例１に係る情報配信システムの概要を説明するための図（２）である。
【図３】図３は、実施例１に係る情報配信システムが有するＡｐｐサーバの構成を説明するための図である。
【図４】図４は、端末一覧テーブルの一例を説明するための図である。
【図５】図５は、推定時間テーブルの一例を説明するための図である。
【図６】図６は、推定時間取得方法の具体例を説明するための図である。
【図７】図７は、未完了情報数の一例を説明するための図である。
【図８】図８は、実施例１に係る待機要否判定部を説明するための図である。
【図９】図９は、待機時間算出部を説明するための図である。
【図１０】図１０は、実施例１に係る情報配信システムが有するＡｐｐサーバによる処理の手順を説明するためのフローチャートである。
【図１１】図１１は、実施例１の第１の変形例を説明するための図である。
【図１２】図１２は、実施例１の第２の変形例を説明するための図である。
【図１３】図１３は、実施例２に係る情報配信システムの概要を説明するための図である。
【図１４】図１４は、実施例２に係る情報配信システムが有するＡｐｐサーバの構成を説明するための図である。
【図１５】図１５は、優先度テーブルの一例を説明するための図である。
【図１６】図１６は、配信可否判定部を説明するための図である。
【図１７】図１７は、実施例２に係る情報配信システムにより作成される履歴情報を説明するための図である。
【図１８】図１８は、実施例２に係る情報配信システムが有するＡｐｐサーバによる処理の手順を説明するためのフローチャートである。
【図１９】図１９は、実施例３に係る情報配信システムが有するＡｐｐサーバの構成を説明するための図である。
【図２０】図２０は、実施例３に係る配信可否判定部及び待機要否判定部を説明するための図である。
【図２１】図２１は、実施例３に係る情報配信システムが有するＡｐｐサーバによる処理の手順を説明するためのフローチャートである。
【図２２】図２２は、Ｗｅｂコンテンツ共有システムの一例を説明するための図である。
【発明を実施するための形態】
【００１５】
以下、本願の開示する情報配信システム、情報配信方法及び情報配信プログラムの実施例を詳細に説明する。なお、以下の実施例により本発明が限定されるものではない。
【実施例１】
【００１６】
［実施例１に係る情報配信システムの概要］
まず、図１及び図２を用いて、実施例１に係る情報配信システムの概要を説明する。図１及び図２は、実施例１に係る情報配信システムの概要を説明するための図である。
【００１７】
ここで、実施例１に係る情報配信システムは、Ｗｅｂサービスを提供するためのシステムであり、具体的には、複数の利用者間で共有されるＷｅｂサービスを提供するためのシステムである。
【００１８】
例えば、実施例１に係る情報配信システムは、Ｗｅｂアプリケーションを動作することで利用者に情報を配信する情報配信装置として、図１の（Ａ）に示すように、アプリケーション（Ａｐｐ：Application）サーバ１０を有する。Ａｐｐサーバ１０は、利用者が使用する端末に対して、利用者が所望する情報を配信する。ここで、利用者が使用する端末は、Ａｐｐサーバ１０との間でＨＴＴＰ（Hypertext Transfer Protocol）通信を行ない、Ａｐｐサーバ１０から配信された情報を自装置に組み込まれたＷｅｂブラウザ機能により処理して、利用者に対して出力する。そして、実施例１に係る情報配信システムは、Ａｐｐサーバ１０から情報が配信される端末として、図１の（Ａ）に示すように、ＰＣ（Personal Computer）としての端末１や、携帯電話としての端末２や、ＨＧＷ（Home Gateway）と接続されるゲーム機としての端末３などを有する。
【００１９】
図１の（Ａ）に示すＡｐｐサーバ１０は、情報を共有する複数の利用者が利用する複数の端末に対して、複数の情報を順次配信する。しかし、配信先の複数の端末それぞれが、Ａｐｐサーバ１０から同時に配信された情報を利用者に対して出力するまでに要する時間には、各端末の情報処理能力が異なる場合、時間差が生じる。ここで、情報処理能力とは、Ａｐｐサーバ１０から情報を端末に配信してから当該端末が当該情報に対する処理を完了するまでに要すると推定される推定時間である。より具体的には、情報処理能力としての推定時間とは、Ａｐｐサーバ１０の情報配信時から配信先の端末の情報受信時までの時間である伝送時間（以下、「下り伝送時間」と記載する）と、配信先の端末の情報受信時から当該配信先の端末における情報処理完了時までの時間である「処理時間」との合計時間である。
【００２０】
例えば、端末１〜３それぞれにおける下り伝送時間は、Ａｐｐサーバ１０と端末１〜３それぞれとを結ぶ回線の下り伝送速度によって定まる。また、端末１〜３それぞれにおける処理時間は、例えば、端末１〜３それぞれのＣＰＵ（Central Processing Unit）性能や、端末１〜３それぞれのＲＡＭ（Random Access Memory）容量、端末１〜３それぞれの並列処理タスクの状況など、様々な要因により定まる。なお、配信先の端末は、情報の出力が完了すると、情報出力完了通知をＡｐｐサーバ１０に送信する。情報出力完了通知の送信時からＡｐｐサーバ１０における情報出力完了通知の受信時までの時間である「上り伝送時間」は、Ａｐｐサーバ１０と配信先の端末とを結ぶ回線の「上り伝送速度」により定まる。
【００２１】
したがって、例えば、プッシュ型情報サービスを実行するために、Ａｐｐサーバ１０が情報処理能力の異なる端末１及び端末２に対して、サッカーなどのスポーツ実況に係る情報を同時に配信すると、図１の（Ｂ）に示すように、端末１にて情報が出力される時間と、端末２にて情報が出力される時間とには、時間差（Ｌ）が生じることが推定される。例えば、時間差（Ｌ）は、図１の（Ｂ）に示すように、端末１の平均下り伝送時間（Ｄ１）及び端末１の平均処理時間（Ｔ１）の合計時間（端末１の推定時間）と、端末２の平均下り伝送時間（Ｄ２）及び端末２の平均処理時間（Ｔ２）の合計時間（端末２の推定時間）との差分として算出される。
【００２２】
そこで、実施例１に係る情報配信システムのＡｐｐサーバ１０は、複数の端末に対して複数の情報を順次配信する際に、当該複数の端末それぞれの情報処理完了状況と情報処理能力とに基づいて、各端末への情報の配信時期を変更するように制御する。
【００２３】
具体的には、実施例１に係るＡｐｐサーバ１０は、情報配信先の複数の端末それぞれの情報処理完了状況として、Ａｐｐサーバ１０からの情報配信時における複数の端末それぞれの未処理の情報数である未完了情報数を取得する。例えば、Ａｐｐサーバ１０は、端末１及び端末２に対して情報を配信する際に、端末１及び端末２それぞれの未完了情報数を取得する（図２の（１）を参照）。一例を挙げると、Ａｐｐサーバ１０は、端末１に対して配信した情報数と、端末１から受信した情報出力完了通知の数との差分から、端末１の未完了情報数を取得する。同様に、Ａｐｐサーバ１０は、端末２に対して配信した情報数と、端末２から受信した情報出力完了通知の数との差分から、端末２の未完了情報数を取得する。
【００２４】
そして、実施例１に係るＡｐｐサーバ１０は、取得した各端末の未完了情報数に基づいて、情報の配信を待機させる待機端末が存在するか否かを判定する。具体的には、Ａｐｐサーバ１０は、未完了情報数が異なる端末が存在する場合、未完了情報数が最大となる端末以外の端末を待機端末として判定する。例えば、Ａｐｐサーバ１０は、端末１の未完了情報数が「０」であり、端末２の未完了情報数が「１」である場合、未完了情報数が「０」である端末１を待機端末として判定する（図２の（２）を参照）。
【００２５】
そして、実施例１に係るＡｐｐサーバ１０は、待機端末が存在すると判定した場合、情報処理能力である推定時間を複数の端末ごとに取得する。例えば、Ａｐｐサーバ１０は、端末１における平均下り伝送時間と、端末１における平均処理時間とを取得して、これらの合計時間を端末１の推定時間として算出する。また、Ａｐｐサーバ１０は、端末２における平均下り伝送時間と、端末２における平均処理時間とを取得して、これらの合計時間を端末２として推定時間を算出する。なお、平均下り時間及び平均処理時間の取得方法については、後に詳述する。
【００２６】
そして、実施例１に係るＡｐｐサーバ１０は、待機端末の推定時間と当該待機端末以外の他の端末の推定時間との時間差に基づいて、待機端末に対する情報配信の待機時間を設定することで、待機端末への情報配信時期を遅らせる。例えば、Ａｐｐサーバ１０は、端末１の推定時間と端末２の推定時間との時間差（Ｌ）を待機時間として算出し、端末１への情報配信を待機時間（Ｌ）分遅らせる（図２の（３）を参照）。なお、待機時間の算出方法については、後に詳述する。
【００２７】
このように、実施例１に係る情報配信システムは、情報配信のタイミングを情報配信ごとに制御することで、配信された情報が各端末にて出力されるタイミングの同期性を向上させることが可能となる。
【００２８】
［実施例１に係るＡｐｐサーバの構成］
次に、図３などを用いて、実施例１に係る情報配信システムが有するＡｐｐサーバ１０の構成を説明する。図３は、実施例１に係る情報配信システムが有するＡｐｐサーバの構成を説明するための図である。
【００２９】
実施例１に係る情報配信システムが有するＡｐｐサーバ１０は、以下に説明する各部が汎用的なサーバなどに備えられることによって実現され、図３に示すように、通信部１１と、記憶部１２と、制御部１３とを有する。
【００３０】
通信部１１は、ＨＴＴＰ通信用の一般的なインタフェース及びライブラリを有し、Ａｐｐサーバ１０と接続される複数の端末（例えば、図１の（Ａ）に示す端末１〜３）との間で情報を送受信する。記憶部１２は、制御部１３における各種制御に用いられる情報を記憶し、図３に示すように、端末一覧テーブル１２ａと、推定時間テーブル１２ｂとを有する。例えば、記憶部１２は、ＲＡＭ（Random  Access  Memory）、ＲＯＭ（Read  Only  Memory）、フラッシュメモリ（flash  memory）などの半導体メモリ素子、または、ハードディスク、光ディスクなどである。
【００３１】
端末一覧テーブル１２ａは、実施例１に係る情報配信システムの管理者により予め設定された情報として、Ａｐｐサーバ１０に接続される各端末が所属する同期対象グループの情報を記憶する。ここで、同期対象グループとは、Ａｐｐサーバ１０から配信される情報を共有するグループのことであり、上述したＡｐｐサーバ１０の制御により情報の出力タイミングが同期されるように設定されたグループのことである。例えば、同期対象グループは、実施例１に係る情報配信システムが提供する情報共有サービスの種類ごとに設定され、利用者は、自身が所属したい同期対象グループに対して、自身が利用する端末の情報を登録する。なお、同期対象グループは、例えば、Ａｐｐサーバ１０や、Ａｐｐサーバ１０に接続される装置などが、利用者の登録情報を収集することで自動的に取得される場合であっても良い。
【００３２】
これにより、例えば、端末一覧テーブル１２ａは、端末のＩＤ（端末ＩＤ）と、当該端末が所属する同期対象グループのＩＤ（同期対象グループＩＤ）とを対応付けて記憶する。図４は、端末一覧テーブルの一例を説明するための図である。図４に示す一例では、端末一覧テーブル１２ａは、「端末ＩＤ：１」と「同期対象グループＩＤ：Ｇ１，Ｇ３」とを対応付けて記憶している。また、図４に示す一例では、端末一覧テーブル１２ａは、「端末ＩＤ：２」と「同期対象グループＩＤ：Ｇ１，Ｇ３」とを対応付けて記憶している。また、図４に示す一例では、端末一覧テーブル１２ａは、「端末ＩＤ：３」と「同期対象グループＩＤ：Ｇ１，Ｇ２」とを対応付けて記憶している。このように、利用者の登録により、一つの端末は、複数の同期対象グループに所属することができる。なお、以下では、図１の（Ａ）に示す端末１が「端末ＩＤ：１」であり、図１の（Ａ）に示す端末２が「端末ＩＤ：２」であり、図１の（Ａ）に示す端末３が「端末ＩＤ：３」であるとして説明する。
【００３３】
例えば、端末１の利用者から「同期対象グループＩＤ：Ｇ３」の情報配信要求を受け付けると、通信部１１は、端末一覧テーブル１２ａを参照して、端末１及び端末２に対して、サッカーの実況情報（例えば、テキストデータや画像データ）を順次送信する。
【００３４】
図３に戻って、推定時間テーブル１２ｂは、情報処理能力としての推定時間をＡｐｐサーバ１０に接続される複数の端末ごとに記憶する。具体的には、推定時間テーブル１２ｂは、各端末の「平均下り伝送時間」及び「平均処理時間」を推定時間として、Ａｐｐサーバ１０に接続される複数の端末ごとに記憶する。図５は、推定時間テーブルの一例を説明するための図である。
【００３５】
図５に示す一例では、「端末ＩＤ：１」と「推定時間（平均下り伝送時間：０．１秒、平均処理時間：０．２秒）」とを対応付けて記憶している。また、図５に示す一例では、「端末ＩＤ：２」と「推定時間（平均下り伝送時間：１秒、平均処理時間：０．２秒）」とを対応付けて記憶している。また、図５に示す一例では、「端末ＩＤ：３」と「推定時間（平均下り伝送時間：２秒、平均処理時間：１０秒）」とを対応付けて記憶している。このように、推定時間テーブル１２ｂは、Ａｐｐサーバ１０が情報を配信する全端末の推定時間を記憶する。
【００３６】
ここで、推定時間は、例えば、実施例１に係る情報配信システムの管理者により予め登録される情報である。以下、図６を用いて、推定時間取得方法の具体例について説明する。図６は、推定時間取得方法の具体例を説明するための図である。
【００３７】
例えば、情報配信システムの管理者は、過去の実測値や仮想環境における実測値から、各端末の推定時間を取得する。まず、管理者は、図６に示すように、一回の情報配信において、Ａｐｐサーバ１０にて記録されたタイムスタンプ「Ａ及びＤ」と、例えば、端末１にて記録されたタイムスタンプ「Ｂ及びＣ」とを取得する。ここで、図６に示すように、「Ａ」は、Ａｐｐサーバ１０にて記録された「情報配信時のタイムスタンプ」であり、「Ｄ」は、Ａｐｐサーバ１０にて記録された「情報出力完了通知受信時のタイムスタンプ」である。また、図６に示すように、「Ｂ」は、端末１にて記録された「情報受信時のタイムスタンプ」であり、「Ｃ」は、端末１にて記録された「情報出力時のタイムスタンプ」である。
【００３８】
ここで、端末１の処理時間は、図６に示すように、「Ｃ−Ｂ」を算出することで取得することができる。また、Ａｐｐサーバ１０と端末１との間での往復伝送時間と端末１の処理時間との和「往復伝送時間＋処理時間」は、図６に示すように、「Ｄ−Ａ」を算出することで取得することができる。したがって、Ａｐｐサーバ１０と端末１との間での往復伝送時間は、「（Ｄ−Ａ）−（Ｃ−Ｂ）」を算出することで取得することができる。
【００３９】
そして、Ａｐｐサーバ１０から端末１への情報の下り伝送時間は、「往復伝送時間」を所定の値「Ｘ」で除することで算出することができる。例えば、Ａｐｐサーバ１０と端末１とを接続する回線の上り伝送速度及び下り伝送速度が対称であると仮定できるのであれば、「Ｘ」は、「２」と設定される。また、Ａｐｐサーバ１０と端末１とを接続する回線の上り伝送速度及び下り伝送速度が非対称であり、例えば、「上り伝送速度：下り伝送速度」が、「３：２」であることが経験的に判明しているならば、「Ｘ」は、「２．５」と設定される。
【００４０】
上述した方法により、例えば、管理者は、複数の情報を配信するごとに端末１の処理時間及び下り伝送時間を取得する。そして、管理者は、取得された複数の処理時間及び複数の下り伝送時間それぞれを平均することで「平均下り伝送時間」及び「平均処理時間」を算出する。そして、管理者は、端末１の推定時間（Ｙ）を、「平均下り伝送時間＋平均処理時間」により算出する。
【００４１】
このようにして、端末１以外の端末についても、推定時間が算出され、その結果が推定時間テーブル１２ｂに格納される。なお、推定時間の算出及び格納処理は、例えば、Ａｐｐサーバ１０及び各端末に接続される装置により自動的に行なわれる場合であっても良い。
【００４２】
図３に戻って、制御部１３は、Ａｐｐサーバ１０における各種制御を行なう。特に、制御部１３は、情報配信のタイミング制御を行なうためのものとして、図３に示すように、未完了情報数取得部１３ａと、待機要否判定部１３ｂと、待機時間算出部１３ｃと、配信制御部１３ｄとを有する。
【００４３】
未完了情報数取得部１３ａは、通信部１１が情報を配信する際に、情報配信先の各端末の未完了情報数を取得する。例えば、通信部１１が情報を端末１及び端末２に配信する際に、未完了情報数取得部１３ａは、通信部１１が端末１に対して配信した情報数と、端末１から通信部１１が受信した情報出力完了通知の数との差分から、端末１の未完了情報数を取得する。また、未完了情報数取得部１３ａは、通信部１１が端末２に対して配信した情報数と、端末２から通信部１１が受信した情報出力完了通知の数との差分から、端末２の未完了情報数を取得する。図７は、未完了情報数の一例を説明するための図である。
【００４４】
例えば、未完了情報数取得部１３ａは、図７に示すように、「端末ＩＤ：１」の端末１における「未完了情報数：０」を取得し、「端末ＩＤ：２」の端末２における「未完了情報数：１」を取得する。
【００４５】
図３に戻って、待機要否判定部１３ｂは、未完了情報数取得部１３ａにより取得された未完了情報に基づいて、待機端末が存在するか否かを判定する。具体的には、待機要否判定部１３ｂは、未完了情報数が異なる場合、未完了情報数が最大となる端末以外の端末を待機端末として判定する。図８は、実施例１に係る待機要否判定部を説明するための図である。
【００４６】
例えば、待機要否判定部１３ｂは、「未完了情報数：０」の端末１と、「未完了情報数：１」の端末２が存在することから、待機処理が必要と判定する。そして、待機要否判定部１３ｂは、図８に示すように、未完了情報数が「０」の端末である「端末ＩＤ：１」の端末１を待機端末として判定する。換言すれば、待機要否判定部１３ｂは、端末２を待機不要端末として判定する。
【００４７】
なお、未完了情報数が最大となる端末以外の端末が複数存在する場合、待機要否判定部１３ｂは、未完了情報数が最大となる端末以外の複数の端末を待機端末として判定する。
【００４８】
図３に戻って、待機時間算出部１３ｃは、待機要否判定部１３ｂにより待機端末として判定された端末に対して、配信情報時期を待機するための待機時間を算出する。図９は、待機時間算出部を説明するための図である。
【００４９】
すなわち、待機時間算出部１３ｃは、図９に示すように、同期対象グループにおける推定時間（Ｙ）の最大値である「Ｙｍａｘ」と、待機端末の推定時間（Ｙ）である「Ｙｗ」を推定時間テーブル１２ｂから取得する。ここで、「Ｙｍａｘ」は、未完了情報数が最大となる端末の推定時間であることが想定される。そして、待機時間算出部１３ｃは、図９に示すように、「Ｙｍａｘ−Ｙｗ」を待機端末の待機時間として算出する。例えば、図８に示す一例により端末１が待機端末として判定された場合、待機時間算出部１３ｃは、図５に例示する推定時間テーブル１２ｂを参照して、端末１の待機時間として「（１＋０．２）−（０．１＋０．２）＝０．９秒」を算出する。
【００５０】
なお、同期対象グループＩＤが「Ｇ１」であり、かつ、端末３の未完了情報数が最大となった結果、待機要否判定部１３ｂにより端末１及び端末２が待機端末であると判定された場合、待機時間算出部１３ｃは、以下のように待機時間を算出する。すなわち、待機時間算出部１３ｃは、図５に例示する推定時間テーブル１２ｂを参照して、「Ｙｍａｘ」が「２＋１０＝１２秒」であると取得する。そして、待機時間算出部１３ｃは、図５に例示する推定時間テーブル１２ｂを参照して、「端末１のＹｗ」が「１．２秒」であることを取得して、端末１の待機時間として「１１．７秒」を算出する。また、待機時間算出部１３ｃは、図５に例示する推定時間テーブル１２ｂを参照して、端末２の待機時間として「１０．８秒」を算出する。
【００５１】
図３に戻って、配信制御部１３ｄは、待機端末への情報配信を待機時間算出部１３ｃにより算出された待機時間分遅らせるように、通信部１１を制御する。例えば、配信制御部１３ｄは、図８に示す一例により端末１が待機端末として判定された場合、待機時間算出部１３ｃにより算出された「待機時間：０．９秒」を端末１に設定することで、情報配信時期の変更が行なわれるように通信部１１を制御する。なお、配信制御部１３ｄは、待機時間を用いた情報配信制御を行なうとともに、通常の情報配信（待機を伴わない配信）についても制御を行なう。
【００５２】
［実施例１に係るＡｐｐサーバによる処理の手順］
続いて、図１０を用いて、実施例１に係る情報配信システムが有するＡｐｐサーバによる処理の手順を説明する。図１０は、実施例１に係る情報配信システムが有するＡｐｐサーバによる処理の手順を説明するためのフローチャートである。
【００５３】
図１０に示すように、実施例１に係るＡｐｐサーバ１０は、同期対象グループＩＤが指定されたことにより、複数の端末に対する情報配信開始要求を受け付けたか否かを判定する（ステップＳ１０１）。ここで、情報配信開始要求を受け付けない場合（ステップＳ１０１否定）、Ａｐｐサーバ１０は、待機状態となる。
【００５４】
一方、情報配信開始要求を受け付けた場合（ステップＳ１０１肯定）、通信部１１ｄは、配信制御部１３ｄの制御の下、端末一覧テーブル１２ａを参照して、配信先の端末を確認し（ステップＳ１０２）、配信先の端末に対して、情報の配信を開始する（ステップＳ１０３）。
【００５５】
そして、配信制御部１３ｄは、配信すべき新規の情報があるか否かを判定する（ステップＳ１０４）。ここで、新規の情報がない場合（ステップＳ１０４否定）、Ａｐｐサーバ１０は、待機状態となる。
【００５６】
一方、新規の情報がある場合（ステップＳ１０４肯定）、未完了情報数取得部１３ａは、配信先の複数の端末それぞれの未完了情報数を取得し（ステップＳ１０５）、待機要否判定部１３ｂは、配信先の複数の端末それぞれの未完了情報数に基づいて、待機端末が存在するか否かを判定する（ステップＳ１０６）。ここで、待機端末が存在しない場合（ステップＳ１０６否定）、通信部１１ｄは、配信制御部１３ｄの制御の下、配信先の全端末に情報を配信する（ステップＳ１０７）。例えば、配信先の複数の端末それぞれの未完了情報数が同一である場合、待機要否判定部１３ｂは、待機端末が存在しないと判定し、通信部１１ｄは、全端末に情報を配信する。
【００５７】
一方、待機端末が存在する場合（ステップＳ１０６肯定）、待機時間算出部１３ｃは、待機端末の待機時間を算出する（ステップＳ１０８）。例えば、待機要否判定部１３ｂは、配信先の複数の端末それぞれの未完了情報数が異なる場合、未完了情報数が最大となる端末（待機不要端末）以外の端末を待機端末と判定する。そして、待機時間算出部１３ｃは、例えば、図９に例示する方法を用いて、待機端末の待機時間を算出する。
【００５８】
そして、通信部１１ｄは、配信制御部１３ｄの制御の下、待機不要端末に情報を配信し（ステップＳ１０９）、さらに、待機時間経過後に待機端末に対して情報を配信する（ステップＳ１１０）。なお、ステップＳ１０８の待機時間算出処理と、ステップＳ１０９の待機不要端末に対する情報配信処理とは、並行して実行される場合であっても良い。
【００５９】
ステップＳ１０７、又は、ステップＳ１１０の処理の後、配信制御部１３ｄは、情報配信終了要求を受け付けたか否かを判定する（ステップＳ１１１）。ここで、情報配信終了要求を受け付けない場合（ステップＳ１１１否定）、配信制御部１３ｄは、ステップＳ１０４の判定処理を行なう。
【００６０】
一方、情報配信終了要求を受け付けた場合（ステップＳ１１１肯定）、Ａｐｐサーバ１０は、処理を終了する。
【００６１】
［実施例１の効果］
上記したように、実施例１に係る情報配信システムは、配信された情報に対して処理を行なって利用者に出力する複数の端末に対して、Ａｐｐサーバ１０から複数の情報を順次配信する際に、制御部１３は、当該複数の端末それぞれの情報処理完了状況と情報処理能力とに基づいて、各端末への情報の配信時期を変更するように制御する。具体的には、未完了情報数取得部１３ａは、複数の端末それぞれの情報処理完了状況として、情報配信時における複数の端末それぞれの未処理の情報数である未完了情報数を取得する。そして、待機要否判定部１３ｂは、未完了情報数取得部１３ａが取得した各端末の未完了情報数に基づいて、情報の配信を待機させる待機端末が存在するか否かを判定する。
【００６２】
そして、待機時間算出部１３ｃは、待機要否判定部１３ｂにより待機端末が存在すると判定された場合、複数の端末それぞれの情報処理能力として、情報を端末に配信してから当該端末が当該情報に対する処理を完了するまでに要すると推定される推定時間を配信先の複数の端末ごとに取得する。そして、待機時間算出部１３ｃは、待機端末の推定時間と当該待機端末以外の他の端末の推定時間との時間差に基づいて、待機端末に対する情報配信の待機時間を算出する。そして、配信制御部１３ｄは、待機時間算出部１３ｃにより算出された待機時間を待機端末に設定することで、通信部１１による待機端末に対する情報配信時期を待機時間分遅延させるように制御する。
【００６３】
したがって、実施例１では、情報配信のタイミングを配信先の各端末の情報処理能力に応じて変更することができる。その結果、実施例１では、複数の端末にて情報を共有する場合に、配信された情報が各端末にて出力されるタイミングの同期性を向上させることが可能となる。
【００６４】
また、実施例１では、推定時間テーブル１２ｂが、推定時間を複数の端末ごとに記憶し、待機時間算出部１３ｃが、推定時間テーブル１２ｂから配信先の複数の端末それぞれの推定時間を取得する。したがって、実施例１では、待機時間の算出処理を、予め登録された推定時間を用いて行なうことができ、情報の出力タイミングの制御を円滑に行なうことが可能となる。
【００６５】
また、実施例１では、推定時間は、情報配信時から配信先の端末の情報受信時までの時間である下り伝送時間と、当該配信先の端末の情報受信時から当該配信先の端末における情報処理完了時までの時間である処理時間との合計時間として設定される。したがって、実施例１では、Ａｐｐサーバ１０のタイムスタンプ及び各端末のタイムスタンプを取得することで、推定時間を取得することができる。すなわち、実施例１では、Ａｐｐサーバ１０及び各端末に内蔵される時計の時刻情報を正確に揃える処理を行なうことなく、各端末の推定時間を取得することができる。その結果、実施例１では、複数の端末にて情報を共有する場合に、配信された情報が各端末にて出力されるタイミングの同期性を向上させることが可能となる。
【００６６】
［実施例１の変形例］
なお、上述した実施例１では、制御部１３の制御により、配信先の複数の端末に対する情報配信時期を変更する場合について説明した。しかし、本実施例１は、第１の変形例として、制御部１３の制御により、配信先の各端末における情報の処理開始時期を変更する場合であっても良い。
【００６７】
すなわち、配信先の各端末における情報の処理開始時期を変更する場合、配信制御部１３ｄは、情報を配信先の全端末に配信するように通信部１１を制御する。その際、配信制御部１３ｄは、待機端末に対しては、待機時間算出部１３ｃにより算出された当該待機端末の待機時間を情報とともに配信するように通信部１１を制御する。具体的には、配信制御部１３ｄは、待機端末に対して「情報受信時から、通知した待機時間が経過した後に、情報の処理を開始せよ」とする指示を送信するように通信部１１を制御する。図１１は、実施例１の第１の変形例を説明するための図である。
【００６８】
例えば、Ａｐｐサーバ１０は、端末１及び端末２に情報を配信する際に、待機端末として判定された端末１に対して、情報とともに待機時間を配信する。その結果、端末２は、情報受信時から受信した情報の処理を開始する。一方、端末１は、図１１に示すように、情報受信時から待機時間経過後に、受信した情報の処理を開始する。
【００６９】
このような待機時間を用いた制御処理によっても、配信された情報が各端末にて出力されるタイミングの同期性を向上させることが可能となる。
【００７０】
また、上述した実施例１では、推定時間テーブル１２ｂに端末ごとの推定時間が格納されている場合について説明した。しかし、本実施例１は、第２の変形例として、推定時間テーブル１２ｂに格納される端末ごとの推定時間が、さらに、情報の処理内容ごとに分類されている場合であっても良い。例えば、情報配信システムの管理者は、処理内容が異なる情報ごとに、図６を用いて説明した各端末の推定時間取得処理を行なう。なお、処理内容が異なる情報ごとの推定時間の算出及び格納処理は、上述したように、例えば、Ａｐｐサーバ１０及び各端末に接続される装置により行なわれる場合であっても良い。図１２は、実施例１の第２の変形例を説明するための図である。
【００７１】
その結果、例えば、推定時間テーブル１２ｂは、図１２に示す一例のように、「端末ＩＤ：１」の「平均下り伝送時間：０．１秒」とともに、「内容（１）」の平均処理時間が「０．１５秒」であることを記憶する。また、推定時間テーブル１２ｂは、図１２に示す一例のように、「端末ＩＤ：１」と「平均下り伝送時間：０．１秒」とともに、「内容（２）」の平均処理時間が「０．２秒」であることを記憶する。また、推定時間テーブル１２ｂは、図１２に示す一例のように、「端末ＩＤ：１」と「平均下り伝送時間：０．１秒」とともに、「内容（３）」の平均処理時間が「０．３３秒」であることを記憶する。同様に、端末２や端末３についても、推定時間テーブル１２ｂは、処理内容ごとの平均処理時間を記憶する。
【００７２】
そして、待機時間算出部１３ｃは、配信される情報の処理内容に対応する推定時間を推定時間テーブル１２ｂから取得して待機時間を算出し、配信制御部１３ｄは、待機時間算出部１３ｃが算出した待機時間を待機端末に設定する。すなわち、配信制御部１３ｄは、配信する情報の処理内容に対応する各端末の推定時間を取得することで、待機時間を用いた情報配信時期の変更制御や、待機時間を用いた情報処理開始時期の変更制御を実行する。
【００７３】
このように、情報の処理内容ごとに取得された推定時間を用いることで、配信された情報が各端末にて出力されるタイミングの同期性をさらに向上させることが可能となる。
【００７４】
また、上述した実施例１では、未完了情報数が最大となる端末以外の配信先の端末が待機端末として判定される場合について説明した。しかし、実施例１は、第３の変形例として、未完了情報数とともに、各端末の推定時間を用いて、待機端末が存在するか否かを判定する場合であっても良い。例えば、待機要否判定部１３ｂは、各端末における未完了情報数と推定時間とを掛け合わせた値（Ｚ）を算出する。そして、待機要否判定部１３ｂは、「Ｚ」が最大となった端末を待機不要端末とし、待機不要端末以外の端末を待機端末として判定する。
【００７５】
また、上述した実施例１では、推定時間テーブル１２ｂに予め格納された推定時間を用いて待機時間が算出される場合について説明した。しかし、本実施例１は、第４の変形例として、待機時間算出部１３ｃが、各端末の推定時間を取得して、待機時間を算出する場合であっても良い。例えば、通信部１１は、配信制御部１３ｄの制御により、情報配信開始直前や、情報処理中に、種々のテストデータを各端末に配信することで、現時点での各端末の推定時間を取得し、待機時間算出部１３ｃは、取得された各端末の推定時間を用いて待機時間を算出する。
【００７６】
すなわち、端末側での処理が定型化されている場合や、回線状況や各端末のハードウェア状況が安定している場合は、上述した実施例１で説明したように、予め登録された推定時間を用いて待機時間を算出しても、タイミングの同期性を向上させることが可能となる。しかし、端末側での処理が定型化されていない場合や、回線状況や各端末のハードウェア状況が不安定な場合、配信された情報が各端末にて出力されるタイミングの同期性を向上させるためには、上述した第４の変形例のように、現時点での配信先の推定時間をリアルタイムで取得して待機時間を算出することが望ましい。
【実施例２】
【００７７】
実施例２では、実施例１とは異なる情報配信制御により、配信された情報が各端末にて出力されるタイミングの同期性を向上させる場合について説明する。
【００７８】
［実施例２に係る情報配信システムの概要］
まず、図１３を用いて、実施例２に係る情報配信システムの概要を説明する。図１３は、実施例２に係る情報配信システムの概要を説明するための図である。
【００７９】
ここで、実施例２に係る情報配信システムは、図１の（Ａ）を用いて説明したように、実施例１と同様に、複数の利用者（端末）間で共有されるＷｅｂサービスを提供するためのシステムである。
【００８０】
すなわち、実施例２に係る情報配信システムは、Ｗｅｂアプリケーションを動作することで利用者に情報を配信する情報配信装置であるＡｐｐサーバ１０と、Ａｐｐサーバ１０から配信された情報に対して処理を行なって利用者に出力する複数の端末（端末１〜３など）を有する。
【００８１】
そして、実施例２に係る情報配信システムが有するＡｐｐサーバ１０は、実施例１と同様に、情報を共有する複数の端末（例えば、同一の同期対象グループに所属する複数の端末）に対して複数の情報を順次配信する。
【００８２】
ここで、図１３の左図に示すように、情報の配信先である端末１及び端末２それぞれの情報処理能力が異なる、すなわち、下り伝送時間と処理時間との合計時間である推定時間が異なると仮定する。具体的には、端末１の推定時間に対して、端末２の推定時間が大きいと仮定する。この場合、端末２の情報出力時期は、図１３の左図に示すように、端末１の情報出力時期に比べて遅延が生じ、情報１、情報２及び情報３を順次配信することで、端末２における遅延が拡大する。例えば、情報処理能力が異なる端末１及び端末２に対してサッカー実況に係る情報を同時に配信する場合、端末２においてサッカーの試合の状況が出力される時期が、端末１と比較して遅れることとなる。
【００８３】
そこで、実施例２に係るＡｐｐサーバ１０は、図１３に示すように、配信する情報の取捨選択を行なう。すなわち、実施例２に係るＡｐｐサーバ１０は、情報を配信する際に、複数の端末それぞれの情報処理完了状況と配信予定情報の属性とに基づいて、配信予定情報の配信可否を決定することにより、各端末へ配信される情報量を制御する。
【００８４】
具体的には、実施例２に係るＡｐｐサーバ１０は、実施例１と同様に、情報配信時に、配信先の各端末の情報処理完了状況として、未完了情報数を取得する。
【００８５】
そして、実施例２に係るＡｐｐサーバ１０は、さらに、配信予定情報の属性を取得する。ここで、配信予定情報の属性とは、例えば、Ａｐｐサーバ１０が配信しようとする情報の優先度である。例えば、最も高い優先度が「１」とされ、優先度が下がるにつれて、優先度の値が「２」、「３」、「４」、「５」となっている。
【００８６】
そして、実施例２に係るＡｐｐサーバ１０は、取得した各端末の未完了情報数及び配信予定情報の優先度に基づいて、当該配信予定情報を配信しない配信不可端末が存在するか否かを判定する。例えば、Ａｐｐサーバ１０は、配信予定情報である情報２の配信時に、端末１の未完了情報数が「０」であり、かつ、端末２の未完了情報数が「１」であることを取得する。そして、Ａｐｐサーバ１０は、例えば、未完了情報数が最大となっている端末２を「配信不可候補端末」とする。そして、Ａｐｐサーバ１０は、例えば、配信予定情報の優先度が「１」で無いならば、「配信不可候補端末」を「配信不可端末」と判定する。
【００８７】
図１３の右図に示す一例では、Ａｐｐサーバ１０は、配信予定情報の優先度が「３」であることから、配信不可候補端末である端末２を配信不可端末として判定する。
【００８８】
そして、実施例２に係るＡｐｐサーバ１０は、配信不可端末が存在すると判定された場合、当該配信不可端末に対して、配信予定情報の配信を中止するように制御する。
【００８９】
すなわち、図１３の右図に示す一例では、Ａｐｐサーバ１０は、情報２の端末２に対する配信を中止するように制御する。これにより、図１３に示すように、端末２における情報出力の遅延が縮小される。すなわち、実施例２においては、Ａｐｐサーバ１０が情報処理能力の異なる端末１及び端末２に対してサッカー実況に係る情報を配信する場合に、端末２に対しては、優先度が低い情報の配信を中止することで、端末２における情報出力の遅延が縮小される。
【００９０】
このように、実施例２に係る情報配信システムは、配信する情報量を情報配信ごとに制御することで、配信された情報が各端末にて出力されるタイミングの同期性を向上させる。
【００９１】
［実施例２に係るＡｐｐサーバの構成］
次に、図１４などを用いて、実施例２に係る情報配信システムが有するＡｐｐサーバ１０の構成を説明する。図１４は、実施例２に係る情報配信システムが有するＡｐｐサーバの構成を説明するための図である。
【００９２】
実施例２に係る情報配信システムが有するＡｐｐサーバ１０は、図３を用いて説明した実施例１に係るＡｐｐサーバ１０と同様に、通信部１１と、記憶部１２と、制御部１３とを有するが、記憶部１２が、推定時間テーブル１２ｂの替わりに優先度テーブル１２ｃを有し、また、制御部１３が、待機要否判定部１３ｂ及び待機時間算出部１３ｃの替わりに配信可否判定部１３ｅを有する点が異なる。以下、これらを中心に説明する。
【００９３】
図１４に示す通信部１１は、図３を用いて説明した通信部１１と同様の処理を行なう。また、図１４に示す端末一覧テーブル１２ａは、図３及び図４を用いて説明した端末一覧テーブル１２ａと同様の内容を記憶する。
【００９４】
図１４に示す優先度テーブル１２ｃは、配信される情報の優先度を記憶する。図１５は、優先度テーブルの一例を説明するための図である。ここで、図１５に示す優先度テーブルは、実施例２に係るＡｐｐサーバ１０がサッカー実況に係る情報を配信する際に用いられる情報である。
【００９５】
図１５に示す一例では、最も高い優先度が「１」とされ、優先度が下がるにつれて、優先度の値が「２」、「３」、「４」、「５」となっている。図１５に示す一例では、情報同期の必要性が無いが、情報配信の必要性がある情報、換言すれば、各端末での出力が同期しなくても良いが、欠落しては困る情報は、優先度が「１」となる。係る情報の一例としては、図１５に示すように、Ｗｅｂアプリケーションが端末に対してメンテナンスに入るなど、急を有する通知が挙げられる。
【００９６】
また、図１５に示す一例では、情報同期の必要性があり、かつ、情報配信の必要性がある情報、換言すれば、各端末での出力を必ず同期させることが望ましく、かつ、欠落しては困る情報は、優先度が「２」となる。係る情報の一例としては、図１５に示すように、試合の開始、終了、得点に係る情報が挙げられる。
【００９７】
また、図１５に示す一例では、情報同期の必要性があり、かつ、情報配信の必要性がない情報、換言すれば、各端末での出力を必ず同期させることが望ましく、かつ、欠落しても良い情報は、優先度が「３」〜「５」に振り分けられる。例えば、優先度が「３」の情報は、図１５に示すように、試合の様子を伝える実況に係る情報となる。また、優先度が「４」の情報は、図１５に示すように、試合に対する友人、知人の感想となる。また、優先度が「５」の情報は、図１５に示すように、試合に対する他人の感想が挙げられる。
【００９８】
なお、図１５に示す一例では、サッカー実況における複数の情報それぞれの優先度のみを示している。しかし、優先度テーブル１２ｃは、サッカー実況以外にも、情報共有サービスの種類ごとに、情報の優先度を記憶している。
【００９９】
図１４に戻って、未完了情報数取得部１３ａは、図３を用いて説明した未完了情報数取得部１３ａと同様の処理を行なう。
【０１００】
そして、図１４に示す配信可否判定部１３ｅは、未完了情報数取得部１３ａが取得した配信先の各端末の未完了情報数、及び、優先度テーブル１２ｃから取得した配信予定情報の優先度に基づいて、配信予定情報を配信しない配信不可端末が存在するか否かを判定する。なお、以下では、図４に示す端末一覧テーブル１２ａにおいて「同期対象グループＩＤ：Ｇ１」に所属する端末１、端末２及び端末３に対して、サッカーの実況情報が順次配信されている場合について説明する。図１６は、配信可否判定部を説明するための図である。
【０１０１】
例えば、図１６の（Ａ）及び（Ｂ）に示すように、「端末ＩＤ：１」である端末１の未完了情報数が「０」であり、「端末ＩＤ：２」である端末２の未完了情報数が「１」であり、「端末ＩＤ：３」である端末３の未完了情報数が「６」であることが、未完了情報数取得部１３ａにより取得されたとする。この場合、配信可否判定部１３ｅは、例えば、未完了情報数が最大となる端末３を配信不可候補端末として判定する。
【０１０２】
しかし、配信可否判定部１３ｅは、図１６の（Ａ）に示すように、配信予定情報の優先度が「１」である場合、配信不可端末が存在しないと判定して、全ての端末に配信可と判定する。
【０１０３】
一方、配信可否判定部１３ｅは、図１６の（Ｂ）に示すように、配信予定情報の優先度が「３」である場合、配信不可候補端末である端末３（ＩＤ：３）を配信不可端末として判定する。
【０１０４】
図１４に戻って、実施例２に係る配信制御部１３ｄは、配信可否判定部１３ｅにより配信不可端末と判定された端末に対して、配信予定情報の配信を中止するように、通信部１１を制御する。図１７は、実施例２に係る情報配信システムにより作成される履歴情報を説明するための図である。
【０１０５】
すなわち、実施例２に係る制御部１３の制御処理により、「端末ＩＤ：１，２」において、優先度が「３」である「配信情報：シュート決まった！」の履歴情報における「配信済みＦＬＡＧ」は、図１７に示すように、「配信済」となる。また、「端末ＩＤ：３」において、優先度が「３」である「配信情報：シュート決まった！」の履歴情報における「配信済みＦＬＡＧ」は、図１７に示すように、「未配信」となる。
【０１０６】
なお、配信可否判定部１３ｅは、未完了情報数が所定の閾値以上となっている端末全てを配信不可候補端末とする場合であっても良い。また、配信可否判定部１３ｅは、例えば、配信予定情報の優先度が「３」以上である場合に、配信不可候補端末を配信不可端末と判定する場合であっても良い。
【０１０７】
［実施例２に係るＡｐｐサーバによる処理の手順］
続いて、図１８を用いて、実施例２に係る情報配信システムが有するＡｐｐサーバによる処理の手順を説明する。図１８は、実施例２に係る情報配信システムが有するＡｐｐサーバによる処理の手順を説明するためのフローチャートである。
【０１０８】
図１８に示すように、実施例２に係るＡｐｐサーバ１０は、同期対象グループＩＤが指定されたことにより、複数の端末に対する情報配信開始要求を受け付けたか否かを判定する（ステップＳ２０１）。ここで、情報配信開始要求を受け付けない場合（ステップＳ２０１否定）、Ａｐｐサーバ１０は、待機状態となる。
【０１０９】
一方、情報配信開始要求を受け付けた場合（ステップＳ２０１肯定）、通信部１１ｄは、配信制御部１３ｄの制御の下、端末一覧テーブル１２ａを参照して、配信先の端末を確認し（ステップＳ２０２）、配信先の端末に対して、情報の配信を開始する（ステップＳ２０３）。
【０１１０】
そして、配信制御部１３ｄは、配信すべき新規の情報があるか否かを判定する（ステップＳ２０４）。ここで、新規の情報がない場合（ステップＳ２０４否定）、Ａｐｐサーバ１０は、待機状態となる。
【０１１１】
一方、新規の情報がある場合（ステップＳ２０４肯定）、未完了情報数取得部１３ａは、配信先の複数の端末それぞれの未完了情報数を取得し、配信可否判定部１３ｅは、優先度テーブル１２ｃを参照して、配信予定情報の優先度を取得する（ステップＳ２０５）。
【０１１２】
そして、配信可否判定部１３ｅは、配信先の複数の端末それぞれの未完了情報数及び配信予定情報の優先度に基づいて、配信不可端末が存在するか否かを判定する（ステップＳ２０６）。ここで、配信不可端末が存在しない場合（ステップＳ２０６否定）、通信部１１ｄは、配信制御部１３ｄの制御の下、配信先の全端末に情報（配信予定情報）を配信する（ステップＳ２０７）。例えば、配信可否判定部１３ｅは、未完了情報数が全端末で同数である場合や、配信不可候補端末が存在するものの配信予定情報の優先度が「１」である場合、配信不可端末が存在しないと判定する。
【０１１３】
一方、配信不可端末が存在する場合（ステップＳ２０６肯定）、通信部１１ｄは、配信制御部１３ｄの制御の下、配信不可端末以外の端末に情報（配信予定情報）を配信する（ステップＳ２０８）。例えば、配信可否判定部１３ｅは、配信不可候補端末が存在し、かつ、配信予定情報の優先度が「２」以上である場合、配信不可候補端末を配信不可端末として判定する。
【０１１４】
ステップＳ２０７、又は、ステップＳ２０８の処理の後、配信制御部１３ｄは、情報配信終了要求を受け付けたか否かを判定する（ステップＳ２０９）。ここで、情報配信終了要求を受け付けない場合（ステップＳ２０９否定）、配信制御部１３ｄは、ステップＳ２０４の判定処理を行なう。
【０１１５】
一方、情報配信終了要求を受け付けた場合（ステップＳ２０９肯定）、Ａｐｐサーバ１０は、処理を終了する。
【０１１６】
［実施例２の効果］
上記したように、実施例２に係る情報配信システムは、配信された情報に対して処理を行なって利用者に出力する複数の端末に対して、Ａｐｐサーバ１０から複数の情報を順次配信する際に、制御部１３は、配信先の複数の端末それぞれの情報処理完了状況（未完了情報数）と配信予定情報の属性（優先度）とに基づいて、配信予定情報の配信可否を決定することにより、各端末へ配信される情報量を制御する。具体的には、優先度テーブル１２ｃは、Ａｐｐサーバ１０から配信される情報の属性として優先度を記憶する。そして、未完了情報数取得部１３ａは、情報配信時における前記複数の端末それぞれの未完了情報数を取得し、配信可否判定部１３ｅは、配信が予定される配信予定情報の優先度を優先度テーブル１２ｃから取得する。そして、配信可否判定部１３ｅは、各端末の未完了情報数と配信予定情報の優先度とに基づいて、配信予定情報を配信しない配信不可端末が存在するか否かを判定する。そして、配信制御部１３ｄは、配信可否判定部１３ｅにより配信不可端末が存在すると判定された場合、当該配信不可端末に対して、配信予定情報の配信を中止するように通信部１１を制御する。
【０１１７】
したがって、実施例２では、利用者によって必須ではない情報を積極的に配信しないようにすることで、提供する情報量を配信先の各端末の情報処理能力に応じて変更することができる。その結果、実施例２では、複数の端末にて情報を共有する場合に、配信された情報が各端末にて出力されるタイミングの同期性を向上させることが可能となる。
【０１１８】
［実施例２の変形例］
なお、上述した実施例２では、未完了情報数に基づいて、配信可否の判定を行なう場合について説明した。しかし、本実施例２は、第１の変形例として、未完了情報数及び実施例１で説明した推定時間に基づいて、配信可否の判定を行なう場合であってもよい。すなわち、配信可否判定部１３ｅは、配信先の全端末において、未完了情報数と推定時間とを乗算した値「Ｚ」を算出する。そして、配信可否判定部１３ｅは、算出した「Ｚ」が所定の値以上となった場合にのみ、配信予定情報の優先度を用いて、配信予定情報に対する配信可否の判定を行なう。
【０１１９】
また、上述した実施例２では、情報配信量を制御するために参照される情報として、配信される情報の優先度が段階的に設定されている場合について説明した。しかし、本実施例２は、第２の変形例として、配信される情報の属性として、情報配信に係るポリシーが設定される場合であってもよい。かかるポリシーの一例を挙げると、配信不可端末に対しては、最新の情報を配信するといったポリシーがある。最新の情報を配信するといったポリシーが設定される場面としては、例えば、Ａｐｐサーバ１０からネットオークションにおける入札金額が、共有される情報として配信先の端末へ配信される場合が挙げられる。かかる場合、Ａｐｐサーバ１０は、未完了情報数が最大となっている端末に対して、過去の入札金額を配信せずに、最新の入札金額を配信する。このように、優先度ではなく情報配信に係るポリシーを用いて配信する情報量を制御することでも、情報処理能力の低い端末における情報出力の遅延を縮小することができ、その結果、配信された情報が各端末にて出力されるタイミングの同期性を向上させることが可能となる。
【実施例３】
【０１２０】
実施例３では、実施例１で説明した待機要否及び実施例２で説明した配信可否が両方行なわれる場合について説明する。
【０１２１】
［実施例３に係るＡｐｐサーバの構成］
まず、図１９及び図２０を用いて、実施例３に係る情報配信システムが有するＡｐｐサーバ１０の構成を説明する。図１９は、実施例３に係る情報配信システムが有するＡｐｐサーバの構成を説明するための図であり、図２０は、実施例３に係る配信可否判定部及び待機要否判定部を説明するための図である。
【０１２２】
実施例３に係る情報配信システムが有するＡｐｐサーバ１０は、図３を用いて説明した実施例１に係るＡｐｐサーバ１０及び図１４を用いて説明した実施例２に係るＡｐｐサーバ１０と同様に、通信部１１と、記憶部１２と、制御部１３とを有する。そして、実施例３に係るＡｐｐサーバ１０の記憶部１２は、実施例１及び２で用いられた端末一覧テーブル１２ａと、実施例１で用いられた推定時間テーブル１２ｂと、実施例２で用いられた優先度テーブル１２ｃとを有する。また、実施例３に係るＡｐｐサーバ１０の制御部１３は、実施例１及び２で用いられた未完了情報数取得部１３ａ及び配信制御部１３ｄと、実施例１で用いられた待機要否判定部１３ｂ及び待機時間算出部１３ｃと、実施例２で用いられた配信可否判定部１３ｅとを有する。
【０１２３】
すなわち、実施例３に係る未完了情報数取得部１３ａは、実施例１及び２と同様に、通信部１１による情報配信時に、配信先の全端末の未完了情報数を取得する。そして、実施例３に係る配信可否判定部１３ｅは、未完了情報数と、優先度テーブル１２ｃから取得した配信予定情報の優先度とに基づいて、配信先の端末に配信不可端末が存在するか否かを判定する。なお、実施例３に係るＡｐｐサーバ１０は、判定可否を判定する場合、実施例２の変形例として説明した第１及び第２の変形例を適用する場合であっても良い。
【０１２４】
配信不可端末が存在する場合、実施例３に係る配信制御部１３ｄは、実施例２と同様に、配信不可端末以外の端末に対して配信予定情報を配信するように通信部１１を制御する。
【０１２５】
そして、実施例３に係る待機要否判定部１３ｂは、配信可否判定部１３ｅによる判定処理の後、未完了情報数及び各端末の推定時間に基づいて、待機端末が存在するか否かを判定する。ここで、配信不可端末が存在しない場合、実施例３に係る待機要否判定部１３ｂは、配信先の全端末それぞれの未完了情報数及び推定時間に基づいて、待機端末が存在するか否かを判定する。すなわち、配信不可端末が存在しない場合、実施例３に係る待機要否判定部１３ｂは、実施例１と同様の判定処理を行なう。
【０１２６】
一方、配信不可端末が存在する場合、実施例３に係る待機要否判定部１３ｂは、配信不可端末以外の配信先の全端末それぞれの未完了情報数に基づいて、待機端末が存在するか否かを判定する。
【０１２７】
例えば、図２０に示すように、「端末ＩＤ：１」である端末１の未完了情報数が「０」であり、「端末ＩＤ：２」である端末２の未完了情報数が「１」であり、「端末ＩＤ：３」である端末３の未完了情報数が「６」であることが、未完了情報数取得部１３ａにより取得されたとする。この場合、配信可否判定部１３ｅは、例えば、未完了情報数が最大となる端末３を配信不可候補端末として判定する。そして、配信可否判定部１３ｅは、図２０に示すように、配信予定情報の優先度が「２」以上の「３」であることから、配信不可候補端末である端末３（ＩＤ：３）を配信不可端末として判定する。
【０１２８】
そして、実施例３に係る待機要否判定部１３ｂは、配信不可端末以外の端末（すなわち、端末１及び端末２）に待機端末が存在するか否かを判定する。ここで、待機要否判定部１３ｂは、図２０に示すように、「未完了情報数：０」の端末１と、「未完了情報数：１」の端末２が存在することから、待機処理が必要と判定する。そして、待機要否判定部１３ｂは、図２０に示すように、未完了情報数が「０」の端末である「端末ＩＤ：１」の端末１を待機端末として判定する。すなわち、待機要否判定部１３ｂは、端末２を待機不要端末として判定する。
【０１２９】
そして、実施例３に係る待機時間算出部１３ｃは、配信不可端末が存在せず、かつ、待機端末が存在する場合、配信先の全端末それぞれの推定時間を推定時間テーブル１２ｂから取得して、待機端末に設定される待機時間を算出する。また、実施例３に係る待機時間算出部１３ｃは、配信不可端末が存在し、かつ、待機端末が存在する場合、配信不可端末以外の配信先の全端末それぞれの推定時間を推定時間テーブル１２ｂから取得して、待機端末に設定される待機時間を算出する。
【０１３０】
そして、待機時間が存在する場合、実施例３に係る配信制御部１３ｄは、実施例１と同様に、待機端末への配信予定情報の配信を、待機時間分遅らせるように、通信部１１を制御する。なお、実施例３に係るＡｐｐサーバ１０は、待機要否を判定して待機時間を待機端末に設定する場合、実施例１の変形例として説明した第１〜第４の変形例を適用する場合であっても良い。
【０１３１】
［実施例３に係るＡｐｐサーバによる処理の手順］
続いて、図２１を用いて、実施例３に係る情報配信システムが有するＡｐｐサーバによる処理の手順を説明する。図２１は、実施例３に係る情報配信システムが有するＡｐｐサーバによる処理の手順を説明するためのフローチャートである。
【０１３２】
図２１に示すように、実施例３に係るＡｐｐサーバ１０は、同期対象グループＩＤが指定されたことにより、複数の端末に対する情報配信開始要求を受け付けたか否かを判定する（ステップＳ３０１）。ここで、情報配信開始要求を受け付けない場合（ステップＳ３０１否定）、Ａｐｐサーバ１０は、待機状態となる。
【０１３３】
一方、情報配信開始要求を受け付けた場合（ステップＳ３０１肯定）、通信部１１ｄは、配信制御部１３ｄの制御の下、端末一覧テーブル１２ａを参照して、配信先の端末を確認し（ステップＳ３０２）、配信先の端末に対して、情報の配信を開始する（ステップＳ３０３）。
【０１３４】
そして、配信制御部１３ｄは、配信すべき新規の情報（配信予定情報）があるか否かを判定する（ステップＳ３０４）。ここで、新規の情報がない場合（ステップＳ３０４否定）、Ａｐｐサーバ１０は、待機状態となる。
【０１３５】
一方、新規の情報がある場合（ステップＳ３０４肯定）、未完了情報数取得部１３ａは、配信先の複数の端末それぞれの未完了情報数を取得し、配信可否判定部１３ｅは、優先度テーブル１２ｃを参照して、配信予定情報の優先度を取得する（ステップＳ３０５）。
【０１３６】
そして、配信可否判定部１３ｅは、配信先の複数の端末それぞれの未完了情報数及び配信予定情報の優先度に基づいて、配信不可端末が存在するか否かを判定する（ステップＳ３０６）。ここで、配信不可端末が存在しない場合（ステップＳ３０６否定）、待機要否判定部１３ｂは、配信予定情報の優先度と、配信先の全端末それぞれの未完了情報数とに基づいて、配信先の全端末内に待機端末が存在するか否かを判定する（ステップＳ３０７）。ここで、配信先の全端末内に待機端末が存在しない場合（ステップＳ３０７否定）、通信部１１ｄは、配信制御部１３ｄの制御の下、配信先の全端末に情報を配信する（ステップＳ３０８）。
【０１３７】
一方、配信先の全端末内に待機端末が存在する場合（ステップＳ３０７肯定）、待機時間算出部１３ｃは、待機端末の待機時間を算出する（ステップＳ３０９）。そして、通信部１１ｄは、配信制御部１３ｄの制御の下、待機端末以外の待機不要端末に情報を配信し（ステップＳ３１０）、さらに、待機時間経過後に待機端末に対して情報を配信する（ステップＳ３１１）。なお、ステップＳ３０９の待機時間算出処理と、ステップＳ３１０の待機不要端末に対する情報配信処理とは、並行して実行される場合であっても良い。
【０１３８】
一方、配信不可端末が存在する場合（ステップＳ３０６否定）、待機要否判定部１３ｂは、配信予定情報の優先度と、配信不可端末以外の端末それぞれの未完了情報数とに基づいて、配信不可端末以外の端末に待機端末が存在するか否かを判定する（ステップＳ３１２）。ここで、配信不可端末以外の端末に待機端末が存在しない場合（ステップＳ３１２否定）、通信部１１ｄは、配信制御部１３ｄの制御の下、配信不可端末以外の端末に情報を配信する（ステップＳ３１３）。
【０１３９】
一方、配信不可端末以外の端末に待機端末が存在する場合（ステップＳ３１２肯定）、待機時間算出部１３ｃは、待機端末の待機時間を算出する（ステップＳ３１４）。そして、通信部１１ｄは、配信制御部１３ｄの制御の下、「配信不可端末及び待機端末」以外の端末（待機不要端末）情報を配信し（ステップＳ３１５）、さらに、待機時間経過後に待機端末に対して情報を配信する（ステップＳ３１６）。なお、ステップＳ３１４の待機時間算出処理と、ステップＳ３１５の待機不要端末に対する情報配信処理とは、並行して実行される場合であっても良い。
【０１４０】
ステップＳ３０８、又は、ステップＳ３１１、又は、ステップＳ３１３、又は、ステップＳ３１６の処理の後、配信制御部１３ｄは、情報配信終了要求を受け付けたか否かを判定する（ステップＳ３１７）。ここで、情報配信終了要求を受け付けない場合（ステップＳ３１７否定）、配信制御部１３ｄは、ステップＳ３０４の判定処理を行なう。
【０１４１】
一方、情報配信終了要求を受け付けた場合（ステップＳ３１７肯定）、Ａｐｐサーバ１０は、処理を終了する。
【０１４２】
［実施例３の効果］
上記したように、実施例３に係る情報配信システムは、実施例１で説明した待機要否及び実施例２で説明した配信可否の双方を行なう。ここで、実施例１で説明した待機要否のみを行なう場合、情報出力のタイミングの同期性が向上されるものの、情報処理能力の低い端末に合わせて情報出力のタイミングが遅延されることとなる。すなわち、実施例１では、情報配信のリアルタイム性が損なわれる場合がある。そこで、実施例３では、実施例２で説明した情報量の削減制御を実施例１に適用することで、情報配信のリアルタイム性が損なわれることなく、配信された情報が各端末にて出力されるタイミングの同期性を向上させることが可能となる。
【実施例４】
【０１４３】
さて、これまで本発明の実施例について説明したが、本発明は上述した実施例以外にも、種々の異なる形態にて実施されてよいものである。
【０１４４】
［適用対象］
上記した実施例１〜３では、同期対象グループに登録された複数の端末に対して、複数の情報を順次配信するプッシュ型情報サービスを行なう情報配信システムにおいて、情報の出力タイミングを制御可能なＡｐｐサーバ１０を適用する場合について説明した。しかし、実施例１〜３で説明した情報の出力タイミング制御は、例えば、以下に説明するような「Ｗｅｂコンテンツ共有システム」に適用される場合であってもよい。図２２は、Ｗｅｂコンテンツ共有システムの一例を説明するための図である。
【０１４５】
図２２に示すＷｅｂコンテンツ共有システムの一例においては、ユーザＡの所有するＨＧＷ１００に、端末１及びＳＩＰ（Session  Initiation  Protocol）フォン１０１が接続される。また、図２２に示すＷｅｂコンテンツ共有システムの一例においては、ユーザＢの所有するＨＧＷ２００に、端末２及びＳＩＰフォン２０１が接続される。
【０１４６】
まず、Ｗｅｂコンテンツ共有システムでは、ＳＩＰフォン１０１とＳＩＰフォン２０１との間で、図２２に示すＳＩＰプロキシ２０の処理により、ＳＩＰによるＣａｌｌセッションが確立される。すなわち、ユーザＡとユーザＢとの間で通話が行われる。
【０１４７】
ここで、ＨＧＷ１００を介して、端末１とＡｐｐサーバ１０との間には、Ｗｅｂセッションが確立されており、また、ＨＧＷ２００を介して、端末２とＡｐｐサーバ１０との間には、Ｗｅｂセッションが確立されている。そこで、例えば、Ａｐｐサーバ１０は、図２２に示すように、ＳＩＰフォン１０１とＳＩＰフォン２０１との間で確立されたＣａｌｌセッション情報を取得することで、ユーザＡとユーザＢとの間で通話が行なわれていることを認識し、端末１とＡｐｐサーバ１０との間で確立されているＷｅｂセッション情報と、端末２とＡｐｐサーバ１０との間で確立されているＷｅｂセッション情報とを連携する。これにより、図２２に例示するＷｅｂコンテンツ共有システムは、端末１と端末２との間で、Ｗｅｂコンテンツの共有が実現される。
【０１４８】
すなわち、Ａｐｐサーバ１０は、例えば、発信者であるユーザＡの端末１にＡｐｐサーバ１０から配信されている情報を、着信者であるユーザＢの端末２に対しても配信することで、端末１と端末２との間でＷｅｂコンテンツの共有が開始される。そして、ユーザＡが端末１を介してＡｐｐサーバ１０に配信要求したＷｅｂコンテンツの情報や、ユーザＢが端末２を介してＡｐｐサーバ１０に配信要求したＷｅｂコンテンツの情報が、端末１及び端末２にて出力される。
【０１４９】
しかし、上記したＷｅｂコンテンツ共有システムにおいても、端末１及び端末２それぞれの情報処理能力が異なる場合、同じ情報が出力されるタイミングが異なってしまう。そこで、図２２に示すＡｐｐサーバ１０に、実施例１〜３で説明した情報配信方法を実行させることにより、端末１及び端末２に対して配信された情報が、端末１及び端末２にて出力されるタイミングの同期性を向上させることが可能となる。
【０１５０】
［制御処理を行なう装置］
また、上記した実施例１〜３では、情報配信を行なうＡｐｐサーバ１０が、情報の出力タイミングを制御する場合について説明したが、情報の出力タイミングを制御する装置は、Ａｐｐサーバ１０と独立に設置される場合であってもよい。
【０１５１】
［システム構成等］
また、本実施例において説明した各処理のうち、自動的におこなわれるものとして説明した処理の全部または一部を手動的におこなうこともでき、あるいは、手動的におこなわれるものとして説明した処理の全部または一部を公知の方法で自動的におこなうこともできる。この他、上記文書中や図面中で示した処理手順、制御手順、具体的名称、各種のデータやパラメータを含む情報については、特記する場合を除いて任意に変更することができる。
【０１５２】
また、図示した各装置の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散・統合の具体的形態は図示のものに限られず、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。さらに、各装置にて行なわれる各処理機能は、その全部または任意の一部が、ＣＰＵ及び当該ＣＰＵにて解析実行されるプログラムにて実現され、あるいは、ワイヤードロジックによるハードウェアとして実現され得る。
【０１５３】
なお、本実施例で説明した情報配信方法は、あらかじめ用意された情報配信プログラムをパーソナルコンピュータやワークステーションなどのコンピュータで実行することによって実現することができる。この情報配信プログラムは、インターネットなどのネットワークを介して配布することができる。また、この情報配信プログラムは、ハードディスク、フレキシブルディスク（ＦＤ）、ＣＤ−ＲＯＭ、ＭＯ、ＤＶＤなどのコンピュータで読み取り可能な記録媒体に記録され、コンピュータによって記録媒体から読み出されることによって実行することもできる。
【産業上の利用可能性】
【０１５４】
以上のように、本発明に係る情報配信システム、情報配信方法及び情報配信プログラムは、複数の端末間でＷｅｂサービスを共有する場合に有用であり、特に、配信された情報が各端末にて出力されるタイミングの同期性を向上させることに適する。
【符号の説明】
【０１５５】
１，２，３  端末
１０  Ａｐｐサーバ
１１  通信部
１２  記憶部
１２ａ  端末一覧テーブル
１２ｂ  推定時間テーブル
１３  制御部
１３ａ  未完了情報数取得部
１３ｂ  待機要否判定部
１３ｃ  待機時間算出部
１３ｄ  配信制御部
【図１】
2012083805.tif 000003
【図２】
2012083805.tif 000004
【図３】
2012083805.tif 000005
【図４】
2012083805.tif 000006
【図５】
2012083805.tif 000007
【図６】
2012083805.tif 000008
【図７】
2012083805.tif 000009
【図８】
2012083805.tif 000010
【図９】
2012083805.tif 000011
【図１０】
2012083805.tif 000012
【図１１】
2012083805.tif 000013
【図１２】
2012083805.tif 000014
【図１３】
2012083805.tif 000015
【図１４】
2012083805.tif 000016
【図１５】
2012083805.tif 000017
【図１６】
2012083805.tif 000018
【図１７】
2012083805.tif 000019
【図１８】
2012083805.tif 000020
【図１９】
2012083805.tif 000021
【図２０】
2012083805.tif 000022
【図２１】
2012083805.tif 000023
【図２２】
2012083805.tif 000024