JP2018073186A - 取引システム、取引システムの制御方法、及び、そのためのプログラム - Google Patents

Abstract

【解決課題】サービス等の取引対象の扱いが多彩な態様になる場合であっても、その取引を円滑、かつ、適格に処理するデータ処理を実現可能な取引システムを提供する。【課題解決手段】複数の需要者と複数の供給者との間の取引を支援する取引システムであって、ネットワークに接続されたサーバ計算機を備え、取引の需要者側の複数の計算機と取引の供給者側の複数の計算機とが前記ネットワークに接続され、前記サーバ計算機は、前記需要者側の複数の計算機の少なくとも一つと、前記供給者側の複数の計算機の少なくとも一つと、の間で行われる取引に介在するための処理を行うプロセッサと、前記複数の需要者側計算機の夫々から出力された、前記取引に関する需要者側情報と、前記複数の供給者側計算機の夫々から出力された、前記取引に関する供給者側情報と、を記録するメモリとを備える。【選択図】図１

Description

本発明は、商品やサービスの需要者と、その供給者との間の取引を仲介、或いは、支援する取引システム等に関する。

近年、ＩＴやＩＣＴにおける技術の進歩によって、商品やサービスの売買等の商取引活動において、コンピュータを利用した取引システムが多用されている。例えば、特開２０１３−４５２６４号公報には、Ｗｅｂサイト上のインターネットショッピングを仲介する取引システムが開示されている。

このシステムは、ＳａａＳ等の商品（クラウド製品）の販売−購入の手続きを可能にするものであって、顧客が購入を検討しているＳａａＳ商品の情報などに付随するアンケート（Ｑ＆Ａ）に対して回答することにより、商品が顧客のニーズにどの程度適合しているかが自動的に分かる適合診断を提供し、アンケート（Ｑ＆Ａ）の情報をもとに、商品と顧客との適合度等を診断し、その結果を利用して商品の売買を効率化しようとするものである。

特開２０１３−４５２６４号公報

特許文献１に係るシステムは、需要者と供給者との間で、ＳａａＳ型の商品やサービスの取引のように定型的な取引を前提としている。しかしながら、近年では、電子商取引が、発電プラント、鉄道システムのような社会インフラ事業の関連サービスにも及び、この種の分野では、需要者が要望するサービスは定型的とは到底いえない規格外のものが主流であって、固定的なサービスや商品の取引を対象としている従来の取引システムでは、これに対応することは困難である。そこで、本願発明は、サービス等の取引対象の扱いが多彩な態様になる場合であっても、その取引を円滑、かつ、適格に処理するデータ処理を実現可能な取引システムを提供することを目的とする。

前記目的を達成するために、本発明は、複数の需要者と複数の供給者との間の取引を支援する取引システムであって、ネットワークに接続されたサーバ計算機を備え、取引の需要者側の複数の計算機と取引の供給者側の複数の計算機とが前記ネットワークに接続され、前記サーバ計算機は、前記需要者側の複数の計算機の少なくとも一つと、前記供給者側の複数の計算機の少なくとも一つと、の間で行われる取引に介在するための処理を行うプロセッサと、前記複数の需要者側計算機の夫々から出力された、前記取引に関する需要者側情報と、前記複数の供給者側計算機の夫々から出力された、前記取引に関する供給者側情報と、を記録するメモリと、を備え、前記メモリは、前記需要者側情報として、前記取引のための要望事項の基本要素を含む第１のデータブロックと、当該要望事項の追加要素を含む第２のデータブロックと、前記供給者側情報として、前記取引のための提供事項の基本要素を含む第３のデータブロックと、当該提供事項の追加要素を含む第４のデータブロックと、を記録し、前記プロセッサは、前記需要者側の複数の計算機の夫々に、前記メモリへの前記需要者側情報の登録と、前記メモリから供給者側情報の参照とを可能にし、前記供給者側の複数の計算機の夫々に、前記メモリへの前記供給者側情報の登録と、前記メモリから需要側情報の参照とを可能にすることを特徴とする。

本願発明によれば、サービス等の取引対象の扱いが多彩な態様になる場合であっても、その取引を円滑、かつ、適格に処理するデータ処理を実現可能な取引システムを提供することができる。

マーケットプレイスシステムを備える取引システムのハードウェアブロック図である。 取引システム（図１）の機能ブロック図である。 データベースのブロック構成の一例である。 サーバ計算機がマッチング処理を行うまでのタイミングチャートである。 供給者のサービスの事前評価のためのタイミングチャートである。 需要者側計算機の出力装置に表示されるサービスフォームの一例である。 供給者側計算機の出力装置に表示されるサービスフォームである。 サービスフォーム登録モジュールのフローチャートである。 サービス要望テーブルの構造の一例である。 サービス要望（追加）テーブルの構造の一例である。 サービス供給テーブルの構造の一例である。 サービス供給（追加）テーブルの構造の一例である。 サービスフォーム参照モジュールのフローチャートである。 サービス情報管理テーブルの構造の一例である。 サービスフォーム管理モジュールのフローチャートの一例である。 サービスマッチング実行モジュールのフローチャートの一例である。 サービス評価データ分析モジュールのフローチャートの一例である。 サービス評価データテーブルの一例である。 サービス評価指標テーブルの一例である。 サービスの指標手法テーブルの一例である。

次に、本発明の実施形態を図面に基づいて説明する。図１は、マーケットプレイスシステム１００を備える取引システムのハードウェアブロック図である。取引システムは、商品やサービスに関する要望を供給者側に伝達する需要者側のシステム１１０と、商品、サービスを提供することを需要者側に伝達する供給者側のシステム１２０と、を備え、需要者側システム１１０と供給者側システム１２０とは、通信ネットワーク１３０を介して、マーケットプレイスシステム１００に接続している。需要者側のシステム１１０は前記要望の処理に係る電子処理を行い、供給者側のシステム１２０は前記供給の処理に係る電子処理を行う。なお、取引システムでは、多数の需要者側システム１１０と多数の供給者側システム１２０が通信ネットワーク１３０に接続し、需要者と供給者との間で、１対１、多対１、１対多、又は、多対多の商取引が実現される。

商品とサービスとは夫々“取引対象”という用語によって総称されてよい。マーケットプレイスシステム１００は、需要者側システム１１０と供給者側システム１２０との間の取引（事業者間取引）を仲介、或いは、支援する等して取引に介在する。夫々のシステムは、計算機から構成される。取引には、ＳａａＳ，ＰａａＳ，ＩａａＳ等の商品・サービス（クラウド製品）の売買、レンタル等取引が含まれるが、本発明のマーケットプレイスシステム１００は、ＳａａＳ等のように定型的にはなり難い専門的サービスを望む需要者と、このサービスの提供を可能とする供給者との間の取引を仲介ないし支援する。また、取引の目的には商品の売買、貸借、利用等を含み、また、サービスの請負、発注等を含むなど、特段限定されない。

