JP4531280B2 - プッシュ型情報配信方法、プッシュ型情報配信用プログラム、及びプッシュ型情報配信装置、記憶媒体 - Google Patents

Description

【０００１】
【発明の属する技術分野】
本発明は、例えば秒単位や分単位で更新されたデータを、サーバからインターネット等のネットワークを通して端末にリアルプッシュ方式で配信するプッシュ型情報配信方法、プッシュ型情報配信用プログラム、記録媒体及びプッシュ型情報配信装置に関するものである。
【０００２】
【従来の技術】
近年、刻々と変化する為替レートやニュースなどの各種情報をインターネットを通じて端末に提供するサービスが行われている。この種の配信方法として、従来、ユーザが見ている画面上のデータがリアルタイムに自動的に更新されるプッシュ型配信方法が知られている。
【０００３】
このプッシュ型配信方法には、一定時間間隔でサーバに対し端末側からデータを取得しに行き接続は１回毎に行うスマートプル方式と、サーバと端末は接続を維持してデータに変化があった更新時のみサーバ側から端末にデータを送信するリアルプッシュ方式とが知られている。しかし、為替レートやニュースなどのリアルタイム性が要求される情報の提供には、ユーザが見ているデータがリアルタイムで自動的に更新されるリアルプッシュ方式の方がより現実的である。
【０００４】
ところで、インターネットで情報提供サービスを受けるユーザ数が例えば数千〜数万人にも及ぶ場合でも、これらのユーザの端末にプッシュ型配信方法で情報を安定的に提供する必要がある。
【０００５】
【発明が解決しようとする課題】
しかし、リアルプッシュ方式を採用した場合、非常に多数のユーザに情報を安定的に提供しようとすると、非常に多数台のサーバを設置しなければならないという問題があった。これはプッシュ型配信方法では、更新データを複数のユーザに時間差なく配信するためにマルチタスク処理が採用されていることに原因がある。マルチタスク処理は、ユーザ一人に１つずつ用意した複数の配信プログラムを極く短時間に切換えながら同時並列的に処理する方式であるため、ある程度の数までのユーザに対してはさほど遅延なくほぼ同時期に配信処理ができるが、ユーザ数が非常に多い場合は非常に多数のプログラム間を切換える切換処理に却って時間を要し、遅延の原因となっていた。また、同時に接続するユーザ数分のＣＰＵなどのサーバ資源が、接続ユーザ数に対しリニアに消費される。また、特にインターネット回線の場合、ユーザ一人ひとりの通信環境（回線環境や端末環境等）が大きく異なり、最も通信環境の悪いユーザにシステム全体のパフォーマンスを左右され易いという問題があった。
【０００６】
このため、サーバ１台当たりが受け持つ端末数をある程度の数に制限せざるを得ず、例えば数千〜数万人のユーザを相手とする情報配信システムを構築する場合、サーバ設置台数が非常に多くなるという問題があった。このような事情から、同時接続可能な端末数を多くしインターネットという個々のユーザ毎に異なる回線状況にあってなおデータのリアルタイム性を確保できる配信方法が要求されていた。
【０００７】
本発明は、前記課題を解決するためになされたものであって、その第１の目的は、秒単位や分単位で更新されるデータでもユーザの端末にさほど表示の遅延を伴わずインターネット等のネットワークを介して配信でき、しかもサーバとして用いられるコンピュータの負荷を軽減することによって、１台のサーバが受け持つ端末数を増やすことを可能とするプッシュ型情報配信方法、プッシュ型情報配信用プログラム、記録媒体及びプッシュ型情報配信装置を提供することにある。また、第２の目的は、ユーザ毎の通信環境に応じて配信方式を切り替えることによって、通信環境の悪い一部のユーザによってサーバ全体のパフォーマンスが左右されることを起き難くすることにある。
【０００８】
【課題を解決するための手段】
上記第１の目的を達成するために請求項１に記載の発明は、端末から受け付けた情報についてそのデータが更新されると、その更新されたデータを前記端末に対しコンピュータネットワークを通じてプッシュ方式で配信するプッシュ型情報配信方法であって、コンピュータのＯＳ層に格納された非同期型通信プロトコルによって複数の端末に対する送受信処理を司る送受信手段を構築するとともに、プッシュ方式の配信処理を該送受信手段に非同期で実行させるように指示するようにし、端末から受け付けた情報についてそのデータが更新されたことをコンピュータの更新検出手段が検出する段階と、コンピュータの配信手段が、前記更新が検出された前記情報の配信待ち状態にある複数の端末のうち送信可能状態にある端末に該更新データを配信するための配信処理を前記送受信手段にシリアライズ処理で指示するとともに、その際に前記送受信手段が送信中の端末に対しては送信せず該更新データを一時保管し、当該送信中の端末が送信可能状態になったことを知ると、それまでに保管されて溜まったデータをまとめて該端末に送信する送信処理を前記送受信手段に指示する段階とを備えたことを要旨とする。
【０００９】
この発明によれば、配信手段は送受信手段に配信処理又は送信処理を指示すれば、その指示した処理は配信手段と非同期で動作する送受信手段が実行するため、例えば端末から受信の応答を待つことなく、配信手段は処理を指示した後に直ぐ次の処理に移ることができる。またデータ更新検出時にシリアライズ処理（ループ処理）で配信処理を指示するため、同時並列処理（マルチタスク法）のような多数プログラム間の切換処理を伴わず、配信先の端末数がかなり多数であっても遅延し難く、しかも全ての配信先でデータを共有できるためメモリ資源を消費し難い。また送信中の端末には送信可能状態になったときにそれまで保管して溜まったデータをまとめて送信するため、端末に早くデータを送信できるうえ、コンピュータの負荷も軽減される。
【００１０】
前記第２の目的を達成するために請求項２に記載の発明は、請求項１に記載のプッシュ型情報配信方法において、端末毎に適用される配信方式として、更新起動型配信方式とタイマ起動型配信方式との二方式を備え、前記情報のデータ更新検出時に起動されてその情報を待つ端末に対し該更新データを配信する更新起動型配信方式の処理をコンピュータの配信手段が行う段階と、端末毎の通信速度を直接又は間接的にコンピュータが判定する段階と、更新起動型配信方式が適用された端末のうち通信速度が基準より遅いと判断された端末についてはその適用される配信方式を、更新起動型配信方式からタイマ起動型配信方式にコンピュータの切替手段が切り替える段階と、コンピュータのタイマ手段により設定時間毎に起動されてその起動時の最新の更新データを前記タイマ起動型配信方式が適用された端末に配信するタイマ起動型配信方式の処理を前記配信手段が行う段階とを備えたことを要旨とする。
【００１１】
この発明によれば、更新起動型配信方式が適用された端末は、更新の度にデータが配信されるが、例えば通信環境が悪く通信速度の遅い端末については、適用される配信方式が、更新起動型配信方式からタイマ起動型配信方式に切り替えられる。このように端末毎の通信環境に応じて配信方法を切り替えることによって、通信環境の悪い一部の端末（ユーザ）によってサーバ全体のパフォーマンスが左右される不都合が起き難くなる。なお、タイマ起動型配信方式の設定時間は、その起動頻度が更新起動型配信方式の起動頻度（更新頻度）よりも少なくなるように設定されるのが望ましい。
【００１２】
請求項３に記載の発明は、端末から受け付けた情報についてそのデータが更新されると、その更新されたデータを前記端末に対しコンピュータネットワークを通じてプッシュ方式で配信するサーバ機能をコンピュータに実現させるプッシュ型情報配信用プログラムであって、特に、コンピュータのＯＳ層に格納された非同期型通信プロトコルによって構築された送受信手段に対しプッシュ方式の配信処理を指示するまでの処理を行うアプリケーションが有するプログラムであり、コンピュータを、端末から受け付けた情報についてそのデータが更新されたことを検出する更新検出手段と、前記更新検出手段が前記情報についてそのデータが更新されたことを検出すると、その更新データを該情報の配信待ち状態にある複数の端末のうち送信可能状態にある端末に配信するための配信処理を前記送受信手段にシリアライズ処理で指示するとともに、その際に前記送受信手段が送信中の端末に対しては送信せず該更新データを一時保管し、当該送信中の端末が送信可能状態になったことを知ると、それまでに保管されて溜まったデータをまとめて該端末に送信するための送信処理を前記送受信手段に指示する配信方式をとる配信手段として機能させることを要旨とする。
【００１３】
この発明によれば、請求項１に記載の発明と同様の作用効果が得られる。
請求項４に記載の発明は、請求項３に記載のプッシュ型情報配信用プログラムにおいて、前記配信手段は、前記配信方式である第１配信方式と、該第１配信方式とはデータ更新検出時に前記送信可能状態の端末に対する配信処理をシリアライズ処理で指示し、前記送信中の端末に対して前記更新データを一時保管するまでは同じ処理で、送信中の端末が送信可能状態となったことを知ると、それまでに保管されて溜まったデ−タのうち更新時期の異なる同一情報のデータについては最新データのみを採用する間引き処理をして該間引き処理後のデータをまとめて該端末に送信する送信処理を前記送受信手段に指示する第２配信方式とを採用し、コンピュータを、前記配信手段と、端末毎の通信速度を直接又は間接的に判定する判定手段と、前記判定手段により通信速度が基準よりも遅いと判定された端末に対しては、前記第１配信方式から第２配信方式に切り替える切替手段として機能させることを要旨とする。
【００１４】
第１配信方式が適用された端末の通信速度が基準よりも遅いと判定されると、その端末には第２配信方式が適用される。よって、送信可能状態となった端末にそれまで保管されて溜まったデータをまとめて送信する際に、間引き処理が行われ、更新時期の異なる同一情報のデータについては最新データのみが採用されて古いデータが間引かれるため、送信されるデータ量が少なく済み通信負荷の低減により通信速度を速められるうえ、コンピュータの負荷も軽減される。
【００１５】
請求項５に記載の発明は、請求項３又は４に記載のプッシュ型情報配信用プログラムにおいて、前記配信手段は、プッシュ方式配信の対象とされる端末に適用される配信方式として、データ更新検出時に起動される前記配信方式である更新起動型配信方式の処理と、コンピュータのタイマ手段によって設定時間毎に起動されるタイマ起動型配信方式の処理とを採用しており、コンピュータを、端末毎に通信速度を直接又は間接的に判定する判定手段と、前記判定手段により通信速度が基準よりも遅いと判定された端末に対してはその適用される方式を、前記更新起動型配信方式からタイマ起動型配信方式に切り替える切替手段と、前記タイマ起動型配信方式に切り替えられた端末に対しては、前記タイマ手段による設定時間毎の起動時における最新の更新データを該情報の配信待ち状態にある複数の端末のうち送信可能状態にある端末に配信する配信処理を前記送受信手段にシリアライズ処理で指示するとともに、その際に前記送受信手段が送信中の端末に対しては送信せず該更新データを一時保管し、当該送信中の端末が送信可能状態になったことを知ると、それまでに保管されて溜まったデータをまとめて該端末に送信する送信処理を前記送受信手段に指示する前記配信手段として機能させることを要旨とする。
【００１６】
この発明によれば、更新起動型配信方式が適用される端末の通信速度が基準よりも遅いと判定されると、この端末に適用される配信方式が更新起動型配信方式からタイマ起動型配信方式に切り替えられる。このように端末毎の通信速度に応じて通信速度の遅い端末については、配信方法が更新起動型配信方式からタイマ起動型配信方式に切り替えられるため、通信環境の悪い一部の端末（ユーザ）によってサーバ全体のパフォーマンスが左右される不都合が起き難くなる。特に請求項４の発明において適用された場合、通信速度の遅い端末については、まず更新起動型配信方式の第１配信方式から第２配信方式に切り替わり、それでも通信速度が遅ければさらに第２配信方式からタイマ起動型配信方式に切り替わる。よって、適用される配信方式が端末毎に３段階のうちから自動切替えされることによって、通信環境の悪い一部の端末（ユーザ）によってサーバ全体のパフォーマンスが左右される不都合を一層防ぎ易くなる。
【００１７】
請求項６に記載の発明は、請求項５に記載のプッシュ型情報配信用プログラムにおいて、前記配信手段には、前記タイマ起動型配信方式としてその起動される設定時間が異なる複数段階用意されており、端末毎に通信速度を直接又は間接的に判定する判定手段と、タイマ起動型配信方式が適用された端末のうち、前記判定手段により通信速度が基準よりも遅いと判定された端末に対しては、前記タイマ手段によって起動される設定時間のより長い段階へと切り替える切替手段とをサーバコンピュータに機能させることを要旨とする。
【００１８】
この発明によれば、タイマ起動型配信方式に切り替えられた後においても、さらに端末の通信速度が基準よりも遅いと判定されると、設定時間がより長い段階へと切り替えられる。よって、通信環境の悪い一部の端末（ユーザ）によってサーバ全体のパフォーマンスが左右される不都合が一層起き難くなる。
【００１９】
請求項７に記載の発明は、端末から受け付けた情報についてそのデータが更新されると、その更新されたデータを前記端末に対しコンピュータネットワークを通じてプッシュ方式で配信するサーバ機能をコンピュータに実現させるプッシュ型情報配信用プログラムであって、特に、コンピュータのＯＳ層に格納された非同期型通信プロトコルによって構築された送受信手段に対しプッシュ方式の配信処理を指示するまでの処理を行うアプリケーションが有するプログラムであり、コンピュータを、複数段階設定された設定時間毎にコンピュータのタイマ手段によって起動され、その起動時における前記情報についての最新の更新データを該情報の配信待ち状態にある複数の端末のうち送信可能状態にある端末に配信する配信処理を前記送受信手段にシリアライズ処理で指示するとともに、その際に前記送受信手段が送信中の端末に対しては送信せず該更新データを一時保管し、当該送信中の端末が送信可能状態になったことを知ると、それまでに保管されて溜まったデータをまとめて該端末に送信する送信処理を前記送受信手段に指示する配信手段と、端末毎に通信速度を直接又は間接的に判定する判定手段と、前記判定手段により通信速度が基準よりも遅いと判定された端末に対しては、前記タイマ手段によって起動される設定時間がより長い段階の配信方式に切り替える切替手段として機能させることを要旨とする。
【００２０】
この発明によれば、配信手段は送受信手段に配信処理又は送信処理を指示すれば、その指示した処理は配信手段と非同期で動作する送受信手段が実行するため、例えば端末から受信の応答を待つことなく、配信手段は処理を指示した後に直ぐ次の処理に移ることができる。また設定時間毎に起動されてシリアライズ処理（ループ処理）で配信処理を指示するため、同時並列処理（マルチタスク法）のような多数プログラム間の切換処理を伴わず、配信先の端末数がかなり多数であっても遅延し難い。また送信中の端末には送信可能状態になったときにそれまで保管して溜まったデータをまとめて送信するため、端末に早くデータを送信できるうえ、コンピュータの負荷も軽減される。端末の通信速度が基準よりも遅いと判定されると、設定時間がより長い段階の配信方式に切り替えられる。よって、通信環境の悪い一部の端末（ユーザ）によってサーバ全体のパフォーマンスが左右される不都合が起き難くなる。
【００２１】
請求項８に記載の発明は、コンピュータ読み取り可能な記録媒体には、請求項３〜７のいずれか一項に記載のプッシュ型情報配信用プログラムが記録されていることを要旨とする。
【００２２】
この発明によれば、記録媒体に記録されたプログラムより請求項３〜７のいずれか一項に記載の発明と同様の作用効果が得られる。
請求項９に記載の発明は、端末から受け付けた情報についてそのデータが更新されると、その更新されたデータを前記端末に対しコンピュータネットワークを通じてプッシュ方式で配信するプッシュ型情報配信装置であって、請求項３〜７のいずれか一項に記載された、コンピュータが備える前記送受信手段と、コンピュータが備える前記配信手段とを少なくとも含む、コンピュータが備える前記各手段を備えたことを要旨とする。
【００２３】
このプッシュ型情報配信装置によれば、請求項３〜７のいずれか一項に記載された発明と同様の作用効果が得られる。
【００２４】
【発明の実施の形態】
以下、本発明を具体化した一実施形態を、図１〜図８に基づいて説明する。
図１は、プッシュ型情報配信システムの構成ブロックを示す。
【００２５】
プッシュ型情報配信システム１は、例えば秒単位または分単位で更新される情報をデータで提供する情報発信源サーバ２と、この情報発信源サーバ２から受信した更新データを配信するコンピュータとしての配信用サーバ（サーバコンピュータ）３と、配信用サーバ３に接続（ログイン）をする多数の端末（クライアント）４とから構成される。配信用サーバ３は、リアルプッシュ方式を採用するものである。
【００２６】
配信用サーバ３は例えば専用回線を通じて情報発信源サーバ２と接続され、端末４はコンピュータネットワークとしてのインターネット５を通じて配信用サーバ３に接続する。この接続には例えばダイヤルアップ接続や専用回線接続などで行われ、この接続方式や端末性能（例えばモデム性能等）などの違いによってユーザ毎に通信環境は大きく異なる。
【００２７】
配信用サーバ３は例えばパーソナルコンピュータからなり、本例では複数（例えば２つ）のＣＰＵを有する。配信用サーバ３の例えばハードディスクには、ＯＳ（Operating Sistem）およびインターネット通信用プロトコルであるTCP/IPを含むＯＳ用ソフトウェアと、リアルプッシュ方式の配信処理をするなどのためのアプリケーションプログラムが格納されている。この実施形態では、TCP/IPライブラリは「非同期」の設定がなされており、TCP/IPはアプリケーションプログラムと非同期で動作する非同期型通信プロトコルとしての非同期型TCP/IPとして機能する。
【００２８】
ＯＳ管理下にある送受信部６は、非同期型TCP/IPから構成されている。送受信部６は、送受信ポートとして機能する複数の端末４用の接続ハンドル（接続ＩＤ）７と、情報発信源サーバ２用の接続ハンドル８とを備える。
【００２９】
また配信用サーバ３は、通信制御部９、データテーブル１０、ユーザテーブル１１およびタイマ１２を備えている。通信制御部９は、更新検出手段としての更新受付部１３、ユーザ受付部１４および配信手段としての配信処理部１５を備え、さらに配信処理部１５はプル処理部１６およびプッシュ処理部１７を備えている。各部９〜１６はアプリケーションプログラムとＣＰＵとメモリ等から構成されており、ＣＰＵがアプリケーションプログラムを実行することで実現される配信処理のための各種機能部として構成される。
【００３０】
通信制御部９は、送受信部６からの各種TCP/IPイベントにより起動される。また、送受信部６は通信制御部９と非同期で動作し、更新データの受付処理、端末（ユーザ）４の受付処理、ユーザへの配信処理などを司る。更新受付部１３は更新イベントにより起動され、接続ハンドル８を通じて受信した更新データをデータテーブル１０に格納する。またユーザ受付部１４は要求イベントにより起動され、端末４のログイン処理をして接続ハンドル７を割り当てるとともにユーザに関するデータ（接続ハンドルＩＤ等）をユーザテーブル１１に格納する。
【００３１】
プル処理部１６は、端末４からユーザが見たい情報についての最初のアクセスを受け付けた時にプル方式でデータ送信処理をし、プッシュ処理部１７はその後のログイン中にリアルプッシュ方式（以下、単にプッシュ方式と称す）で更新データの配信処理をする。ユーザが一度アクセスして端末４の画面上に表示されたデータ（表示内容）は、配信用サーバ３がプッシュ方式の配信処理をすることによって、再度のアクセスをしなくても自動的に更新される。
【００３２】
通信制御部９は、非同期型TCP/IPのプロトコルからなるＯＳ管理下の送受信部６に対し更新データの配信の依頼（指示）をする配信依頼処理をし、送受信部６は、プル処理部１６またはプッシュ処理部１７から受け付けた配信処理を非同期で実行する。送受信部６では、配信処理の際、端末４への更新データ配信後、配信した全ての端末４から受信応答（ＡＣＫ）を受信するまでデータを保持して待機し、送信ミスがあれば再送処理をし、全ての端末４からＡＣＫを受信してからデータを破棄する。このようにＡＣＫ受信確認するまで次の処理に移行できないが、プッシュ処理部１７と送受信部６とは非同期であることから、プッシュ処理部１７は送受信部６にデータの配信（送信）を依頼さえすれば配信処理が完了するまで待つことなく次の処理に移ることができる。
【００３３】
配信用サーバ３は、リアルタイム配信の定義を最新データに対して遅延を最大限少なく配信することと定義してユーザ〜サーバ間の接続環境やデータ特性に見合ったデータ配信方式を選択する。非同期型TCP/IPとスレッドプールとの組み合わせによる同時配信処理数の高効率化を図ることを特徴とする。
【００３４】
本実施形態では、高効率な配信を実現するためのベースとして、全てのTCP/IP通信処理動作は、非同期型TCP/IPライブラリとスレッドプールの概念とを使用する。非同期型では接続ハンドルと処理との分離に加え、通信処理の完了を待たずに次の動作へ移ることが可能である。プッシュ処理部１７では、同一キー（同一情報）の更新データの配信を待つ全ユーザに対する配信処理に一つの処理スレッドを作成し、一つの処理スレッドをループ処理で実行することにより、更新データをユーザ一人ずつ順番にシリアライズ送信する。
【００３５】
送受信部６は、各端末４へ更新データ配信後、端末４から受信確認応答（ＡＣＫ）を受信して接続ハンドル７が空くまで次のデータを送信できない。そのため、送信中のユーザについては送信完了イベントが発生するまで、そのユーザの配信のための処理スレッドを一時メモリに格納（プール）する。そして、ユーザ毎にデータを送信待ちキューに一時格納し、送信完了イベントの発生によって接続ハンドル７の空きが確認されると、そのユーザの送信待ちキューに格納されたデータの送信を送受信部６に依頼する。
【００３６】
ここで、メモリに格納しておけるスレッド数（ユーザ数）＝同時起動数に上限が設定されている。これは、同時に動作するスレッド数を制限しないと送信完了イベントが仮に同時に全ユーザ分発生した場合に、その分のスレッドを起動してしまうと、ＣＰＵ効率が著しく落ちてしまい、送信の場合にシリアライズ化した意味がなくなってしまうからである。プールするスレッド数を制限することで結果として送信完了イベントや配信要求に基づく処理も、ある程度のシリアライズ（経時時間に従って順番に処理）がなされる効果がある。つまり本実施形態では、同時にイベント（接続要求や受信、送信完了）が発生した場合においても、意識的に同時稼動処理数を制限してシリアライズ化させることでＣＰＵ数に見合った最も効率的な同時処理と使用メモリ低減が可能となる。
【００３７】
また本実施形態では、ユーザ毎の通信環境（回線種等）やデータ特性の違いを考慮し、その通信速度に応じて配信方法をユーザ毎に柔軟に切り替える方式を採用している。配信方法として３つの方式を採用する。すなわち、通信速度の高速なユーザにはベストエフォート（BEST EFFORT ）方式（第１配信方式と称す）、通信速度のやや遅いユーザにはデファード（DEFERRED）方式（第２配信方式と称す）、通信速度の遅いユーザにはタイマ（TIMER ）配信方式を採用する。判定手段としての判定部１７Ａがユーザ毎に通信速度を判定し、通信速度が遅いと判定されたユーザには、第１配信方式（単に第１方式という）→第２配信方式（単に第２方式という）→タイマ配信方式（単にタイマ方式という）の順で段階的に配信方式が自動的に切り替えられる設定となっている。この配信方式の切替えは、切替手段としてのプッシュ処理部１７が行う。
【００３８】
第１方式と第２方式は、更新イベントにより起動される更新起動型の配信方式であり、タイマ方式はタイマ１２により設定時間（一定時間間隔）ｔ1 ，ｔ2 ，…，ｔn （但し、ｔ1 ＜ｔ2 ＜…＜ｔn ）毎に起動されるタイマ起動型の配信方式である。ここで、一定時間間隔ｔ1は、更新起動型の第１方式および第２方式よりも、起動間隔時間が相対的に長くなるように設定されている。なお、本実施形態では、タイマ方式に設定される設定時間を複数段階（ｎ段階）としているが、設定時間は１段階とすることもできる。
【００３９】
次に、通信制御部９が管理するデータテーブル１０およびユーザテーブル１１について説明する。
図３に示すように、データテーブル１０は、更新データの管理、更新データの配信処理をする際に配信必要性の有無や配信先の特定などをするための参照用に使用されるもので、キー項目、データ項目、更新フラグ、配信待ちキュー、およびTIMER 配信待ちキューなどのデータ列からなる。キー項目には、情報の識別番号であるキーが格納される。データ項目には更新データが格納される。例えば更新イベントにより更新通知がなされた更新データは同一キーのデータに上書きされ、データ項目には常に最新の更新データが格納される。更新フラグには、タイマ配信処理用のデータ更新を示すフラグが格納される。配信待ちキューには、第１方式と第２方式での配信待ちユーザエントリ用待ち行列が格納される。タイマ方式の配信待ちキューには、タイマ方式での配信待ちユーザエントリ用待ち行列が格納される。
【００４０】
図４に示すように、ユーザテーブル１１には、接続ハンドル、送信中フラグ、間引き送信フラグ、配信待ちエントリ用バッファ配列、送信待ちキュー、送信待ちキュー格納数およびキープアライブ（KeepAlive ）受信時刻などのデータ列からなる。「接続ハンドル」とは、接続中の端末４毎に設定されるコネクションＩＤの識別番号である。「送信中フラグ」とは、非同期TCP/IP送信の完了待ちフラグである。「間引き送信フラグ」とは、第２方式またはタイマ方式が適用されているときにオンになるフラグである。「配信待ちエントリ用バッファ配列」とは、データテーブル１０にエントリするためのバッファ配列を示す。バッファ配列は、「データキー」，「後方ポインタ」，「前方ポインタ」，「ユーザID」，「TCPハンドル」，「配信方式」等からなる。「送信待ちキュー」には、送信待ちデータエントリ用待ち行列が格納される。「送信待ちキュー格納数」は、送信待ちキューに格納されたエントリデータ数を示す。「キープアライブ受信時刻」とは、キープアライブ電文受信時刻を格納するためのものである。
【００４１】
次にユーザ毎に配信方法が切り替えられる３つの方式の内容について説明する。
（１）第１方式（BEST EFFORT 方式）は、更新イベントが発生した際にデータ毎の配信待ちキューにエントリしている（配信の要求を行っている）各ユーザのうち送信中でないユーザについてはシリアライズ送信依頼を行うとともに、前回の送信が完了していない場合にユーザ単位ごとの送信待ちキューに一旦データを格納し、送信完了時に送信待ちキューの複数データを１つにまとめて送信する。これによりユーザの端末４までの回線速度に合わせた遅延および送信パケット数を抑えた回線効率の良い配信を実現する。１ユーザあたりの送信待ちキュー格納数が上限値(設定数）を超えた場合は、自動的に第２方式に移行する設定としている。
【００４２】
（２）第２方式（DEFERRED方式）は、更新イベントが発生した際に配信待ちキューへの格納までは第１方式と同様であるが、配信時に配信待ちキュー内に同一キーデータが複数存在した場合は、未送信の古いデータを破棄し最新のデータのみを編集して１データとして送信する。結果的に間引きされて第１方式に比較して１回の送信パケットサイズを減らして送信が行われる。１ユーザあたりの送信待ちキュー格納数が上限値（設定数）を超えた場合は、自動的にタイマ方式に移行する設定としている。
【００４３】
（３）タイマ方式（TIMER 方式）は、タイマ１２の設定時間毎に処理を起動し、その起動時にデータテーブル１０が更新されていた場合のみ、その最新の更新データのみを送信する。タイマ方式の配信待ちキューにあるユーザには設定時間ｔk内に複数回の更新があっても直近の最新データ以外の更新データが結果的に間引かれて配信される。タイマ方式に移行したときは最初に設定時間ｔ1が設定され、１ユーザあたりの送信待ちキュー格納数が上限値を超えた場合は、設定時間ｔkから次段階の設定時間ｔk+1に切り替えられ、最終的に最後の段階の設定時間ｔnでも送信待ちキュー格納数が上限値（設定数）を超えたときは極度にリアル性が低下するとしてその端末４の接続を切断する。なお、上限値は各方式毎に異なる値を設定してもよい。
【００４４】
このようにユーザ毎の送信待ちキュー格納数から判定される通信速度に応じてユーザ毎に配信方式を切り替える。よって、サーバ３までのインターネット接続環境で常に高速な回線を使用するユーザには第１方式が適用され、低速な回線を使用するユーザによる大規模同時接続に対しては実用上問題の無い範囲内でデータ量を間引く第２方式またはタイマ方式が適用される。自動的に配信方式の切替えが行われた場合は、配信方式変更のコマンド電文をユーザの端末４に送信し、ユーザに対して回線状況の悪化を知らせて別の接続ルートを促す。
【００４５】
データ特性上、第２方式およびタイマ方式による間引き送信が許されるデータの例としては、刻々更新される値段や数値の情報に関するデータが挙げられる。これはユーザにとって最新データさえ見られれば十分で、秒単位で数回更新された全てのデータを漏れなく配信するために遅延して表示されるよりも、多少間引かれても最新データが早く表示されることの方がより重要だからである。逆にデータ特性上、間引き送信があってはならない例としてニュースなどがある。情報がニュースである場合は、第１方式のみが採用される。
【００４６】
図２は、配信処理用アプリケーションプログラムを構成する各処理を示すブロック図である。情報発信源サーバ２は、更新アプリケーション２Ａおよび更新モジュール２Ｂを備え、サーバ２のAPI コールを呼び出すことにより配信用サーバ３にTCP/IP接続し、最新データを配信用サーバ３に送信する。また端末４は、アプリケーション（ブラウザ等）４Ａおよびクライアントモジュール４Ｂを備えており、端末４のAPI コールを呼び出すことによりインターネット５を通じて配信用サーバ３にTCP/IP接続する。
【００４７】
サーバ３は、例えばネットワークカード等からなるハードウェア層１８、ＯＳおよび非同期型TCP/IPからなるＯＳ層１９およびアプリケーション層２０を有している。非同期型TCP/IPにより構成される送受信部６はＯＳ層１９に属する。
【００４８】
アプリケーション層２０には、配信処理用アプリケーションを構成するプログラム群およびデータ群がある。図１のアプリケーション部分の各構成部１０〜１７は、ＣＰＵが図２の各処理（小プログラム群）を実行することで実現される。その対応関係を述べると、図２に示すように、更新受付部１３は、更新側TCP/IPイベント管理（更新側イベント管理と称す）２１と更新受付処理２２とを有する。また、ユーザ受付部１４は、配信側TCP/IPイベント管理（ユーザイベント管理と称す）２３、ユーザ受付処理２４、キープアライブタイマ処理２５およびクリーナップ処理２６を有する。さらに配信処理部１５は配信処理２７を有し、タイマ１２はタイマ処理２８を有する。
【００４９】
更新側イベント管理部２１は、サーバ２の接続、切断やデータ受信などの各TCP/IPイベントを受け付け、データスレッド（プログラム）を起動する。更新側イベント管理部２１は、スレッドプールで構成されており、ＣＰＵ数に応じて同時起動する処理スレッド数を規定し、規定数を超えた場合はシーケンシャルに起動処理を行うことで、処理スレッド数過多によるＯＳのオーバーヘッドを防ぐ。
【００５０】
更新受付処理２２は、更新側イベント管理部２１から受け付けた各TCP/IPイベントによって起動されるデータスレッドからなる。データスレッドは、各TCP/IPイベントの種類に応じて起動される３つの処理群を有する。すなわち(1) ログイン受付処理、(2) ログアウト受付処理、(3) 受信処理である。(1) ログイン受付処理は、TCP/IP接続を受け付ける処理である。(2) ログアウト受付処理は、TCP/IP切断を受け付ける処理である。(3) 受信処理は、配信処理２７を呼び出して更新データを配信処理２７に引き渡す処理である。
【００５１】
ユーザイベント管理２３は、ユーザクライアントからの接続、切断や送信完了などの非同期TCP/IPイベントを受け付け、ユーザスレッド（プログラム）を起動する。ユーザイベント管理２３は、スレッドプールで構成されており、ＣＰＵ数に応じて同時起動する処理スレッド数を規定し、規定数を超えた場合はシーケンシャルに起動処理を行うことで、処理スレッド数過多によるＯＳのオーバーヘッドを防ぐ。
【００５２】
ユーザ受付処理２４は、ユーザイベント管理２３が受け付けた各TCP/IPイベントにより起動されるユーザスレッド（プログラム）からなる。ユーザスレッドは、各TCP/IPイベントの種類に応じて起動される８つの処理群を有する。すなわち、(1) ログイン受付処理、(2) ログイン要求受信、(3) ログアウト処理、(4) 配信要求受信処理、(5) キープアライブ受信処理、(6) 送信完了処理、(7) 再送処理、(8) エラー処理である。
【００５３】
(1) ログイン受付処理は、TCP/IP接続を受け付け、ユーザテーブル１１へのエントリを追加する処理である。(2) ログイン要求受信処理は、ユーザIDを指定してデータの配信のために配信処理２７の呼び出しをする処理である。(3) ログアウト受付処理は、TCP/IP切断を受け付け、クリーナップ処理２６へ通知する処理である。(4) 配信要求受信処理は、データテーブル１０の配信待ちキューへのエントリ追加およびデータテーブル１０の最新データを配信処理２７へ通知する処理である。(5) キープアライブ受信処理とは、ユーザの端末４の通信接続が生きているかをサーバ３が監視するために、端末４が一定間隔刻みで送信してくるキープアライブデータを受信した時のキープアライブ受信時刻をユーザテーブル１１に書き込む処理である。(6) 送信完了処理は、TCP/IP送信の完了（送信完了イベント）を受け付け、配信処理２７へ送信完了を通知する処理である。(7) 再送処理は、TCP/IP送信においてパケット分割が発生した場合、配信処理２７へ通知する処理である。(8) エラー処理は、クリーナップ処理２６へ通知する処理である。
【００５４】
キープアライブタイマ処理２５は、設定時間毎にタイマにより起動され、ユーザテーブル１１にキープアライブ受信時刻が入っているかをユーザ数分チェックし、チェック後キープアライブ受信時刻をクリアする。設定時間間隔を過ぎてもキープアライブ受信時刻が入っていないユーザは正常にログアウトしないで終了したと判断してそのユーザの端末４を通信不通とみなし、切断のためにクリーナップ処理２６を呼び出す。
【００５５】
クリーナップ処理２６は、ユーザテーブル１１における指定ユーザのレコードおよびデータテーブル１０の配信要求等の全データの削除（クリア）、およびTCP/IP接続の切断処理を行う。これによりコネクションやユーザテーブル１１などに無駄なリソースが残ることを回避する。
【００５６】
タイマ処理２８は、タイマ方式の配信でタイマにより予め設定された複数種の設定時間ｔk毎の時刻になると、配信処理２７に対し、タイマ方式の設定時間ｔkが適用された配信待ちのエントリユーザに対するタイマ配信処理を行うことを指示するタイマ配信通知を行う。タイマ処理２８は例えばユーザテーブル１１にタイマ方式が適用されたユーザが存在するときのみ、タイマ配信通知を行う。
【００５７】
配信処理２７は、更新データの蓄積、配信に関する制御を行うプログラムからなり、他の処理から受け付けた通知の種類に応じて起動される５つの処理を備える。すなわち(1) 更新データ蓄積処理、(2) プル処理、(3) 更新データ配信処理、(4) 送信完了処理および(5) タイマ配信処理である。なお(3) 〜(5) の処理はプッシュ処理に該当する。
【００５８】
(1) 更新データ蓄積処理は、データテーブル１０を検索し、該当キーレコードが存在する場合、上書きし、存在しない場合は追加保存する。この時、該当レコードの更新フラグをオンにする。
【００５９】
(2)プル処理は、端末４の画面上でのアクセスを受け付けたときに、ユーザイベント管理２３の配信要求受信処理が通知する配信要求によって起動され、データテーブル１０からその要求キーのデータ項目を編集して送信する送信依頼を行う。
【００６０】
(3) 更新データ配信処理は、更新データを受信した際にデータテーブル１０の配信待ちキュー（第１方式、第２方式）にユーザエントリが存在する場合、全てのエントリ数分のループ処理を行う。ユーザテーブル１１におけるエントリユーザのレコードを参照し、送信中フラグがオフの場合はそのユーザに対する送信依頼を行う。送信中フラグがオンの場合は、その場で送信せずにユーザテーブル１１の送信待ちキューにエントリを行う。
【００６１】
(4) 送信完了処理は、送信完了ユーザの送信待ちキューにエントリデータが存在する場合、全てのエントリデータを取り出し、ユーザの間引き送信フラグがオフ（第１方式）の場合、全データ（複数キー含む）を同一パケットでまとめて送信する。またユーザの間引き送信フラグがオン（第２方式またはタイマ方式）の場合、同一キーデータについては最新データのみとする間引き処理を行い、複数キーデータを同一パケットでまとめて送信する。送信待ちキューにエントリデータが存在しない場合は送信中フラグをオフとする。
【００６２】
(5) タイマ配信処理は、タイマ処理２８から設定時間ｔkのタイマ配信要求を受け付けた場合、データテーブル１０を参照してその設定時間ｔkの更新フラグがオンとなっているキーが存在すれば、そのキーについて設定時間ｔkの配信待ちキューのエントリユーザを取り出す。そして、ユーザテーブル１１を参照してそのエントリユーザの送信中フラグがオフの場合は、更新データを送信する送信依頼を行う。一方、送信中フラグがオンの場合は、ユーザテーブル１１の送信待ちキューにエントリする。なお、配信処理２７では上記５つの処理の他に送信中パケットをTCP/IP非同期で再送する再送処理も行われる。
【００６３】
次に、第１方式、第２方式、タイマ方式の各配信処理および端末（ユーザ）毎の通信環境に応じた配信方式に自動切り替えする処理について、図５〜図７に示すフローチャートを用いて説明する。
【００６４】
ここで、図５は、第１方式と第２方式において更新イベントによって起動されるプログラムであり、配信処理２７における更新データ配信処理に相当する。また図６は、タイマ方式においてタイマ処理２８からのタイマ配信要求を受け付けた時に起動されるプログラムであり、配信処理２７におけるタイマ配信処理に相当する。また図７は、送信完了イベントによって起動されるプログラムであり、配信処理２７における送信完了処理に相当する。
【００６５】
多数の端末４がサーバ３にログインし、各ユーザは端末４の画面上に見たい情報があるとこれにアクセスする。サーバ３がそのアクセスを受信すると、送受信部６はアクセスによって要求された情報について要求イベントを発生し、ユーザスレッドが起動されて配信要求受信処理によって配信要求が配信処理２７に通知される。さらに配信処理２７ではその通知によってプル処理が起動され、要求イベントに応じる形でプル処理部１６によってプル方式でのデータ送信が行われる。ログイン後の端末４とサーバ３との接続は維持される。また、サーバ３には情報発信源サーバ２から所定の情報の更新データが逐次送信されてくる。サーバ３が更新データを受信して送受信部６からの更新イベントを受け付けると、更新側イベント管理２１は更新受付処理２２のデータスレッドを起動させる。そして受信処理によって更新データは更新通知と共に配信処理２７に引き渡される。
【００６６】
＜更新起動型配信依頼ルーチン＞
配信処理２７は、更新データおよび更新通知を受信する度に、図５の更新起動型配信依頼ルーチンを実行する。これは第１方式と第２方式のユーザを対象とする配信処理である。
【００６７】
図５に示すように、ステップ（以下、「Ｓ」と記す）１１では、データテーブル１０における該当キーのデータ項目に更新データを上書き（更新）する。この際、データテーブル１０においてその該当キーのタイマ方式用の更新フラグをオンにする。
【００６８】
Ｓ１２では、そのキーを待つユーザ（第１方式または第２方式）の配信待ちキューを読み出し、最初であるここでは配信待ちキューに格納されたうちまず最初のユーザを読み出す。
【００６９】
Ｓ１３では、ユーザテーブル１１を参照し、送信可能状態（送信中フラグオフ）にあるユーザ（接続ハンドル）であるか否かを判断する。送信可能状態のユーザであればＳ１４に進み、送信中ユーザであればＳ１６に進む。
【００７０】
Ｓ１４では、そのユーザの接続ハンドルを指定して送受信部６に更新データの送信依頼をする。
Ｓ１５では、送信依頼を終えたユーザを送信中とする。つまり、ユーザテーブル１１においてそのユーザ（接続ハンドル）の送信中フラグをオンにする。
【００７１】
Ｓ１６では、ユーザテーブル１１中のそのユーザ（接続ハンドル）の送信待ちキューに更新データを格納（エントリ）する。
Ｓ１７では、送信待ちキューの格納数が上限値を超えたかどうかを判断する。その格納数が上限値を超えた場合はＳ１８に進み、上限値を超えない場合はＳ１９に進む。
【００７２】
Ｓ１８では、次段階の配信方式へ移行する。すなわち送信待ちキューの格納数が上限値を超えたユーザに適用された配信方式が第１方式であれば第２方式に移行し、その上限値を超えたユーザに適用された配信方式が第２方式であればタイマ方式に移行する。第１方式から第２方式への移行は、ユーザテーブル１１の間引き送信フラグをオンにすることによって行われる。また第２方式からタイマ方式への移行は、データテーブル１０中の配信待ちキューの格納データをタイマ方式の設定時間ｔ１の配信待ちキューに移動させることで行う。
【００７３】
Ｓ１９では、配信待ちキューにエントリされた全ユーザ（接続ハンドル）について処理を終えたか否かを判断する。全ユーザ終了したときは当該ルーチンを終了する。一方、全ユーザ終了していなければＳ１２に戻り、全ユーザの処理を終えるまでＳ１２〜Ｓ１８の処理をループ処理で繰り返し行う。これにより配信待ちキューのうち送信中でない各ユーザ（接続ハンドル）に対する更新データの送信はユーザ一人ずつ順番にシリアライズ送信依頼（シリアライズ処理）される。この配信の指示を受けた送受信部（非同期型TCP/IP）６は各端末４に順番に更新データを配信する。ここで最初の端末４と最後の端末４の発信時間差は、非同期型TCP/IPの使用によりネットワークドライバ〜ネットワークカード（ハードウェア）に近いレベルの差だけとなる。各端末４からの受信応答確認は、アプリケーションプログラムと非同期で動作する送受信部６が行うため、アプリケーション上の本ルーチンを実行するＣＰＵは、配信の指示を終えれば直ぐに次の処理に移ることができる。また配信待ちキューのうち送信中の各ユーザ（接続ハンドル）については、各ユーザ毎の送信待ちキューに更新データがエントリされる。
【００７４】
＜ｔkタイマ起動型配信依頼ルーチン＞
タイマ処理２８（１２）では設定時間ｔk毎の時を計時しており、設定時間ｔk（ｔk＝ｔ１，ｔ２，〜ｔｎ）のうちいずれかが経過する度にタイマ処理２８からその時ｔk とタイマ配信要求が配信処理２７に通知される。このタイマ配信要求ｔkを受信すると、図６に示すｔkタイマ起動型配信依頼ルーチンが起動される。
【００７５】
Ｓ２１では、データテーブル１０を参照し、最初であるここでは最初のキーについて時間ｔk の更新フラグがオンとなっているか否かを判断する。全てのキーについて順番に見ていくが、先ず始めは最初のキーについて更新フラグがオンであるかどうかをみる。設定時間ｔkの更新フラグがオンであればＳ２２に進み、その更新フラグがオフであればＳ３０に進む。
【００７６】
Ｓ２２では、そのキーの更新データを待つユーザの配信待ちキューを読み出し、最初であるここでは配信待ちキューに格納されたうちまず最初のユーザを読み出す。
【００７７】
Ｓ２３では、ユーザテーブル１１を参照し、送信可能状態（送信中フラグオフ）にあるユーザ（接続ハンドル）であるか否かを判断する。送信可能状態のユーザであればＳ２４に進み、送信中ユーザであればＳ２６に進む。
【００７８】
Ｓ２４では、そのユーザの接続ハンドルを指定して送受信部６に更新データの送信依頼をする。
Ｓ２５では、送信依頼を終えたユーザを送信中とする。つまり、ユーザテーブル１１においてそのユーザ（接続ハンドル）の送信中フラグをオンにする。
【００７９】
一方、Ｓ２６では、ユーザテーブル１１中のそのユーザ（接続ハンドル）の送信待ちキューに更新データを格納（エントリ）する。
Ｓ２７では、送信待ちキューの格納数が上限値を超えたかどうかを判断する。その格納数が上限値を超えた場合はＳ２８に進み、上限値を超えない場合はＳ２９に進む。
【００８０】
Ｓ２８では、次段階の時間ｔkへ移行する。すなわちタイマ方式の設定時間を、設定時間ｔk→設定時間ｔk+1に移行する。この設定時間ｔk→ｔk+1への移行は、データテーブル１０中の設定時間ｔkに対応する更新フラグと配信待ちキューを、次に適用される設定時間ｔk+1の項目欄に移動させることにより行う。
【００８１】
Ｓ２９では、配信待ちキューにエントリされた全ユーザ（接続ハンドル）の処理を終えたか否かを判断する。全ユーザ終了したときはＳ３０に進む。一方、全ユーザ終了していなければＳ２２に戻り、全ユーザ分の処理を終えるまでＳ２２〜Ｓ２８の処理をループ処理で繰り返し行う。これにより配信待ちキューのうち送信中でない各ユーザ（接続ハンドル）に対する更新データの送信はユーザ一人ずつ順番にシリアライズ送信依頼（シリアライズ処理）される。この配信の指示を受けた送受信部（非同期型TCP/IP）６は各端末４に順番に更新データを配信する。また配信待ちキューのうち送信中の各ユーザ（接続ハンドル）については、各ユーザ毎の送信待ちキューに更新データがエントリされる。
【００８２】
Ｓ３０では、データテーブル１０の全キー終了したか否かを判断する。データテーブル１０の全キーについて更新フラグを走査し終われば当該ルーチンを終了する。一方、全キーについて更新フラグを走査し終わっていなければＳ２１に戻る。こうして更新フラグオンの更新データについてＳ２２〜Ｓ２９の処理を繰り返し、これを更新フラグオンの全てのキーについて繰り返す。なお、各設定時間ｔ１，ｔ２，〜ｔｎの計時は、タイマ配信通知が同時刻にならないように設定することが望ましい。
【００８３】
＜送信完了起動型配信依頼ルーチン＞
送受信部６は端末４からの受信応答（ＡＣＫ）を受信すると送信完了イベントを発生する。これにより配信処理２７は、ユーザ受付処理２４から送信完了通知を受け付けると、図７の送信完了起動型配信依頼ルーチンを起動する。
【００８４】
まずＳ３１では、ユーザテーブル１１を参照し、その送信完了ユーザ（接続ハンドル）の送信待ちキューにエントリデータがあるか否かを判断する。送信待ちエントリデータがなければＳ３７に進み、送信可能状態の設定（送信中フラグオフ）とする。一方、送信待ちエントリデータがあるときにはＳ３２に進む。
【００８５】
Ｓ３２では、送信待ちキューのエントリデータを読み出す。
Ｓ３３では、間引き送信フラグがオンであるか否かを判断する。つまりそのユーザ（接続ハンドル）に適用された配信方式が、第２方式またはタイマ方式であるかを判断する。間引き送信フラグがオンとなった第２方式またはタイマ方式である場合はＳ３４に進み、一方、間引き送信フラグがオフとなっている第１方式の場合はＳ３５に進む。
【００８６】
Ｓ３４では、送信待キューのエントリデータのうち同一キーデータついては、最新の更新データのみとする間引き処理をする。
Ｓ３５では、間引き処理後のデータを１つにまとめて、送受信部６にまとめ送信依頼をする。
【００８７】
Ｓ３６では、送信依頼を終えたユーザ（接続ハンドル）を送信中（送信中フラグオン）とする。
よって図８に示すように、更新データＡを受信すると、この情報を待つ第１方式または第２方式が適用された端末４のうち送信中でない端末（ユーザ）４に対しこの更新データＡのデータパケットが送信される。この際、この更新データＡを待つ複数の端末４に順番に更新データＡがシリアライズに送信される。データパケットを送信した後、そのデータを受信した端末４からの受信応答（ＡＣＫ）を受信するまでの間は、その端末４は送信中とされる。
【００８８】
この送信中の間に新たに受信した更新データ「Ｂ，Ｃ，Ｄ」は送信待ちキューに格納される。そしてＡＣＫを受信して送信完了となった端末４に対してはデータ「Ｂ，Ｃ，Ｄ」はまとめて送信される。例えば送信待ちキューに「Ｂ，Ｃ，Ｄ，Ｂ」が格納されていたとすると、その端末４が第１方式を適用されたものであれば、データ「Ｂ，Ｃ，Ｄ，Ｂ」の全てがまとめて送信される。一方、その端末４が第２方式を適用されたものであれば、データ「Ｂ，Ｃ，Ｄ，Ｂ」のうち更新時期の異なる同一キーデータＢについては直近の最新データのみが採用される間引きがなされた後のデータ「Ｃ，Ｄ，Ｂ」がまとめて送信される。
【００８９】
また端末４が使用する通信環境に起因してその通信速度が遅いために、ＡＣＫを受信するまでの所要時間が長く、送信待ちキューの格納数が上限値を超えると、その端末４に適用される配信方式が次段階の配信方式に切り替えられる。すなわち第１方式→第２方式、第２方式→タイマ方式に切り替えられる。よって、送信待ちキューの格納数が上限値を超えるような通信速度の遅い端末４に第２方式が適用されると、データ量を小さくして通信速度を少しでも速くでき、またユーザの端末４では画面上に古いデータが一時的に表示されることなく最新の更新データが早く表示される。
【００９０】
またタイマ方式では、設定時間ｔk を経過する度に更新データがあるかどうかを確かめ、更新データがあればこの情報を待つタイマ方式の端末４のうち送信中でない複数の端末（ユーザ）４に順番に更新データＡがシリアライズに送信される。
【００９１】
送信中の間に新たに受信した更新データ「Ｂ，Ｃ，Ｄ，Ｂ」は送信待ちキューに格納される。そしてＡＣＫを受信して送信完了となった端末４に対してはデータ「Ｂ，Ｃ，Ｄ，Ｂ」のうち更新時期の異なる同一キーデータＢについては直近の最新データのみが採用される間引きがなされ、間引き後のデータ「Ｃ，Ｄ，Ｂ」がまとめて送信される。また通信速度の遅い端末４であってその送信待ちキューの格納数が上限値を超えるものについては、タイマ方式の設定時間ｔk がさらに長い次段階の設定時間ｔk+1に切り替えられる。よって設定時間ｔk が段階的に長くされていくことにより、結果的にデータの間引き率が大きくなるので、データ量を小さくして通信速度を少しでも速くでき、またユーザの端末４では画面上に最新の更新データが早く表示される。
【００９２】
以上詳述したように本実施形態によれば、以下の効果が得られる。
（１）非同期型ＴＣＰ／ＩＰを使用し、データ更新検出時に配信処理部１５（２７）は、非同期で動く送受信部６に、データの配信または送信の依頼を出すだけでなので、配信先の端末４からの受信応答（ＡＣＫ）を待つことなく直ぐに次の処理に移ることができる。また複数ユーザに対する配信処理は１つの処理スレッド（Ｓ１２〜Ｓ１５またはＳ２２〜Ｓ２５）のループ処理によってユーザ一人ずつ順番にデータがシリアライズ送信されるので、マルチタスク処理のようなプログラム間の切換処理による遅延を回避でき、例えば数百人以上の多数の端末４に同一データを配信するときには、マルチタスク処理を採用する場合に比べ、配信処理の所要時間を短く済ませられ、ＯＳディスパッチを防ぐことができる。また、ループ処理であることからシリアライズ送信される複数ユーザ間で送信データを共有でき、メモリの使用容量がデータ１つ分で済むのでメモリ資源も有効利用できる。よって、使用メモリの肥大化に原因するオーバーヘッドを避けられ、多数ユーザの同時配信に対しても通信の遅延を極力避けることが可能となる。また、シリアライズ処理で問題となる最初のユーザと最後のユーザの時間差は、非同期型TCP/IPの使用によりネットワークドライバソフト〜ネットワークカード（ハードウエア層）に近いレベルの差だけとなる。
【００９３】
（２）さらに送信中のユーザに対しては送信せず更新データをそのユーザの送信待ちキューに一時格納し、その後、そのユーザが送信可能状態になると、その送信待ちキューにそれまで溜まったデータを１つにまとめて送信するまとめ送信処理を採用する。よって、データを個々に送信する場合に比べデータサイズが小さく済むうえ、送信処理を一度で済ませられるため、通信効率を向上させることができる。また、データサイズを小さくできることから、パケット数が少なく済み、例えばパケット課金方式を採用するユーザは通信費を安く抑えられる。
【００９４】
（３）ユーザ毎の通信速度を送信待ちキューの格納数から判定し、通信速度の遅いユーザに対してはその通信速度に応じた配信方式に、ユーザ毎に、第１方式→第２方式→タイマ方式の順に段階的に切り替えるようにした。従って、サーバ３の負担を軽減でき、サーバコンピュータのパフォーマンスが通信速度の遅い一部のユーザによって左右されることを防ぎ易くなる。
【００９５】
（４）第１方式から第２方式に切り替えられると、まとめ送信する際に、同一キーデータについては最新の更新データのみを採用する間引き処理をする。このため、データサイズを小さくして送信速度を高められるとともに、サーバコンピュータの負担も軽減できる。
【００９６】
（５）第２方式からタイマ方式に切り替えられると、一定時間間隔ｔk毎に起動されて、その時に更新データがあればその配信待ちキューのユーザに更新データをループ処理によってシリアライズ送信する。よって、一定時間間隔ｔk内に複数回更新があっても直近の最新データのみが送信され、事実上の間引きが行われる。またタイマ方式では、送信中のユーザについては送信完了後にそれまで溜まったデータをまとめて送信するまとめ送信と、そのまとめ送信の際に同一キーデータについては最新データのみとする間引き処理とが行われる。従って、サーバ３の負担を軽減でき、サーバコンピュータのパフォーマンスが通信速度の遅い一部のユーザによって左右されることを防ぎ易くなる。
【００９７】
（６）タイマ方式では設定時間ｔkを複数段階（ｔk＝ｔ1，…ｔn）に設定したので、通信速度の特に遅いユーザに適用するタイマ方式の設定時間ｔkを切り替えることにより、サーバ３の負担を軽減でき、サーバコンピュータのパフォーマンスが通信速度の遅い一部のユーザによって左右されることを防ぎ易くなる。
【００９８】
なお、実施の形態は、上記に限定されず以下の態様でも実施できる。
・ 第１方式、第２方式、タイマ方式などの配信方式の選択は、サーバ３の判定処理に従う自動切替えではなく、端末４からユーザ自身が指定する方法を採用してもよい。
【００９９】
・ 第１方式、第２方式、タイマ方式の全てを採用することに限定されない。例えば第１方式のみを採用してもよい。また第２方式のみを採用してもよい。第１方式と第２方式のみを採用してもよい。第１方式とタイマ方式のみを採用してもよい。第２方式とタイマ方式のみを採用してもよい。タイマ方式のみを採用してもよい。タイマ方式のみを採用する場合、設定時間は１段階でもよいが、第１方式並みのリアルタイム性が確保される最も時間間隔の短いものと、これよりも長い時間間隔の少なくとも２通りを設定することが望ましい。
【０１００】
・ 更新検出手段は、更新イベントによるのではなく、非常に短い時間（例えば１秒以内の値）間隔で起動するタイマ起動としてもよい。
２．タイマ方式の設定時間（インターバル）は、扱う情報の種類に応じて適宜設定してよい。例えば更新が秒単位であればタイマ配信の設定時間を、２秒、５秒、１０秒、…３分などとし、例えば更新が１０秒単位であればタイマ送信の設定時間をもう少し長く、３０秒、１分、…１０分などとしてもよい。
【０１０１】
・ 端末毎の通信速度を直接又は間接的に判定するコンピュータが備える判定手段の判定方法は、サーバ３でのデータ送信開始時からその受信応答（ＡＣＫ）を受信するまでの所要時間から通信速度を判定するものであってもよい。
【０１０２】
・ 更新起動時やタイマ起動時に更新データを配信（シリアライズ送信）する順番を、配信待ちキューの順番を一定の規則に従って入れ替えることにより、変更する配信順序入れ替え方式を採用できる。この方法によれば、ユーザの公平性を担保することができる。
【０１０３】
・ アプリケーションで構成される配信手段から出された配信依頼を非同期に実行する手段または段階は、非同期型通信プロトコルを用いるものに限定されない。配信処理用プログラム（配信手段）と非同期動作するものであれば他のプログラム等（手段または段階）でもよい。
【０１０４】
・ 本明細書中の用語を次のように定義する。「非同期型通信プロトコル」：アプリケーション上のプログラムとは非同期で動作し、コンピュータネットワークを通じた端末等との間で行う通信を司る通信処理用ソフトウェアであり、特にＯＳ（ミドルウェア含む）として用意されるものである。
【０１０５】
前記実施形態から把握される請求項以外の技術的思想を、以下に記載する。
（１）請求項２において、前記配信手段が前記処理を行って出された配信依頼を受け付けて、コンピュータの非同期型通信プロトコルで構成される送受信手段が該配信の依頼を実行する段階とを備えているプッシュ型情報配信方法。
【０１０６】
（２）請求項４〜７のいずれかにおいて、前記配信手段は、前記送受信手段に依頼する際に前記送受信手段が送信中の端末については端末毎に更新データの配信待ちキューを管理し、前記判定手段は、端末毎に管理された配信待ちキューの格納数が予め設定された設定数を超えたことをもって、端末毎の通信速度を判定することを特徴とするプッシュ型情報配信用プログラム。
【０１０７】
【発明の効果】
以上詳述したように請求項１〜９に記載の発明によれば、秒単位や分単位で更新されるデータでもユーザの端末にさほど表示の遅延を伴わずインターネット等のネットワークを介して配信でき、しかもサーバとして用いられるコンピュータの負担を軽減することによって、１台のサーバが受け持つ端末数を増やすことができる。
【０１０８】
請求項２及び４〜９に記載の発明によれば、ユーザ毎の通信環境に応じて配信方式を切り替えることによって、通信環境の悪い一部のユーザによってサーバ全体のパフォーマンスが左右されることを起き難くすることができる。
【図面の簡単な説明】
【図１】 プッシュ型配信システムを示す概略構成図。
【図２】 アプリケーションプログラムを構成する各処理を示すブロック図。
【図３】 データテーブル図。
【図４】 ユーザテーブル図。
【図５】 更新起動型配信依頼ルーチンのフローチャート。
【図６】 タイマ起動型配信依頼ルーチンのフローチャート。
【図７】 送信完了起動型配信依頼ルーチンのフローチャート。
【図８】 配信方式の処理の流れを説明する説明図。
【符号の説明】
１…プッシュ型情報配信システム、２…情報発信源サーバ、３…プッシュ型情報配信装置及びコンピュータとしての配信用サーバ（サーバコンピュータ）、４…端末、５…コンピュータネットワークとしてのインターネット、６…送受信手段としての送受信部、７…接続ハンドル、１０…データテーブル、１１…ユーザテーブル、１２…タイマ手段としてのタイマ、１３…更新検出手段としての更新受付部、１５…配信手段としての配信処理部、１７…配信手段を構成するとともに切替手段としてのプッシュ処理部、１７Ａ…判定手段としての判定部、１９…ＯＳ層、２０…アプリケーション層。

Claims (9)

1. 端末から受け付けた情報についてそのデータが更新されると、その更新されたデータを前記端末に対しコンピュータネットワークを通じてプッシュ方式で配信するプッシュ型情報配信方法であって、
   コンピュータのＯＳ層に格納された非同期型通信プロトコルによって複数の端末に対する送受信処理を司る送受信手段を構築するとともに、プッシュ方式の配信処理を該送受信手段に非同期で実行させるように指示するようにし、
   端末から受け付けた情報についてそのデータが更新されたことをコンピュータの更新検出手段が検出する段階と、
   コンピュータの配信手段が、前記更新が検出された前記情報の配信待ち状態にある複数の端末のうち送信可能状態にある端末に該更新データを配信するための配信処理を前記送受信手段にシリアライズ処理で指示するとともに、その際に前記送受信手段が送信中の端末に対しては送信せず該更新データを一時保管し、当該送信中の端末が送信可能状態になったことを知ると、それまでに保管されて溜まったデータをまとめて該端末に送信する送信処理を前記送受信手段に指示する段階と
   を備えたことを特徴とするプッシュ型情報配信方法。
2. 請求項１に記載のプッシュ型情報配信方法において、
   前記情報のデータ更新検出時に起動されてその情報を待つ端末に対し該更新データを配信する更新起動型配信方式の処理をコンピュータの配信手段が行う段階と、
   端末毎の通信速度を直接又は間接的にコンピュータが判定する段階と、
   更新起動型配信方式が適用された端末のうち通信速度が基準より遅いと判断された端末についてはその適用される配信方式を、更新起動型配信方式からタイマ起動型配信方式にコンピュータの切替手段が切り替える段階と、
   コンピュータのタイマ手段により設定時間毎に起動されてその起動時の最新の更新データを前記タイマ起動型配信方式が適用された端末に配信するタイマ起動型配信方式の処理を前記配信手段が行う段階と
   を備えたことを特徴とするプッシュ型情報配信方法。
3. 端末から受け付けた情報についてそのデータが更新されると、その更新されたデータを前記端末に対しコンピュータネットワークを通じてプッシュ方式で配信するサーバ機能をコンピュータに実現させるプッシュ型情報配信用プログラムであって、
   特に、コンピュータのＯＳ層に格納された非同期型通信プロトコルによって構築された送受信手段に対しプッシュ方式の配信処理を指示するまでの処理を行うアプリケーションが有するプログラムであり、
   コンピュータを、
   端末から受け付けた情報についてそのデータが更新されたことを検出する更新検出手段と、
   前記更新検出手段が前記情報についてそのデータが更新されたことを検出すると、その更新データを該情報の配信待ち状態にある複数の端末のうち送信可能状態にある端末に配信するための配信処理を前記送受信手段にシリアライズ処理で指示するとともに、その際に前記送受信手段が送信中の端末に対しては送信せず該更新データを一時保管し、当該送信中の端末が送信可能状態になったことを知ると、それまでに保管されて溜まったデータをまとめて該端末に送信するための送信処理を前記送受信手段に指示する配信方式をとる配信手段として機能させるプッシュ型情報配信用プログラム。
4. 請求項３に記載のプッシュ型情報配信用プログラムにおいて、
   前記配信手段は、前記配信方式である第１配信方式と、該第１配信方式とはデータ更新検出時に前記送信可能状態の端末に対する配信処理をシリアライズ処理で指示し、前記送信中の端末に対して前記更新データを一時保管するまでは同じ処理で、送信中の端末が送信可能状態となったことを知ると、それまでに保管されて溜まったデ−タのうち更新時期の異なる同一情報のデータについては最新データのみを採用する間引き処理をして該間引き処理後のデータをまとめて該端末に送信する送信処理を前記送受信手段に指示する第２配信方式とを採用し、
   コンピュータを、
   前記配信手段と、
   端末毎の通信速度を直接又は間接的に判定する判定手段と、
   前記判定手段により通信速度が基準よりも遅いと判定された端末に対しては、前記第１配信方式から第２配信方式に切り替える切替手段として機能させるプッシュ型情報配信用プログラム。
5. 請求項３又は４に記載のプッシュ型情報配信用プログラムにおいて、
   前記配信手段は、プッシュ方式配信の対象とされる端末に適用される配信方式として、データ更新検出時に起動される前記配信方式である更新起動型配信方式の処理と、コンピュータのタイマ手段によって設定時間毎に起動されるタイマ起動型配信方式の処理とを採用しており、
   コンピュータを、
   端末毎に通信速度を直接又は間接的に判定する判定手段と、
   前記判定手段により通信速度が基準よりも遅いと判定された端末に対してはその適用される方式を、前記更新起動型配信方式からタイマ起動型配信方式に切り替える切替手段と、
   前記タイマ起動型配信方式が適用された端末に対しては、前記タイマ手段による設定時間毎の起動時における最新の更新データを該情報の配信待ち状態にある複数の端末のうち送信可能状態にある端末に配信する配信処理を前記送受信手段にシリアライズ処理で指示するとともに、その際に前記送受信手段が送信中の端末に対しては送信せず該更新データを一時保管し、当該送信中の端末が送信可能状態になったことを知ると、それまでに保管されて溜まったデータをまとめて該端末に送信する送信処理を前記送受信手段に指示する前記配信手段として機能させるプッシュ型情報配信用プログラム。
6. 請求項５に記載のプッシュ型情報配信用プログラムにおいて、
   前記配信手段には、前記タイマ起動型配信方式としてその起動される設定時間が異なる複数段階用意されており、
   端末毎に通信速度を直接又は間接的に判定する判定手段と、
   タイマ起動型配信方式が適用された端末のうち、前記判定手段により通信速度が基準よりも遅いと判定された端末に対しては、前記タイマ手段によって起動される設定時間のより長い段階へと切り替える切替手段と
   をサーバコンピュータに機能させるプッシュ型情報配信用プログラム。
7. 端末から受け付けた情報についてそのデータが更新されると、その更新されたデータを前記端末に対しコンピュータネットワークを通じてプッシュ方式で配信するサーバ機能をコンピュータに実現させるプッシュ型情報配信用プログラムであって、
   特に、コンピュータのＯＳ層に格納された非同期型通信プロトコルによって構築された送受信手段に対しプッシュ方式の配信処理を指示するまでの処理を行うアプリケーションが有するプログラムであり、
   コンピュータを、
   複数段階設定された設定時間毎にコンピュータのタイマ手段によって起動され、その起動時における前記情報についての最新の更新データを該情報の配信待ち状態にある複数の端末のうち送信可能状態にある端末に配信する配信処理を前記送受信手段にシリアライズ処理で指示するとともに、その際に前記送受信手段が送信中の端末に対しては送信せず該更新データを一時保管し、当該送信中の端末が送信可能状態になったことを知ると、それまでに保管されて溜まったデータをまとめて該端末に送信する送信処理を前記送受信手段に指示する配信手段と、
   端末毎に通信速度を直接又は間接的に判定する判定手段と、
   前記判定手段により通信速度が基準よりも遅いと判定された端末に対しては、前記タイマ手段によって起動される設定時間がより長い段階の配信方式に切り替える切替手段として機能させるプッシュ型情報配信用プログラム。
8. 請求項３〜７のいずれか一項に記載のプッシュ型情報配信用プログラムを記録したコンピュータ読み取り可能な記録媒体。
9. 端末から受け付けた情報についてそのデータが更新されると、その更新されたデータを前記端末に対しコンピュータネットワークを通じてプッシュ方式で配信するプッシュ型情報配信装置であって、
   請求項３〜７のいずれか一項に記載された、コンピュータが備える前記送受信手段と、コンピュータが備える前記配信手段とを少なくとも含む、コンピュータが備える前記各手段を備えたことを特徴とするプッシュ型情報配信装置。

Images