JP2001338185A - トランザクション管理装置及び電子取引システム並びに電子取引方法及びトランザクション管理方法 - Google Patents

Abstract

(57)【要約】 【課題】 複数の電子店舗を越えて使用可能なグローバ
ルなショッピングカートを提供可能な電子取引システム
を提供すること。 【解決手段】 インターネット６に電子店舗を出すショ
ップサーバ２とクライアント３と電子店舗・利用者間取
引を管理する管理サーバ１が接続され、クライアント３
はショップサーバ２との間で利用者の所望する取引手続
きをした後に利用者から要求された場合に該取引を管理
サーバ１へ進行中の取引として登録する。この登録は複
数のショップサーバ２を越えて可能になる。管理サーバ
１は、ある利用者のクライアント３から複数の進行中の
取引を一括して成立させるべき指示が出された場合、該
当するショップサーバ２との間で所定の手続きを行い、
可能であれば複数の取引を一括して成立させ、それが可
能でなければ複数の取引を一括して取り消し、利用者の
クライアント３へ処理の結果を通知する。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、インターネット等
で電子的な取引を行うためのトランザクション管理装置
及び電子取引システム並びに電子取引方法及びトランザ
クション管理方法に関する。

【０００２】

【従来の技術】インターネット上での電子店舗システム
あるいは電子商取引システム等の多くは、ＷＷＷ（ＷＯ
ＲＬＤ ＷＩＤＥ ＷＥＢ）システムをベースにして構
築されている。電子店舗で買物や予約などをしたい客の
使うクライアントコンピュータでは、ＷＥＢブラウザ
（あるいは単にブラウザ）と呼ばれるソフトウェアが動
作する。客はＷＥＢブラウザからインターネットを介し
て商品の購入などをしたい電子店舗のショップコンピュ
ータに接続し、商品情報の閲覧や、商品の購入手続きな
どを行う。

【０００３】ショップコンピュータ上では、電子店舗の
機能を実行するプログラムが動作し、例えば、客に対し
て商品の説明や価格を提示したり、客からの注文を受け
て在庫の確認、支払いの処理、配送の手配などの販売処
理を行う。また、顧客との過去の取引履歴を管理して、
顧客に合った商品提案や優待販売などのサービスをする
場合もある。ショップコンピュータは、例えばクレジッ
トカードの決済などを行う際などには、他のサービス会
社のコンピュータと通信することもある。

【０００４】クライアントコンピュータ上のＷＥＢブラ
ウザとショップコンピュータ上の電子店舗プログラム
は、ＨＴＴＰと呼ばれるＷＷＷの標準の通信プロトコル
で通信する。ＨＴＴＰプロトコルは、ＵＲＬと呼ばれる
処理要求の識別子と、必要に応じてその要求に付随する
情報をリクエストとして送ると、処理結果を表示するＨ
ＴＭＬドキュメント等のデータがリプライとして返され
る、１組のリクエスト／リプライが通信の基本単位にな
る。電子商取引では、リクエストはクライアントコンピ
ュータからショップコンピュータに向けて送られ、リプ
ライはショップコンピュータからクライアントコンピュ
ータへ向けて送られる。

【０００５】通常、インターネット上のいわゆる電子商
取引における手続きの開始から終了までには、複数回の
リクエスト／リプライの組が必要になる。書籍の販売の
場合を考えてみると、クライアントコンピュータ上のＷ
ＥＢブラウザとショップコンピュータ上のプログラムの
間で、一例として次のようなリクエスト／リプライのシ
ーケンスが必要になる。 （１）欲しい本の名前をリクエストとして送る。 （２）在庫や価格の情報がリプライとして返される。 （３）購入希望を伝えるリクエストを送る。 （４）支払いや配送に関する情報の入力フォームがリプ
ライとして返される。 （５）フォームに必要な情報を記述してリクエストとし
て送る。 （６）手続きの完了がリプライとして返される。

【０００６】このような一纏まりの処理をするために必
要になる一連のリクエスト／リプライの処理系列をセッ
ションと呼ぶ。ＨＴＴＰプロトコル自身はセッションを
管理する手段を持っていない。すなわち、ショップコン
ピュータ上のプログラムは、同時に複数の客との取引処
理を進める。しかし、上記の例で、ショップコンピュー
タ上のプログラムがある客からの（５）の購入に必要な
情報のリクエストを受け取ったときに、そのリクエスト
がどの客の（４）のリプライを受けたものであるかを判
断する手段を、ＨＴＴＰプロトコルは持っていない。そ
こで通常は、例えば「ＲＦＣ２１０９：ＨＴＴＰ Ｓｔ
ａｔｅ Ｍａｎａｇｅｍｅｎｔ Ｍｅｃｈａｎｉｓｍ」
に開示されているＣＯＯＫＩＥと呼ばれるメカニズムを
使ってセッションを管理する。ショップコンピュータ上
のプログラムは、ＣＯＯＫＩＥと呼ばれる識別用の文字
列を使って、セッションを構成する複数のリクエストお
よびリプライを関連付ける。

【０００７】電子店舗を実現するショップコンピュータ
上のプログラムでは、ショッピングカート機能を持つも
のも多い。ショッピングカート機能では、通常、客は、
その電子店舗で選んだ商品をショッピングカートに入れ
たり、一度入れた商品を自由にカートから取り出して返
品することができ、最後に例えば『購入ボタン』あるい
は『決定ボタン』あるいは『確定ボタン』を押すなどす
ることによって、そのときにショッピングカート内に入
っている複数の商品についてまとめて購入手続きをする
ことができるようになっている（ここでクレジット番号
を入力するなどして複数の商品について一括して支払い
手続きを行うことも多い）。ショッピングカート機能を
実現する方式としては、ショップコンピュータ側で客毎
に買った商品を記録していく方法や、クライアントコン
ピュータ側で自分の買った商品を記録していく方法があ
る。

【０００８】以下、従来の電子商取引システムの問題点
について説明する。

【０００９】インターネット上の電子商取引システムの
第１の問題点は、ＨＴＴＰプロトコルとＣＯＯＫＩＥ機
構を使って、客のクライアントコンピュータと店のショ
ップコンピュータの間のセッションを管理しているた
め、客にとっても店にとっても、現在進行中の取引のセ
ッションが正しく進行しているのかエラーが発生してい
るのかを確認する手段が無いことである。

【００１０】例えば、何らかの商品を購入しようとして
いる客が、クライアントコンピュータ上のＷＥＢブラウ
ザから支払いに必要なクレジットカードの番号と配達先
を入力して「支払」ボタンを押したとする。通常はこれ
で支払手続きを開始するリクエストがショップコンピュ
ータに送られ、処理が実行され、支払手続きの完了を知
らせるメッセージがリプライとして送られる。しかし、
「支払」ボタンを押してもなかなかリプライが送られて
こない場合、リクエストがショップコンピュータに届か
なかったのか、ショップコンピュータがダウンしたの
か、支払手続きは済んだがリプライがクライアントコン
ピュータに届かなかったのか、あるいは単に負荷が高く
てまだ支払手続きが済んでいないだけで正常な状態なの
か、客には判断できない。客は、もう一度「支払」ボタ
ンを押すと２重に発注してしまうことになるのかあるい
はエラーになるのかわからないし、また、支払処理が実
行されたのかされていないのかわからないまま取引を終
了するわけにもいかない。

【００１１】また、ショップコンピュータ上の電子店舗
プログラムにとっても同様の問題がある。例えば、客か
ら何らかの商品の購入希望のリクエストを受け取り、そ
の商品の在庫を確保した後、支払方法や配達先の入力を
促すリプライを返したとする。通常はしばらくすると支
払方法や配送先を入力したフォームがリクエストとして
送られてくる。しかし、それがなかなか返ってこない場
合、リプライがクライアントコンピュータに届かなかっ
たのか、クライアントコンピュータがダウンしたのか、
入力したフォームを送るリクエストがショップコンピュ
ータに届かなかったのか、客が購入意思をなくして勝手
に取引をやめたのか、あるいは客が入力フォームへの記
入に手間取っているだけで正常な状態なのか、ショップ
コンピュータ上の電子店舗プログラムには判断できな
い。店は、客はまだ購入意思があるかもしれないので確
保した在庫を解放するわけにもいかないし、かといって
逆に、いつまでも在庫を確保しておいても客は既に購入
する意思を無くしているかもしれない。

【００１２】インターネット上の電子商取引システムの
第２の問題点は、客にとっても店にとっても、現在進行
中の取引のセッション中にエラーあるいはエラーかもし
れない状況が発生した場合に、そのセッションに正しく
復帰して取引を継続するための方法、あるいはそのセッ
ションを正しく中断してそれまでの取引を取り消すため
の統一的な方法が無いことである。現在は、客にとって
も店にとっても、セッションを一方的に放棄するしかな
い。

【００１３】このような状況に対処するために、ショッ
プコンピュータの電子店舗プログラムにおいて、現在進
行中の取引を無効にさせるための機能を用意するなどの
対策も考えられる。しかし、この方法が使えるのは、ク
ライアントコンピュータからショップコンピュータに再
接続することが可能な場合に限られるため、取引をして
いた店のアドレス（ＵＲＬ）を覚えている必要があり、
また、ショップコンピュータの障害に対しては対処でき
ない。

【００１４】インターネット上で電子商取引をする客と
店の両方にとって、取引の途中で何らかのエラーあるい
はエラーかもしれない状況が発生したときに、どの電子
店舗と取引している場合でも同じ手順で取引を正しく継
続あるいは中断するための統一的な方法が必要である。

【００１５】インターネット上の電子商取引システムの
第３の問題点は、複数の電子店舗での買い物をまとめて
決済できるショッピングカート機能が無いことである。

【００１６】同じ電子店舗内では複数の商品を購入して
まとめて決済を済ませるショッピングカート機能が広く
使われている。また、同じ電子ショッピングモール内な
らば複数の電子店舗の商品を入れられるショッピングカ
ート機能が実現されている。しかし、これらの既存の機
能では、異なる電子店舗での購入をまとめることはでき
ない。

【００１７】例えば、旅行の手配をするために、Ａホテ
ルで宿泊の予約をし、Ｂエアラインで航空券の予約をす
る場合、この２つの両方が予約できる場合には購入した
いが、どちらかが満員で予約できない場合はどちらも購
入したくない。現在のインターネット上の電子商取引シ
ステムでこのような買い物の仕方をしようと思えば、Ａ
ホテルとＢエアラインが同じショッピングモールに店を
出していて、かつそのショッピングモールがモール内の
複数店舗の商品を入れられるショッピングカートを提供
している必要がある。

【００１８】上記の例のように相互に依存する買い物で
はない場合でも、複数の電子店舗での買い物をまとめる
ことができるショッピングカート機能があると、支払の
ために必要な手続きを一括して済ませることができて非
常に便利である。

【００１９】インターネット上の電子商取引システムの
第４の問題点は、過去の取引の履歴や、現在進行中の取
引の状態を一元的に管理する手段が無いことである。

【００２０】電話の場合は電話局に記録が管理されてい
るので、希望すれば自分がかけた電話の記録を入手する
ことができる。クレジットカードの場合もカード会社に
は利用記録が残っており、自分の利用記録の明細書を入
手することができる。しかし、インターネットでの電子
商取引の場合には、このように一元的に利用記録を管理
するサービスが無い。

【００２１】例えば、自分が今まで何処の電子店舗で何
を買ったかを調べたい場合、ショッピングカートには入
っているがまだ決済が完了していないものを調べたい場
合、発注したものがどういう状態にあるのか知りたい場
合などに、参照できる記録を自動的に取る機能がない。
現在は、このような過去の取引の記録は、客自身が自主
的に管理するしか方法がない。

【００２２】

【発明が解決しようとする課題】以上説明してきたよう
に、従来のシステムでは、セッションエラーを検出でき
ない、セッション途中の障害に対して復帰あるいは中断
する（統一的な）手段がない、異なるショップを跨って
使えるショッピングカートがない、異なるショップを跨
った取引履歴等の管理機能がないといった種々の問題点
があった。

【００２３】本発明は、上記事情を考慮してなされたも
ので、複数の電子店舗に跨ったグローバルなショッピン
グカートを可能にしたトランザクション管理装置及び電
子取引システム並びに電子取引方法及びトランザクショ
ン管理方法を提供することを目的とする。

【００２４】また、障害の検出や障害からの回復や対処
を効果的に行うことを可能としたトランザクション管理
装置及び電子取引システム並びに電子取引方法及びトラ
ンザクション管理方法を提供することを目的とする。

【００２５】また、複数の電子店舗に跨って過去の取引
履歴を一元的に管理することを可能にしたトランザクシ
ョン管理装置及び電子取引システム並びに電子取引方法
及びトランザクション管理方法を提供することを目的と
する。

【００２６】

【課題を解決するための手段】本発明に係るトランザク
ション管理装置（トランザクション管理コンピュータ）
は、ネットワーク上で電子店舗を提供する複数のショッ
プコンピュータ及び電子店舗を利用する利用者の使用す
る複数のクライアントコンピュータと通信するための通
信手段と、少なくともいずれかの前記電子店舗といずれ
かの前記利用者との間で進行中の取引について、該取引
を特定するための第１の情報と、該取引に係る利用者を
識別するための第２の情報と、該取引に係る電子店舗を
識別するための第３の情報と、該取引の状態が、少なく
とも、取引の成立又は不成立を確定させるための指示を
待っている第１の状態、取引の成立を確定させるための
指示を受けて取引の成立を確定させるための処理を開始
したが該処理が未だ完了していない第２の状態、取引の
成立を確定させるための処理が完了した第３の状態、取
引の不成立が確定している第４の状態のいずれであるか
を区別するための第４の情報との組を含む取引情報を、
管理するための管理手段とを備えたことを特徴とする。

【００２７】また、本発明は、ネットワークを介して通
信可能な、電子店舗を提供する複数のショップコンピュ
ータ、電子店舗を利用する利用者の使用する複数のクラ
イアントコンピュータ及び電子店舗と利用者との間で進
行中の取引を管理するトランザクション管理コンピュー
タとを含む電子取引システムであって、前記利用者のク
ライアントコンピュータと該利用者が所望する電子店舗
を提供するショップコンピュータとの間で該利用者の所
望する取引のための一定の手続きを行った後に、該クラ
イアントコンピュータから該ショップコンピュータへト
ランザクション管理コンピュータを利用すべき旨が要求
された場合に該ショップコンピュータから前記トランザ
クション管理コンピュータへ該一定の手続きを経た取引
を進行中の取引として登録する一連の手順が、該利用者
のクライアントコンピュータと複数のショップコンピュ
ータとの間のそれぞれの取引について行われ、前記トラ
ンザクション管理コンピュータへ登録されている複数の
進行中の取引について、その取引に係る利用者のクライ
アントコンピュータから該トランザクション管理コンピ
ュータへ該複数の取引の成立を一括して確定させるべき
旨が指示された場合に、該当するショップコンピュータ
との間で所定の手続きを行って、可能であれば該複数の
取引の成立を一括して確定させ、それが可能でなければ
該複数の取引を一括して取り消し、前記トランザクショ
ン管理コンピュータから前記利用者のクライアントコン
ピュータへ、前記指示に対する処理の結果を通知するこ
とを特徴とする。

【００２８】また、本発明は、ネットワークを介して電
子店舗を提供するショップコンピュータの電子取引方法
であって、自店舗を利用する利用者のクライアントコン
ピュータとの間で該利用者の所望する取引のための一定
の手続きを行った後に、利用者と電子店舗との間で進行
中の取引を管理するトランザクション管理コンピュータ
を利用すべき旨が該クライアントコンピュータから要求
された場合に、該トランザクション管理コンピュータへ
該一定の手続きを経た取引を進行中の取引として登録
し、前記トランザクション管理コンピュータから、該ト
ランザクション管理コンピュータへ登録されている自店
舗に係る進行中の取引のうちの特定のものについて、該
取引の成立を確定させるための手続きが完結可能である
か否かの問い合わせを受けた場合に、完結可能であるか
否かを判断し、完結可能であればその旨を前記トランザ
クション管理コンピュータへ返答し、前記完結可能の旨
を前記トランザクション管理コンピュータへ返答した後
に、該トランザクション管理コンピュータから、前記特
定の取引の成立を確定させるための手続きを完結させる
ことが指示された場合には、該取引の成立を確定させる
ための処理を行い、前記特定の取引を取り消すべきこと
が指示された場合には、該取引を取り消すための処理を
行った後に、前記トランザクション管理コンピュータへ
処理完了を通知することを特徴とする。

