JP2012520006A - 第２のローカルネットワーク内のサーバからローカルネットワーク内のレンダラへのメディア転送 - Google Patents

Abstract

第１のローカルネットワーク（３００）に存在する第１の装置（３００ｃ、ｄ）において第２のローカルネットワーク（３０２）内のメディアサーバ（３０２ｂ）から第１のローカルネットワーク内のメディアレンダラ（３００ｂ）へのメディアの転送を可能にする方法及び構成。第１の装置と第２のローカルネットワーク内のゲートウェイ（３０２ａ、ｃ）との間に接続が確立され（３：１）且つ第１の装置はゲートウェイでメディアサーバに関してポートマッピングを作成する（３：３）。次に、第１の装置は、作成されたポートマッピング及びメディアサーバに記憶されたメディアコンテンツに対する参照から構成されるＵＲＬを作成し（３：４）且つ作成されたＵＲＬをメディアレンダラヘ送出する（３：５）。これにより、メディアレンダラはそのＵＲＬを使用してメディアサーバからメディアコンテンツをプルできる。

Description

本発明は、リモート制御装置による制御に従って２つのローカルネットワークにある装置の間のメディアの転送を可能にする方法及び構成に関する。

プライベートネットワーク又はホームネットワーク、ＬＡＮ（ローカルエリアネットワーク）、レジデンシャルネットワーク又はオフィスネットワークとも呼ばれる内部アドレス指定転送手段を使用する限定型ローカルネットワーク内の装置が関与するマルチメディア通信の技術の開発が進められている。本明細書において使用される場合の「ローカルネットワーク」はそのようなあらゆるネットワークを表し且つ「装置」はローカルネットワークにおいてメディア通信を実行可能なあらゆるエンティティを表す。ローカルネットワーク内の装置は、固定電話及び無線電話、コンピュータ、メディアプレイヤー又はメディア「レンダラ」、メディアサーバ及びテレビジョンボックス（「ＳＴＢ（セットトップボックス）」とも呼ばれる）などのあらゆる種類のエンティティを含んでもよい。

ローカルネットワーク内の装置はそれぞれ異なるアクセス技術、異なるオペレーティングシステム、異なるプログラミング言語、異なるフォーマット規格及び異なる通信プロトコルを使用する場合があるが、ＵＰｎＰ（ユニバーサルプラグアンドプレイ）は、そのような異なる装置の間で通信のための標準化装置プロトコルを確立する技術である。更に、ＤＬＮＡ（デジタルリビングネットワークアライアンス）は、ローカルネットワークの装置においてデジタルメディアコンテンツを収集し、記憶し且つアクセスする技術である。ＵＰｎＰプロトコルは、ローカルネットワーク内のＤＬＮＡ化装置の間で通信を実行するための基礎プロトコルとしてＤＬＮＡにより利用される。そのようなＤＬＮＡ装置は、ローカルネットワーク内におけるメディア転送の基本転送機構としてＨＴＴＰ（ハイパーテキスト転送プロトコル）を一般に使用可能である。更に、ローカルネットワークにおけるメディア転送のためにＲＴＰ（リアルタイムプロトコル）も使用可能である。

ＵＰｎＰは、装置がローカルネットワークに参加し、ローカルＩＰアドレスを取得し、その装置の装置名及びＩＰアドレスを告知し且つそのネットワークの他の装置との間で能力及びサービスをやり取りすることが可能になる「発見」と呼ばれる処理をサポートする。本明細書において、メディアの転送、通信、符号化／復号化、記憶及び再生のために装置にインストールされるあらゆる機能及びプロトコルをまとめて「能力」と呼ぶ。

マルチメディアサービス及びマルチメディアセッションを処理制御するためのプラットフォームとして、第３世代パートナーシッププロジェクト（３ＧＰＰ）によりＩＭＳ（ＩＰマルチメディアサブシステム）と呼ばれるネットワークアーキテクチャが開発された。限定型ローカルネットワークの装置に対してＩＭＳ利用サービスを提供し且つローカルネットワーク外のエンティティとの間のマルチメディア通信を可能にするように、外部エンティティとの間のセッションを確立するためにＩＭＳネットワークを使用する解決策として、「ＨＩＧＡ（ホームＩＭＳゲートウェイ）」と呼ばれるゲートウェイが提案された。

ＵＰｎＰは、ローカルネットワーク外に配置されたリモートＵＰｎＰ装置とローカルネットワーク内に配置されたＵＰｎＰ装置との通信を可能にするリモートアクセスアーキテクチャ ＲＡＡを更に定義する。更に詳細には、ＲＡＡは、リモートアクセスサーバＲＡＳを有するエンティティとリモートアクセスクライアントＲＡＣを有するエンティティとの間のリモートアクセス接続を可能にするために必要とされるパラメータを規定し且つ構成する方法を指定する。これは一般にＵＰｎＰ ＲＡ手順とも呼ばれる。

図１は、ＵＰｎＰ ＲＡ手順に従ってローカルネットワーク（図示せず）内のローカル装置に対するリモートアクセスを可能にするためのリモート装置１００及びローカルネットワークのローカルゲートウェイ１０２の各々における典型的な論理構造を示す。ローカルゲートウェイ１０２はＲＧＷ（レジデンシャルゲートウェイ）及び／又はＨＩＧＡであってもよい。リモート装置１００においてリモートアクセスクライアント「ＲＡＣ」１００ａが構成され且つローカルゲートウェイ１０２において対応するリモートアクセスサーバ「ＲＡＳ」１０２ａが構成されている。ＲＡＣ１００ａ及びＲＡＳ１０２ａは互いに整合するプロファイルで構成され且つ同期化されるべきであるので、この構成はＲＡＣ１００ａ及びＲＡＳ１０２ａが共にローカルネットワークに存在する場合に実現可能である。

