【事件の表示】
　特願２０１１−　６７７３５「通信装置及びコンピュータプログラム」拒絶査定不服審判事件〔平成２４年１０月２２日出願公開、特開２０１２−２０３６５６〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
第１　手続の経緯
　本願は、平成２３年３月２５日の出願であって、平成２６年２月２０日付けで拒絶理由通知がなされ、同年４月２８日付けで手続補正がなされ、同年１０月１４日付けで拒絶査定がなされ、これに対し、平成２７年１月２１日に拒絶査定不服審判の請求がなされると同時に手続補正がなされたものである。
第２　平成２７年１月２１日付けの手続補正についての補正の却下の決定
［補正の却下の決定の結論］ 
　平成２７年１月２１日付けの手続補正（以下「本件補正」という。）を却下する。 
［理由］
１．新規事項の追加の有無について
　本件補正は、特許請求の範囲の請求項１を、
「【請求項１】
　第一通信用機器及び第二通信用機器が接続される通信装置であって、
　第一通信用機器を制御する第一制御部と、
　
前記第一通信用機器に比べて普及率が低い通信インタフェースである
　データの送信先が前記第一通信用機器であるか前記第二通信用機器であるかに応じて、前記第一制御部と前記第二制御部とのいずれにデータを転送するか判断し、判断した先に前記データを転送する選択部と、を備え、
　前記第一制御部は、ネイティブコードで実装されており、
　前記第二制御部は、前記ネイティブコードに依存しないコードで実装されており、
　前記第一制御部は、前記選択部から前記データの転送を受けると、前記第一通信用機器を制御し前記データを通信路へ送信し、
　前記第二制御部は、前記選択部から前記データの転送を受けると、前記第二通信用機器を制御し前記データを通信路へ送信する、
通信装置。」
に変更する補正内容を含むものである。
　当審は、以下の理由で、本件補正は、本願の願書に最初に添付した明細書、特許請求の範囲又は図面（以下「当初明細書等」という。）に記載した事項の範囲内においてしたものではないと判断する。
　上記本件補正後の請求項１には、「前記第一通信用機器に比べて普及率が低い通信インタフェースである第二通信用機器を制御する第二制御部と、・・・（略）・・・前記第二制御部は、前記ネイティブコードに依存しないコードで実装されており、」との記載（以下「問題記載事項」という。）があるが、当初明細書等に、上記問題記載事項に対応する技術的事項のうち、「前記第一通信用機器に比べて普及率が低い通信インタフェースである第二通信用機器」という技術的事項を示す記載があったとは認められず、また、当該技術的事項は、当業者に自明な事項とも認められない。したがって、特許請求の範囲の請求項１を上記補正後の請求項１とすることを含む本件補正は、当初明細書等の全ての記載を総合することにより導かれる技術的事項との関係において、新たな技術的事項を導入するものであり、当初明細書等に記載した事項の範囲内においてしたものではない。
　なお、請求人は、審判請求書において、以下のとおり、本件補正の根拠について主張している。
「（３）本願発明が特許されるべき理由
・・・（略）・・・
（ｂ）補正の根拠の明示 
　手続き補正書における 
　「
前記第一通信用機器に比べて普及率が低い通信インタフェースである
　という補正事項は、本願明細書の以下の記載を根拠とした補正である。 
　「また、例えば一般的に普及している通信インタフェース（例えば有線ＬＡＮや無線ＬＡＮ）に対応したＨＷ制御部及びＬ２通信制御部はＮａｔｉｖｅ２０上で動作する第一ＨＷ制御部２０４及び第一Ｌ２通信制御部２０３として構成し、あまり一般的に普及していない通信インタフェース（例えばＺｉｇｂｅｅやＷｉＧｉｇ）に対応したＨＷ制御部及びＬ２通信制御部はＪＶＭ３０上で動作する第二ＨＷ制御部３０３及び第二Ｌ２通信制御部３０２として構成しても良い。このように構成することで、あまり一般的に普及していない通信インタフェースについて、ＯＳ毎に開発する必要が無くなり、開発に要するコストや期間を抑えることが可能となる。」本願明細書段落００４５」
　しかしながら、上記請求人の主張に係る明細書の記載を考慮しても、本件補正を、当初明細書等に記載した事項の範囲内においてしたものということはできない。
　なぜならば、上記問題記載事項は、ネイティブコードに依存しないコードで実装される第二制御部の制御対象である「第二通信用機器」が、ネイティブコードで実装される第一制御部の制御対象である「第一通信用機器」よりも普及率の低い通信インタフェースであることを規定するものであって、「第一通信用機器」としての通信インタフェースの普及率と「第二通信用機器」としての通信インタフェースの普及率の相対的な関係を規定するものであるのに対し、上記請求人の主張に係る明細書の記載箇所には、「第一通信用機器」としての通信インタフェースが一般的に普及しているものであり、「第二通信用機器」としての通信インタフェースがあまり一般的に普及していないものであることの記載はあるものの、それぞれの通信インタフェースの普及率の相対的な関係を規定する記載はなく、そのような相対的な関係を規定することは、当業者にとって自明な事項であったともいえないからである。
　以上のとおりであるから、本件補正は、当初明細書等に記載した事項の範囲内においてしたものではない。
２．独立特許要件について
　本件補正は、補正前の請求項１の「第二通信用機器を制御する第二制御部と、」という発明特定事項を、「
前記第一通信用機器に比べて普及率が低い通信インタフェースである
　そうすると、本件補正後の上記請求項１に係る発明（以下「本願補正発明」という。）は、特許出願の際独立して特許を受けることができるもの（特許法第１７条の２第６項において準用する同法第１２６条第７項の規定に適合するもの）でなければならない。
　しかしながら、本願補正発明は、以下の理由で特許法第３６条第６項第２号に規定する要件を満たしていないから、特許出願の際独立して特許を受けることができるものではない。
　本件補正後の請求項１の「前記第一通信用機器に比べて普及率が低い通信インタフェースである第二通信用機器」に含まれる具体的な物の範囲が不明確である。
　なぜならば、ここでいう「普及率」の定義（何と何の割合であるのか）及び当該「普及率」を算出する時点が発明の詳細な説明を参酌しても不明であり、具体的にどのような通信用機器までが、ここでいう「第一通信用機器に比べて普及率が低い通信インタフェースである第二通信用機器」に含まれることになるのかを明確に把握することができないからである。
　以下、この点の具体的問題について詳述する。
（１）「普及率」の定義（何と何の割合であるのか）が不明であることの問題について
　「普及率」という用語からは、「現存する通信機器の全台数に占める特定の通信インタフェースを採用した通信機器の台数の割合」、「過去に販売された通信機器の全台数に占める特定の通信インタフェースを採用した通信機器の台数の割合」、「過去に販売された通信機器の全販売金額に占める特定の通信インタフェースを採用した通信機器の販売金額の割合」等、種々の割合が想定されるが、本願補正発明でいう「普及率」をそれらのいずれの割合とみるかによって、上記「第一通信用機器に比べて普及率が低い通信インタフェースである第二通信用機器」に含まれる具体的な物の範囲は当然に変わると考えられる。
　したがって、上記「普及率」（何と何の割合であるのか）が明確でなければ、上記「第一通信用機器に比べて普及率が低い通信インタフェースである第二通信用機器」に含まれる具体的な物の範囲を明確に把握することができない。
（２）「普及率」を算出する時点が不明であることの問題について
　「普及率」を上記（１）に例示したいずれの割合とみる場合であっても、その「普及率」の値は、それを算出する時点により当然に変化する。
　したがって、上記「普及率」を算出する時点についても、それが明確でなければ、上記「第一通信用機器に比べて普及率が低い通信インタフェースである第二通信用機器」に含まれる具体的な物の範囲を明確に把握することができない。
　以上のとおりであるから、本願補正発明は明確でなく、特許法第３６条第６項第２号に規定する要件を満たしていない。
３．小括
　上記１、２において検討したとおり、本件補正は、特許法第１７条の２第３項の規定、及び、特許法第１７条の２第６項において準用する同法第１２６条第７項の規定に違反するので、同法第１５９条第１項において読み替えて準用する同法第５３条第１項の規定により却下すべきものである。
第３　上記補正の却下の決定を前提とした本願についての検討
１．本願発明
　本件補正は、上記のとおり却下されたので、本願の請求項１に係る発明は、平成２６年４月２８日付け手続補正書の特許請求の範囲の請求項１に記載されたとおりの次のものと認める。（以下、当該請求項１に係る発明を「本願発明」という。）
「【請求項１】
　第一通信用機器及び第二通信用機器が接続される通信装置であって、
　第一通信用機器を制御する第一制御部と、
　第二通信用機器を制御する第二制御部と、
　データの送信先が前記第一通信用機器であるか前記第二通信用機器であるかに応じて、前記第一制御部と前記第二制御部とのいずれにデータを転送するか判断し、判断した先に前記データを転送する選択部と、を備え、
　前記第一制御部は、ネイティブコードで実装されており、
　前記第二制御部は、前記ネイティブコードに依存しないコードで実装されており、
　前記第一制御部は、前記選択部から前記データの転送を受けると、前記第一通信用機器を制御し前記データを通信路へ送信し、
　前記第二制御部は、前記選択部から前記データの転送を受けると、前記第二通信用機器を制御し前記データを通信路へ送信する、
通信装置。」
２．引用例
　原査定の拒絶の理由に引用された特表２００８−５０１２０２号公報（以下「引用例」という。）には、図面とともに次の事項が記載されている。
「
【００２０】
　図３は、ＯＳＧｉゲートウェイ１１０の一般的アーキテクチャを示す。サービスプラットフォーム１１２はＯＳＧｉフレームワークをサポートし、これは典型的には当該ゲートウェイ内のプロセッサにより実行されるソフトウェアにより適用される。ネットワーク内の目標装置を制御するアプリケーションは、サーバ５０上で遠隔的に（アプリケーション１２０）、又はサービスプラットフォーム１１２上でローカルに（アプリケーション１３０）実行することができる。本発明の一実施例によれば、住宅定型制御言語（ＨＵＣＬ）が、サービスプラットフォーム１１２によりサポートされるＯＳＧｉフレームワーク内のアブストラクションレイヤとして使用される。ローカルネットワーク内に存在する各目標装置１５１〜１５３は、“装置サービス”１３３により表される。これは、実際の物理的装置１５１〜１５３のソフトウェアでの表現である。
・・・（略）・・・
【００２２】
　ＨＵＣＬバンドル１４０は、ドライバ１４１、１４２、１４３を接続し、ＯＳＧｉフレームワークに装置サービス１３３を登録し、ＨＵＣＬ管理システム等の一般的管理フィーチャを提供する。ジグビ及びＵＰｎＰ用のドライバ１４１、１４３は、各々、単一のエンティティとして示されている。しかしながら、これらドライバは、Ｘ１０用のドライバに関して示したのと同様の態様で、ベースドライバ１６２と、該ベースドライバ１６３の機能の幾つかを使用する特殊化（refinement）ドライバ１４２により分割することもできる。装置サービス１３３が自身をＯＳＧｉフレームワークに登録し、イベント予約を管理し（後に詳述する）、ＨＵＣＬメッセージをドライバに渡すのを可能にすると共に、斯かるドライバが目標ネットワークにより使用されるプロトコルへの翻訳の全てを実行するのを可能にすることにより、中央管理エンティティの役割を最小化することが可能である。この場合、ＨＵＣＬバンドル１４０の主たるタスクは：
−　中央管理；バージョンＩＤ等を記憶する；
−　ドライバ及び装置サービスを追跡する（ＯＳＧｉフレームワークの関連する予約メカニズムを使用することによる等）；
−　装置サービスを登録する（図５Ａにおいては各装置サービスに対して、図５Ｂにおいては、装置サービスは複合装置に対してのみ登録することができる）；
−　ＯＳＧｉドライバのロケータ対話（又は、低レベルベースドライバとして働くＨＵＣＬドライバに対するネットワーク対話）に参加する；
−　イベント予約を管理する（必要に応じてイベントを送ることができるように）；
−　ＨＵＣＬを使用して通信する；
−　プロトコル翻訳（ＨＵＣＬと目標ネットワークプロトコルとの間の）を実行する；
−　プログラマに優しいジャバＡＰＩから／へＨＵＣＬメッセージストリングを整理（marshall）／分解（unmarshall）する。
【００２３】
　ドライバ１４１、１４２、１４３は、目標ネットワーク上の目標装置を管理し、これら目標装置をＯＳＧｉフレームワーク内のＨＵＣＬ装置サービス１３３として提示する。これは、装置サービス１３３が、標準化されたＨＵＣＬインターフェースを介してドライバ１４１、１４２、１４３と通信するのを可能にする。ドライバ１４１、１４２、１４３は、ジャバ、ネイティブコードで書くことができるか、又はジャバとネイティブコードとの混合で書くことができる。目標ネットワークドライバが存在する場合、他のネットワークもＨＵＣＬを使用することができるように、ＨＵＣＬブリッジドライバが標準のＨＵＣＬ ＡＰＩに変換する。
・・・（略）・・・
【００３５】
　第３の例において、図８Ａ及び８Ｂはアプリケーション１３０が当該システムに既に登録された装置を制御したい場合に発生するメッセージの流れを示す。この例において、アプリケーション１３０は電灯２０をオンするための制御メッセージを送信し、電灯２０は当該システムに‘myHUCLLamp’なる名称で登録されている。図８Ａは、個々の装置サービス１３３が使用される場合のメッセージの流れを示す。最初に、アプリケーション１３０はステップ２４１においてＨＵＣＬ電灯装置サービス１３３に対して、
myHUCLLamp.on()
なる形のメッセージを送信する。ステップ２４２において、電灯装置サービス１３３は、
sendHUCLMsg(“…param1255/param1…”)
なる形のＨＵＣＬメッセージを送信する。これは、ＨＵＣＬ／ＥＨＳドライバ１４４により、ドライバ１６０に送信される（２４３）、
EHSDev5.sendEHSMsg(
TURN_ON)
なるメッセージに翻訳される。該翻訳は、単に上記メッセージのささいな再フォーマットであるか、又はルックアップテーブルの使用によるコマンドの翻訳を含み得る。最後に、ドライバ１６０は目標ネットワークのフォーマットのメッセージ２４４を電灯２０に送出し、これが電灯２０をオンさせる。
【００３６】
　図８Ｂは、汎用ＨＵＣＬバンドル１４０が使用された場合のメッセージの流れを示す。最初に、アプリケーション１３０はステップ２５１においてＨＵＣＬバンドル１４０に対して、
sendHUCLMsgAddressedTo(DevID, “…param1255/param1…”)
なる形のメッセージを送信する。これは、複合装置サービス１４６のうちの特定の副装置１４７に供給され、その場合において、‘DevID’は、ＨＵＣＬ複合装置１４６のうちの電灯２０を表す副装置１４７を識別する識別子である。ＨＵＣＬバンドル１４０は制御メッセージを送出し、該メッセージはＨＵＣＬ／ＥＨＳドライバ１４４によりステップ２５２において、
EHSDev5.sendEHSMsg(TURN_ON)
なる形のＥＨＳメッセージに翻訳される。このメッセージはＥＨＳドライバ１６０に供給される。最後に、ドライバ１６０は目標ネットワークのフォーマットのメッセージ２５３を送出し、該メッセージが電灯２０をオンさせる。」
　ここで、上記記載を本願出願日前からの技術常識等に照らせば、以下のことがいえる。
（１）通信用ドライバを備える装置が、当該通信用ドライバによって制御される通信用機器（ハードウェア）に接続されること及び当該通信用ドライバが当該通信用機器（ハードウェア）を制御して通信を行うことは技術常識であり、段落【００２０】、同【００２２】から【００２３】までの記載及び図３に示されるゲートウェイ１１０の構成並びに上記技術常識から、引用例のゲートウェイには、複数のドライバのそれぞれに対応した通信用機器（ハードウェア）が接続され、当該複数のドライバは、各ドライバに対応する通信用機器を制御して通信を行うものといえる。
（２）一のドライバを一種類のコードで記載することは普通のことであるし、引用例のゲートウェイ１１０において一のドライバを複数種類のコードで記載すべき理由はないから、段落【００２３】の「ドライバ１４１、１４２、１４３は、・・・（略）・・・ジャバとネイティブコードとの混合で書くことができる。」という記載は、あるドライバをジャバで書き、他のドライバをネイティブコードで書くことができることを記載していると解するのが自然である。
（３）段落【００３５】から【００３６】までの記載、図３に示されるゲートウェイ１１０の構成及び図８Ａ、図８Ｂに示される送信メッセージの流れから、ＨＣＵＬバンドルは他の装置又は自装置内のアプリケーションから受信したデータをドライバに送信するものである。
　したがって、引用例には次の発明（以下「引用発明」という。）が記載されているといえる。
「複数の通信用機器（ハードウェア）に接続されたゲートウェイであって、
　前記複数の通信用機器のそれぞれを制御する複数のドライバと、
　ＨＣＵＬバンドルと、を備え、
　前記複数のドライバの一部は、ネイティブコードで実装されており、
　前記複数のドライバの他の一部は、ジャバで実装されており、
　前記複数のドライバの一部は、前記ＨＣＵＬバンドルからデータの伝送を受けると、前記複数のドライバの一部に対応する通信用機器を制御し前記データを通信路へ送信し、
　前記複数のドライバの他の一部は、前記ＨＣＵＬバンドルからデータの伝送を受けると、前記複数のドライバの他の一部に対応する通信用機器を制御し前記データを通信路へ送信する、
ゲートウェイ。」
３．対比
　本願発明と引用発明とを対比すると、次のことがいえる。
（１）引用発明でいう「ゲートウェイ」は、本願発明でいう「通信装置」に相当する。
（２）引用発明でいう「ジャバ」は、本願発明でいう「ネイティブコードに依存しないコード」に相当し、引用発明でいう「複数のドライバの一部」（ネイティブコードで実装されたドライバ）、「複数のドライバの他の一部」（ジャバで実装されたドライバ）はそれぞれ、本願発明でいう「第一制御部」「第二制御部」に相当する。
（３）引用発明でいう「複数のドライバの一部」が制御する通信用機器及び「複数のドライバの他の一部」が制御する通信用機器はそれぞれ、本願発明でいう「第一通信用機器」「第二通信用機器」に相当する。
　したがって、本願発明と引用発明との間には、次の一致点、相違点があるといえる。
（一致点）
「第一通信用機器及び第二通信用機器が接続される通信装置であって、
　第一通信用機器を制御する第一制御部と、
　第二通信用機器を制御する第二制御部と、
を備え、
　前記第一制御部は、ネイティブコードで実装されており、
　前記第二制御部は、前記ネイティブコードに依存しないコードで実装されており、
　前記第一制御部は、データの転送を受けると、前記第一通信用機器を制御し前記データを通信路へ送信し、
　前記第二制御部は、データの転送を受けると、前記第二通信用機器を制御し前記データを通信路へ送信する、
通信装置。」
（相違点）
　本願発明は、「データの送信先が前記第一通信用機器であるか前記第二通信用機器であるかに応じて、前記第一制御部と前記第二制御部とのいずれにデータを転送するか判断し、判断した先に前記データを転送する選択部」を有するのに対し、引用発明は、データをドライバへ送信する「ＨＵＣＬバンドル」を有するものの、その「ＨＵＣＬバンドル」が上記「選択部」のような動作をするものとはされていない点
４．判断
（１）上記相違点について
　転送すべき通信データを他の装置から受信した場合又は送信すべき通信データが自装置において発生した場合に、当該通信データの送信先となる出力部（通信用機器）を判断し、当該判断した出力部に通信データを送信するという機能は、ルータ、ゲートウェイ等のデータ中継装置が、通信効率を向上させるために備えている一般的な中継機能であり、データ中継装置である引用例のゲートウェイにおいて、通信効率の向上のために当該中継機能を設けることは、当業者であれば容易に想到し得たことである。
　そして、そうする場合には、引用例の図３に示される構成からみて、引用発明のＨＵＣＬバンドルにその中継機能を担わせるのが自然である。
　以上のことは、引用発明の「ＨＵＣＬバンドル」を本願発明の「選択部」に相当するものとすることが当業者にとって容易であったことを意味している。
（２）本願発明の効果について
　本願発明の構成によってもたらされる効果は、引用発明から容易に想到し得た構成のものが奏するであろうと当業者が予測する範囲内のものであり、本願発明の進歩性を肯定する根拠となり得るようなものではない。
５．小括
　以上のとおり、本願発明は、引用発明に基いて、当業者が容易に発明をすることができたものである。
第４　むすび
　以上のとおり、本願発明は、引用発明に基づいて、当業者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。
　したがって、本願は、他の請求項について検討するまでもなく、拒絶されるべきものである。
　よって、結論のとおり審決する。