JP2015082135A - 画面表示システム - Google Patents

Abstract

【課題】画面遷移上の各画面の表示内容に係るデータについて可能なものはキャッシュしておくとともに、画面表示のためにＷｅｂサーバとの間で通信されるメッセージを圧縮することで、Ｗｅｂサーバおよびネットワークに対する負荷を低減させる。【解決手段】営業支援端末３０からの営業支援サーバ１０へのアクセスに基づいて、営業支援サーバ１０により提供される１つ以上の支援サービス１７によって取得された情報を営業支援端末３０において複数の画面に表示する画面表示システム１であって、営業支援端末３０は、表示された所定の画面の表示内容に係るデータをキャッシュ３６に保持し、画面を表示もしくは切り替える際に、表示対象の各画面の表示内容に係るデータがキャッシュ３６に保持されている場合に、キャッシュ３６に保持されている当該画面の表示内容に係るデータに基づいて当該画面を表示する画面制御部３４を有する。【選択図】図１

Description

本発明は、営業担当者の営業活動を支援する技術に関し、特に、証券会社等の金融機関における営業活動を支援する画面表示システムに適用して有効な技術に関するものである。

例えば、証券会社等の金融機関では、営業担当者の営業活動に際して、ＣＲＭ（Customer Relationship Management：顧客関係管理）システム等を用いて顧客情報を管理するとともに、営業担当者が営業活動に携行するタブレット端末などの携帯型端末も含む情報処理端末（以下では、このような情報処理端末を「営業支援端末」と記載する場合がある）によって顧客情報や営業活動情報、営業資料等を参照可能としたり、営業実績を記録したり等の処理を行うＳＦＡ（Sales Force Automation：営業支援システム）が活用され、営業活動の効率化が図られている。

このような分野での技術として、例えば、特開２０１１−１９８０６１号公報（特許文献１）には、顧客基本属性情報及び営業推進情報を格納する第１格納部と、イベント情報及び顧客特性情報を格納する第２格納部と、イベント情報に基づいて、第１格納部に格納された顧客基本属性情報と営業推進情報とを対応付けるタイミングを判別して、タイミング時に、双方の情報の対応付けを実行するとともに、第２格納部に格納された顧客特性情報に応じて、顧客に対する営業推進情報の提供の可否を判別する最適化部と、第１格納部に格納された顧客基本属性情報に基づいて画面情報を生成して、接続端末に提供する提供部とを有するシステムが記載されている。前記提供部は、最適化部によって、営業推進情報の提供が可と判別された顧客に対して、顧客基本属性情報に対応付けられた営業推進情報に基づいて画面情報を生成して、接続端末に提供することで、営業推進情報の提供の可否を好適なタイミングで判定して、可と判定された顧客に営業推進情報を提供する。

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

上述したような技術では、営業活動の便宜のために、一度に複数の顧客の情報を参照したり、他の営業担当者も含む組織としての営業活動情報を参照したりする場合がある。このとき、各種の情報を効率よく参照可能とするため、顧客毎などのタブに情報を分類して画面上に表示するユーザインタフェースが採用される場合がある。さらに、特定の顧客内での各種の情報についても、これらを効率よく参照可能とするため、例えば、項目の種類やカテゴリなどの単位でタブに分類して表示する。これにより、表示対象の多数の情報を整理・分類するとともに、目的のデータに容易に到達できるようなユーザインタフェースとすることができる。

ここで、営業支援端末を利用してＷｅｂサーバ等のサーバにアクセスして必要な情報を取得してくる場合、情報を画面上に表示させるには、営業支援端末上に有するＷｅｂブラウザによりＷｅｂサーバにアクセスし、Ｗｅｂサーバ側において、アプリケーションプログラムにより必要な情報を取得して、これらを画面表示するＨＴＭＬ（HyperText Markup Language）データを生成して営業支援端末に応答し、Ｗｅｂブラウザにより画面上に表示させるというのが一般的である。

このとき、上記のようなタブを活用したユーザインタフェースを採用する場合、複数のタブの切り替えにより大量の情報を画面表示することができるが、タブを切り替える毎にＷｅｂサーバに対して画面表示のためのアクセスが発生し、ネットワークやＷｅｂサーバに対して過大な負荷がかかる状態となる。タブの場合、切り替え操作が容易であることから、無駄もしくは不用意なタブの切り替え操作も多く発生し得る。このような操作を複数の営業担当者が同時並行的に行うと、タブによる画面切り替えの際に遅延が生じ、円滑な営業活動に支障をきたす場合も生じ得る。

