JP6469352B2 - 商品販売装置、商品販売プログラム、商品販売方法 - Google Patents

Description

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

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

特開２００１−２９７２１４号

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

図８は本実施形態の処理手順を示すフローチャートである。このフローチャートは、条件登録（ＳＴＥＰ１）、検索処理（ＳＴＥＰ２）、決済処理（ＳＴＥＰ３）、購入通知（ＳＴＥＰ４）、キャンセル（ＳＴＥＰ５）とからなる。

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

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

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

ステップ１−４は、公演日の指定日数を確認する処理である。サーバー１は、条件に含まれる指定日数を取得し、これが２日以内である場合はステップ１−５に進み、３０日以上の場合はステップ１−６に進む。また、指定日数が３日から２９日以内であればステップ１−７に進む。

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

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

ステップ１−７は、公演の指定曜日数を確認する処理である。サーバー１は、条件に含まれる指定曜日を取得し、これが１日以下である場合はステップ１−８に進み、５日以上の場合はステップ１−９に進む。また、指定曜日数が２日から４日以内であればステップ１−１０に進む。

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

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

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

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

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

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

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

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

ステップ１−１６は条件確定のための処理である。サーバー１は、顧客端末２から条件を確定するか否かを示すデータを受信（取得）する。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

なお、上記の処理機能は、コンピュータによって実現することができる。その場合、本発明に係る装置が有すべき機能の処理内容を記述した本発明に係るプログラムが提供される。そのプログラムをコンピュータで実行することにより、上記処理機能がコンピュータ上で実現される。処理内容を記述した本発明に係るプログラムは、コンピュータで読み取り可能な記録媒体に記録しておくことができる。コンピュータで読み取り可能な記録媒体としては、磁気記録装置、光ディスク、光磁気記録媒体、半導体メモリなどがある。磁気記録装置には、ＨＤＤ、ＦＤ、磁気テープなどがある。光ディスクには、ＤＶＤ（Ｄｉｇｉｔａｌ Ｖｅｒｓａｔｉｌｅ Ｄｉｓｃ）、ＤＶＤ−ＲＡＭ、ＣＤ−ＲＯＭ、ＣＤ−Ｒ（Ｒｅｃｏｒｄａｂｌｅ）／ＲＷ（ＲｅＷｒｉｔａｂｌｅ）などがある。光磁気記録装置には、 ＭＯ（Ｍａｇｎｅｔｏ Ｏｐｔｉｃａｌ ｄｉｓｋ）などがある。

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

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

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

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

１ サーバー
２ 顧客端末
１０ インターネット
１１ 記憶装置
１２ 入力装置
１３ 表示モニタ

Claims (25)

1. 購入希望者が購入を希望する使用場所、使用時間、および販売数が限定された商品の決済処理を行う商品販売装置において、
   前記購入希望者から受信した商品の属性情報を、商品検索のための検索条件として記憶する検索条件記憶手段と、
   予め設定された検索のタイミングで、商品を特定するための商品特定情報とその商品の属性情報とが関連づけられている商品データベースを、前記検索条件に基づいて検索処理する検索手段と、
   商品代金の決済に関する前記購入希望者および商品を販売する販売者による事前承認と、商品の代金を決済するための決済情報に基づいて、前記検索処理により検索された商品の代金の決済処理を行う決済手段と、
   を備え、
   前記商品は興行チケットであり、
   前記決済手段は、同一公演者が連日公演を行う場合、１つの公演のみ決済処理することを特徴とする商品販売装置。
2. 購入希望者が購入を希望する使用場所、使用時間、および販売数が限定された商品の決済処理を行う商品販売装置において、
   前記購入希望者から受信した商品の属性情報を、商品検索のための検索条件として記憶する検索条件記憶手段と、
   予め設定された検索のタイミングで、商品を特定するための商品特定情報とその商品の属性情報とが関連づけられている商品データベースを、前記検索条件に基づいて検索処理する検索手段と、
   商品代金の決済に関する前記購入希望者および商品を販売する販売者による事前承認と、商品の代金を決済するための決済情報に基づいて、前記検索処理により検索された商品の代金の決済処理を行う決済手段と、
   を備え、
   前記商品は興行チケットであり、
   前記決済手段は、定期公演の場合、１つの公演のみ決済処理することを特徴とする商品販売装置。
