JP2011071726A - セッション共有システム、方法及びプログラム、並びに、ユーザ端末 - Google Patents

Abstract

【課題】サーバにおけるアプリケーション処理負荷を軽減し、簡単かつ確実に、連携アプリケーションを提供するために必要なＨＴＴＰ／ＳＩＰセッションの共有を実現する。
【解決手段】本発明のセッション共有システムは、第１の機能処理手段と、第２の機能処理手段と、第１の機能処理手段又は第２の機能処理手段から取得した各アプリケーションサーバとの間で確立したセッション情報を所定形式に変換し、第２の機能処理手段又は第１の機能処理手段に与えるセッション情報連携手段とを備え、第２の機能処理手段又は第１の機能処理手段が、セッション情報連携手段からの変換セッション情報を含む要求メッセージを、各アプリケーションサーバに送信し、各アプリケーションサーバが、要求メッセージに含まれる変換セッション情報と、今回の通信処理プロトコルにより生成したセッション情報との対応付けを行う。
【選択図】 図１

Description

本発明は、セッション共有システム、方法及びプログラム、並びに、ユーザ端末に関し、例えば、ＳＩＰ対応のアプリケーションサーバ上に構築した、Ｗｅｂサービスと電話機能とを連携するアプリケーションにおいて、Ｗｅｂサービスと電話機能に係るセッションを共有するシステム、方法及びプログラム、並びに、ユーザ端末に適用し得るものである。

例えば、アプリケーションサーバ（以下、サーバともいう）がＷｅｂサービスと電話機能とを連携するアプリケーションを提供する場合、Ｗｅｂサービスと電話機能との双方の利用者情報を紐付けする必要があるため、利用者を特定しなければならない。

例えば、図２は、例えば３人のユーザＡ〜ユーザＣに対してサーバが連携アプリケーションを提供する場合のＨＴＴＰ（HyperText Transfer Protocol）／ＳＩＰ（Session Initiation Protocol）セッション管理を説明する説明図である。図２において、サーバが、ＨＴＴＰのセッションオブジェクト「１」、「２」、「３」と、ＳＩＰのセッションオブジェクト「ａ」、「ｂ」、「ｃ」とを生成した場合、連携アプリケーションを提供するサーバは、例えばＨＴＴＰのセッションオブジェクト「３」とＳＩＰのセッションオブジェクト「ｂ」とが「ユーザＡ」に関するセッションオブジェクトであることの対応付けを行う必要がある。

一般的に、Ｗｅｂサービスを提供する場合、ＨＴＴＰセッションの管理方法として、例えば、ＷｅｂサーバがＣｏｏｋｉｅをブラウザに保持させてユーザセッションを保持する方法等を用いている。

また、例えばＳＩＰを用いて呼接続により音声通信を行う場合、例えばＳＩＰセッションの管理方法として、例えばＩＥＴＦのＲＦＣ３２６１で規定されている標準化技術（非特許文献１参照）に従い、ＣＡＬＬ−ＩＤ等を利用してユーザセッションを保持する方法等を用いている。

例えば、ＷｅｂのＨＴＴＰリクエストを契機に、サーバ側から電話発信する方式（例えばサードパーティコール等）の場合、サーバがＨＴＴＰリクエストに基づいてＳＩＰを用いた呼制御を行うので、ＨＴＴＰ／ＳＩＰの両セッションの紐付けは比較的容易である。

しかし、図３のように、ユーザ端末から電話発信する方式のアプリケーションの場合、サーバはユーザ端末からＨＴＴＰリクエストメッセージとＳＩＰ ＩＮＶＩＴＥメッセージをそれぞれ個別に受信する形となるので容易に両セッションを紐付けることができない。

上記のような場合に、ＨＴＴＰ／ＳＩＰの両セッションを紐付けする方法として、以下のような方式を用いている。

第１の方法は、Ｗｅｂアプリケーションの応答に、セッション紐付け識別情報を埋め込む方式である。

この場合、例えば、サーバ２０が、図３のステップＳ３に示すＷｅｂアプリケーション処理の中で、ＨＴＴＰセッションを一意に識別する識別子を生成し、この識別子を応答メッセージに含める。その後、ユーザ端末１０が、その識別子を電話発信時のパラメータ（例えばＩＮＶＩＴＥパラメータ）として含めてサーバ２０に送信する。これを受けて、サーバ２０が、ステップＳ６に示すＳＩＰセッション生成処理の際に、識別子に基づき対応するＨＴＴＰセッションとＳＩＰセッションとの紐付けを行うという方式である。

第２の方法は、ユーザ端末の電話番号を、予めＷｅｂアプリケーションに登録する方式である。

この場合、例えば、サーバ２０が、ステップＳ３に示すＷｅｂアプリケーション処理の中で、ユーザに対してユーザ端末１０の電話番号等の呼を識別する情報を登録する。そして、サーバ２０が、ステップＳ６のＳＩＰセッションを生成する際に、ユーザ端末１０からのＩＮＶＩＴＥメッセージに含まれる発信元番号と登録済みの情報とのマッチングを行うことで、ＨＴＴＰセッションとＳＩＰセッションとの紐付けを行うという方式である。

なお、図３の例を用いた上記方法の内容は、Ｗｅｂアクセスの後に電話発信を行うというアプリケーションの場合を例示した。アプリケーションによっては、逆のケース、すなわち、電話発信の後にＷｅｂアクセスを行うケースもあるが、その場合、サーバ２０が、ユーザ端末１０の電話番号を、予めＷｅｂアプリケーションに登録する第２の方法が用いられている。

ＲＦＣ３２６１

しかしながら、上述した従来の方法は、以下のような問題が生じ得る。

上述した第１の方法の場合、サーバアプリケーションに、ＨＴＴＰセッションに対して一意の識別子を生成する処理、この識別子を管理する処理等が必要となるため、アプリケーションの処理が増え、処理負荷が増大するという問題が生じ得る。

また、上述した第２の方法の場合、予めユーザに対して電話番号等の情報を登録する必要があるため、ユーザに余分な処理を強いることになる。さらに、ユーザの情報の登録は人間による手作業で行われるので、作業負担が多くなり、かつ、正確な情報の登録が保障されないこともある。

そのため、サーバにおけるアプリケーション処理負荷を軽減し、簡単かつ確実に、連携アプリケーションを提供するために必要なＨＴＴＰ／ＳＩＰセッションの共有を実現できるセッション共有システム、方法及びプログラム、並びに、ユーザ端末が求められている。