そこで本発明の目的は、営業支援端末において、画面遷移上の各画面の表示内容に係るデータについて可能なものはキャッシュしておくとともに、画面表示のためにＷｅｂサーバとの間で通信されるメッセージを圧縮することで、Ｗｅｂサーバおよびネットワークに対する負荷を低減させる画面表示システムを提供することにある。

本発明の前記ならびにその他の目的と新規な特徴は、本明細書の記述および添付図面から明らかになるであろう。

本願において開示される発明のうち、代表的なものの概要を簡単に説明すれば、以下のとおりである。

本発明の代表的な実施の形態による画面表示システムは、情報処理端末からのＷｅｂサーバへのアクセスに基づいて、前記Ｗｅｂサーバにより提供される１つ以上のサービスによって取得された情報を前記情報処理端末において複数の画面に表示する画面表示システムであって、前記情報処理端末は、表示された所定の画面の表示内容に係るデータをキャッシュに保持し、画面を表示もしくは切り替える際に、表示対象の各画面の表示内容に係るデータが前記キャッシュに保持されている場合に、前記キャッシュに保持されている当該画面の表示内容に係るデータに基づいて当該画面を表示する画面制御部を有するものである。

本願において開示される発明のうち、代表的なものによって得られる効果を簡単に説明すれば以下のとおりである。

すなわち、本発明の代表的な実施の形態によれば、営業支援端末において、画面遷移上の各画面の表示内容に係るデータについて可能なものはキャッシュしておくとともに、画面表示のためにＷｅｂサーバとの間で通信されるメッセージを圧縮することで、Ｗｅｂサーバおよびネットワークに対する負荷を低減させることが可能となる。

本発明の一実施の形態である画面表示システムの構成例について概要を示した図である。 本発明の一実施の形態における画面表示システムにより営業支援端末上に表示される画面例について概要を示した図である。 本発明の一実施の形態における画面表示システムにより営業支援端末上に表示される他の画面例について概要を示した図である。 本発明の一実施の形態における営業支援端末の画面制御部により画面表示を制御する処理の流れの例について概要を示したフローチャートである。 （ａ）〜（ｃ）は、本発明の一実施の形態における画面表示およびキャッシュの内容をリフレッシュする例について概要を示した図である。 本発明の一実施の形態における各営業支援端末あたりの通信量を一定の範囲に制限する仕組みの例について概要を示した図である。 本発明の一実施の形態における営業支援端末と画面表示システムとの間で授受されるメッセージを圧縮する仕組みの例について概要を示した図である。 本発明の一実施の形態における営業支援端末と画面表示システムとの間で授受されるメッセージを短縮化する仕組みの例について概要を示した図である。

以下、本発明の実施の形態を図面に基づいて詳細に説明する。なお、実施の形態を説明するための全図において、同一部には原則として同一の符号を付し、その繰り返しの説明は省略する。

本発明の一実施の形態である画面表示システムは、証券会社等の金融機関において、営業担当者の営業活動を支援するためのＣＲＭシステムやＳＦＡとしての機能を有する情報処理システムであり、顧客情報や営業活動情報を管理するとともに、営業担当者が営業支援端末によってこれを参照したり、さらには、営業活動に携行するタブレット端末などの携帯型端末によって顧客情報や営業資料等を持ち出して外出先においても参照可能としたり、営業実績を記録したり等の処理を行うことによって営業活動の効率化を図るシステムである。

本実施の形態では、営業支援端末上にタブを用いたユーザインタフェースにより顧客情報や営業活動情報、営業資料等の多数の情報を表示する際に、営業支援端末（クライアント）上で動作するアプリケーションのミドルウェアにより、各タブを含む画面遷移における各画面の表示内容に係るデータについて可能なものは営業支援端末上にキャッシュしておく。これにより、タブの切り替えなどによる画面遷移の際に、可能な画面もしくは画面内のパーツについては、キャッシュの内容に基づいて画面表示することで、Ｗｅｂサーバに対する不要なアクセスを回避して、Ｗｅｂサーバおよびネットワークの負荷を低減させることができる。

また、営業支援端末およびＷｅｂサーバ上で動作するアプリケーションのミドルウェアにより、営業支援端末とＷｅｂサーバとの間の通信について、各営業支援端末あたりの通信量を一定の範囲に制限するとともに、通信されるメッセージをアプリケーション（ミドルウェア）レベルで圧縮もしくは短縮化することで、ネットワークの負荷を低減させることができる。

＜システム構成＞
図１は、本発明の一実施の形態である画面表示システムの構成例について概要を示した図である。画面表示システム１は、営業支援サーバ１０と、これにインターネットやイントラネットなどのネットワーク２０を介して接続される、証券会社等の営業担当者が保有する情報処理端末である営業支援端末３０とを有する。

