JPH11154176A - 電子バスケットシステム - Google Patents

Abstract

(57)【要約】 【課題】 商品購入／キャンセル時のユーザの負担を軽
減する。 【解決手段】 ユーザが、各店舗１００，２００，３０
０への商品の予約を行うと、各店舗１００，２００，３
００は、予約データをバスケット制御部４００のマネー
ジャ４０３に送る。マネージャ４０３は、予約データを
データベース４０４に格納すると共に、バスケットＩＤ
を付与し、これを予約データを送信した店舗に送る。ユ
ーザが、予約した商品を購入またはキャンセルする場
合、バスケットＩＤに基づき、バスケット制御部４００
にアクセスする。バスケット制御部４００のマネージャ
４０３は、購入／キャンセルの指定を受けた商品を持つ
店舗に対して、購入／キャンセル処理依頼を行う。店舗
での購入／キャンセル処理が完了すると、マネージャ４
０３は、データベース４０４中の該当データを更新す
る。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、ネットワークを介
して複数のサーバから各種のサービスをユーザに提供す
るネットワーク商取引システムにおいて、複数のサーバ
のサービスの承認／キャンセルを一括して行えるように
した電子バスケットシステムに関する。

【０００２】

【従来の技術】今日、インターネットを用い、ユーザが
Ｗｅｂサーバにアクセスし、Ｗｅｂサーバが各種のサー
ビスを提供するネットワーク商取引システムが知られて
いる。従来、このようなネットワーク商取引システムに
おいて、インターネット上で商取引を行う場合、一つ一
つのＷｅｂサーバに通信したデータは、各々のＷｅｂサ
ーバでしか購入／キャンセル処理ができなかった。

【０００３】

【発明が解決しようとする課題】上記のようなネットワ
ーク商取引システムでは、ブラウザからサービスを供給
されるユーザは複数のＷｅｂサーバとの商取引を網羅的
に見て、ユーザにとって最も有利な条件の商品を購入し
ようとした場合、次の二通りの方法のうちいずれかを行
う必要があった。

【０００４】例１） (1) 欲しい商品を提供している全てのＷｅｂサーバを見
て回り、自分の要求に最も近い商品を探す。 (2) 自分の要求に最も近い製品を扱っているＷｅｂサー
バにアクセスし、商品を購入する。

【０００５】例２） (1) 欲しい商品を提供している全てのＷｅｂサーバに行
き、自分の欲しい商品を購入する。 (2) 購入した商品のうち、最も自分の要求に近い商品以
外のサーバへ再度アクセスし、購入した商品をキャンセ
ルする。

【０００６】しかしながら、このような二つの方法は以
下のような問題点があった。 例１は、一度全ての商品を見てから購入する商品を決
定するため、自分が購入したい商品が売り切れとなり、
購入できなくなる場合がある。

【０００７】例２は、候補となる全ての商品を先に購
入し、必要ない商品をキャンセルするという手順を踏む
ことになるが、キャンセルするサイトに何度も行くのは
面倒であり、また、キャンセル料をとられる場合もあ
る。

【０００８】このような点から、ユーザにとって、商品
の購入時やキャンセル時の負担を軽減することのできる
電子バスケットシステムの実現が望まれていた。

【０００９】

【課題を解決するための手段】本発明は、前述の課題を
解決するため次の構成を採用する。 〈請求項１の構成〉ネットワーク上で独立して設けら
れ、ユーザに対しネットワークを介して固有のサービス
を行い、かつ、ユーザよりサービスの予約を受け付ける
店舗と、店舗におけるサービスの予約結果を格納すると
共に、ユーザからの各サービスの承認要求またはキャン
セル要求に基づき、店舗で予約されたサービスへの承認
またはキャンセル処理を行うバスケット制御部を設けた
ことを特徴とする電子バスケットシステムである。

