特許 6422982 情報処理方法および装置

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】6422982

(24)【登録日】2018年10月26日

(45)【発行日】2018年11月14日

(54)【発明の名称】情報処理方法および装置

(51)【国際特許分類】

   H04N 21/436 20110101AFI20181105BHJP

   G06F 13/00 20060101ALI20181105BHJP

【ＦＩ】

   H04N21/436

   G06F13/00 510A

【請求項の数】11

【全頁数】22

(21)【出願番号】特願2016-543665(P2016-543665)

(86)(22)【出願日】2015年12月30日

(65)【公表番号】特表2018-503987(P2018-503987A)

(43)【公表日】2018年2月8日

(86)【国際出願番号】CN2015099972

(87)【国際公開番号】WO2017071095

(87)【国際公開日】20170504

【審査請求日】2016年6月29日

(31)【優先権主張番号】201510718289.5

(32)【優先日】2015年10月29日

(33)【優先権主張国】CN

(73)【特許権者】

【識別番号】513224180

【氏名又は名称】小米科技有限責任公司

【氏名又は名称原語表記】Ｘｉａｏｍｉ Ｉｎｃ．

(74)【代理人】

【識別番号】100107489

【弁理士】

【氏名又は名称】大塩 竹志

(72)【発明者】

【氏名】▲呉▼ 桂洲

(72)【発明者】

【氏名】李 虹

(72)【発明者】

【氏名】魏 先哲

【審査官】 冨田 高史

(56)【参考文献】

【文献】 米国特許出願公開第２０１５／０１７２７５７（ＵＳ，Ａ１）

【文献】 国際公開第２０１４／０８８３７８（ＷＯ，Ａ１）

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｈ０４Ｎ ２１／００ − ２１／８５８

Ｇ０６Ｆ １３／００

(57)【特許請求の範囲】

【請求項1】

情報処理方法であって、
無線ネットワークの伝送リンクを通してピアデバイスの画面共有要求を取得したかどうかを判断することと、
ピアデバイスの画面共有要求を受信した場合、前記ピアデバイスのＩＰアドレスおよび前記ピアデバイスのポート番号を取得することと、
前記ＩＰアドレスおよび前記ポート番号に基づいて、ピアデバイス画面を再生するためのメディアデータに対応するユニフォームリソースロケータ（ＵＲＬ）を生成することと、
前記ＵＲＬに対応する標準プレーヤを確定することと、
前記標準プレーヤを利用して前記ＵＲＬに対応するメディアデータを再生することと
を含む、情報処理方法。

【請求項2】

前記ＵＲＬに対応する標準プレーヤを確定することは、
デフォルトプレーヤを取得し、
前記デフォルトプレーヤが前記ＵＲＬに対応するフォーマットタイプをサポートするかどうかを判断し、
前記デフォルトプレーヤが前記ＵＲＬに対応するフォーマットタイプをサポートする場合、前記デフォルトプレーヤを前記ＵＲＬに対応する標準プレーヤとして確定し、
前記デフォルトプレーヤが前記ＵＲＬに対応するフォーマットタイプをサポートしない場合、前記デフォルトプレーヤを、前記ＵＲＬに対応するフォーマットタイプをサポートするプレーヤと、設定し、前記ＵＲＬに対応するフォーマットタイプをサポートする前記プレーヤを、前記ＵＲＬに対応する標準プレーヤとして確定することを含むことを特徴とする、請求項１に記載の情報処理方法。

【請求項3】

前記ＵＲＬに対応する標準プレーヤを確定することは、
標準プレーヤを作成し
前記標準プレーヤが前記ＵＲＬに対応するフォーマットタイプをサポートするかどうかを判断し、
前記標準プレーヤが前記ＵＲＬに対応するフォーマットタイプをサポートする場合、前記標準プレーヤを前記ＵＲＬに対応する標準プレーヤとして確定することを含むことを特徴とする、請求項１に記載の情報処理方法。

【請求項4】

ピアデバイスの画面共有要求を取得したかどうかを判断することは、
無線ピアツーピアネットワークＷｉＦｉ Ｐ２Ｐプロトコルにより前記ピアデバイスと通信接続を確立する場合、前記ピアデバイスとプリセットパラメータ情報を交換し、
前記プリセットパラメータ情報に基づいて、前記ピアデバイスとのネゴシエーションが成功したかどうかを判断し、
前記ピアデバイスとのネゴシエーションが成功した場合、前記ピアデバイスの画面共有要求を取得したことを確定し、
前記ピアデバイスとのネゴシエーションが失敗した場合、前記ピアデバイスの画面共有要求を取得しないことを確定することを含むことを特徴とする、請求項１に記載の情報処理方法。

【請求項5】

前記標準プレーヤを利用して前記ＵＲＬに対応するメディアデータを再生することは、
前記ＵＲＬに基づいて前記ピアデバイスにおける前記ＵＲＬに対応するメディアデータを取得し、
前記メディアデータをデコードし、
デコードされたメディアデータをレンダリングし、メディア再生データを取得し、
前記メディア再生データを前記標準プレーヤで再生することを含むことを特徴とする、 請求項１に記載の情報処理方法。

【請求項6】

情報処理装置であって、
無線ネットワークの伝送リンクを通してピアデバイスの画面共有要求を取得したかどうかを判断するように構成される要求判断ユニットと、
ピアデバイスの画面共有要求を受信した場合、前記ピアデバイスのＩＰアドレスおよび前記ピアデバイスのポート番号を取得するように構成される情報取得ユニットと、
前記ＩＰアドレスおよび前記ポート番号に基づいて、ピアデバイス画面を再生するためのメディアデータに対応するユニフォームリソースロケータ（ＵＲＬ）を生成するように構成されるＵＲＬ生成ユニットと、
前記ＵＲＬに対応する標準プレーヤを確定するように構成されるプレーヤ確定ユニットと、
前記標準プレーヤを利用して前記ＵＲＬに対応するメディアデータを再生するように構成されるメディアデータ再生ユニットと
を含む、情報処理装置。

【請求項7】

前記プレーヤ確定ユニットは、
デフォルトプレーヤを取得するように構成されるプレーヤ取得モジュールと、
前記デフォルトプレーヤが前記ＵＲＬに対応するフォーマットタイプをサポートするかどうかを判断するように構成される第１フォーマットタイプ判断モジュールと、
前記デフォルトプレーヤが前記ＵＲＬに対応するフォーマットタイプをサポートする場合、前記デフォルトプレーヤを前記ＵＲＬに対応する標準プレーヤとして確定するように構成される第１標準プレーヤ確定モジュールと、
前記デフォルトプレーヤが前記ＵＲＬに対応するフォーマットタイプをサポートしない場合、前記デフォルトプレーヤを、前記ＵＲＬに対応するフォーマットタイプをサポートするプレーヤと、設定するように構成される標準プレーヤ設定モジュールと、
前記ＵＲＬに対応するフォーマットタイプをサポートする前記プレーヤを前記ＵＲＬに対応する標準プレーヤとして確定するように構成される第２標準プレーヤ確定モジュールと
を含むことを特徴とする、請求項６に記載の情報処理装置。

【請求項8】

前記プレーヤ確定ユニットは、
標準プレーヤを作成するように構成される標準プレーヤ作成モジュールと、
前記標準プレーヤが前記ＵＲＬに対応するフォーマットタイプをサポートするかどうかを判断するように構成される第２フォーマットタイプ判断モジュールと、
前記標準プレーヤが前記ＵＲＬに対応するフォーマットタイプをサポートする場合、前記標準プレーヤを前記ＵＲＬに対応する標準プレーヤとして確定するように構成される第３標準プレーヤ確定モジュールと
を含むことを特徴とする、請求項６に記載の情報処理装置。

【請求項9】

前記要求判断ユニットは、
無線ピアツーピアネットワークＷｉＦｉ Ｐ２Ｐプロトコルにより前記ピアデバイスと通信接続を確立する場合、前記ピアデバイスとプリセットパラメータ情報を交換するように構成されるパラメータ情報交換モジュールと、
前記プリセットパラメータ情報に基づいて、前記ピアデバイスとのネゴシエーションが成功したかどうかを判断するように構成されるネゴシエーション判断モジュールと、
前記ピアデバイスとのネゴシエーションが成功した場合、前記ピアデバイスの画面共有要求を取得したことを確定するように構成される要求成功確定モジュールと、
前記ピアデバイスとのネゴシエーションが失敗した場合、前記ピアデバイスの画面共有要求を取得しないことを確定するように構成される要求失敗確定モジュールと
を含むことを特徴とする、請求項６に記載の情報処理装置。

【請求項10】

