【事件の表示】
　平成１１年特許願第１９５３６６号「通信システム」拒絶査定不服審判事件〔平成１２年　４月　７日出願公開、特開２０００−１０１７１６〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
第１．手続の経緯
　本願は、平成１１年７月９日（パリ条約による優先権主張１９９８年７月１４日、米国）の出願であって、平成１７年３月１４日付けで拒絶査定がなされ、これに対し、平成１７年６月２０日に拒絶査定に対する審判請求がなされ、当審において平成１９年１０月１８日付けで拒絶理由通知がなされ、平成２０年４月２２日付けで手続補正がなされたものである。
　
第２．特許法第２９条第２項について
　
１．本願発明
　本願の請求項１３に係る発明（以下、「本願発明」という。）は、以下のとおりのものである。
「新プロトコルおよび旧プロトコルのうちの一方を用いる単一の通信経路を介して、第１デバイスにより第２デバイスから受信されたメッセージ中のパラメータ内の拡大コマンドエンコーディングを検出して、該新プロトコルと該旧プロトコルに互換性をもたせるようにするための方法であって、
　メッセージを受信するステップと、
　該メッセージ中に含まれるパラメータ内のパラメータ識別フィールドからパラメータエンコーディングを読み出すステップと、
　該パラメータエンコーディングが、該パラメータ内の拡大パラメータ識別のインジケータであるかどうかを判断するステップと、
　該パラメータエンコーディングが該インジケータであるとの判断に応じて、前記拡大パラメータ識別から拡大パラメータエンコーディングを読み出すステップと、
　該拡大パラメータエンコーディングが、新プロトコルによってサポートされるパラメータを表すかどうかを判断するステップと、
　該拡大パラメータエンコーディングが、該新プロトコルによってサポートされるパラメータを表すとの判断に応じて、該パラメータを処理するステップと、を含むことを特徴とする方法。」
　
２．引用例に記載された発明
　当審で通知した拒絶の理由に引用された特公平７−１６２０９号公報（以下、「引用例」という。）には、図面とともに以下の記載がある。
　イ．「実施例
第１図は本発明の一実施例における通信制御装置の構成と通信形態を示す図であり、第２図は第１図に示す通信制御装置が相互にコマンド拡張モードで通信処理を行なう場合の拡張コマンドを用いた通信処理の可否を問合せ確認する通信シーケンスを示す図である。第３図は第２図の通信シーケンスにて使用されるコマンドの組み合せを示す図であり、第４図は第３図で用いられるコマンドの定義域との関係を示す図である。
第１図において、従来例である第５図と共通する素子に同一番号を付している。１は予め定められる電気条件に従って信号を伝送する信号伝送路、２および３は信号伝送路１から信号を取り込む、または信号伝送路１へ送出するコネクタ、４および５はコネクタ2,3を介して信号伝送路１へ接続される通信制御装置、６および７は通信制御装置4,5に各々接続され信号伝送路１を介して通信および制御を行なう／または制御される機器、８は信号伝送路１へ信号を伝送するドライバと信号伝送路１から信号を受信するレシーバより構成されるトランシーバ、９はトランシーバ８を経由して信号伝送路１を介して他の通信制御装置５との間で予め定めたCSMA/CDなどの通信制御手順に従って信号フレームの送信処理および自己宛送信信号フレームの受信処理を行なう通信制御部、10は信号伝送路１に接続される通信制御装置相互間で送受信する予め定められた定義域を持つコマンドの解釈処理を行ない必要ならば機器接続制御部12を介して機器６へ制御の指示を通知する通信処理部、11は予め定めたユーザ毎に割付ける識別名として英数字３文字以上の識別名を記憶保持し前記通信処理部10にて容易に読出すことのできる通信識別情報記憶部、12は前記通信処理部10からの指示または制御情報の通知要求に従って機器６を制御または制御情報を機器６へインタフェース13を介して送信／または機器６からの指示または制御情報の通知要求に従って逆方向に前記通信処理部10に送信する制御を行なう機器接続制御部、13は機器６と通信制御装置４を電気的に接続するインタフェース。」（２頁４欄１８行〜３頁５欄３行）
　
　ロ．「（１）いま第１図の通信制御装置４の通信処理部10と通信制御装置５の通信処理部10との間で送受信されるコマンドは通常第４図に示される標準コマンドの定義域で定義される標準コマンドが用いられる。該標準コマンドとして予めコードが割当てられ定義される拡張要求，拡張応答およびコマンド拡張の各コマンドは第３図の（ａ）〜（ｆ）の形式により第２図の各シーケンスで使用される。以後、第２図（ａ）のユーザ拡張コマンド使用時の拡張の場合における通信シーケンスを用いたコマンド拡張モードの開始／終了動作について述べる。
（２）第１図の通信制御装置４の通信処理部10が通信制御装置５の通信処理部10との間で使用するコマンドを標準コマンドから標準拡張コマンドへコマンドの定義域を切替える場合と、標準コマンドからユーザ毎に個別なコマンド定義域を持つことのできるユーザ拡張コマンドへコマンドの定義域を切替える場合がある。前者の場合は、第４図に示すように標準コマンド定義域に予め定義されるコマンド拡張のOPCに第４図に示すOPR、62H,63H,……,74Hの標準拡張と定義されたOPRのいずれか、例えば62Hを指定すると該62HのOPRにつづくOPCが標準拡張コマンド定義域に定義された拡張コマンドとして受信側は一意に解釈処理する。この時、通信処理部10相互間にて送信される拡張コマンドは第３図の（ｆ）に示す形式をとるとともに第２図の（ｂ）に示す通信シーケンスを用いて行なう。」（３頁６欄４〜２８行）
　
　引用例のロには、通信制御装置４、５の間で送受信するコマンドとして、標準コマンドと標準拡張コマンドとを切り替えて使用することについて記載されており、第２図（ｂ）によれば、通信制御装置４から通信制御装置５へのコマンドを標準拡張コマンドとすることにより、拡張が行われており、その標準拡張コマンドは、第３図（ｆ）を参照すれば、第１のオペコード（コマンド拡張）、第１のオペランド（標準拡張）、第２のオペコード（標準拡張コマンド）、第２のオペランド（オペランド）からなるものであるといえる。第１のオペコードと第１のオペランドとを、第１の領域、第２のオペコードを第２の領域と呼ぶことにすると、第１の領域の内容である第１のオペコード（コマンド拡張）は第１のオペランド（標準拡張）と組み合わされることにより、コマンドが標準拡張されたものであることを指示しており、第２の領域の内容を標準拡張コマンドのオペコードとして解釈すべきこと指示しているものと理解できる。
　
　したがって、引用例には、
「単一の信号伝送路に通信制御装置４，５を接続したシステムにおいて、標準コマンドと標準拡張コマンドとを切り替えて使用する方法であって、
　通信制御装置４からのコマンドを、通信制御装置５において受信するステップと、
　該コマンドの第１の領域の内容がコマンドが標準拡張されたものであることを指示するものであると判断したときに、第２の領域の内容を標準拡張コマンドのオペコードとして解釈して処理するステップとからなる方法。」
（以下、「引用例発明」という。）が開示されているものと認められる。
  
