(57)【特許請求の範囲】
【請求項１】
ネットワーク上で電子店舗を提供するショップコンピュータ及び電子店舗を利用する利用者の使用するクライアントコンピュータと通信するための通信手段と、
前記電子店舗と前記利用者との間で当該電子店舗に係る前記ショップコンピュータと当該利用者に係る前記クライアントコンピュータとの通信を介して進行中である第１の取引について、該第１の取引を特定するための第１の取引ＩＤと、該第１の取引に係る電子店舗を識別するための第１の店ＩＤとの組を、当該電子店舗に係る前記ショップコンピュータから、前記通信手段を介して取得する第１の取得手段と、
取得した前記第１の取引ＩＤと前記第１の店ＩＤとの組が登録される取引情報記憶手段と、
第２の取引を特定するため第２の取引ＩＤと該第２の取引に係る電子店舗を識別するための第２の店ＩＤとの組を、前記クライアントコンピュータから、前記通信手段を介して取得する第２の取得手段と、
前記クライアントコンピュータから前記通信手段を介して取得する、当該クライアントコンピュータに係る前記利用者を識別するための客ＩＤを使って、前記利用者の認証を行う認証手段と、
前記第１の取得手段により前記ショップコンピュータから取得し前記取引情報記憶手段に登録した前記第１の取引ＩＤと前記第１の店ＩＤとの組が、前記第２の取得手段により前記クライアントコンピュータから取得した前記第２の取引ＩＤと前記第２の店ＩＤとの組と同じである場合に、前記認証手段により認証された、当該クライアントコンピュータの利用者に係る前記客ＩＤを、前記取引情報記憶手段に登録された前記第１の取引ＩＤと前記第１の店ＩＤとの組に対して関連付けて前記取引情報記憶手段に登録する管理手段とを備え、
前記管理手段は、前記第１の取引ＩＤと前記第１の店ＩＤとの組に対して関連付けて、当該第１の取引ＩＤで特定される第１の取引の状態を示す状態情報をも、前記取引情報記憶手段に登録するものであることを特徴とするトランザクション管理装置。
【請求項２】
前記取引情報記憶手段に登録されている複数の第１の取引の成立を一括して確定させるべき旨の指示を、前記クライアントコンピュータから前記通信手段を介して受信した場合に、前記取引情報記憶手段において当該クライアントコンピュータの利用者に係る前記客ＩＤと当該第１の取引が成立するか不成立となるかについて確定していないことを示すＡＣＴＩＶＥ状態を示す前記状態情報とが関連付けて登録されている前記第１の取引ＩＤで特定される複数の第１の取引の各々について、当該第１の取引の取引ＩＤと組になって前記取引情報記憶手段に登録されている前記第１の店ＩＤで特定される電子店舗に係る前記ショップコンピュータへ、それぞれ、当該第１の取引の成立を確定させるための手続きが完結可能であるか否かを問い合わせるＰＲＥＰＡＲＥメッセージを、前記通信手段を介して送信するとともに、当該複数の第１の取引の各々に関連付けて前記取引情報記憶手段に登録されている前記状態情報を、それぞれ、ＡＣＴＩＶＥ状態から、ＰＲＥＰＡＲＩＮＧ状態へ変更し、
前記複数の第１の取引の各々について、当該第１の取引に係る前記ショップコンピュータから前記通信手段を介して、前記手続きが完結可能であることを示すＰＲＥＣＯＭＭＩＴメッセージを受信したならば、当該第１の取引の取引ＩＤに関連付けて前記取引情報記憶手段に登録されている前記状態情報を、ＰＲＥＰＡＲＩＮＧ状態から、ＰＲＥＣＯＭＭＩＴＥＤ状態へ変更し、
前記複数の第１の取引の全てについて、当該第１の取引の取引ＩＤに関連付けて前記取引情報記憶手段に登録されている前記状態情報がＰＲＥＣＯＭＭＩＴＥＤ状態へ変更されたならば、前記複数の第１の取引の各々について、当該第１の取引に係る前記ショップコンピュータへ当該第１の取引の成立を確定させるための手続きを完結させることを指示するＣＯＭＭＩＴメッセージを、前記通信手段を介して送信するとともに、当該第１の取引の取引ＩＤに関連付けて前記取引情報記憶手段に登録されている前記状態情報を、ＰＲＥＣＯＭＭＩＴＥＤ状態から、ＣＯＭＭＩＴＴＩＮＧ状態へ変更し、
前記複数の第１の取引の全てについて、当該第１の取引に係る前記ショップコンピュータから前記通信手段を介して、前記手続きが完結したことを示すＣＯＭＭＩＴＴＥＤメッセージを受信したならば、当該第１の取引の取引ＩＤに関連付けて前記取引情報記憶手段に登録されている前記状態情報を、ＣＯＭＭＩＴＴＩＮＧ状態から、最終的に当該第１の取引の成立が確定したことを示すＣＯＭＭＩＴＴＥＤ状態へ変更する一括処理手段を、前記管理手段が含むことを特徴とする請求項１に記載のトランザクション管理装置。
【請求項３】
前記一括処理手段は、前記一括して確定させるべき旨の指示とともに、一括して確定させる対象とすべき第１の取引の範囲に関する指示を受けた場合には、指示を受けた該範囲に含まれる第１の取引についてのみ、一括して確定させる処理の対象とすることを特徴とする請求項２に記載のトランザクション管理装置。
【請求項４】
前記一括処理手段は、
前記複数の第１の取引のうちに、ＰＲＥＰＡＲＥメッセージを送信した後に、当該第１の取引に係る前記ショップコンピュータから前記通信手段を介して、前記手続きが完結不能であることを示すＡＢＯＲＴメッセージを受信したものが一つでもある場合には、ＡＢＯＲＴメッセージを受信した第１の取引の取引ＩＤに関連付けて前記取引情報記憶手段に登録されている前記状態情報を、ＰＲＥＰＡＲＩＮＧ状態から、最終的に当該第１の取引の不成立が確定したことを示すＡＢＯＲＴＥＤ状態へ変更し、
前記複数の第１の取引のうちに、当該第１の取引の取引ＩＤに関連付けて前記取引情報記憶手段に登録されている前記状態情報が既にＰＲＥＣＯＭＭＩＴＴＥＤ状態に変更されているものがあるならば、該状態情報をＰＲＥＣＯＭＭＩＴＴＥＤ状態からＡＢＯＲＴＩＮＧ状態に変更するとともに、当該第１の取引に係る前記ショップコンピュータへ当該第１の取引を取り消すための処理の実行を指示するＡＢＯＲＴメッセージを、前記通信手段を介して送信し、
ＡＢＯＲＴＩＮＧ状態に変更された前記複数の第１の取引の各々について、当該第１の取引に係る前記ショップコンピュータから前記通信手段を介して、前記処理が完結したことを示すＡＢＯＲＴＥＤメッセージを受信したならば、当該第１の取引の取引ＩＤに関連付けて前記取引情報記憶手段に登録されている前記状態情報を、それぞれ、ＡＢＯＲＴＩＮＧ状態から、ＡＢＯＲＴＥＤ状態へ変更することを特徴とする請求項２または３に記載のトランザクション管理装置。
【請求項５】
前記一括処理手段は、
前記取引情報記憶手段に登録されている複数の第１の取引の不成立を一括して確定させるべき旨の指示を、前記クライアントコンピュータから前記通信手段を介して受信した場合に、前記取引情報記憶手段において当該クライアントコンピュータの利用者に係る前記客ＩＤとＡＣＴＩＶＥ状態を示す前記状態情報とが関連付けて登録されている前記第１の取引ＩＤで特定される複数の第１の取引の各々について、当該第１の取引の取引ＩＤと組になって前記取引情報記憶手段に登録されている前記第１の店ＩＤで特定される電子店舗に係るショップコンピュータへ、それぞれ、当該第１の取引を取り消すための処理の実行を指示するＡＢＯＲＴメッセージを、前記通信手段を介して送信するとともに、当該複数の第１の取引の取引ＩＤに関連付けて前記取引情報記憶手段に登録されている前記状態情報を、それぞれ、ＡＣＴＩＶＥ状態から、ＡＢＯＲＴＩＮＧ状態へ変更し、
ＡＢＯＲＴＩＮＧ状態に変更された前記複数の第１の取引の各々について、当該第１の取引に係る前記ショップコンピュータから前記通信手段を介して、前記処理が完結したことを示すＡＢＯＲＴＥＤメッセージを受信したならば、当該第１の取引の取引ＩＤに関連付けて前記取引情報記憶手段に登録されている前記状態情報を、それぞれ、ＡＢＯＲＴＩＮＧ状態から、最終的に当該第１の取引の不成立が確定したことを示すＡＢＯＲＴＥＤ状態へ変更することを特徴とする請求項２ないし４のいずれか１項に記載のトランザクション管理装置。
【請求項６】
前記トランザクション管理装置は、前記客ＩＤと、該客ＩＤに係る利用者に関する個人情報とを関連付けて登録した個人情報記憶手段を更に備え、
前記一括処理手段は、前記第１の取引に係る前記ショップコンピュータへＣＯＭＭＩＴメッセージを送信する際に、該第１の取引に係る利用者の前記客ＩＤに関連付けて前記個人情報記憶手段に登録されている前記個人情報を該ＣＯＭＭＩＴメッセージに含ませて送信することを特徴とする請求項２または３に記載のトランザクション管理装置。
【請求項７】
前記管理手段は、
前記第１の取引ＩＤと前記第１の店ＩＤとの組に対して関連付けて、当該第１の取引ＩＤで特定される第１の取引に係る前記状態情報の現在の内容が前記取引情報記憶手段に登録された日時を示す日時情報をも、前記取引情報記憶手段に登録するものであるとともに、
前記取引情報記憶手段に登録されている前記第１の取引ＩＤと前記第１の店ＩＤとの組のうちに、その組に関連付けて登録されている前記状態情報が、ＰＲＥＰＡＲＩＮＧ状態又はＣＯＭＩＴＴＩＮＧ状態であって、その状態を規定時間以上継続しているものがあるか否かを、前記日時情報と現在日時とを比較することによって調べ、ＰＲＥＰＡＲＩＮＧ状態を規定時間以上継続している前記第１の取引ＩＤと前記第１の店ＩＤとの組がある場合には、その組に係る前記ショップコンピュータへＰＲＥＰＡＲＥメッセージを前記通信手段を介して再送するとともに、前記日時情報を現在日時に更新し、ＣＯＭＩＴＴＩＮＧ状態を規定時間以上継続している前記第１の取引ＩＤと前記第１の店ＩＤとの組がある場合には、その組に係る前記ショップコンピュータへＣＯＭＭＩＴメッセージを前記通信手段を介して再送するとともに、前記日時情報を現在日時に更新することを特徴とする請求項２または３に記載のトランザクション管理装置。
【請求項８】
前記管理手段は、
前記第１の取引ＩＤと前記第１の店ＩＤとの組に対して関連付けて、当該第１の取引ＩＤで特定される第１の取引に係る前記状態情報の現在の内容が前記取引情報記憶手段に登録された日時を示す日時情報をも、前記取引情報記憶手段に登録するものであるとともに、
前記取引情報記憶手段に登録されている前記第１の取引ＩＤと前記第１の店ＩＤとの組のうち、その組に関連付けて登録されている前記状態情報が、ＡＢＯＲＴＩＮＧ状態であって、その状態を規定時間以上継続しているものがあるか否かを、前記日時情報と現在日時とを比較することによって調べ、ＡＢＯＲＴＩＮＧ状態を規定時間以上継続している前記第１の取引ＩＤと前記第１の店ＩＤとの組がある場合には、その組に係る前記ショップコンピュータへＡＢＯＲＴメッセージを前記通信手段を介して再送するとともに、前記日時情報を現在日時に更新することを特徴とする請求項４または５に記載のトランザクション管理装置。
【請求項９】
前記管理手段は、
前記第１の取引ＩＤと前記第１の店ＩＤとの組に対して関連付けて、当該第１の取引ＩＤで特定される第１の取引に係る前記状態情報の現在の内容が前記取引情報記憶手段に登録された日時を示す日時情報をも、前記取引情報記憶手段に登録するものであるとともに、
前記取引情報記憶手段に登録されている前記第１の取引ＩＤと前記第１の店ＩＤとの組のうち、その組に関連付けて登録されている前記状態情報が、当該第１の取引が成立するか不成立となるかについて確定していないことを示すＡＣＴＩＶＥ状態を示すものであって、その状態を規定時間以上継続しているものがあるか否かを、前記日時情報と現在日時とを比較することによって調べ、
ＡＣＴＩＶＥ状態を規定時間以上継続している前記第１の取引ＩＤと前記第１の店ＩＤとの組がある場合には、更に、この組と関連付けて前記取引情報記憶手段に登録されている前記客ＩＤと同じ客ＩＤ及びＡＣＴＩＶＥ状態を示す前記状態情報に関連付けて前記取引情報記憶手段に登録されている他の全ての第１の取引ＩＤと第１の店ＩＤとの組の各々について、ＡＣＴＩＶＥ状態を規定時間以上継続しているか否かを、前記日時情報と現在日時とを比較することによって調べ、
前記他の全ての第１の取引ＩＤと第１の店ＩＤとの組が、ＡＣＴＩＶＥ状態を規定時間以上継続しているものであるならば、前記客ＩＤ及びＡＣＴＩＶＥ状態を示す前記状態情報に関連付けて前記取引情報記憶手段に登録されている全ての第１の取引ＩＤと第１の店ＩＤとの組の各々について、それぞれ、当該第１の店ＩＤで特定される電子店舗に係るショップコンピュータへ、当該第１の取引ＩＤで特定される第１の取引を取り消すための処理の実行を指示するＡＢＯＲＴメッセージを、前記通信手段を介して送信するとともに、当該全ての第１の取引ＩＤと第１の店ＩＤとの組に関連付けて前記取引情報記憶手段に登録されている前記状態情報を、それぞれ、ＡＣＴＩＶＥ状態から、ＡＢＯＲＴＩＮＧ状態へ変更し、
ＡＢＯＲＴＩＮＧ状態に変更された前記第１の取引の各々について、当該第１の取引に係る前記ショップコンピュータから前記通信手段を介して、前記処理が完結したことを示すＡＢＯＲＴＥＤメッセージを受信したならば、当該第１の取引に関連付けて前記取引情報記憶手段に登録されている前記状態情報を、ＡＢＯＲＴＩＮＧ状態から、最終的に当該第１の取引の不成立が確定したことを示すＡＢＯＲＴＥＤ状態へ変更することを特徴とする請求項１に記載のトランザクション管理装置。
【請求項１０】
前記管理手段は、前記複数の第１の取引の全てについて、当該第１の取引の取引ＩＤに関連付けて前記取引情報記憶手段に登録されている前記状態情報がＣＯＭＭＩＴＴＥＤ状態へ変更された場合に、複数の第１の取引の成立を一括して確定させるための処理が完了した旨を通知するメッセージを、該複数の第１の取引に係る利用者の前記クライアントコンピュータへ、前記通信手段を介して送信することを特徴とする請求項２または３に記載のトランザクション管理装置。
【請求項１１】
ネットワーク上で電子店舗を提供するショップコンピュータ及び電子店舗を利用する利用者の使用するクライアントコンピュータと通信するための通信手段と、第１の取得手段と、取引情報記憶手段と、第２の取得手段と、認証手段と、管理手段とを備えたトランザクション管理装置のトランザクション管理方法であって、
前記電子店舗と前記利用者との間で当該電子店舗に係る前記ショップコンピュータと当該利用者に係る前記クライアントコンピュータとの通信を介して進行中である第１の取引について、該第１の取引を特定するための第１の取引ＩＤと、該第１の取引に係る電子店舗を識別するための第１の店ＩＤとの組を、当該電子店舗に係る前記ショップコンピュータから、前記通信手段を介して前記第１の取得手段により取得するステップと、
取得した前記第１の取引ＩＤと前記第１の店ＩＤとの組を取引情報記憶手段に前記管理手段により登録するステップと、
第２の取引を特定するため第２の取引ＩＤと該第２の取引に係る電子店舗を識別するための第２の店ＩＤとの組を、前記クライアントコンピュータから、前記通信手段を介して第２の取得手段により取得するステップと、
前記クライアントコンピュータから前記通信手段を介して取得する、当該クライアントコンピュータに係る前記利用者を識別するための客ＩＤを使って、前記利用者の認証を前記認証手段により行うステップと、
前記第１の取得手段により前記ショップコンピュータから取得し前記取引情報記憶手段に登録した前記第１の取引ＩＤと前記第１の店ＩＤとの組が、前記第２の取得手段により前記クライアントコンピュータから取得した前記第２の取引ＩＤと前記第２の店ＩＤとの組と同じである場合に、前記認証手段により認証された、当該クライアントコンピュータの利用者に係る前記客ＩＤを、前記取引情報記憶手段に登録された前記第１の取引ＩＤと前記第１の店ＩＤとの組に対して関連付けて前記取引情報記憶手段に前記管理手段により登録するステップと、
前記第１の取引ＩＤと前記第１の店ＩＤとの組に対して関連付けて、当該第１の取引ＩＤで特定される第１の取引の状態を示す状態情報を、前記取引情報記憶手段に前記前記管理手段により登録するステップとを有することを特徴とするトランザクション管理方法。
【請求項１２】
前記取引情報記憶手段に登録されている複数の第１の取引の成立を一括して確定させるべき旨の指示を、前記クライアントコンピュータから前記通信手段を介して受信した場合に、前記取引情報記憶手段において当該クライアントコンピュータの利用者に係る前記客ＩＤと当該第１の取引が成立するか不成立となるかについて確定していないことを示すＡＣＴＩＶＥ状態を示す前記状態情報とが関連付けて登録されている前記第１の取引ＩＤで特定される複数の第１の取引の各々について、当該第１の取引の取引ＩＤと組になって前記取引情報記憶手段に登録されている前記第１の店ＩＤで特定される電子店舗に係る前記ショップコンピュータへ、それぞれ、当該第１の取引の成立を確定させるための手続きが完結可能であるか否かを問い合わせるＰＲＥＰＡＲＥメッセージを、前記通信手段を介して送信するとともに、当該複数の第１の取引の各々に関連付けて前記取引情報記憶手段に登録されている前記状態情報を、それぞれ、ＡＣＴＩＶＥ状態から、ＰＲＥＰＡＲＩＮＧ状態へ変更し、
前記複数の第１の取引の各々について、当該第１の取引に係る前記ショップコンピュータから前記通信手段を介して、前記手続きが完結可能であることを示すＰＲＥＣＯＭＭＩＴメッセージを受信したならば、当該第１の取引の取引ＩＤに関連付けて前記取引情報記憶手段に登録されている前記状態情報を、ＰＲＥＰＡＲＩＮＧ状態から、ＰＲＥＣＯＭＭＩＴＥＤ状態へ変更し、
前記複数の第１の取引の全てについて、当該第１の取引の取引ＩＤに関連付けて前記取引情報記憶手段に登録されている前記状態情報がＰＲＥＣＯＭＭＩＴＥＤ状態へ変更されたならば、前記複数の第１の取引の各々について、当該第１の取引に係る前記ショップコンピュータへ当該第１の取引の成立を確定させるための手続きを完結させることを指示するＣＯＭＭＩＴメッセージを、前記通信手段を介して送信するとともに、当該第１の取引の取引ＩＤに関連付けて前記取引情報記憶手段に登録されている前記状態情報を、ＰＲＥＣＯＭＭＩＴＥＤ状態から、ＣＯＭＭＩＴＴＩＮＧ状態へ変更し、
前記複数の第１の取引の全てについて、当該第１の取引に係る前記ショップコンピュータから前記通信手段を介して、前記手続きが完結したことを示すＣＯＭＭＩＴＴＥＤメッセージを受信したならば、当該第１の取引の取引ＩＤに関連付けて前記取引情報記憶手段に登録されている前記状態情報を、ＣＯＭＭＩＴＴＩＮＧ状態から、最終的に当該第１の取引の成立が確定したことを示すＣＯＭＭＩＴＴＥＤ状態へ変更することを、
前記管理手段に含まれる前記一括処理手段により行う一括処理ステップを更に有することを特徴とする請求項１１に記載のトランザクション管理方法。
【請求項１３】
前記一括処理ステップにおいて、前記一括処理手段は、前記一括して確定させるべき旨の指示とともに、一括して確定させる対象とすべき第１の取引の範囲に関する指示を受けた場合には、指示を受けた該範囲に含まれる第１の取引についてのみ、一括して確定させる処理の対象とすることを特徴とする請求項１２に記載のトランザクション管理方法。
【請求項１４】
前記一括処理ステップにおいて、前記一括処理手段は、
前記複数の第１の取引のうちに、ＰＲＥＰＡＲＥメッセージを送信した後に、当該第１の取引に係る前記ショップコンピュータから前記通信手段を介して、前記手続きが完結不能であることを示すＡＢＯＲＴメッセージを受信したものが一つでもある場合には、ＡＢＯＲＴメッセージを受信した第１の取引の取引ＩＤに関連付けて前記取引情報記憶手段に登録されている前記状態情報を、ＰＲＥＰＡＲＩＮＧ状態から、最終的に当該第１の取引の不成立が確定したことを示すＡＢＯＲＴＥＤ状態へ変更し、
前記複数の第１の取引のうちに、当該第１の取引の取引ＩＤに関連付けて前記取引情報記憶手段に登録されている前記状態情報が既にＰＲＥＣＯＭＭＩＴＴＥＤ状態に変更されているものがあるならば、該状態情報をＰＲＥＣＯＭＭＩＴＴＥＤ状態からＡＢＯＲＴＩＮＧ状態に変更するとともに、当該第１の取引に係る前記ショップコンピュータへ当該第１の取引を取り消すための処理の実行を指示するＡＢＯＲＴメッセージを、前記通信手段を介して送信し、
ＡＢＯＲＴＩＮＧ状態に変更された前記複数の第１の取引の各々について、当該第１の取引に係る前記ショップコンピュータから前記通信手段を介して、前記処理が完結したことを示すＡＢＯＲＴＥＤメッセージを受信したならば、当該第１の取引の取引ＩＤに関連付けて前記取引情報記憶手段に登録されている前記状態情報を、それぞれ、ＡＢＯＲＴＩＮＧ状態から、ＡＢＯＲＴＥＤ状態へ変更することを特徴とする請求項１２または１３に記載のトランザクション管理方法。
【請求項１５】
前記一括処理ステップにおいて、前記一括処理手段は、
前記取引情報記憶手段に登録されている複数の第１の取引の不成立を一括して確定させるべき旨の指示を、前記クライアントコンピュータから前記通信手段を介して受信した場合に、前記取引情報記憶手段において当該クライアントコンピュータの利用者に係る前記客ＩＤとＡＣＴＩＶＥ状態を示す前記状態情報とが関連付けて登録されている前記第１の取引ＩＤで特定される複数の第１の取引の各々について、当該第１の取引の取引ＩＤと組になって前記取引情報記憶手段に登録されている前記第１の店ＩＤで特定される電子店舗に係るショップコンピュータへ、それぞれ、当該第１の取引を取り消すための処理の実行を指示するＡＢＯＲＴメッセージを、前記通信手段を介して送信するとともに、当該複数の第１の取引の取引ＩＤに関連付けて前記取引情報記憶手段に登録されている前記状態情報を、それぞれ、ＡＣＴＩＶＥ状態から、ＡＢＯＲＴＩＮＧ状態へ変更し、
ＡＢＯＲＴＩＮＧ状態に変更された前記複数の第１の取引の各々について、当該第１の取引に係る前記ショップコンピュータから前記通信手段を介して、前記処理が完結したことを示すＡＢＯＲＴＥＤメッセージを受信したならば、当該第１の取引の取引ＩＤに関連付けて前記取引情報記憶手段に登録されている前記状態情報を、それぞれ、ＡＢＯＲＴＩＮＧ状態から、最終的に当該第１の取引の不成立が確定したことを示すＡＢＯＲＴＥＤ状態へ変更することを特徴とする請求項２ないし４のいずれか１項に記載のトランザクション管理装置。
【請求項１６】
トランザクション管理装置としてコンピュータを機能させるためのプログラムを記録したコンピュータ読取り可能な記録媒体であって、
ネットワーク上で電子店舗を提供するショップコンピュータ及び電子店舗を利用する利用者の使用するクライアントコンピュータと通信するための通信手段と、
前記電子店舗と前記利用者との間で当該電子店舗に係る前記ショップコンピュータと当該利用者に係る前記クライアントコンピュータとの通信を介して進行中である第１の取引について、該第１の取引を特定するための第１の取引ＩＤと、該第１の取引に係る電子店舗を識別するための第１の店ＩＤとの組を、当該電子店舗に係る前記ショップコンピュータから、前記通信手段を介して取得する第１の取得手段と、
取得した前記第１の取引ＩＤと前記第１の店ＩＤとの組が登録される取引情報記憶手段と、
第２の取引を特定するため第２の取引ＩＤと該第２の取引に係る電子店舗を識別するための第２の店ＩＤとの組を、前記クライアントコンピュータから、前記通信手段を介して取得する第２の取得手段と、
前記クライアントコンピュータから前記通信手段を介して取得する、当該クライアントコンピュータに係る前記利用者を識別するための客ＩＤを使って、前記利用者の認証を行う認証手段と、
前記第１の取得手段により前記ショップコンピュータから取得し前記取引情報記憶手段に登録した前記第１の取引ＩＤと前記第１の店ＩＤとの組が、前記第２の取得手段により前記クライアントコンピュータから取得した前記第２の取引ＩＤと前記第２の店ＩＤとの組と同じである場合に、前記認証手段により認証された当該クライアントコンピュータの利用者に係る前記客ＩＤを、前記取引情報記憶手段に登録された前記第１の取引ＩＤと前記第１の店ＩＤとの組に対して関連付けて前記取引情報記憶手段に登録する管理手段としてコンピュータを機能させるためのものであるとともに、
前記管理手段は、前記第１の取引ＩＤと前記第１の店ＩＤとの組に対して関連付けて、当該第１の取引ＩＤで特定される第１の取引の状態を示す状態情報をも、前記取引情報記憶手段に登録するものであることを特徴とするプログラムを記録したコンピュータ読取り可能な記録媒体。
【請求項１７】
前記管理手段に含まれる一括処理手段であって、
前記取引情報記憶手段に登録されている複数の第１の取引の成立を一括して確定させるべき旨の指示を、前記クライアントコンピュータから前記通信手段を介して受信した場合に、前記取引情報記憶手段において当該クライアントコンピュータの利用者に係る前記客ＩＤと当該第１の取引が成立するか不成立となるかについて確定していないＡＣＴＩＶＥ状態を示す前記状態情報とが関連付けて登録されている前記第１の取引ＩＤで特定される複数の第１の取引の各々について、当該第１の取引の取引ＩＤと組になって前記取引情報記憶手段に登録されている前記第１の店ＩＤで特定される電子店舗に係る前記ショップコンピュータへ、それぞれ、当該第１の取引の成立を確定させるための手続きが完結可能であるか否かを問い合わせるＰＲＥＰＡＲＥメッセージを、前記通信手段を介して送信するとともに、当該複数の第１の取引の各々に関連付けて前記取引情報記憶手段に登録されている前記状態情報を、それぞれ、ＡＣＴＩＶＥ状態から、ＰＲＥＰＡＲＩＮＧ状態へ変更し、
前記複数の第１の取引の各々について、当該第１の取引に係る前記ショップコンピュータから前記通信手段を介して、前記手続きが完結可能であることを示すＰＲＥＣＯＭＭＩＴメッセージを受信したならば、当該第１の取引の取引ＩＤに関連付けて前記取引情報記憶手段に登録されている前記状態情報を、ＰＲＥＰＡＲＩＮＧ状態から、ＰＲＥＣＯＭＭＩＴＥＤ状態へ変更し、
前記複数の第１の取引の全てについて、当該第１の取引の取引ＩＤに関連付けて前記取引情報記憶手段に登録されている前記状態情報がＰＲＥＣＯＭＭＩＴＥＤ状態へ変更されたならば、前記複数の第１の取引の各々について、当該第１の取引に係る前記ショップコンピュータへ当該第１の取引の成立を確定させるための手続きを完結させることを指示するＣＯＭＭＩＴメッセージを、前記通信手段を介して送信するとともに、当該第１の取引の取引ＩＤに関連付けて前記取引情報記憶手段に登録されている前記状態情報を、ＰＲＥＣＯＭＭＩＴＥＤ状態から、ＣＯＭＭＩＴＴＩＮＧ状態へ変更し、
前記複数の第１の取引の全てについて、当該第１の取引に係る前記ショップコンピュータから前記通信手段を介して、前記手続きが完結したことを示すＣＯＭＭＩＴＴＥＤメッセージを受信したならば、当該第１の取引の取引ＩＤに関連付けて前記取引情報記憶手段に登録されている前記状態情報を、ＣＯＭＭＩＴＴＩＮＧ状態から、最終的に当該第１の取引の成立が確定したことを示すＣＯＭＭＩＴＴＥＤ状態へ変更する一括処理手段として更にコンピュータを機能させるためのプログラムを記録した請求項１６に記載の記録媒体。
【請求項１８】
前記一括処理手段は、前記一括して確定させるべき旨の指示とともに、一括して確定させる対象とすべき第１の取引の範囲に関する指示を受けた場合には、指示を受けた該範囲に含まれる第１の取引についてのみ、一括して確定させる処理の対象とするものである請求項１７に記載の記録媒体。
【請求項１９】
前記一括処理手段は、
前記複数の第１の取引のうちに、ＰＲＥＰＡＲＥメッセージを送信した後に、当該第１の取引に係る前記ショップコンピュータから前記通信手段を介して、前記手続きが完結不能であることを示すＡＢＯＲＴメッセージを受信したものが一つでもある場合には、ＡＢＯＲＴメッセージを受信した第１の取引の取引ＩＤに関連付けて前記取引情報記憶手段に登録されている前記状態情報を、ＰＲＥＰＡＲＩＮＧ状態から、最終的に当該第１の取引の不成立が確定したことを示すＡＢＯＲＴＥＤ状態へ変更し、
前記複数の第１の取引のうちに、当該第１の取引の取引ＩＤに関連付けて前記取引情報記憶手段に登録されている前記状態情報が既にＰＲＥＣＯＭＭＩＴＴＥＤ状態に変更されているものがあるならば、該状態情報をＰＲＥＣＯＭＭＩＴＴＥＤ状態からＡＢＯＲＴＩＮＧ状態に変更するとともに、当該第１の取引に係る前記ショップコンピュータへ当該第１の取引を取り消すための処理の実行を指示するＡＢＯＲＴメッセージを、前記通信手段を介して送信し、
ＡＢＯＲＴＩＮＧ状態に変更された前記複数の第１の取引の各々について、当該第１の取引に係る前記ショップコンピュータから前記通信手段を介して、前記処理が完結したことを示すＡＢＯＲＴＥＤメッセージを受信したならば、当該第１の取引の取引ＩＤに関連付けて前記取引情報記憶手段に登録されている前記状態情報を、それぞれ、ＡＢＯＲＴＩＮＧ状態から、ＡＢＯＲＴＥＤ状態へ変更することを特徴とする請求項１７または１８に記録媒体。
【請求項２０】
前記一括処理手段は、
前記取引情報記憶手段に登録されている複数の第１の取引の不成立を一括して確定させるべき旨の指示を、前記クライアントコンピュータから前記通信手段を介して受信した場合に、前記取引情報記憶手段において当該クライアントコンピュータの利用者に係る前記客ＩＤとＡＣＴＩＶＥ状態を示す前記状態情報とが関連付けて登録されている前記第１の取引ＩＤで特定される複数の第１の取引の各々について、当該第１の取引の取引ＩＤと組になって前記取引情報記憶手段に登録されている前記第１の店ＩＤで特定される電子店舗に係るショップコンピュータへ、それぞれ、当該第１の取引を取り消すための処理の実行を指示するＡＢＯＲＴメッセージを、前記通信手段を介して送信するとともに、当該複数の第１の取引の取引ＩＤに関連付けて前記取引情報記憶手段に登録されている前記状態情報を、それぞれ、ＡＣＴＩＶＥ状態から、ＡＢＯＲＴＩＮＧ状態へ変更し、
ＡＢＯＲＴＩＮＧ状態に変更された前記複数の第１の取引の各々について、当該第１の取引に係る前記ショップコンピュータから前記通信手段を介して、前記処理が完結したことを示すＡＢＯＲＴＥＤメッセージを受信したならば、当該第１の取引の取引ＩＤに関連付けて前記取引情報記憶手段に登録されている前記状態情報を、それぞれ、ＡＢＯＲＴＩＮＧ状態から、最終的に当該第１の取引の不成立が確定した状態を示すＡＢＯＲＴＥＤ状態へ変更することを特徴とする請求項１７ないし１９のいずれか１項に記載の記録媒体。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、インターネット等で電子的な取引を行うためのトランザクション管理装置、トランザクション管理方法及び記録媒体に関する。
【０００２】
【従来の技術】
インターネット上での電子店舗システムあるいは電子商取引システム等の多くは、ＷＷＷ（ＷＯＲＬＤ  ＷＩＤＥ  ＷＥＢ）システムをベースにして構築されている。電子店舗で買物や予約などをしたい客の使うクライアントコンピュータでは、ＷＥＢブラウザ（あるいは単にブラウザ）と呼ばれるソフトウェアが動作する。客はＷＥＢブラウザからインターネットを介して商品の購入などをしたい電子店舗のショップコンピュータに接続し、商品情報の閲覧や、商品の購入手続きなどを行う。
【０００３】
ショップコンピュータ上では、電子店舗の機能を実行するプログラムが動作し、例えば、客に対して商品の説明や価格を提示したり、客からの注文を受けて在庫の確認、支払いの処理、配送の手配などの販売処理を行う。また、顧客との過去の取引履歴を管理して、顧客に合った商品提案や優待販売などのサービスをする場合もある。ショップコンピュータは、例えばクレジットカードの決済などを行う際などには、他のサービス会社のコンピュータと通信することもある。
【０００４】
クライアントコンピュータ上のＷＥＢブラウザとショップコンピュータ上の電子店舗プログラムは、ＨＴＴＰと呼ばれるＷＷＷの標準の通信プロトコルで通信する。ＨＴＴＰプロトコルは、ＵＲＬと呼ばれる処理要求の識別子と、必要に応じてその要求に付随する情報をリクエストとして送ると、処理結果を表示するＨＴＭＬドキュメント等のデータがリプライとして返される、１組のリクエスト／リプライが通信の基本単位になる。電子商取引では、リクエストはクライアントコンピュータからショップコンピュータに向けて送られ、リプライはショップコンピュータからクライアントコンピュータへ向けて送られる。
【０００５】
通常、インターネット上のいわゆる電子商取引における手続きの開始から終了までには、複数回のリクエスト／リプライの組が必要になる。書籍の販売の場合を考えてみると、クライアントコンピュータ上のＷＥＢブラウザとショップコンピュータ上のプログラムの間で、一例として次のようなリクエスト／リプライのシーケンスが必要になる。
（１）欲しい本の名前をリクエストとして送る。
（２）在庫や価格の情報がリプライとして返される。
（３）購入希望を伝えるリクエストを送る。
（４）支払いや配送に関する情報の入力フォームがリプライとして返される。
（５）フォームに必要な情報を記述してリクエストとして送る。
（６）手続きの完了がリプライとして返される。
【０００６】
このような一纏まりの処理をするために必要になる一連のリクエスト／リプライの処理系列をセッションと呼ぶ。ＨＴＴＰプロトコル自身はセッションを管理する手段を持っていない。すなわち、ショップコンピュータ上のプログラムは、同時に複数の客との取引処理を進める。しかし、上記の例で、ショップコンピュータ上のプログラムがある客からの（５）の購入に必要な情報のリクエストを受け取ったときに、そのリクエストがどの客の（４）のリプライを受けたものであるかを判断する手段を、ＨＴＴＰプロトコルは持っていない。そこで通常は、例えば「ＲＦＣ２１０９：ＨＴＴＰ  Ｓｔａｔｅ  Ｍａｎａｇｅｍｅｎｔ  Ｍｅｃｈａｎｉｓｍ」に開示されているＣＯＯＫＩＥと呼ばれるメカニズムを使ってセッションを管理する。ショップコンピュータ上のプログラムは、ＣＯＯＫＩＥと呼ばれる識別用の文字列を使って、セッションを構成する複数のリクエストおよびリプライを関連付ける。
【０００７】
電子店舗を実現するショップコンピュータ上のプログラムでは、ショッピングカート機能を持つものも多い。ショッピングカート機能では、通常、客は、その電子店舗で選んだ商品をショッピングカートに入れたり、一度入れた商品を自由にカートから取り出して返品することができ、最後に例えば『購入ボタン』あるいは『決定ボタン』あるいは『確定ボタン』を押すなどすることによって、そのときにショッピングカート内に入っている複数の商品についてまとめて購入手続きをすることができるようになっている（ここでクレジット番号を入力するなどして複数の商品について一括して支払い手続きを行うことも多い）。ショッピングカート機能を実現する方式としては、ショップコンピュータ側で客毎に買った商品を記録していく方法や、クライアントコンピュータ側で自分の買った商品を記録していく方法がある。
【０００８】
以下、従来の電子商取引システムの問題点について説明する。
【０００９】
インターネット上の電子商取引システムの第１の問題点は、ＨＴＴＰプロトコルとＣＯＯＫＩＥ機構を使って、客のクライアントコンピュータと店のショップコンピュータの間のセッションを管理しているため、客にとっても店にとっても、現在進行中の取引のセッションが正しく進行しているのかエラーが発生しているのかを確認する手段が無いことである。
【００１０】
例えば、何らかの商品を購入しようとしている客が、クライアントコンピュータ上のＷＥＢブラウザから支払いに必要なクレジットカードの番号と配達先を入力して「支払」ボタンを押したとする。通常はこれで支払手続きを開始するリクエストがショップコンピュータに送られ、処理が実行され、支払手続きの完了を知らせるメッセージがリプライとして送られる。しかし、「支払」ボタンを押してもなかなかリプライが送られてこない場合、リクエストがショップコンピュータに届かなかったのか、ショップコンピュータがダウンしたのか、支払手続きは済んだがリプライがクライアントコンピュータに届かなかったのか、あるいは単に負荷が高くてまだ支払手続きが済んでいないだけで正常な状態なのか、客には判断できない。客は、もう一度「支払」ボタンを押すと２重に発注してしまうことになるのかあるいはエラーになるのかわからないし、また、支払処理が実行されたのかされていないのかわからないまま取引を終了するわけにもいかない。
【００１１】
また、ショップコンピュータ上の電子店舗プログラムにとっても同様の問題がある。例えば、客から何らかの商品の購入希望のリクエストを受け取り、その商品の在庫を確保した後、支払方法や配達先の入力を促すリプライを返したとする。通常はしばらくすると支払方法や配送先を入力したフォームがリクエストとして送られてくる。しかし、それがなかなか返ってこない場合、リプライがクライアントコンピュータに届かなかったのか、クライアントコンピュータがダウンしたのか、入力したフォームを送るリクエストがショップコンピュータに届かなかったのか、客が購入意思をなくして勝手に取引をやめたのか、あるいは客が入力フォームへの記入に手間取っているだけで正常な状態なのか、ショップコンピュータ上の電子店舗プログラムには判断できない。店は、客はまだ購入意思があるかもしれないので確保した在庫を解放するわけにもいかないし、かといって逆に、いつまでも在庫を確保しておいても客は既に購入する意思を無くしているかもしれない。
【００１２】
インターネット上の電子商取引システムの第２の問題点は、客にとっても店にとっても、現在進行中の取引のセッション中にエラーあるいはエラーかもしれない状況が発生した場合に、そのセッションに正しく復帰して取引を継続するための方法、あるいはそのセッションを正しく中断してそれまでの取引を取り消すための統一的な方法が無いことである。現在は、客にとっても店にとっても、セッションを一方的に放棄するしかない。
【００１３】
このような状況に対処するために、ショップコンピュータの電子店舗プログラムにおいて、現在進行中の取引を無効にさせるための機能を用意するなどの対策も考えられる。しかし、この方法が使えるのは、クライアントコンピュータからショップコンピュータに再接続することが可能な場合に限られるため、取引をしていた店のアドレス（ＵＲＬ）を覚えている必要があり、また、ショップコンピュータの障害に対しては対処できない。
【００１４】
インターネット上で電子商取引をする客と店の両方にとって、取引の途中で何らかのエラーあるいはエラーかもしれない状況が発生したときに、どの電子店舗と取引している場合でも同じ手順で取引を正しく継続あるいは中断するための統一的な方法が必要である。
【００１５】
インターネット上の電子商取引システムの第３の問題点は、複数の電子店舗での買い物をまとめて決済できるショッピングカート機能が無いことである。
【００１６】
同じ電子店舗内では複数の商品を購入してまとめて決済を済ませるショッピングカート機能が広く使われている。また、同じ電子ショッピングモール内ならば複数の電子店舗の商品を入れられるショッピングカート機能が実現されている。しかし、これらの既存の機能では、異なる電子店舗での購入をまとめることはできない。
【００１７】
例えば、旅行の手配をするために、Ａホテルで宿泊の予約をし、Ｂエアラインで航空券の予約をする場合、この２つの両方が予約できる場合には購入したいが、どちらかが満員で予約できない場合はどちらも購入したくない。現在のインターネット上の電子商取引システムでこのような買い物の仕方をしようと思えば、ＡホテルとＢエアラインが同じショッピングモールに店を出していて、かつそのショッピングモールがモール内の複数店舗の商品を入れられるショッピングカートを提供している必要がある。
【００１８】
上記の例のように相互に依存する買い物ではない場合でも、複数の電子店舗での買い物をまとめることができるショッピングカート機能があると、支払のために必要な手続きを一括して済ませることができて非常に便利である。
【００１９】
インターネット上の電子商取引システムの第４の問題点は、過去の取引の履歴や、現在進行中の取引の状態を一元的に管理する手段が無いことである。
【００２０】
電話の場合は電話局に記録が管理されているので、希望すれば自分がかけた電話の記録を入手することができる。クレジットカードの場合もカード会社には利用記録が残っており、自分の利用記録の明細書を入手することができる。しかし、インターネットでの電子商取引の場合には、このように一元的に利用記録を管理するサービスが無い。
【００２１】
例えば、自分が今まで何処の電子店舗で何を買ったかを調べたい場合、ショッピングカートには入っているがまだ決済が完了していないものを調べたい場合、発注したものがどういう状態にあるのか知りたい場合などに、参照できる記録を自動的に取る機能がない。現在は、このような過去の取引の記録は、客自身が自主的に管理するしか方法がない。
【００２２】
【発明が解決しようとする課題】
以上説明してきたように、従来のシステムでは、セッションエラーを検出できない、セッション途中の障害に対して復帰あるいは中断する（統一的な）手段がない、異なるショップを跨って使えるショッピングカートがない、異なるショップを跨った取引履歴等の管理機能がないといった種々の問題点があった。
【００２３】
本発明は、上記事情を考慮してなされたもので、複数の電子店舗に跨ったグローバルなショッピングカートを可能にしたトランザクション管理装置、トランザクション管理方法及び記録媒体を提供することを目的とする。
【００２６】
【課題を解決するための手段】
本発明に係るトランザクション管理装置は、ネットワーク上で電子店舗を提供するショップコンピュータ及び電子店舗を利用する利用者の使用するクライアントコンピュータと通信するための通信手段と、前記電子店舗と前記利用者との間で当該電子店舗に係る前記ショップコンピュータと当該利用者に係る前記クライアントコンピュータとの通信を介して進行中である第１の取引について、該第１の取引を特定するための第１の取引ＩＤと、該第１の取引に係る電子店舗を識別するための第１の店ＩＤとの組を、当該電子店舗に係る前記ショップコンピュータから、前記通信手段を介して取得する第１の取得手段と、取得した前記第１の取引ＩＤと前記第１の店ＩＤとの組が登録される取引情報記憶手段と、第２の取引を特定するため第２の取引ＩＤと該第２の取引に係る電子店舗を識別するための第２の店ＩＤとの組を、前記クライアントコンピュータから、前記通信手段を介して取得する第２の取得手段と、前記クライアントコンピュータから前記通信手段を介して取得する、当該クライアントコンピュータに係る前記利用者を識別するための客ＩＤを使って、前記利用者の認証を行う認証手段と、前記第１の取得手段により前記ショップコンピュータから取得し前記取引情報記憶手段に登録した前記第１の取引ＩＤと前記第１の店ＩＤとの組が、前記第２の取得手段により前記クライアントコンピュータから取得した前記第２の取引ＩＤと前記第２の店ＩＤとの組と同じである場合に、前記認証手段により認証された、当該クライアントコンピュータの利用者に係る前記客ＩＤを、前記取引情報記憶手段に登録された前記第１の取引ＩＤと前記第１の店ＩＤとの組に対して関連付けて前記取引情報記憶手段に登録する管理手段とを備え、前記管理手段は、前記第１の取引ＩＤと前記第１の店ＩＤとの組に対して関連付けて、当該第１の取引ＩＤで特定される第１の取引の状態を示す状態情報をも、前記取引情報記憶手段に登録するものであることを特徴とする。
好ましくは、前記取引情報記憶手段に登録されている複数の第１の取引の成立を一括して確定させるべき旨の指示を、前記クライアントコンピュータから前記通信手段を介して受信した場合に、前記取引情報記憶手段において当該クライアントコンピュータの利用者に係る前記客ＩＤと当該第１の取引が成立するか不成立となるかについて確定していないことを示すＡＣＴＩＶＥ状態を示す前記状態情報とが関連付けて登録されている前記第１の取引ＩＤで特定される複数の第１の取引の各々について、当該第１の取引の取引ＩＤと組になって前記取引情報記憶手段に登録されている前記第１の店ＩＤで特定される電子店舗に係る前記ショップコンピュータへ、それぞれ、当該第１の取引の成立を確定させるための手続きが完結可能であるか否かを問い合わせるＰＲＥＰＡＲＥメッセージを、前記通信手段を介して送信するとともに、当該複数の第１の取引の各々に関連付けて前記取引情報記憶手段に登録されている前記状態情報を、それぞれ、ＡＣＴＩＶＥ状態から、ＰＲＥＰＡＲＩＮＧ状態へ変更し、前記複数の第１の取引の各々について、当該第１の取引に係る前記ショップコンピュータから前記通信手段を介して、前記手続きが完結可能であることを示すＰＲＥＣＯＭＭＩＴメッセージを受信したならば、当該第１の取引の取引ＩＤに関連付けて前記取引情報記憶手段に登録されている前記状態情報を、ＰＲＥＰＡＲＩＮＧ状態から、ＰＲＥＣＯＭＭＩＴＥＤ状態へ変更し、前記複数の第１の取引の全てについて、当該第１の取引の取引ＩＤに関連付けて前記取引情報記憶手段に登録されている前記状態情報がＰＲＥＣＯＭＭＩＴＥＤ状態へ変更されたならば、前記複数の第１の取引の各々について、当該第１の取引に係る前記ショップコンピュータへ当該第１の取引の成立を確定させるための手続きを完結させることを指示するＣＯＭＭＩＴメッセージを、前記通信手段を介して送信するとともに、当該第１の取引の取引ＩＤに関連付けて前記取引情報記憶手段に登録されている前記状態情報を、ＰＲＥＣＯＭＭＩＴＥＤ状態から、ＣＯＭＭＩＴＴＩＮＧ状態へ変更し、前記複数の第１の取引の全てについて、当該第１の取引に係る前記ショップコンピュータから前記通信手段を介して、前記手続きが完結したことを示すＣＯＭＭＩＴＴＥＤメッセージを受信したならば、当該第１の取引の取引ＩＤに関連付けて前記取引情報記憶手段に登録されている前記状態情報を、ＣＯＭＭＩＴＴＩＮＧ状態から、最終的に当該第１の取引の成立が確定したことを示すＣＯＭＭＩＴＴＥＤ状態へ変更する一括処理手段を、前記管理手段が含むようにしてもよい。
好ましくは、前記一括処理手段は、前記一括して確定させるべき旨の指示とともに、一括して確定させる対象とすべき第１の取引の範囲に関する指示を受けた場合には、指示を受けた該範囲に含まれる第１の取引についてのみ、一括して確定させる処理の対象とするようにしてもよい。
好ましくは、前記一括処理手段は、前記複数の第１の取引のうちに、ＰＲＥＰＡＲＥメッセージを送信した後に、当該第１の取引に係る前記ショップコンピュータから前記通信手段を介して、前記手続きが完結不能であることを示すＡＢＯＲＴメッセージを受信したものが一つでもある場合には、ＡＢＯＲＴメッセージを受信した第１の取引の取引ＩＤに関連付けて前記取引情報記憶手段に登録されている前記状態情報を、ＰＲＥＰＡＲＩＮＧ状態から、最終的に当該第１の取引の不成立が確定したことを示すＡＢＯＲＴＥＤ状態へ変更し、前記複数の第１の取引のうちに、当該第１の取引の取引ＩＤに関連付けて前記取引情報記憶手段に登録されている前記状態情報が既にＰＲＥＣＯＭＭＩＴＴＥＤ状態に変更されているものがあるならば、該状態情報をＰＲＥＣＯＭＭＩＴＴＥＤ状態からＡＢＯＲＴＩＮＧ状態に変更するとともに、当該第１の取引に係る前記ショップコンピュータへ当該第１の取引を取り消すための処理の実行を指示するＡＢＯＲＴメッセージを、前記通信手段を介して送信し、ＡＢＯＲＴＩＮＧ状態に変更された前記複数の第１の取引の各々について、当該第１の取引に係る前記ショップコンピュータから前記通信手段を介して、前記処理が完結したことを示すＡＢＯＲＴＥＤメッセージを受信したならば、当該第１の取引の取引ＩＤに関連付けて前記取引情報記憶手段に登録されている前記状態情報を、それぞれ、ＡＢＯＲＴＩＮＧ状態から、ＡＢＯＲＴＥＤ状態へ変更するようにしてもよい。
好ましくは、前記一括処理手段は、前記取引情報記憶手段に登録されている複数の第１の取引の不成立を一括して確定させるべき旨の指示を、前記クライアントコンピュータから前記通信手段を介して受信した場合に、前記取引情報記憶手段において当該クライアントコンピュータの利用者に係る前記客ＩＤとＡＣＴＩＶＥ状態を示す前記状態情報とが関連付けて登録されている前記第１の取引ＩＤで特定される複数の第１の取引の各々について、当該第１の取引の取引ＩＤと組になって前記取引情報記憶手段に登録されている前記第１の店ＩＤで特定される電子店舗に係るショップコンピュータへ、それぞれ、当該第１の取引を取り消すための処理の実行を指示するＡＢＯＲＴメッセージを、前記通信手段を介して送信するとともに、当該複数の第１の取引の取引ＩＤに関連付けて前記取引情報記憶手段に登録されている前記状態情報を、それぞれ、ＡＣＴＩＶＥ状態から、ＡＢＯＲＴＩＮＧ状態へ変更し、ＡＢＯＲＴＩＮＧ状態に変更された前記複数の第１の取引の各々について、当該第１の取引に係る前記ショップコンピュータから前記通信手段を介して、前記処理が完結したことを示すＡＢＯＲＴＥＤメッセージを受信したならば、当該第１の取引の取引ＩＤに関連付けて前記取引情報記憶手段に登録されている前記状態情報を、それぞれ、ＡＢＯＲＴＩＮＧ状態から、最終的に当該第１の取引の不成立が確定したことを示すＡＢＯＲＴＥＤ状態へ変更するようにしてもよい。
【００３０】
なお、装置に係る本発明は方法に係る発明としても成立し、方法に係る本発明は装置に係る発明としても成立する。
また、装置または方法に係る本発明は、コンピュータに当該発明に相当する手順を実行させるための（あるいはコンピュータを当該発明に相当する手段として機能させるための、あるいはコンピュータに当該発明に相当する機能を実現させるための）プログラムを記録したコンピュータ読取り可能な記録媒体としても成立する。
【００３１】
本発明によれば、利用者のクライアントコンピュータと電子店舗のショップコンピュータとの間の取引情報は、トランザクション管理コンピュータに記録して管理され、取引の成立又は不成立を確定させるための処理は、利用者の指示によりトランザクション管理コンピュータの管理下で実行される。
【００３２】
そのため、クライアントコンピュータに障害が発生した場合でも、クライアントコンピュータをトランザクション管理コンピュータへ再接続することによって、進行中の取引を継続することができる。
【００３３】
また、ショップコンピュータの障害や、ネットワークの切断やパケット紛失等の障害の場合も、トランザクション管理コンピュータの提供する障害回復機能によって、決済に必要なトランザクション管理コンピュータとショップコンピュータの間のメッセージを再送して決済処理を継続することができる。
【００３４】
その結果、障害が発生してもトランザクション管理コンピュータによって回復処理が行われるので、利用者も電子店舗も安心して電子商取引を行うことができる。
【００３５】
また、利用者はトランザクション管理コンピュータをショッピングカートとして使って、複数の異なる電子店舗での取引を一括して処理することができる。
【００３６】
また、トランザクション管理コンピュータを、利用者自身の過去の取引履歴の記録として活用することができる。
【００３７】
【発明の実施の形態】
以下、図面を参照しながら発明の実施の形態を説明する。
【００３８】
以下では、インターネット上のいわゆる電子店舗などにおける商取引を例にとって説明するが、もちろん、本発明は、インターネット以外のネットワークにも適用可能であり、また、商取引に該当しない取引あるいは契約を扱うシステムにも適用可能である。
【００３９】
図１に、本発明の一実施形態に係る電子商取引システムのネットワーク構成例を示す。
【００４０】
本電子商取引システムは、インターネット６に接続した、トランザクション管理サービス（ＴＭＳ）事業者のトランザクション管理コンピュータ１、複数の電子店舗サービス事業者のショップコンピュータ２、および電子店舗サービスの利用者側の複数のクライアントコンピュータ３を含んで構成される。
【００４１】
以下では、利用者とはクライアントコンピュータ３のユーザを意味するものとする。利用者は、インターネット６上の電子店舗サービスを客として利用して、商品の購入あるいは宅配サービスの注文あるいは座席や部屋の予約あるいは或物の賃貸など所望の取引を行うために（すなわち通常は自己が代金等の金銭債務を負担する側になる所望の双務契約を締結するために）、クライアントコンピュータ３を操作する。
【００４２】
電子店舗サービスを利用するために利用者が使用するクライアントコンピュータ３上では、ＷＥＢブラウザが動作する。利用者は、ＷＥＢブラウザからインターネット６を介して、商品の購入等を行いたい所望の電子店舗サービスを提供する所望のショップコンピュータ２に接続し、ＷＥＢブラウザに表示されたページ画面を閲覧し、必要に応じてデータを入力し、各種ボタンを押すなどの作業・操作を繰り返すことによって（両コンピュータ間での各種要求の送信や応答の受信などのやり取りを通じて）、電子店舗サービスを利用する（例えば、商品情報の閲覧や商品の購入手続き等を行う）。もちろん、ＷＥＢブラウザではなく、電子店舗サービスを利用するための専用のソフトウェアなどの他のものを用いても構わないが、本実施形態ではＷＥＢブラウザを例にとって説明することとする。
【００４３】
また、クライアントコンピュータ３は、トランザクション管理コンピュータ１やショップコンピュータ２と通信するための手段（例えば通信ソフトや通信インタフェース装置等）を持つ。
【００４４】
なお、クライアントコンピュータ３は、図示しないインターネット・サービス・プロバイダ経由でインターネット６に接続されるものであってもよいし、インターネット・サービス・プロバイダを介さずにインターネット６に接続されているものであってもよい。
【００４５】
ショップコンピュータ２上では、電子店舗プログラムが動作し、クライアントコンピュータ３の利用者に対して、例えば商品販売サービスのサイトでは商品やサービスの内容の説明やその価格の提示、利用者からの注文を受けての在庫の確認、支払いの処理、配送の手配といった販売処理を行うなど、サイトごとに様々な電子店舗サービスを提供する。ショップコンピュータ２上の電子店舗プログラムは、必要な情報、例えば商品のカタログに関する情報、在庫に関する情報、個々の取引の内容に関する情報、実際の支払や配達に関する情報などをデータベースに管理しながら処理を進める。
【００４６】
また、ショップコンピュータ２は、トランザクション管理コンピュータ１やクライアントコンピュータ３と通信するための手段（例えば通信ソフトや通信インタフェース装置等）を持つ。
【００４７】
トランザクション管理コンピュータ１は、概略的には、電子店舗サイトを越えて利用できるグローバルなショッピングカートを提供する（以下、このグローバルなショッピングカートを単にショッピングカートと呼び、電子店舗サイト内のショッピングカートをローカルなショッピングカートと呼ぶ）。利用者は、後述するような手続きによって、ショッピングカート内に、ある電子店舗において現在進行中の取引を保留することができる。なお、ショッピングカート内に保留されている取引は、利用者の電子店舗に対する一定の手続きを経ていて取引内容自体は（全てまたは主要部分が）定まっているが、利用者が最終的に取引の成立を確定させる意思（意図）を表示あるいは通知する（ための指示をシステムに入力する）か、当該取引をショッピングカートから破棄するすなわち当該取引の不成立を確定させる意思（意図）を表示あるいは通知する（ための指示をシステムに入力する）かが待たれている状態にある（後述する“ＡＣＴＩＶＥ”の状態にある）。
【００４８】
トランザクション管理コンピュータ１では、図２に示すように、クライアントコンピュータ３とショップコンピュータ２との間で行われる取引の管理を行うための（利用者にショッピングカート機能を提供するための）トランザクション管理プログラム１１が動作する。
【００４９】
また、図２に示すように、トランザクション管理コンピュータ１で動作するトランザクション管理プログラム１１は、個人情報データベース１２と取引情報データベース１３を管理している。個人情報データベース１２には、取引の際に必要になる登録している利用者の個人情報（氏名の他、必要に応じて、電話番号、住所、銀行の口座番号およびまたはクレジットカード番号、電子メールアドレスなど）が記録されている。取引情報データベース１３には、現在進行中の取引（すなわちショッピングカートの中に保留されている取引）に関する情報が記録されるとともに、履歴サービスを提供する場合には、過去の取引（当該ショッピングカートを利用して成立した取引）の履歴に関する情報が記録される。これらのデータベースには、重要なデータが記録されるので、障害によってデータが消えたりすることの無いように、データベース管理システムによってＡＣＩＤ（Ａｔｏｍｉｃｉｔｙ、Ｃｏｎｃｕｒｒｅｎｃｙ、Ｉｓｏｌａｔｉｏｎ、Ｄｕｒａｂｉｌｉｔｙ）性を保証して管理するように実施することが望ましい。
【００５０】
また、トランザクション管理コンピュータ１は、ショップコンピュータ２やクライアントコンピュータ３と通信するための手段（例えば通信ソフトや通信インタフェース装置等）を持つ。
【００５１】
本実施形態では、利用者は、トランザクション管理コンピュータ１によるトランザクション管理サービス（のショッピングカート）を利用してショップコンピュータ２による電子店舗サービスを受けることも、トランザクション管理サービスを利用せずに電子店舗サービスを受けることも可能である。トランザクション管理サービスを利用する場合、まず、利用者が電子店舗のページを介して操作を行うことによって（利用者と電子店舗側の契約主体との間の）取引の内容が定まり、利用者が例えばＷＥＢブラウザに表示された電子店舗のページ上の『トランザクション管理サービスを利用するためのボタン』を押すことによって、その内容の取引の成立が保留された状態になり、その後、利用者が例えばＷＥＢブラウザに表示されたトランザクション管理サービスのページ上の『取引の成立を確定させるためのボタン』を押すことによって、当該内容の取引の成立を確定させるための処理（当該取引についての手続きを有効に完結させるための処理）が開始され、一方、『取引の不成立を確定させるためのボタン』を押すことによって、当該内容の取引の不成立を確定させるための処理（当該取引に係るこれまでの手続きを取り消すあるいは破棄するための処理）が開始される。また、トランザクション管理サービスを利用する場合、詳しくは後述するように、利用者は、まず、複数の取引をショッピングカートに保持（保留）し、その後、それら取引の成立または不成立を一括して確定させることができる（個別に取引の成立または不成立を確定させることも可能である）。
【００５２】
なお、以下の説明では、既存の電子店舗でよく行われているように指定口座からの引き落としなどにより決済する場合を例にとっていることから、決済の面を強調して、『取引の成立を確定させるためのボタン』を、『決済ボタン』（『一括決済ボタン』、『個別決済ボタン』）と呼んでページ画面上に表示している（図１４参照）。もちろん、商品引き渡し時に代金を支払い、あるいは飛行機に搭乗する日にカウンターで料金を支払い、あるいは宿泊後に料金を支払うような取引にも適用可能である（サイトに応じて処理を行えばよい）。また、ボタンの名前としては、例えば、『確認ボタン』、『確定ボタン』、『決定ボタン』、『申込みボタン』など、他の名称でも構わない。また、売買でない取引が含まれていたとしても（利用者に誤解が生じなければ）、『購入ボタン』などと表示しても構わない。また、ボタン以外のＧＵＩ部品を用いても構わない。なお、ＧＵＩ部品に代えてまたはＧＵＩ部品とともに、音声による入力を可能としてもよい。
【００５３】
また、『取引の不成立を確定させるためのボタン』を、『取消ボタン』（『一括取消ボタン』、『個別取消ボタン』）と呼んでページ画面上に表示している（図１４参照）が、上記と同様に、他の名称でも構わないし、ボタン以外のＧＵＩ部品を用いても構わない。なお、ＧＵＩ部品に代えてまたはＧＵＩ部品とともに、音声による入力を可能としてもよい。
【００５４】
また、トランザクション管理コンピュータ１の管理する取引情報データベース１３（図９参照）では、利用者が１つまたは複数の取引について最終的に『取引の成立を確定させるためのボタン』すなわち本具体例では『一括決済ボタン』または『個別決済ボタン』を押した日時（または該ボタンを押したことによってクライアントコンピュータ３から送信された情報をトランザクション管理コンピュータ１が受信した日時）を記録するフィールドを、『（一括／個別）決済ボタン』の名称に対応させて、「決済日時」と呼んでいるが、これは、例えば、「確認日時」、「確定日時」、「決定日時」、「申込日時」など、他の名称でも構わない。
【００５５】
また、以下の説明では、電子店舗を利用してホテルの部屋等の予約を行う場合を例にとって説明することから、システム上、『トランザクション管理サービスを利用するためのボタン』を『ＴＭＳで予約するボタン』あるいは『ＴＭＳで支払いボタン』、トランザクション管理サービスを利用しない場合に押すボタンを『予約するボタン』あるいは『支払いボタン』と呼んでページ画面上に表示している（図８参照）。例えば、商品売買のサイトの場合には、ボタンの名前は、『ＴＭＳで購入するボタン』などとすればよい。また、ボタンの名前は、『ＴＭＳのショッピングカートを利用するボタン』、『商品をＴＭＳのショッピングカートに入れるボタン』など、他の名称でも構わない。また、ボタン以外のＧＵＩ部品を用いても構わない。なお、ＧＵＩ部品に代えてまたはＧＵＩ部品とともに、音声による入力を可能としてもよい。
【００５６】
ところで、クライアントコンピュータ３の利用者がショップコンピュータ２によって提供される電子店舗サービスを利用する形態としては、会員制はとらずに当該サイトを無条件に誰でも使用できるものとする形態の他に、会員制はとらないが一定の条件を満たすもののみ当該サイトを使用できる形態、当該サイトの有料の会員になった利用者のみを対象とする形態、当該サイトの会員と非会員とで受けられるサービスの内容を異ならせた形態など種々の形態が可能である。また、当該サイトの利用料の形態としては、無償とする形態の他に、会員サービスを利用する利用者が例えば毎月ごとに基本登録料を支払う形態など種々の形態が可能である。
【００５７】
クライアントコンピュータ３の利用者がトランザクション管理コンピュータ１によって提供されるトランザクション管理サービスを利用する形態や当該サイトの利用料の形態は上記と同様である。ただし、本実施形態では、クライアントコンピュータ３の利用者がトランザクション管理コンピュータ１のトランザクション管理サービスを利用する前に、あるいは利用する際に、当該利用者に関する情報をトランザクション管理コンピュータ１の個人情報データベース１２に登録するための手続きがなされるものとする。
【００５８】
ショップコンピュータ２の電子店舗サービス事業者がトランザクション管理コンピュータ１によって提供されるトランザクション管理サービスを利用する形態としては、本実施形態では、当該トランザクション管理サービス事業者と契約した電子店舗サービス事業者のみが使用できる形態の他に、無条件にまたは一定の条件を満たす電子店舗サービス事業者が使用できる形態など他の形態も可能である。また、当該サイトの利用料の形態としては、無償とする形態も、有償とする形態も可能である。後者の場合には、電子店舗サービス事業者が一定の契約料を支払う形態、電子店舗サービス事業者が当該サイトによるトランザクション管理サービスを通じて成立した取引の内容に応じて手数料を支払う形態など種々の形態が可能である。
【００５９】
以下、本実施形態について具体例を用いながら詳しく説明する。
【００６０】
具体例として、図３に示すように、ある利用者Ｙが、そのクライアントコンピュータ３上のＷＥＢブラウザを操作して、札幌Ａホテルのショップコンピュータ２と日本Ｂエアラインのショップコンピュータ２がインターネット６上で提供している電子店舗サービスを利用するとともに、その際、トランザクション管理コンピュータ１が提供しているトランザクション管理サービスを利用して、３月１０日に東京から飛行機で札幌へ行って２泊して３月１２日に帰ってくる旅行の手配（日本Ｂエアラインの東京札幌間の往復の航空便の座席および札幌Ａホテルの３月１０日、１１日の２泊分の部屋の予約）を行う場合を例にする。
【００６１】
なお、図３において、トランザクション管理サービス・サイトにはトランザクション管理コンピュータ１が設置されており、トランザクション管理コンピュータ１上のトランザクション管理プログラム１１は“ｈｔｔｐ：／／ｗｗｗ．ｔｍｓ．ｓｏｍｅｎｅｔ／”というＵＲＬで接続することができるものとする。また、札幌Ａホテルのショップコンピュータ２は“ｈｔｔｐ：／／ｗｗｗ．ｓａｈ．ｓｏｍｅｎｅｔ／”というＵＲＬで、日本Ｂエアラインのショップコンピュータ２は“ｈｔｔｐ：／／ｗｗｗ．ｊｂａ．ｓｏｍｅｎｅｔ／”というＵＲＬでそれぞれ接続することができるものとする。
【００６２】
ここでは、利用者は、札幌Ａホテルと日本Ｂエアラインの両方を同時に予約できるときのみ予約を行い、どちらか一方だけしか予約できないときは両方とも予約しない場合を考える。
【００６３】
以下、利用者がこのような予約のための操作を行う場合について、クライアントコンピュータ３とショップコンピュータ２とトランザクション管理コンピュータ１の間の情報の流れや、クライアントコンピュータ３の表示画面上に表示されるページの流れを参照しながら説明する。
【００６４】
なお、ここで示す実施形態では、クライアントコンピュータ３とショップコンピュータ２とトランザクション管理コンピュータ１の間の通信は、ＨＴＴＰプロトコルで行われるものとする。また、必要に応じてＳＳＬ（Ｓｅｃｕｒｅ  Ｓｏｃｋｅｔ  Ｌａｙｅｒ）などの手段を使ってセキュリティを高めることが望ましい。
【００６５】
まず、利用者が、クライアントコンピュータ３（例えば自分のコンピュータ）のＷＥＢブラウザを使って、札幌Ａホテルを予約する手続きから始める。このときの処理の流れは図４のようになる。
【００６６】
利用者は、札幌Ａホテルのホームページへ接続するために、ＷＥＢブラウザに札幌ＡホテルのＵＲＬ（この例では、ｈｔｔｐ：／／ｗｗｗ．ｓａｈ．ｓｏｍｅｎｅｔ／）を打ち込むと、ＧＥＴリクエスト（図４の［２］）が札幌Ａホテルのショップコンピュータ２に送られ、その結果、該ショップコンピュータ２から札幌Ａホテルのホームページが送り返され（図４の［３］）、クライアントコンピュータ３上のＷＥＢブラウザには例えば図５のように表示される。
【００６７】
利用者は、図５のホームページから、宿泊を予約したり、ホテル内の施設の情報を閲覧したりすることができる。ここでは、シングルルームの予約をしたいので『予約』ボタンを押すと（図４の［４］）、シングルルームの予約ページのＧＥＴリクエストが札幌Ａホテルのショップコンピュータ２に送られ（図４の［５］）、それに答えて該ショップコンピュータ２からシングルルームの予約ページが送り返され（図４の［６］）、クライアントコンピュータ３上のＷＥＢブラウザには例えば図６のように表示される。
【００６８】
こうして表示されたページに対して、図７のように予約内容である宿泊希望日と宿泊数（ここでは３月１０日から２泊）を入力し（図４の［７］）、『空室確認』ボタンを押すと予約確認のためのＧＥＴリクエストが送られる（図４の［８］）。このＧＥＴリクエストには予約内容が“ｄａｔｅ＝０３１０＆ｄａｙ＝２”というＵＲＬのクエリとして指定されている。
【００６９】
このＧＥＴリクエストを受け取った札幌Ａホテルのショップコンピュータ２は、空室状況をチェックし、予約を受けられれば、予約確認のページを送り返し（図４の［１０］）、クライアントコンピュータ３上のＷＥＢブラウザには例えば図８のように表示される。
なお、空室状況をチェックした結果、もし満室で予約を受けられない場合には、札幌Ａホテルのショップコンピュータ２からその旨を表示するためのページが送られ、クライアントコンピュータ３上のＷＥＢブラウザにその旨が表示される。
【００７０】
図８の予約確認ページの内容でよければ、予約する手続を開始する。図８では、『予約する』と『ＴＭＳで予約する』の２つのボタンが並んでいる。トランザクション管理コンピュータ１のトランザクション管理サービス（のショッピングカート機能）を利用する場合には『ＴＭＳで予約する』ボタンを押し、トランザクション管理サービスを利用しない場合には『予約する』ボタンを押すものとする。
【００７１】
『予約する』ボタンを押した場合、従来通り、当該クライアントコンピュータ３と当該ショップコンピュータ２との間で予約のための手続きを行う（必要に応じて支払のための銀行の口座番号もしくはクレジットカード番号の入力なども行う）。
【００７２】
この例では、利用者は、取引をショッピングカート内に保留させるために、『ＴＭＳで予約する』ボタンを押すことになる。
【００７３】
利用者が図８の予約確認ページで『ＴＭＳで予約する』ボタンを押すと（図４の［１１］）、トランザクション管理コンピュータ１を使って予約するためのＧＥＴリクエストが札幌Ａホテルのショップコンピュータ２に送られる（図４の［１２］）。なお、ここでは、予約内容（この例では、“ｄａｔｅ＝０３１０＆ｄａｙ＝２”）もＵＲＬのクエリとして送っているが、ＣＯＯＫＩＥ等の機構を使って、予約内容をショップコンピュータ２側に覚えておくように実装することもできる。
【００７４】
この『ＴＭＳで予約する』ボタンによるＧＥＴリクエストを受け取った札幌Ａホテルのショップコンピュータ２は、予約内容（取引内容）をデータベースに記録する（図４の［１３］）。このとき、この予約を識別するための取引ＩＤを発行し、予約内容を取引ＩＤと対応付けて記録しておく。ショップコンピュータ２とトランザクション管理コンピュータ１の間では、この取引ＩＤを使って個々の取引を識別する。トランザクション管理コンピュータ１側では、具体的な取引内容（例えば、上記の予約内容や、商品売買の場合における商品ＩＤとその個数など）は知る必要がない。
【００７５】
なお、『予約する』ボタンによるＧＥＴリクエストを受け取った場合には、従来通り、その時点で、当該予約がなされたことが確定し、該利用者のために予約日に部屋を確定的に確保するための処理がなされることになるが、『ＴＭＳで予約する』ボタンによるＧＥＴリクエストを受け取った場合には、利用者による取引の取り消しが留保されているので、当該予約がなされたことが確定せず、該利用者のために予約日に部屋を確定的に確保するための処理がなされることにはならない。ただし、本実施形態では、各電子店舗において、『ＴＭＳで予約する』ボタンによるＧＥＴリクエストを受け取った際に、当該内容の予約が後に不能に転じないように、該利用者のために予約日に部屋を仮に確保しておき、後に利用者が例えば『一括決済ボタン』（図２５参照）を押したことなどによって、当該予約がなされたことが確定されたときに、当該取引の成立を確定させるための処理において、この仮の確保を確定的な確保に更新するための処理を行う（当該取引の不成立の確定の際には、仮の確保を解放する）ようにするものとする。
【００７６】
さて、ショップコンピュータ２は、また、トランザクション管理コンピュータ１に登録されている自分の店ＩＤと取引ＩＤの組を、トランザクション管理コンピュータ１に登録する（図４の［１４］）。ここでは、札幌Ａホテルの店ＩＤは“ｓａｈ”であるものとし、今回の予約の取引ＩＤは“１０２９３”であるとする。
【００７７】
トランザクション管理コンピュータ１の管理する取引情報データベース１３は、例えば、図９に示すようなテーブルとして実装される。テーブルの各行は一つの取引情報を記録しており、図９の例では各行は８個のフィールドから構成される。
「客ＩＤ」は、その取引に係る利用者の識別子を保持するフィールドである。「店ＩＤ」は、その取引に係る電子店舗の識別子を保持するフィールドである。なお、１つのショップコンピュータ２が複数の異なる電子店舗を持っていてもよい。
「取引ＩＤ」は、各々の取引を識別する情報を保持するフィールドである。  「決済日時」は、利用者が『一括決済』ボタンまたは『個別決済』ボタン（図２５参照）を押した日時（あるいは該ボタンが押されたことを契機としてクライアントコンピュータ３から送信されたメッセージを受信した日時）を記録するフィールドである。なお、この「決済日時」フィールドは、後で説明するように、該当する取引の状態が“ＣＯＭＭＩＴＴＥＤ”になるまでは、最後に取引の状態を変更した時刻や、障害時にメッセージを再送した時刻を記録するためにも使用される。このような、該当する取引の状態が“ＣＯＭＭＩＴＴＥＤ”になるまでの状態が変化した時刻を記録するために、別のフィールドを用意するようにしてもよい。
「登録日時」は、その取引がトランザクション管理コンピュータ１に登録された日時を記録するフィールドである。
「状態」は、その取引がどのような状態にあるかを示している。図９の例では、“ＣＯＭＭＩＴＴＥＤ”は取引が成立した状態、“ＡＢＯＲＴＥＤ”は一旦ショッピングカートに入れられた後に取り消された状態、“ＡＣＴＩＶＥ”は現在取引が進行中で取引の成立が確定していない状態（ショッピングカート内に保留されている状態）であることをそれぞれ示している。
「カートメッセージ」フィールドは、その取引の内容に関する情報で、利用者個人用のショッピングカートページに取引の情報を表示する際に利用される。  「完了メッセージ」は、取引成立時の処理が完了したときの電子店舗から利用者へのメッセージを記録するフィールドである。従って、「状態」が“ＡＢＯＲＴＥＤ”の取引は完了メッセージを持たない。
【００７８】
図９は、トランザクション管理コンピュータ１が、札幌Ａホテルから、店ＩＤが“ｓａｈ”で且つ取引ＩＤが“１０２９３”の取引情報を受け取り、それを登録した直後の取引情報データベース１３の状態を示している。図９の最初の行がこの取引に対応しており、まだ客ＩＤと対応付けられておらず、取引の成立もなされていないので、客ＩＤと決済日時は空で、状態は“ＡＣＴＩＶＥ”である。カートメッセージの内容は、店ＩＤと取引ＩＤを登録するメッセージに付随して送られてくるものとする。
【００７９】
なお、クライアントコンピュータ３からショップコンピュータ２へ客ＩＤまたはこれを特定可能な情報を送信するなどによって、ショップコンピュータ２が客ＩＤを取得可能とし、ショップコンピュータ２からトランザクション管理コンピュータ１へ店ＩＤと取引ＩＤとともに客ＩＤをも送信し、この時点で、取引情報データベース１３に客ＩＤをも登録してしまうような構成も可能である。
【００８０】
このようにして取引情報データベース１３への登録が終わると、トランザクション管理コンピュータ１は登録完了をショップコンピュータ２へ知らせる（図４の［１６］）。
【００８１】
トランザクション管理コンピュータ１から登録完了を受け取るとショップコンピュータ２は、クライアントコンピュータ３に対して、店ＩＤ（ｓａｈ）と取引ＩＤ（１０２９３）をもってトランザクション管理コンピュータ１に接続するようにＨＴＴＰプロトコルのリダイレクトを指示する（図４の［１７］）。本実施形態では、ショップコンピュータ２は、クライアントコンピュータ３に対して、店ＩＤと取引ＩＤをクエリに持つトランザクション管理コンピュータ１のＵＲＬを指定して、リダイレクトを指示している。
【００８２】
リダイレクトの指示を受け取ったクライアントコンピュータ３は、指示されたトランザクション管理コンピュータ１のＵＲＬ（この例では、ｈｔｔｐ：／／ｗｗｗ．ｔｍｓ．ｓｏｍｅｎｅｔ／）へＧＥＴリクエストを送る（図４の［１８］）。
【００８３】
クライアントコンピュータ３からのＧＥＴリクエストを受け取ったトランザクション管理コンピュータ１は、まず、利用者の認証を行うために、客ＩＤとパスワードの入力を促す（図４の［１９］）。このときにクライアントコンピュータ１には例えば図１０のように表示される。これに従って利用者は客ＩＤとパスワードを入力（図１１参照）すると（図４の［２０］）、その情報がトランザクション管理コンピュータ１に送られ（図４の［２１］）、トランザクション管理コンピュータ１は個人情報データベース１２を参照して利用者の認証を行う（図４の［２２］）。
【００８４】
トランザクション管理コンピュータ１の管理する個人情報データベース１２は、例えば、図１２に示すような構造のテーブルとして実施できる。テーブルの各行は一つの個人情報を記録しており、図１２の例では各行は７個のフィールドから構成される。
「客ＩＤ」フィールドは、その利用者に与えられた一意の識別名である。
「パスワード」フィールドは、その利用者を認証するためのパスワードである。
「名前」フィールドには、利用者の名前が記録される。
「住所」フィールドには、利用者の住所等が記録される。
「電話番号」フィールドには、利用者の電話番号等が記録される。
「メールアドレス」フィールドには、利用者の電子メールのアドレスが記録される。
「口座番号」フィールドには、代金の引き落としなどに使う銀行の口座番号が記録されている。
【００８５】
個人情報データベース１２には、他にも様々な情報が記録されるように実施してよい。代金の支払方法によっては、例えばクレジットカードの番号を記録しておくフィールドなどを設けるように実施することもできる。逆に、代金の支払方法には関与せず、口座番号やクレジットカードの番号などのフィールドを持たない構成もあり得る。
【００８６】
ここでは、利用者から送られてきた客ＩＤとパスワードから、客ＩＤを使って個人情報データベース１２を検索し、そこに記録されているパスワードと送られてきたパスワードとを比較することで認証を行う。
【００８７】
なお、認証方式はここで示した方式以外にも様々な方式があり、どのような方式を用いるように実装しても構わない。認証方式によっては、個人情報データベース１２にパスワードを直接記録しない場合もあるし、その他の必要な情報を記録する場合もある。
【００８８】
なお、ここでは、以降、利用者のクライアントコンピュータ３のＷＥＢブラウザが起動中は、利用者の認証は不要であり、クライアントコンピュータ３がダウンし再起動したことなどによって、ＷＥＢブラウザが再起動となった際には、あらためて、利用者の認証が必要になる場合を例にとっている。
【００８９】
さて、トランザクション管理コンピュータ１では、利用者の認証が終わると、接続してきた利用者の客ＩＤがわかる。この例の場合、客ＩＤは“ｈｉｒｏｓｈｉ．ｙａｍａｄａ”である。リクエストに付随してきた店ＩＤと取引ＩＤを使って、取引情報データベース１３から対応する取引情報を検索し、その取引情報の客ＩＤフィールドは空のままであるので、そこに接続してきた利用者の客ＩＤを記録する（図４の［２３］）。そうすると取引情報データベース１３は、図１３のような状態になる。図９の状態からの変化は、客ＩＤが埋まっていることである。
【００９０】
取引情報データベース１３への登録が完了すると、トランザクション管理コンピュータ１は、取引情報データベース１３の中から、接続してきた利用者の客ＩＤを持つ取引情報を取り出し、その情報を表示するショッピングカートページを作成してクライアントコンピュータ３へ送り返す（図４の［２４］）。
【００９１】
このショッピングカートページをクライアントコンピュータ３のＷＥＢブラウザが表示すると例えば図１４のようになる。図１４には、“ＡＣＴＩＶＥ”状態にある取引（すなわち、現在取引が進行中で取引の成立が確定していない状態である取引）の情報が『現在のショッピングカートの内容』として表示されている。ここでは、先ほど手続きした札幌Ａホテルの電子店舗での取引情報がショッピングカートに入っており、それに対して『決済』あるいは『取消』を行うボタンが用意されている。このショッピングカート画面における個々の取引情報の表示には、トランザクション管理コンピュータ１の取引情報データベース１３の「カートメッセージ」フィールドの値が用いられる。この画面では、過去の取引の情報も、画面の下の方にある『今月（１９９９年１２月）分』ボタン等を押すと、該当する情報を表示する画面を開くことができる。
【００９２】
なお、これまでに説明した実施形態では、取引ＩＤはショップコンピュータ２が発行していたが、取引ＩＤをトランザクション管理コンピュータ１が発行するように実施することもできる。この場合、ショップコンピュータ２が店ＩＤをトランザクション管理コンピュータ１に伝えると、トランザクション管理コンピュータ１は新しく発行した取引ＩＤと受け取った店ＩＤの組を取引情報データベース１３に登録し、発行した取引ＩＤをショップコンピュータ２に返すようにする。取引ＩＤを受け取ったショップコンピュータ２は、その取引ＩＤと取引内容の情報とを関連付けてデータベースに記録しておくようにする。
【００９３】
さて、札幌Ａホテルを予約することだけが目的であれば、図１４の画面で『（一括または個別）決済』ボタンを押せばよいが、ここでは、さらに飛行機の予約のための一定の手続きを行い、その結果、所望する全ての予約が可能となったならば、ショッピングカート機能を利用して、全ての予約について一括して取引成立させようとすることになる（この例では『一括決済』ボタンを押すことになる）。一方、飛行機の予約が取れなければ、すべて予約しないことになる（この例では既にショッピングカート内にある札幌Ａホテルについて『個別取消』ボタンまたは『一括取消』ボタンを押すことになる）。
【００９４】
そこで、利用者は、次に、クライアントコンピュータ３（例えば自分のコンピュータ）のＷＥＢブラウザを使って、日本Ｂエアラインののインターネット予約ページで飛行機を予約するための手続きに移る。このときの処理の流れは図１５のようになる。
【００９５】
利用者は、日本Ｂエアラインのホームページへ接続するために、ＷＥＢブラウザに日本ＢエアラインのＵＲＬ（この例では、ｈｔｔｐ：／／ｗｗｗ．ｊｂａ．ｓｏｍｅｎｅｔ／）を打ち込むと、ＧＥＴリクエスト（図１５の［２６］）が日本Ｂエアラインのショップコンピュータ２に送られ、その結果、該ショップコンピュータ２から日本Ｂエアラインのホームページが送り返され（図１５の［２７］）、クライアントコンピュータ３上のＷＥＢブラウザには例えば図１６のように表示される（この例ではホームページが予約ページであるものとした）。
【００９６】
利用者は、図１６の予約入力ページに対して、図１７に示すように、予約したい日と発着地および人数（この例では、３月１０日に、東京から札幌まで、１人分）を入力する（図１５の［２８］）。入力が完了した後に『空席確認』ボタンを押すと、空席確認処理のＧＥＴリクエストが日本Ｂエアラインのショップコンピュータ２に送られる（図１５の［２９］）。この例では、ＵＲＬのクエリ部分に予約したい日や発着地や人数の情報が指定されている。リクエストを受け取った日本Ｂエアラインのショップコンピュータ２は、指定された便の空席状況を調べ（図１５の［３０］）、予約のためのページを作成してクライアントコンピュータ３に送り直す（図１５の［３１］）。このページはクライアントコンピュータ３上のＷＥＢブラウザに例えば図１８のように表示される。
なお、札幌Ａホテルの例と同様に、空席状況をチェックした結果、もし満席で予約を受けられない場合には、日本Ｂエアラインのショップコンピュータ２からその旨を表示するためのページが送られ、クライアントコンピュータ３上のＷＥＢブラウザにその旨が表示される。
【００９７】
図１８の画面で空席状況を見ると、ＪＢＡ１３５便とＪＢＡ１４１便に空席があることが分かるので、ここではＪＢＡ１３５便を選んでその『予約』ボタンを押す（図１５の［３２］）。すると、ＪＢＡ１３５便を予約するためのＧＥＴリクエストが日本Ｂエアラインのショップコンピュータ２に送られる（図１５の［３３］）。ここでは、ＵＲＬのクエリ部に、予約したい便名と日と発着地と人数の情報を持たせているが、先に予約確認の際に送った予約したい日と発着地と人数の情報をショップコンピュータ２側で覚えておくように実施してもよい。リクエストを受け取った日本Ｂエアラインのショップコンピュータ２は、予約内容を予約番号（Ｃ１０１３５０９７）とともにデータベースに登録し（図１５の［３４］）、予約確認ページをクライアントコンピュータ３に送り返す（図１５の［３５］）。このとき、本実施形態では、ＣＯＯＫＩＥを使って予約番号を一緒に送り返し、ＷＥＢブラウザが予約番号を覚えておく。こうして送られてきた予約確認ページはクライアントコンピュータ３上のＷＥＢブラウザに例えば図１９のように表示される。
【００９８】
なお、札幌Ａホテルの例と同様の理由で、図１８の『予約』ボタンによるＧＥＴリクエストを受け取った際に、当該内容の予約が後に不能に転じないように、該利用者のために予約日に座席を仮に確保するための処理を行い、後に当該取引の成立の確定の際に、仮の確保を確定的な確保に更新するための処理を行う（当該取引の不成立の確定の際には、仮の確保を解放する）ようにするものとする。
【００９９】
さて、図１９のページの表示を見ると、このときに、利用者は、『続いて予約』ボタンを押して他の便の予約を続けることを選択することも、『ＴＭＳで支払い』ボタンを押してトランザクション管理コンピュータ１によるトランザクション管理サービスを利用して手続きすることを選択することも、『支払い』ボタンを押して従来通りトランザクション管理サービスを利用せずに手続きすることを選択することもできるようになっている。
【０１００】
この例では、利用者は、『続いて予約』ボタンを押して帰りの便の予約を続けることになる。
【０１０１】
利用者が図１９の画面で『続いて予約』ボタンを押すと（図１５の［３６］）、先ほどと同様に、予約ページのＧＥＴリクエストが日本Ｂエアラインのショップコンピュータ２に送られる（図１５の［３７］）。そのリクエストに答えて送られてきた（図１５の［３８］）予約ページを表示すると、例えば図１６のようになる。なお、図２０のように、当該サイト内におけるローカルなショッピングカート内の情報を提示するようにしてもよい。
【０１０２】
利用者は図１６（あるいは図２０）の予約入力ページに対して、図２１に示すように、予約したい日と発着地および人数（この例では、３月１２日に、札幌から東京まで、１人分）を入力する（図１５の［３９］）。入力が完了した後に『空席確認』ボタンを押すと、空席確認処理のＧＥＴリクエストが日本Ｂエアラインのショップコンピュータ２に送られる（図１５の［４０］）。リクエストを受け取った日本Ｂエアラインのショップコンピュータ２は、指定された便の空席状況を調べ（図１５の［４１］）、予約のためのページを作成して送り返す（図１５の［４２］）。このページが例えば図２２のように表示される。
【０１０３】
図２２の画面を見ると、ＪＢＡ２４０便とＪＢＡ２４６便に空席があることが分かるので、ここではＪＢＡ２４６便を選んで『予約』ボタンを押す（図１５の［４３］）。すると、ＪＢＡ２４６を予約するためのＧＥＴリクエストが日本Ｂエアラインのショップコンピュータ２に送られる（図１５の［４４］）。リクエストを受け取った日本Ｂエアラインのショップコンピュータ２は、予約内容を予約番号（Ｃ１２２４６１０３）とともにデータベースに登録し（図１５の［４５］）、予約確認ページを送り返す（図１５の［４６］）。このときも、ＣＯＯＫＩＥを使って予約番号を一緒に送り返し、ＷＥＢブラウザが予約番号を覚えておく。こうして送られてきた予約確認ページは、例えば図２３のように表示される。
【０１０４】
以上で、東京札幌間の往復の飛行機が予約できることになったので、当該進行中の取引（トランザクション管理コンピュータ１から見るとローカルなショッピングカートを一括した１つの取引）をトランザクション管理コンピュータ１に登録するために（ショッピングカートに入れるために）、利用者は『ＴＭＳで支払い』ボタンを押す（図１５の［４７］）。『ＴＭＳで支払い』ボタンが押されると、ＣＯＯＫＩＥを使って記憶していた予約番号（Ｃ１０１３５０９７とＣ１２２４６１０３）をクエリ部に持ったＧＥＴリクエストが、日本Ｂエアラインのショップコンピュータ２に送られる（図１５の［４８］）。
【０１０５】
この『ＴＭＳで支払い』ボタンによるＧＥＴリクエストを受け取った日本Ｂエアラインのショップコンピュータ２は、取引ＩＤ（６３７２）を発行し、予約内容（取引内容）を取引ＩＤと関連付けてデータベースに記録し（図１５の［４９］）、トランザクション管理コンピュータ１に対して、日本Ｂエアラインの店ＩＤ“ｊｂａ”と取引ＩＤ“６３７２”の組を登録するリクエストを送る（図１５の［５０］）。このリクエストには、この取引ＩＤに対応するカートメッセージも添えて送る。
【０１０６】
トランザクション管理コンピュータ１は、受け取った店ＩＤと取引ＩＤからなる取引情報を取引情報データベース１３に登録し（図１５の［５１］）、同時に送られてきたカートメッセージも併せて登録する。
【０１０７】
このようにして取引情報データベース１３への登録が終わると、ショップコンピュータ２は登録完了をショップコンピュータ２へ知らせる（図１５の［５２］）。
【０１０８】
トランザクション管理コンピュータ１から登録完了を受け取るとショップコンピュータ２は、クライアントコンピュータ３に対して、店ＩＤ（ｊｂａ）と取引ＩＤ（６３７２）をもってトランザクション管理コンピュータ１に接続するようにＨＴＴＰプロトコルのリダイレクトを指示する（図１５の［５３］）。
【０１０９】
リダイレクトの指示を受け取ったクライアントコンピュータ３は、指定されたＵＲＬ（すなわちトランザクション管理コンピュータ１のＵＲＬ）へＧＥＴリクエストを送る（図１５の［５４］）。
【０１１０】
クライアントコンピュータ３からのＧＥＴリクエストを受け取ったトランザクション管理コンピュータ１は、ここでは利用者の認証は既に終わっているので、リクエストに付随してきた店ＩＤと取引ＩＤを使って、取引情報データベース１３から対応する取引情報を検索し、その取引情報の客ＩＤフィールドは空のままであるので、そこに接続してきた利用者の客ＩＤを記録する（図１５の［５５］）。この時点で、取引情報データベース１３は、図２４のような状態になる。
【０１１１】
取引情報データベース１３への登録が完了すると、トランザクション管理コンピュータ１は、取引情報データベース１３の中から、接続してきた利用者の客ＩＤを持つ取引情報を取り出し、その情報を表示するショッピングカートページを作成して送り返す（図１５の［５６］）。
【０１１２】
このショッピングカートページをクライアントコンピュータ３のＷＥＢブラウザで表示すると例えば図２５のようになる。図２５を見ると、先に予約した札幌Ａホテルの取引情報と今予約した日本Ｂエアラインの取引情報が、ショッピングカートに入っていることがわかる。
【０１１３】
ここで、日本Ｂエアラインのショップコンピュータ２の電子店舗プログラムは、当該電子店舗内のローカルなショッピングカート機能によって、複数の便の予約をまとめて手続きする機能を持っている。このように、個々の電子店舗あるいはモールが独自にショッピングカート機能を持っている場合でも、トランザクション管理コンピュータ１はそれらを複数まとめるショッピングカートとして動作することができる。
【０１１４】
さて、以上の手続きによって希望通り札幌Ａホテルの２泊分の部屋と日本Ｂエアラインの往復分の航空便の座席の予約ができることになったので、次に、ショッピングカートの機能を利用して、一括してそれら取引の成立を確定させるための手続きを行う。図２５のページを見ると、ショッピングカートに入っている札幌Ａホテルの取引情報と日本Ｂエアラインでの取引情報の横に、それぞれ『個別決済』と『個別取消』の２つのボタンが並んでいる。これらは、現在ショッピングカート中にある進行中の取引に対して、個別に取引の成立または不成立を確定させるためのボタンである。それらの上方には、『一括決済』と『一括取消』の２つのボタンが並んでいる。これらは、現在ショッピングカート中にある進行中の取引に対して、全部まとめて取引の成立または不成立を確定させるためのボタンである。
【０１１５】
ここでは、『一括決済』ボタンを押して札幌Ａホテルと日本Ｂエアラインの両方の取引をまとめて手続きする場合の処理の流れを説明する。このときの処理の流れは図２６のようになる。
【０１１６】
まず、利用者は、図２５のショッピングカート画面で『一括決済』ボタンを押す（図２６の［５７］）。すると、クライアントコンピュータ３からトランザクション管理コンピュータ１に対して、一括処理を指示するＧＥＴリクエストが送られる（図２６の［５８］）。リクエストを受け取ったトランザクション管理コンピュータ１は、利用者をまだ認証していない場合には認証の処理を行う。ここでは既に認証の処理は終わっているので（図４の［１９］、［２０］、［２１］、［２２］）省略する。
【０１１７】
次に、トランザクション管理コンピュータ１は、認証済みの客ＩＤを使って、取引情報データベース１３から利用者の取引情報で状態フィールドの値が“ＡＣＴＩＶＥ”のものを一括処理の対象として検索し（図２６の［５９］）、それらの取引の確定処理を、図２７に示すような状態遷移に従って、ショップコンピュータ２と通信しながら進めていく。
【０１１８】
図２７の状態遷移は、取引情報データベース１３中の各取引情報が、状態フィールドに記録している状態の遷移を表している。基本的な原理は、広く使われている分散トランザクションの２相コミットプロトコルと同様である。
【０１１９】
ショップコンピュータ２から新しく登録された取引情報は、まず、“ＡＣＴＩＶＥ”状態として取引情報データベース１３に入る。通常は、利用者により一括処理が指示されると（例えば『一括決済』ボタンが押されると）、一括処理対象となる“ＡＣＴＩＶＥ”状態になっている全ての取引の状態を“ＰＲＥＰＡＲＩＮＧ”に変更するとともに、各取引の相手となるショップコンピュータ２の各々に対して、「当該取引についての手続きを有効に完結可能かどうか」を問い合わせるＰＲＥＰＡＲＥメッセージを送る。
【０１２０】
なお、「当該取引についての手続きを有効に完結可能かどうか」とは、例えば、（１）ショップコンピュータ２の通信機能以外のシステム上のトラブルが発生して必要な処理ができないか、そういうことはなくシステムは正常かという点、（２）システム外の何らかの事態の発生によって当該取引が成立不能になったか、そういうことはなく成立可能かという点、（３）当該電子店舗が利用者の銀行の口座番号あるいはクレジットカード番号等から実際に指定口座からの引き落とし等による決済が可能かどうかを調査し、決済可能でないときは取引の成立を拒否する場合における、当該決済が可能かどうかという点、（４）当該電子店舗がショッピングカート内の当該取引に係る商品の在庫の確保あるいは部屋の確保等を保証するシステムではない場合に、ショッピングカート内に当該取引を入れるに際しては成立可能であった当該取引が現時点でも成立可能かどうかという点などの、最終的に取引の成立を確定させることを阻害する要因がないかどうかということである。そして、そのような阻害要因がなく取引の成立が可能である場合に、当該取引のための手続きを有効に完結可能と判断する。
【０１２１】
ショップコンピュータ２は、当該取引についての手続きの完結が可能ならば、ＰＲＥＣＯＭＭＩＴメッセージを送り返してくるので、その取引の状態を“ＰＲＥＣＯＭＭＩＴＥＤ”に変更する。
【０１２２】
その後、一括処理対象となっている全ての取引（本具体例では２つの取引）に対してＰＲＥＣＯＭＭＩＴメッセージが送り返されてきたならば、各取引の状態を“ＣＯＭＭＩＴＴＩＮＧ”に変更し、該当する各々のショップコンピュータ２に対してＣＯＭＭＩＴメッセージを送って、該当する取引についての手続きを完結させること（すなわち、該当する取引の成立を確定させるための処理の実行）を指示する。ショップコンピュータ２は当該取引の成立を確定させるために当該サイトにおいて必要な処理が終わるとＣＯＭＭＩＴＴＥＤメッセージを返してくるので、当該取引の状態を“ＣＯＭＭＩＴＴＥＤ”に変更する。一括処理対象となっている全ての取引の状態が“ＣＯＭＭＩＴＴＥＤ”に変更されたならば一括処理は完了となる。
【０１２３】
ここで、ＰＲＥＰＡＲＥメッセージを受け取ったショップコンピュータ２は、当該取引についての手続きの完結が不可能である場合は、当該取引を取り消しするための処理を行い、ＡＢＯＲＴメッセージを送ってくるので、当該取引の状態は“ＡＢＯＲＴＥＤ”に変更する。このとき、一括処理対象となっている他の取引のうちにその状態が“ＰＲＥＣＯＭＭＩＴＴＥＤ”になっているものがあれば、該取引については、その状態を“ＡＢＯＲＴＩＮＧ”に変更した後に、該当するショップコンピュータ２にＡＢＯＲＴメッセージを送って、当該取引を取り消すための処理の実行を指示する。当該取引の取り消し（破棄）が完了すれば、ショップコンピュータ２はＡＢＯＲＴＥＤメッセージを送ってくるので、該取引の状態を“ＡＢＯＲＴＥＤ”に変更する。一括処理対象となっている全ての取引の状態が“ＡＢＯＲＴＥＤ”に変更されたならば一括処理は完了となる。
【０１２４】
なお、利用者から個別処理が指示された場合（例えば『個別決済』ボタンが押された場合）、一括処理と同様に二相コミット処理を行ってもよいが、後述する一相コミットを行ってもよい。
【０１２５】
利用者自身が自発的に取引を取り消す場合（例えばショッピングカートページにおいて『一括取消』ボタンや『個別取消』ボタンが押された場合）やトランザクション管理コンピュータ１が自動的に予め定められた基準に従った判断に基づいて取引を取り消するか否かを判断する構成を採用したたときに、取引を取り消すと判断した場合には、取り消すべき取引の状態を“ＡＣＴＩＶＥ”から“ＡＢＯＲＴＩＮＧ”に変更した後に、ショップコンピュータ２にＡＢＯＲＴメッセージを送り、該当する取引の取り消しが完了したショップコンピュータ２からＡＢＯＲＴＥＤメッセージが返ってきたら、該取引の状態を“ＡＢＯＲＴＥＤ”にする。一括取消の場合には、一括処理対象となっている全ての取引の状態が“ＡＢＯＲＴＥＤ”に変更されたならば一括取消は完了となる。
【０１２６】
なお、トランザクション管理コンピュータ１とショップコンピュータ２の間の通信は、ＨＴＴＰプロトコルを使ってもよいし、独自のプロトコルを使っても構わない。ＨＴＴＰプロトコルを使う場合も、例えばＰＲＥＰＡＲＥメッセージとＰＲＥＣＯＭＭＩＴメッセージをＨＴＴＰのリクエストとリプライに対応させるように実施してもよいし、ＰＲＥＰＡＲＥメッセージとＰＲＥＣＯＭＭＩＴメッセージをそれぞれ別のＨＴＴＰのリクエストとして送るように実施してもよい。なお、トランザクション管理コンピュータ１とショップコンピュータ２の通信は、必要に応じて認証するなどの対策によってセキュリティを高めるように実施することが望ましい。
【０１２７】
さて、取引情報データベース１３から状態フィールドの値が“ＡＣＴＩＶＥ”になっている取引情報を検索したトランザクション管理コンピュータ１は、まず、それら一括処理の対象となる取引情報の状態フィールドの値を“ＰＲＥＰＡＲＩＮＧ”に変更するとともに、決済日時フィールドに現在の日時を記録する（図２６の［６０］）。決済日時フィールドに現在の日時を記録するのは、後で述べるように、一括処理の途中で一定の時間以上処理が進まないものを取り消すためのタイムアウトの判断に使うためである。こうして取引情報データベース１３の内容は、図２８に示すようになる。
【０１２８】
その後、一括処理対象のすべての取引情報に関して、その取引を行ったショップコンピュータ２に、その取引の取引ＩＤを持たせたＰＲＥＰＡＲＥメッセージを送る（図２６の［６１］、［６２］）。ここで、ＰＲＥＰＡＲＥメッセージの送り先を決定するためには、取引情報データベース１３に記録されている店ＩＤから、それに対応するショップコンピュータ２を見つける必要がある。本実施形態では、トランザクション管理コンピュータ１上のトランザクション管理プログラム１１が、あらかじめ店ＩＤとそれに対応するショップコンピュータ２（のＵＲＬ等）との対応表を持っているように実施しているものとする。
【０１２９】
ＰＲＥＰＡＲＥメッセージを受け取ったショップコンピュータ２の各々は、メッセージに指定されている取引ＩＤの取引の情報をそのデータベースの中から検索し、該当する取引についての手続きを有効に完結させることが可能かどうか（すなわち、該当する取引の成立を確定させることが可能か、あるいは何らかの要因によって取引の成立は不可能か）をチェックする（図２６の［６３］、［６４］）。完結可能であることが分かれば、トランザクション管理コンピュータ１に対して、取引ＩＤを持たせたＰＲＥＣＯＭＭＩＴメッセージを送り返す（図２６の［６５］、［６６］）。
【０１３０】
ＰＲＥＣＯＭＭＩＴメッセージを受け取ったトランザクション管理コンピュータ１は、該当する取引情報の状態を“ＰＲＥＰＡＲＩＮＧ”から“ＰＲＥＣＯＭＭＩＴＴＥＤ”に変更する。一括処理対象のすべての取引の状態が“ＰＲＥＣＯＭＭＩＴＴＥＤ”になれば、それら全ての取引の成立を確定させることが可能であることが確認できたので、それら取引の状態を“ＰＲＥＣＯＭＭＩＴＴＥＤ”から“ＣＯＭＩＴＴＩＮＧ”に変更するとともに、決済日時フィールドに現在の日時を記録し（図２６の［６７］）、それら取引の相手となる各々のショップコンピュータ２に対して、該当する取引の取引ＩＤを持たせたＣＯＭＭＩＴメッセージを送って、該当する取引についての手続きを完結させること（すなわち、該当する取引の成立を確定させるための処理の実行）を指示する（図２６の［６８］、［６９］）。
このとき、本実施形態では、ＣＯＭＭＩＴメッセージには、当該サイトにおける手続きに必要な利用者の個人情報（例えば、利用者の名前の他、必要に応じて、配送先の住所、電話番号、代金引き落としの口座番号など）を一緒に持たせて送るように実施するものとする。この場合、予めサイトごとに送信すべき個人情報の項目を登録しておき、必要な項目のみ送信する方法や、サイトごとに管理せずに全てのサイトに同一の個人情報を送信してしまう方法などがある。利用者の個人情報を、ＣＯＭＭＩＴメッセージではなく、ＰＲＥＰＡＲＥメッセージに一緒に持たせるようにしてもよい。
【０１３１】
なお、ここでは、指定口座またはクレジットカードによる決済を行う電子店舗側で、そのための手続きを行う場合を例にとっているが、電子店舗側ですべき決済のための手続きをすべてトランザクション管理サービス事業者側（トランザクション管理コンピュータ１側）で代行ようにすることも可能であるし、予め取り決めた電子店舗についてのみ手続きを代行するようにすることも可能である。
【０１３２】
ＣＯＭＭＩＴメッセージを受け取ったショップコンピュータ２の各々は、メッセージに指定されている取引ＩＤの取引の情報をそのデータベースの中から検索し、ＣＯＭＭＩＴメッセージと一緒に送られてきた利用者の個人情報を使って、当該取引の成立を確定させるために当該サイトにおいて必要な処理を行う（図２６の［７０］、［７１］）。この処理が完了すれば、トランザクション管理コンピュータ１に対して、取引ＩＤを持たせたＣＯＭＭＩＴＴＥＤメッセージを送り返す（図２６の［７２］、［７３］）。このとき、本実施形態では、ＣＯＭＭＩＴＴＥＤメッセージに、完了メッセージを一緒に持たせて送るように実施する。完了メッセージは、取引の完了を伴う店から利用者へのメッセージである。
【０１３３】
ＣＯＭＭＩＴＴＥＤメッセージを受け取ったトランザクション管理コンピュータ１は、該当する取引情報の状態を“ＣＯＭＭＩＴＴＩＮＧ”から“ＣＯＭＭＩＴＥＤ”に変更するとともに、決済日時フィールドに現在の日時を記録する（図２６の［７４］）。このとき、ＣＯＭＭＩＴＴＥＤメッセージと一緒に送られてきた完了メッセージを、取引情報データベース１３中の該当する取引の完了メッセージフィールドに記録しておく。一括処理対象のすべての取引の状態が“ＣＯＭＭＩＴＴＥＤ”になれば、すべての手続きが完了したので、利用者への完了通知ページをクライアントコンピュータ３へ送り返す（図２６の［７５］）。この時点で、トランザクション管理コンピュータ１の管理する取引情報データベース１３の内容は、図２９のようになっている。本実施形態では、完了通知ページには、該当する取引を行ったショップコンピュータ２から送られてきた完了メッセージを埋め込むように実施する。
【０１３４】
この完了通知メッセージが埋め込まれた完了通知ページを受け取った利用者のクライアントコンピュータ３では、それをＷＥＢブラウザに表示すると、例えば図３０のような情報が表示される。
【０１３５】
図２６に示した処理の例は、トランザクション管理コンピュータ１がショップコンピュータ２に対して送ったＰＲＥＰＡＲＥメッセージに対して、すべてのショップコンピュータ２がＰＲＥＣＯＭＭＩＴメッセージを返してきた正常な場合を示している。正常でない場合には、いずれかのショップコンピュータ２はＰＲＥＣＯＭＭＩＴメッセージではなくＡＢＯＲＴＥＤメッセージを返してくる。この場合、トランザクション管理コンピュータ１は、前述のように、ＰＲＥＣＯＭＭＩＴメッセージを返してきた取引をすべてアボートして取り消してしまうように実施することができるが、別の方法としては、ＰＲＥＣＯＭＭＩＴメッセージを返してきた取引はアボートせずにコミット処理を続けて手続きを完結させてしまう（取引の成立を確定させてしまう）ように実施することもできる。また、利用者に問い合わせて、すべてを取り消すか、完結可能な取引だけを成立させるか、あるいは、完結可能な取引のうちから利用者が指定した取引だけを成立させるかなどを、適宜、使用者に選択させるように実施することもできる。
【０１３６】
本実施形態では、図２５の例に示すように、ショップコンピュータ２中のすべての取引についてアトミックに成立または不成立を確定させることを指示するボタン以外に、個々の取引を単独で成立または不成立を確定させることを指示するボタンも提供している。本発明では、その他の様々な決済方法を用いることが可能である。例えば、ショッピングカート中のすべての取引で完結可能なものは成立させ、完結不可能なものは取り消す方法を提供し、利用者に対して、どのような方法で成立または不成立を確定させるかを選ばせるように実施することもできる。また、これらを組み合わせて実施することも可能である。
【０１３７】
また、ショッピングカート内の複数の取引を、一括処理させる１または複数の取引群ごとにグルーピングを設定することができるようにしてもよい。さらに、一括処理させる１または複数のグルーピングを指定して、一括処理を指示できるようにしてもよい。
【０１３８】
図２６に示した処理の例は、トランザクション管理コンピュータ１を、従来から広く使われている２相コミット方式で複数の取引についてアトミックに成立または不成立を確定させるように実施したものであるが、２相コミットの代わりに、１相コミットを使うようにトランザクション管理コンピュータ１を実施することもできる。この場合の一括処理の例を図３１に示す。
【０１３９】
この場合も、まず、利用者は図２５のショッピングカート画面で『一括決済』ボタンを押すと（図３１の［５７］）、するとクライアントコンピュータ３からトランザクション管理コンピュータ１に対して、一括処理を指示するＧＥＴリクエストが送られる（図３１の［５８］）。
【０１４０】
次に、トランザクション管理コンピュータ１は、認証済みの客ＩＤを使って、取引情報データベース１３から利用者の取引情報で状態フィールドの値が“ＡＣＴＩＶＥ”のものを一括処理の対象として検索し（図３１の［５９］）、それらの取引を、図３２に示すような状態遷移に従って、ショップコンピュータ２と通信しながら進めていく。
【０１４１】
図３２の状態遷移は、図２７の状態遷移を１相コミットプロトコルにしたものである。
【０１４２】
ショップコンピュータ２から新しく登録された取引情報は、まず、“ＡＣＴＩＶＥ”状態として取引情報データベース１３に入る。通常は、利用者により一括処理が指示されると（例えば『一括決済』ボタンが押されると）、一括処理対象となる“ＡＣＴＩＶＥ”状態になっている全ての取引の状態を“ＣＯＭＭＩＴＴＩＮＧ”に変更するとともに、各取引の相手となるショップコンピュータ２の各々に対して、ＣＯＭＭＩＴメッセージを送って、該当する取引についての手続きを完結させること（すなわち、該当する取引の成立を確定させるための処理の実行）を指示する。ショップコンピュータ２は当該取引の成立を確定させるために当該サイトにおいて必要な処理が終わるとＣＯＭＭＩＴＴＥＤメッセージを返してくるので、当該取引の状態を“ＣＯＭＭＩＴＴＥＤ”に変更する。
【０１４３】
ここで、ＣＯＭＭＩＴＴＥＤメッセージを受け取ったショップコンピュータ２は、当該取引についての手続きの完結が不可能である場合（何らかの要因によって当該取引の成立が不可能である場合）は、当該取引を取り消すするための処理を行い、ＡＢＯＲＴメッセージを送ってくるので、当該取引の状態は“ＡＢＯＲＴＥＤ”に変更する。
【０１４４】
なお、利用者から個別処理が指示された場合（例えば『個別決済』ボタンが押された場合）、指示された取引についてのみ、この一相コミット処理を行う。
【０１４５】
利用者自身が自発的に取引を取り消す場合（例えばショッピングカートページにおいて『一括取消』ボタンや『個別取消』ボタンが押された場合）やトランザクション管理コンピュータ１における予め定められた基準に従った判断に基づいて取引を取り消す場合には、取り消すべき取引の状態を“ＡＣＴＩＶＥ”から“ＡＢＯＲＴＩＮＧ”に変更した後に、ショップコンピュータ２にＡＢＯＲＴメッセージを送り、該当する取引の取り消しが完了したショップコンピュータ２からＡＢＯＲＴＥＤメッセージが返ってきたら、該取引の状態を“ＡＢＯＲＴＥＤ”にする。一括取消の場合には、一括処理対象となっている全ての取引の状態が“ＡＢＯＲＴＥＤ”に変更されたならば一括取消は完了となる。
【０１４６】
さて、取引情報データベース１３から状態フィールドの値が“ＡＣＴＩＶＥ”になっている取引情報を検索したトランザクション管理コンピュータ１は、まず、それら一括処理の対象となる取引情報の状態フィールドの値を“ＡＣＴＩＶＥ”から“ＣＯＭＩＴＴＩＮＧ”に変更するとともに、決済日時フィールドに現在の日時を記録し（図３１の［６０］）、それら取引の相手となる各々のショップコンピュータ２に対して、その取引の取引ＩＤを持たせたＣＯＭＭＩＴメッセージを送って、該当する取引についての手続きを完結させること（すなわち、該当する取引の成立を確定させるための処理の実行）を指示する（図３１の［６１］、［６２］）。前述と同様に、このとき、本実施形態では、ＣＯＭＭＩＴメッセージには、必要な利用者の個人情報を一緒に持たせて送るように実施するものとする。
【０１４７】
ＣＯＭＭＩＴメッセージを受け取ったショップコンピュータ２の各々は、メッセージに指定されている取引ＩＤの取引の情報をそのデータベースの中から検索し、ＣＯＭＭＩＴメッセージと一緒に送られてきた利用者の個人情報を使って、当該取引の成立を確定させるために当該サイトにおいて必要な処理を行う（図３１の［６３］、［６４］）。この処理が終われば、トランザクション管理コンピュータ１に対して、取引ＩＤを持たせたＣＯＭＭＩＴＴＥＤメッセージを送り返す（図３１の［６５］、［６６］）。このとき、本実施形態では、ＣＯＭＭＩＴＴＥＤメッセージに、完了メッセージを一緒に持たせて送るように実施する。
【０１４８】
ＣＯＭＭＩＴＴＥＤメッセージを受け取ったトランザクション管理コンピュータ１は、該当する取引情報の状態を“ＣＯＭＭＩＴＴＩＮＧ”から“ＣＯＭＭＩＴＥＤ”に変更するとともに、決済日時フィールドに現在の日時を記録する（図３１の［６７］）。このとき、ＣＯＭＭＩＴＴＥＤメッセージと一緒に送られてきた完了メッセージを、取引情報データベース１３中の該当する取引の完了メッセージフィールドに記録しておく。一括処理対象のすべての取引の状態が“ＣＯＭＭＩＴＴＥＤ”になれば、すべての手続きが完了したので、利用者への完了通知ページを送り返す（図３１の［６８］）。
【０１４９】
そして、前述と同様に、この完了通知メッセージが埋め込まれた完了通知ページを受け取った利用者のクライアントコンピュータ３では、それをＷＥＢブラウザに表示すると、例えば図３０のような情報が表示される。
【０１５０】
これまでに説明した実施形態では、トランザクション管理サービスを利用して、電子店舗サービスを受ける利用者は、ＷＥＢブラウザを使って、ショップコンピュータ２とトランザクション管理コンピュータ１とに交互に接続し、すなわち、交互に表示された電子店舗のページ画面とショッピングカートのページ画面で閲覧や入力や指示を行って、取引のための手続きを続けるように実施していたが、図３３に示すように、ショップコンピュータ２に接続したショッピング用のウィンドウと、トランザクション管理コンピュータ１に接続したショッピングカート用のウィンドウとを、ディスプレイの画面上に同時に表示して、取引のための手続きを進めることができるように実施することも可能である。このように実施すると、常に現在のショッピングカートの内容が見えており、保留中の取引について成立または不成立を確定させることをせずに忘れてしまうことも防ぐことができて便利である。
【０１５１】
本実施形態では、トランザクション管理コンピュータ１の取引情報データベース１３には、そのショッピングカートを介して過去に成立した取引の情報をも記録するようにしている。利用者は、トランザクション管理コンピュータ１に接続することによって、自分の過去の取引の履歴を閲覧することができるように実施すると、トランザクション管理コンピュータ１は個人用の取引履歴の記録として利用することができる。この機能は、例えば図２５のような個人用のショッピングカートページにおいて、『今月（１９９９年１２月）分』ボタンを押すと、図３４に示すように、その月の取引の履歴が表示されるように実施することができる。さらに、図３４の例で、例えば１２月１７日の『ＲＡＰＴＯＲギフト』の情報をマウス等のポインティングデバイスでクリックすると、その取引を行ったＲＡＰＴＯＲギフトのショップコンピュータ２に接続して、その取引に関するより詳しい情報（例えば、配送の状況など）を照会することができるように実施することもできる。
【０１５２】
トランザクション管理コンピュータ１の持つ取引情報データベース１３は、データベース管理システムで管理されている永続的（パーマネント）なデータであるので、クライアントコンピュータ３やショップコンピュータ２に障害が発生しても影響を受けない。そのため、取引の途中でクライアントコンピュータ３に障害が発生し、クライアントコンピュータ３を再起動したり、あるいは別のクライアントコンピュータ３を使う場合や、ショップコンピュータ２かネットワークに障害が発生して、クライアントコンピュータ３からのリクエストに答えなくなった場合など、取引の途中で障害に遭遇した利用者は、トランザクション管理コンピュータ１に再接続することで、取引を継続することができる。
【０１５３】
例えば、図４と図１５に示すような取引を行った後、図２６に示す一括処理の手続きの開始を指示する前に(例えば、送信された図２５のページを受信する前に、あるいは受信した該ページを表示する前に、あるいは表示された該ページにおいて利用者により『一括決済ボタン』が押される前に)、クライアントコンピュータ３に障害が発生した場合、利用者は、クライアントコンピュータ３を再起動してトランザクション管理コンピュータ１に接続し、客ＩＤの認証が終わると、例えば図２５と同じ状態でショッピングカートページが表示される。ここには、クライアントコンピュータ３に障害が発生する前に進めていた取引の情報が有効に残っており（トランザクション管理コンピュータ１の取引情報データベース１３中に“ＡＣＴＩＶＥ”状態で有効に登録されており）、引き続きこのページから手続きを続ける(例えば、『一括決済ボタン』を押す)ことができる。
【０１５４】
ここで、例えばクライアントコンピュータ３の修理が必要で数日たってからトランザクション管理コンピュータ１に再接続したような場合には、進行中の取引は長時間放置されることになり、問題が生じる。そこで、成立確定前の取引がショッピングカート中に一定時間以上放置されている場合には、該取引をトランザクション管理コンピュータ１によって強制的に取り消させるように実施することもできる。このような場合、再接続したクライアントコンピュータ３には例えば図３５に示すように取引が取り消された旨が通知されるように実施することができる。
【０１５５】
利用者がショッピングカート内に保留した全部または一部の取引について最終的に取引の成立または不成立を確定させるために例えば『一括決済ボタン』あるいは『個別決済ボタン』あるいは『一括取消ボタン』あるいは『個別取消ボタン』を押すなどして、クライアントコンピュータ３からトランザクション管理コンピュータ１に対し要求が出された後に、トランザクション管理コンピュータ１から最終的な結果を受け取る前にクライアントコンピュータ３に障害が発生した場合も、同様に再接続して、最終的な結果を確認することができる。この場合、トランザクション管理コンピュータ１は、利用者が一括処理要求等の指示を出したことを取引情報データベース１３の状態として記録しているので、クライアントコンピュータ３の状況にかかわらず、独自に処理を進めてよい。このとき、完了メッセージは取引情報データベース１３に保存される。そして、クライアントコンピュータ３に障害が発生したために、この時点では完了通知ページをクライアントコンピュータ３に送り返せなかったとしても、クライアントコンピュータ３がトランザクション管理コンピュータ１へ再接続した後に、完了メッセージを含む完了通知ページを利用者に送信して、結果を通知することが可能になる。
【０１５６】
以下では、本実施形態のトランザクション管理コンピュータ１上で動作するトランザクション管理プログラム１１の動作の例をフローチャートを使って説明する。
【０１５７】
トランザクション管理プログラム１１の動作は、大きく、
（１）クライアントコンピュータ３からのショッピングカートページ要求に対する処理
（２）クライアントコンピュータ３からの一括処理要求に対する処理
（３）クライアントコンピュータ３からの取り消し要求に対する処理
（４）障害回復処理
の４つからなる。
【０１５８】
（１）クライアントコンピュータ３からのショッピングカートページ要求に対する処理
利用者がクライアントコンピュータ３からトランザクション管理コンピュータ１へ接続してショッピングカートページを要求した場合の処理の流れは、図３６のようになる。
【０１５９】
まず、既に認証されている利用者からの接続であるかどうかを調べ（図３６のステップＳ１）、まだ認証していなければ利用者に客ＩＤとパスワードを入力させて認証する（図３６のステップＳ２）。
【０１６０】
次に、接続リクエストが店ＩＤと取引ＩＤを持っているかどうかを調べる（図３６のステップＳ３）。クライアントコンピュータ３がトランザクション管理コンピュータ１にショッピングカートページを要求するのは、ショップコンピュータ２からリダイレクトされてきた場合と、障害後や過去の取引履歴閲覧のために自発的に再接続してきた場合とに分けられる。前者の場合には、店ＩＤと取引ＩＤを持っているので、それを使って取引情報データベース１３を検索し、見つかった取引情報の客ＩＤフィールドに、認証した客ＩＤを記録する（図３６のステップＳ４）。
【０１６１】
その後、認証した客ＩＤを使って、その利用者の取引情報を取引情報データベース１３から検索し、その利用者個人用のショッピングカートページを作成し（図３６のステップＳ５）、それをクライアントコンピュータ３に送り返す（図３６のステップＳ６）。
【０１６２】
このように処理することによって、ショップコンピュータ２からリダイレクトされてきた場合でも、自発的に再接続してきた場合でも、常に最新のショッピングカートの情報を利用者に提示することが可能になる。
【０１６３】
（２）クライアントコンピュータ３からの一括処理要求に対する処理
利用者がクライアントコンピュータ３からトランザクション管理コンピュータ１へ接続してショッピングカート中の取引について一括処理を要求した場合（例えば、『一括決済ボタン』を押した場合）の処理の流れは、図３７のようになる。このときも必要に応じて認証を行うが、ここでは既に認証されているものとして省略している。
【０１６４】
まず、取引情報データベース１３において、利用者によって一括処理することを指定されたすべての取引の状態を“ＰＲＥＰＡＲＩＮＧ”に変更するとともに、現在の日時を決済日時フィールドに記録する（図３７のステップＳ１１）。
【０１６５】
次に、一括処理することを指定されたすべての取引について、その取引の相手となるショップコンピュータ２に、取引ＩＤを指定したＰＲＥＰＡＲＥメッセージを送る（図３７のステップＳ１２）。ＰＲＥＰＡＲＥメッセージに対して、ＰＲＥＣＯＭＭＩＴメッセージを返してきたら、その取引の状態は“ＰＲＥＣＯＭＭＩＴＴＥＤ”に、ＡＢＯＲＴＥＤメッセージを返してきたらその取引の状態は“ＡＢＯＲＴＥＤ”に変更し、すべてのＰＲＥＰＡＲＥメッセージの返答が返ってくるまで待つ（図３７のステップＳ１３）。
【０１６６】
すべてのＰＲＥＰＡＲＥメッセージの返答が返ってきて、その中にＡＢＯＲＴメッセージがあって“ＡＢＯＲＴＥＤ”状態になった取引があった場合には、ステップＳ１８に進んですべての取引を取り消すための処理を行い、そうでない場合にはステップＳ１５に進んですべての取引の成立を確定させるための処理を行う（図３７のステップＳ１４）。
【０１６７】
取引の成立を確定させるための処理は、まず、一括処理することを指定されたすべての取引の状態をＣＯＭＩＴＴＩＮＧに変更するとともに、現在の日時を決済日時に記録する（図３７のステップＳ１５）。次に、一括処理することを指定されたすべての取引について、その取引の相手となるショップコンピュータ２に対して、取引ＩＤを指定したＣＯＭＭＩＴメッセージを送る（図３７のステップＳ１６）。ＣＯＭＭＩＴメッセージの返答が返ってきた取引の状態を“ＣＯＭＩＴＴＥＤ”に変更するとともに、現在の日時を決済日時フィールドに記録し、すべてのＣＯＭＭＩＴメッセージの返答が返ってくるまで待つ（図３７のステップＳ１７）。
【０１６８】
取引を取り消すための処理は、まず、取り消すことを指定された取引で“ＰＲＥＣＯＭＭＩＴＴＥＤ”状態のものを“ＡＢＯＲＴＩＮＧ”状態に変更するとともに、現在の日時を決済日時に記録する（図３７のステップＳ１８）。次に、“ＡＢＯＲＴＩＮＧ”状態に変更したすべての取引について、その取引の相手となるショップコンピュータ２に対して、取引ＩＤを指定したＡＢＯＲＴメッセージを送る（図３７のステップＳ１９）。ＡＢＯＲＴメッセージの返答が返ってきた取引の状態を“ＡＢＯＲＴＥＤ”に変更するとともに、現在の日時を決済日時フィールドに記録し、すべてのＡＢＯＲＴメッセージの返答が返ってくるまで待つ（図３７のステップＳ２０）。
【０１６９】
なお、以上の各待ち状態において、必要な全ての返答が返ってくればその処理は完了となるが、返答が返ってこないものについては、後述する障害回復処理を行って、その処理の完了を試みるようにする（この点は、以下の各待ち状態においても同様である）。
【０１７０】
（３）クライアントコンピュータ３からの取り消し要求に対する処理
利用者がクライアントコンピュータ３からトランザクション管理コンピュータ１へ接続してショッピングカート中の取引の取り消しを要求した場合（例えば、『一括取消ボタン』を押した場合）の処理の流れは、図３８のようになる。このときも必要に応じて認証を行うが、ここでは既に認証されているものとして省略している。
【０１７１】
取引を取り消すための処理は、まず、取り消すことを指定されたすべての取引の状態を“ＡＢＯＲＴＩＮＧ”に変更するとともに、現在の日時を決済日時に記録する（図３８のステップＳ２１）。次に、取り消すことを指定されたすべての取引について、その取引の相手となるショップコンピュータ２に対して、取引ＩＤを指定したＡＢＯＲＴメッセージを送る（図３８のステップＳ２２）。ＡＢＯＲＴメッセージの返答が返ってきた取引の状態を“ＡＢＯＲＴＥＤに変更するとともに、現在の日時を決済日時フィールドに記録し、すべてのＡＢＯＲＴメッセージの返答が返ってくるまで待つ（図３８のステップＳ２３）。
【０１７２】
（４）障害回復処理
本実施形態では、トランザクション管理コンピュータ１は、ショップコンピュータ２の障害やネットワークの障害に対処するために、常に、取引情報データベース１３を監視して、必要な障害回復処理を行う。
【０１７３】
取引情報データベース１３中の取引情報で、ある許容時間以上、“ＡＣＴＩＶＥ”状態あるいは“ＰＲＥＰＡＲＩＮＧ”状態あるいは“ＣＯＭＩＴＴＩＮＧ”状態あるいは“ＡＢＯＲＴＩＮＧ”状態にあるものは、障害が発生している可能性があるので、図３９に示した手順で障害回復処理を行う。
【０１７４】
ある許容時間以上経過しているかどうかは、取引情報データベース１３の状態を変更した時刻を決済日時フィールドに記録しているので、その日時と現在の日時とを比較することで判断できる。
【０１７５】
まず、取引の状態が“ＰＲＥＰＡＲＩＮＧ”である場合は（図３９のステップＳ３１）、ＰＲＥＰＡＲＥメッセージの返答が返ってきていないので、該当する取引を行ったショップコンピュータ２に、取引ＩＤを指定したＰＲＥＰＡＲＥメッセージを再送するとともに、現在の日時を決済日時に記録する（図３９のステップＳ３２）。
【０１７６】
取引の状態が“ＣＯＭＩＴＴＩＮＧ”である場合は（図３９のステップＳ３３）、ＣＯＭＭＩＴメッセージの返答が返ってきていないので、該当する取引を行ったショップコンピュータ２に、取引ＩＤを指定したＣＯＭＭＩＴメッセージを再送するとともに、現在の日時を決済日時に記録する（図３９のステップＳ３４）。
【０１７７】
取引の状態が“ＡＢＯＲＴＩＮＧ”である場合は（図３９のステップＳ３５）、ＡＢＯＲＴメッセージの返答が返ってきていないので、該当する取引を行ったショップコンピュータ２に、取引ＩＤを指定したＡＢＯＲＴメッセージを再送するとともに、現在の日時を決済日時に記録する（図３９のステップＳ３６）。
【０１７８】
なお、１回あるいは規定回数、再送を行った場合に、利用者へ、そのクライアントコンピュータ３のＷＥＢブラウザを介して、単に再送している旨あるいは再送している電子店舗の名称等などを通知するようにしてもよい。
【０１７９】
取引の状態が“ＡＣＴＩＶＥ”である場合は（図３９のステップＳ３７）、同じ客ＩＤを持つ他の“ＡＣＴＩＶＥ”状態の取引も、許容時間以上、状態が変化せずに経過しているかどうかを調べる（図３９のステップＳ３８）。これは、利用者が複数の取引をショッピングカート内に保留している場合に、最初の方にカートに入れた取引は“ＡＣＴＩＶＥ”になってから時間が経っているが、直前にカートに入れた取引はまだ“ＡＣＴＩＶＥ”になったばかりであるようなときに、最初の方の取引に引きずられて全体が取り消されないためのチェックである。
【０１８０】
同じ客ＩＤを持つすべての“ＡＣＴＩＶＥ”状態の取引が許容時間以上経っている場合には、利用者は取引を成立させる意思がないものとみなして、ステップＳ３９に進んで、強制的にそれらの取引を取り消すための処理を行う。
【０１８１】
強制的に取引を取り消すための処理は、まず、同じ客ＩＤを持つすべての“ＡＣＴＩＶＥ”状態の取引を“ＡＢＯＲＴＩＮＧ”に変更するとともに、現在の日時を決済日時フィールドに記録する（図３９のステップＳ３９）。
【０１８２】
次に、状態を“ＡＢＯＲＴＩＮＧ”に変更したすべての取引について、その取引を行ったショップコンピュータ２に対して、取引ＩＤを指定したＡＢＯＲＴメッセージを送る（図３９のステップＳ４０）。
【０１８３】
最後に、ＡＢＯＲＴメッセージの返答が返ってきた取引の状態を“ＡＢＯＲＴＥＤ”に変更するとともに、現在の日時を決済日時フィールドに記録し、すべてのＡＢＯＲＴメッセージの返答が返るまで待つ（図３９のステップＳ４１）。
【０１８４】
なお、上記の各メッセージを再送しても返答が返ってこない状態が続いている場合において、メッセージを規定回数以上再送した条件、あるいは最初にメッセージを送信してから規定時間が経過した条件、あるいは当該取引が登録されてから“ＡＣＴＩＶＥ”状態の許容時間に等しい時間が経過した条件などの所定の条件が成立したならば、障害が発生したものと判断して、強制的にそれらの取引を取り消すための処理を行うようにしてもよい。
【０１８５】
障害回復処理の開始を判断するために使う許容時間は、さまざまに設定することができる。一つの方法は、あらかじめ決まっている時間（例えば、５分、３時間、１日など）を許容時間とするように実施する方式である。許容時間は、例えば、“ＡＣＴＩＶＥ”状態の許容時間は１時間で、“ＰＲＥＰＡＲＩＮＧ”状態や“ＣＯＭＩＴＴＩＮＧ”状態や“ＡＢＯＲＴＩＮＧ”状態の許容時間は１２０秒という具合に、取引の状態によって異なるように設定してもよい。
【０１８６】
また、別の方式としては、利用者の過去の取引履歴などを参考にして、例えば頻繁に利用する利用者は許容時間が長くなるように、許容時間を決めるように実施することができる。
【０１８７】
さらに別の方式としては、ショップコンピュータ２が取引をトランザクション管理コンピュータ１に登録する際に、希望の許容時間（例えば、この取引内容は２時間は有効という具合に）を登録するようにし、トランザクション管理コンピュータ１は、すべての取引に対して、それぞれの許容時間を守るように実施することができる。
【０１８８】
状態が“ＡＣＴＩＶＥ”の取引が許容時間を超える前に、トランザクション管理コンピュータ１は、その取引に係る利用者に対して、早く取引の成立または不成立を確定させさせるように警告を送るように実施することもできる。警告の手段としては、利用者がショッピングカートページを要求してきたときに、ショッピングカートページ中に警告メッセージを入れるように実施することができる。また、直接、利用者に電子メールで警告通知を送ったり、あるいは電話で警告の案内を通知するように実施することもできる。
【０１８９】
また、予めショッピングカートページに、許容時間などを提示して、利用者の注意を喚起するようにしておいてもよい。
【０１９０】
本実施形態では、状態が“ＰＲＥＰＡＲＩＮＧ”や“ＣＯＭＩＴＴＩＮＧ”や“ＡＢＯＲＴＩＮＧ”のときに、ショップコンピュータ２の側で障害の発生を認識した場合であっても、トランザクション管理コンピュータ１の側で許容時間でタイムアウトしてメッセージの再送が起こるまで待つように実施しているが、ショップコンピュータ２の側からトランザクション管理コンピュータ１に催促メッセージを送るように実施することもできる。このとき、催促メッセージを受け取ったトランザクション管理コンピュータ１は、該当する取引に関して直前に送ったメッセージを再送する。
【０１９１】
障害回復処理によって、この一括処理の途中でネットワーク障害などが起こっても、トランザクション管理コンピュータ１が障害回復処理を行うので、利用者にとっては安心して一括処理ができる。また、利用者がショッピングカート内に取引を保留しているにもかかわらず途中で操作を放棄してしまっても、トランザクション管理コンピュータ１がそれを強制的に取り消す処理を行うので、電子店舗も取引のための手続き（特に、ショッピングカート内に保留されている取引に係る商品や予約の一定時間の仮の確保）を安心して行うことができる。
【０１９２】
以下では、本実施形態のショップコンピュータ２上で動作する電子店舗プログラムの動作の例をフローチャートを使って説明する。
【０１９３】
電子店舗プログラムの動作は、大きく、
（１）クライアントコンピュータ３からのＴＭＳ登録要求に対する処理
（２）トランザクション管理コンピュータ１からのＰＲＥＰＡＲＥ処理要求に対する処理
（３）トランザクション管理コンピュータ１からのＣＯＭＭＩＴ処理要求に対する処理
（４）トランザクション管理コンピュータ１からのＡＢＯＲＴ処理要求に対する処理
の４つからなる。
【０１９４】
（１）クライアントコンピュータ３からのＴＭＳ登録要求に対する処理
利用者のクライアントコンピュータ３から、現在進行している取引について、トランザクション管理コンピュータ１を利用して、手続きを続行させたい旨の要求がなされた場合（例えば、利用者が『ＴＭＳで予約するボタン』あるいは『ＴＭＳで支払いボタン』を押した場合）、ショップコンピュータ２は、図４０の手順でトランザクション管理コンピュータ１に取引を登録する。
【０１９５】
まず、現在の取引に対して取引ＩＤを発行し、取引内容と取引ＩＤを一緒にして、ショップコンピュータ２の管理するデータベースに格納する（図４０のステップＳ５１）。
【０１９６】
次に、トランザクション管理コンピュータ１からその電子店舗に対して与えられている店ＩＤと取引ＩＤの組を、トランザクション管理コンピュータ１に送って登録する（図４０のステップＳ５２）。
【０１９７】
最後に、クライアントコンピュータ３に対して、店ＩＤと取引ＩＤの組を持ってトランザクション管理コンピュータ１に接続してショッピングカートページを要求するように指示する（図４０のステップＳ５３）。
【０１９８】
本実施形態では、ＨＴＴＰプロトコルのリダイレクション機能を使って、トランザクション管理コンピュータ１への接続をクライアントコンピュータ３に指示するように実施している。他の方式を使って実施することも可能である。
【０１９９】
トランザクション管理コンピュータ１を利用するためには（ショッピングカートを利用するためには）、客ＩＤと店ＩＤと取引ＩＤの組からなる取引情報がトランザクション管理コンピュータ１の取引情報データベース１３に入ればよい。そのため、例えば、ショップコンピュータ２が客ＩＤの認証も行って、客ＩＤと店ＩＤと取引ＩＤの組を直接トランザクション管理コンピュータ１に登録するように実施することもできる。
【０２００】
（２）トランザクション管理コンピュータ１からのＰＲＥＰＡＲＥ処理要求に対する処理
ショップコンピュータ２がトランザクション管理コンピュータ１からのＰＲＥＰＡＲＥメッセージを受け取った場合、図４１の手順で処理を行う。
【０２０１】
まず、ＰＲＥＰＡＲＥメッセージに指定されている取引ＩＤを使ってデータベースを検索し、該当する取引のための手続きが完結可能（すなわち、取引を成立させることが可能）かどうかを調べる（図４１のステップＳ６１）。完結可能であれば（図４１のステップＳ６２）、ＰＲＥＣＯＭＭＩＴＴメッセージを送り返す（図４１のステップＳ６３）。ＰＲＥＣＯＭＭＩＴＴメッセージを送り返す前に、必要に応じて完結可能であることを保証するために、必要な処理（例えばメモリー上にある取引に関するデータを磁気ディスクに記録して、その後の障害によって取引に関するデータがなくならないようにする処理など）をするようにしてもよい）。何らかの要因によって該当する取引のための手続きが完結不可能（すなわち、取引を成立させることが不可能）となった場合には、指定された取引ＩＤに関する情報がデータベースに残っていれば取り消して（図４１のステップＳ６４）、ＡＢＯＲＴＥＤメッセージを送り返す（図４１のステップＳ６５）。
【０２０２】
（３）トランザクション管理コンピュータ１からのＣＯＭＭＩＴ処理要求に対する処理
ショップコンピュータ２がトランザクション管理コンピュータ１からのＣＯＭＭＩＴメッセージを受け取った場合、図４２の手順で処理を行う。
【０２０３】
まず、ＣＯＭＭＩＴメッセージに指定されている取引ＩＤを使ってデータベースを検索し、該当する取引のための手続きが完結可能かどうかを調べる（図４２のステップＳ７１）。完結可能であれば（図４２のステップＳ７２）、ＣＯＭＭＩＴメッセージに含まれている利用者の個人情報を使って、該当する取引の成立を確定させるために必要な処理を行い（図４２のステップＳ７３）、ＣＯＭＭＩＴＴＥＤメッセージを送り返す（図４２のステップＳ７４）。このとき、手続き完了したことを利用者に知らせるための完了メッセージを一緒に送り返す。何らかの要因によって該当する取引のための手続きが完結不可能となった場合には、指定された取引ＩＤに関する情報がデータベースに残っていれば取り消して（図４２のステップＳ７５）、ＡＢＯＲＴＥＤメッセージを送り返す（図４２のステップＳ７６）。
【０２０４】
（４）トランザクション管理コンピュータ１からのＡＢＯＲＴ処理要求に対する処理
ショップコンピュータ２がトランザクション管理コンピュータ１からのＡＢＯＲＴメッセージを受け取った場合、図４３の手順で処理を行う。
【０２０５】
まず、ＡＢＯＲＴメッセージに指定された取引ＩＤに関する情報がデータベースに残っていれば取り消して（図４３のステップＳ８１）、ＡＢＯＲＴＥＤメッセージを送り返す（図４３のステップＳ８２）。
【０２０６】
トランザクション管理コンピュータ１上のトランザクション管理プログラム１１の障害回復処理では、ＰＲＥＰＡＲＥメッセージやＣＯＭＭＩＴメッセージやＡＢＯＲＴメッセージに対する返答が返ってこない場合には、それらのメッセージがネットワーク上で失われた可能性があるので、メッセージを再送することで障害回復を行う。そのため、ショップコンピュータ２上の電子店舗プログラムは、トランザクション管理コンピュータ１からＰＲＥＰＡＲＥメッセージやＣＯＭＭＩＴメッセージやＡＢＯＲＴメッセージが複数回重複して送られてくる場合を想定しておく必要がある。すなわち、既にメッセージを受け取って返答を返していても、その返答がネットワーク上で失われると、トランザクション管理コンピュータ１はメッセージを再送してくる。このとき、先に送った返答と同じ返答を送り返すように実施しておく。
【０２０７】
なお、以上の各機能は、ソフトウェアとしても実現可能である。
【０２０８】
また、本実施形態は、コンピュータに所定の手段を実行させるための（あるいはコンピュータを所定の手段として機能させるための、あるいはコンピュータに所定の機能を実現させるための）プログラムを記録したコンピュータ読取り可能な記録媒体としても実施することもできる。
【０２０９】
本発明は、上述した実施の形態に限定されるものではなく、その技術的範囲において種々変形して実施することができる。
【０２１０】
【発明の効果】
本発明によれば、トランザクション管理装置が、利用者と電子店舗との取引を管理するので、複数の電子店舗を越えたグローバルなショッピングカートが実現できる。
【図面の簡単な説明】
【図１】本発明の一実施形態に係る電子商取引システムの構成例を示す図
【図２】同実施形態に係るトランザクション管理コンピュータの構成例を示す図
【図３】同実施形態に係る電子商取引システムの動作例を示す図
【図４】同実施形態に係る電子商取引システムにおける動作手順の一例を示す図
【図５】クライアントコンピュータの表示画面に表示されたショップコンピュータのホームページの一例を示す図
【図６】クライアントコンピュータの表示画面に表示されたショップコンピュータの予約ページの一例を示す図
【図７】図６の画面で入力がなされた様子を示す図
【図８】クライアントコンピュータの表示画面に表示されたショップコンピュータの予約確認ページの一例を示す図
【図９】取引情報データベースの一例を示す図
【図１０】クライアントコンピュータの表示画面に表示されたトランザクション管理コンピュータのユーザ認証確認ページの一例を示す図
【図１１】図１０の画面で入力がなされた様子を示す図
【図１２】個人情報データベースの一例を示す図
【図１３】取引情報データベースの一例を示す図
【図１４】クライアントコンピュータの表示画面に表示されたトランザクション管理コンピュータのショッピングカートページの一例を示す図
【図１５】同実施形態に係る電子商取引システムにおける動作手順の他の例を示す図
【図１６】クライアントコンピュータの表示画面に表示された他のショップコンピュータの予約入力ページの一例を示す図
【図１７】図１６の画面で入力がなされた様子の一例を示す図
【図１８】クライアントコンピュータの表示画面に表示された他のショップコンピュータの空席状況ページの一例を示す図
【図１９】クライアントコンピュータの表示画面に表示された他のショップコンピュータの予約確認ページの他の例を示す図
【図２０】クライアントコンピュータの表示画面に表示された他のショップコンピュータの予約入力ページの他の例を示す図
【図２１】図１６の画面で入力がなされた様子の他の例を示す図
【図２２】クライアントコンピュータの表示画面に表示された他のショップコンピュータの空席状況ページの他の例を示す図
【図２３】クライアントコンピュータの表示画面に表示された他のショップコンピュータの予約確認ページの他の例を示す図
【図２４】取引情報データベースの一例を示す図
【図２５】クライアントコンピュータの表示画面に表示されたトランザクション管理コンピュータのショッピングカートページの他の例を示す図
【図２６】同実施形態に係る電子商取引システムにおける動作手順のさらに他の例を示す図
【図２７】同実施形態に係るトランザクション管理コンピュータのトランザクション管理プログラムが管理する取引の状態遷移の一例を示す図
【図２８】取引情報データベースの一例を示す図
【図２９】取引情報データベースの一例を示す図
【図３０】クライアントコンピュータの表示画面に表示されたトランザクション管理コンピュータのショッピングカートページのさらに他の例を示す図
【図３１】同実施形態に係る電子商取引システムにおける動作手順のさらに他の例を示す図
【図３２】同実施形態に係るトランザクション管理コンピュータのトランザクション管理プログラムが管理する取引の状態遷移の他の例を示す図
【図３３】クライアントコンピュータの表示画面にショップコンピュータのページとトランザクション管理コンピュータのページとを併せて表示した様子の一例を示す図
【図３４】クライアントコンピュータの表示画面に表示されたトランザクション管理コンピュータのショッピングカートページのさらに他の例を示す図
【図３５】クライアントコンピュータの表示画面に表示されたトランザクション管理コンピュータのショッピングカートページのさらに他の例を示す図
【図３６】同実施形態に係るトランザクション管理コンピュータのトランザクション管理プログラムにおけるクライアントコンピュータからのショッピングカートページ要求に対する処理手順の一例を示すフローチャート
【図３７】同実施形態に係るトランザクション管理コンピュータのトランザクション管理プログラムにおけるクライアントコンピュータからの一括処理要求に対する一括処理手順の一例を示すフローチャート
【図３８】同実施形態に係るトランザクション管理コンピュータのトランザクション管理プログラムにおけるクライアントコンピュータからの取り消し要求に対する処理手順の一例を示すフローチャート
【図３９】同実施形態に係るトランザクション管理コンピュータのトランザクション管理プログラムにおける障害回復処理の手順の一例を示すフローチャート
【図４０】同実施形態に係るショップコンピュータの電子店舗プログラムにおけるクライアントコンピュータからのＴＭＳ登録要求に対する処理手順の一例を示すフローチャート
【図４１】同実施形態に係るショップコンピュータの電子店舗プログラムにおけるトランザクション管理コンピュータからのＰＲＥＰＡＲＥ処理要求に対する処理手順の一例を示すフローチャート
【図４２】同実施形態に係るショップコンピュータの電子店舗プログラムにおけるトランザクション管理コンピュータからのＣＯＭＭＩＴ処理要求に対する処理手順の一例を示すフローチャート
【図４３】同実施形態に係るショップコンピュータの電子店舗プログラムにおけるトランザクション管理コンピュータからのＡＢＯＲＴ処理要求に対する処理手順の一例を示すフローチャート
【符号の説明】
１…トランザクション管理コンピュータ
２…ショップコンピュータ
３…クライアントコンピュータ
６…インターネット
１１…トランザクション管理プログラム
１２…個人情報データベース
１３…取引情報データベース
【図１】
0003906010.tif 000002
【図２】
0003906010.tif 000003
【図３】
0003906010.tif 000004
【図４】
0003906010.tif 000005
【図５】
0003906010.tif 000006
【図６】
0003906010.tif 000007
【図７】
0003906010.tif 000008
【図８】
0003906010.tif 000009
【図９】
0003906010.tif 000010
【図１０】
0003906010.tif 000011
【図１１】
0003906010.tif 000012
【図１２】
0003906010.tif 000013
【図１３】
0003906010.tif 000014
【図１４】
0003906010.tif 000015
【図１５】
0003906010.tif 000016
【図１６】
0003906010.tif 000017
【図１７】
0003906010.tif 000018
【図１８】
0003906010.tif 000019
【図１９】
0003906010.tif 000020
【図２０】
0003906010.tif 000021
【図２１】
0003906010.tif 000022
【図２２】
0003906010.tif 000023
【図２３】
0003906010.tif 000024
【図２４】
0003906010.tif 000025
【図２５】
0003906010.tif 000026
【図２６】
0003906010.tif 000027
【図２７】
0003906010.tif 000028
【図２８】
0003906010.tif 000029
【図２９】
0003906010.tif 000030
【図３０】
0003906010.tif 000031
【図３１】
0003906010.tif 000032
【図３２】
0003906010.tif 000033
【図３３】
0003906010.tif 000034
【図３４】
0003906010.tif 000035
【図３５】
0003906010.tif 000036
【図３６】
0003906010.tif 000037
【図３７】
0003906010.tif 000038
【図３８】
0003906010.tif 000039
【図３９】
0003906010.tif 000040
【図４０】
0003906010.tif 000041
【図４１】
0003906010.tif 000042
【図４２】
0003906010.tif 000043
【図４３】
0003906010.tif 000044