前記メディアデータ再生ユニットは、
前記ＵＲＬに基づいて前記ピアデバイスにおける前記ＵＲＬに対応するメディアデータを取得するように構成されるメディアデータ取得モジュールと、
前記メディアデータをデコードするように構成されるデコードモジュールと、
デコードされたメディアデータをレンダリングし、メディア再生データを取得するように構成されるレンダリングモジュールと、
前記メディア再生データを前記標準プレーヤで再生するように構成される再生モジュールと
を含むことを特徴とする、請求項６に記載の情報処理装置。

【請求項11】

端末であって、
プロセッサと、
プロセッサ実行可能命令を記憶するように構成されるメモリと
を含み、
前記プロセッサは、
無線ネットワークの伝送リンクを通してピアデバイスの画面共有要求を取得したかどうかを判断し、
ピアデバイスの画面共有要求を受信した場合、前記ピアデバイスのＩＰアドレスおよび前記ピアデバイスのポート番号を取得し、
前記ＩＰアドレスおよび前記ポート番号に基づいて、ピアデバイス画面を再生するためのメディアデータに対応するユニフォームリソースロケータ（ＵＲＬ）を生成し、
前記ＵＲＬに対応する標準プレーヤを確定し、
前記標準プレーヤを利用して前記ＵＲＬに対応するメディアデータを再生するように構成される、端末。

【発明の詳細な説明】

【技術分野】

【0001】

本願は出願番号２０１５１０７１８２８９．５、出願日２０１５年１０月２９日の中国特許出願に基づいて提案され、また該中国特許出願の優先権を主張し、該中国特許出願の全ての内容が本願において援用される。

【0002】

本開示の実施例は、通信技術分野に関し、特に情報処理方法および装置に関する。

【背景技術】

【0003】

ＷｉＦｉ−ｄｉｓｐｌａｙ技術は、ＷｉＦｉ Ｄｉｒｅｃｔに基づいてユーザーデバイス間のリアルタイムなリソース共有（ピクチャ、ビデオ、音楽など）を実現する技術である。この共有は、いかなるハードウェアへの接続が必要ではなく、ＷｉＦｉを介して接続するだけで、送信側（すなわちＳｏｕｒｃｅ側）からリアルタイムに受信側（Ｓｉｎｋ側）に伝送されて再生されることができる。例えば、ＷｉＦｉ−ｄｉｓｐｌａｙ技術により、携帯電話のビデオを同期に大画面テレビで再生することができる。

【0004】

しかし、関連技術では、Ｓｏｕｒｃｅ側は再生すべきデータをＳｉｎｋ側に伝送してから直接Ｓｉｎｋ側によって再生し、そのデータの伝送と再生が独立しないので、一旦Ｓｏｕｒｃｅ側とＳｉｎｋ側との間のデータ伝送がある時に利用される通信プロトコルなどが変化した場合、Ｓｏｕｒｃｅ側からＳｉｎｋ側に伝送されたデータがＳｉｎｋ側で正常に再生できない可能性が非常に高い。

【発明の概要】

【発明が解決しようとする課題】

【0005】

間連技術の問題を解決するために、本開示の実施例は、情報処理方法および装置を提供する。

【課題を解決するための手段】

【0006】

本開示の実施例の第１態様による情報処理方法は、
無線ネットワークの伝送リンクを通してピアデバイスの画面共有要求を取得したかどうかを判断することと、
ピアデバイスの画面共有要求を受信した場合、前記ピアデバイスのＩＰアドレスおよび前記ピアデバイスのポート番号を取得することと、
前記ＩＰアドレスおよび前記ポート番号に基づいて、ピアデバイスの画面を再生するためのメディアデータに対応するユニフォームリソースロケータ（ＵＲＬ）を生成することと、
前記ＵＲＬに対応する標準プレーヤを確定することと、
前記標準プレーヤを利用して前記ＵＲＬに対応するメディアデータを再生することとを含む。

【0007】

送信側から送信された画面共有要求を受信した場合、受信側は、送信側のＩＰアドレスおよびポート番号を取得し、ＵＲＬを生成し、受信側は、このＵＲＬに基づいてＵＲＬに対応する標準プレーヤを確定し、取得された標準プレーヤによりこのメディアのデータを再生する。本開示の実施例の受信側における標準プレーヤが独立した標準プレーヤであるので、送信側と受信側がデータ交換を行う時に利用される通信プロトコルが変化しても、受信側における標準プレーヤは、依然として正常に送信側から伝送されたメディアデータを再生することができる。

【0008】

オプションとして、前記ＵＲＬに対応する標準プレーヤを確定することは、
デフォルトプレーヤを取得し、
前記デフォルトプレーヤが前記ＵＲＬに対応するフォーマットタイプをサポートするかどうかを判断し、
前記デフォルトプレーヤが前記ＵＲＬに対応するフォーマットタイプをサポートする場合、前記デフォルトプレーヤを前記ＵＲＬに対応する標準プレーヤとして確定し、
前記デフォルトプレーヤが前記ＵＲＬに対応するフォーマットタイプをサポートしない場合、前記デフォルトプレーヤを、前記ＵＲＬに対応するフォーマットタイプをサポートするプレーヤと、設定し、前記ＵＲＬに対応するフォーマットタイプをサポートする前記プレーヤを、前記ＵＲＬに対応する標準プレーヤとして確定することとを含む。

【0009】

ＵＲＬのフォーマットタイプをサポートしない従来のプレーヤを、ＵＲＬのフォーマットタイプをサポートする標準プレーヤに再構成することにより、Ｓｏｕｒｃｅ側とＳｉｎｋ側との間のデータ伝送プロトコルが変化しても、標準プレーヤの伝送されたメディアデータに対するリアルタイムな再生に影響を与えない。

【0010】

オプションとして、前記ＵＲＬに対応する標準プレーヤを確定することは、
標準プレーヤを作成し、
前記標準プレーヤが前記ＵＲＬに対応するフォーマットタイプをサポートするかどうかを判断し、
前記標準プレーヤが前記ＵＲＬに対応するフォーマットタイプをサポートする場合、前記標準プレーヤを前記ＵＲＬに対応する標準プレーヤとして確定することとを含む。

【0011】

ＵＲＬのフォーマットタイプをサポートする標準プレーヤを作成し、作成した後、該標準プレーヤがＵＲＬのフォーマットタイプをサポートするかどうかを確認する。該標準プレーヤがＵＲＬのフォーマットタイプをサポートする場合、Ｓｏｕｒｃｅ側とＳｉｎｋ側との間のデータ伝送プロトコルが変化しても、標準プレーヤの伝送されたメディアデータに対するリアルタイムな再生に影響を与えない。

【0012】

オプションとして、ピアデバイスの画面共有要求を取得したかどうかを判断することは、
無線ピアツーピアネットワークＷｉＦｉ Ｐ２Ｐプロトコルにより前記ピアデバイスと通信接続を確立する場合、前記ピアデバイスとプリセットパラメータ情報を交換し、
前記プリセットパラメータ情報に基づいて、前記ピアデバイスとのネゴシエーションが成功したかどうかを判断し、
前記ピアデバイスとのネゴシエーションが成功した場合、前記ピアデバイスの画面共有要求を取得したことを確定し、
前記ピアデバイスとのネゴシエーションが失敗した場合、前記ピアデバイスの画面共有要求を取得しないことを確定することとを含む。

【0013】

双方がネゴシエーションを行うことでデータ伝送条件を満たしているかどうかを判断し、Ｓｉｎｋ側がＳｏｕｒｃｅ側から送信されたメディアデータを受信した場合にフォーマットなどの原因により該メディアデータを正常に再生できないことを防ぐ。

【0014】

オプションとして、前記標準プレーヤを利用して前記ＵＲＬに対応するメディアデータを再生することは、
前記ＵＲＬに基づいて前記ピアデバイスにおける前記ＵＲＬに対応するメディアデータを取得し、
前記メディアデータをデコードし、
デコードされたメディアデータをレンダリングし、メディア再生データを取得し、
前記メディア再生データを前記標準プレーヤで再生することとを含む。

【0015】

ＵＲＬを取得した後、まず該ＵＲＬを解析し、解析されたＵＲＬに基づいて対応するメディアデータを取得する。例えば、ＵＲＬを解析した後、Ｓｏｕｒｃｅ側は、確立されたｓｅｓｓｉｏｎによりリアルタイムメディアストリーム（またはクロールされたインタフェース）をＴＳ（ｔｒａｎｓｐｏｒｔ ｓｔｒｅａｍ）方式でＳｉｎｋ側に伝送し、Ｓｉｎｋは、メディアストリームデータ（例えば、オーディオ、ビデオなど）を符号化して逆多重化し、そして標準プレーヤに伝送してデコード、レンダリングおよび再生を行う。