【００２９】また、本発明は、ネットワークを介して電
子店舗を提供する複数のショップコンピュータと電子店
舗を利用する利用者の使用する複数のクライアントコン
ピュータとの間に入り、利用者と電子店舗との間で進行
中の取引を管理するトランザクション管理コンピュータ
のトランザクション管理方法であって、複数の前記ショ
ップコンピュータの各々からの通知に基づいて、前記利
用者のクライアントコンピュータと該利用者が所望する
電子店舗を提供するショップコンピュータとの間で行わ
れるべき一定の手続きを経た取引を進行中の取引として
それぞれ登録し、自コンピュータへ登録されている複数
の進行中の取引について、その取引に係る利用者のクラ
イアントコンピュータから該複数の取引の成立を一括し
て確定させるべき旨が指示された場合に、該指示された
複数の取引の各々について、該当する各々のショップコ
ンピュータへ当該取引の成立を確定させるための手続き
が完結可能であるか否かを問い合わせ、指示された複数
の取引の全てについて完結可能であることが確認された
ならば、該当する各々のショップコンピュータへ当該取
引の成立を確定させるための手続きを完結させることを
指示し、前記クライアントコンピュータから指示された
複数の取引のうちに１つでも完結不可能となるものがあ
ることが確認されたならば、該指示された複数の取引の
全てについて、該当する各々のショップコンピュータへ
当該取引を取り消すべきことを指示し、前記指示を出し
たショップコンピュータから処理完了の通知を受けた場
合に、自コンピュータへ登録されている該当する進行中
の取引を、成立した取引又は取り消された取引として更
新することを特徴とする。

【００３０】なお、装置に係る本発明は方法に係る発明
としても成立し、方法に係る本発明は装置に係る発明と
しても成立する。また、装置または方法に係る本発明
は、コンピュータに当該発明に相当する手順を実行させ
るための（あるいはコンピュータを当該発明に相当する
手段として機能させるための、あるいはコンピュータに
当該発明に相当する機能を実現させるための）プログラ
ムを記録したコンピュータ読取り可能な記録媒体として
も成立する。

【００３１】本発明によれば、利用者のクライアントコ
ンピュータと電子店舗のショップコンピュータとの間の
取引情報は、トランザクション管理コンピュータに記録
して管理され、取引の成立又は不成立を確定させるため
の処理は、利用者の指示によりトランザクション管理コ
ンピュータの管理下で実行される。

【００３２】そのため、クライアントコンピュータに障
害が発生した場合でも、クライアントコンピュータをト
ランザクション管理コンピュータへ再接続することによ
って、進行中の取引を継続することができる。

【００３３】また、ショップコンピュータの障害や、ネ
ットワークの切断やパケット紛失等の障害の場合も、ト
ランザクション管理コンピュータの提供する障害回復機
能によって、決済に必要なトランザクション管理コンピ
ュータとショップコンピュータの間のメッセージを再送
して決済処理を継続することができる。

【００３４】その結果、障害が発生してもトランザクシ
ョン管理コンピュータによって回復処理が行われるの
で、利用者も電子店舗も安心して電子商取引を行うこと
ができる。

【００３５】また、利用者はトランザクション管理コン
ピュータをショッピングカートとして使って、複数の異
なる電子店舗での取引を一括して処理することができ
る。

【００３６】また、トランザクション管理コンピュータ
を、利用者自身の過去の取引履歴の記録として活用する
ことができる。

【００３７】

【発明の実施の形態】以下、図面を参照しながら発明の
実施の形態を説明する。

【００３８】以下では、インターネット上のいわゆる電
子店舗などにおける商取引を例にとって説明するが、も
ちろん、本発明は、インターネット以外のネットワーク
にも適用可能であり、また、商取引に該当しない取引あ
るいは契約を扱うシステムにも適用可能である。

【００３９】図１に、本発明の一実施形態に係る電子商
取引システムのネットワーク構成例を示す。

【００４０】本電子商取引システムは、インターネット
６に接続した、トランザクション管理サービス（ＴＭ
Ｓ）事業者のトランザクション管理コンピュータ１、複
数の電子店舗サービス事業者のショップコンピュータ
２、および電子店舗サービスの利用者側の複数のクライ
アントコンピュータ３を含んで構成される。

【００４１】以下では、利用者とはクライアントコンピ
ュータ３のユーザを意味するものとする。利用者は、イ
ンターネット６上の電子店舗サービスを客として利用し
て、商品の購入あるいは宅配サービスの注文あるいは座
席や部屋の予約あるいは或物の賃貸など所望の取引を行
うために（すなわち通常は自己が代金等の金銭債務を負
担する側になる所望の双務契約を締結するために）、ク
ライアントコンピュータ３を操作する。

【００４２】電子店舗サービスを利用するために利用者
が使用するクライアントコンピュータ３上では、ＷＥＢ
ブラウザが動作する。利用者は、ＷＥＢブラウザからイ
ンターネット６を介して、商品の購入等を行いたい所望
の電子店舗サービスを提供する所望のショップコンピュ
ータ２に接続し、ＷＥＢブラウザに表示されたページ画
面を閲覧し、必要に応じてデータを入力し、各種ボタン
を押すなどの作業・操作を繰り返すことによって（両コ
ンピュータ間での各種要求の送信や応答の受信などのや
り取りを通じて）、電子店舗サービスを利用する（例え
ば、商品情報の閲覧や商品の購入手続き等を行う）。も
ちろん、ＷＥＢブラウザではなく、電子店舗サービスを
利用するための専用のソフトウェアなどの他のものを用
いても構わないが、本実施形態ではＷＥＢブラウザを例
にとって説明することとする。

【００４３】また、クライアントコンピュータ３は、ト
ランザクション管理コンピュータ１やショップコンピュ
ータ２と通信するための手段（例えば通信ソフトや通信
インタフェース装置等）を持つ。

【００４４】なお、クライアントコンピュータ３は、図
示しないインターネット・サービス・プロバイダ経由で
インターネット６に接続されるものであってもよいし、
インターネット・サービス・プロバイダを介さずにイン
ターネット６に接続されているものであってもよい。

【００４５】ショップコンピュータ２上では、電子店舗
プログラムが動作し、クライアントコンピュータ３の利
用者に対して、例えば商品販売サービスのサイトでは商
品やサービスの内容の説明やその価格の提示、利用者か
らの注文を受けての在庫の確認、支払いの処理、配送の
手配といった販売処理を行うなど、サイトごとに様々な
電子店舗サービスを提供する。ショップコンピュータ２
上の電子店舗プログラムは、必要な情報、例えば商品の
カタログに関する情報、在庫に関する情報、個々の取引
の内容に関する情報、実際の支払や配達に関する情報な
どをデータベースに管理しながら処理を進める。

【００４６】また、ショップコンピュータ２は、トラン
ザクション管理コンピュータ１やクライアントコンピュ
ータ３と通信するための手段（例えば通信ソフトや通信
インタフェース装置等）を持つ。

【００４７】トランザクション管理コンピュータ１は、
概略的には、電子店舗サイトを越えて利用できるグロー
バルなショッピングカートを提供する（以下、このグロ
ーバルなショッピングカートを単にショッピングカート
と呼び、電子店舗サイト内のショッピングカートをロー
カルなショッピングカートと呼ぶ）。利用者は、後述す
るような手続きによって、ショッピングカート内に、あ
る電子店舗において現在進行中の取引を保留することが
できる。なお、ショッピングカート内に保留されている
取引は、利用者の電子店舗に対する一定の手続きを経て
いて取引内容自体は（全てまたは主要部分が）定まって
いるが、利用者が最終的に取引の成立を確定させる意思
（意図）を表示あるいは通知する（ための指示をシステ
ムに入力する）か、当該取引をショッピングカートから
破棄するすなわち当該取引の不成立を確定させる意思
（意図）を表示あるいは通知する（ための指示をシステ
ムに入力する）かが待たれている状態にある（後述する
“ＡＣＴＩＶＥ”の状態にある）。

【００４８】トランザクション管理コンピュータ１で
は、図２に示すように、クライアントコンピュータ３と
ショップコンピュータ２との間で行われる取引の管理を
行うための（利用者にショッピングカート機能を提供す
るための）トランザクション管理プログラム１１が動作
する。

【００４９】また、図２に示すように、トランザクショ
ン管理コンピュータ１で動作するトランザクション管理
プログラム１１は、個人情報データベース１２と取引情
報データベース１３を管理している。個人情報データベ
ース１２には、取引の際に必要になる登録している利用
者の個人情報（氏名の他、必要に応じて、電話番号、住
所、銀行の口座番号およびまたはクレジットカード番
号、電子メールアドレスなど）が記録されている。取引
情報データベース１３には、現在進行中の取引（すなわ
ちショッピングカートの中に保留されている取引）に関
する情報が記録されるとともに、履歴サービスを提供す
る場合には、過去の取引（当該ショッピングカートを利
用して成立した取引）の履歴に関する情報が記録され
る。これらのデータベースには、重要なデータが記録さ
れるので、障害によってデータが消えたりすることの無
いように、データベース管理システムによってＡＣＩＤ
（Ａｔｏｍｉｃｉｔｙ、Ｃｏｎｃｕｒｒｅｎｃｙ、Ｉｓ
ｏｌａｔｉｏｎ、Ｄｕｒａｂｉｌｉｔｙ）性を保証して
管理するように実施することが望ましい。

【００５０】また、トランザクション管理コンピュータ
１は、ショップコンピュータ２やクライアントコンピュ
ータ３と通信するための手段（例えば通信ソフトや通信
インタフェース装置等）を持つ。

【００５１】本実施形態では、利用者は、トランザクシ
ョン管理コンピュータ１によるトランザクション管理サ
ービス（のショッピングカート）を利用してショップコ
ンピュータ２による電子店舗サービスを受けることも、
トランザクション管理サービスを利用せずに電子店舗サ
ービスを受けることも可能である。トランザクション管
理サービスを利用する場合、まず、利用者が電子店舗の
ページを介して操作を行うことによって（利用者と電子
店舗側の契約主体との間の）取引の内容が定まり、利用
者が例えばＷＥＢブラウザに表示された電子店舗のペー
ジ上の『トランザクション管理サービスを利用するため
のボタン』を押すことによって、その内容の取引の成立
が保留された状態になり、その後、利用者が例えばＷＥ
Ｂブラウザに表示されたトランザクション管理サービス
のページ上の『取引の成立を確定させるためのボタン』
を押すことによって、当該内容の取引の成立を確定させ
るための処理（当該取引についての手続きを有効に完結
させるための処理）が開始され、一方、『取引の不成立
を確定させるためのボタン』を押すことによって、当該
内容の取引の不成立を確定させるための処理（当該取引
に係るこれまでの手続きを取り消すあるいは破棄するた
めの処理）が開始される。また、トランザクション管理
サービスを利用する場合、詳しくは後述するように、利
用者は、まず、複数の取引をショッピングカートに保持
（保留）し、その後、それら取引の成立または不成立を
一括して確定させることができる（個別に取引の成立ま
たは不成立を確定させることも可能である）。

【００５２】なお、以下の説明では、既存の電子店舗で
よく行われているように指定口座からの引き落としなど
により決済する場合を例にとっていることから、決済の
面を強調して、『取引の成立を確定させるためのボタ
ン』を、『決済ボタン』（『一括決済ボタン』、『個別
決済ボタン』）と呼んでページ画面上に表示している
（図１４参照）。もちろん、商品引き渡し時に代金を支
払い、あるいは飛行機に搭乗する日にカウンターで料金
を支払い、あるいは宿泊後に料金を支払うような取引に
も適用可能である（サイトに応じて処理を行えばよ
い）。また、ボタンの名前としては、例えば、『確認ボ
タン』、『確定ボタン』、『決定ボタン』、『申込みボ
タン』など、他の名称でも構わない。また、売買でない
取引が含まれていたとしても（利用者に誤解が生じなけ
れば）、『購入ボタン』などと表示しても構わない。ま
た、ボタン以外のＧＵＩ部品を用いても構わない。な
お、ＧＵＩ部品に代えてまたはＧＵＩ部品とともに、音
声による入力を可能としてもよい。

【００５３】また、『取引の不成立を確定させるための
ボタン』を、『取消ボタン』（『一括取消ボタン』、
『個別取消ボタン』）と呼んでページ画面上に表示して
いる（図１４参照）が、上記と同様に、他の名称でも構
わないし、ボタン以外のＧＵＩ部品を用いても構わな
い。なお、ＧＵＩ部品に代えてまたはＧＵＩ部品ととも
に、音声による入力を可能としてもよい。

【００５４】また、トランザクション管理コンピュータ
１の管理する取引情報データベース１３（図９参照）で
は、利用者が１つまたは複数の取引について最終的に
『取引の成立を確定させるためのボタン』すなわち本具
体例では『一括決済ボタン』または『個別決済ボタン』
を押した日時（または該ボタンを押したことによってク
ライアントコンピュータ３から送信された情報をトラン
ザクション管理コンピュータ１が受信した日時）を記録
するフィールドを、『（一括／個別）決済ボタン』の名
称に対応させて、「決済日時」と呼んでいるが、これ
は、例えば、「確認日時」、「確定日時」、「決定日
時」、「申込日時」など、他の名称でも構わない。

【００５５】また、以下の説明では、電子店舗を利用し
てホテルの部屋等の予約を行う場合を例にとって説明す
ることから、システム上、『トランザクション管理サー
ビスを利用するためのボタン』を『ＴＭＳで予約するボ
タン』あるいは『ＴＭＳで支払いボタン』、トランザク
ション管理サービスを利用しない場合に押すボタンを
『予約するボタン』あるいは『支払いボタン』と呼んで
ページ画面上に表示している（図８参照）。例えば、商
品売買のサイトの場合には、ボタンの名前は、『ＴＭＳ
で購入するボタン』などとすればよい。また、ボタンの
名前は、『ＴＭＳのショッピングカートを利用するボタ
ン』、『商品をＴＭＳのショッピングカートに入れるボ
タン』など、他の名称でも構わない。また、ボタン以外
のＧＵＩ部品を用いても構わない。なお、ＧＵＩ部品に
代えてまたはＧＵＩ部品とともに、音声による入力を可
能としてもよい。

【００５６】ところで、クライアントコンピュータ３の
利用者がショップコンピュータ２によって提供される電
子店舗サービスを利用する形態としては、会員制はとら
ずに当該サイトを無条件に誰でも使用できるものとする
形態の他に、会員制はとらないが一定の条件を満たすも
ののみ当該サイトを使用できる形態、当該サイトの有料
の会員になった利用者のみを対象とする形態、当該サイ
トの会員と非会員とで受けられるサービスの内容を異な
らせた形態など種々の形態が可能である。また、当該サ
イトの利用料の形態としては、無償とする形態の他に、
会員サービスを利用する利用者が例えば毎月ごとに基本
登録料を支払う形態など種々の形態が可能である。

【００５７】クライアントコンピュータ３の利用者がト
ランザクション管理コンピュータ１によって提供される
トランザクション管理サービスを利用する形態や当該サ
イトの利用料の形態は上記と同様である。ただし、本実
施形態では、クライアントコンピュータ３の利用者がト
ランザクション管理コンピュータ１のトランザクション
管理サービスを利用する前に、あるいは利用する際に、
当該利用者に関する情報をトランザクション管理コンピ
ュータ１の個人情報データベース１２に登録するための
手続きがなされるものとする。

【００５８】ショップコンピュータ２の電子店舗サービ
ス事業者がトランザクション管理コンピュータ１によっ
て提供されるトランザクション管理サービスを利用する
形態としては、本実施形態では、当該トランザクション
管理サービス事業者と契約した電子店舗サービス事業者
のみが使用できる形態の他に、無条件にまたは一定の条
件を満たす電子店舗サービス事業者が使用できる形態な
ど他の形態も可能である。また、当該サイトの利用料の
形態としては、無償とする形態も、有償とする形態も可
能である。後者の場合には、電子店舗サービス事業者が
一定の契約料を支払う形態、電子店舗サービス事業者が
当該サイトによるトランザクション管理サービスを通じ
て成立した取引の内容に応じて手数料を支払う形態など
種々の形態が可能である。

【００５９】以下、本実施形態について具体例を用いな
がら詳しく説明する。

【００６０】具体例として、図３に示すように、ある利
用者Ｙが、そのクライアントコンピュータ３上のＷＥＢ
ブラウザを操作して、札幌Ａホテルのショップコンピュ
ータ２と日本Ｂエアラインのショップコンピュータ２が
インターネット６上で提供している電子店舗サービスを
利用するとともに、その際、トランザクション管理コン
ピュータ１が提供しているトランザクション管理サービ
スを利用して、３月１０日に東京から飛行機で札幌へ行
って２泊して３月１２日に帰ってくる旅行の手配（日本
Ｂエアラインの東京札幌間の往復の航空便の座席および
札幌Ａホテルの３月１０日、１１日の２泊分の部屋の予
約）を行う場合を例にする。

【００６１】なお、図３において、トランザクション管
理サービス・サイトにはトランザクション管理コンピュ
ータ１が設置されており、トランザクション管理コンピ
ュータ１上のトランザクション管理プログラム１１は
“ｈｔｔｐ：／／ｗｗｗ．ｔｍｓ．ｓｏｍｅｎｅｔ／”
というＵＲＬで接続することができるものとする。ま
た、札幌Ａホテルのショップコンピュータ２は“ｈｔｔ
ｐ：／／ｗｗｗ．ｓａｈ．ｓｏｍｅｎｅｔ／”というＵ
ＲＬで、日本Ｂエアラインのショップコンピュータ２は
“ｈｔｔｐ：／／ｗｗｗ．ｊｂａ．ｓｏｍｅｎｅｔ／”
というＵＲＬでそれぞれ接続することができるものとす
る。

