JP6696184B2 - チケット販売プログラム、装置、及び方法 - Google Patents

チケット販売プログラム、装置、及び方法 Download PDF

Info

Publication number
JP6696184B2
JP6696184B2 JP2016005922A JP2016005922A JP6696184B2 JP 6696184 B2 JP6696184 B2 JP 6696184B2 JP 2016005922 A JP2016005922 A JP 2016005922A JP 2016005922 A JP2016005922 A JP 2016005922A JP 6696184 B2 JP6696184 B2 JP 6696184B2
Authority
JP
Japan
Prior art keywords
ticket
stored
information
state
identification information
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
JP2016005922A
Other languages
English (en)
Other versions
JP2017126250A (ja
Inventor
忠彦 佐藤
忠彦 佐藤
聡 福元
聡 福元
明雄 中邑
明雄 中邑
雅登 石井
雅登 石井
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Fujitsu Ltd
Original Assignee
Fujitsu Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Fujitsu Ltd filed Critical Fujitsu Ltd
Priority to JP2016005922A priority Critical patent/JP6696184B2/ja
Publication of JP2017126250A publication Critical patent/JP2017126250A/ja
Application granted granted Critical
Publication of JP6696184B2 publication Critical patent/JP6696184B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Landscapes

  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Description

本発明は、チケット販売プログラム、チケット販売装置、及びチケット販売方法に関する。
各種イベントへ参加するためのチケットをウェブシステムで販売することが行われている。例えば、チケットの販売を希望する主催事業者と、コンビニ店の本部装置との間に介在する第三のメイン装置があり、メイン装置において、購入希望チケットの支払期限と支払事実をチェックする手法が提案されている。この手法では、支払期限を超過した予約は原則としてキャンセル扱いとする。また、例えば航空チケット等でも、支払期限までに支払いがない場合には、予約したチケットをキャンセルすることが行われている。
また、チケット販売のシステムで、人気のイベントのチケットの販売日に注文が殺到するといったケースなどに対応するために、対象のチケットの販売枠を分割して別のデータベース区分に格納する技術が提案されている。この技術では、申込者の電話番号の末尾などの情報を用いて、アクセスするデータベースが振り分けられる。
特開２０００−０６７２７６号公報 再公表特許第２０１３／１３６４４２号公報
"大量トランザクション処理に適したアーキテクチャ"、［online］、２００６年１１月１７日、ＩＴｍｅｄｉａエンタープライズ、［２０１６年１月１１日検索］、インターネット＜ＵＲＬ：http://www.itmedia.co.jp/im/articles/0611/17/news122.html＞ "ご予約・お支払い期間について"、［online］、ＡＮＡホームページ、［２０１６年１月１１日検索］、インターネット＜ＵＲＬ：https://www.ana.co.jp/book-plan/fare/domestic/twtype/kigen.html＞
従来のチケット販売システムでは、個別のイベント毎にチケット代金の決済処理が必要である。しかし、例えば、オリンピックの各種目のチケットを複数購入したい場合など、複数のイベントのチケットを同時期に購入したい場合がある。この場合において、ユーザの立場から見ると、複数のイベント毎のチケットを確保した上で、まとめて決済を行えることが望ましい。
本発明は、一つの側面として、複数のイベントのチケットを一括で決済することを目的とする。
本発明は、一つの側面として、ユーザの識別情報と共に、チケットの指定を含む購入要求を受信し、受信した前記購入要求で指定されたチケットのチケット情報と、前記ユーザの識別情報と、決済処理が未処理であることを示す第１状態とを対応付けて記憶する。そして、特定のチケット情報及び特定のユーザの識別情報に対応付けて記憶された第１状態が、決済処理済みであることを示す第２状態に変更されることなく所定時間が経過したかを判定する。所定時間を経過し、かつ前記特定のユーザの識別情報に、新たなチケット情報が対応付けて記憶されていない場合に、前記特定のユーザの識別情報と前記特定のチケット情報との対応付けを解除し、前記特定のユーザの識別情報に、前記新たなチケット情報が対応付けて記憶されている場合、前記特定のユーザによる前記特定のチケット情報及び前記新たなチケット情報の各々が示す複数のチケットに対する一括での決済指示を受け付け可能とする。
一つの側面として、複数のイベントのチケットを一括で決済することができる、という効果を有する。
第１実施形態に係るチケット販売システムの概略構成を示すブロック図である。 参照データベースの一例を示す図である。 詳細データベースの一例を示す図である。 管理データベースの一例を示す図である。 第１及び第３実施形態に係るチケット販売装置として機能するコンピュータの概略構成を示すブロック図である。 購入要求受信処理の一例を示すフローチャートである。 イベント検索画面の一例を示す図である。 イベント一覧画面の一例を示す図である。 申込画面の一例を示す図である。 販売処理の一例を示すフローチャートである。 管理処理の一例を示すフローチャートである。 買い物カゴ画面の一例を示す図である。 買い物カゴ画面の他の例を示す図である。 参照ＤＢ更新処理の一例を示すフローチャートである。 第２実施形態に係るチケット販売システムの概略構成を示すブロック図である。 第２及び第４実施形態に係るチケット販売装置として機能するコンピュータの概略構成を示すブロック図である。 第２及び第４実施形態に係るキューサーバとして機能するコンピュータの概略構成を示すブロック図である。 第２及び第４実施形態に係るデータベースサーバとして機能するコンピュータの概略構成を示すブロック図である。 第３実施形態に係るチケット販売システムの概略構成を示すブロック図である。 第４実施形態に係るチケット販売システムの概略構成を示すブロック図である。 第５実施形態に係るチケット販売システムの概略構成を示すブロック図である。 第５実施形態に係る管理サーバとして機能するコンピュータの概略構成を示すブロック図である。
以下、図面を参照して本発明に係る実施形態の一例を詳細に説明する。
＜第１実施形態＞
図１に示すように、第１実施形態に係るチケット販売システム１００は、チケット販売装置１０と、チケットに関する各種情報が記憶されたデータベースサーバ２０とを含む。チケット販売システム１００では、ユーザ端末３５から送信された各種イベントのチケットの購入要求を受け付け、決済処理システム３０も利用して、チケットの販売処理を行う。
ユーザ端末３５は、チケット販売システム１００が提供するチケット販売アプリケーションを利用可能な情報処理装置であり、例えば、パーソナルコンピュータ、スマートフォン、タブレット端末、専用端末等である。
チケット販売装置１０は、機能的には、図１に示すように、受信部１１と、提示部１２と、参照更新部１３と、管理部１４とを含む。また、データベースサーバ２０には、参照データベース（ＤＢ）２１と、詳細ＤＢ２２と、管理ＤＢ２３とが記憶される。以下、各機能部及び各データベースについて説明する。
受信部１１は、ユーザ端末３５から送信される検索条件、選択情報、購入要求、及び決済指示を受信する。また、受信部１１は、決済処理システム３０から送信される決済完了通知を受信する。検索条件とは、ユーザが所望のイベントを検索するために検索キーとして指定するイベントの属性情報である。選択情報とは、検索条件に一致するイベントからユーザにより選択されたイベントを特定する情報である。購入要求とは、ユーザの識別情報であるユーザＩＤと、ユーザが指定したイベントの識別情報であるイベントＩＤと、そのイベントのチケットの購入希望枚数とを含む情報である。決済指示とは、ユーザ端末３５から送信された購入要求に応じて確保されたチケットについての決済を指示する情報である。決済完了通知とは、決済指示がされたチケットについての決済処理を決済処理システム３０において完了したことを示す情報である。受信部１１は、受信した検索条件及び選択情報を提示部１２へ受け渡す。また、受信部１１は、受信した購入要求、決済指示、及び決済完了通知を管理部１４へ受け渡す。
提示部１２は、ユーザ端末３５においてチケット販売アプリケーションが起動されると、ユーザがイベントの検索条件を指定するためのイベント検索画面をユーザ端末３５に表示する。なお、ユーザ端末３５へのイベント検索画面の表示は、提示部１２がイベント検索画面を示す画面情報をユーザ端末３５に送信することにより実現される。以下、他の画面についても同様である。
また、提示部１２は、受信部１１から検索条件を受け付けると、参照ＤＢ２１を参照して、検索条件に一致するイベントのイベント情報と、そのイベントの空席状況とを一覧にしたイベント一覧画面をユーザ端末３５に表示する。
図２に、参照ＤＢ２１の一例を示す。図２の例では、各レコード（各行）が１つのイベントに対応する。各レコードは、イベントの「イベントＩＤ」、そのイベントのイベント情報（「イベント名」、「開催日時」、及び「会場」）、並びにそのイベントの「空席状況」等の項目を含む。「空席状況」の項目には、例えば、そのイベントに所定数以上の残席が存在することを示す「空席あり」、残席が所定数未満であることを示す「残りわずか」、残席が存在しないことを示す「空席なし」等の情報が記憶される。
また、提示部１２は、受信部１１からイベントの選択情報を受け付けると、選択されたイベントのチケットの購入をユーザが申し込むための申込画面をユーザ端末３５に表示する。また、提示部１２は、管理ＤＢ２３を参照して、ユーザにより送信された購入要求により指定されたチケットの購入状況を示す買い物カゴ画面をユーザ端末３５に表示する。
参照更新部１３は、詳細ＤＢ２２を参照して、イベント毎の空席状況を集計し、参照ＤＢ２１を更新する。
図３に、詳細ＤＢ２２の一例を示す。図３の例では、各レコード（各行）が１つの座席毎のチケットに対応する。すなわち、詳細ＤＢ２２には、取り扱っているイベントについて販売するチケット数分のレコードが記憶されている。各レコードは、そのチケットの「チケットＩＤ」、そのチケットのイベント情報（「イベント名」、「開催日時」、及び「会場」）、並びに、そのチケットの座席番号を示す「座席」の項目を含む。また、各レコードは、その座席のチケットの「販売状況」、そのチケットがどのユーザに割り当てられたかを示す「ユーザＩＤ」等の項目も含む。「販売状況」の項目には、例えば、そのチケットに対する購入要求を受け付けていないことを示す「未販売」、購入要求を受け付けたが決済処理が未完であることを示す「仮販売」、決済処理まで完了していることを示す「販売済み」等の情報が記憶される。
管理部１４は、受信部１１から購入要求を受け付けると、受け付けた購入要求に、その購入要求で指定されているチケットの購入状況を対応付けて、購入要求を受け付けた日時と共に管理ＤＢ２３に記憶する。
図４に、管理ＤＢ２３の一例を示す。図４の例では、各レコード（各行）が１つの購入要求に対応する。各レコードは、「ユーザＩＤ」、「チケットＩＤ」、「枚数」、「購入状況」、「更新日時」、「解除フラグ」等の項目を含む。「ユーザＩＤ」、「チケットＩＤ」、及び「枚数」の各項目には、購入要求に含まれる各情報が記憶される。「購入状況」の項目には、例えば、その購入要求がまだ処理されていないことを示す「未処理」、購入要求に応じてチケットが確保されたが決済処理が未完であることを示す「仮購入」、決済処理まで完了していることを示す「購入済み」等の情報が記憶される。また、「購入状況」の項目には、その購入要求で指定されたチケットが確保できなかったことを示す「残席なし」の情報も記憶される。「解除フラグ」の項目では、「購入状況」が「仮購入」の状態の購入要求について、「仮購入」の状態を解除する場合に、フラグが設定される。図４の例では、「解除フラグ」の項目に「解除」が記憶されている場合が、フラグが設定されている場合を表している。
また、管理部１４は、管理ＤＢ２３において「購入状況」が「未処理」の購入要求に基づいて、詳細ＤＢ２２における、その購入要求が示すチケットの「販売状況」及び「ユーザＩＤ」、並びに管理ＤＢ２３における、その購入要求の「購入状況」を更新する。
また、管理部１４は、管理ＤＢ２３を参照して、「購入状況」が「仮購入」の状態で、同一ユーザによる新たなチケットを指定した購入要求の記憶、又は「購入状況」の更新がないまま所定時間が経過した購入要求について、「解除フラグ」を設定する。さらに、管理部１４は、詳細ＤＢ２２において、解除フラグが設定された購入要求に含まれるユーザＩＤ及びチケットＩＤに対応する「販売状況」を更新すると共に、「ユーザＩＤ」を削除する。
また、管理部１４は、決済指示を受け付けると、受け付けた決済指示に関するユーザの情報とチケット情報とを決済処理システム３０へ送信し、決済処理を依頼する。また、管理部１４は、決済完了通知を受け付けると、詳細ＤＢ２２における、該当のチケットの「販売状況」、及び管理ＤＢ２３における、該当のチケットを指定した購入要求の「購入状況」及び「更新日時」を更新する。
チケット販売装置１０は、例えば図５に示すコンピュータ４０で実現することができる。コンピュータ４０は、ＣＰＵ４１と、一時記憶領域としてのメモリ４２と、不揮発性の記憶部４３とを備える。また、コンピュータ４０は、入出力装置４４と、記録媒体４９に対するデータの読み込み及び書き込みを制御するread/write（Ｒ／Ｗ）部４５と、通信インターフェース（Ｉ／Ｆ）４６とを備える。ＣＰＵ４１、メモリ４２、記憶部４３、入出力装置４４、Ｒ／Ｗ部４５、及び通信Ｉ／Ｆ４６は、バス４７を介して互いに接続される。
記憶部４３は、Hard Disk Drive（ＨＤＤ）、solid state drive（ＳＳＤ）、フラッシュメモリ等によって実現できる。記憶媒体としての記憶部４３には、コンピュータ４０をチケット販売装置１０として機能させるためのチケット販売プログラム５０が記憶される。チケット販売プログラム５０は、受信プロセス５１と、提示プロセス５２と、参照更新プロセス５３と、管理プロセス５４とを有する。
ＣＰＵ４１は、チケット販売プログラム５０を記憶部４３から読み出してメモリ４２に展開し、チケット販売プログラム５０が有するプロセスを順次実行する。ＣＰＵ４１は、受信プロセス５１を実行することで、図１に示す受信部１１として動作する。また、ＣＰＵ４１は、提示プロセス５２を実行することで、図１に示す提示部１２として動作する。また、ＣＰＵ４１は、参照更新プロセス５３を実行することで、図１に示す参照更新部１３として動作する。また、ＣＰＵ４１は、管理プロセス５４を実行することで、図１に示す管理部１４として動作する。これにより、チケット販売プログラム５０を実行したコンピュータ４０が、チケット販売装置１０として機能することになる。
なお、チケット販売プログラム５０により実現される機能は、例えば半導体集積回路、より詳しくはApplication Specific Integrated Circuit（ＡＳＩＣ）等で実現することも可能である。
次に、第１実施形態に係るチケット販売システム１００の作用について説明する。ユーザ端末３５において、ユーザＩＤを入力してログインすることにより、チケット販売システム１００により提供されるチケット販売アプリケーションが起動されると、チケット販売装置１０が、図６に示す購入要求受信処理を実行する。また、チケット販売装置１０は、購入要求受信処理と並行して、図１０に示す販売処理、及び図１４に示す参照ＤＢ更新処理も実行する。購入要求受信処理、販売処理、及び参照ＤＢ更新処理は、本発明のチケット販売方法の一例である。以下、各処理について詳述する。
まず、図６を参照して、購入要求受信処理について説明する。
ステップＳ１１で、提示部１２が、例えば図７に示すような、ユーザがイベントの検索条件を指定するためのイベント検索画面６１を、ユーザ端末３５に表示する。図７の例では、イベント検索画面６１は、イベントのイベント名、開催日時、会場等の属性を検索キーとして指定するための属性毎の指定領域６１Ａを含む。ユーザは指定領域６１Ａに検索したいイベントの属性をテキストで入力したり、プルダウンメニューから選択したりすることにより、検索条件を指定する。また、イベント検索画面６１には、任意のキーワードを指定するための指定領域６１Ａを設けてもよい。また、イベント検索画面６１には、検索ボタン６１Ｂが含まれる。ユーザが検索ボタン６１Ｂを指定すると、イベント検索画面６１で指定された検索条件が、ユーザ端末３５からチケット販売装置１０へ送信される。受信部１１が検索条件を受信すると、受信部１１は、受信した検索条件を提示部１２へ受け渡す。
次に、ステップＳ１２で、提示部１２が、受信部１１から受け付けた検索条件に一致するイベントのイベント情報と、そのイベントの空席状況とを、参照ＤＢ２１から取得する。提示部１２は、例えば図８に示すような、取得した情報を一覧にしたイベント一覧画面６２をユーザ端末３５に表示する。図８の例では、イベント一覧画面６２には、イベント情報と空席状況との組の一覧６２Ａと、いずれかのイベントを選択するための詳細ボタン６２Ｂとが含まれる。なお、「空席状況」が「空席なし」のイベントについては、ユーザによる選択を許可しないようにするために、詳細ボタン６２Ｂを表示しない。
ユーザがいずれかの詳細ボタン６１Ｂを選択すると、選択された詳細ボタン６１Ｂに対応するイベントのイベントＩＤを含む選択情報が、ユーザ端末３５からチケット販売装置１０へ送信される。
次に、ステップＳ１３で、受信部１１が、選択情報を受信したか否かを判定する。選択情報が受信された場合には、処理はステップＳ１４へ移行し、選択情報が受信されていない場合には、本ステップの判定を繰り返す。
ステップＳ１４では、受信部１１が、受信した選択情報を提示部１２へ受け渡す。提示部１２は、例えば図９に示すような、選択されたイベントのチケットの購入をユーザが申し込むための申込画面６３をユーザ端末３５に表示する。図９の例では、申込画面６３には、選択されたイベントのイベント情報６３Ａが含まれる。イベント情報６３Ａとしては、受け付けた選択情報に含まれるチケットＩＤに対応付けて参照ＤＢ２１に記憶されているチケット情報が表示される。なお、図示は省略するが、申込画面６３には、図９に示すイベント情報６３Ａに加えて、イベントのより詳細な情報、公演時の注意事項、チケットの金額、会場の地図へのリンク等の他の情報を合わせて表示してもよい。また、申込画面６３には、チケットの購入希望枚数をプルダウンメニュー等により指定するための指定領域６３Ｂ、及び申込ボタン６３Ｃが含まれる。
ユーザが希望枚数を指定して申込ボタン６３Ｃを選択すると、ユーザＩＤと、イベント情報６３Ａに表示されているイベントのイベントＩＤと、指定領域６３Ｂで指定されている希望枚数とを含む購入要求が、ユーザ端末３５からチケット販売装置１０へ送信される。
次に、ステップＳ１５で、受信部１１が、購入要求を受信したか否かを判定する。購入要求が受信された場合には、処理はステップＳ１６へ移行し、購入要求が受信されていない場合には、本ステップの判定を繰り返す。
ステップＳ１６では、受信部１１が、受信した購入依頼を管理部１４へ受け渡す。管理部１４は、受け付けた購入要求に、その購入要求で指定されているチケットの購入状況として「未処理」を対応付けて、購入要求を受け付けた日時と共に管理ＤＢ２３に記憶する。なお、この段階では、「解除フラグ」は未設定とする。そして、処理はステップＳ１２に戻る。なお、ユーザによりイベントの検索条件の変更が指示された場合には、ステップＳ１１へ戻るようにしてもよい。ステップＳ１１又はＳ１２に処理が戻ることで、ユーザは引き続き異なるチケットを選択することが可能である。
次に、図１０を参照して、販売処理について説明する。販売処理は、詳細ＤＢ２２へのアクセスが所定期間において一定数を超えないように、所定時間間隔で繰り返し実行される。
ステップＳ２１で、管理部１４が、管理ＤＢ２３において、「購入状況」が「未処理」の購入要求のうち、「更新日時」が最も古い購入要求を、処理対象の購入要求として選択する。
次に、ステップＳ２２で、管理部１４が、処理対象の購入要求で指定されるチケットに空席が存在するか否かを判定する。具体的には、管理部１４は、詳細ＤＢ２２において、処理対象の購入要求に含まれるチケットＩＤに対応付けられているチケットのうち、「販売状況」が「未販売」のチケットが、処理対象の購入要求に含まれる希望枚数分存在するか否かを判定する。空席が存在する場合には、処理はステップＳ２５へ移行し、空席が存在しない場合には、処理はステップＳ２３へ移行する。なお、参照ＤＢ２１の更新のタイミング、又は購入要求が管理ＤＢ２３に記憶されてから上記ステップＳ２１で選択されるまでの時間によっては、イベント一覧画面６２で表示する空席状況が最新の情報ではない場合がある。そのため、本ステップにおいて、改めて空席状況を確認するものである。
ステップＳ２３では、提示部１２が、処理対象の購入要求で指定されたチケットに空席がない旨のメッセージをユーザ端末３５に表示する。また、ステップＳ２４で、管理部１４が、管理ＤＢ２３において、処理対象の購入要求の「購入状況」を「残席なし」に更新すると共に、「更新日時」を現在日時に更新する。そして、販売処理は終了する。
一方、ステップＳ２５では、管理部１４が、詳細ＤＢ２２において、処理対象の購入要求に含まれるチケットＩＤに対応する「販売状況」を「仮販売」に更新し、処理対象の購入要求に含まれるユーザＩＤを「ユーザＩＤ」に記憶する。また、ステップＳ２５で、管理部１４が、管理ＤＢ２３において、処理対象の購入要求の「購入状況」を「仮購入」に更新すると共に、「更新日時」を現在日時に更新する。
次に、ステップＳ３０で、図１１に詳細を示す管理処理が実行される。
管理処理のステップＳ３１で、管理部１４が、処理対象の購入要求に含まれるユーザＩＤと同一のユーザＩＤに対応付けられた全ての「更新日時」の中から、最新の更新日時を取得する。
次に、ステップＳ３２で、管理部１４が、上記ステップＳ３１で取得した更新日時から所定時間が経過しているか否かを判定する。所定時間が経過している場合には、処理はステップＳ３３へ移行し、所定時間が経過していない場合には、管理処理を終了して、処理は図１０に示す販売処理に戻る。
ステップＳ３３では、管理部１４が、管理ＤＢ２３において、処理対象の購入要求に含まれるユーザＩＤに対応付けられた全ての購入要求のうち、「購入状況」が「仮購入」の購入要求の「解除フラグ」を設定する。
次に、ステップＳ３４で、管理部１４が、詳細ＤＢ２２において、上記ステップＳ３３で解除フラグを設定した購入要求に含まれるユーザＩＤ及びチケットＩＤに対応する「販売状況」を「未販売」に更新する。また、管理部１４は、「ユーザＩＤ」の項目に記憶されたユーザＩＤを削除する。そして、処理は図１０に示す販売処理に戻る。
管理処理の実行により、所定時間内に「更新日時」が更新される処理が行われなかったユーザの購入要求のうち、「仮購入」状態のチケットが解放される。逆に、所定時間内に「更新日時」が更新される処理が行われている間は、決済処理へ進まなくても「仮購入」状態のチケットが解放されることはなく、ユーザは引き続き別のチケットの購入要求を行うことが可能である。なお、管理ＤＢ２３の「更新日時」は、購入要求が管理ＤＢ２３に記憶された際、及び「購入状況」が更新された際に更新される。
次に、販売処理のステップＳ４１で、提示部１２が、例えば図１２に示すような買い物カゴ画面６４をユーザ端末３５に表示する。買い物カゴ画面６４には、購入要求毎の購入状況を示す一覧６４Ａが含まれる。具体的には、提示部１２は、処理対象の購入要求に含まれるユーザＩＤに対応付けられている全ての購入要求を管理ＤＢ２３から抽出し、各購入要求に含まれるチケット情報に購入状況を対応付けた一覧６１Ａを作成して買い物カゴ画面６４に表示する。また、買い物カゴ画面６４には、「購入状況」が「仮購入」である購入要求に対応付けて、その購入要求で指定されているチケットの決済処理へ進むための決済ボタン６４Ｂが含まれる。また、買い物カゴ画面６４には、「購入状況」が「仮購入」である購入要求で指定されている全てのチケットを一括で決済するための一括決済ボタン６４Ｃが含まれる。
また、処理対象の購入要求に含まれるユーザＩＤに対応付けられている購入要求として管理ＤＢ２３から抽出された購入要求に、解除フラグが設定されている購入要求が存在する場合には、提示部１２は、図１３に示すような買い物カゴ画面６４を表示する。図１３の例では、解除フラグが設定されている購入要求の「購入状況」が「時間切れ」として表示されると共に、そのチケットは時間切れにより解放された旨のメッセージ６４Ｄが表示されている。
ユーザは買い物カゴ画面６４において、決済ボタン６４Ｂ又は一括決済ボタン６４Ｃを選択する。これにより、選択された決済ボタン６４Ｂ又は一括決済ボタン６４Ｃに対応する購入要求に含まれるチケットＩＤと、ユーザＩＤとを含む決済指示が、ユーザ端末３５からチケット販売装置１０へ送信される。
次に、ステップＳ４２で、受信部１１が、決済指示を受信したか否かを判定する。決済指示が受信された場合には、処理はステップＳ４３へ移行し、所定時間を経過しても決済指示が受信されない場合には、販売処理は終了する。
ステップＳ４３では、受信部１１が、受信した決済指示を管理部１４へ受け渡す。管理部１４は、決済指示に含まれるユーザＩＤ及びチケットＩＤに関連する情報を決済処理システム３０へ送信し、決済処理を依頼する。決済処理システム３０において決済処理が終了すると、決済処理システム３０から決済完了通知がチケット販売装置１０へ送信される。
次に、ステップＳ４４で、受信部１１が、決済完了通知を受信したか否かを判定する。決済完了通知が受信された場合には、処理はステップＳ４５へ移行し、決済完了通知が受信されていない場合には、本ステップの判定を繰り返す。
ステップＳ４５では、受信部１１が、受信した決済完了通知を管理部１４へ受け渡す。管理部１４は、詳細ＤＢ２２において、上記ステップＳ４２で受信した決済指示に含まれるユーザＩＤ及びチケットＩＤに対応する「販売状況」を「販売済み」に更新する。また、ステップＳ４６で、管理部１４が、管理ＤＢ２３において、上記のユーザＩＤ及びチケットＩＤに対応する「購入状況」を「購入済み」に更新すると共に、「更新日時」を現在日時に更新する。そして、販売処理は終了する。
次に、図１４を参照して、参照ＤＢ更新処理について説明する。参照ＤＢ更新処理は、所定時間間隔で繰り返し実行される。
ステップＳ５１で、参照更新部１３が、詳細ＤＢ２２を参照して、イベントＩＤ毎に「販売状況」が「未販売」のチケット数（レコード数）、すなわち残席数を集計する。
次に、ステップＳ５２で、参照更新部１３が、集計した残席数が所定数以上のイベントＩＤについては、そのイベントＩＤに対応する参照ＤＢ２１の「空席状況」を「空席あり」に更新する。また、参照更新部１３は、集計した残席数が所定数未満のイベントＩＤについては、そのイベントＩＤに対応する参照ＤＢ２１の「空席状況」を「残りわずか」に更新する。また、参照更新部１３は、集計した残席数が０のイベントＩＤについては、そのイベントＩＤに対応する参照ＤＢ２１の「空席状況」を「空席なし」に更新する。そして、参照ＤＢ更新処理は終了する。
以上説明したように第１実施形態に係るチケット販売システム１００によれば、チケット販売装置１０において、ユーザ端末３５から受信したチケットの購入要求を、購入状況を示すステータス及び更新日時と対応付けて管理ＤＢ２３に記憶する。そして、所定時間内に同一ユーザに関する購入要求の更新日時が更新される処理が行われている間は、決済処理が未処理の仮購入状態のチケットを解放することなく、同一ユーザによる別のチケットの購入要求を受け付け可能とする。そして、同一ユーザが、仮購入状態のチケットを複数維持する場合には、これら複数のチケットについての一括での決済指示を受け付け可能とする。したがって、複数のイベントのチケットを一括で決済することができる。
また、同一ユーザによる新たなチケットを指定した購入要求や、仮購入状態のチケットの決済処理等が行われることなく所定時間を経過した場合には、そのユーザが維持していた仮購入状態のチケットを解放する。これにより、不当な仮購入状態のチケットの維持を抑制する。なお、同一ユーザにより維持可能な仮購入状態のチケットの数に制限を設けたり、所定期間内に更新日時が更新されている場合でも、最初の購入要求から長時間が経過した場合には、仮購入状態のチケットを解放したりするようにしてもよい。
また、第１実施形態に係るチケット販売装置１０は、受信したチケットの購入要求を一旦管理ＤＢ２３に記憶する。そして、詳細ＤＢ２２へのアクセス数が所定期間において一定数を超えないような所定時間間隔で、管理ＤＢ２３に記憶された購入要求を受信順に取り出して、購入要求に基づいて詳細ＤＢ２２にアクセスして販売処理を行う。すなわち、チケットの購入要求の受信と、購入要求に基づく販売処理とが非同期となる。これにより、購入要求が集中して、詳細ＤＢ２２へのアクセスが上限に達して制限されることにより、販売処理が中断されるような事態を抑制し、購入要求を確実に受け付け、販売処理を実行することができる。
また、第１実施形態に係るチケット販売装置１０では、購入要求を行う前のイベントの検索を、詳細ＤＢ２２ではなく参照ＤＢ２１を参照して行うため、詳細ＤＢ２２への負荷を低減することができる。
＜第２実施形態＞
次に、第２実施形態について説明する。なお、第２実施形態に係るチケット販売システムにおいて、第１実施形態に係るチケット販売システム１００と同様の部分については、同一符号を付して、詳細な説明を省略する。
図１５に示すように、第２実施形態に係るチケット販売システム２００は、複数のチケット販売装置２１０と、キューサーバ２２０Ａと、データベースサーバ２２０Ｂとを含む。
チケット販売装置２１０は、機能部として、受信部１１と、提示部１２とを含む。キューサーバ２２０Ａは、機能部として、管理部１４を含むと共に、管理ＤＢ２３を保持する。データベースサーバ２２０Ｂは、機能部として、参照更新部１３を含むと共に、参照ＤＢ２１及び詳細ＤＢ２２を保持する。
各機能部の機能については、単一装置内での情報のやり取りが、装置間での情報のやり取りに変わる点を除いて、第１実施形態に係るチケット販売装置１０の各機能部と同様である。
チケット販売装置２１０は、例えば図１６に示すコンピュータ４０で実現することができる。コンピュータ４０の記憶部４３には、コンピュータ４０をチケット販売装置２１０として機能させるためのチケット販売プログラム２５０Ａが記憶される。チケット販売プログラム２５０Ａは、受信プロセス５１と、提示プロセス５２とを有する。ＣＰＵ４１は、チケット販売プログラム２５０Ａを記憶部４３から読み出してメモリ４２に展開し、チケット販売プログラム２５０Ａが有するプロセスを順次実行する。これにより、チケット販売プログラム２５０Ａを実行したコンピュータ４０が、チケット販売装置２１０として機能することになる。
キューサーバ２２０Ａは、例えば図１７に示すコンピュータ７０で実現することができる。コンピュータ７０は、ＣＰＵ７１と、一時記憶領域としてのメモリ７２と、不揮発性の記憶部７３とを備える。また、コンピュータ７０は、入出力装置７４と、記録媒体７９に対するデータの読み込み及び書き込みを制御するＲ／Ｗ部７５と、通信Ｉ／Ｆ７６とを備える。ＣＰＵ７１、メモリ７２、記憶部７３、入出力装置７４、Ｒ／Ｗ部７５、及び通信Ｉ／Ｆ７６は、バス７７を介して互いに接続される。
記憶部７３は、ＨＤＤ、ＳＳＤ、フラッシュメモリ等によって実現できる。記憶媒体としての記憶部７３には、コンピュータ７０をキューサーバ２２０Ａとして機能させるためのチケット販売プログラム２５０Ｂが記憶される。チケット販売プログラム２５０Ｂは、管理プロセス５４を有する。また、記憶部７３は、管理ＤＢ２３を構成する情報が記憶される管理情報記憶領域８３を含む。ＣＰＵ７１は、チケット販売プログラム２５０Ｂを記憶部７３から読み出してメモリ７２に展開し、チケット販売プログラム２５０Ｂが有するプロセスを順次実行する。また、ＣＰＵ７１は、管理情報記憶領域８３から情報を読み出して、メモリ７２に管理ＤＢ２３を展開する。これにより、チケット販売プログラム２５０Ｂを実行したコンピュータ７０が、キューサーバ２２０Ａとして機能することになる。
データベースサーバ２２０Ｂは、例えば図１８に示すコンピュータ９０で実現することができる。コンピュータ９０は、ＣＰＵ９１と、一時記憶領域としてのメモリ９２と、不揮発性の記憶部９３とを備える。また、コンピュータ９０は、入出力装置９４と、記録媒体９９に対するデータの読み込み及び書き込みを制御するＲ／Ｗ部９５と、通信Ｉ／Ｆ９６とを備える。ＣＰＵ９１、メモリ９２、記憶部９３、入出力装置９４、Ｒ／Ｗ部９５、及び通信Ｉ／Ｆ９６は、バス９７を介して互いに接続される。
記憶部９３は、ＨＤＤ、ＳＳＤ、フラッシュメモリ等によって実現できる。記憶媒体としての記憶部９３には、コンピュータ９０をデータベースサーバ２２０Ｂとして機能させるためのチケット販売プログラム２５０Ｃが記憶される。チケット販売プログラム２５０Ｃは、参照更新プロセス５３を有する。また、記憶部９３は、参照ＤＢ２１を構成する情報が記憶される参照情報記憶領域８１と、詳細ＤＢ２２を構成する情報が記憶される詳細情報記憶領域８２とを含む。ＣＰＵ９１は、チケット販売プログラム２５０Ｃを記憶部９３から読み出してメモリ９２に展開し、チケット販売プログラム２５０Ｃが有するプロセスを順次実行する。また、ＣＰＵ９１は、参照情報記憶領域８１から情報を読み出して、メモリ９２に参照ＤＢ２１を展開し、詳細情報記憶領域８２から情報を読み出して、メモリ９２に詳細ＤＢ２２を展開する。これにより、チケット販売プログラム２５０Ｃを実行したコンピュータ９０が、データベースサーバ２２０Ｂとして機能することになる。
なお、チケット販売プログラム２５０Ａ、２５０Ｂ、２５０Ｃにより実現される機能は、例えば半導体集積回路、より詳しくはＡＳＩＣ等で実現することも可能である。
第２実施形態に係るチケット販売システム２００の作用については、単一装置内での情報のやり取りが、装置間での情報のやり取りに変わる点を除いて、第１実施形態に係るチケット販売システム１００の作用と同様であるため、説明を省略する。
以上説明したように、第２実施形態に係るチケット販売システム２００によれば、複数のチケット販売装置２１０の各々で受信したチケットの購入要求を、一旦キューサーバ２２０Ａの管理ＤＢ２３に記憶して管理する。これにより、人気イベントのチケット販売日などのように購入要求が集中する際に、購入要求を受け付けるチケット販売装置２１０を増設したとしても、キューサーバ２２０Ａを介して、データベースサーバ２２０Ｂへのアクセス数を一定数以下に保つことができる。
＜第３実施形態＞
次に、第３実施形態について説明する。なお、第３実施形態に係るチケット販売システムにおいて、第１実施形態に係るチケット販売システム１００と同様の部分については、同一符号を付して、詳細な説明を省略する。
図１９に示すように、第３実施形態に係るチケット販売システム３００は、チケット販売装置３１０と、データベースサーバ３２０とを含む。
データベースサーバ３２０には、参照ＤＢ２１と、分散型詳細ＤＢ２２２と、管理ＤＢ２３とが記憶される。分散型詳細ＤＢ２２２は、第１詳細ＤＢ２２２１、第２詳細ＤＢ２２２２、第３詳細ＤＢ２２２３、・・・を含む複数の詳細ＤＢ２２２ｎに情報を分散して記憶するデータベースである。各詳細ＤＢ２２２ｎに記憶される情報は、第１実施形態における詳細ＤＢ２２に記憶される情報と同様、各レコードが１つの座席毎のチケットに相当する情報である。
各詳細ＤＢ２２２ｎへのレコードの記憶は、イベント毎、開催日毎、又は会場毎にそれぞれ異なる詳細ＤＢ２２２ｎに記憶するなど、チケットの属性に基づいて分散することができる。例えば、イベントＡのチケットのレコードは第１詳細ＤＢ２２２１に記憶し、イベントＢのチケットのレコードは第２詳細ＤＢ２２２２に記憶し、イベントＣのチケットのレコードは第３詳細ＤＢ２２２３に記憶するなどのように分散することができる。
また、各詳細ＤＢ２２２ｎに記憶されるレコード数は、略同一となるように分散することが望ましい。データベースに記憶されているレコード数に応じて、そのデータベースにアクセスして情報を参照したり取得したりする際に要する処理時間が異なるため、各詳細ＤＢ２２２ｎに記憶されるレコード数を略同一とすることで、処理時間の安定化を図るものである。なお、レコード数が略同一とは、各詳細ＤＢ２２２ｎに記憶されたレコード数の差が、予め定めた所定数以内であることをいう。
チケット販売装置３１０は、機能的には、図１９に示すように、受信部１１と、提示部１２と、参照更新部３１３と、管理部３１４とを含む。
参照更新部３１３は、分散型詳細ＤＢ２２２を参照して、イベント毎の空席状況を集計し、参照ＤＢ２１を更新する。この際、参照更新部３１３は、分散型詳細ＤＢ２２２に含まれる各詳細ＤＢ２２２ｎに記憶された情報を集約して、イベント毎の空席状況を集計する。
管理部３１４は、分散型詳細ＤＢ２２２にアクセスする際、各詳細ＤＢ２２２ｎへのアクセス数が所定期間において一定数を超えないように、所定時間間隔で各詳細ＤＢ２２２ｎへアクセスする。管理部３１４の他の機能については、第１実施形態における管理部１４と同様である。
チケット販売装置３１０は、例えば図５に示すコンピュータ４０で実現することができる。コンピュータ４０の記憶部４３には、コンピュータ４０をチケット販売装置３１０として機能させるためのチケット販売プログラム３５０が記憶される。チケット販売プログラム３５０は、受信プロセス５１と、提示プロセス５２と、参照更新プロセス３５３と、管理プロセス３５４とを有する。ＣＰＵ４１は、チケット販売プログラム３５０を記憶部４３から読み出してメモリ４２に展開し、チケット販売プログラム３５０が有するプロセスを順次実行する。これにより、チケット販売プログラム３５０を実行したコンピュータ４０が、チケット販売装置３１０として機能することになる。
なお、チケット販売プログラム３５０により実現される機能は、例えば半導体集積回路、より詳しくはＡＳＩＣ等で実現することも可能である。
第３実施形態に係るチケット販売システム３００の作用について、第１実施形態に係るチケット販売システム１００の作用と異なる点について説明する。
第３実施形態では、図１０に示す販売処理が、詳細ＤＢ２２２ｎ毎に並行して、各詳細ＤＢ２２へのアクセスが所定期間において一定数を超えないように、所定時間間隔で繰り返し実行される。そのため、管理部３１４は、どのチケットに関するレコードがどの詳細ＤＢ２２２ｎに記憶されているかという情報、例えば、チケットＩＤと詳細ＤＢ２２２ｎの識別情報との対応表を予め保持しておく。そして、ステップＳ２１で、管理部３１４は、管理ＤＢ２３において、ある詳細ＤＢ２２２ｎに対応するチケットＩＤを含む購入要求であって、「購入状況」が「未処理」の購入要求を抽出する。そして、管理部３１４は、抽出した購入要求のうち、「更新日時」が最も古い購入要求を、その詳細ＤＢ２２２ｎへのアクセスを要する処理対象の購入要求として選択する。
以上説明したように、第３実施形態に係るチケット販売システム３００によれば、詳細ＤＢが、イベントの属性に応じて複数の詳細ＤＢ２２２ｎにレコードが分散記憶された分散型のデータベースとして構成される。これにより、１つの詳細ＤＢに複数のイベントのチケットに関する情報がまとめて記憶されている場合に比べ、効率的に詳細ＤＢへアクセスすることができる。例えば、イベント毎に詳細ＤＢ２２２ｎを分散した場合には、人気のイベントのチケットの購入要求が集中していることにより、他のイベントのチケットの購入要求に対する販売処理が滞る事態を緩和することができる。
また、複数の詳細ＤＢ２２２ｎの各々に記憶するレコード数を略同一とすることで、詳細ＤＢ２２２ｎへアクセスした際の処理時間の安定化を図ることができる。
また、第３実施形態のように、詳細ＤＢとして分散型のデータベースを採用した場合でも、第１実施形態と同様に、管理ＤＢ２３で各購入要求の購入状況を管理し、仮購入状態のチケットの維持又は解放を行うことができる。このため、各詳細ＤＢ２２２ｎにアクセスして販売処理を行う毎に決済処理を行う必要はないため、詳細ＤＢとして分散型のデータベースを採用した場合でも、複数のイベントのチケットを一括で決済することができる。
＜第４実施形態＞
次に、第４実施形態について説明する。なお、第４実施形態に係るチケット販売システムにおいて、第１〜第３実施形態に係るチケット販売システム１００、２００、３００と同様の部分については、同一符号を付して、詳細な説明を省略する。
図２０に示すように、第４実施形態に係るチケット販売システム４００は、複数のチケット販売装置２１０と、キューサーバ４２０Ａと、データベースサーバ４２０Ｂとを含む。
キューサーバ４２０Ａは、機能部として、管理部３１４を含むと共に、管理ＤＢ２３を保持する。データベースサーバ４２０Ｂは、機能部として、参照更新部３１３を含むと共に、参照ＤＢ２１及び分散型詳細ＤＢ２２２を保持する。すなわち、第４実施形態に係るチケット販売システム４００は、第２実施形態と同様にキューサーバを用いた構成と、第３実施形態と同様に、詳細ＤＢとして、分散型のデータベースを採用した構成とを組み合わせた構成である。
チケット販売装置２１０は、例えば図１６に示すコンピュータ４０で実現することができる。キューサーバ４２０Ａは、例えば図１７に示すコンピュータ７０で実現することができる。コンピュータ７０の記憶部７３には、コンピュータ７０をキューサーバ４２０Ａとして機能させるためのチケット販売プログラム４５０Ｂが記憶される。チケット販売プログラム４５０Ｂは、管理プロセス３５４を有する。
データベースサーバ４２０Ｂは、例えば図１８に示すコンピュータ９０で実現することができる。コンピュータ９０の記憶部９３には、コンピュータ９０をデータベースサーバ４２０Ｂとして機能させるためのチケット販売プログラム４５０Ｃが記憶される。チケット販売プログラム４５０Ｃは、参照更新プロセス３５３を有する。
なお、チケット販売プログラム４５０Ｂ、４５０Ｃにより実現される機能は、例えば半導体集積回路、より詳しくはＡＳＩＣ等で実現することも可能である。
第４実施形態に係るチケット販売システム４００の作用については、第２実施形態に係るチケット販売システム２００及び第３実施形態に係るチケット販売システム３００の作用と同様であるため、説明を省略する。
以上説明したように、第４実施形態に係るチケット販売システム４００によれば、複数のチケット販売装置２１０の各々で受信したチケットの購入要求を、一旦キューサーバ４２０Ａの管理ＤＢ２３に記憶して管理する。また、詳細ＤＢとして分散型のデータベースを採用している。この場合においても、データベースサーバ２２０Ｂへのアクセス数を一定数以下に保つことができる。
＜第５実施形態＞
次に、第５実施形態について説明する。なお、第５実施形態に係るチケット販売システムにおいて、第１〜第４実施形態に係るチケット販売システム１００、２００、３００、４００と同様の部分については、同一符号を付して、詳細な説明を省略する。
図２１に示すように、第５実施形態に係るチケット販売システム５００は、複数のチケット販売装置５１０ｎと、複数のデータベースサーバ５２０Ｂｎと、管理サーバ５２０Ｃとを含む。本実施形態では、チケット販売システム５００に、３台のチケット販売装置５１０１、５１０２、５１０３と、３台のデータベースサーバ５２０Ｂ１、５２０Ｂ２、５２０Ｂ３とが含まれる例を示している。なお、末尾の数字が一致するチケット販売装置５１０ｎとデータベースサーバ５２０Ｂｎとがそれぞれ対応する。
データベースサーバ５２０Ｂ１には、第１詳細ＤＢ２２２１が記憶され、データベースサーバ５２０Ｂ２には、第２詳細ＤＢ２２２２が記憶され、データベースサーバ５２０Ｂ３には、第３詳細ＤＢ２２２３が記憶されている。すなわち、第５実施形態に係るチケット販売システム５００は、第４実施形態の詳細ＤＢ２２２ｎを、チケット販売装置の数に対応付けて複数設けた構成である。
チケット販売装置５１０ｎは、機能部として、受信部５１１と、提示部１２とを含む。
受信部５１１は、購入要求を受信した場合には、受信した購入要求を管理サーバ５２０Ｃ及び対応するデータベースサーバ５２０Ｂｎへ送信する。また、受信部５１１は、決済完了通知を受信した場合には、受信した決済完了通知を、対応するデータベースサーバ５２０Ｂｎへ送信する。データベースサーバ５２０Ｂｎでは、受信した購入要求及び決済完了通知に基づいて、詳細ＤＢ２２２ｎの「販売状況」及び「ユーザＩＤ」の項目が更新される。受信部５１１の他の機能については、上記各実施形態における受信部１１と同様である。
管理サーバ５２０Ｃは、機能部として、参照更新部５１３及び管理部５１４を含むと共に、参照ＤＢ２１及び管理ＤＢ２３を保持する。
参照更新部５１３は、各詳細ＤＢ２２２ｎを参照して、イベント毎の空席状況を集計し、参照ＤＢ２１を更新する。上述したように、各詳細ＤＢ２２２ｎは、それぞれ別のデータベースサーバ５２０Ｂｎに記憶されているため、参照更新部５１３は、各データベースサーバ５２０Ｂｎにアクセスして、各データベースサーバ５２０Ｂｎに記憶されている詳細ＤＢ２２２ｎを参照する。
管理部５１４は、チケット販売装置５１０ｎの各々から購入要求を受信すると、受信した購入要求に、「仮購入」の状態を対応付けて、日時と共に管理ＤＢ２３に記憶する。また、管理部５１４は、各データベースサーバ５２０Ｂｎに記憶された詳細ＤＢ２２２ｎで更新されたチケットの販売状況を収集し、管理ＤＢ２３において、そのチケットを指定した購入要求の購入状況を更新する。各データベースサーバ５２０Ｂｎに記憶された詳細ＤＢ２２２ｎでの更新状況を、管理ＤＢ２３において集約して管理するため、上記各実施形態と同様に、一つのユーザＩＤに対応する複数の仮購入状態のチケットの一括決済が可能である。なお、管理部５１４の他の機能については、上記各実施形態における管理部１４、３１４と同様である。
チケット販売装置５１０ｎは、例えば図１６に示すコンピュータ４０で実現することができる。コンピュータ４０の記憶部４３には、コンピュータ４０をチケット販売装置５１０ｎとして機能させるためのチケット販売プログラム５５０Ａが記憶される。チケット販売プログラム５５０Ａは、受信プロセス５５１と、提示プロセス５２とを有する。
管理サーバ５２０Ｃは、例えば図２２に示すコンピュータ１５０で実現することができる。コンピュータ１５０の記憶部１５３には、コンピュータ１５０を管理サーバ５２０Ｃとして機能させるためのチケット販売プログラム５５０Ｄが記憶される。チケット販売プログラム５５０Ｄは、参照更新プロセス５５３と、管理プロセス５５４とを有する。また、記憶部１５３は、参照ＤＢ２１を構成する情報が記憶される参照情報記憶領域８１、及び管理ＤＢ２３を構成する情報が記憶される管理情報記憶領域８３を含む。
なお、チケット販売プログラム５５０Ａ、５５０Ｄにより実現される機能は、例えば半導体集積回路、より詳しくはＡＳＩＣ等で実現することも可能である。
以上説明したように、第５実施形態に係るチケット販売システム５００によれば、データベースサーバへのアクセス集中をチケット販売装置毎に分散できる。また、この場合でも、一つのユーザＩＤに対応する決済については、複数のチケット販売装置が別々に受信したチケットであっても、一括で決済処理を実行することが可能となる。
なお、上記各実施形態では、チケット販売プログラム５０、２５０Ａ、２５０Ｂ、２５０Ｃ、３５０、４５０Ｂ、４５０Ｃ、５５０Ａ、５５０Ｄが記憶部４３、７３、９３に予め記憶（インストール）されている態様を説明したが、これに限定されない。本発明に係るチケット販売プログラムは、ＣＤ−ＲＯＭ、ＤＶＤ−ＲＯＭ、ＵＳＢメモリ等の記録媒体に記録された形態で提供することも可能である。
以上の各実施形態に関し、更に以下の付記を開示する。
（付記１）
コンピュータに、
ユーザの識別情報と共に、チケットの指定を含む購入要求を受信し、
受信した前記購入要求で指定されたチケットのチケット情報と、前記ユーザの識別情報と、決済処理が未処理であることを示す第１状態とを対応付けて記憶し、
特定のチケット情報及び特定のユーザの識別情報に対応付けて記憶された第１状態が、決済処理済みであることを示す第２状態に変更されることなく所定時間が経過し、かつ前記特定のユーザの識別情報に、新たなチケット情報が対応付けて記憶されていない場合に、前記特定のユーザの識別情報と前記特定のチケット情報との対応付けを解除する
ことを含む処理を実行させるチケット販売プログラム。
（付記２）
前記特定のユーザの識別情報及び前記第１状態に対応付けられて複数のチケット情報が記憶されている場合、いずれかのチケット情報の記憶した時刻、及び何れかのチケット情報に対応する第１状態が第２状態へ変更された時刻のうち最新の時刻から所定時間が経過するまで、前記特定のユーザによる前記複数のチケット情報の各々が示す複数のチケットに対する一括での決済指示を受け付け可能とする付記１記載のチケット販売プログラム。
（付記３）
前記コンピュータに、受信した前記購入要求を保持すると共に、前記チケット情報と該チケット情報が示すチケットの販売状況とが対応付けられた複数のチケット販売情報が記憶されたデータベースへのアクセス数が所定期間において一定数を超えないように、保持している前記購入要求の中から受信順に選択した購入要求に基づいて、前記データベースにアクセスすることをさらに含む処理を実行させる付記１又は付記２記載のチケット販売プログラム。
（付記４）
前記データベースは、複数の属性別データベースを含み、チケットの属性に応じて分類されたチケット販売情報が、各属性別データベースに記憶されるチケット販売情報の数の差が所定数以下となるように、各チケットの属性に応じた属性別データベースに分散して記憶される付記３記載のチケット販売プログラム。
（付記５）
前記コンピュータに、前記チケット情報と該チケット情報が示すチケットの販売状況とが対応付けられた複数のチケット販売情報が記憶されたデータベースに記憶されたチケット毎の販売状況を集計して、各チケットの販売残数を参照するための参照用データベースを更新することをさらに含む処理を実行させる付記１〜付記４のいずれか１項記載のチケット販売プログラム。
（付記６）
コンピュータに、
イベントへの参加証であるチケットのチケット情報と、前記チケットが販売されていない状態を示す未販売、特定のユーザからの購入要求を受け付けた状態で決済が完了していない状態を示す仮販売、及び決済が完了した状態を示す販売済のいずれかの状態とを対応付けて、１又は複数のイベント毎に設けられた第１記憶部に記憶し、
ユーザの識別情報と共に、特定のイベントを対象としたチケットの指定を含む購入要求を受け付けると、前記購入要求で対象とされたイベントについて設けられた前記第１記憶部を参照して、未販売の状態と対応付けられたチケット情報の内のいずれかのチケット情報に対応する状態を仮販売の状態に変更すると共に、変更した状態に対応付けられたチケット情報と、ユーザの識別情報と、該チケット情報が示すチケットを確保したが決済が完了していないことを示す仮購入の状態と、前記仮販売の状態に変更した時刻とを対応付けて第２記憶部に記憶し、
特定のユーザの識別情報と対応付けて前記第２記憶部に記憶された時刻から所定時間経過し、かつ前記特定のユーザの識別情報と対応付けられた新たなチケット情報、及び前記仮購入の状態から、決済が完了したことを示す購入済みの状態への変更のいずれもが前記第２記憶部に記憶されていない場合には、前記第２記憶部に記憶された前記特定のユーザの識別情報に対応付けられたチケット情報に対応付けられて前記第１記憶部に記憶されている状態を未販売の状態に変更し、
特定のユーザの識別情報と対応付けて前記第２記憶部に記憶された時刻から所定時間経過する前に、前記特定のユーザの識別情報と対応付けられた新たなチケット情報、又は前記仮購入の状態から前記購入済みの状態への変更のいずれかが前記第２記憶部に記憶されている場合には、前記所定時間の経過を、前記特定のユーザの識別情報に対応付けて前記第２記憶部に記憶された時刻から計測するように設定する
ことを含む処理を実行させるチケット販売プログラム。
（付記７）
ユーザの識別情報と共に、チケットの指定を含む購入要求を受信する受信部と、
受信した前記購入要求で指定されたチケットのチケット情報と、前記ユーザの識別情報と、決済処理が未処理であることを示す第１状態とを対応付けて記憶し、特定のチケット情報及び特定のユーザの識別情報に対応付けて記憶された第１状態が、決済処理済みであることを示す第２状態に変更されることなく所定時間が経過し、かつ前記特定のユーザの識別情報に、新たなチケット情報が対応付けて記憶されていない場合に、前記特定のユーザの識別情報と前記特定のチケット情報との対応付けを解除する制御を行う管理部と、
を含むチケット販売装置。
（付記８）
前記管理部は、前記特定のユーザの識別情報及び前記第１状態に対応付けられて複数のチケット情報が記憶されている場合、いずれかのチケット情報の記憶した時刻、及び何れかのチケット情報に対応する第１状態が第２状態へ変更された時刻のうち最新の時刻から所定時間が経過するまで、前記特定のユーザによる前記複数のチケット情報の各々が示す複数のチケットに対する一括での決済指示を受け付け可能とする付記７記載のチケット販売装置。
（付記９）
前記管理部は、受信した前記購入要求を保持すると共に、前記チケット情報と該チケット情報が示すチケットの販売状況とが対応付けられた複数のチケット販売情報が記憶されたデータベースへのアクセス数が所定期間において一定数を超えないように、保持している前記購入要求の中から受信順に選択した購入要求に基づいて、前記データベースにアクセスする付記７又は付記８記載のチケット販売装置。
（付記１０）
前記データベースは、複数の属性別データベースを含み、チケットの属性に応じて分類されたチケット販売情報が、各属性別データベースに記憶されるチケット販売情報の数の差が所定数以下となるように、各チケットの属性に応じた属性別データベースに分散して記憶される付記９記載のチケット販売装置。
（付記１１）
前記チケット情報と該チケット情報が示すチケットの販売状況とが対応付けられた複数のチケット販売情報が記憶されたデータベースに記憶されたチケット毎の販売状況を集計して、各チケットの販売残数を参照するための参照用データベースを更新する参照更新部をさらに含む付記７〜付記１０のいずれか１項記載のチケット販売装置。
（付記１２）
イベントへの参加証であるチケットのチケット情報と、前記チケットが販売されていない状態を示す未販売、特定のユーザからの購入要求を受け付けた状態で決済が完了していない状態を示す仮販売、及び決済が完了した状態を示す販売済のいずれかの状態とを対応付けて、１又は複数のイベント毎に設けられた第１記憶部に記憶し、
ユーザの識別情報と共に、特定のイベントを対象としたチケットの指定を含む購入要求を受け付けると、前記購入要求で対象とされたイベントについて設けられた前記第１記憶部を参照して、未販売の状態と対応付けられたチケット情報の内のいずれかのチケット情報に対応する状態を仮販売の状態に変更すると共に、変更した状態に対応付けられたチケット情報と、ユーザの識別情報と、該チケット情報が示すチケットを確保したが決済が完了していないことを示す仮購入の状態と、前記仮販売の状態に変更した時刻とを対応付けて第２記憶部に記憶し、
特定のユーザの識別情報と対応付けて前記第２記憶部に記憶された時刻から所定時間経過し、かつ前記特定のユーザの識別情報と対応付けられた新たなチケット情報、及び前記仮購入の状態から、決済が完了したことを示す購入済みの状態への変更のいずれもが前記第２記憶部に記憶されていない場合には、前記第２記憶部に記憶された前記特定のユーザの識別情報に対応付けられたチケット情報に対応付けられて前記第１記憶部に記憶されている状態を未販売の状態に変更し、
特定のユーザの識別情報と対応付けて前記第２記憶部に記憶された時刻から所定時間経過する前に、前記特定のユーザの識別情報と対応付けられた新たなチケット情報、又は前記仮購入の状態から前記購入済みの状態への変更のいずれかが前記第２記憶部に記憶されている場合には、前記所定時間の経過を、前記特定のユーザの識別情報に対応付けて前記第２記憶部に記憶された時刻から計測するように設定する
ことを含む処理を実行するチケット販売装置。
（付記１３）
コンピュータに、
ユーザの識別情報と共に、チケットの指定を含む購入要求を受信し、
受信した前記購入要求で指定されたチケットのチケット情報と、前記ユーザの識別情報と、決済処理が未処理であることを示す第１状態とを対応付けて記憶し、
特定のチケット情報及び特定のユーザの識別情報に対応付けて記憶された第１状態が、決済処理済みであることを示す第２状態に変更されることなく所定時間が経過し、かつ前記特定のユーザの識別情報に、新たなチケット情報が対応付けて記憶されていない場合に、前記特定のユーザの識別情報と前記特定のチケット情報との対応付けを解除する
ことを含む処理を実行させるチケット販売方法。
（付記１４）
前記特定のユーザの識別情報及び前記第１状態に対応付けられて複数のチケット情報が記憶されている場合、いずれかのチケット情報の記憶した時刻、及び何れかのチケット情報に対応する第１状態が第２状態へ変更された時刻のうち最新の時刻から所定時間が経過するまで、前記特定のユーザによる前記複数のチケット情報の各々が示す複数のチケットに対する一括での決済指示を受け付け可能とする付記１３記載のチケット販売方法。
（付記１５）
前記コンピュータに、受信した前記購入要求を保持すると共に、前記チケット情報と該チケット情報が示すチケットの販売状況とが対応付けられた複数のチケット販売情報が記憶されたデータベースへのアクセス数が所定期間において一定数を超えないように、保持している前記購入要求の中から受信順に選択した購入要求に基づいて、前記データベースにアクセスすることをさらに含む処理を実行させる付記１３又は付記１４記載のチケット販売方法。
（付記１６）
前記データベースは、複数の属性別データベースを含み、チケットの属性に応じて分類されたチケット販売情報が、各属性別データベースに記憶されるチケット販売情報の数の差が所定数以下となるように、各チケットの属性に応じた属性別データベースに分散して記憶される付記１５記載のチケット販売方法。
（付記１７）
前記コンピュータに、前記チケット情報と該チケット情報が示すチケットの販売状況とが対応付けられた複数のチケット販売情報が記憶されたデータベースに記憶されたチケット毎の販売状況を集計して、各チケットの販売残数を参照するための参照用データベースを更新することをさらに含む処理を実行させる付記１３〜付記１６のいずれか１項記載のチケット販売方法。
（付記１８）
コンピュータに、
イベントへの参加証であるチケットのチケット情報と、前記チケットが販売されていない状態を示す未販売、特定のユーザからの購入要求を受け付けた状態で決済が完了していない状態を示す仮販売、及び決済が完了した状態を示す販売済のいずれかの状態とを対応付けて、１又は複数のイベント毎に設けられた第１記憶部に記憶し、
ユーザの識別情報と共に、特定のイベントを対象としたチケットの指定を含む購入要求を受け付けると、前記購入要求で対象とされたイベントについて設けられた前記第１記憶部を参照して、未販売の状態と対応付けられたチケット情報の内のいずれかのチケット情報に対応する状態を仮販売の状態に変更すると共に、変更した状態に対応付けられたチケット情報と、ユーザの識別情報と、該チケット情報が示すチケットを確保したが決済が完了していないことを示す仮購入の状態と、前記仮販売の状態に変更した時刻とを対応付けて第２記憶部に記憶し、
特定のユーザの識別情報と対応付けて前記第２記憶部に記憶された時刻から所定時間経過し、かつ前記特定のユーザの識別情報と対応付けられた新たなチケット情報、及び前記仮購入の状態から、決済が完了したことを示す購入済みの状態への変更のいずれもが前記第２記憶部に記憶されていない場合には、前記第２記憶部に記憶された前記特定のユーザの識別情報に対応付けられたチケット情報に対応付けられて前記第１記憶部に記憶されている状態を未販売の状態に変更し、
特定のユーザの識別情報と対応付けて前記第２記憶部に記憶された時刻から所定時間経過する前に、前記特定のユーザの識別情報と対応付けられた新たなチケット情報、又は前記仮購入の状態から前記購入済みの状態への変更のいずれかが前記第２記憶部に記憶されている場合には、前記所定時間の経過を、前記特定のユーザの識別情報に対応付けて前記第２記憶部に記憶された時刻から計測するように設定する
ことを含む処理を実行させるチケット販売方法。
（付記１９）
コンピュータに、
ユーザの識別情報と共に、チケットの指定を含む購入要求を受信し、
受信した前記購入要求で指定されたチケットのチケット情報と、前記ユーザの識別情報と、決済処理が未処理であることを示す第１状態とを対応付けて記憶し、
特定のチケット情報及び特定のユーザの識別情報に対応付けて記憶された第１状態が、決済処理済みであることを示す第２状態に変更されることなく所定時間が経過し、かつ前記特定のユーザの識別情報に、新たなチケット情報が対応付けて記憶されていない場合に、前記特定のユーザの識別情報と前記特定のチケット情報との対応付けを解除する
ことを含む処理を実行させるチケット販売プログラムを記憶した記憶媒体。
（付記２０）
コンピュータに、
イベントへの参加証であるチケットのチケット情報と、前記チケットが販売されていない状態を示す未販売、特定のユーザからの購入要求を受け付けた状態で決済が完了していない状態を示す仮販売、及び決済が完了した状態を示す販売済のいずれかの状態とを対応付けて、１又は複数のイベント毎に設けられた第１記憶部に記憶し、
ユーザの識別情報と共に、特定のイベントを対象としたチケットの指定を含む購入要求を受け付けると、前記購入要求で対象とされたイベントについて設けられた前記第１記憶部を参照して、未販売の状態と対応付けられたチケット情報の内のいずれかのチケット情報に対応する状態を仮販売の状態に変更すると共に、変更した状態に対応付けられたチケット情報と、ユーザの識別情報と、該チケット情報が示すチケットを確保したが決済が完了していないことを示す仮購入の状態と、前記仮販売の状態に変更した時刻とを対応付けて第２記憶部に記憶し、
特定のユーザの識別情報と対応付けて前記第２記憶部に記憶された時刻から所定時間経過し、かつ前記特定のユーザの識別情報と対応付けられた新たなチケット情報、及び前記仮購入の状態から、決済が完了したことを示す購入済みの状態への変更のいずれもが前記第２記憶部に記憶されていない場合には、前記第２記憶部に記憶された前記特定のユーザの識別情報に対応付けられたチケット情報に対応付けられて前記第１記憶部に記憶されている状態を未販売の状態に変更し、
特定のユーザの識別情報と対応付けて前記第２記憶部に記憶された時刻から所定時間経過する前に、前記特定のユーザの識別情報と対応付けられた新たなチケット情報、又は前記仮購入の状態から前記購入済みの状態への変更のいずれかが前記第２記憶部に記憶されている場合には、前記所定時間の経過を、前記特定のユーザの識別情報に対応付けて前記第２記憶部に記憶された時刻から計測するように設定する
ことを含む処理を実行させるチケット販売プログラムを記憶した記憶媒体。
１０、２１０、３１０、５１０ｎ チケット販売装置
１１ 受信部
１２ 提示部
１３、３１３ 参照更新部
１４、３１４ 管理部
２０、２２０Ｂ、３２０、４２０Ｂ、５２０Ｂｎ データベースサーバ
２１ 参照データベース
２２、２２２ｎ 詳細データベース
２３ 管理データベース
３０ 決済処理システム
３５ ユーザ端末
４０、７０、９０、１５０ コンピュータ
４１、７１、９１、１５１ ＣＰＵ
４２、７２、９２、１５２ メモリ
４３、７３、９３、１５３ 記憶部
４９、７９、９９、１５９ 記録媒体
５０、２５０Ａ、２５０Ｂ、２５０Ｃ、３５０、４５０Ｂ、４５０Ｃ 、５５０Ａ、５５０Ｄ チケット販売プログラム
６１ イベント検索画面
６２ イベント一覧画面
６３ 申込画面
６４ 買い物カゴ画面
６４Ｃ 一括決済ボタン
１００、２００、３００、４００ チケット販売システム
２２０Ａ、４２０Ａ キューサーバ
２２２ 分散型詳細データベース
５２０ 管理サーバ

Claims (10)

  1. コンピュータに、
    ユーザの識別情報と共に、チケットの指定を含む購入要求を受信し、
    受信した前記購入要求で指定されたチケットのチケット情報と、前記ユーザの識別情報と、決済処理が未処理であることを示す第１状態とを対応付けて記憶し、
    特定のチケット情報及び特定のユーザの識別情報に対応付けて記憶された第１状態が、決済処理済みであることを示す第２状態に変更されることなく所定時間が経過し、かつ前記特定のユーザの識別情報に、新たなチケット情報が対応付けて記憶されていない場合に、前記特定のユーザの識別情報と前記特定のチケット情報との対応付けを解除し、
    前記特定のユーザの識別情報に、前記新たなチケット情報が対応付けて記憶されている場合、前記特定のユーザによる前記特定のチケット情報及び前記新たなチケット情報の各々が示す複数のチケットに対する一括での決済指示を受け付け可能とする
    ことを含む処理を実行させるチケット販売プログラム。
  2. 前記特定のユーザの識別情報及び前記第１状態に対応付けられて複数のチケット情報が記憶されている場合、いずれかのチケット情報の記憶した時刻、及び何れかのチケット情報に対応する第１状態が第２状態へ変更された時刻のうち最新の時刻から所定時間が経過するまで、前記特定のユーザによる前記複数のチケット情報の各々が示す複数のチケットに対する一括での決済指示を受け付け可能とする請求項１記載のチケット販売プログラム。
  3. 前記コンピュータに、受信した前記購入要求を保持すると共に、前記チケット情報と該チケット情報が示すチケットの販売状況とが対応付けられた複数のチケット販売情報が記憶されたデータベースへのアクセス数が所定期間において一定数を超えないように、保持している前記購入要求の中から受信順に選択した購入要求に基づいて、前記データベースにアクセスすることをさらに含む処理を実行させる請求項１又は請求項２記載のチケット販売プログラム。
  4. 前記データベースは、複数の属性別データベースを含み、チケットの属性に応じて分類されたチケット販売情報が、各属性別データベースに記憶されるチケット販売情報の数の差が所定数以下となるように、各チケットの属性に応じた属性別データベースに分散して記憶される請求項３記載のチケット販売プログラム。
  5. 前記コンピュータに、前記チケット情報と該チケット情報が示すチケットの販売状況とが対応付けられた複数のチケット販売情報が記憶されたデータベースに記憶されたチケット毎の販売状況を集計して、各チケットの販売残数を参照するための参照用データベースを更新することをさらに含む処理を実行させる請求項１〜請求項４のいずれか１項記載のチケット販売プログラム。
  6. コンピュータに、
    イベントへの参加証であるチケットのチケット情報と、前記チケットが販売されていない状態を示す未販売、特定のユーザからの購入要求を受け付けた状態で決済が完了していない状態を示す仮販売、及び決済が完了した状態を示す販売済のいずれかの状態とを対応付けて、１又は複数のイベント毎に設けられた第１記憶部に記憶し、
    ユーザの識別情報と共に、特定のイベントを対象としたチケットの指定を含む購入要求を受け付けると、前記購入要求で対象とされたイベントについて設けられた前記第１記憶部を参照して、未販売の状態と対応付けられたチケット情報の内のいずれかのチケット情報に対応する状態を仮販売の状態に変更すると共に、変更した状態に対応付けられたチケット情報と、ユーザの識別情報と、該チケット情報が示すチケットを確保したが決済が完了していないことを示す仮購入の状態と、前記仮販売の状態に変更した時刻とを対応付けて第２記憶部に記憶し、
    特定のユーザの識別情報と対応付けて前記第２記憶部に記憶された時刻から所定時間経過し、かつ前記特定のユーザの識別情報と対応付けられた新たなチケット情報、及び前記仮購入の状態から、決済が完了したことを示す購入済みの状態への変更のいずれもが前記第２記憶部に記憶されていない場合には、前記第２記憶部に記憶された前記特定のユーザの識別情報に対応付けられたチケット情報に対応付けられて前記第１記憶部に記憶されている状態を未販売の状態に変更し、
    特定のユーザの識別情報と対応付けて前記第２記憶部に記憶された時刻から所定時間経過する前に、前記特定のユーザの識別情報と対応付けられた新たなチケット情報、又は前記仮購入の状態から前記購入済みの状態への変更のいずれかが前記第２記憶部に記憶されている場合には、前記所定時間の経過を、前記特定のユーザの識別情報に対応付けて前記第２記憶部に記憶された時刻から計測するように設定する
    ことを含む処理を実行させるチケット販売プログラム。
  7. ユーザの識別情報と共に、チケットの指定を含む購入要求を受信する受信部と、
    受信した前記購入要求で指定されたチケットのチケット情報と、前記ユーザの識別情報と、決済処理が未処理であることを示す第１状態とを対応付けて記憶し、特定のチケット情報及び特定のユーザの識別情報に対応付けて記憶された第１状態が、決済処理済みであることを示す第２状態に変更されることなく所定時間が経過し、かつ前記特定のユーザの識別情報に、新たなチケット情報が対応付けて記憶されていない場合に、前記特定のユーザの識別情報と前記特定のチケット情報との対応付けを解除し、前記特定のユーザの識別情報に、前記新たなチケット情報が対応付けて記憶されている場合、前記特定のユーザによる前記特定のチケット情報及び前記新たなチケット情報の各々が示す複数のチケットに対する一括での決済指示を受け付け可能とする制御を行う管理部と、
    を含むチケット販売装置。
  8. イベントへの参加証であるチケットのチケット情報と、前記チケットが販売されていない状態を示す未販売、特定のユーザからの購入要求を受け付けた状態で決済が完了していない状態を示す仮販売、及び決済が完了した状態を示す販売済のいずれかの状態とを対応付けて、１又は複数のイベント毎に設けられた第１記憶部に記憶し、
    ユーザの識別情報と共に、特定のイベントを対象としたチケットの指定を含む購入要求を受け付けると、前記購入要求で対象とされたイベントについて設けられた前記第１記憶部を参照して、未販売の状態と対応付けられたチケット情報の内のいずれかのチケット情報に対応する状態を仮販売の状態に変更すると共に、変更した状態に対応付けられたチケット情報と、ユーザの識別情報と、該チケット情報が示すチケットを確保したが決済が完了していないことを示す仮購入の状態と、前記仮販売の状態に変更した時刻とを対応付けて第２記憶部に記憶し、
    特定のユーザの識別情報と対応付けて前記第２記憶部に記憶された時刻から所定時間経過し、かつ前記特定のユーザの識別情報と対応付けられた新たなチケット情報、及び前記仮購入の状態から、決済が完了したことを示す購入済みの状態への変更のいずれもが前記第２記憶部に記憶されていない場合には、前記第２記憶部に記憶された前記特定のユーザの識別情報に対応付けられたチケット情報に対応付けられて前記第１記憶部に記憶されている状態を未販売の状態に変更し、
    特定のユーザの識別情報と対応付けて前記第２記憶部に記憶された時刻から所定時間経過する前に、前記特定のユーザの識別情報と対応付けられた新たなチケット情報、又は前記仮購入の状態から前記購入済みの状態への変更のいずれかが前記第２記憶部に記憶されている場合には、前記所定時間の経過を、前記特定のユーザの識別情報に対応付けて前記第２記憶部に記憶された時刻から計測するように設定する
    ことを含む処理を実行するチケット販売装置。
  9. コンピュータに、
    ユーザの識別情報と共に、チケットの指定を含む購入要求を受信し、
    受信した前記購入要求で指定されたチケットのチケット情報と、前記ユーザの識別情報と、決済処理が未処理であることを示す第１状態とを対応付けて記憶し、
    特定のチケット情報及び特定のユーザの識別情報に対応付けて記憶された第１状態が、決済処理済みであることを示す第２状態に変更されることなく所定時間が経過し、かつ前記特定のユーザの識別情報に、新たなチケット情報が対応付けて記憶されていない場合に、前記特定のユーザの識別情報と前記特定のチケット情報との対応付けを解除し、
    前記特定のユーザの識別情報に、前記新たなチケット情報が対応付けて記憶されている場合、前記特定のユーザによる前記特定のチケット情報及び前記新たなチケット情報の各々が示す複数のチケットに対する一括での決済指示を受け付け可能とする
    ことを含む処理を実行させるチケット販売方法。
  10. コンピュータに、
    イベントへの参加証であるチケットのチケット情報と、前記チケットが販売されていない状態を示す未販売、特定のユーザからの購入要求を受け付けた状態で決済が完了していない状態を示す仮販売、及び決済が完了した状態を示す販売済のいずれかの状態とを対応付けて、１又は複数のイベント毎に設けられた第１記憶部に記憶し、
    ユーザの識別情報と共に、特定のイベントを対象としたチケットの指定を含む購入要求を受け付けると、前記購入要求で対象とされたイベントについて設けられた前記第１記憶部を参照して、未販売の状態と対応付けられたチケット情報の内のいずれかのチケット情報に対応する状態を仮販売の状態に変更すると共に、変更した状態に対応付けられたチケット情報と、ユーザの識別情報と、該チケット情報が示すチケットを確保したが決済が完了していないことを示す仮購入の状態と、前記仮販売の状態に変更した時刻とを対応付けて第２記憶部に記憶し、
    特定のユーザの識別情報と対応付けて前記第２記憶部に記憶された時刻から所定時間経過し、かつ前記特定のユーザの識別情報と対応付けられた新たなチケット情報、及び前記仮購入の状態から、決済が完了したことを示す購入済みの状態への変更のいずれもが前記第２記憶部に記憶されていない場合には、前記第２記憶部に記憶された前記特定のユーザの識別情報に対応付けられたチケット情報に対応付けられて前記第１記憶部に記憶されている状態を未販売の状態に変更し、
    特定のユーザの識別情報と対応付けて前記第２記憶部に記憶された時刻から所定時間経過する前に、前記特定のユーザの識別情報と対応付けられた新たなチケット情報、又は前記仮購入の状態から前記購入済みの状態への変更のいずれかが前記第２記憶部に記憶されている場合には、前記所定時間の経過を、前記特定のユーザの識別情報に対応付けて前記第２記憶部に記憶された時刻から計測するように設定する
    ことを含む処理を実行させるチケット販売方法。
JP2016005922A 2016-01-15 2016-01-15 チケット販売プログラム、装置、及び方法 Active JP6696184B2 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2016005922A JP6696184B2 (ja) 2016-01-15 2016-01-15 チケット販売プログラム、装置、及び方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2016005922A JP6696184B2 (ja) 2016-01-15 2016-01-15 チケット販売プログラム、装置、及び方法

Publications (2)

Publication Number Publication Date
JP2017126250A JP2017126250A (ja) 2017-07-20
JP6696184B2 true JP6696184B2 (ja) 2020-05-20

Family

ID=59365298

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2016005922A Active JP6696184B2 (ja) 2016-01-15 2016-01-15 チケット販売プログラム、装置、及び方法

Country Status (1)

Country Link
JP (1) JP6696184B2 (ja)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111612561B (zh) * 2019-02-26 2024-05-21 阿里巴巴集团控股有限公司 信息的规划方法、计算设备及存储介质

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH06259478A (ja) * 1993-03-02 1994-09-16 Toshiba Corp 分散データベースのデータ再配置方式
CN1359500A (zh) * 1999-03-02 2002-07-17 美国安利有限公司 能包括会员购买机会的市场交易和销售的方法
JP2001022825A (ja) * 1999-07-09 2001-01-26 Fukui Computer Kk 電子ショッピングシステム
JP2002150064A (ja) * 2000-11-10 2002-05-24 Sofmap Co Ltd 電子商取引システム及び仮想店舗システム
JP2003141066A (ja) * 2001-06-20 2003-05-16 Matsushita Electric Ind Co Ltd ネットワークシステムおよびエージェントサーバ
JP5594705B2 (ja) * 2012-12-25 2014-09-24 楽天株式会社 座席管理システム、座席管理システムの制御方法、及びプログラム
JP6469352B2 (ja) * 2014-03-31 2019-02-13 ぴあ株式会社 商品販売装置、商品販売プログラム、商品販売方法

Also Published As

Publication number Publication date
JP2017126250A (ja) 2017-07-20

Similar Documents

Publication Publication Date Title
US8015068B2 (en) Systems and methods for managing orders made via a computer network
JP2002024624A (ja) 通信ネットワーク上の販売システム
JP5149958B2 (ja) 商品受注装置、商品受注方法、商品受注プログラム、及びそのプログラムを記録するコンピュータ読取可能な記録媒体
JP4448272B2 (ja) ネットワークシステム、購入履歴提示方法、サーバ装置、プログラム、および記録媒体
WO2014148101A1 (ja) レビュー管理装置、レビュー管理方法、およびレビュー管理プログラム
JP5781114B2 (ja) 個人間商品取引システム
JP6696184B2 (ja) チケット販売プログラム、装置、及び方法
JP6280272B1 (ja) 決定装置、決定方法、及び決定プログラム
JP7335031B2 (ja) サーバー、トークン管理方法、及びプログラム
JP2019128629A (ja) 限られたサービス提供枠に対する予約システム及び予約方法
US7587340B2 (en) Method and apparatus for selling with short-bidding on goods
JP6760431B2 (ja) 電子レシート処理装置、電子レシート処理方法およびプログラム
US20190130477A1 (en) Systems and methods for managing certificates of transporation
JP2006215841A (ja) 証券取引情報提供システムおよび証券発注プログラム
JPWO2016084258A1 (ja) 情報処理装置、情報処理方法、及び情報処理プログラム
JP6298738B2 (ja) 情報提供装置、及びプログラム
JP5786001B2 (ja) 需要予測装置およびプログラム
JP6456531B1 (ja) 情報処理装置、情報処理方法および情報処理プログラム
US20160104173A1 (en) Real-time economic indicator
KR100707724B1 (ko) 온라인 쇼핑몰 중개 방법 및 온라인 쇼핑몰 중개 시스템
JP3693947B2 (ja) ポイントサービス提供システム
JP7453491B2 (ja) オークション処理システム、オークション処理プログラム、及びオークション処理方法
JP4500322B2 (ja) 情報処理装置、情報処理システム、情報処理方法及びプログラム
KR102302859B1 (ko) 판매 수익 분배를 이용한 상품 판매 촉진 시스템
JP3984925B2 (ja) 情報処理装置及び情報処理システム

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20180912

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20190716

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20190903

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20191004

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20200324

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20200406

R150 Certificate of patent or registration of utility model

Ref document number: 6696184

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150