【0016】

本開示の実施例の第２態様による情報処理装置は、
無線ネットワークの伝送リンクを通してピアデバイスの画面共有要求を取得したかどうかを判断するように構成される要求判断ユニットと、
ピアデバイスの画面共有要求を受信した場合、前記ピアデバイスのＩＰアドレスおよび前記ピアデバイスのポート番号を取得するように構成される情報取得ユニットと、
前記ＩＰアドレスおよび前記ポート番号に基づいて、ピアデバイス画面を再生するためのメディアデータに対応するユニフォームリソースロケータ（ＵＲＬ）を生成するように構成されるＵＲＬ生成ユニットと、
前記ＵＲＬに対応する標準プレーヤを確定するように構成されるプレーヤ確定ユニットと、
前記標準プレーヤを利用して前記ＵＲＬに対応するメディアデータを再生するように構成されるメディアデータ再生ユニットとを含む。

【0017】

オプションとして、前記プレーヤ確定ユニットは、 デフォルトプレーヤを取得するように構成されるプレーヤ取得モジューと、
前記デフォルトプレーヤが前記ＵＲＬに対応するフォーマットタイプをサポートするかどうかを判断するように構成される第一のフォーマットタイプ判断モジュールと、
前記デフォルトプレーヤが前記ＵＲＬに対応するフォーマットタイプをサポートする場合、前記デフォルトプレーヤを前記ＵＲＬに対応する標準プレーヤとして確定するように構成される第１標準プレーヤ確定モジュールと、
前記デフォルトプレーヤが前記ＵＲＬに対応するフォーマットタイプをサポートしない場合、前記デフォルトプレーヤを前記ＵＲＬに対応するフォーマットタイプをサポートするプレーヤと、設定するように構成される標準プレーヤと、
前記ＵＲＬに対応するフォーマットタイプをサポートする前記プレーヤを前記ＵＲＬに対応する標準プレーヤとして確定するように構成される第２標準プレーヤとを含む。

【0018】

オプションとして、前記プレーヤ確定ユニットは、
標準プレーヤを作成するように構成される標準プレーヤ作成モジュールと、
前記標準プレーヤが前記ＵＲＬに対応するフォーマットタイプをサポートするかどうかを判断するように構成される第２フォーマットタイプ判断モジュールと、
前記標準プレーヤが前記ＵＲＬに対応するフォーマットタイプをサポートする場合、前記標準プレーヤを前記ＵＲＬに対応する標準プレーヤとして確定するように構成される第３標準プレーヤ確定モジュールとを含む。

【0019】

オプションとして、前記要求判断ユニットは、
無線ピアツーピアネットワークＷｉＦｉ Ｐ２Ｐプロトコルにより前記ピアデバイスと通信接続を確立する場合に、前記ピアデバイスとプリセットパラメータ情報を交換するように構成されるパラメータ情報交換モジュールと、
前記プリセットパラメータ情報に基づいて、前記ピアデバイスとのネゴシエーションが成功したかどうかを判断するように構成されるネゴシエーション判断モジュールと、
前記ピアデバイスとのネゴシエーションが成功した場合、前記ピアデバイスの画面共有要求を取得したことを確定するように構成される要求成功確定モジュールと、
前記ピアデバイスとのネゴシエーションが失敗した場合、前記ピアデバイスの画面共有要求を取得しないことを確定するように構成される要求失敗確定モジュールとを含む。

【0020】

オプションとして、前記メディアデータ再生ユニットは、
前記ＵＲＬに基づいて前記ピアデバイスにおける前記ＵＲＬに対応するメディアデータを取得するように構成されるメディアデータ取得モジュールと、
前記メディアデータをデコードするように構成されるデコードモジュールと、
デコードされたメディアデータをレンダリングしてメディア再生データを取得するように構成されるレンダリングモジュールと、
前記メディア再生データを前記標準プレーヤで再生するように構成される再生モジュールとを含む。

【0021】

本開示の実施例の第３態様による端末は、
プロセッサと、
プロセッサ実行可能命令を格納するように構成されるメモリとを含み、
ここで、前記プロセッサは、
無線ネットワークの伝送リンクを通してピアデバイスの画面共有要求を取得したかどうかを判断し、
ピアデバイスの画面共有要求を受信した場合、前記ピアデバイスのＩＰアドレスおよび前記ピアデバイスのポート番号を取得し、
前記ＩＰアドレスおよび前記ポート番号に基づいて、ピアデバイス画面を再生するためのメディアデータに対応するユニフォームリソースロケータ（ＵＲＬ）を生成し、
前記ＵＲＬに対応する標準プレーヤを確定し、
前記標準プレーヤを利用して前記ＵＲＬに対応するメディアデータを再生するように構成される。

【0022】

本開示の実施例による技術的解決手段は、以下の有益な効果を含むことができる。

【0023】

本開示発明の実施例による提供される情報処理方法および装置では、受信側が送信側に発見された場合、受信側と送信側との通信接続が確立設定され、通信接続中、受信側と送信側がいくつかの情報を交換してネゴシエーションを行い、ネゴシエーションが成功した場合は、場合、送信側デバイスの画面共有要求を取得したことを確定し、そうすると受信側は送信側のＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ、インターネットプロトコル）アドレスおよびポート番号を取得してＵＲＬを生成し、受信側はこのＵＲＬに基づいてＵＲＬに対応する標準プレーヤを確定し、取得された標準プレーヤにより該メディアデータを再生する。本開示の実施例の受信側における標準プレーヤが独立した標準プレーヤであるので、送信側と受信側がデータ交換を行う時に利用したプロトコルプロトコルが変化しても、受信側における標準プレーヤは、依然として送信側から伝送されたメディアデータを正常に再生することができる。

【0024】

以上の一般的な説明および後の詳細な説明は、例示的なものおよび解釈的なものだけであり、本発明を限定できない。

【図面の簡単な説明】

【0025】

【図1】一つの例示的な実施例によるプロトコル階層図である。

【図2】Ｓｏｕｒｃｅ側とＳｉｎｋ側との間のデータ伝送の概略図である。

【図3】一つの例示的な実施例による情報処理方法のフローチャートである。

【図4】図３におけるステップＳ３４０のフローチャートである。

【図5】図３におけるステップＳ３４０のもう１つのフローチャートである。

【図6】図３におけるステップＳ３１０のフローチャートである。

【図7】図３におけるステップＳ３５０のフローチャートである。

【図8】一つの例示的な実施例による情報処理装置の概略図である。

【図9】図８におけるプレーヤ確定ユニットの概略図である。

【図10】図８におけるプレーヤ確定ユニットのもう１つの概略図である。

【図11】図８における要求判断ユニットの概略図である。

【図12】図８におけるメディアデータ再生ユニットの概略図である。

【図13】例示的な実施例による端末の構造の概略図である。

【発明を実施するための形態】

【0026】

ここの図面は、明細書に組み込まれ、本明細書の一部を構成し、本発明に適合した実施例を示しており、また明細書と一緒に本発明の原理を説明することに用いられる。

【0027】

ここでは例示的な実施例について詳しく説明し、その例は図面に示される。以下の説明は図面に関わる場合、特に明記しない限り、異なる図面における同一の数字は同一または類似の要素を表す。以下の例示的な実施例において説明される実施形態は本発明と一致する全ての実施形態を代表するものではない。逆に、それらは、添付の特許請求の範囲において詳しく説明される、本発明のいくつかの方面と一致する装置および方法の例だけである。

【0028】

Ｇｏｏｇｌｅによりが開発された操作システムＡｎｄｒｏｉｄ ４．２バージョンでは、ＷｉＦｉ Ｄｉｓｐｌａｙ機能に対するサポートが追加されており、これにより、Ａｎｄｒｏｉｄディスプレイアーキテクチャ全体が比較的大きく変化するにもつながった。Ｍｉｒａｃａｓｔは、ＷｉＦｉアライアンスがＷｉＦｉ Ｄｉｓｐｌａｙ（ＷＦＤと略称する）機能をサポートするデバイスに対して認証した名称である。Ｍｉｒａｃａｓｔ認証に合格したデバイスは、最大限にＷＦＤ機能に対するサポートおよび互換性を保存する。

【0029】

