JP2018181012A - 業務連携システムおよび業務連携方法 - Google Patents

Abstract

【課題】クラウド化した営業店端末機能にて業務連携処理を実装するに際し、連携対象業務に応じたホストでの各事象に由来する情報の出力先制御を的確、かつ、効率的なものとする。【解決手段】業務連携システム１０においてチャネルサーバ１００は、営業店端末機能をネットワーク経由で所定端末２００に提供するサーバ装置であり、所定端末２００から業務連携処理に関して受信した要求を格納する記憶装置と、連携対象業務に対応するホスト４００に当該要求を送信して得た応答の所定属性に応じて記憶装置にて要求を参照し、当該要求の示す所定端末２００のアドレスおよび業務システム３００に関する情報に基づきセッション情報を特定して、所定端末２００におけるブラウザを指定して当該応答の表示用情報を送信する演算装置とを備える。【選択図】図１

Description

本発明は、業務連携システムおよび業務連携方法に関するものであり、具体的には、クラウド化した営業店端末機能にて業務連携処理を実装するに際し、連携対象業務に応じたホストでの各事象に由来する情報の出力先制御を的確かつ効率的なものとする技術に関する。

金融機関の各営業店においては、勘定系業務取引をはじめとした新規業務や情報系業務との連携を処理可能な営業店端末（いわゆるＢＴＳ）やスキャナー、出納機、ＡＴＭなど種々の機器が配置され、当該金融機関の基幹系システムと連携して各業務処理を実行している。

一方、そうした業務連携に関して、業務効率改善やサービス品質向上等のため、様々な施策が検討されており、例えば従来技術においては、自社により運用され、１つ以上のサービスを提供する個別システムと、１つ以上のサービスから共通で利用されるサービスを提供する共通システムと、自社の外部においてサービスを提供する外部システムと、を含む複数のシステム環境上で稼働するソフトウェアの連携により業務サービスを提供する階層モデルからなるアプリケーションプログラムを有する情報処理システムにおいて、前記アプリケーションプログラムの各層の機能に対するアクセスの制御もしくは認証を行う統合アクセス制御システムであって、前記個別システムおよび前記外部システムにおいて、前記アプリケーションプログラムにおけるプレゼンテーション層により提供される画面へのアクセスに対して、ユーザおよびユーザがアクセスのために利用しているチャネルの少なくとも１つに基づいて認証処理を行う認証処理部と、前記認証処理部でのユーザ認証を介してログインしたユーザの数に応じて新たなユーザのログインを制限するログイン制御部と、を有する認証制御部と、前記外部システムにより提供される画面へのアクセスの際に、前記個別システムにアクセスした際の認証結果を前記外部システムに対して連携させるための認証連携インタフェース部とを有することを特徴とする統合アクセス制御システム（特許文献１参照）などが提案されている。

また、利用者が操作するクライアント装置と、情報処理を行うサービスを提供する複数のサーバ装置とのそれぞれと通信可能に接続される情報処理装置が、業務毎に、前記業務に必要な一連の前記情報処理のそれぞれについて、前記情報処理を提供する前記サーバ装置を特定するサーバ特定情報をメモリに記憶し、前記クライアント装置から送信される、前記業務を特定する業務特定情報を含むメッセージを受信し、受信した前記メッセージに含まれる前記業務特定情報から前記業務を特定し、特定した前記業務に対応する前記サーバ特定情報を前記メモリから読み出し、読み出した前記サーバ特定情報により特定される前記サーバ装置のそれぞれに対して、前記情報処理を行うように要求する情報処理要求を送信することを特徴とする情報処理方法（特許文献２参照）なども提案されている。

特開２０１３−１９０９７１号公報 特開２００７−１８３７９３号公報

上述した営業店端末は、当該業務向けに特化した専用端末である。そのため、他システ
ムとの業務連携を図るためには、専用のソフトウェアを組込む必要があった。その一方で、近年普及しているタブレット端末を、上述の営業店端末の１つとして活用したいというニーズもある。ところがタブレット端末はその性能・仕様が限定的であり、専用端末たる営業店端末の機能を全て置換することは難しい。

