JP2019160308A - コンピュータプログラム - Google Patents

Abstract

【課題】ユーザに煩雑な操作をさせることなく、宝くじの当落を通知するコンピュータプログラムを提供する。【解決手段】宝くじの当落の通知を行う通信サーバにおいて、コンピュータプログラムは、物理媒体に表示された宝くじの回数及び数字を含むくじ券の識別情報を取得し、取得した回数及び前記識別情報を送信し、識別情報の当落結果を出力する。【選択図】図７

Description

本発明は、宝くじの当落の通知を行うコンピュータプログラムに関する。

宝くじの当落の通知を行う処理システムが提案されている（例えば、特許文献１）。

特開平４−３７０８７９号公報

しかしながら、上述の処理システムはくじの番号をユーザが入力することが必要で煩雑である等の課題がある。

本発明はこのような事情に鑑みてなされたものである。その目的は、ユーザに煩雑な操作をさせることなく、宝くじの当落を通知するコンピュータプログラムの提供である。

本発明に係るコンピュータプログラムは、物理媒体に表示された宝くじの回数及び数字を含むくじ券の識別情報を取得し、取得した前記回数及び前記識別情報を送信し、前記識別情報の当落結果を出力する処理をコンピュータに行わせることを特徴とする。

本発明にあっては、ユーザに煩雑な操作をさせることなく、宝くじの当落を通知可能である。

通知システムの構成を示す説明図である。 通知サーバのハードウェア構成例を示すブロック図である。 ユーザ端末のハードウェア構成例を示すブロック図である。 ユーザＤＢの例を示す説明図である。 パターンＤＢの例を示す説明図である。 くじＤＢの例を示す説明図である。 くじ券登録処理の手順例を示すフローチャートである。 当せん判定処理の手順例を示すフローチャートである。 通知処理の手順例を示すフローチャートである。 抽選日処理の手順例を示すフローチャートである。 車券ＤＢの例を示す説明図である。 馬券ＤＢの例を示す説明図である。 舟券ＤＢの例を示す説明図である。 登録処理の手順例を示すフローチャートである。 登録処理の手順例を示すフローチャートである。 当せん通知画面の例を示す説明図である。 当落一覧画面の例を示す説明図である。 予定通知処理の手順例を示すフローチャートである。 算出処理の手順例を示すフローチャートである。 収支状況グラフの例を示す説明図である。 支出状況のグラフの例を示す説明図である。 遊技結果ＤＢの例を示す説明図である。 広告配信処理の手順例を示すフローチャートである。 くじ付きはがきＤＢの例を示す説明図である。 当せん通知画面の他の例を示す説明図である。 当せん通知画面の他の例を示す説明図である。 登録通知処理の手順例を示すフローチャートである。

以下実施の形態を、図面を参照して説明する。図１は通知システムの構成を示す説明図である。通知システム１００は通知サーバ１、ユーザ端末２及び配信サーバ３を含む。通知サーバ１、ユーザ端末２、配信サーバ３はネットワークＮにより、互いに通信可能に接続されている。

通知サーバ１は宝くじの当落の通知を行うコンピュータである。ユーザ端末２は宝くじを購入したユーザの端末である。また、図１には便宜上、ユーザ端末２を２台記載しているが、１台でも良いし、３台以上でもよい。配信サーバ３は宝くじの当せん番号などを配信するコンピュータである。また、配信サーバ３は情報ポータルの機能も有し、宝くじの発売開始予定日などを記憶している。通知サーバ１は、これらの情報を通知サーバ１やユーザ端末２からの要求に応じて、提供する。

図２は通知サーバのハードウェア構成例を示すブロック図である。通知サーバ１は宝くじの当落判定に関する処理を行う。通知サーバ１はサーバコンピュータ等で構成する。通知サーバ１は、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）１１、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）１２、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）１３、大容量記憶部１４、通信部１５及ぶ計時部１６を含む。各構成はバスＢで接続されている。

ＣＰＵ１１はＲＯＭ１２に記憶された制御プログラム１Ｐにしたがい、ハードウェア各部を制御する。ＲＡＭ１３は例えばＳＲＡＭ（Ｓｔａｔｉｃ ＲＡＭ）、ＤＲＡＭ（Ｄｙｎａｍｉｃ ＲＡＭ）又はフラッシュメモリである。ＲＡＭ１３はＣＰＵ１１によるプログラムの実行時に発生するデータを一時的に記憶する。

大容量記憶部１４は、例えばハードディスク又はＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）などである。大容量記憶部１４は各種データベース（ＤＢ：ＤａｔａＢａｓｅ）を記憶する。大容量記憶部１４はユーザＤＢ１４１、パターンＤＢ１４２、くじＤＢ１４３、車券ＤＢ１４４、馬券ＤＢ１４５、舟券ＤＢ１４６、及び遊技結果ＤＢ１４７を記憶する。また、制御プログラム１Ｐを大容量記憶部１４に記憶してもよい。ユーザＤＢ１４１…は、通知サーバ１以外に記憶してもよい。例えばデータベースサーバやクラウドストレージに記憶してもよい。

通信部１５はネットワークＮを介して、ユーザ端末２及び配信サーバ３と通信を行う。また、ＣＰＵ１１が通信部１５を用い、ネットワークＮ等を介して他のコンピュータから制御プログラム１Ｐをダウンロードし、大容量記憶部１４に記憶してもよい。なお、通知サーバ１の機能を複数のサーバコンピュータで提供してもよい。又、通知サーバ１の機能をクラウドサービスにより提供してもよい。

計時部１６は時刻又は通知サーバ１が起動してからの経過時間等の時間を計時する。計時部１６はＣＰＵ１１からの求めに応じて、計時結果をＣＰＵ１１に与える。

図３はユーザ端末のハードウェア構成例を示すブロック図である。ユーザ端末２はノートパソコン、パネルコンピュータ、タブレットコンピュータ、スマートフォン等で構成する。ユーザ端末２は、ＣＰＵ２１、ＲＯＭ２２、ＲＡＭ２３、大容量記憶部２４、撮像部２５、表示部２６、入力部２７及び通信部２８を含む。各構成はバスＢで接続されている。

ＣＰＵ２１はＲＯＭ２２に記憶された制御プログラム２Ｐにしたがい、ハードウェア各部を制御する。ＲＡＭ２３は例えばＳＲＡＭ、ＤＲＡＭ又はフラッシュメモリである。ＲＡＭ２３はＣＰＵ２１によるプログラムの実行時に発生するデータを一時的に記憶する。

大容量記憶部２４は、例えばハードディスク又はＳＳＤなどである。大容量記憶部２４は各種データを記憶する。

撮像部２５は、例えばＣＣＤカメラ又はＣＭＯＳカメラ等であり、ＣＣＤ又はＣＯＭＳ等を介して入力された光信号を光電変換することにより画像データを取得する。

表示部２６は液晶表示装置である。表示部２６はデータ処理の結果などを表示する。入力部２７はキーボードやマウスである。また、入力部２７は表示部２６と一体化したタッチパネルディスプレイでもよい。なお、ユーザ端末２は外部の表示装置に表示を行ってもよい。

通信部２８はネットワークＮを介して、通知サーバ１及び配信サーバ３と通信を行う。また、ＣＰＵ２１が通信部２８を用い、ネットワークＮ等を介して他のコンピュータから制御プログラム２Ｐをダウンロードし、大容量記憶部２４に記憶してもよい。