３．対比
　本願発明と引用例発明とを対比する。
　ここで、本願発明における「拡大コマンドエンコーディング」という用語は明確なものではないが、「拡大パラメータエンコーディング」と同義であるとして検討する。
　引用例発明の「信号伝送路」「通信制御装置５」「通信制御装置４」「コマンド」は、本願発明の「通信経路」「第１デバイス」「第２デバイス」「メッセージ」にそれぞれ相当する。
　引用例発明は、通信制御システムで使用される標準コマンドを拡張して標準拡張コマンドを定義することにより、コマンド拡張するものであり、通信制御システムは、標準コマンドに加えて標準拡張コマンドが使用可能とされることは技術的に自明である。
　本願明細書の０００２段落には、「プロトコルとは、メッセージパケット内のフィールドの構造と、フィールド内のビットのエンコーディングとを定義する規則のセットのことである。」と記載されていることからすれば、引用例発明の「標準コマンド」及び「標準拡張コマンド」は「プロトコル」であるといえるので、引用例発明の「標準コマンド」及び「標準拡張コマンド」は、本願発明の「旧プロトコル」及び「新プロトコル」に相当するものであり、「互換性」を有するものであるといえる。
　引用例発明は、コマンドの第１の領域の内容がコマンドが標準拡張されたものであることを指示していると判断した場合に、第２領域の内容を標準拡張コマンドのオペコードとして解釈して処理するものであるといえるから、引用例発明の「第１の領域」及び「第１の領域の内容」は、本願発明の「パラメータ識別フィールド」及び「パラメータエンコーディング」に相当し、引用例発明の「第２の領域」及び「第２の領域の内容」は、本願発明の「拡大パラメータ識別」及び「拡大パラメータエンコーディング」に相当するといえる。そして、引用例発明の「コマンドが標準拡張されたものであることを指示するものである」ことは、本願発明の「拡大パラメータ識別のインジケータである」ことに相当するといえる。
　そして、引用例発明は、「パラメータ識別フィールド（第１の領域）」の内容を読み出すステップを有するものであることは技術的に自明である。
　また、引用例発明の「パラメータ識別フィールド（第１の領域）」は、メッセージ中に含まれるパラメータ内のものであるということができる。
　また、引用例発明において、「拡大パラメータ識別（第２の領域）」は、標準拡張コマンドのオペコードとして解釈して処理されるものであるから、引用例発明は「拡大パラメータ識別（第２の領域）から拡大パラメータエンコーディングを読み出すステップ」と「該拡大パラメータエンコーディングを処理するステップ」を有するものであることは技術的に自明である。
　さらに、引用例発明は、「拡大パラメータエンコーディング（第２の領域の内容）」を解釈して処理するものであり、「拡大パラメータエンコーディング」は「拡大コマンドエンコーディング」と同義であるから、引用例発明は、「拡大コマンドエンコーディング」を検出するものであるといえる。
　
　したがって、両者は
「単一の通信経路を介して、第１デバイスにより第２デバイスから受信されたメッセージ中のパラメータ内の拡大コマンドエンコーディングを検出して、新プロトコルと旧プロトコルに互換性をもたせるようにするための方法であって、
　メッセージを受信するステップと、
　該メッセージ中に含まれるパラメータ内のパラメータ識別フィールドからパラメータエンコーディングを読み出すステップと、
　該パラメータエンコーディングが、該パラメータ内の拡大パラメータ識別のインジケータであるかどうかを判断するステップと、
　前記拡大パラメータ識別から拡大パラメータエンコーディングを読み出すステップと、
　該拡大パラメータエンコーディングを処理するステップと、を含む方法。」の点で一致し、以下の点で相違している。
　　
［相違点１］
　本願発明の単一の通信経路は、新プロトコルおよび旧プロトコルのうちの一方を用いるのに対して、引用例発明では、新プロトコルと旧プロトコルとをどのように用いるのか明らかではない点。
［相違点２］
　「前記拡大パラメータ識別から拡大パラメータエンコーディングを読み出す」ことが、本願発明では、「該パラメータエンコーディングが該インジケータであるとの判断に応じて」行われるのに対して、引用例発明では、当該判断に応じて行われるものではない点。
［相違点３］
　本願発明は、「該拡大パラメータエンコーディングが、新プロトコルによってサポートされるパラメータを表すかどうかを判断するステップ」を有するのに対して、引用例発明は、そのようなステップを有するものではない点。
［相違点４］
　拡大パラメータエンコーディングを処理するに際し、本願発明は、該拡大パラメータエンコーディングが、該新プロトコルによってサポートされるパラメータを表すとの判断に応じて処理するものであるのに対して、引用例発明は、そのようなものではない点。
　　　　
４．当審の判断
［相違点１］について
　引用例発明において、新プロトコルと旧プロトコルとは、両方を同時に用いることも片方のみを用いることも可能であることは技術的に自明のことであり、新プロトコルおよび旧プロトコルのうちの一方を用いるようにすることは何ら格別の事項ではない。
［相違点２］について
　新プロトコルで用いられる拡大パラメータ識別に、拡大パラメータエンコーディングが収容されるものである点で、本願発明と引用例発明とは共通している。「該パラメータエンコーディングが該インジケータである」ことは、新プロトコルが用いられていることを意味するものであり、新プロトコルが用いられているかどうかの判断は、本願発明も引用例発明も同様に行うものである。新プロトコルが用いられているとの判断に応じて拡大パラメータエンコーディングを読み出すか、その判断とは関係なく拡大パラメータエンコーディングを読み出すかは、当業者が適宜決定すべき設計的事項にすぎない。
［相違点３、４］について
　本願発明の拡大パラメータエンコーディングが新プロトコルによってサポートされるパラメータとして処理されるべきものであることは、技術的に自明のことである。
　一般的に、コマンド等のパラメータを処理する前に、当該パラメータが適正であることを判断して、その判断に応じて当該パラメータを処理することは、情報通信分野における周知事項（特開平１０−８４４２４号公報【００１２】〜【００１４】段落、特開平７−１６８６４３号公報【００１３】段落、特開平７−６２６９号公報【０００９】段落、特開平２−１４８１５６号公報参照）と認められる。
　本願発明の拡大パラメータエンコーディングが新プロトコルによってサポートされるパラメータとして処理されるべきものであることは、技術的に自明のことであり、当該周知事項を考慮すれば、相違点３、４に係る構成を採用することに格別の困難性は認められない。
　
　そして、本願発明の作用効果も、引用例発明及び周知事項から当業者が予測できる範囲のものである。
　　　
　したがって、本願発明は、引用例発明及び周知事項に基づいて、当業者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。
　
第３．特許法第３６条について
　
１．特許法第３６条についての拒絶理由
　
　当審において、平成１９年１０月１８日付けで特許法第３６条について、以下の拒絶の理由が通知された。
　
 「３−Ｂ．本件出願は、明細書の記載が下記の点で不備のため、特許法第３６条第４項、第６項第１号及び第２号に規定する要件を満たしていない。 
 　　　　　　　　　　　　　　　　　記 
 （１）特許請求の範囲で使用されている用語の定義が不明であり、また、特許請求の範囲の用語と、発明の実施の形態の用語とが対応していない。例えば、請求項１の「拡大パラメータ識別」「インジケータエンコーディング」「拡大パラメータ識別サブフィールド」「拡大エンコーディング」、請求項２の「データセグメント」、請求項３の「データセグメントフィールド」、請求項４の「未使用パラメータエンコーディング」、請求項８の「パラメータエンコーディング」、請求項１３の「拡大コマンドエンコーディング」「パラメータエンコーディング」「拡大パラメータエンコーディング」、請求項１４の「未使用パラメータエンコーディング」、請求項１５の「パラメータエンコーディングフィールド」、等の用語が何を意味するのか不明瞭であり、また、用語の使用が統一されておらず、明細書全体が不明瞭である。
 （明細書全体の補正を検討するとともに、意見書において、図面の符号を特許請求の範囲に記入して説明されたい。） 
 　 
 （２）発明の詳細な説明の用語と、図面の用語とが一致しておらず、不明瞭である。 
 　 
 （３）請求項１の「該第１のプロコトルによりサポートされるが第２のプロコトルによってはサポートされないパラメータを表わす複数の拡大エンコーディングのうちの１つを識別するための手段」という記載は意味不明であり、発明の実施の形態との対応関係も不明である。 
 　 
 （４）請求項６の「前記インジケータエンコーディングが前記第２のプロトコルによってサポートされるパラメータを表すかどうかを判断するための手段」及び「前記インジケータエンコーディングが前記第２のプロトコルによってサポートされるパラメータを表すとの判断に応じて、前記パラメータを処理するための手段」という記載は意味不明であり、発明の実施の形態との対応関係も不明である。 
 　 
 （５）請求項８の「該第１のプロトコルによってサポートされる該第１の複数のパラメータと、該第１の複数のパラメータエンコーディングとをサポートする、該メッセージパケットのデータ構造を定義する新プロトコル」及び「該新プロトコルによってサポートされ、該拡大パラメータ識別フィールドに書き込まれた第２の複数のパラメータエンコーディングによって表される第２の複数のパラメータ」という記載は意味不明であり、発明の実施の形態との対応関係も不明である。 
 　 
 （６）請求項１１の「前記第１の通信デバイスが、マシン読み出し可能な媒体に格納された前記旧プロトコルの命令を実行することにより、 
 　パラメータのパラメータ識別フィールドからエンコーディングを読み出すステップと、 
 　前記エンコーディングが、前記第１の複数のパラメータのうちの１つのパラメータに対応する前記第１の複数のパラメータエンコーディングのうちの１つのパラメータエンコーディングであるかどうかを判断するステップと、 
 　前記パラメータエンコーディングが前記第１の複数のパラメータのうちの１つに対応しないとの判断に応じて、前記パラメータを無視するステップと、を実行する」という記載は意味不明であり、発明の実施の形態との対応関係も不明である。 
 　 
 （７）請求項１２の「前記第１の通信デバイスが、マシン読み出し可能な媒体に格納された、前記新プロトコルで通信するための命令を実行することにより、 
 　パラメータのパラメータ識別フィールドから第１のパラメータエンコーディングを読み出すステップと、
 　前記第１のパラメータエンコーディングが前記インジケータエンコーディングであるかどうかを判断するステップと、
 　前記第１のパラメータエンコーディングが前記インジケータエンコーディングであるとの判断に応じて、前記パラメータ内の前記拡大パラメータ識別フィールドから拡大パラメータエンコーディングを読み出すステップと、
 　前記拡大パラメータエンコーディングが前記第２の複数のパラメータのうちの１つのパラメータを表すかどうかを判断するステップと、
 　前記拡大パラメータエンコーディングが前記第２の複数のパラメータのうちの１つのパラメータを表すとの判断に応じて、前記パラメータを処理するステップと、を実行するようになっている」という記載は意味不明であり、発明の実施の形態との対応関係も不明である。 
 　 
 （８）請求項１５の「前記第１のデバイスが、拡大パラメータエンコーディングをサポートしない前記第２のプロトコルを使用する前記第１のデバイスと通信を行い」という記載は意味不明であり、発明の実施の形態との対応関係も不明である。 
 　 
 （９）０００８段落の「新しい長さの拡大されたパラメータ識別フィールド」及び「新旧いずれのプロトコルによって期待される長さの識別フィールド」とは何か。 
 　 
 （１０）０００９段落の「新プロトコルでは、パラメータの識別フィールドは２つの長さのうちの１つである。識別フィールドの第１の長さは、旧プロトコルでのエンコーディングの長さである。」及び「パラメータが、新プロトコルによってサポートされる新しいパラメータである場合、エンコーディングは第２の、拡大された長さである。」という記載は意味不明である。また、「データサブフィールド」とは何か不明である。 
 　 
 （１１）００１０段落の「データフィールド内の拡大識別シールド」とは何か。 
 　 
 （１２）００１３段落には「コントローラ１０３と１１３は、トランク１０２を通じてメッセージパケットを送信することによって、交換システム１０１および１１１が電話サービスを提供するオペレーションを調整する。」と記載されているが、何がメッセージパケットを生成するのか不明である。
 　 
 （１３）００１７段落の「フィールド３０７は、パケット３００内にエンコードされたパラメータフィールドの最初である。」という記載は意味不明である。 
 　 
 （１４）００１８段落の「システムは、パケットを読み取るときに、このバイト数をこのパラメータとしてまとめて扱う。」という記載は意味不明である。 
 　 
 （１５）００２０段落の「旧プロトコルからの未使用パラメータエンコーディング」とは何か。 
 　 
 （１６）００２０段落の「第２のパラメータ識別フィールド３２３」、「第２パラメータエンコーディングフィールド」とは何か。また、図３の「拡大コマンドパラメータ」との関係が不明である。 
 　 
 （１７）００２３段落の「データ長フィールド３１１あるいは３２１からパラメータ長のバイト数を読み出して捨てる。」という記載は意味不明である。 
 　 
 （１８）００２５段落の「旧プロトコルからの所定の未使用コマンドエンコーディング」とは何か。 
 　 
 （１９）００２６段落の「新エンコーディングが正しい場合、ステップ５０８で、データ長フィールド３１１あるいは３２１に示されるデータバイト数ｎを読み出す。」という記載は意味不明である。また、「データバイト数」と、図３の「パラメータのデータ長」「データ長」との関係が不明である。」
　