そこで、営業店端末の機能を所定のサーバ（以降、チャネルサーバ）上でクラウド化し、当該機能をネットワーク経由でタブレット端末に提供する形態が想定出来る。この場合のタブレット端末は、上述のチャネルサーバにアクセスし、搭載したブラウザを介して営業店端末機能の提供を受けることとなる。

上述のごとき形態に移行する場合、当該タブレット端末では、従来の営業店端末において他システムとの業務連携を図る際に用いた通信方式は採用出来ない。また、上述のチャネルサーバを介した業務連携に際し、連携対象業務に対応したホスト等におけるイベントや画面更新の通知を、ブラウザ別に適宜振り分ける必要があるが、それを実現する構成は提案されていない。

そこで本発明の目的は、クラウド化した営業店端末機能にて業務連携処理を実装するに際し、連携対象業務に応じたホストでの各事象に由来する情報の出力先制御を的確かつ効率的なものとする技術を提供することにある。

上記課題を解決する本発明の業務連携システムは、営業店端末機能をネットワーク経由で所定端末に提供するサーバであって、前記所定端末から業務連携処理に関して受信した要求を格納する記憶装置と、前記要求が示す連携対象業務に対応するホストに当該要求を送信して得た、前記ホストからの応答の所定属性に応じて前記記憶装置にて要求を参照し、当該要求の示す前記所定端末のアドレスおよび前記業務システムに関する情報に基づき、前記所定端末とのセッション情報を特定し、当該セッション情報により前記所定端末におけるブラウザを指定して当該応答の表示用情報を送信する演算装置と、を備えたチャネルサーバを含むことを特徴とする。

また、本発明の業務連携方法は、営業店端末機能をネットワーク経由で所定端末に提供するサーバが、前記所定端末から業務連携処理に関して受信した要求を格納し、前記要求が示す連携対象業務に対応するホストに当該要求を送信して得た、前記ホストからの応答の所定属性に応じて前記記憶装置にて要求を参照し、当該要求の示す前記所定端末のアドレスおよび前記業務システムに関する情報に基づき、前記所定端末とのセッション情報を特定し、当該セッション情報により前記所定端末におけるブラウザを指定して当該応答の表示用情報を送信する、ことを特徴とする。

本発明によれば、クラウド化した営業店端末機能にて業務連携処理を実装するに際し、連携対象業務に応じたホストでの各事象に由来する情報の出力先制御を的確かつ効率的なものとできる。

本実施形態の業務連携システムを含むネットワーク構成図である。 本実施形態のチャネルサーバのハードウェア構成例を示す図である。 本実施形態のタブレット端末のハードウェア構成例を示す図である。 本実施形態のセッションテーブルのデータ構成例を示す図である。 本実施形態における業務連携方法のフロー例を示す図である。 本実施形態における業務連携方法の概念例を示す図である。

−−−ネットワーク構成−−−

以下に本発明の実施形態について図面を用いて詳細に説明する。図１は、本実施形態の業務連携システム１０を含むネットワーク構成図である。図１に示す業務連携システム１０は、クラウド化した営業店端末機能にて業務連携処理を実装するに際し、連携対象業務に応じたホストでの各事象に由来する情報の出力先制御を的確かつ効率的なものとするコンピュータシステムである。

図１に示す業務連携システム１０は、営業店端末の機能をクラウド化して提供するチャネルサーバ１００、当該チャネルサーバ１００とネットワーク１を介して営業店端末機能の提供を受けるタブレット端末２００、融資業務などの各業務に関する処理を実行する業務システム３００、勘定系などのホスト４００（以降、勘定系ホストとする）、および、勘定系ホスト４００へのアクセス制御等を担うＧＷサーバ４５０、のうち少なくともチャネルサーバ１００を含むものである。