次に、通知システム１００で利用されるデータベースについて、説明する。図４はユーザＤＢの例を示す説明図である。ユーザＤＢ１４１はユーザに関する情報を記憶する。ユーザＤＢ１４１は、ユーザＩＤ列、氏名列、年齢列、性別列、職業列、携帯番号列、電子メール列及び通知方法列を含む。ユーザＩＤ列はユーザを一意に特定可能なユーザＩＤを記憶する。氏名列はユーザの氏名を記憶する。年齢列はユーザの年齢を記憶する。性別列はユーザの性別を記憶する。職業列はユーザの職業を記憶する。携帯番号列はユーザの携帯電話の番号を記憶する。電子メール列はユーザの電子メールアドレスを記憶する。通知方法列は宝くじの当落の通知を後日受ける場合に、ユーザが希望する通知方法を記憶する。通知方法は例えば、プッシュ通知、電子メール、アプリケーションである。プッシュ通知はＳＭＳ（Ｓｈｏｒｔ Ｍｅｓｓａｇｅ Ｓｅｒｖｉｃｅ）を用いた通知である。電子メールは当落の通知を電子メールで行う。アプリケーションはユーザ端末２で通知サーバ１と通信するためのアプリケーションソフトウェアが起動しているときに、アプリケーションソフトウェアの機能を用いて通知を行う方法である。

図５はパターンＤＢの例を示す説明図である。パターンＤＢ１４２は宝くじの特徴パターン等の情報を記憶する。パターンＤＢ１４２を用いて、宝くじの画像から宝くじの番号などを抽出する。パターンＤＢ１４２は種別ＩＤ列、種別列、特徴パターン列、及び抽出範囲列を含む。種別ＩＤ列は宝くじの種別を一意に特定可能な種別ＩＤを記憶する。種別列は宝くじの種別を記憶する。種別とは例えば、通常くじ（予め番号が印字されている宝くじ）、ロト、ナンバーズなどである。特徴パターン列はくじの種別を判別するための特徴パターン画像を記憶する。抽出範囲列は特徴パターン画像を基に、宝くじの識別情報を抽出するための座標を記憶する。識別情報は、例えば通常くじであれば、名称、回数、組番号及び番号である。抽出範囲の形状を矩形とした場合、座標は例えば、左上角と右下角の座標である。

図６はくじＤＢの例を示す説明図である。くじＤＢ１４３はユーザが所有するくじの番号などを記憶する。くじＤＢ１４３は、ユーザＩＤ列、種別列、名称列、回数列、通称列、単価列、支出列、組列、番号列、タイプ列、当落列、等級列、当せん金列、及び通知列を含む。ユーザＩＤ列はユーザＩＤを記憶する。種別列は宝くじの種別を記憶する。名称列は宝くじの名称を記憶する。回数列は宝くじの回数を記憶する。通称列は宝くじの通称を記憶する。通称とは例えば「お正月○○くじ」である。単価列は宝くじ１枚あたりの支払い額を記憶する。支出列は宝くじを購入するのにユーザが支出した金額を記憶する。組列は宝くじの組番号を記憶する。組番号のない数字選択式宝くじの場合、組列は空白等の値がないことを示す情報を記憶する。番号列は宝くじの番号を記憶する。数字選択式宝くじの場合、番号列はユーザ選択した番号を記憶する。タイプ列は宝くじの申込タイプを記憶する。申込タイプのないナンバーズ以外の種別である宝くじの場合、タイプ列は空白等の値がないことを示す情報を記憶する。当落列は宝くじが当せんしたか否かを記憶する。図６に示す例では、宝くじが当せんした場合、当落列は「当たり」を記憶する。宝くじが当せんしなかった場合、当落列は「ハズレ」を記憶する。等級列は宝くじが当せんした場合、当せんの等級を記憶する。宝くじが１等に当せんした場合、等級列は１を記憶する。当せん金列は宝くじが当せんした場合、当せん金の金額（収入）を記憶する。当せん金列は宝くじが当せんしなかった場合、０を記憶する。通知列は宝くじの当落を購入したユーザに通知したか否かを記憶する。例えば、まだ当落をユーザに通知していない場合、通知列は「未通知」を記憶する。当落を既にユーザに通知している場合、通知列は「通知済」を記憶する。

くじＤＢ１４３において、抽せん前のように、当落判定がされていない宝くじに対応する当落列、等級列、当せん金列、及び通知列は、空白等の値がないことを示す情報を記憶する。また、くじＤＢ１４３にはユーザが購入した宝くじのくじ券の情報すべてを記憶することを前提とする。しかし、宝くじの種別がスクラッチの場合、当落はすぐに判明する。そのため、当せんしなかったくじの情報をユーザが登録する可能性は低い。ユーザが当せんした宝くじの情報のみの登録を希望する場合、外れたくじに支出した金額も合わせた購入総額を入力させ、くじＤＢ１４３の支出列に記憶する。ユーザＤＢ１４１、パターンＤＢ１４２及びくじＤＢ１４３以外のデータベースについては、後述する。

次に、通知サーバ１が行う処理について、説明する。図７はくじ券登録処理の手順例を示すフローチャートである。くじ券登録処理はユーザが宝くじを購入した後、くじ券の内容を通知システム１００に登録する場合に実行される処理である。ユーザはユーザ端末２で通知システム１００用の制御プログラム２Ｐを起動し、通知サーバ１にログインする。ユーザはログイン後に表示部２６に表示されたメニューから、くじ券登録を入力部２７で選択入力する。ユーザはユーザ端末２の撮像部２５を用いて、くじ券を撮影する。ユーザ端末２のＣＰＵ２１は撮像部２５から画像を取得し、通信部２８を介して通知サーバ１に画像を送信する。ユーザが複数枚のくじ券を登録する場合、複数回撮影を行う。この場合、画像の送信は撮影の都度行ってもよいし、すべてを撮影後にまとめて行ってもよい。ユーザは撮影が終了したら、表示部２６に表示されたメニューから、撮影終了を入力部２７で選択入力する。終了通知を受けた通知サーバ１のＣＰＵ１１はユーザ端末２から画像を取得する（ステップＳ１）。ＣＰＵ１１は処理対象とする画像を選択する（ステップＳ２）。ＣＰＵ１１はパターンＤＢ１４２に記憶されている特徴パターンを用いて、画像のパターンマッチングにより、宝くじの種別を判定する（ステップＳ３）。ＣＰＵ１１は判定種別に対応する抽出範囲を基に、必要な部分画像を切りだし、さらに文字認識技術を用いて、識別情報を抽出する（ステップＳ４）。ＣＰＵ１１は識別情報に含むくじ情報を一時記憶する（ステップＳ５）。くじ情報は名称、回数などである。宝くじが全国自治宝くじ、第７３１回の場合、全国自治、７３１がくじ情報として記憶される。既に同じ情報が一時記憶されている場合は、追加して記憶はしない。くじ情報はＲＡＭ１３や大容量記憶部１４などに設けた一時記憶領域に記憶される。ＣＰＵ１１は識別情報をユーザＩＤと対応付けて、くじＤＢ１４３に記憶する（ステップＳ６）。ＣＰＵ１１は未処理の画像があるか否かを判定する（ステップＳ７）。ＣＰＵ１１は未処理の画像があると判定した場合（ステップＳ７でＹＥＳ）、処理をステップＳ２に戻し、未処理の画像に対する処理を行う。ＣＰＵ１１は未処理の画像がないと判定した場合（ステップＳ７でＮＯ）、ＣＰＵ１１は一時記憶しているくじ情報を選択する（ステップＳ８）。一時記憶しているくじ情報が複数の場合は、１つの情報（例えば名称と回数とを含む１組の情報）をＣＰＵ１１は選択する。ＣＰＵ１１は選択したくじ情報に対応する宝くじを購入するために、ログインユーザが幾ら支出したかを算出し、くじＤＢ１４３の支出列に記憶する（ステップＳ９）。支出の算出は次のように行う。ＣＰＵ１１は選択したくじ情報及びログインユーザのユーザＩＤに対応する識別情報が、何レコード分、くじＤＢ１４３に記憶されているかを集計する。集計した枚数とくじ券１枚当たりの単価とを掛け合わせて、支出を求める。なお、単価が記憶されていない場合は、くじ情報を配信サーバ３に問い合わせて入手し、くじＤＢ１４３の該当するレコードの単価列に記憶する。ＣＰＵ１１はくじ情報に対応する宝くじが抽せん済であるか否かを判定する（ステップＳ１０）。抽せん済であるか否かは配信サーバ３に問い合わせて判定する。ＣＰＵ１１はくじ情報に対応する宝くじが抽せん済でないと判定した場合（ステップＳ１０でＮＯ）、処理をステップＳ１２に移す。ＣＰＵ１１はくじ情報に対応する宝くじが抽せん済であると判定した場合（ステップＳ１０でＹＥＳ）、当せん判定を行う（ステップＳ１１）。ＣＰＵ１１は未処理のくじ情報があるか否かを判定する（ステップＳ１２）。ＣＰＵ１１は未処理のくじ情報があると判定した場合（ステップＳ１２でＹＥＳ）、処理をステップＳ８に戻し、未処理のくじ情報に対応する処理を行う。ＣＰＵ１１は未処理のくじ情報がないと判定した場合（ステップＳ１２でＮＯ）、当せん判定がされた宝くじがあるか否かを判定する（ステップＳ１３）。判定は例えば一時記憶領域の記憶したフラグにより行う。くじ券登録処理の冒頭でフラグをクリアする。ステップＳ１１の当せん判定処理を実行したら、フラグを立てる。フラグが立っていればステップＳ１３ではＹＥＳとなり、フラグがクリアされていればステップＳ１３ではＮＯとなる。ＣＰＵ１１は当せん判定がされた宝くじがあると判定した場合（ステップＳ１３でＹＥＳ）、通知処理を実行し（ステップＳ１４）、くじ券登録処理を終了する。ＣＰＵ１１は当せん判定がされた宝くじがないと判定した場合（ステップＳ１３でＮＯ）、抽せんまで待つ必要がある旨の待ちメッセージをユーザ端末２に送信し（ステップＳ１５）、くじ券登録処理を終了する。