ＲＡＣ１００ａはリモートアクセスディスカバリエージェント「ＲＡＤＡ」１００ｂを備え且つＲＡＳ１０２ａは対応するリモートアクセスディスカバリエージェント「ＲＡＤＡ」１０２ｂを備える。２つのＲＡＤＡは、２つのエンティティ１００及び１０２の間で発見メッセージ又は「ペアリング」メッセージをやり取りするように構成される。ＲＡＣ１００ａはリモートアクセス転送エージェント「ＲＡＴＡ」１００ｃを更に備え且つＲＡＳ１０２ａは対応するリモートアクセス転送エージェント「ＲＡＴＡ」１０２ｃを更に備える。２つのＲＡＴＡは、２つのエンティティ１００及び１０２の間にメディアの転送チャネルを確立するように構成される。ＲＡＴＡ１００ｃ、１０２ｃは、リモートアクセスの信号の送受信及びメディア通信のための接続先エンドポイントとして動作するという効果を有する。

更に、第１の装置がローカルネットワーク内で第２の装置から第３の装置へのメディアの転送を制御することを可能にするための方法も開発されている。この方法は「３−ボックスシナリオ」と呼ばれる場合が多い。例えば、再生容量が限定されている小型ハンドヘルド無線電話及びラップトップコンピュータと比較して大型で高画質の画面にコンテンツを表示するために、メディアレンダラとして使用される大型フラットスクリーンＴＶへビデオメディアをストリーミングすることをラップトップコンピュータ又はメディアサーバに指示するための制御装置として無線電話が使用されてもよい。

国際公開第２００８／１０８６９９号（特許文献１）は、上記の３−ボックスシナリオに従った２つのローカルネットワーク間のメディア転送のための方法を開示する。この方法によれば、第１のローカルネットワーク内の装置と第２のローカルネットワーク内の別の装置との間のセッション中に各ローカルネットワークのゲートウェイによってメディアの通信が可能になり、この通信は、第１のローカルネットワークに存在するリモート制御装置を使用してＩＭＳネットワークを介する制御メッセージの送受信によって開始される。リモート制御装置は２つのローカルネットワークのうち一方にしか存在しないが、リモート制御装置はメディア通信自体には関与しない。この方法では、リモート制御装置がＩＭＳクライアントを有し且つ有効にＩＭＳに加入していること及び少なくとも第２のローカルネットワークにＨＩＧＡがインストールされていることが必要である。

この方法の基礎を説明する。図２は、第１のローカルネットワーク２００、第２のローカルネットワーク２０２及びＩＭＳネットワーク２０４を示す。ネットワーク２００はレジデンシャルゲートウェイ２００ａを備え且つネットワーク２０２はレジデンシャルゲートウェイ２０２ａを備える。少なくとも第２のネットワーク２０２は、ＩＭＳネットワーク２０４と通信するためのＨＩＧＡ２０２ｂを更に備える。

リモート制御装置２００ｂは第１のローカルネットワーク２００を訪問している。第１のローカルネットワークはテレビ２００ｃを更に含み、第２のローカルネットワーク２０２はメディアサーバ２０２ｃを含む。リモート制御装置２００ｂのユーザは、ユーザ自身のホームネットワークであってもよい第２のネットワーク２０２内のサーバ２０２ｃにメディアコンテンツが記憶されているという知識を有する。図２に概略的に示されるように、メディアサーバ２０２ｃからテレビ２００ｃへのメディア転送を実現し且つ制御するために、ＩＭＳネットワーク２０４を介するリモート制御装置２００ｂとＨＩＧＡ２０２ｂとの間のＩＭＳ信号の送受信が必要とされる。従って、リモート制御装置は有効ＩＭＳアイデンティティを有するＩＭＳクライアントでなければならず且つＨＩＧＡ２０２ｂも同様に少なくとも第２のローカルネットワークにインストールされたＩＭＳクライアントでなければならない。そのため、上記のＩＭＳクライアントが利用可能でない限り、３−ボックスシナリオに従った２つのローカルネットワーク間のそのようなメディア転送は不可能であるという制限がある。

この従来の方法のもう１つの制約は、現在のＵＰｎＰ ＲＡ（リモートアクセス）仕様自体が異なるネットワーク間のメディア転送、例えば３−ボックスシナリオに従った遠隔地からのコンテンツのレンダリングを規定しておらず、リモート装置とローカルネットワークとの間のメディア転送のみを規定していることである。

国際公開第２００８／１０８６９９号パンフレット

本発明の目的は、以上概略的に説明した制約、課題及び問題点のうち少なくともいくつかに対処することである。本発明の別の目的は、ＩＭＳクライアント及びＩＭＳネットワークを使用する必要なく３−ボックスシナリオに従った異なるローカルネットワーク間のメディア転送を可能にすることである。添付の独立請求の範囲において定義される方法及び構成を使用することにより、これらの目的及び他の目的を達成することが可能である。

