(57)【特許請求の範囲】
【請求項１】
サーバにおいて、サービスに加入していない非加入ユーザ装置から、当該サービスの識別子と当該サービスに加入している加入ユーザ装置の識別子とを含む当該サービスについてのサービスリクエストを受信するステップと、
前記サーバにより、前記サービスリクエストから前記サービスの前記加入ユーザ装置の前記識別子を抽出するステップと、
前記サーバから、前記加入ユーザ装置に対して、前記非加入ユーザ装置のための前記サービスへのアクセスの承認についての承認リクエストを送信するステップと、
前記サーバにおいて、前記加入ユーザ装置から、前記非加入ユーザ装置のための前記サービスへのアクセスを承認する承認メッセージを受信するステップと、
前記非加入ユーザ装置への前記サービスの提供を承認するステップと、
を含む、サーバにより非加入ユーザへサービスを提供するための方法。
【請求項２】
前記非加入ユーザ装置は、第１のネットワークの加入者であり、前記加入ユーザ装置は、前記第１のネットワークと異なる第２のネットワークの加入者である、請求項１に記載の方法。
【請求項３】
前記サービスリクエストは、前記サービスと関連付けられたパブリックサービス識別子（ＰＳＩ）を含むリクエスト−ＵＲＩ情報要素を含有するＳＩＰインバイトメッセージである、請求項１に記載の方法。
【請求項４】
前記加入ユーザ装置の前記識別子は、ＳＩＰインバイトメッセージ中の被参照ヘッダから抽出される、請求項１に記載の方法。
【請求項５】
前記サービスは、インターネットプロトコルテレビジョン（ＩＰＴＶ）であり、前記サービスは、ＩＰマルチメディアサブシステム（ＩＭＳ）を介して提供される、請求項１に記載の方法。
【請求項６】
サーバにより提供されるサービスに加入していない非加入ユーザ装置から、当該サービスの識別子と当該サービスに加入している加入ユーザ装置の識別子とを含む当該サービスついてのサービスリクエストを受信するためのインタフェースと、
前記サービスリクエストと関連する情報を記憶するためのメモリデバイスと、
前記サービスリクエストから、前記加入ユーザ装置の前記識別子を抽出し、前記非加入ユーザ装置のための前記サービスへのアクセスの承認についての承認リクエストを前記加入ユーザ装置に対して送信するプロセッサーと、
を備え、
前記インタフェースは、前記加入ユーザ装置から、前記非加入ユーザ装置のための前記サービスへのアクセスを承認する承認メッセージを受信し、
前記プロセッサーは、前記サービスの前記非加入ユーザ装置への提供を承認する、
通信ノード。
【請求項７】
前記非加入ユーザ装置は、第１のネットワークの加入者であり、前記加入ユーザ装置は、前記第１のネットワークと異なる第２のネットワークの加入者である、請求項６に記載の通信ノード。
【請求項８】
前記サービスリクエストは、前記サービスと関連付けられたパブリックサービス識別子（ＰＳＩ）を含むリクエスト−ＵＲＩ情報要素を含有するＳＩＰインバイトメッセージである、請求項６に記載の通信ノード。
【請求項９】
前記加入ユーザ装置の前記識別子は、ＳＩＰインバイトメッセージ中の被参照ヘッダから抽出される、請求項６に記載の通信ノード。
【請求項１０】
前記サービスは、インターネットプロトコルテレビジョン（ＩＰＴＶ）であり、前記サービスは、ＩＰマルチメディアサブシステム（ＩＭＳ）を介して提供される、請求項６に記載の通信ノード。
【請求項１１】
サービスに加入していない非加入ユーザ装置のグラフィカルユーザインタフェース（ＧＵＩ）上に非加入サービスを表示するステップと、
前記非加入サービスは、当該サービスに加入している加入ユーザ装置に関連付けられていることと、
前記非加入ユーザ装置の前記ＧＵＩを用いて、前記非加入サービスの選択を受け付けるステップと、
前記非加入サービスの識別子と当該サービスに加入している前記加入ユーザ装置の識別子とを含む前記非加入サービスについてのサービスリクエストを、前記非加入ユーザ装置からサーバに対して送信するステップと、
前記非加入ユーザ装置のために前記非加入サービスへのアクセスが承認されたことを示すメッセージを受信するステップと、
前記非加入ユーザ装置により、前記非加入サービスへアクセスするステップと、
を含む、前記非加入ユーザ装置からサーバにより提供される前記非加入サービスにアクセスするための方法。
【請求項１２】
前記サービスリクエストは、前記サービスと関連付けられたパブリックサービス識別子（ＰＳＩ）を含むリクエスト−ＵＲＩ情報要素を含有するＳＩＰインバイトメッセージである、請求項１１に記載の方法。
【請求項１３】
ＳＩＰインバイトメッセージ中の被参照ヘッダ内に、前記加入ユーザ装置の前記識別子が挿入される、請求項１１に記載の方法。
【請求項１４】
前記サービスは、インターネットプロトコルテレビジョン（ＩＰＴＶ）であり、前記サービスは、ＩＰマルチメディアサブシステム（ＩＭＳ）を介して提供される、請求項１１に記載の方法。
【請求項１５】
前記表示するステップは、前記ＧＵＩ上に、複数のユーザと、それらの端末ケイパビリティと、それらの関連するサービスとを表示することを含み、
前記選択を受け付けるステップは、前記非加入ユーザ装置のための前記非加入サービスとして、前記関連するサービスのうちの前記非加入ユーザ装置が対応する端末ケイパビリティを有している１つ、の選択を受け付けることを含む、
請求項１１に記載の方法。
【請求項１６】
前記ＧＵＩ上に、前記非加入ユーザ装置が対応する端末ケイパビリティを有する前記関連するサービスを強調して表示すること、をさらに含む、請求項１５に記載の方法。
【請求項１７】
ユーザ装置において、
サーバにより提供される前記ユーザ装置が加入していない非加入サービスであって当該サービスに加入している他のユーザ装置に接続されている前記非加入サービスを表示し、前記非加入サービスの選択を受け付ける、ように適合されるグラフィカルユーザインタフェース（ＧＵＩ）と、
前記非加入サービスの識別子と当該サービスに加入している前記他のユーザ装置の識別子とを含む前記非加入サービスについてのサービスリクエストをサーバに対して送信するプロセッサーと、
を備え、
前記プロセッサーは、前記ユーザ装置のために前記非加入サービスへのアクセスが承認されたことを示すメッセージを受信するように構成され、
前記ユーザ装置により、前記非加入サービスへのアクセスが行われる、
ユーザ装置。
【請求項１８】
前記サービスリクエストは、前記サービスと関連付けられたパブリックサービス識別子（ＰＳＩ）を含むリクエスト−ＵＲＩ情報要素を含有するＳＩＰインバイトメッセージである、請求項１７に記載のユーザ装置。
【請求項１９】
前記他のユーザ装置の前記識別子は、ＳＩＰインバイトメッセージ中の被参照ヘッダ内に挿入される、請求項１７に記載のユーザ装置。
【請求項２０】
前記非加入サービスは、インターネットプロトコルテレビジョン（ＩＰＴＶ）であり、ＩＰマルチメディアサブシステム（ＩＭＳ）を介して提供される、請求項１７に記載のユーザ装置。
【請求項２１】
前記ＧＵＩは、さらに複数のユーザと、それらの端末ケイパビリティと、それらの関連するサービスとを表示し、前記非加入サービスとして、前記ユーザ装置が対応する端末ケイパビリティを有している、前記関連するサービスのうちの１つの選択を受け付けるように構成される、請求項１７に記載のユーザ装置。
【請求項２２】
前記ＧＵＩは、前記ユーザ装置が対応する端末ケイパビリティを有している、前記関連するサービスを強調して表示するようにさらに構成される、請求項２１に記載のユーザ装置。
【請求項２３】
前記プロセッサーはさらに、前記他のユーザ装置の前記識別子と前記他のユーザ装置が加入している前記サービスの前記識別子とを含む、前記他のユーザ装置に関するプレゼンス情報を購読し、それに応じて前記他のユーザ装置に関する前記プレゼンス情報を受信するように構成される、請求項１８に記載のユーザ装置。
【請求項２４】
前記非加入ユーザ装置により、前記加入ユーザ装置の前記識別子と前記加入ユーザ装置が加入している前記サービスの前記識別子とを含む、前記加入ユーザ装置に関するプレゼンス情報を購読するステップと、
前記購読するステップに応じて、前記非加入ユーザ装置において、前記加入ユーザ装置に関する前記プレゼンス情報を受信するステップと、
をさらに含む、請求項１１に記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一般的に通信システムとその中のサービス改善に関する。
【背景技術】
【０００２】
技術レベルが向上するにつれて、通信オプションはより多様になってきた。例えば、通信産業においては最近３０年間で個人的な通信は、１つのダイヤル式の電話を有する家から、複数の電話と、音声及びデータに対応するケーブル及び／又は光ファイバー回線とを有する家へと発展してきた。加えて、携帯電話及びＷｉ−Ｆｉが通信に携帯要素を加えてきた。
【０００３】
ＩＰネットワークにおいて新たな異なる方法に対応することは、様々なサービスを提供するために用いられており、新たなネットワークアーキテクチャが開発及び標準化されている。ＩＰマルチメディアサブシステム（ＩＭＳ）は、エンドユーザへＩＰマルチメディアサービスを供給するために利用されるアーキテクチャのフレームワークである。ＩＭＳアーキテクチャは、全く異なるシステムについて収束（ｃｏｎｖｅｒｇｅｎｃｅ）メカニズムを提供するＩＰプロトコル（例えば、セッション初期化プロトコル（ＳＩＰ）信号）を用いる、サービスに依存しないトポロジーに発展してきた。１つには、これは、アクセスネットワークをサービスレイヤから分離する水平制御レイヤの規定を用いて達成される。とりわけ、ＩＭＳアーキテクチャは、ＩＰＴＶシステム及びサービスの展開のための有用なプラットフォームを提供することができる。
【０００４】
３ＧＰＰ標準化団体によると、ＩＭＳネットワーク中で展開されるマルチメディアサービスは、そのネットワークに加入しているＩＭＳユーザにより使用されることができる。例えば、パブリックサービス識別子（ＰＳＩ）言い換えればＳＩＰ統一リソース識別子（ＵＲＩ）の１種は、ＩＭＳユーザが自身のＩＭＳネットワーク中のサービスを見つけ出すことを可能にする。ＰＳＩは、予め端末に設定されたものもあれば、ＩＭＳネットワーク中のプロビジョニングノードからダウンロードされたものものある。
【０００５】
ＩＭＳユーザにいつ例えば彼らの友達が彼らのＩＭＳネットワーク又は他のＩＭＳネットワークにおいてオンラインであるかを知らせるプレゼンス情報もまたＩＭＳネットワークにおいて利用できる。そのようなプレゼンス情報は、例えばオープンモバイルアライアンス（ＯＭＡ）により規定された加入／発行／通知（ＳＵＢＳＣＲＩＢＥ／ＰＵＢＬＩＳＨ／ＮＯＴＩＦＹ）メカニズムを用いて２人のユーザ間で交換される。このプレゼンス情報は、とりわけ、例えばＵＥのショートメッセージサービス（ＳＭＳ）のメッセージングハンドラー、マルチメディアメッセージサービス（ＭＭＳ）のメッセージングハンドラー、インスタントメッセージ（ＩＭ）のグループメッセージングハンドラー（１対多）、及びＩＭマルチチャットハンドラーについての情報を含む、ユーザの端末又は機器（ＵＥ）におけるサービスケイパビリティ（ＳＣ）を含む。例えば、一般的に図１に示されるように、第１のユーザ又はユーザ機器１０は、サービスケイパビリティ（SC1−SC3)に関する情報を第2のユーザ又はユーザ装置１２とプレゼンス信号を用いて、自身のIMSネットワーク１４及び第2のユーザのIMSネットワーク１６を介してシェアすることができる。
【発明の概要】
【発明が解決しようとする課題】
【０００６】
しかしながら、このプレゼンス情報は、ネットワークサービスインジケイションを提供しないことについてのみ絶望的（ｔｅｒｍｉｎａｌ）である。例えば、ＵＥ１０がＭＭＳ機能を有するけれども、そのユーザの事業者ネットワーク１４中でマルチメディアメッセージサービスセンター（ＭＭＳＣ）がない場合を考えてみよう。このケースにおいて、他のユーザ１２は、ＵＥ１０がＭＭＳ機能を有していることはわかるが、ユーザのＩＭＳネットワーク事業者がＭＭＳサービスを提供しているか否かはわからないだろう。
【課題を解決するための手段】
【０００７】
これらの例となる実施形態に従ったシステム、方法、装置、及びソフトウェアは、ＩＭＳユーザ間でサービスをシェアするための技術を提供する。例えば同じ又は他の事業者により提供される非加入サービスは、リクエスト及びそのサービスの現存する加入者との承認の照合の元にアクセスされることが可能である。
【０００８】
１つの例となる実施形態に従えば、非加入ユーザにサービスを提供するための方法は、非加入ユーザ装置からサービスについてのサービスリクエストを受信するステップと、サービスリクエストから上記サービスの加入ユーザ装置の識別子を抽出するステップと、上記加入ユーザ装置に対して承認リクエストを送信するステップと、上記加入ユーザ装置から承認メッセージを受信するステップと、上記サービスの上記費加入ユーザ装置への提供を承認するステップと、を含む。
【０００９】
他の一例となる実施形態に従えば、通信ノードは、サービスについてのサービスリクエストを受信するためのインタフェースと、上記サービスリクエストと関連する情報を格納するためのメモリデバイスと、上記サービスリクエストから上記サービスの加入ユーザ装置の識別子を抽出し、上記加入ユーザ装置に対して承認リクエストを送信するよう構成されたプロセッサと、を有し、上記インタフェースが上記加入ユーザ装置から承認メッセージを受信した後、上記プロセッサは、上記サービスの上記非加入ユーザ装置への提供を承認する。
【００１０】
まだ他の一例としての実施形態に従えば、ユーザ装置から非加入サービスにアクセスするための方法は、非加入サービスを選択するステップと、上記費加入サービスについてのサービスリクエストをサーバに対して送信するステップとを含み、上記サービスリクエストは、上記非加入サービスの加入者の識別子を含む。
【００１１】
他の一例としての実施形態に従えば、ユーザ装置は、非加入サービスを選択するためのユーザインタフェースと、上記非加入サービスについてのサービスリクエストをサーバに対して送信するよう構成されたプロセッサとを有し、上記サービスリクエストは、上記非加入サービスの加入者の識別子を含む。
【図面の簡単な説明】
【００１２】
添付の図面は、代表的な実施形態を描く。
【図１】図１は、従来の端末ケイパビリティ交換を描く。
【図２】図２は、異なる事業者ドメインに関連づけられた一例としての実施形態にかかるユーザ機器間における端末ケイパビリティ及びサービスケイパビリティの交換を描く。
【図３】図３は、一例としての実施形態に係る端末ケイパビリティ及びサービスケイパビリティの受信及び表示方法を描くフローチャートである。
【図４】図４は、一例としての実施形態に係るユーザインタフェースを示す。
【図５】図５は、一例としての実施形態に係る、非加入サービスをリクエストするための方法を描くフローチャートである。
【図６】図６は、一例としての実施形態に係る、非加入サービスのリクエスト及び承認と関連するシグナリング図である。
【図７】図７は、一例としての実施形態に係る通信ノードを示す。
【図８】図８は、一例としての実施形態に係る、非加入ユーザにサービスを提供するための方法を描くフローチャートである。
【図９】図９は、一例としての実施形態に係る、非加入サービスにアクセスするための方法を描くフローチャートである。
【発明を実施するための形態】
【００１３】
続く一例としての実施形態の詳細な記述は、添付の図面を参照する。異なる図面中の同じ参照番号は、同じ又は類似の要素を識別する。また、続く詳細な記述は本発明を限定しない。代わりに、本発明の範囲は添付の請求項により定義される。
【００１４】
上述の通り、ＩＭＳシステムは、加入者に１つのＩＭＳネットワークから他のＩＭＳネットワークにおいて加入者に提供されているサービスを確認又はアクセスするメカニズムを現在提供していない。しかしながら、様々な理由のために、例えば、他のネットワークにおいて同じサービスが実装される前に、加入者が、１つのＩＭＳネットワークにおいて展開される新しいマルチメディアサービスをプレビューすることができるようにするために、一例としての実施形態に従って、他のＩＭＳネットワークにおけるサービスを加入者に知らせ、及び／又はユーザが他のＩＭＳネットワークにおいて提供されるサービスにアクセスできるようにすることは望ましい。さらに、ネットワーク中のユーザが、彼又は彼女のネットワークにおいて利用可能であるけれども、彼又は彼女がまだ加入していないサービスを試す、又はプレビューするようにすることは有用である。例えば図２に描かれる一例としての実施形態に係る通信システムを考えよう。
【００１５】
そのとき、第１のユーザAの端末又はＵＥ２０は、自身の端末ケイパビリティ（ＳＣ１，ＳＣ２，ＳＣ３，等）及び自身の加入サービス（Ｓ１−ＯＰ−Ａ，Ｓ２−ＯＰ−Ａ，Ｓ３−ＯＰ−Ａ，等）の両方に関する情報を第２のユーザＢの端末又はＵＥ２２に提供する。この情報は、図２中においてＳ１−ＯＰ−ＡのようなサービスＩＤをユーザの他のプレゼンス情報と共にネットワーク中において発行することによって、例えば１人のユーザの友達や仲間に提供され得る。例えば、ＳＵＢＳＣＲＩＢＥ／ＰＵＢＬＩＳＨ／ＮＯＴＩＦＹメカニズム（より詳細は下記に記述される）を用いることによって、事業者Ａと関連するネットワーク２４中において展開されるサービスについてのサービスＩＤは、事業者Ｂにより運営されるネットワーク２６中の加入者である他のユーザ２２により受信される。一例としての実施形態によれば、他の事業者のドメイン中（すなわち図２の例の事業者Ｂ）のユーザ２２が、事業者Ａにより提供されるサービスを使いたいとき、事業者Ａと関連するネットワーク２４中の所望のサービスに加入する加入者２０は、ユーザ２２がこのサービスにアクセスすることを許可する承認のためにコンタクトされる。承認が受信された時点で、事業者Ｂと関連するネットワーク２６中のユーザ２２は、事業者Ａにより提供されるサービスにアクセスし、使用することができる。異なる事業者ドメイン（またここでフォーリンサービス（ｆｏｒｅｉｇｎ  ｓｅｒｖｉｃｅｓ）と呼ばれる）に渡ってＩＭＳユーザ間でサービスを例えば、フォーリンサービス発行、フォーリンサービスの選択のためのユーザインタフェース、及びフォーリンサービスリクエストを含む異なるレベルでシェアするためのケイパビリティの提供と関連する、一例としての様々な実施形態が今記述されるだろう。しかしながら、これらの一例としての実施形態に係るサービスシェアリングは、また１つのネットワーク又は事業者ドメイン中においても実行することができることは望ましく、またより詳細に以下で記述される。
【００１６】
図３中に示されるフロー図は、一例としての実施形態に係り、１人のリモートユーザ（例えばユーザＢ２２）と関連するサービス及びサービスケイパビリティが、受信されたリモートユーザ２２のプレゼンス情報からどのようにして取り出されるかを描いている。ステップ３０からはじめると、ユーザＡ及び／又はＵＥ２０（以下、まとめて及び個々にＵＥ２０と称される）は、ユーザＢ及び／又はＵＥ２２（以下、まとめて及び個々にＵＥ２２と称される。）と関連するプレゼンス情報をＳＵＢＳＣＲＩＢＥ／ＰＵＢＬＩＳＨ／ＮＯＴＩＦＹメカニズムを用いて受信する。例えば、ＵＥ２２は、加入するサービスの識別子を発行するために、この標準で規定された他のプレゼンス情報に従って、プレゼンス手順（図３中にて不図示）を実行することができる。プレゼンス手順は、新たなネットワークサービス情報の追加と共にではあるが、例えばオープンモバイルアライアンス（ＯＭＡ）により公表された標準により規定されるように実行されてよい。より具体的には、ＯＭＡプレゼンスメッセージのＸＭＬフォーマットは、例えばＵＥ２２が加入するそれぞれのサービスについての下記の情報サービス識別子、要求されるサービスケイパビリティ、サービスアドレス、及びサービスアイコンを含むように変更することができる。ＳＵＢＳＣＲＩＢＥ／ＰＵＢＬＩＳＨ／ＮＯＴＩＦＹメカニズムの一般的な詳細については、関心のある読者は、発行された３ＧＰＰ標準仕様３ＧＰＰ  ＴＳ  ２４．１４１  Ｖ８．１．０（２００８−０６）を対象とする。この開示は、ここで参照されることにより包含される。
【００１７】
図３に戻ると、ＵＥ２０はＵＥ２２が加入するサービスをその事業者／ネットワーク２６から取り出す（ステップ３２）。このサービスは、ＵＥ２０の事業者／ネットワーク２４により提供されているものとは異なるかもしれない。ＵＥ２０は、自身のサービスケイパビリティを集める。例えば関連付けられた識別子がメモリ内に記憶されているかもしれない。そして、ＵＥ２０は、ステップ３４において加入するサービスをその事業者／ネットワーク２４から取り出す。この点においてＵＥ２０は、例えば様々なケイパビリティと、図４において描かれるユーザインタフェース５０を用いてステップ３６において明らかとなるサービスとを調べて表示する。
【００１８】
そのとき、"Ｃｏｎｔａｃｔｓ"ユーザインタフェース５０が描かれる。このユーザインタフェースは、ＵＥ２０上で例えば液晶又は他のタイプの発光（ｉｌｌｕｍｉｎａｔｅｄ）ディスプレイ上で表示され得る。当然のことながら、ユーザインタフェース５０は、全ての点において一例であり、これらの一例としての実施形態に従ってフォーリンサービスオプションに関する情報をユーザに提供する方法により様々なメカニズムが代わりに提供されてもよい。しかしながら、この一例としての実施形態において、事業者／ネットワーク２４によりＵＥ２０に提供され、ＵＥ２０が加入するサービスは、ユーザインタフェース５０の下部の行５２に表示されていることは特筆すべきだろう。この純粋に説明のための例において、２つのアイコン、例えばＵＥ２０が加入するチャットサービスと関連づけられた１つのアイコン５４と、ＵＥ２０が加入するロケーションベースドサービスと関連づけられた他のアイコン５６が行５２中に描かれる。
【００１９】
また、例えばＵＥ２０の友達または仲間と関連づけられたそれぞれのユーザは、ユーザインタフェース５０中に、彼又は彼女自身の表示されたコンタクト情報の行を有してもよい。とりわけ、それぞれの友達のコンタクト情報の行は、例えば、彼らのＵＥと関連づけられたサービス（例えば、彼らのネットワークにより提供されるサービス及び／又は彼らが加入するサービス）、及び彼らのＵＥと関連づけられたサービスケイパビリティを含んでもよい。これらの、例えば友達又は仲間が加入しているサービスであり、しかしＵＥ２０が加入していないサービスは、ここで"非加入"（ｕｎｓｕｂｓｃｒｉｂｅｄ）サービスと呼ばれる。この例において、ＵＥ２０の友達"Ａｌｉｃｅ"のために情報の行５８はユーザインタフェース５０上に提供される。ユーザインタフェースは、ＵＥ２０のユーザにＡｌｉｃｅを介して利用可能な非加入サービス、例えばカンファレンスサービス及びファイル転送サービス、を示すアイコンの第１のグループ６０を提供する。この例におけるアイコンの第２のグループ６２は、アイコンの第１のグループの下に位置し、Ａｌｉｃｅの端末により提供されるサービスケイパビリティ（例えば、ボイス及びビデオケイパビリティ）を示す。図４中に見られる他のアイコンは、ユーザ自身を示す。例えば、Ａｌｉｃｅが空港で彼女自身の写真を撮り、彼女が写真を彼女のプレゼンス情報と共に彼女のコンタクトに表示させたいとしよう。個々のユーザを示す写真又はアイコンは時々変更され得る。
【００２０】
他のユーザから利用可能な非加入サービス及び／又はフォーリンサービス、ネットワーク及び／又は事業者、及び友達の端末装置のサービスケイパビリティを単純に表示することに加えて、ＵＥ２０及び／又はインタフェース５０はＵＥ２０のサービス及びサービスケイパビリティの間のポテンシャルシナジー、及び一例としての実施形態に係る他のＵＥのそれに関する追加的な情報を提供することができる。例えば、もしＵＥ２２（ユーザＢ）のサービスケイパビリティがＵＥ２０（ユーザＡ）に関するサービスをサポートしているとき、このサービスケイパビリティは、ユーザインタフェース５０において、ハイライトされ、又は別のやり方では強調されてよい。例えば、行５２中の対応するアイコンがハイライトされる。この見積もり及び表示ステップは、図３に戻って、決定ブロック３８からＹｅｓ方向に従ったステップ６４に示される。他の例によれば、もしＵＥ２２のサービスケイパビリティがＵＥ２０を介して利用可能なサービスの１つをサポートしていないとき、そのサービスケイパビリティはユーザインタフェースにおいて、そのようなサービスがＵＥ２０のユーザにより考慮される必要がないことを示すために、グレイアウト又は他の方法では、非強調（ｄｅ−ｅｍｐｈａｓｉｚｅｄ）されてよい（ステップ６６）。例えば、もしＵＥ２０がビデオサービスに加入していないとき、グループ６２中のビデオサービスケイパビリティアイコンはグレイアウトされてよい。
【００２１】
ステップ６８において、ＵＥ２２（ユーザＢ）のネットワーク／事業者２６により提供されるサービスは、例えばＵＥ２０により調査される。もしＵＥ２０におけるサービスケイパビリティがネットワーク／事業者により提供される（又はＵＥ２２により加入される）サービスのうちの１つをサポートすると、そのサービスは図３中のステップ７０及びステップ７２に示されるようにユーザと対応するインタフェース５０の行中でハイライトされ又は他の方法では強調されてよい。例えば、もしＵＥ２０がＵＥ２０の端末ケイパビリティに基づいて、グループ６０中のアイコンの１つにより示されるファイル転送サービスを使用することができるとき、そのアイコンは、ユーザインタフェース５０中で強調されてよい。反対に、もしＵＥ２０のサービスケイパビリティがＵＥ２２と関連するネットワーク／事業者２６により提供されるサービスのうちの１つをサポートしない場合、そのサービスを示すアイコンは、ユーザインタフェース５０において、図３中のステップ７０から"Ｎｏ"の方向に進んだステップ７４により示されるように、非強調又はむしろ削除（すなわち、表示されない）されてもよい。
【００２２】
この一例としてのユーザインタフェース５０を考えると、ユーザ／ＵＥ２０は、今フォーリンサービス即ち、他のネットワークにより提供されるサービスへのアクセスをリクエストすることができる情報と共に提供される。図５のフローチャートは、一例としての実施形態に係るそのようなサービスをリクエストするための方法を描く。そのとき、ステップ７８において、ＵＥ２０のユーザＡは、例えばその他のユーザに電話をかける又はテキストメッセージを送るために、例えばユーザインタフェース５０のコンタクトリスト中の名前のうちの１つをクリック（又は他の方法としては選択）、或いは、行５２中の加入サービスのうちの１つをクリック（又は他の方法としては選択）する。ＵＥ２０と関連するクライアントアプリケーションは、決定ブロック８０においてサービスが選択されているか否かをチェックする。もしローカルサービス、即ち、ＵＥ２０が自身のネットワーク／事業者２４を介して加入しているサービスが選択されているとき、フローは、ステップ８２から８４をスキップしてＹｅｓ方向に従う。もしユーザＡによりローカルサービスが選択されていないとき、この純粋に説明のための一例としての実施形態に従って、他のユーザ例えばユーザＢにより提供されるサービスが、ステップ８２における、この一例としての実施形態に従ってＵＥ２０上に選択のために表示されてよい。この例において、ユーザＡは、ステップ８４においてユーザＢにより提供されるサービスのうちの１つを選択する。
【００２３】
ＵＥ２０のクライアントアプリケーションは、そして、例えばユーザＡが、ネットワーク／事業者２６を介してアクセスするだろうフォーリンサービスについての１又は複数の受信者を選択するコンタクトリストウィンドウを表示する（ステップ８６）ことができる。全ての受信者が選択された後、ＵＥ２０のクライアントアプリケーションは、ステップ８８において、ＰＳＩ（Ｐｕｂｌｉｃ  Ｓｅｒｖｉｃｅ  Ｉｄｅｎｔｉｔｙ）のようなサービスアドレスを含むサービス識別子を取り出すことができる。もし例えばユーザＢにより提供されるフォーリンサービスが、ＵＥ２０によりリクエストされると、フローは、決定ブロック９０から"Ｎｏ"の枝に従い、そしてユーザＢの識別子は、ステップ９２において、この一例としての実施形態に従った外部に向かう（ｏｕｔｇｏｉｎｇ）サービスリクエストに挿入される。ユーザＢの識別子は、ネットワーク／事業者２６によって、非加入者（ユーザＡ、ＵＥ２０）がリクエストされたサービスにアクセスするための承認を得るために用いられる。ユーザＢの識別子をサービスリクエストに挿入するためのメカニズムの一例は、ＳＩＰリクエストメッセージ中の"被参照（Ｒｅｆｅｒｒｅｄ−ｂｙ）"ヘッダを用いることがである。サービスリクエストに挿入されるユーザＢの識別子は、例えば、ＳＩＰ  ＵＲＩ又はＭＳＩＳＤＮ、例えばａｌｉｃｅ＠ｏｐｅｒａｔｏｒＢ．ｃｏｍ、又は５１４−３４５７９００の形態を取ることができる。しかし当然ながら、この情報又は同様のものは、加入ユーザ装置の識別子を運ぶために用いられる、如何なる他の新たな、又は既存のヘッダに挿入されてもよい。
【００２４】
もし、一方、ＵＥ２０において選択されるサービスがローカルサービスであるとき、すなわち、この例においてネットワーク／事業者２４により提供されるものである場合、フローは、ブロック９０から"Ｙｅｓ"方向に従い、余分な（すなわち、フォーリンサービスにアクセスする他のユーザと関連づけられた）ユーザ識別子がサービスリクエストに挿入される必要はない。ステップ９４において、サービスリクエストは、例えばリクエスト−ＵＲＩ中のＰＳＩを用いてサービス（例えばサーバ）に向けて送信される。ＵＥ２０のクライアントアプリケーションは、そしてこの一例としての実施形態におけるステップ９６の通常のＳＩＰシグナリングフローに従ったサービスリクエストに対するレスポンスを待機する。
【００２５】
フォーリンサービス即ち、ＵＥ２０が加入者でない他のネットワークからのサービスのために、ＵＥ２０によりサービスリクエストが送信されると、サービスリクエストは、処理され、もし承認されると、リクエストされたサービスがＵＥ２０及び／又はリクエストされたサービスの受信者に供給される。図６は、フォーリンサービスリクエストと関連するシグナリングと一例としての実施形態に係る、それに続く処理を描く。そこで、サービスリクエスト信号６００、例えばＵＥ２２を識別する情報要素と、リクエストされたサービス及び／又は関連するサーバの識別子を含むＳＩＰインバイトメッセージが、ＵＥ２０から事業者／ネットワーク２６に向けて送信される。より具体的には、この一例としての実施形態に従って、ＳＩＰインバイトメッセージ６００中のリクエスト−ＵＲＩ情報要素がリクエストされたサービスのＰＳＩ、例えばＳ１−ＯＰ−Ｂ＠ｏｐｅｒａｔｏｒＢ．ｃｏｍにセットされ、ユーザＢと関連するＳＩＰ  ＵＲＩが"被参照"ヘッダに配置される。
【００２６】
ネットワーク２４を通過した後、サービスリクエスト信号６００中において識別されるサービス又はサーバ、例えばこの例におけるＳ１−ＯＰ−Ｂは、サービスリクエスト信号６００を受信し、処理する。要求側（ｐａｒｔｙ）、即ちＵＥ２０が加入者でないことを認識した時点で、サービス及び／又はサーバＳ１−ＯＰ−Ｂは、ユーザＢ及び／又はＵＥ２２がユーザＡ／ＵＥ２０のこのサービスへアクセスするためのリクエストを認証又は承認するために、承認メッセージ６０２（例えばＳＩＰインバイト又はＳＩＰメッセージ）のためのリクエストを送信する。様々なメカニズムが、ユーザＢ及び／又はＵＥ２２によりこの承認を提供するか否かを決定するために用いられるだろう。例えば、ＵＥ２２上のユーザインタフェース（図示せず）は、ユーザＢに例えばボタン押下を介して、ユーザＡ及び／又はＵＥ２０がリクエストされたサービスへのアクセスを許可すべきかどうかを示すポップアップメッセージを表示することができる。或いは、ＵＥ２２は、自動的に特定の他のユーザ又はＵＥが特定のサービスにアクセスすることを認証するようにユーザＢにより予めプログラムされてもよい。そのようなケースにおいて、ＵＥ２２は、メッセージ６０２により識別される特定のユーザ／ＵＥがリクエストされたサービスへのアクセスを予め承認されているか否かをチェックすることができる。承認を提供するための特定のメカニズムに関わらず、シグナル６０４は、ＵＥ２２からサーバＳ１−ＯＰ−Ｂに返される。この例において、ＳＩＰ２００ＯＫメッセージは、リクエストが承認されたことを示す。
【００２７】
ユーザＢ及び／又はＵＥ２２から承認を得た後、サービスサーバＳ１−ＯＰ−Ｂは、ユーザＡ／ＵＥ２０に、ユーザＢが彼、彼女、又はそれがリクエストされたサービスを使うことを認証したことを示す成功応答６０６を送信する。この例において、ユーザＡが他のユーザ、例えばユーザＣ及びユーザＤをリクエストされたサービスの受信者として参加させたい場合を考えてみよう。ユーザＡ／ＵＥ２０はそこで例えばＳＩＰ加入リクエスト６０８をサービスのステータスを得るサービスに向けて送信する。事業者Ｂのネットワーク２６中のサービス／サーバＳ１−ＯＰ−Ｂは、例えば、ユーザＡにより送信された最初のＳＩＰインバイトリクエスト６００中の受信者リストに基づいてユーザＣ及びユーザＤに招待６１０，６１２を送信する。当然ながら、ユーザＣ及び／又はＤは、事業者Ｂ又は事業者Ａの加入者であってよいし、加入者でなくてもよい。ユーザＣ又はユーザＤからの応答６１４、６１６がそれぞれ受信されたとき、サービスは、ユーザＡ／ＵＥ２０にサービスのステータスに関するアップデートとして通知６１８，６２０を送信する。図６中に示される例としてのシグナリングフローが成功する後に、ユーザＡ、ユーザＣ、及びユーザＤ間のメディアプレーン接続が確立される。メディアコンテンツは、そして全てのサービス受信者（図６中で不図示）間で交換されるだろう。
【００２８】
上述の一例としての実施形態は、とりわけ例えばＩＭＳシステムのエンドユーザがより自由にサービスをシェアすることを可能にする。ＩＭＳユーザは、彼らの事業者のサービスに限定されず、他の事業者から利用可能なサービスにアクセスすることをまた制御するだろう。新たなマルチメディアサービスを開発する事業者にとって、これらの一例としての実施形態は、このネットワークへの追加のトラフィックを引き起こすためのメカニズムを提供する。また、そのような事業者は、より多数のエンドユーザと共にそのような新たなアプリケーションのテストをする機会を持つだろう。そのような新たなマルチメディアサービスをまだ開発していない事業者にとっては、これらの一例としての実施形態は、他の事業者により開発されたサービスに対するマーケットのリアクションをテストすることのできる方法を提供する。将来的な成長が確認されるとき、事業者は、類似のサービスを、例えば自身の加入者ベースに適合したアップデートと共に、開発することができる。
【００２９】
上述の一例としての実施形態は、とりわけ、非加入者に対するサービスの識別、リクエスト、承認、引渡しを提供する。例えばＵＥ２０、サービスサーバＳ１−ＯＰ−Ｂ、又は上述のシステム中の他のノードに実装して用いることができる、一例としての通信ノードアーキテクチャ７００は、図７について記述されるだろう。ここで、ノード７００は、プロセッサ７０２（又はマルチプルプロセッサコア）、メモリ７０４、１又は複数のセカンダリストレージデバイス７０６、ノード７００とネットワークの残りの装置及び場合によってはディスプレイ７１０との間の通信を取り持つインタフェース部７０８を有することができる。場合によっては、例えば、ノード７００が無線ＵＥとして動作しているとき、インタフェース部７１０は、無線インタフェース上で他のネットワークノードと通信するための送受信機要素を含んでもよい。さらに、ＵＥノード７００は、非加入サービスが選択され得る方法によりユーザインタフェースを表示するためのディスプレイ７１０を含んでもよい。このケースにおいて、プロセッサ７０２は、選択された非加入サービスのためのサービスリクエストを、例えば選択された非加入サービスを提供するサーバに対して送信するだろう。他のケース、例えばノード７００がリクエストされたフォーリンサービスと関連するサーバとして動作しているとき、インタフェース部７１０は、サービスのためのサービスリクエストを受信し、メモリデバイス７０４及び／又はセカンダリストレージデバイス７０６は、シグナル６００からサービスリクエストと関連づけられた情報を記憶するよう動作し、プロセッサは、サービスリクエストから加入ユーザ装置の識別子を抽出し、それに続く承認信号をＵＥに対して送信するだろう。
【００３０】
一例としての実施形態に係る上述の一例としてのシステムを利用して、非加入ユーザにサービスを提供するための方法が図８のフローチャート中に示される。ここで、ステップ８００において、サービスのためのサービスリクエストが非加入ユーザ装置から、そのサービスを提供するサーバにおいて受信される。そのサービスの加入ユーザ装置の識別子が、ステップ８０２においてサービスリクエストから抽出される。そして、承認リクエストが加入ユーザ装置に対してステップ８０４において送信される。承認メッセージが加入ユーザ装置から受信され（ステップ８０６）、そしてサービスは、ステップ８０８において、非加入ユーザ装置への提供について承認されるだろう。
【００３１】
他の一例としての実施形態に係る、ユーザ装置から非加入サービスにアクセスするための方法が図９のフローチャート中に示される。ここで、ステップ９００において、図３及び図４と共に上述されたように、非加入サービスが選択される。その非加入サービスについてのサービスリクエストがステップ９０２においてその非加入サービスを提供するサーバに対して送信され、サービスリクエストは、非加入サービスの加入者の識別子を含む。
【００３２】
当業者にとっては当然ながら、図８及び図９中に描かれるような方法は、全てを、又は一部をソフトウェアで実装されてもよい。かくして、本発明の一実施形態に係るデータ処理のためのシステム及び方法は、メモリデバイス中に格納される命令シーケンスを実行する１又は複数のプロセッサにより実行されてもよい。そのような命令は、固定、リムーバブルな、又はリモート（ネットワークストレージ）メディアであるセカンダリデータストレージデバイス７０６のような、コンピュータが読取り可能な他のメディアからメモリデバイス７０４に読み込まれてもよい。メモリデバイス中に格納される命令のシーケンスの実行は、プロセッサに例えば上述の動作をさせる。代わりの実施形態においては、配線回路が、一例としての実施形態を実装するために、ソフトウェア命令の代わりに、又はソフトウェア命令との組合せで用いられてもよい。
【００３３】
上述の一例としての実施形態は、フォーリンサービスの提供（例えば、あるネットワーク又は事業者ドメインから多のネットワーク又は事業者ドメインと接続するユーザへの非加入サービスの提供）との関連で記述されたけれども、当然ながら本発明はそれに限定されない。例えば、第１のユーザは、第２のユーザからの承認の元に、彼又は彼女がまだ加入していないサービスにアクセスしてもよい。ここで両方のユーザは同じネットワーク又は事業者ドメインに位置している。かくして、非加入のフォーリンサービスへのアクセス（例えばユーザインタフェースを介したそれらのディスプレイ、非加入ユーザによるそれらの選択、及び関連するシグナリング）と関連して上述された全ての技術は、ユーザ自身のネットワーク又は事業者ドメイン中で利用可能な非加入サービスについても同様の方法で応用されてよい。
【００３４】
上述の一例としての実施形態は、全ての点において本発明のむしろ限定的な説明のためのものである。全てのそのような変形及び改良は、続く特許請求の範囲により定義されるように、本発明の範囲及び精神内と見なされる。本命最初の記述において用いられる要素、動作、又は命令は、明確にそのように記述されているかに関わらず、本発明にとって重大又は本質的要素であると解釈されるべきでない。また、ここで用いられるように、冠詞"ａ"は、１又は複数のアイテムを含むことを意図する。
【図１】
0005411275.tif 000002
【図２】
0005411275.tif 000003
【図３】
0005411275.tif 000004
【図４】
0005411275.tif 000005
【図５】
0005411275.tif 000006
【図６】
0005411275.tif 000007
【図７】
0005411275.tif 000008
【図８】
0005411275.tif 000009
【図９】
0005411275.tif 000010