以下、図面を参照しながら、本発明の実施の形態を銀行システムへの適用を例にとり説明する。ただし、本発明が銀行システムへの適用に限定されるわけではない。本発明は、マルチデバイスに対応した任意のシステムに適用することが可能である。
1.銀行システムの構成
図1は、マルチデバイスに対応した銀行システム1の構成の一例を示す。図1に示される例では、銀行システム1は、マルチデバイスとしての端末101、端末102、・・・、端末10Nに対応する。ここで、Nは、2以上の任意の整数である。例えば、端末101は、スマートフォンであり、端末102は、タブレット型の端末であり、端末10Nは、パーソナルコンピュータ(PC)である。このように、銀行システム1は、様々なタイプの端末からの要求に応えることができるように構成されている。端末101、端末102、・・・、端末10Nには、それぞれ、端末のタイプに応じたブラウザ201、202、・・・、20Nが組み込まれている。これにより、端末101、端末102、・・・、端末10Nのそれぞれは、Webブラウザとして機能することが可能である。
銀行システム1は、預金者の口座情報を維持するための口座情報データベース30と、口座情報データベース30に接続された勘定系システム40と、勘定系システム40のフロントエンドとして機能するフロントシステム50とを含む。
勘定系システム40は、銀行の基幹システムであり、入出金の管理など勘定系のすべての銀行サービスを実行する。例えば、勘定系システム40は、預金の残高照会、円預金、外貨預金、振込、FX(店頭外国為替証拠金取引)などの銀行サービスを実行する。
フロントシステム50は、インターネット60を介して、端末101、端末102、・・・端末10Nのうちの少なくとも1つに接続されるように構成されている。
フロントシステム50は、ブラウザ共通インターフェース部51と、勘定系システムインターフェース部52と、プロセッサ部53と、メモリ部54とを含む。
ブラウザ共通インターフェース部51は、ブラウザ201、202、・・・、20Nのうちの少なくとも1つとの通信を制御する。
勘定系システムインターフェース部52は、勘定系システム40との通信を制御する。
プロセッサ部53は、フロントシステム50の全体の動作を制御する。
メモリ部54には、少なくとも1つのスタイルシート55が格納されている。少なくとも1つのスタイルシート55は、例えば、複数のスタイルシート5511、5512、・・・551i、5521、5522、・・・552j、・・・、55N1、55N2、・・・55Nkである。ここで、i、j、kは、1以上の整数である。スタイルシート5511、5512、・・・551iは、端末101に対して用いられるi個のスタイルシートを示す。スタイルシート5521、5522、・・・552jは、端末102に対して用いられるj個のスタイルシートを示す。スタイルシート55N1、55N2、・・・55Nkは、端末10Nに対して用いられるk個のスタイルシートを示す。各スタイルシートは、コンテンツの表示形式を定義する。 原則として、1つのスタイルシートは、端末に表示される1つの画面(1つのウェブページ)を単位として定義される。各コンテンツは、例えば、HTMLやXHTMLなどのマークアップ言語で記述される。各スタイルシートは、例えば、CSSやXSLなどのスタイルシート言語で記述される。各スタイルシートは、銀行サービスが実行される前にメモリ部54に予め格納されていてもよいし、銀行サービスの実行時に動的に生成され、メモリ部54に格納されてもよい。
なお、図1に示されるプロセッサ部53、メモリ部54などのそれぞれの構成要素は、単一のハードウェア部品で構成されてもよいし、複数のハードウェア部品で構成されてもよい。本発明は、特定のハードウェア構成には限定されない。
また、図1に示される実施の形態では、銀行システム1と端末101、端末102、・・・端末10Nとは、インターネット60を介して接続されるとしたが、本発明はこれに限定されない。インターネット60の代わりに任意のタイプのネットワークを用いる場合でも、本発明を適用することが可能である。
2.銀行システムの処理
図2は、銀行システム1の処理フローの概略を示す。以下、各ステップごとに説明する。
ステップS21:要求端末は、要求(例えば、預金の残高照会)をインターネット60を介してフロントシステム50に送信する。ここで、要求端末とは、端末102、・・・、端末10Nのうちの1つの端末であって、要求を送信した端末をいう。
ステップS22:フロントシステム50は、「要求端末のタイプを示す情報」と「要求端末の画面サイズを示す情報」とを取得する。なお、本発明では、フロントシステム50が「要求端末のタイプを示す情報」と「要求端末の画面サイズを示す情報」とをどのようにして取得するかは問わない。フロントシステム50が「要求端末のタイプを示す情報」と「要求端末の画面サイズを示す情報」とを取得する限り、フロントシステムが50がどのような方法でこれらの情報を取得した場合も本発明の範囲内である。
ステップS23:フロントシステム50は、メモリ部54に格納されている少なくとも1つのスタイルシート55のうち、ステップS22において取得された「要求端末のタイプを示す情報」と「要求端末の画面サイズを示す情報」とに対応するスタイルシートを選択する。
ステップS24:フロントシステム50は、要求端末から受信された要求を勘定系システム40に送信する。ただし、要求端末から受信された要求のフロントシステム50から勘定系システム40への送信は、フロントシステム50と勘定系システム40との間の所定のプロトコルに従って行われる。従って、要求端末から受信された要求は、フロントシステム50(すなわち、フロントシステム50の勘定系システムインターフェース部52)において必要に応じて所定のデータ形式に変換され、所定の手順に従って勘定系システム40に送信される。
なお、ステップS24は、ステップS23よりも後に実行されなければならないことはない。ステップS24は、ステップS21よりも後の任意のタイミングで実行され得る。
ステップS25:勘定系システム40は、フロントシステム50から受信された要求(例えば、預金の残高照会)に対する処理を実行する。
ステップS26:勘定系システム40は、フロントシステム50から受信された要求(例えば、預金の残高照会)に対する処理の結果を表す、その要求に対する応答をフロントシステム50に送信する。フロントシステム50は、勘定系システム40からその応答を受信する。ただし、その応答の勘定系システム40からフロントシステム50への送信は、フロントシステム50と勘定系システム40との間の所定のプロトコルに従って行われる。従って、その応答は、所定の手順に従ってフロントシステム50によって受信され、フロントシステム50(すなわち、フロントシステム50の勘定系システムインターフェース部52)において必要に応じて所定のデータ形式に変換される。
ステップS27:フロントシステム50は、勘定系システム40から受信された応答に対応するコンテンツを生成する。ここで、フロントシステム50によって生成されるコンテンツは、マルチデバイスに共通のコンテンツである。例えば、「預金の残高照会」という要求に対して、勘定系システム40から受信された応答が「¥10,000」であったとする。この場合、フロントシステム50は、預金の残高が「¥10,000」であることを示す画面(ウェブページ)を要求端末のディスプレイに表示するためのコンテンツ(例えば、HTMLコンテンツ)を生成する。ここで、フロントシステム50がどのようなタイプの要求端末から(および/または、どのような画面サイズの要求端末から)「預金の残高照会」という要求を受信した場合でも、預金の残高が「¥10,000」であるという事実に変わりはない。従って、フロントシステム50は、フロントシステム50がどのようなタイプの要求端末から(および/または、どのような画面サイズの要求端末から)「預金の残高照会」という要求を受信したかにかかわらず、預金の残高が「¥10,000」であるという勘定系システム40からの応答に対して、マルチデバイスに共通のコンテンツ(例えば、HTLMコンテンツ)を生成する。
ステップS28:フロントシステム50は、ステップS23において選択されたスタイルシートとステップS27において生成されたマルチデバイスに共通のコンテンツ(例えば、HTMLコンテンツ)とをインターネット60を介して要求端末に送信する。
ステップS29:要求端末は、フロントシステム50からインターネット60を介してステップS23において選択されたスタイルシートとステップS27において生成されたマルチデバイスに共通のコンテンツ(例えば、HTMLコンテンツ)とを受信し、受信されたスタイルシートに従って、受信されたコンテンツ(例えば、HTMLコンテンツ)を要求端末のディスプレイに表示する。
このように、図2に示される銀行システム1の処理フローによれば、要求端末は、「要求端末のタイプを示す情報」と「要求端末の画面サイズを示す情報」とに応じて選択されたスタイルシートに従って、コンテンツを要求端末のディスプレイに表示する。表示されるコンテンツは、「要求端末のタイプを示す情報」と「要求端末の画面サイズを示す情報」にかかわらず、マルチデバイスに共通のコンテンツであるが、このコンテンツを「要求端末のタイプを示す情報」と「要求端末の画面サイズを示す情報」とに応じて選択されたスタイルシートに従って表示することによって、マルチデバイスに共通のコンテンツを要求端末のタイプおよび画面サイズに適切な表示形式で要求端末のディスプレイに表示することが可能である。
なお、顧客の携帯電話番号と口座番号とが一対一に対応付けられている銀行システムにおいて、顧客は、携帯電話番号を口座番号の代わりに用いる銀行サービスを利用することができる。例えば、顧客同士が銀行に口座を有している場合には、振込人が受取人の携帯電話番号および氏名のみを指定して振込を行う振込サービス(いわゆる「ケータイ番号振込」サービス)を利用することができる。
要求端末が電話機能を有する携帯端末である場合(例えば、要求端末が携帯電話やスマートフォンである場合)には、勘定系システム40によって実行される処理は、要求端末の携帯電話番号を口座番号の代わりに用いる銀行サービスのための処理であってもよい。そのような銀行サービスとしては、例えば、受取人の携帯電話番号および氏名のみを指定して振込を行う振込サービス(いわゆる「ケータイ番号振込」サービス)が挙げられる。
3.フロントシステムの処理
図3は、フロントシステム50(すなわち、フロントシステム50のプロセッサ部53)によって実行される処理の手順の一例を示す。この処理は、例えば、プログラムの形式でメモリ部54に格納されている。メモリ部54に格納されているプログラムは、例えば、Webサーバプログラムである。プロセッサ部53は、メモリ部54に格納されているWebサーバプログラムを読み出し、そのWebサーバプログラムを実行する。これにより、フロントシステム50は、Webサーバとして機能することが可能になる。
以下、図3に示される処理を各ステップごとに説明する。
ステップS31:フロントシステム50は、要求端末からの要求(例えば、預金の残高照会)をインターネット60を介して受信する。このステップは、図2のステップ21に対応するステップである。
ステップS32:フロントシステム50は、「要求端末のタイプを示す情報」と「要求端末の画面サイズを示す情報」とを取得する。このステップは、図2のステップS22に対応するステップである。
ステップS33:フロントシステム50は、ステップS32において取得された「要求端末のタイプを示す情報」と「要求端末の画面サイズを示す情報」とに少なくとも基づいて、メモリ部54に格納されている少なくとも1つのスタイルシート55のうちのスタイルシートを選択する。このステップは、図2のステップS23に対応するステップである。
ステップS34:フロントシステム50は、要求端末から受信された要求を勘定系システム40に送信する。このステップは、図2のステップS24に対応するステップである。従って、ステップS34は、ステップS33よりも後に実行されなければならないことはない。ステップS34は、ステップS31よりも後の任意のタイミングで実行され得る。
ステップS35:フロントシステム50は、勘定系システム40に送信された要求(例えば、預金の残高照会)に対する勘定系システム40の処理の結果を表す、その要求に対する応答を勘定系システム40から受信する。このステップは、図2のステップS26に対応するステップである。
ステップS36:フロントシステム50は、勘定系システム40から受信された応答に対応するコンテンツを生成する。ここで、フロントシステム50によって生成されるコンテンツは、マルチデバイスに共通のコンテンツである。このステップは、図2のステップS27に対応するステップである。
ステップS37:フロントシステム50は、ステップS33において選択されたスタイルシートとステップS36において生成されたマルチデバイスに共通のコンテンツ(例えば、HTMLコンテンツ)とをインターネット60を介して要求端末に送信する。このステップは、図2のステップS28に対応するステップである。あるいは、ステップS37において、フロントシステム50は、ステップS33において選択されたスタイルシートとステップS36において生成されたマルチデバイスに共通のコンテンツ(例えば、HTMLコンテンツ)とに基づいてコンテンツを合成し、その合成されたコンテンツを要求端末に送信するようにしてもよい。このように合成されたコンテンツは、例えば、HTMLコンテンツである。いずれの場合でも、スタイルシートとマルチデバイスに共通のコンテンツとに基づく情報が、要求端末に送信されることになる。スタイルシートとマルチデバイスに共通のコンテンツとに基づく情報は、スタイルシートそのものとマルチデバイスに共通のコンテンツそのものであってもよいし、スタイルシートとマルチデバイスに共通のコンテンツとに基づいて合成されたコンテンツであってもよい。スタイルシートとマルチデバイスに共通のコンテンツとに基づく情報は、スタイルシートとマルチデバイスに共通のコンテンツとに基づく限り、任意の情報であり得る。
このように、図3に示されるフロントシステム50によって実行される処理の手順によれば、要求端末は、フロントシステム50から、インターネット60を介して、スタイルシートとマルチデバイスに共通のコンテンツとに基づく情報を受信し、スタイルシートによって定義された表示形式に従って、コンテンツ(例えば、HTMLコンテンツ)を要求端末のディスプレイに表示する。表示されるコンテンツは、「要求端末のタイプを示す情報」と「要求端末の画面サイズを示す情報」にかかわらず、マルチデバイスに共通のコンテンツであるが、このコンテンツを「要求端末のタイプを示す情報」と「要求端末の画面サイズを示す情報」とに少なくとも基づいて選択されたスタイルシートによって定義された表示形式に従って表示することによって、マルチデバイスに共通のコンテンツを要求端末のタイプおよび画面サイズに適切な表示形式で要求端末のディスプレイに表示することが可能である。
なお、上述した実施形態では、ステップS34においてフロントシステム50が要求を勘定系システム40に送信し、ステップS35においてフロントシステム50がその要求に対する応答を勘定系システム40から受信する例を説明したが、本発明はこれに限定されない。例えば、フロントシステム50は、要求をフロントシステム50の外部にある勘定系システム40以外のシステムに送信し、その要求に対する応答をその外部のシステムから受信するようにしてもよい。この場合、フロントシステム50は、その外部のシステムから受信された応答に対応するコンテンツを生成する。
あるいは、フロントシステム50は、要求をフロントシステム50の外部にあるシステムに送信し、その外部のシステムから受信する代わりに、その要求をフロントシステム50の内部で処理することにより、その要求に対する応答をフロントシステム50の内部で生成するようにしてもよい。この場合、フロントシステム50は、フロントシステム50の内部で生成された応答に対応するコンテンツを生成する。
このように、フロントシステム50は、必ずしも、フロントシステム50の外部にあるシステムに対するフロントエンドとして機能する必要はない。この意味で、フロントシステム50は、マルチデバイスに対応したシステム(例えば、銀行システム1)において用いられる装置ということができる。
図4は、図3に示されるステップS32の処理の手順の一例を示す。この処理は、フロントシステム50(すなわち、フロントシステム50のプロセッサ部53)によって実行される。この処理は、例えば、プログラムの形式でメモリ部54に格納されている。メモリ部54に格納されているプログラムは、例えば、Webサーバプログラムである。
以下、図4に示される処理を各ステップごとに説明する。
ステップS41:要求端末のユーザ・エージェント情報が認識される。ここで、ユーザ・エージェント情報とは、ユーザのブラウザの種類やオペレーティングシステム(OS)などを示す情報である。
ステップS42:要求端末のタイプがスマートフォンであるか否かが判定される。このような判定は、ステップS41において認識された要求端末のユーザ・エージェント情報を用いて行われる。この判定が「Yes」の場合には、処理は、ステップS43に進み、この判定が「No」の場合には、処理は、ステップS45に進む。
ステップS43:要求端末のタイプがスマートフォンであると判定される。このことは、要求端末のタイプがスマートフォンであることを示す情報が「要求端末のタイプを示す情報」として取得されたことを意味する。
ステップS44:スマートフォン用のスクリプト(例えば、JavaScript(登録商標))が選択される。
ステップS45:要求端末のタイプがタブレット型の端末であるか否かが判定される。このような判定は、ステップS41において認識された要求端末のユーザ・エージェント情報を用いて行われる。この判定が「Yes」の場合には、処理は、ステップS46に進み、この判定が「No」の場合には、処理は、ステップS48に進む。
ステップS46:要求端末のタイプがタブレット型の端末であると判定される。このことは、要求端末のタイプがタブレット型の端末であることを示す情報が「要求端末のタイプを示す情報」として取得されたことを意味する。
ステップS47:タブレット型の端末用のスクリプト(例えば、JavaScript(登録商標))が選択される。
ステップS48:要求端末のタイプがパーソナルコンピュータ(PC)であると判定される。このことは、要求端末のタイプがパーソナルコンピュータ(PC)であることを示す情報が「要求端末のタイプを示す情報」として取得されたことを意味する。なお、図4に示される例では、要求端末のタイプが、スマートフォンではなく、かつ、タブレット型の端末でない場合には、すべて、要求端末のタイプがパーソナルコンピュータ(PC)であると判定される。このように要求端末のタイプを判定することにより、新たなタイプの要求端末が開発された場合でも、その要求端末のタイプがパーソナルコンピュータ(PC)であるとして処理を進めることが可能である。
ステップS49:パーソナルコンピュータ(PC)用のスクリプト(例えば、JavaScript(登録商標))が選択される。
ステップS50:選択されたスクリプトが、インターネット60を介して、要求端末に送信される。
要求端末は、フロントシステム50からインターネット60を介して選択されたスクリプトを受信し、受信された選択されたスクリプトを実行することによって、要求端末の画面サイズを示す情報を取得する。要求端末は、要求端末において取得された要求端末の画面サイズを示す情報をインターネット60を介してフロントシステム50に送信する。
ステップS51:要求端末から、インターネット60を介して、要求端末の画面サイズを示す情報が受信される。このようにして、「要求端末の画面サイズを示す情報」が取得される。
このように、図4に示される処理を実行することにより、「要求端末のタイプを示す情報」と「要求端末の画面サイズを示す情報」とが取得される。従って、図4に示される処理は、図3のステップS32の処理に相当する処理であるということができる。
図5は、図3に示されるステップS33の処理の手順の一例を示す。この処理は、フロントシステム50(すなわち、フロントシステム50のプロセッサ部53)によって実行される。この処理は、例えば、プログラムの形式でメモリ部54に格納されている。メモリ部54に格納されているプログラムは、例えば、Webサーバプログラムである。
図5に示される例では、要求端末のタイプは、「スマートフォン」、「タブレット型の端末」、「パーソナルコンピュータ(PC)」のいずれかであると仮定されている。また、「スマートフォン」には、いくつかの異なる画面サイズを有するタイプがあり、「ダブレット型の端末」にも、いくつかの異なる画面サイズを有するタイプがあるものと仮定されている。もちろん、本発明がこれらの仮定に限定されるわけではない。要求端末のタイプの場合分けが図5に示される例とは異なるように行われ、および/または、要求端末の画面サイズの場合分けが図5に示される例とは異なるように行われる場合でも、本発明を適用することが可能である。
以下、図5に示される処理を各ステップごとに説明する。
ステップS61:要求端末のタイプがスマートフォンであるか否かが判定される。このような判定は、例えば、図4に示されるステップS43、S46、S48において取得される「要求端末のタイプを示す情報」を用いて行われる。この判定が「Yes」の場合には、処理は、ステップS62に進み、この判定が「No」の場合には、処理は、ステップS69に進む。
ステップS62:要求端末の画面サイズ(画面の幅)が320ピクセルより小さいか否かが判定される。このような判定は、例えば、図4に示されるステップS51において取得される「要求端末の画面サイズを示す情報」を用いて行われる。この判定が「Yes」の場合には、処理は、ステップS63に進み、この判定が「No」の場合には、処理は、ステップS64に進む。
ステップS63:メモリ部54に格納されている少なくとも1つのスタイルシート55のうち、要求端末のタイプ=スマートフォン、かつ、要求端末の画面サイズ(画面の幅)=320ピクセルという条件に対応するスタイルシートが選択される。このスタイルシートは、要求端末のタイプ=スマートフォン、かつ、要求端末の画面サイズ(画面の幅)=320ピクセルという条件に適合するように予め設計されている。このスタイルシートが選択された後、処理は終了する。
ステップS64:要求端末の画面サイズ(画面の幅)が480ピクセルより小さいか否かが判定される。このような判定は、例えば、図4に示されるステップS51において取得される「要求端末の画面サイズを示す情報」を用いて行われる。この判定が「Yes」の場合には、処理は、ステップS65に進み、この判定が「No」の場合には、処理は、ステップS66に進む。
ステップS65:メモリ部54に格納されている少なくとも1つのスタイルシート55のうち、要求端末のタイプ=スマートフォン、かつ、要求端末の画面サイズ(画面の幅)=480ピクセルという条件に対応するスタイルシートが選択される。このスタイルシートは、要求端末のタイプ=スマートフォン、かつ、要求端末の画面サイズ(画面の幅)=480ピクセルという条件に適合するように予め設計されている。このスタイルシートが選択された後、処理は終了する。
ステップS66:要求端末の画面サイズ(画面の幅)が800ピクセルより小さいか否かが判定される。このような判定は、例えば、図4に示されるステップS51において取得される「要求端末の画面サイズを示す情報」を用いて行われる。この判定が「Yes」の場合には、処理は、ステップS67に進み、この判定が「No」の場合には、処理は、ステップS68に進む。
ステップS67:メモリ部54に格納されている少なくとも1つのスタイルシート55のうち、要求端末のタイプ=スマートフォン、かつ、要求端末の画面サイズ(画面の幅)=800ピクセルという条件に対応するスタイルシートが選択される。このスタイルシートは、要求端末のタイプ=スマートフォン、かつ、要求端末の画面サイズ(画面の幅)=800ピクセルという条件に適合するように予め設計されている。このスタイルシートが選択された後、処理は終了する。
ステップS68:メモリ部54に格納されている少なくとも1つのスタイルシート55のうち、要求端末のタイプ=スマートフォン、かつ、要求端末の画面サイズ(画面の幅)=1024ピクセルという条件に対応するスタイルシートが選択される。このスタイルシートは、要求端末のタイプ=スマートフォン、かつ、要求端末の画面サイズ(画面の幅)=1024ピクセルという条件に適合するように予め設計されている。このスタイルシートが選択された後、処理は終了する。
ステップS69:要求端末のタイプがタブレット型の端末であるか否かが判定される。このような判定は、例えば、図4に示されるステップS43、S46、S48において取得される「要求端末のタイプを示す情報」を用いて行われる。この判定が「Yes」の場合には、処理は、ステップS72に進み、この判定が「No」の場合には、処理は、ステップS79に進む。
ステップS72〜ステップS78:ステップS72〜ステップS78の内容は、上述したステップS62〜ステップS68の内容と同様である。従って、ここでは、詳しい説明を省略する。
ステップS79:要求端末のタイプがパーソナルコンピュータ(PC)であると判定される。なお、図5に示される例では、要求端末のタイプが、スマートフォンではなく、かつ、タブレット型の端末でない場合には、すべて、要求端末のタイプがパーソナルコンピュータ(PC)であると判定される。この場合には、メモリ部54に格納されている少なくとも1つのスタイルシート55のうち、要求端末のタイプ=パーソナルコンピュータ(PC)、かつ、要求端末の画面サイズ(画面の幅)=1024ピクセルという条件に対応するスタイルシートが選択される。このスタイルシートは、要求端末のタイプ=パーソナルコンピュータ(PC)、かつ、要求端末の画面サイズ(画面の幅)=1024ピクセルという条件に適合するように予め設計されている。このスタイルシートが選択された後、処理は終了する。
このように、マルチデバイスに共通のコンテンツを生成する処理とは切り離して、デバイスのタイプおよび/またはデバイスの画面サイズごとにそのデバイスのタイプおよび画面サイズに適合するように設計されたスタイルシートを用意することにより、マルチデバイスに対応したシステムの開発を行う場合でもデバイスごとに開発を行う必要がない。これにより、マルチデバイスに対応したシステムの開発を行う場合にそのシステムの開発期間を短縮し、開発コストを低減することができる。
図6は、フロントシステム50(すなわち、フロントシステム50のプロセッサ部53)によって実行される処理の手順の他の一例を示す。この処理は、図3に示される処理の変形例である。
以下、図6に示される処理を各ステップごとに説明する。
ステップS31’:フロントシステム50は、要求端末からの要求をインターネット60を介して受信する。
ステップS32’:フロントシステム50は、「要求端末の画面サイズを示す情報」を取得する。
ステップS33’:フロントシステム50は、ステップS32’において取得された「要求端末の画面サイズを示す情報」に少なくとも基づいて、メモリ部54に格納されている少なくとも1つのスタイルシート55のうちのスタイルシートを選択する。
ステップS37’:フロントシステム50は、ステップS33’において選択されたスタイルシートをインターネット60を介して要求端末に送信する。あるいは、ステップS37’において、フロントシステム50は、ステップS33’において選択されたスタイルシートとコンテンツ(例えば、HTMLコンテンツ)とに基づいてコンテンツを合成し、その合成されたコンテンツを要求端末に送信するようにしてもよい。このように合成されたコンテンツは、例えば、HTMLコンテンツである。いずれの場合でも、スタイルシートに基づく情報が、要求端末に送信されることになる。スタイルシートに基づく情報は、スタイルシートそのものであってもよいし、スタイルシートとコンテンツとに基づいて合成されたコンテンツであってもよい。スタイルシートに基づく情報は、スタイルシートに基づく限り、任意の情報であり得る。
このように、図6に示されるフロントシステム50によって実行される処理の手順によれば、要求端末は、フロントシステム50から、インターネット60を介して、スタイルシートに基づく情報を受信し、スタイルシートによって定義された表示形式に従って、コンテンツ(例えば、HTMLコンテンツ)を要求端末のディスプレイに表示する。これにより、コンテンツを要求端末の画面サイズに適切な表示形式で要求端末のディスプレイに表示することが可能である。
なお、図3に示される処理において、図3に示されるステップS32を図6に示されるステップS32’に置換し、かつ、図3に示されるステップS33を図6に示されるステップS33’に置換することも可能である。
図7は、図6に示されるステップS32’の処理の手順の一例を示す。この処理は、図4に示される処理の変形例である。
ステップS41’:要求端末のユーザ・エージェント情報が認識される。ここで、ユーザ・エージェント情報とは、ユーザのブラウザの種類やオペレーティングシステム(OS)などを示す情報である。
ステップS42’:要求端末のタイプがスマートフォンであるか否かが判定される。このような判定は、ステップS41’において認識された要求端末のユーザ・エージェント情報を用いて行われる。この判定が「Yes」の場合には、処理は、ステップS44’に進み、この判定が「No」の場合には、処理は、ステップS45’に進む。
ステップS44’:スマートフォン用のスクリプト(例えば、JavaScript(登録商標))が選択される。
ステップS45’:要求端末のタイプがタブレット型の端末であるか否かが判定される。このような判定は、ステップS41’において認識された要求端末のユーザ・エージェント情報を用いて行われる。この判定が「Yes」の場合には、処理は、ステップS47’に進み、この判定が「No」の場合には、処理は、ステップS49’に進む。
ステップS47’:タブレット型の端末用のスクリプト(例えば、JavaScript(登録商標))が選択される。
ステップS49’:パーソナルコンピュータ(PC)用のスクリプト(例えば、JavaScript(登録商標))が選択される。
ステップS50’:選択されたスクリプトが、インターネット60を介して、要求端末に送信される。
要求端末は、フロントシステム50からインターネット60を介して選択されたスクリプトを受信し、受信された選択されたスクリプトを実行することによって、要求端末の画面サイズを示す情報を取得する。要求端末は、要求端末において取得された要求端末の画面サイズを示す情報をインターネット60を介してフロントシステム50に送信する。
ステップS51’:要求端末から、インターネット60を介して、要求端末の画面サイズを示す情報が受信される。このようにして、「要求端末の画面サイズを示す情報」が取得される。
このように、図7に示される処理を実行することにより、「要求端末の画面サイズを示す情報」が取得される。従って、図7に示される処理は、図6のステップS32’の処理に相当する処理であるということができる。
図8は、図6に示されるステップS33’の処理の手順の一例を示す。この処理は、図5に示される処理の変形例である。
以下、図8に示される処理を各ステップごとに説明する。
ステップS62’:要求端末の画面サイズ(画面の幅)が320ピクセルより小さいか否かが判定される。このような判定は、例えば、図7に示されるステップS51’において取得される「要求端末の画面サイズを示す情報」を用いて行われる。この判定が「Yes」の場合には、処理は、ステップS63’に進み、この判定が「No」の場合には、処理は、ステップS64’に進む。
ステップS63’:メモリ部54に格納されている少なくとも1つのスタイルシート55のうち、要求端末の画面サイズ(画面の幅)=320ピクセルという条件に対応するスタイルシートが選択される。このスタイルシートは、要求端末の画面サイズ(画面の幅)=320ピクセルという条件に適合するように予め設計されている。このスタイルシートが選択された後、処理は終了する。
ステップS64’:要求端末の画面サイズ(画面の幅)が480ピクセルより小さいか否かが判定される。このような判定は、例えば、図7に示されるステップS51’において取得される「要求端末の画面サイズを示す情報」を用いて行われる。この判定が「Yes」の場合には、処理は、ステップS65’に進み、この判定が「No」の場合には、処理は、ステップS66’に進む。
ステップS65’:メモリ部54に格納されている少なくとも1つのスタイルシート55のうち、要求端末の画面サイズ(画面の幅)=480ピクセルという条件に対応するスタイルシートが選択される。このスタイルシートは、要求端末の画面サイズ(画面の幅)=480ピクセルという条件に適合するように予め設計されている。このスタイルシートが選択された後、処理は終了する。
ステップS66’:要求端末の画面サイズ(画面の幅)が800ピクセルより小さいか否かが判定される。このような判定は、例えば、図7に示されるステップS51’において取得される「要求端末の画面サイズを示す情報」を用いて行われる。この判定が「Yes」の場合には、処理は、ステップS67’に進み、この判定が「No」の場合には、処理は、ステップS68’に進む。
ステップS67’:メモリ部54に格納されている少なくとも1つのスタイルシート55のうち、要求端末の画面サイズ(画面の幅)=800ピクセルという条件に対応するスタイルシートが選択される。このスタイルシートは、要求端末の画面サイズ(画面の幅)=800ピクセルという条件に適合するように予め設計されている。このスタイルシートが選択された後、処理は終了する。
ステップS68’:メモリ部54に格納されている少なくとも1つのスタイルシート55のうち、要求端末の画面サイズ(画面の幅)=1024ピクセルという条件に対応するスタイルシートが選択される。このスタイルシートは、要求端末の画面サイズ(画面の幅)=1024ピクセルという条件に適合するように予め設計されている。このスタイルシートが選択された後、処理は終了する。
このように、コンテンツを生成する処理とは切り離して、デバイスの画面サイズごとにそのデバイスの画面サイズに適合するように設計されたスタイルシートを用意することにより、マルチデバイスに対応したシステムの開発を行う場合でもデバイスごとに開発を行う必要がない。これにより、マルチデバイスに対応したシステムの開発を行う場合にそのシステムの開発期間を短縮し、開発コストを低減することができる。
さらに、マルチデバイスとしての複数の端末のうちスマートフォン用のスタイルシートを最初に設計し、その後、スマートフォン用に設計されたスタイルシートに基づいて、複数の端末のうちスマートフォン以外の端末用のスタイルシートを設計することが好ましい。このようにスタイルシートを設計することにより、スタイルシートの設計に要する時間を大幅に短縮することができる。例えば、スマートフォン用のスタイルシートを最初に設計し、その後、スマートフォン用に設計されたスタイルシートの一部を修正することにより、パーソナルコンピュータ(PC)用のスタイルシートを設計することは容易である。その理由は、少なくとも、以下の(1)〜(3)に示すとおりである。
(1)スマートフォン用の画面は、画面サイズが小さいため、スマートフォン用の画面に表示される情報量が最小化されている。例えば、金融取引法で対応が求められる顧客説明に関する標記が最小限で充足している。このような画面サイズが小さいスマートフォン用の画面を画面サイズが大きいパーソナルコンピュータ(PC)用の画面に転用することは容易である。逆に、画面サイズが大きいパーソナルコンピュータ(PC)用の画面を画面サイズが小さいスマートフォン用の画面に転用することは困難である。
(2)スマートフォン用の画面は、画面スクロールが容易であることから、縦に長い画面となる。このように縦に長いスマートフォン用の画面を分割し横並びで配置することにより、スマートフォン用の画面をパーソナルコンピュータ(PC)用の画面に転用することは容易である。逆に、パーソナルコンピュータ(PC)用の画面をスマートフォン用の画面に転用することは困難である。例えば、パーソナルコンピュータ(PC)用の画面においてメニュー構成をタブ形式で表現している場合、そのような画面をスマートフォン用の画面に転用することは困難である。
(3)スマートフォン用の画面は、画面をタッチすることにより、次の動作へ遷移するように設計される。このため、スマートフォン用の画面には、タッチされることが可能な操作用の領域が確保されている。これに対し、パーソナルコンピュータ(PC)用の画面は、マウス操作を前提として設計される。このため、パーソナルコンピュータ(PC)用の画面には、タッチされることが可能な操作用の領域が確保されているとは限らない。従って、パーソナルコンピュータ(PC)用の画面をスマートフォン用の画面に転用するよりも、スマートフォン用の画面をパーソナルコンピュータ(PC)用の画面に転用する方が容易であるといえる。
あるいは、マルチデバイスとしての複数の端末のうち最小の画面サイズを有する端末用のスタイルシートを最初に設計し、その後、最小の画面サイズを有する端末用に設計されたスタイルシートに基づいて、複数の端末のうち最小の画面サイズを有する端末以外の端末用のスタイルシートを設計するようにしてもよい。このようにスタイルシートを設計することにより、スタイルシートの設計に要する時間を大幅に短縮することができる。なぜなら、最小の画面サイズを有する端末用のスタイルシートを設計する際の設計の制約が最も大きいため、いったん最小の画面サイズを有する端末用のスタイルシートの設計が完了すれば、その後、最小の画面サイズを有する端末用に設計されたスタイルシートの一部を修正することにより、複数の端末のうち最小の画面サイズを有する端末以外の端末用のスタイルシートを設計することは容易であるからである。
銀行業界では、伝統的に、パーソナルコンピュータ(PC)を中心としてアプリケーションの開発が行われてきた。なぜなら、銀行業界では、スマートフォンをパーソナルコンピュータ(PC)を補完するための補完チャネルとして捉える考え方がきわめて根強かったからである。すなわち、銀行システムの開発は、あくまで、パーソナルコンピュータ(PC)用のアプリケーションの開発が主流であり、傍流である携帯電話やスマートフォン用のアプリケーションの開発は、主流であるパーソナルコンピュータ(PC)用のアプリケーションの開発とは別個に行われてきた。銀行業界において、スマートフォンを補完チャネルではなくメインチャネルとして位置づけて銀行サービスを設計しているのは「じぶん銀行」だけなのである。「じぶん銀行」では、口座開設から取引に至るまでスマートフォン以外に必要なものはない。この点で、「じぶん銀行」による銀行システムの開発ポリシーは他社による銀行システムの開発ポリシーとは根本的に異なっているといえる。
4.ミラートレードのシグナル通知サービス
「ミラートレード」とは、FX(店頭外国為替証拠金取引)や証券取引などにおいて、利益を出している投資家の取引の手口を知り、同じタイミングで同種の取引を行うことをいう。ミラートレードの一歩手前で、ミラー取引対象者の投資家が取引を行ったタイミングで手口についての情報を受けることをシグナル通知という。
銀行システム1は、ミラートレードのシグナル通知サービスを提供する。このサービスは、ミラー取引対象者が所定の取引(例えば、外貨預金取引)を行う度にミラー取引申請者にシグナル通知が届くことを可能にする。このサービスは、初心者が為替変動で利鞘を稼ぐ知人の手口を参考にしたい場合などに有用である。このサービスは、携帯端末の携帯電話番号を口座番号の代わりに用いる銀行サービスの一例である。
図9は、マルチデバイスに対応した銀行システム1の構成の他の一例を示す。図9に示される例では、銀行システム1は、顧客データベース70と、ミラー取引データベース80とをさらに含む。顧客データベース70およびミラー取引データベース80は、フロントシステム50(特に、フロントシステム50のプロセッサ部53)に接続されている。顧客データベース70は、銀行の顧客の個人情報などを維持するためのデータベースである。ミラー取引データベース80は、ミラー取引対象者の取引履歴などを維持するためのデータベースである。銀行システム1内の他の構成要素は、図1に示される銀行システム1の構成要素と同様であるので、ここではその説明を省略する。なお、図9に示される例では、本発明の実施形態をマルチデバイスに対応した銀行システム1への適用を例にとり説明するが、本発明はこれに限定されない。本発明は、マルチデバイスに対応していない銀行システムに適用することも可能である。
以下、図10、図11を参照して、ミラー取引申請者がミラー取引対象者の携帯端末の携帯電話番号を指定してシグナル通知の申請を行い、ミラー取引対象者がミラー取引申請者に対するシグナル通知を承認した場合には、ミラー取引対象者が所定の取引(例えば、外貨預金取引)を行う度にミラー取引申請者にシグナル通知が届くことを可能にする実施形態を説明する。
図10は、ミラー取引申請者がシグナル通知の承認を受けるまでの銀行システム1の処理フローの概略を示す。以下、各ステップごとに説明する。
ステップS91:ミラー取引申請者の携帯端末は、インターネット60を介して、シグナル通知のためのリクエストをフロントシステム50に送信する。ここで、シグナル通知のためのリクエストは、ミラー取引対象者の携帯端末の電話番号を含む。このようなシグナル通知のためのリクエストの送信は、例えば、ミラー取引申請者が自分の携帯端末の所定の画面(例えば、外貨預金取引のミラートレードのシグナル通知を申請するための画面)内にミラー取引対象者の携帯端末の電話番号(例えば、090−XXXX−XXXX)を入力し、その画面の送信ボタンにタッチすることによって行われる。
ステップS93:フロントシステム50は、ミラー取引申請者の携帯端末から受信されたシグナル通知のためのリクエストに含まれるミラー取引対象者の携帯端末の電話番号に基づいて顧客データベース70を検索し、ミラー取引対象者を特定し、ミラー取引対象者を特定する情報を生成する。
ステップS95:フロントシステム50は、ミラー取引対象者を特定する情報に基づいて、メッセージを生成し、生成されたメッセージをインターネット60を介してミラー取引対象者の携帯端末に送信する。その結果、ミラー取引対象者の携帯端末の画面には、フロントシステム50から受信されたメッセージが表示される。そのメッセージは、例えば、「○○さんから外貨預金取引のミラートレードのシグナル通知のリクエストが届いています。承認しますか?」というメッセージである。
ステップS96:ミラー取引対象者の携帯端末は、インターネット60を介して、ミラー取引申請者からのシグナル通知のためのリクエストを承認するか否かを示す情報をフロントシステム50に送信する。ミラー取引申請者からのシグナル通知のためのリクエストの承認は、例えば、ミラー取引対象者がフロントシステム50から受信されたメッセージが表示された自分の携帯端末の画面内にある承認ボタンにタッチすることによって行われる。この場合には、ミラー取引申請者からのシグナル通知のためのリクエストを承認したことを示す情報がフロントシステム50に送信される。
ステップS97:フロントシステム50は、ミラー取引対象者がミラー取引申請者からのシグナル通知のためのリクエストを承認したことを示す情報をフロントシステム50内に蓄積する。このような情報の蓄積は、例えば、そのような情報をミラー取引データベース80に格納することによって行われる。
ステップS98:フロントシステム50は、インターネット60を介して、ミラー取引申請者の携帯端末にメッセージを送信する。その結果、ミラー取引申請者の携帯端末の画面には、フロントシステム50から受信されたメッセージが表示される。そのメッセージは、例えば、「××さんが、あなたからの外貨預金取引のミラートレードのシグナル通知のリクエストを承認しました。」というメッセージである。
図11は、ミラー取引対象者が所定の取引(例えば、外貨預金取引)を行った際にミラー取引申請者にシグナル通知を提供するための銀行システム1の処理フローの概略を示す。以下、各ステップごとに説明する。
ステップS101:ミラー取引対象者の携帯端末は、インターネット60を介して、所定の取引(例えば、外貨預金取引)のためのリクエストをフロントシステム50に送信する。以下の説明では、所定の取引が外貨預金取引である場合を例にとり説明するが、本発明はこの例示に限定されるわけではない。外貨預金取引以外の取引に本発明を適用することも可能である。外貨預金取引のためのリクエストは、通貨ペア(例えば、「米ドル」、「日本円」のペア)、売買の種別(例えば、「買い」)、取引金額(例えば、「$1,000,000」)を含む。このような外貨預金取引のためのリクエストの送信は、例えば、ミラー取引対象者が自分の携帯端末の所定の画面(例えば、外貨預金取引のための画面)内に、通貨ペア(例えば、「米ドル」、「日本円」のペア)、売買の種別(例えば、「買い」)、取引金額(例えば、「$1,000,000」)を入力し、その画面の送信ボタンにタッチすることによって行われる。
ステップS102:フロントシステム50は、ミラー取引対象者の携帯端末から受信された外貨預金取引のためのリクエストを勘定系システム40に送信する。
ステップS103:勘定系システム40は、フロントシステム50から受信された外貨預金取引のためのリクエストに応答して、外貨預金取引の処理を実行する。
ステップS104:勘定系システム40は、外貨預金取引の処理結果をフロントシステム50に送信する。
ステップS105:フロントシステム50は、勘定系システム40から外貨預金取引の処理結果を受信し、受信された外貨預金取引の処理結果に基づいてメッセージを生成し、生成されたメッセージをインターネット60を介してミラー取引対象者の携帯端末に送信する。その結果、ミラー取引対象者の携帯端末の画面には、フロントシステム50から受信されたメッセージが表示される。そのメッセージは、例えば、「ご依頼の外貨預金取引が完了しました。」というメッセージである。
ステップS106:フロントシステム50は、シグナル通知のためのメッセージを生成し、生成されたメッセージをインターネット60を介してミラー取引申請者の携帯端末に送信する。このようなメッセージの送信は、例えば、プッシュ通知機能などを用いてシグナル配信によって行われる。その結果、ミラー取引申請者の携帯端末の画面には、フロントシステム50から受信されたメッセージが表示される。そのメッセージは、例えば、「××さんが、外貨預金で以下の取引をしました。2013年○月○日 通貨ペア:米ドル、日本円、売買の種別:買い」というメッセージである。
なお、上述したシグナル通知の例では、ミラー取引申請者には、ミラー取引対象者の取引金額は通知しないこととしたが、ミラー取引対象者の承認が得られる場合には、ミラー取引対象者の取引金額もミラー取引申請者に通知するようにしてもよい。
次に、図12、図13を参照して、ミラー取引対象者を匿名とし、ミラー取引申請者がシグナル通知の申請を行う際にミラー取引対象者の個別の承認を得ることなく、所定の条件を満たす取引者の取引を模倣することを可能にする実施形態を説明する。
図12は、ミラー取引申請者がシグナル通知のための登録をするまでの銀行システム1の処理フローの概略を示す。以下、各ステップごとに説明する。
ステップS112:ミラー取引申請者の携帯端末は、インターネット60を介して、シグナル通知のためのリクエストをフロントシステム50に送信する。ここで、シグナル通知のためのリクエストは、ミラー取引対象者の条件を含む。ミラー取引対象者の条件とは、ミラー取引申請者が取引を模倣することを希望する取引者を絞り込むための条件である。ミラー取引対象者の条件は、例えば、「対象期間内における収益率の高い上位3名の取引者」という条件である。あるいは、ミラー取引対象者の条件は、「対象期間内における収益率が10%以上の取引者」という条件であってもよい。ミラー取引対象者の条件は、任意の条件であり得る。このようなシグナル通知のためのリクエストの送信は、例えば、ミラー取引申請者が自分の携帯端末の所定の画面(例えば、外貨預金取引のミラートレードのシグナル通知を申請するための画面)内にミラー取引対象者の条件(例えば、対象期間、収益率が上位の取引者の人数、収益率の水準など)を入力し、その画面の送信ボタンにタッチすることによって行われる。対象期間は、例えば、過去1週間、過去1か月、過去1年などの期間であるが、任意の期間であり得る。
ステップS113:フロントシステム50は、ミラー取引申請者の携帯端末から受信されたシグナル通知のためのリクエストに含まれるミラー取引対象者の条件に基づいてミラー取引データベース80を検索し、ミラー取引対象者の条件を満たす取引者をミラー取引対象者として特定し、特定されたミラー取引対象者を登録する。このような登録は、例えば、ミラー取引データベース80において、ミラー取引対象者とミラー取引申請者とを関連付けることによって行われる。
ミラー取引データベース80には、例えば、ミラー取引対象者識別子と、ミラー取引許諾の有無フラグと、取引明細(例えば、取引日時、通過ペア、取引金額、為替レート、売買の種別)とを含む。取引明細は、例えば、レコードの形式でミラー取引データベース80に格納され得る。
ミラー取引対象者識別子は、ミラー取引対象者を識別するための識別子である。ミラー取引対象者識別子は、顧客データベース70の顧客識別子(すなわち、顧客を識別するための識別子)に関連付けられている。ミラー取引許諾の有無フラグは、顧客がミラー取引対象者となることを許諾しているか否かを示すフラグである。銀行は、ミラー取引対象者となることを許諾するか否かを予め顧客に問い合わせ、その問い合わせ結果をミラー取引許諾の有無フラグに反映させる。例えば、ミラー取引許諾の有無フラグの値が「1」であることは、顧客がミラー取引対象者となることを許諾していることを示し、ミラー取引許諾の有無フラグの値が「0」であることは、顧客がミラー取引対象者となることを許諾していないことを示す。取引明細は、実際に行われた取引の履歴を示す。取引明細は、その取引を実際に行った取引者の識別子(すなわち、ミラー取引対象者識別子)に関連付けられている。取引明細は、例えば、ミラー取引対象者識別子xxxを有する者が、2013年○月○日に、米ドル日本円の通貨ペアで、為替レートが99円/ドルで、$1,000,000の買い取引をしたことを示す。
ここで、ミラー取引対象者識別子xxxを有する者が、2013年○月○日に、米ドル日本円の通貨ペアで、為替レートが99円/ドルで、$1,000,000の買い取引をし、その後、ミラー取引対象者識別子xxxを有する同じ者が、2013年△月△日に、米ドル日本円の通貨ペアで、為替レートが100円/ドルで、$1,000,000の売り取引をしたとする。この場合、この売買取引における収益率は、((100−99)×1,000,000/99×1,000,000)=1/99である。対象期間内にこの売買取引のみがあった場合には、ミラー取引対象者識別子xxxを有する者の収益率は、1/99ということになる。なお、対象期間内に、買い取引があったが売り取引がなかった場合には、対象期間の終了時の実勢レートでこの取引の収益率を評価することが可能である。
フロントシステム50は、ミラー取引データベース80に格納されている各取引明細を参照して、ミラー取引申請者によって指定された対象期間内におけるミラー取引対象者識別子ごとの収益率を計算し、ミラー取引対象者の条件を満たすミラー取引対象者識別子を特定する。フロントシステム50は、この特定されたミラー取引対象者識別子と、顧客データベース70に格納されているミラー取引申請者の顧客識別子とを関連付ける。これにより、ミラー取引対象者とミラー取引申請者とを関連付けることが可能である。この関連付けにより、シグナル通知のための登録手続が完了する。
なお、ミラー取引対象者の条件を満たす取引者の一覧をミラー取引申請者の携帯端末の画面に表示するようにして、ミラー取引申請者が、ミラー取引対象者の条件を満たす取引者の中から、ミラー取引対象者を選択することができるようにしてもよい。例えば、ミラー取引申請者の携帯端末の画面に、「外貨預金9月の収益率ランキング 1位 Aさん ユーロに強い! 2位 Bさん 8月に続き2位! 3位 Cさん 米ドルに強い!」というようにコメント付きで収益率が高い3名を表示するようにしてもよい。この場合、ミラー取引申請者は、そのコメントを参考にしてミラー取引対象者を選択することが可能になる。ここで、Aさん、Bさん、Cさんは匿名(例えば、ハンドルネームや識別子)である。
図13は、ミラー取引対象者が所定の取引(例えば、外貨預金取引)を行った際にミラー取引申請者にシグナル通知を提供するための銀行システム1の処理フローの概略を示す。以下、各ステップごとに説明する。
ステップS121:ミラー取引対象者の携帯端末は、インターネット60を介して、所定の取引(例えば、外貨預金取引)のためのリクエストをフロントシステム50に送信する。以下の説明では、所定の取引が外貨預金取引である場合を例にとり説明するが、本発明はこの例示に限定されるわけではない。外貨預金取引以外の取引に本発明を適用することも可能である。外貨預金取引のためのリクエストは、通貨ペア(例えば、「米ドル」、「日本円」のペア)、売買の種別(例えば、「買い」)、取引金額(例えば、「$1,000,000」)を含む。このような外貨預金取引のためのリクエストの送信は、例えば、ミラー取引対象者が自分の携帯端末の所定の画面(例えば、外貨預金取引のための画面)内に、通貨ペア(例えば、「米ドル」、「日本円」のペア)、売買の種別(例えば、「買い」)、取引金額(例えば、「$1,000,000」)を入力し、その画面の送信ボタンにタッチすることによって行われる。
ステップS122:フロントシステム50は、ミラー取引対象者の携帯端末から受信された外貨預金取引のためのリクエストを勘定系システム40に送信する。
ステップS123:勘定系システム40は、フロントシステム50から受信された外貨預金取引のためのリクエストに応答して、外貨預金取引の処理を実行する。
ステップS124:勘定系システム40は、外貨預金取引の処理結果をフロントシステム50に送信する。
ステップS125:フロントシステム50は、勘定系システム40から外貨預金取引の処理結果を受信し、受信された外貨預金取引の処理結果に基づいてメッセージを生成し、生成されたメッセージをインターネット60を介してミラー取引対象者の携帯端末に送信する。その結果、ミラー取引対象者の携帯端末の画面には、フロントシステム50から受信されたメッセージが表示される。そのメッセージは、例えば、「ご依頼の外貨預金取引が完了しました。」というメッセージである。
ステップS126:フロントシステム50は、シグナル通知のためのメッセージを生成し、生成されたメッセージをインターネット60を介してミラー取引申請者の携帯端末に送信する。このようなメッセージの送信は、例えば、プッシュ通知機能などを用いてシグナル配信によって行われる。その結果、ミラー取引申請者の携帯端末の画面には、フロントシステム50から受信されたメッセージが表示される。そのメッセージは、例えば、「ミラー取引対象者(匿名)が、外貨預金で以下の取引をしました。2013年○月○日 通貨ペア:米ドル、日本円、売買の種別:買い」というメッセージである。このようなメッセージは、登録されたミラー取引対象者に関連付けられているすべてのミラー取引申請者の携帯端末に送信される。
なお、上述したシグナル通知の例では、ミラー取引申請者には、ミラー取引対象者の取引金額は通知しないこととしたが、ミラー取引対象者の承認が得られる場合には、ミラー取引対象者の取引金額もミラー取引申請者に通知するようにしてもよい。
図12、図13に示される実施形態によれば、ミラー取引申請者は、ミラー取引対象者が実際に誰であるのかを知ることなく(従って、ミラー取引申請者がミラー取引対象者に対して個別の承認を得ることなく、ミラー取引対象者は匿名のままで)、ミラー取引対象者の条件を満たす仮想的な取引者の取引を模倣するための情報を即時的に取得することが可能である。仮想的な取引者は、1人であっても複数人であってもよく、対象期間によって異なるミラー取引対象者識別子によって識別される取引者であってもよい。なお、ミラー取引対象者となることを許諾していない者は、このような仮想的な取引者となることはない。これにより、銀行システム1は、ミラー取引対象者の個人情報を保護しつつ、ミラー取引申請者に対してミラートレードのシグナル通知サービスを提供することが可能である。
以上のように、本発明の好ましい実施形態を用いて本発明を例示してきたが、本発明は、この実施形態に限定して解釈されるべきものではない。本発明は、特許請求の範囲によってのみその範囲が解釈されるべきであることが理解される。当業者は、本発明の具体的な好ましい実施形態の記載から、本発明の記載および技術常識に基づいて等価な範囲を実施することができることが理解される。