(57)【要約】  本発明は、無線通信システムに関し、ワイファイディスプレイサービス実行方法及びそのための装置が開示される。そのための、第１無線デバイスでワイファイディスプレイ（Wi-Fi Display；ＷＦＤ）サービスを行う方法は、前記第１無線デバイスが、前記第１無線デバイスのリアルタイム出力画面を、前記第１無線デバイスと第２無線デバイスとが共通にサポートする共通コーデックでエンコードし、前記第２無線デバイスにストリーミングするステップと、マルチメディアファイルのストリーミングを要求するユーザ入力を受信するステップと、前記マルチメディアファイルが前記第２無線デバイスで再生可能な場合、前記リアルタイム出力画面のストリーミングを一時中断し、前記第２無線デバイスに前記マルチメディアファイルをストリーミングするステップと、を有することができる。【選択図】図１３
2017512332.tif 000002
【特許請求の範囲】
【請求項１】
第１無線デバイスでワイファイディスプレイ（ＷＦＤ）サービスを行う方法であって、前記第１無線デバイスが、
前記第１無線デバイスのリアルタイム出力画面を、前記第１無線デバイスと第２無線デバイスとが共通にサポートする共通コーデックでエンコードし、前記第２無線デバイスにストリーミングするステップと、
マルチメディアファイルのストリーミングを要求するユーザ入力を受信するステップと、
前記マルチメディアファイルが前記第２無線デバイスで再生可能な場合、前記リアルタイム出力画面のストリーミングを中断し、前記第２無線デバイスに前記マルチメディアファイルをストリーミングするステップと、を有する、ＷＦＤサービス実行方法。
【請求項２】
前記マルチメディアファイルが前記第２無線デバイスで再生不可能な場合、前記第１無線デバイスは、前記マルチメディアファイルを前記共通コーデックでコード変換し、前記第２無線デバイスにストリーミングする、請求項１に記載のＷＦＤサービス実行方法。
【請求項３】
前記マルチメディアファイルのストリーミングを中断するユーザ入力を受信すると、前記第１無線デバイスは、前記マルチメディアファイルのストリーミングを中断し、前記中断されたリアルタイム出力画面のストリーミングを再開する、請求項１に記載のＷＦＤサービス実行方法。
【請求項４】
前記マルチメディアファイルが前記第２無線デバイスで再生可能な場合、前記第１無線デバイスが、前記第２無線デバイスに、前記リアルタイム出力画面をストリーミングするための前記ＷＦＤサービス下の第１動作モードから、前記マルチメディアファイルのストリーミングのための前記ＷＦＤサービス下の第２動作モードへの変更を要求するステップをさらに有する、請求項１に記載のＷＦＤサービス実行方法。
【請求項５】
前記第１無線デバイスは、前記第２無線デバイスから、前記第２無線デバイスが前記第１動作モードから前記第２動作モードへと変更可能な能力を有するか否かに関する情報を受信する、請求項４に記載のＷＦＤサービス実行方法。
【請求項６】
前記マルチメディアファイルが前記第２無線デバイスで再生可能な場合、前記第１無線デバイスが、前記第２無線デバイスに、前記リアルタイム出力画面をストリーミングするための前記ＷＦＤサービスから前記マルチメディアファイルをストリーミングするための所定のサービスへの切り替えを要求するステップをさらに有する、請求項１に記載のＷＦＤサービス実行方法。
【請求項７】
前記所定のサービスは、デジタルリビングネットワークアライアンス（ＤＬＮＡ（登録商標））及びプレイ（Ｐｌａｙ）サービスのいずれか１つである、請求項６に記載のＷＦＤサービス実行方法。
【請求項８】
前記第１無線デバイスは、前記第２無線デバイスから、前記第２無線デバイスが前記ＷＦＤサービスから前記ＤＬＮＡへと切り替え可能な能力を有するか否かに関する情報を受信する、請求項７に記載のＷＦＤサービス実行方法。
【請求項９】
前記情報は、前記第２無線デバイスのＤＬＮＡ  ユニークユーザ識別情報（ＵＵＩＤ）を有する、請求項８に記載のＷＦＤサービス実行方法。
【請求項１０】
前記情報を受信すると、前記第１無線デバイスは、前記第２無線デバイスに、前記第１無線デバイスのＤＬＮＡ  ＵＵＩＤを有するメッセージを送信する、請求項９に記載のＷＦＤサービス実行方法。
【請求項１１】
第１無線デバイスでワイファイディスプレイ（ＷＦＤ）サービスを行う方法であって、前記第１無線デバイスが、
前記第１無線デバイスと第２無線デバイスとが共通にサポートする共通コーデックでエンコードされた前記第２無線デバイスのリアルタイム出力画面を受信してストリーミングするステップと、
前記第２無線デバイスを介して、前記第１無線デバイスで再生可能なマルチメディアファイルのストリーミングを要求するユーザ入力が受信された場合、前記第２無線デバイスの前記リアルタイム出力画面のストリーミングを中断し、前記第２無線デバイスから前記マルチメディアファイルを受信してストリーミングするステップと、を有する、ＷＦＤサービス実行方法。
【請求項１２】
ワイファイディスプレイ（ＷＦＤ）サービスを行う第１無線デバイスであって、
ディスプレイ部と、
送受信器と、
プロセッサと、を有し、
前記プロセッサは、
前記ディスプレイ部のリアルタイム出力画面を、前記第１無線デバイスと第２無線デバイスとが共通にサポートする共通コーデックでエンコードして、前記第２無線デバイスにストリーミングし、
マルチメディアファイルのストリーミングを要求するユーザ入力を受信し、
前記マルチメディアファイルが前記第２無線デバイスで再生可能な場合、前記リアルタイム出力画面のストリーミングを中断し、前記第２無線デバイスに前記マルチメディアファイルをストリーミングする、ＷＦＤサービスの実行のための第１無線デバイス。
【請求項１３】
ワイファイディスプレイ（ＷＦＤ）サービスを行う第１無線デバイスであって、
ディスプレイ部と、
送受信器と、
プロセッサと、を有し、
前記プロセッサは、
前記第１無線デバイスと第２無線デバイスとが共通にサポートする共通コーデックでエンコードされた前記第２無線デバイスのリアルタイム出力画面を受信してストリーミングし、
前記第２無線デバイスを介して、前記第１無線デバイスで再生可能なマルチメディアファイルのストリーミングを要求するユーザ入力が受信されると、前記第２無線デバイスの前記リアルタイム出力画面のストリーミングを中断し、前記第２無線デバイスから前記マルチメディアファイルを受信してストリーミングする、ＷＦＤサービスの実行のための第１無線デバイス。
【発明の詳細な説明】
【技術分野】
【０００１】
以下の説明は、無線通信システムに係り、より具体的には、ダイレクト（直接）通信システムにおいてワイファイディスプレイサービスを行う方法及びダイレクト通信システムにおいてワイファイディスプレイサービスを行う装置に関する。
【背景技術】
【０００２】
近年、情報通信技術の発展に伴って様々な無線通信技術が開発されている。その中でも無線ＬＡＮ（ＷＬＡＮ）は、無線周波数技術に基づいて個人携帯用情報端末機（Personal Digital Assistant；ＰＤＡ）、ラップトップコンピュータ、携帯用マルチメディアプレーヤ（Portable Multimedia Player；ＰＭＰ）などの携帯用端末機を用いて、家庭、企業又は特定サービス提供地域において、無線でインターネットにアクセスできるようにする技術である。
【０００３】
既存の（conventional）無線ＬＡＮシステムにおいて基本的に必要とされる（required）無線アクセスポイント（ＡＰ）を介せずに、デバイス（device）が互いに容易に接続できるようにするダイレクト通信技術として、Ｗｉ−Ｆｉダイレクト（登録商標）（Wi-Fi Direct（登録商標））又はＷｉ−Ｆｉ（登録商標）Ｐ２Ｐ（peer-to-peer）の導入が議論されている。Ｗｉ−Ｆｉダイレクトによれば、複雑な設定（確立）手順（過程）（establishment procedure）を経ることなくデバイスが互いに接続可能であり、ユーザに様々なサービスを提供するために、一般的な無線ＬＡＮシステムの通信速度で互いにデータをやり取りする動作をサポートする（support）ことができる。
【０００４】
近年、様々なＷｉ−Ｆｉサポート（支援）（support）デバイスが用いられており、特に、ＡＰが介入しなくてもＷｉ−Ｆｉデバイス間の通信が可能なＷｉ−Ｆｉダイレクトサポートデバイスの数が増加している。ＷＦＡ（Wi-Fi Alliance）では、Ｗｉ−Ｆｉダイレクトリンクを用いた様々なサービス（例えば、送信（Ｓｅｎｄ）、プレイ（Ｐｌａｙ）、ディスプレイ（Ｄｉｓｐｌａｙ）、プリント（Ｐｒｉｎｔ）など）をサポートするプラットホームを導入する技術が議論されている。これをワイファイダイレクトサービス（Wi-Fi Direct Service；ＷＦＤＳ）と呼ぶことができる。
【０００５】
ＷＦＤＳのうち、ディスプレイサービスによれば、ワイファイディスプレイ（Wi-Fi Display；ＷＦＤ）ソース（Source）及びワイファイディスプレイシンク（Sink）は、プローブ要求（probe request）及び応答フレームに含まれたＷＦＤ情報要素（Information Element；ＩＥ）を用いてお互いを探索することができる。
【発明の概要】
【発明が解決しようとする課題】
【０００６】
本発明は、ＷＦＤサービスにおいてコード変換（トランスコーディング）（transcoding）を行わずにマルチメディアファイルをストリーミングする方法を提供することを目的とする。具体的には、本発明では、ＷＦＤシンクで再生可能な（playable）マルチメディアファイルのストリーミングが要求された場合、マルチメディアファイルのデコーディング及びエンコーディングを行わずにマルチメディアファイルをストリーミングする方法を提供することを目的とする。
【０００７】
本発明で達成しようとする技術的課題は、以上で言及した技術的課題に制限されず、言及していない他の技術的課題は、以下の記載から、本発明の属する技術分野における通常の知識を有する者に明確に理解されるであろう。
【課題を解決するための手段】
【０００８】
上記の技術的課題を解決するために、本発明の一実施例に係る第１無線デバイスでワイファイディスプレイ（Wi-Fi Display；ＷＦＤ）サービスを行う方法は、第１無線デバイスが、第１無線デバイスのリアルタイム出力画面を第１無線デバイスと第２無線デバイスとが共通にサポートする共通コーデックでエンコードし、第２無線デバイスにストリーミングするステップと、マルチメディアファイルのストリーミングを要求するユーザ入力を受信するステップと、マルチメディアファイルが第２無線デバイスで再生可能な場合、リアルタイム出力画面のストリーミングを中断し、第２無線デバイスにマルチメディアファイルをストリーミングするステップと、を有することができる。
【０００９】
上記の技術的課題を解決するために、本発明の一実施例に係る第１無線デバイスでワイファイディスプレイ（Wi-Fi Display；ＷＦＤ）サービスを行う方法は、第１無線デバイスが、第１無線デバイスと第２無線デバイスとが共通にサポートする共通コーデックでエンコードされた第２無線デバイスのリアルタイム出力画面を受信してストリーミングするステップと、第２無線デバイスを介して、第１無線デバイスで再生可能なマルチメディアファイルのストリーミングを要求するユーザ入力が受信された場合、第２無線デバイスのリアルタイム出力画面のストリーミングを中断し、第２無線デバイスからマルチメディアファイルを受信してストリーミングするステップと、を有することができる。
【００１０】
上記の技術的課題を解決するための本発明の一実施例に係るデバイス探索を行う第１無線デバイスは、送受信器及びプロセッサを有することができる。このとき、プロセッサは、プローブ要求フレームを送信するように送受信器を制御し、送受信器が、第２無線デバイスから、プローブ要求フレームに対する応答としてプローブ応答フレームを受信すると、プローブ応答フレームから、第２無線デバイスが現在接続しているＡＰ（Access Point）の情報をデコードすることができる。
【００１１】
上記の技術的課題を解決するための本発明の一実施例に係るワイファイディスプレイ（Wi-Fi Display；ＷＦＤ）サービスを行う第１無線デバイスは、ディスプレイ部と、送受信器と、プロセッサと、を有することができる。このとき、プロセッサは、ディスプレイ部のリアルタイム出力画面を、第１無線デバイスと第２無線デバイスとが共通にサポートする共通コーデックでエンコードして、第２無線デバイスにストリーミングし、マルチメディアファイルのストリーミングを要求するユーザ入力を受信し、マルチメディアファイルが第２無線デバイスで再生可能な場合、リアルタイム出力画面のストリーミングを中断し、第２無線デバイスにマルチメディアファイルをストリーミングすることができる。
【００１２】
上記の技術的課題を解決するための本発明の一実施例に係るワイファイディスプレイ（Wi-Fi Display；ＷＦＤ）サービスを行う第１無線デバイスは、ディスプレイ部と、送受信器と、プロセッサと、を有することができる。このとき、プロセッサは、第１無線デバイスと第２無線デバイスとが共通にサポートする共通コーデックでエンコードされた第２無線デバイスのリアルタイム出力画面を受信してストリーミングし、第２無線デバイスを介して、第１無線デバイスで再生可能なマルチメディアファイルのストリーミングを要求するユーザ入力が受信されると、第２無線デバイスのリアルタイム出力画面のストリーミングを中断し、第２無線デバイスからマルチメディアファイルを受信してストリーミングすることができる。
【００１３】
本発明について前述した一般的な説明と後述する詳細な説明とは例示的なものであり、請求項記載の発明に関するさらなる説明のためのものである。
【発明の効果】
【００１４】
本発明によれば、ＷＦＤサービスにおいてコード変換を行わずにマルチメディアファイルをストリーミングする方法及びＷＦＤサービスにおいてコード変換を行わずにマルチメディアファイルをストリーミングする装置を提供することができる。具体的には、本発明では、ＷＦＤシンクで再生可能なマルチメディアファイルのストリーミングが要求された場合、マルチメディアファイルのデコーディング及びエンコーディングを行わずにマルチメディアファイルをストリーミングする方法及びそのための装置を提供することができる。
【００１５】
本発明から得られる効果は、以上で言及した効果に制限されず、言及していない他の効果は、以下の記載から、本発明の属する技術分野における通常の知識を有する者に明確に理解されるであろう。
【図面の簡単な説明】
【００１６】
【図１】本発明を適用できるＩＥＥＥ８０２．１１システムの例示的な構造を示す図である。
【図２】ワイファイダイレクト（Wi-Fi Direct）ネットワークを例示する図である。
【図３】ＷＦＤネットワークを構成する過程（処理）（process）を説明する図である。
【図４】近隣探索過程を説明する図である。
【図５】ＷＦＤネットワークの新たな態様を説明する図である。
【図６】ＷＦＤ通信のためのリンクを設定する方法を説明する図である。
【図７】ＷＦＤを行っている通信グループに参加（アソシエーション）（association）する方法を説明する図である。
【図８】ＷＦＤ通信のためのリンクを設定する方法を説明する図である。
【図９】ＷＦＤ通信グループに参加するリンクを設定する方法を説明する図である。
【図１０】ＷＦＤＳフレームワーク構成要素を説明する図である。
【図１１】ＷＦＤソースとＷＦＤシンクとの間でＷＦＤセッションが構築される過程を説明するフローチャートである。
【図１２】ＷＦＤ能力交渉手順を説明する図である。
【図１３】ＷＦＤセッション構築及びビデオ／オーディオストリーミング手順を説明する図である。
【図１４】リアルタイムエンコーディングモードと非コード変換モードとの間の切り替えが行われる例を説明する図である。
【図１５】ＷＦＤソースとＷＦＤシンクとの間の動作モードがリアルタイムエンコーディングモードから非コード変換モードに変更される具体的な例を示した図である。
【図１６】ＷＦＤソースとＷＦＤシンクとの間の動作モードが非コード変換モードからリアルタイムエンコーディングモードに変更される例を示した図である。
【図１７】ＷＦＤサービスからＤＮＬＡにハンドオーバが行われる例を説明する図である。
【図１８】ＷＦＤサービスが中断され、ＤＮＬＡが開始される例を示した図である。
【図１９】ＷＦＤサービスが再開される例を示した図である。
【図２０Ａ】能力交渉手順（capability negotiation procedure）において、ＷＦＤシンクがＷＦＤサービスからＤＮＬＡへ切り替え可能な能力を有するか否かを確認する過程を説明する図である。
【図２０Ｂ】能力交渉手順において、ＷＦＤシンクがＷＦＤサービスからＤＮＬＡへ切り替え可能な能力を有するか否かを確認する過程を説明する図である。
【図２１】本発明の一実施例に係る無線デバイスの構成を示すブロック図である。
【発明を実施するための形態】
【００１７】
本明細書に添付された図面は、本発明に対する理解を提供するためのもので、本発明の様々な実施形態を示し、明細書の記載と共に本発明の原理を説明するためのものである。
【００１８】
以下、本発明の好適な実施形態を、添付の図面を参照して詳細に説明する。添付の図面と共に以下に開示される詳細な説明は、本発明の例示的な実施形態を説明するためのもので、本発明を実施できる唯一の実施形態を示すものではない。以下の詳細な説明は、本発明の完全な理解を提供するために具体的な細部事項を含む。しかし、当業者には、本発明がそれらの具体的な細部事項がなくても実施可能であるということが理解される。
【００１９】
以下の実施例は、本発明の構成要素及び特徴を所定の形態で結合したものである。各構成要素又は特徴は、特別の言及がない限り、選択的なものとして考慮することができる。各構成要素又は特徴は、他の構成要素や特徴と結合されない形態で実施可能である。また、一部の構成要素及び／又は特徴を結合して本発明の実施例を構成してもよい。本発明の実施例で説明される動作の順序は変更可能である。ある実施例の一部の構成や特徴は、別の実施例に含まれてもよく、別の実施例の対応する構成又は特徴に置き替えられてもよい。
【００２０】
以下の説明で使用される特定用語は、本発明の理解を助けるために提供されたもので、これらの特定用語の使用は、本発明の技術的思想から逸脱しない範囲で他の形態に変更可能である。
【００２１】
場合によっては、本発明の概念が曖昧になることを避けるために、公知の構造及び装置を省略したり、各構造及び装置の核心機能を中心にしたブロック図の形式で図示することができる。また、本明細書全体にわたって同一の構成要素には同一の図面符号を付して説明する。
【００２２】
本発明の実施例は、無線アクセスシステムであるＩＥＥＥ８０２システム、３ＧＰＰシステム、３ＧＰＰＬＴＥ及びＬＴＥ−Ａ（LTE-Advanced）システム、３ＧＰＰ２システム並びにＷｉ−Ｆｉ  Ａｌｌｉａｎｃｅ（ＷＦＡ）システムのうち少なくとも１つに開示された標準文書によって裏付けることができる。すなわち、本発明の実施例において、本発明の技術的思想を明確にするために説明を省いた段階又は部分は、上記の文書によって裏付けることができる。また、本文書で開示している用語はいずれも上記の標準文書によって説明することができる。
【００２３】
以下の技術は、ＣＤＭＡ（Code Division Multiple Access）、ＦＤＭＡ（Frequency Division Multiple Access）、ＴＤＭＡ（Time Division Multiple Access）、ＯＦＤＭＡ（Orthogonal Frequency Division Multiple Access）、ＳＣ−ＦＤＭＡ（Single Carrier Frequency Division Multiple Access）などの様々な無線アクセスシステムに用いることができる。ＣＤＭＡは、ＵＴＲＡ（Universal Terrestrial Radio Access）やＣＤＭＡ２０００などの無線技術（radio technology）によって具現することができる。ＴＤＭＡは、ＧＳＭ（登録商標）（Global System for Mobile communications）／ＧＰＲＳ（General Packet Radio Service）／ＥＤＧＥ（Enhanced Data Rates for GSM Evolution）などの無線技術によって具現することができる。ＯＦＤＭＡは、ＩＥＥＥ８０２．１１（Ｗｉ−Ｆｉ）、ＩＥＥＥ８０２．１６（ＷｉＭＡＸ）、ＩＥＥＥ８０２．２０、Ｅ−ＵＴＲＡ（Evolved UTRA）などの無線技術によって具現することができる。明確にするために、以下ではＩＥＥＥ８０２．１１システムを中心に説明するが、本発明の技術的思想がこれに制限されるものではない。
【００２４】
ＷＬＡＮシステムの構造
図１は、本発明を適用できるＩＥＥＥ８０２．１１システムの例示的な構造を示す図である。
【００２５】
ＩＥＥＥ８０２．１１の構造は複数の構成要素（components）を含むことができ、これらの相互作用によって上位層に対してトランスペアレントな移動性をサポートするＷＬＡＮを提供することができる。基本サービスセット（Basic Service Set；ＢＳＳ）は、ＩＥＥＥ８０２．１１ＬＡＮにおける基本的な構成ブロックに対応し（correspond）得る。図１では、２個のＢＳＳ（ＢＳＳ１及びＢＳＳ２）が存在し、それぞれのＢＳＳのメンバーとして２個のＳＴＡが含まれる（ＳＴＡ１及びＳＴＡ２はＢＳＳ１に含まれ、ＳＴＡ３及びＳＴＡ４はＢＳＳ２に含まれる）ことを例示的に示している。図１において、ＢＳＳを示す楕円は、対応するＢＳＳに含まれたＳＴＡが通信を維持するカバレッジ領域を示すと理解してもよい。この領域をＢＳＡ（Basic Service Area）と呼ぶことができる。ＳＴＡがＢＳＡの外へ移動すると、対応するＢＳＡ内の他のＳＴＡと直接通信できなくなる。
【００２６】
ＩＥＥＥ８０２．１１ＬＡＮにおいて最も基本的なタイプのＢＳＳは、独立したＢＳＳ（Independent BSS；ＩＢＳＳ）である。例えば、ＩＢＳＳは、２個のＳＴＡだけで構成された最小の形態を有することができる。また、最も単純な形態であるとともに他の構成要素が省略されている図１のＢＳＳ（ＢＳＳ１又はＢＳＳ２）がＩＢＳＳの代表的な例に対応し得る。このような構成は、ＳＴＡ同士が直接通信できる場合に可能である。また、このような形態のＬＡＮは、予め計画して構成されるものではなく、ＬＡＮが必要な場合に構成され、これをアドホック（ad-hoc）ネットワークと呼ぶことができる。
【００２７】
ＳＴＡの電源オン／オフ、ＳＴＡのＢＳＳ領域への入／出などによって、ＢＳＳでのＳＴＡのメンバーシップが動的に変更され得る。ＢＳＳのメンバーになるためには、ＳＴＡは同期手順（synchronization procedure）を用いてＢＳＳにジョインすることができる。ＢＳＳ基盤構造（BSS based structure）の全てのサービスにアクセスするためには、ＳＴＡはＢＳＳに関連付けられて（associated）いなければならない。このような関連付け（association）は動的に設定することができ、配信（分配）システムサービス（Distribution System Service；ＤＳＳ）の利用を含むことができる。
【００２８】
層構造
無線ＬＡＮシステムで動作するＳＴＡの動作は、層（レイヤ）（layer）構造の観点で説明することができる。装置構成の面で層構造はプロセッサによって具現することができる。ＳＴＡは複数の層構造を有することができる。例えば、８０２．１１標準文書において扱う層構造は、主にＤＬＬ（Data Link Layer）上のＭＡＣ副層（サブレイヤ）（sublayer）及び物理（ＰＨＹ）層である。ＰＨＹは、ＰＬＣＰ（Physical Layer Convergence Procedure）エンティティ（entity）、ＰＭＤ（Physical Medium Dependent）エンティティなどを含むことができる。ＭＡＣ副層及びＰＨＹは、それぞれ、ＭＬＭＥ（MAC sublayer Management Entity）及びＰＬＭＥ（Physical Layer Management Entity）と呼ばれる管理エンティティを概念的に含む。このようなエンティティは、層管理機能が作動する層管理サービスインタフェースを提供する。
【００２９】
正確なＭＡＣ動作を提供するために、ＳＭＥ（Station Management Entity）がそれぞれのＳＴＡ内に存在する。ＳＭＥは、別個の（separate）管理プレーン内に存在したり、又は別個に離れて（off to the side）いるように見られる、層独立（layer independent）エンティティである。ＳＭＥの正確な機能は、本文書で具体的に説明していないが、一般的には様々な層管理エンティティ（ＬＭＥ）から層に従属した状態（layer-dependent status）を収集し、層特定パラメータなどの値をほぼ同一に設定するなどの機能を担当すると見ることができる。一般に、ＳＭＥは、一般のシステム管理エンティティを代表して（on behalf of）このような機能を行い、標準管理プロトコルを具現することができる。
【００３０】
前述したエンティティは、様々な方式で相互作用する。例えば、エンティティ間において、ＧＥＴ／ＳＥＴプリミティブ（primitive）を交換（exchange）することによって相互作用することができる。プリミティブは、特定の目的に関連した要素（element）やパラメータのセットを意味する。ＸＸ−ＧＥＴ．ｒｅｑｕｅｓｔプリミティブは、与えられたＭＩＢａｔｔｒｉｂｕｔｅ（管理情報ベースの属性情報）の値を要求するために使用される。ＸＸ−ＧＥＴ．ｃｏｎｆｉｒｍプリミティブは、Ｓｔａｔｕｓが“成功”である場合には適切なＭＩＢ属性情報値をリターンし、そうでない場合には、Ｓｔａｔｕｓフィールドでエラー指示をリターンするために使用される。ＸＸ−ＳＥＴ．ｒｅｑｕｅｓｔプリミティブは、指示されたＭＩＢ属性が与えられた値に設定されるように要求するために使用される。上記ＭＩＢ属性が特定の動作を意味する場合、これは、該当動作が行われることを要求するものである。そして、ＸＸ−ＳＥＴ．ｃｏｎｆｉｒｍプリミティブは、ｓｔａｔｕｓが“成功”である場合に、指示されたＭＩＢ属性が要求された値に設定されたことを確認し、そうでない場合には、ｓｔａｔｕｓフィールドにエラー条件をリターンするために使用される。ＭＩＢ属性が特定の動作を意味する場合、これによって、該当動作が行われたことが確認される。
【００３１】
また、ＭＬＭＥ及びＳＭＥは、様々なＭＬＭＥ_ＧＥＴ／ＳＥＴプリミティブをＭＬＭＥ_ＳＡＰ（Service Access Point）を介して交換することができる。また、様々なＰＬＭＥ_ＧＥＴ／ＳＥＴプリミティブが、ＰＬＭＥ_ＳＡＰを介してＰＬＭＥとＳＭＥとの間で交換されてもよく、ＭＬＭＥ−ＰＬＭＥ_ＳＡＰを介してＭＬＭＥとＰＬＭＥとの間で交換されてもよい。
【００３２】
無線ＬＡＮの進化
無線ＬＡＮ（ＷＬＡＮ）技術に関する標準は、ＩＥＥＥ（Institute of Electrical and Electronics Engineers）８０２．１１グループで開発している。ＩＥＥＥ  ８０２．１１ａ及びｂは、２．４．ＧＨｚ又は５ＧＨｚで免許不要帯域（unlicensed band）を利用し、ＩＥＥＥ  ８０２．１１ｂは１１Ｍｂｐｓの送信速度を提供し、ＩＥＥＥ  ８０２．１１ａは５４Ｍｂｐｓの送信速度を提供する。ＩＥＥＥ  ８０２．１１ｇは、２．４ＧＨｚで直交周波数分割多重（Orthogonal Frequency Division Multiplexing、ＯＦＤＭ）を適用して５４Ｍｂｐｓの送信速度を提供する。ＩＥＥＥ  ８０２．１１ｎは、多重入出力ＯＦＤＭ（Multiple Input Multiple Output-OFDM；ＭＩＭＯ−ＯＦＤＭ）を適用して３００Ｍｂｐｓの送信速度を提供する。ＩＥＥＥ  ８０２．１１ｎはチャネル帯域幅（channel bandwidth）を４０ＭＨｚまでサポートし、この場合、６００Ｍｂｐｓの送信速度を提供する。
【００３３】
ＩＥＥＥ  ８０２．１１ｅに基づく無線ＬＡＮ環境におけるＤＬＳ（Direct Link Setup）関連プロトコルは、ＢＳＳ（Basic Service Set）がＱｏＳ（Quality of Service）をサポートするＱＢＳＳ（Quality BSS）を前提とする。ＱＢＳＳでは非ＡＰ（Non-AP）ＳＴＡだけでなく、ＡＰもＱｏＳをサポートするＱＡＰ（Quality AP）である。ところが、現在商用化されている無線ＬＡＮ環境（例えば、ＩＥＥＥ  ８０２．１１ａ／ｂ／ｇなどに基づく無線ＬＡＮ環境）では、たとえＮｏｎ−ＡＰ  ＳＴＡがＱｏＳをサポートするＱＳＴＡ（Quality STA）であるとしても、ＡＰはＱｏＳをサポートできないレガシ（Legacy）ＡＰが殆どである。その結果、現在商用化されている無線ＬＡＮ環境ではＱＳＴＡであっても、ＤＬＳサービスを利用できないという限界がある。
【００３４】
トンネルダイレクトリンク設定（Tunneled Direct Link Setup；ＴＤＬＳ）は、上記のような限界を克服するために新しく提案された無線通信プロトコルである。ＴＤＬＳは、ＱｏＳはサポートしないが、現在商用化されたＩＥＥＥ  ８０２．１１ａ／ｂ／ｇなどの無線ＬＡＮ環境でもＱＳＴＡがダイレクトリンクを設定できるようにするとともに、パワーセーブモード（Power Save Mode；ＰＳＭ）でもダイレクトリンクの設定を可能にする。このため、ＴＤＬＳは、レガシＡＰが管理するＢＳＳにおいてもＱＳＴＡがダイレクトリンク設定可能な諸般手順を規定する。以下、このようなＴＤＬＳをサポートする無線ネットワークをＴＤＬＳ無線ネットワークという。
【００３５】
ワイファイダイレクトネットワーク
従来の無線ＬＡＮは、無線アクセスポイント（ＡＰ）がハブとして機能するインフラストラクチャ（infrastructure）ＢＳＳに関する動作を主に扱ってきた。ＡＰは、無線／有線接続のための物理レイヤサポート機能、ネットワーク上のデバイスに対するルーティング機能、及びデバイスをネットワークに追加／除去するためのサービスの提供などを担当する。この場合、ネットワーク内のデバイスはＡＰを介して接続されるもので、互いに直接接続されるものではない。
【００３６】
デバイス間の直接接続をサポートする技術としてワイファイダイレクト（Wi-Fi Direct）標準の制定が完了した。
【００３７】
図２は、ワイファイダイレクト（Wi-Fi Direct）ネットワークを例示する。ワイファイダイレクトネットワークは、Ｗｉ−Ｆｉ装置がホームネットワーク、オフィスネットワーク及びホットスポットネットワークに参加しなくても、互いにデバイス対デバイス（Device to Device；Ｄ２Ｄ）（或いは、Peer-to-Peer；Ｐ２Ｐ）通信が可能なネットワークであり、Ｗｉ−Ｆｉアライアンス（連合）（Alliance）によって提案された。以下、ワイファイダイレクトベース通信を、ワイファイダイレクトＤ２Ｄ通信（略して、Ｄ２Ｄ通信）或いはワイファイダイレクトＰ２Ｐ通信（略して、Ｐ２Ｐ通信）と呼ぶ。また、ワイファイダイレクトＰ２Ｐ実行デバイスを、ワイファイダイレクトＰ２Ｐデバイス、略して、Ｐ２Ｐデバイス又はピア（Peer）デバイスと呼ぶ。
【００３８】
図２を参照すると、ワイファイダイレクトネットワーク２００は、第１のＰ２Ｐデバイス２０２及び第２のＰ２Ｐデバイス２０４のように、少なくとも一つのＷｉ−Ｆｉデバイスを含むことができる。Ｐ２Ｐデバイスとしては、ディスプレイ装置、プリンタ、デジタルカメラ、プロジェクタ及びスマートフォンなどの、Ｗｉ−Ｆｉをサポートするデバイスを含む。また、Ｐ２Ｐデバイスは、Ｎｏｎ−ＡＰ  ＳＴＡ及びＡＰ  ＳＴＡを含む。図示の例では、第１のＰ２Ｐデバイス２０２は携帯電話であり、第２のＰ２Ｐデバイス２０４はディスプレイ装置である。ワイファイダイレクトネットワーク内のＰ２Ｐデバイスは互いに直接接続することができる。具体的には、Ｐ２Ｐ通信は、２つのＰ２Ｐデバイス間の信号送信経路が、第３のデバイス（例えば、ＡＰ）又は既存ネットワークを経由（例えば、ＡＰを経てＷＬＡＮに接続）せずに、対応するＰ２Ｐデバイス間で直接設定された場合を意味することができる。ここで、２つのＰ２Ｐデバイス間で直接設定された信号送信経路は、データ送信経路に制限されてもよい。例えば、Ｐ２Ｐ通信は、複数のＮｏｎ−ＳＴＡがＡＰに介入されずにデータ（例えば、音声／画像／文字情報など）を送信する場合を意味することができる。制御情報（例えば、Ｐ２Ｐ設定のためのリソース割り当て情報、無線デバイス識別情報など）のための信号送信経路は、Ｐ２Ｐデバイス（例えば、Ｎｏｎ−ＡＰ  ＳＴＡ対Ｎｏｎ−ＡＰ  ＳＴＡ、Ｎｏｎ−ＡＰ  ＳＴＡ対ＡＰ）間で直接設定されたり、ＡＰを経由して２つのＰ２Ｐデバイス（例えば、Ｎｏｎ−ＡＰ  ＳＴＡ対Ｎｏｎ−ＡＰ  ＳＴＡ）間で設定されたり、又はＡＰと対応するＰ２Ｐデバイス（例えば、ＡＰ対Ｎｏｎ−ＡＰ  ＳＴＡ＃１、ＡＰ対Ｎｏｎ−ＡＰ  ＳＴＡ＃２）との間で設定されてもよい。
【００３９】
図３は、ワイファイダイレクトネットワークを構成する過程を説明する図である。
【００４０】
図３を参照すると、ワイファイダイレクトネットワーク構成手順（過程）（procedure）は、２つの手順に大別できる。第一の手順は、近隣探索手順（Neighbor Discovery（ＮＤ）procedure）であり（Ｓ３０２ａ）、第二の手順は、Ｐ２Ｐリンク設定及び通信手順である（Ｓ３０４）。近隣探索手順で、Ｐ２Ｐデバイス（例えば、図２の２０２）は、（自体の無線の）カバレッジ内の他の近隣Ｐ２Ｐデバイス（例えば、図２の２０４）を探し、この対応するＰ２Ｐデバイスとの関連付け（association）、例えば、事前の関連づけ（pre-association）に必要な情報を取得することができる。ここで、事前の関連付けは、無線プロトコルにおける第２のレイヤの事前関連付けを意味することができる。事前関連付けに必要な情報は、例えば、近隣Ｐ２Ｐデバイスに関する識別情報などを含むことができる。近隣探索手順は、使用可能無線チャネルごとに行うことができる（Ｓ３０２ｂ）。その後、Ｐ２Ｐデバイス２０２は、他のＰ２Ｐデバイス２０４とワイファイダイレクトＰ２Ｐリンク設定／通信のための手順を行うことができる。例えば、Ｐ２Ｐデバイス２０２は、周辺（peripheral）Ｐ２Ｐデバイス２０４に関連付けられた後、対応するＰ２Ｐデバイス２０４がユーザのサービス要求事項を満たさないＰ２Ｐデバイスであるか否かを判断することができる。そのために、Ｐ２Ｐデバイス２０２は、周辺Ｐ２Ｐデバイス２０４との第２のレイヤの事前関連付け後に、対応するＰ２Ｐデバイス２０４を検索することができる。対応するＰ２Ｐデバイス２０４がユーザのサービス要求事項を満たさない場合、Ｐ２Ｐデバイス２０２は、対応するＰ２Ｐデバイス２０４に対して設定された第２のレイヤの関連付けを絶って、他のＰ２Ｐデバイスと第２のレイヤの関連付けを設定することができる。一方、対応するＰ２Ｐデバイス２０４がユーザのサービス要求事項を満たす場合には、２つのＰ２Ｐデバイス２０２及び２０４は、Ｐ２Ｐリンクを介して信号を送受信することができる。
【００４１】
図４は、近隣探索手順を説明する図である。図４の例は、図３におけるＰ２Ｐデバイス２０２とＰ２Ｐデバイス２０４との間の動作として理解してもよい。
【００４２】
図４を参照すると、図３の近隣探索手順は、ＳＭＥ（Station Management Entity）／アプリケーション／ユーザ／ベンダの指示によって開始され（initiated）（Ｓ４１０）、スキャン段階（scan phase）Ｓ４１２と検索段階（find phase）Ｓ４１４〜Ｓ４１６とに分けることができる。スキャン段階Ｓ４１２は、使用可能な全ての無線チャネルに対して８０２．１１方式によってスキャンする動作を含む。これによって、Ｐ２Ｐデバイスは、最良の（best）動作チャネルを確認することができる。検索段階Ｓ４１４〜Ｓ４１６は、リッスン（聴取）（listen）モードＳ４１４及び検索（search）モードＳ４１６を含み、Ｐ２Ｐデバイスは、リッスンモードＳ４１４と検索モードＳ４１６とを交互に反復する。Ｐ２Ｐデバイス２０２，２０４は、検索モードＳ４１６でプローブ要求（リクエスト）フレーム（Probe request frame）を用いて能動検索（active search）を行い、迅速な検索のために検索範囲をチャネル１、６、１１（例えば、２４１２、２４３７、２４６２ＭＨｚ）のソーシャルチャネル（social channel）に限定することができる。また、Ｐ２Ｐデバイス２０２，２０４は、リッスンモードＳ４１４で３個のソーシャルチャネルから一つのチャネルのみを選択して受信状態に維持する。このとき、他のＰ２Ｐデバイス（例えば、２０２）が検索モードで送信したプローブ要求フレームを受信した場合、Ｐ２Ｐデバイス（例えば、２０４）は、プローブ応答（レスポンス）フレーム（probe response frame）で応答する。リッスンモードＳ４１４の時間はランダムに与えられてもよい（例えば、１００、２００、３００ＴＵ（Time Unit））。Ｐ２Ｐデバイスは、検索モードと受信モードとを繰り返してお互いの共通チャネルに到達することができる。Ｐ２Ｐデバイスは、他のＰ２Ｐデバイスを発見した後、対応するＰ２Ｐデバイスに選択的に結合するために、プローブ要求フレームとプローブ応答フレームとを用いて、デバイスタイプ、メーカ又はよく知られた（familiar）デバイス名（name）を発見／交換することができる。近隣探索手順で周辺Ｐ２Ｐデバイスを発見し、必要な情報を得た場合、Ｐ２Ｐデバイス（例えば、２０２）は、ＳＭＥ／アプリケーション／ユーザ／ベンダにＰ２Ｐデバイス発見を知らせることができる（Ｓ４１８）。
【００４３】
現在、Ｐ２Ｐは、主に、リモート印刷（遠隔プリント）（remote printing）、写真の共有（photo sharing）などの半静的（semi-static）通信のために用いられている。しかし、Ｗｉ−Ｆｉデバイスの一般化（普遍化）（generalization）及び位置ベースサービスなどによって、Ｐ２Ｐの有用性（availability）は拡大の一途にある。例えば、ソーシャルチャット（例えば、ＳＮＳ（Social Network Service）に加入した無線デバイスが、位置ベースサービスに基づいて近隣地域の無線デバイスを認識して情報を送受信）、位置ベースの広告提供、位置ベースのニュース放送、無線デバイス間のゲームの連動（interaction）などにＰ２Ｐが盛んに用いられると予想される。便宜上、このようなＰ２Ｐの応用を、新Ｐ２Ｐ応用（新しいＰ２Ｐの応用）（new P2P application）と呼ぶ。
【００４４】
図５は、ワイファイダイレクトネットワークの新しい態様を説明する図である。
【００４５】
図５の例は、新Ｐ２Ｐ応用（例えば、ソーシャルチャット、位置ベースのサービス提供、ゲーム連動など）が適用される場合のワイファイダイレクトネットワークの態様として理解してもよい。
【００４６】
図５を参照すると、ワイファイダイレクトネットワークにおいて多数のＰ２Ｐデバイス５０２ａ〜５０２ｄがＰ２Ｐ通信５１０を行っており、Ｐ２Ｐデバイスの移動によってワイファイダイレクトネットワークを構成するＰ２Ｐデバイスが随時変更されたり、ワイファイダイレクトネットワーク自体が動的に／短時間で新しく生成されたり消滅したりする。このように、新Ｐ２Ｐ応用部分の特徴は、密集した（dense）ネットワーク環境で相当多数のＰ２Ｐデバイス間で動的に／短時間でＰ２Ｐ通信がなされ、終了し得るという点である。
【００４７】
図６は、ワイファイダイレクト通信のためのリンクを設定する方法を説明する図である。
【００４８】
図６ａに示すように、第１のＳＴＡ（６１０、以下、Ａと称する。）は、既存のワイファイダイレクト通信においてグループオーナ（Group Owner）として動作している。既存のワイファイダイレクト通信のグループクライアント６３０との通信中にＡ（６１０）が、新しいワイファイダイレクト通信の対象であり、ワイファイダイレクト通信を行っていない、第２のＳＴＡ（６２０、以下、Ｂと称する。）を発見した場合、Ａ（６１０）は、Ｂ（６２０）とのリンク設定を試みる。この場合、新しいワイファイダイレクト通信は、Ａ（６１０）とＢ（６２０）との間のワイファイダイレクト通信であり、Ａはグループオーナであるから、既存のグループクライアント６３０との通信とは別に通信設定を行うことができる。一つのワイファイダイレクトグループは、１つのグループオーナと１つ又は複数のグループクライアントとから構成でき、ここでは、１つのグループオーナであるＡ（６１０）を満たすので、図６ｂに示すように、ワイファイダイレクトリンクを設定することができる。これは、Ａ（６１０）が既存のワイファイダイレクト通信グループにＢ（６２０）を招待（invitation）した場合であり、ワイファイダイレクト通信の特性上、Ａ（６１０）とＢ（６２０）との間、Ａ（６１０）と既存のグループクライアント６３０との間のワイファイダイレクト通信が可能である。なお、Ｂ（６２０）と既存のグループクライアント６３０との間のワイファイダイレクト通信もデバイスの能力（capability）によって選択的にサポート可能である。
【００４９】
図７は、ワイファイダイレクト通信を行っている通信グループに参加（アソシエーション）（association）する（（関連付けを行う）（associating with））方法を説明する図である。
【００５０】
図７ａに示すように、第１のＳＴＡ（７１０、以下、Ａと称する。）は、グループクライアント７３０に対してグループオーナとして通信中であり、第２のＳＴＡ（７２０、以下、Ｂと称する。）は、グループクライアント７４０に対してグループオーナとして通信中である。図７ｂに示すように、Ａ（７１０）は、既存のワイファイダイレクト通信を終了（termination）し、Ｂ（７２０）の属するワイファイダイレクト通信グループに参加（association）することができる。Ａ（７１０）は、Ｂ（７２０）がグループオーナであるから、Ｂのグループクライアントとなる。Ａ（７１０）は、Ｂ（７２０）に関連付けを要求する前に、既存のワイファイダイレクト通信を終了することが好ましい。
【００５１】
図８は、ワイファイダイレクト通信のためのリンクを設定する方法を説明する図である。
【００５２】
図８ａに示すように、第２のＳＴＡ（８２０、以下、Ｂと称する。）は、既存のワイファイダイレクト通信においてグループオーナ（Group Owner）として動作中である。既存のワイファイダイレクト通信においてグループクライアント８３０とワイファイダイレクト通信中である場合、Ｂ（８２０）を発見した、ワイファイダイレクト通信を行っていない第１のＳＴＡ（８１０、以下、Ａと称する。）が、Ｂ（８２０）との新しいワイファイダイレクト通信のためにリンク設定を試みる。この場合、Ｂ（８２０）がリンク設定を受諾すると、Ａ（８１０）とＢ（８２０）との間の新しいワイファイダイレクト通信リンクが設定され、Ａ（８１０）は既存Ｂ（８２０）のワイファイダイレクトグループのクライアントとして動作するようになる。これは、Ａ（８１０）がＢ（８２０）のワイファイダイレクト通信グループに参加（association）した場合となる。Ａ（８１０）は、グループオーナであるＢ（８２０）のみとワイファイダイレクト通信することができる。なお、Ａ（８１０）と既存ワイファイダイレクト通信のクライアント８３０との間のワイファイダイレクト通信は、デバイスの能力によって選択的に可能である（サポートされる）。
【００５３】
図９は、ワイファイダイレクト通信グループに参加するリンクを設定する方法を説明する図である。
【００５４】
図９ａに示すように、第１のＳＴＡ（９１０、以下、Ａと称する。）は、グループオーナ９３０に対してグループクライアントとしてワイファイダイレクト通信中にある。このとき、他のワイファイダイレクト通信のグループクライアント９４０に対してグループオーナとして通信中である第２のＳＴＡ（９２０、以下、Ｂと称する。）を発見したＡ（９１０）は、グループオーナ９３０とのリンクを終了（termination）し、Ｂ（９２０）のワイファイダイレクト通信グループに参加することができる。
【００５５】
ワイファイダイレクトサービス（ＷＦＤＳ）
ワイファイダイレクトは、リンクレイヤ（Link layer）の動作などを定義するネットワーク接続標準技術である。ワイファイダイレクトによって構成されたリンクの上位レイヤで動作するアプリケーションに関する標準が定義されていないため、ワイファイダイレクトをサポートするデバイスが相互接続された後にアプリケーションを駆動する場合の互換性をサポートすることが難しかった。このような問題を解決するために、ワイファイダイレクトサービス（ＷＦＤＳ）という上位レイヤアプリケーションの動作に関する標準化がワイファイアライアンス（ＷＦＡ）で議論されている。
【００５６】
図１０は、ＷＦＤＳフレームワーク構成要素を説明する図である。
【００５７】
図１０のワイファイダイレクトレイヤは、ワイファイダイレクト標準によって定義されるＭＡＣレイヤを意味する。ワイファイダイレクトレイヤは、ワイファイダイレクト標準と互換性を有するソフトウェアとして構成することができる。Ｗｉ−Ｆｉ  Ｄｉｒｅｃｔレイヤの下位には、Ｗｉ−Ｆｉ  ＰＨＹと互換性を有する物理レイヤ（図示せず）によって無線接続が構成されてもよい。Ｗｉ−Ｆｉ  Ｄｉｒｅｃｔレイヤの上位にＡＳＰ（Application Service Platform）というプラットホームが定義される。
【００５８】
ＡＳＰは、サービスが必要とする機能を実行する論理エンティティである。ＡＳＰは共通共有プラットホーム（common shared platform）であり、上位のアプリケーション（Application）レイヤと下位のＷｉ−Ｆｉ  Ｄｉｒｅｃｔレイヤとの間においてデバイス探索（Device Discovery）、サービス探索（Service Discovery）、ＡＳＰセッション管理（ASP Session management）、接続トポロジ管理（Connection topology management）及びセキュリティ（保安）（Security）などのタスクを処理することができる。
【００５９】
ＡＳＰの上位にはサービス（Service）レイヤが定義される。サービスレイヤは、用途（use case）特定サービスを含む。ＷＦＤＳでは、４個の基本サービスである送信（Ｓｅｎｄ）、プレイ（Ｐｌａｙ）、ディスプレイ（Ｄｉｓｐｌａｙ）、プリント（Ｐｒｉｎｔ）サービスを定義する。ＷＦＤＳで定義する４つの基本サービスを簡略に説明すると、まず、Ｓｅｎｄは、２つのＷＦＤＳデバイス間でファイル送信が可能なサービス及びアプリケーションを意味する。送信サービスは、ピア機器間のファイルを送信するためのものである点で、ファイル送信サービス（File Transfer Service；ＦＴＳ）と呼ぶこともできる。Ｐｌａｙは、２つのＷＦＤＳデバイス間デジタルリビングネットワークアライアンス（Digital Living Network Alliance；ＤＬＮＡ（登録商標））に基づくオーディオ／ビデオ（Ａ／Ｖ）、写真、音楽などを共有又はストリーミングするサービス及びアプリケーションを意味する。Ｐｒｉｎｔは、文書、写真などのコンテンツを有するデバイスとプリンタとの間で文書、写真の出力を可能にするサービス及びアプリケーションを意味する。Ｄｉｓｐｌａｙは、ＷＦＡのミラキャスト（Miracast）ソースとシンクとの間で画面共有を可能にするサービス及びアプリケーションを意味する。
【００６０】
図１０に示すイネーブル（Enable）ＡＰＩ（Application Program Interface）は、ＷＦＤＳで定める基本サービスの他にサードパーティ（3rd party）アプリケーションをサポートする場合にＡＳＰ共通プラットホームを利用可能にするために定義される。サードパーティーアプリケーションのために定義されるサービスは、一つのアプリケーションでのみ利用されてもよく、様々なアプリケーションで一般的に（又は共通に）利用されてもよい。
【００６１】
説明の便宜のために、ＷＦＤＳによって定義されたサービスはＷＦＤＳサービス、ＷＦＡ以外のサードパーティによって新しく定義されるサービスはイネーブルサービスと呼ぶものとする。
【００６２】
アプリケーションレイヤはユーザインタフェース（ＵＩ）を提供することができ、情報を人にとって認識可能な形態で表現し、ユーザの入力を下位レイヤに伝達するなどの機能を果たす。
【００６３】
上述した説明に基づいて、ＷＦＤＳのうちディスプレイ（Display）サービスについてより詳しく説明する。
【００６４】
Ｗｉ−Ｆｉ  Ｄｉｓｐｌａｙ
ＷＦＤＳのうち、ディスプレイサービスは、Ｐ２Ｐデバイス間で画面共有を可能にするサービス及びアプリケーションを意味する。ディスプレイサービスを利用するＰ２Ｐデバイスを、ＷＦＤデバイスと呼ぶことができ、ＷＦＤデバイスのうち、デバイス（機器）Ｐ２Ｐリンク（device P2P link）を介してマルチメディアコンテンツのストリーミングをサポートする機器をワイファイディスプレイ（ＷＦＤ）ソース（Source）、Ｐ２Ｐリンクを介してＷＦＤソース機器から受信してレンダリングする機器をＷＦＤシンク（Sink）と呼ぶことができる。
【００６５】
図１１は、ＷＦＤソースとＷＦＤシンクとの間にＷＦＤセッションが構築される手順を説明するフローチャートである。ＷＦＤソース及びＷＦＤシンクは、まず、ＷＦＤデバイス探索（WFD Device Discovery）によって、ＷＦＤ接続セットアップに先立ってお互いの存在を探索することができる。具体的には、ＷＦＤデバイスは、ＷＦＤ情報要素（WFD IE）を含むプローブ要求フレーム及びプローブ応答フレームを用いてお互いの存在を認知できる。ＷＦＤ情報要素は、デバイスタイプ及びデバイス状態などの、ＷＦＤデバイス間の最適な接続を構築するための基本情報を含むことができる。ＷＦＤデバイスが、ＷＦＤ  ＩＥを含むプローブ要求フレームを受信すると、それに対する応答として、自体のＷＦＤ  ＩＥを含むプローブ応答フレームを送信することができる。
【００６６】
ＷＦＤデバイスがＡＰと相互接続され（関連付けられ）（inter-connected）ており、Ｗｉ−Ｆｉ  Ｐ２Ｐデバイスとして動作する場合、一つの物理デバイスに論理的に２個以上のワイファイ送受信器が動作するようになる。このとき、ＷＦＤデバイス探索のためには、任意の（any one of）ワイファイダイレクト送受信器を使用することができる。ＷＦＤデバイスの探索のためのプローブ要求フレームには、ＷＦＤ  ＩＥの他、Ｐ２Ｐ情報要素（ＩＥ）が含まれてもよく、これは、ワイファイダイレクト送受信器によってデコーディング可能である。
【００６７】
その後、ＷＦＤソース及びＷＦＤシンクは、ＷＦＤ接続セットアップに先立ってお互いのサービス能力を探索する（search for）（又は、発見する(or discover)）ことができる。具体的には、任意（いずれか一つ）のＷＦＤデバイスが、ＷＦＤ能力が情報副要素（information subelement）として含まれるサービス探索要求フレームを送信すると、他のＷＦＤデバイスは、それに対する応答として、自体のＷＦＤ能力が情報副要素として含まれるサービス探索応答フレームを送信することができる。サービス探索手順はオプションの（optional）（又は、選択的な(or selective)）手順であり、サービス探索手順をサポートするＷＦＤデバイスは、サービス探索手順をサポートする探索された（searched）（又は、発見された(or discovered)）ＷＦＤデバイスとサービス探索手順を行うことができる。サービス探索手順を行うために、デバイス探索手順に用いられるプローブ要求フレーム及び応答フレームには、ＷＦＤデバイスがサービス探索手順をサポートする能力を有するか否かを示す情報が含まれてもよい。
【００６８】
その後、ＷＦＤソース又はＷＦＤシンクは、ＷＦＤ接続セットアップのためのピアＷＦＤデバイスを選択することができる。ユーザの入力によってＷＦＤ接続セットアップを実行するピアＷＦＤデバイスが選択されてもよく、ポリシ（policy）によって自動的にＷＦＤ接続セットアップを行うピアＷＦＤデバイスが選択されてもよい。
【００６９】
その後、ＷＦＤデバイスは、選択されたピアＷＦＤデバイスとのＷＦＤ接続セットアップ方法を選択することができる。具体的には、ＷＦＤデバイスは、Ｗｉ−Ｆｉ  Ｐ２Ｐ又はＴＤＬＳのいずれかの接続スキーム（Connectivity Scheme）でＷＦＤ接続を構築することができる。ＷＦＤデバイスは、好ましい接続（Preferred Connectivity）情報及びＷＦＤ情報要素と共に伝達される相互接続された（関連付けられた）（inter-connected）ＢＳＳＩＤ副要素に基づいて、接続スキームを決定することができる。
【００７０】
ＷＦＤデバイス間でＷｉ−Ｆｉ  Ｐ２Ｐ又はＴＤＬＳを用いて成功裏にＷＦＤセットアップが行われると、ＷＦＤデバイスは、ＷＦＤ能力交渉（WFD capability negotiation）を行うことができる。ＷＦＤ能力交渉を通じてＷＦＤソース及びＷＦＤシンクは、お互いがサポートするコーデック、コーデックのプロファイル情報、コーデックのレベル情報及び解像度情報のうちの少なくとも１つを確認することができる。
【００７１】
具体的には、ＷＦＤソース及びＷＦＤシンクは、ＲＴＳＰ（Real_Time Streaming Protocol）プロトコルを用いてメッセージを交換することによって、ＷＦＤセッションの間のオーディオ／ビデオペイロード（payload）を定義するパラメータセットを決定することができる。ＷＦＤ能力交渉手順の間、ＲＴＳＰ  Ｍ１からＲＴＳＰ  Ｍ４までのメッセージの交換が行われ得る。
【００７２】
一例として、図１２は、ＷＦＤ能力交渉手順を説明する図である。図１２に示された例のように、ＷＦＤソースは、まず、ＲＳＴＰ手順及びＷＦＤ能力交渉を開始するためのＲＴＳＰ  Ｍ１要求メッセージを送信することができる。ＲＴＳＰ  Ｍ１要求メッセージは、ＷＦＤシンクでサポートするＲＴＳＰメソッド（methods）セット（set）を決定するためのＲＴＳＰ  ＯＰＴＩＯＮＳ要求を含むことができる。ＲＴＳＰ  Ｍ１要求メッセージを受信すると、ＷＦＤシンクは、自体がサポートするＲＴＳＰメソッドが列挙された（listed）ＲＴＳＰ  Ｍ１応答メッセージで応答することができる。
【００７３】
ＲＴＳＰ  Ｍ１メッセージの交換に成功した後、ＷＦＤシンクは、ＷＦＤソースでサポートするＲＴＳＰメソッドセットを決定するためのＲＴＳＰ  Ｍ２要求メッセージを送信することができる。ＲＴＳＰ  Ｍ２要求メッセージを受信すると、ＷＦＤソースは、自体がサポートするＲＴＳＰメソッドが列挙されたＲＴＳＰ  Ｍ２応答メッセージで応答することができる。
【００７４】
ＲＴＳＰ  Ｍ２メッセージの交換に成功した後、ＷＦＤソースは、ＷＦＤソースが関心を示す（interested by the WFD source）ＷＦＤ能力のリスト（目録）（list）を明示したＲＴＳＰ  Ｍ３要求メッセージ（ＲＴＳＰ  ＧＥＴ_ＰＡＲＡＭＥＴＥＲ要求メッセージ）を送信することができる。ＲＴＳＰ  Ｍ３要求メッセージを受信すると、ＷＦＤシンクは、ＲＴＳＰ  Ｍ３応答メッセージ（ＲＴＳＰ  ＧＥＴ_ＰＡＲＡＭＥＴＥＲ応答メッセージ）で応答することができる。
【００７５】
ＲＴＳＰ  Ｍ３応答メッセージに基づいて、ＷＦＤソースは、ＷＦＷＤセッションの間に使用される最適なパラメータセットを決定し、ＷＦＤセッションの間にＷＦＤソースとＷＦＤシンクとの間で使用されるパラメータセットを含むＲＴＳＰ  Ｍ４要求メッセージ（ＲＴＳＰ  ＳＥＴ_ＰＡＲＡＭＥＴＥＲ要求メッセージ）をＷＦＤシンクに送信することができる。ＲＴＳＰ  Ｍ４要求メッセージを受信すると、ＷＦＤシンクは、ＲＴＳＰ  Ｍ４応答メッセージ（ＲＴＳＰ  ＳＥＴ_ＰＡＲＡＭＥＴＥＲ応答メッセージ）で応答することができる。
【００７６】
ＷＦＤ能力交渉段階が成功裏に終了すると、ＷＦＤソース及びＷＦＤシンクは、ＷＦＤセッション（又はミラキャストセッション）を構築し、ＷＦＤソースからＷＦＤシンクにビデオ／オーディオコンデンツをストリーミングすることができる。
【００７７】
一例として、図１３は、ＷＦＤセッション構築及びビデオ／オーディオストリーミング手順を説明する図である。
【００７８】
ＷＦＤソースは、トリガパラメータＳＥＴＵＰを含むＲＴＳＰ  Ｍ５要求メッセージ（ＲＴＳＰ  ＳＥＴ_ＰＡＲＡＭＥＴＥＲ要求メッセージ）をＷＦＤシンクに送信することができる。ＲＴＳＰ  Ｍ５要求メッセージを受信すると、ＷＦＤシンクは、ＲＴＳＰ  Ｍ５応答メッセージ（ＲＴＳＰ  ＳＥＴ_ＰＡＲＡＭＥＴＥＲ応答メッセージ）で応答することができる。
【００７９】
トリガパラメータＳＥＴＵＰを含むＲＴＳＰ  Ｍ５メッセージの交換に成功すると、ＷＦＤシンクは、ＲＴＳＰ  Ｍ６要求メッセージ（ＲＴＳＰ  ＳＥＴＵＰ要求メッセージ）をＷＦＤソースに送信することができる。ＲＴＳＰ  Ｍ６要求メッセージを受信すると、ＷＦＤソースは、ＲＴＳＰ  Ｍ６応答メッセージ（ＲＴＳＰ  ＳＥＴＵＰ応答メッセージ）で応答することができる。ＲＴＳＰ  Ｍ６応答メッセージの状態コードが「ＯＫ」を示す場合、ＲＴＳＰセッションの構築に成功したことを意味し得る。
【００８０】
ＲＴＳＰセッションが構築されると、ＷＦＤソースは、ＷＦＤシンクに、ＲＴＳＰ  ＰＬＡＹ要求メッセージ（ＲＴＳＰ  Ｍ７要求メッセージ）又はＲＴＳＰ  ＴＥＡＲＤＯＷＮ要求メッセージ（ＲＴＳＰ  Ｍ８要求メッセージ）の送信をトリガするための（送信のトリガとなる）（for triggering a transmission）ＲＴＳＰ  Ｍ５メッセージを送信し、ＷＦＤシンクは、ＷＦＤソースとＷＦＤシンクとの間のＲＴＳＰセッションを終了（tear down）するためのＲＴＳＰ  Ｍ８メッセージ（ＭＲＴＳＰ  ＴＥＡＲＤＯＷＮメッセージ）を送信することができる。
【００８１】
ＲＴＳＰ  Ｍ６メッセージの交換に成功した後、ＷＦＤシンクは、ＲＴＰストリームを受信する準備ができたことを知らせるために、ＲＴＳＰ  Ｍ７要求メッセージ（ＲＴＳＰ  ＰＬＡＹ要求メッセージ）をＷＦＤソースに送信することができる。ＷＦＤソースは、ＲＴＳＰ  Ｍ７応答メッセージ（ＲＴＳＰ  ＰＬＡＹ応答メッセージ）で応答することができる。ＲＴＳＰ  Ｍ７応答メッセージの状態コードが「ＯＫ」を示す場合、ＷＦＤセッションの構築に成功したことを意味し得る。
【００８２】
ＷＦＤセッションが構築されると、ＷＦＤソースは、ＷＦＤシンクに、ＷＦＤシンクでサポートする少なくとも１つのＲＴＳＰパラメータに関する能力を取得するためのＲＴＳＰ  Ｍ３要求メッセージ（ＲＴＳＰ  ＧＥＴ_ＰＡＲＡＭＥＴＥＲ要求メッセージ）、ＡＶ（Audio/Video）フォーマットの更新のためのＷＦＤソースとＷＦＤシンクとの間の能力再交渉のために、ＷＦＤセッションに対応する少なくとも１つのＲＴＳＰパラメータ値を設定するためのＲＴＳＰ  Ｍ４要求メッセージ、ＷＦＤシンクがＲＴＳＰ  ＰＡＵＳＥ要求メッセージ（ＲＴＳＰ  Ｍ９要求メッセージ）を送信するようにトリガする（送信するトリガとなる）ＲＴＳＰ  Ｍ５要求メッセージ、ＷＦＤソースがＷＦＤ待機モード（Standby mode）に入る（進入する）（enter）ことを指示するＲＴＳＰ  Ｍ１２要求メッセージ、ＵＩＢＣで使用される入力タイプ、入力デバイス及び他のパラメータを選択するためのＲＴＳＰ  Ｍ１４要求メッセージ、又はＵＩＢＣをイネーブル（動作可能）（enable）又はディセーブル（動作不能）（disable）にするためのＲＴＳＰ  Ｍ１５要求メッセージなどをＷＦＤシンクに送信することができる。
【００８３】
ＷＦＤソースから上記列挙されたＲＴＳＰ要求メッセージを受信したＷＦＤシンクは、ＲＴＳＰ応答メッセージで応答することができる。
【００８４】
ＷＦＤセッションが構築されると、ＷＦＤシンクは、一時中断（停止）された（paused）オーディオ／ビデオストリーミングを開始（又は再開）するためのＲＴＳＰ  Ｍ７要求メッセージ（ＲＴＳＰ  ＰＬＡＹ要求メッセージ）、ＷＦＤソースからＷＦＤシンクへのオーディオ／ビデオストリーミングの一時中断のためのＲＴＳＰ  Ｍ９要求メッセージ（ＲＴＳＰ  ＰＡＵＳＥ要求メッセージ）、ＷＦＤソースにオーディオレンダリングデバイスを変更することを要求するためのＲＴＳＰ  Ｍ１０要求メッセージ、活性コネクタタイプ（active connector type）の変更を指示するＲＴＳＰ  Ｍ１１要求メッセージ、ＷＦＤシンクがＷＦＤ待機モードに入ったことを指示するＲＴＳＰ  Ｍ１２要求メッセージ、ＷＦＤソースにＩＤＲをリフレッシュすることを要求するＭ１３要求メッセージ、ＵＩＢＣで使用される入力タイプ、入力デバイス及び他のパラメータを選択するためのＲＴＳＰ  Ｍ１４要求メッセージ、又はＵＩＢＣをイネーブル（enable）又はディセーブル（disable）にするためのＲＴＳＰ  Ｍ１５要求メッセージなどをＷＦＤソースに送信することができる。
【００８５】
ＷＦＤシンクから上記列挙されたＲＴＳＰ要求メッセージを受信したＷＦＤソースは、ＲＴＳＰ応答メッセージで応答することができる。
【００８６】
ＷＦＤセッションが構築され、オーディオ／ビデオストリーミングが開始されると、ＷＦＤソース及びＷＦＤシンクは、両者が共通にサポートするコーデックを用いてオーディオ／ビデオストリーミングを行うことができる。ＷＦＤソースとＷＦＤシンクとが共通にサポートするコーデックを用いることによって、両者間の相互運用性（interoperability）を保証する（secure）ことができる。
【００８７】
一例として、ＷＦＤシンク及びＷＦＤソースがいずれもＬＰＣＭ（Linear PCM（Pulse Code Modulation）  Audio）コーデック及びＨ．２６４コーデックをサポートする場合、オーディオ及びビデオは、それぞれＬＰＣＭコーデック及びＨ．２６４コーデックを介してストリーミングされ得る。ＬＰＣＭコーデック及びＨ．２６４コーデック以外のコーデックをオーディオ／ビデオストリーミングのために使用できることは勿論である。
【００８８】
以下では、説明の便宜上、ＷＦＤシンクとＷＦＤソースとが共通にサポートするオーディオ／ビデオコーデックを「共通コーデック」と呼ぶことにする。
【００８９】
ＷＦＤセッションを介したストリーミングを行う際に、一般に、ＷＦＤソースは、自体のリアルタイム再生画面を共通コーデックでエンコードした後、エンコードされたデータをＷＦＤシンクに送信する。ビデオファイルをストリーミングする場合においても、ＷＦＤソースは、ビデオファイルをデコードして、ビデオファイルの再生画面（play screen）をディスプレイ部上に出力した後、ディスプレイ部の出力を共通コーデックでエンコードし、エンコードされたデータをシンクに送信する。
【００９０】
すなわち、音楽ファイル又はビデオファイルなどのマルチメディアファイルのストリーミングを行うために、ＷＦＤソースは、まず、マルチメディアファイルをデコードした後、デコードされたデータを共通コーデックでエンコードするコード変換（Transcoding）を行うことができる。
【００９１】
ただし、ストリーミングしようとするマルチメディアファイルがＷＦＤシンクで再生可能なであれば、ＷＦＤソースがマルチメディアファイルをコード変換する手順を省略して、マルチメディアファイルを送信することがより効率的であり得る。
【００９２】
一例として、表１は、Ｈ．２６４でエンコードされた１０８０ｐの解像度のビデオファイルをストリーミングするとき、コード変換が行われるか否かによる効果を比較する表である。
【００９３】
【表１】
2017512332.tif 000003
【００９４】
コード変換を行わずにストリーミングを行う場合、マルチメディアファイルのデコーディング及びエンコーディングにかかる時間だけ送信遅延（ディレイ）が減少すると同時に、ＷＦＤソースの過熱（Overheat）を抑制し、ＷＦＤソースの電力効率が増加する効果が得られる。
【００９５】
そこで、本発明では、ＷＦＤサービス中、マルチメディアファイルのコード変換を行わずにマルチメディアファイルがストリーミングされる方法について提案する。
【００９６】
ＷＦＤでのモード遷移（Mode Transition）
ＷＦＤセッションが構築されると、ＷＦＤソースは、自体のリアルタイム出力画面を共通コーデックでエンコードした後、エンコードされたデータをＷＦＤシンクに送信することができる。このとき、ＷＦＤシンクで再生（playback）できるマルチメディアファイルの再生（play）が要求されると、マルチメディアファイルのコード変換（即ち、共通コーデックで変換）を行う代わりに、再生が要求されたマルチメディアファイルをＷＦＤシンクに送信することができる。
【００９７】
すなわち、ＷＦＤサービスの間、ＷＦＤソース及びＷＦＤシンクは、ＷＦＤソースのリアルタイム出力画面をストリーミングするリアルタイムエンコーディングモード（Real-time encoded Mode）下で動作することもでき、コード変換を行わずにマルチメディアファイルをストリーミングする非コード変換モード（Non-Transcoded Mode）下で動作することもできる。
【００９８】
ＷＦＤソース及びＷＦＤシンクのうちの少なくとも１つは、再生が要求されるマルチメディアファイルの属性に応じて、リアルタイムエンコーディングモードと非コード変換モードとの間の切り替えを要求することができる。
【００９９】
図１４は、リアルタイムエンコーディングモードと非コード変換モードとの間の切り替えが行われる例を説明する図である。デバイス探索及びサービス探索手順、能力交渉手順が行われることによって、ＷＦＤセッションが生成されると、ＷＦＤソース及びＷＦＤシンクは、リアルタイムエンコーディングモード下でストリーミングを行うことができる。すなわち、ＷＦＤソースが自体のリアルタイム出力画面を共通コーデックでエンコードしてＷＦＤシンクに送信すると、ＷＦＤシンクは、ＷＦＤソースから受信したエンコーディングデータを共通コーデックでデコードして出力することができる。
【０１００】
その後、マルチメディアファイルの再生を要求するユーザ入力を受信すると、ＷＦＤソースは、再生が要求されたマルチメディアファイルがＷＦＤシンクで再生可能であるか否かを判断することができる。具体的には、ＷＦＤソースは、ＷＦＤシンクがサポートするコーデック情報に基づいて、再生が要求されたマルチメディアファイルがＷＦＤシンクで再生可能であるか否かを判断することができる。一例として、そのために、ＷＦＤソースは、上記図１１で説明したＷＦＤサービス探索手順又はＷＦＤ能力交渉手順で、ＷＦＤシンクがサポートするビデオ及びオーディオコーデック情報を取得することができる。再生が要求されたマルチメディアファイルがビデオファイルである場合、ＷＦＤソースは、追加でコーデックのプロファイル及びレベル情報をさらに考慮して、マルチメディアファイルがＷＦＤシンクで再生可能であるか否かを判断することもできる。
【０１０１】
再生が要求されたマルチメディアファイルがＷＦＤシンクで再生可能である場合、ＷＦＤソースは、ＷＦＤシンクに、リアルタイムエンコーディングモードから非コード変換モードに切り替える（switch）ことを要求することができる。ＷＦＤシンクがＷＦＤソースの動作モード変更要求を受諾すると、ＷＦＤソースはＷＦＤシンクにマルチメディアファイルを送信することができる。
【０１０２】
図１５は、ＷＦＤソースとＷＦＤシンクとの間の動作モードがリアルタイムエンコーディングモードから非コード変換モードに変更される具体的な例を示した図である。
【０１０３】
リアルタイムエンコーディングモードで動作中、マルチメディアファイルの再生を要求するユーザ入力を受信すると、ＷＦＤソースは、再生が要求されたマルチメディアファイルがＷＦＤシンクで再生可能なものであるか否かを判断することができる。
【０１０４】
再生が要求されたマルチメディアファイルがＷＦＤシンクで再生できない場合（例えば、マルチメディアファイルがＷＦＤシンクでサポートしないコーデックで圧縮されていたり、マルチメディアファイルがＷＦＤシンクでサポートしない解像度を有する場合）、ＷＦＤソースは、コード変換を経てマルチメディアファイルをストリーミングすることができる。すなわち、ＷＦＤソースは、マルチメディアファイルをデコードし、デコードされたデータを共通コーデックでエンコードした後、エンコードされたデータをＷＦＤシンクに送信することができる。
【０１０５】
これとは異なり、再生が要求されたマルチメディアファイルがＷＦＤシンクで再生できる場合、ＷＦＤソースは、モード変更を要求するＲＴＳＰ  Ｍ５要求メッセージを送信することができる。そのために、ＷＦＤソースとＷＦＤシンクとの間では、モード切り替えをトリガする「モード遷移（ＭＯＤＥ_ＴＲＡＳＩＴ）」という新（新しい）メソッド（new method）が定義され得る。
【０１０６】
モード遷移メソッドを含むＲＴＳＰ  Ｍ５要求メッセージを受信したＷＦＤシンクは、ＲＴＳＰ  Ｍ５応答メッセージで応答し、リアルタイムストリーミングを一時中断するＲＳＴＰ  Ｍ９要求メッセージ（ＲＴＳＰ  ＰＡＵＳＥ要求メッセージ）をＷＦＤソースに送信することができる。
【０１０７】
ＲＴＳＰ  Ｍ９要求メッセージを受信すると、ＷＦＤソースは、ＲＴＳＰ  Ｍ９応答メッセージで応答し、リアルタイムストリーミングを一時中断（即ち、ＷＦＤソースのリアルタイム出力画面をストリーミングすることを一時中断）することができる。リアルタイムストリーミングが一時中断されると、ＷＦＤソースは、非コード変換モードに切り替わることによって変更されるパラメータを知らせるためのＲＴＳＰ  Ｍ４要求メッセージ（ＲＴＳＰ  ＳＥＴ_ＰＡＲＡＭＥＴＥＲ要求メッセージ）をＷＦＤシンクに送信することができる。ＲＴＳＰ  Ｍ４要求メッセージには、マルチメディアファイルのコーデック及びマルチメディアファイルを送信するのに用いられる送信プロトコル（ＴＣＰ／ＵＤＰなど）の情報が含まれてもよい。
【０１０８】
ＲＴＳＰ  Ｍ４要求メッセージを受信すると、ＷＦＤシンクは、ＲＴＳＰ  Ｍ４応答メッセージで応答することができる。その後、ＷＦＤシンクは、マルチメディアファイルの送信開始を要求するＲＴＳＰ  Ｍ７要求メッセージ（ＲＴＳＰ  ＰＬＡＹ要求メッセージ）をＷＦＤソースに送信することができる。
【０１０９】
ＲＴＳＰ  Ｍ７メッセージを受信すると、ＷＦＤソースは、ＲＴＳＰ  Ｍ７応答メッセージで応答し、非コード変換モード下でマルチメディアファイルをＷＦＤシンクに送信することができる。すなわち、ＷＦＤソースは、コード変換を行わずに、ＷＦＤシンクにマルチメディアファイルをストリーミングすることができる。
【０１１０】
非コード変換モード下でストリーミングされているマルチメディアファイルの再生が終了したり、マルチメディアファイルの再生終了を要求するユーザ入力を受信したりした場合、ＷＦＤソースは、ＷＦＤシンクに、非コード変換モードからリアルタイムエンコーディングモードに切り替えることを要求することができる。ＷＦＤシンクがＷＦＤソースの動作モード変更要求を受諾すると、ＷＦＤソースは、リアルタイム動作モード下でストリーミングを行うことができる。
【０１１１】
図１６は、ＷＦＤソースとＷＦＤシンクとの間の動作モードが非コード変換モードからリアルタイムエンコーディングモードに変更される例を示した図である。
【０１１２】
非コード変換モード下でストリーミングされているマルチメディアファイルの再生が終了したり、マルチメディアファイルの再生終了を要求するユーザ入力を受信したりした場合、ＷＦＤソースは、モード遷移メソッドを含むＲＴＳＰ  Ｍ５要求メッセージをＷＦＤシンクに送信することができる。モード遷移メソッドを含むＲＴＳＰ  Ｍ５要求メッセージを受信したＷＦＤシンクは、ＲＴＳＰ  Ｍ５応答メッセージで応答し、ストリーミングを一時中断するＲＳＴＰ  Ｍ９要求メッセージ（ＲＴＳＰ  ＰＡＵＳＥ要求メッセージ）をＷＦＤソースに送信することができる。
【０１１３】
ＲＴＳＰ  Ｍ９要求メッセージを受信すると、ＷＦＤソースは、ＲＴＳＰ  Ｍ９応答メッセージで応答し、ストリーミングを一時中断することができる。ストリーミングが一時中断されると、ＷＦＤソースは、リアルタイムエンコーディングモードに切り替わることによって変更されるパラメータを知らせるためのＲＴＳＰ  Ｍ４要求メッセージ（ＲＴＳＰ  ＳＥＴ_ＰＡＲＡＭＥＴＥＲ要求メッセージ）をＷＦＤシンクに送信することができる。ＲＴＳＰ  Ｍ４要求メッセージには、リアルタイムエンコーディングモード下で用いられるコーデック情報などが含まれてもよい。
【０１１４】
ＲＴＳＰ  Ｍ４要求メッセージを受信すると、ＷＦＤシンクは、ＲＴＳＰ  Ｍ４応答メッセージで応答することができる。その後、ＷＦＤシンクは、リアルタイムストリーミングの開始を要求するＲＴＳＰ  Ｍ７要求メッセージ（ＲＴＳＰ  ＰＬＡＹ要求メッセージ）をＷＦＤソースに送信することができる。
【０１１５】
ＲＴＳＰ  Ｍ７メッセージを受信すると、ＷＦＤソースは、ＲＴＳＰ  Ｍ７応答メッセージで応答し、リアルタイムエンコーディングモード下でオーディオ／ビデオデータを共通コーデックでエンコードし、エンコードされたオーディオ／ビデオデータをＷＦＤシンクに送信して、ストリーミングを行うことができる。
【０１１６】
ＷＦＤソースは、ＷＦＤシンクとのＷＦＤ能力交渉手順あるいはＷＦＤサービス探索手順で、ＷＦＤシンクがリアルタイムエンコーディングモードから非コード変換モードへのモード切り替えをサポートするか否かを確認することができる。
【０１１７】
具体的には、ＷＦＤソースは、ＲＴＳＰ  Ｍ３メッセージ及びＲＴＳＰ  Ｍ４メッセージのうちの少なくとも１つの交換を通じて、ＷＦＤシンクがモード切り替えをサポートするか否かを確認することができる。
【０１１８】
一例として、ＲＴＳＰ  Ｍ３メッセージ及びＲＴＳＰ  Ｍ４メッセージのうちの少なくとも１つには、ＷＦＤシンクがモード切り替えをサポートするか否かを問い合わせる（問う）（querying）新しいＲＴＳＰパラメータ（ｗｆｄ_ｍｏｄｅ_ｔｒａｎｓｉｔｉｏｎ）が挿入されてもよい。
【０１１９】
サービスハンドオーバ
ＷＦＤセッションが構築されると、ＷＦＤソースは、自体のリアルタイム出力画面を共通コーデックでエンコードした後、エンコードされたデータをＷＦＤシンクに送信することができる。このとき、ＷＦＤシンクで再生できるマルチメディアファイルの再生が要求されると、マルチメディアファイルのコード変換（即ち、共通コーデックで変換）を行う代わりに、再生が要求されたマルチメディアファイルをＷＦＤシンクに送信することができる。
【０１２０】
そのために、ＷＦＤソース及びＷＦＤシンクは、ＷＦＤサービスを一時中断し、ファイル送信が可能なサービスにハンドオーバ（handover）する（引き渡す）ことができる。具体的には、ＷＦＤソース及びＷＦＤシンクは、ファイル送信が可能なＤＮＬＡ（Digital Living Network Alliance）又はワイファイダイレクトサービス（ＷＦＤＳ）中、プレイ（ＰＬＡＹ）サービスにハンドオーバを行うことができる。
【０１２１】
図１７は、ＷＦＤサービスからＤＮＬＡにハンドオーバが行われる例を説明する図である。デバイス探索及びサービス探索手順、能力交渉手順が行われることによって、ＷＦＤセッションが生成されると、ＷＦＤソースは、自体のリアルタイム出力画面を共通コーデックでエンコードしてＷＦＤシンクに送信することができる。ＷＦＤシンクは、ＷＦＤソースから受信したエンコーディングデータを共通コーデックでデコードすることによって、ストリーミングを行うことができる。
【０１２２】
その後、マルチメディアファイルの再生を要求するユーザ入力を受信すると、ＷＦＤソースは、再生が要求されたマルチメディアファイルがＷＦＤシンクで再生可能であるか否かを判断することができる。具体的には、ＷＦＤソースは、ＷＦＤシンクがサポートするコーデック情報に基づいて、再生が要求されたマルチメディアファイルがＷＦＤシンクで再生可能であるか否かを判断することができる。再生が要求されたマルチメディアファイルがビデオファイルである場合、ＷＦＤソースは、ＷＦＤシンクが再生できる動画のコーデック以外に、追加でコーデックのプロファイル及びレベル情報をさらに考慮して、マルチメディアファイルがＷＦＤシンクで再生可能であるか否かを判断することができる。
【０１２３】
再生が要求されたマルチメディアファイルがＷＦＤシンクで再生可能なものである場合、ＷＦＤソースはＷＦＤシンクにサービスハンドオーバを要求することができる。
【０１２４】
ＷＦＤサービスがＷＦＤＳプレイサービス又はＤＮＬＡに切り替わると、ＷＦＤソースは、コード変換を行わずにＷＦＤシンクにマルチメディアファイルをストリーミングすることができる。
【０１２５】
図１８は、ＷＦＤサービスが中断され、ＤＮＬＡが開始される例を示した図である。
【０１２６】
ＷＦＤソースがＷＦＤシンクに対してリアルタイムストリーミングを実行中に、マルチメディアファイルの再生を要求するユーザ入力を受信すると、ＷＦＤソースは、再生が要求されたマルチメディアファイルがＷＦＤシンクで再生可能なものであるか否かを判断することができる。
【０１２７】
再生が要求されたマルチメディアファイルがＷＦＤシンクで再生できない場合であれば（例えば、マルチメディアファイルがＷＦＤシンクでサポートしないコーデックで圧縮されていたり、マルチメディアファイルがＷＦＤシンクでサポートしない解像度を有する場合）、ＷＦＤソースは、ＷＦＤサービス下でマルチメディアファイルのコード変換を経てＷＦＤシンクに、共通コーデックを使用したストリーミングを行うことができる。
【０１２８】
これとは異なり、再生が要求されたマルチメディアファイルがＷＦＤシンクで再生できる場合であれば、ＷＦＤソースは、ＤＮＬＡへの切り替えを要求するＲＴＳＰ  Ｍ５要求メッセージを送信することができる。そのために、ＷＦＤソースとＷＦＤシンクとの間では、ＤＮＬＡへの切り替えをトリガする「ＤＮＬＡ遷移（ＴＲＡＮＳＩＴ_ＤＬＮＡ）」という新メソッドが定義され得る。
【０１２９】
ＤＮＬＡ遷移メソッドを含むＲＴＳＰ  Ｍ５要求メッセージを受信したＷＦＤシンクは、Ｍ５応答メッセージで応答し、リアルタイムストリーミングを一時中断するＲＳＴＰ  Ｍ９要求メッセージ（ＲＴＳＰ  ＰＡＵＳＥ要求メッセージ）をＷＦＤソースに送信することができる。
【０１３０】
ＲＴＳＰ  Ｍ９要求メッセージを受信すると、ＷＦＤソースは、ＲＴＳＰ  Ｍ９応答メッセージで応答し、リアルタイムストリーミングを一時中断することができる。リアルタイムストリーミングが一時中断されると、ＷＦＤソースは、ＤＮＬＡを活性化し、ＤＮＬＡ制御プロトコルであるＨＴＴＰ／ＳＯＡＰのＰＬＡＹアクションを通じて、コード変換を行わずに、マルチメディアコンテンツをＷＦＤシンクにストリーミングすることができる。
【０１３１】
その後、ＤＮＬＡ下でストリーミングされているマルチメディアファイルの再生が終了したり、マルチメディアファイルの再生終了を要求するユーザ入力を受信したりした場合、ＷＦＤソースは、ＷＦＤシンクに、ＤＮＬＡサービスからＷＦＤサービスに切り替えることを要求することができる。
【０１３２】
図１９は、ＷＦＤサービスが再開される例を示した図である。ＤＮＬＡ下でストリーミングされているマルチメディアファイルの再生が終了したり、マルチメディアファイルの再生終了を要求するユーザ入力を受信したりした場合、ＷＦＤソースは、ＷＦＤサービスへの切り替えを要求するためのＲＴＳＰ  Ｍ５要求メッセージをＷＦＤシンクに送信することができる。そのために、ＷＦＤソースとＷＦＤシンクとの間では、ＷＦＤサービスへの切り替えをトリガする「ＷＦＤ遷移（ＴＲＡＮＳＩＴ_ＷＦＤ）」という新メソッドが定義され得る。
【０１３３】
ＷＦＤ遷移メソッドを含むＲＴＳＰ  Ｍ５要求メッセージを受信したＷＦＤシンクは、Ｍ５応答メッセージで応答し、ＷＦＤ  Ｍ５メッセージの交換によって一時中断されていたリアルタイムストリーミングを再開するためのＲＳＴＰ  Ｍ７要求メッセージ（ＲＴＳＰ  ＰＬＡＹ要求メッセージ）をＷＦＤソースに送信することができる。
【０１３４】
ＲＴＳＰ  Ｍ７要求メッセージを受信したＷＦＤソースは、ＲＴＳＰ  Ｍ７応答メッセージで応答し、ＷＦＤサービス下でリアルタイムストリーミングを再開することができる。
【０１３５】
ＷＦＤソースは、ＷＦＤシンクとの能力交渉手順あるいはＷＦＤサービス探索手順で、ＷＦＤシンクがＷＦＤサービスからＤＮＬＡへの切り替えをサポートするか否かを確認することができる。
【０１３６】
具体的には、ＷＦＤソースは、ＲＴＳＰ  Ｍ３メッセージ及びＲＴＳＰ  Ｍ４メッセージのうちの少なくとも１つの交換を通じて、ＷＦＤシンクがＷＦＤサービスからＤＮＬＡへの切り替えをサポートするか否かを確認することができる。
【０１３７】
一例として、ＲＴＳＰ  Ｍ３メッセージ及びＲＴＳＰ  Ｍ４メッセージのうちの少なくとも１つには、ＷＦＤシンクがＷＦＤサービスからＤＮＬＡへと切り替え可能な能力を有するか否かを問う新しいＲＴＳＰパラメータ‘ｗｆｄ_ｍｏｄｅ_ｔｒａｎｓｉｔｉｏｎ’が挿入されてもよい。下記の表２は、ｗｆｄ_ｍｏｄｅ_ｔｒａｎｓｉｔｉｏｎパラメータを説明する表である。
【０１３８】
【表２】
2017512332.tif 000004
【０１３９】
上記表２を参照すると、ＷＦＤソースは、ＷＦＤシンクがＷＦＤサービスからＤＮＬＡへと切り替え可能な能力を有するか否かを問うために、ｗｆｄ_ｍｏｄｅ_ｔｒａｎｓｉｔｉｏｎパラメータを使用することができる。
【０１４０】
対応する能力を有しているＷＦＤシンクは、３２＊３２  ＨＥＸＤＩＧのユニーク（一意の）ユーザ識別情報リスト（Unique User Identifier (Universally Unique Identifier)-List；ＵＵＩＤ−ＬＩＳＴ）で応答することができ、対応する能力を有していないＷＦＤシンクは、“ｎｏｎｅ”として応答することができる。
【０１４１】
図２０Ａ及び図２０Ｂは、能力交渉手順において、ＷＦＤシンクがＷＦＤサービスからＤＮＬＡへと切り替え可能な能力を有するか否かを確認する過程を説明する図である。
【０１４２】
ＲＴＳＰ  Ｍ１及びＲＴＳＰ  Ｍ２メッセージの交換に成功した後、ＷＦＤソースは、取得しようとする能力のリストを明示したＲＴＳＰ  Ｍ３要求メッセージをＷＦＤシンクに送信することができる。図２０Ａを参照すると、ＲＴＳＰ  Ｍ３要求メッセージには、ＷＦＤシンクがサポートするビデオフォーマットを確認するためのパラメータ（ｗｆｄ_ｖｉｄｅｏ  ｆｏｒｍａｔｓ）、ＷＦＤシンクがサポートするオーディオコーデックを確認するためのパラメータ（ｗｆｄ_ａｕｄｉｏ_ｃｏｄｅｃｓ）、ＲＴＰに使用されるＷＦＤシンクのポート番号を確認するためのパラメータ（ｗｆｄ_ｃｌｉｅｎｔ_ｒｔｐ_ｐｏｒｔｓ）及びＷＦＤシンクがサービス切り替えをサポートするか否かを確認するためのパラメータ（ｗｆｄ_ｍｏｄｅ_ｔｒａｎｓｉｔｉｏｎ）が含まれた場合が例示される。
【０１４３】
ＲＴＳＰ  Ｍ３要求メッセージを受信したＷＦＤシンクは、ＲＴＳＰ  Ｍ３応答メッセージによって、ＷＦＤソースが要求するＷＦＤ能力を応答することができる。図２０Ａには、ＷＦＤシンクがＲＴＳＰ  Ｍ３要求メッセージに対する応答として、自体がサポートするビデオフォーマット、自体がサポートするオーディオコーデック、ＲＴＰに使用されるポート番号、及びサービス切り替えをサポートするか否かに対する能力を含むＲＴＳＰ  Ｍ３応答メッセージを送信する場合が例示された。
【０１４４】
このとき、ＷＦＤサービスからＤＬＮＡへの切り替えをサポートする場合、ＷＦＤシンクは、自体のＤＬＮＡ  ＵＵＩＤが含まれるようにＲＴＳＰ  Ｍ３応答メッセージを構成することができる。反対に、ＷＦＤサービスからＤＬＮＡへの切り替えをサポートしない場合、ＷＦＤシンクは、ＷＦＤサービスからＤＬＮＡへの切り替えをサポートしないという意味の文字列（例えば、“ｎｏｎｅ”）が含まれるようにＲＴＳＰ  Ｍ３応答メッセージを構成することができる。
【０１４５】
ＲＴＳＰ  Ｍ３メッセージの交換に成功し、これによってＷＦＤシンクの能力が確認されると、ＷＦＤソースは、ＷＦＤセッションの間にＷＦＤソースとＷＦＤシンクとの間で使用されるパラメータセットを決定することができる。一例として、図２０Ａには、ＲＴＳＰ  Ｍ４要求メッセージが、ＷＦＤセッションの間に使用されるビデオフォーマットを確認するためのパラメータ（ｗｆｄ_ｖｉｄｅｏ  ｆｏｒｍａｔｓ）、ＷＦＤセッションの間に使用されるオーディオコーデックを確認するためのパラメータ（ｗｆｄ_ａｕｄｉｏ_ｃｏｄｅｃｓ）及びＷＦＤセッションの間にＲＴＰに使用されるＷＦＤシンクのポート番号を確認するためのパラメータ（ｗｆｄ_ｃｌｉｅｎｔ_ｒｔｐ_ｐｏｒｔｓ）を含む場合が例示される。
【０１４６】
さらに、ＲＴＳＰ  Ｍ３メッセージの交換を通じて、ＷＦＤシンクがＷＦＤサービスからＤＬＮＡへの切り替えをサポートする能力を有していると確認されると、ＷＦＤソースは、自体のＤＬＮＡ  ＵＵＩＤが含まれるようにＲＴＳＰ  Ｍ４要求メッセージを構成することができる。図２０Ａには、ＲＴＳＰ  Ｍ４要求メッセージが、ＷＦＤソースのＤＬＮＡ  ＵＵＩＤを確認するためのパラメータ（ｗｆｄ_ｍｏｄｅ_ｔｒａｎｓｉｔｉｏｎ）を含む場合が例示された。
【０１４７】
ＷＦＤソースからＲＴＳＰ  Ｍ４要求メッセージを受信したＷＦＤシンクは、ＲＴＳＰ  Ｍ４応答メッセージで応答することができる。ＲＴＳＰ  Ｍ４メッセージの交換に成功すると、ＷＦＤソースとＷＦＤシンクとの間にはＷＦＤセッションが生成され、図１７乃至図１９を参照して説明したストリーミング動作が行われ得る。
【０１４８】
図１７乃至図２０では、ＷＦＤソース及びＷＦＤシンクがＷＦＤサービスを一時中断し、ＤＬＮＡを開始することができる場合が例示された。ＷＦＤソース及びＷＦＤシンクは、ＷＦＤサービスを一時中断し、ＤＬＮＡを開始する代わりに、ＷＦＤサービスを一時中断し、ＷＦＤＳにおけるプレイ（Ｐｌａｙ）サービス（play service in WFDS）を開始することもできる。
【０１４９】
図２１は、本発明の一実施例に係る無線デバイスの構成を示すブロック図である。
【０１５０】
無線デバイス１０は、ディスプレイ部１１、メモリ１２、送受信器１３及びプロセッサ１４を含むことができる。送受信器１３は、無線信号を送信／受信することができ、例えば、ＩＥＥＥ  ８０２システムによる物理層を実現することができる。ディスプレイ部１１は、情報を出力する役割を果たす。ＷＦＤソースは、ディスプレイ部１１に出力される情報を共通コーデックでエンコードすることができ、ＷＦＤシンクは、ＷＦＤソースから受信したデータをデコードしてディスプレイ部１１に出力することができる。
【０１５１】
プロセッサ１４は、送受信器１３と電気的に接続され、ＩＥＥＥ  ８０２システムによる物理層及び／又はＭＡＣ層を実現することができる。また、プロセッサ１４は、ＷＦＤサービスのためのオーディオ／ビデオのエンコーディング及びデコーディングの動作を行うように構成されてもよい。また、前述した本発明の様々な実施例に係る無線デバイスの動作を実現するモジュールがメモリ１２に格納され、プロセッサ１４によって実行されてもよい。メモリ１２は、プロセッサ１４の内部に含まれてもよく、プロセッサ１４の外部に設けられ、プロセッサ１４と公知の手段によって接続されてもよい。図示していないが、無線デバイス１０は、音響を出力するための音響出力部をさらに含むことができる。
【０１５２】
図２１の無線デバイス１０の具体的な構成は、前述した本発明の様々な実施例で説明した事項が独立して適用されたり、又は２つ以上の実施例が同時に適用されるように実現されてもよく、重複する内容は明確性のために説明を省略する。
【０１５３】
上述した本発明の実施例は、様々な手段を通じて具現することができる。例えば、本発明の実施例は、ハードウェア、ファームウェア（firmware）、ソフトウェア又はそれらの結合（組み合わせ）（combinations）などにより具現されてもよい。
【０１５４】
ハードウェアによる具現の場合、本発明の実施例に係る方法は、一つ又はそれ以上のＡＳＩＣｓ（Application Specific Integrated Circuits）、ＤＳＰｓ（Digital Signal Processors）、ＤＳＰＤｓ（Digital Signal Processing Devices）、ＰＬＤｓ（Programmable Logic Devices）、ＦＰＧＡｓ（Field Programmable Gate Arrays）、プロセッサ、コントローラ、マイクロコントローラ、マイクロプロセッサなどによって実現されてもよい。
【０１５５】
ファームウェアやソフトウェアによる具現の場合、本発明の実施例に係る方法は、以上で説明した機能又は動作を実行するモジュール、手順又は関数などの形態で具現することができる。ソフトウェアコードはメモリユニットに格納され、プロセッサによって駆動されてもよい。上記メモリユニットは、上記プロセッサの内部又は外部に設けられ、公知の様々な手段によってプロセッサとデータを交換（授受）する（exchange）ことができる。
【０１５６】
上述したように開示された本発明の好適な実施形態に関する詳細な説明は、当業者が本発明を具現し、実施できるように提供されている。以上では、本発明の好適な実施形態を参照して説明したが、当該技術分野における熟練した当業者は、以下の特許請求の範囲に記載された本発明の思想及び領域から逸脱しない範囲内で本発明を様々に修正及び変更させることができるということが理解できる。したがって、本発明は、ここに開示された実施形態に制限されるものではなく、ここに開示された原理及び新しい特徴と一致する最も広い範囲を与えるためのものである。
【産業上の利用可能性】
【０１５７】
上述した本発明の様々な実施形態は、Ｗｉ−Ｆｉダイレクトシステムを中心に説明したが、様々な移動通信システムに同一の方式で適用可能である。
【図１】
2017512332.tif 000005
【図２】
2017512332.tif 000006
【図３】
2017512332.tif 000007
【図４】
2017512332.tif 000008
【図５】
2017512332.tif 000009
【図６】
2017512332.tif 000010
【図７】
2017512332.tif 000011
【図８】
2017512332.tif 000012
【図９】
2017512332.tif 000013
【図１０】
2017512332.tif 000014
【図１１】
2017512332.tif 000015
【図１２】
2017512332.tif 000016
【図１３】
2017512332.tif 000017
【図１４】
2017512332.tif 000018
【図１５】
2017512332.tif 000019
【図１６】
2017512332.tif 000020
【図１７】
2017512332.tif 000021
【図１８】
2017512332.tif 000022
【図１９】
2017512332.tif 000023
【図２０Ａ】
2017512332.tif 000024
【図２０Ｂ】
2017512332.tif 000025
【図２１】
2017512332.tif 000026
【手続補正書】
【提出日】平成28年8月5日(2016.8.5)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
第１無線デバイスでワイファイディスプレイ（ＷＦＤ）サービスを行う方法であって、前記第１無線デバイスが、
前記第１無線デバイスのリアルタイム出力画面を、前記第１無線デバイスと第２無線デバイスとが共通にサポートする共通コーデックでエンコードし、前記第２無線デバイスにストリーミングするステップと、
マルチメディアファイルの再生を開始するステップと、
前記マルチメディアファイルが前記第２無線デバイスで再生可能な場合、ストリーミングを前記リアルタイム出力画面から前記マルチメディアファイルに切り替えるステップと、を有する、ＷＦＤサービス実行方法。
【請求項２】
前記マルチメディアファイルが前記第２無線デバイスで再生可能な場合、前記第１無線デバイスは、前記マルチメディアファイルをコード変換せずに前記第２無線デバイスにストリーミングし、
前記マルチメディアファイルが前記第２無線デバイスで再生不可能な場合、前記第１無線デバイスは、前記マルチメディアファイルを前記共通コーデックでコード変換し、前記第２無線デバイスにストリーミングする、請求項１に記載のＷＦＤサービス実行方法。
【請求項３】
前記第１無線デバイスが前記ストリーミングを前記リアルタイム出力画面から前記マルチメディアファイルに切り替える場合、前記リアルタイム出力画面のストリーミングを中断し、前記第１無線デバイスが前記第２無線デバイスに前記マルチメディアファイルをストリーミングし、
前記マルチメディアファイルのストリーミングが中断される場合、前記中断されたリアルタイム出力画面のストリーミングを再開する、請求項１に記載のＷＦＤサービス実行方法。
【請求項４】
前記マルチメディアファイルが前記第２無線デバイスで再生可能な場合、前記第１無線デバイスが、前記第２無線デバイスに、前記リアルタイム出力画面をストリーミングするための前記第１動作モードから、前記マルチメディアファイルのストリーミングのための前記第２動作モードへの変更を要求するステップをさらに有する、請求項１に記載のＷＦＤサービス実行方法。
【請求項５】
前記第１無線デバイスは、前記第２無線デバイスから、前記第２無線デバイスが前記第１動作モードから前記第２動作モードへと変更可能な能力を有するか否かに関する情報を受信する、請求項４に記載のＷＦＤサービス実行方法。
【請求項６】
前記マルチメディアファイルが前記第２無線デバイスで再生可能な場合、前記第１無線デバイスが、前記第２無線デバイスに、前記リアルタイム出力画面をストリーミングするための前記ＷＦＤサービスから前記マルチメディアファイルをストリーミングするための所定のサービスへの切り替えを要求するステップをさらに有する、請求項１に記載のＷＦＤサービス実行方法。
【請求項７】
前記所定のサービスは、デジタルリビングネットワークアライアンス（ＤＬＮＡ（登録商標））及びプレイ（Ｐｌａｙ）サービスのいずれか１つである、請求項６に記載のＷＦＤサービス実行方法。
【請求項８】
前記第１無線デバイスは、前記第２無線デバイスから、前記第２無線デバイスが前記ＷＦＤサービスから前記ＤＬＮＡへと切り替え可能な能力を有するか否かに関する情報を受信する、請求項７に記載のＷＦＤサービス実行方法。
【請求項９】
前記情報は、前記第２無線デバイスのＤＬＮＡ  ユニークユーザ識別情報（ＵＵＩＤ）を有する、請求項８に記載のＷＦＤサービス実行方法。
【請求項１０】
前記情報を受信すると、前記第１無線デバイスは、前記第２無線デバイスに、前記第１無線デバイスのＤＬＮＡ  ＵＵＩＤを有するメッセージを送信する、請求項９に記載のＷＦＤサービス実行方法。
【請求項１１】
第１無線デバイスでワイファイディスプレイ（ＷＦＤ）サービスを行う方法であって、前記第１無線デバイスが、
前記第１無線デバイスと第２無線デバイスとが共通にサポートする共通コーデックでエンコードされた前記第２無線デバイスのリアルタイム出力画面を受信してストリーミングするステップと、
前記第２無線デバイスから、前記第１無線デバイスで再生可能なマルチメディアファイルのストリーミング要求を受信した場合、前記第２無線デバイスのストリーミングを前記リアルタイム出力画面から前記マルチメディアファイルに切り替えるステップと、を有する、ＷＦＤサービス実行方法。
【請求項１２】
ワイファイディスプレイ（ＷＦＤ）サービスを行う第１無線デバイスであって、
ディスプレイ部と、
送受信器と、
プロセッサと、を有し、
前記プロセッサは、
前記ディスプレイ部のリアルタイム出力画面を、前記第１無線デバイスと第２無線デバイスとが共通にサポートする共通コーデックでエンコードして、前記第２無線デバイスにストリーミングし、
マルチメディアファイルの再生を開始し、
前記マルチメディアファイルが前記第２無線デバイスで再生可能な場合、前記第２無線デバイスのストリーミングを前記リアルタイム出力画面から前記マルチメディアファイルに切り替える、ＷＦＤサービスの実行のための第１無線デバイス。
【請求項１３】
ワイファイディスプレイ（ＷＦＤ）サービスを行う第１無線デバイスであって、
ディスプレイ部と、
送受信器と、
プロセッサと、を有し、
前記プロセッサは、
前記第１無線デバイスと第２無線デバイスとが共通にサポートする共通コーデックでエンコードされた前記第２無線デバイスのリアルタイム出力画面を受信してストリーミングし、
前記第２無線デバイスを介して、前記第１無線デバイスで再生可能なマルチメディアファイルのストリーミング要求が受信されると、前記第２無線デバイスのストリーミングを前記リアルタイム出力画面から前記マルチメディアファイルに切り替える、ＷＦＤサービスの実行のための第１無線デバイス。
【国際調査報告】
2017512332.tif 000027
2017512332.tif 000028
2017512332.tif 000029
2017512332.tif 000030