図面 (/)

技術 商品販売装置、商品販売プログラム、商品販売方法

出願人 ぴあ株式会社
発明者 山中伸浩早川弘朗大坂俊介
出願日 2014年3月31日 (5年3ヶ月経過) 出願番号 2014-073321
公開日 2015年11月5日 (3年8ヶ月経過) 公開番号 2015-194964
状態 特許登録済
技術分野 特定用途計算機 検索装置
主要キーワード キャンセル回数 指定日数 販売サーバー キャンセル依頼 開始回数 占有期間 チケット購入希望者 商品販売プログラム
関連する未来課題
重要な関連分野

この項目の情報は公開日時点(2015年11月5日)のものです。
また、この項目は機械的に抽出しているため、正しく解析できていない場合があります

図面 (14)

課題

商品購入者が簡便且つ確実に所望の商品購入することを可能にすると共に、商品販売者販売効率を向上させる商品販売装置等を提供する。

解決手段

購入希望者が購入を希望する商品の決済処理を行う商品販売装置等である。購入希望者から受信した商品の属性情報を、商品検索のための検索条件として記憶する検索条件記憶手段と、予め設定された検索のタイミングで、商品を特定するための商品特定情報とその商品の属性情報とが関連づけられている商品データベースを、前記検索条件に基づいて検索処理する検索手段と、商品代金決済に関する前記購入希望者の事前承認と、商品の代金を決済するための決済情報に基づいて、前記検索処理により検索された商品の代金の決済処理を行う決済手段とを備える。

概要

背景

近年、ネット通販と呼ばれるインターネットを利用した商品購入が盛んに行われており、ネット通販の方法にも様々な方法が提供されている。
例えば、検索キーワードを予めコンピュータ登録することにより、簡便に所望の商品を購入できるネット通販の方法が提案されている(例えば、特許文献1)。これは購入者が検索キーワードを予めコンピュータに登録し、コンピュータが定期的、且つ自動的にその検索キーワードに合致する商品を検索する。検索キーワードに合致する商品がある場合、その商品の内容が購入者に通知される。購入者はその商品を購入する意思がある場合、クレジットカード等で決済を行い、それにより商品が購入者に届けられる。このようにすれば購入者は何度も検索キーワードを入力して検索作業を行わずに済むのである。

概要

商品購入者が簡便且つ確実に所望の商品を購入することを可能にすると共に、商品販売者販売効率を向上させる商品販売装置等を提供する。購入希望者が購入を希望する商品の決済処理を行う商品販売装置等である。購入希望者から受信した商品の属性情報を、商品検索のための検索条件として記憶する検索条件記憶手段と、予め設定された検索のタイミングで、商品を特定するための商品特定情報とその商品の属性情報とが関連づけられている商品データベースを、前記検索条件に基づいて検索処理する検索手段と、商品代金の決済に関する前記購入希望者の事前承認と、商品の代金を決済するための決済情報に基づいて、前記検索処理により検索された商品の代金の決済処理を行う決済手段とを備える。

目的

本発明は、商品購入者が簡便且つ確実に所望の商品を購入することを可能にすると共に、商品販売者の販売効率を向上させる商品販売装置等を提供する

効果

実績

技術文献被引用数
0件
牽制数
0件

この技術が所属する分野

(分野番号表示ON)※整理標準化データをもとに当社作成

ライセンス契約や譲渡などの可能性がある特許掲載中! 開放特許随時追加・更新中 詳しくはこちら

請求項1

購入希望者購入希望する商品決済処理を行う商品販売装置において、前記購入希望者から受信した商品の属性情報を、商品検索のための検索条件として記憶する検索条件記憶手段と、予め設定された検索のタイミングで、商品を特定するための商品特定情報とその商品の属性情報とが関連づけられている商品データベースを、前記検索条件に基づいて検索処理する検索手段と、商品代金決済に関する前記購入希望者の事前承認と、商品の代金を決済するための決済情報に基づいて、前記検索処理により検索された商品の代金の決済処理を行う決済手段と、を備える商品販売装置。

請求項2

前記決済処理により決済された前記商品のキャンセル期間内に、顧客からキャンセル依頼があった場合、前記決済処理をキャンセルする決済キャンセル手段を備えることを特徴とする請求項1記載の商品販売装置。

請求項3

前記決済キャンセル手段は、キャンセルした顧客に対しキャンセル料を請求することを特徴とする請求項2記載の商品販売装置。

請求項4

前記決済キャンセル手段は、予め設定されたキャンセル回数を超えた場合にのみ前記キャンセル料を請求することを特徴とする請求項3記載の商品販売装置。

請求項5

前記商品は興行チケットであり、前記決済手段は、同一公演者が連日公演を行う場合、1つの公演のみ決済処理することを特徴とする請求項1記載の商品販売装置。

請求項6

前記商品は興行チケットであり、前記決済手段は、定期公演の場合、1つの公演のみ決済処理することを特徴とする請求項1記載の商品販売装置。

請求項7

前記商品は興行チケットであり、前記決済手段は、同一公演日において1つの公演のみを決済処理することを特徴とする請求項1記載の商品販売装置。

請求項8

前記検索条件の適正性を、商品購入者購入履歴に基づいて判断する適正性判断手段を備えることを特徴とする請求項1記載の商品販売装置。

請求項9

