(57)【要約】【課題】ネットワーク環境でコンテンツのアップロードが異常終了した場合でも既存の機器との接続性を損なうことなくコンテンツの受信済部分を継続的に保持する。【解決手段】コンテンツ受信装置はネットワーク上のアップロード装置２からのアップロード要求を検出し、アップロード対象のコンテンツを格納すべきエントリポイントを生成し、エントリポイントを示すエントリポイント情報をアップロード先としてアップロード装置に通知するコンテンツ生成部３２と、アップロード装置２からアップロード先に対してアップロードされるコンテンツを受信し、このコンテンツをアップロード先に対応するエントリポイントに格納するコンテンツ受信部３３とを備える。コンテンツ受信装置は、さらにアップロードの中断に伴ってコンテンツの受信済部分の継続保持および廃棄のいずれか一方を決定する中断時判定部３４と、受信済部分を継続保持する場合にエントリポイント情報を書き換えるコンテンツ継続保持処理部３５とを備える。【選択図】図２
2010056924.tif 000002
【特許請求の範囲】
【請求項１】
ネットワーク上のアップロード装置からのアップロード要求を検出し、アップロード対象のコンテンツを格納すべきエントリポイントを生成し、前記エントリポイントを示すエントリポイント情報をアップロード先として前記アップロード装置に通知するコンテンツ生成部と、
前記アップロード装置から前記アップロード先に対してアップロードされるコンテンツを受信し、このコンテンツを前記アップロード先に対応するエントリポイントに格納するコンテンツ受信部と、
アップロードの中断に伴って前記コンテンツの受信済部分の継続保持および廃棄のいずれか一方を決定し、前記受信済部分を継続保持する場合に前記エントリポイント情報を書き換えるコンテンツ管理部とを備えることを特徴とするコンテンツ受信装置。
【請求項２】
前記コンテンツ管理部は前記受信済部分の継続保持を決定するために所定の条件が満足されることを検出することを特徴とする請求項１に記載のコンテンツ受信装置。
【請求項３】
前記所定の条件は、前記コンテンツがライブコンテンツである場合であることを特徴とする請求項２に記載のコンテンツ受信装置。
【請求項４】
前記所定の条件は、アップロードが受信側の都合で中断された場合であることを特徴とする請求項２に記載のコンテンツ受信装置。
【請求項５】
前記コンテンツ管理部は前記エントリポイント情報としての識別子を他の識別子に変更し、前記アップロード装置や他の装置に公開することを特徴とする請求項１に記載のコンテンツ受信装置。
【請求項６】
前記コンテンツ受信部は前記受信済部分を廃棄場合に前記エントリポイントおよび前記受信済部分を削除することを特徴とする請求項１に記載のコンテンツ受信装置。
【請求項７】
ネットワーク上のアップロード装置からのアップロード要求を検出し、
前記アップロード対象のコンテンツを格納すべきエントリポイントを生成し、
前記エントリポイントを示すエントリポイント情報をアップロード先として前記アップロード装置に通知し、
前記アップロード装置から前記アップロード先に対してアップロードされるコンテンツを受信し、
このコンテンツを前記アップロード先に対応するエントリポイントに格納し、
アップロードの中断に伴って前記コンテンツの受信済部分の継続保持および廃棄のいずれか一方を決定し、
前記受信済部分を継続保持する場合に前記エントリポイント情報を書き換えることを備えることを特徴とするコンテンツ受信方法。
【請求項８】
前記受信済部分の継続保持を決定するために所定の条件が満足されることを検出することを特徴とする請求項７に記載のコンテンツ受信方法。
【請求項９】
前記所定の条件は、前記コンテンツがライブコンテンツである場合であることを特徴とする請求項８に記載のコンテンツ受信方法。
【請求項１０】
前記所定の条件は、アップロードが受信側の都合で中断された場合であることを特徴とする請求項８に記載のコンテンツ受信方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワーク環境においてアップロードされるコンテンツを受信するコンテンツ受信装置およびコンテンツ受信方法に関する。
【背景技術】
【０００２】
ブロードバンドや無線ＬＡＮ等のコンピュータネットワークの普及や、デジタル技術の発展に伴い、通信機能を備えたデジタル情報機器と呼ばれるデジタル家電製品が普及しつつある。また、地上デジタル放送の開始に伴い、デジタル放送対応のテレビやセットトップボックス、ＤＶＤレコーダ等が、今後より一層普及することが予想される。複数のデジタル家電がネットワークに接続されれば、利用者はネットワーク経由でコンテンツを楽しむことができ、有益である。
【０００３】
国内では、デジタル家電機器を相互接続するための業界団体として例えばＤＬＮＡ（Digital Living Network Alliance）が結成されている。このＤＬＮＡは各社の製品が共通に対応すべきメディアフォーマット（＝ＣＯＤＥＣ）、ＵＰｎＰ(Universal Plug and Play)をベースとする機器間の通信手順、ユーザインタフェース等をガイドラインとして定めている(例えば、非特許文献１を参照)。
【０００４】
例えばＤＮＬＡのガイドラインバージョン１．５（以下、DLNA1.5）は、送信装置（コンテンツアップロード装置）が受信装置（アップロードコンテンツ受信装置）にネットワーク経由でコンテンツをアップロードし、受信装置がアップロードコンテンツを録画する場合の通信手順を規定している。この通信手順は手順１および手順２の２段階である。手順１では、送信装置が受信装置に対して、コンテンツの内容を説明するメタデータを示し(CDS: CreateObjectコマンド)、受信装置がアップロード用のエントリポイントを生成する。手順２では、 送信装置が受信装置のエントリポイントに対してコンテンツをアップロードする(HTTP POSTによる伝送)。ちなみに、アップロードされたコンテンツはこの受信装置から他の装置にDLNA1.5に基づいて公開される。
【０００５】
また、DLNA1.5では、アップロードが正常に終了しない場合、受信装置はアップロード用のエントリポイントとコンテンツの受信済部分を自動的に削除しなければならない。これは、ネットワーク接続の切断を含めた異常終了時に、送信装置から受信装置に何らかの働きかけを行えるとは限らないことと、いつでも再アップロード可能な蓄積コンテンツを主としてアップロードの対象としているからである。
【非特許文献１】IEC 62481-1またはDLNA Networked Device Interoperability Guidelines expanded: October 2006, Section 7.3.110 “MM/CM: DMS with Upload Device Option Support Definition” 7.3.137 “MM/CM: Auto-Destroy Behavior for a Failed or Partial Content Transfer Process”
【発明の開示】
【発明が解決しようとする課題】
【０００６】
しかしながら、送信装置がストリーミング方式で放送番組などのライブコンテンツを受信装置にアップロードすることもある。例えばメモリ残量不足がこのライブコンテンツのアップロード中に受信装置側の都合で発生すると、アップロードが中断されて異常終了処理を行うことになる。ライブコンテンツの場合、前記アップロード手順に基づいて、コンテンツ全体のアップロードに失敗すると、中断が生じるまでのコンテンツの受信済部分を削除しなければならない。この際、コンテンツはアップロード装置および受信装置のいずれにも保持されない問題が生じる。蓄積コンテンツの場合は、アップロードの中断によって受信装置側で受信済部分の削除が行われても、アップロード装置はコンテンツ全体を引き続き保持しており、再度のアップロードを試みればよい。
【０００７】
本発明の目的は、ネットワーク環境でコンテンツのアップロードが異常終了した場合でも既存の機器との接続性を損なうことなくコンテンツの受信済部分を継続的に保持できるコンテンツ受信装置およびコンテンツ受信方法を提供することにある。
【課題を解決するための手段】
【０００８】
本発明の一観点によれば、ネットワーク上のアップロード装置からのアップロード要求を検出し、アップロード対象のコンテンツを格納すべきエントリポイントを生成し、エントリポイントを示すエントリポイント情報をアップロード先としてアップロード装置に通知するコンテンツ生成部と、アップロード装置からアップロード先に対してアップロードされるコンテンツを受信し、このコンテンツをアップロード先に対応するエントリポイントに格納するコンテンツ受信部と、アップロードの中断に伴ってコンテンツの受信済部分の継続保持および廃棄のいずれか一方を決定し、受信済部分を継続保持する場合にエントリポイント情報を書き換えるコンテンツ管理部とを備えるコンテンツ受信装置が提供される。
【０００９】
本発明の一観点によれば、ネットワーク上のアップロード装置からのアップロード要求を検出し、アップロード対象のコンテンツを格納すべきエントリポイントを生成し、エントリポイントを示すエントリポイント情報をアップロード先としてアップロード装置に通知し、アップロード装置からアップロード先に対してアップロードされるコンテンツを受信し、このコンテンツをアップロード先に対応するエントリポイントに格納し、アップロードの中断に伴ってコンテンツの受信済部分の継続保持および廃棄のいずれか一方を決定し、受信済部分を継続保持する場合にエントリポイント情報を書き換えるコンテンツ受信方法が提供される。
【発明の効果】
【００１０】
これらコンテンツ受信装置およびコンテンツ受信方法では、受信済部分を継続保持する場合にエントリポイントを示すエントリポイント情報が書き換えられる。この書き換えにより、受信済部分が書き換え後のエントリポイント情報に基づいて公開可能となる。他方、アップロード装置に対してアップロード先として通知されたエントリポイント情報は存在しなくなり、アップロード結果の受信済部分がエントリポイントと一緒に削除されたように見せかけることができる。従って、ネットワーク環境でアップロード装置のような既存の機器との接続性を損なうことなくコンテンツの受信済部分を継続的に保持できる。
【発明を実施するための最良の形態】
【００１１】
以下、本発明の第１実施形態に係るホームネットワークシステムについて添付図面を参照して説明する。
【００１２】
図１はこのホームネットワークシステムの構成例を示す。このネットワークシステムはネットワーク１、およびこのネットワーク１上で相互接続されるコンテンツアップロード装置（以下、アップロード装置）２およびアップロードコンテンツ受信装置（以下、コンテンツ受信装置）３を含む。アップロード装置２は例えばアンテナで受信したデジタル放送コンテンツを復調するチューナに設けられ、ネットワーク１上でUPnP AVのContentDiretoryクライアントおよびHTTPクライアントとして動作する。コンテンツ受信装置３は例えばアップロード装置２で復調されたデジタル放送コンテンツを録画するビデオレコーダに設けられ、ネットワーク１上でUPnP AVのContentDirectoryサービスおよびHTTPサーバとして動作する。アップロード装置２はUPnPの機器発見手順に基づいてコンテンツ受信装置３を発見することができ、さらにDLNA1.5のコンテンツアップロード手順に従ってコンテンツ受信装置３に対してコンテンツのアップロードを行う。
【００１３】
図２はアップロード装置２およびコンテンツ受信装置３の構成例を示し、図３はアップロード装置２およびコンテンツ受信装置３間の通信内容を示す。アップロード装置２はコンテンツ記憶部２１、コンテンツ生成要求部２２、およびコンテンツ送信部２３を含む。コンテンツ記憶部２１はアップロード要求の対象となるライブコンテンツ等のコンテンツを記憶する。コンテンツ生成要求部２２はコンテンツ記憶部２１に記憶されたコンテンツからその内容を説明するメタデータを取得し、このメタデータをCreateObjectコマンドと組み合わせたアップロード要求の送信によりコンテンツ受信装置３にアップロード手順の開始を伝える。コンテンツ送信部２３はコンテンツ記憶部２１に記憶されたコンテンツをコンテンツ受信装置３に送信する。ライブコンテンツは例えばストリーミング方式で送信される。
【００１４】
コンテンツ受信装置３は、コンテンツ記録部３１、コンテンツ生成部３２、コンテンツ受信部３３、中断時判定部３４、コンテンツ継続保持処理部３５を含む。コンテンツ生成部３２はコンテンツ生成要求部２２から送られるアップロード要求に応答して、このアップロード要求の対象コンテンツを格納すべきエントリポイントをコンテンツ記録部３１に生成し、このアップロード要求に組み込まれたメタデータをコンテンツ記録部３１に格納させる。ここで、エントリポイントはメタデータに基づいて決定される。コンテンツ生成部３２はエントリポイントを示すエントリポイント情報をアップロード先(URL:  res@importURI)としてアップロード装置３のコンテンツ生成要求部２２に通知する。コンテンツ受信部３３はコンテンツ送信部２３からアップロード先に対してアップロードされるコンテンツを受信し、このコンテンツのデータをアップロード先に対応するエントリポイントに格納する。コンテンツ記録部３１はこのエントリポイントに関連付けてコンテンツのメタデータを管理する。中断時判定部３４はアップロードの中断に伴ってコンテンツの受信済部分の継続保持および廃棄のいずれか一方の処理を決定する。コンテンツ継続保持処理部３５はコンテンツの受信済部分を継続保持する場合にエントリポイントを示すエントリポイント情報の書き換えを行う。ここで、中断時判定部３４および継続保持処理部３５はコンテンツ管理部を構成する。
【００１５】
図４はアップロード装置２で行われるアップロード処理を示す。このアップロード処理では、コンテンツ生成要求部２２がステップＳ１でコンテンツ記憶部３１からアップロード対象のコンテンツを選択し、このコンテンツのメタデータを取得する。コンテンツ生成要求部２２はさらにステップＳ２でCreateObjectコマンドおよびこのメタデータからなるアップロード要求をコンテンツ受信装置３に送信する。ステップＳ３では、コンテンツ生成要求部２２がコンテンツ受信装置３からコンテンツのアップロード先(URL: res@importURI)として通知されるエントリポイント情報を受信する。ステップＳ４では、コンテンツ送信部３３がアップロード先のURLに対して、コンテンツ記憶部３１から選択されたアップロード対象のコンテンツをアップロードする。
【００１６】
図５はコンテンツ受信装置３で行われる受信処理を示す。この受信処理では、コンテンツ生成部３２がステップＳ１１でアップロード装置２からのアップロード要求を受信し、ステップＳ１２でアップロード対象のコンテンツを格納すべきエントリポイントをコンテンツ記録部３１に生成し、このエントリポイントを示すエントリポイント情報をアップロード先としてアップロード装置２へ送信する。ステップＳ１３では、コンテンツ受信部３３がアップロード装置２からアップロード先に対してアップロードされるコンテンツを待つ。ステップＳ１４では、コンテンツ受信部３３がアップロードされるコンテンツを受信し、アップロード先に対応するコンテンツ記録部３１のエントリポイントに格納させる。コンテンツ受信部３３は、ステップＳ１５で正常にアップロードを完了したコンテンツのエントリポイントに関連付けられたメタデータをアップロード用から公開用に変更する。
【００１７】
以下、アップロード装置２およびコンテンツ受信装置３間の通信内容について説明する。図６はアップロード要求およびこの要求に対する応答の例を示す。ここでは、ContentDirectrory:1サービス仕様のCDS:CreateObjectコマンドとした場合について説明する。図６において、「request」はアップロード要求としてアップロード装置２のコンテンツ生成要求部２２からコンテンツ受信装置３のコンテンツ生成部３２へ送信されるコンテンツ生成要求であり、「response」はこの「request」に対してコンテンツ受信装置３のコンテンツ生成部３２からアップロード装置２のコンテンツ生成要求部２２へ送信される応答である。この「request」では、メタデータはXMLを用いて記述されており、タイトルが”A Newsshow”、開始時刻が2008年2月28日19時で終了時刻が2008年2月28日19時30分であるようなビデオコンテンツのエントリポイントの生成を要求する。「response」では、送られたメタデータの内容に加えて生成されたエントリポイントの識別子（エントリポイント情報）が”12”であること、コンテンツのアップロード先がresタグのimportUri属性に示されているURL “http:/pc/item?id=12”であることが示される。
【００１８】
続いて、アップロード装置２のコンテンツ送信部２３は、コンテンツ記憶部２１からコンテンツを読みだしてコンテンツ受信装置３のコンテンツ受信部33に対して送信する。コンテンツは一括して読みだされることもあるし、放送コンテンツなど部分に分けて読みだされ時間をかけて送られることもある。コンテンツアップロード受信装置３のコンテンツ受信部２２は、送られてきたコンテンツを受信し、コンテンツ記録部３１のメタデータと関連付けられた領域に保存する。
【００１９】
図７は、アップロード対象のコンテンツの送信およびこの送信に対する応答の例を示す。コンテンツの送信は、例えばHTTPプロトコルのPOSTコマンドを用いて行われる。ここでは、URL “http://pc/item?id=12” に対して、MPEG形式のビデオコンテンツを送信し、「成功」が受信側の応答として返されていることを示す。ここでアップロード先として用いられているURL “http://pc/item?id=12” は、コンテンツ生成要求の応答の一部として得られる値である。また、transferMode.dlna.orgヘッダは転送モードを示し、その値 ”Background” は非リアルタイムコンテンツの転送であることを示している。リアルタイム性が要求されるコンテンツの場合には”Streaming”を指定することが期待される。
【００２０】
コンテンツのアップロードが完了すると、コンテンツ受信装置３のコンテンツ受信部３３は、該当するコンテンツのエントリポイントに対するこれ以上のアップロードを禁止するために、コンテンツのアップロード先を指すresタグのimportUri属性を削除し、コンテンツを他の機器からアクセス可能とする場合にはresタグに適切なURLを設定する。
【００２１】
アップロード完了後、コンテンツアップロード受信装置３上のコンテンツエントリは、コンテンツアップロード装置2からUPnP AVのCDS:Browseコマンドによって確認することができる。
【００２２】
図８は、識別子が”12”であるエントリポイントに関連付けられたメタデータの問い合わせおよびこの問い合わせに対する応答の例を示す。アップロード完了後に、再度のアップロードを受け付けないことを示すよう、resタグのimportUri属性は消滅しており、またresタグの値として示されるURL http://pc/cd/content?id=12 からアップロードされてコンテンツをネットワークを通じて取得可能であることを示している。
【００２３】
以上の一連のDLNA1.5のコンテンツアップロード手順において、コンテンツのアップロード、具体的にはHTTPプロトコルのPOSTコマンドによるコンテンツのアップロードが、途中で何らかの原因で中断され、また所定時間の間にアップロード装置２からのアップロードが再開されない場合には、異常終了と判断して、コンテンツ受信装置３はエントリポイント情報とそれまでに受信したコンテンツを削除することで、中途半端なコンテンツがアップロード受信装置３に存在し続けることを回避できる。
【００２４】
コンテンツ受信装置３のコンテンツ受信部３２は、異常終了がPOSTコマンドによるアップロードの中断により発生した場合に、コンテンツ記録部３１内に格納されているコンテンツのエントリポイントとこのコンテンツの受信済部分、すなわち途中まで受信したデータを削除する処理を選択肢として有する。
【００２５】
図９は途中まで受信したデータを削除した場合の問い合わせおよびこの問い合わせに対する応答の例を示す。コンテンツ受信装置２はエントリポイントの削除後、UPnP AVのCDS:Browseコマンドに対して、指定のコンテンツが存在しない旨の応答を返す。
【００２６】
コンテンツ受信装置３では、図１０または図１１に示す判定処理が中断判定部３４を利用することにより図５に示す受信処理のステップＳ１３およびＳ１４と並行して行われる。
【００２７】
図１０に示す判定処理が行われる場合、ステップＳ２１でアップロード中に発生するイベントを待ち受け、ステップＳ２１でアップロードが中断されたかコンテンツ受信部３３から出力される中断イベントの有無によりにチェックされる。アップロードの中断が確認されなければ、ステップＳ２２に続いてステップＳ２１が再び実行される。アップロードの中断が確認されると、ステップＳ２３で中断原因およびコンテンツの性質の少なくとも一方を基準にしてコンテンツの受信済部分の継続保持および廃棄のいずれか一方をコンテンツ受信部３３に対して決定する。この受信済部分の継続保持がステップＳ２４で検出されると、ステップＳ２５で保持手続処理を実行させる。他方、受信済部分の継続保持がステップＳ２４で検出されなければ、ステップＳ２６で該当のエントリポイント情報およびコンテンツの受信済部分を削除する。判定処理はステップＳ２５またはＳ２５に続いて終了する。
【００２８】
図１１に示す判定処理は、アップロードの中断時にアップロードの再開を所定の期間待ち受けるように構成される。この判定処理が行われる場合、ステップＳ３１でアップロード中に発生するイベントを待ち受け、ステップＳ３１でアップロードが中断されたかコンテンツ受信部３３から出力される中断イベントの有無によりにチェックされる。アップロードの中断が確認されなければ、ステップＳ３２に続いてステップＳ３１が再び実行される。アップロードの中断が確認されると、ステップＳ３３で中断原因およびコンテンツの性質の少なくとも一方を基準にしてコンテンツの受信済部分の継続保持および廃棄のいずれか一方をコンテンツ受信部３３に対して決定する。この受信済部分の継続保持がステップＳ３４で検出されると、ステップＳ３５で保持手続処理を実行させる。他方、受信済部分の継続保持がステップＳ３４で検出されなければ、ステップＳ３６でアップロードの再開を所定期間待ち受ける。ステップＳ３７でアップロードの再開が検出されれば、ステップＳ３８でコンテンツの受信を再開して、ステップＳ３１に戻る。これにより、廃棄の決定は無効になる。他方、ステップＳ３７でアップロードの再開が検出されなければ、ステップＳ３９で該当のエントリポイント情報およびコンテンツの受信済部分を削除する。判定処理はステップＳ３５またはＳ３９に続いて終了する。
【００２９】
図１２は図１０に示すステップＳ２５および図１１に示すステップＳ３５で実行される保持手続処理を示す。この保持手続処理はコンテンツ受信部３３からの指示に基づきコンテンツ継続保持処理部３５により行われる。保持手続処理が実行されると、コンテンツ継続保持処理部３５はステップＳ４１でアップロードが中断されたコンテンツに対応するエントリポイントのエントリポイント情報（識別子）を書き換えにより変更し、ステップＳ４２で他装置への公開用にメタデータの内容を調整する。コンテンツ継続保持処理部３５はさらにステップ４３で変更前のエントリポイント情報（識別子）が示すエントリポイントが削除された旨をアップロード装置２に通知し、ステップＳ４４で変更後のエントリポイント情報（識別子）が示すエントリポイントに新規コンテンツが生成された旨をアップロード装置２に通知する。これにより保持手続処理が終了する。この結果、アップロードの中断後においてコンテンツの受信済部分が新規コンテンツとして継続保持されることになる。
【００３０】
図１３はアップロード対象のコンテンツの送信およびアップロードの中断が発生した送信に対する応答の例を示す。コンテンツの送信は、例えばHTTPプロトコルのPOSTコマンドを用いて行われる。ここでは、URL “http://pc/item?id=12” に対して、MPEG形式のビデオコンテンツを送信し、受信側の応答として成功が返されていることを示す。ここでアップロード先として用いられているURL “http://pc/item?id=12” は、コンテンツ生成要求の応答の一部として得られる値である。ここで、転送モードを示すtransferMode.dlna.lrgヘッダには、”Streaming”が指定されるとしておく。これは、アップロードによる予約録画を想定する際、伝送されるコンテンツはその時間帯に放送されているリアルタイム性の高いデータであると考えられるためである。
【００３１】
ただし、アップロード装置２がアップロード対象のコンテンツをすべてアップロードする前に、何らかの原因でアップロードが中断する状況を考える。
【００３２】
この際、コンテンツ受信装置３の中断時判定部３４は、図１０または図１１に示す判定処理を実行し、アップロードの中断原因とコンテンツの性質に基づいて、中断後のコンテンツの継続保持または破棄を決定する。
【００３３】
受信済部分の継続保持を決定するための条件の具体例は次のとおりである。
【００３４】
（１）一部分しか得られなくとも意味のあるコンテンツである。例えば、全体のデータが得られないとデコードできないようなものでない。
【００３５】
（２）アップロードされたコンテンツがライブコンテンツである。
【００３６】
（２−Ａ）転送モードが streamingである。(かつコピー伝送である場合、すなわち MOVE伝送でない場合)
（２−Ｂ）取得したメタデータから、コンテンツが放送コンテンツであって、予定開始/終了時刻が転送時にかぶさる。
【００３７】
（２−Ｃ）転送モードがstreamingであって、コンテンツバイナリに埋め込まれているタイムスタンプが、転送時刻にかぶる。
【００３８】
（３）中断が、受信装置側の理由による場合
（３−Ａ）記憶装置の残量不足
（３−Ｂ）ユーザ操作
（３−Ｃ）受信装置側で予定された中断
実際には、これら条件のいずれ、またはこれら条件のうちの選択的な組み合わせが満足される場合に受信済部分の継続保持が決定される。
【００３９】
本実施形態では、転送モードがstreamingであればアップロード中断時にも保存する、とされていると仮定する。
【００４０】
上記のコンテンツ送信例では、transferModeヘッダにstreamingが指定されており、アップロードが中断された場合に、コンテンツ受信装置３は、それまでに受信したコンテンツを保存すべきと判断する。削除すべきと判断した際の処理内容は、通常通りである。
【００４１】
アップロードが中断されたコンテンツを保持する場合には、保持手続処理において対応するエントリポイントを示すエントリポイント情報である識別子を別のものに変更する。
【００４２】
この変更例では、この識別子が例えば“12”から”112”に変更される。ContentDirectory:1サービスの制約上、ContentDirectory中のいずれのエントリポイントとも識別子が重複しないことが要求されるほかは、識別子の割り当て方法は装置依存である。また、必要に応じて、このエントリに対するアップロードを受け付けない場合には、resタグのimportUri属性の削除を行う。また、途中までアップロードされたコンテンツをアップロード装置２またはその他の装置に対して公開する場合には、resタグに適当なURLを設定したり、メタデータの整合性が取れるよう調整する。また、必要に応じて、変更前の識別子が指すアップロード用のエントリポイントが削除され、変更後の識別子が指す新たなコンテンツが別個に生成された旨を、アップロード装置２に通知する。
【００４３】
図１４はアップロードの中断に伴ってエントリポイント情報である識別子が変更されたコンテンツのメタデータを確認するUPnP AVのCDS:Browseコマンドおよびこのコマンドに対する応答を示す。ここでは、新規のエントリポイント情報である識別子が”112”となっている。アップロード装置２および他の機器側から、具体的な変更後のコンテンツ識別子を取得する手段はない。
【００４４】
図１５に示すように、アップロード先として通知されたエントリポイント情報である識別子”12”に対するUPnP AV CDS:Browseコマンドに対しては、該当するエントリポイントが存在しない旨を応答する。これは、アップロードの異常終了時にDLNA1.5のコンテンツアップロード手順として求められる動作に合致する。
【００４５】
上述した本実施形態では、受信済部分を継続保持する場合にエントリポイントを示すエントリポイント情報が書き換えられる。この書き換えにより、受信済部分が書き換え後のエントリポイント情報に基づいて公開可能となる。他方、アップロード装置に対してアップロード先として通知されたエントリポイント情報は存在しなくなり、アップロード結果の受信済部分がエントリポイントと一緒に削除されたように見せかけることができる。従って、ネットワーク環境でアップロード装置のような既存の機器との接続性を損なうことなくコンテンツの受信済部分を継続的に保持できる。
【００４６】
尚、本発明は上述の実施形態に限定されず、様々に変形可能である。
【００４７】
上述のアップロード受信装置３は、アップロードの中断に伴ってエントリポイント情報である識別子を変更する際に、アップロード装置２に対して変更前と変更後の識別子を通知し、これによりアップロード装置２がアップロードの中断後もコンテンツ受信装置３において継続保持されるコンテンツを追跡可能にしてもよい。
【００４８】
また、変更前の識別子はアップロードの対応を取るための情報として保存しておいてもよい。
【図面の簡単な説明】
【００４９】
【図１】本発明の一実施形態に係るホームネットワークシステムの構成例を示す図である。
【図２】図１に示すアップロード装置およびコンテンツ受信装置の構成例を示す図である。
【図３】図２に示すアップロード装置およびコンテンツ受信装置間の通信内容を示す図である。
【図４】図２に示すアップロード装置で行われるアップロード処理を示す図である。
【図５】図２に示すコンテンツ受信装置で行われる受信処理を示す図である。
【図６】図２に示すアップロード装置およびコンテンツ受信装置間で行われるアップロード要求およびこの要求に対する応答の例を示す図である。
【図７】図２に示すアップロード装置およびコンテンツ受信装置間で行われるアップロード対象のコンテンツの送信およびこの送信に対する応答の例を示す図である。
【図８】図２に示すアップロード装置およびコンテンツ受信装置間で行われるメタデータの問い合わせおよびこの問い合わせに対する応答の例を示す図である。
【図９】図２に示すアップロード装置およびコンテンツ受信装置間で途中まで受信したデータを削除した場合に行われるメタデータの問い合わせおよびこの問い合わせに対する応答の例を示す図である。
【図１０】図２に示すコンテンツ受信装置で行われる判定処理の例を示す図である。
【図１１】図１０に示す判定処理とは異なる判定処理の例を示す図である。
【図１２】図１０および図１１に示す判定処理の一部で行われる保持手続処理を示す図である。
【図１３】図２に示すアップロード装置およびコンテンツ受信装置間の通信内容を示す図である。
【図１４】図２に示すアップロード装置で行われるアップロード処理を示す図である。
【図１５】図２に示すコンテンツ受信装置で行われる受信処理を示す図である。
【符号の説明】
【００５０】
２…コンテンツアップロード装置、３…アップロード受信装置、２１…コンテンツ記憶部、２２…コンテンツ生成要求部、２３…コンテンツ送信部、３１…コンテンツ記録部、３２…コンテンツ生成部、３３…コンテンツ受信部、３４…中断時判定部、３５…コンテンツ継続保持処理部。
【図１】
2010056924.tif 000003
【図２】
2010056924.tif 000004
【図３】
2010056924.tif 000005
【図４】
2010056924.tif 000006
【図５】
2010056924.tif 000007
【図６】
2010056924.tif 000008
【図７】
2010056924.tif 000009
【図８】
2010056924.tif 000010
【図９】
2010056924.tif 000011
【図１０】
2010056924.tif 000012
【図１１】
2010056924.tif 000013
【図１２】
2010056924.tif 000014
【図１３】
2010056924.tif 000015
【図１４】
2010056924.tif 000016
【図１５】
2010056924.tif 000017