Ｍｉｒａｃａｓｔのコア機能は、デバイス同士がＷｉＦｉ無線ネットワークを介してビデオとオーディオのデータを共有させることである。簡単なアプリケーションシナリオを例に説明するが、Ｍｉｒａｃａｓｔを持っていれば、ハードワイヤ（ＨＤＭＩ（登録商標）（Ｈｉｇｈ Ｄｅｆｉｎｉｔｉｏｎ Ｍｕｌｔｉｍｅｄｉａ Ｉｎｔｅｒｆａｃｅ、高精細度マルチメディアインタフェース）など）を必要とすることなく直接ＷｉＦｉにより携帯電話におけるビデオをテレビに伝送して表示することができる。現在のスマートデバイスの発展傾向から見ると、ＷＦＤは比較的短い時間内に本当の意味でのマルチスクリーンインタラクションの実現に貢献する可能性が非常に高い。ＷＦＤプロトコルは、ＷｉＦｉおよびＲＴＳＰ（Ｒｅａｌ Ｔｉｍｅ Ｓｔｒｅａｍｉｎｇ Ｐｒｏｔｏｃｏｌ、リアルタイムストリーミングプロトコル）を拡大し、ＲＴＳＰに基づいて一連のパラメータおよびｍｅｓｓａｇｅタイプを定義し、ＷｉＦｉのＩｎｆｏｍａｔｉｏｎ Ｅｌｅｍｅｎｔカスタム機能により基礎となる伝送を行う。そのプロトコル層は図１に示される。

【0030】

図２に示すように、ＷＦＤプロトコルでは少なくとも１つのＳｏｕｒｃｅデバイス（Ｓｏｕｒｃｅ側）および１つのＳｉｎｋデバイス（Ｓｉｎｋ側）が存在する必要があると規定しており、ＳｏｕｒｃｅデバイスがＷＦＤ Ｓｏｕｒｃｅ、ＳｉｎｋデバイスがＷＦＤ Ｓｉｎｋと呼ばれている。Ｓｏｕｒｃｅデバイスは、送信側であり、Ｓｉｎｋデバイスは、受信側である。以下にＳｏｕｒｃｅ側とＳｉｎｋ側がどのようにデータ交換を行うかについて簡単に紹介する。Ｍｉｒａｃａｓｔはｓｅｓｓｉｏｎ（セッション制御）を単位として２つのデバイス間のデータ交換を管理し、主なステップは以下のとおりである（順番に紹介する）。

【0031】

デバイス発見（Ｄｅｖｉｃｅ Ｄｉｓｃｏｖｅｒｙ）：ＷｉＦｉ Ｐ２Ｐにより近くのＷｉＦｉ Ｐ２Ｐをサポートするデバイスを検索する。

【0032】

デバイス選択（Ｄｅｖｉｃｅ Ｓｅｌｅｃｔｉｏｎ）：デバイスＡがデバイスＢを発見したら、デバイスＡはユーザーに知らせる必要がある。ユーザーは必要に応じてデバイスＢとペアリングするかどうかを選択することができる。

【0033】

接続確立（Ｃｏｎｎｅｃｔｉｏｎ Ｓｅｔｕｐ）：Ｓｏｕｒｃｅ側とＳｉｎｋ側におけるディスプレイ（Ｄｉｓｐｌａｙ）デバイスはＷｉＦｉＰ２Ｐにより接続を確立する。ＷｉＦｉ Ｄｉｒｅｃｔ技術仕様によると、このステップは、Ｇｒｏｕｐ Ｏｗｎｅｒ（グループ所有者）の確立およびＣｌｉｅｎｔ（クライアント）の確立を含む。その後、この２つのデバイスではＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ、トランスミッションコントロールプロトコル）接続が確立され、同時にＲＴＳＰに用いられるポートは、後のＳｅｓｓｉｏｎ管理および制御のために作成される。

【0034】

機能ネゴシエーション（Ｃａｐａｂｉｌｉｔｙ Ｎｅｇｏｔｉａｔｉｏｎ）：正式にビデオとオーディオのデータを伝送する前に、ＳｏｕｒｃｅデバイスとＤｉｓｐｌａｙデバイスは、双方がサポートするビデオとオーディオのフォーマットなどのＭｉｒａｃａｓｔパラメータ情報を交換する必要がある。両者のネゴシエーションが成功してから、後の処理を継続することができる。

【0035】

セッション制御および確立プロセス（Ｓｅｓｓｉｏｎ Ｅｓｔａｂｌｉｓｈｍｅｎｔ ａｎｄ ｓｔｒｅａｍｉｎｇ）：前のステップが完了した後、ＳｏｕｒｃｅデバイスとＤｉｓｐｌａｙデバイスは、ＭｉｒａｃａｓｔＳｅｓｓｉｏｎを確立する。その後、ビデオおよびオーディオデータの伝送を開始することができる。Ｓｏｕｒｃｅ側のビデオおよびオーディオデータは、ＭＰＥＧ２ＴＳ（Ｍｏｖｉｎｇ Ｐｉｃｔｕｒｅ Ｅｘｐｅｒｔｓ Ｇｒｏｕｐ Ｔｒａｎｓｐｏｒｔ Ｓｔｒｅａｍ、動的ピクチャーエキスパートグループ伝送ストリーム）でコーディングされた後、ＲＴＰ（Ｒｅａｌ−ｔｉｍｅ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ、リアルタイム伝送プロトコル）によりＤｉｓｐｌａｙデバイスに伝送される。Ｄｉｓｐｌａｙデバイスは、受信されたデータをデコードし、最終表示する。

【0036】

しかし、上記の解決手段では、Ａｐｋ（ＡｎｄｒｏｉｄＰａｃｋａｇｅ、Ａｎｄｒｏｉｄパッケージ）層がＳｅｔｔｉｎｇと一緒に設置され、また中間層がＷｉＦｉＰ２Ｐと混合し、ロジックプロセスから十分に明確ではなく、結合解除やメンテナンスが難しくなる。上記の解決手段はプロセス全体から見ると基本的にリンクと再生に分けることができ、一旦リンク部が変化したら、再生部の正常な動作に影響を与える。例えば、Ｓｏｕｒｃｅ側の既存のＷｉＦｉ Ｐ２Ｐ発見プロトコルを置き換え、ｕｐｎｐ（Ｕｎｉｖｅｒｓａｌ Ｐｌｕｇ ａｎｄ Ｐｌａｙ、ユニバーサルプラグアンドプレイ）／ｍｓｄｎｓ（Ｍｉｃｒｏｓｏｆｔ Ｄｅｖｅｌｏｐｅｒ Ｎｅｔｗｏｒｋ、マイクロソフト開発者向けネットワーク）または独自の発見プロトコルを介してデバイスを発見すると、基礎となるＲＴＳＰプロトコルが変化しないので、再生部は、正常に動作しない可能性がある。

【0037】

ネイティブのＭｉｒｃａｓｔソリューションではリンクＲＴＳＰ ｓｅｒｖｅｒとＷｉＦｉ Ｐ２Ｐリンクプロセスを一緒に混合させているので、Ｓｏｕｒｃｅ側のＩＰアドレスとポート番号を取得した後にすぐに再生を開始する。再生とリンクの直接の関連はＩＰアドレスとポートだけであることを考慮し、再生とリンクの独立を実現するために、ＩＰアドレスとポートをｉｎｔｅｎｔ方式によりアプリケーションに伝送して後の操作を行うことができる。従って、本開示の実施例による情報処理方法および装置は、上記のリンク部と再生部の結合を解除し、リンク部の変化による影響を受けないように再生部を独立させることができる。具体的なプロセスは後の実施例において詳しく説明される。

【0038】

関連技術における技術問題に対し、本開示の実施例ではまずＳｉｎｋ側に応用される情報処理方法を提供し、図３に示すように、該方法は、以下のステップを含むことができる。

【0039】

ステップＳ３１０では、無線ネットワークの伝送リンクを通してピアデバイスの画面共有要求を取得したかどうかを判断する。

【0040】

Ｓｏｕｒｃｅ側は、ＷｉＦｉ Ｐ２Ｐにより近くのＷｉＦｉ Ｐ２Ｐをサポートするデバイスを検索することができ、また独自の発見プロトコルのような他のプロトコルにより相手側を発見することも可能である。Ｓｏｕｒｃｅ側がＳｉｎｋ側を発見した場合、Ｓｏｕｒｃｅ側とＳｉｎｋ側は、両者がサポートするネットワーク伝送プロトコルを用いて通信接続を確立し、Ｓｏｕｒｃｅ側がメディアデータをＳｉｎｋ側でリアルタイムに再生して画面共有を実現する必要がある場合、Ｓｏｕｒｃｅ側は、確立された通信接続を通してＳｉｎｋ側に画面共有要求を送信する。

【0041】

ピアデバイスの画面共有要求を受信した場合、ステップＳ３２０で、ピアデバイスのＩＰアドレスおよびピアデバイスのポート番号を取得する。

【0042】

ピアデバイスのＩＰアドレスとピアデバイスのポート番号は、Ｓｏｕｒｃｅ側のＩＰアドレスとポート番号を指す。

