JP5745199B1 - 投票券販売仲介装置、投票券販売仲介方法、および、投票券販売仲介装置用プログラム - Google Patents

Abstract

投票券を購入した第１ユーザと当該購入済み投票券の賭式および買い目とを特定可能な情報を含む、当該購入済み投票券のキャンセル依頼を、第１ユーザから受け付け（Ｓ１）、キャンセル依頼を受け付けた後に、第１ユーザからキャンセル依頼を受け付けた投票券の賭式および買い目と同じ賭式および買い目の投票券の購入を第２ユーザから受け付けた場合、第１ユーザからキャンセル依頼を受け付けた投票券の金額と第２ユーザから受け付けた投票券の金額とに応じて、第１ユーザの口座に入金して、入金する金額がゼロでない場合に、キャンセル依頼が成立した旨の情報を、第１ユーザ用に出力する（Ｓ３、Ｓ４、Ｓ５、Ｓ６、Ｓ９）。

Description

本発明は、公営競技の投票券の販売を行う投票券販売仲介装置、投票券販売仲介方法、および、投票券販売仲介装置用プログラムの技術分野に関する。

競馬や競輪といった公営競技の投票券の購入に関して、ネットワークに接続する端末から投票券を購入したり、レースの情報を取得したりと、様々なサービスが受けられるようになっている。例えば、特許文献１では、レースが開始される前に、予約した投票内容の変更や取り消しができる予約投票管理サーバが開示されている。

特開２００５−３２２１５１号公報

しかし、投票券を取り消しできるのは、主催者のホストシステムに直接アクセスできる場合に限られるため、ネット販売や場外馬券売り場の等の端末では、取り消しすることが不可能であった。

本発明は、このような問題に鑑みてなされたものであり、その課題の一例は、主催者のホストシステムに取り消し依頼せずに、投票券の取り消しを可能とする投票券販売仲介装置等を提供することを目的とする。

上記課題を解決するために、請求項１に記載の発明は、公営競技の投票券の購入をユーザ端末から受け付けて、当該投票券を購入したユーザの名義の情報を含まない投票券購入情報を当該公営競技が主催する主催者サーバ装置に送信する投票券販売仲介装置において、投票券を購入した第１ユーザと当該購入済み投票券の賭式および買い目とを特定可能な情報を含む、当該購入済み投票券のキャンセル依頼を、前記第１ユーザのユーザ端末から受け付けるキャンセル受付手段と、前記キャンセル依頼を受け付けた後であって投票券購入締め切りが到来する前に、前記第１ユーザからキャンセル依頼を受け付けた投票券の賭式および買い目と同じ賭式および買い目の投票券の購入を第２ユーザから受け付けた場合、前記第１ユーザから前記キャンセル依頼を受け付けた投票券の金額と前記第２ユーザから受け付けた投票券の金額とに応じて前記第１ユーザの口座に入金する入金手段と、前記決定した返金する金額がゼロでない場合に、前記キャンセル依頼のうち前記入金される金額に応じたキャンセルが成立した旨の情報を、前記第１ユーザ用に出力する出力手段と、を備えたことを特徴とする。

従って、第１ユーザからのキャンセル依頼を受け付けた投票券の金額と、第２ユーザから受け付けた同じ賭式および買い目の投票券の金額とに応じて、第１ユーザの口座に返金できるので、主催者のホストシステムに取り消し依頼せずに、投票券の取り消しを行うことができる。

請求項２に記載の発明は、請求項１に記載の投票券販売仲介装置において、前記第１ユーザから受け付けた前記キャンセル依頼を受け付けた投票券の金額が、前記第２ユーザから受け付けた前記同じ賭式および買い目の投票券の金額より少ない場合、これらの購入金額の差額に基づいた前記名義の情報を含まない投票券購入情報を、前記主催者サーバ装置に送信すると決定する送信情報決定手段を更に備えたことを特徴とする。

この場合、差額のみを送信して、主催者のホストシステムに取り消し依頼せずに、キャンセルが実現できる。また、第２ユーザの購入分、主催者側に通知する必要がないので、トラフィックの減少を図ることができる。

請求項３に記載の発明は、請求項１または請求項２に記載の投票券販売仲介装置において、前記第１ユーザから受け付けた前記キャンセル依頼を受け付けた投票券の金額が、前記第２ユーザから受け付けた前記同じ賭式および買い目の投票券の金額より大きい場合、前記入金手段は、前記第２ユーザから受け付けた前記同じ賭式および買い目の投票券の金額分、前記第１ユーザの口座に入金することを特徴とする。

この場合、第２ユーザからの購入分の投票券購入情報を主催者側に送信する必要が無く、第２ユーザの購入分、第１ユーザに一部返金することにより、部分的にキャンセルすることができる。

請求項４に記載の発明は、請求項３に記載の投票券販売仲介装置において、前記同じ賭式および買い目の投票券に対して、前記第１ユーザを含む複数のユーザから受け付けた前記キャンセル依頼における投票券の金額を合計した額が、前記第２ユーザから受け付けた前記同じ賭式および買い目の投票券の金額より大きい場合、前記入院手段は、前記第２ユーザから受け付けた前記同じ賭式および買い目の投票券の購入金額において、当該複数のユーザから受け付けたキャンセル依頼の各時刻に応じて、当該各ユーザの口座に入金することを特徴とする。

この場合、キャンセルを依頼した各ユーザに対して、キャンセル依頼の時刻に応じた公平感がある返金により、部分的なキャンセルを行うことができる。

請求項５に記載の発明は、請求項３に記載の投票券販売仲介装置において、前記同じ賭式および買い目の投票券に対して、前記第１ユーザを含む複数のユーザから受け付けた前記キャンセル依頼における投票券の金額を合計した額が、前記第２ユーザから受け付けた前記同じ賭式および買い目の投票券の金額より大きい場合、前記入金手段は、前記第２ユーザから受け付けた前記同じ賭式および買い目の投票券の金額において、当該複数のユーザにおける各ユーザのユーザ情報に応じて、当該各ユーザの口座に入金することを特徴とする。

この場合、キャンセルを依頼した各ユーザに対して、各ユーザのユーザ情報に応じた所定の基準に従った返金を行うことで、公平感がある部分的なキャンセルを行うことができる。

請求項６に記載の発明は、公営競技の投票券の購入をユーザ端末から受け付けて、当該投票券を購入したユーザの名義の情報を含まない投票券購入情報を当該公営競技が主催する主催者サーバ装置に送信する投票券販売仲介装置の投票券販売仲介方法において、投票券を購入した第１ユーザと当該購入済み投票券の賭式および買い目とを特定可能な情報を含む、当該購入済み投票券のキャンセル依頼を、前記第１ユーザから受け付けるキャンセル受付ステップと、前記キャンセル依頼を受け付けた後であって投票券購入締め切りが到来する前に、前記第１ユーザからキャンセル依頼を受け付けた投票券の賭式および買い目と同じ賭式および買い目の投票券の購入を第２ユーザから受け付けた場合、前記第１ユーザから前記キャンセル依頼を受け付けた投票券の金額と前記第２ユーザから受け付けた投票券の金額とに応じて、前記第１ユーザの口座に入金する入金ステップと、前記入金する金額がゼロでない場合に、前記キャンセル依頼のうち前記入金される金額に応じたキャンセルが成立した旨の情報を、前記第１ユーザ用に出力する出力ステップと、を含むことを特徴とする。