営業支援サーバ１０は、例えば、サーバ機器や、クラウドコンピューティングサービス上に構築された仮想サーバなどのサーバシステムにより構成され、図示しないＯＳ（Operating System）やＤＢＭＳ（DataBase Management System：データベース管理システム）、およびＷｅｂサーバプログラム１１などの基盤ソフトウェア上で稼働するソフトウェアプログラムによって実装される通信制御部１２や、営業担当者の営業活動を支援する各種のサービスを提供する業務アプリケーションプログラムである支援サービス１７などの各部を有する。

支援サービス１７は、必要に応じて営業支援端末３０の支援サービス３７と連携して営業活動を支援するサービスを提供するが、ここで提供されるサービスとしては、例えば、データベースやファイルなどからなる営業支援情報１８として保持された各種の顧客情報や営業情報を取得して営業支援端末３０上に表示させたり、営業支援端末３０を介して営業担当者の活動実績の登録を受け付けて記録したりなどが含まれる。営業支援サーバ１０は、上記の各部やテーブル以外にも図示しない構成を有していてもよく、全体として、証券会社等におけるＣＲＭやＳＦＡとしての各種機能やサービスを実現している。

通信制御部１２は、後述する営業支援端末３０の通信制御部３２と連携して、通信設定１３に設定された内容に従って、営業支援端末３０と営業支援サーバ１０との間で通信されるデータをアプリケーション（ミドルウェア）レベルで圧縮もしくは短縮化する機能を有する。処理内容の詳細については後述する。

営業支援端末３０は、例えば、ＰＣ（Personal Computer）等の情報処理端末からなる。ノート型ＰＣやタブレット端末などの携帯型端末であってもよい。営業支援端末３０は、図示しないＯＳ上で稼働するソフトウェアプログラムによって実装されるＷｅｂブラウザ３１や、通信制御部３２、画面制御部３４、および支援サービス３７などの各部を有する。

通信制御部３２、画面制御部３４、および支援サービス３７は、それぞれ、営業支援サーバ１０上に保持されているＨＴＭＬファイルやプログラムモジュールなどに基づいてクライアント側のＷｅｂブラウザ３１上で実行されるものである。支援サービス３７は、通信制御部３２や画面制御部３４の機能を利用しつつ、営業支援サーバ１０の支援サービス１７と連携して、営業担当者の営業活動を支援する各種機能やサービスを提供する。例えば、営業担当者が営業活動すべき顧客の情報を把握、参照したり、活動予定や訪問する営業先の情報を確認したり、営業活動の実績を登録して報告したりなどのサービスを提供する。

通信制御部３２は、営業支援サーバ１０の通信制御部１２と連携して、通信設定３３に設定された内容に従って、営業支援端末３０と営業支援サーバ１０との間で通信されるデータをアプリケーション（ミドルウェア）レベルで圧縮もしくは短縮化する機能を有する。処理内容の詳細については後述する。

画面制御部３４は、営業支援端末３０上にタブを用いたユーザインタフェースにより顧客情報や営業活動情報、営業資料等の多数の情報を表示させる際に、各タブを含む画面遷移における各画面の表示内容に係るデータについて可能なものはキャッシュ３６として保持しておくとともに、画面遷移における各画面のインスタンスのツリー構造を画面構造３５として保持しておく。これにより、タブの切り替えなどによる画面遷移の際に、画面構造３５およびキャッシュ３６の内容に基づいて、可能な場合にはキャッシュ３６からデータを取得して画面表示させる機能を有する。処理内容の詳細については後述する。

＜画面例＞
図２および図３は、営業担当者の営業活動を支援するために、営業支援サーバ１０により営業支援端末３０上に表示される画面例について概要を示した図である。営業支援端末３０上では、例えば、画面上部のタブにより、営業担当者単位での情報集約画面（“Dash board”タブ）と、顧客単位での情報集約画面（“Client360”タブ）を切り替えて表示することができる。図２では、“Dash board”タブの画面例を示しており、また、図３では、“Client360”タブの画面例を示している。

図２に示した“Dash board”タブでは、対象の営業担当者の営業活動全般を支援するための情報を複数のタブによって切り替え可能な画面で表示する。図２の例では、“サマリー”タブの画面例を示しており、サマリー情報として、例えば、各種のイベントが発生している顧客の件数や、該当する顧客のサマリー情報を一覧表示する“リード”欄、現在営業活動中の案件の内容や進捗状況の概要を一覧表示する“案件一覧”欄、営業担当者の活動状況をグラフ表示した“活動状況”欄、および営業担当者の営業日誌のサマリー情報を一覧表示する“営業日誌”欄などを表示している。また、“顧客一覧”や“案件一覧”、“営業日誌”などのタブでは、それぞれ、より詳細な内容を一覧表示する。

