【事件の表示】
　特願２０００−１５１２１７「メディア処理システム及び方法」拒絶査定不服審判事件〔平成１３年　２月　９日出願公開、特開２００１−　３４５７６〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
１．手続の経緯
　本願の手続の経緯は次のとおりである。
出願　　　　　　　　　　平成１２年５月２３日（優先権主張１９９９年５　　　　　　　　　　　　月２７日、米国）
拒絶理由の通知　　　　　平成１５年１月７日（起案日、平成１４年１２月　　　　　　　　　　　　２４日）
意見書、補正書の提出　　平成１５年４月４日
拒絶査定　　　　　　　　平成１５年６月３０日（起案日、平成１５年６月　　　　　　　　　　　　２３日）
審判請求、補正書の提出　平成１５年９月２４日
　
２．平成１５年９月２４日付けの手続補正についての補正却下の決定
［補正却下の決定の結論］
　平成１５年９月２４日付けの手続補正を却下する。
［理由］
（１）補正後の本願発明
　前記手続補正により、特許請求の範囲の請求項１乃至請求項２５について、次のとおり補正された。
「【請求項１】
　一つ以上の処理アルゴリズムを検索されたデジタル・データに与え、要求に応えて一つ以上のメディア・ストリームを生成するメディア処理システムであって、
　要求を受け取るコントローラと、
　内部データ・バッファおよび待ち行列を含み、かつ前記要求に応答して検索されたデータの少なくとも一つのデータ・パスをフィルタ間の接続を規定するグラフを参照して生成し、前記少なくとも一つのデータ・パスを、一つ以上の処理アルゴリズムにもとづいて前記データを処理するための複数のフィルタから構成させる、少なくとも一つのデータポンプ・コンポーネントと、
　前記コントローラに応答してデータを処理するためのグラフを生成すると共に、前記データポンプ・コンポーネントに対してファイルを検索させて前記グラフにもとづいて前記少なくとも一つのデータ・パスを生成するように指令する、少なくとも一つのコンポーネントと、
　を備えることを特徴とするメディア処理システム。
　【請求項２】
　前記少なくとも一つのコンポーネントは、コントローラ・アプリケーションを備えることを特徴とする請求項１に記載のメディア処理システム。
　【請求項３】
　前記少なくとも一つのコンポーネントは、グラフ管理プログラム・コンポーネントを含むことを特徴とする請求項１に記載のメディア処理システム。
　【請求項４】
　さらに、少なくとも一つのコントローラ・アプリケーションを含み、前記グラフ管理プログラム・コンポーネント及び前記少なくとも一つのコントローラ・アプリケーションの一つは前記データポンプ・コンポーネントに指示する請求項３に記載のメディア処理システム。
　【請求項５】
　さらに、データを処理するためのグラフを事前に定めるためのグラフ・キャリブレーション・コンポーネントを含むことを特徴とする請求項１に記載のメディア処理システム。
　【請求項６】
　前記グラフ・キャリブレーション・コンポーネントは、さらにグラフを評価するためのコンポーネント手段と前記グラフを完成させるためのデータポンプ必要条件を決定するためのコンポーネント手段とを有することを特徴とする請求項５に記載のメディア処理システム。
　【請求項７】
　一つ以上の処理アルゴリズムを検索されたデジタル・データに与え、要求に応えて一つ以上のメディア・ストリームを生成するメディア処理システムのための方法であって、
　要求を受け取るステップと、
　前記要求に応じてデータを処理するためのデータ・パスを規定するフィルタ間のグラフを生成するステップと、
　前記要求に応答して検索されたデータの少なくとも一つのデータ・パスをフィルタ間の接続を規定するグラフを参照して生成し、前記少なくとも一つのデータ・パスを内部データ・バッファおよび待ち行列を使用して一つ以上の複数のデータ処理フィルタから構成するステップと、
　を有することを特徴とするメディア処理システムの方法。
　【請求項８】
　前記グラフを生成するステップは、所定のグラフを検索するステップが含まれることを特徴とする請求項７に記載の方法。
　【請求項９】
　前記動的に少なくとも一つのデータ・パスを生成するステップは、複数のフィルタを検索し、前記フィルタを接続するステップが含まれることを特徴とする請求項７に記載の方法。
　【請求項１０】
　前記フィルタを接続するステップは、
　前記複数のフィルタの一つに対する出力ポートと前記複数のフィルタの次に続くひとつに対する入力ポートとを識別するステップと、
　前記出力ポートに対する接続属性を決定するステップと、
　前記入力ポートに対して前記接続属性を転送するステップと、
　前記接続に対する承認を得るステップと、
　を有することを特徴とする請求項９に記載の方法。
　【請求項１１】
　前記入力及び出力ポートの各々は所有フィルタに対応付けられ、前記接続に対して前記承認を得るステップは、
　所有フィルタに対して前記入力ポートが接続属性を転送するステップと、
　前記入力ポートに対する応答を前記所有フィルタが伝えるステップと、
　前記出力ポートに対して前記入力ポートが制御を返すステップと、
　を有することを特徴とする請求項１０に記載の方法。
　【請求項１２】
　さらに、前記接続が完了したかを前記出力ポートが確かめるステップを有することを特徴とする請求項１１に記載の方法。
　【請求項１３】
　さらに、前記接続に対して、少なくとも一つの別の出力ポートと少なくとも一つの別の入力ポートとを識別するステップを有することを特徴とする請求項１１に記載の方法。
　【請求項１４】
　さらに、前記フィルタ及び接続されたポートが前記データ・パスに沿って処理することが可能なデータ・フローを表す所定のデータ・フロー・モデルを得るために、前記データ・パスを特徴付けるステップを有することを特徴とする請求項９に記載の方法。
　【請求項１５】
　さらに、前記データ・パスに沿って転送するためにデータ・パケットを集めるステップを有することを特徴とする請求項７に記載の方法。
　【請求項１６】
　さらに、前記データ・パスを沿って転送するために複数のデータ・パケットをつなげるステップを有することを特徴とする請求項１５に記載の方法。
　【請求項１７】
　前記データ・パスはソース・ノード・フィルタで開始されるもので、さらに前記方法は前記ソース・ノード・フィルタに対して前記所定のデータ・フロー・モデルを与えるステップを有することを特徴とする請求項１４に記載の方法。
　【請求項１８】
　さらに、前記所定のデータ・フロー・モデルにもとづいて前記ソース・ノードがデータ・パケットを集めるステップを有することを特徴とする請求項１７に記載の方法。
　【請求項１９】
　複数の処理フィルタとコネクタとを持つデータ・パスに沿って転送するための検索実体によって検索されたデータのフローの管理を提供する方法であって、
　前記複数の処理フィルタ及びコネクタの各々を問い合わせ、処理フィルタおよびコネクタからグラフを作成し、所定のデータ・フロー・モデルを得るステップと、
　前記検索実体に対して前記所定のデータ・フロー・モデルを提供するステップと、
　前記所定のデータ・フロー・モデルにもとづいて検索されたデータを集め、内部データ・バッファに格納し、待ち行列を使用してデータ・パスに提供するステップと、
　を有することを特徴とする方法。
　【請求項２０】
　複数の処理フィルタとコネクタとを持つデータ・パスに沿って転送するために検索されたデータのフローに対する管理を提供するシステムあって、
　前記複数の処理フィルタ及びコネクタの各々を問い合わせ、処理フィルタおよびコネクタからグラフを作成し、所定のデータ・フロー・モデルを得るための問い合わせコンポーネントと、
　前記所定のデータ・フロー・モデルにもとづいて検索されたデータを集め、内部データ・バッファに格納し、待ち行列を使用してデータ・パスに提供する検索実体と、
　を有することを特徴とするシステム。
　【請求項２１】
　メディア・ストリームの分散制御を提供するための方法であって、
　複数の処理フィルタと、前記複数の処理フィルタの各々に対応して少なくとも一つの入力ポート及び少なくとも一つの出力ポートと、前記入力ポート及び前記出力ポートに接続する複数のパイプとを有し、前記複数のパイプの各々は、メディア・ストリームにおいてデータ及び制御情報を送受信することが可能なインテリジェント・インタフェースを有し、制御チャンネルとデータ・チャンネルとを持つデータ・パスを生成するステップと、
　前記データ・チャンネルに沿って内部データ・バッファおよび待ち行列を使用して内部データ・バッファに格納されたデータを提供するステップと、
　前記データ・パスの前記出力チャンネルに対して複数の制御コマンドを与えるステップとを有し、さらに、
　前記フィルタの各々が適合して実行するステップは、
　前記フィルタによって実行される前記複数の制御コマンドから少なくとも一つのコマンドを選択するステップと、
　前記選択された制御コマンドの各々を完了するステップと、
　前記データ・パスを通して前記選択されたコマンドの完了の通知を伝えるステップと、
　前記複数のコマンドのなかで選択されていないコマンドの各々を前記複数のフィルタの他のものによって実行されるように上流方向に沿って転送するステップと、
　を有することを特徴とする方法。
　【請求項２２】
　さらに、前記複数の制御コマンドの少なくとも一つにもとづいて前記データにフラグを立てるステップを有することを特徴とする請求項２１に記載の方法。
　【請求項２３】
　さらに、前記フィルタ及び接続されたポートが前記データ・パスに沿って処理されることが可能である前記データ・フローを表す所定のデータ・フロー・モデルを得るために、前記データ・パスを特徴付けするステップを有することを特徴とする請求項２１に記載の方法。
　【請求項２４】
　前記データ・パスはソース・ノード・フィルタで開始され、前記方法はさらに、前記ソース・ノード・フィルタに対して前記所定のデータ・フロー・モデルを提供するステップを有することを特徴とする請求項２３に記載の方法。
　【請求項２５】
　前記所定のデータ・フロー・モデルにもとづいて前記データ・パケットを前記ソース・ノードが集める工程を有することを特徴とする請求項２４に記載の方法。」
　
　前記補正は、該当請求項に記載した発明を特定するために必要な事項である、補正前の請求項１の、「データポンプ・コンポーネント」「少なくとも一つのコンポーネント」、請求項４の「データ・ポンプ」、請求項７の「グラフを生成するステップ」「一つ以上の複数のデータ処理フィルタから構成するステップ」、請求項１９の「複数の処理フィルタ及びコネクタの各々を問い合わせるステップ」「検索されたデータを集めるステップ」、請求項２０の「問い合わせコンポーネント」「検索実体」、請求項２１の「「データ・チャンネルに沿ってデータを提供するステップ」にそれぞれ限定を加えるものであると認められるから、特許請求の範囲の減縮を目的とするものにあたる。
　そこで、前記特許請求の範囲についてされた補正について、前記請求項１に記載された発明（以下、「本願補正発明」という。）が、特許出願の際独立して特許を受けることができるものであるか（特許法第１７条の２第５項において第４項２号の場合に準用する同法第１２６条第４項の規定に適合するか）について検討する。
　
（２）引用例の発明
　原審の拒絶の理由に引用された、本願優先権主張日前に頒布された刊行物である、特開平７−５６７５４号公報（以下「刊行物１」という。）には、次の事項が記載されている。
Ａ．「【００１３】
【発明が解決しようとする課題】
　上述のように、従来技術はマルチメディア要求の多様性を完全に統合しない。従って、本発明の目的は、システム資源へのアクセスを要求する複数のマルチメディア装置または装置グループに、マルチメディア・コンピュータ資源を正確に、効率的に且つタイムリに割当てることである。
【００１４】本発明の別の目的は、コンピュータ資源を要求し、割当てる集中型エンティティ及び発見的（heuristic）プロシージャを提供することである。
【００１５】本発明の他の目的は、ユーザ定義パラメータと同様に、特定のマルチメディア装置制限の知識が、コンピュータ資源選択プロセスと統合されることを可能とすることである。
【００１６】本発明の他の目的は、システム資源を適切に割当てるグラフ・タイプのデータ・フロー構造を提供することである。
…（中略）…
【００１８】
【課題を解決するための手段】
　本発明は、システム・コンピュータ資源をマルチメディア・オブジェクトまたはプロセスを要求するグループに割当てる技術について述べる。要素グループまたはユーザにより課せられる要素から、特定のデータ処理要素の制約に関する全ての知識を収集することにより、コンピュータ資源の効果的な割当てが実現される。
【００１９】集中型グラフ・データ・フロー構造は収集される制約情報を表し、横断されるデータ・フロー・パスを適切に構成し、それにより各要求要素が順序化される。集中型知識を有するエンティティを有することにより、オブジェクトはお互いに関して知る必要性、或いはお互いに特定的にコード化される必要性から解放される。１度特定のグラフ構造が知られると、それらは記憶及び処理のために単純な形式に展開される。」（【００１３】〜【００１９】段落）
Ｂ．「【００２１】最適なマルチメディア・コンピュータ資源割当てを獲得するために、処理要素（オブジェクト）要求がタイプによりグループ化される。グループ化が有用なよい例に、図１に示される電子会議がある。…（中略）…マルチメディア・プロセス及びオブジェクトのグループに対するコンピュータ資源の割当ては、しばしばシステム制約及びユーザ制約または制限に依存する。これらの制約が無視されると、究極的には最低の資源割当てが発生する。本発明のシステムは、各装置、装置グループまたはアプリケーションに密接に関係する特定の制約情報を収集し、集中型管理エンティティを形成する。これは本願では資源マネージャとして参照される。」（【００２１】段落）
Ｃ．「【００２２】制約の収集プロシージャは、ユーザが特定の装置またはプログラムの選択により、受動的に資源割当てに制約を設定する時に開始する。エンドユーザは資源ニーズに関し、できる限り意識しないものとする。ユーザは実行する任意のアプリケーションを選択することにより、資源制約に関する判断を下す。例えば、ユーザがサーバから映画の実演を選択する場合、一連の制約が意味される。…（中略）…幾つかの場合では、ユーザは、自身が使用するビデオ品質（例えば１秒当たりのフレーム数及びフレーム・サイズ）を要求するためのビデオ制御パネルなどの他の制御を有する。」（【００２２】段落）
Ｄ．「【００２３】選択アプリケーションは判断が下される重要な場所である。…（中略）…ここでサーバからの映画の実演は、短い遅延を意味するものではなく、高品質のデリバリがより重要であることを意味することに注意されたい。アプリケーションは資源使用を制限する上記例以外の特定の要求をする可能性もあり、従って、上記例に制限されるべきではない。
【００２４】実際のマルチメディア・オブジェクトまたはプロセスが、次に実際の資源利用に関する詳細を計算するために、アプリケーション、性能に関するその制約、及びユーザにより提供される制約を使用する役割を担う。映画を実演するためには、バッファリング及びジッタの除去のために多額の費用が要求される。ビデオ会議の実施においては、少量のバッファだけが要求されるが、ＣＰＵ時間の獲得が非常に重要である。
【００２５】アプリケーションは優先順位について認識し、それらを全てのタイプの要求に対して設定するように期待される。資源割当てのための任意の要求は、優先順位が特定の制約に提供されるように要求できる。これに対する一般的例として、端末間遅延限界を指定する他に、アプリケーションは遅延が資源割当てにおける最も重要な要因と見なされるように要求できる。こうして、優先順位がアプリケーションにより資源タイプに設定される。更に、様々なオブジェクトのユーザ詳細を示す制御パネル・アプリケーションが作成される。ユーザはネットワーク優先順位を制御可能であるか、或いは相対優先順位をアプリケーションに割当てることができる。このような制御パネルにより、ユーザは警報ブザーがムード音楽プレイヤよりも高い優先順位を有するように設定することができ、システムはこれを認識する。」（【００２３】〜【００２５】段落）
Ｅ．「【００２８】グラフ・マネージャ：一般的システムにおいて、遅延及び他のマルチメディア基本制約の問題を解決する最小限度の方法は、少なくとも割当てに関連する全てのオブジェクトのリストを有する中央エンティティを提供することである。このリストは考慮されるオブジェクトのグループを含む。中央エンティティは次に各処理要素が留意されたかどうかを確認し、各要素に留意するために要する正確な時間を待機することができる。
【００２９】遅延に関連する問題を解決するための最良の方法は、グラフ・マネージャと呼ばれる十分に成長した中央エンティティを導入することである。このグラフ・マネージャはグループ化されるオブジェクトのリストだけでなく、オブジェクト間の接続性についても認識する。これは命令される順序化及び共通グループの自動検出を考慮する。データ・ストリームにおける各オブジェクトまたはプロセスの生成及び破壊がグラフ・マネージャに報告される。これはオブジェクト自身、またはそのオブジェクトのクライアントとして動作するアプリケーションにより実行される。好適な実施例では、グラフに相互接続される全てのオブジェクトを自動的にグループ化することによりこれを達成する。これは明示的にオブジェクトをグループ化する必要性からアプリケーションを解放する。
【００３０】グラフにデータ・フローの知識を盛り込むことにより、グラフ・マネージャはグラフの横断を実行し、各ノードまたはエッジが任意のオペレーションにおいて考慮された時期を知る。このグラフ構造の知識無しでは、全てのオブジェクトがオペレートされた時期を知ることは容易ではない。グラフ・マネージャはグラフを横断するように通知され、グラフの各ノードまたはエッジに対してオペレーションを実行する。マルチメディア・データ・ストリームにおける最も一般的な種類の横断は、データの出所からデータの消費側への横断である。この種の横断はコンピュータ資源の予約において特に有用である。」（【００２８】〜【００３０】段落）
Ｆ．「【００３３】図２はオーディオとビデオの両方を含む典型的な映画のプレイバックを表す。用語グラフ理論が上記図の情報を用いて説明され、また図３に表される。図３はノード及びエッジを含む単純なグラフを示す。便宜上、ノードはオーディオまたはビデオ・デコーダなどの処理ポイントであり、エッジはオーディオ及びビデオ・データの混合パスなどの接続性のタイプとする。」（【００３３】段落）
Ｇ．「【００３５】グラフを構成するノード及びエッジの収集は、記憶装置内において配列及びリンク構造などの多くの方法により表される。グラフは、通常、全てのノードが訪問されることを確認する目的で、データ・フロー・パスを横断するために使用される（しばしば特定の順序による）。
…（中略）…
【００３６】図４は映画ミキサの一般的グラフを示す。２つの映画が一緒に混合され、記憶され、編集ワークステーション上に表示されるためにデコードされる。」（【００３５】〜【００３６】段落）
Ｈ．「【００３９】次に図３及び図４において見い出される映画グラフを用いる例について説明する。
【００４０】ステップ１：アプリケーションはデータ処理のためにデバイス'Ａ'を生成する。デバイス'Ａ'はその存在をグラフ・マネージャに報告する。好適な実施例では、これはデバイス・オープン通知（OpenDeviceNotify）により実行される。
【００４１】ステップ２乃至４：デバイス'Ｂ'、'Ｃ'及び'Ｄ'を生成するためにステップ１を繰返す。デバイス生成の順序は重要でない。
【００４２】ステップ５：アプリケーションはデバイス'Ａ'及び'Ｂ'の間で接続'１'を生成する。接続'１'はその存在（及び接続方法の詳細）をグラフ・マネージャに報告する。好適な実施例では、これは接続オープン通知（OpenConnectionNotify）により実行される。
【００４３】ステップ６乃至７：接続'２'及び'３'を生成するためにステップ５を繰返す。接続生成の順序は重要でない。
【００４４】ステップ８：この時点で、グラフ・マネージャはグラフに関する全てを知る。アプリケーションは貴重と見なすグラフ上のあらゆるオペレーションを実行することができる。ここでは基本オペレーションは資源割当てである。これはデバイス準備（PrepareDevice）ファンクションにより実行される
【００４５】オブジェクトに対して実行される時には、ステップは逆転されるべきである。
【００４６】ステップ９：アプリケーションは様々なオブジェクトを切断する。本システムでは、これは接続オブジェクトを破壊することにより実行され、その結果、接続クローズ通知（CloseConnectionNotify）がグラフ・マネージャにより求められる。
【００４７】ステップ１０：アプリケーションは様々なデバイス・オブジェクトを破壊する。本システムでは、デバイス・クローズ通知（CloseDeviceNotify）がグラフ・マネージャにより求められる。」（【００３９】〜【００４７】段落）
Ｉ．「【００４８】資源マネージャ：グラフ・マネージャにより全ての要求が収集されたと判断されると、資源マネージャは資源割当てに関する様々な制約の均衡を取り、成功一致を提案しようと試みる。
…（中略）…
【００５０】制約がシステム上で使用可能な資源に適合すると、資源マネージャはその時、資源を様々なオブジェクトに割当てる。」（【００４８】〜【００５０】段落）
Ｊ．「【００６２】図６により、本発明の主要オブジェクトはデバイス（論理システム・デバイスを表す）と呼ばれ、ＩＤにより識別される。デバイス・オブジェクトはデバイス・オープン通知（OpenDeviceNotify）及びデバイス・クローズ通知（CloseDeviceNotify）ファンクションを用いる。デバイスは下記のグラフ説明において、ノードとして使用される。
【００６３】他の重要なオブジェクトは接続と呼ばれる。これらについてもＩＤにより識別されるが、グラフ・マネージャは、どのデバイスＩＤが接続の開始及び終わりに関連付けられるかを伝達される必要がある（なぜなら接続は方向を有するからである）。それに加え、本発明ではデバイス上のポート或いは接続ポイントの概念を有し、この情報もまた接続がオープンされる時に伝達される必要がある。
【００６４】デバイス及び接続オープン及びクローズ通知を使用することにより、グラフ・マネージャは、ユーザまたは他のアプリケーションに関連することなく、グラフ間の全ての接続性を追跡可能となる。明示的に接続されないオブジェクトが、あるオペレーションにおいてグループ化されると見なされることが必要な場合には、追加のインタフェースが提供される。グループ・オープン通知（OpenGroupNotify）ファンクションがグループ生成のために使用される。グループ生成時に、デバイスを生成及び接続しているアプリケーション・プログラムが、グループ化したいデバイスのリストを指定する。上述のように、デバイスはＩＤにより識別される。この概念は、未接続のグラフが単一の資源予約または他のオペレーションにおいて考慮される必要がある場合、強力且つ有用である。」（【００６２】〜【００６４】段落）
Ｋ．「【００６６】１．ユーザがアプリケーションを開始する。
２．アプリケーションがオブジェクト（デバイス）のセットを生成し、それらを所望されるように接続する。このプロセスの間、グラフ・マネージャは接続情報を収集する。
３．アプリケーションが資源割当てを要求する。これはグラフ・マネージャを呼出して予約をさせ、次に資源の割当てを実行させる。
４．グラフ・マネージャは資源マネージャからフローＩＤ（FlowID）を要求する。この識別子は、このグラフまたはグループ内のオブジェクトからの全ての予約及び割当てにおいて使用される。
５．グラフ・マネージャは将来使用のために、各オブジェクトから制御値定義を収集する。
６．グラフ・マネージャはシステムにより要求される順序により、グラフを横断する。これは、通常、データ・ストリームの開始から終りに向かう。
ａ．第１のオブジェクトが、資源マネージャから要求する必要のある任意の資源を要求すべきであることを示す通知と一緒に、呼出される。
ｂ．オブジェクトは資源を要求するために、資源マネージャ上のレジスタ・ファンクションを呼出す。資源マネージャはこのタスクを実行するために資源制御装置を使用する。
ｃ．グラフまたはグループ内の互いのデバイス・オブジェクトに対して、ステップ'ａ'及び'ｂ'が繰返される。
７．グラフ・マネージャは資源を均衡化するために、資源マネージャを呼出す。失敗が発生すると資源マネージャは失敗した資源タイプのリストを返却する。グラフ・マネージャが次に適切な制御値を変更する。資源タイプに適切な制御値が存在しない場合、資源割当ては失敗を返却する。少なくとも１つが変更される場合には、ステップ６に戻り再試行する。資源の予約は実際にそれらを使用中（inuse）と記すが、それらを割当てない。
８．成功予約が達成されると、グラフ・マネージャは（ステップ６と同様の横断において）各オブジェクトを呼出し、許可された資源の受諾を確認させる。任意のオブジェクトが許可された資源に同意しない場合、資源割当ては失敗する。
９．グラフ・マネージャは資源を割当てるために、（ステップ６と同様の横断において）各オブジェクトを呼出す。各オブジェクトは資源マネージャの資源獲得（GetResources）ファンクションを用いて、実際に資源を割当て、資源に関する情報をオブジェクトに返却する。資源マネージャは資源制御装置を用い、このタスクを実行する。
１０．資源割当てが完了し、グラフ・マネージャは資源マネージャを呼出し、フローＩＤを解放する。
１１．システムは他のタスクに要求される全てのことを実行する。例えば、ウィンドウ内に映画を表示したりする。
１２．アプリケーションが資源の割当て解除を要求する。これによりグラフ・マネージャが割当て解除を実行する。
１３．グラフ・マネージャは（ステップ６と同様の横断において）各オブジェクトを呼出す。各オブジェクトは資源マネージャの資源解放（FreeResources）を用い、その資源を割当て解除する。資源マネージャは資源制御装置を用い、タスクを実行する。」（【００６６】段落）
　
（ア）刊行物１のマルチメディア・システムは、Ｃ．の記載を参照すると、ユーザがサーバから映画の実演を選択する場合に、実行する任意のアプリケーションを選択し、ビデオ品質などの要求をするものであり、この選択乃至要求は、要求であり、Ｅ．の記載を参照すると、マルチメディア・データ・ストリームのデータ出所からデータ消費側への横断があることから、前記ユーザからの選択（要求）に応えて一つ以上のメディア・ストリームを生成するメディア処理システムであることが読み取れる。マルチメディア・システムの内部では、図２、図３、図４と、前記Ａ．Ｇ．の記載を参照すると、映画データのソースからの映画データに対して、処理ポイントである、ミキサ、デコーダにおいて、それぞれ、２つの映画データが一緒に混合され、記憶され、編集ワークステーション上に表示されるためにデコードされ、これらの混合やデコードの処理においては、それぞれの処理アルゴリズムを映画データに与えるシステムであることが読み取れる。
（イ）刊行物１のマルチメディア・システムは、制御部（コントローラ）を有することは自明であり、Ｄ．の記載を参照すると、システムはアプリケーションの資源使用を制限する要求、アプリケーションによる資源タイプへの設定、制御パネルによる設定をシステムが認識する旨記載されており、このコントローラを有するシステムが前記設定を認識することは、コントローラを有するシステムが要求を受け取ることであるといえる。
（ウ）刊行物１には、Ａ．の記載を参照すると、システム資源を適切に割当てるグラフ・タイプのデータ・フロー構造を提供するための、システム・コンピュータ資源をマルチメディア・オブジェクトまたはプロセスを要求するグループに割当てる技術について、要素グループまたはユーザにより課せられる要素から、特定のデータ処理要素の制約に関する全ての知識を収集することにより、コンピュータ資源の効果的な割当てが実現されること、集中型グラフ・データ・フロー構造は収集される制約情報を表し、横断されるデータ・フロー・パスを適切に構成することにより各要求要素が順序化される旨記載され、Ｂ．の記載を参照すると、処理要素（オブジェクト）要求がタイプによりグループ化され、Ｅ．の記載を参照すると、グラフ・マネージャはグループ化されるオブジェクトのリストだけでなく、オブジェクト間の接続性についても認識し、グラフに相互接続される全てのオブジェクトを自動的にグループ化する旨記載され、Ｇ．の記載を参照すると、グラフを構成するノード及びエッジの収集は、配列及びリンク構造などの方法により表され、グラフは、通常、全てのノードが訪問されることを確認する目的で、データ・フロー・パスを横断するために使用される旨記載されている。
　前記オブジェクト間の接続性、処理要素の制約はオブジェクト間の接続の規定と換言でき、処理要素（オブジェクト）要求が、タイプによりグループ化され、このグループ化は、前記グラフに相互接続される全てのオブジェクトがグループ化され、且つ、グラフは全てのノードが訪問されることを目的としてデータ・フロー・パスを横断するために使用され、このグラフを使用してデータ・フロー・パスを横断する旨の点は、グラフを参照してデータ・フロー・パスを生成することと換言できる点を踏まえると、前記グラフ・タイプのデータ・フロー構造に関し、要求に応答してデータの少なくとも一つのデータ・フロー・パスを、オブジェクト間の接続を規定するグラフを参照して生成することが読み取れる。
　また、前記グラフに相互接続されるオブジェクトは処理要素であり、この処理要素は、Ｆ．Ｇ．Ｊ．の記載と図４を参照すると、論理デバイスであり、ミキサ、デコーダなどのオブジェクト（処理要素）であり、それぞれのオブジェクト（処理要素）がそれぞれの処理アルゴリズムにもとづいてデータを処理するメソッドをもつことは自明であり、さらに、Ｄ．の記載を参照すると、マルチメディア・オブジェクトまたはプロセスはバッファリングのための費用が要求されるとあり、バッファを備えることが示されることから、前記グラフ・タイプのデータ・フロー構造にはデータ・バッファを含むことが読み取れる。
　これらを踏まえると、データ・バッファを含み、要求に応答してデータの少なくとも一つのデータ・フロー・パスをオブジェクト（処理要素）間の接続を規定するグラフを参照して生成し、前記少なくとも一つのデータ・フロー・パスを、一つ以上の処理アルゴリズムにもとづいて前記データを処理するための複数のオブジェクト（処理要素）から構成させる、少なくとも一つのグラフ・タイプのデータ・フロー構造が示されている。
（エ）刊行物１には、アプリケーションとグラフ・マネジャについて、Ｈ．Ｋ．の記載を参照すると、アプリケーションはオブジェクトのセットを生成し、接続を生成して、グラフ・マネジャに報告し、グラフ・マネージャはグラフに関する全てを知る旨記載され、Ｉ．Ｋ．の記載を参照すると、アプリケーションは、資源割当てを要求し、グラフ・マネージャを呼び出して、グラフ・マネージャが資源マネージャからフローＩＤを要求し、資源マネージャは様々な制約の均衡を取り、資源を様々なオブジェクトに割当て、グラフ・マネージャはシステムにより要求される順序によりグラフを横断する旨記載されており、これらの記載から、前記システム（コントローラを有するシステム）に応答してデータを処理するためのグラフを生成すると共に、前記グラフ・タイプのデータ・フロー構造に対して前記グラフにもとづいて前記少なくとも一つのデータ・フロー・パスを生成するように指令する、アプリケーションとグラフ・マネジャが示されている。
　
　以上の点を踏まえると、刊行物１には、マルチメディア要求の多様性を統合するための次の発明（以下「刊行物１の発明」という。）が開示されていると認められる。
「一つ以上の処理アルゴリズム（例えば、デコード）をデジタル・データに与え、ユーザからの選択（要求）に応えて一つ以上のマルチメディア・ストリームを生成するマルチメディア処理システムであって、
　要求を受け取るコントローラを有するシステムと、
　データ・バッファを含み、要求に応答してデータの少なくとも一つのデータ・フロー・パスをオブジェクト（処理要素）間の接続を規定するグラフを参照して生成し、前記少なくとも一つのデータ・フロー・パスを、一つ以上の処理アルゴリズムにもとづいて前記データを処理するための複数のオブジェクト（処理要素）から構成させる、少なくとも一つのグラフ・タイプのデータ・フロー構造と、
　前記コントローラを有するシステムに応答してデータを処理するためのグラフを生成すると共に、前記グラフ・タイプのデータ・フロー構造に対して前記グラフにもとづいて前記少なくとも一つのデータ・フロー・パスを生成するように指令する、アプリケーションとグラフ・マネジャと、
　を備えるマルチメディア処理システム」
　
　同じく、原審の拒絶の理由に引用された、本願優先権主張日前に頒布された刊行物である、特表平９−５０３３２１号公報（以下「刊行物２」という。）には、次の事項が記載されている。
ａ．「発明の概要
　以上に鑑みて、本発明の主目的は、マルチメディア・プレゼンテーションが進行している過程で、ストレージ（記憶装置）とディスプレイ（表示装置）を備えたコンピュータを使用してマルチメディア・データをルーチング（routing−経路指定）するシステムと方法を提供することである。接続されたディスプレイ、ストレージおよびマルチメディア・デバイスを備えたプロセッサは、マルチメディア情報をやりとりするための少なくとも１つのポートを含んでいるマルチメディア・デバイスを管理するためのコンポーネント・オブジェクトをプロセッサのストレージ内に作成する。プロセッサは、前記少なくとも１つのポートをマルチメディア・デバイスに結合してマルチメディア情報のやりとりを容易化する結合オブジェクトを含んでおり、プロセッサはマルチメディア・デバイスとコンポーネント・オブジェクト・ポートとの間で情報を転送する。」（第６頁６行〜１７行）
ｂ．「オーディオ・ポート間のコネクションはオーディオ・データのバッファを使用して実現されている。各コネクション、つまり「パッチ・コード」はそれと関連付けられたバッファをもっている。オーディオ・プロセッサはそのオーディオ・ポートの各々に対して、そのバッファのアドレスとサイズを要求することができる。図１４はデータをその入力バッファから読み取り、そのデータを処理し、その結果をその出力バッファに書き出す関連のＲｕｎ（）メンバ関数をもつオーディオ・プロセッサ・アーキテクチャを示すブロック図である。」（第２５頁下８行〜下１行）
　
　ａ．ｂ．の記載と図１４を参照すると、刊行物２には、オーディオ・ポート間のコネクションはオーディオ・データのバッファを使用して実現され、オーディオ・プロセッサはそのオーディオ・ポートの各々に対して、そのバッファのアドレスとサイズを要求することができ、データをその入力バッファから読み取って処理し、処理した結果をその出力バッファに書き出す技術が記載されている。
　
（３）対比
   本願補正発明と刊行物１の発明とを対比すると、