かかる課題を解決するために、第１の本発明のセッション共有システムは、１又は複数のアプリケーションサーバが複数のアプリケーションを連携するシステムで、それぞれのセッションを共有するセッション共有システムにおいて、（１）第１の通信処理プロトコルを用いて各アプリケーションサーバから第１のアプリケーションサービスの提供を受ける第１の機能処理手段と、（２）第２の通信処理プロトコルを用いて各アプリケーションサーバから第２のアプリケーションの提供を受ける第２の機能処理手段と、（３）第１の機能処理手段又は第２の機能処理手段から取得した各アプリケーションサーバとの間で確立したセッション情報を所定形式に変換し、第２の機能処理手段又は第１の機能処理手段に与えるセッション情報連携手段とを備え、第２の機能処理手段又は第１の機能処理手段が、セッション情報連携手段からの変換セッション情報を含む要求メッセージを、各アプリケーションサーバに送信し、各アプリケーションサーバが、要求メッセージに含まれる上記変換セッション情報と、今回の通信処理プロトコルにより生成したセッション情報との対応付けを行うことを特徴とする。

第２の本発明のセッション共有方法は、１又は複数のアプリケーションサーバが複数のアプリケーションを連携するシステムで、それぞれのセッションを共有するセッション共有方法において、（１）第１の機能処理手段が、第１の通信処理プロトコルを用いて各アプリケーションサーバから第１のアプリケーションサービスの提供を受ける第１の機能処理工程と、（２）第２の機能処理手段が、第２の通信処理プロトコルを用いて各アプリケーションサーバから第２のアプリケーションの提供を受ける第２の機能処理工程と、（３）セッション情報連携手段が、第１の機能処理手段又は上記第２の機能処理手段から取得した各アプリケーションサーバとの間で確立したセッション情報を所定形式に変換し、第２の機能処理手段又は第１の機能処理手段に与えるセッション情報連携工程と、（４）第２の機能処理手段又は第１の機能処理手段が、セッション情報連携手段からの変換セッション情報を含む要求メッセージを、各アプリケーションサーバに送信する工程と、（５）各アプリケーションサーバが、要求メッセージに含まれる変換セッション情報と、今回の通信処理プロトコルにより生成したセッション情報との対応付けを行う工程とを有することを特徴とする。

第３の本発明のセッション共有プログラムは、複数のアプリケーションを連携するシステムで、１又は複数のアプリケーションサーバにそれぞれのセッションを共有させるセッション共有プログラムにおいて、ユーザ端末を、（１）第１の通信処理プロトコルを用いて各アプリケーションサーバから第１のアプリケーションサービスの提供を受ける第１の機能処理手段と、（２）第２の通信処理プロトコルを用いて各アプリケーションサーバから第２のアプリケーションの提供を受ける第２の機能処理手段と、（３）第１の機能処理手段又は第２の機能処理手段から取得した各アプリケーションサーバとの間で確立したセッション情報を所定形式に変換し、第２の機能処理手段又は第１の機能処理手段に与えるセッション情報連携手段として機能させ、（４）第２の機能処理手段又は第１の機能処理手段が、セッション情報連携手段からの変換セッション情報を含む要求メッセージを、各アプリケーションサーバに送信する機能することを特徴とする。

第４の本発明のユーザ端末は、複数のアプリケーションを連携するシステムで、１又は複数のアプリケーションサーバにそれぞれのセッションを共有させるセッション共有システムを構成するユーザ端末において、（１）第１の通信処理プロトコルを用いて各アプリケーションサーバから第１のアプリケーションサービスの提供を受ける第１の機能処理手段と、（２）第２の通信処理プロトコルを用いて各アプリケーションサーバから第２のアプリケーションの提供を受ける第２の機能処理手段と、（３）第１の機能処理手段又は第２の機能処理手段から取得した各アプリケーションサーバとの間で確立したセッション情報を所定形式に変換し、第２の機能処理手段又は上記第１の機能処理手段に与えるセッション情報連携手段とを備え、第２の機能処理手段又は第１の機能処理手段が、セッション情報連携手段からの変換セッション情報を含む要求メッセージを、各アプリケーションサーバに送信することを特徴とする。

本発明によれば、サーバにおけるアプリケーション処理負荷を軽減し、簡単かつ確実に、連携アプリケーションを提供するために必要なＨＴＴＰ／ＳＩＰセッションの共有を実現できる。

第１の実施形態のセッション共有システムの構成を示す構成図である。 従来のＨＴＴ／ＳＩＰセッションの紐付けを説明する説明図である。 従来のＷｅｂ／電話連携アプリケーションのシーケンス図である。 第１の実施形態のセッション連携機能部の機能構成を示すブロック図である。 第１の実施形態のＷｅｂアクセス後に電話発信する場合のセッション連携処理を示すシーケンス図である。 第１の実施形態のＷｅｂアクセス後に電話発信する場合のユーザ端末におけるシーケンス図である。 第１の実施形態のＳＩＰメッセージにＨＴＴＰセッション情報を付与する具体的な例を説明する説明図である。 第１の実施形態の電話発信後にＷｅｂアクセスする場合のセッション連携処理を示すシーケンス図である。 第１の実施形態の電話発信後にＷｅｂアクセスする場合のユーザ端末におけるシーケンス図である。 第１の実施形態のＨＴＴＰメッセージにＳＩＰセッション情報を付与する具体的な例を説明する説明図である。 第２の実施形態のセッション共有システムの構成を示す構成図である。 第２の実施形態のＷｅｂアクセス後に電話発信する場合のセッション連携処理を示すシーケンス図である。 第２の実施形態のＷｅｂアクセス後に電話発信する場合のユーザ端末におけるシーケンス図である。 複数台のアプリケーションサーバを備える構成の場合のＨＴＴＰ／ＳＩＰセッションの分離の問題を説明する説明図である。 第３の実施形態のセッション共有システムの構成を示す構成図である。 第３の実施形態のロードバランサの要求メッセージ振分部の機能構成を示すブロック図である。 第３の実施形態のＷｅｂアクセス後に電話発信する場合のセッション連携処理を示すシーケンス図である。

（Ａ）第１の実施形態
以下では、本発明のセッション共有システム、方法及びプログラム、並びに、ユーザ端末の第１の実施形態を図面を参照しながら説明する。