【００１０】〈請求項１の説明〉店舗が行うサービスと
は、例えば商品の売買である。このような商品として
は、家電製品、乗用車等の物品や、旅券、コンサートチ
ケット等の券、更に宿泊施設の利用、パーティ会場の利
用といった種々のものが対象となる。そして、サービス
の予約とは、このような商品の予約を意味する。また、
サービスの承認とは商品の購入に相当する。店舗は、例
えばインターネット上に設けられた仮想店舗であり、ユ
ーザが自由に商品の予約が可能な店舗である。

【００１１】バスケット制御部は、店舗においてユーザ
が予約した商品の管理を行う機能部である。従って、ユ
ーザが複数の店舗で商品を予約した場合でも、その予約
結果はバスケット制御部により一括して管理されてい
る。このため、ユーザは、いずれかの店舗で予約した商
品を購入またはキャンセルする場合は、その店舗にアク
セスして行う必要がなく、バスケット制御部で集中して
行うことができる。

【００１２】その結果、ユーザにとって商品の購入やキ
ャンセルを行う場合の負担を軽減することができ、利用
しやすい商取引システムを実現することができる。

【００１３】〈請求項２の構成〉請求項１に記載の電子
バスケットシステムにおいて、バスケット制御部は、店
舗におけるサービスの予約結果を、バスケットＩＤを付
与したバスケットのデータとして格納するデータベース
と、ユーザから特定のバスケットＩＤで、サービスの承
認要求またはキャンセル要求を受けた場合は、バスケッ
トＩＤに対応するバスケットのデータの処理要求を出力
するバスケットサーバと、ユーザが店舗でサービスの予
約を行った場合にバスケットＩＤを付与し、その後、ユ
ーザがこのバスケットＩＤで任意のサービス予約を行っ
た場合は、同一のバスケットのデータとしてデータベー
スに格納すると共に、バスケットサーバからバスケット
の処理要求を受けた場合は、サービスの承認またはキャ
ンセルを、該当する店舗に通知し、かつ、データベース
中のデータの承認またはキャンセル処理を行うマネージ
ャとを備えたことを特徴とする電子バスケットシステム
である。

【００１４】〈請求項２の説明〉請求項２の発明は、サ
ービスのデータをバスケット単位で管理するようにした
ものである。即ち、このバスケットとは、実際の買い物
を行う場合に商品を入れる篭（バスケット）のイメージ
であり、各サービスが商品に相当する。

【００１５】バスケット制御部のマネージャは、ユーザ
が任意の店舗で商品の予約を最初に行った場合にバスケ
ットＩＤを付与する。これは店舗に依存しないユーザ固
有の値である。そして、ユーザがこのバスケットＩＤで
ログインし、予約を行った場合は、同一のバスケット内
のデータとして管理する。即ち、これは、実際に買い物
を行う場合に、ユーザがバスケット内に商品を入れてい
る状態（精算はまだしていない状態）に相当する。

【００１６】一方、ユーザがいずれかのバスケットＩＤ
でログインし、サービスの承認またはキャンセルを要求
した場合、マネージャは、該当する店舗に対して承認ま
たはキャンセルの処理要求を行う。また、データベース
内の予約データも更新する。即ち、これはバスケット内
の商品を購入またはキャンセルする状態に相当する。こ
の場合、従来であれば、ユーザはその都度、予約した店
舗にアクセスし、購入やキャンセルの処理を行わなけれ
ばならなかったが、請求項２の発明では、他の店舗で予
約した商品であっても一括して購入またはキャンセルの
処理を行うことができる。

【００１７】このように、請求項２の発明では、ユーザ
があたかも商品を入れるための複数の店舗に共通な篭を
もって買い物をしているような状態であるため、ユーザ
にとって非常に利用しやすいシステムを実現することが
できる。

【００１８】

【発明の実施の形態】以下、本発明の実施の形態を図面
を用いて詳細に説明する。 《具体例》 〈構成〉図１は本発明の電子バスケットシステムの具体
例を示す説明図である。図の装置は、ブラウザ１０、店
舗１００，２００，３００、バスケット制御部４００か
らなる。尚、これらブラウザ１０および店舗１００〜３
００とバスケット制御部４００は、インターネットを介
して接続されているが、図面上では、信号のやり取りの
みを示している。

