(57)【要約】【課題】  ソフトウェア更新方法の一つとして放送波を受信可能なAV製品の場合、通常は放送波からのダウンロードにより自機器のソフトウェアアップデートを行ことができる。しかし、本方法は、放送波を受信できる環境にない機器はソフトウェアを更新することができない。また、手動で実施する場合にはユーザあるいは保守対応員の負担が増大する。【解決手段】  本発明は、ホームネットワークで接続された機器同士でソフトウェアダウンロードを代行することで、放送波が受信できない機器や、外部ネットワークに接続されていない環境、あるいは自機器がリソース使用中でダウンロード不可能な場合、でもファームウェアの取得・更新を行う。また、この際、デジタル放送受信装置は必要に応じてソフトウェアダウンロードの代行を行い、必要とする記憶領域を自機器のダウンロード用に予め持っている一時領域のみとして、特別な記憶領域を不要とする。【選択図】  図１
2009171371.tif 000002
【特許請求の範囲】
【請求項１】
ネットワークで接続された機器同士で映像・音声などのコンテンツを共有するホームネットワークシステムにおいて、
ネットワークで接続された機器からシステム更新のためのソフトウェアダウンロードに必要な告知情報及びダウンロードデータを取得し、システムを更新するネットワーク対応機器と、
放送波からシステム更新のためのソフトウェアダウンロードに必要な告知情報及びダウンロードデータを取得し、ネットワークに送出するデジタル放送受信装置と、
を備えたことを特徴とするホームネットワークシステム。
【請求項２】
請求項１に記載のホームネットワークシステムにおいて、
前記ネットワーク対応機器は、ネットワークを介して音声・映像などのコンテンツを共有して再生・表示するネットワーク対応機器であって、
ネットワークで接続された機器からソフトウェアダウンロードスケジュールなどの告知情報を取得・解析するダウンロードスケジュール管理部と、
ネットワークで接続された機器からダウンロードデータを取得し、これを用いてシステムを更新するダウンロード管理部と、
を備えたことを特徴とするホームネットワークシステム。
【請求項３】
請求項２に記載のホームネットワークシステムにおいて、
前記ネットワーク対応機器は、ネットワークに接続された機器が発行する機器情報を解析し、自機器の代わりに放送波からのデータダウンロードを代行するダウンロード代行サービスを提供している機器かどうかを判定する機器情報管理部、
を備えたことを特徴とするホームネットワークシステム。
【請求項４】
請求項２及び３に記載のホームネットワークシステムにおいて、
前記ダウンロードスケジュール管理部は、機器情報管理部がダウンロード代行サービスを提供していると判定した機器に対して、放送波から告知情報を受信した時に、自機器に対し告知情報受信イベントを通知するように要求すること
を特徴とするホームネットワークシステム。
【請求項５】
請求項２及び３に記載のホームネットワークシステム、
前記ダウンロード管理部は、放送波によるダウンロード時刻の接近を検知すると、機器情報管理部がダウンロード代行サービスを提供していると判定したデジタル情報受信装置に対して、ダウンロード代行及びダウンロードデータ送信を要求すること
を特徴とするホームネットワークシステム。
【請求項６】
請求項２、３及び５に記載のホームネットワークシステムにおいて、
前記ダウンロード管理部は、デジタル情報受信装置に対してダウンロード代行を要求し、対象機器から要求を拒否された場合に、ネットワーク上に存在し、ダウンロード代行サービスを提供する別機器に対して、再度ダウンロード代行を要求すること
を特徴とするホームネットワークシステム。
【請求項７】
請求項２に記載のホームネットワークシステムにおいて、
他機器の提供するダウンロード代行サービスを利用し、ネットワークを介してソフトウェアを取得してシステムを更新する機能を利用するかどうかを設定するユーザインタフェース
を備えたことを特徴とするホームネットワークシステム。
【請求項８】
請求項１に記載のホームネットワークシステムにおいて、
前記デジタル放送受信装置は、放送波から音声・映像などのコンテンツを受信して再生・表示するデジタル放送受信装置あって、
放送波からのソフトウェアダウンロードスケジュールなどを含む告知情報を取得し、これをネットワークで接続された機器に送出する告知情報管理部と、
放送波からのダウンロードデータを取得し、これをネットワークで接続された機器に送出するダウンロード管理部と、
を備えたことを特徴とするホームネットワークシステム。
【請求項９】
請求項８に記載のホームネットワークシステムにおいて、
前記告知情報管理部は、ネットワーク対応機器から告知情報受信イベントを通知するように要求された機器に対してのみ告知情報を送信すること
を特徴とするホームネットワークシステム。
【請求項１０】
請求項８に記載のホームネットワークシステムにおいて、
前記告知情報管理部は、ネットワーク接続された全ての機器に対して告知情報を送信すること
を特徴とするホームネットワークシステム。
【請求項１１】
請求項８及び９または１０に記載のホームネットワークシステムにおいて、
前記告知情報管理部が送信する告知情報が、放送波から受信した告知情報と同一である、または放送波から受信した告知情報を解析した結果であること
を特徴とするホームネットワークシステム。
【請求項１２】
請求項８に記載のホームネットワークシステムにおいて、
自機器の代わりに放送波からのデータダウンロードを代行するダウンロード代行サービスを提供している機器であることを示す機器情報を送信する機器情報管理部、
を備えたことを特徴とするホームネットワークシステム。
【請求項１３】
請求項８に記載のホームネットワークシステムにおいて、
放送波からダウンロードデータを取得し、ネットワークを介して他機器に送信するダウンロード代行サービスを提供するかどうかを設定するユーザインタフェース
を備えたことを特徴とするホームネットワークシステム。
【請求項１４】
請求項８に記載のホームネットワークシステムにおいて、
自機器が放送波受信のために使用するリソースが利用不可能である場合に、ネットワーク接続されたデジタル放送受信装置に対してダウンロード代行及びダウンロードデータ送信を要求する機能
を備えたことを特徴とするホームネットワークシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、放送波からソフトウェア等のダウンロードを実施し、ネットワークで接続された機器に送信するデジタル放送受信装置と、ネットワークで送信された前記ソフトウェアを利用して自機器のソフトウェアを更新するネットワーク対応機器に関する。
【背景技術】
【０００２】
近年、ネットワーク技術の普及により、家庭内のさまざまな場所にAV（Audio/Visual）機器を設置し、これをネットワークで接続して、相互にコンテンツを共有するホームネットワークが普及してきている。ホームネットワーク対応機器であれば、放送波を受信できない環境であっても、ネットワーク経由で取得したコンテンツを視聴することができる。
【０００３】
非特許文献１に記載のDLNA（Digital Living Network Alliance）では、家庭内の機器同士をIP（Internet Protocol）ネットワークで相互に接続し、各機器に蓄積された、あるいはチューナなどを介して利用可能なコンテンツを共有するための標準規格が定められている。本規格では、IPネットワーク上の著作権保護技術として非特許文献２に記載のDTCP-IP（Digital Transmmision Content Protection over Internet Protocol）規格が取り入れられており、ネットワークで接続されたコンテンツ送信元機器が放送波受信可能であれば、そのコンテンツを視聴することも可能である。
【０００４】
一般的に、このようなデジタルAV製品では、ソフトウェア規模の増大に起因する不具合などにより、出荷後にソフトウェアを修正する機会が増大する傾向にある。また、製品に新たな機能を追加する際もソフトウェアの更新のみで対応できる場合がある。このようなソフトウェア更新方法の一つとして放送波を受信可能なAV製品の場合、通常は放送波からのダウンロードにより自機器のソフトウェアアップデートを行ことができる。しかし、本方法では、すべての機器が放送波を受信できる環境にないとソフトウェアを更新することができない。
【０００５】
また、宅外ネットワーク上のサーバから当該ソフトウェアをダウンロードして自動／手動でアップデートする方法もあるが、当該機器が外部ネットワークに接続できない場合には更新できない、手動で実施する場合にはユーザあるいは保守対応員の負担が増大する、という問題がある。
【０００６】
特許文献１では、このような更新の負担を軽減するソフトウェア管理方法として、外部ネットワークに接続されたホームゲートウェイが、宅内のすべての機器のソフトウェアを一元的に管理する手法が提案されている。
【０００７】
【特許文献１】特開2006−128848号公報
【非特許文献１】DLNA  Home Networked Device Interoperability Guidelines
【非特許文献２】DTLA  DTCP Volume 1 Supplement E Revision 1.1 (Informational Version)
【発明の開示】
【発明が解決しようとする課題】
【０００８】
しかし、特許文献１の方法では、ホームゲートウェイにおける放送波からのソフトウェアダウンロードは想定されておらず、外部ネットワークに接続された環境が必須であるため、費用やセキュリティの問題で外部ネットワークへの接続ができない場合に、更新処理が行えないという問題がある。さらに、当該ホームゲートウェイには宅内の機器のソフトウェア情報を保管しておくために特別な記憶領域を必要としているため、当該機能を組み込んだ機器のコストが増大するという問題がある。
【０００９】
また、放送波を受信可能な機器であっても、録画などですべてのリソースを使用している場合、ダウンロード時刻を予め知っていても当該ソフトウェアを受信できないという問題がある。
【課題を解決するための手段】
【００１０】
本発明では、ホームネットワークで接続された機器同士でソフトウェアダウンロードを代行することで、放送波が受信できない機器や、外部ネットワークに接続されていない環境、あるいは自機器がリソース使用中でダウンロード不可能な場合、でもファームウェアの取得・更新を行う。また、この際、デジタル放送受信装置は必要に応じてソフトウェアダウンロードの代行を行い、必要とする記憶領域を自機器のダウンロード用に予め持っている一時領域のみとして、特別な記憶領域を不要とする。
【発明の効果】
【００１１】
本発明によれば、自身が放送波を受信できない環境にある機器、また、外部ネットワークに接続されていない機器であっても、ホームネットワークに接続されていて、ホームネットワーク内に放送波を受信可能な機器が存在すればソフトウェアの自動更新が可能となる。
【００１２】
また、別には、放送波を受信可能な機器であって、更新時刻にリソース使用中の機器であっても、ホームネットワークに接続されていて、ホームネットワーク内に放送波を受信可能な機器が存在すればソフトウェアの自動更新が可能となる。
【００１３】
また、別には、ダウンロードも逐次行う形式であれば、特別な領域は不要となり、コストアップを防ぐことができる。
【発明を実施するための最良の形態】
【００１４】
以下、図面を用いて本発明を実現する最良の形態の実施例を示す。一般的に、デジタル放送受信装置が放送波を利用して自身のソフトウェアダウンロードを行う場合の動作概要は以下の通りである。最初に、デジタル放送受信装置は、受信した放送波に含まれる告知情報を取得する。ここで、告知情報とは、対象となる受信装置の識別情報や、ダウンロードがいつ、どのサービス（チャネル）で行われるかを示すスケジュール情報、ダウンロードされるコンテンツ情報、などのダウンロード及びシステム更新実施に必要な各種情報から構成される事前情報のことである。
【００１５】
次に、デジタル放送受信装置は自機器の不揮発性メモリなどの記憶装置から現在自機器にインストールされているソフトウェアの情報を取得し、告知されたダウンロードの実行要否を判定する。実行が必要と判定した場合は、告知情報から取得したスケジュール情報を元に、ダウンロード開始時刻を待つ。
【００１６】
ダウンロード開始時刻になると、ダウンロードを開始し、取得したダウンロードデータを用いてシステムを更新する。ここでいうダウンロードデータとは、システムの更新に必要なソフトウェアや共通データ（事業者ロゴ、ジャンルコード等）のことである。一方、ダウンロードの実行要否判定で実行不要と判定された場合は、そのまま処理を終え、次の告知情報を待つ。
【実施例１】
【００１７】
以下に、図面を用いて本発明の第１の実施例（正常系）を示す。図１は本発明によるデジタル放送受信装置によるダウンロード代行を可能とするホームネットワークシステムの全体構成図である。デジタル放送受信装置１、７はアンテナ線４を介して地上波放送用アンテナ５及びＢＳＣＳアンテナ６と接続されている。また、ネットワーク対応機器２は、IPネットワーク３を介してデジタル放送受信装置１、７と接続されている。
【００１８】
図２は、図１におけるデジタル放送受信装置１と、ネットワーク対応機器２の間でのダウンロード代行処理が実施されるまでの簡単な概要を示すフロー図である。本ホームネットワークシステムでは、最初にデジタル放送受信装置１が機器情報を送信（Ｓ１１）し、ネットワーク対応機器２がこれを受信・解析する（Ｓ１２）、これにより、機器情報が交換される（Ｓ１）。
【００１９】
次に、ネットワーク対応機器２が告知情報受信イベントの通知を要求し（Ｓ２１）、デジタル放送受信装置１はこれを受けて、ネットワーク対応機器１を告知情報通知先として登録する（Ｓ２２）。これにより告知情報受信イベントの通知登録処理（Ｓ2）が完了する。
【００２０】
デジタル放送受信装置１が放送波からの告知情報を受信したときに、登録済みのネットワーク対応機器２に対して告知情報受信イベント通知を送信（Ｓ３２）し、ネットワーク対応機器２はこれを受信・解析して、ダウンロードの実行時刻を登録する（Ｓ３３）。ここまでが、告知情報配信処理（Ｓ３）である。
【００２１】
最後に、ネットワーク対応機器２は、告知情報で指定されたダウンロード時刻の接近を検知すると、デジタル放送受信装置２に対してダウンロード代行を要求する（Ｓ４１）。デジタル放送受信装置１はこのダウンロード代行要求を受信・解析し（Ｓ４２）、要求されたダウンロードを実行して放送波からダウンロードデータを取得する（Ｓ４３）。
【００２２】
デジタル放送受信装置１はダウンロードが完了すると、ネットワーク対応機器２からの要求に応じて取得したダウンロードデータを送信する（Ｓ４４）。ネットワーク対応機器２は、ダウンロードデータを受信し、その後、システムを更新する（Ｓ４５）。ここまでが、ダウンロード代行処理（Ｓ４）である。
【００２３】
図３は、本発明におけるデジタル放送受信装置１の装置構成を示すブロック図である。デジタル放送受信装置１は、システムを制御するCPU（Central Processing Unit）１０４と、放送波を受信・デスクランブルし、放送信号をデマルチプレクサ１０２に供給するチューナ１０１と、放送信号を映像・音声データとそれ以外に分離するデマルチプレクサ１０２と、受信した映像・音声データに対してデコードその他再生に必要な処理を行い、ディスプレイ・スピーカ等に出力する再生制御部１０３と、告知情報、ダウンロードデータ、映像・音声データなどの送受信を行うネットワークインタフェース１０６と、各種情報を保存するRAM（Ramdom Access Memory）やROM（Read Only Memory）から成る記憶部１０５から構成される。
【００２４】
デジタル放送受信装置１には図３で示した装置以外にも、コンテンツを再生するために必要な一般的なテレビ、PC（Personal Computer）、携帯電話などが具備する機能を有するものであるが、本図では省略している。
【００２５】
図４は、本発明におけるデジタル放送受信装置１の機能構成を示すブロック図である。デジタル放送受信装置１は、デマルチプレクサ１０２で分離され、ＣＰＵ１０４に供給された映像・音声以外の放送信号を受信・解析する放送波受信部１５１と、前記信号のうち告知情報に関する処理を行う告知情報管理部１５２と、前記信号のうちダウンロードデータに関する処理を行うダウンロード管理部と、自機器の設定情報管理や状態管理、他機器の機器情報管理を行う機器情報管理部１５４と、各種データのネットワークインタフェース１０６への送受信を行うネットワーク送受信部１５５と、時刻を管理する時刻管理部１５６から構成される。デジタル放送受信装置１には図４で示した機能ブロック以外にも、コンテンツを再生するために必要な一般的なテレビ、PC、携帯電話などが具備する機能を有するものであるが、本図では省略している。
【００２６】
図５は、本発明におけるネットワーク対応機器２の装置構成を示すブロック図である。ネットワーク対応機器２は、システムを制御するCPU２０３と、告知情報、ダウンロードデータ、映像・音声データなどの送受信を行うネットワークインタフェース２０１と、受信した映像・音声データに対してデコードその他再生に必要な処理を行い、ディスプレイ・スピーカ等に出力する再生制御部２０２と、各種情報を保存するＲＡＭやＲＯＭから成る記憶部２０４から構成される。ネットワーク対応機器２は、図５で示した装置以外にも、コンテンツを再生するために必要な一般的なテレビ、ＰＣ、携帯電話などが具備する機能を有するものであるが、本図では省略している。
【００２７】
図６は、本発明におけるネットワーク対応機器２の機能構成を示すブロック図である。ネットワーク対応機器２は、各種データのネットワークインタフェース２０１への送受信を行うネットワーク送受信部２５１と、告知情報の解析や告知情報を元にダウンロードスケジュールの管理などを行うダウンロードスケジュール管理部２５２と、ダウンロードの実行を制御するダウンロード管理部２５３と、自機器の設定情報管理や状態管理、他機器の機器情報管理を行う機器情報管理部２５４と、内部時刻を管理する時刻管理部２５５、から構成される。ネットワーク対応機器２には図６で示した機能ブロック以外にも、コンテンツを再生するために必要な一般的なテレビ、PC、携帯電話などが具備する機能を有するものであるが、本図では省略している。
【００２８】
以下、本実施例では、ホームネットワークにおいて機器情報を交換する仕組みとしてＵＰｎＰ（Universal Plug & Play）を例に説明するが、ＴＰｎＰ以外の手段を用いても問題ない。
【００２９】
図７は、デジタル放送受信装置１における機器情報送信処理Ｓ１１のフロー図である。また、図８の１０００は、デジタル放送受信装置１が発行する機器情報（ＵＰｎＰのデバイスディスクリプション）の一例を示す図である。以下、図４及び図７、図８を用いて、デジタル放送受信装置１における機器情報送信処理Ｓ１１の流れを説明する。最初に、デジタル放送受信装置１の機器情報管理部１５４は自機器がダウンロード代行サービスを提供するかどうかを確認する（Ｓ１１１）。
【００３０】
自機器がダウンロード代行サービスを提供するかどうかは、例えばユーザの意思などに従って決定される。ユーザ意思を反映する場合の設定画面例を、図１８の５０００に示す。自機器がダウンロード代行サービスを提供する設定と判定された場合（Ｓ１１１のＹＥＳ）は、発行する機器情報に、自機器がダウンロード代行サービスを提供していることを示す記述として、図８の１００１を追加する（Ｓ１１２）。
【００３１】
一方、自機器がダウンロード代行サービスを提供しない設定と判定された場合（Ｓ１１１のＮＯ）は、何もしない。最後に、機器情報管理部１５４は、ネットワーク送受信部１５５を介して、ネットワークに自機器の機器情報を送信する（Ｓ１１３）。
【００３２】
図９は、ネットワーク対応機器２における機器情報受信処理Ｓ１２及び告知情報受信イベント通知要求発行処理Ｓ２１のフロー図である。また、図１０は、ネットワーク対応機器２からデジタル放送受信装置１への告知情報受信イベント通知要求及び、その応答メッセージの一例である。
【００３３】
以下、図６、図８、図９、図１０を用いて、ネットワーク対応機器２における機器情報受診処理Ｓ１２の流れを説明する。ネットワーク対応機器２の機器情報管理部２５４は最初に、ネットワーク送受信部２５１を介して、デジタル放送受信装置１が発行する図８の１０００に示す機器情報を受信する（Ｓ１２１）。機器情報取得後、機器情報管理部２５４は、自機器のダウンロード代行サービス利用設定が有効であるかどうかを確認する（Ｓ１２２）。ここで、ダウンロード代行サービス利用が有効であるか、無効であるかは、例えばユーザの意思などによって決定される。
【００３４】
ユーザ意思を反映する場合の設定画面例を、図１９の５１００に示す。ここまでが、機器情報受信処理Ｓ１２に相当する。自機器のダウンロード代行サービス利用設定が有効である場合（Ｓ１２２のYES）は、取得した機器情報１０００に図８の１００１に示すサービス“urn:schemas-xrdl-org:service:X_ScheduledDownload:1”に関する記述が含まれるかどうかによって、デジタル放送受信装置１がダウンロード代行サービスを提供しているかどうかを確認する（Ｓ１２３）。
【００３５】
ダウンロード代行サービスが提供されている場合（Ｓ１２３のＹＥＳ）、ネットワーク対応機器２はデジタル放送受信装置１から当該サービスに関する詳細情報を取得後、告知情報受信のイベント通知要求として、図１０に示すURI２００１を指定したサブスクライブメッセージ２０００を発行し（Ｓ１２４）、そのレスポンス２１００を受信したところで、処理を終了する（Ｓ１２５）。
【００３６】
自機器のダウンロード代行サービス利用設定が無効である場合（Ｓ１２２のＮＯ）、及びダウンロード代行サービスが提供されていない場合（Ｓ１２３のＮＯ）は、何もせず処理を終了する。ここまでが、告知情報受信イベント通知要求発行処理Ｓ２１に相当する。
【００３７】
図１１は、デジタル放送受信装置１における告知情報送信機器の登録処理Ｓ２２のフロー図である。以下、図４、図１０、図１１を用いて、デジタル放送受信装置１における告知情報送信機器登録処理Ｓ２２の流れを示す。デジタル放送受信装置１の告知情報管理部１５２は、ネットワーク送受信部１５５を介して、ネットワーク対応機器２から送信された告知情報受信イベント通知要求２０００を受信する（Ｓ２２１）。次に、告知情報管理部１５２は、機器情報管理部１５４に自機器がダウンロード代行サービスを提供しているかどうかを問い合わせる（Ｓ２２２）。
【００３８】
自機器がダウンロード代行サービスを提供している場合（Ｓ２２２のＹＥＳ）は、告知情報配信先として、告知情報受信イベント通知要求の送信元機器を登録する（Ｓ２２３）。一方、自機器がダウンロード代行サービスを提供していない場合（Ｓ２２２のＮＯ）は、何もせずに処理を終了する。
【００３９】
図１２は、デジタル放送受信装置１における告知情報送信処理Ｓ３１のフロー図である。また、図１３は、デジタル放送受信装置１が発行する告知情報受信イベントメッセージの一例である。尚、以下の説明ではデジタル放送受信機器から送信する場合、告知情報と告知情報受信イベント通知は同義で使用する。
【００４０】
以下、図４、図１２及び図１３を用いて、デジタル放送受信装置１における告知情報送信処理の流れを説明する。デジタル放送受信装置１の告知情報管理部１５２は、放送波受信部１５１から、放送信号に含まれた告知情報を取得する（Ｓ３１１）。
【００４１】
次に、告知情報管理部１５２は、告知情報受信イベント通知が必要な機器の有無を確認する（Ｓ３１２）。通知先機器の登録がない場合（Ｓ３１２のNO）は、処理の最初に戻り、告知情報を受信するところ（Ｓ３１１）から前記処理を繰り返す。
【００４２】
通知先機器の登録がある場合（Ｓ３１２のYES）は、対象機器に対して、告知情報受信イベントとして、図１３の３０００に示すメッセージを生成し、ネットワーク送受信部１５５を介してこれを送信する（Ｓ３１３）。尚、本メッセージには、本情報が告知情報であることを示す３００１に示すタグ及び告知情報の内容を示す３００２に示すタグを含む。
【００４３】
メッセージ発行後は、処理の最初に戻り、告知情報を受信するところ（Ｓ３１１）から前記処理を繰り返す。以上により、告知情報の配信処理が完了となる。本実施例においては、告知情報の送信先を、予め登録された機器のみとしたが、前記登録処理を行わず、受信した告知情報をすべてネットワーク上にブロードキャストで配信する構成にしてもよい。
【００４４】
図１４は、ネットワーク対応機器２における告知情報受信処理Ｓ３２のフロー図である。以下、図６、図１３及び図１４を用いて、ネットワーク対応機器２における告知情報受信イベント受信処理の流れを説明する。ネットワーク対応機器２のダウンロードスケジュール管理部２５２は、ネットワーク送受信部２５１を介して、デジタル情報受信装置１から送信された告知情報受信イベントであるメッセージ３０００を受信する（Ｓ３２１）。
【００４５】
ダウンロードスケジュール管理部２５２は、メッセージ３０００を解析し（Ｓ３２２）、告知情報に含まれる対象機器の識別情報やダウンロードされるコンテンツ情報から、自機器に必要な更新が必要かどうかを判定する（Ｓ３２３）。
【００４６】
更新が不要と判定した場合（Ｓ３２３のNO）は、処理を終了する。一方、更新が必要と判定した場合（Ｓ３２３のYES）は、時刻管理部２５５にダウンロード時刻を登録する（Ｓ３２４）。以上により、ネットワーク対応機器２における告知情報受信処理が完了する。尚、本実施例では、告知情報はネットワーク対応機器が解析する方法を示したが、予めデジタル放送受信装置側でメーカID、ソフトウェアバージョンなどを詳細に解析し、ネットワーク対応機器は開始時刻だけ通知される、という構成にすることも可能である。
【００４７】
図１５は、ネットワーク対応機器２における、ダウンロード代行要求処理Ｓ４１及びダウンロードデータ取得処理Ｓ４５のフロー図である。図１６は、ダウンロード代行処理を要求するメッセージ及びレスポンスの一例である。以下、図６、図１５、図１６を用いて、ネットワーク対応機器２におけるダウンロード代行要求処理の流れを説明する。ネットワーク対応機器２のダウンロードスケジュール管理部２５２は時刻管理部２５５から、ダウンロード時刻の接近を通知される（Ｓ４１１）と、ネットワーク送受信部２５１を介し、デジタル放送受信装置１に対して図１６の４０００に示すダウンロード代行処理の開始を要求するＳＯＡＰリクエストを送信する（Ｓ４１２）。
【００４８】
ここで、要求先のデジタル放送受信装置１が停止状態やスタンバイ状態で、メッセージを受信できない状態にある場合は、ＷＯＬ（Wakeup On LAN）を利用して、これを起動してもよいし、警告メッセージを表示する、ビープ音を鳴らすなどによってユーザに起動を促してもよい。次に、前記要求に対してデジタル情報受信装置１から返されるレスポンスメッセージ（図１６の４１００）を受信し（Ｓ４１３）、開始要求の成否を判定する（Ｓ４１４）。
【００４９】
要求が失敗した場合（Ｓ４１４のNO）、処理を終了する。要求が成功した場合（Ｓ４１４のＹＥＳ）、ダウンロードスケジュール管理部２５２は、ダウンロードデータ管理部２５３にダウンロード開始を通知する。ここまでが、ダウンロード代行要求処理Ｓ４１に相当する。
【００５０】
次に、ダウンロードデータ取得処理Ｓ４５に進む。ダウンロードデータ管理部２５３は、ダウンロードスケジュール管理部２５２からダウンロード開始を通知されると、デジタル放送受信装置１の、前記レスポンスで指定されたＵＲＩ（図１６の４１０１）に対して、HTTP  GET要求を発行する（Ｓ４５１）。
【００５１】
ダウンロードデータ管理部２５３は、前記GET要求のレスポンスとしてダウンロードデータを受信する（Ｓ４５２）。ダウンロードデータの受信が完了すると、これを保管し、任意のタイミングでシステムを更新する（Ｓ４５３）。ダウンロードデータ保存後のシステム更新の方法は、放送波から直接ダウンロードする場合と同様の処理で問題ないので、ここでは説明を省略する。
【００５２】
図１７は、デジタル放送受信装置１におけるダウンロード代行処理Ｓ４２〜Ｓ４４のフロー図である。以下、図４、図１６、図１７を用いて、デジタル放送受信装置１におけるダウンロード代行処理の流れを説明する。デジタル放送受信装置１のダウンロード管理部１５３は、ネットワーク対応機器２から送信されたダウンロード代行要求４０００を受信すると（Ｓ４２１）、機器情報管理部１５４に自機器のリソース状態を問い合わせ、当該要求の処理可否を確認する（Ｓ４２２）。
【００５３】
ここで、自機器のリソース状態とは、放送波受信部１０３の現在の使用状況、録画予約などの状況及び、ネットワークインタフェースの使用状態のことであり、当該要求を処理可能な状態とは、放送波から要求されたダウンロードデータを受信し、要求元機器に送信できる状態にあることをいう。また要求受け入れ可否は、図２０の画面５２００内に示す、５２０１のようなポップアップを用いてユーザに問い合わせてもよい。
【００５４】
ダウンロード管理部１５３が、当該要求は処理不可と判定した場合（Ｓ４２２のＮＯ）は、ネットワーク送受信部１５５を介してネットワーク対応機器２に対してＮＧレスポンスを送信し（Ｓ４２４）、処理を終了する。当該要求を処理可能と判定した場合（Ｓ４２２のＹＥＳ）、ダウンロード管理部１５３は、ネットワーク送受信部１５５を介して、ネットワーク対応機器２に対してダウンロードデータ取得用のＵＲＬを含めてＯＫレスポンスを送信する（Ｓ４２３）。
【００５５】
次に、放送波受信部１５１に要求されたチャネルの放送信号受信を指示し、ダウンロードデータの受信を開始する（Ｓ４３１）。次に、ダウンロード管理部１５３は放送波受信部１５１から、放送信号に含まれるダウンロードデータを取得する（Ｓ４３２）。ダウンロード管理部１５３は、ネットワーク対応機器２からダウンロードデータ取得要求であるHTTP  GETリクエストを受信すると（Ｓ４４１）、ダウンロードが完了しているかどうかを確認する（Ｓ４４２）。
【００５６】
ダウンロードが完了している場合（Ｓ４４２のＹＥＳ）、ネットワーク送受信部１５５を介しネットワーク対応機器２にダウンロードデータを送信する（Ｓ４４３）。ダウンロードが未完了の場合（Ｓ４４２のＮＯ）、Ｓ４３１に戻りダウンロードを継続する。
【００５７】
以上により、放送波を受信できず、外部のネットワークに接続されていないホームネットワーク機器であっても、他の放送波受信装置にダウンロード代行を要求し、これを取得することでソフトウェアダウンロードによるシステム更新が可能となる。また、本発明によれば、必要に応じて逐次ダウンロードの代行を要求するため、代行処理を実施する機器には自機器のソフトウェアダウンロード用の一時領域のみあればよく、ダウンロードしたソフトウェアを保持しておく特別な領域を必要としない。
【実施例２】
【００５８】
以下に、図面を用いて本発明の第２の実施例（断られたら他に要求する）を示す。ここで説明する実施の形態は、ホームネットワーク内に放送波受信可能なデジタル放送受信装置が複数存在する場合に、最初にダウンロード代行処理を要求したデジタル放送受信装置が当該要求を受け入れられない場合であっても、別のデジタル放送受信装置に対して要求を行うことで、ダウンロードデータ取得の機会を逃す確率を低減させることを目的とする。
【００５９】
本実施形態においても、ネットワーク対応機器２が告知情報を取得し、デジタル放送受信装置１に対してダウンロード代行要求処理の実施（図１５のＳ４１１）までは、実施の形態１と同様である。
【００６０】
図２１は、本実施形態におけるダウンロード代行要求処理のフロー図である。最初に、ネットワーク対応機器２のダウンロードスケジュール管理部２５２は、ネットワーク送受信部２５１を介して、デジタル放送受信装置１に対して図１６の４０００に示すダウンロード代行処理の開始を要求するＳＯＡＰリクエストを送信する（Ｓ５０１）。
【００６１】
次に、前記要求に対してデジタル情報受信装置１から返されるレスポンスメッセージ（図１６の４１００）を受信し（Ｓ５０２）、開始要求の成否を判定する（Ｓ５０３）。要求が成功した場合（Ｓ５０３のＹＥＳ）、図１５のＳ４５１からＳ４５３の処理を実施し、システムを更新する。これは、第１の実施形態と同様の処理である。一方、要求が失敗した場合（Ｓ５０３のＮＯ）、機器情報管理部１５４は、再度ホームネットワークに接続された機器の機器情報を収集し（Ｓ５０４）、ダウンロード代行サービスを提供する機器が存在するかどうかを確認する（Ｓ５０５）。
【００６２】
ダウンロード代行サービスを提供する機器が存在しない場合（Ｓ５０５のＮＯ）は、処理を終了する。一方、ダウンロード代行サービスを提供する機器が存在する場合（Ｓ５０５のＹＥＳ）は、次のステップに進み、対象機器に対してダウンロード代行要求を発行済みかどうかを確認する（Ｓ５０６）。
【００６３】
対象機器に対してダウンロード代行要求を未発行の場合（Ｓ５０６のＹＥＳ）は、Ｓ５０１に戻り、要求発行処理を開始する。対象機器に対してダウンロード代行要求を発行済みの場合（Ｓ５０６のＮＯ）は、Ｓ５０５に戻り、他にダウンロード代行サービスを提供する機器が存在するかどうかを確認する。以下、いずれかの機器にダウンロード代行要求が成功するか、ダウンロード代行サービスを提供する機器が新規に発見できなくなるまで、前記処理を繰り返す。
【００６４】
ここでは、その都度機器探索を行う実施例を示したが、起動時にすべてを登録することもできるし、機器がネットワークに参加する都度アドバタイズされる情報を保持しておいて、要求失敗時に改めて機器情報を収集せず、迅速に再要求を行う方法も可能である。
【００６５】
以上により、最初にダウンロード代行処理を要求したデジタル放送受信装置が当該要求を受け入れられない場合であっても、別のデジタル放送受信装置に対して要求を行うことで、ダウンロードデータ取得の機会を逃す確率を低減させることできる。
【実施例３】
【００６６】
次に、本発明の第３の実施例（自分が忙しかったら他に要求する）を図面を用いて説明する。ここで説明する実施の形態は、ホームネットワーク内に放送波受信可能なデジタル放送受信装置が複数存在する場合に、放送波が受信可能なデジタル放送受信装置であっても、ダウンロード時刻に自機器のリソースが使用中であり、ソフトウェアのダウンロードができない場合に、別のデジタル放送受信装置に対してダウンロード代行処理要求を行うことで、ダウンロードデータ取得の機会を逃す確率を低減させることを目的とする。
【００６７】
本実施形態においても、ネットワーク対応機器２が告知情報を取得し、デジタル放送受信装置１に対してダウンロード代行要求処理の実施（図１５のＳ４１１）までは、実施の形態１と同様である。
【００６８】
図２２は、本実施形態におけるダウンロード代行要求処理のフロー図である。デジタル放送受信装置７のダウンロード管理部は、時刻管理部１５６からダウンロード時刻が接近したことを通知される（Ｓ６０１）と、機器管理部１５４に自機器のリソース状態を問い合わせ、放送波からのダウンロード処理実行可能かどうかを確認する（Ｓ６０２）。放送波からのダウンロード処理が可能であると判定された場合（Ｓ６０３のＹＥＳ）、放送波を直接利用してダウンロードを行い、システムを更新する（Ｓ６０８）。
【００６９】
一方、放送波からのダウンロード処理が不可能であると判定された場合（Ｓ６０３のＮＯ）、ホームネットワークに接続された機器の機器情報を収集し（Ｓ６０４）、ダウンロード代行サービスを提供する機器が存在するかどうかを確認する（Ｓ６０５）。ダウンロード代行サービスを提供する機器が存在しない場合（Ｓ６０５のＮＯ）は、処理を終了する。一方、ダウンロード代行サービスを提供する機器が存在する場合（Ｓ６０５のＹＥＳ）、要求発行処理を開始し（Ｓ６０６）、以下図１５と同様の処理を行ってシステムを更新する（Ｓ６０７）。
【００７０】
ここでは、必要になったら機器情報を収集する実施例を示したが、起動時にすべてを登録することもできるし、機器がネットワークに参加する都度アドバタイズされる情報を保持しておくことでダウンロード処理が不可能と判明した際に改めて機器情報を収集せず、迅速に別機器への要求要求を行う方法も可能である。
【００７１】
以上により、ダウンロード時刻に自機器のリソースが使用中であり、ソフトウェアのダウンロードができない場合に、別のデジタル放送受信装置に対してダウンロード代行処理要求を行うことで、ダウンロードデータ取得の機会を逃す確率を低減させることができる。
【図面の簡単な説明】
【００７２】
【図１】本発明を用いるホームネットワークシステムの全体構成図
【図２】ネットワークを介したダウンロード代行処理全体の流れを示すシーケンス図
【図３】デジタル放送受信装置の装置構成を示すブロック図
【図４】デジタル放送受信装置の機能構成を示すブロック図
【図５】ネットワーク対応機器の装置構成を示すブロック図
【図６】ネットワーク対応機器の機能構成を示すブロック図
【図７】デジタル放送受信装置における機器情報送信処理のフロー図
【図８】デジタル放送受信装置が発行する機器情報（UPnPのデバイスディスクリプション）の一例
【図９】ネットワーク対応機器における機器情報受信処理及び告知情報受信イベント通知要求発行処理のフロー図
【図１０】ネットワーク対応機器からデジタル放送受信装置への告知情報受信イベント通知要求及び、その応答メッセージの一例
【図１１】デジタル放送受信装置における告知情報送信機器の登録処理のフロー図
【図１２】デジタル放送受信装置における告知情報送信処理のフロー図
【図１３】デジタル放送受信装置が発行する告知情報受信イベントメッセージの一例
【図１４】ネットワーク対応機器における告知情報受信イベント受信処理のフロー図
【図１５】ネットワーク対応機器における、ダウンロード代行要求処理のフロー図
【図１６】ダウンロード代行処理を要求するメッセージ及びレスポンスの一例
【図１７】デジタル放送受信装置におけるダウンロード代行処理のフロー図
【図１８】自機器がダウンロード代行サービスを提供するかどうかを設定する設定画面例
【図１９】自機器がダウンロード代行サービスを利用してシステム更新するかどうかを設定する設定画面例
【図２０】ダウンロード代行処理要求受信時に、自機器のリソースを当該処理に利用してよいかどうかを確認する確認画面例
【図２１】実施形態２におけるダウンロード代行要求処理のフロー図である
【図２２】実施形態３におけるダウンロード代行要求処理のフロー図である
【符号の説明】
【００７３】
１  デジタル放送受信装置
２  ネットワーク対応機器
３  ＩＰネットワーク
４  アンテナ線
５  地上派放送用アンテナ
６  ＢＳＣＳ放送用アンテナ
１０１  チューナ
１０２  デマルチプレクサ
１０３、２０２  再生制御部
１０４、２０３  ＣＰＵ
１０５、２０４  記憶部
１０６、２０１  ネットワークインタフェース
１５１  放送波受信部
１５２  告知情報管理部
１５３、２５３  ダウンロード管理部
１５４、２５４  機器情報管理部
１５５、２５１  ネットワーク送受信部
２５２  ダウンロードスケジュール管理部
【図１】
2009171371.tif 000003
【図２】
2009171371.tif 000004
【図３】
2009171371.tif 000005
【図４】
2009171371.tif 000006
【図５】
2009171371.tif 000007
【図６】
2009171371.tif 000008
【図７】
2009171371.tif 000009
【図８】
2009171371.tif 000010
【図９】
2009171371.tif 000011
【図１０】
2009171371.tif 000012
【図１１】
2009171371.tif 000013
【図１２】
2009171371.tif 000014
【図１３】
2009171371.tif 000015
【図１４】
2009171371.tif 000016
【図１５】
2009171371.tif 000017
【図１６】
2009171371.tif 000018
【図１７】
2009171371.tif 000019
【図１８】
2009171371.tif 000020
【図１９】
2009171371.tif 000021
【図２０】
2009171371.tif 000022
【図２１】
2009171371.tif 000023
【図２２】
2009171371.tif 000024