(57)【要約】【課題】  ｅｂＸＭＬを用いた電子商取引において、ＣＰＡの再合意および再登録を行い、取引企業の負担を軽減させる手段を提供する。【解決手段】  電子商取引システム４００は、自社取引装置４０１と相手先取引装置４０２とがネットワーク４０２０に接続されて構成される。メッセージ交換プログラム４０６ａは、業務担当者がメッセージの操作を行うＧＵＩ手段４０７と、メッセージを作成するメッセージ作成手段４０１０と、メッセージを送信するメッセージ送信手段４０９と、メッセージを受信するメッセージ受信手段４０８と、受信したメッセージを解析するメッセージ解析手段４０１１と、ｅｂＸＭＬ仕様による高信頼配信のためにメッセージを管理するメッセージ管理手段４０１２と、ＤＢ４０１６内のＣＰＡを管理するＣＰＡ管理手段４０１５と、ＣＰＡ承認定義ファイル４０１４を参照してＣＰＡの再合意や更新を行うＣＰＡ更新手段４０１３とから構成される。【選択図】      図４
2005353007.tif 000002
【特許請求の範囲】
【請求項１】
複数の取引装置がネットワークを介して接続されて構成され、その取引装置の間においてｅｂＸＭＬの仕様に準拠した電子商取引を行うと共に、その電子商取引における合意事項を所定の文書形式で定義したＣＰＡの更新に対する再合意を行うことを可能とする電子商取引システムであって、
前記電子商取引システムは、少なくとも、
ＣＰＡの更新を要求するＣＰＡ更新要求を発行する第１の取引装置と、
前記第１の取引装置からＣＰＡ更新要求を受けて、そのＣＰＡ更新要求に対する承認または否認を判定し、その判定結果を前記第１の取引装置に返信する第２の取引装置と、
から構成され、
前記第１の取引装置は、
現在のＣＰＡである第１のＣＰＡを記憶する第１のＣＰＡ記憶手段と、
ＣＰＡを更新しようとする第１のユーザの操作によって、電子商取引を行う上で必要となる情報を所定の文書形式で定義したＣＰＰまたはＣＰＡの更新後の内容を入力する第１のユーザ入出力手段と、
前記第１のＣＰＡ記憶手段が記憶した第１のＣＰＡならびに前記第１のユーザ入出力手段が入力したＣＰＰもしくはＣＰＡから更新後のＣＰＡである第２のＣＰＡを生成し、前記第１のＣＰＡおよび前記第２のＣＰＡの間の差分データを生成し、生成した第２のＣＰＡおよび差分データを含むＣＰＡ更新要求メッセージを作成する第１のメッセージ作成手段と、
前記第１のメッセージ作成手段が作成したＣＰＡ更新要求メッセージを前記第２の取引装置に送信する第１のメッセージ送信手段と、
前記第２の取引装置から前記第１のメッセージ送信手段が送信したＣＰＡ更新要求メッセージに対する承認または否認を示す回答メッセージを受信する第１のメッセージ受信手段と、
前記第１のメッセージ受信手段が受信した回答メッセージが承認を示すとき、前記第２のＣＰＡを前記第１のＣＰＡ記憶手段に記憶させることによって前記第１のＣＰＡを更新する第１のＣＰＡ更新手段と、
を備え、
前記第２の取引装置は、
現在のＣＰＡである第３のＣＰＡを記憶する第２のＣＰＡ記憶手段と、
前記第１の取引装置から前記ＣＰＡ更新要求メッセージを受信する第２のメッセージ受信手段と、
前記ＣＰＡ更新要求メッセージに対する承認または否認の判定を行うための判定条件データを記憶する判定条件データ記憶手段と、
前記第２のメッセージ受信手段が受信したＣＰＡ更新要求メッセージに含まれる差分データおよび前記判定条件データ記憶手段が記憶した判定条件データを照合して、前記ＣＰＡ更新要求メッセージに対する承認または否認の判定を行うＣＰＡ更新判定手段と、
前記ＣＰＡ更新判定手段が判定した結果を含む回答メッセージを作成する第２のメッセージ作成手段と、
前記第２のメッセージ作成手段が作成した回答メッセージを前記第１の取引装置に送信する第２のメッセージ送信手段と、
前記ＣＰＡ更新判定手段が判定した結果が承認であるとき、前記ＣＰＡ更新要求メッセージに含まれる第２のＣＰＡを前記第２のＣＰＡ記憶手段に記憶させることによって前記第３のＣＰＡを更新する第２のＣＰＡ更新手段と、
を備える
ことを特徴とする電子商取引システム。
【請求項２】
前記第２の取引装置は、前記差分データを表示し、ＣＰＡの更新の可否を判定する第２のユーザの操作によって、その差分データに係るＣＰＡ更新要求メッセージに対する承認または否認の判定結果を入力する第２のユーザ入出力手段を更に備え、
前記判定条件データ記憶手段は、判定条件データとして、更新を承認する差分データの範囲を示す１以上の更新承認範囲データと、更新を否認する差分データの範囲を示す１以上の更新否認範囲データとを記憶し、
前記ＣＰＡ更新判定手段は、前記ＣＰＡ更新要求メッセージに含まれる差分データと、前記更新承認範囲データおよび前記更新否認範囲データとを照合した結果として、その全ての差分データが前記更新承認範囲データのいずれかに該当するとき、更新を承認し、少なくとも１つの差分データが前記更新否認範囲データのいずれかに該当するとき、更新を否認し、それ以外のとき、前記第２のユーザ入出力手段によって、前記差分データを表示し、前記第２のユーザの操作から判定結果を入力する
ことを特徴とする請求項１に記載の電子商取引システム。
【請求項３】
前記第２のユーザ入出力手段は、前記第１の取引装置から受信したＣＰＡ更新要求メッセージのうち、前記ＣＰＡ更新判定手段が承認したメッセージおよびそのメッセージが承認済である旨、ならびに、前記第２のユーザが承認または否認の判定を行う必要のあるメッセージおよびそのメッセージがユーザによる判定を必要とする旨を表示し、前記第２のユーザが後者のメッセージを選択したとき、前記差分データを表示する
ことを特徴とする請求項２に記載の電子商取引システム。
【請求項４】
前記第１のメッセージ作成手段は、前記ＣＰＡ更新要求メッセージを作成するとき、ｅｂＸＭＬのメッセージヘッダにＣＰＡ更新要求メッセージであることを示す情報を付加し、
前記第２のメッセージ作成手段は、前記回答メッセージを作成するとき、ｅｂＸＭＬのメッセージヘッダに回答メッセージであることを示す情報を付加する
ことを特徴とする請求項１ないし請求項３のいずれか一項に記載の電子商取引システム。
【請求項５】
前記第１のＣＰＡ記憶手段は、予めＣＰＡに対応して記憶している第１の状態データを使用中にしておき、前記第１のメッセージ送信手段が前記ＣＰＡ更新要求メッセージを送信したとき、前記第１の状態データを更新中にし、前記第１のＣＰＡ更新手段の処理が終了したとき、前記第１の状態データを使用中に戻し、
前記第２のＣＰＡ記憶手段は、予めＣＰＡに対応して記憶している第２の状態データを使用中にしておき、前記第２のメッセージ受信手段が前記ＣＰＡ更新要求メッセージを受信したとき、前記第２の状態データを更新中にし、前記第２のＣＰＡ更新手段の処理が終了したとき、前記第２の状態データを使用中に戻す
ことを特徴とする請求項１ないし請求項４のいずれか一項に記載の電子商取引システム。
【請求項６】
複数の取引装置がネットワークを介して接続されて構成され、その取引装置の間においてｅｂＸＭＬの仕様に準拠した電子商取引を行う電子商取引システムにおいて、
その電子商取引における合意事項を所定の文書形式で定義したＣＰＡの更新に対する再合意を行うことを可能とするために取引装置が行う電子商取引方法であって、
第１の取引装置が、
現在のＣＰＡである第１のＣＰＡを第１のメモリに記憶するステップと、
ＣＰＡを更新しようとする第１のユーザの操作によって、電子商取引を行う上で必要となる情報を所定の文書形式で定義したＣＰＰまたはＣＰＡの更新後の内容を入力するステップと、
前記第１のメモリに記憶した第１のＣＰＡならびに前記入力したＣＰＰもしくはＣＰＡから更新後のＣＰＡである第２のＣＰＡを生成し、前記第１のＣＰＡおよび前記第２のＣＰＡの間の差分データを生成し、生成した第２のＣＰＡおよび差分データを含むＣＰＡ更新要求メッセージを作成するステップと、
前記作成したＣＰＡ更新要求メッセージを送信するステップと、
を実行し、
第２の取引装置が、
現在のＣＰＡである第３のＣＰＡを第２のメモリに記憶するステップと、
前記第１の取引装置から前記ＣＰＡ更新要求メッセージを受信するステップと、
前記ＣＰＡ更新要求メッセージに対する承認または否認の判定を行うための判定条件データを所定のメモリに記憶するステップと、
前記受信したＣＰＡ更新要求メッセージに含まれる差分データおよび前記所定のメモリに記憶した判定条件データを照合して、前記ＣＰＡ更新要求メッセージに対する承認または否認の判定を行うステップと、
前記判定した結果を含む回答メッセージを作成するステップと、
前記作成した回答メッセージを前記第１の取引装置に送信するステップと、
を実行し、
前記第１の取引装置が、
前記第２の取引装置から前記回答メッセージを受信するステップと、
前記受信した回答メッセージが承認を示すとき、前記第２のＣＰＡによって前記第１のメモリに記憶した第１のＣＰＡを更新するステップと、
を実行し、
前記第２の取引装置が、
前記判定した結果が承認であるとき、前記ＣＰＡ更新要求メッセージに含まれる第２のＣＰＡによって前記第２のメモリに記憶した第３のＣＰＡを更新するステップ
を実行する
ことを特徴とする電子商取引方法。
【請求項７】
前記判定条件データは、更新を承認する差分データの範囲を示す１以上の更新承認範囲データと、更新を否認する差分データの範囲を示す１以上の更新否認範囲データとを含み、
前記第２の取引装置は、
前記ＣＰＡ更新要求メッセージに対する承認または否認の判定を行うステップにおいて、
前記ＣＰＡ更新要求メッセージに含まれる差分データと、前記更新承認範囲データおよび前記更新否認範囲データとを照合した結果として、その全ての差分データが前記更新承認範囲データのいずれかに該当するとき、更新を承認し、少なくとも１つの差分データが前記更新否認範囲データのいずれかに該当するとき、更新を否認し、それ以外のとき、前記差分データを表示し、ＣＰＡの更新の可否を判定する第２のユーザの操作からその差分データに係るＣＰＡ更新要求メッセージに対する判定結果を入力する
ことを特徴とする請求項６に記載の電子商取引方法。
【請求項８】
前記第２の取引装置は、
前記差分データを表示する場合、
前記第１の取引装置から受信したＣＰＡ更新要求メッセージのうち、前記更新を承認したメッセージおよびそのメッセージが承認済である旨、ならびに、前記第２のユーザが承認または否認の判定を行う必要のあるメッセージおよびそのメッセージがユーザによる判定を必要とする旨を表示し、前記第２のユーザが後者のメッセージを選択したとき、前記差分データを表示する
ことを特徴とする請求項７に記載の電子商取引方法。
【請求項９】
前記第１の取引装置は、
前記ＣＰＡ更新要求メッセージを作成するステップにおいて、ｅｂＸＭＬのメッセージヘッダにＣＰＡ更新要求メッセージであることを示す情報を付加し、
前記第２の取引装置は、
前記回答メッセージを作成するステップにおいて、ｅｂＸＭＬのメッセージヘッダに回答メッセージであることを示す情報を付加する
ことを特徴とする請求項６ないし請求項８のいずれか一項に記載の電子商取引方法。
【請求項１０】
前記第１の取引装置は、
予めＣＰＡに対応して所定のメモリに記憶している第１の状態データを使用中にしておき、前記ＣＰＡ更新要求メッセージを送信したとき、前記第１の状態データを更新中にし、前記第１のＣＰＡを更新するステップが終了したとき、前記第１の状態データを使用中に戻し、
前記第２の取引装置は、
予めＣＰＡに対応して所定のメモリに記憶している第２の状態データを使用中にしておき、前記ＣＰＡ更新要求メッセージを受信したとき、前記第２の状態データを更新中にし、前記第３のＣＰＡを更新するステップが終了したとき、前記第２の状態データを使用中に戻す
ことを特徴とする請求項６ないし請求項９のいずれか一項に記載の電子商取引方法。
【請求項１１】
請求項６ないし請求項１０のいずれか一項に記載の電子商取引方法をコンピュータに実行させることを特徴とする電子商取引プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、企業間の合意事項に基づいて電子商取引を行う電子商取引システム、電子商取引方法および電子商取引プログラムに関する。
【背景技術】
【０００２】
企業間電子商取引を実現する技術は、大きく分けると、ＶＡＮ（Value Added Network、付加価値通信網）型とインターネット型の２つに分類することができる。前者のＶＡＮ型は、従来からある技術であり、専用線（ＶＡＮ）を用いて特定の取引先と比較的大量のデータをやりとりする際に使用される。専用線を用いるため、セキュリティや信頼性などの面ではメリットがある反面、導入コストが高く、システムとして独自性が強いため、取引先が限定されるというデメリットもある。コストが高いため、利用者は、大企業に偏りがちであり、中小企業では利用されない場合が多い。一方、後者のインターネット型は、最近普及している技術であり、インターネットを用いて多数の取引先と比較的少量のデータをやりとりする際に使用される。オープンなインターネットを用いるため、比較的安価な導入コストで利用でき、中小企業においても利用しやすい。しかし、インターネットを使用するため、セキュリティや信頼性などの面を考慮する必要がある。
ＶＡＮ型とインターネット型のどちらも現在利用されている技術ではあるが、企業間電子商取引の将来像を考えると一つ大きな弊害がある。それは、企業間の電子商取引における標準化が進んでいない点である。ＶＡＮ型は、もともと取引先を限定する形態であるため、取引ごとにシステムは千差万別であるが、インターネット型は、オープンな技術であるため、多数の企業が参画可能であるにも関わらず、標準化が進んでいないために、結局は、特定の企業グループごとにその利用が特化されてしまうケースが大半である。その意味で、標準化を進めることが、企業間電子商取引を広く普及させる上で急務となっている。
【０００３】
電子商取引における標準化を進めるにあたり、近年、ｅｂＸＭＬ(Electronic Business Extensible Markup Language：非特許文献１参照）という技術が注目されている。ｅｂＸＭＬは、企業間の取引プロセスの定義や取引相手との取引情報の合意、メッセージ交換の方法など、企業間電子商取引に関る様々な枠組みを規定している。つまり、ｅｂＸＭＬ自身が標準インターフェースの役割を担うので、ｅｂＸＭＬに則って電子商取引を行うことで、前記標準化の問題を解決することができるのである。
ｅｂＸＭＬに則った企業間電子商取引を行うためには、ｅｂＸＭＬ仕様に準拠した電子商取引システムが必要となる。そして、その電子商取引システムには、少なくとも、取引企業間の取引情報の合意事項をＸＭＬで定義したＣＰＡ（Collaboration Protocol Agreement：非特許文献２参照）と、ｅｂＸＭＬ ＭＳ（Messaging Service：非特許文献３参照）の仕様に準拠して動作するメッセージ交換プログラムとが必要となる。ｅｂＸＭＬで取り扱うメッセージは、ＳｗＡ（SOAP Messages with Attachments：非特許文献６参照）形式を採用している。ＳｗＡ形式は、ＳＯＡＰ（Simple Object Access Program：非特許文献７参照）の封筒構造に、ＭＩＭＥ（Multipurpose Internet Mail Extension：非特許文献８参照）によって添付文書を付加できるようにした形式である。
【０００４】
ｅｂＸＭＬを用いて取引を行うための手順は、概ね以下のようになる。まず、取引を行いたい企業がＣＰＰ（Collaboration Protocol Profile：非特許文献２参照）と呼ばれるファイルを作成する。ＣＰＰとは、その企業が取引を行う上で必要となる情報をＸＭＬで定義したものである。その内容には、企業情報、取引対象サービス情報、通信手段、セキュリティポリシー、ｅｂＸＭＬ特性などの情報が含まれる。通常、作成したＣＰＰは、ｅｂＸＭＬ  Ｒｅｇｉｓｔｒｙ（非特許文献４参照）と呼ばれるレジストリに登録する。また、その企業が取引におけるビジネスフローをＢＰＳＳ（Business Process Specification Schema：非特許文献５参照）として定義し、そのＢＰＳＳをＣＰＰと関連付けている場合は、ＣＰＰと同様にＢＰＳＳもレジストリに登録する。なお、ＢＰＳＳの定義は、任意であるため、なくてもよい。また、レジストリの登録自体も必須ではないため、登録しなくてもよい。
次に、取引相手を決める。既に取引相手が事前に決定している場合もあるが、レジストリに登録している場合は、お互いの取引情報が公開されているので、そこで決まる場合もある。ただし、この時点では、取引相手が仮に決まっただけで、取引の合意はされていない。
取引相手が決まった段階で、お互いのＣＰＰを照合し、交渉を行う。例えば、Ａ社が文書Ｘを送る定義になっているのに、Ｂ社が文書Ｘを受け取れる定義になっていない場合など、ＣＰＰの内容に対応が取れていない部分があれば、この時点で修正を行う。お互いのＣＰＰの内容に問題がなく、取引を行うことに双方が合意した段階でＣＰＡを作成する。ＣＰＡは、双方のＣＰＰの内容と有効期限情報などのＣＰＡ独自項目とから構成される。
そして、作成したＣＰＡを双方のメッセージ交換プログラムに登録する。メッセージ交換プログラムは登録したＣＰＡに従って動作し、その取引が開始される。
【非特許文献１】ebXML Technical Architecture Project Team、“ebXML Technical Architecture Specification v1.0.4”、［online］、OASIS、16 February 2001、［２００４年３月２６日検索］、インターネット＜ＵＲＬ：http://www.ebxml.org/specs/＞
【非特許文献２】OASIS ebXML Collaboration Protocol Profile and Agreement Technical Committee、“Collaboration-Protocol Profile and Agreement Specification Version 2.0”、［online］、OASIS、23 September 2002、［２００４年３月２６日検索］、インターネット＜ＵＲＬ：http://www.ebxml.org/specs/＞
【非特許文献３】OASIS ebXML Messaging Services Technical Committee、“Message Service Specification Version 2.0”、［online］、OASIS、1 April 2002、［２００４年３月２６日検索］、インターネット＜ＵＲＬ：http://www.ebxml.org/specs/＞
【非特許文献４】OASIS/ebXML Registry Technical Committee、“OASIS/ebXML Registry Services Specification v2.0”、［online］、OASIS、6 December 2001、［２００４年３月２６日検索］、インターネット＜ＵＲＬ：http://www.ebxml.org/specs/＞
【非特許文献５】Business Process Project Team、“ebXML Business Process Specification Schema Version 1.01”、［online］、OASIS、11 May 2001、［２００４年３月２６日検索］、インターネット＜ＵＲＬ：http://www.ebxml.org/specs/＞
【非特許文献６】John J. Barton、Satish Thatte、Henrik Frystyk Nielsen、“SOAP Messages with Attachments”、［online］、W3C、11 December 2000、［２００４年３月２６日検索］、インターネット＜ＵＲＬ：http://www.w3.org/TR/2000/NOTE-SOAP-attachments-20001211＞
【非特許文献７】Don Box、David Ehnebuske、Gopal Kakivaya、Andrew Layman、Noah Mendelsohn、Henrik Frystyk Nielsen、Satish Thatte、Dave Winer、“Simple Object Access Protocol (SOAP) 1.1”、［online］、W3C、8 May 2000、［２００４年３月２６日検索］、インターネット＜ＵＲＬ：http://www.w3.org/TR/2000/NOTE-SOAP-20000508＞
【非特許文献８】N.Freed、N.Borenstein、“Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies（RFC2045）”、［online］、Network Working Group、IETF(The Internet Engineering Task Force)、November 1996、［２００４年３月２９日検索］、インターネット＜ＵＲＬ：http://www.ietf.org/rfc/rfc2045.txt?number=2045＞
【発明の開示】
【発明が解決しようとする課題】
【０００５】
ｅｂＸＭＬを用いた電子商取引システムにおいては、企業間の合意事項を記したＣＰＡが前提となり、双方のメッセージ交換プログラムは、その内容に従って動作する。ＣＰＡの内容に更新が生じる場合は、一旦取引を中断させた後、双方でＣＰＡの更新内容について再合意を行い、ＣＰＡを再作成する。ＣＰＡの再作成については、通常、専用のツールを用いて行う。作成にあたっては、それぞれの企業がそれぞれのＣＰＡを作成する場合もあるし、一方の企業がＣＰＡを作成し、他方の企業に配布する場合や、第三者にＣＰＡの作成を依頼し、その第三者からそれぞれに配布してもらう場合など様々な形態がある。ＣＰＡ再作成後は、次回の取引から更新後のＣＰＡを使用させるために、双方のメッセージ交換プログラムに再登録する。
しかしながら、従来技術では、前記ＣＰＡ更新の過程において、合意からメッセージ交換プログラムへの再登録までを実際の電子商取引とは別の経路で行うことを前提としている。例えば、ＣＰＡの再合意については、メールやＦＡＸなどの別経路で内容を確認する必要があるし、メッセージ交換プログラムへの登録については、再度プログラムに読み込ませる必要がある。このように、ＣＰＡ更新の都度、取引企業に対する負担が生じてしまうという問題がある。更に、その結果として、取引遅延につながることも考えられる。
【０００６】
そこで、本発明は、前記問題に鑑み、ｅｂＸＭＬを用いた電子商取引において、ＣＰＡ更新要求に対する再合意および再登録を行い、取引企業に対する負担を軽減させる手段を提供することを課題とする。
【課題を解決するための手段】
【０００７】
前記課題を解決する本発明は、複数の取引装置がネットワークを介して接続されて構成され、その取引装置の間においてｅｂＸＭＬの仕様に準拠した電子商取引を行うと共に、その電子商取引における合意事項を所定の文書形式で定義したＣＰＡの更新に対する再合意を行うことを可能とする電子商取引システムであって、少なくとも、第２の取引装置にＣＰＡの更新を要求するＣＰＡ更新要求を発行する第１の取引装置と、第１の取引装置からＣＰＡ更新要求を受けて、そのＣＰＡ更新要求に対する承認または否認を判定し、その判定結果を第１の取引装置に返信する第２の取引装置とから構成される。
【０００８】
第１の取引装置においては、まず、第１のユーザ入出力手段が、ＣＰＡを更新しようとする第１のユーザの操作によって、電子商取引を行う上で必要となる情報を所定の文書形式で定義したＣＰＰまたはＣＰＡの更新後の内容を入力する。次に、第１のメッセージ作成手段が、予め第１のＣＰＡ記憶手段が記憶した現在のＣＰＡである第１のＣＰＡと、入力したＣＰＰまたはＣＰＡの内容とから、更新後のＣＰＡである第２のＣＰＡおよび差分データを生成し、それらを含むＣＰＡ更新要求メッセージを作成する。そして、第１のメッセージ送信手段が、作成したＣＰＡ更新要求メッセージを第２の取引装置に送信する。
第２の取引装置においては、第２のメッセージ受信手段が、第１の取引装置からＣＰＡ更新要求メッセージを受信する。一方、判定条件データ記憶手段が、ＣＰＡ更新要求メッセージに対して承認するかまたは否認するかを判定するためのデータ（判定条件データ）を記憶している。そこで、ＣＰＡ更新判定手段が、受信したＣＰＡ更新要求メッセージに含まれる差分データと、判定条件データとを照合し、その照合の結果に基づいて、承認または否認の判定を行う。そして、第２のメッセージ作成手段が、その判定結果を含む回答メッセージを作成し、第２のメッセージ送信手段が、作成した回答メッセージを第１の取引装置に送信する。
第１の取引装置においては、第１のメッセージ受信手段が、第２の取引装置から回答メッセージを受信する。そして、第１のＣＰＡ更新手段が、受信した回答メッセージが先のＣＰＡ更新要求メッセージの承認を示すとき、第２のＣＰＡによって、第１のＣＰＡ記憶手段に記憶された第１のＣＰＡを更新する。第２の取引装置においても、第２のＣＰＡ更新手段が、ＣＰＡ更新判定手段の判定結果が承認であるとき、第２のＣＰＡによって、第２のＣＰＡ記憶手段に記憶された現在のＣＰＡである第３のＣＰＡを更新する。
【０００９】
これによれば、通常の電子商取引を行うネットワークを介して、ＣＰＡの更新に対する再合意を行うので、別ルートを経由することがなく、効率的である。また、判定条件データによってＣＰＡ更新要求に対する承認または否認の判定を行うと共に、その判定が承認であったとき、双方の取引装置でＣＰＡの更新を行うので、ユーザの手間を省くことができる。
なお、本発明は、電子商取引方法および電子商取引プログラムを含むものとする。
【発明の効果】
【００１０】
本発明によれば、ｅｂＸＭＬによる電子商取引の中で、ＣＰＡ更新要求に対する再合意および更新後のＣＰＡの再登録を行うことができ、取引企業に対する負担を軽減させることが可能である。
【発明を実施するための最良の形態】
【００１１】
以下、本発明を実施するための最良の形態（以下、「本発明の実施の形態」という）について図面を参照して詳細に説明する。
【００１２】
≪ｅｂＸＭＬの概要≫
図１は、本発明の実施の形態に係るｅｂＸＭＬの概略図である。ｅｂＸＭＬを用いた電子商取引を行う上で、取引を行う各企業１０１は、ＣＰＰ１０２を作成する。ＣＰＰ１０２の内容については、図２で別途説明する。双方の企業１０１は、お互いのＣＰＰの内容を確認すると共に、その内容に問題があれば修正を行う。ＣＰＰ１０２の内容に問題がなくなり、企業１０１の間で合意が形成されたとき、ＣＰＡ１０４を作成する。ＣＰＡ１０４の内容については、図３で別途説明する。その作成したＣＰＡ１０４は、それぞれの取引装置１０３内にあるメッセージ交換プログラム１０５に設定する。ＣＰＡ１０４の設定後、双方のメッセージ交換プログラム１０５の間でｅｂＸＭＬのメッセージ１０６がＨＴＴＰ（Hypertext Transfer Protocol）などの通信プロトコルを用いて送受信される。
【００１３】
図２は、本発明の実施の形態に係るＣＰＰの内容例を示す図である。ＣＰＰは、取引情報をＸＭＬ形式化したファイルである。内容としては、例えば、上位階層に企業情報２０１（タグ名：PartyInfo）、その下位階層に企業ＩＤ２０２（タグ名：PartyID）、役割２０３（タグ名：CollaborationRole）、証明書２０４（タグ名：Certificate）、セキュリティ詳細（タグ名：SecurityDetails）２０５、転送情報２０６（タグ名：Transport）、文書交換情報２０７（タグ名：DocExchange）などを含む。
【００１４】
図３は、本発明の実施の形態に係るＣＰＡの構成を示す図である。ＣＰＡ３０１は、ＸＭＬ形式のファイルであり、ＣＰＡステータス３０２、ＣＰＡ有効期限−開始３０３、ＣＰＡ有効期限−終了３０４などのＣＰＡ項目と、一方の企業の企業情報３０５であるＣＰＰ情報と、他方の企業の企業情報３０６であるＣＰＰ情報と、パッケージング情報などの双方の共通情報３０７とから構成される。
【００１５】
≪システムの構成と概要≫
図４は、本発明の実施の形態に係る電子商取引システムの構成を示す図である。電子商取引システム４００は、自社取引装置４０１（第１の取引装置）と相手先取引装置４０２（第２の取引装置）とがネットワーク４０２０を介して接続されて構成される。自社取引装置４０１は、モニタ４０３、ＣＰＵ４０４、通信アダプタ４０５およびメモリ４０６がバス４０１９を介して接続されて構成される。自社取引装置４０１に電源が投入されたとき、所定の不揮発性記憶装置（ハードディスク装置など、図示せず）からメモリ４０６内にメッセージ交換プログラム４０６ａがローディングされる。メッセージ交換プログラム４０６ａは、業務担当者がメッセージの送受信の操作を行うためのＷｅｂ画面などをモニタ４０３に表示し、その操作によるデータを入力するＧＵＩ手段４０７と、ＧＵＩ手段４０７からデータを受け取ってｅｂＸＭＬのメッセージを作成するメッセージ作成手段４０１０と、その作成したメッセージを通信アダプタ４０５経由で相手先取引装置４０２に送信するメッセージ送信手段４０９と、相手先取引装置４０２から送られて来たメッセージを通信アダプタ４０５経由で受信するメッセージ受信手段４０８と、その受信したメッセージを解析するメッセージ解析手段４０１１と、ｅｂＸＭＬ仕様に従った高信頼配信を実現するためにメッセージの送受信制御を行ったり、ＤＢ４０１６内のメッセージ管理テーブル４０１７を使用してメッセージの管理を行ったりするメッセージ管理手段４０１２と、ＤＢ４０１６内のＣＰＡ管理テーブル４０１８を使用してＣＰＡを管理するＣＰＡ管理手段４０１５と、ＣＰＡ更新時にＣＰＡ承認定義ファイル４０１４を参照してＣＰＡの再合意や更新を行うＣＰＡ更新手段４０１３とから構成される。
【００１６】
なお、自社取引装置４０１および相手先取引装置４０２は、サーバやＰＣ（Personal Computer）によって実現される。ネットワーク４０２０は、インターネットなどによって実現される。前記各手段は、メモリ４０６内のメッセージ交換プログラム４０６ａをＣＰＵ４０４が実行することによって実現される。また、相手先取引装置４０２は、自社取引装置４０１と同様の構成を持つものとする。更に、図４には、ネットワーク４０２０に２つの取引装置が接続されているように示されているが、実際には、多数の取引装置が接続され、それらの各取引装置の間で電子商取引が行われるものとする。
【００１７】
前記各手段の関連性およびデータのフローについては、図６および図１３〜図２０で説明する。また、ＧＵＩ手段４０７の画面例については、図７〜図１０で説明する。また、ＣＰＡ承認定義ファイル４０１４の定義例については、図１１で説明する。また、ＣＰＡ管理テーブル４０１８の項目内容については、図１２で説明する。なお、図４のメッセージ管理テーブル４０１７は、本発明の実施の形態の中で単純にメッセージを管理するテーブルとしてのみ紹介する程度であるため、テーブル構造についての詳細な説明は割愛する。
【００１８】
図５は、本発明の実施の形態に係るｅｂＸＭＬメッセージの形式を示す図である。ｅｂＸＭＬメッセージは、階層構造で形成される。最も外側は、ｅｂＸＭＬメッセージパッケージ５０１である。その中には、１つのｅｂＸＭＬヘッダ５０２と複数の“payload”（５０１０）と呼ばれる添付文書５０９で構成され、更に、ｅｂＸＭＬヘッダ５０２の中には、ＳＯＡＰエンベロープ５０３がある。ＳＯＡＰエンベロープ５０３は、ＳＯＡＰヘッダ５０４とＳＯＡＰボディ５０７とから構成されており、それぞれの中身は、ｅｂＸＭＬで規定される内容がＸＭＬで書かれる。例えば、ＳＯＡＰヘッダ５０４には、“eb:MessegeHeader”（５０５）などの情報が規定されており、ＳＯＡＰボディ５０７には、“eb:Manifest”（５０８）などの情報が規定されている。ただし、ｅｂＸＭＬとしては、ＳＯＡＰヘッダ５０４またはＳＯＡＰボディ５０７内に規定外の内容が書かれたとしても、特に制限されない。本発明の実施の形態では、本発明を実現する手段として、ＳＯＡＰヘッダ５０４内におけるｅｂＸＭＬ規定外のその他５０６の拡張可能領域を使用する。実際の内容については、図１３〜図２０のフローの中で説明する。
【００１９】
図６は、本発明の実施の形態に係る、取引元企業から取引先企業へＣＰＡの更新要求のメッセージを送信する際の処理手順全体を示す図である。取引元企業である企業Ａのユーザは、企業Ａ取引装置のＧＵＩ手段４０７を使って、「ＣＰＡ更新要求」を相手先の企業Ｂ取引装置に送信する（ステップＳ６０１）。「ＣＰＡ更新要求」送信の処理詳細については、図１３に示す。送信された「ＣＰＡ更新要求」を取引先企業である企業Ｂの取引装置が受信する（ステップＳ６０２）。その受信と同時に、企業Ａに受信したことを告げるメッセージであるＡＣＫ（Acknowledgement）を返す。そして、企業Ａ取引装置が、「ＣＰＡ更新要求」に対するＡＣＫを受信する（ステップＳ６０４）。そのＡＣＫの受信の処理詳細は、図１８に示す。その後、企業Ｂ取引装置において、「ＣＰＡ更新要求」に対して承認するか否認するかが決定され、その結果に応じて企業Ａ取引装置に「ＣＰＡ更新承認」または「ＣＰＡ更新否認」を送信する（ステップＳ６０３）。「ＣＰＡ更新要求」の受信から、その解析結果である「ＣＰＡ更新承認」または「ＣＰＡ更新否認」を送信するまでの処理の詳細は、図１５に示す。その後、企業Ａ取引装置が「ＣＰＡ更新承認」または「ＣＰＡ更新否認」を受信し、その受信と同時に企業Ｂ取引装置にそのメッセージに対するＡＣＫを返す（ステップＳ６０５）。「ＣＰＡ更新承認」または「ＣＰＡ更新否認」の受信の処理詳細は、図１９に示す。そして、企業Ｂ取引装置が「ＣＰＡ更新承認」または「ＣＰＡ更新否認」に対するＡＣＫを受信する（ステップＳ６０６）。そのＡＣＫの受信の処理詳細は、図２０に示す。
【００２０】
≪取引装置のＧＵＩ画面例≫
図７〜図１０は、図４のＧＵＩ手段４０７における画面例である。順次各画面例について説明する。
図７および図８は、本発明の実施の形態に係るメッセージの送信画面例である。図７は、通常のビジネスメッセージの送信画面例であり、図８は、「ＣＰＡ更新要求」メッセージの送信画面例である。通常のビジネスメッセージを送信する場合、業務担当者は、図７の画面を用いてビジネスメッセージを送信する。入力項目としては、宛て先７０１、件名７０２および添付文書７０４があり、添付文書を複数添付するときは、追加ボタン７０３をクリックする。業務担当者は、これらの入力項目に情報を入力し、送信ボタン７０５をクリックすることでメッセージの送信を行う。一方、ＣＰＡの更新を要求する場合、業務担当者は、図８の画面を用いる。この場合、入力項目としては、宛て先８０１および１つの添付文書８０２となる。図７の画面にあった件名に関しては、プログラムにより固定の件名（例えば、「ＣＰＡ更新要求」など）が入力されるため、その入力欄はない。また、添付文書は、更新するＣＰＰまたはＣＰＡの１つであるため、図７の画面にあった追加ボタンはない。メッセージの送信は、ビジネスメッセージの場合と同様に送信ボタン８０３をクリックすることで行う。
【００２１】
図９は、本発明の実施の形態に係るＧＵＩ手段のメイン画面の例である。取引先９０７ごとにメインの画面を切り替えることができる。左側のメニュー９０１では、受信メッセージ９０８または送信メッセージ９０９の選択が可能となっており、更に送信メッセージについては、ビジネス文書９０１０またはＣＰＡ更新要求９０１１を選択できる。例えば、メニュー９０１からビジネス文書９０１０を選択した場合は、図７の画面に別ウインドウで遷移し、ＣＰＡ更新要求９０１１を選択した場合は、図８の画面に別ウインドウで遷移する。図９に示すように、受信メッセージ９０８を選択すると、右側に受信メッセージ一覧９０２が表示される。通常のビジネスメッセージは、「件名[メッセージＩＤ]」の形式で表示される（符号９０５または符号９０６参照）。「ＣＰＡ更新要求」の場合は、表示方法が異なる。ＣＰＡの更新がプログラムによって自動的に承認された場合は、「ＣＰＡ更新要求[メッセージＩＤ](自動承認済)」の形式で表示される（符号９０３参照）。また、ＣＰＡの更新がプログラムによって自動的に否認された場合は、「ＣＰＡ更新要求[メッセージＩＤ](自動否認済)」の形式で表示される（画面例には図示せず）。一方、ＣＰＡの更新が業務担当者に委ねられる場合は、「ＣＰＡ更新要求[メッセージＩＤ](承認処理要)」の形式で表示される（符号９０４参照）。ＣＰＡの更新が業務担当者に委ねられる場合は、図９に示すようにアイコンを他のメッセージと変えることで業務担当者が判別しやすいようにする（符号９０４参照）。その他の受信メッセージの種類としては、「ＣＰＡ更新要求」に対する回答として、「ＣＰＡ更新承認」、「ＣＰＡ更新否認」などのメッセージも存在する。それぞれ、「ＣＰＡ更新承認[メッセージＩＤ]」、「ＣＰＡ更新否認[メッセージＩＤ]」の形式で表示される（画面例には図示せず）。
【００２２】
図１０は、本発明の実施の形態に係る「ＣＰＡ更新要求」に対する承認画面の例である。図９の受信メッセージ一覧９０２で「ＣＰＡ更新要求[メッセージＩＤ](承認処理要)」（９０４）をクリックした場合に、別ウインドウで本画面に遷移する。本画面で確認できる内容としては、取引先１００１、更新するＣＰＡ１００２、差分リスト１００３がある。ここで、差分リスト１００３は、現在のＣＰＡと更新するＣＰＡとの差分をファイル化したものである。このファイルは、メッセージ交換プログラム４０６ａが自動的に作成し、ＣＰＡと共に送付する。業務担当者は、差分リスト１００３の内容を確認し、承認するか否認するかを決める。承認する場合は、承認ボタン１００４をクリックし、否認する場合は、否認ボタン１００５をクリックする。クリック後、「ＣＰＡ更新要求」の送信元取引装置に対して、承認の場合は、「ＣＰＡ更新承認」が、否認の場合は、「ＣＰＡ更新否認」のメッセージがそれぞれ送信される。
なお、「ＣＰＡ更新要求[メッセージＩＤ](承認処理要)」以外の「ＣＰＡ更新要求」メッセージをクリックした場合、承認ボタンおよび否認ボタンは表示されないが、更新するＣＰＡおよび差分リストは閲覧可能である。
【００２３】
図１１は、本発明の実施の形態に係るＣＰＡ承認定義ファイルの定義例を示す図である。実際にメッセージ交換プログラム４０６ａに登録するＣＰＡは、複数存在する場合があるため、複数のＣＰＡに関して図４のＣＰＡ承認定義ファイル４０１４を定義できるようにする。各ＣＰＡは、ＣＰＡに固有の番号であるＣＰＡＩＤによってメッセージ交換プログラム４０６ａ内で管理されているため、[CPAID=XXXX]のセクションで各ＣＰＡを区切る。図１１の例では、ＣＰＡＩＤが“C0001”の場合のセクション１１０１（[CPAID=C0001]）と、ＣＰＡＩＤが“C0002“の場合のセクション１１０６（[CPAID=C0002]）とが存在している。各ＣＰＡは、図３で説明した企業情報を複数含むため、ＣＰＡ承認定義ファイル４０１４は、それぞれの企業情報に対する自動承認または自動否認の範囲の定義を可能とする。メッセージ交換プログラム４０６ａでは、企業の識別にＰａｒｔｙＩＤを使用するため、[PartyID=XXXX]のセクションで更に区切る。図１１の例では、ＰａｒｔｙＩＤが“COMPANY01”の場合のセクション１１０２（[PartyID=COMPANY01]）とＰａｒｔｙＩＤが“COMPANY02”の場合のセクション１１０５（[PartyID=COMPANY02]）とが存在する。この場合、例えば、“COMPANY01”が取引先企業であり、“COMPANY02”が自社企業であることを意味する。更に、各企業情報のどの部分を承認対象または否認対象にするかを定義するために、[PartyID=XXXX]セクションの中に[Approval]セクション１１０３と[Denial]セクション１１０４を記述する。[Approval]セクション１１０３には、自動承認可能なＣＰＡの範囲を記述し、[Denial]セクション１１０４には、自動否認可能なＣＰＡの範囲を記述する。なお、ＣＰＡの更新範囲が、これらのセクションに記述された範囲に該当しない場合は、業務担当者に承認または否認の判断を委ねることになる。また、図３で説明したＣＰＡ項目や共通情報は、ＰａｒｔｙＩＤに依存しない共通の情報であるが、それらに対する自動承認または自動否認の範囲は、いずれか１つの[PartyID=XXXX]セクションにおいて企業情報の場合と同様に定義すればよいこととする。
【００２４】
ＣＰＡは、ＸＭＬ形式のツリー構造となっているため、[Approval]セクションまたは[Denial]セクションには、承認または否認の範囲をパス形式で階層的に記述する。フォーマットは、「＜階層パス＞、(＜フラグ-A:追加｜C:変更｜D:削除＞)、（＜修正内容＞）」のようになる。フォーマットの中で＜階層パス＞の最後に“*”をつけた場合は、その階層以下の全てを意味する。また、＜フラグ＞を記述しない場合は、追加、変更、削除の全てを意味する。また、最後の＜修正内容＞には、追加または修正の場合に承認または否認となる内容を記述する。ただし、追加または修正の内容に制限を設けないのであれば、＜修正内容＞を記述する必要はない。この＜修正内容＞については、実際に活用する上で、様々な記述上の規定を設けることが想定されるが、これらの規定については、本発明の実施の形態に直接関係しないため割愛する。
【００２５】
例えば、図１１の[Approval]セクション１１０３の１行目は、＜階層パス＞が“/END”であり、＜フラグ＞が“Ｃ“、＜修正内容＞が““2004-01-01T00:00:00”-“2006-01-01T00:00:00””である。これは、ＣＰＡの<END>タグの値を“2004-01-01T00:00:00”から“2006-01-01T00:00:00”の範囲で修正されている場合には、自動的に承認することを意味する。２行目は、＜階層パス＞が“/PartyInfo/CollaborationRole/ServiceBinding/CanSend/*”であり、＜フラグ＞が“Ａ“である。これは、<CanSend>タグ以下の全てタグの内容について、追加の場合には、追加の内容に関わらず自動的に承認することを意味する。[Denial]セクションも[Approval]セクションと同様の記述となるが、メッセージ交換プログラム４０６ａは、まず[Approval]セクションに記述された内容から解釈するため、[Approval]セクションで記述のあった範囲以外の範囲が対象となる。図１１の[Denial]セクション１１０４の例では、＜階層パス＞が“/PartyInfo/DocExchange/*”である。これは、<DocExchange>タグ以下の全てのタグの内容について、追加、変更、削除に関わらず、自動的に否認することを意味する。更に、図１１の[PartyID=COMPANY02]セクション１１０５には、“=COMPANY01“が記述されている。これは、自動承認および自動否認の範囲が[PartyID=COMPANY01]セクション１１０２で記載されたものと同じであることを意味する。以上のように、ＣＰＡ内の自動承認範囲および自動否認範囲を定義として明確にすることで、メッセージ交換プログラム４０６ａがＣＰＡの再合意に対する自動承認および自動否認の判断を行うことができるようになる。
【００２６】
図１２は、本発明の実施の形態に係るＣＰＡ管理テーブルの内容例とＣＰＡの状態遷移を示す図である。図１２（ａ）に示すように、ＣＰＡ管理テーブル４０１８（図４と同じもの）は、ＣＰＡを識別する固有の番号であるＣＰＡＩＤ１２０１と、ＣＰＡの状態を示す状態１２０２と、実データであるＣＰＡ１２０３との３つの項目から構成される。図１２（ｂ）に示すように、状態１２０２について、送信側取引装置Ａでは、「使用中」１２０４、「更新要求中」１２０５、「更新回答待ち」１２０６の３つの状態があり、受信側取引装置Ｂでは、「使用中」１２０４、「更新承認中」１２０７の２つの状態がある。ＣＰＡ登録後に通常のビジネスメッセージを送受信するときには、状態１２０２は「使用中」１２０４のままで変更されない。しかし、「ＣＰＡ更新要求」メッセージが送信されるときは、以下の手順で状態１２０２を変更する。まず、ＣＰＡ登録後の初期状態は、「使用中」１２０４である。業務担当者がＧＵＩ手段４０７を使用して「ＣＰＡ更新要求」を送信した後、送信側取引装置Ａのメッセージ交換プログラム４０６ａが、取引先企業の取引装置にメッセージを送信する過程で、状態１２０２を「更新要求中」１２０５に変更する。更に、メッセージ送信後に取引先企業の取引装置からそのメッセージに対するＡＣＫが返って来たとき、状態１２０２を「更新回答待ち」１２０６に変更する。一方、受信側取引装置Ｂのメッセージ交換プログラム４０６ａは、「ＣＰＡ更新要求」を受信し、そのメッセージに対するＡＣＫを返した後に、状態１２０２を「使用中」１２０４から「更新承認中」１２０７に変更する。その後、受信側取引装置Ｂでは、「ＣＰＡ更新要求」に対する「ＣＰＡ更新承認」または「ＣＰＡ更新否認」のメッセージを送信側取引装置Ａに送信し、そのメッセージに対するＡＣＫを受信する。このとき、双方のメッセージ交換プログラム４０６ａは、該当するＣＰＡを更新すると共に、その状態１２０２を「使用中」１２０４に戻す。以上のように、送信側取引装置Ａおよび受信側取引装置Ｂにおいて、ＣＰＡ更新要求時に状態１２０２を変更し、他のビジネスメッセージの処理がその状態１２０２をチェックすることによって、ＣＰＡ更新要求の処理中は、該当するＣＰＡを使用するビジネスメッセージの送受信処理を一時的に中断させることが可能となる。なお、請求項における「更新中」は、送信側取引装置Ａにおける「更新要求中」１２０５および「更新回答待ち」１２０６ならびに受信側取引装置Ｂにおける「更新承認中」１２０７を含むものとする。
【００２７】
≪システムの動作≫
図１３〜図２０を用いて、図６で示す「ＣＰＡ更新要求」時の一連の流れと、図４で示すメッセージ交換プログラム４０６ａの各機能の関連性を説明する。
【００２８】
図１３は、本発明の実施の形態に係る「ＣＰＡ更新要求」の送信処理の動作を示すフローチャートである。これは、「ＣＰＡ更新要求」の送信側取引装置で行われる動作である。まず、ＣＰＡの更新を行いたい業務担当者が、ＧＵＩ手段４０７が表示する「ＣＰＡ更新要求」の送信画面（図８参照）から「ＣＰＡ更新要求」を送信する（ステップＳ１３０１）。その後、送信側取引装置のメッセージ交換プログラム４０６ａのメッセージ作成手段４０１０が呼び出され、「ＣＰＡ更新要求」に対するｅｂＸＭＬメッセージを作成する（ステップＳ１３０２）。「ＣＰＡ更新要求」に対するメッセージを作成する処理の詳細については、図１４に示す。次に、メッセージ作成手段４０１０は、作成したメッセージをメッセージ管理手段４０１２に渡す。メッセージ管理手段４０１２は、受け取ったメッセージをＤＢ４０１６のメッセージ管理テーブル４０１７に格納すると共に、メッセージ送信手段４０９に渡す（ステップＳ１３０３）。ここで、メッセージをＤＢ４０１６に格納する理由は、ｅｂＸＭＬの高信頼配信の仕様に準拠するためである。ｅｂＸＭＬの高信頼配信では、送信したメッセージに対するＡＣＫが送信先の取引装置から所定の時間内に返って来ない場合、同じメッセージを再送する仕様となっている。したがって、所定の期間メッセージをＤＢなどの保管領域に保存しておく必要がある。本システムでは、メッセージをＤＢ４０１６のメッセージ管理テーブル４０１７に保管する。そして、メッセージ送信手段４０９が、受け取ったメッセージを取引先企業の取引装置に送信する（ステップＳ１３０４）。
【００２９】
図１４は、本発明の実施の形態に係る「ＣＰＡ更新要求」メッセージの作成処理の動作を示すフローチャートである。これは、「ＣＰＡ更新要求」の送信側取引装置で行われる動作である。図１３でＧＵＩ手段４０７から送られたメッセージが「ＣＰＡ更新要求」である場合（図８の画面から送信された場合）は、通常のビジネスメッセージの場合（図７の画面から送信された場合）とは引数などによる呼び出され方が異なる。したがって、メッセージ作成手段４０１０は、そのメッセージが「ＣＰＡ更新要求」であるか否かを判断することができる。メッセージ作成手段４０１０は、「ＣＰＡ更新要求」であることを確認すると、ＣＰＡ更新手段４０１３にそのメッセージに添付される添付情報（ＣＰＰまたはＣＰＡ）を渡す（ステップＳ１４０１）。ＣＰＡ更新手段４０１３は、添付情報を渡された後、まず、ＣＰＡ管理手段４０１５から現在設定されている既存のＣＰＡを取得し、ＣＰＡの状態を「使用中」から「更新要求中」に変更する（ステップＳ１４０２）。既存のＣＰＡは、ＣＰＡＩＤと共にＣＰＡ管理テーブル４０１８に管理されており、送られるメッセージのヘッダに含まれるＣＰＡＩＤによって取得することが可能である。
【００３０】
その後、ＣＰＡ更新手段４０１３は、受け取った添付情報がＣＰＰであるか否かを確認する（ステップＳ１４０３）。添付情報がＣＰＰである場合は（ステップＳ１４０３のＹｅｓ）、ステップＳ１４０２で取得した現在のＣＰＡと比較して変更点を抽出し、その抽出した変更点を反映することによって、更新ＣＰＡを作成する（ステップＳ１４０４）。図３で説明したように、ＣＰＡの中には、構成要素として取引企業それぞれのＣＰＰ情報が存在するが、その内容は、規則性がありほとんど同じである。したがって、前記のように一企業の更新するＣＰＰのみがＧＵＩ手段４０７から送信された場合でも、既存のＣＰＡを基に相手先の企業のＣＰＰ情報も更新することができる。故に、ステップＳ１４０４における更新ＣＰＡの作成処理が可能となる。一方、添付情報がＣＰＰでない、すなわち、ＣＰＡである場合は（ステップＳ１４０３のＮｏ）、その添付情報のＣＰＡをそのまま更新ＣＰＡとする（ステップＳ１４０５）。ここで、後で取引先企業の取引装置が「ＣＰＡ更新要求」を承認した場合、ＤＢ４０１６内の該当ＣＰＡを更新することになるため、ステップＳ１４０４またはステップＳ１４０５で取得する更新ＣＰＡは、メモリまたはファイル（または、ＤＢなどの保管領域）に保存しておく。その後、ＣＰＡ更新手段４０１３は、既存のＣＰＡと更新ＣＰＡとの差分リストを作成し、その作成した差分リストを更新ＣＰＡと共にメッセージ作成手段４０１０に渡す（ステップＳ１４０６）。そして、メッセージ作成手段４０１０がｅｂＸＭＬメッセージを作成する。作成にあたっては、メッセージヘッダのその他５０６の領域に「ＣＰＡ更新要求タグ」（例：<CPAUpdate/>）を付加し、添付として更新ＣＰＡおよび差分リストを添付する（ステップＳ１４０７）。送信先の取引装置のメッセージ交換プログラム４０６ａは、メッセージが「ＣＰＡ更新要求」であるか否かの判断に、この「ＣＰＡ更新要求タグ」を使用する。
【００３１】
図１５は、本発明の実施の形態に係る「ＣＰＡ更新要求」受信処理から「ＣＰＡ更新承認（否認）」送信処理までの動作を示すフローチャートである。これは、「ＣＰＡ更新要求」の受信側取引装置で行われる動作である。まず、メッセージ受信手段４０８が「ＣＰＡ更新要求」を受信し、メッセージ解析手段４０１１に渡す（ステップＳ１５０１）。メッセージ解析手段４０１１は、メッセージの形式がｅｂＸＭＬの仕様に準拠しているか否かをチェックし、準拠していれば、メッセージ管理手段４０１２にメッセージを渡す。準拠していなければ、メッセージ送信手段４０９経由でエラーメッセージを送信元の取引装置に返す。メッセージ管理手段４０１２は、メッセージを受け取ったら、添付情報を含めてＤＢ４０１６のメッセージ管理テーブル４０１７に格納（保存）すると共に、メッセージ送信手段４０９経由で「ＣＰＡ更新要求」に対するＡＣＫを送信元の取引装置に返す（ステップＳ１５０２）。その後、メッセージ解析手段４０１１は、メッセージヘッダに「ＣＰＡ更新要求タグ」が存在するか否かを確認する。存在する場合、ＣＰＡ更新手段４０１３にメッセージの添付情報（更新ＣＰＡおよび差分リスト）を渡す（ステップＳ１５０３）。なお、「ＣＰＡ更新要求タグ」が存在しない場合は、通常のビジネスメッセージであるので、ＣＰＡ更新手段４０１３は呼び出さずに、直接ＧＵＩ手段４０７経由でＧＵＩ画面上に受信メッセージを表示する。ＣＰＡ更新手段４０１３は、まず、ＣＰＡ管理手段４０１５経由でＣＰＡの状態を「使用中」から「更新承認中」に変更する（ステップＳ１５０４）。その後、渡された添付情報を基にして「ＣＰＡ更新要求」に対する承認または否認を行う（ステップＳ１５０５）。「ＣＰＡ更新要求」に対する承認または否認の処理の詳細については、図１６に示す。ステップＳ１５０５の結果から、メッセージ作成手段４０１０が「ＣＰＡ更新承認」または「ＣＰＡ更新否認」メッセージを作成する（ステップＳ１５０６）。「ＣＰＡ更新承認」または「ＣＰＡ更新否認」のメッセージの作成の処理の詳細については、図１７に示す。次に、メッセージ作成手段４０１０は、作成したメッセージをメッセージ管理手段４０１２に渡す。メッセージ管理手段４０１２は、受け取ったメッセージをＤＢ４０１６のメッセージ管理テーブル４０１７に格納すると共に、メッセージ送信手段４０９へ渡す（ステップＳ１５０７）。そして、メッセージ送信手段４０９が、受け取ったメッセージを取引先企業の取引装置に送信する（ステップＳ１５０８）。
【００３２】
図１６は、本発明の実施の形態に係る「ＣＰＡ更新要求」に対する承認または否認の処理の動作を示すフローチャートである。これは、「ＣＰＡ更新要求」の受信側取引装置で行われる動作である。まず、ＣＰＡ更新手段４０１３が、メッセージ解析手段４０１１から渡された添付情報の中の差分リストを解析し、どの範囲に対する修正なのかを確認する。そして、その修正範囲が図１１のＣＰＡ承認定義ファイルで定義された自動承認範囲または自動否認範囲に該当するか否かを比較検証する（ステップＳ１６０１）。その比較検証の結果から、まず、全ての修正範囲がＣＰＡ承認定義ファイル内の自動承認範囲であるか否かを確認する（ステップＳ１６０２）。全てが自動承認範囲である場合（ステップＳ１６０２のＹｅｓ）、ＣＰＡ更新手段４０１３がメッセージ解析手段４０１１経由でＧＵＩ手段４０７を呼び出し、ＧＵＩ手段４０７が「ＣＰＡ更新要求」メッセージ（自動承認済）９０３を表示する（ステップＳ１６０４）。そして、ＣＰＡ更新手段４０１３が、メッセージ作成手段４０１０に「ＣＰＡ更新承認」メッセージの作成を依頼する（ステップＳ１６０８）。一方、全てが自動承認範囲ではない場合（ステップＳ１６０２のＮｏ）、少なくとも１つの修正範囲が自動否認範囲であるか否かを確認する（ステップＳ１６０３）。少なくとも１つが自動否認範囲である場合（ステップＳ１６０３のＹｅｓ）、ＣＰＡ更新手段４０１３がメッセージ作成手段４０１０に「ＣＰＡ更新否認」メッセージの作成を依頼する（ステップＳ１６０９）。全てが自動否認範囲でない場合（ステップＳ１６０３のＮｏ）、ＧＵＩ手段４０７が「ＣＰＡ更新要求」メッセージ（承認処理要）９０４を表示する（ステップＳ１６０５）。このとき、ユーザである業務担当者の判断が必要となるため、業務担当者は、図１０の「ＣＰＡ更新要求」に対する承認画面によって承認か否認かを判定する（ステップＳ１６０６）。業務担当者が承認する場合（ステップＳ１６０７のＹｅｓ）、ステップＳ１６０８が実行される。業務担当者が否認する場合（ステップＳ１６０７のＮｏ）、ステップＳ１６０９が実行される。
なお、「ＣＰＡ更新要求」の受信側取引装置において、自動否認したＣＰＡ更新要求メッセージを表示するようにしてもよい。これによれば、自動否認したＣＰＡ更新要求メッセージの内容をチェックすることによって、ＣＰＡ承認定義ファイルの内容の修正や改善を検討することが可能になる。
【００３３】
図１７は、本発明の実施の形態に係る「ＣＰＡ更新承認」と「ＣＰＡ更新否認」のメッセージの作成処理の動作を示すフローチャートである。これは、「ＣＰＡ更新要求」の受信側取引装置で行われる動作である。まず、メッセージ作成手段４０１０が、ＣＰＡ更新手段４０１３から受けた依頼内容を確認する（ステップＳ１７０１）。依頼内容が「ＣＰＡ更新承認」のメッセージ作成依頼の場合（ステップＳ１７０２のＹｅｓ）、メッセージ作成手段４０１０は、メッセージヘッダのその他５０６の領域に、「ＣＰＡ更新回答タグ」を“ＯＫ”の値と共に付加し（例：<CPAResponse>OK</CPAResponse>）、「ＣＰＡ更新承認」メッセージを作成する（ステップＳ１７０３）。一方、依頼内容が「ＣＰＡ更新否認」のメッセージ作成依頼の場合（ステップＳ１７０２のＮｏ）、メッセージ作成手段４０１０は、メッセージヘッダのその他５０６の領域に、「ＣＰＡ更新回答タグ」を“ＮＧ”の値と共に付加し（例：<CPAResponse>NG</CPAResponse>）、「ＣＰＡ更新否認」メッセージを作成する（ステップＳ１７０４）。
図１４のステップＳ１４０７ならびに図１７のステップＳ１７０３もしくはステップＳ１７０４のように、前記タグを付加することによって、メッセージを受信した取引装置において、そのメッセージがＣＰＡ更新要求メッセージなのか、回答メッセージなのかを明確に識別できる。また、前記タグの有無によって、そのメッセージがＣＰＡ更新に関するメッセージなのか、通常の電子商取引のためのビジネスメッセージなのかを識別できる。
【００３４】
図１８は、本発明の実施の形態に係る「ＣＰＡ更新要求」に対するＡＣＫ受信処理の動作を示すフローチャートである。これは、「ＣＰＡ更新要求」の送信側取引装置で行われる動作である。まず、メッセージ受信手段４０８が「ＣＰＡ更新要求」メッセージに対するＡＣＫを受信し、メッセージ解析手段４０１１に渡す（ステップＳ１８０１）。メッセージ解析手段４０１１は、「ＣＰＡ更新要求」に対するＡＣＫであることを確認し、その情報をＣＰＡ更新手段４０１３に渡す（ステップＳ１８０２）。「ＣＰＡ更新要求」に対するＡＣＫであることを確認するには、例えば、メッセージの送信時に「ＣＰＡ更新要求」であることが分かるようなメッセージＩＤを付与しておき、ＡＣＫの受信時に返されたメッセージＩＤをチェックする方法などが考えられる。ＣＰＡ更新手段４０１３は、ＣＰＡ管理手段４０１５を呼び出し、該当するＣＰＡの状態を「更新要求中」から「更新回答待ち」にする（ステップＳ１８０３）。
【００３５】
図１９は、本発明の実施の形態に係る「ＣＰＡ更新承認」と「ＣＰＡ更新否認」の受信処理の動作を示すフローチャートである。これは、「ＣＰＡ更新要求」の送信側取引装置で行われる動作である。まず、メッセージ受信手段４０８が「ＣＰＡ更新承認」または「ＣＰＡ更新否認」メッセージを受信し、その受信したメッセージをメッセージ解析手段４０１１に渡す（ステップＳ１９０１）。メッセージ解析手段４０１１は、その渡されたメッセージの形式がｅｂＸＭＬの仕様に準拠しているか否かをチェックし、準拠していればメッセージ管理手段４０１２にメッセージを渡す。準拠していなければ、メッセージ送信手段４０９経由でエラーメッセージをメッセージ送信元の取引装置に返す。メッセージ管理手段４０１２は、メッセージを受け取ったら、ＤＢ４０１６のメッセージ管理テーブル４０１７に格納すると共に、メッセージ送信手段４０９経由で「ＣＰＡ更新承認」または「ＣＰＡ更新否認」に対するＡＣＫをメッセージ送信元の取引装置に返す（ステップＳ１９０２）。その後、メッセージ解析手段４０１１は、メッセージヘッダに「ＣＰＡ更新回答タグ」が存在するか否かとそのタグ値を確認し、その情報をＣＰＡ更新手段４０１３に渡す（ステップＳ１９０３）。ＣＰＡ更新手段４０１３は、その渡された情報から「ＣＰＡ更新回答タグ」の値を確認する（ステップＳ１９０４）。「ＣＰＡ更新回答タグ」の値が“ＯＫ”の場合（ステップＳ１９０５のＹｅｓ）、ＣＰＡ管理手段４０１５を呼び出し、保存されている更新ＣＰＡでＣＰＡを更新すると共に、ＣＰＡの状態を「更新回答待ち」から「使用中」に変更する（ステップＳ１９０６）。一方、「ＣＰＡ更新回答タグ」の値が“ＮＧ”の場合（ステップＳ１９０５のＮｏ）、ＣＰＡ管理手段４０１５を呼び出し、ＣＰＡの状態を「更新回答待ち」から「使用中」に変更する（ステップＳ１９０７）。ＣＰＡの更新要求が否認されたため、保存されていた更新ＣＰＡは削除し、ＤＢ４０１６内の該当ＣＰＡの更新は行わない。そして、ＣＰＡ更新手段４０１３が、メッセージ解析手段４０１１経由でＧＵＩ手段４０７を呼び出し、受信した「ＣＰＡ更新承認」または「ＣＰＡ更新否認」のメッセージを表示する（ステップＳ１９０８）。
【００３６】
図２０は、本発明の実施の形態に係る「ＣＰＡ更新承認」と「ＣＰＡ更新否認」に対するＡＣＫ受信処理の動作を示すフローチャートである。これは、「ＣＰＡ更新要求」の受信側取引装置で行われる動作である。まず、メッセージ受信手段４０８が、「ＣＰＡ更新承認」または「ＣＰＡ更新否認」のメッセージに対するＡＣＫを受信し、その受信したＡＣＫをメッセージ解析手段４０１１に渡す（ステップＳ２００１）。メッセージ解析手段４０１１は、その渡されたＡＣＫが「ＣＰＡ更新承認」または「ＣＰＡ更新否認」に対するＡＣＫであることを確認し、その情報をＣＰＡ更新手段４０１３に渡す（ステップＳ２００２）。「ＣＰＡ更新承認」または「ＣＰＡ更新否認」に対するＡＣＫであることを確認するには、例えば、メッセージの送信時に「ＣＰＡ更新承認」または「ＣＰＡ更新否認」であることが分かるようなメッセージＩＤを付与しておき、ＡＣＫの受信時に返されたメッセージＩＤをチェックする方法などが考えられる。ＣＰＡ更新手段４０１３は、その渡された情報から「ＣＰＡ更新承認」と「ＣＰＡ更新否認」のいずれに対するＡＣＫであるかを確認する（ステップＳ２００３）。その確認の結果、「ＣＰＡ更新承認」に対するＡＣＫの場合（ステップＳ２００４のＹｅｓ）、ＣＰＡ管理手段４０１５を呼び出し、保存されている更新ＣＰＡでＣＰＡを更新すると共に、ＣＰＡの状態を「更新承認中」から「使用中」に変更する（ステップＳ２００５）。一方、「ＣＰＡ更新否認」に対するＡＣＫの場合（ステップＳ２００４のＮｏ）、ＣＰＡ管理手段４０１５を呼び出し、ＣＰＡの状態を「更新承認中」から「使用中」に変更する（ステップＳ２００６）。ＣＰＡの更新要求が否認されたため、保存してあった更新ＣＰＡは削除し、ＤＢ４０１６内の該当ＣＰＡの更新は行わない。
【００３７】
以上本発明の実施の形態について説明したが、図４に示すメッセージ交換プログラム４０６ａの各手段で実行されるプログラムをコンピュータによる読み取り可能な記録媒体に記録し、この記録媒体に記録されたプログラムをコンピュータシステムに読み込ませ、実行することにより、本発明の実施の形態に係る取引装置が実現されるものとする。ここでいうコンピュータシステムとは、ＯＳ（Operating System）などのソフトウエアや周辺機器などのハードウエアを含むものである。
【００３８】
≪その他の実施の形態≫
以上本発明について好適な実施の形態について一例を示したが、本発明は前記実施の形態に限定されず、本発明の趣旨を逸脱しない範囲で適宜変更が可能である。例えば、以下のような実施の形態が考えられる。
（１）前記実施の形態においては、取引装置がメッセージを受信したとき、メッセージ送信元の取引装置にＡＣＫを返すように記載したが、ＡＣＫの返信を省略してもよい。これによれば、メッセージを送信した後、送信先の取引装置からのＡＣＫの受信待ちを行う必要がなくなり、メッセージ交換プログラムの処理を減らすことができる。
（２）前記実施の形態においては、ＣＰＡ更新要求の受信側取引装置が、受信したメッセージの添付情報である更新ＣＰＡによってＣＰＡを更新するように記載したが、更新ＣＰＡを使用することなく、もう一つの添付情報である差分リストによってＣＰＡを更新するようにしてもよい。これによれば、更新ＣＰＡを保持しておく必要がないので、その分のメモリ容量を節減することができる。なお、これは、ＣＰＡ更新要求の送信側取引装置においても適用可能である。
【図面の簡単な説明】
【００３９】
【図１】本発明の実施の形態に係るｅｂＸＭＬの概略を示す図である。
【図２】本発明の実施の形態に係るＣＰＰの内容例を示す図である。
【図３】本発明の実施の形態に係るＣＰＡの構成を示す図である。
【図４】本発明の実施の形態に係る電子商取引システムの構成を示す図である。
【図５】本発明の実施の形態に係るｅｂＸＭＬメッセージの形式を示す図である。
【図６】本発明の実施の形態に係るＣＰＡ更新要求メッセージを送信する際の処理手順全体を示す図である。
【図７】本発明の実施の形態に係るビジネスメッセージの送信画面例である。
【図８】本発明の実施の形態に係るＣＰＡ更新要求メッセージの送信画面例である。
【図９】本発明の実施の形態に係るＧＵＩ手段のメイン画面の例である。
【図１０】本発明の実施の形態に係るＣＰＡ更新要求に対する承認画面の例である。
【図１１】本発明の実施の形態に係るＣＰＡ承認定義ファイルの定義例を示す図である。
【図１２】本発明の実施の形態に係るＣＰＡ管理テーブルの内容例とＣＰＡの状態遷移を示す図である。（ａ）は、ＣＰＡ管理テーブルの内容例を示す。（ｂ）は、送信側取引装置と受信側取引装置におけるＣＰＡの状態遷移を示す。
【図１３】本発明の実施の形態に係るＣＰＡ更新要求の送信処理の動作を示すフローチャートである。
【図１４】本発明の実施の形態に係るＣＰＡ更新要求のメッセージの作成処理の動作を示すフローチャートである。
【図１５】本発明の実施の形態に係るＣＰＡ更新要求の受信処理からＣＰＡ更新承認（否認）の送信処理までの動作を示すフローチャートである。
【図１６】本発明の実施の形態に係るＣＰＡ更新要求に対する承認または否認の処理の動作を示すフローチャートである。
【図１７】本発明の実施の形態に係るＣＰＡ更新承認とＣＰＡ更新否認のメッセージの作成処理の動作を示すフローチャートである。
【図１８】本発明の実施の形態に係るＣＰＡ更新要求に対するＡＣＫ受信処理の動作を示すフローチャートである。
【図１９】本発明の実施の形態に係るＣＰＡ更新承認とＣＰＡ更新否認の受信処理の動作を示すフローチャートである。
【図２０】本発明の実施の形態に係るＣＰＡ更新承認とＣＰＡ更新否認に対するＡＣＫ受信処理の動作を示すフローチャートである
【符号の説明】
【００４０】
４００    電子商取引システム
４０１    自社取引装置（第１の取引装置）
４０２    相手先取引装置（第２の取引装置）
４０３    モニタ
４０４    ＣＰＵ
４０５    通信アダプタ
４０６    メモリ
４０６ａ  メッセージ交換プログラム
４０７    ＧＵＩ手段（第１のユーザ入出力手段、第２のユーザ入出力手段）
４０８    メッセージ受信手段（第１のメッセージ受信手段、第２のメッセージ受信手段）
４０９    メッセージ送信手段（第１のメッセージ送信手段、第２のメッセージ送信手段）
４０１０  メッセージ作成手段（第１のメッセージ作成手段、第２のメッセージ作成手段）
４０１３  ＣＰＡ更新手段（ＣＰＡ更新判定手段）
４０１４  ＣＰＡ承認定義ファイル（判定条件データ記憶手段）
４０１５  ＣＰＡ管理手段（第１のＣＰＡ更新手段、第２のＣＰＡ更新手段）
４０１６  ＤＢ（第１のＣＰＡ記憶手段、第２のＣＰＡ記憶手段）
４０２０  ネットワーク
【図１】
2005353007.tif 000003
【図２】
2005353007.tif 000004
【図３】
2005353007.tif 000005
【図４】
2005353007.tif 000006
【図５】
2005353007.tif 000007
【図６】
2005353007.tif 000008
【図７】
2005353007.tif 000009
【図８】
2005353007.tif 000010
【図９】
2005353007.tif 000011
【図１０】
2005353007.tif 000012
【図１１】
2005353007.tif 000013
【図１２】
2005353007.tif 000014
【図１３】
2005353007.tif 000015
【図１４】
2005353007.tif 000016
【図１５】
2005353007.tif 000017
【図１６】
2005353007.tif 000018
【図１７】
2005353007.tif 000019
【図１８】
2005353007.tif 000020
【図１９】
2005353007.tif 000021
【図２０】
2005353007.tif 000022