【事件の表示】
　特願２００２−１８１４１１「マルチチャネルストリームの記録装置及び方法と、それによる記録媒体」拒絶査定不服審判事件〔平成１５年　２月２８日出願公開、特開２００３−　５９２４１〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
１．手続の経緯
　
　本件の審判請求に係る特許出願（以下「本願」という。）は、２００２年（平成１４年）６月２１日（パリ条約による優先権主張　２００１年（平成１３年）６月２１日　大韓民国）を出願日とする出願であって、平成１６年６月１０日付け拒絶理由の通知に応答して平成１６年９月１５日付けで手続補正がなされたが、平成１６年１０月２８日付けで拒絶査定がなされ、これに対し、平成１７年１月３１日に拒絶査定不服審判が請求されるとともに、平成１７年３月１日付けで手続補正がなされたものである。
　
２．本願発明
　　
　平成１７年３月１日付けの手続補正は、特許請求の範囲について、補正前の平成１６年９月１５日付け手続補正の請求項７，８，１１，１４を削除することで補正前の請求項９，１０，１２，１３を繰り上げ新たに請求項７乃至１０とするもので、特許法第１７条の２第４項第１号に規定する請求項の削除を目的とするものに該当する。
　そして、本願の請求項１〜１０に係る発明は、平成１７年３月１日付け手続補正書により補正された明細書の特許請求の範囲の請求項１〜１０に記載された事項により特定されるとおりのものと認められるところ、請求項１に係る発明（以下「本願発明」という。）は、次のとおりのものである。
　
「【請求項１】　複数チャネルのサブストリームで形成された一つのマルチストリームを、各々のサブストリーム別に区分して複数の記録集合体に区画して記録する１段階；及び
　前記複数の記録集合体に各々記録されたマルチストリームに含まれた複数チャネルのサブストリーム各々に対するサーチ情報を生成して記録する２段階を含み、前記２段階は、前記複数の記録集合体に対して、一つのプログラム情報と、前記複数チャネルのサブストリーム各々に対する複数のセル情報を生成して記録する段階をさらに含むことを特徴とするマルチチャネルストリームの記録方法。」
　
３．引用例
　
　原査定の拒絶の理由に引用された特開２００１−６７８０２号公報（以下「引用例」という。）には、マルチチャンネル記録方法に関し、図面と共に、以下の記載がある。なお、下線は、当審で付与した。
　
（１）「【０００１】
【発明の属する技術分野】この発明は、例えばＲＴＲ（Real Time Recorder）−ＤＶＤ（Digital Versatile Disk）等のディスク状記録媒体に、複数の番組を同時記録するためのマルチチャンネル記録装置及び記録方法に関する。」
　
（２）「【０００９】ここでは、リアルタイムで録画中に、ディフェクトやジャンプ発生時にも連続再生が可能なように、最低限ＡＶ（Audio Video）データが連続しなければならないデータ長単位を規定しており、これをＣＤＡ（Contiguous Data Area）と称している。
【００１０】このＣＤＡブロックの制限は、ディスクに連続して配置され、さらに、その長さはＥＣＣ（Error Correcting Code）ブロックの正数倍になっており、ＣＤＡ長は、記録レートにより変化し、基本的には、ピックアップがディスクの最内周から最外周までアクセスする時間より長い時間、バッファ内のデータがなくならない程度の時間、再生できるだけのデータ量が必要となってくる。」
　
（３）「【００１６】また、
この発明に係るマルチチャンネル記録方法は、番組を構成するデジタルデータを、最低限連続しなければならない規定されたデータ長単位で、ディスク状記録媒体に記録する記録方法を対象としている。そして、互いに異なる第１及び第２の番組を構成する各デジタルデータを、それぞれ、規定されたデータ長単位で、交互にディスク状記録媒体に記録する
　
（４）「【００２３】ビデオファイルは、図２に示すように、階層構造で管理されており、１つのＶＯＢＳは複数のＶＯＢ（Video Object）で構成されており、１つのＶＯＢは複数のＶＯＢＵ（Video Object Unit）で構成されている。また、ＶＯＢＵは、複数の様々な種類のデータからなっているパックによって構成されている。１パックは、１つ以上のパケットとパックヘッダとで構成され、各ビデオデータ、オーディオデータは、このパケット内に記録されている。
【００２４】ここで、パックは、データ転送処理を行なう最小単位である。さらに、論理状の処理を行なう最小単位はセルで、論理上の処理はこのセル単位で行なわれる。そして、
データを再生する順番は、ＰＧＣで定義され、このＰＧＣには複数のＰＧ（Program）が登録され、このＰＧにはセルが登録されている
【００２５】また、このセルには、再生すべきＶＯＢの番号と、そのＶＯＢ内での再生時間が登録されており、このセルの再生情報にしたがってＶＯＢが再生されることになる。
【００２６】
このＰＧＣの構造を実際に記録してあるのがＰＧＣ情報ＰＧＣＩである。再生処理は、このＰＧＣＩにしたがって行なわれ、記録時または編集時にＰＧＣＩを作成することになる
【００２７】また、記録再生ＤＶＤでは、記録順に再生する（ＶＴＲライクな再生処理）ための特別なＰＧＣをオリジナルＰＧＣと称し、このオリジナルＰＧＣの情報はＯＲＧ＿ＰＧＣＩに記録されている。また、編集等により作成されるＰＧＣをユーザーデファインドＰＧＣと称し、このユーザーデファインドＰＧＣの情報はＵＤ＿ＰＧＣＩに記録されている。
【００２８】以上のことから、ＯＲＧ＿ＰＧＣは１ディスクに１つとなり、ＵＤ＿ＰＧＣは複数存在することになる。
【００２９】図３は、光ディスク１１に対してデータの記録再生を行なう記録再生装置を示している。この記録再生装置は、主として、Ａ／Ｖ（Audio／Video）入力部１２、ＭＰＵ（Microprocessing Unit）部１３、表示部１４、デコーダ部１５、エンコーダ部１６、ＴＶチューナー部１７、ＳＴＣ（System Time Clock）部１８、Ｄ（Data）−ＰＲＯ（Processer）部１９、一時記憶部２０、ディスクドライブ部２１、キー入力部２２、Ｖ（Video）ミキシング部２３、フレームメモリ部２４、ＴＶ受信機２５用のＤ／Ａ（Digital／Analogue）変換部２６及びデジタル出力用のＩ／Ｆ（Inter／Face）部２７，２８を有している。
【００３０】エンコーダ部１６は、Ａ／Ｄ（Analogue／Digital）変換部１６ａ、ビデオエンコード部１６ｂ、オーディオエンコード部１６ｃ、ＳＰ（Sub Picture）エンコード部１６ｄ、フォーマッタ部１６ｅ及びバッファメモリ部１６ｆより構成されている。」
　
（５）「【００３５】また、このとき、例えば、
１ＧＯＰ（Group of Picture）毎にＶＯＢＵとし、そのときの切り分け情報をバッファメモリ部１６ｆに保存し、切り分け情報がある程度貯まったときにＭＰＵ部１３に転送して、ＭＰＵ部１３では、その情報をもとにタイムマップ情報を作成する
【００３６】ここで、切り分け情報（ＶＯＢＵ情報）としては、ＶＯＢＵの大きさ、ＶＯＢＵ先頭から最後までの再生時間、ＶＯＢＵ先頭からフレーム内符号化画像であるＩピクチャのエンドアドレス等が考えられる。また、上記切り分け情報を元に、直接、フォーマッタ部１６ｅがタイムマップ情報を作成し、ＴＭＡＰの形でＭＰＵ部１３へ渡すことも考えられる。」
　
（６）「【００４７】
さらに、ビデオデータを管理するためにＶＭＧ内にＭ＿ＡＶＦＩＴＩ（MovieAV File Information Table Information）と、再生順序を制御するためにＰＧＣＩが記録され
【００４８】これらのうち、
切り分け情報によりＭ＿ＡＶＦＩＴＩの中のＴＭＡＰＩ（TimeMap Information）を作成し、記録した順にＰＧＣＩを設定するのがＯＲＧ＿ＰＧＣＩで、ＣＤＡ単位で記録した内容をＣＤＡテーブルに反映させている
【００４９】ここで、ＰＧＣＩは、図５に示すように、ＶＭＧに含まれている。また、ＰＧＣＩは、ＰＧＣ＿ＧＩ（ＰＧＣに含まれるＰＧの数、セルの数が含まれる）、ＰＧＩＴ［ＰＧのタイプ：プロテクション／ノンプロテクション、ＰＧ内のセルの数、プライマリテキスト情報、アイテムテキストへのＳＲＰ（Search Pointer）番号、サムネールポインタ］、ＣＩ＿ＳＲＰＴ（セルサーチポインタテーブル）、ＣＩＴ（セル情報テーブル）で構成されている。
【００５０】さらに、ＣＩＴは、ＣＩ＃１〜＃ｊで構成され、ＣＩは、Ｃ＿ＧＩ（セルタイプ、ＶＯＢ情報ＶＯＢＩへのサーチポンタ：セルの再生すべきＶＯＢ番号、セルの再生開始時間、終了時間）と、Ｃ＿ＥＰＩ＃１〜＃ｋ［ＥＰ（Entry Point）タイプ（テキスト情報有り／無し）、ＥＰの再生時間、テキスト情報）とで構成されている。
【００５１】次に、ＶＯＢを再生するための情報として、図６に示すように、Ｍ＿ＶＯＢＩがＶＭＧに含まれる。このＭ＿ＶＯＢＩには、ＴＭＡＰＩが含まれ、このＴＭＡＰＩには、ＴＭＡＰ＿ＧＩ（ＴＭＵの数、ＶＯＢＵ＿ＥＮＴの数、タイムオフセット、アドレスオフセット：本ＶＯＢのビデオファイル内での先頭からファイルポンタ）、ＴＭ＿ＥＮＴ＃１〜＃ｎ（１０ｓｅｃおきのＶＯＢＵ＿ＥＮＴの番号、Time difference、ＶＯＢＵアドレス：本ＶＯＢＵのビデオファイル内での先頭からファイルポンタ）、ＶＯＢＵ＿ＥＮＴ＃１〜＃ｍ（ＶＯＢＵ先頭からＩピクチャの最終データまで相対アドレス、ＶＯＢＵの再生時間、ＶＯＢＵのサイズ）で構成されている。」
　
（７）「【００５５】ここで、２番組の記録処理について、図７及び図８に示すフローチャートを参照して説明する。
【００５６】１．ファイルシステムデータを読み込み、空き容量があるかどうかをチェックし、容量がない場合には、その旨を表示して終了する。
【００５７】２．空き容量がある場合には、後述する録画前処理を行ない、書き込みアドレスを決定する。
【００５８】３．エンコーダ部１６に対して録画初期設定を行なう。このとき、フォーマッタ部１６ｅに、ＰＧ、セル、ＶＯＢＵの区切り条件を設定し、フォーマッタ部１６ｅの方で、自動的に区切るようにする。また、前記アライン処理を行なう場合にも、フォーマッタ部１６ｅに設定する。
【００５９】４．以下の５〜１１の処理をタスク毎に、分割し、番組毎に並列処理する。
【００６０】５．エンコーダ部１６に録画開始命令を設定する。
【００６１】６．最初の１ＣＤＡ分がバッファメモリ部１６ｆ内に貯まったら、ディスクドライブ部２１に書き込みアドレスと書き込み長、書き込み命令を発行する。
【００６２】７．切り分け情報が貯まったかどうかをチェックし、貯まっている場合には、フォーマッタ部１６ｅより、切り分け情報を読み込む。
【００６３】８．１ＣＤＡ分のデータがバッファメモリ部１６ｆ内に貯まったかどうかをチェックし、貯まっていない場合には１０の処理に移行する。
【００６４】９．貯まった場合には、後述する録画中のＣＤＡ処理を行ない、記録アドレス、記録長、記録命令をディスクドライブ部２１に発行する。」
　
（８）「【０１０５】さらに、この実施の形態における２番組記録の場合のＰＧＣＩ作成処理は、図１３に示すようになる。
【０１０６】１．
記録したＶＯＢ１（録画処理１により発生したＶＯＢ）をセル１として登録する
【０１０７】２．
記録したＶＯＢ２（録画処理２により発生したＶＯＢ）をセル２として登録する
【０１０８】３．
前記セル１をプログラム１とし、セル２をプログラム２として、ＯＲＧ＿ＰＧＣＩに登録する
　
（９）「【０１２２】また、録画処理１における録画中のＣＤＡ処理の動作について、図１５に示すフローチャートにより説明する。
【０１２３】１．最後に記録したＣＤＡ番号を取り出し、その番号以降のＣＤＡで未使用のＣＤＡを探し（次のＣＤＡ番号＝“００００”）、見つからずにＣＤＡテーブルを一周した場合には、記録できるＣＤＡが無いので、その旨をメインルーチンに返して終了する。
【０１２４】２．未使用のＣＤＡがあった場合に、そのＣＤＡが録画処理２で使用中のＣＤＡかどうかチェックし、録画処理２で使用中のものの場合には、１の処理に移行する。未使用のＣＤＡで、録画処理２で使用していない場合、見つけた未使用ＣＤＡのスタートアドレス、ＣＤＡサイズを次回記録時の記録アドレス、記録サイズとし、ＣＤＡテーブルの中の最後に記録したＣＤＡの項の次のＣＤＡ番号の所とｎｏｗ＿ｃｄａｌに見つけた未使用ＣＤＡ番号を設定して、この処理を終了する。
【０１２５】これにより、記録を終わったＣＤＡより先のＣＤＡ（記録している方向）で、未使用のＣＤＡに記録を行なう。このとき、録画処理２で記録中のＣＤＡは避けるようにすることになる。ただし、未使用の領域が記録方向に無い場合には、リードインへヘッドを移動して、改めて記録する方向に未記録領域が無いか検索を行なう。」
　
（１０）「【０１３０】また、録画処理２における録画開始、及び録画中のＣＤＡ処理の動作について、図１７に示すフローチャートにより説明する。
【０１３１】１．録画開始がどうかをチェックし、開始時には、録画処理１で記録中のＣＤＡ番号を録画処理２の最後に記録したＣＤＡ番号（ｎｏｗ＿ｃｄａ２←ｎｏｗ＿ｃｄａ１）とする。
【０１３２】２．最後に記録したＣＤＡ番号を読み出す（ｃｄａ＿ｎｕｍ２←ｎｏｗ＿ｃｄａ２）。
【０１３３】３．次のＣＤＡから未使用かどうかを調べるために、そのＣＤＡ番号（ｃｄａ＿ｎｕｍ２）をインクリメントする。
【０１３４】４．ｃｄａ＿ｎｕｍ２以降のＣＤＡで未使用のＣＤＡを探し（次のＣＤＡ番号＝“００００”）、見つからずにＣＤＡテーブルを一周した場合には、記録できるＣＤＡが無いので、その旨をメインルーチンに返して終了する。
【０１３５】５．未使用のＣＤＡがあった場合に、そのＣＤＡが録画処理１で使用中のＣＤＡかどうかチェックし、録画処理１で使用中のものの場合には、３の処理に移行する。未使用のＣＤＡで、録画処理１で使用していない場合、見つけた未使用ＣＤＡのスタートアドレス、ＣＤＡサイズを次回記録時の記録アドレス、記録サイズとし、ＣＤＡテーブルの中の最後に記録したＣＤＡの項の次のＣＤＡ番号の所とｎｏｗ＿ｃｄａ２に見つけた未使用ＣＤＡ番号を設定して、この処理を終了する。
【０１３６】つまり、記録を終わったＣＤＡより先のＣＤＡ（記録している方向）で、未使用のＣＤＡに記録を行なう。このとき、録画処理１で記録中のＣＤＡは避けるようにすることになる。ただし、未使用の領域が記録方向に無い場合には、リードインへヘッドを移動して、改めて記録方向に未記録領域が無いか検索を行なう。」
　
（１１）「【０１４２】これらのＣＤＡ処理により、図１９（ａ），（ｂ）に示されるように、
録画処理１で記録したＣＤＡと録画処理２で記録したＣＤＡは、ＣＤＡ単位で交互に記録されるようになる
【０１４３】これにより、
録画処理１で発生したＶＯＢをＶＯＢ１とし、録画処理２で発生したＶＯＢをＶＯＢ２として、各切り分け情報よりＴＭＡＰＩをそれぞれ作成する
【０１４４】また、
論理的なイメージとしては、図２０に示すように、録画順の再生を行うために用意されたＯＲＧ＿ＰＧＣ上では、録画処理１で発生したＶＯＢをＰＧ１とし、録画処理２で発生したＶＯＢをＰＧ２として登録し、再生の順番を決める
　　
　上記摘示事項及び図面の記載を参酌すると、引用例には、次の発明が記載されているものと認める。
　
「第１及び第２の番組を構成する各デジタルデータを、それぞれ、規定されたデータ長（ＣＤＡ）単位で、交互に記録媒体に記録（録画処理１、録画処理２）し、さらに、ビデオデータを管理するためにＶＭＧ内にＭ＿ＡＶＦＩＴＩと再生順序を制御するためのＰＧＣＩを記録し、
　さらに、上記ＰＧＣＩには、録画処理１により発生したＶＯＢ（ＶＯＢ１）のセル１をプログラム１として登録し、録画処理２により発生したＶＯＢ（ＶＯＢ２）のセル２をプログラム２として登録し、（ＶＯＢ１，ＶＯＢ２の）各切り分け情報によりＭ＿ＡＶＦＩＴＩの中のＴＭＡＰＩ（タイムマップ情報）をそれぞれ作成する、マルチチャンネル記録方法。」
　
４．対比
　
　そこで、本願発明と引用例に記載された発明とを対比する。
（１）引用例に記載された発明における「番組」「（各）デジタルデータ」「ＴＭＡＰＩ（タイムマップ情報）」「プログラム」及び「セル」は、それぞれ本願発明の「チャネル」「サブストリーム」「サーチ情報」「プログラム情報」及び「セル情報」に相当する。
（２）引用例に記載された発明は、各デジタルデータをそれぞれ規定されたデータ長単位で記録するものであるから、本願発明の「各々のサブストリーム別に」「区画して」「記録する」に相当する構成を備えている。
（３）引用例に記載された発明は、各チャンネル（番組）のタイムマップ情報をそれぞれ作成するものであるから、本願発明の「複数チャネルのサブストリーム各々に対する」「サーチ情報を生成して」に相当する構成を備えている。
（４）引用例に記載された発明は、１つであるかどうかは別にして「プログラム（情報）」を作成（生成）するものである。
（５）引用例に記載された発明は、録画処理１，２により発生したＶＯＢ１，ＶＯＢ２、それぞれを「セル１」、「セル２」として登録（生成）するものであるから、本願発明の「複数チャネルのサブストリーム各々に対する」「複数のセル情報を生成して」に相当する構成を備えているといえる。
　　
　そうすると、本願補正発明と引用例に記載された発明とは、次の点で一致する。
　
＜一致点＞
　
「各々のサブストリーム別に区画して記録する１段階；及び
　前記複数チャネルのサブストリーム各々に対するサーチ情報を生成して記録する２段階を含み、前記２段階は、プログラム情報と、前記複数チャネルのサブストリーム各々に対する複数のセル情報を生成して記録する段階をさらに含むマルチチャネルストリームの記録方法。」の点。
　
　そして、次の各点で相違する。
＜相違点＞
（ａ）「複数のサブストリーム」について、本願発明は、「複数チャネルのサブストリームで形成された一つのマルチストリームを」、各々のサブストリーム別に「区分して」「複数の記録集合体」に区画して記録するのに対し、引用例に記載された発明は、番組を構成する各デジタルデータをＣＤＡ単位で交互に記録している点。
　
（ｂ）「プログラム情報」について、本願発明は、「複数の記録集合体に対して一つ」のプログラム情報を生成しているのに対し、引用例に記載された発明は、（番組毎の）「複数」のプログラム（情報）を登録（生成）している点。
　
５．判断
　
　そこで、上記各相違点について検討する。
（相違点ａについて）
　複数のプログラムが多重されているトランスポートストリーム（マルチストリーム）の中から１つ以上のプログラムを選択して記録することは、周知（必要であれば、特開平１０−５１７３７号公報（【従来の技術】）、特開平１０−２６９６９８号公報（【従来の技術】）等参照）である。
　すると、引用例に記載された発明において、複数のプログラムが多重されているマルチストリームの中からプログラムを選択して各チャンネル（番組）のデジタルデータとすること、即ち、相違点ａのように「複数チャネルのサブストリームで形成された１つのマルチストリームを、各々のサブストリーム別に区分して」とする構成は、当業者が適宜容易に想到できるものである。
　また、サブストリームの記録について、引用例に記載された発明のものは「規定されたデータ長単位」で交互に記録媒体に記録していることから、本願発明のように「（各々の）サブストリーム別に（区分して）」「（複数の）記録集合体」に区画して記録するようなことは、複数のサブストリームの記録再生処理の効率ないし記録媒体へのアクセス制御等を考慮して当業者が適宜に採用する設計的事項にすぎないものである。
　
（相違点ｂについて）
  データ管理の形態として階層型データの管理方式は、周知（必要であれば、特開平１−１１６８１９号公報（従来技術）等参照）である。