【0043】

ステップＳ３３０では、ＩＰアドレスとポート番号に基づいて、ピアデバイス画面を再生するためのメディアデータに対応するＵＲＬを生成する。

【0044】

ＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ、ユニフォームリソースロケータ）は、Ｓｏｕｒｃｅ側のＩＰアドレスおよびＳｏｕｒｃｅ側のポート番号に基づいて生成され、該ＵＲＬのフォーマットタイプがｗｆｄフォーマットタイプであってよい。

【0045】

ステップＳ３４０では、ＵＲＬに対応する標準プレーヤを確定する。

【0046】

ＵＲＬに対応する標準プレーヤを確定することは、既存のプレーヤを標準プレーヤに再構成してＵＲＬのフォーマットタイプをサポートするようにすること、およびＵＲＬタイプをサポートする標準プレーヤを作成することという２種の手法があることができる。これにより、該標準プレーヤは、ＵＲＬに対応するメディアデータを再生できる。

【0047】

ステップＳ３５０では、標準プレーヤを利用してＵＲＬに対応するメディアデータを再生する。

【0048】

標準プレーヤを確定した後、該標準プレーヤを利用してＵＲＬに対応するメディアデータを再生することができ、すなわち、Ｓｉｎｋ側は、Ｓｏｕｒｃｅ側から伝送されたメディアデータをリアルタイムに再生することができる。

【0049】

本開示の実施例による情報処理方法では、送信側から送信された画面共有要求を受信した場合、受信側は、送信側のＩＰアドレスおよびポート番号を取得してＵＲＬを生成し、また該ＵＲＬに基づいてＵＲＬに対応する標準プレーヤを確定し、取得された標準プレーヤを通して該メディアデータを再生する。本開示の実施例の受信側における標準プレーヤが独立した標準プレーヤであるので、送信側と受信側がデータ交換を行っている時に利用される通信プロトコルが変化しても、受信側における標準プレーヤは、依然として正常に送信側から伝送されたメディアデータを再生することができる。

【0050】

ＵＲＬに対応する標準プレーヤを確定して既存のプレーヤを再構成するために、本開示の実施例によるもう１つの実施例では、図３に基づいて、図４に示すように、前記ステップＳ３４０は、さらに以下のステップを含むことができる。

【0051】

ステップＳ３４１では、デフォルトプレーヤを取得する。

【0052】

該デフォルトプレーヤが既存のプレーヤであって良いので、直接該デフォルトプレーヤを使用すればよい。

【0053】

ステップＳ３４２では、デフォルトプレーヤがＵＲＬに対応するフォーマットタイプをサポートするかどうかを判断する。

【0054】

該デフォルトプレーヤを取得した後、まず該プレーヤがＵＲＬに対応するフォーマットをサポートするかどうかを判断する必要がある。該ＵＲＬは、ｗｆｄ：／／ｘｘｘのＵＲＬのようなｗｆｄフォーマットタイプのＵＲＬであって良い。

【0055】

デフォルトプレーヤがＵＲＬに対応するフォーマットタイプをサポートする場合、ステップＳ３４３では、デフォルトプレーヤをＵＲＬに対応する標準プレーヤとして確定する。

【0056】

該デフォルトプレーヤがＵＲＬに対応するフォーマットタイプをサポートする場合、該デフォルトプレーヤを再構成する必要がなく、直接利用すればよい。現在、既存のプレーヤが一般的にｗｆｄ：／／ｘｘｘのＵＲＬのフォーマットタイプをサポートしないので、該ステップでデフォルトプレーヤがＵＲＬに対応するフォーマットタイプをサポートする場合、該デフォルトプレーヤは、再構成されたもの、または予め作成された標準プレーヤだと考えることができる。該デフォルトプレーヤを標準プレーヤとして確定する。

【0057】

デフォルトプレーヤがＵＲＬに対応するフォーマットタイプをサポートしない場合、ステップＳ３４４では、デフォルトプレーヤを、ＵＲＬに対応するフォーマットタイプをサポートするプレーヤと、設定し、さらにＵＲＬに対応するフォーマットタイプをサポートするプレーヤを、ＵＲＬに対応する標準プレーヤとして確定する。

【0058】

該デフォルトプレーヤがＵＲＬに対応するフォーマットタイプをサポートしない場合、該デフォルトプレーヤを再構成してＵＲＬに対応するフォーマットタイプをサポートするようにする必要があり、さらに再構成されたデフォルトプレーヤを標準プレーヤとして確定する。

【0059】

ここではＲＴＰ Ｓｉｎｋに基づいてオーディオおよびとビデオのデータを取得してそしてＴｕｎｎｅｌＲｅｎｄｅｒにおいてプレーヤを起動して再生する方式を用いても良い。該方式ではすでに標準的なプレーヤおよびインタフェースがあるので、統一したプロセスによりｓｕｒｆａｃｅの作成および設定などをＭｅｄｉａｐｌａｙｅｒｓｅｒｖｉｃｅアーキテクチャにおける対応するインタフェースに割り当てるだけでよい。また、該方式はＷｉＦｉＤｉｓｐｌａｙＳｉｎｋ−＞ＲＴＰＲｅｃｅｉｖｅｒ−＞ＴｕｎｎｅｌＲｅｎｄｅｒｅｒという流れにより再生を行うフレームであるので、このフレームの実際のプレーヤは、ＴｕｎｎｅｌＲｅｎｄｅｒｅｒのオブジェクトですでに初期化され、またｓｅｔＤａｔａＳｏｕｒｃｅ（）、ｓｅｔＶｉｄｅｏＳｕｒｆａｃｅＴｅｘｔｕｒｅ（）、ｓｔａｒｔ（）などの関数インタフェースを呼び出すことで再生プロセスを起動した。

【0060】

しかし、上記の方式では、リンクと再生の結合が解除できないため、再生部が独立せず、上位アプリケーションに対してＵＲＬが再生タイプを自動識別することにより再生プロセスを作成することを望むので、プレーヤを初期化するプロセスをＭｅｄｉａｐｌａｙｅｒｓｅｒｖｉｃｅクラスに取り入れる必要があるという問題が存在している。具体的に言うと、Ｍｅｄｉａｐｌａｙｅｒｓｅｒｖｉｃｅクラスのメンバー関数ｓｅｔＤａｔａＳｏｕｒｃｅを再構成することにより、ＭｉｒａｃａｓｔのＵＲＬを識別できるようにするということである。ここでは、ｗｆｄ：／／ｘｘｘにて、再生タイプがＭｉｒａｃａｓｔであることを識別し、これにより他のプロトコルと区別して基礎部が正しい再生プロセスを作成できるようにする。ｓｅｔＶｉｄｅｏＳｕｒｆａｃｅＴｅｘｔｕｒｅ（）、ｓｔａｒｔ（）などの他のプロセスは、標準的な再生呼び出しプロセスと同様である。

【0061】

ＵＲＬフォーマットタイプをサポートしない既存のプレーヤを、ＵＲＬフォーマットタイプをサポートする標準プレーヤに再構成することにより、Ｓｏｕｒｃｅ側とＳｉｎｋ側との間のデータ伝送プロトコルが変化しても、標準プレーヤの伝送されたメディアデータに対するリアルタイムの再生に影響を与えない。

【0062】

ＵＲＬに対応する標準プレーヤを確定して作成するために、本開示によるもう１つの実施例では、図３に基づいて、図５に示すように、前記ステップＳ３４０は、さらに以下のステップを含むことができる。

【0063】

ステップＳ３４５において標準プレーヤを作成する。

【0064】

現在、ＵＲＬフォーマットタイプをサポートするプレーヤが基本的にないので、ここでは標準プレーヤを作成する必要がある。該標準プレーヤは標準インタフェースを有し、一般的なプレーヤが呼び出される標準プロセスをサポートするものとする。該標準プレーヤは、ｗｆｄ：／／ｘｘｘＵＲＬのようなフォーマットタイプをサポートする。

【0065】

ステップＳ３４６では、標準プレーヤがＵＲＬに対応するフォーマットタイプをサポートするかどうかを判断する。

【0066】

標準プレーヤを作成した後、さらに、該標準プレーヤが正しくＵＲＬに対応するメディアデータを再生するように、作成された標準プレーヤを確認し、ＵＲＬに対応するフォーマットタイプをサポートするかどうかを判断する必要がある。

【0067】

前記標準プレーヤがＵＲＬに対応するフォーマットタイプをサポートする場合、ステップＳ３４７において標準プレーヤをＵＲＬに対応する標準プレーヤとして確定する。

【0068】