【００６２】ここでは、利用者は、札幌Ａホテルと日本
Ｂエアラインの両方を同時に予約できるときのみ予約を
行い、どちらか一方だけしか予約できないときは両方と
も予約しない場合を考える。

【００６３】以下、利用者がこのような予約のための操
作を行う場合について、クライアントコンピュータ３と
ショップコンピュータ２とトランザクション管理コンピ
ュータ１の間の情報の流れや、クライアントコンピュー
タ３の表示画面上に表示されるページの流れを参照しな
がら説明する。

【００６４】なお、ここで示す実施形態では、クライア
ントコンピュータ３とショップコンピュータ２とトラン
ザクション管理コンピュータ１の間の通信は、ＨＴＴＰ
プロトコルで行われるものとする。また、必要に応じて
ＳＳＬ（Ｓｅｃｕｒｅ Ｓｏｃｋｅｔ Ｌａｙｅｒ）な
どの手段を使ってセキュリティを高めることが望まし
い。

【００６５】まず、利用者が、クライアントコンピュー
タ３（例えば自分のコンピュータ）のＷＥＢブラウザを
使って、札幌Ａホテルを予約する手続きから始める。こ
のときの処理の流れは図４のようになる。

【００６６】利用者は、札幌Ａホテルのホームページへ
接続するために、ＷＥＢブラウザに札幌ＡホテルのＵＲ
Ｌ（この例では、ｈｔｔｐ：／／ｗｗｗ．ｓａｈ．ｓｏ
ｍｅｎｅｔ／）を打ち込むと、ＧＥＴリクエスト（図４
の［２］）が札幌Ａホテルのショップコンピュータ２に
送られ、その結果、該ショップコンピュータ２から札幌
Ａホテルのホームページが送り返され（図４の
［３］）、クライアントコンピュータ３上のＷＥＢブラ
ウザには例えば図５のように表示される。

【００６７】利用者は、図５のホームページから、宿泊
を予約したり、ホテル内の施設の情報を閲覧したりする
ことができる。ここでは、シングルルームの予約をした
いので『予約』ボタンを押すと（図４の［４］）、シン
グルルームの予約ページのＧＥＴリクエストが札幌Ａホ
テルのショップコンピュータ２に送られ（図４の
［５］）、それに答えて該ショップコンピュータ２から
シングルルームの予約ページが送り返され（図４の
［６］）、クライアントコンピュータ３上のＷＥＢブラ
ウザには例えば図６のように表示される。

【００６８】こうして表示されたページに対して、図７
のように予約内容である宿泊希望日と宿泊数（ここでは
３月１０日から２泊）を入力し（図４の［７］）、『空
室確認』ボタンを押すと予約確認のためのＧＥＴリクエ
ストが送られる（図４の［８］）。このＧＥＴリクエス
トには予約内容が“ｄａｔｅ＝０３１０＆ｄａｙ＝２”
というＵＲＬのクエリとして指定されている。

【００６９】このＧＥＴリクエストを受け取った札幌Ａ
ホテルのショップコンピュータ２は、空室状況をチェッ
クし、予約を受けられれば、予約確認のページを送り返
し（図４の［１０］）、クライアントコンピュータ３上
のＷＥＢブラウザには例えば図８のように表示される。
なお、空室状況をチェックした結果、もし満室で予約を
受けられない場合には、札幌Ａホテルのショップコンピ
ュータ２からその旨を表示するためのページが送られ、
クライアントコンピュータ３上のＷＥＢブラウザにその
旨が表示される。

【００７０】図８の予約確認ページの内容でよければ、
予約する手続を開始する。図８では、『予約する』と
『ＴＭＳで予約する』の２つのボタンが並んでいる。ト
ランザクション管理コンピュータ１のトランザクション
管理サービス（のショッピングカート機能）を利用する
場合には『ＴＭＳで予約する』ボタンを押し、トランザ
クション管理サービスを利用しない場合には『予約す
る』ボタンを押すものとする。

【００７１】『予約する』ボタンを押した場合、従来通
り、当該クライアントコンピュータ３と当該ショップコ
ンピュータ２との間で予約のための手続きを行う（必要
に応じて支払のための銀行の口座番号もしくはクレジッ
トカード番号の入力なども行う）。

【００７２】この例では、利用者は、取引をショッピン
グカート内に保留させるために、『ＴＭＳで予約する』
ボタンを押すことになる。

【００７３】利用者が図８の予約確認ページで『ＴＭＳ
で予約する』ボタンを押すと（図４の［１１］）、トラ
ンザクション管理コンピュータ１を使って予約するため
のＧＥＴリクエストが札幌Ａホテルのショップコンピュ
ータ２に送られる（図４の［１２］）。なお、ここで
は、予約内容（この例では、“ｄａｔｅ＝０３１０＆ｄ
ａｙ＝２”）もＵＲＬのクエリとして送っているが、Ｃ
ＯＯＫＩＥ等の機構を使って、予約内容をショップコン
ピュータ２側に覚えておくように実装することもでき
る。

【００７４】この『ＴＭＳで予約する』ボタンによるＧ
ＥＴリクエストを受け取った札幌Ａホテルのショップコ
ンピュータ２は、予約内容（取引内容）をデータベース
に記録する（図４の［１３］）。このとき、この予約を
識別するための取引ＩＤを発行し、予約内容を取引ＩＤ
と対応付けて記録しておく。ショップコンピュータ２と
トランザクション管理コンピュータ１の間では、この取
引ＩＤを使って個々の取引を識別する。トランザクショ
ン管理コンピュータ１側では、具体的な取引内容（例え
ば、上記の予約内容や、商品売買の場合における商品Ｉ
Ｄとその個数など）は知る必要がない。

【００７５】なお、『予約する』ボタンによるＧＥＴリ
クエストを受け取った場合には、従来通り、その時点
で、当該予約がなされたことが確定し、該利用者のため
に予約日に部屋を確定的に確保するための処理がなされ
ることになるが、『ＴＭＳで予約する』ボタンによるＧ
ＥＴリクエストを受け取った場合には、利用者による取
引の取り消しが留保されているので、当該予約がなされ
たことが確定せず、該利用者のために予約日に部屋を確
定的に確保するための処理がなされることにはならな
い。ただし、本実施形態では、各電子店舗において、
『ＴＭＳで予約する』ボタンによるＧＥＴリクエストを
受け取った際に、当該内容の予約が後に不能に転じない
ように、該利用者のために予約日に部屋を仮に確保して
おき、後に利用者が例えば『一括決済ボタン』（図２５
参照）を押したことなどによって、当該予約がなされた
ことが確定されたときに、当該取引の成立を確定させる
ための処理において、この仮の確保を確定的な確保に更
新するための処理を行う（当該取引の不成立の確定の際
には、仮の確保を解放する）ようにするものとする。

【００７６】さて、ショップコンピュータ２は、また、
トランザクション管理コンピュータ１に登録されている
自分の店ＩＤと取引ＩＤの組を、トランザクション管理
コンピュータ１に登録する（図４の［１４］）。ここで
は、札幌Ａホテルの店ＩＤは“ｓａｈ”であるものと
し、今回の予約の取引ＩＤは“１０２９３”であるとす
る。

【００７７】トランザクション管理コンピュータ１の管
理する取引情報データベース１３は、例えば、図９に示
すようなテーブルとして実装される。テーブルの各行は
一つの取引情報を記録しており、図９の例では各行は８
個のフィールドから構成される。「客ＩＤ」は、その取
引に係る利用者の識別子を保持するフィールドである。
「店ＩＤ」は、その取引に係る電子店舗の識別子を保持
するフィールドである。なお、１つのショップコンピュ
ータ２が複数の異なる電子店舗を持っていてもよい。
「取引ＩＤ」は、各々の取引を識別する情報を保持する
フィールドである。「決済日時」は、利用者が『一括決
済』ボタンまたは『個別決済』ボタン（図２５参照）を
押した日時（あるいは該ボタンが押されたことを契機と
してクライアントコンピュータ３から送信されたメッセ
ージを受信した日時）を記録するフィールドである。な
お、この「決済日時」フィールドは、後で説明するよう
に、該当する取引の状態が“ＣＯＭＭＩＴＴＥＤ”にな
るまでは、最後に取引の状態を変更した時刻や、障害時
にメッセージを再送した時刻を記録するためにも使用さ
れる。このような、該当する取引の状態が“ＣＯＭＭＩ
ＴＴＥＤ”になるまでの状態が変化した時刻を記録する
ために、別のフィールドを用意するようにしてもよい。
「登録日時」は、その取引がトランザクション管理コン
ピュータ１に登録された日時を記録するフィールドであ
る。「状態」は、その取引がどのような状態にあるかを
示している。図９の例では、“ＣＯＭＭＩＴＴＥＤ”は
取引が成立した状態、“ＡＢＯＲＴＥＤ”は一旦ショッ
ピングカートに入れられた後に取り消された状態、“Ａ
ＣＴＩＶＥ”は現在取引が進行中で取引の成立が確定し
ていない状態（ショッピングカート内に保留されている
状態）であることをそれぞれ示している。「カートメッ
セージ」フィールドは、その取引の内容に関する情報
で、利用者個人用のショッピングカートページに取引の
情報を表示する際に利用される。「完了メッセージ」
は、取引成立時の処理が完了したときの電子店舗から利
用者へのメッセージを記録するフィールドである。従っ
て、「状態」が“ＡＢＯＲＴＥＤ”の取引は完了メッセ
ージを持たない。

【００７８】図９は、トランザクション管理コンピュー
タ１が、札幌Ａホテルから、店ＩＤが“ｓａｈ”で且つ
取引ＩＤが“１０２９３”の取引情報を受け取り、それ
を登録した直後の取引情報データベース１３の状態を示
している。図９の最初の行がこの取引に対応しており、
まだ客ＩＤと対応付けられておらず、取引の成立もなさ
れていないので、客ＩＤと決済日時は空で、状態は“Ａ
ＣＴＩＶＥ”である。カートメッセージの内容は、店Ｉ
Ｄと取引ＩＤを登録するメッセージに付随して送られて
くるものとする。

【００７９】なお、クライアントコンピュータ３からシ
ョップコンピュータ２へ客ＩＤまたはこれを特定可能な
情報を送信するなどによって、ショップコンピュータ２
が客ＩＤを取得可能とし、ショップコンピュータ２から
トランザクション管理コンピュータ１へ店ＩＤと取引Ｉ
Ｄとともに客ＩＤをも送信し、この時点で、取引情報デ
ータベース１３に客ＩＤをも登録してしまうような構成
も可能である。

【００８０】このようにして取引情報データベース１３
への登録が終わると、トランザクション管理コンピュー
タ１は登録完了をショップコンピュータ２へ知らせる
（図４の［１６］）。

【００８１】トランザクション管理コンピュータ１から
登録完了を受け取るとショップコンピュータ２は、クラ
イアントコンピュータ３に対して、店ＩＤ（ｓａｈ）と
取引ＩＤ（１０２９３）をもってトランザクション管理
コンピュータ１に接続するようにＨＴＴＰプロトコルの
リダイレクトを指示する（図４の［１７］）。本実施形
態では、ショップコンピュータ２は、クライアントコン
ピュータ３に対して、店ＩＤと取引ＩＤをクエリに持つ
トランザクション管理コンピュータ１のＵＲＬを指定し
て、リダイレクトを指示している。

【００８２】リダイレクトの指示を受け取ったクライア
ントコンピュータ３は、指示されたトランザクション管
理コンピュータ１のＵＲＬ（この例では、ｈｔｔｐ：／
／ｗｗｗ．ｔｍｓ．ｓｏｍｅｎｅｔ／）へＧＥＴリクエ
ストを送る（図４の［１８］）。

【００８３】クライアントコンピュータ３からのＧＥＴ
リクエストを受け取ったトランザクション管理コンピュ
ータ１は、まず、利用者の認証を行うために、客ＩＤと
パスワードの入力を促す（図４の［１９］）。このとき
にクライアントコンピュータ１には例えば図１０のよう
に表示される。これに従って利用者は客ＩＤとパスワー
ドを入力（図１１参照）すると（図４の［２０］）、そ
の情報がトランザクション管理コンピュータ１に送られ
（図４の［２１］）、トランザクション管理コンピュー
タ１は個人情報データベース１２を参照して利用者の認
証を行う（図４の［２２］）。

【００８４】トランザクション管理コンピュータ１の管
理する個人情報データベース１２は、例えば、図１２に
示すような構造のテーブルとして実施できる。テーブル
の各行は一つの個人情報を記録しており、図１２の例で
は各行は７個のフィールドから構成される。「客ＩＤ」
フィールドは、その利用者に与えられた一意の識別名で
ある。「パスワード」フィールドは、その利用者を認証
するためのパスワードである。「名前」フィールドに
は、利用者の名前が記録される。「住所」フィールドに
は、利用者の住所等が記録される。「電話番号」フィー
ルドには、利用者の電話番号等が記録される。「メール
アドレス」フィールドには、利用者の電子メールのアド
レスが記録される。「口座番号」フィールドには、代金
の引き落としなどに使う銀行の口座番号が記録されてい
る。

【００８５】個人情報データベース１２には、他にも様
々な情報が記録されるように実施してよい。代金の支払
方法によっては、例えばクレジットカードの番号を記録
しておくフィールドなどを設けるように実施することも
できる。逆に、代金の支払方法には関与せず、口座番号
やクレジットカードの番号などのフィールドを持たない
構成もあり得る。

【００８６】ここでは、利用者から送られてきた客ＩＤ
とパスワードから、客ＩＤを使って個人情報データベー
ス１２を検索し、そこに記録されているパスワードと送
られてきたパスワードとを比較することで認証を行う。

【００８７】なお、認証方式はここで示した方式以外に
も様々な方式があり、どのような方式を用いるように実
装しても構わない。認証方式によっては、個人情報デー
タベース１２にパスワードを直接記録しない場合もある
し、その他の必要な情報を記録する場合もある。

【００８８】なお、ここでは、以降、利用者のクライア
ントコンピュータ３のＷＥＢブラウザが起動中は、利用
者の認証は不要であり、クライアントコンピュータ３が
ダウンし再起動したことなどによって、ＷＥＢブラウザ
が再起動となった際には、あらためて、利用者の認証が
必要になる場合を例にとっている。

【００８９】さて、トランザクション管理コンピュータ
１では、利用者の認証が終わると、接続してきた利用者
の客ＩＤがわかる。この例の場合、客ＩＤは“ｈｉｒｏ
ｓｈｉ．ｙａｍａｄａ”である。リクエストに付随して
きた店ＩＤと取引ＩＤを使って、取引情報データベース
１３から対応する取引情報を検索し、その取引情報の客
ＩＤフィールドは空のままであるので、そこに接続して
きた利用者の客ＩＤを記録する（図４の［２３］）。そ
うすると取引情報データベース１３は、図１３のような
状態になる。図９の状態からの変化は、客ＩＤが埋まっ
ていることである。

【００９０】取引情報データベース１３への登録が完了
すると、トランザクション管理コンピュータ１は、取引
情報データベース１３の中から、接続してきた利用者の
客ＩＤを持つ取引情報を取り出し、その情報を表示する
ショッピングカートページを作成してクライアントコン
ピュータ３へ送り返す（図４の［２４］）。

【００９１】このショッピングカートページをクライア
ントコンピュータ３のＷＥＢブラウザが表示すると例え
ば図１４のようになる。図１４には、“ＡＣＴＩＶＥ”
状態にある取引（すなわち、現在取引が進行中で取引の
成立が確定していない状態である取引）の情報が『現在
のショッピングカートの内容』として表示されている。
ここでは、先ほど手続きした札幌Ａホテルの電子店舗で
の取引情報がショッピングカートに入っており、それに
対して『決済』あるいは『取消』を行うボタンが用意さ
れている。このショッピングカート画面における個々の
取引情報の表示には、トランザクション管理コンピュー
タ１の取引情報データベース１３の「カートメッセー
ジ」フィールドの値が用いられる。この画面では、過去
の取引の情報も、画面の下の方にある『今月（１９９９
年１２月）分』ボタン等を押すと、該当する情報を表示
する画面を開くことができる。

【００９２】なお、これまでに説明した実施形態では、
取引ＩＤはショップコンピュータ２が発行していたが、
取引ＩＤをトランザクション管理コンピュータ１が発行
するように実施することもできる。この場合、ショップ
コンピュータ２が店ＩＤをトランザクション管理コンピ
ュータ１に伝えると、トランザクション管理コンピュー
タ１は新しく発行した取引ＩＤと受け取った店ＩＤの組
を取引情報データベース１３に登録し、発行した取引Ｉ
Ｄをショップコンピュータ２に返すようにする。取引Ｉ
Ｄを受け取ったショップコンピュータ２は、その取引Ｉ
Ｄと取引内容の情報とを関連付けてデータベースに記録
しておくようにする。