専門的サービスとして、例えば、発電所、データセンター、鉄道、プラント等社会資本、大型の空調システム等の関連設備や機能の保守、管理、改良、拡張等、シェアリングエコノミー、旅行代理店等複数事業者の協業によって提供されるサービス等を例示することができる。専門的サービスの取引においては、需要者が望むサービスの種類、内容は多彩かつ複雑になることが多く、そして、供給者が提供できるサービスの種類、内容も同じである。したがって、両者の仲介、即ち、マッチングを図ることもできるマーケットプレイスシステムは、このような要求に合った構成や機能を持つことになる。なお、“需要者”を“要望者”あるいは“利用者”に、“供給者”を“提供者”に言い換えてもよい。

図１に示すように、マーケットプレイスシステム１００はサーバ計算機１０１を備える。サーバ計算機１０１は、プロセッサ１０２、メモリ１０３、そして、通信モジュール１０４を備える。通信モジュール１０４は通信ネットワーク１３０に接続する。サーバ計算機１０１には、キーボード等の入力装置１０５と、ディスプレイ等の出力装置１０６とが接続する。

需要者側システム１１０のクライアント計算機１１１は、サーバ計算機１０１に通信ネットワーク１３０を介して接続する。クライアント計算機１１１は、サーバ計算機１０１と同様に、プロセッサ１１２、メモリ１１３、そして、通信モジュール１１４を備え、クライアント計算機１１１には、キーボード等の入力装置１１５と、ディスプレイ等の出力装置１１６とが接続する。供給者側計算機１２１も需要者側計算機１１１と同じように構成されている（１２２〜１２６）。需要者や供給者側の計算機１１１、１２１は、サーバ計算機１０１に対してプッシュ方式、又は、プル方式で通信する。

需要者側システム１１０は、需要者が望むサービスの情報をマーケットプレイスシステム１００に登録する。供給者側システム１２０は、供給者が提供可能なサービスの情報をマーケットプレイスシステム１００に登録する。マーケットプレイスシステム１００は、需要者の要望と供給者の提供とのマッチングを含めた、様々な管理処理を実行する。需要者側システム１１０と供給者側システム１２０夫々の計算機１１１，１２１は、パソコン、モバイル端末、或いは、タブレット端末等特段限定されない。

需要者側システム１１０と供給者側システム１２１夫々の数は限定されない。マーケットプレイスシステム１００を構成するサーバ計算機１０１は、分散処理による負荷分散のため、ハードウェア故障対策として、多重に存在してもよい。サーバ計算機１０１が複数存在する態様では、データのコンシステンシを維持するために入出力アクセスの制限（ロック）を実行すればよい。

図２に取引システム（図１）の機能ブロック図を示す。図２に示される夫々の機能モジュールは、プロセッサがメモリに記録されているプログラムを実行することによって実現される。マーケットプレイスシステム１００のサーバ計算機１０１は、管理系モジュールＦＡ１と、登録/参照系モジュールＦＡ２と、サービスマッチング系モジュールＦＡ３と、サービス評価系モジュールＦＡ４と、を備える。

管理系モジュールＦＡ１は、需要者側システム１１０と供給者側システム１２０との間の取引の仲介のための管理を実行するものであって、例えば、サーバ計算機１０１にユーザを登録するユーザ登録モジュールＦ１０１を備える。ユーザとは、需要者、供給者、そして、マーケットプレイスシステム１００の管理者である。

管理系モジュールＦＡ１は、さらに、サービスフォームを管理するサービスフォームの管理モジュールＦ１０２を備える。サービスフォームとは、需要者が望むサービスや提供者が可能なサービスの情報をサーバ計算機１０１に登録するための帳票である。

ユーザ登録情報及びサービスフォームはデータベース１０７に記録されている。ユーザ登録モジュールＦ１０１とサービスフォーム管理モジュールＦ１０２は、必要に応じてデータベース１０７にアクセスする。需要者側計算機１１１のユーザ入力モジュールＦ１１１と供給者側計算機１２１のユーザ入力モジュールＦ１２１は夫々ユーザ登録モジュールＦ１０１にアクセスしてユーザ登録を行う。

登録／参照系モジュールＦＡ２は、サービスフォーム登録モジュールＦ１０３、サービスフォーム参照モジュールＦ１０４、そして、サービス評価結果反映モジュールＦ１０５を備える。サービスフォーム登録モジュールＦ１０３は、情報が入力されたサービスフォームをサーバ計算機１０１のデータベース１０７に登録し、サービスフォーム参照モジュールＦ１０４はデータベース１０７の登録済みサービスフォームをユーザに参照させ、サービス評価結果反映モジュールＦ１０５は、提供者のサービスに対する評価結果をデータベース１０７に反映させる。

需要者側計算機１１１のサービスフォーム入力モジュールＦ１１２と、供給者側計算機１２１のサービスフォーム入力モジュールＦ１２２は夫々サービスフォーム登録モジュールＦ１０３にアクセスしてサービスフォームへのサービス情報の入力を行う。需要者側計算機１１１のサービスフォーム参照モジュールＦ１１３と、供給者側計算機１２１のサービスフォーム参照モジュールＦ１２３とは、夫々サービスフォーム参照モジュールＦ１０３にアクセスしてサービスフォームの情報を参照できる。

サービスマッチング系モジュールＦＡ３は、サービスマッチング実行モジュールＦ１０６を実現して、重要者と供給者の間において、サービスフォームに登録されたサービスの条件、要件、或いは基準等が相互に適合するか否かを判定し、これを肯定する場合には、重要者が求めるサービスと供給者が提供可能なサービスとのマッチングを実行する。“相互に適合”とは、サービスの条件が完全に一致するほか、略一致することを含む。“サービスのマッチングを実行する”とは、重要者と供給者との間で、お互いの要望が一致したことを、夫々に電子メール等で通知する等、両者の間の契約の成立を支援することを含む。サービスマッチング実行モジュールＦ１０６は、適合度を規定することによって、重要者と供給者の間のマッチングの要否、あるいは、適否を判定する際の参考にすることができる。

マッチングの態様には、需要者と提供者との間で１：１、１：多、多：１、又は、多：多のマッチングが含まれる。例えば、需要者が望むサービが複数の供給者のサービスの組合せによって達成される場合、マーケットプレイスシステム１００は、１：多のマッチングを行う。需要者が望むサービが複数の供給者のサービスの組合せによって達成されるか否かは、サービスマッチング実行モジュールＦ１０６がサービスフォームの入力情報に基づいて、過去のマッチング実績（サービスマッチングテーブル（図３：Ｄ３０７）を参照して判断できる。

サービス評価系モジュールＦＡ４は、需要者と供給者との間で取引が成立する前に、提供者のサービスを評価して、評価結果を需要者に開示することにより、需要者が、自身が要望するサービスに適したサービスを提供できる最適な供給者を複数の供給者の中から選択できるようにしている。

近年、需要者と供給者との間で取引されるサービスや商品について、需要者の要望は、経済や技術の拡大や進歩に伴って複雑かつ多彩になってきており、しかも、需要者の要望も日々変化する。例えば、大型の空調設備などを保持するタワー型のオフィスビルなどの施設では、空調設備、昇降機設備などの安定稼働のために、設備や機能の寿命や故障を施設の稼働データから予測して（予兆分析）、例えば、設備の故障のレベルと発生予測日時を事前に算出して、施設の稼働停止に至らないようにすることが必須とされている。