図８は当せん判定処理の手順例を示すフローチャートである。当せん判定処理はくじＤＢ１４３に記憶されている各くじ券が当せんしているか否かを判定する処理である。図７においては、ステップＳ１１に対応する処理である。ＣＰＵ１１は処理対象となる宝くじの当せん番号を取得する（ステップＳ２１）。処理対象となる宝くじの情報（名称、回数等）は当せん判定処理呼び出し時に引数等により渡されるものとする。当せん番号は配信サーバ３に宝くじの情報を送信して取得する。ＣＰＵ１１は宝くじの情報を基に判定対象となるくじ券のレコードをくじＤＢ１４３から抽出する（ステップＳ２２）。ＣＰＵ１１は抽出したレコードから処理対象とするレコードを選択する（ステップＳ２３）。ＣＰＵ１１は選択したレコードの組、番号等を当せん番号と照合する（ステップＳ２４）。ＣＰＵ１１は照合の結果、くじ券が当せんしているか否かを判定する（ステップＳ２５）。ＣＰＵ１１はくじ券が当せんしていないと判定した場合（ステップＳ２５でＮＯ）、処理をステップＳ２７へ移す。ＣＰＵ１１はくじ券が当せんしていると判定した場合（ステップＳ２５でＹＥＳ）、当せん実績をくじＤＢ１４３に記憶する（ステップＳ２６）。ここでは、等級列に当せんした等数を示す数字を記憶する。当せん金列に当せんして得られる当せん金の金額を記憶する。ＣＰＵ１１は当落を当落列に記憶する（ステップＳ２７）。ＣＰＵ１１は未処理のくじ券のレコードがあるか否かを判定する（ステップＳ２８）。ＣＰＵ１１は未処理のくじ券のレコードがあると判定した場合（ステップＳ２８でＹＥＳ）、処理をステップＳ２３に戻し、未処理のくじ券のレコードに対する処理を行う。ＣＰＵ１１は未処理のくじ券のレコードがないと判定した場合（ステップＳ２８でＮＯ）、当せん判定処理を終了し、処理を呼び出し元に戻す。

図９は通知処理の手順例を示すフローチャートである。通知処理はくじの当落結果をユーザに通知する処理である。通知処理は、図７においては、ステップＳ１４に対応する処理である。通知サーバ１のＣＰＵ１１は処理対象とするユーザＩＤを取得する（ステップＳ４１）。処理対象のユーザＩＤは通知処理が呼び出されるときに、引数等で渡される。ＣＰＵ１１は対象となるくじデータを抽出する（ステップＳ４２）。対象となるくじデータは、対象となるユーザのユーザＩＤがユーザＩＤ列に記憶され、当落列に当落が記憶されており、通知列が未通知になっているレコードである。ＣＰＵ１１は抽出したレコードの中に当せんがあるか否かを判定する（ステップＳ４３）。すなわち、当落列に当たりが記憶されているレコードがあるか否かを判定する。ＣＰＵ１１は抽出したレコードの中に当せんがあると判定した場合（ステップＳ４３でＹＥＳ）、当せんメッセージを生成する（ステップＳ４４）。当せんメッセージには、「宝くじに当せんしました。」などの当たりを伝える内容を含む。当せんメッセージには、くじの名称、等級、当せん金などを含めてもよい。ＣＰＵ１１は抽出したレコードの中に当せんがないと判定した場合（ステップＳ４３でＮＯ）、落せんメッセージを生成する（ステップＳ４５）。落せんメッセージには、「残念ながら、宝くじに落せんしました。」などの外れたことを伝える内容を含む。ＣＰＵ１１は対象ユーザがログイン中か否かを判定する（ステップＳ４６）。ＣＰＵ１１は対象ユーザがログイン中であると判定した場合（ステップＳ４６でＹＥＳ）、ユーザ端末２に当せんメッセージ又は落せんメッセージを送信する（ステップＳ４７）。ＣＰＵ１１はくじＤＢ１４３において、対象となるくじのレコードの通知列に通知済を記憶する（ステップＳ４８）。ＣＰＵ１１は通知処理を終了し、処理を呼び出し元に戻す。ＣＰＵ１１は対象ユーザがログイン中でないと判定した場合（ステップＳ４６でＮＯ）、対象ユーザが希望する通知方法をユーザＤＢ１４１から取得する（ステップＳ４９）。ＣＰＵ１１は通知方法が電子メールであるか否かを判定する（ステップＳ５０）。ＣＰＵ１１は通知方法が電子メールであると判定した場合（ステップＳ５０でＹＥＳ）、メッセージを電子メールで送信する（ステップＳ５１）。ＣＰＵ１１は処理をステップＳ４８に移す。ＣＰＵ１１は通知方法が電子メールでないと判定した場合（ステップＳ５０でＮＯ）、通知方法はプッシュ通知であるか否かを判定する（ステップＳ５２）。ＣＰＵ１１は通知方法がプッシュ通知であると判定した場合（ステップＳ５２でＹＥＳ）、メッセージをプッシュ通知で送信する（ステップＳ５３）。ＣＰＵ１１は処理をステップＳ４８に移す。ＣＰＵ１１は通知方法がプッシュ通知でないと判定した場合（ステップＳ５２でＮＯ）、通知処理を終了し、処理を呼び出し元に戻す。ステップＳ５２でＮＯとなる場合は、ユーザの希望する通知方法が、通知サーバ１のログイン時である。対象ユーザが次回、通知サーバ１にログインした場合に、通知がされる。この場合に備えて、ステップＳ４４又はＳ４５で生成したメッセージを大容量記憶部１４に記憶してもよい。