【００１９】ブラウザ１０は、ユーザ端末に設けられ、
各店舗１００，２００，３００やバスケット制御部４０
０のＷｅｂサーバ１０１，２０１，３０１，４０１との
アクセスを行うためのソフトウェアである。

【００２０】店舗１００，２００，３００は、それぞれ
独立したインターネット上の店舗であり、各店舗１００
〜３００は独自にＷｅｂサーバ１０１，２０１，３０１
を立ち上げ、商品の販売を行っている。また、バスケッ
ト制御部４００は、各店舗１００〜３００での商品予約
をユーザ毎に管理しているシステムである。尚、本具体
例では、店舗として三つの店舗１００〜３００のみ示す
が、インターネット上の店舗数はこれに限定されるもの
ではない。

【００２１】以下、各店舗１００〜３００およびバスケ
ット制御部４００の構成を詳細に説明する。各店舗１０
０，２００，３００は、それぞれＷｅｂサーバ１０１，
２０１，３０１、サーバ１０２，２０２，３０２、デー
タベース１０３，２０３，３０３を備えている。

【００２２】Ｗｅｂサーバ１０１，２０１，３０１は、
それぞれインターネット上で商品の展示を行う機能を有
するサーバである。サーバ１０２，２０２，３０２は、
それぞれ各店舗の商品予約をバスケット制御部４００の
後述するマネージャ４０３に通知し、データベース１０
３，２０３，３０３の更新を行う機能を有するサーバで
ある。データベース１０３，２０３，３０３は、その店
舗の商品情報および受注データを保存しているデータベ
ースである。

【００２３】バスケット制御部４００は、Ｗｅｂサーバ
４０１、バスケットサーバ４０２、マネージャ４０３、
データベース４０４からなる。このバスケット制御部４
００は、ブラウザ１０とインターネットを介して接続さ
れ、また、各店舗１００，２００，３００とはインター
ネットや、ＬＡＮ等の通信路を介して接続されている。

【００２４】Ｗｅｂサーバ４０１は、ブラウザ１０経由
でユーザが商品の予約方法の閲覧を行ったり、商品の購
入／キャンセルを行う為のサーバである。

【００２５】バスケットサーバ４０２は、上述した各店
舗１００〜３００およびＷｅｂサーバ４０１経由で受信
した命令に従って閲覧するバスケット制御部４００の情
報を表示するためのページをデータベース４０４に保持
している情報から作成する機能と、ブラウザ１０からの
購入／キャンセル情報を元に、マネージャ４０３に各店
舗１００〜３００の情報の更新を依頼する機能を備えて
いるサーバである。

【００２６】マネージャ４０３は、各店舗１００，２０
０，３００のサーバ１０２，２０２，３０２からの予約
情報をデータベース４０４に書き込む機能と、バスケッ
ト制御部４００内のバスケットサーバ４０２からの購入
／キャンセル依頼を元に、各店舗１００，２００，３０
０上のサーバ１０２，２０２，３０２に各店舗のデータ
ベース１０３，２０３，３０３の更新依頼を行い、か
つ、データベース４０４内のデータの更新を行う機能を
有している。

【００２７】〈動作〉以下、本具体例の電子バスケット
システムの動作を、「商品の予約」と「商品の購入／キ
ャンセル」に分けて説明する。

【００２８】●商品の予約 ブラウザ１０を用いて商品を購入するユーザは、先ず、
店舗上の商品を確保するために、店舗のＷｅｂサーバよ
り購入する商品を選択する。この場合の店舗側の処理
を、店舗１００および店舗２００への予約を例に説明す
る。

【００２９】図２は、予約時に連続してバスケットにデ
ータ投入する場合のシーケンスチャートである。

【００３０】１．ユーザ（ブラウザ１０）からの要求
を、店舗１００のＷｅｂサーバ１０１で受ける（ステッ
プＳ１０１）。 ２．Ｗｅｂサーバ１０１は、受け取ったデータをデータ
ベース１０３の処理を行うサーバ１０２に送る。 ３．サーバ１０２は、データベース１０３のデータに対
し予約処理を行う（ステップＳ１０２）。

