ポートフォリオ機能
| ポートフォリオを新規に作成して保存 |
|
|
| 既存のポートフォリオに追加保存 |
|
PDFをダウンロード
|
| 審決分類 |
審判 査定不服 2項進歩性 特許、登録しない。 G11B 審判 査定不服 特36条6項1、2号及び3号 請求の範囲の記載不備 特許、登録しない。 G11B |
|---|---|
| 管理番号 | 1202246 |
| 審判番号 | 不服2005-21527 |
| 総通号数 | 118 |
| 発行国 | 日本国特許庁(JP) |
| 公報種別 | 特許審決公報 |
| 発行日 | 2009-10-30 |
| 種別 | 拒絶査定不服の審決 |
| 審判請求日 | 2005-11-07 |
| 確定日 | 2009-08-12 |
| 事件の表示 | 特願2002- 961「コンテンツストリームデータが記録された記録媒体、その記録装置及び再生装置」拒絶査定不服審判事件〔平成14年 9月13日出願公開、特開2002-260344〕について、次のとおり審決する。 |
| 結論 | 本件審判の請求は、成り立たない。 |
| 理由 |
1.手続の経緯 本願は、平成14年1月7日(パリ条約による優先権主張 2001年1月10日 大韓民国)に出願したものであって、平成16年7月13日付け拒絶理由通知に対する応答期間(期間延長)内の平成17年1月19日付けで手続補正がなされたが、平成17年8月2日付けで拒絶査定がなされ、これに対して、平成17年11月7日付けで拒絶査定不服審判が請求されるとともに、同年12月7日付けで手続補正がなされたものである。 2.本願発明 本願の請求項1乃至18に係る発明は、平成17年12月7日付け手続補正書の明細書の特許請求の範囲の請求項1乃至18に記載されたとおりのものであるところ、そのうち請求項1に係る発明(以下「本願発明」という。)は、次のとおりである。 「【請求項1】 コンテンツストリームデータが、所定の大きさを有する少なくとも1つの記録単位が集まってなるストリームオブジェクトとして記録された記録媒体において、前記記録単位は1つまたはそれ以上のストリームパックを含み、前記ストリームパックは再生時間情報を表示する応用タイムスタンプ及びコンテンツストリームデータがパッキングされた応用パケットを含み、前記記録単位のうち最後の記録単位を除いた残りは各々少なくとも1つの応用タイムスタンプを全て含み、 前記応用パケットの大きさは前記記録単位が少なくとも1つの応用タイムスタンプをすべて含むように十分に小さく、 前記応用パケットの大きさ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は対応記録単位のスタッフィングバイトの数を、各々意味する。」 3.引用例 これに対し、原査定の拒絶の理由に引用された国際公開第00/68946号パンフレット(2000年11月16日公開、以下「引用例1」という。)には、パケット構造をもって伝送されるストリームデータの記録再生に適したデータ構造に関して、図面と共に次の技術事項が記載されている。(なお、下線は当審で付与した。) (1)「発明の分野 この発明は、デジタル放送などで伝送される映像データあるいはパケット構造をもって伝送されるストリームデータの記録再生に適したデータ構造、このデータ構造を用いてストリームデータを記録する方法、およびこのデータ構造により記録されたストリームデータを再生する方法に関する。」(1頁4?9行) (2)「図1は、この発明の一実施の形態に係るストリームデータのデータ構造を説明する図である。図1には、情報記憶媒体(たとえば相変化記録方式、光磁気記録方式などを利用した光ディスク)上に記録するストリームデータのデータ構造(階層構造)と、その構築過程を示している。 情報記憶媒体上に記録されるストリームデータ(図1(f)のSTREAM.VRO106)は、ストリームデータ内の映像情報のコンテンツ毎に、ストリームオブジェクト(SOBと略記される)としてまとまって記録されている。図1では、そのうちの2個のストリームオブジェクトについて詳細に示され、それらはストリームオブジェクト#A(SOB#A)298とストリームオブジェクト#B(SOB#B)299で表現されている。図1には、STREAM.VRO106(SOB#A・298、SOB#B・299、…)を構成するデータと、それが構築されるまでの途中のデータ構造が示されている。 SOB#A・298は、図1(e)(g)に示すように、ストリームオブジェクトユニット(SOBUと略記される)51、52、…で構成される。同様に、SOB#B・299は、SOBU54、…、SOBU57、…で構成される。 各SOBUは、図1(d)(h)に示すように、複数のストリームパックで構成されている。ここでは、SOB#A・298のSOBU51がストリームパックNｏ.0、Nｏ.1、…Nｏ.31で構成され、SOB#A・298のSOBU52がストリームパックNｏ.32、Nｏ.33、…Nｏ.32n-1で構成された例を示している。 ストリームパックNｏ.0は、図1(c)に示すように、パックヘッダ1と、PESヘッダ＆サブストリームID6と、ロングアプリケーションヘッダ11と、データエリア21とで構成されている。他のストリームパックも同様に構成される。ここで、ロングアプリケーションヘッダ11は記録媒体に記録が行われるときに付加されるものである。記録時には、図1(b)に示すように、データエリア21にはモディファイドタイムスタンプ(あるいはアプリケーションタイムスタンプ)およびアプリケーションパケットの組が1以上含まれる。 …(中略)… DVD-RAMディスクなどの記録媒体にストリームデータを記録する場合には、2048kバイト毎のセクタを最小単位として、記録が行われる。ストリームデータの記録フォーマット(データ構造)では、図1(d)、(h)に示すように、セクタ毎にストリームパックを構成している。ストリームパックは、図1(c)または図1(i)に示すように、パックヘッダ、PESヘッダ＆サブストリームIDと、ロングアプリケーションヘッダまたはショートアプリケーションヘッダと、データエリアとで構成される。 つまり、各ストリームパックの先頭位置には、パックヘッダ1、2、3、4とそれに続くPESヘッダ＆サブストリームID6、7、8、9が配置されている。また、実際のストリームデータが記録されているデータエリア21?26と上記PESヘッダ＆サブストリームID6?9との間には、アプリケーションヘッダが配置されている。この発明の一実施の形態では、記録されるストリームデータの情報内容に応じて、このアプリケーションヘッダとして、ロングアプリケーションヘッダ11、12とショートアプリケーションヘッダ13、14との使い分けを行っている。 …(中略)… 図1に戻って説明を続ける。図1(b)に示すように、デジタルTV放送を受信したときに得られたアプリケーションパケットdを情報記憶媒体上に記録する場合、2個のストリームパックに分割記録することがある。これは、情報記憶媒体の記録エリアを効率的に利用するためである。このときのアプリケーションパケットを部分アプリケーションパケットとして示している。この場合にはストリームパックNｏ.1のデータエリア22の開始位置には、部分アプリケーションパケットd2が配置記録される。 …(中略)… 図1(e)(g)に示すように、複数のストリームパックをまとめてストリームオブジェクトユニットSOBU51?57が形成されている。図1に示した実施の形態では、SOB#A・298内の1個のSOBU51またはSOBU52は32個のストリームパック(セクタ)から構成され、SOB#B・299内の1個のSOBU54またはSOBU57は16個のストリームパック(セクタ)から構成されている。 最後のストリームパック内の最後に記録されたアプリケーションパケットf、ｚ(図1(a)(j))の後ろには、図1(b)(j)に示すように、エンドコード31、32が記録される。これらのエンドコードの後ろには、全てが“1”または全てが“0”のデータで埋められたパディングエリア36、37が適宜設けられる。 ストリーム情報が最後に記録された最後のストリームパックがSOBU57の中央部に位置している場合には、同一SOBU57内でそれ以降のセクタは図1(h)に示すパディングパック40になる。」(9頁4行?14頁9行) (3)「図15は、ストリームパックのデータ構造を説明する図である。各ストリームパックは、図15(b)に示すようなデータ構造を持っている。すなわち、14バイトのパックヘッダと、6バイトのPESヘッダと、1バイトのサブストリームIDと、9バイトのアプリケーションヘッダと、必要に応じて用いられるオプションのアプリケーションヘッダエキステンションと、必要に応じて用いられるオプションのスタッフィングバイトと、アプリケーションタイムスタンプATSが付与されたアプリケーションパケットを1つ以上含むアプリケーションパケット群とで、1つのストリームパックが構成されている。」(61頁4?14行) 上記摘示事項及び図面を総合勘案すると、引用例1には次の発明(以下「引用発明」という。)が記載されているものと認める。 「コンテンツ毎のストリームデータが、ストリームオブジェクトユニット(SOBU)51、52、…で構成されるストリームオブジェクト(SOB)として記録された情報記憶媒体において、 SOBUは、複数のストリームパックで構成され、ストリームパックはアプリケーションタイムスタンプおよびアプリケーションパケットを含む 情報記憶媒体。」 同じく、原査定の拒絶の理由に引用された国際公開第00/46803号パンフレット(2000年8月10日国際公開、以下「引用例2」という。)には、図面と共に、次の技術事項が記載されている。(なお、下線は当審で付与した。) (4)「前述したように1セクタサイズは2048バイトであり、各種ヘッダサイズを差し引いても1個のデータエリア21、22、23、24(図1(c)(i))内にはデジタル放送用のトランスポートパケットが10個前後記録できる。 それに対して、ISDNなどのデジタル通信網では1パケットサイズが4096バイトある大きなロングパケットが転送される場合がある。 デジタル放送などのように1個のデータエリア21、22、23、24(図1(c)(i))内に複数個のトランスパケットを記録するだけでなく、ロングパケットのようにパケットサイズの大きなパケットの場合でも記録できるよう、前記特徴を生かしたデータ構造(1パケットのデータを複数パケットに跨って記録できる特徴)を用いることにより、1個のパケットを複数のデータエリア21、22、23、24に連続して跨るように記録する。 そうすれば、デジタル放送用のトランスポートパケットやデジタル通信用のロングパケットなどは、パケットサイズに依ることなく、全てのパケットをストリームブロック内に端数なく記録することができる。」(42頁25行?43頁18行) (5)「ビットレートが極めて低い記録がなされる場合、タイムマップ情報(第3図(h)の252;あるいは図29のSOBI内MAPL)の回復(再生)を確実にするためにスタッフィングが必要になる。図26(i)のスタッフィングパケットは、そのための概念的な単位として定義されている。このスタッフィングパケットの目的は、スタッフィングエリアを含め夫々のSOBUが少なくとも1つのATS値を含むようにすることで、達成される。」(95頁13?20行) 4.対比 本願発明と引用発明とを対比する。 (1)引用発明の「コンテンツ毎のストリームデータ」「SOBU」及び「情報記憶媒体」は、それぞれ本願発明の「コンテンツストリームデータ」「記録単位」及び「記録媒体」に相当し、引用発明の「ストリームオブジェクト(SOB)」は本願発明の「ストリームオブジェクト」であり、「SOBU」が所定の大きさを有することは明らかであるから、引用発明と本願発明とは「コンテンツストリームデータが、所定の大きさを有する少なくとも1つの記録単位が集まってなるストリームオブジェクトとして記録された記録媒体」で共通する。 (2)引用発明と本願発明の「ストリームパック」は共通し、引用発明の「アプリケーションタイムスタンプ」及び「アプリケーションパケット」は、本願発明の「再生時間情報を表示する応用タイムスタンプ」及び「コンテンツストリームデータがパッキングされた応用パケット」に相当する。 そして、引用発明の「SOBU」は複数のストリームパックで構成され、ストリームパックはアプリケーションタイムスタンプを含むとすることから、引用発明と本願発明とは「記録単位は1つまたはそれ以上のストリームパックを含み、前記ストリームパックは再生時間情報を表示する応用タイムスタンプ及びコンテンツストリームデータがパッキングされた応用パケットを含み、前記記録単位」「は各々少なくとも1つの応用タイムスタンプを全て含み」で共通する。 (3)引用発明では、「SOBU」は「複数のストリームパックで構成され」、「ストリームパック」は、「アプリケーションタイムスタンプおよびアプリケーションパケットを含む」から、引用発明と本願発明とは「応用パケットの大きさは前記記録単位が少なくとも1つの応用タイムスタンプを全て含むように十分に小さく」で共通する。 そうすると、本願発明と引用発明とは、次の点で一致する。 ＜一致点＞ 「コンテンツストリームデータが、所定の大きさを有する少なくとも1つの記録単位が集まってなるストリームオブジェクトとして記録された記録媒体において、前記記録単位は1つまたはそれ以上のストリームパックを含み、前記ストリームパックは再生時間情報を表示する応用タイムスタンプ及びコンテンツストリームデータがパッキングされた応用パケットを含み、前記記録単位は各々少なくとも1つの応用タイムスタンプを全て含み、 前記応用パケットの大きさは前記記録単位が少なくとも1つの応用タイムスタンプを全て含むように充分に小さ(い)記録媒体。」の点。 そして、次の各点で相違する。 ＜相違点＞ (a)本願発明は、「記録単位のうち最後の記録単位を除いた残り」が各々少なくとも1つの応用タイムスタンプを全て含みとするのに対し、引用発明はそのような特定がなされていない点。 (b)本願発明は、応用パケットの大きさ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は対応記録単位のスタッフィングバイトの数を、各々意味する。 5.判断 そこで、上記各相違点について検討する。 相違点(a)について 引用発明において、SOBUは複数のストリームパックで構成され、ストリームパックはアプリケーションタイムスタンプを含むのであるから、SOBUは少なくとも1つのアプリケーションタイムスタンプを含む。 そうすると、SOBUのうち最後のSOBUを除いた残りも少なくとも1つのアプリケーションタイムスタンプを全て含むことも当然のことであって、上記相違点(a)は自明の事項又は適宜なし得る程度のものである。 相違点(b)について 引用発明および本願発明と同一の技術分野に属する上記引用例2には、アプリケーションパケットのパケットサイズ(大きさ)は、放送、通信分野に応じて適宜に設定されること(上記3.(4))、及び、タイムマップ情報の回復(再生)を確実にするためにSOBUが少なくとも1つのATS(アプリケーションタイムスタンプ)を含むようにする(上記3.(5))ことが記載されている。 また、引用例1には、図15のストリームパックのデータ構造について、パックヘッダ等を含む固定のヘッダ、アプリケーションヘッダエキステンション、スタッフィングバイトおよびアプリケーションタイムスタンプ(ATS)付アプリケーションパケットからなるストリームパックのデータ構造が記載(上記3.(3))されており、このストリームパックのデータ構造は本願発明と同一である。 ストリームパックの中でアプリケーションパケットを格納できるエリアは、ストリームパックから固定のヘッダを除いたエリア(本願発明の「SPayload_SZ」に相当)からアプリケーションヘッダエキステンション及びスタッフィングバイトを除いたエリアとなることは明らかである。 そして、引用発明において、SOBUが1つのアプリケーションタイムスタンプを含むとした場合、アプリケーションパケットにはストリームパックに分割記録できること(上記3.(2))を踏まえると、SOBU内のストリームパックの上記エリアから1つのアプリケーションタイムスタンプのバイト数分を除いた残りのエリアとなり、式で表すと、アプリケーションパケットの大きさは本願発明の式において、右辺の値に等しくなる。(上記式の等号の場合にあたる。) また、SOBUが2以上のアプリケーションタイムスタンプを含むようなアプリケーションパケットの場合、2以上のアプリケーションタイムスタンプのバイト数に伴い、アプリケーションパケットを格納するエリアは該増加したアプリケーションタイムスタンプのバイト数分減少するのであるから、アプリケーションパケットの大きさはSOBU内に1つのATSが含まれるとした本願発明の式の右辺の値より小さくなることは明らかであるから、当然にアプリケーションパケットの大きさは上記式において不等式の関係を満たすことも自明のことである。 したがって、引用発明において、異なるアプリケーションパケットのパケットサイズが相違点(b)のような式を満たすとすることは当業者が適宜なし得る程度のことである。 なお、審判請求人は、審判請求の理由において「このようなMPEGシステムの場合は応用パケットの大きさが188バイトに固定されているため、全てのSOBUは複数のATSを有することは当然であり、よって本発明で認識した問題点は全く生じません。しかし、本発明はこのようなMPEGシステムではなく、その他の一般的な状況、すなわち応用パケットの大きさに制限のない環境下では1つの記録単位が一つの応用タイムスタンプも有せない状況も発生しうるので、前記状況を考慮して請求項1のように応用パケットの大きさを決めようとすることです。本願の請求項1で請求したように、応用パケットの大きさを定めると、記録単位が一つの応用タイムスタンプを有せない状況を防止することができます」旨主張している。 しかしながら、通常、応用パケットの大きさは応用分野(放送、通信)により異なるものであり、応用パケットの大きさが本願発明の式を満たすとすることは上記相違点(b)で検討したように当業者が適宜なし得ると判断するものであるから、上記審判請求人の主張は採用できない。 そして、上記相違点を総合的に判断しても、本願発明が奏する効果は引用例1及び引用例2から、当業者が十分に予測できたものであって、格別なものとはいえない。 6.むすび 以上のとおり、本願の請求項1に係る発明は、引用例に記載された発明及び引用例2の記載事項に基づいて当業者が容易に発明をすることができたものであるから、特許法第29条第2項の規定により特許を受けることができない。 したがって、本願は、その余の請求項について論及するまでもなく拒絶すべきものである。 よって、結論のとおり審決する。 |
| 審理終結日 | 2009-03-12 |
| 結審通知日 | 2009-03-17 |
| 審決日 | 2009-03-30 |
| 出願番号 | 特願2002-961(P2002-961) |
| 審決分類 |
P
1
8・
537-
Z
(G11B)
P 1 8・ 121- Z (G11B) |
| 最終処分 | 不成立 |
| 前審関与審査官 | 齋藤 哲 |
| 特許庁審判長 |
小松 正 |
| 特許庁審判官 |
山田 洋一 江畠 博 |
| 発明の名称 | コンテンツストリームデータが記録された記録媒体、その記録装置及び再生装置 |
| 代理人 | 村山 靖彦 |
| 代理人 | 志賀 正武 |
| 代理人 | 渡邊 隆 |
| 代理人 | 実広 信哉 |