このような画面により、営業担当者は、自身が担当する複数の顧客に対する営業活動のために有用な情報の提供を受けたり、営業活動の予実を管理したりすることができる。また、特定の営業担当者についての情報に限らず、例えば、当該営業担当者がアクセス権を有する一定範囲の組織に属する他の営業担当者についての情報も、個別もしくはサマリーの情報として表示して参照可能としてもよい。

図３に示した“Client360”タブでは、検索等により選択された顧客、もしくは“Dash board”タブの画面において選択された特定の顧客についての営業活動を支援するための情報を複数のタブによって切り替え可能な画面として表示する。図３の例では、“サマリー”タブの画面例を示しており、サマリー情報として、例えば、対象の顧客の口座番号や氏名や住所等の基本的な属性情報を表示する“基本属性”欄、対象の顧客の保有資産のサマリー情報を一覧表示する“資産”欄、対象の顧客について発生しているイベントの概要を一覧表示する“リード”欄、対象の顧客について現在活動中の案件の概要を一覧表示する“案件一覧”欄、および対象の顧客に対する営業担当者の営業活動の履歴のサマリー情報を一覧表示する“接触履歴”欄などを表示している。また、“収集情報”や“預り資産”、“投資状況”などのタブでは、それぞれ、より詳細な内容を表示する。

このような画面により、営業担当者は、特定の顧客に対する営業活動のために有用な情報の提供を受けたり、当該顧客に係る詳細なデータを参照したりすることができる。

図２、図３の各画面例では、それぞれ、タブの選択により表示内容を切り替えることができ、また、各タブにおいても、複数種類のデータを表示するための欄が、リストや表などのパーツとして表示されている。このような画面を表示させる際、営業支援端末３０上のＷｅｂブラウザ３１からのリクエストに対して、営業支援サーバ１０側において、例えば、支援サービス１７により営業支援情報１８等から必要な情報を取得して、これらを画面表示するＨＴＭＬデータを生成して営業支援端末３０に応答し、Ｗｅｂブラウザ３１上に表示させるという従来の一般的な手法をとった場合、上述したように、タブの切り替えの度に営業支援サーバ１０やネットワーク２０に対して余計な負荷がかかってしまう。

そこで、本実施の形態では、上述したように、営業支援端末３０上で動作するアプリケーションのミドルウェアである画面制御部３４により、各タブを含む画面遷移における各画面の表示内容に係るデータについて可能なものはキャッシュ３６として保持しておくとともに、画面遷移における各画面のインスタンスのツリー構造を画面構造３５として保持しておく。これにより、タブの切り替えなどによる画面遷移の際に、画面構造３５およびキャッシュ３６の内容に基づいて、可能な場合にはキャッシュ３６からデータを取得して画面表示させることで、営業支援サーバ１０に対する不要なアクセスを回避して、営業支援サーバ１０およびネットワーク２０の負荷を低減させる。

本実施の形態では、画面制御部３４のようなミドルウェアを実装するために、営業支援端末３０上に表示する画面を、単純なＨＴＭＬのみによるのではなく、クライアントサイドで動作するモジュールにより実装するＲＩＡ（Rich Internet Applications）として実装する。例えば、Ａｄｏｂｅ（登録商標）社のＦｌａｓｈ（登録商標）およびこれを基盤としたフレームワークであるＦｌｅｘ（登録商標）や、Ｊａｖａ（登録商標）のアプレット、Ａｊａｘ（Asynchronous JavaScript + XML）などの技術を適宜利用することができる。画面制御部３４は、これらの技術を利用して、各画面に対して画面表示に係る共通の機能を提供するミドルウェアとして実装するものとする。

＜画面制御の処理の流れ＞
図４は、営業支援端末３０の画面制御部３４により、画面表示を制御する処理の流れの例について概要を示したフローチャートである。ここでは、タブの単位で画面を表示する際の処理の例について示す。

画面表示が行われるに際して、共通のミドルウェアである画面制御部３４が呼び出されると、画面制御部３４は、まず、画面構造３５を参照して、当該画面表示がタブの切り替えであるか否かを判定する（Ｓ０１）。すなわち、当該画面表示が既に画面上に表示されているタブ（非アクティブなタブも含む）に表示を切り替える旨の指示によるものか、別の支援サービス１７、３７に基づく新たな画面を新規タブとして表示する（タブを追加する）ものかを判定する。