3. 購入希望者が購入を希望する使用場所、使用時間、および販売数が限定された商品の決済処理を行う商品販売装置において、
   前記購入希望者から受信した商品の属性情報を、商品検索のための検索条件として記憶する検索条件記憶手段と、
   予め設定された検索のタイミングで、商品を特定するための商品特定情報とその商品の属性情報とが関連づけられている商品データベースを、前記検索条件に基づいて検索処理する検索手段と、
   商品代金の決済に関する前記購入希望者および商品を販売する販売者による事前承認と、商品の代金を決済するための決済情報に基づいて、前記検索処理により検索された商品の代金の決済処理を行う決済手段と、
   を備え、
   前記商品は興行チケットであり、
   前記決済手段は、同一公演日において１つの公演のみを決済処理することを特徴とする商品販売装置。
4. 購入希望者が購入を希望する使用場所、使用時間、および販売数が限定された商品の決済処理を行う商品販売装置において、
   前記購入希望者から受信した商品の属性情報を、商品検索のための検索条件として記憶する検索条件記憶手段と、
   予め設定された検索のタイミングで、商品を特定するための商品特定情報とその商品の属性情報とが関連づけられている商品データベースを、前記検索条件に基づいて検索処理する検索手段と、
   商品代金の決済に関する前記購入希望者および商品を販売する販売者による事前承認と、商品の代金を決済するための決済情報に基づいて、前記検索処理により検索された商品の代金の決済処理を行う決済手段と、
   前記検索条件の適正性を、商品購入者の購入履歴に基づいて判断する適正性判断手段と、
   を備えることを特徴とする商品販売装置。
5. 購入希望者が購入を希望する使用場所、使用時間、および販売数が限定された商品の決済処理を行う商品販売装置において、
   前記購入希望者から受信した商品の属性情報を、商品検索のための検索条件として記憶する検索条件記憶手段と、
   予め設定された検索のタイミングで、商品を特定するための商品特定情報とその商品の属性情報とが関連づけられている商品データベースを、前記検索条件に基づいて検索処理する検索手段と、
   商品代金の決済に関する前記購入希望者および商品を販売する販売者による事前承認と、商品の代金を決済するための決済情報に基づいて、前記検索処理により検索された商品の代金の決済処理を行う決済手段と、
   前記商品は興行チケットであり、公演終了後、再度その公演の興行チケット購入を行うか否かを確認する再購入確認手段と、
   を備える商品販売装置。
6. 購入希望者が購入を希望する使用場所、使用時間、および販売数が限定された商品の決済処理を行う商品販売装置において、
   前記購入希望者から受信した商品の属性情報を、商品検索のための検索条件として記憶する検索条件記憶手段と、
   予め設定された検索のタイミングで、商品を特定するための商品特定情報とその商品の属性情報とが関連づけられている商品データベースを、前記検索条件に基づいて検索処理する検索手段と、
   商品代金の決済に関する前記購入希望者および商品を販売する販売者による事前承認と、商品の代金を決済するための決済情報に基づいて、前記検索処理により検索された商品の代金の決済処理を行う決済手段と、
   を備え、
   前記決済手段は、
   前記検索処理により検索された商品の占有期間内に顧客から送信された決済依頼と、前記決済情報に基づいて、前記検索処理で検索された商品の決済を行い、
   前記検索手段は、
   前記検索条件に合致した商品が検索できない場合に、前記検索条件を絞り込んだ新たな検索条件で検索する、
   ことを特徴とする商品販売装置。
7. 購入希望者が購入を希望する使用場所、使用時間、および販売数が限定された商品の決済処理を行う商品販売装置において、
   前記購入希望者から受信した商品の属性情報を、商品検索のための検索条件として記憶する検索条件記憶手段と、
   予め設定された検索のタイミングで、商品を特定するための商品特定情報とその商品の属性情報とが関連づけられている商品データベースを、前記検索条件に基づいて検索処理する検索手段と、
   商品代金の決済に関する前記購入希望者および商品を販売する販売者による事前承認と、商品の代金を決済するための決済情報に基づいて、前記検索処理により検索された商品の代金の決済処理を行う決済手段と、
   を備え、
   前記決済手段は、
   前記検索処理により検索された商品の占有期間が経過した場合、前記決済情報に基づいて、前記検索処理で検索された商品の決済を行い、
   前記検索手段は、
   前記検索条件に合致した商品が検索できない場合に、前記検索条件を絞り込んだ新たな検索条件で検索する、
   ことを特徴とする商品販売装置。
