(57)【要約】企業体間の外貨交換取引をコンピュータ・ネットワークによって容易にする方法であり、この方法は、企業体と電気的に通信するための通信チャネルを有する中央サーバ・システムを用提供することを含み、それによって、登録された第１企業体の代表者が、中央サーバ・システムへアクセスできるようにする。そして、代表者は、取引しようとしている通貨の対の対の組み合わせを選ぶことができる。次いで、システムは、中央サーバ・システムに登録された第２企業体からの代表者によって提示される、選択した通貨の対の対の組み合わせに対し少なくとも１つのレートを表示し、第２企業体は、第１企業体との相互信用限度を確立し終る。最後に、第１企業体の代表者は、通貨の対の対の組み合わせに対するオーダーを設定することができ、それによって、このオーダーが提示レートと比べられ、一致する場合には取引が行われ、不一致の場合にはオーダーの提示となる。
2004522223.tif 000002
【特許請求の範囲】
【請求項１】
企業体間で外貨交換取引を行うことをコンピュータ・ネットワークによって容易にする方法が、
企業体と電子的に通信を行うための通信チャネルを有する中央サーバ・システムを提供し、それによって、登録されている第１企業体の代表者が、中央サーバ・システムへアクセスできるようにする行為と、
代表者が取引しようとしている通貨の対の組み合わせを選択できるようにする行為と、
中央サーバ・システムに登録された第２企業体からの代表者によって提示された、選択された通貨の対の対の組み合わせの内の少なくとも一方のレートを表示し、第２企業体が第１企業体との相互信用限度を確立し終った行為と、
第１企業体の代表者が通貨の対の対の組み合わせに対してオーダーを設定できるようにし、それによって、該オーダーが提示レートと比べられ、一致した場合には、取引が行われ、不一致の場合には、オーダーが提示されるようにする行為と、
から成る方法。
【請求項２】
取引の明細はディスプレイに表示されるようになる請求項１に記載の方法。
【請求項３】
中央サーバ・システムにより、企業体が、代表者によって取引され得る総額を制限することができるようにした請求項１に記載の方法。
【請求項４】
中央サーバ・システムにより、企業体が、取引できる期間を指定することができるようにした請求項１に記載の方法。
【請求項５】
企業体によって与えられた信用限度の予定のパーセンテージを取引が上回った場合に、中央サーバ・システムが、取引が行なわれないよう阻止するようにした請求項１に記載の方法。
【請求項６】
中央サーバ・システムにより、企業体が予定のパーセンテージを決定することができるようになる請求項５に記載の方法。
【請求項７】
所与の通貨の対の対の組み合わせに対する３つの最良レートが提示されるようになる請求項１に記載の方法。
【請求項８】
通貨の総額が、レートと共に提示されるようになる請求項１に記載の方法。
【請求項９】
通貨の総額が、レートと共に掲示されるようになる請求項７に記載の方法。
【請求項１０】
総額は複数のオーダーからの合算であり得る、請求項８に記載の方法。
【請求項１１】
総額が複数のオーダーからの合算であり得る、請求項９に記載の方法。
【請求項１２】
一致するオーダーが得られたとき、総額が更新されるようになる請求項８に記載の方法。
【請求項１３】
一致するオーダーが得られたとき、総額が更新されるようになる請求項９に記載の方法。
【請求項１４】
一致するオーダーが得られたとき、総額が更新されるようになる請求項１０に記載の方法。
【請求項１５】
一致するオーダーが得られたとき、総額が更新されるようになる請求項１１に記載の方法。
【請求項１６】
中央サーバ・システムにより、企業体が、顧客に対する外国為替オーダーを通信チャネルを介して直接送ることができるようになる請求項１に記載の方法。
【請求項１７】
顧客が、ネットワークを介して外国為替オーダーを設定することができるようになる請求項１６に記載の方法。
【請求項１８】
顧客が、ネットワークを介してアクセスしたオーダー開始インタフェースを使用して、オーダーを設定することができるにした請求項１７に記載の方法。
【請求項１９】
オーダー開始インタフェースが、企業体のシステムによって提供されるようにした請求項１８に記載の方法。
【請求項２０】
インタフェースが、オーダー・タイプに対するフィールドを含むようになる請求項１８に記載の方法。
【請求項２１】
企業体のシステムにより、顧客によって設定されたオーダーをオーダー・モニタを介して見ることができるようになる請求項１９に記載の方法。
【請求項２２】
顧客によって設定されたオーダーが、顧客にサービスを提供している企業体によって実行されるようにした請求項２１に記載の方法。
【請求項２３】
顧客が企業体に担保を設定するようにした請求項１６に記載の方法。
【請求項２４】
顧客が企業体に担保を設定するようにした請求項１７に記載の方法。
【請求項２５】
設定された担保の総額に基づいて顧客が取引することのできる総額に対する限界を企業体がセットするようにした請求項２３に記載の方法。
【請求項２６】
設定された担保の総額に基づいて顧客が取引することのできる総額に対する限界を企業体がセットするようにした請求項２４に記載の方法。
【請求項２７】
コンピュータ・ネットワークによって企業体間で外貨交換取引を行うのを容易する方法であって、
企業体と電子的に通信するための通信チャネルを有する中央サーバ・システムを用意する行為と、
第１企業体を登録し、それによって、代表者が、管理者、信用調査係、およびトレーダの役割を割り当てられ、各々の役割が、中央サーバ・システムにアクセスするために適切なログインＩＤおよびパスワードを要求する行為と、
取引しようとしている通貨の対の対の組み合わせをトレーダが選択できるようにする行為と、
中央サーバ・システムに登録された第２企業体からのトレーダによって提示された、選択した通貨の対の対の組み合わせに対し少なくとも１つのレートを表示し、第２企業体が第１企業体との相互信用限度を確立し終る行為と、
第１企業体のトレーダが通貨の対の対の組み合わせに対しオーダーを設定することができるようにし、それによって、オーダーが提示されたレートと比較され、一致する場合には、オーダーの完了となり、不一致の場合には、オーダーの提示になるようにする行為と、
から成る方法。
【請求項２８】
取引がディスプレイに表示されるようになる請求項２７に記載の方法。
【請求項２９】
中央サーバ・システムにより、管理者が、トレーダによって取引され得る総額を制限することができるようにした請求項２７に記載の方法。
【請求項３０】
中央サーバ・システムにより、企業体が、取引に見越される期間を明記することができるようにした請求項２７に記載の方法。
【請求項３１】
中央サーバ・システムにより、企業体に与えられた信用限度の予定のパーセンテージを取引が上回る場合に、取引発生を阻止することができるした請求項２７に記載の方法。
【請求項３２】
中央サーバ・システムにより、信用調査係が予定のパーセンテージを決定することができるにした請求項３１に記載の方法。
【請求項３３】
所与の通貨の対の対の組み合わせに対して３つの最良レートが提示されるようになる請求項２７に記載の方法。
【請求項３４】
通貨の総額がレートと共に掲示されるようになる請求項２７に記載の方法。
【請求項３５】
通貨の総額がレートと共に掲示されるようになる請求項３３に記載の方法。
【請求項３６】
総額が複数のオーダーからの合算であり得る請求項３４に記載の方法。
【請求項３７】
総額が複数のオーダーからの合算であり得る請求項３５に記載の方法。
【請求項３８】
一致するオーダーが得られたとき、総額が更新されるようになる請求項３４に記載の方法。
【請求項３９】
一致するオーダーが得られたとき、総額が更新されるようになる請求項３５に記載の方法。
【請求項４０】
一致するオーダーが得られたとき、総額が更新されるようになる請求項３６に記載の方法。
【請求項４１】
一致するオーダーが得られたとき、総額が更新されるようになる請求項３７に記載の方法。
【請求項４２】
中央サーバ・システムにより、企業体が、顧客に対する外国為替オーダーを通信チャネルを介して直接送ることができるようになる請求項２７に記載の方法。
【請求項４３】
顧客が、ネットワークを介して外国為替オーダーを設定することができるになる請求項４２に記載の方法。
【請求項４４】
顧客が、ネットワークを介してアクセスされたオーダー開始インタフェースを用いて、オーダーを設定することができる、請求項４３に記載の方法。
【請求項４５】
オーダー開始インタフェースは、企業体のシステムによって提供されるようになる請求項４４に記載の方法。
【請求項４６】
インタフェースは、オーダー・タイプに対するフィールドを含んでいるようになる請求項４４に記載の方法。
【請求項４７】
企業体のシステムにより、顧客によって設定されたオーダーをオーダー・モニタを介して見ることができるようにした請求項４５に記載の方法。
【請求項４８】
顧客によって設定されたオーダーが、顧客にサービスを提供している企業体によって実行できるようにした請求項４７に記載の方法。
【請求項４９】
顧客が企業体に担保を設定するようにした請求項４２に記載の方法。
【請求項５０】
顧客が企業体に担保を設定するようにした請求項４３に記載の方法。
【請求項５１】
設定された担保の総額に基づいて顧客が取引できる総額に対する限界を企業体がセットするようにした請求項４９に記載の方法。
【請求項５２】
設定された担保の総額に基づいて顧客が取引できる総額に対する限界を企業体がセットするようにした請求項５０に記載の方法。
【請求項５３】
企業体にアカウントを設けている顧客間で外貨交換取引を行なうのをコンピュータ・ネットワークによって容易にする方法であって、
顧客と電子的に通信するための通信チャネルを有する企業体のシステムを提供する行為と、
企業体のシステムに顧客を登録し、それによって、登録された顧客が企業体のシステムへアクセスすることができるようになり、また、登録された顧客が企業体に担保を設定することができるようになる行為と、
取引しようとしている通貨の対の対の組み合わせを顧客が選択できるようにする行為と、
登録された顧客によって提示された、選択した通貨の対の対の組み合わせに対し少なくとも１つのレートを表示する行為と、
登録された顧客が通貨の対の対の組み合わせに対しオーダーを設定することができるようにし、それによって、そのオーダーを提示レートと比べ、一致した場合には取引となり、不一致の場合にはオーダーの提示となるようにする行為と、
取引を決済する行為と、
から成る方法。
【請求項５４】
取引の明細がディスプレイに表示されるようになる請求項５３に記載の方法。
【請求項５５】
企業体のシステムが、顧客によって取引され得る総額を制限し、その限界は、顧客によって設定された担保の総額によって決定されるようにした請求項５３に記載の方法。
【請求項５６】
所与の通貨の対の対の組み合わせに対する３つの最良レートが提示されるようになる請求項５３に記載の方法。
【請求項５７】
通貨の総額がレートと共に掲示されるようにした請求項５３に記載の方法。
【請求項５８】
通貨の総額がレートと共に掲示されるようにした請求項５６に記載の方法。
【請求項５９】
総額は複数のオーダーからの合算であり得る請求項５７に記載の方法。
【請求項６０】
総額は複数のオーダーからの合算であり得る請求項５８に記載の方法。
【請求項６１】
一致するオーダーが得られたとき、総額が更新されるようになる請求項５７に記載の方法。
【請求項６２】
一致するオーダーが得られたとき、総額が更新されるようになる請求項５８に記載の方法。
【請求項６３】
一致するオーダーが得られたとき、総額が更新されるようになる請求項５９に記載の方法。
【請求項６４】
一致するオーダーが得られたとき、総額が更新されるようになる請求項６０に記載の方法。
【請求項６５】
企業体は銀行である請求項５３に記載の方法。
【請求項６６】
顧客は銀行のアカウント保持者である請求項６５に記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一般的には金融取引を容易にするためのシステムの分野に関するものであり、特に、ネットワークを通して外貨交換取引を容易にするためのシステムに関する。
【背景技術】
【０００２】
毎日、数十億ドル相当のドル通貨が売買されている。外国為替（又は「ｆｏｒｅｘ」）として普通知られている通貨の売買は、金融業界に必要不可欠な活動である。高い取引高にもかかわらず、通貨は他の数多くの金融商品とは異なる方法で売り買いされる。たとえば、株は、公開入札システムを有する公開市場において販売される。適正なプロトコルに従っていて、充分な資金が存在することを示すことができる限り、実質的に、（或る程度の制約はあるが）誰でも、提示価格で株を購入することができる。言い換えれば、株の価格は、購入者の社会的地位で決まるわけではないし、売り手が買い手を差別して選り好みすることもできない。
【０００３】
一方、通貨は、公開市場で売買されない。昔から、ｆｏｒｅｘ市場は、常に、或る機関が、信用力があるとみなした別の機関と取引する、という閉鎖的制度であった。実際、取引が実行される前に、取引している機関との信用限度を決める必要が常にある。信用限度は、機関毎に変り得る。一般的に言えば、明らかに、大きな資金額および優良な信用格付けを有する大機関は、限られた資産しか持たない小さな機関よりも高い信用限度を与えられることになる。しかしながら、信用限度は１つの機関によって別の機関に与えられるものであり、中央組織によって認められるものではないから、１つの機関が、取引している相手によって異なった信用限度を有する可能性がある。
たとえば、Ａ銀行は、Ｂ銀行に対して１００，０００，０００ドルの信用限度を有しても、Ｃ銀行については８０，０００，０００ドルの信用限度しか持たないかも知れない。
【０００４】
同様に、１つの機関が別の機関に請求する為替レートさえ、その機関の現状に応じて変わる可能性がある。為替レートを決定するには、一般的には数多くの要因が関係している一方で、或る機関が、優良な顧客であるとみなす機関に対しもっと有利なレートを提供する、といったこともまれではない。
【０００５】
種々の為替レートが種々に異なった機関に適用されるため、そして、最初に信用限度を確立しなければならないため、通貨は、公開市場でたやすく売買することはできない。本質的には、信用限度というものは、或る程度充分な資金レベルを持たない機関に与えられることはまずあり得ないので、ｆｏｒｅｘ取引は、優良信用格付けを有する大きい機関にしか委託されない。それに加えて、為替レートは部分的には取引の規模によって決まるので、充分な規模の取引だけが行われることとなり、これがまた、小さい機関がｆｏｒｅｘ市場に参入するのを制限するのである。
【０００６】
ｆｏｒｅｘ取引は、大部分、いまだに人的な方法で行われている。たとえば、銀行のような或る機関が他の銀行との通貨取引を望むとき、その銀行を代表するトレーダは、他の銀行を代表するトレーダと手作業により連絡をとる。そして標準的な交渉が続いて、為替レートが、インターバンク・レートや、信用度や、取引中の通貨の安定度などのような種々の要因（すべて、ｆｏｒｅｘ市場で周知の要因である）を適用することによって、決定される。
【０００７】
取引をある程度まで自動化するために、これまで多数のｆｏｒｅｘシステムが開発されて来て、現在使用されている。このようなシステムの１つが、米国特許第５，７８７，４０２号、米国特許第５，９７８，４８５号、および米国特許第５，５０８，８１３号に記載されている。他のシステムも、www.forextradlng.comといったようにインターネット上で見つけられるが、そのいくつかは、銀行を選択した一握りのグループに対してのみ利用できる専用システムである。このような専用システムの１つは、一般的に言って、銀行のうち最大級の銀行のみを受け入れる電子ブローキング・システム（ＥＢＳ）として知られている。
【特許文献１】米国特許第５，７８７，４０２号
【特許文献１】米国特許第５，９７８，４８５号
【特許文献１】米国特許第５，５０８，８１３号
【発明の開示】
【発明が解決しようとする課題】
【０００８】
ｆｏｒｅｘ取引に関する現在利用できる大部分のシステムは、一般的に、２つの異なったカテゴリに入る。
第１のタイプとしては、或る機関が他の機関と取引するのを許可するシステムがある。基本的には、このタイプのシステムでは、或る取引の明細を入力し、取引をオンラインで実行することができる。このタイプのシステムは、基本的には、１対１である。すなわち、単一の金融機関に対して１つのｆｏｒｅｘオーダーしか提出することができない。このシステムは取引を行うのを簡単にすることができるが、信用限度の確立といったような全ての必要なプロトコルは、なお依然として達成されなければならない。
【０００９】
第２のタイプは、ｆｏｒｅｘ取引に対する市場を創り出すために機関ネットワークを提供するというシステムである。取引が行なわれる前に依然として信用限度が確立される必要があるけれども、或る機関の信用限度がいったん確立されれば、異なった複数の機関によって提示されたいくつかの為替レートにアクセスすることができる。このようなシステムは、通貨に対する疑似公開市場と考えられ得る。現在、この第２タイプのシステムは、超大資本を有する選択されたグループの銀行に対してのみ参加を限っている専用システムとして利用されている。
【００１０】
これらのシステムは、全般としてはｆｏｒｅｘ取引に伴う数多くの従来の手作業工程を自動化するのであるが、本質的には従来のｆｏｒｅｘ取引をもっと楽にするというためのシステムである。これらシステムが、ｆｏｒｅｘ取引それ自体の基本的な性質を変えるということはない。たとえば、これらのシステムでは全部、事業体は、取引が実行される前に、依然として信用限度を確立しなければならない。たとえば、正味財産の少ない個人がｆｏｒｅｘ取引を行ないたいと思っても、どの機関もこのような個人に信用限度を与えることはないので、その人はｆｏｒｅｘ取引を行うことはできないであろう。同じことが、比較的小額の通貨を売買する必要のある、小規模から中規模程度の会社にも当てはまる。この現行の自動化システムは、より効率的にはなったが、本質的にはいまだに閉鎖的なシステムなのである。
【００１１】
とはいえ、小さい機関や個人が通貨を売買したいという、道理にかなった理由がある。これを利用しようとする人達の要求は、現在のところ、既存のシステム（従来の手作業システムであろうと、自動化システムであろうと）では満たされていない。もちろん、現在でも小規模事業体が通過を売買するのは可能ではあるが、インターバンク市場において請求されるレートよりも相当に高いレートを要求する銀行やあるいは他の金融機関から、直接、通貨を購入しなければならない。これは、多くの小さな機関の多くにとって容認されるものでなく、確かに最善のものではない。したがって、現在必要とされるのは、ｆｏｒｅｘ市場の基本的な経済基盤をこれからも保持し続けながらも、大銀行であるとか他の大きな機関だけに参加者を限定しないという新しい通貨取引の方法なのである。
【００１２】
したがって、本発明の目的は、上記の従来技術システムの欠点を解消する、通貨の交換を容易にするための方法およびシステムを提供することにある。
【課題を解決するための手段】
【００１３】
本発明のシステムは、２つの取引層を有する。第１層は、金融機関および他の企業体が通貨を売買できるウェブベースの外国為替取引（「ｆｏｒｅｘ」）市場を含む。このｆｏｒｅｘ市場において行われる取引は、一般的に、Ｂ２Ｂ（企業-対-企業）取引と呼ぶことにする。典型的には、これらの企業体は銀行であるけれども、本発明のシステムは、他の企業体（たとえば、会社法人であるとか、公共機関とか、あるいは個人さえも含む）をも受け入れる。ｆｏｒｅｘ市場に参加するために、特殊なソフトウェアはまったく不要である。企業体側に必要なのは、Internet ExplorerかNetscapeのようなインターネット・ブラウザが全てである。銀行のような企業体は、現在、銀行間に存在している現行の信用限度構造で取引することが可能である。
【００１４】
本発明のシステムの第２層は、Ｂ２Ｃ（企業-対-顧客）取引を容易にするものであり、この場合、企業は、その企業体自身の顧客に対しｆｏｒｅｘ取引能力を提供することができる。このＢ２Ｃの特徴により、各企業体が、インターネットを介して自分達のそれぞれの顧客からｆｏｒｅｘオーダーを取り付けるのを可能にするのである。このシステムは、オーダーの注文を受け付ける前に、担保および保証金についてオンライン・チェック機能を提供する。各企業体は、顧客の注文にヒットすることで自分達の顧客から受けた注文に働きかけたり、あるいは、厳密に各企業体の裁量で、（おそらく、最初にスプレッドを加えて）それぞれの企業体の信用限度を使用して、それぞれの企業体の名義でｆｏｒｅｘ市場へ注文を通したりと、選択することができるようになっている。このような方法で、企業体の顧客はｆｏｒｅｘ市場へとリンクされてゆく。顧客のオーダーを直接的に処理する能力により、企業体は、顧客のオーダーをより自由に受け入れることができるのである。
【００１５】
本発明のシステムは、ウェブサーバ・エンジン２２と、データベース兼アプリケーション・マネージャ２４と、複数のウェブ・ページ２６とから成る、中央サーバ・システム２０を含む。中央サーバ・システム２０は、ウェブベースのｆｏｒｅｘ市場を確立し、ウェブ・ページを介して必要なインタフェースを提供することによって企業体間での通貨の取引を容易にする。中央サーバ・システムは、インターネットを介して企業体のサーバ・システムにリンクされる。企業体のサーバ・システムは、ウェブサーバと、Ｂ２Ｃエンジンと、企業体の様々な代表者のＰＣと、企業体のレガシーｆｏｒｅｘシステムと、から成る。企業体のサーバ・システムは、インターネットを介して、企業体の顧客のＰＣにリンクされる。企業体のシステムは、そのウェブサーバとＢ２Ｃとを介して、Ｂ２ＢとＢ２Ｃの両方の取引を容易にする。基本的には、顧客側のＰＣでは、インターネット・ブラウザがあって、そこに適切なインターネット接続するだけである。
【００１６】
本発明の一実施例においては、企業体間の外貨交換取引を達成するためにコンピュータ・ネットワークによって促進される方法は、企業体と電子的に通信するための通信チャネルを有する中央サーバ・システムを用意する工程を含んでおり、これによって、登録されている第１企業体の代表者が、中央サーバ・システムへアクセスするのを許可される。次いで、この代表者は、取引しようとしている通貨の対の組み合わせ（通貨ペア）を選ぶことが認められる。すると、システムは、中央サーバ・システムに登録されている第２企業体からの代表者によって提示された選択通貨の対の組み合わせの内の少なくとも一方のレートを表示し、第２企業体は、第１企業体との相互信用限度を確立したことになる。そして最後に、第１企業体の代表者が通貨の対の組み合わせについてオーダーを出すことが許され、これによって、このオーダーが、提示されたレートと比べられる。そして、一致した場合には取引成立し、不一致の場合にはオーダーの提示ということになる。
【００１７】
別の実施例では、企業体間の外貨交換取引を達成するのをコンピュータ・ネットワークによって容易にされる方法が、企業体との電子通信のための通信チャネルを有し且つ第１企業体を登録している、という中央サーバ・システムを用意する工程を含み、これによって、代表者は、管理者と、信用調査係と、トレーダの役割を割当てられることになり、中央サーバ・システムにアクセスするために、各々の役割には固有のログインＩＤとパスワードが必要である。次に、トレーダは、取引しようとしている通貨の対の組み合わせを選ぶことが認められ、そして、システムは、中央サーバ・システムで登録された第２企業体からのトレーダによって提示された選択通貨の対の組み合わせの内の少なくとも一方のレートを表示し、第２企業体は、第１企業体との相互信用限度を確立したことになる。そして最後に、第１企業体のトレーダは、通貨の対の組み合わせについてのオーダーを出すことが許され、これによって、このオーダーが、提示されたレートと比べられ、一致した場合にはオーダーの成立となり、不一致の場合にはオーダーの提示となる。
【００１８】
企業体にアカウントを有する顧客同士間の外貨交換取引を達成するためにコンピュータ・ネットワークによって促進される別の方法は、顧客との電子通信を行なうための通信チャネルを有し且つ企業体システムに顧客を登録している、という企業体システムを用意する工程を含み、それによって、登録されている顧客が、企業体システムへアクセスすることができるようになり、そして、登録されている顧客が、企業体に担保を設定する。そうすると、顧客は、取引しようとしている通貨の対の組み合わせを選ぶことを認められ、システムが、登録されている顧客に提示された選択通貨の対の組み合わせの内の少なくとも一方のレートを表示するので、登録されている顧客は通貨の対の組み合わせについてオーダーを出すことができるようになる。それによって、オーダーが提示されたレートと比べられ、一致した場合には取引となり、不一致の場合にはオーダーの提示となる。次いで、取引が決済される。
【発明を実施するための最良の形態】
【００１９】
以下添付図面を参照して本発明の好適な実施の形態を詳細に説明する。
【実施例１】
【００２０】
図１は、本発明の全般的な概念を示す象徴的な説明図である。好ましい実施例において、本発明のシステムは、２つの取引層を有する。第１の層は、金融機関及び他の企業体１２が通貨を売買できるウェブベースの外国為替（「ＦＯＲＥＸ」）市場１０を含む。このｆｏｒｅｘ市場１０において行なわれるこれらの取引は、全般的に、Ｂ２Ｂ（企業-対-企業）取引と呼ぶことにする。典型的には、これらの企業体は銀行であるが、本発明のシステムは、他の事業体（たとえば、企業法人、公共機関、さらには個人でさえも）に対応できる。しかしながら、銀行が本発明のシステムの最多のユーザであろうから、以下、説明例として頻繁に銀行に言及する。しかしながら、ユーザとしては、銀行以外の他の広範囲にわたる事業体が含まれることは了解されたい。
【００２１】
ｆｏｒｅｘ市場１０に参加するためには、なんら特殊なソフトウェアは必要なく、企業１２に必要なのは、Internet ExplorerまたはNetscapeのようなインターネット・ブラウザだけである。銀行のような企業体は、現在、銀行間に存在する現行の信用限度構造で取引することが可能である。好ましい実施例においては、ｆｏｒｅｘ市場１０は、インターネットのサブスクリプション・ベースでこれらの企業体１２が自由に利用できるが、各参加事業体は、本発明のシステムを使用して行った各取引を決済するべく法的義務を負う。Ｂ２Ｂ層は、システムのＢ２Ｃ層から独立して操作できる。
【００２２】
図１について更に説明すると、本発明システムの第２の層はＢ２Ｃ（企業-対-顧客）取引を容易にするもので、この場合、企業は、その企業体１２自体の顧客１４に対してｆｏｒｅｘ取引能力を提供することができる。一番典型的なのは、顧客が銀行のアカウント保持者となることであり、したがって、この事業関係をたびたび説明例として以下に使用することになるが、しかし、明らかに他のシナリオも可能である。たとえば、顧客は、企業の従業員でもあるかもしれない。このＢ２Ｃ機能では、各企業体は、インターネットを介してそれぞれの顧客からｆｏｒｅｘオーダーを受け取ることができる。システムは、オーダーの応募を受け入れる前に担保および保証金のオンライン・チェックを行う。各企業体は、顧客の注文にヒットすることで自分達の顧客から受けた注文に働きかけたり、あるいは、厳密に各企業体の裁量で、（おそらく、最初にスプレッドを加えて）それぞれの企業体の信用限度を使用して、それぞれの企業体の名義でｆｏｒｅｘ市場へ注文を通したりと、選択することができるようになっている。このような方法で、企業体の顧客はｆｏｒｅｘ市場へとリンクされてゆく。顧客のオーダーを直接的に処理する能力により、企業体は、顧客のオーダーをより自由に受け入れることができるのである。一方、本発明のシステムは、企業体に、オーダーの受け入れ，拒否，あるいは「転送」のような管理制御を与えることによって企業体を保護する。顧客に請求されるスプレッドは、なんでも全く企業体の裁断である。
【００２３】
図２は、本発明の金融システムの好ましいアーキテクチャ全体を示している。図１及び図２の両図を参照して説明すると、中央サーバ・システム２０は、ウェブサーバ・エンジン２２、データベース兼アプリケーション・マネージャ２４および複数のウェブ・ページ２６からなる。中央サーバ・システム２０は、ウェブベースのｆｏｒｅｘ市場１０を確立し、ウェブ・ページ２６を介して必要なインタフェースを提供することによって企業体１２間での通貨の取引を促進する。中央サーバ・システム２０は、企業体のサーバ・システム３０にインターネット３９を介してリンクされる。企業体のサーバ・システム３０は、ウェブサーバ３２、Ｂ２Ｃエンジン３４、企業体の様々な代表者のＰＣ３６および企業体のレガシーｆｏｒｅｘシステム３８を含む。企業体のサーバ・システム３０は、企業体の顧客のＰＣ４０にインターネット３９を介してリンクされる。企業体のシステム３０は、そのウェブサーバ３２およびＢ２Ｃ３４を通して、Ｂ２Ｂ及びＢ２Ｃの両取引を容易にする。顧客のＰＣ４０は、基本的には、インターネット・ブラウザ４２と適切なインターネット接続が必要なだけである。
【００２４】
本発明のシステムの好ましい実施例を使用してｆｏｒｅｘ市場１０に参加するためには、企業体の代表者は、トレーダ、信用調査係、および管理者の、３つの異なった役割を割当てられる必要がある。各役割を努める使用者は、固有のログインＩＤおよびパスワードを割り当てられ、システムが、その役割に対し適切なインタフェースへのアクセスを与えるだけである。図８に示されるインタフェースによって表わされているように、トレーダの主な役目は、ウェブベースのＢ２Ｂディーリングルームでｆｏｒｅｘ取引を行なうことである。とりわけ、信用調査係の主な役割は、取引に関係する団体に信用限度を割り当て、信用グループを形成することである。また、中でも、管理者の主な役目は、たとえばユーザをトレーダから管理者に変えると言ったようなユーザ役割を更新することや、個別のトレーダについての取引限度を更新するとか、好ましい決済方法を明確にするなど、多くの管理業務を取り扱うことにある。これらの代表者の各々は、ＰＣを使用して任意の場所からインターネットを介して中央サーバ・システム２０にアクセスすることができる。一般的には、ＰＣは物理的に企業体サイトに設置されており、企業体のウェブサーバ３２を通過してゆくのであるが、企業体のシステム３０の外部にあるＰＣも使用し得ることは了解されたい。
【００２５】
図３は、データベース兼アプリケーション・マネージャ２４を詳細に示している。ユーザ・プロフィール・マネージャ５１が、中央サーバ・システム２４と、この中央サーバ・システム２４にアクセスしている企業体３０の様々な代表者との間のインタフェース作用を促進する。ユーザ明細（たとえば、ユーザ名、ログインＩＤ、暗号化パスワードなど）が、ユーザ・プロフィール・データベース５２に格納されている。認証マネージャ５３が、ユーザ・プロフィール・マネージャ５１およびユーザ・プロフィール・データベース５２と協働し、たとえば、ユーザのユーザＩＤを対応するパスワードと照合することによってユーザを認証する。許可マネージャ５５が、ユーザ・プロフィール・マネージャ５１と協働し、ユーザに割当てられた役割に従って適切な活動を許可する。たとえば、トレーダとして指定されたユーザは、企業体に代わって通貨を売買する許可を与えられることになるが、信用調査係として指定されたユーザにのみ指定された活動である、信用限度を割当てたり変えたりするということは許可されない。
【００２６】
オーダー・マネージャ５７は、オーダーの入力や取消しといったような、（トレーダによって設定された）オーダーの管理を取り扱う。設定されたが、実行されていない（すなわち、まだ売買されていない）オーダーは、未決オーダー・データベース５６に格納される。実行されたオーダーは、実行済みオーダー・データベース５８に格納される。決済マネージャ５６が、決済情報（たとえば、決済方法および決済アカウント情報）の取扱いを管理し、決済データベース６０内に情報を格納する。
【００２７】
通貨マネージャ６１は、中でも、通貨の対の組み合わせの管理を取り扱い、その明細は、通貨の対の組み合わせ・データベース６２に格納される。これらの明細は、たとえば、US$／Yen、通貨乗数、および最小／最大取引範囲といったような、許可された通貨の対の組み合わせのリストのような情報を含む。
【００２８】
休日マネージャ６３は、休日及びオフアワーの追跡を続け、すべての関連情報を休日／オフアワー・データベース６４に格納する。ニュースフィード・マネージャ６５が、さまざまなソースからのニュースフィードを受け取り、ニュースフィード・データベース６６に関連情報を格納し、ウェブ・ページの１つにニュースを表示する。レート・マネージャ６７は、主に、公共ソースから得られた種々の通貨の対の組み合わせの表示為替レートを表示する役割を果たす。表示レートは、レート・データベース６８に格納される。ニュース・マネージャ６９が、本発明システムと関係するニュースの表示を処理し、そして、ニュース・データベース７０がニュース情報を格納する。
【００２９】
信用マネージャ７１は、本発明システムによって提供されるｆｏｒｅｘ市場１０において取引する企業３０間の信用の授受を管理する。通貨が売買される前に、企業体は、まず、信用グループを確立し、これから取引が行なわれるすべての関係者に信用限度を与えなければならない。信用グループに関する情報は、信用グループ・データベース７６に格納される。様々な取引関係者に与えられる信用限度は、信用限度データベース７４に格納される。名称やアドレス等々の企業体の明細は、企業体データベース７２に格納される。
担保マネージャ７３が、顧客から企業体が受け取った担保情報の追跡を続け、担保データベース７８にこの情報を格納する。
【００３０】
図４は、企業体のシステム３０のＢ２Ｃエンジン３４の構成要素を示している。ユーザー・マネージャ８４は、企業体のシステム３０と、システム３０にこれからアクセスしようとしている企業体の顧客４０との間のインタフェース接続を、ユーザの認証を含めて、促進する。名称やアドレス等々のユーザ明細は、ユーザ・アカウント・データベース８２に格納される。一方、ユーザ・プロフィール・データベース８０は、ユーザＩＤ、パスワード、担保（タイプおよび額）などのようなユーザ情報を格納する。
【００３１】
オーダー・マネージャ９０は、オーダーの入力や取り消しのような、顧客よって設定されたオーダーの管理を取り扱う。設定されたが、実行されない（すなわち、まだ売買されていない）オーダーは、オーダー・データベース８６に格納される。実行済みのオーダーは、取引データベース８８に格納される。担保データベース９２は、担保の詳細を格納する。たとえば、データベース９２は、各顧客によって設定された担保のタイプと額を、そして、顧客によって実行された取引の損益を評価した後に残っている担保の額とを格納する。顧客が取引を実行すると、担保情報は定期的に更新される。
【００３２】
マージン・レート・データベース９４は、３つの主要なタイプのマージン・レート情報を含んでいる。第１のタイプは、銀行のような企業体が通貨の対の組み合わせの各取引について請求するコミッションであるスプレッド・マージンである。第２のタイプは、企業体に対して顧客によって設定された担保総額に基づいて顧客が売買できる最大総額を算出するのに使用されるイニシャル・マージンである。第３のタイプは、顧客が担保を上乗せする必要に迫られる前の、取引における損失分で使用された担保のパーセンテージであるメインテナンス・マージンである。担保およびマージン・レート情報の管理は、担保マネージャ３９６によって取り扱われる。
【００３３】
Ｂ２Ｃエンジンは、オプションとして、決済データベース９８および決済マネージャ９９を含めることができる。特定の企業体の要求によっては、銀行において最も普遍的に見られる企業体のレガシー・システムによって決済が処理される場合には、決済データベースは、単に決済方法（中央サーバ・システムの決済データベース６０に類似する）のような情報を含むだけでもよい。あるいはまた、決済データベース９８および決済マネージャ９９は、各企業体の顧客に対するアカウント・データすべてを組み入れることによって、決済プロセスにおいて、もっと積極的な役割を果すこともできる。
【００３４】
図５は、企業-対-企業、すなわち、Ｂ２Ｂ取引についての概略的なプロセスの流れを示している。ステップ１００において、本発明のシステムを使用して通貨を売買したいと思っている企業体は、各々の代表者がシステムに適切にアクセスすることができるように、まず、企業体それ自体とその代表者を中央サーバ・システム２０に登録しなければならない。代表者達には、管理者、信用調査係、そしてトレーダの役割を割当てられる必要がある。適正に登録されれば、管理者は、ステップ１０２において、トレーダによってｆｏｒｅｘオーダーが設定される前に、様々な管理活動を実施する。ステップ１０４において、企業体の信用調査係が１つ以上の他の企業体との信用限度を確立する。ステップ１０６において、信用調査係が中央サーバ・システム２０にアクセスし、信用グループを形成し、各グループに信用限度を割り当てる。ステップ１０８において、トレーダがディーリングルームにアクセスし、取引を行う。ステップ１１０において、システムが実行済みの取引を決済する。
【００３５】
ステップ１００において行われた企業体およびその代表者の登録は、オンラインでもオフラインでも行われ得るが、セキュリティを確保するためにオフラインで実施されるのが好ましい。登録プロセスは、基本的には、企業名、アドレス、連絡者、そして、企業が銀行である場合にはディーリング・コード、といったような登録企業体の明細を得ることが必要である。企業体は、また、管理者、信用調査係、およびトレーダの役割を果すユーザの明細も指定する。もちろん、必要ならば、１名だけの代表者が多数の役割を果すことも可能である。それぞれの役割プレーヤには、固有のログインＩＤおよびパスワードが割り当てられる。適正なログインＩＤおよびパスワードをもつユーザのみが、その特定の役割に対して許可された任務を遂行することができるものである。すべての情報は、図３のユーザ・プロフィール・データベース５２に格納される。好ましい実施例においては、多数の役割が定義してあるが、役割の形式的な分離が全くなされない構成とすることも可能であることは了解されたい。
【００３６】
ステップ１０２の管理任務は、管理者によって遂行される。とりわけ、管理者の役目は、或る特定のユーザによって果される役割に変更がある場合に、ユーザの役割を更新すること；或る特定のトレーダに対する取引限度、すなわち、トレーダが所与の日時に取引できる額についての限度を更新すること；取引バランスを更新すること、すなわち、トレーダが取引限度を超えて取引を行えるようにある特定のトレーダによってなされた取引のバランスを調整すること；取引時間、すなわち、トレーダたちによって取引が行われ得る時間の範囲を更新すること；トレーダのアカウントを稼働／停止させ、好ましい決済方法を創り出す、どのアカウントから売買された通貨を引き出すことになるかを定めるとか諸々の作業を行うことにある。
【００３７】
ステップ１０４において、銀行のような企業体が、たとえば別の銀行のような企業体と接触し、互いの相互信用限度を確立する。電話、電子メール、ファックス等々の種々の接触手段で通信することができる。信用限度という概念は銀行業界のような或る種の産業では良く理解されているが、ここで使用する「信用限度」という用語はもっと一般的で、通貨の交換が行なわれるように取引関係者間での理解を促進するメカニズムであり、あるいは契約ルールである、ということを意味していることは了解されたい。
【００３８】
ステップ１０６において、中央サーバ・システム２０にアクセスすることによって、１つ以上の企業体に対して信用が確立されたならば、信用調査係は、信用グループを形成し、信用限度を各々のグループ割り当てる。各信用グループは、１つ以上の企業体から成る単一の取引体を代表する。個々の事業体としては充分な信用限度を利用できない場合でも、１つのグループとしては、充分な信用限度を確立することができるようになるので、この信用グループにより、小さな機関が、多数の機関（通常、提携している）を集めているｆｏｒｅｘ市場に参加することができるようになる。たとえば、単一の銀行業務機関が、いくつかの国に多数の支店を有することがある。これらの支店は、個々に取引するのではなくて、１つの信用グループとして取引することを決めることができる。
【００３９】
信用グループの編成および信用限度の割り当ては、図９に示すインタフェースにアクセスすることによって実施される。信用調査係は、まず、与えられたフィールドにおいて信用グループ２４０の名前を入力する。どのような名前でも可である。次に、日毎の信用限度２４２を入力する。これは、図５のステップ１０４において確立された日毎信用限度である。次いで、警告パーセンテージ２４４（警告が与えられる前に利用できる信用のパーセンテージ）を入力する。信用限度がすでに以前に確立されている場合には、それは最新信用限度２４８の下に示される。利用可能バランス２５０は、どのくらいの信用が残っているかを示している。既存の信用グループのリストが、ディスプレイ・ボックス２５２に示される。
【００４０】
ひとたび信用グループが形成され、そして、信用限度が割り当てられたならば、信用調査係は、企業体を１つの信用グループに割り当てるためのプロセスである取引フロアを割り当てる。取引フロアの割り当ては、図１０に示すインタフェースを介して行われる。図示のように、図９のインタフェースを使用して形成された信用グループの名前が、ボックス２６０に示されている。すでに適正に登録されていて、システム２０へ適正に入力される企業体のリストが、ボックス２６２内にある。信用調査係は、まず、ボックス２６０内の信用グループを選択し、次に、この選択済みの企業グループに追加したいと思う企業名をボックス２６２から選択する。追加された企業体は、ボックス２６４に示される。ボックス２６２に掲げられているすべての企業体が信用グループに割り当てられてしまうまで、このプロセスが繰り返される。信用グループの編成で企業体が多数の事業体を一緒にまとめる融通性が得られるので、この機能は非常に望ましいけれども、このシステムは、各企業体がそれ自身の名前および信用限度の下に取引を行うという特徴を伴わず作動するということを承知されたい。
【００４１】
ステップ１０８において本発明のシステムを使用してトレーダがどのように通貨の取引を行なうかについての詳細を、図６及び６Ａに示すフローチャートおよび図８に示すインタフェース２００を参照しながら、以下に説明する。まず図６を参照すると、ステップ１２０において、トレーダは、図８に示すウェブ・インタフェース２００によって表わされるようなディーリングルームにアクセスする。次に、ステップ１２２において、トレーダは、ドロップダウン・メニュー２１０から通貨の対の組み合わせを選択する。各インタフェース２００は、２組の通貨の対の組み合わせを表示でき、この場合、日本円Ｙｅｎ対米国ドル（ＵＳＤ／ＪＰＹ）２０２と、米国ドル対ヨーロッパのユーロ（ＥＵＲ／ＵＳＤ）２０４とを示すことができることに留意されたい。しかしながら、取引プロセスを説明する目的のために、同一のステップ・セットがすべての通貨の対の組み合わせにあてはまるので、図示例としてＵＳＤ／ＪＰＹのみを以下で使用する。
【００４２】
ステップ１２４において、システムは、各通貨の対の組み合わせに対し最良レートを３つ表示する。提示されたレートは、現在のトレーダの企業体がそこと信用限度を確立した、そして、システムに入力され終わった企業体からのものである。ここで、ＵＳＤ／ＪＰＹに対する最良の３つのレートが、ディスプレイ・ボード２０６にリストで示される。交換レートの下２桁が、大きい方のボックス２０８に太字で示され、残りの桁は、小さい方のボックス２１０内に示されていることに注意されたい。左側のレート２１２は、米国ドルに買いの注文が出ているレートを示しており、したがって、米国ドルに最も好感度の高いレートは、ディスプレイ・ボード２０６を注視しているトレーダの立場からの「最良」レートと考えられる。トレーダの立場からの最良レートが、リストの最初に示される。右側のレート２１４は、米国ドルに売りの注文が出ているレートを示しており、したがって、米国ドルに対し好感度の最も低いレートが、トレーダの立場からの「最良」レートと考えられ、リストの最初に示される。小さい方のボックス２１０の直ぐ下の数字２１６は、乗数なしで示されたレートで買いをいれられている通貨のユニット数を示している。乗数係数２２８が、インタフェースの左側に示されている。ここでは、乗数が１００，０００となっているが、他の乗数（たとえば、１，０００，０００）も可能なのは明らかである。したがって、ここでは、数字「５５」は、５５×１００，０００、すなわち、５，５００，０００米国ドルを示している。額５５は単一の企業体によって設定されている必要がない、ということに注目されたい。いくつかの企業体が同じレートに対してオーダーを出したところで、総額が集計される。それ故、総額５５は、単一の企業体から来たものかもしれないし、複数の企業体によって設定されたいくつかのオーダーの合算であるかもしれない。しかしながら、インタフェース２００は、提示された総額が単一の企業体から来たものか、または多数の提示の合算であるかは示さない。
【００４３】
ステップ１２６において、トレーダは、「Ｔｙｐｅ」２１７の下にある「Ｂｉｄ」２１８または「Ａｓｋ」２２０を選択する。「Ｂｉｄ」を選択した場合、トレーダが日本円に対して米国ドルを買いたいことを示すことになり、「Ａｓｋ」を選択した場合、トレーダが日本円に対して米国ドルを売りたいことを示すことになる。例示目的だけのために、ここでは「Ａｓｋ」が選ばれていて、トレーダが、日本円に対して米国ドルを買いたいと思っているのを示している。ステップ１２８において、トレーダは、自分が売りたい或いは買いたい総額を総額フィールド２２２に入力する。乗数２２３は１００，０００であるので、例えば１０を入力することは、この場合は米国ドルであるが、１，０００，０００単位の通貨に相当することになることに留意されたい。
【００４４】
ステップ１３０において、トレーダは、ディスプレイ・ボード２０６に提示された「最良」レートで、買うのか、売るのか、を決める。イエスの場合、トレーダは、「Hit at Market Rate」２２６を選ぶ（ステップ１３２）。すると、システムは自動的に、トレーダがディスプレイ・ボード２０６に表示されている最良レートで取引したいといういことを想定する。トレーダが「Ｂｉｄ」を選んだ場合、「最良」レートは、ディスプレイ・ボード２０６の右側（「Ａｓｋ」側または「ｓｅｌｌ」側）にリストで示される最初のレートとなる。しかし、トレーダが「Ａｓｋ」を選択した場合には、「最良」レートは、ディスプレイ・ボード２０６の左側（「Ｂｉｄ」側または「ｂｕｙ」側）にリストで示された最初のレートとなる。次に、総額フィールド２２２で入力された総額は、最良レートに対してステップ１３４において示された総額２１６から差し引かれる。さて、「Ｔｙｐｅ」のところで「Ａｓｋ」が選択されたので、入力された総額「１０」が、総額「５５」２１６から差し引かれることになる。総額５５がいくつかの企業体によって設定されたオーダーの合算である場合、総額１０が、まず、最初に設置された「Ｂｉｄ」オーダーから差し引かれる。したがって、たとえば、企業体Ａが最初に８単位のオーダーを発注し、企業体Ｂが二番目に４７単位のオーダー（それ故、合計５５）を発注した場合、入力された総額１０のうち８が、まず、企業体Ａの８のオーダーから差し引かれ、次ぎに、残りの２単位が、企業体のオーダーの４７から差し引かれることになる。そして今度は、この差引勘定後に残っている総額が表示されるようになる。入力された総額がディスプレイ・ボード上で利用できる額よりも大きい場合、利用できる総額のすべてが、提示額から差し引かれ、そして、残りの総額が提示される。差引勘定が行なわれたならば、取引は、「done deal」（取引終了）とみなされ、そして、システムは、「Deal Done」セクション２２６にこの取引を表示する。このセクションは、現在のトレーダによって行なわれた取引を示すだけで、システム２０を使用して実施された取引のすべてをリストで示すわけではないことを承知されたい。
【００４５】
次に図６Ａを参照して説明すると、図６のステップ１３０において、トレーダが最良レートを採用しないと決めた場合、トレーダは、ステップ１４０において、レート・フィールド２２４に所望のレートを入力する。ステップ１４２において、システムは、提示レートに対してレートを一致させようとする。この場合は、入力したレートは１１６．７０であった、そして、取引は「Ａｓｋ」（ｓｅｌｌ）である。したがって、システム２０は、ディスプレイ・ボード２０６上の「Ｂｉｄ」サイド２１２にあるポスティングに注目し、トレーダの入力した値と一致しているか或いはもっと良い値をＢｉｄレートを提示した買い手がいるかどうかを見る。トレーダの入力したレートで米国ドルを買う気がある買い手が全然いないので、ステップ１４４での質問に対する答えは、「ノー」で、システムはステップ１４６に移動する。その一方、システムが、ステップ１４４で一致があると決定した場合には、システムは、ステップ１５６において、入力されたレートに一致するかまたはそれを超える提示レートから、入力された総額を差し引き、ステップ１５８において、「Deal Done」というセクション２２６の下にこの取引を表示する。
【００４６】
ステップ１４６において、入力されたオーダーは、他のオーダーの中で待ち行列に入れられる。入力されたオーダーが３つの最良レート内にある場合には、ステップ１４８においてディスプレイ・ボード２０６上に提示される。次に、システムは、一致するオーダーが、ステップ１５０においてシステムを使用している他の企業体のトレーダによって設定されるのを待つ。一致するオーダーが発見された場合には、システムは、この総額をステップ１５２において提示総額から差し引き、ステップ１５４においてこの取引を表示する。
【００４７】
ステップ１１０の決済プロセスは、管理者によって定められた方法に従ってシステムによって実施される。好ましい実施例においては、決済プロセスは、既存の決済プロセスを使用して企業体によってオフラインで実施される。
【００４８】
図７は、企業-対-顧客（Ｂ２Ｃ）取引の全体的なプロセスの流れを示している。ステップ１６０において、ｆｏｒｅｘ取引を行ないたい顧客は、まず、企業体に登録を行い、ログインＩＤおよびパスワードを得る。ステップ１６２において、顧客は、Ｂ２Ｃシステム上へログインし、オーダーを発注する。ステップ１６３において、顧客のオーダーはオーダー・モニタに送られて、トレーダが、いかにしてオーダーを最良に実行するかについて決定することができるようになる。ステップ１６４において、企業体のためのトレーダは、オーダーをＢ２Ｂシステムに送るかどうかを決定する。トレーダが「組織内」（in house ）でオーダーを実行する決意をした場合には、ステップ１６６において、顧客のオーダーを遂行する。しかしながら、トレーダがＢ２Ｂシステムを介して顧客のオーダーを実現することを決定した場合には、そのオーダーは、Ｂ２Ｂシステムに「転送」され、ステップ１６８において、顧客のオーダーの明細が、Ｂ２Ｂディーリングルーム・インタフェース２００（図８）に表示される。次に、ステップ１７０において、取引がディーリングルームで実行される。そして、企業体は、ステップ１７２において取引が行なわれた企業体との取引を決済する（「Ｂ２Ｂ」決済）。次いで、企業体は、ステップ１７４において顧客との取引を決済する（「Ｂ２Ｃ決済」）。
【００４９】
ステップ１６０において実施された顧客の登録は、オンラインでもオフラインでも行われ得るが、セキュリティを確実にするためにオフラインで実施されるのが一般的に好ましい。登録プロセスは、基本的には、顧客の明細、たとえば、名前、アドレス等々を得ることを伴う。登録プロセスは、また、必要な金融情報を獲得して顧客の信用分析を行うことによって、顧客の信用価値を決定するということを伴う。顧客は、企業体に対する担保を設定することも必要である。一般的に担保はキャッシュであるが、他の金融商品または物品であってもよい。たとえば、担保は、株、債券、或いは不動産であってもよい。顧客の設定した担保の額と、企業体によってその顧客に対して行われた顧客分析とに基づいて、企業体は、イニシアル・マージン・レートを決定し、これが、顧客の取引できる最高総額を計算するのに使用される。好ましい実施例においては、最高総額は、以下の式を用いて計算される。
2004522223.tif 000003
【００５０】
したがって、例えば、１０，０００米国ドルの担保総額に対して２０％のイニシアル・マージン・レートであるならば、最大総額は、５０，０００米国ドルで取引されるようにセットされる。ユーザの要求次第で上記の式については数多くの変形が可能であり、したがって、上記の式がほんの一例であることは了解されたい。
【００５１】
企業体は、また、担保を「つぎ足す」ことについて顧客に警告を与える前に、取引の損失相殺後に残っている担保額のパーセンテージであるメインテナンス・マージン・レートをセットする。たとえば、１０，０００米国ドルの担保が顧客によって設定された上記例を用いれば、５％のメインテナンス・マージン・レートとは、全損失が４５，０００米国ドルに達したときに警告が与えられる、ということを意味する。情報のすべてが受け入れられ、そして、適切な財務分析が行われたならば、顧客には、受注を行うのに必要なログインＩＤおよびパスワードが割り当てられる。
【００５２】
適正なログインＩＤおよびパスワードが獲得されれば、顧客は受注を行うことができる。図７のステップ１６２の受注は、図１１に示すインタフェースを介して実施される。ログインＩＤおよびパスワードを用いて、顧客は、まず、インターネットを介してＢ２Ｃシステムにアクセスする。顧客は、まず、Order Type２７０を選択する。好ましい実施例においては、Order Type２７０は、Take Profit、Stop Loss、あるいはCallである。「Take Profit」を選択するということは、入力されたレートが達成されるかそれを上回るときに、顧客オーダーが実行されることを意味する。他方、「Stop Loss」は、停止損失限界に達したときにオープン姿勢を終了するアクションによってさらなる損失が制限されるプライス・レベルである。「Call」とは、顧客のオーダーについての取引が実行される前に、確認のためにトレーダが顧客に電話をかける必要があることを意味する。
【００５３】
Order Type２７０で選択を行った後、顧客は、通貨の対の組み合わせ２７２（たとえば、US$／Yen）を選ぶ。顧客は、Buy／Sell２７４で通貨を売るか買うかを選択する。US$／Yenが通貨の対の組み合わせとして選択された場合、たとえば、「Buy」を選んだ場合、顧客が、Yenに対してUS$を購入したいと望んでいることを示すことになる。「Sell」を選んだ場合には、顧客がYenに対してUS$を売ることを望んでいることを示すことになる。それから、顧客は、Currency 1 Amount２７６、あるいは、通貨の対の組み合わせにおいて最初にリストに示される通貨を入力する。たとえば、通貨の対の組み合わせUS$／Yenが選択された場合、「最初の」通貨はUS$となろう。Currency 1 Amount２７６が入力されたならば、Currency 2 Amount２８０が自動的に算出される。次に、顧客は、通貨を買ったり、売ったりするときに望むRate２７８を入力する。顧客の提出した他の明細のいくつかは、Expiry City２８２（タイムゾーン決定の目的で顧客が居るタイムゾーン）、Expiry Date２８４（オーダーが期限満了となる日）、およびExpiry Time２８６（オーダーが期限満了となる時刻）である。
【００５４】
情報のすべてが入力されたならば、顧客は、「Execute」２９０をヒットする。これは、システムに入力されたデータのすべてが有効であるかどうかをチェックするのを促し、入力されたレート２７８を使用して通貨の対の組み合わせについての通貨総額（２７６または２８０のいずれか）を計算し、また、タイムゾーン差を考慮に入れながらオーダーの満了日を算出する。そして、計算された値が、対応するフィールドに表示される。顧客は算出数値を見た後で、Amend２９２をヒットして、入力したデータを訂正することが選択できる。顧客がオーダーに満足した場合には、Confirm２８６をヒットし、これによりオーダーをOrder Monitor（以下に説明する）に送る。Reset２９２をヒットすることで、すべてのフィールドをクリアし、デフォルト値に戻すようにする。しかし、このオプションは、オーダーが実行される前にのみ利用可能である。
【００５５】
顧客のオーダーがステップ１６３においてOrder Monitorに送られたとき、トレーダは、企業体のトレーダのＰＣ上で稼働しているＢ２Ｃデスクトップ・アプリケーションを介して、オーダーを見ることができる。このアプリケーションを使用して、Ｂ２Ｃデスクトップ・アプリケーションにアクセスするのに必要なログインＩＤおよびパスワードがトレーダに適切に割り当てられているならば、トレーダは、種々の機能、たとえば、顧客のオーダーを見たり、オーダーを実行したり、オーダーを取消したり或いは譲渡したりする、といった機能を実施することができる。
【００５６】
確認された顧客のオーダーは、Order Monitorディスプレイに表示される。図１２は、まだ実行されていない、または、部分的に実行されたオーダーである未決オーダー３０２のリストを示すOrder Monitorディスプレイ３００を示している。各オーダーに対して、Order Monitor３００は、下記を表示する（括弧内は対応する部分の参照符号）。
2004522223.tif 000004
【００５７】
オーダーを初めて受け取ったとき、トレーダは、まず、オーダーをハイライトしてから、「Accept」ボタン３０４を押して、トレーダがオーダーをいま受け入れていることを示して、オーダーを「Accept」しなければならない。しかしながら、トレーダがオーダーを受け入れたくない場合には、オーダーをハイライトし、「Assign」ボタン３０８を押すことによって、オーダーを「assign」することができる。さらに、オーダーは、また、オーダーをハイライトし、「cancel」ボタンを押すことによって取消される。「collateral」ボタンを押せば、トレーダは、顧客の担保情報を見ることができる。
【００５８】
トレーダがステップ１６４（図７）において行わなければならない重大な決定は、オーダーをＢ２Ｂシステムに「転送」するか、「組織内で」オーダーを実行する、すなわち、企業体によってオーダーを実行するかどうかである。ステップ１６６でオーダーを実行するために、トレーダは、オーダーをハイライトし、「Execute」ボタン３０６を押す。この時点で、図１３のExecute Orderインタフェース３３０が現れる。ハイライトされたオーダーの関連した明細のすべては、Order Information３３１のExecute Orderインタフェース３３０の関連したフィールドにインポートされる。特に、インポートされた情報は、以下の通りである。すなわち、Order ID３３２、User ID３３４、Buy／Sell３３６、Order Type３３８、Ccy Pair３４０、Target Rate３４２、Ccy 1 Amount３４４である。Balance To Execute３４８は、Ccy 1 Amount３４４からExecuted Amount３４６を減算することによって算出される。
【００５９】
所与のOrder Information３３１に基づいて、トレーダは、Dealt Rate３５０およびAmount３５２を入力する。トレーダは、Balance to Execute３４８へ金額を入力するのを選択するか、或いは、Balance to Execute３４８より少ない金額を入力してオーダーを部分的にのみ実行することを選択する。トレーダは、「Execute」ボタン３５４を押してオーダーを実行し、これで、フィールド内のデータすべてをフリーズする。これは、「Amend」ボタン３５６を押すことによってのみ訂正され得る。すべての確認が終わったならば、トレーダは、「Confirm」ボタン３５８を押す。オーダーが適切に実現されたならば、企業体は、ステップ１７４において、顧客との取引を決済する。
【００６０】
ステップ１６４において、トレーダがオーダーをＢ２Ｂシステムへ転送することを決定した場合、トレーダは、Order Monitor３００上のオーダーをハイライトし、「転送」ボタン３１１を押す。次に、選択されたオーダーは、図８のＢ２Ｂディーリングルーム２００に送られ、そのオーダーの明細が、トレーダが同じインタフェース２００を使用してデータを入力する方法と同様な方法で、適切なフィールドに入力される。次いで、オーダーが通常のＢ２Ｂ取引プロセスで実行され、この場合、基本的には、顧客のオーダーは企業体によって「白ラベル」を付けられている。換言すれば、Ｂ２Ｂシステムを使用している他の企業体は、そのオーダーが企業体の顧客から発注されたものであることに気がつかないのである。取引がステップ１７０において実行されたならば、取引が、まず、Ｂ２Ｂステージで決済され、次いで、企業体の顧客に対してＢ２Ｂステージで決済される。
【実施例２】
【００６１】
図１４は、本発明の別の実施例を示しており、ここでは、企業体は、基本的には中央サーバ・システム２０（図２）の役割を果し、その顧客３８２が、上述したＢ２Ｂシステムと実質的に類似の方法で、互いに通貨を売買することができるにする。このタイプの取引は、顧客-対-顧客すなわちＣ２Ｃ取引と呼ばれる。図１４の実施例は、企業体システム３７０を含み、これは、インターネット・ブラウザ３８４を有する企業体の顧客のＰＣ３８２によってインターネットを介してアクセスすることができる。企業体のシステム３７０は、ウェブサーバ・エンジン３７４、企業体のレガシー・システム３７６、データベース兼アプリケーション・マネージャ３７８、ウェブ・ページ３８０を含む。
【００６２】
図１５は、データベース兼アプリケーション・マネージャ３７８を詳細に示している。ユーザ・マネージャ３９０は、企業体のシステム３７０と、このシステム３７０にアクセスしている企業体の顧客３８２との間のインタフェース接続を容易にする。ユーザ明細、たとえば、ユーザ名やアドレス等々は、ユーザ・アカウント・データベース３９４に格納される。他方、ユーザ・プロフィール・データベース３９２は、ユーザ情報、たとえば、ユーザＩＤ、パスワード、担保（タイプおよび額）その他を格納する。
【００６３】
担保データベース３９８は、担保の詳細を格納する。たとえば、データベース３９８は、各顧客によって設定された担保のタイプと総額、および顧客によって実行された取引の損益を評価した後に残っている担保の総額を格納する。顧客が取引を実行するにつれて、担保情報は定期的に更新される。
【００６４】
マージン・レート・データベース４００は、主要な３タイプのマージン・レート情報を含んでいる。第１のタイプは、銀行のような企業体が通貨の対の組み合わせの各取引について請求するコミッションであるスプレッド・マージンである。第２のタイプは、企業体に対して顧客によって設定された担保総額に基づいて顧客が売買できる最大総額を算出するのに使用されるイニシャル・マージンである。第３のタイプは、顧客が担保を上乗せする必要に迫られる前の、取引における損失分で使用された担保のパーセンテージであるメインテナンス・マージンである。担保およびマージン・レート情報の管理は、担保マネージャ３９６によって取り扱われる。
【００６５】
オーダー・マネージャ４０８は、オーダーの入力や取り消しのようなオーダー管理を取り扱う。設定されたが、実行されていない（すなわち、まだ売買されていない）オーダーは、未決オーダー・データベース４０２に格納される。実行されたオーダーは、実行済みオーダー・データベース４０４に格納される。決済マネージャ４１０は、決済情報、たとえば、決済方法および決済アカウント情報の取り扱いを管理し、決済データベース４０６に情報を格納する。
【００６６】
通貨マネージャ４１４は、特に、通貨の対の組み合わせの管理を取り扱う。その明細は、通貨の対の組み合わせ・データベース４１２に格納される。これらの明細としては、許可された通貨の対の組み合わせのリスト、たとえば、US$／Yen、通貨乗数および最小／最大取引範囲のリストのような情報を含むことができる。休日マネージャは、休日、オフアワーの追跡を続け、すべての関連情報を休日／オフアワー・データベース４１６に格納する。ニュースフィード・マネージャ４２２は、種々のソースからのニュースフィードを受け取り、ニュースフィード・データベース４２０に関連情報を格納し、ウェブ・ページの１つにそのニュースを表示する。レート・マネージャ４２６は、主として、公共ソースから得られる種々の通貨の対の組み合わせの表示為替レートを表示する役割を果たす。表示レートは、表示レート・データベース４２４に格納される。ニュース・マネージャ４３０は、本発明のシステムに関するニュースの表示を取り扱い、ニュース・データベース４２８が、そのニュース情報を格納する。
【００６７】
図１６は、顧客-対-顧客すなわちＣ２Ｃ取引に対する全体的なプロセスの流れを示している。ステップ４５０において、ｆｏｒｅｘ取引を行ないたい思っている顧客は、まず最初に企業体に対して登録し、ログインＩＤおよびパスワードを獲得する。ステップ４５２において、顧客は、ウェブ・ページ３８０を介して企業体のシステムにログインし、オンラインで取引を行う。ステップ４５４において、実行された取引が決済される。
【００６８】
ステップ４５０において実施された顧客の登録は、オンラインでもオフラインでも行われ得るが、セキュリティを確保するためにオフラインで実施するのが一般的に好ましい。登録プロセスは、基本的に、名前、アドレス等々といった顧客の明細を獲得することを伴う。登録プロセスは、また、必要な金融情報を獲得し、顧客の信用分析を行うことによって顧客の信用価値を決定することも伴う。顧客は、また、企業体に対して担保を設定する必要がある。担保は、一般的には現金であるが、他の金融商品でもよいし、物品であってもよい。たとえば、担保は、株、債券、或いはまた不動産であってもよい。顧客によって設定された担保の総額と、企業体によって顧客について実施された信用分析とに基づいて、企業体は、顧客が売買できる最大総額を算出するのに使用されるイニシアル・マージン・レートを決定する。好ましい実施例において、最大総額は、以下の式を使って算出される。
2004522223.tif 000005
【００６９】
したがって、例えば、１０，０００米国ドルの担保総額に対して２０％のイニシアル・マージン・レートであるならば、最大総額は、５０，０００米国ドルで取引されるようにセットされる。ユーザの要求次第で上記の式については数多くの変形が可能であり、したがって、上記の式がほんの一例であることは了解されたい。
【００７０】
また、企業体は、顧客に担保を「つぎ足す」ように警告が与えられる前に、取引の損失を相殺した後に残っている担保総額のパーセンテージであるメインテナンス・マージン・レートをセットする。たとえば、１０，０００米国ドルの担保が顧客によって設定された上記例を用いれば、５％のメインテナンス・マージン・レートは、全損が４５，０００米国ドルに達したときに警告が与えられる、ということを意味する。すべての情報が知らされて、適切な財務分析が行われたならば、顧客は、オーダー開始を行うのに必要なログインＩＤおよびパスワードを割り当てられる。
【００７１】
適正なログインＩＤおよびパスワードを獲得したならば、顧客は、図１８に示すディーリングルーム・ウェブ・インタフェース６００を使用して通貨をオンラインで売買することができるようになる。ステップ４５２において本発明のシステムを用いて顧客がどのように通貨の取引を行うかの詳細を、図１７，図１７Ａ，図１８に示すフローチャートを参照しながら、以下に説明する。まず、図１７を参照すると、ステップ４７０において、顧客は、図１８に示すウェブ・インタフェース６００によって表わされるようなディーリングルームにアクセスする。次いで、ステップ４７２において、ドロップダウン・メニュー６１０から、顧客は通貨の対の組み合わせを選択する。インタフェース６００は、２通りまでの通貨の対の組み合わせ、ここでは、日本円に対する米国ドル（ＵＳＤ／ＪＰＹ）６０２と、米国ドルに対するヨーロッパのユーロ（ＥＵＲ／ＵＳＤ）６０４を示すことができることを承知されたい。しかしながら、取引プロセスを説明するという目的であるから、同じステップがすべての通貨の対の組み合わせにあてはまるので、以下、ＵＳＤ／ＪＰＹのみを説明例として用いることとする。
【００７２】
ステップ４７４において、システムは、各通貨の対の組み合わせに対し３つの最良レートを表示する。提示されたレートは、現在ディーリングルーム・インタフェース６００を使用しているすべての顧客からのものである。ここでは、ＵＳＤ／ＪＰＹに対する３つの最良レートが、ディスプレイ・ボード６０６にリストで示されている。大きいボックス６０８には、為替レートの下２桁が太字で示されており、残りの桁は、小さいボックス６１０に示されていることを承知されたい。左側のレート６１２は、米国ドルが買いを提示されているレートを示しており、したがって、米国ドルにとって最も好ましいレートが、ディスプレイ・ボード６０６に注目している顧客の視点から「最良」レートとみなされることになる。顧客の視点からの最良レートは、リストの最初に示される。右側のレート６１４は、米国ドルが売り提示されているレートを示しており、したがって、米国ドルにとって最も好ましくないレートが、顧客の視点からは「最良」レートであるとみなされ、リストの最初に示されることになる。小さいボックス６１０の直ぐ下にある数字６１６は、乗数なしで示されるレートで提示されている通貨の単位数を示している。乗数係数６２８が、インタフェースの左側に示されている。ここでは、乗数は１０００であるが、他の乗数（たとえば、１０，０００）も可能であることは明らかである。したがって、ここでは、数字「５５」は、５５×１０００、すなわち、５５，０００米国ドルを示している。ここで、総額５５が、単一の顧客によって設定される必要はない、ということに留意されたい。いくつかの顧客が同じレートでオーダーを設定する場合、総額は合算される。それ故、総額５５は、単一の顧客から来たものであるかも知れないし、または、複数の顧客によって設定されたいくつかのオーダーの合算であるかも知れない。しかしながら、インタフェース６００は、提示された総額が単一の顧客から来たものであるか、複数の提示の合算であるかは表示しない。
【００７３】
ステップ４７６において、顧客は、「Ｔｙｐｅ」６１７で、「Ｂｉｄ」６１８か「Ａｓｋ」６２０かのどちらかを選択する。「Ｂｉｄ」を選択した場合、それは、顧客が日本円に対して米国ドルを買いたいと思っていることを示し、「Ａｓｋ」を選択した場合、それは、顧客が日本円に対して米国ドルを売りたいと思っていることを示す。この場合では、説明の目的だけ、「Ａｓｋ」が選択され、顧客が日本円に対して米国ドルを買いたいと思っているものと仮定する。ステップ４７８において、顧客は、総額フィールド６２２に、顧客が売ったり、買ったりしたいと思っている総額を入力する。ここで、乗数６２３が１０００であるから、たとえば、１０を入力した場合、１０，０００単位の通過（ここでは、米国ドル）に相当する点に留意されたい。
【００７４】
ステップ４８０で、顧客は、ディスプレイ・ボード６０６上に掲示された「最良」レートで買うか、売るかを決める。ＹＥＳの場合、顧客は、ステップ４８２において「Hit at Market Rate」６２６を選び、システムは、自動的に、顧客が、ディスプレイ・ボード６０６に表示されている最良レートで取引したいものと想定する。顧客が「Ｂｉｄ」を選択した場合、「最良」レートは、ディスプレイ・ボード６０６の右側（「Ａｓｋ」または「ｓｅｌｌ」側）のリストにある最初のレートとなる。しかし、顧客が「Ａｓｋ」を選んだ場合には、「最良レート」は、ディスプレイ・ボード６０６の左側（「Ｂｉｄ」または「ｂｕｙ」側）のリストの最初のレートとなる。次に、総額フィールド６２２に入力された総額が、ステップ４８４において最良レートについて示された総額６１６から差し引かれる。ここでは、「Ｔｙｐｅ」で「Ａｓｋ」が選択されたので、入力された総額「１０」が、総額「５５」６１６から差し引かれることになる。総額５５がいくつかの顧客によって設定されたオーダーの合算である場合、総額１０が、最初に設定された「Ｂｉｄ」オーダーから最初に差し引かれることになる。したがって、たとえば、顧客Ａが最初に８単位のオーダーを設定し、顧客Ｂが二番目に４７ユニットのオーダー（それ故、合計５５）を設定した場合、入力された総額１０のうちの８が、最初に、顧客Ａの８のオーダーから差し引かれ、次に、残っている２単位が、顧客Ｂの４７のオーダーから差し引かれる。この差し引き操作の後に残っている総額（４５）が、ここで、表示されることになる。入力された総額がディスプレイ・ボードで利用できる金額よりも大きい場合には、利用できる総額のすべてが、提示額から差し引かれ、残りの総額が掲示される。ひとたび差し引き操作がなされたならば、取引は、「done deal」とみなされ、システムは、その取引を「Deal Done」セクション６２６に表示する。このセクションは、現在の顧客に実施された取引を示しているだけで、システムを使用して実施されたすべての取引をリストしているわけではないことは承知されたい。
【００７５】
さて今度は図１７Ａについて説明する。図１７のステップ４８０において顧客が最良レートを採用しないと決定した場合、顧客は、ステップ４８８においてレート・フィールド６２４に所望のレートを入力することになる。ステップ４９０において、システムは、そのレートを提示されたレートに対して一致させようとする。この場合、入力レートは１１６．７０であり、取引は「Ａｓｋ」（「ｓｅｌｌ」）である。したがって、システムは、ディスプレイ・ボード６０６の「Ｂｉｄ」側６１２上の提示額に注目し、顧客によって入力されたレートと一致するか、または、それよりも良いｂｉｄレートを提示した買い手がいるかどうかを調べる。顧客の入力したレートで米国ドルを買う気のある買い手がまったくいないので、ステップ４９２における質問に対する回答は、「ノー」である。システムは、ステップ４９４に移動する。一方、ステップ４９２において一致があるとシステムが決定した場合には、システムは、ステップ５０４において、入力総額を、入力レートと一致するか或いはそれを凌駕する提示レートから差し引き、ステップ５０６において、「Deal Done」セクション６２６に取引を表示する。
【００７６】
ステップ４９４において、入力されたオーダーは、他のオーダーの間で待ち行列に入れられる。入力されたオーダーが３つの最良レート内にある場合には、それは、ステップ４９６においてディスプレイ・ボード６０６上に提示される。次いで、システムは、ステップ４９８において、システムを使用している顧客または他の企業体によって一致するオーダーが設定されるのを待つ。一致オーダーが得られた場合には、システムは、ステップ５００において提示された総額から差し引き、ステップ５０２においてこの取引を表示する。
【００７７】
ステップ４５４の決済プロセスは、管理者によって定められた方法に従ってシステムによって実施される。好ましい実施例において、決済プロセスは、既存の決済プロセスをオフラインで使用して企業体によって実施される。
【００７８】
本発明は、その精神またはその本質的な特徴から逸脱することなく、他のいろいろな形で実施され得る。したがって、ここに開示した実施例は、あらゆる点で例示的なものであって、限定的ではないと解釈されるべきであり、発明の範囲は、添付の特許請求の範囲に示されているものであり、したがって、特許請求の範囲と同等の意味、範囲内にあるあらゆる変更が含まれる。
【図面の簡単な説明】
【００７９】
【図１】本発明の全般的な概念を示す象徴的な説明図である。
【図２】本発明のシステムの物理的アーキテクチャを示している。
【図３】中央サーバ・システムのデータベース兼アプリケーション・マネージャを詳細に示している。
【図４】Ｂ２Ｃエンジンの構成要素を示している。
【図５】企業体が本発明のシステムを使用してＢ２Ｂ取引を行う全プロセスを示すフローチャートである。
【図６】トレーダが本発明のシステムを使用して取引を行う（図５のステップ１０８）プロセスの流れを示すフローチャートである。
【図６Ａ】トレーダが本発明のシステムを使用して取引を行う（図５のステップ１０８）プロセスの流れを示すフローチャートである。
【図７】顧客が本発明のシステムを使用してＢ２Ｃ取引を行なう全プロセスの流れを示すフローチャートである。
【図８】トレーダが外国為替取引を行なうディーリングルームを表わしているウェブ・インタフェースである。
【図９】信用グループが形成され、信用限度が割り当てられる場合のウェブ・インタフェースである。
【図１０】企業体が信用グループへ設定評価される場合のウェブ・インタフェースである。
【図１１】顧客が外国為替オーダーを設定する場合のウェブ・インタフェースである。
【図１２】トレーダが顧客によって設定されたオーダーのリストを見ることができる場合のウェブ・インタフェースである。
【図１３】トレーダが「組織内で」（イン・ハウス）顧客のオーダーを実行できる場合のウェブ・インタフェースである。
【図１４】本発明の他の実施例の物理的アーキテクチャを示している。
【図１５】図１４の企業体システムのデータベース兼アプリケーション・マネージャを示している。
【図１６】Ｃ２Ｃ取引を行う全プロセスの流れを示すフローチャートである。
【図１７】顧客が図１４に示されるシステムを使用して取引を行うプロセスの流れを示すフローチャートである。
【図１７Ａ】顧客が図１４に示されるシステムを使用して取引を行うプロセスの流れを示すフローチャートである。
【図１８】顧客が外国為替取引を行うディーリングルームを表わしているウェブ・インタフェースである。
【図１】
2004522223.tif 000006
【図２】
2004522223.tif 000007
【図３】
2004522223.tif 000008
【図４】
2004522223.tif 000009
【図５】
2004522223.tif 000010
【図６】
2004522223.tif 000011
【図６Ａ】
2004522223.tif 000012
【図７】
2004522223.tif 000013
【図８】
2004522223.tif 000014
【図９】
2004522223.tif 000015
【図１０】
2004522223.tif 000016
【図１１】
2004522223.tif 000017
【図１２】
2004522223.tif 000018
【図１３】
2004522223.tif 000019
【図１４】
2004522223.tif 000020
【図１５】
2004522223.tif 000021
【図１６】
2004522223.tif 000022
【図１７】
2004522223.tif 000023
【図１７Ａ】
2004522223.tif 000024
【図１８】
2004522223.tif 000025
【国際公開パンフレット】
2004522223.tif 000026
2004522223.tif 000027
2004522223.tif 000028
2004522223.tif 000029
2004522223.tif 000030
2004522223.tif 000031
2004522223.tif 000032
2004522223.tif 000033
2004522223.tif 000034
2004522223.tif 000035
2004522223.tif 000036
2004522223.tif 000037
2004522223.tif 000038
2004522223.tif 000039
2004522223.tif 000040
2004522223.tif 000041
2004522223.tif 000042
2004522223.tif 000043
2004522223.tif 000044
2004522223.tif 000045
2004522223.tif 000046
2004522223.tif 000047
2004522223.tif 000048
2004522223.tif 000049
2004522223.tif 000050
2004522223.tif 000051
2004522223.tif 000052
2004522223.tif 000053
2004522223.tif 000054
2004522223.tif 000055
2004522223.tif 000056
2004522223.tif 000057
2004522223.tif 000058
2004522223.tif 000059
2004522223.tif 000060
2004522223.tif 000061
2004522223.tif 000062
2004522223.tif 000063
2004522223.tif 000064
2004522223.tif 000065
2004522223.tif 000066
2004522223.tif 000067
2004522223.tif 000068
2004522223.tif 000069
2004522223.tif 000070
2004522223.tif 000071
2004522223.tif 000072
2004522223.tif 000073
2004522223.tif 000074
2004522223.tif 000075
2004522223.tif 000076
2004522223.tif 000077
2004522223.tif 000078
2004522223.tif 000079
2004522223.tif 000080
2004522223.tif 000081
2004522223.tif 000082
2004522223.tif 000083
2004522223.tif 000084
2004522223.tif 000085
2004522223.tif 000086
2004522223.tif 000087
2004522223.tif 000088
2004522223.tif 000089
2004522223.tif 000090
2004522223.tif 000091
【国際調査報告】
2004522223.tif 000092
2004522223.tif 000093
2004522223.tif 000094