続いて、抽選日処理について説明する。抽選日処理は宝くじの抽選日に行われる処理である。抽選結果に基づき、当せん判定を行い、くじの購入ユーザに通知を行う。図１０は抽選日処理の手順例を示すフローチャートである。通知サーバ１のＣＰＵ１１は、抽選が行われた宝くじのくじ情報（名称、回数など）を取得する（ステップＳ６１）。ＣＰＵ１１は当せん判定処理を行う（ステップＳ６２）。当せん判定処理は図８に示したとおりである。ＣＰＵ１１は当せん判定したくじを購入したユーザを抽出する（ステップＳ６３）。ＣＰＵ１１はユーザを選択する（ステップＳ６４）。ＣＰＵ１１は選択したユーザを対象に通知処理を行う（ステップＳ６５）。ＣＰＵ１１は未処理のユーザがあるか否かを判定する（ステップＳ６６）。ＣＰＵ１１は未処理のユーザがあると判定した場合（ステップＳ６６でＹＥＳ）、処理をステップＳ６４に戻し、未処理のユーザに対する処理を行う。ＣＰＵ１１は未処理のユーザがないと判定した場合（ステップＳ６６でＮＯ）、抽選日処理を終了する。

以上のように、本実施の形態においては、宝くじを購入したユーザはくじ券の識別情報の部分を撮影し、通知サーバ１に送信する。宝くじが既に抽せん済みの場合、ユーザはすぐに購入した宝くじの当落を知ることが可能となる。また、抽せん結果が出ていない宝くじについては、抽せんが行われた後に速やかに、通知サーバ１は通知を行う。ユーザは抽せん後、すぐに購入した宝くじの当落を知ることが可能となる。ユーザ端末２がスマートフォンの場合、通知方法をプッシュ通知としていれば、画面がロック画面となっているときや他のアプリケーション実行しているときでも、当落の通知を受け取ることが可能である。

通知サーバ１は複数の画像をユーザ端末２からすべて受信してから処理を行ったが、それに限らない。ユーザ端末２が画像を撮影する度に送信してくる場合、画像を受信する度にステップＳ１からステップＳ６の処理を繰り返してもよい。そして、撮影終了をユーザ端末２から受信したら、ＣＰＵ１１はステップＳ８以降を実行する。

さらに、上述した処理を次のように組み合わせることにより、ユーザは当せんくじ券と落せんしたくじ券とを仕分け可能である。ユーザはユーザ端末２の撮像部２５でくじ券の識別情報を撮影し、通知サーバ１に送信する。通知サーバ１は送信された画像を基に、くじ券の当せん判定を行い、当落をユーザ端末２に返信する。ユーザ端末２は当落を表示部２６に表示する。ユーザは表示された当落により、くじ券の仕分けが行うことが可能となる。

以上の説明では宝くじについて説明したが、競輪やオートレースの車券、競馬の馬券、競艇の舟券についても、同様な処理により、当落の判定を行い、ユーザに通知することが可能である。

図１１は車券ＤＢの例を示す説明図である。車券ＤＢ１４４はユーザが購入した車券の情報を記憶する。車券ＤＢ１４４はユーザＩＤ列、日付列、開催場所列、グレード列、種目列、レース番号列、名称列、賭式列、番号列、入金額列、当落列、払戻金列及び払戻総額列を含む。ユーザＩＤ列はユーザＩＤを記憶する。日付列はレースの開催日を記憶する。開催場所列は開催レース場の名称を記憶する。グレード列はレースのグレードを記憶する。グレードは例えばＧ１、Ｇ２などである。種目列はレースの種目を記憶する。レース番号列はレース番号を記憶する。名称列はレースの名称を記憶する。賭式列はユーザが選択した賭式を記憶する。賭式とは、例えば３連単や２枠複である。３連単は車番で１・２・３着を着順どおりに予想し、的中させる賭式である。２枠複は枠番で着順にかかわらず１〜２着を予想し、的中させる賭式である。番号列はユーザが賭けた番号を記憶する。賭式が３連単であれば、車番を３つ記憶する。２枠複であれば、枠番を２つ記憶する。入金額列は賭けた金額を記憶する。当落列は賭けが当たったか否かを記憶する。払戻金列は払戻金額を記憶する。払戻金額は、当たった場合において、所定の賭金に対して払い戻される金額を記憶する。例えば、１００円賭けた場合に払い戻される金額を記憶する。払戻総額列はユーザが払い戻しにより得た払戻金の総額を記憶する。払戻金の総額は入金額と払戻金から算出可能である。

図１２は馬券ＤＢの例を示す説明図である。馬券ＤＢ１４５はユーザが購入した馬券の情報を記憶する。馬券ＤＢ１４５はユーザＩＤ列、日付列、開催場所列、回数列、日列、レース番号列、グレード列、名称列、賭式列、番号列、入金額列、当落列、払戻金列及び払戻総額列を含む。ユーザＩＤ列はユーザＩＤを記憶する。日付列は開催日を記憶する。開催場所列はレース開催場所の競馬場名を記憶する。回数列は開催回数を記憶する。日列は開催回において、何日目であるかを示す数字を記憶する。レース番号列はレース番号を記憶する。グレード列はレースのグレードを記憶する。名称列はレースの名称を記憶する。賭式列はユーザが選択した賭式を記憶する。番号列、入金額列、当落列、払戻金列、払戻総額列はそれぞれ車券ＤＢ１４４の同名の列と同様であるから、説明を省略する。

図１３は舟券ＤＢの例を示す説明図である。舟券ＤＢ１４６はユーザが購入した舟券の情報を記憶する。舟券ＤＢ１４６はユーザＩＤ列、レース場列、グレード列、日付列、レース番号列、回数列、名称列、式別列、番号列、入金額列、当落列、払戻金列及び払戻総額列を含む。ユーザＩＤ列はユーザＩＤを記憶する。レース場列はレース開催場所のレース場の名称を記憶する。グレード列はレースのグレードを記憶する。日付列は開催日を記憶する。レース番号列はレース番号を記憶する。回数列は開催回数を記憶する。名称列はレースの名称を記憶する。式別列はユーザが選択した式別を記憶する。式別は、車券、馬券の賭式と同様な概念である。番号列、入金額列、当落列、払戻金列、払戻総額列はそれぞれ車券ＤＢ１４４の同名の列と同様であるから、説明を省略する。

次に、くじ券及びくじ券以外の車券等を登録する処理について、説明する。図１４及び図１５は登録処理の手順例を示すフローチャートである。図１４及び図１５に示す処理は、図７を用いて説明したくじ券登録処理を拡張したものである。以下の説明では、くじ券登録処理と異なる点を主として説明する。

通知サーバ１のＣＰＵ１１は、券種、入力形式を取得する（ステップＳ７１）。券種とは、例えば、くじ券、車券、馬券、舟券である。入力形式は画像入力、テキスト入力などである。ＣＰＵ１１は入力形式が画像入力か否かを判定する（ステップＳ７２）。ＣＰＵ１１は入力形式が画像入力と判定した場合（ステップＳ７２でＹＥＳ）、ユーザ端末２から画像を取得する（ステップＳ７３）。ＣＰＵ１１は処理対象とする画像を選択する（ステップＳ７４）。ＣＰＵ１１は券種がくじ券か否かを判定する（ステップＳ７５）。ＣＰＵ１１は券種がくじ券であると判定した場合（ステップＳ７５でＹＥＳ）、宝くじの種別を判定し（ステップＳ７６）、処理をステップＳ７７に進める。ＣＰＵ１１は券種がくじ券でないと判定した場合（ステップＳ７５でＮＯ）、識別情報を抽出する（ステップＳ７７）。くじ券以外の車券等の識別情報を抽出するための特徴パターン等の情報は、くじ券と同様に、パターンＤＢ１４２等に記憶しておく。なお、発売場所により、券面のレイアウトが異なる場合は、宝くじの種別判定と同様に発売場所の判定を行う。ＣＰＵ１１はくじ、レース情報を一時記憶する（ステップＳ７８）。既に同じ情報が一時記憶されている場合は、追加して記憶はしない。ＣＰＵ１１は識別情報を記憶する（ステップＳ７９）。識別情報は車券であれは、開催場所、種目、レース番号、賭式、番号、入金額など、当落判定に必要な情報及びユーザが支出した金額の情報である。車券の識別情報は車券ＤＢ１４４に記憶する。ＣＰＵ１１は未処理の画像があるか否かを判定する（ステップＳ８０）。ＣＰＵ１１は未処理の画像があると判定した場合（ステップＳ８０でＹＥＳ）、処理をステップＳ７４に戻す。ＣＰＵ１１は未処理の画像がないと判定した場合（ステップＳ８０でＮＯ）、処理をステップＳ８４に進める。ステップＳ７３、Ｓ７４、Ｓ７６からＳ８０は、それぞれ図７のステップＳ１、Ｓ２、Ｓ３からＳ７と同様な処理である。

