(57)【要約】【課題】投票券発券装置が適切なサービスをより提供できるように、発売状況情報を配信するための技術を提供する。【解決手段】更新部１２は、ＰＣ５からの指示に従って、記憶部１１上のレース発売状況情報群１７、或いはレース出走表情報群１８を公営競技場単位で更新する。第１の配信部１３は、更新を契機に、更新された公営競技場単位の発売状況情報群をブロードキャストにより各投票券発払機２に送信する。第２の配信部１４は、ブロードキャストによる送信によって公営競技場単位の発売状況情報群の受信が確認できなかった投票券発払機２を対象に、公営競技場単位の発売状況情報群を個別に送信する。その送信は、何らかの要求の受信を契機に行われ、公営競技場単位の発売状況情報群の送信対象は、端末管理情報１９を用いて管理される。【選択図】図１
2016053926.tif 000002
【特許請求の範囲】
【請求項１】
公営競技の投票券の販売に係わる発売状況情報を送信すべき端末装置を認識する認識部と、
通信部を用いて、前記発売状況情報を各端末装置宛に送信させる第１の配信制御部と、
前記第１の配信制御部が前記発売状況情報を送信させた前記各端末装置からの応答を基に、前記認識部が認識する前記端末装置のなかから、前記発売状況情報の再送信の候補とする端末装置である候補端末装置を特定する第１の特定部と、
前記特定部が特定した候補端末装置のなかで前記発売状況情報を受信可能と推定する候補端末装置を再送信実行対象として特定する第２の特定部と、
前記第２の特定部が特定した再送信実行対象に、前記発売状況情報を送信するための制御を行う第２の配信制御部と、
を備えたことを特徴とする情報管理装置。
【請求項２】
前記第１の配信制御部は、前記発売状況情報が更新された場合に、更新後の前記発売状況情報を前記各端末装置宛に送信させ、
前記第２の特定部は、前記候補端末装置のなかで要求を行った候補端末装置を前記再送信実行対象として特定する、
ことを特徴とする請求項１記載の情報管理装置。
【請求項３】
前記第２の配信制御部は、前記通信部により、前記発売状況情報を前記再送信実行対象宛に送信させるか、或いは前記発売状況情報の版数を前記候補端末装置に送信し、前記候補端末装置の応答を基に、前記発売状況情報を前記再送信実行対象宛に送信させる、
ことを特徴とする請求項１、または２記載の情報管理装置。
【請求項４】
各端末装置への情報配信を管理する情報管理装置として用いられる情報処理装置に、
公営競技の投票券の販売に係わる発売状況情報を送信すべき端末装置を認識させ、
通信部を用いて、前記発売状況情報を各端末装置宛に送信させ、
前記発売状況情報を送信させた前記各端末装置からの応答を基に、認識された前記端末装置のなかから、前記発売状況情報の再送信の候補とする端末装置である候補端末装置を特定させ、
特定された前記候補端末装置のなかで前記発売状況情報を受信可能と推定する候補端末装置を再送信実行対象として特定させ、
特定された前記再送信実行対象に、前記発売状況情報を送信するための制御を行わせる、
ことを特徴とする情報管理方法。
【請求項５】
各端末装置への情報配信を管理する情報管理装置として用いられる情報処理装置に、
公営競技の投票券の販売に係わる発売状況情報を送信すべき端末装置を認識させ、
通信部を用いて、前記発売状況情報を各端末装置宛に送信させ、
前記発売状況情報を送信させた前記各端末装置からの応答を基に、認識された前記端末装置のなかから、前記発売状況情報の再送信の候補とする端末装置である候補端末装置を特定させ、
特定された前記候補端末装置のなかで前記発売状況情報を受信可能と推定する候補端末装置を再送信実行対象として特定させ、
特定された前記再送信実行対象に、前記発売状況情報を送信するための制御を行わせる、
処理を実行させる情報管理プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、公営競技の投票券を購入希望者に購入させるための技術に関する。
【背景技術】
【０００２】
競馬、競輪、競艇、オートレース等の公営競技では、希望者は、式別毎に、レース結果、つまり競技者（ここでは、競技者である騎手が乗馬する馬を含む）の着順を予想し、投票券を購入することができる。
【０００３】
公営競技場、及び投票所には、投票券を自動的に購入できるように、投票券発券装置（ここでは投票券発払装置を含む）が設置されている。その投票券発券装置は、購入希望者が挿入する投票カードを読み取り、その投票カードで指定された投票内容の投票券を発券する端末装置である。
【０００４】
公営競技の各レースでは、投票券の発売状況は、発売停止→発売中→発売締切→減算（取り消し）締切→確定（払戻中）、という流れで順次、推移する。そのため、購入希望者は、購入可能な期間内に投票券を購入しなければならない。投票券発券装置には、発売期間中に投票券を発券できるように、発売状況を表す情報（発売状況情報）が制御用情報としてホストコンピュータ等の情報管理装置から配信される。
【０００５】
現在、投票券発券装置の多くは、複数の公営競技場の投票券を発券できるようになっている。各公営競技場では、複数のレースが行われている。このことから、情報管理装置は、投票券発券装置が投票券を発券可能な公営競技場毎に、その公営競技場で行われる各レースの発売状況情報を送信している。
【０００６】
発売状況情報は、投票券の発売状況の推移に応じて更新される。投票券発券装置に適切にサービスを提供させるには、最新の発売状況情報に沿って投票券発券装置を動作させる必要がある。このことから、情報管理装置は、何れかの発売状況情報の更新により、公営競技場単位で全ての発売状況情報（以降「全発売状況情報」と表記）を送信している。全発売状況情報の送信には、通常、ブロードキャストが用いられる。
【０００７】
全発売状況情報の送信は、ネットワークを介して行われる。投票券発券装置は、ネットワーク上に、或いは投票券発券装置自身に発生した一時的な障害等により、全発売状況情報を受信できない可能性がある。投票券発券装置のなかで全発売状況情報を受信できなかった投票券発券装置は、最新の発売状況情報に沿って動作しないことから、適切なサービスを提供できない。
【０００８】
全発売状況情報を受信できなかった投票券発券装置では、例えば実際には発売が終了したレースの投票券が購入可能となっている場合がある。そのレースの投票券の購入を希望する利用者は、そのレースの投票券を購入することはできない。このため、利用者にとっては、購入できないレースの投票券の購入のために行った操作が無駄になり、その操作を行った時間を浪費することになる。
【０００９】
また、全発売状況情報を受信できなかった投票券発券装置では、発売が開始したレースが発売停止のままとなる。そのため、利用者は、本来、購入できるレースの投票券を購入することができない。
【００１０】
このように、全発売状況情報を受信できない投票券発券装置は、適切なサービスを提供できなくなる。その状態は、次に全発売状況情報を受信するまで継続する。全発売状況情報は、更新を契機に配信されることから、何らかのレースの発売状況が変化するまで送信されない。発売状況が変化するまでには或る程度の時間が必要であり、その時間、投票券発券装置が適切なサービスを提供できなくなるのは、利用者の満足度を大きく低下させる原因となりうることから、非常に望ましくない。このことを考慮すれば、情報管理装置には、投票券発券装置が適切なサービスをより提供できるように、全発売状況情報（発売状況情報）の配信を行わせることが重要である。
【先行技術文献】
【特許文献】
【００１１】
【特許文献１】特開２０１１−１５８９３３号公報
【特許文献２】特開２００６−０４８５７１号公報
【発明の概要】
【発明が解決しようとする課題】
【００１２】
１側面では、本発明は、投票券発券装置が適切なサービスをより提供できるように、発売状況情報を配信するための技術を提供することを目的とする。
【課題を解決するための手段】
【００１３】
本発明を適用した１装置は、公営競技の投票券の販売に係わる発売状況情報を送信すべき端末装置を認識する認識部と、通信部を用いて、発売状況情報を各端末装置宛に送信させる第１の配信制御部と、第１の配信制御部が発売状況情報を送信させた各端末装置からの応答を基に、認識部が認識する端末装置のなかから、発売状況情報の再送信の候補とする端末装置である候補端末装置を特定する第１の特定部と、特定部が特定した候補端末装置のなかで発売状況情報を受信可能と推定する候補端末装置を再送信実行対象として特定する第２の特定部と、第２の特定部が特定した再送信実行対象に、発売状況情報を送信するための制御を行う第２の配信制御部と、を備えている。
【発明の効果】
【００１４】
本発明を適用した場合には、投票券発券装置が適切なサービスをより提供できるように、発売状況情報を配信することができる。
【図面の簡単な説明】
【００１５】
【図１】本実施形態による情報管理装置を用いて構築された投票券発売・払戻システムの構成例を説明する図である。
【図２】ホストとして用いることが可能なコンピュータのハードウェア構成例を説明する図である。
【図３】投票券発払機のハードウェア構成例を説明する図である。
【図４】配信される情報を用いて投票券発払機がディスプレイに表示させる画面例を表す図である。
【図５】端末管理情報の構成例を説明する図である。
【図６】場単位発売状況情報の配信のためのホスト、及び投票券発払機の動作の流れの例を表すシーケンス図である。
【図７】更新配信処理のフローチャートである。
【図８】個別配信処理のフローチャートである。
【図９】発売状況取得処理のフローチャートである。
【図１０】版数通知受信処理のフローチャートである。
【図１１】場単位発売状況情報の配信のためのホスト、及び投票券発払機の動作の流れの例を表す他のシーケンス図である。
【発明を実施するための形態】
【００１６】
以下、本発明の実施形態について、図面を参照しながら詳細に説明する。
図１は、本実施形態による情報管理装置を用いて構築された投票券発売・払戻システムの構成例を説明する図である。
【００１７】
この投票券発売・払戻システムは、公営競技場、或いは投票所に来場した人が投票券の購入、及び払い戻しを行えるように構築されたシステムである。図１に表すように、投票券発売・払戻システムは、ホストコンピュータ（以降「ホスト」と略記）１と複数台の投票券発払機２をネットワーク３により接続し、ホスト１とＰＣ（Personal Computer）５をネットワーク４により接続した構成となっている。
【００１８】
投票券発払機２は、利用者の操作により、投票券の発券、及び払い戻しを行える端末装置である。図１では、便宜的に投票券発払機２のみを表しているが、投票券発売・払戻システムは、投票券発払機２の代わりに、投票券の発券のみを行う投票券発券機、及び払い戻しのみを行う投票券払戻機を含む構成であっても良い。或いは投票券発払機２に加えて、投票券発券機、及び投票券払戻機のうちの少なくとも一方を含む構成であっても良い。
【００１９】
ホスト１は、投票券発払機２からの要求により、投票券の発売、或いは払い戻しのための処理を行う装置である。ホスト１は、投票券の発売、或いは払い戻し等のために、公営競技場単位で発売状況情報を各投票券発払機２に配信する。本実施形態による情報管理装置は、ホスト１上に実現されている。
【００２０】
公営競技場単位の発売状況情報（以降「場単位発売状況情報」と表記）は、公営競技場におけるレースの進行に応じて順次、更新される。レースの進行は、予め作成された予定に沿って行われる。しかし、状況により、予定は変更される場合がある。このことから、場単位発売状況情報の更新は、手動で行うようになっている。ＰＣ５は、場単位発売状況情報の更新に用いられる。場単位発売状況情報の更新は、管理用の作業であることから、ホスト１とＰＣ５間は管理用のネットワーク４により接続されている。
【００２１】
ホスト１は、図１に表すように、機能構成として、記憶部１１、更新部１２、第１の配信部１３、第２の配信部１４、及び投票・払戻処理部１５を備える。
【００２２】
記憶部１１には、レース発売状況情報群１７、レース出走表情報群１８、及び端末管理情報１９が保存される。ここでは、情報管理装置が対象とする情報（データ）のみを表している。
【００２３】
レース発売状況情報群１７は、複数の場単位発売状況情報を含む。各場単位発売状況情報は、例えば公営競技場を表す場名コード、版数、及び各レースの発売状況情報を含む。各レースの発売状況情報は、レース番号、及び発売状況フラグを含む。発売状況フラグは、例えば発売停止、発売中、発売締切、減算締切、及び確定（払戻中）のうちの１つを表すフラグである。
【００２４】
各公営競技場では、レース毎に、そのレースの競技者（ここでは、騎手が乗馬する馬を含む意味で用いている）が管理される。レース出走表情報群１８は、公営競技場毎に、その公営競技場で行われる各レースの競技者の状況を表す情報群である。１つの公営競技場の出走表情報は、以降「場単位出走表情報」と表記する。
【００２５】
場単位出走表情報は、例えば公営競技場を表す場名コード、及びレース毎の各競技者の状況フラグを含む。各競技者の状況フラグは、例えば登録あり、登録なし、及び取り消しのうちの１つを表すフラグである。
【００２６】
上記レース発売状況情報群１７、及び上記レース出走表情報群１８の各構成は、上記のようなものに限定されない。例えば各レースの発売状況情報は、場名コード、レース番号、及び発売状況フラグを含む構成であっても良い。その構成例に版数を含ませていないのは、版数がなくとも、発売状況フラグから更新の有無を特定できるからである。
【００２７】
上記レース発売状況情報群１７、及び上記レース出走表情報群１８は、ホスト１が各投票券発払機２に配信する対象とする情報である。ホスト１は、端末管理情報１９を用いて、情報の配信対象とする投票券発払機２を管理する。
【００２８】
図５は、端末管理情報の構成例を説明する図である。図５に表すように、端末管理情報１９は、各エントリ（レコード）に、端末番号、及び状態フラグの各情報が格納されるテーブルである。
【００２９】
端末番号は、各投票券発払機２に識別情報として割り当てられた情報である。各投票券発払機２は、ネットワーク３に電文（メッセージ）を送信する場合、そのメッセージ中に端末番号を格納するようになっている。
【００３０】
状態フラグは、対応する投票券発払機２の状態を表す情報である。図５に表す「０」〜「２」の各値は、それぞれ以下のような状態を表している。
【００３１】
０は、ホスト１が未認識であることを表している。投票券発払機２が存在しない、投票券発払機２が故障している、或いは電源が投入されていないような場合、状態フラグは０となる。
【００３２】
１は、ホスト１が認識していることを表している。ここでは、投票券発払機２が正常に動作していると見なされる場合のみ、状態フラグは１となる。
【００３３】
２は、ホスト１が一旦は認識しながら、最後に配信した情報を正常に受信したか否かが不明なことを表している。配信した情報の受信を表す応答を確認できなかった投票券発払機２の状態フラグは２となる。
【００３４】
発売状況情報を公営競技場単位で送信する場合、投票券発払機２に送信すべき場単位発売状況情報を個別に特定できるように、状態フラグは公営競技場毎に格納しても良い。ここでは説明上、便宜的に、特に断らない限り、場単位発売状況情報は１つのみを想定する。
【００３５】
配信した情報を受信できなかった投票券発払機２では、適切なサービスを提供できない可能性がある。投票券を購入可能なレースで投票券を購入できない、購入できない投票券が購入可能となっている、確定しているレースで払い戻しができない、といったことが発生する。そのように適切なサービスを提供できない期間はより短くするのが望ましい。このことから、本実施形態では、情報を受信したことを確認できなかった投票券発払機２を、その情報の再送信の対象としている。再送信の対象にすることにより、次に情報を配信する状況となる前であっても、投票券発払機２が情報を受信可能であると確認（推定）できた場合に、情報を再送信するようにしている。それにより、投票券発払機２が適切なサービスを提供可能な期間がより長くなることから、投票券発払機２のような端末装置が提供するサービスの質をより向上させることができる。以降、情報の再送信の対象とする投票券発払機２は「リカバリ対象」とも表記する。
【００３６】
ホスト１が配信対象とする情報は、上記のように、レース発売状況情報群１７、及びレース出走表情報群１８である。レース発売状況情報群１７、及びレース出走表情報群１８は、公営競技場単位で情報が送信される。配信される頻度は、通常、レース発売状況情報群１７のほうが非常に大きい。このことから、以降、便宜的に、ホスト１が配信対象とする情報として、レース発売状況情報群１７、つまり場単位発売状況情報のみを想定する。
【００３７】
第１の配信部１２は、更新部１２によって更新された場単位発売状況情報を各投票券発払機２に送信する。この第１の配信部１２は、各投票券発払機２が場単位発売状況情報を受信することで返信する応答を監視し、状態フラグが１の投票券発払機２のなかで応答を確認できない投票券発払機２の状態フラグを２に変更し、その投票券発払機２をリカバリ対象とする。
【００３８】
リカバリ対象のなかで正常に動作する、或いは正常に動作するようになった投票券発払機２は、利用者による投票券の購入指示、或いは払い戻し指示等により、ホスト１に何らかの要求を行う。少なくとも一部の機能（発券機能、或いは払戻機能、等）が正常に動作していなければ、投票券発払機２が要求をホスト１に対して行うことは考え難い。このことから、本実施形態では、その要求が行われたことを、投票券発払機２が正常に動作している可能性を表しているとして、投票券発払機２の正常動作が確認されたことと見なし、場単位発売状況情報を送信するようにしている。
【００３９】
投票券発払機２の利用者は、より人の少ない投票券発払機２を利用しようとするのが一般的である。また、利用者は、正常に動作しない投票券発払機２を利用しようとしないのも一般的である。そのため、正常に動作する投票券発払機２は、配信された場単位発売状況情報を受信できなくとも、直ぐに何らかの要求をホスト１に対して行うと期待できる。従って、ホスト１への要求を投票券発払機２の正常動作の確認と見なす場合、場単位発売状況情報を受信できなかった投票券発払機２のなかで正常に動作する投票券発払機２の確認を迅速に行えると期待できる。その確認のためのメッセージをホスト１が送信しなくとも良いことから、ネットワーク３上のトラフィック量の増大を回避、或いは抑制させることができる。これらのことから、ホスト１への要求を投票券発払機２の正常動作の確認と見なすことは、ネットワーク３上のトラフィック量の増大を回避、或いは抑制させつつ、投票券発払機２が提供するサービスの質をより向上させるうえで有用である。
【００４０】
図２は、上記ホストとして用いることが可能なコンピュータのハードウェア構成例を説明する図である。図３は、上記投票券発払機のハードウェア構成例を説明する図である。次に、図２、及び図３を参照し、ホスト１、及び投票券発払機２の各ハードウェア構成例について詳細に説明する。
【００４１】
上記ホスト１として用いることが可能なコンピュータ（情報処理装置）は、例えば図２に表すように、ＣＰＵ（Central Processing Unit）１０２、メモリ１０４、入力装置１０６、出力装置１０８、外部記憶装置１１０、媒体駆動装置１１２、及び２つのネットワーク接続装置１１６、及び１１８を有し、これらがシステムバス１２０によって互いに接続された構成となっている。
【００４２】
ＣＰＵ１０２は、当該コンピュータ全体の制御を行う。図２には一つのみ表しているが、ＣＰＵ１０２はコンピュータに複数、搭載されていても良い。
【００４３】
メモリ１０４は、プログラム実行、データ更新等の際に、外部記憶装置１１０（あるいは可搬型の記録媒体１３０）に記憶されているプログラムあるいはデータを一時的に格納するＲＡＭ等の半導体メモリである。ＣＰＵ１０２は、プログラムをメモリ１０４に読み出して実行することにより、全体の制御を行う。
【００４４】
入力装置１０６は、例えば、キーボード等のオペレータが操作する操作装置、及びその操作への操作を検出する検出装置を備えたものか、或いは他のコンピュータである端末装置（例えばコンソール）と接続するためのインタフェースである。前者の場合、入力装置１０６は、操作装置へのオペレータの操作を検出し、その検出結果をＣＰＵ１０２に通知する。後者の場合、入力装置１０６は、端末装置を介したオペレータの指示を受信し、その指示内容をＣＰＵ１０２に通知する。ここでは便宜的に、入力装置１０６は前者と想定する。
【００４５】
出力装置１０８は、例えば表示装置に画像を表示させる表示制御装置である。外部記憶装置１１０は、例えばフラッシュメモリ、或いはハードディスク装置等の大容量の記憶装置である。主に各種データやプログラムの保存に用いられる。
【００４６】
媒体駆動装置１１２は、メモリカード等の可搬型の記録媒体１３０にアクセスするものである。ネットワーク接続装置１１６、及び１１８は、例えばネットワークを介した不図示の外部装置との通信を可能とさせるものである。例えばネットワーク接続装置１１６はネットワーク３と接続され、ネットワーク接続装置１１８はネットワーク４と接続される。
【００４７】
図１に表す記憶部１１は、例えば外部記憶装置１１０であるか、或いはその外部記憶装置１１０、及びメモリ１０４によって実現される。更新部１２、第１の配信部１３、及び第２の配信部１４が１つのアプリケーション・プログラム（以降「情報配信アプリケーション」と表記する）によって実現される機能であり、その情報配信アプリケーションが外部記憶装置１１０に格納されていると想定する。また、ネットワーク接続装置１１６はネットワーク３と接続され、ネットワーク接続装置１１８はネットワーク４と接続されると想定する。そのような想定では、更新部１２は、ＣＰＵ１０２、メモリ１０４、外部記憶装置１１０、ネットワーク接続装置１１６、及びバス１２０によって実現される。また、第１の配信部１３、及び第２の配信部１４は、共に、ＣＰＵ１０２、メモリ１０４、外部記憶装置１１０、ネットワーク接続装置１１８、及びバス１２０によって実現される。
【００４８】
次に、投票券発払機２のハードウェア構成例について、図３を参照して詳細に説明する。
【００４９】
投票券発払機２は、図３に表すように、制御部２１、ディスプレイ２２、管理者用ディスプレイ２３、タッチパネル２４、管理者用タッチパネル２５、投票カード読取ユニット２６、紙幣還流ユニット２７、硬貨還流ユニット２８、投票券印刷ユニット２９、及び払戻投票券読取ユニット３０を備えている。
【００５０】
ディスプレイ２２は、利用者に対し、操作案内、レース案内、投票カードの投票内容等の情報の表示に用いられる。
【００５１】
管理者用ディスプレイ２３は、メンテナンス等の際に、作業員に必要な情報の表示に用いられる。管理者用ディスプレイ２３は、例えば投票券発払機２の裏側に設けられている。
【００５２】
タッチパネル２４は、ディスプレイ２２の上方に配置された入力装置である。管理者用タッチパネル２５は、管理者用ディスプレイ２３の上方に配置された入力装置である。
【００５３】
投票カード読取ユニット２６は、利用者が挿入した投票カード束から投票カードを１枚ずつ繰り出して搬送し、搬送中に投票カードに記入された投票内容を読み取るための装置である。
【００５４】
紙幣還流ユニット２７は、紙幣の入金、及び出金を可能にするための装置である。硬貨還流ユニット２８は、硬貨の入金、及び出金を可能にするための装置である。これら紙幣還流ユニット２７、及び硬貨還流ユニット２８により、利用者は現金を用いた投票券の購入、及び払い戻しを行うことができる。
【００５５】
投票券印刷ユニット２９は、未印刷の投票券に必要な内容を印刷して、投票券を発券するための装置である。
【００５６】
払戻投票券読取ユニット３０は、利用者が挿入した投票券の投票内容を読み取るための装置である。
【００５７】
制御部２１は、投票券発払機２全体を制御する制御装置である。図３に表すように、ＣＰＵ２１１、ＲＡＭ（Random Access Memory）２１２、ＨＤＤ（Hard Disk Drive）２１３、通信インタフェース２１４、グラフィック処理ユニット２１５、入出力インタフェース２１６を備え、各々がバス２１７に接続されている。なお、制御部２１は、コンピュータの一例に相当する。
【００５８】
ＣＰＵ２１１は、制御部２１を制御して、投票券発券機２全体を制御する。ＲＡＭ２
１２は、ＣＰＵ２１１が実行するＯＳ（Operating System）、及びアプリケーション・プログラム等の少なくとも一部の一時的な格納に用いられる。また、ＲＡＭ２１２は、ＣＰＵ２１１による処理に必要な各種データ（例えば投票内容のデータ等）の一時的な格納に用いられる。ＨＤＤ２１３には、ＯＳやアプリケーション・プログラム、各種データ等が格納される。
【００５９】
通信インタフェース２１４は、ネットワーク３に接続され、ネットワーク３を介したホスト１との通信を可能にさせる。投票券の発券、及び払い戻し時には、ネットワーク３を介したホスト１との通信が行われる。
【００６０】
なお、ＣＰＵ２１１に実行させるプログラムは、ネットワーク３を介して外部装置から受信しても良い。また、入出力インタフェース２１６が可搬型記録媒体３１にアクセス可能な駆動装置に接続可能であった場合、プログラムは、入出力インタフェース２１６を介して取得するようにしても良い。このようなこともあり、プログラムの格納先、及び取得方法等は特に限定されない。
【００６１】
グラフィック処理ユニット２１５は、ＣＰＵ２１１の指示に従い、ディスプレイ２２、或いは管理者用ディスプレイ２３に表示させる画面（画像データ）を生成し、生成した画面をディスプレイ２２、或いは管理者用ディスプレイ２３に出力する。それにより、ＣＰＵ２１１は、必要な情報をディスプレイ２２、及び管理者用ディスプレイ２３に表示させる。
【００６２】
入出力インタフェース２１６は、双方向のデータの入出力のためのインタフェースである。入出力インタフェース２１６には、タッチパネル２４、管理者用タッチパネル２５、投票カード読取ユニット２６、紙幣還流ユニット２７、硬貨還流ユニット２８、投票券印刷ユニット２９、及び投票券読取ユニット３０が接続されている。それにより、ＣＰＵ２１１は、これら各ユニット２４〜３０への指示、及び各ユニット２４〜３０の状態の確認、及び必要なデータの取得を、入出力インタフェース２１６を介して行う。
【００６３】
図４は、配信される情報を用いて投票券発払機がディスプレイに表示させる画面例を表す図である。
【００６４】
図４に表す画面４０は、ホスト１から配信されたレース発売状況情報群１７、及びレース出走表情報群１８を用いて作成・表示される、各公営競技場で投票券が購入可能なレース、払い戻しが可能なレース等を表すインフォメーション画面である。画面４０には、公営競技場毎に、投票券が購入可能なレース、及び払い戻しが可能なレースの情報が配置されるレース状況表示エリア４１、及び取り消しとなった競技者についての情報が配置される出走関連表示エリア４２が設けられている。
【００６５】
レース状況表示エリア４１内に表記の「Ａ場」「Ｂ場」「Ｃ場」「Ｄ場」及び「Ｅ場」は、それぞれ公営競技場を表している。「３月１４日」は、競技が行われる月日を表している。「１」〜「１２」は、それぞれレース番号を表している。レース状況表示エリア４１内に表示された情報は、全ての公営競技場の全てのレースで投票券を購入できることを表している。
【００６６】
出走関連表示エリア４２に表記の「Ｅ場  ３月１４日    １２Ｒ  ４番  ５番  ６番」は、３月１４日にＥ場の公営競技場で開催される１２レースで４〜６番の競技者が欠場することを表している。
【００６７】
投票券の購入希望者は、投票内容を決定次第、投票内容を決定したレースの投票券を購入することを考えるのが一般的である。話題となっている、或いは人気のある競技者が出場するレースでは、投票券の購入希望者が多くなり、投票券の購入のための時間的余裕は小さくなることが多々ある。このこともあり、投票券発払機２では、投票券が購入可能となったレースで直ちに投票券を購入希望者が購入できるようにする必要がある。たとえ場単位発売状況情報を受信できず、投票券が購入可能となった時点で投票券を購入できない不適切な状態となっても、その状態となっている時間は、より短くする必要がある。投票券の発売が締め切りとなった時点でも投票券の購入を可能とさせる不適切な状態では、購入希望者は、誤って購入できない投票券を購入しようとする可能性がある。購入できない投票券を購入しようと操作を行う時間は、購入希望者にとっては時間の浪費であり、その購入希望者が他に購入を希望している投票券を購入できなくする可能性を生じさせる。本実施形態では、不適切な状態となっている時間をより短くし、投票券発払機２が適切に動作する状態を最大化させることができる。
【００６８】
図６は、場単位発売状況情報の配信のためのホスト、及び投票券発払機の動作の流れの例を表すシーケンス図である。次に、図６を参照し、場単位発売状況情報の配信に着目し、ホスト１、及び投票券発払機（図６中「端末」と表記）２の動作について詳細に説明する。ここでは、投票券発払機２として、リカバリ対象となる１台の投票券発払機２のみを表している。また、理解を容易とするために、場単位発売状況情報を更新させる発売状況変化、ホスト１側で管理する場単位発売状況情報の版数（図６中「発売状況版数」と表記）、及び投票券発払機２側で認識している場単位発売状況情報の版数を併せて表している。場単位発売状況情報はＡ場のもののみを想定している。場単位発売状況情報の版数の初期値は、ホスト１、及び投票券発払機２共に０と想定している。
【００６９】
投票券発払機２は、起動後、ホスト１に対し、場単位発売状況情報を取得するための電文を送信する（Ｓ１）。その電文には、例えば版数の確認を望む場単位発売状況情報の公営競技場を表す場名コード等も格納される。
【００７０】
照会のための電文を受信したホスト１は、電文が指定する場単位発売状況情報とその版数を格納した応答を投票券発払機２に送信する（Ｓ２）。応答を送信した投票券発払機２の状態フラグの値が１でない場合、状態フラグを１に更新する。
【００７１】
図９は、起動直後の投票券発払機が実行する発売状況取得処理のフローチャートである。上記版数の確認は、投票券発払機２が版数確認処理を実行することで実現される。ここで図９を参照し、発売状況取得確認処理について詳細に説明する。ここでは、処理を実行する主体として、ＣＰＵ２１１を想定する。
【００７２】
先ず、ＣＰＵ２１１は、Ａ場の場単位発売状況情報の版数を管理するための変数（図９中「受信済Ａ場発売状況版数」と表記）に、初期値として０を設定する（ＳＢ１）。次にＣＰＵ２１１は、Ａ場の場単位発売状況情報を取得する照会のための電文をホスト１に送信する（ＳＢ２）。その後はＳＢ３に移行する。
【００７３】
ＳＢ３では、ＣＰＵ２１１は、ホスト１からの応答を受信するのを待って、受信した発売状況照会応答中の発売状況を記録するとともに、発売状況照会応答中の版数を受信済Ａ場発売状況版数に設定する。その後、発売状況取得処理が終了する。
【００７４】
図６の説明に戻る。
Ａ場の全レースの投票券の発売を開始する状況変化が発生すると、場単位発売状況情報が更新される。場単位発売状況情報中の版数は０から１に更新される。ホスト１は、更新により、更新後の場単位発売状況情報をブロードキャストし、各投票券発払機２に最新の場単位発売状況情報と版数を通知する（Ｓ３）。
【００７５】
場単位発売状況情報を受信した投票券発払機２は、場単位発売状況情報を正常に受信した旨を表す応答を返信する（Ｓ４）。
【００７６】
正常受信を表す応答を受信したホスト１は、応答を送信した投票券発払機２の状態フラグを確認し、状態フラグの値が１でなければ１に更新する。それにより、配信した場単位発売状況情報を正常に受信したことが確認できた投票券発払機２は、リカバリ対象から除外される。
【００７７】
Ａ場の全レースの投票券の発売が開始された後、１レースの投票券の発売が締め切られる状況変化が発生した場合、再度、場単位発売状況情報が更新される。場単位発売状況情報中の版数は１から２に更新される。ホスト１は、更新により、更新後の場単位発売状況情報をブロードキャストし、各投票券発払機２に最新の場単位発売状況情報と版数を通知する（Ｓ５）。
【００７８】
ネットワーク３上の障害、或いは自身の障害により、場単位発売状況情報を受信できなかった投票券発払機２は、応答をホスト１に返信しない。ホスト１は、例えば状態フラグが１となっている全ての投票券発払機２から応答を受信できなかった場合、予め定めた最大回数を上限に、場単位発売状況情報の再度のブロードキャスト（リトライ）を繰り返し行う（Ｓ６）。ブロードキャストの繰り返し時に応答を受信できなかった投票券発払機２の状態フラグは２とされる。状態フラグが２の投票券発払機２のなかで応答を受信した投票券発払機２の状態フラグは１に更新される。
【００７９】
応答を送信しなかった投票券発払機２は、投票券の発券が可能な状態であれば、利用者の操作により、投票券の発券のための要求をホスト１に対して送信する（Ｓ７）。
【００８０】
要求を受信したホスト１は、要求を送信した投票券発払機２の状態フラグを確認する。それにより、状態フラグが２であることを確認した場合、ホスト１は、最新の場単位発売状況情報を投票券発払機２宛に送信する（Ｓ８）。
【００８１】
場単位発売状況情報を受信できた投票券発払機２は、正常受信を表す応答をホスト１に送信する（Ｓ９）。それにより、ホスト１は、応答を送信した投票券発払機２の状態フラグを２から１に更新し、投票券発払機２をリカバリ対象から除外する。
【００８２】
図７は、更新配信処理のフローチャートである。この更新配信処理は、場単位発売状況情報の更新、及び更新された場単位発売状況情報の配信のために実行される処理である。図１に表す更新部１２、及び第１の配信部１３は、この更新配信処理をＣＰＵ１０２が実行することで実現される。場単位発売状況情報のＰＣ５からの更新指示に対応するために、この更新配信処理は、起動後に常駐させるサブプログラムによって実現される。次に図７を参照し、この更新配信処理について詳細に説明する。ここでは、処理を実行する主体としてＣＰＵ１０２を想定する。
【００８３】
先ず、ＣＰＵ１０２は、変数であるＡ場発売状況版数に０を設定する（ＳＡ１）。次にＣＰＵ１０２は、ＰＣ５から、レース進行に対応する操作を要求するコマンドを受信するのを待つ（ＳＡ２）。そのコマンドをネットワーク接続装置１１８が受信した場合、ＳＡ２の判定はＹ（ＹＥＳ）となってＳＡ３に移行する。ＳＡ２の判定処理は、そのコマンドを受信するまでの間、つまりＳＡ２の判定がＮ（ＮＯ）となる間、繰り返し実行される。
【００８４】
ＳＡ３では、ＣＰＵ１０２は、Ａ場発売状況版数をインクリメントし、インクリメント後のＡ場発売状況版数の値に応じて、場単位発売状況情報を更新する。その更新は、通常、版数、及び１レース以上の発売状況フラグを対象に行われる。
【００８５】
次にＣＰＵ１０２は、場単位発売状況情報の配信のためのリトライを行った回数を計数するための変数である送信リトライカウンタに０を設定する（ＳＡ４）。その後はＳＡ５に移行する。
【００８６】
ＳＡ５では、ＣＰＵ１０２は、ネットワーク接続装置１０８を介して、更新後の場単位発売状況情報をブロードキャストする。次に、ＣＰＵ１０２は、ブロードキャストを行ってから経過した時間を計時するための応答監視タイマを起動させる（ＳＡ６）。応答の監視は、最大、その応答監視タイマが所定の最大時間を計時するまで行われる。
【００８７】
応答監視タイマを起動させた後、ＣＰＵ１０２は、例えば状態フラグが１となっている投票券発払機２全台から応答を受信したか否か判定する（ＳＡ７）。状態フラグが１となっている全ての投票券発払機２から応答を受信した場合、ＳＡ７の判定はＹとなってＳＡ１１に移行する。状態フラグが１となっている投票券発払機２のなかで応答を受信していない投票券発払機２が存在する場合、ＳＡ７の判定はＮとなってＳＡ８に移行する。
【００８８】
ＳＡ８では、ＣＰＵ１０２は、応答監視がタイムアウトしたか否か判定する。応答監視タイマが計時した時間が最大時間に達した場合、ＳＡ８の判定はＹとなってＳＡ９に移行する。その応答監視タイマが計時した時間が最大時間より小さい場合、ＳＡ８の判定はＮとなってＳＡ７に戻る。それにより、応答監視タイマが最大時間を計時するまで、各投票券発払機２から送信される応答が監視される。
【００８９】
ＳＡ９では、ＣＰＵ１０２は、送信リトライカウンタの値をインクリメントする。次に、ＣＰＵ１０２は、送信がリトライアウトしたか否か判定する（ＳＡ１０）。送信リトライカウンタの値が上記最大回数と一致する場合、最大回数のリトライを行ったことから、ＳＡ１０の判定はＹとなってＳＡ１１に移行する。送信リトライカウンタの値が上記最大回数未満であった場合、ＳＡ１０の判定はＮとなってＳＡ５に戻る。それにより、再度、リトライが行われる。
【００９０】
ＳＡ１１では、ＣＰＵ１０２は、応答を受信できなかった全ての投票券発払機２の状態フラグを２にする。そのようにして端末管理情報１９を更新した後、ＳＡ２に戻り、ＰＣ５からの再度のコマンドの送信を待つ。
【００９１】
図８は、個別配信処理のフローチャートである。個別配信処理は、状態フラグが２となっている投票券発払機２を対象に、最新の場単位発売状況情報を送信するための処理であり、投票券発払機２からの電文の受信を契機に実行される。図１に表す第２の配信部１４は、個別配信処理をＣＰＵ１０２が実行することで実現される。次に、図８を参照し、個別配信処理について詳細に説明する。
【００９２】
図８では、端末番号がｎ番の投票券発払機２からの電文の受信を想定し、処理内容を表記している。このことから、ここでは、端末番号がｎ番の投票券発払機２から電文を受信したとの想定で説明を行うこととする。場単位発売状況情報のブロードキャストによる投票券発払機２からの応答（電文）は、更新配信処理によって処理される。このことから、ここで対象となる電文は、その応答を除く電文である。通常、何らかの要求のための電文である。
【００９３】
先ず、ＣＰＵ１０２は、ｎ番の投票券発払機２が、状態フラグが２の端末か否か判定する（ＳＡ３１）。状態フラグが２でなかった場合、つまり、状態フラグが１であった場合、ＳＡ３１の判定はＮとなってＳＡ３２に移行する。状態フラグが２であった場合、ＳＡ３１の判定はＹとなってＳＡ３３に移行する。
【００９４】
ＳＡ３２では、ＣＰＵ１０２は、受信した電文を処理し、電文に応じた応答を送信する。その後、個別配信処理が終了する。
【００９５】
ＳＡ３２で処理される電文としては、場単位発売状況情報の版数を確認する照会のための電文、投票券の発券のための電文、及び払い戻しのための電文、等が含まれる。このことから、投票・払戻処理部１５も、個別配信処理をＣＰＵ１０２が実行することで実現される。
【００９６】
ＳＡ３２のような処理は、ＳＡ３３に移行する前に、或いはＳＡ３３以降で実行される。しかし、ここでは、理解を容易とするために、ＳＡ３１のＹの判定以降に実行されるＳＡ３２のような処理は省略させている。
【００９７】
ＳＡ３３では、ＣＰＵ１０２は、場単位発売状況情報の個別的な配信のためのリトライを行った回数を計数するための変数である送信リトライカウンタに０を設定する。その後、ＣＰＵ１０２は、ネットワーク接続装置１０８を介して、最新の場単位発売状況情報をｎ番の投票券発払機２宛に送信する。送信後、ＣＰＵ１０２は、送信してから経過した時間を計時するための応答監視タイマを起動させる（ＳＡ３５）。
【００９８】
応答監視タイマを起動させた後、ＣＰＵ１０２は、場単位発売状況情報を送信した投票券発払機２から応答を受信したか否か判定する（ＳＡ３６）。投票券発払機２から応答を受信した場合、ＳＡ３６の判定はＹとなってＳＡ３８に移行する。投票券発払機２から応答を受信していない場合、ＳＡ３６の判定はＮとなってＳＡ３７に移行する。
【００９９】
ＳＡ３７では、ＣＰＵ１０２は、応答監視がタイムアウトしたか否か判定する。応答監視タイマが計時した時間が最大時間に達した場合、ＳＡ３７の判定はＹとなってＳＡ３９に移行する。応答監視タイマが計時した時間が最大時間より小さい場合、ＳＡ３３７の判定はＮとなってＳＡ３６に戻る。以上により、応答監視タイマが最大時間を計時するまで、場単位発売状況情報を送信した投票券発払機２からの応答が監視される。
【０１００】
ＳＡ３８では、ＣＰＵ１０２は、応答を受信した投票券発払機２の状態フラグを２から１に更新する。その後、この個別配信処理が終了する。
【０１０１】
ＳＡ３９では、ＣＰＵ１０２は、送信リトライカウンタの値をインクリメントする。次に、ＣＰＵ１０２は、送信がリトライアウトしたか否か判定する（ＳＡ４０）。送信リトライカウンタの値が上記最大回数と一致する場合、その最大回数の場単位発売状況情報の送信を行ったことから、ＳＡ４０の判定はＹとなり、ここでこの個別配信処理が終了する。送信リトライカウンタの値が上記最大回数未満であった場合、ＳＡ４０の判定はＮとなって上記ＳＡ３４に戻る。それにより、再度、場単位発売状況情報の送信が行われる。
【０１０２】
なお、本実施形態では、状態フラグが２となっている投票券発払機２から何らかの要求のための電文を受信した場合、送信すべき場単位発売状況情報を直ちに送信しているが、場単位発売状況情報を直ちに送信させなくとも良い。例えば電文を受信した投票券発払機２に対し、全場分の発売状況情報の版数を通知し、場単位発売状況情報の照会の必要性を投票券発払機２に判定させるようにしても良い。そのようにした場合、不要な場単位発売状況情報の送信を回避させられることから、ネットワーク３上のトラフィック量の増大をより抑制させることができる。また、場ごとの版数条件の判定を投票券発払機２が行うため、ホスト１が場ごとに状態フラグを管理する必要はなく、ホスト１側の処理を単純にできる。場単位発売状況情報の版数を通知するための電文は、以降「版数通知」と表記する。
【０１０３】
図１１は、単位発売状況情報の版数を通知する場合のホスト、及び投票券発払機の動作の流れの例を表す他のシーケンス図である。
【０１０４】
図６との違いは、Ｓ８で発売状況通知の代わりに発売状況版数通知を送信する点と、投票券発払機２からの正常受信を表す応答をホスト１が受信すると（Ｓ９）、それにより、ホスト１は、応答を送信した投票券発払機２の状態フラグを２から１に更新し、投票券発払機２をリカバリ対象から除外する点、投票券発払機２が発売状況版数の条件判定を行い、必要に応じて発売状況照会をホスト１に送信し（Ｓ１０）、ホスト１から受信した発売状況照会応答中の発売状況を記録するとともに、発売状況照会応答中の版数を受信済Ａ場発売状況版数に設定する。（Ｓ１１）その後、発売状況取得処理が終了する。  
【０１０５】
投票券発払機２が、場単位発売状況情報の照会の必要性の判定は、図１０に表すような版数通知受信処理を実行すれば良い。ここで図１０を参照し、その版数通知受信処理について詳細に説明する。
【０１０６】
先ず、ＣＰＵ２１１は、受信した版数通知（受信電文）中の版数（ここでは「Ａ場発売状況版数」と表記）が、変数である受信済Ａ場発売状況版数より大きいか否か判定する（ＳＢ１１）。投票券発払機２が受信していない場単位発売状況情報に更新されていた場合、その条件が満たされることから、ＳＢ１１の判定はＹとなってＳＢ１２に移行する。投票券発払機２が受信していない場単位発売状況情報に更新されていない場合、その条件が満たされないことから、ＳＢ１１の判定はＮとなり、場単位発売状況情報の送信が不要である旨を表す応答をホスト１に送信した後、版数通知受信処理が終了する。
【０１０７】
ＳＢ１２では、ＣＰＵ２１１は、場単位発売状況情報の送信を要求するための電文を応答としてホスト１に送信する。その後、ＣＰＵ２１１は、要求した場単位発売状況情報のホスト１からの受信に対応する（ＳＢ１３）。それにより、ホスト１から場単位発売状況情報を受信した後、版数通知処理が終了する。
【０１０８】
このような版数通知処理を投票券発払機２に実行させることにより、ホスト１からの不要な場単位発売状況情報の送信をより抑制させることができる。  また、本実施形態では、何らかの要求のための電文の受信を、状態フラグが２の投票券発払機２のなかで正常に動作可能な投票券発払機２とする条件としているが、その条件とは異なる条件を設定しても良い。例えば応答を必要とする電文をホスト１に送信させ、正常な動作が可能とする投票券発払機２を特定するようにしても良い。或いは、場単位発売状況情報を個別に投票券発払機２に送信させ、応答により、正常な動作を投票券発払機２が可能か否かを特定するようにしても良い。
【０１０９】
また、本実施形態による情報管理装置は、ホスト１に搭載させる形で実現させているが、ホスト１とは別の装置上に実現させても良い。或いは専用の装置として実現させても良い。このようなことから、情報管理装置の実現方法は特に限定されない。
【符号の説明】
【０１１０】
１    ホストコンピュータ
２    投票券発払機
３、４    ネットワーク
５    ＰＣ
１１    記憶部
１２    更新部
１３    第１の配信部
１４    第２の配信部
１５    投票・払戻処理部
１７    レース発売状況情報群
１８    レース出走表情報群
１９    端末管理情報
１０２    ＣＰＵ
１０４    メモリ
１１０    外部記憶装置
１１２    媒体駆動装置
１１６、１１８    ネットワーク接続装置
１３０    記録媒体
【図１】
2016053926.tif 000003
【図２】
2016053926.tif 000004
【図３】
2016053926.tif 000005
【図５】
2016053926.tif 000006
【図６】
2016053926.tif 000007
【図７】
2016053926.tif 000008
【図８】
2016053926.tif 000009
【図９】
2016053926.tif 000010
【図１０】
2016053926.tif 000011
【図１１】
2016053926.tif 000012
【図４】
2016053926.tif 000013