上述のうち、チャネルサーバ１００は、その構成において、サーブレット１１０、Ｊ２ＥＥサーバ１１１、および、ＷｅｂＳｏｃｋｅｔサーバ１１２を含んだ、サーバシステムとなっている。なお、Ｊ２ＥＥサーバ１１１およびＷｅｂＳｏｃｋｅｔサーバ１１２の各機能をソフトウェアとして実装して単体のチャネルサーバ１００が備えるとしてもよい。

また、タブレット端末２００は、金融機関の各営業店におけるテラー等（勿論、役席者であってもよく、営業店での対象者の範囲は限定しない）が操作する端末である。テラーらは、例えば窓口対応中の顧客からの指示に応じて勘定取引に関する操作を当該タブレット端末２００で行う。

また、業務システム３００は、例えば、融資業務など金融機関における各業務に関する処理をそれぞれに担うシステムである。本実施形態では、一例として融資業務の業務システムであるとして説明を行う。

また、勘定系ホスト４００は、チャネルサーバ１００を運用主体たる金融機関における、顧客の口座残高等の管理、入出金や振込、決済といった各種処理を実行するシステムである。本実施形態における勘定系ホスト４００での処理は、特に、上述のタブレット端末２００からの業務連携の要求に関して行うもので、その要求に対する応答たる処理結果は、ＧＷサーバ（ゲートウェイサーバ）を介し、チャネルサーバ１００経由で当該タブレット端末２００（のブラウザ）に返されることとなる。
−−−ハードウェア構成−−−

また、本実施形態における業務改善支援システム１０を構成する各装置は、以下のようなハードウェア構成を備える。図２に、本実施形態のチャネルサーバ１００のハードウェア構成例を、また、図３に、本実施形態のタブレット端末２００のハードウェア構成例を示す。

このうちチャネルサーバ１００は、図２にて例示するように、ＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）やハードディスクドライブなど適宜な不揮発性記憶素子で構成される記憶装置１０１、ＲＡＭなど揮発性記憶素子で構成されるメモリ１０３、記憶装置１０１に保持されるプログラム１０２をメモリ１０３に読み出すなどして実行し装置自体の統括制御を行なうとともに各種判定、演算及び制御処理を行なうＣＰＵなどの演算装置１０４、ネットワーク１と接続してタブレット端末２００や業務システム３００、ＧＷサー
バ４５０、ホスト４００など他装置との通信処理を担う通信装置１０５、を備える。

なお、記憶装置１０１内には、本実施形態の業務連携システム１００におけるチャネルサーバ１００として必要な機能たるプログラム１０２に加え、サーブレット１１０およびセッションテーブル１２５（後述）が少なくとも記憶されている。この図２においては、説明の簡便化のため、チャネルサーバ１００の機能を実装するハードウェアのみ例示した。サーバシステムとしてのチャネルサーバ１００は、既に述べたように、Ｊ２ＥＥサーバ１１１、および、ＷｅｂＳｏｃｋｅｔサーバ１１２の各サーバ装置も含む。

また、本実施形態におけるタブレット端末２００は、図３にて例示するように、ＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）やハードディスクドライブなど適宜な不揮発性記憶素子で構成される記憶装置２０１、ＲＡＭなど揮発性記憶素子で構成されるメモリ２０３、記憶装置２０１に保持されるプログラム２０２をメモリ２０３に読み出すなどして実行し装置自体の統括制御を行なうとともに各種判定、演算及び制御処理を行なうＣＰＵなどの演算装置２０４、ユーザからの入力受付と処理データの表示を行うタッチパネル等の入出力装置２０５、ネットワーク１と接続してチャネルサーバ１００や業務システム３００等の他装置との通信処理を担う通信装置２０６、を備える。