【００３１】４．サーバ１０２は、バスケット制御部４
００のマネージャ４０３に対して、ユーザの購入した商
品のデータを送る（ステップＳ１０３）。 ５．バスケット制御部４００のマネージャ４０３は、デ
ータベース４０４に対してユーザの商品予約情報を書き
込むと共に、バスケットＩＤを取得する（ステップＳ１
０４）。即ち、バスケット制御部４００にユーザからの
最初のデータが投入された時点でバスケットＩＤが採番
される。尚、バスケットＩＤの保存については、データ
ベース４０４等、バスケット制御部４００内の任意の場
所に格納されるとする。

【００３２】６．バスケット制御部４００のマネージャ
４０３は、店舗１００のサーバ１０２に、店舗１００に
依存しないユーザ固有の値として、バスケットＩＤを送
る（ステップＳ１０５）。 ７．店舗１００のサーバ１０２は、Ｗｅｂサーバ１０１
を介して、このバスケットＩＤとバスケット内商品デー
タをブラウザに通知する（ステップＳ１０６）。

【００３３】図３は、この画面表示を示す説明図であ
る。図示のように、バスケットＩＤとしてレシート番号
が表示され、また、予約した商品や注文者、届け先等の
情報が表示される。

【００３４】８．ユーザ（ブラウザ１０）は、付与され
たレシート番号やユーザ名を保存する（ステップＳ１０
７）。

【００３５】そして、ユーザが連続して店舗２００に対
して予約を行った場合は、次のようになる。

【００３６】９．ユーザのブラウザ１０からの要求を、
店舗２００のＷｅｂサーバ２０１で受ける（ステップＳ
１０８）。 １０．Ｗｅｂサーバ２０１は、受け取ったデータをデー
タベース２０３の処理を行うサーバ２０２に送る。 １１．サーバ２０２は、データベース２０３のデータに
対し予約処理を行う（ステップＳ１０９）。 １２．サーバ２０２は、バスケット制御部４００のマネ
ージャ４０３に対して、ユーザの購入した商品のデータ
を送る（ステップＳ１１０）。

【００３７】１３．バスケット制御部４００のマネージ
ャ４０３は、ブラウザ１０からＷｅｂサーバ２０１を通
して送られたユーザ固有の値であるバスケットＩＤを元
に、データベース４０４を検索し、店舗２００で予約し
た商品データを追加する（ステップＳ１１１）。即ち、
バスケット制御部４００にはユーザ固有のデータが既に
存在しているため、このデータに対して新たなデータが
追加される。 １４．バスケット制御部４００のマネージャ４０３は、
店舗２００のサーバ２０２に、店舗２００に依存しない
ユーザ固有の値であるバスケットＩＤを送る（ステップ
Ｓ１１２）。 １５．店舗２００のサーバ２０２は、このバスケットＩ
Ｄとバスケット内商品データをブラウザ１０に通知する
（ステップＳ１１３）。

【００３８】また、ユーザが一旦ブラウザ１０での処理
を止めた後に再度同一のバスケットを用いて予約を行っ
た場合は次のようになる。

【００３９】図４は、既に存在するバスケットにデータ
を投入する場合のシーケンスチャートである。 １．ユーザ（ブラウザ１０）は、先ず、電子バスケット
システムへのログインを行う（ステップＳ２０１）。即
ち、ブラウザ１０が、ユーザ名，レシート番号等のデー
タをバスケット制御部４００に送信する。 ２．バスケット制御部４００のバスケットサーバ４０２
は、受信したレシート番号からバスケットＩＤを抽出
し、バスケットＩＤをキーとしたユーザデータをデータ
ベース４０４から検索する。そして、検索したユーザ名
とブラウザ１０から送信されたユーザ名を比較・確認
し、一致した場合は、顧客データ、商品データによるＨ
ＴＭＬページの作成を行い（ステップＳ２０２）、これ
をブラウザ１０に送信する（ステップＳ２０３）。