予兆分析等高い専門性を必要としているサービスについて、需要者は、これを外部専門組織に依頼することが多々ある。需要者は、専門サービスのための供給者が複数現われた場合、最も優秀な供給者を選ぼうとするが、これを計算機システムが、Ｑ＆Ａ形式等の固定的は審査方式によって行おうとしても、需要者の要望を満足し得る供給者のサービスを見出すことは困難である。そして、供給者のサービスの優劣は需要者にサービスが提供されて初めて分かることが多い。

そこで、サービス評価系モジュールＦＡ４は、需要者からの情報に基づいて供給者のサービスを事前にシミュレーションして、分析結果を需要者に知らせる。需要者は分析結果に基づいて供給者のサービスを事前に評価した上で供給者を決定することができる。サービスの分析は、サービス評価系モジュールＦＡ４によって行われてもよいし、供給者自身によって行われてもよい。

サービス評価系モジュールＦＡ４は、サービスの評価のためのデータ（評価データ）を取得するモジュールＦ１０７と、このデータを分析するモジュールＦ１０８と、を備える。評価データ取得モジュールＦ１０７は、需要者側計算機１１１からサービスの評価のために必要なデータ、例えば、設備の運用データ等を取得し、供給者側計算機１２１からサービスの評価のための計算方法・計算方式等の評価手法を取得し、取得データに基づいて、評価データ分析モジュールＦ１０８は、供給者のサービスを分析する。又は、評価データ分析モジュールＦ１０８は、評価データ取得モジュールＦ１０７が取得した需要者からのデータに基づいて、供給者側計算機１２１に供給者が提供しようとしているサービスを実行させてよい。

需要者側の計算機１１１のサービス評価データ入力モジュールＦ１１４と、供給者側の計算機１２１のサービス評価データ入力／取得モジュールＦ１２４とは夫々サービス評価データ取得モジュールＦ１０７にアクセスすることによって、サービス評価データ取得モジュールＦ１０７は、サービス評価データ入力モジュールＦ１１３、サービス評価データ入力／取得モジュールＦ１２４の夫々からデータを取得し、さらに、サービス評価データ入力／取得モジュールＦ１２４にサービス評価データ入力モジュールＦ１１３からのデータを取得させることができる。

サーバ計算機１０１のデータベース１０７は、サーバ計算機１０１のモジュールで扱うデータを継続的に蓄積する。データベース１０７はメモリ１０３に存在する。データベース１０７は、サーバ計算機１０１外の外部ストレージシステムに存在してもよい。図３に、データベースのブロック構成の一例を示す。データベース１０７には、複数のモジュールにおける機能の違いに合わせて、複数の種類のテーブルが存在する。

図３に示すユーザ情報テーブルＤ３０１は、ユーザ（需要者、供給者、マーケットプレイスシステムの運用者）の情報を蓄積し、サービス要望テーブルＤ３０２は、サービスの要望情報としてのサービスフフォームを蓄積し、サービス要望（追加）テーブルＤ３０３は、サービス要望テーブルＤ３０２にリンクするものであって、サービスの要望情報の追加項目を蓄積し、サービス提供テーブルＤ３０４は、サービスの提供情報としてのサービスフォームを蓄積し、サービス提供（追加）テーブルＤ３０５は、サービス提供テーブルＤ３０４にリンクするものであって、サービスの提供情報の追加項目を蓄積する。

サービス情報管理テーブルＤ３０６はサービスの管理情報を保持し、サービスマッチングテーブルＤ３０７は、サービスマッチングの履歴情報等マッチングに関係する情報を保持し、サービス評価手法テーブルＤ３０８は、サービスの事前評価に関する評価手法の情報を保持し、サービス評価データテーブルＤ３０９は、サービスの事前評価のためのデータを保持し、サービス評価指標テーブルＤ３１０は、サービスの評価結果を保持し、履歴情報テーブルＤ３１１は、サービスフォームのアクセス履歴の情報を保持する。サーバ計算機１０１の複数のモジュールの夫々は、データベース１０７の一つ又は複数のテーブルを参照して、夫々の機能に基づく管理、処理、或いは、制御を実行する。

次に、図１に示す取引システムのタイミングチャートについて説明する。図４Ａは、サーバ計算機１０１がマッチング処理を行うまでのタイミングチャートであり、図４Ｂは、供給者のサービスの事前評価のためのタイミングチャートである。図４Ａのタイミングチャートは、「事前登録フェーズ」、「サービス情報登録フェーズ」、「サービス情報参照フェーズ」、「サービスマッチングフェーズ」の順に進んでいく。なお、取引システムを構成する複数の計算機は、複数のフェーズを並列に実行してもよい。

事前登録フェーズは、マーケットプレイスに参加するユーザを登録する。ユーザとは、既述のとおり、サービスの需要者（需要者側計算機１１１）、サービスの提供者（提供者側計算機１２１）を含む。マーケットプレイスの運用管理者（管理用計算機１００Ａ）は、マーケットプレイスシステムの利用規則や加入契約に相当する業務を実施しており、ユーザ登録モジュールＦ１０１は、需要者を特定する情報である氏名や企業名、住所、電話番号、メールアドレス等に加え、マーケットプレイスシステムにアクセスするためのアカウント情報（ＩＤ、パスワード）を、需要者側システム１１０から取得し（Ｓ１０１）、そして、供給者側システム１２０から取得して（Ｓ１０２）、これらをデータベース１０７のユーザ情報テーブルＤ３０１に登録する（Ｓ１０３）。ユーザ登録モジュールＦ１０１は、登録された情報を更新や削除する際、需要者情報テーブルＤ３０１を更新する。

次に、サービス情報登録フェーズについて説明する。サービス情報は、需要者が要望するサービスの情報、提供者が提供できるサービスの情報を含む。図５は、需要者側計算機１１１の出力装置１１６に表示されるサービスフォーム（サービスフォームのデータ構造例）であり、５Ａが基本のサービスフォームを示し、５Ｂが追加のサービスフォームを示す。サービスフォーム登録モジュールＦ１１２が、サービス要望情報をサービスフォームに入力する（図４Ａ：Ｓ１０４）。

図５に示すように、例えば、サービス需要者のＩＤ 「Ｕ＿ＩＤ９０００」の工場事業者Ａ（５０１）が工場で製品生産に必要な電力の提供を要望することを想定すると、サービスフォーム５Ａには、「いつ：２０１６年３月１０日」（５０４）、「どこで：工場Ａ」（５０５）、「なにを：電力供給」（５０２）、「いくらで：￥４３/ｋＷｈ以下で」（５０３）、「どれぐらいの量：１００ｋＷｈ」（５０６）という、要望するサービスの内容を記述する項目を含む。

サービスフォームは、Ｗｅｂページ等として、需要者側計算機１１１がサーバ計算機１０１にアクセスすることによって、出力装置１１６（図１）に表示させてよい。“実行”アイコン５０８が選択されると、サービスフォーム登録モジュールＦ１１２は、サービスフォームの情報をサービスフォーム登録モジュールＦ１０３に出力する（Ｓ１０５）。サービスフォーム登録モジュールＦ１０３は、基本サービスフォーム５Ａをサービス要望テーブルＤ３０２に登録し、追加サービスフォーム５Ｂをサービス要望（追加）テーブルＤ３０５に登録する。