第１の実施形態は、Ｗｅｂサービスと電話機能との双方を連携するアプリケーションをアプリケーションサーバが提供する連携アプリケーシステムにおいて、アプリケーションサーバがＨＴＴＰ／ＳＩＰセッションを共有する方式に本発明を適用した実施形態を例示して説明する。

（Ａ−１）第１の実施形態の構成
図１は、第１の実施形態に係るセッション共有システムの主な構成を示す構成図である。図１において、第１の実施形態に係るセッション共有システム９Ａは、ネットワークを介して、ユーザ端末１とアプリケーションサーバ２とが接続している。

なお、実際のシステムの構成は、例えば、ユーザ端末１とアプリケーションサーバ２との間に、ＳＩＰ／ＨＴＴＰプロキシサーバやロードバランサ等の装置が介在することもあるが発明の特徴を簡潔に説明するためにこれら装置の説明は割愛する。

ユーザ端末１は、連携アプリケーションの提供を受ける利用者の端末であり、例えば、パーソナルコンピュータ、通信機能を有する携帯電話機、ＰＤＡやゲーム端末等の携帯端末などが該当する。また、ユーザ端末１の内部構成は、図１に示すように、ブラウザ機能部１１、電話機能部１２、セッション連携機能部１３、通信処理部１４を少なくとも有する。

ブラウザ機能部１１は、例えば通信プロトコルとしてＨＴＴＰを用いて、アプリケーションサーバ２が提供するＷｅｂデータや情報（例えば、ＨＴＭＬファイル、画像ファイル、音楽ファイル等）を閲覧する処理部である。また、ブラウザ機能部１１は、通常のブラウザを適用することができ、ＨＴＴＰセッションを管理するためにアプリケーションサーバ２からのＣｏｏｋｉｅ情報を受け取り、これを保持する。

また、ブラウザ機能部１１は、電話発信の後にＷｅｂアクセスする場合、後述するセッション連携機能部１３から、電話機能に係るＳＩＰセッションを特定するセッション情報（ＨＴＴＰパラメータ形式のＣＡＬＬ−ＩＤ等）を受け取り、このセッション情報をＨＴＴＰメッセージに付与し、アプリケーションサーバ２に送信してアクセスを行うものである。

電話機能部１２は、例えばＳＩＰを用いた音声通信を行う処理部である。電話機能部１２は、例えばＲＦＣ３２６１に規定される標準化技術に従って、アプリケーションサーバ２との間でＳＩＰメッセージを送受信することでセッション確立して音声通信を実現する。

また、電話機能部１２は、Ｗｅｂアクセスの後に電話発信を行う場合、後述するセッション連携機能部１３から、Ｗｅｂアクセスに係るＨＴＴＰセッションを特定するセッション情報（ＳＩＰパラメータ形式のＣｏｏｋｉｅ情報等）を受け取り、このセッション情報をＳＩＰメッセージに付与して、アプリケーションサーバ２に送信する。

セッション連携機能部１３は、ブラウザ機能部１１又は電話機能部１２から取得したセッション情報を所定形式に変換し、この変換したセッション情報を電話機能部１２又はブラウザ機能部１１に与えるものである。

図４は、セッション連携機能部１３の機能構成を示すブロック図である。図４に示すように、セッション連携機能部１３は、機能開始指示受取部１３１、セッション情報形式変換部１３２、機能開始指示部１３３を少なくとも有する。

機能開始指示受取部１３１は、アプリケーションサーバ２との間で先に動作している、ブラウザ機能部１１又は電話機能部１２から、今回機能動作を開始する機能開始指示を受け取るものである。

セッション情報形式変換部１３２は、機能開始指示に含まれているセッション情報を、今回通信を開始する通信プロトコルのパラメータ形式に変換するものである。

例えば、セッション情報形式変換部１３２は、Ｗｅｂアクセスの後に電話発信する場合、ブラウザ機能部１１から電話発信指示を受け取ると共に、ＨＴＴＰセッションを特定するセッション情報をＳＩＰパラメータ形式に変換して、電話機能部１２に与えるものである。

また例えば、セッション情報形式変換部１３２は、電話発信の後にＷｅｂアクセスする場合、電話機能部１２からＷｅｂアクセス指示を受け取ると共に、ＳＩＰセッションを特定するセッション情報をＨＴＴＰパラメータ形式に変換して、ブラウザ機能部１１に与えるものである。

ここで、ＳＩＰセッションを特定するセッション情報は、既存技術に基づくものを適用することができ、例えばＣＡＬＬ−ＩＤ等を適用することができる。また、ＨＴＴＰセッションを特定するセッション情報も、既存技術に基づくものを適用することができ、例えば、アプリケーションサーバ２からのＣｏｏｋｉｅ情報を適用することができる。

例えば、ＨＴＴＰのセッション情報をＳＩＰパラメータ形式に変換する場合、セッション連携機能部１３は、ブラウザ機能部１１がＷｅｂアクセスで用いたＣｏｏｋｉｅ情報を取得し、このＣｏｏｋｉｅ情報をＳＩＰパラメータ形式に変換する。

また例えば、ＳＩＰのセッション情報をＨＴＴＰパラメータ形式に変換する場合、セッション連携機能部１３は、電話機能部１２が取得するＣＡＬＬ−ＩＤをＨＴＴＰメッセージであるＨＴＴＰ ＧＥＴのパラメータに変換する。

上記のように、ユーザ端末１側が、ＨＴＴＰ又はＳＩＰのセッション情報の変換を行うことで、サーバ２のアプリケーション処理によるセッション管理処理の負担を軽減しながら、サーバ２側のセッション共有を図ることができる。

機能開始指示部１３３は、セッション情報形式変換部１３２により変換されたセッション情報を含む機能開始指示を、今回通信を行う電話機能部１２又はブラウザ機能部１１に与えるものである。

通信処理部１４は、通信網との間で情報を授受する通信処理部である。

アプリケーションサーバ２は、ユーザに対して複数の機能を連携したアプリケーションを提供するものである。アプリケーションサーバ２は、図１に示すように、ＨＴＴＰを用いたＷｅｂアプリケーションを提供するＨＴＴＰアプリケーション２１と、ＳＩＰを用いて電話機能を提供する電話アプリケーション２２とを有するものである。

ＨＴＴＰアプリケーション２１は、所定のＷｅｂアプリケーションプログラムの実行を行うものである。ＨＴＴＰアプリケーション２１は、所定のアプリケーション処理において、ユーザ端末１との間のセッションを確立し、例えばＣｏｏｋｉｅ情報を生成してユーザ端末１に送信する。また、ＨＴＴＰアプリケーション２１は、例えば、セッション情報とアプリケーションレファレンスとを対応付けるセッション管理を行っている。

