(57)【要約】【課題】ＯＳのメディアフレームワークなどの既存要素に手を入れることなく、サーバから取得したコンテンツに対してメディアフレームワークが実行できない処理を実行して再生すること。【解決手段】メディアフレームワークを有する通信端末であって、サーバが有するコンテンツの再生指示を受けた場合に、当該通信端末を示す特定アドレスにルート情報を付加して宛先を生成し、メディアフレームワークに対して宛先を含むコンテンツ要求を渡す第１コンテンツ要求部と、メディアフレームワークから特定アドレスとルート情報との宛先を含むゲット要求を受信した場合に、サーバに対してコンテンツを要求し、サーバから取得したコンテンツに対してメディアフレームワークが実行できないコンテンツ処理を実行して、ゲット要求に対するゲット応答として、コンテンツ処理を実行した処理済コンテンツをメディアフレームワークに送信するコンテンツ取得部と、を備える。【選択図】  図１
2014207506.tif 000002
【特許請求の範囲】
【請求項１】
コンテンツを再生するメディアフレームワークを有する通信端末であって、
サーバが有するコンテンツの再生指示を受けた場合、当該通信端末を示す特定アドレスにルート情報を付加して宛先を生成し、前記メディアフレームワークに対して前記宛先を含むコンテンツ要求を渡す第１コンテンツ要求手段と、
前記特定アドレスと前記ルート情報とで示される前記宛先を監視することで、前記メディアフレームワークから前記宛先を含むゲット要求を受信した場合に、前記サーバに対して前記コンテンツを要求し、前記サーバから取得した前記コンテンツに対して前記メディアフレームワークが実行できないコンテンツ処理を実行して、前記ゲット要求に対するゲット応答として、前記コンテンツ処理を実行した処理済コンテンツを前記メディアフレームワークに送信するコンテンツ取得手段と、
を備える通信端末。
【請求項２】
前記コンテンツ取得手段は、
前記特定アドレスと前記ルート情報とで示される宛先に対して前記メディアフレームワークから発行されるゲット要求を監視する監視手段と、
前記メディアフレームワークから前記宛先を含む前記ゲット要求を受信した場合に、サーバに対して前記コンテンツを要求する第２コンテンツ要求手段と、
前記第２コンテンツ要求手段による要求の応答として前記サーバから取得した前記コンテンツに対して、前記コンテンツ処理を実行する実行手段と、
前記実行手段が前記コンテンツ処理を実行した処理済コンテンツを、前記ゲット要求に対するゲット応答として前記メディアフレームワークに送信する送信手段と、
を含む請求項１に記載の通信端末。
【請求項３】
前記実行手段が実行する前記コンテンツ処理は、暗号化コンテンツの復号処理であって、
前記第２コンテンツ要求手段による前記サーバに対する前記暗号化コンテンツの要求に先立って、前記暗号化コンテンツを復号するための鍵を交換する鍵交換手段をさらに備える請求項２に記載の通信端末。
【請求項４】
前記実行手段が実行する前記コンテンツ処理は、前記サーバから取得した前記コンテンツのフォーマットを変換するトランスコード処理である請求項２または３に記載の通信端末。
【請求項５】
前記特定アドレスは、ローカル・ループバック・アドレスであり、前記ルート情報は、ポート番号である請求項１乃至４のいずれか１項に記載の通信端末。
【請求項６】
前記第１コンテンツ要求手段は、前記宛先に、さらに続いて前記コンテンツを取得するサーバのサーバアドレスと取得すべきコンテンツのコンテンツ名称とを付加して、前記メディアフレームワークに対して前記コンテンツ要求を渡し、
前記コンテンツ取得手段は、前記メディアフレームワークからの前記宛先を含む前記ゲット要求を、前記サーバアドレスへの前記コンテンツ名称のゲット要求に変更して、前記サーバに向けて送信する請求項１乃至５のいずれか１項に記載の通信端末。
【請求項７】
前記第１コンテンツ要求手段は、
前記コンテンツ取得手段に対してコンテンツを取得可能なサーバの検索を要求して、検索されたサーバを一覧表示させ、
前記コンテンツ取得手段に対してサーバ一覧表示から選択されたサーバを通知すると共に、前記選択されたサーバが保持するコンテンツの検索を要求して、検索されたコンテンツを一覧表示させ、
前記コンテンツ取得手段に対して、コンテンツ一覧表示から選択されたコンテンツ名称を通知すると共に、前記メディアフレームワークに対して、前記特定アドレスに前記ルート情報を付加して送信し、
前記コンテンツ取得手段は、
前記選択された前記サーバのサーバアドレスと前記選択されたコンテンツ名称とを記憶する記憶手段を有し、
前記メディアフレームワークから受信した前記宛先を含む前記ゲット要求を、記憶された前記サーバアドレスへの前記コンテンツ名称のゲット要求に変更して、前記サーバに向けて送信する請求項１乃至５のいずれか１項に記載の通信端末。
【請求項８】
前記第１コンテンツ要求手段は、さらに再生開始時間を付加して、前記メディアフレームワークに送信し、
前記コンテンツ取得手段は、前記取得すべきコンテンツの前記再生開始時間から以降を前記サーバから取得して前記メディアフレームワークに送信する請求項１乃至７のいずれか１項に記載の通信端末。
【請求項９】
サーバから取得したコンテンツを処理する複数のコンテンツ取得手段を有し、
前記第１コンテンツ要求手段は、前記特定アドレスに続いて、異なるルート情報を付加して前記宛先を生成し、
前記複数のコンテンツ取得手段の内、前記ルート情報に対応するコンテンツ取得手段が前記メディアフレームワークからゲット要求を受信する請求項１乃至８のいずれか１項に記載の通信端末。
【請求項１０】
自通信端末を示す特定アドレスとルート情報とで示される宛先に対してメディアフレームワークから発行されるゲット要求を監視するステップと、
前記メディアフレームワークから前記宛先を含む前記ゲット要求を受信した場合に、サーバに対してコンテンツを要求するステップと、
前記コンテンツの要求の応答として前記サーバから取得した前記コンテンツに対して、前記メディアフレームワークが実行できないコンテンツ処理を実行するステップと、
前記コンテンツ処理を実行した処理済コンテンツを、前記ゲット要求に対するゲット応答として前記メディアフレームワークに送信するステップと、
をコンピュータに実行させるモジュールプログラム。
【請求項１１】
サーバが有するコンテンツの再生指示を受けるステップと、
前記コンテンツの再生指示に応答して、自通信端末を示す特定アドレスに、前記サーバから前記コンテンツを取得してメディアフレームワークが実行できないコンテンツ処理を実行するモジュールへのルート情報を付加して宛先を生成し、前記メディアフレームワークに対して前記宛先を含むコンテンツ要求を渡すステップと、
をコンピュータに実行させるプレイヤープログラム。
【請求項１２】
コンテンツを再生するメディアフレームワークを有する通信端末のコンテンツ再生方法であって、
サーバが有するコンテンツの再生指示を受けるステップと、
前記コンテンツの再生指示に応答して、当該通信端末を示す特定アドレスにルート情報を付加して宛先を生成し、前記メディアフレームワークに対して前記宛先を含むコンテンツ要求を渡すステップと、
前記特定アドレスと前記ルート情報とで示される前記宛先に対して前記メディアフレームワークから発行されるゲット要求を受けると、前記サーバに対して前記コンテンツを要求するステップと、
前記コンテンツの要求の応答として前記サーバから取得した前記コンテンツに対して、前記メディアフレームワークが実行できないコンテンツ処理を実行するステップと、
前記コンテンツ処理を実行した処理済コンテンツを、前記ゲット要求に対するゲット応答として前記メディアフレームワークに送信するステップと、
を含むコンテンツ再生方法。
【請求項１３】
コンテンツを再生するメディアフレームワークを有する通信端末のコンテンツ再生プログラムであって、
サーバが有するコンテンツの再生指示を受けるステップと、
前記コンテンツの再生指示に応答して、当該通信端末を示す特定アドレスにルート情報を付加して宛先を生成し、前記メディアフレームワークに対して前記宛先を含むコンテンツ要求を渡すステップと、
前記特定アドレスと前記ルート情報とで示される前記宛先に対して前記メディアフレームワークから発行されるゲット要求を受けると、前記サーバに対して前記コンテンツを要求するステップと、
前記コンテンツの要求の応答として前記サーバから取得した前記コンテンツに対して、前記メディアフレームワークが実行できないコンテンツ処理を実行するステップと、
前記コンテンツ処理を実行した処理済コンテンツを、前記ゲット要求に対するゲット応答として前記メディアフレームワークに送信するステップと、
をコンピュータに実行させるコンテンツ再生プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、サーバから取得したコンテンツを再生する技術に関する。
【背景技術】
【０００２】
上記技術分野において、特許文献１には、デジタル・メディア統合フレームワーク(DMIF:digital media integration framework)で受信する、種々の暗号化方式で暗号化されたコンテンツを複数の復号器(decoder)で暗号化方式に対応して復号する技術が開示されている（図２参照）。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】米国特許第６，０９２，１０７号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
しかしながら、上記文献に記載の技術は、デジタル・メディア統合フレームワークの後に複数の復号器を接続して、デジタル・メディア統合フレームワークが有しない復号および再生の処理を実行する。そのため、映像や音声を再生する既存の通信機器に対して大がかりな設計変更を必要とする。その上、ＯＳのデジタル・メディア統合フレームワークなどのバージョンアップに際してさらに設計変更が必要となり、バージョンアップに簡単に対応することができなかった。
【０００５】
本発明の目的は、上述の課題を解決する技術を提供することにある。
【課題を解決するための手段】
【０００６】
上記目的を達成するため、本発明に係る装置は、
コンテンツを再生するメディアフレームワークを有する通信端末であって、
サーバが有するコンテンツの再生指示を受けた場合、当該通信端末を示す特定アドレスにルート情報を付加して宛先を生成し、前記メディアフレームワークに対して前記宛先を含むコンテンツ要求を渡す第１コンテンツ要求手段と、
前記特定アドレスと前記ルート情報とで示される前記宛先を監視することで、前記メディアフレームワークから前記宛先を含むゲット要求を受信した場合に、前記サーバに対して前記コンテンツを要求し、前記サーバから取得した前記コンテンツに対して前記メディアフレームワークが実行できないコンテンツ処理を実行して、前記ゲット要求に対するゲット応答として、前記コンテンツ処理を実行した処理済コンテンツを前記メディアフレームワークに送信するコンテンツ取得手段と、
を備える。
【０００７】
上記目的を達成するため、本発明に係るモジュールプログラムは、
自通信端末を示す特定アドレスとルート情報とで示される宛先に対してメディアフレームワークから発行されるゲット要求を監視するステップと、
前記メディアフレームワークから前記宛先を含む前記ゲット要求を受信した場合に、サーバに対してコンテンツを要求するステップと、
前記コンテンツの要求の応答として前記サーバから取得した前記コンテンツに対して、前記メディアフレームワークが実行できないコンテンツ処理を実行するステップと、
前記コンテンツ処理を実行した処理済コンテンツを、前記ゲット要求に対するゲット応答として前記メディアフレームワークに送信するステップと、
をコンピュータに実行させる。
【０００８】
上記目的を達成するため、本発明に係るプレイヤープログラムは、
サーバが有するコンテンツの再生指示を受けるステップと、
前記コンテンツの再生指示に応答して、自通信端末を示す特定アドレスに、前記サーバから前記コンテンツを取得してメディアフレームワークが実行できないコンテンツ処理を実行するモジュールへのルート情報を付加して宛先を生成し、前記メディアフレームワークに対して前記宛先を含むコンテンツ要求を渡すステップと、
をコンピュータに実行させる。
【０００９】
上記目的を達成するため、本発明に係る方法は、
コンテンツを再生するメディアフレームワークを有する通信端末のコンテンツ再生方法であって、
サーバが有するコンテンツの再生指示を受けるステップと、
前記コンテンツの再生指示に応答して、当該通信端末を示す特定アドレスにルート情報を付加して宛先を生成し、前記メディアフレームワークに対して前記宛先を含むコンテンツ要求を渡すステップと、
前記特定アドレスと前記ルート情報とで示される前記宛先に対して前記メディアフレームワークから発行されるゲット要求を受けると、前記サーバに対して前記コンテンツを要求するステップと、
前記コンテンツの要求の応答として前記サーバから取得した前記コンテンツに対して、前記メディアフレームワークが実行できないコンテンツ処理を実行するステップと、
前記コンテンツ処理を実行した処理済コンテンツを、前記ゲット要求に対するゲット応答として前記メディアフレームワークに送信するステップと、
を含む。
【００１０】
上記目的を達成するため、本発明に係るコンテンツ再生プログラムは、
コンテンツを再生するメディアフレームワークを有する通信端末のコンテンツ再生プログラムであって、
サーバが有するコンテンツの再生指示を受けるステップと、
前記コンテンツの再生指示に応答して、当該通信端末を示す特定アドレスにルート情報を付加して宛先を生成し、前記メディアフレームワークに対して前記宛先を含むコンテンツ要求を渡すステップと、
前記特定アドレスと前記ルート情報とで示される前記宛先に対して前記メディアフレームワークから発行されるゲット要求を受けると、前記サーバに対して前記コンテンツを要求するステップと、
前記コンテンツの要求の応答として前記サーバから取得した前記コンテンツに対して、前記メディアフレームワークが実行できないコンテンツ処理を実行するステップと、
前記コンテンツ処理を実行した処理済コンテンツを、前記ゲット要求に対するゲット応答として前記メディアフレームワークに送信するステップと、
をコンピュータに実行させる。
【発明の効果】
【００１１】
本発明によれば、ＯＳのメディアフレームワークなどの既存の構成要素に手を入れることなく、サーバから取得したコンテンツに対してメディアフレームワークが実行できない処理を実行して再生することができる。
【図面の簡単な説明】
【００１２】
【図１】本発明の第１実施形態に係る通信端末の機能構成を示すブロック図である。
【図２Ａ】本発明の第２実施形態に係る通信端末の構成および動作の概念を示す図である。
【図２Ｂ】本発明の第２実施形態に係る通信端末の表示部の表示例を示す図である。
【図３Ａ】本発明の第２実施形態に係る通信端末の動作手順を示すシーケンス図である。
【図３Ｂ】本発明の第２実施形態に係るコンテンツのゲット宛先の置き換えを説明する図である。
【図４Ａ】本発明の第２実施形態に係る通信端末の動作を順に示す図である。
【図４Ｂ】本発明の第２実施形態に係る通信端末の動作を順に示す図である。
【図４Ｃ】本発明の第２実施形態に係る通信端末の動作を順に示す図である。
【図４Ｄ】本発明の第２実施形態に係る通信端末の動作を順に示す図である。
【図４Ｅ】本発明の第２実施形態に係る通信端末の動作を順に示す図である。
【図４Ｆ】本発明の第２実施形態に係る通信端末の動作を順に示す図である。
【図５】本発明の第２実施形態に係る通信端末のハードウェア構成を示すブロック図である。
【図６Ａ】本発明の第２実施形態に係る通信端末の処理手順を示すフローチャートである。
【図６Ｂ】本発明の第２実施形態に係る自作プレイヤーの処理手順を示すフローチャートである。
【図６Ｃ】本発明の第２実施形態に係るメディアフレームワークの処理手順を示すフローチャートである。
【図６Ｄ】本発明の第２実施形態に係るHTTP Client & Daemonを含む自作モジュールの処理手順を示すフローチャートである。
【図７Ａ】本発明の第３実施形態に係る通信端末の構成および動作の概念を示す図である。
【図７Ｂ】本発明の第３実施形態に係る通信端末の表示部の表示例を示す図である。
【図８Ａ】本発明の第３実施形態に係る通信端末の動作手順を示すシーケンス図である。
【図８Ｂ】本発明の第３実施形態に係るコンテンツのゲット宛先の置き換えを説明する図である。
【図９Ａ】本発明の第３実施形態に係る通信端末の動作を順に示す図である。
【図９Ｂ】本発明の第３実施形態に係る通信端末の動作を順に示す図である。
【図９Ｃ】本発明の第３実施形態に係る通信端末の動作を順に示す図である。
【図９Ｄ】本発明の第３実施形態に係る通信端末の動作を順に示す図である。
【図１０】本発明の第３実施形態に係る通信端末の処理手順を示すフローチャートである。
【図１１Ａ】本発明の第３実施形態に係る自作プレイヤーの処理手順を示すフローチャートである。
【図１１Ｂ】本発明の第３実施形態に係るHTTP Client & Daemonを含む自作モジュールの処理手順を示すフローチャートである。
【図１２】本発明の第４実施形態に係る通信端末の動作手順を示すシーケンス図である。
【図１３Ａ】本発明の第４実施形態に係る自作プレイヤーの処理手順を示すフローチャートである。
【図１３Ｂ】本発明の第４実施形態に係るHTTP Client & Daemonを含む自作モジュールの処理手順を示すフローチャートである。
【図１４】本発明の第５実施形態に係る通信端末の動作手順を示すシーケンス図である。
【図１５】本発明の第５実施形態に係る通信端末の動作を示す図である。
【図１６Ａ】本発明の第６実施形態に係る通信端末の動作手順を示すシーケンス図である。
【図１６Ｂ】本発明の第６実施形態に係る通信端末の動作手順を示すシーケンス図である。
【図１７】本発明の第６実施形態に係る通信端末の動作を順に示す図である。
【図１８】本発明の第６実施形態に係る通信端末の動作を順に示す図である。
【図１９】本発明の第６実施形態に係る通信端末の処理手順を示すフローチャートである。
【図２０】本発明の第６実施形態に係るHTTP Client & Daemonを含む自作モジュールの処理手順を示すフローチャートである。
【図２１Ａ】本発明の第７実施形態に係る通信端末の動作を順に示す図である。
【図２１Ｂ】本発明の第７実施形態に係る通信端末の動作を順に示す図である。
【図２２】本発明の第８実施形態に係る通信端末を含むシステムの構成を示す図である。
【図２３】既存の通信端末のコンテンツ再生動作を示す図である。
【発明を実施するための形態】
【００１３】
以下に、図面を参照して、本発明の実施の形態について例示的に詳しく説明する。ただし、以下の実施の形態に記載されている構成要素は単なる例示であり、本発明の技術範囲をそれらのみに限定する趣旨のものではない。
【００１４】
［第１実施形態］
本発明の第１実施形態としての通信端末１００について、図１を用いて説明する。
【００１５】
図１に示すように、通信端末１００は、コンテンツを再生するメディアフレームワーク１２０を有する通信端末であり、第１コンテンツ要求部１１０と、コンテンツ取得部１３０と、を含む。第１コンテンツ要求部１１０は、サーバ１４０が有するコンテンツの再生指示を受けた場合に、当該通信端末を示す特定アドレス１１１にルート情報１１２を付加して宛先を生成し、メディアフレームワーク１２０に対して宛先を含むコンテンツ要求を渡す。コンテンツ取得部１３０は、特定アドレス１１１とルート情報１１２とで示される宛先を監視することで、メディアフレームワーク１２０から宛先を含むゲット要求(HTTP GET Request）を受信した場合に、サーバ１４０に対してコンテンツを要求する。次に、コンテンツ取得部１３０は、サーバ１４０から取得したコンテンツに対してメディアフレームワーク１２０が実行できないコンテンツ処理を実行する。そして、コンテンツ取得部１３０は、ゲット要求(HTTP GET Request）に対するゲット応答(HTTP GET Response)として、コンテンツ処理を実行した処理済コンテンツをメディアフレームワーク１２０に送信する。
【００１６】
また、コンテンツ取得部１３０は、監視部１３１と、第２コンテンツ要求部１３２と、実行部１３３と、送信部１３４と、を含む。監視部１３１は、特定アドレス１１１とルート情報１１２とで示される宛先に対してメディアフレームワーク１２０から発行されるゲット要求(HTTP GET Request）を監視する。第２コンテンツ要求部１３２は、メディアフレームワーク１２０からゲット要求(HTTP GET Request）を受信した場合に、サーバ１４０に対してコンテンツを要求する。実行部１３３は、第２コンテンツ要求部１３２による要求の応答としてサーバ１４０から取得したコンテンツに対して、コンテンツ処理を実行する。送信部１３４は、実行部１３３がコンテンツ処理を実行した処理済コンテンツを、ゲット要求(HTTP GET Request）に対するゲット応答(HTTP GET Response)としてメディアフレームワーク１２０に送信する。
【００１７】
本実施形態によれば、ＯＳのメディアフレームワークなどの既存の構成要素に手を入れることなく、サーバから取得したコンテンツに対してメディアフレームワークが実行できない処理を実行して再生することができる。なお、本実施形態における、コンテンツ一覧の情報は、第３実施形態のように「サーバ検索」や「コンテンツ検索」によって得られてもよいが、他の通信端末からのコンテンツ一覧や記憶媒体からのコンテンツ一覧などを取得してもよい。あるいは、あらかじめサーバに準備されたユーザの嗜好に合ったコンテンツ一覧であってもよい。
【００１８】
以下の第２実施形態乃至第８実施形態においては、メディアフレームワークが有しない機能あるいは実行できない処理として著作権保護コンテンツの復号機能やトランスコード処理を例に、さらに具体的な動作を説明する。しかしながら、本発明のメディアフレームワークが有しない機能は、著作権保護コンテンツの復号機能やトランスコード処理に限定されるものではない。他の暗号化に対応する復号機能を含み、さらに他のメディアフレームワークが有しない、コンテンツ再生に必要な他の機能をも含むものである。また、当該通信端末（自通信端末）を宛先とする特定アドレスとしてローカル・ループバック・アドレス、ルート情報としてポート番号を使用して説明するが、同様の機能を果たすものであればこれらに限定されない。
【００１９】
［第２実施形態］
次に、本発明の第２実施形態に係る通信端末について説明する。本実施形態の通信端末は、著作権保護されたコンテンツの再生指示があった場合に、第１コンテンツ要求部としての自作プレイヤーアプリケーションからメディアフレームワークに対して、ローカル・ループバック・アドレスのコンテンツに対するゲット要求(HTTP GET Request）を発行する。ローカル・ループバック・アドレスによるゲット要求先の、コンテンツ取得部としての自作モジュールは、コンテンツサーバから暗号化されたコンテンツを取得して復号し、ゲット応答(HTTP GET Response)として復号したコンテンツをメディアフレームワークに返す。
【００２０】
本実施形態によれば、ＯＳのビューシステムやメディアフレームワークに手を入れることなく、メディアフレームワークが有しない機能としての、著作権保護のため暗号化されたコンテンツの復号をすることができる。
【００２１】
なお、本実施形態の通信端末のソフトウェア構成は、Android（登録商標）端末のアーキテクチャに沿って説明するが、他の通信端末のソフトウェア構成においても同様に適用できるものである。また、本実施形態においては、コンテンツを再生するメディアフレームワークが、著作権保護の暗号化コンテンツを復号する機能を有しない例を説明する。
【００２２】
《既存の通信端末の動作》
まず、本実施形態の通信端末のコンテンツ再生動作の利点を明瞭にするため、図２３を参照して、既存の通信端末のコンテンツ再生動作を示す。
【００２３】
図２３に示すように、既存の通信端末においては、コンテンツのストリーミング再生指示があると、プレイヤーアプリケーションは、ストリーミング再生したいコンテンツの取得先およびコンテンツを示すＵＲＬを指定する。そして、プレイヤーアプリケーションは、ビューシステム(図面では、View System)を介し、メディアフレームワーク(図面では、Media Framework)にコンテンツ再生を要求する。メディアフレームワークは、指定されたＵＲＬによりサーバ（不図示）にコンテンツを要求する。
【００２４】
しかしながら、メディアフレームワークが著作権保護のため暗号化されたコンテンツの復号機能を有していない場合には、取得したコンテンツを再生することができない。その１つの解決先として、暗号化コンテンツを復号した後に再生させるように、メディアフレームワークのコードを修正する方法がある。しかしながら、修正の該当箇所を探すのが困難な上、ＯＳのメディアフレームワークなどのバージョンアップに伴いコードが変わる可能性があり、メンテナンス性が非常に乏しい。
【００２５】
《構成および動作の概念》
図２Ａは、本実施形態に係る通信端末２００の構成および動作の概念を示す図である。なお、図２Ａには、本実施形態の動作に関連する構成を示す。
【００２６】
図２Ａにおいて、通信端末２００は、入出力部２１０と、通信端末２００を動作させるためのソフトウェア構成２２０とを含む。入出力部２１０は、通信端末２００を操作するタッチパネルなどの操作部２１１と、操作ボタンや再生コンテンツを表示する表示部２１２と、マイクとスピーカを含む音声の入出力をする音声入出力部２１３と、を含む。
【００２７】
ソフトウェア構成２２０は、アプリケーション２３０と、アプリケーション・フレームワーク２４０と、ライブラリ２５０と、カーネル２６０と、から構成されている。図２Ａには、本実施形態に関連するソフトウェアとして、自作プレイヤー２３１と、ビューシステム２４１と、メディアフレームワーク２５１と、自作モジュール２５２と、ＷｉＦｉドライバ２６１と、が図示されている。これらが、コンテンツ再生プログラムに含まれる。第１コンテンツ要求部としての自作プレイヤー２３１は、アプリケーション２３０の１つであり、本通信端末２００をプレイヤーとして機能させ、著作権保護の暗号化コンテンツを復号するために作成されたプログラムである。ビューシステム２４１は、アプリケーション・フレームワーク２４０の１つであり、表示部２１２への表示ツールやフォーマットを提供するためのプログラムである。メディアフレームワーク２５１は、画像や音声や映像(Video)などのコンテンツを通信端末２００の内部あるいは外部から取得して再生するためのプログラムである。コンテンツ取得部としての自作モジュール２５２は、ライブラリ２５０の１つであり、本実施形態においては実行部としての復号部２５３を有し、著作権保護の暗号化コンテンツを復号するために作成されたプログラムである。ＷｉＦｉドライバ２６１は、カーネル２６０の１つであり、メディアフレームワーク２５１や本実施形態の自作モジュール２５２、あるいはその他の機能要素とネットワークを介した通信を行なうプログラムである。
【００２８】
本実施形態においては、ＷｉＦｉドライバ２６１を介して著作権保護コンテンツ２７１をコンテンツサーバ２７０から取得する。なお、コンテンツサーバ２７０は、通信端末２００の外部にあっても、通信端末２００の内部にあってもよい。
【００２９】
本実施形態において、表示部２１２に表示されたコンテンツ一覧から操作部２１１を介してユーザが選択したコンテンツについて、自作プレイヤー２３１が、既存のビューシステム２４１やメディアフレームワーク２５１を使用しながら、自作モジュール２５２にコンテンツ取得を要求する。自作モジュール２５２は、コンテンツサーバ２７０から著作権保護コンテンツ２７１を取得して復号部２５３で復号して、復号機能を有しないメディアフレームワーク２５１に復号した著作権保護コンテンツ２７１を渡す。このような構成により、既存のビューシステム２４１やメディアフレームワーク２５１に手を付けることなく、メディアフレームワーク２５１が有しない機能である、著作権保護コンテンツ２７１の復号を実現する。
【００３０】
《表示例》
図２Ｂは、本実施形態に係る通信端末２００の表示部２１２の表示例を示す図である。
【００３１】
表示画面２８０には、コンテンツ一覧が表示されている。そして、ユーザが、「再生するコンテンツ」２８１を選択した状態である。「再生するコンテンツ」の取得先アドレスとコンテンツ名称とは、“http://192.168.10.100/play.mp4”である。
【００３２】
表示画面２９０には、取得されたコンテンツが復号されて映像２９１が出力されている。なお、図２Ｂにおいては明瞭ではないが、映像２９１として、既存の通信端末２００が有するビューシステム２４１やメディアフレームワーク２５１により再生された、同じフォーマットや調整の映像が出力される。
【００３３】
《通信端末の動作手順》
図３Ａは、本実施形態に係る通信端末２００の動作手順を示すシーケンス図である。
【００３４】
ステップＳ３０１において、自作プレイヤー２３１は、ビューシステム２４１を利用して、表示部２１２に対しコンテンツ一覧の表示を指示する。表示部２１２は、ステップＳ３０３において、コンテンツ一覧を表示する。そして、操作部２１１においてユーザによるコンテンツ選択が行なわれると、ステップＳ３０５において、ビューシステム２４１は、選択されたリストを検出して、自作プレイヤー２３１に送信する。
【００３５】
自作プレイヤー２３１は、選択されたコンテンツがサーバから取得するものであれば、ステップＳ３０７において、取得先アドレスであるサーバアドレスではなく、ローカル・ループバック・アドレスを宛先としてメディアフレームワーク２５１にコンテンツ再生を要求する。ローカル・ループバック・アドレスには、所定のポート番号と任意のコンテンツ名称と、さらにサーバアドレスと取得すべきコンテンツ名称を付加する。なお、本例においては、任意のコンテンツ名称はフォーマット上の意味の無いデータであるが、オプションとして有意な情報として使用されてよい。
【００３６】
ローカル・ループバック・アドレスを受けたメディアフレームワーク２５１は、ステップＳ３０９において、ローカル・ループバック・アドレスを宛先として指定された所定のポート番号にゲット要求(HTTP Get Request)を発行する。その際、図３Ｂに示すように要求コンテンツ名称として、ポート番号以降の文字列が指定される。      
【００３７】
ローカル・ループバック・アドレスを宛先とする所定のポート番号へのゲット要求(HTTP GET Request）を監視していた自作モジュール２５２は、メディアフレームワーク２５１からのゲット要求(HTTP GET Request）を受信する。そして、自作モジュール２５２は、ステップＳ３１１において、図３Ｂに示すように、コンテンツ取得先とコンテンツ名称とを、メディアフレームワークからのゲット要求に設定されたサーバアドレスとコンテンツ名称とに置き換える。そして、自作モジュール２５２は、ステップＳ３１３において、コンテンツサーバ２７０に対して本例では著作権保護コンテンツを要求する。コンテンツサーバ２７０は、ステップＳ３１５において、コンテンツを検索し送信する。なお、煩雑になるので詳細な図示は避けるが、暗号化された著作権保護コンテンツを復号するための鍵を、認証を受けて取得する。自作モジュール２５２は、ステップＳ３１７において、取得した鍵を使用して復号部２５３において取得したコンテンツを復号する。そして、自作モジュール２５２は、ステップＳ３１９において、メディアフレームワーク２５１からのゲット要求(HTTP GET Request）に応答するゲット応答(HTTP GET Response)によって、復号されたコンテンツをメディアフレームワーク２５１に送信する。
【００３８】
復号されたコンテンツを受信したメディアフレームワーク２５１は、ステップＳ３２１において、コンテンツのデコードを実施し、ビューシステム２４１を利用して、表示部２１２（および／または音声出力部）に対して、デコードされたコンテンツの提示を指示する（Ｓ３２３、Ｓ３２５参照）。
【００３９】
なお、メディアフレームワーク２５１、自作モジュール２５２、コンテンツサーバ２７０間の通信は、RFC2616(HTTP/1.1)に準拠するゲット要求(HTTP GET Request）とゲット応答(HTTP GET Response)とにより行なわれる。また、自作プレイヤー２３１からのローカル・ループバック・アドレスを宛先とするコンテンツ要求は、ＯＳにより当該通信端末内部へのゲット要求(HTTP GET Request）となる。したがって、メディアフレームワーク２５１から自作モジュール２５２へのゲット要求が発行され、それに対する応答として復号コンテンツが渡される。同様に、宛先をサーバに置き換えた自作モジュール２５２からコンテンツサーバ２７０へのゲット要求に応答するゲット応答により、サーバからの暗号化コンテンツが自作モジュール２５２により取得される。また、図３Ａおよび以降のシーケンス図においては、煩雑さを避けるためにコンテンツ取得と再生を１回示しているが、実際のストリーミング再生においては所定長のコンテンツが繰り返し送信されて、復号および再生が繰り返される。
【００４０】
《ゲット宛先の置き換え》
図３Ｂは、本実施形態に係るコンテンツのゲット宛先の置き換えを説明する図である。
【００４１】
ゲット要求３１０は、メディアフレームワーク２５１から自作モジュール２５２に渡されるゲット要求(HTTP GET Request）のフォーマット例である。ゲット要求３１０では、宛先であるホスト(以下、Host)はローカル・ループバック・アドレス(127.0.0.1)のポート番号20000であり、取得対象のコンテンツ名称として“target.mp4/192.168.10.100/play.mp4”が付加されている。この内、“target.mp4”はローカル・ループバック・アドレスで取得対象とする任意のコンテンツ名称である。“192.168.10.100”３１１はサーバアドレスである。“play.mp4”３１２は再生すべきコンテンツ名称である。
【００４２】
ゲット要求３２０は、自作モジュール２５２がサーバから再生すべきコンテンツを取得するためのゲット要求(HTTP GET Request）である。ゲット要求３２０においては、Hostがローカル・ループバック・アドレス(127.0.0.1)のポート番号20000から、サーバアドレス“192.168.10.100”３２１に置き換わっている。また、コンテンツ名称が、再生すべきコンテンツ名称“play.mp4”３２２に置き換わっている。
【００４３】
メディアフレームワーク２５１は、自作プレイヤー２３１から再生要求を受けた場合、既存の処理手順に従って、ローカル・ループバック・アドレスのポート番号20000にゲット要求(HTTP GET Request）を発行する。それで、自作モジュール２５２がサーバから再生すべきコンテンツを取得して復号し、メディアフレームワーク２５１が処理可能な復号したコンテンツをゲット要求(HTTP GET Request）へのゲット応答(HTTP GET Response)として取得することができる。すなわち、既存のメディアフレームワーク２５１を使用した復号コンテンツの取得が可能になる。
【００４４】
《通信端末の動作》
図４Ａ〜図４Ｆは、図３Ａに示したシーケンスに従った通信端末２００の動作を順により詳細に示す図である。なお、自作モジュール２５２は、HTTP Client & DaemonとDTCP-IPとUPnPとを含むように示されているが、これに限定されない。本例では、自作モジュール２５２の本体である“HTTP Client & Daemon”と、復号部である“DTCP-IP”と、通信プロトコルを提供する“UPnP”とが一例として示されている。
【００４５】
図４Ａは、通信端末２００の表示画面に表示されたコンテンツの一覧表示から「再生するコンテンツ」が選択された時点である。その時の、通信端末２００の表示画面２８０と対応するソフトウェア構成２２０の状態とを示す図である。この処理４１０では、ビューシステム２４１により、(11)サーバのコンテンツリストを表示した状態から、(12)ユーザが、再生するコンテンツを選択してタップしたことを検出し、自作プレイヤー２３１に通知する。
【００４６】
図４Ｂは、自作プレイヤー２３１からビューシステム２４１を経由してメディアフレームワーク２５１に伝えられる、通信端末２００の対応するソフトウェア構成２２０の状態を示す図である。まず、処理４２０では、(13)自作プレイヤー２３１からビューシステム２４１に、再生コンテンツ取得の情報である“http://127.0.0.1:20000/target.mp4/192.168.10.100/play.mp4”が伝えられる。そして、処理４３０では、(13)ビューシステム２４１からメディアフレームワーク２５１に、再生コンテンツ取得の情報である“http://127.0.0.1:20000/target.mp4/192.168.10.100/play.mp4”がそのまま伝えられる。
【００４７】
図４Ｃは、メディアフレームワーク２５１がローカル・ループバック・アドレス(127.0.0.1)を受けて、ゲット要求(HTTP GET Request）をポート番号(20000)に出力する時点である。その時の、通信端末２００の対応するソフトウェア構成２２０の状態を示す図である。処理４４０では、(15)メディアフレームワーク２５１は、127.0.0.1に対して、コンテンツ取得要求（HTTP Get Request)を行う（図３Ｂのゲット要求３１０参照）。
【００４８】
図４Ｄは、自作モジュール２５２が、メディアフレームワーク２５１から発行されたゲット要求(HTTP GET Request）の宛先と再生すべきコンテンツ名称とを置き換えて、サーバに対してコンテンツをゲット要求する時点である。その時の、通信端末２００の対応するソフトウェア構成２２０の状態を示す図である。処理４５０では、(16)自作モジュール２５２のHTTP Client & Daemonが、メディアフレームワーク２５１から発行されたゲット要求の「送信宛先」と「コンテンツ名称」とを差し替え、サーバ（http://192.168.10.100)に対してコンテンツ(play.mp4)のゲット要求を発行する（図３Ｂのゲット要求３２０参照）。
【００４９】
図４Ｅは、自作モジュール２５２が、サーバから送信された暗号化コンテンツを受信して、復号して、メディアフレームワーク２５１に対してゲット要求(HTTP GET Request）へのゲット応答(HTTP GET Response)として送信する時点である。その時の、通信端末２００の対応するソフトウェア構成２２０の状態を示す図である。処理４６０では、(17)サーバから暗号化データを受信したら、平文に復号した後に、メディアフレームワーク２５１に対してHTTP Get Responseでデータを転送する。
【００５０】
図４Ｆは、メディアフレームワーク２５１が、自作モジュール２５２から復号コンテンツを受信して、ビューシステム２４１を利用して、表示部２１２（および／または音声出力部）に対して、デコードされたコンテンツを出力する時点である。その時の、通信端末２００の表示画面２９０に再生した映像２９１と対応するソフトウェア構成２２０の状態を示す図である。処理４７０では、(18)メディアフレームワーク２５１でリンクプロテクション（暗号）されたコンテンツの再生が行われる。
【００５１】
《通信端末のハードウェア構成》
図５は、本実施形態に係る通信端末２００のハードウェア構成を示すブロック図である。
【００５２】
図５で、ＣＰＵ(Central Processing Unit)５１０は演算制御用のプロセッサであり、プログラムを実行することで図１および図２Ａの通信端末２００の機能構成部を実現する。ＲＯＭ(Read Only Memory)５２０は、初期データおよびプログラムなどの固定データおよびプログラムを記憶する。また、通信制御部５３０は、ネットワークあるいはＬＡＮを介して他の通信端末や各サーバと通信する。
【００５３】
なお、ＣＰＵ５１０は１つに限定されず、複数のＣＰＵであっても、あるいは画像処理用のＧＰＵを含んでもよい。また、通信制御部５３０は、ＣＰＵ５１０とは独立したＣＰＵを有して、ＲＡＭ５４０の領域に送受信データを書き込みあるいは読み出しするのが望ましい。また、ＲＡＭ５４０とストレージ５５０との間でデータを転送するＤＭＡＣを設けるのが望ましい（図示なし）。さらに、入出力インタフェース５６０は、ＣＰＵ５１０とは独立したＣＰＵを有して、ＲＡＭ５４０の領域に入出力データを書き込みあるいは読み出しするのが望ましい。したがって、ＣＰＵ５１０は、ＲＡＭ５４０にデータが受信あるいは転送されたことを認識してデータを処理する。また、ＣＰＵ５１０は、処理結果をＲＡＭ５４０に準備し、後の送信あるいは転送は通信制御部５３０やＤＭＡＣ、あるいは入出力インタフェース５６０に任せる。
【００５４】
ＲＡＭ５４０は、ＣＰＵ５１０が一時記憶のワークエリアとして使用するランダムアクセスメモリである。ＲＡＭ５４０には、本実施形態の実現に必要なデータを記憶する領域が確保されている。サーバ一覧５４１は、本通信端末２００がコンテンツを取得可能なサーバ一覧のデータである。選択サーバアドレス５４２は、ユーザがサーバ一覧から選択したサーバのアドレスである。コンテンツ一覧５４３は、選択したサーバに格納されたコンテンツ一覧のデータである。選択コンテンツ名称５４４は、コンテンツ一覧からユーザが再生指示したコンテンツの名称（あるいはＩＤ）である。自作モジュールへのゲット要求５４５は、自作プレイヤー２３１からのローカル・ループバック・アドレスを受けたメディアフレームワーク２５１が発行する、ゲット要求メッセージである。サーバへのゲット要求５４６は、コンテンツサーバ２７０へのゲット要求メッセージである。ここでは、メディアフレームワーク２５１からのゲット要求(HTTP GET Request）を受けた自作モジュール２５２がコンテンツ要求先をサーバに置き換え、コンテンツ名称を再生すべきコンテンツ名称に置き換える。受信コンテンツデータ５４７は、サーバから自作モジュール２５２が取得した暗号化コンテンツである。復号コンテンツデータ５４８は、自作モジュール２５２が復号したコンテンツである。入出力データ５４９は、入出力インタフェース５６０を介して入出力されるデータである。
【００５５】
ストレージ５５０には、データベースや各種のパラメータ、あるいは本実施形態の実現に必要な以下のデータまたはプログラムが記憶されている。アプリケーション２３０と、アプリケーション・フレームワーク２４０と、ライブラリ２５０と、カーネル２６０とは、本通信端末２００に搭載された既存のプログラムである。アプリケーション・フレームワーク２４０には既存のビューシステム２４１が含まれ、ライブラリ２５０には既存のメディアフレームワーク２５１が含まれ、カーネル２６０には既存のＷｉＦｉドライバ２６１が含まれる。
【００５６】
通信端末制御プログラム５５１は、本通信端末２００全体を制御する制御プログラムである（図６Ａ参照）。自作プレイヤー２３１は、アプリケーション２３０に含まれるが、本実施形態において作成された特徴を有するプログラムである（図６Ｂ参照）。また、自作モジュール２５２は、ライブラリ２５０に含まれるが、本実施形態において新たに作成された特徴を有するプログラムである（図６Ｄ参照）。本実施形態においては、自作モジュール２５２には、HTTP Client & DaemonとDTCP-IPとUPnPが含まれる。
【００５７】
入出力インタフェース５６０は、入出力機器との入出力データをインタフェースする。入出力インタフェース５６０には、表示部２１２、タッチパネル／キーボードなどの操作部２１１、が接続される。また、スピーカやマイクなどの音声入出力部２１３が接続される。さらに、撮像部５６１やＧＰＳ位置検出部５６２も接続される。なお、本通信端末２００に内蔵されるコンテンツとして、例えば、ＳＤ」カードなどのコンテンツ格納部５６が接続される。なお、図５のＲＡＭ５４０やストレージ５５０には、通信端末２００が有する汎用の機能や他の実現可能な機能に関連するプログラムやデータは図示されていない。
【００５８】
《通信端末の処理手順》
図６Ａは、本実施形態に係る通信端末２００の処理手順を示すフローチャートである。このフローチャートは、図５のＣＰＵ５１０がＲＡＭ５４０を使用しながら実行して、図１および図２Ａの機能構成部を実現する。
【００５９】
通信端末２００は、ステップＳ６０１において、コンテンツ一覧を表示する。通信端末２００は、ステップＳ６０３において、ユーザがコンテンツ一覧から再生したいコンテンツを選択指示するのを待つ。選択指示があれば、通信端末２００は、ステップＳ６０５において、自作プレイヤー２３１がローカル・ループバック・アドレスに対してコンテンツ要求を発行する。
【００６０】
通信端末２００は、ステップＳ６０７において、ローカル・ループバック・アドレスに対してコンテンツ要求を受けたメディアフレームワーク２５１が、ローカル・ループバック・アドレスを宛先とするゲット要求(HTTP GET Request）を発行する。通信端末２００は、ステップＳ６０９において、メディアフレームワーク２５１が発行したゲット要求(HTTP GET Request）を受けた自作モジュールが、コンテンツサーバ２７０から著作権保護コンテンツ２７１を取得する。そして、この著作権保護コンテンツ２７１を復号して、メディアフレームワーク２５１にゲット応答(HTTP GET Response)として送る。
【００６１】
通信端末２００は、ステップＳ６１１において、既存のコンテンツ再生手順に従ってコンテンツを再生出力する。
【００６２】
（自作プレイヤーの処理手順）
図６Ｂは、本実施形態に係る自作プレイヤープログラムである自作プレイヤー２３１の処理手順を示すフローチャートである。
【００６３】
自作プレイヤー２３１は、ステップＳ６２１において、コンテンツ一覧の表示をビューシステム２４１に指示する。自作プレイヤー２３１は、ステップＳ６２３において、ビューシステム２４１からの、ユーザがコンテンツ一覧から再生したいコンテンツを選択指示した情報を待つ。選択指示をビューシステム２４１から取得すれば、自作プレイヤー２３１は、ステップＳ６２５において、ローカル・ループバック・アドレスに、ポート番号（本例では、20000）と任意のコンテンツ名称（本例では、有意なものではない）、さらに、サーバアドレスと再生すべきコンテンツ名称とを付加する。そして、自作プレイヤー２３１は、ステップＳ６２７において、メディアフレームワーク２５１に対して、ビューシステム２４１を経由して、ローカル・ループバック・アドレスによる再生要求を発行する。
【００６４】
なお、メディアフレームワーク２５１からのコンテンツの受信を待って、自作プレイヤー２３１が設定したフォーマットでコンテンツを出力するのはビューシステム２４１の処理であるが、既存の手順でありここでは説明を省略する。
【００６５】
（メディアフレームワークの処理手順）
図６Ｃは、本実施形態に係るメディアフレームワーク２５１の処理手順を示すフローチャートである。
【００６６】
メディアフレームワーク２５１は、ステップＳ６４１において、自作プレイヤー２３１からビューシステム２４１を経由してコンテンツの再生要求を受信する。メディアフレームワーク２５１は、ステップＳ６４３において、指定されたＵＲＩを基に指定された宛先に対して、指定されたコンテンツのゲット要求を発行する。すなわち、指定されたＵＲＩの宛先がローカル・ループバック・アドレスであれば、ローカル・ループバック・アドレスに対して（自作モジュールに対して）、ゲット要求が発行され、宛先が実際のサーバアドレスであれば、実際のサーバに対してゲット要求が発行される。本例では、ローカル・ループバック・アドレスのポート番号（本例では、20000）に対して、ゲット要求(HTTP GET Request）が発行される。
【００６７】
メディアフレームワーク２５１は、ステップＳ６４５において、ゲット応答(HTTP GET Response)を待つ。ゲット応答(HTTP GET Response)を受信すると、メディアフレームワーク２５１は、ステップＳ６４７において、ビューシステム２４１に対して受信した平文コンテンツをデコードした結果を再生コンテンツとして送信する。
【００６８】
（自作モジュールの処理手順）
図６Ｄは、本実施形態に係るHTTP Client & Daemonを含む自作モジュールプログラムである自作モジュール２５２の処理手順を示すフローチャートである。
【００６９】
自作モジュール２５２は、ステップＳ６６１において、所定のポート番号（本例では、20000）に発行されたゲット要求(HTTP GET Request）を受信する。ゲット要求(HTTP GET Request）を受信すると、自作モジュール２５２は、ステップＳ６６３において、ゲット要求(HTTP GET Request）の宛先をサーバアドレスに、コンテンツ名称を再生すべきコンテンツ名称に置き換える。
【００７０】
自作モジュール２５２は、ステップＳ６６５において、再生すべきコンテンツが著作権保護コンテンツか否かを判定する。著作権保護コンテンツであれば、自作モジュール２５２は、ステップＳ６６７において、機器認証と鍵交換（Authentication and Key Exchange：AKE）を行なう。
【００７１】
自作モジュール２５２は、ステップＳ６６９において、サーバに対して、宛先をサーバアドレスに、コンテンツ名称を再生すべきコンテンツ名称に置き換えたゲット要求(HTTP GET Request）を発行する。そして、自作モジュール２５２は、ステップＳ６７１において、再生すべきコンテンツをサーバから受信する。
【００７２】
自作モジュール２５２は、ステップＳ６７３において、再生すべきコンテンツが著作権保護コンテンツか否かを判定する。著作権保護コンテンツであれば、自作モジュール２５２は、ステップＳ６７５において、鍵交換で得た鍵によりコンテンツデータの復号を行なう。そして、自作モジュール２５２は、ステップＳ６７７において、復号したコンテンツデータをゲット応答(HTTP GET Response）として、メディアフレームワーク２５１に返信する。
【００７３】
なお、機器認証と鍵交換は本例の手順に限定されない。手順の前後は自由に変更可能である。
【００７４】
本実施形態によれば、ＯＳのビューシステムやメディアフレームワークに手を入れることなく、メディアフレームワークが有しない機能としての、著作権保護のため暗号化されたコンテンツの復号をすることができる。
【００７５】
［第３実施形態］
次に、本発明の第３実施形態に係る通信端末について説明する。本実施形態に係る通信端末は、上記第２実施形態と比べると、自作プレイヤーが、メディアプレイヤーに対してサーバアドレスや再生すべきコンテンツ名称を送らなくても、自作モジュールにおいて置き換えてサーバをアクセスする点で異なる。その他の構成および動作は、第２実施形態と同様であるため、同じ構成および動作については同じ符号を付してその詳しい説明を省略する。
【００７６】
本実施形態によれば、ユーザが再生したいコンテンツを選択するまでの手順で、サーバアドレスや再生すべきコンテンツ名称が取得されるので、自作プレイヤーから自作モジュールへのゲット要求を簡素化できる。
【００７７】
《構成および動作の概念》
図７Ａは、本実施形態に係る通信端末７００の構成および動作の概念を示す図である。なお、図７Ａには、本実施形態の動作に関連する構成を示す。また、図７Ａにおいて、図２Ａと同様の構成要素には同じ参照番号を付して、説明は省略する。
【００７８】
図７Ａにおいて、図２Ａとの相違点は、ソフトウェア構成７２０において、アプリケーション７３０の自作プレイヤー７３１とライブラリ７５０の自作モジュール７５２との間の、ユーザのコンテンツ選択に先立つ手順において、コンテンツ要求先のサーバアドレスと再生すべきコンテンツ名称とを取得する点である。自作モジュール７５２は、サーバアドレスと再生すべきコンテンツ名称とを記憶する記憶部７５４を有している。
【００７９】
《表示例》
図７Ｂは、本実施形態に係る通信端末７００の表示部２１２の表示例を示す図である。
【００８０】
通信端末７００の表示画面７６０は、通信端末７００がアクセス可能なコンテンツサーバ一覧を要求するボタン７６１を表示している。なお、表示画面７６０は図７Ｂに限定されない。通信端末７００の表示画面７７０は、コンテンツサーバ一覧表示から映画コンテンツサーバ７７１が選択された画面であり、映画コンテンツサーバ７７１に格納されたコンテンツ一覧が要求される。通信端末７００の表示画面７８０は、映画コンテンツサーバ７７１のコンテンツ一覧が表示された画面である。通信端末７００の表示画面２８０は、コンテンツ一覧から「再生するコンテンツ」２８１が選択された画面である。かかる表示画面２８０は、図２Ｂの表示画面２８０と同様である。以下、サーバアドレスと再生すべきコンテンツ名称とが、自作モジュール７５２の記憶部７５４から取得される以外は、コンテンツの取得、復号、再生、出力の手順は、第２実施形態と同様であるので、詳細な説明は省略する。
【００８１】
《通信端末の動作手順》
図８Ａは、本実施形態に係る通信端末７００の動作手順を示すシーケンス図である。なお、図８Ａにおいて、図３Ａと同様の構成要素またはステップには同じ参照番号や同じステップ番号を付して、説明は省略する。
【００８２】
ユーザからの操作部２１１を介したサーバ一覧表示の指示を、ビューシステム２４１が、ステップＳ８０１において、自作プレイヤー７３１に送信する。自作プレイヤー７３１は、ステップＳ８０３において、自作モジュール７５２に対して、本通信端末７００がアクセス可能なサーバ検索を指示する。サーバ検索指示を受けて、自作モジュール７５２は、ステップＳ８０５において、コンテンツサーバ２７０〜２７ｎに対する検索を実行する。コンテンツサーバ２７０〜２７ｎは、ステップＳ８０７において、検索に対して応答する。自作モジュール７５２は、ステップＳ８０９において、検索結果のサーバ一覧を自作プレイヤー７３１に送信すると共に、記憶部７５４にサーバアドレスを保持する。
【００８３】
自作モジュール７５２からサーバ一覧を受け取った自作プレイヤー７３１は、ステップＳ８１１において、サーバ一覧の表示をビューシステム２４１に指示する。表示部２１２は、ステップＳ８１３において、サーバ一覧を表示する。そして、ユーザからの操作部２１１を介したサーバ選択指示を、ビューシステム２４１が、ステップＳ８１５において、自作プレイヤー７３１に送信する。ここで、コンテンツサーバ２７０が選択されたと仮定する。自作プレイヤー７３１は、ステップＳ８１６において、選択されたサーバを自作モジュール７５２に通知し、自作モジュール７５２は、選択されたサーバを記憶部７５４に記憶して保持する。
【００８４】
自作プレイヤー７３１は、ステップＳ８１７において、自作モジュール７５２に対して、ユーザが選択したサーバに格納されたコンテンツ検索を指示する。コンテンツ検索指示を受けて、自作モジュール７５２は、ステップＳ８１９において、コンテンツサーバ２７０に対するコンテンツ検索を実行する。コンテンツサーバ２７０は、ステップＳ８２１において、コンテンツ検索に対して応答する。自作モジュール７５２は、ステップＳ８２３において、検索結果のコンテンツ一覧を自作プレイヤー７３１に送信すると共に、記憶部７５４にコンテンツ名称を保持する。
【００８５】
自作モジュール７５２からコンテンツ一覧を受け取った自作プレイヤー７３１は、ステップＳ８２５において、コンテンツ一覧表示をビューシステム２４１に指示する。その後、第２実施形態の図３Ａのシーケンスに移行する。ただし、ユーザによるコンテンツ選択情報は、ステップＳ８２７において、自作プレイヤー７３１から自作モジュール７５２に送られて、ステップＳ８２９において、自作モジュール７５２の記憶部７５４に記憶される。
【００８６】
《ゲット宛先の置き換え》
図８Ｂは、本実施形態に係るコンテンツのゲット宛先の置き換えを説明する図である。なお、図８Ｂにおいて、図３Ｂと同様なデータには同じ参照番号を付す。
【００８７】
ゲット要求８１０は、メディアフレームワーク２５１から自作モジュール７５２に渡されるゲット要求(HTTP GET Request）のフォーマット例である。ゲット要求８１０では、ゲット宛先(Host)はローカル・ループバック・アドレス(127.0.0.1)のポート番号20000であり、ゲット対象のコンテンツ名称として“target.mp4”のみが渡される。
【００８８】
記憶部７５４には、サーバ一覧表示、サーバ選択、コンテンツ一覧表示、コンテンツ選択の手順の中で自作モジュール７５２が取得した、接続対象のサーバアドレス８２２と再生対象のコンテンツ名称８２１（ＩＤ８２３）が保持されている。
【００８９】
ゲット要求３２０は、自作モジュール７５２がサーバから再生すべきコンテンツを取得するためのゲット要求(HTTP GET Request）である。ゲット要求３２０においては、ゲット宛先(Host)がローカル・ループバック・アドレス(127.0.0.1)のポート番号20000から、記憶部７５４に記憶されたサーバアドレス“192.168.10.100”３２１に置き換わっている。また、ゲット対象のコンテンツ名称が、記憶部７５４に記憶された再生すべきコンテンツ名称“play.mp4”３２２に置き換わっている。
【００９０】
このように、本実施形態においては、自作プレイヤー７３１が発行するローカル・ループバック・アドレスのポート番号20000へのゲット要求(HTTP GET Request）に、サーバアドレスと再生すべきコンテンツ名称とを付加しない。それでも、自作モジュール７５２がサーバから再生すべきコンテンツを取得して復号し、メディアフレームワーク２５１が処理可能な復号したコンテンツをゲット要求(HTTP GET Request）へのゲット応答(HTTP GET Response)として取得することができる。すなわち、既存のメディアフレームワーク２５１を使用した復号コンテンツの取得が可能になる。
【００９１】
《通信端末の動作》
図９Ａ〜図９Ｄは、図７Ａに示したシーケンスに従った通信端末７００の動作を順により詳細に示す図である。なお、自作モジュール２５２は、HTTP Client & DaemonとDTCP-IPとUPnPとを含むように示されているが、これに限定されない。本例では、自作モジュール２５２の本体である“HTTP Client & Daemon”と、復号部である“DTCP-IP”と、通信プロトコルを提供する“UPnP”とが一例として示されている。
【００９２】
図９Ａは、ユーザが通信端末７００からアクセス可能なサーバの一覧表示を要求して、取得したサーバ一覧を表示した時点の、通信端末７００の表示画面７６０と対応するソフトウェア構成７２０の状態とを示す図である。この処理９１０では、(21)自作プレイヤー７３１は自作モジュール７５２に対して、サーバ検索を要求する。(22)サーバ検索結果を取得してビューシステム２４１がリスト表示し、ユーザに選択を促し、自作モジュール７５２は、得られた検索結果を保持しておく。
【００９３】
図９Ｂは、ユーザが通信端末７００からサーバ一覧の１つのサーバを選択した時点の、通信端末７００の表示画面７７０と対応するソフトウェア構成７２０の状態とを示す図である。この処理９２０では、(23)ユーザがサーバを選択した場合、自作プレイヤー７３１は、ビューシステム２４１から得た選択されたサーバの情報を自作モジュール７５２に設定するので、自作モジュール７５２は、現在どのサーバが「対象サーバ」かがわかる。
【００９４】
図９Ｃは、ユーザのサーバ選択に応答して、コンテンツ一覧表示を要求して、取得したコンテンツ一覧を表示した時点の、通信端末７００の表示画面７８０と対応するソフトウェア構成７２０の状態とを示す図である。この処理９３０では、(24)自作プレイヤー７３１は自作モジュール７５２に対して、コンテンツリスト取得を要求する。(25)自作モジュール７５２は、「対象サーバ」に対してBrowseアクションを発行して、対象サーバからコンテンツリストを取得し、得られたコンテンツリストを保持する。(26)自作プレイヤー７３１は、取得したコンテンツリストをビューシステム２４１に表示させて、ユーザにコンテンツ選択を促す。
【００９５】
図９Ｄは、ユーザが通信端末７００からコンテンツ覧の１つのコンテンツを選択した時点の、通信端末７００の表示画面２８０と対応するソフトウェア構成７２０の状態とを示す図である。この処理９４０では、(27)ユーザがコンテンツを選択した場合、自作プレイヤー７３１は、ビューシステム２４１から得た選択されたコンテンツの情報を自作モジュール７５２に設定するので、自作モジュール７５２は、現在どのコンテンツが「対象コンテンツ」かがわかる。
【００９６】
これ以降、選択されたコンテンツの再生を行なうが、サーバアドレスと再生すべきコンテンツ名称とが、自作モジュール７５２の記憶部７５４から取得される以外は、コンテンツの取得、復号、再生、出力の手順は、第２実施形態と同様であるので、詳細な説明は省略する。
【００９７】
《通信端末の処理手順》
図１０は、本実施形態に係る通信端末７００の処理手順を示すフローチャートである。このフローチャートは、図５のＣＰＵ５１０がＲＡＭ５４０を使用しながら実行して、図１および図７Ａの機能構成部を実現する。
【００９８】
通信端末７００は、ステップＳ１００１において、通信端末７００がアクセス可能なサーバを検索する。なお、ＤＬＮＡ(Digital Living Network Alliance)のシステムであれば、ＤＭＳ(digital media server)を検索することになる。通信端末７００は、ステップＳ１００３において、検索結果のサーバ一覧を表示する。
【００９９】
通信端末７００は、ステップＳ１００５において、ユーザによるサーバ選択を待つ。サーバ選択があれば、通信端末７００は、ステップＳ１００７において、コンテンツリストをＤＬＮＡの場合にはBrowseにより取得する。そして、通信端末７００は、図６ＡのステップＳ６０１において、コンテンツ一覧を表示する。以降の処理は、サーバアドレスと再生すべきコンテンツ名称とが、自作モジュール７５２の記憶部７５４から取得される以外、図６Ａと同様である。
【０１００】
（自作プレイヤーの処理手順）
図１１Ａは、本実施形態に係る自作プレイヤー７３１の処理手順を示すフローチャートである。
【０１０１】
自作プレイヤー７３１は、ステップＳ１１０１において、メニュー表示をビューシステム２４１に指示する。自作プレイヤー７３１は、ステップＳ１１０３において、ビューシステム２４１からの通知によりメニューからサーバ検索が選択されたか否かを判定する。サーバ検索でなければ、他のメニュー処理を行なう。
【０１０２】
サーバ検出であれば、自作プレイヤー７３１は、ステップＳ１１０５において、自作モジュール７５２にサーバ検索を指示する。そして、自作プレイヤー７３１は、ステップＳ１１０７において、サーバ検索結果を受信する。サーバ検索結果を受信すると、自作プレイヤー７３１は、ステップＳ１１０９において、表示部２１２へのサーバ一覧表示をビューシステム２４１に指示する。
【０１０３】
次に、自作プレイヤー７３１は、ステップＳ１１１１において、ビューシステム２４１からの通知によりサーバ一覧からユーザがサーバを選択したか否かを判定する。サーバが選択されると、自作プレイヤー７３１は、ステップＳ１１１２において、自作モジュール７５２に対して選択されたサーバを通知し、ステップＳ１１１３において、自作モジュール７５２に選択されたサーバのコンテンツ検索を指示する。ステップＳ１１１５においてコンテンツ検索結果を受信すると、自作プレイヤー７３１は、ステップＳ６２１において、表示部２１２へのコンテンツ一覧表示をビューシステム２４１に指示する。そして、自作プレイヤー７３１は、ステップＳ６２３において、ビューシステム２４１から再生したいコンテンツの選択情報を受信すると、ステップＳ１１１７において、自作モジュール７５２に対して選択されたコンテンツを通知する。
【０１０４】
以降の処理は、サーバアドレスと再生すべきコンテンツ名称とをローカル・ループバック・アドレスを付加しないことを除けば、図６Ｂと同様であるので、説明は省略する。
【０１０５】
（自作モジュールの処理手順）
図１１Ｂは、本実施形態に係るHTTP Client & Daemonを含む自作モジュール７５２の処理手順を示すフローチャートである。
【０１０６】
自作モジュール７５２は、ステップＳ１１２１において、自作プレイヤー７３１からのサーバ検索指示か否かを判定する。サーバ検索指示でなければ、他の処理を行なう。
【０１０７】
サーバ検索指示であれば、自作モジュール７５２は、ステップＳ１１２３において、サーバ検索処理を行なう。そして、自作モジュール７５２は、ステップＳ１１２５において、サーバ検索結果を記憶部７５４に記憶し、ステップＳ１１２７において、自作プレイヤー７３１に報告する。そして、自作モジュール７５２は、ステップ１１２８において、自作プレイヤー７３１から通知される選択されたサーバの情報を記憶部７５４に記憶する。次に、自作モジュール７５２は、ステップＳ１１２９において、自作プレイヤー７３１からの選択サーバのコンテンツ検索指示を待つ。
【０１０８】
自作プレイヤー７３１からのコンテンツ検索指示を受けると、自作モジュール７５２は、ステップＳ１１３１において、コンテンツ検索処理を行なう。そして、自作モジュール７５２は、ステップＳ１１３３において、コンテンツ検索結果を記憶部７５４に記憶し、ステップＳ１１３５において、自作プレイヤー７３１に報告する。自作モジュール７５２は、ステップＳ１１３７において、選択されたコンテンツを記憶部７５４に記憶する。
【０１０９】
自作モジュール７５２は、ステップＳ６６１において、所定のポート番号（本例では、20000）に発行されたゲット要求(HTTP GET Request）の受信を待つ。以降の処理は、サーバアドレスと再生すべきコンテンツ名称とを記憶部７５４から読み出すことを除けば、図６Ｄと同様であるので、説明は省略する。
【０１１０】
本実施形態によれば、ユーザが再生したいコンテンツを選択するまでの手順で、サーバアドレスや再生すべきコンテンツ名称が取得されるので、自作プレイヤーから自作モジュールへのゲット要求を簡素化できる。
【０１１１】
［第４実施形態］
次に、本発明の第４実施形態に係る通信端末について説明する。本実施形態に係る通信端末は、上記第２実施形態および第３実施形態と比べると、コンテンツの再生開始時間を設定可能である点で異なる。その他の構成および動作は、第２実施形態または第３実施形態と同様であるため、同じ構成および動作については同じ符号を付してその詳しい説明を省略する。
【０１１２】
《通信端末の動作手順》
図１２は、本実施形態に係る通信端末の動作手順を示すシーケンス図である。なお、図１２において、図３Ａと同様のステップには同じステップ番号を付して、説明を省略する。
【０１１３】
図１２において、図３Ａと異なるステップは、操作部２１１が、ステップＳ１２０６において、ユーザが入力した再生開始時間を設定するステップである。再生開始時間をビューシステム２４１から受信した自作プレイヤー１２３１は、ステップＳ１２０７において、ローカル・ループバック・アドレスに続くデータに引数として再生開始時間を付加して、メディアフレームワーク２５１に送信する。
【０１１４】
自作モジュール１２５２は、メディアフレームワーク２５１から発行されたゲット要求(HTTP GET Request）に対して、ステップＳ１２１１において、コンテンツの要求先とコンテンツ名称を置き換えるのに加えて、再生開始時間を付加する。コンテンツサーバ２７０においては、ステップＳ１２１５において、再生開始時間以降のコンテンツを自作モジュール１２５２に送信する。
【０１１５】
（自作プレイヤーの処理手順）
図１３Ａは、本実施形態に係る自作プレイヤー１２３１の処理手順を示すフローチャートである。なお、図１３Ａにおいて、図６Ｂと同様のステップには同じステップ番号を付して、説明を省略する。
【０１１６】
図１３Ａにおいて、図６Ｂとの相違点は、ステップＳ１３２５において、自作プレイヤー１２３１がローカル・ループバック・アドレスの後に、再生開始時間を付加することである。その他のステップは、図６Ｂと同様である。
【０１１７】
（自作モジュールの処理手順）
図１３Ｂは、本実施形態に係るHTTP Client & Daemonを含む自作モジュール１２５２の処理手順を示すフローチャートである。なお、図１３Ｂにおいて、図６Ｄと同様のステップには同じステップ番号を付して、説明を省略する。
【０１１８】
図１３Ｂにおいて、図６Ｄとの相違点は、ステップＳ１３６３において、自作モジュール１２５２がゲット要求(HTTP GET Request）のコンテンツ取得先とコンテンツ名称を置き換えることに加えて、再生開始時間を付加することである。その他のステップは、図６Ｄと同様である。
【０１１９】
本実施形態によれば、ユーザが再生を望むコンテンツの再生開始時間（再生位置）から再生するので、例えば、複数の通信端末からの同時再生やトリック操作に対応できる。
【０１２０】
［第５実施形態］
次に、本発明の第５実施形態に係る通信端末について説明する。本実施形態に係る通信端末は、上記第２実施形態乃至第４実施形態と比べると、通信端末が複数の自作モジュールを有して、それぞれがサーバからのコンテンツを取得して復号し、表示部の同一画面に表示する点で異なる。その他の構成および動作は、第２実施形態乃至第４実施形態のいずれかと同様であるため、同じ構成および動作については同じ符号を付してその詳しい説明を省略する。
【０１２１】
《通信端末の動作手順》
図１４は、本実施形態に係る通信端末の動作手順を示すシーケンス図である。なお、図１４において、図３Ａと同様のステップには同じステップ番号を付して、説明を省略する。
【０１２２】
図１４において、図３Ａと異なるステップは、ステップＳ１４０５〜Ｓ１４０９において、同時に他のコンテンツ（本例ではコンテンツＢ）の再生を他の自作モジュール１４５２に要求することである。また、ステップＳ１４１３〜Ｓ１４１７において、自作モジュール１４５２がコンテンツサーバ１４７０からコンテンツＢを取得して復号することである。そして、ステップＳ１４１９〜Ｓ１４２５において、コンテンツＢを表示部２１２にコンテンツＡと同時表示（例えば、picture in picture）することである。
【０１２３】
《通信端末の動作》
図１５は、図１４に示したシーケンスに従った通信端末１５００の動作をより詳細に示す図である。なお、自作モジュール２（１４５２）は、HTTP Client & DaemonとDTCP-IPとUPnPとを含むように示されているが、これに限定されない。本例では、自作モジュール２（１４５２）の本体である“HTTP Client & Daemon”と、復号部である“DTCP-IP”と、通信プロトコルを提供する“UPnP”とが一例として示されている。
【０１２４】
図１５は、自作モジュール２５２および１４５２が、サーバから送信された暗号化コンテンツを受信して、復号して、メディアフレームワーク１４５１に対してゲット要求(HTTP GET Request）へのゲット応答(HTTP GET Response)として送信する時点である。その時の、通信端末１５００の表示画面１５１０に再生した映像２９１および１５９１と対応するソフトウェア構成１５２０の状態を示す図である。メディアフレームワーク１４５１およびビューシステム１４４１において、リンクプロテクション（暗号）された複数コンテンツの表示画面１５１０への同時再生が行われる。
【０１２５】
本実施形態によれば、複数コンテンツを復号し、同一画面への同時再生ができる。
【０１２６】
［第６実施形態］
次に、本発明の第６実施形態に係る通信端末について説明する。本実施形態に係る通信端末は、上記第２実施形態と比べると、１つの自作モジュールが、メディアフレームワークが有しない異なる処理が可能である点で異なる。その他の構成および動作は、第２実施形態と同様であるため、同じ構成および動作については同じ符号を付してその詳しい説明を省略する。
【０１２７】
なお、本実施形態においては、復号プログラムとトランスコードとの複数の処理を説明するが、メディアフレームワークが有しない他の機能を自作モジュールに付加することも可能であり、本実施形態に含まれる。ここで、トランスコードとは、元のデジタル動画データをデコードによって圧縮を解除した後、改めて再エンコードすることによって、目的の別種の動画圧縮コードや縦横の解像度、ビットレートに変換するといった処理である。すなわち、通信端末によっては再生可能な動画フォーマットが限られているため、トランスコードすることで再生可能な動画フォーマットに変換することで再生を可能にする。なお、トランスコード部は、ソフトウェアで提供されても、ハードウェアチップで提供されてもよい。
【０１２８】
《通信端末の動作手順》
図１６Ａおよび図１６Ｂは、本実施形態に係る通信端末１７００の動作手順を示すシーケンス図である。なお、図１６Ａおよび図１６Ｂにおいて、図３Ａと同様のステップには同じステップ番号を付して、説明は省略する。
【０１２９】
図１６Ａの手順では、自作モジュール１６５２は、コンテンツＡの選択に対して、ステップＳ１６１３、Ｓ１６１５、Ｓ１６１７において、コンテンツサーバ２７０から取得した暗号コンテンツに対して復号を行ない、ゲット応答(HTTP GET Response)としてメディアフレームワーク２５１に返す。
【０１３０】
図１６Ｂの手順では、自作モジュール１６５２は、コンテンツＢの選択に対して、ステップＳ１６１４、Ｓ１６１６、Ｓ１６１８において、コンテンツサーバ２７０から取得した、当該通信端末に対して非適応コードのコンテンツに対してトランスコード処理を行ない、ゲット応答(HTTP GET Response)としてメディアフレームワーク２５１に返す。
【０１３１】
《通信端末の動作》
図１７および図１８は、図１６Ａおよび図１６Ｂに示したシーケンスに従った通信端末１７００の動作を順により詳細に示す図である。なお、自作モジュール１６５２は、HTTP Client & DaemonとDTCP-IPとトランスコード部とUPnPとを含むように示されているが、これに限定されない。本例では、自作モジュール１６５２の本体である“HTTP Client & Daemon”と、復号部である“DTCP-IP”と、トランスコード処理をするトランスコード部と、通信プロトコルを提供する“UPnP”とが一例として示されている。
【０１３２】
図１７は、通信端末１７００において、表示画面１７９０のコンテンツ一覧からメディアフレームワーク２５１が有しない暗号化コンテンツ１７９１が選択されたので、自作モジュール１６５２においては、(17) サーバから暗号化データを受信したら、ＤＴＣＰ−ＩＰによって平文に復号した後に、メディアフレームワークに対してHTTP Get Responseでデータを転送する。
【０１３３】
一方、図１８は、通信端末１７００において、表示画面１７９０のコンテンツ一覧からメディアフレームワーク２５１では再生できないメディアフォーマットのコンテンツ１７９２が選択されたので、自作モジュール１６５２においては、(33) サーバからデータを受信したら、トランスコード部において再生可能なコード形式に変換後に、メディアフレームワークに対してHTTP Get Responseでデータを転送する。
【０１３４】
《通信端末の処理手順》
図１９は、本実施形態に係る通信端末１７００の処理手順を示すフローチャートである。なお、図１９において、図６Ａと同様のステップには同じステップ番号を付して、説明を省略する。
【０１３５】
通信端末１７００は、ステップＳ１９０９において、コンテンツサーバからコンテンツを取得して、そのコンテンツが暗号化コンテンツか／非適応のコードかを判定して、判定結果に対応する処理を実行して、メディアフレームワーク２５１にゲット応答(HTTP GET Response)でコンテンツデータを返す。
【０１３６】
（自作モジュールの処理手順）
図２０は、本実施形態に係るHTTP Client & Daemonを含む自作モジュール１６５２の処理手順を示すフローチャートである。なお、図２０において、図６Ｄと同様のステップには同じステップ番号を付して、説明を省略する。
【０１３７】
自作モジュール１６５２は、取得したコンテンツが著作権保護コンテンツであれば、ステップＳ６７５においてコンテンツデータを復号した後、ステップＳ２０７７において、復号コンテンツを保持する。一方、取得したコンテンツが著作権保護コンテンツでなければ、自作モジュール１６５２はステップＳ２０７９に進む。そして、自作モジュール１６５２は、ステップＳ２０７９において、通信端末１６００に適応しないコードのコンテンツか否かを判定する。非適応コードであれば、自作モジュール１６５２は、ステップＳ２０８１において、トランスコード部において通信端末１６００に適応するコードへトランスコード処理を行なう。自作モジュール１６５２は、ステップＳ６７７において、取得したコンテンツに対応して、復号処理および／またはトランスコード処理したコンテンツを、メディアフレームワーク２５１にゲット応答(HTTP GET Response)で返す。
【０１３８】
本実施形態によれば、ＯＳのビューシステムやメディアフレームワークに手を入れることなく、復号ができるのみでなく、サーバ側のコンテンツが、自身が再生不可能な動画フォーマットであっても、トランスコードすることで再生可能な動画フォーマットに変換することで再生を可能にする。
【０１３９】
［第７実施形態］
次に、本発明の第７実施形態に係る通信端末について説明する。本実施形態に係る通信端末は、上記第２実施形態と比べると、自作モジュールを複数増設可能で、かつ、選択使用できる点で異なる。その他の構成および動作は、第２実施形態と同様であるため、同じ構成および動作については同じ符号を付してその詳しい説明を省略する。
【０１４０】
《通信端末の動作》
図２１Ａおよび図２１Ｂは、本実施形態の通信端末２１００の動作を順に示す図である。なお、自作モジュール１（２１５２）は、HTTP Client & DaemonとDTCP-IPとUPnPとを含むように示され、自作モジュール２（２１５３）は、HTTP Client & Daemonとトランスコード部とUPnPとを含むように示されているが、これに限定されない。なお、図２１Ａおよび図２１Ｂにおいて、図４Ａ〜図４Ｆと同様の処理には同じ参照番号を付し、説明は省略する。
【０１４１】
図２１Ａは、通信端末２１００において、選択されたコンテンツのトランスコード処理するための自作モジュールを、複数の自作モジュールから選択して起動して、サーバにゲット要求(HTTP GET Request）を発行した時点である。その時の、通信端末２１００の表示画面２１１０と対応するソフトウェア構成２１２０の状態とを示す図である。ここでは、サンプルコンテンツ２１１１は、自作モジュール２（２１５３）が有するトランスコード部によるトランスコード処理が可能であると仮定する。
【０１４２】
処理２１４０では、(43)自前の自作モジュール２（２１５３）のHTTP DaemonのＵＲＬを指定して、ビューシステム２４１に渡す（http://127.0.0.1:20001/target2.mp4）。処理２１６０では、(44)メディアフレームワーク２５１に（Http://127.0.0.1:20001/target2.mp4）を伝える。
【０１４３】
処理２１７０では、(45)メディアフレームワーク２５１は、127.0.0.1に対して、コンテンツ取得要求（HTTP Get Request)を行う。この場合に、ローカル・ループバック・アドレスに続く、ポート番号(20001)のコンテンツ名称(target2.mp4)を対象としているので、自作モジュール２（２１５３）がコンテンツ取得要求を受ける。そして、処理２１８０では、(46)自作モジュール２（２１５３）のHTTP Client & Daemonは、メディアフレームワーク２５１からの要求メッセージを「宛先」だけ差し替え、サーバ（http://192.168.10.100/movie.mp4)に対してゲット要求(HTTP GET Request)を発行する。
【０１４４】
図２１Ｂは、通信端末２１００において、サーバから取得したコンテンツをトランスコード部でコード変換して、メディアフレームワーク２５１に返し、再生映像を通信端末２１００に出力した時点である。その時の、通信端末２１００の表示画面２９０の映像２９１と対応するソフトウェア構成２１２０の状態とを示す図である。
【０１４５】
処理２１９０では、(47)サーバから通信端末２１００では対応できないコードのコンテンツデータを受信したら、自作モジュール２（２１５３）のトランスコード部で通信端末２１００に適応するコードへのトランスコード処理を実行した後に、メディアフレームワーク２５１に対してゲット応答(HTTP Get Response)でデータを転送する。
【０１４６】
本実施形態によれば、複数種類の自作モジュールによる処理を切り替えて、復号に限定されないメディアフレームワークが有しない機能を、ＯＳのビューシステムやメディアフレームワークに手を入れることなく増設できる。なお、本実施形態においても、コンテンツによって復号処理とトランスコード処理の両方を実行してもよい。その場合には、復号コンテンツが続くトランスコード処理のために、自作モジュール２１５２で一時保持されて、自作モジュール２１５３に渡される。
【０１４７】
［第８実施形態］
次に、本発明の第８実施形態に係る通信端末につい説明する。本実施形態に係る通信端末は、上記第２実施形態と比べると、サーバが通信端末に含まれる点で異なる。その他の構成および動作は、第２実施形態と同様であるため、同じ構成および動作については同じ符号を付してその詳しい説明を省略する。
【０１４８】
《システム構成》
図２２は、本実施形態に係る通信端末を含むシステムの構成を示す図である。なお、図２２においては、サーバの位置などが分かり易い例として、ＤＬＮＡ（Digital Living Network Alliance）におけるＤＭＣ(Digital Media Controller）、ＤＭＳ(Digital Media Server）、ＤＭＲ(Digital Media Renderer）によって図示するが、これに限定されない。
【０１４９】
図２２の第１システム２２１０は、第１クライアント端末２２３０も、第２クライアント端末２２４０もＤＭＲ（レンダラー）２２３３、２２４３のみを有する。そして、ＤＭＳ（サーバ）２２２２はサーバ機器２２２０にある。すなわち、サーバがクライアント端末の外部にある構成である。
【０１５０】
一方、第２システム２２５０は、サーバ機器はなく、第３クライアント端末２２６０と第４クライアント端末２２７０とのシステムである。ここでは、第３クライアント端末２２６０がＤＭＣ（コントローラ）２２６１を有し、第４クライアント端末２２７０がＤＭＳ２２７２を有している。
【０１５１】
本実施形態によれば、通信端末をクライアント端末やサーバ端末に固定することなく、柔軟なシステム構成ができる。
【０１５２】
［他の実施形態］
以上、実施形態を参照して本発明を説明したが、本発明は上記実施形態に限定されるものではない。本発明の構成や詳細には、本発明のスコープ内で当業者が理解し得る様々な変更をすることができる。また、それぞれの実施形態に含まれる別々の特徴を如何様に組み合わせたシステムまたは装置も、本発明の範疇に含まれる。
【０１５３】
また、本発明は、複数の機器から構成されるシステムに適用されてもよいし、単体の装置に適用されてもよい。さらに、本発明は、実施形態の機能を実現する情報処理プログラムが、システムあるいは装置に直接あるいは遠隔から供給される場合にも適用可能である。したがって、本発明の機能をコンピュータで実現するために、コンピュータにインストールされるプログラム、あるいはそのプログラムを格納した媒体、そのプログラムをダウンロードさせるＷＷＷ(World Wide Web)サーバも、本発明の範疇に含まれる。特に、少なくとも、非一時的コンピュータ可読媒体（non-transitory computer readable medium）は本発明の範疇に含まれる。
【図１】
2014207506.tif 000003
【図２Ａ】
2014207506.tif 000004
【図２Ｂ】
2014207506.tif 000005
【図３Ａ】
2014207506.tif 000006
【図３Ｂ】
2014207506.tif 000007
【図４Ａ】
2014207506.tif 000008
【図４Ｂ】
2014207506.tif 000009
【図４Ｃ】
2014207506.tif 000010
【図４Ｄ】
2014207506.tif 000011
【図４Ｅ】
2014207506.tif 000012
【図４Ｆ】
2014207506.tif 000013
【図５】
2014207506.tif 000014
【図６Ａ】
2014207506.tif 000015
【図６Ｂ】
2014207506.tif 000016
【図６Ｃ】
2014207506.tif 000017
【図６Ｄ】
2014207506.tif 000018
【図７Ａ】
2014207506.tif 000019
【図７Ｂ】
2014207506.tif 000020
【図８Ａ】
2014207506.tif 000021
【図８Ｂ】
2014207506.tif 000022
【図９Ａ】
2014207506.tif 000023
【図９Ｂ】
2014207506.tif 000024
【図９Ｃ】
2014207506.tif 000025
【図９Ｄ】
2014207506.tif 000026
【図１０】
2014207506.tif 000027
【図１１Ａ】
2014207506.tif 000028
【図１１Ｂ】
2014207506.tif 000029
【図１２】
2014207506.tif 000030
【図１３Ａ】
2014207506.tif 000031
【図１３Ｂ】
2014207506.tif 000032
【図１４】
2014207506.tif 000033
【図１５】
2014207506.tif 000034
【図１６Ａ】
2014207506.tif 000035
【図１６Ｂ】
2014207506.tif 000036
【図１７】
2014207506.tif 000037
【図１８】
2014207506.tif 000038
【図１９】
2014207506.tif 000039
【図２０】
2014207506.tif 000040
【図２１Ａ】
2014207506.tif 000041
【図２１Ｂ】
2014207506.tif 000042
【図２２】
2014207506.tif 000043
【図２３】
2014207506.tif 000044
【手続補正書】
【提出日】平成25年9月4日(2013.9.4)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
コンテンツを再生するメディアフレームワークを有する通信端末であって、
サーバが有するコンテンツの再生指示を受けた場合、当該通信端末を示す特定アドレスにルート情報を付加して宛先を生成し、前記メディアフレームワークに対して前記宛先を含むコンテンツ要求を渡す第１コンテンツ要求手段と、
前記特定アドレスと前記ルート情報とで示される前記宛先を監視することで、前記メディアフレームワークから前記宛先を含むゲット要求を受信した場合に、前記サーバに対して前記コンテンツを要求し、前記サーバから取得した前記コンテンツに対して前記メディアフレームワークが有しないコンテンツ処理を実行して、前記ゲット要求に対するゲット応答として、前記コンテンツ処理を実行した処理済コンテンツを前記メディアフレームワークに送信するコンテンツ取得手段と、
を備える通信端末。
【請求項２】
前記コンテンツ取得手段は、
前記特定アドレスと前記ルート情報とで示される宛先に対して前記メディアフレームワークから発行されるゲット要求を監視する監視手段と、
前記メディアフレームワークから前記宛先を含む前記ゲット要求を受信した場合に、サーバに対して前記コンテンツを要求する第２コンテンツ要求手段と、
前記第２コンテンツ要求手段による要求の応答として前記サーバから取得した前記コンテンツに対して、前記コンテンツ処理を実行する実行手段と、
前記実行手段が前記コンテンツ処理を実行した処理済コンテンツを、前記ゲット要求に対するゲット応答として前記メディアフレームワークに送信する送信手段と、
を含む請求項１に記載の通信端末。
【請求項３】
前記実行手段が実行する前記コンテンツ処理は、暗号化コンテンツの復号処理であって、
前記第２コンテンツ要求手段による前記サーバに対する前記暗号化コンテンツの要求に先立って、前記暗号化コンテンツを復号するための鍵を交換する鍵交換手段をさらに備える請求項２に記載の通信端末。
【請求項４】
前記実行手段が実行する前記コンテンツ処理は、前記サーバから取得した前記コンテンツのフォーマットを変換するトランスコード処理である請求項２または３に記載の通信端末。
【請求項５】
前記特定アドレスは、ローカル・ループバック・アドレスであり、前記ルート情報は、ポート番号である請求項１乃至４のいずれか１項に記載の通信端末。
【請求項６】
前記第１コンテンツ要求手段は、前記宛先に、さらに続いて前記コンテンツを取得するサーバのサーバアドレスと取得すべきコンテンツのコンテンツ名称とを付加して、前記メディアフレームワークに対して前記コンテンツ要求を渡し、
前記コンテンツ取得手段は、前記メディアフレームワークからの前記宛先を含む前記ゲット要求を、前記サーバアドレスへの前記コンテンツ名称のゲット要求に変更して、前記サーバに向けて送信することにより、前記サーバに対して前記コンテンツを要求し、前記サーバから取得した前記コンテンツに対して前記メディアフレームワークが有しないコンテンツ処理を実行して、前記ゲット要求に対するゲット応答として、前記コンテンツ処理を実行した処理済コンテンツを前記メディアフレームワークに送信する請求項１乃至５のいずれか１項に記載の通信端末。
【請求項７】
前記第１コンテンツ要求手段は、前記メディアフレームワークに対して前記コンテンツ要求を渡す前に、
前記コンテンツ取得手段に対してコンテンツを取得可能なサーバの検索を要求して、検索されたサーバを一覧表示させ、
前記コンテンツ取得手段に対してサーバ一覧表示から選択されたサーバを通知すると共に、前記選択されたサーバが保持するコンテンツの検索を要求して、検索されたコンテンツを一覧表示させ、
前記コンテンツ取得手段に対して、コンテンツ一覧表示から選択されたコンテンツ名称を通知し、
前記コンテンツ取得手段は、
前記第１コンテンツ要求手段により通知された、前記選択された前記サーバのサーバアドレスと前記選択されたコンテンツ名称とを記憶する記憶手段を有し、
前記メディアフレームワークから受信した前記宛先を含む前記ゲット要求を、前記記憶手段に記憶された前記サーバアドレスへの前記コンテンツ名称のゲット要求に変更して、前記サーバに向けて送信することにより、前記サーバに対して前記コンテンツを要求し、前記サーバから取得した前記コンテンツに対して前記メディアフレームワークが有しないコンテンツ処理を実行して、前記ゲット要求に対するゲット応答として、前記コンテンツ処理を実行した処理済コンテンツを前記メディアフレームワークに送信する請求項１乃至５のいずれか１項に記載の通信端末。
【請求項８】
前記第１コンテンツ要求手段は、さらに再生開始時間を付加して、前記メディアフレームワークに送信し、
前記コンテンツ取得手段は、前記取得すべきコンテンツの前記再生開始時間から以降を前記サーバから取得して前記メディアフレームワークに送信する請求項１乃至７のいずれか１項に記載の通信端末。
【請求項９】
サーバから取得したコンテンツを処理する複数のコンテンツ取得手段を有し、
前記第１コンテンツ要求手段は、前記特定アドレスに続いて、異なるルート情報を付加して前記宛先を生成し、
前記複数のコンテンツ取得手段の内、前記ルート情報に対応するコンテンツ取得手段が前記メディアフレームワークからゲット要求を受信する請求項１乃至８のいずれか１項に記載の通信端末。
【請求項１０】
自通信端末を示す特定アドレスとルート情報とで示される宛先に対して、前記自通信端末のメディアフレームワークから前記メディアフレームワークが有しないコンテンツ処理時に発行されるゲット要求を監視するステップと、
前記メディアフレームワークから前記宛先を含む前記ゲット要求を受信した場合に、前記自通信端末の外部にあるサーバに対してコンテンツを要求するステップと、
前記コンテンツの要求の応答として前記サーバから取得した前記コンテンツに対して、前記メディアフレームワークが有しないコンテンツ処理を実行するステップと、
前記コンテンツ処理を実行した処理済コンテンツを、前記ゲット要求に対するゲット応答として前記メディアフレームワークに送信するステップと、
を前記自通信端末のコンピュータに実行させるモジュールプログラム。
【請求項１１】
自通信端末の外部にあるサーバが有するコンテンツの再生指示を受けるステップと、
前記コンテンツの再生指示に応答して、前記自通信端末を示す特定アドレスに前記自通信端末のモジュールへのルート情報を付加して宛先を生成し、前記メディアフレームワークに対して前記宛先を含むコンテンツ要求を渡すステップと、
を前記自通信端末のコンピュータに実行させるプレイヤープログラムであって、
前記自通信端末のモジュールが、前記サーバから前記コンテンツを取得して前記自通信端末のメディアフレームワークが有しないコンテンツ処理を実行するモジュールである、プレイヤープログラム。
【請求項１２】
コンテンツを再生するメディアフレームワークを有する通信端末のコンテンツ再生方法であって、
サーバが有するコンテンツの再生指示を受けるステップと、
前記コンテンツの再生指示に応答して、当該通信端末を示す特定アドレスにルート情報を付加して宛先を生成し、前記メディアフレームワークに対して前記宛先を含むコンテンツ要求を渡すステップと、
前記特定アドレスと前記ルート情報とで示される前記宛先に対して前記メディアフレームワークから発行されるゲット要求を受けると、前記サーバに対して前記コンテンツを要求するステップと、
前記コンテンツの要求の応答として前記サーバから取得した前記コンテンツに対して、前記メディアフレームワークが有しないコンテンツ処理を実行するステップと、
前記コンテンツ処理を実行した処理済コンテンツを、前記ゲット要求に対するゲット応答として前記メディアフレームワークに送信するステップと、
を含むコンテンツ再生方法。
【請求項１３】
コンテンツを再生するメディアフレームワークを有する通信端末のコンテンツ再生プログラムであって、
サーバが有するコンテンツの再生指示を受けるステップと、
前記コンテンツの再生指示に応答して、当該通信端末を示す特定アドレスにルート情報を付加して宛先を生成し、前記メディアフレームワークに対して前記宛先を含むコンテンツ要求を渡すステップと、
前記特定アドレスと前記ルート情報とで示される前記宛先に対して前記メディアフレームワークから発行されるゲット要求を受けると、前記サーバに対して前記コンテンツを要求するステップと、
前記コンテンツの要求の応答として前記サーバから取得した前記コンテンツに対して、前記メディアフレームワークが有しないコンテンツ処理を実行するステップと、
前記コンテンツ処理を実行した処理済コンテンツを、前記ゲット要求に対するゲット応答として前記メディアフレームワークに送信するステップと、
をコンピュータに実行させるコンテンツ再生プログラム。
【手続補正２】
【補正対象書類名】明細書
【補正対象項目名】０００６
【補正方法】変更
【補正の内容】
【０００６】
上記目的を達成するため、本発明に係る装置は、
コンテンツを再生するメディアフレームワークを有する通信端末であって、
サーバが有するコンテンツの再生指示を受けた場合、当該通信端末を示す特定アドレスにルート情報を付加して宛先を生成し、前記メディアフレームワークに対して前記宛先を含むコンテンツ要求を渡す第１コンテンツ要求手段と、
前記特定アドレスと前記ルート情報とで示される前記宛先を監視することで、前記メディアフレームワークから前記宛先を含むゲット要求を受信した場合に、前記サーバに対して前記コンテンツを要求し、前記サーバから取得した前記コンテンツに対して前記メディアフレームワークが有しないコンテンツ処理を実行して、前記ゲット要求に対するゲット応答として、前記コンテンツ処理を実行した処理済コンテンツを前記メディアフレームワークに送信するコンテンツ取得手段と、
を備える。
【手続補正３】
【補正対象書類名】明細書
【補正対象項目名】０００７
【補正方法】変更
【補正の内容】
【０００７】
上記目的を達成するため、本発明に係るモジュールプログラムは、
自通信端末を示す特定アドレスとルート情報とで示される宛先に対して、前記自通信端末のメディアフレームワークから前記メディアフレームワークが有しないコンテンツ処理時に発行されるゲット要求を監視するステップと、
前記メディアフレームワークから前記宛先を含む前記ゲット要求を受信した場合に、前記自通信端末の外部にあるサーバに対してコンテンツを要求するステップと、
前記コンテンツの要求の応答として前記サーバから取得した前記コンテンツに対して、前記メディアフレームワークが有しないコンテンツ処理を実行するステップと、
前記コンテンツ処理を実行した処理済コンテンツを、前記ゲット要求に対するゲット応答として前記メディアフレームワークに送信するステップと、
を前記自通信端末のコンピュータに実行させる。
【手続補正４】
【補正対象書類名】明細書
【補正対象項目名】０００８
【補正方法】変更
【補正の内容】
【０００８】
上記目的を達成するため、本発明に係るプレイヤープログラムは、
自通信端末の外部にあるサーバが有するコンテンツの再生指示を受けるステップと、
前記コンテンツの再生指示に応答して、前記自通信端末を示す特定アドレスに前記自通信端末のモジュールへのルート情報を付加して宛先を生成し、前記メディアフレームワークに対して前記宛先を含むコンテンツ要求を渡すステップと、
を前記自通信端末のコンピュータに実行させるプレイヤープログラムであって、
前記自通信端末のモジュールが、前記サーバから前記コンテンツを取得して前記自通信端末のメディアフレームワークが有しないコンテンツ処理を実行するモジュールである。
【手続補正５】
【補正対象書類名】明細書
【補正対象項目名】０００９
【補正方法】変更
【補正の内容】
【０００９】
上記目的を達成するため、本発明に係る方法は、
コンテンツを再生するメディアフレームワークを有する通信端末のコンテンツ再生方法であって、
サーバが有するコンテンツの再生指示を受けるステップと、
前記コンテンツの再生指示に応答して、当該通信端末を示す特定アドレスにルート情報を付加して宛先を生成し、前記メディアフレームワークに対して前記宛先を含むコンテンツ要求を渡すステップと、
前記特定アドレスと前記ルート情報とで示される前記宛先に対して前記メディアフレームワークから発行されるゲット要求を受けると、前記サーバに対して前記コンテンツを要求するステップと、
前記コンテンツの要求の応答として前記サーバから取得した前記コンテンツに対して、前記メディアフレームワークが有しないコンテンツ処理を実行するステップと、
前記コンテンツ処理を実行した処理済コンテンツを、前記ゲット要求に対するゲット応答として前記メディアフレームワークに送信するステップと、
を含む。
【手続補正６】
【補正対象書類名】明細書
【補正対象項目名】００１０
【補正方法】変更
【補正の内容】
【００１０】
上記目的を達成するため、本発明に係るコンテンツ再生プログラムは、
コンテンツを再生するメディアフレームワークを有する通信端末のコンテンツ再生プログラムであって、
サーバが有するコンテンツの再生指示を受けるステップと、
前記コンテンツの再生指示に応答して、当該通信端末を示す特定アドレスにルート情報を付加して宛先を生成し、前記メディアフレームワークに対して前記宛先を含むコンテンツ要求を渡すステップと、
前記特定アドレスと前記ルート情報とで示される前記宛先に対して前記メディアフレームワークから発行されるゲット要求を受けると、前記サーバに対して前記コンテンツを要求するステップと、
前記コンテンツの要求の応答として前記サーバから取得した前記コンテンツに対して、前記メディアフレームワークが有しないコンテンツ処理を実行するステップと、
前記コンテンツ処理を実行した処理済コンテンツを、前記ゲット要求に対するゲット応答として前記メディアフレームワークに送信するステップと、
をコンピュータに実行させる。