なお、記憶装置２０１内には、本実施形態のタブレット端末２００として必要な機能を実装する為のプログラム２０２に加えて、ブラウザ２１０および業務連携ＡＰＩ２１１が少なくとも記憶されている。但し、業務連携ＡＰＩ２１１は、業務連携に当たってブラウザ２１０が起動され、該当業務システム３００にアクセスした際、当該業務システム３００からダウンロードされ、記憶装置２０１に格納されるものである。
−−−テーブル構造例−−−

続いて、本実施形態の業務連携システム１０を構成するチャネルサーバ１００が用いるテーブル類について説明する。図４に、本実施形態におけるセッションテーブル１２５の一例を示す。

セッションテーブル１２５は、タブレット端末２００から業務連携処理に関して受信した要求に関する情報を蓄積したテーブルである。そのデータ構造は、例えば、該当要求に関して当該タブレット端末のブラウザ２１０２００とチャネルサーバ１００との間で確立したセッションごとのレコードであって、当該レコード＃、当該セッションの対象であるタブレット端末２００のＩＰアドレス、当該要求における業務連携対象の業務システム３００の業務連携ＡＰＩの種別、および、当該セッションのＩＤ（業務連携ＡＰＩを利用しているブラウザの識別情報と言える）といったデータから成るレコードの集合体である。

なお、上述の業務連携ＡＰＩは、業務システム３００が提供するものであり、業務連携に際して、連携開始／終了、画面上のフィールド値取得、ＰＢＰＲ状態取得、取引権限チェックなどの各種コマンドに対応した機能や、エラー表示、障害発生、ログオフなどのホスト等で生じたイベントに関する通知機能、を提供するものとなる。

上述のセッションテーブル１２５のＡＰＩ種別は、各種の業務連携ＡＰＩのうち、いずれも業務連携を一旦受け付けた後にホストでの処理を待って回答する必要がある業務連携ＡＰＩに該当するものである。こうした業務連携ＡＰＩとしては、画面制御に関する画面制御ＡＰＩか、取引権限チェックといった業務連携ＡＰＩかは問わず、チャネルサーバ１００のサーブレット１１０とタブレット端末２００のブラウザ２１０との間のセッションを維持せずにすなわち非同期で、業務連携処理の結果たる勘定系ホスト４００からの応答を該当ブラウザ２１０に通知する業務連携が該当する。
−−−フロー例−−−

以下、本実施形態における業務連携方法の実際手順について図に基づき説明する。以下で説明する業務連携方法に対応する各種動作は、業務連携システム１０を構成する各装置らがメモリ等に読み出してそれぞれ実行するプログラムによって実現される。そして、このプログラムは、以下に説明される各種の動作を行うためのコードから構成されている。
図５は、本実施形態における業務連携方法のフロー例を示す図であり、図６は、本実施形態における業務連携方法の概念例を示す図である。

ここでは、ネットワーク１に接続された複数のタブレット端末２００のうち、“タブレット１”なるタブレット端末２００が、融資業務の業務システム３００との業務連携を要求する前提にて説明を行うものとする。また、この“タブレット１”なるタブレット端末２００は、ブラウザ２１０を起動して上述の業務システム３００にアクセスし、業務連携ＡＰＩ２１１をダウンロードして記憶装置２０１に保持しているものとする。
そこで“タブレット１”なるタブレット端末２００が、チャネルサーバ１００のサーブレット１１０に対し、ｈｔｔｐリクエストを送信する（ｓ１００）。

このｈｔｔｐリクエストは、業務連携処理に関する要求であって、当該“タブレット１”なるタブレット端末２００のＩＰアドレス、業務連携ＡＰＩ呼び出しフラグ、当該ｈｔｔｐリクエストに基づき該当ブラウザ２１０とチャネルサーバ１００との間で確立するセッションのセッションＩＤ、といった値を少なくとも含む。