請求項７に記載の発明は、公営競技の投票券の購入をユーザ端末から受け付けて、当該投票券を購入したユーザの名義の情報を含まない投票券購入情報を当該公営競技が主催する主催者サーバ装置に送信する投票券販売仲介装置用プログラムにおいて、コンピュータを、投票券を購入した第１ユーザと当該購入済み投票券の賭式および買い目とを特定可能な情報を含む、当該購入済み投票券のキャンセル依頼を、前記第１ユーザから受け付けるキャンセル受付手段、前記キャンセル依頼を受け付けた後であって投票券購入締め切りが到来する前に、前記第１ユーザからキャンセル依頼を受け付けた投票券の賭式および買い目と同じ賭式および買い目の投票券の購入を第２ユーザから受け付けた場合、前記第１ユーザから前記キャンセル依頼を受け付けた投票券の金額と前記第２ユーザから受け付けた投票券の金額とに応じて、前記第１ユーザの口座に入金する入金手段、および、前記入金する金額がゼロでない場合に、前記キャンセル依頼のうち前記入金される金額に応じたキャンセルが成立した旨の情報を、前記第１ユーザ用に出力する出力手段として機能させることを特徴とする。

本発明によれば、第１ユーザからのキャンセル依頼を受け付けた投票券の金額と、第２ユーザから受け付けた同じ賭式および買い目の投票券の金額とに応じて、第１ユーザの口座に返金できるので、主催者のホストシステムに取り消し依頼せずに、投票券の取り消しを行うことができる。

本発明の実施形態に係る投票券販売仲介システムの概要構成例を示す模式図である。 図１の投票券販売仲介サーバと、主催者の主催者サーバと端末装置との関係を示す模式図である。 図１の投票券販売仲介サーバの概要構成の一例を示すブロック図である。 図３の投票券販売仲介サーバの購入投票券データベースの一例を示す模式図である。 図１の主催者サーバの概要構成の一例を示すブロック図である。 図１の端末装置の概要構成の一例を示すブロック図である。 図１の投票券販売仲介システムの動作例を示すフローチャートである。 図１の端末装置の表示の一例を示す模式図である。 投票券のキャンセル後における他のユーザの投票券の購入の一例を示す模式図である。 複数人の投票券のキャンセル後における他のユーザの投票券の購入の一例を示す模式図である。

以下、図面を参照して本発明の実施形態について説明する。なお、以下に説明する実施の形態は、投票券販売仲介システムに対して本発明を適用した場合の実施形態である。

［１．投票券販売仲介システムの構成および機能概要］
まず、本発明の一実施形態に係る投票券販売仲介システムの構成および概要機能について、図１および図２を用いて説明する。

図１は、本実施形態に係る投票券販売仲介システム１の概要構成例を示す模式図である。図２は、投票券販売仲介サーバ１０と、主催者の主催者サーバ２０と端末装置３０との関係を示す模式図である。

図１に示すように、投票券販売仲介システム１は、競馬、競輪、競艇等の公営競技における投票券に関する情報を提供し投票券の販売の仲介を行う投票券販売仲介サーバ１０（投票券販売仲介装置の一例）と、公営競技を主催または運営し、投票券を発行する主催者側の主催者サーバ２０と、投票券販売仲介サーバ１０からの情報の提供を受けて、ユーザが競技（レース）に対して投票券の購入を行うための端末装置３０（ユーザ端末の一例）と、を備えている。

投票券販売仲介サーバ１０と、主催者サーバ２０と、端末装置３０とは、ネットワーク３により接続され、通信プロトコル（例えば、ＴＣＰ／ＩＰ）により、データの送受信が可能になっている。なお、ネットワーク３は、例えば、インターネット、専用通信回線（例えば、ＣＡＴＶ（Community Antenna Television）回線）、移動体通信網（基地局等を含む）、および、ゲートウェイ等により構築されている。なお、投票券販売仲介サーバ１０と、主催者サーバ２０とは、セキュリティ向上のため専用回線で接続されていてもよい。

投票券販売仲介サーバ１０は、主催元が発表するレースのオッズや、レース場の状態や、レースに出場する馬や自転車やボート等の競争体の情報や、レースの結果等の情報を主催者サーバより受信する。また、投票券販売仲介サーバ１０は、端末装置３０におけるユーザの投票券の購入を支援する情報を端末装置３０に出力する。また、投票券販売仲介サーバ１０は、投票券の購入の受付や、各端末装置３０に対して的中した投票券に対する払い戻し等の処理を行う。このように、投票券販売仲介サーバ１０は、競馬サイト等の公営競技のサイトを運営のためのサーバである。公営競技の投票券の購入を複数の端末装置３０から受け付けて、当該投票券を購入したユーザの名義の情報を含まない投票券購入情報を、公営競技が主催する主催者サーバ２０に送信する。

主催者サーバ２０は、投票券販売仲介サーバ１０や、レース場や投票券発売所に設置された端末装置等に対して、投票券の発行処理をしたり、発行された投票券に基づきオッズを集計して発表処理したりする。

ユーザの端末装置３０は、複数存在し、投票券を購入するための情報を表示し、購入する投票券に関する情報を投票券販売仲介サーバ１０に送信する。

図２に示すように、各端末装置３０は、投票券販売仲介サーバ１０に接続して、データの送受信ができるようになっている。また、投票券販売仲介サーバ１０が主催者サーバ２０に接続してデータの送受信ができるようになっている。投票券販売仲介サーバ１０は、各端末装置３０から、各端末装置３０のユーザＩＤ（ユーザの名義の一例）と共に投票券の購入を受け付け、レース、賭式、および、買い目毎に集計し、名義情報が無いサマリーデータを生成する。投票券販売仲介サーバ１０は、生成したサマリーデータを、主催者サーバ２０に送信する。

また、主催者サーバ２０は、投票券販売仲介サーバ１０からのサマリーデータを含む、不特定多数の投票者からの投票券購入総額によってオッズを算出する。従って、投票券販売仲介サーバ１０が送信するサマリーデータには、誰がいくら買ったかという情報は不要であるので、ユーザＩＤ等の名義情報が含まれない。

主催者サーバ２０は、ユーザＩＤで特定されるユーザからの投票を管理するのではなく、投票券販売仲介サーバ１０からのサマリーデータを含む、競馬場や場外馬券場で不特定多数の投票者から投票券購入を受け付けて、オッズ等の算出を行っている。

ここで、オッズとは配当率（賭金に対する倍率）であり、レース開始前に概算オッズとして逐次発表されるものと、投票券発売締切以降に確定オッズ（最終的に確定した最終オッズ）として発表されるものとがある。また、投票券の投票券種別（投票法の種類、いわゆる賭式）毎、レースに出場する競争体のうち１以上の競争体を指定する買い目（競争体の競争体番号により構成される買い目）毎にオッズがある。すなわち、賭式と買い目とに対応した投票券毎にオッズがある。なお、レースの競争体には、馬の騎手や、自転車やボートを操縦する選手を含めてもよい。

