(57)【要約】【課題】メタデータの処理負荷を低減する。また、映像再生端末の種別・能力を意識することなく映システムサイドの適応化によって映像データを配信する。【解決手段】コンテンツ購入処理サーバ２では、ユーザの好みを示すユーザプロファイル情報１３と、メタデータ５の要約情報であるアダプテーションヒント７とにより、ユーザの好みに合うメタデータ５のみを選別し統合して各ユーザお勧めのコンテンツメニューであるＲＣＭ９を作成して、携帯端末１へ送る。携帯端末１はＲＣＭ９を参照して、コンテンツの購入要求１０をコンテンツ購入処理サーバ２へ送信し、コンテンツの視聴を許可するコンテンツ視聴券１２を得て、コンテンツ視聴券１２を有する映像端末１２から端末情報１６およびコンテンツ視聴ステイタ情報１５をコンテンツ配信サーバ３に送信し、当該映像端末４に最適なデータフォーマットの映像データ１７を受信する。【選択図】        図１
2004247844.tif 000002
【特許請求の範囲】
【請求項１】
映像コンテンツのメタデータ中にどのような情報が含まれているかを記述したメタデータ要約情報に基づいて、上記メタデータを選別するメタデータ選別処理方法。
【請求項２】
前記メタデータは、映像コンテンツのシーン構造を記述する情報と、各シーンの特徴的な意味内容を記述する情報とを含み、
前記メタデータ要約情報に基づいて、前記各シーンの特徴的な意味内容を記述する情報が存在するメタデータを選別することを特徴とする請求項１記載のメタデータ選別処理方法。
【請求項３】
映像中に特異な映像特徴量の変化があったことをイベントとして検出し、
前記メタデータは、映像コンテンツのシーン構造を記述する情報と、各シーンのイベントを記述する情報とを含み、
前記メタデータ要約情報に基づいて、前記各シーンのイベントを記述する情報が存在するメタデータを選別することを特徴とする請求項１記載のメタデータ選別処理方法。
【請求項４】
映像コンテンツのメタデータ中にどのような情報が含まれているかを記述したメタデータ要約情報と、所望の映像コンテンツの部分または全体を抽出するためのクエリ情報とを入力し、前記メタデータ要約情報に基づいて、前記クエリ情報に該当するデータ要素が存在するメタデータを特定して該データ要素を抽出し、所定の規則にしたがって抽出したデータ要素を統合するメタデータ選択統合処理方法。
【請求項５】
前記メタデータは、映像コンテンツのシーン構造を記述する情報と、各シーンの特徴的な意味内容を記述する情報とを含み、
前記メタデータ要約情報に基づいて、前記各シーンの意味内容を記述する情報が存在するメタデータを特定して該データ要素を抽出し、所定の規則にしたがって抽出したデータ要素を統合することを特徴とする請求項４記載のメタデータ選択統合処理方法。
【請求項６】
映像中に特異な映像特徴量の変化があったことをイベントとして検出し、
前記メタデータは、映像コンテンツのシーン構造を記述する情報と、各シーンのイベントを記述する情報とを含み、
前記メタデータ要約情報に基づいて、前記各シーンのイベントを記述する情報が存在するメタデータを特定して該データ要素を抽出し、所定の規則にしたがって抽出したデータ要素を統合することを特徴とする請求項４記載のメタデータ選択統合処理方法。
【請求項７】
映像コンテンツのメタデータ中にどのような情報が含まれているかを記述したメタデータ要約情報と、所望の映像の部分または全体を抽出するためのクエリ情報とを入力し、前記メタデータ要約情報に基づいて、前記クエリ情報に該当するデータ要素が存在するメタデータを特定して該データ要素を抽出し、所定の規則にしたがって抽出したデータ要素を統合するとともに、抽出されたデータ要素が含まれる映像シーンを特定して連続的に再生することを特徴とする映像再生方法。
【請求項８】
ユーザ毎にカスタマイズされたコンテンツメニューをユーザ端末に送信し、
ユーザ端末からコンテンツメニューを参照してのコンテンツ購入要求があり、当該コンテンツの視聴を許可する場合には、少なくともコンテンツの内容である映像データのロケータ情報、コンテンツの総再生時間、映像データをどの時刻から再生すればよいかの情報、およびコンテンツの視聴期限が記述されているコンテンツ視聴券を当該ユーザ端末に送信するコンテンツ購入処理方法。
【請求項９】
請求項８記載のコンテンツ購入処理方法において、
ユーザ端末は、前記コンテンツ視聴券を受信すると、
当該ユーザ端末自身、あるいは他の映像再生端末に前記コンテンツ視聴券を渡して当該他の映像再生端末から、前記コンテンツ視聴券に基づきコンテンツのロケータ情報およびコンテンツを再生開始からどこまで視聴したかを示す再生時刻情報を含むコンテンツ視聴ステイタス情報と、少なくとも当該端末にて受信可能な映像データフォーマットを示す端末情報を、コンテンツ配信サーバに対し送信し、
前記コンテンツ配信サーバは、前記端末から前記コンテンツ視聴ステイタス情報および端末情報を受信すると、前記端末情報に従って上記端末に送信すべき映像データの最適なデータフォーマットを決定し、前記コンテンツ視聴ステイタス情報に従って最初ないしは途中から要求されたコンテンツを決定した最適なデータフォーマットにて当該端末へ送信し、
当該端末は、当該端末に最適なデータフォーマットで送信される最初ないしは途中からのコンテンツを再生する、
ことを特徴とするコンテンツ購入処理方法。
【請求項１０】
請求項９記載のコンテンツ購入処理方法において、
上記端末は、当該端末に最適なデータフォーマットで送信された最初ないしは途中からのコンテンツを再生した後、再生を終了すると、その再生時間に基づきコンテンツ視聴券の再生時刻情報を更新することを特徴とするコンテンツ購入処理方法。
【請求項１１】
ユーザ毎にカスタマイズされたコンテンツメニューをユーザ端末に送信し、
ユーザ端末からコンテンツメニューを参照してのコンテンツ購入要求があり、当該コンテンツの視聴を許可する場合には、少なくともコンテンツの内容である映像データのロケータ情報、コンテンツの総再生時間、映像データをどの時刻から再生すればよいかの情報、およびコンテンツの視聴期限が記述されているコンテンツ視聴券を当該ユーザ端末に送信するコンテンツ購入処理サーバ。
【請求項１２】
コンテンツの内容である映像データのロケータ情報、コンテンツの総再生時間、映像データをどの時刻から再生すればよいかの情報、およびコンテンツの視聴期限が記述されているコンテンツ視聴券を受信したユーザ端末自身、あるいは当該コンテンツ視聴券を渡した他の映像再生端末から、前記コンテンツ視聴券に基づきコンテンツのロケータ情報およびコンテンツを再生開始からどこまで視聴したかを示す再生時刻情報を含むコンテンツ視聴ステイタス情報と、少なくとも当該端末にて受信可能な映像データフォーマットを示す端末情報とが送信されてくると、
前記端末情報に従って上記端末に送信すべき映像データの最適なデータフォーマットを決定し、前記コンテンツ視聴ステイタス情報に従って最初ないしは途中から要求されたコンテンツを決定した最適なデータフォーマットにて当該端末へ送信して、当該端末に最適なデータフォーマットで最初ないしは途中からのコンテンツを再生させる、
ことを特徴とするコンテンツ配信サーバ。
【請求項１３】
コンテンツの内容である映像データのロケータ情報、コンテンツの総再生時間、映像データをどの時刻から再生すればよいかの情報、およびコンテンツの視聴期限が記述されているコンテンツ視聴券の情報を受信して、該コンテンツ視聴券の情報と、少なくとも自身が受信再生可能な映像データフォーマットを示す端末情報とに基づいて、視聴対象となるコンテンツを、受信再生可能な最適な映像データフォーマットで送信することを要求する、
ことを特徴とする映像再生端末。
【請求項１４】
映像コンテンツのメタデータ中にどのような情報が含まれているかを記述したメタデータ要約情報と、所望の映像コンテンツの部分または全体を抽出するためのクエリ情報とを入力し、前記メタデータ要約情報に基づいて、前記クエリ情報に該当するデータ要素が存在するメタデータを特定して該データ要素を抽出し、所定の規則にしたがって抽出したデータ要素を統合することをコンピュータに実行させるメタデータ選択統合処理プログラム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
この発明は、メタデータに関連付けられて管理される映像コンテンツの効率的伝送、蓄積、管理、運用を行うシステムに供することのできるメタデータ選別処理方法、メタデータ選択統合処理方法、メタデータ選択統合処理プログラム、映像再生方法、コンテンツ購入処理方法、コンテンツ購入処理サーバ、コンテンツ配信サーバに関するものである。具体的な応用例としては、ネット配信型コンテンツサービスの提供、映像利用型監視システムの構築、などがある。
【０００２】
【従来の技術】
近年、ＭＰＥＧ−２，  ＭＰＥＧ−４などデジタル映像コンテンツの圧縮技術の普及を背景として、ＤＶＤやハードディスクレコーダ、映像再生機能付携帯電話など、デジタル映像コンテンツを再生・記録する機器・装置が爆発的な普及を見せている。また、インターネットの広帯域化や広帯域モバイル網の整備に伴い、オンラインでデジタル映像コンテンツを伝送、蓄積、管理、運用するシステムの重要性が増している。一方で、いまもってデジタル映像コンテンツはオンラインで直接やりとりするには文書情報などに比してかさばるデータ量であること、かつ、意味内容が時系列変化する情報であることから、その内容を遠隔から的確かつ迅速に確認するためにメタデータを付与することの意義が大きい。このような映像コンテンツへのアクセスを効率化させる目的で、ＭＰＥＧ−７  （ＩＳＯ／ＩＥＣ  １５９３８）、ＴＶ  Ａｎｙｔｉｍｅ（ｈｔｔｐ：／／ｗｗｗ．ｔｖ−ａｎｙｔｉｍｅ．ｏｒｇ／）などの国際標準・業界標準の映像メタデータフォーマットが定められている。このような標準化されたメタデータによれば、オンラインでの映像コンテンツ管理・運用を行うシステムは、ネット上で映像コンテンツそのものにアクセスすることなく外部からのアクセス（検索、ブラウジング、フィルタリング）に効率的に対処することができる。
【０００３】
なお、このようなメタデータを開示した従来技術として、例えば、特開平２００１−０２８７２２号公報に開示されている動画像管理装置がある。この動画像管理装置では、ビデオデータを複数のシーンに分割し、各シーンに対して、そのシーンの再生に必要な区間情報と、シーン番号と、シーンを代表する画像との集まりであるメタデータを作成し、各インデックスに検索目的に応じたタイトルを付与する。ユーザはタイトルを用いてメタデータを検索し、インデックスに含まれるシーン番号の順番と区間情報により、ビデオデータの中の必要なシーンだけをつなぎ合わせて再生することができる。
【０００４】
【特許文献１】
特開平２００１−０２８７２２号公報
【０００５】
【発明が解決しようとする課題】
しかしながら、映像コンテンツの総数が爆発的に増大すると、映像コンテンツのメタデータそのものを管理するデータベースや、メタデータ検索エンジンの処理負荷も大きくなり、結果的にコンテンツアクセスの効率低下を招くという問題が発生する。
【０００６】
特に、映像コンテンツは、時系列により内容が変わるコンテンツであるので、アクセスの主体（ユーザなど）側からの要求として、時系列中の特定の箇所に迅速にアクセスを行いたい、という要求があり、そのためには時系列を所定のシーン単位に分割してメタデータを付与して管理する、といった必要性が生じる。このため、メタデータ自体のデータ量が映像の長さに比例して増大する可能性がある。メタデータに基づいてアクセスの主体が欲する映像コンテンツを見つけようとすると、時系列の最後までメタデータの内容を確認しなければ所望の映像シーンを抽出することができない、という問題がある。
【０００７】
さらに、従来のデジタル映像コンテンツ管理・運用システムにおいては、映像配信側が、視聴に利用可能な映像再生端末の限定を行っており、コンテンツを視聴するには、ユーザ側がシステムの仕様に合わせて端末を用意する必要があった。
【０００８】
本発明は、上記課題を解決するためになされたものであり、メタデータの処理負荷を低減できるメタデータ選別処理方法、メタデータ選択統合処理方法、メタデータ選択統合処理プログラム、映像再生方法、およびユーザが映像再生端末の種別・能力を意識することなくシステムサイドの適応化によって映像データの伝送を行うことのできるコンテンツ購入処理方法、コンテンツ購入処理サーバ、コンテンツ配信サーバを提供することを目的とする。
【０００９】
【課題を解決するための手段】
上記課題を解決するため、本発明では、映像コンテンツのメタデータ中にどのような情報が含まれているかを記述したメタデータ要約情報に基づいて、上記メタデータを選別することを基本とする。
【００１０】
【発明の実施の形態】
実施の形態１．（ネット配信型コンテンツ提供サービスモデル）
本実施の形態１では、本発明を利用した映像コンテンツ管理運用システムの事例として、ネット配信型コンテンツ提供サービスを例に挙げてその構成について述べる。
【００１１】
図１に、本実施の形態１におけるネット配信型コンテンツ提供サービスの全体システム構成を示す。同図において、携帯電話１と、コンテンツ購入処理サーバ２とが携帯電話回線上に構成されるＩＰ網を介して接続されている。また、コンテンツ配信サーバ３と、映像端末４とが公衆ＩＰ網を介して接続されている。携帯電話１と映像端末４とは、例えば赤外線通信経由で接続されているが、動画再生機能付き携帯電話のように、携帯電話１と映像端末４とが同一装置で構成されていても勿論かまわない。なお、以下、すべての実施の形態において、映像データとは、映像のみのデータだけでなく、それに付随するオーディオデータを含んだオーディオビジュアルデータも含むものとする。
【００１２】
メタデータ５は、映像データ６に関連付けられており、少なくとも、映像データ６の例えばシーンのタイトル、シーンの開始点・長さなどのシーン構成と、個々のシーンの映像、音声等のメディアデータに関する特徴量を記述したデータである。
【００１３】
図２に、メタデータ５の構成例を示す。メタデータ５は、例えば、図２に示すように、映像コンテンツのタイトルや、ジャンル、符号化方式等のコンテンツ全体の属性と、各シーン毎に、開始時刻や、シーン時間長、キーワード、特徴量などのメタデータが記述されている。また、シーンによっては、その下位に幾つかのサブシーンが構成され、このサブシーンにも、開始時刻や、シーン時間長、キーワード、特徴量などのメタデータが記述される。なお、これらのメタデータ５は、映像データ６に関して、コンテンツ提供者や本実施の形態１のサービスをおこなう者によってあらかじめ作成されていても良いし、本実施の形態１のサービス提供中に動的に作成されても良い。
【００１４】
動的に作成するメタデータ５の例としては、例えば、ライブ映像コンテンツを提供するケースを想定し、サービス加入者がオンラインで即時視聴できない場合に、ある程度サービス提供側で映像データ６をキャッシュしておき、あらかじめ用意しておくライブ映像固有の映像特徴あるいは音声特徴のテンプレート、例えば、スポーツのライブ映像であれば、サッカーのゴールシーンや、野球のホームランシーン、ゴルフのショットシーンなどのテンプレートとのマッチングを取ることで、映像データ６中の特徴的な映像シーンの抽出を行うなどの事例が考えられる。
【００１５】
また、事前に付与されるメタデータ５の例としては、たとえば「俳優○○が出ているシーン」などといったキーワード的なデータ要素が考えられる。
【００１６】
アダプテーションヒント７は、メタデータ５に関連付けられており、個々のメタデータ５に実際にどのようなデータが含まれているかを記述したメタデータの要約情報である。アダプテーションヒント７も、メタデータ５に関してコンテンツ提供者や本実施の形態１のサービスをおこなう者によって、あらかじめ作成されていても良いし、本実施の形態１のサービスをおこなっている最中に動的に作成されても良い。同図において、メタデータ５、アダプテーションヒント７は、コンテンツ購入処理サーバ２の一部として蓄積されているものとして記載されているが、これらはインターネット上の任意のサーバに配置されていてもよい。
【００１７】
以下、図１のシステムの、一連の動作フローを説明する。
▲１▼．コンテンツ購入処理
コンテンツ購入処理サーバ２は、例えばネット配信型コンテンツサービスプロバイダが運用するものであり、サービス加入ユーザごとにカスタマイズされた、お勧めのコンテンツメニュー９（Ｒｅｃｏｍｍｅｎｄｅｄ  Ｃｏｎｔｅｎｔｓ  Ｍｅｎｕ、以下ＲＣＭと略す）を携帯電話１に送出する。ＲＣＭ９は、ＲＣＭ生成部８によって生成されるが、その詳細動作は後述する。
【００１８】
ＲＣＭ９は、システムがユーザに勧めるコンテンツの一覧情報であり、例えば各コンテンツの代表画像のサムネイルや、サムネイルへリンクとして埋め込まれるコンテンツの識別情報（ＵＲＬなど）、コンテンツのタイトル、概要説明情報といったデータが含まれる。ＲＣＭ９はあらゆるデータ表現形式を取りうる。例えば、携帯電話がＷＥＢブラウザを搭載している場合はＨＴＭＬデータであってもよいし、携帯電話がＳＭＩＬブラウザを搭載している場合はＳＭＩＬデータとして、携帯電話がＪａｖａ（登録商標）実行環境を有する場合にはＪａｖａ（登録商標）プログラムとして実装されてもよい。
【００１９】
ユーザは、サービスプロバイダ等のコンテンツ購入処理サーバ２から送られてくるＲＣＭ９をディスプレイ上に表示して、自分が視聴したいコンテンツを選択し、購入要求１０を送出する。その際、ユーザインタフェースとしては、例えば、ＲＣＭ９を構成する情報の一部としてコンテンツの代表画像（サムネイル）をディスプレイ上に表示して、それを選択し、購入ボタンを押す、などの処理で購入要求１０を送出する。
【００２０】
購入要求１０は、ユーザが何を選択したかの情報となるため、選択されたコンテンツに関連付けられているメタデータからタイトル、ジャンル、キーワードなどの情報を吸い上げ、サービスプロバイダ側の個々の加入ユーザのプロファイル情報１３として蓄積・更新しておき、以降のＲＣＭ９供給時に反映させる。この機構により、ＲＣＭ作成部８は、更新されたユーザプロファイル情報１３を用いて、常にユーザの最新の嗜好を反映したＲＣＭ９を送信することができる。つまり、ユーザプロファイル情報１３は、ＲＣＭ９生成のためのトリガとなるクエリ情報として用いられる。
【００２１】
コンテンツ購入処理サーバ２は、その内部の機能ブロックである購入処理部１１において、適切なユーザ認証のもとで購入要求１０を処理し、ユーザが選択したコンテンツを視聴する権利情報であるコンテンツ視聴券１２を当該ユーザの携帯電話１へ送出する。この際の認証情報としては、携帯電話の電話番号を用いる、などが考えられる。
【００２２】
図３に、コンテンツ視聴券１２の一例を示す。コンテンツ視聴券１２は、例えば、図３に示すように、ユーザが購入したコンテンツのタイトル（Ｔｉｔｌｅ）や、概要情報（Ａｂｓｔｒａｃｔ）、購入日時（Ｐｕｒｃｈａｓｅ  Ｔｉｍｅ／Ｄａｔｅ）、コンテンツの内容である映像データ６のＵＲＬ等のロケータ情報、コンテンツの総再生時間（Ｔｏｔａｌ  Ｔｉｍｅ）、映像データ６のどの時刻から再生すればよいかの情報（Ｓｔａｒｔ  Ｔｉｍｅ）、ユーザが改変・操作できないデータ形式で記述されたコンテンツ視聴有効期限の情報（Ｅｘｐｉｒｅ  Ｔｉｍｅ／Ｄａｔｅ）のいずれかを含むデジタルデータである。なお、コンテンツ視聴有効期限の情報（Ｅｘｐｉｒｅ  Ｔｉｍｅ／Ｄａｔｅ）はユーザが改変・操作できるデータ形式で記述されていても良いし、また、コンテンツ視聴券１２にはこのコンテンツ視聴有効期限の情報（Ｅｘｐｉｒｅ  Ｔｉｍｅ／Ｄａｔｅ）が記述されてなく、コンテンツ購入処理部１２等のサーバ側でのみユーザが改変・操作できないように管理するようにしても勿論よい。また、コンテンツ視聴有効期限の情報（Ｅｘｐｉｒｅ  Ｔｉｍｅ／Ｄａｔｅ）だけでなく、映像データ６をどの時刻から再生すればよいかの情報（Ｓｔａｒｔ  Ｔｉｍｅ）以外の更新されない情報は、ユーザが改変・操作できないデータ形式で記述されていることが望ましい。また、このコンテンツ視聴券１２がなければ、コンテンツの内容である映像データ６のロケータ情報が入手できないように、このコンテンツ視聴券１２に、このロケータ情報を入手するための暗号キーなどが記述されていても勿論良い。携帯電話１は、コンテンツ視聴有効期限情報（Ｅｘｐｉｒｅ  Ｔｉｍｅ／Ｄａｔｅ）が示す有効期限が残っている間は、コンテンツ視聴券１０を自端末内に記憶しておくようにする。また、有効期限が過ぎたコンテンツ視聴券１０は自端末から抹消する。コンテンツ購入処理サーバ２から送信された時点では、再生すべき時刻は、映像データ６の始まる時刻である。なお、再生開始時刻を、ユーザが以前の再生時刻に設定できず、自動的に再生時間分だけ自動的にインクリメントのみするように制御することにより、１回限りのコンテンツ視聴許可に制限すること可能となる。勿論このような１回限りのコンテンツ視聴許可に制限しなくても、本実施の携帯１では、コンテンツ視聴有効期限情報（Ｅｘｐｉｒｅ  Ｔｉｍｅ／Ｄａｔｅ）により、コンテンツの視聴期限は制限している。
【００２３】
ＲＣＭ作成部８は、例えばネット上もしくはローカルの大容量ディスクに蓄積されたサービス提供対象となる映像コンテンツに関連付けて蓄積される膨大なメタデータ５を入力して、該入力メタデータそれぞれについて付与されているアダプテーションヒント７と、ユーザプロファイル１３を用いてターゲットとなるメタデータの部位をフィルタリングし、それらを統合することによってお勧めのコンテンツメニューであるＲＣＭ９を作成し送出する。具体的には、ターゲットとなるメタデータの部位とは、ユーザ嗜好としてユーザプロファイル１３に登録されてキーワードに合致する映像シーンのメタデータなどである。
【００２４】
ここで、アダプテーションヒント７は、対応するメタデータ５の特定のデータ種別に着目して、メタデータ５の実データ（以下、インスタンスと呼ぶ）に、着目する種別のデータがどの程度含まれているかを示す概要・要約情報である。例えば、着目するデータ種別の例として、ＭＰＥＧ−７で規定される、映像シーンを特定の観点から見た場合の重要度を記述するデータである「ＰｏｉｎｔＯｆＶｉｅｗ記述子」を考える。ＰｏｉｎｔＯｆＶｉｅｗ記述子は、以下のようなデータシンタックスで表現される。
【００２５】
2004247844.tif 000003
【００２６】
ｖｉｅｗｐｏｉｎｔとは、上記の「観点」を記述するデータであり、いわば映像シーンをある側面から見た場合の特徴的なキーワードの情報と言い換えることができる。
【００２７】
Ｉｍｐｏｒｔａｎｃｅとは、０〜１の範囲で定義され、ｖｉｅｗｐｏｉｎｔから映像シーンを見た場合に、該ｖｉｅｗｐｏｉｎｔの意味で当該映像シーンがどの程度重要度が高いシーンかを示す情報である。上記のデータ例では、ある映像シーンを「スポーツ」という観点から見た場合に、その重要度は０．５、すなわち１００％を最重要とすれば５０％程度のそこそこの程度である、ということを記述していることになる。ＲＣＭ作成部８は、アダプテーションヒント７としてＭＰＥＧ−７で規定されるＰｏｉｎｔＯｆＶｉｅｗ記述子のｖｉｅｗｐｏｉｎｔの内容と、ユーザのプロファイル情報１３とのマッチングによって、ユーザが望むコンテンツのメタデータを抽出・特定することができる。
【００２８】
なお、ＭＰＥＧ−７規格の標準準拠性の観点からは、ＭＰＥＧ−７で規定される記述子は、スキーマ（シンタックス定義）によってメタデータ５のインスタンス内に含まれることが規定されても、実際のインスタンスに記述として現れるかどうかは、インスタンスを確認する以外に知る手段がない。したがって、映像コンテンツのように時系列で長時間の映像データでは、＜ＰｏｉｎｔＯｆＶｉｅｗ記述子＞のような映像シーン単位に出現の状況が異なるような記述子がメタデータ５のインスタンス内にどの程度含まれているか、サブシーン階層構造を有する映像コンテンツの場合にどの階層に含まれているかなどの情報は、メタデータ５のみでは事前に知ることができないので、上記例のように「スポーツ」を含む映像シーンの存在を＜ＰｏｉｎｔＯｆＶｉｅｗ＞でチェックするにはメタデータすべての解析作業が必要となる。この解析処理の処理量を低減する目的で、メタデータ要約情報としてのアダプテーションヒント７を用いることになる。アダプテーションヒント７は、例えば解析対象のメタデータ５に何個の＜ＰｏｉｎｔＯｆＶｉｅｗ＞が含まれるか、どの階層に＜ＰｏｉｎｔＯｆＶｉｅｗ＞が含まれるか、などのメタデータのインスタンスに関する要約情報を記述する。したがって、端的な例を示せば、複数のメタデータ５をチェックする前にアダプテーションヒント１４を確認して、個々のメタデータに＜ＰｏｉｎｔＯｆＶｉｅｗ＞が少なくとも１つ含まれるかどうかを知ることができれば、＜ＰｏｉｎｔＯｆＶｉｅｗ＞が含まれるメタデータについてのみ、そのインスタンスの記述内容を解析すればよいため、ＲＣＭ９を生成するためのユーザプロファイル情報１３とメタデータ５とのマッチング処理量を大幅に削減することができる。
【００２９】
▲２▼．映像データ配信要求・再生
以上の手順で、ユーザは自分の携帯電話１にコンテンツ購入サーバ２よりコンテンツ視聴券を獲得し、その有効期限が来るまで保持しておき、どこにでも持ち歩くことができる。持ち歩いたコンテンツ視聴券１２は、その内容を解釈できる映像端末４へ赤外線通信や、記録媒体等を介して伝達することにより、映像端末４が自身の映像再生能力に応じてコンテンツ配信サーバ３にユーザが購入した映像コンテンツを映像データ６として要求する。勿論、携帯電話１と映像端末４とが同一であれば、このようなコンテンツ視聴券の伝達は不要である。このため、映像端末４は、コンテンツ視聴券１２の情報を標準的に定められた手順で解釈し、ユーザが有する権利に応じて正当な映像データ６を要求し、再生することが可能な機能処理部を備える。このような機能を有する映像端末４と、携帯電話１および映像端末４と分離してのコンテンツ視聴券１２の流通により、ユーザは携帯電話１を持ち歩くだけで、いつでもどこでも利用可能な映像端末４を用いて、自宅でビデオ機器を操作するがごとくコンテンツを視聴することが可能となる。つまり、コンテンツ購入処理サーバ２から正当に取得したコンテンツ視聴券１２を自己の携帯電話１等に保持している限り、自己の映像端末４とは性能の異なる他人の映像端末４を借りてそこに自己のコンテンツ視聴券１２をセットする限りは、他人の映像端末４を借りても、そのコンテンツ視聴券１２により許可された映像コンテンツをコンテンツ配信サーバ３より正常に受信して使用できることになる。
【００３０】
ここで、映像端末４は、コンテンツ視聴ステイタス情報１５、端末情報１６をコンテンツ配信サーバ３に送出することにより、映像端末４自身の映像再生能力に応じた映像コンテンツを映像データ６として要求する。コンテンツ視聴ステイタス情報１５とは、コンテンツ視聴の状態を保持した情報であり、少なくともコンテンツのＵＲＬなどのロケータ情報、コンテンツを再生開始からどこまで視聴したかを示す再生時刻情報を含む。コンテンツ視聴ステイタス情報１５は、ロケータ情報と、再生時刻情報とにより、ユーザは映像端末４を特定してコンテンツ視聴券１２を送信したあと、コンテンツを再生したいポイントから瞬時に再生開始させることができる。これによれば、ある映像端末４で視聴していたコンテンツの視聴をある時刻で中止した場合、その時刻の次の時刻が再生時刻情報としてコンテンツ視聴券１２に更新されるので、同一のあるいは別の映像端末４でそのコンテンツを視聴する場合でも、前回中止した時点の次からコンテンツの視聴を継続できるというメリットがある。
【００３１】
また、前に別の映像端末４で視聴した時点の記憶があいまいで、今回の視聴を始める前に以前の映像のストーリーを確認したい場合には、あらかじめ再生再開時刻よりも遡った時刻から高速再生またはダイジェスト再生などを行わせることによって、手早く視聴記憶を取り戻して再生を再開させることもできる。この際、高速再生やダイジェスト再生の途中でストーリー上のキーになる映像箇所では代表画像を静止画として表示したり、といったインタフェースも可能である。
【００３２】
端末情報１６は、映像端末４に固有で、標準的なデータ定義に従って記述される情報として映像端末４から標準的な手順に従ってコンテンツ配信サーバ３に送信される。端末情報１６は、少なくとも、映像端末４の表示可能な時間・空間解像度や、受信可能な映像データフォーマット、例えば符号化方式やビットレートなどを含んでいる。
【００３３】
コンテンツ配信サーバ３では、映像フォーマット判定部１８が端末情報１６に従って、映像端末４に送信すべき映像データ６の最適なデータフォーマット、すなわち適応化映像データ１７のデータフォーマットを決定する。データフォーマットの種別には、例えばＭＰＥＧ−４、ＭＰＥＧ−２、Ｍｏｔｉｏｎ−ＪＰＥＧ、ＪＰＥＧ、Ｗｉｎｄｏｗｓ（登録商標）  Ｍｅｄｉａ  Ｖｉｄｅｏ，  ＤｉｖＸなどがある。映像フォーマット判定部１８、決定した送出映像データフォーマットに対して、コンテンツ配信サーバ３自身からそのまま送出可能な映像データか、自分自身でリアルタイムに映像データフォーマットの変換を行いながら送出すべきデータか、あるいは他の連携して動作する別サーバから送出することが適当な映像データか、などの判断を行い、要求元の映像端末４にとって最適な解像度、映像データフォーマットにしたがって、要求された映像データ６を適応化映像データ１７として要求された再生開始時刻から配信する。
【００３４】
なお、映像端末４では、映像再生を中断した場合、中断した時刻でのコンテンツ視聴券１２を携帯電話１に送信する。すると、携帯電話１は、中断した時刻を更新したコンテンツ視聴券１２を記憶する。なお、コンテンツ視聴券１２への中断した時刻の更新は、携帯電話１だけでなく、映像端末４等が行うようにしても勿論よい。そして、携帯電話１が、コンテンツ視聴券１２を別の映像端末４に送信すれば、上記同様の手順によって、別の映像端末４では映像再生を中断した時刻から、再び映像を再生することができる。
【００３５】
▲３▼．映像データ蓄積配信
コンテンツ配信サーバ３は、映像端末４からの端末情報１６と、コンテンツ視聴ステイタス情報１５とを入力して、コンテンツ視聴券１２に対応した映像データ６を、再生すべき時刻から、端末情報１６に記述された映像端末４で再生可能な映像データフォーマット、例えばＭＰＥＧ−４やＭＰＥＧ−２、Ｍｏｔｉｏｎ−ＪＰＥＧ、ＪＰＥＧなどに変換し、変換結果の適応化映像データ１７として、当該映像端末４へ配信する。
【００３６】
その際、コンテンツ配信サーバ３内では、映像フォーマット判定部１８が端末情報１６の入力から映像端末４で再生可能なフォーマットを判定し、必要に応じて映像フォーマット変換部２０にフォーマット情報１９を送信し、コンテンツ視聴ステイタス情報１５に含まれる映像データのロケータ情報と再生開始時刻とを映像データサーバ２１に送信する。
【００３７】
映像データサーバ２１は、映像データのロケータ情報で指示される場所に格納される映像データ６を映像フォーマット変換部２０に送信する。
【００３８】
映像フォーマット変換部２０は、映像データサーバ２１からの映像データ６を、映像フォーマット判定部１８からのフォーマット情報１９で指定される映像データフォーマットに変換したものを、適応化映像データ１７として映像端末に送信する。
【００３９】
従って、本実施の形態１によれば、ユーザの好みを示すユーザプロファイル情報１３と、メタデータ５の要約情報であるアダプテーションヒント７とにより、ユーザの好みに合うメタデータ５のみを選別し統合して各ユーザお勧めのコンテンツメニューであるＲＣＭ９を作成するようにしたので、映像コンテンツのメタデータ５のようにメタデータ５の量が莫大であっても、効率良くユーザの好みにあうメタデータ５を抽出して、ＲＣＭ９を作成することができる。
【００４０】
また、本実施の形態１によれば、コンテンツ視聴券１２を保持した映像端末１２のみがコンテンツを視聴できるようにしたので、インターネット上などの分散環境に蓄積される映像コンテンツを、いつでもどこでも、動的に変化する視聴条件、例えば端末種別や、場所、時間、視聴形態に関する嗜好などに適応させて視聴可能とする、視聴する権利をユーザが購入可能となるシステムを構築することが可能である。
【００４１】
この結果、本実施の形態１によれば、コンテンツアクセスや、メディア伝送の処理に関し、ユーザがシステム仕様を意識することなく、システムが、利用ユーザの個々のコンテンツアクセス環境に適応することが可能となる。具体的には、個々のメタデータを自動生成したり、メタデータに基づいた検索などの処理を行ったりする際に、コンテンツ購入処理サーバ２等のサーバ側で、メタデータ自体の要約情報であるアダプテーションヒント７を自動的に生成し、該要約情報あるアダプテーションヒント７を利用することにより、以降のメタデータの処理、例えばメタデータに基づく所望のコンテンツの検索や、所望のコンテンツに類似したコンテンツの抽出、所望の映像シーンのピックアップと、その結果の提供などの処理実行ステップを低減させることができる。また、映像端末４に、映像のコンテンツ視聴券１２を与えて、映像端末４が端末情報１６やコンテンツ視聴ステイタス情報１５を介し自律的に映像コンテンツ配信サーバ３とネゴシエーションを行うようにしたので、ユーザのコンテンツ視聴環境に依存しない、すなわちどのようなスペックの映像端末４を変えたり、あるいは時間的に間を空けたしても、コンテンツ視聴券１２があって端末情報１６やコンテンツ視聴ステイタス情報１５をコンテンツ配信サーバ３に送信することができる限り、どこでも、何時でも継続的なコンテンツの配信を実現することが可能となる。
【００４２】
なお、本実施の形態１においては、携帯電話１と映像端末４とを別々の端末として説明したが、本発明では、携帯電話１と映像端末４とを同一の端末として構成しても良いし、また携帯電話１とした部分は、持ち運び可能なＰＣやＰＤＡに置き換えても良い。その場合、コンテンツ購入処理サーバ２と携帯電話１の間の通信、すなわちＲＣＭ９や購入要求１０、コンテンツ視聴券１２のやり取りは、携帯電話網ではなく、有線、無線のＩＰ網を通じておこなっても良い。また、携帯電話１と映像端末４間の、コンテンツ視聴券１２の送受信は、赤外線通信を想定しているが、Ｂｌｕｅｔｏｏｔｈ（登録商標）等の無線通信や、あるいはＳＤカード（登録商標）などのカードメディア、家庭用ＬＡＮなどのＩＰ網を通じて行っても良い。
【００４３】
また、コンテンツ配信サーバ３と映像端末４間の端末情報１６やコンテンツ視聴ステイタス情報１５、適応化映像データ１７の伝送は、本実施の形態１では一般のＩＰ網を通じて行うことを想定しているが、ＡＤＳＬやＣＡＴＶケーブル、光ファイバなど一般に利用可能な加入者アクセス網も勿論利用可能である。
【００４４】
また、コンテンツ購入サーバ２とコンテンツ配信サーバ３とを別々のサーバとして説明したが、コンテンツ購入サーバ２とコンテンツ配信サーバ３とを同一のサーバにより構成しても勿論よい。
【００４５】
さらに、ＲＣＭ作成部８や購入処理部１１、映像フォーマット判定部１８等のコンテンツ購入サーバ２やコンテンツ配信サーバ３における処理は、ハードウエアにより構成するだけでなくなく、プログラムの実行によりソフトウエア的に処理するように構成するようにしても勿論良い。このことは、携帯電話１および映像端末４でも同様で、それらの機能をハードウエアにより構成するだけでなくなく、プログラムの実行によりソフトウエア的に処理するように構成するようにしても勿論良い。
【００４６】
実施の形態２．（監視システムモデル）
実施の形態２では、本発明を利用した映像コンテンツ管理運用システムの事例として、映像監視システムを例に挙げてその構成について述べる。
【００４７】
図４に、本実施の形態における、映像監視システムのシステム構成を示す。
実施の形態２の映像監視システムは、図４に示すように、監視映像イベント検出サーバ３９と、監視映像集配信サーバ４９とから構成されており、これらと監視端末４０とが通信する。、監視映像イベント検出サーバ３９は、特徴量抽出処理部３４、メタデータサーバ３７と、アダプテーションヒントサーバ３８、ＲＣＭ作成部４３、および再生イベント決定部４５を有している。監視映像集配深部４９は、映像データサーバ３０、映像フォーマット判定部４７、および映像フォーマット変換部５１を有している。
以下、図４に示すシステムの、一連の動作を説明する。
【００４８】
▲１▼．監視映像蓄積・イベント抽出
映像データサーバ３０は、例えば、監視サービスセンター（図示せず）が運用するものであり、監視カメラ３１から伝送される監視映像を映像データ３２として蓄積する。勿論、監視カメラ３１は、１台でも複数台配置されていてもよい。映像データ３２に関連付けられて撮影条件情報３３も監視カメラ３１より送信されて蓄積される。撮影条件情報３３は、映像データ３２が撮影された日時・時刻の情報を含み、監視カメラ３１が複数台ある場合は、どのカメラかを識別する情報も含む。映像データサーバ３０は、映像データ３２、撮影条件情報３３を、監視映像イベント検出サーバ３９の特徴量抽出処理部３４に送出する。
【００４９】
監視映像イベント検出サーバ３９の特徴量抽出処理部３４は、映像データ３２、撮影条件情報３３を入力して、メタデータ３５、アダプテーションヒント３６を作成し、夫々をメタデータサーバ３７、アダプテーションヒントサーバ３８に蓄積する。メタデータ３５は、撮影条件情報３３、映像のシーン構造情報、映像データ３２中に発生するイベント、例えば映像特徴や音の抑揚に応じた監視映像内の他の映像シーンに対する特異性を、色、動き、音などのメディア特徴量で記述したデータの情報を含んでいる。また、アダプテーションヒント３６は、実施の形態１でも説明した通り、メタデータ３５に関連付けられていて、個々のメタデータ３５に実際にどのような内容、特に本実施の形態２ではイベントの内容が含まれているかを記述したメタデータ３５の要約情報である。
【００５０】
なお、映像データ３２を各カメラ３１のローカルな蓄積可能領域、例えばハードディスクなどに蓄積し、特徴抽出処理部３４の機能を当該カメラ３２の内部に含むように構成してもよい。この場合は、上記のイベント情報の検出に必要な特徴抽出処理を各カメラ３１で実施し、結果としてメタデータ３５およびアダプテーションヒント３６を出力するように構成されることになる。このような構成によれば、各カメラ３１内部の実装は複雑になるが、特徴抽出処理を行う目的での映像データ３２の伝送の手間を削減することができる。
【００５１】
▲２▼．監視映像イベント検出
監視映像イベント検出サーバ３９は、例えば監視サービスセンター（図示せず）が運用するものであり、監視端末４０が監視指定情報４１を送信すると、監視端末４０からその監視指定情報４１を受け取り、監視者ごとにカスタマイズされたＲＣＭ４２を監視端末４０に送出する。
【００５２】
監視指定情報４１は、ＲＣＭ４２を生成するためのトリガとなるクエリ情報であり、確認を行いたい監視カメラ３１を特定したり、確認したい記録時刻を指定する情報である。なお、監視指定情報４１は、監視者が明示的に情報を入力して送出するだけでなく、システムが監視端末４０の状態を自動的に検知して設定するように構成してもよい。例えば、イベントが発生した現場にガードマン等が携帯可能な監視端末４０をもって向かうケースを想定した場合には、システムが監視端末４０からのアクセス時刻を検知するとともに、ＧＰＳなどの位置計測システムによって特定される監視端末４０の現在位置に基づいてもっとも近くにある監視カメラ３１を自動的に特定するように構成してもよい。このように構成すれば、緊急時にガードマンが煩雑な端末操作を行うことなく、ガードマンが確認すべき現場のカメラで撮影されたイベントをＲＣＭ４２の情報として迅速に確認することが可能となる。
【００５３】
本実施の形態２で述べるような監視映像システムにおいては、日々、複数の監視カメラ３１で撮影された映像が映像データ３２として映像データサーバ３０に格納される。したがって、これらの監視映像アーカイブを効率よく管理・運用するため、特徴量抽出処理部３４においてメタデータ３５を生成し、個々の監視映像に関連付けておく。
【００５４】
ＲＣＭ作成部４３は、このように一つ一つが監視映像データに関連付けられた複数のメタデータ３５を入力として、アダプテーションヒント３６と、監視指定情報４１を用いてフィルタリングし、ＲＣＭ４２を作成、送出する。その際、ＲＣＭ作成部４３は、アダプテーションヒント３６に含まれるメタデータ３５の要約情報を用いて、不要なメタデータ３５の検索を防ぎ、検索を効率化できる。事例としては、例えば、アダプテーションヒント３６が記述すべき要約の項目として、監視映像中のイベントシーンを記述するための特徴量、例えば映像の色特徴や、動き特徴、音などが考えられる。具体的には、服装の色や、人物の動きの速さ、音の大きさ等の特徴量が考えられ、これらにより、例えば店舗内の不審者等を特定することが可能になる。類似イベントを他のカメラの映像も含めて確認を行いたい場合、類似イベントが色特徴によって特徴付けられるのであれば、アダプテーションヒント３６として映像中の色特徴記述子に関する要約情報を記述しておけばよい。
【００５５】
監視者は、監視端末４０によりＲＣＭ作成部４３からＲＣＭ４２を受け取ると、ＲＣＭ４２の情報として提供されるイベント発生区間の代表画像のサムネイルから再生したい画像を選択した再生映像指定情報の送信や、類似イベントとして検索したいイベントを表すサムネイルから検索したい画像を選択した検索キーの送信である再生映像指定情報・検索キー４４を再生イベント決定部４５に送信する。
【００５６】
再生イベント決定部４５は、再生映像指示情報・検索キー４４が再生映像指示情報である場合は、映像再生要求４６を映像フォーマット判定部４７に送信する。映像再生要求４６は、少なくとも、映像データ３２のロケータ情報と、その再生すべき時刻、例えば再生開始時刻や再生時間を含む。また、再生映像指示情報・検索キー４４が検索キーである場合、再生イベント決定部４５は、指定された監視カメラ３１の種類や時間区間などに含まれるすべてのメタデータ３５から、選択されたイベントに類似したイベントを含むメタデータ３５を検索する。この際、再生イベント決定部４５は、ＲＣＭ生成部４３と同様、アダプテーションヒント３６に含まれるメタデータ３５の要約情報を用いて、不要なメタデータ３５の検索を防ぎ、検索を効率化することができる。
【００５７】
▲３▼．映像データ配信要求・再生
監視端末４０は、映像データ配信要求をする場合、まず、端末情報４８を監視映像集配信サーバ４９に送出する。端末情報４８は、少なくとも、監視端末４０の表示解像度や、受信可能な画像フォーマット、例えばＭＰＥＧ−４、ＭＰＥＧ−２、Ｍｏｔｉｏｎ−ＪＰＥＧ、ＪＰＥＧ、Ｗｉｎｄｏｗｓ（登録商標）  Ｍｅｄｉａ  Ｖｉｄｅｏ，  ＤｉｖＸなどに関する情報を含む。監視端末４０は、監視映像集配信サーバ４９から送出される適応化映像データ５０を受信し、映像を再生する。適応化映像データ５０については後述する。監視端末４０としては、監視センタ内のＰＣでもよいし、ガードマンが携帯するＰＤＡ、ＰＣ、携帯電話などでもよい。
【００５８】
▲４▼．監視映像集配信サーバ
監視映像集配信サーバ４９は、例えば監視サービスセンター（図示せず）が運用するものであり、監視端末４０からの端末情報４８、再生イベント決定部４５からの映像再生要求４６の入力に基づき、指定再生開始時刻からの要求映像データ３２を、端末情報４８に記述された監視端末４０で再生可能な映像フォーマット、例えばＭＰＥＧ−４、ＭＰＥＧ−２、Ｍｏｔｉｏｎ−ＪＰＥＧ、ＪＰＥＧ、Ｗｉｎｄｏｗｓ（登録商標）  Ｍｅｄｉａ  Ｖｉｄｅｏ，  ＤｉｖＸなどに変換して、適応化映像データ５０を配信する。
【００５９】
映像フォーマット判定部４７は、監視端末４０から入力した端末情報４８に基づいて監視端末４０で再生可能なフォーマットを判定し、映像フォーマット変換部５１に対しフォーマット情報５２を送信する一方、映像データサーバ３０に対し映像再生要求４６に対応した映像データ３２のロケータ情報と、その再生開始時刻・再生時間等を指定した映像再生要求４６を送る。
【００６０】
映像データサーバ３０は、映像フォーマット判定部４７からの映像再生要求４６に対応した映像データ３２を映像フォーマット変換部５１に送信する。映像フォーマット変換部５１は、映像データサーバ３０からの入力映像データ３２のフォーマットを映像フォーマット判定部４７からのフォーマット情報５２に基づいて変換し、フォーマットに変換したものを適応化映像データ５０として監視端末４０に送信する。監視端末４０は、監視映像集配信サーバ４９から送信されてきた適応化映像データ５０を受信して再生する。
【００６１】
従って、本実施の形態２の映像監視システムによれば、監視カメラ３１から撮像した大量の映像データに対して、撮像時の条件情報とともに映像中で異常検知された箇所をイベントとしてメタデータ３５で統一的に管理することができ、所望の時刻や類似イベントを含む映像シーンに対して効率的にアクセスを行うことが可能となる。
【００６２】
特に、メタデータ３５は、すべてのイベントを記述しているので、映像再生機能を工夫することによって、イベント映像シーンのみを集約して高速再生したり、スキップ再生したりといった特殊再生機能も容易に実現できる。
【００６３】
また、映像再生端末の情報に基づいて伝送時の映像データフォーマットを自動的に変換することにより、監視センタ内の映像端末、現場に向かうガードマンが携帯する携帯端末、例えば映像再生機能付携帯電話やＰＤＡなどの端末種別にかかわらず、いつでもどこでも所望の映像シーンへの迅速なアクセスが可能となる。
【００６４】
なお、本実施の形態２では、監視映像イベント検出サーバ３９と、監視映像集配信サーバ４９とを別々のサーバで構成したが、勿論同一サーバで構成しても良い。また、監視端末４０は、映像の再生まで行うように説明したが、実施の形態１のように携帯電話１と映像端末４との別々の端末で構成しても勿論かまわない。
【００６５】
また、実施の形態１と同様に、ＲＣＭ作成部４３や特徴量抽出処理部３４、再生イベント決定部４５、映像フォーマット判定部４７等のコンテンツ購入サーバ２やコンテンツ配信サーバ３における処理は、ハードウエアにより構成するだけでなくなく、プログラムの実行によりソフトウエア的に処理するように構成するようにしても勿論良い。このことは、監視端末４０でも同様で、監視端末４０の機能をハードウエアにより構成するだけでなくなく、プログラムの実行によりソフトウエア的に処理するように構成するようにしても勿論良い。
【００６６】
【発明の効果】
以上説明したように、本発明によれば、映像コンテンツのメタデータ中にどのような情報が含まれているかを記述したメタデータ要約情報に基づいて、上記メタデータを選別するようにしので、映像コンテンツのメタデータのようにメタデータの量が莫大であっても、効率良く目的とするメタデータを抽出することができる。
【図面の簡単な説明】
【図１】実施の形態１のネット配信型コンテンツ提供サービスを実現する全体システム構成を示す図である。
【図２】実施の形態１で用いるメタデータの一実現例を示す図である。
【図３】実施の形態１で用いるコンテンツ購入券のデータフォーマットの一例を示す図である。
【図４】実施の形態２の映像監視システムの全体システム構成を示す図である。
【符号の説明】
１  携帯電話、２  コンテンツ購入処理サーバ、３  コンテンツ配信サーバ、４  映像端末、５  メタデータ、６  映像データ、７  アダプテーションヒント、８  ＲＣＭ作成部、９  ＲＣＭ、１０  購入要求、１１  購入処理部、１２  コンテンツ視聴券、１５  コンテンツ視聴ステイタス情報、１６  端末情報、１７  適応化映像データ、１８  映像フォーマット判定部、２０  映像フォーマット変換部、２１  映像データサーバ。
【図１】
2004247844.tif 000004
【図２】
2004247844.tif 000005
【図３】
2004247844.tif 000006
【図４】
2004247844.tif 000007