(57)【要約】【課題】  システムにより十分利益を出している場合も、利益も出さない場合も同じように費用が掛かってしまう。つまり、システムの利用者にとっては、支払いのリスクが発生してしまう。つまり、システムを導入して儲けがなくとも、必ず安くない対価を支払わなくてはいけない。このため、システムの購入の阻害になるとの課題があった。【解決手段】  本発明では、システムの利用回数に基づき、システムの対価を算出する構成とした。本発明には、以下の態様も含まれる。複数のシステム（それぞれが所定の機能を実行する）からなる業務システムにおいて、各システムの機能を利用した回数を計測し、それに基づいて、各システムを提供した提供者に対する対価を算出する。【選択図】  図１
2006330777.tif 000002
【特許請求の範囲】
【請求項１】
それぞれが予め定められた機能を実行する複数のシステムを有する業務システムにおい
て、
予め、前記システムそれぞれを提供した提供者と対応付けて記憶する手段と、
利用者が希望する機能を特定する情報を受信する手段と、
受信された機能を実行するシステムの提供者を前記記憶する手段に記憶された内容に基
づいて、特定することで、特定された提供者が提供したシステムの利用回数をカウントす
る手段と、
カウントされた利用回数に基づき、当該提供者に対するシステム提供の対価を計算する
手段とを有することを特徴とする業務システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、それぞれが所定の機能を有するシステムを有する業務システムの対価の算出
に関する。業務システムとして、送金や入出金処理を行う金融システムが含まれる。
【背景技術】
【０００２】
従来、ソフトウエアやいわゆるシステムの対価を計算する場合、構築前に見積もりを構
築者（提供者）が算出することが行われている。例えば、特許文献１にあるように、機能
項目ごとに費用（対価）算出していた。
【０００３】
【特許文献１】特開２００４−１７８５３０号公報
【発明の開示】
【発明が解決しようとする課題】
【０００４】
しかしながら、特許文献１の場合、実際にシステム（ソフトウエア）を導入者において
、このシステムにより十分利益を出している場合も、利益も出さない場合も同じように費
用が掛かってしまう。つまり、システムの利用者にとっては、支払いのリスクが発生して
しまう。つまり、システムを導入して儲けがなくとも、必ず安くない対価を支払わなくて
はいけない。このため、システムの購入の阻害になるとの課題があった。
【課題を解決するための手段】
【０００５】
そこで、本発明では、システムの利用回数に基づき、システムの対価を算出する構成と
した。本発明には、以下の態様も含まれる。複数のシステム（それぞれが所定の機能を実
行する）からなる業務システムにおいて、各システムの機能を利用した回数を計測し、そ
れに基づいて、各システムを提供した提供者に対する対価を算出する。より具体的には、
それぞれが予め定められた機能を実行する複数のシステムを有する業務システムにおいて
、予め、前記システムそれぞれを提供した提供者と対応付けて記憶する手段と、利用者が
希望する機能を特定する情報を受信する手段と、受信された機能を実行するシステムの提
供者を前記記憶する手段に記憶された内容に基づいて、特定することで、特定された提供
者が提供したシステムの利用回数をカウントする手段と、カウントされた利用回数に基づ
き、当該提供者に対するシステム提供の対価を計算する手段とを有する。
【０００６】
なお、本発明では、利用回数に限らず、そのシステムでの売上げや履歴を計測し、これ
に基づいて対価を算出してもよい。
【発明の効果】
【０００７】
本発明によれば、システムの利用に応じた対価を算出でき、よりシステム購入をし易い
環境にすることが可能になる。
【発明を実施するための最良の形態】
【０００８】
本発明の実施の形態について、図面を用いて説明する。
【０００９】
まず、本実施の形態におけるシステム構成図を図１に示す。端末１−１、端末１−２、
ＰＣ２、処理装置３は、ネットワークを介して互いに接続されている。これらの装置は、
いわゆる処理装置（ＣＰＵ）、プログラムを記憶した記憶装置を有し、処理装置がこのプ
ログラムに従って情報処理を行ういわゆるコンピュータである。つまり、処理装置は、図
２に示す対応表、図３に示すログＤＢを有し、図４に示すフローチャートに従って、処理
装置が情報処理を実行するものである。
【００１０】
以下、本実施の形態の処理内容について、説明する。
【００１１】
まず、ステップ１０１において、顧客が利用する端末１−１、端末１−２、ＰＣ２の入
力に応じて、取引メニューの受信を行う。顧客が選択できる取引メニューとしては、送金
、入出金、外為、投信などがある。
【００１２】
次に、ステップ１０２において、図２の対応表から提供者を特定する。本実施例では、
顧客が送金を選んだ場合で説明する。ここでは、対応表から提供者は、Ａ社となる。次に
、ステップ１０３において、特定された提供者について、取引回数を＋１する。特定され
た提供者がＡ社の場合、図３の例では、回数を＋１し、３になる。次に、ステップ１０４
において、取引実行またはキャンセル指示を受信し、キャンセル指示の場合は、ステップ
１０５により、取引回数を−１する。図３の例では、回数を−１し、２に戻る。ここでは
、上記のフローに従っているが、取引実行時にのみ取引回数を＋１するフローでもよい。
次に、ステップ１０６において、提供者へのフィーを算出し、ステップ１０７において、
フィーをログＤＢに登録する。図４の例では、３回×￥１，０００＝￥３，０００が書き
込まれる。フィーの算出モデルとしては、回数に一定の金額を掛けた金額（図５）とする
。それ以外にも、取引が１件もなかった場合に、一定の固定費を支払うモデル（図６）、
ある一定の回数を超えた場合に掛ける金額の減額を行うモデル（図７）、回数の上限を設
定し、それ以上のフィーを支払わないモデル（図８）など、バリエーションはいろいろ考
えられる。次に、ステップ１０８において、一定日時になったかを判定し、なった場合に
は、ステップ１０９において、支払い処理を実行する。例えば、１ヶ月に１度支払い処理
を実行するなどが考えられる。次に、ステップ１１０において、ログＤＢの取引回数、フ
ィーを０にクリアする。
【産業上の利用可能性】
【００１３】
本発明は、取引の仲介を、コンピュータを用いて実現することが可能になる。
【図面の簡単な説明】
【００１４】
【図１】システム構成図である。
【図２】対応表である。
【図３】ログＤＢである。
【図４】フローチャートである。
【図５】回数とフィーの関係を示す第１のグラフである。
【図６】回数とフィーの関係を示す第２のグラフである。
【図７】回数とフィーの関係を示す第３のグラフである。
【図８】回数とフィーの関係を示す第４のグラフである。
【符号の説明】
【００１５】
１−１…端末、１−２…端末、２…ＰＣ、３…システム。
【図１】
2006330777.tif 000003
【図２】
2006330777.tif 000004
【図３】
2006330777.tif 000005
【図４】
2006330777.tif 000006
【図５】
2006330777.tif 000007
【図６】
2006330777.tif 000008
【図７】
2006330777.tif 000009
【図８】
2006330777.tif 000010