（ａ）刊行物１の発明の、「一つ以上の処理アルゴリズム（例えば、デコード）をデジタル・データに与え、ユーザからの選択（要求）に応えて一つ以上のマルチメディア・ストリームを生成するマルチメディア処理システム」は、デジタル・データが検索されたものではないが、本願補正発明の「検索されたデジタル・データ」も上位概念ではデジタル・データであるから、刊行物１の発明と本願補正発明とは「一つ以上の処理アルゴリズムをデジタル・データに与え、要求に応えて一つ以上のメディア・ストリームを生成するメディア処理システム」である点では一致する。
（ｂ）刊行物１の発明の、「要求を受け取るコントローラを有するシステム」は、本願補正発明の「要求を受け取るコントローラ」と実質的な差異はない。
（ｃ）刊行物１の発明の、「データ・バッファを含み、要求に応答してデータの少なくとも一つのデータ・フロー・パスをオブジェクト（処理要素）間の接続を規定するグラフを参照して生成し、前記少なくとも一つのデータ・フロー・パスを、一つ以上の処理アルゴリズムにもとづいて前記データを処理するための複数のオブジェクト（処理要素）から構成させる、少なくとも一つのグラフ・タイプのデータ・フロー構造」は、該データ・バッファは内部データ・バッファとまではいえないが上位概念ではデータ・バッファであり、複数のオブジェクト（処理要素）は、マルチメディアのデータストリームに対して等時性の異なる処理（図４のデコーダ、ミキサ参照）を行う複数の処理ブロックと見ることができるので、フィルタに相当し、前記グラフ・タイプのデータ・フロー構造の機能は、データポンプ・コンポーネント（データポンプ・コンポーネントは本願優先権主張日前に周知であり、例えば、特開平９−２３３０６３号公報【００２４】、【００３９】〜【００４０】段落、図３には、マルチメディアデータを形成するビットストリームに関し、データポンプはディスクとネットワークとの間に最適なデータパスを設定する旨記載されている。）の機能と実質的な差異はなく、これらの点をふまえると、本願補正発明の「データ・バッファを含み、かつ前記要求に応答してデータの少なくとも一つのデータ・パスをフィルタ間の接続を規定するグラフを参照して生成し、前記少なくとも一つのデータ・パスを、一つ以上の処理アルゴリズムにもとづいて前記データを処理するための複数のフィルタから構成させる、少なくとも一つのデータポンプ・コンポーネント」と共通する。
（ｄ）刊行物１の発明の、「前記コントローラを有するシステムに応答してデータを処理するためのグラフを生成すると共に、前記グラフをデータがストリームする役割を担う機能部分に対して前記グラフにもとづいて前記少なくとも一つのデータ・フロー・パスを生成するように指令する、アプリケーションとグラフ・マネジャ」は、本願補正発明の「前記コントローラに応答してデータを処理するためのグラフを生成すると共に、前記データポンプ・コンポーネントに対して前記グラフにもとづいて前記少なくとも一つのデータ・パスを生成するように指令する、少なくとも一つのコンポーネント」と共通する。
　したがって、刊行物１の発明と本願補正発明とは、次の構成を有する発明である点では一致し、そして、次の点で相違している。
〈一致点〉
「一つ以上の処理アルゴリズムをデジタル・データに与え、要求に応えて一つ以上のメディア・ストリームを生成するメディア処理システムであって、
　要求を受け取るコントローラと、
　データ・バッファを含み、かつ前記要求に応答してデータの少なくとも一つのデータ・パスをフィルタ間の接続を規定するグラフを参照して生成し、前記少なくとも一つのデータ・パスを、一つ以上の処理アルゴリズムにもとづいて前記データを処理するための複数のフィルタから構成させる、少なくとも一つのデータポンプ・コンポーネントと、
　前記コントローラに応答してデータを処理するためのグラフを生成すると共に、前記データポンプ・コンポーネントに対して前記グラフにもとづいて前記少なくとも一つのデータ・パスを生成するように指令する、少なくとも一つのコンポーネントと、
　を備えることを特徴とするメディア処理システム」
　
〈相違点１〉デジタル・データが、本願補正発明は「検索された」デジタル・データであるのに対し、刊行物１の発明は、そのような構成を備えていない点。
〈相違点２〉データポンプ・コンポーネントにおけるデータ・パスに関して、本願補正発明は、「内部データ・バッファおよび待ち行列を含み」、且つ、「検索されたデータ」のデータ・パスであるのに対し、刊行物１の発明は、データ・バッファを含むものの、内部データ・バッファおよび待ち行列を含み、且つ、検索されたデータのデータ・パスであることは開示されていない点。
〈相違点３〉データポンプ・コンポーネントに対して前記グラフにもとづいて前記少なくとも一つのデータ・パスを生成するように指令するのに、本願補正発明は、「ファイルを検索させて」いるのに対し、刊行物１の発明は、そのようなことは開示されていない点。
　
（４）相違点についての当審判断
〈相違点１〉について
　マルチメディア情報の処理技術において処理対象となるデジタル・データが、検索されたデジタル・データであることは、本願優先権主張日前に周知の技術である。即ち、例えば、特開平９−１６０８９７号公報【０００４】、【０００９】〜【００１０】、【００１５】段落には、動画、音声などのマルチメディアデータの利用において、フィルタを用い、キーワードマッチングすることにより、情報を取捨選択しながら選択された情報毎に利用するフィルタによるキーワードマッチング処理の技術が示されており、前記キーワードにより取捨選択された情報は検索されたデジタル・データといえる。
　刊行物１の発明において、デジタル・データを、検索されたデジタル・データとすることは、共通するマルチメディアにおける技術である前記周知の技術を参酌することにより、当業者が容易になし得ることである。
　
〈相違点２〉について   
  データポンプ・コンポーネントにおけるデータ・パスに関して、内部データ・バッファおよび待ち行列を含み、且つ、検索されたデータのデータ・パスである技術は、本願優先権主張日前に周知の技術である。即ち、例えば、刊行物２（特に、第２５頁２０行〜第２６頁２行を参照）には、オーディオ・ポート間のコネクションはオーディオ・データのバッファを使用する技術がみられ、特開平８−６５３３４号公報【００９５】には待ち行列に対する内部バッファリング、内部ターゲット・バッファが示され、特開平１０−２８３１９９号公報には、図１４〜図１６にフィルタが記載され、関連する次の記載を参照すると、フィルタ、内部データ・バッファおよび待ち行列を含む技術が読み取れる。
