JP2011165210A - ネットシステム - Google Patents

ネットシステム Download PDF

Info

Publication number
JP2011165210A
JP2011165210A JP2011103204A JP2011103204A JP2011165210A JP 2011165210 A JP2011165210 A JP 2011165210A JP 2011103204 A JP2011103204 A JP 2011103204A JP 2011103204 A JP2011103204 A JP 2011103204A JP 2011165210 A JP2011165210 A JP 2011165210A
Authority
JP
Japan
Prior art keywords
price
user
information
product
yen
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
JP2011103204A
Other languages
English (en)
Inventor
Mieko Tsuyusaki
美恵子 露崎
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Individual
Original Assignee
Individual
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Individual filed Critical Individual
Priority to JP2011103204A priority Critical patent/JP2011165210A/ja
Publication of JP2011165210A publication Critical patent/JP2011165210A/ja
Pending legal-status Critical Current

Links

Images

Landscapes

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

Abstract

【課題】インターネット上等で商店等が提供する商品やサービスに対する値引き交渉等を販売促進につなげ、かつ取引が安全に行えるネットシステムを提供する。
【解決手段】クレジットカード情報の一致を判断する以外に、情報処理装置固有の情報やバイオメトリクス情報の一致をも判断に加味するようにした。保護ソフトウェアはユーザの情報処理装置にインストールされる。ホームページに挿入された命令により、保護ソフトウェアの起動がされ、情報処理装置固有の情報の取得、バイオメトリクス情報の取得及び所定のロジックに従い生成されるシリアル番号の取得が可能である。
【選択図】図９６

Description

本発明はネットシステムに係わり、特にインターネット上等で商店等が提供する商品やサービスに対する値引き交渉等を販売促進につなげ、かつ取引が安全に行えるネットシステムに関する。
最近、インターネットを利用して、各種ショッピング、企業間取引、流通取引等がＷＷＷ（World Wide Web）サーバが提供するホームページ上で行われている。このホームページ上にはカタログ等が掲示されており、ユーザがそのホームページにアクセスして商品やサービス等を購入したり、取引提携できるようになっている。そして、利用者は、興味のある品物を簡単かつ迅速に手に入れることが出来、便利であるので利用人口も急速に延びつつある。
ここに、出願人は、特許文献１及び特許文献２において、ユーザである購入者等がサイトの運営者等により表示された金額より安価に商品等を購入できるようにするため、値引き交渉等の行えるシステムを提案している。
特開２００２−１７５４７３号公報 特願２００５−１２０４１９号
ところで、上述したインターネットを利用した値引き交渉等を販売促進に役立てることが望まれる。そして、この際、値引き交渉は各店舗毎にそれぞれ行われてもよいが、一括してまとめて交渉ができれば忙しい人等にとっては便利である。
また、各商店等のＷｅｂページから自動化された就職の支援プログラムが直接動作できれば就職希望者にとっても商店等にとっても便利である。また、ユーザに対し特典を付与する等により一層の販売促進に繋げることが望まれる。
更に、商店等で商品やサービスを購入後、自宅等から所定のＷｅｂサイトに接続し値引き交渉を可能とするとユーザにとって楽しみが増す。また、商店等の更なる売上増大や宣伝効果の増大につながる。
更に、昨今、インターネットを介して個人間取引も盛んになりつつあるが、支払をしても購入者の手元に商品が届かなかったり、商品を送っても支払がされなかったりする事例が多く報告されている。この個人間取引等が安全に行え、かつ手数料をいかに安くしてユーザへの負担を軽くするかが問題である。
更に、従来、商店等７が日常の販売以外にセールを行おうとする場合、改めてセールのホームページを別に作ったり、セール商品を混在させた形でホームページを作り、セールを開始する。そして、セールの終了したときには、元のセール前の状態のホームページに戻す必要があった。そして、手動にてセール終了を行った場合には、購入処理のセッション途中にあるユーザ５に対して、途中で購入処理が継続出来なくなる等多大の迷惑をかけるおそれがあった。
また、このホームページが貸し店舗形式で行われるＷＷＷサーバ３に掲載された場合には、セール品を含むホームページの更新をＷＷＷサーバ３のサイトにその都度依頼しなければならず不便であった。
更に、昨今では、インターネットを介して様々な犯罪が横行している。例えば、フィッシングや通信傍受等によりクレジットカード情報を盗まれたり、現在のネット取引がクレジットカードの番号や有効期限等を入力するだけで簡単に買物できることを逆手に取られて不正にクレジットカード情報が利用される等している。また、既に仮想店舗において使用された実績のあるクレジットカード情報をこの仮想店舗側で保存しておき、再度の利用者にはこのクレジットカード情報を示さずに商品を購入させる方法もある。この場合、２回目以降にはクレジットカード情報を入力する必要はないが、代わりにログインＩＤやパスワード等を入力することになるため、このログインＩＤやパスワードが盗まれれば同様に被害を被ることになる。
本発明はこのような従来の課題に鑑みてなされたもので、インターネット上等で商店等が提供する商品やサービスに対する値引き交渉等を販売促進につなげ、かつ取引が安全に行えるネットシステムを提供することを目的とする。
このため本発明は、商品及び／又はサービスと、該商品及び／又はサービスを提供する複数の商店等と、該商店等により提供される前記商品及び／又はサービスのユーザに対する希望販売価格又は希望販売率と、前記商品及び／又はサービスのユーザによる購入金額又は購入率が前記希望販売価格又は希望販売率より低い金額又は販売率となるように前記ユーザとの間でネットを介した値段交渉を可能とする値段交渉手段と、該値段交渉手段で前記各商店等毎に値段交渉された結果がまとめてユーザに対し提供される値段交渉結果提供手段とを備えて構成した。
以上により、ユーザは各店舗毎に値引き交渉をするということなく複数の商店等についてまとめて値引き交渉が可能となる。このため、どの店が最も安く購入できそうか、若しくは最も安く購入できるか簡単かつ迅速に判断可能となる。購入したい商店等を選択した上で値引き交渉可能とすれば一層便利である。
また、本発明は、ユーザと、該ユーザが商店等より購入した商品及び／又はサービスと、該商品等について前記ユーザが支払った支払金額と、該支払金額を前記ユーザ毎に管理するデータベースと、前記支払金額の支払後、該支払金額より低い金額となるように前記ユーザとの間でネットを介して値引き交渉を行う値引き交渉手段と、該値引き交渉手段で値引き交渉された結果の決定額と前記支払金額との差額を算出する差額算出手段と、該差額算出手段で算出された差額を貯蓄する貯蓄手段とを備えて構成した。
以上により、ユーザは商店等で商品やサービスを購入後、値引き交渉により自分の意思で支払金額が減額されることになるので、買い物が楽しく行える。ユーザは商品購入後も値引き交渉等のためＷＷＷサーバのサイトのショップ等を訪れることになるので、サイトのアクセス数が増大し販売の増加及び宣伝効果の増大につなげることができる。
更に、本発明は、前記貯蓄手段には、前記値引き交渉手段での値引き交渉がされなかったときに予め設定された現金還元額分が貯蓄されることを特徴とする。
値引き交渉がユーザにより行われなかった場合であっても現金還元の処理がされるので、ユーザにとっては安心である。従って、本システム利用に伴い、商店等の売上増にもつながる。
更に、本発明は、就職希望者の求職活動で使用される就職希望者個人の求職情報及び企業、商店等により提供される就職求人情報が登録されたデータベースと、該就職求人情報をＷｅｂ上で提供するセンターサーバーと、該センターサーバーにより提供される就職求人情報をネットを介して閲覧する就職希望者と、該就職希望者が前記企業、商店等との面接を希望する旨の意思表示を前記センターサーバーにする面接希望意思表示手段と、該面接希望意思表示手段で前記就職希望者から意思表示のあったとき前記就職希望者個人の求職情報の一部データを前記データベースより抽出して前記企業、商店等に送信する一部情報抽出送信手段と、該一部情報抽出送信手段により送信された前記就職希望者個人の求職情報の一部データを前記企業、商店等が見て、面接受諾の旨の意思表示を前記センターサーバーにする面接受諾意思表示手段と、該面接受諾意思表示手段で意思表示のあったとき前記就職希望者の求職情報の完全データを前記データベースより抽出して前記企業、商店等に送信する完全情報抽出送信手段とを備えて構成した。
就職希望者の側から企業や商店等に対し就職のアプローチをする場合である。就職希望者が企業、商店等との面接を希望する旨の意思表示をセンターサーバーに対して行った場合には、まず、最初の段階として就職希望者個人の求職情報の一部データをデータベースより抽出して企業、商店等に送信する。送信は、電子メールにより自動配信されることが望ましいが、ファックス等で配信されてもよい。あるいは、センターサーバー側で企業、商店等に対し閲覧自在となるように閲覧ページが用意されてもよい（以下、同旨）。この一部データには、就職希望者個人の連絡先等個人情報に係る重要な事項は記載されないことが望ましい。その後、面接受諾の意思表示のあったときにこの連絡先等を含む就職希望者の求職情報の完全データをデータベースより抽出して企業、商店等に送信する。
以上により、Ｗｅｂ上で円滑なリクルート活動の支援が可能となる。企業側からの対応も速やか、かつ確実に行われるようになる。省力化されているため求職、求人情報を安価に提供できる。各商店等へのリクルート絡みのアクセス数が増加するので販売増及び宣伝効果増に結びつくと共に、ユーザへの特典が付与されることとすれば各商店等の購入が一層増加される。
更に、本発明は、就職希望者の求職活動で使用される就職希望者個人の求職情報及び企業、商店等により提供される就職求人情報が登録されたデータベースと、該就職希望者個人の求職情報の抜粋をＷｅｂ上で提供するセンターサーバーと、該センターサーバーで提供される就職希望者個人の求職情報の抜粋をネットを介して検索及び／又は閲覧する企業、商店等と、該企業、商店等が前記就職希望者個人の求職情報の一部データを前記センターサーバーに対し要求する求職情報一部要求手段と、該求職情報一部要求手段で要求された前記就職希望者個人の求職情報の一部データを前記センターサーバーより抽出して提供する一部情報提供手段と、該一部情報提供手段で提供された前記就職希望者個人の求職情報の一部を見て、前記企業、商店等が面接希望の就職希望者を特定する面接希望者特定手段と、該面接希望者特定手段で特定された就職希望者が面接を受諾する旨を前記センターサーバーに対し、又は電子メールにより伝える面接受諾手段と、該面接受諾手段で面接の受諾がされたとき、前記就職希望者の求職情報の完全データを前記データベースより抽出して前記企業、商店等に送信する完全情報抽出送信手段とを備えて構成した。
企業や商店等側から就職希望者側に対し就職のアプローチをする場合である。就職希望者個人の求職情報の抜粋をＷｅｂ上で提供し、企業、商店等に対し検索や閲覧を可能とする。そして、企業、商店等が就職希望者個人の求職情報のより詳しい情報を欲する場合には、この就職希望者個人の求職情報の一部データをセンターサーバーに対し要求する。この際には、センターサーバーでは、就職希望者個人の求職情報の一部データをデータベースより抽出して企業、商店等に送信する。この一部データには、就職希望者個人の連絡先等個人情報に係る重要な事項は記載されないことが望ましい。その後、就職希望者から面接受諾の意思表示のあったときにこの連絡先等を含む就職希望者の求職情報の完全データをデータベースより抽出して企業、商店等に送信する。
以上により、Ｗｅｂ上で円滑なリクルート活動の支援が可能となる。企業側からの対応も速やか、かつ確実に行われるようになる。商店等が希望する人材を積極的かつ容易に得ることができる。省力化されているため求職、求人情報を安価に提供できる。
更に、本発明は、就職希望者の求職活動で使用される就職希望者個人の求職情報及び企業、商店等により提供される就職求人情報が登録されたデータベースと、該就職希望者個人の求職情報の内の一部データを少なくとも一人分提供するセンターサーバーと、該センターサーバーより提供される就職希望者個人の求職情報の一部データを見た前記企業、商店等が面接希望の就職希望者を前記センターサーバーに対し、又は電子メールにより特定する面接希望者特定手段と、該面接希望者特定手段で特定された就職希望者が前記センターサーバーに対し、又は電子メールにより面接を受諾する面接受諾手段と、該面接受諾手段で面接の受諾がされたとき、前記就職希望者の求職情報の完全データを前記データベースより抽出して前記企業、商店等に送信する完全情報抽出送信手段とを備えて構成した。
ＷＷＷサーバ３のサイトの運営者より就職希望者の情報を随時提供し、これらの就職希望者の情報の中から企業や商店等側が面接を望む就職希望者が存在した場合に就職希望者側に対し就職のアプローチをする場合である。
センターサーバーから就職希望者個人の求職情報の内の一部データを少なくとも一人分提供する。この提供は、電子メールにより自動配信されることが望ましいが、ファックス等で配信されてもよい。あるいは、センターサーバー側で企業、商店等に対し閲覧自在となるように閲覧ページが用意されてもよい。この提供された就職希望者個人の求職情報の一部データを見た企業、商店等が面接希望の就職希望者を特定する。この特定は企業、商店等がセンターサーバーにログインして所定のＷｅｂ画面にて行ってもよいし、電子メールにて返答をすることで特定されるようにしてもよい。その後、面接受諾の意思表示のあったときに就職希望者の求職情報の完全データをデータベースより抽出して企業、商店等に送信する。
以上により、商店等に対し適材と思われる人材が随時推奨されるので商店等は希望する人材を容易に得ることができる。省力化されているため求職、求人情報を安価に提供できる。
更に、本発明は、前記企業、商店等が前記就職希望者の採用について意思表示する採用意思表示手段と、該採用意思表示手段での意思表示が所定期間内にされたか否かを判断する判断手段とを備えて構成した。
所定期間内に採用や不採用、キャンセル等の採用結果が得られなかったことを早期に発見することで就職斡旋を円滑、かつ確実に行うことができるようになる。
更に、本発明は、商店等により提供される商品及び／又はサービスのユーザに対する希望販売価格又は希望販売率と、該希望販売価格又は希望販売率に対して設定され、該商品及び／又はサービスの購入に対し使われ、若しくは他の商品及び／又はサービスの購入に対し使われる現金還元額又は還元率又はポイントと、該現金還元額又は還元率又はポイントに相当する額等の一部若しくはすべてを蓄積する蓄積手段と、該蓄積手段に対し入金又は出金自在とする入出金手段と、該入出金手段により蓄積された金額及び／又は前記蓄積手段で蓄積された額等を前記商品及び／又はサービスの支払い代金の一部若しくは全部として使用する支払い手段とを備えて構成した。
蓄積手段には現金還元額又は還元率又はポイントに相当する額等が蓄積される。この蓄積手段に対しては、入金又は出金が自在である。この入金や出金は銀行口座等の金額を参照しつつデータベースを更新するようにしてもよいし、銀行口座と一体化されてもよい。また、銀行口座と連携されるようにしてもよい。商品やサービスの購入に際し、蓄積手段に入金された金額や蓄積手段に蓄積されている現金還元額を利用して支払い代金の一部若しくは全部として使用する。
以上により、商品代金の支払が簡単に行え、手数料も低く抑えることができる。
更に、本発明は、前記蓄積手段を有する商品販売者と、該商品販売者とは別に蓄積手段を有し、該商品販売者が販売する商品を購入する商品購入者と、該商品購入者による商品の購入に基づき、該商品購入者の有する蓄積手段から商品代金の一部又はすべてが引き出され、前記商品販売者の有する蓄積手段に蓄積されることを特徴とする。
以上のように、蓄積手段を利用して商品販売者と商品購入者間の支払が行えることで、代金を支払ったのに商品が届かない状況や、商品を送ったのに代金の支払が無い等の事態を防止できる。このため、例えば個人対個人等の取引で、お互いに信頼関係がない状況でも安全に取引を行うことができる。また、この際には送金手数料等の負担もない。
貯めた貯金は降ろすことができる。貯金は、取引の都度降ろすこともできるが、複数回分の取引をまとめて降ろすようにすることで銀行手数料等は取引の都度降ろす場合に比べ実質安く抑えることができる。降ろさずに継続して貯められる場合には、手数料は一切かからず、便利である。降ろさない場合であっても、買物の支払に利用できる。
オークション等の個人間取引にも有効であり、取引を安全に行い、かつ手数料等を無料、若しくは安く抑えることができる。なお、本発明はポイント還元制に適用されてもよい。この場合には、貯めたポイントを現金に換算した上で支払を実施したり、逆に支払を受けた現金をポイントに換算する演算部分が必用となる。但し、支払を受けた現金はそのまま貯めるようにされてもよい。
更に、本発明は、サーバーに保存され、通常販売にかかる通常販売データと、サーバーに保存され、該通常販売より安価に設定されるセール販売にかかるセール販売データと、セール開始日時を現在日時と比較するセール開始日時比較手段、及び／又は、セール終了日時を現在日時と比較するセール終了日時比較手段とを備え、前記セール開始日時比較手段の判断でセール開始日時が現在日時より後のとき、及び／又は、前記セール終了日時比較手段の判断でセール終了日時が現在日時より前のとき、前記通常販売データに基づき形成されたホームページがユーザの情報端末に提供され、前記セール開始日時比較手段の判断でセール開始日時が現在日時より先のとき、及び／又は、前記セール終了日時比較手段の判断でセール終了日時が現在日時より後のとき、前記セール販売データに基づき形成されたホームページがユーザの情報端末に提供されることを特徴とする。
以上により、商店自身がＷｅｂ上で簡単にセールを実行出来る。通常販売からセールへの移行、あるいは、セールから通常販売への移行が円滑に行える。セールの終了時においても、商店はホームページについて特別な処置をしないですむ。なお、セール販売データは、通常販売データの中から選択されるのが望ましい。また、セール販売データは保存しておき、次のセールを実施する際に商店が以前のセール販売データを利用出来ることが望ましい。
更に、本発明（請求項１）は、ログインＩＤ、クレジットカード情報、情報処理装置固有の情報、バイオメトリクス情報若しくは該バイオメトリクス情報を基に生成された特徴データ、及び所定のロジックに従い生成されたシリアル番号のいずれか少なくとも一つをセンターサーバーのデータベースに登録する登録手段と、ホームページと、該ホームページに挿入された保護ソフトウェアの起動、情報処理装置固有の情報の取得、バイオメトリクス情報の取得及び所定のロジックに従い生成されるシリアル番号の取得のいずれか少なくとも一つを含む命令と、該命令に基づき取得された情報処理装置固有の情報、バイオメトリクス情報若しくは該バイオメトリクス情報を基に生成された特徴データ及びシリアル番号を送信するデータ送信手段と、該データ送信手段により送信されたデータをセンターサーバーにて受信するデータ受信手段と、該データ受信手段で受信されたデータを前記登録手段により登録されたデータと対比するデータ対比手段と、該データ対比手段による対比結果の一致を基に本人であると確認する本人確認手段とを備えて構成した。
クレジットカード情報のみをネットを介して送信し、情報の一致を判断することでのみ本人認証をすることは安全とは言えない。暗証番号によれば、安全性は増すがそれでも十分な本人確認であるとは言えない。このため、クレジットカード情報の一致を判断する以外に、情報処理装置固有の情報やバイオメトリクス情報の一致をも判断に加味するようにした。このことにより、クレジットカードの本人認証の確度を上げることができる。
保護ソフトウェアはユーザの情報処理装置にインストールされる。但し、ブラウザと一体化して構成されてもよい。ホームページに挿入された命令により、保護ソフトウェアの起動がされ、情報処理装置固有の情報の取得、バイオメトリクス情報の取得及び所定のロジックに従い生成されるシリアル番号の取得が可能である。クレジットカード情報は常に必要というものではなく、ログインＩＤと情報処理装置固有の情報、バイオメトリクス情報、シリアル番号の内のいずれか少なくとも一つの情報の一致を組み合わせることでも本人確認が可能である。また、これとは逆に、ログインＩＤを省略し、情報処理装置固有の情報等とクレジットカード情報の一致の組み合わせで本人のクレジットカードであることを認識するようにされてもよい。情報処理装置から取得したデータはファイルに保管してもよいが、センターサーバーに送信し、情報処理装置内には残さないようにされてもよい。
更に、本発明（請求項２）は、ログインＩＤ、クレジットカード情報、情報処理装置固有の情報、及びバイオメトリクス情報若しくは該バイオメトリクス情報を基に生成された特徴データのいずれか少なくとも一つをセンターサーバーに送信する送信手段と、該送信手段で送信されたデータを受信する受信手段と、ログインＩＤ、クレジットカード情報、情報処理装置固有の情報、及びバイオメトリクス情報若しくは該バイオメトリクス情報を基に生成された特徴データのいずれか少なくとも一つに対し割り付けられセンターデータベースに保存されると共に前記情報処理装置にも保存される所定のキーと、ホームページと、該ホームページに挿入された保護ソフトウェアの起動、及び／又は、前記所定のキーの送信を含む命令と、該命令に基づき取得された前記所定のキーを前記情報処理装置より送信するキー送信手段と、該キー送信手段により送信された所定のキーをセンターサーバーにて受信する受信手段と、該受信手段で受信された所定のキーを前記センターデータベースに保存された所定のキーと対比するキー対比手段と、該キー対比手段による対比結果の一致を基に本人であると確認する本人確認手段とを備えて構成した。
情報処理装置には、センターサーバーにおいて、ログインＩＤ、クレジットカード情報、情報処理装置固有の情報、及びバイオメトリクス情報等に対し割り付けられた所定のキーが保存される。即ち、所定のキーが分かれば、このキーからユーザのログインＩＤやクレジットカード情報、情報処理装置固有の情報等が分かるようになっている。保護ソフトウェアはユーザの情報処理装置にインストールされる。但し、ブラウザと一体化して構成されてもよい。ホームページに挿入された命令により、保護ソフトウェアの起動がされ、所定のキーの送信がされる。センターサーバーにおいては、この送信された所定のキーがセンターデータベースに保存されている所定のキーと一致するか否かを判断する。クレジットカード情報は常に必要というものではなく、ログインＩＤと所定のキーの一致を組み合わせることでも本人確認が可能である。所定のキーは情報処理装置のファイルに保管されるが、クレジットカード情報、情報処理装置固有の情報、及びバイオメトリクス情報等では無いので、漏れても一定の安全を確保できる。
更に、本発明（請求項３）は、前記情報処理装置固有の情報、及び／又は、バイオメトリクス情報若しくは該バイオメトリクス情報を基に生成された特徴データを保存するファイルと、前記命令に基づき取得されたデータと該ファイルに保存されたデータとを対比する対比手段とを前記情報処理装置に備えたことを特徴とする。
情報処理装置内部において、改めて取得されたデータとファイル内に保存されたデータの一致を判断することで、本人認証をまずユーザ所有の情報処理装置において行うことが出来る。その上でセンターサーバーにおいても更に本人認証が行われることになるので、一層厳格な本人の特定が可能となる。
以上説明したように本発明によれば、値段交渉手段で各商店等毎に値段交渉された結果がまとめてユーザに対し提供されるように構成したので、ユーザは各店舗毎に値引き交渉をするということなく複数の商店等についてまとめて値引き交渉が可能となる。このため、どの店が最も安く購入できそうか、若しくは最も安く購入できるか簡単かつ迅速に判断可能となる。
本発明の実施形態のシステム構成図 商品等の分類項目を示す画面 項目及びデータ入力欄の例 文字、数字、記号等入力補助ツール ソフトウェアを用いた登録申請方法例 サービス業務の場合の一例 フローチャート（その１） 料金体系の選択画面例 フローチャート（その２） フローチャート（その３） 当月度データベースの内容を示す図 ホームページのメイン画面例 地図表示例 一覧表示例 各商店等のホームページ フローチャート（その４） ユーザ希望情報メール送信サービスの例 フローチャート（その５） 電子メールの情報送付例 フローチャート（その６） フローチャート（その７） フローチャート（その８） フローチャート（第２実施形態である製品購入手順） 同上 フローチャート（値引き交渉可能回数Ｎのインクリメント） フローチャート（値引き交渉ルーチン） フローチャート（実数ｍをお客様の段階に応じて変動させる方法） フローチャート（危険を承知でチャレンジルーチン） フローチャート（確率ルーチン） ギャンブルの一例（スロット）を示す図 フローチャート（第３実施形態である製品購入手順） 同上 本発明の第４実施形態のフローチャート 本発明の第５実施形態の構成図 本発明の第５実施形態のフローチャート 本発明の第６実施形態のフローチャート 本発明の第８実施形態のフローチャート 履歴例その１ 履歴例その２ 履歴例その３ 底値の安い順等に提示されたリスト例 現金還元の実施されたものの履歴 現金還元額の大きい順等に提示されたリスト例 本発明の第１２実施形態のフローチャート（その１） 本発明の第１２実施形態のフローチャート（その２） 商品選択の画面例 本発明の第１３実施形態のフローチャート（その１） 本発明の第１３実施形態のフローチャート（その２） 本発明の第１３実施形態のフローチャート（その３） 本発明の第１３実施形態のフローチャート（その４） ご購入予定商品と比較例の対比図の様子を示す図 図５０の処理の別態様（その１） 図５０の処理の別態様（その２） 本発明の第１４実施形態のフローチャート 選択された機能の内存在する機能と存在しない機能とを明示した図 希望販売価格Ｘ、提示価格の中でも最高額である最大提示価格Ｅｍａｘ、底値Ｙとの関係を示す図 ユーザ希望入力価格Ｚと底値Ｙの比率であるＺ／Ｙと提示価格値との間の関係を示したグラフ 本発明の第１６実施形態のフローチャート 本発明の第１８実施形態のフローチャート（その１） 本発明の第１８実施形態のフローチャート（その２） 本発明の第１９実施形態のホームページの画面例（直接価格対比） ウィンドウショッピングのホームページの画面例 ウィンドウショッピングのホームページの画面例 特別店舗紹介コーナーの画面例 本発明の第２０実施形態のフローチャート 本発明の第２１実施形態のフローチャート ロボット店員によるユーザの訪問時間の管理 ロボット店員による天候の挨拶 ユーザの近況が変化した場合の時候の挨拶 ユーザの過去の購入情報を基にした挨拶 ボット店員が各店舗に合わせて衣替えするフローチャート 本発明の第２２実施形態のフローチャート（その１） 本発明の第２２実施形態のフローチャート（その２） 本発明の第２３実施形態のフローチャート（その１） 本発明の第２３実施形態のフローチャート（その２） 本発明の第２４実施形態のフローチャート（その１） 本発明の第２４実施形態のフローチャート（その２） 本発明の第３実施形態における直接減額される金額とユーザ貯金額の関係を示すグラフ 本発明の第２５実施形態における直接減額される金額とユーザ貯金額の関係を示すグラフ 本発明の第２６実施形態のフローチャート 本発明の第２７実施形態のフローチャート（その１） 本発明の第２７実施形態のフローチャート（その２） 本発明の第２８実施形態の動作フロー（その１） 本発明の第２８実施形態の動作フロー（その２） 本発明の第２８実施形態の動作フロー（その３） 本発明の第２８実施形態のＷｅｂページの画面例 本発明の第２９実施形態のフローチャート（その１） 本発明の第２９実施形態のフローチャート（その２） 本発明の第２９実施形態のフローチャート（その３） 本発明の第２９実施形態のフローチャート（その４） 本発明の第２９実施形態のフローチャート（その５） 本発明の第２９実施形態のフローチャート（その６） 本発明の第３０実施形態のフローチャート 本発明の第３１実施形態のフローチャート ユーザ貯金箱の概念図 本発明の第１７実施形態の適用例１、登録時の処理 本発明の第１７実施形態の適用例１、利用時の処理その１ 本発明の第１７実施形態の適用例１、利用時の処理その２ 本発明の第１７実施形態の適用例２、登録時の処理 本発明の第１７実施形態の適用例２、利用時の処理 本発明の第１７実施形態の適用例３、登録時の処理 本発明の第１７実施形態の適用例３、利用時の処理その１ 本発明の第１７実施形態の適用例３、利用時の処理その２ 本発明の第１７実施形態の適用例４、登録時の処理その１ 本発明の第１７実施形態の適用例４、登録時の処理その２ 本発明の第１７実施形態の適用例４、利用時の処理その１ 本発明の第１７実施形態の適用例４、利用時の処理その２ 本発明の第１７実施形態の適用例４、利用時の処理その３ 本発明の第３２実施形態のフローチャート 本発明の第３２実施形態のフローチャート
以下、本発明の実施形態について説明する。本発明の実施形態のシステム構成図を図１に示す。図１において、インターネット１にはＷＷＷサーバ３、ユーザ５のパソコン及び商店等７のパソコンが接続されている。但し、パソコンに限定するものではなく、携帯電話や移動携帯端末等でも同様である。商店等７は、商品を販売するデパート、スーパー、通信販売の店等の他、産地直送店や農家、製造メーカー、問屋等であってもよい。また、病院、介護、ビジネス、流通、その他のサービス業も含む。ＷＷＷサーバ３の運営するホームページにはソフトウェア９のダウンロード可能なページがあり、商店等７はソフトウェア９をダウンロードする。また、ソフトウェア９はＣＤ−ＲＯＭの形でも提供される。ソフトウェア９は、商店等７が自己のホームページを作成し、完成したホームページをＷＷＷサーバ３に登録申請等するために利用される。また、ＷＷＷサーバ３より必要なデータを入手可能なようになっている。
ソフトウェア９がダウンロードされたパソコンにはスタートメニューやデスクトップに起動用アイコンが登録されるようになっている。起動用アイコンを起動した場合には、例えば図２に示すような商品等の分類項目を示す画面がパソコン画面に表示される。商店等７はこの分類項目の中から自店で販売やサービス等を行っている項目の内特売、販売したい項目や提供するサービス等を選択する。
図２において、仮に食品を選択した場合には、食品の下位概念として続いて図３の各項目及びデータ入力欄１０が表示される。商店等７で例えばさくらんぼｘｇをｙ１円で販売若しくは特売したい場合には、果物の項目を選択した後、データ入力欄１０の内の品名欄１１をまずクリックする。このとき、図４に示すような文字、数字、記号等入力補助ツール２０が表示される。文字、数字、記号等入力補助ツール２０は、それぞれ文字ボタン１４Ａ、記号等ボタン１４Ｂ、数字ボタン１４Ｃをクリックすることで独立して表示、消去させることが可能である。なお、この文字入力補助ツール２０Ａ、記号等入力補助ツール２０Ｂ、数字入力補助ツール２０Ｃを一括してタブ選択とし、文字ボタン１４Ａ、記号等ボタン１４Ｂ、数字ボタン１４Ｃを一つにまとめるようにしてもよい。この場合にはスペースを省略出来る。
そして、品名欄１１の下部には「頭文字を選択して下さい」の指示が出される。文字入力補助ツール２０Ａのひらがなキー３７を選択し「さ」をクリックすると「さくらんぼ」とひらがな表示される。複数の商品名候補が存在する場合には、候補表示がされ、いずれか一つを選択するようにメッセージ表示される。
次に、単位欄１３において、ドロップダウンリストボックスから例えば「グラム」単位を選択する。価格欄１５には、図４の数字入力補助ツール２０Ｃをクリックすることで入力する。価格欄１５には、希望販売価格を入力するが、他に定価をも入力するのが望ましい。メッセージ欄１７には、商店等７がこの商品に関し、例えば糖度や産地、生産者、３割引等を宣伝可能である。漢字入力したい場合には、例えば、漢字指定範囲の先頭までカーソルを持っていき、漢字変換２１をクリックすれば市販の文字入力ソフト等と連携され、漢字候補が表示され、その候補の中から選択可能である。また、メッセージ欄１７はコンボボックスとし、当該分野において使用が想定される標準的なメッセージが予め用意され選択可能とされている。この場合、メッセージは英文にも対照されている。また、メッセージ欄１７を音声再生スイッチに変え、音声保存されたデータを再生し、宣伝に供するようにしてもよい。保存される音声は予め標準で用意された音声ファイル中から選択してもよいし、商店等７が独自に音声入力したものでもよい。当該商品等をインターネット上で販売をするのか、あるいは単に宣伝のみを行うのかをネット販売実施可否欄８にて選択する。
ネット販売実施可否欄８で販売を行う旨の選択がされている場合には、次の値引き交渉欄１９、底値記入欄２３が入力可能となる。ユーザ５に対し値引き交渉に応ずることが可能ならば値引き交渉欄１９において、値引き交渉「可」を選択し、底値記入欄２３に底値ｙ２円を、図４の数字入力補助ツールをクリックすることで入力する。底値は、商店等７が値引き交渉に応じた場合に、これ以上の値引きには応じられない限界である最低価格値である。但し、この底値記入欄２３は、通常価格、お得意様限定価格、上得意様限定価格と分け、ユーザ５の今までの購入頻度や購入金額の合計等に応じて複数段階に底値を下げるようにしてもよい。なお、底値記入欄２３はユーザ５に対しては開示されない。また、図示していないが、各商品について配達が可能であるか否かを選択可能とするチェックボックスを設けてもよい。更に、配達の可能な場合には、配達の可能な地域である「近郊」、「市内」、「県内」、「全国」、「指定距離以内」等を選択可能とするチェックボックスを設けるのが望ましい。
品名、単位、価格、ネット販売実施可否、値引交渉の可、不可、可の場合には底値が最低限記入されたとき、データ入力欄１０の下段には次のデータ入力欄が追加表示される。なお、商店等７が例えば野菜も特売したい場合には、野菜をクリックした後同様の処理を繰り返す。特売品等が食品の他に家電等複数分類にまたがる場合には、１項目についてのデータ入力が完了した後、再び図２の分類項目に戻って続けて２項目を操作する。
画像欄２５に商品等の画像を取り込みたい場合には、画像欄２５をクリックするとウィザァードが自動的に立ち上がり、画像ファイルの存在するドライブ、ディレクトリ等を指定するように要求がされる。そして、サムネイル表示されたファイルの中から適当な画像を選択する。画像は写真や絵等であり、予め標準的なものが用意されている。品名欄１１で品名が選択されている場合には、この品名に基づき絞り込まれた画像が自動的に抽出され、サムネイル表示される。
但し、商店等７にて独自に画像を作成することも可能である。この場合、スキャナで読み込まれた画像や、ディジタルカメラにて撮像された画像はプレビューウィンドウの枠中に全体表示される。そして、全体画像の中から取り込みたい範囲を取り込み枠にて囲む。この際には、取り込み枠をマウスでドラッグや移動操作をして範囲調整する。但し、全体画像をそのまま使用したい等の場合には範囲調整しなくても構わない。確認ボタンをクリックすると、範囲選択された画像のサイズが抽出され、画像欄２５のサイズに自動調整された後、その画像が画像欄２５に張り付けられる。
なお、商店等７が独自に画像を作成する場合には、背景を削除する等の画像編集もソフトウェア９にて可能である。但し、かかる画像編集をＷＷＷサーバ３側にて行うように依頼することも可能である。このため、各画像欄２５にそれぞれ対応されて又は全画像を一括して編集依頼する図示しない画像編集依頼ボタンを配設してもよい。ＷＷＷサーバ３側では、依頼された画像を抽出し、背景を削除したり、トリミングを施したりする。
しかしながら、画像の必要ない場合には画像欄２５を操作する必要はない。また、画像欄２５には、商品の様子がより判断し易いように動画を取り込めるようにしてもよい。更に、画像欄２５にはＵＲＬ（Uniform Resource Locator）を配し、各商店等７が例えばこの商品の拡大画像も含め、この商品に関する詳細な情報等を独自に用意したホームページの形で提供できるようにリンクが可能である。
サービス内容欄２６はコンボボックスとし、例えば日替わりセール、タイムサービス、朝市、夕市、通常販売、空白等のサービス種類を選択可能である。そして、日替わりセールの場合には日を、タイムサービスの場合には時間を日・時設定欄２８に設定する。サービス内容欄２６で朝市、夕市が選択された場合は、日・時設定欄２８は日入力欄と時間入力欄とに分かれて表示される。日入力欄をクリックすると図５に示すカレンダー３０が表示されるので、カレンダー３０より日を選択し入力する。そして、時間入力欄に時間を記入等する。
データ入力欄１０に入力された項目は種類毎に並べ替えが可能であり、各項目毎にも移動ボタン１６により順番を変更可能である。削除ボタン１８により項目の削除も可能である。
次に、ボタン２７で次画面である図５に進む。図５では特売を行う商店等７では、特売日をカレンダー３０上で選択する。カレンダー３０は、パソコン内蔵の時計機能により自動更新される。まず、「特売日の開始日はいつですか。」のメッセージを表示して特売日の開始日を選択させる。続いて「特売日の終了日はいつですか。」のメッセージを表示して特売日の終了日を選択させる。商店等７は、特売期間欄２９により特売の期間を確認する。勿論、特売期間欄２９に直接キー入力等してもよい。特売の目的である例えば開店セール、記念セール、通常販売、毎週木曜日等を特売目的欄３１のコンボボックスから選択する。特売目的欄３１や特売期間欄２９も英文対照されている。メッセージ３３にはその他の自由記載が可能である。また、音声保存されたデータを再生し、宣伝に供するようにしてもよい。保存される音声は予め標準で用意された音声ファイル中から選択してもよいし、商店等７が独自に音声入力したものでもよい。
商店等７がＷＷＷサーバ３に対し登録されていない場合には、登録申請のための事項の記入が要求される。商店等名欄３５をクリックすれば、文字、数字、記号等入力補助ツール２０が表示されるので、例えばひらがなキー３７を選択し、文字入力補助ツールにより「とくばいせんもんてん」と記入する。この際には、漢字変換したい先頭にカーソルを移動し、漢字変換２１をクリックすれば「特売専門商店」と入力可能である。このような手順をメッセージによりガイドするのが望ましい。
このようにすることで、キー操作に不慣れな人でも簡単に文字入力可能となる。郵便番号入力欄３９には郵便番号を記載する。この郵便番号に割り付けられた住所地が住所欄に自動入力される。住所地は英文対照されている。そして、その後に文字、数字、記号等入力補助ツール２０により地番等を記入する。電子メール欄４１には、電子メール欄４１をクリックした後、文字、数字、記号等入力補助ツール２０により、小文字キー４３を選択して入力可能である。但し、電子メール欄４１が選択された場合には、記号等入力補助ツール２０Ｂ以外は表示されないようにしてもよい。また、大文字で入力された場合でも確定時に小文字に自動変換するようにしてもよい。業種欄３８はコンボボックスによりデパート、スーパー、八百屋、病院、税理士、不動産等選択可能なようになっている。
確認ボタン４５をクリックすると、以上に入力若しくは選択されたすべての項目がホームページ形式でリスト表示される。ホームページは壁紙等すべてが定型化された形式で統一されている。この際、バナナのように候補選択等された文字は自動的に英文字Ｂａｎａｎａにも対照されており、英語表示ボタン４４をクリックすることで、英文記載のホームページも同時に作成される。従って、文字入力欄等にキーボードから文字入力することは可能であるが、この場合には英文対照されない。このため、必要ならば英文字を直接入力する。
商店等７ではこのホームページの記載事項等を確認後、ＯＫであれば送信ボタン４７をクリックして送信する。送信先は、ソフトウェア９によりＷＷＷサーバ３のＵＲＬに指定されている。ＷＷＷサーバ３に送信されたホームページは受信後、所定の調査が行われた後にインターネット上で公開されることとなる。この交信の際には、ＷＷＷサーバ３は商店名等を顧客データベースに登録し、顧客ＩＤを発行し、この顧客ＩＤを商店等７のパソコンの特定のファイルに保存する。そして、登録完了の旨の通知を商店等７に対し送信する。
なお、ソフトウェア９は商品等の全分類項目をまとめて一つのソフトウェアとして説明したが、商店等７が小規模で販売品目等が限定されている場合を考え、商品等の分類項目毎にソフトウェア９を分離し、ダウンロードやＣＤ−ＲＯＭ提供可能としてもよい。この場合には機能が限定されている分使いやすく、ダウンロード時間も短く処理速度も向上する。
なお、図３及び図５は、例えば商店を対象とした一例であり、選択された分類等に従い、その分類にふさわしい表示項目、入力欄、データ等が予め用意され、ソフトウェア９に保存されている。
商品を対象とせずにサービスを提供する場合の一例を図６に示す。図６には病院の例を示す。診療科目欄１１１には内科、外科等をコンボボックスより選択し、担当医師名欄１１３を記入する。当該医師の担当曜日は月〜日曜日の内から選択される。今月の休診日１１５は図５のカレンダー３０より選択される。住所地は、郵便番号を入力した後、地番を入力する。駅欄１１７は最寄りの駅を入力する。
このように、ソフトウェア９では、各分類毎に定型化された共通の基本となるホームページを予め用意し、入力すべきデータをも予め扱われる品目等毎に各商店等７に対応したものを用意する。そして、このデータは、クリック操作により選択可能としたことで、キーボード操作が不慣れで、かつホームページの知識の無い人でも簡単にホームページを作成可能である。また、このようにデータも予め用意したので、日本語に対照した英文ホームページも同時に完成する。更に、形式や項目等の統一により、検索される際には余計なノイズが無くなり、検索精度が向上する。また、ＷＷＷサーバ３側にて種々のデータ処理を行う場合には、その処理が簡単に行える。
なお、ホームページの知識を有する人のために、設定により壁紙等の選択を可能とするようにしてもよい。また、ホームページはソフトウェア９により作成されたものではなく、商店等７が別に独自に作成したものをＷＷＷサーバ３にリンクさせることも可能である。
また、ソフトウェア９には過去のデータを履歴として保存可能とし、カレンダー３０で選択された日の情報を参照できるようにしてもよい。
更に、ソフトウェア９には商店等７が販売や宣伝をしたい画像や項目、特売情報、商店等７の情報等が既に揃っているので、この画像や項目等を利用してカタログや新聞の折り込みチラシ、店頭掲示用チラシ、葉書広告等を作成させる機能を付加させることが可能である。まず、印刷される対象の用紙を選択すると、この用紙のサイズに合った形のひな型が複数個表示される。商店等７はこのひな型を参照し、ひな型の中から好みのものを一つ選択する。ひな型には予めどの位置に値段が表示され、どの位置に画像が配設されるか、その他背景や模様、レイアウト等が決められている。
なお、用紙単位にひな型を用意するのではなく、各商品欄単位毎に独立させて、あるいは商店等表示欄に対しひな型を用意するようにしてもよい。この商品欄単位には、画像欄、商品名欄、個数欄、価格欄、メッセージ欄等が属し、商店等表示欄には、商店等の名称、支店、営業時間、電話番号等が属する。それぞれの欄には、複数のひな型から自由に選択可能とするのが望ましい。また、画像欄、商品名欄、個数欄、価格欄、メッセージ欄等を各商品欄単位毎に自由にレイアウト可能としてもよい。
例えば、画面に表示された用紙の中の適当な位置に、まず商品欄単位が置かれる範囲（以下、商品欄範囲という）や商店等表示欄を選択する。このとき、この商品欄範囲の中には画像欄、商品名欄、個数欄、価格欄、メッセージ欄等が標準的な大きさ、位置で表示される。商品欄範囲を拡大、縮小、移動すれば画像欄、商品名欄等もこの商品欄範囲に従い拡大等される。画像欄、商品名欄等はその属する商品欄範囲内で移動可能であり、削除、コピーや拡大縮小も可能である。そして、商品欄単位は、分類毎整理のボタンをクリックすることで、サービス目的である本日限り、朝市等の各分類毎に整理し、ブロック分けすることも可能である。
更に、商品欄範囲には、写真欄、図形欄、背景、模様、宣伝文入力欄等様々な部品を挿入若しくは重ね合わせ等可能なように選択可能に用意してもよい。また、大きさも可変可能としてもよい。宣伝文入力欄には様々な宣伝文が記入可能である。各商品欄単位には番号が割り付けられ、図３の各項目をこの番号に対応させることで自動的に画像欄、商品名欄等が読み込まれ折り込みチラシ等のレイアウトが完成する。
なお、このように番号に対応させる方法ではなく、まずすべての図３の各項目を選択された所定の用紙サイズに合わせてサービス目的毎に標準的配列に従い割り付け、その後に商店等７により削除、移動、拡大縮小、内容の修正等が行われるようにしてもよい。この際には、自動調整ボタンを設け、削除等のされた後に自動的に空欄等を埋める形で大きさや位置を調整可能なようにするのが望ましい。文字や数字の書体等もひな型の中から選択する。各項目毎に書体を変えることも可能である。
写真欄や図形欄が挿入されている場合には、この写真欄や図形欄をクリックした後、フォルダ、ファイルを選択する。ファイルはサムネイル表示されるのが望ましい。カラーを選択して所定の用紙にプリンタで印刷することで簡単に折り込みチラシ等を作成可能である。更に、完成したチラシ等はホームページ形式とした後、ＷＷＷサーバ３にアップロード可能である。
次に、ホームページ掲載に要する料金体系を定める一方法について説明する。 商店等７により作成されたホームページは次のように価格に反映される。図７のフローチャートに示すように、ステップ１（図中Ｓ１と略す。以下同旨）で確認ボタン４５がクリックされると、ステップ３でソフトウェア９は、作成されたホームページの合計データサイズが何〔ＫＢ〕かを検出する。英文の存在する場合には英文ホームページもデータサイズが合計される。ステップ５でデータサイズがａ１〔ＫＢ〕以下のとき、ステップ７で「ホームページ掲載の基本料金はＭ１円です。」と表示する。Ｍ１円には、例えば無料の場合も含む。ステップ９でデータサイズがａ１〔ＫＢ〕を超えてａ２〔ＫＢ〕以下のとき、ステップ１１で「ホームページ掲載の基本料金はＭ２円です。」と表示する。
そして、ステップ１３では「終了してよいですか？」との問い合わせが表示される。よい場合には「はい」ボタンをクリックしステップ１５で終了する。高いと感じた場合や更に多くの項目を追加したい場合には「いいえ」ボタンをクリックしステップ１７に進む。ステップ１７では、「商品項目や画像を追加・削除して下さい」の問い合わせが行われる。現状で良ければステップ１５で終了し、商品項目、画像を追加や削除したい場合にはステップ１９に進み不要箇所の削除等を行う。そして、再びステップ１から同様の処理を繰り返す。
このように、ホームページ掲載の基本料金を無料若しくは所定の最低金額を基礎とし、その後はホームページの合計データサイズに応じて連続的又は段階的に料金を上げることが可能となる。また、商店等７ではホームページ作成時点でホームページ掲載の基本料金を確認でき、掲載の効率を考慮することができる。
以上は、データサイズによりホームページ掲載の基本料金を定めるとして説明したが、この値段で月当たりの掲載料金を固定とすることも可能である。
次に、各商店等７で作成されたホームページにはそれぞれに図示しないカウンタを設ける。そして、ホームページにユーザからアクセスのあった都度カウンタ値をインクリメントさせる。そして、このカウンタ値に応じて料金体系を定める。これに先立ち、各商店等７には、登録申請時に図８に示すようにいずれかの料金体系を選択させる。標準としては項目１の「月当たりＮ１回までＰ１円で、Ｎ１回を超えるとホームページの閲覧が制限（若しくは閲覧不可）される。」が選択されている。この項目１が選択されている場合、月当たりカウンタ値がＮ１回まで掲載料はＰ１円で、カウンタ値がＮ１回を超えるとホームページの閲覧が制限等される。
Ｐ１円は例えば図７でホームページ掲載の基本料金として算出したＭ１、Ｍ２・・円である。他に、項目２「月当たりＮ２回までＰ２円、Ｎ２回を超えるとホームページの閲覧が制限等される。」、項目３「月当たりＮ３回までＰ３円、Ｎ３回を超えるとホームページの閲覧が制限等される。」が選択可能である。ホームページの閲覧制限は、例えば商店等名や住所等の一部の項目を除き表示せず、検索も商店等名以外出来なくするものである。また、項目４では、各カウンタ値の段階に応じて値段を異ならせ、カウンタ値が大きくなる程重み付けを低くする。更に、項目５では、月当たりの定額を選択可能である。
図９のフローチャートに基づき詳細を説明する。まず、ステップ２１で例えば毎日定期的にソフトが起動される。ステップ２３で、顧客データベースに登録されている例えば登録番号がＣ番めの商店等７のホームページが選択される。ステップ２５でそのホームページへのアクセス数であるカウンタの積算数を読む。ステップ２７で、カウンタ値がＮ１回を超えているときステップ２９に進み、登録申請時に図８で、項目１の「月当たりＮ１回までＰ１円で、Ｎ１回を超えるとホームページの閲覧が制限等される。」が選択されている場合には、ステップ３１において、ホームページ上の商店等７の機能を制限する。そして、ステップ３２に進みカウンタ値をゼロとし、ステップ３３で商店等７の登録申請日に相当する翌月まで休止扱いとする。
ステップ２７でカウンタ値がＮ１回を超えていないとき、ステップ３４で登録番号Ｃ＋１番にインクリメントされ、ステップ２５でＣ＋１番めの商店等７のカウンタ数が読まれる。ステップ２９で項目１が選択されていない場合には、ステップ３５でカウンタ値がＮ２回を超えているときステップ３６に進み、登録申請時に図８で、項目２の「月当たりＮ２回までＰ２円で、Ｎ２回を超えるとホームページの閲覧が制限等される。」が選択されている場合には、ステップ３１〜ステップ３３の処理を行う。ステップ３５でカウンタ値がＮ２回を超えていないとき、ステップ３７で登録番号Ｃ＋１番にインクリメントされ、ステップ２５でＣ＋１番めの商店等７のカウンタ数が読まれる。以下同様である。
以上により、商店等７のカウンタ数が予め定めた所定値以上になったときには当該商店等７のホームページ上の機能を制限可能である。従って、利用料金に応じたホームページ掲載サービスが提供可能であり、低価格のサービスを実現出来る。また、機能制限されたホームページ部分や画像等を一旦記憶部分から他の記憶部に移動したり、削除等すればデータベース等の負担が軽くなる。
次に、図８の項目４に関し、月末の請求方法を図１０のフローチャートに基づき説明する。図１０に示すように、ステップ４１で月末の請求書作成のための起動がされる。ステップ４３で登録番号順に顧客データベースにアクセスする。但し、商店等７毎に登録申請日を基準に月末処理が行われるような場合には、月末に相当する商店等７をまず検索する。そして、ステップ４５でカウンタ値を読む。ステップ４７でカウンタ値がＮ１以下のとき、ステップ４９でその商店等７の当月の請求額はＱ１円となる。Ｑ１円は、例えば図７でホームページ掲載の基本料金として算出したＭ１、Ｍ２・・円である。
ステップ５１でカウンタ値がＮ２以下のとき、ステップ５３でその商店等７の当月の請求額はＱ１＋Ｑ２円となる。ステップ５５でカウンタ値がＮ３以下のとき、ステップ５７でその商店等７の当月の請求額はＱ１＋Ｑ２＋Ｑ３円となる。ステップ５５でカウンタ値がＮ３を超えているとき、当月の請求額はステップ５９でＱ４円となる。そして、請求額の計算が終わった場合にはステップ６１で登録番号Ｃ＋１番にインクリメントされ、ステップ４３より同様の処理を繰り返す。
以上により、ホームページの閲覧された度合いが少ない場合には低額若しくは無料とし、その後ホームページが閲覧された度合いに応じて料金請求がされるため、費用体系が合理的であり、商店等７は安心し、かつ気軽にホームページを掲載できる。
次に、商店等７が自分のホームページにアクセスした場合や、心ないユーザ５によりホームページが無用の頻繁なアクセスをされた場合の対処について説明する。
商店等７より自己のホームページにアクセスをする場合には、ソフトウェア９の図示しないホームページ確認ボタンにより行う。この際には顧客ＩＤが商店等７のパソコンの特定ファイルより検出されると共に、自己のアクセスとしてカウントされない。但し、積算値がデクリメントされるか、図９のステップ２５又は図１０のステップ４５のカウンタ値を読む際等に自己のアクセス分をまとめて積算値から減算するようにしてもよい。自己のアクセス分は、ソフトウェア９側で計測しＣｏｏｋｉｅ等に保存され交信の際に読み込まれてもよいし、ＷＷＷサーバ３側で顧客ＩＤ単位に計測されてもよい。また、登録申請の交信時にＣｏｏｋｉｅ等にも顧客ＩＤを記録した場合には、ソフトウェア９の起動等にかかわらず、ＷＷＷサーバ３により顧客ＩＤが検出され、検出された顧客ＩＤが顧客データベースの内容と一致した場合には自己のアクセスとしてカウントされない。
ユーザ５がホームページにアクセスした場合、送信された交信メッセージにユーザＩＤが存在しない場合には、ユーザＩＤを発行し、Ｃｏｏｋｉｅ等に記録する。以降の交信メッセージにはユーザＩＤが含まれるので、このユーザＩＤを検出することで、商店等７と異なることを検出可能である。また、ユーザ５がホームページにアクセスした際に簡単な仮登録申請をさせ、ユーザＩＤ等を発行し、以降このユーザＩＤを使用に際し記入させるようにしてもよい。更に、住所、氏名、電話番号等正式に会員登録を済ませたユーザ５のみに商店等７のホームページを利用可能としてもよい。この場合には、例えばユーザＩＤ、暗証番号等の入力を要求し、会員であることを確認した後ホームページを利用可能とする。会員でない場合には登録申請画面を表示する。
図１１には、当月度データベースの内容を示す。当月度データベース５０には、各顧客ＩＤのホームページに対し、各ユーザが当月内に何回アクセスしたかをテーブル作成したものである。当月の開始日、終了日はすべてを統一させることも可能であるが、当月度データベース５０では登録申請日を月の開始日としている。このようにすることで、図８の項目１〜３に示すカウント数の上限を設定したアクセスされない商店等７の数が特定の期間に集中するのを防止出来る。
当月度データベース５０のカウント数の積算において、例えばユーザＩＤ１の人は、顧客ＩＤ１のホームページに３０回、ユーザＩＤ４の人は、顧客ＩＤ１のホームページに４回アクセスしているが、無用にアクセスされた場合を考慮し、例えば３回以上同一人からのアクセスがあった場合でも３回以上はカウントしないこととする。このため、顧客ＩＤ１のカウント数の積算は、３＋１＋２＋３＝９のようになる。ユーザＩＤ５の人は、３＋３＋３＋２＝１１で、図８のＮ１＝１０としたときには、本日以降ホームページの閲覧は機能制限等される。
本日が月の終了日９日の場合には、顧客ＩＤ１、顧客ＩＤ４はカウント数の積算を行ったのち、図１０等により請求書を発行する。その後、顧客ＩＤ１、顧客ＩＤ４の各ユーザのカウント数をゼロにする。なお、カウント数の積算は、別途各顧客ＩＤ毎に累積され、履歴や、ホームページの人気度ランキング等に利用される。
次に、図１２にＷＷＷサーバ３によるホームページのメイン画面例を示す。メイン画面からは各種検索が可能である。地域選択のための地図キー５１をクリックすると日本地図が表示される。その後、更に例えば東京都、中央区、銀座と順次希望の地域を絞り込みクリックする。このとき、図１３に示す銀座付近の地図と共に、各商店等７の店名及び業種が表示される。商店等７をクリックすることで各店のホームページに進む。
地区名入力欄５３は上位概念から下位概念へと選択可能なドロップダウンリストボックスであり、例えば東京都に続き中央区、続いて銀座とツリー化されて選択可能である。続いて、地図表示ボタン５６をクリックすると図１３に示す地図形式の表示画面が表示され、一覧表示ボタン５７をクリックすると図１４に示す一覧形式の表示画面が表示される。駅名入力欄５５には、路線名及び駅名を選択することで当該駅の周辺地区を開くことが出来る。
この際、一覧表示ボタン５７をクリックすると当該駅の周辺の商店等７が一覧表示される。このため、顧客データベースにおいて、商店等７は、各駅と関連付けされている。図１４では、選択された地域の商品等の分類項目に属する各商店等７の店名、業種及び特売日等がテキスト表示される。ユーザ５は興味のある商店等７を選択し、各商店等７のホームページに進む。
図１２のメイン画面からは、品目に限定した検索も可能である。業種欄５８でツリー化された業種を上位概念から下位概念にたどることで寿司屋、学校、弁護士等選択可能である。また、キーワード入力欄６１に商品名等を記入し、検索ボタン６３をクリックすることで当該商品等を扱う商店名等、特売日、住所地等が一覧表示される。キーワード入力欄６１に商店名を直接入力し、商店等７のホームページに直接進むことも可能である。更に、本日が特売日キー６５をクリックすることで、本日が特売日に当たる商店名、特売日、住所地等が表示される。ユーザ５は興味のある商店等７を選択し、各商店等７のホームページに進む。
キーワード入力欄６１に商品名を記入した後、値段欄６７に値段の上限値若しくは下限値、又はこれらの双方を記入して検索ボタン６３をクリックすると、当該商品を当該値段で扱う商店名、特売日、住所地等が表示される。但し、商品名が例えばエアコンのような場合には、多数のメーカ名と機種が存在する。また、畳数等の使用容量を示す条件によっても異なる。このため、検索ボタン６３をクリックした後、これらの条件を選択させるページを表示し、この条件選択がされた後に商店名等を表示するようにしてもよい。更に、図示していないが、値引き交渉可能な店に限定可能なようにしてもよい。
また、価格範囲と各商品等の属性を基に決められる各条件を指定することにより、所定の検索が行えると同時に、商品の売れ筋情報やお勧め情報がユーザ５に対し提示されるようにしてもよい。このため、ＷＷＷサーバ３側にて価格範囲と各条件に応じて予め商品の売れ筋情報等をホームページ形式で作成し、保存しておく。そして、指定された価格範囲に一致若しくは重複し、かつ各条件に合致するホームページを検索、抽出してユーザ５に対し表示する。ユーザ５は、この売れ筋情報やお勧め情報を基に確実な商品知識を得ることができる。このことにより、購入したい商品等を的確に短時間に絞ることができる。
しかしながら、この商品の売れ筋情報やお勧め情報は、各商店等７毎に独自に作成されたものが保存され、提示されてもよい。ソフトウェア９には、各商店等７又は各機種毎に売れ筋情報や店長お勧め情報等が記載可能なようにする。これらの情報は、ソフトウェア９によりホームページ形式とされ、アップロード可能である。そして、この売れ筋情報等は、各商店等７や各機種毎にページ保存され、リンク可能である。
タイムサービスボタン７１、朝市ボタン７３、夕市ボタン７５をクリックすると現在行われているか、または、今後例えば２時間以内にタイムサービス等が実施される予定の商品名、商店等７の名称等が表示される。均一セールボタン７７をクリックすると、例えば２００円均一セール、１０００円均一セール等が行われている商店等７の名称等がテキスト表示される。
営業時間入力欄７９のコンボボックスで１０時〜２３時や２４時間等を選択すると、該当する商店等７の名称等がテキスト表示される。これらは、地区名入力欄５３や業種欄５８等と組み合わせることで、より効果的な検索が可能である。即ち、例えば、顧客データベースには、商店名、ＵＲＬ、業種、商品等の分類項目、営業時間、地区名、商品名、この商品の値段、値引き交渉可か否か、特売情報、最寄りの駅名等が保存されている。特売情報には、セール目的、朝市、夕市、タイムサービス等や特売品目、値段、特売日、特売時間等が含まれる。そして、これらのデータは互いに関連付けされており、いずれの項目の検索によっても必ず商店名、ＵＲＬを含む情報が抽出される。地区名は都道府県名、区、市、郡、町、村のそれぞれ、又は組み合わせによっても商店名、ＵＲＬが抽出可能である。従って、検索効率は向上する。
検索結果である商店等名欄をクリックすることで、例えば図１５に示す各商店等７のホームページに進む。図１５において、商店等７の扱う小分類項目毎に商品が整理されて開示されている。価格欄１５には、希望販売価格が表示されるが、他に定価をも表示されるのが望ましい。また、日替わりセール、タイムサービス、朝市、均一セール等が開催される場合には、各サービス分類に従い商品が整理され、開示される。これらのセールは時々刻々によりデータが変わるため、ユーザ５のアクセス数は向上する。
なお、各セールの日や時間はＷＷＷサーバ３側に内蔵の時計機能から現在日、現在時刻が抽出され、古くなったデータは削除される。従って、ユーザ５を混乱させることはない。画像２５にはＵＲＬが関連付けられており、ユーザ５は画像２５をダブルクリックすることで商店等７が独自に用意したホームページに進み、商品の詳細な情報を入手可能である。
値引き交渉欄１９で値引き交渉が「可」とされている場合には、ユーザ５はユーザ希望購入価格欄９１に希望購入価格を入力する。そして、個数欄９３に購入する個数を入力する。その後、購入ボタン９５をクリックすると、仮想店員の顔が現れ、「うーん、少し考えさせて下さい」等と表示又は音声出力する。この際の顔の表情や言葉は、複数用意し、価格欄１５に提示された金額より低い割合となる程渋い顔等にしたり、底値に近くなった場合に「参ったなあ」等と表示するようにすると効率的で興味深い。その後、仮想店員の値段も含めた返事が店員返事欄９７に表れる。店員返事欄９７の金額は、別途用意される電卓に表示されるようにしてもよい。
値引き交渉は、商店等７の各品目毎に、各ユーザ５に対し例えば月当たり３回だけチャンスをみとめるようにする。従って、ユーザ５は仮想店員との間の駆け引きで真剣勝負をせざるを得ない。各商店等７は、値引き交渉が考慮される分、他店の値段を気にすることなく、自分なりの値段を自由に価格欄１５に提供でき、値段の提供方法に自由度が増す。即ち、同一の品物が他店よりも高く価格欄１５に提示されていたとしても、ユーザ５の値引き交渉の仕方如何により、また底値如何により当該他店よりも低い値段となりうるものである。
次に図１６のフローチャートに基づき値引き交渉方法を説明する。図１６には、ユーザ５が同一商店等７で同一商品につき月当たり３回まで値引き交渉可能な例を示す。しかしながら、通常顧客、お得意様、上得意様と段階を分け、通常顧客には１回、お得意様には２回、上得意様には３回まで値引き交渉可能なようにしてもよい。また、購入個数と価格をかけた値段の大きさに応じて値引き交渉の回数を決めるようにしてもよい。更に、同一の商品について、値引き交渉可能な月当たりの商店等７の件数を制限するようにしてもよい。地域単位にこれらの制限を設けるようにしてもよい。
図１６において、ステップ７０では、ユーザ５は値引き交渉可能であることを確認する。ステップ７１で、ユーザ５は価格欄１５の値段Ｘ円を参考にして、ユーザ５が希望する価格である希望購入価格Ｚ円をユーザ希望購入価格欄９１に入力する。また、このとき同時に個数欄９３に購入を希望する個数を記入する。その後、ステップ７３で購入ボタン９５をクリックするとデータはＷＷＷサーバ３に送信される。
ステップ７５で値引き交渉可能な商品であることが確認された場合には、ステップ７７でユーザ個人が特定される。即ち、交信メッセージの中にユーザＩＤが含まれているか否か判断される。または、ユーザ個人を特定するためユーザＩＤや暗証番号等を入力させてもよい。ステップ７９でユーザＩＤが存在しない場合には、ステップ８１に進みユーザ登録作業を行い、ユーザＩＤを付与する。ユーザＩＤは例えばユーザパソコンのＣｏｏｋｉｅファイル等にも記録される。ユーザ登録作業は、住所、氏名、電話番号、電子メール等を入力するものである。また、登録作業を行わない場合には、仮ユーザＩＤを付与するようにしてもよい。
ステップ８３では、検出したユーザＩＤが過去にユーザデータベースに保存されたデータと一致するか否か判断される。ユーザデータベースに存在しない場合には、新規のユーザＩＤをユーザデータベースに作成する。そして、このユーザＩＤに対し当該顧客ＩＤの当該商品に１回目の値引き交渉を行うことを示すため１をインクリメントする。この値引き交渉回数は表示するのが望ましい。そして、ステップ８５では、価格欄１５の値段Ｘ円と予め商店等７が宣言している底値Ｙ円より（Ｘ＋Ｙ）／２円が演算され、希望購入価格Ｚ円との間で比較がされる。（Ｘ＋Ｙ）／２円を算出するのは、一例として希望販売価格と底値の中間をまず１回目の値引き交渉の目安値としたもので、希望販売価格より１割下げて１回目の値引き交渉の目安値とする等してもよく、この数式に限定されるものではない。
（Ｘ＋Ｙ）／２円が希望購入価格Ｚ円以下のとき、ステップ８７に進み、店員返事欄９７に「Ｚ円で販売します。」と表示する。但し、仮想店員の口元に表示等するようにしてもよい。また、仮想店員に「有り難うございます。」とお辞儀をさせるようにしてもよい。このＺ円の販売価格は、ステップ８８でユーザＩＤ、商店名、商品等と共にユーザデータベース等に保存される。一方、（Ｘ＋Ｙ）／２円が希望購入価格Ｚ円を超えているとき、ステップ８９に進み、底値Ｙ円と希望購入価格Ｚ円を比較する。希望購入価格Ｚ円の方が底値Ｙ円以上のときステップ８７に進み、店員返事欄９７に「Ｚ円で販売します。」と表示する。希望購入価格Ｚ円の方が底値Ｙ円を下回るとき、仮想店員にとっては思慮外なので、ステップ９１で店員返事欄９７に「目一杯、（Ｘ＋Ｙ）／２円でどうですか。」等と表示する。但し、（Ｘ＋Ｙ）／２円は百円単位や千円単位等に適宜端数の出ないようにするのが望ましい。
または、端数をなくすように交渉するための端数削除依頼ボタンを設けるようにしてもよい。このとき、端数削除後の値段が底値Ｙ円（又は底値Ｙ＋α円：αは予め定めた余裕値）以上の場合には、端数をなくすことを可能とする。この端数削除の可否を予め、商店等７に対しソフトウェア９により登録申請させるようにしてよい。
また、かかる端数の削除に代えて、あるいは端数の削除に併設しておまけを付けるように交渉するためのおまけボタンを設けるようにしてもよい。このとき、おまけの可否を予め、商店等７に対しソフトウェア９により登録申請させる。そして、この際には、おまけの商品名や型式等と共に単価を登録申請させる。ユーザ５よりおまけを付けるように要求された場合には、当該おまけを付けることにより底値Ｙ円（又は底値Ｙ＋α円）未満となるか否かを判断する。底値Ｙ円（又は底値Ｙ＋α円）以上の場合には少なくとも一つのおまけを付ける。なお、登録申請の際には、「常におまけを付ける」又は「値段交渉時のみにおまけを付ける」を選択可能としてもよい。
ステップ９３でＹＥＳボタンがクリックされた場合にはステップ９５で「ありがとうございます。（Ｘ＋Ｙ）／２円（但し、端数の削除された場合には削除された値段を表示する。また、おまけのある場合にはこれらも表示する。以下、同旨）で販売します。」と店員返事欄９７に表示する。この（Ｘ＋Ｙ）／２円の価格は、ステップ９６でユーザＩＤ、商店名、商品等と共にユーザデータベース等に保存される。
ＮＯボタンがクリックされた場合にはステップ７１に戻り、再び値引き交渉にチャレンジ可能である。希望購入価格Ｚ円を再びユーザ希望購入価格欄９１に入力する。今度はユーザＩＤがユーザデータベースに存在し、ステップ８３で同一人と認定される。ステップ９７では、交渉は成立済みか否か判断され、ステップ９５でこのユーザＩＤに対し既に交渉が成立済みの場合にはステップ９９で「この商品に関し、既に値引き交渉は（Ｘ＋Ｙ）／２円で成立済です。」と店員返事欄９７に表示する。
ユーザデータベースに、当該ユーザＩＤに対する顧客ＩＤの当該商品に１回の値引き交渉が行われたことを示す１が存在する場合には、２回目の値引き交渉と判断し、ステップ１０３に進む。ステップ１０３では、（Ｘ＋２Ｙ）／３円が演算され、希望購入価格Ｚ円との間で比較がされる。（Ｘ＋２Ｙ）／３円を算出するのは、価格欄１５の値段Ｘ円と底値Ｙ円の差を３等分した（Ｘ−Ｙ）／３円に底値Ｙ円を加算したものであり、第２回目の値引き交渉の目安値である。従って、第２回目の値引き交渉の目安値である（Ｘ＋２Ｙ）／３円は、第１回目の値引き交渉の目安値（Ｘ＋Ｙ）／２円より低い値段である。
ステップ１０３において、（Ｘ＋２Ｙ）／３円が希望購入価格Ｚ円以下のとき、ステップ１０５に進み、店員返事欄９７に「Ｚ円で販売します。」と表示する。一方、（Ｘ＋２Ｙ）／３円が希望購入価格Ｚ円を超えているとき、ステップ１０７に進み、底値Ｙ円と希望購入価格Ｚ円を比較する。希望購入価格Ｚ円の方が底値Ｙ円以上のときステップ１０５に進み、店員返事欄９７に「Ｚ円で販売します。」と表示する。希望購入価格Ｚ円の方が底値Ｙ円を下回るとき、ステップ１０９で店員返事欄９７に「限界です。（Ｘ＋２Ｙ）／３円でどうですか。」等と表示する。
ステップ１１１でＹＥＳボタンがクリックされた場合にはステップ１１３で
「ありがとうございます。（Ｘ＋２Ｙ）／３円で販売します。」と店員返事欄９７に表示する。ＮＯボタンがクリックされた場合にはステップ７１に戻り、再び値引き交渉にチャレンジ可能である。希望購入価格Ｚ円を再びユーザ希望購入価格欄９１に入力する。
３回目の値引き交渉においては、ステップ１１５でユーザデータベースに、当該ユーザＩＤに対する顧客ＩＤの当該商品に２回の値引き交渉が行われたことを示す２が存在するので、３回目の値引き交渉と判断し、ステップ１１７に進む。ステップ１１７では、（Ｘ＋３Ｙ）／４円が演算され、希望購入価格Ｚ円との間で比較がされる。（Ｘ＋３Ｙ）／４円を算出するのは、価格欄１５の値段Ｘ円と底値Ｙ円の差を４等分した（Ｘ−Ｙ）／４円に底値Ｙ円を加算したものであり、第３回目の値引き交渉の目安値である。なお、ステップ１１９〜ステップ１２８までの処理は前述したのと同様であるので説明を省略する。
値引き交渉が４回目になった場合には、ステップ１１５でステップ１２９に進み、既に決定済の３回目の値段が提示されて終了する。また、値引き交渉の目安値の一般式はｍを実数として、（Ｘ−（１−ｍ）Ｙ）／ｍ円であり、実数ｍは、各商店等７の希望により随時、変更可能である。更に、通常顧客、お得意様、上得意様の段階に応じて実数ｍを異ならせるようにしてもよい。お得意様、上得意様の判断は、例えばユーザＩＤ毎の利用頻度や購入金額の大きさに応じて判断する。
また、値引き交渉の結果に対して、ユーザ５が不満の場合、「もう一声」ボタンを押すことで一層の値引きが行えるようにしてもよい。このとき、ＷＷＷサーバ３側では、現在表示されている交渉価格と底値Ｙ円との間の価格を提示する。この価格は、乱数や予め定められた掛け率等によってもよいが、例えば先述の値引き交渉の目安値の一般式のｍをｍ＋１として演算し直すことで値段を下げユーザ５に提示する。「もう一声」の交渉の可否は、予め、商店等７に対しソフトウェア９により登録申請させる。
更に、同一の商品等について、他店の方が安かった場合には、「他店の方が安い」ボタンを押すことで更に値段交渉を可能としてもよい。このとき、他店との値段の比較の可否を予め、商店等７に対しソフトウェア９により登録申請させる。他店との比較は、同一地域内に存在する商店等７に限定されるようにしてもよい。この際の比較は、ユーザＩＤ及び同一の商品名にて過去データ（例えば１月分）の検索を行い、過去に行われた値段交渉の結果を抽出する。そして、この過去の値段が、現在の値段より本当に低かった場合に、過去の値段以下で、かつ底値Ｙ円以上の値段を提示する。但し、値段を下げる代わりに過去の値段以下で、かつ底値Ｙ円以上の値段となるよう前述のおまけを付けるようにしてもよい。また、同一の商品についての過去に行われた値段交渉の結果と比較するのではなく、他の商店等７の希望販売価格を抽出して値段を比較するようにしてもよい。更に、過去に行われた値段交渉の結果及び他の商店等７の希望販売価格の双方を抽出して値段を比較するようにしてもよい。
なお、買い物の都度若しくは買い物の最後には、購入リストを商店等名、商品等、購入金額、数量等と共に表示し、ユーザ５に確認してもらうのが望ましい。その際には、不要なものは取消可能とする。その後、購入リストは各商店等７毎に注文書として電子メールにて送信される。但し、ソフトウェア９がユーザ５のパソコンに常駐されれば、購入リストはソフトウェア９との間でデータ交信されてもよい。なお、ソフトウェア９には、注文書を履歴保存したり、各商品単位に月当たりの販売個数や金額、消費税等を合計したり等の演算や販売統計を取ることを可能としてもよい。ユーザ５の情報等もユーザ５のパソコン内に自動保存させれば、顧客管理にも使用できる。
また、ユーザ希望購入価格欄９１を設けず、図示しない一発回答ボタンを店員返事欄９７に隣接して配設し、ユーザ５にこの一発回答ボタンをクリックさせることで、予め用意した価格欄１５の値段Ｘ円より低い金額（例えば、底値Ｙ円）を店員返事欄９７に提示するようにしてもよい。店員返事欄９７への入力は自動による他、手動によることも可能である。この場合の金額は、通常顧客、お得意様、上得意様の段階に応じて異ならせるようにしてもよい。また、価格欄１５の値段Ｘ円より低い金額で、かつ底値より高い金額の範囲で乱数発生により宝くじのように提示してもよい。更に、くじ引きを導入し、当選した順位等により金額を異ならせるようにしてもよい。
なお、ユーザ希望購入価格欄９１には金額を入力するとして説明したが、４割引き等の割引率や定価の６割等の販売率を入力可能としてもよい。この場合であっても、割引率等を金額換算すれば前述と同様の処理で対処可能である。あるいは、ユーザ希望購入価格欄９１にはユーザ５が直接的に減額を希望する割引額を入力するようにしてもよい。
また、各商店等７では、図示は省略しているが、商品毎に配達を行うか否か、また配達の可能な地域である「近郊」、「市内」、「県内」、「全国」、「指定距離以内」等が表示されている。そして、ユーザ５は、配達の可能とされる商品について、チェックボックスにて「配達依頼」か若しくは「商品は取りにいく」を選択することができる。但し、この選択は、買い物の都度若しくは買い物の最後に行われる購入金額のユーザ５による確認の後でも修正可能とするのが望ましい。
「配達依頼」を選択した場合には、配達先欄に配達先を指定する。この配達先は、商店等７により予め登録された配達可能区域である「近郊」、「市内」、
「県内」、「全国」、「指定距離以内」等と比較される。この際には、地図データ上で商店等７の位置と配達先が比較され、商店等７からみた配達先が前記所定範囲内に包含されるか否か判断されたり、商店等７の位置と配達先の直線距離が算出され、前記指定距離以内に属する否か判断される。そして、配達先が配達可能区域から外れた場合には、「配達可能区域外」の表示をユーザ５に対し行う。
更に、各商店等７において配達を行わないとされる商品についても、地域内において、複数の商店等７で購入した商品等をまとめて配達依頼可能としてもよい。但し、この際には、図１５に示す各商店等７のホームページにおいて、まとめて配達可能な商品等の表示を各商品単位にしておく。そして、ユーザ５は、買い物の最後に「地域内まとめて配達依頼」を選択し、配達希望日時を選択する。
この「地域内まとめて配達依頼」を選択した場合の処理について、図２２のフローチャートに基づき説明する。
図２２において、ステップ３０１で、「地域内まとめて配達依頼」がユーザ５により選択される。ステップ３０３では、各商店等７で購入した商品の内から各商店等７において、独自に配達の行われる商品が配達対象リストより除かれる。ステップ３０５では、残された商品について、その商品の属する商店等７が顧客データベースより抽出される。ステップ３０７では、各商店等７に当該商品を取りに行き、ユーザ５に対し配達を行うことの可能な地域担当者（若しくは地域担当センター、以下同旨）が地域担当データベースより検索される。地域担当データベースには、予め商店名と共にこの商店について配達の可能な地域担当者が登録されている。
ステップ３０９で、地域担当者が一人（若しくは一か所の地域担当センター）ですむか否か判断される。一人ですむ場合には、ステップ３１１で商品の重量、大きさ等の予め設定されている料率の下に送料が計算される。一方、一部の商店が離れている等により、一人ではすべての商店にわたる配達が不可能な場合には、ステップ３１３に進む。そして、この地域担当者ではカバーできない商店をまず抽出する。次に、ステップ３１５では、この地域担当者ではカバーできない先述の商店を担当可能な地域外担当者が地域担当データベースより抽出される。
地域外担当者は、この商店から受け取った商品を宅配等の方法によりユーザ５に対し配送する。このため、ステップ３１７では、ユーザ５の住所から地域外担当者までの距離が算出される。ステップ３１１では、地域外担当者による送料が、この距離、商品の重量、大きさ等の予め設定されている料率の下に送料が計算される。そして、地域担当者の送料に対し地域外担当者の送料が加算される。
ステップ３１９で、地域担当者（及び地域外担当者）の電子メールアドレスが地域担当データベースより抽出される。ステップ３２１で、カード決済等による入金が確認された場合には、ステップ３２３に進み地域担当者（及び地域外担当者）の携帯電話やパソコン等宛に電子メールが送信される。この電子メールには、店名、品名、個数、受注日、配達先住所、氏名、配達希望日時等が記載される。また、配達先住所の位置を示す地図が添付されるのが望ましい。ステップ３２５では、地域担当者が電子メールを確認したことを返信する。この際、配達希望日時等の都合のつかない場合には、その旨の返信が地域担当者よりされ、この際には同時に都合のつく日時の候補が示される。その後、この都合のつく日時の候補がユーザ５に対し電子メール等で示される。ユーザ５が、この候補の中から一つを選択すると、この情報がＷＷＷサーバ３に自動返信される。候補の選択は、まず日を選択した後、時間を指定するのが望ましい。選択された日時は、ＷＷＷサーバ３より地域担当者に送信される。なお、地域担当者に直接電子メールを送信するのではなく、地域担当センターで受信し、この地域担当センター内で配達の可能な地域担当者を選定するようにしてもよい。ステップ３２７では、配達の完了した場合に、地域担当者はＷＷＷサーバ３に対し配達完了の旨の電子メールによる通知を行う。
以上により、ユーザ５が日常の買い物等の困難な人であっても地域担当者が代行して行うことができる。
次に、ＷＷＷサーバ３では、各商品やサービス毎にこれらの商品等が実際に販売された価格の最高額や平均額等を算出し保存する。そして、ホームページ上に各商店等７で扱われている各商品やサービス毎にこれらのデータを抽出し、各商店等７に対しダウンロード可能とする。これらのデータは、各商店等７にて当該商品やサービスの販売価格や底値を決める際の参考データとすることができる。なお、これらのデータは、各地域毎に価格の最高額や平均額等を算出し、ダウンロードするようにしてもよい。
次に、上述の例では、交渉の対象を商品等の値段として、交渉結果である商品等の値段に対し、消費税と、送料が規定されている場合にはこの送料が合算されるとして説明した。しかしながら、ユーザ５にとっては、特定の予算の範囲内で商品等を購入したい場合がある。この場合にユーザ５が商品等の値段をその都度自己の予算から逆算することは面倒な作業である。
かかる場合を考慮して、ユーザ希望購入価格欄９１には、消費税及び送料を含めたユーザ５の予算金額を入力可能としてもよい。このため、底値Ｙ円及び先述の値引き交渉の目安値に対しては、消費税及び先述の送料計算を行った後に、合算して合計金額を算出する。その上で、各合計金額をユーザ５の予算金額と比較して、値引き交渉を成立させるか否か判断する。
このことにより、ユーザ５は、自己の予算範囲で目的とする商品等が購入可能か否か簡単に判断できる。
また、上述の例では、値引き交渉の成立した価格にて商品等が販売されるとして説明した。しかしながら、商品等の販売は、あくまで価格欄１５の値段Ｘ円として、値段Ｘ円から値引き交渉の成立した価格を引いた残りの金額を、データベースにて各ユーザＩＤ毎にポイントや点数等の形で蓄えておき、後に他の商品等の購入の際に使用可能としたり、ある程度蓄積された所で景品や現金等に代えたりしてもよい。
この際には、ユーザ５にとっては、値引き交渉の努力の成果としてポイント等の蓄積されることが楽しみとなる。従って、購入意欲や購入に対する努力、研究も更に促進される。ホームページを訪れる機会も増えることで、広告等の宣伝効果も増す。値引き交渉による感動を維持しつつ一律の値段Ｘ円にて取引が可能となるので、処理作業が簡単に行える。また、残りのポイント等を確認するための残額確認ボタンやポイント等にて商品を購入するためのボタンを配設するのが望ましい。残額確認ボタンが押された場合には、各ユーザＩＤ毎に蓄積されたポイント等を抽出してユーザ５に対し表示する。
次に、ユーザ５に対しては、ユーザ５により予め選択された各商店等７のバーゲン情報等をまとめて電子メールにて送信可能なようにする。ユーザ５にとって、各商店等７毎にホームページを確認し、バーゲン情報等を把握するのは時間を要し煩雑な作業である。このため、お気に入りの商店や地域に存在する商店等７等の情報をまとめて提供することとする。また、購入したい商品等が決まっていれば、その商品等に関するバーゲン情報等をまとめて電子メールにて入手可能とする。
このため、図１４に示すように、バーゲン情報の入手を希望する旨のチェックボックス１０１を各商店等７毎に配設する。または、図１７に示すように、例えばメイン画面にユーザ希望情報メール送信サービス１３０を掲載する。そして、このユーザ希望情報メール送信サービス１３０にてユーザ５に対しメール送信を希望する必要項目を設定してもらい、その必要項目分の情報だけを抜粋し送信することも可能である。
ユーザ希望情報メール送信サービス１３０では、地区名入力欄１３１で地域選択が可能である。地区名入力欄１３１は上位概念から下位概念へと選択可能なドロップダウンリストボックスである。複数の地域を選択したい場合には、追加ボタン１３２をクリックする。この際には地区名入力欄１３１がもう一つ追加される。または、同一ボックス内に複数の記載が可能である。
特売の目的である例えば特売情報のすべて、開店セール、朝市、タイムサービス、均一セール、通常販売、空欄等を特売目的欄１３３から選択する。業種欄１３５も同様に選択可能である。商店等名欄１３７にはチェックボックス１０１で選択した場合には記載不要である。また、入力された商店等名が顧客データベースに存在しない場合にはその旨のメッセージが表示される。この場合、追加ボタン１３２を押すことにより図１４の画面に戻り、商店等を追加可能なようにしてもよい。商品名欄１３９には今後購入を予定しているため入手したい情報を選択する。例えば車を選択し、値段欄１４１に２００万円〜２３０万円等と記載する。但し、車等の場合には、車種やメーカ名等の条件を更に指定可能なようにするのが望ましい。なお、ＷＷＷサーバ３側にて価格範囲と商品等の各条件に応じて予め商品の売れ筋情報やお勧め情報等を保存しておき、かかる情報をも入手可能とするのが望ましい。値引き交渉が可能なものを選択したい場合には値引交渉欄１４１を選択する。送付店数上限欄１４５には、電子メールに送付される店数の上限値を記載する。標準値は例えば１０店に設定されている。この場合、検索された情報の内から１０店分以下の情報が送付される。
例えば、地域の特売情報のすべてを入手したい場合には、地区名入力欄１３１と特売目的欄１３３を設定する。プレビューボタン１４７をクリックすれば、検索が行われ、電子メールに記載される予定の項目が画面にてリスト表示される。ユーザ５が確認後、これでよければメール依頼ボタン１４９をクリックする。メール依頼ボタン１４９がクリックされた場合には、電子メールデータベースにユーザＩＤが登録され、そのユーザＩＤには検索条件が記録される。図１４でバーゲン情報の入手を希望する旨のチェックボックス１０１が選択され、かつ図１７のユーザ希望情報メール送信サービス１３０にも検索条件が設定された場合には論理和条件が取られる。
図１８のフローチャートに電子メール作成手順を示す。
ステップ２０１で、電子メールデータベースに登録されている例えばユーザ番号Ｕ（＝１）番めのユーザＩＤが選択される。ステップ２０３で、このユーザＩＤに登録された商店等名が抽出される。そして、ステップ２０５で、顧客データベースから、この商店等７のデータが取得される。この場合のデータは、例えば商店名、特売情報、特売期間、特売商品、値段等の限られた情報とする。
ステップ２０７では、この取得されたデータを商店等７に関連付けて電子メールデータベースに保存する。ステップ２０９で、商店名が複数存在している場合には、ステップ２０３に戻り次の商店名を抽出する。ステップ２０９ですべての商店名の抽出が完了している場合にはステップ２１１に進み、ユーザ番号をＵ＋１とする。ステップ２１３で、ユーザ番号の残りが存在する場合にはステップ２０３に戻り、同様の処理が繰り返される。但し、１ユーザ毎に電子メールを作成するようにしてもよい。
ステップ２１５では、各ユーザＩＤ毎に複数の商店等７が保存されている場合には、この各商店等７をホームページへのアクセス順位の高い順に配列する。このようにするのは、人気のある商店等７を電子メールの先頭に位置させるためである。ステップ２１７で、各ユーザＩＤ毎に電子メールを作成する。
電子メールの情報送付は例えば図１９のようであり、各商店等７にはＵＲＬがリンクされ、商店等７をクリックすることで各商店等７のホームページに直接アクセス可能である。このため、ユーザ５が気に入っている商店等７の概略情報がまとめて電子メールにて入手されると共に、その詳細情報を見たい場合にはホームページにアクセスすることで簡単に入手することが出来る。なお、ユーザ希望情報メール送信サービス１３０にてメール送信を希望しないユーザ５に対しては、購入実績のある商店等７をデータベースに保存しておき、この商店等７の新情報を送信するようにしてもよい。
次に、図２０のフローチャートに電子メール作成手順の別例を示す。
図２０において、ステップ２３１で、電子メールデータベースに登録されている例えばユーザ番号Ｕ（＝１）番めのユーザＩＤが選択される。ステップ２３３で、顧客データベースから登録番号Ｃ（＝１）番めの顧客ＩＤが選択される。ステップ２３５で予めユーザ５により設定された検索条件を電子メールデータベースより抽出する。そして、ステップ２３７では、顧客データベースのＣ番めの顧客ＩＤである商店等７から、この商店等７のデータがこの検索条件に基づき取得される。ステップ２３９では、この取得されたデータを商店等７に関連付けて電子メールデータベースに保存する。ステップ２４１で登録番号Ｃをインクリメントする。ステップ２４３で、顧客ＩＤがまだ残っている場合には、ステップ２３５から同様の処理を繰り返す。
ステップ２４５では、各商店等７をホームページへのアクセス順位の高い順に配列する。そして、ステップ２４７では、送付店数上限欄１４５に、電子メールに送付される店数の上限値が記載されているか否か判断される。全データが選択されている場合には、ステップ２４９に進みステップ２５１で電子メールを作成する。上限値が設定されている場合には、ステップ２５３で掲載数を上限値までに制限し、ステップ２５１で電子メールを作成する。電子メールの作成が完了した場合には、ステップ２５５で次のユーザ番号に進み、ステップ２３３から同様の処理を繰り返す。
以上により、ユーザ５の必要とする情報をきめ細かく配慮した形で電子メールによる情報の送付が行える。
次に、図２１のフローチャートに電子メール作成手順の更に別例を示す。
図１８及び図２０では、電子メールへの掲載順を各商店等７のホームページへのアクセス数の多い順としたが、図２１では各商店等７の意向を重視した形で掲載順を設定するものである。なお、図２０と同一要素のものについては同一符号を付して説明は省略する。
各商店等７に対しては、電子メールへの掲載順を配列順に応じて先頭から例えば１０段階に分けた場合に、どの段階に掲載されるのを望むかを予め登録申請時に選択させておく。この１０段階には、選択する場合の料金の目安を例として挙げておく。
図２１において、ステップ２３７で商店等７のデータが検索条件に基づき取得された場合には、ステップ２６１で顧客データベースの顧客ＩＤには、別途配設する乱数発生部により発生された乱数を割り付ける。但し、この乱数は、既に割り付けられた値と同一の値は排除される。ステップ２６３では、予めユーザ５により宣言された、１０段階中のどの段階であるかを顧客データベースから読み取る。電子メールデータベースの記憶部分は、この１０段階に対応させてデータを保存可能とする。そして、ステップ２６５では、電子メールデータベースのユーザ５により宣言された段階に保存する。ステップ２４３で、顧客ＩＤのすべてにわたりデータの保存が完了した場合には、ステップ２６７で各段階毎に乱数の値順に配列し直す。
以上により、商店等７のほぼ希望する順に、公平の原則の下に電子メールへの掲載順を決めることが出来る。
なお、各商店等７に対しては、情報送付されるユーザ５の数を通知すると共にその通知件数に応じて請求額が決められる。
または、電子メールは通常上から読まれるので、図１９においては、Ａ商店に相当する先頭位置を最も高額とし、Ｂ商店、Ｃ商店と進むに連れて値段を安く設定するようにしてもよい。例えば先頭からの順番に応じて料金を段階的に設定したテーブルを予め用意し、商店等７の掲載された順番からこのテーブルを基に料金を算出する。
なお、本発明は、ネットショッピングのみならず、企業間取引や流通取引等にも適用される。先述の値引き交渉の目安値の一般式のｍは、通常顧客、お得意様、上得意様の段階に応じて異ならせるとして説明したが、お得意様、上得意様の判断は、例えば企業規模や購入金額の大きさ等により判断する。従って、ユーザの登録申請の際には各企業に従業員数、資本金、設立年度等を登録してもらうのが望ましい。
ユーザの企業規模や購入金額の大きさ等により一般式のｍや底値Ｙ円を異ならせるか否かの可否、及びそのときのｍの値や底値Ｙ円の設定等は、予め、商店等７に対しソフトウェア９により登録申請させる。この場合には、企業規模や購入金額の大きさ等に応じて、複数の段階毎にｍの値や底値Ｙ円を異ならせて設定するのが望ましい。
また、最終段階での値引き交渉の結果に対しても、ユーザ５が不満の場合、更なる交渉の機会を設けるようにしてもよい。更なる交渉の機会は、例えば再交渉ボタンを押すことで、行われる。この際には、ユーザ５の名称や交渉の経過等が電子メール等により商店等７に対し連絡される。更なる交渉の機会を設けるか否かも、予め、商店等７に対しソフトウェア９により登録申請させる。
次に、本発明の第２実施形態について説明する。第２実施形態である製品購入手順のフローチャートを図２３及び図２４に示す。第２実施形態では、例えば、一つの製品を購入して貰ったら、１回値引き交渉を認めたり、お得意様の状況等により値引き交渉可能な回数に制限を持たせるものである。そして、不特定多数からの無用な値引き交渉アクセスを制限するものである。また、交渉の過程においてギャンブル性を持たせたものである。
図２３及び図２４において、ユーザ５は、ステップ５０１において製品を購入するためにセンターのホームページを開く。そして、ステップ５０３において購入したい製品（プロダクトＩＤ）のページに進み、ステップ５０５において製品の購入ボタンを押す。製品は、例えばソフトウエアとする。これにより当該製品を購入したい旨の情報がセンターに送信される。
センターは、ステップ５０７において、ステップ５０５で購入ボタンを押したユーザ５に対して購入画面（センターＨＴＭＬ）を提供する。これに対し、ユーザ５は、ステップ５０９においてユーザＩＤを入力し、ステップ５１１においてこのユーザＩＤをセンターに送信する。
センターは、ステップ５１３において、ステップ５１１で送信されたユーザＩＤを有するユーザ５が有効期限以内（例えば現在より過去１ヶ月以内）に当該製品（プロダクトＩＤ）に対して値引き交渉したことのある者か否かを判断する。センターは、このステップ５１３で、ユーザ５が同じ製品に対して短期間に繰り返し値引き交渉を行おうとしている者か否かを判断する。但し、このステップ５１３の前に、この製品が値引き交渉可能か否か判断するようしてもよい。値引き交渉のできない場合には、定価若しくは所定の割引率により販売する。
そして、このステップ５１３で値引き交渉されたことがある（ＹＥＳ）と判断された場合には、ステップ５２１において「既に値引き交渉済みです。」と表示し、ステップ５２３において値段、交渉日時、その製品名等を表示して、本手順を終了する。
一方、ステップ５１３で値引き交渉されたことがない（ＮＯ）と判断された場合には、ステップ５１５において値引き交渉可能回数Ｎが１以上か否かを判断する。センターは、このステップ５１５で、ユーザ５が何回値引き交渉が可能かを判断する。
そして、このステップ５１５でＮが１以上でない（ＮＯ）と判断された場合、すなわちＮ＝０の場合には、ステップ５２５において今回は定価販売になる旨を表示し、これに同意すればステップ５２７で定価の値段を表示する。また、この定価販売に同意した者に対しては、ステップ５３５以降の手順が行われる。一方、定価販売であることに不同意である者に対しては、本手順を終了する。
ステップ５１５でＮが１以上である（ＹＥＳ）と判断された場合には、ステップ６０１以降の値引き交渉ルーチンに進む。値引き交渉ルーチンについては、図２６に後述する。
値引き交渉ルーチンを経て図２４のステップ５２９で値引き交渉が成立すると、センターは、ステップ５３１において当該製品の値段（値引き交渉後の値段）を表示する。また、ステップ５３３において値引き交渉を１回行ったので、値引き交渉可能回数Ｎを１回デクリメントする。
さらに、センターは、ステップ５３５において当該製品の成立価格及び成立日時をデータベース１００９に保存する。この成立価格は、ステップ５４３の購入価格累計の加算に用いられ、成立日時は前述したステップ５１３の判断に用いられる。
その後、ユーザ５は、ステップ５３７において銀行振込、郵便振替、カード等の支払い方法を選択し、必要事項を入力することで購入手続を行う。そして、センターは、ステップ５３９においてユーザ５の行った購入手続の確認を行う。
さらに、センターは、ステップ５４１において、このユーザ５の今までの購入本数累計に対して今回の購入本数分をインクリメントする。また、ステップ５４３において、ステップ５３５で保存した成立価格をユーザ５の今までの購入価格累計に加算する。
そして、ステップ５４５において、当該ユーザＩＤに対し値引き交渉可能回数Ｎをインクリメントする。値引き交渉可能回数Ｎをインクリメントするのは、製品を購入して貰ったユーザ５に対しては、お得意様と考え、次回に値引き交渉の機会を与えてあげようとする趣旨である。このステップ５４５では、例えば図２５に示すように販売価格が５千円未満のときはＮに１をインクリメントし、５千円以上のときはＮに２をインクリメントし、一万円以上のときはＮに３をインクリメントする等のように、販売価格に基づいてインクリメント値を変更するようにしてもよい。但し、この際には、Ｎが複数回認められるからといって、同じ製品に対して値引き交渉回数を繰り返し認めることは望ましくなく、異なる製品に対して認めることが望ましい。そして、このステップ５４５の終了後、本手順を終了する。
次に、上述した値引き交渉ルーチンについて説明する。値引き交渉ルーチンのフローチャートを図２６に示す。
図２６において、本ルーチンが始まると、センターは、ステップ６０１において、ユーザ５に対し購入画面上に仮想店員を表示する。そして、ステップ６０３において、仮想店員の口元に「いらっしゃいませ。この商品ＡＡＡについてご希望の値段を希望価格入力欄に入力して下さい。」と表示し、これを音声出力する。
これに対して、ユーザ５は、ステップ６０５において購入の希望価格Ｚを入力する。そして、ステップ６０７においてＯＫすると、この希望価格Ｚがセンターに送信され、次のステップ６０９に進む。一方、ステップ６０７においてＯＫしない場合には本ルーチンを終了する。
センターは、ステップ６０９において、値引き交渉の目安値Ｅ（以下提示価格Ｅという）がユーザ５の希望する希望価格Ｚ以下か否かを判断する。ここで、提示価格Ｅ＝（Ｘ−（１−ｍ）Ｙ）／ｍであり、Ｘは定価、Ｙは底値、ｍは割引の度合いに対応する実数である。そして、底値Ｙは、製品を提供するベンダーによりいつでも自由に上下できる。
また、実数ｍは、製品を提供を管理する管理者により随時、変更可能である。さらに、実数ｍは、上述したステップ５４１やステップ５４３で加算累計した購入本数累計や購入価格累計（すなわちお客様の段階）に応じて変動させることも可能である。実数ｍをお客様の段階に応じて変動させる方法を説明する。本方法のフローチャートを図２７に示す。
図２７において、センターは、ステップ９０１において購入本数累計が５以上、又は購入価格の累計が５万円以上か否かを判断する。そして、購入本数累計が５以上、又は購入価格の累計が５万円以上である（ＹＥＳ）と判断された場合には、ステップ９０３において実数ｍを０．２上げる。これにより、例えばステップ６０９で判断される提示価格Ｅが低くされる。一方、購入本数累計が５未満、及び購入価格の累計が５万円未満である（ＮＯ）と判断された場合には、実数ｍを変動させることなく、次のステップ９０５に進む。
さらに、ステップ９０５において購入本数累計が１０以上、又は購入価格の累計が１０万円以上か否かを判断する。そして、購入本数累計が１０以上、又は購入価格の累計が１０万円以上である（ＹＥＳ）と判断された場合には、ステップ９０７において実数ｍをさらに０．２上げて、提示価格Ｅを低くする。一方、これ以外（ＮＯ）の場合には、実数ｍを変動させることなく、次のステップに進む。
これにより、購入本数累計や購入価格の累計のしきい値を上昇させつつ、上記ステップ９０１、９０３、…と同じ手順を行うことで、購入本数累計や購入価格の累計の大きいお得意様のユーザ５に対しては、その程度に応じて実数ｍを大きくして提示価格Ｅを低くすることができる。なお、実数ｍは、例えば最大値は４とする。
そして、図２６のステップ６０９で提示価格Ｅが希望価格Ｚ以下である（ＹＥＳ）と判断された場合には、センターは、ステップ６１１において希望価格Ｚ円で販売する旨を表示して、図２４のステップ５２９で値引き交渉が成立する。また、ステップ６０９で提示価格Ｅが希望価格Ｚを超えている（ＮＯ）と判断された場合でも、ステップ６１３において底値Ｙが希望価格Ｚ以下か否かを判断し、底値Ｙが希望価格Ｚ以下である（ＹＥＳ）と判断された場合には、ステップ６１１において希望価格Ｚ円で販売する旨を表示し、ステップ５２９で値引き交渉が成立する。
これに対し、ステップ６１３で底値Ｙが希望価格Ｚを超える（ＮＯ）と判断された場合には、ステップ６１５において提示価格Ｅ円で販売する旨の同意を求める。この提示価格Ｅは例えば１０円単位で四捨五入される。そして、提示価格Ｅ円での販売に同意する場合には、ステップ６１７において提示価格Ｅ円で販売する旨を表示して、ステップ５２９で値引き交渉が成立する。一方、提示価格Ｅ円での販売に不同意である場合には、ステップ７０１以降の危険を承知でチャレンジルーチンに進み、このルーチンを終えることで、ステップ５２９に進んで値引き交渉が成立する。
なお、ステップ６０９において、演算された提示価格Ｅが希望価格Ｚを超えていると判断された場合には、ステップ６１３の判断をせずに、直ちにステップ６１５で「提示価格Ｅ円でどうですか」の表示を行うようにしてもよい。
危険を承知でチャレンジルーチンについて説明する。危険を承知でチャレンジルーチンのフローチャートを図２８に示す。
図２８において、本ルーチンが始まると、ユーザ５は、ステップ７０１においてコースの選択を行う。この選択では、もう少し何とかコース、もう一声コース、もっとお願いコースの３コースの選択が可能である。
いずれのコースにおいても、以下の確率ルーチンにおいて所定のギャンブルを行うことで、これに成功すると（ある確率で成功する）、提示価格Ｅよりも販売価格を下げることができる。しかしながら、ギャンブルに失敗すると販売価格が提示価格Ｅよりも上がってしまう。また、各コースにより提示価格Ｅからの下げ幅が異なり、下げ幅の段階が大きいコースについては、ギャンブルに成功する確率を減らしている。
そのため、ステップ７０１で「もう少し何とかコース」を選択した場合には、センターは、ステップ７０５において「提示価格Ｅより１段階安くなる確率が３０％、提示価格Ｅより高くなってしまう確率が７０％、それでもトライしてみますか？」と表示を行う。また、ステップ７０１で「もう一声コース」を選択した場合には、「提示価格Ｅより２段階安くなる確率が２０％、提示価格Ｅより高くなってしまう確率が８０％、困難と思いますが、それでもトライしてみますか？」と表示を行う。さらに、ステップ７０１で「もっとお願いコース」を選択した場合には、「提示価格Ｅより３段階安くなる確率が１０％、提示価格Ｅより高くなってしまう確率が９０％、相当厳しいですが、それでもトライしてみますか？」と表示を行う。
その後、ステップ７１５においてチャレンジに同意した場合には、ステップ８０１以降においてギャンブルを行うべく確率ルーチンに進む。一方、ステップ７１５でチャレンジに不同意である場合には、図２６のステップ６１５に戻り、再度提示価格Ｅ円で販売する旨の同意を求める。
確率ルーチンについて説明する。確率ルーチンのフローチャートを図２９に示す。なお、図２９には確率ルーチンで行うギャンブルの一例として数字選びを示す。
図２９において、センターは、ステップ８０１で「いずれかの数字（例えば０〜９の１０個の数字とする）を入力し、送信してください。入力された数字がセンターで乱数発生させた数字と一致したら提示価格Ｅより安くします。一致しなかったら提示価格Ｅより高くなります、ごめんなさい。」と表示する。
そして、ユーザ５が数字を１つ入力し、これを送信すると、センターは、ステップ８０３において上記ステップ７０１で選択されたコースを認識し、ステップ８０５において各コースに基づき必要個数の乱数を発生する。
例えば、「もう少し何とかコース」であれば成功確率が３０％なので３個の乱数を発生し、「もう一声コース」であれば成功確率が２０％なので２個の乱数を発生し、「もっとお願いコース」であれば成功確率が１０％なので１個の乱数を発生する。
その結果、ステップ８０７において、「もう一声コース」であれば「センターで乱数発生させた数字は３、５で、ユーザ５が入力した数字は７です。」と表示した後、双方の数字の一致、不一致を判断して「Ｋ円で販売します。」と表示する。
このとき、上記の例では数字が不一致であるので提示価格Ｅより高い失敗価格Ｋが提示される。例えば、失敗価格Ｋ＝（Ｅ＋Ｘ）／２である。この失敗価格Ｋは例えば３コースとも同じとされる。但し、３コース毎に独自に設定されてもよい。
一方、数字が一致した場合には、ステップ８０７において提示価格Ｅより低い成功価格Ｌが提示される。例えば、成功価格Ｌ＝（（Ｅ−Ｙ）×（１−ｎ））＋Ｙである。このとき、ｎはコース別の割引段階を示す値であり、「もう少し何とかコース」であればｎ＝０．１、「もう一声コース」であればｎ＝０．２、「もっとお願いコース」であればｎ＝０．３とする。なお、ｎ＜１であり、ｎが大きくなると成功価格Ｌは下がる。また、ｎは適宜変更可能であり、お得意様の程度に応じて０．０２ずつ上げても良い。
そして、ステップ８０７で価格Ｋ、Ｌの提示を行うと、図２４のステップ５２９で値引き交渉が成立する。
以上により、前もって製品を必ず１つ購入してもらい、次の製品の購入から値引き交渉を行わせることが出来る。従って、ユーザの製品購入意欲を促進させることができる。また、このように、製品購入の程度に応じて値引き交渉を認めつつ同一のユーザが同一の製品を購入するに対しては、値引き交渉の可能回数を制限するようにしたため、不特定多数の者が無制限に値引き交渉する等による底値Ｙの安易な暴露を防止できる。さらに、複数本購入した者や多額の購入を行った者に対してはｍ値を上げて、提示価格Ｅを下げることが出来る。
なお、本実施形態では、確率ルーチンで行うギャンブルの一例として数字選びを示したが、これに限られず、スロットマシンやルーレット、トランプ等であっても良い。図３０にスロットマシンを用いたギャンブルの一例を示す。
図３０（ａ）において、センターからスロット８５１の画面が提供されると、ユーザ５がスタートレバー８５６をクリック等することで、３つのリール８５２、８５３、８５４が回転し始める。その後、ボタン８５７、８５８、８５９を順次押すことで、リール８５２、８５３、８５４の回転が停止する。このとき、ボタン８５７、８５８、８５９を押してからリール８５２、８５３、８５４の回転が停止するまでには時間を要することが望ましい。そして、この時間は、乱数発生などにより停止の都度異ならせ一定としないことが望ましい。各リール８５２、８５３、８５４には、例えば図３０（ｂ）に示すように、Ａ、Ｂ、Ｃの３種類の模様が３回連続して繰り返し設けられる。
そのため、３つの窓８６０、８６１、８６２のいずれかに同じ模様が並ぶ確率は、窓の数（３）×２つ目のリール８５３に１つ目のリール８５２と同じ模様が並ぶ確率（１／３）×３つ目のリール８５４に２つ目のリール８５３と同じ模様が並ぶ確率（１／３）＝３／９（約３３％）となる。そのため、この状態を上述した「もう少し何とかコース」とすれば、成功確率をおよそ３０％とできる。
一方、「もう一声コース」では、同じ模様を並べられる窓の数を２つとすることで、窓８６０、８６１に同じ模様がそろう確率を窓の数（２）×１／３×１／３＝２／９（約２２％）とでき、「もう一声コース」の成功確率をおよそ２０％とできる。さらに、「もっとお願いコース」では、同じ模様を並べられる窓の数を１つとすることで、確率を窓の数（１）×１／３×１／３＝１／９（約１１％）とでき、「もっとお願いコース」の成功確率をおよそ１０％とできる。
なお、各コースの成功確率を変更させる方法は、上記のように「窓の数」を変更させる場合だけでなく、各リール８５２、８５３、８５４に施す模様の種類を変更させても良い。この場合、「もう一声コース」で同じ模様を並べられる窓の数を３として各リール８５２、８５３、８５４にＡ、Ｂ、Ｃ、Ｄの４種類の模様を設けることで、同じ模様がそろう確率を窓の数（３）×１／４×１／４＝３／１６（約１９％）とできる。また、「もっとお願いコース」では、各リール８５２、８５３、８５４に６種類の模様を施すことで、確率を窓の数（３）×１／６×１／６＝３／３６（約８％）とできる。
また、本実施形態で示した方法は、第１実施形態で示した様々な値引き交渉態様と組み合わされて適用されてもよい。
次に、本発明の第３実施形態について説明する。第３実施形態である商品購入手順のフローチャートを図３１及び図３２に示す。第３実施形態では、例えば、ユーザ５が購入しようとする商品に対し、若しくは次回の商品購入の際に現金還元を行うことを可能としたものである。現金還元は、基本的には、すべてのユーザ５に対し一律に一定金額を還元しようとするものである。また、この現金還元を値引き交渉と組み合わせることで、値引き交渉の多様化を図ると共に、より利用されやすいシステムとするものである。ユーザ５は、現金還元か値引き交渉のいずれかを選択可能である。現金還元された仮想現金は各ユーザ毎にデータベース１００９上に設けられたユーザ貯金箱に入れられるようになっている。
センターのホームページ上には、商品仕様等と共にこの商品の標準価格Ｑ円が掲載されている。また、一般ユーザ向け（お得意様ではない状態）の現金還元額Ｒ円が掲載されている。但し、この現金還元額は、ユーザのお得意様状況如何により異なる。この現金還元額は、還元率として適用されてもよい。
図３１のステップ１００１において購入したい商品（プロダクトＩＤ）のページに進み、この商品の購入を決意したユーザ５はステップ１００３において商品の購入ボタンを押す。商品は、例えばソフトウエアである。しかしながら、各種商品の他、サービス等にも適用可能である。これにより当該商品を購入したい旨の情報がセンターに送信される。
ユーザ５は、ステップ１００５においてユーザＩＤを入力した後送信する。そして、センターにてこのユーザＩＤが確認される。ステップ１００７において、ユーザ５によるユーザＩＤ等の登録後初めての購入か否かが判断される。この判断は、センター側にてユーザＩＤの属する情報を判断することで自動的に行われる。登録後初めての購入の場合には、ステップ１００９において、現金還元か値引き交渉のいずれかを選択する。基本的には、登録後初めての購入の場合には、現金還元に進んでもらうことを原則とする。そして、この際には、現金還元と共に値引き交渉権を付与するものとする。また、現金還元の内、ユーザ５の判断により一定金額分を今回の購入分から値引き可能とする。但し、かかる一定金額分の今回の購入分からの値引きを行わないことも可能である。
値引き交渉が選択された場合には、ステップ１０１１に進み、登録後初めての購入の場合には値引き交渉は行えず、現金還元のみが行える旨の表示を行う。そして、ユーザ５には現金還元の行えるページに進んでもらう。ステップ１００９において、ユーザ５により現金還元が選択された場合にはステップ１０１３に進み、還元される仮想現金の内Ｄ円分を今回の商品に対し使うか、若しくはユーザ貯金箱に入れるかの問い合わせが行われる。Ｄ円は、例えば現金還元額Ｒ円の３割である。商品に対しＤ円分を今回使う旨の意思表示のあった場合には、ステップ１０１５で本製品の購入のためＣ円（＝Ｑ−Ｄ）を支払うように表示する。
また、残りの現金還元額Ｆ円（この場合、現金還元額Ｒ円の７割）はユーザ貯金箱に入れられる旨の表示がされる。一方、ステップ１０１３でＤ円分をユーザ貯金箱に入れる旨の選択がされた場合には、ステップ１０１５で本製品の購入のためＣ円（＝Ｑ−０＝Ｑ）を支払うように表示する。本ユーザは商品を初めて購入されたユーザであり、お得意様には相当しないので、ユーザ貯金箱には、Ｒ円が現金還元され、ユーザ貯金箱の残額はＲ円となる。
ステップ１０１７では、ユーザ５に対し、ユーザ５からの本支払いの入金があり、センター側でこの入金が確認された後には値引き交渉権が１回分（若しくはその金額に応じて複数回分）付与される旨の予告表示が行われる。ステップ１０１９で、上述の各データはセンターのデータベース１００９に一時保存され、ステップ１０２１で例えば２週間経過しても入金が確認されなかった場合には、ステップ１０２３で保存されていたデータを消去する。２週間経過しても入金のない状態は、ユーザ５が実質的に購入を止めたものと解されるためである。但し、この入金の確認は、銀行振込や郵便振替等のような場合に配慮され、キャッシュカード支払い等のように、即座にオンライン決済の可能な場合には直ちに確定処理が実施される。ステップ１０２５で２週間以内に入金の確認された場合には、ステップ１０２７でデータの確定指令が出され、ステップ１０２９で確定処理が実施される。これにより、ステップ１０３１でユーザ貯金箱に対しＰ円の入金が確定され、ステップ１０３３でユーザ貯金箱の残額にＰ円が加算される。ここに、Ｐ＝Ｆ（若しくは後述するＳ）である。そして、ステップ１０３５で値引き交渉可能回数も１回分（若しくはその金額に応じて複数回分）加算される。
次に、ステップ１００７の判断で、ユーザ５による購入が初めてでない場合について説明する。この場合には、図３２のステップ１０４１で現金還元か値引き交渉のいずれかを選択する。値引き交渉が選択された場合には、ステップ１０４３に進み値引き交渉処理が行われる。値引き交渉処理は、第１実施形態、第２実施形態で説明したいずれかのものであり、値引き交渉結果であるＢ円が表示されているものとする。そして、ステップ１０４５では、ユーザ５に対し、ユーザ貯金箱から仮想現金を引き出して今回の製品購入のために使うか否かの問い合わせが行われ、ユーザ貯金箱の残額が示される。ユーザ５がＹＥＳを選択した場合には、ステップ１０４７に進みユーザ貯金箱から本製品の購入のためＵ円が使われる旨の確認メッセージが表示される。そして、ステップ１０４９ではユーザ貯金箱から本製品の購入のためＵ円が使われたため、残額であるＷ円を指定期日迄に支払うように督促する旨の表示を出す。この際には、お支払い方法の確認も可能である。なお、ステップ１０４５でユーザ５がＮＯを選択した場合には、ステップ１０４９に進む。この場合には、ユーザ貯金箱からの出金は０円であり、ユーザ５はＢ円全額を支払うことになる。また、ユーザ貯金箱からの出金で当該商品の全額を賄えた場合には残額Ｗ円の支払い督促メッセージは表示しないものとする。
このように、値引き交渉結果で値引きがされた上に、更にユーザ貯金箱より仮想現金を引き出して当該製品を購入可能としたので、ユーザ５による本システムの利用の促進に繋がる。
一方、ステップ１０４１で現金還元が選択された場合には、ステップ１０５１に進み、ユーザ貯金箱からたまっている仮想金額を使うか否かの問い合わせが行われる。使う旨の意思表示（ＹＥＳ）がされた場合には、ステップ１０５３でユーザ貯金箱から本製品の購入のためＴ円（Ｔ≦Ｑ）が使われる旨の確認メッセージが表示される。そして、ステップ１０５５ではユーザ貯金箱から本製品の購入のためＴ円が使われたため、残額であるＶ円（＝Ｑ−Ｔ）を指定期日迄に支払うように督促する旨の表示を出す。この際には、ユーザ５は支払い方法を確認することも可能である。また、入金確認後には、ユーザ５に対し、どの程度の現金還元が行われるのか予告表示する。この際の現金還元額はお得意様ランクに応じて異ならせられる。お得意様ランクは、購入金額の合計や購入頻度等に応じて例えばＡ〜Ｅまでの５段階とし、この各段階に応じたお得意様段階率（例えば数パーセント程度）を定義し、現金還元額Ｓ円を算出する。現金還元額Ｓの算出方法は、例えばＳ＝Ｒ＋お得意様段階率×（Ｑ−Ｒ）である。
なお、ステップ１０５１でユーザ５がＮＯを選択した場合には、ステップ１０５５に進む。この場合には、ユーザ貯金箱からの出金は０円であり、ユーザ５はＱ円全額を所定の支払い方法に従い支払うことになる。また、ユーザ貯金箱からの出金で当該商品の全額を賄えた場合には残額Ｖ円の支払い督促メッセージは表示しないものとする。
これらのデータはステップ１０１９に進み一時保存され、ステップ１０２１で例えば２週間経過しても入金が確認されなかった場合には、ステップ１０２３で保存されたデータは消去される。但し、仮想現金で賄われている場合には消去はされない。ステップ１０２９で確定処理が実施された場合には、ステップ１０３１でユーザ貯金箱に対しＰ円の入金が確定され、ステップ１０３３でユーザ貯金箱の残額にＰ円が加算される。ここに、Ｐ＝Ｓである。なお、この場合には、ステップ１０３５は省略され、値引き交渉可能回数は加算されない。但し、値引き交渉可能回数が加算されるようにしてもよい。
以上により、値引き交渉を好まないユーザ５は現金還元を選択できるので、一層利用されやすいシステムにできる。また、現金還元の額が分かることで、値引き交渉額の底値を推定するヒントの一つを自然の形に提供でき、値引き交渉の利用促進にも繋げることができる。
なお、付与された値引き交渉回数や現金還元額は、付与の日から所定期日経過後にキャンセルされるものとする（フローチャートは省略する）。このことにより、ユーザ５による積極的な購入意欲を促すことができる。
また、ステップ１０４１で現金還元が選択された場合にも、一定金額分を今回の購入分から直接減額可能とされてもよい。この際には、例えば、現金還元総額Ｔ円に対して直接減額分限度額Ｕ円を貸し店舗である商店等７若しくはＷＷＷサーバ３のサイトの運営者が設定する。直接減額分限度額は、現金還元として直接減額の可能な最大の限度額である。商店等７が設定する場合には、この設定はＷＷＷサーバ３のサイトに対してオンライン接続された状態で行われるのが望ましい。設定されたデータは、データベースに保存され、このデータを基にホームページのデータが更新されてユーザ５に対して表示される。そして、この直接減額分限度額Ｕ円の範囲内で、ユーザ５は直接減額の希望額Ｖ円を図示しない直接減額分金額入力欄に入力可能である。このとき、ユーザ貯金箱にはＴ−Ｖ円が貯金される。但し、直接減額分限度額Ｔ若しくはユーザ貯金箱へＴ−Ｖのいずれかが０円のときには、この０円となる項目についてＷｅｂ画面表示はしないことが望ましい。
このように、商店等７側では、直接減額分とユーザ貯金箱への入金額とを自由に設定できる。この設定は商店等７により底値やｍ値等と共に随時変更可能である。
なお、本実施形態で示した方法は、第１実施形態で示した様々な値引き交渉態様と組み合わされて適用可能である。また、現金還元ではなくポイント制であっても同様に適用可能である。
次に、値引き交渉では現金還元によるよりも必ず安く購入される方法について説明する。ホームページ上に表示されている現金還元額よりも値引き交渉で安くなることを期待するユーザ５に配慮するためである。表示された現金還元額をＣ円とすると、現金還元後の価格Ｐ円は数７のように表される。
（数７）
希望販売価格Ｘ−現金還元額Ｃ＝現金還元後価格Ｐ
ここに、現金還元後価格Ｐ円は数８の条件でないとデータベースに入力できないものとする。
（数８）
現金還元後価格Ｐ≧底値Ｙ
一方、中間提示価格Ｅ円の計算は、図１６のステップ９１、ステップ１０９、ステップ１２３において、希望販売価格Ｘと底値Ｙの間で
中間提示価格Ｅ＝（Ｘ−（１−ｍ）Ｙ）／ｍ円
とされているが、数９のように、この希望販売価格Ｘに代えて現金還元後価格Ｐを代入して計算する。即ち、中間提示価格Ｅ円を現金還元後価格Ｐと底値Ｙの間に設定する。
（数９）
中間提示価格Ｅ＝（Ｐ−（１−ｍ）Ｙ）／ｍ円
また、現金還元後価格Ｐ円がユーザ５により入力された金額より小さいとき、ポップアップ画面で、「現金還元によるよりも高い購入金額が入力されています。このままでよいですか？」とユーザ５に対し尋ね、ユーザ５に対し「このままでよい」若しくは「入力金額を見直す」のいずれかを選択させる。そして、ユーザ５が「このままでよい」を選択すればこのまま処理を継続する。一方、「入力金額を見直す」が選択された際には、ユーザ５に対しユーザ希望購入価格欄９１に希望購入価格を再度入力させる。
次に、本発明の第４実施形態について説明する。本発明の第４実施形態のフローチャートを図３３に示す。本発明の第４実施形態では、複数購入商品について値引き交渉を行う場合である。例えば、ａ、ｂ、ｃ、ｄ（価格はそれぞれａ円、ｂ円、ｃ円、ｄ円であって、額の大きさの順はａ円＞ｂ円＞ｃ円＞ｄ円である）の商品があったとする。そして、この内、ａとｂとは値引き処理等対象商品であり、ｃとｄとは値引き処理等対象外の通常の商品であると仮定する。値引き処理等対象商品は、例えば値引き交渉によるものであったり、現金還元によるものである。値引き処理等対象外の通常の商品は、値引き交渉や現金還元処理の行われないものであり、例えば標準価格販売、当店販売価格、標準価格より一定価格値下げされた価格が提示されて販売されるような場合等である。
基本方針として、１個だけ価格が突出しているパターンであって、しかも残りの合計額が小額のときにはこの１個について予め定められた値下げ方法が取られる以外に、残りの商品等については値下げ処理はしないこととする。これは、全体としてみて当該１個の商品について値引き等の処理が行えれば充分と考えられるからである。また、値引き処理等対象商品と値引き処理等対象外の通常の商品とで区別した処理を行うものとする。値引き処理等対象商品における実数ｍ値やそれぞれの底値等を配慮した形で、複数商品購入されたときのまとめた値引きが行えるようにする一方で、値引き処理等対象外の商品についてもまとまった金額の大きさに応じて何らかの値下げをしようとするためである。
即ち、購入総額Ｔ円（＝ａ＋ｂ＋ｃ＋ｄ）が大きければ、値引き処理等対象外の商品に対してある値下げ率の値引きを行う。なお、この値下げ率はテーブル表から読み取る。通常販売では値引き処理等対象外の商品に対して、標準価格販売であって値下げは行われていないか若しくは大きな額の値下げはされていないが、購入総額が大きいときにある率の値下げをするので顧客にとってはお買い得感がでる。更に、値引き処理等対象商品（同一、異種を問わない）が複数購入され、かつ金額が相当以上のときにはｍ値と底値Ｙを下げることとする。
図３３において、ステップ１１００では、個別に値引き交渉や現金還元が行われていないことを確認し、個別に値引き交渉や現金還元が行われた商品等については以降の処理を行わない。既に個別に値引き交渉等の行われている場合には、重ねて値引きに応ずる必要はないからである。ステップ１１０１では、購入された複数の商品の中から一番最大の価格Ｃｍａｘ（例えばａ円）を抽出する。そして、ステップ１１０３では、購入総額からこの最大の価格Ｃｍａｘを引いた残額が購入総額に対してどの程度の割合か否かを判断する。割合α未満のときにはステップ１１０５に進み、まとめての値引きは行わない。この割合αは例えば０．２である。即ち、各商品単位で予め決められた仕様に基づく処理のみが許可される。例えば、それぞれ個別に商品ａとｂについては値引き交渉や現金還元が可能であり、一方、ｃとｄについては通常の販売価格での販売がされる。残額が少ない割合のときにまで一層の値下げをする必要がないからである。また、各個別に認められた値引き等が行われるだけで充分だからである。
次にステップ１１０７では、購入総額Ｔ円から最大の価格Ｃｍａｘを引いた残額がβ円以上か否かを判断する。このβ円は例えば２０００円である。β円未満のときにはステップ１１０５に進み、まとめての値引きは行わない。残額が少ないときにまで一層の値下げをする必要がないからである。
次に、複数商品購入された場合に、値引き処理や現金還元について更に優遇するための処理をステップ１１０９〜ステップ１１２１で行う。
まず、ステップ１１０９で購入された複数の商品の中から値引き処理等対象商品（例えばａとｂ）を抽出する。ステップ１１１１で、同一製品か異種製品かを問わず、複数個購入の場合には、ステップ１１１３に進み、抽出した値引き処理等対象商品の中から一番最大の価格Ｐｍａｘ（例えばａ円）を抽出する。一方、ステップ１１１１で値引き処理等対象商品が一つの場合にはステップ１１１２で値下げ率θ１、θ２を０にする。値下げ率θ１、θ２は、複数個購入のされた場合にｍ値や底値Ｙを更に一層下げようとするための率である。このことにより、ユーザ５はまとめ買いにより更に安い価格で購入できる可能性が増す。
その後、ステップ１１１５で値引き処理等対象商品の総額Ｒ円（＝ａ＋ｂ）からこの最大の価格Ｐｍａｘを引いた残額が総額Ｒ円に対してどの程度の割合か否かを判断する。なお、ａとｂとは同一の商品であってもよい。また、Ｐｍａｘは１商品についての値である。そして、残額が総額Ｒ円に対して割合γ未満のときにはステップ１１１２に進み、値下げ率θ１、θ２を０にする。この割合γは例えば０．２である。残額が少ない割合のときにまで一層の値下げをする必要がないからである。また、各個別に認められた値引き等が行われるだけで充分だからである。
次に、ステップ１１１７では、購入総額Ｒ円から最大の価格Ｐｍａｘを引いた残額がδ円以上か否かを判断する。このδ円は例えば２０００円である。δ円未満のときにはステップ１１１２に進み、値下げ率θ１、θ２を０にする。残額が少ないときにまで一層の値下げをする必要がないからである。
残額がδ円以上のときにはステップ１１１９に進み、総額−率テーブル表より総額Ｒ円を基にｍ値及び底値ｙの値下げ率θ１、θ２を抽出する。総額Ｒ円を基として、後述する全体の商品の購入である購入総額Ｔ円（＝ａ＋ｂ＋ｃ＋ｄ）を基にしていないのは、ｍ値及び底値ｙが、値引き処理等対象外の商品価格の影響により変動されるのは不合理と考えられるからである。また、購入総額Ｔ円を基にして、後述のステップ１１２９〜ステップ１１３７で値引き対象外の商品について値段が下げられるので、このことだけでユーザにとっては既に充分であり、購入総額Ｔ円を基に更にｍ値及び底値ｙを下げるのは行き過ぎと考えられるからである。
総額−率テーブル表では、購入総額Ｒ円に対するｍ値及び底値ｙの値下げ率θ１、θ２が規定されており、購入総額Ｒ円が大きいときにはｍ値及び底値ｙの値下げ率θ１、θ２も大きくなるように設定されている。但し、購入総額Ｔ円を基に総額−率テーブル表の設定及び抽出処理がされるようにすることも可能である。なお、現金還元の場合には、総額−率テーブル表に購入総額Ｒ円に対する更に還元され得る現金還元額若しくは還元率が設定されることになる。そして、ステップ１１２１では、ｍ（１＋θ１）、ｙ（１−θ２）を演算する。なお、ここで演算されたｍ（１＋θ１）、ｙ（１−θ２）は、ステップ１１３９で使用される。
次のステップ１１２７以降の処理では、まとめて相当額を購入してくれたユーザ５に対しては、値引き処理等対象外の商品についても値下げをしようとするものである。ステップ１１２７において、購入された複数の商品の中から値引き対象外の商品（例えばｃとｄ）を抽出する。そして、ステップ１１２９で同一製品か異種製品かを問わず、値引き対象外の商品を１個以上購入したか否かが判断される。１個以上購入の場合には、ステップ１１３１に進み、購入総額Ｔ円（＝ａ＋ｂ＋ｃ＋ｄ）を算出し、購入総額Ｔ円がε円（＝例えば６０００円）を超えているか否か判断される。このときの購入総額Ｔ円は、値引き処理等対象商品と値引き処理等対象外の商品の両方の総額である。ステップ１１２９で値引き処理等対象外の商品を一つも購入されていないと判断されたとき、及びステップ１１３１で購入総額Ｔ円がε円未満のときには、ステップ１１３３で値下げ率λが０に設定される。ステップ１１２７以降の処理は、値引き対象外の商品が存在する場合に、購入総額如何では、この値引き対象外の商品についても値下げを実施しようとするものであり、値引き対象外の商品が存在しない場合には、ステップ１１２９以降の処理により値下げをする必要はない。また購入総額Ｔ円が少ない場合まで値下げをする必要もないからである。
ステップ１１３１で購入総額Ｔ円がε円（＝例えば６０００円）を超えている場合には、ステップ１１３３に進み、総額Ｔ円−率テーブル表より総額Ｔ円を基に値下げ率λを抽出する。総額Ｔ円−率テーブル表では、購入総額Ｔ円に対する値引き対象外の商品の値下げ率λが規定されており、購入総額Ｔ円が大きいときには値下げ率λも大きくなるように設定されている。値下げ率λは、ｍ値及び底値ｙの値下げ率θ１、θ２とは同一としないことが目的、処理する価格の相違及び自由度の点から望ましいため、区別して扱っている。しかしながら、共通とし、総額Ｔ円を基に値下げ率λ、θ１、θ２を決めるようにしてもよい。
ステップ１１３５では、値引き対象外の商品の総額Γ円（＝ｃ＋ｄ）を算出する。そして、ステップ１１３７では、この総額Γ円に対する値下げ後の金額Γ （１−λ）が演算される。
ステップ１１３９では、ステップ１１２１で求めたｍ値をｍ（１＋θ１）、底値をｙ（１−θ２）として総額Ｒ円に対して値引き交渉を実施する。値引き交渉の基本処理方法は、図１６のフローチャートの通りであるが、このとき、図１６のフローチャート中の標準価格Ｘ円は各商品ａ、ｂの標準価格の合計、即ち購入総額Ｒ円と読み変えられる。同様に、底値Ｙ円は、各商品ａ、ｂの底値の合計として適用される。ユーザ５に対しては商品ａ、ｂ、ｃ、ｄに対する購入総額Ｔ円が標準価格Ｘ円の代わりに表示される。これに対して、ユーザ５は、希望購入価格欄９１に希望購入価格Ｚ円を入力するが、この希望購入価格Ｚ円は、商品ａ、ｂ、ｃ、ｄに対する購入総額Ｔ円に対するものである。一方、値引き処理等対象外の商品の総額Γ円（＝ｃ＋ｄ）を算出し、希望購入価格Ｚ円から減算して値引き処理等対象部分希望購入価格ｚ１（＝Ｚ円−Γ円）を求める。
そして、値引き交渉の目安値である（Ｘ−（１−ｍ）Ｙ）／ｍ円が求められると、図１６におけるステップ８５、ステップ１０３、ステップ１１７の比較では、この目安値と値引き処理等対象部分希望購入価格ｚ１とが対比されることとなる。そして、図３３のステップ１１４１では、値引き結果と金額Γ（１−λ）とが合計される。具体的には、図１６のステップ９１、ステップ１０９、ステップ１２３では、値引き交渉の目安値に代えて、この目安値と金額Γ（１−λ）が足し算され、この足し算結果が表示される。一方、ステップ８５等の比較で、目安値が値引き処理等対象部分希望購入価格ｚ１以下のときには「希望購入価格Ｚ円で販売します」と表示する。
但し、ユーザ５に対しては値引き処理等対象商品についての購入総額Ｒ円に対して値引き交渉させ、ここで定まった目安値と金額Γ（１−λ）若しくは値引き交渉の結果の額と金額Γ（１−λ）がそれぞれ足し算され、この足し算結果が表示されるようにしてもよい。
なお、現金還元の場合、総額−率テーブル表には購入総額Ｒ円に対する更に還元され得る現金還元額（若しくは還元率）を設定しておく。そして、この総額−率テーブル表を基に購入総額Ｒ円に対する更に還元され得る現金還元額（若しくは還元率）が演算され、この結果から算出された還元後の最終値段と金額Γ（１−λ）とが合計される。但し、値引き交渉によるものと、現金還元によるものとそれぞれグループに分けた上で上記処理を行い、その結果を加算するようにしてもよい。この場合、購入総額Ｒ円や購入総額Ｔ円に代えて各グループ毎の購入総額を基に処理されてもよい。更に、グループ分けは、値引き交渉によるものと、現金還元によるものと、値引き処理等対象外の商品とをそれぞれグループに分けたものとされてもよい。
また、値引き処理等対象商品について総額−率テーブル表で、ｍ値及び底値ｙについて値下げ率を設定し演算するとして説明したが、この処理を行わずに総額−率テーブル表には最終的な最終値引き率ηを設定しておき、値引き交渉の結果の額Ｒ１に対してこの最終値引き率η分を値下げ（Ｒ１×（１−η））してユーザ５に対して販売するようにしてもよい。但し、ｍ値及び底値ｙについて値下げ率（θ１、θ２）を設定し、更にこの最終値引き率ηを併せて設けるようにしてもよい。そして、まとめて値引きをしたことによる優遇分を明確にするため、実際のまとめて値引きをした額の部分とは区別して表示するようにしてもよい。具体的にはＲ１＋Γと優遇分であるηＲ１＋λΓを区別して表示した上で、実際のユーザ５の支払額であるＲ１＋Γ−（ηＲ１＋λΓ）をも併せて表示する。更に、値引き前の金額であるＲ＋Γをも表示するようにしてもよい。このことにより、ユーザ５は商品等をまとめて購入したことによるメリットを金額により具体的に実感できる。
以上により、値引き処理等対象商品と値引き処理等対象外の商品とが混在している場合であっても、複数購入商品についてまとめて値引き交渉を行うことが可能である。商品は野菜や衣類等の各グループ分けされた形で、各グループ単位にまとめて値引き交渉が行われるようにしてもよい。値引き処理等対象商品だけを複数本購入する場合であっても、また値引き処理等対象外の商品だけを複数本購入する場合に対しても適用可能である。値引き処理等対象商品と値引き処理等対象外の商品のいずれであっても、同一の商品を複数購入する場合に対して適用可能である。
複数購入商品についてまとめて値引き交渉を行うに際しては、各商店等７単位に行われてもよいが、各商店等７にまたがって複数の商品が購入され、一度に値引き交渉を可能としてもよい。次に、貸し店舗形式で販売が行われる場合、複数の商店等で提供する商品等が混在してもまとめて値引き交渉を可能とする方法について説明する。ステップ１１３９の処理において、値引き処理等対象商品について希望販売価格の合計金額Ｒ円と底値の合計ＡＹとを算出する。その後値引き交渉により、複数商品をまとめての決定価格が決まるので、まず数１を基に率Ｓを算出する。
（数１）
Ｓ＝（まとめての決定価格−底値の合計ＡＹ）／（希望販売価格の合計金額Ｒ−底値の合計ＡＹ）
次に、この算出した率Ｓを基に各商品の決定価格を算出する。この各商品の決定価格は希望販売価格をＸ、底値をＹとして数２のように算出できる。
（数２）
各商品の決定価格＝（希望販売価格Ｘ−底値Ｙ）＊Ｓ＋底値Ｙ
以上により、複数の商店等で提供する商品等が混在している場合にまとめての値引き交渉をした場合であっても、各商品毎に決定価格を算出できる。
なお、値下げ率λ、最終値引き率ηは、各商店等７とＷＷＷサーバ３のサイトとで独自に設定されてもよい。現金還元額（若しくは還元率）についても同様である。
このように、ネットショップにおける買い物かごに複数の商店等で提供する商品等を同時に入れ、複数の商店等にまたがったまとめての購入及び値引き交渉が可能である。値引き交渉による決定価格、現金還元額、まとめての値下げ額は各商品毎に分けられる。このため、まとめて購入された場合であっても売上は各店舗毎に表示可能となる。このことにより、クレジットカード決済の場合にカード情報の入力は各店舗にまたがって１回ですむ。各商品についての送付先の入力もまとめて１回ですむ。入力されたこれらの情報や決済情報は各店舗毎にまとめられる。そして、各商店等７に対して閲覧可能な情報として提供される。各商店等７はログインＩＤとパスワードでサイトに入りこの情報を閲覧する。
次に、同じ値引き処理等対象商品であっても、その中にまとめて購入することにより更に値引き可能なものと、まとめて購入されたとしても更なる値引きは行わないものとが混在した場合について説明する。まとめて購入する場合に更なる値引きが可能か否かは商品毎に表示され、この表示は値引き交渉や現金還元が可能か否かの表示とは別に表示される。
例えばＡ商店のａ商品（希望販売価格ａ円、底値をｙａとする）及びＣ商店のｃ商品（希望販売価格ｃ円、底値をｙｃとする）についてはまとめたときの更なる値引きが可能とし、Ｂ商店のｂ商品（希望販売価格ｂ円、底値をｙｂとする）についてはまとめたときの更なる値引きはできないものとする。
このとき、総額Ｒ円を算出するに際しては、まとめたときの更なる値引きが可能なものだけ（この場合にはＡ商店のａ商品とＣ商店のｃ商品について）を合計する。そして、この総額Ｒ円を基にステップ１１１９でθ１、θ２を求める。まとめたときの底値の合計ＡＹは、
（数３）
底値の合計ＡＹ＝ｙａ（１−θ２）＋ｙｂ＋ｙｃ（１−θ２）＝（ｙａ＋ｙｃ）（１−θ２）＋ｙｂ
即ち、値引き処理等対象商品の内、まとめたときに更なる値引きが可能なものだけについて底値を合計し、これらについてのみ底値を下げた形で合計をとる。一方、実数ｍ値については、ｍ（１＋θ１×ｇ／ｈ）とする。ここに、ｈは値引き処理が可能な商品の総数であり、ｇはこの総数の内でまとめたときの更なる値引きが可能なものの数である。このようにθ１を減じるのは、まとめての値引き交渉の際には、更なる値引きは行わないものも含めた形で全体として一括して値引き交渉が行われるからである。
このように算出したｍ値と底値に基づきステップ１１３９で値引き交渉を実施する。そして、値引き交渉の決定価格が出たら、この決定価格を基に数１の率Ｓを求める。
その後、この率Ｓが算出されたら、先述の数２に基づき各商品の決定価格を算出する。このときに用いられる底値Ｙはａ商品についてはｙａ（１−θ２）、ｂ商品についてはｙｂ、ｃ商品についてはｙｃ（１−θ２）である。
現金還元の場合もほぼ同様であり、総額Ｒ円を算出するに際しては、現金還元額についてまとめたときの更なる値引きが可能なものだけ（例えばＡ商店のａ商品とＣ商店のｃ商品について）を合計する。そして、この算出した総額Ｒ円について、更に還元される現金還元額（若しくは還元率δ）を総額−率テーブル表より求める。各商品の最終価格を算出するに際しては、更なる値引きが可能な商品について、この商品の現金還元額に対して算出された還元率δ分を加味（各商品の現金還元額×（１＋δ））すればよい。
総額−率テーブル表より求められたのが率ではなく、金額の場合には、まず総額Ｒ円についてこの金額が相当する全体の還元率を算出する。その後、同様にこの還元率分をそれぞれの商品の現金還元額に対して加味すればよい。
値引き処理等対象外の商品については、ステップ１１３３で算出された値下げ率λを各商品毎に適用すれば各商品毎の最終価格が算出可能である。
なお、ユーザ５に対して価格表示するに際しては、まとめて購入したときの効果である減額分を独立して表示することが望ましい。
以上により、ユーザ５が複数の商店等７から複数の商品やサービスを購入したとしても販売処理が可能であると共に、同じ値引き処理等対象商品の中にまとめて購入することにより更に値引き可能なものと、まとめて購入されたとしても更なる値引きは行わないものとが混在した場合であっても、販売及び値引き交渉や現金還元処理が可能となる。
この場合であっても、販売結果の報告は各商店等７単位に行うことが可能となる。
次に、本発明の第５実施形態について説明する。本発明の第５実施形態の構成図を図３４に示す。本発明の第５実施形態は、お店の中で商品等をチェックして気に入った商品等を購入したり、チラシや雑誌をチェックして商品等を購入する際に、値引き交渉や現金還元がその場で簡単にできるようにしたものである。
図３４において、お店の中に置かれた商品１００１にはその製品にバーコード１００３が付されている。バーコード１００３は１次元、２次元等のものや、ＩＣタグ等その種類を問わない。コードには暗号化されたものや暗号化されていないものも含む。お店で商品等や価格を確認したユーザ５が、この商品等を購入したい場合には、携帯電話１００５にてこのバーコード１００３を撮像して読み取る。若しくはＩＣタグからその情報を電磁的に読み取らせるようにしてもよい。但し、携帯電話１００５を持たないユーザ５を考慮して携帯電話１００５に代えて、店にインターネット接続可能な専用装置１００６や移動情報端末を配備するようにしてもよい。この専用装置１００６では、移動可能として、バーコード１００３を読み取り、情報を解析できるものとしてもよいし、バーコード１００３の読み取りを要さず、当該商品専用として備付けられるようにしてもよい。
当該商品専用として備付けられる場合には、予めこの専用装置１００６内に必要な情報（商品専用のＵＲＬや商品情報、価格等）が設定されている。若しくは常時、当該商品の購入ページが画面に開かれていてもよい。また、バーコード１００３に代えて、商品等に付されたＩＣタグに対し専用装置１００６から無線にて電力送信を行うと共にＩＣタグより受信した受信データを読み込むようにしてもよい。このようにすれば、バーコード１００３を撮像して読み取る等の作業は不要となる。
なお、チラシ１００７（若しくは雑誌等）の場合には、その商品情報や価格等と共に当該商品のバーコードが印刷されていたりＩＣタグ等が付されている。携帯電話１００５（若しくは専用装置１００６）で読み込まれ解析されたデータに基づきセンターサーバ１００８にインターネットを介して接続されて当該商品等のＷｅｂページが直接開かれるようになっている。そして、センターサーバ１００８において、ユーザ５は、この商品について値引き交渉や現金還元ができるようになっている。
データベース１００９には製品情報が予め保存されている他、ユーザ５により購入された情報が、このデータベース１００９に保存されるようになっている。センターサーバ１００８は、複数のレジ１１１１に接続されている。そして、このレジ１１１１には、商品に付されたバーコード１００３を読み取るためのリーダー１１１３と、情報を表示可能な表示器１１１５とが備えられている。
図３５のフローチャートを基に本実施形態の動作を説明する。
図３５において、ステップ１２０１では、ユーザ５が購入したい商品又はサービスに関するバーコード１００３を携帯電話１００５（若しくは専用装置１００６）で読み取る。そして、ステップ１２０３で、このバーコード１００３に記録された情報から製品名、品番、ＵＲＬを解析する。但し、これらの情報は、バーコード１００３によらず、記載された情報を基に手入力されるようにしてもよい。例えば、センターサーバ１００８のホームページに手動操作で進み、このホームページより品番等を入力することでもよい。あるいは、専用装置１００６が、当該商品専用として備え付けられている場合には、予めこの専用装置１００６内に必要な情報を設定しておくようにしてもよい。ステップ１２０５では、解析されたＵＲＬを基にサイトの当該商品又はサービスのＷｅｂページが開かれる。ステップ１２０７では、ユーザ５はＷｅｂページ上で商品情報等を確認したり標準価格（若しくは当店販売価格）等を確認する。但し、店頭にて既に掲載されていたり、特に必要なものがなければ、これらの情報は省略されてもよい。
商品等を購入したい場合には、ユーザ５は、ステップ１２０９でＷｅｂページ上でユーザＩＤを入力し、ステップ１２１１でパスワードを入力する。そして、ステップ１２１３で、値引き交渉や現金還元を実行する。値引き交渉等は、本発明の第４実施形態で説明した複数個購入してまとめて値引き交渉等が行われるものであってもよい。ステップ１２１５では、この値引き交渉結果が表示される。但し、値引き交渉を行わずに購入だけの処理とされてもよい。この場合には、ステップ１２１３及びステップ１２１５の処理は省略できる。ステップ１２１７で、Ｗｅｂページ上に表示された購入ボタンをクリックすると、ステップ１２１９でデータベース１００９にこの購入のデータが蓄積される。なお、電子決裁によりこの時点で銀行口座等より支払いが完了されるようにしてもよいし、この時点では、支払い未了のまま、レジ１１１１にて現金支払いやカード支払いがされるようにしてもよい。ステップ１２２１では、他に購入したい商品等が存在する場合には、ステップ１２０１から繰り返す。但し、この際には、ステップ１２０９のユーザＩＤの入力及びステップ１２１１のパスワードの入力は省略される。
終了する場合には、当該商品をレジ１１１１に持参する。但し、商品自体を持参しなくても商品情報あるいは値段等の記載された商品カードやＩＣタグ等を持参するようにしてもよい。また、この段階で決済の済んでいる場合には、以降の処理を行わずに商品渡しや商品発送を行い処理が終了されるようにしてもよい。なお、商品の中には値引き交渉等がされない商品が混在されていてもよい。ステップ１２２３では、レジ１１１１にてレジ係によりユーザ５のユーザＩＤ等が確認され、ステップ１２２５でレジ１１１１にて各商品又はサービスに附帯されたバーコード１００３がリーダー１１１３により読み取られる。サービスの場合には、情報の記録されたカード等によってもよい。ＩＣタグに対し無線にて電力送信を行うと共にＩＣタグより受信した受信データを読み込むようにしてもよい。このようにすれば、レジ係が各商品をリーダー１１１３で読み込む等の作業は不要となる。ステップ１２２７で読み取られた情報から製品名、品番が解析される。ステップ１２２９では、この製品名、品番を基にデータベース１００９より一致する保存されていたデータが抽出される。なお、製品名の他、品番まで記載されていれば、これらの情報からユーザ５が購入する製品は特定されるので、ステップ１２２３でのレジ係によるユーザ５のユーザＩＤ等の確認は不要とすることもできる。
ステップ１２３１では、データベース１００９より抽出された製品名、金額等がその都度表示器１１１５に表示され、確認される。この際、既に支払い済決裁のされた製品については、その旨のメッセージも表示される。値引き交渉等のされない通常の商品についてもステップ１２３３でレジ１１１１にて集計がされる。ステップ１２３５では、レジ１１１１に合計金額を表示し、ステップ１２３７で支払い未納分が有れば、ステップ１２３９に進み現金若しくはカード等による支払いが行われる。その後、ステップ１２４１で支払いが完了すれば、ステップ１２４３でレシートが発行される。なお、ステップ１２３７で既に値引き交渉等のＷｅｂ上で電子決裁がされ、支払い済の場合には、ステップ１２４３に進みレシートのみが発行される。
このことにより、商品購入に際して内気な人であっても気軽に値引き交渉ができ、買い物を楽しむことができる。高額な商品以外であっても値引き交渉が可能であり、交渉のために店員が対応する等の手間も無くなる。この際には、まとめて値引き交渉等もできる。商品を直接目で見て確認した上で購入できるのでユーザは安心である。ＩＣタグを採用することでレジでの作業が簡単になる。
なお、本実施形態では、本人確認をユーザＩＤにより行うとして説明したが、カードで本人確認するようにしてもよい。この場合、購入に際してカード番号を入力し、更にレジ１１１１にてカード情報を読み取ることで本人かどうかをチェックする。また、携帯電話１００５に内蔵されたＩＣタグと、このＩＣタグより電磁的に情報を読み取る読み取り回路をレジ１１１１に備えてもよい。移動情報端末でｃｏｏｋｉｅ情報を利用、分析した形で本人確認するようにしてもよい。携帯電話１００５（若しくは専用装置１００６）において指紋等のバイオメトリクス情報を取得可能とし、この情報を基に本人確認がされ、その結果本人と判定されたときに以降のステップに進むようにしてもよい。そして、レジ１１１１にても照合可能とする。あるいは、適宜買い物の都度、センターサーバ１００８にて顧客番号を発行し、レジにてこの顧客番号を確認するようにしてもよい。
チラシ１００７（若しくは雑誌）をチェックして商品等を購入するに際しては、ステップ１２０１でこのチラシや雑誌に印刷されたバーコード１００３を携帯電話１００５で読み取り、解析されたＵＲＬを基に当該商店のＷｅｂページに進む。そして、少なくとも一つの商品等について値引き交渉や現金還元を行った後、ユーザ５はこの商店におもむく。値引き交渉等の結果はデータベース１００９に保存される。
ステップ１２２３でレジ係によりユーザ５のユーザＩＤ等が確認されることで、ステップ１２２９でデータベース１００９よりこのユーザＩＤに一致する保存されていたデータが抽出される（この場合、ステップ１２２５、ステップ１２２７は省略する）。そして、レジ１１１１にて商品が渡され、支払いがされる。但し、ユーザ５がこの商店におもむかなくても配送可能とされてもよい。この際、電子決裁済であれば、商品の配送のみですむ。着払いであれば、製品名、金額、購入日、配送先等を記載した伝票を添付する。
次に、本発明の第６実施形態について説明する。本発明の第６実施形態は第５実施形態の別態様である。図３６のフローチャートを基に動作を説明する。図３５では、お店の店内やチラシ等をチェックして商品等を購入する場合について説明したが、図３６では、お店以外で商品等を見つけて同じ商品等が欲しくなり、購入を希望したような場合である。例えば、他人が所有していた商品等と同じ物が欲しい場合等である。なお、図３５と同一要素のものについては同一符号を付して説明は省略する。
図３６において、ステップ１２０１では、欲しい商品等に付されているバーコード１００３を携帯電話１００５で読み取る。ステップ１２０３で、このバーコード１００３に記録された情報から製品名、サイトのＵＲＬを解析する。但し、この情報の中に販売店名が記録されていてもよい。ＵＲＬを基にステップ１３０１ではサイトのＷｅｂページが開かれる。そして、ステップ１３０３では、製品名を基にデータベース１００９より当該商品を扱う商店等のリストを表示する。ステップ１３０５では、このリストの中からユーザ５により選択された一つの商店の当該製品ページが表示される。そして、ユーザ５が購入を希望する場合には、値引き交渉等を行い、購入をする。ステップ１３０７では、ユーザ５は、この選択された商店に出向き、レジにてユーザＩＤ等が確認される。レジでの支払いが完了したような場合等には、ステップ１３０９で商品の引渡がされる。但し、ユーザ５がこの商店に出向かなくても配送可能とされてもよい。また、当該商店では、この商品以外の商品がユーザ５により併せて購入されてもよい。
以上により、欲しい商品の詳しい情報が無くても現物から同じ商品を簡単に購入できる。この際には、値引き交渉等も行える。より安い店を探すこともできる。
次に、本発明の第７実施形態について説明する。本発明の第７実施形態は第５実施形態の別態様である。
第７実施形態では、テレビやテレビ機能付きパソコン等において、テレビショッピングが行われる場合である。このテレビショッピングにおいて、商品紹介の際には画面の適所にバーコード１００３が表示される。フローチャートは、図３５のものとステップ１２０１〜ステップ１２２１まで同様である。図３５のステップ１２０１において、この画面に表示されたバーコード１００３を携帯電話１００５等で撮像して読み取る。ステップ１２０３で、このバーコード１００３に記録された情報から製品名、サイトのＵＲＬを解析する。このＵＲＬを基にステップ１３０１ではサイトのＷｅｂページが開かれ、その後値引き交渉等が行われる。ステップ１２２３以降の処理に代えて、電子決済や銀行振込、あるいは着払いを中心とした決済が行われ、購入された商品は配送される。
なお、インターネット機能を有するテレビやパソコン等において、テレビショッピングを行う場合には、画面上で当該商品のネット接続可能な購入ボタンを押すことで、値引き交渉等のＷｅｂページが開かれる。この際には、テレビ映像欄外にてユーザ希望購入価格欄９１を表示したり、テレビ映像と２重に重ねられた状態でユーザ希望購入価格欄９１を表示することが望ましい。ユーザは、ユーザ希望購入価格欄９１に希望購入価格を入力することで当該商品等について値引き交渉が行える。
次に、本発明の第８実施形態について説明する。本発明の第８実施形態は第５実施形態の別態様である。
図３７のフローチャートを基に本発明の第８実施形態の動作を説明する。なお、図３５と同一要素のものについては同一符号を付して説明は省略する。
無線にて情報取得可能なアンテナ部を有するＩＣタグを各商品、若しくは紙やプラスチック等の商品カードに付しておく。ステップ１３５１では、ユーザ５は、商品や商品カードを買い物かごに入れる。ステップ１２２１にて商品購入を終了する場合にはステップ１２２５に進み、続ける場合には、ステップ１３５１を繰り返す。そして、ステップ１２２５では、レジ１１１１にてこれらの情報をまとめて電磁的に読み込む。レジ１１１１には、このための電磁波送受信部及びデータ解析部が配設されている。この場合、ＩＣタグに対し無線にて電力送信を行うと共にＩＣタグより受信した受信データを読み込むようにする。ＩＣタグ側では、受信電波より電力を得ると共にこの電力を利用して保存されていた情報を電波にして放射する。この情報の搬送された電波を受信し、ステップ１２２７で解析することで情報を取得できる。但し、バーコードにより情報を読み込むようにしてもよい。
情報には、製品名が記録されている。取得された製品名はデータベース１００９に保存される。そして、この製品名を基にステップ１２２９では、データベース１００９よりデータが抽出され、表示器１１１５には当該製品名と共に価格が表示される。この価格についてステップ１２１３では値引き交渉等を行う。商品は複数についてまとめて値引き交渉等がされることも可能である。但し、値引き交渉等をせずに購入のみを可能としてもよい。また、購入金額の大きさにより値引き交渉等を可能とする等されてもよい。レジ１１１１には、ユーザ希望購入価格を入力するためのテンキーが用意されており、ユーザ５は、このテンキーを利用してユーザ希望購入価格を入力する。ステップ１２０９及びステップ１２１１は省略されてもよい。表示された値引き交渉結果でよければステップ１２１７で購入ボタンを押す。ステップ１２３７以降にて支払いをする。
以上により、ユーザ５は、会計の際にまとめて値引き交渉等ができるので、効率的である。
次に、本発明の第９実施形態について説明する。本発明の第９実施形態は値引き交渉における底値Ｙ円及び実数ｍ値を交渉の都度変動させるものである。
底値Ｙ円はこの値を含む若しくは下限とする範囲とする。即ち、例えば１万円の商品に対してこれ以上値下げできない限界値が５千円だったとして、４千８百円〜５千８百円の範囲（若しくは５千円〜６千円の範囲）の中のいずれかの値として底値を定義する。そして、この範囲の中で例えば乱数発生をさせ、底値を決めることとする。このことにより、底値はその都度変動するため、ユーザ５に対しては底値が推定し難いものとなる。
また、底値Ｙ円及び実数ｍ値は、商店等７の利益如何に応じて変動させるのが望ましい。このため、例えば実際に行われた値引き交渉結果値の平均値ＡＶを取り、予め商店等７側で予定した値ＰＲとの差を求め、ＡＶ−ＰＲが正のとき乱数結果により求められた底値に対して一定値を下げる。但し、この下げ値を考慮したことによる底値が限界値を超えないことが望ましい。また、この下げ値はＡＶ−ＰＲの大きさ如何によって変化させるのが望ましい。例えばＡＶ−ＰＲの大きさが大きければ下げ値も大きくする。一方、ＡＶ−ＰＲが負のとき乱数結果による底値に対して一定値を上げる。
あるいは、ＡＶ−ＰＲが正のとき、４千８百円〜５千８百円の範囲の上限である５千８百円を一定値下げ（例えば５千４百円とする等）、一方、ＡＶ−ＰＲが負のとき４千８百円〜５千８百円の範囲の下限である４千８百円を一定値上げる（例えば５千円とする等）ようにしてもよい。下げ幅、上げ幅は、ＡＶ−ＰＲの絶対値の大きさ如何で決めることが望ましい。
更に、ＡＶ−ＰＲが正のとき実数ｍ値の値から一定値を上げ、一方、ＡＶ−ＰＲが負のとき実数ｍ値の値から一定値を下げるようにしてもよい。
なお、上述の説明では、ＡＶ−ＰＲを算出して底値Ｙ円及び実数ｍ値を変動させるとして説明したが、底値Ｙ円以上に相当する部分を利益額としてその額の合計を算出し、この利益額如何により底値Ｙ円及び実数ｍ値を前述と同様に交渉の都度変動させるようにしてもよい。
次に、本発明の第１０実施形態について説明する。本発明の第１０実施形態は、図１６等で行われた値引き交渉の結果として減額される価格の内、一定金額又は全額を現金還元としてデータベース１００９側に設けたユーザ貯金箱に保管するものである。そして、このユーザ貯金箱に保管された仮想現金を商品１００１の購入の代金として使用可能とするものである。
ネット上でユーザ５に表示される希望販売価格はＸ円で、底値はＹ円、第１回目の交渉金額がＧ１円とする。希望販売価格Ｘ−第１回目の交渉金額（値引き交渉の目安値）Ｇ１＝Ｈ円とすると、この内の一定金額を現金還元としてデータベース１００９側に設けたユーザ貯金箱に保管する。例えば、Ｈ円の内、３０パーセントを現金還元される額として設定すると、現金還元額は０．３Ｈ円となる。
そして、ユーザ５に対しては、予め、値引き交渉により減額された価格の内から、この０．３Ｈ円を現金還元額としてユーザ貯金箱に保管する旨の表示を行う。 値引き交渉による最終決定金額は、値引き交渉による決定価格にユーザ貯金箱に入れられる現金還元額を加算した額となる。なお、ユーザ貯金箱に入れられる現金還元額が、希望販売価格Ｘ−値引き交渉の決定価格である場合には、ユーザ５の支払金額は希望販売価格Ｘ円となる。そして、このユーザ貯金箱に入れられた現金還元額をユーザ５は、その後の商品購入代金として利用可能である。
なお、値引き交渉による決定価格にユーザ貯金箱に入れられる現金還元額を加算した額が希望販売価格Ｘを超えるような場合には、現金還元額を減額する等の処理を行うことが望ましい。
次に、本実施形態の別例について説明する。
図１６等における底値Ｙ円に対し、現金還元額を例えば０．３Ｈ円として、底値＋現金還元額を改めて底値Ｙ円に代えて仮底値として読みなおす。そして、ユーザ５には、この仮底値以上希望販売価格以下の間で値引き交渉をさせる。
例えばＪ円で値引き交渉が決定したとする。このときのユーザ５の支払額はＪ円である。そして、この中から０．３Ｈ円がユーザ貯金箱に入れられる。
以上により、ユーザ貯金箱に仮想現金が貯められていることで、ユーザ５が、再びこの仮想現金を使うため商品１００１を購入することが期待できる。
なお、以上の処理を第４実施形態等で説明した複数購入商品についてまとめて値引き交渉する場合に対し適用する方法について説明する。
この場合には、まずそれぞれの商品１００１の現金還元額を予め決めてユーザ５に対し開示しておく。そして、各商品１００１についての底値の合計額より、各商品１００１の現金還元額の合計額分だけアップさせた金額を仮底値として値引き交渉をさせる。そして、値引き交渉が成立したら、現金還元額の合計額分をユーザ貯金箱に入れる。
次に、本発明の第１１実施形態について説明する。本発明の第１１実施形態は、上述した各実施形態の値引き交渉処理を用い、例えばある商品等の商品購入の際に複数の人が一種の入札をする形で競い合いつつ、スリルに富んだ買い物ができるようにしたものである。
商店等７にはまず、その商品１００１の希望販売価格及びその商品１００１のこれ以下では販売を許可しない底値価格を提示してもらう。希望販売価格をホームページには載せる。そして、当該商品１００１について入札に参加したい人に対しては、当該商品１００１のホームページからログインＩＤ及びパスワードによりサイトに入ってもらって参加の意思表示をしてもらう。この参加の意思表示のあった場合には、サイトよりこのユーザ５に対し電子メールを送信する。電子メールには、例えば一定回数だけ入札に参加を認めるための番号が記載されている。
ユーザ５には指し値の勝負をしてもらう。ユーザ５が底値価格以下の値段をつけたら例えば図１６のステップ９１、１２３、１０９で示すように、「この値段でどうですか」という具合に交渉価格を提示する。ユーザ５は、この価格で購入したければ、購入のボタンを押す。この価格では高すぎて購入出来なければ、図示しない購入断念のボタンを押す。
参加を認められた他のユーザ５も上記と同様の処理を行う。そして、各ユーザ５によって購入断念のされた入札履歴は、図３８以下に示すようにホームページ上で表示され、誰でも閲覧が可能なようになっている。商品１００１は一番先に買いを意思表示した人に販売される。即ち、交渉価格でユーザ５が購入を決意した場合、あるいは、底値を超えた価格を入力することでこのユーザ５は商品購入が可能となる。
図３８の履歴例を基に説明する。商店等７の希望販売価格を１００００円、底値価格を７０００円、第１回目の交渉価格を８５００円、第２回目の交渉価格を８０００円とする。商品１００１は電子レンジで、出店者はＡＡさんである。ソラさんは値引き交渉権を４回以上持っている。履歴表示の項目で「１人目 ソラさん １０００円 １５日１０時２分 購入断念」は、１０００円で購入しようと思ったが、８５００円でどうですかと表示されたので、購入を断念したということを意味する。７人目でソラさんは再び７５００円で挑戦したところ、底値落札価格の７０００円を超えたので購入できた。
次に図３９の履歴例について説明する。ソラさんは値引き交渉権を２回以上持っている。履歴表示の項目で「１人目 ソラさん １０００円 １５日１０時２分 購入断念」は、１０００円で購入しようと思ったが、「８５００円でどうですか」と表示されたので、購入を断念した。
その後もう１回続けてチャレンジした。ソラさんは再び２４００円で挑戦したところ、２回目交渉価格「８０００円でどうですか」と表示された。この価格ならと購入を決意した。
次に図４０の履歴例について説明する。ソラさんは値引き交渉権を２回以上持っている。そして、２回続けて挑戦したが、２回目交渉価格８０００円でも高いと感じたので降りた。カニさんは１回挑戦したが、「８５００円でどうですか」と表示されたので、購入を断念した。様子を見ていたＡＡさんは、特別表示価格を９０００円に下げた。底値落札価格も６５００円に下げた。
但し、ＡＡさんは、逆に特別表示価格を高くしてもよいし、底値落札価格を高くしてもよい。人気があるとみれば底値落札価格を高くすることも可能である。 このように、商店等７側や出店者は、この入札履歴を参照して、自らの設定した希望販売価格や底値価格をサイト上で変更することができる。変更されたデータはサイトのデータベース１００９に保存される。但し、商店等７側により割引の度合いに対応する実数である実数ｍをも変更可能としてもよい。変更の履歴は入札履歴に記録される。このため、ユーザ５は、値段が変更されたことを知ることができる。その後、この変更された希望販売価格及び底値価格等に対してユーザ５は改めて作戦を立て直し、購入に向けた入札を行うことができる。なお、商店等７側が底値落札価格を下げた時点で、この底値落札価格よりも高い金額にて入札を行っていたユーザ５がいた場合には、このユーザ５に対して購入を認めるようにしてもよい。商品等の在庫数量が複数ある場合には、最も値段を高く設定したユーザ５から順に複数人に対し購入を認める等してもよい。
このように、本実施形態では、オークション的機能に加えて早い者勝ちの機能をも有する。当該商品等を即刻欲しい人は交渉価格で購入することも可能である。一方、底値ぎりぎりの値段での購入を希望するユーザ５は、少しずつ値段を競り合う形での参加が可能である。底値に一番早く到達したユーザ５に対し落札が認められるため、ユーザ５はいち早く入札金額を提示しようとする。また、底値は途中で商店等７により下がることもあるのでユーザ５はクギ付けになる。但し、以上の機能に加えて入札には制限時間を設け、制限時間内で最高額を出したユーザ５に対して購入を認めるようにしてもよい。また、この際には、出店者の設定した最低額を超えた値段だけが入札の参加可能な金額として認められるようにしてもよい。この最低額は通常底値以下に設定され、入札の可能とされる最低の金額である。また、前記と同様に底値価格を超えた場合には購入可能であり、また提示された交渉価格にても購入可能である。このように、制限時間をも組み合わせることでより一層緊迫の度合いが増す。各入札参加者にとっては、底値価格での購入、交渉価格での購入、制限時間による最高値を付けた人による購入のいずれの態様で購入が決まるのか全く分からないので、緊迫の度合いは極めて大きい。更に、底値以上になったときに購入可能とする機能を任意選択（若しくは保留）可能としてもよい。更に、以上の機能の組み合わせを各機能毎に任意に選択可能としてもよい。これらのオークション機能は、証券取引及び株価決定等にも使用可能である。
なお、同一のユーザ５の入札への参加回数は無制限とされてもよい。また、この場合に、同一のログインＩＤの者に対して当該競争入札に限り、例えば２回だけ中間提示額を提示しての交渉を認める。そして、ユーザ５に対して、この中間提示額を提示しての交渉を行うか否かユーザ５が入札を行った際に尋ねるようにする。入札金額の低い内から中間提示額を提示しての交渉により落札される可能性は低いが、入札が競って来た場合には、中間提示額を提示しての交渉により早期の決着を望む場合があるからである。また、この中間提示額は、各ユーザ５が入札を行った入札金額が底値落札価格に近くなればなるほど底値落札価格に近づくように低くされてもよい。希望販売価格をＸ円、現時点での入札金額の最高額Ｌ円、底値落札価格Ｙ円とすると、中間提示額Ｑ円は、Ｑ＝ｍ（Ｙ−Ｌ）（Ｘ−Ｙ）／Ｙ＋Ｙ
ｍは実数であり、現時点での入札金額が底値落札価格に近づいたときに、どの程度中間提示額Ｑを底値落札価格に近づけるかの感度を示す。但し、この中間提示額Ｑは一律の値ではなく、（Ｙ−Ｌ）／Ｙに依存した関数としてもよい。そして、例えば、（Ｘ−Ｌ）／Ｙの値が小さくなればなるほどｍ値は大きくする等されてもよい。この場合には、ユーザ５は中間提示額が下がりいつ落札されても分からない事態となるので一層のスリルを感じる。あるいは、ｍの値は入札のあった回数に従い変化するようにしてもよい。また、底値価格を超えた場合に購入される、このときの底値価格の設定値と、中間提示額を算出するのに使用される底値の設定値とは異なるように設定されてもよい。
なお、例えば図４１に示すように、商品名や商品ジャンルにより底値Ｙ円の安い順等にリストを提示し、商店等７名や商品型番等をクリックすることで当該出展品にリンクされるようにしてもよい。底値Ｙ円はユーザ５に対しては開示されない価格なので、表示価格については順不同となる。
次に、本実施形態の別例について説明する。図４２においては、現金還元の実施されたものの履歴がとられるようになっている。そして、この履歴はユーザ５が閲覧可能である。現金還元額３０００円はユーザ貯金箱に入れられ、次の購入に使用できる。値引き交渉権が無くても参加できる。購入により値引き交渉権が少なくとも一回分つく。
なお、例えば図４３に示すように、商品名や商品ジャンルにより現金還元額の大きい順等にリストを提示し、商品型番等をクリックすることで当該出展品にリンクされるようにしてもよい。
また、ユーザ５が電子メールで付与された回数を超えて更に入札に参加し続けたい場合には、既に商品購入等により蓄積されている値引き交渉権を利用して入札が可能とされてもよい。また、商品１００１の購入に際しては、ユーザ貯金箱からの支払も可能である。
更に、商店等７側の判断により、随時、入札履歴の中で最高入札金額を提示している一人若しくは商品等の数量が複数あれば最高入札金額の人から数えて数人分に対して購入を認めるようにしてもよい。
次に、本実施形態に関し、ユーザ５が手動で入札に際しての金額を入力する代わりに、自動的に入札可能とする方法について説明する。
上記した実施形態では、ユーザ５は時々刻々の入札履歴を閲覧しつつ次の一手を考えて実行する必要がある。このため、常時パソコン画面を閲覧する必要がでてくるが、長時間となると煩雑である。したがって、以下のようにユーザ５が入札のシミュレートを考案し、入札に容易に参加可能なようにするものである。なお、本方法は、本実施形態に限定されるものではなく、インターネット１を通じて広く行われている複数の人が価格を少しずつ上げて行って入札を競り合うインターネットオークション形式の競争入札に対しても同様に適用可能なものである。
センターサーバー１００８とユーザ５の使用するパソコンとはインターネット１を介して接続されている。まず、ユーザ５は、センターサーバー１００８に接続し、Ｗｅｂ画面上で入札に参加する商品等がこれから落札されるであろう推定価格を３段階に設定する。推定価格第１段階、第２段階、第３段階となるにつれて金額は大きく設定されるようになっている。但し、推定価格は必ずしも３段階に限定されるものではない。そして、ユーザ５は更に入札１回目の突き放し度αを設定する。続いて入札２回目の突き放し度β、入札３回目の突き放し度γ（α＜β＜γ）を設定する。但し、突き放し度は、入札３回目の突き放し度γ以降にも入札４回目の突き放し度δ・・・・等任意に追加設定可能なようになっている。この突き放し度は、他者の追随を振り払うために設定される度合いである。
推定価格第１段階、第２段階、第３段階、突き放し度はセンターのデータベース１００９に保存される。入札開始にあっては、入札金額＝（（推定価格第１段階−入札開始最低価格）×突き放し度／１００＋入札開始最低価格）、一方、入札履歴が１件以上あった場合には入札金額＝（（推定価格第１段階−入札履歴中の現時点での最高価格）×突き放し度／１００＋入札履歴中の現時点での最高価格）に設定される。すなわち、他者に対し価格面での追随を許さないためには入札の金額をできるだけ高く設定するのが理想であるが、いきなりあまりに高額を設定することは低価格での購入が出来なくなることに繋がりユーザ５にとって好ましいことではない。したがって、この両者を満足させる適当な突き放し度をユーザ５本人が予め設定する。突き放し度αでの価格設定に基づき入札が行われることにより、このユーザ５が１番高額の入札価格を設定したことになる。
しかしながら、この入札価格に対して他者が更に高額な入札価格を設定してきた場合には、次の突き放し度βでの価格設定に基づき自動入札が行われる。但し、この時点で他者の入札価格が突き放し度βでの価格設定をすでに超えていた場合には、突き放し度γでの価格が入札価格に設定される。この自動入札によれば、逐一ユーザ５がＷｅｂ画面上で入札価格を入力するのではなく、センターサーバー１００８に予め保存されたデータを基にセンターサーバー１００８内で自動処理される。以降同様の処理が繰り返される。その後、他者の設定した入札価格が推定価格第１段階を超えた場合には、推定価格第１段階に代えて推定価格第２段階が代入された上で再び入札金額＝（（推定価格第２段階−入札履歴中の現時点での最高価格）×突き放し度／１００＋入札履歴中の現時点での最高価格）に基づき突き放し度αからの処理が繰り返される。なお、この点は、他者の入札価格が先の推定価格第１段階における突き放し度γでの価格を超え、かつ推定価格第１段階をもいきなり超えてしまったような場合にも同様である。但し、推定価格第２段階においては、推定価格第１段階とは異なる突き放し度が設定されるようにしてもよい。以降、推定価格第３段階についても同様の処理が行われる。そして、底値価格を初めて超えた場合に落札が決定され商品等を購入することができる。しかしながら、この点は、通常のインターネットオークションのように最終的に最高値をつけたユーザ５に対し落札がされるというようにされてもよい。
次に、本発明の第１２実施形態について説明する。本発明の第１２実施形態は、値引き交渉を会社同士の取引に適用するものである。
値引き交渉を会社同士の取引に適用する場合には、取引元は取引先である会社の規模や当該会社との間のこれまでの取引や実績、将来的な協力関係等を考慮した上で値引きの程度を個々に勘案することが望ましい。また、値引き交渉の行える会社を無制限に認めるのではなく、ある程度真に交渉を希望する会社に制限するため許可性を取ることが望ましい。
図４４のフローチャートに基づき説明する。Ｗｅｂ上には、値引き交渉等により値段決定可能な取引を提示している取引元である一方の会社が存在する。まず、ステップ１４０１では、この会社の情報及び取引項目を閲覧し、この会社との間での取引を希望する会社がＷｅｂ上でログインＩＤを入力する。取引希望会社が未だ登録されていない会社の場合には、Ｗｅｂ上で会社名、代表者、所在地、電話番号、資本金、従業員数、設立年、電子メール番号等を入力してもらう。次に、ステップ１４０３ではパスワードを入力する。そして、ステップ１４０５では、取引希望会社は「値引き交渉を希望」（あるいは取引を希望）等のボタンを押す。ステップ１４０６では、センターサーバー１００８に接続する。ステップ１４０７では、登録情報の中から当該取引希望会社についての会社情報を読む。ステップ１４０９では、会社便覧等の予め入れられたデータベース１００９からこの会社情報と一致する会社を検索する。そして、ステップ１４１１では、このデータベース１００９中から会社情報を読む。ステップ１４１３では、読まれた会社情報から資本金、従業員数等の企業力を点数評価する。ステップ１４１５では、取引希望会社に対しユーザパソコンから今回取引を希望する相手企業との間のこれまでの取引情報を入力してもらう。あるいは入力等を要さずに会社情報から予めセンターのデータベース１００９に保存されている取引情報を読むようにしてもよい。
ステップ１４１７では、当該会社との間の取引状況を点数化する。この場合取引元と各企業との間で最高の取引額のケースを例えば１００として点数化したりすればよい。また、ステップ１４１９では、これまでの実績を評価し点数化する。これは、例えば依頼案件について日常良くやってくれている。信頼がおける等のこれまでの取引における質面の評価を最高点を１００として点数化する。そして、これらの質及び量の面から総合的に評価を下すため図４５のステップ１４２１で点数の合計を算出する。ステップ１４２３では、予め定めた一応合格ラインとみなせる値である標準点数値との間の偏差を算出する。
ステップ１４２５で偏差が相当に低いと判断された場合には、ステップ１４２７でその内容を取引元に電子メール等で通知する。そして、この場合にはステップ１４２９で企業の独自判断に委ねる。一方、ステップ１４２５で偏差が一定レベル以上の場合には、ステップ１４３１でその偏差の大きさに応じて底値、割引の度合いに対応する実数である実数ｍを変える。ステップ１４３３では、利用可能番号を付した電子メールを取引希望会社に配信する。ステップ１４３５でこの電子メール等を受信した取引希望会社はステップ１４３７においてＷｅｂ上で利用可能番号を入力する。ステップ１４３９でこの利用可能番号がセンターサーバー１００８に送信されることで、ステップ１４３９では値引き交渉が実施可能となる。
以上により、一層信頼関係の重視されるような企業間での取引等においても、適正に値引き交渉機能が適用可能となる。
次に、本発明の第１３実施形態について説明する。本発明の第１３実施形態は、予算総額を入力し、その予算総額に入る商品リストを提示するものである。
図４６には商品選択の画面例を示すが、ユーザ５が購入したい商品等の優先順位や商品名、メーカー名等、欲しい機能等を指定できると共に当該商品についての予算割当金額が入力できるようになっている。欲しい機能やキーワードは複数個選択若しくは指定されてもよい。図４７のステップ１５０１で、ユーザ５はセンターサーバー１００８のホームページにおいて「予算内で購入」ボタンをクリックする。ステップ１５０３で地域を選択し、ステップ１５０５で商店名を選択する。地域は全国いずれの地域なのかを選択するが、限定しないことも可能である。また、商店名を選択せずにステップ１５０６で、安い店を選択、大規模店を選択、老舗を選択、底値の低い店を選択、現金還元額の大きい店を選択、人気店を選択、よく売れている商品で選択等から選択がされてもよい。これらのデータはセンターサーバー１００８のデータベース１００９に保存されている。
次に、ステップ１５０７でＷｅｂ画面上で商品１００１を選択する。この商品選択では、図４６に示すように、ユーザ５が予算総額の中で購入を優先したい順位、商品ジャンル、商品名、個数、機能、メーカー名、予算割当金額、その他必要なキーワードが入力若しくは選択可能である。予算割当金額には、予算総額の中でこの商品１００１について幾ら位を当てるかについて記載する。キーワードは、自由記載であり、このキーワードに関連する商品１００１をデータベース１００９からテキスト検索可能なようになっている。ステップ１５０９では、「お薦めを選択」ボタンをクリックすることにより、お薦め商品を選択、女性に人気、２０代に人気、３０代に人気、４０代に人気、５０代に人気、特にこだわらない等を選択可能である。そして、ステップ１５１１では、予算総額を図示しない予算総額入力欄に入力し、センターに送信する。この予算総額は、例えば１００００円と一義的に入力されてもよいし、１００００円〜１５０００円と範囲指定により入力されてもよい。また、１００００円以下等と入力されるようにしてもよい。範囲指定される場合には、予算割当て金額は複数の範囲指定の中から一つを選択とされてもよい。このとき、当該商品名に属するすべての商品について希望販売価格の最高額と最低額とを基に、予め金額範囲を適当な範囲に分割して設定したものを複数用意しておく。
そして、ステップ１５１３でセンターサーバー１００８にログインするためのユーザＩＤやパスワードを入力する。センターサーバー１００８側では、予算総額の−３割減〜＋３割増しを設定する。予算範囲を目安として商品１００１を選択するためである。ステップ１５１７では、カウンターＮに１を入れる。カウンターＮはユーザ５が購入優先順位で選択した順位の数である。
まず、ステップ１５１９で購入優先順位１番目を選択する。そして、ステップ１５２１で商品名に基づきデータベース１００９から商品の絞り込みを行う。図４８において、ステップ１５２３では、「人気商品」「お薦め」等のユーザ５が選択した事項に基づき商品を絞り込みするか否か判断する。即ち、ステップ１５０９で「お薦め」等の選択がされている場合にはステップ１５３１に進む。一方、「お薦め」等の選択がされていなかった場合には、ステップ１５２５でメーカー名に基づき商品を絞り込む。そして、ステップ１５２７で機能に基づき商品を絞り込み、更に、ステップ１５２９でキーワードに基づき商品を絞り込む。
ステップ１５３１では、当該商品の予算割り当て金額の−３割減〜＋３割増しに入る商品を絞り込む。一応、この金額範囲ならばユーザ５が購入する可能性があるし、予算額を考え直す可能性があると考えられるためである。但し、この範囲（−３割減〜＋３割増し）については必ずしも限定するものではない。なお、現金還元システムが希望販売価格よりも現金還元された分実際に安く購入できる設定の場合には、予算金額として現金還元された結果の額を基に（即ち、商店等７の希望販売価格から現金還元額を引いた金額を基に）絞り込みが行われるようにしてもよい。こうすることにより、ユーザ５による実際の支払額と予算額との差を極力小さくすることができる。予算金額として商店等７の希望販売価格をそのまま用いるのか、あるいは、現金還元された結果の額を用いるのかを予め設定するようにしてもよい。また、値引き交渉結果の金額がおよそ推測可能であるならば、この値引き交渉結果の金額を基に絞り込みが行われるようにしてもよい。例えば、値引き交渉結果の金額を現金還元される額と同じとみなして処理がされてもよい。
次にステップ１５３３で絞り込み件数が１以上存在するか否か判断する。１以上存在する場合には、ステップ１５３５でデータを保存し、ステップ１５３７でカウンターＮを１インクリメントする。ステップ１５３９では、次の購入優先順位の商品が存在するか否か判断し、存在する場合には、ステップ１５１９から同様の処理を行う。一方、ステップ１５３３で絞り込み件数が１以上存在しなかった場合には、図５０のステップ１５７５に進む。ステップ１５７５では、予算割り当て金額の−３割減〜＋３割増しを超えて商品を再び絞り込む。この範囲は少しずつ広げて随時判断するのが望ましい。そして、ステップ１５７７で絞り込み件数が１以上存在した場合にはステップ１５３５に進みデータを保存する。
ステップ１５７７で絞り込み件数が１以上存在しなかった場合は、ステップ１５７９で「人気商品」「お薦め」等のユーザ５が選択した事項を無視して商品を再び絞り込む。ステップ１５８１で絞り込み件数が１以上存在した場合にはステップ１５３５に進みデータを保存する。ステップ１５８１で絞り込み件数が１以上存在しなかった場合は、ステップ１５８３で機能やキーワードを無視して商品を再び絞り込む。ステップ１５８５で絞り込み件数が１以上存在した場合にはステップ１５３５に進みデータを保存する。ステップ１５８５で絞り込み件数が１以上存在しなかった場合は、ステップ１５８７でメーカー名を無視して商品を再び絞り込む。ステップ１５８９で絞り込み件数が１以上存在した場合にはステップ１５３５に進みデータを保存する。ステップ１５８９で絞り込み件数が１以上存在しなかった場合は、ステップ１５９１で「予算内に入る商品を見つけることができませんでした。」とセンターサーバー１００８よりユーザ５に対しメッセージを送信、表示する。但し、絞り込み手順はこれに限定するものではない。
なお、ユーザ５の指定により、一つの選択された商品の値段が予算を大きく超えた場合に、他の商品に対し、この超えた分を回すようにされてもよい。具体的には、例えば、優先順位の高い商品について選定の結果予算割当金額を大きく上まわった場合に、優先順位の低い商品についての予算割当金額を小さく設定し直す等の調整をする。このように設定された新たな予算割当金額について商品等の絞り込みが再び行われる。そして、絞り込みの行われた結果の商品等についてあらためて金額が計算される。一方、優先順位の高い商品について選定の結果予算割当金額を大きく下まわった場合に、優先順位の低い商品についての予算割当金額を高く設定し直す等されてもよい。そして、再び商品等の絞り込みが行われる。
ステップ１５４１では、選択された結果の商品を各ジャンルから一つ抽出して組み合わせる。このとき、各ジャンルには少なくとも一つの商品データが保存されているが、これらのデータをジャンル毎に一つずつ抽出して組み合わせて表示する。例えば、購入優先順位１位のジャンルから一つの商品を抽出し、購入優先順位２位のジャンルから一つの商品を抽出し、・・・という具合に抽出して組み合わせる。この組み合わせの順位については、任意としてもよいが、例えばメーカー名、機能、キーワード、お薦め度合い等の間に予め優先順位を付けるようにしてその順位に従って表示することが望ましい。そして、図４９のステップ１５４３では組み合わせの行われた商品等について合計金額を算出する。ステップ１５４５で「予算範囲を超えたリストを要求」ボタンを押した場合にはステップ１５５１で総予算額の−３割減〜＋３割増しを超えたものを選択する。そして、ステップ１５５３で「予算範囲を超えたリストです」とＷｅｂ表示した上でステップ１５５５でリストを表示する。
一方、ステップ１５４５で「予算範囲を超えたリストを要求」ボタンを押さなかった場合には、ステップ１５４７で総予算額の−３割減〜＋３割増し以内に絞る商品を選択する。そして、ステップ１５４９で「予算範囲か若しくは値引き等により予算範囲に近くなると思われるリストです。」とＷｅｂ表示した上でステップ１５５５でリストを表示する。
但し、ステップ１５４５、１５４７、１５４９、１５５１、１５５３の処理は省略することも可能である。
ステップ１５５７では、リスト以上に詳細な例えば機能仕様等の商品データを表示する。ステップ１５５９でユーザ５により、「他の当店人気商品と比較」ボタンが押された場合には、ステップ１５６１で他の当店人気商品の詳細が対比される。この「他の当店人気商品と比較」ボタンが押されない状態では、ステップ１５４１で抽出されたデータはご購入予定商品欄に記載される。「他の当店人気商品と比較」ボタンが押された場合で、ご購入予定商品と比較例の表示された対比図の様子を図５１に示す。当店人気商品については、予め商店側で販売統計等を基に選定されたものがデータベース１００９に保存されている。図５１では、比較例は２個について表示されているが、必ずしもこれに限定されるものではなく、随時比較例の下位のものを追加表示することができるようになっている。
Ｗｅｂ画面にはユーザの入力した総予算額のデータとともに今回ご購入予定商品の合計金額とが表示されている。これにより、ユーザ５は、合計金額が総予算額の範囲内に収まっているのか、若しくは総予算額の範囲からどの程度ずれているかを判断できる。このご購入予定商品欄に記載されたデータと比較例とに記載された詳細データとを比較参照したユーザ５は、ステップ１５６３で比較データのいずれかをクリックすることで、ステップ１５６５でこの比較データの商品をご購入予定商品に変更することができる。この場合には、ステップ１５６７で、あらためてすべてのご購入予定商品に対し合計金額を算出し直す。ステップ１５６９で購入ボタンがクリックされた場合には、ステップ１５７１で値引き交渉等を行うことが可能である。この値引き交渉には商品等をまとめて値引きが行われるようにされてもよい。ステップ１５７３で「次の候補」ボタンがクリックされた場合には、ステップ１５４１に戻り、絞り込みのされた商品等データの中から次の組み合わせが抽出され、その後同様の処理が行われる。
以上により、ユーザ５に対しインターネット１を介して予算額の範囲内で購入の可能な商品を見積もり提供できる。また、ユーザ５は、他のお薦め商品等と対比をすることができ、対比の結果購入したい商品を変更することもできるため、商品選択が簡単に行える。購入の決まった商品はインターネット１を介して値引き交渉や現金還元等により安価に購入をすることができる。
なお、図５０のステップ１５７５〜ステップ１５９１に代えて、図５２及び図５３に示すような処理とされてもよい。以下、図５０の処理の別態様について説明する。図５２及び図５３のフローチャートにおいて、ステップ１５３３で絞り込み件数が１以上存在しなかった場合には、ステップ１６０１で、無視すべき項目をユーザに提示し選択させる。この無視すべき項目は、予算額、「人気商品」「お薦め」等のユーザが選択した事項、機能及び／又はキーワード、メーカー名である。ユーザは無視してもよい項目を少なくとも一つ選択する。
例えば、ステップ１６０３で「予算を無視して商品を再び絞り込み」が選択された場合には、ステップ１６０５で予算を無視して商品を再び絞り込む処理が行われる。この場合、ステップ１５２１〜ステップ１５３１迄の処理の内、ステップ１５３１の処理がスキップされて絞り込みが行われる。そして、ステップ１６０７で絞り込み件数が１以上存在した場合にはステップ１５３５に進む。一方、ステップ１６０７で絞り込み件数が１以上存在しなかった場合にはステップ１６０９で「商品を絞り込みすることができませんでした。」とユーザ５に対して表示する。但し、予算額を完全に無視するのではなく、予算額を随時一段ずつランクアップした上で再度絞り込みを行うようにしてもよい。この場合には、商品件数が一つ以上存在した予算額のランクにおいてステップ１５３５に進むことが望ましい
また、ステップ１６１１で「「人気商品」「お薦め」等のユーザが選択した事項を無視して商品を再び絞り込み」が選択された場合には、ステップ１６１３で「人気商品」「お薦め」等のユーザが選択した事項を無視して商品を再び絞り込む処理が行われる。そして、ステップ１６１５で絞り込み件数が１以上存在した場合にはステップ１５３５に進む。一方、ステップ１６１５で絞り込み件数が１以上存在しなかった場合にはステップ１６０９で「商品を絞り込みすることができませんでした。」とユーザ５に対して表示する。
以下、図５３のステップ１６１７で「機能及び／又はキーワードを無視して商品を再び絞り込む」が選択された場合についてもステップ１６１７〜１６２１に示すように上記と同様に処理が行われ、一方、ステップ１６２３で「メーカー名を無視して商品を再び絞り込む」が選択された場合についてもステップ１６２３〜ステップ１６２７に示すように上記と同様に処理が行われる。
更に、ステップ１６２９で、例えば「「人気商品」「お薦め」等のユーザが選択した事項を無視して商品を再び絞り込み」及び「機能及び／又はキーワードを無視して商品を再び絞り込む」の２つが選択された場合については、ステップ１６３１でまず、「人気商品」「お薦め」等のユーザが選択した事項を無視して商品を再び絞り込む処理が行われ、その後、ステップ１６３３で機能及び／又はキーワードを無視して商品を再び絞り込む処理が行われる。なお、２つの選択の組み合わせは上記に限らない。そして、ステップ１６３５で絞り込み件数が１以上存在した場合にはステップ１５３５に進む。一方、ステップ１６３５で絞り込み件数が１以上存在しなかった場合にはステップ１６０９で「商品を絞り込みすることができませんでした。」とユーザ５に対して表示する。なお、３つ以上の機能無視が選択された場合についても上記と同様である。
以上により、ユーザ５にとってより一層簡単に自分の商品購入希望に沿った形での絞り込みが行える。
次に、本発明の第１４実施形態について説明する。本発明の第１４実施形態は、商品の絞り込みをユーザに簡単にしてもらう手法についてである。まず、図５４のステップ１６５１で前準備をする。ここでは、商品名を選択したりする。ステップ１６５３では、予算額を入力若しくは選択する。即ち、予算額は金額を入力欄に入力してもらってもよいし、予め複数設定された金額範囲の内から一つの範囲を選択するようにしてもよい。また、メーカー名を指定若しくは全メーカー名を指定して絞れるようにしてもよい。そして、ステップ１６５５では、ユーザ５は必要な機能を選択する。この機能は当該商品名に属するすべての商品を調査し、これらの商品を網羅できるように予め設定された機能（機能を示す単語若しくはキーワード的なもの）と当該機能の説明とである。この機能等は人為的に収集され設定されてもよいが、各商品仕様を箇条項目としてこれらのデータをコンピュータが自動収集して設定するようにされてもよい。同一の機能であっても各社毎に異なる定義や解説のされている場合があるが、かかる場合には、データベース１００９に入力する際に機能の定義等を一義的に共通に定めたテーブルを用いて人為的にデータ変換することで半自動収集が可能となる。
ステップ１６５７では、予算額の範囲内で絞り込みを行い、絞り込みの結果、商品が存在しなかった場合には、ステップ１６５９で予算額の再設定を行った上で再びステップ１６５７からやり直す。絞り込みの結果、商品が存在した場合には、ステップ１６６１で当店人気順で絞り込みを行う。この際には、人気の理由として、各ユーザが支持した機能の統計を取り集計結果を表示するようにしてもよい。あるいは、この当店人気順に代えて、若しくは当店人気順と共に当店お勧め順を提示し、この当店お勧め順に従って絞り込みをされてもよい。当店お勧めのポイントとしてそのお勧めの要点を指摘するようにしてもよい。お勧めのポイントの内からユーザ５に対して少なくとも一つを選択させることで絞り込みを行うようにしてもよい。なお、このように選択された属性や推奨要因を蓄積、集計すれば、企業にとっての開発に役立つ。ステップ１６６３では、ステップ１６５５で設定された機能に基づき絞り込みを行う。機能で絞り込みを行った結果、完全一致したものが存在した場合には、ステップ１６６５で商品の候補を表示する。ユーザ５はステップ１６６７で候補の内から一つを選択し、ステップ１６６９で購入をする。この際には、ステップ１６７１で値引き交渉が可能である。
一方、ステップ１６６３において、機能で絞り込みを行った結果、完全一致したものが存在しなかった場合には、ステップ１６７３で機能の一致した個数の多いもの順に候補を表示する。即ち、例えばユーザ５の希望した機能の個数が５であったとすると、この内４つの一致した商品をまず第１候補とし、３つの機能の一致したものを次の候補とする等である。同順位候補が複数存在してもよい。また、各機能にはユーザ５の重視する機能項目順に異なる評価点数をユーザ５が与えるようにし、候補表示に際しては評価点数の合計の大きい商品順に表示するようにしてもよい。更に、機能毎にユーザ５に対して必要とされる順に優先順位を番号で付けてもらい、この優先順位の高い項目を有する商品から先に候補とされるようにしてもよい。
また、ステップ１６７５では、図５５に示すように、ユーザ５により選択された機能の内、この商品にない機能とある機能とを表示する。ユーザ５により選択された機能の内いずれの機能がその商品にあって、いずれの機能が無いのか明確になることにより、ユーザ５は予算範囲で購入するに際して、その商品でよいかどうか簡単に判断できる。ステップ１６７７でユーザ５が候補の内から気に入って購入を希望する商品の一つを選択すると、ステップ１６７９で購入が行われ、ステップ１６８１で値引き交渉等が行われる。一方、ステップ１６７７でユーザ５にとって、購入を希望する商品が無かった場合には、ステップ１６８３で図５５に示す「予算額を１段上げる」ボタンをクリックすることで予算額を１段上げてステップ１６５７から再び処理を行う。
以上により、予算額の範囲内でユーザ希望の機能を完全、あるいはある程度満足し、定評のある商品の絞り込みをユーザが簡単に行えるようになる。
次に、本発明の第１５実施形態について説明する。本発明の第１５実施形態は、図１６のステップ８５、９１等で中間の提示額をユーザ５に対して提示する際に、ユーザ５が底値未満を希望購入価格として入力してきた場合であっても底値に近い値を出してきたらその分低い金額を提示額として提示しようとするものである。この理由として、ユーザ５は当該商品等の妥当な値段をよく研究している訳だからその分提示額も安くする必要があると判断されるからである。逆に底値よりはるかに下回る値段を出してきた場合には提示額に高い値段を提示してもかまわない。この理由として、ユーザ５は当該商品等の妥当な値段を研究していない訳だから（すなわち、その商品自体を研究していない訳であるから）その分値段を高くしてもかまわないと判断されるからである。
図５６には、希望販売価格Ｘ、提示価格の中でも最高額である最大提示価格Ｅｍａｘ、底値Ｙとの関係を示す。最大提示価格Ｅｍａｘは、前出の実数ｍ値を基に算出された提示価格である。そして、この図において、ユーザ希望入力価格Ｚ１が底値Ｙ未満で、かつ底値Ｙから相当程度離れている場合には提示価格Ｅ１も底値Ｙから相当程度離れており、一方、ユーザ希望入力価格Ｚ２が底値Ｙ未満で、かつ底値Ｙにより接近している場合には提示価格Ｅ２も底値Ｙにより近く設定されている様子を示す。
図５７は、ユーザ希望入力価格Ｚと底値Ｙの比率であるＺ／Ｙと提示価格値との間の関係を示したグラフである。数値例を基に具体的に説明する。今、最大提示価格を１１万円、底値Ｙを１０万円とする。そして、ユーザ希望入力価格が９万円までのとき（すなわちＺ／Ｙが０．９までのとき）、例えば図１６のステップ９１では１１万円が提示される。また、ユーザ希望入力価格が９万５千円のとき （すなわちＺ／Ｙが０．９５のとき）には１０万５千円が提示され、ユーザ希望入力価格が９万９千円のとき（すなわちＺ／Ｙが０．９９のとき）には１０万１千円が提示される。
これらの関係を一般式で表すと、αは倍率である（例えばα値は１０）。そして、
Ｚ／Ｙが0≦Ｚ／Ｙ＜１−１／αのとき最大提示価格Ｅｍａｘ
Ｚ／Ｙが１−１／α≦Ｚ／Ｙのとき
提示価格Ｅ＝α＊（Ｙ−Ｚ）／Ｙ＊（Ｅｍａｘ−Ｙ）＋Ｙ
グラフはαの値が小のとき傾斜は緩やか（感度鈍い）となり、一方、αの値が大のとき傾斜は急となる（感度敏感）。
なお、提示価格Ｅは、上記のように最大提示価格Ｅｍａｘと底値Ｙの間でもよいし、希望販売価格Ｘと底値Ｙの間とされてもよい。また、連続的な変化とせずに階段値とされてもよい。階段値を補完するようにしてもよい。リニアな変化ではなく所定の曲率を有して変化するようにしてもよい。
以上により、よく商品を知り尽くした人にはより安く購入させることでユーザ５の満足を得ることができる。
なお、上記の処理は、上述したように値引き交渉に利用可能であるとともに、第１１実施形態で述べたオークション的機能にも使用可能である。このとき、中間提示額は次第に下がっていくのでより一層のスリル感が期待できる。なお、商店等により底値が変更された場合には、改めてＺ／Ｙが算出された後、図５７のグラフに従って提示価格が算出される。ｍ値が変更されることで最大提示価格Ｅｍａｘが変わったような場合も同様である。
次に、本発明の第１６実施形態について説明する。本発明の第１６実施形態は他店よりも自店舗の方が商品等の販売価格が高かった場合であっても、ユーザからの依頼により可能な範囲で他店以下に値段を即時に下げることで販売を有利にするものである。
図５８にフローチャートを示す。図５８において、ステップ１７０１では、ユーザ５はインターネット接続されたパソコンにおいて、センターサーバ１００８に接続すると共にそのＷｅｂ上でユーザＩＤ、パスワードを入力する。そして、ステップ１７０３でＷｅｂ上に表示された商品等の中から購入を欲している商品を指定する。ステップ１７０５では、他店の店名、販売の期日、サイトのＵＲＬ、他店の属する県名、電話番号及び他店で幾らだったか（他店価格Ｕ円）等をＷｅｂの入力欄に入力してもらう。そして、ステップ１７０７では、「他店の方が安いよ」ボタンを押す。このことにより、ステップ１７０９では、データがセンターサーバ１００８に送信される。
そして、ステップ１７１１では、センターサーバ１００８で受信された他店のデータをデータベース１００９に蓄積する。この蓄積されたデータは、後で分析や参考に使用される。ステップ１７１３では、当該ユーザ５による商店等７でのこれまでの購入実績である合計金額がａ円以上であるか否か、若しくはお得意様ランクが所定水準以上であるか否かが判断される。
但し、センターサーバ１００８が貸し店舗形式を採用している場合には、ステップ１７１３の判断は、テナントとして入っている各商店等７毎に独自に判断されるのが望ましい。これは、他店より安く販売するという利益行為を特定のユーザに限って認めるためである。不特定多数に対し認める場合にはこれらの処理は不要である。判断の結果がＹＥＳの場合にはステップ１７１５に進む。
ステップ１７１５では、当該ユーザＩＤに対してこの商品についての交渉が初めてか否か判断される。複数回認めることは好ましくないからである。初めてのときにはステップ１７１７に進み、当該ユーザ５が値引き交渉可能回数をｎ回分以上有しているか否かが判断される。ｎ個は例えば少なくとも１回である。より慎重を期するため、値引き交渉可能回数を有する人だけに対し認めようとするものである。
ステップ１７１７で値引き交渉可能回数がｎ個以上存在していた場合には、ステップ１７１９に進み、Ｌ円＝他店金額Ｕ円−底値Ｙ円が演算される。底値Ｙ円は、当該商店等７が設定したこれ以下では販売が困難とされる価格である。そして、このＬ円が０円以上か否かが判断される。０円以上のときには、ステップ１７２１に進み、例えば（Ｕ−Ｙ）／ｍ１＋Ｙが演算される。但し、図１６の所で既に説明したように、値引き交渉の目安値の一般式はｍ１を実数として、（Ｕ−（１−ｍ１）Ｙ）／ｍ１であり、実数ｍ１や底値等は、各商店等７の希望若しくは任意により随時変更可能である。自動的に随時変動するように予めプログラムされてもよい。
更に、通常顧客、お得意様、上得意様の段階に応じて実数ｍ１を異ならせるようにしてもよい。但し、この数式に限定するものではなく、他店金額Ｕ円以下に設定されるように算出されればよい。そして、ユーザ５への提示金額は、底値Ｙ円以上となることが望ましいが、必ずしもこれに限定するものではなく、底値Ｙ円は、通常顧客、お得意様、上得意様の段階に応じて下げるように設定してもよい。また、割合ではなく、予め設定した所定の金額分だけ下げるようにされてもよい。更に、Ｌ円の大きさに応じて段階的に所定金額分ずつ下がるように設定されてもよい。
そして、このステップ１７２１で算出された価格は、ステップ１７２３においてユーザ５に対しＷｅｂを介して提示される。そして、「この値段ではどうですか？」と問い合わせがされる。ユーザ５は、ステップ１７２５において、この値段を見て購入若しくはキャンセルを選択する。その後、ステップ１７２７では、ユーザ５の有する値引き交渉可能回数が少なくとも１回分デクリメントされる。一方、ステップ１７１９でＬ円が負の場合には、ステップ１７２９で「当店ではこの値段ではきびしいです。」とメッセージを返す。
しかしながら、この際には、図１６の所で既に説明したのと同様に当店なりの実数ｍ２値に従った値段（（Ｘ−Ｙ）／ｍ２＋Ｙを演算）を提示し、「この値段ではどうですか」と問い合わせしてもよい（ステップ１７３０）。そして、ユーザ５は、ステップ１７３１において、この値段を見て購入若しくはキャンセルを選択する。その後、ステップ１７２７では、ユーザ５の有する値引き交渉可能回数が少なくとも１回分デクリメントされる。
一方、ステップ１７１３、ステップ１７１５及びステップ１７１７で、判断の結果がＮＯの場合にはステップ１７３３で電子メールが商店等７に対し配信される。これは、最終的な判断を商店等７に委ねることが望ましいためである。しかしながら、この際には、底値Ｙ円や実数ｍ１値やｍ２値を変えて提示されるようにしてもよい。即ち、ステップ１７２１で演算された値段よりも多少高い値段を設定する等である。
以上により、他店よりも自店舗の方が商品等の販売価格が高かった場合であっても、ユーザからの依頼により可能な範囲で他店以下に値段を即時に下げることが可能となる。このため、タイミングを逸しない効率的な販売が可能となる。なお、各実施形態においては、必ずしもインターネットを介在させる必要はなく、ＬＡＮ等であっても構成可能である。
また、センターサーバー１００８とは異なるＵＲＬを有する各商店等７の自前のホームページに対し、前述したセンターサーバー１００８のＵＲＬを埋め込んだアイコンを掲載し、このアイコンから前述した各機能若しくは当該機能を有するホームページにリンクするようにしてもよい。例えば、各商店等７のホームページには商品アイテムが掲載されているが、この商品を購入したいときには、ユーザ５がこの商品を購入する旨の購入ボタン（若しくは値引き交渉ボタン）をクリックする。この購入ボタンにはセンターサーバー１００８のＵＲＬが埋め込まれている。このことにより、各商店等７のホームページからユーザ５は直接前述した値引き交渉や現金還元等を始めとする各機能を利用することができるようになる。また、ボタンは、各機能毎に異なる名称や表示のボタンとされることが望ましい。そして、これらのボタンとセンターサーバー１００８の各機能とが直接リンクされることが望ましい。これにより、各商店等７は各実施形態で説明した諸機能を簡単に導入出来、販売促進につなげることが出来る。即ち、各商店等７の自前のホームページに埋設したアイコンをクリックすることでセンターサーバー１００８で提供する特定の機能（各実施形態で説明する機能）を直接呼ぶことができる。このリンクについては以下の各実施形態についても同様に適用可能である。
次に、本発明の第１７実施形態について説明する。本発明の第１２実施形態では、電子メールを送信することで特定の相手に対してのみ利用を限定するとして説明したが、本発明の第１５実施形態ではより厳格にユーザ５を特定することで、ユーザ５や各商店等７による不正な利用方法をできるだけ避けようとするものである。
ネットオークションやフリーマーケット等では互いの顔が見えない上に、センターサーバー１００８側ではユーザＩＤでのみ管理をしようとしているので、商品の提供者がユーザに成り済まして価格をつり上げる等の問題が生じている。かかる問題を解決するために各人を厳正に特定する必要がある。また、個人を特定できない状態であると、商品が届いても不払いされたり、支払を行ってもいつまで待っても商品が届かない等の状況が起こりやすい。更に、値引き交渉等の機能の利用者や利用回数を限定することが望ましい場合がある。そこで、商店等７やユーザ５をパソコンの固有情報やバイオメトリクス情報を基に各人を識別した上で各種サービスの利用を可能とする。
この機能を有する保護ソフトウェアはセンターのサイトにダウンロードソフトの形で提供されている。
まず、ユーザ５はこの保護ソフトウェアをダウンロードしてユーザ５の使用するパソコンにインストールする。保護ソフトウェアが起動されると、保護ソフトウェアは、パソコンのハードウェア情報やそのシステム情報、さらにパソコンにインストールされているソフトウェア情報等から、固有情報を検出しファイルＦ１としてユーザ５の使用するパソコンに保存するようになっている。
固有情報としては、例えばパソコン本体の情報、ＣＰＵの情報、ＰＣＩ情報、ＭＡＣアドレス、ハードディスクの情報、ＯＳ情報、メールアドレス、ＩＰアドレス、ＩＰｖ６アドレス（Internet Protocol version 6）、ｃｏｏｋｉｅ、ＳＣＳＩ情報、ソフトウェア又はファイルシステム情報等である。
そして、パソコン本体の情報としては、例えば富士通製パソコンならばＦＭＶＴ４２３Ｂ、ＮＥＣ製パソコンならばＰＣ９８２１Ｘａ１６Ｗ３０等のパソコン型式等であり、既存のハードウェア情報からソフトウェアで取得可能な情報である。ただし、この型式は必ずしもフル型式である必要はなく、ＰＣ９８２１、ＦＭＶ等の一部情報であっても良い。また、ハードディスクドライブの情報としては、例えばハードディスクドライブの容量や記憶されているソフトウェアの名称等である。
さらに、ＯＳ情報としては、例えばＷｉｎｄｏｗｓ（登録商標）９５のインストール時に設定されたユーザ名、プロダクトＩＤ番号、ＯＳのインストール実行日時等である。このＯＳのインストール実行日時を用いる場合には、例えばＯＳのインストールされた基本ドライブの各ディレクトリの更新日時を参照することで可能である。
また、固有情報としてメールアドレス、ＩＰアドレス、ｃｏｏｋｉｅ情報、ＳＣＳＩ情報等を用いる場合には、他のパソコン等でも同一となる可能性があるため、ハードウェア情報等と組み合わせて用いるのが望ましい。
このように、固有情報としては、あくまで本発明のために改めて記録され、用意されるものではなく、既存のハードウェアや、既存のシステム等から読み取り可能な情報であれば良い。そのため、様々なＯＳに対して（Ｗｉｎ９５〜ＸＰまで）固有情報を検出可能となっている。なお、固有情報には、別途機器を必要とするがメモリカード等の記録媒体に設定されたＩＤ情報や、バイオメトリクス情報等の情報を含めても良い。また、必ずしも既存から読み取り可能な情報に限定するものではなく、新規に改造や組み込み等されることで読み取りの可能となった情報等であっても良い。
さらに、固有情報としては、上記のように読み取り可能であっても、容易に変更可能なものは好ましくない。例えば、容易に、あるいは頻繁に部品の交換等が前提となっているものは好ましくない。
そして、保護ソフトウェアは、このような固有情報のうち、複数個の固有情報１〜Ｎ（番号１〜Ｎは各固有情報に対応する番号である）を検出するようになっている。このとき、固有情報１〜Ｎはハッシュ値化される。ただし、必ずしもハッシュ化せずにそのままデータとして使用されても良い。
さらに、これらの固有情報１〜Ｎに基づいて、ファイル類を暗号化、復号化するためのキーを生成するようになっている。なお、保護ソフトで検出する固有情報は、複数個が望ましいが、一つとされても良い。
その後、ユーザ５は、画面上でユーザ情報及びユーザＩＤやパスワード等の入力をする。そして、センターサーバー１００８に対してこの情報を送信することで登録申請を行う。なお、ユーザＩＤやパスワードはセンター側で自動発行されてもよい。そして、登録申請の際には、この登録申請情報がセンターサーバー１００８に送信されるとともに固有情報の保存されていたファイルＦ１も暗号化された形で送信される。
但し、ユーザ個人の特定はこの個人の使用するパソコンから得られた固有情報だけでもほぼ特定可能なので、ユーザＩＤやパスワード等は必ずしも必要なものではないが、センターにおける管理のし易さ及びより一層厳格な個人の特定を考慮して設けられている。
これらの登録申請情報と固有情報とはセンター側で復号化された上で保存される。そして、これらの情報を基にセンターサーバー１００８では、固有情報、ユーザＩＤ及び使用許可符号等を含むファイルＦ８を生成する。その後、センターサーバー１００８からはこのファイルＦ８がユーザ５のパソコンに向けて送信される。使用許可符号はユーザ５に対してセンター側で用意した機能の利用を認めるためのパスワード等である。ユーザ５側では保護ソフトウェアが受信したファイルＦ８の固有情報と既にファイルＦ１に保存されている固有情報とが一致するか否かを判断する。そして、一致していたら使用許可符号をファイルＦ８から抽出してファイルＦ１に保存する。
ユーザ５がサイトの機能を利用するに際しては、まず該当のサイトページを開く。その後、この保護ソフトウェアのパスワード入力ボタンをクリックする。但し、保護ソフトウェアの起動が自動でされるようにしてもよい。この際に、保護ソフトウェアは、ユーザ５のパソコンから固有情報及び／又はバイオメトリクス情報を取得し、ファイルＦ１に保存されている固有情報と一致するか否かを比較する。そして、一致するという結果であれば、自動的に保護ソフトウェア側よりＷｅｂ側にファイルＦ１から抽出したユーザＩＤ、パスワードが渡される。これにより、ユーザ５は、当該サイトの機能を利用することができるようになる。
この際には、Ｗｅｂのデータ入力欄に自動的にデータを入力するようにしてもよいが、直接データをユーザ５のパソコンからデータベース１００９側に対して送信するようにしてもよい。このことにより、ユーザＩＤ、パスワードが一致するユーザ５の保有する値引き交渉回数等がデータベース１００９にて判断できる。そして、ユーザ５を明確に特定できるため、ユーザ５に対して１回だけ若しくは数回だけサーバー側の機能の利用を認める等の行為を厳格に監視できる。なお、パソコンの固有情報であってもかなりの程度厳格な利用の監視は可能であるが、バイオメトリクス情報によれば、一層個人に対する厳格な利用の監視ができる。ユーザ５の情報はセンター側で認識されているので、各ユーザは不正な行為がし難くなる。また、ユーザＩＤ（パスワード）のみについてはユーザ５に入力してもらい、このユーザＩＤをセンターサーバー１００８に送信するようにしてもよい。このことにより、一層厳格な個人の特定が可能となる。また、ユーザＩＤに代えてメールアドレス等によってもよい。さらに、ユーザＩＤ、パスワードを送信せずに、送信される固有情報のみで本人を特定するようにされてもよい。
次に、本実施形態の別例について説明する。
保護ソフトウェアがユーザ５のパソコンにインストールされ、起動されると、パソコンの固有情報及び／又はバイオメトリクス情報が取得される。そして、登録申請の際にこの固有情報等と画面上でユーザ５により入力されたユーザ情報及びユーザＩＤ（パスワード）とがセンターサーバー１００８に送信される。センターサーバー１００８側では、データベース１００９にこの固有情報とユーザ情報データを保存しておく。そして、次にユーザ５がセンターサーバー１００８の機能を利用するためにログインしてきた場合には、固有情報等と画面上でユーザ５により入力されたユーザＩＤとがユーザ５のパソコンからセンターサーバー１００８に送信される。センターサーバー１００８側では受信されたユーザＩＤと固有情報とをセンターサーバー１００８に保存されていたデータと比較し、一致するか否かをみる。一致していたらユーザ５に対してセンターサーバー１００８側で用意した機能の利用を認める。なお、固有情報そのものを送信してセンターサーバー１００８側で保存したり、対比するのではなく、これらの固有情報を基に特定のロジックを基に一つのキーをユーザ５のパソコン側で生成し、登録申請の際にセンターサーバー１００８に送信する。センターサーバー１００８側では、このキーをデータベース１００９に保存しておき、再びこのキーがユーザ５のパソコンから送信されてきたときにこのキーに基づく対比を行うようにしてもよい。また、ユーザＩＤに代えてメールアドレス等によってもよい。さらに、ユーザＩＤを送信せずに固有情報を基に生成されたキーのみで本人を特定するようにされてもよい。
次に、本発明の第１７実施形態をクレジットカード支払やログインＩＤの入力に適用した例について説明する。
図９６は、カード情報やログインＩＤを本人特定のもとに使用可能とするものである。図９６では、本人特定をパソコンの固有情報によって行っている。即ち、予めユーザ５が登録を行ったパソコンでのみ認証が可能となるものである。従来のネット取引では、クレジットカード番号とカードの有効期限を入力するだけで認証を可能としていたが、これでは本人認証の機能を有しないので認証は確実ではなかった。また、暗証番号を入力させるようにしても本人特定の機能を有していない点は同様であり、取引の安全が確保されているとは言えなかった。
本例では、パソコン固有情報を本人の確認用に用いたため、カード利用の際に確実に本人を特定できる。なお、パソコンではなく、携帯電話の固有情報を取得するようにされてもよい。
図９６には、まず、ネット取引において、クレジットカードで支払をしようとする本人が利用するパソコンをセンター側に登録する処理について説明する。図９６のフローチャートにおいて、ステップ３５０１ではクレジットカードを利用しようとするユーザ５の有するパソコン（携帯電話でも同様）において保護ソフトウェアを起動する。この保護ソフトウェアは、予めユーザ５がセンターサーバー１００８よりダウンロードする等してユーザ５の有するパソコンにインストールされている。ステップ３５０３では、この保護ソフトウェアについて、インターネットエクスプローラやネットサーフィン等のブラウザとの関連付けを実施する。この関連付けは例えばブラウザに対し保護ソフトウェアの拡張子を関連付けすることで行う。但し、この保護ソフトウェアはこのようにブラウザと独立して構成されてもよいが、ブラウザと一体化して構成されてもよい。この場合には、ブラウザとの関連付けのステップはソフトウェアの機能としてもともと組み込まれた状態で構成されるので省略されてもよい。ステップ３５０５では、ユーザ５の有するパソコン（携帯電話等）の固有情報を取得する。ステップ３５０７では、この取得したパソコン固有情報をファイルＦ２に保存する。
ステップ３５０９では、ユーザ５がパソコンの画面上に表示された登録処理ボタンをクリックする。この登録処理ボタンは保護ソフトウェア側で生成された画面上に配設されているが、センターサーバー１００８よりダウンロードされたＨＴＭＬ文書に基づきＷｅｂ上で行うようにされてもよい。ステップ３５１１でセンター接続を行う。そして、ステップ３５１３でログインＩＤ、パスワード入力を行う。このログイン画面は、保護ソフトウェア側で生成した画面において行われても良いが、Ｗｅｂよりダウンロードする形でＨＴＭＬ上で行われても良い。
ステップ３５１５では、ログイン画面に続いてダウンロードされた画面に対し、本人情報（メールアドレスを含む）を入力し、ステップ３５１７でクレジットカード会社名、カード番号、有効期限を入力し、ステップ３５１９でカード用暗証番号を入力する。但し、カード用暗証番号の入力は不要とされてもよい。ステップ３５２１で、これらの情報をファイルＦ１に保存する。
続いて、ステップ３５２３では、保護ソフトウェアはファイルＦ２に保存されているパソコン固有情報を基に暗号化キーを生成する。そして、ステップ３５２５でこの暗号化キーを基にファイルＦ１を暗号化する。暗号化は例えば共通キー方式や公開キー方式が適用されている。ステップ３５２７では、ファイルＦ２を予め定めた固定のキーを用いて共通キー方式に従い暗号化する。ステップ３５２９では、ファイルＦ１、Ｆ２をセンターに向けて送信する。ステップ３５３１では、センターでこのデータを受信し、ステップ３５３３で復号化する。この復号化は、前述した暗号化の逆の手続による。ステップ３５３５でセンターデータベース１００９に受信したデータを保存する。ステップ３５３７では、念のため本人に対し登録完了の旨のメールを発信する。以上により、ログインＩＤやカード情報及び個人情報と、このユーザ５が使用するパソコンの情報とがセンターサーバー１００８に登録される。
次に、クレジットカードを利用してＷｅｂ上で支払する処理について図９７及び図９８を基に説明する。
図９７のステップ３５４１において、パラメータファイルには、ａ社サイトのＵＲＬ１及び保護ソフトウェア起動用命令が予め挿入されており、ダウンロード可能なようになっている。ａ社サイトは、例えば通信販売サイト等のクレジットカードでの支払の存在するサイトや、特定のログインＩＤでないと利用できないサイト等である。ステップ３５４３では、ユーザ５がユーザ５のパソコンにおいて、ａ社サイトよりＷｅｂページ（ログインページ）をダウンロードする。ステップ３５４５において、ログインＩＤ、パスワードを入力し、ステップ３５４７でこのログインページをセンターに向けて送信する。ステップ３５４９では、センター側でこの送信されたデータを受信する。ステップ３５５１では、ログインＩＤ、パスワードをセンターサーバー１００８において取得する。
続いて、ステップ３５５３では、ログインページにリンクされた情報入力ページがダウンロードされる。この情報入力ページについて、ステップ３５５５で本人情報（メールアドレスを含む）を入力する。そして、続いてステップ３５５７でカード会社、カード番号、有効期限を入力し、ステップ３５５９でカード用暗証番号を入力する。但し、カード用暗証番号の入力は不要とされてもよい。また、後述するように、情報の入力はユーザ５に対し登録時のみ行ってもらい、その後の処理はセンターサーバー１００８に保存されたデータ情報を用いることで入力を省略するようにされてもよい。
ステップ３５６１では、これらの情報を暗号化し、ステップ３５６３でセンターに対しデータ送信する。
一方、ステップ３５６５では、受信されたデータの中からログインＩＤを取得し、ステップ３５６７でパラメータファイルにこのログインＩＤを挿入する。ステップ３５６９では、センターよりユーザ５のパソコンに対しこのパラメータファイルをダウンロードする。パラメータファイルのダウンロードは、例えばＷｅｂページ（ログインページ）のＨＴＭＬソースにこの旨の命令を記載しておくことで行う。ステップ３５７１では、ユーザ５のパソコンでパラメータファイルを受信する。このとき、ステップ３５７３でブラウザを介し、パラメータファイルに含まれる保護ソフトウェアの起動命令が実行される。
その後、ステップ３５７５では、起動した保護ソフトウェアによりパソコン固有情報が自動で取得される。そして、ステップ３５７７でファイルＦ２に保存されている固有情報と一致しているか否かが判断される。一致している場合には、ユーザ５本人が登録の際に使用したパソコンと同一のものなので、本人と認めることができる。このため、ステップ３５７９に進み、センターへ向けてａ社サイトのＵＲＬ１、固有情報、ログインＩＤを送信する。一方、ステップ３５７７でファイルＦ２に保存されている固有情報と一致していないと判断されたとき、ステップ３５８０でエラー表示を行う。登録時のパソコンの情報と異なるためである。但し、この固有情報の対比は厳正に一致するか一致しないかで判断されてもよいが、それぞれの固有情報に対し重み付けの点数を設定し、該当する固有情報が存在した場合にはその点数を加算し、一方存在しない場合には０点としてその重み付けの合計点数をまず算出し、その合計に対するすべての固有情報が一致した場合の重み付けの度合いを評価するようにされてもよい。
ステップ３５７９で送信されたデータはステップ３５８１でセンターにおいて受信される。そして、ステップ３５８３では、次のＷｅｂページ（例えば認証確認待ち状態ページ）をダウンロードする。ステップ３５８５では、センターにおいてログインＩＤ、パスワードの一致を判断する。これは、ステップ３５５１からステップ３５６３までの処理ルートで送信されたデータの登録者と、ステップ３５６５からステップ３５８０までの処理ルートで送信されたデータの登録者とが一致することをセンター側で確認するためである。
一致するデータが存在した場合には、ステップ３５８７でセンターサーバー１００８のデータベース１００９にアクセスする。そして、ステップ３５９１で受信データからカード情報を抽出する。一方、一致しなかった場合にはステップ３５８９で認証不許可とする。この場合には、カードでの決済が認められない。ステップ３５９１で抽出されたカード情報は、ステップ３５９３でセンターデータベース１００９に登録済のデータと一致するか否かが判断される。一致したデータの存在する場合には、ステップ３５９５に進み、登録済のパソコン固有情報が存在しているか否かが判断されさる。そして、ステップ３５９９で受信された固有情報が登録済のパソコン固有情報と一致している場合には、ユーザ５本人のパソコンであると認められる。ステップ３６０３では、ａ社サイトのＵＲＬ１が一致しているか否か判断され、一致している場合は、ステップ３６０５で認証が許可される。このとき、センターサーバー１００８側では、ａ社サイトにおいてユーザ５が購入等をしたものと判断できる。但し、ａ社サイトが同時にセンターサーバー１００８としての機能を有する場合にはこのサイトのＵＲＬの判断は不要である。
一方、ステップ３６０３で一致していない場合には、ステップ３６０７で認証は許可されない。また、ステップ３５９３の判断で、カード情報がセンターデータベース１００９に登録済のデータと一致しない場合には、ステップ３５９７で認証は許可されない。但し、ステップ３５９５で登録済のパソコン固有情報が存在しない場合には、ユーザ５がカード情報のみで（パソコン固有情報によることなく）カード決済を希望していると判断されるので、そのままステップ３６０１で認証を許可する。
以上により、パソコンや携帯電話等の固有の情報を基に本人確認をした上でカード決済やログインＩＤの使用が可能なので、カード使用の際の安全性が向上する。
なお、ａ社サイトとセンターサーバー１００８とは同一のサイトとして構成されてもよいし、異なるサイトとして構成されることも可能である。同一のサイトとして構成された場合には、ａ社サイトのＵＲＬ１の情報は不要とされてもよい。異なるサイトとして構成された場合には、ユーザ５により申請のあったログインＩＤ、パスワードの情報、本人情報、カード情報等及び購入のあった商品名、商品コード、金額等をａ社サイト側よりセンターサーバー１００８に向けて送信してセンターサーバー１００８側でオーソリ認証を行う必要がある。また、オーソリ認証の結果をセンターサーバー１００８側よりａ社サイト側にデータ送信するために必要なソフトウェアがａ社サイト側に導入される必要がある。但し、オーソリ認証の結果は、センターサーバー１００８側でａ社に対し閲覧可能にＷｅｂ上で公開されるようにされてもよい。
なお、異なるサイトとして構成された場合の別構成として、ユーザ５により申請のあったログインＩＤ、パスワードの情報、本人情報、カード情報等及び購入のあった商品名、商品コード、金額等をパラメータファイルに挿入した上でダウンロードさせたり、ＨＴＭＬ文書として引き継ぐように処理されてもよい。
更に、ログインＩＤは省略することも可能である。この場合、センターサーバー１００８側では、固有情報の一致とカード番号の一致等の組み合わせで本人のカード使用であることを確認可能である。
また、これとは逆に本例の中からログインＩＤを残し、カード情報（や本人情報）を不要とすることも可能である。即ち、ログインＩＤの入力に際して、パソコンの固有情報が一致したものにだけログインが有効となるというような形で利用可能である。
次に、本人確認をバイオメトリクス情報により行う場合について図９９及び図１００のフローチャートを基に説明する。但し、バイオメトリクス情報に代えてＩＣタグから電磁波を介して得た情報を用いるようにしても良い。バイオメトリクス情報の例として指紋について説明するが、本人認証のために指紋、筆跡、声紋、網膜（眼底の毛細血管の模様を用いる）、虹彩、手の大きさや形、手のひらの紋様、手の甲の血管、顔の形（２次元位置データとして照合、３次元計測による照合）、キーストローク、マウス操作の癖、遺伝子情報等によるバイオメトリクス情報を用いてもよい。また、バイオメトリクス情報を用いる以外にも、本人確認データとしてスマートメディア、メモリスティック、ＳＤカード等のように、個別認証の可能なＩＤ付記録媒体等を用るようにしてもよい。これらのＩＤ付記録媒体には、予め各記録媒体を識別するための認証符号ＩＤが付与された形で記録媒体内に記憶されている。
図９９の登録処理において、図９６と同一のステップについては同一の符号を付して説明を省略する。ステップ３６５１においては、指紋情報等のバイオメトリクス情報を指紋入力装置等より取得する。ステップ３６５３では、指紋データの内から、この指紋を特徴付ける特徴データを抽出する。この特徴データは、サンプリングされたデータや例えば指紋を特徴付ける箇所数点の位置関係情報等である。そして、この特徴データをステップ３５２１でファイルＦ１に保存する。ステップ３６５５では、パソコン固有情報を基に生成された暗号化キーを利用して本人情報及びカード情報を暗号化する。そして、この本人情報及びカード情報をステップ３６５７でファイルＦ１、Ｆ２と共にセンターに送信する。
次に、バイオメトリクス情報を用い、クレジットカードを利用してＷｅｂ上で支払する処理について図１００を基に説明する。なお、図９７及び図９８と同一要素の部分については同一の符号を付して説明を省略する。また、図１００のフローチャートは、図９７及び図９８と同一の処理フローの部分については省略をしている。即ち、図９７のステップ３５７３以降の処理フローを抜粋し、かつ図９７及び図９８と異なる所を中心に説明する。
図１００のステップ３５７３において、保護ソフトウェアが起動されるとステップ３５７５で固有情報が取得され、ステップ３５７７でファイルＦ２に保存されている固有情報と比較される。一致していたら、ユーザ５所有のパソコン等であると判断され、ステップ３７０１に進み、指紋情報等のバイオメトリクス情報を取得する。そして、ステップ３７０３で、特徴データを抽出し、ステップ３７０４でファイルＦ１に保存された特徴データと一致するか否か判断される。一致しない場合にはステップ３５８０でエラーとなる。一方、特徴が一致した場合には、ステップ３７０５でこのファイルＦ１に保存された特徴データを基に暗号化キーを生成する。特徴の一致は完全一致の他、特徴が近似範囲に属すると判断されるものも含む。暗号の方式は共通キー方式や公開キー方式等である。この暗号化キーは、例えば、特徴データをシリアルに並べ、そのうちからサンプリングしたデータを一定のルールに従い並べ替えることで生成したり、この特徴データのシリアルを所定の論理式に従い演算した結果の数値を用いることで生成する。ステップ３７０７では、この暗号化キーを基にパソコン固有情報を暗号化し、ステップ３７０９でセンターへこのパソコン固有情報データを送信する。
センター側では、ステップ３５９１で受信データからカード情報を抽出し、ステップ３５９３でこのカード情報がセンターデータベース１００９に登録済のデータと一致するデータがあると判断されたとき、ステップ３５９５でセンターデータベース１００９に既に登録済の固有情報が存在するか否か判断される。そして、存在する場合にはステップ３７１１で、センターデータベース１００９に登録された特徴データを基に復号化キーを生成する。ステップ３７１３では、この復号化キーを基にパソコン固有情報を復号化する。ここで、復号化ができれば、本当に本人が認証を請求していると判断できる。固有情報が登録済のパソコン固有情報と一致すれば本人使用のパソコンであると判断できる。
なお、上述した処理に代えて、図示は省略するが、ステップ３５２３においては、ファイルＦ１に保存されたバイオメトリクス情報の特徴データを基に暗号化キーを生成することも可能である。この場合、ステップ３５２５では、この暗号化キーを基にファイルＦ２を暗号化し、ステップ３６５５では、この暗号化キーを基に本人及びカード情報を暗号化する。ステップ３５２７では、ファイルＦ１を共通キー方式で暗号化する。
この場合には、ステップ３５７３で保護ソフトウェアが起動すると、まず、指紋等のバイオメトリクス情報を取得し特徴データが生成される。そして、この特徴データがファイルＦ１に保存されているデータと一致するか否か判断される。一致している場合には、ファイルＦ１の特徴データを基に復号化キーが生成され、この復号化キーを用いてファイルＦ２が復号化される。その後、パソコン固有情報が取得され、ファイルＦ２に保存されている固有情報と一致しているか否か判断される。一致している場合にはファイルＦ１を基に暗号化キーが生成され、この暗号化キーを用いてファイルＦ２が暗号化される。その後、ステップ３７０９以降に進むように処理されてもよい。
また、上述した処理に代えて、図示は省略するが、本人及びカード情報を暗号化するのがファイルＦ１のバイオメトリクス情報の特徴データを基としてキー生成された暗号化キーで行われた場合において、このファイルＦ１のバイオメトリクス情報の特徴データをファイルＦ２のパソコン固有情報を基としてキー生成された暗号化キーで行われるようにされてもよい。
更に、暗号化の順序を本人及びカード情報を暗号化するのをファイルＦ２のパソコン固有情報を基としてキー生成された暗号化キーで行うこととし、ファイルＦ２のパソコン固有情報をファイルＦ１のバイオメトリクス情報の特徴データを基としてキー生成された暗号化キーで行われるようにされてもよい。
更に、本人及びカード情報については、ユーザ５のパソコンからセンターサーバー１００８に対し送信するだけなので、ネット取引によく使用されているＳＳＬ方式による暗号化がされるようにしてもよい。
更に、ステップ３５９９では、パソコン固有情報の一致を判断したが、これに代えてバイオメトリクス情報の特徴データが一致するか否かを判断するようにしてもよい。このときは前述の処理に代えてステップ３７０５では、ファイルＦ２のパソコン固有情報を基に暗号化キーを生成する。そして、ステップ３７０７では、この暗号化キーを基にファイルＦ１のバイオメトリクス情報の特徴データを暗号化する。ステップ３７０９では、センターへこの特徴データを送信する。その後、ステップ３５９５では、登録済みのバイオメトリクス情報の特徴データが存在するか否か判断される。そして、ステップ３７１１では、センターデータベース１００９に登録された固有情報を基に復号化キーが生成される。ステップ３７１３では、この復号化キーを基にファイルＦ１のバイオメトリクス情報の特徴データが復号化される。そして、ステップ３５９９では、受信されたバイオメトリクス情報の特徴データが登録済みの特徴データの中に一致するデータがあるか否か判断される。
更に、上述では、暗号化をパソコン固有情報又はバイオメトリクス情報の特徴データを基にする旨説明したが、予め定めた特定のキーを基に共通化キー方式や公開キー方式にて処理されるようにされてもよい。
更に、ファイルＦ１及び／又はファイルＦ２は、登録時及びカード利用時共に、ユーザ５のパソコンにおいて、生成したら送信してしまい、ユーザ５のパソコンにデータとして残さないようにしてもよい。この際には、センターサーバー１００８側にてパソコン固有情報又はバイオメトリクス情報の特徴データの一致を判断することで本人確認の処理が行われる。この場合、ステップ３５７７とステップ３７０４の一致判断は不要となる。
このとき、固有情報、バイオメトリクス情報や特徴データはユーザ５のパソコンに残らないのでパソコンが盗まれたとしても安全である。このため、犯罪の一手法として他人の手指を切断してその指紋を利用する等の犯罪は出来なくなる。更に、指紋データ等そのものを保存しておいたり送信することはないので指紋データ等が盗まれることもなく安全である。フィッシング詐欺をしてカード情報を盗んだとしても利用出来なくなる。
なお、ファイルＦ２については、登録時及びカード利用時共にユーザ５のパソコンに残し、カード利用時に、保護ソフトウェアの取得した固有情報データとファイルＦ２に保存された固有情報の一致を判断する。その後、この一致を見てからバイオメトリクス情報を取得し、ファイルＦ１を生成して送信する。センターサーバー１００８では、パソコン固有情報及び／又はバイオメトリクス情報の特徴データの一致（近似を含む）を判断する。かかる方法とした場合には、送信側での固有情報による本人確認、受信側での固有情報やバイオメトリクス情報の特徴データによる本人確認が行える上に、バイオメトリクス情報の特徴データはユーザ５のパソコンに残らないので望ましい。なお、バイオメトリクス情報の特徴データについては、バイオメトリクス情報そのものと置き換えられることも可能である。
以上により、バイオメトリクス情報とパソコン固有情報を用い、本人であること、及び予め登録のあったパソコンでの使用を条件にクレジットカードの認証を厳格に行うことができる。但し、バイオメトリクス情報の特徴データを暗号化キーや復号化キー生成のために利用するのではなく、バイオメトリクス情報そのもののデータ、若しくはバイオメトリクス情報の特徴データについて、センターサーバー１００８において既に登録時において保存されているこれらのデータと、カード利用時にユーザ５から送信されたこれらのデータとを対比し、一致するか否かを判断することで本人確認がされてもよい。
次に、本人確認を固有情報とバイオメトリクス情報の特徴データとからシリアル番号を作ることにより行う場合について図１０１、図１０２及び図１０３のフローチャートを基に説明する。但し、バイオメトリクス情報に代えてＩＣタグから電磁波を介して得た情報を用いるようにしても良い。
なお、図９６、図９７及び図９８と同一処理の部分については同一の符号を付して説明を省略する。また、図１０２及び図１０３は、図９７及び図９８と同一の処理フローの部分については簡略のためステップ自体を省略をしている。即ち、図９７のステップ３５７３以降の処理を抜粋し、かつ図９７と異なる所を重点的に説明する。
図１０１において、ステップ３７５１では、指紋情報等のバイオメトリクス情報を取得可能か否かが判断される。そして、バイオメトリクス情報を取得可能な装置が存在している場合には、ステップ３７５３で指紋情報等のバイオメトリクス情報を取得し、ステップ３７５５で特徴データを抽出する。ステップ３７５６では、この特徴データをファイルＦ２に保存する。ステップ３７５７では、ファイルＦ２に保存された固有情報と特徴データを基に所定のロジックに従いシリアル番号を生成する。この所定のロジックは、例えば予めサンプリング的に一定数毎にデータを抽出し、この抽出したデータをシリアルに連続して並べて一つの番号を作成する等である。そして、生成したシリアル番号をステップ３５２１でファイルＦ１に保存する。
一方、ステップ３７５１で指紋情報等のバイオメトリクス情報を取得出来ないと判断された場合には、ステップ３７５９に進み、ファイルＦ２に保存された固有情報と特定の数値を基に所定のロジックに従いシリアル番号を生成する。この特定の数値は、特徴データの代わりに予め定めた数値を準備したものである。所定のロジックはステップ３７５７のものと変わらないものでよい。
そして、生成したシリアル番号をステップ３５２１でファイルＦ１に保存する。
このシリアル番号は、バイオメトリクス情報と固有情報とから生成されており、バイオメトリクス情報や特徴データそのもののデータではないので通信途上でデータが盗まれたとしても安全である。また、バイオメトリクス情報だけで認証するものではないので、犯罪の一手法として問題となっている他人の手指を切断してその指紋を利用する等の犯罪は出来なくなる。フィッシング詐欺をしてカード情報を盗んだとしても利用出来なくなる。
但し、バイオメトリクス情報と固有情報との双方のデータを利用するのではなく、バイオメトリクス情報の特徴データだけを用いて所定のロジックに従いシリアル番号を生成するようにしてもよい。この場合であっても、バイオメトリクス情報の特徴データそのもののデータではないので通信途上でデータが盗まれたとしても安全である。なお、ステップ３５２３の処理は、パソコン固有情報ではなく、パソコン固有情報及び／又は特徴データを用いて暗号化キーを生成するようにしてもよい。
次に、シリアル番号を用い、クレジットカードを利用してＷｅｂ上で支払する処理について図１０２及び図１０３を基に説明する。なお、図９７及び図９８と同一要素の部分については同一の符号を付して説明を省略する。また、図１０２及び図１０３のフローチャートは、図９７及び図９８と同一の処理フローの部分については省略をしている。即ち、図９７及び図９８のステップ３５７３以降の処理フローを抜粋し、かつ図９７及び図９８と異なる所を中心に説明する。
登録処理と同様に、ダウンロードされたＨＴＭＬ文書に連動してステップ３５７３において保護ソフトウェアが起動されると、ステップ３５７５でパソコン固有情報が自動で保護ソフトウェアにより取得される。また、ステップ３７５１でバイオメトリクス情報を取得可能ならば、ステップ３７５３でバイオメトリクス情報が取得され、ステップ３７５５で特徴データが抽出される。そして、ステップ３７６０において、この特徴データとファイルＦ２に保存されている特徴データとが対比される。一致していなければステップ３７６０でエラーとなり、一致していれば、その後、ステップ３７５７において、ファイルＦ２に保存された固有情報と特徴データを基に所定のロジックに従いシリアル番号が生成される。
一方、ステップ３７５１でバイオメトリクス情報を取得可能でないならば、ステップ３７５９でファイルＦ２に保存された固有情報と特定の数値との間でシリアル番号が生成される。そして、ステップ３８０１では、この生成されたシリアル番号がファイルＦ２に保存された固有情報を基に暗号化される。そして、次にステップ３８０３でファイルＦ２が共通化キー方式で暗号化される。ステップ３８０５では、シリアル番号とファイルＦ２とがセンターに向けて送信される。
センター側でこれらのデータを受信した後、ログインＩＤの一致とカード情報の一致とが判断される。その後、ステップ３５９５で既に登録済のパソコン固有情報が存在するか否か判断される。登録済のパソコン固有情報が存在しない場合には、ユーザ５がカード情報のみでカード決済を希望していると判断されるので、そのままステップ３６０１で認証を許可する。但し、ここでは、既に登録済のシリアル番号が存在するか否かで判断されるようにしてもよい。続いて、ステップ３８０７では、ファイルＦ２を共通化キー方式のもとに復号化する。そして、ステップ３８０９では、ファイルＦ２に保存された固有情報を基に復号化キーを生成し、ステップ３８１１でこの復号化キーを基にシリアル番号を復号化する。
その後、ステップ３５９９でパソコン固有情報の一致が判断され、ステップ３８１３では、受信されたシリアル番号が登録済のシリアル番号と一致するか否か判断される。シリアル番号が一致する場合には、ステップ３６０３に進み、一方、一致しない場合にはステップ３６０７で認証は許可されない。
以上により、シリアル番号は、バイオメトリクス情報と固有情報とから生成されており、ユーザを確実に特定可能である。また、バイオメトリクス情報や特徴データそのもののデータではないので通信途上でデータが盗まれたとしても安全である。
次に、別例として、登録済みのデータのあることを保証するシリアル番号をセンターサーバー１００８側で生成し、このシリアル番号を一旦ユーザの所有するパソコン等に保存しておき、クレジットカード等を使用する際にこのシリアル番号を参照することで本人確認をする方法について図１０４〜図１０８を基に説明する。
なお、図９６、図９７と同一の要素については同一の符号を付して説明を省略する。
図１０４において、保護ソフトウェアをインストールし、ステップ３５０９で登録ボタンをクリックする。但し、この登録処理は、インストールに続けて行っても良いし、保護ソフトウェアの再起動後に行うようにされてもよい。ステップ３５１３では、ログインページが表示され、ステップ３５１５では、この表示されたログインページに入力を行う。そして、ステップ３８５１ではセンターに向けてログイン情報の送信がされる。ステップ３８５３では、センターのデータベース１００９中にログインＩＤ、パスワードの一致するものがあるか否か判断される。
ログインＩＤ、パスワードの一致するものが存在しない場合には、ステップ３８５５で新規登録となり、ステップ３８５７以降の登録処理が行われる。新規登録が行われない場合には、ステップ３８５９で処理を終了する。一方、ステップ３８５３で既に、センターのデータベース１００９中にログインＩＤ、パスワードの一致するものがあった場合には、ステップ３８６１に進み追加処理が行われる。追加を希望しない場合には、ステップ３８６３において、登録済みのデータが表示される。
新規登録又は追加の場合には、ステップ３８６５でクレジットカード会社名、クレジットカード番号、暗証番号、有効期限、個人情報入力ページにデータを入力する。但し、センターサーバー１００８側において、既にクレジットカードに関する情報が存在しているような場合には、例えばクレジットカード番号のみが入力されるようにしてもよい。そして、ステップ３８６７で入力されたデータをファイルＦ１に保存する。その後、ステップ３８６９では、パソコン固有情報を基に暗号化キーを生成し、ステップ３８７１でこの暗号化キーを利用してファイルＦ１を暗号化する。
また、ステップ３８７３ではファイルＦ２を共通キー方式で暗号化する。そして、ステップ３８７５でセンターへ送信する。ステップ３８７７では、これらのデータをセンターで受信する。ステップ３８７９では、ファイルＦ２を復号化し、ステップ３８８１でファイルＦ２に保存されていたパソコン固有情報をセンターデータベース１００９に保存する。ステップ３８８３では、ファイルＦ１を復号化できたか否かが判断される。復号化できなければ、ステップ３８８７でエラーとされ、一方復号化出来たならば、ステップ３８８５でファイルＦ１より抽出したクレジットカード番号等をセンターデータベース１００９に保存する。その後、ステップ３８８９では、固有のシリアル番号を自動生成し、ステップ３８９１でファイルＦ８の中にこのシリアル番号を入れると共にセンターデータベース１００９にも保存をする。固有のシリアル番号は、最低限各パソコンを区別出来ればよく登録順に任意に割りつけた符号等とされてもよい。但し、ログインＩＤ等のデータと共にシリアル化されてもよい。
ステップ３８９３では、センターデータベース１００９に保存の固有情報を取得し、ファイルＦ９を生成し、このファイルの中に固有情報を保存する。ステップ３８９５では、ファイルＦ８、Ｆ９を暗号化してユーザ５の有するパソコンに送信する。そして、ステップ３８９７では、ユーザ５の有するパソコンにおいて、ファイルＦ２とＦ９のパソコン固有情報が一致するか否かが判断される。そして、一致していたならば、ステップ３８９９でシリアル番号をファイルＦ８より抽出してファイルＦ１に保存する。一方、一致しなかったときはステップ３９０１でエラーとする。
次に、ユーザがクレジットカードを利用する際のフローについて図１０６、図１０７及び図１０８を基に説明する。以下、パラメータファイルには、保護ソフト起動用命令を予め挿入しているとして説明するが、パラメータファイルには、商品コード、サイト情報、保護ソフト起動用命令を予め挿入するようにしてもよい。
図１０６、図１０７及び図１０８において、ステップ３９５１では、ＨＴＭＬ文書（例えば商品購入における購入ページ）をダウンロードする。ステップ３９５３では、このＨＴＭＬ文書のログインＩＤ、パスワード入力部がユーザ５のパソコン等に表示される。ステップ３９５５では、ユーザ５がこのパスワード入力部に対しデータ入力を行い、ステップ３９５７で送信する。その後、ステップ３９５８では、センターサーバー１００８において受信されたＨＴＭＬ文書中よりログインＩＤ、商品コード、サイト情報を抽出してパラメータファイルに挿入する。
ステップ３９５９では、このパラメータファイルをダウンロードし、ステップ３９６１で保護ソフトウェアを起動する。そして、ステップ３９６３でこの保護ソフトウェアがユーザ５のパソコンにおいてパソコン固有情報を取得する。続いて、ステップ３９６５でファイルＦ２を共通キー方式で復号化する。ステップ３９６７では、パソコン固有情報の一致を判断し、一致していないときにはステップ３９７１でエラー表示する。一方、一致しているときには、ステップ３９６９でファイルＦ２のパソコン固有情報を基に復号化キーを生成する。
そして、この復号化キーを基にステップ３９７３でファイルＦ１を復号化する。ステップ３９７５では、パラメータファイルよりログインＩＤ、サイト情報、商品コードを取得し、ステップ３９７７では、ファイルＦ１中にこのログインＩＤ、サイト情報、商品コードと記録日時とを記録する。但し、サイト情報に代えて特定の異なるデータとして生成された符号がその都度発行されるようにしてもよい。
その後、ステップ３９７９では、ファイルＦ２のパソコン固有情報を基に暗号化キーを生成し、ステップ３９８１で、この暗号化キーを用いてファイルＦ１を暗号化する。ステップ３９８３では、ファイルＦ２を共通キー方式で暗号化する。ステップ３９８５では、これらのファイルＦ１、Ｆ２をセンターに送信し、ステップ３９８７では、センターで受信をする。
その後、センターサーバー１００８側では、ステップ３９８９においてファイルＦ２をまず共通キー方式で復号化する。ステップ３９９１では、このファイルＦ２のパソコン固有情報を基に復号化キーを生成し、ステップ３９９３でファイルＦ１を復号化する。そして、ステップ３９９５では、サイト情報、シリアル番号、ログインＩＤ、商品コード等を抽出する。ステップ３９９６では、抽出したデータをセンターサーバー１００８のメモリー内に保存する。
一方、ステップ４００１では、センターサーバー１００８に送信されたＨＴＭＬ文書中よりログインＩＤ、パスワード、商品コード、サイト情報を引き継ぐ。ステップ４００３では、センターデータベース１００９中にログインＩＤ、パスワードの一致するデータがあるか否か判断される。一致するデータが存在しない場合には、ステップ４００５で終了する。あるいは、新規登録画面に進む。そして、ステップ４００７では、情報再入力省略モードの設定がされているか否か判断する。情報再入力省略モードの設定は、改めてクレジットカード等の情報を入力させるユーザ５の手間を省略させるため、及びクレジットカードの情報の漏洩防止のために設けられている。なお、この情報再入力省略モードの設定は、本例以外でも同様に適用可能である。
情報再入力省略モードの設定がされていない場合には、ステップ４００９でクレジットカード会社名、クレジットカード番号、有効期限、暗証番号入力、個人情報入力画面が表示される。ステップ４０１１では、この画面に対しデータ入力を行い、ステップ４０１３で送信する。このデータはステップ４０１５で受信される。ここに、ステップ４０１７において、ユーザ５が複数回のデータ入力を繰り返し行おうとしても安全確保のため許可されない。
ステップ４０１９で入力データの一致が判断され、一致していなければステップ４０２３で認証は許可されない。ステップ４０２１では、暗証番号の判断が可能なものにあっては、暗証番号の一致が判断される。そして、暗証番号が一致しない場合にはステップ４０２３で認証は許可されない。
一方、暗証番号が一致した場合には、ステップ４０２５に進み、データベース１００９中に当該ログインＩＤについてシリアル番号の登録があるか否かが判断される。データベース１００９中にシリアル番号の登録が無かった場合には、個人認証の判断をしない状態のままステップ４０２７で認証が許可される。シリアル番号の登録が無い以上、ユーザ５がカード決済の上で個人認証の判断までは必要無いと判断していると考えられるためである。
一方、データベース１００９中にシリアル番号の登録が存在する場合には、ステップ４０２９に進み、ステップ３９９６においてメモリーに保存されたデータと対比が行われ、このメモリーの中に当該ログインＩＤに一致するデータが存在するか否か判断される。存在しない場合には、まだステップ３９８７での受信がされていない状況の可能性もあるので、ステップ４０３１でタイマーのカウントを行い、ステップ４０３３で設定時間を超えたか否かが判断される。この設定時間までは、保護ソフトウェアからのデータ送信を待つためである。そして、設定時間を超えた場合にはステップ４０３５で認証は許可されない。一方、設定時間に満たない場合には、ステップ４０２９からの処理が繰り返される。
メモリーの中に当該ログインＩＤに一致するデータが存在する場合には、ステップ４０３７でサイト情報が一致しているか否か判断される。但し、この判断は、商品購入したサイトとセンターサーバー１００８のサイトとのＵＲＬが異なる場合において行われ、同一の場合にはサイト情報の判断自体省略可能である。サイト情報が一致していない場合には、データベース１００９中に他に一致するものが存在する可能性があるので、ステップ４０３９でデータベース１００９中のサイト情報をサーチする。ステップ４０４１で一致するデータが見つからなかった場合には、まだステップ３９８７での受信がされていない状況の可能性もあるので、ステップ４０３１でタイマーのカウントを行い、ステップ４０３３で設定時間を超えたか否かが判断される。
サイト情報の一致したデータが存在した場合には、ステップ４０４３に進み、メモリー中に保存されたデータとデータベース１００９に保存されたデータとの間で、商品コードの一致が判断される。商品コードが一致するものが存在しなかった場合には、ステップ４０４５でデータベース１００９中の商品コードをサーチする。ステップ４０４７で一致するデータが見つからなかった場合には、まだステップ３９８７での受信がされていない状況の可能性もあるので、ステップ４０３１でタイマーのカウントを行い、ステップ４０３３で設定時間を超えたか否かが判断される。
商品コードの一致したデータが存在した場合には、ステップ４０４９に進み、
データベース１００９に保存のシリアル番号と対比される。対比の結果、一致している場合にはステップ４０５３に進みカードの有効期限が判断される。シリアル番号が一致しない場合や有効期限を超えている場合にはステップ４０５１で認証は許可されない。ステップ４０５３でカードが有効期限内のときにはステップ４０５５で認証が許可される。
なお、図１０４〜図１０８の例では、パソコン固有情報のみを用いて説明したが、上述したバイオメトリクス情報を用いた例のように、パソコン固有情報とバイオメトリクス情報との組み合わせに対しシリアル番号を発行してもよい。このとき、ユーザ５のパソコンにおいて、カード利用時には、パソコン固有情報の一致を見ると共にバイオメトリクス情報の一致を見ることが望ましい。あるいは、パソコン固有情報の代わりにバイオメトリクス情報を用い、これに対しシリアル番号を発行するようにされてもよい（図示略）。このとき、ユーザ５のパソコンにおいて、カード利用時には、バイオメトリクス情報の一致を見ることが望ましい。
次に、本発明の第１８実施形態について説明する。本発明の第１８実施形態を図５９及び図６０のフローチャートを基に説明する。本発明の第１８実施形態は、ユーザ５がセンターサーバー１００８に入り、センターサーバー１００８側で用意された各機能を利用する場合には、ログインＩＤとパスワードとが必要とされるが、このログインＩＤを忘れた場合の対処方法についてである。ユーザ５がステップ１８０１において「ログインＩＤを忘れた」ボタンをクリックする。このとき、ステップ１８０３では、パスワードを覚えているか否かがＷｅｂを介してユーザ５に対して問い合わせされる。ユーザ５がパスワードを覚えている場合には、ステップ１８０５に進み、Ｗｅｂ画面にてメールアドレス、電話番号、氏名（法人名）、生年月日、性別及びパスワードを入力する。
その後、ステップ１８０７でセンターサーバー１００８に向けて、ユーザ５により入力された情報が送信される。ステップ１８０９では、センターサーバー１００８側で受信されたデータについて、データベース１００９に一致したデータが存在するか否かが判断される。存在する場合には、ステップ１８１３に進み、データベース１００９から一致したユーザ５のログインＩＤを抽出する。そして、ステップ１８１５では、インターネット上のＷｅｂ画面を介してユーザ５に対してログインＩＤが表示されるので、ユーザ５はこれを確認する。一方、ステップ１８０９でデータベース１００９に一致したデータが存在しなかった場合には、ステップ１８１１でユーザ５に対して再入力を依頼する。再入力のあった場合には、ステップ１８０５からの処理が繰り返される。
また、ステップ１８０３でユーザ５がパスワードを覚えていなかった場合には、ステップ１８１７に進み、Ｗｅｂ画面にてメールアドレス、電話番号、住所、氏名（法人名）、生年月日、性別を入力する。但し、メールアドレスは省略されてもよい。その後、ステップ１８１９でセンターサーバー１００８に向けて、ユーザ５により入力された情報が送信される。ステップ１８２１では、センターサーバー１００８側で受信されたデータについて、データベース１００９に一致したデータが存在するか否かが判断される。存在する場合には、ステップ１８２５に進み、データベース１００９から一致したユーザ５のメールアドレスを抽出する。そして、ステップ１８２７では、このメールアドレスへの電子メール文に「ＵＲＬ ｈｔｔｐ：／／ａａａａ．・・・に行ってログインＩＤを確認して下さい。」と記載する。そして、ステップ１８２９では、センターサーバー１００８側では、待ち受け状態符号を設定し、日時をデータベース１００９に記録する。待ち受け状態符号を設定するのは、正当な手順を踏まない不正アクセスを阻止するためである。その後、ステップ１８３１では、電子メール送信を行う。ステップ１８３３でユーザ５が電子メールを受信し、このユーザ５は、ステップ１８３５で、ｈｔｔｐ：／／ａａａａ．・・・に行ってＨＴＭＬ文書をダウンロードしてユーザ５のメールアドレス、電話番号を入力する。このＵＲＬへのジャンプは電子メールに記載されたＵＲＬをクリックすることで行うことができる。この電子メールが届き、その後の処理を行う人は、真のユーザであると判断できる。
ステップ１８３７では、メールアドレス、電話番号をセンターサーバー１００８に向けて送信する。センターサーバー１００８側では、ステップ１８３９においてメールアドレス、電話番号の一致したユーザ５のログインＩＤを抽出する。但し、このときにパスワードも抽出するようにしてもよい。そして、ステップ１８４１では、ステップ１８２９で記録された日時をチェックして、７日以内か否か判断する。このように期間を限ったのは、不正なアクセスを阻止するためである。
７日以内のときステップ１８４３で待ち受け状態符号が設定されているか否かが判断される。７日を過ぎている場合には、ステップ１８５１で「７日を過ぎています。もう一度最初から手続きをお願いします。」とメッセージを出す。待ち受け状態符号が設定されている場合には、ステップ１８４５で、インターネット上のＷｅｂ画面を介してユーザ５に対してログインＩＤが表示されるので、ユーザ５はこれを確認する。但し、このときログインＩＤだけでなくパスワードも同時に表示されるようにしてもよい。一方、待ち受け状態符号が設定されていなかった場合には、ステップ１８４９で、「最初から手続きをお願いします。」とユーザ５に対してメッセージ表示する。ステップ１８４７では、待ち受け状態符号を解除する。
以上により、ユーザ５はログインＩＤを忘れた場合であっても簡単、かつ確実に再び入手が可能となる。
次に、本発明の第１９実施形態について説明する。本発明の第１９実施形態のホームページの画面例を図６１に示す。本発明の第１９実施形態では、指定あるいは検索されたある商品について、他の商店等７の同一の商品との間で価格を比較可能にすると共に値引き交渉をも可能とすることで値引き交渉の際の最低価格の推測をし易くしたものである。また、ウィンドウショッピングの要素をも併せて取り入れたものである。
図６１において、閲覧モード選択ボタン２００１において、直接価格対比のページか、若しくはウィンドウショッピングのページかを選択する。図６１の例では、下段のＨＴＭＬ画面欄２００３に直接価格対比のページが選択されて表示された状態である。商品名入力又は検索欄２００５に入力された商品名「パソコンＰＣ９８２１Ｖ１３」はユーザ５により指定されたもの、あるいは検索の結果によるものである。そして、この商品についてはＡ商店、Ｂ商店、Ｃ商店等が販売を行っており、その販売価格がＨＴＭＬ画面欄２００３に示されるようになっている。これらの商店は、通常表示は商店名順であるが、表示順選択欄２００７により売れ行き順、価格の安い順等を選択することで、これらに従って絞り込まれたデータが表示されるようにしてもよい。閲覧モード選択ボタン２００１、商品名入力又は検索欄２００５、表示順選択欄２００７等を含む画面上段部分２０１３は、ＨＴＭＬにて構成されている。
また、Ａ商店の項目をクリックすればこのＡ商店の企業概要が表示されるようになっている。各商店等７の情報はサーバ３のデータベース１００９に保存されている。なお、この商品については別途独立して商店等７側で用意されたホームページからリンクが張られるようになっている。
そして、各商店等７は、ＷＷＷサーバ３のサイトに対し貸し店舗形式で加入したり、商品を登録するようになっている。図６１では、各商店等７及びＷＷＷサーバ３のサイトの運営者において設定された当該商品についての現金還元額が表示されている。即ち、商店等７で現金還元された上に、更にＷＷＷサーバ３のサイトの運営者によっても追加の現金還元がされるようになっている。
但し、各商店等７又はＷＷＷサーバ３のサイトの運営者のそれぞれのみが当該商品について設定した現金還元額を表示するようにしてもよい。図６１の例で言えば、Ａ商店の希望販売価格２０万円でＡ商店による現金還元額は０円、Ｂ商店の希望販売価格１９万９千円でＢ商店による現金還元額は４００円、Ｃ商店の希望販売価格２０万円でＣ商店による現金還元額は３００円であり、かつＢ商店とＣ商店では、値引き交渉も可能なようになっている。なお、値引き交渉と現金還元（ユーザ貯金箱を含む）の処理については前述した各実施形態の通りである。希望販売価格Ｘ円、底値Ｙ円、現金還元額、送料データ等はサーバ３のデータベース１００９に保存されている。このように、ホームページの一画面で各商店等７の価格比較をし、かつ値引き交渉と現金還元額をも設定することで、ユーザ５にとっては商品の底値Ｙ円の推定がし易くなる。また、値引き交渉を設定した商店等７にとっては、常に底値ぎりぎりの額を表示する必要が無くなり、表示した価格が他店よりも高くても値引きされる含みを残すことで、底値ぎりぎりの額を表示した商店等７とも互角に競争できる。
なお、ＷＷＷサーバ３のサイトの運営者側では、サーバ３のデータベース１００９にユーザ５による販売情報の履歴が取られ貸し店舗にて加入された商店等７がいつでも閲覧可能なようになっている。そして、ユーザ５による購入のあった場合には、各商店等７に対し電子メールが送信され、その電子メールを受け取った各商店等７はサーバ３のデータベース１００９に接続して販売情報の履歴を閲覧する。販売情報の履歴には、値引き交渉又は現金還元による決定価格、支払方法、お届け先、送料、購入者情報、ユーザ貯金箱に関する情報等が表示されている。このユーザ貯金箱は、貸し店舗にて加入された商店等７毎に独立してサーバ３のデータベース１００９に配設され、かつ各ユーザ単位に準備されたものである。そして、ユーザ貯金箱に関する情報は、この商店等７のユーザ５の有するユーザ貯金箱に対し貯金がどの程度存在するかの情報である。なお、図６１のようにＷＷＷサーバ３のサイトの運営者によっても追加の現金還元がされるような場合には、ユーザ５の有するユーザ貯金箱がサイトの運営者側でも商店等７側とは別に用意されている。この際には、ユーザ５は、商店等７のユーザ貯金箱から貯金を利用して購入した商品の支払ができると共に、ＷＷＷサーバ３のサイトの運営者により提供されたユーザ貯金箱からも貯金を利用して支払に当てることができる。
その後は、各商店等７はユーザ５からの入金の確認処理をし、商品の出荷等を行う。なお、各商店等７の独自のホームページにおいても商品やサービスの販売がされている場合には、これらの商品やサービスについて各商店等７のホームページ上に特定のアイコンを埋設し、このアイコンがユーザ５によりクリックされたときにＷＷＷサーバ３のサイトにリンクされることが望ましい。ＷＷＷサーバ３のサイト側では値引き交渉や現金還元の機能を提供可能である。このため、この特定のアイコンは値引き交渉等が可能であることを明示することが望ましい。また、特定のアイコンがクリックされたときに、ＷＷＷサーバ３のサイト側で用意した値引き交渉機能や現金還元機能に直接リンクされてもよい。この場合には、あたかも値引き交渉機能や現金還元機能が各商店等７側で独自に用意された機能であるかのように動作可能である。
また、図６１では「その他商店」を選択可能なようになっており、このその他商店では、直接価格対比ページへの商品掲載はしていないが、ＷＷＷサーバ３のサイト内の貸し店舗に登録があり、当該商品をこの貸し店舗において販売している商店等７の名称が複数用意されており、この中から一つを選択可能なようになっている。但し、その他商店では、これまでのページで表示されていない残りの商店を表示順選択欄２００７で指定された順に従って配列するようにしてもよい。
そして、この貸し店舗の一つが選択された場合には、ＷＷＷサーバ３のサイト内の貸し店舗のページに進み表示されるようになっている。この貸し店舗の情報や販売の商品等は、サーバ３のデータベース１００９に保存されている。一方、貸し店舗のページには、「直接価格対比ページの情報を見る」ボタン（図示略）を有しており、このボタンをクリックすることで直接価格対比ページに進み、各商店毎の価格比較が行えるようになっている。なお、閲覧モード選択ボタン２００１をクリックすることで直接価格対比ページに進んでもよい。
このことにより、貸し店舗のページで値引き交渉の底値の判断をし難いと感じたユーザ５は直接価格対比ページに進み、この価格情報を見ることで底値の推定が容易となる。更に、これらの各商店には図５８における「他店の方が安いよ」ボタンを配設するようにしてもよい。
次に、図６１の閲覧モード選択ボタン２００１において、ウィンドウショッピングのページを選択した場合について説明する。
ウィンドウショッピングのページは、図６２に示すように、ＷＷＷサーバ３のサイトの開設する貸し店舗において登録された各商店等７のホームページ２００９で構成されている。各商店等７の情報や商品情報等はサーバ３のデータベース１００９に保存され、Ｗｅｂページとして閲覧可能なようになっている。
ユーザ５は、閲覧モード選択ボタン２００１でウィンドウショッピングのページを選択した後、まず商品名入力又は検索欄２００５で商品名（例えば「パソコンＰＣ９８２１Ｖ１３」）を指定、あるいは検索により商品名を特定する。このことにより、Ａ商店の当該商品情報及び価格の属するページが開かれる。この際には、当該商品が目立つようにページトップに表示されたり、色分け等の施されるのが望ましい。このページには、また、Ａ商店で扱う他の商品情報も含まれている。図６２は、このＡ商店のページが開かれた様子を示している。ユーザ５は、「次のお店（Ｂ商店）へウィンドウショッピングする」の移動ボタン２０１１によりページを進めたり戻ったりできるようになっている。次のお店（Ｂ商店）のページでは、同様に図６３に示すように、Ｂ商店の当該商品情報及び価格の属するページが開かれる。このページには、また、Ｂ商店で扱う他の商品情報も含まれている。ユーザ５は、以下、同様にページを進めたり戻ったりすることで、各商店を巡るウィンドウショッピングの感覚で楽しみながら、当該商品の値段を次第に把握できる。何店舗かの価格を参照することで、底値についての推測も自然の形で把握できる。そして、気に入った商店等７で値引き交渉等により商品を購入できる。
なお、ユーザ５が、当該商品の値段を直接対比したくなった場合には、閲覧モード選択ボタン２００１で直接価格対比のページを選択すればよい。
また、次のお店（Ｂ商店）へウィンドウショッピングするのに代えて、複数の商店の中から一つを選択自在としてもよい。これらの商店は、通常表示は商店名順であるが、売れ行き順、価格の安い順等を選択することで、これらに従って絞り込まれたデータが表示されるようにしてもよい。
なお、商店名検索欄２０１５に直接商店名を入力、若しくは複数の商店の中から一つを選択することで、直接当該商店のページが直接価格対比又はウィンドウショッピングのページの先頭に表示されるようにしてもよい。
このように、ユーザ５が、ウィンドウショッピングの感覚で買い物を楽しむことが可能でありながら、直接価格対比もでき、価格相場が簡単に分かる。この価格相場を基にユーザ５は値引き交渉を効率よく行うことが可能となる。
なお、上述した直接価格対比及びウィンドウショッピングは、第１１実施形態で述べたオークション等について適用されることも可能である。但し、この場合には値引き交渉ボタンは、オークション処理に進むためのボタンとなる。
このことによっても、ウィンドウショッピングのように楽しみつつ価格相場が分かる。この価格相場を基にユーザ５はオークションや入札を効率よく行うことが可能となる。
次に、本発明の第２０実施形態について説明する。上述した直接価格対比又はウィンドウショッピングのページでは、商店等７にとっては扱いも小さく、かつページが変わった場合には消えてしまうものである。本発明の第２０実施形態では、この点を同じページの一角に特別店舗紹介コーナーを設け、直接価格対比又はウィンドウショッピング等のページが繰られても常に定位置に表示されることで宣伝効果を高くしたものである。
図６４に画面構成例を示し、図６５にフローチャートを示す。図６４には、特別店舗紹介コーナー２０１７が追加されている。そして、特別店舗紹介コーナー２０１７は、直接価格対比又はウィンドウショッピング等のページが繰られても常に定位置に表示されるようになっている。特別店舗紹介コーナー２０１７においては、店舗名、商品型番、希望販売額、値引き交渉が可能か否か。現金還元された際の金額等が表示されており、店舗名をクリックすれば当該店舗に進み、商品型番をクリックすれば商品の詳細仕様を含む情報が表示される。そして、この商品の詳細仕様のページからも値引き交渉や現金還元が可能であるが、特別店舗紹介コーナー２０１７における値引き交渉をクリックしても値引き交渉処理に直接飛べる。
図６５において、ステップ１８８１では、商品名入力又は検索欄２００５で商品名（例えば「パソコンＰＣ９８２１Ｖ１３」）を指定、あるいは検索により商品名を特定する。ステップ１８８３では、当該商品を扱う商店が商店掲載順位テーブル中に存在するか否かが判断される。この商店掲載順位テーブルには特別店舗紹介コーナー２０１７における掲載順位毎若しくは掲載欄毎に料金が設定されている。店舗はこの商店掲載順位テーブルに予めデータを登録することにより、特別店舗紹介コーナー２０１７に表示されるようになっている。
ステップ１８８３で当該商品を扱う商店が商店掲載順位テーブル中に存在していた場合には、ステップ１８８５で商店掲載順位テーブルが参照される。一方、存在しなかった場合にはステップ１８８７で終了する。ステップ１８８９では、初期値としてｎ＝１が設定される。ステップ１８９１では、まず１番目に掲載する商店が抽出される。そして、ステップ１８９３で抽出した商店の画像や販売情報等をＷｅｂページのｎ番目の欄に組み込む。ステップ１８９５で商店掲載順位テーブルからの抽出が完了していない場合には、ステップ１８９７でｎをインクリメントした上で再びステップ１８９１からの処理を繰り返す。そして、ステップ１８９９で、一つのＷｅｂページの形にしてユーザパソコンにダウンロードさせる。
以上により、当該商品を購入したいユーザ５に対してＷｅｂページの目立つ箇所に常に店舗名等が表示され、ユーザ５が購入し易い。
次に、本発明の第２１実施形態について説明する。本発明の第２１実施形態では、サイト内にソフトウェアにて構成されたロボット店員を仮想配置し、このロボット店員にユーザ５との間でユーザ５の有する独自の情報やサイトの有する情報等に応じて臨機応変に様々な対応をさせるものである。この対応には、例えば、値引き交渉の誘導及び案内、商品説明、挨拶、サイトの紹介、ヘルプ等が含まれるがこれらに限定されるものではない。
現金還元額の大きさやｍ値の設定、底値価格の設定をお得意様段階に応じて例えば５段階に設定している場合には、このお得意様段階に応じてホームページ上に現れるロボット店員を異ならせる。お得意様段階は、ユーザ５による購入価格の総額と購入頻度やサイトの利用実績等に応じて決められている。お得意様段階と購入価格の総額等のデータはサーバ３のデータベース１００９に保存されている。そして、このお得意様段階は、例えば購入価格の総額が５万円未満で、かつ購入頻度が４回未満の場合にはお得意様段階は１段階とする。そして、お得意様段階が１段階上がったユーザ５に対してはロボット係長が応対するようになっている。購入価格の総額が５万円以上２０万円未満で、かつ購入頻度が４回以上７回未満の場合にはお得意様段階は２段階とする等である。そして、お得意様段階が２段階上がったユーザ５に対してはロボット課長が応対するようになっている。以下、更に１段階ずつランクの上がった場合にはロボット部長、ロボット店長、ロボット社長が応対するようになっている。
次に、図６６にフローチャートを示す。ステップ１９０１では、ユーザ５がＷＷＷサーバ３のサイトに接続する。ステップ１９０３ではユーザ５のパソコンからクッキー（ｃｏｏｋｉｅ）情報を取得する。そして、ステップ１９０５では、データベース１００９よりこのクッキー情報を基にユーザ情報の一致するデータを抽出する。ステップ１９０７では、ユーザ５が検出される。但し、ユーザ５の検出は、ユーザＩＤを入力させ、このユーザＩＤ情報を基に判断されるようにしてもよい。ステップ１９０９では、このユーザ５に属するお得意様段階をデータベース１００９より抽出する。ステップ１９１１では、このお得意様段階を基に出現させるロボット店員をデータベース１００９より選定する。例えば、購入価格の総額が６万円で購入頻度が５回の場合には、ロボット課長が選定される。このとき、ロボット課長のデザインの組み込まれたホームページがデータベース１００９より抽出される。ステップ１９１３では、抽出されたロボット店員を含むホームページがユーザパソコンに表示される。
こうすることで、ユーザ５は、自分がお得意様であることを認識できるし、一層安く購入できるということを感覚的に理解できる。従って購入の促進につながる。
次に、このロボット店員により様々な挨拶を行う処理について説明する。まず、ロボット店員によるユーザ５の訪問時間の管理について説明する。図６７において、ステップ１９０１〜ステップ１９０７までの処理については図６６と同様であるので省略する（以下、同旨）。ステップ１９２１では、サイトの訪問が初めてか否かを判断する。この判断は、クッキー情報を抽出して過去に同じユーザ５からのデータが保存されていないかどうかを見ることで判断できる。または、クッキー情報に一致する既にユーザ登録されたデータがデータベース１００９中に存在しないかどうかで判断されてもよい。更に、ユーザＩＤを入力させ、このユーザＩＤ情報を基に判断されるようにしてもよい。
当サイトへの訪問が初めてであると判断されたときには、ステップ１９２３で「はじめまして。登録をお願いします。」とＷｅｂ画面上に表示する。但し、音声にて発するようにしてもよい（以下、同旨）。一方、ステップ１９２１で、当サイトへの訪問が初めてではないと判断されたとき、ステップ１９２５で前回訪問からの時間を算出する。これは、データベース１００９に対しユーザ５の訪問日時を各ユーザ毎に記録することで可能となる。ステップ１９２７で、一定時間以上経過しているか否かが判断される。そして、一定時間以上経過していると判断されたときステップ１９２９で「＊＊さんこんばんわ。しばらくです。」と表示する。この文言はデータベース１００９に保存されたデータと、ステップ１９０７で検出されたユーザ５の名前とを組み合わせることで可能である。
一方、ステップ１９２７で、「一定時間以上経過していないと判断されたときステップ１９３１で「＊＊さんこんばんわ。たびたびご来店頂きありがとう。」と表示する。
次に、ロボット店員による天候の挨拶について説明する。図６８のステップ１９４１において、データベース１００９に登録されたユーザ５の住所を抽出する。この住所はほぼユーザ５の現在居る住所と同じであると推測される。しかしながら、移動情報処理端末や携帯型のパソコン等で移動中の場合もあり、この場合には、ＧＰＳ等による位置情報を検出し、この情報を用いてもよい。ステップ１９４３では、天気予報データベース１００９より当該住所地の属する天気データを抽出する。このため、天気予報データベース１００９には時々刻々に各地域毎の天気データが保存されるようになっている。あるいは、この天気予報データベース１００９は、気象庁等の提供者によるものとしてこのデータベース１００９とリンクすることで取得されてもよい。ステップ１９４１で抽出した住所がいずれの地域に属するかを判断することで当該住所地の属する天気データを抽出することが可能である。
ステップ１９４５では、天気データ−時候の挨拶文言テーブルより時候の挨拶文を抽出する。このため、天気データ−時候の挨拶文言テーブルには予め天気データが晴れのときには「今日はいい天気ですね」、天気データが雨のときには 「今日はあいにくの天気ですね」という文言を関連付けして保存しておく。その後、ステップ１９４７では、Ｗｅｂページを合成する。即ち、晴れマークを追加すると共に「＊＊さん 今日はいい天気ですね。」という文言を合成して、一つのＷｅｂページとして生成され、ユーザ５のパソコンにダウンロードされる。
次に、ユーザ５の近況が変化した場合の時候の挨拶について説明する。図６９において、ステップ１９５１でユーザ５の登録情報である例えば住所が変更されたような場合である。この情報の変化を抽出する。そして、ステップ１９５３では、「＊＊さん こんにちわ。住所が変わられたんですね。」とユーザ５に対して表示する。「＊＊さん こんにちわ。＊＊が変わられたんですね。」の＊＊に相当する部分に対して、検出した情報である氏名や、変更のあったものの情報 （この場合には住所という文言）を組み込みＷｅｂページを合成する。変更の想定される文言は予めデータベース１００９に保存され、この中から情報の変更のあった文言が選択されるようになっている。
次に、ユーザ５の過去の購入情報を基にした挨拶について説明する。図７０のフローチャートにおいて、ステップ１９６１で販売管理データベース１００９より過去の購入情報を見る。そして、ステップ１９６３で、購入情報が存在する場合には、ステップ１９６５で「この間はご購入いただきありがとうございました」とロボット店員が挨拶をする。一方、ステップ１９６３で購入情報が存在しない場合には、ステップ１９６７で次の処理へ進む。
次に、ロボット店員が各店舗に合わせて衣替えする方法について説明する。ロボット店員は、ホームページ上で閲覧可能な画像にて形成される。そして、このロボット店員の画像中の適所には、商号等のマークが表示されている。ＷＷＷサーバ３のサイトに対し貸し店舗形式で各店舗に加入してもらう場合、ロボット店員に付される商号等のマークが各店舗に合わせて変えられることが望ましい。図７１のフローチャートにおいて、ステップ１９７１でユーザ５がＷＷＷサーバ３のサイト内の店舗のホームページに接続する。このとき、ステップ１９７３では、ＷＷＷサーバ３はこの店舗のホームページが選択されているということをＵＲＬを検出することで確認したり、あるいはソフトウェア的にサーバ３内部の処理により確認する。そして、例えば店舗名（あるいは店舗のコード）を抽出する。ステップ１９７５では、店舗−衣替え用部品テーブルを参照する。この店舗−衣替え用部品テーブルは、例えば、各店舗毎に用意された部品の形態である。部品は、例えば、ロボット店員の衣類に表示する各店舗の商号等のマークやロボット店員の顔、季節に応じた衣類等である。しかしながら、音声等であってもよい。これらの部品は各店舗毎にデータベース１００９に保存されている。
ステップ１９７７では、当該店舗に一致した部品を抽出する。そして、ステップ１９７９では、ロボット店員の画像の一部を抽出部品と交換することで、このロボット店員に着せ変えを行う。ステップ１９８１では、この着せ変えの完了したロボット店員を含む画像をダウンロードする。なお、部品は店舗毎に対応してデータベース１００９に保存されるとして説明したが、複数のアイコンや形態等をデータベース１００９に予め用意しておき、ユーザ５に対しそのうちの好きなアイコンや形態を選択してもらい、このユーザ５に特有のアイコンとして登録するようにしてもよい。そして、ロボット店員を表示する際には、このユーザ５に特有のアイコン等で着せ変えられた態様で画像表示されるようにしてもよい。また、部品を交換するのではなく、予め店舗毎やユーザ５毎に対応されたロボット店員の画像を含む専用のＨＴＭＬ画像の全画面分を店舗名や店舗コード若しくはユーザＩＤと関連付けしてデータベース１００９に用意しておき、店舗名等を基にこの専用のＨＴＭＬ画像を検索した後、ユーザパソコンにダウンロードさせるようにしてもよい。
以上により、ロボット店員の様々な臨機応変の登場及び挨拶が可能となり、ユーザ５にとっては親しみがわき再びサイトを訪問したくなる。従って、商品等の購入促進にもつながる。
次に、本発明の第２２実施形態について説明する。本発明の第２２実施形態では、サイト内にソフトウェアにて構成されたロボット店員を仮想配置し、このロボット店員に対しサイト内で販売を担当させるものである。この販売を担当させる方法について図７２及び図７３のフローチャートを基に説明する。図７２及び図７３において、ステップ２００１では、同一ジャンルの複数の商品を対比する閲覧ページを表示する。このページは、例えば、携帯電話やプリンター等の商品分類毎について複数の商品アイテムがまとめて掲示されたページや、上述の直接価格対比のページやウィンドウショッピングのページ等も含む。但し、ジャンルや商品等は入力欄により指定されてもよい。ステップ２００３ではロボット店員を表示する。ステップ２００５では、ユーザ５は当該ページで表示されている商品ジャンル（例えばパソコンのページならばパソコン）について、若しくは入力欄に指定した商品（例えば「ＰＣ９８２１Ｖ１３」等のパソコン型番を入力した場合にはこのパソコン型番、商品ジャンルを指定した場合にはこの商品ジャンル等）について、予算金額入力欄にユーザ５が当該商品を購入するのに許容可能な予算金額を入力する。また、ステップ２００７では機能を選択する。機能は機能入力欄に文字入力されてもよいが、予め用意された機能の中から選択されてもよい。
ステップ２００９では、お勧めで購入又は売れ筋で購入を選択する。ステップ２０１１でお勧めで購入が選択された場合には、ステップ２０１３に進む。ステップ２０１３では、予算金額の入力があるか否かが判断される。そして、予算金額の入力があった場合には、ステップ２０１５で商品ジャンル−お勧め商品テーブルより予算金額以内のデータを抽出する。この商品ジャンル−お勧め商品テーブルには、予め各商品ジャンル毎にＷＷＷサーバ３のサイトの運営者により選定されたお勧め商品が少なくとも一つ保存されている。
また、ステップ２００７で機能の選択があったとステップ２０１７で判断された場合に、ステップ２０１９でこの機能に従ってデータが絞られる。そして、ステップ２０２１に進む。一方、ステップ２０１７で機能の選択が無かったと判断された場合にはステップ２０２１に進む。ステップ２０２１では、ｎの値を初期値として１を設定する。次にステップ２０２３では、ｎ番目に高いお勧め商品を抽出する。即ち、まずは１番高額なお勧め商品を抽出する。次に、ステップ２０２５では、当該お勧め商品のお勧めのポイント（要点）が抽出される。このお勧めのポイントは、サイトの運営者によって予め記載されてデータベース１００９に保存されたものである。この商品選択の際に参考となるお勧めの要点がデータベース１００９より抽出される。
ステップ２０２７では、抽出されたお勧めの要点がロボット店員と組み合わされて一つのＷｅｂページとされる。このページには表示のみではなく、音声が含まれてもよい。そして、このＷｅｂページがユーザパソコンにダウンロードされることで、ロボット店員が表示若しくは音声によりお勧め商品を紹介する。ステップ２０２９では、ユーザ５が詳細仕様を見たい場合にこの詳細仕様を閲覧する。そして、ステップ２０３１で当該商品を購入する旨のボタンをクリックする。ユーザ５は、詳細仕様を見ずにステップ２０３１で当該商品を購入する旨のボタンをクリックすることも可能である。
ステップ２０３１で購入せずに「次の商品を紹介」ボタンをクリックした場合には、ステップ２０３２でｎのカウント値を１つインクリメントした上で再びステップ２０２３からの処理を繰り返す。ステップ２０３１で購入を選択した場合にはステップ２０３３で値引き交渉処理や現金還元処理が可能である。
なお、ステップ２０３５で売れ筋で購入が選択された場合には、ステップ２０３７に飛ぶ。そして、ステップ２０３７では、予算金額の入力があるか否かが判断される。そして、予算金額の入力があった場合には、ステップ２０３９で商品ジャンル−売れ筋商品テーブルより予算金額以内のデータを抽出する。この商品ジャンル−売れ筋商品テーブルには、予め各商品ジャンル毎にＷＷＷサーバ３のサイトの運営者により選定された売れ筋商品が少なくとも一つ保存されている。
また、ステップ２００７で機能の選択があったとステップ２０４１で判断された場合に、ステップ２０４３でこの機能に従ってデータが絞られる。そして、ステップ２０４５に進む。一方、ステップ２０４１で機能の選択が無かったと判断された場合にはステップ２０４５に進む。ステップ２０４５では、ｎの値を初期値として１を設定する。次にステップ２０４７では、ｎ番目に高い売れ筋商品を抽出する。即ち、まずは１番高額な売れ筋商品を抽出する。次に、ステップ２０４９では、当該売れ筋商品のお勧めのポイント（要点）が抽出される。この売れ筋のポイントは、サイトの運営者によって予め記載されてデータベース１００９に保存されたものである。この商品選択の際に参考となる売れ筋の要点がデータベース１００９より抽出される。
ステップ２０５１では、抽出された売れ筋の要点がロボット店員と組み合わされて一つのＷｅｂページとされる。このページには表示のみではなく、音声が含まれてもよい。そして、このＷｅｂページがユーザパソコンにダウンロードされることで、ロボット店員が表示若しくは音声により売れ筋商品を紹介する。ステップ２０５３では、ユーザ５が詳細仕様を見たい場合にこの詳細仕様を閲覧する。そして、ステップ２０５５で当該商品を購入する旨のボタンをクリックする。ユーザ５は、詳細仕様を見ずにステップ２０５５で当該商品を購入する旨のボタンをクリックすることも可能である。
ステップ２０５５で購入せずに「次の商品を紹介」ボタンをクリックした場合には、ステップ２０５６でｎのカウント値を１つインクリメントした上で再びステップ２０４７からの処理を繰り返す。ステップ２０５５で購入を選択した場合にはステップ２０５７で値引き交渉処理や現金還元処理が可能である。
次に、本発明の第２３実施形態について説明する。本発明の第２３実施形態では、サイト内にソフトウェアにて構成されたロボット店員を仮想配置し、このロボット店員がユーザ５に対して挨拶する際に何か出物があったらお知らせするというものである。この何か出物があったらお知らせする方法について図７４及び図７５のフローチャートを基に説明する。まず、図７４及び図７５において、ユーザ５は、ステップ２１０１で、ＷＷＷサーバ３のサイトに対し予め何か出物があったら通知が欲しい旨の設定を登録しておく。この際には、ステップ２１０３において欲しい商品（商品名若しくは型番）で登録するか、若しくは希望のジャンルや趣味で登録するかを選択する。ジャンルは、例えば生活、旅行、教育、健康、スポーツ、ゲーム等である。
ステップ２１０３で欲しい商品（商品名若しくは型番）で登録するを選択した場合には、ステップ２１０５で予めユーザ５が情報の欲しい商品（必須記入）と仕様が分かっている場合にはその仕様、最高限度価格（任意記入）、最高限度価格との差額が誤差範囲内のときに通知を希望（率若しくは金額）（任意記入）とをＷｅｂ画面にて登録する。商品はディジタルカメラや、パソコン等と一般的な商品名称を登録してもよいし、商品の型番が分かっている場合には、その型番を登録する。
最高限度価格では、この金額以下の商品ならば情報をもらいたいという場合に金額入力欄に金額を入力する。また、「最高限度価格との差額が誤差範囲内のときに通知を希望（率若しくは金額）」は、最高限度額を超えてはいても一定範囲内ならば情報をもらいたいという場合に設定する。一方、ステップ２１０３で 「希望のジャンルや趣味で登録する」を選択した場合には、ステップ２１０７でＷｅｂ画面上でジャンルを選択したり、趣味を選択する。
そして、ステップ２１０９でユーザ５が再びＷＷＷサーバ３のサイトを訪問したとき、ステップ２１１１でユーザ５のパソコンからクッキー情報が取得される。ステップ２１１３では、このクッキー情報を基に一致するユーザ５の情報がデータベース１００９より取得される。但し、ユーザ本人の確認はユーザＩＤによって行われてもよい。その後、ステップ２１１５では、ステップ２１０３において設定された欲しい商品の登録が存在するか否かが判断される。欲しい商品の登録が存在する場合には、ステップ２１１７でこの欲しい商品について既にステップ２１０５で登録されていたデータをデータベース１００９より抽出する。
一方、ステップ２１１５で、欲しい商品の登録が存在しない場合には、ステップ２１１９で購入実績をみたりステップ２１０７で登録された趣味データやジャンルを参照する。あるいは、よく訪れるサイトを蓄積・分析することで、ステップ２１２１において欲しい商品を推定する。そして、ステップ２１２３では、登録あるいは推定された欲しい商品について出物が存在するか否かが判断される。但し、欲しいジャンルについて出物が存在するか否かが判断されるようにしてもよい。また、欲しい商品はオークション等の出品物に対して適用されてもよい。
この出物情報は、日時と共に随時ジャンル、商品名毎にデータベース１００９に保存されるようになっている。欲しい商品やジャンルについて出物が存在しない場合には、既存の商品の中から最もユーザ５の希望に沿った商品を案内することが望ましい。このための処理について説明する。ステップ２１２５では、登録あるいは推定された欲しい商品についてデータベース１００９からジャンルや商品名の一致するデータをすべて抽出し、その値段を取得する。ステップ２１２７で現金還元可能な商品か否かを判断し、可能なものについては、ステップ２１２９で欲しい商品の値段から現金還元額分を差し引く。但し、この現金還元額分の減額は必ず商品価格から減額されることが確認されているものについてのみ減額が行われる。現金還元額分がユーザ貯金箱に貯金されるような場合には差し引かないことが望ましいからである。また、現金還元額は出物として提示する際に記載されるのでユーザ５がその際に分かるからである。
ステップ２１３１では、最高限度価格の指定があるか否かが判断される。最高限度価格の指定がある場合には、ステップ２１３３に進み、ステップ２１２５で抽出した商品データに関し、欲しい商品についての最高限度価格より値段の安いものがあるか否かを判断し、あった場合には抽出する。またはオークションの場合には、オークションでの出品でユーザ５希望のものが出され、かつ値段がユーザ５の指定した最高限度価格より安いものがあるか否かが判断されてもよい。
ステップ２１３５では、「＊＊さん（依頼されていた）商品＊＊についてよい出物がありますよ。」とのメッセージがホームページ構成され、このホームページがユーザのパソコンにダウンロードされることでロボット店員がメッセージをユーザ５に対して表示する。この際には、ステップ２１３７で、商店名、商品名、価格、値引き交渉可能か否か、現金還元額を提示する。複数の商品が存在している場合にはその複数の商品を提示する。ステップ２１３９では、ユーザ５が商品名をクリックするとこの出物の詳細の記載されたページへ進むようになっている。ステップ２１４１でユーザ５が気に入り購入ボタンをクリックした場合には、ステップ２１４３で値引き交渉や現金還元が可能なようになっている。一方、ステップ２１３９でキャンセルボタンがクリックされた場合には、ステップ２１４５でキャンセル処理がされる。
なお、ステップ２１２３で欲しい商品について出物が存在した場合には、ステップ２１３５からの処理が行われ出物が存在する旨をユーザ５に対して案内する。また、ステップ２１３１で最高限度価格の指定が無かった場合には、ステップ２１４７で欲しい商品について値段の安い物件を数件抽出し、ステップ２１３５からの処理が行われ出物が存在する旨をユーザ５に対して案内する。
更に、ステップ２１３３で、欲しい商品について最高限度価格より値段の安いものが無かった場合には、ステップ２１４９で最高限度価格との差額が算出される。そして、ステップ２１５１でこの差が設定の割合以内か否かが判断される。この差はユーザ５が最高限度価格をどこまで超えても許容してくれるかによるが、一応１０〜２０パーセント程度に設定される。このとき、ステップ２１５３では、「＊＊さん（依頼されていた）商品＊＊についてご希望に近いよい出物がありますよ。」とホームページ上で案内する。そして、以降ステップ２１３７からの処理が行われる。一方、ステップ２１５１で、差が設定の割合以内に納まらなかった場合にはステップ２１５５で「＊さん依頼されていた商品について今のところ掘り出しものはありませんが鋭意努力中です。しかしながら、値引き交渉如何によってはご希望の価格以内に納まることもあります。」とのメッセージをホームページ上でユーザ５に対して案内する。そして、ステップ２１５７で、当該商品について値引き交渉の可能な商店リストをユーザ５に対して提示する。ステップ２１５９では、ユーザ５はこの内から商店を選択することで、ＷＷＷサーバ３のサイト内のこの店舗のホームページに接続する。
なお、図７４の上記説明では、ステップ２１０９でユーザ５が再びサイトを訪問した際に画面にてメッセージを表示するとして説明したが、事前に欲しい商品についての出物が出たことをユーザ５に対し電子メールにて伝えるようにすることが望ましい。この場合であっても、ステップ２１１５以降の処理を別途事前に行うことで出物の存在を検出することが可能である。
以上により、ユーザ５が何か出物を探しているような場合に、その条件を予めＷＷＷサーバ３のサイトに対し設定しておくことで、出物が見つかったことをいち早くユーザ５がサイトを訪れた際に報告でき、臨機応変な対応ができる。ユーザ５は探し物で大変な思いをしなくて済む。また、商店にとっては販売促進につながる。
次に、本発明の第２４実施形態について説明する。本発明の第２４実施形態では、買い物かごに入れた商品の合計をした後、合計金額が予算に合っていないことに気づいたユーザが、予算に合うように商品選定の見直しが容易にできるようにしたものである。
図７６及び図７７にフローチャートを示す。まず、ユーザ５はＷＷＷサーバ３のサイトにおいて、ステップ２２０１で図示しない買い物かごに商品を入れる。そして、ステップ２２０３でもうこれ以上買い物をするものが無くなったときに最終的な金額の合計をする。この金額はステップ２２０５でユーザ５に対して金額表示される。この金額に不満のあるユーザ５は次にステップ２２０７で「予算に合うように見直し」ボタンをクリックするか、若しくは「個別に商品を見直す」ボタンをクリックする。「個別に商品を見直す」ボタンがクリックされた場合には、ステップ２２０９で買い物かごの中から「商品を一つ指定」ボタン若しくは「削除」ボタンを選択する。「商品を一つ指定」ボタンが選択された場合には、ステップ２２１１でメーカや仕様等の属性を指定する。但し、金額の上限が設定されるようにしてもよい。しかしながら、これらについては指定されなくてもよい。ステップ２２１３では、この商品と同じ分類の商品が少なくとも一つ候補表示される。例えば、買い物かごの中から見直しのために指定された商品がパソコンＰＣ９８２１であれば、他のパソコンが候補表示される。メーカー名、仕様等の指定がされている場合には、これらのデータにより絞られた上で候補が表示される。
ステップ２２１５では、ユーザが候補の内から一つを選択する。そして、ステップ２２１７で再度合計金額が算出される。その結果を見てユーザ５はステップ２２１９で購入するか否かを判断する。購入をクリックした場合には、ステップ２２２１で値引き交渉や現金還元の処理が行われる。一方、購入しない場合には、ステップ２２０７からの処理が繰り返される。
ステップ２２０７において、「予算に合うように見直し」ボタンがクリックされた場合には、ユーザ５はステップ２２２３で予算金額入力欄に予算金額を入力する。また、ステップ２２２５で商品の優先順位を指定する。商品の優先順位は、買い物かごの中に入れられた商品の内、ユーザ５が最も購入したいものの順である。ステップ２２２７では、初期値としてｎに１を設定する。ステップ２２２９では、合計金額が予算金額以上か否かが判断される。合計金額が予算金額以上の場合には、ステップ２２３１で、商品の優先順位のまず１番目に低い商品について商品を少なくとも一つ候補表示する。出来るだけ優先順位の低い商品について予算に合うように商品ランクを落とすためである。この候補表示の際は、ステップ２２３３で選択された商品よりも安い商品について色分け明示することが望ましい。このことにより、ユーザ５が商品を選択し易くなり、また、容易に予算金額以内にすることができる。
一方、ステップ２２２９で、合計金額が予算金額を下回っている場合には、ステップ２２５５で商品の優先順位のまず１番目に高い商品について商品を少なくとも一つ候補表示する。出来るだけ優先順位の高い商品について商品ランクを上げることで、予算に近づけるためである。ユーザ５が最も欲しい商品について商品ランクを上げることが望ましいからである。また、この候補表示の際には、ステップ２２５７で選択された商品よりも値段の高い商品について色分け明示することが望ましい。
ステップ２２３５では、メーカや仕様等の属性を指定するか否か問い合わせがされる。指定した場合には、ステップ２２３７でこの指定された属性によりデータが絞られる。ステップ２２３９でユーザ５にとって選択したい候補がこの中に見つかった場合にはステップ２２４１でユーザ５が候補の内から一つを選択する。選択されると、ステップ２２４３で再度合計金額が算出される。一方、ユーザ５にとって選択したい候補が見つからなかった場合には、ステップ２２５９で次の商品を変更するボタンをクリックするか、若しくは前の商品を変更するボタンをクリックする。次の商品を変更するボタンがクリックされた場合には、ステップ２２６１でｎの値がインクリメントされた上で、ステップ２２２９からの処理が繰り返される。即ち、予算金額との関係でｎ＋１番目に安い商品、若しくはｎ＋１番目に高い商品について候補表示がされる。
一方、ステップ２２５９で前の商品を変更するボタンがクリックされた場合には、ステップ２２６３でｎの値がデクリメントされた上で、ステップ２２２９からの処理が繰り返される。即ち、予算金額との関係でｎ−１番目に安い商品若しくはｎ−１番目に高い商品について候補表示がされる。
ステップ２２４５では、ステップ２２４３で算出された合計金額がステップ２２２３で入力された予算金額と比較され、この予算金額以内かどうか判断される。予算金額以内と判断された場合には、ステップ２２４７で「予算金額以内です。確定していいですか？」と問い合わせメッセージがユーザ５に対して出される。確定する場合には、ステップ２２４９に進み、購入ボタンをクリックし、ステップ２２５１で値引き交渉や現金還元の処理が行われる。一方、購入しない場合には、ステップ２２５３で候補選択に戻るが選択され、ステップ２２３５からの処理が繰り返される。
なお、ステップ２２４５で予算金額を超えていると判断された場合には、ステップ２２６５で「予算金額を超えていますが確定していいですか？」と問い合わせメッセージがユーザ５に対して出される。確定する場合には、ステップ２２４９に進み、購入処理が行われる。一方、購入したくない場合には、ステップ２２６７で候補選択に戻るか、次の商品を変更するか、若しくは前の商品を変更するのかが選択される。そして、候補選択に戻る場合には、ステップ２２３５からの処理が繰り返される。次の商品を変更するが選択された場合には、ステップ２２６９でｎの値がインクリメントされた上で、ステップ２２２９からの処理が繰り返される。即ち、予算金額との関係でｎ＋１番目に安い商品、若しくはｎ＋１番目に高い商品について候補表示がされる。
一方、ステップ２２６７で前の商品を変更するが選択された場合には、ステップ２２７１でｎの値がデクリメントされた上で、ステップ２２２９からの処理が繰り返される。即ち、予算金額との関係でｎ−１番目に安い商品若しくはｎ−１番目に高い商品について候補表示がされる。
以上により、購入の直前に予算金額に合わないことが分かった場合であってもユーザ５は予算金額に合うように面倒な処理を行うことなく簡単に見直しを行うことが可能となる。
次に、本発明の第２５実施形態について説明する。本発明の第３実施形態では直接減額の希望額Ｖ円とユーザ貯金箱への貯金額Ｔ−Ｖ円との合計である現金還元総額Ｔ円がユーザ５による直接減額の希望額Ｖ円如何にかかわらず一定である場合について説明したが、本実施形態では、直接減額の希望額の大きさ如何により変動させる方法について説明する。すなわち、ユーザ５が直接減額の希望額Ｖ円を高く希望すればする程、ユーザ貯金箱に入れられる仮想現金（若しくはポイント制が導入されていれば貯められるポイント）を上記から得られる仮想現金の金額Ｔ−Ｖ円よりも小さくするものである。従って、現金還元総額Ｔ円もその分小さくなるものである。
図７８には、本発明の第３実施形態における直接減額される金額とユーザ貯金額（若しくはポイント制が導入されていれば貯められるポイント）の関係をグラフで示す。即ち、最高限度額はＶ円であって、最高限度額Ｖ円までの直接減額が可能である。このＶ円までのなにがしかの金額ｈ円をユーザ５は直接減額の希望金額入力欄に入力する。このとき、直接減額の希望金額入力欄に入力された金額ｈ円を基に図７８のグラフからユーザ貯金箱に入れられる仮想金額ａ１円が抽出される。そして、このａ１円がユーザ貯金箱に入れられ、一方ｈ円が直接減額される。ここに、現金還元総額Ｔ＝ａ１＋ｈの関係がある。
これに対して本実施形態の直接減額される金額とユーザ貯金額（若しくはポイント制が導入されていれば貯められるポイント）の関係を図７９にグラフで示す。直接減額の方がユーザ５にとっては有り難いはずのものである一方で、商店等７にとっては再度の購入の機会が減る可能性があることを配慮し、直接減額分が大きければ大きい程ユーザ貯金箱やポイントに入れられる金額や率、ポイントを小さくするものである。
図７９中、（イ）の直線は、図７８のグラフと同様に、丁度直接減額分とユーザ貯金箱に入れられる金額の合計が総現金還元額になっている特性を示す。一方、（ロ）の直線は傾斜が（イ）の傾斜よりもきつい。（ロ）の直線は、数４で現される。
（数４）
ｙ＝Ｔ−αｘ
ここに、0≦ｘ≦Ｖ、１≦αである。αは傾斜度合を示す。最高限度額はＶ円であって、最高限度額Ｖ円までの直接減額が可能である。このＶ円までのなにがしかの金額ｈ円をユーザ５は直接減額の希望金額入力欄に入力する。このとき、直接減額の希望金額入力欄に入力された金額ｈ円を基に図７９のグラフからａ２円が抽出される。そして、このａ２円がユーザ貯金箱に入れられ、一方ｈ円が直接減額される。ここに、数５の関係がある。
（数５）
現金還元総額Ｔ０＝ａ２＋ｈ＋ｅ
ここに、ｅ円は、（イ）の特性からの差額分である。即ち、現金還元総額Ｔ０＞Ｔ１（＝ａ２＋ｈ）であり、第３実施形態と同じ直接減額分ｈ円が直接減額の希望金額入力欄に入力された場合であっても、ユーザ貯金箱に入れられる金額（ａ２円）はｅ円分だけ小さくなっている。このため、ａ２円と直接減額分ｈ円の合計である現金還元総額Ｔ１円も第３実施形態の現金還元総額Ｔ０円より小さくなっている。
直接減額の希望金額ｈ円とユーザ貯金箱に入れられる金額（ａ２円）とはユーザ５に対して提示され、ユーザ５がこの額で納得した場合には、図示しない決定ボタンをクリックすることで額が決定されるが、この額に納得しない場合には、ユーザ５は、設定見直しボタンをクリックする。この場合、再びなにがしかの希望金額ｈ円を直接減額の希望金額入力欄に入力する。以降は同様の処理が行われる。
なお、図７８、図７９の特性はリニアとしたが、曲線等であってもよい。また、（ロ）の特性と、それよりも上側に湾曲された特性と下側に湾曲された特性とをそれぞれ用意し、ユーザ５に対してくじ等でいずれかの特性を選択させるようにされてもよい。あるいは、ユーザ５のお得意様状況の段階如何によって自動的に特性が選択されるようにしてもよい。この場合には、お得意様段階の高い人は上側に湾曲された特性が採用される。
以上により、ユーザ５が直接減額の希望額Ｖ円を高く希望すればする程、ユーザ貯金箱に入れられる仮想現金は小さくすることができる。従って、販売促進につなげられると共に、ユーザ貯金箱に仮想現金が貯められていることで次回の購入もされやすい。直接減額を可能とするか否か、ユーザ貯金箱に入れられる仮想現金を認めるか否か、また、直接減額分をどの程度大きくするか、ユーザ貯金箱に入れられる仮想現金をどの程度大きくするか等、商店等７の希望も配慮されるため、商店等７側に受け入れられやすいシステムにできる。
次に、本発明の第２６実施形態について説明する。本発明の第２６実施形態では現金還元についてもまとめて値引きを考慮したものである。図８０に本発明の第２６実施形態のフローチャートを示す。図８０において、ステップ２４０１では「まとめて値引き」ボタンをクリックする。次にステップ２４０３で、値引き交渉又は現金還元の可能な商品やサービスについて、各商品等毎に値引き交渉とするのか現金還元にするのかを選択する。ステップ２４０５では、選択されたものの内現金還元のされる商品を抽出する。そして、ステップ２４０７では、現金還元のされる商品について購入総額Ｒ円を算出する。但し、この際には、購入総額Ｒ円について総額−率テーブル表より更なる還元額若しくは還元率を求めるようにされてもよい。この場合には直接減額される金額の合計か若しくはユーザ貯金箱に入れられる結果の貯金額が増やされる。
次に、ステップ２４０９では、現金還元の内、ユーザ５の指定によらず、予め商店等７側で無条件に直接減額する金額の合計Ｊ円が算出される。そして、ステップ２４１１では、この合計Ｊ円がユーザ５に対して表示される。一方、ステップ２４１３では、現金還元の内、ユーザ５が指定可能な直接減額分限度額の合計Ｋ円を算出する。ステップ２４１５では、この合計Ｋ円がユーザ５に対して表示される。ステップ２４１７では、この直接減額分限度額の合計Ｋ円に対してユーザ５が直接減額希望金額欄にＬ円を入力する。
ステップ２４１９では、各商品毎の直接減額分を求める。この各商品毎の直接減額分は、数６で現される。
（数６）
各商品毎の直接減額分＝各商品毎の直接減額分限度額ｋｎ×Ｌ／Ｋ
その後、ステップ２４２１では、ステップ２４１９で算出された各商品毎の直接減額分を基に各商品に対応した図７８若しくは図７９の直接減額分−ユーザ貯金額の関係グラフ又はテーブルからユーザ貯金箱に入れられる金額が算出される。ステップ２４２３では、各商品毎の直接減額分とユーザ貯金箱に入れられる金額とがＷｅｂページにてユーザ５に対し表示される。ステップ２４２５では、ユーザ５に対し問い合わせがされ、ユーザ５がこれで良ければ次のステップ２４２７で現金還元である各商品毎の直接減額分とユーザ貯金箱に入れられる金額とが確定され、次のステップ２４２９に進む。一方、ユーザ５が不満のある場合には、ステップ２４０７からの処理が繰り返される。
次にステップ２４２９では、選択されたものの内、値引き交渉のされる商品が抽出される。そして、ステップ２４３１では、本発明の第４実施形態等で説明したまとめて値引き交渉の処理がされる。
このようにまとめて現金還元処理とまとめて値引き交渉処理とをシリーズに処理してもよいが、Ｗｅｂ画面上に両処理を併記することで現金還元処理の直接減額希望金額欄への入力と値引き交渉処理の希望購入金額欄への入力とを同時に行えるよう並列表記されてもよい。
または、現金還元処理については、総現金還元額の全額がユーザ貯金箱に入金されるとして、値引き交渉処理の希望購入金額欄への入力のみが行えるようにされてもよいし、あるいは、総現金還元額の全額が直接減額されるとして、値引き交渉処理の希望購入金額欄への入力のみが行える等されてもよい。直接減額分とユーザ貯金箱に入金される金額とが予め設定された額にて行われるものとされてもよい。これらを選択可能なボタンが用意されてもよい。
以上により、複数の商店等７にまたがり、複数の商品等がまとまって現金還元された場合であっても各商品毎に現金還元額を分離できる。直接減額分とユーザ貯金箱に入金される金額との割合が各商品毎に異なる場合であっても各商品毎に還元額及びユーザ貯金箱に入金される金額を分離可能である。
なお、以上の実施形態は、ポイント制に基づき割引分としてのポイントが付与される場合に対して適用されることも可能である。
次に、本発明の第２７実施形態について説明する。本発明の第２７実施形態ではロボット店員による音声対応及びユーザによる音声入力により操作の簡単化を考慮したものである。図８１及び図８２に本発明の第２７実施形態のフローチャートを示す。図８１及び図８２において、ステップ２５００では、まずユーザ５がＷＷＷサーバ３のサイトにオンライン接続する。このとき、ステップ２５０１でロボット店員がユーザ５に対して挨拶をする。次にステップ２５０３では、ロボット店員が「探し物は何ですか？」との問を発する。この問は、ＷＷＷサーバ３からインターネット通信を介して音声によりユーザ５に対して行われる。
ステップ２５０５では、ユーザ５が返事をする。返事は、例えば「パソコンです。」のようにされる。この返事は、音声によりユーザ５のパソコン等に接続されたマイクや携帯電話のマイク等を通して行われる。なお、これに先立ち、ユーザ５は音声を送信データに変換し、かつＷＷＷサーバ３側に送信可能なソフトウェアをダウンロードし、ユーザ５のパソコンにインストールしているものとする。音声データはパケット化される等して送信される。あるいは、音声ファイルとしてＷＷＷサーバ３に対し送信されてもよい。送信されたデータは、ＷＷＷサーバ３側で受信され、解析された後、このデータはデータベースに保存される（以下、同旨）。解析に際しては返事の文言の中から助詞、助動詞、形容詞、副詞、接続詞等を排除し、商品名である名詞を抽出する。
ステップ２５０７では、この受信されたデータによりユーザ５が何を探しているのかを特定する。この特定は、データベースに予め保存されたデータの中に一致する商品名（若しくはジャンル）のデータが存在するか否かで判断される。特定された場合には、ステップ２５０９に進む。一方、特定出来なかった場合にはステップ２５１０で処理を終了するか、若しくは次に用意された別の処理に進む。ステップ２５０９では、ロボット店員が「メーカー名が分かれば教えて下さい。」との問を発する。この問に対してユーザ５はステップ２５１１で音声により返事を行う。音声データは送信データに変換され、ＷＷＷサーバ３側で受信され、このデータはデータベースに保存される。ステップ２５１３では、この返事によりメーカー名が特定されたか否かが判断される。この特定は、データベースに予め保存されたデータの中に一致するメーカー名のデータが存在するか否かで判断される。
特定されたならば、ステップ２５１５に進み、ロボット店員が「型式が分かれば教えてください。」との問を発する。この問に対してユーザ５はステップ２５１７で音声により返事を行う。ステップ２５１９では、この返事により型式が特定されたか否かが判断される。この特定は、データベースに予め保存されたデータの中に一致する型式のデータが存在するか否かで判断される。特定されたならば、ステップ２５２１に進み、商品を表示する。一方、ステップ２５１３、ステップ２５１９で特定されていないと判断された場合にはステップ２５２７へと進む。ステップ２５２３でユーザ５が、購入を選択した場合には、ステップ２５２５で値引き交渉又は現金還元が行われる。この値引き交渉又は現金還元において、ユーザ５による金額の入力に代えて、金額が音声入力されるようにされてもよい。音声入力された金額はインストールされているソフトウェアにより数値変換されてＷＷＷサーバ３に対し送信される。あるいは、この数値変換は、ＷＷＷサーバ３側で行われるようにされてもよい。
ステップ２５２７では、ロボット店員が「予算はいくらですか？」との問を発する。この問に対してユーザ５はステップ２５２９で予算金額をマイクを通じて音声入力したり、あるいはキー操作により入力する。そして、ステップ２５３１では、当該商品につき予めデータベースに保存されている仕様を提示し、ロボット店員が「欲しい仕様の番号を言って下さい。」との問を発する。仕様の提示は、例えば図５４のステップ１６５５等の通りである。この問に対してユーザ５はステップ２５３３で欲しい仕様の番号をマイクを通じて音声入力したり、あるいはキー操作により入力する。この辺りの処理は既に各実施形態で述べた処理と同様に可能である。その後、ＷＷＷサーバ３側では、受信されたデータに基づき検索が行われ、商品の絞り込みがされる。そして、ステップ２５３５では、絞り込みのされた結果の商品データをユーザ５に対して提示する。ロボット店員が「この商品ではどうですか？この中から一つ選択して下さい。」等の問を発する。その後、ステップ２５１９からの処理が行われる。商品が特定されなければ、再び、ステップ２５２７で予算の見直しを行い同様の処理を行う。
以上により、ロボット店員の動画像を見ながら、音声対応でユーザは商品を楽しくかつ簡単に購入できる。キー操作の不慣れな人にとっても使い易い。
なお、上述した各実施形態について本実施形態と同様にロボット店員を配置し、同様な音声対応とすることも可能である。
次に、本発明の第２８実施形態について説明する。本発明の第２８実施形態ではユーザ５が貸し店舗形式で加入した複数の商店等７と同時にまとめて一気に値引き交渉を行う場合である。ユーザ５が希望の商品について一店舗ずつ値引き交渉を行うのが煩わしいといったような場合に適用される。ＷＷＷサーバ３側にはデータベースが配設され、ユーザ５はインターネット１等の通信を介してこのＷＷＷサーバ３の提供するサイトにアクセス可能である。このサイトには複数の商店等７が貸し店舗形式で加盟している。
図８３〜図８５までに本発明の第２８実施形態の動作フローを示す。また、図８６にはＷｅｂページの画面例を示す。まず、図８３のステップ２９０１において、ユーザ５がＷＷＷサーバ３の提供するサイトのページにアクセスし、このページにおいて「複数の店とまとめて交渉」ボタンを押す。ステップ２９０３ではユーザ５はユーザＩＤ入力画面にてユーザＩＤを入力する。ステップ２９０５では、ユーザＩＤがデータベース１００９に保存されているデータと一致するか否か確認され、未登録のユーザの場合には新規登録が行われる。
ステップ２９０７では、商品を指定する。即ち、図８６において、商品名入力欄２０２１に商品を指定し、メーカー名入力欄２０２３にメーカー名を指定、型式の存在する場合には型式入力欄２０２５に型式を入力する。商品名等はキー入力されてもよいし、予め登録されたデータの内から選択されるようにしてもよい。ユーザ５により音声で入力されるようにしてもよい。そして、ステップ２９０９では、「交渉可能な商店を表示」ボタン２０４１を押して検索を実施する。ステップ２９１１では、全商店の中から、値引き交渉可能な商店が抽出されて表示される。ステップ２９１３では、この抽出された値引き交渉可能な商店の中から
ユーザ５自身がまとめて値引き交渉したい商店を選択する。但し、ユーザ５がまとめて交渉したい商店を絞らずに全商店について交渉されるようにされてもよい。ステップ２９１５ではこの選択された商店の件数ｔを算出する。
ステップ２９１７では、ユーザ５に対してＷｅｂ画面上で「値引き交渉権をｓ回分使用します」と表示される。このｓ回分は選択された商店の件数ｔに応じて変化されてもよいし、予め設定された回数分が使われるようにされてもよい。車等の高額商品についてはたくさんの回数を消費するようにする。また、後述する２回目の交渉と１回目の交渉とで変えられるようにされてもよい。キャンセルボタンが押されればステップ２９２１で処理は終了する。ステップ２９１７で了解されれば、ステップ２９１９に進みユーザ５が希望購入価格入力欄２０２７にこの商品の希望購入価格Ｚ円を入力し、入力後ステップ２９２３で値引き交渉ボタン２０４３をクリックする。ステップ２９２５では、カウンタｒの値に１を設定する。そして、ステップ２９２７では、まず１店目のデータをデータベース１００９より抽出する。このデータは各店舗毎の当該商品に対する標準販売価格、底値、実数ｍ値等である。ステップ２９２９では、値引き交渉処理が実施される。
この値引き交渉処理は、図１６の所で既に説明したのと同様に中間額Ｅ＝（Ｘ−（１−ｍ）Ｙ）／ｍと希望購入価格Ｚとが比較される。そして、中間額Ｅ円が
希望購入価格Ｚ円以下のときステップ２９３５でメモリーＵｒ１にＺ円が保存される。一方、中間額Ｅ円が希望購入価格Ｚ円を超えているとき、ステップ２９３３で底値Ｙが希望購入価格Ｚを超えるか否か判断される。底値Ｙが希望購入価格Ｚを超えているときステップ２９３７で中間額Ｅ円がメモリーＵｒ２に保存される。ステップ２９３３で底値Ｙが希望購入価格Ｚ以下のときにはステップ２９３５でメモリーＵｒ１にＺ円が保存される。
ステップ２９３９では商店件数がｔに至るまでステップ２９２５に戻り、２件目以降の商店に対し同様の値引き交渉をする。値引き交渉された結果は随時ステップ２９３５若しくはステップ２９３７でデータ保存される。そして、ステップ２９４１では、商店の名称、交渉結果価格（Ｕｒ１、Ｕｒ２）等をまとめて図８６に示すような交渉結果リストのＷｅｂページが作成される。この交渉結果リスト２０３１には、商店名称欄に商店名、東京等の営業所所在地、値引き交渉された交渉結果の金額、送料、特典等が記載されている。この交渉結果については、ボタン２０２９で商店名順に表示したり、交渉結果が安い順に表示すること等が選択可能なようになっている。特典２０３３にはおまけのある場合やポイント制を採用している場合ににその内容の詳細が閲覧できるようになっている。
なお、図８６では、中間提示額Ｅ円をも各店毎に提示する例を示したが、中間提示額Ｅ円を提示せずに「この価格では当店では売れない」と表示してもよい。あるいは、この価格で販売できない場合には空欄とされてもよい。この交渉結果リスト２０３１を見て、ユーザ５が交渉のやり直しを希望する場合には、ステップ２９４５で「値引き交渉をもう一度やり直す」ボタン２０３５を押す。
ステップ２９５５で２回目を超えたか否か判断され、超えていた場合にはステップ２９５９で処理を終了する。２回目の場合にはステップ２９５７に進み実数ｍ値の値を一段上げる。そして、以降、ステップ２９０９に戻りステップ２９０９からの処理を繰り返す。但し、１回目の交渉でユーザ５によりステップ２９１３で選択された商店等７を記憶しておき、ステップ２９１７に戻りステップ２９１７からの処理が繰り返されるようにしてもよい。ユーザ５が交渉のやり直しを希望しない場合には、ステップ２９６１で処理が終了する。
一方、ユーザ５がステップ２９４３において、この交渉結果ページから購入したい商店を一つ選択し、ステップ２９４７で図示しない購入ボタンを押すと、ステップ２９４９で交渉が成立する。この際には、ユーザ５はステップ２９５1で支払い方法の選択を行う。ステップ２９５３では、購入された商品情報が商店等７に対しＷＷＷサーバ３のサイトから送信される。
ステップ２９４７で購入ボタンが押されない場合には、ステップ２９６３でこの商店で交渉をやり直すか、若しくはステップ２９６５でステップ２９５５に戻り最初からもう一度やり直すかを選択できる。「この商店で交渉をやり直す」が選択された場合には、ステップ２９６７で「値引き交渉権をｖ回分使用します」と表示がされる。このｖ回は、通常は１回であり、ｓ回よりも小さい。キャンセルがクリックされた場合にはステップ２９７１で処理が終了する。了解されるとステップ２９６９で２回目を超えているか否かが判断される。３回目ならばステップ２９７５で処理が終了される。２回目ならば、ステップ２９７３で実数ｍ値の値を一段上げる。そして、ステップ２９７７で今回購入したい商店として選択されている商店の底値等のデータをデータベース１００９より抽出する。そして、ステップ２９８１で値引き交渉処理を実施する。その後、既に説明したステップ２９３１、ステップ２９３３の処理が行われ、ステップ２９３５、ステップ２９３７で算出された交渉結果が保存される。そして、ステップ２９８９ではステップ２９３５で保存された交渉結果に対し「Ｚ円で販売します」とユーザ５の入力された金額で販売する旨の表示がされ、一方、ステップ２９３３では、ステップ２９３７で保存された交渉結果に対し「Ｕｒ２円でどうですか？」と商店等７側の提示価格が表示される。ステップ２９９５で購入ボタンが押された場合にはステップ２９９８で「Ｕｒ円で販売します」と表示される。一方、ステップ２９９７でキャンセルボタンが押された場合にはステップ２９９９で処理が終了する。
以上により、ユーザ５は各店舗毎に値引き交渉をするということなく複数の商店についてまとめて値引き交渉が可能となる。このため、どの店が最も安く購入できそうか、若しくは最も安く購入できるか簡単かつ迅速に判断可能となる。購入したい商店も選択した上で値引き交渉可能なので便利である。
なお、本発明の第２５実施形態等で述べたように、現金還元額の内、直接減額される金額を希望金額入力欄に入力する場合においても本実施形態を適用可能で
ある。即ち、貸し店舗形式で加入した複数の商店等７を相手に、同一の直接減額される金額に対しユーザ貯金箱に入れられる仮想現金の額を一度に得ることができる。
この場合にはまず、検索によりステップ２９１１では直接減額の可能な商店が表示される。そして、ステップ２９１９では希望金額入力欄に直接減額の希望額を入力すると、ステップ２９２７以降の処理でユーザ貯金箱に入れられる仮想現金の額（ポイント制が導入されていればポイント）が各商店等７毎に演算されステップ２９４１でまとめて表示される。ステップ２９４３でユーザ５がこの結果ページから購入したい商店等７を一つ選択し、ステップ２９４７で購入ボタンを押せば商品等を購入することができる。但し、ステップ２９５５の２回目以降の処理やステップ２９６３以降の処理は値引き交渉に必要な処理なので省略される。
次に、本発明の第２９実施形態について説明する。本発明の第２９実施形態では貸し店舗形式で加入した商店等７及び求職者であるユーザ５に対しＷｅｂ上で自動により簡便なリクルート手法を提供するものである。
図８７〜図９２に本発明の第２９実施形態のフローチャートを示す。図８７及び図８８は、まず就職希望者の側から企業や商店等に対し就職のアプローチをする場合である。図８７において、ステップ２６０１では、まず就職希望者であるユーザ５がＷＷＷサーバ３のサイトにオンライン接続する。そして、あらかじめ就職希望者登録情報をＷＷＷサーバ３のデータベース１００９に対し登録する。この就職希望者登録情報は、例えば氏名、性別、年齢、住所、電話番号、メールアドレス、写真等の履歴書に記載される事項、職務経歴である。また、本人を撮影した動画（音声付きが望ましい）等がデータベース１００９に保存されるようにしてもよい。一方、貸し店舗形式の店舗に関し、リクルート項目を各商店や各サービス店のＷｅｂページに載せる。
なお、各商店や各サービス店がリクルート中であることは検索によっても分かる。例えば、検索の項目に現在リクルート中の商店等７を選択する項目を設けることで抽出可能である。現在リクルート中の商店等７であることは、データベース１００９に保存されたリクルート期間を検索することで分かる。ユーザ５が商店や各サービス店のＷｅｂページやリクルート情報を閲覧し、商店等７に面接を希望した場合には、ステップ２６０３でリクルート項目中の面接希望ボタンを押す。その後、ステップ２６０５では、ログイン画面にてユーザＩＤを入力する。
ステップ２６０７では、履歴書の情報の一部がデータベース１００９より抽出される。このとき、履歴書の情報としては、氏名、住所、電話番号、メールアドレス、写真あるいは本人の動画（音声付きが望ましい）等は掲載されずにその他の情報が抽出される。但し、このときに写真あるいは本人の動画（音声付きが望ましい）等が掲載されるようにしてもよい。写真あるいは本人の動画、音声付きとするか否かはユーザ５本人の選択事項とされてもよい。ステップ２６０９では、この履歴書の情報の一部の掲載された電子メールが商店等７に送信される。なお、電子メールではなく、ファックス等で履歴書の情報の一部を掲載した情報等が送受信されてもよい（以下、同旨）。
ステップ２６１１では商店等７がこの電子メールを受信する。そして、商店等７が希望する場合にはステップ２６１３でセンターサーバー１００８の商店閲覧画面にログインする。但し、ログインはこのように商店閲覧画面にてログインＩＤを入力することでサイトに入り行ってもよいが、電子メールに記載されたＵＲＬが選択されることで専用のページに飛んで以降の処理がされてもよい。また、専用のページに飛ぶことなく、電子メールに記載された事項に応答し返信、若しくは電子メール中の特定のＵＲＬが選択され送信されるだけでセンターサーバー１００８側では返答と見なし、以降の処理が完結されるようにしてもよい。
商店閲覧画面には、ユーザＩＤ、年齢、ユーザによる送信日時、商店による面接受諾ボタン、面接希望日時入力欄等が記載されている。そして、ステップ２６１５では、商店閲覧画面から面接を受諾するユーザＩＤを選択し、ステップ２６１７で面接希望日時の候補を少なくとも一つ指定する。この指定は、センターサーバー１００８にてＷｅｂページに掲載されたカレンダーに従って入力されることが望ましい。
ステップ２６１９では、商店閲覧画面の中の面接を受諾するユーザＩＤに対して面接受諾ボタンを押す。面接の受諾された旨はセンターサーバー１００８に記録されると同時に、ステップ２６２１で就職希望者に対し自動配信で受諾の旨の電子メールが送信される。ステップ２６２３で就職希望者が電子メールを受信する。この就職希望者は、ステップ２６２５でセンターサーバー１００８にログインし、ステップ２６２７で商店等７より指定された面接希望日時の候補の中から一つを選択する。ログインはユーザ閲覧画面にてログインＩＤを入力することでサイトに入り行ってもよいが、電子メールに記載されたＵＲＬが選択されることで専用のページに飛んで以降の処理がされてもよい（以下、同旨）。
このことにより、ステップ２６２９では、センターサーバー１００８より正式な全経歴情報を商店に対し電子メールにて自動配信する。この全経歴情報には、ステップ２６０７とは異なり、履歴書の情報のすべてがデータベース１００９より抽出される。ステップ２６３１では、商店等７が全経歴情報及び面接日時の記載された電子メールを受信する。 なお、正式な全経歴情報等は、ステップ２６１９で面接受諾ボタンが押されたときにセンターサーバー１００８より送信されるようにされてもよい。
ステップ２６３３では、商店等７がセンターサーバー１００８にログインし、ステップ２６３５でこのユーザＩＤの就職希望者との面接について確認（了解）した旨のＷｅｂページの確認ボタンを押す。なお、ログインは商店閲覧画面にて行ってもよいが、電子メールに記載されたＵＲＬが選択されることで専用のページに飛んで確認処理がされてもよい（以下、同旨）。 この際には商店等７からメッセージ記入欄にメッセージが記入されることが望ましい。この確認ボタンが押されると、ステップ２６３７では、確認メッセージがユーザ５に送信される。
ステップ２６３９で商店等７と就職希望者であるユーザ５との間で面接が行われる。面接の実施後、ステップ２６４１では、商店等７がセンターサーバー１００８の商店閲覧画面にログインする。そして、ステップ２６４３で商店閲覧画面上で採用、不採用、キャンセルのいずれかの項目を選択する。選択された項目はセンターサーバー１００８のデータベース１００９に保存されると共にユーザ５に対して送信される。ところで、ステップ２６４５では、就職希望者に対し所定期間以内に電子メールが送信されたか否かが判断される。所定期間は採用に際しての検討時間であり、例えば５日〜１４日程度である。この所定期間が経過している場合にはステップ２６５１で問い合わせの電子メールが商店等７に対して送信される。但し、就職希望者に対しても問い合わせの電子メールが送信されてもよい。問い合わせの電子メールは、１回ではなく、一定期間経過毎に複数回行われるようにされてもよい。ステップ２６４７で延長期間が設定されている場合には、ステップ２６４９でこの延長期間の経過後に問い合わせの電子メールが送信される。なお、問い合わせの結果、商店等７がステップ２６４１からの処理を行った場合には、ステップ２６４５での所定期間以内かどうかの判断はされない。
ステップ２６５３で就職希望者が内定した場合には、ステップ２６５５でこの就職希望者に対して、値引き交渉権が例えば１０回分付与され、また商店等７の有するユーザ貯金箱に例えば１万円の貯金が加算される。あるいは、ＷＷＷサーバ３のサイトの運営者において用意されたユーザ貯金箱に貯金されるようにしてもよい。ユーザ５はこのユーザ貯金箱の貯金を利用して当該商店やＷＷＷサーバ３のサイトの運営者より商品を購入することができる。このように、ユーザ５に対して特典を付与することで利用が促進される。一方、商店等７側にとってはユーザ５に対して本システムを介して返事をする義務が生ずることになるので、本システムの円滑な運用が図れる。
なお、面接実行回数に対する採用、不採用、キャンセル等のいずれかの返事を商店等７側がユーザ５に対して送信した比率を演算し、公表することが望ましい。返事をしなければ企業としての評判が悪くなるので企業側は注意せざるを得なくなる。このように、企業の評価をすることで、企業の不正を防止する。このため、例えば、内定率（内定者数／申し込み者数）を演算したり、面接受諾率を演算する。若しくは、内定が出るまでの平均日数や面接がされるまでの平均日数を演算する。更に、以上の評価項目を点数評価したり、重み付け処理をし、合計する。そして、これらの演算結果をホームページ上に評価基準として掲載する。更に、ユーザ５の平均ユーザ貯金箱への入金取得額やユーザ５の平均値引き交渉可能回数取得数を掲載するようにしてもよい。
以上により、Ｗｅｂ上で円滑なリクルート活動の支援が可能となる。企業側からの対応も速やか、かつ確実に行われるようになる。省力化されているため求職、求人情報を安価に提供できる。各商店等へのリクルート絡みのアクセス数が増加するので販売増及び宣伝効果増に結びつくと共に、ユーザへの特典が付与されることで各商店等の購入が一層増加される。
次に、本実施形態の別形態について説明する。図８９及び図９０は、企業や商店等側から就職希望者側に対し就職のアプローチをする場合である。なお、図８７及び図８８と同一要素のものについては同一符号を付して説明は省略する。
図８９において、ステップ２７０１では、まず、ユーザ５から就職希望者としての登録情報を集める。この登録は、ユーザ５がＷＷＷサーバ３のサイトのホームページ上で所定の欄にキー入力等により行われるのが望ましい。そして、集められた登録情報は登録者情報としてデータベース１００９に保存しておく。
ステップ２７０３では、商店等７側がセンターサーバー１００８にログインし、ステップ２７０５で商店等７は就職希望者を検索する。検索項目はジャンルや年齢、勤務地、希望給与等である。ジャンルは今後就きたい職や、これまでに経験した職、実務能力を有する職等である。
ステップ２７０９では、検索結果として一致するデータが存在する場合に、登録情報の内のごく一部のみを抜粋してホームページにて掲載する。この情報はステップ２６０７で記載した情報の一部よりずっと少ない情報である。例えば、年齢、職歴、学歴の抜粋、自己ＰＲ文程度である。そして、この情報を見た商店等７が興味を持った就職希望者が存在する場合には、ステップ２７１１で商店等７は履歴情報希望ボタンを押す。このとき、ステップ２７１３では、履歴書の情報の一部がデータベース１００９より抽出される。この履歴書の情報の一部はステップ２６０７で記載した情報と同じである。
ステップ２７１５でこの履歴書の情報の一部を掲載した電子メールが商店等７に対し送信される。ステップ２７１７では、この履歴書の情報の一部を読んで商店等７側では面接を希望する就職希望者を絞り込む。そして、絞り込んだ就職希望者に対し商店等７は、ステップ２７１９で商店閲覧画面にログインで入り、商店閲覧画面上で面接希望日時の候補を少なくとも一つ指定した上で、ステップ２７２１でこの就職希望者に対し商店閲覧画面上に配設された面接希望ボタンを押す。このとき、ステップ２７２３でセンターサーバー１００８より就職希望者に対し電子メールが送信され、ステップ２７２５でこの就職希望者が電子メールを受信する。この電子メールには、商店等７の企業情報及び当該就職希望者に対し面接を希望する旨の記載がされている。
その後、ステップ２７２７では、就職希望者が望めばセンターサーバー１００８の指定画面にログインする。そして、ステップ２７２９では、指定画面の中の面接を受諾する商店ＩＤに対して面接受諾ボタンを押し、かつステップ２７３１では、就職希望者がこの指定画面上に表示された面接希望日時の候補の中から一つを選択する。この面接希望日時の候補はステップ２７１９で予め商店等７により設定されたものである。このとき、ステップ２７３３で商店等７に対し自動配信で受諾の旨の電子メールが送信される。そして、同時にステップ２７３５で正式な全経歴情報が商店等７に対し自動配信される。その後はステップ２６３９で面接が行われ、以降ステップ２６４１からの処理が同様に行われる。
以上により、商店等７が希望する人材を容易に得ることができる。省力化されているため求職、求人情報を安価に提供できる。
次に、本実施形態の更なる別形態について説明する。図９１及び図９２は、ＷＷＷサーバ３のサイトの運営者より就職希望者の情報を企業や商店等に対し随時提供し、これらの就職希望者の情報の中から企業や商店等側が面接を望む就職希望者が存在した場合に就職希望者側に対し就職のアプローチをする場合である。なお、図８７及び図８８と同一要素のものについては同一符号を付して説明は省略する。
図９１において、ステップ２８０１では、まず、ユーザ５から就職希望者としての登録情報を集める。この登録は、ユーザ５がＷＷＷサーバ３のサイトのホームページ上で所定の欄にキー入力等により行われるのが望ましい。この場合、写真等は画像ファイルとして保存される。そして、集められた登録情報は登録者情報としてＷＷＷサーバ３のサイトのデータベース１００９に保存しておく。また、これに先立ち、予め商店等７に対してどのようなジャンルの人材を探しているのか、あるいは、どのような年齢や経歴の人材を探しているのか等をＷＷＷサーバ３のサイトのホームページ上で所定の欄に入力してもらっておくことが望ましい。または、ＷＷＷサーバ３のサイトの管理者側でこれらの情報を予め入力しておいてもよい。これらのデータは求人情報としてＷＷＷサーバ３のサイトのデータベース１００９に保存しておく。
ステップ２８０３では、このような商店等７の求人情報を基に希望に合いそうな就職希望者がＷＷＷサーバ３のサイトの管理者により検索若しくは抽出され、その履歴書の情報の一部がデータベース１００９より抽出される。あるいは、サイトの管理者によらず、商店等７の求人情報を基にデータベース１００９から自動で検索されてもよい。そして、ステップ２８０５では、この履歴書の情報の一部を掲載した電子メールが商店等７に送信される。履歴書の情報の一部には少なくとも一人の就職希望者の情報が含まれている。ステップ２８０７では、商店等７がこの電子メールを受信する。なお、電子メールではなく、ファックス等で履歴書の情報の一部を掲載した情報等が送受信されてもよい。
商店等７がこの履歴書の情報の一部を見て就職希望者との面接等の希望が生じた場合には、ステップ２８０９に進み商店等７がセンターサーバー１００８の商店閲覧画面にログインする。この際、商店等７が未登録の場合には商店等７の情報をまず登録する。そして、ステップ２８１１では、商店閲覧画面に掲載された面接を希望するユーザ５の一覧の中から希望のユーザＩＤを選択した上で面接希望ボタンを押す。
このとき、ステップ２８１３では、このユーザＩＤを有する就職希望者に対しセンターサーバー１００８より自動配信で商店側からの面接希望の旨を記載した電子メールが送信される。ステップ２８１５で就職希望者がこの電子メールを受信する。就職希望者が商店等７に興味を抱いた場合にはステップ２８１７に進み、就職希望者がセンターサーバー１００８にログインする。ログインするとユーザ閲覧画面が開かれる。このユーザ閲覧画面には面接希望のあった商店等７のＵＲＬが記載されており、このＵＲＬから商店等７のリクルートページや業務内容のページを参照できるようになっている。但し、就職希望者に対し送信される電子メールに面接を希望する商店等７の求人情報が記載されてもよい。商店等７の求人情報はセンターサーバー１００８のデータベース１００９に予め登録されていることが望ましい。
ステップ２８１９で、ユーザ５が商店側からの面接希望を受諾する場合には、このユーザ閲覧画面上で面接受諾の旨と面接希望日時の候補を少なくとも一つ指定する。このとき、ステップ２８２１では、商店等７に対し自動配信で受諾の旨の電子メールが送信される。これに対し、ステップ２８２３では、商店等７がセンターサーバー１００８にログインし、ステップ２８２５では、商店等７はステップ２８１９で指定された面接希望日時の候補の中から一つを選択する。選択された情報はデータベース１００９に保存され、ステップ２８２７でセンターサーバー１００８より正式な全経歴情報が商店等７に対し電子メールで自動配信される。ステップ２８２９では、商店等７がこの全経歴情報及び面接日時を受信する。ステップ２８３１では、この電子メールを受け取り、記載された情報を確認した旨を伝えるため商店等７がセンターサーバー１００８にログインし、かつステップ２８３３で確認ボタンを押す。この確認された旨はステップ２８３５で確認メッセージとしてユーザ５に対し送信される。この確認メッセージには、商店等７が確認した旨と面接日時や場所等が記載されている。その後はステップ２６３９で面接が行われ、以降ステップ２６４１からの処理が同様に行われる。
以上により、商店等７に対し適材と思われる人材が随時推奨されるので商店等７は希望する人材を容易に得ることができる。省力化されているため求職、求人情報を安価に提供できる。
なお、本実施形態の機能は貸し店舗形式で加入された商店等７のＷｅｂページの一部にアイコンが埋設され、リンクされた機能とされてもよいし、商店等７の自前のホームページのリクルート欄に所定のアイコンが埋設され、このアイコンがクリックされることでセンターサーバー１００８に繋がり、本実施形態の機能が動作されてもよい。あるいは、就職専門のサイトとして構築されてもよい。
次に、本発明の第３０実施形態について説明する。本発明の第３０実施形態は第５実施形態〜第８実施形態で説明した実際に商品等が店頭販売される場合の別態様についてである。図９３に本発明の第３０実施形態のフローチャートを示す。なお、図３４〜図３７と同一要素のものについては同一符号を付して説明は省略する。図９３において、ステップ１３５１では、ユーザ５はスーパー等の各商店等７に赴き、この店内において買い物をする。そして、購入したい商品を買い物カゴに入れる。なお、図３７と同様にステップ１２２５〜ステップ１２３１の処理が行われるようにされてもよい。
ステップ１２３３で集計され、ステップ１２３５でレジ１１１１に合計金額を表示する。その後、その商店等７において用意、かつ配布され、ユーザ５が保持している専用カードが読み取り装置に通される。この専用カードには予め登録されたユーザ５のユーザＩＤ等のデータが磁気により保存されている。あるいは、ユーザ５のユーザＩＤ等のデータを保存したＩＣチップが埋設されている。読み取り装置では、これらのデータが磁気的に読み取られ、センターサーバー１００８に通信回線を通じて送信される。なお、専用カードを忘れたユーザ５に対しては、以下のように処理することでユーザ５を特定可能である。まず、レジ係がセンターサーバー１００８のデータベース１００９にアクセスした状態で、ユーザ５から聞き出した電話番号の下４桁を入力する。このとき、センターサーバー１００８でユーザの検索が行われ、電話番号の下４桁の一致するユーザ５のデータが少なくとも一人分抽出してレジ係に対して表示される。次に、レジ係はユーザ５から聞き出したユーザ５の氏名を基にこの表示されたデータの内から一つ選択することでユーザ５を特定できる。また、センターサーバー１００８のデータベース１００９にアクセスした状態で、ユーザＩＤを直接入力するようにされてもよい。
次に、ステップ３１１３では、レジ１１１１にてユーザ５により実際に支払がなされる。そして、ステップ３１１５ではレシートが発行される。このレシートには、購入日、購入店、ユーザＩＤ、購入品名、支払金額等が表示される。但し、電話番号の下４桁、ユーザの氏名等が記載されてもよい。これらのデータはステップ３１１７でセンターサーバー１００８のデータベース１００９に保存される。ステップ３１１９では、購入日から所定期間（例えば１０日）以内か否かが判断される。そして、所定期間内の場合には、ステップ３１２１でパソコン又は携帯電話からセンターサーバー１００８に接続し、個別の商品毎に、あるいは購入回毎にまとめて値引き交渉がされる。この値引き交渉については各実施形態で述べた通りである。ステップ３１２５では、値引き交渉による決定金額が算出される。そして、ステップ３１２７では支払金額から決定金額が差し引かれ、ステップ３１３１ではこの差額がユーザ貯金箱に貯金される。そして、ステップ３１３３では、この事実がユーザ５に対し電子メールで伝えられる。一方、ステップ３１１９で所定期間を経過した場合には、ステップ３１２９で各商品毎に設定された現金還元額が合計され、ステップ３１３１でこの現金還元額の合計がユーザ貯金箱に貯金される。ステップ３１３３では、この旨がユーザ５に対し電子メールで伝えられる。
ユーザ貯金箱に貯金された仮想現金は次にユーザ５が商品等を購入する際に利用できる。この場合、ユーザ５はＷＷＷサーバ３のサイトの管理者側で運営する貸し店舗である当該商店等７のＷｅｂサイトに接続し商品等を購入する際にユーザ貯金箱から仮想現金を引き出して使うことが可能である。あるいは、当該商店等７が自前で有する当該商店等７のＷｅｂサイトに接続し、ユーザ５が商品等を購入する際に、このＷｅｂページに埋設されたアイコンがユーザ５によりクリックされることでＷＷＷサーバ３のサイトにリンクされ、この仮想現金を引き出して使う処理ルーチンがＷＷＷサーバ３のサイト側で動作されるようにしてもよい。更には、レジ１１１１にてステップ３１１３で支払を行う際にセンターサーバー１００８に接続し、ユーザ貯金箱から仮想現金を引き出してその場で使う等されてもよい。この場合には、レジ係が貯められた仮想現金の内の幾ら分を使うかをユーザ５から聞き出して入力操作を行う。
なお、上記では１回の支払単位に値引き交渉を行うとして説明したが、月単位に複数の支払回分をまとめて値引き交渉をしてもよい。このとき、複数の商品をまとめて値引き交渉や現金還元処理する必要があるが、この処理については本発明の第４実施形態の説明で述べた通りである。また、各ユーザ毎に複数の異なる商店分について月単位にまとめて値引き交渉や現金還元処理をしてもよい。このとき、複数の商品について複数の商店に渡りまとめて値引き交渉や現金還元処理する必要があるが、この処理についても本発明の第４実施形態の説明で述べた通りである。更に、本発明の第４実施形態の説明で述べたように、まとめたことで更なる値引きがされるように処理されてもよい。更に、本実施形態ではレジ１１１１にて購入する場合について説明したが、本発明の第７実施形態のようにテレビショッピング等で商品が購入された場合についても同様に適用可能である。
なお、月単位にまとめた購入履歴は、ユーザ５に対してＷＷＷサーバ３のサイトの管理者側で閲覧や印刷可能とすることが望ましい。
以上により、ユーザは商店で商品を購入後、値引き交渉により自分の意思で支払金額が減額されることになるので、買い物が楽しく行える。また、値引き交渉がユーザにより行われなかった場合であっても現金還元の処理がされるので、ユーザにとっては安心である。従って、本システム利用に伴い、商店等の売上増にもつながる。
更に、ユーザは商品購入後も値引き交渉等のためＷＷＷサーバ３のサイトのショップ等を頻繁に訪れることになるので、サイトのアクセス数が増大し販売の増加や宣伝効果の増大につなげることができる。
次に、本発明の第３１実施形態について説明する。最近、例えば個人同士の取引をネット上で行う場合、支払をしても購入した商品が届かなかったり、商品を届けても支払が行われなかったりする事例が多く報告されている。そこで、本発明の第３１実施形態はユーザ貯金箱を利用することで、ネット上の取引（特に個人同士の間で行われる取引）がこのような支障無く安全に行われ、かつ銀行等への振込手数料やカード会社等への手数料が無料若しくは格安にでき、更に買物を一層便利にすることができるシステムを提供するものである。
図９４に本発明の第３１実施形態のフローチャートを示す。図９４において、ステップ３１５１では、商品購入者によりネット上で商品購入の申請が行われる。この際には、商品購入者は個人又は法人である商品販売者が提供する商品を購入する旨の申請をインターネット接続画面にて行う。商品購入者の情報は購入申請前にＷｅｂ画面上で登録するようになっている。商品の提供はネットショップ、ネット通信販売、オークション、個人間取引等その形態は問わない。
ステップ３１５３では、商品販売者側で商品登録時等の際に「ユーザ貯金箱による支払を希望」のみが支払方法として選択されているか否かが判断される。ユーザ貯金箱は図９５の概念図に示すようにＷＷＷサーバ３のデータベース１００９に各ユーザ５毎に用意されている。そして、このユーザ貯金箱には、ユーザ５が商品をサイトで購入する際に、商店等７により設定された現金還元額がユーザ５に対し還元されるようになっている。この現金還元額は、ユーザ５が実際に支払う金額の内の一部であって、このユーザ貯金箱に貯められるようになっている。そして、現金還元額は仮想現金としてユーザ貯金箱に貯められ、次の商品購入の際にこの仮想現金を使って支払金額の一部又はすべてとして利用できるものである。
商店等７にとってはリピーターを増やすことができる。こうして貯められた仮想現金は、商店等７の行うサービスの一種として貯蓄のあった日から２年経過すると償却されるようになっている。但し、この期間内にユーザ５により新たな商品の購入のあった場合には、この最終購入日から更に２年等の期間が延長されるようになっている。即ち、ユーザ５による購入の継続する限りユーザ５は半永久的に仮想現金を使い続けることができる。しかしながら、ユーザ５による購入が継続しない場合であっても半永久的に消滅しないようにされてもよい。
このユーザ貯金箱にはまた、実際の現金（以下、仮想現金に対し実現金という）が入金されるようになっている。現金の入金は、銀行口座を利用する場合、同一の支店を利用すれば無料となる。同一の銀行支店間の取引においても手数料は安くなっている。この入金は、例えば、ユーザ５から銀行等に振り込まれた金額を確認したサイトの係員が、データベース上に配設されたユーザ５のユーザ貯金箱に対しデータ（金額）を加算することで行う。しかしながら、この間の処理を係員を介さず自動にて連携されるようにしてもよい。また、ユーザ貯金箱を銀行口座等と独立させずに一体化してもよい。この場合にも手数料は無料若しくは安くできる。
また、このユーザ貯金箱には、ユーザ５による支払金額が実際に商品購入の際に支払うべき金額を誤って超えて支払われたような場合にもその超過金額分が貯金されるようになっている。即ち、この超過金額分はユーザ５に直接返却されるのではなく、ユーザ貯金箱に貯金される。超過金額分は実金額として扱われるようになっている。
このように、ユーザ貯金箱は仮想現金の貯められる仮想現金部分と実現金の貯められる実現金部分とで構成されている。
なお、商品購入に際しては、仮想現金部分に償却期間が設けられた場合には、仮想現金部分よりも実現金部分の方から先に代金に充てるようにプログラムされるのが望ましい。
更に、このユーザ貯金箱には、後述するように他のユーザ貯金箱より振込がされるようになっている。振込のされた金額は実金額として扱われるようになっている。
そして、商品購入の際には、仮想現金と実現金とを加算した形でその合計金額の中から支払をすることができるようになっている。この際には、実現金の部分から先に支払を行い、実現金では賄いきれなくなったとき不足部分について仮想現金を使うというように処理されることが望ましい。
図９５の場合には、商品購入のあったとき、商品販売者であるＢさんのユーザ貯金箱に商品購入者であるＡさんのユーザ貯金箱から支払（振込）がされるようになっている。この支払（振込）は商品購入の意思表示のあってから例えば３カ月経過後に確定され、支払（振込）が実行される。３カ月経過していれば、商品販売者側から商品購入者側に商品が届けられていると想定されるからである。ステップ３１５３では、このように、取引の安全や手数料金額を抑えることを希望する商品販売者が、予め「ユーザ貯金箱による支払を希望」の項目をセンターサーバーに対し登録している場合である。
この項目がセンターサーバーで選択かつ登録されている場合には、ステップ３１５５でその旨が商品購入者側に対しＷｅｂ画面上で表示される。商品購入者は、この商品販売者の提示した「ユーザ貯金箱による支払を希望」に同意するか否かを決め、同意のボタンをクリックした場合にはステップ３１５７に進む。同意しなかった場合にはステップ３１５９で処理は中止され、商品購入者は商品を購入することが出来ない。
ステップ３１５７では、商品の価格（決定価格）Ｌ円を抽出する。商品の価格は例えば値引き交渉による場合には値引き交渉により決定した価格である。ステップ３１６１では、商品購入者の有するユーザ貯金箱の貯金額Ｓ円を抽出する。そして、ステップ３１６３でユーザ貯金箱の貯金額Ｓ円と商品の価格（決定価格）Ｌ円を対比する。商品の代金を支払うだけの十分な金額が商品購入者の有するユーザ貯金箱に残っているか否かを判断するためである。
ユーザ貯金箱の貯金額Ｓ円が商品の価格（決定価格）Ｌ円以上のとき、ステップ３１６５に進み、商品の価格（決定価格）Ｌ円を一時商品販売者側のユーザ貯金箱に仮保存し、かつユーザ貯金箱の貯金額を一時Ｓ−Ｌにて仮保存する。このとき、商品購入者のユーザ貯金箱の貯金額は一時Ｓ−Ｌになっているので、商品購入者はユーザ貯金箱の貯金額を全額使ってＳ−Ｌ円を超えた商品購入の支払は出来なくなる。取引が完了するまでの期間、商品価格相当の金額を一時預かりするためである。但し、一部内金という形を認めることにしてＳ−Ｌ円を超えた商品購入を可能としてもよい。
ステップ３１６７では、商品販売者側に商品が購入された旨の通知がされる。通知は電子メールで行われる。この通知があったときには商品販売者側は商品を商品購入者に対し配送する。
ステップ３１６９では、キャンセルが取引完了すると想定される例えば３カ月以内の間にされたか否かが判断される。通常であれば、この期間内に商品も商品購入者側に到達していると考えられ、キャンセルはされない。この場合には、ステップ３１７１に進み３カ月経過後に仮保存データがＢさんのユーザ貯金箱に自動にて確定され、商品販売者側であるＢさんでは、この確定した金額を使用することができるようになる。入金された金額は実現金として扱われる。
確定の際には、サーバーより電子メールにて確定の旨の通知がされる。但し、商品購入者側から商品到着の旨の電子メール等による通知をサーバー側で受けたことを条件に取引成立とし、ステップ３１７１での確定処理を行うようにしてもよい。この電子メール等による通知作業はユーザ５にとっては煩わしいので、正常に取引の行われている場合にはユーザ５に対し何も負担をかけず、商品が到達しなかった場合に限りキャンセルの旨を通知させるようにするのが望ましい。
３カ月の期間内に商品販売者側から商品が届かない等の事情が生じた場合には、ステップ３１６９で商品購入者側からの申請により取引をキャンセルできる。キャンセルは、サーバーに対しログインし、「商品がまだ届いていない」ボタンを押すことで可能である。キャンセルのあったときには、その旨は商品販売者側にも電子メールで通知される。その後、所定期間経過後（例えば２週間経過後等）にキャンセル状態は確定し、ステップ３１７３でステップ３１６５における仮保存データを取引前の状態である元に戻す。所定期間を設定したのは、キャンセルが虚偽で行われた場合に、商品販売者側に異議を唱える機会を設けたためである。キャンセルの確定した場合には、商品の売買は成立せず、商品購入者の有するユーザ貯金箱は貯金額Ｓ円に戻される。
但し、虚偽のキャンセルがされた場合を配慮して、キャンセルのあったときには、キャンセルの旨が商品販売者側に通知される一方で、３ヶ月経過してもデータの確定が自動ではされないようにしてもよい。そして、データを元に戻すのは、係員の判断に基づき手動とされてもよい。
「３カ月」等の期間は商品販売者と商品購入者との間で自由に決められるのが望ましい。例えば、ネットを介して「２カ月でどうですか」との一方側の希望申請（期間を選択させる）に対し、「良いです」等相手側が返答ボタンを押すことで確定する等のようにされてもよい。
ステップ３１７５においては、商品販売者側で事前に「ユーザ貯金箱による支払を希望」のみが予め選択されている訳ではないが、「ユーザ貯金箱による支払を希望」が支払方法項目の一つとして選択されているか否かが判断される。選択されている場合であって、かつステップ３１７７で商品購入者側でも「ユーザ貯金箱による支払を希望」が選択された場合には、商品販売者及び商品購入者の双方共にユーザ貯金箱による支払を希望していることになるので、ステップ３１５７以降で説明したように、互いのユーザ貯金箱間を利用して支払が行われる。
ステップ３１７５で商品販売者側で「ユーザ貯金箱による支払を希望」が支払方法項目の一つとして選択されていない場合や、ステップ３１７７で商品購入者側で「ユーザ貯金箱による支払を希望」が選択されなかった場合には、ステップ３１７９で銀行振込や郵便振替、着払い、カード支払、コンビニ支払等の他の方法であって、かつ商品購入者の指定した支払方法となる。
ステップ３１６３でユーザ貯金箱の貯金額Ｓ円と商品の価格（決定価格）Ｌ円を対比した結果、ユーザ貯金箱の貯金額Ｓ円が商品の価格（決定価格）Ｌ円未満のとき、ステップ３１８１に進む。この際には、Ｗｅｂ画面上で商品購入者に対し、ユーザ貯金箱の残金が不足している旨のメッセージが出される。ステップ３１８３で補充のあった場合には、ステップ３１５７からの処理が繰り返される。補充の無かった場合には、ステップ３１８５で処理が中止される。
以上のように、ユーザ貯金箱を利用して商品販売者と商品購入者間の支払を行わせることで、代金を支払ったのに商品が届かない状況や、商品を送ったのに代金の支払が無い等の事態を防止できる。個人対個人等の取引で、お互いに信頼関係がない状況でも安全に取引を行うことができる。なお、図９５において、商品販売者であるＢさんは、Ａさんよりユーザ貯金箱に支払を受けた金額を元に自ら他の商品を購入し、その購入の代金に充てることができる。
商品購入に際しては、商品購入の都度現金還元された額を貯めた仮想現金部分とＡさんより支払を受けた実現金部分との両方の額を使用することができるので便利である。また、この際には送金手数料等の負担もない。
Ｂさんはまた、貯めた貯金（実現金部分）を降ろすことができる。貯金を降ろす場合には、センターサーバーに対し申請をする。申請の金額は貯金額を超えることはできない。その後、サイトの運営会社より申請のあった金額が所定の銀行口座等に振り込まれる。貯金は、取引の都度降ろすこともできるが、複数回分の取引をまとめて降ろすようにすることで銀行手数料等は取引の都度降ろす場合に比べ実質安く抑えることができる。降ろさずに継続して貯められる場合には、手数料は一切かからず、便利である。降ろさない場合であっても、買物の支払に利用できる。
以降、同様に図９５に示すようにＢさんが商品購入者になり、商品販売者であるＣさんから商品を購入し、この商品代金をＢさんはユーザ貯金箱から支払うことができる。
オークション等の個人間取引にも有効であり、取引を安全に行い、かつ手数料等を無料、若しくは安く抑えることができる。なお、本実施形態はポイント還元制に適用されてもよい。この場合には、貯めたポイントを現金に換算した上で支払を実施したり、逆に支払を受けた現金をポイントに換算する演算部分が必用となる。但し、支払を受けた現金はそのまま貯めるようにされてもよい。
次に、本発明の第３２実施形態について説明する。本発明の第３２実施形態は、商店等７がＷｅｂ上で簡単にセールを行えるシステムについてである。従来、商店等７が日常の販売以外にセールを行おうとする場合、改めてセールのホームページを別に作ったり、セール商品を混在させた形でホームページを作り、セールを開始する。そして、セールの終了したときには、元のセール前の状態のホームページに戻す必要があった。そして、手動にてセール終了を行った場合には、購入処理のセッション途中にあるユーザ５に対して、途中で購入処理が継続出来なくなる等多大の迷惑をかけるおそれがあった。
また、このホームページが貸し店舗形式で行われるＷＷＷサーバ３に掲載された場合には、セール品を含むホームページの更新をＷＷＷサーバ３のサイトにその都度依頼しなければならず不便であった。
そこで、本発明の第３２実施形態は、商店等７がセール品やサービス品の金額や商品情報等を通常販売データから修正若しくは追加するだけで、いつでも簡単にセールを設定出来、かつセールの終了時において何らの処理も不要であるＷｅｂ上でセールを行えるシステムを提供するものである。
図１０９及び図１１０に本発明の第３２実施形態のフローチャートを示す。図１０９は、商店等７がＷＷＷサーバ３にアクセスし、セールの準備を行う処理について説明している。図１１０は、ユーザ５がセールにて商品等を購入する処理について説明している。
図１０９において、ステップ３２０１では、商店等７がＷＷＷサーバ３にアクセスし、セールの準備を開始する。ユーザ５はステップ３２０３で図示しない商店設定画面にログインする。この商店設定画面は、予めＷＷＷサーバ３側で用意され、PHP: Hypertext Preprocessor 、Perl、Ruby、C、JAVA（登録商標）、VB等のソフトウェア言語によりプログラム生成された画面であり、商店等７がログインすることが可能なようになっている。そして、ステップ３２０５では、この商店設定画面に対し、商店等７はセール期間開始日時Ｔ１０、セール期間終了日時Ｔ１１を設定する。この設定は、タイムセールならば、例えば１２月１日の午後１：００（Ｔ１０）〜２：００（Ｔ１１）、例えば歳末セールならば、１２月１５日午前１０：００（Ｔ１０）〜１２月３１日午後２１：００（Ｔ１１）といったように設定される。
ステップ３２０７では、商店データベースより商品又はサービス品に関する価格、商品情報等が読み出され商店等７に対し表示される。この際の画像もPHP等のソフトウェア言語によりプログラム生成された画面である。この商店データベースには、ＷＷＷサーバ３の運営する貸し店舗サイトに登録された商店等７で通常（セールではない状態）販売品としてＷｅｂ上に掲載し、販売されているデータが保存されている。通常販売品としての情報は、例えば当該商品の当該商店等７における通常販売価格、底値、現金還元額等である。
ステップ３２０９では、ステップ３２０７において読み出された商品又はサービス品の中から商店等７がセールを行いたいセール商品又はセールサービス品を選択する。そして、ステップ３２１１では、このセール商品又はセールサービス品に対し底値、現金還元額、特別価格等の金額やセールに関するデータ情報を設定する。設定したセール情報は、ステップ３２１３でセール専用データベースに保存する。ここに、セール専用データベースは、商店データベースとは異なるが、同一のデータベースとされてもよい。この場合には、同一の商品に対し通常販売のデータとセールのデータの２種類が共存される。
一旦、セール専用データベースが作成された場合には、セール情報の更新が簡単に行える。即ち、この場合には、ステップ３２１５でセール専用データベースより必要なデータを読み出し、修正を加えることで更新が可能である。セール専用データベースには、直前のデータのみを保存してもよいが、直前データだけでなく、履歴データとして過去に実施されたセール情報を複数残すようにされてもよい。また、セール商品やセールサービス品を新たに追加したい場合には、商店データベースより商品やサービスを選択し追加を行う。
次に、図１１０に基づきユーザによる購入処理について説明する。ステップ３２２１では、ユーザ５によりセール商品又はセールサービス品の購入処理が開始される。セールページには、例えばステップ３２２３のように、商店等７の有する通常販売のページよりセールアイコンをクリックすることで進む。このセールアイコンにはセールページがリンクされている。ステップ３２２５ではセールページが開かれる。
その後、ステップ３２２７では、セール期間開始日時Ｔ１０を現在日時と比較し、現在日時がセール期間開始日時Ｔ１０を過ぎているとき、ステップ３２２９で現在セールを行っていない旨の表示をセール画面に挿入しユーザ５に対し送る。このとき、ステップ３２３１で、ユーザ５がこのセール画面において商品選択してもステップ３２３３でログインできない。従って、この商品を購入することができない。しかしながら、リンク元である通常販売画面に戻り、購入処理をすればこの商品を購入することができる。この際には、商店データベースの金額にて購入処理される。
あるいは、ステップ３２３３では、ログインを可能として、商店データベースによる金額等を参照しつつセールではない通常販売価格等にて購入可能とされてもよい。
一方、ステップ３２２７で現在日時がセール期間開始日時Ｔ１０を超えているとき、ステップ３２３５に進む。そして、ステップ３２３５では、セール期間終了日時Ｔ１１を現在日時と比較し、セール期間終了日時Ｔ１１が現在日時より後のとき、ステップ３２３７で、只今歳末セール等のセール（又はタイムセール）中である旨の表示をセール画面に挿入しユーザ５に送信する。現在日時がセール期間終了日時Ｔ１１を過ぎている場合には、ステップ３２３６でセールが終了した旨のメッセージをユーザ５に対し通知する。この際には、ステップ３２３８で商店データベースに保存された通常販売価格や底値等により販売が行われる。なお、ステップ３２３６のセールの終了メッセージはユーザ５に対して通知されなくてもよい。
ステップ３２３９では、ユーザ５が商品若しくはサービス品の選択を行い、ステップ３２４１ではログインを行う。このとき、ログイン画面において、ユーザ５はユーザＩＤやパスワードを入力する。ログイン後において、ステップ３２４３では、再びセール期間終了日時Ｔ１１を現在日時と比較する。ステップ３２４３において、セール期間終了日時Ｔ１１が現在日時より後のとき、ステップ３２４５でセール専用データベースに保存された金額及びデータ情報に基づく販売を行う。このとき、ステップ３２１３で保存されたセール専用の金額や情報に基づいた販売となる。一方、ステップ３２４３で、現在日時がセール期間終了日時Ｔ１１を過ぎた場合には、ステップ３２４７でセッションの途中であるか否かが判断される。このセッションの途中とは、現在日時がセール期間終了日時Ｔ１１を過ぎる前にユーザ５がログインし、購入処理の途中にある場合である。このセッションの途中であるならば、ステップ３２４５に進みそのまま購入処理を継続させる。このことにより、購入処理のセッション途中にあるユーザ５が、途中で購入処理が継続出来なくなる等の不具合は無くなる。
一方、セッションの途中でない場合には、ステップ３２４９でセールが終了したことをＨＴＭＬ文書にてユーザ５に対して通知する。従って、これ以降、ユーザ５は、セール専用データベースに保存された金額での購入が出来なくなる。しかしながら、ステップ３２５１で商店データベースに基づく通常販売が可能である。なお、ステップ３２４９のセールの終了メッセージはユーザ５に対して通知されなくてもよい。
また、ユーザ５は、ステップ３２２５でセールページを開くことなく、ステップ３２４１のログイン画面に直接アクセスして購入処理を行うようにしてもよい。このとき、ステップ３２２７以降の判断処理が行われる。
以上により、商店等７自身がＷｅｂ上で簡単にセールを実行出来る。通常販売からセールへの移行、あるいは、セールから通常販売への移行が円滑に行える。セールの終了時においても、商店等７は何もしないでよい。また、次のセールを実施する際にも、商店等７は以前のセールデータを利用出来るので簡単にセールを実施できる。
１ インターネット
３ サーバ
５ ユーザ
７ 商店等
９ ソフトウェア
１００１ 商品
１００３ バーコード
１００５ 携帯電話
１００６ 専用装置
１００７ チラシ
１００８ センターサーバ
１００９ データベース
１１１１ レジ
１１１３ リーダー
１１１５ 表示器
２００１ 閲覧モード選択ボタン
２００５ 商品名入力又は検索欄
２００７ 表示順選択欄
２００９ ホームページ
２０１１ 移動ボタン
２０１３ 画面上段部分
２０１５ 商店名検索欄
２０１７ 特別店舗紹介コーナー
２０２１ 商品名入力欄
２０２３ メーカー名入力欄
２０２５ 型式入力欄
２０２７ 希望購入価格入力欄
２０４３ 値引き交渉ボタン

Claims (3)

  1. ログインＩＤ、クレジットカード情報、情報処理装置固有の情報、バイオメトリクス情報若しくは該バイオメトリクス情報を基に生成された特徴データ、及び所定のロジックに従い生成されたシリアル番号のいずれか少なくとも一つをセンターサーバーのデータベースに登録する登録手段と、
    ホームページと、
    該ホームページに挿入された保護ソフトウェアの起動、情報処理装置固有の情報の取得、バイオメトリクス情報の取得及び所定のロジックに従い生成されるシリアル番号の取得のいずれか少なくとも一つを含む命令と、
    該命令に基づき取得された情報処理装置固有の情報、バイオメトリクス情報若しくは該バイオメトリクス情報を基に生成された特徴データ及びシリアル番号を送信するデータ送信手段と、
    該データ送信手段により送信されたデータをセンターサーバーにて受信するデータ受信手段と、
    該データ受信手段で受信されたデータを前記登録手段により登録されたデータと対比するデータ対比手段と、
    該データ対比手段による対比結果の一致を基に本人であると確認する本人確認手段とを備えたことを特徴とするネットシステム。
  2. ログインＩＤ、クレジットカード情報、情報処理装置固有の情報、及びバイオメトリクス情報若しくは該バイオメトリクス情報を基に生成された特徴データのいずれか少なくとも一つをセンターサーバーに送信する送信手段と、
    該送信手段で送信されたデータを受信する受信手段と、
    ログインＩＤ、クレジットカード情報、情報処理装置固有の情報、及びバイオメトリクス情報若しくは該バイオメトリクス情報を基に生成された特徴データのいずれか少なくとも一つに対し割り付けられセンターデータベースに保存されると共に前記情報処理装置にも保存される所定のキーと、
    ホームページと、
    該ホームページに挿入された保護ソフトウェアの起動、及び／又は、前記所定のキーの送信を含む命令と、
    該命令に基づき取得された前記所定のキーを前記情報処理装置より送信するキー送信手段と、
    該キー送信手段により送信された所定のキーをセンターサーバーにて受信する受信手段と、
    該受信手段で受信された所定のキーを前記センターデータベースに保存された所定のキーと対比するキー対比手段と、
    該キー対比手段による対比結果の一致を基に本人であると確認する本人確認手段とを備えたことを特徴とするネットシステム。
  3. 前記情報処理装置固有の情報、及び／又は、バイオメトリクス情報若しくは該バイオメトリクス情報を基に生成された特徴データを保存するファイルと、
    前記命令に基づき取得されたデータと該ファイルに保存されたデータとを対比する対比手段とを前記情報処理装置に備えたことを特徴とする請求項１又は請求項２記載のネットシステム。
JP2011103204A 2005-05-26 2011-05-02 ネットシステム Pending JP2011165210A (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2011103204A JP2011165210A (ja) 2005-05-26 2011-05-02 ネットシステム

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
JP2005154722 2005-05-26
JP2005154722 2005-05-26
JP2005264492 2005-09-12
JP2005264492 2005-09-12
JP2011103204A JP2011165210A (ja) 2005-05-26 2011-05-02 ネットシステム

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
JP2006000282A Division JP2007102750A (ja) 2005-05-26 2006-01-04 ネットシステム

Publications (1)

Publication Number Publication Date
JP2011165210A true JP2011165210A (ja) 2011-08-25

Family

ID=44595740

Family Applications (2)

Application Number Title Priority Date Filing Date
JP2011103204A Pending JP2011165210A (ja) 2005-05-26 2011-05-02 ネットシステム
JP2011168617A Pending JP2011258221A (ja) 2005-05-26 2011-08-01 ネットシステム

Family Applications After (1)

Application Number Title Priority Date Filing Date
JP2011168617A Pending JP2011258221A (ja) 2005-05-26 2011-08-01 ネットシステム

Country Status (1)

Country Link
JP (2) JP2011165210A (ja)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2020184306A (ja) * 2020-01-23 2020-11-12 利仁 曽根 地図コンテンツ配信方法

Also Published As

Publication number Publication date
JP2011258221A (ja) 2011-12-22

Similar Documents

Publication Publication Date Title
US9691087B2 (en) Method and system for use of game for charity donations
US9105054B2 (en) Method and system for automated online calendar-based donations
US20060108418A1 (en) System for buying and selling tickets to sporting events in the aftermarket through gifting
KR102196517B1 (ko) 음식 주문 맞춤형 플랫폼을 이용한 음식 주문 중개 장치 및 방법
US20210133790A1 (en) Marketing Based Privacy Credits Using Conventional and Distributed Ledger Technology
JP6590167B2 (ja) 情報処理装置、情報処理方法、プログラム及び製造方法
JP2006313393A (ja) ネットシステムまたは値引き交渉システム
JP2007102750A (ja) ネットシステム
JP4970866B2 (ja) ネットシステム
KR100375556B1 (ko) 전자상거래 시스템
KR100676708B1 (ko) 전자 상거래 방법
KR20130015041A (ko) 거래 서비스를 제공하기 위한 방법 및 시스템
JP2002216035A (ja) ネットワークによる情報入手と商品購入方法、該システム及びプログラム
JP2023011316A (ja) 提供装置、提供方法及び提供プログラム
KR20210049772A (ko) O2o 서비스를 위한 사용자 장치, 그리고 이에 적용되는 방법, 컴퓨터 프로그램 및 기록매체
JP2010020627A (ja) 電子商取引支援システム
JP2012141997A (ja) ネットシステム
US20100161401A1 (en) Incentive providing system for increase of visitors on internet site and method thereof
AU7212400A (en) Method and system for membership sales in internet shopping mall
JP2018005307A (ja) 訪日外国人用サンプルマッチング販売システム
JP7451466B2 (ja) スタンプラリー提供システム、スタンプラリー提供方法、及びプログラム
KR20010108578A (ko) 사용자가 입력하는 조건에 적합한 점수대로 상품 리스트를보여주는 인터넷 검색관리 방법 및 시스템
JP5252321B2 (ja) ネットシステム
JP2011258221A (ja) ネットシステム
JP4933006B2 (ja) インターネットシステム及びソフトウェアプログラムが保存された記録媒体

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20110601

A072 Dismissal of procedure [no reply to invitation to correct request for examination]

Free format text: JAPANESE INTERMEDIATE CODE: A073

Effective date: 20121002