また、投票券の賭式の一例として、１着になると予想される競争体を指定する単勝、１着および２着になると予想される競争体を順番通りに指定する馬単等の競争体番号連勝単式、１着、２着、３着になると予想される競争体を順番通りに指定する３連単、１着から３着、または、１着から２着に入ると予想される競争体を１つ指定する複勝、１着から２着に入ると予想される競争体を２つ指定する馬連等の普通競争体番号連勝複式、１着から２着に入ると予想される競争体が入っている枠を指定する枠連、１着から３着に入ると予想される競争体を２つ指定するワイド、１着から３着に入ると予想される競争体を３つ指定する３連複等が挙げられる。

また、買い目として、単勝の場合、１着と予想される競争体の番号、馬単の場合、１着および２着になると予想される競争体の番号、３連単の場合、１着、２着、３着になると予想される競争体の番号、馬連の場合、２つの指定された競争体番号の組み、枠連の場合、２つの指定された枠番号（枠の中に入る競争体の競争体番号が対応している）の組み、ワイドの場合、２つの指定された競争体番号の組み、３連複の場合、３つの指定された競争体番号の組み、連勝の場合、１つの指定された競争体番号が挙げられる。

［２．各サーバの構成および機能］
（２．１ 投票券販売仲介サーバ１０の構成および機能）
次に、投票券販売仲介サーバ１０の構成および機能について、図３を用いて説明する。

図３は、投票券販売仲介サーバ１０の概要構成の一例を示すブロック図である。図４は、投票券販売仲介サーバ１０の購入投票券データベースの一例を示す模式図である。

図３に示すように、コンピュータとして機能する投票券販売仲介サーバ１０は、通信部１１と、記憶部１２と、入出力インターフェース部１３と、システム制御部１４と、を備えている。そして、システム制御部１４と入出力インターフェース部１３とは、システムバス１５を介して接続されている。

通信部１１は、ネットワーク３に接続して主催者サーバ２０と端末装置３０等との通信状態を制御し、さらに、ローカルエリアネットワークに接続して、ローカルエリアネットワーク上の他のサーバとデータの送受信を行う。

記憶部１２は、例えば、ハードディスクドライブ等により構成されており、オペレーティングシステムおよびサーバプログラム等の各種プログラムや、ユーザに提供するレースに関する情報を提示するためのウェブページの画面データ等を記憶する。なお、各種プログラムは、例えば、他のサーバ装置等からネットワーク３を介して取得されるようにしてもよいし、記録媒体に記録されてドライブ装置（図示せず）を介して読み込まれるようにしてもよい。

また、記憶部１２には、各競技場で開催されるレースに関するレース情報等を、主催者サーバ２０から受信して記憶するレース情報データベース１２ａ（以下「レース情報ＤＢ１２ａ」とする。）と、ユーザにより購入された投票券の情報を記憶する購入投票券データベース１２ｂ（以下「購入投票券ＤＢ１２ｂ」とする。）と、ユーザから投票券購入のための資金の入金情報を端末装置３０から受け付けて記憶する（以下「口座ＤＢ１２ｃ」とする。）と、会員に関する情報を記憶する会員データベース１２ｄ（以下「会員ＤＢ１２ｄ」とする。）等が構築されている。

レース情報ＤＢ１２ａ（記憶手段の一例）には、主催者サーバ２０から取得したオッズ情報、レースの結果等のレース情報が、各競技場で開催されるレースを特定するレースＩＤに関連付けられ記憶される。

ここで、レース情報の一例として、レース開始前の概算オッズ情報の他に、競技場名、競技場の天候、馬場がダート、芝であるといった競技場の種類等のレース条件、開催されるレース名、レースに出場する馬の名前、年齢、体重や、自転車やボートの種類等の競争体の状態（馬の騎手や、自転車やボートの選手等の名前、年齢、体重等も含む）等が挙げられる。さらに、レース情報として投票券の発売が終了した場合の最終オッズの情報や、レースが終了して順位が確定した場合のレースの順位、１着と２着とのタイム差等も挙げられる。

さらに、レース情報ＤＢ１２ａには、投票券種別毎および競争体パターン毎のオッズ情報が、レースＩＤに関連付けられ記憶される。

購入投票券ＤＢ１２ｂには、図４に示すように、投票券を購入したユーザのユーザＩＤに関連付けられて、購入した投票券のレースＩＤ、賭式、買い目、購入金額、購入時刻、キャンセルフラグ、キャンセル申込み時刻、返金額等が記憶されている。

なお、買い目の欄に記載されるデータには、賭式が馬単で、１着になると予想される競争体の競争体番号”1”、２着になると予想される競争体の競争体番号”2”の場合、”1-2”となる。また、賭式が馬連で、１着および２着になると予想される競争体の競争体番号の組み（競争体の競争体番号”1”と競争体番号”2”との組み）も、”1-2”とする。

また、キャンセルフラグは、キャンセルを受け付けた賭式の掛け目がＯＮとなる。返金額は、キャンセルを受け付けた後、同じレースにおいて同じ賭式および買い目で、他のユーザから購入の注文があり、キャンセルが成立した金額が記載される。また、キャンセル依頼の残金は、購入金額−返金額である。

口座ＤＢ１２ｃには、ユーザが投票券を購入するための資金が入金され、その金額がユーザＩＤに関連付けられ記憶される。例えば、ユーザは、レースが開催される日に購入する投票券の予算を決めて、投票券を買う前にインターネット上の銀行等から、端末装置３０によって予算分の金額を口座ＤＢ１２ｃに振り込みをする。また、口座ＤＢ１２ｃには、投票券のキャンセル依頼が成立した場合、キャンセルが成立した金額に応じて入金される。また、投票券が的中した場合、口座ＤＢ１２ｃには払戻金が入金される。また、ユーザが投票券を購入すると、口座ＤＢ１２ｃにおけるユーザの残高から購入の金額が差し引かれる。さらに、口座ＤＢ１２ｃには、ユーザによる銀行等からの入金と、払戻金による入金との累計である累計入金額が記憶される。

会員ＤＢ１２ｄには、会員登録されたユーザ（競馬サイトの利用者）のユーザＩＤ、名称、住所、電話番号、メールアドレス、職業、趣味、購買履歴、ユーザの関心があるテーマやジャンル等のユーザ情報が登録されている。また、会員ＤＢ１２ｄには、ユーザが端末装置３０から競馬サイトにログインする際に必要な、ユーザＩＤ、ログインＩＤ、および、パスワードが登録されている。ここで、ログインＩＤおよびパスワードは、ログイン処理（ユーザの認証処理）に使用されるログイン情報である。

また、記憶部１２には、競馬サイトからの情報を端末装置３０に表示させるために、ＨＴＭＬ（HyperText Markup Language）、ＸＭＬ（Extensible Markup Language）等のマークアップ言語等により記述されたウェブページのファイル等が記憶されている。

