JP2015146186A

JP2015146186A - マルチデバイスに対応したシステムにおいて用いられる装置、その装置において実行される方法およびプログラム

Info

Publication number: JP2015146186A
Application number: JP2015026637A
Authority: JP
Inventors: 一弥榊原; Kazuya Sakakibara; 良和都木; Yoshikazu Togi; 本田　進; Susumu Honda; 進本田
Original assignee: JIBUN BANK CORP
Current assignee: JIBUN BANK CORP
Priority date: 2015-02-13
Filing date: 2015-02-13
Publication date: 2015-08-13
Anticipated expiration: 2033-10-29
Also published as: JP5788116B2

Abstract

【課題】マルチデバイスに対応したシステムにおいて用いられる装置を提供すること。【解決手段】装置は、ネットワークを介して、マルチデバイスとしての複数の端末のうちの少なくとも１つの端末に接続されるように構成される。装置は、要求端末からの要求をネットワークを介して受信すること（ステップＳ３１’）と、要求端末の画面サイズを示す情報を取得すること（ステップＳ３２’）と、要求端末の画面サイズを示す情報に少なくとも基づいて、少なくとも１つのスタイルシートのうちのスタイルシートを選択すること（ステップＳ３３’）と、選択されたスタイルシートに基づく情報をネットワークを介して要求端末に提供すること（ステップＳ３７’）とを行うように構成されている。【選択図】図６

Description

本発明は、マルチデバイスに対応したシステムにおいて用いられる装置、その装置において実行される方法およびプログラムに関し、特に、マルチデバイスに対応したシステムの開発を行う場合にそのシステムの開発期間を短縮し開発コストを低減することを可能にする装置、その装置において実行される方法およびプログラムに関する。

従来から、マルチデバイスに対応したシステムが知られている。特許文献１には、ユーザが複数種類のクライアント装置を使用する場合でも、予め登録されたスケジュールに沿ってクライアント装置の種類に応じたアプリケーション実行環境の事前生成を可能にする情報処理装置が開示されている。特許文献２には、ユーザが利用する端末の種類に応じて、提供する案内情報の形態を変更することが可能な案内情報提供方法が開示されている。特許文献３には、画像表示を要求した携帯端末から送信されるユーザエージェントから取得する携帯端末の情報を参照しながら携帯端末に最適な映像変換指示を生成する工程を含む画像処理方法が開示されている。

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

しかしながら、従来、マルチデバイスに対応したシステムの開発を行う場合に、そのシステムの開発期間を短縮し開発コストを低減するための手法が確立されていないという課題があった。

本発明は、この課題を解決するためになされたものであり、マルチデバイスに対応したシステムの開発を行う場合にそのシステムの開発期間を短縮し開発コストを低減することを可能にする装置、その装置において実行される方法およびプログラムを提供することを目的とする。

本発明は、マルチデバイスに対応したシステムにおいて用いられる装置であって、前記装置は、ネットワークを介して、前記マルチデバイスとしての複数の端末のうちの少なくとも１つの端末に接続されるように構成され、前記装置は、プロセッサ部とメモリ部とを含み、前記メモリ部には、少なくとも１つのスタイルシートが格納されており、前記少なくとも１つのスタイルシートのそれぞれは、コンテンツの表示形式を定義するものであり、前記少なくとも１つのスタイルシートのそれぞれは、前記少なくとも１つの端末のうちの１つに対応し、前記プロセッサ部は、要求端末からの要求を前記ネットワークを介して受信することであって、前記要求端末は、前記少なくとも１つの端末のうちの１つである、ことと、前記要求端末の画面サイズを示す情報を取得することと、前記要求端末の画面サイズを示す情報に少なくとも基づいて、前記少なくとも１つのスタイルシートのうちのスタイルシートを選択することと、前記選択されたスタイルシートに基づく情報を前記ネットワークを介して前記要求端末に提供することとを行うように構成されている。これに
より、上述した目的が達成される。

前記プロセッサ部は、前記要求端末のユーザ・エージェント情報を認識することにより前記要求端末のタイプを判定し、前記要求端末のタイプに応じたスクリプトを、前記ネットワークを介して、前記要求端末に送信し、前記送信されたスクリプトを前記要求端末が実行することによって前記要求端末において取得された前記要求端末の画面サイズを示す情報を、前記ネットワークを介して、前記要求端末から受信することによって、前記要求端末の画面サイズを示す情報を取得するように構成されていてもよい。

前記プロセッサ部は、前記受信された要求に対して実行される処理の結果を表す応答に対応する前記マルチデバイスに共通のコンテンツを生成するようにさらに構成されており、前記プロセッサ部は、前記選択されたスタイルシートと前記生成されたコンテンツとに基づく情報を前記ネットワークを介して前記要求端末に提供してもよい。

前記プロセッサ部は、前記要求端末のタイプを示す情報を取得するようにさらに構成されており、前記プロセッサ部は、前記要求端末の画面サイズを示す情報と前記要求端末のタイプを示す情報とに少なくとも基づいて、前記少なくとも１つのスタイルシートのうちのスタイルシートを選択してもよい。

前記システムは、預金者の口座情報を維持するための口座情報データベースと、前記口座情報データベースに接続された勘定系システムであって、銀行サービスのための処理を実行する勘定系システムとを含み、前記受信された要求に対して実行される処理は、前記受信された要求に対して前記勘定系システムによって実行される前記銀行サービスのための処理であってもよい。

前記要求端末は、電話機能を有する携帯端末であり、前記勘定系システムによって実行される銀行サービスのための処理は、前記要求端末の携帯電話番号を口座番号の代わりに利用する銀行サービスのための処理であってもよい。

前記銀行サービスは、ミラートレードのためのシグナル通知サービスであってもよい。

本発明は、マルチデバイスに対応したシステムにおいて用いられる装置において実行される方法であって、前記装置は、ネットワークを介して、前記マルチデバイスとしての複数の端末のうちの少なくとも１つの端末に接続されるように構成され、前記装置は、プロセッサ部とメモリ部とを含み、前記メモリ部には、少なくとも１つのスタイルシートが格納されており、前記少なくとも１つのスタイルシートのそれぞれは、コンテンツの表示形式を定義するものであり、前記少なくとも１つのスタイルシートのそれぞれは、前記少なくとも１つの端末のうちの１つに対応し、前記方法は、前記プロセッサ部が、要求端末からの要求を前記ネットワークを介して受信することであって、前記要求端末は、前記少なくとも１つの端末のうちの１つである、ことと、前記プロセッサ部が、前記要求端末の画面サイズを示す情報を取得することと、前記プロセッサ部が、前記要求端末の画面サイズを示す情報に少なくとも基づいて、前記少なくとも１つのスタイルシートのうちのスタイルシートを選択することと、前記プロセッサ部が、前記選択されたスタイルシートに基づく情報を前記ネットワークを介して前記要求端末に提供することとを含む。これにより、上述した目的が達成される。

本発明は、マルチデバイスに対応したシステムにおいて用いられる装置において実行されるプログラムであって、前記装置は、ネットワークを介して、前記マルチデバイスとしての複数の端末のうちの少なくとも１つの端末に接続されるように構成され、前記装置は、プロセッサ部とメモリ部とを含み、前記メモリ部には、少なくとも１つのスタイルシー
トが格納されており、前記少なくとも１つのスタイルシートのそれぞれは、コンテンツの表示形式を定義するものであり、前記少なくとも１つのスタイルシートのそれぞれは、前記少なくとも１つの端末のうちの１つに対応し、前記プログラムは、前記プロセッサ部によって実行されると、要求端末からの要求を前記ネットワークを介して受信することであって、前記要求端末は、前記少なくとも１つの端末のうちの１つである、ことと、前記要求端末の画面サイズを示す情報を取得することと、前記要求端末の画面サイズを示す情報に少なくとも基づいて、前記少なくとも１つのスタイルシートのうちのスタイルシートを選択することと、前記選択されたスタイルシートに基づく情報を前記ネットワークを介して前記要求端末に提供することとを前記プロセッサ部に行わせる。これにより、上述した目的が達成される。

本発明によれば、マルチデバイスに対応したシステムの開発を行う場合にそのシステムの開発期間を短縮し開発コストを低減することを可能にする装置、その装置において実行される方法およびプログラムを提供することが可能になる。