8. 前記決済処理により決済された前記商品のキャンセル期間内に、顧客からキャンセル依頼があった場合、前記決済処理をキャンセルする決済キャンセル手段を備えることを特徴とする請求項１から請求項７までのいずれか１項に記載の商品販売装置。
9. 前記決済キャンセル手段は、キャンセルした顧客に対しキャンセル料を請求することを特徴とする請求項８記載の商品販売装置。
10. 前記決済キャンセル手段は、予め設定されたキャンセル回数を超えた場合にのみ前記キャンセル料を請求することを特徴とする請求項９記載の商品販売装置。
11. 前記検索手段は、未確定の状態の検索条件に基づいて、前記検索処理を行うことを特徴とする請求項１から請求項７までのいずれか１項に記載の商品販売装置。
12. 購入希望者が購入を希望する使用場所、使用時間、および販売数が限定された商品の決済処理を行うプログラムにおいて、
    コンピュータを、
    前記購入希望者から受信した商品の属性情報を、商品検索のための検索条件として記憶する検索条件記憶手段、
    予め設定された検索のタイミングで、商品を特定するための商品特定情報とその商品の属性情報とが関連づけられている商品データベースを、前記検索条件に基づいて検索処理する検索手段、
    商品代金の決済に関する前記購入希望者および商品を販売する販売者による事前承認と、商品の代金を決済するための決済情報に基づいて、前記検索処理により検索された商品の代金の決済処理を行う決済手段、
    として機能させ、
    前記商品は興行チケットであり、
    前記決済手段は、同一公演者が連日公演を行う場合、１つの公演のみ決済処理することを特徴とする商品販売プログラム。
13. 購入希望者が購入を希望する使用場所、使用時間、および販売数が限定された商品の決済処理を行うプログラムにおいて、
    コンピュータを、
    前記購入希望者から受信した商品の属性情報を、商品検索のための検索条件として記憶する検索条件記憶手段、
    予め設定された検索のタイミングで、商品を特定するための商品特定情報とその商品の属性情報とが関連づけられている商品データベースを、前記検索条件に基づいて検索処理する検索手段、
    商品代金の決済に関する前記購入希望者および商品を販売する販売者による事前承認と、商品の代金を決済するための決済情報に基づいて、前記検索処理により検索された商品の代金の決済処理を行う決済手段、
    として機能させ、
    前記商品は興行チケットであり、
    前記決済手段は、定期公演の場合、１つの公演のみ決済処理することを特徴とする商品販売プログラム。
14. 購入希望者が購入を希望する使用場所、使用時間、および販売数が限定された商品の決済処理を行うプログラムにおいて、
    コンピュータを、
    前記購入希望者から受信した商品の属性情報を、商品検索のための検索条件として記憶する検索条件記憶手段、
    予め設定された検索のタイミングで、商品を特定するための商品特定情報とその商品の属性情報とが関連づけられている商品データベースを、前記検索条件に基づいて検索処理する検索手段、
    商品代金の決済に関する前記購入希望者および商品を販売する販売者による事前承認と、商品の代金を決済するための決済情報に基づいて、前記検索処理により検索された商品の代金の決済処理を行う決済手段、
    として機能させ、
    前記商品は興行チケットであり、
    前記決済手段は、同一公演日において１つの公演のみを決済処理することを特徴とする商品販売プログラム。
15. 購入希望者が購入を希望する使用場所、使用時間、および販売数が限定された商品の決済処理を行うプログラムにおいて、
    コンピュータを、
    前記購入希望者から受信した商品の属性情報を、商品検索のための検索条件として記憶する検索条件記憶手段、
    予め設定された検索のタイミングで、商品を特定するための商品特定情報とその商品の属性情報とが関連づけられている商品データベースを、前記検索条件に基づいて検索処理する検索手段、
    商品代金の決済に関する前記購入希望者および商品を販売する販売者による事前承認と、商品の代金を決済するための決済情報に基づいて、前記検索処理により検索された商品の代金の決済処理を行う決済手段、
    前記検索条件の適正性を、商品購入者の購入履歴に基づいて判断する適正性判断手段、
    として機能させることを特徴とする商品販売プログラム。
16. 購入希望者が購入を希望する使用場所、使用時間、および販売数が限定された商品の決済処理を行うプログラムにおいて、
    コンピュータを、
    前記購入希望者から受信した商品の属性情報を、商品検索のための検索条件として記憶する検索条件記憶手段、
    予め設定された検索のタイミングで、商品を特定するための商品特定情報とその商品の属性情報とが関連づけられている商品データベースを、前記検索条件に基づいて検索処理する検索手段、
    商品代金の決済に関する前記購入希望者および商品を販売する販売者による事前承認と、商品の代金を決済するための決済情報に基づいて、前記検索処理により検索された商品の代金の決済処理を行う決済手段、
    前記商品は興行チケットであり、公演終了後、再度その公演の興行チケット購入を行うか否かを確認する再購入確認手段、
    として機能させることを特徴とする商品販売プログラム。