画面構造３５には、既に表示されている画面のインスタンスのツリー構造が保持されているため、これを参照することで対象の画面が存在するか否か（既存の画面か否か）を判定することができる。なお、画面のインスタンスのツリー構造は、例えば、Ｆｌｅｘ（登録商標）などのフレームワークを用いることで容易に取得することができる。

ステップＳ０１でタブの切り替えでなはない、すなわち、新規タブの表示である場合は、後述のステップＳ０４に移る。一方、既存のタブへの切り替えである場合は、次に、切り替え先のタブに表示される画面内容がキャッシュの対象であるか否かを判定する（Ｓ０２）。

各画面がキャッシュされるタイプ（キャッシュタイプ）か、表示毎にサーバにアクセスして最新の内容で画面を生成する必要があるタイプ（オンラインタイプ）かを特定する情報は、例えば、画面に表示する情報の更新頻度等の性質などに応じて予め営業支援サーバ１０上に設定しておくことができる。この情報は、例えば、画面制御部３４が営業支援サーバ１０から予め取得して、画面構造３５の補助情報などとしてメモリ上などに保持していてもよいし、ステップＳ０２での判定の際に営業支援サーバ１０に都度問い合わせて取得してもよい。

ステップＳ０２でキャッシュの対象ではない場合は、後述のステップＳ０４に移る。一方、キャッシュの対象である場合は、次に、キャッシュ３６の内容を画面ＩＤなどをキーとして検索し、切り替え先のタブの画面内容がキャッシュ３６に保持されているか否かを判定する（Ｓ０３）。対象のタブの画面が前回表示されてから間隔が空いていると、データがキャッシュ３６から追い出されて保持されていない場合がある。

ステップＳ０３でキャッシュ３６に画面内容のデータがない場合、新規タブに新たに画面を表示するため、営業支援サーバ１０にアクセスして、対応する支援サービス１７により生成された画面内容のデータを取得する（Ｓ０４）。ステップＳ０１で新規タブの表示である場合、およびステップＳ０２で切り替え先のタブの画面がキャッシュの対象ではない場合も同様の処理となる。

その後、ステップＳ０４で取得した画面内容のデータに基づいて新規タブを画面表示する（Ｓ０５）。さらに、対象のタブのインスタンスの情報について、画面構造３５に保持するツリー構造に記録するとともに、対象のタブの画面内容のデータをキャッシュ３６に記録して（Ｓ０６）、処理を終了する。

一方、ステップＳ０３でキャッシュ３６に画面内容のデータがある場合は、キャッシュ３６から当該画面内容のデータを取得し（Ｓ０７）、対象のタブに画面を切り替えた上で取得したデータに基づいて画面内容を表示して（Ｓ０８）、処理を終了する。

以上のような処理により、タブを切り替える際には、キャッシュ３６に保持された画面内容のデータがある場合にはこれに基づいてタブの画面内容を表示することができ、営業支援サーバ１０に対して画面データを取得するための余計なアクセスを回避することができる。また、上記のような処理を、画面制御部３４という共通のミドルウェアで実行することで、各画面が個別に上記のような処理を実行する必要をなくし、処理を効率化することができるだけでなく、アプリケーションプログラムの開発を効率化することもできる。

なお、上記のような制御は、タブの切り替えにより画面を切り替えるユーザインタフェースに限らず、例えば、画面上のメニュー領域やメニューフレーム等において選択された内容に基づいて画面内容を切り替えるようなユーザインタフェースであっても用いることができる。

対象のタブに表示される画面がキャッシュの対象ではない場合、すなわち、常に最新の情報を表示する必要があるオンラインタイプの場合は、対象のタブに切り替えられる毎に都度最新の情報を営業支援サーバ１０から取得して表示する。一方、キャッシュタイプの場合は、キャッシュ３６に画面内容のデータがあればこれに基づいて画面内容が表示される。この場合、何らかのタイミングで画面内容およびキャッシュ３６の内容を最新の情報に更新する必要が生じる。例えば、所定の時間間隔の経過により、営業支援サーバ１０から最新の情報に基づく画面内容を取得して画面表示およびキャッシュ３６の内容をリフレッシュする処理を行うようにしてもよい。

また、営業担当者からの指示に基づいて画面表示およびキャッシュ３６の内容をリフレッシュするようにしてもよい。この場合、画面全体のリフレッシュに限らず、例えば、上記の図２や図３の例における“リード”欄や“案件一覧”欄など、画面内の特定のパーツ（表やリストなど）単位で、画面表示およびキャッシュ３６の内容をリフレッシュすることも可能である。

