【事件の表示】
　特願２００５−３７６２５５「通信装置および通信制御方法」拒絶査定不服審判事件〔平成１９年　７月１２日出願公開、特開２００７−１７９２５５〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
第一　手続の経緯
　本願は、平成１７年１２月２７日の出願であって、平成２１年１１月１６日付け拒絶理由通知に対して、平成２２年１月１９日に手続補正がなされたが、同年４月１２日付けで拒絶査定がなされ、これに対し、同年７月１６日に拒絶査定不服審判が請求されるとともに手続補正がなされたものである。
　
第二　補正の却下の決定
［補正の却下の決定の結論］
　平成２２年７月１６日付けの手続補正（以下、「本件補正」という。）を却下する。
　
［理由］
（ａ）補正の内容
　本件補正によると、その特許請求の範囲の請求項１は、
「所定のファイルシステムフォーマットで記憶装置へのアクセスを行う制御側装置と所定の制御プロトコルで機能が外部から制御されることが可能である被制御側装置との両方と通信を行う通信装置において、
　前記制御側装置へ前記ファイルシステムフォーマットに準拠し、前記被制御側装置から取得した特性に基づいて生成されたファイル構成情報を提供するファイル構成提供手段と、
　前記制御側装置からの前記ファイル構成情報に含まれるファイルへのアクセスを、前記制御プロトコルに準拠し前記被制御側装置の前記機能を制御する制御命令情報に変換するプロトコル変換手段と、
　前記制御命令情報を前記被制御側装置へ提供する制御命令提供手段と、
を備えることを特徴とする通信装置。」
と補正されている。
　
　上記補正は、本件補正前の請求項１に記載した発明を特定するために必要な事項である「前記被制御側装置の特性に合わせたファイル構成情報」を「前記被制御側装置
から取得した
基づいて生成され
　したがって、本件補正は、平成１８年法律第５５号改正附則第３条第１項によりなお従前の例によるとされる同法による改正前の特許法第１７条の２第４項第２号に規定する特許請求の範囲の減縮を目的とするものに該当するといえる。
　そこで、本件補正後の前記請求項１に記載された発明（以下、「本願補正発明」という。）が、特許出願の際独立して特許を受けることができるものであるか（平成１８年法律第５５号改正附則第３条第１項によりなお従前の例によるとされる同法による改正前の特許法第１７条の２第５項において準用する同法第１２６条第５項の規定に適合するか）否かについて以下検討する。
　
　
（ｂ）引用例
　原査定の拒絶の理由に引用された国際公開第２００５／０１３１３６号（２００５年２月１０日国際公開。以下、「引用例」という。）には、図面とともに次の記載がある。
　
イ．「［００３３］　図２は、ユビキタスモジュールユニット４の主たる構成（コア）となるユビキタスモジュール（図中ＵＭと略記）の概略構成を示した図である。（以下では、一例として、映像に関わるユビキタスモジュール、ユビキタス映像モジュールユニットについて説明を行うため、それぞれ、ユビキタス映像モジュール、ユビキタス映像モジュールユニットと称する。）
　ユビキタス映像モジュール１２は、ユビキタス映像モジュール１２のハードウェアエンジン１７を制御するためのＵＭ−ＣＰＵ１３、ＵＭ−ＣＰＵ１３と各ハードウェアエンジンとを接続するためのローカルバス１４、外部の映像情報装置とユビキタス映像モジュール１２とを接続するための汎用バスＵＭ−ＢＵＳ１６、汎用バスＵＭ−ＢＵＳ１６とローカルバス１４とを接続するバスブリッジ１５、各種のネットワークの映像信号処理において必要な機能をハードウェアでの実現を図ったハードウェアエンジン１７によって構成される。
［００３４］　ここでハードウェアエンジン１７には、例えばネットワーク１に接続するための有線ＬＡＮ、無線ＬＡＮ、シリアルバス（Ｓｅｒｉａｌ  ＢＵＳ）接続等のためのバスライン１８等を設けることが可能である。
［００３５］　各ハードウェアエンジン１７は、ユビキタス映像モジュールユニット４を装着することによって、映像情報装置には本来存在しない機能を追加・補充するためのエンジンである。
［００３６］　このエンジンは、例えば図３に示すように、ネットワーク１に接続するための有線ＬＡＮ、無線ＬＡＮ、シリアルバス通信等の、ユビキタス映像モジュール１２とそのネットワーク１との間の通信機能を担うためのコミュニケーションエンジン２４がある。」（第９頁第２６行−第１０頁第１８行）
　
ロ．「［００６４］＜ネットワーク接続に関する説明＞
　図８は、図７に示したユビキタス映像モジュールユニット４において、インターネット環境に接続するためのコミュニケーションエンジン２４の具体的な構成の一例である。
［００６５］　コミュニケーションエンジン２４は、例えば、有線ＬＡＮ、無線ＬＡＮ、シリアルバスのハードウェアエンジン及び接続端子を有する。このように構成されたユビキタス映像モジュールユニット４は、有線ＬＡＮ、無線ＬＡＮ、ＩＥＥＥ１３９４等のシリアルバス等を経由してネットワーク接続が可能となる。ユビキタス映像モジュールは、これら全ての接続形態に対応する端子を持つよう構成することも可能であるし、いずれか一つの接続形態に対応する端子を持つように構成することもできる。これらの端子等は、ネットワークや製品に応じて適宜選択すればよい。
［００６６］　図９は、図８に示したコミュニケーションエンジン２４におけるインターネット通信プロトコルに従うミドルウェアのソフトウェアブロック構成例を示したものである。
［００６７］  なお、図９は、各ソフトウェアブロックの層の上下について示してあり、組込みＬｉｎｕｘ７０が最下位層（ハードウェアに一番近い層）、アプリケーション８３が最上位層（ハードウェアから一番遠い層）、およびその中間にある層の関係を概略的に示している。
［００６８］　図８に示した構成例と同様、例えば図９に示した通信用インタフェースは、１０ＢＡＳＥ−Ｔ（伝送速度１０ＭｂｐｓのＥｔｈｅｒｎｅｔの物理レイヤ。なお、Ｅｔｈｅｒｎｅｔ、イーサネットはＸＥＲＯＸ社の登録商標。）や１００ＢＡＳＥ−ＴＸ（伝送速度１００ＭｂｐｓのＥｔｈｅｒｎｅｔの物理レイヤ）から成る有線ＬＡＮ、ＩＥＥＥ８０２．１１ａ／ｂ／ｇから成る無線ＬＡＮ、ＩＥＥＥ１３９４等の高速シリアル通信用の３種類のハードウェアおよびそれらのハードウェアの動作を制御するデバイスドライバが用いられる。
［００６９］　そして、図８に示すように、各ハードウェアを制御するデバイスドライバは、上記ハードウェアの各々対応してイーサネットドライバ７１、無線ＬＡＮドライバ７２、ＩＥＥＥ１３９４ドライバ７３（以下、１３９４ドライバ７３と称す）である。
［００７０］　図を参照すると分かるように、インターネットプロトコルの処理を行うＩＰプロトコルスタック７７は、イーサネットドライバ７１および無線ＬＡＮドライバ７２の上位層として配置される。
［００７１］　このＩＰスタック７７は、現在主流のＩＰプロトコル（Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ  ｖｅｒｓｉｏｎ  ４）を更に発展させた次世代型インターネットプロトコルであるＩＰｖ６（Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ  ｖｅｒｓｉｏｎ  ６）に対応するための処理や、セキュリティのためのプロトコルＩＰｓｅｃ（ＩＰ  ｓｅｃｕｒｉｔｙ）に対応する処理を含む。
［００７２］　１３９４ドライバ７３の上位にはＩＥＥＥ１３９４のトランザクション（ｔｒａｎｓａｃｔｉｏｎ）処理を行う１３９４トランザクションスタック７５が配置される。また、１３９４トランザクション処理を無線ＬＡＮ経由で実行できるよう、無線ＬＡＮドライバ７２と１３９４トランザクションスタック７５との間にＰＡＬ（Ｐｒｏｔｏｃｏｌ  Ａｄａｐｔａｔｉｏｎ  Ｌａｙｅｒ）７４を配置する。
［００７３］　ＰＡＬ７４は１３９４トランザクションと無線ＬＡＮの間のプロトコル変換を行う。ＩＰスタック７７の上位にはトランスポート層としてＴＣＰ／ＵＤＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ  Ｃｏｎｔｒｏｌ  Ｐｒｏｔｏｃｏｌ／Ｕｓｅｒ  Ｄａｔａｇｒａｍ  Ｐｒｏｔｏｃｏｌ）スタック７８が配置される。
［００７４］　ＴＣＰ／ＵＤＰスタック７８の上位には、ＨＴＴＰ（Ｈｙｐｅｒ  Ｔｅｘｔ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ）のプロトコル処理を行うＨＴＴＰスタック７９が配置される。
［００７５］　また、ＨＴＴＰスタック７９の上位にはＨＴＴＰを用いてＸＭＬ（ｅＸｔｅｎｓｉｂｌｅ  Ｍａｒｋｕｐ  Ｌａｎｇｕａｇｅ）をベースとして、他のコンピュータにあるデータやサービスを呼び出したり、メッセージ通信を行うＳＯＡＰ（Ｓｉｍｐｌｅ  Ｏｂｊｅｃｔ  Ａｃｃｅｓｓ  Ｐｒｏｔｏｃｏｌ）のプロトコル処理を行うＳＯＡＰ／ＸＭＬスタック８０が配置される。
［００７６］　組込みＬｉｎｕｘ（Ｅｍｂｅｄｄｅｄ  Ｌｉｎｕｘ）７０より上位の層で、ＨＴＴＰスタック７９、ＳＯＡＰ／ＸＭＬスタック８０、１３９４トランザクションスタック７５を含む層迄が、ＩＰｖ６対応インターネット通信プロトコルに従うミドルウェア８７に含まれる。
［００７７］　これより上位の層として、ＳＯＡＰ／ＸＭＬスタック８０及びＨＴＴＰスタック７９の上位に、インターネット通信プロトコルをベースとするプラグアンドプレイ（Ｐｌｕｇ  ａｎｄ  Ｐｌａｙ）機能を実現するプロトコルであるユニバーサルプラグアンドプレイ（Ｕｎｉｖｅｒｓａｌ  Ｐｌｕｇ  ａｎｄ  Ｐｌａｙ）の処理を行うＵＰｎＰスタック８１が配置される。
［００７８］　また、１３９４トランザクションスタック７５の上位にはＩＥＥＥ１３９４を用いたネットワークのプラグアンドプレイ機能を実現する処理を行うＡＶ系ミドルウェア７６が配置される。
［００７９］　ＵＰｎＰスタック８１およびＡＶ系ミドルウェア７６の上位には、各ネットワークを相互接続する統合ミドルウェア８２が配置される。ＡＶ系ミドルウェア７６、ＵＰｎＰスタック８１、統合ミドルウェア８２を含む層が、ユニバーサルプラグアンドプレイのミドルウェア８８に含まれる。
［００８０］　統合ミドルウェア８２より上位の層は、アプリケーション層８９となる。
　また、さらに、ＳＯＡＰを用いたネットワーク上の他のコンピュータとの間でアプリケーションの連携を行うために、Ｗｅｂサーバプログラム８４、Ｗｅｂサービスアプリケーションインタフェース８５、Ｗｅｂサービスアプリケーション８６が統合ミドルウェア８２より上位の層に階層的に配置される。
［００８１］　Ｗｅｂサービスアプリケーション８６は、Ｗｅｂサービスアプリケーションインタフェース８５を通じてＷｅｂサーバの提供するサービス（他のコンピュータにあるデータやサービスを呼び出したり、メッセージ通信を行う）を利用する。
［００８２］　また、上記Ｗｅｂサーバの提供するサービスを利用しないアプリケーション８３は、統合ミドルウェア８２を経由して通信を行う。例えば、このようなアプリケーション８３としては、ＨＴＴＰを用いたブラウザソフトウェアが挙げられる。
［００８３］　図１０に示すように、その他の通信用インタフェースが、図９に示した通信プロトコルミドルウェアのソフトウェアブロックに追加されても良い。
［００８４］　図１０に示す構成では、図９に示したのと同様のイーサネットドライバ９０、無線ＬＡＮドライバ９１、ＩＥＥＥ１３９４ドライバ９２によるネットワーク接続可能なソフトウェアブロック構成（それぞれのデバイスドライバ）に加え、携帯電話やコンシューマ製品に適する無線伝送により相互のデータ交換を行う通信用インタフェースとしてのブルートゥース（Ｂｌｕｅｔｏｏｔｈ）ドライバ９３、比較的弱い電波により無線通信を行う特定小電力無線ドライバ９４、電灯線を用いたＰＬＣ（Ｐｏｗｅｒ  Ｌｉｎｅ  Ｃｏｍｍｕｎｉｃａｔｉｏｎ）ドライバ９５のように白物家電系ネットワークに接続するためのソフトウェアブロック（それぞれのデバイスドライバ）が追加されている。
［００８５］　図示するように、各ネットワークインタフェースを制御するデバイスドライバである、ブルートゥースドライバ９３、特定小電力ドライバ９４、ＰＬＣドライバ９５は、ソフトウェアブロック構成における最下層に配置される。
［００８６］　これらデバイスドライバの上位に、ＩＰスタック９６、ＴＣＰ／ＵＤＰスタック９７、白物家電系ネットワークミドルウェア（ＥＣＨＯＮＥＴ）９８が階層的に配置されている。
［００８７］　この場合、統合ミドルウェア１０４をＡＶ系ミドルウェア１００、ＵＰｎＰスタック１０３および白物家電系ネットワークミドルウェア９８の上位に配置することで、図示したデバイスドライバを介するネットワーク、すなわち、イーサネット、無線ＬＡＮ、ＩＥＥＥ１３９４、ブルートゥース、特定小電力無線、ＰＬＣの間において、それぞれ相互通信が可能となり、それらネットワーク間におけるデータの授受ができる。」（第１４頁第２７行−第１８頁第２行）
　
ハ．「［００８８］　図１１は、本実施の形態１であるユビキタス映像モジュール１２のソフトウェアブロックの構成例である。
　この例では、例えばＣＰＵのようなハードウェア層１１０の上位に、マイクロプロセッサ、キャッシュ構成、Ｉ／Ｏバスの違い、割り込み処理方法等の違いによる機種依存性を仮想化することにより、それらの違いを吸収するためハードウェアアダプテーションソフトウェアＨＡＬ（Ｈａｒｄｗａｒｅ  Ａｄａｐｔａｔｉｏｎ  Ｌａｙｅｒ）１１１を配置する。
［００８９］　ＨＡＬ１１１の上位には、マルチタスク用のオペレーティングシステムである組込みＬｉｎｕｘ１１２を配置する。
　組込みＬｉｎｕｘ１１２は、ＨＡＬ１１１に含まれるソフトウェアを介して、各ハードウェアデバイスを制御することに加え、各ハードウェアデバイスに対応したアプリケーションの実行環境を提供する。
［００９０］　また、組込みＬｉｎｕｘ１１２上で動作するグラフィックシステムとしてＸ−Ｗｉｎｄｏｗ１１３（Ｘ−Ｗｉｎｄｏｗｓは、Ｘ  Ｃｏｎｓｏｒｔｉｕｍ，Ｉｎｃの登録商標）が使用される。図１１に示した構成では、以下に説明する、組込みＬｉｎｕｘ１１２の上位層で動作する４つのミドルウェアを配置している。
［００９１］　第１のミドルウェアは、インターネットと接続するための通信処理を行うもので、先に説明したＩＰｖ６プロトコルにも対応しているＩＰｖ６対応インターネット通信プロトコルミドルウェア１１４である。
［００９２］　第２のミドルウェアは、機器をネットワークに接続する際に、その機器のネットワーク接続を自動的に設定するユニバーサルプラグアンドプレイミドルウェア１１５である。
［００９３］　このユニバーサルプラグアンドプレイミドルウェア１１５は、ＩＰｖ６対応のインターネット通信プロトコルミドルウェア１１４に属するプロトコルを使用できるよう、階層的にＩＰｖ６対応インターネット通信プロトコルミドルウェア１１４の上位層に配置する。」（第１８頁第３行−同頁第２５行）
　
ニ．「［０１６７］実施の形態２．
＜イーサネットインターフェースを備える場合のシステム構成について＞
　図２８は、ユビキタス映像モジュール１２を映像情報装置４０のイーサネットインタフェースに接続した場合のシステム構成例を示す図である。
［０１６８］　
ユビキタス映像モジュール１２を含むユビキタス映像モジュールユニット４
［０１６９］　
このユビキタス映像モジュールユニット４の接続により、映像情報装置４０は、ＬＡＮ３３上のネットワークカメラ３４ｄ、３４ｅ及び３４ｆ等の他の機器とＬＡＮ等のネットワークを介して通信・制御することができる
［０１７０］　ここで
映像情報装置４０は、ＮＡＳとの通信・制御に使用するプロトコルを実装している
［０１７１］　図２９は、図２８に示したユビキタス映像モジュール１２を含むユビキタス映像モジュールユニット４におけるソフトウェアブロックの構成例を示す図である。
［０１７２］　映像情報装置４０が装置外部にあるネットワークカメラ３４ｄ、３４ｅ及び３４ｆのいずれかを利用しようとする場合、ユビキタス映像モジュール１２は、ＮＡＳとの通信・制御プロトコルを受信して、イーサネット（Ｅｔｈｅｒｎｅｔ）上のネットワークカメラと通信・制御する。
［０１７３］　ユビキタス映像モジュール１２は、
映像情報装置４０
からＮＡＳ用通信・制御プロトコルを受信する
　イーサネットデバイスコントローラ１６２は、イーサネットエミュレータ１６３を制御して
受信したＮＡＳ用通信・制御プロトコルを解析する
［０１７４］　
解析されたプロトコルは、プロトコルコンバータ
２８によりイーサネット上のネットワークカメラ３４ｄ、３４ｅ及び３４ｆのいずれかとの通信・制御に使用されるプロトコルに変換され、イーサネットドライバ１６１、イーサネットホストインタフェース１６０を介して、ＬＡＮ３３上のネットワークカメラ３４ｄ、３４ｅ及び３４ｆのいずれかとの通信・制御を行う
［０１７５］　以降では、本実施の形態のユビキタス映像モジュール１２についてさらに詳しく説明する。まず、一般的なＮＡＳ、例えば図１８に示したＮＡＳ３４ｃにおけるソフトウェアのブロック図を図３０に示す。ＮＡＳ３４ｃは、イーサネットを用いて映像情報装置４０に接続するための、イーサネットホストＩ／Ｆ３６０、イーサネットドライバ３６１を実装する。さらに、上位の通信プロトコルとしてインターネットプロトコルであるＩＰ３６２を実装し、その上位にＴＣＰ３６３、ＵＤＰ３６４、リモートプロシージャコール（Ｒｅｍｏｔｅ  Ｐｒｏｃｅｄｕｒｅ  Ｃａｌｌ）３６６を実装する。一方、映像情報装置４０から送られてきたデータを記憶するためのＨＤＤ３７１、ＨＤＤ３７１と接続するための記憶デバイスＩ／Ｆ３７０、記憶デバイスドライバ３６９を実装している。そして、ＮＦＳサーバソフトウェア３６７は映像情報装置４０からの要求に従いファイルシステムドライバ３６８を起動し、映像情報装置４０から受信したデータをＨＤＤ３７１に記憶させる。通常、記憶デバイスＩ／Ｆ３７０とＨＤＤ３７１との間の通信プロトコルはＡＴＡ、もしくはＡＴＡＰＩ（ＡＴＡ  Ｐａｃｈｅｔ  Ｉｎｔｅｒｆａｃｅ）である。なお、ＮＡＳは、ＬＡＮに接続された他の機器、例えば映像情報装置４０によってローカル記憶デバイスとして認識され、使用できる点に特徴がある。
［０１７６］　次に、図３１に、本実施の形態におけるユビキタス映像モジュール１２のソフトウェアのブロック構成を示す。図３０に示したＮＡＳ３４ｃとの違いは、ネットワークカメラ３４ｄに接続するために、イーサネットホストＩ／Ｆ３７２、イーサネットドライバ３７３、仮想ファイルシステムドライバ３７６、コマンド処理部３７４、及びリクエスト処理部３７５を実装する点にある。なお、
映像情報装置４０とユビキタス映像ユニット１２との間の通信プロトコルはＮＦＳ、マウントプロトコルが用いられ、ユビキタス映像ユニット１２とネットワークカメラ３４ｄとの間の通信プロトコルにはｈｔｔｐが用いられる
［０１７７］　なお、仮想ファイルシステム３７６の例として、例えばＬｉｎｕｘのＰｒｏｃファイルシステムがある。このＬｉｎｕｘのＰｒｏｃファイルシステムは、あるディレクトリ上にあるように見えるファイルを読み書きすることにより、ＬｉｎｕｘのＫｅｒｎｅｌへのインタフェースを提供する機能を有する。すなわち、Ｐｒｏｃファイルシステムを用いることにより、ディレクトリ上にあるファイルにアクセスすることがＫｅｒｎｅｌの状態を読み出すこととなり、ファイルへの書き込みを行うことがＫｅｒｎｅｌの設定を変更することとなる。本実施の形態のユビキタス映像モジュールユニット１２における
仮想ファイルシステムドライバ３７６も、ＬｉｎｕｘのＰｒｏｃファイルシステムのような機能を有する
［０１７８］　図３２に、
仮想ファイルシステムドライバ３７６により作成された仮想ファイルシステム３８０
この仮想ファイルシステム３８０は
ディレクトリにより表現されるものであり、このディレクトリは映像情報装置４０が認識するものである
作成されたｃｏｍｍａｎｄディレクトリの下には、ｓｅｔ、及びｇｅｔのファイルが配置され、これらはそれぞれコマンド処理部３７４に接続される。映像情報装置４０がｓｅｔ又はｇｅｔのファイルにアクセスすることにより、コマンド処理部３７４を通してユビキタス映像モジュールユニット１２とカメラ３４ｄ、３４ｅとの接続を指示したり、コマンド処理部３７４に接続されたカメラ３４ｄ、３４ｅの接続状況を確認すること等が可能となる。
ｃａｍ１、ｃａｍｓ２等の名称が付されたディレクトリ
［０１７９］　このように、映像情報装置４０は、仮想ファイルシステムドライバ３７６が作成した仮想ファイルシステム３８０にアクセスすることにより、コマンド処理部３７４、リクエスト処理部３７５を介してカメラ３４ｄ、３４ｅを制御したり、画像データを取り出すことが可能となる。すなわち、映像情報装置４０は、ユビキタス映像モジュールユニット１２を介することにより、カメラ３４ｄ、３４ｅからの画像データをＮＡＳからの画像データと認識することとなる。」（第３６頁第２行−第３８頁第２４行）
　
ホ．「［０１８５］　この一連の処理により、仮想ファイルシステム３８０にあるディレクトリとネットワーク上にあるカメラとが関連付けられ、
映像情報装置４０からディレクトリへの書込み処理が、カメラの実際の操作に変換される
映像情報装置４０が既存で有しているＮＦＳのコマンドによりカメラを実際に操作できることとなる
　
ヘ．「［０１９５］　図３７に示した
ディレクトリ構造
それぞれのカメラ用ディレクトリの中に、カメラに対するコマンド送受信用ファイルも配置した
　
ト．「［０１９８］　このような構成を採用することで、ユビキタス映像モジュールユニット１２がＮＡＳ用通信・制御プロトコルとネットワークカメラ用通信・制御プロトコルの変換を行うように構成できる（ＮＡＳ用制御コマンドの送受信を装置外部と行える）。
［０１９９］　そして、これにより、例えば、映像情報装置４０自身のＮＡＳとの通信・制御プロトコルに対応する構成はそのままで、ネットワークカメラ３４ｄ、３４ｅ及び３４ｆのいずれかとの通信・制御プロトコルのための構成を新たに追加すること無く、ＬＡＮ３３上のネットワークカメラ３４ｄ、３４ｅ及び３４ｆのいずれかとネットワークを介して通信・制御できる。すなわち、機能追加に伴う新たなシステムＬＳＩ等の開発が不要となる。
［０２００］　尚、実施の形態２において、上記以外の点は実施の形態１の場合と同じであるので説明を省略する。」（第４３頁第１６行−同頁第２５行）
　
　したがって、引用例には次の発明（以下、「引用発明」という。）が開示されていると認められる。
　
「ユビキタス映像モジュール１２を含むユビキタス映像モジュールユニット４であって、
　このユビキタス映像モジュールユニット４の接続により、ＮＡＳとの通信・制御に使用するプロトコルを実装している映像情報装置４０は、ＬＡＮ３３上のネットワークカメラ３４ｄ、３４ｅ及び３４ｆ等の他の機器とＬＡＮ等のネットワークを介して通信・制御することができ、
　映像情報装置４０からＮＡＳ用通信・制御プロトコルを受信し、受信したＮＡＳ用通信・制御プロトコルを解析し、解析されたプロトコルは、プロトコルコンバータ２８によりイーサネット上のネットワークカメラ３４ｄ、３４ｅ及び３４ｆのいずれかとの通信・制御に使用されるプロトコルに変換され、イーサネットドライバ１６１、イーサネットホストインタフェース１６０を介して、ＬＡＮ３３上のネットワークカメラ３４ｄ、３４ｅ及び３４ｆのいずれかとの通信・制御を行い、
　映像情報装置４０とユビキタス映像ユニット１２との間の通信プロトコルはＮＦＳ、マウントプロトコルが用いられ、ユビキタス映像ユニット１２とネットワークカメラ３４ｄとの間の通信プロトコルにはｈｔｔｐが用いられ、
　ＬｉｎｕｘのＰｒｏｃファイルシステムのような機能を有する仮想ファイルシステムドライバ３７６により仮想ファイルシステム３８０が作成され、この仮想ファイルシステム３８０はディレクトリにより表現されるものであり、このディレクトリは映像情報装置４０が認識するものであり、作成されたディレクトリ構造では、ｃｏｍｍａｎｄディレクトリ、及び、ｃａｍ１、ｃａｍｓ２等の名称が付されたディレクトリの下には、ｓｅｔ、及びｇｅｔのファイルが配置され、これらはそれぞれコマンド処理部３７４に接続され、映像情報装置４０がｓｅｔ又はｇｅｔのファイルにアクセスすることにより、コマンド処理部３７４を通してユビキタス映像モジュールユニット１２とカメラ３４ｄ、３４ｅとの接続を指示したり、コマンド処理部３７４に接続されたカメラ３４ｄ、３４ｅの接続状況を確認すること等が可能となり、
　映像情報装置４０からディレクトリへの書込み処理が、カメラの実際の操作に変換され、映像情報装置４０が既存で有しているＮＦＳのコマンドによりカメラを実際に操作できることとなる、
　ユビキタス映像モジュールユニット４。」
　
（ｃ）対比
　本願補正発明と引用発明とを対比する。
　引用発明の「映像情報装置４０」は、既存でＮＦＳを有しているものであるので、本願補正発明の「所定のファイルシステムフォーマットで記憶装置へのアクセスを行う制御側装置」に相当する。
　引用発明の「ネットワークカメラ３４」は、ｈｔｔｐでユビキタス映像モジュールユニット４から通信・制御が行われるものであるので、本願補正発明の「所定の制御プロトコルで機能が外部から制御されることが可能である被制御側装置」に相当する。
　引用発明の「ユビキタス映像モジュールユニット４」は、映像情報装置４０とネットワークカメラ３４との両方と通信を行っているので、本願補正発明の「通信装置」に相当する。
　引用発明では、仮想ファイルシステム３８０はディレクトリにより表現されるものであり、このディレクトリは映像情報装置４０が認識するものである。ディレクトリが映像情報装置４０で認識されることから、ディレクトリにより表現される仮想ファイルシステム３８０は、映像情報装置４０のファイルシステムフォーマットに準拠して提供されていることは明らかである。よって、引用発明の「ディレクトリにより表現される仮想ファイルシステム」において、「ｃｏｍｍａｎｄディレクトリ、及び、ｃａｍ１、ｃａｍｓ２等の名称が付されたディレクトリ」の構造が、本願補正発明の「ファイル構成情報」に相当し、引用発明の「ユビキタス映像モジュールユニット４」は、「前記制御側装置へ前記ファイルシステムフォーマットに準拠したファイル構成情報を提供するファイル構成提供手段」を有している点で、本願補正発明の「通信装置」と一致している。
　引用発明では、映像情報装置４０からＮＡＳ用通信・制御プロトコル（ＮＦＳ、マウントプロトコル）を受信し、受信したＮＡＳ用通信・制御プロトコルを解析し、解析されたプロトコルは、プロトコルコンバータ２８によりイーサネット上のネットワークカメラ３４ｄ、３４ｅ及び３４ｆのいずれかとの通信・制御に使用されるプロトコル（ｈｔｔｐ）に変換される。また、映像情報装置４０が、ｃｏｍｍａｎｄディレクトリ、及び、ｃａｍ１、ｃａｍｓ２等の名称が付されたディレクトリの構造により、それの下に配置されたｓｅｔ又はｇｅｔのファイルにアクセスすることにより、コマンド処理部３７４を通してユビキタス映像モジュールユニット１２とカメラ３４ｄ、３４ｅとの接続を指示したり、コマンド処理部３７４に接続されたカメラ３４ｄ、３４ｅの接続状況を確認すること等が可能となる。よって、引用発明の「プロトコルコンバータ２８」は、本願補正発明の「プロトコル変換手段」に相当し、引用発明の「ユビキタス映像モジュールユニット４」は、「前記制御側装置からの前記ファイル構成情報に含まれるファイルへのアクセスを、前記制御プロトコルに準拠し前記被制御側装置の前記機能を制御する制御命令情報に変換するプロトコル変換手段」を有している点で、本願補正発明の「通信装置」と一致している。
　引用発明では、プロトコルコンバータ２８により、ＮＡＳ用通信・制御プロトコル（ＮＦＳ、マウントプロトコル）をネットワークカメラ３４との通信・制御に使用されるプロトコル（ｈｔｔｐ）に変換し、イーサネットドライバ１６１、イーサネットホストインタフェース１６０を介して、ＬＡＮ３３上のネットワークカメラ３４との通信・制御を行っている。よって、引用発明の「イーサネットドライバ１６１、イーサネットホストインタフェース１６０」は、本願補正発明の「制御命令提供手段」に相当し、引用発明の「ユビキタス映像モジュールユニット４」は、「前記制御命令情報を前記被制御側装置へ提供する制御命令提供手段」を有している点で、本願補正発明の「通信装置」と一致している。
　
　したがって、両者の一致点・相違点は、次のとおりである。
　
＜一致点＞
「所定のファイルシステムフォーマットで記憶装置へのアクセスを行う制御側装置と所定の制御プロトコルで機能が外部から制御されることが可能である被制御側装置との両方と通信を行う通信装置において、
　前記制御側装置へ前記ファイルシステムフォーマットに準拠したファイル構成情報を提供するファイル構成提供手段と、
　前記制御側装置からの前記ファイル構成情報に含まれるファイルへのアクセスを、前記制御プロトコルに準拠し前記被制御側装置の前記機能を制御する制御命令情報に変換するプロトコル変換手段と、
　前記制御命令情報を前記被制御側装置へ提供する制御命令提供手段と、
を備えることを特徴とする通信装置。」
　
＜相違点＞
　本願補正発明は、通信装置が制御側装置へ提供するファイル構成情報が、被制御側装置から取得した特性に基づいて生成されたものであるのに対して、引用発明のファイル構成情報は、そのようなものではない点。
　
　
（ｄ）判断
　以下、相違点について検討する。
　引用例において、被制御側装置が、ＥＣＨＯＮＥＴやＵＰｎＰなどのネットワークを介して通信装置に接続することが開示されている（記載事項イ・ロ）。
　ネットワークに接続された機器において、該ネットワークに接続された被制御側装置から該被制御側装置の特性を取得することは、たとえば特開２００３−３０８２６４号公報（段落【００１６】−【００１８】）や、特開２００３−３０９８８４号公報（段落【００４０】）にみられるように周知な技術である。また、被制御側装置の特性に基づいてファイル構成情報を生成することは、たとえば特開２００４−３１８８６４号公報（【請求項２】−【請求項４】，段落【００２３】−【００２９】）や、特開２００４−３０２６５８号公報（段落【００８６】−【００９７】）にみられるように周知な技術である。
　したがって、引用発明において、ネットワークに接続された被制御側装置から該被制御装置の特性を取得し、該特性に基づいてファイル構成情報を生成するように構成することは、当業者が容易に想到し得たことである。
　また、本願補正発明が奏する効果も、引用発明及び周知技術に基づいて、当業者が予測し得る範囲内のものである。
　
　
（ｅ）結論
　そうすると、本願補正発明は、引用発明及び周知技術に基づいて当業者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により、特許出願の際独立して特許を受けることができないものである。
　したがって、本件補正は、平成１８年法律第５５号改正附則第３条第１項によりなお従前の例によるとされる同法による改正前の特許法第１７条の２第５項において準用する同法第１２６条第５項の規定に違反するので、同法１５９条第１項において読み替えて準用する同法第５３条第１項の規定より却下すべきものである。
　
　
第三　本願発明
　上記のとおり、本件補正は却下されたので、本願の請求項１に係る発明（以下、「本願発明」という。）は、平成２２年１月１９日に提出された手続補正書における特許請求の範囲の請求項１に記載された事項により特定される、以下のとおりのものである。
　
「所定のファイルシステムフォーマットで記憶装置へのアクセスを行う制御側装置と所定の制御プロトコルで機能が外部から制御されることが可能である被制御側装置との両方と通信を行う通信装置において、
　前記制御側装置へ前記ファイルシステムフォーマットに準拠し、前記被制御側装置の特性に合わせたファイル構成情報を提供するファイル構成提供手段と、
　前記制御側装置からの前記ファイル構成情報に含まれるファイルへのアクセスを、前記制御プロトコルに準拠し前記被制御側装置の前記機能を制御する制御命令情報に変換するプロトコル変換手段と、
　前記制御命令情報を前記被制御側装置へ提供する制御命令提供手段と、
を備えることを特徴とする通信装置。」
　
　
第四　引用例
　原査定の拒絶の理由に引用された引用例、及びその記載事項は、前記「第
二（ｂ）」に記載したとおりである。
　
　
第五　対比・判断
　本願発明は、前記「第二　補正の却下の決定」で検討した本願補正発明の「前記被制御側装置
から取得した
基づいて生成され
　そうすると、本願発明の構成要件をすべて含み、さらに「前記被制御側装置の特性に合わせたファイル構成情報」を下位概念化したものに相当する本願補正発明が、前記「第二　補正の却下の決定」に記載したとおり、引用発明及び周知技術に基づいて、当業者が容易に発明をすることができたものであるから、本願発明も同様の理由により、引用発明及び周知技術に基づいて、当業者が容易に発明をすることができたものである。
　
　
第六　むすび
　以上のとおり、本願発明は、引用発明及び周知技術に基づいて、当業者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により、特許を受けることができない。
　したがって、本願は、その余の請求項について論及するまでもなく拒絶すべきものである。
　よって、結論のとおり審決する。