入出力インターフェース部１３は、通信部１１および記憶部１２とシステム制御部１４との間のインターフェース処理を行う。

システム制御部１４は、ＣＰＵ（Central Processing Unit）１４ａ、ＲＯＭ（Read Only Memory）１４ｂ、ＲＡＭ（Random Access Memory）１４ｃ等により構成されている。システム制御部１４は、ＣＰＵ１４ａがＲＯＭ１４ｂや記憶部１２に記憶された各種プログラムを読み出し実行することにより、投票券販売仲介のための処理等を行う。

（２．２ 主催者サーバ２０の構成および機能）
次に、主催者サーバ２０の構成および機能について、図５を用いて説明する。
図５は、主催者サーバ２０の概要構成の一例を示すブロック図である。

図５に示すように、主催者サーバ２０は、通信部２１と、記憶部２２と、入出力インターフェース部２３と、システム制御部２４と、を備え、システム制御部２４と入出力インターフェース部２３とは、システムバス２５を介して接続されている。なお、主催者サーバ２０の構成および機能は、投票券販売仲介サーバ１０の構成および機能とほぼ同じであるので、投票券販売仲介サーバ１０の各構成や各機能において、異なるところを中心に説明する。

通信部２１は、ネットワーク３やローカルエリアネットワーク等を通して、端末装置３０や投票券販売仲介サーバ１０等と通信状態を制御等するようになっている。

記憶部２２には、レースに関する情報等が記憶されている。

システム制御部２４は、ＣＰＵ２４ａ、ＲＯＭ２４ｂ、ＲＡＭ２４ｃ等により構成されている。そして、システム制御部２４は、ＣＰＵ２４ａが、ＲＯＭ２４ｂや記憶部２２に記憶された各種プログラムを読み出し実行することにより、投票券販売仲介サーバ１０にオッズ情報を送信する処理等を行う。

（２．３ 端末装置３０の構成および機能）
次に、端末装置３０の構成および機能について、図６を用いて説明する。
図６は、端末装置３０の概要構成の一例を示すブロック図である。

図６に示すように、コンピュータとして機能する端末装置３０は、例えば、パーソナルコンピュータやスマートフォンを含む携帯型無線電話機やＰＤＡ等の携帯端末であり、通信部３１と、記憶部３２と、表示部３３と、操作部３４と、入出力インターフェース部３５と、システム制御部３６とを備えている。そして、システム制御部３６と入出力インターフェース部３５とは、システムバス３７を介して接続されている。

通信部３１は、ネットワーク３を通して、投票券販売仲介サーバ１０等と通信を制御する。なお、端末装置３０が携帯端末装置の場合、ネットワーク３の移動体通信網に接続するために、通信部３１は、無線通信機能を有する。

記憶部３２は、例えば、ハードディスクドライブ等からなり、オペレーティングシステム、ウェブブラウザのプログラムやウェブブラウザ用ツールバーのプログラム等を記憶する。また、記憶部３２は、投票券販売仲介サーバ１０からの情報を表示したり、投票券の購入を行ったりする専用のアプリケーションソフト（いわゆるアプリ）等を記憶する。

表示部３３は、例えば、液晶表示素子またはＥＬ（Electro Luminescence）素子等によって構成されている。表示部３３には、競馬サイトのトップページの画面や特定のレースに関する投票券を購入するためのレース情報表のウェブページがウェブブラウザにより表示される。

操作部３４は、例えば、キーボードおよびマウス等によって構成されている。ユーザは、操作部３４により応答を入力する。なお、表示部３３がタッチパネルのようなタッチスイッチ方式の表示パネルの場合、操作部３４は、ユーザが接触または近接した表示部３３の位置情報を取得する。

入出力インターフェース部３５は、通信部３１および記憶部３２とシステム制御部３６とのインターフェースである。

システム制御部３６は、例えば、ＣＰＵ３６ａと、ＲＯＭ３６ｂと、ＲＡＭ３６ｃとを有する。システム制御部３６は、ＣＰＵ３６ａが、ＲＯＭ３６ｂや、ＲＡＭ３６ｃや、記憶部３２に記憶された各種プログラムを読み出して実行する。例えば、システム制御部３６は、ウェブブラウザのプログラムを実行しウェブブラウザとして機能する。

［３．投票券販売仲介システムの動作］
次に、本発明の１実施形態に係る投票券販売仲介システム１の動作について図を用い説明する。

（３．１ 投票券の購入の動作）
まず、ユーザ（第１ユーザ、例えば”Ａさん”）は、予めユーザが投票券の購入に必要なお金を、競馬サイトに入金しておく。例えば、ユーザは、今日開催されるレースに対して購入する投票券の予算として、投票券を購入する前に、投票券購入の資金を、投票券販売仲介サーバ１０に開設してある自分の口座に予め入金をしておく。ユーザは、端末装置３０から投票券販売仲介サーバ１０の競馬サイトにログインして、入金の手続きを行う。投票券販売仲介サーバ１０は、会員ＤＢ１２ｄを参照して、ログイン処理を行い、入金を受け付ける。そして、投票券販売仲介サーバ１０は、口座ＤＢ１２ｃにおけるユーザＩＤに対応する口座に入金情報を記憶する。なお各レースの状況を見て、レース毎に入金手続きを行ってもよい。

入金を受けた後、ユーザは、例えば、レース情報表に基づき、投票券を購入するための検討を行い、購入する投票券が決まったならば、ウェブページやアプリにおいて、レース番号、賭式、および、買い目を選択して、購入金額（受付金額）を入力する。

なお、投票券販売仲介サーバ１０は、レース情報表を、主催者サーバ２０から逐次送信されてくるレース情報（オッズ情報を含む）から生成する。

購入金額の入力後、ユーザにより購入ボタンがクリックされると、ユーザＩＤと共に、レース番号、賭式、買い目、購入金額等の投票券購入情報が、端末装置３０から投票券販売仲介サーバ１０に送信される。

次に、投票券販売仲介システム１は、投票券の賭式、賭式における買い目、および、各買い目に対する金額等の投票券購入情報を受け付ける。具体的には、投票券販売仲介サーバ１０が、端末装置３０から、投票券購入情報を受信する。

投票券販売仲介サーバ１０は、受け付けた投票券購入情報を、ユーザＩＤに関連付けて購入投票券ＤＢ１２ｂに記憶する。すなわち、購入投票券ＤＢ１２ｂにおいて、第１ユーザのユーザＩＤで、新たなレコードが生成される。

投票券販売仲介サーバ１０は、所定時間間隔で、他のユーザを含めた各端末装置３０から受け付けた投票券購入情報を、レース、賭式、および、買い目毎に集計して、サマリーデータを生成する。投票券販売仲介サーバ１０は、生成したサマリーデータを、主催者サーバ２０に送信する。

なお、投票券販売仲介サーバ１０は、所定時間間隔に限らず、不規則な間隔で、主催者サーバ２０にサマリーデータを送信してもよいし、主催者サーバ２０からの要求に応じて、サマリーデータを主催者サーバ２０に送信してもよい。また、サマリーデータは、例えば、各ユーザの名義に対応するユーザＩＤを含まず、レース、賭式、および、買い目毎に、投票数が集計されたデータである。