電話アプリケーション２２は、ユーザ端末１からの呼接続要求メッセージを受けると、当該ユーザ端末１と通信先との間の呼制御を行うアプリケーションを実行するものである。電話アプリケーション２２は、例えばＲＦＣ３２６１の標準技術に従って、ＣＡＬＬ−ＩＤ等を生成し、このＣＡＬＬ−ＩＤ等を含むＳＩＰメッセージの送受信を行い、またＣＡＬ−ＩＤ等を用いて呼状態の管理を行っている。

さらに、ＨＴＴＰアプリケーション２１及び電話アプリケーション２２は、セッション共有処理部２３を有している。

セッション共有処理部２３は、ＳＩＰのセッション情報とＨＴＴＰのセッション情報との対応付けを行い、ＨＴＴＰ／ＳＩＰセッションの紐付けを行うものである。

（Ａ−２）第１の実施形態の動作
次に、第１の実施形態のセッション共有方式の動作を図面を参照しながら説明する。

第１の実施形態のセッション共有処理は、Ｗｅｂアクセスと電話機能との動作順序に関わらず適用することができる。

そこで、以下では、ユーザ端末１が、Ｗｅｂアクセスを行った後に電話発信する場合と、電話発信を行った後にＷｅｂアクセスを行う場合とに分けて動作を説明する。

（Ａ−１−１）Ｗｅｂアクセスを行った後に電話発信する場合
図５は、Ｗｅｂアクセス後に電話発信する場合のセッションの連携処理を示すシーケンス図である。また、図６は、ユーザ端末１におけるセッション連携処理を示すシーケンス図である。

まず、ユーザ端末１は、所定のＷｅｂサイトへのアクセスを行うために、ブラウザ機能部１１が、Ｗｅｂサイトへのアクセスを要求するＨＴＴＰ ＧＥＴをアプリケーションサーバ２に送信する（ステップＳ１１）。

アプリケーションサーバ２では、ＨＴＴＰ ＧＥＴを受信すると、ＨＴＴＰセッション（Ｃｏｏｋｉｅ情報）を生成し（ステップＳ１２）、ＨＴＴＰアプリケーション２１が、Ｗｅｂアプリケーション処理を行い、Ｃｏｏｋｉｅ情報を含む応答メッセージ（２００ＯＫ）をユーザ端末１に返信する（ステップＳ１３、Ｓ１４）。

これにより、ユーザ端末１では、ブラウザ機能部１１がアプリケーションサーバ２のＷｅｂデータを表示し、アプリケーションサーバ２からのＷｅｂサービスの提供を受けることができる。

その後、ユーザ端末１が、Ｗｅｂサービスと連携する電話機能の連携アプリケーションを受ける場合、セッション連携機能部１３が、Ｗｅｂアクセスに係るセッション情報をＳＩＰパラメータ形式に変換する処理を行う（ステップＳ１５）。

このとき、図６において、ブラウザ機能部１１が、アプリケーションサーバ２からＣｏｏｋｉｅ情報を含むＨＴＴＰ ２００ＯＫを受信すると（ステップＳ１０１）、ブラウザ機能部１１が、セッション連携機能部１３に対して電話発信指示を行う（ステップＳ１０２）。

ブラウザ機能部１１からの電話発信指示には、Ｃｏｏｋｉｅ情報が含まれており、セッション連携機能部１３が、Ｃｏｏｋｉｅ情報をＳＩＰパラメータ形式に変換し（ステップＳ１０３）、その変換したＣｏｏｋｉｅ情報を含む電話発信指示を電話機能部１２に与える（ステップＳ１０４）。

電話機能部１２は、ＳＩＰ ＩＮＶＩＴＥメッセージのヘッダ情報にＣｏｏｋｉｅ情報を付与し、アプリケーションサーバ２に送信する（ステップＳ１０５、図５のステップＳ１６）。

ここで、ＳＩＰメッセージにＣｏｏｋｉｅ情報を付与する方法について説明する。例えば、電話機能部１２は、ＳＩＰ ＩＮＶＩＴＥメッセージのＴｏヘッダ パラメータ、又はＣｏｎｔａｃｔヘッダ パラメータとして、Ｃｏｏｋｉｅ情報を付与することができる。

具体的な例を図７に示す。例えば、図７の例では、Ｃｏｏｋｉｅ情報が「ed29cdffea3527b1」であるとする。

例えば、ＴＯヘッダにＣｏｏｋｉｅ情報を付与する場合、図７（Ａ）に例示するように、「To：＜sip：vxml＠110.5.1.52；Cookie＝ed29cdffea3527b1＞」と変換して付与する。また例えば、ＣｏｎｔａｃｔヘッダにＣｏｏｋｉｅ情報を付与する場合、図７（Ｂ）に例示するように、「Contact：“0095”＜sip：110.5.1.71：5060；Transport＝udp；Cookie＝ed29cdffea3527b1＞」と変換して付与する。さらに、ＳＩＰ拡張ヘッダとして付与する場合、図７（Ｃ）に例示するように、「X-Cookie：ed29cdffea3527b1」に変換して付与する。

また、セッション連携機能部１３と電話機能部１２とがより密接に連携することで、電話発信の際のＣＡＬＬ−ＩＤやＦｒｏｍヘッダのｔａｇ値にＨＴＴＰセッション情報を含めることも可能である。この方式を採用した場合、ＳＩＰヘッダ上の余計なパラメータが不要となるため、ＳＩＰ網との親和性が高まる。独自パラメータがＳＩＰ網の仕様に反する、又は中間ノードでパラメータが自動削除されたりすることがなくなる。

アプリケーションサーバ２では、ＳＩＰ ＩＮＶＩＴＥメッセージの受信により電話アプリケーション２２が起動し、ＳＩＰのセッション情報（例えばＣＡＬＬ−ＩＤ等）の生成を行い（ステップＳ１７）、ＳＩＰ ＩＮＶＩＴＥメッセージに含まれる発信元（ユーザ端末１）と発信先との間の呼制御処理を行う（ステップＳ１８）。