該標準プレーヤがＵＲＬに対応するフォーマットタイプをサポートする場合、該ＵＲＬを該ＵＲＬに対応する標準プレーヤとして確定することができる。

【0069】

標準プレーヤを作成する場合、ＭｅｄｉａＲｅｃｅｉｖｅｒからＤｉｒｅｃｔｒｅｎｄｅｒへ直接オーディオおよびとビデオのデコード、再生を行う方法に基づいて作成することができ、具体的には、ＷｉＦｉＤｉｓｐｌａｙＳｉｎｋ−＞ＭｅｄｉａＲｅｃｅｉｖｅｒ−＞ＤｉｒｅｃｔＲｅｎｄｅｒｅｒとなる。この方法では再生のプロセスはあるが、標準Ａｎｄｒｏｉｄプレーヤのプロセスと一致しない。この方法の最大の欠点として、ｓｅｔＤａｔａＳｏｕｒｃｅ、ｓｅｔＶｉｄｅｏＳｕｒｆａｃｅＴｅｘｔｕｒｅなどのプレーヤのベースクラスＭｅｄｉａＰｌａｙｅｒＩｎｔｅｒｆａｃｅの標準インタフェースを実現しておらず、またＷｉＤｉに対して、Ｓｏｕｒｃｅ側が解像度の切り換えを行った場合で、アプリケーションに対して適時に解像度の切り換えを知らせることができない。この場合、マウスとビデオは対応しない。これらの問題を解決するために、プレーヤクラスを作成し、暫定的にＦａｋｅＭｉｒａｃａｓｔＰｌａｙｅｒに命名し、この新しいプレーヤクラスは、アプリケーション層に公開されており、アプリケーション層は、標準ＭｅｄｉａＰｌａｙｅｒのプロセスを呼び出すことができ、基礎部は、元のフレームワークを引き受け、掛け橋の役割を果たし、上層部は、ｗｆｄ：／／ｘｘｘＵＲＬタイプによりそれを起動し、基礎部は、それを通してアプリケーション層に対してイベントの発生を知らせる。

【0070】

また、該ＦａｋｅＭｉｒａｃａｓｔＰｌａｙｅｒは、標準なｓｅｔＤａｔａＳｏｕｒｃｅインタフェースを介して元のＷｉＦｉｄｉｓｐｌａｙを呼び出し、ｓｅｔＬｉｓｔｅｎｅｒインタフェースを介して上層部プレーヤのエンティティをＷｉＦｉｄｉｓｐｌａｙに伝送し、これにより、ＷｉＦｉｄｉｓｐｌａｙにおける情報フィードバックを取得し、ｓｅｔＷｆｄＳｕｒｆａｃｅを介して標準なｓｕｒｆａｃｅをＷｉＦｉｄｉｓｐｌａｙに伝送し、さらにコーディングおよびデコード、表示に用い、このような手法により、インタフェースとプロセスの統合を図る。

【0071】

ＵＲＬフォーマットタイプをサポートする標準プレーヤを作成し、作成が完了した後、該標準プレーヤがＵＲＬのフォーマットタイプをサポートするかどうかを確認する。該標準プレーヤがＵＲＬのフォーマットタイプをサポートする場合、Ｓｏｕｒｃｅ側とＳｉｎｋ側との間のデータ伝送プロトコルが変化しても、標準プレーヤの伝送されたメディアデータに対するリアルタイムな再生に影響を与えない。

【0072】

Ｓｉｎｋ側がＳｏｕｒｃｅ側から送信された画面共有要求を取得したかどうかを判断するために、本開示のもう１つの実施例では、図３に基づいて、図６に示すように、ステップＳ３１０は、さらに以下の内容を含むことができる。

【0073】

ステップＳ３１１では、無線ピアツーピアネットワークＷｉＦｉ Ｐ２Ｐプロトコルによりピアデバイスと通信接続を確立する場合、ピアデバイスとプリセットパラメータ情報を交換する。

【0074】

ここのプリセットパラメータ情報は、Ｓｏｕｒｃｅ側とＳｉｎｋ側がサポートするビデオ／オーディオフォーマットなどのＭｉｒａｃａｓｔパラメータ情報であってよい。

【0075】

ステップＳ３１２では、プリセットパラメータ情報に基づいて、ピアデバイスとのネゴシエーションが成功したかどうかを判断する。

【0076】

Ｓｏｕｒｃｅ側とＳｉｎｋ側がプリセットパラメータ情報を交換した後、双方は、交換されたプリセットパラメータ情報をチェックし、自身のデバイスによってサポートされるかどうか、すなわち、双方のネゴシエーションが成功したかどうかを判断する。

【0077】

ピアデバイスとのネゴシエーションが成功した場合、ステップＳ３１３において、ピアデバイスの画面共有要求を取得したことを確定する。

【0078】

ピアデバイスとのネゴシエーションが失敗した場合、ステップＳ３１４において、ピアデバイスの画面共有要求を取得しないことを確定する。

【0079】

双方がネゴシエーションを行うことで、データ伝送条件を満たしているかどうかを判断し、Ｓｉｎｋ側がＳｏｕｒｃｅ側から送信されたメディアデータを受信した場合に、フォーマットなどの原因により正常に該メディアデータを再生できないことを防ぐ。

【0080】

標準プレーヤがＵＲＬに基づいて対応するメディアデータを取得した後、どのように該メディアデータを再生するかことは、モードロック状態になるために、本開示のもう１つの実施例では、図３に基づいて、図７に示すように、ステップＳ３５０は、さらに以下の内容を含むことができる。）
ステップＳ３５１では、ＵＲＬに基づいてピアデバイスにおけるＵＲＬに対応するメディアデータを取得する。

【0081】

ステップＳ３５２では、メディアデータをデコードする。

【0082】

ステップＳ３５３では、デコードされたメディアデータをレンダリングし、メディア再生データを取得する。

【0083】

ステップＳ３５４では、メディア再生データを標準プレーヤで再生する。

【0084】

ＵＲＬを取得した後、まず該ＵＲＬを解析し、解析されたＵＲＬに基づいて対応するメディアデータを取得する。例えば、ＵＲＬを解析した後、Ｓｏｕｒｃｅ側は、確立されたｓｅｓｓｉｏｎによりリアルタイムメディアストリーム（またはクロールされたインタフェース）をＴＳ（ｔｒａｎｓｐｏｒｔ ｓｔｒｅａｍ）方式でＳｉｎｋ側に伝送し、Ｓｉｎｋはメディアストリームデータ（例えば、オーディオ、ビデオなど）をコーディングして逆多重化し、その後標準プレーヤに伝送してデコード、レンダリングおよび再生を行う。

【0085】

本開示の実施例による情報処理方法では、送信側から送信された画面共有要求を受信した場合、受信側は送信側のＩＰアドレスおよびポート番号を取得してＵＲＬを生成し、また該ＵＲＬに基づいてＵＲＬに対応する標準プレーヤを確定し、取得された標準プレーヤを通して該メディアデータを再生する。本開示の実施例の受信側における標準プレーヤが独立した標準プレーヤであるので、送信側と受信側がデータ交換を行っている時に利用される通信プロトコルが変化しても、受信側における標準プレーヤは、依然として正常に送信側から伝送されたメディアデータを再生することができる。

【0086】

また、本発明の実施例では標準プレーヤを確定するための２種の方式を提供し、この２種の方式により確定された標準プレーヤはプレーヤを独立させてリンク部との結合を解除することができ、これにより、標準プレーヤが取得されたメディアデータを再生する時に伝送プロトコルの影響を受けないことができ、再生効率が大いに向上する。なお、この実施形態において提案される方法は、標準ＡＰＫインタフェースに統合しているので、容易にこの変動に適応でき、ビデオとマウスが異なる解像度でもマッチングできる問題を解決できる。

【0087】

以上の方法の実施例の説明により、本分野の当業者は、本開示の実施例がソフトウェアおよび必要な汎用ハードウェアプラットフォームを利用して実現されることができ、もちろん、ハードウェアにより実現されることもでき、多くの場合において前者が好ましい実施形態であることを、明確に理解することができる。このような理解に基づいて、本開示の発明の技術的解決手段は、本質的にソフトウェア製品の形態で体現され、または従来技術に貢献する部分がソフトウェア製品の形態で体現されることができ、該コンピュータソフトウェア製品は、記憶媒体に保存され、コンピュータデバイス（パーソナルコンピュータ、サーバまたはネットワーク装置などであってよい）に本開示の各実施例における前記方法の全部または一部のステップを実行させるための若干の命令を含む。前記記憶媒体は、読み出し専用メモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、ディスクまたは光ディスクなどのプログラムコードを保存できる様々なメディアを含む。

【0088】