【００９３】さて、札幌Ａホテルを予約することだけが
目的であれば、図１４の画面で『（一括または個別）決
済』ボタンを押せばよいが、ここでは、さらに飛行機の
予約のための一定の手続きを行い、その結果、所望する
全ての予約が可能となったならば、ショッピングカート
機能を利用して、全ての予約について一括して取引成立
させようとすることになる（この例では『一括決済』ボ
タンを押すことになる）。一方、飛行機の予約が取れな
ければ、すべて予約しないことになる（この例では既に
ショッピングカート内にある札幌Ａホテルについて『個
別取消』ボタンまたは『一括取消』ボタンを押すことに
なる）。

【００９４】そこで、利用者は、次に、クライアントコ
ンピュータ３（例えば自分のコンピュータ）のＷＥＢブ
ラウザを使って、日本Ｂエアラインののインターネット
予約ページで飛行機を予約するための手続きに移る。こ
のときの処理の流れは図１５のようになる。

【００９５】利用者は、日本Ｂエアラインのホームペー
ジへ接続するために、ＷＥＢブラウザに日本Ｂエアライ
ンのＵＲＬ（この例では、ｈｔｔｐ：／／ｗｗｗ．ｊｂ
ａ．ｓｏｍｅｎｅｔ／）を打ち込むと、ＧＥＴリクエス
ト（図１５の［２６］）が日本Ｂエアラインのショップ
コンピュータ２に送られ、その結果、該ショップコンピ
ュータ２から日本Ｂエアラインのホームページが送り返
され（図１５の［２７］）、クライアントコンピュータ
３上のＷＥＢブラウザには例えば図１６のように表示さ
れる（この例ではホームページが予約ページであるもの
とした）。

【００９６】利用者は、図１６の予約入力ページに対し
て、図１７に示すように、予約したい日と発着地および
人数（この例では、３月１０日に、東京から札幌まで、
１人分）を入力する（図１５の［２８］）。入力が完了
した後に『空席確認』ボタンを押すと、空席確認処理の
ＧＥＴリクエストが日本Ｂエアラインのショップコンピ
ュータ２に送られる（図１５の［２９］）。この例で
は、ＵＲＬのクエリ部分に予約したい日や発着地や人数
の情報が指定されている。リクエストを受け取った日本
Ｂエアラインのショップコンピュータ２は、指定された
便の空席状況を調べ（図１５の［３０］）、予約のため
のページを作成してクライアントコンピュータ３に送り
直す（図１５の［３１］）。このページはクライアント
コンピュータ３上のＷＥＢブラウザに例えば図１８のよ
うに表示される。なお、札幌Ａホテルの例と同様に、空
席状況をチェックした結果、もし満席で予約を受けられ
ない場合には、日本Ｂエアラインのショップコンピュー
タ２からその旨を表示するためのページが送られ、クラ
イアントコンピュータ３上のＷＥＢブラウザにその旨が
表示される。

【００９７】図１８の画面で空席状況を見ると、ＪＢＡ
１３５便とＪＢＡ１４１便に空席があることが分かるの
で、ここではＪＢＡ１３５便を選んでその『予約』ボタ
ンを押す（図１５の［３２］）。すると、ＪＢＡ１３５
便を予約するためのＧＥＴリクエストが日本Ｂエアライ
ンのショップコンピュータ２に送られる（図１５の［３
３］）。ここでは、ＵＲＬのクエリ部に、予約したい便
名と日と発着地と人数の情報を持たせているが、先に予
約確認の際に送った予約したい日と発着地と人数の情報
をショップコンピュータ２側で覚えておくように実施し
てもよい。リクエストを受け取った日本Ｂエアラインの
ショップコンピュータ２は、予約内容を予約番号（Ｃ１
０１３５０９７）とともにデータベースに登録し（図１
５の［３４］）、予約確認ページをクライアントコンピ
ュータ３に送り返す（図１５の［３５］）。このとき、
本実施形態では、ＣＯＯＫＩＥを使って予約番号を一緒
に送り返し、ＷＥＢブラウザが予約番号を覚えておく。
こうして送られてきた予約確認ページはクライアントコ
ンピュータ３上のＷＥＢブラウザに例えば図１９のよう
に表示される。

【００９８】なお、札幌Ａホテルの例と同様の理由で、
図１８の『予約』ボタンによるＧＥＴリクエストを受け
取った際に、当該内容の予約が後に不能に転じないよう
に、該利用者のために予約日に座席を仮に確保するため
の処理を行い、後に当該取引の成立の確定の際に、仮の
確保を確定的な確保に更新するための処理を行う（当該
取引の不成立の確定の際には、仮の確保を解放する）よ
うにするものとする。

【００９９】さて、図１９のページの表示を見ると、こ
のときに、利用者は、『続いて予約』ボタンを押して他
の便の予約を続けることを選択することも、『ＴＭＳで
支払い』ボタンを押してトランザクション管理コンピュ
ータ１によるトランザクション管理サービスを利用して
手続きすることを選択することも、『支払い』ボタンを
押して従来通りトランザクション管理サービスを利用せ
ずに手続きすることを選択することもできるようになっ
ている。

【０１００】この例では、利用者は、『続いて予約』ボ
タンを押して帰りの便の予約を続けることになる。

【０１０１】利用者が図１９の画面で『続いて予約』ボ
タンを押すと（図１５の［３６］）、先ほどと同様に、
予約ページのＧＥＴリクエストが日本Ｂエアラインのシ
ョップコンピュータ２に送られる（図１５の［３
７］）。そのリクエストに答えて送られてきた（図１５
の［３８］）予約ページを表示すると、例えば図１６の
ようになる。なお、図２０のように、当該サイト内にお
けるローカルなショッピングカート内の情報を提示する
ようにしてもよい。

【０１０２】利用者は図１６（あるいは図２０）の予約
入力ページに対して、図２１に示すように、予約したい
日と発着地および人数（この例では、３月１２日に、札
幌から東京まで、１人分）を入力する（図１５の［３
９］）。入力が完了した後に『空席確認』ボタンを押す
と、空席確認処理のＧＥＴリクエストが日本Ｂエアライ
ンのショップコンピュータ２に送られる（図１５の［４
０］）。リクエストを受け取った日本Ｂエアラインのシ
ョップコンピュータ２は、指定された便の空席状況を調
べ（図１５の［４１］）、予約のためのページを作成し
て送り返す（図１５の［４２］）。このページが例えば
図２２のように表示される。

【０１０３】図２２の画面を見ると、ＪＢＡ２４０便と
ＪＢＡ２４６便に空席があることが分かるので、ここで
はＪＢＡ２４６便を選んで『予約』ボタンを押す（図１
５の［４３］）。すると、ＪＢＡ２４６を予約するため
のＧＥＴリクエストが日本Ｂエアラインのショップコン
ピュータ２に送られる（図１５の［４４］）。リクエス
トを受け取った日本Ｂエアラインのショップコンピュー
タ２は、予約内容を予約番号（Ｃ１２２４６１０３）と
ともにデータベースに登録し（図１５の［４５］）、予
約確認ページを送り返す（図１５の［４６］）。このと
きも、ＣＯＯＫＩＥを使って予約番号を一緒に送り返
し、ＷＥＢブラウザが予約番号を覚えておく。こうして
送られてきた予約確認ページは、例えば図２３のように
表示される。

【０１０４】以上で、東京札幌間の往復の飛行機が予約
できることになったので、当該進行中の取引（トランザ
クション管理コンピュータ１から見るとローカルなショ
ッピングカートを一括した１つの取引）をトランザクシ
ョン管理コンピュータ１に登録するために（ショッピン
グカートに入れるために）、利用者は『ＴＭＳで支払
い』ボタンを押す（図１５の［４７］）。『ＴＭＳで支
払い』ボタンが押されると、ＣＯＯＫＩＥを使って記憶
していた予約番号（Ｃ１０１３５０９７とＣ１２２４６
１０３）をクエリ部に持ったＧＥＴリクエストが、日本
Ｂエアラインのショップコンピュータ２に送られる（図
１５の［４８］）。

【０１０５】この『ＴＭＳで支払い』ボタンによるＧＥ
Ｔリクエストを受け取った日本Ｂエアラインのショップ
コンピュータ２は、取引ＩＤ（６３７２）を発行し、予
約内容（取引内容）を取引ＩＤと関連付けてデータベー
スに記録し（図１５の［４９］）、トランザクション管
理コンピュータ１に対して、日本Ｂエアラインの店ＩＤ
“ｊｂａ”と取引ＩＤ“６３７２”の組を登録するリク
エストを送る（図１５の［５０］）。このリクエストに
は、この取引ＩＤに対応するカートメッセージも添えて
送る。

【０１０６】トランザクション管理コンピュータ１は、
受け取った店ＩＤと取引ＩＤからなる取引情報を取引情
報データベース１３に登録し（図１５の［５１］）、同
時に送られてきたカートメッセージも併せて登録する。

【０１０７】このようにして取引情報データベース１３
への登録が終わると、ショップコンピュータ２は登録完
了をショップコンピュータ２へ知らせる（図１５の［５
２］）。

【０１０８】トランザクション管理コンピュータ１から
登録完了を受け取るとショップコンピュータ２は、クラ
イアントコンピュータ３に対して、店ＩＤ（ｊｂａ）と
取引ＩＤ（６３７２）をもってトランザクション管理コ
ンピュータ１に接続するようにＨＴＴＰプロトコルのリ
ダイレクトを指示する（図１５の［５３］）。

【０１０９】リダイレクトの指示を受け取ったクライア
ントコンピュータ３は、指定されたＵＲＬ（すなわちト
ランザクション管理コンピュータ１のＵＲＬ）へＧＥＴ
リクエストを送る（図１５の［５４］）。

【０１１０】クライアントコンピュータ３からのＧＥＴ
リクエストを受け取ったトランザクション管理コンピュ
ータ１は、ここでは利用者の認証は既に終わっているの
で、リクエストに付随してきた店ＩＤと取引ＩＤを使っ
て、取引情報データベース１３から対応する取引情報を
検索し、その取引情報の客ＩＤフィールドは空のままで
あるので、そこに接続してきた利用者の客ＩＤを記録す
る（図１５の［５５］）。この時点で、取引情報データ
ベース１３は、図２４のような状態になる。

【０１１１】取引情報データベース１３への登録が完了
すると、トランザクション管理コンピュータ１は、取引
情報データベース１３の中から、接続してきた利用者の
客ＩＤを持つ取引情報を取り出し、その情報を表示する
ショッピングカートページを作成して送り返す（図１５
の［５６］）。

【０１１２】このショッピングカートページをクライア
ントコンピュータ３のＷＥＢブラウザで表示すると例え
ば図２５のようになる。図２５を見ると、先に予約した
札幌Ａホテルの取引情報と今予約した日本Ｂエアライン
の取引情報が、ショッピングカートに入っていることが
わかる。

【０１１３】ここで、日本Ｂエアラインのショップコン
ピュータ２の電子店舗プログラムは、当該電子店舗内の
ローカルなショッピングカート機能によって、複数の便
の予約をまとめて手続きする機能を持っている。このよ
うに、個々の電子店舗あるいはモールが独自にショッピ
ングカート機能を持っている場合でも、トランザクショ
ン管理コンピュータ１はそれらを複数まとめるショッピ
ングカートとして動作することができる。

【０１１４】さて、以上の手続きによって希望通り札幌
Ａホテルの２泊分の部屋と日本Ｂエアラインの往復分の
航空便の座席の予約ができることになったので、次に、
ショッピングカートの機能を利用して、一括してそれら
取引の成立を確定させるための手続きを行う。図２５の
ページを見ると、ショッピングカートに入っている札幌
Ａホテルの取引情報と日本Ｂエアラインでの取引情報の
横に、それぞれ『個別決済』と『個別取消』の２つのボ
タンが並んでいる。これらは、現在ショッピングカート
中にある進行中の取引に対して、個別に取引の成立また
は不成立を確定させるためのボタンである。それらの上
方には、『一括決済』と『一括取消』の２つのボタンが
並んでいる。これらは、現在ショッピングカート中にあ
る進行中の取引に対して、全部まとめて取引の成立また
は不成立を確定させるためのボタンである。

【０１１５】ここでは、『一括決済』ボタンを押して札
幌Ａホテルと日本Ｂエアラインの両方の取引をまとめて
手続きする場合の処理の流れを説明する。このときの処
理の流れは図２６のようになる。

【０１１６】まず、利用者は、図２５のショッピングカ
ート画面で『一括決済』ボタンを押す（図２６の［５
７］）。すると、クライアントコンピュータ３からトラ
ンザクション管理コンピュータ１に対して、一括処理を
指示するＧＥＴリクエストが送られる（図２６の［５
８］）。リクエストを受け取ったトランザクション管理
コンピュータ１は、利用者をまだ認証していない場合に
は認証の処理を行う。ここでは既に認証の処理は終わっ
ているので（図４の［１９］、［２０］、［２１］、
［２２］）省略する。

【０１１７】次に、トランザクション管理コンピュータ
１は、認証済みの客ＩＤを使って、取引情報データベー
ス１３から利用者の取引情報で状態フィールドの値が
“ＡＣＴＩＶＥ”のものを一括処理の対象として検索し
（図２６の［５９］）、それらの取引の確定処理を、図
２７に示すような状態遷移に従って、ショップコンピュ
ータ２と通信しながら進めていく。

【０１１８】図２７の状態遷移は、取引情報データベー
ス１３中の各取引情報が、状態フィールドに記録してい
る状態の遷移を表している。基本的な原理は、広く使わ
れている分散トランザクションの２相コミットプロトコ
ルと同様である。

【０１１９】ショップコンピュータ２から新しく登録さ
れた取引情報は、まず、“ＡＣＴＩＶＥ”状態として取
引情報データベース１３に入る。通常は、利用者により
一括処理が指示されると（例えば『一括決済』ボタンが
押されると）、一括処理対象となる“ＡＣＴＩＶＥ”状
態になっている全ての取引の状態を“ＰＲＥＰＡＲＩＮ
Ｇ”に変更するとともに、各取引の相手となるショップ
コンピュータ２の各々に対して、「当該取引についての
手続きを有効に完結可能かどうか」を問い合わせるＰＲ
ＥＰＡＲＥメッセージを送る。

【０１２０】なお、「当該取引についての手続きを有効
に完結可能かどうか」とは、例えば、（１）ショップコ
ンピュータ２の通信機能以外のシステム上のトラブルが
発生して必要な処理ができないか、そういうことはなく
システムは正常かという点、（２）システム外の何らか
の事態の発生によって当該取引が成立不能になったか、
そういうことはなく成立可能かという点、（３）当該電
子店舗が利用者の銀行の口座番号あるいはクレジットカ
ード番号等から実際に指定口座からの引き落とし等によ
る決済が可能かどうかを調査し、決済可能でないときは
取引の成立を拒否する場合における、当該決済が可能か
どうかという点、（４）当該電子店舗がショッピングカ
ート内の当該取引に係る商品の在庫の確保あるいは部屋
の確保等を保証するシステムではない場合に、ショッピ
ングカート内に当該取引を入れるに際しては成立可能で
あった当該取引が現時点でも成立可能かどうかという点
などの、最終的に取引の成立を確定させることを阻害す
る要因がないかどうかということである。そして、その
ような阻害要因がなく取引の成立が可能である場合に、
当該取引のための手続きを有効に完結可能と判断する。

【０１２１】ショップコンピュータ２は、当該取引につ
いての手続きの完結が可能ならば、ＰＲＥＣＯＭＭＩＴ
メッセージを送り返してくるので、その取引の状態を
“ＰＲＥＣＯＭＭＩＴＥＤ”に変更する。

【０１２２】その後、一括処理対象となっている全ての
取引（本具体例では２つの取引）に対してＰＲＥＣＯＭ
ＭＩＴメッセージが送り返されてきたならば、各取引の
状態を“ＣＯＭＭＩＴＴＩＮＧ”に変更し、該当する各
々のショップコンピュータ２に対してＣＯＭＭＩＴメッ
セージを送って、該当する取引についての手続きを完結
させること（すなわち、該当する取引の成立を確定させ
るための処理の実行）を指示する。ショップコンピュー
タ２は当該取引の成立を確定させるために当該サイトに
おいて必要な処理が終わるとＣＯＭＭＩＴＴＥＤメッセ
ージを返してくるので、当該取引の状態を“ＣＯＭＭＩ
ＴＴＥＤ”に変更する。一括処理対象となっている全て
の取引の状態が“ＣＯＭＭＩＴＴＥＤ”に変更されたな
らば一括処理は完了となる。