このとき、アプリケーションサーバ２の電話アプリケーション２２は、ＳＩＰ ＩＮＶＩＴＥメッセージに含まれているＣｏｏｋｉｅ情報を抽出し、今回生成したＣＡＬＬ−ＩＤとＣｏｏｋｉｅ情報の対応付けを行い、Ｃｏｏｋｉｅ情報を基にＨＴＴＰセッションとの紐付けを行う。

（Ａ−１−２）電話発信した後にＷｅｂアクセスを行う場合
図８は、電話発信した後にＷｅｂアクセスを行う場合のセッションの連携処理を示すシーケンス図である。また、図９は、ユーザ端末１におけるセッション連携処理を示すシーケンス図である。

まず、ユーザ端末１は、通話を行うために、電話機能部１２が、アプリケーションサーバ２に対してＳＩＰ ＩＮＶＩＴＥメッセージを送信する（ステップＳ２１）。

アプリケーションサーバ２では、ＳＩＰ ＩＮＶＩＴＥメッセージを受信すると、ＳＩＰのセッション情報としてＣＡＬＬ−ＩＤを生成し（ステップＳ２２）、ＳＩＰ ＩＮＶＩＴＥに含まれている発信先との間の呼制御を行い、電話アプリケーション処理を行う（ステップＳ２３）。

そして、ユーザ端末１が電話機能と連携するＷｅｂアクセスを行う際、電話機能部１２はユーザ端末１の通話が終了して切断し（ステップＳ２４）、セッション連携機能部１３がＳＩＰのセッション情報であるＣＡＬＬ−ＩＤをＨＴＴＰパラメータ形式に変換する処理を行う（ステップＳ２５）。

このとき、電話機機能部１２は、アプリケーションサーバ２から通話切断の応答メッセージ（２００ＯＫ）を受信すると（ステップＳ２０１）、電話機能部１２が、セッション連携機能部１３に対してブラウザ起動指示を行う（ステップＳ２０２）。

電話機能部１２からのブラウザ起動指示には、ＣＡＬＬ−ＩＤが含まれており、セッション連携機能部１３は、ＣＡＬＬ−ＩＤをＨＴＴＰパラメータ形式に変換し（ステップＳ２０３）、その変換したＣＡＬＬ−ＩＤを含むブラウザ起動指示をブラウザ機能部１１に与える（ステップＳ２０４）。

ブラウザ機能部１１は、ＨＴＴＰメッセージにＳＩＰセッション情報（ＣＡＬＬ−ＩＤ）を付与し、アプリケーションサーバ２に送信する（ステップＳ２０５、図８のステップＳ２６）。

ここで、ＨＴＴＰメッセージにＳＩＰセッション情報を付与する方法について説明する。例えば、ブラウザ機能部１１は、ＨＴＴＰのＧＥＴメソッドのパラメータ、又はＨＴＴＰ拡張ヘッダとして、ＳＩＰセッション情報（ＣＡＬＬ−ＩＤ等）を付与することができる。

具体的な例を図１０に示す。例えば、図１０の例では、ＣＡＬＬ−ＩＤが「440ca9599ba757fbc9a5a0024728db0e@110.5.1.71」であるとする。

例えば、ＧＥＴメソッドにＣＡＬＬ−ＩＤを付与する場合、図１０（Ａ）に例示するように、「http://www.oki.com/?Call-ID＝440ca9599ba757fbc9a5a0024728db0e@110.5.1.71」と変換して付与する。また例えば、ＨＴＴＰ拡張ヘッダにＣＡＬＬ−ＩＤを付与する場合、図１０（Ｂ）に例示するように、「X-Call-ID：440ca9599ba757fbc9a5a0024728db0e@110.5.1.71」と変換して付与する。

アプリケーションサーバ２では、ＨＴＴＰ ＧＥＴの受信によりＨＴＴＰアプリケーション２１が起動し、ＨＴＴＰのセッション情報（例えばＣｏｏｋｉｅ）の生成を行い（ステップＳ２７）、Ｗｅｂアプリケーション処理を行う（ステップＳ２８、Ｓ２９）。

このとき、アプリケーションサーバ２のＨＴＴＰアプリケーション２１は、ＨＴＴＰ ＧＥＴに含まれているＣＡＬＬ−ＩＤを抽出し、今回生成したＣｏｏｋｉｅ情報とＣＡＬＬ−ＩＤとの対応付けを行い、ＣＡＬＬ−ＩＤを基にＳＩＰセッションとの紐付けを行う。

なお、第１の実施形態では、セッション情報の文字列数は実装依存となるため、ＳＩＰやＨＴＴＰのパラメータとして仕様範囲外の長さになる場合も考えられる。このような場合には、ハッシュ関数を用いて、セッション情報を適切な長さに短縮する方式を採用することができる。

（Ａ−３）第１の実施形態の効果
上記のように、第１の実施形態によれば、ユーザ端末側が連携するアプリケーションのセッション情報をアプリケーションサーバに送信するようにしたので、従来のようにアプリケーションサーバがセッションを紐付けする識別子の生成や管理を行う必要がなくなり、サーバ側のアプリケーション処理負担を軽減することができる。

また、第１の実施形態によれば、連携アプリケーションのタイプとして、Ｗｅｂアクセス、電話発信の両機能の動作順番を問わずに適用することができる。

さらに、従来の方式では、利用者側の電話番号を予め登録することが必要であったが、第１の実施形態によれば、利用者に対して余計な処理を要求する必要がなくなる。

（Ｂ）第２の実施形態
次に、本発明のセッション共有システム、方法及びプログラムの第２の実施形態を図面を参照しながら説明する。

第１の実施形態は、ユーザ端末が、ブラウザ機能部と電話機能部とを備える場合の実施形態を例示したが、第２の実施形態は、ブラウザ機能部と電話機能部とがそれぞれ別のユーザ端末に搭載されている場合の実施形態を例示する。

（Ｂ−１）第２の実施形態の構成
図１１は、第２の実施形態のセッション共有システムの主な構成を示す構成図である。図１１において、第２の実施形態のセッション共有システム９Ｂは、ネットワークを介して、ユーザ端末１−１及び１−２と、アプリケーションサーバ２とが接続する構成である。

ユーザ端末１−１は、例えばパーソナルコンピュータやＰＤＡ等の携帯端末等が該当する。また、ユーザ端末１−１は、ブラウザ機能部１１、セッション連携機能部３１、通信処理部１４を少なくとも有するものである。なお、ブラウザ機能部１１及び通信処理部１４は、第１の実施形態で説明したものと同じ処理部である。