このうちＩＰアドレスは、タブレット端末２００が予め保持する固定値か、或いは今次のｈｔｔｐリクエストに際してネットワーク１にアクセスした際に付与された値である。また、業務連携ＡＰＩ呼び出しフラグは、チャネルサーバ１００のサーブレット１１０とタブレット端末２００のブラウザ２１０との間のセッションを維持せずにすなわち非同期で、業務連携処理の結果たる勘定系ホスト４００からの応答を該当ブラウザ２１０に通知する業務連携に関して付与されるフラグ（本実施形態においては、付与前の値は“ｏｆｆ”で付与後の値は“ｏｎ”）であり、業務連携ＡＰＩ２１０が予め保持するものとする。

一方、上述のｈｔｔｐリクエストを受信したチャネルサーバ１００のサーブレット１１０は、当該ｈｔｔｐリクエストが含む業務連携ＡＰＩ呼び出しフラグをチェックする（ｓ１０１）。

上述のチェックの結果、業務連携ＡＰＩ呼び出しフラグが、“ｏｆｆ”であった場合（ｓ１０２：ｏｆｆ）、チャネルサーバ１００のサーブレット１１０は、Ｊ２ＥＥサーバ１１１から、当該ｈｔｔｐリクエストが示す連携対象業務（上述の場合は融資業務）に関する業務ロジックの実行に応じて、対応する勘定系ホスト４００から得た、当該ｈｔｔｐリクエストの示す画面制御ＡＰＩに関する処理結果すなわち応答を受信し、これを同期通信で、すなわちセッションを維持したままの“セッションＢ”の“ブラウザ２”に宛てて送信し（ｓ１０３）、処理を終了する。いわば、通常の画面転送制御がチャネルサーバ１００とタブレット端末２００との間で行われる。

他方、上述のチェックの結果、業務連携ＡＰＩ呼び出しフラグが、“ｏｎ”であった場合（ｓ１０２：ｏｎ）、チャネルサーバ１００のサーブレット１１０は、当該業務連携に関して、勘定系ホスト４００から得る応答を非同期での通信によって該当ブラウザに返信すべきと認識し、当該ｈｔｔｐリクエストに伴うセッションに関してレコードを生成して、これをセッションテーブル１２５に登録し、当該レコードのＩＰアドレス欄に“タブレット１”（に対応したＩＰアドレス値）、ＡＰＩ種別欄に“業務連携ＡＰＩ”または“画面制御ＡＰＩ”、および、セッションＩＤ欄に、例えば“セッションＡ”または“セッションＢ”といった値を設定し（ｓ１０４）、処理を終了する。

上述のｓ１０４の実行後、チャネルサーバ１００のＪ２ＥＥサーバ１１１は、当該ｈｔｔｐリクエストが示す連携対象業務すなわち上述の場合は融資業務に関する業務ロジックを実行し、対応する勘定系ホスト４００に対し、当該ｈｔｔｐリクエストの示す業務連携ＡＰＩまたは画面制御ＡＰＩに関する処理要求を送信する（ｓ１０５）。この場合、勘定系ホスト４００は、当該処理要求の対象業務に関して、当該業務の処理要求の受付通知を、チャネルサーバ１００に返すことになる。チャネルサーバ１００のＪ２ＥＥサーバ１１１は、いまだセッションが維持されている上述の“タブレット１”の該当ブラウザ（処理要求が業務連携ＡＰＩに関するものであれば、“ブラウザ１”、画面制御ＡＰＩに関するものであれば“ブラウザ２”）に宛て、サーブレット１１０を介して上述の受付通知を送信するものとする。この時点で、該当セッションのリクエストとレスポンスは完結し、当該セッションは一旦終了することになる。

またその後、勘定系ホスト４００は、当該画面制御ＡＰＩまたは業務連携ＡＰＩの処理を実行し、その処理結果たる応答をＪ２ＥＥサーバ１１１に返すこととなる。上述の勘定系ホスト４００のＧＷサーバ４５０は、当該勘定系ホスト４００にて上述の処理要求を受け付けた画面制御ＡＰＩまたは業務連携ＡＰＩに関して処理を行った旨、すなわちイベントが生じた旨を、チャネルサーバ１００のＪ２ＥＥサーバ１１１に通知する。