１つの態様によれば、第１の装置において第２のローカルネットワーク内のメディアサーバから第１のローカルネットワーク内のメディアレンダラへのメディアの転送を可能にする方法が提供される。この方法において、第１の装置と第２のローカルネットワーク内のゲートウェイとの間に接続が確立され、そのゲートウェイにおいて、メディアサーバに関してのポートマッピングが作成される。第１の装置は、作成されたポートマッピング及びメディアサーバに記憶されたメディアコンテンツに対する参照を備えるＵＲＬを更に作成し、次に、作成されたＵＲＬをメディアレンダラヘ送出する。これにより、メディアレンダラは、そのＵＲＬを使用してメディアサーバからメディアコンテンツをプルできる。

別の態様によれば、第１のローカルネットワークに存在し、第２のローカルネットワーク内のメディアサーバから第１のローカルネットワーク内のメディアレンダラへのメディアの転送を可能にする第１の装置における構成が提供される。この構成によれば、第１の装置は、第１の装置と第２のローカルネットワーク内のゲートウェイとの間に接続を確立する接続モジュールと、ゲートウェイにおける、メディアサーバに関するポートマッピングを作成するポートマッピングモジュールとを備える。また、第１の装置は、作成されたポートマッピング及びメディアサーバに記憶されたメディアコンテンツに対する参照を備えるＵＲＬを作成するＵＲＬモジュールと、作成されたＵＲＬをメディアレンダラへ送出する送出モジュールとを更に備える。

上記の方法及び構成は、異なる実施形態に従って構築され、実現されてもよい。一実施形態において、ＵＲＬ中のポートマッピングは、メディアサーバのローカルＩＰアドレス及びポート番号をゲートウェイの外部パブリックＩＰアドレス及びポート番号でマッピングする。メディア参照はメディアサーバのメディアファイルのファイル名及び経路を含んでもよい。確立された接続は、第１の装置のユーザによるメディアコンテンツの選択を可能にするようにメディアサーバのコンテンツを閲覧するために使用できる。また、確立された接続はＶＰＮトンネルであってもよい。

更なる可能な実施形態においては、第１の装置のリモートアクセスクライアントＲＡＣとゲートウェイのリモートアクセスサーバＲＡＳとの間に接続が確立され、これらＲＡＣ及びＲＡＳは事前にペアリング処理により対を形成している。ＲＡＣ及びＲＡＳは更にＵＰｎＰ ＲＡアーキテクチャバージョン１に準拠してもよい。更に、第１の装置はＵＰｎＰ ＡＶ手順に基づいてＵＲＬをメディアレンダラヘ送出してもよい。その場合、第１の装置は、メディアサーバからメディアコンテンツを取り出すためのＨＴＴＰ ＧＥＴメッセージに変換可能なＵＰｎＰ ＡＶＴ Ｐｌａｙコマンドをメディアレンダラへ送出可能である。

第１の装置が移動電話である場合、ＶＰＮトンネルを経てセルラネットワークを介して信号メッセージを通信可能であり、その一方で実際のメディアは固定ネットワークを介して、例えばストリーミング技術を使用してメディアサーバからメディアレンダラへ送出可能である。このように、利用可能な通信リンク及び帯域幅を高い効率で利用可能である。

この方法の更なる可能な特徴及び利点は以下の詳細な説明から明らかになる。

以下、添付の図面を参照して、例示的な実施形態によって本発明を更に詳細に説明する。

従来の技術に従ってローカルネットワーク内の装置に対してリモートアクセスを実行するように構成されたリモート装置及びローカルゲートウェイを示すブロック図である。 既知の方法に従った２つのローカルネットワークの間のメディア転送に関与する３ボックススキームの通信の概要を示す図である。 可能な実施形態に係る２つのローカルネットワークの間のメディア転送に関与する３ボックススキームの通信の概要を示す図である。 別の可能な実施形態に係る第１の装置により実行されるステップを示すフローチャートである。 更なる例示的な実施形態に係る本発明を実施可能にする方法の一実施例を示す信号フロー図である。 更なる例示的な実施形態に係る第１の装置の構成を更に詳細に示すブロック図である。

簡単に説明すると、第１の装置が第１のローカルネットワークに存在する場合に接続先である第２のローカルネットワーク内のメディアサーバのメディアコンテンツを第１のローカルネットワーク内のメディアレンダラで再生するために第１の装置のユーザがメディアサーバからのメディアコンテンツの転送を制御することを可能にする方法が提供される。従って、ユーザは、第１のネットワークを訪問する際にメディアサーバに記憶されているメディアコンテンツを遠隔地からアクセスし且つメディアコンテンツをメディアレンダラで再生すること、すなわち上記の３−ボックスシナリオに従って再生することを要求することができる。本発明は、特にＩＭＳ加入又はＩＭＳメッセージ交換をまったく必要とせずにこれを可能にする。

第１の装置は、第１のローカルネットワーク内のゲートウェイとの接続を確立し、それにより、少なくとも接続先ネットワークから見て接続先ネットワークにおける仮想の「ローカル」装置にもなる。従って、基本的に図１に示されるように第１の装置のＲＡＣとゲートウェイのＲＡＳとの間で例えばＶＰＮトンネルなどのそのような接続を取得することが可能である。この接続により、特にメディアサーバのメディアを閲覧し且つメディアサーバから所望のメディアを選択するために、ユーザは第２のネットワークのローカル装置と通信可能である。