セッション連携機能部３１は、アプリケーションの連携を行う際、ブラウザ機能部１１が保持するＣｏｏｋｉｅ情報を取得し、そのＣｏｏｋｉｅ情報を所定形式に変換するものである。

セッション連携機能部３１は、図１１に示すように、セッション情報形式変換部３１１、表示部３１２を少なくとも有するものである。

セッション情報形式変換部３１１は、第１の実施形態と同様に、ブラウザ機能部１１からのＣｏｏｋｉｅ情報をＳＩＰパラメータ形式に変換する。さらにセッション情報形式変換部３１１は、ＳＩＰパラメータ形式のＣｏｏｋｉｅ情報を二次元コードに変換するものである。ここで、二次元コードの種類は、特に限定されるものではなく、ＱＲコードやＳＰコード等広く適用することができる。第２の実施形態では、ＱＲコードの場合を例示する。なお、ＱＲコードへの変換方法は、既存の変換技術を適用できるのでここでの詳細な説明は省略する。

表示部３１２は、セッション情報形式変換部３１１により変換されたＣｏｏｋｉｅ情報の二次元コードを表示するものである。表示部３１２は、例えば、パーソナルコンピュータ等のディスプレイが該当する。

ユーザ端末１−２は、例えば電話機（固定式電話機、携帯電話機を含む）、電話機能を有するＰＤＡ等の携帯端末等が該当する。ユーザ端末１−２は、電話機能部１２、セッション連携機能部３２、通信処理部１４を少なくとも有する。なお、電話機能部１２及び通信処理部１４は、第１の実施形態で説明したものと同じ処理部である。

セッション連携機能部３２は、ユーザ端末１−１の表示部３１２に表示された二次元コードを読み取り、その二次元コードからＣｏｏｋｉｅ情報を復元し、この復元したＣｏｏｋｉｅ情報をＳＩＰパラメータ形式に変換するものである。

セッション連携機能部３２は、図１１に示すように、ＱＲコード読取部３２１、セッション情報形式変換部３２２を少なくとも有する。

ＱＲコード読取部３２１は、ユーザ端末１−１の表示部３１２に表示された二次元コードを読み取るものである。

セッション情報形式変換部３２２は、ＱＲコード読取部３２１が読み取った二次元コードから、ＳＩＰパラメータ形式に変換されたＣｏｏｋｉｅ情報に変換して、電話機能部１２に与えるものである。

なお、第１の実施形態では、ユーザ端末１−１のセッション連携機能部３１が、Ｃｏｋｋｉｅ情報をＳＩＰパラメータ形式に変換する場合を例示するが、セッション連携機能部３１はブラウザ機能部１１からのＣｏｏｋｉｅ情報をそのまま二次元コード化し、ユーザ端末１−２のセッション連携機能部３２が、二次元コードから復元したＣｏｏｋｉｅ情報をＳＩＰパラメータ形式に変換して電話機能部１２に与えるようにしても良い。

（Ｂ−２）第２の実施形態の動作
次に、第２の実施形態のセッション共有方式の動作を図面を参照しながら説明する。第２の実施形態では、二次元コードを読み取ったユーザ端末１−２が電話発信することを想定しているので、Ｗｅｂアクセス後に電話発信する場合のセッション連携処理を例示する。

図１２は、Ｗｅｂアクセス後に電話発信する場合のセッションの連携処理を示すシーケンス図である。また、図１３は、ユーザ端末１−１及びユーザ端末１−２におけるセッション連携処理を示すシーケンス図である。

まず、第１の実施形態と同様に、ユーザ端末１−１は、所定のＷｅｂサイトへのアクセスを行うために、ブラウザ機能部１１がＨＴＴＰ ＧＥＴを送信し（ステップＳ３０）、アプリケーションサーバ２が、ＨＴＴＰセッションを生成し（ステップＳ３１）、Ｗｅｂアプリケーション処理を行い、Ｃｏｏｋｉｅ情報を含む応答メッセージ（２００ＯＫ）をユーザ端末１−１に返信する（ステップＳ３２、Ｓ３３、図１３のステップＳ３０１）。

その後、利用者がユーザ端末１−２を用いて、Ｗｅｂサービスと連携する電話発信を行う（ステップＳ３４）。

このときユーザ端末１−１において、ブラウザ機能部１１が、セッション連携機能部３１に対して、Ｃｏｏｋｉｅ情報を含む電話発信指示を行う（ステップＳ３０２）。

セッション連携機能部３１において、セッション情報形式変換部３１１は、Ｃｏｏｋｉｅ情報をＳＩＰパラメータ形式に変換し（ステップＳ３０３）、さらにＳＩＰパラメータ形式のＣｏｏｋｉｅ情報を二次元コード化して（ステップＳ３０４）、二次元コード（ＱＲコード）を表示部３１２に表示する。

利用者は、ユーザ端末１−１の表示部３１２に表示された二次元コードをユーザ端末１−２のＱＲコード読取部３２１で読み取り（図１２のステップＳ３５、ステップＳ３０５）、セッション情報変換部３２２が、二次元コードからＣｏｏｋｉｅ情報に変換して、電話機能部１２に与える（ステップＳ３０６）。

そして、電話機能部１２は、第１の実施形態と同様に、ＳＩＰパラメータ形式に変換したＣｏｏｋｉｅ情報をＳＩＰ ＩＮＶＩＴＥメッセージに付加して、アプリケーションサーバ２に送信する（ステップＳ３０７）。その後の処理は、第１の実施形態と同じである。

（Ｂ−３）第２の実施形態の効果
上記のように、第２の実施形態によれば、第１の実施形態の効果に加えて、従来では、ブラウザ機能部と電話機能部とが別端末上に搭載されている場合でも、セッション情報の紐付けができる。

（Ｃ）第３の実施形態
次に、本発明のセッション共有システム、方法及びプログラム、並びにユーザ端末の第３の実施形態を図面を参照しながら説明する。

第１の実施形態では、アプリケーションサーバが１台の場合を例示したが、例えば冗長化や負荷分散に対応するために、アプリケーションサーバを複数台備えるアクト構成で設置することがある。

このような構成の場合、例えば図１４に示すように、Ｗｅｂと電話のリクエストが別サーバに着信した場合に、ＳＩＰ／ＨＴＴＰのセッションが、サーバ間で分離する可能性がある。このような場合、サーバ間でセッションを共有する仕組みのないサーバであれば、ＳＩＰとＨＴＴＰのセッション情報を紐付けることが不可能となる。