図５は、画面内のパーツの単位で画面表示およびキャッシュ３６の内容をリフレッシュする例について概要を示した図である。図５（ａ）は、検索条件を指定して検索ボタンを押下することで検索結果を一覧表示するタブの例を示している。この場合、検索結果が一覧表示される画面下段の網掛け部分の欄（パーツ）は、検索という処理の特性上、検索ボタンが押下された時点での最新の情報を表示する必要がある。従って、当該パーツに係る部分は、検索ボタンが押下されたタイミングでのみ、検索結果に基づいてリフレッシュすることになる。

図５（ｂ）は、画面内に複数の欄（パーツ）が表示されているタブの例を示している。ここでは、全ての欄（画面内の網掛け部分の欄）が、タブが切り替えられた場合にキャッシュ３６の内容に基づいて表示を行うキャッシュタイプのものであることを示している。この場合、リフレッシュによる最新情報への更新は、例えば、画面右上部に配置されたリフレッシュ（更新）ボタンが押下されたタイミングで行い、このタイミングで全ての欄の内容について画面表示およびキャッシュ３６の内容を一括してリフレッシュする。

図５（ｃ）は、画面内に複数の欄が表示されているタブの例であるが、図５（ｂ）の例と異なり、画面上段および下段の網掛け部分の欄のみがキャッシュタイプであり、画面中段の白抜き部分の欄は、当該タブに切り替えられて画面表示を行う都度、営業支援サーバ１０にアクセスして画面内容のデータを取得するオンラインタイプであることを示している。この場合は、キャッシュタイプの欄にのみリフレッシュボタンが配置され、それぞれが押下されたタイミングで対応する欄の内容について画面表示およびキャッシュ３６の内容を個別にリフレッシュする。

このように、画面内のパーツ単位で柔軟に画面表示およびキャッシュ３６の内容をリフレッシュできるようにすることで、営業支援端末３０から営業支援サーバ１０への余計なアクセスをより細かく低減させることが可能となる。

＜ネットワーク負荷の低減＞
通常のＷｅｂアプリケーションでは、各クライアント端末からＷｅｂサーバに対しては、アクセスするサービス毎に通信セッションが確立される。従って、上記のような営業支援サーバ１０および営業支援端末３０のように、営業支援端末３０上で多数のタブを開くことで同時に多数の支援サービス１７にアクセス可能な構成の場合には、通信セッションの数が多数となり、ネットワーク２０および営業支援サーバ１０に過大な負荷がかかるおそれがある。

そこで、本実施の形態では、営業支援端末３０および営業支援サーバ１０との間の通信について、各営業支援端末３０あたりの通信量を一定の範囲に制限するとともに、授受されるメッセージをアプリケーション（ミドルウェア）レベルで圧縮もしくは短縮化することで、ネットワーク２０の負荷を低減させる仕組みを有している。

図６は、各営業支援端末３０あたりの通信量を一定の範囲に制限する仕組みの例について概要を示した図である。図６の例では、営業支援端末３０上の各支援サービス３７が、営業支援サーバ１０上の対応する支援サービス１７との間で個別に通信セッションを確立するのではなく、営業支援端末３０の通信制御部３２を介して通信セッション２１の確立を行う。ここで、確立される通信セッション２１の数は、通信制御部３２により、予め定められた最大数（図６の例では６本）を超えないように制御される。

本実施の形態では、上記のような通信制御を実現するため、営業支援端末３０の通信制御部３２上にキュー３８を有しており、各支援サービス３７からのリクエストに係るメッセージはキュー３８に一旦キューイングされる構成とする。通信制御部３２は、通信セッション２１に空きがある場合には、キュー３８からメッセージを取り出して、通信セッション２１を介して営業支援サーバ１０に対して送信する。通信セッション２１に空きがない場合は、空くのを待ってキュー３８から取り出して送信する。

これにより、営業支援端末３０から発行されるリクエストの数を一定の範囲以下となるように制御し、ネットワーク２０および営業支援サーバ１０に過大な負荷がかからないようにすることができる。

図７は、営業支援端末３０と営業支援サーバ１０との間で授受されるメッセージを圧縮する仕組みの例について概要を示した図である。上述の図６の例では、営業支援端末３０側での支援サービス３７に対する通信の窓口が通信制御部３２（キュー３８）に一元化されているが、図７の例では、さらに、営業支援サーバ１０側の通信の窓口を通信制御部１２に一元化した上で、通信制御部３２と通信制御部１２との間で通信セッション２１を介して授受されるデータを圧縮する。

具体的には、例えば、営業支援端末３０上の支援サービス３７から営業支援サーバ１０に対して送信されるメッセージは、窓口である通信制御部３２に受け渡され、通信制御部３２において所定の手法（例えば、Ａｄｏｂｅ（登録商標）社の規格であるＡＭＦ３（Action Message Format 3）など）により圧縮された上で通信セッション２１を介して送信される。通信セッション２１から圧縮データを受け取った営業支援サーバ１０上の通信制御部１２では、これを解凍し、得られたメッセージの内容を参照して、処理対象の支援サービス１７を判定してメッセージを振り分ける。