次に、第１の装置はゲートウェイでメディアサーバに関してポートマッピングを作成し、更に、そのポートマッピング及びユーザにより選択されたメディアサーバに記憶されているメディアコンテンツに対する参照から構成されるＵＲＬを作成する。作成されたＵＲＬを第１の装置がメディアレンダラヘ送出すると、メディアレンダラは、例えばＨＴＴＰ ＧＥＴメッセージなどに含まれる形で受信されたＵＲＬを使用してメディアサーバから対応するメディアコンテンツをプルできる。

例えばゲートウェイを介してインターネットに接続されているユーザのホームネットワークの中にビデオなどのメディアコンテンツを有するメディアサーバをユーザが有している場合などにこの方法を使用できる。ユーザが移動電話を操作し、そのようなメディアコンテンツを再生するのに有用なメディアレンダラを備えた別のローカルネットワークを訪問した場合、移動電話のＲＡＣは家のゲートウェイのＲＡＳとの間で信号の送受信を実行するためのリモートアクセス接続を確立することができる。従って、これは無線インタフェース又はセルラインタフェースを介して実行され且つＵＰｎＰ ＲＡ信号送受信のためにＲＡＣとＲＡＳとの間に安全なトンネルを確立できる。

上記のような使用例の場合、訪問先ローカルネットワークのゲートウェイ装置は非リモートアクセス装置になるが、訪問先ネットワークでホームネットワークからのメディアをユーザが共有するための安全な経路を次のように提供する。ユーザの移動電話はローカルインタフェースを介して、例えばＷｉＦｉを使用して訪問先ローカルネットワークに接続する。移動電話にはいわゆる「ＡＶ ＣＰ（オーディオビデオコントロールポイント）」が更に組み込まれている。従って、移動電話のＡＶ ＣＰは双方のローカルネットワークの一部として動作可能である。ユーザの移動電話、家のメディアサーバ及び訪問先メディアレンダラは基本的に上記の３−ボックスシナリオを形成する。ＲＡＣをホームネットワークに接続することにより、ＡＶ ＣＰはその接続を介してメディアサーバのコンテンツを閲覧し且つ選択することが可能である。

ＡＶセットアップ段階において、ＡＶ ＣＰは、ＲＡＣとＲＡＳとの間のＶＰＮトンネルを介するＵＰｎＰ ＲＡ信号送受信を使用してメディアサーバから訪問先インターネットゲートウェイのパブリックＩＰアドレスへメディアストリームを送出させることができる。しかし、コンテンツは大量のデータを含むことがあるので、実際のメディアは同じトンネルを介してストリーミングされるのではなく、コンテンツのデータをストリーミングする場合、通常はコストが高く且つ限定されている移動電話の無線接続を使用せずに、ゲートウェイの固定接続を介してデータをストリーミングすることができる。前述のように、訪問先ゲートウェイの背後に存在するメディアレンダラ、すなわちＮＡＴ（ネットワークアドレス変換器）にストリームを到達させるために、関連ポートマッピングがゲートウェイで作成されなければならない。従って、訪問先メディアレンダラにおいてメディアストリームが再生される一方、移動電話のＡＶ ＣＰはメディアストリームのレンダリングを制御できる。

次に、図３を参照して、２つのローカルネットワークの間で典型的な３−ボックスシナリオに従ってこの方法を使用するための例示的な一実施例を説明する。第１のローカルネットワーク３００は「ＲＧＷ」と示されるゲートウェイ３００ａと、例えば大画面テレビなどのメディアレンダラ３００ｂとを含む。移動電話などの第１の装置３００ｃは現在第１のローカルネットワーク３００にあり、第１のローカルネットワーク３００は特にＲＡＣ３００ｄを更に含む。第１の装置３００ｃのユーザは自身の家のローカルネットワーク、すなわち図示される第２のローカルネットワーク３０２とも関連している。第２のローカルネットワーク３０２は、同様に「ＲＧＷ」と示されるゲートウェイ３０２ａと、メディアサーバ３０２ｂとを更に備える。

ゲートウェイ３０２ａはＲＡＳ３０２ｃを更に備え、第１の装置３００ｃのＲＡＣ３００ｄ及びゲートウェイ３０２ａのＲＡＳ３０２ｃは、第１の装置３００ｃが実際に第２のローカルネットワーク３０２に存在していた時点で事前に正規の発見処理又はペアリング処理により対を形成していたと仮定する。従って、第１の装置３００ｃは既にわかっており、第２のネットワーク３０２の信頼できるメンバーになっている。更に、第１の装置３００ｃは、先に図１に関して説明したように例えば正規の発見処理又はペアリング処理において訪問先ローカルネットワーク３００に既に接続していると仮定する。この処理はＳＳＤＰ（シンプルサービスディスカバリプロトコル）と呼ばれる既存のプロトコルに基づいてもよい。

図示される第１の動作３：１において、第１の装置３００ｃのＲＡＣ３００ｄとゲートウェイ３０２ａのＲＡＳ３０２ｃとの間にＲＡ接続が確立される。この接続はＶＰＮトンネル又はそれと同等の接続であるのが好ましい。従って、次に説明するように２つのネットワーク３００及び３０２の間でメディア転送を開始するために、信号の送受信及び閲覧にこの接続を使用できる。次の動作３：２において、第１の装置３００ｃのユーザはメディアサーバ３０２ｂのメディアを閲覧し且つ後に実行されるべき転送及びメディアレンダラ３００ｂにおける再生に備えてメディアサーバ３０２ｂからメディアコンテンツを選択する。基本的には、ユーザがメディアサーバのある特定のメディアコンテンツを選択した場合、第１の装置３００ｃはそのメディアコンテンツに対する適切な参照を取得し且つ保存する。この処理の後の段階の動作で実行されるメディアサーバ３０２ｂからの実際のコンテンツのアクセスのために参照を使用できる。