前記商品は興行チケットであり、公演終了後、再度その公演の興行チケット購入を行うか否かを確認する再購入確認手段を備えることを特徴とする請求項1記載の商品販売装置。

請求項10

前記検索手段は、未確定の状態の検索条件に基づいて、前記検索処理を行うことを特徴とする請求項1記載の商品販売装置。

請求項11

前記検索処理により検索された商品の占有期間内に顧客から送信された決済依頼と、前記決済情報に基づいて、前記検索処理で検索された商品の決済を行う決済依頼による決済手段を備えることを特徴とする請求項1記載の商品販売装置。

請求項12

前記検索処理により検索された商品の占有期間が経過した場合、前記決済情報に基づいて、前記検索処理で検索された商品の決済を行う占有期間経過による決済手段を備えることを特徴とする請求項1記載の商品販売装置。

請求項13

前記検索手段は、前記検索条件を減らして検索することを特徴とする請求項11または請求項12記載の商品販売装置。

請求項14

購入希望者が購入を希望する商品の決済処理を行うプログラムにおいて、コンピュータを、前記購入希望者から受信した商品の属性情報を、商品検索のための検索条件として記憶する検索条件記憶手段、予め設定された検索のタイミングで、商品を特定するための商品特定情報とその商品の属性情報とが関連づけられている商品データベースを、前記検索条件に基づいて検索処理する検索手段、商品代金の決済に関する前記購入希望者の事前承認と、商品の代金を決済するための決済情報に基づいて、前記検索処理により検索された商品の代金の決済処理を行う決済手段、として機能させることを特徴とする商品販売プログラム

請求項15

購入希望者が、購入を希望する商品の決済処理を行う商品販売方法において、検索条件記憶手段が、前記購入希望者から受信した商品の属性情報を、商品検索のための検索条件として記憶するステップと、検索手段が、予め設定された検索のタイミングで、商品を特定するための商品特定情報とその商品の属性情報とが関連づけられている商品データベースを、前記検索条件に基づいて検索処理するステップと、決済手段が、商品代金の決済に関する前記購入希望者の事前承認と、商品の代金を決済するための決済情報に基づいて、前記検索処理により検索された商品の代金の決済処理を行うステップと、を有することを特徴とする商品販売方法。

技術分野

0001

本発明は、商品購入者が簡便且つ確実に所望の商品購入することを可能にすると共に、商品販売者販売効率を向上させる商品販売装置等を提供するものである。

背景技術

0002

近年、ネット通販と呼ばれるインターネットを利用した商品の購入が盛んに行われており、ネット通販の方法にも様々な方法が提供されている。
例えば、検索キーワードを予めコンピュータ登録することにより、簡便に所望の商品を購入できるネット通販の方法が提案されている(例えば、特許文献1)。これは購入者が検索キーワードを予めコンピュータに登録し、コンピュータが定期的、且つ自動的にその検索キーワードに合致する商品を検索する。検索キーワードに合致する商品がある場合、その商品の内容が購入者に通知される。購入者はその商品を購入する意思がある場合、クレジットカード等で決済を行い、それにより商品が購入者に届けられる。このようにすれば購入者は何度も検索キーワードを入力して検索作業を行わずに済むのである。

先行技術

0003

特開2001−297214号

発明が解決しようとする課題

0004

上記のように予め検索キーワードを登録すれば、購入者の負担は軽減される。
しかし、上記の方法では、購入者は検索された商品の内容を確認し、その商品について購入意思があることを明らかにした上で決済することが必須になっている。よって、次のような不都合が生じることがある。例えば、興行チケットを扱う業界では、プラチナチケットと呼ばれる希少価値の高い商品がある。このプラチナチケットの購入希望者は、検索キーワードに合致したチケットがあれば即時に決済することを希望することが多い。プラチナチケット購入希望者は、プラチナチケットが入手可能な場合、ほぼ確実に購入するものであり、「購入しない」というケースは極めて少ないからである。即ち、プラチナチケットの購入希望者にとって、チケットの内容を確認したり、購入意思を示すことは不要な手続なのである。また、購入者が、購入手続を行うことを忘れてしまった場合、折角入手可能であったプラチナチケットが入手できなくなってしまうおそれもある。
このように従来の方法には、顧客に面倒な手続を強いたり、商品を確実に入手できないという問題があった。なお、この問題はプラチナチケットだけでなく、その他の商品においても起こり得ることである。

0005

更に、従来の方法では、顧客だけでなく、商品の販売者にとっても不都合な場合がある。即ち、従来の方法では、検索条件に合致した商品が検索された場合、その商品を未決済の状態で予約扱いとし、顧客に商品が検索されたことを通知する。そして、顧客からその商品を購入する意思が示された場合は問題ないが、それが通知がなされない場合(購入を拒否された場合)、販売者はその商品の代金を得られないばかりか、予約を取り消して、再度販売しなければならない。
よって、従来の方法は、販売者にとって効率の良い販売方法とは言えなかった。

0006

本発明は、このような課題を解決するためのものであり、商品購入者が簡便且つ確実に所望の商品を購入することを可能にすると共に、商品販売者の販売効率を向上させる商品販売装置等を提供する。

課題を解決するための手段

0007