「【０１４４】次に、図１４を参照して説明すると、図は複数の処理コンポーネント間で使用されるときの、バッファ・アロケータ・メカニズムのオペレーションを示したものである。図には、特定の処理コンポーネントに関連するバッファ間のデータ・フロー（つまり、バッファ・フレーム間の実際のデータ転送）も示されている。
コントロールは各処理コンポーネントに渡されるが、データは必要時にだけ転送され、一部の処理コンポーネントはデータ操作を実行し、データを既存バッファ・フレームに戻すようにしている。言い換えれば、データは新しいバッファに転送されることなく同じロケーションで処理されるので、「同所(inplace)」で処理されると呼ばれている。」（【０１４４】段落）
 「【０１５１】
　図１５は、バッファ・アロケータ・メカニズムが上述してきた相互接続カーネル・モード・バッファ方式でどのように論理的に実装されるかを示している。図１４と図１５は共に同じフィルタ・グラフ・トポロジを示し、バッファ・アロケータ・メカニズムのオペレーションを理解しやすくするために使用されている。
関係ドライバとその部分はそれぞれ、ユーザ・モード・クライアントがドライバを制御することを可能にするアクセス・ポイントをもち、これらはファイル・オブジェクトで表されている。相互通信はＩＲＰを使用して行われる（ＩＲＰがカーネル・モード・ドライバによって作成されたか、ユーザ・モード入出力オペレーションに応答してＮＴエグゼクティブによって作成されたかとは無関係である）。」（【０１５１】段落）
「【０１７２】バッファ・アロケータを表すファイル・オブジェクトは、正常に作成されたときは、データ構造を指すポイントをファイル・コンテキスト・エリアに置いている。このデータ構造には、ＩＲＰを種々のＩＲＰコード（例えば、作成、入出力コントロールなど）に基づいて指定のハンドラへ送るためのディスパッチ・テーブルが、バッファ・アロケータの状態を保持するための他のデータ・エリアと構造と共に収められている。トラッキングできる実装依存情報のいくつかを挙げると、バッファが関係する接続ピン・インスタンスのファイル・オブジェクトへの参照、割当てフレーミング要件データ構造への参照、イベントを待っているクライアントのイベント・キュー、未処理になっている割当て要求（例えば、ＩＲＰによって受信されたもの）のキューなどがある。」（【０１７２】段落）
「【０１７９】次に、図１６を参照して説明すると、同図には前述したバッファ割当てメカニズムを利用する図１１と図１２の相互接続フィルタ・システムが示されている。制御エージェント１７０はフィルタ間の相互接続を行ったあと、必要バッファ量について各入力ピン・インスタンスに照会する。図に示すように、サウンド・レンダリング・フィルタ１７８はバッファ・フレームをサウンド・カード・メモリ２５８から割当てる必要があり、デコンプレッサ・フィルタ１７４はデータをディスク・ドライブ２６２から直接に受け取ることができるシステム・メモリ２６０からメモリを割当てることになる。
【０１８０】制御エージェント１７０はファイル・オブジェクトで表され、入力ピン・インスタンス１８８上に形成されるバッファ・アロケータ２６４を作成する。バッファ・アロケータ２６４はバッファ・フレームをサウンド・カード・メモリ２５８から割当て、バッファ・アロケータ２６４への参照は破線２６６で示された出力ピン・インスタンス２０４に設定される。この参照はバッファ・アロケータ２６４を表すファイル・オブジェクトへのハンドルとなり、必要時にバッファ・フレームを割当てるためにデコンプレッサ・フィルタ１７４によって使用されてからデータが新しいバッファに転送される。
【０１８１】同じように、バッファ・アロケータ２６８もファイル・オブジェクトによって表され、入力ピン・インスタンス２０６上に作成される。このバッファ・アロケータ２６８はシステム・メモリ２６０の割当てを管理する。制御エージェント１７０はバッファ・アロケータ２６８を作成したあと、破線２７０で示すようにその参照を出力ピン・インスタンスにストアする。この場合も、バッファ・アロケータ２６８はシステム・メモリ２６０間のバッファ・フレームの割当てを担当し、データがディスク２６２からそこに転送できるようにする。
【０１８２】制御エージェントは出力ピン・インスタンス１９２のバッファ・アロケータ参照の値にヌル（空白）を入れ、同所変換が行われることを示し、効果フィルタ１７６はサウンド・カード・メモリ２５８内の既存バッファからデータを読み取り、必要とされる変換または効果を適用したあとでデータをサウンド・カード・メモリ２５８に戻す。逆に、制御エージェントがバッファ・アロケータ参照を設定していなければ、値が空白であり、同所変換が行われると想定される。」（【０１７９】〜【０１８２】段落）
　これらの記載から、相互接続フィルタ・システム（図１６参照）におけるバッファ技術であって、フィルタと、１つ以上のバッファ（バッファアロケータ）によって参照されるバッファ（サウンドカードメモリ）である内部バッファと、待ち行列（キュー）を含む技術が示されている。
　
　刊行物１の発明において、データポンプ・コンポーネントにおけるデータ・パスに関して、内部データ・バッファおよび待ち行列を含ませることは前記周知の技術を参酌することにより当業者が容易になし得ることであり、且つ、〈相違点１〉で言及した、データを検索されたデータとした場合に、システム全体の整合をとって、検索されたデータのデータ・パスとすることは当然の設計的事項を施したにすぎない。
　
〈相違点３〉について
　グラフにもとづいて前記少なくとも一つのデータ・パスを生成するように指令するのに、ファイルを検索させることは、本願優先権主張日前に周知の技術である。即ち、例えば、前記特開平９−１６０８９７号公報には、「【００１１】図２は、フィルタにより分類された情報毎に行う処理をユーザがカスタマイズする画面の例を説明する。図２において、処理はアイコン（２１１）〜（２１９）で表現される。アイコンは処理部品のパレット（２３０）に登録されており、ユーザがマウス等の入力装置で指定することにより編集領域（２０１）上に配置する。線図形（２２１）、（２２２）、（２２４）、（２２５）、（２２６）、（２２８）が処理の順序を表す。順次受信する情報の送信元を表す情報源（２１１）、必要な情報と不要な情報を分類するフィルタ（２１２）、（２１４）、（２１８）および、…（中略）…タイトル等はリスト２１５に順次表示され、映像がディスプレイ２１６で表示され、ＤＢ（２１７）に格納される。以上のように、処理を表すアイコンを用意し、これらのアイコンを結ぶフロー図をユーザに作成させる。作成したフロー図を処理手順を表すシナリオデータに変換し、これを記憶装置に保存しておく。情報の利用時にはシナリオ情報に基づいて順次受信情報を処理する。」、「【００１８】図８は本実施例の全体の処理の流れを表す図である。編集処理（８１０）において、編集処理に必要な数種のテーブルを格納した、部品情報ファイル（８１１）を読み込み、図２に示した対話的なビジュアルなプログラミングにより作成した、受信情報に対する処理手順を記述したシナリオを、シナリオテーブルファイル（８１３）として出力する。編集処理（８１３）は処理のアイコンを表示するために、アイコン画像（８１２）を読み込む。実行処理（８２０）とニュース情報格納処理（８３０）は並行して行われる。…（中略）…実行処理（８２０）はニュース情報（８２２）を順次読みだし、シナリオテーブル（８１３）に従って図１に示したような情報利用処理を行う。このとき、編集処理（８１０）におけるアイコンに対応する各処理部品の処理情報を部品処理属性情報ファイル（８２１）を読みだして用いる。」と記載されており、予め作成した処理を表すアイコンを結ぶフロー図を（シナリオデータに変換はされるが）ファイルとして保存しておき、利用時に前記フロー図を復元して用いる技術が示されており、前記シナリオテーブルファイルとして出力したり、アイコンに対応する各処理部品の処理情報を部品処理属性情報ファイル（８２１）を読みだして用いる際に、ファイルが検索される過程が付随していることは、一般に、ファイルの読み出しに関し、ファイルにファイル名を付して格納し、所定のファイル名のファイルをファイル名の付されたファイルの中から検索して読み出すことは通常のことであって、ファイルの読み出しに示されているに等しい事項である点を加味すると、少なくとも一つのデータ・パスを生成するように指令するのに、ファイルを検索させて行う技術が読み取れる。
　刊行物１の発明において、データポンプ・コンポーネントに対してファイルを検索させて前記グラフにもとづいて前記少なくとも一つのデータ・パスを生成するように指令するごとくなすことは、前記周知の技術を参酌することにより、当業者が容易になし得ることである。
（この点に関して、請求人も、審尋に対する回答書の（３）の（イ）の項において、作成した内容をファイルに保存しておき、後でそのファイルを探して前記保存した内容をファイルから読み出して使用することは周知技術であり、この周知技術を有向データ・フロー・グラフに適用する点には困難性はない旨言及している。）
　
　そして、本願補正発明によって得られる作用効果も、前記刊行物１及び刊行物２に記載された事項、及び前記周知の事項から当然予想される範囲内のものであり、格別顕著なものとは認められない。
　
　したがって、本願補正発明は、刊行物１に記載された発明、刊行物２に記載された発明、及び前記周知事項に基いて、当業者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許出願の際独立して特許を受けることができないものである。
　
（５）むすび
　以上のとおり、本件補正は、特許法第１７条の２第５項において、第４項第２号の場合に準用するとしている同法第１２６条第４項の規定に違反するものであり、特許法第１５９条第１項で準用する特許法第５３条第１項の規定により却下されるべきものである。
　
３．本願発明について
（１）平成１５年９月２４日付けの手続補正は前記のとおり却下された。
　本願の請求項１に係る発明（以下、同項記載の発明を「本願発明」という。）は、平成１５年４月４日付けの手続補正書における特許請求の範囲の請求項１に記載されたとおりの次の事項により特定されるものである。
「一つ以上の処理アルゴリズムを検索されたデジタル・データに与え、要求に応えて一つ以上のメディア・ストリームを生成するメディア処理システムであって、
　要求を受け取るコントローラと、
　前記要求に応答して検索されたデータの少なくとも一つのデータ・パスを動的に生成し、前記少なくとも一つのデータ・パスが一つ以上の処理アルゴリズムにもとづいて前記データを処理するための複数のフィルタから構成される少なくとも一つのデータポンプ・コンポーネントと、
　データを処理するためのグラフを生成するために、かつ前記データポンプに対してファイルを検索して前記グラフにもとづいて前記少なくとも一つのデータ・パスを生成するように指示するために、前記コントローラに応答する少なくとも一つのコンポーネントと、
　を備えることを特徴とするメディア処理システム。」
　
（２）引用刊行物
　引用刊行物とその記載事項、及び周知事項は、前記２．（２）、２．（４）に記載したとおりである。
　
（３）対比・判断
　本願発明は、前記２．（１）乃至２．（４）で検討した本願補正発明から、
（ア）「データポンプ・コンポーネント」についての
「内部データ・バッファおよび待ち行列を含み、」「フィルタ間の接続を規定するグラフを参照して生成し、」の限定事項、
（イ）「少なくとも一つのコンポーネント」についての
「前記コントローラに応答して・・・すると共に、・・・コンポーネント・・・検索させて・・・指令する、」の限定事項
を省いたものであり、そうすると、本願発明の構成要件を全て含み、さらに他の構成要件を付加したものに相当する本願補正発明が、前記２．（２）乃至２．（４）に記載したとおり、刊行物１に記載された発明、刊行物２に記載された発明、及び前記周知技術に基いて、当業者が容易に発明をすることができたものであるから、本願発明も、同様の理由により、刊行物１に記載された発明、刊行物２に記載された発明、及び前記周知技術に基いて当業者が容易に発明をすることができたものである。
　
（４）むすび
　以上のとおり、本願発明は、刊行物１に記載された発明、刊行物２に記載された発明、及び周知技術に基いて当業者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。
　よって、結論のとおり審決する。