【事件の表示】
　特願２００２−１３０９６２「適応多重化／逆多重化方法及び装置」拒絶査定不服審判事件〔平成１５年　１月２４日出願公開、特開２００３−　２３６１１〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
第一　経緯
１　手続
　本願は、１９９８年（平成１０年）６月９日（パリ条約による優先権主張　１９９７年９月２２日　（ＵＳ）アメリカ合衆国）を国際出願日とする出願（特願２０００−５１３３７４号）の一部を新たな特許出願とした平成１４年５月２日の出願であり、平成１７年１１月８日付けで手続補正がなされたが、平成１８年４月１０日付けで拒絶査定された。
　本件は、本願についてされた上記拒絶査定を不服とする平成１８年７月１８日の審判請求であり、請求後、平成１８年７月２４日付けで手続補正書（明細書又は図面について請求の日から３０日以内にする補正）が提出された。
　
　当審において、平成２１年７月１７日付けで査定の理由とは異なる拒絶の理由を通知したところ、平成２１年１０月２１日付けで意見書及び手続補正書が提出された。
　
２　当審の拒絶の理由
　当審が平成２１年７月１７日付けで通知した拒絶の理由は、概略、以下のとおりである。
　
　　　　　　　　　　　　　　　理　由
《理由１》
　本願の請求項１ないし２に係る発明は、その出願前日本国内又は外国において頒布された下記刊行物に記載された発明に基づいて当業者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。
　
　　　　　　　　　　　　　　　　記
刊行物１：「ＩＴＵ−Ｔ　Ｈシリーズ（オーディオビジュアル／マルチメディア関連）勧告集（その２）」、財団法人新日本ＩＴＵ協会、平成９年４月３０日、ｐｐ．２２−４３
刊行物２：特開平４−２７８７３５号公報
刊行物３：特開平４−１１９０３１号公報
刊行物４：特開平５−１３０００７号公報
刊行物５：TOM GEARY、Multiplexing Protocol for Low Bitrate Multimedia Communication over Low Error-Prone Channels、Draft Recommendation H.223 - Annex A、１９９７年９月１１日
　
《理由２》
　この出願は、明細書及び図面の記載が下記の点で不備のため、特許法第３６条第６項第２号に規定する要件を満たしていない。
　
　　　　　　　　　　　　　　　　記
　請求項３に係る発明の構成は明確ではない。
　
３　平成２１年１０月２１日付け手続補正
　平成２１年１０月２１日付け手続補正は、特許請求の範囲を下記のとおり、補正するものである。（下線は、請求人が付した補正箇所を示す。）
　
　　　　　　　　　　　　　　　　記
　「【請求項１】　マルチメディアデジタルシステムにおける、マルチメディア多重化／逆多重化方法において、
　（ａ）マルチメディアデータを符号化する過程と、
　（ｂ）前記（ａ）過程において符号化されたマルチメディアデータを、同期コードが付加された所定単位に多重化する過程と、
　（ｃ）前記（ｂ）過程において多重化された所定単位毎に付加された同期コードに、通信環境に応じた選択に基づいて、少なくとも一つ以上のビットを、さらに付加する過程とを含み、
　前記（ｂ）過程における多重化は、Ｈ．２２３勧告を適用することを特徴とするマルチメディア多重化／逆多重化方法。
　　【請求項２】　前記マルチメディアデジタルシステムは、Ｈ．３２４規格が適用されることを特徴とする請求項１記載のマルチメディア多重化／逆多重化方法。
　　【請求項３】　前記（
ｃ
いてさらに付加された
　
　
第二　本願発明
　本願の請求項１ないし３に係る発明は、本願明細書及び図面（平成１７年１１月８日付け、平成１８年７月２４日付け、平成２１年１０月２１日付けの各手続補正書により補正された明細書及び図面）の記載からみて、それぞれ、特許請求の範囲の請求項１ないし３に記載したとおりのものであるところ、そのうち、請求項１に係る発明（再掲、以下「本願発明」という）は、以下のとおりのものである。
　
「マルチメディアデジタルシステムにおける、マルチメディア多重化／逆多重化方法において、 
　（ａ）マルチメディアデータを符号化する過程と、
　（ｂ）前記（ａ）過程において符号化されたマルチメディアデータを、同期コードが付加された所定単位に多重化する過程と、
　（ｃ）前記（ｂ）過程において多重化された所定単位毎に付加された同期コードに、通信環境に応じた選択に基づいて、少なくとも一つ以上のビットを、さらに付加する過程とを含み、
　前記（ｂ）過程における多重化は、Ｈ．２２３勧告を適用することを特徴とするマルチメディア多重化／逆多重化方法。」
　
　
第三　当審の判断
１　刊行物
（１）刊行物の記載
ア　刊行物１の記載
　当審の拒絶の理由で引用された刊行物１には、図面とともに、以下の事項が記載されている。
　
（ａ）「勧告Ｈ．２２３
　　　　低ビットレートマルチメディア通信用多重化プロトコル
１．通　則
　この勧告は，低ビットレートマルチメディア通信のためのフレーム構造，フィールドフォーマットおよびパケット多重化手順を規定する。このプロトコルは２つの低ビットレートマルチメディア端末間，または，低ビットレートマルチメディア端末と多地点制御ユニット（ＭＣＵ）または相互接続アダプタ（ＩＷＡ）との間での使用が可能である。この多重化プロトコルの実施に必要な制御手順は，勧告Ｈ．２４５に規定されている。」（第２２頁第１〜７行）
　
（ｂ）「５．概　要
　この勧告は，データおよび制御プロトコルとオーディオおよびビデオコーデックのような，上位層エンティティ間における１または複数の情報ストリームの交換のためのパケット指向の多重プロトコルを規定するものである。
・・・（略）・・・ 
　多重化部の一般的な構造を図２／Ｈ．２２３に示す。多重化部は，多重化（ＭＵＸ）レイヤとアダプテーションレイヤ（ＡＬ）との２つの個別のレイヤにより構成される。」（第２４頁第３１行〜第２５頁第３行）
　
（ｃ）「５．１　多重化（ＭＵＸ）レイヤの概要
　ＭＵＸレイヤは，ＡＬから受信した受信した方法を，下位物理レイヤのサービスを使用して相手端末に転送することを任務とする。ＭＵＸレイヤは，ＭＵＸ−ＳＤＵと呼ばれる論理的ユニットによってＡＬと情報を交換する。ＭＵＸ−ＳＤＵは，単一の論理チャネルに所属する整数個のオクテットを常に含む。ＭＵＸ−ＳＤＵ，一般に，受信側で解釈を必要とするフィールドの位置が開始と終了によってマークされる情報ブロックを示す。
　ＭＵＸ−ＳＤＵは，１つまたは複数のＭＵＸ−ＰＤＵと呼ばれる可変長パケットで，ＭＵＸレイヤによって転送される。ＭＵＸ−ＰＤＵは，１オクテットのヘッダとこれに続く可変数のオクテットの情報フィールドとで構成される。ＭＵＸ−ＰＤＵは，ＨＤＬＣフラグにより区切られる。ＨＤＬＣＤビット挿入法はフラグがＭＵＸ−ＰＤＵ内で誤認識されないために用いる。」（第２５頁第４〜１２行）
　
（ｄ）「５．２　アダプテーションレイヤの概要
・・・（略）・・・
●　ＡＬ２は，主としてデジタルオーディオの転送を目的とするものである。ＡＬ２は，おそらくは可変長のＡＬ−ＳＤＵでのその上位レイヤ（例えば，オーディオ符号器）からの情報を受け取り，８ビットＣＲＣ用に１オクテット，また，オプションとしてシーケンスナンバリング用に１オクテットを追加してこれをＭＵＸ−ＳＤＵによってＭＵＸレイヤに引き渡す。
●　ＡＬ３は，主としてデジタルビデオの転送を目的とするものである。ＡＬ３は，おそらくは可変長のＡＬ−ＳＤＵでのその上位レイヤ（例えば,ビデオ符号器）からの情報を受け取り，１６ビットＣＲＣ用に２オクテット，また，オプションとして１または２オクテットを追加して，これをＭＵＸ−ＳＤＵによってＭＵＸレイヤに引き渡す。ＡＬ３は，ビデオ用再送プロトコルを含む。」（第２６頁第９〜３１行）
　
（ｅ）「６．３　ＭＵＸ−ＰＤＵフレーム化
　すべてのＭＵＸ−ＰＤＵは，ＨＤＬＣフラグを使用して区切られなければならない。
６．３．１　フラグ
　すべてのＭＵＸ−ＰＤＵには，その前後に固有のビットパターン，“０１１１１１１０”からなるフラグが配置されなければならない。ＭＵＸ−ＰＤＵに先行するフラグは，開始フラグとして定義される。ＭＵＸ−ＰＤＵに続くフラグは，終結フラグとして定義される。終結フラグは次のＭＵＸ−ＰＤＵの開始フラグとして使用してもよい。しかし，フラグはＭＵＸ−ＰＤＵの間で繰り返し伝送されることがあるため，本勧告に準拠するすべての受信装置は，連続する複数のフラグを受信することができるものでなければならない。」（第２７頁第１８〜２５行）
　
（ｆ）「６．４　ＭＵＸ−ＰＤＵのフォーマットおよび符号化
　すべてのＭＵＸ−ＰＤＵは，図３／Ｈ．２２３に示すフォーマットに準拠しなければならない。
６．４．１　ヘッダ
　ヘッダのフォーマットは，図４／Ｈ．２２３に示すフォーマットに準拠しなければならない。」（第２７頁第３１行〜第２８頁第２行）
　
（ｇ）「６．６　事例
　表２／Ｈ．２２３は，elementListに１，２または３のMultiplexElementsを含むMultipleEntryDescriptorsの例を示すものである。表の各行は，MultipleEntryDescriptorに対応する。各MultipleEntryDescriptorについて，elementListにおけるMultiplexElementsの数，入れ子深度およびsubelementListサイズが別の例に示されている。
　以下のとおり，５つの論理チャネルが想定されている。ＬＣＮ０：制御，ＬＣＮ１：オーディオ１，ＬＣＮ２：データ，ＬＣＮ３：ビデオ，ＬＣＮ４：オーディオ２。オーディオ論理チャネルは分割不可能として指定されており，その他はすべて分割可能として指定されている。
　最初の５行は，基本的なMultipleEntryDescriptorの例を示したものである。
　最初の２行は，ＭＵＸ−ＰＤＵ情報フィールド全体が単一の論理チャネルに割り当てられる方法について示したものである。第１行に示したエントリは任意の長さのオーディオＭＵＸ−ＳＤＵを送信するために使用することができるが，複数のオーディオＭＵＸ−ＳＤＵの送信に使用できないことに留意されたい。
　第３行は，単一のＭＵＸ−ＰＤＵにおけるオーディオＭＵＸ−ＳＤＵの後で，ビデオを送信する方法について示したものである。
　第４行は，データ１オクテットおよび３オクテットのビデオの繰り返しパターンを使用してデータとビデオとを混在させる方法について示したものである。
　第５行は，データとビデオの繰り返しパターンを使用しておそらくは，無音期間中に送られる背景雑音情報を示す短いオーディオＭＵＸ−ＳＤＵを混在させる方法について示したものである。このエントリは，情報フィールドの構成を例示するために後で本節において使用する。
・・・（略）・・・
　図５／Ｈ．２２３は，MultipleEntryDescriptorからの情報フィールドの構成を示し，ＰＭフィールドの使用を例示したものである。この例では，表２／Ｈ．２２３の第５行で示したMultipleEntryDescriptorが使用されている。
　この例では，ある時点で多重化部が送信の準備を終えている３つのＭＵＸ−ＳＤＵ，すなわち，ＬＣＮ１からの４オクテットＭＵＸ−ＳＤＵ，ＬＣＮ２からの３オクテットＭＵＸ−ＳＤＵおよびＬＣＮ３からの３オクテットＭＵＸ−ＳＤＵを持っていることを想定している。
　ＭＵＸ−ＳＤＵは，ＬＣＮ１からの４オクテットＭＵＸ−ＳＤＵに始まり，ＬＣＮ２からの１オクテットセグメント，ＬＣＮ３からの２オクテットセグメント，ＬＣＮ２からの１オクテットセグメントおよびＬＣＮ３からのもう一つの１オクテットセグメントと続いて形成される。このときＬＣＮ３からのＭＵＸ−ＳＤＵが終わりに達するので，ＭＵＸ−ＰＤＵは，フラグをもって終結され，次のＭＵＸ−ＰＤＵのＰＭフィールドがセットされる。ＬＮ２からのＭＵＸ−ＳＤＵの最終オクテットは，次に続くＭＵＸ−ＰＤＵのいずれかによって送信することができる。」（第３１頁第１４行〜第３３頁第４行）
　
イ　刊行物２の記載
　当審の拒絶の理由で引用された刊行物２には、図面とともに、以下の事項が記載されている。
　
（ｈ）「【特許請求の範囲】
【請求項１】　受信機能を有する１台の親局と、送信機能を有する複数の子局から構成される無線通信システムにおいて、前記親局および前記子局間の通信に使用されるデータフォーマットの一部を前記親局が受信状態を検知することにより、変更できることを特徴とした無線通信システム。」
　
（ｉ）「【０００１】
【産業上の利用分野】本発明は単向通信におけるデータの通信方式に関する。」
　
（ｊ）「【０００２】
【従来の技術】従来、デジタル信号による無線通信においては、図４に示すような同期コード、データからなるデータフォーマットが使用されている。このデータフォーマットの内、データについては送信される内容によって変更されるものであるが、同期コードの部分は、子局、親局間の取り決めによる一定の符号が使用されている。図３は１台の親局１１と、複数の子局１２で構成された従来の無線通信システムの一例を示したものである。
このシステムにおいて親局側に電波の有無検出機能がない場合には、親局は常に白色雑音を受信していることになる。この白色雑音を図４に示すデータフォーマット中の同期コード１３と判断しないように、同期コードのビット長は十分に取る必要がある。また白色雑音を同期コードと判断してしまうビット長は親局の受信回路の特性により大きく変動することから、その値も考慮して同期コードのビット長を決める必要がある。」
　
（ｋ）「【０００３】
【発明が解決しようとする課題】しかし、従来の方法における親局の従来の方法では、親局の受信回路の特性にかかわらず常にデータフォーマットのビット長は同一であり、送信時間が長くなるために、子局側の消費電流の増大や伝送効率が悪くなるという欠点を有していた。また伝送効率を上げようとするために、同期コードのビット長を短くすることにより、白色雑音による受信エラーが増えるという欠点を有していた。」
　
（ｌ）「【０００４】
【課題を解決するための手段】上記の課題を解決するために、本発明においてはシステムの利用開始時に親局が予め用意された複数のビット長の異なる同期コードについて、白色雑音の受信状態で白色雑音を同期コードと判断するか否かの確認を行い、その結果により、システムにおいて使用するデータフォーマット中の同期コードを決定することにした。」
　
（ｍ）「【０００６】
【実施例】以下に本発明の実施例を図面に基づいて説明する。図１は、本発明の一実施例を示す親局のブロック図である。変調された無線データを復調する受信部１、そのデータを取込み処理を行う制御部２、予め決められた同期コード及び受信データを記憶する記憶部３、時間の計測を行う計時部５、受信データ等を表示する表示部４で構成されている。親局は動作として同期コードを選択するモードと、運用モードの２つのモードを持っている。親局はシステムとしての利用を開始する前に、同期コードの選択モードとなり、白色雑音の受信を行う。
【０００７】受信部１によって受信された白色雑音は、制御部２で記憶部３に記憶されている同期コードデータと比較を行う。同期コードはビット長の異なるものが複数種類用意されており、ビット長の短いものから比較が行われる。比較を行う時間は、計時部５にて計測する。
決められた時間経過した後、白色雑音を同期コードとして認識しない、最も短い同期コードのパターンについて、表示部４に表示する。
【０００８】例えば図５に示す３種類のビット長の異なる同期コードについて、まず（ａ）について白色雑音との比較を一定時間行う。その結果、白色雑音を同期コードと認識しない場合は、（ａ）の同期コードを使用する。また、同期コードと認識された場合は、次の（ｂ）について行う。（ｃ）についても同様である。同期コードが決定した後、親局は運用モードとなる。次に子局側に対する送信信号であるデータフォーマットの設定について説明する。」
　
（２）刊行物１に記載された発明
　刊行物１に記載された発明（以下「刊行物発明」という）として、「マルチメディア多重化／逆多重化方法」の発明を認定する。
　
ア　マルチメディア多重化／逆多重化方法
　刊行物１は、勧告Ｈ．２２３「低ビットレートマルチメディア通信用多重化プロトコル」を説明するところ、
　当該プロトコルは、「２つの低ビットレートマルチメディア端末間，または・・・との間での使用が可能である」｛上記（ａ）｝ものであるから、「
マルチメディアデジタルシステムにおける
　したがって、刊行物発明として、「勧告Ｈ．２２３で勧告される低ビットレートマルチメディア通信用多重化プロトコルを適用した、マルチメディアデジタルシステムにおける、マルチメディア多重化／逆多重化方法」の発明を、認定することができる。
　
イ　符号化する過程
　上記（ｂ）（ｄ）、図２／Ｈ．２２３（Ｈ．２２３プロトコルスタック）には、オーディオおよびビデオを符号化する過程が認められ、符号化されたオーディオおよびビデオは多重化部（多重化（ＭＵＸ）レイヤとアダプテーションレイヤ（ＡＬ）により構成される多重化部）に渡される。
　したがって、刊行物発明として「マルチメディアデータを符号化する過程」を含むものを認定することができる。
　
ウ　多重化する過程
　上記（ｂ）〜（ｆ）、図３／Ｈ．２２３（ＭＵＸ−ＰＤＵフォーマット）によれば、勧告Ｈ．２２３の多重化プロトコルでは、多重化（ＭＵＸ）レイヤにおいて、ヘッダとこれに続く可変長の情報フィールドで構成されるＭＵＸ−ＰＤＵ（多重化−プロトコルデータユニット）と呼ばれるパケットには、すべて、開始フラグとして定義されるＨＤＬＣフラグ（“０１１１１１１０”）が配置されている｛上記（ｅ）｝。
　また、上記（ｂ）（ｄ）（ｆ）（ｇ）、図２／Ｈ．２２３（Ｈ．２２３プロトコルスタック）によれば、符号化されたデジタルオーディオおよびビデオは、アダプテーションレイヤ（ＡＬ）から、ＭＵＸ−ＳＤＵによって多重化（ＭＵＸ）レイヤに渡され｛上記（ｄ）｝、ＭＵＸレイヤでは、例えば、上記（ｇ）、図５／Ｈ．２２３（情報フィールドの例）にみられるように、ヘッダと、ＬＣＮ１（オーディオ）、ＬＣＮ２、・・・ＬＣＮ３（ビデオ）からなる情報フィールドとからなるＭＵＸ−ＰＤＵとされたパケットにフラグ、すなわちＨＤＬＣフラグが付加されたものを単位として多重化される。
　したがって、刊行物発明として「ヘッダと、これに続く符号化されたマルチメディアデータを含む情報フィールドとからなるユニット（ＭＵＸ−ＰＤＵ）に、開始フラグとしてＨＤＬＣフラグを付加したものを単位として多重化する過程」を含むものを認定することができる。　
　
エ　まとめ
　上記アないしウによれば、刊行物発明として、以下のとおりのものを認定することができる。
　
「勧告Ｈ．２２３で勧告される低ビットレートマルチメディア通信用多重化プロトコルを適用した、マルチメディアデジタルシステムにおける、マルチメディア多重化／逆多重化方法として、
　マルチメディアデータを符号化する過程と、
　ヘッダと、これに続く符号化されたマルチメディアデータを含む情報フィールドとからなるユニット（ＭＵＸ−ＰＤＵ）に、開始フラグとしてＨＤＬＣフラグを付加したものを単位として多重化する過程と
を含む方法。」
　
（３）刊行物２に記載された技術
　刊行物２には、上記（ｉ）を産業上の利用分野、上記（ｊ）を従来の技術、上記（ｋ）を解決しようとする課題とするもので、上記（ｈ）（ｌ）（ｍ）記載のようにした、同期コードを白色雑音の受信状況に応じて選択する無線通信システムが記載されている。
　具体的には、白色雑音を同期コードと誤って判断しないように、同期コードのビット長は十分に取る必要があり、また白色雑音を同期コードと判断してしまうビット長は大きく変動することから、その値も考慮して同期コードのビット長を決める必要がある｛上記（ｊ）｝と認識されていたものの、
　従来、同期コードのビット長は同一であったために、伝送効率が悪くなるという欠点を有しており、また伝送効率を上げようとするために、同期コードのビット長を短くすると、白色雑音による受信エラーが増えるという欠点を有していた｛上記（ｋ）｝という課題があったところ、
　この課題を解決するために、ビット長の異なる複数の同期コードを用意しておき、システムの利用開始時（同期コードの選択モード）に、白色受信の受信を行い、記憶されている同期コードとビット長の短いものから比較が行われ、その結果、白色雑音を同期コードと認識しない場合は、その同期コード｛図５（ａ）｝を使用し、また、同期コードと認識された場合（すなわち、白色雑音を同期コードと誤認識した場合）は、そのビット長より長い次のビット長の同期コード｛図５（ｂ）｝ついても同様にして比較を行い、運用モード時における同期コードを決定する｛上記（ｈ）（ｌ）（ｍ）｝ことが記載されている。
　より長いビット長の同期コードは、よりエラー耐性が高い同期コードといえる｛後記４（２）ア｝から、より長いビット長の同期コードへの変更は、『よりエラー耐性が高い同期コードへの変更』であるということができ、また、当該変更は、白色雑音の受信状況に応じて選択しているのであるから、当該変更を、『通信環境に応じた選択に基づいて行う』ものということができる。
　
　以上のとおりであるから、刊行物２に記載された技術〈刊行物２記載技術〉として、『よりエラー耐性が高い同期コードへの変更を、通信環境に応じた選択に基づいて行う技術』を認めることができる。
　
２　対比
　本願発明と刊行物発明とを対比する。
  　
（１）「マルチメディアデジタルシステムにおける、マルチメディア多重化／逆多重化方法」について
　本願発明と刊行物発明とは、「マルチメディアデジタルシステムにおける、マルチメディア多重化／逆多重化方法」である点において、両者に相違はない。
　
（２）「（ａ）マルチメディアデータを符号化する過程」について
　本願発明と刊行物発明とは、「（ａ）マルチメディアデータを符号化する過程」を含む点において、両者に相違はない。
　
（３）「（ｂ）前記（ａ）過程において符号化されたマルチメディアデータを、同期コードが付加された所定単位に多重化する過程」、及び、「前記（ｂ）過程における多重化は、Ｈ．２２３勧告を適用すること」について
　本願発明でいう「同期コード」は、本願明細書の『【００１１】図５（ａ）は通常のＨ．２２３ ＭＵＸ／ＤＥＭＵＸ２１０のＭＵＸ−ＰＤＵの構成図である。Ｈ．２２３ ＭＵＸ／ＤＥＭＵＸ２１０のＭＵＸ−ＰＤＵは伝送制御のために用いられる８ビットＨＤＬＣフラグ３１０、データ情報を含む８ビットヘッダ３２０、そしてビデオ及びオーディオデータを含むペイロード(Payload)３３０を具備する。ここでＭＵＸ−ＰＤＵはＭＵＸにおいてオーディオ、ビデオ、データを多重化して発生した最小限の単位(Unit)であって、チャンネルインタフェース前に生成される。またＨＤＬＣフラグ３１０はフレームの開始または終了を示す６連続の１(例えば、０１１１１１１０)のユニークなビットパターンである。
【００１２】図５（ｂ）はＨ．２２３ ＭＵＸ／ＤＥＭＵＸ２１０の上位レベルＭＵＸ／ＤＥＭＵＸとして動作する第１ＭＵＸ／ＤＥＭＵＸ２２０のＭＵＸ−ＰＤＵの構成図である。第１ＭＵＸ／ＤＥＭＵＸ２２０のＭＵＸ−ＰＤＵはＨ．２２３勧告より多くのビットを有する少なくとも８ビット以上の長いＨＤＬＣフラグ３４２、データ情報の含まれた８ビットヘッダ３４４、ビデオ、オーディオデータの含まれたペイロード３４６を具備する。第１ ＭＵＸ／ＤＥＭＵＸ２２０は図５（ｂ）に示されたように、Ｈ．２２３ ＭＵＸ／ＤＥＭＵＸ ２１０のＭＵＸ−ＰＤＵにおいてビデオ及びオーディオ信号間の同期化を向上させるために多くのビットのＨＤＬＣフラグを採択する。・・・』、図５（ａ）（ｂ）の記載に照らせば、
　勧告Ｈ．２２３で規定される「ＨＤＬＣフラグ」を含むものであるところ、その「ＨＤＬＣフラグ」は、刊行物発明の「開始フラグとして」の「ＨＤＬＣフラグ」と相違しない。
　すなわち、刊行物発明の「開始フラグとして」の「ＨＤＬＣフラグ」は、本願発明でいう「同期コード」と相違しない。
　そして、本願発明でいう、「前記（ｂ）過程における多重化は、Ｈ．２２３勧告を適用すること」とした、「（ｂ）前記（ａ）過程において符号化されたマルチメディアデータを、同期コードが付加された所定単位に多重化する過程」（以下、本節において“（ｂ）過程”という）とは、
　同じく本願明細書の上記記載に照らせば、『ＨＤＬＣフラグ（３１０、３４２）、ヘッダ（３２０、３４４）、ビデオおよびオーディオを含むペイロード（３３０、３４６）からなる単位（ＭＵＸ−ＰＤＵ）に多重化すること』をいうところ、
　刊行物発明の「ヘッダと、これに続く符号化されたマルチメディアデータを含む情報フィールドとからなるユニット（ＭＵＸ−ＰＤＵ）に、開始フラグとしてＨＤＬＣフラグを付加したものを単位として多重化する過程」も、『ＨＤＬＣフラグ、ヘッダ、ビデオおよびオーディオを含むペイロードからなる単位に多重化するもの』であるから、
　刊行物発明のこの過程は、本願発明の“（ｂ）過程”に相当する過程といえ、両過程は相違しない。
（なお、本願発明では、ＨＤＬＣフラグを含めたものを「ＭＵＸ−ＰＤＵ」と称するのに対して、刊行物１ではＨＤＬＣフラグを除いた部分を「ＭＵＸ−ＰＤＵ」と称していて、何を「ＭＵＸ−ＰＤＵ」というかの点で相違するが、そのような相違に関係なく、「同期コードが付加された所定単位に多重化する過程」を含む点、及び、その多重化単位の実質的内容においては、両者間に相違はない。）
　
（４）「（ｃ）前記（ｂ）過程において多重化された所定単位毎に付加された同期コードに、通信環境に応じた選択に基づいて、少なくとも一つ以上のビットを、さらに付加する過程」について
　本願発明では、「（ｃ）前記（ｂ）過程において多重化された所定単位毎に付加された同期コードに、通信環境に応じた選択に基づいて、少なくとも一つ以上のビットを、さらに付加する過程」を含むのに対し、刊行物発明では、そのような過程を含んでいない点で相違が認められる。
　
３　一致点、相違点
　以上の対比によれば、本願発明と刊行物発明とは、
［一致点］
「マルチメディアデジタルシステムにおける、マルチメディア多重化／逆多重化方法において、
　（ａ）マルチメディアデータを符号化する過程と、
　（ｂ）前記（ａ）過程において符号化されたマルチメディアデータを、同期コードが付加された所定単位に多重化する過程と、
　を含み、
　前記（ｂ）過程における多重化は、Ｈ．２２３勧告を適用することを特徴とするマルチメディア多重化／逆多重化方法。」
である点で一致し、以下の点で相違している。
　
［相違点］
　本願発明では、（ｃ）前記（ｂ）過程において多重化された所定単位毎に付加された同期コードに、通信環境に応じた選択に基づいて、少なくとも一つ以上のビットを、さらに付加する過程を含むのに対し、
　刊行物発明では、そのような過程を含んでいない点。
　
４　判断
（１）［相違点の克服］
　刊行物発明の「ヘッダと、これに続く符号化されたマルチメディアデータを含む情報フィールドとからなるユニット（ＭＵＸ−ＰＤＵ）に、開始フラグとしてＨＤＬＣフラグを付加したものを単位として多重化する過程」において多重化された所定単位毎に付加されたＨＤＬＣフラグ（同期コード）に、通信環境に応じた選択に基づいて、少なくとも一つ以上のビットを、さらに付加する過程を付加することで、本願発明に至る。
　
（２）上記［相違点の克服］の容易想到性
ア　技術常識
　一般に、「同期コード」は、伝送するべき目的のデータが開始することを示すために使用される特定の符号、すなわち『特定のビット列（パターン）』をいうものであり、受信される一連のビット列とその『特定のビット列（パターン）』の一致をみて（一致を検知することで）目的のデータの開始を認識する（すなわち同期を検出する）ことがその利用形態の基本であるところ、
　「同期コード」のビット長が長ければ、元々（送信端では）「同期コード」ではなかったビット列が通信経路のノイズにより変化しても、『特定のビット列（パターン）』と一致するビット列となる可能性は、ビット長が長い分だけ基本的には減少することは当然であり、その結果、受信端で元来「同期コード」ではなかったものを「同期コード」と誤認識することが少なくなること、すなわち、「同期コード」のビット長が長ければノイズによるエラー耐性が高まること、逆に短かければノイズによるエラー耐性が低下することは自明である。
　また、このこと（「同期コード」のビット長が長ければエラー耐性が高まり、逆に短ければエラー耐性が低下すること）は、当業者が十分認識している周知の事項｛例えば、刊行物２（段落【０００２】、【０００３】）、刊行物３及び刊行物５（下記参照）等参照｝でもある。
　すなわち、「同期コード」のビット長が長ければエラー耐性が高まり、逆に短かければエラー耐性が低下することは、当業者の技術常識である。
　
イ　容易想到性判断
　刊行物発明の勧告Ｈ．２２３の多重化プロトコル技術を、モバイルチャンネルのようにエラーの多い環境の中で使用することは、当業者が困難無くごく普通に想定し得るところ、
　そのような場合、同期コード（開始コード）として用いる８ビット長のＨＤＬＣのエラー耐性が十分でなくなることも、当業者が容易に想定し得ることである。（事実、刊行物５では、下記のとおり、モバイルチャンネルのようにエラーの多い環境の中で使用する場合、多重化プロトコルＨ．２２３の８ビットのＨＤＬＣフラグに代えて、１６ビット長のユニークなビットパターンから成るフラグを用いている。）
　そして、上述したように、「同期コード」のビット長が長ければエラー耐性が高まり、逆に短かければエラー耐性が低下することは、当業者の技術常識であるから、刊行物発明の勧告Ｈ．２２３の多重化プロトコル技術を、モバイルチャンネルのようにエラーの多い環境の中で使用する場合において、エラー耐性を高くするため、８ビット長のＨＤＬＣフラグより長いビット長の同期コードを用いようとすることは、当業者が容易に想起することといえ、その場合において、８ビット長のＨＤＬＣフラグより長いビット長の同期コードを、８ビット長のＨＤＬＣフラグに
単に１つ以上のビットを付加したもの
　また、上記１（３）のとおり、『よりエラー耐性が高い同期コードへの変更を、通信環境に応じた選択に基づいて行う技術』〈刊行物２記載技術〉も知られているのであるから、よりエラー耐性が高い同期コードへの変更に、当該技術を適用することも当業者にとって困難なこととはいえない。
　よって、上記［相違点の克服］は、技術常識、周知事項、刊行物２記載技術に基づいて当業者が容易になし得ることである。
　
ウ　まとめ 
　以上のとおりであるから、刊行物発明を出発点として、上記［相違点の克服］をすることで本願発明の構成に達するところ、この［相違点の克服］は当業者が容易になし得ることである。
　そして、本願発明の構成は、上記のとおり当業者容易想到であるところ、本願発明の効果は、その容易想到である構成から当業者が予測し得る範囲内のものであり、同範囲を超える格別顕著なものもない。
　
　　　　　　　　　　　　　記（周知例一覧）
刊行物３：特開平４−１１９０３１号公報
「〔産業上の利用分野〕
　本発明は、フレーム同期パターンを含むフォーマットのフレームによってデータ通信を行うデータ通信システムに関する。
　データをフレーム単位で伝送するデータ通信システムにおいては、受信側においてフレームの位相を正しく認識するために、各フレームの先頭にフレーム同期パターンを含んでいる。
　このフレーム同期パターンは、同期引き込みの安全性、確実性の点からは、長いことが望ましく、また、伝送効率の点からは短いことが望ましい。
〔従来の技術および発明が解決しようとする課題〕
　・・・（略）・・・フレーム同期パターンは、同期引き込みの確実性の点からは、長いことが望ましく、また、伝送効率の点からは短いことが望ましいが、常にフレーム同期パターンの長さを一定にして、この２つの条件を同時に両立させることは困難であるため、同期引き込みの安全性、確実性の点を重要視してフレーム同期パターンを長くすれば伝送効率が低下し、また、伝送効率の点を重要視してフレーム同期パターンを短くすれば同期引き込みの安全性、確実性が低下して、擬似同期引き込み等を起こすという問題があった。」（第２頁右下欄〜第３頁左上欄）
　
　上記「同期パターンを短くすれば同期引き込みの安全性、確実性が低下して、擬似同期引き込み等を起こす」とは、短くすれば、本来同期パターンでないものを同期パターンと誤認識することを意味し、逆に、長ければ、そのような誤認識を起こしにくくなることを意味するものである。すなわち、「同期コード」のビット長ければエラー耐性が高まり、逆に短ければエラー耐性が低下すると理解し得るものである。
　
　
刊行物５：TOM GEARY、Multiplexing Protocol for Low Bitrate Multimedia Communication over Low Error-Prone Channels、Draft Recommendation H.223 - Annex A、１９９７年９月１１日
“This Annex specifies an error robust framing scheme for multiplexing protocol H.223. The protocol provides robustness against transmission errors occuring in error prone environment like mobile channels. HDLC framing defined in H.223 is replaced by a longer flag without performing HDLC zero bit insertion.”（第１頁「SUMMARY」）
（訳）「この付録は、多重化プロトコルＨ．２２３のためのエラーに強いフレーミングスキームを規定します。このプロトコルは、モバイルチャンネルのようなエラーが多い環境の中で生じる送信エラーに対する強健さを提供します。Ｈ．２２３に定義されるＨＤＬＣフレーミングは、ＨＤＬＣゼロビット挿入を行なうことなく、より長いフラグよって置き換えられます。」
　
“In the basic mode, which in mandetory, all MUX-PDUs shall be delimited using 16-bit flags. Level 1 transmissions shall start in the basic mode.”（第４頁「A.2.1 MUX-PDU framing」）
（訳）「義務的であるベーシックモードでは、すべてのＭＵＸ−ＰＤＵは、１６ビットフラグを使用して境界を定められる。レベル１の送信はベーシックモードで開始される。」
　
“In the basic mode all MUX-PDUs shall be preceded and followed by the 16-bit flag consisting of the following unique bit pattern:”（第４頁「A.2.1.1 Flag」）
(訳)）「ベーシックモードでは、すべてのＭＵＸ−ＰＤＵは、次のユニークなビットパターン（審決注：第４頁「Figure 1」）から成る１６ビットフラグによって先行しそして後続します。」
　
　上記記載の「多重化プロトコルＨ．２２３」は、刊行物１などに記載される勧告Ｈ．２２３であり、Ｈ．２２３での「ＨＤＬＣフレーミング」では、８ビットのＨＤＬＣフラグ“０１１１１１１０”が用いられていることは明らかであるから、刊行物５では、８ビットのＨＤＬＣフラグに代えて、ユニークなビットパターンから成る１６ビットフラグを用いてフレーミングすることにより、エラーに対する耐性する強健さを提供していると理解し得るものである。
　また、刊行物５では、Ｈ．２２３プロトコルの多重化技術を、モバイルチャンネルのようにエラーの多い環境の中で使用する場合、８ビットのＨＤＬＣフラグに代えて、１６ビット長のユニークなビットパターンから成るフラグを用いるようにすると理解し得るものである。
　
　
５　請求人の主張についての検討
　請求人は、平成２１年１０月２１日付け意見書において、『しかしながら、本願請求項１の記載から明らかなように、本願発明において、「同期コード」は、その名の通り、同期化を目的とするコードですが、該同期化コードに付加される「少なくとも一つ以上のビット」は、本来、同期化を目的とするビット列ではありません。
　このように、同期コードに、本来同期を目的としないコード（例えばＰＮコード）を付加することによって、同期コードの特性を、本来の特性とは異ならせて、様々に変化させることができます。
　これに対して、引例２・・・（略）・・・
　このように、引例２〜５に記載の可変長の同期パターンは、いずれも、同期を目的としたコードのみから構成されます。
　故に、引例２〜５の同期パターンでは、上述したような本願発明の効果を得ることはできません。』と主張している。
　
　しかしながら、以下にみるように、上記出願人の主張は採用できない。
　
　請求項１において、発明を特定するために、同期コードにさらに付加するものとして記載した事項は、「少なくとも一つ以上のビット」であって、「本来同期を目的としないコード」（例えばＰＮコード）でないことは明白である。したがって、上記請求人の主張は、請求項１に記載した事項である「少なくとも一つ以上のビット」は、「本来同期を目的としないコード」（例えばＰＮコード）であると限定解釈されることを前提とする主張といえるところ、以下のように、そのような前提は成り立たず、上記請求人の主張は、その前提を欠くものであって、請求項１に記載した事項に基づくものとはいえず、採用することができない。
　
〈理由〉
　「少なくとも一つ以上のビット」とは、例えば、単なる１ビットの「０」や「１」をも許容するものであり、それら１ビットの「０」や「１」自体が「本来同期を目的としないコード」であるとかないとかを論ずることは意味をなさないものであるし、
　「本来同期を目的としないコード」であろうとなかろうと、たとえ１ビットでも、元々の同期コードに「少なくとも一つ以上のビット」を付加して同期コードを長くすれば、ノイズ環境下における「同期コード」の誤認識の可能性が低くなり、エラー耐性が高まるという、技術的意義があるといえるのであるから、
　「少なくとも一つ以上のビット」が、「本来同期を目的としないコード」（例えばＰＮコード）を意味すると限定的に解釈することはできない。
　また、請求項１の他のどこにも、「少なくとも一つ以上のビット」が、「本来同期を目的としないコード」（例えばＰＮコード）を意味するものと解釈すべき根拠となる記載はない。むしろ、「本来同期を目的としないコード」との要件は、請求項１の従属項である請求項３において、初めて「ＰＮコード」として特定記載されるものであり、このことからみても、請求項１の「少なくとも一つ以上のビット」が、「本来同期を目的としないコード」（例えばＰＮコード）と解釈する余地はない。
　以上のことから、請求項１記載の「少なくとも一つ以上のビット」は、「本来同期を目的としないコード」（例えばＰＮコード）と限定的に解釈することはできない。
　
　したがって、上記請求人の主張は、請求項１に記載した事項に基づくものではなく、採用することができない。
　
６　まとめ（当審の判断）
　以上のように、本願発明は、刊行物１に記載された発明及び刊行物２に記載された発明、技術常識、周知事項に基づいて当業者が容易に想到し得るものである。
　
　
第四　むすび
　以上のとおり、本願の請求項１に係る発明は、刊行物１に記載された発明及び刊行物２に記載された発明、技術常識、周知事項に基づいて当業者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。
　したがって、本願は、残る請求項２ないし３に係る発明について検討するまでもなく、拒絶をすべきものである。
　よって、結論のとおり審決する。