そこで、第３の実施形態では、ユーザ端末に返却するセッション情報に、アプリケーションサーバの識別情報（例えばＩＰアドレス等）を付与することで、ネットワーク機器（例えばロードバランサ等）が、同一ユーザのＳＩＰ／ＨＴＴＰ要求を同じサーバに振り分けられるようにするものである。

（Ｃ−１）第３の実施形態の構成
図１５は、第３の実施形態のセッション共有システムの主な構成を示す構成図である。図１５示すように、第３の実施形態のセッション共有システム９Ｃは、ユーザ端末１が、ロードバランサ４を介してアプリケーションサーバ２−１〜２−３に接続している。

ロードバランサ４は、ユーザ端末１側から受信したパケットをアプリケーションサーバ２−１〜２−３に振り分ける負荷分散装置である。ロードバランサ４は、通常のロードバランサの機能に加えて、図１５に示すように、要求メッセージ振分部４１を有する。

要求メッセージ振分部４１は、ユーザ端末１から受信した要求メッセージに基づいて、アプリケーションサーバ２−１〜２−３のいずれかに当該要求メッセージを振り分けるものである。

図１６は、要求メッセージ振分部４１の機能構成を示すブロック図である。要求メッセージ振分部４１は、サーバ情報判定部４１１と、要求メッセージ振分実行部４１２とを少なくとも有する。

サーバ情報判定部４１２は、ユーザ端末１から受信した要求メッセージに含まれているサーバ情報に基づいて、要求メッセージの送信先を判定するものである。ここで、サーバ情報としては、例えば、アプリケーションサーバ２−１〜２−３のＩＰアドレスなどが該当する。

要求メッセージ振分実行部４１２は、サーバ情報判定部４１２の判定結果に応じて、等級メッセージの振り分けを行うものである。

アプリケーションサーバ２−１〜２−３は、第１の実施形態で説明したアプリケーションサーバと同様のものであり、ロードバランサ４により負荷分散を受けている。そのため、ＨＴＴＰ／ＳＩＰセッションがアプリケーションサーバ間で分離する場合があるが、第３の実施形態のアプリケーションサーバ２−１〜２−３は、これを回避するためにサーバ情報付与部４２を備える。

サーバ情報付与部４２は、ユーザ端末１に返信する応答メッセージに、自サーバのサーバ情報を付与するものである。つまり、アプリケーションサーバ２−１〜２−３は、応答メッセージに、セッション情報とサーバ情報とを付与して送信する。

（Ｃ−２）第３の実施形態の動作
次に、第３の実施形態のセッション共有処理の動作を図面を参照しながら説明する。以下では、Ｗｅｂアクセス後に電話発信する場合の処理を例示するが、電話発信後にＷｅｂアクセスする場合の処理も同様の処理を適用することができる。

図１７は、Ｗｅｂアクセス後に電話発信する場合のセッションの連携処理を示すシーケンス図である。

まず、第１の実施形態と同様に、ユーザ端末１は、Ｗｅｂサイトへのアクセスを行うために、ブラウザ機能部１１がＨＴＴＰ ＧＥＴを送信する（ステップＳ４１）。このとき、ＨＴＴＰ ＧＥＴの送信先は、例えばロードバランサ４の仮想ノードのアドレスとなっている。

ロードバランサ４は、ＨＴＴＰ ＧＥＴを受信すると、所定の負荷分散等の処理を行い、対応するアプリケーションサーバにＨＴＴＰ ＧＥＴを送信する。ここでは、アプリケーションサーバ２−２にＨＴＴＰ ＧＥＴを送信する場合を例示する。

アプリケーションサーバ２−２では、ＨＴＴＰセッション（Ｃｏｏｋｉｅ情報）を生成し（ステップＳ４２）、Ｗｅｂアプリケーション処理を行う（ステップＳ４３）。さらに、アプリケーションサーバ２−２は、サーバ情報付与部４２が自サーバのサーバ情報を応答メッセージに付与してユーザ端末１に送信する（ステップＳ４４）。

ユーザ端末１では、応答メッセージを受信すると（ステップＳ４５）、第１の実施形態と同様にしてセッション連携処理を行い（ステップＳ４７）、電話機能部１２が、ＳＩＰパラメータ形式に変換されたＣｏｏｋｉｅ情報とアプリケーションサーバ２−２のサーバ情報をＳＩＰ ＩＮＶＩＴＥメッセージに付与して、ロードバランサ４に送信する（ステップＳ４７）。

ロードバランサ４は、ユーザ端末１からＳＩＰ ＩＮＶＩＴＥメッセージを受信すると、サーバ情報判定部４１１が、ＳＩＰ ＩＮＶＩＴＥメッセージに含まれているサーバ情報に基づいて、アプリケーションサーバ２−２宛の要求メッセージであることを判定し、要求メッセージ振分実行部４１２が、アプリケーションサーバ２−２に当該ＳＩＰ ＩＮＶＩＴＥメッセージを送信する（ステップＳ４８）。

これにより、当該Ｗｅｂサービスと連携する電話アプリケーションを提供するアプリケーションサーバ２−２に、ＨＴＴＰのセッション情報（Ｃｏｏｋｉｅ情報）を含むＳＩＰ ＩＮＶＩＴＥメッセージを与えることができ、ＨＴＴＰ／ＳＩＰセッションの紐付けができる。

なお、これ以降の処理は、第１の実施形態と同様であるので説明を省略する。

（Ｃ−３）第３の実施形態の効果
上記のように、第３の実施形態によれば、第１の実施形態の効果に加えて、サーバ間でセッションを共有する仕組みのないサーバであっても、アプリケーションサーバをアクト構成で複数台設置することが可能となる。

（Ｄ）他の実施形態
上述した第１〜第３の実施形態では、呼制御に係る通信プロトコルにＳＩＰを用いる場合を例示したが、ＳＩＰに限定されるものではなく、例えば、ＩＴＵ−ＴのＨ．３２３勧告やＭＧＣＰ等にも適用することができる。

第２の実施形態では、ユーザ端末間でセッション情報を授受する手段として、例えば、ＱＲコード等の二次元コードを用いることとしたが、これに限定されるものではなく、１次元コードを用いるようにしても良い。この場合、ユーザ端末が一次元コードの読み取り手段を設けることが必要となる。また例えば、ユーザ端末間でＵＳＢ接続等によりセッション情報の授受を行うようにしても良い。