この場合のＪ２ＥＥサーバ１１１は、ＧＷサーバ４５０を介して、上述のイベント発生に関する通知を受信し（ｓ１０６）、ＷｅｂＳｏｃｋｅｔサーバ１１２に対して、ＲＭＩ（Ｒｅｍｏｔｅ Ｍｅｔｈｏｄ Ｉｎｖｏｃａｔｉｏｎ）通信によりイベント通知指示を送る（ｓ１０７）。このイベント通知指示は、上述のタブレット端末２００およびそのブラウザ２１０と画面制御ＡＰＩまたは業務連携ＡＰＩとに関する情報が少なくとも含まれている。

続いて、チャネルサーバ１００のＷｅｂＳｏｃｋｅｔサーバ１１２は、上述のイベント通知指示を受けて、当該イベント通知指示が示すタブレット端末２００のＩＰアドレスの値を取得する（ｓ１０８）。上述の例であれば、ｓ１０８で得るＩＰアドレスは、“タブレット１”の値となる。

次に、チャネルサーバ１００のＷｅｂＳｏｃｋｅｔサーバ１１２は、ｓ１０８で得たＩＰアドレスの値を、セッションテーブル１２５に照合し、当該“タブレット１”に関するレコードのうちＡＰＩ種別が“業務連携ＡＰＩ”であるものから、セッションＩＤの値を取得する（ｓ１０９）。上述の例であれば、ｓ１０９で得るセッションＩＤは、“セッションＡ”の値となる。勿論、ｓ１０９の結果、セッションテーブル１２５でセッションＩＤの値が取得出来ない、すなわち、該当レコードが存在しないケースもあるが、その場合は処理をｓ１１１に遷移させるものとする。

また、チャネルサーバ１００のＷｅｂＳｏｃｋｅｔサーバ１１２は、ｓ１０９で得たセッションＩＤ“セッションＡ”の対象となっていた“ブラウザ１”に宛て、上述の勘定系ホスト４００における業務連携ＡＰＩに関する処理のイベントを通知する（ｓ１１０）。

この通知は、ＷｅｂＳｏｃｋｅｔ通信によるプッシュ通信で行われるものであり、該当業務連携ＡＰＩの処理結果たる応答を当該タブレット端末２００のブラウザ２１０で表示させる表示用情報を含みうる。

また、チャネルサーバ１００のＷｅｂＳｏｃｋｅｔサーバ１１２は、ｓ１０８で得たＩＰアドレスの値を、セッションテーブル１２５に照合し、当該“タブレット１”に関するレコードのうちＡＰＩ種別が“画面制御ＡＰＩ”であるものから、セッションＩＤの値を
取得する（ｓ１１１）。上述の例であれば、ｓ１１１で得るセッションＩＤは、“セッションＢ”の値となる。勿論、ｓ１１１の結果、セッションテーブル１２５でセッションＩＤの値が取得出来ない、すなわち、該当レコードが存在しないケースもあるが、その場合は処理を終了する。

また、チャネルサーバ１００のＷｅｂＳｏｃｋｅｔサーバ１１２は、ｓ１１１で得たセッションＩＤ“セッションＢ”の対象となっていた“ブラウザ２”に宛て、上述の勘定系ホスト４００における画面制御ＡＰＩに関する処理のイベントを通知し（ｓ１１２）、処理を終了する。この通知は、ＷｅｂＳｏｃｋｅｔ通信によるプッシュ通信で行われるものであり、該当画面制御ＡＰＩの処理結果たる応答を当該タブレット端末２００のブラウザ２１０で表示させる表示用情報を含みうる。

以上、本発明を実施するための最良の形態などについて具体的に説明したが、本発明はこれに限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能である。

こうした本実施形態によれば、クラウド化した営業店端末機能にて業務連携処理を実装するに際し、連携対象業務に応じたホストでの各事象に由来する情報の出力先制御を的確かつ効率的なものとできる。