【０１２３】ここで、ＰＲＥＰＡＲＥメッセージを受け
取ったショップコンピュータ２は、当該取引についての
手続きの完結が不可能である場合は、当該取引を取り消
しするための処理を行い、ＡＢＯＲＴメッセージを送っ
てくるので、当該取引の状態は“ＡＢＯＲＴＥＤ”に変
更する。このとき、一括処理対象となっている他の取引
のうちにその状態が“ＰＲＥＣＯＭＭＩＴＴＥＤ”にな
っているものがあれば、該取引については、その状態を
“ＡＢＯＲＴＩＮＧ”に変更した後に、該当するショッ
プコンピュータ２にＡＢＯＲＴメッセージを送って、当
該取引を取り消すための処理の実行を指示する。当該取
引の取り消し（破棄）が完了すれば、ショップコンピュ
ータ２はＡＢＯＲＴＥＤメッセージを送ってくるので、
該取引の状態を“ＡＢＯＲＴＥＤ”に変更する。一括処
理対象となっている全ての取引の状態が“ＡＢＯＲＴＥ
Ｄ”に変更されたならば一括処理は完了となる。

【０１２４】なお、利用者から個別処理が指示された場
合（例えば『個別決済』ボタンが押された場合）、一括
処理と同様に二相コミット処理を行ってもよいが、後述
する一相コミットを行ってもよい。

【０１２５】利用者自身が自発的に取引を取り消す場合
（例えばショッピングカートページにおいて『一括取
消』ボタンや『個別取消』ボタンが押された場合）やト
ランザクション管理コンピュータ１が自動的に予め定め
られた基準に従った判断に基づいて取引を取り消するか
否かを判断する構成を採用したたときに、取引を取り消
すと判断した場合には、取り消すべき取引の状態を“Ａ
ＣＴＩＶＥ”から“ＡＢＯＲＴＩＮＧ”に変更した後
に、ショップコンピュータ２にＡＢＯＲＴメッセージを
送り、該当する取引の取り消しが完了したショップコン
ピュータ２からＡＢＯＲＴＥＤメッセージが返ってきた
ら、該取引の状態を“ＡＢＯＲＴＥＤ”にする。一括取
消の場合には、一括処理対象となっている全ての取引の
状態が“ＡＢＯＲＴＥＤ”に変更されたならば一括取消
は完了となる。

【０１２６】なお、トランザクション管理コンピュータ
１とショップコンピュータ２の間の通信は、ＨＴＴＰプ
ロトコルを使ってもよいし、独自のプロトコルを使って
も構わない。ＨＴＴＰプロトコルを使う場合も、例えば
ＰＲＥＰＡＲＥメッセージとＰＲＥＣＯＭＭＩＴメッセ
ージをＨＴＴＰのリクエストとリプライに対応させるよ
うに実施してもよいし、ＰＲＥＰＡＲＥメッセージとＰ
ＲＥＣＯＭＭＩＴメッセージをそれぞれ別のＨＴＴＰの
リクエストとして送るように実施してもよい。なお、ト
ランザクション管理コンピュータ１とショップコンピュ
ータ２の通信は、必要に応じて認証するなどの対策によ
ってセキュリティを高めるように実施することが望まし
い。

【０１２７】さて、取引情報データベース１３から状態
フィールドの値が“ＡＣＴＩＶＥ”になっている取引情
報を検索したトランザクション管理コンピュータ１は、
まず、それら一括処理の対象となる取引情報の状態フィ
ールドの値を“ＰＲＥＰＡＲＩＮＧ”に変更するととも
に、決済日時フィールドに現在の日時を記録する（図２
６の［６０］）。決済日時フィールドに現在の日時を記
録するのは、後で述べるように、一括処理の途中で一定
の時間以上処理が進まないものを取り消すためのタイム
アウトの判断に使うためである。こうして取引情報デー
タベース１３の内容は、図２８に示すようになる。

【０１２８】その後、一括処理対象のすべての取引情報
に関して、その取引を行ったショップコンピュータ２
に、その取引の取引ＩＤを持たせたＰＲＥＰＡＲＥメッ
セージを送る（図２６の［６１］、［６２］）。ここ
で、ＰＲＥＰＡＲＥメッセージの送り先を決定するため
には、取引情報データベース１３に記録されている店Ｉ
Ｄから、それに対応するショップコンピュータ２を見つ
ける必要がある。本実施形態では、トランザクション管
理コンピュータ１上のトランザクション管理プログラム
１１が、あらかじめ店ＩＤとそれに対応するショップコ
ンピュータ２（のＵＲＬ等）との対応表を持っているよ
うに実施しているものとする。

【０１２９】ＰＲＥＰＡＲＥメッセージを受け取ったシ
ョップコンピュータ２の各々は、メッセージに指定され
ている取引ＩＤの取引の情報をそのデータベースの中か
ら検索し、該当する取引についての手続きを有効に完結
させることが可能かどうか（すなわち、該当する取引の
成立を確定させることが可能か、あるいは何らかの要因
によって取引の成立は不可能か）をチェックする（図２
６の［６３］、［６４］）。完結可能であることが分か
れば、トランザクション管理コンピュータ１に対して、
取引ＩＤを持たせたＰＲＥＣＯＭＭＩＴメッセージを送
り返す（図２６の［６５］、［６６］）。

【０１３０】ＰＲＥＣＯＭＭＩＴメッセージを受け取っ
たトランザクション管理コンピュータ１は、該当する取
引情報の状態を“ＰＲＥＰＡＲＩＮＧ”から“ＰＲＥＣ
ＯＭＭＩＴＴＥＤ”に変更する。一括処理対象のすべて
の取引の状態が“ＰＲＥＣＯＭＭＩＴＴＥＤ”になれ
ば、それら全ての取引の成立を確定させることが可能で
あることが確認できたので、それら取引の状態を“ＰＲ
ＥＣＯＭＭＩＴＴＥＤ”から“ＣＯＭＩＴＴＩＮＧ”に
変更するとともに、決済日時フィールドに現在の日時を
記録し（図２６の［６７］）、それら取引の相手となる
各々のショップコンピュータ２に対して、該当する取引
の取引ＩＤを持たせたＣＯＭＭＩＴメッセージを送っ
て、該当する取引についての手続きを完結させること
（すなわち、該当する取引の成立を確定させるための処
理の実行）を指示する（図２６の［６８］、［６
９］）。このとき、本実施形態では、ＣＯＭＭＩＴメッ
セージには、当該サイトにおける手続きに必要な利用者
の個人情報（例えば、利用者の名前の他、必要に応じ
て、配送先の住所、電話番号、代金引き落としの口座番
号など）を一緒に持たせて送るように実施するものとす
る。この場合、予めサイトごとに送信すべき個人情報の
項目を登録しておき、必要な項目のみ送信する方法や、
サイトごとに管理せずに全てのサイトに同一の個人情報
を送信してしまう方法などがある。利用者の個人情報
を、ＣＯＭＭＩＴメッセージではなく、ＰＲＥＰＡＲＥ
メッセージに一緒に持たせるようにしてもよい。

【０１３１】なお、ここでは、指定口座またはクレジッ
トカードによる決済を行う電子店舗側で、そのための手
続きを行う場合を例にとっているが、電子店舗側ですべ
き決済のための手続きをすべてトランザクション管理サ
ービス事業者側（トランザクション管理コンピュータ１
側）で代行ようにすることも可能であるし、予め取り決
めた電子店舗についてのみ手続きを代行するようにする
ことも可能である。

【０１３２】ＣＯＭＭＩＴメッセージを受け取ったショ
ップコンピュータ２の各々は、メッセージに指定されて
いる取引ＩＤの取引の情報をそのデータベースの中から
検索し、ＣＯＭＭＩＴメッセージと一緒に送られてきた
利用者の個人情報を使って、当該取引の成立を確定させ
るために当該サイトにおいて必要な処理を行う（図２６
の［７０］、［７１］）。この処理が完了すれば、トラ
ンザクション管理コンピュータ１に対して、取引ＩＤを
持たせたＣＯＭＭＩＴＴＥＤメッセージを送り返す（図
２６の［７２］、［７３］）。このとき、本実施形態で
は、ＣＯＭＭＩＴＴＥＤメッセージに、完了メッセージ
を一緒に持たせて送るように実施する。完了メッセージ
は、取引の完了を伴う店から利用者へのメッセージであ
る。

【０１３３】ＣＯＭＭＩＴＴＥＤメッセージを受け取っ
たトランザクション管理コンピュータ１は、該当する取
引情報の状態を“ＣＯＭＭＩＴＴＩＮＧ”から“ＣＯＭ
ＭＩＴＥＤ”に変更するとともに、決済日時フィールド
に現在の日時を記録する（図２６の［７４］）。このと
き、ＣＯＭＭＩＴＴＥＤメッセージと一緒に送られてき
た完了メッセージを、取引情報データベース１３中の該
当する取引の完了メッセージフィールドに記録してお
く。一括処理対象のすべての取引の状態が“ＣＯＭＭＩ
ＴＴＥＤ”になれば、すべての手続きが完了したので、
利用者への完了通知ページをクライアントコンピュータ
３へ送り返す（図２６の［７５］）。この時点で、トラ
ンザクション管理コンピュータ１の管理する取引情報デ
ータベース１３の内容は、図２９のようになっている。
本実施形態では、完了通知ページには、該当する取引を
行ったショップコンピュータ２から送られてきた完了メ
ッセージを埋め込むように実施する。

【０１３４】この完了通知メッセージが埋め込まれた完
了通知ページを受け取った利用者のクライアントコンピ
ュータ３では、それをＷＥＢブラウザに表示すると、例
えば図３０のような情報が表示される。

【０１３５】図２６に示した処理の例は、トランザクシ
ョン管理コンピュータ１がショップコンピュータ２に対
して送ったＰＲＥＰＡＲＥメッセージに対して、すべて
のショップコンピュータ２がＰＲＥＣＯＭＭＩＴメッセ
ージを返してきた正常な場合を示している。正常でない
場合には、いずれかのショップコンピュータ２はＰＲＥ
ＣＯＭＭＩＴメッセージではなくＡＢＯＲＴＥＤメッセ
ージを返してくる。この場合、トランザクション管理コ
ンピュータ１は、前述のように、ＰＲＥＣＯＭＭＩＴメ
ッセージを返してきた取引をすべてアボートして取り消
してしまうように実施することができるが、別の方法と
しては、ＰＲＥＣＯＭＭＩＴメッセージを返してきた取
引はアボートせずにコミット処理を続けて手続きを完結
させてしまう（取引の成立を確定させてしまう）ように
実施することもできる。また、利用者に問い合わせて、
すべてを取り消すか、完結可能な取引だけを成立させる
か、あるいは、完結可能な取引のうちから利用者が指定
した取引だけを成立させるかなどを、適宜、使用者に選
択させるように実施することもできる。

【０１３６】本実施形態では、図２５の例に示すよう
に、ショップコンピュータ２中のすべての取引について
アトミックに成立または不成立を確定させることを指示
するボタン以外に、個々の取引を単独で成立または不成
立を確定させることを指示するボタンも提供している。
本発明では、その他の様々な決済方法を用いることが可
能である。例えば、ショッピングカート中のすべての取
引で完結可能なものは成立させ、完結不可能なものは取
り消す方法を提供し、利用者に対して、どのような方法
で成立または不成立を確定させるかを選ばせるように実
施することもできる。また、これらを組み合わせて実施
することも可能である。

【０１３７】また、ショッピングカート内の複数の取引
を、一括処理させる１または複数の取引群ごとにグルー
ピングを設定することができるようにしてもよい。さら
に、一括処理させる１または複数のグルーピングを指定
して、一括処理を指示できるようにしてもよい。

【０１３８】図２６に示した処理の例は、トランザクシ
ョン管理コンピュータ１を、従来から広く使われている
２相コミット方式で複数の取引についてアトミックに成
立または不成立を確定させるように実施したものである
が、２相コミットの代わりに、１相コミットを使うよう
にトランザクション管理コンピュータ１を実施すること
もできる。この場合の一括処理の例を図３１に示す。

【０１３９】この場合も、まず、利用者は図２５のショ
ッピングカート画面で『一括決済』ボタンを押すと（図
３１の［５７］）、するとクライアントコンピュータ３
からトランザクション管理コンピュータ１に対して、一
括処理を指示するＧＥＴリクエストが送られる（図３１
の［５８］）。

【０１４０】次に、トランザクション管理コンピュータ
１は、認証済みの客ＩＤを使って、取引情報データベー
ス１３から利用者の取引情報で状態フィールドの値が
“ＡＣＴＩＶＥ”のものを一括処理の対象として検索し
（図３１の［５９］）、それらの取引を、図３２に示す
ような状態遷移に従って、ショップコンピュータ２と通
信しながら進めていく。

【０１４１】図３２の状態遷移は、図２７の状態遷移を
１相コミットプロトコルにしたものである。

【０１４２】ショップコンピュータ２から新しく登録さ
れた取引情報は、まず、“ＡＣＴＩＶＥ”状態として取
引情報データベース１３に入る。通常は、利用者により
一括処理が指示されると（例えば『一括決済』ボタンが
押されると）、一括処理対象となる“ＡＣＴＩＶＥ”状
態になっている全ての取引の状態を“ＣＯＭＭＩＴＴＩ
ＮＧ”に変更するとともに、各取引の相手となるショッ
プコンピュータ２の各々に対して、ＣＯＭＭＩＴメッセ
ージを送って、該当する取引についての手続きを完結さ
せること（すなわち、該当する取引の成立を確定させる
ための処理の実行）を指示する。ショップコンピュータ
２は当該取引の成立を確定させるために当該サイトにお
いて必要な処理が終わるとＣＯＭＭＩＴＴＥＤメッセー
ジを返してくるので、当該取引の状態を“ＣＯＭＭＩＴ
ＴＥＤ”に変更する。

【０１４３】ここで、ＣＯＭＭＩＴＴＥＤメッセージを
受け取ったショップコンピュータ２は、当該取引につい
ての手続きの完結が不可能である場合（何らかの要因に
よって当該取引の成立が不可能である場合）は、当該取
引を取り消すするための処理を行い、ＡＢＯＲＴメッセ
ージを送ってくるので、当該取引の状態は“ＡＢＯＲＴ
ＥＤ”に変更する。

【０１４４】なお、利用者から個別処理が指示された場
合（例えば『個別決済』ボタンが押された場合）、指示
された取引についてのみ、この一相コミット処理を行
う。

【０１４５】利用者自身が自発的に取引を取り消す場合
（例えばショッピングカートページにおいて『一括取
消』ボタンや『個別取消』ボタンが押された場合）やト
ランザクション管理コンピュータ１における予め定めら
れた基準に従った判断に基づいて取引を取り消す場合に
は、取り消すべき取引の状態を“ＡＣＴＩＶＥ”から
“ＡＢＯＲＴＩＮＧ”に変更した後に、ショップコンピ
ュータ２にＡＢＯＲＴメッセージを送り、該当する取引
の取り消しが完了したショップコンピュータ２からＡＢ
ＯＲＴＥＤメッセージが返ってきたら、該取引の状態を
“ＡＢＯＲＴＥＤ”にする。一括取消の場合には、一括
処理対象となっている全ての取引の状態が“ＡＢＯＲＴ
ＥＤ”に変更されたならば一括取消は完了となる。

【０１４６】さて、取引情報データベース１３から状態
フィールドの値が“ＡＣＴＩＶＥ”になっている取引情
報を検索したトランザクション管理コンピュータ１は、
まず、それら一括処理の対象となる取引情報の状態フィ
ールドの値を“ＡＣＴＩＶＥ”から“ＣＯＭＩＴＴＩＮ
Ｇ”に変更するとともに、決済日時フィールドに現在の
日時を記録し（図３１の［６０］）、それら取引の相手
となる各々のショップコンピュータ２に対して、その取
引の取引ＩＤを持たせたＣＯＭＭＩＴメッセージを送っ
て、該当する取引についての手続きを完結させること
（すなわち、該当する取引の成立を確定させるための処
理の実行）を指示する（図３１の［６１］、［６
２］）。前述と同様に、このとき、本実施形態では、Ｃ
ＯＭＭＩＴメッセージには、必要な利用者の個人情報を
一緒に持たせて送るように実施するものとする。

【０１４７】ＣＯＭＭＩＴメッセージを受け取ったショ
ップコンピュータ２の各々は、メッセージに指定されて
いる取引ＩＤの取引の情報をそのデータベースの中から
検索し、ＣＯＭＭＩＴメッセージと一緒に送られてきた
利用者の個人情報を使って、当該取引の成立を確定させ
るために当該サイトにおいて必要な処理を行う（図３１
の［６３］、［６４］）。この処理が終われば、トラン
ザクション管理コンピュータ１に対して、取引ＩＤを持
たせたＣＯＭＭＩＴＴＥＤメッセージを送り返す（図３
１の［６５］、［６６］）。このとき、本実施形態で
は、ＣＯＭＭＩＴＴＥＤメッセージに、完了メッセージ
を一緒に持たせて送るように実施する。