上記問題を解決するため、本発明では、購入希望者が購入を希望する商品の決済処理を行う商品販売装置において、前記購入希望者から受信した商品の属性情報を、商品検索のための検索条件として記憶する検索条件記憶手段と、予め設定された検索のタイミングで、商品を特定するための商品特定情報とその商品の属性情報とが関連づけられている商品データベースを、前記検索条件に基づいて検索処理する検索手段と、商品代金の決済に関する前記購入希望者の事前承認と、商品の代金を決済するための決済情報に基づいて、前記検索処理により検索された商品の代金の決済処理を行う決済手段とを備える商品販売装置が提供される。

0008

上記問題を解決するため、本発明では、購入希望者が購入を希望する商品の決済処理を行うプログラムにおいて、コンピュータを、前記購入希望者から受信した商品の属性情報を、商品検索のための検索条件として記憶する検索条件記憶手段、予め設定された検索のタイミングで、商品を特定するための商品特定情報とその商品の属性情報とが関連づけられている商品データベースを、前記検索条件に基づいて検索処理する検索手段、商品代金の決済に関する前記購入希望者の事前承認と、商品の代金を決済するための決済情報に基づいて、前記検索処理により検索された商品の代金の決済処理を行う決済手段として機能させることを特徴とする商品販売プログラムが提供される。

0009

上記問題を解決するため、本発明では、購入希望者が、購入を希望する商品の決済処理を行う商品販売方法において、検索条件記憶手段が、前記購入希望者から受信した商品の属性情報を、商品検索のための検索条件として記憶するステップと、検索手段が、予め設定された検索のタイミングで、商品を特定するための商品特定情報とその商品の属性情報とが関連づけられている商品データベースを、前記検索条件に基づいて検索処理するステップと、決済手段が、商品代金の決済に関する前記購入希望者の事前承認と、商品の代金を決済するための決済情報に基づいて、前記検索処理により検索された商品の代金の決済処理を行うステップとを有することを特徴とする商品販売方法が提供される。

発明の効果

0010

本発明は、予め記憶された検索条件に基づいて商品データベースを検索し、検索された商品の代金の決済を「商品代金の決済に関する購入希望者の事前承認」に基づいて行うので、登録された検索条件に合致した商品があれば、その商品について即時に決済がなされる。
これにより購入者は所望の商品を簡便、且つ確実に購入することができる。即ち、購入者は、商品内容の確認や購入手続などの面倒な手続を行うことなく所望の商品を購入でき、また購入者が購入手続を忘れて折角入手可能であった商品が購入できないという不都合を回避できる。
更に、商品の販売者も、検索条件に合致した商品を確実に販売することができ、販売効率を向上させることができる。

図面の簡単な説明

0011

本発明の実施形態に係るハードウェア構成の一例を表す図である。
第1実施形態における各装置の機能構成図の一例を表す図である。
第1実施形態における顧客データの一例を表す図である。
第1実施形態における条件データの一例を表す図である。
興行データベースの一例を表す図である。
第1実施形態における条件データ入力画面の表示例を表す図である。
チケットの決済完了通知を表す図である。
第1実施形態の全体処理を表すフローチャート図である。
検索条件登録の詳細処理を表すフローチャート図である。
第2実施形態における各装置の機能構成図の一例を表す図である。
第2実施形態における条件データ入力画面の表示例を表す図である。
第2実施形態における条件データの一例を表す図である。
第2実施形態の全体処理を表すフローチャート図である。

実施例

0012

本発明の第1実施形態を図に基づいて説明する。
図1は、本発明の一実施形態を示したシステム構成図(ハードウェア構成図)である。
このシステムは、興行チケットに関する情報を管理・処理するサーバー1(商品販売装置)と、購入希望者が利用する顧客端末2とからなり、各々はインターネット10を介して情報の送受信ができるよう接続されている。

0013

サーバー1は、情報の入出力を行う入出力部、情報の送受信を行う送受信部、情報の処理を行う処理部等を備えたコンピュータである。また、サーバー1は、情報の記憶を行う記憶部11と接続され、情報の記憶を行う。
顧客端末2は、情報の入力を行う入力部12、情報の出力を行う出力部(表示部13)、情報の送受信を行う送受信部、情報の処理を行う処理部、情報の記憶を行う記憶部等を備えたコンピュータ(パーソナルコンピュータ)である。

0014

サーバー1、顧客端末2の記憶部には、本発明を実現するためのコンピュータプログラムや所定のデータが記憶されており、処理部はこのコンピュータプログラムの処理命令に従って所定の処理を行う。

0015

図2は、本発明の一実施形態を示した機能構成図である。
サーバー1は、検索条件調整部21、検索条件記憶部22、チケット検索部23、決済部24、購入通知部25、キャンセル部26とからなる。
検索条件調整部21は、検索条件申請部31から検索条件を取得し、検索条件申請部31との間で検索条件の調整を行い、検索条件を検索条件記憶部22に送信する。
検索条件記憶部22は、検索条件調整部21から検索条件を取得し、記憶装置11に記憶する。
チケット検索部23は、所定のタイミングで、記憶装置から検索条件を取得し、それに基づいて興行データベースを検索(興行チケットの検索処理を行い)、検索条件に合致する興行チケットを抽出し、これを決済部24に送信する。
決済部24は、チケット検索部23から抽出された興行チケットを取得すると共に、記憶装置から顧客の決済情報(クレジットカード番号等)を取得し、興行チケットの決済を行う。また、決済部24は、決済が完了したことを購入通知部25に通知する。
購入通知部25は、決済の完了通知を取得した場合、興行チケットの決済(購入手続)が完了したことを購入確認部32に通知する。
キャンセル部26は、キャンセル要求部33からキャンセル要求を受信した場合、決済済みの興行チケットをキャンセル処理する。