なお、前記各実施例の実現手段として、本発明の実施例ではさらに１種の情報処理装置を提供する。この装置は、端末に位置し、図８に示すように、要求判断ユニット１０、情報取得ユニット２０、ＵＲＬ生成ユニット３０、プレーヤ確定ユニット４０およびメディアデータ再生ユニット５０を含み、
要求判断ユニット１０が無線ネットワークの伝送リンクを通してピアデバイスの画面共有要求を取得したかどうかを判断するように構成され、
情報取得ユニット２０がピアデバイスの画面共有要求を受信した場合、前記ピアデバイスのＩＰアドレスおよび前記ピアデバイスのポート番号を取得するように構成され、
ＵＲＬ生成ユニット３０が前記ＩＰアドレスおよび前記ポート番号に基づいて、ピアデバイス画面を再生するためのメディアデータに対応するユニフォームリソースロケータ（ＵＲＬ）を生成するように構成され、
プレーヤ確定ユニット４０が前記ＵＲＬに対応する標準プレーヤを確定するように構成され、
メディアデータ再生ユニット５０が前記標準プレーヤを利用して前記ＵＲＬに対応するメディアデータを再生するように構成される。

【0089】

本開示のもう１つの実施例では、図８に基づいて、図９に示すように、プレーヤ確定ユニット４０は、プレーヤ取得モジュール４１、第１フォーマットタイプ判断モジュール４２、第１標準プレーヤ確定モジュール４３、標準プレーヤ設定モジュール４４および第２標準プレーヤ確定モジュール４５を含み、
プレーヤ取得モジュール４１がデフォルトプレーヤを取得するように構成され、
第１フォーマットタイプ判断モジュール４２が、前記デフォルトプレーヤが前記ＵＲＬに対応するフォーマットタイプをサポートするかどうかを判断するように構成され、
第１標準プレーヤ確定モジュール４３が、前記デフォルトプレーヤが前記ＵＲＬに対応するフォーマットタイプをサポートする場合、前記デフォルトプレーヤを前記ＵＲＬに対応する標準プレーヤとして確定するように構成され、
標準プレーヤ設定モジュール４４が、前記デフォルトプレーヤが前記ＵＲＬに対応するフォーマットタイプをサポートしない場合、前記デフォルトプレーヤを、前記ＵＲＬに対応するフォーマットタイプをサポートするプレーヤと、設定するように構成され、
第２標準プレーヤ確定モジュール４５が前記ＵＲＬに対応するフォーマットタイプをサポートする前記プレーヤを、前記ＵＲＬに対応する標準プレーヤとして確定するように構成される。

【0090】

本開示のもう１つ実施例では、図８に基づいて、図１０に示すように、プレーヤ確定ユニット４０は、標準プレーヤ作成モジュール４６、第二フォーマットタイプ判断モジュール４７および第３標準プレーヤ確定モジュール４８を含み、
標準プレーヤ作成モジュール４６が標準プレーヤを作成するように構成され、
第２フォーマットタイプ判断モジュール４７が、前記標準プレーヤが前記ＵＲＬに対応するフォーマットタイプをサポートするかどうかを判断するように構成され、
第３標準プレーヤ確定モジュール４８が、前記標準プレーヤが前記ＵＲＬに対応するフォーマットタイプをサポートする場合、前記標準プレーヤを前記ＵＲＬに対応する標準プレーヤとして確定するように構成される。

【0091】

本発明のもう１つの実施例では、図８に基づいて、図１１に示すように、要求判断ユニット１０は、パラメータ情報交換モジュール１１、ネゴシエーション判断モジュール１２、要求成功確定モジュール１３と要求失敗確定モジュール１４を含み、
パラメータ情報交換モジュール１１がピアツーピア無線ネットワークＷｉＦｉ Ｐ２Ｐプロトコルを通して前記ピアデバイスと通信接続を確立する場合、前記ピアデバイスとプリセットパラメータ情報を交換するように構成され、
ネゴシエーション判断モジュール１２が前記プリセットパラメータ情報に基づいて、前記ピアデバイスとのネゴシエーションが成功したかどうかを判断するように構成され、
要求成功確定モジュール１３が、前記ピアデバイスとのネゴシエーションが成功した場合、前記ピアデバイスの画面共有要求を取得したことを確定するように構成され、
要求失敗確定モジュール１４が、前記ピアデバイスとのネゴシエーションが失敗した場合、前記ピアデバイスの画面共有要求を取得しないことを確定するように構成される。

【0092】

本開示のもう１つの実施例では、図８に基づいて、図１２に示すように、メディアデータ再生ユニットは、メディアデータ取得モジュール５１、デコードモジュール５２、レンダリングモジュール５３および再生モジュール５４を含み、
メディアデータ取得モジュール５１が前記ＵＲＬに基づいて前記ピアデバイスにおける前記ＵＲＬに対応するメディアデータを取得するように構成され、
デコードモジュール５２が前記メディアデータをデコードするように構成され、
レンダリングモジュール５３がデコードされたメディアデータをレンダリングし、メディア再生データを取得するように構成され、
再生モジュール５４が前記メディア再生データを前記標準プレーヤで再生するように構成される。

【0093】

上記の実施例における装置については、各モジュールが操作を実行する具体的な方式は、該方法に関する実施例において詳しく説明されているので、ここでは詳しい説明を省略する。

【0094】

図１３は、一つの例示的な実施例による情報処理のための端末１３００の構造の概略図である。例えば、端末１３００は、携帯電話、コンピュータ、デジタル放送端末、メッセージ送受信デバイス、ゲームコンソール、タブレットデバイス、医療機器、フィットネス機器、パーソナルデジタルアシスタントなどであってよい。

【0095】

図１３を参照すると、端末１３００は、処理ユニット１３０２、メモリ１３０４、電源ユニット１３０６、マルチメディアユニット１３０８、オーディオユニット１３１０、入力／出力（Ｉ／Ｏ）インタフェース１３１２、センサユニット１３１４および通信ユニット１３１６のうちの１つまたは複数のユニットを含むことができる。

【0096】

処理ユニット１３０２は、通常、表示、電話呼び出し、データ通信、カメラ操作および記録操作に関連する操作のような端末１３００の全体操作を制御する。処理ユニット１３０２は、上記方法の全部または一部のステップを完了する遂行するために、１つまたは複数のプロセッサ１３０２を含んで命令を実行するのための１つまたは複数のプロセッサ１３０２を含むことができる。また、処理ユニット１３０２は、その他のユニットとのインタラクションを容易にするために、１つまたは複数のモジュールを含むことができる。例えば、処理ユニット１３０２は、マルチメディアユニット１３０８とのインタラクションを容易にするために、マルチメディアモジュールを含むことができる。

【0097】

メモリ１３０４は、様々なタイプのデータを記憶して端末１３００での操作をサポートするように構成される。これらのデータの例は、端末１３００で操作されるいかなるアプリケーションプログラムまたは方法のための命令、連絡先データ、電話帳データ、メッセージ、ピクチャ、ビデオなどを含む。メモリ１３０４は、スタティックランダムアクセスメモリ（ＳＲＡＭ）、電気的消去可能プログラム可能読み出し専用メモリ（ＥＥＰＲＯＭ）、消去可能プログラム可能読み出し専用メモリ（ＥＰＲＯＭ）、プログラム可能読み出し専用メモリ（ＰＲＯＭ）、読み出し専用メモリ（ＲＯＭ）、磁気メモリ、フラッシュメモリ、磁気ディスクまたは光ディスクなどのいかなるタイプの揮発性または不揮発性記憶デバイスまたはそれらの組み合わせによって実現されることができる。

【0098】

電源ユニット１３０６は、端末１３００の各ユニットに電力を提供する。電源ユニット１３０６は、電源管理システム、１つまたは複数の電源、その他端末１３００のために電力を生成、管理および配分することに関連する他のユニットを含むことができる。

【0099】

マルチメディアユニット１３０８は、前記端末１３００とユーザーとの間の１つの出力インタフェースを提供する画面を含む。いくつかの実施例では、画面は、液晶ディスプレイ（ＬＣＤ）およびタッチパネル（ＴＰ）を含むことができる。画面がタッチパネルを含む場合、その画面は、ユーザーからの入力信号を受信するために、タッチパネルとして実現されることができる。タッチパネルは、タッチ、スライドおよびタッチパネル上のジェスチャーをセンシングするために１つまたは複数のタッチセンサを含む。前記タッチセンサは、タッチやスライドの境界をセンシングするだけでなく、前記タッチやスライドに関連する継続時間および圧力を検出することができる。いくつかの実施例では、マルチメディアユニット１３０８は、フロントカメラおよび／またはリアカメラを含む。端末１３００が撮影モードやビデオモードのような操作モードにある場合、フロントカメラと／またはリアカメラは、外部のマルチメディアデータを受信することができる。各フロントカメラとリアカメラは、固定された光学レンズシステムであってよく、または焦点距離および光学ズーム機能を備える。