【００４０】３．ユーザ（ブラウザ１０）は、付与され
たレシート番号やユーザ名を保存する（ステップＳ２０
４）。

【００４１】その後、ユーザが例えば店舗２００に対し
て予約を行う場合の動作（ステップＳ２０５〜ステップ
Ｓ２１０）は、上述した“連続してバスケットにデータ
投入する場合”のステップＳ１０８〜ステップＳ１１３
と同様の動作となる。

【００４２】このように、一旦、ブラウザ１０での処理
を止めた後に予約を行う場合は、最初にバスケット制御
部４００へのログインを行う。尚、ブラウザ１０で、付
与されているバスケットＩＤでログインを行えば、予約
データはそのバスケット内のデータとして扱われるが、
上述したステップＳ１０１からの操作を行うことによ
り、別のバスケットＩＤが付与される。即ち、バスケッ
トＩＤは複数持つことが可能であり、このようにバスケ
ットＩＤを複数持っている場合、ユーザはいずれかのバ
スケットＩＤでログインすることになる。

【００４３】各店舗１００，２００，３００において購
入したい商品を予約したユーザは、バスケット制御部４
００のＷｅｂサーバ４０１にアクセスし、商品予約情報
を見て、実際に購入若しくはキャンセルする商品を選択
する。ここでは、初めに店舗３００の商品を購入する場
合を説明する。

【００４４】●商品の購入 図５は、バスケット内の商品を購入する場合のシーケン
スチャートである。 １．ユーザ（ブラウザ１０）は、先ず、電子バスケット
システムへのログインを行う（ステップＳ３０１）。即
ち、ブラウザ１０が、ユーザ名、レシート番号等をバス
ケット制御部４００のバスケットサーバ４０２に送信す
る。

【００４５】２．バスケット制御部４００のバスケット
サーバ４０２は、受信したレシート番号からバスケット
ＩＤを抽出し、バスケットＩＤをキーとしたユーザデー
タをデータベース４０４から検索する。そして、検索し
たユーザ名とブラウザ１０から送信されたユーザ名を比
較・確認し、一致した場合は、顧客データ、商品データ
によるＨＴＭＬページの作成を行い（ステップＳ３０
２）、これをブラウザ１０に送信する（ステップＳ３０
３）。以上、１．および２．の処理は、最初に電子バス
ケットシステムにログインする場合の通常動作である。
従って、予約処理（あるいは、他の店舗からの購入また
はキャンセル動作処理）からの連続使用の場合は不要で
ある。

【００４６】３．ユーザは、バスケットＩＤを保存した
（ステップＳ３０４）後、バスケット制御部４００との
やり取りを行い、購入／キャンセル用の画面を表示す
る。

【００４７】図６および図７は、購入／キャンセルを行
う場合の画面イメージである。この画面にはユーザがそ
れまで予約している商品のデータが表示されており、各
商品に対する「購入／キャンセル」の欄で、「購入」
「キャンセル」「保留」のいずれかを指定し「実行」ボ
タンを押下することにより、そのデータがバスケット制
御部４００に送信される。尚、予約時ではその商品は
「保留」となっている。

【００４８】４．ユーザは、ブラウザ１０によって、店
舗３００の商品を購入するというデータをバスケット制
御部４００に送信する（ステップＳ３０５）。 ５．バスケット制御部４００のＷｅｂサーバ４０１は、
ブラウザ１０から送られたデータをバスケットサーバ４
０２に送る。 ６．バスケットサーバ４０２は、ブラウザ１０から送ら
れたバスケットＩＤによりデータベース４０４から、対
応する商品データを検索し、購入処理データを作成する
（ステップＳ３０６）。そして、マネージャ４０３に対
して購入処理データの処理依頼を行う（ステップＳ３０
７）。

