(57)【要約】【課題】  特に中規模な企業にも適した柔軟な構成をとる電子商取引システムを提供する。【解決手段】  電子商取引システム１の利用企業は、この電子商取引システム１を利用する際に取引企業との間でやりとりされるＸＭＬ形式のビジネスメッセージの形式と、このビジネスメッセージの送信先とを対応づけて記載したビジネスプロファイルを、ディスパッチサーバ１００に登録する。ディスパッチサーバ１００は、取引先企業（Ｂ社）から送信されるビジネスメッセージを利用企業（Ａ社）があらかじめ定めた振り分け規則に従い、Ａ社のコンバートサーバ２００かウェブサーバ１０１に転送するかを決定し、その通りに送信する。【選択図】  図１
2006277046.tif 000002
【特許請求の範囲】
【請求項１】
通信ネットワークを介して複数のクライアント装置に接続され、前記複数のクライアント装置間で取引の進行に応じて交換される電子メッセージの交換を仲介することにより取引を進行させる電子商取引システムであって、
前記クライアント装置のために対話式インターフェイスを提供するウェブサーバと、
前記クライアント装置あるいは前記ウェブサーバから取引の進行中の各段階に応じて定められた取引段階識別情報を含んだ電子メッセージを受け付け、受け付けた電子メッセージを前記通信ネットワークで接続された前記クライアント装置あるいは前記ウェブサーバに送信する振り分けサーバと、
を備え、
前記振り分けサーバは、
前記取引段階識別情報と電子メッセージの送付先を示す送付先情報とを対応づけて格納する取引手順記憶手段と、
前記クライアント装置あるいは前記ウェブサーバから電子メッセージを受け付ける電文受け付け手段と、
前記電文受け付け手段で受け付けた電子メッセージに含まれている前記取引段階識別情報に対応づけられている送信先情報を、前記取引手順記憶手段に格納されている情報から検索し、検索した送付先情報に従って、該電子メッセージを前記複数のクライアント装置のうちの１つに送信するか前記ウェブサーバに送信するかを判別し、送信先として判別された前記ウェブサーバあるいはクライアント装置へ電子メッセージを送信するメッセージ振り分け手段と、
を具備し、
前記ウェブサーバは、前記通信ネットワークを介して前記振り分けサーバと前記複数のクライアント装置とに接続され、利用者からの入力操作に応答して電子メッセージを生成し前記振り分けサーバに送信すること、
を特徴とする電子商取引システム。
【請求項２】
前記振り分けサーバは、さらに
各クライアント装置へ送信するための電子メッセージの記述形式を示すフォーマット情報を格納する形式記憶手段を具備し、
前記メッセージ振り分け手段は、前記電文受け付け手段で受け付けた電子メッセージを、前記形式記憶手段に格納されている送信先のクライアント装置に対応するフォーマット情報に示される記述形式に変換して振り分ける、
ことを特徴とする請求項１に記載の電子商取引システム。
【請求項３】
前記振り分けサーバは、さらに、
取引単位で、取引の段階を記録する取引段階記憶手段と、
前記電文メッセージ受け付け手段で受け付けた電子メッセージに含まれている取引段階識別情報に従って、前記取引段階記憶手段に格納された取引の段階を更新する更新手段と、
を特徴とする請求項１または２に記載の電子商取引システム。
【請求項４】
前記ウェブサーバは、
前記メッセージ振り分け手段が送信した電子メッセージに従って、対話処理のための表示画面を生成する表示画面生成手段と、
前記対話処理における応答入力を受け付ける入力受け付け手段と、
前記入力受け付け手段で受け付けた応答入力に従って、前記メッセージ振り分け手段が送信した電子メッセージに含まれている取引段階識別情報の次の段階に相当する取引段階識別情報を含む電子メッセージを作成し、前記振り分けサーバに送信するメッセージ送信手段と、
を具備することを特徴とする請求項１、２または３に記載の電子商取引システム。
【請求項５】
通信ネットワークを介してクライアント装置と、対話型処理に使用される情報処理装置とに接続されたサーバ装置が、
クライアント装置あるいは情報処理装置から、商取引の進行のために送信される電子メッセージを受信する受信ステップと、
前記受信ステップで受信した電子メッセージを、取引の進行中の各段階に応じて定められた取引段階識別情報と電子メッセージの送付先を示す送信先情報とを対応づけた進行シナリオデータに従って、前記複数のクライアント装置のうちの１つに送信するか、あるいは前記情報処理装置に送信するかを判別する判別ステップと、
前記判別ステップにおける判別結果に応じて該電子メッセージをクライアント装置あるいは前記情報処理装置に送信する送信ステップと、
を備えることを特徴とする電子商取引処理方法。
【請求項６】
通信ネットワークを介して、クライアント装置と対話型処理に使用される仲介装置とに接続され、電子商取引の進行シナリオに基づいてあらかじめ作成された電子メッセージ単位で、電子メッセージが送信される取引の段階を識別する取引段階識別情報と該電子メッセージの送信先とを対応づけて記載した振り分け先データを格納した、情報処理装置が、
クライアント装置から電子商取引の進行のために送信される電子メッセージを受信し、
受信した電子メッセージを、前記振り分け先データに従って、前記複数のクライアント装置のうちの１つに送信するか、あるいは前記仲介装置に送信するかを判別し、
判別した通りに該電子メッセージをクライアント装置あるいは前記仲介装置に送信する、
電子商取引装置として機能させることを特徴とするプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、電子商取引システム、電子商取引処理方法およびプログラムに関し、特にサーバクライアント方式の電子商取引システム、電子商取引処理方法およびプログラムに関する。
【背景技術】
【０００２】
企業間電子商取引は、１９７０年代より電子データ交換（Electronic Data Interchange、ＥＤＩ）によって始まった。ＥＤＩでは、プログラムが理解できるデータ交換用のＥＤＩメッセージフォーマットを使用する。ＥＤＩメッセージフォーマットには、全銀協手順やＪＣＡ（日本チェーンストア協会）手順など業種ごとに特化したメッセージフォーマットが並立していた。
【０００３】
このため、例えば特許文献１で触れられているように、拡張性に富んだデータ表現形式であるＸＭＬ（eXtensible Markup Language）を用いたメッセージ交換により電子商取引を行うため、規格化や接続実験が進められている。例えば、ＵＮ／ＣＥＦＡＣＴ（United Nations Centre for Trade Facilitation and Electronic Business）とＯＡＳＩＳ（Organization for the Advancement of Structured Information Standards）とが策定しているｅｂＸＭＬ（Electronic Business XML）がある。
【０００４】
ＸＭＬ形式のメッセージ交換を使用する電子商取引では、従来のＥＤＩの反省を生かし業務とその業務の流れとに重点をおいている。
【特許文献１】特開２００３−９１５３０号公報（第２頁）
【発明の開示】
【発明が解決しようとする課題】
【０００５】
従来のＥＤＩのみを利用した電子商取引を行うためには、特定の標準メッセージの送受信を専用に行うパッケージソフトウェアを購入した上で、このパッケージソフトウェアと自社の業務システムと連携させるソフトウェアを個別に開発しなければならなかった。さらに、情報を交換する複数の取引相手があり、そのうちのある取引相手が異なる標準メッセージや独自の交換メッセージを使用している場合には、取引相手ごとにソフトウェアをチューニングしたり、別ソフトウェアを開発したりしなければならなかった。このため、ＥＤＩを利用した電子商取引は、大量の取引をこなさなければならない大企業でしか利用する意味がなかった。
【０００６】
近年、ウェブブラウザプログラムを介してウェブサーバにアクセスし、このウェブサーバで商品の受発注処理を行うシステム（以下、ＷＥＢ−ＥＤＩシステムと称する）が利用されている。
【０００７】
ＷＥＢ−ＥＤＩシステムの運営形態は、ウェブサーバを需要側の企業が運営する場合と、供給側の企業が運営する場合とに大きく分かれる。どちらの運営形態も、需要側または供給側のどちらか一方の企業が運営することが前提となっている。
【０００８】
ＷＥＢ−ＥＤＩシステムは、ネットワーク接続にインターネットが使用可能で、専用線やＶＡＮ（Value Added Network）を使う必要はない。また、取引先のＷＥＢ−ＥＤＩシステムのみを利用することにすれば、既存の社内システムを更新する必要もない。このため、従来のＥＤＩシステムよりも格段に安く導入できる。しかし、取引量が多くなると、ＷＥＢ−ＥＤＩシステム上での操作が増え、作業量が増えてしまう。
【０００９】
このため、取引先とのデータ交換の量がほどほどの企業にとっては、ＥＤＩのような、企業間でデータを交換しながら取引を進める形態、ウェブブラウザ上のインターフェイスを利用して取引を進める形態共に、適さない取引形態となる。
【００１０】
本発明は上記問題点に鑑みてなされたもので、設定に応じて自動的なデータ交換と対話的なデータ交換とを併用することのできる電子商取引システム、電子商取引処理方法およびプログラムを提供することを目的とする。
【課題を解決するための手段】
【００１１】
本発明の第１の観点に係る電子商取引システムは、
通信ネットワークを介して複数のクライアント装置に接続され、前記複数のクライアント装置間で取引の進行に応じて交換される電子メッセージの交換を仲介することにより取引を進行させる電子商取引システムであって、
前記クライアント装置のために対話式インターフェイスを提供するウェブサーバと、
前記クライアント装置あるいは前記ウェブサーバから取引の進行中の各段階に応じて定められた取引段階識別情報を含んだ電子メッセージを受け付け、受け付けた電子メッセージを前記通信ネットワークで接続された前記クライアント装置あるいは前記ウェブサーバに送信する振り分けサーバと、
を備え、
前記振り分けサーバは、
前記取引段階識別情報と電子メッセージの送付先を示す送付先情報とを対応づけて格納する取引手順記憶手段と、
前記クライアント装置あるいは前記ウェブサーバから電子メッセージを受け付ける電文受け付け手段と、
前記電文受け付け手段で受け付けた電子メッセージに含まれている前記取引段階識別情報に対応づけられている送信先情報を、前記取引手順記憶手段に格納されている情報から検索し、検索した送付先情報に従って、該電子メッセージを前記複数のクライアント装置のうちの１つに送信するか前記ウェブサーバに送信するかを判別し、送信先として判別された前記ウェブサーバあるいはクライアント装置へ電子メッセージを送信するメッセージ振り分け手段と、
を具備し、
前記ウェブサーバは、前記通信ネットワークを介して前記振り分けサーバと前記複数のクライアント装置とに接続され、利用者からの入力操作に応答して電子メッセージを生成し前記振り分けサーバに送信する。
【００１２】
この発明によれば、振り分けサーバが、取引手順記憶手段に格納されている取引の進行中の各段階に応じて定められた取引段階識別情報と電子メッセージの送付先情報とに従って、取引中に交換される電子メッセージを、対話式インターフェイスを提供するウェブサーバ、あるいはクライアント装置に振り分ける。このため、利用者側で取引の進行に応じて電子メッセージの送付先を設定したものを振り分けサーバに格納しておけば、振り分けサーバはこれに従って電子メッセージを振り分ける。
【００１３】
上記電子商取引システムにおいて、
前記振り分けサーバ装置は、さらに
各クライアント装置へ送信するための電子メッセージの記述形式を示すフォーマット情報を格納する形式記憶手段を具備することが望ましい。この場合、
前記メッセージ振り分け手段は、前記電文受け付け手段で受け付けた電子メッセージを、前記形式記憶手段に格納されている送信先のクライアント装置に対応するフォーマット情報に示される記述形式に変換して振り分ける。
【００１４】
この発明によれば、電子商取引システムにおいて、電子メッセージの新たな記述形式への対応が容易であり、電子商取引システムの拡張性が高まる。
【００１５】
上記電子商取引システムにおいて、
前記振り分けサーバは、例えば、
取引単位で、取引の段階を記録する取引段階記憶手段と、
前記電文メッセージ受け付け手段で受け付けた電子メッセージに含まれている取引段階識別情報に従って、前記取引段階記憶手段に格納された取引の段階を更新する更新手段と、
を具備する。
【００１６】
上記電子商取引システムにおいて、
前記ウェブサーバは、例えば、
前記メッセージ振り分け手段が送信した電子メッセージに従って、対話処理のための表示画面を生成する表示画面生成手段と、
前記対話処理における応答入力を受け付ける入力受け付け手段と、
前記入力受け付け手段で受け付けた応答入力に従って、前記メッセージ振り分け手段が送信した電子メッセージに含まれている取引段階識別情報の次の段階に相当する取引段階識別情報を含む電子メッセージを作成し、前記振り分けサーバに送信するメッセージ送信手段と、
を具備する。
【００１７】
本発明の第２の観点に係る電子商取引処理方法は、
通信ネットワークを介してクライアント装置と、対話型処理に使用される情報処理装置とに接続されたサーバ装置が、
クライアント装置あるいは情報処理装置から、商取引の進行のために送信される電子メッセージを受信する受信ステップと、
前記受信ステップで受信した電子メッセージを、取引の進行中の各段階に応じて定められた取引段階識別情報と電子メッセージの送付先を示す送信先情報とを対応づけた進行シナリオデータに従って、前記複数のクライアント装置のうちの１つに送信するか、あるいは前記情報処理装置に送信するかを判別する判別ステップと、
前記判別ステップにおける判別結果に応じて該電子メッセージをクライアント装置あるいは前記情報処理装置に送信する送信ステップと、
を備える。
【００１８】
本発明の第３の観点に係るプログラムは、
通信ネットワークを介して、クライアント装置と対話型処理に使用される仲介装置とに接続され、電子商取引の進行シナリオに基づいてあらかじめ作成された電子メッセージ単位で、電子メッセージが送信される取引の段階を識別する取引段階識別情報と該電子メッセージの送信先とを対応づけて記載した振り分け先データを格納した、情報処理装置が、
クライアント装置から電子商取引の進行のために送信される電子メッセージを受信し、
受信した電子メッセージを、前記振り分け先データに従って、前記複数のクライアント装置のうちの１つに送信するか、あるいは前記仲介装置に送信するかを判別し、
判別した通りに該電子メッセージをクライアント装置あるいは前記仲介装置に送信する、
電子商取引装置として機能させる。
【発明の効果】
【００１９】
本発明によれば、その企業の想定する電子商取引の進行シナリオに従って、電子商取引のために交換される電子メッセージの送信先を振り分ける電子商取引システムを提供することができる。
【発明を実施するための最良の形態】
【００２０】
本発明に係る実施の形態を、以下図面を参照して説明する。図１は、本発明の実施の形態に係る電子商取引システムの構成を示すブロック図である。
【００２１】
本実施形態の電子商取引システム１は、ディスパッチサーバ１００と、ウェブサーバ１０１と、コンバートサーバ２００と、ＰＣ３００と、ＢＰＩ（Business Process Integration）サーバ４００とにより構成される。これらの各装置は通信ネットワークＣを介して接続されている。
【００２２】
通信ネットワークＣは、例えば、ＴＣＰ／ＩＰ（Transmission Control Protocol/Internet Protocol）などの所定の通信プロトコルに基づくＬＡＮ（Local Area Network）などの通信ネットワークである。
【００２３】
ディスパッチサーバ１００は、ユーザ企業（会社Ａ）と取引企業（会社Ｂ）との間のメッセージを仲介し、また、拡張したSpecification Schemaに基づいて記述されたビジネスプロセスの管理や取引先とのメッセージ変換を受け持つ。ディスパッチサーバ１００では、拡張Specification Schemaに基づいて記述されたビジネスプロセスを管理することで、ウェブサーバ１０１とコンバートサーバ２００との連携を可能にする。
ディスパッチサーバ１００は、ＸＭＬ形式で記述されたメッセージをウェブサーバ１０１か、企業に設置されているコンバートサーバ２００やＢＰＩサーバ４００かへ振り分ける。振り分ける基準は拡張Specification Schemaに基づいて記載されたビジネスプロファイルに記述される。
【００２４】
なお、本電子商取引システム１において交換されるメッセージには、「プロセスコード」、や送信元の情報、送信先の情報、「トランザクションの名称」およびメッセージ本体、などを含む。
【００２５】
ここで、「プロセスコード」とは本電子商取引システム１において、進行中の電子商取引（以下、単に商取引と称する。）の識別情報であり、商取引の開始時に、コンバートサーバ２００やＢＰＩサーバ４００が所定の命名規則にしたがって付与する。「トランザクションの名称」は、商取引においてメッセージが交換される段階を特定するための識別情報であり、ビジネスプロファイルの作成時に定義される。
【００２６】
ディスパッチサーバ１００は、例えば図２に示すように、制御部１１０と、記憶部１２０と、入力制御部１３０と、出力制御部１４０と、通信制御部１５０とを備える。そして、入力制御部１３０に入力装置１３が、出力制御部１４０に出力装置１４がそれぞれ接続されている。
【００２７】
制御部１１０はＣＰＵ（Central Processing Unit）等のプロセッサからなり、記憶部１２０に格納されている動作プログラムを読み出して実行することにより、例えば、図３に示すような、メッセージングサービス１１１、ビジネスプロセス処理部１１２、メッセージ変換部１１３などを実現する。制御部１１０は、ディスパッチサーバ１００の各部を制御しつつ、後述する見積・発注処理などを実行する。
【００２８】
メッセージングサービス１１１は、通信制御部１５０から送信される各種メッセージを受け取り、ビジネスプロセス処理部１１２に転送する。また、通信制御部１５０を経由して、メッセージ変換部１１３から送信された変換後の各種メッセージをこのメッセージの送信先として指定されたサーバに送信する。
【００２９】
ビジネスプロセス処理部１１２は、メッセージングサービス１１１から受け取ったメッセージに付加されている送信元と送信先、および「プロセスコード」「トランザクションの名称」を参照する。
ビジネスプロセス処理部１１２は、記憶部１２０内を検索し、この「プロセスコード」と対応づけられている「取引状態情報」が格納されていれば、その「取引状態情報」に含まれているビジネスプロファイルの記載に従い、転送されてきたメッセージがそのビジネスプロファイル上で記載されているどの「プロセス状態」で送信されたものなのかを判別する。そして、「取引状態情報」に新しい「プロセス状態」に遷移したことを記録する。また、このビジネスプロファイルの記載に従い、転送されてきたメッセージの変換形式を判別する。より正確には、ビジネスプロファイルに記載されたメッセージの変換方法を規定するファイル（以下、データ変換定義と称する）の名称から、そのメッセージの変換形式を判別する。
記憶部１２０内を検索し、この「プロセスコード」と対応づけられている「取引状態情報」が格納されていなければ、ビジネスプロセス処理部１１２は、送信元あるいは送信先として指定されている企業名から、このメッセージがどのビジネスプロファイルに基づいて送信されてきたものなのか、およびそのビジネスプロファイル上で記載されているどの「プロセス状態」で送信されたものなのかを判別する。この際、送信元あるいは送信先として指定されている企業名だけで判別できない場合は、さらに「トランザクションの名称」にも従って判別する。ビジネスプロセス処理部１１２は、記憶部１２０内に「プロセスコード」と対応づけられる「取引状態情報」登録する。また、判別されたビジネスプロファイルの記載に従い、転送されてきたメッセージの変換形式を判別する。
ビジネスプロセス処理部１１２は、受信したデータ、データ変換方式と次の送信先の情報をメッセージ変換部１１３に渡す。
【００３０】
メッセージ変換部１１３は、ビジネスプロセス処理部１１２から受け渡されるメッセージの形式をビジネスプロセス処理部１１２で判別された変換形式に変換し、メッセージングサービス１１１に転送する。メッセージの形式を変更する際、ビジネスプロファイルにより指定されているデータ変換定義を参照する。
【００３１】
図２に戻って、記憶部１２０は、ハードディスク装置などの記憶装置から構成され、制御部１１０で実行される動作プログラムや見積・発注処理などにおいて参照されるデータや同処理などで生成される一時データ、などを格納する。図４は、記憶部１２０に格納されるデータを説明するための図である。記憶部１２０は、企業情報データベース（ＤＢ）１２１と、プロセスデータベース（ＤＢ）１２２と、プログラム記憶部１２５とを備える。
【００３２】
企業情報ＤＢ１２１は、本電子商取引システム１を利用している企業に関し、システム利用上必要な企業情報を格納する。図５に示すように、企業情報ＤＢ１２１には企業ごとに一意に割り当てられた「企業コード」を主キーとするレコードが作成される。格納される企業情報は、「企業名」、「属性情報」、「定義ファイル情報」などを含む。
【００３３】
ここで、「企業コード」とは本電子商取引システム１の利用企業の識別情報であり、電子商取引システム１の管理者が付与する。「企業名」は、利用企業の名称を示す情報である。「属性情報」は、企業に関する属性を示す種々の情報であり、例えば、利用企業の住所（本社所在地）、担当者名、企業が本電子商取引システム１で使用する端末のＩＰアドレス、等である。「定義ファイル情報」は、利用企業が電子商取引システム１利用の際に交換されるメッセージの形式とその送信先とを対応づけて記載したビジネスプロファイルのファイル名と、電子商取引システム１内で送受信されるメッセージの形式に整合性をつけるためメッセージ形式の変換方法を定義したＸＳＬＴファイルのファイル名とを関連付けて格納する。なお、これらのビジネスプロファイルと、ＸＳＬＴファイルとは、企業情報ＤＢ１２１に格納される。
【００３４】
ここで、ビジネスプロファイルは、拡張されたSpecification Schema（の定義）に従って記述されたテキスト形式のファイルである。まず図６を参照して、Specification Schemaの基本概念を説明する。
【００３５】
コラボレーションとは、取引企業間で実行されるトランザクションの集まりを意味する。各取引企業はそれぞれに割り当てられたRole（例えば、販売者、購入者など）を実行する。コラボレーションには、Binary CollaborationsとMultiparty Collaborationsとの２種類がある。Binary Collaborationsは、２企業間の協働である。Multiparty Collaborationsは２つ以上の企業間の協働であり、図７に示すように複数のBinary Collaborationsを組み合わせて表現される。なお、図示していないが、Binary Collaborationsは２企業間で行われる「Business Activity」の集まりとして表される。「Business Activity」は、トランザクション処理のようなこれ以上分割できない処理や他のBinary Collaborationsを実行する複合的処理を定義する。
【００３６】
トランザクションは協働する２企業間のアトミックな処理要素である。トランザクションは業務処理について相対する役割を果たす２つの企業間で処理される。その相対する役割は常に要求者と応答者に分かれる。トランザクションは、「Business Activity」とは異なり、それ以上分割できない。また、トランザクションは正確で実行可能な業務処理を定義するため、明確に制約された表現形式に則って記述される。この性質より、ソフトウェア処理で自動実行できる。トランザクションの実行結果は、常に成功か失敗のどちらかしかありえない。もし失敗した場合は、その旨が取引相手に直ちに通知され、そのトランザクション中で行われた処理をロールバックする必要がある。
【００３７】
ドキュメントフローとは、要求者と応答者間でのドキュメントの流れであり、トランザクションの詳細を表現したものである。ドキュメントフローは、片方向通知、双方向対話のように、設計された業務処理の内容により要求されるビジネスドキュメント（メッセージ）と応答するビジネスドキュメントとで構成される。
【００３８】
コレオグラフィとは、トランザクションや部分的な協働における推移順を定義する。コレオグラフィは、開始状態、完了状態、実行、同期、トランザクション、推移などの要素として設計されている。
【００３９】
なお、Specification Schemaであらかじめ定義されたビジネスプロセスの基本パターンを利用すれば、利用企業はビジネスプロファイルを迅速に設計、実装できる。
【００４０】
図８に、本実施の形態における拡張されたSpecification Schemaの要素定義を示す。図８（Ａ）に示したTransition要素の下線を引いた部分は、本来のSpecification Schemaに追加した部分である。図８（Ｂ）に示したInternalTransition要素および、図８（Ｃ）に示したTranslation要素は本来のSpecification Schemaにはない新たな定義である。
【００４１】
本発明の実施の形態に係る拡張されたSpecification Schemaは、ｅｂＸＭＬ Specification Schemaに「InternalTransition」要素と「Translation」要素とを加え、「Transition」要素に「Translation」要素を加えたものである。
【００４２】
従来のｅｂＸＭＬで定義されている「Transition」要素は、「fromBusinessState」要素で指定されるビジネス状態から「toBusinessState」要素で指定されるビジネス状態への遷移を記述する。
本発明の実施の形態に係る「Transition」要素は、図８（Ａ）に示すように従来の「Transition」各要素に加え、「Translation」要素と「TranslationID」要素（「Translation」要素の識別情報の指定：オプション）とを含む。
「Transition」要素では、ディスパッチサーバ１００にＸＭＬデータの変換をさせるため、「Translation」要素の指定が必要となる。ディスパッチサーバ１００は、「fromBusinessState」要素で指定されるビジネス状態から「toBusinessState」要素で指定されるビジネス状態への遷移中に、ＸＭＬデータのメッセージ形式を「Translation」要素で指定された「変換規則」で変換する。
【００４３】
「InternalTransition」要素は、「fromBusinessState」要素で指定されるビジネス状態（その状態で使用するトランザクションは「fromBusinessTransaction」）から「toBusinessState」要素で指定されるビジネス状態（その状態で使用するトランザクションは「toBusinessTransaction」）への遷移を記述する。
「InternalTransition」要素は、図８（Ｂ）に示すように、図８（Ａ）の「Transition」各属性に加え、「fromBusinessState」要素と「fromBusinessStateID」要素（「fromBusinessState」属性の識別情報の指定：オプション）と「toBusinessState」要素と「toBusinessStateID」要素（「toBusinessState」属性の識別情報の指定：オプション）とを含む。
「InternalTransition」要素では、「Transition」要素と同様に、ディスパッチサーバ１００にＸＭＬデータの変換をさせるため、「Translation」属性の指定が必要となる。ディスパッチサーバ１００は、「fromBusinessState」要素で指定されるビジネス状態から「toBusinessState」要素で指定されるビジネス状態への遷移中に、ＸＭＬデータのメッセージ形式を「Translation」属性で指定された「変換規則」で変換する。
【００４４】
図８（Ｃ）に示す「Translation」要素は、あるメッセージ形式で記述されたＸＭＬデータ（ビジネスメッセージ）を他のメッセージ形式のＸＭＬデータに変換する規則を定義するＸＳＬＴ(eXtensible Stylesheet Language Transformations)ファイルを特定する。ディスパッチサーバ１００は、メッセージ形式の変換が必要になった際、メッセージ変換部１１３において、そのＸＳＬＴファイルに記述された変換規則に則ってＸＭＬデータのメッセージ形式を送信先のサーバ（「サーバ」と名付けられていてればどのサーバでも構わない）で解釈可能なメッセージ形式に変換する。
【００４５】
プロセスＤＢ１２２は、本電子商取引システム１において進行中の商取引を管理する取引情報を格納する。図９に示すように、プロセスＤＢ１２２には商取引ごとに一意に割り当てられた「プロセスコード」を主キーとするレコードが作成される。格納される取引情報は、「企業名」、「取引状態情報」などを含む。
【００４６】
ここで、「企業名」は、「プロセスコード」で特定される商取引に関与する企業の名称を示す情報である。「取引状態情報」は、「プロセスコード」により特定される商取引がどの段階であるかを示す情報であり、この商取引において交換されるメッセージが則っているビジネスプロファイルの名称やそのビジネスプロファイルで定義されているトランザクションの名称（図では「１２」が該当する）などの情報を格納する。「取引状態情報」は、取引の進展に応じて随時更新される。
【００４７】
プログラム記憶部１２５には、ディスパッチサーバ１００の基本動作を司るオペレーティングシステム（Operating System：ＯＳ）が格納されていることはもとより、例えば、以下のようなプログラムが格納される。
（１）「通信プログラム」：通信制御部１５０を制御し、通信ネットワークＣを介してウェブサーバ１０１や、コンバートサーバ２００、ＢＰＩサーバ４００との通信を行うプログラム
（２）「ＤＢ制御プログラム」：企業情報ＤＢ１２１に格納されるデータベースの入出力制御および所定の検索を行うプログラム
（３）「メッセージ管理プログラム」：ＯＳと協動し、ディスパッチサーバ１００全体の動作を制御し、ウェブサーバ１０１や、コンバートサーバ２００、ＢＰＩサーバ４００から送信されるメッセージを変換・送信するプログラム
【００４８】
図２に戻って、入力制御部１３０は、例えば、キーボードやポインティングデバイス等の入力装置１３を接続し、入力装置１３から入力された制御部１１０への指示などを受け付けて制御部１１０に伝達する。
【００４９】
出力制御部１４０は、例えば、ディスプレイなどの出力装置１４を接続し、制御部１１０の処理結果などを必要に応じて出力装置１４に出力する。
【００５０】
通信制御部１５０は、例えば、ＮＩＣ（Network Interface Card）やルータなどの通信装置から構成され、ディスパッチサーバ１００と通信ネットワークＣとを接続し、ディスパッチサーバ１００とウェブサーバ１０１、コンバートサーバ２００、ＢＰＩサーバ４００との間で行われる通信を制御する。
【００５１】
図１に戻って、ウェブサーバ１０１は、ＡＳＰ事業者が設置し、ＰＣサーバなどの情報処理装置で構成される。ウェブサーバ１０１は、ＰＣ３００からのアクセスを受け付け、対話形式により電子商取引の過程を進行させる。ウェブサーバ１０１は、記憶部１２０に格納されているビジネスプロファイルのコピーを格納しており、ビジネスプロファイルの記載に従って、対話形式の処理結果を電子メッセージ化しディスパッチサーバ１００に送信する。
【００５２】
コンバートサーバ２００は、Ａ社に設置された情報処理装置であって、業務システム２０１と通信ネットワークＣとの間に設置され、ディスパッチサーバ１００と業務システム２０１との間で交換されるメッセージのデータ形式を変換する。
コンバートサーバ２００とＰＣ３００とは各商取引の進行段階に応じて使い分けられる。例えば、自動化できるビジネスプロセスについてはコンバートサーバ２００を使用し、決裁者の承認が必要なビジネスプロセスについてはＰＣ３００を使用する。
【００５３】
図１０に示すように、本実施の形態に係るコンバートサーバ２００は、制御部２１０と、記憶部２２０と、入力制御部２３０と、出力制御部２４０と、通信制御部２５０とを備える。そして、入力制御部２３０に入力装置２３が、出力制御部２４０に出力装置２４がそれぞれ接続されている。
【００５４】
制御部２１０は、例えば、ＣＰＵや、ワークエリアとなる記憶装置（ＲＡＭ等）などを備える。制御部２１０は、記憶部２２０に格納されている動作プログラムを読み出して実行することにより、メッセージ変換処理などを実行する。
【００５５】
記憶部２２０は、ハードディスク装置などの記憶装置から構成され、制御部２１０で実行される動作プログラムやメッセージ変換処理において参照されるビジネスプロファイルやＸＳＬＴファイルなどを格納する。
【００５６】
入力制御部２３０は、例えば、キーボードやポインティングデバイス等の入力装置２３を接続し、入力装置２３から入力された制御部２１０への指示などを受け付けて制御部２１０に伝達する。
【００５７】
出力制御部２４０は、例えば、ディスプレイなどの出力装置２４を接続し、制御部２１０の処理結果などを必要に応じて出力装置２４に出力する。
【００５８】
通信制御部２５０は、例えば、ＮＩＣやルータなどの通信装置から構成され、コンバートサーバ２００と通信ネットワークＣとを接続し、コンバートサーバ２００とディスパッチサーバ１００やウェブサーバ１０１との間で行われる通信を制御する。
【００５９】
再び図１に戻って、業務システム２０１は、会社Ａが設置している情報処理装置であり、社内の業務（ここでは在庫管理システム）に関する処理を実行する。
【００６０】
ＰＣ３００は、会社Ａが設置している情報処理装置であり、ウェブサーバ１０１を介した各種処理に使用される。ウェブブラウザプログラムがインストールされている。
【００６１】
ＢＰＩサーバ４００は、会社Ｂに設置される情報処理装置である。ＢＰＩサーバ４００は、通信ネットワークＣを介してディスパッチサーバ１００との間でメッセージを送受信する。ＢＰＩサーバ４００は、会社Ｂにおける商取引に関する情報処理を一手に行っている。
【００６２】
図１１に示すように、本実施の形態に係るＢＰＩサーバ４００は、制御部４１０と、記憶部４２０と、入力制御部４３０と、出力制御部４４０と、通信制御部４５０とを備える。入力制御部４３０に入力装置４３が、出力制御部４４０に出力装置４４がそれぞれ接続されている。
【００６３】
制御部４１０は、例えば、中央演算処理装置（ＣＰＵ）やワークエリアとなる記憶装置（ＲＡＭ等）などを備える。制御部４１０は、記憶部４２０に格納されている動作プログラムを読み出して実行することにより、見積・発注処理などを実行する。
【００６４】
記憶部４２０は、ハードディスク装置などの記憶装置から構成され、制御部４１０で実行される動作プログラムや見積・発注処理で使用するＡ社のビジネスプロファイルなどを格納する。なお、Ａ社のビジネスプロファイルの取得方法については後述する。
【００６５】
入力制御部４３０は、例えば、キーボードやポインティングデバイス等の入力装置４３を接続し、入力装置４３から入力された制御部４１０への指示などを受け付けて制御部４１０に伝達する。
【００６６】
出力制御部４４０は、例えば、ディスプレイなどの出力装置４４を接続し、制御部４１０の処理結果などを必要に応じて出力装置４４に出力する。
【００６７】
通信制御部４５０は、例えば、ＮＩＣやルータなどの通信装置から構成され、ディスパッチサーバ１００と通信ネットワークＣとを接続し、ディスパッチサーバ１００とＢＰＩサーバ４００との間で行われる通信を制御する。
【００６８】
次に、図面を参照し、電子商取引システム１を利用した電子商取引の例を説明する。
まず、図１２を参照し、Ａ社とＢ社との間で電子商取引システム１を利用するための事前準備について説明する。
【００６９】
Ａ社では、通信ネットワーク（図示なし）を介して、アクセス可能なｅｂＸＭＬレジストリＲ、あるいは所定の機関に、ｅｂＸＭＬの記述仕様や、ｅｂＸＭＬファイルを記述する際のモデルとなるビジネスプロセスの実装方法を問い合わせ（ステップＳ１）、資料を入手する。そして、入手内容を確認した後、Ａ社で想定した商取引のプロセスをｅｂＸＭＬ形式のビジネストランザクションの集合として記述したｅｂＸＭＬファイル（以下、ビジネスプロファイルと称する）を作成する（ステップＳ２）。ビジネスプロファイルには、採用した商取引のシナリオだけでなく、Ａ社が設置している業務システムの処理能力と実行上の制約とを記述する。シナリオとはＸＭＬ形式で表現された商取引のプロセスとそれに関連した情報である。そして、作成したビジネスプロファイルと、ｅｂＸＭＬレジストリＲに登録する（ステップＳ３）。ｅｂＸＭＬレジストリＲは登録されたビジネスプロファイルの記載内容が所定の記述仕様に則っているか否か、また実行可能か否かを判別し、受信確認をＡ社に送信する。
【００７０】
一方、Ｂ社では、ｅｂＸＭＬレジストリＲ内に格納された各社のビジネスプロファイルを検索し（ステップＳ４）、Ａ社のビジネスプロファイルを見つけ出す。探し出したビジネスプロファイルをｅｂＸＭＬレジストリＲからダウンロードし（ステップＳ５）、ＢＰＩサーバ４００の記憶部４２０に格納する。
【００７１】
次に、Ａ社とＢ社とで、商品取引の交渉を行い、電子商取引システム１を利用する包括的な取引契約を締結する（ステップＳ６）。これで、Ａ社とＢ社との間で本電子商取引システム１上で電子商取引を行う準備が終了する。
【００７２】
なお、ステップＳ１、Ｓ３、Ｓ４、Ｓ５の手順は、通信ネットワークを介さずに実行してもよい。また、ｅｂＸＭＬレジストリＲを経由させず、Ａ社からＢ社にＡ社との電子商取引に必要なビジネスプロファイルを図１の通信ネットワークＣを介して送付してもよい。
【００７３】
次に、図１３、１４を参照して、製品の取引（見積もり後発注）を例にとり、電子商取引システム１の動作を説明する。なお、以下の説明において、特に必要がなければ、制御部１１０、２１０、４１０など個々の動作を述べず、ディスパッチサーバ１００やコンバートサーバ２００、ＢＰＩサーバ４００の動作として説明する。
【００７４】
Ｂ社の担当者がＢＰＩサーバ４００を起動し、入力装置４３を操作し、Ａ社から購入したい商品の商品コードと購入数量とを入力する。これを契機として、見積・発注処理が開始される。ＢＰＩサーバ４００は入力された商品コードと購入数量とを受け付け（図１３：ステップＳ１０１）、商品コードと購入数量と、Ａ社を指定する情報とをＡ社用のビジネスプロファイルの記載に則った見積要求メッセージを生成し、通信ネットワークＣを介してディスパッチサーバ１００に送信する（ステップＳ１０２）。
【００７５】
メッセージングサービス１１１から見積要求メッセージを転送されたビジネスプロセス処理部１１２は、プロセスＤＢ１２２を検索し、見積要求メッセージに含まれている「プロセスコード」が登録されているか否かを判別する。見積メッセージはこの見積・発注処理において最初に創出されるメッセージであるため、判別結果は（常に）偽となる。そこで、ビジネスプロセス処理部１１２は、見積要求メッセージに含まれている送信先の情報（企業名）で、見積要求メッセージが則っているビジネスプロファイルを企業情報ＤＢ１２１内から検索する。ビジネスプロセス処理部１１２は、検索したビジネスプロファイルと、「プロセスコード」と、見積要求メッセージに含まれている「トランザクションの名称」と、送信元、送信先の情報とに基づいて、「取引状態情報」を作成し、これをプロセスＤＢ１２２に登録する（ステップＳ１０３）
【００７６】
ビジネスプロセス処理部１１２は、ＢＰＩサーバ４００から受信した見積要求メッセージをＡ社のコンバートサーバ２００で処理できるよう、Ａ社のビジネスプロファイルを参照して変換するメッセージ形式を判別する。上述したようにビジネスプロファイルには、Ａ社のコンバートサーバ２００とデータ交換するためのメッセージ形式が規定されている。また、メッセージの変換方法についても、ビジネスプロファイルにそのためのＸＳＬＴファイルが指定されている。ビジネスプロセス処理部１１２は、見積要求メッセージと、送信先の情報と、判別したメッセージ形式を指定する情報とをメッセージ変換部１１３に送信する。
【００７７】
見積要求メッセージと、送信先の情報と、メッセージ形式を指定する情報とを受信したメッセージ変換部１１３は、メッセージ形式を指定する情報で指定されたＸＳＬＴファイルの記載内容に従って、見積要求メッセージの形式を判別したメッセージ形式に変換する（ステップＳ１０４）。
【００７８】
なお、ここで説明した処理は、ステップＳ１０９、Ｓ１１４、Ｓ１１９において同様に実行される。
【００７９】
ディスパッチサーバ１００は、変換後の見積要求メッセージをコンバートサーバ２００へ送信する（ステップＳ１０５）。
【００８０】
コンバートサーバ２００は、ディスパッチサーバ１００から送信された見積要求メッセージを受信し、業務システム２０１に転送する。業務システム２０１は、見積要求メッセージの受信に応答して、見積要求メッセージに含まれる商品コードと見積もり数量と、見積要求メッセージの元々の発信元が属する会社とに基づいて、商品購入の際の見積金額を算出する（ステップＳ１０６）。
コンバートサーバ２００は、算出された見積額を含む見積回答メッセージを作成し、ディスパッチサーバ１００に送信する（ステップＳ１０７）。
【００８１】
メッセージングサービス１１１から見積回答メッセージを転送されたビジネスプロセス処理部１１２は、プロセスＤＢ１２２を検索し、見積回答メッセージに含まれている「プロセスコード」が登録されているか否かを判別する。ステップＳ１０３において、この「プロセスコード」で特定される「取引状態情報」がプロセスＤＢ１２２に格納されているため、判別結果は真となる。ビジネスプロセス処理部１１２は、検索した「取引状態情報」の「トランザクションの名称」を、見積要求メッセージに含まれている「トランザクションの名称」で更新する（ステップＳ１０８）。
【００８２】
なお、ここで説明した処理は、ステップＳ１１３、Ｓ１１８において同様に実行される。
【００８３】
ビジネスプロセス処理部１１２は、ＢＰＩサーバ４００から受信した見積回答メッセージをＡ社のディスパッチサーバ２００で処理できるよう、Ａ社のビジネスプロファイルを参照して変換するメッセージ形式を判別する。ビジネスプロセス処理部１１２は、見積回答メッセージと、送信先の情報と、判別したメッセージ形式を指定する情報とをメッセージ変換部１１３に送信する。
【００８４】
コンバートサーバ２００から見積回答メッセージを受け取ったディスパッチサーバ１００は、ステップＳ１０４と同様にして、ＢＰＩサーバ４００で解釈できるように、見積回答メッセージの形式を変換し（ステップＳ１０９）、変換後の見積回答メッセージをＢＰＩサーバ４００へ送信する（ステップＳ１１０）。
【００８５】
ステップＳ１１０で送信された見積回答メッセージを受け取った、ＢＰＩサーバ４００は出力装置４４に見積金額を表示させる。Ｂ社の担当者は表示された見積金額を確認した上で、入力装置４３を操作し商品の発注する旨を入力する。すると、ＢＰＩサーバ４００は商品の発注する旨を示す情報を受け付け（ステップＳ１１１）、商品の商品コードと、購入数量、Ａ社を指定する情報、とを含む発注メッセージを生成し、通信ネットワークＣを介してディスパッチサーバ１００に送信する（図１４：ステップＳ１１２）。
【００８６】
ディスパッチサーバ１００は、ＢＰＩサーバ４００から受信した発注メッセージをＡ社のコンバートサーバ２００で処理できるよう、ビジネスプロファイルを参照してメッセージの形式を変換する（ステップＳ１１４）。そして、ディスパッチサーバ１００は、変換後の発注メッセージをウェブサーバ１０１へ送信する（ステップＳ１１５）。
【００８７】
Ａ社の担当者は、ＰＣ３００からウェブサーバ１０１にアクセスし、発注を承認する（ステップＳ１１６）。図１５は、ステップＳ１１６での作業の際にＰＣ３００に表示される画面の例である。
図１５は、承認待ちの発注案件を表示した画面の例である。例えば、Ａ社の担当者がＰＣ３００から、所定のウェブページにアクセスすると、ウェブサーバ１０１からＰＣ３００へ、発注メッセージに基づいて作成された承認待ちの発注案件のデータが送信される。そして、ＰＣ３００にインストールされているウェブブラウザプログラムが、承認待ちの発注案件のデータを整形してＰＣ３００の表示部に表示させる。
図示するように、この表示画面には、Ａ社の名称や、発注商品の品番情報、発注個数、納期、等が配置される。ここで表示されている事項のうち、Ａ社の名称や、発注商品の品番情報、発注個数は、発注メッセージに基づいている。また、担当者が納期を入力する欄が配置されている。
【００８８】
ここで、担当者が納期を示す日付を入力し「はい」のボタンをクリックすると、入力した数値を指定する情報と承認を示す情報とがＰＣ３００からウェブサーバ１０１に送信される。ウェブサーバ１０１は、承認を示す情報を受信すると、先に受信した発注メッセージに含まれていた「プロセスコード」と、納期を示すデータとに従って、発注完了メッセージを生成し、ディスパッチサーバ１００に送信する（ステップＳ１１７）。
【００８９】
ディスパッチサーバ１００は、ウェブサーバ１０１から受信した発注完了メッセージをＢ社のＢＰＩサーバ４００で処理できるよう、ビジネスプロファイルを参照してメッセージの形式を変換する（ステップＳ１１９）。そして、ディスパッチサーバ１００は、変換後の発注完了メッセージをＢＰＩサーバ４００へ送信する（ステップＳ１２０）。
【００９０】
ＢＰＩ４００は、発注完了メッセージを受信すると、商品の発注が無事完了した旨を示すメッセージおよび納期を出力装置４４に表示する（ステップＳ１２１）。さらに、プロセスＤＢ１２２に登録されている「取引登録情報」をビジネスプロセス処理部１１２に削除させるため、終了メッセージを作成し、ディスパッチサーバ１００に送信する。メッセージングサービス１１１を経由して終了メッセージを受信したビジネスプロセス処理部１１２は、終了メッセージに含まれる「プロセスコード」に対応する「取引登録情報」をプロセスＤＢ１２２から削除し（ステップＳ１２３）、見積・発注処理を終了する。
【００９１】
以上、説明したように、本発明の実施の形態に係る電子商取引システム１によれば、ＡＳＰ事業者等が提供するＸＭＬ−ＥＤＩサブシステムとＷＥＢ−ＥＤＩサブシステムとを介して、各企業が電子商取引を行うことができる。
【００９２】
既存のｅｂＸＭＬ Specification Schemaにメッセージの表現形式を変換する指定を組み込めるように拡張した、拡張Specification Schemaの形式でＸＭＬ形式のメッセージを交換するようにした。このため、既存のｅｂＸＭＬ Specification Schemaでは、図１３および図１４のステップＳ１０２、Ｓ１１０、Ｓ１１２、Ｓ１２０の部分で受け渡されるメッセージの交換しか記述できなかったものが、ステップＳ１０５、Ｓ１０７、Ｓ１１５、Ｓ１１７の部分で受け渡されるメッセージの交換も記述できるようになった。つまり、電子商取引のプロセスに関し、自社と、取引先との中継地点となるディスパッチサーバ１００との間しか記述できなかったものが、自社と取引先との間まで記述できるようになった。
【００９３】
また、ＸＳＬＴに基づくメッセージ変換機能により、異なるメッセージ形式への対応が容易である。このため、社内の業務システム２０１との連携がとりやすくなり、また、社内の業務システム２０１の設計も容易になる。
【００９４】
さらに、上記電子商取引システム１では、ＸＭＬ−ＥＤＩサブシステムとＷＥＢ−ＥＤＩサブシステムとを併用している。また、ビジネスプロファイルの記述を業務システム２０１の更改、更新に合わせて更新することができる。このため、会社規模の拡大や社内業務システムの更新に応じて、ＷＥＢ−ＥＤＩサブシステムからＸＭＬ−ＥＤＩサブシステムへと段階的に移行できる。
【００９５】
例えば、Ａ社が商品の取引量が少ない小企業の場合、ＷＥＢ−ＥＤＩサブシステムのみを使用する。企業規模が大きくなり中程度の企業に成長すれば、図１に示したように上述したＸＭＬ−ＥＤＩサブシステムとＷＥＢ−ＥＤＩサブシステムとを併用する。さらに企業規模が大きくなり大企業になれば、ＸＭＬ−ＥＤＩサブシステムのみを使用する。
【００９６】
なお、本発明は上記実施の形態に限定されず、種々の変形および応用が可能である。
例えば、上記実施の形態では、データ形式として拡張したｅｂＸＭＬフォーマットを例に説明したが、ＦＩＸ（Financial Information eXchange）、ＯＢＩ（Open Buying on the Internet）、ＲｏｓｅｔｔａＮｅｔなど、他のメッセージフォーマット（またはその拡張フォーマットや後継フォーマット）を使用してもよい。
【００９７】
また、上記実施の形態においてＸＭＬ形式のメッセージは、ＸＭＬスキーマで記述される構造に則って記述されるものとしたが、ＤＴＤ（Document Type Definition）など他のスキーマ言語で記述される構造に則って記述されるようにしてもよい。
【００９８】
また、上記ディスパッチサーバ１００の機能とウェブサーバ１０１の機能とを備えた情報処理装置を用意し、ディスパッチサーバ１００やウェブサーバ１０１が実行していた処理を実行させるようにしてもよい。
【００９９】
さらに、上記コンバートサーバ２００の処理機能を、業務システム２０１に組み込むこともできる。この場合、例えばコンバートサーバ２００の処理機能は業務システム２０１のアドインシステム（プログラム）として実現される。
【０１００】
また、ビジネスプロセス処理部１１２が、プロセスＤＢ１２２の登録内容とビジネスプロファイルに記載されているビジネス状態の移行順序通りにメッセージに含まれている「トランザクションの名称」が遷移しているか否かを判別してもよい。この場合、ビジネスプロファイルの記載通りにメッセージが交換されていないと判別した場合、ビジネスプロセス処理部１１２は偽のメッセージが電子商取引システム１に送信されたと判別することができる。
【０１０１】
なお、本発明の実施の形態に係るディスパッチサーバ１００、コンバートサーバ２００およびＢＰＩサーバ４００を実現するための情報処理装置は、専用のシステムによらず、通常のコンピュータシステムを用いて実現可能である。例えば、汎用コンピュータに、上述の処理を実行するためのプログラムを格納した媒体（ＣＤ−ＲＯＭなど）から当該プログラムを記憶部１２０、２２０または４２０にインストールすることにより、上述の処理を実行するディスパッチサーバ１００、コンバートサーバ２００およびＢＰＩサーバ４００を構成することができる。
【０１０２】
また、上述の機能を、ＯＳ（Operating System）とアプリケーションとの分担、またはＯＳとアプリケーションとの協動により実現する場合などには、ＯＳ以外の部分のみを媒体に格納してもよい。
【０１０３】
また、搬送波にプログラムを重畳し、通信ネットワークを介して配信することも可能である。例えば、通信ネットワーク上の掲示板（ＢＢＳ、Bulletin Board System）に該プログラムを掲示し、ネットワークを介して該プログラムを配信してもよい。そして、このプログラムを起動し、オペレーティングシステムの制御下で、他のアプリケーションプログラムと同様に実行することにより、上述の処理を実行できるように構成しても構わない。
【図面の簡単な説明】
【０１０４】
【図１】本発明の実施の形態に係る電子商取引システムのブロック図である。
【図２】図１のディスパッチサーバの構成を示すブロック図である。
【図３】図２の制御部の論理構成図である。
【図４】図２の記憶部に格納されるデータを説明するための図である。
【図５】図４の企業情報ＤＢに格納される情報の例を説明するための図である。
【図６】本発明の実施の形態において、想定するビジネスプロセスの概念図である。
【図７】図６に登場するコラボレーションの概念を説明するための図である。
【図８】図４の企業情報ＤＢに格納されるビジネスプロファイルを説明するための図であり、（Ａ）ビジネスプロファイルに含まれるTransition要素の構造定義であり、（Ｂ）ビジネスプロファイルに含まれるInternalTransition要素の構造定義であり、（Ｃ）ビジネスプロファイルに含まれるTranslation要素の構造定義である。
【図９】図４のプロセスＤＢに格納される情報の例を説明するための図である。
【図１０】図１のコンバートサーバの構成を示すブロック図である。
【図１１】図１のＢＰＩサーバの構成を示すブロック図である。
【図１２】本発明の実施の形態に係る電子商取引システムを利用するための事前準備の手続きを示す図である。
【図１３】本発明の実施の形態に係る見積・発注処理を説明するためのフローチャートの前半部分である。
【図１４】本発明の実施の形態に係る見積・発注処理を説明するためのフローチャート後半部分であり、図１３の続きである。
【図１５】本発明の実施の形態に係る見積・発注処理において、ＰＣの表示部に表示される画面の例を示した図である。
【符号の説明】
【０１０５】
Ｃ      通信ネットワーク
Ｒ      ｅｂＸＭＬレジストリ
１      電子商取引システム
１００  ディスパッチサーバ
１０１  ウェブサーバ
１１０  制御部
１２０、２２０、４２０  記憶部
１２１  企業情報データベース
１２２  プロセスデータベース
１２５  プログラム記憶部
１３０、２３０、４３０  入力制御部
１３、２３、４３  入力装置
１４０、２４０、４４０  出力制御部
１４、２４、４４  出力装置
１５０、２５０、４５０  通信制御部
２００  コンバートサーバ
２０１  業務システム
３００  ＰＣ
４００  ＢＰＩサーバ
【図１】
2006277046.tif 000003
【図２】
2006277046.tif 000004
【図３】
2006277046.tif 000005
【図４】
2006277046.tif 000006
【図５】
2006277046.tif 000007
【図６】
2006277046.tif 000008
【図７】
2006277046.tif 000009
【図８】
2006277046.tif 000010
【図９】
2006277046.tif 000011
【図１０】
2006277046.tif 000012
【図１１】
2006277046.tif 000013
【図１２】
2006277046.tif 000014
【図１３】
2006277046.tif 000015
【図１４】
2006277046.tif 000016
【図１５】
2006277046.tif 000017