次の動作３：３において、第１の装置３００ｃは接続先ゲートウェイ３０２ａでメディアサーバ３０２ｂに関してポートマッピングを取得又は作成する。この動作はゲートウェイ３０２ａにおける「ピンホール作成」と呼ばれてもよい。有用な一実施例において、この動作で作成されるポートマッピングは、メディアサーバ３０２ｂのローカルＩＰアドレス及びポート番号をメディアサーバ３０２ｂと関連するゲートウェイ３０２ａの外部パブリックＩＰアドレス及びポート番号でマッピングする。このポートマッピングを参照することにより、ネットワーク３０２外のエンティティからメディアサーバ３０２ｂにアクセスできる。

続く動作３：４において、第１の装置３００ｃは図中では「ＵＲＬ^＊」と示される特定のＵＲＬを作成する。このＵＲＬは、作成されたポートマッピング及び事前に取得されていたメディアサーバ３０２ｂのメディアコンテンツに対する参照から構成される。次の動作３：５において、第１の装置３００ｃは、作成されたＵＲＬをローカルネットワーク３００内のメディアレンダラ３００ｂへ送出する。例えば、ＵＲＬはＵＰｎＰ ＡＶ手順に基づいて、例えばメッセージ「ＡＶＴ：ＳｅｔＡＶＴｒａｎｓｐｏｒｔＵＲＬ（ＵＲＬ^＊）」に含まれる形で送出されてもよい。

次の動作３：６において、メディアレンダラ３００ｂは、受信したＵＲＬによってメディアサーバからメディアコンテンツを取り出す、すなわち「プルする」ことができる。従って、ＵＲＬは、メディアサーバ３０２ｂと関連するゲートウェイ３０２ａにおけるポートマッピング及び先に選択されていた参照に従ったメディアサーバのメディアコンテンツの双方を表す。別の有用な実施例において、メディアレンダラ３００ｂは、ＵＲＬを使用してＨＴＴＰ ＧＥＴメッセージをメディアサーバ３０２ｂへ送出するのが好ましい。その場合、最終動作３：７に示されるように、メディアコンテンツはメディアサーバ３０２ｂからメディアレンダラ３００ｂへコンテンツストリームとして転送されるだろう。

このように、上述の方法を使用することにより、３−ボックスシナリオに従って２つのローカルネットワークの間でＩＭＳを使用する必要なくメディアを転送可能である。尚、メディア転送の準備段階として実行されるネットワーク３００、３０２間の信号送受信動作は当初の動作３：１で確立された接続を介して実行されるが、その結果として実行される動作３：６及び３：７に従ったメディア転送は、ゲートウェイ３００ａ及び３０２ａにより使用される通常は固定アクセス機構である外部機構によって別の接続を介して実現されることになる。従って、第１の装置が移動電話である場合、移動電話はＶＰＮトンネルを経てセルラネットワークを介して信号メッセージを通信するが、実際のメディアは固定ネットワークを介してメディアサーバからメディアレンダラへ送出される。

次に、図４のフローチャートを参照して、第２のローカルネットワーク内のメディアサーバから第１のローカルネットワーク内のメディアレンダラへのメディアの転送を可能にするために第１のローカルネットワーク内に存在する第１の装置により実行される手順を説明する。第１のステップ４００において、第１の装置は第２のローカルネットワーク内のゲートウェイとの間の接続を確立する。この動作は基本的には図３の動作３：１に相当する。遠隔地の第１の装置からメディアサーバのメディアを閲覧するためにこの接続を使用できる。次のステップ４０２において、第１の装置は第２のローカルネットワークのゲートウェイでメディアサーバに関してポートマッピングを作成する。この動作は基本的には図３の動作３：３に相当する。

次に、ステップ４０４において、第１の装置は、作成されたポートマッピング及びメディアサーバに記憶されたメディアコンテンツに対する参照から構成されるＵＲＬを作成する。この動作は基本的には図３の動作３：４に相当する。先に説明したように、確立された接続を使用して第１の装置のユーザがメディアサーバのメディアを閲覧したときに既にメディアコンテンツはユーザにより選択されているものと仮定する。最終ステップ４０６において、第１の装置は作成されたＵＲＬをメディアレンダラへ送出する。これにより、メディアレンダラは受信したＵＲＬを使用してメディアサーバからそのメディアコンテンツをプルできる。

図５の信号フロー図を参照して、本発明の方法を実際にどのようにして実現できるかを示す一実施例を説明する。本実施例に関連するノード及びエンティティは次の通りである。第１の装置５００はこの場合には移動電話であり、第１のローカルネットワーク内にある。この場合、第１のネットワークのゲートウェイ機能５０２は、このようなローカルゲートウェイ機能を表すために使用されることが多い用語である「ＩＧＤ（インターネットゲートウェイデバイス）」として示される。第１のローカルネットワークにはメディアレンダラ５０４も存在する。第２のローカルネットワーク「２」にはホームゲートウェイノード５０６及びメディアサーバ５０８がある。