（３．２ 投票券のキャンセルの動作）
次に、投票券のキャンセルの動作について、図７から図１０を用いて説明する。

図７は、投票券販売仲介システム１の動作例を示すフローチャートである。図８は、端末装置３０の表示の一例を示す模式図である。図９は、投票券のキャンセル後における他のユーザの投票券の購入の一例を示す模式図である。図１０は、複数人の投票券のキャンセル後における他のユーザの投票券の購入の一例を示す模式図である。

図７に示すように、投票券販売仲介システム１は、キャンセル依頼を受け付ける（ステップＳ１）。具体的には、図８に示すように、端末装置３０の表示部３３に投票券のキャンセルを受け付ける画面が表示される。表示部３３には、ユーザ（投票券を購入した第１ユーザ）の購入済みの投票券の情報として、レース番号、賭式、買い目、購入金額が表示される。表示部３３には、各賭式の買い目毎にキャンセルができるように、キャンセルボタンが表示される。

ユーザがキャンセルしたい賭式の買い目のキャンセルボタンを選択して端末装置３０がキャンセル依頼を受け付けると、端末装置３０は、ユーザＩＤ、レースＩＤ、賭式、買い目、および、購入金額を含むキャンセル依頼の情報を、投票券販売仲介サーバ１０に送信する。

なお、投票券を購入した第１ユーザと当該購入済み投票券の買い目とを特定可能な情報の一例として、ユーザＩＤ、レースＩＤ、賭式、買い目、および、購入金額の代わりに、投票券の購入番号や投票券の購入ＩＤ等でもよい。

購入した買い目の全額のキャンセルでなく、一部の金額をキャンセルしたい場合、キャンセル依頼の情報に、ユーザＩＤ、レースＩＤ、賭式、買い目、および、キャンセル金額が含まれる。または、キャンセル依頼の情報に、投票券の購入ＩＤおよびキャンセル金額が含まれる。

投票券販売仲介サーバ１０が、端末装置３０からキャンセル依頼の情報を受信する。

このように、投票券販売仲介サーバ１０が、投票券を購入した第１ユーザと当該購入済み投票券の賭式および買い目とを特定可能な情報を含む、当該購入済み投票券のキャンセル依頼を、前記第１ユーザから受け付けるキャンセル受付手段の一例として機能する。

次に、投票券販売仲介システム１は、キャンセル依頼の情報を記憶する（ステップＳ２）。具体的には、投票券販売仲介サーバ１０が、購入投票券ＤＢ１２ｂを参照して、キャンセル依頼のユーザＩＤ、レースＩＤ、賭式、買い目に基づき、キャンセルに該当する投票券を特定する。投票券販売仲介サーバ１０が、購入投票券ＤＢ１２ｂにおいて、特定された投票券のキャンセルフラグをＯＮにして、キャンセル申込時刻に受信時刻等を記憶する。

なお、投票券販売仲介サーバ１０は、キャンセル依頼の投票券の購入ＩＤに基づき、キャンセルに該当する投票券を特定してもよい。

例えば、図４および図９に示すように、第１ユーザ”Ａさん”（ユーザＩＤ”00111”）が、賭式”馬単”の買い目”1-2”で購入金額\1,000の投票券に対して、キャンセルを2014年9月9日14：45：00に行ったとする。

次に、投票券販売仲介システム１は、投票券購入情報を受け付ける（ステップＳ３）。具体的には、投票券販売仲介サーバ１０が、キャンセル依頼の情報を送信してきた端末装置３０と異なるユーザ（第２ユーザ）の端末装置３０から投票券購入情報を受信する。

投票券販売仲介サーバ１０が、購入投票券ＤＢ１２ｂにおいて、第２ユーザのユーザＩＤで、投票券購入情報のレコードを生成する。

例えば、図４および図９に示すように、第２ユーザ”Ｘさん”（ユーザＩＤ”00xxx”）が、同じレースＩＤの賭式”馬単”の買い目”1-2”の投票券を購入金額\300で2014年9月9日15：00：00に購入したとする。

次に、投票券販売仲介システム１は、賭式および買い目と同じか否かを判定する（ステップＳ４）。具体的には、投票券販売仲介サーバ１０が、購入投票券ＤＢ１２ｂを参照して、キャンセル依頼を受け付けた投票券のレースＩＤ、賭式および買い目と、購入を受け付けた投票券のレースＩＤ、賭式および買い目とが同じであるか否かを判定する。さらに具体的には、投票券販売仲介サーバ１０が、投票券の購入を依頼してきたユーザのユーザＩＤと異なり、かつ、キャンセルフラグがＯＮのレコードにおいて、レースＩＤ、賭式、および、買い目が同じ投票券を検索する。

賭式および買い目と同じである場合（ステップＳ４；ＹＥＳ）、投票券販売仲介システム１は、第２ユーザが購入を申し込んだ同じ投票券（レースＩＤ、賭式および買い目が同じ投票券）における購入金額が、キャンセル依頼の残金よりも少ないか否かを判定する（ステップＳ５）。具体的には、投票券販売仲介サーバ１０が、購入投票券ＤＢ１２ｂを参照して、第２ユーザが購入を申し込んだ同じ投票券における購入金額が、キャンセル依頼の残金（購入金額−返金額）よりも少ないか否かを判定する。

第２ユーザが購入を申し込んだ同じ投票券における購入金額がキャンセル依頼の残金よりも少ない場合（ステップＳ５；ＹＥＳ）、投票券販売仲介システム１は、部分返金処理を行う（ステップＳ６）。具体的には、投票券販売仲介サーバ１０が、第２ユーザが購入を申し込んだ同じ投票券における購入金額を加算した金額を、第１ユーザに返金すると決定する。既に決定されている返金額がある場合、投票券販売仲介サーバ１０が、既に決定されている返金額に、第２ユーザが購入を申し込んだ同じ投票券における購入金額を加算した金額を、第１ユーザに返金すると決定する。

次に、投票券販売仲介サーバ１０が、購入投票券ＤＢ１２ｂにおいて、キャンセル依頼をしたユーザのレコードの返金額の欄に、第２ユーザが購入を申し込んだ同じ投票券における購入金額を加算した金額を記憶する。投票券販売仲介サーバ１０が、残金の欄に、新たな残金（前の残金−第２ユーザが購入を申し込んだ同じ投票券における購入金額）を記憶する。例えば、図４に示すように、返金額\300および残金\700が記憶される。このように、部分返金処理を行うことで、部分的にキャンセルが成立する。このように、キャンセル依頼の全額でなく一部を返金する、すなわち、部分的にキャンセルが成立した場合も、キャンセル依頼の成立の一例である。

次に、投票券販売仲介サーバ１０が、口座ＤＢ１２ｃにおいて、第１ユーザの口座に返金額を入金する。なお、口座ＤＢ１２ｃへの入金は、投票券の受付が締め切られた後で行ってもよいし、部分的にキャンセルが成立する毎に、逐次、入金が行われてもよい。