0016

顧客端末2は、検索条件申請部31、購入確認部32、キャンセル要求部33とからなる。
検索条件申請部31は入力装置12から検索条件の入力を受け付け、検索条件を検索条件調整部21に送信する。
購入確認部32は、購入通知部25から興行チケットの決済完了通知を取得し、これを表示モニタ13に表示する。
キャンセル要求部33は、入力装置12からキャンセル要求情報の入力を受け付け、それをキャンセル部26に送信する。

0017

次に、記憶装置11に記憶されているデータについて説明する。
図3は、本実施形態で使用される顧客データの構成図を表したものである。
このデータは、顧客ID(顧客を特定するための情報)に、顧客の氏名、住所、決済情報(クレジットカード番号)、キャンセル回数購入履歴とが関連づけて記憶されているものである。
決済情報とは、興行チケットを購入するための情報であり、ここではクレジットカード番号が記憶されている。なお、クレジットカード番号に限るものではなく銀行口座電子マネーのID等であってもよい。
キャンセル回数とは、これまでチケットを購入したがその後キャンセルした回数を意味する。
購入履歴とは、その顧客がこれまでに購入した興行チケットの履歴である。

0018

図4は、本実施形態で使用される条件データの構成図を表したものである。
このデータは、顧客IDに商品属性情報とが関連づけられているものであり、具体的には、条件番号公演日、曜日指定、開催地域、ジャンルアーティスト名、定期開催の場合の継続購入の要否、同一アーティストの連日購入の要否とが顧客IDに関連づけて記憶されているものである。
定期開催の場合の継続購入の要否とは、定期的に開催される興行の場合、1回のみ購入するのか、開催される興行のチケットを継続して購入するのかを指定する項目である。本発明は、検索条件に合致した興行のチケットを、顧客の購入意思を確認することなく決済するものである。よって、定期開催の場合は、購入者の意に反して何枚ものチケットを決済してしまう可能性があり、顧客にとって不利益が大きい。このような顧客の不利益を防止するため、予め1回のみ購入するのか、継続的に購入するのかを指定しておくのである。

0019

同一アーティストの連日購入の要否とは、同一アーティストが興行を連日開催する場合、1回のみ購入するのか、連日購入するのかを指定する項目である。本発明は、検索条件に合致した興行のチケットを、顧客の購入意思を確認することなく決済するものである。よって、同一アーティストが連日興行を開催する場合は、購入者の意に反して何枚ものチケットを決済してしまう可能性があり、顧客にとって不利益が大きい。このような顧客の不利益を防止するため、予め1回のみ購入するのか、連日購入するのかを指定しておくのである。
公演日とは、顧客がチケット購入を希望する期間を指定する項目であり、期間でなく1日のみを指定してもよい。
曜日指定とは、顧客がチケット購入を希望する曜日を指定する項目であり、1つの曜日のみを指定してもよいし、複数の曜日を指定してもよい。
開催地域とは、顧客がチケット購入を希望する地域を指定する項目であり、1つの地域だけを指定してもよいし、複数の地域を指定してもよい。
ジャンルとは、興行の種別を指定する項目であり、例えば、ロックジャズ、クラシックプロ野球、プロボクシングなどを指定する。
なお、本実施例では、この条件データが商品代金の決済に関する購入希望者の事前承認としての役割を果たす。即ち、サーバー1がこのデータを受信した場合、サーバー1は検索条件に合致した商品があれば、顧客の購入意思を確認することなく決済処理を行うのである。

0020

図5は、本実施形態で使用される興行データベース(商品データベース)の構成図を表したものである。
このデータは、興行番号(興行を特定するための情報)と興行属性情報(商品属性情報)とが関連づけられているものであり、具体的には興行番号と公演日、開催曜日、開催場所、ジャンル、アーティスト名、定期開催区分、同一公演の連日開催区分とが関連づけて記憶されているものである。
定期開催区分とは、その興行が定期的に開催される興行であるか否かを表す区分である。
同一公演の連日開催区分とは、その興行が2日以上連続して開催されるか否かを表す区分である。
アーティスト名とは、アーティストの名前名称を指定する項目である。

0021

図6及び図7は、本実施形態において表示モニタ13に表示される表示例を表したものである。
図6は、検索条件の入力画面である。ここでは図4の条件データとして記憶されるための情報を入力する。顧客は所定の内容を入力し、送信ボタンクリックする。これにより入力された条件がサーバー1に送信され、条件データとして記憶される。
図7は、チケットの決済完了通知の内容である。サーバー1が、興行チケットの決済処理を行った後に、この決算完了通知を顧客端末2に送信する。図7は、この通知を顧客端末2の表示モニタ13に表示した例である。

0022

図8は本実施形態の処理手順を示すフローチャートである。このフローチャートは、条件登録(STEP1)、検索処理(STEP2)、決済処理(STEP3)、購入通知(STEP4)、キャンセル(STEP5)とからなる。

0023