移動電話５００は、先に説明した第１の装置の可能な実現形態として、基本的に先の実施例において説明した通りに動作するように構成される。更に詳細には、移動電話５００はＡＶ ＣＰ５００ａ、ＩＧＤ ＣＰ５００ｂ及びＲＡＣ５００ｃを含むように構成される。更に、ホームゲートウェイノード５０６はゲートウェイ機能ＩＧＤ’５０６ａ及びＲＡＳ５０６ｂを含むように構成される。移動電話５００及びホームゲートウェイ５０６の上記の機能は、正規のＵＰｎＰの実施仕様に従って構成されるか、又は本明細書で説明されるように本発明を実現するための新規な方法において利用可能な他の任意の同等の仕様又は類似の規格及びプロトコルに従って構成されてもよい。

次に、種々の概略的なステップ又は動作によって図５の手順を説明する。各ステップは、使用されるプロトコルに応じて双方向に転送される１つ以上の特定の機能及びメッセージを表してもよい。第１の動作５：１は、例えば移動電話５００が実際にネットワーク２に存在していたときに正規の発見処理又はペアリング処理のいずれかの時点でＲＡＣ５００ｃ及びＲＡＳ５０６ｂが対を形成していたことを示す。これは、次に続く手順の前提条件とみなされてもよい。次の動作５：２において、移動電話５００のＩＧＤ ＣＰ５００ｂは第１のネットワーク１にローカルに接続し且つ発見処理又はペアリング処理を実行する。この処理において、ＩＧＤ ＣＰ５００ｂは例えば正規のプロトコルＳＳＤＰに従ってローカルゲートウェイＩＧＤ５０２を発見する。

次の動作５：３は、例えばＵＰｎＰ ＲＡ手順に従って接続先ネットワーク２においてもＲＡＣ５００ｃとＲＡＳ５０６ｂとの間にＲＡ接続が確立されることを示す。更に、動作５：４においてＲＡＣ５００ｃとＲＡＳ５００ｂとの間で正規のＲＡ同期化メッセージがやり取りされる。これにより、接続先ネットワーク２の装置に関する知識が移動電話５００に効果的に提供される。ＲＡ同期化は図１に示されるようなＲＡＤＡエンティティの間で実行されてもよく、これは「ＲＡＤＡ同期化」と呼ばれてもよい。

概略的に示される動作５：５ａは、例えば正規のプロトコルＳＳＤＰに従ってメディアを再生するために第１のネットワーク１のメディアレンダラ５０４及びその能力を移動電話５００のＡＶ ＣＰ５００ａが発見することを示す。これに対し、概略的に示される別の動作５：５ｂは、ＡＶ ＣＰ５００ａが第２のネットワーク２のメディアサーバ５０４も発見することを示す。概略的に示される更に別の動作５：６は、動作５：４において実行された事前のＲＡ同期化によって、移動電話５００のＩＧＤ ＣＰ５００ｂがＲＡＣ５００ｃからネットワーク２のゲートウェイＩＧＤ’５０６ａを発見することを更に示す。

次に、続く動作５：７において、動作５：３で確立された接続によって、移動電話５００のユーザはメディアサーバ５０８のメディアを閲覧し且つメディアサーバ５０８からメディアコンテンツを選択する。動作５：７におけるメディアの閲覧は移動電話５００のＡＶ ＣＰ５００ａにより実行される。次に、動作５：８において、ゲートウェイＩＧＤ’５０６ａでメディアサーバ５０８に関してポートマッピングが作成される。先に示した実施例に関して基本的に説明したように、ポートマッピングは、メディアサーバ５０８のローカルＩＰアドレス及びポート番号をＩＧＤ’５０６ａの外部パブリックＩＰアドレス及びポート番号でマッピングする。概略的に示される動作５：９は、移動電話５００のＩＧＤ ＣＰ５００ｂがゲートウェイＩＧＤ’５０６ａからポートマッピングを取得することを示す。

次の動作５：１０は、移動電話５００でＵＲＬが作成されることを示す。これはＡＶ ＣＰ５００ａで実現され、ＵＲＬは、上記のポートマッピング及びメディアサーバ５０８の選択されたメディアコンテンツに対する参照から構成される。次の動作５：１１において、移動電話５００のＡＶ ＣＰ５００ａは、作成されたＵＲＬを例えばメッセージ「ＡＶＴ：ＳｅｔＡＶＴｒａｎｓｐｏｒｔＵＲＬ（ＵＲＬ^＊）」に含まれる形でメディアレンダラ５０４へ送出し、メディアサーバ５０８からプルされるべき選択されたメディアコンテンツのアドレスをメディアレンダラ５０４に効果的に報知する。

概略的に示される次の動作５：１２は、例えば「ＡＶ ＣＭ（オーディオ／ビデオコネクションマネージメント）サービス」と呼ばれる方法を使用して、実行されるべきメディア転送に備えた接続のためにＡＶ ＣＰ５００ａとメディアサーバ５０８との間の通信の準備がされることを示す。このサービスは、メディアストリームを送出するという目的のためにメディアサーバ５０８自体にネットワークへの接続の準備をさせる。更に詳細には、この動作により、メディアサーバ５０８は例えばメディアサーバの現在の状態及び／又はネットワークの現在の状態に基づいて接続を確立可能か否かを指示できる。

