【事件の表示】
　特願２００２−　　　９６１「コンテンツストリームデータが記録された記録媒体、その記録装置及び再生装置」拒絶査定不服審判事件〔平成１４年　９月１３日出願公開、特開２００２−２６０３４４〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
１．手続の経緯
　
　本願は、平成１４年１月７日（パリ条約による優先権主張　２００１年１月１０日　大韓民国）に出願したものであって、平成１６年７月１３日付け拒絶理由通知に対する応答期間（期間延長）内の平成１７年１月１９日付けで手続補正がなされたが、平成１７年８月２日付けで拒絶査定がなされ、これに対して、平成１７年１１月７日付けで拒絶査定不服審判が請求されるとともに、同年１２月７日付けで手続補正がなされたものである。
２．本願発明
　
　本願の請求項１乃至１８に係る発明は、平成１７年１２月７日付け手続補正書の明細書の特許請求の範囲の請求項１乃至１８に記載されたとおりのものであるところ、そのうち請求項１に係る発明（以下「本願発明」という。）は、次のとおりである。
　
「【請求項１】　コンテンツストリームデータが、所定の大きさを有する少なくとも１つの記録単位が集まってなるストリームオブジェクトとして記録された記録媒体において、前記記録単位は１つまたはそれ以上のストリームパックを含み、前記ストリームパックは再生時間情報を表示する応用タイムスタンプ及びコンテンツストリームデータがパッキングされた応用パケットを含み、前記記録単位のうち最後の記録単位を除いた残りは各々少なくとも１つの応用タイムスタンプを全て含み、
　前記応用パケットの大きさは前記記録単位が少なくとも１つの応用タイムスタンプをすべて含むように十分に小さく、
　前記応用パケットの大きさAP_PKT_SZは次の式を満たすことを特徴とする記録媒体。
　AP_PKF_SZ≦SPayload_SZ＊［SOBU_SZ］-［N_AHE+N_SByte+ATS_SZ］　ここで、SOBU_SZは前記記録単位の大きさを、ATS_SZはバイト単位よりなる応用タイムスタンプの大きさを、SPayload_SZは前記ストリームパックで固定されたヘッダ領域を除いた情報の記録可能なデータ空間の大きさを、N_AHEは対応記録単位のアプリケーションヘッダエキステンションの数を、N_SByteは対応記録単位のスタッフィングバイトの数を、各々意味する。」
　
３．引用例
　
　これに対し、原査定の拒絶の理由に引用された国際公開第００／６８９４６号パンフレット（２０００年１１月１６日公開、以下「引用例１」という。）には、パケット構造をもって伝送されるストリームデータの記録再生に適したデータ構造に関して、図面と共に次の技術事項が記載されている。（なお、下線は当審で付与した。）
　
（１）「発明の分野
　この発明は、デジタル放送などで伝送される映像データあるいは
パケット構造をもって伝送されるストリームデータの記録再生に適したデータ構造
　
（２）「図１は、この発明の一実施の形態に係るストリームデータのデータ構造を説明する図である。図１には、情報記憶媒体（たとえば相変化記録方式、光磁気記録方式などを利用した光ディスク）上に記録するストリームデータのデータ構造（階層構造）と、その構築過程を示している。
　
情報記憶媒体上に記録されるストリームデータ（図１（ｆ）のＳＴＲＥＡＭ．ＶＲＯ１０６）は、ストリームデータ内の映像情報のコンテンツ毎に、ストリームオブジェクト（ＳＯＢと略記される）としてまとまって記録されている
　
ＳＯＢ＃Ａ・２９８は、図１（ｅ）（ｇ）に示すように、ストリームオブジェクトユニット（ＳＯＢＵと略記される）５１、５２、…で構成される
　各
ＳＯＢＵは、図１（ｄ）（ｈ）に示すように、複数のストリームパックで構成されている
　
ストリームパックＮｏ．０は、図１（ｃ）に示すように、パックヘッダ１と、ＰＥＳヘッダ＆サブストリームＩＤ６と、ロングアプリケーションヘッダ１１と、データエリア２１とで構成されている
データエリア２１にはモディファイドタイムスタンプ（あるいはアプリケーションタイムスタンプ）およびアプリケーションパケットの組が１以上含まれる
　…（中略）…　
　ＤＶＤ−ＲＡＭディスクなどの記録媒体にストリームデータを記録する場合には、２０４８ｋバイト毎のセクタを最小単位として、記録が行われる。ストリームデータの記録フォーマット（データ構造）では、図１（ｄ）、（ｈ）に示すように、セクタ毎にストリームパックを構成している。ストリームパックは、図１（ｃ）または図１（ｉ）に示すように、パックヘッダ、ＰＥＳヘッダ＆サブストリームＩＤと、ロングアプリケーションヘッダまたはショートアプリケーションヘッダと、データエリアとで構成される。
　つまり、各ストリームパックの先頭位置には、パックヘッダ１、２、３、４とそれに続くＰＥＳヘッダ＆サブストリームＩＤ６、７、８、９が配置されている。また、実際のストリームデータが記録されているデータエリア２１〜２６と上記ＰＥＳヘッダ＆サブストリームＩＤ６〜９との間には、アプリケーションヘッダが配置されている。この発明の一実施の形態では、記録されるストリームデータの情報内容に応じて、このアプリケーションヘッダとして、ロングアプリケーションヘッダ１１、１２とショートアプリケーションヘッダ１３、１４との使い分けを行っている。
　…（中略）…
　図１に戻って説明を続ける。図１（ｂ）に示すように、デジタルＴＶ放送を受信したときに得られた
アプリケーションパケットｄを情報記憶媒体上に記録する場合、２個のストリームパックに分割記録することがある。これは、情報記憶媒体の記録エリアを効率的に利用するためである
　…（中略）…
　図１（ｅ）（ｇ）に示すように、複数のストリームパックをまとめてストリームオブジェクトユニットＳＯＢＵ５１〜５７が形成されている。図１に示した実施の形態では、ＳＯＢ＃Ａ・２９８内の１個のＳＯＢＵ５１またはＳＯＢＵ５２は３２個のストリームパック（セクタ）から構成され、ＳＯＢ＃Ｂ・２９９内の１個のＳＯＢＵ５４またはＳＯＢＵ５７は１６個のストリームパック（セクタ）から構成されている。
　最後のストリームパック内の最後に記録されたアプリケーションパケットｆ、ｚ（図１（ａ）（ｊ））の後ろには、図１（ｂ）（ｊ）に示すように、エンドコード３１、３２が記録される。これらのエンドコードの後ろには、全てが“１”または全てが“０”のデータで埋められたパディングエリア３６、３７が適宜設けられる。
　ストリーム情報が最後に記録された最後のストリームパックがＳＯＢＵ５７の中央部に位置している場合には、同一ＳＯＢＵ５７内でそれ以降のセクタは図１（ｈ）に示すパディングパック４０になる。」（９頁４行〜１４頁９行）
　
（３）「図１５は、ストリームパックのデータ構造を説明する図である。各ストリームパックは、図１５（ｂ）に示すようなデータ構造を持っている。すなわち、
１４バイトのパックヘッダと、６バイトのＰＥＳヘッダと、１バイトのサブストリームＩＤと、９バイトのアプリケーションヘッダと、必要に応じて用いられるオプションのアプリケーションヘッダエキステンションと、必要に応じて用いられるオプションのスタッフィングバイトと、アプリケーションタイムスタンプＡＴＳが付与されたアプリケーションパケットを１つ以上含むアプリケーションパケット群とで、１つのストリームパックが構成されている
　
　上記摘示事項及び図面を総合勘案すると、引用例１には次の発明（以下「引用発明」という。）が記載されているものと認める。
　
「コンテンツ毎のストリームデータが、ストリームオブジェクトユニット（ＳＯＢＵ）５１、５２、…で構成されるストリームオブジェクト（ＳＯＢ）として記録された情報記憶媒体において、
　ＳＯＢＵは、複数のストリームパックで構成され、ストリームパックはアプリケーションタイムスタンプおよびアプリケーションパケットを含む
　情報記憶媒体。」
　
　同じく、原査定の拒絶の理由に引用された国際公開第００／４６８０３号パンフレット（２０００年８月１０日国際公開、以下「引用例２」という。）には、図面と共に、次の技術事項が記載されている。（なお、下線は当審で付与した。）
　
（４）「前述したように１セクタサイズは２０４８バイトであり、各種ヘッダサイズを差し引いても１個の
データエリア２１、２２、２３、２４（図１（ｃ）（ｉ））内にはデジタル放送用のトランスポートパケットが１０個前後記録できる
　それに対して、
ＩＳＤＮなどのデジタル通信網では１パケットサイズが４０９６バイトある大きなロングパケットが転送される場合がある
　デジタル放送などのように１個のデータエリア２１、２２、２３、２４（図１（ｃ）（ｉ））内に複数個のトランスパケットを記録するだけでなく、ロングパケットのようにパケットサイズの大きなパケットの場合でも記録できるよう、前記特徴を生かしたデータ構造（１パケットのデータを複数パケットに跨って記録できる特徴）を用いることにより、１個のパケットを複数のデータエリア２１、２２、２３、２４に連続して跨るように記録する。
　そうすれば、
デジタル放送用のトランスポートパケットやデジタル通信用のロングパケットなどは、パケットサイズに依ることなく、全てのパケットをストリームブロック内に端数なく記録することができる
　
（５）「ビットレートが極めて低い記録がなされる場合、
タイムマップ情報（第３図（ｈ）の２５２；あるいは図２９のＳＯＢＩ内ＭＡＰＬ）の回復（再生）を確実にするためにスタッフィングが必要になる
夫々のＳＯＢＵが少なくとも１つのＡＴＳ値を含むようにする
　
 ４．対比
　