条件登録(STEP1)の詳細は図9の通りである。以下、ステップ毎に説明する。
ステップ1−1は、ID、パスワードの入力処理である。チケット購入を希望する購入者は、顧客端末2を利用してチケット販売会社ウェブサイト顧客認証のためのウェブサイト)にアクセスし、入力装置12(キーボード等)から、IDとパスワードを入力する。サーバー1は顧客端末2から入力されたIDとパスワードを取得する。

0024

ステップ1−2は、IDとパスワードが正当であるか否かを確認する処理である。サーバー1は、顧客端末2から取得したID、パスワードと図3の顧客データに含まれるID、パスワードとが一致するか否かを判断し、一致する場合はステップ1−3に進み、一致しない場合はステップ1−1に戻る。

0025

ステップ1−3は、顧客が購入を希望する興行チケットの条件を入力する処理である。IDとパスワードが正当であると認証された場合、顧客端末2の表示モニタ13には図6のような条件入力画面が表示される。顧客は画面に表示された内容を入力し、送信をクリックする。これにより顧客端末2は入力された条件をサーバー1に送信し、サーバー1これを受信(取得)する。

0026

ステップ1−4は、公演日の指定日数を確認する処理である。サーバー1は、条件に含まれる指定日数を取得し、これが2日以内である場合はステップ1−5に進み、30日以上の場合はステップ1−6に進む。また、指定日数が3日から29日以内であればステップ1−7に進む。

0027

ステップ1−5は、期間拡大指示メッセージを作成するための処理である。条件となる公演日の数が余りに少ないと、検索条件に合致する興行が見つからないという不都合が生じる。よって、ここでは公演日の条件となる期間(指定日数)を拡大するよう顧客に促すメッセージを作成するのである。サーバー1は、記憶装置11に予め記憶されている期間拡大指示を、記憶装置11から取得し、期間拡大指示メッセージを作成する。例えば「公演日の指定日数が少ないため、興行を検索できない可能性があります。指定日数を拡大してみてはいかがでしょうか。」などのメッセージを作成する。

0028

ステップ1−6は、期間短縮指示メッセージを作成するための処理である。条件となる公演日の数が余りに多いと、検索条件に合致する興行が数多く見つかることになる。本発明は、顧客の購入意思を確認することなくチケット代金の決済を行うものであるため、顧客が想像した以上のチケット代金の請求が顧客に対してなされるおそれがある。そこで、このような不都合を回避するため
公演日の条件となる期間(指定日数)を短縮(縮小)するよう顧客に促すメッセージを作成するのである。サーバー1は、記憶装置11に予め記憶されている期間短縮指示を、記憶装置11から取得し、期間短縮指示メッセージを作成する。例えば「公演日の指定日数が多いため、多くの興行が自動購入され、高額のチケット代金が請求される可能性があります。指定日数を減らしてみてはいかがでしょうか。」などのメッセージを作成する。

0029

ステップ1−7は、公演の指定曜日数を確認する処理である。サーバー1は、条件に含まれる指定曜日を取得し、これが1日以下である場合はステップ1−8に進み、5日以上の場合はステップ1−9に進む。また、指定曜日数が2日から4日以内であればステップ1−10に進む。

0030

ステップ1−8は、曜日拡大指示メッセージを作成するための処理である。条件となる曜日の数が余りに少ないと、検索条件に合致する興行が見つからないという不都合が生じる。よって、ここでは公演日の条件となる曜日を拡大するよう顧客に促すメッセージを作成するのである。サーバー1は、記憶装置11に予め記憶されている曜日拡大指示を、記憶装置11から取得し、曜日拡大指示メッセージを作成する。例えば「指定の曜日が少ないため、興行を検索できない可能性があります。指定の曜日数を拡大してみてはいかがでしょうか。」などのメッセージを作成する。

0031

ステップ1−9は、曜日絞込指示メッセージを作成するための処理である。条件となる曜日の数が余りに多いと、検索条件に合致する興行が数多く見つかることになる。本発明は、顧客の購入意思を確認することなくチケット代金の決済を行うものであるため、顧客が想像した以上のチケット代金の請求が顧客に対してなされるおそれがある。そこで、このような不都合を回避するため
公演日の条件となる曜日の数を絞り込むよう顧客に促すメッセージを作成するのである。サーバー1は、記憶装置11に予め記憶されている曜日絞込指示を、記憶装置11から取得し、曜日絞込指示メッセージを作成する。例えば「指定の曜日数が多いため、多くの興行が自動購入され、高額のチケット代金が請求される可能性があります。曜日数を減らしてしてみてはいかがでしょうか。」などのメッセージを作成する。

0032

ステップ1−10は、公演の開催地域(場所)を確認する処理である。サーバー1は、条件に含まれる開催地域を取得し、これが都道府県庁所在地を含まない場合はステップ1−11に進み、東京と大阪双方を含む場合はステップ1−12に進む。また、都道府県庁所在地を含む場合はステップ1−13に進む。

0033

ステップ1−11は、地域拡大指示メッセージを作成するための処理である。条件となる開催地域が県所在地を含まないと、検索条件に合致する興行が見つからない可能性がある。よって、ここでは公演日の条件となる開催地域を拡大するよう顧客に促すメッセージを作成するのである。サーバー1は、記憶装置11に予め記憶されている地域拡大指示を、記憶装置11から取得し、地域拡大指示メッセージを作成する。例えば「地域が狭いため、興行を検索できない可能性があります。開催地域を拡大してみてはいかがでしょうか。」などのメッセージを作成する。