本明細書の記載により、少なくとも次のことが明らかにされる。すなわち、本実施形態の業務連携システムにおいて、前記サーバの演算装置は、前記応答の所定属性が、業務連携処理の結果応答以外の所定処理に関する応答に対応したものである場合、前記記憶装置にて前記要求を参照せず、通信セッションを維持したままの前記所定端末におけるブラウザに、当該応答の表示用情報を送信するものである、としてもよい。

これによれば、上述の応答として、当該ホストにて該当要求を受け付けたこと（のみ）を示す通知や、当該ホストでの情報照会結果を返すものを受けた場合など、ブラウザとのセッションが維持されて同期通信が可能な状態での応答について、本実施形態におけるセッションテーブルでの参照動作を行わず、そのまま該当ブラウザへの応答の表示処理を行うことが可能となる。

また、本実施形態の業務連携方法において、前記サーバが、前記応答の所定属性が、業務連携処理の結果応答以外の所定処理に関する応答に対応したものである場合、前記記憶装置にて前記要求を参照せず、通信セッションを維持したままの前記所定端末におけるブラウザに、当該応答の表示用情報を送信する、としてもよい。

１ ネットワーク
１０ 業務連携システム
１００ チャネルサーバ
１０１ 記憶装置
１０２ プログラム
１０３ メモリ
１０４ 演算装置
１０５ 通信装置
１１０ サーブレット
１１１ Ｊ２ＥＥサーバ
１１２ ＷｅｂＳｏｃｋｅｔサーバ
１２５ セッションテーブル
２００ タブレット端末
２０１ 記憶装置
２０２ プログラム
２０３ メモリ
２０４ 演算装置
２０５ 入出力装置
２０６ 通信装置
２１０ ブラウザ
２１１ 業務連携ＡＰＩ
３００ 業務システム
４００ 勘定系ホスト（ホスト）
４５０ ＧＷサーバ

Claims (4)

1. 営業店端末機能をネットワーク経由で所定端末に提供するサーバであって、
   前記所定端末から業務連携処理に関して受信した要求を格納する記憶装置と、
   前記要求が示す連携対象業務に対応するホストに当該要求を送信して得た、前記ホストからの応答の所定属性に応じて前記記憶装置にて要求を参照し、当該要求の示す前記所定端末のアドレスおよび前記業務システムに関する情報に基づき、前記所定端末とのセッション情報を特定し、当該セッション情報により前記所定端末におけるブラウザを指定して当該応答の表示用情報を送信する演算装置と、
   を備えたチャネルサーバを含むことを特徴とする業務連携システム。
2. 前記演算装置は、
   前記応答の所定属性が、業務連携処理の結果応答以外の所定処理に関する応答に対応したものである場合、前記記憶装置にて前記要求を参照せず、通信セッションを維持したままの前記所定端末におけるブラウザに、当該応答の表示用情報を送信するものである、
   ことを特徴とする請求項１に記載の業務連携システム。
3. 営業店端末機能をネットワーク経由で所定端末に提供するサーバが、
   前記所定端末から業務連携処理に関して受信した要求を格納し、
   前記要求が示す連携対象業務に対応するホストに当該要求を送信して得た、前記ホストからの応答の所定属性に応じて前記記憶装置にて要求を参照し、
   当該要求の示す前記所定端末のアドレスおよび前記業務システムに関する情報に基づき、前記所定端末とのセッション情報を特定し、当該セッション情報により前記所定端末におけるブラウザを指定して当該応答の表示用情報を送信する、
   ことを特徴とする業務連携方法。
4. 前記サーバが、
   前記応答の所定属性が、業務連携処理の結果応答以外の所定処理に関する応答に対応したものである場合、前記記憶装置にて前記要求を参照せず、通信セッションを維持したままの前記所定端末におけるブラウザに、当該応答の表示用情報を送信する、
   ことを特徴とする請求項３に記載の業務連携方法。

Images