これにより、営業支援端末３０と営業支援サーバ１０との間で授受されるメッセージのデータ量を削減し、ネットワーク２０の負荷を低減させることができる。また、営業支援サーバ１０側の通信の窓口を通信制御部１２に一元化したことにより、より柔軟な構成をとることも可能となる。例えば、図７に示した構成と、上述の図６に示した構成とを組み合わせて用いることも容易となる。

図８は、営業支援端末３０と営業支援サーバ１０との間で授受されるメッセージを短縮化する仕組みの例について概要を示した図である。図８の例では、営業支援端末３０と営業支援サーバ１０との間で同一のコードマスタをそれぞれ保持し（コードマスタ３３ａおよびコードマスタ１３ａ）、メッセージの送信側においてメッセージに含まれるデータをコードマスタを参照して対応するコード値に変換して短縮化する。

具体的には、例えば、営業支援端末３０上の支援サービス３７から営業支援サーバ１０に対して送信されるメッセージ（図８の例では“あいうえお”）は、窓口である通信制御部３２に受け渡され、通信制御部３２では、通信設定３３の一部として予め有しているコードマスタ３３ａを参照して、メッセージ内のデータが該当する場合には対応するコード値（図８の例では“Ａ１”）に変換する。

コードマスタ３３ａには、例えば、変換元の文字列等のデータ（“あいうえお”）とコード値（“Ａ１”）との対応付けのリストが保持されている。コード値のデータ長は、少なくとも変換元のデータのデータ長より短いものとして定義される。このコードマスタ３３ａは、例えば、営業支援端末３０から営業支援サーバ１０にログインした際に営業支援サーバ１０上のコードマスタ１３ａをダウンロードして上書き更新することで、コードマスタ１３ａの内容と同期させる。１つ以上の営業支援端末３０がログインしている状態で営業支援サーバ１０上のコードマスタ１３ａの内容を更新した場合は、例えば、ログイン中の各営業支援端末３０に対して、同期のために再ログインを促すメッセージを出力したり、セッションを強制的に終了させたりして、再度ログインさせるようにする。

コード値に変換されたデータを含むメッセージを受け取った営業支援サーバ１０上の通信制御部１２では、通信設定１３の一部として予め定義されているコードマスタ１３ａを参照して、メッセージ内のデータが該当する場合には対応する変換元のデータ（“あいうえお”）に変換することで元のデータを復元する。

これにより、営業支援端末３０と営業支援サーバ１０との間で授受されるメッセージのデータ量を削減し、ネットワーク２０の負荷を低減させることができる。なお、図８に示した構成も、上述の図６や図７に示した構成と適宜組み合わせて用いることができる。

以上に説明したように、本発明の一実施の形態である営業支援サーバ１０によれば、営業支援端末３０上にタブを用いたユーザインタフェースにより顧客情報や営業資料等の多数の情報を表示する際に、営業支援端末３０上の画面制御部３４により、各タブを含む画面遷移上における各画面の表示内容に係るデータについて可能なものは営業支援端末３０上にキャッシュ３６として保持しておく。これにより、タブの切り替えなどによる画面遷移の際に、可能な画面もしくは画面内のパーツについては、キャッシュ３６の内容に基づいて画面表示することで、営業支援サーバ１０に対する不要なアクセスを回避して、営業支援サーバ１０およびネットワーク２０の負荷を低減させることができる。

また、営業支援端末３０および営業支援サーバ１０上の通信制御部３２および通信制御部１２により、営業支援端末３０と営業支援サーバ１０との間の通信について、各営業支援端末３０あたりの通信量を一定の範囲に制限するとともに、通信されるメッセージをアプリケーション（ミドルウェア）レベルで圧縮もしくは短縮化することで、ネットワーク２０の負荷を低減させることができる。

なお、本実施の形態では、証券会社等の営業担当者による営業活動を支援するシステムとして、営業担当者が保有する営業支援端末３０上に画面を表示する場合について説明したが、これに限られず、Ｗｅｂブラウザを有するクライアント端末によってＷｅｂサーバにアクセスして画面表示するようなシステムであれば適宜適用することが可能である。

以上、本発明者によってなされた発明を実施の形態に基づき具体的に説明したが、本発明は上記の実施の形態に限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能であることはいうまでもない。例えば、上記の実施の形態は本発明を分かりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。また、上記の実施の形態の構成の一部について、他の構成の追加・削除・置換をすることが可能である。