次の動作５：１３において、移動電話５００のＡＶ ＣＰ５００ａは、メディアレンダラ５０４へ再生コマンドを送出することにより、続く動作５：１４においてメディアサーバ５０８からのＵＲＬに含まれる参照に従ってコンテンツをプルするためにメディアレンダラ５０４をトリガする。最後に、最終動作５：１５に示されるように、メディアコンテンツをストリームの形でメディアサーバ５０８からメディアレンダラ５０４へ転送可能である。

次に、図６のブロック図を参照して第１の装置の構成を更に詳細に説明する。第１のローカルネットワーク「１」に存在する場合、第１の装置６００は、第２のローカルネットワーク「２」内のメディアサーバ６０６からローカルネットワーク１内のメディアレンダラ６０２へのメディアの転送、すなわち３−ボックスシナリオに従ったメディア転送を可能にし且つ制御するように構成される。ローカルネットワーク２はゲートウェイ６０４を更に備える。第１の装置６００は先に説明した手順及び実施形態のうちいずれかを実現するために使用されてもよい。本明細書において、第１の装置の種々の機能は「モジュール」と呼ばれるが、ユニット、ブロック、要素又は構成要素とみなされてもよい。

この構成によれば、第１の装置６００は、第１の装置とローカルネットワーク２内のゲートウェイ６０４との間に接続を確立するように構成された接続モジュール６００ａと、ゲートウェイでメディアサーバに関してポートマッピングを作成するように構成されたポートマッピングモジュール６００ｂとを備える。第１の装置６００は、作成されたポートマッピング及びメディアサーバに記憶されたメディアコンテンツに対する参照から構成されるＵＲＬを作成するように構成されたＵＲＬモジュール６００ｃと、作成されたＵＲＬをメディアレンダラ６０２へ送出するように構成された送出モジュール６００ｄとを更に備える。これにより、メディアレンダラは受信したＵＲＬを使用してメディアサーバからメディアコンテンツをプルできる。

尚、図６は論理的な意味で第１の装置の種々の機能ユニット又はモジュールを示しているに過ぎないが、当業者は実際には適切なソフトウェア手段及びハードウェア手段を使用してそれらの機能を自由に実現できる。従って、本発明は図示されている第１の装置６００の構造には限定されず、第１の装置の機能モジュール６００ａ〜６００ｄは、図３〜図５に関して先に説明した方法及び手順に従って適宜動作するように構成されてもよい。

第１の装置６００は種々のいずれかの実施形態に従って構成されてもよい。例えば、接続モジュール６００ａは、第１の装置のリモートアクセスクライアントＲＡＣとゲートウェイのリモートアクセスサーバＲＡＳとの間に接続を確立するように更に構成されてもよく、その場合、ＲＡＣ及びＲＡＳは事前にペアリング処理により対を形成している。別の例示的な実施形態において、送出モジュール６００ｄは、ＵＰｎＰ ＡＶ手順に基づいて上記のＵＲＬをメディアレンダラへ送出するように更に構成される。

送出モジュール６００ｄは、メディアサーバからメディアコンテンツを取り出すためのＨＴＴＰ ＧＥＴメッセージに変換可能なＵＰｎＰ ＡＶＴ Ｐｌａｙコマンドをメディアレンダラへ送出するように更に構成されてもよい。前述のように、第１の装置は移動電話であってもよい。

例えば先に説明した実施形態のうちのいずれかに従って本発明を使用する場合、ＩＭＳ機能又はＩＭＳ加入をまったく必要とせずに３−ボックスシナリオによって２つのローカルネットワーク間のメディア転送を実現可能である。本発明の方法において、関連するノードへの影響を最小限に抑えて、先に説明した方式でＵＰｎＰ ＡＶ仕様を使用できる。特に、第１の装置における上述のＲＡＣアプリケーション及び第２のローカルネットワークのゲートウェイにおけるＲＡＳアプリケーションがＵＰｎＰ ＲＡアーキテクチャバージョン１に準拠している場合に本発明の方法を使用できる。更に、第１の装置として移動電話が使用される場合、メディア転送の準備のための信号メッセージは、通常は帯域幅が限定されているセルラネットワークを介して通信されるが、実際のメディアは、メディアのストリーミングに通常必要とされる更に高いデータ通信速度により適する固定ネットワークを介して転送可能である。

特定の例示的な実施形態を参照して本発明を説明したが、本明細書の説明は一般に本発明の概念を例示することのみを目的とし、本発明の範囲を限定するとみなされるべきではない。例えば、本明細書を通して「装置」、「メディアサーバ」、「メディアレンダラ」、「ゲートウェイ」、「ＵＲＬ」及び「ポートマッピング」などの用語が使用されているが、本明細書において説明される機能性及び特性を有する他の任意の対応する機能、パラメータ、ノード及び／又はユニットが使用されてもよい。実施形態を説明する際にＵＰｎＰ、ＩＧＤ、ＲＡＣ及びＲＡＳの概念も使用されているが、他のあらゆる類似の又は同等の規格、プロトコル及びネットワーク要素が基本的に本明細書に説明されるように使用されてもよい。本発明は添付の請求の範囲により定義される。

Claims (20)

1. 第１のローカルネットワーク内に存在する第１の装置において第２のローカルネットワーク内のメディアサーバから前記第１のローカルネットワーク内のメディアレンダラへのメディアの転送を可能にする方法であって、
   −前記第１の装置と前記第２のローカルネットワーク内のゲートウェイとの間の接続を確立するステップと、
   −前記ゲートウェイにおいて、前記メディアサーバに関してポートマッピングを作成するステップと、
   −作成された前記ポートマッピング及び前記メディアサーバに記憶されたメディアコンテンツに対する参照を備えるＵＲＬを作成するステップと、
   −作成された前記ＵＲＬを前記メディアレンダラへ送出するステップとを有し、
   前記メディアレンダラが前記ＵＲＬを使用して前記メディアサーバから前記メディアコンテンツをプルすることを可能にする、ことを特徴とする方法。