なお、このまま、投票券の受付が締め切られた場合、残金に対するキャンセルを行うことができないので、残金\700が確定する。このとき、投票券販売仲介サーバ１０が、購入投票券ＤＢ１２ｂにおいて、購入金額を、確定した残金\700の金額にして、部分的にキャンセルが成立したとして、購入金額を\1,000から\700になるようにしてもよい。

このように、投票券販売仲介サーバ１０が、前記キャンセル依頼を受け付けた後であって投票券購入締め切りが到来する前に、前記第１ユーザからキャンセル依頼を受け付けた投票券の賭式および買い目と同じ賭式および買い目の投票券の購入を第２ユーザから受け付けた場合、前記第１ユーザから前記キャンセル依頼を受け付けた投票券の金額と前記第２ユーザから受け付けた投票券の金額とに応じて、前記第１ユーザの口座に入金する入金手段の一例として機能する。また、投票券販売仲介サーバ１０が、前記第１ユーザから受け付けた前記キャンセル依頼を受け付けた投票券の金額が、前記第２ユーザから受け付けた前記同じ賭式および買い目の投票券の金額より大きい場合、前記第２ユーザから受け付けた前記同じ賭式および買い目の投票券の金額分、前記第１ユーザの口座に入金する入金手段の一例として機能する。

返金額の決定後、投票券販売仲介サーバ１０が、返金する金額に応じたキャンセルが成立した旨の情報を第１ユーザ用に出力する。例えば、投票券販売仲介サーバ１０が、通信部１１を通して、決定した返金額の情報を含む部分的にキャンセルが成立（キャンセル依頼の成立の一例）した旨の情報を端末装置３０に送信する。または、投票券情報提供サーバ１０が、会員ＤＢ１２ｄで関連付けられたメールアドレス宛に、決定した返金額の情報を含む部分的にキャンセルが成立した旨の情報を、メール通知として送信する。なお、各部分的にキャンセルが成立する度に、投票券販売仲介サーバ１０が、部分的にキャンセルが成立した旨の情報を第１ユーザ用に出力してもよいし、投票券の受付が締め切られた後、確定した返金額を含む情報を第１ユーザ用に出力してもよい。

このように、投票券販売仲介サーバ１０が、前記入金する金額がゼロでない場合に、前記キャンセル依頼が成立した旨の情報を、前記第１ユーザ用に出力する出力手段の一例として機能する。

賭式および買い目と同じでない場合（ステップＳ４；ＮＯ）、投票券販売仲介システム１は、サマリー送信時にデータを送信する（ステップＳ７）。具体的には、サマリーデータを送信する時刻になったら、投票券販売仲介サーバ１０が、第２ユーザのユーザＩＤ等の名義の情報が除かれて、第２ユーザの投票券購入情報（レースＩＤ、賭式、買い目、および購入金額）を含んで集計されたサマリーデータを主催者サーバ２０に送信する。

このように、投票券販売仲介サーバ１０が、前記第１ユーザから受け付けた前記キャンセル依頼を受け付けた投票券の金額と前記第２ユーザから受け付けた前記同じ賭式および買い目の投票券の金額とに応じて、前記主催者サーバ装置に送信する前記名義の情報を含まない投票券購入情報を決定する送信情報決定手段の一例として機能する。

次に、投票券販売仲介システム１は、投票券の受付締め切りか否かを判定する（ステップＳ８）。具体的には、投票券販売仲介サーバ１０が、キャンセル依頼対象の投票券のレースに関して、投票券の受付締め切りか否かを判定する。例えば、投票券の受付締め切りは、予め定められたレースが開始される時刻の所定時刻前、主催者サーバ２０から投票券の受付締切の情報を受信した場合等が挙げられる。

投票券の受付締め切りでない場合（ステップＳ８；ＮＯ）、ステップＳ３の処理に戻り、投票券販売仲介サーバ１０が、新たな投票券の購入を受け付ける。

投票券の受付の締め切りまでに、キャンセル依頼を受け付けた投票券のレースＩＤ、賭式および買い目と同じで、新たな投票券購入情報を受け付けた場合、ステップＳ５において、投票券販売仲介サーバ１０が、新たな購入において賭式および買い目が同じ投票券における購入金額が、キャンセル依頼の残金よりも少ないか否かを判定する。

新たな購入において賭式および買い目が同じ投票券における購入金額（例えば、\500）が、キャンセル依頼の残金（例えば、\700）よりも少ない場合、ステップＳ６において、投票券販売仲介サーバ１０が、購入投票券ＤＢ１２ｂにおいて、キャンセル依頼をしたユーザのレコードの返金額の欄に、新たな購入の同じ投票券における購入金額を加算した金額（例えば、\800）を記憶し、残金の欄に新たな残金（例えば、\200）を記憶する。ステップＳ３からステップＳ８の処理が、残金がゼロになるまで、または、投票券の購入の受け付けが締め切られるまで、繰り返される。

キャンセル依頼の残金よりも少なく無い場合（ステップＳ５；ＮＯ）、投票券販売仲介システム１は、返金処理を行う（ステップＳ９）。具体的には、投票券販売仲介サーバ１０が、キャンセル依頼をした投票券の金額を、第１ユーザに返金すると決定する。なお、一部の金額をキャンセルしたい場合は、投票券販売仲介サーバ１０が、キャンセル金額を、第１ユーザに返金すると決定する。

次に、投票券販売仲介サーバ１０が、購入投票券ＤＢ１２ｂにおいて、キャンセル依頼をしたユーザのレコードの残金欄に、”\0”を記載する。返金額の欄は、購入金額と同じ額となる。なお、投票券販売仲介サーバ１０が、キャンセル依頼をしたユーザのレコードを消去してもよい。

次に、投票券販売仲介サーバ１０が、口座ＤＢ１２ｃにおいて、第１ユーザの口座に返金額を入金する。なお、口座ＤＢ１２ｃへの入金は、投票券の受付が締め切られた後で行ってもよいし、キャンセル依頼が成立したときに入金が行われてもよい。

このように、投票券販売仲介サーバ１０が、前記第１ユーザから受け付けた前記キャンセル依頼を受け付けた投票券の金額が、前記第２ユーザから受け付けた前記同じ賭式および買い目の投票券の金額より大きい場合、前記第２ユーザから受け付けた前記同じ賭式および買い目の投票券の金額分、前記第１ユーザの口座に入金する入金手段の一例として機能する。

返金額の決定後、投票券販売仲介サーバ１０が、返金する金額に応じたキャンセルが成立した旨の情報を第１ユーザ用に出力する。例えば、投票券販売仲介サーバ１０が、通信部１１を通して、キャンセル依頼のキャンセルが全て成立した旨の情報を端末装置３０に送信する。または、投票券情報提供サーバ１０が、会員ＤＢ１２ｄで関連付けられたメールアドレス宛に、キャンセル依頼のキャンセルが全て成立（キャンセル依頼の成立の一例）した旨の情報を、メール通知として送信する。投票券の受付が締め切られた後、キャンセルが全て成立した旨の情報を第１ユーザ用に出力してもよい。