0034

ステップ1−12は、地域絞込指示メッセージを作成するための処理である。条件となる地域に東京及び大阪の両大都市を含むと、検索条件に合致する興行が数多く見つかることになる。本発明は、顧客の購入意思を確認することなくチケット代金の決済を行うものであるため、顧客が想像した以上のチケット代金の請求が顧客に対してなされるおそれがある。そこで、このような不都合を回避するため地域を絞り込むよう顧客に促すメッセージを作成するのである。サーバー1は、記憶装置11に予め記憶されている地域絞込指示を、記憶装置11から取得し、地域絞込指示メッセージを作成する。例えば「東京と大阪双方を含むため、多くの興行が自動購入され、高額のチケット代金が請求される可能性があります。地域を更に限定してみてはいかがでしょうか。」などのメッセージを作成する。

0035

ステップ1−13は、アーティスト名入力の有無を確認する処理である。サーバー1は、条件を取得し、ここにアーティスト名の入力があるか否かを判断する。アーティスト名の入力がない場合はステップ1−14に進み、入力がある場合はステップ1−15に進む。

0036

ステップ1−14は、アーティスト名入力指示メッセージを作成するための処理である。アーティスト名が入力されていないと、検索条件に合致する興行が数多く見つかる可能性がある。本発明は、顧客の購入意思を確認することなくチケット代金の決済を行うものであるため、顧客が想像した以上のチケット代金の請求が顧客に対してなされるおそれがある。そこで、このような不都合を回避するためアーティスト名の入力を行って検索対象を絞り込むよう顧客に促すメッセージを作成するのである。サーバー1は、記憶装置11に予め記憶されているアーティスト名入力指示を、記憶装置11から取得し、アーティスト名入力指示メッセージを作成する。例えば「アーティスト名の入力がないため、多くの興行が自動購入され、高額のチケット代金が請求される可能性があります。アーティスト名を入力して検索対象を絞り込んでみてはいかがでしょうか。」などのメッセージを作成する。
なお、キャンセル回数が多いか否かを判断する回数を予め記憶装置11に記憶するとともに、サーバー1が図3のキャンセル回数を参照し、キャンセル回数が多い人に対し、何らかの条件を追加するような指示をしてもよい。

0037

ステップ1−15は上記ステップにて作成した指示メッセージを顧客端末2に送信するための処理である。サーバー1は、図3の顧客データから顧客のメールアドレスを取得し、これまでに作成した指示メッセージをそのメールアドレス宛に送信する。これにより顧客の検索条件を適切なものとすることができる。
なお、サーバー1は、顧客端末2から受信した検索条件(未確定の状態の検索条件)に基づいて図5の興行データベースを試験的に検索し、その試験的な検索結果を顧客端末2に送信してもよい。このようにすれば、顧客はその検索条件が適正なものであるか否かを判断することができる。

0038

ステップ1−16は条件確定のための処理である。サーバー1は、顧客端末2から条件を確定するか否かを示すデータを受信(取得)する。

0039

ステップ1−17は条件確定のための処理である。サーバー1は、ステップ1−16で取得したデータが条件の確定を示す場合は、ステップ1−18に進み、条件を確定せず再入力することを示す場合はステップ1−3に戻る。

0040

ステップ1−18は条件を記憶装置11に記憶するための処理である。サーバー1は、ステップ1−16で取得したデータを図4のように記憶装置11に記憶する。

0041

ステップ2は、ステップ1において確定した条件に合致した興行を検索するための処理である。サーバー1は、記憶装置11に記憶された条件データ(図4)を取得し、図5の興行データベースを検索し、条件に合致した興行を抽出する。なお、検索処理を行うタイミングは、予め記憶装置11に記憶されているものとする。このタイミングは任意であり、例えば、一週間に一度の何れかのタイミングでも良いし、毎日でも良いし、一時間毎であっても良い。

0042

サーバー1は、図4の条件データ「同一アーティストの連日購入の要否」の項目が「1回のみ購入」となっている場合、図5のアーティスト名及び公演日を参照して、同一アーティストの連日公演の検索・決済を行わないようにする。
また、サーバー1は、図4の条件データ「定期開催の場合の継続購入の要否」の項目が「1回のみ購入」となっている場合、図5の定期開催区分及び図3の購入履歴を参照して、定期開催の場合は継続して検索・決済を行わないようにする。
更に、サーバー1は、図5の公演日を参照して、同一公演日に行われる複数の公演を検索・決済しないようにしてもよい。例えば、アーティストFとアーティストGが同日に公演を開催する場合、どちらか一方のみを検索・決済し、他方の公演については検索・決済を行わないのである。同一の日に複数の公演を鑑賞するのは基本的に不可能であり、同一日に複数の公演を購入する人は不正転売目的の人であるおそれがある。よって、それを防止するためにこのような処理を行うのである。

0043

ステップ3は、ステップ2において抽出された興行チケットの決済を行うための処理である。サーバー1は、記憶装置11に記憶された顧客データ(図3)から顧客の決済情報(ここではクレジットカード番号)を取得し、抽出された興行チケットの決済処理を行う。なお、この決済処理は既知の処理であるためここでの説明は省略する。また、この決済処理は、検索条件に合致した商品があったことを通知する前に行われる。更に、興行チケット販売の場合、この決済処理は、興行チケットの数量が確定した後に行われる。興行チケットの場合、チケットの数量が確定しないと販売できないからである。