2. 前記ＵＲＬの前記ポートマッピングは、前記メディアサーバのローカルＩＰアドレス及びポート番号を前記ゲートウェイの外部パブリックＩＰアドレス及びポート番号でマッピングすることを特徴とする請求項１に記載の方法。
3. 前記メディアへの参照は前記メディアサーバのメディアファイルのファイル名及び経路を含むことを特徴とする請求項１又は２に記載の方法。
4. 確立された前記接続は、前記第１の装置のユーザによる前記メディアコンテンツの選択を可能にするように前記メディアサーバのコンテンツを閲覧するために使用されることを特徴とする請求項１から３のいずれか１項に記載の方法。
5. 確立された前記接続はＶＰＮトンネルであることを特徴とする請求項１から４のいずれか１項に記載の方法。
6. 前記接続は前記第１の装置のリモートアクセスクライアントＲＡＣと前記ゲートウェイのリモートアクセスサーバＲＡＳとの間で確立され、前記ＲＡＣ及び前記ＲＡＳは事前にペアリング処理により対を形成していることを特徴とする請求項１から５のいずれか１項に記載の方法。
7. 前記ＲＡＣ及び前記ＲＡＳはＵＰｎＰ ＲＡアーキテクチャバージョン１に準拠することを特徴とする請求項６に記載の方法。
8. 前記第１の装置はＵＰｎＰ ＡＶ手順に基づいて前記ＵＲＬを前記メディアレンダラヘ送出することを特徴とする請求項１から７のいずれか１項に記載の方法。
9. 前記第１の装置は、前記メディアサーバから前記メディアコンテンツを取り出すためのＨＴＴＰ ＧＥＴメッセージに変換可能なＵＰｎＰ ＡＶＴ Ｐｌａｙコマンドを前記メディアレンダラへ更に送出することを特徴とする請求項８に記載の方法。
10. 前記第１の装置は移動電話であることを特徴とする請求項１から９のいずれか１項に記載の方法。
11. 前記第１の装置は前記ＶＰＮトンネルを経てセルラネットワークを介して信号メッセージを通信し、前記メディアは前記メディアサーバから固定ネットワークを介して前記メディアレンダラへ送出されることを特徴とする請求項５または１０に記載の方法。
12. 第１のローカルネットワークに存在し、第２のローカルネットワーク内のメディアサーバから前記第１のローカルネットワーク内のメディアレンダラへのメディアの転送を可能にする第１の装置の構成であって、前記第１の装置は、
    −前記第１の装置と前記第２のローカルネットワーク内のゲートウェイとの間に接続を確立する接続モジュールと、
    −前記ゲートウェイにおいて前記メディアサーバに関してポートマッピングを作成するポートマッピングモジュールと、
    −作成された前記ポートマッピング及び前記メディアサーバに記憶されたメディアコンテンツに対する参照を備えるＵＲＬを作成するＵＲＬモジュールと、
    −作成された前記ＵＲＬを前記メディアレンダラへ送出する送出モジュールと、を備え、
    前記メディアレンダラが前記ＵＲＬを使用して前記メディアサーバから前記メディアコンテンツをプルすることを可能にする、ことを特徴とする構成。
13. 前記ＵＲＬの前記ポートマッピングは、前記メディアサーバのローカルＩＰアドレス及びポート番号を前記ゲートウェイの外部パブリックＩＰアドレス及びポート番号でマッピングすることを特徴とする請求項１２に記載の構成。
14. 前記メディアの参照は前記メディアサーバのメディアファイルのファイル名及び経路を含むことを特徴とする請求項１２又は１３に記載の構成。
15. 確立された前記接続は、前記第１の装置のユーザによる前記メディアコンテンツの選択を可能にするように前記メディアサーバのコンテンツを閲覧するために使用できることを特徴とする請求項１２から１４のいずれか１項に記載の構成。
16. 確立された前記接続はＶＰＮトンネルであることを特徴とする請求項１２から１５のいずれか１項に記載の構成。
17. 前記接続モジュールは、前記第１の装置のリモートアクセスクライアントＲＡＣと前記ゲートウェイのリモートアクセスサーバＲＡＳとの間に前記接続を確立するように更に構成され、前記ＲＡＣ及び前記ＲＡＳは事前にペアリング処理により対を形成していることを特徴とする請求項１２から１６のいずれか１項に記載の構成。
18. 前記送出モジュールは、ＵＰｎＰ ＡＶ手順に基づいて前記ＵＲＬを前記メディアレンダラへ送出するように更に構成されることを特徴とする請求項１２から１７のいずれか１項に記載の構成。
19. 前記送出モジュールは、前記メディアサーバから前記メディアコンテンツを取り出すためのＨＴＴＰ ＧＥＴメッセージに変換可能なＵＰｎＰ ＡＶＴ Ｐｌａｙコマンドを前記メディアレンダラヘ送出するように更に構成されることを特徴とする請求項１８に記載の構成。
20. 前記第１の装置は移動電話であることを特徴とする請求項１２から１９のいずれか１項に記載の構成。

Images