このように、投票券販売仲介サーバ１０が、前記入金する金額がゼロでない場合に、前記キャンセル依頼が成立した旨の情報を、前記第１ユーザ用に出力する出力手段の一例として機能する。

次に、投票券販売仲介システム１は、差額があれば、差額分をサマリーデータとして送信する（ステップＳ１０）。具体的には、サマリーデータを送信する時刻になったら、投票券販売仲介サーバ１０が、第２ユーザのユーザＩＤ等の名義の情報が除かれて、第２ユーザが購入を申し込んだ同じ投票券における購入金額からキャンセル依頼の残金を差し引いた金額（差額分）における投票券（同じレースＩＤ、賭式、および、買い目の投票券）の情報を含んで集計されたサマリーデータを主催者サーバ２０に送信し、一連のキャンセルの処理を終了する。

このように、投票券販売仲介サーバ１０が、前記第１ユーザから受け付けた前記キャンセル依頼を受け付けた投票券の金額が、前記第２ユーザから受け付けた前記同じ賭式および買い目の投票券の金額より少ない場合、これらの購入金額の差額に基づいた前記名義の情報を含まない投票券購入情報を、前記主催者サーバ装置に送信すると決定する送信情報決定手段の一例として機能する。

または、投票券の受付締め切りである場合（ステップＳ８；ＹＥＳ）、投票券販売仲介システム１は、一連のキャンセルの処理を終了する。

なお、レース終了後に、口座ＤＢ１２ｃにおいて、第１ユーザの口座に、キャンセルが成立した分の金額が入金される。

以上のように、本実施形態によれば、第１ユーザ（”Ａさん”）からのキャンセル依頼を受け付けた投票券の金額と、第２ユーザから受け付けた同じ賭式および買い目の投票券の金額とに応じて、第１ユーザの口座に返金できるので、主催者のホストシステムに取り消し依頼せずに、投票券の取り消しを行うことができる。

また、決定した返金する金額がゼロでない場合に、キャンセル依頼が成立した旨の情報を、第１ユーザ用に出力することにより、キャンセルが一部（キャンセル依頼の一部の金額を返金）、または、全て成立（キャンセル依頼の全額を返金）したことを、キャンセルを依頼したユーザが確認できる。

また、第１ユーザから受け付けたキャンセル依頼を受け付けた投票券の金額が、第２ユーザから受け付けた同じ賭式および買い目の投票券の金額より大きいときに、第２ユーザから受け付けた同じ賭式および買い目の投票券の金額分、第１ユーザに返金すると決定する場合、第２ユーザからの購入分の投票券購入情報を主催者側に送信する必要が無く、第２ユーザの購入分、第１ユーザに一部返金することにより、部分的にキャンセルすることができる。

［４．変形例］
次に、キャンセルの依頼が複数のユーザからある場合について図１０を用いて説明する。

図１０は、複数人の投票券のキャンセル後における他のユーザの投票券の購入の一例を示す模式図である。

図１０に示すように、同じレースの同じ賭式および買い目の投票券に対して、複数のキャンセル依頼がある場合でもよい。

図１０に示すように、賭式”馬単”の買い目”1-2”に”Ａさん”（第１ユーザの一例）から、\1,000のキャンセル依頼、”Ｂさん”（第１ユーザの一例）から、\3,000のキャンセル依頼があったとする。

第２ユーザの一例の”Ｘさん”が、”Ａさん”および”Ｂさん”のキャンセル依頼後に、同じ賭式”馬単”の買い目”1-2”で投票券を\xで購入したとする。

”Ｘさん”の購入金額\xが\4,000（”Ａさん”の\1,000とＢさん”の\3,000の合計を残金とする）以上の場合、ステップＳ５で”ＮＯ”となり、ステップＳ９において、投票券販売仲介サーバ１０が、購入投票券ＤＢ１２ｂにおいて、キャンセル依頼をしたユーザ”Ａさん”および”Ｂさん”のレコードの残金欄に、”\0”を記載する。

”Ｘさん”の購入金額\xが\4,000よりも少ない場合、ステップＳ５で”ＹＥＳ”となり、投票券販売仲介サーバ１０が、ユーザ”Ａさん”および”Ｂさん”に対して部分返金処理を行う。

このとき、例えば、投票券販売仲介サーバ１０が、￥金額\xを、ユーザ”Ａさん”および”Ｂさん”に” \x/2ずつ均等に配分する。このようにキャンセル依頼をしたユーザの数で割った額（配分金額）を、各ユーザに配分することにより公平感を出す。

投票券販売仲介サーバ１０が、購入投票券ＤＢ１２ｂにおいて、キャンセル依頼をした各ユーザのレコードの返金額の欄に、配分金額を加算した金額を記憶する。投票券販売仲介サーバ１０が、残金の欄に、新たな残金（前の残金−配分金額）を記憶する。口座ＤＢ１２ｃにおけるユーザ”Ａさん”の口座および”Ｂさん”の口座に、それぞれの金額が入金される。

なお、投票券販売仲介サーバ１０が、キャンセル依頼の時刻に応じて、金額\xを、ユーザ”Ａさん”および”Ｂさん”に”配分する配分金額を決定してもよい。例えば、ユーザ”Ｂさん”のキャンセル依頼の時刻が早いので、ユーザ”Ｂさん”の配分を多くする。

このように、同じ賭式および買い目の投票券に対して、複数の第１ユーザ（例えば、”Ａさん”および”Ｂさん”）から受け付けた前記キャンセル依頼における投票券の金額を合計した額（例えば、\4,000）が、第２ユーザ（例えば、”Ｘさん”）から受け付けた同じ賭式および買い目の投票券の購入金額（例えば、\x）より大きい場合、第２ユーザから受け付けた同じ賭式および買い目の投票券の購入金額において、当該複数のユーザから受け付けたキャンセル依頼の各時刻に応じて、各ユーザに返金する返金額（配分金額）を決定する。

この場合、キャンセルを依頼した各第１ユーザに対して、キャンセル依頼の時刻に応じたより公平感がある返金により、部分的なキャンセルを行うことができる。

なお、複数の第１ユーザにおける各ユーザのユーザ情報に応じて、各ユーザに返金する返金額を決定してもよい。他の賭式の買い目でキャンセル依頼をしている第１ユーザに対する配分金額を多くする。または、既に他の賭式の買い目でキャンセルが成立（部分返金処理による部分成立を含む）していない第１ユーザに対する配分金額を多くする。

同じ賭式および買い目の投票券に対して、第１ユーザを含む複数のユーザから受け付けたキャンセル依頼における投票券の金額を合計した額が、第２ユーザから受け付けた同じ賭式および買い目の投票券の金額より大きい場合、第２ユーザから受け付けた同じ賭式および買い目の投票券の金額において、当該複数のユーザの各ユーザのユーザ情報に応じて、各ユーザに返金する返金額を決定し、各ユーザの口座に入金する。

この場合、キャンセルを依頼した各第１ユーザに対して、各ユーザのユーザ情報に応じた所定の基準に従った返金を行うことで、より公平感がある部分的なキャンセルを行うことができる。