　一方、本願発明において、「１つのプログラム情報」は、複数のデジタルチャネルストリームを管理する（明細書、段落【００３７】の記載参照）もの、即ち、「１つの管理情報」で複数の「情報」を管理する「階層型データの管理」の１形態である。
　すると、引用例に記載された発明において、各チャンネルの番組に対してそれぞれ「プログラム（情報）」を生成するものに代えて、上記周知の階層型のデータ管理方式を採用し、相違点ｂのように、複数の記録集合体に対して、「１つのプログラム情報」を生成することは、当業者が容易に想到できるものである。
　　　
　なお、審判請求人は、審判請求の理由で、『ここで、特に、本願発明と引用例１に記載された発明とを対比してみると、引用例１の発明には、本願の「１つのプログラム情報により複数の各チャンネルデータを管理する」技術思想については開示も示唆もされていない。すなわち、引用例１の発明は、各チャンネルの番組に対して、それぞれ１つのセルと１つのプログラムを設定し、それぞれのセルとプログラムがそれぞれ各チャンネルを管理しており、チャンネル数が多くなるとチャンネルデータの管理が煩雑となるとともに、各チャンネルデータを管理するためのメモリ容量が増大するという欠点がある。これに対して本願発明は、前述したように、１つのプログラム情報により各チャンネルデータを管理するようにしているため、各チャンネルデータの統合的な管理を実現することができ、したがって、チャンネル数が多くなっても記録媒体の１つの管理領域だけで各チャンネルデータが管理できるという簡単な管理が実現できることから、引用例１のように記録媒体のあちこちに各管理領域を設けて各チャンネルデータを管理するようなことを排除できるとともに、各チャンネルデータを管理するためのメモリ容量も低減できるという引用例１の発明には期待できない作用効果を奏する』旨主張する。
　しかしながら、１つのプログラム情報により各チャネルデータを管理する構成は、上記相違点ｂで検討したように当業者が容易に想到し得ると判断するものであり、そして、階層型データ構造の管理方式においては、統合的な管理が実現できること、及びデータ管理するためのメモリ容量を低減できることは明らかであり、本願発明に基づく特有の効果とはいえないものであるから、上記審判請求人の主張は採用できない。
　
　そして、本願発明が奏する効果は引用例に記載された発明及び周知技術から、当業者が十分に予測できたものであって、格別なものとはいえない。
　
６．むすび
　
　以上のとおり、本願の請求項１に係る発明は、引用例に記載された発明及び周知技術に基づいて当業者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。
　したがって、本願は、その余の請求項について論及するまでもなく拒絶すべきものである。
　よって、結論のとおり審決する。