ＣＰＵ１１は入力形式が画像入力でないと判定した場合（ステップＳ７２でＮＯ）、識別情報を入力するための入力画面を、ユーザ端末２へ出力する（ステップＳ８１）。ユーザはユーザ端末２において、表示部２６に表示された入力画面に、入力部２７を用いて購入した券の識別情報を入力する。入力が完了したら、通知サーバ１に送信する。ＣＰＵ１１はユーザ端末２から送信された識別情報のうち、くじ、レース情報を一時記憶する（ステップＳ８２）。既に同じ情報が一時記憶されている場合は、追加して記憶はしない。ＣＰＵ１１は識別情報を券種に応じたデータベースに記憶する（ステップＳ８３）。ＣＰＵ１１は処理をステップＳ８４に進める。ＣＰＵ１１は一時記憶しているくじ、レース情報を１つ選択する（ステップＳ８４）。ＣＰＵ１１は選択したくじ、レース情報に対応する券を購入するために、ユーザが幾ら支出したかを算出し、券種に対応するデータベースの支出列に記憶する（ステップＳ８５）。支出額の算出方法は、図７のステップＳ９と同様である。図１５に移り、ＣＰＵ１１はくじ券の当落が既に判明しているか否かを判定する（ステップＳ８６）。車券、馬券、舟券などの場合は、レースが終了し払戻金が確定しているか、配信サーバ３に問い合わせて、判定する。ＣＰＵ１１はくじ券の当落が既に判明していると判定した場合（ステップＳ８６でＹＥＳ）、当落判定を行う（ステップＳ８７）。当落判定処理は、くじ券以外の券においても、図８で参照して説明したくじ券の当せん判定と同様な処理であるので、説明を省略する。ＣＰＵ１１はくじ券の当落が既に判明していないと判定した場合（ステップＳ８６でＮＯ）、処理をステップＳ８８に移す。ＣＰＵ１１は未処理のくじ、レース情報があるか否かを判定する（ステップＳ８８）。ＣＰＵ１１は未処理のくじ、レース情報があると判定した場合（ステップＳ８８でＹＥＳ）、処理をステップＳ８４に戻す。ＣＰＵ１１は未処理のくじ、レース情報がないと判定した場合（ステップＳ８８でＮＯ）、当落判定を実行した否かを判定する（ステップＳ８９）。ＣＰＵ１１は当落判定を実行したと判定した場合（ステップＳ８９でＹＥＳ）、当落を通知し（ステップＳ９０）、登録処理を終了する。通知の処理は、くじ券以外の券においても、図９で参照して説明したくじ券の通知と同様な処理であるので、説明を省略する。ＣＰＵ１１は当落判定を実行していないと判定した場合（ステップＳ８９でＮＯ）、当落が判明するまで待つ必要がある旨の待ちメッセージをユーザ端末２に送信し（ステップＳ９１）、登録処理を終了する。

以上のように、車券ＤＢ１４４、馬券ＤＢ１４５及び舟券ＤＢ１４６は、各レースを識別するための情報、及びユーザが賭けた内容と入金額を記憶する。それにより、宝くじの場合と同様に、レース結果（宝くじの抽選結果に相当）及び払戻金（当せん金に相当）と車券ＤＢ、馬券ＤＢ及び舟券ＤＢの番号情報とを対照することにより、賭けの当たりを判定し、結果を通知することが可能となる。

ここで、通知画面の例を示す。図１６は当せん通知画面の例を示す説明図である。当せん通知画面は２つの画面を含む。図１６Ａは第１画面を示し、図１６Ｂは第２画面を示している。第１画面は抽選結果が出ていることを示す。第１画面はくじ表示領域２１６、参照ボタン２６２及び保留ボタン２６３を含む。くじ表示領域２１６には抽選結果が出ているくじの名称、回数等を表示する。参照ボタン２６２は抽選結果を表示する第１画面へ遷移するためのボタンである。参照ボタン２６２をマウスクリックなどで操作すると、第２画面に遷移する。保留ボタン２６３は結果表示を保留するボタンである。保留ボタン２６３をマウスクリックなどで操作すると、第２画面以外の画面に遷移する。第２画面は、当せん本数表示領域２６４と当せん金表示領域２６５とを含む。当せん本数表示領域２６４は、当せんした宝くじの等級と本数とを表示する。当せん金表示領域２６５には、当せん金の合計を表示する。

図１７は当落一覧画面の例を示す説明図である。当落一覧画面は一覧表２６６を含む。必要に応じて、当落一覧画面にはスクロールバー２６７が表示される。一覧表２６６はくじ券毎に当落が表示される。当せんしたくじについては、当せんした等級と当せん金とが表示される。ユーザ購入したくじ券の枚数が多く、１画面に収まらない場合は、スクロールバー２６７が表示される。スクロールバー２６７を操作することにより、表示されていないくじ券の当落を確認可能となる。

また、通知の機能としては、宝くじの発売予定や競輪、オートレース、競馬、競艇などの公営競技の開催予定を通知してもよい。図１８は予定通知処理の手順例を示すフローチャートである。ＣＰＵ１１は配信サーバ３から宝くじの発売予定を取得する（ステップＳ１０１）。ＣＰＵ１１は取得した予定の中で、発売予定開始日が所定日前（例えば、３日前）のものがあるか判定する（ステップＳ１０２）。ＣＰＵ１１は発売予定開始日が所定日前のものがあると判定した場合（ステップＳ１０２でＹＥＳ）、通知メッセージを生成する（ステップＳ１０３）。通知メッセージは例えば、「年末○○宝くじ、いよいよ３日後の２７日から発売開始！！」である。ＣＰＵ１１は発売予定開始日が所定日前のものがないと判定した場合（ステップＳ１０２でＮＯ）、販売最終日前日であるか否かを判定する（ステップＳ１０４）。ＣＰＵ１１は、販売最終日前日であると判定した場合（ステップＳ１０４でＹＥＳ）、通知メッセージを生成する（ステップＳ１０５）。通知メッセージは例えば、「年末○○宝くじ、とうとう明日が販売最終日。お買い忘れではありませんか。」である。ＣＰＵ１１は対象ユーザを抽出する（ステップＳ１０６）。抽出条件は、過去に宝くじを購入したことのあるユーザである。これは、くじＤＢ１４３に記憶されている過去のデータを利用すればよい。最終日前の通知の場合、くじＤＢ１４３を検索し、既に宝くじを購入済みのユーザは通知対象から外してもよい。

