映像録画装置、端末装置、録画映像提供方法、映像録画装置の制御プログラム
【課題】ネットワーク上の録画装置において効率的に録画コンテンツを管理、編集できるようにし、著作権に関わる人の間での利益の分配を適切に行ないつつ、視聴者に録画済み番組の編集機能を提供すると共に、より柔軟な広告機能を提供する。
【解決手段】取得した放送番組データをデータベースに格納する番組データ受信部２０５と、放送番組データを特定する情報および放送番組データの放送開始時刻から放送終了時刻までの間のいずれかの時間的範囲を示す情報を含む構成情報を格納する構成管理データベース２５３と、端末装置３〜３’’から構成管理データベースに格納されている構成情報を編集する編集要求があったときに、編集要求に従って、構成情報の編集を実行する編集制御部２０３と、編集後の構成情報に基づいて、放送番組データの全部または一部を端末装置に配信する番組データ配信部２０６と、を備える。
【解決手段】取得した放送番組データをデータベースに格納する番組データ受信部２０５と、放送番組データを特定する情報および放送番組データの放送開始時刻から放送終了時刻までの間のいずれかの時間的範囲を示す情報を含む構成情報を格納する構成管理データベース２５３と、端末装置３〜３’’から構成管理データベースに格納されている構成情報を編集する編集要求があったときに、編集要求に従って、構成情報の編集を実行する編集制御部２０３と、編集後の構成情報に基づいて、放送番組データの全部または一部を端末装置に配信する番組データ配信部２０６と、を備える。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、視聴者から録画要求された放送番組を取得して視聴者に代行して録画し、配信サービスを行なう映像録画装置に関し、特に、関係者との契約に基づき、録画済み番組を編集し、編集済みの録画番組を視聴者に配信する映像録画装置、端末装置、録画映像提供方法、映像録画装置の制御プログラムに関する。
【背景技術】
【０００２】
従来から、インターネットなどのグローバルネットワークの高速化に伴い、ＩＰ（Internet Protocol）ネットワーク上でテレビジョン番組の動画像配信が行なえるシステムが登場しつつある。また、配信のみならず、その配信済みもしくは未配信の動画像を、ネットワーク上のストレージに記録することで、視聴者に代わって録画を行なうシステムが存在する。例えば、特許文献１にて開示された技術では、複数の端末から録画要求を受け付け、録画対象の放送番組を録画し、各端末からの再生要求に応えてストリーミング再生するシステムが提案されている。このシステムでは、複数の端末から同一の番組の録画を要求された場合には、唯一のデータをストレージ上に記録し、各端末へはその共通のデータを、それぞれの各端末へ配信することで、効率的なストレージの利用を実現している。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２００４−１９４２５５号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
しかしながら、特許文献１では、視聴者の当然の欲求である、録画済みデータに対する編集（ＣＭ（Commercial Message）カットなど）を可能とする技術は提供されておらず、視聴者が繰り返し視聴したいお気に入りの番組も、毎回、ＣＭを見るか、あるいは、スキップ操作をすることが必要で、煩わしかった。
【０００５】
また、録画データは放送局から直接受け取るため、受信者毎の要望に合った番組を提供する処理がない。このため、全ての受信者が同じコンテンツを見ることしかできない。ユーザは、繰り返し見るようなコンテンツの場合、ＣＭを何度も見なければならず、よりユーザフレンドリーな技術が望まれていた。
【０００６】
ここで、ＣＭカットなどの編集操作ができるようにする場合問題となるのが、放送番組の著作権の問題である。放送番組は著作物であり、著作権者に無断で自由に編集ができることとすると、著作権上の問題が発生する可能性がある。著作権者と編集許諾契約を結び、著作権利用料を著作権者に払った場合には、著作物を自由に編集することが可能となるが、一般のユーザが全ての編集操作に対して著作権利用料の全額を負担するのは割に合わず、編集操作を諦めてしまうことにつながる可能性がある。このような放送番組の編集についての著作権に関する利害関係をどのように調整するのかが問題となる。
【０００７】
本発明は、このような事情に鑑みてなされたものであり、ネットワーク上の録画装置において効率的に録画コンテンツを管理、編集できるようにし、著作権に関わる人の間での利益の分配を適切に行ないつつ、視聴者に録画済み番組の編集機能を提供すると共に、より柔軟な広告機能を提供する映像録画装置、端末装置、録画映像提供方法、映像録画装置の制御プログラムを提供することを目的とする。
【課題を解決するための手段】
【０００８】
（１）上記の目的を達成するために、本発明は、以下のような手段を講じた。すなわち、本発明の映像録画装置は、ネットワークに接続されている端末装置に対して録画映像を提供する映像録画装置であって、放送番組データを取得し、取得した放送番組データをデータベースに格納する番組録画部と、放送番組データを特定する情報および放送番組データの放送開始時刻から放送終了時刻までの間のいずれかの時間的範囲を示す情報を少なくとも含む構成情報を格納する構成管理データベースと、端末装置から構成管理データベースに格納されている構成情報を編集する編集要求があったときに、編集要求に従って、構成情報の編集を実行する編集制御部と、編集後の構成情報に基づいて、放送番組データの全部または一部を端末装置に配信する番組データ配信部と、を備えることを特徴とする。
【０００９】
このように、本発明は、放送番組データを特定する情報および放送番組データの放送開始時刻から放送終了時刻までの間のいずれかの時間的範囲を示す情報を少なくとも含む構成情報を格納するので、ユーザの端末装置からの録画予約に応じて、番組の構成情報を含む録画予約レコードを構成管理データベースに格納することができる。さらに、構成情報の編集を実行するので、ユーザ端末装置から番組コンテンツの編集要求があれば、編集制御部が上記構成管理データバースに格納された構成情報を編集することができる。これにより、放送番組データのような容量の大きなデータを編集することなく、編集された放送番組をユーザが視聴することができる。
【００１０】
（２）また、本発明の映像記録装置において、端末装置から構成管理データベースに格納されている構成情報を編集する編集要求があったときに、その編集要求を承認するか否かを判定する承認処理部と、編集要求を承認するための編集条件を示す情報を格納する編集条件データベースと、をさらに備え、承認処理部は、編集条件データベースに格納されている編集条件に基づいて、編集要求を承認するか否かを判定し、編集制御部は、判定の結果、編集要求が承認された場合、編集要求に従って、構成情報の編集を実行することを特徴とする。
【００１１】
このように、編集要求を承認するか否かを判定する承認処理部と編集条件を示す情報を格納する編集条件データベースを備えるので、ユーザの編集要求を編集条件データベースに格納することができ、承認処理部はこれに基づき編集要求を承認するか否かを判定することができる。これにより、著作権に関わる人の間の契約に基づいて、ユーザの編集条件を制御することができる。編集制御部は、判定の結果、編集要求が承認された場合、編集要求に従って、構成情報の編集を実行するので、ユーザの要求に従って、放送番組を編集することができる。
【００１２】
（３）また、本発明の映像記録装置において、番組データ配信部は、視聴範囲として、配信した放送番組データを示す情報を記憶する視聴範囲記憶部を備え、編集要求の対象となった放送番組データの全部または一部が、視聴範囲に含まれることを編集条件とする。
【００１３】
このように、視聴範囲記憶部を備えることにより、承認処理部が編集条件に基づいて編集要求を承認するか否かを判定する際に、ユーザが、その編集するコンテンツを視聴したかどうかを判断基準とすることができる（後述の「視聴範囲編集」に相当）。
【００１４】
（４）また、本発明の映像記録装置において、編集要求の対象となった放送番組データの全部または一部が録画された時刻から、予め定められた時間が経過することを編集条件とする。
【００１５】
このように、予め定められた時間が経過することを編集条件とすることにより、特定期間が経過するまでは、ＣＭがカットされることはないため、広告主にとって大きな不利益になることはない。また、特定時間が経過した後はＣＭカットができるようになるため、長期間保存しておきたい録画コンテンツの整理ができ、ユーザにとって利益となる（後述の「特定期間後」に相当）。
【００１６】
（５）また、本発明の映像録画装置において、構成情報の編集に対する課金を実行すると共に、課金に関する情報を記憶する課金処理部をさらに備え、承認処理部は、課金が実行されたか否かに応じて編集要求を承認するか否かを判定することを特徴とする。
【００１７】
このように、承認処理部が契約に基づく編集条件の可否を判定すると共に、それに応じて課金されたか否かを判定することにより、契約に応じた適切な課金処理を実現できる。
【００１８】
（６）また、本発明の映像録画装置において、課金処理部は、編集回数または編集サイズを示す情報を記憶すると共に、端末装置による編集に伴って増減する編集回数または編集サイズに基づいて課金を実行することを特徴とする。
【００１９】
このように、編集回数または編集サイズに基づいて課金することにより、契約に基づいた適切な課金をすることができる。
【００２０】
（７）また、本発明の映像録画装置において、課金処理部は、編集回数または編集サイズの上限値または下限値を記憶すると共に、端末装置による編集に伴って増減する編集回数または編集サイズが、上限値または下限値を超える場合は、課金の実行を停止することを特徴とする。
【００２１】
このように、編集回数または編集サイズに上限値または下限値を設け、それに応じて課金停止をすることにより、編集に対する一定の制限がかかり、ユーザが想定しない編集をすることを防ぐことができる。
【００２２】
（８）また、本発明の映像録画装置において、番組データ配信部は、端末装置とは異なる他の端末装置から、端末装置の編集要求に基づいて録画された放送番組データを検索する旨の検索要求があったときに、検索要求に従って、放送番組データの検索を行ない、検索した放送番組データを他の端末装置へ配信することを特徴とする。
【００２３】
このように、他の端末装置による検索視聴要求に従って、検索された放送番組データをその端末装置へ配信することにより、第三者は契約をしているユーザと同様に放送番組データを視聴することができる。
【００２４】
（９）また、本発明の映像録画装置において、番組データ配信部は、端末装置から公開設定要求があったときに、録画した放送番組データが他の端末装置からの検索要求に応じて検索されるように設定を行ない、承認処理部は、他の端末装置から検索要求があったときに、検索要求を承認するか否かを判定することを特徴とする。
【００２５】
このように、承認処理部が他の端末装置から検索要求があったときに、検索要求を承認するか否かを判定することにより、放送番組データの第三者公開に関して一定の制限をかけることができる。これにより、ユーザと映像録画装置の事業者との契約に基づいた公開が可能となる。
【００２６】
（１０）また、本発明の映像録画装置において、公開設定要求を承認するための公開条件を示す情報を記憶する公開条件データベースをさらに備え、承認処理部は、公開条件データベースに格納されている公開条件に基づいて、公開設定要求を承認するか否かを判定することを特徴とする。
【００２７】
このように、公開条件を示す情報を記憶する公開条件データベースを設け、公開条件に基づいて承認判定を行なうことにより、録画データの公開回数に対して契約に基づく制限をすることが可能となる。
【００２８】
（１１）また、本発明の映像録画装置において、公開設定要求の対象となった放送番組データの全部または一部が、視聴範囲に含まれることを公開条件とする。
【００２９】
このように、放送番組データの全部または一部が、視聴範囲に含まれていることを公開条件とすることにより、少なくとも一度はユーザがＣＭを視聴する必要があるため、広告主の目的を少なくとも部分的に達成することができる。
【００３０】
（１２）また、本発明の映像録画装置において、公開設定要求の対象となった放送番組データの全部または一部が録画された時刻から、予め定められた時間が経過することを公開条件とする。
【００３１】
このように、録画された時刻から、予め定められた時間が経過することを公開条件とすることにより、特定期間が経過するまでは、公開前の状態が保たれる為、公開前の状態においてＣＭがある場合に、その広告主にとって大きな不利益になることはない。また、特定期間が経過した後は公開される為、公開時に新しいＣＭデータを挿入することが可能となり、その広告主にとって利益となる。
【００３２】
（１３）また、本発明の映像録画装置において、公開設定に対する課金を実行すると共に、課金に関する情報を記憶する公開設定課金処理部をさらに備え、承認処理部は、課金が実行されたか否かに応じて公開設定要求を承認するか否かを判定することを特徴とする。
【００３３】
このように、承認処理部が課金が実行されたか否かに応じて公開設定要求を承認するか否かを判定することにより、公開設定の契約に基づいた適切な課金処理を行なうことができる。
【００３４】
（１４）また、本発明の映像録画装置において、公開設定課金処理部は、公開設定回数または公開設定サイズを示す情報を記憶すると共に、端末装置による公開設定に伴って増減する公開設定回数または公開設定サイズに基づいて課金を実行することを特徴とする。
【００３５】
このように、公開設定回数または公開設定サイズに基づいて課金を実行することにより、実際の視聴毎に管理できるので、正確な手数料（著作権利用料）を計算できる。
【００３６】
（１５）また、本発明の映像録画装置において、公開設定課金処理部は、公開設定回数または公開設定サイズの上限値または下限値を記憶すると共に、端末装置による公開設定に伴って増減する公開設定回数または公開設定サイズが、上限値または下限値を超える場合は、課金の実行を停止することを特徴とする。
【００３７】
このように、公開設定回数または公開設定サイズに上限値または下限値を設け、それに応じて課金停止をすることにより、公開に対する一定の制限がかかり、ユーザが想定しない公開をすることを防ぐことができる。
【００３８】
（１６）また、本発明の映像録画装置において、広告データを取得する広告情報通信部をさらに備え、番組データ配信部は、編集後の構成情報に基づいて、放送番組データの全部または一部を端末装置に配信する際に、取得した広告データを放送番組データの全部または一部に挿入することを特徴とする。
【００３９】
このように、放送番組データの全部または一部を端末装置に配信する際に、取得した広告データを放送番組データの全部または一部に挿入することにより、広告主にとってはＣＭが視聴されることで利益を受けるので、ユーザ端末のユーザにとって、映像録画装置の事業者への手数料が安く抑えられる可能性がある。
【００４０】
（１７）また、本発明の映像録画装置において、番組録画部は、録画した放送番組データに関連するキーワードを放送番組データと共にデータベースに格納し、広告情報通信部は、放送番組データに関連するキーワードを用いて広告データを取得することを特徴とする。
【００４１】
このように、放送番組データに関連するキーワードを用いて広告データを取得することにより、視聴者は放送番組の内容に関連する広告を見ることになるので、効果の高い広告を実現することができる。
【００４２】
（１８）本発明の端末装置は、上記（１）〜（１７）のいずれかに記載の映像録画装置から放送番組データを取得する。
【００４３】
このように、端末装置は映像録画装置と接続されていることにより、映像録画装置に対して録画予約をすることができる。さらに、端末装置から番組コンテンツの編集要求をすることにより、映像録画装置に対して構成管理データベースに格納された構成情報を編集することができる。また、端末装置から視聴要求をすることにより、編集後の構成情報と放送番組データの全部または一部を受信することができる。これにより、放送番組データのような容量の大きなデータを編集することなく、編集された放送番組をユーザが視聴することができる。
【００４４】
（１９）本発明の録画映像提供方法は、ネットワークに接続されている端末装置に対して録画映像を提供する録画映像提供方法であって、放送通信部において、放送番組データを取得するステップと、番組録画部において、取得した放送番組データをデータベースに格納するステップと、構成管理データベースに放送番組データを特定する情報および放送番組データの放送開始時刻から放送終了時刻までの間のいずれかの時間的範囲を示す情報を少なくとも含む構成情報を格納するステップと、承認処理部において、端末装置から構成管理データベースに格納されている構成情報を編集する編集要求があったときに、その編集要求を承認するか否かを判定するステップと、編集制御部において、判定の結果、編集要求が承認された場合、編集要求に従って、構成情報の編集を実行するステップと、番組データ配信部において、編集後の構成情報に基づいて、放送番組データの全部または一部を端末装置に配信するステップと、を少なくとも含むことを特徴とする。
【００４５】
このように、構成管理データベースに放送番組データを特定する情報および放送番組データの放送開始時刻から放送終了時刻までの間のいずれかの時間的範囲を示す情報を少なくとも含む構成情報を格納するので、ユーザの端末装置からの録画予約に応じて、番組の構成情報を含む録画予約レコードを構成管理データベースに格納することができる。さらに、承認処理部において、端末装置から構成管理データベースに格納されている構成情報を編集する編集要求があったときに、その編集要求を承認するか否かを判定するので、著作権に関わる人の間の契約に基づいて、ユーザの編集条件を制御することができる。編集制御部において、判定の結果、編集要求が承認された場合、編集要求に従って、構成情報の編集を実行するので、ユーザ端末装置から番組コンテンツの編集要求があれば、編集制御部が上記構成管理データバースに格納された構成情報を編集することができる。これにより、放送番組データのような容量の大きなデータを編集することなく、編集された放送番組をユーザが視聴することができる。
【００４６】
（２０）本発明の映像録画装置の制御プログラムは、ネットワークに接続されている端末装置に対して録画映像を提供する映像録画装置の制御プログラムであって、番組録画部において、放送番組データを取得し、取得した放送番組データをデータベースに格納する処理と、構成管理データベースに放送番組データを特定する情報および放送番組データの放送開始時刻から放送終了時刻までの間のいずれかの時間的範囲を示す情報を少なくとも含む構成情報を格納する処理と、承認処理部において、端末装置から構成管理データベースに格納されている構成情報を編集する編集要求があったときに、その編集要求を承認するか否かを判定する処理と、編集制御部において、判定の結果、編集要求が承認された場合、編集要求に従って、構成情報の編集を実行する処理と、番組データ配信部において、編集後の構成情報に基づいて、放送番組データの全部または一部を端末装置に配信する処理と、の一連の処理を、コンピュータに読み取り可能および実行可能にコマンド化したことを特徴とする。
【００４７】
このように、放送番組データを特定する情報および放送番組データの放送開始時刻から放送終了時刻までの間のいずれかの時間的範囲を示す情報を少なくとも含む構成情報を格納するので、ユーザの端末装置からの録画予約に応じて、番組の構成情報を含む録画予約レコードを構成管理データベースに格納することができる。さらに、構成情報の編集を実行するので、ユーザ端末装置から番組コンテンツの編集要求があれば、上記構成管理データバースに格納された構成情報を編集することができる。これにより、放送番組データのような容量の大きなデータを編集することなく、編集された放送番組をユーザが視聴することができる。
【発明の効果】
【００４８】
本発明によれば、ネットワーク上の録画装置において、効率的に録画コンテンツを管理し、編集することが可能となる。また、著作権者に関わる人の間で利益の分配を適切に行ないつつ、視聴者に録画済み番組の編集機能を提供することで、利便性を高めることができる。また、より柔軟な広告機能を提供することができる。
【図面の簡単な説明】
【００４９】
【図１】本発明の第１の実施形態に係る放送システムの概略構成を示すブロック図である。
【図２】本発明の第１の実施形態に係る映像録画装置の録画処理を示すフローチャートである。
【図３】録画された番組データの一部の例を示す図である。
【図４】本発明の第１の実施形態に係る映像録画装置の録画予約処理を示すフローチャートである。
【図５】２人のユーザＡとＢによって録画要求された場合の例を、模式的に表わす図である。
【図６】録画完了後の構成管理ＤＢ２５３に記録されたレコードの例を示す図である。
【図７】本発明の第１の実施形態に係る映像録画装置の編集処理を示すフローチャートである。
【図８】編集処理後の構成管理ＤＢ２５３に記録されたレコードの例を示す図である。
【図９】編集操作に関する契約条件ＤＢに記録されたレコードの例を示す図である。
【図１０】、ユーザＡが録画コンテンツ１０１−１を視聴した範囲の一例を示す図である。
【図１１】編集処理における承認処理部２０２の動作を示すフローチャートである。
【図１２】視聴履歴レコードの例を示す図である。
【図１３】本発明のおける視聴処理を示すフローチャートである。
【図１４】本発明の第２の実施形態に係る放送システムの概略構成を示すブロック図である。
【図１５】ユーザが編集した録画コンテンツを、第三者に公開することに関する条件をユーザ毎に表す公開条件レコードの例を模式的に示す図である。
【図１６】本発明の第２の実施形態において、公開録画コンテンツを検索して視聴する処理の流れを示すフローチャートである。
【図１７】広告サーバ４に対する広告データ取得リクエストの一例を示す図である。
【発明を実施するための形態】
【００５０】
（第１の実施形態）
図１は、本発明の第１の実施形態に係る放送システムの概略構成を示すブロック図である。本実施形態に係る放送システムは、図１に示すように、放送サーバ１、映像録画装置２およびユーザ端末３から構成される。
【００５１】
放送サーバ１は、放送番組データ（番組データ）を配信する。放送サーバ１の配信方法は、いわゆる地上波による配信、放送衛星による配信などの他、ＩＰネットワーク上でデジタルデータをマルチキャスト／ユニキャストで配信することもある。これらのような形態の放送サーバは、現時点でもすでに多数存在しているため、詳細な説明を省略する。なお、番組データは、典型的には、ＭＰＥＧ２（Motion Picture Expert Group）フォーマットや、Ｈ．２６４フォーマットで記述された動画像である。
【００５２】
映像録画装置２は、図１の破線内部の機能ブロックから構成される。映像録画装置２は、放送通信部２０１、承認処理部２０２、編集制御部２０３、録画制御部２０４、番組データ受信部２０５、番組データ配信部２０６およびＩＰ通信部２０７を備えている。さらに、ユーザ管理ＤＢ２５１、契約条件ＤＢ２５２、構成管理ＤＢ２５３、録画番組ＤＢ２５４を備えている。
【００５３】
映像録画装置２および各構成要素は、一般的なコンピュータシステムで実現され、ＣＰＵ（Central Processing Unit）、ＲＡＭ（Random Access Memory）、ＲＯＭ（Read Only Memory）、２次記憶装置、入出力装置、ディスプレイ、キーボード、およびそれらの制御プログラムなどから構成される。または、それらのコンピュータシステムを複合することにより構成することも可能である。
【００５４】
放送通信部２０１は、放送サーバ１から配信された番組データ（放送コンテンツ）を取得する。放送形態によって、アンテナ、ＩＰネットワーク端子や、チューナー、ＭＰＥＧ２デコーダ、Ｈ．２６４デコーダなどから構成される。
【００５５】
承認処理部２０２は、ユーザからの編集要求および後述する第２の実施形態における公開録画コンテンツ検索要求の際に、契約条件ＤＢ２５２を参照して、ユーザ操作を許可するかどうかを判定する。
【００５６】
編集制御部２０３は、承認処理部２０２によって許可されたユーザからの編集操作の要求を受けて、構成管理ＤＢ２５３および録画番組ＤＢ２５４に格納された録画コンテンツを編集する。例えば、ユーザ端末３から、ＨＴＴＰ（Hyper Text Transfer Protocol）によって編集要求を受け付ける場合は、編集制御部２０３は、ＨＴＴＰに対応したサーバプログラムとして実現されることになる。編集方法などについては後述する。
【００５７】
録画制御部２０４は、録画番組ＤＢ２５４に記録される番組データのＩＤを割り当てたり、ユーザ毎の録画要求に対し適切に処理して、構成管理ＤＢ２５３に記録、管理する。例えば、ユーザ端末３から、ＨＴＴＰによって録画要求を受け付ける場合は、編集制御部２０３は、ＨＴＴＰに対応したサーバプログラムとして実現されることになる。その制御方法について後述する。録画制御部２０４は、録画番組ＤＢ２５４に記録される番組データのＩＤを割り当てたり、ユーザ毎の録画要求に対し適切に処理して、構成管理ＤＢ２５３に記録、管理する。例えば、ユーザ端末３から、ＨＴＴＰによって録画要求を受け付ける場合は、編集制御部２０３は、ＨＴＴＰに対応したサーバプログラムとして実現されることになる。その制御方法について後述する。
【００５８】
番組データ受信部２０５は、放送通信部２０１で取得した番組データを、録画番組ＤＢ２５４に記録する。詳細な記録内容については後述する。
【００５９】
番組データ配信部２０６は、ユーザからの視聴要求に従い、録画番組ＤＢ２５４に記録された録画コンテンツを、ユーザ端末３に配信する。デジタルコンテンツの配信方法は、典型的にはＲＴＳＰ（Realtime Streaming Protocol）／ＲＴＰ（Realtime Transport Protocol）や、ＨＴＴＰを使って行なわれることが多いが、特にこれに制限されることはなく、配信を達成できるための任意の配信方法でよい。配信を実現するための技術は公知であるため、詳細な説明を省略する。
【００６０】
ＩＰ通信部２０７は、ユーザ端末３からの様々な要求を受け付けて、各構成要素に転送したり、デジタルデータの配信処理を行なう。ユーザ端末３とは典型的にはＩＰネットワークで接続されており（経路上のルータなどの存在は省略）、ＩＰネットワーク用の端子や、その制御チップ、プログラムで構成される。なお、放送通信部２０１と、ＩＰ通信部２０７がそれぞれ放送サーバ１と、ユーザ端末３とのやりとりのために接続するネットワークは、ここでは別ものであるとしているが、同一のものであってもよい。すなわち、映像録画装置２からのネットワーク経路上に共通のルータ機器が存在し、そのルータ機器から放送サーバ１、ユーザ端末３の両方に接続するような経路であっても良い。さらには、放送サーバ１から配信されるデジタルデータが、一旦ユーザ端末３まで届き、ユーザ端末３が映像録画装置２へ転送するような経路でも良い。
【００６１】
ユーザ管理ＤＢ２５１は、映像録画装置２が提供するサービスを利用するユーザを管理するためのＤＢである。ユーザ管理の技術は公知であるので、詳細な説明は省略する。また、本発明の映像編集サービスを利用するユーザは、公知のユーザ管理技術により、任意のタイミングで既に登録済みであると仮定する。
【００６２】
契約条件ＤＢ２５２は、編集操作の可否を判定するための根拠となるデータを格納する。詳細な内容は後述する。また、構成管理ＤＢ２５３は、録画番組ＤＢ２５４に記録された録画コンテンツに対して、ユーザ毎の構成情報を管理するためのＤＢである。構成情報とは、録画番組ＤＢ２５４に格納された番組データの全部または一部を表すためのメタ情報である。詳細な内容は後述する。また、録画番組ＤＢ２５４は、放送通信部２０１で取得された番組データを格納する。格納方法については後述する。
【００６３】
ユーザ管理ＤＢ２５１、契約条件ＤＢ２５２、構成管理ＤＢ２５３、録画番組ＤＢ２５４は、典型的には固定ディスクなどの記憶装置や、管理するためのＤＢＭＳ（Database Management System）で構成される。
【００６４】
ユーザ端末３は、映像録画装置２に録画要求、編集要求、検索要求、配信要求を行なったり、配信された番組データをモニタ、スピーカーなどで再生することができる。ユーザ端末３の各要求操作に対するユーザインターフェースとしては、既に普及しているＤＶＤレコーダや、ＨＴＭＬ（Hypertext Markup Language）ブラウザ上でのユーザインターフェースなどを利用すればよく、公知であるので、詳細な説明を省略する。ユーザ端末３は、典型的にはユーザ毎に用意され、複数存在するが、本実施の形態の説明では区別なく扱う。
【００６５】
＜録画処理＞
図２は、本発明の第１の実施形態に係る映像録画装置２の録画処理を示すフローチャートである。ここでは、図１の例を用いて説明する。映像録画装置２は、チャンネルサーチを行なうか、マニュアルで設定するなどして予め設定されたチャンネル毎に、録画制御部２０４で、時間毎（２４時間単位であれば日付など）に番組データを記録する単位を特定するためのＩＤを割り当てる（ステップＳ１０１）。例えば、２００９年３月１日の、放送局Ａ−ＢＣの番組データに対して、ファイルＩＤ＝１０１を割り当て、ファイル名として、「2009/03/02/101.mpg」を対応づける。
【００６６】
次に、番組データ受信部２０５にて、録画を実施し、具体的には上述のファイル名に対して放送通信部２０１で取得した番組データを、録画番組ＤＢ２５４に順次記録していく（ステップＳ１０２）。この録画処理は、全てのチャンネルについて並列に行ない（ステップＳ１０３）、日が経過（業界では午前４：００を日の区切りとすることが多い）する際に、新しいＩＤを割り当て直して、録画実施を繰り返す（ステップＳ１０４）。これらの処理の結果、映像録画装置２で管理されているチャンネルの番組を常に録画し続けることになる。
【００６７】
図３は、録画された番組データの一部の例を示す図である。上記処理により、図３に示すようなファイルおよびＤＢレコードが番組データＤＢ２５４に記録されることとなる。ファイルＩＤ＝１０１の録画コンテンツ（録画コンテンツ１０１）は、２００９年３月１日午前４：００から、２００９年３月２日午前４：００（の直前と解釈しても良い）の間のＡ−ＢＣ放送局によって放送された番組データが、「2009/03/02/101.mpg」というファイル名で記録されていることを示す。ファイルＩＤ＝１０２の録画コンテンツは、同時間の、Ｎ−ＴＶ放送局によって放送された番組データに対するレコードである。ここで時刻は、日本時間などの地域ローカルタイムを基準にして良いが、特にこれにこだわらず、世界標準時などを基準にしても良い。また、基準時刻が異なる複数国の番組を録画する場合は、基準時刻はそれぞれのコンテンツで異なったものになると考えられるので、より適切に時間の区切りを設定すればよい。
【００６８】
＜録画予約処理＞
図４は、本発明の第１の実施形態に係る映像録画装置の録画予約処理を示すフローチャートである。ここでは、図１の例を用いて説明する。まず、ユーザ端末３から、録画要求を発行し、ＩＰ通信部２０７を経由して、録画制御部２０４が録画要求を受け付ける（ステップＳ２０１）。もし、対応する録画番組が、図２におけるステップＳ１０１〜Ｓ１０４での録画処理にて録画されたら、録画制御部２０４は録画確認を行なう（ステップＳ２０２）。次に、録画制御部２０４は、要求元ユーザＩＤと関連づけて、録画コンテンツに関するレコードを作成し、構成管理ＤＢ２５３に格納する（ステップＳ２０３）。ここで、ユーザＩＤと関連付けられた録画コンテンツに関するレコードを録画予約レコードと表す。
【００６９】
図５は、２人のユーザＡとＢによって録画要求された場合の例を、模式的に表わす図である。図５では、番組データ５０１は録画番組ＤＢ２５４に記録され、録画要求範囲５０２、５０３はそれぞれユーザＡ、ユーザＢによって要求された範囲を示す。
【００７０】
図６は、録画完了後の構成管理ＤＢ２５３に記録されたレコードの例を示す図である。録画ＩＤ１０１−１、１０１−２は、それぞれユーザＡ、ユーザＢに対するレコードであり、１９:００〜２０：００、１９：３０〜２０：３０という時間範囲を持つ。番組データの実体は、いずれもファイルＩＤ＝１０１の番組データであり、複数のユーザに対し、効率的に番組データの格納を行なうことができている。
【００７１】
ここで、録画要求の対象番組は、未来に存在する場合がほとんどであるため、ステップＳ２０１時点では、予約情報として管理し、内部のタイマー制御などによって、後日ステップＳ２０２〜Ｓ２０３の処理を行なうことになるが、これらの処理は既に公知であるので詳細な説明はしない。逆に、上述のような構成となっているので、過去に存在する番組に対して録画要求を出すこともできる。例えば、放送されてから１週間は番組データを録画番組ＤＢ２５４から削除しなければ、この期間の間は、遡って録画要求を発行することができるので、見逃し視聴などのサービスも簡単に実現することができる。
【００７２】
＜編集処理＞
図７は、本発明の第１の実施形態に係る映像録画装置の編集処理を示すフローチャートである。ここで“編集”とは、録画コンテンツの動画像に対し、特定の範囲に対して、削除、削除解除、ホワイトバランス補正、トリミング、フェードアウト、フェードイン、などの映像編集処理のことを言う。ここでは、図１および図６の例を用いて説明する。まず、ユーザ端末３が編集要求を発行し、編集制御部２０３は、編集要求を受け付ける（ステップＳ３０１）。例えば、編集要求としては、「ユーザＡの録画コンテンツ１０１−１（録画ＩＤ＝１０１−１のコンテンツ）に対して、１９：２９〜１９：３０の範囲を削除する」という内容だったと仮定する。
【００７３】
次に、編集制御部２０３は、承認処理部２０２に編集操作の可否を問い合わせる（ステップＳ３０２）。承認処理部２０２は、後述の処理によってＯＫ、または、ＮＧの回答を行ない、ＮＧであれば何も編集操作を実行せずにエラーをユーザ端末３に返す。承認処理部２０２がＯＫを回答すれば、録画コンテンツ１０１−１に関係するレコード（図６の録画ＩＤ＝１０１−１のレコード）を構成管理ＤＢ２５３より取得する（ステップＳ３０３）。ＳＴＡＲＴ＝１９：００、ＥＮＤ＝２０：００となっているので、上記編集要求の場合、１９：００〜１９：２９と、１９：３０〜２０：００の２つのレコードに分割することになる（ステップＳ３０４）。
【００７４】
図８は、編集処理後の構成管理ＤＢ２５３に記録されたレコードの例を示す図である。図８では、上記編集要求に加え、さらに１９：４４〜１９：４５の範囲も削除している。ここで、図６に示されたＳＥＱ＝０の値を持つレコードは図８には示さなかったが、実際にＳＥＱ＝０のレコードを削除しても良いし、残しておいても良い。残した場合には、ＳＥＱ＝０か０以外かによって、全体を表す場合と、一部を表す場合とを区別することができる。なお、ステップＳ３０２で、承認処理部２０２は、編集操作の可否を判定するが、それは次のようにして行なう。
【００７５】
図９は、編集操作に関する契約条件ＤＢに記録されたレコードの例を示す図である。ここで、「編集契約」は、どのような種類の編集が契約によって許可されているかを示す。視聴範囲編集は、一度視聴した範囲ならば編集することが可能であることを示し、編集するためには少なくとも一度は視聴する必要がある。自由範囲編集は、一度も視聴していなくとも自由に編集することが可能であることを示す。特定期間後は、録画後すぐは編集できないが、例えば、１週間、１月、１年などの期間が経過すれば、自由に編集しても良いことを示す。
【００７６】
「編集課金種類」は、課金される場合、どのような方法で課金されるかを示す。定額は、例えば月額いくら、というふうに１月あたりの決まった手数料を支払う方式である。編集毎、および、従量制は、編集の回数または量（サイズ）に応じて課金する方式で、ここでは、決まった上限を設定し、その範囲内で編集可能にする場合と、上限は決めずに、ある期日により編集回数、量を測定して、それに応じて課金金額を決める方式の２種類があると想定している。例えば、ユーザＢの場合は、月内（あるいは、年内、無期限）にあと５回編集操作が可能であり、編集操作を行なうと、（残）編集回数の値が減っていくことを示し、ユーザＤの場合は、月内（あるいは、年内、その他の期間内）に、すでに１０回編集操作が行なわれており、編集操作を行なう毎に（残）編集回数の値は増えていくことを示す。
【００７７】
なお、図９のレコードについては、ユーザと映像録画装置２の事業者との間で契約が締結され、それに基づき予め設定されているものとする。データベースに対してレコードを記録するのは一般的なことであり、詳細な説明は省略する。
【００７８】
図１０は、ユーザＡが録画コンテンツ１０１−１を視聴した範囲の一例を示す図である。録画コンテンツ１０１−１全体６０１に対し、矢印部分が、ユーザＡが視聴した範囲６０２である（途中、スキップまたは早送りが行なわれた）。また、ユーザＡが削除編集したい部分の候補６１１、６１２、６１３は、塗りつぶし部分で示す。
【００７９】
図１１は、編集処理における承認処理部２０２の動作を示すフローチャートである。ここでは、図１、図３、図９、図１０の例を用いて説明する。以下の処理は、全て承認処理部２０２で行なわれる。まず、ユーザＡの編集条件レコードを取得する（ステップＳ４０１）。次に、編集契約の種類を判定し、「視聴範囲編集」「自由範囲編集」「特定期間後」であった場合にはそれぞれ、ステップＳ４０３、ステップＳ４０４、ステップＳ４０５へ進み、契約がない場合にはＮＧ判定となる（ステップＳ４０２）。
【００８０】
「視聴範囲編集」では、まず視聴済み範囲かどうかが判定される（ステップＳ４０３）。視聴済み範囲かどうかを判定するため、番組データ配信部２０６において後述の視聴処理を行なう際、視聴履歴レコードを作成する。
【００８１】
図１２は、視聴履歴レコードの例を示す図である。例えば、ＳＥＱ＝１のレコードは、ユーザＡが録画コンテンツ１０１−１を視聴する際、１９：００〜１９：４０の範囲を視聴済みであることを示す。視聴履歴レコードは、ユーザ管理ＤＢ２５１に記録すれば良いが、構成管理ＤＢ２５３や、その他の図示しないＤＢに格納しても良い。さて、編集対象が、ユーザＡが削除編集したい部分の候補６１１、６１３に対応する範囲であれば、この範囲は視聴済みであることが分かるのでＯＫとし、Ｓ４０４へ進むが、ユーザＡが削除編集したい部分の候補６１２に対応する範囲であれば、視聴済みでないのでＮＧとなる。
【００８２】
この方法では、例えば、ＣＭをカットしたい場合は、少なくとも一度はＣＭを視聴する必要があるため、広告主の目的を少なくとも部分的に達成することができる。このようにＣＭカット操作を許可したとしても、広告主にとって著しく不利益になることはないので、ユーザが支払う手数料を低く抑えることが可能となる。さらに、ネットワークの双方向性を利用し、ＣＭの場所に他メディアによる広告へのリンクを埋め込んでおき、ユーザが少なくとも一度は広告へのリンク先にアクセスしなければ編集できないようにしていてもよい。映像録画装置２の少なくとも関連する事業者が広告サーバを運用して上記リンクを捕捉できるようにしておけば、図１２に相当するレコードを作成するのは容易である。これによると、必ず広告を見ることになるので、広告主にとって大きな利益となる。
【００８３】
次に、課金状況が確認される（ステップＳ４０４）。図９において、ユーザＡの場合には、定額であるのでＯＫとなる。もし、編集毎であった場合には、（残）編集回数を減じ（０のときはＮＧ）、もし、従量制であった場合には、（残）編集回数を増加しＯＫとなる（ステップＳ４０６）。
【００８４】
「自由範囲編集」の場合は、直接Ｓ４０４へ進み、ステップＳ４０６の処理を実行する。
【００８５】
「特定期間後」の場合は、まず、期間を判定する（ステップＳ４０５）。図３により、録画コンテンツ１０１−１の録画日時は、２００９年３月１日４：００なので、「特定期間」を1週間とする場合は、Ｓ４０５の処理を行なう日時が、３月８日４：００以降であればＯＫとなる。特定期間が１月や、その他の期間でも同様の処理となる。また、時間については、常に４：００を基準とするなどの方法でも良い（ユーザには、日だけで判定できるので分かり易い）。その後の課金処理は、Ｓ４０４に進むので同様となる。
【００８６】
この方法では、特定期間が経過するまでは、ＣＭがカットされることはないため、広告主にとって大きな不利益になることはない。特定期間が経過した後はＣＭカットできるようになるため、長期間保存しておきたい録画コンテンツの整理ができ、ユーザにとって利益となる。
【００８７】
なお、図９では、これらの編集契約は、ユーザ毎に１つとしたが、放送局毎や、時間帯毎などとしてもよい。また、上述の３種類だけでなく、サイズによる制約があってもよい（比較的短いコンテンツである場合は編集可能など）。
【００８８】
ここで、編集処理の例として、削除処理を扱ったが、これに限定するものではない。本発明の映像録画装置２は、構成管理ＤＢ２５３による管理を行なっているので、一度削除した範囲を取り消し、削除を解除することができる。その他の、ホワイトバランス補正、トリミング、フェードアウト、フェードインについても、図８に、それらの編集内容を記述するデータを追加し、番組データ配信部２０６が配信処理をする際に、データの内容を記述されたデータに従って修正して配信すればよい。例えば、１９：００〜１９：０１の範囲を、フェードインという属性をつけたレコードを構成管理ＤＢ２５３に記録しておき、配信時には、その範囲についてフェードイン処理をリアルタイムで行なって配信すればよい。もっとも、リアルタイムで行なうには負荷の高い処理の場合には、予め処理済みのデータを作っておく（そのための管理レコードも必要になる）ことも有効である。
【００８９】
なお、上述の編集操作では、対象の範囲（開始時刻〜終了時刻）を指定する必要があるが、その時に、他のユーザの編集範囲を、編集対象候補としてユーザ端末３に提案することもできる。例えば、図８の例では、ユーザＡが録画コンテンツ１０１−１を編集しているとき、同じファイルＩＤでＳＴＡＲＴ〜ＥＮＤの範囲が重なるユーザＢのレコードにおいて、「１９：４４〜１９：４５」「１９：５９〜２０：００」の範囲が編集によってカットされていることが分かるので、それらの範囲を、編集候補としてユーザＡのユーザ端末３に提案することもできる。
【００９０】
なお、上述の編集操作は、サイズの大きな番組データそのものの編集を行なうのでなく、その構成を管理するレコードだけを修正するので、非常に高速に行なうことができる。
【００９１】
＜録画コンテンツの視聴処理＞
図１３は、録画コンテンツの視聴処理を示すフローチャートである。ここでは、図１および図８の例用いて説明する。なお、録画コンテンツリストの記述、視聴要求の記述や、ＵＩ表示については、従来のネットワーク型ビデオオンデマンドシステムなどで公知であるので詳細な説明はしない。まず、ユーザ端末３は、録画コンテンツリスト要求を発行する。録画制御部２０４は、リスト要求を受け付け、ユーザの判定を行ない、対応する録画コンテンツのリストを作成してユーザ端末３に応答する（ステップＳ５０１）。対応する録画コンテンツは、図８等で示されるレコードの内、録画ＩＤとＳＥＱで特定されるものを検索すればよい。
【００９２】
次に、ユーザ端末３はそのうちの特定のコンテンツを選択して視聴要求を発行する。録画制御部２０４は、視聴要求を受け付ける（ステップＳ５０２）。この処理でのプロトコルは、ＳＤＰや、ＲＴＳＰ／ＲＴＰなど公知の技術があり説明を省略する。但し、ＲＴＰで送信する録画コンテンツの番組データについてはステップＳ５０３〜Ｓ５０５の流れで処理される。次に、指定された特定の録画コンテンツに対応するレコード集合を構成管理ＤＢ２５３から取得する（ステップＳ５０３）。録画コンテンツ１０１−１が指定されたとすると、図８で示されるＳＥＱ＝１〜３のレコードが取得される。
【００９３】
続いて、対応するレコードをＳＥＱ順（トリックプレイの場合には対応するＳＥＱから）に取得し、その範囲の録画データを録画番組ＤＢ２５４から取得してユーザ端末３に送信する（ステップＳ５０４〜Ｓ５０５）。図８の例では、１９：００〜１９：２９、１９：３０〜１９：４４、１９：４５〜１９：５６の範囲に対応する録画データを順に送信することになる。なお、ここでＭＰＥＧ２の内部に埋め込まれているＰＣＲ（Program Clock Reference）など、連続性のあるデータについては、適切に処理されるものとする。ステップＳ５０４〜Ｓ５０５にて、視聴済みかどうかを判定するため、図１２に示されるような視聴履歴を作成してもよい。
【００９４】
（第２の実施形態）
第１の実施形態では、録画コンテンツに対し、ユーザの要求により編集する例を説明した。第２の実施形態では、編集された番組データだけでなく、広告サーバからの広告データを統合して扱う例、および、編集されたコンテンツを第三者に公開する例を示す。
【００９５】
図１４は、本発明の第２の実施形態に係る放送システムの概略構成をを示すブロック図である。図１における第１の実施形態との違いは、映像録画装置１２の構成に変更があることと、広告サーバ４が追加されたことである。映像録画装置１２は、構成要素として、ほとんど映像録画装置２と同様なものを含むが、広告情報通信部１２０７を含むところと、番組データ配信部１２０６と契約条件ＤＢ１２５２の機能が異なる。また、ユーザ端末３，３’，３”は、本実施形態では、第１の実施形態と異なり、区別して扱う。ここで、ユーザ端末３のユーザは第１の実施形態において映像録画装置２の事業者と契約をしている者とし、ユーザ端末３’、３”のユーザは第三者とする。
【００９６】
番組データ配信部１２０６は、番組データ配信部２０６と同様にユーザ端末に対して、録画コンテンツの番組データを配信するが、広告情報通信部１２０７によって取得された広告データを、番組データに挿入して配信するところが異なる。詳細な手順については後述する。広告情報通信部１２０７は、広告データを広告サーバ４から取得し、保持する。番組データ配信部１２０６からの要求に従って、相応しい広告データを返し、ユーザ端末３および第三者のユーザ端末（以下、ユーザ端末３’等）によって、適切に広告が視聴されるようにする。
【００９７】
なお、実装としては、典型的には一般的なコンピュータシステムで実現され、広告データを格納するための外部記憶装置があってもよい。また、広告データの取得タイミングとしては、番組データ配信部１２０６からの要求があってから、広告サーバ４から取得しても良いし、予め広告サーバ４から配信の可能性のある広告データを予め取得しておき、データベースに格納しておいても良い。
【００９８】
契約条件ＤＢ１２５２は、契約条件ＤＢ２５２と同様にユーザ毎の契約条件を記録するが、第三者への公開に関する契約条件をも含むところが異なる。内容の詳細については後述する。なお、契約条件を記録するための処理については、一般的なデータベースへの登録処理であり、公知であるので詳細な説明を省略する。
【００９９】
広告サーバ４は、広告データを映像録画装置１２に提供する。広告は通常、番組内容を知った上で効果があると判断した広告主が出すので、広告データを単に出すだけでなく、挿入される番組に対する条件（あるいは、特定の番組を指定）も合わせて提示されることが想定される。実装としては、単なるデータを提供するサーバであり、一般的なコンピュータシステムで実装されるので、詳細な説明を省略する。
【０１００】
図１５は、ユーザが編集した録画コンテンツを、第三者に公開することに関する条件をユーザ毎に表す公開条件レコードの例を模式的に示す図である。「公開契約」とは、どのような条件で公開が許可されるかを示す。視聴後公開は、ユーザが録画コンテンツを視聴した後、第三者への公開が許可されうることを示す。無制限公開は、ユーザが視聴していなくても許可されうることを示す。特定期間後公開は、特定の期間（１週間、１月、１年など）が経過すれば許可されうることを示す。ＣＭ公開は、公開された場合に、ユーザが編集（典型的にはＣＭカット）した部分に、広告サーバ４から取得されたＣＭデータが挿入されるような形態で許可されうることを示す。広告主にとってはＣＭが視聴されることで利益を受けるので、ユーザ端末３のユーザにとって、映像録画装置１２の事業者への手数料が安く抑えられる可能性がある。ユーザＧのように「公開契約」が設定されていない場合は、公開が許可されるような契約が締結されていないことを示す。
【０１０１】
「公開課金種類」とは、課金の種類を表す。定額は、月額いくらなど、公開される録画コンテンツ数、量に関わらず一定の手数料を支払う形態の契約である。課金処理が煩雑にならないというメリットがある。従量制は、公開後、第三者ユーザが視聴する回数、量をカウントしておき、月末などの期日にとりまとめて手数料を決定する方式である。実際の視聴毎に管理できるので、正確な手数料（著作権利用料）を計算できるメリットがある。公開毎は、ユーザの操作によって、特定の録画コンテンツを公開に設定し、その設定操作毎に課金する方式である。コンテンツ毎に課金できるので、ある程度著作権者の意向を手数料に反映でき（録画コンテンツによって料金が異なるなど）、課金処理も比較的容易である。このときユーザの設定操作に関しては一般的な技術であるので詳細な説明を省略する。なお、従量制、公開毎ともに、上限を設定し、上限を超えそうになったら、公開を停止する、または、公開設定操作を禁止するなどの方式を組み合わせることも可能である。そして手数料から、予め締結された契約に基づく著作権利用料が、映像録画装置１２の事業者から著作権者に支払われることになる。
【０１０２】
図８の、「公開Ｆ」は、該当する録画コンテンツが、第三者に対して公開されているかどうかを示す。公開ＦをＹｅｓに変更する処理は、例えば、ユーザ端末３からの操作によって行なわれる。操作の詳細は一般的であり説明を省略するが、定額の契約の場合は課金による制限はなく、従量制の場合は図１５の「（残）公開回数」が正であることを条件とし、公開毎の場合は「（残）公開回数」が正であることを条件として設定される。公開契約がないときは公開Ｆを変更することは出来ない。以降、図１５のようなレコードが契約条件ＤＢ１２５２に予め記録されているものとして説明する。
【０１０３】
＜検索視聴処理＞
図１６は、本発明の第２の実施形態において、公開録画コンテンツを検索して視聴する処理の流れを示すフローチャートである。ここでは、図８、図１４、図１５の例で説明する。まず、番組データ配信部１２０６において、図１３のＳ５０１と同様に、ユーザ端末３’等から受け付けた録画リスト取得要求に対し、ユーザに関連する録画リストを返却する（ステップＳ６０１）。次に、ユーザ端末３’等から検索視聴要求を受け付ける（ステップＳ６０２）。
【０１０４】
この時、特定の録画コンテンツに関連するものとして要求され、図８において、録画コンテンツ１０１−１が指定されていれば、ファイルＩＤが一致し、ＳＴＡＲＴ〜ＥＮＤで表される範囲に重なりがあるようなコンテンツが検索される（ステップＳ６０３）。但し、図８の公開ＦがＹｅｓに設定されているものだけが検索対象となる。例えば、図８では、ユーザＢの録画コンテンツ１０１−２が、検索結果の１つとなる。これにより、検索された録画コンテンツのリストが返却される（ステップＳ６０４）。
【０１０５】
次に、ユーザ端末３’等は、検索された録画コンテンツのリストから、録画コンテンツ１０１−２を選択し、視聴要求を発行する。番組データ配信部１２０６は、その視聴要求を受け付け（ステップＳ６０５）、対応するレコード集合を取得する（ステップＳ６０６）。図８の例ではＳＥＱ＝１〜３の３つのレコードが取得される。なお、この時、１０１−２の所有者であるユーザＢの契約条件は、図１５に示すとおり従量制であるとすると、今回の公開によって、課金されるユーザであるユーザＢの「（残）公開回数」を増加（上限のある回数券のようなタイプであれば減少させる処理でも良い）させる必要がある。また、上限に達した場合には、ユーザＢの録画コンテンツの「公開Ｆ」をＮｏに設定し、これ以上第三者に視聴されることがないようにする必要がある（公開Ｆでなく、他のテーブルなどで公開許可を管理してもよい）。取得された対応レコードを順に１つ取り出し、その範囲の録画データを送信する（ステップＳ６０７）。この際、契約条件によっては、ＣＭデータを取得し、送信する（ステップＳ６０８）。取得された対応レコードに後続があればＳ６０７に戻り、後続がなければ検索視聴処理が完了する（ステップＳ６０９）。ステップＳ６０７〜Ｓ６０９の繰り返しにより、検索された録画データを視聴することができる。
【０１０６】
上記のように、録画データの１つを送信する毎に、公開契約の内容（ＣＭ公開）によっては、録画コンテンツとは別に、広告情報通信部１２０７によって取得された広告データを、挿入して送信することもできる。そのようにすることで、特に、ユーザ端末３’等では、有用なダイジェストデータ（例えば、野球中継のハイライトシーンだけにしたダイジェストなど）のような録画データを見ることができると同時に、著作権者、あるいは、放送局にとっては特に最新の広告を提供こともできるため、双方にとって利便性が高い。そのような場合には、ユーザ端末３を所有するユーザの公開契約のために支払う手数料を安く抑えられる可能性がある。
【０１０７】
また、Ｓ６０８にて、広告主は通常、広告を提供する際の放送コンテンツの内容を選ぶので、録画コンテンツの内容に応じて挿入する広告データを切り替えられるのが望ましい。例えば、録画された日時と放送局が分かればどの番組か特定できるので、それを用いて広告データを取得（広告サーバ側で適切なものを返す）してもよい。また、番組データ受信部２０５が放送データを受信する際に、ＥＰＧ（Electronic Program Guide）に含まれたキーワードを同時に取得しておき、録画番組ＤＢ２５４などに関連づけて記憶しておくと、そのキーワードを指定して広告取得すればよい。
【０１０８】
図１７は、広告サーバ４に対する広告データ取得リクエストの一例を示す図である。ｂａｓｅｂａｌｌ，ｃａｍｐなどの狭義のキーワードに加え、日時なども指定しており、広告サーバ側では、これらすべてを広義のキーワードとして扱って検索するようにすればよい。もっとも、予め広告サーバ４から広告データを取得しておく場合には、キーワード情報なども同時に取得しておけばよい。なお、Ｓ６０７とＳ６０８の順序は逆でも良い。
【０１０９】
＜第２の実施形態の変形例＞
図１６のステップＳ６０２〜Ｓ６０３では、返却された録画リストのうち特定の録画コンテンツを選択し、それに関連する公開可能コンテンツを検索するとしたが、本発明は、それに限定されず、例えば放送局（または、映像録画装置１２の事業者）が提供する録画コンテンツが検索結果のリストにあってもよい。例えば、放送局が野球中継のハイライトシーンだけで構成されたダイジェストデータを含めておけば、ＣＭ公開の契約の場合と同じように動作させることで、最新のＣＭを提供しつつ、より多くのユーザに視聴してもらえるので、非常に広告効果の高いコンテンツ提供を行なうことができることになる。
【０１１０】
なお、上述では、広告サーバ４からの広告データを統合して扱うことと、編集されたコンテンツを第三者に公開することの両方を同時に用いる例としたが、それに限らない。第三者に公開する機能がなくても、ハイライトシーンダイジェストを作る場合には、広告データを自動挿入するような場合でも手数料を抑えた編集契約を実施できるし、同じくハイライトシーン提供事業者などの事業を考慮すると、広告データの自動挿入機能がなくても、第三者への公開を行なうことができる公開契約を定義しても構わない。
【符号の説明】
【０１１１】
１ 放送サーバ
２、１２ 映像録画装置
３、３’、３” ユーザ端末
４ 広告サーバ
２０１ 放送通信部
２０２ 承認処理部
２０３ 編集制御部
２０４ 録画制御部
２０５ 番組データ受信部
２０６、１２０６ 番組データ配信部
２０７ ＩＰ通信部
２５１ ユーザ管理ＤＢ
２５２、１２５２ 契約条件ＤＢ
２５３ 構成管理ＤＢ
２５４ 録画番組ＤＢ
１２０７ 広告情報通信部
【技術分野】
【０００１】
本発明は、視聴者から録画要求された放送番組を取得して視聴者に代行して録画し、配信サービスを行なう映像録画装置に関し、特に、関係者との契約に基づき、録画済み番組を編集し、編集済みの録画番組を視聴者に配信する映像録画装置、端末装置、録画映像提供方法、映像録画装置の制御プログラムに関する。
【背景技術】
【０００２】
従来から、インターネットなどのグローバルネットワークの高速化に伴い、ＩＰ（Internet Protocol）ネットワーク上でテレビジョン番組の動画像配信が行なえるシステムが登場しつつある。また、配信のみならず、その配信済みもしくは未配信の動画像を、ネットワーク上のストレージに記録することで、視聴者に代わって録画を行なうシステムが存在する。例えば、特許文献１にて開示された技術では、複数の端末から録画要求を受け付け、録画対象の放送番組を録画し、各端末からの再生要求に応えてストリーミング再生するシステムが提案されている。このシステムでは、複数の端末から同一の番組の録画を要求された場合には、唯一のデータをストレージ上に記録し、各端末へはその共通のデータを、それぞれの各端末へ配信することで、効率的なストレージの利用を実現している。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２００４−１９４２５５号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
しかしながら、特許文献１では、視聴者の当然の欲求である、録画済みデータに対する編集（ＣＭ（Commercial Message）カットなど）を可能とする技術は提供されておらず、視聴者が繰り返し視聴したいお気に入りの番組も、毎回、ＣＭを見るか、あるいは、スキップ操作をすることが必要で、煩わしかった。
【０００５】
また、録画データは放送局から直接受け取るため、受信者毎の要望に合った番組を提供する処理がない。このため、全ての受信者が同じコンテンツを見ることしかできない。ユーザは、繰り返し見るようなコンテンツの場合、ＣＭを何度も見なければならず、よりユーザフレンドリーな技術が望まれていた。
【０００６】
ここで、ＣＭカットなどの編集操作ができるようにする場合問題となるのが、放送番組の著作権の問題である。放送番組は著作物であり、著作権者に無断で自由に編集ができることとすると、著作権上の問題が発生する可能性がある。著作権者と編集許諾契約を結び、著作権利用料を著作権者に払った場合には、著作物を自由に編集することが可能となるが、一般のユーザが全ての編集操作に対して著作権利用料の全額を負担するのは割に合わず、編集操作を諦めてしまうことにつながる可能性がある。このような放送番組の編集についての著作権に関する利害関係をどのように調整するのかが問題となる。
【０００７】
本発明は、このような事情に鑑みてなされたものであり、ネットワーク上の録画装置において効率的に録画コンテンツを管理、編集できるようにし、著作権に関わる人の間での利益の分配を適切に行ないつつ、視聴者に録画済み番組の編集機能を提供すると共に、より柔軟な広告機能を提供する映像録画装置、端末装置、録画映像提供方法、映像録画装置の制御プログラムを提供することを目的とする。
【課題を解決するための手段】
【０００８】
（１）上記の目的を達成するために、本発明は、以下のような手段を講じた。すなわち、本発明の映像録画装置は、ネットワークに接続されている端末装置に対して録画映像を提供する映像録画装置であって、放送番組データを取得し、取得した放送番組データをデータベースに格納する番組録画部と、放送番組データを特定する情報および放送番組データの放送開始時刻から放送終了時刻までの間のいずれかの時間的範囲を示す情報を少なくとも含む構成情報を格納する構成管理データベースと、端末装置から構成管理データベースに格納されている構成情報を編集する編集要求があったときに、編集要求に従って、構成情報の編集を実行する編集制御部と、編集後の構成情報に基づいて、放送番組データの全部または一部を端末装置に配信する番組データ配信部と、を備えることを特徴とする。
【０００９】
このように、本発明は、放送番組データを特定する情報および放送番組データの放送開始時刻から放送終了時刻までの間のいずれかの時間的範囲を示す情報を少なくとも含む構成情報を格納するので、ユーザの端末装置からの録画予約に応じて、番組の構成情報を含む録画予約レコードを構成管理データベースに格納することができる。さらに、構成情報の編集を実行するので、ユーザ端末装置から番組コンテンツの編集要求があれば、編集制御部が上記構成管理データバースに格納された構成情報を編集することができる。これにより、放送番組データのような容量の大きなデータを編集することなく、編集された放送番組をユーザが視聴することができる。
【００１０】
（２）また、本発明の映像記録装置において、端末装置から構成管理データベースに格納されている構成情報を編集する編集要求があったときに、その編集要求を承認するか否かを判定する承認処理部と、編集要求を承認するための編集条件を示す情報を格納する編集条件データベースと、をさらに備え、承認処理部は、編集条件データベースに格納されている編集条件に基づいて、編集要求を承認するか否かを判定し、編集制御部は、判定の結果、編集要求が承認された場合、編集要求に従って、構成情報の編集を実行することを特徴とする。
【００１１】
このように、編集要求を承認するか否かを判定する承認処理部と編集条件を示す情報を格納する編集条件データベースを備えるので、ユーザの編集要求を編集条件データベースに格納することができ、承認処理部はこれに基づき編集要求を承認するか否かを判定することができる。これにより、著作権に関わる人の間の契約に基づいて、ユーザの編集条件を制御することができる。編集制御部は、判定の結果、編集要求が承認された場合、編集要求に従って、構成情報の編集を実行するので、ユーザの要求に従って、放送番組を編集することができる。
【００１２】
（３）また、本発明の映像記録装置において、番組データ配信部は、視聴範囲として、配信した放送番組データを示す情報を記憶する視聴範囲記憶部を備え、編集要求の対象となった放送番組データの全部または一部が、視聴範囲に含まれることを編集条件とする。
【００１３】
このように、視聴範囲記憶部を備えることにより、承認処理部が編集条件に基づいて編集要求を承認するか否かを判定する際に、ユーザが、その編集するコンテンツを視聴したかどうかを判断基準とすることができる（後述の「視聴範囲編集」に相当）。
【００１４】
（４）また、本発明の映像記録装置において、編集要求の対象となった放送番組データの全部または一部が録画された時刻から、予め定められた時間が経過することを編集条件とする。
【００１５】
このように、予め定められた時間が経過することを編集条件とすることにより、特定期間が経過するまでは、ＣＭがカットされることはないため、広告主にとって大きな不利益になることはない。また、特定時間が経過した後はＣＭカットができるようになるため、長期間保存しておきたい録画コンテンツの整理ができ、ユーザにとって利益となる（後述の「特定期間後」に相当）。
【００１６】
（５）また、本発明の映像録画装置において、構成情報の編集に対する課金を実行すると共に、課金に関する情報を記憶する課金処理部をさらに備え、承認処理部は、課金が実行されたか否かに応じて編集要求を承認するか否かを判定することを特徴とする。
【００１７】
このように、承認処理部が契約に基づく編集条件の可否を判定すると共に、それに応じて課金されたか否かを判定することにより、契約に応じた適切な課金処理を実現できる。
【００１８】
（６）また、本発明の映像録画装置において、課金処理部は、編集回数または編集サイズを示す情報を記憶すると共に、端末装置による編集に伴って増減する編集回数または編集サイズに基づいて課金を実行することを特徴とする。
【００１９】
このように、編集回数または編集サイズに基づいて課金することにより、契約に基づいた適切な課金をすることができる。
【００２０】
（７）また、本発明の映像録画装置において、課金処理部は、編集回数または編集サイズの上限値または下限値を記憶すると共に、端末装置による編集に伴って増減する編集回数または編集サイズが、上限値または下限値を超える場合は、課金の実行を停止することを特徴とする。
【００２１】
このように、編集回数または編集サイズに上限値または下限値を設け、それに応じて課金停止をすることにより、編集に対する一定の制限がかかり、ユーザが想定しない編集をすることを防ぐことができる。
【００２２】
（８）また、本発明の映像録画装置において、番組データ配信部は、端末装置とは異なる他の端末装置から、端末装置の編集要求に基づいて録画された放送番組データを検索する旨の検索要求があったときに、検索要求に従って、放送番組データの検索を行ない、検索した放送番組データを他の端末装置へ配信することを特徴とする。
【００２３】
このように、他の端末装置による検索視聴要求に従って、検索された放送番組データをその端末装置へ配信することにより、第三者は契約をしているユーザと同様に放送番組データを視聴することができる。
【００２４】
（９）また、本発明の映像録画装置において、番組データ配信部は、端末装置から公開設定要求があったときに、録画した放送番組データが他の端末装置からの検索要求に応じて検索されるように設定を行ない、承認処理部は、他の端末装置から検索要求があったときに、検索要求を承認するか否かを判定することを特徴とする。
【００２５】
このように、承認処理部が他の端末装置から検索要求があったときに、検索要求を承認するか否かを判定することにより、放送番組データの第三者公開に関して一定の制限をかけることができる。これにより、ユーザと映像録画装置の事業者との契約に基づいた公開が可能となる。
【００２６】
（１０）また、本発明の映像録画装置において、公開設定要求を承認するための公開条件を示す情報を記憶する公開条件データベースをさらに備え、承認処理部は、公開条件データベースに格納されている公開条件に基づいて、公開設定要求を承認するか否かを判定することを特徴とする。
【００２７】
このように、公開条件を示す情報を記憶する公開条件データベースを設け、公開条件に基づいて承認判定を行なうことにより、録画データの公開回数に対して契約に基づく制限をすることが可能となる。
【００２８】
（１１）また、本発明の映像録画装置において、公開設定要求の対象となった放送番組データの全部または一部が、視聴範囲に含まれることを公開条件とする。
【００２９】
このように、放送番組データの全部または一部が、視聴範囲に含まれていることを公開条件とすることにより、少なくとも一度はユーザがＣＭを視聴する必要があるため、広告主の目的を少なくとも部分的に達成することができる。
【００３０】
（１２）また、本発明の映像録画装置において、公開設定要求の対象となった放送番組データの全部または一部が録画された時刻から、予め定められた時間が経過することを公開条件とする。
【００３１】
このように、録画された時刻から、予め定められた時間が経過することを公開条件とすることにより、特定期間が経過するまでは、公開前の状態が保たれる為、公開前の状態においてＣＭがある場合に、その広告主にとって大きな不利益になることはない。また、特定期間が経過した後は公開される為、公開時に新しいＣＭデータを挿入することが可能となり、その広告主にとって利益となる。
【００３２】
（１３）また、本発明の映像録画装置において、公開設定に対する課金を実行すると共に、課金に関する情報を記憶する公開設定課金処理部をさらに備え、承認処理部は、課金が実行されたか否かに応じて公開設定要求を承認するか否かを判定することを特徴とする。
【００３３】
このように、承認処理部が課金が実行されたか否かに応じて公開設定要求を承認するか否かを判定することにより、公開設定の契約に基づいた適切な課金処理を行なうことができる。
【００３４】
（１４）また、本発明の映像録画装置において、公開設定課金処理部は、公開設定回数または公開設定サイズを示す情報を記憶すると共に、端末装置による公開設定に伴って増減する公開設定回数または公開設定サイズに基づいて課金を実行することを特徴とする。
【００３５】
このように、公開設定回数または公開設定サイズに基づいて課金を実行することにより、実際の視聴毎に管理できるので、正確な手数料（著作権利用料）を計算できる。
【００３６】
（１５）また、本発明の映像録画装置において、公開設定課金処理部は、公開設定回数または公開設定サイズの上限値または下限値を記憶すると共に、端末装置による公開設定に伴って増減する公開設定回数または公開設定サイズが、上限値または下限値を超える場合は、課金の実行を停止することを特徴とする。
【００３７】
このように、公開設定回数または公開設定サイズに上限値または下限値を設け、それに応じて課金停止をすることにより、公開に対する一定の制限がかかり、ユーザが想定しない公開をすることを防ぐことができる。
【００３８】
（１６）また、本発明の映像録画装置において、広告データを取得する広告情報通信部をさらに備え、番組データ配信部は、編集後の構成情報に基づいて、放送番組データの全部または一部を端末装置に配信する際に、取得した広告データを放送番組データの全部または一部に挿入することを特徴とする。
【００３９】
このように、放送番組データの全部または一部を端末装置に配信する際に、取得した広告データを放送番組データの全部または一部に挿入することにより、広告主にとってはＣＭが視聴されることで利益を受けるので、ユーザ端末のユーザにとって、映像録画装置の事業者への手数料が安く抑えられる可能性がある。
【００４０】
（１７）また、本発明の映像録画装置において、番組録画部は、録画した放送番組データに関連するキーワードを放送番組データと共にデータベースに格納し、広告情報通信部は、放送番組データに関連するキーワードを用いて広告データを取得することを特徴とする。
【００４１】
このように、放送番組データに関連するキーワードを用いて広告データを取得することにより、視聴者は放送番組の内容に関連する広告を見ることになるので、効果の高い広告を実現することができる。
【００４２】
（１８）本発明の端末装置は、上記（１）〜（１７）のいずれかに記載の映像録画装置から放送番組データを取得する。
【００４３】
このように、端末装置は映像録画装置と接続されていることにより、映像録画装置に対して録画予約をすることができる。さらに、端末装置から番組コンテンツの編集要求をすることにより、映像録画装置に対して構成管理データベースに格納された構成情報を編集することができる。また、端末装置から視聴要求をすることにより、編集後の構成情報と放送番組データの全部または一部を受信することができる。これにより、放送番組データのような容量の大きなデータを編集することなく、編集された放送番組をユーザが視聴することができる。
【００４４】
（１９）本発明の録画映像提供方法は、ネットワークに接続されている端末装置に対して録画映像を提供する録画映像提供方法であって、放送通信部において、放送番組データを取得するステップと、番組録画部において、取得した放送番組データをデータベースに格納するステップと、構成管理データベースに放送番組データを特定する情報および放送番組データの放送開始時刻から放送終了時刻までの間のいずれかの時間的範囲を示す情報を少なくとも含む構成情報を格納するステップと、承認処理部において、端末装置から構成管理データベースに格納されている構成情報を編集する編集要求があったときに、その編集要求を承認するか否かを判定するステップと、編集制御部において、判定の結果、編集要求が承認された場合、編集要求に従って、構成情報の編集を実行するステップと、番組データ配信部において、編集後の構成情報に基づいて、放送番組データの全部または一部を端末装置に配信するステップと、を少なくとも含むことを特徴とする。
【００４５】
このように、構成管理データベースに放送番組データを特定する情報および放送番組データの放送開始時刻から放送終了時刻までの間のいずれかの時間的範囲を示す情報を少なくとも含む構成情報を格納するので、ユーザの端末装置からの録画予約に応じて、番組の構成情報を含む録画予約レコードを構成管理データベースに格納することができる。さらに、承認処理部において、端末装置から構成管理データベースに格納されている構成情報を編集する編集要求があったときに、その編集要求を承認するか否かを判定するので、著作権に関わる人の間の契約に基づいて、ユーザの編集条件を制御することができる。編集制御部において、判定の結果、編集要求が承認された場合、編集要求に従って、構成情報の編集を実行するので、ユーザ端末装置から番組コンテンツの編集要求があれば、編集制御部が上記構成管理データバースに格納された構成情報を編集することができる。これにより、放送番組データのような容量の大きなデータを編集することなく、編集された放送番組をユーザが視聴することができる。
【００４６】
（２０）本発明の映像録画装置の制御プログラムは、ネットワークに接続されている端末装置に対して録画映像を提供する映像録画装置の制御プログラムであって、番組録画部において、放送番組データを取得し、取得した放送番組データをデータベースに格納する処理と、構成管理データベースに放送番組データを特定する情報および放送番組データの放送開始時刻から放送終了時刻までの間のいずれかの時間的範囲を示す情報を少なくとも含む構成情報を格納する処理と、承認処理部において、端末装置から構成管理データベースに格納されている構成情報を編集する編集要求があったときに、その編集要求を承認するか否かを判定する処理と、編集制御部において、判定の結果、編集要求が承認された場合、編集要求に従って、構成情報の編集を実行する処理と、番組データ配信部において、編集後の構成情報に基づいて、放送番組データの全部または一部を端末装置に配信する処理と、の一連の処理を、コンピュータに読み取り可能および実行可能にコマンド化したことを特徴とする。
【００４７】
このように、放送番組データを特定する情報および放送番組データの放送開始時刻から放送終了時刻までの間のいずれかの時間的範囲を示す情報を少なくとも含む構成情報を格納するので、ユーザの端末装置からの録画予約に応じて、番組の構成情報を含む録画予約レコードを構成管理データベースに格納することができる。さらに、構成情報の編集を実行するので、ユーザ端末装置から番組コンテンツの編集要求があれば、上記構成管理データバースに格納された構成情報を編集することができる。これにより、放送番組データのような容量の大きなデータを編集することなく、編集された放送番組をユーザが視聴することができる。
【発明の効果】
【００４８】
本発明によれば、ネットワーク上の録画装置において、効率的に録画コンテンツを管理し、編集することが可能となる。また、著作権者に関わる人の間で利益の分配を適切に行ないつつ、視聴者に録画済み番組の編集機能を提供することで、利便性を高めることができる。また、より柔軟な広告機能を提供することができる。
【図面の簡単な説明】
【００４９】
【図１】本発明の第１の実施形態に係る放送システムの概略構成を示すブロック図である。
【図２】本発明の第１の実施形態に係る映像録画装置の録画処理を示すフローチャートである。
【図３】録画された番組データの一部の例を示す図である。
【図４】本発明の第１の実施形態に係る映像録画装置の録画予約処理を示すフローチャートである。
【図５】２人のユーザＡとＢによって録画要求された場合の例を、模式的に表わす図である。
【図６】録画完了後の構成管理ＤＢ２５３に記録されたレコードの例を示す図である。
【図７】本発明の第１の実施形態に係る映像録画装置の編集処理を示すフローチャートである。
【図８】編集処理後の構成管理ＤＢ２５３に記録されたレコードの例を示す図である。
【図９】編集操作に関する契約条件ＤＢに記録されたレコードの例を示す図である。
【図１０】、ユーザＡが録画コンテンツ１０１−１を視聴した範囲の一例を示す図である。
【図１１】編集処理における承認処理部２０２の動作を示すフローチャートである。
【図１２】視聴履歴レコードの例を示す図である。
【図１３】本発明のおける視聴処理を示すフローチャートである。
【図１４】本発明の第２の実施形態に係る放送システムの概略構成を示すブロック図である。
【図１５】ユーザが編集した録画コンテンツを、第三者に公開することに関する条件をユーザ毎に表す公開条件レコードの例を模式的に示す図である。
【図１６】本発明の第２の実施形態において、公開録画コンテンツを検索して視聴する処理の流れを示すフローチャートである。
【図１７】広告サーバ４に対する広告データ取得リクエストの一例を示す図である。
【発明を実施するための形態】
【００５０】
（第１の実施形態）
図１は、本発明の第１の実施形態に係る放送システムの概略構成を示すブロック図である。本実施形態に係る放送システムは、図１に示すように、放送サーバ１、映像録画装置２およびユーザ端末３から構成される。
【００５１】
放送サーバ１は、放送番組データ（番組データ）を配信する。放送サーバ１の配信方法は、いわゆる地上波による配信、放送衛星による配信などの他、ＩＰネットワーク上でデジタルデータをマルチキャスト／ユニキャストで配信することもある。これらのような形態の放送サーバは、現時点でもすでに多数存在しているため、詳細な説明を省略する。なお、番組データは、典型的には、ＭＰＥＧ２（Motion Picture Expert Group）フォーマットや、Ｈ．２６４フォーマットで記述された動画像である。
【００５２】
映像録画装置２は、図１の破線内部の機能ブロックから構成される。映像録画装置２は、放送通信部２０１、承認処理部２０２、編集制御部２０３、録画制御部２０４、番組データ受信部２０５、番組データ配信部２０６およびＩＰ通信部２０７を備えている。さらに、ユーザ管理ＤＢ２５１、契約条件ＤＢ２５２、構成管理ＤＢ２５３、録画番組ＤＢ２５４を備えている。
【００５３】
映像録画装置２および各構成要素は、一般的なコンピュータシステムで実現され、ＣＰＵ（Central Processing Unit）、ＲＡＭ（Random Access Memory）、ＲＯＭ（Read Only Memory）、２次記憶装置、入出力装置、ディスプレイ、キーボード、およびそれらの制御プログラムなどから構成される。または、それらのコンピュータシステムを複合することにより構成することも可能である。
【００５４】
放送通信部２０１は、放送サーバ１から配信された番組データ（放送コンテンツ）を取得する。放送形態によって、アンテナ、ＩＰネットワーク端子や、チューナー、ＭＰＥＧ２デコーダ、Ｈ．２６４デコーダなどから構成される。
【００５５】
承認処理部２０２は、ユーザからの編集要求および後述する第２の実施形態における公開録画コンテンツ検索要求の際に、契約条件ＤＢ２５２を参照して、ユーザ操作を許可するかどうかを判定する。
【００５６】
編集制御部２０３は、承認処理部２０２によって許可されたユーザからの編集操作の要求を受けて、構成管理ＤＢ２５３および録画番組ＤＢ２５４に格納された録画コンテンツを編集する。例えば、ユーザ端末３から、ＨＴＴＰ（Hyper Text Transfer Protocol）によって編集要求を受け付ける場合は、編集制御部２０３は、ＨＴＴＰに対応したサーバプログラムとして実現されることになる。編集方法などについては後述する。
【００５７】
録画制御部２０４は、録画番組ＤＢ２５４に記録される番組データのＩＤを割り当てたり、ユーザ毎の録画要求に対し適切に処理して、構成管理ＤＢ２５３に記録、管理する。例えば、ユーザ端末３から、ＨＴＴＰによって録画要求を受け付ける場合は、編集制御部２０３は、ＨＴＴＰに対応したサーバプログラムとして実現されることになる。その制御方法について後述する。録画制御部２０４は、録画番組ＤＢ２５４に記録される番組データのＩＤを割り当てたり、ユーザ毎の録画要求に対し適切に処理して、構成管理ＤＢ２５３に記録、管理する。例えば、ユーザ端末３から、ＨＴＴＰによって録画要求を受け付ける場合は、編集制御部２０３は、ＨＴＴＰに対応したサーバプログラムとして実現されることになる。その制御方法について後述する。
【００５８】
番組データ受信部２０５は、放送通信部２０１で取得した番組データを、録画番組ＤＢ２５４に記録する。詳細な記録内容については後述する。
【００５９】
番組データ配信部２０６は、ユーザからの視聴要求に従い、録画番組ＤＢ２５４に記録された録画コンテンツを、ユーザ端末３に配信する。デジタルコンテンツの配信方法は、典型的にはＲＴＳＰ（Realtime Streaming Protocol）／ＲＴＰ（Realtime Transport Protocol）や、ＨＴＴＰを使って行なわれることが多いが、特にこれに制限されることはなく、配信を達成できるための任意の配信方法でよい。配信を実現するための技術は公知であるため、詳細な説明を省略する。
【００６０】
ＩＰ通信部２０７は、ユーザ端末３からの様々な要求を受け付けて、各構成要素に転送したり、デジタルデータの配信処理を行なう。ユーザ端末３とは典型的にはＩＰネットワークで接続されており（経路上のルータなどの存在は省略）、ＩＰネットワーク用の端子や、その制御チップ、プログラムで構成される。なお、放送通信部２０１と、ＩＰ通信部２０７がそれぞれ放送サーバ１と、ユーザ端末３とのやりとりのために接続するネットワークは、ここでは別ものであるとしているが、同一のものであってもよい。すなわち、映像録画装置２からのネットワーク経路上に共通のルータ機器が存在し、そのルータ機器から放送サーバ１、ユーザ端末３の両方に接続するような経路であっても良い。さらには、放送サーバ１から配信されるデジタルデータが、一旦ユーザ端末３まで届き、ユーザ端末３が映像録画装置２へ転送するような経路でも良い。
【００６１】
ユーザ管理ＤＢ２５１は、映像録画装置２が提供するサービスを利用するユーザを管理するためのＤＢである。ユーザ管理の技術は公知であるので、詳細な説明は省略する。また、本発明の映像編集サービスを利用するユーザは、公知のユーザ管理技術により、任意のタイミングで既に登録済みであると仮定する。
【００６２】
契約条件ＤＢ２５２は、編集操作の可否を判定するための根拠となるデータを格納する。詳細な内容は後述する。また、構成管理ＤＢ２５３は、録画番組ＤＢ２５４に記録された録画コンテンツに対して、ユーザ毎の構成情報を管理するためのＤＢである。構成情報とは、録画番組ＤＢ２５４に格納された番組データの全部または一部を表すためのメタ情報である。詳細な内容は後述する。また、録画番組ＤＢ２５４は、放送通信部２０１で取得された番組データを格納する。格納方法については後述する。
【００６３】
ユーザ管理ＤＢ２５１、契約条件ＤＢ２５２、構成管理ＤＢ２５３、録画番組ＤＢ２５４は、典型的には固定ディスクなどの記憶装置や、管理するためのＤＢＭＳ（Database Management System）で構成される。
【００６４】
ユーザ端末３は、映像録画装置２に録画要求、編集要求、検索要求、配信要求を行なったり、配信された番組データをモニタ、スピーカーなどで再生することができる。ユーザ端末３の各要求操作に対するユーザインターフェースとしては、既に普及しているＤＶＤレコーダや、ＨＴＭＬ（Hypertext Markup Language）ブラウザ上でのユーザインターフェースなどを利用すればよく、公知であるので、詳細な説明を省略する。ユーザ端末３は、典型的にはユーザ毎に用意され、複数存在するが、本実施の形態の説明では区別なく扱う。
【００６５】
＜録画処理＞
図２は、本発明の第１の実施形態に係る映像録画装置２の録画処理を示すフローチャートである。ここでは、図１の例を用いて説明する。映像録画装置２は、チャンネルサーチを行なうか、マニュアルで設定するなどして予め設定されたチャンネル毎に、録画制御部２０４で、時間毎（２４時間単位であれば日付など）に番組データを記録する単位を特定するためのＩＤを割り当てる（ステップＳ１０１）。例えば、２００９年３月１日の、放送局Ａ−ＢＣの番組データに対して、ファイルＩＤ＝１０１を割り当て、ファイル名として、「2009/03/02/101.mpg」を対応づける。
【００６６】
次に、番組データ受信部２０５にて、録画を実施し、具体的には上述のファイル名に対して放送通信部２０１で取得した番組データを、録画番組ＤＢ２５４に順次記録していく（ステップＳ１０２）。この録画処理は、全てのチャンネルについて並列に行ない（ステップＳ１０３）、日が経過（業界では午前４：００を日の区切りとすることが多い）する際に、新しいＩＤを割り当て直して、録画実施を繰り返す（ステップＳ１０４）。これらの処理の結果、映像録画装置２で管理されているチャンネルの番組を常に録画し続けることになる。
【００６７】
図３は、録画された番組データの一部の例を示す図である。上記処理により、図３に示すようなファイルおよびＤＢレコードが番組データＤＢ２５４に記録されることとなる。ファイルＩＤ＝１０１の録画コンテンツ（録画コンテンツ１０１）は、２００９年３月１日午前４：００から、２００９年３月２日午前４：００（の直前と解釈しても良い）の間のＡ−ＢＣ放送局によって放送された番組データが、「2009/03/02/101.mpg」というファイル名で記録されていることを示す。ファイルＩＤ＝１０２の録画コンテンツは、同時間の、Ｎ−ＴＶ放送局によって放送された番組データに対するレコードである。ここで時刻は、日本時間などの地域ローカルタイムを基準にして良いが、特にこれにこだわらず、世界標準時などを基準にしても良い。また、基準時刻が異なる複数国の番組を録画する場合は、基準時刻はそれぞれのコンテンツで異なったものになると考えられるので、より適切に時間の区切りを設定すればよい。
【００６８】
＜録画予約処理＞
図４は、本発明の第１の実施形態に係る映像録画装置の録画予約処理を示すフローチャートである。ここでは、図１の例を用いて説明する。まず、ユーザ端末３から、録画要求を発行し、ＩＰ通信部２０７を経由して、録画制御部２０４が録画要求を受け付ける（ステップＳ２０１）。もし、対応する録画番組が、図２におけるステップＳ１０１〜Ｓ１０４での録画処理にて録画されたら、録画制御部２０４は録画確認を行なう（ステップＳ２０２）。次に、録画制御部２０４は、要求元ユーザＩＤと関連づけて、録画コンテンツに関するレコードを作成し、構成管理ＤＢ２５３に格納する（ステップＳ２０３）。ここで、ユーザＩＤと関連付けられた録画コンテンツに関するレコードを録画予約レコードと表す。
【００６９】
図５は、２人のユーザＡとＢによって録画要求された場合の例を、模式的に表わす図である。図５では、番組データ５０１は録画番組ＤＢ２５４に記録され、録画要求範囲５０２、５０３はそれぞれユーザＡ、ユーザＢによって要求された範囲を示す。
【００７０】
図６は、録画完了後の構成管理ＤＢ２５３に記録されたレコードの例を示す図である。録画ＩＤ１０１−１、１０１−２は、それぞれユーザＡ、ユーザＢに対するレコードであり、１９:００〜２０：００、１９：３０〜２０：３０という時間範囲を持つ。番組データの実体は、いずれもファイルＩＤ＝１０１の番組データであり、複数のユーザに対し、効率的に番組データの格納を行なうことができている。
【００７１】
ここで、録画要求の対象番組は、未来に存在する場合がほとんどであるため、ステップＳ２０１時点では、予約情報として管理し、内部のタイマー制御などによって、後日ステップＳ２０２〜Ｓ２０３の処理を行なうことになるが、これらの処理は既に公知であるので詳細な説明はしない。逆に、上述のような構成となっているので、過去に存在する番組に対して録画要求を出すこともできる。例えば、放送されてから１週間は番組データを録画番組ＤＢ２５４から削除しなければ、この期間の間は、遡って録画要求を発行することができるので、見逃し視聴などのサービスも簡単に実現することができる。
【００７２】
＜編集処理＞
図７は、本発明の第１の実施形態に係る映像録画装置の編集処理を示すフローチャートである。ここで“編集”とは、録画コンテンツの動画像に対し、特定の範囲に対して、削除、削除解除、ホワイトバランス補正、トリミング、フェードアウト、フェードイン、などの映像編集処理のことを言う。ここでは、図１および図６の例を用いて説明する。まず、ユーザ端末３が編集要求を発行し、編集制御部２０３は、編集要求を受け付ける（ステップＳ３０１）。例えば、編集要求としては、「ユーザＡの録画コンテンツ１０１−１（録画ＩＤ＝１０１−１のコンテンツ）に対して、１９：２９〜１９：３０の範囲を削除する」という内容だったと仮定する。
【００７３】
次に、編集制御部２０３は、承認処理部２０２に編集操作の可否を問い合わせる（ステップＳ３０２）。承認処理部２０２は、後述の処理によってＯＫ、または、ＮＧの回答を行ない、ＮＧであれば何も編集操作を実行せずにエラーをユーザ端末３に返す。承認処理部２０２がＯＫを回答すれば、録画コンテンツ１０１−１に関係するレコード（図６の録画ＩＤ＝１０１−１のレコード）を構成管理ＤＢ２５３より取得する（ステップＳ３０３）。ＳＴＡＲＴ＝１９：００、ＥＮＤ＝２０：００となっているので、上記編集要求の場合、１９：００〜１９：２９と、１９：３０〜２０：００の２つのレコードに分割することになる（ステップＳ３０４）。
【００７４】
図８は、編集処理後の構成管理ＤＢ２５３に記録されたレコードの例を示す図である。図８では、上記編集要求に加え、さらに１９：４４〜１９：４５の範囲も削除している。ここで、図６に示されたＳＥＱ＝０の値を持つレコードは図８には示さなかったが、実際にＳＥＱ＝０のレコードを削除しても良いし、残しておいても良い。残した場合には、ＳＥＱ＝０か０以外かによって、全体を表す場合と、一部を表す場合とを区別することができる。なお、ステップＳ３０２で、承認処理部２０２は、編集操作の可否を判定するが、それは次のようにして行なう。
【００７５】
図９は、編集操作に関する契約条件ＤＢに記録されたレコードの例を示す図である。ここで、「編集契約」は、どのような種類の編集が契約によって許可されているかを示す。視聴範囲編集は、一度視聴した範囲ならば編集することが可能であることを示し、編集するためには少なくとも一度は視聴する必要がある。自由範囲編集は、一度も視聴していなくとも自由に編集することが可能であることを示す。特定期間後は、録画後すぐは編集できないが、例えば、１週間、１月、１年などの期間が経過すれば、自由に編集しても良いことを示す。
【００７６】
「編集課金種類」は、課金される場合、どのような方法で課金されるかを示す。定額は、例えば月額いくら、というふうに１月あたりの決まった手数料を支払う方式である。編集毎、および、従量制は、編集の回数または量（サイズ）に応じて課金する方式で、ここでは、決まった上限を設定し、その範囲内で編集可能にする場合と、上限は決めずに、ある期日により編集回数、量を測定して、それに応じて課金金額を決める方式の２種類があると想定している。例えば、ユーザＢの場合は、月内（あるいは、年内、無期限）にあと５回編集操作が可能であり、編集操作を行なうと、（残）編集回数の値が減っていくことを示し、ユーザＤの場合は、月内（あるいは、年内、その他の期間内）に、すでに１０回編集操作が行なわれており、編集操作を行なう毎に（残）編集回数の値は増えていくことを示す。
【００７７】
なお、図９のレコードについては、ユーザと映像録画装置２の事業者との間で契約が締結され、それに基づき予め設定されているものとする。データベースに対してレコードを記録するのは一般的なことであり、詳細な説明は省略する。
【００７８】
図１０は、ユーザＡが録画コンテンツ１０１−１を視聴した範囲の一例を示す図である。録画コンテンツ１０１−１全体６０１に対し、矢印部分が、ユーザＡが視聴した範囲６０２である（途中、スキップまたは早送りが行なわれた）。また、ユーザＡが削除編集したい部分の候補６１１、６１２、６１３は、塗りつぶし部分で示す。
【００７９】
図１１は、編集処理における承認処理部２０２の動作を示すフローチャートである。ここでは、図１、図３、図９、図１０の例を用いて説明する。以下の処理は、全て承認処理部２０２で行なわれる。まず、ユーザＡの編集条件レコードを取得する（ステップＳ４０１）。次に、編集契約の種類を判定し、「視聴範囲編集」「自由範囲編集」「特定期間後」であった場合にはそれぞれ、ステップＳ４０３、ステップＳ４０４、ステップＳ４０５へ進み、契約がない場合にはＮＧ判定となる（ステップＳ４０２）。
【００８０】
「視聴範囲編集」では、まず視聴済み範囲かどうかが判定される（ステップＳ４０３）。視聴済み範囲かどうかを判定するため、番組データ配信部２０６において後述の視聴処理を行なう際、視聴履歴レコードを作成する。
【００８１】
図１２は、視聴履歴レコードの例を示す図である。例えば、ＳＥＱ＝１のレコードは、ユーザＡが録画コンテンツ１０１−１を視聴する際、１９：００〜１９：４０の範囲を視聴済みであることを示す。視聴履歴レコードは、ユーザ管理ＤＢ２５１に記録すれば良いが、構成管理ＤＢ２５３や、その他の図示しないＤＢに格納しても良い。さて、編集対象が、ユーザＡが削除編集したい部分の候補６１１、６１３に対応する範囲であれば、この範囲は視聴済みであることが分かるのでＯＫとし、Ｓ４０４へ進むが、ユーザＡが削除編集したい部分の候補６１２に対応する範囲であれば、視聴済みでないのでＮＧとなる。
【００８２】
この方法では、例えば、ＣＭをカットしたい場合は、少なくとも一度はＣＭを視聴する必要があるため、広告主の目的を少なくとも部分的に達成することができる。このようにＣＭカット操作を許可したとしても、広告主にとって著しく不利益になることはないので、ユーザが支払う手数料を低く抑えることが可能となる。さらに、ネットワークの双方向性を利用し、ＣＭの場所に他メディアによる広告へのリンクを埋め込んでおき、ユーザが少なくとも一度は広告へのリンク先にアクセスしなければ編集できないようにしていてもよい。映像録画装置２の少なくとも関連する事業者が広告サーバを運用して上記リンクを捕捉できるようにしておけば、図１２に相当するレコードを作成するのは容易である。これによると、必ず広告を見ることになるので、広告主にとって大きな利益となる。
【００８３】
次に、課金状況が確認される（ステップＳ４０４）。図９において、ユーザＡの場合には、定額であるのでＯＫとなる。もし、編集毎であった場合には、（残）編集回数を減じ（０のときはＮＧ）、もし、従量制であった場合には、（残）編集回数を増加しＯＫとなる（ステップＳ４０６）。
【００８４】
「自由範囲編集」の場合は、直接Ｓ４０４へ進み、ステップＳ４０６の処理を実行する。
【００８５】
「特定期間後」の場合は、まず、期間を判定する（ステップＳ４０５）。図３により、録画コンテンツ１０１−１の録画日時は、２００９年３月１日４：００なので、「特定期間」を1週間とする場合は、Ｓ４０５の処理を行なう日時が、３月８日４：００以降であればＯＫとなる。特定期間が１月や、その他の期間でも同様の処理となる。また、時間については、常に４：００を基準とするなどの方法でも良い（ユーザには、日だけで判定できるので分かり易い）。その後の課金処理は、Ｓ４０４に進むので同様となる。
【００８６】
この方法では、特定期間が経過するまでは、ＣＭがカットされることはないため、広告主にとって大きな不利益になることはない。特定期間が経過した後はＣＭカットできるようになるため、長期間保存しておきたい録画コンテンツの整理ができ、ユーザにとって利益となる。
【００８７】
なお、図９では、これらの編集契約は、ユーザ毎に１つとしたが、放送局毎や、時間帯毎などとしてもよい。また、上述の３種類だけでなく、サイズによる制約があってもよい（比較的短いコンテンツである場合は編集可能など）。
【００８８】
ここで、編集処理の例として、削除処理を扱ったが、これに限定するものではない。本発明の映像録画装置２は、構成管理ＤＢ２５３による管理を行なっているので、一度削除した範囲を取り消し、削除を解除することができる。その他の、ホワイトバランス補正、トリミング、フェードアウト、フェードインについても、図８に、それらの編集内容を記述するデータを追加し、番組データ配信部２０６が配信処理をする際に、データの内容を記述されたデータに従って修正して配信すればよい。例えば、１９：００〜１９：０１の範囲を、フェードインという属性をつけたレコードを構成管理ＤＢ２５３に記録しておき、配信時には、その範囲についてフェードイン処理をリアルタイムで行なって配信すればよい。もっとも、リアルタイムで行なうには負荷の高い処理の場合には、予め処理済みのデータを作っておく（そのための管理レコードも必要になる）ことも有効である。
【００８９】
なお、上述の編集操作では、対象の範囲（開始時刻〜終了時刻）を指定する必要があるが、その時に、他のユーザの編集範囲を、編集対象候補としてユーザ端末３に提案することもできる。例えば、図８の例では、ユーザＡが録画コンテンツ１０１−１を編集しているとき、同じファイルＩＤでＳＴＡＲＴ〜ＥＮＤの範囲が重なるユーザＢのレコードにおいて、「１９：４４〜１９：４５」「１９：５９〜２０：００」の範囲が編集によってカットされていることが分かるので、それらの範囲を、編集候補としてユーザＡのユーザ端末３に提案することもできる。
【００９０】
なお、上述の編集操作は、サイズの大きな番組データそのものの編集を行なうのでなく、その構成を管理するレコードだけを修正するので、非常に高速に行なうことができる。
【００９１】
＜録画コンテンツの視聴処理＞
図１３は、録画コンテンツの視聴処理を示すフローチャートである。ここでは、図１および図８の例用いて説明する。なお、録画コンテンツリストの記述、視聴要求の記述や、ＵＩ表示については、従来のネットワーク型ビデオオンデマンドシステムなどで公知であるので詳細な説明はしない。まず、ユーザ端末３は、録画コンテンツリスト要求を発行する。録画制御部２０４は、リスト要求を受け付け、ユーザの判定を行ない、対応する録画コンテンツのリストを作成してユーザ端末３に応答する（ステップＳ５０１）。対応する録画コンテンツは、図８等で示されるレコードの内、録画ＩＤとＳＥＱで特定されるものを検索すればよい。
【００９２】
次に、ユーザ端末３はそのうちの特定のコンテンツを選択して視聴要求を発行する。録画制御部２０４は、視聴要求を受け付ける（ステップＳ５０２）。この処理でのプロトコルは、ＳＤＰや、ＲＴＳＰ／ＲＴＰなど公知の技術があり説明を省略する。但し、ＲＴＰで送信する録画コンテンツの番組データについてはステップＳ５０３〜Ｓ５０５の流れで処理される。次に、指定された特定の録画コンテンツに対応するレコード集合を構成管理ＤＢ２５３から取得する（ステップＳ５０３）。録画コンテンツ１０１−１が指定されたとすると、図８で示されるＳＥＱ＝１〜３のレコードが取得される。
【００９３】
続いて、対応するレコードをＳＥＱ順（トリックプレイの場合には対応するＳＥＱから）に取得し、その範囲の録画データを録画番組ＤＢ２５４から取得してユーザ端末３に送信する（ステップＳ５０４〜Ｓ５０５）。図８の例では、１９：００〜１９：２９、１９：３０〜１９：４４、１９：４５〜１９：５６の範囲に対応する録画データを順に送信することになる。なお、ここでＭＰＥＧ２の内部に埋め込まれているＰＣＲ（Program Clock Reference）など、連続性のあるデータについては、適切に処理されるものとする。ステップＳ５０４〜Ｓ５０５にて、視聴済みかどうかを判定するため、図１２に示されるような視聴履歴を作成してもよい。
【００９４】
（第２の実施形態）
第１の実施形態では、録画コンテンツに対し、ユーザの要求により編集する例を説明した。第２の実施形態では、編集された番組データだけでなく、広告サーバからの広告データを統合して扱う例、および、編集されたコンテンツを第三者に公開する例を示す。
【００９５】
図１４は、本発明の第２の実施形態に係る放送システムの概略構成をを示すブロック図である。図１における第１の実施形態との違いは、映像録画装置１２の構成に変更があることと、広告サーバ４が追加されたことである。映像録画装置１２は、構成要素として、ほとんど映像録画装置２と同様なものを含むが、広告情報通信部１２０７を含むところと、番組データ配信部１２０６と契約条件ＤＢ１２５２の機能が異なる。また、ユーザ端末３，３’，３”は、本実施形態では、第１の実施形態と異なり、区別して扱う。ここで、ユーザ端末３のユーザは第１の実施形態において映像録画装置２の事業者と契約をしている者とし、ユーザ端末３’、３”のユーザは第三者とする。
【００９６】
番組データ配信部１２０６は、番組データ配信部２０６と同様にユーザ端末に対して、録画コンテンツの番組データを配信するが、広告情報通信部１２０７によって取得された広告データを、番組データに挿入して配信するところが異なる。詳細な手順については後述する。広告情報通信部１２０７は、広告データを広告サーバ４から取得し、保持する。番組データ配信部１２０６からの要求に従って、相応しい広告データを返し、ユーザ端末３および第三者のユーザ端末（以下、ユーザ端末３’等）によって、適切に広告が視聴されるようにする。
【００９７】
なお、実装としては、典型的には一般的なコンピュータシステムで実現され、広告データを格納するための外部記憶装置があってもよい。また、広告データの取得タイミングとしては、番組データ配信部１２０６からの要求があってから、広告サーバ４から取得しても良いし、予め広告サーバ４から配信の可能性のある広告データを予め取得しておき、データベースに格納しておいても良い。
【００９８】
契約条件ＤＢ１２５２は、契約条件ＤＢ２５２と同様にユーザ毎の契約条件を記録するが、第三者への公開に関する契約条件をも含むところが異なる。内容の詳細については後述する。なお、契約条件を記録するための処理については、一般的なデータベースへの登録処理であり、公知であるので詳細な説明を省略する。
【００９９】
広告サーバ４は、広告データを映像録画装置１２に提供する。広告は通常、番組内容を知った上で効果があると判断した広告主が出すので、広告データを単に出すだけでなく、挿入される番組に対する条件（あるいは、特定の番組を指定）も合わせて提示されることが想定される。実装としては、単なるデータを提供するサーバであり、一般的なコンピュータシステムで実装されるので、詳細な説明を省略する。
【０１００】
図１５は、ユーザが編集した録画コンテンツを、第三者に公開することに関する条件をユーザ毎に表す公開条件レコードの例を模式的に示す図である。「公開契約」とは、どのような条件で公開が許可されるかを示す。視聴後公開は、ユーザが録画コンテンツを視聴した後、第三者への公開が許可されうることを示す。無制限公開は、ユーザが視聴していなくても許可されうることを示す。特定期間後公開は、特定の期間（１週間、１月、１年など）が経過すれば許可されうることを示す。ＣＭ公開は、公開された場合に、ユーザが編集（典型的にはＣＭカット）した部分に、広告サーバ４から取得されたＣＭデータが挿入されるような形態で許可されうることを示す。広告主にとってはＣＭが視聴されることで利益を受けるので、ユーザ端末３のユーザにとって、映像録画装置１２の事業者への手数料が安く抑えられる可能性がある。ユーザＧのように「公開契約」が設定されていない場合は、公開が許可されるような契約が締結されていないことを示す。
【０１０１】
「公開課金種類」とは、課金の種類を表す。定額は、月額いくらなど、公開される録画コンテンツ数、量に関わらず一定の手数料を支払う形態の契約である。課金処理が煩雑にならないというメリットがある。従量制は、公開後、第三者ユーザが視聴する回数、量をカウントしておき、月末などの期日にとりまとめて手数料を決定する方式である。実際の視聴毎に管理できるので、正確な手数料（著作権利用料）を計算できるメリットがある。公開毎は、ユーザの操作によって、特定の録画コンテンツを公開に設定し、その設定操作毎に課金する方式である。コンテンツ毎に課金できるので、ある程度著作権者の意向を手数料に反映でき（録画コンテンツによって料金が異なるなど）、課金処理も比較的容易である。このときユーザの設定操作に関しては一般的な技術であるので詳細な説明を省略する。なお、従量制、公開毎ともに、上限を設定し、上限を超えそうになったら、公開を停止する、または、公開設定操作を禁止するなどの方式を組み合わせることも可能である。そして手数料から、予め締結された契約に基づく著作権利用料が、映像録画装置１２の事業者から著作権者に支払われることになる。
【０１０２】
図８の、「公開Ｆ」は、該当する録画コンテンツが、第三者に対して公開されているかどうかを示す。公開ＦをＹｅｓに変更する処理は、例えば、ユーザ端末３からの操作によって行なわれる。操作の詳細は一般的であり説明を省略するが、定額の契約の場合は課金による制限はなく、従量制の場合は図１５の「（残）公開回数」が正であることを条件とし、公開毎の場合は「（残）公開回数」が正であることを条件として設定される。公開契約がないときは公開Ｆを変更することは出来ない。以降、図１５のようなレコードが契約条件ＤＢ１２５２に予め記録されているものとして説明する。
【０１０３】
＜検索視聴処理＞
図１６は、本発明の第２の実施形態において、公開録画コンテンツを検索して視聴する処理の流れを示すフローチャートである。ここでは、図８、図１４、図１５の例で説明する。まず、番組データ配信部１２０６において、図１３のＳ５０１と同様に、ユーザ端末３’等から受け付けた録画リスト取得要求に対し、ユーザに関連する録画リストを返却する（ステップＳ６０１）。次に、ユーザ端末３’等から検索視聴要求を受け付ける（ステップＳ６０２）。
【０１０４】
この時、特定の録画コンテンツに関連するものとして要求され、図８において、録画コンテンツ１０１−１が指定されていれば、ファイルＩＤが一致し、ＳＴＡＲＴ〜ＥＮＤで表される範囲に重なりがあるようなコンテンツが検索される（ステップＳ６０３）。但し、図８の公開ＦがＹｅｓに設定されているものだけが検索対象となる。例えば、図８では、ユーザＢの録画コンテンツ１０１−２が、検索結果の１つとなる。これにより、検索された録画コンテンツのリストが返却される（ステップＳ６０４）。
【０１０５】
次に、ユーザ端末３’等は、検索された録画コンテンツのリストから、録画コンテンツ１０１−２を選択し、視聴要求を発行する。番組データ配信部１２０６は、その視聴要求を受け付け（ステップＳ６０５）、対応するレコード集合を取得する（ステップＳ６０６）。図８の例ではＳＥＱ＝１〜３の３つのレコードが取得される。なお、この時、１０１−２の所有者であるユーザＢの契約条件は、図１５に示すとおり従量制であるとすると、今回の公開によって、課金されるユーザであるユーザＢの「（残）公開回数」を増加（上限のある回数券のようなタイプであれば減少させる処理でも良い）させる必要がある。また、上限に達した場合には、ユーザＢの録画コンテンツの「公開Ｆ」をＮｏに設定し、これ以上第三者に視聴されることがないようにする必要がある（公開Ｆでなく、他のテーブルなどで公開許可を管理してもよい）。取得された対応レコードを順に１つ取り出し、その範囲の録画データを送信する（ステップＳ６０７）。この際、契約条件によっては、ＣＭデータを取得し、送信する（ステップＳ６０８）。取得された対応レコードに後続があればＳ６０７に戻り、後続がなければ検索視聴処理が完了する（ステップＳ６０９）。ステップＳ６０７〜Ｓ６０９の繰り返しにより、検索された録画データを視聴することができる。
【０１０６】
上記のように、録画データの１つを送信する毎に、公開契約の内容（ＣＭ公開）によっては、録画コンテンツとは別に、広告情報通信部１２０７によって取得された広告データを、挿入して送信することもできる。そのようにすることで、特に、ユーザ端末３’等では、有用なダイジェストデータ（例えば、野球中継のハイライトシーンだけにしたダイジェストなど）のような録画データを見ることができると同時に、著作権者、あるいは、放送局にとっては特に最新の広告を提供こともできるため、双方にとって利便性が高い。そのような場合には、ユーザ端末３を所有するユーザの公開契約のために支払う手数料を安く抑えられる可能性がある。
【０１０７】
また、Ｓ６０８にて、広告主は通常、広告を提供する際の放送コンテンツの内容を選ぶので、録画コンテンツの内容に応じて挿入する広告データを切り替えられるのが望ましい。例えば、録画された日時と放送局が分かればどの番組か特定できるので、それを用いて広告データを取得（広告サーバ側で適切なものを返す）してもよい。また、番組データ受信部２０５が放送データを受信する際に、ＥＰＧ（Electronic Program Guide）に含まれたキーワードを同時に取得しておき、録画番組ＤＢ２５４などに関連づけて記憶しておくと、そのキーワードを指定して広告取得すればよい。
【０１０８】
図１７は、広告サーバ４に対する広告データ取得リクエストの一例を示す図である。ｂａｓｅｂａｌｌ，ｃａｍｐなどの狭義のキーワードに加え、日時なども指定しており、広告サーバ側では、これらすべてを広義のキーワードとして扱って検索するようにすればよい。もっとも、予め広告サーバ４から広告データを取得しておく場合には、キーワード情報なども同時に取得しておけばよい。なお、Ｓ６０７とＳ６０８の順序は逆でも良い。
【０１０９】
＜第２の実施形態の変形例＞
図１６のステップＳ６０２〜Ｓ６０３では、返却された録画リストのうち特定の録画コンテンツを選択し、それに関連する公開可能コンテンツを検索するとしたが、本発明は、それに限定されず、例えば放送局（または、映像録画装置１２の事業者）が提供する録画コンテンツが検索結果のリストにあってもよい。例えば、放送局が野球中継のハイライトシーンだけで構成されたダイジェストデータを含めておけば、ＣＭ公開の契約の場合と同じように動作させることで、最新のＣＭを提供しつつ、より多くのユーザに視聴してもらえるので、非常に広告効果の高いコンテンツ提供を行なうことができることになる。
【０１１０】
なお、上述では、広告サーバ４からの広告データを統合して扱うことと、編集されたコンテンツを第三者に公開することの両方を同時に用いる例としたが、それに限らない。第三者に公開する機能がなくても、ハイライトシーンダイジェストを作る場合には、広告データを自動挿入するような場合でも手数料を抑えた編集契約を実施できるし、同じくハイライトシーン提供事業者などの事業を考慮すると、広告データの自動挿入機能がなくても、第三者への公開を行なうことができる公開契約を定義しても構わない。
【符号の説明】
【０１１１】
１ 放送サーバ
２、１２ 映像録画装置
３、３’、３” ユーザ端末
４ 広告サーバ
２０１ 放送通信部
２０２ 承認処理部
２０３ 編集制御部
２０４ 録画制御部
２０５ 番組データ受信部
２０６、１２０６ 番組データ配信部
２０７ ＩＰ通信部
２５１ ユーザ管理ＤＢ
２５２、１２５２ 契約条件ＤＢ
２５３ 構成管理ＤＢ
２５４ 録画番組ＤＢ
１２０７ 広告情報通信部
【特許請求の範囲】
【請求項１】
ネットワークに接続されている端末装置に対して録画映像を提供する映像録画装置であって、
放送番組データを取得し、取得した放送番組データをデータベースに格納する番組録画部と、
前記放送番組データを特定する情報および前記放送番組データの放送開始時刻から放送終了時刻までの間のいずれかの時間的範囲を示す情報を少なくとも含む構成情報を格納する構成管理データベースと、
前記端末装置から前記構成管理データベースに格納されている構成情報を編集する編集要求があったときに、前記編集要求に従って、前記構成情報の編集を実行する編集制御部と、
前記編集後の構成情報に基づいて、前記放送番組データの全部または一部を前記端末装置に配信する番組データ配信部と、を備えることを特徴とする映像録画装置。
【請求項２】
前記端末装置から前記構成管理データベースに格納されている構成情報を編集する編集要求があったときに、その編集要求を承認するか否かを判定する承認処理部と、
前記編集要求を承認するための編集条件を示す情報を格納する編集条件データベースと、をさらに備え、
前記承認処理部は、前記編集条件データベースに格納されている編集条件に基づいて、前記編集要求を承認するか否かを判定し、
前記編集制御部は、前記判定の結果、前記編集要求が承認された場合、前記編集要求に従って、前記構成情報の編集を実行することを特徴とする請求項１記載の映像録画装置。
【請求項３】
前記番組データ配信部は、視聴範囲として、配信した放送番組データを示す情報を記憶する視聴範囲記憶部を備え、
前記編集要求の対象となった放送番組データの全部または一部が、前記視聴範囲に含まれることを前記編集条件とする請求項２記載の映像録画装置。
【請求項４】
前記編集要求の対象となった放送番組データの全部または一部が録画された時刻から、予め定められた時間が経過することを前記編集条件とする請求項２記載の映像録画装置。
【請求項５】
前記構成情報の編集に対する課金を実行すると共に、課金に関する情報を記憶する課金処理部をさらに備え、
前記承認処理部は、前記課金が実行されたか否かに応じて前記編集要求を承認するか否かを判定することを特徴とする請求項１から請求項４のいずれかに記載の映像録画装置。
【請求項６】
前記課金処理部は、編集回数または編集サイズを示す情報を記憶すると共に、前記端末装置による編集に伴って増減する編集回数または編集サイズに基づいて課金を実行することを特徴とする請求項５記載の映像録画装置。
【請求項７】
前記課金処理部は、編集回数または編集サイズの上限値または下限値を記憶すると共に、前記端末装置による編集に伴って増減する編集回数または編集サイズが、前記上限値または下限値を超える場合は、課金の実行を停止することを特徴とする請求項６記載の映像録画装置。
【請求項８】
前記番組データ配信部は、前記端末装置とは異なる他の端末装置から、前記端末装置の編集要求に基づいて録画された放送番組データを検索する旨の検索要求があったときに、前記検索要求に従って、放送番組データの検索を行ない、検索した放送番組データを前記他の端末装置へ配信することを特徴とする請求項１から請求項７のいずれかに記載の映像録画装置。
【請求項９】
前記番組データ配信部は、前記端末装置から公開設定要求があったときに、前記録画した放送番組データが前記他の端末装置からの検索要求に応じて検索されるように設定を行ない、
前記承認処理部は、前記他の端末装置から検索要求があったときに、前記検索要求を承認するか否かを判定することを特徴とする請求項８記載の映像録画装置。
【請求項１０】
前記公開設定要求を承認するための公開条件を示す情報を記憶する公開条件データベースをさらに備え、
前記承認処理部は、前記公開条件データベースに格納されている公開条件に基づいて、前記公開設定要求を承認するか否かを判定することを特徴とする請求項９記載の映像録画装置。
【請求項１１】
前記公開設定要求の対象となった放送番組データの全部または一部が、前記視聴範囲に含まれることを前記公開条件とする請求項１０記載の映像録画装置。
【請求項１２】
前記公開設定要求の対象となった放送番組データの全部または一部が録画された時刻から、予め定められた時間が経過することを前記公開条件とする請求項１０記載の映像録画装置。
【請求項１３】
前記公開設定に対する課金を実行すると共に、課金に関する情報を記憶する公開設定課金処理部をさらに備え、
前記承認処理部は、前記課金が実行されたか否かに応じて前記公開設定要求を承認するか否かを判定することを特徴とする請求項９から請求項１２のいずれかに記載の映像録画装置。
【請求項１４】
前記公開設定課金処理部は、公開設定回数または公開設定サイズを示す情報を記憶すると共に、前記端末装置による公開設定に伴って増減する公開設定回数または公開設定サイズに基づいて課金を実行することを特徴とする請求項１３記載の映像録画装置。
【請求項１５】
前記公開設定課金処理部は、公開設定回数または公開設定サイズの上限値または下限値を記憶すると共に、前記端末装置による公開設定に伴って増減する公開設定回数または公開設定サイズが、前記上限値または下限値を超える場合は、課金の実行を停止することを特徴とする請求項１４記載の映像録画装置。
【請求項１６】
広告データを取得する広告情報通信部をさらに備え、
前記番組データ配信部は、前記編集後の構成情報に基づいて、前記放送番組データの全部または一部を前記端末装置に配信する際に、前記取得した広告データを前記放送番組データの全部または一部に挿入することを特徴とする請求項１から請求項１５のいずれかに記載の映像録画装置。
【請求項１７】
前記番組録画部は、録画した放送番組データに関連するキーワードを前記放送番組データと共に前記データベースに格納し、
前記広告情報通信部は、前記放送番組データに関連するキーワードを用いて広告データを取得することを特徴とする請求項１６記載の映像録画装置。
【請求項１８】
請求項１から請求項１７のいずれかに記載の映像録画装置から放送番組データを取得する端末装置。
【請求項１９】
ネットワークに接続されている端末装置に対して録画映像を提供する録画映像提供方法であって、
放送通信部において、放送番組データを取得するステップと、
番組録画部において、前記取得した放送番組データをデータベースに格納するステップと、
構成管理データベースに前記放送番組データを特定する情報および前記放送番組データの放送開始時刻から放送終了時刻までの間のいずれかの時間的範囲を示す情報を少なくとも含む構成情報を格納するステップと、
承認処理部において、前記端末装置から前記構成管理データベースに格納されている構成情報を編集する編集要求があったときに、その編集要求を承認するか否かを判定するステップと、
編集制御部において、前記判定の結果、前記編集要求が承認された場合、前記編集要求に従って、前記構成情報の編集を実行するステップと、
番組データ配信部において、前記編集後の構成情報に基づいて、前記放送番組データの全部または一部を前記端末装置に配信するステップと、を少なくとも含むことを特徴とする録画映像提供方法。
【請求項２０】
ネットワークに接続されている端末装置に対して録画映像を提供する映像録画装置の制御プログラムであって、
番組録画部において、放送番組データを取得し、取得した放送番組データをデータベースに格納する処理と、
構成管理データベースに前記放送番組データを特定する情報および前記放送番組データの放送開始時刻から放送終了時刻までの間のいずれかの時間的範囲を示す情報を少なくとも含む構成情報を格納する処理と、
承認処理部において、前記端末装置から前記構成管理データベースに格納されている構成情報を編集する編集要求があったときに、その編集要求を承認するか否かを判定する処理と、
編集制御部において、前記判定の結果、前記編集要求が承認された場合、前記編集要求に従って、前記構成情報の編集を実行する処理と、
番組データ配信部において、前記編集後の構成情報に基づいて、前記放送番組データの全部または一部を前記端末装置に配信する処理と、の一連の処理を、コンピュータに読み取り可能および実行可能にコマンド化したことを特徴とする映像録画装置の制御プログラム。
【請求項１】
ネットワークに接続されている端末装置に対して録画映像を提供する映像録画装置であって、
放送番組データを取得し、取得した放送番組データをデータベースに格納する番組録画部と、
前記放送番組データを特定する情報および前記放送番組データの放送開始時刻から放送終了時刻までの間のいずれかの時間的範囲を示す情報を少なくとも含む構成情報を格納する構成管理データベースと、
前記端末装置から前記構成管理データベースに格納されている構成情報を編集する編集要求があったときに、前記編集要求に従って、前記構成情報の編集を実行する編集制御部と、
前記編集後の構成情報に基づいて、前記放送番組データの全部または一部を前記端末装置に配信する番組データ配信部と、を備えることを特徴とする映像録画装置。
【請求項２】
前記端末装置から前記構成管理データベースに格納されている構成情報を編集する編集要求があったときに、その編集要求を承認するか否かを判定する承認処理部と、
前記編集要求を承認するための編集条件を示す情報を格納する編集条件データベースと、をさらに備え、
前記承認処理部は、前記編集条件データベースに格納されている編集条件に基づいて、前記編集要求を承認するか否かを判定し、
前記編集制御部は、前記判定の結果、前記編集要求が承認された場合、前記編集要求に従って、前記構成情報の編集を実行することを特徴とする請求項１記載の映像録画装置。
【請求項３】
前記番組データ配信部は、視聴範囲として、配信した放送番組データを示す情報を記憶する視聴範囲記憶部を備え、
前記編集要求の対象となった放送番組データの全部または一部が、前記視聴範囲に含まれることを前記編集条件とする請求項２記載の映像録画装置。
【請求項４】
前記編集要求の対象となった放送番組データの全部または一部が録画された時刻から、予め定められた時間が経過することを前記編集条件とする請求項２記載の映像録画装置。
【請求項５】
前記構成情報の編集に対する課金を実行すると共に、課金に関する情報を記憶する課金処理部をさらに備え、
前記承認処理部は、前記課金が実行されたか否かに応じて前記編集要求を承認するか否かを判定することを特徴とする請求項１から請求項４のいずれかに記載の映像録画装置。
【請求項６】
前記課金処理部は、編集回数または編集サイズを示す情報を記憶すると共に、前記端末装置による編集に伴って増減する編集回数または編集サイズに基づいて課金を実行することを特徴とする請求項５記載の映像録画装置。
【請求項７】
前記課金処理部は、編集回数または編集サイズの上限値または下限値を記憶すると共に、前記端末装置による編集に伴って増減する編集回数または編集サイズが、前記上限値または下限値を超える場合は、課金の実行を停止することを特徴とする請求項６記載の映像録画装置。
【請求項８】
前記番組データ配信部は、前記端末装置とは異なる他の端末装置から、前記端末装置の編集要求に基づいて録画された放送番組データを検索する旨の検索要求があったときに、前記検索要求に従って、放送番組データの検索を行ない、検索した放送番組データを前記他の端末装置へ配信することを特徴とする請求項１から請求項７のいずれかに記載の映像録画装置。
【請求項９】
前記番組データ配信部は、前記端末装置から公開設定要求があったときに、前記録画した放送番組データが前記他の端末装置からの検索要求に応じて検索されるように設定を行ない、
前記承認処理部は、前記他の端末装置から検索要求があったときに、前記検索要求を承認するか否かを判定することを特徴とする請求項８記載の映像録画装置。
【請求項１０】
前記公開設定要求を承認するための公開条件を示す情報を記憶する公開条件データベースをさらに備え、
前記承認処理部は、前記公開条件データベースに格納されている公開条件に基づいて、前記公開設定要求を承認するか否かを判定することを特徴とする請求項９記載の映像録画装置。
【請求項１１】
前記公開設定要求の対象となった放送番組データの全部または一部が、前記視聴範囲に含まれることを前記公開条件とする請求項１０記載の映像録画装置。
【請求項１２】
前記公開設定要求の対象となった放送番組データの全部または一部が録画された時刻から、予め定められた時間が経過することを前記公開条件とする請求項１０記載の映像録画装置。
【請求項１３】
前記公開設定に対する課金を実行すると共に、課金に関する情報を記憶する公開設定課金処理部をさらに備え、
前記承認処理部は、前記課金が実行されたか否かに応じて前記公開設定要求を承認するか否かを判定することを特徴とする請求項９から請求項１２のいずれかに記載の映像録画装置。
【請求項１４】
前記公開設定課金処理部は、公開設定回数または公開設定サイズを示す情報を記憶すると共に、前記端末装置による公開設定に伴って増減する公開設定回数または公開設定サイズに基づいて課金を実行することを特徴とする請求項１３記載の映像録画装置。
【請求項１５】
前記公開設定課金処理部は、公開設定回数または公開設定サイズの上限値または下限値を記憶すると共に、前記端末装置による公開設定に伴って増減する公開設定回数または公開設定サイズが、前記上限値または下限値を超える場合は、課金の実行を停止することを特徴とする請求項１４記載の映像録画装置。
【請求項１６】
広告データを取得する広告情報通信部をさらに備え、
前記番組データ配信部は、前記編集後の構成情報に基づいて、前記放送番組データの全部または一部を前記端末装置に配信する際に、前記取得した広告データを前記放送番組データの全部または一部に挿入することを特徴とする請求項１から請求項１５のいずれかに記載の映像録画装置。
【請求項１７】
前記番組録画部は、録画した放送番組データに関連するキーワードを前記放送番組データと共に前記データベースに格納し、
前記広告情報通信部は、前記放送番組データに関連するキーワードを用いて広告データを取得することを特徴とする請求項１６記載の映像録画装置。
【請求項１８】
請求項１から請求項１７のいずれかに記載の映像録画装置から放送番組データを取得する端末装置。
【請求項１９】
ネットワークに接続されている端末装置に対して録画映像を提供する録画映像提供方法であって、
放送通信部において、放送番組データを取得するステップと、
番組録画部において、前記取得した放送番組データをデータベースに格納するステップと、
構成管理データベースに前記放送番組データを特定する情報および前記放送番組データの放送開始時刻から放送終了時刻までの間のいずれかの時間的範囲を示す情報を少なくとも含む構成情報を格納するステップと、
承認処理部において、前記端末装置から前記構成管理データベースに格納されている構成情報を編集する編集要求があったときに、その編集要求を承認するか否かを判定するステップと、
編集制御部において、前記判定の結果、前記編集要求が承認された場合、前記編集要求に従って、前記構成情報の編集を実行するステップと、
番組データ配信部において、前記編集後の構成情報に基づいて、前記放送番組データの全部または一部を前記端末装置に配信するステップと、を少なくとも含むことを特徴とする録画映像提供方法。
【請求項２０】
ネットワークに接続されている端末装置に対して録画映像を提供する映像録画装置の制御プログラムであって、
番組録画部において、放送番組データを取得し、取得した放送番組データをデータベースに格納する処理と、
構成管理データベースに前記放送番組データを特定する情報および前記放送番組データの放送開始時刻から放送終了時刻までの間のいずれかの時間的範囲を示す情報を少なくとも含む構成情報を格納する処理と、
承認処理部において、前記端末装置から前記構成管理データベースに格納されている構成情報を編集する編集要求があったときに、その編集要求を承認するか否かを判定する処理と、
編集制御部において、前記判定の結果、前記編集要求が承認された場合、前記編集要求に従って、前記構成情報の編集を実行する処理と、
番組データ配信部において、前記編集後の構成情報に基づいて、前記放送番組データの全部または一部を前記端末装置に配信する処理と、の一連の処理を、コンピュータに読み取り可能および実行可能にコマンド化したことを特徴とする映像録画装置の制御プログラム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【公開番号】特開２０１０−２７３０８３（Ｐ２０１０−２７３０８３Ａ）
【公開日】平成２２年１２月２日（２０１０．１２．２）
【国際特許分類】
【出願番号】特願２００９−１２２９４２（Ｐ２００９−１２２９４２）
【出願日】平成２１年５月２１日（２００９．５．２１）
【出願人】（０００００５０４９）シャープ株式会社 (33,933)
【Ｆターム（参考）】
【公開日】平成２２年１２月２日（２０１０．１２．２）
【国際特許分類】
【出願日】平成２１年５月２１日（２００９．５．２１）
【出願人】（０００００５０４９）シャープ株式会社 (33,933)
【Ｆターム（参考）】
[ Back to top ]