追加サービスフォーム５Ｂは、サービスフォーム５Ａの情報を補足するためのものである。例えば、需要者が製品生産に必要な電力として、「太陽光発電」を要望する場合には、サービスフォーム入力モジュール１１２は、追加サービスフォーム５Ｂの追加項目名称５１２に「エネルギー種別」と入力し、参考情報５１３に「太陽光発電」と入力すればよい。５１０は追加項目のエントリであり、５１１は要望サービスのＩＤである。追加サービスフォーム５Ｂは要望サービスＩＤ ５１１を外部キーにして、基本サービスフォーム５ＡのサービスＩＤ ５０１にリンクされる。需要者の要望を、基本情報（サービスフォーム５Ａ）と、基本情報よりも詳細或いは特徴的な追加情報（追加サービスフォーム５Ｂ）に分けることによって、需要者の要望が明瞭になる。

図６は、供給者側計算機１２１の出力装置１２６に表示されるサービスフォームであり、６Ａが基本のサービスフォームを示し、６Ｂが追加のサービスフォームを示す。サービスフォーム入力モジュールＦ１２２が、サービス供給情報をサービスフォームに入力する（図４Ａ：Ｓ１０５Ａ）。サービスフォーム６Ａは、例えば、図６に示す項目（６０１〜６０７）を含む。サービスフォーム５Ｂも、例えば、図６に示す項目（６１０〜６１３）を含む。

サービスフォームは、Ｗｅｂページ等として表示されてよい。“実行”アイコン６０８が選択されると、サービスフォーム入力モジュールＦ１２２は、サービスフォームの情報をサービスフォーム登録モジュールＦ１０３に出力する（Ｓ１０５Ｂ）。サービスフォーム登録モジュールＦ１０３は、基本サービスフォーム６Ａをサービス提供テーブルＤ３０４に登録し、追加サービスフォーム６Ｂをサービス要望（追加）テーブルＤ３０３に登録する。

サーバ計算機１０１は、需要者側計算機１１１、又は、供給者側計算機１２１からのサービスフォームに関するリクエストを受信すると、メッセージに含められた「登録処理」又は「参照処理」に対応するデータに基づいて、サービスフォーム登録モジュール（Ｆ１０３）の処理、又は、サービスフォーム参照モジュール（Ｆ１０４）の処理を分岐させる。

図７に、サービスフォーム登録モジュールＦ１０３のフローチャートを示す。サービスフォーム登録モジュールＦ１０３は、ユーザ（需要者側計算機１１１、又は、供給者側計算機１２１）からサービスフォームのリクエストの受信処理を実施する（Ｓ３０１）。Ｓ３０１では、サービスフォーム登録モジュールＦ１０３は、サーバ計算機１０１の負荷を管理するために、リクエストのログを履歴情報として履歴情報テーブルＤ３１１に登録する。

次に、サービスフォーム登録モジュールＦ１０３は、ユーザ情報取得処理（Ｓ３０２）を実行する。Ｓ３０２は、受信したメッセージの中から、ユーザＩＤを取得し、ユーザ情報テーブルＤ３０１を参照して、ユーザ認証を行う。ユーザ認証を肯定すると（Ｓ３０３：Ｙｅｓ）、サービスフォーム情報取得処理（Ｓ３０４）に移行する。

サービスフォーム登録モジュールＦ１０３は、Ｓ３０４において、ユーザに最適なサービスフォームを入力用として取得して提供する。サービスフォームの雛形は、サービスの内容、その種類等に応じてパターン化されていてよい。需要者向けサービスフォームの点レートはサービス要望テーブルＤ３０２に記録されていてよい。供給者向けサービスフォームはサービス提供テーブルＤ３０４に記録されていてよい。

サービスフォーム登録モジュールＦ１０３は、これらのテーブルを参照し、ユーザＩＤの登録情報に基づいて、例えば、ユーザの業種に応じて、ユーザに適したサービスフォームを選択して需要者に提示する。その際、サービスフォーム登録モジュールＦ１０３は、例えば、ユーザへの提示回数が多いサービスフォームを優先することができる。回数等の管理情報は、サービス情報管理テーブルＤ３０６に記録されている。なお、サービスフォームはユーザによって選択されるようにしてもよい。サービスフォーム登録モジュールＦ１０３は、追加テーブルをユーザのリクエストに応じて提供する。

次いで、サービスフォーム登録モジュールＦ１０３は、サービスフォームの情報を登録する処理（Ｓ３０５）に移行する。Ｓ３０５において、サービスフォーム登録モジュールＦ１０３は、需要者側システム１１０からの入力済みサービスフォーム（図５）をサービス要望テーブルＤ３０２，Ｄ３０３に登録する。一方、サービスフォーム登録モジュールＦ１０３は、供給者側システム１２０からの入力済みサービスフォーム（図６）をサービス提供テーブルＤ３０４，Ｄ３０５に登録する。

次いで、サービスフォーム登録モジュールＦ１０３は、登録が完了した旨、もしくは、登録に失敗した旨の結果の通知を需要者側計算機１１１、又は、供給者側計算機１２１にｗｅｂページとして報知する（Ｓ３０６）。Ｓ３０３において、サービスフォーム登録モジュールＦ１０３は、ユーザ認証を失敗すると、Ｓ３０４−Ｓ３０６をスキップしてフローチャートを終了する。サービスフォーム登録モジュールＦ１０３は、ユーザ認証に失敗したことをユーザに伝え、ユーザ計算機からの応答をまってユーザ登録モジュールＦ１０２を動作させる。

図８にサービス要望テーブルＤ３０２の構造の一例を示す。テーブルの構造は、サービスフォーム５Ａ（図５）に対応している。テーブルの構造は、レコードの複数のＩＤ夫々にサービスのＩＤに、サービスの利用者（５０１）、サービス要望名称（５０２）、希望価格（５０３）、利用時期（５０４）、要望場所（５０５）、値（５０６）を対応させている。これらの項目は、サービスの特定に必要なものとして例示したものに過ぎず、これに限定されるものではない。

図９に、サービス要望（追加）テーブルＤ３０３の構造の一例を示す。テーブルの構造は、サービスフォーム５Ｂ（図５）に対応している。テーブルの構造は、サービスのＩＤ（６１０）に、サービスの要望ＩＤ（６１１）、追加項目名称（６１２）、追加項目の関連情報（値）（６１３）を対応させている。これらの項目は、サービスの特定に必要なものとして例示したものに過ぎず、これに限定されるものではない。

図１０にサービス供給テーブルＤ３０４の構造の一例を示す。テーブルの構造は、サービスフォーム６Ａ（図６）に対応している。テーブルの構造は、サービスのＩＤ６０１に、サービス名称６０２、サービス供給者名６０３、価格６０４、供給時期６０５、供給場所６０６、値（供給量）６０７を対応させている。これらの項目は、供給可能なサービスの特定に必要なものとして例示したものに過ぎず、これに限定されるものではない。

図１１に、サービス供給（追加）テーブルＤ３０５の構造の一例を示す。テーブルの構造は、サービスフォーム６Ｂ（図６）に対応している。テーブルの構造は、サービスのＩＤ（６１０）に、サービスの供給 ＩＤ（６１１）、追加項目名称（６１２）、追加項目の関連情報（値）（６１３）を対応させている。これらの項目は、サービスの特定に必要なものとして例示したものに過ぎず、これに限定されるものではない。