ＣＰＵ１１は販売最終日前日でないと判定した場合（ステップＳ１０４でＮＯ）、配信サーバ３からレース開催予定を取得する（ステップＳ１０７）。ＣＰＵ１１は取得した予定の中で、開催初日から所定日前（例えば、３日前）のものがあるか判定する（ステップＳ１０８）。ＣＰＵ１１は開催初日から所定日前のものがあると判定した場合（ステップＳ１０８でＹＥＳ）、通知メッセージを生成する（ステップＳ１０９）。通知メッセージは例えば、「×△選手権レース、いよいよ３日後の２７日から開催！！」である。ＣＰＵ１１は開催初日から所定日前のものがないと判定した場合（ステップＳ１０８でＮＯ）、開催最終日前日であるか否かを判定する（ステップＳ１１０）。ＣＰＵ１１は、開催最終日前日であると判定した場合（ステップＳ１１０でＹＥＳ）、通知メッセージを生成する（ステップＳ１１１）。通知メッセージは例えば、「×△選手権レース、とうとう明日が開催最終日。投票はお済みですか。」である。ＣＰＵ１１は対象ユーザを抽出する（ステップＳ１１２）。抽出条件は、過去に券を購入したことのあるユーザである。これは、車券ＤＢ１４４に記憶されている過去のデータを利用すればよい。最終日前の通知の場合、車券ＤＢ１４４を検索し、既に投票済みのユーザは通知対象から外してもよい。ステップＳ１０７からステップＳ１１２までの処理は、競技別に行う。

ＣＰＵ１１は対象ユーザを整理する（ステップＳ１１３）。マージの際、通知メッセージ毎に、対象ユーザをグループ分けする。例えば、宝くじの通知のみが対象のグループ、宝くじと競馬の通知が対象のグループは別になる。ＣＰＵ１１は、グループ毎にメッセージをマージする（ステップＳ１１４）。ＣＰＵ１１はメッセージを配信し（ステップＳ１１５）、予定通知処理を終了する。ＣＰＵ１１は、開催最終日前日でないと判定した場合（ステップＳ１１０でＮＯ）、予定通知処理を終了する。

予定通知機能により、宝くじ、車券、馬券、舟券の販売促進が行える。通知対象は過去に購入履歴のあるユーザとしたが、当せん金が大きな宝くじの場合は、宝くじが購入したことのないユーザに通知してもよい。車券、馬券、舟券については、ＧＩレースのようにグレードの高いレースの場合は、これらの券を購入したことのないユーザに通知してもよい。

くじＤＢ１４３、車券ＤＢ１４４、馬券ＤＢ１４５、舟券ＤＢ１４６に蓄積したデータを活用することにより、ユーザの収支を管理可能である。図１９は算出処理の手順例を示すフローチャートである。ＣＰＵ１１は処理対象となるユーザのユーザＩＤを取得する（ステップＳ１２１）。ＣＰＵ１１は算出する期間を取得する（ステップＳ１２２）。期間は全期間、過去１年間、過去半年、過去３ヶ月、過去１ヶ月などである。ＣＰＵ１１は算出対象とする券種や算出内容を取得する（ステップＳ１２３）。算出内容とは、収支、損益、累積損益などである。ＣＰＵ１１は算出を行う（ステップＳ１２４）。ＣＰＵ１１は結果出力する（ステップＳ１２５）。複数の期間、複数の券種、複数の算出内容で算出を行う場合は、ステップＳ１２４、Ｓ１２５を必要回、繰り返す。ステップＳ１２５の結果出力については、グラフ等で複数の結果を１つまとめられる場合は、まとめてもよい。

図２０は収支状況グラフの例を示す説明図である。縦軸は金額であり、単位は円である。横軸は日付である。折れ線グラフは日毎の損益を示す。棒グラフは累積の収支を示す。収支は、宝くじ、競輪、競馬、競艇毎に計算して、それぞれについて図２０に示すグラフを作成表示してもよい。また、宝くじ、競輪、競馬、競艇の区別なく集計した上で、図２０に示すグラフをそれぞれ表示してもよい。

図２１は支出状況のグラフの例を示す説明図である。図１５のように、ジャンル毎に支出状況を一目で確認可能となる。

上述の予定通知処理において、ユーザの収支や支出状況を活用してもよい。例えば、宝くじの販売予定は宝くじをよく買うユーザに配信するが、宝くじの収支が悪い場合は、ユーザ住所から近い場所で行われるレースの開催予定を配信してもよい。レース開催予定については、ユーザがよく賭けているレースのレース開催場所の予定だけでなく、Ｇ１レースによく賭けるユーザには、全国のＧ１レースの情報を配信する。競艇しかしないユーザであっても、Ｇ１レースによく賭けるユーザには、他の競技、例えば競馬のＧ１レースの開催予定を配信してもよい。

収支を管理する内容として、遊技の結果を加えてもよい。図２２は遊技結果ＤＢの例を示す説明図である。遊技結果ＤＢ１４７はユーザの遊技結果（遊技の収支）を記憶する。遊技結果ＤＢ１４７はユーザＩＤ列、日付列、ホール列、区別列、種別列、機種名列、貸し料金列、投入金額列及び換金額列を含む。ユーザＩＤ列はユーザＩＤを記憶する。日付列は遊技した日付を記憶する。ホール列は遊技した遊技ホールの名称を記憶する。区別列は遊技した遊技機がパチンコであったか、スロットであったかを記憶する。種別列は遊技した遊技機のパチンコ機又はスロット機における種別を記憶する。機種名列は遊技した遊技機の名称を記憶する。貸し料金列は遊技球又は遊技メダルの貸出料金を記憶する。投入金額列は遊技に投入した金額を記憶する。換金額列は遊技終了後に特殊景品を交換所で売却して得た金額を記憶する。

遊技結果ＤＢ１４７の記憶する内容は、ユーザ端末２を用いてユーザが行う。遊技結果ＤＢ１４７を用いることにより、宝くじと同様に収支を管理することが可能なる。遊技結果以外に、ユーザが有する金融商品の損益を管理するようにしてもよい。金融商品とは、株式、投資信託、ＦＸ、仮想通貨などである。金融商品の損益は、取得価額と評価価額から算出する。

さらに、また、ユーザの支出動向に応じて、ユーザに広告配信を行ってもよい。図２３は広告配信処理の手順例を示すフローチャートである。ＣＰＵ１１は配信する広告と配信条件を取得する（ステップＳ１３１）。ＣＰＵ１１は配信条件にユーザの属性条件を含むか判定する（ステップＳ１３２）。属性条件とは、例えば、２０代女性である。ＣＰＵ１１は配信条件にユーザの属性条件を含むと判定した場合（ステップＳ１３２でＹＥＳ）、ユーザＤＢ１４１を参照して、対象ユーザを抽出する（ステップＳ１３３）。ＣＰＵ１１は配信条件にユーザの属性条件を含まないと判定した場合（ステップＳ１３２でＮＯ）、処理をステップＳ１３４に移す。ＣＰＵ１１は配信条件に支出動向を含むか判定する（ステップＳ１３４）。支出動向とは、例えば、１ヶ月間に競馬に１０万円以上投資するユーザである。ＣＰＵ１１は配信条件に支出動向を含むと判定した場合（ステップＳ１３４でＹＥＳ）、必要なデータベースを参照して、対象ユーザを抽出する（ステップＳ１３５）。上述の例では、馬券ＤＢ１４５を参照して、ユーザ毎、１ヶ月平均の入金額を算出する。そして、算出した平均額が１０万円以上のユーザを抽出する。ＣＰＵ１１は配信条件に支出動向を含まないと判定した場合（ステップＳ１３４でＮＯ）、処理をステップＳ１３６に移す。ＣＰＵ１１は配信条件に損益状況を含むか判定する（ステップＳ１３６）。損益状況とは、例えば、３ヶ月間の競馬の損益が儲け５０万円以上のユーザである。ＣＰＵ１１は配信条件に損益状況を含むと判定した場合（ステップＳ１３６でＹＥＳ）、必要なデータベースを参照して、対象ユーザを抽出する（ステップＳ１３７）。上述の例では、馬券ＤＢ１４５を参照して、ユーザ毎に直近３ヶ月の損益を算出する。そして、算出した損益が＋５０万円以上のユーザを抽出する。ＣＰＵ１１は配信条件に損益状況を含まないと判定した場合（ステップＳ１３６でＮＯ）、処理をステップＳ１３８に移す。ＣＰＵ１１は対象ユーザを整理する（ステップＳ１３８）。整理とは、ステップＳ１３３、Ｓ１３５、Ｓ１３７で抽出した各ユーザの集合の和集合や積集合を生成することである。例えば、２０代女性で、競馬に１ヶ月に１０万円以上投資し、３ヶ月で５０万以上儲けたユーザの場合は、３つの集合（ステップＳ１３３、Ｓ１３５、Ｓ１３７それぞれで生成した集合）の積集合となる。また、２０代女性で、競馬に１ヶ月に１０万円以上投資するか、３ヶ月で５０万以上儲けたユーザであれば、ステップＳ１３５とＳ１３７とで生成した集合の和集合を求め、求めた和集合とステップＳ１３３で生成した集合との積集合が最終的な集合である。ＣＰＵ１１は対象ユーザに広告を配信し（ステップＳ１３９）、広告配信処理を終了する。