【０１４８】ＣＯＭＭＩＴＴＥＤメッセージを受け取っ
たトランザクション管理コンピュータ１は、該当する取
引情報の状態を“ＣＯＭＭＩＴＴＩＮＧ”から“ＣＯＭ
ＭＩＴＥＤ”に変更するとともに、決済日時フィールド
に現在の日時を記録する（図３１の［６７］）。このと
き、ＣＯＭＭＩＴＴＥＤメッセージと一緒に送られてき
た完了メッセージを、取引情報データベース１３中の該
当する取引の完了メッセージフィールドに記録してお
く。一括処理対象のすべての取引の状態が“ＣＯＭＭＩ
ＴＴＥＤ”になれば、すべての手続きが完了したので、
利用者への完了通知ページを送り返す（図３１の［６
８］）。

【０１４９】そして、前述と同様に、この完了通知メッ
セージが埋め込まれた完了通知ページを受け取った利用
者のクライアントコンピュータ３では、それをＷＥＢブ
ラウザに表示すると、例えば図３０のような情報が表示
される。

【０１５０】これまでに説明した実施形態では、トラン
ザクション管理サービスを利用して、電子店舗サービス
を受ける利用者は、ＷＥＢブラウザを使って、ショップ
コンピュータ２とトランザクション管理コンピュータ１
とに交互に接続し、すなわち、交互に表示された電子店
舗のページ画面とショッピングカートのページ画面で閲
覧や入力や指示を行って、取引のための手続きを続ける
ように実施していたが、図３３に示すように、ショップ
コンピュータ２に接続したショッピング用のウィンドウ
と、トランザクション管理コンピュータ１に接続したシ
ョッピングカート用のウィンドウとを、ディスプレイの
画面上に同時に表示して、取引のための手続きを進める
ことができるように実施することも可能である。このよ
うに実施すると、常に現在のショッピングカートの内容
が見えており、保留中の取引について成立または不成立
を確定させることをせずに忘れてしまうことも防ぐこと
ができて便利である。

【０１５１】本実施形態では、トランザクション管理コ
ンピュータ１の取引情報データベース１３には、そのシ
ョッピングカートを介して過去に成立した取引の情報を
も記録するようにしている。利用者は、トランザクショ
ン管理コンピュータ１に接続することによって、自分の
過去の取引の履歴を閲覧することができるように実施す
ると、トランザクション管理コンピュータ１は個人用の
取引履歴の記録として利用することができる。この機能
は、例えば図２５のような個人用のショッピングカート
ページにおいて、『今月（１９９９年１２月）分』ボタ
ンを押すと、図３４に示すように、その月の取引の履歴
が表示されるように実施することができる。さらに、図
３４の例で、例えば１２月１７日の『ＲＡＰＴＯＲギフ
ト』の情報をマウス等のポインティングデバイスでクリ
ックすると、その取引を行ったＲＡＰＴＯＲギフトのシ
ョップコンピュータ２に接続して、その取引に関するよ
り詳しい情報（例えば、配送の状況など）を照会するこ
とができるように実施することもできる。

【０１５２】トランザクション管理コンピュータ１の持
つ取引情報データベース１３は、データベース管理シス
テムで管理されている永続的（パーマネント）なデータ
であるので、クライアントコンピュータ３やショップコ
ンピュータ２に障害が発生しても影響を受けない。その
ため、取引の途中でクライアントコンピュータ３に障害
が発生し、クライアントコンピュータ３を再起動した
り、あるいは別のクライアントコンピュータ３を使う場
合や、ショップコンピュータ２かネットワークに障害が
発生して、クライアントコンピュータ３からのリクエス
トに答えなくなった場合など、取引の途中で障害に遭遇
した利用者は、トランザクション管理コンピュータ１に
再接続することで、取引を継続することができる。

【０１５３】例えば、図４と図１５に示すような取引を
行った後、図２６に示す一括処理の手続きの開始を指示
する前に(例えば、送信された図２５のページを受信す
る前に、あるいは受信した該ページを表示する前に、あ
るいは表示された該ページにおいて利用者により『一括
決済ボタン』が押される前に)、クライアントコンピュ
ータ３に障害が発生した場合、利用者は、クライアント
コンピュータ３を再起動してトランザクション管理コン
ピュータ１に接続し、客ＩＤの認証が終わると、例えば
図２５と同じ状態でショッピングカートページが表示さ
れる。ここには、クライアントコンピュータ３に障害が
発生する前に進めていた取引の情報が有効に残っており
（トランザクション管理コンピュータ１の取引情報デー
タベース１３中に“ＡＣＴＩＶＥ”状態で有効に登録さ
れており）、引き続きこのページから手続きを続ける
(例えば、『一括決済ボタン』を押す)ことができる。

【０１５４】ここで、例えばクライアントコンピュータ
３の修理が必要で数日たってからトランザクション管理
コンピュータ１に再接続したような場合には、進行中の
取引は長時間放置されることになり、問題が生じる。そ
こで、成立確定前の取引がショッピングカート中に一定
時間以上放置されている場合には、該取引をトランザク
ション管理コンピュータ１によって強制的に取り消させ
るように実施することもできる。このような場合、再接
続したクライアントコンピュータ３には例えば図３５に
示すように取引が取り消された旨が通知されるように実
施することができる。

【０１５５】利用者がショッピングカート内に保留した
全部または一部の取引について最終的に取引の成立また
は不成立を確定させるために例えば『一括決済ボタン』
あるいは『個別決済ボタン』あるいは『一括取消ボタ
ン』あるいは『個別取消ボタン』を押すなどして、クラ
イアントコンピュータ３からトランザクション管理コン
ピュータ１に対し要求が出された後に、トランザクショ
ン管理コンピュータ１から最終的な結果を受け取る前に
クライアントコンピュータ３に障害が発生した場合も、
同様に再接続して、最終的な結果を確認することができ
る。この場合、トランザクション管理コンピュータ１
は、利用者が一括処理要求等の指示を出したことを取引
情報データベース１３の状態として記録しているので、
クライアントコンピュータ３の状況にかかわらず、独自
に処理を進めてよい。このとき、完了メッセージは取引
情報データベース１３に保存される。そして、クライア
ントコンピュータ３に障害が発生したために、この時点
では完了通知ページをクライアントコンピュータ３に送
り返せなかったとしても、クライアントコンピュータ３
がトランザクション管理コンピュータ１へ再接続した後
に、完了メッセージを含む完了通知ページを利用者に送
信して、結果を通知することが可能になる。

【０１５６】以下では、本実施形態のトランザクション
管理コンピュータ１上で動作するトランザクション管理
プログラム１１の動作の例をフローチャートを使って説
明する。

【０１５７】トランザクション管理プログラム１１の動
作は、大きく、 （１）クライアントコンピュータ３からのショッピング
カートページ要求に対する処理 （２）クライアントコンピュータ３からの一括処理要求
に対する処理 （３）クライアントコンピュータ３からの取り消し要求
に対する処理 （４）障害回復処理 の４つからなる。

【０１５８】（１）クライアントコンピュータ３からの
ショッピングカートページ要求に対する処理 利用者がクライアントコンピュータ３からトランザクシ
ョン管理コンピュータ１へ接続してショッピングカート
ページを要求した場合の処理の流れは、図３６のように
なる。

【０１５９】まず、既に認証されている利用者からの接
続であるかどうかを調べ（図３６のステップＳ１）、ま
だ認証していなければ利用者に客ＩＤとパスワードを入
力させて認証する（図３６のステップＳ２）。

【０１６０】次に、接続リクエストが店ＩＤと取引ＩＤ
を持っているかどうかを調べる（図３６のステップＳ
３）。クライアントコンピュータ３がトランザクション
管理コンピュータ１にショッピングカートページを要求
するのは、ショップコンピュータ２からリダイレクトさ
れてきた場合と、障害後や過去の取引履歴閲覧のために
自発的に再接続してきた場合とに分けられる。前者の場
合には、店ＩＤと取引ＩＤを持っているので、それを使
って取引情報データベース１３を検索し、見つかった取
引情報の客ＩＤフィールドに、認証した客ＩＤを記録す
る（図３６のステップＳ４）。

【０１６１】その後、認証した客ＩＤを使って、その利
用者の取引情報を取引情報データベース１３から検索
し、その利用者個人用のショッピングカートページを作
成し（図３６のステップＳ５）、それをクライアントコ
ンピュータ３に送り返す（図３６のステップＳ６）。

【０１６２】このように処理することによって、ショッ
プコンピュータ２からリダイレクトされてきた場合で
も、自発的に再接続してきた場合でも、常に最新のショ
ッピングカートの情報を利用者に提示することが可能に
なる。

【０１６３】（２）クライアントコンピュータ３からの
一括処理要求に対する処理 利用者がクライアントコンピュータ３からトランザクシ
ョン管理コンピュータ１へ接続してショッピングカート
中の取引について一括処理を要求した場合（例えば、
『一括決済ボタン』を押した場合）の処理の流れは、図
３７のようになる。このときも必要に応じて認証を行う
が、ここでは既に認証されているものとして省略してい
る。

【０１６４】まず、取引情報データベース１３におい
て、利用者によって一括処理することを指定されたすべ
ての取引の状態を“ＰＲＥＰＡＲＩＮＧ”に変更すると
ともに、現在の日時を決済日時フィールドに記録する
（図３７のステップＳ１１）。

【０１６５】次に、一括処理することを指定されたすべ
ての取引について、その取引の相手となるショップコン
ピュータ２に、取引ＩＤを指定したＰＲＥＰＡＲＥメッ
セージを送る（図３７のステップＳ１２）。ＰＲＥＰＡ
ＲＥメッセージに対して、ＰＲＥＣＯＭＭＩＴメッセー
ジを返してきたら、その取引の状態は“ＰＲＥＣＯＭＭ
ＩＴＴＥＤ”に、ＡＢＯＲＴＥＤメッセージを返してき
たらその取引の状態は“ＡＢＯＲＴＥＤ”に変更し、す
べてのＰＲＥＰＡＲＥメッセージの返答が返ってくるま
で待つ（図３７のステップＳ１３）。

【０１６６】すべてのＰＲＥＰＡＲＥメッセージの返答
が返ってきて、その中にＡＢＯＲＴメッセージがあって
“ＡＢＯＲＴＥＤ”状態になった取引があった場合に
は、ステップＳ１８に進んですべての取引を取り消すた
めの処理を行い、そうでない場合にはステップＳ１５に
進んですべての取引の成立を確定させるための処理を行
う（図３７のステップＳ１４）。

【０１６７】取引の成立を確定させるための処理は、ま
ず、一括処理することを指定されたすべての取引の状態
をＣＯＭＩＴＴＩＮＧに変更するとともに、現在の日時
を決済日時に記録する（図３７のステップＳ１５）。次
に、一括処理することを指定されたすべての取引につい
て、その取引の相手となるショップコンピュータ２に対
して、取引ＩＤを指定したＣＯＭＭＩＴメッセージを送
る（図３７のステップＳ１６）。ＣＯＭＭＩＴメッセー
ジの返答が返ってきた取引の状態を“ＣＯＭＩＴＴＥ
Ｄ”に変更するとともに、現在の日時を決済日時フィー
ルドに記録し、すべてのＣＯＭＭＩＴメッセージの返答
が返ってくるまで待つ（図３７のステップＳ１７）。

【０１６８】取引を取り消すための処理は、まず、取り
消すことを指定された取引で“ＰＲＥＣＯＭＭＩＴＴＥ
Ｄ”状態のものを“ＡＢＯＲＴＩＮＧ”状態に変更する
とともに、現在の日時を決済日時に記録する（図３７の
ステップＳ１８）。次に、“ＡＢＯＲＴＩＮＧ”状態に
変更したすべての取引について、その取引の相手となる
ショップコンピュータ２に対して、取引ＩＤを指定した
ＡＢＯＲＴメッセージを送る（図３７のステップＳ１
９）。ＡＢＯＲＴメッセージの返答が返ってきた取引の
状態を“ＡＢＯＲＴＥＤ”に変更するとともに、現在の
日時を決済日時フィールドに記録し、すべてのＡＢＯＲ
Ｔメッセージの返答が返ってくるまで待つ（図３７のス
テップＳ２０）。

【０１６９】なお、以上の各待ち状態において、必要な
全ての返答が返ってくればその処理は完了となるが、返
答が返ってこないものについては、後述する障害回復処
理を行って、その処理の完了を試みるようにする（この
点は、以下の各待ち状態においても同様である）。

【０１７０】（３）クライアントコンピュータ３からの
取り消し要求に対する処理 利用者がクライアントコンピュータ３からトランザクシ
ョン管理コンピュータ１へ接続してショッピングカート
中の取引の取り消しを要求した場合（例えば、『一括取
消ボタン』を押した場合）の処理の流れは、図３８のよ
うになる。このときも必要に応じて認証を行うが、ここ
では既に認証されているものとして省略している。

【０１７１】取引を取り消すための処理は、まず、取り
消すことを指定されたすべての取引の状態を“ＡＢＯＲ
ＴＩＮＧ”に変更するとともに、現在の日時を決済日時
に記録する（図３８のステップＳ２１）。次に、取り消
すことを指定されたすべての取引について、その取引の
相手となるショップコンピュータ２に対して、取引ＩＤ
を指定したＡＢＯＲＴメッセージを送る（図３８のステ
ップＳ２２）。ＡＢＯＲＴメッセージの返答が返ってき
た取引の状態を“ＡＢＯＲＴＥＤに変更するとともに、
現在の日時を決済日時フィールドに記録し、すべてのＡ
ＢＯＲＴメッセージの返答が返ってくるまで待つ（図３
８のステップＳ２３）。

【０１７２】（４）障害回復処理 本実施形態では、トランザクション管理コンピュータ１
は、ショップコンピュータ２の障害やネットワークの障
害に対処するために、常に、取引情報データベース１３
を監視して、必要な障害回復処理を行う。

【０１７３】取引情報データベース１３中の取引情報
で、ある許容時間以上、“ＡＣＴＩＶＥ”状態あるいは
“ＰＲＥＰＡＲＩＮＧ”状態あるいは“ＣＯＭＩＴＴＩ
ＮＧ”状態あるいは“ＡＢＯＲＴＩＮＧ”状態にあるも
のは、障害が発生している可能性があるので、図３９に
示した手順で障害回復処理を行う。

【０１７４】ある許容時間以上経過しているかどうか
は、取引情報データベース１３の状態を変更した時刻を
決済日時フィールドに記録しているので、その日時と現
在の日時とを比較することで判断できる。

【０１７５】まず、取引の状態が“ＰＲＥＰＡＲＩＮ
Ｇ”である場合は（図３９のステップＳ３１）、ＰＲＥ
ＰＡＲＥメッセージの返答が返ってきていないので、該
当する取引を行ったショップコンピュータ２に、取引Ｉ
Ｄを指定したＰＲＥＰＡＲＥメッセージを再送するとと
もに、現在の日時を決済日時に記録する（図３９のステ
ップＳ３２）。

【０１７６】取引の状態が“ＣＯＭＩＴＴＩＮＧ”であ
る場合は（図３９のステップＳ３３）、ＣＯＭＭＩＴメ
ッセージの返答が返ってきていないので、該当する取引
を行ったショップコンピュータ２に、取引ＩＤを指定し
たＣＯＭＭＩＴメッセージを再送するとともに、現在の
日時を決済日時に記録する（図３９のステップＳ３
４）。

【０１７７】取引の状態が“ＡＢＯＲＴＩＮＧ”である
場合は（図３９のステップＳ３５）、ＡＢＯＲＴメッセ
ージの返答が返ってきていないので、該当する取引を行
ったショップコンピュータ２に、取引ＩＤを指定したＡ
ＢＯＲＴメッセージを再送するとともに、現在の日時を
決済日時に記録する（図３９のステップＳ３６）。

【０１７８】なお、１回あるいは規定回数、再送を行っ
た場合に、利用者へ、そのクライアントコンピュータ３
のＷＥＢブラウザを介して、単に再送している旨あるい
は再送している電子店舗の名称等などを通知するように
してもよい。

【０１７９】取引の状態が“ＡＣＴＩＶＥ”である場合
は（図３９のステップＳ３７）、同じ客ＩＤを持つ他の
“ＡＣＴＩＶＥ”状態の取引も、許容時間以上、状態が
変化せずに経過しているかどうかを調べる（図３９のス
テップＳ３８）。これは、利用者が複数の取引をショッ
ピングカート内に保留している場合に、最初の方にカー
トに入れた取引は“ＡＣＴＩＶＥ”になってから時間が
経っているが、直前にカートに入れた取引はまだ“ＡＣ
ＴＩＶＥ”になったばかりであるようなときに、最初の
方の取引に引きずられて全体が取り消されないためのチ
ェックである。

【０１８０】同じ客ＩＤを持つすべての“ＡＣＴＩＶ
Ｅ”状態の取引が許容時間以上経っている場合には、利
用者は取引を成立させる意思がないものとみなして、ス
テップＳ３９に進んで、強制的にそれらの取引を取り消
すための処理を行う。

【０１８１】強制的に取引を取り消すための処理は、ま
ず、同じ客ＩＤを持つすべての“ＡＣＴＩＶＥ”状態の
取引を“ＡＢＯＲＴＩＮＧ”に変更するとともに、現在
の日時を決済日時フィールドに記録する（図３９のステ
ップＳ３９）。

