以下、本発明の実施形態について説明する。本発明の実施形態のシステム構成図を図1に示す。図1において、インターネット1にはWWWサーバー3、ユーザ5のパソコン及び商店等7のパソコンが接続されている。但し、パソコンに限定するものではなく、携帯電話や移動携帯端末等でも同様である。商店等7は、商品を販売するデパート、スーパー、通信販売の店等の他、産地直送店や農家、製造メーカー、問屋等であってもよい。また、病院、介護、ビジネス、流通、その他のサービス業も含む。WWWサーバー3の運営するホームページにはソフトウェア9のダウンロード可能なページがあり、商店等7はソフトウェア9をダウンロードする。また、ソフトウェア9はCD−ROMの形でも提供される。ソフトウェア9は、商店等7が自己のホームページを作成し、完成したホームページをWWWサーバー3に登録申請等するために利用される。また、WWWサーバー3より必要なデータを入手可能なようになっている。
ソフトウェア9がダウンロードされたパソコンにはスタートメニューやデスクトップに起動用アイコンが登録されるようになっている。起動用アイコンを起動した場合には、例えば図2に示すような商品等の分類項目を示す画面がパソコン画面に表示される。商店等7はこの分類項目の中から自店で販売やサービス等を行っている項目の内特売、販売したい項目や提供するサービス等を選択する。
図2において、仮に食品を選択した場合には、食品の下位概念として続いて図3の各項目及びデータ入力欄10が表示される。商店等7で例えばさくらんぼxgをy1円で販売若しくは特売したい場合には、果物の項目を選択した後、データ入力欄10の内の品名欄11をまずクリックする。このとき、図4に示すような文字、数字、記号等入力補助ツール20が表示される。文字、数字、記号等入力補助ツール20は、それぞれ文字ボタン14A、記号等ボタン14B、数字ボタン14Cをクリックすることで独立して表示、消去させることが可能である。なお、この文字入力補助ツール20A、記号等入力補助ツール20B、数字入力補助ツール20Cを一括してタブ選択とし、文字ボタン14A、記号等ボタン14B、数字ボタン14Cを一つにまとめるようにしてもよい。この場合にはスペースを省略できる。
そして、品名欄11の下部には「頭文字を選択して下さい」の指示が出される。文字入力補助ツール20Aのひらがなキー37を選択し「さ」をクリックすると「さくらんぼ」とひらがな表示される。複数の商品名候補が存在する場合には、候補表示がされ、いずれか一つを選択するようにメッセージ表示される。
次に、単位欄13において、ドロップダウンリストボックスから例えば「グラム」単位を選択する。価格欄15には、図4の数字入力補助ツール20Cをクリックすることで入力する。価格欄15には、希望販売価格を入力するが、他に定価をも入力するのが望ましい。メッセージ欄17には、商店等7がこの商品に関し、例えば糖度や産地、生産者、3割引等を宣伝可能である。漢字入力したい場合には、例えば、漢字指定範囲の先頭までカーソルを持っていき、漢字変換21をクリックすれば市販の文字入力ソフト等と連携され、漢字候補が表示され、その候補の中から選択可能である。また、メッセージ欄17はコンボボックスとし、当該分野において使用が想定される標準的なメッセージが予め用意され選択可能とされている。この場合、メッセージは英文にも対照されている。また、メッセージ欄17を音声再生スイッチに変え、音声保存されたデータを再生し、宣伝に供するようにしてもよい。保存される音声は予め標準で用意された音声ファイル中から選択してもよいし、商店等7が独自に音声入力したものでもよい。当該商品等をインターネット上で販売をするのか、あるいは単に宣伝のみを行うのかをネット販売実施可否欄8にて選択する。
ネット販売実施可否欄8で販売を行う旨の選択がされている場合には、次の値引き交渉欄19、底値記入欄23が入力可能となる。ユーザ5に対し値引き交渉に応ずることが可能ならば値引き交渉欄19において、値引き交渉「可」を選択し、底値記入欄23に底値y2円を、図4の数字入力補助ツールをクリックすることで入力する。底値は、商店等7が値引き交渉に応じた場合に、これ以上の値引きには応じられない限界である最低価格値である。但し、この底値記入欄23は、通常価格、お得意様限定価格、上得意様限定価格と分け、ユーザ5の今までの購入頻度や購入金額の合計等に応じて複数段階に底値を下げるようにしてもよい。なお、底値記入欄23はユーザ5に対しては開示されない。また、図示していないが、各商品について配達が可能であるか否かを選択可能とするチェックボックスを設けてもよい。更に、配達の可能な場合には、配達の可能な地域である「近郊」、「市内」、「県内」、「全国」、「指定距離以内」等を選択可能とするチェックボックスを設けるのが望ましい。
品名、単位、価格、ネット販売実施可否、値引き交渉の可、不可、可の場合には底値が最低限記入されたとき、データ入力欄10の下段には次のデータ入力欄が追加表示される。なお、商店等7が例えば野菜も特売したい場合には、野菜をクリックした後同様の処理を繰り返す。特売品等が食品の他に家電等複数分類にまたがる場合には、1項目についてのデータ入力が完了した後、再び図2の分類項目に戻って続けて2項目を操作する。
画像欄25に商品等の画像を取り込みたい場合には、画像欄25をクリックするとウィザァードが自動的に立ち上がり、画像ファイルの存在するドライブ、ディレクトリ等を指定するように要求がされる。そして、サムネイル表示されたファイルの中から適当な画像を選択する。画像は写真や絵等であり、予め標準的なものが用意されている。品名欄11で品名が選択されている場合には、この品名に基づき絞り込まれた画像が自動的に抽出され、サムネイル表示される。
但し、商店等7にて独自に画像を作成することも可能である。この場合、スキャナで読み込まれた画像や、ディジタルカメラにて撮像された画像はプレビューウィンドウの枠中に全体表示される。そして、全体画像の中から取り込みたい範囲を取り込み枠にて囲む。この際には、取り込み枠をマウスでドラッグや移動操作をして範囲調整する。但し、全体画像をそのまま使用したい等の場合には範囲調整しなくても構わない。確認ボタンをクリックすると、範囲選択された画像のサイズが抽出され、画像欄25のサイズに自動調整された後、その画像が画像欄25に張り付けられる。
なお、商店等7が独自に画像を作成する場合には、背景を削除する等の画像編集もソフトウェア9にて可能である。但し、かかる画像編集をWWWサーバー3側にて行うように依頼することも可能である。このため、各画像欄25にそれぞれ対応されて又は全画像を一括して編集依頼する図示しない画像編集依頼ボタンを配設してもよい。WWWサーバー3側では、依頼された画像を抽出し、背景を削除したり、トリミングを施したりする。
しかしながら、画像の必要ない場合には画像欄25を操作する必要はない。また、画像欄25には、商品の様子がより判断し易いように動画を取り込めるようにしてもよい。更に、画像欄25にはURL(Uniform Resource Locator)を配し、各商店等7が例えばこの商品の拡大画像も含め、この商品に関する詳細な情報等を独自に用意したホームページの形で提供できるようにリンクが可能である。
サービス内容欄26はコンボボックスとし、例えば日替わりセール、タイムサービス、朝市、夕市、通常販売、空白等のサービス種類を選択可能である。そして、日替わりセールの場合には日を、タイムサービスの場合には時間を日・時設定欄28に設定する。サービス内容欄26で朝市、夕市が選択された場合は、日・時設定欄28は日入力欄と時間入力欄とに分かれて表示される。日入力欄をクリックすると図5に示すカレンダー30が表示されるので、カレンダー30より日を選択し入力する。そして、時間入力欄に時間を記入等する。
データ入力欄10に入力された項目は種類毎に並べ替えが可能であり、各項目毎にも移動ボタン16により順番を変更可能である。削除ボタン18により項目の削除も可能である。
次に、ボタン27で次画面である図5に進む。図5では特売を行う商店等7では、特売日をカレンダー30上で選択する。カレンダー30は、パソコン内蔵の時計機能により自動更新される。まず、「特売日の開始日はいつですか。」のメッセージを表示して特売日の開始日を選択させる。続いて「特売日の終了日はいつですか。」のメッセージを表示して特売日の終了日を選択させる。商店等7は、特売期間欄29により特売の期間を確認する。勿論、特売期間欄29に直接キー入力等してもよい。特売の目的である例えば開店セール、記念セール、通常販売、毎週木曜日等を特売目的欄31のコンボボックスから選択する。特売目的欄31や特売期間欄29も英文対照されている。メッセージ33にはその他の自由記載が可能である。また、音声保存されたデータを再生し、宣伝に供するようにしてもよい。保存される音声は予め標準で用意された音声ファイル中から選択してもよいし、商店等7が独自に音声入力したものでもよい。
商店等7がWWWサーバー3に対し登録されていない場合には、登録申請のための事項の記入が要求される。商店等名欄35をクリックすれば、文字、数字、記号等入力補助ツール20が表示されるので、例えばひらがなキー37を選択し、文字入力補助ツールにより「とくばいせんもんてん」と記入する。この際には、漢字変換したい先頭にカーソルを移動し、漢字変換21をクリックすれば「特売専門商店」と入力可能である。このような手順をメッセージによりガイドするのが望ましい。
このようにすることで、キー操作に不慣れな人でも簡単に文字入力可能となる。郵便番号入力欄39には郵便番号を記載する。この郵便番号に割り付けられた住所地が住所欄に自動入力される。住所地は英文対照されている。そして、その後に文字、数字、記号等入力補助ツール20により地番等を記入する。電子メール欄41には、電子メール欄41をクリックした後、文字、数字、記号等入力補助ツール20により、小文字キー43を選択して入力可能である。但し、電子メール欄41が選択された場合には、記号等入力補助ツール20B以外は表示されないようにしてもよい。また、大文字で入力された場合でも確定時に小文字に自動変換するようにしてもよい。業種欄38はコンボボックスによりデパート、スーパー、八百屋、病院、税理士、不動産等選択可能なようになっている。
確認ボタン45をクリックすると、以上に入力若しくは選択されたすべての項目がホームページ形式でリスト表示される。ホームページは壁紙等すべてが定型化された形式で統一されている。この際、バナナのように候補選択等された文字は自動的に英文字Bananaにも対照されており、英語表示ボタン44をクリックすることで、英文記載のホームページも同時に作成される。従って、文字入力欄等にキーボードから文字入力することは可能であるが、この場合には英文対照されない。このため、必要ならば英文字を直接入力する。
商店等7ではこのホームページの記載事項等を確認後、OKであれば送信ボタン47をクリックして送信する。送信先は、ソフトウェア9によりWWWサーバー3のURLに指定されている。WWWサーバー3に送信されたホームページは受信後、所定の調査が行われた後にインターネット上で公開されることとなる。この交信の際には、WWWサーバー3は商店名等を顧客データベースに登録し、顧客IDを発行し、この顧客IDを商店等7のパソコンの特定のファイルに保存する。そして、登録完了の旨の通知を商店等7に対し送信する。
なお、ソフトウェア9は商品等の全分類項目をまとめて一つのソフトウェアとして説明したが、商店等7が小規模で販売品目等が限定されている場合を考え、商品等の分類項目毎にソフトウェア9を分離し、ダウンロードやCD−ROM提供可能としてもよい。この場合には機能が限定されている分使い易く、ダウンロード時間も短く処理速度も向上する。
なお、図3及び図5は、例えば商店を対象とした一例であり、選択された分類等に従い、その分類にふさわしい表示項目、入力欄、データ等が予め用意され、ソフトウェア9に保存されている。
商品を対象とせずにサービスを提供する場合の一例を図6に示す。図6には病院の例を示す。診療科目欄111には内科、外科等をコンボボックスより選択し、担当医師名欄113を記入する。当該医師の担当曜日は月〜日曜日の内から選択される。今月の休診日115は図5のカレンダー30より選択される。住所地は、郵便番号を入力した後、地番を入力する。駅欄117は最寄りの駅を入力する。
このように、ソフトウェア9では、各分類毎に定型化された共通の基本となるホームページを予め用意し、入力すべきデータをも予め扱われる品目等毎に各商店等7に対応したものを用意する。そして、このデータは、クリック操作により選択可能としたことで、キーボード操作が不慣れで、かつホームページの知識のない人でも簡単にホームページを作成可能である。また、このようにデータも予め用意したので、日本語に対照した英文ホームページも同時に完成する。更に、形式や項目等の統一により、検索される際には余計なノイズが無くなり、検索精度が向上する。また、WWWサーバー3側にて種々のデータ処理を行う場合には、その処理が簡単に行える。
なお、ホームページの知識を有する人のために、設定により壁紙等の選択を可能とするようにしてもよい。また、ホームページはソフトウェア9により作成されたものではなく、商店等7が別に独自に作成したものをWWWサーバー3にリンクさせることも可能である。
また、ソフトウェア9には過去のデータを履歴として保存可能とし、カレンダー30で選択された日の情報を参照できるようにしてもよい。
更に、ソフトウェア9には商店等7が販売や宣伝をしたい画像や項目、特売情報、商店等7の情報等が既に揃っているので、この画像や項目等を利用してカタログや新聞の折り込みチラシ、店頭掲示用チラシ、葉書広告等を作成させる機能を付加させることが可能である。まず、印刷される対象の用紙を選択すると、この用紙のサイズに合った形のひな型が複数個表示される。商店等7はこのひな型を参照し、ひな型の中から好みのものを一つ選択する。ひな型には予めどの位置に値段が表示され、どの位置に画像が配設されるか、その他背景や模様、レイアウト等が決められている。
なお、用紙単位にひな型を用意するのではなく、各商品欄単位毎に独立させて、あるいは商店等表示欄に対しひな型を用意するようにしてもよい。この商品欄単位には、画像欄、商品名欄、個数欄、価格欄、メッセージ欄等が属し、商店等表示欄には、商店等の名称、支店、営業時間、電話番号等が属する。それぞれの欄には、複数のひな型から自由に選択可能とするのが望ましい。また、画像欄、商品名欄、個数欄、価格欄、メッセージ欄等を各商品欄単位毎に自由にレイアウト可能としてもよい。
例えば、画面に表示された用紙の中の適当な位置に、まず商品欄単位が置かれる範囲(以下、商品欄範囲という)や商店等表示欄を選択する。このとき、この商品欄範囲の中には画像欄、商品名欄、個数欄、価格欄、メッセージ欄等が標準的な大きさ、位置で表示される。商品欄範囲を拡大、縮小、移動すれば画像欄、商品名欄等もこの商品欄範囲に従い拡大等される。画像欄、商品名欄等はその属する商品欄範囲内で移動可能であり、削除、コピーや拡大縮小も可能である。そして、商品欄単位は、分類毎整理のボタンをクリックすることで、サービス目的である本日限り、朝市等の各分類毎に整理し、ブロック分けすることも可能である。
更に、商品欄範囲には、写真欄、図形欄、背景、模様、宣伝文入力欄等様々な部品を挿入若しくは重ね合わせ等可能なように選択可能に用意してもよい。また、大きさも可変可能としてもよい。宣伝文入力欄には様々な宣伝文が記入可能である。各商品欄単位には番号が割り付けられ、図3の各項目をこの番号に対応させることで自動的に画像欄、商品名欄等が読み込まれ折り込みチラシ等のレイアウトが完成する。
なお、このように番号に対応させる方法ではなく、まずすべての図3の各項目を選択された所定の用紙サイズに合わせてサービス目的毎に標準的配列に従い割り付け、その後に商店等7により削除、移動、拡大縮小、内容の修正等が行われるようにしてもよい。この際には、自動調整ボタンを設け、削除等のされた後に自動的に空欄等を埋める形で大きさや位置を調整可能なようにするのが望ましい。文字や数字の書体等もひな型の中から選択する。各項目毎に書体を変えることも可能である。
写真欄や図形欄が挿入されている場合には、この写真欄や図形欄をクリックした後、フォルダ、ファイルを選択する。ファイルはサムネイル表示されるのが望ましい。カラーを選択して所定の用紙にプリンターで印刷することで簡単に折り込みチラシ等を作成可能である。更に、完成したチラシ等はホームページ形式とした後、WWWサーバー3にアップロード可能である。
次に、ホームページ掲載に要する料金体系を定める一方法について説明する。 商店等7により作成されたホームページは次のように価格に反映される。図7のフローチャートに示すように、ステップ1(図中S1と略す。以下同旨)で確認ボタン45がクリックされると、ステップ3でソフトウェア9は、作成されたホームページの合計データサイズが何〔KB〕かを検出する。英文の存在する場合には英文ホームページもデータサイズが合計される。ステップ5でデータサイズがa1〔KB〕以下のとき、ステップ7で「ホームページ掲載の基本料金はM1円です。」と表示する。M1円には、例えば無料の場合も含む。ステップ9でデータサイズがa1〔KB〕を超えてa2〔KB〕以下のとき、ステップ11で「ホームページ掲載の基本料金はM2円です。」と表示する。
そして、ステップ13では「終了してよいですか?」との問い合わせが表示される。よい場合には「はい」ボタンをクリックしステップ15で終了する。高いと感じた場合や更に多くの項目を追加したい場合には「いいえ」ボタンをクリックしステップ17に進む。ステップ17では、「商品項目や画像を追加・削除して下さい」の問い合わせが行われる。現状でよければステップ15で終了し、商品項目、画像を追加や削除したい場合にはステップ19に進み不要箇所の削除等を行う。そして、再びステップ1から同様の処理を繰り返す。
このように、ホームページ掲載の基本料金を無料若しくは所定の最低金額を基礎とし、その後はホームページの合計データサイズに応じて連続的又は段階的に料金を上げることが可能となる。また、商店等7ではホームページ作成時点でホームページ掲載の基本料金を確認でき、掲載の効率を考慮することができる。
以上は、データサイズによりホームページ掲載の基本料金を定めるとして説明したが、この値段で月当たりの掲載料金を固定とすることも可能である。
次に、各商店等7で作成されたホームページにはそれぞれに図示しないカウンタを設ける。そして、ホームページにユーザからアクセスのあった都度カウンタ値をインクリメントさせる。そして、このカウンタ値に応じて料金体系を定める。これに先立ち、各商店等7には、登録申請時に図8に示すようにいずれかの料金体系を選択させる。標準としては項目1の「月当たりN1回までP1円で、N1回を超えるとホームページの閲覧が制限(若しくは閲覧不可)される。」が選択されている。この項目1が選択されている場合、月当たりカウンタ値がN1回まで掲載料はP1円で、カウンタ値がN1回を超えるとホームページの閲覧が制限等される。
P1円は例えば図7でホームページ掲載の基本料金として算出したM1、M2・・円である。他に、項目2「月当たりN2回までP2円、N2回を超えるとホームページの閲覧が制限等される。」、項目3「月当たりN3回までP3円、N3回を超えるとホームページの閲覧が制限等される。」が選択可能である。ホームページの閲覧制限は、例えば商店等名や住所等の一部の項目を除き表示せず、検索も商店等名以外できなくするものである。また、項目4では、各カウンタ値の段階に応じて値段を異ならせ、カウンタ値が大きくなる程重み付けを低くする。更に、項目5では、月当たりの定額を選択可能である。
図9のフローチャートに基づき詳細を説明する。まず、ステップ21で例えば毎日定期的にソフトが起動される。ステップ23で、顧客データベースに登録されている例えば登録番号がC番めの商店等7のホームページが選択される。ステップ25でそのホームページへのアクセス数であるカウンタの積算数を読む。ステップ27で、カウンタ値がN1回を超えているときステップ29に進み、登録申請時に図8で、項目1の「月当たりN1回までP1円で、N1回を超えるとホームページの閲覧が制限等される。」が選択されている場合には、ステップ31において、ホームページ上の商店等7の機能を制限する。そして、ステップ32に進みカウンタ値をゼロとし、ステップ33で商店等7の登録申請日に相当する翌月まで休止扱いとする。
ステップ27でカウンタ値がN1回を超えていないとき、ステップ34で登録番号C+1番にインクリメントされ、ステップ25でC+1番目の商店等7のカウンタ数が読まれる。ステップ29で項目1が選択されていない場合には、ステップ35でカウンタ値がN2回を超えているときステップ36に進み、登録申請時に図8で、項目2の「月当たりN2回までP2円で、N2回を超えるとホームページの閲覧が制限等される。」が選択されている場合には、ステップ31〜ステップ33の処理を行う。ステップ35でカウンタ値がN2回を超えていないとき、ステップ37で登録番号C+1番にインクリメントされ、ステップ25でC+1番目の商店等7のカウンタ数が読まれる。以下同様である。
以上により、商店等7のカウンタ数が予め定めた所定値以上になったときには当該商店等7のホームページ上の機能を制限可能である。従って、利用料金に応じたホームページ掲載サービスが提供可能であり、低価格のサービスを実現できる。また、機能制限されたホームページ部分や画像等を一旦記憶部分から他の記憶部に移動したり、削除等すればデータベース等の負担が軽くなる。
次に、図8の項目4に関し、月末の請求方法を図10のフローチャートに基づき説明する。図10に示すように、ステップ41で月末の請求書作成のための起動がされる。ステップ43で登録番号順に顧客データベースにアクセスする。但し、商店等7毎に登録申請日を基準に月末処理が行われるような場合には、月末に相当する商店等7をまず検索する。そして、ステップ45でカウンタ値を読む。ステップ47でカウンタ値がN1以下のとき、ステップ49でその商店等7の当月の請求額はQ1円となる。Q1円は、例えば図7でホームページ掲載の基本料金として算出したM1、M2・・円である。
ステップ51でカウンタ値がN2以下のとき、ステップ53でその商店等7の当月の請求額はQ1+Q2円となる。ステップ55でカウンタ値がN3以下のとき、ステップ57でその商店等7の当月の請求額はQ1+Q2+Q3円となる。ステップ55でカウンタ値がN3を超えているとき、当月の請求額はステップ59でQ4円となる。そして、請求額の計算が終わった場合にはステップ61で登録番号C+1番にインクリメントされ、ステップ43より同様の処理を繰り返す。
以上により、ホームページの閲覧された度合いが少ない場合には低額若しくは無料とし、その後ホームページが閲覧された度合いに応じて料金請求がされるため、費用体系が合理的であり、商店等7は安心し、かつ気軽にホームページを掲載できる。
次に、商店等7が自分のホームページにアクセスした場合や、心ないユーザ5によりホームページが無用の頻繁なアクセスをされた場合の対処について説明する。
商店等7より自己のホームページにアクセスをする場合には、ソフトウェア9の図示しないホームページ確認ボタンにより行う。この際には顧客IDが商店等7のパソコンの特定ファイルより検出されると共に、自己のアクセスとしてカウントされない。但し、積算値がデクリメントされるか、図9のステップ25又は図10のステップ45のカウンタ値を読む際等に自己のアクセス分をまとめて積算値から減算するようにしてもよい。自己のアクセス分は、ソフトウェア9側で計測しCookie等に保存され交信の際に読み込まれてもよいし、WWWサーバー3側で顧客ID単位に計測されてもよい。また、登録申請の交信時にCookie等にも顧客IDを記録した場合には、ソフトウェア9の起動等にかかわらず、WWWサーバー3により顧客IDが検出され、検出された顧客IDが顧客データベースの内容と一致した場合には自己のアクセスとしてカウントされない。
ユーザ5がホームページにアクセスした場合、送信された交信メッセージにユーザIDが存在しない場合には、ユーザIDを発行し、Cookie等に記録する。以降の交信メッセージにはユーザIDが含まれるので、このユーザIDを検出することで、商店等7と異なることを検出可能である。また、ユーザ5がホームページにアクセスした際に簡単な仮登録申請をさせ、ユーザID等を発行し、以降このユーザIDを使用に際し記入させるようにしてもよい。更に、住所、氏名、電話番号等正式に会員登録を済ませたユーザ5のみに商店等7のホームページを利用可能としてもよい。この場合には、例えばユーザID、暗証番号等の入力を要求し、会員であることを確認した後ホームページを利用可能とする。会員でない場合には登録申請画面を表示する。
図11には、当月度データベースの内容を示す。当月度データベース50には、各顧客IDのホームページに対し、各ユーザが当月内に何回アクセスしたかをテーブル作成したものである。当月の開始日、終了日はすべてを統一させることも可能であるが、当月度データベース50では登録申請日を月の開始日としている。このようにすることで、図8の項目1〜3に示すカウント数の上限を設定したアクセスされない商店等7の数が特定の期間に集中するのを防止できる。
当月度データベース50のカウント数の積算において、例えばユーザID1の人は、顧客ID1のホームページに30回、ユーザID4の人は、顧客ID1のホームページに4回アクセスしているが、無用にアクセスされた場合を考慮し、例えば3回以上同一人からのアクセスがあった場合でも3回以上はカウントしないこととする。このため、顧客ID1のカウント数の積算は、3+1+2+3=9のようになる。ユーザID5の人は、3+3+3+2=11で、図8のN1=10としたときには、本日以降ホームページの閲覧は機能制限等される。
本日が月の終了日9日の場合には、顧客ID1、顧客ID4はカウント数の積算を行ったのち、図10等により請求書を発行する。その後、顧客ID1、顧客ID4の各ユーザのカウント数をゼロにする。なお、カウント数の積算は、別途各顧客ID毎に累積され、履歴や、ホームページの人気度ランキング等に利用される。
次に、図12にWWWサーバー3によるホームページのメイン画面例を示す。メイン画面からは各種検索が可能である。地域選択のための地図キー51をクリックすると日本地図が表示される。その後、更に例えば東京都、中央区、銀座と順次希望の地域を絞り込みクリックする。このとき、図13に示す銀座付近の地図と共に、各商店等7の店名及び業種が表示される。商店等7をクリックすることで各店のホームページに進む。
地区名入力欄53は上位概念から下位概念へと選択可能なドロップダウンリストボックスであり、例えば東京都に続き中央区、続いて銀座とツリー化されて選択可能である。続いて、地図表示ボタン56をクリックすると図13に示す地図形式の表示画面が表示され、一覧表示ボタン57をクリックすると図14に示す一覧形式の表示画面が表示される。駅名入力欄55には、路線名及び駅名を選択することで当該駅の周辺地区を開くことができる。
この際、一覧表示ボタン57をクリックすると当該駅の周辺の商店等7が一覧表示される。このため、顧客データベースにおいて、商店等7は、各駅と関連付けされている。図14では、選択された地域の商品等の分類項目に属する各商店等7の店名、業種及び特売日等がテキスト表示される。ユーザ5は興味のある商店等7を選択し、各商店等7のホームページに進む。
図12のメイン画面からは、品目に限定した検索も可能である。業種欄58でツリー化された業種を上位概念から下位概念にたどることで寿司屋、学校、弁護士等選択可能である。また、キーワード入力欄61に商品名等を記入し、検索ボタン63をクリックすることで当該商品等を扱う商店名等、特売日、住所地等が一覧表示される。キーワード入力欄61に商店名を直接入力し、商店等7のホームページに直接進むことも可能である。更に、本日が特売日キー65をクリックすることで、本日が特売日に当たる商店名、特売日、住所地等が表示される。ユーザ5は興味のある商店等7を選択し、各商店等7のホームページに進む。
キーワード入力欄61に商品名を記入した後、値段欄67に値段の上限値若しくは下限値、又はこれらの双方を記入して検索ボタン63をクリックすると、当該商品を当該値段で扱う商店名、特売日、住所地等が表示される。但し、商品名が例えばエアコンのような場合には、多数のメーカー名と機種が存在する。また、畳数等の使用容量を示す条件によっても異なる。このため、検索ボタン63をクリックした後、これらの条件を選択させるページを表示し、この条件選択がされた後に商店名等を表示するようにしてもよい。更に、図示していないが、値引き交渉可能な店に限定可能なようにしてもよい。
また、価格範囲と各商品等の属性を基に決められる各条件を指定することにより、所定の検索が行えると同時に、商品の売れ筋情報やお勧め情報がユーザ5に対し提示されるようにしてもよい。このため、WWWサーバー3側にて価格範囲と各条件に応じて予め商品の売れ筋情報等をホームページ形式で作成し、保存しておく。そして、指定された価格範囲に一致若しくは重複し、かつ各条件に合致するホームページを検索、抽出してユーザ5に対し表示する。ユーザ5は、この売れ筋情報やお勧め情報を基に確実な商品知識を得ることができる。このことにより、購入したい商品等を的確に短時間に絞ることができる。
しかしながら、この商品の売れ筋情報やお勧め情報は、各商店等7毎に独自に作成されたものが保存され、提示されてもよい。ソフトウェア9には、各商店等7又は各機種毎に売れ筋情報や店長お勧め情報等が記載可能なようにする。これらの情報は、ソフトウェア9によりホームページ形式とされ、アップロード可能である。そして、この売れ筋情報等は、各商店等7や各機種毎にページ保存され、リンク可能である。
タイムサービスボタン71、朝市ボタン73、夕市ボタン75をクリックすると現在行われているか、又は、今後例えば2時間以内にタイムサービス等が実施される予定の商品名、商店等7の名称等が表示される。均一セールボタン77をクリックすると、例えば200円均一セール、1000円均一セール等が行われている商店等7の名称等がテキスト表示される。
営業時間入力欄79のコンボボックスで10時〜23時や24時間等を選択すると、該当する商店等7の名称等がテキスト表示される。これらは、地区名入力欄53や業種欄58等と組み合わせることで、より効果的な検索が可能である。即ち、例えば、顧客データベースには、商店名、URL、業種、商品等の分類項目、営業時間、地区名、商品名、この商品の値段、値引き交渉可か否か、特売情報、最寄りの駅名等が保存されている。特売情報には、セール目的、朝市、夕市、タイムサービス等や特売品目、値段、特売日、特売時間等が含まれる。そして、これらのデータは互いに関連付けされており、いずれの項目の検索によっても必ず商店名、URLを含む情報が抽出される。地区名は都道府県名、区、市、郡、町、村のそれぞれ、又は組み合わせによっても商店名、URLが抽出可能である。従って、検索効率は向上する。
検索結果である商店等名欄をクリックすることで、例えば図15に示す各商店等7のホームページに進む。図15において、商店等7の扱う小分類項目毎に商品が整理されて開示されている。価格欄15には、希望販売価格が表示されるが、他に定価をも表示されるのが望ましい。また、日替わりセール、タイムサービス、朝市、均一セール等が開催される場合には、各サービス分類に従い商品が整理され、開示される。これらのセールは時々刻々によりデータが変わるため、ユーザ5のアクセス数は向上する。
なお、各セールの日や時間はWWWサーバー3側に内蔵の時計機能から現在日、現在時刻が抽出され、古くなったデータは削除される。従って、ユーザ5を混乱させることはない。画像25にはURLが関連付けられており、ユーザ5は画像25をダブルクリックすることで商店等7が独自に用意したホームページに進み、商品の詳細な情報を入手可能である。
値引き交渉欄19で値引き交渉が「可」とされている場合には、ユーザ5はユーザ希望購入価格欄91に希望購入価格を入力する。そして、個数欄93に購入する個数を入力する。その後、購入ボタン95をクリックすると、仮想店員の顔が現れ、「うーん、少し考えさせて下さい」等と表示又は音声出力する。この際の顔の表情や言葉は、複数用意し、価格欄15に提示された金額より低い割合となる程渋い顔等にしたり、底値に近くなった場合に「参ったなあ」等と表示するようにすると効率的で興味深い。その後、仮想店員の値段も含めた返事が店員返事欄97に表れる。店員返事欄97の金額は、別途用意される電卓に表示されるようにしてもよい。
値引き交渉は、商店等7の各品目毎に、各ユーザ5に対し例えば月当たり3回だけチャンスを認めるようにする。従って、ユーザ5は仮想店員との間の駆け引きで真剣勝負をせざるを得ない。各商店等7は、値引き交渉が考慮される分、他店の値段を気にすることなく、自分なりの値段を自由に価格欄15に提供でき、値段の提供方法に自由度が増す。即ち、同一の品物が他店よりも高く価格欄15に提示されていたとしても、ユーザ5の値引き交渉の仕方如何により、また底値如何により当該他店よりも低い値段となりうるものである。
次に図16のフローチャートに基づき値引き交渉方法を説明する。図16には、ユーザ5が同一商店等7で同一商品につき月当たり3回まで値引き交渉可能な例を示す。しかしながら、通常顧客、お得意様、上得意様と段階を分け、通常顧客には1回、お得意様には2回、上得意様には3回まで値引き交渉可能なようにしてもよい。また、購入個数と価格をかけた値段の大きさに応じて値引き交渉の回数を決めるようにしてもよい。更に、同一の商品について、値引き交渉可能な月当たりの商店等7の件数を制限するようにしてもよい。地域単位にこれらの制限を設けるようにしてもよい。
図16において、ステップ70では、ユーザ5は値引き交渉可能であることを確認する。ステップ71で、ユーザ5は価格欄15の値段X円を参考にして、ユーザ5が希望する価格である希望購入価格Z円をユーザ希望購入価格欄91に入力する。また、このとき同時に個数欄93に購入を希望する個数を記入する。その後、ステップ73で購入ボタン95をクリックするとデータはWWWサーバー3に送信される。
ステップ75で値引き交渉可能な商品であることが確認された場合には、ステップ77でユーザ個人が特定される。即ち、交信メッセージの中にユーザIDが含まれているか否か判断される。または、ユーザ個人を特定するためユーザIDや暗証番号等を入力させてもよい。ステップ79でユーザIDが存在しない場合には、ステップ81に進みユーザ登録作業を行い、ユーザIDを付与する。ユーザIDは例えばユーザパソコンのCookieファイル等にも記録される。ユーザ登録作業は、住所、氏名、電話番号、電子メール等を入力するものである。また、登録作業を行わない場合には、仮ユーザIDを付与するようにしてもよい。
ステップ83では、検出したユーザIDが過去にユーザデータベースに保存されたデータと一致するか否か判断される。ユーザデータベースに存在しない場合には、新規のユーザIDをユーザデータベースに作成する。そして、このユーザIDに対し当該顧客IDの当該商品に1回目の値引き交渉を行うことを示すため1をインクリメントする。この値引き交渉回数は表示するのが望ましい。そして、ステップ85では、価格欄15の値段X円と予め商店等7が宣言している底値Y円より(X+Y)/2円が演算され、希望購入価格Z円との間で比較がされる。(X+Y)/2円を算出するのは、一例として希望販売価格と底値の中間をまず1回目の値引き交渉の目安値としたもので、希望販売価格より1割下げて1回目の値引き交渉の目安値とする等してもよく、この数式に限定されるものではない。
(X+Y)/2円が希望購入価格Z円以下のとき、ステップ87に進み、店員返事欄97に「Z円で販売します。」と表示する。但し、仮想店員の口元に表示等するようにしてもよい。また、仮想店員に「ありがとうございます。」とお辞儀をさせるようにしてもよい。このZ円の販売価格は、ステップ88でユーザID、商店名、商品等と共にユーザデータベース等に保存される。一方、(X+Y)/2円が希望購入価格Z円を超えているとき、ステップ89に進み、底値Y円と希望購入価格Z円を比較する。希望購入価格Z円の方が底値Y円以上のときステップ87に進み、店員返事欄97に「Z円で販売します。」と表示する。希望購入価格Z円の方が底値Y円を下回るとき、仮想店員にとっては思慮外なので、ステップ91で店員返事欄97に「目一杯、(X+Y)/2円でどうですか。」等と表示する。但し、(X+Y)/2円は百円単位や千円単位等に適宜端数の出ないようにするのが望ましい。
または、端数をなくすように交渉するための端数削除依頼ボタンを設けるようにしてもよい。このとき、端数削除後の値段が底値Y円(又は底値Y+α円:αは予め定めた余裕値)以上の場合には、端数をなくすことを可能とする。この端数削除の可否を予め、商店等7に対しソフトウェア9により登録申請させるようにしてよい。
また、かかる端数の削除に代えて、あるいは端数の削除に併設しておまけを付けるように交渉するためのおまけボタンを設けるようにしてもよい。このとき、おまけの可否を予め、商店等7に対しソフトウェア9により登録申請させる。そして、この際には、おまけの商品名や型式等と共に単価を登録申請させる。ユーザ5よりおまけを付けるように要求された場合には、当該おまけを付けることにより底値Y円(又は底値Y+α円)未満となるか否かを判断する。底値Y円(又は底値Y+α円)以上の場合には少なくとも一つのおまけを付ける。なお、登録申請の際には、「常におまけを付ける」又は「値段交渉時のみにおまけを付ける」を選択可能としてもよい。
ステップ93でYESボタンがクリックされた場合にはステップ95で「ありがとうございます。(X+Y)/2円(但し、端数の削除された場合には削除された値段を表示する。また、おまけのある場合にはこれらも表示する。以下、同旨)で販売します。」と店員返事欄97に表示する。この(X+Y)/2円の価格は、ステップ96でユーザID、商店名、商品等と共にユーザデータベース等に保存される。
NOボタンがクリックされた場合にはステップ71に戻り、再び値引き交渉にチャレンジ可能である。希望購入価格Z円を再びユーザ希望購入価格欄91に入力する。今度はユーザIDがユーザデータベースに存在し、ステップ83で同一人と認定される。ステップ97では、交渉は成立済か否か判断され、ステップ95でこのユーザIDに対し既に交渉が成立済の場合にはステップ99で「この商品に関し、既に値引き交渉は(X+Y)/2円で成立済です。」と店員返事欄97に表示する。
ユーザデータベースに、当該ユーザIDに対する顧客IDの当該商品に1回の値引き交渉が行われたことを示す1が存在する場合には、2回目の値引き交渉と判断し、ステップ103に進む。ステップ103では、(X+2Y)/3円が演算され、希望購入価格Z円との間で比較がされる。(X+2Y)/3円を算出するのは、価格欄15の値段X円と底値Y円の差を3等分した(X−Y)/3円に底値Y円を加算したものであり、第2回目の値引き交渉の目安値である。従って、第2回目の値引き交渉の目安値である(X+2Y)/3円は、第1回目の値引き交渉の目安値(X+Y)/2円より低い値段である。
ステップ103において、(X+2Y)/3円が希望購入価格Z円以下のとき、ステップ105に進み、店員返事欄97に「Z円で販売します。」と表示する。一方、(X+2Y)/3円が希望購入価格Z円を超えているとき、ステップ107に進み、底値Y円と希望購入価格Z円を比較する。希望購入価格Z円の方が底値Y円以上のときステップ105に進み、店員返事欄97に「Z円で販売します。」と表示する。希望購入価格Z円の方が底値Y円を下回るとき、ステップ109で店員返事欄97に「限界です。(X+2Y)/3円でどうですか。」等と表示する。
ステップ111でYESボタンがクリックされた場合にはステップ113で
「ありがとうございます。(X+2Y)/3円で販売します。」と店員返事欄97に表示する。NOボタンがクリックされた場合にはステップ71に戻り、再び値引き交渉にチャレンジ可能である。希望購入価格Z円を再びユーザ希望購入価格欄91に入力する。
3回目の値引き交渉においては、ステップ115でユーザデータベースに、当該ユーザIDに対する顧客IDの当該商品に2回の値引き交渉が行われたことを示す2が存在するので、3回目の値引き交渉と判断し、ステップ117に進む。ステップ117では、(X+3Y)/4円が演算され、希望購入価格Z円との間で比較がされる。(X+3Y)/4円を算出するのは、価格欄15の値段X円と底値Y円の差を4等分した(X−Y)/4円に底値Y円を加算したものであり、第3回目の値引き交渉の目安値である。なお、ステップ119〜ステップ128までの処理は前述したのと同様であるので説明を省略する。
値引き交渉が4回目になった場合には、ステップ115でステップ129に進み、既に決定済の3回目の値段が提示されて終了する。また、値引き交渉の目安値の一般式はmを実数として、(X−(1−m)Y)/m円であり、実数mは、各商店等7の希望により随時、変更可能である。更に、通常顧客、お得意様、上得意様の段階に応じて実数mを異ならせるようにしてもよい。お得意様、上得意様の判断は、例えばユーザID毎の利用頻度や購入金額の大きさに応じて判断する。
また、値引き交渉の結果に対して、ユーザ5が不満の場合、「もう一声」ボタンを押すことで一層の値引きが行えるようにしてもよい。このとき、WWWサーバー3側では、現在表示されている交渉価格と底値Y円との間の価格を提示する。この価格は、乱数や予め定められた掛け率等によってもよいが、例えば先述の値引き交渉の目安値の一般式のmをm+1として演算し直すことで値段を下げユーザ5に提示する。「もう一声」の交渉の可否は、予め、商店等7に対しソフトウェア9により登録申請させる。
更に、同一の商品等について、他店の方が安かった場合には、「他店の方が安い」ボタンを押すことで更に値段交渉を可能としてもよい。このとき、他店との値段の比較の可否を予め、商店等7に対しソフトウェア9により登録申請させる。他店との比較は、同一地域内に存在する商店等7に限定されるようにしてもよい。この際の比較は、ユーザID及び同一の商品名にて過去データ(例えば1月分)の検索を行い、過去に行われた値段交渉の結果を抽出する。そして、この過去の値段が、現在の値段より本当に低かった場合に、過去の値段以下で、かつ底値Y円以上の値段を提示する。但し、値段を下げる代わりに過去の値段以下で、かつ底値Y円以上の値段となるよう前述のおまけを付けるようにしてもよい。また、同一の商品についての過去に行われた値段交渉の結果と比較するのではなく、他の商店等7の希望販売価格を抽出して値段を比較するようにしてもよい。更に、過去に行われた値段交渉の結果及び他の商店等7の希望販売価格の双方を抽出して値段を比較するようにしてもよい。
なお、買い物の都度若しくは買い物の最後には、購入リストを商店等名、商品等、購入金額、数量等と共に表示し、ユーザ5に確認してもらうのが望ましい。その際には、不要なものは取消可能とする。その後、購入リストは各商店等7毎に注文書として電子メールにて送信される。但し、ソフトウェア9がユーザ5のパソコンに常駐されれば、購入リストはソフトウェア9との間でデータ交信されてもよい。なお、ソフトウェア9には、注文書を履歴保存したり、各商品単位に月当たりの販売個数や金額、消費税等を合計したり等の演算や販売統計を取ることを可能としてもよい。ユーザ5の情報等もユーザ5のパソコン内に自動保存させれば、顧客管理にも使用できる。
また、ユーザ希望購入価格欄91を設けず、図示しない一発回答ボタンを店員返事欄97に隣接して配設し、ユーザ5にこの一発回答ボタンをクリックさせることで、予め用意した価格欄15の値段X円より低い金額(例えば、底値Y円)を店員返事欄97に提示するようにしてもよい。店員返事欄97への入力は自動による他、手動によることも可能である。この場合の金額は、通常顧客、お得意様、上得意様の段階に応じて異ならせるようにしてもよい。また、価格欄15の値段X円より低い金額で、かつ底値より高い金額の範囲で乱数発生により宝くじのように提示してもよい。更に、くじ引きを導入し、当選した順位等により金額を異ならせるようにしてもよい。
なお、ユーザ希望購入価格欄91には金額を入力するとして説明したが、4割引等の割引率や定価の6割等の販売率を入力可能としてもよい。この場合であっても、割引率等を金額換算すれば前述と同様の処理で対処可能である。あるいは、ユーザ希望購入価格欄91にはユーザ5が直接的に減額を希望する割引額を入力するようにしてもよい。
また、各商店等7では、図示は省略しているが、商品毎に配達を行うか否か、また配達の可能な地域である「近郊」、「市内」、「県内」、「全国」、「指定距離以内」等が表示されている。そして、ユーザ5は、配達の可能とされる商品について、チェックボックスにて「配達依頼」か若しくは「商品は取りに行く」を選択することができる。但し、この選択は、買い物の都度若しくは買い物の最後に行われる購入金額のユーザ5による確認の後でも修正可能とするのが望ましい。
「配達依頼」を選択した場合には、配達先欄に配達先を指定する。この配達先は、商店等7により予め登録された配達可能区域である「近郊」、「市内」、
「県内」、「全国」、「指定距離以内」等と比較される。この際には、地図データ上で商店等7の位置と配達先が比較され、商店等7から見た配達先が前記所定範囲内に包含されるか否か判断されたり、商店等7の位置と配達先の直線距離が算出され、前記指定距離以内に属する否か判断される。そして、配達先が配達可能区域から外れた場合には、「配達可能区域外」の表示をユーザ5に対し行う。
更に、各商店等7において配達を行わないとされる商品についても、地域内において、複数の商店等7で購入した商品等をまとめて配達依頼可能としてもよい。但し、この際には、図15に示す各商店等7のホームページにおいて、まとめて配達可能な商品等の表示を各商品単位にしておく。そして、ユーザ5は、買い物の最後に「地域内まとめて配達依頼」を選択し、配達希望日時を選択する。
この「地域内まとめて配達依頼」を選択した場合の処理について、図22のフローチャートに基づき説明する。
図22において、ステップ301で、「地域内まとめて配達依頼」がユーザ5により選択される。ステップ303では、各商店等7で購入した商品の内から各商店等7において、独自に配達の行われる商品が配達対象リストより除かれる。ステップ305では、残された商品について、その商品の属する商店等7が顧客データベースより抽出される。ステップ307では、各商店等7に当該商品を取りに行き、ユーザ5に対し配達を行うことの可能な地域担当者(若しくは地域担当センター、以下同旨)が地域担当データベースより検索される。地域担当データベースには、予め商店名と共にこの商店について配達の可能な地域担当者が登録されている。
ステップ309で、地域担当者が一人(若しくは一か所の地域担当センター)で済むか否か判断される。一人で済む場合には、ステップ311で商品の重量、大きさ等の予め設定されている料率の下に送料が計算される。一方、一部の商店が離れている等により、一人ではすべての商店にわたる配達が不可能な場合には、ステップ313に進む。そして、この地域担当者ではカバーできない商店をまず抽出する。次に、ステップ315では、この地域担当者ではカバーできない先述の商店を担当可能な地域外担当者が地域担当データベースより抽出される。
地域外担当者は、この商店から受け取った商品を宅配等の方法によりユーザ5に対し配送する。このため、ステップ317では、ユーザ5の住所から地域外担当者までの距離が算出される。ステップ311では、地域外担当者による送料が、この距離、商品の重量、大きさ等の予め設定されている料率の下に送料が計算される。そして、地域担当者の送料に対し地域外担当者の送料が加算される。
ステップ319で、地域担当者(及び地域外担当者)の電子メールアドレスが地域担当データベースより抽出される。ステップ321で、カード決済等による入金が確認された場合には、ステップ323に進み地域担当者(及び地域外担当者)の携帯電話やパソコン等宛に電子メールが送信される。この電子メールには、店名、品名、個数、受注日、配達先住所、氏名、配達希望日時等が記載される。また、配達先住所の位置を示す地図が添付されるのが望ましい。ステップ325では、地域担当者が電子メールを確認したことを返信する。この際、配達希望日時等の都合のつかない場合には、その旨の返信が地域担当者よりされ、この際には同時に都合のつく日時の候補が示される。その後、この都合のつく日時の候補がユーザ5に対し電子メール等で示される。ユーザ5が、この候補の中から一つを選択すると、この情報がWWWサーバー3に自動返信される。候補の選択は、まず日を選択した後、時間を指定するのが望ましい。選択された日時は、WWWサーバー3より地域担当者に送信される。なお、地域担当者に直接電子メールを送信するのではなく、地域担当センターで受信し、この地域担当センター内で配達の可能な地域担当者を選定するようにしてもよい。ステップ327では、配達の完了した場合に、地域担当者はWWWサーバー3に対し配達完了の旨の電子メールによる通知を行う。
以上により、ユーザ5が日常の買い物等の困難な人であっても地域担当者が代行して行うことができる。
次に、WWWサーバー3では、各商品やサービス毎にこれらの商品等が実際に販売された価格の最高額や平均額等を算出し保存する。そして、ホームページ上に各商店等7で扱われている各商品やサービス毎にこれらのデータを抽出し、各商店等7に対しダウンロード可能とする。これらのデータは、各商店等7にて当該商品やサービスの販売価格や底値を決める際の参考データとすることができる。なお、これらのデータは、各地域毎に価格の最高額や平均額等を算出し、ダウンロードするようにしてもよい。
次に、上述の例では、交渉の対象を商品等の値段として、交渉結果である商品等の値段に対し、消費税と、送料が規定されている場合にはこの送料が合算されるとして説明した。しかしながら、ユーザ5にとっては、特定の予算の範囲内で商品等を購入したい場合がある。この場合にユーザ5が商品等の値段をその都度自己の予算から逆算することは面倒な作業である。
かかる場合を考慮して、ユーザ希望購入価格欄91には、消費税及び送料を含めたユーザ5の予算金額を入力可能としてもよい。このため、底値Y円及び先述の値引き交渉の目安値に対しては、消費税及び先述の送料計算を行った後に、合算して合計金額を算出する。その上で、各合計金額をユーザ5の予算金額と比較して、値引き交渉を成立させるか否か判断する。
このことにより、ユーザ5は、自己の予算範囲で目的とする商品等が購入可能か否か簡単に判断できる。
また、上述の例では、値引き交渉の成立した価格にて商品等が販売されるとして説明した。しかしながら、商品等の販売は、あくまで価格欄15の値段X円として、値段X円から値引き交渉の成立した価格を引いた残りの金額を、データベースにて各ユーザID毎にポイントや点数等の形で蓄えておき、後に他の商品等の購入の際に使用可能としたり、ある程度蓄積された所で景品や現金等に代えたりしてもよい。
この際には、ユーザ5にとっては、値引き交渉の努力の成果としてポイント等の蓄積されることが楽しみとなる。従って、購入意欲や購入に対する努力、研究も更に促進される。ホームページを訪れる機会も増えることで、広告等の宣伝効果も増す。値引き交渉による感動を維持しつつ一律の値段X円にて取引が可能となるので、処理作業が簡単に行える。また、残りのポイント等を確認するための残額確認ボタンやポイント等にて商品を購入するためのボタンを配設するのが望ましい。残額確認ボタンが押された場合には、各ユーザID毎に蓄積されたポイント等を抽出してユーザ5に対し表示する。
次に、ユーザ5に対しては、ユーザ5により予め選択された各商店等7のバーゲン情報等をまとめて電子メールにて送信可能なようにする。ユーザ5にとって、各商店等7毎にホームページを確認し、バーゲン情報等を把握するのは時間を要し煩雑な作業である。このため、お気に入りの商店や地域に存在する商店等7等の情報をまとめて提供することとする。また、購入したい商品等が決まっていれば、その商品等に関するバーゲン情報等をまとめて電子メールにて入手可能とする。
このため、図14に示すように、バーゲン情報の入手を希望する旨のチェックボックス101を各商店等7毎に配設する。または、図17に示すように、例えばメイン画面にユーザ希望情報メール送信サービス130を掲載する。そして、このユーザ希望情報メール送信サービス130にてユーザ5に対しメール送信を希望する必要項目を設定してもらい、その必要項目分の情報だけを抜粋し送信することも可能である。
ユーザ希望情報メール送信サービス130では、地区名入力欄131で地域選択が可能である。地区名入力欄131は上位概念から下位概念へと選択可能なドロップダウンリストボックスである。複数の地域を選択したい場合には、追加ボタン132をクリックする。この際には地区名入力欄131がもう一つ追加される。または、同一ボックス内に複数の記載が可能である。
特売の目的である例えば特売情報のすべて、開店セール、朝市、タイムサービス、均一セール、通常販売、空欄等を特売目的欄133から選択する。業種欄135も同様に選択可能である。商店等名欄137にはチェックボックス101で選択した場合には記載不要である。また、入力された商店等名が顧客データベースに存在しない場合にはその旨のメッセージが表示される。この場合、追加ボタン132を押すことにより図14の画面に戻り、商店等を追加可能なようにしてもよい。商品名欄139には今後購入を予定しているため入手したい情報を選択する。例えば車を選択し、値段欄141に200万円〜230万円等と記載する。但し、車等の場合には、車種やメーカー名等の条件を更に指定可能なようにするのが望ましい。なお、WWWサーバー3側にて価格範囲と商品等の各条件に応じて予め商品の売れ筋情報やお勧め情報等を保存しておき、かかる情報をも入手可能とするのが望ましい。値引き交渉が可能なものを選択したい場合には値引き交渉欄141を選択する。送付店数上限欄145には、電子メールに送付される店数の上限値を記載する。標準値は例えば10店に設定されている。この場合、検索された情報の内から10店分以下の情報が送付される。
例えば、地域の特売情報のすべてを入手したい場合には、地区名入力欄131と特売目的欄133を設定する。プレビューボタン147をクリックすれば、検索が行われ、電子メールに記載される予定の項目が画面にてリスト表示される。ユーザ5が確認後、これでよければメール依頼ボタン149をクリックする。メール依頼ボタン149がクリックされた場合には、電子メールデータベースにユーザIDが登録され、そのユーザIDには検索条件が記録される。図14でバーゲン情報の入手を希望する旨のチェックボックス101が選択され、かつ図17のユーザ希望情報メール送信サービス130にも検索条件が設定された場合には論理和条件が取られる。
図18のフローチャートに電子メール作成手順を示す。
ステップ201で、電子メールデータベースに登録されている例えばユーザ番号U(=1)番めのユーザIDが選択される。ステップ203で、このユーザIDに登録された商店等名が抽出される。そして、ステップ205で、顧客データベースから、この商店等7のデータが取得される。この場合のデータは、例えば商店名、特売情報、特売期間、特売商品、値段等の限られた情報とする。
ステップ207では、この取得されたデータを商店等7に関連付けて電子メールデータベースに保存する。ステップ209で、商店名が複数存在している場合には、ステップ203に戻り次の商店名を抽出する。ステップ209ですべての商店名の抽出が完了している場合にはステップ211に進み、ユーザ番号をU+1とする。ステップ213で、ユーザ番号の残りが存在する場合にはステップ203に戻り、同様の処理が繰り返される。但し、1ユーザ毎に電子メールを作成するようにしてもよい。
ステップ215では、各ユーザID毎に複数の商店等7が保存されている場合には、この各商店等7をホームページへのアクセス順位の高い順に配列する。このようにするのは、人気のある商店等7を電子メールの先頭に位置させるためである。ステップ217で、各ユーザID毎に電子メールを作成する。
電子メールの情報送付は例えば図19のようであり、各商店等7にはURLがリンクされ、商店等7をクリックすることで各商店等7のホームページに直接アクセス可能である。このため、ユーザ5が気に入っている商店等7の概略情報がまとめて電子メールにて入手されると共に、その詳細情報を見たい場合にはホームページにアクセスすることで簡単に入手することができる。なお、ユーザ希望情報メール送信サービス130にてメール送信を希望しないユーザ5に対しては、購入実績のある商店等7をデータベースに保存しておき、この商店等7の新情報を送信するようにしてもよい。
次に、図20のフローチャートに電子メール作成手順の別例を示す。
図20において、ステップ231で、電子メールデータベースに登録されている例えばユーザ番号U(=1)番めのユーザIDが選択される。ステップ233で、顧客データベースから登録番号C(=1)番めの顧客IDが選択される。ステップ235で予めユーザ5により設定された検索条件を電子メールデータベースより抽出する。そして、ステップ237では、顧客データベースのC番めの顧客IDである商店等7から、この商店等7のデータがこの検索条件に基づき取得される。ステップ239では、この取得されたデータを商店等7に関連付けて電子メールデータベースに保存する。ステップ241で登録番号Cをインクリメントする。ステップ243で、顧客IDがまだ残っている場合には、ステップ235から同様の処理を繰り返す。
ステップ245では、各商店等7をホームページへのアクセス順位の高い順に配列する。そして、ステップ247では、送付店数上限欄145に、電子メールに送付される店数の上限値が記載されているか否か判断される。全データが選択されている場合には、ステップ249に進みステップ251で電子メールを作成する。上限値が設定されている場合には、ステップ253で掲載数を上限値までに制限し、ステップ251で電子メールを作成する。電子メールの作成が完了した場合には、ステップ255で次のユーザ番号に進み、ステップ233から同様の処理を繰り返す。
以上により、ユーザ5の必要とする情報をきめ細かく配慮した形で電子メールによる情報の送付が行える。
次に、図21のフローチャートに電子メール作成手順の更に別例を示す。
図18及び図20では、電子メールへの掲載順を各商店等7のホームページへのアクセス数の多い順としたが、図21では各商店等7の意向を重視した形で掲載順を設定するものである。なお、図20と同一要素のものについては同一符号を付して説明は省略する。
各商店等7に対しては、電子メールへの掲載順を配列順に応じて先頭から例えば10段階に分けた場合に、どの段階に掲載されるのを望むかを予め登録申請時に選択させておく。この10段階には、選択する場合の料金の目安を例として挙げておく。
図21において、ステップ237で商店等7のデータが検索条件に基づき取得された場合には、ステップ261で顧客データベースの顧客IDには、別途配設する乱数発生部により発生された乱数を割り付ける。但し、この乱数は、既に割り付けられた値と同一の値は排除される。ステップ263では、予めユーザ5により宣言された、10段階中のどの段階であるかを顧客データベースから読み取る。電子メールデータベースの記憶部分は、この10段階に対応させてデータを保存可能とする。そして、ステップ265では、電子メールデータベースのユーザ5により宣言された段階に保存する。ステップ243で、顧客IDのすべてにわたりデータの保存が完了した場合には、ステップ267で各段階毎に乱数の値順に配列し直す。
以上により、商店等7のほぼ希望する順に、公平の原則の下に電子メールへの掲載順を決めることができる。
なお、各商店等7に対しては、情報送付されるユーザ5の数を通知すると共にその通知件数に応じて請求額が決められる。
または、電子メールは通常上から読まれるので、図19においては、A商店に相当する先頭位置を最も高額とし、B商店、C商店と進むに連れて値段を安く設定するようにしてもよい。例えば先頭からの順番に応じて料金を段階的に設定したテーブルを予め用意し、商店等7の掲載された順番からこのテーブルを基に料金を算出する。
なお、本発明は、ネットショッピングのみならず、企業間取引や流通取引等にも適用される。先述の値引き交渉の目安値の一般式のmは、通常顧客、お得意様、上得意様の段階に応じて異ならせるとして説明したが、お得意様、上得意様の判断は、例えば企業規模や購入金額の大きさ等により判断する。従って、ユーザの登録申請の際には各企業に従業員数、資本金、設立年度等を登録してもらうのが望ましい。
ユーザの企業規模や購入金額の大きさ等により一般式のmや底値Y円を異ならせるか否かの可否、及びそのときのmの値や底値Y円の設定等は、予め、商店等7に対しソフトウェア9により登録申請させる。この場合には、企業規模や購入金額の大きさ等に応じて、複数の段階毎にmの値や底値Y円を異ならせて設定するのが望ましい。
また、最終段階での値引き交渉の結果に対しても、ユーザ5が不満の場合、更なる交渉の機会を設けるようにしてもよい。更なる交渉の機会は、例えば再交渉ボタンを押すことで、行われる。この際には、ユーザ5の名称や交渉の経過等が電子メール等により商店等7に対し連絡される。更なる交渉の機会を設けるか否かも、予め、商店等7に対しソフトウェア9により登録申請させる。
次に、本発明の第2実施形態について説明する。第2実施形態である製品購入手順のフローチャートを図23及び図24に示す。第2実施形態では、例えば、一つの製品を購入してもらったら、1回値引き交渉を認めたり、お得意様の状況等により値引き交渉可能な回数に制限を持たせるものである。そして、不特定多数からの無用な値引き交渉アクセスを制限するものである。また、交渉の過程においてギャンブル性を持たせたものである。
図23及び図24において、ユーザ5は、ステップ501において製品を購入するためにセンターのホームページを開く。そして、ステップ503において購入したい製品(プロダクトID)のページに進み、ステップ505において製品の購入ボタンを押す。製品は、例えばソフトウェアとする。これにより当該製品を購入したい旨の情報がセンターに送信される。
センターは、ステップ507において、ステップ505で購入ボタンを押したユーザ5に対して購入画面(センターHTML)を提供する。これに対し、ユーザ5は、ステップ509においてユーザIDを入力し、ステップ511においてこのユーザIDをセンターに送信する。
センターは、ステップ513において、ステップ511で送信されたユーザIDを有するユーザ5が有効期限以内(例えば現在より過去1ヶ月以内)に当該製品(プロダクトID)に対して値引き交渉したことのある者か否かを判断する。センターは、このステップ513で、ユーザ5が同じ製品に対して短期間に繰り返し値引き交渉を行おうとしている者か否かを判断する。但し、このステップ513の前に、この製品が値引き交渉可能か否か判断するようしてもよい。値引き交渉のできない場合には、定価若しくは所定の割引率により販売する。
そして、このステップ513で値引き交渉されたことがある(YES)と判断された場合には、ステップ521において「既に値引き交渉済です。」と表示し、ステップ523において値段、交渉日時、その製品名等を表示して、本手順を終了する。
一方、ステップ513で値引き交渉されたことがない(NO)と判断された場合には、ステップ515において値引き交渉可能回数Nが1以上か否かを判断する。センターは、このステップ515で、ユーザ5が何回値引き交渉が可能かを判断する。
そして、このステップ515でNが1以上でない(NO)と判断された場合、即ちN=0の場合には、ステップ525において今回は定価販売になる旨を表示し、これに同意すればステップ527で定価の値段を表示する。また、この定価販売に同意した者に対しては、ステップ535以降の手順が行われる。一方、定価販売であることに不同意である者に対しては、本手順を終了する。
ステップ515でNが1以上である(YES)と判断された場合には、ステップ601以降の値引き交渉ルーチンに進む。値引き交渉ルーチンについては、図26に後述する。
値引き交渉ルーチンを経て図24のステップ529で値引き交渉が成立すると、センターは、ステップ531において当該製品の値段(値引き交渉後の値段)を表示する。また、ステップ533において値引き交渉を1回行ったので、値引き交渉可能回数Nを1回デクリメントする。
更に、センターは、ステップ535において当該製品の成立価格及び成立日時をデータベース1009に保存する。この成立価格は、ステップ543の購入価格累計の加算に用いられ、成立日時は前述したステップ513の判断に用いられる。
その後、ユーザ5は、ステップ537において銀行振込、郵便振替、カード等の支払方法を選択し、必要事項を入力することで購入手続を行う。そして、センターは、ステップ539においてユーザ5の行った購入手続の確認を行う。
更に、センターは、ステップ541において、このユーザ5の今までの購入本数累計に対して今回の購入本数分をインクリメントする。また、ステップ543において、ステップ535で保存した成立価格をユーザ5の今までの購入価格累計に加算する。
そして、ステップ545において、当該ユーザIDに対し値引き交渉可能回数Nをインクリメントする。値引き交渉可能回数Nをインクリメントするのは、製品を購入してもらったユーザ5に対しては、お得意様と考え、次回に値引き交渉の機会を与えてあげようとする趣旨である。このステップ545では、例えば図25に示すように販売価格が5千円未満のときはNに1をインクリメントし、5千円以上のときはNに2をインクリメントし、一万円以上のときはNに3をインクリメントする等のように、販売価格に基づいてインクリメント値を変更するようにしてもよい。但し、この際には、Nが複数回認められるからといって、同じ製品に対して値引き交渉回数を繰り返し認めることは望ましくなく、異なる製品に対して認めることが望ましい。そして、このステップ545の終了後、本手順を終了する。
次に、上述した値引き交渉ルーチンについて説明する。値引き交渉ルーチンのフローチャートを図26に示す。
図26において、本ルーチンが始まると、センターは、ステップ601において、ユーザ5に対し購入画面上に仮想店員を表示する。そして、ステップ603において、仮想店員の口元に「いらっしゃいませ。この商品AAAについてご希望の値段を希望価格入力欄に入力して下さい。」と表示し、これを音声出力する。
これに対して、ユーザ5は、ステップ605において購入の希望価格Zを入力する。そして、ステップ607においてOKすると、この希望価格Zがセンターに送信され、次のステップ609に進む。一方、ステップ607においてOKしない場合には本ルーチンを終了する。
センターは、ステップ609において、値引き交渉の目安値E(以下提示価格Eという)がユーザ5の希望する希望価格Z以下か否かを判断する。ここで、提示価格E=(X−(1−m)Y)/mであり、Xは定価、Yは底値、mは割引の度合いに対応する実数である。そして、底値Yは、製品を提供するベンダーによりいつでも自由に上下できる。
また、実数mは、製品を提供を管理する管理者により随時、変更可能である。更に、実数mは、上述したステップ541やステップ543で加算累計した購入本数累計や購入価格累計(即ちお客様の段階)に応じて変動させることも可能である。実数mをお客様の段階に応じて変動させる方法を説明する。本方法のフローチャートを図27に示す。
図27において、センターは、ステップ901において購入本数累計が5以上、又は購入価格の累計が5万円以上か否かを判断する。そして、購入本数累計が5以上、又は購入価格の累計が5万円以上である(YES)と判断された場合には、ステップ903において実数mを0.2上げる。これにより、例えばステップ609で判断される提示価格Eが低くされる。一方、購入本数累計が5未満、及び購入価格の累計が5万円未満である(NO)と判断された場合には、実数mを変動させることなく、次のステップ905に進む。
更に、ステップ905において購入本数累計が10以上、又は購入価格の累計が10万円以上か否かを判断する。そして、購入本数累計が10以上、又は購入価格の累計が10万円以上である(YES)と判断された場合には、ステップ907において実数mを更に0.2上げて、提示価格Eを低くする。一方、これ以外(NO)の場合には、実数mを変動させることなく、次のステップに進む。
これにより、購入本数累計や購入価格の累計のしきい値を上昇させつつ、上記ステップ901、903、…と同じ手順を行うことで、購入本数累計や購入価格の累計の大きいお得意様のユーザ5に対しては、その程度に応じて実数mを大きくして提示価格Eを低くすることができる。なお、実数mは、例えば最大値は4とする。
そして、図26のステップ609で提示価格Eが希望価格Z以下である(YES)と判断された場合には、センターは、ステップ611において希望価格Z円で販売する旨を表示して、図24のステップ529で値引き交渉が成立する。また、ステップ609で提示価格Eが希望価格Zを超えている(NO)と判断された場合でも、ステップ613において底値Yが希望価格Z以下か否かを判断し、底値Yが希望価格Z以下である(YES)と判断された場合には、ステップ611において希望価格Z円で販売する旨を表示し、ステップ529で値引き交渉が成立する。
これに対し、ステップ613で底値Yが希望価格Zを超える(NO)と判断された場合には、ステップ615において提示価格E円で販売する旨の同意を求める。この提示価格Eは例えば10円単位で四捨五入される。そして、提示価格E円での販売に同意する場合には、ステップ617において提示価格E円で販売する旨を表示して、ステップ529で値引き交渉が成立する。一方、提示価格E円での販売に不同意である場合には、ステップ701以降の危険を承知でチャレンジルーチンに進み、このルーチンを終えることで、ステップ529に進んで値引き交渉が成立する。
なお、ステップ609において、演算された提示価格Eが希望価格Zを超えていると判断された場合には、ステップ613の判断をせずに、直ちにステップ615で「提示価格E円でどうですか」の表示を行うようにしてもよい。
危険を承知でチャレンジルーチンについて説明する。危険を承知でチャレンジルーチンのフローチャートを図28に示す。
図28において、本ルーチンが始まると、ユーザ5は、ステップ701においてコースの選択を行う。この選択では、もう少し何とかコース、もう一声コース、もっとお願いコースの3コースの選択が可能である。
いずれのコースにおいても、以下の確率ルーチンにおいて所定のギャンブルを行うことで、これに成功すると(ある確率で成功する)、提示価格Eよりも販売価格を下げることができる。しかしながら、ギャンブルに失敗すると販売価格が提示価格Eよりも上がってしまう。また、各コースにより提示価格Eからの下げ幅が異なり、下げ幅の段階が大きいコースについては、ギャンブルに成功する確率を減らしている。
そのため、ステップ701で「もう少し何とかコース」を選択した場合には、センターは、ステップ705において「提示価格Eより1段階安くなる確率が30%、提示価格Eより高くなってしまう確率が70%、それでもトライしてみますか?」と表示を行う。また、ステップ701で「もう一声コース」を選択した場合には、「提示価格Eより2段階安くなる確率が20%、提示価格Eより高くなってしまう確率が80%、困難と思いますが、それでもトライしてみますか?」と表示を行う。更に、ステップ701で「もっとお願いコース」を選択した場合には、「提示価格Eより3段階安くなる確率が10%、提示価格Eより高くなってしまう確率が90%、相当厳しいですが、それでもトライしてみますか?」と表示を行う。
その後、ステップ715においてチャレンジに同意した場合には、ステップ801以降においてギャンブルを行うべく確率ルーチンに進む。一方、ステップ715でチャレンジに不同意である場合には、図26のステップ615に戻り、再度提示価格E円で販売する旨の同意を求める。
確率ルーチンについて説明する。確率ルーチンのフローチャートを図29に示す。なお、図29には確率ルーチンで行うギャンブルの一例として数字選びを示す。
図29において、センターは、ステップ801で「いずれかの数字(例えば0〜9の10個の数字とする)を入力し、送信して下さい。入力された数字がセンターで乱数発生させた数字と一致したら提示価格Eより安くします。一致しなかったら提示価格Eより高くなります、ごめんなさい。」と表示する。
そして、ユーザ5が数字を1つ入力し、これを送信すると、センターは、ステップ803において上記ステップ701で選択されたコースを認識し、ステップ805において各コースに基づき必要個数の乱数を発生する。
例えば、「もう少し何とかコース」であれば成功確率が30%なので3個の乱数を発生し、「もう一声コース」であれば成功確率が20%なので2個の乱数を発生し、「もっとお願いコース」であれば成功確率が10%なので1個の乱数を発生する。
その結果、ステップ807において、「もう一声コース」であれば「センターで乱数発生させた数字は3、5で、ユーザ5が入力した数字は7です。」と表示した後、双方の数字の一致、不一致を判断して「K円で販売します。」と表示する。
このとき、上記の例では数字が不一致であるので提示価格Eより高い失敗価格Kが提示される。例えば、失敗価格K=(E+X)/2である。この失敗価格Kは例えば3コースとも同じとされる。但し、3コース毎に独自に設定されてもよい。
一方、数字が一致した場合には、ステップ807において提示価格Eより低い成功価格Lが提示される。例えば、成功価格L=((E−Y)×(1−n))+Yである。このとき、nはコース別の割引段階を示す値であり、「もう少し何とかコース」であればn=0.1、「もう一声コース」であればn=0.2、「もっとお願いコース」であればn=0.3とする。なお、n<1であり、nが大きくなると成功価格Lは下がる。また、nは適宜変更可能であり、お得意様の程度に応じて0.02ずつ上げてもよい。
そして、ステップ807で価格K、Lの提示を行うと、図24のステップ529で値引き交渉が成立する。
以上により、前もって製品を必ず1つ購入してもらい、次の製品の購入から値引き交渉を行わせることができる。従って、ユーザの製品購入意欲を促進させることができる。また、このように、製品購入の程度に応じて値引き交渉を認めつつ同一のユーザが同一の製品を購入するに対しては、値引き交渉の可能回数を制限するようにしたため、不特定多数の者が無制限に値引き交渉する等による底値Yの安易な暴露を防止できる。更に、複数本購入した者や多額の購入を行った者に対してはm値を上げて、提示価格Eを下げることができる。
なお、本実施形態では、確率ルーチンで行うギャンブルの一例として数字選びを示したが、これに限られず、スロットマシンやルーレット、トランプ等であってもよい。図30にスロットマシンを用いたギャンブルの一例を示す。
図30(a)において、センターからスロット851の画面が提供されると、ユーザ5がスタートレバー856をクリック等することで、3つのリール852、853、854が回転し始める。その後、ボタン857、858、859を順次押すことで、リール852、853、854の回転が停止する。このとき、ボタン857、858、859を押してからリール852、853、854の回転が停止するまでには時間を要することが望ましい。そして、この時間は、乱数発生などにより停止の都度異ならせ一定としないことが望ましい。各リール852、853、854には、例えば図30(b)に示すように、A、B、Cの3種類の模様が3回連続して繰り返し設けられる。
そのため、3つの窓860、861、862のいずれかに同じ模様が並ぶ確率は、窓の数(3)×2つ目のリール853に1つ目のリール852と同じ模様が並ぶ確率(1/3)×3つ目のリール854に2つ目のリール853と同じ模様が並ぶ確率(1/3)=3/9(約33%)となる。そのため、この状態を上述した「もう少し何とかコース」とすれば、成功確率をおよそ30%とできる。
一方、「もう一声コース」では、同じ模様を並べられる窓の数を2つとすることで、窓860、861に同じ模様が揃う確率を窓の数(2)×1/3×1/3=2/9(約22%)とでき、「もう一声コース」の成功確率をおよそ20%とできる。更に、「もっとお願いコース」では、同じ模様を並べられる窓の数を1つとすることで、確率を窓の数(1)×1/3×1/3=1/9(約11%)とでき、「もっとお願いコース」の成功確率をおよそ10%とできる。
なお、各コースの成功確率を変更させる方法は、上記のように「窓の数」を変更させる場合だけでなく、各リール852、853、854に施す模様の種類を変更させてもよい。この場合、「もう一声コース」で同じ模様を並べられる窓の数を3として各リール852、853、854にA、B、C、Dの4種類の模様を設けることで、同じ模様が揃う確率を窓の数(3)×1/4×1/4=3/16(約19%)とできる。また、「もっとお願いコース」では、各リール852、853、854に6種類の模様を施すことで、確率を窓の数(3)×1/6×1/6=3/36(約8%)とできる。
また、本実施形態で示した方法は、第1実施形態で示した様々な値引き交渉態様と組み合わされて適用されてもよい。
次に、本発明の第3実施形態について説明する。第3実施形態である商品購入手順のフローチャートを図31及び図32に示す。第3実施形態では、例えば、ユーザ5が購入しようとする商品に対し、若しくは次回の商品購入の際に現金還元を行うことを可能としたものである。現金還元は、基本的には、すべてのユーザ5に対し一律に一定金額を還元しようとするものである。また、この現金還元を値引き交渉と組み合わせることで、値引き交渉の多様化を図ると共に、より利用されやすいシステムとするものである。ユーザ5は、現金還元か値引き交渉のいずれかを選択可能である。現金還元された仮想現金は各ユーザ毎にデータベース1009上に設けられたユーザ貯金箱に入れられるようになっている。
センターのホームページ上には、商品仕様等と共にこの商品の標準価格Q円が掲載されている。また、一般ユーザ向け(お得意様ではない状態)の現金還元額R円が掲載されている。但し、この現金還元額は、ユーザのお得意様状況如何により異なる。この現金還元額は、還元率として適用されてもよい。
図31のステップ1001において購入したい商品(プロダクトID)のページに進み、この商品の購入を決意したユーザ5はステップ1003において商品の購入ボタンを押す。商品は、例えばソフトウェアである。しかしながら、各種商品の他、サービス等にも適用可能である。これにより当該商品を購入したい旨の情報がセンターに送信される。
ユーザ5は、ステップ1005においてユーザIDを入力した後送信する。そして、センターにてこのユーザIDが確認される。ステップ1007において、ユーザ5によるユーザID等の登録後初めての購入か否かが判断される。この判断は、センター側にてユーザIDの属する情報を判断することで自動的に行われる。登録後初めての購入の場合には、ステップ1009において、現金還元か値引き交渉のいずれかを選択する。基本的には、登録後初めての購入の場合には、現金還元に進んでもらうことを原則とする。そして、この際には、現金還元と共に値引き交渉権を付与するものとする。また、現金還元の内、ユーザ5の判断により一定金額分を今回の購入分から値引き可能とする。但し、かかる一定金額分の今回の購入分からの値引きを行わないことも可能である。
値引き交渉が選択された場合には、ステップ1011に進み、登録後初めての購入の場合には値引き交渉は行えず、現金還元のみが行える旨の表示を行う。そして、ユーザ5には現金還元の行えるページに進んでもらう。ステップ1009において、ユーザ5により現金還元が選択された場合にはステップ1013に進み、還元される仮想現金の内D円分を今回の商品に対し使うか、若しくはユーザ貯金箱に入れるかの問い合わせが行われる。D円は、例えば現金還元額R円の3割である。商品に対しD円分を今回使う旨の意思表示のあった場合には、ステップ1015で本製品の購入のためC円(=Q−D)を支払うように表示する。
また、残りの現金還元額F円(この場合、現金還元額R円の7割)はユーザ貯金箱に入れられる旨の表示がされる。一方、ステップ1013でD円分をユーザ貯金箱に入れる旨の選択がされた場合には、ステップ1015で本製品の購入のためC円(=Q−0=Q)を支払うように表示する。本ユーザは商品を初めて購入されたユーザであり、お得意様には相当しないので、ユーザ貯金箱には、R円が現金還元され、ユーザ貯金箱の残額はR円となる。
ステップ1017では、ユーザ5に対し、ユーザ5からの本支払の入金があり、センター側でこの入金が確認された後には値引き交渉権が1回分(若しくはその金額に応じて複数回分)付与される旨の予告表示が行われる。ステップ1019で、上述の各データはセンターのデータベース1009に一時保存され、ステップ1021で例えば2週間経過しても入金が確認されなかった場合には、ステップ1023で保存されていたデータを消去する。2週間経過しても入金のない状態は、ユーザ5が実質的に購入を止めたものと解されるためである。但し、この入金の確認は、銀行振込や郵便振替等のような場合に配慮され、キャッシュカード支払等のように、即座にオンライン決済の可能な場合には直ちに確定処理が実施される。ステップ1025で2週間以内に入金の確認された場合には、ステップ1027でデータの確定指令が出され、ステップ1029で確定処理が実施される。これにより、ステップ1031でユーザ貯金箱に対しP円の入金が確定され、ステップ1033でユーザ貯金箱の残額にP円が加算される。ここに、P=F(若しくは後述するS)である。そして、ステップ1035で値引き交渉可能回数も1回分(若しくはその金額に応じて複数回分)加算される。
次に、ステップ1007の判断で、ユーザ5による購入が初めてでない場合について説明する。この場合には、図32のステップ1041で現金還元か値引き交渉のいずれかを選択する。値引き交渉が選択された場合には、ステップ1043に進み値引き交渉処理が行われる。値引き交渉処理は、第1実施形態、第2実施形態で説明したいずれかのものであり、値引き交渉結果であるB円が表示されているものとする。そして、ステップ1045では、ユーザ5に対し、ユーザ貯金箱から仮想現金を引き出して今回の製品購入のために使うか否かの問い合わせが行われ、ユーザ貯金箱の残額が示される。ユーザ5がYESを選択した場合には、ステップ1047に進みユーザ貯金箱から本製品の購入のためU円が使われる旨の確認メッセージが表示される。そして、ステップ1049ではユーザ貯金箱から本製品の購入のためU円が使われたため、残額であるW円を指定期日迄に支払うように督促する旨の表示を出す。この際には、お支払方法の確認も可能である。なお、ステップ1045でユーザ5がNOを選択した場合には、ステップ1049に進む。この場合には、ユーザ貯金箱からの出金は0円であり、ユーザ5はB円全額を支払うことになる。また、ユーザ貯金箱からの出金で当該商品の全額を賄えた場合には残額W円の支払督促メッセージは表示しないものとする。
このように、値引き交渉結果で値引きがされた上に、更にユーザ貯金箱より仮想現金を引き出して当該製品を購入可能としたので、ユーザ5による本システムの利用の促進に繋がる。
一方、ステップ1041で現金還元が選択された場合には、ステップ1051に進み、ユーザ貯金箱から貯まっている仮想金額を使うか否かの問い合わせが行われる。使う旨の意思表示(YES)がされた場合には、ステップ1053でユーザ貯金箱から本製品の購入のためT円(T≦Q)が使われる旨の確認メッセージが表示される。そして、ステップ1055ではユーザ貯金箱から本製品の購入のためT円が使われたため、残額であるV円(=Q−T)を指定期日迄に支払うように督促する旨の表示を出す。この際には、ユーザ5は支払方法を確認することも可能である。また、入金確認後には、ユーザ5に対し、どの程度の現金還元が行われるのか予告表示する。この際の現金還元額はお得意様ランクに応じて異ならせられる。お得意様ランクは、購入金額の合計や購入頻度等に応じて例えばA〜Eまでの5段階とし、この各段階に応じたお得意様段階率(例えば数パーセント程度)を定義し、現金還元額S円を算出する。現金還元額Sの算出方法は、例えばS=R+お得意様段階率×(Q−R)である。
なお、ステップ1051でユーザ5がNOを選択した場合には、ステップ1055に進む。この場合には、ユーザ貯金箱からの出金は0円であり、ユーザ5はQ円全額を所定の支払方法に従い支払うことになる。また、ユーザ貯金箱からの出金で当該商品の全額を賄えた場合には残額V円の支払督促メッセージは表示しないものとする。
これらのデータはステップ1019に進み一時保存され、ステップ1021で例えば2週間経過しても入金が確認されなかった場合には、ステップ1023で保存されたデータは消去される。但し、仮想現金で賄われている場合には消去はされない。ステップ1029で確定処理が実施された場合には、ステップ1031でユーザ貯金箱に対しP円の入金が確定され、ステップ1033でユーザ貯金箱の残額にP円が加算される。ここに、P=Sである。なお、この場合には、ステップ1035は省略され、値引き交渉可能回数は加算されない。但し、値引き交渉可能回数が加算されるようにしてもよい。
以上により、値引き交渉を好まないユーザ5は現金還元を選択できるので、一層利用されやすいシステムにできる。また、現金還元の額が分かることで、値引き交渉額の底値を推定するヒントの一つを自然の形に提供でき、値引き交渉の利用促進にも繋げることができる。
なお、付与された値引き交渉回数や現金還元額は、付与の日から所定期日経過後にキャンセルされるものとする(フローチャートは省略する)。このことにより、ユーザ5による積極的な購入意欲を促すことができる。
また、ステップ1041で現金還元が選択された場合にも、一定金額分を今回の購入分から直接減額可能とされてもよい。この際には、例えば、現金還元総額T円に対して直接減額分限度額U円を貸し店舗である商店等7若しくはWWWサーバー3のサイトの運営者が設定する。直接減額分限度額は、現金還元として直接減額の可能な最大の限度額である。商店等7が設定する場合には、この設定はWWWサーバー3のサイトに対してオンライン接続された状態で行われるのが望ましい。設定されたデータは、データベースに保存され、このデータを基にホームページのデータが更新されてユーザ5に対して表示される。そして、この直接減額分限度額U円の範囲内で、ユーザ5は直接減額の希望額V円を図示しない直接減額分金額入力欄に入力可能である。このとき、ユーザ貯金箱にはT−V円が貯金される。但し、直接減額分限度額T若しくはユーザ貯金箱へT−Vのいずれかが0円のときには、この0円となる項目についてWeb画面表示はしないことが望ましい。
このように、商店等7側では、直接減額分とユーザ貯金箱への入金額とを自由に設定できる。この設定は商店等7により底値やm値等と共に随時変更可能である。
なお、本実施形態で示した方法は、第1実施形態で示した様々な値引き交渉態様と組み合わされて適用可能である。また、現金還元ではなくポイント制であっても同様に適用可能である。
次に、値引き交渉では現金還元によるよりも必ず安く購入される方法について説明する。ホームページ上に表示されている現金還元額よりも値引き交渉で安くなることを期待するユーザ5に配慮するためである。表示された現金還元額をC円とすると、現金還元後の価格P円は数7のように表される。
(数7)
希望販売価格X−現金還元額C=現金還元後価格P
ここに、現金還元後価格P円は数8の条件でないとデータベースに入力できないものとする。
(数8)
現金還元後価格P≧底値Y
一方、中間提示価格E円の計算は、図16のステップ91、ステップ109、ステップ123において、希望販売価格Xと底値Yの間で
中間提示価格E=(X−(1−m)Y)/m円
とされているが、数9のように、この希望販売価格Xに代えて現金還元後価格Pを代入して計算する。即ち、中間提示価格E円を現金還元後価格Pと底値Yの間に設定する。
(数9)
中間提示価格E=(P−(1−m)Y)/m円
また、現金還元後価格P円がユーザ5により入力された金額より小さいとき、ポップアップ画面で、「現金還元によるよりも高い購入金額が入力されています。このままでよいですか?」とユーザ5に対し尋ね、ユーザ5に対し「このままでよい」若しくは「入力金額を見直す」のいずれかを選択させる。そして、ユーザ5が「このままでよい」を選択すればこのまま処理を継続する。一方、「入力金額を見直す」が選択された際には、ユーザ5に対しユーザ希望購入価格欄91に希望購入価格を再度入力させる。
次に、本発明の第4実施形態について説明する。本発明の第4実施形態のフローチャートを図33に示す。本発明の第4実施形態では、複数購入商品について値引き交渉を行う場合である。例えば、a、b、c、d(価格はそれぞれa円、b円、c円、d円であって、額の大きさの順はa円>b円>c円>d円である)の商品があったとする。そして、この内、aとbとは値引き処理等対象商品であり、cとdとは値引き処理等対象外の通常の商品であると仮定する。値引き処理等対象商品は、例えば値引き交渉によるものであったり、現金還元によるものである。値引き処理等対象外の通常の商品は、値引き交渉や現金還元処理の行われないものであり、例えば標準価格販売、当店販売価格、標準価格より一定価格値下げされた価格が提示されて販売されるような場合等である。
基本方針として、1個だけ価格が突出しているパターンであって、しかも残りの合計額が小額のときにはこの1個について予め定められた値下げ方法が取られる以外に、残りの商品等については値下げ処理はしないこととする。これは、全体としてみて当該1個の商品について値引き等の処理が行えれば充分と考えられるからである。また、値引き処理等対象商品と値引き処理等対象外の通常の商品とで区別した処理を行うものとする。値引き処理等対象商品における実数m値やそれぞれの底値等を配慮した形で、複数商品購入されたときのまとめた値引きが行えるようにする一方で、値引き処理等対象外の商品についてもまとまった金額の大きさに応じて何らかの値下げをしようとするためである。
即ち、購入総額T円(=a+b+c+d)が大きければ、値引き処理等対象外の商品に対してある値下げ率の値引きを行う。なお、この値下げ率はテーブル表から読み取る。通常販売では値引き処理等対象外の商品に対して、標準価格販売であって値下げは行われていないか若しくは大きな額の値下げはされていないが、購入総額が大きいときにある率の値下げをするので顧客にとってはお買い得感が出る。更に、値引き処理等対象商品(同一、異種を問わない)が複数購入され、かつ金額が相当以上のときにはm値と底値Yを下げることとする。
図33において、ステップ1100では、個別に値引き交渉や現金還元が行われていないことを確認し、個別に値引き交渉や現金還元が行われた商品等については以降の処理を行わない。既に個別に値引き交渉等の行われている場合には、重ねて値引きに応ずる必要はないからである。ステップ1101では、購入された複数の商品の中から一番最大の価格Cmax(例えばa円)を抽出する。そして、ステップ1103では、購入総額からこの最大の価格Cmaxを引いた残額が購入総額に対してどの程度の割合か否かを判断する。割合α未満のときにはステップ1105に進み、まとめての値引きは行わない。この割合αは例えば0.2である。即ち、各商品単位で予め決められた仕様に基づく処理のみが許可される。例えば、それぞれ個別に商品aとbについては値引き交渉や現金還元が可能であり、一方、cとdについては通常の販売価格での販売がされる。残額が少ない割合のときにまで一層の値下げをする必要がないからである。また、各個別に認められた値引き等が行われるだけで充分だからである。
次にステップ1107では、購入総額T円から最大の価格Cmaxを引いた残額がβ円以上か否かを判断する。このβ円は例えば2000円である。β円未満のときにはステップ1105に進み、まとめての値引きは行わない。残額が少ないときにまで一層の値下げをする必要がないからである。
次に、複数商品購入された場合に、値引き処理や現金還元について更に優遇するための処理をステップ1109〜ステップ1121で行う。
まず、ステップ1109で購入された複数の商品の中から値引き処理等対象商品(例えばaとb)を抽出する。ステップ1111で、同一製品か異種製品かを問わず、複数個購入の場合には、ステップ1113に進み、抽出した値引き処理等対象商品の中から一番最大の価格Pmax(例えばa円)を抽出する。一方、ステップ1111で値引き処理等対象商品が一つの場合にはステップ1112で値下げ率θ1、θ2を0にする。値下げ率θ1、θ2は、複数個購入のされた場合にm値や底値Yを更に一層下げようとするための率である。このことにより、ユーザ5はまとめ買いにより更に安い価格で購入できる可能性が増す。
その後、ステップ1115で値引き処理等対象商品の総額R円(=a+b)からこの最大の価格Pmaxを引いた残額が総額R円に対してどの程度の割合か否かを判断する。なお、aとbとは同一の商品であってもよい。また、Pmaxは1商品についての値である。そして、残額が総額R円に対して割合γ未満のときにはステップ1112に進み、値下げ率θ1、θ2を0にする。この割合γは例えば0.2である。残額が少ない割合のときにまで一層の値下げをする必要がないからである。また、各個別に認められた値引き等が行われるだけで充分だからである。
次に、ステップ1117では、購入総額R円から最大の価格Pmaxを引いた残額がδ円以上か否かを判断する。このδ円は例えば2000円である。δ円未満のときにはステップ1112に進み、値下げ率θ1、θ2を0にする。残額が少ないときにまで一層の値下げをする必要がないからである。
残額がδ円以上のときにはステップ1119に進み、総額−率テーブル表より総額R円を基にm値及び底値yの値下げ率θ1、θ2を抽出する。総額R円を基として、後述する全体の商品の購入である購入総額T円(=a+b+c+d)を基にしていないのは、m値及び底値yが、値引き処理等対象外の商品価格の影響により変動されるのは不合理と考えられるからである。また、購入総額T円を基にして、後述のステップ1129〜ステップ1137で値引き対象外の商品について値段が下げられるので、このことだけでユーザにとっては既に充分であり、購入総額T円を基に更にm値及び底値yを下げるのは行き過ぎと考えられるからである。
総額−率テーブル表では、購入総額R円に対するm値及び底値yの値下げ率θ1、θ2が規定されており、購入総額R円が大きいときにはm値及び底値yの値下げ率θ1、θ2も大きくなるように設定されている。但し、購入総額T円を基に総額−率テーブル表の設定及び抽出処理がされるようにすることも可能である。なお、現金還元の場合には、総額−率テーブル表に購入総額R円に対する更に還元され得る現金還元額若しくは還元率が設定されることになる。そして、ステップ1121では、m(1+θ1)、y(1−θ2)を演算する。なお、ここで演算されたm(1+θ1)、y(1−θ2)は、ステップ1139で使用される。
次のステップ1127以降の処理では、まとめて相当額を購入してくれたユーザ5に対しては、値引き処理等対象外の商品についても値下げをしようとするものである。ステップ1127において、購入された複数の商品の中から値引き対象外の商品(例えばcとd)を抽出する。そして、ステップ1129で同一製品か異種製品かを問わず、値引き対象外の商品を1個以上購入したか否かが判断される。1個以上購入の場合には、ステップ1131に進み、購入総額T円(=a+b+c+d)を算出し、購入総額T円がε円(=例えば6000円)を超えているか否か判断される。このときの購入総額T円は、値引き処理等対象商品と値引き処理等対象外の商品の両方の総額である。ステップ1129で値引き処理等対象外の商品を一つも購入されていないと判断されたとき、及びステップ1131で購入総額T円がε円未満のときには、ステップ1133で値下げ率λが0に設定される。ステップ1127以降の処理は、値引き対象外の商品が存在する場合に、購入総額如何では、この値引き対象外の商品についても値下げを実施しようとするものであり、値引き対象外の商品が存在しない場合には、ステップ1129以降の処理により値下げをする必要はない。また購入総額T円が少ない場合まで値下げをする必要もないからである。
ステップ1131で購入総額T円がε円(=例えば6000円)を超えている場合には、ステップ1133に進み、総額T円−率テーブル表より総額T円を基に値下げ率λを抽出する。総額T円−率テーブル表では、購入総額T円に対する値引き対象外の商品の値下げ率λが規定されており、購入総額T円が大きいときには値下げ率λも大きくなるように設定されている。値下げ率λは、m値及び底値yの値下げ率θ1、θ2とは同一としないことが目的、処理する価格の相違及び自由度の点から望ましいため、区別して扱っている。しかしながら、共通とし、総額T円を基に値下げ率λ、θ1、θ2を決めるようにしてもよい。
ステップ1135では、値引き対象外の商品の総額Γ円(=c+d)を算出する。そして、ステップ1137では、この総額Γ円に対する値下げ後の金額Γ (1−λ)が演算される。
ステップ1139では、ステップ1121で求めたm値をm(1+θ1)、底値をy(1−θ2)として総額R円に対して値引き交渉を実施する。値引き交渉の基本処理方法は、図16のフローチャートの通りであるが、このとき、図16のフローチャート中の標準価格X円は各商品a、bの標準価格の合計、即ち購入総額R円と読み変えられる。同様に、底値Y円は、各商品a、bの底値の合計として適用される。ユーザ5に対しては商品a、b、c、dに対する購入総額T円が標準価格X円の代わりに表示される。これに対して、ユーザ5は、希望購入価格欄91に希望購入価格Z円を入力するが、この希望購入価格Z円は、商品a、b、c、dに対する購入総額T円に対するものである。一方、値引き処理等対象外の商品の総額Γ円(=c+d)を算出し、希望購入価格Z円から減算して値引き処理等対象部分希望購入価格z1(=Z円−Γ円)を求める。
そして、値引き交渉の目安値である(X−(1−m)Y)/m円が求められると、図16におけるステップ85、ステップ103、ステップ117の比較では、この目安値と値引き処理等対象部分希望購入価格z1とが対比されることとなる。そして、図33のステップ1141では、値引き結果と金額Γ(1−λ)とが合計される。具体的には、図16のステップ91、ステップ109、ステップ123では、値引き交渉の目安値に代えて、この目安値と金額Γ(1−λ)が足し算され、この足し算結果が表示される。一方、ステップ85等の比較で、目安値が値引き処理等対象部分希望購入価格z1以下のときには「希望購入価格Z円で販売します」と表示する。
但し、ユーザ5に対しては値引き処理等対象商品についての購入総額R円に対して値引き交渉させ、ここで定まった目安値と金額Γ(1−λ)若しくは値引き交渉の結果の額と金額Γ(1−λ)がそれぞれ足し算され、この足し算結果が表示されるようにしてもよい。
なお、現金還元の場合、総額−率テーブル表には購入総額R円に対する更に還元され得る現金還元額(若しくは還元率)を設定しておく。そして、この総額−率テーブル表を基に購入総額R円に対する更に還元され得る現金還元額(若しくは還元率)が演算され、この結果から算出された還元後の最終値段と金額Γ(1−λ)とが合計される。但し、値引き交渉によるものと、現金還元によるものとそれぞれグループに分けた上で上記処理を行い、その結果を加算するようにしてもよい。この場合、購入総額R円や購入総額T円に代えて各グループ毎の購入総額を基に処理されてもよい。更に、グループ分けは、値引き交渉によるものと、現金還元によるものと、値引き処理等対象外の商品とをそれぞれグループに分けたものとされてもよい。
また、値引き処理等対象商品について総額−率テーブル表で、m値及び底値yについて値下げ率を設定し演算するとして説明したが、この処理を行わずに総額−率テーブル表には最終的な最終値引き率ηを設定しておき、値引き交渉の結果の額R1に対してこの最終値引き率η分を値下げ(R1×(1−η))してユーザ5に対して販売するようにしてもよい。但し、m値及び底値yについて値下げ率(θ1、θ2)を設定し、更にこの最終値引き率ηを併せて設けるようにしてもよい。そして、まとめて値引きをしたことによる優遇分を明確にするため、実際のまとめて値引きをした額の部分とは区別して表示するようにしてもよい。具体的にはR1+Γと優遇分であるηR1+λΓを区別して表示した上で、実際のユーザ5の支払額であるR1+Γ−(ηR1+λΓ)をも併せて表示する。更に、値引き前の金額であるR+Γをも表示するようにしてもよい。このことにより、ユーザ5は商品等をまとめて購入したことによるメリットを金額により具体的に実感できる。
以上により、値引き処理等対象商品と値引き処理等対象外の商品とが混在している場合であっても、複数購入商品についてまとめて値引き交渉を行うことが可能である。商品は野菜や衣類等の各グループ分けされた形で、各グループ単位にまとめて値引き交渉が行われるようにしてもよい。値引き処理等対象商品だけを複数本購入する場合であっても、また値引き処理等対象外の商品だけを複数本購入する場合に対しても適用可能である。値引き処理等対象商品と値引き処理等対象外の商品のいずれであっても、同一の商品を複数購入する場合に対して適用可能である。
複数購入商品についてまとめて値引き交渉を行うに際しては、各商店等7単位に行われてもよいが、各商店等7にまたがって複数の商品が購入され、一度に値引き交渉を可能としてもよい。次に、貸し店舗形式で販売が行われる場合、複数の商店等で提供する商品等が混在してもまとめて値引き交渉を可能とする方法について説明する。ステップ1139の処理において、値引き処理等対象商品について希望販売価格の合計金額R円と底値の合計AYとを算出する。その後値引き交渉により、複数商品をまとめての決定価格が決まるので、まず数1を基に率Sを算出する。
(数1)
S=(まとめての決定価格−底値の合計AY)/(希望販売価格の合計金額R−底値の合計AY)
次に、この算出した率Sを基に各商品の決定価格を算出する。この各商品の決定価格は希望販売価格をX、底値をYとして数2のように算出できる。
(数2)
各商品の決定価格=(希望販売価格X−底値Y)*S+底値Y
以上により、複数の商店等で提供する商品等が混在している場合にまとめての値引き交渉をした場合であっても、各商品毎に決定価格を算出できる。
なお、値下げ率λ、最終値引き率ηは、各商店等7とWWWサーバー3のサイトとで独自に設定されてもよい。現金還元額(若しくは還元率)についても同様である。
このように、ネットショップにおける買い物かごに複数の商店等で提供する商品等を同時に入れ、複数の商店等にまたがったまとめての購入及び値引き交渉が可能である。値引き交渉による決定価格、現金還元額、まとめての値下げ額は各商品毎に分けられる。このため、まとめて購入された場合であっても売上は各店舗毎に表示可能となる。このことにより、クレジットカード決済の場合にカード情報の入力は各店舗にまたがって1回で済む。各商品についての送付先の入力もまとめて1回で済む。入力されたこれらの情報や決済情報は各店舗毎にまとめられる。そして、各商店等7に対して閲覧可能な情報として提供される。各商店等7はログインIDとパスワードでサイトに入りこの情報を閲覧する。
次に、同じ値引き処理等対象商品であっても、その中にまとめて購入することにより更に値引き可能なものと、まとめて購入されたとしても更なる値引きは行わないものとが混在した場合について説明する。まとめて購入する場合に更なる値引きが可能か否かは商品毎に表示され、この表示は値引き交渉や現金還元が可能か否かの表示とは別に表示される。
例えばA商店のa商品(希望販売価格a円、底値をyaとする)及びC商店のc商品(希望販売価格c円、底値をycとする)についてはまとめたときの更なる値引きが可能とし、B商店のb商品(希望販売価格b円、底値をybとする)についてはまとめたときの更なる値引きはできないものとする。
このとき、総額R円を算出するに際しては、まとめたときの更なる値引きが可能なものだけ(この場合にはA商店のa商品とC商店のc商品について)を合計する。そして、この総額R円を基にステップ1119でθ1、θ2を求める。まとめたときの底値の合計AYは、
(数3)
底値の合計AY=ya(1−θ2)+yb+yc(1−θ2)=(ya+yc)(1−θ2)+yb
即ち、値引き処理等対象商品の内、まとめたときに更なる値引きが可能なものだけについて底値を合計し、これらについてのみ底値を下げた形で合計をとる。一方、実数m値については、m(1+θ1×g/h)とする。ここに、hは値引き処理が可能な商品の総数であり、gはこの総数の内でまとめたときの更なる値引きが可能なものの数である。このようにθ1を減じるのは、まとめての値引き交渉の際には、更なる値引きは行わないものも含めた形で全体として一括して値引き交渉が行われるからである。
このように算出したm値と底値に基づきステップ1139で値引き交渉を実施する。そして、値引き交渉の決定価格が出たら、この決定価格を基に数1の率Sを求める。
その後、この率Sが算出されたら、先述の数2に基づき各商品の決定価格を算出する。このときに用いられる底値Yはa商品についてはya(1−θ2)、b商品についてはyb、c商品についてはyc(1−θ2)である。
現金還元の場合もほぼ同様であり、総額R円を算出するに際しては、現金還元額についてまとめたときの更なる値引きが可能なものだけ(例えばA商店のa商品とC商店のc商品について)を合計する。そして、この算出した総額R円について、更に還元される現金還元額(若しくは還元率δ)を総額−率テーブル表より求める。各商品の最終価格を算出するに際しては、更なる値引きが可能な商品について、この商品の現金還元額に対して算出された還元率δ分を加味(各商品の現金還元額×(1+δ))すればよい。
総額−率テーブル表より求められたのが率ではなく、金額の場合には、まず総額R円についてこの金額が相当する全体の還元率を算出する。その後、同様にこの還元率分をそれぞれの商品の現金還元額に対して加味すればよい。
値引き処理等対象外の商品については、ステップ1133で算出された値下げ率λを各商品毎に適用すれば各商品毎の最終価格が算出可能である。
なお、ユーザ5に対して価格表示するに際しては、まとめて購入したときの効果である減額分を独立して表示することが望ましい。
以上により、ユーザ5が複数の商店等7から複数の商品やサービスを購入したとしても販売処理が可能であると共に、同じ値引き処理等対象商品の中にまとめて購入することにより更に値引き可能なものと、まとめて購入されたとしても更なる値引きは行わないものとが混在した場合であっても、販売及び値引き交渉や現金還元処理が可能となる。
この場合であっても、販売結果の報告は各商店等7単位に行うことが可能となる。
次に、本発明の第5実施形態について説明する。本発明の第5実施形態の構成図を図34に示す。本発明の第5実施形態は、お店の中で商品等をチェックして気に入った商品等を購入したり、チラシや雑誌をチェックして商品等を購入する際に、値引き交渉や現金還元がその場で簡単にできるようにしたものである。
図34において、お店の中に置かれた商品1001にはその製品にバーコード1003が付されている。バーコード1003は1次元、2次元等のものや、ICタグ等その種類を問わない。コードには暗号化されたものや暗号化されていないものも含む。お店で商品等や価格を確認したユーザ5が、この商品等を購入したい場合には、携帯電話1005にてこのバーコード1003を撮像して読み取る。若しくはICタグからその情報を電磁的に読み取らせるようにしてもよい。但し、携帯電話1005を持たないユーザ5を考慮して携帯電話1005に代えて、店にインターネット接続可能な専用装置1006や移動情報端末を配備するようにしてもよい。この専用装置1006では、移動可能として、バーコード1003を読み取り、情報を解析できるものとしてもよいし、バーコード1003の読み取りを要さず、当該商品専用として備え付けられるようにしてもよい。
当該商品専用として備え付けられる場合には、予めこの専用装置1006内に必要な情報(商品専用のURLや商品情報、価格等)が設定されている。若しくは常時、当該商品の購入ページが画面に開かれていてもよい。また、バーコード1003に代えて、商品等に付されたICタグに対し専用装置1006から無線にて電力送信を行うと共にICタグより受信した受信データを読み込むようにしてもよい。このようにすれば、バーコード1003を撮像して読み取る等の作業は不要となる。
なお、チラシ1007(若しくは雑誌等)の場合には、その商品情報や価格等と共に当該商品のバーコードが印刷されていたりICタグ等が付されている。携帯電話1005(若しくは専用装置1006)で読み込まれ解析されたデータに基づきセンターサーバー1008にインターネットを介して接続されて当該商品等のWebページが直接開かれるようになっている。そして、センターサーバー1008において、ユーザ5は、この商品について値引き交渉や現金還元ができるようになっている。
データベース1009には製品情報が予め保存されている他、ユーザ5により購入された情報が、このデータベース1009に保存されるようになっている。センターサーバー1008は、複数のレジ1111に接続されている。そして、このレジ1111には、商品に付されたバーコード1003を読み取るためのリーダー1113と、情報を表示可能な表示器1115とが備えられている。
図35のフローチャートを基に本実施形態の動作を説明する。
図35において、ステップ1201では、ユーザ5が購入したい商品又はサービスに関するバーコード1003を携帯電話1005(若しくは専用装置1006)で読み取る。そして、ステップ1203で、このバーコード1003に記録された情報から製品名、品番、URLを解析する。但し、これらの情報は、バーコード1003によらず、記載された情報を基に手入力されるようにしてもよい。例えば、センターサーバー1008のホームページに手動操作で進み、このホームページより品番等を入力することでもよい。あるいは、専用装置1006が、当該商品専用として備え付けられている場合には、予めこの専用装置1006内に必要な情報を設定しておくようにしてもよい。ステップ1205では、解析されたURLを基にサイトの当該商品又はサービスのWebページが開かれる。ステップ1207では、ユーザ5はWebページ上で商品情報等を確認したり標準価格(若しくは当店販売価格)等を確認する。但し、店頭にて既に掲載されていたり、特に必要なものがなければ、これらの情報は省略されてもよい。
商品等を購入したい場合には、ユーザ5は、ステップ1209でWebページ上でユーザIDを入力し、ステップ1211でパスワードを入力する。そして、ステップ1213で、値引き交渉や現金還元を実行する。値引き交渉等は、本発明の第4実施形態で説明した複数個購入してまとめて値引き交渉等が行われるものであってもよい。ステップ1215では、この値引き交渉結果が表示される。但し、値引き交渉を行わずに購入だけの処理とされてもよい。この場合には、ステップ1213及びステップ1215の処理は省略できる。ステップ1217で、Webページ上に表示された購入ボタンをクリックすると、ステップ1219でデータベース1009にこの購入のデータが蓄積される。なお、電子決裁によりこの時点で銀行口座等より支払が完了されるようにしてもよいし、この時点では、支払未了のまま、レジ1111にて現金支払やカード支払がされるようにしてもよい。ステップ1221では、他に購入したい商品等が存在する場合には、ステップ1201から繰り返す。但し、この際には、ステップ1209のユーザIDの入力及びステップ1211のパスワードの入力は省略される。
終了する場合には、当該商品をレジ1111に持参する。但し、商品自体を持参しなくても商品情報あるいは値段等の記載された商品カードやICタグ等を持参するようにしてもよい。また、この段階で決済の済んでいる場合には、以降の処理を行わずに商品渡しや商品発送を行い処理が終了されるようにしてもよい。なお、商品の中には値引き交渉等がされない商品が混在されていてもよい。ステップ1223では、レジ1111にてレジ係によりユーザ5のユーザID等が確認され、ステップ1225でレジ1111にて各商品又はサービスに附帯されたバーコード1003がリーダー1113により読み取られる。サービスの場合には、情報の記録されたカード等によってもよい。ICタグに対し無線にて電力送信を行うと共にICタグより受信した受信データを読み込むようにしてもよい。このようにすれば、レジ係が各商品をリーダー1113で読み込む等の作業は不要となる。ステップ1227で読み取られた情報から製品名、品番が解析される。ステップ1229では、この製品名、品番を基にデータベース1009より一致する保存されていたデータが抽出される。なお、製品名の他、品番まで記載されていれば、これらの情報からユーザ5が購入する製品は特定されるので、ステップ1223でのレジ係によるユーザ5のユーザID等の確認は不要とすることもできる。
ステップ1231では、データベース1009より抽出された製品名、金額等がその都度表示器1115に表示され、確認される。この際、既に支払済決裁のされた製品については、その旨のメッセージも表示される。値引き交渉等のされない通常の商品についてもステップ1233でレジ1111にて集計がされる。ステップ1235では、レジ1111に合計金額を表示し、ステップ1237で支払未納分があれば、ステップ1239に進み現金若しくはカード等による支払が行われる。その後、ステップ1241で支払が完了すれば、ステップ1243でレシートが発行される。なお、ステップ1237で既に値引き交渉等のWeb上で電子決裁がされ、支払済の場合には、ステップ1243に進みレシートのみが発行される。
このことにより、商品購入に際して内気な人であっても気軽に値引き交渉ができ、買い物を楽しむことができる。高額な商品以外であっても値引き交渉が可能であり、交渉のために店員が対応する等の手間も無くなる。この際には、まとめて値引き交渉等もできる。商品を直接目で見て確認した上で購入できるのでユーザは安心である。ICタグを採用することでレジでの作業が簡単になる。
なお、本実施形態では、本人確認をユーザIDにより行うとして説明したが、カードで本人確認するようにしてもよい。この場合、購入に際してカード番号を入力し、更にレジ1111にてカード情報を読み取ることで本人かどうかをチェックする。また、携帯電話1005に内蔵されたICタグと、このICタグより電磁的に情報を読み取る読み取り回路をレジ1111に備えてもよい。移動情報端末でcookie情報を利用、分析した形で本人確認するようにしてもよい。携帯電話1005(若しくは専用装置1006)において指紋等のバイオメトリクス情報を取得可能とし、この情報を基に本人確認がされ、その結果本人と判定されたときに以降のステップに進むようにしてもよい。そして、レジ1111にても照合可能とする。あるいは、適宜買い物の都度、センターサーバー1008にて顧客番号を発行し、レジにてこの顧客番号を確認するようにしてもよい。
チラシ1007(若しくは雑誌)をチェックして商品等を購入するに際しては、ステップ1201でこのチラシや雑誌に印刷されたバーコード1003を携帯電話1005で読み取り、解析されたURLを基に当該商店のWebページに進む。そして、少なくとも一つの商品等について値引き交渉や現金還元を行った後、ユーザ5はこの商店に赴く。値引き交渉等の結果はデータベース1009に保存される。
ステップ1223でレジ係によりユーザ5のユーザID等が確認されることで、ステップ1229でデータベース1009よりこのユーザIDに一致する保存されていたデータが抽出される(この場合、ステップ1225、ステップ1227は省略する)。そして、レジ1111にて商品が渡され、支払がされる。但し、ユーザ5がこの商店に赴かなくても配送可能とされてもよい。この際、電子決裁済であれば、商品の配送のみで済む。着払いであれば、製品名、金額、購入日、配送先等を記載した伝票を添付する。
次に、本発明の第6実施形態について説明する。本発明の第6実施形態は第5実施形態の別態様である。図36のフローチャートを基に動作を説明する。図35では、お店の店内やチラシ等をチェックして商品等を購入する場合について説明したが、図36では、お店以外で商品等を見つけて同じ商品等が欲しくなり、購入を希望したような場合である。例えば、他人が所有していた商品等と同じ物が欲しい場合等である。なお、図35と同一要素のものについては同一符号を付して説明は省略する。
図36において、ステップ1201では、欲しい商品等に付されているバーコード1003を携帯電話1005で読み取る。ステップ1203で、このバーコード1003に記録された情報から製品名、サイトのURLを解析する。但し、この情報の中に販売店名が記録されていてもよい。URLを基にステップ1301ではサイトのWebページが開かれる。そして、ステップ1303では、製品名を基にデータベース1009より当該商品を扱う商店等のリストを表示する。ステップ1305では、このリストの中からユーザ5により選択された一つの商店の当該製品ページが表示される。そして、ユーザ5が購入を希望する場合には、値引き交渉等を行い、購入をする。ステップ1307では、ユーザ5は、この選択された商店に出向き、レジにてユーザID等が確認される。レジでの支払が完了したような場合等には、ステップ1309で商品の引渡がされる。但し、ユーザ5がこの商店に出向かなくても配送可能とされてもよい。また、当該商店では、この商品以外の商品がユーザ5により併せて購入されてもよい。
以上により、欲しい商品の詳しい情報がなくても現物から同じ商品を簡単に購入できる。この際には、値引き交渉等も行える。より安い店を探すこともできる。
次に、本発明の第7実施形態について説明する。本発明の第7実施形態は第5実施形態の別態様である。
第7実施形態では、テレビやテレビ機能付きパソコン等において、テレビショッピングが行われる場合である。このテレビショッピングにおいて、商品紹介の際には画面の適所にバーコード1003が表示される。フローチャートは、図35のものとステップ1201〜ステップ1221まで同様である。図35のステップ1201において、この画面に表示されたバーコード1003を携帯電話1005等で撮像して読み取る。ステップ1203で、このバーコード1003に記録された情報から製品名、サイトのURLを解析する。このURLを基にステップ1301ではサイトのWebページが開かれ、その後値引き交渉等が行われる。ステップ1223以降の処理に代えて、電子決済や銀行振込、あるいは着払いを中心とした決済が行われ、購入された商品は配送される。
なお、インターネット機能を有するテレビやパソコン等において、テレビショッピングを行う場合には、画面上で当該商品のネット接続可能な購入ボタンを押すことで、値引き交渉等のWebページが開かれる。この際には、テレビ映像欄外にてユーザ希望購入価格欄91を表示したり、テレビ映像と2重に重ねられた状態でユーザ希望購入価格欄91を表示することが望ましい。ユーザは、ユーザ希望購入価格欄91に希望購入価格を入力することで当該商品等について値引き交渉が行える。
次に、本発明の第8実施形態について説明する。本発明の第8実施形態は第5実施形態の別態様である。
図37のフローチャートを基に本発明の第8実施形態の動作を説明する。なお、図35と同一要素のものについては同一符号を付して説明は省略する。
無線にて情報取得可能なアンテナ部を有するICタグを各商品、若しくは紙やプラスチック等の商品カードに付しておく。ステップ1351では、ユーザ5は、商品や商品カードを買い物かごに入れる。ステップ1221にて商品購入を終了する場合にはステップ1225に進み、続ける場合には、ステップ1351を繰り返す。そして、ステップ1225では、レジ1111にてこれらの情報をまとめて電磁的に読み込む。レジ1111には、このための電磁波送受信部及びデータ解析部が配設されている。この場合、ICタグに対し無線にて電力送信を行うと共にICタグより受信した受信データを読み込むようにする。ICタグ側では、受信電波より電力を得ると共にこの電力を利用して保存されていた情報を電波にして放射する。この情報の搬送された電波を受信し、ステップ1227で解析することで情報を取得できる。但し、バーコードにより情報を読み込むようにしてもよい。
情報には、製品名が記録されている。取得された製品名はデータベース1009に保存される。そして、この製品名を基にステップ1229では、データベース1009よりデータが抽出され、表示器1115には当該製品名と共に価格が表示される。この価格についてステップ1213では値引き交渉等を行う。商品は複数についてまとめて値引き交渉等がされることも可能である。但し、値引き交渉等をせずに購入のみを可能としてもよい。また、購入金額の大きさにより値引き交渉等を可能とする等されてもよい。レジ1111には、ユーザ希望購入価格を入力するためのテンキーが用意されており、ユーザ5は、このテンキーを利用してユーザ希望購入価格を入力する。ステップ1209及びステップ1211は省略されてもよい。表示された値引き交渉結果でよければステップ1217で購入ボタンを押す。ステップ1237以降にて支払をする。
以上により、ユーザ5は、会計の際にまとめて値引き交渉等ができるので、効率的である。
次に、本発明の第9実施形態について説明する。本発明の第9実施形態は値引き交渉における底値Y円及び実数m値を交渉の都度変動させるものである。
底値Y円はこの値を含む若しくは下限とする範囲とする。即ち、例えば1万円の商品に対してこれ以上値下げできない限界値が5千円だったとして、4千8百円〜5千8百円の範囲(若しくは5千円〜6千円の範囲)の中のいずれかの値として底値を定義する。そして、この範囲の中で例えば乱数発生をさせ、底値を決めることとする。このことにより、底値はその都度変動するため、ユーザ5に対しては底値が推定し難いものとなる。
また、底値Y円及び実数m値は、商店等7の利益如何に応じて変動させるのが望ましい。このため、例えば実際に行われた値引き交渉結果値の平均値AVを取り、予め商店等7側で予定した値PRとの差を求め、AV−PRが正のとき乱数結果により求められた底値に対して一定値を下げる。但し、この下げ値を考慮したことによる底値が限界値を超えないことが望ましい。また、この下げ値はAV−PRの大きさ如何によって変化させるのが望ましい。例えばAV−PRの大きさが大きければ下げ値も大きくする。一方、AV−PRが負のとき乱数結果による底値に対して一定値を上げる。
あるいは、AV−PRが正のとき、4千8百円〜5千8百円の範囲の上限である5千8百円を一定値下げ(例えば5千4百円とする等)、一方、AV−PRが負のとき4千8百円〜5千8百円の範囲の下限である4千8百円を一定値上げる(例えば5千円とする等)ようにしてもよい。下げ幅、上げ幅は、AV−PRの絶対値の大きさ如何で決めることが望ましい。
更に、AV−PRが正のとき実数m値の値から一定値を上げ、一方、AV−PRが負のとき実数m値の値から一定値を下げるようにしてもよい。
なお、上述の説明では、AV−PRを算出して底値Y円及び実数m値を変動させるとして説明したが、底値Y円以上に相当する部分を利益額としてその額の合計を算出し、この利益額如何により底値Y円及び実数m値を前述と同様に交渉の都度変動させるようにしてもよい。
次に、本発明の第10実施形態について説明する。本発明の第10実施形態は、図16等で行われた値引き交渉の結果として減額される価格の内、一定金額又は全額を現金還元としてデータベース1009側に設けたユーザ貯金箱に保管するものである。そして、このユーザ貯金箱に保管された仮想現金を商品1001の購入の代金として使用可能とするものである。
ネット上でユーザ5に表示される希望販売価格はX円で、底値はY円、第1回目の交渉金額がG1円とする。希望販売価格X−第1回目の交渉金額(値引き交渉の目安値)G1=H円とすると、この内の一定金額を現金還元としてデータベース1009側に設けたユーザ貯金箱に保管する。例えば、H円の内、30パーセントを現金還元される額として設定すると、現金還元額は0.3H円となる。
そして、ユーザ5に対しては、予め、値引き交渉により減額された価格の内から、この0.3H円を現金還元額としてユーザ貯金箱に保管する旨の表示を行う。 値引き交渉による最終決定金額は、値引き交渉による決定価格にユーザ貯金箱に入れられる現金還元額を加算した額となる。なお、ユーザ貯金箱に入れられる現金還元額が、希望販売価格X−値引き交渉の決定価格である場合には、ユーザ5の支払金額は希望販売価格X円となる。そして、このユーザ貯金箱に入れられた現金還元額をユーザ5は、その後の商品購入代金として利用可能である。
なお、値引き交渉による決定価格にユーザ貯金箱に入れられる現金還元額を加算した額が希望販売価格Xを超えるような場合には、現金還元額を減額する等の処理を行うことが望ましい。
次に、本実施形態の別例について説明する。
図16等における底値Y円に対し、現金還元額を例えば0.3H円として、底値+現金還元額を改めて底値Y円に代えて仮底値として読みなおす。そして、ユーザ5には、この仮底値以上希望販売価格以下の間で値引き交渉をさせる。
例えばJ円で値引き交渉が決定したとする。このときのユーザ5の支払額はJ円である。そして、この中から0.3H円がユーザ貯金箱に入れられる。
以上により、ユーザ貯金箱に仮想現金が貯められていることで、ユーザ5が、再びこの仮想現金を使うため商品1001を購入することが期待できる。
なお、以上の処理を第4実施形態等で説明した複数購入商品についてまとめて値引き交渉する場合に対し適用する方法について説明する。
この場合には、まずそれぞれの商品1001の現金還元額を予め決めてユーザ5に対し開示しておく。そして、各商品1001についての底値の合計額より、各商品1001の現金還元額の合計額分だけアップさせた金額を仮底値として値引き交渉をさせる。そして、値引き交渉が成立したら、現金還元額の合計額分をユーザ貯金箱に入れる。
次に、本発明の第11実施形態について説明する。本発明の第11実施形態は、上述した各実施形態の値引き交渉処理を用い、例えばある商品等の商品購入の際に複数の人が一種の入札をする形で競い合いつつ、スリルに富んだ買い物ができるようにしたものである。
商店等7にはまず、その商品1001の希望販売価格及びその商品1001のこれ以下では販売を許可しない底値価格を提示してもらう。希望販売価格をホームページには載せる。そして、当該商品1001について入札に参加したい人に対しては、当該商品1001のホームページからログインID及びパスワードによりサイトに入ってもらって参加の意思表示をしてもらう。この参加の意思表示のあった場合には、サイトよりこのユーザ5に対し電子メールを送信する。電子メールには、例えば一定回数だけ入札に参加を認めるための番号が記載されている。
ユーザ5には指し値の勝負をしてもらう。ユーザ5が底値価格以下の値段をつけたら例えば図16のステップ91、123、109で示すように、「この値段でどうですか」という具合に交渉価格を提示する。ユーザ5は、この価格で購入したければ、購入のボタンを押す。この価格では高すぎて購入できなければ、図示しない購入断念のボタンを押す。
参加を認められた他のユーザ5も上記と同様の処理を行う。そして、各ユーザ5によって購入断念のされた入札履歴は、図38以下に示すようにホームページ上で表示され、誰でも閲覧が可能なようになっている。商品1001は一番先に買いを意思表示した人に販売される。即ち、交渉価格でユーザ5が購入を決意した場合、あるいは、底値を超えた価格を入力することでこのユーザ5は商品購入が可能となる。
図38の履歴例を基に説明する。商店等7の希望販売価格を10000円、底値価格を7000円、第1回目の交渉価格を8500円、第2回目の交渉価格を8000円とする。商品1001は電子レンジで、出店者はAAさんである。ソラさんは値引き交渉権を4回以上持っている。履歴表示の項目で「1人目 ソラさん 1000円 15日10時2分 購入断念」は、1000円で購入しようと思ったが、8500円でどうですかと表示されたので、購入を断念したということを意味する。7人目でソラさんは再び7500円で挑戦した所、底値落札価格の7000円を超えたので購入できた。
次に図39の履歴例について説明する。ソラさんは値引き交渉権を2回以上持っている。履歴表示の項目で「1人目 ソラさん 1000円 15日10時2分 購入断念」は、1000円で購入しようと思ったが、「8500円でどうですか」と表示されたので、購入を断念した。
その後もう1回続けてチャレンジした。ソラさんは再び2400円で挑戦した所、2回目交渉価格「8000円でどうですか」と表示された。この価格ならと購入を決意した。
次に図40の履歴例について説明する。ソラさんは値引き交渉権を2回以上持っている。そして、2回続けて挑戦したが、2回目交渉価格8000円でも高いと感じたので降りた。カニさんは1回挑戦したが、「8500円でどうですか」と表示されたので、購入を断念した。様子を見ていたAAさんは、特別表示価格を9000円に下げた。底値落札価格も6500円に下げた。
但し、AAさんは、逆に特別表示価格を高くしてもよいし、底値落札価格を高くしてもよい。人気があると見れば底値落札価格を高くすることも可能である。 このように、商店等7側や出店者は、この入札履歴を参照して、自らの設定した希望販売価格や底値価格をサイト上で変更することができる。変更されたデータはサイトのデータベース1009に保存される。但し、商店等7側により割引の度合いに対応する実数である実数mをも変更可能としてもよい。変更の履歴は入札履歴に記録される。このため、ユーザ5は、値段が変更されたことを知ることができる。その後、この変更された希望販売価格及び底値価格等に対してユーザ5は改めて作戦を立て直し、購入に向けた入札を行うことができる。なお、商店等7側が底値落札価格を下げた時点で、この底値落札価格よりも高い金額にて入札を行っていたユーザ5がいた場合には、このユーザ5に対して購入を認めるようにしてもよい。商品等の在庫数量が複数ある場合には、最も値段を高く設定したユーザ5から順に複数人に対し購入を認める等してもよい。
このように、本実施形態では、オークション的機能に加えて早い者勝ちの機能をも有する。当該商品等を即刻欲しい人は交渉価格で購入することも可能である。一方、底値ぎりぎりの値段での購入を希望するユーザ5は、少しずつ値段を競り合う形での参加が可能である。底値に一番早く到達したユーザ5に対し落札が認められるため、ユーザ5はいち早く入札金額を提示しようとする。また、底値は途中で商店等7により下がることもあるのでユーザ5はクギ付けになる。但し、以上の機能に加えて入札には制限時間を設け、制限時間内で最高額を出したユーザ5に対して購入を認めるようにしてもよい。また、この際には、出店者の設定した最低額を超えた値段だけが入札の参加可能な金額として認められるようにしてもよい。この最低額は通常底値以下に設定され、入札の可能とされる最低の金額である。また、前記と同様に底値価格を超えた場合には購入可能であり、また提示された交渉価格にても購入可能である。このように、制限時間をも組み合わせることでより一層緊迫の度合いが増す。各入札参加者にとっては、底値価格での購入、交渉価格での購入、制限時間による最高値を付けた人による購入のいずれの態様で購入が決まるのか全く分からないので、緊迫の度合いは極めて大きい。更に、底値以上になったときに購入可能とする機能を任意選択(若しくは保留)可能としてもよい。更に、以上の機能の組み合わせを各機能毎に任意に選択可能としてもよい。これらのオークション機能は、証券取引及び株価決定等にも使用可能である。
なお、同一のユーザ5の入札への参加回数は無制限とされてもよい。また、この場合に、同一のログインIDの者に対して当該競争入札に限り、例えば2回だけ中間提示額を提示しての交渉を認める。そして、ユーザ5に対して、この中間提示額を提示しての交渉を行うか否かユーザ5が入札を行った際に尋ねるようにする。入札金額の低い内から中間提示額を提示しての交渉により落札される可能性は低いが、入札が競って来た場合には、中間提示額を提示しての交渉により早期の決着を望む場合があるからである。また、この中間提示額は、各ユーザ5が入札を行った入札金額が底値落札価格に近くなればなるほど底値落札価格に近づくように低くされてもよい。希望販売価格をX円、現時点での入札金額の最高額L円、底値落札価格Y円とすると、中間提示額Q円は、Q=m(Y−L)(X−Y)/Y+Y
mは実数であり、現時点での入札金額が底値落札価格に近づいたときに、どの程度中間提示額Qを底値落札価格に近づけるかの感度を示す。但し、この中間提示額Qは一律の値ではなく、(Y−L)/Yに依存した関数としてもよい。そして、例えば、(X−L)/Yの値が小さくなればなるほどm値は大きくする等されてもよい。この場合には、ユーザ5は中間提示額が下がりいつ落札されても分からない事態となるので一層のスリルを感じる。あるいは、mの値は入札のあった回数に従い変化するようにしてもよい。また、底値価格を超えた場合に購入される、このときの底値価格の設定値と、中間提示額を算出するのに使用される底値の設定値とは異なるように設定されてもよい。
なお、例えば図41に示すように、商品名や商品ジャンルにより底値Y円の安い順等にリストを提示し、商店等7名や商品型番等をクリックすることで当該出展品にリンクされるようにしてもよい。底値Y円はユーザ5に対しては開示されない価格なので、表示価格については順不同となる。
次に、本実施形態の別例について説明する。図42においては、現金還元の実施されたものの履歴がとられるようになっている。そして、この履歴はユーザ5が閲覧可能である。現金還元額3000円はユーザ貯金箱に入れられ、次の購入に使用できる。値引き交渉権がなくても参加できる。購入により値引き交渉権が少なくとも一回分つく。
なお、例えば図43に示すように、商品名や商品ジャンルにより現金還元額の大きい順等にリストを提示し、商品型番等をクリックすることで当該出展品にリンクされるようにしてもよい。
また、ユーザ5が電子メールで付与された回数を超えて更に入札に参加し続けたい場合には、既に商品購入等により蓄積されている値引き交渉権を利用して入札が可能とされてもよい。また、商品1001の購入に際しては、ユーザ貯金箱からの支払も可能である。
更に、商店等7側の判断により、随時、入札履歴の中で最高入札金額を提示している一人若しくは商品等の数量が複数あれば最高入札金額の人から数えて数人分に対して購入を認めるようにしてもよい。
次に、本実施形態に関し、ユーザ5が手動で入札に際しての金額を入力する代わりに、自動的に入札可能とする方法について説明する。
上記した実施形態では、ユーザ5は時々刻々の入札履歴を閲覧しつつ次の一手を考えて実行する必要がある。このため、常時パソコン画面を閲覧する必要が出てくるが、長時間となると煩雑である。従って、以下のようにユーザ5が入札のシミュレートを考案し、入札に容易に参加可能なようにするものである。なお、本方法は、本実施形態に限定されるものではなく、インターネット1を通じて広く行われている複数の人が価格を少しずつ上げて行って入札を競り合うインターネットオークション形式の競争入札に対しても同様に適用可能なものである。
センターサーバー1008とユーザ5の使用するパソコンとはインターネット1を介して接続されている。まず、ユーザ5は、センターサーバー1008に接続し、Web画面上で入札に参加する商品等がこれから落札されるであろう推定価格を3段階に設定する。推定価格第1段階、第2段階、第3段階となるに連れて金額は大きく設定されるようになっている。但し、推定価格は必ずしも3段階に限定されるものではない。そして、ユーザ5は更に入札1回目の突き放し度αを設定する。続いて入札2回目の突き放し度β、入札3回目の突き放し度γ(α<β<γ)を設定する。但し、突き放し度は、入札3回目の突き放し度γ以降にも入札4回目の突き放し度δ・・・・等任意に追加設定可能なようになっている。この突き放し度は、他者の追随を振り払うために設定される度合いである。
推定価格第1段階、第2段階、第3段階、突き放し度はセンターのデータベース1009に保存される。入札開始にあっては、入札金額=((推定価格第1段階−入札開始最低価格)×突き放し度/100+入札開始最低価格)、一方、入札履歴が1件以上あった場合には入札金額=((推定価格第1段階−入札履歴中の現時点での最高価格)×突き放し度/100+入札履歴中の現時点での最高価格)に設定される。即ち、他者に対し価格面での追随を許さないためには入札の金額をできるだけ高く設定するのが理想であるが、いきなりあまりに高額を設定することは低価格での購入ができなくなることに繋がりユーザ5にとって好ましいことではない。従って、この両者を満足させる適当な突き放し度をユーザ5本人が予め設定する。突き放し度αでの価格設定に基づき入札が行われることにより、このユーザ5が1番高額の入札価格を設定したことになる。
しかしながら、この入札価格に対して他者が更に高額な入札価格を設定してきた場合には、次の突き放し度βでの価格設定に基づき自動入札が行われる。但し、この時点で他者の入札価格が突き放し度βでの価格設定を既に超えていた場合には、突き放し度γでの価格が入札価格に設定される。この自動入札によれば、逐一ユーザ5がWeb画面上で入札価格を入力するのではなく、センターサーバー1008に予め保存されたデータを基にセンターサーバー1008内で自動処理される。以降同様の処理が繰り返される。その後、他者の設定した入札価格が推定価格第1段階を超えた場合には、推定価格第1段階に代えて推定価格第2段階が代入された上で再び入札金額=((推定価格第2段階−入札履歴中の現時点での最高価格)×突き放し度/100+入札履歴中の現時点での最高価格)に基づき突き放し度αからの処理が繰り返される。なお、この点は、他者の入札価格が先の推定価格第1段階における突き放し度γでの価格を超え、かつ推定価格第1段階をもいきなり超えてしまったような場合にも同様である。但し、推定価格第2段階においては、推定価格第1段階とは異なる突き放し度が設定されるようにしてもよい。以降、推定価格第3段階についても同様の処理が行われる。そして、底値価格を初めて超えた場合に落札が決定され商品等を購入することができる。しかしながら、この点は、通常のインターネットオークションのように最終的に最高値をつけたユーザ5に対し落札がされるというようにされてもよい。
次に、本発明の第12実施形態について説明する。本発明の第12実施形態は、値引き交渉を会社同士の取引に適用するものである。
値引き交渉を会社同士の取引に適用する場合には、取引元は取引先である会社の規模や当該会社との間のこれまでの取引や実績、将来的な協力関係等を考慮した上で値引きの程度を個々に勘案することが望ましい。また、値引き交渉の行える会社を無制限に認めるのではなく、ある程度真に交渉を希望する会社に制限するため許可性を取ることが望ましい。
図44のフローチャートに基づき説明する。Web上には、値引き交渉等により値段決定可能な取引を提示している取引元である一方の会社が存在する。まず、ステップ1401では、この会社の情報及び取引項目を閲覧し、この会社との間での取引を希望する会社がWeb上でログインIDを入力する。取引希望会社が未だ登録されていない会社の場合には、Web上で会社名、代表者、所在地、電話番号、資本金、従業員数、設立年、電子メール番号等を入力してもらう。次に、ステップ1403ではパスワードを入力する。そして、ステップ1405では、取引希望会社は「値引き交渉を希望」(あるいは取引を希望)等のボタンを押す。ステップ1406では、センターサーバー1008に接続する。ステップ1407では、登録情報の中から当該取引希望会社についての会社情報を読む。ステップ1409では、会社便覧等の予め入れられたデータベース1009からこの会社情報と一致する会社を検索する。そして、ステップ1411では、このデータベース1009中から会社情報を読む。ステップ1413では、読まれた会社情報から資本金、従業員数等の企業力を点数評価する。ステップ1415では、取引希望会社に対しユーザパソコンから今回取引を希望する相手企業との間のこれまでの取引情報を入力してもらう。あるいは入力等を要さずに会社情報から予めセンターのデータベース1009に保存されている取引情報を読むようにしてもよい。
ステップ1417では、当該会社との間の取引状況を点数化する。この場合取引元と各企業との間で最高の取引額のケースを例えば100として点数化したりすればよい。また、ステップ1419では、これまでの実績を評価し点数化する。これは、例えば依頼案件について日常よくやってくれている。信頼がおける等のこれまでの取引における質面の評価を最高点を100として点数化する。そして、これらの質及び量の面から総合的に評価を下すため図45のステップ1421で点数の合計を算出する。ステップ1423では、予め定めた一応合格ラインとみなせる値である標準点数値との間の偏差を算出する。
ステップ1425で偏差が相当に低いと判断された場合には、ステップ1427でその内容を取引元に電子メール等で通知する。そして、この場合にはステップ1429で企業の独自判断に委ねる。一方、ステップ1425で偏差が一定レベル以上の場合には、ステップ1431でその偏差の大きさに応じて底値、割引の度合いに対応する実数である実数mを変える。ステップ1433では、利用可能番号を付した電子メールを取引希望会社に配信する。ステップ1435でこの電子メール等を受信した取引希望会社はステップ1437においてWeb上で利用可能番号を入力する。ステップ1439でこの利用可能番号がセンターサーバー1008に送信されることで、ステップ1439では値引き交渉が実施可能となる。
以上により、一層信頼関係の重視されるような企業間での取引等においても、適正に値引き交渉機能が適用可能となる。
次に、本発明の第13実施形態について説明する。本発明の第13実施形態は、予算総額を入力し、その予算総額に入る商品リストを提示するものである。
図46には商品選択の画面例を示すが、ユーザ5が購入したい商品等の優先順位や商品名、メーカー名等、欲しい機能等を指定できると共に当該商品についての予算割当金額が入力できるようになっている。欲しい機能やキーワードは複数個選択若しくは指定されてもよい。図47のステップ1501で、ユーザ5はセンターサーバー1008のホームページにおいて「予算内で購入」ボタンをクリックする。ステップ1503で地域を選択し、ステップ1505で商店名を選択する。地域は全国いずれの地域なのかを選択するが、限定しないことも可能である。また、商店名を選択せずにステップ1506で、安い店を選択、大規模店を選択、老舗を選択、底値の低い店を選択、現金還元額の大きい店を選択、人気店を選択、よ売れている商品で選択等から選択がされてもよい。これらのデータはセンターサーバー1008のデータベース1009に保存されている。
次に、ステップ1507でWeb画面上で商品1001を選択する。この商品選択では、図46に示すように、ユーザ5が予算総額の中で購入を優先したい順位、商品ジャンル、商品名、個数、機能、メーカー名、予算割当金額、その他必要なキーワードが入力若しくは選択可能である。予算割当金額には、予算総額の中でこの商品1001について幾ら位を当てるかについて記載する。キーワードは、自由記載であり、このキーワードに関連する商品1001をデータベース1009からテキスト検索可能なようになっている。ステップ1509では、「お薦めを選択」ボタンをクリックすることにより、お薦め商品を選択、女性に人気、20代に人気、30代に人気、40代に人気、50代に人気、特にこだわらない等を選択可能である。そして、ステップ1511では、予算総額を図示しない予算総額入力欄に入力し、センターに送信する。この予算総額は、例えば10000円と一義的に入力されてもよいし、10000円〜15000円と範囲指定により入力されてもよい。また、10000円以下等と入力されるようにしてもよい。範囲指定される場合には、予算割当金額は複数の範囲指定の中から一つを選択とされてもよい。このとき、当該商品名に属するすべての商品について希望販売価格の最高額と最低額とを基に、予め金額範囲を適当な範囲に分割して設定したものを複数用意しておく。
そして、ステップ1513でセンターサーバー1008にログインするためのユーザIDやパスワードを入力する。センターサーバー1008側では、予算総額の−3割減〜+3割増しを設定する。予算範囲を目安として商品1001を選択するためである。ステップ1517では、カウンタNに1を入れる。カウンタNはユーザ5が購入優先順位で選択した順位の数である。
まず、ステップ1519で購入優先順位1番目を選択する。そして、ステップ1521で商品名に基づきデータベース1009から商品の絞り込みを行う。図48において、ステップ1523では、「人気商品」「お薦め」等のユーザ5が選択した事項に基づき商品を絞り込みするか否か判断する。即ち、ステップ1509で「お薦め」等の選択がされている場合にはステップ1531に進む。一方、「お薦め」等の選択がされていなかった場合には、ステップ1525でメーカー名に基づき商品を絞り込む。そして、ステップ1527で機能に基づき商品を絞り込み、更に、ステップ1529でキーワードに基づき商品を絞り込む。
ステップ1531では、当該商品の予算割当金額の−3割減〜+3割増しに入る商品を絞り込む。一応、この金額範囲ならばユーザ5が購入する可能性があるし、予算額を考え直す可能性があると考えられるためである。但し、この範囲(−3割減〜+3割増し)については必ずしも限定するものではない。なお、現金還元システムが希望販売価格よりも現金還元された分実際に安く購入できる設定の場合には、予算金額として現金還元された結果の額を基に(即ち、商店等7の希望販売価格から現金還元額を引いた金額を基に)絞り込みが行われるようにしてもよい。こうすることにより、ユーザ5による実際の支払額と予算額との差を極力小さくすることができる。予算金額として商店等7の希望販売価格をそのまま用いるのか、あるいは、現金還元された結果の額を用いるのかを予め設定するようにしてもよい。また、値引き交渉結果の金額がおよそ推測可能であるならば、この値引き交渉結果の金額を基に絞り込みが行われるようにしてもよい。例えば、値引き交渉結果の金額を現金還元される額と同じとみなして処理がされてもよい。
次にステップ1533で絞り込み件数が1以上存在するか否か判断する。1以上存在する場合には、ステップ1535でデータを保存し、ステップ1537でカウンタNを1インクリメントする。ステップ1539では、次の購入優先順位の商品が存在するか否か判断し、存在する場合には、ステップ1519から同様の処理を行う。一方、ステップ1533で絞り込み件数が1以上存在しなかった場合には、図50のステップ1575に進む。ステップ1575では、予算割当金額の−3割減〜+3割増しを超えて商品を再び絞り込む。この範囲は少しずつ広げて随時判断するのが望ましい。そして、ステップ1577で絞り込み件数が1以上存在した場合にはステップ1535に進みデータを保存する。
ステップ1577で絞り込み件数が1以上存在しなかった場合は、ステップ1579で「人気商品」「お薦め」等のユーザ5が選択した事項を無視して商品を再び絞り込む。ステップ1581で絞り込み件数が1以上存在した場合にはステップ1535に進みデータを保存する。ステップ1581で絞り込み件数が1以上存在しなかった場合は、ステップ1583で機能やキーワードを無視して商品を再び絞り込む。ステップ1585で絞り込み件数が1以上存在した場合にはステップ1535に進みデータを保存する。ステップ1585で絞り込み件数が1以上存在しなかった場合は、ステップ1587でメーカー名を無視して商品を再び絞り込む。ステップ1589で絞り込み件数が1以上存在した場合にはステップ1535に進みデータを保存する。ステップ1589で絞り込み件数が1以上存在しなかった場合は、ステップ1591で「予算内に入る商品を見つけることができませんでした。」とセンターサーバー1008よりユーザ5に対しメッセージを送信、表示する。但し、絞り込み手順はこれに限定するものではない。
なお、ユーザ5の指定により、一つの選択された商品の値段が予算を大きく超えた場合に、他の商品に対し、この超えた分を回すようにされてもよい。具体的には、例えば、優先順位の高い商品について選定の結果予算割当金額を大きく上まわった場合に、優先順位の低い商品についての予算割当金額を小さく設定し直す等の調整をする。このように設定された新たな予算割当金額について商品等の絞り込みが再び行われる。そして、絞り込みの行われた結果の商品等について改めて金額が計算される。一方、優先順位の高い商品について選定の結果予算割当金額を大きく下回った場合に、優先順位の低い商品についての予算割当金額を高く設定し直す等されてもよい。そして、再び商品等の絞り込みが行われる。
ステップ1541では、選択された結果の商品を各ジャンルから一つ抽出して組み合わせる。このとき、各ジャンルには少なくとも一つの商品データが保存されているが、これらのデータをジャンル毎に一つずつ抽出して組み合わせて表示する。例えば、購入優先順位1位のジャンルから一つの商品を抽出し、購入優先順位2位のジャンルから一つの商品を抽出し、・・・という具合に抽出して組み合わせる。この組み合わせの順位については、任意としてもよいが、例えばメーカー名、機能、キーワード、お薦め度合い等の間に予め優先順位を付けるようにしてその順位に従って表示することが望ましい。そして、図49のステップ1543では組み合わせの行われた商品等について合計金額を算出する。ステップ1545で「予算範囲を超えたリストを要求」ボタンを押した場合にはステップ1551で総予算額の−3割減〜+3割増しを超えたものを選択する。そして、ステップ1553で「予算範囲を超えたリストです」とWeb表示した上でステップ1555でリストを表示する。
一方、ステップ1545で「予算範囲を超えたリストを要求」ボタンを押さなかった場合には、ステップ1547で総予算額の−3割減〜+3割増し以内に絞る商品を選択する。そして、ステップ1549で「予算範囲か若しくは値引き等により予算範囲に近くなると思われるリストです。」とWeb表示した上でステップ1555でリストを表示する。
但し、ステップ1545、1547、1549、1551、1553の処理は省略することも可能である。
ステップ1557では、リスト以上に詳細な例えば機能仕様等の商品データを表示する。ステップ1559でユーザ5により、「他の当店人気商品と比較」ボタンが押された場合には、ステップ1561で他の当店人気商品の詳細が対比される。この「他の当店人気商品と比較」ボタンが押されない状態では、ステップ1541で抽出されたデータはご購入予定商品欄に記載される。「他の当店人気商品と比較」ボタンが押された場合で、ご購入予定商品と比較例の表示された対比図の様子を図51に示す。当店人気商品については、予め商店側で販売統計等を基に選定されたものがデータベース1009に保存されている。図51では、比較例は2個について表示されているが、必ずしもこれに限定されるものではなく、随時比較例の下位のものを追加表示することができるようになっている。
Web画面にはユーザの入力した総予算額のデータとともに今回ご購入予定商品の合計金額とが表示されている。これにより、ユーザ5は、合計金額が総予算額の範囲内に収まっているのか、若しくは総予算額の範囲からどの程度ずれているかを判断できる。このご購入予定商品欄に記載されたデータと比較例とに記載された詳細データとを比較参照したユーザ5は、ステップ1563で比較データのいずれかをクリックすることで、ステップ1565でこの比較データの商品をご購入予定商品に変更することができる。この場合には、ステップ1567で、改めてすべてのご購入予定商品に対し合計金額を算出し直す。ステップ1569で購入ボタンがクリックされた場合には、ステップ1571で値引き交渉等を行うことが可能である。この値引き交渉には商品等をまとめて値引きが行われるようにされてもよい。ステップ1573で「次の候補」ボタンがクリックされた場合には、ステップ1541に戻り、絞り込みのされた商品等データの中から次の組み合わせが抽出され、その後同様の処理が行われる。
以上により、ユーザ5に対しインターネット1を介して予算額の範囲内で購入の可能な商品を見積もり提供できる。また、ユーザ5は、他のお薦め商品等と対比をすることができ、対比の結果購入したい商品を変更することもできるため、商品選択が簡単に行える。購入の決まった商品はインターネット1を介して値引き交渉や現金還元等により安価に購入をすることができる。
なお、図50のステップ1575〜ステップ1591に代えて、図52及び図53に示すような処理とされてもよい。以下、図50の処理の別態様について説明する。図52及び図53のフローチャートにおいて、ステップ1533で絞り込み件数が1以上存在しなかった場合には、ステップ1601で、無視すべき項目をユーザに提示し選択させる。この無視すべき項目は、予算額、「人気商品」「お薦め」等のユーザが選択した事項、機能及び/又はキーワード、メーカー名である。ユーザは無視してもよい項目を少なくとも一つ選択する。
例えば、ステップ1603で「予算を無視して商品を再び絞り込み」が選択された場合には、ステップ1605で予算を無視して商品を再び絞り込む処理が行われる。この場合、ステップ1521〜ステップ1531迄の処理の内、ステップ1531の処理がスキップされて絞り込みが行われる。そして、ステップ1607で絞り込み件数が1以上存在した場合にはステップ1535に進む。一方、ステップ1607で絞り込み件数が1以上存在しなかった場合にはステップ1609で「商品を絞り込みすることができませんでした。」とユーザ5に対して表示する。但し、予算額を完全に無視するのではなく、予算額を随時一段ずつランクアップした上で再度絞り込みを行うようにしてもよい。この場合には、商品件数が一つ以上存在した予算額のランクにおいてステップ1535に進むことが望ましい
また、ステップ1611で「「人気商品」「お薦め」等のユーザが選択した事項を無視して商品を再び絞り込み」が選択された場合には、ステップ1613で「人気商品」「お薦め」等のユーザが選択した事項を無視して商品を再び絞り込む処理が行われる。そして、ステップ1615で絞り込み件数が1以上存在した場合にはステップ1535に進む。一方、ステップ1615で絞り込み件数が1以上存在しなかった場合にはステップ1609で「商品を絞り込みすることができませんでした。」とユーザ5に対して表示する。
以下、図53のステップ1617で「機能及び/又はキーワードを無視して商品を再び絞り込む」が選択された場合についてもステップ1617〜1621に示すように上記と同様に処理が行われ、一方、ステップ1623で「メーカー名を無視して商品を再び絞り込む」が選択された場合についてもステップ1623〜ステップ1627に示すように上記と同様に処理が行われる。
更に、ステップ1629で、例えば「「人気商品」「お薦め」等のユーザが選択した事項を無視して商品を再び絞り込み」及び「機能及び/又はキーワードを無視して商品を再び絞り込む」の2つが選択された場合については、ステップ1631でまず、「人気商品」「お薦め」等のユーザが選択した事項を無視して商品を再び絞り込む処理が行われ、その後、ステップ1633で機能及び/又はキーワードを無視して商品を再び絞り込む処理が行われる。なお、2つの選択の組み合わせは上記に限らない。そして、ステップ1635で絞り込み件数が1以上存在した場合にはステップ1535に進む。一方、ステップ1635で絞り込み件数が1以上存在しなかった場合にはステップ1609で「商品を絞り込みすることができませんでした。」とユーザ5に対して表示する。なお、3つ以上の機能無視が選択された場合についても上記と同様である。
以上により、ユーザ5にとってより一層簡単に自分の商品購入希望に沿った形での絞り込みが行える。
次に、本発明の第14実施形態について説明する。本発明の第14実施形態は、商品の絞り込みをユーザに簡単にしてもらう手法についてである。まず、図54のステップ1651で前準備をする。ここでは、商品名を選択したりする。ステップ1653では、予算額を入力若しくは選択する。即ち、予算額は金額を入力欄に入力してもらってもよいし、予め複数設定された金額範囲の内から一つの範囲を選択するようにしてもよい。また、メーカー名を指定若しくは全メーカー名を指定して絞れるようにしてもよい。そして、ステップ1655では、ユーザ5は必要な機能を選択する。この機能は当該商品名に属するすべての商品を調査し、これらの商品を網羅できるように予め設定された機能(機能を示す単語若しくはキーワード的なもの)と当該機能の説明とである。この機能等は人為的に収集され設定されてもよいが、各商品仕様を箇条項目としてこれらのデータをコンピュータが自動収集して設定するようにされてもよい。同一の機能であっても各社毎に異なる定義や解説のされている場合があるが、かかる場合には、データベース1009に入力する際に機能の定義等を一義的に共通に定めたテーブルを用いて人為的にデータ変換することで半自動収集が可能となる。
ステップ1657では、予算額の範囲内で絞り込みを行い、絞り込みの結果、商品が存在しなかった場合には、ステップ1659で予算額の再設定を行った上で再びステップ1657からやり直す。絞り込みの結果、商品が存在した場合には、ステップ1661で当店人気順で絞り込みを行う。この際には、人気の理由として、各ユーザが支持した機能の統計を取り集計結果を表示するようにしてもよい。あるいは、この当店人気順に代えて、若しくは当店人気順と共に当店お勧め順を提示し、この当店お勧め順に従って絞り込みをされてもよい。当店お勧めのポイントとしてそのお勧めの要点を指摘するようにしてもよい。お勧めのポイントの内からユーザ5に対して少なくとも一つを選択させることで絞り込みを行うようにしてもよい。なお、このように選択された属性や推奨要因を蓄積、集計すれば、企業にとっての開発に役立つ。ステップ1663では、ステップ1655で設定された機能に基づき絞り込みを行う。機能で絞り込みを行った結果、完全一致したものが存在した場合には、ステップ1665で商品の候補を表示する。ユーザ5はステップ1667で候補の内から一つを選択し、ステップ1669で購入をする。この際には、ステップ1671で値引き交渉が可能である。
一方、ステップ1663において、機能で絞り込みを行った結果、完全一致したものが存在しなかった場合には、ステップ1673で機能の一致した個数の多いもの順に候補を表示する。即ち、例えばユーザ5の希望した機能の個数が5であったとすると、この内4つの一致した商品をまず第1候補とし、3つの機能の一致したものを次の候補とする等である。同順位候補が複数存在してもよい。また、各機能にはユーザ5の重視する機能項目順に異なる評価点数をユーザ5が与えるようにし、候補表示に際しては評価点数の合計の大きい商品順に表示するようにしてもよい。更に、機能毎にユーザ5に対して必要とされる順に優先順位を番号で付けてもらい、この優先順位の高い項目を有する商品から先に候補とされるようにしてもよい。
また、ステップ1675では、図55に示すように、ユーザ5により選択された機能の内、この商品にない機能とある機能とを表示する。ユーザ5により選択された機能の内いずれの機能がその商品にあって、いずれの機能がないのか明確になることにより、ユーザ5は予算範囲で購入するに際して、その商品でよいかどうか簡単に判断できる。ステップ1677でユーザ5が候補の内から気に入って購入を希望する商品の一つを選択すると、ステップ1679で購入が行われ、ステップ1681で値引き交渉等が行われる。一方、ステップ1677でユーザ5にとって、購入を希望する商品がなかった場合には、ステップ1683で図55に示す「予算額を1段上げる」ボタンをクリックすることで予算額を1段上げてステップ1657から再び処理を行う。
以上により、予算額の範囲内でユーザ希望の機能を完全、あるいはある程度満足し、定評のある商品の絞り込みをユーザが簡単に行えるようになる。
次に、本発明の第15実施形態について説明する。本発明の第15実施形態は、図16のステップ85、91等で中間の提示額をユーザ5に対して提示する際に、ユーザ5が底値未満を希望購入価格として入力してきた場合であっても底値に近い値を出してきたらその分低い金額を提示額として提示しようとするものである。この理由として、ユーザ5は当該商品等の妥当な値段をよく研究している訳だからその分提示額も安くする必要があると判断されるからである。逆に底値よりはるかに下回る値段を出してきた場合には提示額に高い値段を提示しても構わない。この理由として、ユーザ5は当該商品等の妥当な値段を研究していない訳だから(即ち、その商品自体を研究していない訳であるから)その分値段を高くしても構わないと判断されるからである。
図56には、希望販売価格X、提示価格の中でも最高額である最大提示価格Emax、底値Yとの関係を示す。最大提示価格Emaxは、前出の実数m値を基に算出された提示価格である。そして、この図において、ユーザ希望入力価格Z1が底値Y未満で、かつ底値Yから相当程度離れている場合には提示価格E1も底値Yから相当程度離れており、一方、ユーザ希望入力価格Z2が底値Y未満で、かつ底値Yにより接近している場合には提示価格E2も底値Yにより近く設定されている様子を示す。
図57は、ユーザ希望入力価格Zと底値Yの比率であるZ/Yと提示価格値との間の関係を示したグラフである。数値例を基に具体的に説明する。今、最大提示価格を11万円、底値Yを10万円とする。そして、ユーザ希望入力価格が9万円までのとき(即ちZ/Yが0.9までのとき)、例えば図16のステップ91では11万円が提示される。また、ユーザ希望入力価格が9万5千円のとき (即ちZ/Yが0.95のとき)には10万5千円が提示され、ユーザ希望入力価格が9万9千円のとき(即ちZ/Yが0.99のとき)には10万1千円が提示される。
これらの関係を一般式で表すと、αは倍率である(例えばα値は10)。そして、
Z/Yが0≦Z/Y<1−1/αのとき最大提示価格Emax
Z/Yが1−1/α≦Z/Yのとき
提示価格E=α*(Y−Z)/Y*(Emax−Y)+Y
グラフはαの値が小のとき傾斜は緩やか(感度鈍い)となり、一方、αの値が大のとき傾斜は急となる(感度敏感)。
なお、提示価格Eは、上記のように最大提示価格Emaxと底値Yの間でもよいし、希望販売価格Xと底値Yの間とされてもよい。また、連続的な変化とせずに階段値とされてもよい。階段値を補完するようにしてもよい。リニアな変化ではなく所定の曲率を有して変化するようにしてもよい。
以上により、よ商品を知り尽くした人にはより安く購入させることでユーザ5の満足を得ることができる。
なお、上記の処理は、上述したように値引き交渉に利用可能であるとともに、第11実施形態で述べたオークション的機能にも使用可能である。このとき、中間提示額は次第に下がって行くのでより一層のスリル感が期待できる。なお、商店等により底値が変更された場合には、改めてZ/Yが算出された後、図57のグラフに従って提示価格が算出される。m値が変更されることで最大提示価格Emaxが変わったような場合も同様である。
次に、本発明の第16実施形態について説明する。本発明の第16実施形態は他店よりも自店舗の方が商品等の販売価格が高かった場合であっても、ユーザからの依頼により可能な範囲で他店以下に値段を即時に下げることで販売を有利にするものである。
図58にフローチャートを示す。図58において、ステップ1701では、ユーザ5はインターネット接続されたパソコンにおいて、センターサーバー1008に接続すると共にそのWeb上でユーザID、パスワードを入力する。そして、ステップ1703でWeb上に表示された商品等の中から購入を欲している商品を指定する。ステップ1705では、他店の店名、販売の期日、サイトのURL、他店の属する県名、電話番号及び他店で幾らだったか(他店価格U円)等をWebの入力欄に入力してもらう。そして、ステップ1707では、「他店の方が安いよ」ボタンを押す。このことにより、ステップ1709では、データがセンターサーバー1008に送信される。
そして、ステップ1711では、センターサーバー1008で受信された他店のデータをデータベース1009に蓄積する。この蓄積されたデータは、後で分析や参考に使用される。ステップ1713では、当該ユーザ5による商店等7でのこれまでの購入実績である合計金額がa円以上であるか否か、若しくはお得意様ランクが所定水準以上であるか否かが判断される。
但し、センターサーバー1008が貸し店舗形式を採用している場合には、ステップ1713の判断は、テナントとして入っている各商店等7毎に独自に判断されるのが望ましい。これは、他店より安く販売するという利益行為を特定のユーザに限って認めるためである。不特定多数に対し認める場合にはこれらの処理は不要である。判断の結果がYESの場合にはステップ1715に進む。
ステップ1715では、当該ユーザIDに対してこの商品についての交渉が初めてか否か判断される。複数回認めることは好ましくないからである。初めてのときにはステップ1717に進み、当該ユーザ5が値引き交渉可能回数をn回分以上有しているか否かが判断される。n個は例えば少なくとも1回である。より慎重を期するため、値引き交渉可能回数を有する人だけに対し認めようとするものである。
ステップ1717で値引き交渉可能回数がn個以上存在していた場合には、ステップ1719に進み、L円=他店金額U円−底値Y円が演算される。底値Y円は、当該商店等7が設定したこれ以下では販売が困難とされる価格である。そして、このL円が0円以上か否かが判断される。0円以上のときには、ステップ1721に進み、例えば(U−Y)/m1+Yが演算される。但し、図16の所で既に説明したように、値引き交渉の目安値の一般式はm1を実数として、(U−(1−m1)Y)/m1であり、実数m1や底値等は、各商店等7の希望若しくは任意により随時変更可能である。自動的に随時変動するように予めプログラムされてもよい。
更に、通常顧客、お得意様、上得意様の段階に応じて実数m1を異ならせるようにしてもよい。但し、この数式に限定するものではなく、他店金額U円以下に設定されるように算出されればよい。そして、ユーザ5への提示金額は、底値Y円以上となることが望ましいが、必ずしもこれに限定するものではなく、底値Y円は、通常顧客、お得意様、上得意様の段階に応じて下げるように設定してもよい。また、割合ではなく、予め設定した所定の金額分だけ下げるようにされてもよい。更に、L円の大きさに応じて段階的に所定金額分ずつ下がるように設定されてもよい。
そして、このステップ1721で算出された価格は、ステップ1723においてユーザ5に対しWebを介して提示される。そして、「この値段ではどうですか?」と問い合わせがされる。ユーザ5は、ステップ1725において、この値段を見て購入若しくはキャンセルを選択する。その後、ステップ1727では、ユーザ5の有する値引き交渉可能回数が少なくとも1回分デクリメントされる。一方、ステップ1719でL円が負の場合には、ステップ1729で「当店ではこの値段では厳しいです。」とメッセージを返す。
しかしながら、この際には、図16の所で既に説明したのと同様に当店なりの実数m2値に従った値段((X−Y)/m2+Yを演算)を提示し、「この値段ではどうですか」と問い合わせしてもよい(ステップ1730)。そして、ユーザ5は、ステップ1731において、この値段を見て購入若しくはキャンセルを選択する。その後、ステップ1727では、ユーザ5の有する値引き交渉可能回数が少なくとも1回分デクリメントされる。
一方、ステップ1713、ステップ1715及びステップ1717で、判断の結果がNOの場合にはステップ1733で電子メールが商店等7に対し配信される。これは、最終的な判断を商店等7に委ねることが望ましいためである。しかしながら、この際には、底値Y円や実数m1値やm2値を変えて提示されるようにしてもよい。即ち、ステップ1721で演算された値段よりも多少高い値段を設定する等である。
以上により、他店よりも自店舗の方が商品等の販売価格が高かった場合であっても、ユーザからの依頼により可能な範囲で他店以下に値段を即時に下げることが可能となる。このため、タイミングを逸しない効率的な販売が可能となる。なお、各実施形態においては、必ずしもインターネットを介在させる必要はなく、LAN等であっても構成可能である。
また、センターサーバー1008とは異なるURLを有する各商店等7の自前のホームページに対し、前述したセンターサーバー1008のURLを埋め込んだアイコンを掲載し、このアイコンから前述した各機能若しくは当該機能を有するホームページにリンクするようにしてもよい。例えば、各商店等7のホームページには商品アイテムが掲載されているが、この商品を購入したいときには、ユーザ5がこの商品を購入する旨の購入ボタン(若しくは値引き交渉ボタン)をクリックする。この購入ボタンにはセンターサーバー1008のURLが埋め込まれている。このことにより、各商店等7のホームページからユーザ5は直接前述した値引き交渉や現金還元等を始めとする各機能を利用することができるようになる。また、ボタンは、各機能毎に異なる名称や表示のボタンとされることが望ましい。そして、これらのボタンとセンターサーバー1008の各機能とが直接リンクされることが望ましい。これにより、各商店等7は各実施形態で説明した諸機能を簡単に導入でき、販売促進に繋げることができる。即ち、各商店等7の自前のホームページに埋設したアイコンをクリックすることでセンターサーバー1008で提供する特定の機能(各実施形態で説明する機能)を直接呼ぶことができる。このリンクについては以下の各実施形態についても同様に適用可能である。
次に、本発明の第17実施形態について説明する。本発明の第12実施形態では、電子メールを送信することで特定の相手に対してのみ利用を限定するとして説明したが、本発明の第17実施形態ではより厳格にユーザ5を特定することで、ユーザ5や各商店等7による不正な利用方法をできるだけ避けようとするものである。
ネットオークションやフリーマーケット等では互いの顔が見えない上に、センターサーバー1008側ではユーザIDでのみ管理をしようとしているので、商品の提供者がユーザに成り済まして価格をつり上げる等の問題が生じている。かかる問題を解決するために各人を厳正に特定する必要がある。また、個人を特定できない状態であると、商品が届いても不払いされたり、支払を行ってもいつまで待っても商品が届かない等の状況が起こり易い。更に、値引き交渉等の機能の利用者や利用回数を限定することが望ましい場合がある。そこで、商店等7やユーザ5をパソコンの固有情報やバイオメトリクス情報を基に各人を識別した上で各種サービスの利用を可能とする。
この機能を有する保護ソフトウェアはセンターのサイトにダウンロードソフトの形で提供されている。
まず、ユーザ5はこの保護ソフトウェアをダウンロードしてユーザ5の使用するパソコンにインストールする。保護ソフトウェアが起動されると、保護ソフトウェアは、パソコンのハードウェア情報やそのシステム情報、更にパソコンにインストールされているソフトウェア情報等から、固有情報を検出しファイルF1としてユーザ5の使用するパソコンに保存するようになっている。
固有情報としては、例えばパソコン本体の情報、CPUの情報、PCI情報、MACアドレス、ハードディスクの情報、OS情報、メールアドレス、IPアドレス、IPv6アドレス(Internet Protocol version 6)、cookie、SCSI情報、ソフトウェア又はファイルシステム情報等である。
そして、パソコン本体の情報としては、例えば富士通製パソコンならばFMVT423B、NEC製パソコンならばPC9821Xa16W30等のパソコン型式等であり、既存のハードウェア情報からソフトウェアで取得可能な情報である。但し、この型式は必ずしもフル型式である必要はなく、PC9821、FMV等の一部情報であってもよい。また、ハードディスクドライブの情報としては、例えばハードディスクドライブの容量や記憶されているソフトウェアの名称等である。
更に、OS情報としては、例えばWindows(登録商標)95のインストール時に設定されたユーザ名、プロダクトID番号、OSのインストール実行日時等である。このOSのインストール実行日時を用いる場合には、例えばOSのインストールされた基本ドライブの各ディレクトリの更新日時を参照することで可能である。
また、固有情報としてメールアドレス、IPアドレス、cookie情報、SCSI情報等を用いる場合には、他のパソコン等でも同一となる可能性があるため、ハードウェア情報等と組み合わせて用いるのが望ましい。
このように、固有情報としては、あくまで本発明のために改めて記録され、用意されるものではなく、既存のハードウェアや、既存のシステム等から読み取り可能な情報であればよい。そのため、様々なOSに対して(Win95〜XPまで)固有情報を検出可能となっている。なお、固有情報には、別途機器を必要とするがメモリーカード等の記録媒体に設定されたID情報や、バイオメトリクス情報等の情報を含めてもよい。また、必ずしも既存から読み取り可能な情報に限定するものではなく、新規に改造や組み込み等されることで読み取りの可能となった情報等であってもよい。
更に、固有情報としては、上記のように読み取り可能であっても、容易に変更可能なものは好ましくない。例えば、容易に、あるいは頻繁に部品の交換等が前提となっているものは好ましくない。
そして、保護ソフトウェアは、このような固有情報の内、複数個の固有情報1〜N(番号1〜Nは各固有情報に対応する番号である)を検出するようになっている。このとき、固有情報1〜Nはハッシュ値化される。但し、必ずしもハッシュ化せずにそのままデータとして使用されてもよい。
更に、これらの固有情報1〜Nに基づいて、ファイル類を暗号化、復号化するためのキーを生成するようになっている。なお、保護ソフトで検出する固有情報は、複数個が望ましいが、一つとされてもよい。
その後、ユーザ5は、画面上でユーザ情報及びユーザIDやパスワード等の入力をする。そして、センターサーバー1008に対してこの情報を送信することで登録申請を行う。なお、ユーザIDやパスワードはセンター側で自動発行されてもよい。そして、登録申請の際には、この登録申請情報がセンターサーバー1008に送信されるとともに固有情報の保存されていたファイルF1も暗号化された形で送信される。
但し、ユーザ個人の特定はこの個人の使用するパソコンから得られた固有情報だけでもほぼ特定可能なので、ユーザIDやパスワード等は必ずしも必要なものではないが、センターにおける管理のし易さ及びより一層厳格な個人の特定を考慮して設けられている。
これらの登録申請情報と固有情報とはセンター側で復号化された上で保存される。そして、これらの情報を基にセンターサーバー1008では、固有情報、ユーザID及び使用許可符号等を含むファイルF8を生成する。その後、センターサーバー1008からはこのファイルF8がユーザ5のパソコンに向けて送信される。使用許可符号はユーザ5に対してセンター側で用意した機能の利用を認めるためのパスワード等である。ユーザ5側では保護ソフトウェアが受信したファイルF8の固有情報と既にファイルF1に保存されている固有情報とが一致するか否かを判断する。そして、一致していたら使用許可符号をファイルF8から抽出してファイルF1に保存する。
ユーザ5がサイトの機能を利用するに際しては、まず該当のサイトページを開く。その後、この保護ソフトウェアのパスワード入力ボタンをクリックする。但し、保護ソフトウェアの起動が自動でされるようにしてもよい。この際に、保護ソフトウェアは、ユーザ5のパソコンから固有情報及び/又はバイオメトリクス情報を取得し、ファイルF1に保存されている固有情報と一致するか否かを比較する。そして、一致するという結果であれば、自動的に保護ソフトウェア側よりWeb側にファイルF1から抽出したユーザID、パスワードが渡される。これにより、ユーザ5は、当該サイトの機能を利用することができるようになる。
この際には、Webのデータ入力欄に自動的にデータを入力するようにしてもよいが、直接データをユーザ5のパソコンからデータベース1009側に対して送信するようにしてもよい。このことにより、ユーザID、パスワードが一致するユーザ5の保有する値引き交渉回数等がデータベース1009にて判断できる。そして、ユーザ5を明確に特定できるため、ユーザ5に対して1回だけ若しくは数回だけサーバー側の機能の利用を認める等の行為を厳格に監視できる。なお、パソコンの固有情報であってもかなりの程度厳格な利用の監視は可能であるが、バイオメトリクス情報によれば、一層個人に対する厳格な利用の監視ができる。ユーザ5の情報はセンター側で認識されているので、各ユーザは不正な行為がし難くなる。また、ユーザID(パスワード)のみについてはユーザ5に入力してもらい、このユーザIDをセンターサーバー1008に送信するようにしてもよい。このことにより、一層厳格な個人の特定が可能となる。また、ユーザIDに代えてメールアドレス等によってもよい。更に、ユーザID、パスワードを送信せずに、送信される固有情報のみで本人を特定するようにされてもよい。
次に、本実施形態の別例について説明する。
保護ソフトウェアがユーザ5のパソコンにインストールされ、起動されると、パソコンの固有情報及び/又はバイオメトリクス情報が取得される。そして、登録申請の際にこの固有情報等と画面上でユーザ5により入力されたユーザ情報及びユーザID(パスワード)とがセンターサーバー1008に送信される。センターサーバー1008側では、データベース1009にこの固有情報とユーザ情報データを保存しておく。そして、次にユーザ5がセンターサーバー1008の機能を利用するためにログインしてきた場合には、固有情報等と画面上でユーザ5により入力されたユーザIDとがユーザ5のパソコンからセンターサーバー1008に送信される。センターサーバー1008側では受信されたユーザIDと固有情報とをセンターサーバー1008に保存されていたデータと比較し、一致するか否かを見る。一致していたらユーザ5に対してセンターサーバー1008側で用意した機能の利用を認める。なお、固有情報そのものを送信してセンターサーバー1008側で保存したり、対比するのではなく、これらの固有情報を基に特定のロジックを基に一つのキーをユーザ5のパソコン側で生成し、登録申請の際にセンターサーバー1008に送信する。センターサーバー1008側では、このキーをデータベース1009に保存しておき、再びこのキーがユーザ5のパソコンから送信されてきたときにこのキーに基づく対比を行うようにしてもよい。また、ユーザIDに代えてメールアドレス等によってもよい。更に、ユーザIDを送信せずに固有情報を基に生成されたキーのみで本人を特定するようにされてもよい。
次に、本発明の第17実施形態をクレジットカード支払やログインIDの入力に適用した例について説明する。
図96は、カード情報やログインIDを本人特定のもとに使用可能とするものである。図96では、本人特定をパソコンの固有情報によって行っている。即ち、予めユーザ5が登録を行ったパソコンでのみ認証が可能となるものである。従来のネット取引では、クレジットカード番号とカードの有効期限を入力するだけで認証を可能としていたが、これでは本人認証の機能を有しないので認証は確実ではなかった。また、暗証番号を入力させるようにしても本人特定の機能を有していない点は同様であり、取引の安全が確保されているとは言えなかった。
本例では、パソコン固有情報を本人の確認用に用いたため、カード利用の際に確実に本人を特定できる。なお、パソコンではなく、携帯電話の固有情報を取得するようにされてもよい。
図96には、まず、ネット取引において、クレジットカードで支払をしようとする本人が利用するパソコンをセンター側に登録する処理について説明する。図96のフローチャートにおいて、ステップ3501ではクレジットカードを利用しようとするユーザ5の有するパソコン(携帯電話でも同様)において保護ソフトウェアを起動する。この保護ソフトウェアは、予めユーザ5がセンターサーバー1008よりダウンロードする等してユーザ5の有するパソコンにインストールされている。ステップ3503では、このインストールの際に保護ソフトウェアについて、インターネットエクスプローラやネットサーフィン等のブラウザとの関連付けを実施する。この関連付けは例えばブラウザに対し保護ソフトウェアの拡張子を関連付けすることで行う。但し、この保護ソフトウェアはこのようにブラウザと独立して構成されてもよいが、ブラウザと一体化して構成されてもよい。この場合には、ブラウザとの関連付けのステップはソフトウェアの機能としてもともと組み込まれた状態で構成されるので省略されてもよい。ステップ3505では、ユーザ5の有するパソコン(携帯電話等)の固有情報を取得する。ステップ3507では、この取得したパソコン固有情報をファイルF2に保存する。
ステップ3509では、ユーザ5がパソコンの画面上に表示された登録処理ボタンをクリックする。この登録処理ボタンは保護ソフトウェア側で生成された画面上に配設されているが、センターサーバー1008よりダウンロードされたHTML文書に基づきWeb上で行うようにされてもよい。ステップ3511でセンター接続を行う。そして、ステップ3513でログインID、パスワード入力を行う。このログイン画面は、保護ソフトウェア側で生成した画面において行われてもよいが、Webよりダウンロードする形でHTML上で行われてもよい。
ステップ3515では、ログイン画面に続いてダウンロードされた画面に対し、本人情報(メールアドレスを含む)を入力し、ステップ3517でクレジットカード会社名、カード番号、有効期限を入力し、ステップ3519でカード用暗証番号を入力する。但し、カード用暗証番号の入力は不要とされてもよい。ステップ3521で、これらの情報をファイルF1に保存する。
続いて、ステップ3523では、保護ソフトウェアはファイルF2に保存されているパソコン固有情報を基に暗号化キーを生成する。そして、ステップ3525でこの暗号化キーを基にファイルF1を暗号化する。暗号化は例えば共通キー方式や公開キー方式が適用されている。ステップ3527では、ファイルF2を予め定めた固定のキーを用いて共通キー方式に従い暗号化する。ステップ3529では、ファイルF1、F2をセンターに向けて送信する。ステップ3531では、センターでこのデータを受信し、ステップ3533で復号化する。この復号化は、前述した暗号化の逆の手続による。ステップ3535でセンターデータベース1009に受信したデータを保存する。ステップ3537では、念のため本人に対し登録完了の旨のメールを発信する。以上により、ログインIDやカード情報及び個人情報と、このユーザ5が使用するパソコンの情報とがセンターサーバー1008に登録される。
次に、クレジットカードを利用してWeb上で支払する処理について図97及び図98を基に説明する。
図97のステップ3541において、パラメータファイルには、a社サイトのURL1及び保護ソフトウェア起動用命令が予め挿入されており、ダウンロード可能なようになっている。a社サイトは、例えば通信販売サイト等のクレジットカードでの支払の存在するサイトや、特定のログインIDでないと利用できないサイト等である。ステップ3543では、ユーザ5がユーザ5のパソコンにおいて、a社サイトよりWebページ(ログインページ)をダウンロードする。ステップ3545において、ログインID、パスワードを入力し、ステップ3547でこの入力されたデータをセンターに向けて送信する。ステップ3549では、センター側でこの送信されたデータを受信する。ステップ3551では、ログインID、パスワードをセンターサーバー1008において取得する。
続いて、ステップ3553では、ログインページにリンクされた情報入力ページがダウンロードされる。この情報入力ページについて、ステップ3555で本人情報(メールアドレスを含む)を入力する。そして、続いてステップ3557でカード会社、カード番号、有効期限を入力し、ステップ3559でカード用暗証番号を入力する。但し、カード用暗証番号の入力は不要とされてもよい。また、後述するように、情報の入力はユーザ5に対し登録時のみ行ってもらい、その後の処理はセンターサーバー1008に保存されたデータ情報を用いることで入力を省略するようにされてもよい。
ステップ3561では、これらの情報を暗号化し、ステップ3563でセンターに対しデータ送信する。
一方、ステップ3565では、受信されたデータの中からログインIDを取得し、ステップ3567でパラメータファイルにこのログインIDを挿入する。ステップ3569では、センターよりユーザ5のパソコンに対しこのパラメータファイルをダウンロードする。パラメータファイルのダウンロードは、例えばWebページ(ログインページ)のHTMLソースにこの旨の命令を記載しておくことで行う。ステップ3571では、ユーザ5のパソコンでパラメータファイルを受信する。このとき、ステップ3573でブラウザを介し、パラメータファイルに含まれる保護ソフトウェアの起動命令が実行される。
その後、ステップ3575では、起動した保護ソフトウェアによりパソコン固有情報が自動で取得される。そして、ステップ3577でファイルF2に保存されている固有情報と一致しているか否かが判断される。一致している場合には、ユーザ5本人が登録の際に使用したパソコンと同一のものなので、本人と認めることができる。このため、ステップ3579に進み、センターへ向けてa社サイトのURL1、固有情報、ログインIDを送信する。一方、ステップ3577でファイルF2に保存されている固有情報と一致していないと判断されたとき、ステップ3580でエラー表示を行う。登録時のパソコンの情報と異なるためである。但し、この固有情報の対比は厳正に一致するか一致しないかで判断されてもよいが、それぞれの固有情報に対し重み付けの点数を設定し、該当する固有情報が存在した場合にはその点数を加算し、一方存在しない場合には0点としてその重み付けの合計点数をまず算出し、その合計に対するすべての固有情報が一致した場合の重み付けの度合いを評価するようにされてもよい。
ステップ3579で送信されたデータはステップ3581でセンターにおいて受信される。そして、ステップ3583では、次のWebページ(例えば認証確認待ち状態ページ)をダウンロードする。ステップ3585では、センターにおいてログインID、パスワードの一致を判断する。これは、ステップ3551からステップ3563までの処理ルートで送信されたデータの登録者と、ステップ3565からステップ3580までの処理ルートで送信されたデータの登録者とが一致することをセンター側で確認するためである。
一致するデータが存在した場合には、ステップ3587でセンターサーバー1008のデータベース1009にアクセスする。そして、ステップ3591で受信データからカード情報を抽出する。一方、一致しなかった場合にはステップ3589で認証不許可とする。この場合には、カードでの決済が認められない。ステップ3591で抽出されたカード情報は、ステップ3593でセンターデータベース1009に登録済のデータと一致するか否かが判断される。一致したデータの存在する場合には、ステップ3595に進み、登録済のパソコン固有情報が存在しているか否かが判断される。そして、ステップ3599で受信された固有情報が登録済のパソコン固有情報と一致している場合には、ユーザ5本人のパソコンであると認められる。ステップ3603では、a社サイトのURL1が一致しているか否か判断され、一致している場合は、ステップ3605で認証が許可される。このとき、センターサーバー1008側では、a社サイトにおいてユーザ5が購入等をしたものと判断できる。但し、a社サイトが同時にセンターサーバー1008としての機能を有する場合にはこのサイトのURLの判断は不要である。
一方、ステップ3603で一致していない場合には、ステップ3607で認証は許可されない。また、ステップ3593の判断で、カード情報がセンターデータベース1009に登録済のデータと一致しない場合には、ステップ3597で認証は許可されない。但し、ステップ3595で登録済のパソコン固有情報が存在しない場合には、ユーザ5がカード情報のみで(パソコン固有情報によることなく)カード決済を希望していると判断されるので、そのままステップ3601で認証を許可する。
以上により、パソコンや携帯電話等の固有の情報を基に本人確認をした上でカード決済やログインIDの使用が可能なので、カード使用の際の安全性が向上する。
なお、a社サイトとセンターサーバー1008とは同一のサイトとして構成されてもよいし、異なるサイトとして構成されることも可能である。同一のサイトとして構成された場合には、a社サイトのURL1の情報は不要とされてもよい。異なるサイトとして構成された場合には、ユーザ5により申請のあったログインID、パスワードの情報、本人情報、カード情報等及び購入のあった商品名、商品コード、金額等をa社サイト側よりセンターサーバー1008に向けて送信してセンターサーバー1008側でオーソリ認証を行う必要がある。また、オーソリ認証の結果をセンターサーバー1008側よりa社サイト側にデータ送信するために必要なソフトウェアがa社サイト側に導入される必要がある。但し、オーソリ認証の結果は、センターサーバー1008側でa社に対し閲覧可能にWeb上で公開されるようにされてもよい。
なお、異なるサイトとして構成された場合の別構成として、ユーザ5により申請のあったログインID、パスワードの情報、本人情報、カード情報等及び購入のあった商品名、商品コード、金額等をパラメータファイルに挿入した上でダウンロードさせたり、HTML文書として引き継ぐように処理されてもよい。
更に、ログインIDは省略することも可能である。この場合、センターサーバー1008側では、固有情報の一致とカード番号の一致等の組み合わせで本人のカード使用であることを確認可能である。
また、これとは逆に本例の中からログインIDを残し、カード情報(や本人情報)を不要とすることも可能である。即ち、ログインIDの入力に際して、パソコンの固有情報が一致したものにだけログインが有効となるというような形で利用可能である。
次に、本人確認をバイオメトリクス情報により行う場合について図99及び図100のフローチャートを基に説明する。但し、バイオメトリクス情報に代えてICタグから電磁波を介して得た情報を用いるようにしてもよい。バイオメトリクス情報の例として指紋について説明するが、本人認証のために指紋、筆跡、声紋、網膜(眼底の毛細血管の模様を用いる)、虹彩、手の大きさや形、手のひらの紋様、手の甲の血管、顔の形(2次元位置データとして照合、3次元計測による照合)、キーストローク、マウス操作の癖、遺伝子情報等によるバイオメトリクス情報を用いてもよい。また、バイオメトリクス情報を用いる以外にも、本人確認データとしてスマートメディア、メモリースティック、SDカード等のように、個別認証の可能なID付記録媒体等を用るようにしてもよい。これらのID付記録媒体には、予め各記録媒体を識別するための認証符号IDが付与された形で記録媒体内に記憶されている。
図99の登録処理において、図96と同一のステップについては同一の符号を付して説明を省略する。ステップ3651においては、指紋情報等のバイオメトリクス情報を指紋入力装置等より取得する。ステップ3653では、指紋データの内から、この指紋を特徴付ける特徴データを抽出する。この特徴データは、サンプリングされたデータや例えば指紋を特徴付ける箇所数点の位置関係情報等である。そして、この特徴データをステップ3521でファイルF1に保存する。ステップ3655では、パソコン固有情報を基に生成された暗号化キーを利用して本人情報及びカード情報を暗号化する。そして、この本人情報及びカード情報をステップ3657でファイルF1、F2と共にセンターに送信する。
次に、バイオメトリクス情報を用い、クレジットカードを利用してWeb上で支払する処理について図100を基に説明する。なお、図97及び図98と同一要素の部分については同一の符号を付して説明を省略する。また、図100のフローチャートは、図97及び図98と同一の処理フローの部分については省略をしている。即ち、図97のステップ3573以降の処理フローを抜粋し、かつ図97及び図98と異なる所を中心に説明する。
図100のステップ3573において、保護ソフトウェアが起動されるとステップ3575で固有情報が取得され、ステップ3577でファイルF2に保存されている固有情報と比較される。一致していたら、ユーザ5所有のパソコン等であると判断され、ステップ3701に進み、指紋情報等のバイオメトリクス情報を取得する。そして、ステップ3703で、特徴データを抽出し、ステップ3704でファイルF1に保存された特徴データと一致するか否か判断される。一致しない場合にはステップ3580でエラーとなる。一方、特徴が一致した場合には、ステップ3705でこのファイルF1に保存された特徴データを基に暗号化キーを生成する。特徴の一致は完全一致の他、特徴が近似範囲に属すると判断されるものも含む。暗号の方式は共通キー方式や公開キー方式等である。この暗号化キーは、例えば、特徴データをシリアルに並べ、その内からサンプリングしたデータを一定のルールに従い並べ替えることで生成したり、この特徴データのシリアルを所定の論理式に従い演算した結果の数値を用いることで生成する。ステップ3707では、この暗号化キーを基にパソコン固有情報を暗号化し、ステップ3709でセンターへこのパソコン固有情報データを送信する。
センター側では、ステップ3591で受信データからカード情報を抽出し、ステップ3593でこのカード情報がセンターデータベース1009に登録済のデータと一致するデータがあると判断されたとき、ステップ3595でセンターデータベース1009に既に登録済の固有情報が存在するか否か判断される。そして、存在する場合にはステップ3711で、センターデータベース1009に登録された特徴データを基に復号化キーを生成する。ステップ3713では、この復号化キーを基にパソコン固有情報を復号化する。ここで、復号化ができれば、本当に本人が認証を請求していると判断できる。固有情報が登録済のパソコン固有情報と一致すれば本人使用のパソコンであると判断できる。
なお、上述した処理に代えて、図示は省略するが、ステップ3523においては、ファイルF1に保存されたバイオメトリクス情報の特徴データを基に暗号化キーを生成することも可能である。この場合、ステップ3525では、この暗号化キーを基にファイルF2を暗号化し、ステップ3655では、この暗号化キーを基に本人及びカード情報を暗号化する。ステップ3527では、ファイルF1を共通キー方式で暗号化する。
この場合には、ステップ3573で保護ソフトウェアが起動すると、まず、指紋等のバイオメトリクス情報を取得し特徴データが生成される。そして、この特徴データがファイルF1に保存されているデータと一致するか否か判断される。一致している場合には、ファイルF1の特徴データを基に復号化キーが生成され、この復号化キーを用いてファイルF2が復号化される。その後、パソコン固有情報が取得され、ファイルF2に保存されている固有情報と一致しているか否か判断される。一致している場合にはファイルF1を基に暗号化キーが生成され、この暗号化キーを用いてファイルF2が暗号化される。その後、ステップ3709以降に進むように処理されてもよい。
また、上述した処理に代えて、図示は省略するが、本人及びカード情報を暗号化するのがファイルF1のバイオメトリクス情報の特徴データを基としてキー生成された暗号化キーで行われた場合において、このファイルF1のバイオメトリクス情報の特徴データをファイルF2のパソコン固有情報を基としてキー生成された暗号化キーで行われるようにされてもよい。
更に、暗号化の順序を本人及びカード情報を暗号化するのをファイルF2のパソコン固有情報を基としてキー生成された暗号化キーで行うこととし、ファイルF2のパソコン固有情報をファイルF1のバイオメトリクス情報の特徴データを基としてキー生成された暗号化キーで行われるようにされてもよい。
更に、本人及びカード情報については、ユーザ5のパソコンからセンターサーバー1008に対し送信するだけなので、ネット取引によ使用されているSSL方式による暗号化がされるようにしてもよい。
更に、ステップ3599では、パソコン固有情報の一致を判断したが、これに代えてバイオメトリクス情報の特徴データが一致するか否かを判断するようにしてもよい。このときは前述の処理に代えてステップ3705では、ファイルF2のパソコン固有情報を基に暗号化キーを生成する。そして、ステップ3707では、この暗号化キーを基にファイルF1のバイオメトリクス情報の特徴データを暗号化する。ステップ3709では、センターへこの特徴データを送信する。その後、ステップ3595では、登録済のバイオメトリクス情報の特徴データが存在するか否か判断される。そして、ステップ3711では、センターデータベース1009に登録された固有情報を基に復号化キーが生成される。ステップ3713では、この復号化キーを基にファイルF1のバイオメトリクス情報の特徴データが復号化される。そして、ステップ3599では、受信されたバイオメトリクス情報の特徴データが登録済の特徴データの中に一致するデータがあるか否か判断される。
更に、上述では、暗号化をパソコン固有情報又はバイオメトリクス情報の特徴データを基にする旨説明したが、予め定めた特定のキーを基に共通化キー方式や公開キー方式にて処理されるようにされてもよい。
更に、ファイルF1及び/又はファイルF2は、登録時及びカード利用時共に、ユーザ5のパソコンにおいて、生成したら送信してしまい、ユーザ5のパソコンにデータとして残さないようにしてもよい。この際には、センターサーバー1008側にてパソコン固有情報又はバイオメトリクス情報の特徴データの一致を判断することで本人確認の処理が行われる。この場合、ステップ3577とステップ3704の一致判断は不要となる。
このとき、固有情報、バイオメトリクス情報や特徴データはユーザ5のパソコンに残らないのでパソコンが盗まれたとしても安全である。このため、犯罪の一手法として他人の手指を切断してその指紋を利用する等の犯罪はできなくなる。更に、指紋データ等そのものを保存しておいたり送信することはないので指紋データ等が盗まれることもなく安全である。フィッシング詐欺をしてカード情報を盗んだとしても利用できなくなる。
なお、ファイルF2については、登録時及びカード利用時共にユーザ5のパソコンに残し、カード利用時に、保護ソフトウェアの取得した固有情報データとファイルF2に保存された固有情報の一致を判断する。その後、この一致を見てからバイオメトリクス情報を取得し、ファイルF1を生成して送信する。センターサーバー1008では、パソコン固有情報及び/又はバイオメトリクス情報の特徴データの一致(近似を含む)を判断する。かかる方法とした場合には、送信側での固有情報による本人確認、受信側での固有情報やバイオメトリクス情報の特徴データによる本人確認が行える上に、バイオメトリクス情報の特徴データはユーザ5のパソコンに残らないので望ましい。なお、バイオメトリクス情報の特徴データについては、バイオメトリクス情報そのものと置き換えられることも可能である。
以上により、バイオメトリクス情報とパソコン固有情報を用い、本人であること、及び予め登録のあったパソコンでの使用を条件にクレジットカードの認証を厳格に行うことができる。但し、バイオメトリクス情報の特徴データを暗号化キーや復号化キー生成のために利用するのではなく、バイオメトリクス情報そのもののデータ、若しくはバイオメトリクス情報の特徴データについて、センターサーバー1008において既に登録時において保存されているこれらのデータと、カード利用時にユーザ5から送信されたこれらのデータとを対比し、一致するか否かを判断することで本人確認がされてもよい。
次に、本人確認を固有情報とバイオメトリクス情報の特徴データとからシリアル番号を作ることにより行う場合について図101、図102及び図103のフローチャートを基に説明する。但し、バイオメトリクス情報に代えてICタグから電磁波を介して得た情報を用いるようにしてもよい。
なお、図96、図97及び図98と同一処理の部分については同一の符号を付して説明を省略する。また、図102及び図103は、図97及び図98と同一の処理フローの部分については簡略のためステップ自体を省略をしている。即ち、図97のステップ3573以降の処理を抜粋し、かつ図97と異なる所を重点的に説明する。
図101において、ステップ3751では、指紋情報等のバイオメトリクス情報を取得可能か否かが判断される。そして、バイオメトリクス情報を取得可能な装置が存在している場合には、ステップ3753で指紋情報等のバイオメトリクス情報を取得し、ステップ3755で特徴データを抽出する。ステップ3756では、この特徴データをファイルF2に保存する。ステップ3757では、ファイルF2に保存された固有情報と特徴データを基に所定のロジックに従いシリアル番号を生成する。この所定のロジックは、例えば予めサンプリング的に一定数毎にデータを抽出し、この抽出したデータをシリアルに連続して並べて一つの番号を作成する等である。そして、生成したシリアル番号をステップ3521でファイルF1に保存する。
一方、ステップ3751で指紋情報等のバイオメトリクス情報を取得できないと判断された場合には、ステップ3759に進み、ファイルF2に保存された固有情報と特定の数値を基に所定のロジックに従いシリアル番号を生成する。この特定の数値は、特徴データの代わりに予め定めた数値を準備したものである。所定のロジックはステップ3757のものと変わらないものでよい。
そして、生成したシリアル番号をステップ3521でファイルF1に保存する。
このシリアル番号は、バイオメトリクス情報と固有情報とから生成されており、バイオメトリクス情報や特徴データそのもののデータではないので通信途上でデータが盗まれたとしても安全である。また、バイオメトリクス情報だけで認証するものではないので、犯罪の一手法として問題となっている他人の手指を切断してその指紋を利用する等の犯罪はできなくなる。フィッシング詐欺をしてカード情報を盗んだとしても利用できなくなる。
但し、バイオメトリクス情報と固有情報との双方のデータを利用するのではなく、バイオメトリクス情報の特徴データだけを用いて所定のロジックに従いシリアル番号を生成するようにしてもよい。この場合であっても、バイオメトリクス情報の特徴データそのもののデータではないので通信途上でデータが盗まれたとしても安全である。なお、ステップ3523の処理は、パソコン固有情報ではなく、パソコン固有情報及び/又は特徴データを用いて暗号化キーを生成するようにしてもよい。
次に、シリアル番号を用い、クレジットカードを利用してWeb上で支払する処理について図102及び図103を基に説明する。なお、図97及び図98と同一要素の部分については同一の符号を付して説明を省略する。また、図102及び図103のフローチャートは、図97及び図98と同一の処理フローの部分については省略をしている。即ち、図97及び図98のステップ3573以降の処理フローを抜粋し、かつ図97及び図98と異なる所を中心に説明する。
登録処理と同様に、ダウンロードされたHTML文書に連動してステップ3573において保護ソフトウェアが起動されると、ステップ3575でパソコン固有情報が自動で保護ソフトウェアにより取得される。また、ステップ3751でバイオメトリクス情報を取得可能ならば、ステップ3753でバイオメトリクス情報が取得され、ステップ3755で特徴データが抽出される。そして、ステップ3760において、この特徴データとファイルF2に保存されている特徴データとが対比される。一致していなければステップ3760でエラーとなり、一致していれば、その後、ステップ3757において、ファイルF2に保存された固有情報と特徴データを基に所定のロジックに従いシリアル番号が生成される。
一方、ステップ3751でバイオメトリクス情報を取得可能でないならば、ステップ3759でファイルF2に保存された固有情報と特定の数値との間でシリアル番号が生成される。そして、ステップ3801では、この生成されたシリアル番号がファイルF2に保存された固有情報を基に暗号化される。そして、次にステップ3803でファイルF2が共通化キー方式で暗号化される。ステップ3805では、シリアル番号とファイルF2とがセンターに向けて送信される。
センター側でこれらのデータを受信した後、ログインIDの一致とカード情報の一致とが判断される。その後、ステップ3595で既に登録済のパソコン固有情報が存在するか否か判断される。登録済のパソコン固有情報が存在しない場合には、ユーザ5がカード情報のみでカード決済を希望していると判断されるので、そのままステップ3601で認証を許可する。但し、ここでは、既に登録済のシリアル番号が存在するか否かで判断されるようにしてもよい。続いて、ステップ3807では、ファイルF2を共通化キー方式のもとに復号化する。そして、ステップ3809では、ファイルF2に保存された固有情報を基に復号化キーを生成し、ステップ3811でこの復号化キーを基にシリアル番号を復号化する。
その後、ステップ3599でパソコン固有情報の一致が判断され、ステップ3813では、受信されたシリアル番号が登録済のシリアル番号と一致するか否か判断される。シリアル番号が一致する場合には、ステップ3603に進み、一方、一致しない場合にはステップ3607で認証は許可されない。
以上により、シリアル番号は、バイオメトリクス情報と固有情報とから生成されており、ユーザを確実に特定可能である。また、バイオメトリクス情報や特徴データそのもののデータではないので通信途上でデータが盗まれたとしても安全である。
次に、別例として、登録済のデータのあることを保証するシリアル番号をセンターサーバー1008側で生成し、このシリアル番号を一旦ユーザの所有するパソコン等に保存しておき、クレジットカード等を使用する際にこのシリアル番号を参照することで本人確認をする方法について図104〜図108を基に説明する。
なお、図96、図97と同一の要素については同一の符号を付して説明を省略する。
図104において、保護ソフトウェアをインストールし、ステップ3509で登録ボタンをクリックする。但し、この登録処理は、インストールに続けて行ってもよいし、保護ソフトウェアの再起動後に行うようにされてもよい。ステップ3513では、ログインページが表示され、ステップ3515では、この表示されたログインページに入力を行う。そして、ステップ3851ではセンターに向けてログイン情報の送信がされる。ステップ3853では、センターのデータベース1009中にログインID、パスワードの一致するものがあるか否か判断される。
ログインID、パスワードの一致するものが存在しない場合には、ステップ3855で新規登録となり、ステップ3857以降の登録処理が行われる。新規登録が行われない場合には、ステップ3859で処理を終了する。一方、ステップ3853で既に、センターのデータベース1009中にログインID、パスワードの一致するものがあった場合には、ステップ3861に進み追加処理が行われる。追加を希望しない場合には、ステップ3863において、登録済のデータが表示される。
新規登録又は追加の場合には、ステップ3865でクレジットカード会社名、クレジットカード番号、暗証番号、有効期限、個人情報入力ページにデータを入力する。但し、センターサーバー1008側において、既にクレジットカードに関する情報が存在しているような場合には、例えばクレジットカード番号のみが入力されるようにしてもよい。そして、ステップ3867で入力されたデータをファイルF1に保存する。その後、ステップ3869では、パソコン固有情報を基に暗号化キーを生成し、ステップ3871でこの暗号化キーを利用してファイルF1を暗号化する。
また、ステップ3873ではファイルF2を共通キー方式で暗号化する。そして、ステップ3875でセンターへ送信する。ステップ3877では、これらのデータをセンターで受信する。ステップ3879では、ファイルF2を復号化し、ステップ3881でファイルF2に保存されていたパソコン固有情報をセンターデータベース1009に保存する。ステップ3883では、ファイルF1を復号化できたか否かが判断される。復号化できなければ、ステップ3887でエラーとされ、一方復号化できたならば、ステップ3885でファイルF1より抽出したクレジットカード番号等をセンターデータベース1009に保存する。その後、ステップ3889では、固有のシリアル番号を自動生成し、ステップ3891でファイルF8の中にこのシリアル番号を入れると共にセンターデータベース1009にも保存をする。固有のシリアル番号は、最低限各パソコンを区別できればよ登録順に任意に割り付けた符号等とされてもよい。但し、ログインID等のデータと共にシリアル化されてもよい。
ステップ3893では、センターデータベース1009に保存の固有情報を取得し、ファイルF9を生成し、このファイルの中に固有情報を保存する。ステップ3895では、ファイルF8、F9を暗号化してユーザ5の有するパソコンに送信する。そして、ステップ3897では、ユーザ5の有するパソコンにおいて、ファイルF2とF9のパソコン固有情報が一致するか否かが判断される。そして、一致していたならば、ステップ3899でシリアル番号をファイルF8より抽出してファイルF1に保存する。一方、一致しなかったときはステップ3901でエラーとする。
次に、ユーザがクレジットカードを利用する際のフローについて図106、図107及び図108を基に説明する。以下、パラメータファイルには、保護ソフト起動用命令を予め挿入しているとして説明するが、パラメータファイルには、商品コード、サイト情報、保護ソフト起動用命令を予め挿入するようにしてもよい。
図106、図107及び図108において、ステップ3951では、HTML文書(例えば商品購入における購入ページ)をダウンロードする。ステップ3953では、このHTML文書のログインID、パスワード入力部がユーザ5のパソコン等に表示される。ステップ3955では、ユーザ5がこのパスワード入力部に対しデータ入力を行い、ステップ3957で送信する。その後、ステップ3958では、センターサーバー1008において受信されたHTML文書中よりログインID、商品コード、サイト情報を抽出してパラメータファイルに挿入する。
ステップ3959では、このパラメータファイルをダウンロードし、ステップ3961で保護ソフトウェアを起動する。そして、ステップ3963でこの保護ソフトウェアがユーザ5のパソコンにおいてパソコン固有情報を取得する。続いて、ステップ3965でファイルF2を共通キー方式で復号化する。ステップ3967では、パソコン固有情報の一致を判断し、一致していないときにはステップ3971でエラー表示する。一方、一致しているときには、ステップ3969でファイルF2のパソコン固有情報を基に復号化キーを生成する。
そして、この復号化キーを基にステップ3973でファイルF1を復号化する。ステップ3975では、パラメータファイルよりログインID、サイト情報、商品コードを取得し、ステップ3977では、ファイルF1中にこのログインID、サイト情報、商品コードと記録日時とを記録する。但し、サイト情報に代えて特定の異なるデータとして生成された符号がその都度発行されるようにしてもよい。
その後、ステップ3979では、ファイルF2のパソコン固有情報を基に暗号化キーを生成し、ステップ3981で、この暗号化キーを用いてファイルF1を暗号化する。ステップ3983では、ファイルF2を共通キー方式で暗号化する。ステップ3985では、これらのファイルF1、F2をセンターに送信し、ステップ3987では、センターで受信をする。
その後、センターサーバー1008側では、ステップ3989においてファイルF2をまず共通キー方式で復号化する。ステップ3991では、このファイルF2のパソコン固有情報を基に復号化キーを生成し、ステップ3993でファイルF1を復号化する。そして、ステップ3995では、サイト情報、シリアル番号、ログインID、商品コード等を抽出する。ステップ3996では、抽出したデータをセンターサーバー1008のメモリー内に保存する。
一方、ステップ4001では、センターサーバー1008に送信されたHTML文書中よりログインID、パスワード、商品コード、サイト情報を引き継ぐ。ステップ4003では、センターデータベース1009中にログインID、パスワードの一致するデータがあるか否か判断される。一致するデータが存在しない場合には、ステップ4005で終了する。あるいは、新規登録画面に進む。そして、ステップ4007では、情報再入力省略モードの設定がされているか否か判断する。情報再入力省略モードの設定は、改めてクレジットカード等の情報を入力させるユーザ5の手間を省略させるため、及びクレジットカードの情報の漏洩防止のために設けられている。なお、この情報再入力省略モードの設定は、本例以外でも同様に適用可能である。
情報再入力省略モードの設定がされていない場合には、ステップ4009でクレジットカード会社名、クレジットカード番号、有効期限、暗証番号入力、個人情報入力画面が表示される。ステップ4011では、この画面に対しデータ入力を行い、ステップ4013で送信する。このデータはステップ4015で受信される。ここに、ステップ4017において、ユーザ5が複数回のデータ入力を繰り返し行おうとしても安全確保のため許可されない。
ステップ4019で入力データの一致が判断され、一致していなければステップ4023で認証は許可されない。ステップ4021では、暗証番号の判断が可能なものにあっては、暗証番号の一致が判断される。そして、暗証番号が一致しない場合にはステップ4023で認証は許可されない。
一方、暗証番号が一致した場合には、ステップ4025に進み、データベース1009中に当該ログインIDについてシリアル番号の登録があるか否かが判断される。データベース1009中にシリアル番号の登録がなかった場合には、個人認証の判断をしない状態のままステップ4027で認証が許可される。シリアル番号の登録がない以上、ユーザ5がカード決済の上で個人認証の判断までは必要ないと判断していると考えられるためである。
一方、データベース1009中にシリアル番号の登録が存在する場合には、ステップ4029に進み、ステップ3996においてメモリーに保存されたデータと対比が行われ、このメモリーの中に当該ログインIDに一致するデータが存在するか否か判断される。存在しない場合には、まだステップ3987での受信がされていない状況の可能性もあるので、ステップ4031でタイマーのカウントを行い、ステップ4033で設定時間を超えたか否かが判断される。この設定時間までは、保護ソフトウェアからのデータ送信を待つためである。そして、設定時間を超えた場合にはステップ4035で認証は許可されない。一方、設定時間に満たない場合には、ステップ4029からの処理が繰り返される。
メモリーの中に当該ログインIDに一致するデータが存在する場合には、ステップ4037でサイト情報が一致しているか否か判断される。但し、この判断は、商品購入したサイトとセンターサーバー1008のサイトとのURLが異なる場合において行われ、同一の場合にはサイト情報の判断自体省略可能である。サイト情報が一致していない場合には、データベース1009中に他に一致するものが存在する可能性があるので、ステップ4039でデータベース1009中のサイト情報をサーチする。ステップ4041で一致するデータが見つからなかった場合には、まだステップ3987での受信がされていない状況の可能性もあるので、ステップ4031でタイマーのカウントを行い、ステップ4033で設定時間を超えたか否かが判断される。
サイト情報の一致したデータが存在した場合には、ステップ4043に進み、メモリー中に保存されたデータとデータベース1009に保存されたデータとの間で、商品コードの一致が判断される。商品コードが一致するものが存在しなかった場合には、ステップ4045でデータベース1009中の商品コードをサーチする。ステップ4047で一致するデータが見つからなかった場合には、まだステップ3987での受信がされていない状況の可能性もあるので、ステップ4031でタイマーのカウントを行い、ステップ4033で設定時間を超えたか否かが判断される。
商品コードの一致したデータが存在した場合には、ステップ4049に進み、データベース1009に保存のシリアル番号と対比される。対比の結果、一致している場合にはステップ4053に進みカードの有効期限が判断される。シリアル番号が一致しない場合や有効期限を超えている場合にはステップ4051で認証は許可されない。ステップ4053でカードが有効期限内のときにはステップ4055で認証が許可される。
なお、図104〜図108の例では、パソコン固有情報のみを用いて説明したが、上述したバイオメトリクス情報を用いた例のように、パソコン固有情報とバイオメトリクス情報との組み合わせに対しシリアル番号を発行してもよい。このとき、ユーザ5のパソコンにおいて、カード利用時には、パソコン固有情報の一致を見ると共にバイオメトリクス情報の一致を見ることが望ましい。あるいは、パソコン固有情報の代わりにバイオメトリクス情報を用い、これに対しシリアル番号を発行するようにされてもよい(図示略)。このとき、ユーザ5のパソコンにおいて、カード利用時には、バイオメトリクス情報の一致を見ることが望ましい。
次に、本発明の第18実施形態について説明する。本発明の第18実施形態を図59及び図60のフローチャートを基に説明する。本発明の第18実施形態は、ユーザ5がセンターサーバー1008に入り、センターサーバー1008側で用意された各機能を利用する場合には、ログインIDとパスワードとが必要とされるが、このログインIDを忘れた場合の対処方法についてである。ユーザ5がステップ1801において「ログインIDを忘れた」ボタンをクリックする。このとき、ステップ1803では、パスワードを覚えているか否かがWebを介してユーザ5に対して問い合わせされる。ユーザ5がパスワードを覚えている場合には、ステップ1805に進み、Web画面にてメールアドレス、電話番号、氏名(法人名)、生年月日、性別及びパスワードを入力する。
その後、ステップ1807でセンターサーバー1008に向けて、ユーザ5により入力された情報が送信される。ステップ1809では、センターサーバー1008側で受信されたデータについて、データベース1009に一致したデータが存在するか否かが判断される。存在する場合には、ステップ1813に進み、データベース1009から一致したユーザ5のログインIDを抽出する。そして、ステップ1815では、インターネット上のWeb画面を介してユーザ5に対してログインIDが表示されるので、ユーザ5はこれを確認する。一方、ステップ1809でデータベース1009に一致したデータが存在しなかった場合には、ステップ1811でユーザ5に対して再入力を依頼する。再入力のあった場合には、ステップ1805からの処理が繰り返される。
また、ステップ1803でユーザ5がパスワードを覚えていなかった場合には、ステップ1817に進み、Web画面にてメールアドレス、電話番号、住所、氏名(法人名)、生年月日、性別を入力する。但し、メールアドレスは省略されてもよい。その後、ステップ1819でセンターサーバー1008に向けて、ユーザ5により入力された情報が送信される。ステップ1821では、センターサーバー1008側で受信されたデータについて、データベース1009に一致したデータが存在するか否かが判断される。存在する場合には、ステップ1825に進み、データベース1009から一致したユーザ5のメールアドレスを抽出する。そして、ステップ1827では、このメールアドレスへの電子メール文に「URL http://aaaa.・・・に行ってログインIDを確認して下さい。」と記載する。そして、ステップ1829では、センターサーバー1008側では、待ち受け状態符号を設定し、日時をデータベース1009に記録する。待ち受け状態符号を設定するのは、正当な手順を踏まない不正アクセスを阻止するためである。その後、ステップ1831では、電子メール送信を行う。ステップ1833でユーザ5が電子メールを受信し、このユーザ5は、ステップ1835で、http://aaaa.・・・に行ってHTML文書をダウンロードしてユーザ5のメールアドレス、電話番号を入力する。このURLへのジャンプは電子メールに記載されたURLをクリックすることで行うことができる。この電子メールが届き、その後の処理を行う人は、真のユーザであると判断できる。
ステップ1837では、メールアドレス、電話番号をセンターサーバー1008に向けて送信する。センターサーバー1008側では、ステップ1839においてメールアドレス、電話番号の一致したユーザ5のログインIDを抽出する。但し、このときにパスワードも抽出するようにしてもよい。そして、ステップ1841では、ステップ1829で記録された日時をチェックして、7日以内か否か判断する。このように期間を限ったのは、不正なアクセスを阻止するためである。
7日以内のときステップ1843で待ち受け状態符号が設定されているか否かが判断される。7日を過ぎている場合には、ステップ1851で「7日を過ぎています。もう一度最初から手続をお願いします。」とメッセージを出す。待ち受け状態符号が設定されている場合には、ステップ1845で、インターネット上のWeb画面を介してユーザ5に対してログインIDが表示されるので、ユーザ5はこれを確認する。但し、このときログインIDだけでなくパスワードも同時に表示されるようにしてもよい。一方、待ち受け状態符号が設定されていなかった場合には、ステップ1849で、「最初から手続をお願いします。」とユーザ5に対してメッセージ表示する。ステップ1847では、待ち受け状態符号を解除する。
以上により、ユーザ5はログインIDを忘れた場合であっても簡単、かつ確実に再び入手が可能となる。
次に、本発明の第19実施形態について説明する。本発明の第19実施形態のホームページの画面例を図61に示す。本発明の第19実施形態では、指定あるいは検索されたある商品について、他の商店等7の同一の商品との間で価格を比較可能にすると共に値引き交渉をも可能とすることで値引き交渉の際の最低価格の推測をし易くしたものである。また、ウィンドウショッピングの要素をも併せて取り入れたものである。
図61において、閲覧モード選択ボタン2001において、直接価格対比のページか、若しくはウィンドウショッピングのページかを選択する。図61の例では、下段のHTML画面欄2003に直接価格対比のページが選択されて表示された状態である。商品名入力又は検索欄2005に入力された商品名「パソコンPC9821V13」はユーザ5により指定されたもの、あるいは検索の結果によるものである。そして、この商品についてはA商店、B商店、C商店等が販売を行っており、その販売価格がHTML画面欄2003に示されるようになっている。これらの商店は、通常表示は商店名順であるが、表示順選択欄2007により売れ行き順、価格の安い順等を選択することで、これらに従って絞り込まれたデータが表示されるようにしてもよい。閲覧モード選択ボタン2001、商品名入力又は検索欄2005、表示順選択欄2007等を含む画面上段部分2013は、HTMLにて構成されている。
また、A商店の項目をクリックすればこのA商店の企業概要が表示されるようになっている。各商店等7の情報はサーバー3のデータベース1009に保存されている。なお、この商品については別途独立して商店等7側で用意されたホームページからリンクが張られるようになっている。
そして、各商店等7は、WWWサーバー3のサイトに対し貸し店舗形式で加入したり、商品を登録するようになっている。図61では、各商店等7及びWWWサーバー3のサイトの運営者において設定された当該商品についての現金還元額が表示されている。即ち、商店等7で現金還元された上に、更にWWWサーバー3のサイトの運営者によっても追加の現金還元がされるようになっている。
但し、各商店等7又はWWWサーバー3のサイトの運営者のそれぞれのみが当該商品について設定した現金還元額を表示するようにしてもよい。図61の例で言えば、A商店の希望販売価格20万円でA商店による現金還元額は0円、B商店の希望販売価格19万9千円でB商店による現金還元額は400円、C商店の希望販売価格20万円でC商店による現金還元額は300円であり、かつB商店とC商店では、値引き交渉も可能なようになっている。なお、値引き交渉と現金還元(ユーザ貯金箱を含む)の処理については前述した各実施形態の通りである。希望販売価格X円、底値Y円、現金還元額、送料データ等はサーバー3のデータベース1009に保存されている。このように、ホームページの一画面で各商店等7の価格比較をし、かつ値引き交渉と現金還元額をも設定することで、ユーザ5にとっては商品の底値Y円の推定がし易くなる。また、値引き交渉を設定した商店等7にとっては、常に底値ぎりぎりの額を表示する必要が無くなり、表示した価格が他店よりも高くても値引きされる含みを残すことで、底値ぎりぎりの額を表示した商店等7とも互角に競争できる。
なお、WWWサーバー3のサイトの運営者側では、サーバー3のデータベース1009にユーザ5による販売情報の履歴が取られ貸し店舗にて加入された商店等7がいつでも閲覧可能なようになっている。そして、ユーザ5による購入のあった場合には、各商店等7に対し電子メールが送信され、その電子メールを受け取った各商店等7はサーバー3のデータベース1009に接続して販売情報の履歴を閲覧する。販売情報の履歴には、値引き交渉又は現金還元による決定価格、支払方法、お届け先、送料、購入者情報、ユーザ貯金箱に関する情報等が表示されている。このユーザ貯金箱は、貸し店舗にて加入された商店等7毎に独立してサーバー3のデータベース1009に配設され、かつ各ユーザ単位に準備されたものである。そして、ユーザ貯金箱に関する情報は、この商店等7のユーザ5の有するユーザ貯金箱に対し貯金がどの程度存在するかの情報である。なお、図61のようにWWWサーバー3のサイトの運営者によっても追加の現金還元がされるような場合には、ユーザ5の有するユーザ貯金箱がサイトの運営者側でも商店等7側とは別に用意されている。この際には、ユーザ5は、商店等7のユーザ貯金箱から貯金を利用して購入した商品の支払ができると共に、WWWサーバー3のサイトの運営者により提供されたユーザ貯金箱からも貯金を利用して支払に当てることができる。
その後は、各商店等7はユーザ5からの入金の確認処理をし、商品の出荷等を行う。なお、各商店等7の独自のホームページにおいても商品やサービスの販売がされている場合には、これらの商品やサービスについて各商店等7のホームページ上に特定のアイコンを埋設し、このアイコンがユーザ5によりクリックされたときにWWWサーバー3のサイトにリンクされることが望ましい。WWWサーバー3のサイト側では値引き交渉や現金還元の機能を提供可能である。このため、この特定のアイコンは値引き交渉等が可能であることを明示することが望ましい。また、特定のアイコンがクリックされたときに、WWWサーバー3のサイト側で用意した値引き交渉機能や現金還元機能に直接リンクされてもよい。この場合には、あたかも値引き交渉機能や現金還元機能が各商店等7側で独自に用意された機能であるかのように動作可能である。
また、図61では「その他商店」を選択可能なようになっており、このその他商店では、直接価格対比ページへの商品掲載はしていないが、WWWサーバー3のサイト内の貸し店舗に登録があり、当該商品をこの貸し店舗において販売している商店等7の名称が複数用意されており、この中から一つを選択可能なようになっている。但し、その他商店では、これまでのページで表示されていない残りの商店を表示順選択欄2007で指定された順に従って配列するようにしてもよい。
そして、この貸し店舗の一つが選択された場合には、WWWサーバー3のサイト内の貸し店舗のページに進み表示されるようになっている。この貸し店舗の情報や販売の商品等は、サーバー3のデータベース1009に保存されている。一方、貸し店舗のページには、「直接価格対比ページの情報を見る」ボタン(図示略)を有しており、このボタンをクリックすることで直接価格対比ページに進み、各商店毎の価格比較が行えるようになっている。なお、閲覧モード選択ボタン2001をクリックすることで直接価格対比ページに進んでもよい。
このことにより、貸し店舗のページで値引き交渉の底値の判断をし難いと感じたユーザ5は直接価格対比ページに進み、この価格情報を見ることで底値の推定が容易となる。更に、これらの各商店には図58における「他店の方が安いよ」ボタンを配設するようにしてもよい。
次に、図61の閲覧モード選択ボタン2001において、ウィンドウショッピングのページを選択した場合について説明する。
ウィンドウショッピングのページは、図62に示すように、WWWサーバー3のサイトの開設する貸し店舗において登録された各商店等7のホームページ2009で構成されている。各商店等7の情報や商品情報等はサーバー3のデータベース1009に保存され、Webページとして閲覧可能なようになっている。
ユーザ5は、閲覧モード選択ボタン2001でウィンドウショッピングのページを選択した後、まず商品名入力又は検索欄2005で商品名(例えば「パソコンPC9821V13」)を指定、あるいは検索により商品名を特定する。このことにより、A商店の当該商品情報及び価格の属するページが開かれる。この際には、当該商品が目立つようにページトップに表示されたり、色分け等の施されるのが望ましい。このページには、また、A商店で扱う他の商品情報も含まれている。図62は、このA商店のページが開かれた様子を示している。ユーザ5は、「次のお店(B商店)へウィンドウショッピングする」の移動ボタン2011によりページを進めたり戻ったりできるようになっている。次のお店(B商店)のページでは、同様に図63に示すように、B商店の当該商品情報及び価格の属するページが開かれる。このページには、また、B商店で扱う他の商品情報も含まれている。ユーザ5は、以下、同様にページを進めたり戻ったりすることで、各商店を巡るウィンドウショッピングの感覚で楽しみながら、当該商品の値段を次第に把握できる。何店舗かの価格を参照することで、底値についての推測も自然の形で把握できる。そして、気に入った商店等7で値引き交渉等により商品を購入できる。
なお、ユーザ5が、当該商品の値段を直接対比したくなった場合には、閲覧モード選択ボタン2001で直接価格対比のページを選択すればよい。
また、次のお店(B商店)へウィンドウショッピングするのに代えて、複数の商店の中から一つを選択自在としてもよい。これらの商店は、通常表示は商店名順であるが、売れ行き順、価格の安い順等を選択することで、これらに従って絞り込まれたデータが表示されるようにしてもよい。
なお、商店名検索欄2015に直接商店名を入力、若しくは複数の商店の中から一つを選択することで、直接当該商店のページが直接価格対比又はウィンドウショッピングのページの先頭に表示されるようにしてもよい。
このように、ユーザ5が、ウィンドウショッピングの感覚で買い物を楽しむことが可能でありながら、直接価格対比もでき、価格相場が簡単に分かる。この価格相場を基にユーザ5は値引き交渉を効率よく行うことが可能となる。
なお、上述した直接価格対比及びウィンドウショッピングは、第11実施形態で述べたオークション等について適用されることも可能である。但し、この場合には値引き交渉ボタンは、オークション処理に進むためのボタンとなる。
このことによっても、ウィンドウショッピングのように楽しみつつ価格相場が分かる。この価格相場を基にユーザ5はオークションや入札を効率よく行うことが可能となる。
次に、本発明の第20実施形態について説明する。上述した直接価格対比又はウィンドウショッピングのページでは、商店等7にとっては扱いも小さく、かつページが変わった場合には消えてしまうものである。本発明の第20実施形態では、この点を同じページの一角に特別店舗紹介コーナーを設け、直接価格対比又はウィンドウショッピング等のページが繰られても常に定位置に表示されることで宣伝効果を高くしたものである。
図64に画面構成例を示し、図65にフローチャートを示す。図64には、特別店舗紹介コーナー2017が追加されている。そして、特別店舗紹介コーナー2017は、直接価格対比又はウィンドウショッピング等のページが繰られても常に定位置に表示されるようになっている。特別店舗紹介コーナー2017においては、店舗名、商品型番、希望販売額、値引き交渉が可能か否か。現金還元された際の金額等が表示されており、店舗名をクリックすれば当該店舗に進み、商品型番をクリックすれば商品の詳細仕様を含む情報が表示される。そして、この商品の詳細仕様のページからも値引き交渉や現金還元が可能であるが、特別店舗紹介コーナー2017における値引き交渉をクリックしても値引き交渉処理に直接飛べる。
図65において、ステップ1881では、商品名入力又は検索欄2005で商品名(例えば「パソコンPC9821V13」)を指定、あるいは検索により商品名を特定する。ステップ1883では、当該商品を扱う商店が商店掲載順位テーブル中に存在するか否かが判断される。この商店掲載順位テーブルには特別店舗紹介コーナー2017における掲載順位毎若しくは掲載欄毎に料金が設定されている。店舗はこの商店掲載順位テーブルに予めデータを登録することにより、特別店舗紹介コーナー2017に表示されるようになっている。
ステップ1883で当該商品を扱う商店が商店掲載順位テーブル中に存在していた場合には、ステップ1885で商店掲載順位テーブルが参照される。一方、存在しなかった場合にはステップ1887で終了する。ステップ1889では、初期値としてn=1が設定される。ステップ1891では、まず1番目に掲載する商店が抽出される。そして、ステップ1893で抽出した商店の画像や販売情報等をWebページのn番目の欄に組み込む。ステップ1895で商店掲載順位テーブルからの抽出が完了していない場合には、ステップ1897でnをインクリメントした上で再びステップ1891からの処理を繰り返す。そして、ステップ1899で、一つのWebページの形にしてユーザパソコンにダウンロードさせる。
以上により、当該商品を購入したいユーザ5に対してWebページの目立つ箇所に常に店舗名等が表示され、ユーザ5が購入し易い。
次に、本発明の第21実施形態について説明する。本発明の第21実施形態では、サイト内にソフトウェアにて構成されたロボット店員を仮想配置し、このロボット店員にユーザ5との間でユーザ5の有する独自の情報やサイトの有する情報等に応じて臨機応変に様々な対応をさせるものである。この対応には、例えば、値引き交渉の誘導及び案内、商品説明、挨拶、サイトの紹介、ヘルプ等が含まれるがこれらに限定されるものではない。
現金還元額の大きさやm値の設定、底値価格の設定をお得意様段階に応じて例えば5段階に設定している場合には、このお得意様段階に応じてホームページ上に現れるロボット店員を異ならせる。お得意様段階は、ユーザ5による購入価格の総額と購入頻度やサイトの利用実績等に応じて決められている。お得意様段階と購入価格の総額等のデータはサーバー3のデータベース1009に保存されている。そして、このお得意様段階は、例えば購入価格の総額が5万円未満で、かつ購入頻度が4回未満の場合にはお得意様段階は1段階とする。そして、お得意様段階が1段階上がったユーザ5に対してはロボット係長が応対するようになっている。購入価格の総額が5万円以上20万円未満で、かつ購入頻度が4回以上7回未満の場合にはお得意様段階は2段階とする等である。そして、お得意様段階が2段階上がったユーザ5に対してはロボット課長が応対するようになっている。以下、更に1段階ずつランクの上がった場合にはロボット部長、ロボット店長、ロボット社長が応対するようになっている。
次に、図66にフローチャートを示す。ステップ1901では、ユーザ5がWWWサーバー3のサイトに接続する。ステップ1903ではユーザ5のパソコンからクッキー(cookie)情報を取得する。そして、ステップ1905では、データベース1009よりこのクッキー情報を基にユーザ情報の一致するデータを抽出する。ステップ1907では、ユーザ5が検出される。但し、ユーザ5の検出は、ユーザIDを入力させ、このユーザID情報を基に判断されるようにしてもよい。ステップ1909では、このユーザ5に属するお得意様段階をデータベース1009より抽出する。ステップ1911では、このお得意様段階を基に出現させるロボット店員をデータベース1009より選定する。例えば、購入価格の総額が6万円で購入頻度が5回の場合には、ロボット課長が選定される。このとき、ロボット課長のデザインの組み込まれたホームページがデータベース1009より抽出される。ステップ1913では、抽出されたロボット店員を含むホームページがユーザパソコンに表示される。
こうすることで、ユーザ5は、自分がお得意様であることを認識できるし、一層安く購入できるということを感覚的に理解できる。従って購入の促進に繋がる。
次に、このロボット店員により様々な挨拶を行う処理について説明する。まず、ロボット店員によるユーザ5の訪問時間の管理について説明する。図67において、ステップ1901〜ステップ1907までの処理については図66と同様であるので省略する(以下、同旨)。ステップ1921では、サイトの訪問が初めてか否かを判断する。この判断は、クッキー情報を抽出して過去に同じユーザ5からのデータが保存されていないかどうかを見ることで判断できる。または、クッキー情報に一致する既にユーザ登録されたデータがデータベース1009中に存在しないかどうかで判断されてもよい。更に、ユーザIDを入力させ、このユーザID情報を基に判断されるようにしてもよい。
当サイトへの訪問が初めてであると判断されたときには、ステップ1923で「はじめまして。登録をお願いします。」とWeb画面上に表示する。但し、音声にて発するようにしてもよい(以下、同旨)。一方、ステップ1921で、当サイトへの訪問が初めてではないと判断されたとき、ステップ1925で前回訪問からの時間を算出する。これは、データベース1009に対しユーザ5の訪問日時を各ユーザ毎に記録することで可能となる。ステップ1927で、一定時間以上経過しているか否かが判断される。そして、一定時間以上経過していると判断されたときステップ1929で「**さんこんばんわ。しばらくです。」と表示する。この文言はデータベース1009に保存されたデータと、ステップ1907で検出されたユーザ5の名前とを組み合わせることで可能である。
一方、ステップ1927で、「一定時間以上経過していないと判断されたときステップ1931で「**さんこんばんわ。たびたびご来店頂きありがとう。」と表示する。
次に、ロボット店員による天候の挨拶について説明する。図68のステップ1941において、データベース1009に登録されたユーザ5の住所を抽出する。この住所はほぼユーザ5の現在居る住所と同じであると推測される。しかしながら、移動情報処理端末や携帯型のパソコン等で移動中の場合もあり、この場合には、GPS等による位置情報を検出し、この情報を用いてもよい。ステップ1943では、天気予報データベース1009より当該住所地の属する天気データを抽出する。このため、天気予報データベース1009には時々刻々に各地域毎の天気データが保存されるようになっている。あるいは、この天気予報データベース1009は、気象庁等の提供者によるものとしてこのデータベース1009とリンクすることで取得されてもよい。ステップ1941で抽出した住所がいずれの地域に属するかを判断することで当該住所地の属する天気データを抽出することが可能である。
ステップ1945では、天気データ−時候の挨拶文言テーブルより時候の挨拶文を抽出する。このため、天気データ−時候の挨拶文言テーブルには予め天気データが晴れのときには「今日はいい天気ですね」、天気データが雨のときには 「今日はあいにくの天気ですね」という文言を関連付けして保存しておく。その後、ステップ1947では、Webページを合成する。即ち、晴れマークを追加すると共に「**さん 今日はいい天気ですね。」という文言を合成して、一つのWebページとして生成され、ユーザ5のパソコンにダウンロードされる。
次に、ユーザ5の近況が変化した場合の時候の挨拶について説明する。図69において、ステップ1951でユーザ5の登録情報である例えば住所が変更されたような場合である。この情報の変化を抽出する。そして、ステップ1953では、「**さん こんにちわ。住所が変わられたんですね。」とユーザ5に対して表示する。「**さん こんにちわ。**が変わられたんですね。」の**に相当する部分に対して、検出した情報である氏名や、変更のあったものの情報 (この場合には住所という文言)を組み込みWebページを合成する。変更の想定される文言は予めデータベース1009に保存され、この中から情報の変更のあった文言が選択されるようになっている。
次に、ユーザ5の過去の購入情報を基にした挨拶について説明する。図70のフローチャートにおいて、ステップ1961で販売管理データベース1009より過去の購入情報を見る。そして、ステップ1963で、購入情報が存在する場合には、ステップ1965で「この間はご購入頂きありがとうございました」とロボット店員が挨拶をする。一方、ステップ1963で購入情報が存在しない場合には、ステップ1967で次の処理へ進む。
次に、ロボット店員が各店舗に合わせて衣替えする方法について説明する。ロボット店員は、ホームページ上で閲覧可能な画像にて形成される。そして、このロボット店員の画像中の適所には、商号等のマークが表示されている。WWWサーバー3のサイトに対し貸し店舗形式で各店舗に加入してもらう場合、ロボット店員に付される商号等のマークが各店舗に合わせて変えられることが望ましい。図71のフローチャートにおいて、ステップ1971でユーザ5がWWWサーバー3のサイト内の店舗のホームページに接続する。このとき、ステップ1973では、WWWサーバー3はこの店舗のホームページが選択されているということをURLを検出することで確認したり、あるいはソフトウェア的にサーバー3内部の処理により確認する。そして、例えば店舗名(あるいは店舗のコード)を抽出する。ステップ1975では、店舗−衣替え用部品テーブルを参照する。この店舗−衣替え用部品テーブルは、例えば、各店舗毎に用意された部品の形態である。部品は、例えば、ロボット店員の衣類に表示する各店舗の商号等のマークやロボット店員の顔、季節に応じた衣類等である。しかしながら、音声等であってもよい。これらの部品は各店舗毎にデータベース1009に保存されている。
ステップ1977では、当該店舗に一致した部品を抽出する。そして、ステップ1979では、ロボット店員の画像の一部を抽出部品と交換することで、このロボット店員に着せ変えを行う。ステップ1981では、この着せ変えの完了したロボット店員を含む画像をダウンロードする。なお、部品は店舗毎に対応してデータベース1009に保存されるとして説明したが、複数のアイコンや形態等をデータベース1009に予め用意しておき、ユーザ5に対しその内の好きなアイコンや形態を選択してもらい、このユーザ5に特有のアイコンとして登録するようにしてもよい。そして、ロボット店員を表示する際には、このユーザ5に特有のアイコン等で着せ変えられた態様で画像表示されるようにしてもよい。また、部品を交換するのではなく、予め店舗毎やユーザ5毎に対応されたロボット店員の画像を含む専用のHTML画像の全画面分を店舗名や店舗コード若しくはユーザIDと関連付けしてデータベース1009に用意しておき、店舗名等を基にこの専用のHTML画像を検索した後、ユーザパソコンにダウンロードさせるようにしてもよい。
以上により、ロボット店員の様々な臨機応変の登場及び挨拶が可能となり、ユーザ5にとっては親しみがわき再びサイトを訪問したくなる。従って、商品等の購入促進にも繋がる。
次に、本発明の第22実施形態について説明する。本発明の第22実施形態では、サイト内にソフトウェアにて構成されたロボット店員を仮想配置し、このロボット店員に対しサイト内で販売を担当させるものである。この販売を担当させる方法について図72及び図73のフローチャートを基に説明する。図72及び図73において、ステップ2001では、同一ジャンルの複数の商品を対比する閲覧ページを表示する。このページは、例えば、携帯電話やプリンター等の商品分類毎について複数の商品アイテムがまとめて掲示されたページや、上述の直接価格対比のページやウィンドウショッピングのページ等も含む。但し、ジャンルや商品等は入力欄により指定されてもよい。ステップ2003ではロボット店員を表示する。ステップ2005では、ユーザ5は当該ページで表示されている商品ジャンル(例えばパソコンのページならばパソコン)について、若しくは入力欄に指定した商品(例えば「PC9821V13」等のパソコン型番を入力した場合にはこのパソコン型番、商品ジャンルを指定した場合にはこの商品ジャンル等)について、予算金額入力欄にユーザ5が当該商品を購入するのに許容可能な予算金額を入力する。また、ステップ2007では機能を選択する。機能は機能入力欄に文字入力されてもよいが、予め用意された機能の中から選択されてもよい。
ステップ2009では、お勧めで購入又は売れ筋で購入を選択する。ステップ2011でお勧めで購入が選択された場合には、ステップ2013に進む。ステップ2013では、予算金額の入力があるか否かが判断される。そして、予算金額の入力があった場合には、ステップ2015で商品ジャンル−お勧め商品テーブルより予算金額以内のデータを抽出する。この商品ジャンル−お勧め商品テーブルには、予め各商品ジャンル毎にWWWサーバー3のサイトの運営者により選定されたお勧め商品が少なくとも一つ保存されている。
また、ステップ2007で機能の選択があったとステップ2017で判断された場合に、ステップ2019でこの機能に従ってデータが絞られる。そして、ステップ2021に進む。一方、ステップ2017で機能の選択がなかったと判断された場合にはステップ2021に進む。ステップ2021では、nの値を初期値として1を設定する。次にステップ2023では、n番目に高いお勧め商品を抽出する。即ち、まずは1番高額なお勧め商品を抽出する。次に、ステップ2025では、当該お勧め商品のお勧めのポイント(要点)が抽出される。このお勧めのポイントは、サイトの運営者によって予め記載されてデータベース1009に保存されたものである。この商品選択の際に参考となるお勧めの要点がデータベース1009より抽出される。
ステップ2027では、抽出されたお勧めの要点がロボット店員と組み合わされて一つのWebページとされる。このページには表示のみではなく、音声が含まれてもよい。そして、このWebページがユーザパソコンにダウンロードされることで、ロボット店員が表示若しくは音声によりお勧め商品を紹介する。ステップ2029では、ユーザ5が詳細仕様を見たい場合にこの詳細仕様を閲覧する。そして、ステップ2031で当該商品を購入する旨のボタンをクリックする。ユーザ5は、詳細仕様を見ずにステップ2031で当該商品を購入する旨のボタンをクリックすることも可能である。
ステップ2031で購入せずに「次の商品を紹介」ボタンをクリックした場合には、ステップ2032でnのカウント値を1つインクリメントした上で再びステップ2023からの処理を繰り返す。ステップ2031で購入を選択した場合にはステップ2033で値引き交渉処理や現金還元処理が可能である。
なお、ステップ2035で売れ筋で購入が選択された場合には、ステップ2037に飛ぶ。そして、ステップ2037では、予算金額の入力があるか否かが判断される。そして、予算金額の入力があった場合には、ステップ2039で商品ジャンル−売れ筋商品テーブルより予算金額以内のデータを抽出する。この商品ジャンル−売れ筋商品テーブルには、予め各商品ジャンル毎にWWWサーバー3のサイトの運営者により選定された売れ筋商品が少なくとも一つ保存されている。
また、ステップ2007で機能の選択があったとステップ2041で判断された場合に、ステップ2043でこの機能に従ってデータが絞られる。そして、ステップ2045に進む。一方、ステップ2041で機能の選択がなかったと判断された場合にはステップ2045に進む。ステップ2045では、nの値を初期値として1を設定する。次にステップ2047では、n番目に高い売れ筋商品を抽出する。即ち、まずは1番高額な売れ筋商品を抽出する。次に、ステップ2049では、当該売れ筋商品のお勧めのポイント(要点)が抽出される。この売れ筋のポイントは、サイトの運営者によって予め記載されてデータベース1009に保存されたものである。この商品選択の際に参考となる売れ筋の要点がデータベース1009より抽出される。
ステップ2051では、抽出された売れ筋の要点がロボット店員と組み合わされて一つのWebページとされる。このページには表示のみではなく、音声が含まれてもよい。そして、このWebページがユーザパソコンにダウンロードされることで、ロボット店員が表示若しくは音声により売れ筋商品を紹介する。ステップ2053では、ユーザ5が詳細仕様を見たい場合にこの詳細仕様を閲覧する。そして、ステップ2055で当該商品を購入する旨のボタンをクリックする。ユーザ5は、詳細仕様を見ずにステップ2055で当該商品を購入する旨のボタンをクリックすることも可能である。
ステップ2055で購入せずに「次の商品を紹介」ボタンをクリックした場合には、ステップ2056でnのカウント値を1つインクリメントした上で再びステップ2047からの処理を繰り返す。ステップ2055で購入を選択した場合にはステップ2057で値引き交渉処理や現金還元処理が可能である。
次に、本発明の第23実施形態について説明する。本発明の第23実施形態では、サイト内にソフトウェアにて構成されたロボット店員を仮想配置し、このロボット店員がユーザ5に対して挨拶する際に何か出物があったらお知らせするというものである。この何か出物があったらお知らせする方法について図74及び図75のフローチャートを基に説明する。まず、図74及び図75において、ユーザ5は、ステップ2101で、WWWサーバー3のサイトに対し予め何か出物があったら通知が欲しい旨の設定を登録しておく。この際には、ステップ2103において欲しい商品(商品名若しくは型番)で登録するか、若しくは希望のジャンルや趣味で登録するかを選択する。ジャンルは、例えば生活、旅行、教育、健康、スポーツ、ゲーム等である。
ステップ2103で欲しい商品(商品名若しくは型番)で登録するを選択した場合には、ステップ2105で予めユーザ5が情報の欲しい商品(必須記入)と仕様が分かっている場合にはその仕様、最高限度価格(任意記入)、最高限度価格との差額が誤差範囲内のときに通知を希望(率若しくは金額)(任意記入)とをWeb画面にて登録する。商品はディジタルカメラや、パソコン等と一般的な商品名称を登録してもよいし、商品の型番が分かっている場合には、その型番を登録する。
最高限度価格では、この金額以下の商品ならば情報をもらいたいという場合に金額入力欄に金額を入力する。また、「最高限度価格との差額が誤差範囲内のときに通知を希望(率若しくは金額)」は、最高限度額を超えてはいても一定範囲内ならば情報をもらいたいという場合に設定する。一方、ステップ2103で 「希望のジャンルや趣味で登録する」を選択した場合には、ステップ2107でWeb画面上でジャンルを選択したり、趣味を選択する。
そして、ステップ2109でユーザ5が再びWWWサーバー3のサイトを訪問したとき、ステップ2111でユーザ5のパソコンからクッキー情報が取得される。ステップ2113では、このクッキー情報を基に一致するユーザ5の情報がデータベース1009より取得される。但し、ユーザ本人の確認はユーザIDによって行われてもよい。その後、ステップ2115では、ステップ2103において設定された欲しい商品の登録が存在するか否かが判断される。欲しい商品の登録が存在する場合には、ステップ2117でこの欲しい商品について既にステップ2105で登録されていたデータをデータベース1009より抽出する。
一方、ステップ2115で、欲しい商品の登録が存在しない場合には、ステップ2119で購入実績を見たりステップ2107で登録された趣味データやジャンルを参照する。あるいは、よ訪れるサイトを蓄積・分析することで、ステップ2121において欲しい商品を推定する。そして、ステップ2123では、登録あるいは推定された欲しい商品について出物が存在するか否かが判断される。但し、欲しいジャンルについて出物が存在するか否かが判断されるようにしてもよい。また、欲しい商品はオークション等の出品物に対して適用されてもよい。
この出物情報は、日時と共に随時ジャンル、商品名毎にデータベース1009に保存されるようになっている。欲しい商品やジャンルについて出物が存在しない場合には、既存の商品の中から最もユーザ5の希望に沿った商品を案内することが望ましい。このための処理について説明する。ステップ2125では、登録あるいは推定された欲しい商品についてデータベース1009からジャンルや商品名の一致するデータをすべて抽出し、その値段を取得する。ステップ2127で現金還元可能な商品か否かを判断し、可能なものについては、ステップ2129で欲しい商品の値段から現金還元額分を差し引く。但し、この現金還元額分の減額は必ず商品価格から減額されることが確認されているものについてのみ減額が行われる。現金還元額分がユーザ貯金箱に貯金されるような場合には差し引かないことが望ましいからである。また、現金還元額は出物として提示する際に記載されるのでユーザ5がその際に分かるからである。
ステップ2131では、最高限度価格の指定があるか否かが判断される。最高限度価格の指定がある場合には、ステップ2133に進み、ステップ2125で抽出した商品データに関し、欲しい商品についての最高限度価格より値段の安いものがあるか否かを判断し、あった場合には抽出する。またはオークションの場合には、オークションでの出品でユーザ5希望のものが出され、かつ値段がユーザ5の指定した最高限度価格より安いものがあるか否かが判断されてもよい。
ステップ2135では、「**さん(依頼されていた)商品**についてよい出物がありますよ。」とのメッセージがホームページ構成され、このホームページがユーザのパソコンにダウンロードされることでロボット店員がメッセージをユーザ5に対して表示する。この際には、ステップ2137で、商店名、商品名、価格、値引き交渉可能か否か、現金還元額を提示する。複数の商品が存在している場合にはその複数の商品を提示する。ステップ2139では、ユーザ5が商品名をクリックするとこの出物の詳細の記載されたページへ進むようになっている。ステップ2141でユーザ5が気に入り購入ボタンをクリックした場合には、ステップ2143で値引き交渉や現金還元が可能なようになっている。一方、ステップ2139でキャンセルボタンがクリックされた場合には、ステップ2145でキャンセル処理がされる。
なお、ステップ2123で欲しい商品について出物が存在した場合には、ステップ2135からの処理が行われ出物が存在する旨をユーザ5に対して案内する。また、ステップ2131で最高限度価格の指定がなかった場合には、ステップ2147で欲しい商品について値段の安い物件を数件抽出し、ステップ2135からの処理が行われ出物が存在する旨をユーザ5に対して案内する。
更に、ステップ2133で、欲しい商品について最高限度価格より値段の安いものがなかった場合には、ステップ2149で最高限度価格との差額が算出される。そして、ステップ2151でこの差が設定の割合以内か否かが判断される。この差はユーザ5が最高限度価格をどこまで超えても許容してくれるかによるが、一応10〜20パーセント程度に設定される。このとき、ステップ2153では、「**さん(依頼されていた)商品**についてご希望に近いよい出物がありますよ。」とホームページ上で案内する。そして、以降ステップ2137からの処理が行われる。一方、ステップ2151で、差が設定の割合以内に納まらなかった場合にはステップ2155で「*さん依頼されていた商品について今のところ掘り出しものはありませんが鋭意努力中です。しかしながら、値引き交渉如何によってはご希望の価格以内に納まることもあります。」とのメッセージをホームページ上でユーザ5に対して案内する。そして、ステップ2157で、当該商品について値引き交渉の可能な商店リストをユーザ5に対して提示する。ステップ2159では、ユーザ5はこの内から商店を選択することで、WWWサーバー3のサイト内のこの店舗のホームページに接続する。
なお、図74の上記説明では、ステップ2109でユーザ5が再びサイトを訪問した際に画面にてメッセージを表示するとして説明したが、事前に欲しい商品についての出物が出たことをユーザ5に対し電子メールにて伝えるようにすることが望ましい。この場合であっても、ステップ2115以降の処理を別途事前に行うことで出物の存在を検出することが可能である。
以上により、ユーザ5が何か出物を探しているような場合に、その条件を予めWWWサーバー3のサイトに対し設定しておくことで、出物が見つかったことをいち早くユーザ5がサイトを訪れた際に報告でき、臨機応変な対応ができる。ユーザ5は探し物で大変な思いをしなくて済む。また、商店にとっては販売促進に繋がる。
次に、本発明の第24実施形態について説明する。本発明の第24実施形態では、買い物かごに入れた商品の合計をした後、合計金額が予算に合っていないことに気づいたユーザが、予算に合うように商品選定の見直しが容易にできるようにしたものである。
図76及び図77にフローチャートを示す。まず、ユーザ5はWWWサーバー3のサイトにおいて、ステップ2201で図示しない買い物かごに商品を入れる。そして、ステップ2203でもうこれ以上買い物をするものが無くなったときに最終的な金額の合計をする。この金額はステップ2205でユーザ5に対して金額表示される。この金額に不満のあるユーザ5は次にステップ2207で「予算に合うように見直し」ボタンをクリックするか、若しくは「個別に商品を見直す」ボタンをクリックする。「個別に商品を見直す」ボタンがクリックされた場合には、ステップ2209で買い物かごの中から「商品を一つ指定」ボタン若しくは「削除」ボタンを選択する。「商品を一つ指定」ボタンが選択された場合には、ステップ2211でメーカーや仕様等の属性を指定する。但し、金額の上限が設定されるようにしてもよい。しかしながら、これらについては指定されなくてもよい。ステップ2213では、この商品と同じ分類の商品が少なくとも一つ候補表示される。例えば、買い物かごの中から見直しのために指定された商品がパソコンPC9821であれば、他のパソコンが候補表示される。メーカー名、仕様等の指定がされている場合には、これらのデータにより絞られた上で候補が表示される。
ステップ2215では、ユーザが候補の内から一つを選択する。そして、ステップ2217で再度合計金額が算出される。その結果を見てユーザ5はステップ2219で購入するか否かを判断する。購入をクリックした場合には、ステップ2221で値引き交渉や現金還元の処理が行われる。一方、購入しない場合には、ステップ2207からの処理が繰り返される。
ステップ2207において、「予算に合うように見直し」ボタンがクリックされた場合には、ユーザ5はステップ2223で予算金額入力欄に予算金額を入力する。また、ステップ2225で商品の優先順位を指定する。商品の優先順位は、買い物かごの中に入れられた商品の内、ユーザ5が最も購入したいものの順である。ステップ2227では、初期値としてnに1を設定する。ステップ2229では、合計金額が予算金額以上か否かが判断される。合計金額が予算金額以上の場合には、ステップ2231で、商品の優先順位のまず1番目に低い商品について商品を少なくとも一つ候補表示する。出来るだけ優先順位の低い商品について予算に合うように商品ランクを落とすためである。この候補表示の際は、ステップ2233で選択された商品よりも安い商品について色分け明示することが望ましい。このことにより、ユーザ5が商品を選択し易くなり、また、容易に予算金額以内にすることができる。
一方、ステップ2229で、合計金額が予算金額を下回っている場合には、ステップ2255で商品の優先順位のまず1番目に高い商品について商品を少なくとも一つ候補表示する。出来るだけ優先順位の高い商品について商品ランクを上げることで、予算に近づけるためである。ユーザ5が最も欲しい商品について商品ランクを上げることが望ましいからである。また、この候補表示の際には、ステップ2257で選択された商品よりも値段の高い商品について色分け明示することが望ましい。
ステップ2235では、メーカーや仕様等の属性を指定するか否か問い合わせがされる。指定した場合には、ステップ2237でこの指定された属性によりデータが絞られる。ステップ2239でユーザ5にとって選択したい候補がこの中に見つかった場合にはステップ2241でユーザ5が候補の内から一つを選択する。選択されると、ステップ2243で再度合計金額が算出される。一方、ユーザ5にとって選択したい候補が見つからなかった場合には、ステップ2259で次の商品を変更するボタンをクリックするか、若しくは前の商品を変更するボタンをクリックする。次の商品を変更するボタンがクリックされた場合には、ステップ2261でnの値がインクリメントされた上で、ステップ2229からの処理が繰り返される。即ち、予算金額との関係でn+1番目に安い商品、若しくはn+1番目に高い商品について候補表示がされる。
一方、ステップ2259で前の商品を変更するボタンがクリックされた場合には、ステップ2263でnの値がデクリメントされた上で、ステップ2229からの処理が繰り返される。即ち、予算金額との関係でn−1番目に安い商品若しくはn−1番目に高い商品について候補表示がされる。
ステップ2245では、ステップ2243で算出された合計金額がステップ2223で入力された予算金額と比較され、この予算金額以内かどうか判断される。予算金額以内と判断された場合には、ステップ2247で「予算金額以内です。確定していいですか?」と問い合わせメッセージがユーザ5に対して出される。確定する場合には、ステップ2249に進み、購入ボタンをクリックし、ステップ2251で値引き交渉や現金還元の処理が行われる。一方、購入しない場合には、ステップ2253で候補選択に戻るが選択され、ステップ2235からの処理が繰り返される。
なお、ステップ2245で予算金額を超えていると判断された場合には、ステップ2265で「予算金額を超えていますが確定していいですか?」と問い合わせメッセージがユーザ5に対して出される。確定する場合には、ステップ2249に進み、購入処理が行われる。一方、購入したくない場合には、ステップ2267で候補選択に戻るか、次の商品を変更するか、若しくは前の商品を変更するのかが選択される。そして、候補選択に戻る場合には、ステップ2235からの処理が繰り返される。次の商品を変更するが選択された場合には、ステップ2269でnの値がインクリメントされた上で、ステップ2229からの処理が繰り返される。即ち、予算金額との関係でn+1番目に安い商品、若しくはn+1番目に高い商品について候補表示がされる。
一方、ステップ2267で前の商品を変更するが選択された場合には、ステップ2271でnの値がデクリメントされた上で、ステップ2229からの処理が繰り返される。即ち、予算金額との関係でn−1番目に安い商品若しくはn−1番目に高い商品について候補表示がされる。
以上により、購入の直前に予算金額に合わないことが分かった場合であってもユーザ5は予算金額に合うように面倒な処理を行うことなく簡単に見直しを行うことが可能となる。
次に、本発明の第25実施形態について説明する。本発明の第3実施形態では直接減額の希望額V円とユーザ貯金箱への貯金額T−V円との合計である現金還元総額T円がユーザ5による直接減額の希望額V円如何にかかわらず一定である場合について説明したが、本実施形態では、直接減額の希望額の大きさ如何により変動させる方法について説明する。即ち、ユーザ5が直接減額の希望額V円を高く希望すればする程、ユーザ貯金箱に入れられる仮想現金(若しくはポイント制が導入されていれば貯められるポイント)を上記から得られる仮想現金の金額T−V円よりも小さくするものである。従って、現金還元総額T円もその分小さくなるものである。
図78には、本発明の第3実施形態における直接減額される金額とユーザ貯金額(若しくはポイント制が導入されていれば貯められるポイント)の関係をグラフで示す。即ち、最高限度額はV円であって、最高限度額V円までの直接減額が可能である。このV円までのなにがしかの金額h円をユーザ5は直接減額の希望金額入力欄に入力する。このとき、直接減額の希望金額入力欄に入力された金額h円を基に図78のグラフからユーザ貯金箱に入れられる仮想金額a1円が抽出される。そして、このa1円がユーザ貯金箱に入れられ、一方h円が直接減額される。ここに、現金還元総額T=a1+hの関係がある。
これに対して本実施形態の直接減額される金額とユーザ貯金額(若しくはポイント制が導入されていれば貯められるポイント)の関係を図79にグラフで示す。直接減額の方がユーザ5にとってはありがたいはずのものである一方で、商店等7にとっては再度の購入の機会が減る可能性があることを配慮し、直接減額分が大きければ大きい程ユーザ貯金箱やポイントに入れられる金額や率、ポイントを小さくするものである。
図79中、(イ)の直線は、図78のグラフと同様に、丁度直接減額分とユーザ貯金箱に入れられる金額の合計が総現金還元額になっている特性を示す。一方、(ロ)の直線は傾斜が(イ)の傾斜よりもきつい。(ロ)の直線は、数4で現される。
(数4)
y=T−αx
ここに、0≦x≦V、1≦αである。αは傾斜度合いを示す。最高限度額はV円であって、最高限度額V円までの直接減額が可能である。このV円までのなにがしかの金額h円をユーザ5は直接減額の希望金額入力欄に入力する。このとき、直接減額の希望金額入力欄に入力された金額h円を基に図79のグラフからa2円が抽出される。そして、このa2円がユーザ貯金箱に入れられ、一方h円が直接減額される。ここに、数5の関係がある。
(数5)
現金還元総額T0=a2+h+e
ここに、e円は、(イ)の特性からの差額分である。即ち、現金還元総額T0>T1(=a2+h)であり、第3実施形態と同じ直接減額分h円が直接減額の希望金額入力欄に入力された場合であっても、ユーザ貯金箱に入れられる金額(a2円)はe円分だけ小さくなっている。このため、a2円と直接減額分h円の合計である現金還元総額T1円も第3実施形態の現金還元総額T0円より小さくなっている。
直接減額の希望金額h円とユーザ貯金箱に入れられる金額(a2円)とはユーザ5に対して提示され、ユーザ5がこの額で納得した場合には、図示しない決定ボタンをクリックすることで額が決定されるが、この額に納得しない場合には、ユーザ5は、設定見直しボタンをクリックする。この場合、再びなにがしかの希望金額h円を直接減額の希望金額入力欄に入力する。以降は同様の処理が行われる。
なお、図78、図79の特性はリニアとしたが、曲線等であってもよい。また、(ロ)の特性と、それよりも上側に湾曲された特性と下側に湾曲された特性とをそれぞれ用意し、ユーザ5に対してくじ等でいずれかの特性を選択させるようにされてもよい。あるいは、ユーザ5のお得意様状況の段階如何によって自動的に特性が選択されるようにしてもよい。この場合には、お得意様段階の高い人は上側に湾曲された特性が採用される。
以上により、ユーザ5が直接減額の希望額V円を高く希望すればする程、ユーザ貯金箱に入れられる仮想現金は小さくすることができる。従って、販売促進に繋げられると共に、ユーザ貯金箱に仮想現金が貯められていることで次回の購入もされやすい。直接減額を可能とするか否か、ユーザ貯金箱に入れられる仮想現金を認めるか否か、また、直接減額分をどの程度大きくするか、ユーザ貯金箱に入れられる仮想現金をどの程度大きくするか等、商店等7の希望も配慮されるため、商店等7側に受け入れられやすいシステムにできる。
次に、本発明の第26実施形態について説明する。本発明の第26実施形態では現金還元についてもまとめて値引きを考慮したものである。図80に本発明の第26実施形態のフローチャートを示す。図80において、ステップ2401では「まとめて値引き」ボタンをクリックする。次にステップ2403で、値引き交渉又は現金還元の可能な商品やサービスについて、各商品等毎に値引き交渉とするのか現金還元にするのかを選択する。ステップ2405では、選択されたものの内現金還元のされる商品を抽出する。そして、ステップ2407では、現金還元のされる商品について購入総額R円を算出する。但し、この際には、購入総額R円について総額−率テーブル表より更なる還元額若しくは還元率を求めるようにされてもよい。この場合には直接減額される金額の合計か若しくはユーザ貯金箱に入れられる結果の貯金額が増やされる。
次に、ステップ2409では、現金還元の内、ユーザ5の指定によらず、予め商店等7側で無条件に直接減額する金額の合計J円が算出される。そして、ステップ2411では、この合計J円がユーザ5に対して表示される。一方、ステップ2413では、現金還元の内、ユーザ5が指定可能な直接減額分限度額の合計K円を算出する。ステップ2415では、この合計K円がユーザ5に対して表示される。ステップ2417では、この直接減額分限度額の合計K円に対してユーザ5が直接減額希望金額欄にL円を入力する。
ステップ2419では、各商品毎の直接減額分を求める。この各商品毎の直接減額分は、数6で現される。
(数6)
各商品毎の直接減額分=各商品毎の直接減額分限度額kn×L/K
その後、ステップ2421では、ステップ2419で算出された各商品毎の直接減額分を基に各商品に対応した図78若しくは図79の直接減額分−ユーザ貯金額の関係グラフ又はテーブルからユーザ貯金箱に入れられる金額が算出される。ステップ2423では、各商品毎の直接減額分とユーザ貯金箱に入れられる金額とがWebページにてユーザ5に対し表示される。ステップ2425では、ユーザ5に対し問い合わせがされ、ユーザ5がこれでよければ次のステップ2427で現金還元である各商品毎の直接減額分とユーザ貯金箱に入れられる金額とが確定され、次のステップ2429に進む。一方、ユーザ5が不満のある場合には、ステップ2407からの処理が繰り返される。
次にステップ2429では、選択されたものの内、値引き交渉のされる商品が抽出される。そして、ステップ2431では、本発明の第4実施形態等で説明したまとめて値引き交渉の処理がされる。
このようにまとめて現金還元処理とまとめて値引き交渉処理とをシリーズに処理してもよいが、Web画面上に両処理を併記することで現金還元処理の直接減額希望金額欄への入力と値引き交渉処理の希望購入金額欄への入力とを同時に行えるよう並列表記されてもよい。
または、現金還元処理については、総現金還元額の全額がユーザ貯金箱に入金されるとして、値引き交渉処理の希望購入金額欄への入力のみが行えるようにされてもよいし、あるいは、総現金還元額の全額が直接減額されるとして、値引き交渉処理の希望購入金額欄への入力のみが行える等されてもよい。直接減額分とユーザ貯金箱に入金される金額とが予め設定された額にて行われるものとされてもよい。これらを選択可能なボタンが用意されてもよい。
以上により、複数の商店等7にまたがり、複数の商品等がまとまって現金還元された場合であっても各商品毎に現金還元額を分離できる。直接減額分とユーザ貯金箱に入金される金額との割合が各商品毎に異なる場合であっても各商品毎に還元額及びユーザ貯金箱に入金される金額を分離可能である。
なお、以上の実施形態は、ポイント制に基づき割引分としてのポイントが付与される場合に対して適用されることも可能である。
次に、本発明の第27実施形態について説明する。本発明の第27実施形態ではロボット店員による音声対応及びユーザによる音声入力により操作の簡単化を考慮したものである。図81及び図82に本発明の第27実施形態のフローチャートを示す。図81及び図82において、ステップ2500では、まずユーザ5がWWWサーバー3のサイトにオンライン接続する。このとき、ステップ2501でロボット店員がユーザ5に対して挨拶をする。次にステップ2503では、ロボット店員が「探し物は何ですか?」との問を発する。この問は、WWWサーバー3からインターネット通信を介して音声によりユーザ5に対して行われる。
ステップ2505では、ユーザ5が返事をする。返事は、例えば「パソコンです。」のようにされる。この返事は、音声によりユーザ5のパソコン等に接続されたマイクや携帯電話のマイク等を通して行われる。なお、これに先立ち、ユーザ5は音声を送信データに変換し、かつWWWサーバー3側に送信可能なソフトウェアをダウンロードし、ユーザ5のパソコンにインストールしているものとする。音声データはパケット化される等して送信される。あるいは、音声ファイルとしてWWWサーバー3に対し送信されてもよい。送信されたデータは、WWWサーバー3側で受信され、解析された後、このデータはデータベースに保存される(以下、同旨)。解析に際しては返事の文言の中から助詞、助動詞、形容詞、副詞、接続詞等を排除し、商品名である名詞を抽出する。
ステップ2507では、この受信されたデータによりユーザ5が何を探しているのかを特定する。この特定は、データベースに予め保存されたデータの中に一致する商品名(若しくはジャンル)のデータが存在するか否かで判断される。特定された場合には、ステップ2509に進む。一方、特定できなかった場合にはステップ2510で処理を終了するか、若しくは次に用意された別の処理に進む。ステップ2509では、ロボット店員が「メーカー名が分かれば教えて下さい。」との問を発する。この問に対してユーザ5はステップ2511で音声により返事を行う。音声データは送信データに変換され、WWWサーバー3側で受信され、このデータはデータベースに保存される。ステップ2513では、この返事によりメーカー名が特定されたか否かが判断される。この特定は、データベースに予め保存されたデータの中に一致するメーカー名のデータが存在するか否かで判断される。
特定されたならば、ステップ2515に進み、ロボット店員が「型式が分かれば教えて下さい。」との問を発する。この問に対してユーザ5はステップ2517で音声により返事を行う。ステップ2519では、この返事により型式が特定されたか否かが判断される。この特定は、データベースに予め保存されたデータの中に一致する型式のデータが存在するか否かで判断される。特定されたならば、ステップ2521に進み、商品を表示する。一方、ステップ2513、ステップ2519で特定されていないと判断された場合にはステップ2527へと進む。ステップ2523でユーザ5が、購入を選択した場合には、ステップ2525で値引き交渉又は現金還元が行われる。この値引き交渉又は現金還元において、ユーザ5による金額の入力に代えて、金額が音声入力されるようにされてもよい。音声入力された金額はインストールされているソフトウェアにより数値変換されてWWWサーバー3に対し送信される。あるいは、この数値変換は、WWWサーバー3側で行われるようにされてもよい。
ステップ2527では、ロボット店員が「予算は幾らですか?」との問を発する。この問に対してユーザ5はステップ2529で予算金額をマイクを通じて音声入力したり、あるいはキー操作により入力する。そして、ステップ2531では、当該商品につき予めデータベースに保存されている仕様を提示し、ロボット店員が「欲しい仕様の番号を言って下さい。」との問を発する。仕様の提示は、例えば図54のステップ1655等の通りである。この問に対してユーザ5はステップ2533で欲しい仕様の番号をマイクを通じて音声入力したり、あるいはキー操作により入力する。この辺りの処理は既に各実施形態で述べた処理と同様に可能である。その後、WWWサーバー3側では、受信されたデータに基づき検索が行われ、商品の絞り込みがされる。そして、ステップ2535では、絞り込みのされた結果の商品データをユーザ5に対して提示する。ロボット店員が「この商品ではどうですか?この中から一つ選択して下さい。」等の問を発する。その後、ステップ2519からの処理が行われる。商品が特定されなければ、再び、ステップ2527で予算の見直しを行い同様の処理を行う。
以上により、ロボット店員の動画像を見ながら、音声対応でユーザは商品を楽しくかつ簡単に購入できる。キー操作の不慣れな人にとっても使い易い。
なお、上述した各実施形態について本実施形態と同様にロボット店員を配置し、同様な音声対応とすることも可能である。
次に、本発明の第28実施形態について説明する。本発明の第28実施形態ではユーザ5が貸し店舗形式で加入した複数の商店等7と同時にまとめて一気に値引き交渉を行う場合である。ユーザ5が希望の商品について一店舗ずつ値引き交渉を行うのが煩わしいといったような場合に適用される。WWWサーバー3側にはデータベースが配設され、ユーザ5はインターネット1等の通信を介してこのWWWサーバー3の提供するサイトにアクセス可能である。このサイトには複数の商店等7が貸し店舗形式で加盟している。
図83〜図85までに本発明の第28実施形態の動作フローを示す。また、図86にはWebページの画面例を示す。まず、図83のステップ2901において、ユーザ5がWWWサーバー3の提供するサイトのページにアクセスし、このページにおいて「複数の店とまとめて交渉」ボタンを押す。ステップ2903ではユーザ5はユーザID入力画面にてユーザIDを入力する。ステップ2905では、ユーザIDがデータベース1009に保存されているデータと一致するか否か確認され、未登録のユーザの場合には新規登録が行われる。
ステップ2907では、商品を指定する。即ち、図86において、商品名入力欄2021に商品を指定し、メーカー名入力欄2023にメーカー名を指定、型式の存在する場合には型式入力欄2025に型式を入力する。商品名等はキー入力されてもよいし、予め登録されたデータの内から選択されるようにしてもよい。ユーザ5により音声で入力されるようにしてもよい。そして、ステップ2909では、「交渉可能な商店を表示」ボタン2041を押して検索を実施する。ステップ2911では、全商店の中から、値引き交渉可能な商店が抽出されて表示される。ステップ2913では、この抽出された値引き交渉可能な商店の中からユーザ5自身がまとめて値引き交渉したい商店を選択する。但し、ユーザ5がまとめて交渉したい商店を絞らずに全商店について交渉されるようにされてもよい。ステップ2915ではこの選択された商店の件数tを算出する。
ステップ2917では、ユーザ5に対してWeb画面上で「値引き交渉権をs回分使用します」と表示される。このs回分は選択された商店の件数tに応じて変化されてもよいし、予め設定された回数分が使われるようにされてもよい。車等の高額商品についてはたくさんの回数を消費するようにする。また、後述する2回目の交渉と1回目の交渉とで変えられるようにされてもよい。キャンセルボタンが押されればステップ2921で処理は終了する。ステップ2917で了解されれば、ステップ2919に進みユーザ5が希望購入価格入力欄2027にこの商品の希望購入価格Z円を入力し、入力後ステップ2923で値引き交渉ボタン2043をクリックする。ステップ2925では、カウンタrの値に1を設定する。そして、ステップ2927では、まず1店目のデータをデータベース1009より抽出する。このデータは各店舗毎の当該商品に対する標準販売価格、底値、実数m値等である。ステップ2929では、値引き交渉処理が実施される。
この値引き交渉処理は、図16の所で既に説明したのと同様に中間額E=(X−(1−m)Y)/mと希望購入価格Zとが比較される。そして、中間額E円が希望購入価格Z円以下のときステップ2935でメモリーUr1にZ円が保存される。一方、中間額E円が希望購入価格Z円を超えているとき、ステップ2933で底値Yが希望購入価格Zを超えるか否か判断される。底値Yが希望購入価格Zを超えているときステップ2937で中間額E円がメモリーUr2に保存される。ステップ2933で底値Yが希望購入価格Z以下のときにはステップ2935でメモリーUr1にZ円が保存される。
ステップ2939では商店件数がtに至るまでステップ2925に戻り、2件目以降の商店に対し同様の値引き交渉をする。値引き交渉された結果は随時ステップ2935若しくはステップ2937でデータ保存される。そして、ステップ2941では、商店の名称、交渉結果価格(Ur1、Ur2)等をまとめて図86に示すような交渉結果リストのWebページが作成される。この交渉結果リスト2031には、商店名称欄に商店名、東京等の営業所所在地、値引き交渉された交渉結果の金額、送料、特典等が記載されている。この交渉結果については、ボタン2029で商店名順に表示したり、交渉結果が安い順に表示すること等が選択可能なようになっている。特典2033にはおまけのある場合やポイント制を採用している場合ににその内容の詳細が閲覧できるようになっている。
なお、図86では、中間提示額E円をも各店毎に提示する例を示したが、中間提示額E円を提示せずに「この価格では当店では売れない」と表示してもよい。あるいは、この価格で販売できない場合には空欄とされてもよい。この交渉結果リスト2031を見て、ユーザ5が交渉のやり直しを希望する場合には、ステップ2945で「値引き交渉をもう一度やり直す」ボタン2035を押す。
ステップ2955で2回目を超えたか否か判断され、超えていた場合にはステップ2959で処理を終了する。2回目の場合にはステップ2957に進み実数m値の値を一段上げる。そして、以降、ステップ2909に戻りステップ2909からの処理を繰り返す。但し、1回目の交渉でユーザ5によりステップ2913で選択された商店等7を記憶しておき、ステップ2917に戻りステップ2917からの処理が繰り返されるようにしてもよい。ユーザ5が交渉のやり直しを希望しない場合には、ステップ2961で処理が終了する。
一方、ユーザ5がステップ2943において、この交渉結果ページから購入したい商店を一つ選択し、ステップ2947で図示しない購入ボタンを押すと、ステップ2949で交渉が成立する。この際には、ユーザ5はステップ2951で支払方法の選択を行う。ステップ2953では、購入された商品情報が商店等7に対しWWWサーバー3のサイトから送信される。
ステップ2947で購入ボタンが押されない場合には、ステップ2963でこの商店で交渉をやり直すか、若しくはステップ2965でステップ2955に戻り最初からもう一度やり直すかを選択できる。「この商店で交渉をやり直す」が選択された場合には、ステップ2967で「値引き交渉権をv回分使用します」と表示がされる。このv回は、通常は1回であり、s回よりも小さい。キャンセルがクリックされた場合にはステップ2971で処理が終了する。了解されるとステップ2969で2回目を超えているか否かが判断される。3回目ならばステップ2975で処理が終了される。2回目ならば、ステップ2973で実数m値の値を一段上げる。そして、ステップ2977で今回購入したい商店として選択されている商店の底値等のデータをデータベース1009より抽出する。そして、ステップ2981で値引き交渉処理を実施する。その後、既に説明したステップ2931、ステップ2933の処理が行われ、ステップ2935、ステップ2937で算出された交渉結果が保存される。そして、ステップ2989ではステップ2935で保存された交渉結果に対し「Z円で販売します」とユーザ5の入力された金額で販売する旨の表示がされ、一方、ステップ2933では、ステップ2937で保存された交渉結果に対し「Ur2円でどうですか?」と商店等7側の提示価格が表示される。ステップ2995で購入ボタンが押された場合にはステップ2998で「Ur円で販売します」と表示される。一方、ステップ2997でキャンセルボタンが押された場合にはステップ2999で処理が終了する。
以上により、ユーザ5は各店舗毎に値引き交渉をするということなく複数の商店についてまとめて値引き交渉が可能となる。このため、どの店が最も安く購入で競うか、若しくは最も安く購入できるか簡単かつ迅速に判断可能となる。購入したい商店も選択した上で値引き交渉可能なので便利である。
なお、本発明の第25実施形態等で述べたように、現金還元額の内、直接減額される金額を希望金額入力欄に入力する場合においても本実施形態を適用可能である。即ち、貸し店舗形式で加入した複数の商店等7を相手に、同一の直接減額される金額に対しユーザ貯金箱に入れられる仮想現金の額を一度に得ることができる。
この場合にはまず、検索によりステップ2911では直接減額の可能な商店が表示される。そして、ステップ2919では希望金額入力欄に直接減額の希望額を入力すると、ステップ2927以降の処理でユーザ貯金箱に入れられる仮想現金の額(ポイント制が導入されていればポイント)が各商店等7毎に演算されステップ2941でまとめて表示される。ステップ2943でユーザ5がこの結果ページから購入したい商店等7を一つ選択し、ステップ2947で購入ボタンを押せば商品等を購入することができる。但し、ステップ2955の2回目以降の処理やステップ2963以降の処理は値引き交渉に必要な処理なので省略される。
次に、本発明の第29実施形態について説明する。本発明の第29実施形態では貸し店舗形式で加入した商店等7及び求職者であるユーザ5に対しWeb上で自動により簡便なリクルート手法を提供するものである。
図87〜図92に本発明の第29実施形態のフローチャートを示す。図87及び図88は、まず就職希望者の側から企業や商店等に対し就職のアプローチをする場合である。図87において、ステップ2601では、まず就職希望者であるユーザ5がWWWサーバー3のサイトにオンライン接続する。そして、予め就職希望者登録情報をWWWサーバー3のデータベース1009に対し登録する。この就職希望者登録情報は、例えば氏名、性別、年齢、住所、電話番号、メールアドレス、写真等の履歴書に記載される事項、職務経歴である。また、本人を撮影した動画(音声付きが望ましい)等がデータベース1009に保存されるようにしてもよい。一方、貸し店舗形式の店舗に関し、リクルート項目を各商店や各サービス店のWebページに載せる。
なお、各商店や各サービス店がリクルート中であることは検索によっても分かる。例えば、検索の項目に現在リクルート中の商店等7を選択する項目を設けることで抽出可能である。現在リクルート中の商店等7であることは、データベース1009に保存されたリクルート期間を検索することで分かる。ユーザ5が商店や各サービス店のWebページやリクルート情報を閲覧し、商店等7に面接を希望した場合には、ステップ2603でリクルート項目中の面接希望ボタンを押す。その後、ステップ2605では、ログイン画面にてユーザIDを入力する。
ステップ2607では、履歴書の情報の一部がデータベース1009より抽出される。このとき、履歴書の情報としては、氏名、住所、電話番号、メールアドレス、写真あるいは本人の動画(音声付きが望ましい)等は掲載されずにその他の情報が抽出される。但し、このときに写真あるいは本人の動画(音声付きが望ましい)等が掲載されるようにしてもよい。写真あるいは本人の動画、音声付きとするか否かはユーザ5本人の選択事項とされてもよい。ステップ2609では、この履歴書の情報の一部の掲載された電子メールが商店等7に送信される。なお、電子メールではなく、ファックス等で履歴書の情報の一部を掲載した情報等が送受信されてもよい(以下、同旨)。
ステップ2611では商店等7がこの電子メールを受信する。そして、商店等7が希望する場合にはステップ2613でセンターサーバー1008の商店閲覧画面にログインする。但し、ログインはこのように商店閲覧画面にてログインIDを入力することでサイトに入り行ってもよいが、電子メールに記載されたURLが選択されることで専用のページに飛んで以降の処理がされてもよい。また、専用のページに飛ぶことなく、電子メールに記載された事項に応答し返信、若しくは電子メール中の特定のURLが選択され送信されるだけでセンターサーバー1008側では返答とみなし、以降の処理が完結されるようにしてもよい。
商店閲覧画面には、ユーザID、年齢、ユーザによる送信日時、商店による面接受諾ボタン、面接希望日時入力欄等が記載されている。そして、ステップ2615では、商店閲覧画面から面接を受諾するユーザIDを選択し、ステップ2617で面接希望日時の候補を少なくとも一つ指定する。この指定は、センターサーバー1008にてWebページに掲載されたカレンダーに従って入力されることが望ましい。
ステップ2619では、商店閲覧画面の中の面接を受諾するユーザIDに対して面接受諾ボタンを押す。面接の受諾された旨はセンターサーバー1008に記録されると同時に、ステップ2621で就職希望者に対し自動配信で受諾の旨の電子メールが送信される。ステップ2623で就職希望者が電子メールを受信する。この就職希望者は、ステップ2625でセンターサーバー1008にログインし、ステップ2627で商店等7より指定された面接希望日時の候補の中から一つを選択する。ログインはユーザ閲覧画面にてログインIDを入力することでサイトに入り行ってもよいが、電子メールに記載されたURLが選択されることで専用のページに飛んで以降の処理がされてもよい(以下、同旨)。
このことにより、ステップ2629では、センターサーバー1008より正式な全経歴情報を商店に対し電子メールにて自動配信する。この全経歴情報には、ステップ2607とは異なり、履歴書の情報のすべてがデータベース1009より抽出される。ステップ2631では、商店等7が全経歴情報及び面接日時の記載された電子メールを受信する。 なお、正式な全経歴情報等は、ステップ2619で面接受諾ボタンが押されたときにセンターサーバー1008より送信されるようにされてもよい。
ステップ2633では、商店等7がセンターサーバー1008にログインし、ステップ2635でこのユーザIDの就職希望者との面接について確認(了解)した旨のWebページの確認ボタンを押す。なお、ログインは商店閲覧画面にて行ってもよいが、電子メールに記載されたURLが選択されることで専用のページに飛んで確認処理がされてもよい(以下、同旨)。 この際には商店等7からメッセージ記入欄にメッセージが記入されることが望ましい。この確認ボタンが押されると、ステップ2637では、確認メッセージがユーザ5に送信される。
ステップ2639で商店等7と就職希望者であるユーザ5との間で面接が行われる。面接の実施後、ステップ2641では、商店等7がセンターサーバー1008の商店閲覧画面にログインする。そして、ステップ2643で商店閲覧画面上で採用、不採用、キャンセルのいずれかの項目を選択する。選択された項目はセンターサーバー1008のデータベース1009に保存されると共にユーザ5に対して送信される。ところで、ステップ2645では、就職希望者に対し所定期間以内に電子メールが送信されたか否かが判断される。所定期間は採用に際しての検討時間であり、例えば5日〜14日程度である。この所定期間が経過している場合にはステップ2651で問い合わせの電子メールが商店等7に対して送信される。但し、就職希望者に対しても問い合わせの電子メールが送信されてもよい。問い合わせの電子メールは、1回ではなく、一定期間経過毎に複数回行われるようにされてもよい。ステップ2647で延長期間が設定されている場合には、ステップ2649でこの延長期間の経過後に問い合わせの電子メールが送信される。なお、問い合わせの結果、商店等7がステップ2641からの処理を行った場合には、ステップ2645での所定期間以内かどうかの判断はされない。
ステップ2653で就職希望者が内定した場合には、ステップ2655でこの就職希望者に対して、値引き交渉権が例えば10回分付与され、また商店等7の有するユーザ貯金箱に例えば1万円の貯金が加算される。あるいは、WWWサーバー3のサイトの運営者において用意されたユーザ貯金箱に貯金されるようにしてもよい。ユーザ5はこのユーザ貯金箱の貯金を利用して当該商店やWWWサーバー3のサイトの運営者より商品を購入することができる。このように、ユーザ5に対して特典を付与することで利用が促進される。一方、商店等7側にとってはユーザ5に対して本システムを介して返事をする義務が生ずることになるので、本システムの円滑な運用が図れる。
なお、面接実行回数に対する採用、不採用、キャンセル等のいずれかの返事を商店等7側がユーザ5に対して送信した比率を演算し、公表することが望ましい。返事をしなければ企業としての評判が悪くなるので企業側は注意せざるを得なくなる。このように、企業の評価をすることで、企業の不正を防止する。このため、例えば、内定率(内定者数/申し込み者数)を演算したり、面接受諾率を演算する。若しくは、内定が出るまでの平均日数や面接がされるまでの平均日数を演算する。更に、以上の評価項目を点数評価したり、重み付け処理をし、合計する。そして、これらの演算結果をホームページ上に評価基準として掲載する。更に、ユーザ5の平均ユーザ貯金箱への入金取得額やユーザ5の平均値引き交渉可能回数取得数を掲載するようにしてもよい。
以上により、Web上で円滑なリクルート活動の支援が可能となる。企業側からの対応も速やか、かつ確実に行われるようになる。省力化されているため求職、求人情報を安価に提供できる。各商店等へのリクルート絡みのアクセス数が増加するので販売増及び宣伝効果増に結びつくと共に、ユーザへの特典が付与されることで各商店等の購入が一層増加される。
次に、本実施形態の別形態について説明する。図89及び図90は、企業や商店等側から就職希望者側に対し就職のアプローチをする場合である。なお、図87及び図88と同一要素のものについては同一符号を付して説明は省略する。
図89において、ステップ2701では、まず、ユーザ5から就職希望者としての登録情報を集める。この登録は、ユーザ5がWWWサーバー3のサイトのホームページ上で所定の欄にキー入力等により行われるのが望ましい。そして、集められた登録情報は登録者情報としてデータベース1009に保存しておく。
ステップ2703では、商店等7側がセンターサーバー1008にログインし、ステップ2705で商店等7は就職希望者を検索する。検索項目はジャンルや年齢、勤務地、希望給与等である。ジャンルは今後就きたい職や、これまでに経験した職、実務能力を有する職等である。
ステップ2709では、検索結果として一致するデータが存在する場合に、登録情報の内のごく一部のみを抜粋してホームページにて掲載する。この情報はステップ2607で記載した情報の一部よりずっと少ない情報である。例えば、年齢、職歴、学歴の抜粋、自己PR文程度である。そして、この情報を見た商店等7が興味を持った就職希望者が存在する場合には、ステップ2711で商店等7は履歴情報希望ボタンを押す。このとき、ステップ2713では、履歴書の情報の一部がデータベース1009より抽出される。この履歴書の情報の一部はステップ2607で記載した情報と同じである。
ステップ2715でこの履歴書の情報の一部を掲載した電子メールが商店等7に対し送信される。ステップ2717では、この履歴書の情報の一部を読んで商店等7側では面接を希望する就職希望者を絞り込む。そして、絞り込んだ就職希望者に対し商店等7は、ステップ2719で商店閲覧画面にログインで入り、商店閲覧画面上で面接希望日時の候補を少なくとも一つ指定した上で、ステップ2721でこの就職希望者に対し商店閲覧画面上に配設された面接希望ボタンを押す。このとき、ステップ2723でセンターサーバー1008より就職希望者に対し電子メールが送信され、ステップ2725でこの就職希望者が電子メールを受信する。この電子メールには、商店等7の企業情報及び当該就職希望者に対し面接を希望する旨の記載がされている。
その後、ステップ2727では、就職希望者が望めばセンターサーバー1008の指定画面にログインする。そして、ステップ2729では、指定画面の中の面接を受諾する商店IDに対して面接受諾ボタンを押し、かつステップ2731では、就職希望者がこの指定画面上に表示された面接希望日時の候補の中から一つを選択する。この面接希望日時の候補はステップ2719で予め商店等7により設定されたものである。このとき、ステップ2733で商店等7に対し自動配信で受諾の旨の電子メールが送信される。そして、同時にステップ2735で正式な全経歴情報が商店等7に対し自動配信される。その後はステップ2639で面接が行われ、以降ステップ2641からの処理が同様に行われる。
以上により、商店等7が希望する人材を容易に得ることができる。省力化されているため求職、求人情報を安価に提供できる。
次に、本実施形態の更なる別形態について説明する。図91及び図92は、WWWサーバー3のサイトの運営者より就職希望者の情報を企業や商店等に対し随時提供し、これらの就職希望者の情報の中から企業や商店等側が面接を望む就職希望者が存在した場合に就職希望者側に対し就職のアプローチをする場合である。なお、図87及び図88と同一要素のものについては同一符号を付して説明は省略する。
図91において、ステップ2801では、まず、ユーザ5から就職希望者としての登録情報を集める。この登録は、ユーザ5がWWWサーバー3のサイトのホームページ上で所定の欄にキー入力等により行われるのが望ましい。この場合、写真等は画像ファイルとして保存される。そして、集められた登録情報は登録者情報としてWWWサーバー3のサイトのデータベース1009に保存しておく。また、これに先立ち、予め商店等7に対してどのようなジャンルの人材を探しているのか、あるいは、どのような年齢や経歴の人材を探しているのか等をWWWサーバー3のサイトのホームページ上で所定の欄に入力してもらっておくことが望ましい。または、WWWサーバー3のサイトの管理者側でこれらの情報を予め入力しておいてもよい。これらのデータは求人情報としてWWWサーバー3のサイトのデータベース1009に保存しておく。
ステップ2803では、このような商店等7の求人情報を基に希望に合いそうな就職希望者がWWWサーバー3のサイトの管理者により検索若しくは抽出され、その履歴書の情報の一部がデータベース1009より抽出される。あるいは、サイトの管理者によらず、商店等7の求人情報を基にデータベース1009から自動で検索されてもよい。そして、ステップ2805では、この履歴書の情報の一部を掲載した電子メールが商店等7に送信される。履歴書の情報の一部には少なくとも一人の就職希望者の情報が含まれている。ステップ2807では、商店等7がこの電子メールを受信する。なお、電子メールではなく、ファックス等で履歴書の情報の一部を掲載した情報等が送受信されてもよい。
商店等7がこの履歴書の情報の一部を見て就職希望者との面接等の希望が生じた場合には、ステップ2809に進み商店等7がセンターサーバー1008の商店閲覧画面にログインする。この際、商店等7が未登録の場合には商店等7の情報をまず登録する。そして、ステップ2811では、商店閲覧画面に掲載された面接を希望するユーザ5の一覧の中から希望のユーザIDを選択した上で面接希望ボタンを押す。
このとき、ステップ2813では、このユーザIDを有する就職希望者に対しセンターサーバー1008より自動配信で商店側からの面接希望の旨を記載した電子メールが送信される。ステップ2815で就職希望者がこの電子メールを受信する。就職希望者が商店等7に興味を抱いた場合にはステップ2817に進み、就職希望者がセンターサーバー1008にログインする。ログインするとユーザ閲覧画面が開かれる。このユーザ閲覧画面には面接希望のあった商店等7のURLが記載されており、このURLから商店等7のリクルートページや業務内容のページを参照できるようになっている。但し、就職希望者に対し送信される電子メールに面接を希望する商店等7の求人情報が記載されてもよい。商店等7の求人情報はセンターサーバー1008のデータベース1009に予め登録されていることが望ましい。
ステップ2819で、ユーザ5が商店側からの面接希望を受諾する場合には、このユーザ閲覧画面上で面接受諾の旨と面接希望日時の候補を少なくとも一つ指定する。このとき、ステップ2821では、商店等7に対し自動配信で受諾の旨の電子メールが送信される。これに対し、ステップ2823では、商店等7がセンターサーバー1008にログインし、ステップ2825では、商店等7はステップ2819で指定された面接希望日時の候補の中から一つを選択する。選択された情報はデータベース1009に保存され、ステップ2827でセンターサーバー1008より正式な全経歴情報が商店等7に対し電子メールで自動配信される。ステップ2829では、商店等7がこの全経歴情報及び面接日時を受信する。ステップ2831では、この電子メールを受け取り、記載された情報を確認した旨を伝えるため商店等7がセンターサーバー1008にログインし、かつステップ2833で確認ボタンを押す。この確認された旨はステップ2835で確認メッセージとしてユーザ5に対し送信される。この確認メッセージには、商店等7が確認した旨と面接日時や場所等が記載されている。その後はステップ2639で面接が行われ、以降ステップ2641からの処理が同様に行われる。
以上により、商店等7に対し適材と思われる人材が随時推奨されるので商店等7は希望する人材を容易に得ることができる。省力化されているため求職、求人情報を安価に提供できる。
なお、本実施形態の機能は貸し店舗形式で加入された商店等7のWebページの一部にアイコンが埋設され、リンクされた機能とされてもよいし、商店等7の自前のホームページのリクルート欄に所定のアイコンが埋設され、このアイコンがクリックされることでセンターサーバー1008に繋がり、本実施形態の機能が動作されてもよい。あるいは、就職専門のサイトとして構築されてもよい。
次に、本発明の第30実施形態について説明する。本発明の第30実施形態は第5実施形態〜第8実施形態で説明した実際に商品等が店頭販売される場合の別態様についてである。図93に本発明の第30実施形態のフローチャートを示す。なお、図34〜図37と同一要素のものについては同一符号を付して説明は省略する。図93において、ステップ1351では、ユーザ5はスーパー等の各商店等7に赴き、この店内において買い物をする。そして、購入したい商品を買い物かごに入れる。なお、図37と同様にステップ1225〜ステップ1231の処理が行われるようにされてもよい。
ステップ1233で集計され、ステップ1235でレジ1111に合計金額を表示する。その後、その商店等7において用意、かつ配布され、ユーザ5が保持している専用カードが読み取り装置に通される。この専用カードには予め登録されたユーザ5のユーザID等のデータが磁気により保存されている。あるいは、ユーザ5のユーザID等のデータを保存したICチップが埋設されている。読み取り装置では、これらのデータが磁気的に読み取られ、センターサーバー1008に通信回線を通じて送信される。なお、専用カードを忘れたユーザ5に対しては、以下のように処理することでユーザ5を特定可能である。まず、レジ係がセンターサーバー1008のデータベース1009にアクセスした状態で、ユーザ5から聞き出した電話番号の下4桁を入力する。このとき、センターサーバー1008でユーザの検索が行われ、電話番号の下4桁の一致するユーザ5のデータが少なくとも一人分抽出してレジ係に対して表示される。次に、レジ係はユーザ5から聞き出したユーザ5の氏名を基にこの表示されたデータの内から一つ選択することでユーザ5を特定できる。また、センターサーバー1008のデータベース1009にアクセスした状態で、ユーザIDを直接入力するようにされてもよい。
次に、ステップ3113では、レジ1111にてユーザ5により実際に支払がなされる。そして、ステップ3115ではレシートが発行される。このレシートには、購入日、購入店、ユーザID、購入品名、支払金額等が表示される。但し、電話番号の下4桁、ユーザの氏名等が記載されてもよい。これらのデータはステップ3117でセンターサーバー1008のデータベース1009に保存される。ステップ3119では、購入日から所定期間(例えば10日)以内か否かが判断される。そして、所定期間内の場合には、ステップ3121でパソコン又は携帯電話からセンターサーバー1008に接続し、個別の商品毎に、あるいは購入回毎にまとめて値引き交渉がされる。この値引き交渉については各実施形態で述べた通りである。ステップ3125では、値引き交渉による決定金額が算出される。そして、ステップ3127では支払金額から決定金額が差し引かれ、ステップ3131ではこの差額がユーザ貯金箱に貯金される。そして、ステップ3133では、この事実がユーザ5に対し電子メールで伝えられる。一方、ステップ3119で所定期間を経過した場合には、ステップ3129で各商品毎に設定された現金還元額が合計され、ステップ3131でこの現金還元額の合計がユーザ貯金箱に貯金される。ステップ3133では、この旨がユーザ5に対し電子メールで伝えられる。
ユーザ貯金箱に貯金された仮想現金は次にユーザ5が商品等を購入する際に利用できる。この場合、ユーザ5はWWWサーバー3のサイトの管理者側で運営する貸し店舗である当該商店等7のWebサイトに接続し商品等を購入する際にユーザ貯金箱から仮想現金を引き出して使うことが可能である。あるいは、当該商店等7が自前で有する当該商店等7のWebサイトに接続し、ユーザ5が商品等を購入する際に、このWebページに埋設されたアイコンがユーザ5によりクリックされることでWWWサーバー3のサイトにリンクされ、この仮想現金を引き出して使う処理ルーチンがWWWサーバー3のサイト側で動作されるようにしてもよい。更には、レジ1111にてステップ3113で支払を行う際にセンターサーバー1008に接続し、ユーザ貯金箱から仮想現金を引き出してその場で使う等されてもよい。この場合には、レジ係が貯められた仮想現金の内の幾ら分を使うかをユーザ5から聞き出して入力操作を行う。
なお、上記では1回の支払単位に値引き交渉を行うとして説明したが、月単位に複数の支払回分をまとめて値引き交渉をしてもよい。このとき、複数の商品をまとめて値引き交渉や現金還元処理する必要があるが、この処理については本発明の第4実施形態の説明で述べた通りである。また、各ユーザ毎に複数の異なる商店分について月単位にまとめて値引き交渉や現金還元処理をしてもよい。このとき、複数の商品について複数の商店にわたりまとめて値引き交渉や現金還元処理する必要があるが、この処理についても本発明の第4実施形態の説明で述べた通りである。更に、本発明の第4実施形態の説明で述べたように、まとめたことで更なる値引きがされるように処理されてもよい。更に、本実施形態ではレジ1111にて購入する場合について説明したが、本発明の第7実施形態のようにテレビショッピング等で商品が購入された場合についても同様に適用可能である。
なお、月単位にまとめた購入履歴は、ユーザ5に対してWWWサーバー3のサイトの管理者側で閲覧や印刷可能とすることが望ましい。
以上により、ユーザは商店で商品を購入後、値引き交渉により自分の意思で支払金額が減額されることになるので、買い物が楽しく行える。また、値引き交渉がユーザにより行われなかった場合であっても現金還元の処理がされるので、ユーザにとっては安心である。従って、本システム利用に伴い、商店等の売上増にも繋がる。
更に、ユーザは商品購入後も値引き交渉等のためWWWサーバー3のサイトのショップ等を頻繁に訪れることになるので、サイトのアクセス数が増大し販売の増加や宣伝効果の増大に繋げることができる。
次に、本発明の第31実施形態について説明する。最近、例えば個人同士の取引をネット上で行う場合、支払をしても購入した商品が届かなかったり、商品を届けても支払が行われなかったりする事例が多く報告されている。そこで、本発明の第31実施形態はユーザ貯金箱を利用することで、ネット上の取引(特に個人同士の間で行われる取引)がこのような支障なく安全に行われ、かつ銀行等への振込手数料やカード会社等への手数料が無料若しくは格安にでき、更に買い物を一層便利にすることができるシステムを提供するものである。
図94に本発明の第31実施形態のフローチャートを示す。図94において、ステップ3151では、商品購入者によりネット上で商品購入の申請が行われる。この際には、商品購入者は個人又は法人である商品販売者が提供する商品を購入する旨の申請をインターネット接続画面にて行う。商品購入者の情報は購入申請前にWeb画面上で登録するようになっている。商品の提供はネットショップ、ネット通信販売、オークション、個人間取引等その形態は問わない。
ステップ3153では、商品販売者側で商品登録時等の際に「ユーザ貯金箱による支払を希望」のみが支払方法として選択されているか否かが判断される。ユーザ貯金箱は図95の概念図に示すようにWWWサーバー3のデータベース1009に各ユーザ5毎に用意されている。そして、このユーザ貯金箱には、ユーザ5が商品をサイトで購入する際に、商店等7により設定された現金還元額がユーザ5に対し還元されるようになっている。この現金還元額は、ユーザ5が実際に支払う金額の内の一部であって、このユーザ貯金箱に貯められるようになっている。そして、現金還元額は仮想現金としてユーザ貯金箱に貯められ、次の商品購入の際にこの仮想現金を使って支払金額の一部又はすべてとして利用できるものである。
商店等7にとってはリピーターを増やすことができる。こうして貯められた仮想現金は、商店等7の行うサービスの一種として貯蓄のあった日から2年経過すると償却されるようになっている。但し、この期間内にユーザ5により新たな商品の購入のあった場合には、この最終購入日から更に2年等の期間が延長されるようになっている。即ち、ユーザ5による購入の継続する限りユーザ5は半永久的に仮想現金を使い続けることができる。しかしながら、ユーザ5による購入が継続しない場合であっても半永久的に消滅しないようにされてもよい。
このユーザ貯金箱にはまた、実際の現金(以下、仮想現金に対し実現金という)が入金されるようになっている。現金の入金は、銀行口座を利用する場合、同一の支店を利用すれば無料となる。同一の銀行支店間の取引においても手数料は安くなっている。この入金は、例えば、ユーザ5から銀行等に振り込まれた金額を確認したサイトの係員が、データベース上に配設されたユーザ5のユーザ貯金箱に対しデータ(金額)を加算することで行う。しかしながら、この間の処理を係員を介さず自動にて連携されるようにしてもよい。また、ユーザ貯金箱を銀行口座等と独立させずに一体化してもよい。この場合にも手数料は無料若しくは安くできる。
また、このユーザ貯金箱には、ユーザ5による支払金額が実際に商品購入の際に支払うべき金額を誤って超えて支払われたような場合にもその超過金額分が貯金されるようになっている。即ち、この超過金額分はユーザ5に直接返却されるのではなく、ユーザ貯金箱に貯金される。超過金額分は実金額として扱われるようになっている。
このように、ユーザ貯金箱は仮想現金の貯められる仮想現金部分と実現金の貯められる実現金部分とで構成されている。
なお、商品購入に際しては、仮想現金部分に償却期間が設けられた場合には、仮想現金部分よりも実現金部分の方から先に代金に充てるようにプログラムされるのが望ましい。
更に、このユーザ貯金箱には、後述するように他のユーザ貯金箱より振込がされるようになっている。振込のされた金額は実金額として扱われるようになっている。
そして、商品購入の際には、仮想現金と実現金とを加算した形でその合計金額の中から支払をすることができるようになっている。この際には、実現金の部分から先に支払を行い、実現金では賄いきれなくなったとき不足部分について仮想現金を使うというように処理されることが望ましい。
図95の場合には、商品購入のあったとき、商品販売者であるBさんのユーザ貯金箱に商品購入者であるAさんのユーザ貯金箱から支払(振込)がされるようになっている。この支払(振込)は商品購入の意思表示のあってから例えば3ヶ月経過後に確定され、支払(振込)が実行される。3ヶ月経過していれば、商品販売者側から商品購入者側に商品が届けられていると想定されるからである。ステップ3153では、このように、取引の安全や手数料金額を抑えることを希望する商品販売者が、予め「ユーザ貯金箱による支払を希望」の項目をセンターサーバーに対し登録している場合である。
この項目がセンターサーバーで選択かつ登録されている場合には、ステップ3155でその旨が商品購入者側に対しWeb画面上で表示される。商品購入者は、この商品販売者の提示した「ユーザ貯金箱による支払を希望」に同意するか否かを決め、同意のボタンをクリックした場合にはステップ3157に進む。同意しなかった場合にはステップ3159で処理は中止され、商品購入者は商品を購入することができない。
ステップ3157では、商品の価格(決定価格)L円を抽出する。商品の価格は例えば値引き交渉による場合には値引き交渉により決定した価格である。ステップ3161では、商品購入者の有するユーザ貯金箱の貯金額S円を抽出する。そして、ステップ3163でユーザ貯金箱の貯金額S円と商品の価格(決定価格)L円を対比する。商品の代金を支払うだけの充分な金額が商品購入者の有するユーザ貯金箱に残っているか否かを判断するためである。
ユーザ貯金箱の貯金額S円が商品の価格(決定価格)L円以上のとき、ステップ3165に進み、商品の価格(決定価格)L円を一時商品販売者側のユーザ貯金箱に仮保存し、かつユーザ貯金箱の貯金額を一時S−Lにて仮保存する。このとき、商品購入者のユーザ貯金箱の貯金額は一時S−Lになっているので、商品購入者はユーザ貯金箱の貯金額を全額使ってS−L円を超えた商品購入の支払はできなくなる。取引が完了するまでの期間、商品価格相当の金額を一時預かりするためである。但し、一部内金という形を認めることにしてS−L円を超えた商品購入を可能としてもよい。
ステップ3167では、商品販売者側に商品が購入された旨の通知がされる。通知は電子メールで行われる。この通知があったときには商品販売者側は商品を商品購入者に対し配送する。
ステップ3169では、キャンセルが取引完了すると想定される例えば3ヶ月以内の間にされたか否かが判断される。通常であれば、この期間内に商品も商品購入者側に到達していると考えられ、キャンセルはされない。この場合には、ステップ3171に進み3ヶ月経過後に仮保存データがBさんのユーザ貯金箱に自動にて確定され、商品販売者側であるBさんでは、この確定した金額を使用することができるようになる。入金された金額は実現金として扱われる。
確定の際には、サーバーより電子メールにて確定の旨の通知がされる。但し、商品購入者側から商品到着の旨の電子メール等による通知をサーバー側で受けたことを条件に取引成立とし、ステップ3171での確定処理を行うようにしてもよい。この電子メール等による通知作業はユーザ5にとっては煩わしいので、正常に取引の行われている場合にはユーザ5に対し何も負担をかけず、商品が到達しなかった場合に限りキャンセルの旨を通知させるようにするのが望ましい。
3ヶ月の期間内に商品販売者側から商品が届かない等の事情が生じた場合には、ステップ3169で商品購入者側からの申請により取引をキャンセルできる。キャンセルは、サーバーに対しログインし、「商品がまだ届いていない」ボタンを押すことで可能である。キャンセルのあったときには、その旨は商品販売者側にも電子メールで通知される。その後、所定期間経過後(例えば2週間経過後等)にキャンセル状態は確定し、ステップ3173でステップ3165における仮保存データを取引前の状態である元に戻す。所定期間を設定したのは、キャンセルが虚偽で行われた場合に、商品販売者側に異議を唱える機会を設けたためである。キャンセルの確定した場合には、商品の売買は成立せず、商品購入者の有するユーザ貯金箱は貯金額S円に戻される。
但し、虚偽のキャンセルがされた場合を配慮して、キャンセルのあったときには、キャンセルの旨が商品販売者側に通知される一方で、3ヶ月経過してもデータの確定が自動ではされないようにしてもよい。そして、データを元に戻すのは、係員の判断に基づき手動とされてもよい。
「3ヶ月」等の期間は商品販売者と商品購入者との間で自由に決められるのが望ましい。例えば、ネットを介して「2ヶ月でどうですか」との一方側の希望申請(期間を選択させる)に対し、「よいです」等相手側が返答ボタンを押すことで確定する等のようにされてもよい。
ステップ3175においては、商品販売者側で事前に「ユーザ貯金箱による支払を希望」のみが予め選択されている訳ではないが、「ユーザ貯金箱による支払を希望」が支払方法項目の一つとして選択されているか否かが判断される。選択されている場合であって、かつステップ3177で商品購入者側でも「ユーザ貯金箱による支払を希望」が選択された場合には、商品販売者及び商品購入者の双方共にユーザ貯金箱による支払を希望していることになるので、ステップ3157以降で説明したように、互いのユーザ貯金箱間を利用して支払が行われる。
ステップ3175で商品販売者側で「ユーザ貯金箱による支払を希望」が支払方法項目の一つとして選択されていない場合や、ステップ3177で商品購入者側で「ユーザ貯金箱による支払を希望」が選択されなかった場合には、ステップ3179で銀行振込や郵便振替、着払い、カード支払、コンビニ支払等の他の方法であって、かつ商品購入者の指定した支払方法となる。
ステップ3163でユーザ貯金箱の貯金額S円と商品の価格(決定価格)L円を対比した結果、ユーザ貯金箱の貯金額S円が商品の価格(決定価格)L円未満のとき、ステップ3181に進む。この際には、Web画面上で商品購入者に対し、ユーザ貯金箱の残金が不足している旨のメッセージが出される。ステップ3183で補充のあった場合には、ステップ3157からの処理が繰り返される。補充のなかった場合には、ステップ3185で処理が中止される。
以上のように、ユーザ貯金箱を利用して商品販売者と商品購入者間の支払を行わせることで、代金を支払ったのに商品が届かない状況や、商品を送ったのに代金の支払がない等の事態を防止できる。個人対個人等の取引で、お互いに信頼関係がない状況でも安全に取引を行うことができる。なお、図95において、商品販売者であるBさんは、Aさんよりユーザ貯金箱に支払を受けた金額を元に自ら他の商品を購入し、その購入の代金に充てることができる。
商品購入に際しては、商品購入の都度現金還元された額を貯めた仮想現金部分とAさんより支払を受けた実現金部分との両方の額を使用することができるので便利である。また、この際には送金手数料等の負担もない。
Bさんはまた、貯めた貯金(実現金部分)を降ろすことができる。貯金を降ろす場合には、センターサーバーに対し申請をする。申請の金額は貯金額を超えることはできない。その後、サイトの運営会社より申請のあった金額が所定の銀行口座等に振り込まれる。貯金は、取引の都度降ろすこともできるが、複数回分の取引をまとめて降ろすようにすることで銀行手数料等は取引の都度降ろす場合に比べ実質安く抑えることができる。降ろさずに継続して貯められる場合には、手数料は一切かからず、便利である。降ろさない場合であっても、買い物の支払に利用できる。
以降、同様に図95に示すようにBさんが商品購入者になり、商品販売者であるCさんから商品を購入し、この商品代金をBさんはユーザ貯金箱から支払うことができる。
オークション等の個人間取引にも有効であり、取引を安全に行い、かつ手数料等を無料、若しくは安く抑えることができる。なお、本実施形態はポイント還元制に適用されてもよい。この場合には、貯めたポイントを現金に換算した上で支払を実施したり、逆に支払を受けた現金をポイントに換算する演算部分が必用となる。但し、支払を受けた現金はそのまま貯めるようにされてもよい。
次に、本発明の第32実施形態について説明する。本発明の第32実施形態は、商店等7がWeb上で簡単にセールを行えるシステムについてである。従来、商店等7が日常の販売以外にセールを行おうとする場合、改めてセールのホームページを別に作ったり、セール商品を混在させた形でホームページを作り、セールを開始する。そして、セールの終了したときには、元のセール前の状態のホームページに戻す必要があった。そして、手動にてセール終了を行った場合には、購入処理のセッション途中にあるユーザ5に対して、途中で購入処理が継続できなくなる等多大の迷惑をかけるおそれがあった。
また、このホームページが貸し店舗形式で行われるWWWサーバー3に掲載された場合には、セール品を含むホームページの更新をWWWサーバー3のサイトにその都度依頼しなければならず不便であった。
そこで、本発明の第32実施形態は、商店等7がセール品やサービス品の金額や商品情報等を通常販売データから修正若しくは追加するだけで、いつでも簡単にセールを設定でき、かつセールの終了時において何らの処理も不要であるWeb上でセールを行えるシステムを提供するものである。
図109及び図110に本発明の第32実施形態のフローチャートを示す。図109は、商店等7がWWWサーバー3にアクセスし、セールの準備を行う処理について説明している。図110は、ユーザ5がセールにて商品等を購入する処理について説明している。
図109において、ステップ3201では、商店等7がWWWサーバー3にアクセスし、セールの準備を開始する。ユーザ5はステップ3203で図示しない商店設定画面にログインする。この商店設定画面は、予めWWWサーバー3側で用意され、PHP: Hypertext Preprocessor 、Perl、Ruby、C、JAVA(登録商標)、VB等のソフトウェア言語によりプログラム生成された画面であり、商店等7がログインすることが可能なようになっている。そして、ステップ3205では、この商店設定画面に対し、商店等7はセール期間開始日時T10、セール期間終了日時T11を設定する。この設定は、タイムセールならば、例えば12月1日の午後1:00(T10)〜2:00(T11)、例えば歳末セールならば、12月15日午前10:00(T10)〜12月31日午後21:00(T11)といったように設定される。
ステップ3207では、商店データベースより商品又はサービス品に関する価格、商品情報等が読み出され商店等7に対し表示される。この際の画像もPHP等のソフトウェア言語によりプログラム生成された画面である。この商店データベースには、WWWサーバー3の運営する貸し店舗サイトに登録された商店等7で通常(セールではない状態)販売品としてWeb上に掲載し、販売されているデータが保存されている。通常販売品としての情報は、例えば当該商品の当該商店等7における通常販売価格、底値、現金還元額等である。
ステップ3209では、ステップ3207において読み出された商品又はサービス品の中から商店等7がセールを行いたいセール商品又はセールサービス品を選択する。そして、ステップ3211では、このセール商品又はセールサービス品に対し底値、現金還元額、特別価格等の金額やセールに関するデータ情報を設定する。設定したセール情報は、ステップ3213でセール専用データベースに保存する。ここに、セール専用データベースは、商店データベースとは異なるが、同一のデータベースとされてもよい。この場合には、同一の商品に対し通常販売のデータとセールのデータの2種類が共存される。
一旦、セール専用データベースが作成された場合には、セール情報の更新が簡単に行える。即ち、この場合には、ステップ3215でセール専用データベースより必要なデータを読み出し、修正を加えることで更新が可能である。セール専用データベースには、直前のデータのみを保存してもよいが、直前データだけでなく、履歴データとして過去に実施されたセール情報を複数残すようにされてもよい。また、セール商品やセールサービス品を新たに追加したい場合には、商店データベースより商品やサービスを選択し追加を行う。
次に、図110に基づきユーザによる購入処理について説明する。ステップ3221では、ユーザ5によりセール商品又はセールサービス品の購入処理が開始される。セールページには、例えばステップ3223のように、商店等7の有する通常販売のページよりセールアイコンをクリックすることで進む。このセールアイコンにはセールページがリンクされている。ステップ3225ではセールページが開かれる。
その後、ステップ3227では、セール期間開始日時T10を現在日時と比較し、現在日時がセール期間開始日時T10を過ぎているとき、ステップ3229で現在セールを行っていない旨の表示をセール画面に挿入しユーザ5に対し送る。このとき、ステップ3231で、ユーザ5がこのセール画面において商品選択してもステップ3233でログインできない。従って、この商品を購入することができない。しかしながら、リンク元である通常販売画面に戻り、購入処理をすればこの商品を購入することができる。この際には、商店データベースの金額にて購入処理される。
あるいは、ステップ3233では、ログインを可能として、商店データベースによる金額等を参照しつつセールではない通常販売価格等にて購入可能とされてもよい。
一方、ステップ3227で現在日時がセール期間開始日時T10を超えているとき、ステップ3235に進む。そして、ステップ3235では、セール期間終了日時T11を現在日時と比較し、セール期間終了日時T11が現在日時より後のとき、ステップ3237で、只今歳末セール等のセール(又はタイムセール)中である旨の表示をセール画面に挿入しユーザ5に送信する。現在日時がセール期間終了日時T11を過ぎている場合には、ステップ3236でセールが終了した旨のメッセージをユーザ5に対し通知する。この際には、ステップ3238で商店データベースに保存された通常販売価格や底値等により販売が行われる。なお、ステップ3236のセールの終了メッセージはユーザ5に対して通知されなくてもよい。
ステップ3239では、ユーザ5が商品若しくはサービス品の選択を行い、ステップ3241ではログインを行う。このとき、ログイン画面において、ユーザ5はユーザIDやパスワードを入力する。ログイン後において、ステップ3243では、再びセール期間終了日時T11を現在日時と比較する。ステップ3243において、セール期間終了日時T11が現在日時より後のとき、ステップ3245でセール専用データベースに保存された金額及びデータ情報に基づく販売を行う。このとき、ステップ3213で保存されたセール専用の金額や情報に基づいた販売となる。一方、ステップ3243で、現在日時がセール期間終了日時T11を過ぎた場合には、ステップ3247でセッションの途中であるか否かが判断される。このセッションの途中とは、現在日時がセール期間終了日時T11を過ぎる前にユーザ5がログインし、購入処理の途中にある場合である。このセッションの途中であるならば、ステップ3245に進みそのまま購入処理を継続させる。このことにより、購入処理のセッション途中にあるユーザ5が、途中で購入処理が継続できなくなる等の不具合は無くなる。
一方、セッションの途中でない場合には、ステップ3249でセールが終了したことをHTML文書にてユーザ5に対して通知する。従って、これ以降、ユーザ5は、セール専用データベースに保存された金額での購入ができなくなる。しかしながら、ステップ3251で商店データベースに基づく通常販売が可能である。なお、ステップ3249のセールの終了メッセージはユーザ5に対して通知されなくてもよい。
また、ユーザ5は、ステップ3225でセールページを開くことなく、ステップ3241のログイン画面に直接アクセスして購入処理を行うようにしてもよい。このとき、ステップ3227以降の判断処理が行われる。
以上により、商店等7自身がWeb上で簡単にセールを実行できる。通常販売からセールへの移行、あるいは、セールから通常販売への移行が円滑に行える。セールの終了時においても、商店等7は何もしないでよい。また、次のセールを実施する際にも、商店等7は以前のセールデータを利用できるので簡単にセールを実施できる。
次に、本発明の第33実施形態について説明する。本発明の第33実施形態は、カード情報やログインIDを本人特定のもとに使用可能とするもので第17実施形態の別例である。そして、本実施形態は、基本的には、カード情報やパスワード、メールアドレス等の重要な情報は、出来るだけネット上に流さない状態で的確な認証処理を行いつつ、外出先等から他人所有のパソコンを利用したときでも簡単かつ安全に認証が行えるようにするものである。なお、図96と同一要素のものについては同一符号を付して説明は省略する。また、ユーザ5が有するパソコンについて以下説明するが、携帯電話等でも同様に適用可能である。
まず、ユーザ5からネット上等からの申込があった場合には、フィッシング詐欺による被害を防ぐため、ユーザ5にはクレジットカードや銀行カードの番号、メールアドレス等を書類に記載して郵送にてセンターに送ってもらうこととする。その後、センター側では、これらの情報をデータベース1009に保存した後、ユーザIDを記載したメールを配信する。このユーザIDにはデータベース1009にてカード番号、メールアドレス等の情報が関連付けされている。但し、ユーザIDは当初は仮のものとしてユーザ5に付与し、その後、ネット上で正式なものに設定し直してもらうようにされてもよい。また、この際にはパスワードや暗唱番号が設定されてもよい。
メールにはURLが記載されており、ユーザ5はこのURLのサイトに掲載された保護ソフトをダウンロードする。
次に、図111のフローチャートのステップ4101に示すように、このダウンロードした保護ソフトをユーザ5の有するパソコン等にインストールする。インストールの際にはステップ3503において、ブラウザとの間で拡張子の関連付けを行う。
ステップ4105では、保護ソフトのインストールされた時刻が抽出されてファイルF1に保存される。このインストール時刻は、本人を認証するための認証キーの一つとして使用される。
ステップ4107では、図112のように保護ソフトにおいて設定事項を設定する。この設定事項は、ユーザ5が登録を行ったパソコンではなく、外部のパソコン等を利用して、カードにより購入処理を行ったり、特定のサイトにログインを行う可能性がある場合に予めその旨を設定しておくものである。例えば、ユーザ5が外出先等において自分所有のパソコンではない他人のパソコンを利用してカード決済を行う可能性のある場合には「外部操作を可能とする」を選択する。そして、その可能性のある時間帯を選択する。使用日が分かっていればその日を選択する。また、パスワードを携帯電話やホームページ等で別途センター側から必要の都度受信し、その受信したパスワードをパスワード入力欄にキー入力するか否かを選択可能とする。このとき、携帯電話は本人自身が所有しているため、パスワードはこの携帯電話で受信されるようにするのがより望ましく、その旨の選択がされるようにしてもよい。
そして、次に、ステップ4109では、ユーザ5は保護ソフトの画面に向かいユーザIDを入力する。但し、このときパスワードも入力するようにされてもよい。パスワードは後述するようにパソコン画面において、HTML上のボタン操作を行うことでセンターよりユーザ5所有の携帯電話に向けメールにて配信されたものを利用する等されるのが望ましい。ユーザIDは予めセンターより送られているものである。ステップ4111で保護ソフトの画面において登録ボタンを押す。ステップ4113では、パソコンの固有情報が取得される。なお、ここでバイオメトリクス情報が取得され利用されるようにしてもよい。あるいは、固有情報としてUSBメモリーやICメモリーカード、外付けハードディスク、CD、FD等に埋め込まれた装置特有のシリアル番号が取得され利用されるようにしてもよい。
ステップ4115では保護ソフトがユーザID(若しくはパスワードの入力されている場合にはパスワードも含む)をセンターに向けて送信し、ステップ4117ではセンターでこの情報を受信する。
ステップ4119ではユーザID、パスワードの一致するデータがセンターデータベース1009に存在するか否かが判断される。存在する場合にはステップ4121でセンターサーバー1008より公開キーが配信される。この公開キーは暗号理論に基づき秘密キーと共に乱数発生されたものである。一方、存在しない場合にはステップ4109に戻り改めてユーザID、パスワードをよく確認した上でユーザID、パスワードを再度入力するよう促す。
ステップ4123ではファイルF1を固有情報を基に暗号化する。ここでは、複数の固有情報のそれぞれからサンプリング的にコードを抽出して一つのキーを生成する。そして、このキーを基に例えば共通キー方式でファイルF1を暗号化する。続いて、ステップ4125では、固有情報を公開キーを用いて暗号化し、ステップ4127ではファイルF1、固有情報をセンターに送信する。このように、本実施形態では、固有情報についてユーザパソコンの中にはファイルの形で残さずに直ちにセンターに向けて送信する。このことにより、不正者によるファイルの解析を極力防止できる。
センターでは、これらの情報をステップ4129において受信し、ステップ4131では固有情報を秘密キーを用いて復号化する。その後、この復号化された固有情報を用いて、ステップ4133では、ファイルF1を固有情報で復号化する。そして、ステップ4135では、この復号化したファイルF1、固有情報をセンターデータベース1009に保存する。
次に、ユーザ5が実際に購入処理を行ったり所定のサイトにログインする方法について説明する。図113には全体の概念図を示す。図113に示すように、モールや商店のホームページにおいてユーザ5が商品購入をする。このとき、商品価格、商品の型式、商品名等が決定し商店等7のデータベースに保存される。次に、ホームページを進めると、従来通りの方法でカード番号を入力するか、本実施形態に基づきユーザID等を入力するかの選択ページが表示される。従来通りの方法でカード番号を入力する場合とは、例えば、クレジットカード番号と有効期限とを入力するもので、他にユーザ5を特定する機能を有しない。
ユーザID等を入力する場合、複数のカードを所有するユーザ5に対してはいずれのカードを使用するのかの選択をしてもらうことが望ましい。このとき、カード会社の名前だけを選択してもらったり、カード情報の内の例えば上位数桁のみを記入してもらう等することで情報の漏洩を防止する。但し、カード情報ではなく、ユーザ5の所有する各カード毎にユーザIDを対応付けし、ユーザID自体をそれぞれ異ならせるようにしてもよい。また、ユーザIDではなく、従来と同様に直接カード番号や有効期限等を入力するようにされてもよい。この場合であっても、後述するように固有情報等が一致しなければ本人認証ができず、結局の所、不正者により利用のされることがないからである。
パスワードの入力は、より一層ユーザ本人を厳密に特定するために入力させることが望ましい。しかしながら、本実施形態では、パソコン固有情報等で本人特定が可能なため、必ずしも必須のものではない。入力する場合には、後述するようにセンター側から送信されたパスワードが入力されるのが望ましい。
モールや商店のホームページには予めパラメータファイルが準備されている。このパラメータファイルには保護ソフト起動命令が含まれており、ホームページのユーザパソコンへのダウンロードと共に保護ソフトが起動される。保護ソフトが起動すると後述する認証がユーザのパソコンを介してセンターにて行われ、カード会社からのオーソリゼーション(信用照会)結果との双方が共に許可であったときに商店等7に対しセンターより認証許可を付与する。但し、オーソリゼーションと保護ソフトを用いた認証とは別サーバーとして独立させた形で構成されてもよい。この場合には、例えば保護ソフトによる認証を行った上で、オーソリゼーション用のサーバーに結果を送信する。オーソリゼーション用のサーバーでは、オーソリゼーションの結果を商店等7のサーバーに対し送信する。あるいは、保護ソフトによる認証とオーソリゼーションとを平行して処理を行い、その結果を商店等7のサーバーに対し送信するようにしてもよい。商店等7のサーバーでは、両方の結果の論理積をとることで認証の結果を判断する。
一方、不許可のときには認証不許可を付与する。センターから商店等7への許可、不許可の符号は所定のURLに組み合わせて送信される。商店等7のサーバーでは、このURLに基づきCGIやPHP等のプログラムが動作し、商店等7のサーバーにデータを保存したり、データ処理を行い、必要ならばホームページを表示させる。なお、ユーザ5が未登録の場合には、登録するように促すようにされてもよい。また、認証不許可の場合に、次の携帯電話を使用した処理を選択するようにされてもよい。
次に、この携帯電話を使用した処理について図114のフローチャートに基づき説明する。まず、ステップ4151では、外部操作が可能となっているか否かを判断する。この設定は、図112に基づき例えばユーザ5の所有するパソコンにてユーザ5により設定されたものである。外部操作が可能と設定されていなければ、ステップ4159で「設定が許可されていません」と表示する。また、ステップ4152では、受信パスワードを入力するモードがユーザ5により設定されているか否かが判断される。このモードが設定されていればステップ4153に進み、一方、設定されていなければ、ステップ4159に進む。
ステップ4153では、図112に基づきユーザ5により日時が設定されているか否かを判断する。この日時が設定されており、かつステップ4155において日時が設定内であれば、ステップ4157に進みパスワード画面を表示する。一方、日時が設定外であるときには、ステップ4159に進む。
但し、ステップ4153で日時が設定されておらず、いつでも入力許可されていれば、ステップ4157に進みパスワード画面を表示する。このパスワード画面にはパスワード入力欄と共にパスワード自動生成用のボタンが表示されている。ステップ4161では、ユーザ5がこの画面上でパスワード自動生成用のボタンを押す。このとき、センターサーバー1008では、パスワードが乱数発生され、データベース1009に保存された上で、ステップ4163でこのパスワードの記入されたメールがユーザ5の携帯電話に向けて配信される。パスワードは例えば発行時刻から3分間だけ有効である。即ち、3分経過するとこのパスワードではセンター側で受け付けられなくなる。
ステップ4165では、ユーザ5が今使用しているパソコンの画面に表示されたパスワード入力欄に向かって、携帯電話で受け取ったメールに記載されているパスワードを見ながら入力する。その後、ステップ4167で送信ボタンを押す。センターサーバー1008では受信されたパスワードがデータベース1009に保存されている3分前までに発行したパスワードと一致したとき、ステップ4169で「パスワードは正常に受け付けられました。このパスワードは以降使用できません。」と表示する。即ち、このパスワードが一旦受け付けられると、2回目以降に送られた同一のパスワードは無視される。一方、パスワードが一致しなかったときには、再度パスワード画面に戻り、パスワード自動生成用のボタンを押すようにメッセージする。
ステップ4171では、携帯電話のメールにも正常に受け付けた旨を確認のため配信する。
なお、別形態として、ステップ4163において、メールにはURLを記載してもよい。このとき、ユーザ5がこのURLにクリックすると、例えばセンターサーバー1008において2分毎に更新されたパスワードを含むHTML文書がPHP等により随時自動で2分毎に生成され、かつダウンロードされる。従って、ユーザ5は、パスワード自動生成用のボタンを押す必要がない。また、メール配信に伴うタイムラグも軽減できる。
更に、別形態として、本人確認のためにメールを携帯電話等に配信するので、ユーザ5がこのメールを返信するようにされてもよい。このとき、返信メールがセンターサーバー1008に届いた時点で認証を許可する。返信先アドレスはメール本文中に記載することも可能である。なお、この場合にはパスワード画面及びパスワードの入力は不要である。返信はメール送信時刻から所定時間(例えば30分)内に行われたときにのみ有効とされるのが望ましい。かかる形態であっても、携帯電話自体が本人所有のものなので本人認証としては十分に機能する。操作も簡単である。
また、携帯電話自体の固有情報(及び/又は固有ID)を登録時に取得し、センターに送信しデータベース1009に保管しておく。その後メールを配信する際にこのメールを登録時に保管しておいた固有情報を基に暗号化する。受信の際には、携帯電話の固有情報を基に復号化を行うようにされてもよい。あるいは、携帯電話が指紋等のバイオメトリクス情報を取得可能な場合には、固有情報と共に、若しくは固有情報に代えてこのバイオメトリクス情報を暗号化に用いるようにされてもよい。
更に、携帯電話やパソコン自体が指紋等のバイオメトリクス情報を判断して本人と認識されたときにのみ機能するようになっていれば、本人にのみセンターより送信されたパスワードが知れることになるので一層安全である。このような場合、ステップ4165では、ユーザ5が携帯電話の画面に表示されたパスワード入力欄に向かって、同じ携帯電話で受け取ったメールに記載されているパスワードを見ながら入力するようにされてもよい。
更に、登録時には公開キーをセンターサーバー1008より携帯電話側に送信し、保存する。使用時には秘密キーを用いてメールを暗号化し、携帯電話側にこのメールを送信する。携帯電話側ではこのメールを保存している公開キーを用いて復号化するようにされてもよい。固有情報による暗号化と公開キー方式による暗号化とを2重に施してもよい。
以上により、パソコン固有情報の異なる例えば外出中に使用したユーザ所有以外の他のパソコン等においても購入処理やログインが安全に行える。
次に、実際の購入処理やログイン方法を図115及び図116のフローチャートに基づき説明する。
ステップ4181で、ユーザ5のパソコンに対し商店等7のサーバーよりホームページがダウンロードされる。このホームページには「保護ソフトで入力画面が生成されるので、その画面に対しユーザID、パスワードを入力して下さい。」と記載されている。ここで、パスワードの入力は本人認証のために必須ではないが、図114の処理と組み合わせることでより厳密な本人認証が可能となる。但し、パスワードの入力は、センターに対し予め届け出済のものが使用されてもよい。
あるいは、入力はカード番号、有効期限等であってもよい。これらのデータが仮に不正者の手に渡っても固有情報等での本人認証が追加条件とされているので直ちにカードが使用されてしまう等の被害に繋がることがないからである。ステップ4183では、パラメータファイルがダウンロードされる。その後、ステップ4185で、保護ソフトが起動される。ステップ4187では、この保護ソフトで生成された画面に対しユーザIDが入力される。但し、パスワードが入力されるようにされてもよい。このときのパスワードは携帯電話から指示したものであるとより望ましい。また、保護ソフトで画面を生成する代わりに、ホームページにて画面を生成するようにされてもよい。
続いてステップ4189では、ユーザ5が保護ソフトで生成された画面上で送信ボタンを押す。このとき、ステップ4191でセンターに対しユーザID等が送信されると共に公開キーが要求される。ステップ4193では、計測時間のカウントが開始される。計測時間のカウントを行うのは、不正者による成り済まし的行動を排除するためである。センターでは、ステップ4195でこのユーザIDがセンターサーバー1008に登録されたものであるか否かが判断される。そして、ユーザIDがセンターサーバー1008に登録されたものであるならば、このユーザIDに対し乱数発生により公開キーと秘密キーとをいわゆる公開キー方式の暗号理論に基づき生成し、生成した公開キーと秘密キーとをデータベース1009に保存する。
その後、ステップ4197では、ファイルF8がセンターにおいて生成され、このファイルF8に公開キーとシリアル番号が入れられる。シリアル番号は公開キー等と共にセンターデータベース1009に保存される。シリアル番号は、乱数発生されてもよい。ステップ4199では、センターデータベース1009よりこのユーザIDに一致する固有情報を抽出し、ファイルF8をこの固有情報を基に暗号化する。なお、ファイルF8は一層の安全化を図るため更に別途秘密キーで暗号化されてもよい。この場合、この秘密キーに対応した公開キーは予め復号化のため保護ソフト側に持たせておく。
そして、ステップ4201では、SSL通信を行いファイルF8をユーザ5の有するパソコンに対して送信する。ステップ4203では、保護ソフトがファイルF8をパソコン側で受信する。ステップ4205では、保護ソフトがユーザ5のパソコンからパソコンの固有情報を抽出する。ステップ4207では、ファイルF8を固有情報を基に復号化する。ステップ4209でファイルF8の復号化が完了したならば、ステップ4211で公開キーとシリアル番号をファイルF8から抽出する。復号化に失敗したならばステップ4239で認証は許可されない。また、ステップ4213では、ファイルF1を固有情報を基に復号化する。そして、ステップ4215では、抽出したシリアル番号をファイルF1に保存する。ステップ4217では、このファイルF1をパソコンより抽出した固有情報を基に暗号化する。
続いて、ステップ4219では、この固有情報をステップ4211で抽出した公開キーを用いて暗号化する。ステップ4221では、このファイルF1、固有情報をセンターに送信し、ステップ4223においてセンターで受信する。受信したデータは、ステップ4225において、まず固有情報をセンターで保存していた秘密キーを用いて復号化する。このとき、復号化できるか否かで届けた公開キーが正しく使われたかどうかを判断できる。続いて、ステップ4227では、ファイルF1を固有情報を基に復号化する。そして、ステップ4229では、センター側に送信されたユーザID、パスワード、ファイルF1を復号化して得られるインストール時刻、シリアル番号、そして固有情報がデータベース1009に保存されたデータと一致するか否かを判断する。
ステップ4231で判断の結果、データが一致すると判断された場合にはステップ4233に進み、ステップ4193において計測を開始した時間カウント値を判断する。時間カウント値が制限時間内ならばステップ4235で認証を許可する。一方、ステップ4231で判断の結果、データが一致しないと判断されたときにはステップ4239で認証は許可されない。また、ステップ4233で時間カウント値が制限時間を超えている場合にはステップ4239で認証は許可されない。認証許可の場合には、ユーザ5に対し確認のためステップ4237でメールを配信する。
以上により、安全にネット上で商取引を行ったり、サイトへのログインが安全に行える。