広告配信の例としては次のようなものが考えられる。２０代女性で、競馬に１ヶ月に１０万円以上投資するか、３ヶ月で５０万以上儲けたユーザに、場外馬券売り場近くのアクセサリー店の広告を軽信する。定期的にユーザが良く行くと推測される競馬場周辺の飲食店の情報を配信する。高額な当せん金を得たユーザには、投資先として金融商品についての広告を配信する。さらに、同じ属性をもったユーザ毎の支出状況や収支状況を分析し、出力してもよい。例えば、支出額を見ることにより、可処分所得の額を推測することが可能となる。そして、その額に応じた商品やサービスの広告を配信すれは、商品購入やサービス利用を促進することが可能となる。

（はがきくじ）
通知システム１００は、上述した宝くじ以外のくじへの適用も可能である。ここでは、くじ引番号付き郵便はがきについて述べる。当該はがきの例として、年賀はがき（お年玉付郵便はがき）の場合を説明するが、夏のおたより郵便はがきかもめ〜る（登録商標）の場合も、同様である。

図２４はくじ付きはがきＤＢの例を示す説明図である。くじ付きはがきＤＢ１４８はくじ引番号付き郵便はがきの情報を記憶する。くじ付きはがきＤＢ１４８は例えば、大容量記憶部１４に記憶する。くじ付きはがきＤＢ１４８は、ユーザＩＤ列、種別列、年列、送受列、メモ列、組列、番号列、当落列、等級列及び通知列を含む。ユーザＩＤ列ははがきを送った又は受け取ったユーザのユーザＩＤを記憶する。種別列はくじ引番号付き郵便はがきの種別を記憶する。種別は例えば、年賀、かもめーるである。年列はくじ引番号付き郵便はがきが発売された年を記憶する。送受列は送受の区別を記憶する。例えば、ユーザが送ったはがきについては、送受列は送を記憶する。ユーザが受け取ったはがきについては、送受列は受を記憶する。メモ列はユーザがはがきを送った相手、又はユーザがはがきを受け取った相手を記憶する。組列はくじ引番号に付された組を記憶する。番号列はくじ引番号の番号を記憶する。当落列はくじ引の当落を記憶する。例えば、当せんの場合には当を、落せんの場合には落を、当落列は記憶する。等級列は当落した場合に、当せん級を記憶する。通知例は当落の通知を行ったか否かを記憶する。

ユーザはくじ引番号付き郵便はがきを購入した際、又は投函前に、くじ引番号を登録する。くじ引き番号を登録する処理は、図７を用いて説明したくじ券登録処理と同様であるから、説明を省略する。また、ユーザはくじ引番号付き郵便はがきを受領した際、くじ引番号を登録する。くじの抽選日になると、当落の判定処理が実行された結果が通知される。くじ引き番号の当せん判定処理は、図８を用いて説明した当せん判定処理と同様であるから、説明を省略する。当せん結果の通知処理は、図９を用いて説明した通知処理と同様であるから、説明を省略する。抽選日に行う処理は、図１０で示した抽選日処理と同様であるから、説明を省略する。ユーザがくじ引番号を登録したのが、抽選日後の場合、速やかに当せん判定処理、通知処理が実行される。

図２５は当せん通知画面の他の例を示す説明図である。当せん通知画面は第１当落一覧表２６８１と第２当落一覧表２６８２とを含む。第１当落一覧表２６８１はユーザが受領したはがきの当落が表示される。第２当落一覧表２６８２はユーザが差し出したはがきの当落が表示される。

当せん通知画面は一覧表示に限らない。全てのはがきの当落ではなく、ユーザが受け取った又は送ったはがきの中で、当せんがあったか否かの表示でもよい。ユーザが受け取ったはがきの中で当せんがあった場合、当せんした賞品を３Ｄ（ｔｈｒｅｅ−ｄｉｍｅｎｓｉｏｎａｌ） ＶＲ（Ｖｉｒｔｕａｌ Ｒｅａｌｉｔｙ）技術により表示してもよい。複数の賞品から選べる場合には、個々の賞品を数秒ずつ繰り返し表示しても良い。賞品の３Ｄ画像データは通知サーバ１又ははがき販売者のサーバから取得する。

くじ引番号付き郵便はがきの場合、以下の効果を奏する。ユーザは受け取ったはがきについているくじが当せんしているか否かを迅速に調べることが可能となる。抽選日前にくじを登録しておけば、当せん番号が発表された後に速やかに当落を知ることが可能となる。また、登録時に送付人の情報を登録した場合、当せんしたはがきを送った人も通知可能となるので、当せんしたはがきを容易に見つけることが可能となる。また、ユーザは他者に送るはがきのくじ番号を投函前に登録しておけば、誰に送ったはがきが当せんしたかを知ることが可能となる。

当せんした場合に、賞品を３Ｄ ＶＲ（３次元の仮想現実空間）で表示することにより、当せんした場合にユーザにより大きな喜びを与えることが期待できる。

（結果表示の他の例）
宝くじや年賀はがきの結果表示の他の例について説明する。ユーザに当せんへの期待を抱かせるように、結果表示を動画で行ってもよい。図２６は当せん通知画面の他の例を示す説明図である。図２６は宝箱を用いた例である。結果を通知する際に、まず図２６Ａに示すように閉じた宝箱を表示する。ユーザが画面をタッチするなどのアクションを行うと、鍵を開けて宝箱が開く動画を表示する。宝箱が開いた後、宝箱の状態で当落を表現する。図２６Ｂは宝くじが当せんした場合の表示の例である。宝箱に金貨が入っている表示をすることで、当せんしたことを表している。当せん金の大小で金貨の量を変えても良い。図２６Ｃは年賀はがきのくじが当せんした場合の例である。宝箱が開いた後に、当せんした賞品が宝箱から現れる。賞品が複数のものから選択できる場合は、選択できる賞品を所定時間毎に変えて表示しても良い。動画表示を３Ｄ ＶＲ表示としてもよい。

（レース動画表示）
車券等を登録して当たり・外れの結果を表示するに際して、レース動画を表示しても良い。図２７は登録通知処理の手順例を示すフローチャートである。登録通知処理は図１４及び図１５に示した登録処理と類似する処理である。