【０１８２】次に、状態を“ＡＢＯＲＴＩＮＧ”に変更
したすべての取引について、その取引を行ったショップ
コンピュータ２に対して、取引ＩＤを指定したＡＢＯＲ
Ｔメッセージを送る（図３９のステップＳ４０）。

【０１８３】最後に、ＡＢＯＲＴメッセージの返答が返
ってきた取引の状態を“ＡＢＯＲＴＥＤ”に変更すると
ともに、現在の日時を決済日時フィールドに記録し、す
べてのＡＢＯＲＴメッセージの返答が返るまで待つ（図
３９のステップＳ４１）。

【０１８４】なお、上記の各メッセージを再送しても返
答が返ってこない状態が続いている場合において、メッ
セージを規定回数以上再送した条件、あるいは最初にメ
ッセージを送信してから規定時間が経過した条件、ある
いは当該取引が登録されてから“ＡＣＴＩＶＥ”状態の
許容時間に等しい時間が経過した条件などの所定の条件
が成立したならば、障害が発生したものと判断して、強
制的にそれらの取引を取り消すための処理を行うように
してもよい。

【０１８５】障害回復処理の開始を判断するために使う
許容時間は、さまざまに設定することができる。一つの
方法は、あらかじめ決まっている時間（例えば、５分、
３時間、１日など）を許容時間とするように実施する方
式である。許容時間は、例えば、“ＡＣＴＩＶＥ”状態
の許容時間は１時間で、“ＰＲＥＰＡＲＩＮＧ”状態や
“ＣＯＭＩＴＴＩＮＧ”状態や“ＡＢＯＲＴＩＮＧ”状
態の許容時間は１２０秒という具合に、取引の状態によ
って異なるように設定してもよい。

【０１８６】また、別の方式としては、利用者の過去の
取引履歴などを参考にして、例えば頻繁に利用する利用
者は許容時間が長くなるように、許容時間を決めるよう
に実施することができる。

【０１８７】さらに別の方式としては、ショップコンピ
ュータ２が取引をトランザクション管理コンピュータ１
に登録する際に、希望の許容時間（例えば、この取引内
容は２時間は有効という具合に）を登録するようにし、
トランザクション管理コンピュータ１は、すべての取引
に対して、それぞれの許容時間を守るように実施するこ
とができる。

【０１８８】状態が“ＡＣＴＩＶＥ”の取引が許容時間
を超える前に、トランザクション管理コンピュータ１
は、その取引に係る利用者に対して、早く取引の成立ま
たは不成立を確定させさせるように警告を送るように実
施することもできる。警告の手段としては、利用者がシ
ョッピングカートページを要求してきたときに、ショッ
ピングカートページ中に警告メッセージを入れるように
実施することができる。また、直接、利用者に電子メー
ルで警告通知を送ったり、あるいは電話で警告の案内を
通知するように実施することもできる。

【０１８９】また、予めショッピングカートページに、
許容時間などを提示して、利用者の注意を喚起するよう
にしておいてもよい。

【０１９０】本実施形態では、状態が“ＰＲＥＰＡＲＩ
ＮＧ”や“ＣＯＭＩＴＴＩＮＧ”や“ＡＢＯＲＴＩＮ
Ｇ”のときに、ショップコンピュータ２の側で障害の発
生を認識した場合であっても、トランザクション管理コ
ンピュータ１の側で許容時間でタイムアウトしてメッセ
ージの再送が起こるまで待つように実施しているが、シ
ョップコンピュータ２の側からトランザクション管理コ
ンピュータ１に催促メッセージを送るように実施するこ
ともできる。このとき、催促メッセージを受け取ったト
ランザクション管理コンピュータ１は、該当する取引に
関して直前に送ったメッセージを再送する。

【０１９１】障害回復処理によって、この一括処理の途
中でネットワーク障害などが起こっても、トランザクシ
ョン管理コンピュータ１が障害回復処理を行うので、利
用者にとっては安心して一括処理ができる。また、利用
者がショッピングカート内に取引を保留しているにもか
かわらず途中で操作を放棄してしまっても、トランザク
ション管理コンピュータ１がそれを強制的に取り消す処
理を行うので、電子店舗も取引のための手続き（特に、
ショッピングカート内に保留されている取引に係る商品
や予約の一定時間の仮の確保）を安心して行うことがで
きる。

【０１９２】以下では、本実施形態のショップコンピュ
ータ２上で動作する電子店舗プログラムの動作の例をフ
ローチャートを使って説明する。

【０１９３】電子店舗プログラムの動作は、大きく、 （１）クライアントコンピュータ３からのＴＭＳ登録要
求に対する処理 （２）トランザクション管理コンピュータ１からのＰＲ
ＥＰＡＲＥ処理要求に対する処理 （３）トランザクション管理コンピュータ１からのＣＯ
ＭＭＩＴ処理要求に対する処理 （４）トランザクション管理コンピュータ１からのＡＢ
ＯＲＴ処理要求に対する処理 の４つからなる。

【０１９４】（１）クライアントコンピュータ３からの
ＴＭＳ登録要求に対する処理利用者のクライアントコン
ピュータ３から、現在進行している取引について、トラ
ンザクション管理コンピュータ１を利用して、手続きを
続行させたい旨の要求がなされた場合（例えば、利用者
が『ＴＭＳで予約するボタン』あるいは『ＴＭＳで支払
いボタン』を押した場合）、ショップコンピュータ２
は、図４０の手順でトランザクション管理コンピュータ
１に取引を登録する。

【０１９５】まず、現在の取引に対して取引ＩＤを発行
し、取引内容と取引ＩＤを一緒にして、ショップコンピ
ュータ２の管理するデータベースに格納する（図４０の
ステップＳ５１）。

【０１９６】次に、トランザクション管理コンピュータ
１からその電子店舗に対して与えられている店ＩＤと取
引ＩＤの組を、トランザクション管理コンピュータ１に
送って登録する（図４０のステップＳ５２）。

【０１９７】最後に、クライアントコンピュータ３に対
して、店ＩＤと取引ＩＤの組を持ってトランザクション
管理コンピュータ１に接続してショッピングカートペー
ジを要求するように指示する（図４０のステップＳ５
３）。

【０１９８】本実施形態では、ＨＴＴＰプロトコルのリ
ダイレクション機能を使って、トランザクション管理コ
ンピュータ１への接続をクライアントコンピュータ３に
指示するように実施している。他の方式を使って実施す
ることも可能である。

【０１９９】トランザクション管理コンピュータ１を利
用するためには（ショッピングカートを利用するために
は）、客ＩＤと店ＩＤと取引ＩＤの組からなる取引情報
がトランザクション管理コンピュータ１の取引情報デー
タベース１３に入ればよい。そのため、例えば、ショッ
プコンピュータ２が客ＩＤの認証も行って、客ＩＤと店
ＩＤと取引ＩＤの組を直接トランザクション管理コンピ
ュータ１に登録するように実施することもできる。

【０２００】（２）トランザクション管理コンピュータ
１からのＰＲＥＰＡＲＥ処理要求に対する処理 ショップコンピュータ２がトランザクション管理コンピ
ュータ１からのＰＲＥＰＡＲＥメッセージを受け取った
場合、図４１の手順で処理を行う。

【０２０１】まず、ＰＲＥＰＡＲＥメッセージに指定さ
れている取引ＩＤを使ってデータベースを検索し、該当
する取引のための手続きが完結可能（すなわち、取引を
成立させることが可能）かどうかを調べる（図４１のス
テップＳ６１）。完結可能であれば（図４１のステップ
Ｓ６２）、ＰＲＥＣＯＭＭＩＴＴメッセージを送り返す
（図４１のステップＳ６３）。ＰＲＥＣＯＭＭＩＴＴメ
ッセージを送り返す前に、必要に応じて完結可能である
ことを保証するために、必要な処理（例えばメモリー上
にある取引に関するデータを磁気ディスクに記録して、
その後の障害によって取引に関するデータがなくならな
いようにする処理など）をするようにしてもよい）。何
らかの要因によって該当する取引のための手続きが完結
不可能（すなわち、取引を成立させることが不可能）と
なった場合には、指定された取引ＩＤに関する情報がデ
ータベースに残っていれば取り消して（図４１のステッ
プＳ６４）、ＡＢＯＲＴＥＤメッセージを送り返す（図
４１のステップＳ６５）。

【０２０２】（３）トランザクション管理コンピュータ
１からのＣＯＭＭＩＴ処理要求に対する処理 ショップコンピュータ２がトランザクション管理コンピ
ュータ１からのＣＯＭＭＩＴメッセージを受け取った場
合、図４２の手順で処理を行う。

【０２０３】まず、ＣＯＭＭＩＴメッセージに指定され
ている取引ＩＤを使ってデータベースを検索し、該当す
る取引のための手続きが完結可能かどうかを調べる（図
４２のステップＳ７１）。完結可能であれば（図４２の
ステップＳ７２）、ＣＯＭＭＩＴメッセージに含まれて
いる利用者の個人情報を使って、該当する取引の成立を
確定させるために必要な処理を行い（図４２のステップ
Ｓ７３）、ＣＯＭＭＩＴＴＥＤメッセージを送り返す
（図４２のステップＳ７４）。このとき、手続き完了し
たことを利用者に知らせるための完了メッセージを一緒
に送り返す。何らかの要因によって該当する取引のため
の手続きが完結不可能となった場合には、指定された取
引ＩＤに関する情報がデータベースに残っていれば取り
消して（図４２のステップＳ７５）、ＡＢＯＲＴＥＤメ
ッセージを送り返す（図４２のステップＳ７６）。

【０２０４】（４）トランザクション管理コンピュータ
１からのＡＢＯＲＴ処理要求に対する処理 ショップコンピュータ２がトランザクション管理コンピ
ュータ１からのＡＢＯＲＴメッセージを受け取った場
合、図４３の手順で処理を行う。

【０２０５】まず、ＡＢＯＲＴメッセージに指定された
取引ＩＤに関する情報がデータベースに残っていれば取
り消して（図４３のステップＳ８１）、ＡＢＯＲＴＥＤ
メッセージを送り返す（図４３のステップＳ８２）。

【０２０６】トランザクション管理コンピュータ１上の
トランザクション管理プログラム１１の障害回復処理で
は、ＰＲＥＰＡＲＥメッセージやＣＯＭＭＩＴメッセー
ジやＡＢＯＲＴメッセージに対する返答が返ってこない
場合には、それらのメッセージがネットワーク上で失わ
れた可能性があるので、メッセージを再送することで障
害回復を行う。そのため、ショップコンピュータ２上の
電子店舗プログラムは、トランザクション管理コンピュ
ータ１からＰＲＥＰＡＲＥメッセージやＣＯＭＭＩＴメ
ッセージやＡＢＯＲＴメッセージが複数回重複して送ら
れてくる場合を想定しておく必要がある。すなわち、既
にメッセージを受け取って返答を返していても、その返
答がネットワーク上で失われると、トランザクション管
理コンピュータ１はメッセージを再送してくる。このと
き、先に送った返答と同じ返答を送り返すように実施し
ておく。

【０２０７】なお、以上の各機能は、ソフトウェアとし
ても実現可能である。

【０２０８】また、本実施形態は、コンピュータに所定
の手段を実行させるための（あるいはコンピュータを所
定の手段として機能させるための、あるいはコンピュー
タに所定の機能を実現させるための）プログラムを記録
したコンピュータ読取り可能な記録媒体としても実施す
ることもできる。

【０２０９】本発明は、上述した実施の形態に限定され
るものではなく、その技術的範囲において種々変形して
実施することができる。

【０２１０】

【発明の効果】本発明によれば、トランザクション管理
コンピュータが、利用者と電子店舗との取引を管理する
ので、障害の検出や障害からの回復や対処が可能にな
る。また、本発明によれば、トランザクション管理コン
ピュータが、利用者と電子店舗との取引を管理するの
で、複数の電子店舗を越えたグローバルなショッピング
カートが実現できる。本発明によれば、トランザクショ
ン管理コンピュータが、利用者と電子店舗との取引を管
理するので、複数の電子店舗に跨って過去の取引履歴を
一元的に管理することができる。

【図面の簡単な説明】

【図１】本発明の一実施形態に係る電子商取引システム
の構成例を示す図

【図２】同実施形態に係るトランザクション管理コンピ
ュータの構成例を示す図

【図３】同実施形態に係る電子商取引システムの動作例
を示す図

【図４】同実施形態に係る電子商取引システムにおける
動作手順の一例を示す図

【図５】クライアントコンピュータの表示画面に表示さ
れたショップコンピュータのホームページの一例を示す
図

【図６】クライアントコンピュータの表示画面に表示さ
れたショップコンピュータの予約ページの一例を示す図

【図７】図６の画面で入力がなされた様子を示す図

【図８】クライアントコンピュータの表示画面に表示さ
れたショップコンピュータの予約確認ページの一例を示
す図

【図９】取引情報データベースの一例を示す図

【図１０】クライアントコンピュータの表示画面に表示
されたトランザクション管理コンピュータのユーザ認証
確認ページの一例を示す図

【図１１】図１０の画面で入力がなされた様子を示す図

【図１２】個人情報データベースの一例を示す図

【図１３】取引情報データベースの一例を示す図

【図１４】クライアントコンピュータの表示画面に表示
されたトランザクション管理コンピュータのショッピン
グカートページの一例を示す図

【図１５】同実施形態に係る電子商取引システムにおけ
る動作手順の他の例を示す図

【図１６】クライアントコンピュータの表示画面に表示
された他のショップコンピュータの予約入力ページの一
例を示す図

【図１７】図１６の画面で入力がなされた様子の一例を
示す図

【図１８】クライアントコンピュータの表示画面に表示
された他のショップコンピュータの空席状況ページの一
例を示す図

【図１９】クライアントコンピュータの表示画面に表示
された他のショップコンピュータの予約確認ページの他
の例を示す図

【図２０】クライアントコンピュータの表示画面に表示
された他のショップコンピュータの予約入力ページの他
の例を示す図

【図２１】図１６の画面で入力がなされた様子の他の例
を示す図

【図２２】クライアントコンピュータの表示画面に表示
された他のショップコンピュータの空席状況ページの他
の例を示す図

【図２３】クライアントコンピュータの表示画面に表示
された他のショップコンピュータの予約確認ページの他
の例を示す図

【図２４】取引情報データベースの一例を示す図

【図２５】クライアントコンピュータの表示画面に表示
されたトランザクション管理コンピュータのショッピン
グカートページの他の例を示す図

【図２６】同実施形態に係る電子商取引システムにおけ
る動作手順のさらに他の例を示す図

【図２７】同実施形態に係るトランザクション管理コン
ピュータのトランザクション管理プログラムが管理する
取引の状態遷移の一例を示す図

【図２８】取引情報データベースの一例を示す図

【図２９】取引情報データベースの一例を示す図

【図３０】クライアントコンピュータの表示画面に表示
されたトランザクション管理コンピュータのショッピン
グカートページのさらに他の例を示す図

【図３１】同実施形態に係る電子商取引システムにおけ
る動作手順のさらに他の例を示す図

【図３２】同実施形態に係るトランザクション管理コン
ピュータのトランザクション管理プログラムが管理する
取引の状態遷移の他の例を示す図

【図３３】クライアントコンピュータの表示画面にショ
ップコンピュータのページとトランザクション管理コン
ピュータのページとを併せて表示した様子の一例を示す
図

【図３４】クライアントコンピュータの表示画面に表示
されたトランザクション管理コンピュータのショッピン
グカートページのさらに他の例を示す図

【図３５】クライアントコンピュータの表示画面に表示
されたトランザクション管理コンピュータのショッピン
グカートページのさらに他の例を示す図

【図３６】同実施形態に係るトランザクション管理コン
ピュータのトランザクション管理プログラムにおけるク
ライアントコンピュータからのショッピングカートペー
ジ要求に対する処理手順の一例を示すフローチャート

【図３７】同実施形態に係るトランザクション管理コン
ピュータのトランザクション管理プログラムにおけるク
ライアントコンピュータからの一括処理要求に対する一
括処理手順の一例を示すフローチャート

【図３８】同実施形態に係るトランザクション管理コン
ピュータのトランザクション管理プログラムにおけるク
ライアントコンピュータからの取り消し要求に対する処
理手順の一例を示すフローチャート

【図３９】同実施形態に係るトランザクション管理コン
ピュータのトランザクション管理プログラムにおける障
害回復処理の手順の一例を示すフローチャート

【図４０】同実施形態に係るショップコンピュータの電
子店舗プログラムにおけるクライアントコンピュータか
らのＴＭＳ登録要求に対する処理手順の一例を示すフロ
ーチャート

【図４１】同実施形態に係るショップコンピュータの電
子店舗プログラムにおけるトランザクション管理コンピ
ュータからのＰＲＥＰＡＲＥ処理要求に対する処理手順
の一例を示すフローチャート

【図４２】同実施形態に係るショップコンピュータの電
子店舗プログラムにおけるトランザクション管理コンピ
ュータからのＣＯＭＭＩＴ処理要求に対する処理手順の
一例を示すフローチャート

