(57)【要約】【課題】複数国間での馬券の売買を効率良く行うこと。【解決手段】処理部１２は、複数国に含まれる第１の国で行われる競馬の馬券に対する購入指示と、第１の国とは異なる第２の国の通貨で示された購入金額とを受信する。処理部１２は、第１の国と第２の国の間での為替レートの情報に基づいて、第２の国の通貨で示された購入金額を第１の国における馬券の購入金額に変換する。処理部１２は、変換した第１の国における馬券の購入金額で購入できる第１の国における馬券数を特定する。処理部１２は、特定した馬券数に対応する第１の国における馬券の購入金額と、第２の国の通貨で示された購入金額との差額を、馬券の買い目に対応付けて購入毎に蓄積する。処理部１２は、第１の買い目に対して蓄積した差額の合計が第１の国において馬券を購入できる金額以上となった場合に、第１の買い目を追加して購入する。【選択図】図１
2019212065.tif 000002
【特許請求の範囲】
【請求項１】
複数国間での馬券の売買を管理する馬券売買管理プログラムであって、
前記複数国に含まれる第１の国で行われる競馬の馬券に対する購入指示と、前記第１の国とは異なる第２の国の通貨で示された購入金額とを受信し、
前記第１の国と前記第２の国の間での為替レートの情報に基づいて、前記第２の国の通貨で示された購入金額を前記第１の国における馬券の購入金額に変換し、
変換した前記第１の国における馬券の購入金額で購入できる前記第１の国における馬券数を特定し、
特定した前記馬券数に対応する前記第１の国における馬券の購入金額と、前記第２の国の通貨で示された購入金額との差額を、馬券の買い目に対応付けて購入毎に蓄積し、
第１の買い目に対して蓄積した前記差額の合計が前記第１の国において馬券を購入できる金額以上となった場合に、前記第１の買い目を追加して購入する、
処理をコンピュータに実行させることを特徴とする馬券売買管理プログラム。
【請求項２】
前記コンピュータに更に、前記第２の国における馬券の購入金額の単価に対応する払戻金の額、または、前記単価に対応する払戻金の額の比率を、所定の装置に送信する、
処理を実行させることを特徴とする請求項１記載の馬券売買管理プログラム。
【請求項３】
前記第１の買い目を購入する際、前記第１の買い目に対する前記差額の合計から前記第１の国における馬券の単価を減算した額を、前記第１の買い目に対する更新後の前記差額の合計とする、
ことを特徴とする請求項１記載の馬券売買管理プログラム。
【請求項４】
複数国間での馬券の売買を管理する馬券売買管理装置であって、
記憶部と、
前記複数国に含まれる第１の国で行われる競馬の馬券に対する購入指示と、前記第１の国とは異なる第２の国の通貨で示された購入金額とを受信し、前記第１の国と前記第２の国の間での為替レートの情報に基づいて、前記第２の国の通貨で示された購入金額を前記第１の国における馬券の購入金額に変換し、変換した前記第１の国における馬券の購入金額で購入できる前記第１の国における馬券数を特定し、特定した前記馬券数に対応する前記第１の国における馬券の購入金額と、前記第２の国の通貨で示された購入金額との差額を、馬券の買い目に対応付けて購入毎に前記記憶部に蓄積し、第１の買い目に対して蓄積した前記差額の合計が前記第１の国において馬券を購入できる金額以上となった場合に、前記第１の買い目を追加して購入する処理部と、
を有することを特徴とする馬券売買管理装置。
【請求項５】
複数国間での馬券の売買を管理する馬券売買管理方法であって、
コンピュータが、
前記複数国に含まれる第１の国で行われる競馬の馬券に対する購入指示と、前記第１の国とは異なる第２の国の通貨で示された購入金額とを受信し、
前記第１の国と前記第２の国の間での為替レートの情報に基づいて、前記第２の国の通貨で示された購入金額を前記第１の国における馬券の購入金額に変換し、
変換した前記第１の国における馬券の購入金額で購入できる前記第１の国における馬券数を特定し、
特定した前記馬券数に対応する前記第１の国における馬券の購入金額と、前記第２の国の通貨で示された購入金額との差額を、馬券の買い目に対応付けて購入毎に蓄積し、
第１の買い目に対して蓄積した前記差額の合計が前記第１の国において馬券を購入できる金額以上となった場合に、前記第１の買い目を追加して購入する、
ことを特徴とする馬券売買管理方法。
【請求項６】
複数国間での馬券の売買を管理する馬券売買管理プログラムであって、
前記複数国に含まれる第１の国で行われる競馬の馬券に対する購入指示と、前記第１の国とは異なる第２の国の通貨で示された購入金額とを受信し、
前記第１の国と前記第２の国の間での為替レートの情報に基づいて、前記第２の国の通貨で示された購入金額を前記第１の国における馬券の購入金額に変換し、
変換した前記第１の国における馬券の購入金額で購入できる前記第１の国における馬券数を特定し、
特定した前記馬券数に対応する前記第１の国における馬券の購入金額と、前記第２の国の通貨で示された購入金額との差額を、馬券を購入したユーザに対応付けて購入毎に蓄積し、
蓄積した前記差額の合計が前記第１の国において馬券を購入できる金額以上となった場合に、前記ユーザに対し、馬券の購入が可能である旨を通知する、
処理をコンピュータに実行させることを特徴とする馬券売買管理プログラム。
【請求項７】
複数国間での馬券の売買を管理する馬券売買管理装置であって、
記憶部と、
前記複数国に含まれる第１の国で行われる競馬の馬券に対する購入指示と、前記第１の国とは異なる第２の国の通貨で示された購入金額とを受信し、前記第１の国と前記第２の国の間での為替レートの情報に基づいて、前記第２の国の通貨で示された購入金額を前記第１の国における馬券の購入金額に変換し、変換した前記第１の国における馬券の購入金額で購入できる前記第１の国における馬券数を特定し、特定した前記馬券数に対応する前記第１の国における馬券の購入金額と、前記第２の国の通貨で示された購入金額との差額を、馬券を購入したユーザに対応付けて購入毎に前記記憶部に蓄積し、蓄積した前記差額の合計が前記第１の国において馬券を購入できる金額以上となった場合に、前記ユーザに対し、馬券の購入が可能である旨を通知する処理部と、
を有することを特徴とする馬券売買管理装置。
【請求項８】
複数国間での馬券の売買を管理する馬券売買管理方法であって、
コンピュータが、
前記複数国に含まれる第１の国で行われる競馬の馬券に対する購入指示と、前記第１の国とは異なる第２の国の通貨で示された購入金額とを受信し、
前記第１の国と前記第２の国の間での為替レートの情報に基づいて、前記第２の国の通貨で示された購入金額を前記第１の国における馬券の購入金額に変換し、
変換した前記第１の国における馬券の購入金額で購入できる前記第１の国における馬券数を特定し、
特定した前記馬券数に対応する前記第１の国における馬券の購入金額と、前記第２の国の通貨で示された購入金額との差額を、馬券を購入したユーザに対応付けて購入毎に蓄積し、
蓄積した前記差額の合計が前記第１の国において馬券を購入できる金額以上となった場合に、前記ユーザに対し、馬券の購入が可能である旨を通知する、
ことを特徴とする馬券売買管理方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は馬券売買管理プログラム、馬券売買管理装置および馬券売買管理方法に関する。
【背景技術】
【０００２】
競馬や競輪などの公営競技では、競技ファンは、上位に入賞すると予想される競走馬や競技者に投票する。例えば、競技ファンは、投票先に応じた投票券を購入することで、投票を行う。競技ファンは、予想が的中すると、的中票数に応じた払戻金を受け取る。そこで、投票や払戻に関する手続きを情報処理技術により支援することが考えられている。
【０００３】
例えば、トータリゼータシステムに接続された電話投票システムの提案がある。提案の電話投票システムは、登録会員の口座ファイルの投票ベットポインタに複数のベット情報を一連の投票としてセットする。電話投票システムは、複数のベット情報に含まれる第１のレースが的中したとき、その払戻金額を次のベット情報の指定するレースの投票資金として、１つの賭番号あるいは複数の賭番号に予め申し込まれた比率に従って投票枚数を割り振る。これにより、１回の電話により払戻金額を自動的に次の投票の購入資金に充当する複数レースの投票を可能にする。
【０００４】
また、利用者自らが操作して投票を行う公営競技の自動発券端末の提案もある。提案の自動発券端末は、的中した投票券の的中金額を全額利用して次レース以降の投票券を購入する際に、複数の組合せに投票できるようにする。自動発券端末は、投票による端数金額を金額情報として投票券に記録し、端数部分を次以後の投票券購入および精算に充てる。
【０００５】
なお、くじやスポーツブックを管理するサーバや、遊技施設に設置されたゲーミングマシンから、当選金額を示す情報を受信することで、賭けやゲームによって獲得できた有価価値を、日常生活における支出に当てることができる携帯端末機の提案もある。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開昭６３−２４５７９２号公報
【特許文献２】特開２００９−１４０２７１号公報
【特許文献３】特開２０１４−１５７６３２号公報
【発明の概要】
【発明が解決しようとする課題】
【０００７】
第１の国で行われる競馬の馬券を第２の国のファンにより購入可能にすることが考えられる。この場合、第１の国の通貨と第２の国の通貨との交換に伴い為替レートが考慮される。一方、第１の国において馬券の発売価格の単位が定められていることがある。このため、第２の国の通貨で受け付けた購入金額を、第１の国の通貨での購入金額に変換したとき、変換後の購入金額が第１の国における馬券の発売価格の単位で割り切れなければ、第１の国での馬券購入により差額が生じる。そこで、当該差額の扱いが問題となる。
【０００８】
１つの側面では、本発明は、複数国間での馬券の売買を効率良く行うことができる馬券売買管理プログラム、馬券売買管理装置および馬券売買管理方法を提供することを目的とする。
【課題を解決するための手段】
【０００９】
１つの態様では、複数国間での馬券の売買を管理する馬券売買管理プログラムが提供される。馬券売買管理プログラムは、複数国に含まれる第１の国で行われる競馬の馬券に対する購入指示と、第１の国とは異なる第２の国の通貨で示された購入金額とを受信し、第１の国と第２の国の間での為替レートの情報に基づいて、第２の国の通貨で示された購入金額を第１の国における馬券の購入金額に変換し、変換した第１の国における馬券の購入金額で購入できる第１の国における馬券数を特定し、特定した馬券数に対応する第１の国における馬券の購入金額と、第２の国の通貨で示された購入金額との差額を、馬券の買い目に対応付けて購入毎に蓄積し、第１の買い目に対して蓄積した差額の合計が第１の国において馬券を購入できる金額以上となった場合に、第１の買い目を追加して購入する、処理をコンピュータに実行させる。
【００１０】
また、１つの態様では、複数国間での馬券の売買を管理する馬券売買管理プログラムが提供される。馬券売買管理プログラムは、複数国に含まれる第１の国で行われる競馬の馬券に対する購入指示と、第１の国とは異なる第２の国の通貨で示された購入金額とを受信し、第１の国と第２の国の間での為替レートの情報に基づいて、第２の国の通貨で示された購入金額を第１の国における馬券の購入金額に変換し、変換した第１の国における馬券の購入金額で購入できる第１の国における馬券数を特定し、特定した馬券数に対応する第１の国における馬券の購入金額と、第２の国の通貨で示された購入金額との差額を、馬券を購入したユーザに対応付けて購入毎に蓄積し、蓄積した差額の合計が第１の国において馬券を購入できる金額以上となった場合に、ユーザに対し、馬券の購入が可能である旨を通知する、処理をコンピュータに実行させる。
【００１１】
また、１つの態様では、複数国間での馬券の売買を管理する馬券売買管理装置が提供される。
また、１つの態様では、複数国間での馬券の売買を管理する馬券売買管理方法が提供される。
【発明の効果】
【００１２】
１つの側面では、複数国間での馬券の売買を効率良く行うことができる。
【図面の簡単な説明】
【００１３】
【図１】第１の実施の形態の馬券売買管理装置を示す図である。
【図２】第２の実施の形態の馬券売買管理システムを示す図である。
【図３】ＧＷサーバのハードウェア例を示す図である。
【図４】馬券売買管理システムの機能例を示す図である。
【図５】会員投票テーブルの例を示す図である。
【図６】端数管理テーブルの例を示す図である。
【図７】確定情報の例を示す図である。
【図８】払戻金ファイルの例を示す図である。
【図９】投票処理の例を示すフローチャートである。
【図１０】結果処理の例を示すフローチャートである。
【図１１】投票の例を示す図である。
【図１２】払戻の例を示す図である。
【図１３】第３の実施の形態の馬券売買管理システムの機能例を示す図である。
【図１４】会員投票テーブルの例を示す図である。
【図１５】端数管理テーブルの例を示す図である。
【図１６】投票処理の例を示すフローチャートである。
【発明を実施するための形態】
【００１４】
以下、本実施の形態について図面を参照して説明する。
［第１の実施の形態］
第１の実施の形態を説明する。
【００１５】
図１は、第１の実施の形態の馬券売買管理装置を示す図である。
馬券売買管理装置１０は、複数国間での馬券の売買を管理する。馬券売買管理装置１０は、第１の国で行われる競馬の馬券を、第２の国のユーザ（競馬ファン）により購入可能にする。ここで、第１の国で利用される通貨の単位を「ＣＵｘ」（ＣＵ：Currency Unit）とする。また、第２の国で利用される通貨の単位を「ＣＵｙ」とする。例えば、第１の国が日本であれば「ＣＵｘ」は「ＪＰＹ（円）」であり、第２の国が米国であれば「ＣＵｙ」は「ＵＳＤ（米国ドル）」である。
【００１６】
馬券売買管理装置１０は、ホスト装置２０に接続されている。ホスト装置２０は、第１の国で行われる競馬における投票数を管理する。ホスト装置２０は、ネットワークを介して第１の国のユーザが利用する端末装置（図示を省略している）に接続され、当該端末装置から第１の国のユーザによる投票を受け付ける。また、ホスト装置２０は、馬券売買管理装置１０を介して、第２の国のユーザによる投票を受け付ける。ホスト装置２０は、第１の国のユーザおよび第２の国のユーザによる投票数を合算して管理する。
【００１７】
ここで、投票数は、各賭式の買い目単位に管理される。賭式とは、単勝式、複勝式、連勝単式、連勝複式および重勝式などの馬券の種類（勝馬投票法に応じた種類）を示す。買い目とは、投票先の候補あるいは投票先となる馬番、枠番、馬番の組合せおよび枠番の組合せを示す。賭式が重勝式の場合、買い目は、複数レースにおける馬番または枠番の組合せ（例えば、第１レースにおける第１の馬番と第２レースにおける第２の馬番との組合せなど）となる。ホスト装置２０は、各買い目の投票数に応じて、パリミュチュエル方式などに基づく所定の演算により、各買い目に対して、馬券の発売単価に対する配当額、あるいは、購入単価（α）に対する配当額（β）の比率（β／α）（オッズ）を決定する。
【００１８】
また、馬券売買管理装置１０は、ゲートウェイ３０に接続されている。ゲートウェイ３０は、ホスト装置４０に接続されている。ホスト装置４０は、ネットワークを介して第２の国のユーザが利用する端末装置（図示を省略している）に接続され、当該端末装置から第２の国のユーザによる投票を示す投票情報を受け付ける。第２の国のユーザによる投票情報の入力は、第２の国の通貨を用いて行われる。すなわち、投票情報は、第２の国のユーザにより選択された買い目や購入金額の情報を含む。
【００１９】
ホスト装置４０は、投票情報をゲートウェイ３０に送信する。ゲートウェイ３０は、投票情報をホスト装置４０から受信し、馬券売買管理装置１０に送信する。すなわち、ゲートウェイ３０は、ホスト装置４０から馬券売買管理装置１０へ投票情報の中継を行う。馬券売買管理装置１０は、ゲートウェイ３０から受信した投票情報を基に、為替レートを考慮し、第１の国での該当の買い目への投票数を決定する。馬券売買管理装置１０は、ホスト装置２０に、買い目と投票数とを送信する。
【００２０】
こうして、第１の国と第２の国との間で、賭金のプールが統合され、いわゆるコミングリングが実現される。このとき、馬券売買管理装置１０において、第２の国のユーザにより指定された第２の国の通貨での購入金額と第１の国の通貨での馬券の購入金額とでは、為替レートによる差額が生じ得る。そこで、馬券売買管理装置１０は、当該差額を考慮して、馬券売買を効率的に行う機能を提供する。
【００２１】
馬券売買管理装置１０は、記憶部１１および処理部１２を有する。記憶部１１は、ＲＡＭ（Random Access Memory）などの揮発性記憶装置でもよいし、ＨＤＤ（Hard Disk Drive）やフラッシュメモリなどの不揮発性記憶装置でもよい。処理部１２は、ＣＰＵ（Central Processing Unit）、ＤＳＰ（Digital Signal Processor）、ＡＳＩＣ（Application Specific Integrated Circuit）、ＦＰＧＡ（Field Programmable Gate Array）などを含み得る。処理部１２はプログラムを実行するプロセッサであってもよい。ここでいう「プロセッサ」には、複数のプロセッサの集合（マルチプロセッサ）も含まれ得る。
【００２２】
記憶部１１は、為替レートの情報や第１の国における馬券の発売価格の単位（発売単価）の情報を記憶する。一例として、２種の通貨「ＣＵｘ」および「ＣＵｙ」の為替レートは、１（ＣＵｙ）当たり１４（ＣＵｘ）（「１（ＣＵｙ）＝１４（ＣＵｘ）」）とする。また、一例として、第１の国における馬券の発売価格の単位は、１票当たり１００（ＣＵｘ）とする。
【００２３】
記憶部１１は、管理テーブル５０を記憶する。管理テーブル５０は、第２の国のユーザにより指定された第２の国の通貨での購入金額と第１の国の通貨での馬券の購入金額との為替レートによる差額を、買い目毎（各賭式の買い目毎）に管理するための情報である。管理テーブル５０は、例えばレース毎に設けられる。
【００２４】
処理部１２は、複数国に含まれる第１の国で行われる競馬の馬券に対する購入指示と、第１の国とは異なる第２の国の通貨で示された購入金額とを受信する。第１の国で行われる競馬の馬券の第２の国での購入金額は、第２の国の通貨（ＣＵｙ）でホスト装置４０に対して指定される。このとき、ホスト装置４０は、投票先の買い目の選択を受け付け、購入金額と投票先の買い目とを含む投票情報を馬券売買管理装置１０に送信する。処理部１２は、当該購入金額と投票先の買い目とを含む投票情報を、ゲートウェイ３０を介して、ホスト装置４０から受信することで、第１の国で行われる競馬の馬券が第２の国で購入されたことを検出する。すると、処理部１２は、第１の国と第２の国の間での為替レートの情報を取得する。例えば、処理部１２は、ネットワークを介して接続された、為替レートを提供する所定の情報処理装置から為替レートの情報を取得し、記憶部１１に格納する。
【００２５】
処理部１２は、取得した為替レートの情報に基づいて、第２の国の通貨で示された購入金額を第１の国における馬券の購入金額に変換する。例えば、為替レートが１（ＣＵｙ）＝１４（ＣＵｘ）であれば、ａ（ＣＵｙ）＝１４ａ（ＣＵｘ）である。
【００２６】
処理部１２は、変換した第１の国における馬券の購入金額で購入できる第１の国における馬券の数を特定する。例えば、馬券の発売価格の単位が１票＝１００（ＣＵｘ）であれば、購入できる馬券の数は、Ｉｎｔｅｇｅｒ（１４ａ／１００）である。ここで、演算子Ｉｎｔｅｇｅｒは括弧内の実数の整数部を得る演算を示す。
【００２７】
処理部１２は、特定した馬券数に対応する第１の国における馬券の購入金額と、第２の国の通貨で示された購入金額（ただし、第１の国の通貨に変換後の金額）との差額を、馬券の買い目に対応付けて購入毎に蓄積する。上記の例では、差額は、１４ａ−（１００×Ｉｎｔｅｇｅｒ（１４ａ／１００））である。
【００２８】
処理部１２は、差額および差額の合計を管理テーブル５０に記録する。例えば、管理テーブル５０は、購入＃、買い目、差額、差額合計の項目を含む。購入＃は、馬券の１回の購入を識別する番号である。買い目は、賭式毎の買い目を示す。差額は、特定した馬券数に対応する第１の国の通貨単位での購入金額と、第２の国のユーザが入力した第２の国の通貨で示された購入金額を第１の国の通貨単位に変換した購入金額との差額であり、第１の国の通貨単位（ＣＵｘ）で表される。差額合計は、買い目毎の差額の合計であり、第１の国の通貨単位（ＣＵｘ）で表される。
【００２９】
処理部１２は、ある買い目（第１の買い目）に対して蓄積した差額の合計が第１の国において馬券を購入できる金額以上となった場合に、該当の買い目（第１の買い目）を追加して購入する（すなわち、第１の買い目への投票を行う）。上記の例でいえば、第１の国において馬券を購入できる金額は、第１の国における馬券の発売価格の単位であり、１００（ＣＵｘ）である。この場合、処理部１２は、ある買い目に対して蓄積した差額の合計が１００（ＣＵｘ）以上となったか否かを判定する。そして、処理部１２は、蓄積した差額の合計が１００（ＣＵｘ）以上となった場合、該当の買い目に投票する。一方、処理部１２は、蓄積した差額の合計が１００（ＣＵｘ）未満の場合、該当の買い目に対する投票を行わない（当該差額の合計を用いて馬券を購入することができないため）。
【００３０】
例えば、あるレースに対して、馬券売買管理装置１０およびホスト装置２０が第２の国のユーザによる投票を受け付けていない場合を起点に考える。この場合、管理テーブル５０には各買い目の差額および差額合計が記録されていない。このときの各買い目の差額合計は０（ＣＵｘ）である。
【００３１】
第２の国の第１のユーザが、買い目「Ａ」に対して１０（ＣＵｙ）相当の馬券を購入したとする。第２の国における馬券の購入金額と購入したユーザとの対応関係は、例えば、ホスト装置４０により管理される。この場合、第２の国における馬券の購入金額は１０（ＣＵｙ）である。このとき、上記の為替レートの例では、第１の国における馬券の購入金額は、１０×１４＝１４０（ＣＵｘ）である。また、第１の国における馬券の購入金額で購入できる第１の国における馬券の数は、Ｉｎｔｅｇｅｒ（１４０／１００）＝１である。そして、特定した馬券数に対応する購入金額（特定した馬券数に対応する第１の国における馬券の購入金額）と、第２の国における馬券の購入金額（第２の国の通貨で示された購入金額を第１の国の通貨単位に変換した購入金額）との差額は、１４０−１００＝４０である。よって、処理部１２は、買い目「Ａ」に対する１票をホスト装置２０に計上する。処理部１２は、購入＃「１」、買い目「Ａ」、差額「４０」、差額合計「４０」のレコードを管理テーブル５０に記録する。
【００３２】
次に、第２の国の第２のユーザ（ただし、第１のユーザと異なってもよいし、同一でもよい）が、買い目「Ｂ」に対して２０（ＣＵｙ）相当の馬券を購入したとする。この場合、第２の国における馬券の購入金額は２０（ＣＵｙ）である。このとき、上記の為替レートの例では、第１の国における馬券の購入金額は、２０×１４＝２８０（ＣＵｘ）である。また、第１の国における馬券の購入金額で購入できる第１の国における馬券の数は、Ｉｎｔｅｇｅｒ（２８０／１００）＝２である。そして、特定した馬券数に対応する購入金額と、第２の国における馬券の購入金額との差額は、２８０−２００＝８０である。よって、処理部１２は、買い目「Ｂ」に対する２票をホスト装置２０に計上する。処理部１２は、購入＃「２」、買い目「Ｂ」、差額「８０」、差額合計「８０」のレコードを管理テーブル５０に記録する。
【００３３】
次に、第２の国の第３のユーザ（ただし、第１，第２のユーザと異なってもよいし、同一でもよい）が、買い目「Ａ」に対して２０（ＣＵｙ）相当の馬券を購入したとする。この場合、第２の国における馬券の購入金額は２０（ＣＵｙ）である。上記の為替レートの例では、第１の国における馬券の購入金額は、２０×１４＝２８０（ＣＵｘ）である。また、第１の国における馬券の購入金額で購入できる第１の国における馬券の数は、Ｉｎｔｅｇｅｒ（２８０／１００）＝２である。そして、特定した馬券数に対応する購入金額と、第２の国における馬券の購入金額との差額は、２８０−２００＝８０である。ここで、管理テーブル５０によれば、買い目「Ａ」に関する最新のレコード（購入＃「１」のレコード）において差額合計「４０」が記録されている。したがって、今回の購入による買い目「Ａ」に対する差額合計は４０＋８０＝１２０（ＣＵｘ）である。よって、処理部１２は、買い目「Ａ」に対する２票をホスト装置２０に計上する。処理部１２は、購入＃「３」、買い目「Ａ」、差額「８０」、差額合計「１２０」のレコードを管理テーブル５０に記録する。
【００３４】
ここで、処理部１２は、管理テーブル５０により、購入＃「３」の買い目「Ａ」に対する差額合計「１２０」（ＣＵｘ）が、第１の国において馬券を購入できる金額「１００」（ＣＵｘ）以上であることを検出する。すると、処理部１２は、該当の買い目「Ａ」に対する１票をホスト装置２０に計上する。また、処理部１２は、購入＃「４」、買い目「Ａ」、差額「２０」、差額合計「２０」のレコードを管理テーブル５０に記録する。ここで、差額および差額合計を「２０」とする理由は、購入＃「３」における差額合計「１２０」から投票した１票分の金額「１００」を減算した金額を、該当の買い目「Ａ」に対する差額の残りとして管理するためである。すなわち、差額合計から１票分の馬券が購入されたことになる。
【００３５】
処理部１２は、レースが行われた後、当該レースにおける順位の確定情報やオッズ（あるいは馬券の購入単価に対する配当額）の情報をホスト装置２０から取得し、ゲートウェイ３０を介してホスト装置４０に送信する。すなわち、処理部１２は、第２の国における馬券の購入金額の単価に対応する払戻金の額、または、単価に対応する払戻金の額の比率を、ホスト装置４０（所定の装置）に送信する。ホスト装置４０は、当該オッズに基づいて、的中票（的中した馬券）を持つユーザに対し、払戻金を割り当てる。
【００３６】
馬券売買管理装置１０によれば、複数国に含まれる第１の国で行われる競馬の馬券に対する購入指示と、第１の国とは異なる第２の国の通貨で示された購入金額とが受信される。第１の国と第２の国の間での為替レートの情報に基づいて、第２の国の通貨で示された購入金額が第１の国における馬券の購入金額に変換される。変換した第１の国における馬券の購入金額で購入できる第１の国における馬券数が特定される。特定した馬券数に対応する第１の国における馬券の購入金額と、第２の国の通貨で示された購入金額（ただし、第１の国の通貨に変換後の金額）との差額が、馬券の買い目に対応付けて購入毎に蓄積される。第１の買い目に対して蓄積した差額の合計が第１の国において馬券を購入できる金額以上となった場合に、第１の買い目が追加して購入される。
【００３７】
これにより、複数国間での馬券の売買を効率良く行うことができる。
例えば、コミングリングにより、賭金プールを統合する場合、馬券売買管理装置１０において、第２の国のユーザにより指定された第２の国の通貨での購入金額と第１の国の通貨での馬券の購入金額とでは、為替レートによる差額が生じ得る。そこで、このような差額の取り扱いが問題となる。例えば、発生した差額を第２の国のユーザに全て返還することも考えられる。しかし、第２の国のユーザにとっては、第２の国の通貨によって所望の購入金額を指定したにも拘わらず、そのうちの一部が受け付けられなかったことになり、競技への期待や興味の低下を招く可能性がある。また、指定した購入金額により投票したいという第２の国のユーザの意思に反して、差額の返還を行うという非効率な処理をゲートウェイ３０やホスト装置４０に強いることにもなる。更に、発生した差額をプールできず、コミングリングの魅力を十分に発揮できない可能性もある。
【００３８】
そこで、馬券売買管理装置１０は、買い目単位の差額合計が、第１の国における馬券の発売価格の単位に達すると、該当の買い目に対する自動投票を行う。これにより、該当の買い目に対して投票したユーザの意思を、ホスト装置２０が管理する当該買い目の投票数に適切に反映させることができる。ホスト装置２０は、差額合計による投票数も計上した上で、オッズの計算を行える。賭金プールに投入される金額が増すことで、第１および第２の国のユーザによる高配当に対する期待感も向上し、コミングリングの魅力を十分に発揮できる。また、第２の国のユーザの意思に反して差額を返還するという非効率な処理を行わずに済む。こうして、馬券売買管理装置１０は、複数国間での馬券の売買を効率良く行うことができる。
【００３９】
なお、馬券売買管理装置１０によれば、買い目毎の差額を常に１票未満の金額にすることができる。このため、為替誤差による票数の誤差（あるいはオッズの誤差）を最小限に抑えることができる。買い目毎に最終的に残った差額は、運用に応じて処理される。例えば、差額を切り捨てる（オッズに反映させない）、差額を切り上げる（オッズに反映させる）、または、全体票の売上に計上する（オッズに反映させる）などの方法が考えられる。
【００４０】
［第２の実施の形態］
次に、第２の実施の形態を説明する。
図２は、第２の実施の形態の馬券売買管理システムを示す図である。
【００４１】
第２の実施の形態の馬券売買管理システムは、日本（第１の実施の形態における第１の国の一例）で開催される競馬の馬券を香港（第１の実施の形態における第２の国の一例）のファンにも購入可能にし、コミングリングを実現する。第２の実施の形態の馬券売買管理システムは、ゲートウェイ（ＧＷ：GateWay）サーバ１００，３００およびホスト装置２００，４００を含む。ＧＷサーバ１００およびホスト装置２００は、例えば、日本の競馬の主催者により運用される。ＧＷサーバ３００およびホスト装置４００は、例えば、香港の競馬の主催者により運用される。
【００４２】
ＧＷサーバ１００はホスト装置２００と接続される。ＧＷサーバ１００は、ＬＡＮ（Local Area Network）やＷＡＮ（Wide Area Network）などのネットワークを介してホスト装置２００と接続されてもよい。ＧＷサーバ３００はホスト装置４００と接続される。ＧＷサーバ３００は、ＬＡＮやＷＡＮなどのネットワークを介してホスト装置４００と接続されてもよい。
【００４３】
ＧＷサーバ１００，３００は、ネットワーク６０に接続される。ホスト装置２００は、ネットワーク７０に接続される。ホスト装置４００は、ネットワーク８０に接続される。ネットワーク６０，７０，８０は、インターネットでもよい。ネットワーク６０，７０，８０それぞれは、個別のＷＡＮやＬＡＮでもよい。
【００４４】
ＧＷサーバ１００は、ＧＷサーバ３００と通信し、香港のファンによる勝馬投票券（馬券）の購入を受け付けるサーバコンピュータである。ＧＷサーバ１００は、香港ドル（ＨＫＤ）での馬券の購入金額を受け付け、為替レートの情報に基づいて、日本円での馬券の購入金額に変換する。ＧＷサーバ１００は、日本円での馬券の購入金額（あるいは購入金額に応じた投票数）をホスト装置２００に通知することで、当該馬券の購入金額（あるいは投票数）をホスト装置２００に計上する。また、ＧＷサーバ１００は、ホスト装置２００により計算された払戻金（あるいはオッズ）を取得し、ＧＷサーバ３００を介して、ホスト装置４００に提供する。ＧＷサーバ１００は、第１の実施の形態の馬券売買管理装置１０の一例である。
【００４５】
ホスト装置２００は、日本のファンおよび香港のファンによる馬券の購入を受け付け、当該馬券の売上や投票数を管理するサーバコンピュータである。例えば、ネットワーク７０には、ユーザ端末７１，７２が接続される。ユーザ端末７１，７２は、日本のファンが利用するクライアントコンピュータである。ホスト装置２００は、日本のファンにより購入される馬券の買い目や購入金額の情報をユーザ端末７１，７２から取得する。また、ホスト装置２００は、香港のファンにより購入される馬券の買い目や購入金額の情報をＧＷサーバ１００から取得する。このように、ホスト装置２００は、日本のファンおよび香港のファンの両者による馬券の購入を受け付けることで、合計の売上（あるいは合計の投票数）を管理する。ホスト装置２００は、当該合計の売上（あるいは合計投票数）に応じて、各賭式の買い目に対する払戻金（あるいはオッズ）を計算する。ホスト装置２００は、第１の実施の形態のホスト装置２０の一例である。
【００４６】
ＧＷサーバ３００は、ＧＷサーバ１００と通信し、ホスト装置４００から通知された香港のファンによる馬券の購入をＧＷサーバ１００に通知するサーバコンピュータである。ＧＷサーバ３００は、第１の実施の形態のゲートウェイ３０の一例である。
【００４７】
ホスト装置４００は、香港のファンによる馬券の購入を受け付け、当該馬券の売上や投票数を管理するサーバコンピュータである。例えば、ネットワーク８０には、ユーザ端末８１，８２が接続される。ユーザ端末８１，８２は、香港のファンが利用するクライアントコンピュータである。ホスト装置４００は、香港のファンにより購入される馬券の買い目や購入金額の情報をユーザ端末８１，８２から取得する。ホスト装置４００は、ＧＷサーバ３００を介して、香港のファンにより購入される馬券の買い目や購入金額の情報をＧＷサーバ１００に通知する。また、ホスト装置４００は、ホスト装置２００により計算された払戻金（あるいはオッズ）の情報を取得し、ユーザ端末８１，８２へ現在のオッズの情報を提供したり、レース結果の確定後には香港の各ファンに割り当てる払戻金の計算に利用したりする。ホスト装置４００は、第１の実施の形態のホスト装置４０の一例である。
【００４８】
図３は、ＧＷサーバのハードウェア例を示す図である。
ＧＷサーバ１００は、ＣＰＵ１０１、ＲＡＭ１０２、ＨＤＤ１０３、画像信号処理部１０４、入力信号処理部１０５、媒体リーダ１０６および通信インタフェース１０７，１０８を有する。なお、ＣＰＵ１０１は、第１の実施の形態の処理部１２に対応する。ＲＡＭ１０２またはＨＤＤ１０３は、第１の実施の形態の記憶部１１に対応する。
【００４９】
ＣＰＵ１０１は、プログラムの命令を実行するプロセッサである。ＣＰＵ１０１は、ＨＤＤ１０３に記憶されたプログラムやデータの少なくとも一部をＲＡＭ１０２にロードし、プログラムを実行する。なお、ＣＰＵ１０１は複数のプロセッサコアを含んでもよい。また、ＧＷサーバ１００は複数のプロセッサを有してもよい。以下で説明する処理は複数のプロセッサまたはプロセッサコアを用いて並列に実行されてもよい。また、複数のプロセッサの集合を「マルチプロセッサ」または単に「プロセッサ」と言うことがある。
【００５０】
ＲＡＭ１０２は、ＣＰＵ１０１が実行するプログラムやＣＰＵ１０１が演算に用いるデータを一時的に記憶する揮発性の半導体メモリである。なお、ＧＷサーバ１００は、ＲＡＭ以外の種類のメモリを備えてもよく、複数個のメモリを備えてもよい。
【００５１】
ＨＤＤ１０３は、ＯＳ（Operating System）やミドルウェアやアプリケーションソフトウェアなどのソフトウェアのプログラム、および、データを記憶する不揮発性の記憶装置である。なお、ＧＷサーバ１００は、フラッシュメモリやＳＳＤ（Solid State Drive）などの他の種類の記憶装置を備えてもよく、複数の不揮発性の記憶装置を備えてもよい。
【００５２】
画像信号処理部１０４は、ＣＰＵ１０１からの命令に従って、ＧＷサーバ１００に接続されたディスプレイ１１１に画像を出力する。ディスプレイ１１１としては、ＣＲＴ（Cathode Ray Tube）ディスプレイ、液晶ディスプレイ（ＬＣＤ：Liquid Crystal Display）、プラズマディスプレイ、有機ＥＬ（ＯＥＬ：Organic Electro-Luminescence）ディスプレイなど、任意の種類のディスプレイを用いることができる。
【００５３】
入力信号処理部１０５は、ＧＷサーバ１００に接続された入力デバイス１１２から入力信号を取得し、ＣＰＵ１０１に出力する。入力デバイス１１２としては、マウス・タッチパネル・タッチパッド・トラックボールなどのポインティングデバイス、キーボード、リモートコントローラ、ボタンスイッチなどを用いることができる。また、ＧＷサーバ１００に、複数の種類の入力デバイスが接続されていてもよい。
【００５４】
媒体リーダ１０６は、記録媒体１１３に記録されたプログラムやデータを読み取る読み取り装置である。記録媒体１１３として、例えば、磁気ディスク、光ディスク、光磁気ディスク（ＭＯ：Magneto-Optical disk）、半導体メモリなどを使用できる。磁気ディスクには、フレキシブルディスク（ＦＤ：Flexible Disk）やＨＤＤが含まれる。光ディスクには、ＣＤ（Compact Disc）やＤＶＤ（Digital Versatile Disc）が含まれる。
【００５５】
媒体リーダ１０６は、例えば、記録媒体１１３から読み取ったプログラムやデータを、ＲＡＭ１０２やＨＤＤ１０３などの他の記録媒体にコピーする。読み取られたプログラムは、例えば、ＣＰＵ１０１によって実行される。なお、記録媒体１１３は可搬型記録媒体であってもよく、プログラムやデータの配布に用いられることがある。また、記録媒体１１３やＨＤＤ１０３を、コンピュータ読み取り可能な記録媒体と言うことがある。
【００５６】
通信インタフェース１０７は、ネットワーク６０に接続され、ネットワーク６０を介してＧＷサーバ３００と通信を行うインタフェースである。通信インタフェース１０７は、例えば、スイッチやルータなどの通信装置とケーブルで接続される。
【００５７】
通信インタフェース１０８は、ホスト装置２００と接続され、ホスト装置２００と通信を行うインタフェースである。通信インタフェース１０８は、ＬＡＮなどのネットワークを介してホスト装置２００と接続されてもよい。
【００５８】
なお、ホスト装置２００，４００、ＧＷサーバ３００およびユーザ端末７１，７２，８１，８２もＧＷサーバ１００と同様のハードウェアを用いて実現される。
図４は、馬券売買管理システムの機能例を示す図である。
【００５９】
ＧＷサーバ１００は、為替情報記憶部１２０、端数情報記憶部１３０、結果情報記憶部１４０およびＧＷ処理部１５０を有する。為替情報記憶部１２０、端数情報記憶部１３０および結果情報記憶部１４０は、ＲＡＭ１０２やＨＤＤ１０３の記憶領域を用いて実現される。ＧＷ処理部１５０は、ＲＡＭ１０２に記憶されたプログラムをＣＰＵ１０１が実行することで実現される。
【００６０】
為替情報記憶部１２０は、為替情報を記憶する。為替情報は、為替レートの情報であり、香港ドルから日本円へ変換するときの為替レートを含む。為替情報は、ＧＷ処理部１５０により、為替情報を提供する所定のサーバから取得され、為替情報記憶部１２０に格納される。
【００６１】
端数情報記憶部１３０は、端数情報を記憶する。端数情報は、香港ドルで指定された購入金額と、日本円での馬券の購入金額との差額に相当する端数を、各賭式の買い目単位に管理するための情報である。端数情報は、レース毎に作成される。
【００６２】
結果情報記憶部１４０は、レースの結果情報を記憶する。結果情報は、確定情報および払戻金ファイルを含む。確定情報は、該当のレースにおける競走馬の着順や着差などを示す情報である。払戻金ファイルは、的中した馬券に対する購入単価当たりの払戻金（配当額）を示す情報である。
【００６３】
ＧＷ処理部１５０は、ＧＷサーバ１００におけるＧＷ処理を実行する。ＧＷ処理は、香港ドルで受け付けた馬券の購入情報を、日本円での馬券の購入情報に変換して、ホスト装置２００に計上する処理、および、ＧＷサーバ３００を介してホスト装置４００に結果情報を提供する処理を含む。ＧＷ処理部１５０は、投票部１５１および結果処理部１５２を有する。
【００６４】
投票部１５１は、香港のファンによるレース毎の投票を受け付け、ホスト装置２００に計上する。投票部１５１は、為替情報記憶部１２０に記憶された為替レートの情報に基づいて、香港ドルで受け付けた馬券の購入情報を、日本円での馬券の購入情報に変換し、ホスト装置２００に送信する。ここで、日本での馬券の発売価格の単位（発売単価と言う）は、例えば、１００円である。このため、香港ドルによる購入金額を為替レートに応じて日本円に変換した金額が、１００円の倍数でない（１００円で割り切れない）場合、端数（差額）が生じることになる。投票部１５１は、生じた端数を、買い目毎に、端数情報記憶部１３０に保存し、買い目毎に、端数の合計額を計算する。投票部１５１は、ある買い目について端数の合計額が、日本での馬券の発売単価である１００円以上になると、当該合計額を用いて、該当の買い目に対する投票を行う。
【００６５】
結果処理部１５２は、ホスト装置２００から結果情報を取得し、結果情報記憶部１４０に格納する。ホスト装置２００から取得される結果情報は、日本向けの形式（例えば、日本円での記述を含む）となっている。このため、結果処理部１５２は、日本向けの形式の結果情報を、香港向けの形式に変換し、ＧＷサーバ３００を介してホスト装置４００に提供する。
【００６６】
ホスト装置２００は、投票情報記憶部２１０および投票管理部２２０を有する。投票情報記憶部２１０は、ホスト装置２００のＲＡＭやＨＤＤなど記憶領域を用いて実現される。投票管理部２２０は、ホスト装置２００のＲＡＭに記憶されたプログラムを、ホスト装置２００のＣＰＵが実行することで実現される。
【００６７】
投票情報記憶部２１０は、レース毎の投票情報を記憶する。投票情報は、各買い目に対し、日本のファンによる投票数と香港のファンによる投票数とを合わせた投票数を示す。１票当たりの日本円の購入金額は１００円なので、当該投票数に１００を乗じた金額は売上に相当する。
【００６８】
投票管理部２２０は、ユーザ端末７１，７２から日本のファンの投票を受け付け、投票情報記憶部２１０に記憶された投票情報に記録する。また、投票管理部２２０は、ＧＷサーバ１００から香港のファンの投票を受け付け、投票情報記憶部２１０に記憶された投票情報に記録する。投票管理部２２０は、当該投票情報に基づいて、各買い目に対するオッズを計算する。オッズの計算には、例えば、パリミュチュエル方式に基づく所定の演算式が用いられる。当該演算式には、例えば、法令で定められた演算式を用いることができる。あるレースに関し、ある時点で計算されたオッズの情報は、ＧＷサーバ１００，３００を介してホスト装置４００に提供される。また、投票管理部２２０は、レース終了後には、レース結果を示す結果情報を生成し、ＧＷサーバ１００に送信する。
【００６９】
ＧＷサーバ３００は、中継部３１０を有する。中継部３１０は、ＧＷサーバ３００のＲＡＭに記憶されたプログラムを、ＧＷサーバ３００のＣＰＵが実行することで実現される。中継部３１０は、ホスト装置４００とＧＷサーバ１００との間でのデータ転送を中継する。中継部３１０は、ホスト装置４００から受信した投票情報を、ＧＷサーバ１００に送信する。また、中継部３１０は、ＧＷサーバ１００から受信した結果情報を、ホスト装置４００に送信する。
【００７０】
ホスト装置４００は、会員情報記憶部４１０、ＵＩ（User Interface）処理部４２０および投票管理部４３０を有する。会員情報記憶部４１０は、ホスト装置４００のＲＡＭやＨＤＤの記憶領域により実現される。ＵＩ処理部４２０および投票管理部４３０は、ホスト装置４００のＲＡＭに記憶されたプログラムを、ホスト装置４００のＣＰＵが実行することで実現される。
【００７１】
会員情報記憶部４１０は、香港のファンの会員情報を記憶する。会員情報は、香港のファンの会員ＩＤ（IDentifier）に関する情報や、香港のファンによるレース毎の投票数を管理するための情報を含む。
【００７２】
ＵＩ処理部４２０は、ユーザ端末８１，８２に対してＧＵＩ（Graphical User Interface）を提供する。ＵＩ処理部４２０は、ＧＷサーバ１００，３００を介して取得したオッズの情報を、ユーザ端末８１，８２に提供する。また、ＵＩ処理部４２０は、レース終了後には、投票管理部４３０から払戻金の割り当て結果を取得し、ユーザ端末８１，８２に提供する。
【００７３】
投票管理部４３０は、レース終了後に、ＧＷサーバ１００，３００を介して取得した結果情報に基づいて、香港の各ファンに対する払戻金の割り当てを行う。投票管理部４３０は、払戻金の割り当て結果を、ＵＩ処理部４２０に通知する。
【００７４】
図５は、会員投票テーブルの例を示す図である。
会員投票テーブル４１１は、香港のファンによるレース毎の投票数を管理するための情報である。例えば、会員投票テーブル４１１は、投票管理部４３０により作成され、会員情報記憶部４１０に格納される。投票管理部４３０は、ＵＩ処理部４２０を介してユーザ端末８１，８２から受け付けた香港ドルでの投票数を会員投票テーブル４１１に記録する。会員投票テーブル４１１は、投票日、会員ＩＤ、場名、レース番号、賭式、馬番、口数および賭け金の項目を含む。
【００７５】
投票日の項目には、投票日が登録される。会員ＩＤの項目には、香港のファンの会員ＩＤが登録される。場名の項目には、レースが開催される競馬場の名称が登録される。レース番号の項目には、レース番号が登録される。賭式の項目には、勝馬投票法（賭式）が登録される。馬番の項目には、投票先の馬番または馬番の組合せが登録される（枠番または枠番の組合せも馬番と同様に登録され得る）。口数の項目には、該当の買い目（図５では、馬番または馬番の組合せを例示）に対する投票数（口数）が登録される。賭け金の項目には、投票数に対応する賭け金の額（香港ドル単位）が登録される。例えば、香港での１票当たりの馬券の購入金額（単価）を１０香港ドル（ＨＫＤ）とする。すると、投票数の価値は、香港ドル単位で、（１０×投票数）ＨＫＤである。
【００７６】
ここで、勝馬投票法（賭式）には、例えば、いわゆる単勝、複勝、枠連、馬連、ワイド、馬単、３連複、３連単、および、重勝式が挙げられる。買い目は、賭式に応じた投票先の番号（馬番や枠番）、または、番号の組合せ（馬番の組合せや枠番号の組合せといった組番）となる。賭式が重勝式の場合、買い目は、複数レースにおける馬番または枠番の組合せとなる。
【００７７】
例えば、会員投票テーブル４１１には、投票日が「ｙｙｙｙｍｍｄｄ」、会員ＩＤが「００１」、場名が「東京」、レース番号が「１」、賭式が「馬連」、馬番が「１−２」、口数が「１」、賭け金が「１０」というレコードが登録される。このレコードは、投票日「ｙｙｙｙｍｍｄｄ」に、会員ＩＤ「００１」の香港のファンが場名「東京」のレース番号「１」のレースにおいて、賭式「馬連」で買い目として馬番「１−２」を指定した口数「１」の投票を行ったことを示す。また、当該口数「１」の投票に対応する賭け金が「１０」ＨＫＤであることを示す。
【００７８】
このように、会員投票テーブル４１１は、各ファンによる１ベット（bet）毎に投票内容を管理する。
なお、会員投票テーブル４１１をホスト装置４００により管理する例を示したが、会員投票テーブル４１１をＧＷサーバ３００により記憶し、管理してもよい。
【００７９】
図６は、端数管理テーブルの例を示す図である。
端数管理テーブル１３１，１３２，１３３，・・・は、香港ドルで指定された購入金額と、日本円での馬券の購入金額との差額に相当する端数を、各賭式の買い目単位に管理するための端数情報である。１つの端数管理テーブルは、１つの賭式の１つの買い目に対応する。例えば、端数管理テーブル１３１は、単勝１番（すなわち、単勝式という賭式の馬番「１」に相当する買い目）に対応する。同様に、端数管理テーブル１３２，１３３，・・・は、単勝の他の買い目、あるいは、他の賭式の買い目に対応する。ここでは、端数管理テーブル１３１を主に説明するが、端数管理テーブル１３２，１３３，・・・も端数管理テーブル１３１と同様のデータ構造を有する。
【００８０】
端数管理テーブル１３１は、Ｎｏ、トランザクションＩＤ、会員ＩＤ、ＨＫＤ購入金額、ＪＰＹ金額、ＪＰ購入票数、端数、端数累計および繰上票の項目を含む。
Ｎｏの項目には、レコードを識別する番号が登録される。トランザクションＩＤの項目には、馬券購入のためのトランザクションの識別情報（トランザクションＩＤ）が登録される。会員ＩＤの項目には、会員ＩＤが登録される。ＨＫＤ購入金額の項目には、香港ドルで指定された馬券の購入金額が登録される。前述のように、一例として、香港における馬券の発売単価は、１０ＨＫＤであるとする。この場合、ＨＫＤ購入金額の項目に設定される値は、１０ＨＫＤの倍数になる。ＪＰＹ金額の項目には、ＨＫＤ購入金額を為替レートに基づいて日本円に変換した金額が登録される。一例として、為替レートを、１０ＨＫＤ＝１４０円とする。なお、直前のトランザクションによって端数累計の金額が日本での馬券の購入単価である１００円に達したとき、次のレコードのＪＰＹ金額の項目には、当該端数累計の金額が登録される。ＪＰ購入票数の項目には、ＪＰＹ金額に対して購入可能な馬券の票数が登録される。端数の項目には、ＪＰＹ金額とＪＰ購入票数に応じた購入金額との差額（端数）が登録される。端数累計の項目には、端数の累計が登録される。繰上票の項目には、端数累計で購入可能な馬券の票数が登録される。
【００８１】
例えば、端数管理テーブル１３１には、Ｎｏが「１」、トランザクションＩＤが「Ｔ１」、会員ＩＤが「００３」、ＨＫＤ購入金額が「１０ＨＫＤ」、ＪＰＹ金額が「１４０円」、ＪＰ購入票数が「１」、端数が「４０円」、端数累計が「４０円」、繰上票が「０」というレコードが登録される。このレコードは、会員ＩＤ「００３」の香港のファンにより、トランザクションＩＤ「Ｔ１」のトランザクションによって、単勝１番の馬券が購入されたこと（単勝１番に投票されたこと）を示し、香港ドルでの購入金額が１０ＨＫＤであることを示す。また、購入金額１０ＨＫＤを日本円に変換すると１４０円であり、その場合の日本での購入票数が１票であること、馬券購入において為替誤差に伴う端数が４０円であることを示す。更に、単勝１番の買い目に対する端数累計が４０円であること、端数累計に対する繰上票の数が０であることを示す。
【００８２】
また、例えば、端数管理テーブル１３１には、Ｎｏが「２」、トランザクションＩＤが「Ｔ２」、会員ＩＤが「００１」、ＨＫＤ購入金額が「２０ＨＫＤ」、ＪＰＹ金額が「２８０円」、ＪＰ購入票数が「２」、端数が「８０円」、端数累計が「１２０円」、繰上票が「１」というレコードが登録される。このレコードは、会員ＩＤ「００１」の香港のファンにより、トランザクションＩＤ「Ｔ２」のトランザクションによって、単勝１番の馬券が購入されたことを示し、香港ドルでの購入金額が２０ＨＫＤであることを示す。また、購入金額２０ＨＫＤを日本円に変換すると２８０円であり、その場合の日本での購入票数が２票であること、馬券購入において為替誤差に伴う端数が８０円であることを示す。更に、単勝１番の買い目に対する端数累計が１２０円であること、端数累計に対する繰上票の数が１であることを示す。
【００８３】
また、例えば、端数管理テーブル１３１には、Ｎｏが「３」、トランザクションＩＤが「Ｔ２’」、会員ＩＤが設定なし（設定なしをハイフン記号「−」で示す）、ＨＫＤ購入金額が設定なし（「−」）、ＪＰＹ金額が「１２０円」、ＪＰ購入票数が「１」、端数が「２０円」、端数累計が「２０円」、繰上票が「０」というレコードが登録される。このレコードは、トランザクションＩＤ「Ｔ２’」のトランザクションによって、単勝１番の馬券が購入されたことを示す。ここで、トランザクションＩＤ「Ｔ２’」のトランザクションは、トランザクションＩＤ「Ｔ２」に付随するトランザクションである。トランザクションＩＤ「Ｔ２’」のトランザクションは、ＧＷサーバ１００による自動投票に相当する。当該Ｎｏ．「３」のレコードでは、ＪＰＹ金額は、Ｎｏ．「２」のレコードにおける端数累計「１２０円」を示す。また、この場合の日本での購入票数が１票であり、端数が２０円であること、単勝１番の買い目に対する端数累計が２０円であり、自動投票完了後の繰上票の数が０であることを示す。
【００８４】
このように、投票部１５１は、端数管理テーブル１３１，１３２，１３３，・・・を用いて、買い目毎に、端数の累計を保持する。
図７は、確定情報の例を示す図である。
【００８５】
確定情報１４１は、ホスト装置２００により生成され、ＧＷサーバ１００に提供される。確定情報１４１は、結果情報記憶部１４０に格納される。確定情報１４１は、着順、枠番、馬番、馬名、タイムおよび着差の項目を含む。
【００８６】
着順の項目には、レースにおける着順が登録される。枠番には、該当の競走馬の枠番が登録される。馬番の項目には、該当の競走馬の馬番が登録される。馬名の項目には、競走馬の名称が登録される。タイムの項目には、該当のレースにおいて該当の競走馬が記録したタイム（スタート地点からゴール地点までの所要時間）が登録される。着差の項目には、先にゴール（入線）した競走馬の鼻先と次にゴールした競走馬の鼻先との間の距離が登録される。着差は、ハナ、アタマ、クビおよび馬身などを単位として表される。
【００８７】
例えば、確定情報１４１には、着順が「１」、枠番が「１」、馬番が「１」、馬名が「馬Ａ」、タイムが「Ｔ１」、着差が設定なし（「−」）というレコードが登録される。このレコードは、該当のレースにおいて、馬名「馬Ａ」の競走馬が１着であり、当該競走馬の枠番が「１」であり、馬番が「１」であり、タイムが「Ｔ１」であったことを示す。１着の競走馬は、先頭なので、着差は設定なし（「−」）である。
【００８８】
確定情報１４１には、２着以降の競走馬に関する情報も登録される。
図８は、払戻金ファイルの例を示す図である。
払戻金ファイル１４２は、レース毎に、ホスト装置２００により生成され、ＧＷサーバ１００に提供される。払戻金ファイル１４２は、結果情報記憶部１４０に格納される。結果処理部１５２は、日本向けの形式（ＪＰ形式と言う）の払戻金ファイル１４２に基づいて、香港向けの形式（ＨＫ形式と言う）の払戻金ファイル１４３を生成し、結果情報記憶部１４０に格納する。
【００８９】
払戻金ファイル１４２は、賭式、買い目、払戻金およびオッズの項目を含む。賭式の項目には、賭式が登録される。買い目の項目には、当該賭式に対応する買い目が登録される。払戻金の項目には、馬券の発売単価である１００円に対する払戻金（配当額）が登録される。オッズの項目には、オッズが登録される。
【００９０】
例えば、払戻金ファイル１４２には、賭式が「単勝」、買い目が「馬番１」、払戻金が「２００円」、オッズが「２．０」というレコードが登録される。このレコードは、単勝１番の的中票に対する払戻金が１００円当たり２００円であり、的中票の購入金額に対する払戻金の比率（オッズ）が２．０であることを示す。
【００９１】
払戻金ファイル１４３も、払戻金ファイル１４２と同様のデータ構造を有する。ただし、払戻金ファイル１４３は、ＨＫ形式であり、例えば、払戻金の項目に、香港での馬券の発売単価（例えば、１０ＨＫＤ）に対する香港ドルでの払戻金が登録される。例えば、払戻金ファイル１４２によれば、単勝１番のオッズは２．０である。したがって、香港での馬券の発売単価１０ＨＫＤに対する払戻金の額は、２０ＨＫＤである。
【００９２】
次に、ＧＷサーバ１００の処理手順を説明する。まず、ＧＷサーバ１００による投票処理の手順を説明する。
図９は、投票処理の例を示すフローチャートである。
【００９３】
以下に示す処理は、投票部１５１が、香港のファンによる馬券購入の情報をＧＷサーバ３００から受け付けるたびに実行される。香港のファンによる馬券購入の情報は、例えば、レースの指定と、賭式と、賭式に応じた投票先の買い目と、香港ドルでの購入金額の情報とを含む。
【００９４】
（Ｓ１０）投票部１５１は、為替計算を行う。具体的には、投票部１５１は、為替レートの情報を提供する所定のサーバから為替レートの情報を取得し、為替情報記憶部１２０に格納する。投票部１５１は、為替レートに基づいて、ＧＷサーバ３００から受け付けた今回の香港ドルでの購入金額（投票額）を、日本円に変換する。
【００９５】
（Ｓ１１）投票部１５１は、日本での購入対象となる馬券の票数と端数とを計算する。票数は、ステップＳ１０の日本円への変換後の金額（変換後金額）を、日本での１票の金額（例えば、１００円）で割った値の整数部である。図９では、当該票数を求める演算を、「整数部（変換後金額÷ＪＰ１票金額）」と表記している。また、端数は、ステップＳ１０の変換後金額を日本での１票の金額（例えば、１００円）で割ったときの余りである。図９では、当該端数を求める演算を、「変換後金額％ＪＰ１票金額」と表記している。ここで、％は剰余演算子である。
【００９６】
（Ｓ１２）投票部１５１は、ステップＳ１１で求めた票数が１以上である（票数≧１）か否かを判定する。票数が１以上である場合、ステップＳ１３に処理が進む。票数が１未満である場合、ステップＳ１４に処理が進む。
【００９７】
（Ｓ１３）投票部１５１は、ステップＳ１１で求めた該当の買い目に対する票数をホスト装置２００に計上する。
（Ｓ１４）投票部１５１は、該当の買い目の端数累計にステップＳ１１で求めた端数を合算する。例えば、投票部１５１は、単勝１番の馬券の購入に対して算出された端数および端数累計を含むレコードを、端数情報記憶部１３０に記憶された端数管理テーブル１３１に記録する。すなわち、投票部１５１は、端数情報記憶部１３０に端数累計を買い目単位に蓄積する。この段階では、記録されたレコードにおける繰上票の項目は設定なしでよい。
【００９８】
（Ｓ１５）投票部１５１は、該当の買い目に対して、繰上票および繰上票に基づく端数を計算する。繰上票は、該当の買い目の端数累計を、日本での１票の金額（例えば、１００円）で割った値の整数部である。図９では、当該繰上票を求める演算を、「整数部（端数累計÷ＪＰ１票金額）」と表記している。投票部１５１は、計算した繰上票の値を、ステップＳ１４で記録したレコードの繰上票の項目に登録する。また、端数は、該当の買い目の端数累計を日本での１票の金額（例えば、１００円）で割ったときの余りである。図９では、当該端数を求める演算を、「端数累計％ＪＰ１票金額」と表記している。
【００９９】
（Ｓ１６）投票部１５１は、繰上票が１以上である（繰上票≧１）か否かを判定する。繰上票が１以上である場合、ステップＳ１７に処理が進む。繰上票が１未満である場合、投票処理が終了する。
【０１００】
（Ｓ１７）投票部１５１は、該当の買い目に対する繰上票（該当の買い目に対する票数１の投票）をホスト装置２００に計上する。ステップＳ１７は、投票部１５１による自動投票に相当する。
【０１０１】
（Ｓ１８）投票部１５１は、該当の買い目の端数累計を０円に設定する。
（Ｓ１９）投票部１５１は、該当の買い目の端数累計にステップＳ１５で求めた端数を合算する。例えば、投票部１５１は、単勝１番の馬券の購入に対して算出された端数および端数累計を含むレコードを、端数情報記憶部１３０に記憶された端数管理テーブル１３１に記録する。ただし、当該レコードは、自動投票を示すレコードであり、会員ＩＤやＨＫＤ購入金額の項目は設定なしとなる。また、当該レコードの繰上票の項目は、「０」である。そして、投票処理が終了する。
【０１０２】
次に、ＧＷサーバ１００による結果処理を説明する。
図１０は、結果処理の例を示すフローチャートである。
（Ｓ２０）結果処理部１５２は、ＪＰ形式の確定情報と払戻金ファイルとをホスト装置２００から受信し、結果情報記憶部１４０に格納する。前述のように、確定情報は、レースの着順の情報を含む。また、払戻金ファイルは、的中票に対する払戻金およびオッズの情報を含む。
【０１０３】
（Ｓ２１）結果処理部１５２は、ＪＰ形式の払戻金ファイルをＨＫ形式に変換する。また、結果処理部１５２は、確定情報についても、ホスト装置４００により参照可能なＨＫ形式に変換してもよい。
【０１０４】
（Ｓ２２）結果処理部１５２は、ＨＫ形式の確定情報と払戻金ファイルとをＧＷサーバ３００を介して、ホスト装置４００に送信する。そして、結果処理が終了する。
なお、ホスト装置４００は、ＨＫ形式の確定情報と払戻金ファイルとを受信する。ホスト装置４００は、払戻金ファイルと会員情報記憶部４１０に記憶された会員投票テーブル４１１とに基づいて、香港の各ファンに対する払戻金の割り当てを行う。
【０１０５】
図１１は、投票の例を示す図である。
図１１（Ａ）は、トランザクションＩＤ「Ｔ１」のトランザクションに対応する投票を示す。まず、会員ＩＤ「００３」のファンが、ユーザ端末８１を操作して、単勝式での買い目「馬番１」を選択し、１票を投票する（ステップＳＴ１０）。香港での１票の発売単価は１０ＨＫＤである。当該投票の情報は、ホスト装置４００によって受け付けられ、ＧＷサーバ３００に送信される。ＧＷサーバ３００は、香港での１票（１０ＨＫＤ）の購入の情報をＧＷサーバ１００に送信する（ステップＳＴ１１）。
【０１０６】
ＧＷサーバ１００は、為替レートの情報を取得し、当該為替レートに基づいて、指定された購入金額１０ＨＫＤを１４０円に変換する。ＧＷサーバ１００は、日本の馬券の発売単価１００円に基づいて、１４０円に対する端数４０円を保持する（ステップＳＴ１２）。ＧＷサーバ１００は、１票（１００円）の投票をホスト装置２００に計上する（ステップＳＴ１３）。
【０１０７】
図１１（Ｂ）は、トランザクションＩＤ「Ｔ２」のトランザクションに対応する投票を示す。まず、会員ＩＤ「００１」のファンがユーザ端末８２を操作して、単勝式での買い目「馬番１」を選択し、２票を投票する（ステップＳＴ２０）。当該投票の情報は、ホスト装置４００によって受け付けられ、ＧＷサーバ３００に送信される。ＧＷサーバ３００は、香港での２票（２０ＨＫＤ）の購入の情報をＧＷサーバ１００に送信する（ステップＳＴ２１）。
【０１０８】
ＧＷサーバ１００は、為替レートの情報を取得し、当該為替レートに基づいて、指定された購入金額２０ＨＫＤを２８０円に変換する。ＧＷサーバ１００は、日本の馬券の発売単価１００円に基づいて、２８０円に対する端数８０円を保持する（ステップＳＴ２２）。ＧＷサーバ１００は、２票（２００円）の投票をホスト装置２００に計上する（ステップＳＴ２３）。
【０１０９】
図１１（Ｃ）は、トランザクションＩＤ「Ｔ２’」のトランザクションに対応する投票（自動投票）を示す。ＧＷサーバ１００は、トランザクションＩＤ「Ｔ２」のトランザクションによる投票の後、単勝１番の端数管理テーブル１３１に基づいて、単勝１番に対応する端数累計が１２０円となり、繰上票が発生したことを検出する。すると、ＧＷサーバ１００は、日本の馬券の発売単価１００円に基づいて、１２０円に対する端数２０円を保持する（ステップＳＴ３０）。ＧＷサーバ１００は、（繰上票分の）１票（１００円）の投票をホスト装置２００に計上する（ステップＳＴ３１）。
【０１１０】
次に払戻の例を説明する。
図１２は、払戻の例を示す図である。
まず、ホスト装置２００は、レース結果に応じて生成したＪＰ形式の確定情報と払戻金ファイルとをＧＷサーバ１００に送信する（ステップＳＴ４０）。ＧＷサーバ１００は、ＪＰ形式の確定情報と払戻金ファイルとをＨＫ形式に変換する（ステップＳＴ４１）。ＧＷサーバ１００は、ＨＫ形式に変換後の確定情報と払戻金ファイルとを、ＧＷサーバ３００に送信する（ステップＳＴ４２）。ＧＷサーバ３００は、ＨＫ形式の確定情報と払戻金ファイルとを受信し、ホスト装置４００に送信する。ホスト装置４００は、ＨＫ形式の確定情報に基づいて、ユーザ端末８１，８２にレース結果を提供する。また、ホスト装置４００は、ＨＫ形式の払戻金ファイルと、各ファンがもつ的中票数とに基づいて、会員毎に払戻金を割り当てる（ステップＳＴ４３）。
【０１１１】
第２の実施の形態で例示したように、ＧＷサーバ１００は、買い目単位の端数累計が、日本（第１の国）における馬券の発売単価に達すると、該当の買い目に対する自動投票を行う。これにより、該当の買い目に対して投票したファンの意思を、ホスト装置２００が管理する当該買い目の投票数に適切に反映させることができる。ホスト装置２００は、端数累計による投票数も計上した上で、オッズの計算を行える。賭金プールに投入される金額が増すことで、各国のファンによる高配当に対する期待感も向上し、コミングリングの魅力を十分に発揮できる。また、香港（第２の国）のファンの意思に反して差額を返還するという非効率な処理を行わずに済む。こうして、ＧＷサーバ１００は、複数国間での馬券の売買を効率良く行うことができる。
【０１１２】
ＧＷサーバ１００によれば、買い目毎の端数を常に１票未満の金額にすることができる。このため、為替誤差による票数の誤差（あるいはオッズの誤差）を最小限に抑えることができる。買い目毎に最終的に残った端数は、運用に応じて処理される。例えば、端数を切り捨てる（オッズに反映させない）、端数を切り上げる（オッズに反映させる）、または、各買い目の残りの端数を全体票の売上に計上する（オッズに反映させる）などの方法が考えられる。
【０１１３】
更に、第２の実施の形態の方法によれば、端数累計の管理をＧＷサーバ１００により管理し、ホスト装置４００は、香港ドルでの票数を管理すればよい。このため、香港側（第２の国の側）の既存システムに対する影響を抑えられるという利点もある。
【０１１４】
［第３の実施の形態］
次に第３の実施の形態を説明する。前述の第２の実施の形態と相違する事項を主に説明し、共通する事項の説明を省略する。
【０１１５】
ここで、第３の実施の形態における馬券売買管理システムの装置構成や装置のハードウェア構成は、第２の実施の形態の馬券管理システムで説明した装置構成およびハードウェア構成と同様である。
【０１１６】
第３の実施の形態では、ＧＷサーバ１００は、香港ドルでの馬券の購入金額と、日本円での馬券の購入金額との差額（端数）を、香港のファン（ユーザ）単位に蓄積し、蓄積した差額合計をファン毎の新たな投票に利用可能にする。第３の実施の形態のＧＷサーバ１００は、複数国間での馬券の売買を管理するので、「馬券売買管理装置」と呼ばれてもよい。
【０１１７】
図１３は、第３の実施の形態の馬券売買管理システムの機能例を示す図である。
ＧＷサーバ１００は、為替情報記憶部１２０、結果情報記憶部１４０、端数情報記憶部１６０およびＧＷ処理部１７０を有する。為替情報記憶部１２０、結果情報記憶部１４０および端数情報記憶部１６０は、ＲＡＭ１０２やＨＤＤ１０３の記憶領域により実現される。ＧＷ処理部１７０は、ＲＡＭ１０２に記憶されたプログラムをＣＰＵ１０１が実行することで実現される。
【０１１８】
ここで、為替情報記憶部１２０および結果情報記憶部１４０に記憶される情報は、第２の実施の形態で説明した情報と同様であるため、説明を省略する。
端数情報記憶部１６０は、端数情報を記憶する。第３の実施の形態の端数情報は、香港ドルで指定された購入金額と、日本円での馬券の購入金額との差額に相当する端数を、各ファンの会員ＩＤに対応付けて（すなわち、ユーザに対応付けて）管理するための情報である。端数情報は、レース毎に作成される。
【０１１９】
ＧＷ処理部１７０は、第３の実施の形態のＧＷ処理を実行する。当該ＧＷ処理は、ＧＷサーバ１００におけるＧＷ処理を実行する。ＧＷ処理は、香港ドルで受け付けた馬券の購入情報を、日本円での馬券の購入情報に変換して、ホスト装置２００，４００に計上する処理、および、ＧＷサーバ３００を介してホスト装置４００に結果情報を提供する処理を含む。ＧＷ処理部１７０は、投票部１７１および結果処理部１７２を有する。
【０１２０】
投票部１７１は、日本（第１の国の一例）で行われる競馬の馬券を香港（第２の国の一例）で購入した場合に、日本と香港の間での為替レートの情報を取得する。投票部１７１は、取得した為替レートの情報に基づいて、香港における馬券の購入金額を日本における馬券の購入金額に変換する。投票部１７１は、変換した日本における馬券の購入金額で購入できる日本における馬券数を特定する。投票部１７１は、特定した馬券数に対応する購入金額と、香港における馬券の購入金額との差額を、馬券を購入したユーザに対応付けて購入毎に蓄積する。投票部１７１は、蓄積した差額の合計が第１の国において馬券を購入できる金額以上となった場合に、ユーザに対し、馬券の購入が可能である旨を通知する。
【０１２１】
より具体的には、投票部１７１は、香港のファンによるレース毎の投票を受け付け、ホスト装置２００，４００に計上する。投票部１７１は、為替情報記憶部１２０に記憶された為替レートの情報に基づいて、香港ドルで受け付けた馬券の購入情報を、日本円での馬券の購入情報に変換し、ホスト装置２００に送信する。ここで、日本での馬券の発売単価は、例えば、１００円である。このため、香港ドルによる購入金額を為替レートに応じて日本円に変換した金額が、１００円の倍数でない（１００円で割り切れない）場合、端数（差額）が生じることになる。投票部１７１は、生じた端数を、ファン毎（すなわち、会員ＩＤ毎）に、端数情報記憶部１６０に保存し、ファン毎に、端数の合計額を計算する。投票部１７１は、香港のあるファンの端数の合計額が日本での馬券の発売単価である１００円以上になると、当該合計額により馬券の購入が可能になったことを、ＧＷサーバ３００を介して、該当のファンに通知する。
【０１２２】
結果処理部１７２は、ホスト装置２００から結果情報を取得し、結果情報記憶部１４０に格納する。結果処理部１７２は、ＧＷサーバ３００を介してホスト装置４００に結果情報を提供する。
【０１２３】
ホスト装置２００は、投票情報記憶部２１０および投票管理部２２０を有する。投票情報記憶部２１０および投票管理部２２０の機能は、第２の実施の形態の同名の機能と同様であるため説明を省略する。
【０１２４】
ＧＷサーバ３００は、中継部３１０を有する。中継部３１０の機能は、第２の実施の形態の同名の機能と同様であるため、説明を省略する。
ホスト装置４００は、会員情報記憶部４４０、ＵＩ処理部４５０および投票管理部４６０を有する。会員情報記憶部４４０は、ホスト装置４００のＲＡＭやＨＤＤの記憶領域により実現される。ＵＩ処理部４５０および投票管理部４６０は、ホスト装置４００のＲＡＭに記憶されたプログラムを、ホスト装置４００のＣＰＵが実行することで実現される。
【０１２５】
会員情報記憶部４４０は、香港のファンの会員情報を記憶する。会員情報は、香港のファンの会員ＩＤに関する情報や、香港のファンによるレース毎の投票数を管理するための情報を含む。
【０１２６】
ＵＩ処理部４５０は、ユーザ端末８１，８２に対してＧＵＩを提供する。ＵＩ処理部４５０は、ＧＷサーバ１００，３００を介して取得したオッズの情報を、ユーザ端末８１，８２に提供する。また、ＵＩ処理部４５０は、レース終了後には、投票管理部４６０から払戻金の割り当て結果を取得し、ユーザ端末８１，８２に提供する。
【０１２７】
投票管理部４６０は、レース終了後に、ＧＷサーバ１００，３００を介して取得した結果情報に基づいて、香港の各ファンに対する香港ドルでの払戻金の割り当てを行う。投票管理部４６０は、払戻金の割り当て結果を、ＵＩ処理部４５０に通知する。ここで、投票管理部４６０は、ＧＷサーバ１００と連携して、ユーザ端末８１，８２から受け付けた香港ドルを日本円に換算した場合における投票数を記録する。すなわち、投票管理部４６０は、ユーザ端末８１，８２から受け付けた香港ドルでの投票数を会員投票テーブルに記録するのではなく、当該香港ドルを日本円に換算した場合における投票数を記録する点が、投票管理部４３０と異なる。
【０１２８】
図１４は、会員投票テーブルの例を示す図である。
会員投票テーブル４４１は、香港のファンによるレース毎の投票数を管理するための情報である。例えば、会員投票テーブル４４１は、投票管理部４６０により作成され、会員情報記憶部４４０に格納される。会員投票テーブル４４１は、投票日、会員ＩＤ、場名、レース番号、賭式、馬番、口数および賭け金の項目を含む。
【０１２９】
投票日の項目には、投票日が登録される。会員ＩＤの項目には、香港のファンの会員ＩＤが登録される。場名の項目には、レースが開催される競馬場の名称が登録される。レース番号の項目には、レース番号が登録される。賭式の項目には、勝馬投票法（賭式）が登録される。馬番の項目には、投票先の馬番または馬番の組合せが登録される（枠番または枠番の組合せも馬番と同様に登録され得る）。口数の項目には、該当の買い目（図１４では、馬番または馬番の組合せを例示）に対する投票数（口数）が登録される。賭け金の項目には、投票数に対応する賭け金の額（日本円単位）が登録される。例えば、日本での１票当たりの馬券の購入金額（単価）を１００円（ＪＰＹ）とする。すると、投票数の価値は、日本円単位で、（１００×投票数）円である。
【０１３０】
例えば、会員投票テーブル４４１には、投票日が「ｙｙｙｙｍｍｄｄ」、会員ＩＤが「００１」、場名が「東京」、レース番号が「１」、賭式が「馬連」、馬番が「１−２」、口数が「１」、賭け金が「１００」というレコードが登録される。このレコードは、投票日「ｙｙｙｙｍｍｄｄ」に、会員ＩＤ「００１」の香港のファンが場名「東京」のレース番号「１」のレースにおいて、賭式「馬連」で買い目として馬番「１−２」を指定した口数「１」の投票を行ったことを示す。また、当該口数「１」の投票に対応する賭け金が「１００」円であることを示す。
【０１３１】
このように、会員投票テーブル４４１には、該当のレースにおいて採用される賭式の買い目毎に、ファン毎の投票数（日本で実際に購入された投票数）が記録される。
なお、会員投票テーブル４４１をホスト装置４００により管理する例を示したが、会員投票テーブル４４１をＧＷサーバ３００により記憶し、管理してもよい。
【０１３２】
図１５は、端数管理テーブルの例を示す図である。
端数管理テーブル１６１は、香港ドルで指定された購入金額と、日本円での馬券の購入金額との差額に相当する端数を、会員ＩＤ単位（すなわち、ユーザ単位）に管理するための端数情報である。
【０１３３】
端数管理テーブル１６１は、Ｎｏ、トランザクションＩＤ、会員ＩＤ、ＨＫＤ購入金額、ＪＰＹ金額、ＪＰ購入票数、端数、端数累計および繰上票の項目を含む。
Ｎｏの項目には、レコードを識別する番号が登録される。トランザクションＩＤの項目には、馬券購入のためのトランザクションの識別情報（トランザクションＩＤ）が登録される。会員ＩＤの項目には、会員ＩＤが登録される。ＨＫＤ購入金額の項目には、香港ドルで指定された馬券の購入金額が登録される。前述のように、一例として、香港における馬券の発売単価は、１０ＨＫＤであるとする。この場合、ＨＫＤ購入金額の項目に設定される値は、１０ＨＫＤの倍数になる。ＪＰＹ金額の項目には、ＨＫＤ購入金額を為替レートに基づいて日本円に変換した金額が登録される。一例として、為替レートを、１０ＨＫＤ＝１４０円とする。なお、端数累計によって追加票が購入されたときのレコードでは、ＨＫＤ購入金額の項目は設定なしとなり、ＪＰＹ金額の項目には、当該端数累計の金額が登録される。ＪＰ購入票数の項目には、ＪＰＹ金額に対して購入可能な馬券の票数が登録される。端数の項目には、ＪＰＹ金額とＪＰ購入票数に応じた購入金額との差額（端数）が登録される。端数累計の項目には、会員ＩＤ毎（すなわち、ユーザ毎）の端数の累計が登録される。繰上票の項目には、端数累計で購入可能な馬券の票数が登録される。
【０１３４】
例えば、端数管理テーブル１６１には、Ｎｏが「１」、トランザクションＩＤが「Ｔ１」、会員ＩＤが「００１」、ＨＫＤ購入金額が「１０ＨＫＤ」、ＪＰＹ金額が「１４０円」、ＪＰ購入票数が「１」、端数が「４０円」、端数累計が「４０円」、繰上票が「０」というレコードが登録される。このレコードは、会員ＩＤ「００１」の香港のファンにより、トランザクションＩＤ「Ｔ１」のトランザクションによって、馬券の購入が受け付けられたことを示し、香港ドルでの購入金額が１０ＨＫＤであることを示す。また、購入金額１０ＨＫＤを日本円に変換すると１４０円であり、その場合の日本での購入票数が１票であること、馬券購入において為替誤差に伴う端数が４０円であることを示す。更に、会員ＩＤ「００１」に対する端数累計が４０円であること、端数累計に対する繰上票の数が０であることを示す。
【０１３５】
また、例えば、端数管理テーブル１６１には、Ｎｏが「２」、トランザクションＩＤが「Ｔ２」、会員ＩＤが「００１」、ＨＫＤ購入金額が「２０ＨＫＤ」、ＪＰＹ金額が「２８０円」、ＪＰ購入票数が「２」、端数が「８０円」、端数累計が「１２０円」、繰上票が「１」というレコードが登録される。このレコードは、会員ＩＤ「００１」の香港のファンにより、トランザクションＩＤ「Ｔ２」のトランザクションによって、馬券の購入が受け付けられたことを示し、香港ドルでの購入金額が２０ＨＫＤであることを示す。また、購入金額２０ＨＫＤを日本円に変換すると２８０円であり、その場合の日本での購入票数が２票であること、馬券購入において為替誤差に伴う端数が８０円であることを示す。更に、会員ＩＤ「００１」に対する端数累計が１２０円であること、端数累計に対する繰上票の数が１であることを示す。
【０１３６】
また、例えば、端数管理テーブル１６１には、Ｎｏが「３」、トランザクションＩＤが「Ｔ３」、会員ＩＤが「００１」、ＨＫＤ購入金額が設定なし（「−」）、ＪＰＹ金額が「１２０円」、ＪＰ購入票数が「１」、端数が「２０円」、端数累計が「２０円」、繰上票が「０」というレコードが登録される。このレコードは、会員ＩＤ「００１」の香港のファンにより、トランザクションＩＤ「Ｔ３」のトランザクションによって、馬券の購入が受け付けられたことを示す。ここで、トランザクションＩＤ「Ｔ３」のトランザクションは、ＧＷサーバ１００による繰上票の発生通知に応じた投票に相当する。当該Ｎｏ．「３」のレコードでは、ＪＰＹ金額は、Ｎｏ．「２」のレコードにおける端数累計「１２０円」を示す。また、この場合の日本での購入票数が１票であり、端数が２０円であること、会員ＩＤ「００１」に対する端数累計が２０円であり、投票完了後の繰上票の数が０であることを示す。
【０１３７】
このように、投票部１７１は、端数管理テーブル１６１を用いて、会員ＩＤ毎（ユーザ毎）に、端数の累計を保持する。なお、投票部１７１は、会員ＩＤ毎に異なる端数管理テーブルを用いて、会員ＩＤ毎の端数累計を管理してもよい。
【０１３８】
図１６は、投票処理の例を示すフローチャートである。
以下に示す処理は、投票部１７１が、香港のファンによる馬券購入の情報をＧＷサーバ３００から受け付けるたびに実行される。香港のファンによる馬券購入の情報は、例えば、レースの指定と、賭式と、賭式に応じた投票先の買い目と、香港ドルでの購入金額の情報とを含む。
【０１３９】
（Ｓ３０）投票部１７１は、為替計算を行う。具体的には、投票部１７１は、為替レートの情報を提供する所定のサーバから為替レートの情報を取得し、為替情報記憶部１２０に格納する。投票部１７１は、為替レートに基づいて、ＧＷサーバ３００から受け付けた今回の香港ドルでの購入金額（投票額）を、日本円に変換する。
【０１４０】
（Ｓ３１）投票部１７１は、日本での購入対象となる馬券の票数と端数とを計算する。票数は、ステップＳ３０の日本円への変換後の金額（変換後金額）を、日本での１票の金額（例えば、１００円）で割った値の整数部である。図１６では、当該票数を求める演算を、「整数部（変換後金額÷ＪＰ１票金額）」と表記している。また、端数は、ステップＳ３０の変換後金額を日本での１票の金額（例えば、１００円）で割ったときの余りである。図１６では、当該端数を求める演算を、「変換後金額％ＪＰ１票金額」と表記している。ここで、％は剰余演算子である。
【０１４１】
（Ｓ３２）投票部１７１は、ステップＳ３１で求めた票数が１以上である（票数≧１）か否かを判定する。票数が１以上である場合、ステップＳ３３に処理が進む。票数が１未満である場合、ステップＳ３４に処理が進む。
【０１４２】
（Ｓ３３）投票部１７１は、ステップＳ３１で求めた該当の買い目に対する票数をホスト装置２００に計上する。また、投票部１７１は、ステップＳ３１で求めた該当の買い目に対する票数を、ＧＷサーバ３００を介して、ホスト装置４００に計上する。ホスト装置４００では、該当の会員ＩＤについて、当該会員ＩＤにより選択された賭式の買い目に対する投票数（会員投票テーブル４４１の投票数）が更新される。
【０１４３】
（Ｓ３４）投票部１７１は、該当の会員ＩＤの端数累計にステップＳ３１で求めた端数を合算する。例えば、投票部１７１は、会員ＩＤに対して算出された端数および端数累計を含むレコードを、端数情報記憶部１６０に記憶された端数管理テーブル１６１に記録する。すなわち、投票部１７１は、端数情報記憶部１６０に端数累計を会員ＩＤ（ユーザ）単位に蓄積する。この段階では、記録されたレコードにおける繰上票の項目は設定なしでよい。
【０１４４】
（Ｓ３５）投票部１７１は、該当の会員ＩＤに対して、繰上票を計算する。繰上票は、該当の会員ＩＤに対応する端数累計を、日本での１票の金額（例えば、１００円）で割った値の整数部である。図１６では、当該繰上票を求める演算を、「整数部（端数累計÷ＪＰ１票金額）」と表記している。投票部１７１は、計算した繰上票の値を、ステップＳ３４で記録したレコードの繰上票の項目に登録する。
【０１４５】
（Ｓ３６）投票部１７１は、繰上票が１以上である（繰上票≧１）か否かを判定する。繰上票が１以上である場合、ステップＳ３７に処理が進む。繰上票が１未満である場合、投票処理が終了する。
【０１４６】
（Ｓ３７）投票部１７１は、該当の会員ＩＤの会員に対して繰上票の購入可能を通知する。例えば、投票部１７１は、該当の会員に対して、繰上票の購入可能を示す電子メールを送信してもよい。あるいは、投票部１７１は、当該電子メールの送信指示を、ＧＷサーバ３００を介して、ホスト装置４００に送信し、ホスト装置４００により当該電子メールを送信させてもよい。また、例えば、投票部１７１は、該当の会員が利用するユーザ端末に、繰上票の購入可能を示す画面を表示させる指示を、ＧＷサーバ３００を介して、ホスト装置４００に送信してもよい。
【０１４７】
（Ｓ３８）投票部１７１は、ステップＳ３７の通知に応じて、香港のファンによる繰上票の購入を受け付けたか否かを判定する。繰上票の購入を受け付けた場合、ステップＳ３９に処理が進む。繰上票の購入を受け付けない場合、投票処理が終了する。なお、繰上票の購入時には、任意の賭式の任意の買い目が選択されてよい。また、繰上票の購入は、今回、該当の会員が選択したレースと同一のレースでもよいし、異なるレースに対して行われもよい。
【０１４８】
（Ｓ３９）投票部１７１は、ステップＳ３８で受け付けた購入票をホスト装置２００に計上し、該当の会員の端数累計から購入票相当の金額を減算した額により、端数と端数累計と繰上票とを更新する。例えば、１票の金額が１００円であれば、繰上票が１票購入されたとき、端数累計から１００円が減算された額が、端数管理テーブル１６１における該当の会員ＩＤの端数と端数累計の項目に設定される。同様に、繰上票が２票購入されたとき、端数累計から２００円が減算された額が、端数管理テーブル１６１における該当の会員ＩＤの端数と端数累計の項目に設定される。また、更新後の端数累計を日本での１票の金額（例えば、１００円）で割った値の整数部が、更新後の繰上票の値となる。更に、投票部１７１は、ステップＳ３８で受け付けた購入票を、ＧＷサーバ３００を介して、ホスト装置４００に計上する。ホスト装置４００では、該当の会員ＩＤについて、当該会員ＩＤにより選択された賭式の買い目に対する投票数（会員投票テーブル４４１の投票数）が更新される。そして、投票処理が終了する。
【０１４９】
なお、投票部１７１は、ステップＳ３６〜Ｓ３９の処理を、投票処理とは非同期のタイミングで、実行してもよい。例えば、投票部１７１は、ステップＳ３５〜Ｓ３９の処理を、会員ＩＤ毎に、定期的なタイミングで実行し、香港の各ファンへの通知を行うように、ホスト装置４００に促すことも考えられる。また、ホスト装置４００は、ＧＷサーバ１００の指示に応じて、香港のファンがホスト装置４００にログインしたタイミングや馬券の購入画面をユーザ端末８１，８２に表示させたタイミングなどに、繰上票の購入可能をユーザ端末８１，８２に通知してもよい。
【０１５０】
また、レースの結果が確定された後、結果処理部１７２は、ホスト装置２００から結果情報を取得し、ＧＷサーバ３００を介して、ホスト装置４００に結果情報を提供する。結果情報は、レースの確定情報と、払戻金ファイルとを含む。この場合、結果情報は、ＪＰ形式のままでもよい。ホスト装置４００は、結果情報を受信すると、会員投票テーブル４４１と結果情報に含まれる払戻金ファイルとに基づいて、香港の各ファンに対する払戻金の割り当てを行う。
【０１５１】
第３の実施の形態のＧＷサーバ１００によれば、複数国間での馬券の売買を効率良く行うことができる。
例えば、コミングリングにより、賭金プールを統合する場合、ＧＷサーバ１００において、第２の国のユーザにより指定された第２の国の通貨での購入金額と第１の国の通貨での馬券の購入金額とでは、為替レートによる差額が生じ得る。そこで、このような差額の取り扱いが問題となる。例えば、発生した差額を第２の国のユーザに全て返還することも考えられる。しかし、第２の国のユーザにとっては、第２の国の通貨によって所望の購入金額を指定したにも拘わらず、そのうちの一部が受け付けられなかったことになり、競技への期待や興味の低下を招く可能性がある。また、指定した購入金額により投票したいという第２の国のユーザの意思に反して、差額の返還を行うという非効率な処理をＧＷサーバ３００やホスト装置４００に強いることにもなる。更に、発生した差額をプールできず、コミングリングの魅力を十分に発揮できない可能性もある。
【０１５２】
第３の実施の形態で例示したように、ＧＷサーバ１００は、香港のファン（ユーザ）単位の端数累計（差額の合計）が、日本（第１の国）における馬券の発売単価に達すると、該当のファンに対して、繰上票の購入が可能になったことを通知する。これにより、ファンに対して、為替誤差の蓄積によって生じた端数累計により、追加の馬券が購入可能であることを適切に通知できる。香港のファンは、自身で端数累計を管理せずに済み、馬券の売買を効率良く行えるようになる。こうして、当該端数合計による馬券の購入を促し、香港のファンによる投票が増すことで、ホスト装置２００は、端数合計による投票数も計上した上で、オッズの計算を行える。賭金プールに投入される金額が増すことで、各国のファンによる高配当に対する期待感も向上し、コミングリングの魅力を十分に発揮できる。
【０１５３】
なお、第３の実施の形態のＧＷサーバ１００において管理される香港のファン毎の端数累計が最終的に繰上票の購入に利用されないことも考えられる。この場合、ＧＷサーバ１００は、所定のタイミング（例えば、１日のレースが全て完了したタイミングや、ファンにより要求されたタイミング）で、残った端数累計に相当する金額を香港ドルに変換して、該当のファンに返還することが考えられる。このようにすれば、馬券の購入毎に返還するよりも、返還処理を実行する回数を減らし、馬券の売買を一層効率良く行うことができる。
【０１５４】
また、第２，第３の実施の形態では、第１の国として日本を例示し、第２の国として香港を例示したが、第１，第２の国はこれらに限定されるものではなく他の国でもよい。
更に、第１の実施の形態の情報処理は、処理部１２にプログラムを実行させることで実現できる。また、第２，第３の実施の形態の情報処理は、ＣＰＵ１０１にプログラムを実行させることで実現できる。プログラムは、コンピュータ読み取り可能な記録媒体１１３に記録できる。
【０１５５】
例えば、プログラムを記録した記録媒体１１３を配布することで、プログラムを流通させることができる。また、プログラムを他のコンピュータに格納しておき、ネットワーク経由でプログラムを配布してもよい。コンピュータは、例えば、記録媒体１１３に記録されたプログラムまたは他のコンピュータから受信したプログラムを、ＲＡＭ１０２やＨＤＤ１０３などの記憶装置に格納し（インストールし）、当該記憶装置からプログラムを読み込んで実行してもよい。
【符号の説明】
【０１５６】
１０  馬券売買管理装置
１１  記憶部
１２  処理部
２０，４０  ホスト装置
３０  ゲートウェイ
５０  管理テーブル
【図１】
2019212065.tif 000003
【図２】
2019212065.tif 000004
【図３】
2019212065.tif 000005
【図４】
2019212065.tif 000006
【図５】
2019212065.tif 000007
【図６】
2019212065.tif 000008
【図７】
2019212065.tif 000009
【図８】
2019212065.tif 000010
【図９】
2019212065.tif 000011
【図１０】
2019212065.tif 000012
【図１１】
2019212065.tif 000013
【図１２】
2019212065.tif 000014
【図１３】
2019212065.tif 000015
【図１４】
2019212065.tif 000016
【図１５】
2019212065.tif 000017
【図１６】
2019212065.tif 000018