【００４９】７．マネージャ４０３は、バスケットＩＤ
からデータベース４０４に格納されていた予約データを
読み込み、店舗３００のサーバ３０２に商品の購入要求
を通知する（ステップＳ３０８）。 ８．店舗３００のサーバ３０２は、データベース３０３
の商品情報を、予約情報から購入情報に変更する（ステ
ップＳ３０９）。 ９．店舗３００のサーバ３０２は、変更が完了した旨の
データをバスケット制御部４００のマネージャ４０３に
送る（ステップＳ３１０）。

【００５０】１０．マネージャ４０３は、データベース
４０４内の購入した商品の情報を削除する（ステップＳ
３１１）。 １１．マネージャ４０３は、購入処理が完了した旨の通
知をバスケットサーバ４０２に対して行う（ステップＳ
３１２）。 １２．バスケットサーバ４０２は、顧客データ、商品デ
ータおよびバスケットＩＤによるＨＴＭＬページを作成
し（ステップＳ３１３）、このページをブラウザ１０に
送信する（ステップＳ３１４）。

【００５１】尚、別の店舗１００，２００のデータ、お
よび購入処理を行わなかったデータ（図６および図７中
の「購入／キャンセル」で「保留」のままのデータ）
は、バスケット制御部４００で保留状態のままとなる。
また、このような保留状態のデータをいつまで保留状態
とするか、また、削除するタイミング等は実装するシス
テムによって適宜決定する。

【００５２】●商品のキャンセル 図８は、バスケット内の商品をキャンセルする場合のシ
ーケンスチャートである。

【００５３】図示例は、店舗１００の商品をキャンセル
する場合を示している。この場合のバスケット制御部４
００での処理は、購入データがキャンセルデータとなっ
た点が異なるだけで、基本的には上述した購入時の処理
と同様である。

【００５４】また、点線内に示す処理（ステップＳ４０
１〜Ｓ４０３）は、ブラウザ１０での処理を一旦止めた
場合の、電子バスケットシステムへのログイン処理であ
り、購入動作時の点線内の動作と同様であるため、ここ
での説明は省略する。従って、この場合も、予約処理
（あるいは、他の店舗からの購入またはキャンセル動作
処理）からの連続使用の場合は不要となる。

【００５５】ブラウザ１０で、バスケットＩＤが保存さ
れる（ステップＳ４０４）と共に、図６および図７で示
した画面と同様の画面が表示され、ユーザが店舗１００
のいずれかの商品に対してキャンセル操作を行ったとす
る。

【００５６】１．ブラウザ１０は、バスケット制御部４
００に対して、キャンセルする商品のデータと、ブラウ
ザ１０が保存しているバスケットＩＤを送信する（ステ
ップＳ４０５）。 ２．バスケット制御部４００のＷｅｂサーバ４０１は、
ブラウザ１０から送られたデータをバスケットサーバ４
０２に送る。 ３．バスケットサーバ４０２は、ブラウザ１０から送ら
れたバスケットＩＤによりデータベース４０４から、対
応する商品データを検索し、キャンセル処理データを作
成する（ステップＳ４０６）。そして、マネージャ４０
３に対してキャンセル処理データの処理依頼を行う（ス
テップＳ４０７）。

【００５７】４．マネージャ４０３は、バスケットＩＤ
からデータベース４０４に格納されていた予約データを
読み込み、店舗１００のサーバ１０２に商品のキャンセ
ル要求を通知する（ステップＳ４０８）。 ５．店舗１００のサーバ１０２は、データベース１０３
の商品情報を、予約情報からキャンセル情報に変更する
（ステップＳ４０９）。 ６．店舗１００のサーバ１０２は、変更が完了した旨の
データをバスケット制御部４００のマネージャ４０３に
送る（ステップＳ４１０）。

【００５８】７．マネージャ４０３は、データベース４
０４内のキャンセルした商品の情報を削除する（ステッ
プＳ４１１）。 ８．マネージャ４０３は、キャンセル処理が完了した旨
の通知をバスケットサーバ４０２に対して行う（ステッ
プＳ４１２）。 ９．バスケットサーバ４０２は、顧客データ、商品デー
タおよびバスケットＩＤによるＨＴＭＬページを作成し
（ステップＳ４１３）、このページをブラウザ１０に送
信する（ステップＳ４１４）。