0044

ステップ4は、興行チケットの決済処理が完了したことを顧客に通知するための処理である。サーバー1は、記憶装置11に記憶された顧客データ(図3)から顧客のメールアドレスを取得する。サーバー1は、図7のようにチケットの購入手続(決済処理)が完了したこと等を顧客のメールアドレス宛に送信する。

0045

ステップ5は、決済済みの興行チケットのキャンセル処理を行う。記憶装置11には予めキャンセルを受け付ける期間が記憶されており、サーバー1は、この期間内に顧客端末2からキャンセル要求を受信した場合、これに基づいてキャンセル処理を行う。また、顧客に対しキャンセル料を請求するための情報を生成し、これを顧客端末2に送信する。
また、記憶装置11に予めキャンセル料の徴収を開始する開始回数を記憶しておき、サーバー1は図3のキャンセル回数が開始回数に達した場合にキャンセル料を請求するようにしてもよい。

0046

なお、サーバー1が、図3の購入履歴を参照し、公演日以降に同じ条件で検索・決済するか否かを問い合わせるための情報を作成し、それを顧客端末2に送信してもよい。また、興行チケット販売の場合、上記ステップ1からステップ5の処理を、チケットの一般販売よりも先行して行っても良い。このようにすれば一般販売時に販売サーバーへの処理の集中がなくなり、サーバーへの負担を軽減することができる。

0047

本発明の第2実施形態を図に基づいて説明する。
第1実施形態では、検索条件に合致したチケットがあった場合は無条件にそのチケットについて決済していた。本実施形態では、無条件に決済せず、顧客のために一旦チケットを購入する権利を確保し、チケットが検索されたことを顧客に通知し、顧客から入金があった場合や決済依頼があった場合にそのチケットについて決済を行うものである。

0048

図10は、本実施形態の機能構成図である。第1実施形態には「購入確認部23−2」と「購入依頼部31−2」は存在しないが、本実施形態ではこれらが存在する。
購入確認部23−2は、チケット検索部23から検索条件に合致したチケットを受信し、購入依頼部31−2に対しチケットの購入を行うか否かを確認する。また、購入確認部23−2から購入するか否かを区別する情報の入力を受け付け、それを決済部24に送信する。
購入依頼部31−2は、表示モニタ13にチケットの内容を表示し、購入するか否かを区別する情報の入力を受け付け、それを購入確認部23−2に送信する。

0049

図11は、本実施形態における、条件データの入力画面の表示例である。第1実施形態には、検索されたチケットの購入確認を行うか否かを区別するためのチェックボックスはないが、本実施形態にはこれが存在する。顧客は、購入確認を希望する場合は、このチェックボックスにチェックを入れて送信ボタンをクリックする。

0050

図12は記憶装置11に記憶されている条件データである。第1実施形態には「チケット購入確認の要否」のデータ項目がないが、本実施形態にはこれが存在する。図11のチェックボックスにチェックが入れられた場合、「要否=確認する」となり、チェックがない場合は「要否=確認しない(即時決済)」となる。

0051

図13は、本実施形態における、フローチャートである。第1実施形態には決済確認(S2.5)と購入要否確認(S2.6)は存在しないが、本実施形態ではこれが存在する。
ステップ2.5では、サーバー1は、検索条件に合致したチケットが存在した場合、顧客端末2に対して検索条件に合致したチケットが抽出されたこと、及びそれを購入するか否かを確認するデータを送信する。それを受信した顧客端末2はその内容を表示モニタ13に表示し、顧客は入力装置12から購入依頼または購入不要を示すデータを入力し、顧客端末2はそれをサーバー1に送信する。

0052

ステップ2.6では、顧客端末2から送信されたデータが、購入依頼(決済依頼)を示すか、購入不要を示すか判断する。購入依頼を示す場合はステップ3へ進み、購入不要を示す場合は処理を終了する。
このようにすることにより、顧客は検索された商品を即時購入するだけでなく、購入しないことも選択できるので、不要なチケットを購入してしまう不都合を回避できるのである。

0053

なお、この第一実施形態と第二実施形態とを組み合わせてもよい。例えば、「4人分の空席(4人分のチケットを購入すること)」が検索条件の場合、2人分を第1実施形態のように即時決済(購入者に購入意思を確認することなく決済すること)するようにし、残りの2人分を第二実施形態のようにチケットを購入する権利を確保するようにしてもよい。

0054

また、図13の検索処理(S2)において、検索条件に合致した興行チケットが検索できない場合、検索条件に近似した条件(例えば、検索条件から1個または2個減らしたもの)に合致したものを抽出し、これを確保し、顧客に通知してもよい。
更に、本実施形態では、記憶装置11に占有期間(未決済の状態のチケットを購入する権利が、その顧客のために確保されている期間)を記憶させ、サーバー1がこの占有期間内に「購入不要」の情報を顧客端末2から受信しなかった場合は、チケットの決済を行うようにしてもよい。また、占有期間内に「購入依頼」を受信しなかった場合は、チケットの決済を行わず、その興行チケットの占有解除するようにしてもよい。

