(57)【要約】【課題】サービスを提供するサーバの負荷の増大を抑えると共に、メッセージの自動振分に対応できる、異なる端末装置間でサービスの継続利用を可能とするための技術を提供する。【解決手段】ＧＷ装置２０は、動画配信サーバ６０が提供するサービスを利用している端末装置１０のユーザに係わる属性情報を、その動画配信サーバ６０が生成した状態（セッション）６２の識別子６３と対応付けて保存する。端末装置１０から識別子６３が付加されていないメッセージを受信すると、その端末装置１０のユーザの属性情報をＳＡＭＬ認証サーバ３０から取得し、取得した属性情報と一致する属性情報が保存されているか否か確認する。その確認により、一致する属性情報が存在していることが判明すると、その属性情報に対応付けた識別子を受信したメッセージに挿入してＳＬＢ５０に送信する。【選択図】図１
2011076425.tif 000002
【特許請求の範囲】
【請求項１】
通信ネットワークを介して端末装置からサーバに送信されるメッセージを中継する中継装置であって、
前記メッセージを受信した前記端末装置のユーザに係わる属性情報を取得する属性情報取得手段と、
前記端末装置からのメッセージによりセッションを生成したサーバが該端末装置へのメッセージ中に挿入する、該セッションを識別するための識別子を取得する識別子取得手段と、
前記識別子取得手段が取得した識別子を、前記属性情報取得手段が取得した属性情報と対応付けて保存する情報保存手段と、
前記属性情報取得手段が属性情報を取得した場合に、該取得した属性情報と一致する属性情報を前記情報保存手段が保存しているか否か判定する判定手段と、
前記属性情報取得手段が取得した属性情報に一致する属性情報を前記情報保存手段が保存していると前記判定手段が判定した場合に、該属性情報取得手段が属性情報を取得する契機となったメッセージ中に該属性情報に対応付けられた識別子を挿入する識別子挿入手段と、
前記識別子挿入手段が識別子を挿入したメッセージを送信する中継手段と、
を具備することを特徴とする中継装置。
【請求項２】
前記情報保存手段は、前記識別子、及び前記属性情報を、前記識別子が挿入されたメッセージにより前記サーバに要求されるサービスと対応付けて保存する、
ことを特徴とする請求項１記載の中継装置。
【請求項３】
前記属性情報取得手段は、前記端末装置のユーザが認証済みであることを示す認証情報を用いて、該ユーザに係わる属性情報を取得する、
ことを特徴とする請求項１、または２記載の中継装置。
【請求項４】
前記識別子挿入手段は、前記端末装置から受信したメッセージの通信プロトコルを判別し、該判別結果に応じて、該メッセージ中に前記識別子を挿入する位置を決定する、
ことを特徴とする請求項１記載の中継装置。
【請求項５】
端末装置のユーザに通信ネットワークを介してサーバが提供するサービスを該ユーザが使用する異なる端末装置の間で継続して利用可能とする方法において、
前記通信ネットワークを介して前記端末装置から前記サーバに送信されるメッセージを中継する中継装置に、
前記メッセージを前記端末装置から受信した場合に、該端末装置のユーザに係わる属性情報を取得させ、
前記端末装置からのメッセージによりセッションを生成したサーバが該端末装置へのメッセージ中に挿入する、該セッションを識別するための識別子を取得させ、
該識別子を、該識別子を挿入したメッセージを送信する端末装置のユーザに係わる属性情報と対応付けて保存させ、
前記メッセージを前記端末装置から受信した場合に、前記メッセージの受信により取得する属性情報と一致する属性情報が保存されているか否か判定させ、
前記一致する属性情報が保存されていると判定した場合に、前記端末装置から受信したメッセージ中に該一致する属性情報に対応付けられた識別子を挿入して送信する中継を行わせる、
ことを特徴とする異なる端末装置間のサービス継続方法。
【請求項６】
前記属性情報を取得する契機となったメッセージにより前記サーバに要求されるサービスを特定し、該特定したサービスは該属性情報と対応付けて保存する、
ことを特徴とする請求項５記載の異なる端末装置間のサービス継続方法。
【請求項７】
前記属性情報は、前記端末装置のユーザが認証済みであることを示す認証情報を用いて取得する、
ことを特徴とする請求項５、または６記載の異なる端末装置間のサービス継続方法。
【請求項８】
通信ネットワークを介して端末装置からサーバに送信されるメッセージを中継する中継装置として用いられるコンピュータに、
前記メッセージを受信した前記端末装置のユーザに係わる属性情報を取得する属性情報取得機能と、
前記端末装置からのメッセージによりセッションを生成したサーバが該端末装置へのメッセージ中に挿入する、該セッションを識別するための識別子を取得する識別子取得機能と、
前記識別子取得機能により取得した識別子を、前記属性情報取得機能により取得した属性情報と対応付けて保存する情報保存機能と、
前記属性情報取得機能により属性情報を取得した場合に、該取得した属性情報と一致する属性情報を前記情報保存機能により保存しているか否か判定する判定機能と、
前記属性情報取得機能により取得した属性情報に一致する属性情報を前記情報保存機能により保存していると前記判定機能により判定した場合に、該属性情報取得機能による属性情報を取得する契機となったメッセージ中に該属性情報に対応付けられた識別子を挿入する識別子挿入機能と、
前記識別子挿入機能により識別子を挿入したメッセージを送信する中継機能と、
を実現させるための中継プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、通信ネットワークを介してサーバが端末装置のユーザにサービスを提供するための技術に関する。
【背景技術】
【０００２】
現在、インターネットに代表される通信ネットワークは広く社会に普及している。それにより、サーバを用いて、通信ネットワークと接続されたクライアントである端末装置のユーザを対象にした様々なサービスが提供されるようになっている。
【０００３】
サービスを提供するサーバは、端末装置から受信したメッセージによりセッションを生成し、その端末装置のユーザを対象にしたサービスを提供する。このセッションは、サーバが１端末装置にサービスを提供するうえでの単位に相当する。このセッションを生成したサーバは、端末装置へのレスポンスとするメッセージに、生成したセッションを識別するための識別子を挿入して送信する。識別子が挿入されたメッセージを受信した端末装置は以降、その識別子を挿入したメッセージをサーバ宛てに送信する。それによりサーバは、端末装置から受信したメッセージ中の識別子により、サービスの提供を継続させることができる。
【０００４】
通信ネットワークを介して提供するサービスは通常、多くの人の利用を想定する。利用する人が多くなるほど、サーバの負荷は増大する。このことから、サービスを提供する側は、複数のサーバを用意し、端末装置のユーザにサービスを提供させるサーバをそのうちの一つに振り分ける負荷分散を行うシステム構成を採用するのが普通である。この負荷分散は通常、ＳＬＢ（Server Load Balancer：負荷分散装置）を用いて行われる。
【０００５】
ＳＬＢは、識別子とその識別子が割り当てられたセッションを保持するサーバとの関係を保存する。それによりＳＬＢは、識別子が挿入されたメッセージを端末装置から受信した場合、その識別子を有する関係を保存しているか否か確認し、その確認結果に応じて、メッセージの振分先を決定する。決定される振分先は、識別子を有する関係が保存されていれば、その関係から特定されるサーバであり、識別子を有する関係が保存されていなければ、ラウンドロビン方式等の自律振分アルゴリズムにより選択したサーバである。そのように振分先を決定することによりＳＬＢは、同じ端末装置から送信される関連するメッセージは同じサーバに振り分ける一意性保証を実現する。この一意性保証を実現する機能は一意性保証機能（或いはセッション維持機能）と呼ばれる。この一意性保証の実現に用いる関係は以降「一意性保証情報」と呼ぶことにする。自律振分アルゴリズムにより振り分けるメッセージ、つまりサーバがセッションを生成する契機となるメッセージは以降「初期メッセージ」と呼ぶこととする。
【０００６】
近年、携帯電話機は多機能化し、大部分の携帯電話機は端末装置として使用できるようになっている。パーソナル・コンピュータ（ＰＣ）は安価になり、複数台のＰＣを所有する人は多い。このようなこともあり、ユーザの多くは、複数の端末装置を使用することができる。
【０００７】
ユーザが端末装置を変えてサービスを利用する場合、各端末装置から最初に送信させるメッセージは、何れも初期メッセージとしてサーバに処理される。そのように初期メッセージとして処理した場合、或る端末装置により利用していたサービスは他の端末装置では継続利用することはできない。しかし、ユーザは、異なる端末装置（複数の端末装置）の間でサービスを継続して利用することを望む場合がある。例えば映像の配信サービスでは、ユーザは、端末装置を変えても、視聴中の映像は視聴していない箇所から視聴を継続したいと望むことが多い。このようなことから現在では、異なる端末装置の間でサービスを継続して利用できるようにする技術が創案されている。この技術は以降「サービス継続技術」と呼ぶことにする。
【０００８】
従来のサービス継続技術としては、例えば特許文献１及び２に記載されたものがある。特許文献１に記載の従来のサービス継続技術では、サービスの継続を可能とさせるための専用のデバイスを用意して、その専用デバイスにセッショに係わる情報（セッション情報）を記録する。この記録したセッション情報を用いることにより、別の端末装置でサービスの継続を可能とさせる。そのようにして専用デバイスは、異なる端末装置間でのセッション情報の共有化に用いる。専用デバイスは、端末装置との通信により、セッション情報の取得、更新、或いは提供を行う。
【０００９】
特許文献２に記載の従来のサービス継続技術では、サービスを提供するサーバは、端末装置にユーザが入力した識別情報（ユーザＩＤ）を受信して、関係がある既存のセッションが存在するか否か判定する。その判定結果に応じてサーバは、新たなセッションの生成、及び既存のセッションへの再関連の何れかを行う。そのセッションへの再関連により、ユーザは別の端末装置を用いてサービスの継続した利用を行うことができる。
【００１０】
専用デバイスを用意する場合、サービスを提供するうえでのコストの上昇、或いはユーザの経済的負担を増大させる。また、端末装置（に実行させるプログラム）は、専用デバイスに対応させる必要がある。その対応のために、端末装置のユーザは煩わしい操作等を行わなければならない。このようなことから、特許文献１に記載の従来のサービス継続技術は、望ましいものではない。
【００１１】
特許文献２に記載の従来のサービス継続技術では、コストの上昇やユーザの経済的負担の増大は共に抑えることができる。しかし、サーバは、識別情報の受信により、既存のセッションのなかから関連するセッションを抽出しなければならない。このため、サーバの負荷は増大する。この負荷の増大は、サービスの質の低下、或いは必要とするサーバの台数の増加、等の不具合を生じさせる。負荷の増大は、多くの人が利用するほど深刻化する。通信ネットワークを介したサービスは、多くの人が利用するのを想定している。このようなことから、サーバにおける負荷の増大は抑えるのが望ましい。
【００１２】
上記の通り、多くの人の利用を想定する場合、サービスを提供する側は、複数のサーバを用意し、ＳＬＢによりメッセージを自動振分するシステム構成を採用するのが普通である。特許文献２に記載の従来のサービス継続技術は、そのようなシステム構成には対応できない。なぜなら、メッセージを自動振分するＳＬＢは、ユーザが入力した識別情報（ユーザＩＤ）からメッセージを送信すべきサーバを特定できないからである。このようなことから、異なる端末装置間のサービスの継続利用では、サーバの負荷の増大を抑える他に、ＳＬＢを用いたシステム構成、つまりメッセージの自動振分にも対応できるようにすることも重要である。
【先行技術文献】
【特許文献】
【００１３】
【特許文献１】特開２００６−１９１６１７号公報
【特許文献２】特開２００８−１０２９４０号公報
【発明の概要】
【発明が解決しようとする課題】
【００１４】
本発明は、サービスを提供するサーバの負荷の増大を抑えると共に、メッセージの自動振分に対応できる、異なる端末装置間でサービスの継続利用を可能とするための技術を提供することを目的とする。
【課題を解決するための手段】
【００１５】
開示のシステムでは、端末装置と、その端末装置のユーザに通信ネットワークを介してサービスを提供するサーバとの間に、端末装置からサーバに送信されるメッセージを中継する中継装置を配置する。その中継装置は、メッセージを端末装置から受信した場合に、その端末装置のユーザに係わる属性情報を取得し、端末装置からのメッセージによりセッションを生成したサーバがその端末装置へのメッセージ中に挿入する、そのセッションを識別するための識別子を取得し、取得した識別子を、その識別子を挿入したメッセージを送信する端末装置のユーザに係わる属性情報と対応付けて保存し、メッセージを端末装置から受信した場合に、そのメッセージの受信により取得する属性情報と一致する属性情報が保存されているか否か判定し、一致する属性情報が保存されていると判定した場合に、その端末装置から受信したメッセージ中に一致する属性情報に対応付けられた識別子を挿入して送信する中継を行う。
【発明の効果】
【００１６】
開示のシステムでは、実際にサービスを提供するサーバの負荷の増大を抑えつつ、メッセージの自動振分が行われるシステム構成であっても、異なる端末装置間でユーザはサービスを継続利用することができる。
【図面の簡単な説明】
【００１７】
【図１】本実施形態による中継装置を用いて構築されたサービス提供システムの構成を示す図である。
【図２】本実施形態による中継装置であるＧＷ装置２０の機能構成図である。
【図３】端末装置１０を代えて動画配信サービスを利用する例のタイミングチャートである。
【図４】携帯端末装置１１、ＰＣ１２、各ＳＬＢ５０、ＳＡＭＬ認証サーバ３０、及び動画配信サーバ６０の動作例を示すシーケンス図である。
【図５】携帯端末装置１１、ＰＣ１２、各ＳＬＢ５０、ＳＡＭＬ認証サーバ３０、動画配信サーバ６０、及び一意性保証情報設定管理装置７０の動作例を示すシーケンス図である。
【図６】属性種別情報テーブル２５のデータ構成を説明する図である。
【図７】属性／識別子情報テーブル２６のデータ構成、及びエントリへのデータの格納手順を説明する図である。
【図８】サービス名抽出テーブル２７のデータ構成を説明する図である。
【図９】セッション位置抽出テーブル２８のデータ構成を説明する図である。
【図１０】認証問い合わせ要求と認証アサーションの構文例を説明する図である。
【図１１】属性問い合わせ要求と属性アサーションの構文例を説明する図である。
【図１２】ＳＩＰメッセージ例を説明する図である。
【図１３】ＨＴＴＰメッセージ例を説明する図である。
【図１４】メッセージ中継処理のフローチャートである。
【図１５】本発明を適用可能なコンピュータのハードウェア構成の一例を示す図である。
【発明を実施するための形態】
【００１８】
以下、本発明の実施形態について、図面を参照しながら詳細に説明する。
図１は、本実施形態による中継装置を用いて構築されたサービス提供システムの構成を示す図である。このサービス提供システムは、不図示の通信ネットワークを介して接続されるクライアントである端末装置１０のユーザを対象にサービスを提供するために構築されている。図１には端末装置１０として、携帯電話機、ＰＤＡ、或いはノート型のＰＣ等の携帯が容易な携帯端末装置１１、及びデスクトップ型、或いはノート型の通常は携帯しないＰＣ１２を示している。端末装置１０は、それらに限定されるものではなく、通信ネットワークを介した通信が可能なテレビジョン、及びカーナビゲーション装置等も端末装置１０として使用するのが可能である。ここでは便宜的に、端末装置１０としては携帯端末装置１１、及びＰＣ１２のみを想定することとする。携帯端末装置１１、及びＰＣ１２の表記は、端末装置１０を区別する場合にのみ用いる。区別する必要がない場合は端末装置１０と表記する。
【００１９】
サービス提供システムは、ＧＷ（GateWay）装置２０、ＳＡＭＬ（Security Assertion Markup Language）認証サーバ３０、及びサービス処理システム４０を備えている。本実施形態による中継装置は、ＧＷ装置２０として実現されている。
【００２０】
ＳＡＭＬは、周知のように、ＩＤ／パスワードなどの認証情報を安全に交換するための仕様である。ＳＡＭＬ認証サーバ３０は、端末装置１０から送信される認証情報を用いて認証を行い、その認証によって端末装置１０のユーザがアカウントの登録者であることを確認した場合に、認証済みであることを示すアーティファクト（認証情報）を発行する。
【００２１】
アーティファクトは、他のサイトへのアクセスを可能にするＧＳＳＯ（Global Single Sign On）を実現させる。ＳＡＭＬ認証サーバ３０は、アーティファクトにより、そのアーティファクトから特定されるアサーションを発行する。ＧＳＳＯは、このアサーションを他のサイトが信用し、認証済みと見なすことで実現される。ＳＡＭＬ仕様では、アサーションとして、認証済みのユーザについての情報を伝えるメッセージである認証アサーション、そのユーザの属性情報を伝える属性アサーション、ユーザ（サブジェクト）が特定のリソースへのアクセスが許可されているか否かを示す認可決定アサーションの３種類が存在する。
【００２２】
このように、ＳＡＭＬ認証サーバ３０はＧＳＳＯを実現させるために用意される。複数のサイトで認証結果を利用できることから、サービス提供システムにとって必須の構成要素ではない。ＳＡＭＬ認証サーバ３０は、他のサイトに用意されたものであっても良く、複数のサイトにそれぞれ用意されていても良い。ここでは便宜的に、ＳＡＭＬ認証サーバ３０は１台のみとする。
【００２３】
ＳＡＭＬ認証サーバ３０は、認証のためにリポジトリ３１を備えている。このリポジトリ３１は、具体的には例えば補助記憶装置、或いは接続されたストレージ装置である。リポジトリ３１には、認証情報データベース（ＤＢ）３５、認証アサーション情報テーブル３６、及び属性情報ＤＢ３７が格納されている。
【００２４】
認証情報ＤＢ３５には、アカウントの登録者毎にその認証情報が格納されている。図１中に表記の「ｉｄ０１／ｐａｓ１」は、認証情報として格納されたＩＤ／パスワードを表している。ここでは、認証情報としてＩＤ／パスワードを想定する。
【００２５】
認証済みか否かの確認は、アーティファクトによるＳＡＭＬ認証サーバ３０のアサーションの発行の有無から行われる。認証アサーション情報テーブル３６は、発行したアーティファクトとそのアーティファクトが割り当てられたアサーションの対応関係を管理するためのテーブルである。図１中の１エントリ（レコード）に表記の「ＡＡＡ」「携帯端末ユーザＡ」は、携帯端末装置１１を使用するユーザＡの認証によって「ＡＡＡ」のアーティファクトが発行されたことを表している。実際には、１エントリに、アーティファクトと、例えばそのアーティファクトが割り当てられた認証アサーション、属性アサーションの各保存場所を示す保存場所情報とが格納される。ＳＡＭＬ認証サーバ３０は、認証を行う度に、認証アサーション情報テーブル３６にエントリ（レコード）を追加する。
【００２６】
属性情報ＤＢ３７は、アカウントの登録者毎に、その登録者に係わる属性情報を格納したテーブルである。図１中の１エントリに表記の「ＣＮ＝Ｔａｒｏ  Ｓｕｚｕｋｉ，ＴＥＩＤ＝ｉｄ０１，ＵＩＤ＝ｉｄ０３」は、氏名（ＣＮ）はＴａｒｏ  Ｓｕｚｕｋｉ、携帯端末装置１２でのＩＤ（端末ＩＤ）はｉｄ０１、ＰＣ１２でのＩＤはｉｄ０３、であることを表している。属性情報としては他に、誕生日（ＤＢ）、都市名（Ｌ）、都道府県名（ＳＴ）、国名（Ｃ）、等が存在する。組織に属する人では、属性情報に、グループ名（ＯＧ）、組織名（ＯＵ）、職種（Ｏ）が含まれる。認証アサーション、及び属性アサーションは、この属性情報ＤＢ３７から抽出される属性情報を用いて生成される。
【００２７】
ＧＷ装置２０は、端末装置１０と不図示の通信ネットワークを介して接続され、端末装置１０から送信されたメッセージを中継する。サービスの提供に係わるメッセージは、サービス処理システム４０に転送する。それにより、サービス処理システム４０にメッセージを処理させ、端末装置１０のユーザが望むサービスの提供を実現させる。
【００２８】
サービス処理システム４０は、例えば通信プロトコル毎に用意されたＳＬＢ５０、動画配信サービス等の複数のサービスを提供する複数の動画配信サーバ６０、及びＳＬＢ５０への一意性保証情報の設定を管理する一意性保証情報設定管理装置７０を備えている。
【００２９】
図１では、ＳＬＢ５０として、５０ａ及び５０ｂの符号を付した２台を示している。動画配信サーバ６０も、６０ａ及び６０ｂを付した２台を示している。５０ａ、５０ｂ、６０ａ及び６０ｂの各符号も端末装置１０と同様に、区別する必要がある場合のみ用いることとする。
【００３０】
各動画配信サーバ６０は、アプリケーション・プログラム（以降「アプリケーション」と略記）６１を実行することにより、端末装置１０のユーザを対象にしたサービスを提供する。サービスを提供していないユーザが使用する端末装置１０から送信されたメッセージ（初期メッセージ）を受信すると、状態６２を生成し、その状態６２を一意に識別できる識別子６３を割り当てる。図１中に表記の「α１」は識別子６３を表している。
【００３１】
上記サービスとは、動画の配信に係わるものである。サービスの種類は特に限定するものではないが、ここでは便宜的に、映画やドラマ等の動画配信サービス、テレビジョン会議用に動画と音声を配信するＴＶ会議サービスを想定する。サービスの提供は、状況に応じた処理をアプリケーション６１が実行することにより実現される。状態６２は、状況に応じた処理を実行するために生成する。このことから、状態６２はセッションを維持している間のみ存在する、セッションの存在の他に、状況を示す情報である。
【００３２】
アプリケーション６１は、状態（セッション）６２を生成すると、そのセッションに係わるデータ（セッションデータ）を保存する。そのセッションデータは、識別子６３、及びセッションに付随するデータを含むものである。アプリケーション６１には、セッション情報監視・通知部６１ａが搭載されている。この通知部６１ａは、アプリケーション６１によるセッションの生成を監視し、生成されたセッションに係わる情報（セッション情報）を一意性保証情報設定管理装置（以降「設定管理装置」と略記）７０に通知する。このセッション情報は少なくとも識別子６３を含んでいる情報である。
【００３３】
ＳＬＢ５０は、通信プロトコル毎に用意されている。初期メッセージは１台のＳＬＢ５０によって１台の動画配信サーバ６０に転送され、その動画配信サーバ６０は、識別子６３を挿入したメッセージをレスポンスとしてそのＳＬＢ５０に送信する。このため、同じ端末装置１０から送信される関連するメッセージを同じ動画配信サーバ６０に転送するための一意性保証情報は、初期メッセージを転送したＳＬＢ５０にのみ設定されるのが普通である。しかし、このように一意性保証情報を設定した場合、端末装置１０から通信プロトコルを変えて送信されるメッセージは、転送すべき動画配信サーバ６０に転送できるとは限らない。本実施形態では、そのような通信プロトコルの変更は、設定管理装置７０により対応できるようにしている。
【００３４】
設定管理装置７０は、動画配信サーバ６０からセッション情報を取得すると、そのセッション情報を用いて、初期メッセージを転送していないＳＬＢ５０に設定すべき一意性保証情報を生成し、そのＳＬＢ５０に送信する。そのようにして、初期メッセージを転送していないＳＬＢ５０にも一意性保証情報を登録させることにより、複数の通信プロトコル間の連携を可能とさせる一意性保証を実現させる。本実施形態では、初期メッセージを転送したＳＬＢ５０への一意性保証情報の登録も併せて行わせている。
【００３５】
一意性保証情報は、状態（セッション）６２に割り当てられた識別子６３と、その状態６２を生成した動画配信サーバ６０との関係を示す情報である。動画配信サーバ６０を示す情報とは、例えばアドレス、各動画配信サーバ６０に割り当てられた固有の識別子、である。
【００３６】
動画配信サーバ６０からのメッセージは、ＳＬＢ５０を介してＧＷ装置２０に送信される。しかし、そのメッセージは、ＳＬＢ５０等を中継することなく端末装置１０に送信しても良い。そのようにメッセージを送信する場合には、設定管理装置７０に各ＳＬＢ５０への一意性保証情報の登録を行わせれば良い。一意性保証情報の登録は、セッションを生成した動画配信サーバ６０に行わせても良い。一意性保証情報の設定用に設定管理装置７０を用意しているのは、各動画配信サーバ６０の負荷をより抑えるためである。
【００３７】
携帯端末装置１１及びＰＣ１２を使用できるユーザでは、外出中は携帯端末装置１１によりサービスを利用し、外出から戻ったらＰＣ１２によりサービスを利用するケースが考えられる。その逆のケースも考えられる。動画配信サービスでは、それら何れのケースでも、ユーザは端末装置１０を代えた後、動画を最初から視聴しようと望む可能性は低いと思われる。これは、動画を視聴していたユーザは、その続きが気になって、視聴していた時点以降の動画を直ちに視聴したいと望む場合が多いと考えられるからである。このことから本実施形態では、異なる端末装置１０間でサービスを継続して利用できるようにしている。
【００３８】
図３は、端末装置１０を代えて動画配信サービスを利用する例のタイミングチャートである。この図３に示す例は、最初に携帯端末装置１１を用いて動画配信サービスを利用した後、ＰＣ１２を用いて動画配信サービスを継続して利用した場合である。通信プロトコルは、携帯端末装置１１ではＳＩＰ（Session Initiation Protocol）、ＰＣ１２ではＨＴＴＰ（HyperText Transfer Protocol）が用いられている。以降は便宜的に、携帯端末装置１１及びＰＣ１２それぞれに用いられる通信プロトコルはＳＩＰ及びＨＴＴＰのみと想定する。ＳＬＢ５０ａはＳＩＰ専用、ＳＬＢ５０ｂはＨＴＴＰ専用と想定する。
【００３９】
端末装置１０からのメッセージの振分は、そのメッセージの通信プロトコルに対応するＳＬＢ５０が行う。その振分は、メッセージから状態６２の識別子６３を抽出できた場合、登録されている一意性保証情報を参照して行われる。本実施形態では、このことに着目し、異なる端末装置１０間でのサービスの継続利用は、端末装置１０から送信されるメッセージのなかで識別子６３を挿入すべきメッセージを抽出し、抽出したメッセージに識別子６３を挿入することで実現させる。そのメッセージの抽出、及び抽出したメッセージへの識別子６３の挿入は、ＧＷ装置２０により実現させている。
【００４０】
上記のようにメッセージに識別子６３を挿入する場合、ＳＬＢ５０は識別子６３から転送すべき動画配信サーバ６０を特定することができる。動画配信サーバ６０は、ＧＷ装置２０によって識別子６３が挿入されたメッセージを、それまで受信していたメッセージと同様に処理することができる。このようなことから、基本的にサービス処理システム４０側の変更を行うことなく、異なる端末装置１０間でのサービスの継続利用を可能にすることができる。動画配信サーバ６０の負荷の増大は回避できるか、或いは抑えることができる。これらも、ＧＷ装置２０によりサービスの継続利用を可能とさせた理由である。
【００４１】
図２は、本実施形態による中継装置であるＧＷ装置２０の機能構成図である。このＧＷ装置２０は、図２に示すように、メッセージ受信／送信部２１、メッセージ間関係付けテーブル作成部２２、識別子抽出／挿入部２３、及び格納部２４を備えている。格納部２４には、属性種別情報テーブル２５、属性／識別子情報テーブル２６、サービス名抽出テーブル２７、及びセッション位置抽出テーブル２８が格納されている。
【００４２】
ＧＷ装置２０は、ＳＬＢ５０を介して動画配信サーバ６０が端末装置１０宛てに送信したメッセージを受信し、そのメッセージ中の識別子６３を抽出して保存する。その識別子６３には、端末装置１０のユーザに係わる属性情報を対応付ける。属性情報は、使用する端末装置１０が異なっても、ユーザが同じであれば変化しない。このことから属性情報は、端末装置１０から送信されたメッセージのなかで識別子６３を挿入すべきメッセージ、及びメッセージに挿入すべき識別子６３の特定の両方に用いている。
【００４３】
動画配信サーバ６０が提供するサービスの利用は、ＳＡＭＬ認証サーバ３０による認証を前提としている。このため、端末装置１０のユーザに係わる属性情報は、ＳＡＭＬ認証サーバ３０から取得できる。これは、端末装置１０側に、属性情報等のユーザを識別するための情報を送信する機能を新たに搭載させることなく、必要な属性情報を得られることを意味する。識別子６３に属性情報を対応付けるのは、端末装置１０側に新たな機能を追加する必要性を回避できることも理由の一つである。属性情報の取得方法は、認証結果を利用して取得する以外の方法であっても良い。
【００４４】
格納部２４に格納されたテーブル２５〜２８は、上記のようにしてメッセージに識別子６３を挿入するために用いられる。各部２１〜２３の説明の前に、これらのテーブル２５〜２８について、図６〜図９を参照して具体的に説明する。
【００４５】
図６は、属性種別情報テーブル２５のデータ構成を説明する図である。この属性種別情報テーブル２５は、動画配信サーバ６０が提供可能なサービス（ここでは動画配信サービス、及びＴＶ会議サービス）毎に、ユーザの特定に用いる属性の種別をまとめたものである。属性種別情報は、属性の種別をまとめたもの、つまり属性の組み合わせに相当する。図６において、「ｍｏｖｉｅ」は動画配信サービス、「ＴＶｃｏｎｆｅｒｅｎｃｅ」はＴＶ会議サービスをそれぞれ表している。上記したように、「ＣＮ」「ＤＢ」「Ｌ」「ＯＧ」「ＯＵ」「Ｏ」及び「Ｃ」はそれぞれ、氏名、誕生日、都市名、グループ名、組織名、職種、及び国名を表している。
【００４６】
図６に示すように、属性種別情報、つまりユーザを特定するための属性の組み合わせは、サービスによって異なっている。これは、サービスによって対象とする人が異なるからである。動画配信サービスは、個人を対象にするのに対し、ＴＶ会議サービスは、複数の人を対象にするからである。このことから、動画配信サービスでは、ユーザ自身に係わる属性情報、ＴＶ会議サービスでは、ユーザが属する組織に係わる属性情報をそれぞれユーザの識別に用いている。
【００４７】
図８は、サービス名抽出テーブル２７のデータ構成を説明する図である。このサービス名抽出テーブル２７は、端末装置１０が送信したメッセージから、そのメッセージの通信プロトコル、及び要求されたサービスを特定するためのテーブルである。図８では、以下のようにして、通信プロトコルとサービスを特定することを示している。図８中の「ＨＴＴＰ／ｍｏｖｉｅ」「ＨＴＴＰ／ＴＶｃｏｎｆｅｒｅｎｃｅ」及び「ＳＩＰ／ｍｏｖｉｅ」はそれぞれ、ＨＴＴＰにより提供される動画配信サービス、ＨＴＴＰにより提供されるＴＶ会議サービス、ＳＩＰにより提供される動画配信サービスを表している。
【００４８】
メッセージは、ＩＰヘッダ、通信プロトコルに応じたヘッダ、及び通信プロトコルに応じたボディを備えた構成である。図８中の「ＩＰヘッダ値」及び「メッセージヘッダ値」はそれぞれ、ＩＰヘッダ及び通信プロトコルに応じたヘッダから抽出する対象となるフィールド値を示す項目である。それにより、これらの項目名は「ヘッダ値」項目の下位に位置している。通信プロトコルに応じたヘッダ、及びボディについては、例えば「ＳＩＰヘッダ」「ＨＴＴＰヘッダ」のように、通信プロトコル名を付した表記を用いる。
【００４９】
「ＩＰヘッダ値」項目は、通信プロトコルの特定に用いられる。「ＩＰヘッダ」項目中の「受信ポート」項目の欄に表記した「８０」「５０６０」は、動画配信サーバ６０がメッセージの受信に用いるポート番号を表している。つまり、動画配信サーバ６０は、ＨＴＴＰ、ＳＩＰの各メッセージの受信にそれぞれ番号が「８０」「５０６０」のポートを用いることを表している。このことから本実施形態では、ＩＰヘッダ中のポート番号から、メッセージの通信プロトコルを特定している。「Ｐｒｏｔｏｃｏｌ  ＩＤ」項目の値として表記の「ｔｃｐ」「ｕｄｐ」はそれぞれ、ＨＴＴＰ、ＳＩＰに割り当てられた識別子６３を表している。ポート番号は、ＩＰアドレスの下に割り当てられたサブアドレスである。
【００５０】
図１２及び図１３に示すように、通信プロトコルに応じたヘッダ、及びボディの各構成は通信プロトコルによって異なる。「メッセージヘッダ値」項目は、通信プロトコルに応じたヘッダからサービスを特定するのに用いられる。具体的には「メッセージヘッダ値」項目中の「Ｒｅｑｕｅｓｔ−ＵＲＩ」項目の欄に表記の「／ｍｏｖｉｅ」及び「／ｃｏｎｆｅｒｅｎｃｅ」はそれぞれ、動画配信サービス及びＴＶ会議サービスと特定される文字列を表している。それらの文字列は、例えば図１３に示すように、ＨＴＴＰヘッダのＧＥＴメソッドとして記述される文字列である。このことから「Ｒｅｑｕｅｓｔ−ＵＲＩ」項目は、ＨＴＴＰメッセージが要求するサービスの特定に用いられる。
【００５１】
「Ｒｏｕｔｅ」項目は、ＳＩＰメッセージが要求するサービスの特定に用いられる。その項目の欄に表記の「ＳＩＰ：１９２．１６８．０．１００：５０６０」は、動画配信サービスと特定される文字列を表している。この文字列は、図１２（ａ）に示すように、ＳＩＰヘッダのＲｏｕｔｅヘッダにフィールド値として記述される。
【００５２】
図９は、セッション位置抽出テーブル２８のデータ構成を説明する図である。このセッション位置抽出テーブル２８は、サービス毎に、状態（セッション）６２の識別子６３がメッセージ内に挿入された位置（セッション位置）を特定するためのテーブルである。そのセッション位置は、通信プロトコル毎に定義されている。セッション位置は、通信プロトコルが同じであればサービスの種類によって変化しない。ＨＴＴＰメッセージでは、図１３に示すように、ＨＴＴＰヘッダのＣｏｏｋｉｅフィールドである。ＳＩＰメッセージでは、図１２（ｂ）に示すように、ＳＩＰヘッダのＣｏｎｔａｃｔフィールドである。識別子６３は、「ｓｅｓｓｉｏｎ＝」の後に記述される。このことからセッション位置抽出テーブル２８は、動画配信サーバ６０が送信したメッセージ（応答メッセージ）から識別子６３を抽出する他に、端末装置１０が送信したメッセージへの識別子６３の挿入にも用いられる。
【００５３】
図７は、属性／識別子情報テーブル２６のデータ構成、及びエントリへのデータの格納手順を説明する図である。このテーブル２６は、端末装置１０から送信されたメッセージのなかで識別子６３を挿入すべきメッセージに識別子６３を挿入するために用いられる。
【００５４】
エントリ（レコード）は、端末装置１０のユーザが要求したサービス毎に登録される。１エントリ（レコード）には、サービス名、属性情報、及び識別子情報が格納される。サービス名は、端末装置１０のユーザが要求したサービスの種類を表し、識別子情報は、そのサービスの要求によって生成された状態（セッション）６２の識別子６３を表している。属性情報としては、そのサービスの種類に応じた属性情報の組み合わせが格納される。
【００５５】
動画配信サーバ６０が提供するサービスの利用には、ＳＡＭＬ認証サーバ３０による認証が必要である。これは、動画配信サーバ６０が状態６２を生成する初期メッセージは認証後に端末装置１０から送信されることを意味する。このため、図７（ａ）のエントリ生成前の状態（ここではエントリが存在しない初期状態）で生成されるエントリには、図７（ｂ）に示すように、サービス名と属性情報が格納される。その後、初期メッセージへの応答メッセージにより、図７（ｃ）に示すように、その応答メッセージに挿入された識別子６３が識別子情報として格納される。生成されたエントリは、予め定めた条件が満たされた場合に消去される。その条件とは、状態６２が維持される期間に応じて定義されたものか、或いは状態６２を消去した旨の通知の受信である。
【００５６】
格納部２４に格納されたテーブル２５〜２８において、テーブル２５、２７及び２８は予め固定的に用意される。しかし、属性／識別子情報テーブル２６は、上記のように、ＧＷ装置２０が随時、更新する。その更新により、テーブル２６には、端末装置１０が送信したメッセージのなかから識別子６３を挿入すべきメッセージを抽出し、抽出したメッセージに識別子６３を挿入するための情報（以降「識別子挿入情報」と呼ぶ）が必要なだけ格納（登録）される。このため、ＧＷ装置２０は、テーブル２６を参照することにより、識別子６３を挿入すべきメッセージに挿入すべき識別子６３を挿入することができる。
【００５７】
テーブル２６の１エントリに格納される識別子挿入情報は、サービス名、属性情報、及び識別子情報を備えた構成である。サービス名を格納するのは、動画配信サーバ６０は複数のサービスを提供できるからである。動画配信サーバ６０が提供するサービスが１種類のみの場合には、サービス名は格納しなくとも良い。このことから識別子挿入情報は、少なくとも、識別子情報、及び属性情報を含む情報であれば良い。
【００５８】
次に、図２に示す各部２１〜２３の動作について具体的に説明する。
メッセージ受信／送信部２１は、端末装置１０とＳＬＢ５０との間で送受信されるメッセージを中継する。認証済みのユーザが使用する端末装置１０は、その認証によって得られたアーティファクトを挿入したメッセージを送信する。メッセージ受信／送信部２１は、アーティファクトが挿入されたメッセージを受信した場合、そのアーティファクトを用いて生成したメッセージである認証問い合わせ要求をＳＡＭＬ認証サーバ３０に送信することにより、認証アサーションを取得する。その認証アサーションは受信したメッセージと共に識別子抽出／挿入部２３に渡す。
【００５９】
図１０は、認証問い合わせ要求と認証アサーションの構文例を説明する図である。図１０（ａ）は認証問い合わせ要求、図１０（ｂ）は認証アサーションをそれぞれ示している。図１０（ａ）において、アーティファクトは「ＢＢＢ」に相当する。メッセージ受信／送信部２１は、図１０（ａ）のような認証問い合わせ要求を生成してＳＡＭＬ認証サーバ３０に送信することにより、図１０（ｂ）に示すような認証アサーションを取得する。その認証アサーションには、図４に示すように、認証に用いた認証手段、有効期間の他に、氏名（ＣＮ）、端末ＩＤ（ＴＥＩＤ）、誕生日（ＤＢ）、都市名（Ｌ）、都道府県名（ＳＴ）、国名（Ｃ）、等の属性情報が記述されている。
【００６０】
識別子抽出／挿入部２３は、図８のサービス名抽出テーブル２７を参照して、渡されたメッセージの通信プロトコル、及びそのメッセージが要求するサービス（サービス名）を特定する。その特定結果を用いて、図９のセッション位置抽出テーブル２８を参照し、渡されたメッセージに識別子６３（図１２（ｂ）或いは図１３）が挿入されているか否か判定する。識別子６３が挿入されていると判定した場合、その旨をメッセージ受信／送信部２１に通知する。識別子６３が挿入されていないと判定した場合、例えば渡されたメッセージが要求するサービスの属性種別情報を図６の属性種別情報テーブル２５から抽出し、渡された認証アサーション８０に必要な属性情報（属性値）が全て存在するか否か判定する。必要な属性情報が全て存在すると判定した場合、特定したサービス名、及び必要とする属性情報が格納されたエントリを図７の属性／識別子情報テーブル２６から抽出する。足りない属性情報が存在すると判定した場合、その旨をメッセージ受信／送信部２１に通知する。
【００６１】
識別子抽出／挿入部２３は、対応するエントリを抽出できた場合、図９のセッション位置抽出テーブル２８を参照して、そのエントリに格納された識別子６３を渡されたメッセージに挿入し、その挿入後のメッセージをメッセージ受信／送信部２１に渡す。エントリを抽出できたことは、ユーザが端末装置１０を代えて、利用中のサービスを継続利用しようとしていることを意味する。対応するエントリを抽出できなかった場合、識別子６３を挿入できない旨をメッセージ受信／送信部２１に通知する。
【００６２】
メッセージ受信／送信部２１は、識別子６３が挿入されている旨の通知を受け取った場合、メッセージを対応するＳＬＢ５０に送信する。メッセージが渡された場合も同様に、そのメッセージを対応するＳＬＢ５０に送信する。そのようにして送信されたメッセージは何れも、挿入された識別子６３により、ＳＬＢ５０によって転送すべき動画配信サーバ６０に転送される。一方、識別子６３を挿入できない旨の通知を受け取った場合は、端末装置１０から受信したメッセージは初期メッセージと見なし、そのまま対応するＳＬＢ５０に送信する。それにより、メッセージの転送先とする動画配信サーバ６０をＳＬＢ５０の自動振分機能により選択させる。
【００６３】
足りない属性情報が存在する旨の通知を受け取ったメッセージ受信／送信部２１は、アーティファクトを用いて生成したメッセージである属性問い合わせ要求をＳＡＭＬ認証サーバ３０に送信することにより、属性アサーションを取得する。図１１（ａ）は属性問い合わせ要求、図１１（ｂ）は属性アサーションの構文例をそれぞれ示している。この属性アサーションには、図４に示すような認証アサーション８０には存在しない属性情報が記述されている。メッセージ受信／送信部２１は、取得した属性アサーションを識別子抽出／挿入部２３に渡す。
【００６４】
このようにして本実施形態では、最初に認証アサーション８０を取得し、属性アサーションは必要に応じて取得するようにしている。それにより、ＳＡＭＬ認証サーバ３０との間のメッセージ交換を行う頻度を抑えている。属性種別情報テーブル２５におけるサービス毎の属性種別情報（属性の組み合わせ）の定義は、認証アサーション８０及び属性アサーションにそれぞれ記述された属性を考慮して行っている。このことから、属性種別情報が組み合わせを示す属性の値は、認証アサーション８０及び属性アサーションのうちの少なくとも一方に記述されている。
【００６５】
図６に示すように、必要とする属性の組み合わせはサービス毎に定義している。このことから、各アサーションに値が記述される属性の組み合わせをサービスに応じて決定しても良い。つまり例えば動画配信サービスでは認証アサーション８０のみ、ＴＶ会議サービスでは属性アサーションのみを取得するといったように、サービスに応じて取得すべきアサーションを選択するようにしても良い。
【００６６】
属性アサーションが渡された識別子抽出／挿入部２３は、特定したサービス名、及び必要とする属性情報が格納されたエントリを図７の属性／識別子情報テーブル２６から抽出する。そのエントリを抽出できた場合、図９のセッション位置抽出テーブル２８を参照して、そのエントリに格納された識別子６３を渡されたメッセージに挿入し（図１２（ｂ）或いは図１３）、その挿入後のメッセージをメッセージ受信／送信部２１に渡す。そのエントリを抽出できなかった場合、識別子６３を挿入できない旨をメッセージ受信／送信部２１に通知する。
【００６７】
メッセージ受信／送信部２１は、識別子抽出／挿入部２３からメッセージが渡された場合、そのメッセージを対応するＳＬＢ５０に送信する。それによりＳＬＢ５０は、挿入した識別子６３から特定される動画配信サーバ６０をメッセージの転送先として選択する。識別子６３を挿入できない旨の通知を受け取った場合は、上記のように、端末装置１０から受信したメッセージは初期メッセージと見なし、対応するＳＬＢ５０に送信する。そのメッセージは、取得済みのアサーションと共にメッセージ間関係付けテーブル生成部２２に渡される。
【００６８】
メッセージ間関係付けテーブル生成部２２は、属性／識別子情報テーブル２６に１エントリを生成（追加）し、図６、図８及び図９にそれぞれ示すテーブル２５、２７及び２８を参照して、渡されたメッセージ、及びアサーションからそれぞれ抽出した情報を格納する。それにより生成したエントリには、図７（ｂ）に示すように、サービス名、及び属性値の組み合わせである属性情報が格納される。このようなことから、テーブル２６へのエントリの追加は、初期メッセージの受信時に行われる。
【００６９】
動画配信サーバ６０からの応答メッセージは、ＳＬＢ５０を介してＧＷ装置２０に送信される。メッセージ受信／送信部２１は、受信した応答メッセージを端末装置１０に送信すると共に、メッセージ間関係付けテーブル生成部２２に渡す。
【００７０】
メッセージ間関係付けテーブル生成部２２は、渡された応答メッセージから、図７の属性／識別子情報テーブル２６中の対応するエントリを特定し、特定したエントリに、その応答メッセージから図９のセッション位置抽出テーブル２８を参照して抽出した識別子６３を識別子情報として格納する。対応するエントリの特定は、例えばそのエントリの生成時に、その契機となったメッセージが要求するサービス、及びそのメッセージの送信元アドレスを保存することにより行うことができる。
【００７１】
このようにしてＧＷ装置２０は、初期メッセージと見なさないメッセージを端末装置１０から受信した場合、そのメッセージのアーティファクトにより取得されるアサーションの属性値から挿入すべき識別子６３を特定し挿入する。このため、識別子６３を挿入したメッセージは、ＳＬＢ５０の一意性保証機能により、転送すべき動画配信サーバ６０に転送されることになる。メッセージが転送された動画配信サーバ６０は、挿入された識別子６３により、既に存在する状態（セッション）６２として処理される。このため、端末装置１０を代えても、ユーザはそれまで利用していたサービスを継続して利用できることとなる。この結果、例えば図３に示すような時系列でサービスを継続利用することができるようになる。これは、ＳＬＢ５０によりメッセージの転送先を振り分けないシステム構成であっても同じである。
【００７２】
アーティファクトを用いて属性情報を取得する場合、ＧＷ装置２０は必要なデータのみを保存する形となる。他のサービスを利用していない人のデータを扱う必要性は回避され、ＧＷ装置２０の負荷は抑えられる。このことから本実施形態では、アーティファクトを用いて必要な属性情報を取得している。
【００７３】
上記メッセージ受信／送信部２１、メッセージ間関係付けテーブル作成部２２、及び識別子抽出／挿入部２３は、ＧＷ装置２０がメッセージの中継のためのプログラム（中継プログラム）を実行することで実現される。ここで図１５を参照して、本発明を適用可能なコンピュータ、つまりこの中継プログラムを実行することでＧＷ装置２０として使用可能なコンピュータについて具体的に説明する。
【００７４】
図１５に示すコンピュータは、ＣＰＵ９１、メモリ９２、入力装置９３、出力装置９４、外部記憶装置９５、媒体駆動装置９６、及びネットワーク接続装置９７を有し、これらがバス９８によって互いに接続された構成となっている。図１５に示す構成は一例であり、これに限定されるものではない。例えばサービス処理システム４０との接続、及び端末装置１０との接続がそれぞれ異なる通信ネットワークを介して実現される場合、ネットワーク接続装置９７は複数、備えた構成となる。
【００７５】
ＣＰＵ９１は、当該コンピュータ全体の制御を行う。
メモリ９２は、プログラムの実行、データ更新等の際に、外部記憶装置９５（あるいは可搬型の記録媒体９９）に記憶されているプログラムあるいはデータを一時的に格納するＲＡＭ等の半導体メモリである。ＣＰＵ９１は、プログラムをメモリ９２に読み出して実行することにより、全体の制御を行う。
【００７６】
入力装置９３は、例えば、キーボード、マウス等の操作装置と接続可能なインターフェースである。接続された操作装置に対するユーザの操作を検出し、その検出結果をＣＰＵ９１に通知する。
【００７７】
出力装置９４は、例えば表示装置と接続された表示制御装置である。ネットワーク接続装置９７は、例えばサービス処理システム４０及び端末装置１０と通信ネットワークを介して通信を行うためのものである。外部記憶装置９５は、例えばハードディスク装置である。主に各種データやプログラムの保存に用いられる。
【００７８】
媒体駆動装置９６は、光ディスクや光磁気ディスク等の可搬型の記録媒体９９にアクセスするものである。
上記中継プログラムは、外部記憶装置９５、若しくは記録媒体９９に記録されているか、或いは通信ネットワークを介してネットワーク接続９７により取得される。その中継プログラムをメモリ９２に読み出してＣＰＵ９１が実行することにより、ＧＷ装置２０は実現される。中継プログラムが外部記憶装置９５に格納されていると想定する場合、メッセージ受信／送信部２１は、例えばＣＰＵ９１、メモリ９２、外部記憶装置９５、ネットワーク接続装置９７、及びバス９８によって実現される。更に、格納部２４が外部記憶装置９５であると想定した場合には、メッセージ間関係付けテーブル生成部２２は、例えばＣＰＵ９１、メモリ９２、外部記憶装置９５、及びバス９８によって実現される。これは、識別子抽出／挿入部２３も同様である。
【００７９】
図４は、携帯端末装置１１、ＰＣ１２、各ＳＬＢ５０、ＳＡＭＬ認証サーバ３０、及び動画配信サーバ６０の動作例を示すシーケンス図である。このシーケンス図は、ユーザが端末装置１０を携帯端末装置１１からＰＣ１２に代えて同じサービスを利用するケースを例にとったものである。次に図４を参照して、このケースにおけるそれらの装置の動作について具体的に説明する。
【００８０】
図４では、属性／識別子情報テーブルは「ＴＢＬ−２」と表記している。これは、図５及び図１４でも同様である。また、ＳＩＰ専用のＳＬＢ５０ａは「ＳＬＢ−Ａ」、ＨＴＴＰ専用のＳＬＢ５０ｂは「ＳＬＢ−Ｂ」とそれぞれ表記している。
【００８１】
携帯端末装置１１によるサービスの利用では、特には図示していないが、ユーザはＳＡＭＬ認証サーバ３０にアクセスして認証を行う。その認証は、チャレンジ・レスポンス方式を採用している場合、例えば以下のようにして行われる。
【００８２】
先ず、携帯端末装置１１は、ＩＤ／パスワードを付加していないＲＥＧＩＳＴＥＲメッセージをＳＡＭＬ認証サーバ３０に送信する。ＳＡＭＬ認証サーバ３０は、そのメッセージの受信により、認証情報を要求するエラーメッセージ（401 Unauthorized）を携帯端末装置１１に送信する。そのエラーメッセージを受信した携帯端末装置３０は、認証（Authorization）ヘッダに認証情報を格納したメッセージを再度ＳＡＭＬ認証サーバ３０に送信する。ＳＡＭＬ認証サーバ３０は、そのメッセージ中の認証情報が表すＩＤ／パスワードの組み合わせが認証情報ＤＢ３５に登録されているか否か確認することにより認証を行う。その認証の結果、ＩＤ／パスワードの登録が確認できた場合、アーティファクトを発行し、携帯端末装置１１にメッセージにより通知する。また、認証アサーション情報テーブル３６に１エントリを生成（追加）し、そのエントリに、発行したアーティファクト、及び生成した各アサーションの保存場所情報を格納する。ＩＤ／パスワードの登録が確認できなかった場合には、再度、上記エラーメッセージを携帯端末装置１１に送信する。
【００８３】
上記のようにして認証が済んだ後、携帯端末装置１１によるサービスの提供の要求が可能となる、その要求は、アーティファクトが挿入されたメッセージ（初期メッセージ）を送信することで行われる（シーケンスＳ１−３）。そのメッセージはＧＷ装置２０によって受信され、ＧＷ装置２０は、メッセージ中のアーティファクトを挿入した認証問い合わせ要求を生成してＳＡＭＬ認証サーバ３０に送信することにより、アーティファクト検証を行う（シーケンスＳ１−４）。その認証問い合わせ要求を受信したＳＡＭＬ認証サーバ３０は、認証アサーション情報テーブル３６を参照して、要求された認証アサーション８０をＧＷ装置２０に送信する（シーケンスＳ１−５）。
【００８４】
認証アサーション８０を受信したＧＷ装置２０は、そのアサーション８０に記述された属性情報（属性値）を抽出し、属性／識別子情報テーブル２６を参照することにより、受信したメッセージ中に挿入すべき識別子６３が存在するか否か確認する。ここでは、受信したメッセージは初期メッセージに相当する。このため、ＧＷ装置２０は受信したメッセージに識別子６３を挿入することなく、ＳＩＰ専用のＳＬＢ５０ａに送信する。それによりＳＬＢ５０ａは、自動振分機能により選択した動画配信サーバ６０にメッセージを転送する（以上、シーケンスＳ１−６）。ＧＷ装置２０は、属性／識別子情報テーブル２６に１エントリを生成し、サービス名、及び属性情報を格納することも併せて行う。
【００８５】
初期メッセージを受信した動画配信サーバ６０は、状態６２を生成し、識別子６３を割り当て、その識別子６３を挿入した応答メッセージをＳＬＢ５０ａに送信する。ＳＬＢ５０ａは、その応答メッセージを受信し、ＧＷ装置２０に送信する（シーケンスＳ１−７）。ＧＷ装置２０は、受信した応答メッセージを携帯端末装置１１に送信すると共に、その応答メッセージから識別子６３を抽出し、属性／識別子情報テーブル２６の対応するエントリに格納する（シーケンスＳ１−８）。
【００８６】
ユーザが携帯端末装置１１に代えてＰＣ１２を使用し、同一のサービスを利用する場合、ＰＣ１２はサービスの提供を要求するメッセージを送信する（シーケンスＳ２−３）。そのメッセージにはアーティファクトは挿入されていない。このことからＧＷ装置２０は、そのメッセージを受信すると、ＳＡＭＬ認証サーバ３０による認証を行わせる。その認証は、例えばリダイレクトによりＰＣ１２をＳＡＭＬ認証サーバ３０にアクセスさせることで行う（シーケンスＳ２−４）。
【００８７】
ＧＷ装置２０は、リダイレクトにより、ＰＣ１２に転送先を通知する。その通知により、ＰＣ１２は転送先であるＳＡＭＬ認証サーバ３０にアクセスし、ＳＡＭＬ認証サーバ３０は認証情報を要求する。その要求により、ＰＣ１２は認証情報をＳＡＭＬ認証サーバ３０に送信する。それによりＳＡＭＬ認証サーバ３０は、ＳＩＰの場合と同様に、受信した認証情報が表すＩＤ／パスワードの組み合わせが認証情報ＤＢ３５に登録されているか否か確認することにより認証を行う。その認証の結果、ＩＤ／パスワードの登録が確認できた場合、アーティファクトを発行し、ＰＣ１２にメッセージにより通知する。このアーティファクトの発行により、認証アサーション情報テーブル３６には、図１に示すように、同じユーザ（ユーザＡ）を対象にするアーティファクトが端末装置１０毎に格納されることとなる。
【００８８】
上記のようにして認証が済んだ後、ＰＣ１２はサービスの提供を要求する、アーティファクトが挿入されたメッセージを送信する。そのメッセージを受信したＧＷ装置２０は、メッセージ中のアーティファクトを挿入した認証問い合わせ要求を生成してＳＡＭＬ認証サーバ３０に送信することにより、アーティファクト検証を行う（シーケンスＳ１−４）。その認証問い合わせ要求を受信したＳＡＭＬ認証サーバ３０は、認証アサーション情報テーブル３６を参照して、要求された認証アサーション８０をＧＷ装置２０に送信する（シーケンスＳ１−５）。
【００８９】
認証アサーション８０を受信したＧＷ装置２０は、そのアサーション８０に記述された属性情報を抽出し、属性／識別子情報テーブル２６を参照することにより、受信したメッセージ中に挿入すべき識別子６３が存在するか否か確認する。ここでは、受信したメッセージは、端末装置１０は異なっても、同一のユーザが使用するＰＣ１２から送信されたものである。そのユーザに対応するエントリは属性／識別子情報テーブル２６に存在する。このため、ＧＷ装置２０は受信したメッセージに挿入すべき識別子６３（図４の「α１」）を例えば図１３に示すように挿入し、ＨＴＴＰ専用のＳＬＢ５０ｂに送信する。ＳＬＢ５０ｂには、一意性保証情報設定管理装置７０により、対応する一意性保証情報が登録されている。このためＳＬＢ５０ｂは、一意性保証情報に従って選択した動画配信サーバ６０にメッセージを転送する（以上、シーケンスＳ２−６）。
【００９０】
このようにして、同一のサービスを利用する場合、ユーザが使用する端末装置１０を代えても、最初に使用した端末装置１０のメッセージが転送された動画配信サーバ６０に、それ以降に使用される端末装置１０のメッセージは同じ識別子６３が挿入されて転送される。このためユーザは、端末装置１０を代えてもサービスを継続して利用することができる。
【００９１】
図５は、携帯端末装置１１、ＰＣ１２、各ＳＬＢ５０、ＳＡＭＬ認証サーバ３０、動画配信サーバ６０、及び一意性保証情報設定管理装置７０の動作例を示すシーケンス図である。このシーケンス図は、図４と同じく、ユーザが端末装置１０を携帯端末装置１１からＰＣ１２に代えて同じサービスを利用するケースを例にとったものである。次に図５を参照して、一意性保証情報設定管理装置７０を含む各装置の動作についてより具体的に説明する。
【００９２】
先ず、携帯端末装置１１は、ＩＤ／パスワードを付加していないＲＥＧＩＳＴＥＲメッセージをＳＡＭＬ認証サーバ３０に送信する（シーケンスＳ１０１）。ＳＡＭＬ認証サーバ３０は、そのメッセージの受信により、認証情報を要求するエラーメッセージ（401 Unauthorized）を携帯端末装置１１に送信する（シーケンスＳ１０２）。
【００９３】
そのエラーメッセージを受信した携帯端末装置３０は、ユーザの操作に従い、認証ヘッダに認証情報を格納したメッセージを再度ＳＡＭＬ認証サーバ３０に送信する。ＳＡＭＬ認証サーバ３０は、そのメッセージ中の認証情報が表すＩＤ／パスワードの組み合わせが認証情報ＤＢ３５に登録されているか否か確認することにより認証を行う。その認証の結果、ＩＤ／パスワードの登録が確認できた場合、アーティファクトを発行し、携帯端末装置１１にメッセージにより通知する。ＩＤ／パスワードの登録が確認できなかった場合には、再度、上記エラーメッセージを携帯端末装置１１に送信する。シーケンスＳ１０３では、このような認証のためのメッセージの送受信が行われる。ＩＤ／パスワードの登録が確認できた場合、ＳＡＭＬ認証サーバ３０は、認証アサーション情報テーブル３６に１エントリを生成（追加）し、そのエントリに、発行したアーティファクト、及び生成した各アサーションの保存場所情報を格納する。
【００９４】
上記のようにして認証が済んだ後、携帯端末装置１１はサービスの提供を要求する、アーティファクトが挿入されたメッセージ（初期メッセージ）を送信する（シーケンスＳ１０４）。そのメッセージを受信したＧＷ装置２０は、そのメッセージ中のアーティファクトを挿入した認証問い合わせ要求を生成してＳＡＭＬ認証サーバ３０に送信する（シーケンスＳ１０５）。その認証問い合わせ要求を受信したＳＡＭＬ認証サーバ３０は、認証アサーション情報テーブル３６を参照して、要求された認証アサーション８０をＧＷ装置２０に送信する（シーケンスＳ１０６）。
【００９５】
認証アサーション８０を受信したＧＷ装置２０は、そのアサーション８０に記述された属性情報を抽出し、受信したメッセージから特定したサービス名を用いて図６の属性種別情報テーブル２５を参照することにより、必要な属性情報が全て存在しているか否か判定する。その判定により、足りない属性情報が存在することが判明した場合、属性問い合わせ要求を生成して再度、ＳＡＭＬ認証サーバ３０に送信する（シーケンスＳ１０７）。その属性問い合わせ要求を受信したＳＡＭＬ認証サーバ３０は、認証アサーション情報テーブル３６を参照して、要求された属性アサーションをＧＷ装置２０に送信する（シーケンスＳ１０８）。
【００９６】
ＧＷ装置２０は、受信した属性アサーションから足りない属性情報を抽出し、受信したメッセージから特定したサービス名、及び抽出した全ての属性情報を用いて図７の属性／識別子情報テーブル２６を参照することにより、対応するエントリの特定を行う。ここでは、携帯端末装置１１から受信したメッセージは初期メッセージに相当するため、エントリは特定できない。この結果、受信したメッセージに識別子６３を挿入することなく、対応するＳＬＢ５０ａに送信する（シーケンスＳ１０９）。ＧＷ装置２０は、属性／識別子情報テーブル２７に１エントリを生成し、サービス名、及び属性情報（指定された各属性の値）を格納することも併せて行う。ＳＬＢ５０ａは、受信したメッセージを自動振分機能により選択した動画配信サーバ６０に転送する（シーケンスＳ１１０）。
【００９７】
初期メッセージを受信した動画配信サーバ６０は、状態（セッション）６２を生成し、識別子６３を割り当て、生成した状態（セッション）６２に係わるセッション情報を一意性保証情報設定管理装置７０に通知する（シーケンスＳ１１１）。その通知は、動画配信サーバ６０が実行するアプリケーション６１に搭載されたセッション情報監視・通知部６１ａの制御で行われる。一意性保証情報設定管理装置７０は、例えば通知されたセッション情報中の識別子６３、及びそのセッション情報を通知した動画配信サーバ６０を示す情報の組み合わせである一意性保証情報を生成し、各ＳＬＢ５０に送信する（シーケンスＳ１１２）。各ＳＬＢ５０は、受信した一意性保証情報を登録し、その旨を返信する（シーケンスＳ１１３）。一意性保証情報設定管理装置７０は、その返信を受信すると、一意性保証情報の設定が完了した旨を動画配信サーバ６０に通知する（シーケンスＳ１１４）。動画配信サーバ６０は、その通知を受信するのを待って、応答メッセージを対応するＳＬＢ５０ａに送信する（シーケンスＳ１１５）。
【００９８】
ＳＬＢ５０ａは、受信した応答メッセージをＧＷ装置２０に送信する（シーケンスＳ１１６）。ＧＷ装置２０は、受信した応答メッセージを携帯端末装置１１に送信する（シーケンスＳ１１７）。また、その応答メッセージから識別子６３を抽出し、属性／識別子情報テーブル２６の対応するエントリに格納する。以降、携帯端末装置１１から送信されるメッセージは、ＧＷ装置２０によって識別子６３が挿入されることなく、対応するＳＬＢ５０ａに転送され、そのＳＬＢ５０ａによって同じ動画配信サーバ６０に転送される。
【００９９】
ユーザが携帯端末装置１１に代えてＰＣ１２を使用し、同一のサービスを利用する場合、ＰＣ１２はサービスの提供を要求するメッセージを送信する（シーケンスＳ１１８）。そのメッセージにはアーティファクトは挿入されていない。このことからＧＷ装置２０は、そのメッセージを受信すると、ＳＡＭＬ認証サーバ３０にアクセスさせるリダイレクト用の応答メッセージをＰＣ１２に送信する（シーケンスＳ１１８）。それによりＰＣ１２は、受信した応答メッセージで指定されるＳＡＭＬ認証サーバ３０にメッセージを送信する（シーケンスＳ１２０）。
【０１００】
メッセージを受信したＳＡＭＬ認証サーバ３０は、ＰＣ１２に認証情報を要求し、その要求によりＰＣ１２は、認証情報をＳＡＭＬ認証サーバ３０に送信する。それにより、ＳＡＭＬ認証サーバ３０は、携帯端末装置１１（ＳＩＰ）の場合と同様に、受信した認証情報が表すＩＤ／パスワードの組み合わせが認証情報ＤＢ３５に登録されているか否か確認することにより認証を行う。シーケンスＳ１２１では、このような認証のためのメッセージの送受信が行われる。その認証の結果、ＩＤ／パスワードの登録が確認できた場合、ＳＡＭＬ認証サーバ３０は、アーティファクトを挿入したメッセージをＰＣ１２に送信する（シーケンスＳ１２２）。認証アサーション情報テーブル３６には１エントリを生成（追加）し、そのエントリに、発行したアーティファクト、及び生成した各アサーションの保存場所情報を格納する。
【０１０１】
このようにしてアーティファクトを取得したＰＣ１２は、そのアーティファクトを挿入したメッセージを送信する（シーケンスＳ１２３）。そのメッセージを受信したＧＷ装置２０は、メッセージ中のアーティファクトを挿入した認証問い合わせ要求を生成してＳＡＭＬ認証サーバ３０に送信する（シーケンスＳ１２４）。その認証問い合わせ要求を受信したＳＡＭＬ認証サーバ３０は、認証アサーション情報テーブル３６を参照して、要求された認証アサーション８０をＧＷ装置２０に送信する（シーケンスＳ１２５）。
【０１０２】
認証アサーション８０を受信したＧＷ装置２０は、そのアサーション８０に記述された属性情報を抽出し、受信したメッセージから特定したサービス名を用いて図６の属性種別情報テーブル２５を参照することにより、必要な属性情報（属性値）が全て存在しているか否か判定する。その判定により、足りない属性情報が存在することが判明した場合、属性問い合わせ要求を生成して再度、ＳＡＭＬ認証サーバ３０に送信する（シーケンスＳ１２６）。その属性問い合わせ要求を受信したＳＡＭＬ認証サーバ３０は、認証アサーション情報テーブル３６を参照して、要求された属性アサーションをＧＷ装置２０に送信する（シーケンスＳ１２７）。
【０１０３】
ＧＷ装置２０は、受信した属性アサーションから足りない属性情報を抽出し、受信したメッセージから特定したサービス名、及び抽出した全ての属性情報を用いて図７の属性／識別子情報テーブル２６を参照することにより、対応するエントリの特定を行う。この状況では、ユーザはＰＣ１２を使用する前に、携帯端末装置１１を使用して同じサービスを利用している。このため、エントリは特定できる。この結果、特定したエントリに格納されている識別子６３を受信したメッセージに挿入し、対応するＳＬＢ５０に送信する（シーケンスＳ１２８）。ＳＬＢ５０は、一意性保証情報に従って、受信したメッセージを転送すべき動画配信サーバ６０に転送する（シーケンスＳ１２９）。動画配信サーバ６０は、受信したメッセージの応答メッセージを対応するＳＬＢ５０に送信する（シーケンスＳ１３０）。ＳＬＢ５０は、動画配信サーバ６０から受信した応答メッセージをＧＷ装置２０に転送し（シーケンスＳ１３１）、ＧＷ装置２０は、転送された応答メッセージをＰＣ１２に送信する（シーケンスＳ１３２）。
【０１０４】
応答メッセージを受信したＰＣ１２は、その後に送信する、関連するメッセージには識別子６３を挿入する。このため、ＧＷ装置２０は以降、ＰＣ１２から受信したメッセージは識別子６３を挿入することなく中継することとなる。
【０１０５】
図１４は、メッセージ中継処理のフローチャートである。このフローチャートは、理解を容易とするために、端末装置１０から送信された１メッセージ（要求メッセージ）に対応するために実行される処理を抜粋し、その流れを示したものである。次に図１４を参照して、ＧＷ装置２０の動作について詳細に説明する。図１４にフローチャートを示すメッセージ中継処理は、ＧＷ装置２０に搭載されたＣＰＵが上記中継プログラムを実行することで実現される。
【０１０６】
先ず、ステップＳ２０１では、端末装置１０から送信されたメッセージ（要求メッセージ）を受信する。次のステップＳ２０２では、図８のサービス名抽出テーブル２７を参照して、受信したメッセージの通信プロトコル及び要求するサービスを特定すると共に、図９のセッション位置抽出テーブル２９を参照して、識別子６３の有無を確認する。特には図示していなが、識別子６３を確認できた場合、受信したメッセージを対応するＳＬＢ５０に送信し、ここでメッセージ中継処理を終了する。それによりステップＳ２０３には、識別子６３を確認できなかった場合に移行する。
【０１０７】
ステップＳ２０３では、受信したメッセージからアーティファクトの抽出を行うことにより、このメッセージを送信させたユーザが認証を行ったか否か判定する。ユーザが認証を行った後に端末装置１０から送信されるメッセージにはアーティファクトが挿入されている。このため、受信したメッセージからアーティファクトを抽出できた場合、判定はＹＥＳとなってステップＳ２０８に移行する。そのアーティファクトを抽出できなかった場合には、判定はＮＯとなってステップＳ２０７に移行し、ＳＡＭＬ認証サーバ３０にアクセスさせるリダイレクト用のメッセージを端末装置１０に送信した後、このメッセージ中継処理を終了する。
【０１０８】
ステップＳ２０８では、抽出したアーティファクトを用いて認証問い合わせ要求（図１０（ａ））を生成してＳＡＭＬ認証サーバ３０に送信する。認証問い合わせ要求を送信した後はステップＳ２０９に移行して、ＳＡＭＬ認証サーバ３０から認証アサーション８０（図４及び図１０（ｂ））を受信するのを待つ。その認証アサーション８０を受信した後に、ステップＳ２１０に移行する。
【０１０９】
ステップＳ２１０では、ステップＳ２０２で抽出したサービス名を用いて図６の属性種別情報テーブル（図１４中「ＴＢＬ−１」と表記）２５を参照し、認証アサーション８０から必要な属性値を取得する。属性種別情報テーブル２５には、サービス毎に、必要とする属性情報（属性値）の組み合わせ（図１４中「属性グループ」と表記）を示す属性種別情報が定義されている。続くステップＳ２１１では、該当する属性種別情報が示す属性値を全て取得できたか否か判定する。足りない属性値が存在した場合、判定はＮＯとなってステップＳ２１２に移行し、属性問い合わせ要求（図１１（ａ））を生成してＳＡＭＬ認証サーバ３０に送信し、属性アサーション（図１１（ｂ）を受信するのを待って、ステップＳ２１３に移行する。必要な属性値を全て取得できた場合には、判定はＹＥＳとなってステップＳ２１３に移行する。
【０１１０】
ステップＳ２１３では、特定したサービス名、及び取得した属性値を用いて図７の属性／識別子情報テーブル２６を参照することにより、そのサービス名、及び取得した属性値を格納したエントリが存在するか否か判定する。そのようなエントリが存在した場合、判定はＹＥＳとなってステップＳ２１４に移行し、そのエントリの識別子６３を受信したメッセージ（図１４中「ＭＳＧ」と表記）に付加して対応するＳＬＢ５０に送信した後、このメッセージ中継処理を終了する。識別子６３の付加は、メッセージの通信プロトコルに応じて、図１２（ｂ）或いは図１３に示すように行う。そのようなエントリが存在しない場合には、判定はＮＯとなってステップＳ２１５に移行する。
【０１１１】
ステップＳ２１５への移行は、受信したメッセージが初期メッセージであることを意味している。このことからステップＳ２１５以降では、初期メッセージに対応するための処理が実行される。
【０１１２】
ステップＳ２１５では、属性／識別子情報テーブル２６に新規にエントリを登録し、特定したサービス名、及び取得した全ての属性値をそのエントリに格納する。次のステップＳ２１６では、受信したメッセージ（初期メッセージ）を対応するＳＬＢ５０、つまり特定した通信プロトコルのＳＬＢ５０に送信する。その後はステップＳ２１７に移行して、メッセージの送信により返信される応答メッセージを受信するのを待つ。それによりステップＳ２１８には応答メッセージ（ＭＳＧ）の受信後に移行する。
【０１１３】
ステップＳ２１８では、図９のセッション位置抽出テーブル２８を参照して、応答メッセージから識別子６３を抽出し、抽出した識別子６３をステップＳ２１５で新規に登録したエントリに格納する。続くステップＳ２１９では、応答メッセージを端末装置１０に送信する。その送信を行った後、メッセージ中継処理を終了する。
【０１１４】
なお、本実施形態では、端末装置１０からのメッセージに必要に応じて識別子を挿入する中継装置はＧＷ装置２０として実現させているが、本実施形態を適用可能な装置はＧＷ装置２０に限定されるものではない。端末装置１０とサービスを提供するサーバの間に位置している装置であれば、幅広く本実施形態を適用することができる。このことから、ＳＬＢ５０に本実施形態による中継装置を搭載させることも可能である。
【符号の説明】
【０１１５】
１０    端末装置（クライアント）
１１    携帯端末装置
１２    ＰＣ
２０    ＧＷ（ゲートウェイ）装置
２１    メッセージ受信／送信部
２２    メッセージ間関係付けテーブル生成部
２３    識別子抽出／挿入部
２４    格納部
２５    属性種別情報テーブル
２６    属性／識別子情報テーブル
２７    サービス名抽出テーブル
２８    セッション位置抽出テーブル
３０    ＳＡＭＬ認証サーバ
３１    リポジトリ
４０    サービス処理システム
５０、５０ａ、５０ｂ    ＳＬＢ
６０、６０ａ、６０ｂ    動画配信サーバ
６１    アプリケーション・プログラム
６２    状態（セッション）
６３    識別子
７０    一意性保証情報設定管理装置
【図２】
2011076425.tif 000003
【図３】
2011076425.tif 000004
【図１】
2011076425.tif 000005
【図４】
2011076425.tif 000006
【図５】
2011076425.tif 000007
【図６】
2011076425.tif 000008
【図７】
2011076425.tif 000009
【図８】
2011076425.tif 000010
【図９】
2011076425.tif 000011
【図１０】
2011076425.tif 000012
【図１１】
2011076425.tif 000013
【図１２】
2011076425.tif 000014
【図１３】
2011076425.tif 000015
【図１４】
2011076425.tif 000016
【図１５】
2011076425.tif 000017