マルチデバイスに対応した銀行システム１の構成の一例を示す図銀行システム１の処理フローの概略を示す図フロントシステム５０（すなわち、フロントシステム５０のプロセッサ部５３）によって実行される処理の手順の一例を示す図図３に示されるステップＳ３２の処理の手順の一例を示す図図３に示されるステップＳ３３の処理の手順の一例を示す図フロントシステム５０（すなわち、フロントシステム５０のプロセッサ部５３）によって実行される処理の手順の他の一例を示す図図６に示されるステップＳ３２’の処理の手順の一例を示す図図６に示されるステップＳ３３’の処理の手順の一例を示す図マルチデバイスに対応した銀行システム１の構成の他の一例を示す図ミラー取引申請者がシグナル通知の承認を受けるまでの銀行システム１の処理フローの概略を示す図ミラー取引対象者が所定の取引（例えば、外貨預金取引）を行った際にミラー取引申請者にシグナル通知を提供するための銀行システム１の処理フローの概略を示す図ミラー取引申請者がシグナル通知の登録をするまでの銀行システム１の処理フローの概略を示す図ミラー取引対象者が所定の取引（例えば、外貨預金取引）を行った際にミラー取引申請者にシグナル通知を提供するための銀行システム１の処理フローの概略を示す図

以下、図面を参照しながら、本発明の実施の形態を銀行システムへの適用を例にとり説明する。ただし、本発明が銀行システムへの適用に限定されるわけではない。本発明は、マルチデバイスに対応した任意のシステムに適用することが可能である。

１．銀行システムの構成
図１は、マルチデバイスに対応した銀行システム１の構成の一例を示す。図１に示される例では、銀行システム１は、マルチデバイスとしての端末１０_１、端末１０_２、・・・、端末１０_Ｎに対応する。ここで、Ｎは、２以上の任意の整数である。例えば、端末１０_１は、スマートフォンであり、端末１０_２は、タブレット型の端末であり、端末１０_Ｎは
、パーソナルコンピュータ（ＰＣ）である。このように、銀行システム１は、様々なタイプの端末からの要求に応えることができるように構成されている。端末１０_１、端末１０_２、・・・、端末１０_Ｎには、それぞれ、端末のタイプに応じたブラウザ２０_１、２０_２、・・・、２０_Ｎが組み込まれている。これにより、端末１０_１、端末１０_２、・・・、端末１０_Ｎのそれぞれは、Ｗｅｂブラウザとして機能することが可能である。

銀行システム１は、預金者の口座情報を維持するための口座情報データベース３０と、口座情報データベース３０に接続された勘定系システム４０と、勘定系システム４０のフロントエンドとして機能するフロントシステム５０とを含む。

勘定系システム４０は、銀行の基幹システムであり、入出金の管理など勘定系のすべての銀行サービスを実行する。例えば、勘定系システム４０は、預金の残高照会、円預金、外貨預金、振込、ＦＸ（店頭外国為替証拠金取引）などの銀行サービスを実行する。

フロントシステム５０は、インターネット６０を介して、端末１０_１、端末１０_２、・・・端末１０_Ｎのうちの少なくとも１つに接続されるように構成されている。

フロントシステム５０は、ブラウザ共通インターフェース部５１と、勘定系システムインターフェース部５２と、プロセッサ部５３と、メモリ部５４とを含む。

ブラウザ共通インターフェース部５１は、ブラウザ２０_１、２０_２、・・・、２０_Ｎのうちの少なくとも１つとの通信を制御する。

勘定系システムインターフェース部５２は、勘定系システム４０との通信を制御する。

プロセッサ部５３は、フロントシステム５０の全体の動作を制御する。

メモリ部５４には、少なくとも１つのスタイルシート５５が格納されている。少なくとも１つのスタイルシート５５は、例えば、複数のスタイルシート５５_１１、５５_１２、・・・５５_１ｉ、５５_２１、５５_２２、・・・５５_２ｊ、・・・、５５_Ｎ１、５５_Ｎ２、・・・５５_Ｎｋである。ここで、ｉ、ｊ、ｋは、１以上の整数である。スタイルシート５５_１１、５５_１２、・・・５５_１ｉは、端末１０_１に対して用いられるｉ個のスタイルシートを示す。スタイルシート５５_２１、５５_２２、・・・５５_２ｊは、端末１０_２に対して用いられるｊ個のスタイルシートを示す。スタイルシート５５_Ｎ１、５５_Ｎ２、・・・５５_Ｎｋは、端末１０_Ｎに対して用いられるｋ個のスタイルシートを示す。各スタイルシートは、コンテンツの表示形式を定義する。原則として、１つのスタイルシートは、端末に表示される１つの画面（１つのウェブページ）を単位として定義される。各コンテンツは、例えば、ＨＴＭＬやＸＨＴＭＬなどのマークアップ言語で記述される。各スタイルシートは、例えば、ＣＳＳやＸＳＬなどのスタイルシート言語で記述される。各スタイルシートは、銀行サービスが実行される前にメモリ部５４に予め格納されていてもよいし、銀行サービスの実行時に動的に生成され、メモリ部５４に格納されてもよい。

なお、図１に示されるプロセッサ部５３、メモリ部５４などのそれぞれの構成要素は、単一のハードウェア部品で構成されてもよいし、複数のハードウェア部品で構成されてもよい。本発明は、特定のハードウェア構成には限定されない。

また、図１に示される実施の形態では、銀行システム１と端末１０_１、端末１０_２、・・・端末１０_Ｎとは、インターネット６０を介して接続されるとしたが、本発明はこれに限定されない。インターネット６０の代わりに任意のタイプのネットワークを用いる場合でも、本発明を適用することが可能である。

２．銀行システムの処理
図２は、銀行システム１の処理フローの概略を示す。以下、各ステップごとに説明する。

ステップＳ２１：要求端末は、要求（例えば、預金の残高照会）をインターネット６０を介してフロントシステム５０に送信する。ここで、要求端末とは、端末１０_２、・・・、端末１０_Ｎのうちの１つの端末であって、要求を送信した端末をいう。

ステップＳ２２：フロントシステム５０は、「要求端末のタイプを示す情報」と「要求端末の画面サイズを示す情報」とを取得する。なお、本発明では、フロントシステム５０が「要求端末のタイプを示す情報」と「要求端末の画面サイズを示す情報」とをどのようにして取得するかは問わない。フロントシステム５０が「要求端末のタイプを示す情報」と「要求端末の画面サイズを示す情報」とを取得する限り、フロントシステムが５０がどのような方法でこれらの情報を取得した場合も本発明の範囲内である。

ステップＳ２３：フロントシステム５０は、メモリ部５４に格納されている少なくとも１つのスタイルシート５５のうち、ステップＳ２２において取得された「要求端末のタイプを示す情報」と「要求端末の画面サイズを示す情報」とに対応するスタイルシートを選択する。

ステップＳ２４：フロントシステム５０は、要求端末から受信された要求を勘定系システム４０に送信する。ただし、要求端末から受信された要求のフロントシステム５０から勘定系システム４０への送信は、フロントシステム５０と勘定系システム４０との間の所定のプロトコルに従って行われる。従って、要求端末から受信された要求は、フロントシステム５０（すなわち、フロントシステム５０の勘定系システムインターフェース部５２）において必要に応じて所定のデータ形式に変換され、所定の手順に従って勘定系システム４０に送信される。

なお、ステップＳ２４は、ステップＳ２３よりも後に実行されなければならないことはない。ステップＳ２４は、ステップＳ２１よりも後の任意のタイミングで実行され得る。

ステップＳ２５：勘定系システム４０は、フロントシステム５０から受信された要求（例えば、預金の残高照会）に対する処理を実行する。

ステップＳ２６：勘定系システム４０は、フロントシステム５０から受信された要求（例えば、預金の残高照会）に対する処理の結果を表す、その要求に対する応答をフロントシステム５０に送信する。フロントシステム５０は、勘定系システム４０からその応答を受信する。ただし、その応答の勘定系システム４０からフロントシステム５０への送信は、フロントシステム５０と勘定系システム４０との間の所定のプロトコルに従って行われる。従って、その応答は、所定の手順に従ってフロントシステム５０によって受信され、フロントシステム５０（すなわち、フロントシステム５０の勘定系システムインターフェース部５２）において必要に応じて所定のデータ形式に変換される。

ステップＳ２７：フロントシステム５０は、勘定系システム４０から受信された応答に対応するコンテンツを生成する。ここで、フロントシステム５０によって生成されるコンテンツは、マルチデバイスに共通のコンテンツである。例えば、「預金の残高照会」という要求に対して、勘定系システム４０から受信された応答が「￥１０，０００」であったとする。この場合、フロントシステム５０は、預金の残高が「￥１０，０００」であることを示す画面（ウェブページ）を要求端末のディスプレイに表示するためのコンテンツ（
例えば、ＨＴＭＬコンテンツ）を生成する。ここで、フロントシステム５０がどのようなタイプの要求端末から（および／または、どのような画面サイズの要求端末から）「預金の残高照会」という要求を受信した場合でも、預金の残高が「￥１０，０００」であるという事実に変わりはない。従って、フロントシステム５０は、フロントシステム５０がどのようなタイプの要求端末から（および／または、どのような画面サイズの要求端末から）「預金の残高照会」という要求を受信したかにかかわらず、預金の残高が「￥１０，０００」であるという勘定系システム４０からの応答に対して、マルチデバイスに共通のコンテンツ（例えば、ＨＴＬＭコンテンツ）を生成する。