次に、サービス情報参照フェーズ（図４Ａ）について説明する。任意のタイミングで、需要者側計算機１１１のサービスフォーム参照モジュールＦ１１３（図２）から、サーバ計算機１０１が、サービス提供情報の取得要求を受信する（Ｓ１０６）と、サーバ計算機１０１のサービスフォーム参照モジュールＦ１０４は、サービスの情報（サービスＩＤ）を検索キーとして、サービス提供テーブルＤ３０４と、サービス提供（追加）テーブルＤ３０５を検索して、検索キーの値に該当するか、或いは、キーの値に類似するサービスフォームを検索結果として、サービスフォーム参照モジュールＦ１１３に送信する（Ｓ１０７）。これにより需要者は要望したサービスに適合するサービスが提供されているか否かを確認できる。

任意のタイミングで、供給者側計算機１２１のサービスフォーム参照モジュールＦ１２３（図２）から、サービスフォーム参照モジュールＦ１０４が、サービス要望情報の取得要求を受信する（Ｓ１０８）と、サービスフォーム参照モジュールＦ１０４は、サービスの情報を検索キーとして、サービス要望テーブルＤ３０２と、サービス要望（追加）テーブルＤ３０３を検索して、例えば、検索キーの値に該当するか、或いは、検索キーの値に類似するサービスフォームを検索して、検索結果をサービスフォーム参照モジュールＦ１２３に送信する（Ｓ１０９）。これにより供給者側計算機１２０は提供するサービスに適合するサービスが要望されているか否かを確認することができる。

図１２に、サービスフォーム参照モジュールＦ１０４のフローチャートを示す。サービスフォーム参照モジュールＦ１０４は、サービスフォーム参照モジュールＦ１１３又はＦ２１３からサービスフォームの参照のリクエスト受信する（Ｓ３０１）。Ｓ３０１では、サービスフォーム参照モジュールＦ１０４は、サーバ計算機１０１の負荷を管理するために、リクエストのログを履歴情報として履歴情報テーブルＤ３１１に登録する。

次に、サービスフォーム参照モジュールＦ１０４は、ユーザ情報取得処理（Ｓ３０２）、次いで、ユーザ認証（Ｓ３０３）を行う。これらの処理は、図７に示すフローチャートの説明と同じである。サービスフォーム参照モジュールＦ１０４は、Ｓ３１１において、既述のように、サービスフォームを参照する（Ｓ１０６−Ｓ１０９）。その際、サービスフォーム参照モジュールＦ１０４は、サービスの内容が同一又は類似のものについて、複数のサービスフォーム（入力用フォーム）の中から、参照回数が多いサービスフォーム、実績回数（図１３において後述）が多いサービスフォーム、或いは、適合度が高いサービスフォームから優先して抽出することができる。したがって、ユーザは、例えば、アクセスが多く関心を集めるサービスフォーム、自分のサービスにより適合しているサービスフォーム等優先順位にしたがってサービスフォームを参照できるようになる。参照回数、実績回数、或いは適合度は優先度の例である。優先度とは、複数の処理対象について、処理を優先させる度合いをいう。

サービスフォーム管理モジュールＦ１０２は、サービス情報管理フェーズ（図４Ａ）において、履歴情報テーブルＤ３１１を参照し、サービスフォームの参照回数等の管理情報をサービス情報管理テーブルＤ３０６に記録する。サービスフォーム参照モジュールＦ１０４は、サービスフォームの参照のために、テーブルＤ３０１〜Ｄ３０５を参照する。

次いで、サービスフォーム参照モジュールＦ１０４は、ユーザ認証の結果、参照されるサービスフォームをサービスフォーム参照モジュールＦ１１３又はＦ１１４に通知する（Ｓ３０６）。

図１３は、サービス情報管理テーブルＤ３０６の構造の一例を示す。サービス情報管理テーブルＤ３０６はサービスフォームを管理するものであって、具体的には、サービスフォームが要望のサービスフォームであるか提供のサービスフォームであるかを問わずにこれらを一緒に管理する。４０１は、テーブルのエントリを区別するＩＤであり、４０２は、サービス ＩＤ４０１（外部キー）である。サービス ＩＤの中の「Ｒ」はサービスフォームが要望であることを示し、「Ｐ」はサービスフォームが提供であることを示す。４０３は、サービスフォームが参照された回数であり、４０４は、あるサービスフォームについて、需要者と供給者との間でマッチングができた回数（実績回数）であり、４０５は、マッチングやサービスの事前評価において、サービスの需要者の要望をサービスの供給者が満足させる度合い、即ち、適合度である。なお、適合度の詳細については後述する。

サービスフォーム管理モジュールＦ１０２は、サービス情報管理フェーズ（図４）において、サーバ計算機１０１の負荷の低減、処理能力の維持のため、テーブルの最適化処理を実行する（Ｓ１１１）。テーブルの最適化処理は、テーブルから重複データや参照回数が少ないデータを削除すること、又は、テーブルを圧縮することを含む。サービス情報管理フェーズは、既述のフェーズとは異なるタイミングで実施されてよい。最適化処理は、サーバ計算機１０１の管理用計算機１００ＡからのリクエストＳ１１０を契機として実行されてよい。以上により、サービスフォームの登録や参照において、データの処理量が増大する場合でも、サービスフォームの参照、登録の迅速処理、ＩＣＴリソースの処理量、及び、蓄積データ量の削減を図ることができる。

図１４に、サービスフォーム管理モジュールＦ１０２のフローチャートの一例を示す。サービスフォーム管理モジュールＦ１０２は、履歴情報テーブルＤ３１１から履歴情報を読み込み（Ｓ３３１）、ユーザ情報テーブルＤ３０１からユーザ情報を読み込む（Ｓ３０２）。後者の理由は、ユーザ情報テーブルにも最適化処理を行うためである。Ｓ３０４の内容は、既述のフローチャートの説明と同じである。

サービスフォーム管理モジュールＦ１０２は、Ｓ３３２において、テーブルの情報が管理条件を満たしているか否かを判定する。例えば、サービス情報管理テーブルＤ３０６のレコードを走査して、サービスフォームをテーブルに登録後一定期間内での参照回数が管理値以下のレコードからサービスＩＤを抽出し、このサービスＩＤをキーにして、サービスフォームが登録されたテーブルを検索し、サービスＩＤに属するレコードをテーブルから削除する。Ｓ３０６では、サービスフォーム管理モジュールＦ１０２は、Ｓ３３２の処理結果を管理用計算機１００Ａ（図４Ａ）に通知する。

図１５に、サービスマッチング実行モジュールＦ１０６（図２）のフローチャートの一例を示す。サービスマッチング実行モジュールＦ１０６は、ユーザ情報テーブルＤ３０１を参照して、マッチングの対象となるユーザの情報を取得する（Ｓ３０２）。サービスマッチング実行モジュールＦ１０６は、マッチングのために、サービス情報管理テーブルＤ３０６、サービス要望テーブルＤ３０２，Ｄ３０３、サービス提供テーブルＤ３０４，Ｄ３０５を参照する（Ｓ３０４）。