第３の実施形態では、第１の実施形態の構成を基本として、複数台のアプリケーションサーバを備える構成の場合を例示したが、第２の実施形態においても同様に適用することができる。

１、１−１及び１−２…ユーザ端末、
１１…ブラウザ機能部、１２…電話機能部、１３、３１、３２…セッション連携機能部、
１３１…機能開始指示受取部、１３２、３１１、３２２…セッション情報形式変換部、
１３３…機能開始指示部、３１２…表示部、３２１…ＱＲコード読取部、
１４…通信処理部、
２、２−１〜２−３…アプリケーションサーバ、
２１…ＨＴＴＰアプリケーション、２２…電話アプリケーション、
４…ロードバランサ、４１…要求メッセージ振分部、４１１…サーバ情報判定部、
４１２…要求メッセージ振分実行部。

Claims (7)

1. １又は複数のアプリケーションサーバが複数のアプリケーションを連携するシステムで、それぞれのセッションを共有するセッション共有システムにおいて、
   第１の通信処理プロトコルを用いて上記各アプリケーションサーバから第１のアプリケーションサービスの提供を受ける第１の機能処理手段と、
   第２の通信処理プロトコルを用いて上記各アプリケーションサーバから第２のアプリケーションの提供を受ける第２の機能処理手段と、
   上記第１の機能処理手段又は上記第２の機能処理手段から取得した上記各アプリケーションサーバとの間で確立したセッション情報を所定形式に変換し、上記第２の機能処理手段又は上記第１の機能処理手段に与えるセッション情報連携手段と
   を備え、
   上記第２の機能処理手段又は上記第１の機能処理手段が、上記セッション情報連携手段からの変換セッション情報を含む要求メッセージを、上記各アプリケーションサーバに送信し、
   上記各アプリケーションサーバが、上記要求メッセージに含まれる上記変換セッション情報と、今回の通信処理プロトコルにより生成したセッション情報との対応付けを行う
   ことを特徴とするセッション共有システム。
2. 上記セッション情報連携手段が、上記各アプリケーションサーバとの間で先に確立したセッション情報を、今回通信する通信プロトコル形式に変換するものであることを特徴とする請求項１に記載のセッション共有システム。
3. 第１のユーザ端末が、上記第１の機能処理手段と上記セッション情報連携手段とを備え、
   第２のユーザ端末が、上記第２の機能処理手段と上記セッション情報連携手段とを備え、
   上記第１のユーザ端末の上記セッション情報連携手段が、上記セッション情報を二次元コードに変換し、変換した二次元コードを表示部への表示を行うものであり、
   上記第２のユーザ端末の上記セッション情報連携手段が、上記第１のユーザ端末の上記表示部に表示された上記二次元コードを読み取り、上記セッション情報の復元を行うものである
   ことを特徴とする請求項１に記載のセッション共有システム。
4. 上記各アプリケーションサーバが、確立した上記セッション情報及び自身のサーバ識別情報を付与した情報をユーザ端末に送信するサーバ情報付与部を備え、
   上記第２の機能処理手段又は上記第１の機能処理手段から送信された上記セッション情報及び上記サーバ識別情報を含む要求メッセージを受信し、上記サーバ識別情報に基づいて当該要求メッセージを振り分けるメッセージ振分手段を備えることを特徴とするセッション共有システム。
5. １又は複数のアプリケーションサーバが複数のアプリケーションを連携するシステムで、それぞれのセッションを共有するセッション共有方法において、
   第１の機能処理手段が、第１の通信処理プロトコルを用いて上記各アプリケーションサーバから第１のアプリケーションサービスの提供を受ける第１の機能処理工程と、
   第２の機能処理手段が、第２の通信処理プロトコルを用いて上記各アプリケーションサーバから第２のアプリケーションの提供を受ける第２の機能処理工程と、
   セッション情報連携手段が、上記第１の機能処理手段又は上記第２の機能処理手段から取得した上記各アプリケーションサーバとの間で確立したセッション情報を所定形式に変換し、上記第２の機能処理手段又は上記第１の機能処理手段に与えるセッション情報連携工程と、
   上記第２の機能処理手段又は上記第１の機能処理手段が、上記セッション情報連携手段からの変換セッション情報を含む要求メッセージを、上記各アプリケーションサーバに送信する工程と、
   上記各アプリケーションサーバが、上記要求メッセージに含まれる上記変換セッション情報と、今回の通信処理プロトコルにより生成したセッション情報との対応付けを行う工程と
   を有することを特徴とするセッション共有方法。
6. 複数のアプリケーションを連携するシステムで、１又は複数のアプリケーションサーバにそれぞれのセッションを共有させるセッション共有プログラムにおいて、
   ユーザ端末を、
   第１の通信処理プロトコルを用いて上記各アプリケーションサーバから第１のアプリケーションサービスの提供を受ける第１の機能処理手段、
   第２の通信処理プロトコルを用いて上記各アプリケーションサーバから第２のアプリケーションの提供を受ける第２の機能処理手段、
   上記第１の機能処理手段又は上記第２の機能処理手段から取得した上記各アプリケーションサーバとの間で確立したセッション情報を所定形式に変換し、上記第２の機能処理手段又は上記第１の機能処理手段に与えるセッション情報連携手段
   として機能させ、
   上記第２の機能処理手段又は上記第１の機能処理手段が、上記セッション情報連携手段からの変換セッション情報を含む要求メッセージを、上記各アプリケーションサーバに送信する機能することを特徴とするセッション共有プログラム。
7. 複数のアプリケーションを連携するシステムで、１又は複数のアプリケーションサーバにそれぞれのセッションを共有させるセッション共有システムを構成するユーザ端末において、
   第１の通信処理プロトコルを用いて上記各アプリケーションサーバから第１のアプリケーションサービスの提供を受ける第１の機能処理手段と、
   第２の通信処理プロトコルを用いて上記各アプリケーションサーバから第２のアプリケーションの提供を受ける第２の機能処理手段と、
   上記第１の機能処理手段又は上記第２の機能処理手段から取得した上記各アプリケーションサーバとの間で確立したセッション情報を所定形式に変換し、上記第２の機能処理手段又は上記第１の機能処理手段に与えるセッション情報連携手段と
   を備え、
   上記第２の機能処理手段又は上記第１の機能処理手段が、上記セッション情報連携手段からの変換セッション情報を含む要求メッセージを、上記各アプリケーションサーバに送信することを特徴とするユーザ端末。

Images