ステップＳ２８：フロントシステム５０は、ステップＳ２３において選択されたスタイルシートとステップＳ２７において生成されたマルチデバイスに共通のコンテンツ（例えば、ＨＴＭＬコンテンツ）とをインターネット６０を介して要求端末に送信する。

ステップＳ２９：要求端末は、フロントシステム５０からインターネット６０を介してステップＳ２３において選択されたスタイルシートとステップＳ２７において生成されたマルチデバイスに共通のコンテンツ（例えば、ＨＴＭＬコンテンツ）とを受信し、受信されたスタイルシートに従って、受信されたコンテンツ（例えば、ＨＴＭＬコンテンツ）を要求端末のディスプレイに表示する。

このように、図２に示される銀行システム１の処理フローによれば、要求端末は、「要求端末のタイプを示す情報」と「要求端末の画面サイズを示す情報」とに応じて選択されたスタイルシートに従って、コンテンツを要求端末のディスプレイに表示する。表示されるコンテンツは、「要求端末のタイプを示す情報」と「要求端末の画面サイズを示す情報」にかかわらず、マルチデバイスに共通のコンテンツであるが、このコンテンツを「要求端末のタイプを示す情報」と「要求端末の画面サイズを示す情報」とに応じて選択されたスタイルシートに従って表示することによって、マルチデバイスに共通のコンテンツを要求端末のタイプおよび画面サイズに適切な表示形式で要求端末のディスプレイに表示することが可能である。

なお、顧客の携帯電話番号と口座番号とが一対一に対応付けられている銀行システムにおいて、顧客は、携帯電話番号を口座番号の代わりに用いる銀行サービスを利用することができる。例えば、顧客同士が銀行に口座を有している場合には、振込人が受取人の携帯電話番号および氏名のみを指定して振込を行う振込サービス（いわゆる「ケータイ番号振込」サービス）を利用することができる。

要求端末が電話機能を有する携帯端末である場合（例えば、要求端末が携帯電話やスマートフォンである場合）には、勘定系システム４０によって実行される処理は、要求端末の携帯電話番号を口座番号の代わりに用いる銀行サービスのための処理であってもよい。そのような銀行サービスとしては、例えば、受取人の携帯電話番号および氏名のみを指定して振込を行う振込サービス（いわゆる「ケータイ番号振込」サービス）が挙げられる。

３．フロントシステムの処理
図３は、フロントシステム５０（すなわち、フロントシステム５０のプロセッサ部５３）によって実行される処理の手順の一例を示す。この処理は、例えば、プログラムの形式でメモリ部５４に格納されている。メモリ部５４に格納されているプログラムは、例えば、Ｗｅｂサーバプログラムである。プロセッサ部５３は、メモリ部５４に格納されているＷｅｂサーバプログラムを読み出し、そのＷｅｂサーバプログラムを実行する。これにより、フロントシステム５０は、Ｗｅｂサーバとして機能することが可能になる。

以下、図３に示される処理を各ステップごとに説明する。

ステップＳ３１：フロントシステム５０は、要求端末からの要求（例えば、預金の残高照会）をインターネット６０を介して受信する。このステップは、図２のステップ２１に対応するステップである。

ステップＳ３２：フロントシステム５０は、「要求端末のタイプを示す情報」と「要求端末の画面サイズを示す情報」とを取得する。このステップは、図２のステップＳ２２に対応するステップである。

ステップＳ３３：フロントシステム５０は、ステップＳ３２において取得された「要求端末のタイプを示す情報」と「要求端末の画面サイズを示す情報」とに少なくとも基づいて、メモリ部５４に格納されている少なくとも１つのスタイルシート５５のうちのスタイルシートを選択する。このステップは、図２のステップＳ２３に対応するステップである。

ステップＳ３４：フロントシステム５０は、要求端末から受信された要求を勘定系システム４０に送信する。このステップは、図２のステップＳ２４に対応するステップである。従って、ステップＳ３４は、ステップＳ３３よりも後に実行されなければならないことはない。ステップＳ３４は、ステップＳ３１よりも後の任意のタイミングで実行され得る。

ステップＳ３５：フロントシステム５０は、勘定系システム４０に送信された要求（例えば、預金の残高照会）に対する勘定系システム４０の処理の結果を表す、その要求に対する応答を勘定系システム４０から受信する。このステップは、図２のステップＳ２６に対応するステップである。

ステップＳ３６：フロントシステム５０は、勘定系システム４０から受信された応答に対応するコンテンツを生成する。ここで、フロントシステム５０によって生成されるコンテンツは、マルチデバイスに共通のコンテンツである。このステップは、図２のステップＳ２７に対応するステップである。

ステップＳ３７：フロントシステム５０は、ステップＳ３３において選択されたスタイルシートとステップＳ３６において生成されたマルチデバイスに共通のコンテンツ（例えば、ＨＴＭＬコンテンツ）とをインターネット６０を介して要求端末に送信する。このステップは、図２のステップＳ２８に対応するステップである。あるいは、ステップＳ３７において、フロントシステム５０は、ステップＳ３３において選択されたスタイルシートとステップＳ３６において生成されたマルチデバイスに共通のコンテンツ（例えば、ＨＴＭＬコンテンツ）とに基づいてコンテンツを合成し、その合成されたコンテンツを要求端末に送信するようにしてもよい。このように合成されたコンテンツは、例えば、ＨＴＭＬコンテンツである。いずれの場合でも、スタイルシートとマルチデバイスに共通のコンテンツとに基づく情報が、要求端末に送信されることになる。スタイルシートとマルチデバイスに共通のコンテンツとに基づく情報は、スタイルシートそのものとマルチデバイスに共通のコンテンツそのものであってもよいし、スタイルシートとマルチデバイスに共通のコンテンツとに基づいて合成されたコンテンツであってもよい。スタイルシートとマルチデバイスに共通のコンテンツとに基づく情報は、スタイルシートとマルチデバイスに共通のコンテンツとに基づく限り、任意の情報であり得る。

このように、図３に示されるフロントシステム５０によって実行される処理の手順によれば、要求端末は、フロントシステム５０から、インターネット６０を介して、スタイル
シートとマルチデバイスに共通のコンテンツとに基づく情報を受信し、スタイルシートによって定義された表示形式に従って、コンテンツ（例えば、ＨＴＭＬコンテンツ）を要求端末のディスプレイに表示する。表示されるコンテンツは、「要求端末のタイプを示す情報」と「要求端末の画面サイズを示す情報」にかかわらず、マルチデバイスに共通のコンテンツであるが、このコンテンツを「要求端末のタイプを示す情報」と「要求端末の画面サイズを示す情報」とに少なくとも基づいて選択されたスタイルシートによって定義された表示形式に従って表示することによって、マルチデバイスに共通のコンテンツを要求端末のタイプおよび画面サイズに適切な表示形式で要求端末のディスプレイに表示することが可能である。

なお、上述した実施形態では、ステップＳ３４においてフロントシステム５０が要求を勘定系システム４０に送信し、ステップＳ３５においてフロントシステム５０がその要求に対する応答を勘定系システム４０から受信する例を説明したが、本発明はこれに限定されない。例えば、フロントシステム５０は、要求をフロントシステム５０の外部にある勘定系システム４０以外のシステムに送信し、その要求に対する応答をその外部のシステムから受信するようにしてもよい。この場合、フロントシステム５０は、その外部のシステムから受信された応答に対応するコンテンツを生成する。

あるいは、フロントシステム５０は、要求をフロントシステム５０の外部にあるシステムに送信し、その外部のシステムから受信する代わりに、その要求をフロントシステム５０の内部で処理することにより、その要求に対する応答をフロントシステム５０の内部で生成するようにしてもよい。この場合、フロントシステム５０は、フロントシステム５０の内部で生成された応答に対応するコンテンツを生成する。

このように、フロントシステム５０は、必ずしも、フロントシステム５０の外部にあるシステムに対するフロントエンドとして機能する必要はない。この意味で、フロントシステム５０は、マルチデバイスに対応したシステム（例えば、銀行システム１）において用いられる装置ということができる。

図４は、図３に示されるステップＳ３２の処理の手順の一例を示す。この処理は、フロントシステム５０（すなわち、フロントシステム５０のプロセッサ部５３）によって実行される。この処理は、例えば、プログラムの形式でメモリ部５４に格納されている。メモリ部５４に格納されているプログラムは、例えば、Ｗｅｂサーバプログラムである。