【0100】

オーディオユニット１３１０は、オーディオ信号を出力および／または入力するように構成される。例えば、オーディオユニット１３１０はマイクロフォン（ＭＩＣ）を含み、端末１３００が呼び出しモード、記録モードおよび音声認識モードのような操作モードにある場合、マイクロフォンは外部のオーディオ信号を受信するように構成される。受信されたオーディオ信号はさらにメモリ１３０４に記憶され、または通信ユニット１３１６経由で送信されることができる。いくつかの実施例では、オーディオユニット１３１０は、さらにオーディオ信号を出力する構成されるスピーカーを含む。

【0101】

Ｉ／Ｏインタフェース１３１２は処理ユニット１３０２と周辺インタフェースモジュールとの間にインタフェースを提供し、前記周辺インタフェースモジュールがキーボード、クイックホイール、ボタンなどであってよい。これらのボタンはホームページボタン、ボリュームボタン、起動ボタンおよびロックボタンを含むことができるがそれらに限定されない。

【0102】

センサユニット１３１４は、端末１３００に各方面の状態評価を提供するように構成される１つまたは複数のセンサを含む。例えば、センサユニット１３１４は、端末１３００のオン／オフ状態、ユニットの相対的な位置決め、例えば前記ユニットが端末１３００のディスプレイおよびキーパッドであることを検出でき、センサユニット１３１４はさらに端末１３００または端末１３００の一つのユニットの位置変化、ユーザーとの端末１３００との接触が存在するかどうか、端末１３００の方位または加速／減速および端末１３００の温度変化を検出することも可能である。センサユニット１３１４は、いかなる物理的接触がない時に近くの物体が存在しているかどうかを検出するように構成される近接センサを含むことができる。該センサユニット１３１４はさらにイメージングアプリケーションに使用されるように構成されるＣＭＯＳやＣＣＤイメージセンサのような光センサを含むことができる。いくつかの実施例では、該センサユニット１３１４はさらに加速度センサ、ジャイロセンサ、磁気センサ、圧力センサまたは温度センサを含むことができる。

【0103】

通信ユニット１３１６は、端末１３００と他のデバイスとの有線または無線通信を容易にするように構成される。端末１３００は、通信規格に基づく無線ネットワーク、例えばＷｉＦｉ、２Ｇまたは３Ｇ、またはそれらの組み合わせにアクセスすることができる。一つの例示的な実施例では、通信ユニット１３１６は、放送チャネルを介して外部の放送管理システムからの放送信号または放送関連情報を受信する。一つの例示的な実施例では、前記通信ユニット１３１６は、さらに、近距離通信を促進するために近距離通信（ＮＦＣ）モジュールを含む。例えば、ＮＦＣモジュールは、無線周波数識別（ＲＦＩＤ）技術、赤外線データ協会（ＩｒＤＡ）技術、超広帯域（ＵＷＢ）技術、ブルートゥース（登録商標）（ＢＴ）技術およびその他の技術に基づいて実現されることができる。

【0104】

例示的な実施例では、端末１３００は、１つまたは複数の特定用途向け集積回路（ＡＳＩＣ）、デジタル信号プロセッサ（ＤＳＰ）、デジタル信号処理デバイス（ＤＳＰＤ）、プログラマブルロジックデバイス（ＰＬＤ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、コントローラ、マイクロコントローラ、マイクロプロセッサ、またはその他の電子コンポーネントによって実現されることができ、上記方法を実行するように構成される。

【0105】

例示的な実施例では、さらに、メモリ１３０４のような命令を含む非一時的なコンピュータ可読記憶媒体を提供している。前記命令は端末１３００のプロセッサ１３２０によって実行されて上記方法を完了することができる。前記非一時的なコンピュータ可読記憶媒体は、ＲＯＭ、ランダムアクセスメモリ（ＲＡＭ）、ＣＤ−ＲＯＭ、テープ、フロッピー（登録商標）ディスクおよび光データ記憶装置などであってよい。

【0106】

非一時的なコンピュータ可読記憶媒体であって、前記記憶媒体における命令が移動端末のプロセッサによって実行される場合、移動端末は、情報処理方法を実行することができる。前記方法は、
無線ネットワークの伝送リンクを通してピアデバイスの画面共有要求を取得したかどうかを判断することと、
ピアデバイスの画面共有要求を受信した場合、前記ピアデバイスのＩＰアドレスおよび前記ピアデバイスのポート番号を取得することと、
前記ＩＰアドレスおよび前記ポート番号に基づいて、ピアデバイス画面を再生するためのメディアデータに対応するユニフォームリソースロケータ（ＵＲＬ）を生成することと、
前記ＵＲＬに対応する標準プレーヤを確定することと、
前記標準プレーヤを利用して前記ＵＲＬに対応するメディアデータを再生することとを含む。

【0107】

本発明は、多数の汎用または専用コンピューティングシステムの環境または構成、例えばパーソナルコンピュータ、サーバコンピュータ、ハンドヘルドデバイスまたは便携用デバイス、タブレット型デバイス、マルチプロセッサシステム、マイクロプロセッサベースのシステム、セットトップボックス、プログラム可能な家庭用電子機器、ネットワークＰＣ、小型コンピュータ、大型コンピュータ、上記のシステムまたはデバイスを含む分散コンピューティング環境などに用いられることができると理解できる。

【0108】

本開示の実施例は、プログラムモジュールのような、コンピュータによって実行されるコンピュータ実行可能命令の一般的な文脈において説明されることができる。一般的に、プログラムモジュールは、特定のタスクを実行し、または特定の抽象データタイプを実現するルーチン、プログラム、オブジェクト、ユニット、データ構造などを含む。分散型コンピューティング環境で本発明を実践することも可能であり、これらの分散コンピューティング環境では、通信ネットワークを介して接続されるリモート処理デバイスによってタスクを実行する。分散型コンピューティング環境では、プログラムモジュールは、記憶デバイスを含むローカルおよびリモートコンピュータ記憶媒体に位置することができる。

【0109】

本明細書では、「第１」、「第２」などの関係用語は、一つのエンティティまたは操作を別のエンティティまたは操作と区別するためのものだけであり、必ずしもこれらのエンティティまたは操作の間にこのようないかなる実際の関係または順序があることを要求するまたは暗示するわけではない。また、用語「備える」、「含む」またはその変体が非排他的な包含をカバーすることを意図し、これにより、一連の要素を含むプロセス、方法、物品またはデバイスは、それらの要素を含むだけではなく、明示されていないその他の要素、または上記のプロセス、方法、物品またはデバイスが本来有している要素を含むということになる。特により多くの制限がない場合で、「……を含む」という文によって限定される要素は、前記要素を含むプロセス、方法、物品またはデバイスの中に別の同じ要素が存在している可能性もあると説明すべきである。

【0110】

本分野の当業者は、明細書を考慮してここで開示された発明を実践した後、本発明の他の実施形態を考える可能性が高い。本願は、本発明の任意の変形、用途または適応的変化をカバーすることを意図しており、これらの変形、用途または適応的変化が本発明の一般的な原理に従い且つ本開示の実施例で開示されていない本技術分野における公知常識または慣用技術手段を含むものとする。明細書および実施例は、例示的なものと見なされるだけであり、本発明の真の範囲および精神は、以下の特許請求の範囲によって示される。

【0111】

本発明は、上記で説明され且つ図面で示された精確な構造に限定されるものではなく、またその範囲を逸脱しなくて様々な修正および変更を行うことができると理解すべきである。本発明の範囲は、添付の特許請求の範囲によって限定されるものとする。

【産業上の利用可能性】

【0112】

本開示の実施例による情報処理方法および装置では、受信側が送信側に発見された場合、受信側と送信側との通信接続が確立され、通信接続中、受信側と送信側がいくつかの情報を交換してネゴシエーションを行い、ネゴシエーションが成功した場合、送信側デバイスの画面共有要求を取得したことを確定し、そうすると受信側は、送信側のＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ、インターネットプロトコル）アドレスおよびポート番号を取得してＵＲＬを生成し、受信側は、このＵＲＬに基づいてＵＲＬに対応する標準プレーヤを確定し、取得された標準プレーヤにより該メディアデータを再生する。本開示の実施例の受信側における標準プレーヤが独立した標準プレーヤであるので、送信側と受信側がデータ交換を行う時に利用したプロトコルが変化しても、受信側における標準プレーヤは、依然として送信側から伝送されたメディアデータを正常に再生することができる。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】