17. 購入希望者が購入を希望する使用場所、使用時間、および販売数が限定された商品の決済処理を行うプログラムにおいて、
    コンピュータを、
    前記購入希望者から受信した商品の属性情報を、商品検索のための検索条件として記憶する検索条件記憶手段、
    予め設定された検索のタイミングで、商品を特定するための商品特定情報とその商品の属性情報とが関連づけられている商品データベースを、前記検索条件に基づいて検索処理する検索手段、
    商品代金の決済に関する前記購入希望者および商品を販売する販売者による事前承認と、商品の代金を決済するための決済情報に基づいて、前記検索処理により検索された商品の代金の決済処理を行う決済手段、
    として機能させ、
    前記決済依頼は、
    前記検索処理により検索された商品の占有期間内に顧客から送信された決済依頼と、前記決済情報に基づいて、前記検索処理で検索された商品の決済を行い、
    前記検索手段は、
    前記検索条件に合致した商品が検索できない場合に、前記検索条件を絞り込んだ新たな検索条件で検索する、
    ことを特徴とする商品販売プログラム。
18. 購入希望者が購入を希望する使用場所、使用時間、および販売数が限定された商品の決済処理を行うプログラムにおいて、
    コンピュータを、
    前記購入希望者から受信した商品の属性情報を、商品検索のための検索条件として記憶する検索条件記憶手段、
    予め設定された検索のタイミングで、商品を特定するための商品特定情報とその商品の属性情報とが関連づけられている商品データベースを、前記検索条件に基づいて検索処理する検索手段、
    商品代金の決済に関する前記購入希望者および商品を販売する販売者による事前承認と、商品の代金を決済するための決済情報に基づいて、前記検索処理により検索された商品の代金の決済処理を行う決済手段、
    として機能させ、
    前記決済手段は、
    前記検索処理により検索された商品の占有期間が経過した場合、前記決済情報に基づいて、前記検索処理で検索された商品の決済を行い、
    前記検索手段は、
    前記検索条件に合致した商品が検索できない場合に、前記検索条件を絞り込んだ新たな検索条件で検索する、
    ことを特徴とする商品販売プログラム。
19. 購入希望者が、購入を希望する使用場所、使用時間、および販売数が限定された商品の決済処理を行う商品販売方法において、
    検索条件記憶手段が、前記購入希望者から受信した商品の属性情報を、商品検索のための検索条件として記憶するステップと、
    検索手段が、予め設定された検索のタイミングで、商品を特定するための商品特定情報とその商品の属性情報とが関連づけられている商品データベースを、前記検索条件に基づいて検索処理するステップと、
    決済手段が、商品代金の決済に関する前記購入希望者および商品を販売する販売者による事前承認と、商品の代金を決済するための決済情報に基づいて、前記検索処理により検索された商品の代金の決済処理を行うステップと、
    を有し、
    前記商品は興行チケットであり、
    前記決済手段は、同一公演者が連日公演を行う場合、１つの公演のみ決済処理することを特徴とする商品販売方法。
20. 購入希望者が、購入を希望する使用場所、使用時間、および販売数が限定された商品の決済処理を行う商品販売方法において、
    検索条件記憶手段が、前記購入希望者から受信した商品の属性情報を、商品検索のための検索条件として記憶するステップと、
    検索手段が、予め設定された検索のタイミングで、商品を特定するための商品特定情報とその商品の属性情報とが関連づけられている商品データベースを、前記検索条件に基づいて検索処理するステップと、
    決済手段が、商品代金の決済に関する前記購入希望者および商品を販売する販売者による事前承認と、商品の代金を決済するための決済情報に基づいて、前記検索処理により検索された商品の代金の決済処理を行うステップと、
    を有し、
    前記商品は興行チケットであり、
    前記決済手段は、定期公演の場合、１つの公演のみ決済処理することを特徴とする商品販売方法。