以下、図４に示される処理を各ステップごとに説明する。

ステップＳ４１：要求端末のユーザ・エージェント情報が認識される。ここで、ユーザ・エージェント情報とは、ユーザのブラウザの種類やオペレーティングシステム（ＯＳ）などを示す情報である。

ステップＳ４２：要求端末のタイプがスマートフォンであるか否かが判定される。このような判定は、ステップＳ４１において認識された要求端末のユーザ・エージェント情報を用いて行われる。この判定が「Ｙｅｓ」の場合には、処理は、ステップＳ４３に進み、この判定が「Ｎｏ」の場合には、処理は、ステップＳ４５に進む。

ステップＳ４３：要求端末のタイプがスマートフォンであると判定される。このことは、要求端末のタイプがスマートフォンであることを示す情報が「要求端末のタイプを示す情報」として取得されたことを意味する。

ステップＳ４４：スマートフォン用のスクリプト（例えば、ＪａｖａＳｃｒｉｐｔ（登
録商標））が選択される。

ステップＳ４５：要求端末のタイプがタブレット型の端末であるか否かが判定される。このような判定は、ステップＳ４１において認識された要求端末のユーザ・エージェント情報を用いて行われる。この判定が「Ｙｅｓ」の場合には、処理は、ステップＳ４６に進み、この判定が「Ｎｏ」の場合には、処理は、ステップＳ４８に進む。

ステップＳ４６：要求端末のタイプがタブレット型の端末であると判定される。このことは、要求端末のタイプがタブレット型の端末であることを示す情報が「要求端末のタイプを示す情報」として取得されたことを意味する。

ステップＳ４７：タブレット型の端末用のスクリプト（例えば、ＪａｖａＳｃｒｉｐｔ（登録商標））が選択される。

ステップＳ４８：要求端末のタイプがパーソナルコンピュータ（ＰＣ）であると判定される。このことは、要求端末のタイプがパーソナルコンピュータ（ＰＣ）であることを示す情報が「要求端末のタイプを示す情報」として取得されたことを意味する。なお、図４に示される例では、要求端末のタイプが、スマートフォンではなく、かつ、タブレット型の端末でない場合には、すべて、要求端末のタイプがパーソナルコンピュータ（ＰＣ）であると判定される。このように要求端末のタイプを判定することにより、新たなタイプの要求端末が開発された場合でも、その要求端末のタイプがパーソナルコンピュータ（ＰＣ）であるとして処理を進めることが可能である。

ステップＳ４９：パーソナルコンピュータ（ＰＣ）用のスクリプト（例えば、ＪａｖａＳｃｒｉｐｔ（登録商標））が選択される。

ステップＳ５０：選択されたスクリプトが、インターネット６０を介して、要求端末に送信される。

要求端末は、フロントシステム５０からインターネット６０を介して選択されたスクリプトを受信し、受信された選択されたスクリプトを実行することによって、要求端末の画面サイズを示す情報を取得する。要求端末は、要求端末において取得された要求端末の画面サイズを示す情報をインターネット６０を介してフロントシステム５０に送信する。

ステップＳ５１：要求端末から、インターネット６０を介して、要求端末の画面サイズを示す情報が受信される。このようにして、「要求端末の画面サイズを示す情報」が取得される。

このように、図４に示される処理を実行することにより、「要求端末のタイプを示す情報」と「要求端末の画面サイズを示す情報」とが取得される。従って、図４に示される処理は、図３のステップＳ３２の処理に相当する処理であるということができる。

図５は、図３に示されるステップＳ３３の処理の手順の一例を示す。この処理は、フロントシステム５０（すなわち、フロントシステム５０のプロセッサ部５３）によって実行される。この処理は、例えば、プログラムの形式でメモリ部５４に格納されている。メモリ部５４に格納されているプログラムは、例えば、Ｗｅｂサーバプログラムである。

図５に示される例では、要求端末のタイプは、「スマートフォン」、「タブレット型の端末」、「パーソナルコンピュータ（ＰＣ）」のいずれかであると仮定されている。また、「スマートフォン」には、いくつかの異なる画面サイズを有するタイプがあり、「ダブ
レット型の端末」にも、いくつかの異なる画面サイズを有するタイプがあるものと仮定されている。もちろん、本発明がこれらの仮定に限定されるわけではない。要求端末のタイプの場合分けが図５に示される例とは異なるように行われ、および／または、要求端末の画面サイズの場合分けが図５に示される例とは異なるように行われる場合でも、本発明を適用することが可能である。

以下、図５に示される処理を各ステップごとに説明する。

ステップＳ６１：要求端末のタイプがスマートフォンであるか否かが判定される。このような判定は、例えば、図４に示されるステップＳ４３、Ｓ４６、Ｓ４８において取得される「要求端末のタイプを示す情報」を用いて行われる。この判定が「Ｙｅｓ」の場合には、処理は、ステップＳ６２に進み、この判定が「Ｎｏ」の場合には、処理は、ステップＳ６９に進む。

ステップＳ６２：要求端末の画面サイズ（画面の幅）が３２０ピクセルより小さいか否かが判定される。このような判定は、例えば、図４に示されるステップＳ５１において取得される「要求端末の画面サイズを示す情報」を用いて行われる。この判定が「Ｙｅｓ」の場合には、処理は、ステップＳ６３に進み、この判定が「Ｎｏ」の場合には、処理は、ステップＳ６４に進む。

ステップＳ６３：メモリ部５４に格納されている少なくとも１つのスタイルシート５５のうち、要求端末のタイプ＝スマートフォン、かつ、要求端末の画面サイズ（画面の幅）＝３２０ピクセルという条件に対応するスタイルシートが選択される。このスタイルシートは、要求端末のタイプ＝スマートフォン、かつ、要求端末の画面サイズ（画面の幅）＝３２０ピクセルという条件に適合するように予め設計されている。このスタイルシートが選択された後、処理は終了する。

ステップＳ６４：要求端末の画面サイズ（画面の幅）が４８０ピクセルより小さいか否かが判定される。このような判定は、例えば、図４に示されるステップＳ５１において取得される「要求端末の画面サイズを示す情報」を用いて行われる。この判定が「Ｙｅｓ」の場合には、処理は、ステップＳ６５に進み、この判定が「Ｎｏ」の場合には、処理は、ステップＳ６６に進む。

ステップＳ６５：メモリ部５４に格納されている少なくとも１つのスタイルシート５５のうち、要求端末のタイプ＝スマートフォン、かつ、要求端末の画面サイズ（画面の幅）＝４８０ピクセルという条件に対応するスタイルシートが選択される。このスタイルシートは、要求端末のタイプ＝スマートフォン、かつ、要求端末の画面サイズ（画面の幅）＝４８０ピクセルという条件に適合するように予め設計されている。このスタイルシートが選択された後、処理は終了する。

ステップＳ６６：要求端末の画面サイズ（画面の幅）が８００ピクセルより小さいか否かが判定される。このような判定は、例えば、図４に示されるステップＳ５１において取得される「要求端末の画面サイズを示す情報」を用いて行われる。この判定が「Ｙｅｓ」の場合には、処理は、ステップＳ６７に進み、この判定が「Ｎｏ」の場合には、処理は、ステップＳ６８に進む。

ステップＳ６７：メモリ部５４に格納されている少なくとも１つのスタイルシート５５のうち、要求端末のタイプ＝スマートフォン、かつ、要求端末の画面サイズ（画面の幅）＝８００ピクセルという条件に対応するスタイルシートが選択される。このスタイルシートは、要求端末のタイプ＝スマートフォン、かつ、要求端末の画面サイズ（画面の幅）＝
８００ピクセルという条件に適合するように予め設計されている。このスタイルシートが選択された後、処理は終了する。

ステップＳ６８：メモリ部５４に格納されている少なくとも１つのスタイルシート５５のうち、要求端末のタイプ＝スマートフォン、かつ、要求端末の画面サイズ（画面の幅）＝１０２４ピクセルという条件に対応するスタイルシートが選択される。このスタイルシートは、要求端末のタイプ＝スマートフォン、かつ、要求端末の画面サイズ（画面の幅）＝１０２４ピクセルという条件に適合するように予め設計されている。このスタイルシートが選択された後、処理は終了する。

ステップＳ６９：要求端末のタイプがタブレット型の端末であるか否かが判定される。このような判定は、例えば、図４に示されるステップＳ４３、Ｓ４６、Ｓ４８において取得される「要求端末のタイプを示す情報」を用いて行われる。この判定が「Ｙｅｓ」の場合には、処理は、ステップＳ７２に進み、この判定が「Ｎｏ」の場合には、処理は、ステップＳ７９に進む。