　本願発明と引用発明とを対比する。
（１）引用発明の「コンテンツ毎のストリームデータ」「ＳＯＢＵ」及び「情報記憶媒体」は、それぞれ本願発明の「コンテンツストリームデータ」「記録単位」及び「記録媒体」に相当し、引用発明の「ストリームオブジェクト（ＳＯＢ）」は本願発明の「ストリームオブジェクト」であり、「ＳＯＢＵ」が所定の大きさを有することは明らかであるから、引用発明と本願発明とは「コンテンツストリームデータが、所定の大きさを有する少なくとも１つの記録単位が集まってなるストリームオブジェクトとして記録された記録媒体」で共通する。
（２）引用発明と本願発明の「ストリームパック」は共通し、引用発明の「アプリケーションタイムスタンプ」及び「アプリケーションパケット」は、本願発明の「再生時間情報を表示する応用タイムスタンプ」及び「コンテンツストリームデータがパッキングされた応用パケット」に相当する。
　そして、引用発明の「ＳＯＢＵ」は複数のストリームパックで構成され、ストリームパックはアプリケーションタイムスタンプを含むとすることから、引用発明と本願発明とは「記録単位は１つまたはそれ以上のストリームパックを含み、前記ストリームパックは再生時間情報を表示する応用タイムスタンプ及びコンテンツストリームデータがパッキングされた応用パケットを含み、前記記録単位」「は各々少なくとも１つの応用タイムスタンプを全て含み」で共通する。
（３）引用発明では、「ＳＯＢＵ」は「複数のストリームパックで構成され」、「ストリームパック」は、「アプリケーションタイムスタンプおよびアプリケーションパケットを含む」から、引用発明と本願発明とは「応用パケットの大きさは前記記録単位が少なくとも１つの応用タイムスタンプを全て含むように十分に小さく」で共通する。
　そうすると、本願発明と引用発明とは、次の点で一致する。
　
＜一致点＞
　
「コンテンツストリームデータが、所定の大きさを有する少なくとも１つの記録単位が集まってなるストリームオブジェクトとして記録された記録媒体において、前記記録単位は１つまたはそれ以上のストリームパックを含み、前記ストリームパックは再生時間情報を表示する応用タイムスタンプ及びコンテンツストリームデータがパッキングされた応用パケットを含み、前記記録単位は各々少なくとも１つの応用タイムスタンプを全て含み、　
　前記応用パケットの大きさは前記記録単位が少なくとも１つの応用タイムスタンプを全て含むように充分に小さ（い）記録媒体。」の点。
　
　そして、次の各点で相違する。
　
＜相違点＞
　
（ａ）本願発明は、「記録単位のうち最後の記録単位を除いた残り」が各々少なくとも１つの応用タイムスタンプを全て含みとするのに対し、引用発明はそのような特定がなされていない点。
　
（ｂ）本願発明は、応用パケットの大きさAP_PKT_SZは次の式を満たすとするのに対し、引用発明はそのような特定がなされていない点。
　AP_PKT_SZ≦SPayload_SZ＊［SOBU_SZ］-［N_AHE+N_SByte+ATS_SZ］　ここで、SOBU_SZは前記記録単位の大きさを、ATS_SZはバイト単位よりなる応用タイムスタンプの大きさを、SPayload_SZは前記ストリームパックで固定されたヘッダ領域を除いた情報の記録可能なデータ空間の大きさを、N_AHEは対応記録単位のアプリケーションヘッダエキステンションの数を、N_SByteは対応記録単位のスタッフィングバイトの数を、各々意味する。
　
５．判断
　
　そこで、上記各相違点について検討する。
　
相違点（ａ）について
　引用発明において、ＳＯＢＵは複数のストリームパックで構成され、ストリームパックはアプリケーションタイムスタンプを含むのであるから、ＳＯＢＵは少なくとも１つのアプリケーションタイムスタンプを含む。
　そうすると、ＳＯＢＵのうち最後のＳＯＢＵを除いた残りも少なくとも１つのアプリケーションタイムスタンプを全て含むことも当然のことであって、上記相違点（ａ）は自明の事項又は適宜なし得る程度のものである。
　　
相違点（ｂ）について
　引用発明および本願発明と同一の技術分野に属する上記引用例２には、アプリケーションパケットのパケットサイズ（大きさ）は、放送、通信分野に応じて適宜に設定されること（上記３．（４））、及び、タイムマップ情報の回復（再生）を確実にするためにＳＯＢＵが少なくとも１つのＡＴＳ（アプリケーションタイムスタンプ）を含むようにする（上記３．（５））ことが記載されている。
　また、引用例１には、図１５のストリームパックのデータ構造について、パックヘッダ等を含む固定のヘッダ、アプリケーションヘッダエキステンション、スタッフィングバイトおよびアプリケーションタイムスタンプ（ＡＴＳ）付アプリケーションパケットからなるストリームパックのデータ構造が記載（上記３．（３））されており、このストリームパックのデータ構造は本願発明と同一である。
　ストリームパックの中でアプリケーションパケットを格納できるエリアは、ストリームパックから固定のヘッダを除いたエリア（本願発明の「SPayload_SZ」に相当）からアプリケーションヘッダエキステンション及びスタッフィングバイトを除いたエリアとなることは明らかである。
　そして、引用発明において、ＳＯＢＵが１つのアプリケーションタイムスタンプを含むとした場合、アプリケーションパケットにはストリームパックに分割記録できること（上記３．（２））を踏まえると、ＳＯＢＵ内のストリームパックの上記エリアから１つのアプリケーションタイムスタンプのバイト数分を除いた残りのエリアとなり、式で表すと、アプリケーションパケットの大きさは本願発明の式において、右辺の値に等しくなる。（上記式の等号の場合にあたる。）
　また、ＳＯＢＵが２以上のアプリケーションタイムスタンプを含むようなアプリケーションパケットの場合、２以上のアプリケーションタイムスタンプのバイト数に伴い、アプリケーションパケットを格納するエリアは該増加したアプリケーションタイムスタンプのバイト数分減少するのであるから、アプリケーションパケットの大きさはＳＯＢＵ内に１つのＡＴＳが含まれるとした本願発明の式の右辺の値より小さくなることは明らかであるから、当然にアプリケーションパケットの大きさは上記式において不等式の関係を満たすことも自明のことである。
　
　したがって、引用発明において、異なるアプリケーションパケットのパケットサイズが相違点（ｂ）のような式を満たすとすることは当業者が適宜なし得る程度のことである。
　
　なお、審判請求人は、審判請求の理由において「このようなＭＰＥＧシステムの場合は応用パケットの大きさが１８８バイトに固定されているため、全てのSOBUは複数のＡＴＳを有することは当然であり、よって本発明で認識した問題点は全く生じません。しかし、本発明はこのようなＭＰＥＧシステムではなく、その他の一般的な状況、すなわち応用パケットの大きさに制限のない環境下では１つの記録単位が一つの応用タイムスタンプも有せない状況も発生しうるので、前記状況を考慮して請求項１のように応用パケットの大きさを決めようとすることです。本願の請求項１で請求したように、応用パケットの大きさを定めると、記録単位が一つの応用タイムスタンプを有せない状況を防止することができます」旨主張している。
　しかしながら、通常、応用パケットの大きさは応用分野（放送、通信）により異なるものであり、応用パケットの大きさが本願発明の式を満たすとすることは上記相違点（ｂ）で検討したように当業者が適宜なし得ると判断するものであるから、上記審判請求人の主張は採用できない。
　
　そして、上記相違点を総合的に判断しても、本願発明が奏する効果は引用例１及び引用例２から、当業者が十分に予測できたものであって、格別なものとはいえない。
　
６．むすび
　
　以上のとおり、本願の請求項１に係る発明は、引用例に記載された発明及び引用例２の記載事項に基づいて当業者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。
　したがって、本願は、その余の請求項について論及するまでもなく拒絶すべきものである。
　よって、結論のとおり審決する。