なお、サマリーデータを送信する前に、新たなキャンセル依頼があった場合、投票券販売仲介サーバ１０が、ステップＳ４のように、送信前のサマリーされる投票券と同じレースＩＤ、賭式、買い目があるかどうか検索してもよい。投票券販売仲介サーバ１０が、ステップＳ５のように、新たなキャンセル依頼の金額と送信前のサマリーされる投票券の金額とに応じて、ステップＳ６のような部分返金処理、ステップＳ９のような返金処理を行ってもよい。

また、キャンセル依頼の成立後、返金処理または部分返金処理において、第１ユーザの口座に入金する代わりに、第１ユーザにポイントを付与してもよい。

さらに、本発明は、上記各実施形態に限定されるものではない。上記各実施形態は、例示であり、本発明の特許請求の範囲に記載された技術的思想と実質的に同一な構成を有し、同様な作用効果を奏するものは、いかなるものであっても本発明の技術的範囲に包含される。

１：投票券販売仲介システム
１０：投票券販売仲介サーバ（投票券販売仲介装置）
１２ｂ： 購入投票券ＤＢ
１２ｃ：口座ＤＢ
２０：主催者サーバ（主催者サーバ装置）
３０：端末装置（ユーザ端末）

Claims (7)

1. 公営競技の投票券の購入をユーザ端末から受け付けて、当該投票券を購入したユーザの名義の情報を含まない投票券購入情報を当該公営競技が主催する主催者サーバ装置に送信する投票券販売仲介装置において、
   投票券を購入した第１ユーザと当該購入済み投票券の賭式および買い目とを特定可能な情報を含む、当該購入済み投票券のキャンセル依頼を、前記第１ユーザのユーザ端末から受け付けるキャンセル受付手段と、
   前記キャンセル依頼を受け付けた後であって投票券購入締め切りが到来する前に、前記第１ユーザからキャンセル依頼を受け付けた投票券の賭式および買い目と同じ賭式および買い目の投票券の購入を第２ユーザから受け付けた場合、前記第１ユーザから前記キャンセル依頼を受け付けた投票券の金額と前記第２ユーザから受け付けた投票券の金額とに応じて、前記第１ユーザの口座に入金する入金手段と、
   前記入金する金額がゼロでない場合に、前記キャンセル依頼のうち前記入金される金額に応じたキャンセルが成立した旨の情報を、前記第１ユーザ用に出力する出力手段と、
   を備えたことを特徴とする投票券販売仲介装置。
2. 請求項１に記載の投票券販売仲介装置において、
   前記第１ユーザから受け付けた前記キャンセル依頼を受け付けた投票券の金額が、前記第２ユーザから受け付けた前記同じ賭式および買い目の投票券の金額より少ない場合、これらの購入金額の差額に基づいた前記名義の情報を含まない投票券購入情報を、前記主催者サーバ装置に送信すると決定する送信情報決定手段を更に備えたことを特徴とする投票券販売仲介装置。
3. 請求項１または請求項２に記載の投票券販売仲介装置において、
   前記第１ユーザから受け付けた前記キャンセル依頼を受け付けた投票券の金額が、前記第２ユーザから受け付けた前記同じ賭式および買い目の投票券の金額より大きい場合、前記入金手段は、前記第２ユーザから受け付けた前記同じ賭式および買い目の投票券の金額分、前記第１ユーザの口座に入金することを特徴とする投票券販売仲介装置。
4. 請求項３に記載の投票券販売仲介装置において、
   前記同じ賭式および買い目の投票券に対して、前記第１ユーザを含む複数のユーザから受け付けた前記キャンセル依頼における投票券の金額を合計した額が、前記第２ユーザから受け付けた前記同じ賭式および買い目の投票券の金額より大きい場合、前記入金手段は、前記第２ユーザから受け付けた前記同じ賭式および買い目の投票券の金額において、当該複数のユーザから受け付けたキャンセル依頼の各時刻に応じて、当該各ユーザの口座に入金することを特徴とする投票券販売仲介装置。
5. 請求項３に記載の投票券販売仲介装置において、
   前記同じ賭式および買い目の投票券に対して、前記第１ユーザを含む複数のユーザから受け付けた前記キャンセル依頼における投票券の金額を合計した額が、前記第２ユーザから受け付けた前記同じ賭式および買い目の投票券の金額より大きい場合、前記入金手段は、前記第２ユーザから受け付けた前記同じ賭式および買い目の投票券の金額において、当該複数のユーザにおける各ユーザのユーザ情報に応じて、当該各ユーザの口座に入金することを特徴とする投票券販売仲介装置。
6. 公営競技の投票券の購入をユーザ端末から受け付けて、当該投票券を購入したユーザの名義の情報を含まない投票券購入情報を当該公営競技が主催する主催者サーバ装置に送信する投票券販売仲介装置の投票券販売仲介方法において、
   投票券を購入した第１ユーザと当該購入済み投票券の賭式および買い目とを特定可能な情報を含む、当該購入済み投票券のキャンセル依頼を、前記第１ユーザから受け付けるキャンセル受付ステップと、
   前記キャンセル依頼を受け付けた後であって投票券購入締め切りが到来する前に、前記第１ユーザからキャンセル依頼を受け付けた投票券の賭式および買い目と同じ賭式および買い目の投票券の購入を第２ユーザから受け付けた場合、前記第１ユーザから前記キャンセル依頼を受け付けた投票券の金額と前記第２ユーザから受け付けた投票券の金額とに応じて、前記第１ユーザの口座に入金する入金ステップと、
   前記入金する金額がゼロでない場合に、前記キャンセル依頼のうち前記入金される金額に応じたキャンセルが成立した旨の情報を、前記第１ユーザ用に出力する出力ステップと、
   を含むことを特徴とする投票券販売仲介方法。
7. 公営競技の投票券の購入をユーザ端末から受け付けて、当該投票券を購入したユーザの名義の情報を含まない投票券購入情報を当該公営競技が主催する主催者サーバ装置に送信する投票券販売仲介装置用プログラムにおいて、
   コンピュータを、
   投票券を購入した第１ユーザと当該購入済み投票券の賭式および買い目とを特定可能な情報を含む、当該購入済み投票券のキャンセル依頼を、前記第１ユーザから受け付けるキャンセル受付手段、
   前記キャンセル依頼を受け付けた後であって投票券購入締め切りが到来する前に、前記第１ユーザからキャンセル依頼を受け付けた投票券の賭式および買い目と同じ賭式および買い目の投票券の購入を第２ユーザから受け付けた場合、前記第１ユーザから前記キャンセル依頼を受け付けた投票券の金額と前記第２ユーザから受け付けた投票券の金額とに応じて、前記第１ユーザの口座に入金する入金手段、および、
   前記入金する金額がゼロでない場合に、前記キャンセル依頼のうち前記入金される金額に応じたキャンセルが成立した旨の情報を、前記第１ユーザ用に出力する出力手段として機能させることを特徴とする投票券販売仲介装置用プログラム。

Images