ステップＳ７２〜ステップＳ７８：ステップＳ７２〜ステップＳ７８の内容は、上述したステップＳ６２〜ステップＳ６８の内容と同様である。従って、ここでは、詳しい説明を省略する。

ステップＳ７９：要求端末のタイプがパーソナルコンピュータ（ＰＣ）であると判定される。なお、図５に示される例では、要求端末のタイプが、スマートフォンではなく、かつ、タブレット型の端末でない場合には、すべて、要求端末のタイプがパーソナルコンピュータ（ＰＣ）であると判定される。この場合には、メモリ部５４に格納されている少なくとも１つのスタイルシート５５のうち、要求端末のタイプ＝パーソナルコンピュータ（ＰＣ）、かつ、要求端末の画面サイズ（画面の幅）＝１０２４ピクセルという条件に対応するスタイルシートが選択される。このスタイルシートは、要求端末のタイプ＝パーソナルコンピュータ（ＰＣ）、かつ、要求端末の画面サイズ（画面の幅）＝１０２４ピクセルという条件に適合するように予め設計されている。このスタイルシートが選択された後、処理は終了する。

このように、マルチデバイスに共通のコンテンツを生成する処理とは切り離して、デバイスのタイプおよび／またはデバイスの画面サイズごとにそのデバイスのタイプおよび画面サイズに適合するように設計されたスタイルシートを用意することにより、マルチデバイスに対応したシステムの開発を行う場合でもデバイスごとに開発を行う必要がない。これにより、マルチデバイスに対応したシステムの開発を行う場合にそのシステムの開発期間を短縮し、開発コストを低減することができる。

図６は、フロントシステム５０（すなわち、フロントシステム５０のプロセッサ部５３）によって実行される処理の手順の他の一例を示す。この処理は、図３に示される処理の変形例である。

以下、図６に示される処理を各ステップごとに説明する。

ステップＳ３１’：フロントシステム５０は、要求端末からの要求をインターネット６０を介して受信する。

ステップＳ３２’：フロントシステム５０は、「要求端末の画面サイズを示す情報」を取得する。

ステップＳ３３’：フロントシステム５０は、ステップＳ３２’において取得された「要求端末の画面サイズを示す情報」に少なくとも基づいて、メモリ部５４に格納されている少なくとも１つのスタイルシート５５のうちのスタイルシートを選択する。

ステップＳ３７’：フロントシステム５０は、ステップＳ３３’において選択されたスタイルシートをインターネット６０を介して要求端末に送信する。あるいは、ステップＳ３７’において、フロントシステム５０は、ステップＳ３３’において選択されたスタイルシートとコンテンツ（例えば、ＨＴＭＬコンテンツ）とに基づいてコンテンツを合成し、その合成されたコンテンツを要求端末に送信するようにしてもよい。このように合成されたコンテンツは、例えば、ＨＴＭＬコンテンツである。いずれの場合でも、スタイルシートに基づく情報が、要求端末に送信されることになる。スタイルシートに基づく情報は、スタイルシートそのものであってもよいし、スタイルシートとコンテンツとに基づいて合成されたコンテンツであってもよい。スタイルシートに基づく情報は、スタイルシートに基づく限り、任意の情報であり得る。

このように、図６に示されるフロントシステム５０によって実行される処理の手順によれば、要求端末は、フロントシステム５０から、インターネット６０を介して、スタイルシートに基づく情報を受信し、スタイルシートによって定義された表示形式に従って、コンテンツ（例えば、ＨＴＭＬコンテンツ）を要求端末のディスプレイに表示する。これにより、コンテンツを要求端末の画面サイズに適切な表示形式で要求端末のディスプレイに表示することが可能である。

なお、図３に示される処理において、図３に示されるステップＳ３２を図６に示されるステップＳ３２’に置換し、かつ、図３に示されるステップＳ３３を図６に示されるステップＳ３３’に置換することも可能である。

図７は、図６に示されるステップＳ３２’の処理の手順の一例を示す。この処理は、図４に示される処理の変形例である。

ステップＳ４１’：要求端末のユーザ・エージェント情報が認識される。ここで、ユーザ・エージェント情報とは、ユーザのブラウザの種類やオペレーティングシステム（ＯＳ）などを示す情報である。

ステップＳ４２’：要求端末のタイプがスマートフォンであるか否かが判定される。このような判定は、ステップＳ４１’において認識された要求端末のユーザ・エージェント情報を用いて行われる。この判定が「Ｙｅｓ」の場合には、処理は、ステップＳ４４’に進み、この判定が「Ｎｏ」の場合には、処理は、ステップＳ４５’に進む。

ステップＳ４４’：スマートフォン用のスクリプト（例えば、ＪａｖａＳｃｒｉｐｔ（登録商標））が選択される。

ステップＳ４５’：要求端末のタイプがタブレット型の端末であるか否かが判定される。このような判定は、ステップＳ４１’において認識された要求端末のユーザ・エージェント情報を用いて行われる。この判定が「Ｙｅｓ」の場合には、処理は、ステップＳ４７’に進み、この判定が「Ｎｏ」の場合には、処理は、ステップＳ４９’に進む。

ステップＳ４７’：タブレット型の端末用のスクリプト（例えば、ＪａｖａＳｃｒｉｐｔ（登録商標））が選択される。

ステップＳ４９’：パーソナルコンピュータ（ＰＣ）用のスクリプト（例えば、Ｊａｖ
ａＳｃｒｉｐｔ（登録商標））が選択される。

ステップＳ５０’：選択されたスクリプトが、インターネット６０を介して、要求端末に送信される。

ステップＳ５１’：要求端末から、インターネット６０を介して、要求端末の画面サイズを示す情報が受信される。このようにして、「要求端末の画面サイズを示す情報」が取得される。

このように、図７に示される処理を実行することにより、「要求端末の画面サイズを示す情報」が取得される。従って、図７に示される処理は、図６のステップＳ３２’の処理に相当する処理であるということができる。

図８は、図６に示されるステップＳ３３’の処理の手順の一例を示す。この処理は、図５に示される処理の変形例である。

以下、図８に示される処理を各ステップごとに説明する。

ステップＳ６２’：要求端末の画面サイズ（画面の幅）が３２０ピクセルより小さいか否かが判定される。このような判定は、例えば、図７に示されるステップＳ５１’において取得される「要求端末の画面サイズを示す情報」を用いて行われる。この判定が「Ｙｅｓ」の場合には、処理は、ステップＳ６３’に進み、この判定が「Ｎｏ」の場合には、処理は、ステップＳ６４’に進む。

ステップＳ６３’：メモリ部５４に格納されている少なくとも１つのスタイルシート５５のうち、要求端末の画面サイズ（画面の幅）＝３２０ピクセルという条件に対応するスタイルシートが選択される。このスタイルシートは、要求端末の画面サイズ（画面の幅）＝３２０ピクセルという条件に適合するように予め設計されている。このスタイルシートが選択された後、処理は終了する。

ステップＳ６４’：要求端末の画面サイズ（画面の幅）が４８０ピクセルより小さいか否かが判定される。このような判定は、例えば、図７に示されるステップＳ５１’において取得される「要求端末の画面サイズを示す情報」を用いて行われる。この判定が「Ｙｅｓ」の場合には、処理は、ステップＳ６５’に進み、この判定が「Ｎｏ」の場合には、処理は、ステップＳ６６’に進む。

ステップＳ６５’：メモリ部５４に格納されている少なくとも１つのスタイルシート５５のうち、要求端末の画面サイズ（画面の幅）＝４８０ピクセルという条件に対応するスタイルシートが選択される。このスタイルシートは、要求端末の画面サイズ（画面の幅）＝４８０ピクセルという条件に適合するように予め設計されている。このスタイルシートが選択された後、処理は終了する。

ステップＳ６６’：要求端末の画面サイズ（画面の幅）が８００ピクセルより小さいか否かが判定される。このような判定は、例えば、図７に示されるステップＳ５１’において取得される「要求端末の画面サイズを示す情報」を用いて行われる。この判定が「Ｙｅ
ｓ」の場合には、処理は、ステップＳ６７’に進み、この判定が「Ｎｏ」の場合には、処理は、ステップＳ６８’に進む。

ステップＳ６７’：メモリ部５４に格納されている少なくとも１つのスタイルシート５５のうち、要求端末の画面サイズ（画面の幅）＝８００ピクセルという条件に対応するスタイルシートが選択される。このスタイルシートは、要求端末の画面サイズ（画面の幅）＝８００ピクセルという条件に適合するように予め設計されている。このスタイルシートが選択された後、処理は終了する。