２．請求人の対応
　上記拒絶理由通知に対して、請求人は、平成２０年４月２２日付けで意見書と手続補正書を提出した。
　
３．当審の判断
　拒絶理由の（１）（２）で指摘した用語の不備については、補正されておらず、意見書において釈明もなされていない。
　拒絶理由の（３）（４）（８）に対して、「第１のプロトコル」「第２のプロトコル」を「新プロトコル」「旧プロトコル」と補正したが、この補正により記載不備が解消するものとは認められない。
　拒絶理由の（５）に対して、「該旧プロトコルの要素をすべて含み、さらに該旧プロトコル及び第１の複数のパラメータエンコーディングによりサポートされる該第１の複数のパラメータをサポートする該メッセージパケットのデータ構造を定義するパラメータを含む新プロトコル」との補正がなされたが、補正された記載も意味不明であり、発明の実施の形態との対応関係も不明である。
　拒絶理由の（６）（７）に対しては、補正されておらず、適切な釈明もなされていない。
　拒絶理由の（９）〜（１９）で指摘した発明の詳細な説明及び図面の記載不備に対しては、補正されておらず、釈明もなされていない。
　
　拒絶理由（１）〜（１９）は全て妥当なものであり、平成２０年４月２２日付けの意見書と手続補正書によって、拒絶理由で指摘した記載不備が解消したものとは認められない。
　
　したがって、本件出願は、明細書の記載が不備のため、特許法第３６条第４項、第６項第１号及び第２号に規定する要件を満たしていない。
　
第４．むすび
　以上のとおり、本願発明は、特許法第２９条第２項の規定により特許を受けることができない。また、本件出願は、明細書の記載に不備があり、特許法第３６条第４項、第６項第１号及び第２号に規定する要件を満たしていない。
　
　よって、結論のとおり審決する。