本発明は、証券会社等の金融機関における営業活動を支援する画面表示システムに利用可能である。

１…画面表示システム、
１０…営業支援サーバ、１１…Ｗｅｂサーバプログラム、１２…通信制御部、１３…通信設定、１３ａ…コードマスタ、１７…支援サービス、１８…営業支援情報、
２０…ネットワーク、２１…通信セッション、
３０…営業支援端末、３１…Ｗｅｂブラウザ、３２…通信制御部、３３…通信設定、３３ａ…コードマスタ、３４…画面制御部、３５…画面構造、３６…キャッシュ、３７…支援サービス。

Claims (8)

1. 情報処理端末からのＷｅｂサーバへのアクセスに基づいて、前記Ｗｅｂサーバにより提供される１つ以上のサービスによって取得された情報を前記情報処理端末において複数の画面に表示する画面表示システムであって、
   前記情報処理端末は、表示された所定の画面の表示内容に係るデータをキャッシュに保持し、画面を表示もしくは切り替える際に、表示対象の各画面の表示内容に係るデータが前記キャッシュに保持されている場合に、前記キャッシュに保持されている当該画面の表示内容に係るデータに基づいて当該画面を表示する画面制御部を有する、画面表示システム。
2. 請求項１に記載の画面表示システムにおいて、
   前記画面制御部は、画面を表示もしくは切り替える際に、画面のインスタンスのツリー構造の情報に基づいて、表示対象の画面が存在するか否かを判定する、画面表示システム。
3. 請求項１または２に記載の画面表示システムにおいて、
   前記画面制御部は、画面内の所定のパーツの表示内容に係るデータを前記キャッシュに保持し、画面を表示もしくは切り替える際に、表示対象の画面内のパーツに係るデータが前記キャッシュに保持されている場合に、前記キャッシュに保持されている当該パーツの表示内容に係るデータに基づいて当該パーツを表示する、画面表示システム。
4. 請求項３に記載の画面表示システムにおいて、
   前記画面制御部は、画面に表示されたパーツのうち、所定のパーツに対するユーザによる指定に基づいて、当該パーツの表示内容に係るデータを前記Ｗｅｂサーバから取得して、当該パーツの表示を更新し、前記キャッシュに保持されている当該パーツの表示内容に係るデータを更新する、画面表示システム。
5. 請求項１〜４のいずれか１項に記載の画面表示システムにおいて、
   前記情報処理端末は、前記Ｗｅｂサーバとの間の通信セッションの数が所定の値を超えない場合に、前記Ｗｅｂサーバに対するメッセージが入力されるキューからメッセージを取り出して、当該メッセージを前記通信セッションのうちの１つを介して前記Ｗｅｂサーバに送信する通信制御部を有する、画面表示システム。
6. 請求項１〜４のいずれか１項に記載の画面表示システムにおいて、
   前記情報処理端末は、前記Ｗｅｂサーバに対するメッセージを圧縮して送信する第１の通信制御部を有し、
   前記Ｗｅｂサーバは、前記情報処理端末から受信したメッセージを解凍し、当該メッセージの内容に基づいて、対応する前記サービスに当該メッセージを振り分ける第２の通信制御部を有する、画面表示システム。
7. 請求項１〜４のいずれか１項に記載の画面表示システムにおいて、
   前記情報処理端末は、前記Ｗｅｂサーバとの間でメッセージを送受信する第１の通信制御部を有し、
   前記Ｗｅｂサーバは、前記情報処理端末との間でメッセージを送受信し、前記情報処理端末から受信したメッセージを、当該メッセージの内容に基づいて対応する前記サービスに振り分ける第２の通信制御部を有し、
   前記第１の通信制御部と前記第２の通信制御部は、変換元のデータと当該データのデータ長より短い長さである変換後のコード値との対応のリストからなるコードマスタとして共通のものをそれぞれ有し、
   メッセージの送信側の前記第１もしくは前記第２の通信制御部は、当該メッセージ内のデータを前記コードマスタの内容に基づいてコード値に変換した上で当該メッセージを送信し、
   メッセージの受信側の前記第２もしくは前記第１の通信制御部は、受信したメッセージ内のコード値を前記コードマスタの内容に基づいて変換元のデータに復元する、画面表示システム。
8. 請求項７に記載の画面表示システムにおいて、
   前記情報処理端末の前記第１の通信制御部は、前記情報処理端末から前記Ｗｅｂサーバに対してログインが行われた際に、前記Ｗｅｂサーバから前記Ｗｅｂサーバが保持する前記コードマスタを取得する、画面表示システム。
   
   
   
   
   

Images