ステップＳ６８’：メモリ部５４に格納されている少なくとも１つのスタイルシート５５のうち、要求端末の画面サイズ（画面の幅）＝１０２４ピクセルという条件に対応するスタイルシートが選択される。このスタイルシートは、要求端末の画面サイズ（画面の幅）＝１０２４ピクセルという条件に適合するように予め設計されている。このスタイルシートが選択された後、処理は終了する。

このように、コンテンツを生成する処理とは切り離して、デバイスの画面サイズごとにそのデバイスの画面サイズに適合するように設計されたスタイルシートを用意することにより、マルチデバイスに対応したシステムの開発を行う場合でもデバイスごとに開発を行う必要がない。これにより、マルチデバイスに対応したシステムの開発を行う場合にそのシステムの開発期間を短縮し、開発コストを低減することができる。

さらに、マルチデバイスとしての複数の端末のうちスマートフォン用のスタイルシートを最初に設計し、その後、スマートフォン用に設計されたスタイルシートに基づいて、複数の端末のうちスマートフォン以外の端末用のスタイルシートを設計することが好ましい。このようにスタイルシートを設計することにより、スタイルシートの設計に要する時間を大幅に短縮することができる。例えば、スマートフォン用のスタイルシートを最初に設計し、その後、スマートフォン用に設計されたスタイルシートの一部を修正することにより、パーソナルコンピュータ（ＰＣ）用のスタイルシートを設計することは容易である。その理由は、少なくとも、以下の（１）〜（３）に示すとおりである。

（１）スマートフォン用の画面は、画面サイズが小さいため、スマートフォン用の画面に表示される情報量が最小化されている。例えば、金融取引法で対応が求められる顧客説明に関する標記が最小限で充足している。このような画面サイズが小さいスマートフォン用の画面を画面サイズが大きいパーソナルコンピュータ（ＰＣ）用の画面に転用することは容易である。逆に、画面サイズが大きいパーソナルコンピュータ（ＰＣ）用の画面を画面サイズが小さいスマートフォン用の画面に転用することは困難である。

（２）スマートフォン用の画面は、画面スクロールが容易であることから、縦に長い画面となる。このように縦に長いスマートフォン用の画面を分割し横並びで配置することにより、スマートフォン用の画面をパーソナルコンピュータ（ＰＣ）用の画面に転用することは容易である。逆に、パーソナルコンピュータ（ＰＣ）用の画面をスマートフォン用の画面に転用することは困難である。例えば、パーソナルコンピュータ（ＰＣ）用の画面においてメニュー構成をタブ形式で表現している場合、そのような画面をスマートフォン用の画面に転用することは困難である。

（３）スマートフォン用の画面は、画面をタッチすることにより、次の動作へ遷移するように設計される。このため、スマートフォン用の画面には、タッチされることが可能な操作用の領域が確保されている。これに対し、パーソナルコンピュータ（ＰＣ）用の画面は、マウス操作を前提として設計される。このため、パーソナルコンピュータ（ＰＣ）用の画面には、タッチされることが可能な操作用の領域が確保されているとは限らない。従
って、パーソナルコンピュータ（ＰＣ）用の画面をスマートフォン用の画面に転用するよりも、スマートフォン用の画面をパーソナルコンピュータ（ＰＣ）用の画面に転用する方が容易であるといえる。

あるいは、マルチデバイスとしての複数の端末のうち最小の画面サイズを有する端末用のスタイルシートを最初に設計し、その後、最小の画面サイズを有する端末用に設計されたスタイルシートに基づいて、複数の端末のうち最小の画面サイズを有する端末以外の端末用のスタイルシートを設計するようにしてもよい。このようにスタイルシートを設計することにより、スタイルシートの設計に要する時間を大幅に短縮することができる。なぜなら、最小の画面サイズを有する端末用のスタイルシートを設計する際の設計の制約が最も大きいため、いったん最小の画面サイズを有する端末用のスタイルシートの設計が完了すれば、その後、最小の画面サイズを有する端末用に設計されたスタイルシートの一部を修正することにより、複数の端末のうち最小の画面サイズを有する端末以外の端末用のスタイルシートを設計することは容易であるからである。

銀行業界では、伝統的に、パーソナルコンピュータ（ＰＣ）を中心としてアプリケーションの開発が行われてきた。なぜなら、銀行業界では、スマートフォンをパーソナルコンピュータ（ＰＣ）を補完するための補完チャネルとして捉える考え方がきわめて根強かったからである。すなわち、銀行システムの開発は、あくまで、パーソナルコンピュータ（ＰＣ）用のアプリケーションの開発が主流であり、傍流である携帯電話やスマートフォン用のアプリケーションの開発は、主流であるパーソナルコンピュータ（ＰＣ）用のアプリケーションの開発とは別個に行われてきた。銀行業界において、スマートフォンを補完チャネルではなくメインチャネルとして位置づけて銀行サービスを設計しているのは「じぶん銀行」だけなのである。「じぶん銀行」では、口座開設から取引に至るまでスマートフォン以外に必要なものはない。この点で、「じぶん銀行」による銀行システムの開発ポリシーは他社による銀行システムの開発ポリシーとは根本的に異なっているといえる。

４．ミラートレードのシグナル通知サービス
「ミラートレード」とは、ＦＸ（店頭外国為替証拠金取引）や証券取引などにおいて、利益を出している投資家の取引の手口を知り、同じタイミングで同種の取引を行うことをいう。ミラートレードの一歩手前で、ミラー取引対象者の投資家が取引を行ったタイミングで手口についての情報を受けることをシグナル通知という。

銀行システム１は、ミラートレードのシグナル通知サービスを提供する。このサービスは、ミラー取引対象者が所定の取引（例えば、外貨預金取引）を行う度にミラー取引申請者にシグナル通知が届くことを可能にする。このサービスは、初心者が為替変動で利鞘を稼ぐ知人の手口を参考にしたい場合などに有用である。このサービスは、携帯端末の携帯電話番号を口座番号の代わりに用いる銀行サービスの一例である。

図９は、マルチデバイスに対応した銀行システム１の構成の他の一例を示す。図９に示される例では、銀行システム１は、顧客データベース７０と、ミラー取引データベース８０とをさらに含む。顧客データベース７０およびミラー取引データベース８０は、フロントシステム５０（特に、フロントシステム５０のプロセッサ部５３）に接続されている。顧客データベース７０は、銀行の顧客の個人情報などを維持するためのデータベースである。ミラー取引データベース８０は、ミラー取引対象者の取引履歴などを維持するためのデータベースである。銀行システム１内の他の構成要素は、図１に示される銀行システム１の構成要素と同様であるので、ここではその説明を省略する。なお、図９に示される例では、本発明の実施形態をマルチデバイスに対応した銀行システム１への適用を例にとり説明するが、本発明はこれに限定されない。本発明は、マルチデバイスに対応していない
銀行システムに適用することも可能である。

以下、図１０、図１１を参照して、ミラー取引申請者がミラー取引対象者の携帯端末の携帯電話番号を指定してシグナル通知の申請を行い、ミラー取引対象者がミラー取引申請者に対するシグナル通知を承認した場合には、ミラー取引対象者が所定の取引（例えば、外貨預金取引）を行う度にミラー取引申請者にシグナル通知が届くことを可能にする実施形態を説明する。

図１０は、ミラー取引申請者がシグナル通知の承認を受けるまでの銀行システム１の処理フローの概略を示す。以下、各ステップごとに説明する。

ステップＳ９１：ミラー取引申請者の携帯端末は、インターネット６０を介して、シグナル通知のためのリクエストをフロントシステム５０に送信する。ここで、シグナル通知のためのリクエストは、ミラー取引対象者の携帯端末の電話番号を含む。このようなシグナル通知のためのリクエストの送信は、例えば、ミラー取引申請者が自分の携帯端末の所定の画面（例えば、外貨預金取引のミラートレードのシグナル通知を申請するための画面）内にミラー取引対象者の携帯端末の電話番号（例えば、０９０−ＸＸＸＸ−ＸＸＸＸ）を入力し、その画面の送信ボタンにタッチすることによって行われる。

ステップＳ９３：フロントシステム５０は、ミラー取引申請者の携帯端末から受信されたシグナル通知のためのリクエストに含まれるミラー取引対象者の携帯端末の電話番号に基づいて顧客データベース７０を検索し、ミラー取引対象者を特定し、ミラー取引対象者を特定する情報を生成する。

ステップＳ９５：フロントシステム５０は、ミラー取引対象者を特定する情報に基づいて、メッセージを生成し、生成されたメッセージをインターネット６０を介してミラー取引対象者の携帯端末に送信する。その結果、ミラー取引対象者の携帯端末の画面には、フロントシステム５０から受信されたメッセージが表示される。そのメッセージは、例えば、「○○さんから外貨預金取引のミラートレードのシグナル通知のリクエストが届いています。承認しますか？」というメッセージである。