サービスマッチング実行モジュールＦ１０６は、テーブルのサービスＩＤ毎にマッチング条件を判定する（Ｓ３４１）。例えば、サービスマッチング実行モジュールＦ１０６は、サービス要望テーブルＤ３０２，Ｄ３０３のサービスＩＤ毎にサービス提供テーブルＤ３０４，Ｄ３０５の全てのサービスＩＤを順番に走査して、サービスの要望内容に合致した提供可能サービスを抽出する。ここで、“合致”とは、既述のとおり、両者が完全に一致する場合の他、一部一致を含む。例えば、サービスマッチング実行モジュールＦ１０６は、サービス情報管理テーブルＤ３０６を参照し、マッチング検討対象のサービスＩＤに、適合度（図１３:４０５）が設定されている場合には、適合度の範囲で“合致”を判断する。例えば、適合度を８０パーセントとすると、サービスの要望量の８０パーセント以上満たすことができるサービスであれば、サービスマッチング実行モジュールＦ１０６はこのサービスを要望されたサービスにマッチングさせてよい。

需要者側計算機１１１は適合度をサービス要望テーブルＤ３０２又はＤ３０３に登録することができる。供給者側計算機１２１も適合度をサービス提供テーブルＤ３０４又はＤ３０５に登録することができる。サービスフォーム管理モジュールＦ１０２は、適合度をサービス情報管理テーブルＤ３０６に登録する。また、例えば、サービスフォーム管理モジュールＦ１０２は、サービスの種類、ユーザの業種にしたがって、過去のサービスマッチングの実績の統計情報から、適合度を設定してもよい。またさらに、サービスマッチング実行モジュールＦ１０６は、提供されるサービスの事前評価（後述）の結果に基づいて、サービスマッチングを行ってもよい。

サービスマッチング実行モジュールＦ１０６はＳ３４１を肯定判定すると、Ｓ３０６（サービスマッチング後処理）に移行し、サービスマッチングの情報をサービスマッチングテーブルＤ３０７に記録する。サービスマッチングテーブルＤ３０７は、サービスマッチングが成立した、需要者側サービスＩＤと供給者側サービスＩＤとの組み合わせ、需要者側のユーザＩＤ、供給者側ユーザＩＤ、サービスマッチングの成立年月日等、サービスマッチングに係る情報を記録する。

サービスマッチング実行モジュールＦ１０６は、さらに、サービス要望テーブルＤ３０２，Ｄ３０３、サービス提供テーブルＤ３０４，Ｄ３０５、そして、ユーザ情報テーブルＤ３０１に、サービスマッチングに伴う関連情報を記録する。

サービスマッチング実行モジュールＦ１０６は、サービスマッチングされたユーザである、需要者計算機１１１にサービスマッチングされた供給者側サービスの情報（供給者のユーザ情報、供給者側サービスのサービスフォーム等）を通知する（図４Ａ：Ｓ１１２）。さらに、サービスマッチング実行モジュールＦ１０６は、供給者側計算機１２１にサービスマッチングされた需要者側サービスの情報（需要者のユーザ情報、需要者側サービスのサービスフォーム等）を通知する（Ｓ１１３）。この通知を受けた、需要者側計算機１１１と供給者側計算機１２１とは直接に通信して（Ｓ１１４）、需要者と供給者との間の契約の締結を促すようにできる。

サービスマッチング実行モジュールＦ１０６はＳ３４１を否定判定すると、サービスマッチングを行うことなく、次のサービスＩＤについて、マッチング条件を判定する。なお、サービスマッチング実行モジュールＦ１０６は図１５に示すフローチャートを、所定期間ごとに実施する。サービスマッチングの成立は、サービス情報管理テーブルＤ３０６等に記録されるため、サービスマッチング実行モジュールＦ１０６は、サービスマッチングの成立記録がないサービスＩＤについてのみサービスマッチングの成立の要否を判定してもよい。

供給者は、需要者が作成したサービスフォームを参照して、需要者の要望に応じる形でサービスフォームを入力してもよい。この場合、供給者が作成するサービスフォームのサービスＩＤには需要者が作成したサービスフォームのサービスＩＤがリンクされる。一方、需要者は、供給者が作成したサービスフォームを参照して、供給者のオファーに応じる形でサービスフォームを入力してもよい。

この場合、需要者が作成するサービスＩＤには供給者が作成したサービスフォームのサービスＩＤがリンクされる。サービスマッチング実行モジュールＦ１０６は、このようなリンクが形成された需要者と提供者との間のマッチングの要否を優先的に判定するようにしてもよい。

サービスマッチング実行モジュールは、既述のサービスフォーム、そして、テーブルに含まれるサービスの詳細な記述情報に基づいてマッチングを実行できるために、従来のようなＱ＆Ａのような定型的なマッチングとは異なり、需要者の要求が多彩かつ複雑でも、需要者と供給者とのマッチングを可能にする。

次に、供給者のサービスの事前評価について説明する。取引システムの好適な態様では、サーバ計算機１０１が事前評価を行い、評価結果を需要者と供給者とのマッチングの要否の判断に利用する。需要者にとってみれば、自身が望むサービスに適合するサービスを提供可能な複数の供給者が分かっても、供給者のサービスが実際に行われなければどのサービスが最適なのかは明らかでない。

そこで、サーバ計算機１０１は、供給者のサービスを、需要者と供給者との取引の成立前に、事前に検証するシステムを備える。サーバ計算機１０１は、事前検証が可能な範囲でのデータを需要者に求め、一方、供給者には、サービスを検証、評価、分析等するための手法（計算方法、関数等）を求め、データ及び手法に基づいて供給者のサービスをシミュレートして、需要者側の要望との比較を行い供給者のサービスが要望に合致しているか否かを判定する。

需要者側計算機１１１のサービス評価データ入力モジュールＦ１１４（図２）は、サーバ計算機１０１のサービス評価データ取得モジュールＦ１０７に、サービス評価のためのデータを入力する（図４Ｂ：Ｓ２０３）。サービス評価データ取得モジュールＦ１０７は、このデータをサービスフォーム評価データテーブルＤ３０９に登録する（Ｓ２０４）。

サービス評価のためのデータは、サービスを例えば、空調機の性能の劣化を判定することであると仮定すると、空調機の運転データなど、空調機の性能の劣化の演算の根拠となるデータである。

サービス評価のためのデータは、サービス評価指標を含む。サービス評価指標とは、サービスの分析結果と比較されるものであって、サービスの分析結果を評価するためのベースとなるデータである。サービス評価指標は、需要者側で作成された分析結果でよく、既述の例でいえば、空調機の性能劣化に関する過去の実例での演算結果でよい。サービスの分析結果がサービスの評価指標と比較されることによって、供給者側のサービスが需要者の要望に合ったものであるかが分かる。

サービス評価データ入力モジュールＦ１１４（図２）は、サーバ計算機１０１のサービス評価データ取得モジュールＦ１０７にサービス評価データを送信する（Ｓ２０３）。サービス評価データ取得モジュールＦ１０７は、サービス評価指標をサービス評価指標テーブルＤ３１０に登録する。

供給者側計算機１２１のサービス評価データ入力モジュールＦ１２４（図２）は、サーバ計算機１０１のサービス評価データ取得モジュールＦ１０７に、サービス評価のためのデータを入力する（Ｓ２０５）。サービス評価のためのデータは、サービスの評価手法（演算方法等）を含む。サーバ計算機１０１のサービス評価データ分析モジュールＦ１０８は、既述の根拠データを評価手法に基づいて演算し、演算結果をサービス評価指標と比較する（Ｓ２０６）。