21. 購入希望者が、購入を希望する使用場所、使用時間、および販売数が限定された商品の決済処理を行う商品販売方法において、
    検索条件記憶手段が、前記購入希望者から受信した商品の属性情報を、商品検索のための検索条件として記憶するステップと、
    検索手段が、予め設定された検索のタイミングで、商品を特定するための商品特定情報とその商品の属性情報とが関連づけられている商品データベースを、前記検索条件に基づいて検索処理するステップと、
    決済手段が、商品代金の決済に関する前記購入希望者および商品を販売する販売者による事前承認と、商品の代金を決済するための決済情報に基づいて、前記検索処理により検索された商品の代金の決済処理を行うステップと、
    を有し、
    前記商品は興行チケットであり、
    前記決済手段は、同一公演日において１つの公演のみを決済処理することを特徴とする商品販売方法。
22. 購入希望者が、購入を希望する使用場所、使用時間、および販売数が限定された商品の決済処理を行う商品販売方法において、
    検索条件記憶手段が、前記購入希望者から受信した商品の属性情報を、商品検索のための検索条件として記憶するステップと、
    検索手段が、予め設定された検索のタイミングで、商品を特定するための商品特定情報とその商品の属性情報とが関連づけられている商品データベースを、前記検索条件に基づいて検索処理するステップと、
    決済手段が、商品代金の決済に関する前記購入希望者および商品を販売する販売者による事前承認と、商品の代金を決済するための決済情報に基づいて、前記検索処理により検索された商品の代金の決済処理を行うステップと、
    適正性判断手段が、前記検索条件の適正性を、商品購入者の購入履歴に基づいて判断するステップと、
    を有することを特徴とする商品販売方法。
23. 購入希望者が、購入を希望する使用場所、使用時間、および販売数が限定された商品の決済処理を行う商品販売方法において、
    検索条件記憶手段が、前記購入希望者から受信した商品の属性情報を、商品検索のための検索条件として記憶するステップと、
    検索手段が、予め設定された検索のタイミングで、商品を特定するための商品特定情報とその商品の属性情報とが関連づけられている商品データベースを、前記検索条件に基づいて検索処理するステップと、
    決済手段が、商品代金の決済に関する前記購入希望者および商品を販売する販売者による事前承認と、商品の代金を決済するための決済情報に基づいて、前記検索処理により検索された商品の代金の決済処理を行うステップと、
    前記商品は興行チケットであり、再購入確認手段が、公演終了後、再度その公演の興行チケット購入を行うか否かを確認するステップと、
    を有することを特徴とする商品販売方法。
24. 購入希望者が、購入を希望する使用場所、使用時間、および販売数が限定された商品の決済処理を行う商品販売方法において、
    検索条件記憶手段が、前記購入希望者から受信した商品の属性情報を、商品検索のための検索条件として記憶するステップと、
    検索手段が、予め設定された検索のタイミングで、商品を特定するための商品特定情報とその商品の属性情報とが関連づけられている商品データベースを、前記検索条件に基づいて検索処理するステップと、
    決済手段が、商品代金の決済に関する前記購入希望者および商品を販売する販売者による事前承認と、商品の代金を決済するための決済情報に基づいて、前記検索処理により検索された商品の代金の決済処理を行うステップと、
    を有し、
    前記決済依頼は、
    前記検索処理により検索された商品の占有期間内に顧客から送信された決済依頼と、前記決済情報に基づいて、前記検索処理で検索された商品の決済を行い、
    前記検索手段は、
    前記検索条件に合致した商品が検索できない場合に、前記検索条件を絞り込んだ新たな検索条件で検索する、
    ことを特徴とする商品販売方法。
25. 購入希望者が、購入を希望する使用場所、使用時間、および販売数が限定された商品の決済処理を行う商品販売方法において、
    検索条件記憶手段が、前記購入希望者から受信した商品の属性情報を、商品検索のための検索条件として記憶するステップと、
    検索手段が、予め設定された検索のタイミングで、商品を特定するための商品特定情報とその商品の属性情報とが関連づけられている商品データベースを、前記検索条件に基づいて検索処理するステップと、
    決済手段が、商品代金の決済に関する前記購入希望者および商品を販売する販売者による事前承認と、商品の代金を決済するための決済情報に基づいて、前記検索処理により検索された商品の代金の決済処理を行うステップと、
    を有し、
    前記決済手段は、
    前記検索処理により検索された商品の占有期間が経過した場合、前記決済情報に基づいて、前記検索処理で検索された商品の決済を行い、
    前記検索手段は、
    前記検索条件に合致した商品が検索できない場合に、前記検索条件を絞り込んだ新たな検索条件で検索する、
    ことを特徴とする商品販売方法。

Images