ステップＳ９６：ミラー取引対象者の携帯端末は、インターネット６０を介して、ミラー取引申請者からのシグナル通知のためのリクエストを承認するか否かを示す情報をフロントシステム５０に送信する。ミラー取引申請者からのシグナル通知のためのリクエストの承認は、例えば、ミラー取引対象者がフロントシステム５０から受信されたメッセージが表示された自分の携帯端末の画面内にある承認ボタンにタッチすることによって行われる。この場合には、ミラー取引申請者からのシグナル通知のためのリクエストを承認したことを示す情報がフロントシステム５０に送信される。

ステップＳ９７：フロントシステム５０は、ミラー取引対象者がミラー取引申請者からのシグナル通知のためのリクエストを承認したことを示す情報をフロントシステム５０内に蓄積する。このような情報の蓄積は、例えば、そのような情報をミラー取引データベース８０に格納することによって行われる。

ステップＳ９８：フロントシステム５０は、インターネット６０を介して、ミラー取引申請者の携帯端末にメッセージを送信する。その結果、ミラー取引申請者の携帯端末の画面には、フロントシステム５０から受信されたメッセージが表示される。そのメッセージは、例えば、「××さんが、あなたからの外貨預金取引のミラートレードのシグナル通知のリクエストを承認しました。」というメッセージである。

図１１は、ミラー取引対象者が所定の取引（例えば、外貨預金取引）を行った際にミラー取引申請者にシグナル通知を提供するための銀行システム１の処理フローの概略を示す。以下、各ステップごとに説明する。

ステップＳ１０１：ミラー取引対象者の携帯端末は、インターネット６０を介して、所定の取引（例えば、外貨預金取引）のためのリクエストをフロントシステム５０に送信する。以下の説明では、所定の取引が外貨預金取引である場合を例にとり説明するが、本発明はこの例示に限定されるわけではない。外貨預金取引以外の取引に本発明を適用することも可能である。外貨預金取引のためのリクエストは、通貨ペア（例えば、「米ドル」、「日本円」のペア）、売買の種別（例えば、「買い」）、取引金額（例えば、「＄１，０００，０００」）を含む。このような外貨預金取引のためのリクエストの送信は、例えば、ミラー取引対象者が自分の携帯端末の所定の画面（例えば、外貨預金取引のための画面）内に、通貨ペア（例えば、「米ドル」、「日本円」のペア）、売買の種別（例えば、「買い」）、取引金額（例えば、「＄１，０００，０００」）を入力し、その画面の送信ボタンにタッチすることによって行われる。

ステップＳ１０２：フロントシステム５０は、ミラー取引対象者の携帯端末から受信された外貨預金取引のためのリクエストを勘定系システム４０に送信する。

ステップＳ１０３：勘定系システム４０は、フロントシステム５０から受信された外貨預金取引のためのリクエストに応答して、外貨預金取引の処理を実行する。

ステップＳ１０４：勘定系システム４０は、外貨預金取引の処理結果をフロントシステム５０に送信する。

ステップＳ１０５：フロントシステム５０は、勘定系システム４０から外貨預金取引の処理結果を受信し、受信された外貨預金取引の処理結果に基づいてメッセージを生成し、生成されたメッセージをインターネット６０を介してミラー取引対象者の携帯端末に送信する。その結果、ミラー取引対象者の携帯端末の画面には、フロントシステム５０から受信されたメッセージが表示される。そのメッセージは、例えば、「ご依頼の外貨預金取引が完了しました。」というメッセージである。

ステップＳ１０６：フロントシステム５０は、シグナル通知のためのメッセージを生成し、生成されたメッセージをインターネット６０を介してミラー取引申請者の携帯端末に送信する。このようなメッセージの送信は、例えば、プッシュ通知機能などを用いてシグナル配信によって行われる。その結果、ミラー取引申請者の携帯端末の画面には、フロントシステム５０から受信されたメッセージが表示される。そのメッセージは、例えば、「××さんが、外貨預金で以下の取引をしました。２０１３年○月○日通貨ペア：米ドル、日本円、売買の種別：買い」というメッセージである。

なお、上述したシグナル通知の例では、ミラー取引申請者には、ミラー取引対象者の取引金額は通知しないこととしたが、ミラー取引対象者の承認が得られる場合には、ミラー取引対象者の取引金額もミラー取引申請者に通知するようにしてもよい。

次に、図１２、図１３を参照して、ミラー取引対象者を匿名とし、ミラー取引申請者がシグナル通知の申請を行う際にミラー取引対象者の個別の承認を得ることなく、所定の条件を満たす取引者の取引を模倣することを可能にする実施形態を説明する。

図１２は、ミラー取引申請者がシグナル通知のための登録をするまでの銀行システム１の処理フローの概略を示す。以下、各ステップごとに説明する。

ステップＳ１１２：ミラー取引申請者の携帯端末は、インターネット６０を介して、シグナル通知のためのリクエストをフロントシステム５０に送信する。ここで、シグナル通知のためのリクエストは、ミラー取引対象者の条件を含む。ミラー取引対象者の条件とは、ミラー取引申請者が取引を模倣することを希望する取引者を絞り込むための条件である。ミラー取引対象者の条件は、例えば、「対象期間内における収益率の高い上位３名の取引者」という条件である。あるいは、ミラー取引対象者の条件は、「対象期間内における収益率が１０％以上の取引者」という条件であってもよい。ミラー取引対象者の条件は、任意の条件であり得る。このようなシグナル通知のためのリクエストの送信は、例えば、ミラー取引申請者が自分の携帯端末の所定の画面（例えば、外貨預金取引のミラートレードのシグナル通知を申請するための画面）内にミラー取引対象者の条件（例えば、対象期間、収益率が上位の取引者の人数、収益率の水準など）を入力し、その画面の送信ボタンにタッチすることによって行われる。対象期間は、例えば、過去１週間、過去１か月、過去１年などの期間であるが、任意の期間であり得る。

ステップＳ１１３：フロントシステム５０は、ミラー取引申請者の携帯端末から受信されたシグナル通知のためのリクエストに含まれるミラー取引対象者の条件に基づいてミラー取引データベース８０を検索し、ミラー取引対象者の条件を満たす取引者をミラー取引対象者として特定し、特定されたミラー取引対象者を登録する。このような登録は、例えば、ミラー取引データベース８０において、ミラー取引対象者とミラー取引申請者とを関連付けることによって行われる。

ミラー取引データベース８０には、例えば、ミラー取引対象者識別子と、ミラー取引許諾の有無フラグと、取引明細（例えば、取引日時、通過ペア、取引金額、為替レート、売買の種別）とを含む。取引明細は、例えば、レコードの形式でミラー取引データベース８０に格納され得る。

ミラー取引対象者識別子は、ミラー取引対象者を識別するための識別子である。ミラー取引対象者識別子は、顧客データベース７０の顧客識別子（すなわち、顧客を識別するための識別子）に関連付けられている。ミラー取引許諾の有無フラグは、顧客がミラー取引対象者となることを許諾しているか否かを示すフラグである。銀行は、ミラー取引対象者となることを許諾するか否かを予め顧客に問い合わせ、その問い合わせ結果をミラー取引許諾の有無フラグに反映させる。例えば、ミラー取引許諾の有無フラグの値が「１」であることは、顧客がミラー取引対象者となることを許諾していることを示し、ミラー取引許諾の有無フラグの値が「０」であることは、顧客がミラー取引対象者となることを許諾していないことを示す。取引明細は、実際に行われた取引の履歴を示す。取引明細は、その取引を実際に行った取引者の識別子（すなわち、ミラー取引対象者識別子）に関連付けられている。取引明細は、例えば、ミラー取引対象者識別子ｘｘｘを有する者が、２０１３年○月○日に、米ドル日本円の通貨ペアで、為替レートが９９円／ドルで、＄１，０００，０００の買い取引をしたことを示す。

ここで、ミラー取引対象者識別子ｘｘｘを有する者が、２０１３年○月○日に、米ドル日本円の通貨ペアで、為替レートが９９円／ドルで、＄１，０００，０００の買い取引をし、その後、ミラー取引対象者識別子ｘｘｘを有する同じ者が、２０１３年△月△日に、米ドル日本円の通貨ペアで、為替レートが１００円／ドルで、＄１，０００，０００の売り取引をしたとする。この場合、この売買取引における収益率は、（（１００−９９）×１，０００，０００／９９×１，０００，０００）＝１／９９である。対象期間内にこの売買取引のみがあった場合には、ミラー取引対象者識別子ｘｘｘを有する者の収益率は、１／９９ということになる。なお、対象期間内に、買い取引があったが売り取引がなかった場合には、対象期間の終了時の実勢レートでこの取引の収益率を評価することが可能で
ある。