比較結果は、需要者の要望に対する供給者のサービスの適合の可否を示唆する。サービス評価データ分析モジュールＦ１０８は、評価結果を供給者側計算機１２１のサービス評価データ入力モジュールＦ１２４に出力する。

サービス評価データ取得モジュールＦ１０７は評価手法を、サービス評価手法テーブルＤ３０８に登録する。サービス評価データ分析モジュールＦ１０８は事前評価結果をサービス評価データテーブルＤ３０９に登録する。サービス評価系モジュールＦＡ４は評価結果を需要者側計算機Ｆ１１１に出力する。

サービスマッチング実行モジュールＦ１０６は、サービス評価データテーブルＤ３０９を参照して、事前評価結果が適合であればサービスマッチングを実行してもよい。サービスマッチング実行モジュールＦ１０６は、需要者が供給者を指定することに基づいて、マッチングの対象として選択した供給者について、事前評価を実施しその結果に応じてマッチングの可否を決定してもよい。なお、適合の判定には既述の適合度を加味してもよい。

事前評価のための演算を、サービス評価データ分析モジュールＦ１０８ではなく、提供者側計算機１２１が行うようにしてもよい。その際、サービス評価データ取得モジュールＦ１０７は、サービス評価データ取得モジュールＦ１２４の求め（Ｓ２０８）に応じて、分析用データをサービス評価データ取得モジュールＦ１２４に提供し、一方、評価手法の入力を求めない。

サービスマッチング実行モジュールＦ１０６は、事前評価をマッチングの要件に含ませないようにしてもよい。その場合、サービス評価データ分析モジュールＦ１０８は、マッチングされた供給者のサービスについて事前評価を実行させてもよい。需要者が供給者を指定して、事前評価が実施されるようにしてもよい。

サービス評価系モジュールＦＡ４は、事前評価の要否を、例えば、サービスフォーム（要望・提供）に記録されたフラグ情報に基づいて判定してもよい。ユーザは、サービスフォームに、事前評価の要否をフラグとして設定できる。サービス評価データ取得モジュールＦ１０７はサービスフォームを参照して、需要者と供給者の双方からのフラグを確認すると、フラグが立っているサービスＩＤについて事前評価を実施するために、ユーザ計算機１１１と１２１に事前評価に必要な情報の入力を求める。サービス評価データ分析モジュールＦ１０８は、サービスフォームに基づいてサービスの事前評価が設定されたサービスＩＤについて事前評価を行ったのち、サービスマッチング実行モジュールＦ１０６に事前評価結果に基づいてマッチングを実行させてもよい。

次に、サービス評価データ分析モジュールＦ１０８のフローチャートの一例を図１６に基づいて説明する。サービス評価データ分析モジュールＦ１０８は、事前評価を適用するユーザ情報のために、ユーザ情報の取得処理を実行する（Ｓ３０２）。次いで、サービス評価データ分析モジュールＦ１０８は、サービスの事前評価が必要なサービスＩＤを確認するために、サービス要望テーブルＤ３０２，Ｄ３０３、サービス提供テーブルＤ３０４，Ｄ３０５を参照する（Ｓ３０４）。この際、参照回数が多いサービスＩＤについて、優先的に事前評価を実施する等のために、サービス情報管理テーブルＤ３０６を参照してもよい。

サービス評価データ分析モジュールＦ１０８は、サービスの事前評価が必要なサービスＩＤについて、サービス評価データテーブルＤ３０９から評価データを取得する（Ｓ３４１）。次いで、サービス評価データ分析モジュールＦ１０８は、サービスの事前評価が必要なサービスＩＤについて、サービス評価手法テーブルＤ３０８から評価手法を取り込み、さらに、サービス評価指標テーブルＤ３１０からサービス評価指標を取り込み、サービスの事前評価分析を行う（Ｓ３４２）。

サービス評価データ分析モジュールＦ１０８は、Ｓ３０４，Ｓ３４１，Ｓ３４２をサービスの事前評価を要する他のサービスＩＤについても適用する。サービス評価データ分析モジュールＦ１０８はＳ３４２を終了すると、Ｓ３０６において、サービス評価結果反映モジュール（図２：Ｆ１０５）に、サービスの事前評価をサービスマッチングテーブルＤ３０７に登録させ、サービスマッチング実行モジュールＦ１０６にこれを利用させてもよい。

次に、サービスの事前評価を、空調機の性能劣化の判定評価を例として、具体的に説明する。図１７にサービス評価データテーブルＤ３０９の一例を示す。サービス評価データは、サービスＩＤ毎にデータ名とデータ値によって特定される。さらに、図１８にサービス評価指標テーブルＤ３１０の一例を示す。サービス評価指標は、サービスＩＤ毎に指標名称と指標値によって特定される。さらにまた、図１９にサービスの指標手法テーブルＤ３０８の一例を示す。サービスの評価手法は、サービスＩＤ毎に、サービス評価名と、評価手法によって特定される。これらテーブル間で、サービスはサービスＩＤ（外部キー）によって連携されている。

サービスＩＤが“１”のサービスについて、サービス評価データとして、「データ名称：１℃当たりの変化時間」、「値：２０１００７１０＿１０１０００―１２３０、２．５分」、「値：２０１５０７１０＿１０１０―１３００、３分」が記録されている。なお、このデータは、空調器の温度変更操作（１℃分の変更）をしてから、実際の目標の温度になるまでの時間を表現している。データとして、設備の型番やデータの単位などを含めてもよい。

空調機の性能劣化の判定とは、空調機に対するある時点で一定量のエネルギーを投入しそれに対し得られる効果を基に、経年劣化によりどれぐらいの性能があるか、という処理に関係している。サービスの供給者は、サービス評価データを取得し、供給者のサービスの評価手法をサービス評価手法テーブルＤ３０８に登録する。サービス評価名は性能劣化診断になり、評価手法として線形予測や閾値判定が実施される。具体的な計算処理のアルゴリズム、関数式も合わせて登録される。

サービス評価データ分析モジュールＦ１０８は、供給者のサービスがどの程度の精度や価値があるかの演算を実施する。そして、演算結果をサービス評価指標と比較する。例えば、演算結果が「値：２０１６０７１０＿１０１０００―１４３０、４．５分」であり、対応するサービスＩＤのサービス評価指標が、「名称：性能値」、「値：２０１６０７１０＿１０１０００−１５００、５分」であるとすると（図６：サービスＩＤ“１”）、両者の差分である０．５分（５分−４．５分）を算出する。サービス評価データ分析モジュールＦ１０８は適合度を勘案して、評価結果に基づいて、供給者のサービスの需要者の要望に対する適否を判断するようにしてもよい。例えば、適合度が９０パーセントであるとすると、０．５分という差分は、評価指標の５分の１０パーセント以内であるから、事前評価結果は、適合ということになる。