【図４３】同実施形態に係るショップコンピュータの電
子店舗プログラムにおけるトランザクション管理コンピ
ュータからのＡＢＯＲＴ処理要求に対する処理手順の一
例を示すフローチャート

【符号の説明】

１…トランザクション管理コンピュータ ２…ショップコンピュータ ３…クライアントコンピュータ ６…インターネット １１…トランザクション管理プログラム １２…個人情報データベース １３…取引情報データベース

Claims (20)

【特許請求の範囲】
1. 【請求項１】ネットワーク上で電子店舗を提供する複数
   のショップコンピュータ及び電子店舗を利用する利用者
   の使用する複数のクライアントコンピュータと通信する
   ための通信手段と、 少なくともいずれかの前記電子店舗といずれかの前記利
   用者との間で進行中の取引について、該取引を特定する
   ための第１の情報と、該取引に係る利用者を識別するた
   めの第２の情報と、該取引に係る電子店舗を識別するた
   めの第３の情報と、該取引の状態が、少なくとも、取引
   の成立又は不成立を確定させるための指示を待っている
   第１の状態、取引の成立を確定させるための指示を受け
   て取引の成立を確定させるための処理を開始したが該処
   理が未だ完了していない第２の状態、取引の成立を確定
   させるための処理が完了した第３の状態、取引の不成立
   が確定している第４の状態のいずれであるかを区別する
   ための第４の情報との組を含む取引情報を、管理するた
   めの管理手段とを備えたことを特徴とするトランザクシ
   ョン管理装置。
2. 【請求項２】前記管理手段に管理されている第１の状態
   にある複数の取引情報に係る取引の成立又は不成立を一
   括して確定させるべき旨の指示を前記クライアントコン
   ピュータから受信した場合に、該当するショップコンピ
   ュータとの間で所定の手続きを行って、該複数の取引の
   成立を一括して確定させ又は該複数の取引の不成立を一
   括して確定させることのいずれかを行う一括処理手段を
   更に備えたことを特徴とする請求項１に記載のトランザ
   クション管理装置。
3. 【請求項３】前記一括処理手段は、前記クライアントコ
   ンピュータから前記管理手段に管理されている第１の状
   態を持つ複数の取引情報に係る取引の成立を一括して確
   定させるべき旨の指示を受信した場合には、該指示され
   た複数の取引の各々について、該当する各々のショップ
   コンピュータへ当該取引の成立を確定させるための手続
   きが完結可能であるか否かを問い合わせ、指示された複
   数の取引の全てについて完結可能であることが確認され
   たならば、該当する各々のショップコンピュータへ当該
   取引の成立を確定させるための手続きを完結させること
   を指示し、前記クライアントコンピュータから指示され
   た複数の取引のうちに１つでも完結不可能となるものが
   あることが確認されたならば、該指示された複数の取引
   の全てについて、該当する各々のショップコンピュータ
   へ当該取引を取り消すべきことを指示することを特徴と
   する請求項２に記載のトランザクション管理装置。
4. 【請求項４】前記一括処理手段は、前記ショップコンピ
   ュータへ取引の成立を確定させるための手続きを完結さ
   せることを指示する際に、該取引に係る利用者に関する
   個人情報を併せて通知することを特徴とする請求項３に
   記載のトランザクション管理装置。
5. 【請求項５】前記管理手段に管理されている取引情報の
   うち、前記第４の情報が、最終的な状態以外の状態を規
   定時間以上継続しているものがあるか否か調べ、該当す
   る取引情報が、既に送信したメッセージに対する返答を
   待っている状態を持つものである場合には、該メッセー
   ジを再送し、その状態が継続している時間を初期化する
   ことを特徴とする請求項１に記載のトランザクション管
   理装置。
6. 【請求項６】前記管理手段に管理されている取引情報の
   うち、前記第１の状態を規定時間以上継続しているもの
   があるか否か調べ、該当する取引情報がある場合には、
   該当するショップコンピュータへ該取引を取り消すべき
   ことを指示することを特徴とする請求項１に記載のトラ
   ンザクション管理装置。
7. 【請求項７】前記利用者のクライアントコンピュータか
   ら再接続があった場合に、前記管理手段に管理された該
   利用者に該当する第２の情報を持つ取引情報の持つ前記
   第４の情報の示す状態に応じた内容の通知情報を作成し
   て、該通知情報を該クライアントコンピュータへ送信す
   る手段を更に備えたことを特徴とする請求項１に記載の
   トランザクション管理装置。
8. 【請求項８】前記管理手段は、前記第３の状態を持つ取
   引を過去の取引履歴として管理するものであり、 前記トランザクション管理装置は、前記利用者のクライ
   アントコンピュータから所定の条件を満たす取引の履歴
   を送信すべき要求を受信した場合に、前記管理手段に管
   理された取引情報のうち、前記第３の状態を持ち且つ前
   記第２の情報が該要求元の利用者に該当し且つ前記所定
   の条件を満たす取引情報に基づいて、取引履歴情報を生
   成し、該取引履歴情報を該要求元のクライアントコンピ
   ュータへ送信する手段を更に備えたことを特徴とする請
   求項１に記載のトランザクション管理装置。
9. 【請求項９】前記取引情報のうち前記クライアントコン
   ピュータ又は前記ショップコンピュータにおいて発生す
   る情報は、該取引に係る利用者のクライアントコンピュ
   ータから該取引に係る電子店舗を提供するショップコン
   ピュータを経由して自装置へ伝えられるものであること
   を特徴とする請求項１に記載のトランザクション管理装
   置。
10. 【請求項１０】前記管理手段に管理されている第１の状
    態を持つ取引情報に係る取引の成立を確定させるべき旨
    の指示は、該取引に係る利用者のクライアントコンピュ
    ータから自装置を経由して該取引に係る電子店舗を提供
    するショップコンピュータへ伝えられるものであること
    を特徴とする請求項１に記載のトランザクション管理装
    置。
11. 【請求項１１】指示された前記管理手段に管理されてい
    る第１の状態を持つ取引情報に係る取引を確定させるた
    めの処理が完了した旨の通知は、該取引に係る電子店舗
    を提供するショップコンピュータから自装置を経由して
    該取引に係る利用者のクライアントコンピュータへ伝え
    られるものであることを特徴とする請求項１に記載のト
    ランザクション管理装置。
12. 【請求項１２】ネットワークを介して通信可能な、電子
    店舗を提供する複数のショップコンピュータ、電子店舗
    を利用する利用者の使用する複数のクライアントコンピ
    ュータ及び電子店舗と利用者との間で進行中の取引を管
    理するトランザクション管理コンピュータとを含む電子
    取引システムであって、 前記利用者のクライアントコンピュータと該利用者が所
    望する電子店舗を提供するショップコンピュータとの間
    で該利用者の所望する取引のための一定の手続きを行っ
    た後に、該クライアントコンピュータから該ショップコ
    ンピュータへトランザクション管理コンピュータを利用
    すべき旨が要求された場合に該ショップコンピュータか
    ら前記トランザクション管理コンピュータへ該一定の手
    続きを経た取引を進行中の取引として登録する一連の手
    順が、該利用者のクライアントコンピュータと複数のシ
    ョップコンピュータとの間のそれぞれの取引について行
    われ、 前記トランザクション管理コンピュータへ登録されてい
    る複数の進行中の取引について、その取引に係る利用者
    のクライアントコンピュータから該トランザクション管
    理コンピュータへ該複数の取引の成立を一括して確定さ
    せるべき旨が指示された場合に、該当するショップコン
    ピュータとの間で所定の手続きを行って、可能であれば
    該複数の取引の成立を一括して確定させ、それが可能で
    なければ該複数の取引を一括して取り消し、 前記トランザクション管理コンピュータから前記利用者
    のクライアントコンピュータへ、前記指示に対する処理
    の結果を通知することを特徴とする電子取引システム。
13. 【請求項１３】ネットワークを介して電子店舗を提供す
    るショップコンピュータの電子取引方法であって、 自店舗を利用する利用者のクライアントコンピュータと
    の間で該利用者の所望する取引のための一定の手続きを
    行った後に、利用者と電子店舗との間で進行中の取引を
    管理するトランザクション管理コンピュータを利用すべ
    き旨が該クライアントコンピュータから要求された場合
    に、該トランザクション管理コンピュータへ該一定の手
    続きを経た取引を進行中の取引として登録し、 前記トランザクション管理コンピュータから、該トラン
    ザクション管理コンピュータへ登録されている自店舗に
    係る進行中の取引のうちの特定のものについて、該取引
    の成立を確定させるための手続きが完結可能であるか否
    かの問い合わせを受けた場合に、完結可能であるか否か
    を判断し、完結可能であればその旨を前記トランザクシ
    ョン管理コンピュータへ返答し、 前記完結可能の旨を前記トランザクション管理コンピュ
    ータへ返答した後に、該トランザクション管理コンピュ
    ータから、前記特定の取引の成立を確定させるための手
    続きを完結させることが指示された場合には、該取引の
    成立を確定させるための処理を行い、前記特定の取引を
    取り消すべきことが指示された場合には、該取引を取り
    消すための処理を行った後に、前記トランザクション管
    理コンピュータへ処理完了を通知することを特徴とする
    電子取引方法。
14. 【請求項１４】ネットワークを介して電子店舗を提供す
    る複数のショップコンピュータと電子店舗を利用する利
    用者の使用する複数のクライアントコンピュータとの間
    に入り、利用者と電子店舗との間で進行中の取引を管理
    するトランザクション管理コンピュータのトランザクシ
    ョン管理方法であって、 複数の前記ショップコンピュータの各々からの通知に基
    づいて、前記利用者のクライアントコンピュータと該利
    用者が所望する電子店舗を提供するショップコンピュー
    タとの間で行われるべき一定の手続きを経た取引を進行
    中の取引としてそれぞれ登録し、 自コンピュータへ登録されている複数の進行中の取引に
    ついて、その取引に係る利用者のクライアントコンピュ
    ータから該複数の取引の成立を一括して確定させるべき
    旨が指示された場合に、該指示された複数の取引の各々
    について、該当する各々のショップコンピュータへ当該
    取引の成立を確定させるための手続きが完結可能である
    か否かを問い合わせ、指示された複数の取引の全てにつ
    いて完結可能であることが確認されたならば、該当する
    各々のショップコンピュータへ当該取引の成立を確定さ
    せるための手続きを完結させることを指示し、前記クラ
    イアントコンピュータから指示された複数の取引のうち
    に１つでも完結不可能となるものがあることが確認され
    たならば、該指示された複数の取引の全てについて、該
    当する各々のショップコンピュータへ当該取引を取り消
    すべきことを指示し、 前記指示を出したショップコンピュータから処理完了の
    通知を受けた場合に、自コンピュータへ登録されている
    該当する進行中の取引を、成立した取引又は取り消され
    た取引として更新することを特徴とするトランザクショ
    ン管理方法。
15. 【請求項１５】ネットワークを介して電子店舗を提供す
    る複数のショップコンピュータと電子店舗を利用する利
    用者の使用する複数のクライアントコンピュータとの間
    に入り、利用者と電子店舗との間で進行中の取引を管理
    するトランザクション管理コンピュータから送信され
    た、該トランザクション管理コンピュータに管理されて
    いる或る利用者の進行中の取引に関する情報を含むペー
    ジを受信した該或る利用者のクライアントコンピュータ
    は、受信した該ページを表示画面に表示し、 前記クライアントコンピュータは、前記トランザクショ
    ン管理コンピュータに管理されている複数の進行中の取
    引に関する情報を含む前記ページの表示中に、該複数の
    取引について、取引の成立を一括して確定すべき旨の指
    示の入力を受け付け、 前記指示が入力されたことによって前記クライアントコ
    ンピュータから前記トランザクション管理コンピュータ
    へ該指示が与えられたことを契機として、該当するショ
    ップコンピュータとの間で所定の手続きを行って、可能
    であれば該複数の取引の成立を一括して確定させ、それ
    が可能でなければ該複数の取引を一括して取り消す処理
    を行った前記トランザクション管理コンピュータから送
    信された、該処理の結果を示す情報を含むページを受信
    した該或る利用者のクライアントコンピュータは、受信
    した該ページを表示画面に表示することを特徴とする電
    子取引方法。
16. 【請求項１６】前記指示が与えられたことを契機として
    前記処理を行っている前記トランザクション管理コンピ
    ュータは、或る要因で処理が滞っている場合に、その旨
    を示す表示可能な情報を前記或る利用者のクライアント
    コンピュータへ送信することを特徴とする請求項１５に
    記載の電子取引方法。
17. 【請求項１７】ネットワークを介して電子店舗を提供す
    る複数のショップコンピュータと電子店舗を利用する利
    用者の使用する複数のクライアントコンピュータとの間
    に入り、利用者と電子店舗との間で進行中の取引を管理
    するトランザクション管理コンピュータから送信され
    た、該トランザクション管理コンピュータに管理されて
    いる或る利用者の進行中の取引に関する情報を含むペー
    ジを受信した該或る利用者のクライアントコンピュータ
    は、受信した該ページを表示画面に表示し、 前記クライアントコンピュータは、前記トランザクショ
    ン管理コンピュータに管理されている複数の進行中の取
    引に関する情報を含む前記ページの表示中に、該複数の
    取引について、取引を取り消すべき旨の指示の入力を受
    け付け、 前記指示が入力されたことによって前記クライアントコ
    ンピュータから前記トランザクション管理コンピュータ
    へ該指示が与えられたことを契機として、該当するショ
    ップコンピュータとの間で所定の手続きを行って、該取
    引を取り消す処理を行った前記トランザクション管理コ
    ンピュータから送信された、該処理の結果を示す情報を
    含むページを受信した該或る利用者のクライアントコン
    ピュータは、受信した該ページを表示画面に表示するこ
    とを特徴とする電子取引方法。
18. 【請求項１８】ネットワークを介して電子店舗を提供す
    る複数のショップコンピュータと電子店舗を利用する利
    用者の使用する複数のクライアントコンピュータとの間
    に入り、利用者と電子店舗との間の取引を管理するトラ
    ンザクション管理コンピュータに対するページ要求が、
    或る利用者のクライアントコンピュータにおいて入力さ
    れた場合、該クライアントコンピュータから該トランザ
    クション管理コンピュータへページ要求を送信し、 前記トランザクション管理コンピュータは、ページ要求
    を送信した前記或る利用者のクライアントコンピュータ
    が再接続となるものである場合には、自コンピュータに
    管理されている該或る利用者の取引の進行状況に応じて
    該取引に関する情報を含むページを作成して、該或る利
    用者のクライアントコンピュータへ送信し、 前記ページを受信した前記或る利用者のクライアントコ
    ンピュータは、受信した該ページを表示画面に表示する
    ことを特徴とする電子取引方法。
19. 【請求項１９】ネットワークを介して電子店舗を提供す
    る複数のショップコンピュータと電子店舗を利用する利
    用者の使用する複数のクライアントコンピュータとの間
    に入り、利用者と電子店舗との間の取引を管理するトラ
    ンザクション管理コンピュータに対する取引履歴のペー
    ジ要求が、或る利用者のクライアントコンピュータにお
    いて入力された場合、該クライアントコンピュータから
    該トランザクション管理コンピュータへ取引履歴のペー
    ジ要求を送信し、 前記トランザクション管理コンピュータは、受信したペ
    ージ要求が取引履歴を要求するものである場合には、自
    コンピュータに管理されている該或る利用者の過去に成
    立した取引に関する情報を含むページを作成して、該或
    る利用者のクライアントコンピュータへ送信し、 前記ページを受信した前記或る利用者のクライアントコ
    ンピュータは、受信した該ページを表示画面に表示する
    ことを特徴とする電子取引方法。
20. 【請求項２０】ネットワークを介して電子店舗を提供す
    る複数のショップコンピュータと電子店舗を利用する利
    用者の使用する複数のクライアントコンピュータとの間
    に入り、利用者と電子店舗との間で進行中の取引を管理
    するトランザクション管理コンピュータのためのプログ
    ラムを記録したコンピュータ読取り可能な記録媒体であ
    って、 ネットワーク上で電子店舗を提供する複数のショップコ
    ンピュータ及び電子店舗を利用する利用者の使用する複
    数のクライアントコンピュータと通信するための手段
    と、 少なくともいずれかの前記電子店舗といずれかの前記利
    用者との間で進行中の取引について、該取引を特定する
    ための第１の情報と、該取引に係る利用者を識別するた
    めの第２の情報と、該取引に係る電子店舗を識別するた
    めの第３の情報と、該取引の状態が、少なくとも、取引
    の成立又は不成立を確定させるための指示を待っている
    第１の状態、取引の成立を確定させるための指示を受け
    て取引の成立を確定させるための処理を開始したが該処
    理が未だ完了していない第２の状態、取引の成立を確定
    させるための処理が完了した第３の状態、取引の不成立
    が確定している第４の状態のいずれであるかを区別する
    ための第４の情報との組を含む取引情報を、管理するた
    めの手段として機能させるためのプログラムを記録した
    コンピュータ読取り可能な記録媒体。