0055

本実施形態では、特定の例に基づいて本発明の内容を説明したが、本発明はこれに限るものではない。

0056

この実施形態は本発明の範囲を限定するものではない。本実施形態で説明した各処理はどの装置で行ってもよい。例えば、1つの装置で行う処理を、複数の装置で行ってもよい。
また、本実施形態で説明したシステム構成(ハードウェア構成)は一例であり、用途や目的に応じて様々な構成があることは言うまでもない。
更に、本実施形態で説明したデータ構成は一例であり、用途や目的に応じて様々なデータ構成があることは言うまでもない。

0057

なお、上記の処理機能は、コンピュータによって実現することができる。その場合、本発明に係る装置が有すべき機能の処理内容記述した本発明に係るプログラムが提供される。そのプログラムをコンピュータで実行することにより、上記処理機能がコンピュータ上で実現される。処理内容を記述した本発明に係るプログラムは、コンピュータで読み取り可能な記録媒体に記録しておくことができる。コンピュータで読み取り可能な記録媒体としては、磁気記録装置光ディスク光磁気記録媒体半導体メモリなどがある。磁気記録装置には、HDDFD磁気テープなどがある。光ディスクには、DVD(Digital Versatile Disc)、DVD−RAM、CD−ROM、CD−R(Recordable)/RW(ReWritable)などがある。光磁気記録装置には、 MO(Magneto Optical disk)などがある。

0058

本発明に係るプログラムを流通させる場合には、たとえば、そのプログラムが記録されたDVD、CD−ROMなどの可搬型記録媒体が販売される。また、プログラムをサーバコンピュータの記憶装置に格納しておき、ネットワークを介して、サーバコンピュータから他のコンピュータにそのプログラムを転送することもできる。

0059

本発明に係るプログラムを実行するコンピュータは、たとえば、可搬型記録媒体に記録されたプログラムもしくはサーバコンピュータから転送されたプログラムを、自己の記憶装置に格納する。そして、コンピュータは、自己の記憶装置から本発明に係るプログラムを読み取り、そのプログラムに従った処理を実行する。
なお、コンピュータは、可搬型記録媒体からそのプログラムを読み取り、プログラムに従った処理を実行することもできる。また、コンピュータは、サーバコンピュータからプログラムが転送される毎に、逐次、受け取ったプログラムに従った処理を実行することもできる。

0060

なお、本発明は、上述の実施の形態にのみ限定されるものではなく、本発明の要旨を逸脱しない範囲内において種々の変更を加えることができる。

0061

上記については単に本発明の原理を示すものである。さらに、多数の変形、変更が当業者にとって可能であり、本発明は上記に示し、説明した正確な構成および 応用例に限定されるものではなく、対応するすべての変形例および均等物は、添付の請求項およびその均等物による本発明の範囲とみなされる。

0062

1サーバー
2顧客端末
10インターネット
11記憶装置
12入力装置
13 表示モニタ

ページトップへ

この技術を出願した法人

この技術を発明した人物

ページトップへ

関連する挑戦したい社会課題

関連する公募課題

ページトップへ

技術視点だけで見ていませんか?

この技術の活用可能性がある分野

分野別動向を把握したい方- 事業化視点で見る -

(分野番号表示ON)※整理標準化データをもとに当社作成

ページトップへ

おススメ サービス

おススメ astavisionコンテンツ

新着 最近 公開された関連が強い技術

  • グーグルエルエルシーの「 ビデオマッチングシステムのサービス品質向上のための画像マッチングシステムの使用」が 公開されました。( 2019/05/30)

    【課題・解決手段】システムは、対象のビデオを受信する。システムは、対象のビデオ内の動的セグメントと準静的セグメントとを識別する。システムは、対象のビデオの動的セグメントと参照ビデオの参照動的セグメント... 詳細

  • 尾和剛一の「 特許文献集合の分析方法」が 公開されました。( 2019/05/23)

    【課題】特定のコア技術や、特定の出願人の特定の分野の全特許文献集合の文献件数時系列動向とは異なる動向を示す文献項目を抽出する方法を提供する。【解決手段】特定文献集合分折方法は、特定の文献集合の特許文献... 詳細

  • 株式会社大塚商会の「 画像解析システム」が 公開されました。( 2019/05/23)

    【課題】 画像解析システムを提供することを目的とする。【解決手段】 画像解析システムであって,対象物と対象物関連情報とを対応づけて記憶する対象物情報記憶部と,第1の画像情報と,少なくとも一以上の第... 詳細

この 技術と関連性が強い人物

関連性が強い人物一覧

この 技術と関連する社会課題

関連する挑戦したい社会課題一覧

この 技術と関連する公募課題

関連する公募課題一覧

astavision 新着記事

サイト情報について

本サービスは、国が公開している情報(公開特許公報、特許整理標準化データ等)を元に構成されています。出典元のデータには一部間違いやノイズがあり、情報の正確さについては保証致しかねます。また一時的に、各データの収録範囲や更新周期によって、一部の情報が正しく表示されないことがございます。当サイトの情報を元にした諸問題、不利益等について当方は何ら責任を負いかねることを予めご承知おきのほど宜しくお願い申し上げます。

主たる情報の出典

特許情報…特許整理標準化データ(XML編)、公開特許公報、特許公報、審決公報、Patent Map Guidance System データ