フロントシステム５０は、ミラー取引データベース８０に格納されている各取引明細を参照して、ミラー取引申請者によって指定された対象期間内におけるミラー取引対象者識別子ごとの収益率を計算し、ミラー取引対象者の条件を満たすミラー取引対象者識別子を特定する。フロントシステム５０は、この特定されたミラー取引対象者識別子と、顧客データベース７０に格納されているミラー取引申請者の顧客識別子とを関連付ける。これにより、ミラー取引対象者とミラー取引申請者とを関連付けることが可能である。この関連付けにより、シグナル通知のための登録手続が完了する。

なお、ミラー取引対象者の条件を満たす取引者の一覧をミラー取引申請者の携帯端末の画面に表示するようにして、ミラー取引申請者が、ミラー取引対象者の条件を満たす取引者の中から、ミラー取引対象者を選択することができるようにしてもよい。例えば、ミラー取引申請者の携帯端末の画面に、「外貨預金９月の収益率ランキング１位Ａさんユーロに強い！２位Ｂさん８月に続き２位！３位Ｃさん米ドルに強い！」というようにコメント付きで収益率が高い３名を表示するようにしてもよい。この場合、ミラー取引申請者は、そのコメントを参考にしてミラー取引対象者を選択することが可能になる。ここで、Ａさん、Ｂさん、Ｃさんは匿名（例えば、ハンドルネームや識別子）である。

図１３は、ミラー取引対象者が所定の取引（例えば、外貨預金取引）を行った際にミラー取引申請者にシグナル通知を提供するための銀行システム１の処理フローの概略を示す。以下、各ステップごとに説明する。

ステップＳ１２１：ミラー取引対象者の携帯端末は、インターネット６０を介して、所定の取引（例えば、外貨預金取引）のためのリクエストをフロントシステム５０に送信する。以下の説明では、所定の取引が外貨預金取引である場合を例にとり説明するが、本発明はこの例示に限定されるわけではない。外貨預金取引以外の取引に本発明を適用することも可能である。外貨預金取引のためのリクエストは、通貨ペア（例えば、「米ドル」、「日本円」のペア）、売買の種別（例えば、「買い」）、取引金額（例えば、「＄１，０００，０００」）を含む。このような外貨預金取引のためのリクエストの送信は、例えば、ミラー取引対象者が自分の携帯端末の所定の画面（例えば、外貨預金取引のための画面）内に、通貨ペア（例えば、「米ドル」、「日本円」のペア）、売買の種別（例えば、「買い」）、取引金額（例えば、「＄１，０００，０００」）を入力し、その画面の送信ボタンにタッチすることによって行われる。

ステップＳ１２２：フロントシステム５０は、ミラー取引対象者の携帯端末から受信された外貨預金取引のためのリクエストを勘定系システム４０に送信する。

ステップＳ１２３：勘定系システム４０は、フロントシステム５０から受信された外貨預金取引のためのリクエストに応答して、外貨預金取引の処理を実行する。

ステップＳ１２４：勘定系システム４０は、外貨預金取引の処理結果をフロントシステム５０に送信する。

ステップＳ１２５：フロントシステム５０は、勘定系システム４０から外貨預金取引の処理結果を受信し、受信された外貨預金取引の処理結果に基づいてメッセージを生成し、生成されたメッセージをインターネット６０を介してミラー取引対象者の携帯端末に送信する。その結果、ミラー取引対象者の携帯端末の画面には、フロントシステム５０から受信されたメッセージが表示される。そのメッセージは、例えば、「ご依頼の外貨預金取引
が完了しました。」というメッセージである。

ステップＳ１２６：フロントシステム５０は、シグナル通知のためのメッセージを生成し、生成されたメッセージをインターネット６０を介してミラー取引申請者の携帯端末に送信する。このようなメッセージの送信は、例えば、プッシュ通知機能などを用いてシグナル配信によって行われる。その結果、ミラー取引申請者の携帯端末の画面には、フロントシステム５０から受信されたメッセージが表示される。そのメッセージは、例えば、「ミラー取引対象者（匿名）が、外貨預金で以下の取引をしました。２０１３年○月○日通貨ペア：米ドル、日本円、売買の種別：買い」というメッセージである。このようなメッセージは、登録されたミラー取引対象者に関連付けられているすべてのミラー取引申請者の携帯端末に送信される。

図１２、図１３に示される実施形態によれば、ミラー取引申請者は、ミラー取引対象者が実際に誰であるのかを知ることなく（従って、ミラー取引申請者がミラー取引対象者に対して個別の承認を得ることなく、ミラー取引対象者は匿名のままで）、ミラー取引対象者の条件を満たす仮想的な取引者の取引を模倣するための情報を即時的に取得することが可能である。仮想的な取引者は、１人であっても複数人であってもよく、対象期間によって異なるミラー取引対象者識別子によって識別される取引者であってもよい。なお、ミラー取引対象者となることを許諾していない者は、このような仮想的な取引者となることはない。これにより、銀行システム１は、ミラー取引対象者の個人情報を保護しつつ、ミラー取引申請者に対してミラートレードのシグナル通知サービスを提供することが可能である。

以上のように、本発明の好ましい実施形態を用いて本発明を例示してきたが、本発明は、この実施形態に限定して解釈されるべきものではない。本発明は、特許請求の範囲によってのみその範囲が解釈されるべきであることが理解される。当業者は、本発明の具体的な好ましい実施形態の記載から、本発明の記載および技術常識に基づいて等価な範囲を実施することができることが理解される。

本発明は、マルチデバイスに対応したシステムの開発を行う場合にそのシステムの開発期間を短縮し開発コストを低減することを可能にする装置、その装置において実行される方法およびプログラムを提供するものとして有用である。

１銀行システム
１０_１、１０_２、・・・１０_Ｎ端末
２０_１、２０_２、・・・２０_Ｎブラウザ
３０口座情報データベース
４０勘定系システム
５０フロントシステム
５１ブラウザ共通インターフェース部
５２勘定系システムインターフェース部
５３プロセッサ部
５４メモリ部
５５スタイルシート
６０インターネット
７０顧客データベース
８０ミラー取引データベース

Claims

マルチデバイスに対応したシステムにおいて用いられる装置であって、
前記装置は、ネットワークを介して、前記マルチデバイスとしての複数の端末のうちの少なくとも１つの端末に接続されるように構成され、
前記装置は、プロセッサ部とメモリ部とを含み、
前記メモリ部には、少なくとも１つのスタイルシートが予め格納されており、前記少なくとも１つのスタイルシートのそれぞれは、コンテンツの表示形式を定義するものであり、前記少なくとも１つのスタイルシートのそれぞれは、前記少なくとも１つの端末のうちの１つに対応し、
前記プロセッサ部は、
前記少なくとも１つの端末のうちの１つである要求端末からの任意の要求に対して、
前記要求を前記ネットワークを介して受信することと、
前記要求端末のタイプを示すタイプ情報と前記要求端末の画面サイズを示す画面サイズ情報とを取得することと、
前記タイプ情報と前記画面サイズ情報とに基づいて、前記少なくとも１つのスタイルシートのうちのスタイルシートを選択することと、
前記選択されたスタイルシートに基づく情報を前記ネットワークを介して前記要求端末に提供することと
を行うように構成されている、装置。
前記少なくとも１つのスタイルシートは、前記要求端末の画面にタッチされることが可能な操作用の領域が確保されているスタイルシートを含み、
前記少なくとも１つのスタイルシートのうちのスタイルシートを選択することは、前記タイプ情報と前記画面サイズ情報とに基づいて、前記少なくとも１つのスタイルシートのうち、前記要求端末の画面にタッチされることが可能な操作用の領域が確保されている前記スタイルシートを選択することを含む、請求項１に記載の装置。
前記プロセッサ部は、前記要求端末のユーザ・エージェント情報を認識することにより前記要求端末のタイプを判定し、前記要求端末のタイプに応じたスクリプトを、前記ネットワークを介して、前記要求端末に送信し、前記送信されたスクリプトを前記要求端末が実行することによって前記要求端末において取得された前記要求端末の画面サイズを示す画面サイズ情報を、前記ネットワークを介して、前記要求端末から受信することによって、前記要求端末の画面サイズを示す画面サイズ情報を取得するように構成されている、請求項１または請求項２に記載の装置。
前記プロセッサ部は、前記受信された要求に対して実行される処理の結果を表す応答に対応する前記マルチデバイスに共通のコンテンツを生成するようにさらに構成されており、
前記プロセッサ部は、前記選択されたスタイルシートと前記生成されたコンテンツとに基づく情報を前記ネットワークを介して前記要求端末に提供する、請求項１〜３のいずれか一項に記載の装置。