【００５９】尚、この場合も、別の店舗２００，３００
のデータ、およびキャンセル処理を行わなかったデータ
はバスケット制御部４００で保留状態のままとなる。

【００６０】〈効果〉以上のように、具体例によれば、
各店舗１００，２００，３００のにおける商品の予約や
購入／キャンセルを管理するバスケット制御部４００を
設けたので、ユーザは、予約した商品に対して購入やキ
ャンセルを行う場合に、わざわざ予約した店舗に対して
操作を行う必要がなくなり、ユーザにとって利用しやす
いシステムを実現することができる。

【００６１】尚、上記具体例では、バスケット制御部４
００は、各店舗１００，２００，３００毎に商品の管理
を行うようにしたが、これ以外にも、各店舗が独自にＷ
ｅｂサーバを有する形式のモールにおいて、各店舗単位
でなくモール単位で商品の購入、決済を行う場合にも利
用可能である。

【図面の簡単な説明】

【図１】本発明の電子バスケットシステムの具体例を示
す説明図である。

【図２】本発明の電子バスケットシステムの具体例にお
いて予約時に連続してバスケットにデータ投入する場合
のシーケンスチャートである。

【図３】本発明の電子バスケットシステムの具体例にお
いて予約時の画面表示の説明図である。

【図４】本発明の電子バスケットシステムの具体例にお
いて既に存在するバスケットにデータ投入する場合のシ
ーケンスチャートである。

【図５】本発明の電子バスケットシステムの具体例にお
いてバスケット内の商品を購入する場合のシーケンスチ
ャートである。

【図６】本発明の電子バスケットシステムの具体例にお
いて購入／キャンセルを行う場合の画面イメージの説明
図（その１）である。

【図７】本発明の電子バスケットシステムの具体例にお
いて購入／キャンセルを行う場合の画面イメージの説明
図（その２）である。

【図８】本発明の電子バスケットシステムの具体例にお
いてバスケット内の商品をキャンセルする場合のシーケ
ンスチャートである。

【符号の説明】

１０ ブラウザ １００，２００，３００ 店舗 ４００ バスケット制御部 ４０２ バスケットサーバ ４０３ マネージャ ４０４ データベース

Claims (2)

【特許請求の範囲】
1. 【請求項１】 ネットワーク上で独立して設けられ、ユ
   ーザに対し前記ネットワークを介して固有のサービスを
   行い、かつ、当該ユーザより前記サービスの予約を受け
   付ける店舗と、 前記店舗におけるサービスの予約結果を格納すると共
   に、前記ユーザからの各サービスの承認要求またはキャ
   ンセル要求に基づき、前記店舗で予約されたサービスへ
   の承認またはキャンセル処理を行うバスケット制御部を
   設けたことを特徴とする電子バスケットシステム。
2. 【請求項２】 請求項１に記載の電子バスケットシステ
   ムにおいて、 バスケット制御部は、 店舗におけるサービスの予約結果を、バスケットＩＤを
   付与したバスケットのデータとして格納するデータベー
   スと、 ユーザから特定のバスケットＩＤで、サービスの承認要
   求またはキャンセル要求を受けた場合は、当該バスケッ
   トＩＤに対応するバスケットのデータの処理要求を出力
   するバスケットサーバと、 ユーザが前記店舗でサービスの予約を行った場合にバス
   ケットＩＤを付与し、その後、当該ユーザがこのバスケ
   ットＩＤで任意のサービス予約を行った場合は、同一の
   バスケットのデータとして前記データベースに格納する
   と共に、前記バスケットサーバからバスケットの処理要
   求を受けた場合は、当該サービスの承認またはキャンセ
   ルを、該当する店舗に通知し、かつ、前記データベース
   中のデータの承認またはキャンセル処理を行うマネージ
   ャとを備えたことを特徴とする電子バスケットシステ
   ム。