サーバ計算機１０１は、事前評価での適合を、サービスマッチングの要件としてもよいし、サービスマッチングの候補とされた需要者−供給者間において、需要者側計算機１１１がサーバ計算機１０１又は供給者側計算機１２１の求めに応じて、サーバ計算機１０１が事前評価を行うようにしてもよい。事前評価は、既述のように、供給者側計算機１２１によって行われてもよい。サービス評価指標は、需要者が所有する過去の分析結果であってよい。サービス評価指標は、サーバ計算機１０１が、過去のデータに基づくなどして設定されてもよい。事前評価には、必ずしも、評価指標は必須ではない。この場合、サーバ計算機１０１は、分析結果、既述の例でいうと、“４．５分”を評価結果として出力すればよい。なお、既述の実施形態の説明は一例であって、本発明を限定するものではない。

１００ マーケットプレイスシステム
１０１ サーバ計算機
１１０ 需要者側システム
１１１ 需要者側計算機
１２０ 供給者側システム
１２１ 供給者側計算機

Claims (14)

1. 複数の需要者と複数の供給者との間の取引を支援する取引システムであって、
   ネットワークに接続されたサーバ計算機を備え、
   取引の需要者側の複数の計算機と取引の供給者側の複数の計算機とが前記ネットワークに接続され、
   前記サーバ計算機は、
   前記需要者側の複数の計算機の少なくとも一つと、前記供給者側の複数の計算機の少なくとも一つと、の間で行われる取引に介在するための処理を行うプロセッサと、
   前記複数の需要者側計算機の夫々から出力された、前記取引に関する需要者側情報と、前記複数の供給者側計算機の夫々から出力された、前記取引に関する供給者側情報と、を記録するメモリと、
   を備え、
   前記メモリは、
   前記需要者側情報として、前記取引のための要望事項の基本要素を含む第１のデータブロックと、当該要望事項の追加要素を含む第２のデータブロックと、
   前記供給者側情報として、前記取引のための提供事項の基本要素を含む第３のデータブロックと、当該提供事項の追加要素を含む第４のデータブロックと、
   を記録し、
   前記プロセッサは、
   前記需要者側の複数の計算機の夫々に、前記メモリへの前記需要者側情報の登録と、前記メモリから供給者側情報の参照とを可能にし、
   前記供給者側の複数の計算機の夫々に、前記メモリへの前記供給者側情報の登録と、前記メモリから需要側情報の参照とを可能にする
   取引システム。
2. 前記プロセッサは、
   前記需要者側情報と前記供給者側情報とに基づいて、前記取引のための要望事項と、前記取引のための提供事項と、を比較し、
   前記要望事項に適合する提供事項が設定された取引の対象を決定し、
   当該決定された取引の対象に基づいて、需要者と供給者との組み合わせを設定する
   請求項１記載の取引システム。
3. 前記プロセッサは、
   前記需要者側情報と前記供給者側情報の少なくとも一方に基づいて、優先度を設定し、
   当該優先度に従って、前記取引のための要望事項と、前記取引のための提供事項と、を比較する
   請求項２記載の取引システム。
4. 前記プロセッサは、
   前記要望事項への前記提供事項の適合の有無を適合度の範囲内で決定する、
   請求項２記載の取引システム。
5. 前記プロセッサは、
   前記要望事項に前記提供事項の複数を適合させる、
   請求項２記載の取引システム。
6. 前記プロセッサは、
   前記要望事項の事前評価を行い、
   当該事前評価の結果に基づいて、前記要望事項に適合する前記提供事項を決定する、
   請求項１記載の取引システム。
7. 前記プロセッサは、
   前記事前評価を前記需要者側計算機と前記供給者側計算機とから夫々提供されたデータに基づいて実行する、
   請求項６記載の取引システム。
8. 前記プロセッサは、
   前記事前評価を需要者側計算機から提供されたデータに基づいて、前記供給者側計算機に実行させる、
   請求項６記載の取引システム。
9. 前記プロセッサは、
   前記事前評価に適合した提供事項を前記要望事項に組み合わせる、
   請求項６記載の取引システム。
10. 前記プロセッサは、
    前記適合の有無を適合度の範囲内で決定する、
    請求項９記載の取引システム。
11. 前記プロセッサは、
    前記需要者側の複数の計算機のうち、前記メモリへ前記需要者側情報を登録しようとする第１の計算機と、前記供給者側の複数の計算機のうち、前記メモリへ前記供給者側情報を登録しようとする第２の計算機とに、夫々、情報登録用入力フォームを提示し、
    当該入力フォームを提示することを、複数の情報登録用入力フォーム夫々の優先度にしたがって、所定の入力フォームを抽出し、当該所定の入力フォームを提示することによって実行する、
    請求項１記載の取引システム。
12. 前記プロセッサは、前記メモリに、前記需要者側情報と前記供給者側情報とを、登録した後、夫々の優先度に基づいて、当該登録した情報を最適化する、
    請求項１記載の取引システム。
13. 複数の需要者と複数の供給者との間の取引を支援する取引システムの制御方法であって、
    取引の需要者側の複数の計算機と取引の供給者側の複数の計算機とを接続するネットワークに接続されたサーバ計算機は、
    前記需要者側の複数の計算機の少なくとも一つと、前記供給者側の複数の計算機の少なくとも一つと、の間で行われる取引に介在するために、
    前記複数の需要者側計算機の夫々から出力された、前記取引に関する需要者側情報と、前記複数の供給者側計算機の夫々から出力された、前記取引に関する供給者側情報と、をメモリに記録し、
    前記需要者側情報を、前記取引のための要望事項の基本要素を含む第１のデータブロックと、当該要望事項の追加要素を含む第２のデータブロックとし、
    前記供給者側情報を、前記取引のための提供事項の基本要素を含む第３のデータブロックと、当該提供事項の追加要素を含む第４のデータブロックとし、
    前記需要者側の複数の計算機の夫々に、前記メモリへの前記需要者側情報の登録と、前記メモリから供給者側情報の参照とを可能にし、
    前記供給者側の複数の計算機の夫々に、前記メモリへの前記供給者側情報の登録と、前記メモリから需要側情報の参照とを可能にする
    取引システムの制御方法。
14. 複数の需要者と複数の供給者との間の取引を支援する取引システムの制御のためのプログラムであって、
    取引の需要者側の複数の計算機と取引の供給者側の複数の計算機とを接続するネットワークに接続されたサーバ計算機に、
    前記需要者側の複数の計算機の少なくとも一つと、前記供給者側の複数の計算機の少なくとも一つと、の間で行われる取引に介在するために、
    前記複数の需要者側計算機の夫々から出力された、前記取引に関する需要者側情報と、前記複数の供給者側計算機の夫々から出力された、前記取引に関する供給者側情報と、をメモリに記録させる機能と、
    前記需要者側情報を、前記取引のための要望事項の基本要素を含む第１のデータブロックと、当該要望事項の追加要素を含む第２のデータブロックとする機能と、
    前記供給者側情報を、前記取引のための提供事項の基本要素を含む第３のデータブロックと、当該提供事項の追加要素を含む第４のデータブロックとする機能と、
    前記需要者側の複数の計算機の夫々に、前記メモリへの前記需要者側情報の登録と、前記メモリから供給者側情報の参照とを可能にする機能と、
    前記供給者側の複数の計算機の夫々に、前記メモリへの前記供給者側情報の登録と、前記メモリから需要側情報の参照とを可能にする機能と、
    を実現させるためのプログラム。

Images