(57)【要約】  本開示は、インターネットプロトコル・マルチメディア・サブシステム（ＩＭＳ）領域と非ＩＭＳ領域の間の相互運用性を提供するための技術に関する。この技術を実装する方法は、サービスレイヤ上で非ＩＭＳ領域からサービス呼び出しメッセージを受信するステップと、そのメッセージはＩＭＳ領域内のサービスを呼び出すための要求であると識別するためにそのメッセージを分析するステップと、そのメッセージの中に含まれる非ＩＭＳセッション制御プロトコル要素をＩＭＳセッション制御関連のプロトコル要素に変換するステップと、そして、ＩＭＳ制御セッションを確立するために発信ＩＭＳメッセージを生成するステップとを備える。
2009520390.tif 000002
【特許請求の範囲】
【請求項１】
インターネットプロトコル・マルチメディア・サブシステム（ＩＭＳ）領域（１０）と非ＩＭＳ領域（２０）との間の相互運用性を提供する方法であって、
サービスレイヤ上で非ＩＭＳ領域からサービス呼び出しメッセージを受信するステップと、
前記ＩＭＳ領域内のサービスを呼び出す要求として前記メッセージを識別するために前記メッセージを分析するステップと、
セッション制御レイヤ上で、前記メッセージに関連する非ＩＭＳセッション制御プロトコル要素をＩＭＳセッション制御関連プロトコル要素に変換するステップと、
前記ＩＭＳセッション制御関連プロトコル要素に基づいて、前記ＩＭＳ領域内にＩＭＳ制御セッションを提供するために前記ＩＭＳ領域へ１以上のメッセージを送信するステップと、
を備えることを特徴とする方法。
【請求項２】
前記サービスレイヤ上で、前記ＩＭＳ制御セッションを使用して前記サービス呼び出しメッセージを転送するステップを更に備えることを特徴とする請求項１に記載の方法。
【請求項３】
前記ＩＭＳ領域内で呼び出された前記サービスに関連する更なるメッセージを前記非ＩＭＳ領域から受信するステップと、
前記サービスレイヤ上で、前記ＩＭＳ制御セッションを使用して前記サービスメッセージを転送するステップと、
を更に備えることを特徴とする請求項１又は２に記載の方法。
【請求項４】
前記セッションの間に前記ＩＭＳ領域からメッセージを受信するステップと、
前記メッセージに関連する前記ＩＭＳ領域からのＩＭＳセッション制御プロトコル要素を非ＩＭＳセッション制御プロトコル要素に変換するステップと、
前記非ＩＭＳセッション制御プロトコル要素に基づいて非ＩＭＳメッセージを生成するステップと、
前記非ＩＭＳメッセージを前記非ＩＭＳ領域へ送信するステップと、
を更に備えることを特徴とする請求項１乃至３のいずれか１項に記載の方法。
【請求項５】
前記ＩＭＳ領域内の前記サービスは、認証、許可、課金、請求、アクセス制御、或いはＨＳＳなどのＩＭＳサポート機能であることを特徴とする請求項１乃至４のいずれか１項に記載の方法。
【請求項６】
前記ＩＭＳ領域内の前記サービスは、非ＩＭＳプロトコルベースのアプリケーションであることを特徴とする請求項１乃至５のいずれか１項に記載の方法。
【請求項７】
前記ＩＭＳセッション制御プロトコル要素は、セッション開始プロトコル（ＳＩＰ）ヘッダを含み、
前記非ＩＭＳセッション制御プロトコル要素は非ＳＩＰヘッダを含む
ことを特徴とする請求項１乃至６のいずれか１項に記載の方法。
【請求項８】
前記非ＩＭＳ領域は、拡張マークアップ言語（ＭＬ）ベースのメッセージのためのプロトコルを使用することを特徴とする請求項１乃至７のいずれか１項に記載の方法。
【請求項９】
前記非ＩＭＳ領域及び前記ＩＭＳ領域のうちの少なくとも一方から受信した前記メッセージを分析するステップと、
前記分析したメッセージに基づいて前記ＩＭＳ領域内の前記サービスについての前記セッションの状態を判断するステップと、
前記セッションの前記状態を格納するステップと、
を備えることを特徴とする請求項１乃至８のいずれか１項に記載の方法。
【請求項１０】
前記ＩＭＳ領域内の前記サービスについてのセッションが進行中であるか否かをチェックするステップと、
進行中のセッションが存在しない場合に、前記ＩＭＳセッション制御プロトコルの下で新たなセッションを開始するステップと、
を備えることを特徴とする請求項１乃至９のいずれか１項に記載の方法。
【請求項１１】
前記ＩＭＳ領域内で前記制御セッションを確立することに先立って前記非ＩＭＳメッセージを認証するステップを備えることを特徴とする請求項１乃至１０のいずれか１項に記載の方法。
【請求項１２】
前記非ＩＭＳメッセージを認証する前記ステップは、前記メッセージ内で指定されたアドレスを分析するステップを含むことを特徴とする請求項１１に記載の方法。
【請求項１３】
固定サービス及び移動サービスのうちの少なくとも一方の呼び出しのためのＳＩＰアドレス指定を使用する一様なアドレス指定スキームを使用するステップを備えることを特徴とする請求項１乃至１２のいずれか１項に記載の方法。
【請求項１４】
呼び出される前記サービスは、前記ＩＭＳ領域内の移動プラットフォーム上に存在し、
当該方法は、前記移動プラットフォームの現在のユニーク・リソース・ロケータ（ＵＲＬ）に関わらず前記ＩＭＳ領域内の前記サービスの動的な呼び出しのためのＳＩＰユニーク・リソース・アイデンティファイア（ＵＲＩ）を定義するステップを備える
ことを特徴とする請求項１乃至１３のいずれか１項に記載の方法。
【請求項１５】
前記ＩＭＳ領域内の前記サービスに関する固定されたアドレス指定のためのＳＩＰユニーク・リソース・ロケータ（ＵＲＬ）を定義するステップを備えることを特徴とする請求項１乃至１４のいずれか１項に記載の方法。
【請求項１６】
１以上のコンピュータ又はコンピュータシステム上で実行されると請求項１乃至１５のいずれか１項に記載の各ステップを実行するプログラムコードを含むコンピュータプログラム。
【請求項１７】
コンピュータ読み取り可能な記録媒体に格納されていることを特徴とする請求項１６に記載のコンピュータプログラム。
【請求項１８】
コンピュータプロセッサと、当該プロセッサに結合されたメモリとを含むシステムであって、
前記メモリは、請求項１乃至１５のいずれか１項に記載の方法に従ってセッション開始プロトコルと非セッション開始プロトコルとの間の相互運用性を提供する各ステップを実行可能な１以上のプログラムでコーディングされている
ことを特徴とするシステム。
【請求項１９】
インターネットプロトコル・マルチメディア・サブシステム（ＩＭＳ）領域（１０）と非ＩＭＳ領域（２０）との間の相互運用性を提供するマッピングデバイス（１００）であって、
サービスレイヤ上で前記非ＩＭＳ領域（２０）から受信した着信するサービス呼び出しメッセージ（１０１）のうちの１つが前記ＩＭＳ領域（１０）内のサービスの呼び出しであるか否かを識別するために当該サービス呼び出しメッセージ（１０１）を分析する分析ユニット（１０２）と、
セッション制御レイヤ上で、前記メッセージ（１０１）のうちの１つに関連する非ＩＭＳセッション制御プロトコル要素をＩＭＳセッション制御関連プロトコル要素に変換する変換ユニット（１０４）と、
前記ＩＭＳセッション制御関連プロトコル要素に基づいて、前記ＩＭＳ領域（１０）内にＩＭＳ制御セッションを提供するために１以上のメッセージ（１０７）を生成するメッセージングユニット（１０６）と、
を備えることを特徴とするマッピングデバイス（１００）。
【請求項２０】
前記ＩＭＳ領域と前記非ＩＭＳ領域との間のゲートウェイとして実装されることを特徴とする請求項１９に記載のマッピングデバイス（１００）。
【請求項２１】
前記非ＩＭＳ領域内のネットワークコンポーネントのプロトコルスタック内に統合されることを特徴とする請求項１９に記載のマッピングデバイス（１００）。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、異なるプロトコル領域間の相互運用性を提供する技術に関する。この技術は特に、インターネット・プロトコル・マルチメディア・サブシステム（ＩＭＳ）領域に関して用いられるように構成される。この点で、本発明は、ＩＭＳセッション制御プロトコルとの相互運用性を提供することが意図されている。
【背景技術】
【０００２】
ＩＭＳは、移動マルチメディアサービスおよび固定マルチメディアサービスを提供するネットワークオペレータのための標準化された次世代ネットワーク（ＮＧＮ）アーキテクチャである。ＩＭＳは、第三世代パートナシッププロジェクト（３ＧＰＰ）の標準化された実装であるＳＩＰを用いて、標準的なインターネットプロトコル（ＩＰ）上で動作する。既存の電話システム（パケット交換型および回線交換型）もサポートされる。ＩＭＳは、インターネット・エンジニアリング・タスク・フォース（ＩＥＴＦ）によって定義されたようにオープン標準のＩＰプロトコルを用いる。このようにして、例えば２人のＩＭＳユーザ間、ＩＭＳユーザとインターネット上のユーザとの間、あるいはインターネット上の２人のユーザ間のマルチメディアセッションが、まったく同一のプロトコルを用いて確立されうる。ＩＭＳは、インターネットの世界とセルラーの世界とをセルラー技術を用いて結合し、ユビキタスなアクセス技術とインターネット技術を提供して魅力的なサービスを実現する。
【０００３】
ＩＭＳは、３つの主要コンポーネント、すなわち、制御レイヤ上のサービング呼セッション制御機能（Ｓ−ＣＳＣＦ）、アプリケーションレイヤ上のホーム加入者サーバ（ＨＳＳ）およびセッション開始プロトコル（ＳＩＰ）アプリケーションサーバ（ＡＳ）を備えている。
【０００４】
ＳＩＰプロトコルは、ＩＭＳのコア制御技術である。これは、例えば音声とデータストリームとを結合するマルチメディアセッションを制御するのに用いられる。本質的に、ＳＩＰは、当事者間の通信セッションのためのテキストベースのプロトコルである。特に、ＳＩＰは、ネットワークベースのアプリケーション間の通信セッションの確立、制御、終了のために用いられるが、これらのアプリケーション間のメディアチャネルの制御のためにも用いられる。セッションが確立された後は、アプリケーション間の通信のために他のプロトコルを用いることができる。従って、ＳＩＰの主な機能は、サービスレベルでのセッション制御、アドレス指定、そしてモビリティ管理である。
【０００５】
ＩＭＳは、移動ネットワークによって用いられる多くの一般的機能、例えばＡＡＡ（認証、許可、課金）、請求、アクセス制御、ＨＳＳ（すなわち、ユーザプロフィール・データベース）を提供する。このようなＩＭＳの機能は、集中型のアプリケーションによって一様の方法で用いられることが意図されており、従って、例えば音声通信およびデータ通信に別々のメカニズムを適用する必要がない。
【０００６】
ＩＭＳ領域と並行して、拡張マークアップ言語（ＸＭＬ）ウェブサービス（ＷＳ）の概念が発達してきた。ＸＭＬ  ＷＳは、分散型の相互運用性の高いシステムを構築するための比較的新しい技術である。ＸＭＬ  ＷＳは、ＸＭＬベースの標準、例えば、シンプル・オブジェクト・アクセス・プロトコル（ＳＯＡＰ）、ウェブサービス記述言語（ＷＳＤＬ)、ユニバーサル・ディスクリプション、ディスカバリー＆インテグレーション（ＵＤＤＩ)に基づいている。ウェブサービスは、クロスプラットフォームで相互運用可能であり、プログラミング言語に非依存である。ウェブサービスは、企業のシステムおよびネットワークアプリケーションの開発およびシステム統合の手段として普及してきている。その柔軟性とＩＴネットワークとの整合性が高い設計とに起因して、ウェブサービスに基づくアーキテクチャ、例えばサービス指向アーキテクチャ（ＳＯＡ）が、急速に浮上してきており、移動通信ネットワーク設計に採用される傾向がある。
【０００７】
大半のウェブサービスはステートレス(状態がない）であるが、それは、ウェブサービスの呼び出しはそれぞれ、要求を処理するのに必要なすべての情報を含む必要があることを意味する。なぜなら、処理がこのデータだけに依存するからである。この設計は、ＷＳの実装を大いに簡素化する。しかし最近になって、ＷＳ分野の多くの研究者や実行者は、ステートフルなウェブサービスの必要性もあるということを認識するようになってきた。そのようなステートフルなサービスは、複数のサービス呼び出しを含むトランザクションの場合に特に重要である。それらはまた、メッセージ間の相互関係が必要な場合、例えばエレクトロニックバンキング、チケット予約などの場合にも同じく重要である。これらの問題に取り組む複数のＷＳの仕様、例えば、ＷＳコンテクスト、ＷＳアドレッシング、そしてＷＳリソース・フレームワークが、標準化のために提出されたが、これらの大半は、単にＷＳ  ＳＯＡＰの呼び出しヘッダを、セッション情報ヘッダで補完するものである。
【０００８】
ＩＭＳアーキテクチャは、着信するサービス呼び出しはすべてＳＩＰセッションで実行される、と定義する。ＩＭＳノード、例えばＣＳＣＦ−ＩおよびＣＳＣＦ−Ｐは、着信するＳＩＰメッセージを取り扱うＳＩＰサーバである。しかし、今日でも、オペレータ領域には多くの非ＳＩＰベースのサービスが存在し、これらのサービスは非ＳＩＰプロトコルおよび技術（例えば、ウェブサービス、またＪ２ＥＥ、．ＮＥＴなど）を用いる場合が多い。
【０００９】
ＩＭＳ領域において、外部ユーザにサービス、特に非ＳＩＰサービスへのアクセスを提供することは、一般に不可能であるが、それは、外部の第三者である非ＳＩＰサービス・コンシューマアプリケーションは通常、呼び出されたサービスがＩＭＳ領域内に位置するという事実を知らず、しかもそのような外部コンシューマアプリケーションは通常、ＳＩＰをサポートしないからである。従って、非ＳＩＰサービスの消費者は、ＩＭＳ領域内にある目標のサービスにアクセスできず、そのことが、サービスの利用可能性と、結果的にサービスの価値をも大いに減らす。
【００１０】
ＳＩＰとＷＳとは、類似した問題に取り組んでいるのだが、各々がセッション管理に対する独自のソリューションを有している。言い換えると、ＳＩＰとＷＳとによってセッション管理のために用いられるアプローチは、互いに独立している。結果として、ＩＭＳ領域内に配置されるウェブサービスは、認証、課金、請求および他のＩＭＳ機能を含めて、ＩＭＳと互換性のない独自のＷＳインフラストラクチャを必要とする。更に、ＷＳ呼び出しは、サービスの現在のネットワークアドレス（例えばＩＰ番号、ＤＮＳ名など）に関する正確な知識を必要とするＵＲＬ（ユニーク・リソース・ロケータ）に基づいて実行される。これは、移動プラットフォーム（例えば移動端末、そして、自分のＵＲＬを定期的に変更するネットワークノード）の現在のＵＲＬが分かるまでは、それによってホストされるサービスをユーザが呼び出せないことを意味する。
【００１１】
しかし、ウェブサービスのＳＯＡＰ呼び出しヘッダは、セッション情報ヘッダによって補完される。これによって、ペイロードのサイズに比べて大きなＳＯＡＰメッセージができてしまうかもしれない。そのようなヘッダが、各ＳＯＡＰメッセージと共に送信され、従って、セッションレスのウェブサービスより広い帯域幅を消費する。トラヒックの増加は、無線（エア）上の移動環境においては特別な問題になる可能性がある。この環境では、ネットワーク負荷が一層増加し、遅延の拡大が生じることもあろう。この問題に取り組むため、ＳＯＡＰメッセージを圧縮・解凍する圧縮のスキームが採用されてもよいが、これらは、高性能移動端末で用いる場合でも、リソース集約的(intensive)で時間を消費することが示されている。
【００１２】
従って、ＩＭＳ領域内に位置するサービスと、ＩＭＳ領域外に位置するクライアントコンポーネントとの間の相互運用性を増強するための技術が必要である。
【発明の開示】
【課題を解決するための手段】
【００１３】
一態様によれば、本発明は、インターネットプロトコル・マルチメディア・サブシステム（ＩＭＳ）領域と非ＩＭＳ領域との間の相互運用性を実現するための方法を提供し、本方法は、サービスレイヤ上で非ＩＭＳ領域からサービス呼び出しメッセージを受信するステップと、そのメッセージをＩＭＳ領域内のサービスを呼び出すための要求であると識別するためにそのメッセージを分析するステップと、セッション制御レイヤ上でそのメッセージに関連する非ＩＭＳセッション制御プロトコル要素をＩＭＳセッション制御関連プロトコル要素に変換するステップと、そしてＩＭＳセッション制御関連プロトコル要素に基づいてＩＭＳ領域においてＩＭＳ制御セッションを提供するために１以上のメッセージをＩＭＳ領域に向けて送信するステップとを備える。
【００１４】
一例において、変換ステップは、個々の非ＩＭＳセッション制御プロトコル要素を個々のＩＭＳセッション制御関連プロトコル要素に関連付けるマッピングスキームに基づいてもよい。プロトコル要素には、プロトコル固有のメッセージタイプ（例えばサービス呼び出しメッセージ）と、メッセージ部分（例えばヘッダ）と、メッセージフィールド（例えば特定のアドレスを指定するヘッダフィールド）とが含まれる。
【００１５】
また本方法は、サービスレイヤ上でＩＭＳ制御セッションを用いてサービス呼び出しメッセージを転送するステップを有してもよい。更に方法は、ＩＭＳ領域内の呼び出されたサービスに関連する非ＩＭＳ領域からの少なくとも１つのさらなるメッセージを受信するステップと、サービスレイヤ上でＩＭＳ制御セッションを用いてサービスメッセージを転送するステップとを有してもよい。また、特定のサービス要求者（例えばＩＭＳ領域外のアプリケーションまたはネットワークコンポーネント）を１以上の要求された（および／または進行中の）ＩＭＳ領域内のセッションに関連付けるためにここでマッピングスキームが用いられてもよい。
【００１６】
本発明の方法は、更に、セッション中にＩＭＳ領域からメッセージを受信するステップと、ＩＭＳ領域からのメッセージに関連するＩＭＳセッション制御関連プロトコル要素を非ＩＭＳセッション制御プロトコル要素に変換するステップと、非ＩＭＳセッション制御プロトコル要素に基づいて非ＩＭＳメッセージを生成するステップと、セッション中に非ＩＭＳ領域に向けて非ＩＭＳメッセージを送信するステップとを有してもよい。
【００１７】
本発明の一変形形態において、ＩＭＳ領域内のサービスは、ＩＭＳプロトコルベースのサービスである。例えば、ＩＭＳ領域内のサービスは、認証、許可、課金（例えばＡＡＡ）、請求、アクセス制御、及びＨＳＳの諸機能のうち１以上の機能を含み得るＩＭＳサポート機能であってもよいだろう。ここで、ＩＭＳセッション制御プロトコルは、例えばサービスの課金情報を提供するＤＩＡＭＥＴＥＲプロトコルであってもよい。サービス自体が、ＩＭＳ領域の中でまたは外から提供されてもよい。
【００１８】
別の変形形態において、ＩＭＳ領域内のサービスは、非ＩＭＳプロトコルベースのアプリケーション（例えばＩＭＳ領域内から運用されるウェブサービスベースのアプリケーションのような、プログラム的にアクセス可能なサービス）である。ここで、ＩＭＳセッション制御プロトコルは、ＩＭＳサービスセッションの提供（例えば、確立および／または全般的管理）を制御するＳＩＰであってもよい。
【００１９】
非ＩＭＳセッション制御プロトコル要素は、非ＩＭＳセッション制御プロトコルのヘッダを備えることが望ましく、また、ＩＭＳセッション制御関連プロトコル要素は、ＳＩＰヘッダのようなヘッダを備えることが望ましい。一例として、非ＩＭＳプロトコルベースのサービスは、マークアップ言語（ＭＬ）に基づくメッセージングプロトコル、例えばＸＭＬウェブサービスを使用してもよい。
【００２０】
本方法には更に、非ＩＭＳ領域および／またはＩＭＳ領域から受信したメッセージを分析するステップと、分析されたメッセージに基づいてＩＭＳ領域内のサービスとのセッションの状態を判断するステップと、セッションの状態を記憶するステップとが含まれることが望ましい。特定のセッションの状態を記憶することによって、ＩＭＳ領域内の個々のサービスと（非ＩＭＳ領域へ広がる可能性がある）個々のセッションとの間のマッピングを円滑に行うことができる。
【００２１】
さらなる態様によれば、（例えば非ＩＭＳ領域からのメッセージの受信に応じて）ＩＭＳ領域内のサービスとのセッションが進行中かどうかがチェックされ、そして、進行中のセッションがない場合、例えばＳＩＰのようなＩＭＳセッション制御プロトコルの下で新規セッションが確立されてもよい。
【００２２】
非ＩＭＳメッセージは、ＩＭＳ領域内で制御セッションを確立する前に認証されることが望ましい。認証は、非ＩＭＳメッセージの中で指定されたアドレスを分析することによって行われてもよい。
【００２３】
一変形形態において、本方法には更に、固定サービスおよび／または移動サービスの呼び出しのために、ＳＩＰアドレス指定を用いて一様のアドレス指定スキームを採用するステップが含まれる。このようにして、呼び出されることになるサービスがＩＭＳ領域内の移動プラットフォーム上に存在する場合、本方法には更に、移動プラットフォームの現在のユニーク・リソース・ロケータ（ＵＲＬ）に関わらず、ＩＭＳ領域内でサービスを動的に呼び出すためのＳＩＰユニフォーム・リソース・アイデンティファイア（ＵＲＩ）を定義するステップが含まれてもよい。
【００２４】
従って、上記のプロトコル要素変換とは別に動作する可能性のあるさらなる概念は、ＳＩＰアドレス指定による一様のアドレス指定スキームを用いて固定サービスおよび移動サービスをアドレス指定して呼び出すという方法であり、この方法は、移動サービスの現在のＵＲＬとは無関係に移動サービスを動的に呼び出すためのＳＩＰ  ＵＲＩの使用を（例えばＷＳアドレッシングの拡張を定義することによって）定義するステップと、サービスの固定アドレス指定をＳＩＰ  ＵＲＬを用いて定義するステップと、のうちの少なくとも一方を備える。アドレス指定および識別の目的で、ＳＩＰの代わりに他のＩＭＳセッション制御プロトコルが用いられてもよいだろう。
【００２５】
別の態様によって、本発明は、１以上のコンピュータもしくはコンピュータシステム上で実行された場合に本方法の各ステップを実行するためのプログラムコードを備える、コンピュータプログラムを提供する。コンピュータプログラムは、コンピュータ可読記録媒体に記憶されてもよい。
【００２６】
さらなる態様によって、本発明は、コンピュータプロセッサとプロセッサに結合されたメモリとを提供し、そのメモリは、上記の本発明の方法によるＩＭＳ領域と非ＩＭＳ領域との間の相互運用性を提供する各ステップを行うことができる１以上のプログラムでメモリがコーディングされる。
【００２７】
本発明のさらなる態様によって、インターネットプロトコル・マルチメディア・サブシステム（ＩＭＳ）領域と非ＩＭＳ領域との間の相互運用性を実現するためのマッピングデバイスが提供され、そのマッピングデバイスは、サービスレイヤ上で非ＩＭＳ領域から受信された着信するサービス呼び出しメッセージを分析してサービス呼び出しメッセージのうちの１つがＩＭＳ領域内のサービスの呼び出しであるかどうか識別する分析部（分析ユニット）と、セッション制御レイヤ上でメッセージのうちの１つに関連する非ＩＭＳセッション制御プロトコル要素をＩＭＳセッション制御関連プロトコル要素に変換する変換部と、そして、ＩＭＳセッション制御関連プロトコル要素に基づいてＩＭＳ領域においてＩＭＳ制御セッションを提供するために１以上のメッセージを生成するメッセージング部とを備える。
【００２８】
本発明のマッピングデバイスは、ＩＭＳ領域と非ＩＭＳ領域との間のゲートウェイとして実装されてもよい。あるいは、マッピングデバイスは、非ＩＭＳ領域内のネットワークコンポーネントのプロトコルスタックに統合されてもよい。他の実装が同様に用いられてもよい。
【００２９】
ここで、添付の図面を参照して本発明の特定の実施形態について説明する。図面中、類似の参照番号は、類似の特徴を示す。
【発明を実施するための最良の形態】
【００３０】
下記の記述において、限定ではなく説明を目的として、本発明の十分な理解を提供するために、例えば特定のステップのシーケンス、プロトコル標準、および各種のデバイスの構成のような、具体的詳細を説明する。理解されるであろうが、本発明は、これらの具体的詳細から逸れた他の実施形態において実施されてもよい。
【００３１】
更に、当業者であれば理解するであろうが、本明細書で以下に説明する機能は、プログラムされたマイクロプロセッサまたは汎用コンピュータに関連するソフトウェア機能を用いて、および／または(and/or)特定用途向け集積回路（ＡＳＩＣ）を用いて実施されてもよい。
【００３２】
本発明による、異なるプロトコル領域間の相互運用性を提供するための技術を、最初に図１および２に関して記述しよう。図１は、ＩＭＳ領域と非ＩＭＳ領域との間の相互運用性を提供するための方法の実施形態を概略的に図解する。同様に、図２は、ＩＭＳ領域と非ＩＭＳ領域との間の相互運用性を提供するように動作する、マッピングデバイス１００の実施形態を概略的に図解する。
【００３３】
図１および２の両方に関して、方法の第１のステップＳ１は、サービス（またはアプリケーション）レイヤ上で非ＩＭＳ領域からサービス呼び出しメッセージ１０１を受信することを含む。このメッセージ１０１は、マッピングデバイス１００によって受信される。方法の第２のステップは、非ＩＭＳ領域から受信したメッセージを分析することを含む。言い換えると、マッピングデバイス１００によって受信されたメッセージ１０１は、マッピングデバイスの分析部１０２において分析を受ける。第３のステップＳ３は、非ＩＭＳ領域から受信したサービス呼び出しメッセージを、（例えば、ＩＭＳ領域外から提供されることになるサービスと対比して）ＩＭＳ領域内のサービスを呼び出す要求であると識別することを含む。このサービスは、例えば、ＩＭＳサポート機能、例えばＡＡＡまたはＨＳＳであってもよいし、あるいはＩＭＳ領域内から提供される非ＩＭＳサービスであってもよい。マッピングデバイス１００によって受信されたメッセージ１０１の性質を識別するステップは、通常は分析部１０２によって実行される。
【００３４】
非ＩＭＳ領域から受信されたメッセージ１０１が、ＩＭＳ領域内のサービスの呼び出しであると識別された後、方法は、サービス呼び出しメッセージに関連する非ＩＭＳセッション制御プロトコル要素をＩＭＳセッション制御関連プロトコル要素に変換する、さらなるステップＳ４を含む。この点で、本発明の方法は、例えば非ＩＭＳセッション制御プロトコルヘッダをＩＭＳセッション制御プロトコル、例えばＳＩＰのプロトコルヘッダに変換することまたはマッピングすることを提供する。この目的で、マッピングデバイス１００は、非ＩＭＳプロトコル要素のＩＭＳプロトコル要素へのこの変換を行う、変換部１０４を含む。
【００３５】
変換は、着信する呼び出しメッセージのフィールドの中に含まれる情報によってサポートされてもよい。そのような情報は、送信側のＩＰアドレスと、またおそらくその送信側のＤＮＳアドレスと、ウェブサービス（例えばＳＯＡＰ、ＷＳコンテクスト）メッセージのようなサービス固有のフィールドと、メッセージ内に含まれる証明書のかたちでの認証情報とから収集できる。
【００３６】
例えばＣＯＲＢＡの場合、トランザクションまたはセッションに関連する情報を導出するためｒｅｑｕｅｓｔ＿ｉｄフィールドおよびｓｅｒｖｉｃｅ＿ｃｏｎｔｅｘｔｓフィールドが用いられてもよいし、他方、ＳＩＰ  ＦｒｏｍフィールドまたはＳＩＰ  Ｔｏフィールドに関連する情報を導出するのにｒｅｑｕｅｓｔｉｎｇ＿ｐｒｉｎｃｉｐａｌおよびｏｐｅｒａｔｉｏｎのようなフィールドが用いられてもよい。概して、このタイプの情報は、ＳＩＰセッション確立フィールド、例えばＦｒｏｍ、Ｔｏ、Ａｌｌｏｗ、Ｓｕｐｐｏｒｔｅｄ、Ｃｏｎｔａｃｔへのマッピングによって変換可能である。
【００３７】
方法は次いで、ＩＭＳ領域内でＩＭＳセッション制御関連プロトコル要素に基づいてＩＭＳ制御セッションを提供する文脈（例えば、制御セッションを確立すること、または確立された制御セッションを制御すること）における発信メッセージ１０７を生成する、さらなるステップＳ５を含む。セッションの確立は、マッピングデバイス１００とサービスとの間の複数のメッセージの交換を含んでもよい。従って、マッピングデバイスは、ＩＭＳ領域内でセッションを確立する間、通信当事者の役割を担ってもよい。
【００３８】
当然、例えば、ＩＭＳ領域内のサービスを呼び出す非ＩＭＳ領域からの最初のメッセージに加えて、１以上のさらなるメッセージ１０１が、非ＩＭＳ領域から追加で受信されてもよい。この点で、マッピングデバイス１００のメッセージング部１０６は、セッションが一旦確立されてからそのセッションを制御するために、対応する発信ＩＭＳメッセージを生成するように構成される。
【００３９】
同様に、ここで図３を参照すると、呼び出されたサービスのために確立されたセッションの間に、ＩＭＳ領域からメッセージ１０７が受信される場合もありうる。ＩＭＳ領域から受信されたメッセージ１０７は、マッピングデバイス１００によって反対の方式で取り扱われる。具体的には、そのメッセージに含まれるＩＭＳセッション制御関連プロトコル要素、例えばＳＩＰヘッダが、変換部１０４によって非ＩＭＳセッション制御プロトコル要素に変換されてもよく、そして、対応する非ＩＭＳメッセージが、メッセージング部１０６によって生成されてもよい。次いでマッピングデバイス１００が、この非ＩＭＳメッセージ１０１を、確立されたセッションの過程で、またはその後で、非ＩＭＳ領域へ送信する。理解されるであろうが、図２および３において、参照番号１０１は、非ＩＭＳメッセージを示し、参照番号１０７は、ＩＭＳメッセージを示す。
【００４０】
下記のいくつかの実施形態は、セッション指向の非ＳＩＰサービスとＳＩＰサービスとの間の相互運用性を可能にするための一般的なアプローチを提供する。更に、また、それらの実施形態は、非セッション指向のサービス技術（例えばウェブサービス）にセッション機能を提供することをも可能にする。
【００４１】
非ＳＩＰサービスとＳＩＰセッションとの間のマッピングは、（おそらく複数の異なるプロトコルで）着信するメッセージを構文解析することによって特定のセッションの状態を記憶するエンティティ（例えば図２および３に示すマッピングデバイス１００または他のデバイス）によって達成される。次いで、この知識は、（この場合もまた、おそらく複数の異なるプロトコルで）適切な発信メッセージを生成するのに用いられる。
【００４２】
セッションベースではなく、ＩＭＳ領域内に配置されるサービスを呼び出すような（ＩＭＳ領域外からの）非ＳＩＰアプリケーションは、ＳＩＰのことを認識しないので、ＩＭＳによって必要とされるセッションを確立して維持することができない。そのため、セッションマッピングデバイスの実装は、トランザクションのセッション認識部分によって必要とされるのに応じて、対象のアプリケーションのためのセッションの開始と管理を処理する。このことは、呼び出し手と呼び出されるサービスとの間のすべてのメッセージがマッピングデバイスを経由することを必要とすることがある。
【００４３】
これを達成するため、オペレータは、公衆に利用可能なＩＭＳサービスに関連するすべての着信トラヒックを、マッピングデバイス経由で（例えばＩＰレベルかまたはより高位のレベル上で）ルーティングしてもよい。例えば、ＩＭＳ領域内のサービスが、マッピングデバイス上でホストされるＵＲＬまたは他の何らかのアドレス指定メカニズムを介して公開されてもよいだろう。オペレータが、アドレス指定を目的としてこのＵＲＬを外部の当事者に公開してもよい。
【００４４】
明瞭にするために、技術的アプローチを説明するのに用いられる実施形態では、ＩＭＳ領域内で典型的な非ＳＩＰサービスをホストするアプリケーションサーバは、呼び出されるサービスに適したＳＩＰスタックと非ＳＩＰスタック（例えば、ＷＳ、Ｊ２ＥＥ、ＣＯＲＢＡ等）を両方共含むものとする。異なるノード構成で展開される異なるプロトコルスタックを含む設定が他にもありうるけれども、一般的な技術的アプローチは同じである。
【００４５】
以下で、セッションのマッピングメカニズムの一実施形態を、ＩＭＳ領域内のサービスＢを呼び出す（例えばＩＭＳ領域外に位置するＷＳ対応ユーザ端末上で実行される）非ＳＩＰアプリケーションＡに関して説明する。従って、この非ＳＩＰアプリケーションは、ＩＭＳサービスＢに関するクライアントとして動作する。
【００４６】
セッションのマッピングは、下記のステップで行うことができる。
【００４７】
１．  非ＳＩＰアプリケーションから着信する要求が、以下で更に詳細に記述する複数のメカニズムに基づいて認証されてもよい。
【００４８】
２．  ＩＭＳサービスＢを呼び出す非ＳＩＰアプリケーションＡの認証に基づいて、非ＳＩＰアプリケーションＡとＩＭＳサービスＢとの間の（ＩＭＳ領域内のセッション制御レイヤ上の特定のセッションに対応する）進行中のサービスレイヤトランザクションに関する知識をマッピングデバイス１００がすでに有しているかどうかを、マッピングデバイス１００がチェックする。この目的で、非ＳＩＰアプリケーションＡおよび／またはその他の非ＳＩＰアプリケーションＡ’についての複数の以前に確立されたセッションをリストしている可能性があるマッピングテーブルが参照されてもよい。
【００４９】
３．  非ＳＩＰアプリケーションＡとＩＭＳサービスＢとの間に進行中のトランザクションがない場合、新規のＳＩＰセッションが初期化される。ここで、マッピングデバイス１００は、ＩＭＳサービスＢとの間で確立されたＳＩＰセッションにおける通信相手の役割を果たす。
【００５０】
ａ．  非ＳＩＰアプリケーションＡがセッションを認識しない場合、デバイス１００は、非ＳＩＰアプリケーションＡの機能をそれ以上考慮することなく新規セッションを確立する。
【００５１】
ｂ．  非ＳＩＰアプリケーションＡがセッションを認識する場合、デバイス１００は、非ＳＩＰアプリケーションＡのセッション機能（例えば、ＷＳコンテクスト、ＷＳアドレッシングヘッダ等）に従って新規セッションを確立するであろう。下記の第１の例は、ＷＳクライアントＡによってＷＳセッション管理用のＷＳコンテクスト仕様を用いて作成されたサービス呼び出しを例示する。第２の例は、マッピングデバイス１００によって途中で取られた(intercepted)ＳＯＡＰメッセージのマッピングから収集されたセッション情報を用いて、マッピングデバイス１００が、ＩＭＳサービスＢとの新規ＳＩＰセッションをどのように確立するかを例示する。この設定は、サービスＢがＳＩＰスタックとＷＳスタックを両方含むことを意味する。他にも、異なるノード上に配置される異なるプロトコルスタックに関連する他の設定が存在するかもしれない。
【００５２】
ＷＳコンテクストセッションを指定するＸＭＬベースのサービス呼び出しメッセージの一例を以下に挙げる。
【００５３】
<soap:Envelope xmlns:soap="http://www.w3.org/2002/06/soap-envelope">
<soap:Header>
<context xmlns="http://docs.oasis-open.org/wscaf/2004/09/wsctx" timeout="100"
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
xmlns:soapbind=http://schemas.xmlsoap.org/wsdl/soap/
soap:mustUnderstand="l">
<context-identifier>
http://services.operator.com/wscaf/2004/09/wsctx/abcdef:012345
</context-identifier>
<type>
http://services.operator.com/wscaf/2004/09/wsctx/context/mmservice
</type>
</context>
</soap:Header>
<soap:Body>
<!-- Application Payload -->
</soap:Body>
</soap:Envelope>
【００５４】
マッピングデバイス１００は、上記のサービス呼び出しメッセージに含まれる非ＳＩＰ要素を、以下のように、ＷＳコンテクストセッションからのセッション情報を指定するＳＩＰセッション確立メッセージに変換する。
【００５５】
INVITE sips:service1@operator.com SIP/2.0
Via:SIP/2.0/TLS server.operator.com:5061;branch=z9hG4bK74bf9
Max-Forwards:70
From:SESSION1l <sips:sipsoapgw@operator.com>;tag=1234567
To:SIPAS<sips:service1@operator.com>
Call-ID:12345601@operator.com
CSeq:1 INVITE
Contact:<sips:sipsoapgw@operator.com>
Allow:INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Supported:replaces
Content-Type:application/sdp
Content-Length:...
v=0
o=servicebroker 2890844526 2890842807 IN IP4 asb.operator.com
s=Conference Service
t=0 0
m=audio 5004 RTP/AVP 0
c=IN IP4 131.160.1.112
a=rtpmap:0 PCMU/8000
m=message 49172 IMTP/TCP application/soap+xml
c=IN IP4 asb.operator.com
a=direction:both
a=wsdl:http://schemas.operator.com/conferencecontrol.wsdl
a=wscafcontextidentifier:http://services.operator.com/wscaf/2004/09/wsctx/abcdef:012345
a=wscaftype:http://services.operator.com/wscaf/2004/09/wsctx/context/mmservice
【００５６】
４．  既存のトランザクションの場合、その状態（ステータス）は、処理された単数又は複数のメッセージに基づいて更新される。
【００５７】
５．  セッション情報を搬送するのに用いられるＳＯＡＰ要素は、ＳＩＰヘッダに変換され、逆もまた同様である。
【００５８】
すでにＳＩＰセッションにマップされたトランザクションは、ＳＩＰセッション開始の間にすでに交渉されたＳＯＡＰメッセージ内のＷＳセッション関連情報の再送信を回避できる。以下の例は、（ステップ３ｂで記述したように）確立されたＳＩＰセッションに基づいて、ＷＳサービス呼び出しのためのＷＳコンテクストセッションに関する情報が、ＳＯＡＰヘッダ内でのＷＳコンテクスト関連情報の反復を回避することを通じてどのように最適化されうるかを例示する。
【００５９】
ａ）ＷＳコンテクストセッションを指定するサービス呼び出しの一例
<soap: Envelope
xmlns:soap="http://www.w3.org/2002/06/soap-envelope">
<soap:Header>
<context xmlns="http://docs.oasis-open.org/wscaf/2004/09/wsctx" timeout="100"
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
xmlns:soapbind=http://schemas.xmlsoap.org/wsdl/soap/
soap:mustUnderstand="l">
<context-identifier>
http://services.operator.com/wscaf/2004/09/wsctx/abcdef:012345
</context-identifier>
<type>
http://services.operator.com/wscaf/2004/09/wsctx/context/mmservice
</type>
</context>
</soap:Header>
<soap:Body>
<!-- Application Payload
MMService specific payload-->
</soap:Body>
</soap:Envelope>
【００６０】
ｂ）ＷＳコンテクストセッションの明示的な指定のない最適化されたサービス呼び出しの一例
<soap:Envelope xmlns:soap="http://www.w3.org/2002/06/soap-envelope">
<soap:Header>
</soap:Header>
<soap:Body>
<!-- Application Payload
MMService specific payload -->
</soap:Body>
</soap:Envelope>
【００６１】
６．  こうして生成されたＳＩＰメッセージが、ＩＭＳサービスＢへ転送される。
【００６２】
上記アルゴリズムのステップ３で記述されたようにＳＯＡＰエンベロープに基づく認証が適用可能になる前に、必要とされる証明書をどのように提供するかについて、サービス消費者とサービスプロバイダとの間で合意に達する必要がある。そのような証明書は、下記のプロトコルを用いて交換することができる。
【００６３】
１．  オペレータが、サービスプロバイダとして、アプリケーションを記述しユーザを認証する各種のタイプのデータ（例えばログイン名、パスワード、アプリケーション名など）を含んだ証明書を交換するためのフォーマットを定義する。そのようなフォーマットは、各種の手段で実装可能であり、例えば、適切なパラメータを含むように、あるいは、この場合もまた適切なヘッダパラメータを使ってＳＯＡＰメッセージのヘッダを拡張するように、所与のサービスのＷＳＤＬ記述（ディスクリプション）を拡張することによって実装可能である。
【００６４】
２．  認証を求めるアプリケーションは、ステップ１で記述したように、オペレータが提供するスキーマに基づいて認証スキームを実装する必要がある。
【００６５】
ａ．  オペレータの加入者の認証のための証明書は、オペレータとアプリケーションとの両者が知っている共通の秘密（例えば、ユーザのｉｄシステム、端末データなど）に基づいて生成される。
【００６６】
ｂ．  非加入者の認証のための証明書は、事前に合意される必要がある。これは、オペレータが提供する適切なサイトに登録することを通じて行われてもよい。
【００６７】
以下に、上記のセッションマッピングメカニズムと組み合わせて使うことのできる認証メカニズムの一実施形態について記述しよう。入力として、このメカニズムは、着信する呼び出し要求メッセージを、例えばＩＭＳ領域外の端末上で実行される非ＳＩＰアプリケーションから受信する。出力は、非ＳＩＰアプリケーションの認証ステータスであろう。
【００６８】
１．  着信する要求のＩＰアドレスを分析する
ａ．  信頼される領域内のアドレスから（オペレータ自身からかまたは他の信頼されるネットワークから）発信された要求は、更にステップ２で処理される。
ｂ．  信頼される領域外から発信された要求は、更に、ステップ４で処理される。
【００６９】
２．  ＩＰアドレスが、要求に認証の証明書を追加する、既知であって信頼されるノード（例えばＷＡＰゲートウェイ）のアドレスであるか？
ａ．  そうであれば、埋め込まれた証明書が利用可能であるか？（例えば、ＷＡＰゲートウェイによって挿入された特別なＨＴＴＰヘッダのためのＷＡＰゲートウェイチェックの場合）
ｉ    そうであれば、証明書を分析する（例えばＭＳＩＳＤＮ番号を抽出する）
ｉｉ  そうでなければ、ステップ３に進む
ｂ．  そうでなければ、ステップ３に進む
【００７０】
３．  要求（例えばＳＯＡＰエンベロープ）を分析して認証の（例えばＳＯＡＰヘッダ／本文内部の）証明書の利用可能性をチェックする
ａ．  証明書が利用可能であれば、元のサービスＡＰＩに適合するため、マッピングデバイスによって必要とされる認証データを要求から除去する。ステップ５においてこのデータに基づいてさらなる認証を続行する。
【００７１】
以下の例は、ＩＭＳセッションの確立に必要な証明書が、着信する拡張ＳＯＡＰメッセージからどのように抽出され、それによって非拡張ＳＯＡＰメッセージを生成するのかを、例示する。
【００７２】
認証の証明書によって拡張されたＳＯＡＰ要求の一例を以下に挙げる。
<soap: Envelope xmlns:soap=http://www.w3.org/2002/06/soap-envelope
xmlns:auth="http://liberty.org">
<soap:Header>
<auth:credential1 name="user1"/>
<auth:credential2:password="secret"/>
</soap:Header>
<soap:Body>
<!--Application Payload
MMService specific payload -->
</soap:Body>
</soap:Envelope>
【００７３】
認証の証明書のないＳＯＡＰ要求の一例を以下に挙げる。
<soap:Envelope xmlns:soap="http://www.w3.org/2002/06/soap-envelope">
<soap:Header>
</soap:Header>
<soap:Body>
<!--Application Payload
MMService specific payload-->
</soap:Body>
</soap:Envelope>
【００７４】
ｂ．  そうでなければ、ステップ４へ進む
【００７５】
４．  着信するパケットのアドレス特性（例えばＩＰアドレス、ＤＮＳアドレス、ＭＡＣアドレス等）を用いて、暗示的にユーザのｉｄシステムを判断し、適切な一時的証明書を作成する。留意すべきだが、この識別は、これまでのステップを通じて可能であった識別ほど正確でもセキュアでもない。精度の不足は、例えば、ＩＰアドレスとアプリケーション間の一意のマッピングが存在しないことによる。
【００７６】
５．  証明書をＩＭＳ形式に変換し、それらを用いてアプリケーションを認証する。
【００７７】
以下で、マッピングデバイス１００のいくつかの実施形態について、もっと詳しく論じよう。
【００７８】
図４に示す一実施形態によると、マッピングデバイス１００は、ＩＭＳ領域１０と、非ＩＭＳ領域に位置するクライアント２０（例えばウェブサービスを用いるＳＯＡＰクライアント２０）と、の間に位置するゲートウェイノードとして実装される。図４は、ＩＭＳ領域１０内に配置される非ＳＩＰのオペレータが制御するサービスにアクセスするための非ＳＩＰからＳＩＰへの実行時（ランタイム）セッションマッピングを図解する。
【００７９】
サービス記述プロトコル（ＳＤＰ）は、さまざまなタイプのＳＩＰサービスを記述するのに用いられうる。ＳＩＰセッション開始は、それぞれ、ＳＤＰ記述を含みうる。従って、１つの可能性は、特定の非ＩＭＳサービス呼び出しおよびセッション確立／管理技術に対応するものとして特定のタイプのセッションを確立するためのＳＤＰ記述を定義することであろう。従ってセッションマッピング／変換も、着信するサービス呼び出しのあるフィールドを、それらに対応するＳＤＰ記述のフィールドにマッピングすることによって使用可能になりうる。この場合、特定のタイプの非ＩＭＳサービス呼び出し（例えばＣＯＲＢＡサービス、Ｊ２ＥＥサービス、Ｊａｖａ（登録商標）  ＲＭＩサービス、．ＮＥＴサービス、および当然、純粋なＳＯＡＰサービス）が、これらの技術についての特定の事前定義されたＳＤＰ記述にマップされるであろう。
【００８０】
セッションマッピングは、現在進行中のセッションをリストするテーブルを用いて実装されてもよい。テーブルにおいて、進行中の各セッションは、クライアント２０からサービスレイヤメッセージを受信すると、ＩＭＳ領域１０内で進行中のセッションにそのメッセージが関連するか否かをマッピングデバイス１００が識別できるようにするような、特定のパラメータに関連付けられてもよい。原則として、個々のクライアント２０は、ＩＭＳ領域１０内のまったく同一のサービスまたはさまざまなサービスに関する複数の個別セッションに関連付けられてもよい。
【００８１】
図４に示すように、サービス呼び出しメッセージが、サービスレイヤ（ＨＴＴＰ上のＳＯＡＰ）上でマッピングデバイス１００によって受信され、ＩＭＳ領域内のサービスを呼び出していると認識される。次いで、セッション制御レイヤ（「ＳＩＰレイヤ」）上で、呼び出されるサービスのためのＩＭＳ制御セッション（「ＳＩＰで制御されるセッション」）を提供するという文脈においてマッピングデバイス１００内でプロトコル要素変換が起こる。次いで、ＩＭＳ制御セッションが、ＩＭＳ領域１０内のクライアント２０と要求されるサービスとの間の通信の伝達手段として用いられる。
【００８２】
図４のシナリオにおいて、マッピングデバイス１００は、呼び出し側のＳＯＡＰクライアント２０には完全に透過的である（すなわち、クライアント２０は、マッピングデバイス１００の存在と機能との知識を何も有する必要がない）。これは、非ＩＭＳ領域において標準的な（修正されていない）クライアント２０による利用が可能となることから、有利である。
【００８３】
またマッピングデバイス１００は、非ＩＭＳ領域の側に、例えば、クライアントプロトコルスタック（すなわち、Ｊ２ＥＥ、ＷＳ  ＳＯＡＰスタック等）を修正することによってクライアント２０の中に、実装されてもよい。これは、図５の中で、ウェブサービスを一例として用いて描かれている。
【００８４】
図５は、ＩＭＳ領域１０内に配置される非ＳＩＰオペレータが制御するサービスにアクセスするための、非ＳＩＰからＳＩＰへの実行時（ランタイム）セッションマッピングを図解する。このシナリオにおいて、マッピングデバイス１００は、非ＩＭＳ領域内のクライアント２０のクライアントプロトコルスタックに統合される。このソリューションは、追加のネットワークノード（例えば図４に示す実施形態の場合のゲートウェイ）の配置を必要としないため、特に有利である。
【００８５】
ＩＭＳ対応のクライアント（例えば携帯電話のようなユーザ端末）が市場に広く行き渡っていないということを考えると、そのような修正されたスタックが、そのようなクライアントの最初の世代に直接実装されてもよいだろう。既存のクライアントが追加機能によって更新される必要があるような典型的な配置シナリオに比べて、更新関連コストを排除することから、これは有利である。
【００８６】
ゲートウェイとしてのマッピングデバイス１００の実装は、通常、ＩＭＳ領域１０内のオペレータが制御するサービスへの透過的なアクセスに用いられる。ゲートウェイを利用するソリューションの特別用途の事例は、２つの非ＩＭＳコンポーネント２０および３０が、ＩＭＳ領域１０によって提供されるサポート機能（例えばＤＩＡＭＥＴＥＲプロトコルを用いたＡＡＡ、ＨＳＳ等）というかたちでＩＭＳサービスを利用できるように、そのようなゲートウェイ１００を通じて相互に通信するという状況であってもよいだろう。このシナリオは、図６に示しており、第三者であるサービスプロバイダはオペレータのことを信用できる信頼に足る仲介者であると考えるため、特に彼らにとっては興味深い。オペレータも同様に、この機能を提供することについて料金を請求できることから、利益を得る可能性がある。
【００８７】
図６に示すシナリオでは、非ＩＭＳ領域のサービスプロバイダ３０が、ＩＭＳオペレータとの適切な営業上の契約を有し、そして、マッピングデバイスゲートウェイ１００を介して、自社のサービスが登録されていてアクセス可能であるようなかたちで、自社のサービスを展開していることが必要となる可能性がある。あるいはまた、非ＩＭＳ領域内のクライアント２０が、オペレータに登録されていてもよい。これによって、クライアント２０は、第三者サービスプロバイダ３０に対して自分を識別させることを目的として、オペレータが提供するＳＩＰの認証メカニズムおよび許可メカニズムを活用できる。
【００８８】
図７を参照して、上記の諸実施形態と組み合わせて用いられうるＳＩＰベースの一様の(uniform)アドレス指定およびサービス呼び出しスキームの一実施形態について、記述しよう。
【００８９】
ＨＴＴＰ（ハイパーテキスト伝送プロトコル）  ＵＲＬを用いる代わりに、論理的なＳＩＰ  ＵＲＩ（そして結果的にＳＩＰ  ＵＲＬ）が、一様のアドレス指定スキームのためおよび移動サービス呼び出しのために用いられる。ＵＲＩを介するサービスへのアクセスは、その現在のＵＲＬに関わらず透過的なアクセスをサービスに提供することによって、サービスのモビリティを可能にする。これによって、ネットワークへの固定的な接続を有せず、従って、固定されたＵＲＬを有しない移動デバイス上に配置されるＩＭＳサービスのアドレス指定が可能になる。
【００９０】
図７に示すシナリオは、以下のような２つの主なステップを含む。即ち、
ａ．  （おそらく、ＷＳアドレッシングの拡張を定義することによって）現在のＵＲＬに関わらず移動ＩＭＳサービスを動的に呼び出すためのＳＩＰ  ＵＲＩの使用を定義すること
ｂ．  ＳＩＰ  ＵＲＬを用いるサービスの固定的アドレス指定を定義すること
である。
【００９１】
上記の諸実施形態で示したように、ＩＭＳ領域と他のいずれかの領域との間の相互運用性は、ＷＳセッション／サービスと（１以上の）ＳＩＰセッションとの間のマッピングを確立することによって増強される。この文脈においては、セッション情報を搬送するのに用いられるＳＯＡＰ要素は、ＳＩＰヘッダに変換されることができ、逆も同様である。ＩＭＳ／ＳＩＰネットワーク内でのＳＯＡＰメッセージの中のＷＳセッション関連情報の再送信は、ＳＩＰセッションにすでにそれが与えられている場合、回避されうる。
【００９２】
それらの技術は、例えば非ＳＩＰサービスとＳＩＰセッションとの間で透過的にマッピングし、クライアントアプリケーションを改造しなくても使用可能な、ＳＩＰから非ＳＩＰへの（例えばＳＩＰ−ＳＯＡＰ）ゲートウェイによって実行されてもよい。あるいは、それらの技術は、ＷＳスタック／ＳＩＰスタックを拡張してアプリケーションを進化させ、ネットワーク内に追加のインフラコンポーネントがなくてもアプリケーションがＷＳセッションとＳＩＰセッションとの間で透過的にマッピングできるようにすることによって、上記の実施形態の中で実行される。
【００９３】
このように、諸実施形態は、ＩＭＳ領域内またはＩＭＳネットワーク内でＷＳ呼び出しを提供する。それらは、ＷＳセッション管理のための既存の、より効率的なＳＩＰベースのセッション管理メカニズムの使用を可能にし、ＩＭＳのシステムおよびインフラと、ＩＭＳ領域内に配置されるウェブサービスとの間の、よりよい相互運用性と統合とを提供する。更に、諸実施形態によって、例えばＩＭＳ領域外のウェブサービスのようなサービスの呼び出しや制御についても、ＡＡＡ、請求などのための標準的なＩＭＳメカニズムの使用が、可能になる。そうすることで、諸実施形態によって、ウェブサービスをＩＭＳシステムにシームレスに統合することが可能になる。開発者は、ＩＭＳ／ＳＩＰプロトコルおよびＡＰＩを明示的にサポートする必要がない。これがすべて、透過的に、あるいはＷＳスタックおよび／またはＳＩＰスタックの拡張によって、行われうる。
【００９４】
更に、諸実施形態によって、例えばＩＭＳネットワーク内のウェブサービスによるセッション情報の送信に必要なトラヒック量の削減が可能になる。また諸実施形態は、ウェブサービスのＵＲＬとは異なるかもしれない、ウェブサービスのＵＲＩを用いる呼び出しを可能にすることによって、ウェブサービスにモビリティを与える。これによって、同じＵＲＩでアドレス指定可能でありながら、サービスがその実行プラットフォームを（従ってそのＵＲＬを）変えることが可能になる。この点で、サービス呼び出し呼のルーティングは、全ユーザの現在位置を知っていて、サービス呼び出し呼をＳＩＰ  ＵＲＩを用いて現時点で正確なＳＩＰ  ＵＲＬに転送する、ＳＩＰレジストリ（すなわち、ＩＭＳ領域内のＣＳＣＦノード）によって取り扱われてもよい。
【００９５】
ここで留意すべきだが、上記で述べた各アプローチは、ウェブサービスセッションをＳＩＰセッションにマッピングするためだけに用いられうるのではない。原則として本発明は、セッションという概念を持つものであればいかなる外部のリモートプロシージャコール（ＲＰＣ）プロトコルを、必要性に適していればいかなるＩＭＳ内部プロトコルにマッピングするのにも用いられうる。これらには、例えば、ＣＯＲＢＡ、Ｊａｖａ（登録商標）  ＲＭＩ、およびその他のプロプライエタリのプロトコルが含まれてもよい。
【００９６】
特定の実施形態に関して本発明について記述してきたが、当業者であれば、本発明は本書で記述され図解される特定の実施形態に限定されないことを理解するであろう。従って、本発明についてその好適実施形態に関して記述してきたが、この開示は例示にすぎないことが、理解されるべきである。従って、本発明は、ここに添付する請求項の範囲によってのみ限定されることが意図される。
【図面の簡単な説明】
【００９７】
【図１】本発明による方法の実施形態を図解する概略的なフローチャートである。
【図２】本発明による、非ＩＭＳ領域から受信されたメッセージを変換するように動作するマッピングデバイスの実施形態の概略的な図解である。
【図３】本発明による、ＩＭＳ領域から受信されたメッセージを変換するように動作するマッピングデバイスの実施形態の概略的な図解である。
【図４】ＩＭＳ領域内のウェブサービスにアクセスするためＳＩＰ上のＳＯＡＰゲートウェイとして実施された、本発明による一実施形態を図解する図である。
【図５】ＩＭＳ領域内のウェブサービスにアクセスするため、設計時のＳＯＡＰからＳＩＰへのセッションマッピングとして実施された、本発明による一実施形態を図解する図である。
【図６】ユーザ／サービス管理を目的としてＩＭＳ設備に透過的にアクセスするためのＳＩＰ上のＳＯＡＰマッピングとして実施された、本発明による一実施形態を図解する図である。
【図７】移動サービスのアドレス指定を実施するためＳＩＰ  ＵＲＩを用いた、本発明による一実施形態を図解する図である。
【図１】
2009520390.tif 000003
【図２】
2009520390.tif 000004
【図３】
2009520390.tif 000005
【図４】
2009520390.tif 000006
【図５】
2009520390.tif 000007
【図６】
2009520390.tif 000008
【図７】
2009520390.tif 000009
【手続補正書】
【提出日】平成20年4月29日(2008.4.29)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
インターネットプロトコル・マルチメディア・サブシステム（ＩＭＳ）領域（１０）と非ＩＭＳ領域（２０）との間の相互運用性を提供する方法であって、
サービスレイヤ上で前記非ＩＭＳ領域からサービス呼び出しメッセージを受信するステップと、
前記ＩＭＳ領域内のサービスを呼び出す要求として前記メッセージを識別するために前記メッセージを分析するステップと、
セッション制御レイヤ上で、前記メッセージに関連する非ＩＭＳセッション制御プロトコル要素をＩＭＳセッション制御関連プロトコル要素に変換するステップと、
前記ＩＭＳセッション制御関連プロトコル要素に基づいて、前記ＩＭＳ領域内にＩＭＳ制御セッションを提供するために前記ＩＭＳ領域へ１以上のメッセージを送信するステップと、
前記サービスレイヤ上で、前記ＩＭＳ制御セッションを使用して前記サービス呼び出しメッセージを転送するステップと、
を備えることを特徴とする方法。
【請求項２】
前記ＩＭＳ領域内で呼び出された前記サービスに関連する更なるメッセージを前記非ＩＭＳ領域から受信するステップと、
前記サービスレイヤ上で、前記ＩＭＳ制御セッションを使用して前記サービスメッセージを転送するステップと、
を更に備えることを特徴とする請求項１に記載の方法。
【請求項３】
前記セッションの間に前記ＩＭＳ領域からメッセージを受信するステップと、
前記メッセージに関連する前記ＩＭＳ領域からのＩＭＳセッション制御プロトコル要素を非ＩＭＳセッション制御プロトコル要素に変換するステップと、
前記非ＩＭＳセッション制御プロトコル要素に基づいて非ＩＭＳメッセージを生成するステップと、
前記非ＩＭＳメッセージを前記非ＩＭＳ領域へ送信するステップと、
を更に備えることを特徴とする請求項１又は２に記載の方法。
【請求項４】
前記非ＩＭＳメッセージは前記セッションの間に前記非ＩＭＳ領域へ送信されることを特徴とする請求項３に記載の方法。
【請求項５】
前記ＩＭＳ領域内の前記サービスは、認証、許可、課金、請求、アクセス制御、或いはＨＳＳなどのＩＭＳサポート機能であることを特徴とする請求項１乃至４のいずれか１項
【請求項６】
前記ＩＭＳ領域内の前記サービスは、非ＩＭＳプロトコルベースのアプリケーションであることを特徴とする請求項１乃至５のいずれか１項に記載の方法。
【請求項７】
前記ＩＭＳセッション制御プロトコル要素は、セッション開始プロトコル（ＳＩＰ）ヘッダを含み、
前記非ＩＭＳセッション制御プロトコル要素は非ＳＩＰヘッダを含む
ことを特徴とする請求項１乃至６のいずれか１項に記載の方法。
【請求項８】
前記非ＩＭＳ領域は、拡張マークアップ言語（ＭＬ）ベースのメッセージのためのプロトコルを使用することを特徴とする請求項１乃至７のいずれか１項に記載の方法。
【請求項９】
前記非ＩＭＳ領域及び前記ＩＭＳ領域のうちの少なくとも一方から受信した前記メッセージを分析するステップと、
前記分析したメッセージに基づいて前記ＩＭＳ領域内の前記サービスについての前記セッションの状態を判断するステップと、
前記セッションの前記状態を格納するステップと、
を備えることを特徴とする請求項１乃至８のいずれか１項に記載の方法。
【請求項１０】
前記ＩＭＳ領域内の前記サービスについてのセッションが進行中であるか否かをチェックするステップと、
進行中のセッションが存在しない場合に、前記ＩＭＳセッション制御プロトコルの下で新たなセッションを開始するステップと、
を備えることを特徴とする請求項１乃至９のいずれか１項に記載の方法。
【請求項１１】
サービス要求者と、前記ＩＭＳ領域内の１以上の要求されたセッション及び進行中のセッションの少なくともいずれかと、を関連付けるステップをさらに備えることを特徴とする請求項１乃至１０のいずれか１項に記載の方法。
【請求項１２】
前記サービス要求者は、前記ＩＭＳ領域外のアプリケーション又はネットワークコンポーネントであることを特徴とする請求項１１に記載の方法。
【請求項１３】
前記ＩＭＳ領域内で前記制御セッションを確立することに先立って前記非ＩＭＳメッセージを認証するステップを備えることを特徴とする請求項１乃至１２のいずれか１項に記載の方法。
【請求項１４】
前記非ＩＭＳメッセージを認証する前記ステップは、前記メッセージ内で指定されたアドレスを分析するステップを含むことを特徴とする請求項１３に記載の方法。
【請求項１５】
固定サービス及び移動サービスのうちの少なくとも一方の呼び出しのためのＳＩＰアドレス指定を使用する一様なアドレス指定スキームを使用するステップを備えることを特徴とする請求項１乃至１４のいずれか１項に記載の方法。
【請求項１６】
呼び出される前記サービスは、前記ＩＭＳ領域内の移動プラットフォーム上に存在し、
当該方法は、前記移動プラットフォームの現在のユニーク・リソース・ロケータ（ＵＲＬ）に関わらず前記ＩＭＳ領域内の前記サービスの動的な呼び出しのためのＳＩＰユニーク・リソース・アイデンティファイア（ＵＲＩ）を定義するステップを備える
ことを特徴とする請求項１乃至１５のいずれか１項に記載の方法。
【請求項１７】
前記ＩＭＳ領域内の前記サービスに関する固定されたアドレス指定のためのＳＩＰユニーク・リソース・ロケータ（ＵＲＬ）を定義するステップを備えることを特徴とする請求項１乃至１６のいずれか１項に記載の方法。
【請求項１８】
１以上のコンピュータ又はコンピュータシステム上で実行されると請求項１乃至１７のいずれか１項に記載の各ステップを実行するプログラムコードを含むコンピュータプログラム。
【請求項１９】
コンピュータ読み取り可能な記録媒体に格納されていることを特徴とする請求項１８に記載のコンピュータプログラム。
【請求項２０】
コンピュータプロセッサと、当該プロセッサに結合されたメモリとを含むシステムであって、
前記メモリは、請求項１乃至１７のいずれか１項に記載の方法に従ってセッション開始プロトコルと非セッション開始プロトコルとの間の相互運用性を提供する各ステップを実行可能な１以上のプログラムでコーディングされている
ことを特徴とするシステム。
【請求項２１】
インターネットプロトコル・マルチメディア・サブシステム（ＩＭＳ）領域（１０）と非ＩＭＳ領域（２０）との間の相互運用性を提供するマッピングデバイス（１００）であって、
サービスレイヤ上で前記非ＩＭＳ領域（２０）から受信した着信するサービス呼び出しメッセージ（１０１）のうちの１つが前記ＩＭＳ領域（１０）内のサービスの呼び出しであるか否かを識別するために当該サービス呼び出しメッセージ（１０１）を分析する分析ユニット（１０２）と、
セッション制御レイヤ上で、前記メッセージ（１０１）のうちの１つに関連する非ＩＭＳセッション制御プロトコル要素をＩＭＳセッション制御関連プロトコル要素に変換する変換ユニット（１０４）と、
前記ＩＭＳセッション制御関連プロトコル要素に基づいて、前記ＩＭＳ領域（１０）内にＩＭＳ制御セッションを提供するために１以上のメッセージ（１０７）を生成するメッセージングユニット（１０６）と、
を備え、前記サービスレイヤ上で、前記ＩＭＳ制御セッションを使用して前記サービス呼び出しメッセージを転送するように構成されることを特徴とするマッピングデバイス。
【請求項２２】
前記ＩＭＳ領域と前記非ＩＭＳ領域との間のゲートウェイとして実装されることを特徴とする請求項２１に記載のマッピングデバイス（１００）。
【請求項２３】
前記非ＩＭＳ領域内のネットワークコンポーネントのプロトコルスタック内に統合されることを特徴とする請求項２１に記載のマッピングデバイス（１００）。
【請求項２４】
請求項２１乃至２３のいずれか１項に記載のマッピングデバイスを含むことを特徴とするユーザ端末。
【国際調査報告】
2009520390.tif 000010
2009520390.tif 000011
2009520390.tif 000012