ユーザはユーザ端末２の撮像部２５で車券を撮影し、通知サーバ１に送信する通知サーバ１のＣＰＵ１１は、ユーザ端末２から画像を取得する（ステップＳ１５１）。ＣＰＵ１１は処理対象とする画像を選択する（ステップＳ１５２）。ＣＰＵ１１は車券情報を抽出する（ステップＳ１５３）。開催場所、種目、レース番号、賭式、番号額など、当落判定に必要な情報である。ＣＰＵ１１は開催場所、種目、レース番号のレース情報を一時記憶する（ステップＳ１５４）。ＣＰＵ１１は識別情報を記憶する（ステップＳ１５５）。識別情報は車券情報及びユーザが支出した金額の情報である。車券の識別情報は車券ＤＢ１４４に記憶する。ＣＰＵ１１は未処理の画像があるか否かを判定する（ステップＳ１５６）。ＣＰＵ１１は未処理の画像があると判定した場合（ステップＳ１５６でＹＥＳ）、処理をステップＳ１５２に戻す。ＣＰＵ１１は未処理の画像がないと判定した場合（ステップＳ１５６でＮＯ）、一時記憶しているレース情報を１つ選択する（ステップＳ１５７）。ＣＰＵ１１は車券の当たり・外れの結果が判明済みか否かを判定する（ステップＳ１５８）。ＣＰＵ１１は、レースが終了し払戻金が確定しているか、配信サーバ３に問い合わせて、判定する。ＣＰＵ１１は結果判明済みでないと判定した場合（ステップＳ１５８でＮＯ）、待ちメッセージをユーザ端末２に送信し（ステップＳ１６３）、処理をステップＳ１６１へ移す。ＣＰＵ１１は結果判明済みと判定した場合（ステップＳ１５８でＹＥＳ）、当たり・外れの判定を行う（ステップＳ１５９）。ＣＰＵ１１はレース動画と判定結果をユーザ端末２に送信する（ステップＳ１６０）。ＣＰＵ１１は未処理のレース情報があるか否かを判定する（ステップＳ１６１）。ＣＰＵ１１は未処理のレース情報があると判定した場合（ステップＳ１６１でＹＥＳ）、処理をステップＳ１５７に戻す。ＣＰＵ１１は未処理のレース情報がないと判定した場合（ステップＳ１６１でＮＯ）、終了をユーザ端末２に通知し（ステップＳ１６２）、処理を終了する。

終了の通知を受けたユーザ端末２は、結果判明済みのレースについては、レース動画を再生し、再生後に当たり・外れを表示する。結果判明済みでないレースについては、待ちメッセージを表示する。待ちメッセージは、レース開催まで待つ必要があることを示す内容を含む。上述の説明では、一時記憶したレース情報の全ての処理をしてから、ユーザ端末２はレース動画の再生等を行うとしたが、それに限らない。ユーザ端末２は、通知サーバ１から１つのレースについての動画、判定結果を取得する毎に、動画再生等の処理を行っても良い。通知サーバ１はレース動画を送信するのではなく、レース動画を視聴可能な動画配信サイトヘのリンク情報を送信しても良い。リンク情報は例えばＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ）である。

結果が判明していないレースに関しては、レース結果の確定後、ステップＳ１５７からステップＳ１６０の処理をＣＰＵ１１が実行し、結果をユーザ端末２へ送信する。また、レース直前に、通知サーバ１からユーザ端末２にプッシュ通知を行い、ユーザがレースをライブで鑑賞可能としても良い。その場合、レースのライブ映像を鑑賞できる配信サイトへのリンク情報をプッシュ通知に含めても良い。

レース動画を表示することにより、レースを鑑賞しなかったユーザであっても、レース開催後に臨場感を持ってレースを楽しむことが可能となる。また、プッシュ通知により、レースの開催、ライブ配信サイトを通知することにより、ユーザはレースを当日に楽しむことが可能となる。

各実施の形態で記載されている技術的特徴（構成要件）はお互いに組み合わせ可能であり、組み合わせすることにより、新しい技術的特徴を形成することができる。
今回開示された実施の形態はすべての点で例示であって、制限的なものではないと考えられるべきである。本発明の範囲は、上記した意味ではなく、特許請求の範囲によって示され、特許請求の範囲と均等の意味及び範囲内でのすべての変更が含まれることが意図される。

１００ 通知システム
１ 通知サーバ
１１ ＣＰＵ
１２ ＲＯＭ
１３ ＲＡＭ
１４ 大容量記憶部
１４１ ユーザＤＢ
１４２ パターンＤＢ
１４３ くじＤＢ
１４４ 車券ＤＢ
１４５ 馬券ＤＢ
１４６ 舟券ＤＢ
１４７ 遊技結果ＤＢ
１５ 通信部
１６ 計時部
１Ｐ 制御プログラム
２ ユーザ端末
３ 配信サーバ

Claims (14)

1. 物理媒体に表示された宝くじの回数及び数字を含むくじ券の識別情報を取得し、
   取得した前記回数及び前記識別情報を送信し、
   前記識別情報の当落結果を出力する
   処理をコンピュータに行わせることを特徴とするコンピュータプログラム。
2. 複数の前記物理媒体についての前記識別情報及び当落結果を一覧で出力する
   ことを特徴とする請求項１のコンピュータプログラム。
3. トリガー信号を受け付けた後に、前記当落結果を出力する
   ことを特徴とする請求項１又は２に記載のコンピュータプログラム。
4. 前記当落結果に当せんを含む場合、当せんした旨を出力する
   ことを特徴とする請求項１又は２に記載のコンピュータプログラム。
5. 既に当落結果が判明している宝くじの前記回数及び前記識別情報を、当該識別情報の当落結果とともに出力する
   ことを特徴とする請求項１から請求項４の何れか１項に記載のコンピュータプログラム。
6. 宝くじの発売予定を出力する
   ことを特徴とする請求項１から請求項４の何れか１項に記載のコンピュータプログラム。
7. 宝くじ、公営競技、及び遊技に関わる支出データ及び収入データを取得し、
   前記宝くじ、前記公営競技、及び前記遊技毎に損益を出力する
   処理をコンピュータに行わせることを特徴とするコンピュータプログラム。
8. 物理媒体に表示された宝くじの回数及び数字を含むくじ券の識別情報を取得し、
   取得した前記回数及び前記識別情報を送信し、
   前記識別情報の当落結果を取得し、
   取得した識別情報及び当落結果に基づいて、宝くじに関わる支出データ及び収入データを取得する
   ことを特徴とする請求項７に記載のコンピュータプログラム。
9. 前記宝くじの発売予定及び前記公営競技の開催予定を出力する
   ことを特徴とする請求項７又は請求項８に記載のコンピュータプログラム。
10. 金融商品の取得価額及び数量、並びに評価価額を取得し、
    前記金融商品についての損益を算出し、
    前記宝くじ、前記公営競技、及び前記遊技毎の損益、並びに前記金融商品についての損益を出力する
    ことを特徴とする請求項７から請求項９の何れか１項に記載のコンピュータプログラム。
11. ユーザの宝くじ、公営競技、及び遊技に関わる支出データ及び収入データを取得し、
    取得した前記支出データ及び前記収入データに基づき、前記ユーザの支出動向を判定し、
    判定した支出動向に応じた広告情報を出力する
    処理をコンピュータに行わせることを特徴とするコンピュータプログラム。
12. 前記ユーザの属性情報を取得し、
    取得した属性情報及び前記ユーザの支出動向を出力する
    ことを特徴とする請求項１１に記載のコンピュータプログラム。
13. 前記当落結果を、３次元の仮想現実空間を構成する画像を用いて表示する
    ことを特徴とする請求項１から請求項６の何れか１項に記載のコンピュータプログラム。
14. はがきに印字されたくじの組及び番号を含む識別情報を取得し、
    取得した前記識別情報を送信し、
    前記識別情報の当落結果を出力する
    処理をコンピュータに行わせることを特徴とするコンピュータプログラム。

Images