(57)【特許請求の範囲】
【請求項１】
複数の利用者端末からの送信を、受付を行うサーバコンピュータである受付サーバにおいて受け付ける際に、各利用者端末からの送信が集中しないように、各利用者端末に分散して送信させるシステムであって、
前記利用者端末は、
事前に前記受付サーバから取得されて利用者端末内に記憶された、応答受付開始時刻からの経過時間ｔに応じて想定されるアクセス数である想定アクセス数Ｘ（ｔ）を利用して、当該想定アクセス数Ｘ（ｔ）に直前の経過時間ｔ−１における想定アクセス待ち数Ｗ（ｔ−１）を加えることにより、経過時間ｔにおけるアクセストライ数Ｙ（ｔ）を算出する機能と、
前記アクセストライ数Ｙ（ｔ）が、前記受付サーバの受付許容数より小さい場合にデータを前記受付サーバに送信すると共に、前記アクセストライ数Ｙ（ｔ）が、前記受付許容数より大きい場合には、前記アクセストライ数Ｙ（ｔ）を最大値として発生させた乱数が前記受付許容数より小さいときに、データを前記受付サーバに送信し、前記乱数が前記受付許容数より大きいときに、前記アクセストライ数Ｙ（ｔ）から前記受付許容数を減じることにより経過時間ｔにおける想定アクセス待ち数Ｗ（ｔ）を算出する機能と、
を有するものであることを特徴とする分散送信システム。
【請求項２】
前記応答は、出題された問題に対する解答であって、
前記想定アクセス数Ｘ（ｔ）は、出題の性質に応じて異なるものであることを特徴とする請求項１に記載の分散送信システム。
【請求項３】
送信の受付を行うサーバコンピュータである受付サーバにネットワークを通じて送信する利用者端末であって、
事前に前記受付サーバから取得されて利用者端末内に記憶された、応答受付開始時刻からの経過時間ｔに応じて想定されるアクセス数である想定アクセス数Ｘ（ｔ）を利用して、当該想定アクセス数Ｘ（ｔ）に直前の経過時間ｔ−１における想定アクセス待ち数Ｗ（ｔ−１）を加えることにより、経過時間ｔにおけるアクセストライ数Ｙ（ｔ）を算出する機能と、
前記アクセストライ数Ｙ（ｔ）が、前記受付サーバの受付許容数より小さい場合にデータを前記受付サーバに送信すると共に、前記アクセストライ数Ｙ（ｔ）が、前記受付許容数より大きい場合には、前記アクセストライ数Ｙ（ｔ）を最大値として発生させた乱数が前記受付許容数より小さいときに、データを前記受付サーバに送信し、前記乱数が前記受付許容数より大きいときに、前記アクセストライ数Ｙ（ｔ）から前記受付許容数を減じることにより経過時間ｔにおける想定アクセス待ち数Ｗ（ｔ）を算出する機能と、
を有するものであることを特徴とする利用者端末。
【請求項４】
利用者が利用する端末装置である利用者端末に、
事前に、利用者端末からの送信データの受付を行うサーバコンピュータである受付サーバから取得されて利用者端末内に記憶された、応答受付開始時刻からの経過時間ｔに応じて想定されるアクセス数である想定アクセス数Ｘ（ｔ）を利用して、当該想定アクセス数Ｘ（ｔ）に直前の経過時間ｔ−１における想定アクセス待ち数Ｗ（ｔ−１）を加えることにより、経過時間ｔにおけるアクセストライ数Ｙ（ｔ）を算出する機能と、
前記アクセストライ数Ｙ（ｔ）が、前記受付サーバの受付許容数より小さい場合にデータを前記受付サーバに送信すると共に、前記アクセストライ数Ｙ（ｔ）が、前記受付許容数より大きい場合には、前記アクセストライ数Ｙ（ｔ）を最大値として発生させた乱数が前記受付許容数より小さいときに、データを前記受付サーバに送信し、前記乱数が前記受付許容数より大きいときに、前記アクセストライ数Ｙ（ｔ）から前記受付許容数を減じることにより経過時間ｔにおける想定アクセス待ち数Ｗ（ｔ）を算出する機能と、
を実行させるための端末用プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、多くのデータが集中して送信される場合に、そのデータを分散して送信するための技術に関する。
【背景技術】
【０００２】
近年、テレビ番組やイベント開催時に内容と連動したアンケートやクイズ等の番組連動型コンテンツの実施が多く行われている。コンテンツとしては、テレビ番組内容と同内容のクイズを視聴者に参加させたり、番組内の議論内容について視聴者の意見を募集したり、プレゼントへの応募を行わせたりといった例がある。
【０００３】
このような番組連動型で双方向機能を利用するコンテンツにおいては、利用者がアクセスを行うタイミングが集中してしまうことがある。アクセスが集中すると、システムの構成やハードウェアやインフラの性能によっては、回答送信や応募ができないといったコンテンツの重要な機能である双方向機能が利用できなくなる。テレビ番組やイベントでは、全ての視聴者・参加者に対してコンテンツの視聴と連動企画への参加を保障しなければならないため、アクセス集中の処理は、サービス提供の基盤となる機能となる。
【０００４】
そこで、サーバへの負荷が集中するのを防ぐため、他のサーバに負荷を分散させる手法等も提案されている（例えば、特許文献１参照）。
【特許文献１】特開２００４−３０４６９８号公報
【発明の開示】
【発明が解決しようとする課題】
【０００５】
しかしながら、上記従来の技術では、別サーバを増設する必要があるが、このようなサーバの増設にはコストがかかるという問題がある。
【０００６】
そこで、本発明は、受け付けるサーバ側ではなく、利用者端末側で、送信するタイミングを判断し、全体として分散して送信することが可能な分散送信システムを提供することを課題とする。
【課題を解決するための手段】
【０００７】
上記課題を解決するため、本発明では、複数の利用者端末からの送信を、受付を行うサーバコンピュータである受付サーバにおいて受け付ける際に、各利用者端末からの送信が集中しないように、各利用者端末に分散して送信させるシステムとして、前記利用者端末は、事前に前記受付サーバから取得されて利用者端末内に記憶された、応答受付開始時刻からの経過時間ｔに応じて想定されるアクセス数である想定アクセス数Ｘ（ｔ）を利用して、当該想定アクセス数Ｘ（ｔ）に直前の経過時間ｔ−１における想定アクセス待ち数Ｗ（ｔ−１）を加えることにより、経過時間ｔにおけるアクセストライ数Ｙ（ｔ）を算出する機能と、前記アクセストライ数Ｙ（ｔ）が、前記受付サーバの受付許容数より小さい場合にデータを前記受付サーバに送信すると共に、前記アクセストライ数Ｙ（ｔ）が、前記受付許容数より大きい場合には、前記アクセストライ数Ｙ（ｔ）を最大値として発生させた乱数が前記受付許容数より小さいときに、データを前記受付サーバに送信し、前記乱数が前記受付許容数より大きいときに、前記アクセストライ数Ｙ（ｔ）から前記受付許容数を減じることにより経過時間ｔにおける想定アクセス待ち数Ｗ（ｔ）を算出する機能を有する構成としたことを特徴とする。
【発明の効果】
【０００８】
本発明によれば、経過時間ｔに応じた想定アクセス数Ｘ（ｔ）を利用して、各利用者端末が個々に、送信可能かどうかを判断し、サーバに対して送信を行うようにしたので、サーバ等のコストのかかる増設を行うことなく分散送信を行うことが可能となる。
【発明を実施するための最良の形態】
【０００９】
以下、本発明の好適な実施形態について、図面を参照して詳細に説明する。
（システム構成）
図１は、本発明に係る分散送信システムの一実施形態を示す構成図である。図１において、１０ａ〜１０ｃは利用者端末、２０はネットワーク、３０は受付サーバである。
【００１０】
利用者端末１０は、ネットワーク２０を介して受付サーバ３０とデータの送受信が可能とされている端末装置である。利用者端末１０としては、携帯電話機、ＰＤＡ（携帯情報端末）等の携帯型の機器、およびパーソナルコンピュータ等を用いることができるが、携帯可能で普及している携帯電話機を利用するのが好ましい。
【００１１】
受付サーバ３０は、利用者端末１０からの解答を受け付けて集計する機能を有するサーバコンピュータである。本実施形態では、受付サーバ３０は、利用者端末１０において起動させるための端末用プログラムを保有し、利用者端末１０からの要求に応じて、端末用プログラムを利用者端末１０に供給する機能も有している。
【００１２】
（端末用プログラムのダウンロード）
続いて、本発明の分散送信システムを、テレビで放送されるクイズ番組の解答に用いる場合を例にとって説明していく。図２は、クイズ番組への参加申請から時差の算出までを行う場合のフローチャートである。まず、クイズに参加を希望する利用者は、放送局が運営するクイズ番組のＷｅｂサイトにアクセスする（Ｓ１）。Ｗｅｂサイトは、インターネット上の適当なＷｅｂサーバに開設しておくことができるが、本実施形態では、受付サーバ３０上に開設されているものとする。このＷｅｂサイト上において、利用者は、クイズに参加する旨、および自身の氏名等を入力する。受付サーバ３０では、利用者端末１０から利用者に関する情報を受け取ると、新たに会員ＩＤを発行して、受け取った情報と共に、受付サーバ３０内の会員データベースに登録する（Ｓ２）。さらに、受付サーバ３０は発行した会員ＩＤと共に、自身が保有している端末用プログラム、受付サーバ３０のサーバ性能値Ｎ、想定アクセスデータを利用者端末１０に送信する（Ｓ３）。利用者端末１０は、端末用プログラムを受信すると、以降は、この端末用プログラムを起動して所定の処理を行うことが可能となる。また、サーバ性能値Ｎ、想定アクセスデータは、利用者端末１０内の所定の記憶領域に記憶される。サーバ性能値とは、受付サーバ３０が１秒間に受付可能なアクセス数を示すものである。想定アクセスデータとは、解答開始時刻からの時間経過に応じた想定アクセス数を示すものであり、番組の種類ごとに異なる。ここで、想定アクセスデータの一例を図３に示す。図３は、なぞなぞ型のクイズ番組に対する想定アクセスデータを示したものである。
【００１３】
（参加登録）
利用者は、クイズ番組の放送直前に参加登録を行う。具体的には、まず、上記のようにしてダウンロードした端末用プログラムを、利用者端末１０上で起動する。端末用プログラムが起動されると、利用者端末１０の画面には、ニックネームの入力画面が表示されるので、利用者はニックネームの入力後、参加する旨の指示および入力した情報を送信する（Ｓ４）。受付サーバ３０では、参加申込およびニックネームを受け取ると、その申込者のＩＤおよびニックネームを参加者情報として登録する（Ｓ５）。続いて、受付サーバ３０は、正しく参加者登録された旨を利用者端末１０に送信する（Ｓ６）。
【００１４】
以上のようにして、プログラムおよび必要なデータをダウンロードし、参加登録を終えたら、番組開始前の準備は完了である。後は、利用者は、番組を見ながら、利用者端末１０に対して解答入力を行えば良い。ここで、本発明の分散処理の基本的な考え方について説明しておく。アクセス数の時間による変化の仕方は、質問・出題等の性質により異なってくるものである。例えば、クイズ番組であっても、なぞなぞ型は、一般に、出題直後は解答できる人が少なく、徐々に増えていく傾向がある。テスト型についても同様である。逆に早押し型は、一般に、出題直後に解答しようとする人が多く、遅れて解答する人は時間の経過に従って減っていく傾向がある。
【００１５】
ここで、時間の経過による想定アクセス数の変化の概略をグラフ化したものを図４（ａ）（ｂ）に示す。図４（ａ）は早押し型、図４（ｂ）はなぞなぞ型に対応するものである。想定アクセス数は、あくまでも想定したアクセス数であり、現実にアクセスしてきた数ではないが、過去の同様の番組における経験値から導き出したものであり、現実のアクセス数に似た傾向となるものである。そこで、本発明では、各利用者端末１０において、この想定アクセス数が多い時間帯に送信することを抑制し、全体として分散化を図ろうとするものである。
【００１６】
図４（ａ）（ｂ）に示した想定アクセス数を有する番組について、分散化を図った状態のアクセス数のグラフを図４（ｃ）（ｄ）に示す。図４（ｃ）は早押し型、図４（ｄ）はなぞなぞ型に対応するものである。早押し型の場合は、出題開始直後に、アクセスが多いため、図４（ｃ）に示すように、最初のアクセスを抑制し、後に分散させることになる。なぞなぞ型の場合は、出題開始直後に、アクセスが少ないため、図４（ｄ）に示すように、最初のアクセスは全て許容し、その後、上限までに抑制し、後に分散させることになる。
【００１７】
（解答の送信）
続いて、本発明に係るデータ分散方法の具体的な処理内容を、図５のフローチャートを用いて具体的に説明していく。利用者端末１０において、クイズ番組のタイムスケジュールに合わせて、時刻管理を行う。そして、利用者端末１０は、クイズ番組の開始時刻になると、利用者端末１０内の記憶領域からサーバ性能値Ｎを抽出する（Ｓ１１）。このサーバ性能値Ｎは、端末用プログラムをダウンロードする際に、同時に取得され、利用者端末１０内の所定の記憶領域に記録されたものである。
【００１８】
利用者端末１０は、タイムスケジュールにより、問題の解答開始時刻になると、経過時間ｔの測定を開始する（Ｓ１２）。利用者が、質問に対する解答を送信する指示を利用者端末１０に対して行うと、利用者端末１０は、送信アクションを検知する（Ｓ１３）。利用者端末１０は、送信アクションを検知すると、検知した時点における経過時間ｔで想定アクセスデータを参照し、想定アクセス数Ｘ（ｔ）を抽出する（Ｓ１４）。続いて、ｔ秒後にデータ送信を行おうとしているユーザの総数であるアクセストライ数Ｙ（ｔ）を算出する（Ｓ１５）。具体的には、上記想定アクセス数Ｘ（ｔ）およびアクセス待ち数Ｗ（ｔ−１）の和として、以下の〔数式１〕に従って算出される。
【００１９】
〔数式１〕
Ｙ（ｔ）＝Ｘ（ｔ）＋Ｗ（ｔ−１）
【００２０】
なお、Ｗ（ｔ）は、ｔ秒後の想定アクセス待ち数であり、以下の〔数式２〕に従った処理により算出されるものである。なお、Ｗ（０）＝０である。
【００２１】
〔数式２〕
Ｗ（ｔ）＝Ｗ（ｔ−１）＋Ｘ（ｔ）−（Ｎ−ｍ）
【００２２】
続いて、サーバ性能値Ｎと安全用マージンｍの差分値（Ｎ−ｍ）を、受付サーバ３０の受付許容数として算出し、アクセストライ数Ｙ（ｔ）が、受付許容数（Ｎ−ｍ）以上であるかどうかの比較判断を行う（Ｓ１６）。この安全用マージンｍは、端末用プログラム内部に記録されているものである。ここで、安全用マージンｍを用いて、受付許容数（Ｎ−ｍ）を算出するのは、サーバ性能値Ｎはあくまでも理想的な値であるため、必ずしもＮだけのアクセスに対応できるとは限らないからである。そして、Ｙ（ｔ）が（Ｎ−ｍ）未満と判断された場合は、データ送信を行う（Ｓ１７）。具体的には、上記Ｓ４において検知した指示された解答を、サーバに送信する処理を行う。すなわち、アクセストライ数Ｙ（ｔ）が（Ｎ−ｍ）未満である場合には、受付サーバ３０が全て受け付ける能力があると判断して、制限を行うことなく、利用者端末１０から送信を行うのである。
【００２３】
一方、Ｙ（ｔ）が（Ｎ−ｍ）以上と判断された場合は、１からＹ（ｔ）までの範囲において整数値の乱数Ｒａｎｄ（Ｙ（ｔ））を発生させ、このＲａｎｄ（Ｙ（ｔ））と（Ｎ−ｍ）の大小の比較判断を行う（Ｓ１８）。この結果、Ｒａｎｄ（Ｙ（ｔ））が（Ｎ−ｍ）以下と判断された場合は、データ送信を行う（Ｓ１７）。すなわち、アクセストライ数Ｙ（ｔ）が（Ｎ−ｍ）以上である場合には、受付サーバ３０が全てを受け付ける能力がないと判断して、一様の確率で発生される乱数を生成し、その乱数が（Ｎ−ｍ）以下であるものについてのみ、送信を行うのである。このような処理が、多数の利用者端末１０で同様に行われることになり、必ずしも、同時に送信される数が（Ｎ−ｍ）以下となることを保証するものではないが、乱数は、１からＹ（ｔ）までの範囲において一様の確率で発生されるため、ほとんどの場合、受付サーバ３０が同時に受け付けるアクセス数は（Ｎ−ｍ）以下になることが想定される。
【００２４】
一方、Ｒａｎｄ（Ｙ（ｔ））が（Ｎ−ｍ）より大きいと判断された場合は、ｔ秒後のアクセストライ数Ｙ（ｔ）から（Ｎ−ｍ）を減算した値を、ｔ秒後の想定アクセス待ち数Ｗ（ｔ）とする処理を行う（Ｓ１９）。すなわち、ここでは、この利用者端末１０からは送信は行わなかったが、他の（Ｎ−ｍ）台の利用者端末１０からは、送信が行われ、受付サーバ３０が受け付けたであろうと想定し、新たな想定アクセス待ち数Ｗ（ｔ）を算出しているのである。
【００２５】
その後、ｔを１加算し（Ｓ２０）、１秒経過した時点で、Ｓ１４に戻って、加算した経過時間ｔで想定アクセスデータを参照し、想定アクセス数Ｘ（ｔ）を抽出する。Ｓ１８、１９、Ｓ２０からＳ１４へのループは、Ｓ１７におけるデータ送信処理が行われるまで続けられる。
【図面の簡単な説明】
【００２６】
【図１】本発明に係る分散送信システムの一実施形態を示す構成図である。
【図２】利用者端末１０が端末用プログラム等を取得する場合のフローチャートである。
【図３】想定アクセスデータを示す図である。
【図４】アクセス数の経時変化の様子をグラフ化した図である。
【図５】本発明に係る分散送信システムの処理動作を示すフローチャートである。
【符号の説明】
【００２７】
１０ａ〜１０ｃ・・・利用者端末
２０・・・ネットワーク
３０・・・受付サーバ
【図１】
0004831297.tif 000002
【図２】
0004831297.tif 000003
【図３】
0004831297.tif 000004
【図４】
0004831297.tif 000005
【図５】
0004831297.tif 000006