【事件の表示】
　平成　９年特許願第２３６０３７号「通信インタフェース装置」拒絶査定不服審判事件〔平成１１年　３月３０日出願公開、特開平１１−　８５６５１〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
１．手続の経緯・本願発明
　本願は、平成９年９月１日の出願であって、 平成１５年１２月２４日付けで拒絶査定がされ、これに対し、平成１６年２月５日に拒絶査定不服審判が請求されるとともに、同日付けで手続補正がなされたものである。
　そして、当審において、平成１８年８月３日付けで拒絶理由が通知され、その指定期間内である平成１８年１０月５日付けで手続補正書が提出されたものである。
　
　本願の請求項１に係る発明（以下、「本願発明」という。）は、平成１８年１０月５日付け手続補正書の特許請求の範囲の請求項１に記載された事項により特定される、以下のとおりのものである。
　
「通信対象機器とこれを操作し或いはその動作を監視する管理装置との間に介在する通信ネットワークに対して前記機器を接続するための通信インタフェース装置であって、
　前記機器と前記通信ネットワークとの間の第一のポートを通して前記管理装置からの接続要求がある毎に送受される信号のプロトコル変換を行うソケットサーバと、
　前記通信ネットワークとの間の第二のポートを通して接続されるＷＷＷサーバと、
　該ＷＷＷサーバに接続された記憶手段とを備え、
　該記憶手段には、前記管理装置に設けられたクライアントプログラムに従って前記通信ネットワーク経由で前記管理装置に転送され且つ前記クライアントプログラム上で実行されるアプリケーションプログラムおよび各種情報が格納されていることを特徴とする通信インタフェース装置。」
　
　
２．引用刊行物
　
　当審の拒絶の理由に引用されたGoldberg, K.; Mascha, M.; Gentner, S.; Rothenberg, N.; Sutter, C.; Wiegley, J.;'Desktop teleoperation via the World Wide Web',Robotics and Automation, 1995. Proceedings., 1995 IEEE International Conference on Volume 1, 21-27 May 1995, Page(s):654 - 659 vol.1（以下、「引用刊行物１」という。）には、図面と共に、
　
「In the Spring of 1994, hundreds of WWW servers were coming online every week. We conjectured that it might be possible to use this medium to allow low cost public access to a teleoperated robot, in effect providing: desktop teleoperation.
 As illustrated in Figure 1, we set up a SCARA-type robot arm over a semi-annular workspace containing sand and buried artifacts. We attached a CCD camera to the end of the arm along with a nozzle to direct air bursts into the sand.
We then developed an interface so this hardware could be controlled via the WWW.」（第６５４頁［1 Goals of the Project］の項）
　
「1994年春には、何百ものWWWサーバーが毎週オンライン化していた。我々は、デスクトップの遠隔操作という趣旨で、この媒体を利用して遠隔操作ロボットへの一般からのアクセスを低価格で実現できるのではないかと推測した。
　図1に説明するように、砂と埋め込み人工物を含む半円状の作業領域の上部にスカラ型ロボットアームを設置した。ノズルと共にアームの端にCCDカメラを取り付け、空気が砂に放出されるようにした。次に、このハードウェアのWWWによる操作を可能とするインターフェースを開発した。」（第６５４頁［1　本プロジェクトの目標］の項の和訳）
　
「To facilitate use by a wide audience of non-specialists, we sought to make all robot controls available via the standard point-and-click mouse commands as shown in Figure 2.
This forced us to consider a 2D workspace with only a few buttons for out-of-plane effects. Users are trained with an on-line tutorial prior to operating the robot.
 The user interface centers around the bitmap that we call the “status image” as shown in Figure 3. Any number of “observers” car1 simultaneously view the status image, but only the current “operator” can send commands by clicking on the image. To limit access to one operator at a time,we implemented password authentication and a queue that gives each operator 5 minutes at the helm.
 When the operator clicks on the status image using the mouse, theXY coordinates are transferred back to our server,which interprets them to decode the desired robot action.
This action can be: (1) a global move to center the camer at XY in the schematic workspace, (2) a local move to center the camera at XY in the camera image, (3) moving the camera to one of two fixed Z heights, or (4) blowing a burst of compressed air into the sand directly below the camera.
 We worked to reduce the size of the status image to minimize turnaround time when a command is issued. The average image size for the status image, encoded as a .gif file, is 17.3 Kbytes. Although were able to achieve response times of 10 seconds for on-campus users, cycle times of up to 60 seconds were reported from users in Europe operating via 14.4K telephone lines.
 Just for fun, we created a fictional context for the system,inventing the history of a deceased paleuhydrologist who had discovered unexplained artifacts in a radioactive region of southwest Nevada. We explained that the Mercury robot was originally developed to explore that region and that one mandate of our grant was to make our system “available to the broader scientific community”. A hypertext document describing this background provides an online introduction.」（第６５５頁［３　System Design and User Interface］の項）
　
「専門家でない幅広いユーザーによる利用を容易にするために、図2に示すように標準ポイントアンドクリック方式のマウスのコマンドによりすべてのロボットの制御を利用できるようにするよう努めた。このため、我々は、面外への影響のために数個のボタンのみを備えた二次元の作業領域を検討しなければならなかった。ユーザーには、ロボットを操作する前にオンラインでの指導による研修が行われた。
　ユーザーのインターフェースは、図3に示すように我々が「ステータスイメージ」と呼ぶビットマップを軸に展開されている。「オブザーバー」が何人であろうと、ステータスイメージを同時に見ることができるが、イメージにクリックしてコマンドを送信することができるのは、その時の「オペレーター」だけである。オペレーターへの同時のアクセスを制限するために、パスワード認証と各オペレーターに5分間舵取りする時間を与える待ち行列を実装した。
　オペレーターがマウスを使用してステータスイメージをクリックすると、XY座標が我々のサーバーに再転送され、サーバーはこれらの座標を解釈し、望まれたロボットの行動を解読する。この行動として考えられるものは、次のものである。（1）作業領域図のXYにカメラを集中させる広範囲の動き、（2）カメラ画像のXYにカメラを集中させる局所的な動き、（3）カメラを固定された高さZの2点のうちの1点にカメラを移動させること、あるいは（4）カメラの真下の砂に圧縮空気を放出すること、である。
　コマンドが出されたときの応答時間が最小となるように、ステータスイメージのサイズを減らす努力をしている。.gifファイルとしてコード化されたステータスイメージの平均画像サイズは、17.3キロバイトである。大学構内のユーザーについては応答時間を10秒とすることができたが、14.4キロバイトの電話回線により操作するヨーロッパのユーザーからのサイクルタイムは最大60秒であった。
　遊びのつもりで、我々は、南西部のネバダ州の放射線を帯びた地域において原因不明の人工物を発見したすでに故人となっている古水文学者の経歴をでっち上げて、このシステムの架空のコンテキストを作成した。そして、マーキュリーロボットは当初はこの地域を探索するために開発されたのであり、我々が助成金を受けるための使命の一つは、このシステムを「より広範な科学コミュニティが利用できるように」することであったと説明した。この背景を説明するハイパーテキスト文書が、オンライン上で紹介されている。」（第６５５頁［３　システム設計とユーザーインターフェース］の項の和訳）
　
「To allow users to manipulate the remote environment we initially planned to place a simple gripper at the end effector.
Anticipating user attempts at sabotage (which is, after all, the time-honored hacker tradition), we opted to use compressed air as the medium for manipulation.
 The CCD camera is an EDC 1000 from Electrim Inc. This camera was chosen based on size and cost. Image data is sent from the camera back through a custom serial line to a video capture card. The camera image has a resolution of 192 by 165 pixels with 256 shades of gray, which we truncate to 64 shades to reduce transfer time. Exposure time can be changed by software to range between 64ms to 200ms. Although we slowed the robot to minimize dynamiceffects, mechanical settling times are long enough to cause image blur at the camera. To avoid this, we implemented a stability check by taking two images separated by 64ms and differencing them. Subsequent images are taken until the two successive images are sufficiently similar.
 To avoid the complexity of another servo motor, we use a fixed focus camera and choose a focal point that compromises between the two fixed camera heights. The workspace is primarily illuminated by standard florescent fixtures. We tested a contrast enhancement routine to normalize the lighting of each image captured from the camera. This increased image quality in most cases but exaggerated intensity variations across the workspace.」（第６５６頁［4 Robot and Camera］の項）
　
「ユーザーが遠隔環境を操作できるように、当初は、エンドエフェクターに単純なグリッパを設置する予定であった。ユーザーが妨害行為を試みることを予想して（この行為は、結局のところ、昔ながらのハッカーの伝統であるのだが）、我々は、操作の手段として圧縮空気を使用することを選択した。
　CCDカメラは、Electrim Inc.のEDC 1000である。このカメラは、サイズとコストを基に選択した。画像データは、カメラから顧客のシリアル回線を通してビデオキャプチャーカードに送り返される。カメラ画像の解像度は192×164ピクセルで256階調であり、我々は転送時間を短縮するためにこれを64階調に減らした。露光時間は、ソフトウェアにより、64ミリ秒から200ミリ秒となるように変更することができる。運動力の作用が最小となるように、ロボットの動きを遅くしたが、機械の整定時間が長かったため、カメラに画像のぶれが生じた。これを回避するために、64ミリ秒の間をあけて2つの画像を撮影し、これらに差をつけることにより安定度試験を行った。2つの連続して撮影された画像が十分に類似したものになるまでその後も続けて画像が撮影された。
　他の複雑なサーボモーターを避けて、我々は、固定焦点カメラを使用し、2つの固定カメラの高さの間で妥協する焦点を選択する。作業領域は、主に標準蛍光灯器具により照らされている。カメラからキャプチャーされた各画像の明るさを標準化するためにコントラスト強化ルーチンを試験した。これにより、ほとんどのケースで画質が向上したが、作業領域全体の強度変化が増大した。」（第６５６頁［４　ロボットとカメラ］の項の和訳）
　
「As shown in Figure 4, WWW clients from around the world enter our system through the Internet. The system includes three communicating subsystems. Server A responds to Universal Resource Locator (URL) requests for any file on the raiders/ directory. Server A runs the vanilla NCSA HTTP Demon v.1.3 on a Sun SPARCserver 1000, with SunOS Release 5.3. Server A caches the most recent status image and sends it whenever an observer request comes in.
 When a user registers as an operator by entering a password,we use a database server to verify. This server, B,runs on the same machine as Server A. The database server is custom programmed for this project, but performs fairly standard database functions.
 When an operator is verified, Server A either adds the operator to the queue or communicates with Server C which controls the robot. Server A decodes the ISMAP X and Y mouse coordinates, and sends them across campus to Server C via Ethernet.
 On Server C, a custom program decodes the XY coordinates into a robot command and verifies that the command is legal, e.g., within the robot workspace. If it is, the command is then executed via a command sent to the robot over a 4800 baud serial line. Once the command is completed, server C uses a local frame buffer to capture the image.
 Server C then generates a new schematic view of the robot in the resulting configuration, combines it with the camera image and appropriately highlighted control buttons to form a new status image. Server C then compresses this image into GIF format and returns it to Server A, which updates the most recent status image and returns it to the client.
 To maintain compatibility with the widest possible set of user platforms, we stayed within the the standard HTTP protocol.For example, although X windows permit live video feed, we sacrificed this feature for the sake of compatibility.We hope that future versions of the protocol will allow the server to connect to and update clients to avoid manual re-loading of images.
 The major difficulty in implementing Server C was scheduling responses to the network, the local mouse, and the image capture board. Although we seriously considered a multi-tasking environment such as Linux, the Electrim camera was only compatible with DOS and the company would not part with any source code. Thus we hand-crafted our memory management and used the screen itself as a memory buffer. This enabled us to speed a custom GIF encoder down to a few microseconds per status image.」（第６５６頁〜第６５７頁［5 System Architecture］の項）
　
「図4に示すように、世界中からのWWWクライアントは、インターネットを介して我々のシステムに入っている。システムには、3つの通信サブシステムが含まれる。サーバーAは、the raiders／ディレクトリ上のファイルに対するURL要求に応答する。サーバーAは、SunOS Release 5.3と共に、サン社のSPARCserver 1000に関する標準的な米国スーパーコンピューティング応用研究センター（NCSA）のHTTPデーモン（1.3バージョン）を実行する。サーバーAは、最新のステータスイメージをキャッシュし、オブザーバーの要求が入ってくるといつでもそれを送信する。
　ユーザーがパスワードの入力によりオペレーターとして登録すると、我々はデータベースサーバーを使用してそれを検証する。このサーバーBは、サーバーAと同じマシン上で実行される。データベースサーバーは、このプロジェクト向けにカスタムプログラミングされているが、ごく普通のデータベース機能を果たしている。
　オペレーターが検証されると、サーバーAは、そのオペレーターを待ち行列に追加するか、ロボットを制御するサーバーCと通信する。サーバーAは、ISMAPのXとYのマウス座標を解読し、それらを構内全体にわたってイーサネットによりサーバーCに送信する。
　サーバーC上では、カスタムプログラムがXY座標を解読してロボットへのコマンドにし、そのコマンドが例えばロボットの作業領域内で正当であることを検証する。コマンドが正当であるならば、そのコマンドは、4800ボーのシリアル回線でロボットに送信されるコマンドにより実行される。コマンドが完了した時点で、サーバーCは、ローカルフレームバッファを使用して画像をキャプチャーする。
　次にサーバーCは、結果として生じる形態でロボットの概略図を新たに作成し、それをカメラ画像や適切に強調表示された制御ボタンと結び付け、新しいステータスイメージを形成する。サーバーCは、この画像をGIFフォーマットに圧縮し、それをサーバーAに戻す。サーバーAは、最新のステータスイメージを更新し、それをクライアントに戻す。
　最大限幅広いユーザープラットフォームとの互換性を維持するために、本研究では、標準HTTPプロトコルの範囲内に留めた。例えば、Xの画面でライブビデオ画像が許可されたが、互換性のためにこの機能を犠牲にした。プロトコルの将来バージョンでは、手作業で画像を再ロードしなくてよいように、サーバーがクライアントに接続し、更新できるようになっていることを願う。
　サーバーCを実行するにあたっての大きな難題は、ネットワーク、ローカルマウス、画像キャプチャボードへの応答のスケジューリングであった。我々は、Linuxなどのマルチタスク環境とすることも検討したが、Electrim社のカメラはDOSとのみ互換性があり、また同社はソースコードを手放さないだろう。そのため、我々はメモリ管理を手作りで行い、スクリーン自体をメモリバッファーとして使用した。これによって、カスタムGIFエンコーダの速さを上げて1ステータスイメージあたり2〜3ミリ秒に落とすことが可能となった。」（第６５６頁〜第６５７頁［5　システムアーキテクチャ］の項の和訳）
　
「Each time Server A returns a new status image to an operator or observer, it adds a large random number to its embedded URL for the update button. This random token prevents the client from caching the status image (otherwise repeated requests to update the image would simply reload the local image and not request an updated image from Server A).
 The random token also allows Server A to identify and track clients. When an operator logs in with a verified password,Server A tracks the operator by maintaining a database of recent clients so that URL requests can be customized depending on the user’s status. For example the queue is only visible to the operators and those on deck.
 Servers A and B are at opposite ends of the USC campus and are connected via Ethernet. Each machine has its own IP address and resides in the usc.edu domain. Communication is achieved using a socket connection between the two machines.The implementation on Server A was done using the standard BSD socket functions provided with the SunOS 4.1 operating system and Perl. On Server C we used a publicly available socket package called Waterloo TCP and Borland C. The Waterloo TCP package was obtained from the ftp site dorm.rutgers.edu in the file /pub/msdos/wattcplwattcp.zip.」（第６５７頁［5.1 Random Tokens］の項）
　
「サーバーAは、新しいステータスイメージをオペレーター又はオブザーバーに戻すたびに、更新ボタンの埋め込みURLに大きな乱数を追加する。このランダムトークンは、クライアントがステータスイメージを格納することを妨げる（そうでなければ、画像の更新が繰り返し要求されることによりローカル画像が簡単に再ロードされ、サーバーAからの更新された画像は要求されない）。
　またランダムトークンは、サーバーAがクライアントを特定し、追跡することも可能にする。オペレーターが認証パスワードによりログインすると、サーバーAは、最近のクライアントのデータベースを維持することによりオペレーターを追跡し、ユーザーのステータスによりURL要求をカスタマイズできるようにする。例えば、待ち行列を見ることができるのは、オペレーターとデッキにいるものだけである。
　サーバーAとBは、南カリフォルニア大学キャンパスの両端にあり、イーサネットにより接続されている。それぞれの機械が、独自のIPアドレスを持っており、usc.eduドメインに属する。2つの機械の間にソケット接続を使用することで、通信が行われている。サーバーAにおける実装は、SunOS 4.1オペレーティングシステムとパールと共に提供される標準BSDソケットを使用して行われた。サーバーCには、一般に入手可能なWaterloo TCPとBorland Cと呼ばれるソケットパッケージを使用した。Waterloo TCPパッケージは、FTPサイト（dorm.rutgers.edu）のfile/pub/msdos/wattcp/wattcp.zipから入手することができる。」（第６５７頁［5.1　ランダムトークン］の項の和訳）
　
　と、記載されている。
　そして、図面の説明として、
「Figure 1 : Robot, camera and air nozzle above workspace.」、「図1：作業領域上のロボット、カメラ、空気ノズル」（和訳）
「Figure 2: The interface as viewed by a WWW browser.」、図2：WWWブラウザから見たインターフェース（和訳）
「Figure 3: The “status image”. At the right is a schematic top view of the semi-annular workspace and robot linkage. At left is a CCD camera image of the view directly beneath the robot end-effector. UpDown buttons are included for Z motion of the camera. and the round button is used to blow a burst of compressed air into the sand.」、「図3：「ステータスイメージ」。右側は、半円状の作業領域とロボットの連結の図を上面から見たものである。左側は、ロボットのエンドエフェクターの真下の光景をCCDカメラで撮った画像である。上下操作ボタンは、カメラのZ点の動きに含められている。丸ボタンは、砂に圧縮空気を放出するために使用される。」（和訳）
「Figure 4: System Architecture」、「図4：システムアーキテクチャ」（和訳）
　そして、図４には、インターネットに接続されたWWWクライアント、インターネットに接続されたHTTPサーバー及びデータサーバーBを含み動的文書のスクリプトが実行されるUNIXサーバーＡと、インターネットに接続されたPCロボットサーバーCと、PCロボットサーバーCには、カメラとロボットが接続されていることが記載されている。
　
　
　これらの記載によれば、引用刊行物１には、
「圧縮空気が放出されるノズルと共にアームの端にCCDカメラを取り付けたロボットを、オペレータは、ＷＷＷブラウザを用いてマウスを使用してＷＷＷブラウザ上に表示されているステータスイメージをクリックすることによりコマンドを送信して操作し、当該操作による行動には、（1）作業領域図のXYにカメラを集中させる広範囲の動き、（2）カメラ画像のXYにカメラを集中させる局所的な動き、（3）カメラを固定された高さZの2点のうちの1点にカメラを移動させること、（4）カメラの真下の砂に圧縮空気を放出することがあり、
　前記ステータスイメージは、半円状の作業領域とロボットの連結の図を上面から見たもの、ロボットのエンドエフェクターの真下の光景をCCDカメラで撮った画像、上下操作ボタン及び丸ボタンからなり、前記上下操作ボタンは、カメラのZ点の動きに含められており、前記丸ボタンは、砂に圧縮空気を放出するために使用されるものであり、
　前記ステータスイメージは、オブザーバーが同時に見ることができるものであり、当該ステータスイメージをクリックすることによりコマンドを送信することができるのは、オペレータだけであり、
　このシステムでは、ＷＷＷクライアントは、インターネットを介して、当該システムに入ってくるものであり、
　インターネットに接続されたＨＴＴＰサーバーであるサーバーAと、
　インターネットに接続されたサーバーCと、
　サーバーCに接続された前記CCDカメラ及び前記ロボットからなり、
　サーバーAは、the raiders／ディレクトリ上のファイルに対するURL要求に応答し、最新のステータスイメージをキャッシュし、オブザーバーの要求が入ってくるとそれを送信し、
　ユーザーがパスワードの入力によりオペレーターとして登録すると、データベースサーバーを使用して検証し、当該データベースサーバーは、サーバーAと同じマシン上で実行され、前記オペレーターの検証が終わると、サーバーAは、そのオペレーターを待ち行列に追加するか、ロボットを制御するサーバーCと通信し、
　サーバーAは、ISMAPのXとYのマウス座標を解読し、サーバーCに送信し、
　サーバーC上では、カスタムプログラムがXY座標を解読してロボットへのコマンドにし、前記コマンドは、4800ボーのシリアル回線でロボットに送信されるコマンドにより実行され、当該コマンドが完了した時点で、サーバーCは、ローカルフレームバッファを使用して画像をキャプチャーし、当該コマンド実行の結果として生じる形態でロボットの概略図を新たに作成し、それをカメラ画像、制御ボタンと結び付け、新しいステータスイメージを形成し、この画像をGIFフォーマットに圧縮し、サーバーAに戻し、
　サーバーAは、最新のステータスイメージを更新し、それをクライアントに戻すシステム。」の発明（以下「引用刊行物１発明」という。）が記載されているものと認めることができる。
　
　
　当審の拒絶の理由に引用された高梨伸彰他１名、「ロボットコントローラの上位通信インターフェースと内部通信インターフェース」、１９９６年月１５日発行、日本ロボット学会誌、第１４巻、第６号　第７８４頁−第７８７頁（ＪＲＳＪ　Ｖｏｌ．１４　Ｎｏ．６、第２６頁−第２９頁）（以下、「引用刊行物２」という。）には、図面と共に、
　
「２．２　インターネットを通したロボットの操作
　インターネットの爆発的な普及に伴い，ロボットや加工機器・検査機器等のネットワークとの結合が重要視されている［２］．インターネットのホームページにロボットを日本から簡単に操作できる例も増加している［３］［４］．
　U.C.Berkeleyのシステム［３］ではシリアル通信ポートによりロボットをワークステーションに接続し，ネットワークから直接ロボットに動作指令を出す（図２）．ユーザがＷＷＷ（World Wide Web［５］）のブラウザ上に表示された操作ボタンを押すと，インターネットを通してＨＴＴＰサーバがロボットにコマンドを送出する．ロボットの先端のカメラから移動後の画像がブラウザに送られ，ユーザは遠く離れた場所からロボットを駆動して周囲を見ることができる．」（第２６頁）
「２．３　上位通信フォーマットの例
　上記のような実時間にて上位系から直接操作するロボットは研究用実験システムとして開発例がある［６］．特に遠隔操作ロボットでは通信コマンドによる直接ロボット操作は必須である．一例として宇宙ロボット作業実験システム［７］に適用した通信フォーマットを第３図にに示す．
　ここでは，汎用性を重視したＲＳ２３２Ｃ通信コマンドと高速性を重視したＥｔｈｅｒｎｅｔ　ＴＣＰ／ＩＰ通信コマンドを定義した．ＲＳ２３２Ｃ通信コマンドは７ｂｉｔＡＳＣＩＩ文字列からなり，開始文字（ＳＴＸ：０２ｈ）に続いてコマンド文字，（必要なら）パラメータ，チェックサム，終了文字（ＣＲ：０Ｄｈ）からなる．Ｅｔｈｅｒｎｅｔ通信コマンドはソケット通信によりデータを直接送受信するため，開始文字（ｉｄ），コマンド文字とバイナリデータ形式のパラメータのみを送受する．両者でコマンド文字とコマンド毎のパラメータ数及び解釈を共通化した．
　通信コマンドは，動作コマンドと制御コマンドの２種に分けた．動作コマンドはロボット動作に関連し，動作が完了するまで次のコマンドの実行を猶予する。制御コマンドは上位から通信を受け付け次第直ちに処理を実行する．
ＲＳ２３２Ｃ通信コマンドとＥｔｈｅｒｎｅｔ通信コマンドの定義はほぼ共通である．表１に代表的コマンドをまとめる．」（第２７頁左欄）
　
　これらの記載によれば、引用刊行物２には、
「遠隔操作ロボットに用いる通信コマンドの通信フォーマットにおいて、ＲＳ２３２Ｃ通信コマンドとＴＣＰ／ＩＰ通信コマンドとでコマンド文字とコマンド毎のパラメータ数及び解釈を共通化する」発明（以下「引用刊行物２発明」という。）が記載されているものと認めることができる。
　
　
　３．対比
　
　そこで、本願発明と引用刊行物１発明とを比較すると、引用刊行物１発明の「CCDカメラ」及び「ロボット」は、本願発明の「通信対象機器」に相当する。以下、同様に、「インターネット」は「通信ネットワーク」に、「ＷＷＷブラウザ」は「クライアントプログラム」に、それぞれ相当する。
　引用刊行物１発明の「サーバーA」は、ＨＴＴＰサーバーであるから、本願発明の「ＷＷＷサーバ」に相当する。
　引用刊行物１発明のオペレータは、ＷＷＷブラウザを用いてマウスを使用してWWWブラウザ上に表示されているステータスイメージをクリックすることによりコマンドを送信してロボットを操作し、前記ステータスイメージには、半円状の作業領域とロボットの連結の図を上面から見たもの、ロボットのエンドエフェクターの真下の光景をCCDカメラで撮った画像が含まれることから、引用刊行物１発明のオペレータは本願発明の「管理装置」に相当する装置を用いており、通信対象機器であるロボット、カメラを操作し、その動作を監視していることは、明らかである。
　引用刊行物１発明のオペレータは、ＷＷＷブラウザを用いてマウスを使用してWWWブラウザ上に表示されているステータスイメージをクリックすることによりコマンドを送信してロボットを操作することから、前記マウスを使用したクリックにより送信されるコマンドは、本願発明の「管理装置からの接続要求」に相当する。
　引用刊行物１発明の「サーバーC」は、オペレータのマウス座標に関連するXY座標を解読して、ロボットへのコマンドにし、前記コマンドは、4800ボーのシリアル回線でロボットに送信されるコマンドにより実行され、コマンドが完了した時点で、新しいステータスイメージを形成し、この画像をGIFフォーマットに圧縮し、サーバーAに戻し、サーバーAは、最新のステータスイメージを更新し、それをクライアントに戻すものであり、コマンドが完了した時点で、新しいステータスイメージを形成することから、コマンドが完了した時点で、ロボットからサーバーCにコマンドが完了した信号が送信され、シリアル回線を介して、サーバーCで前記信号を受信することは明らかである。
　そして、オペレータ、サーバーA及びサーバーCは、インターネットを介して接続されていることから、信号が、ＴＣＰ／ＩＰ通信信号からシリアル通信信号に、シリアル通信信号からＴＣＰ／ＩＰ通信信号に変換されていることは、明らかである。
　したがって、引用刊行物１発明の「サーバーC」は、本願発明のソケットサーバと、「管理装置からの接続要求がある毎に送受される信号の変換を行うサーバ」である点で一致する。
　引用刊行物１発明の「サーバーA」は、the raiders／ディレクトリ上のファイルに対するURL要求に応答し、最新のステータスイメージをキャッシュしていることから、記憶手段が接続されていることは明らかである。
　引用刊行物１発明の「the raiders／ディレクトリ上のファイル」及び「ステータスイメージ」は、本願発明の「各種情報」に相当する。
　引用刊行物１発明の「サーバーＡ」及び「サーバーＣ」は、通信対象機器であるCCDカメラ及びロボットを、通信ネットワークであるインターネットを介してＷＷＷクライアントに操作させるためのものであり、通信ネットワークに対して通信対象機器を接続するものであることは明らかであるから、本願発明の「通信インタフェース装置」に相当する。
　
　以上総合して、両者は、
「通信対象機器とこれを操作し或いはその動作を監視する管理装置との間に介在する通信ネットワークに対して前記機器を接続するための通信インタフェース装置であって、
　前記機器と前記通信ネットワークとの間で前記管理装置からの接続要求がある毎に送受される信号の変換を行うサーバと、
　前記通信ネットワークに接続されるＷＷＷサーバと、
　該ＷＷＷサーバに接続された記憶手段とを備え、
　該記憶手段には、各種情報が格納されていることを特徴とする通信インタフェース装置。」の点で一致し、以下の点で相違している。
　
　
［相違点１］本願発明では、信号の変換を行うサーバについて、管理装置からの接続要求が通信対象機器と通信ネットワークの間の第一のポートを通してなされ、ＷＷＷサーバについて、通信ネットワークとの間の第二のポートを通して接続されているのに対して、引用刊行物１発明では、信号の変換を行うサーバ、ＷＷＷサーバについて、ポートに関する記載がない点。
　
［相違点２］
　信号の変換を行うサーバについて、本願発明では、プロトコル変換を行うソケットサーバであるのに対し、引用刊行物１発明では、そのようなソケットサーバであるかどうか不明な点。
　
［相違点３］
　本願発明では、記憶手段に、管理装置に設けられたクライアントプログラムに従って通信ネットワーク経由で前記管理装置に転送され且つ前記クライアントプログラム上で実行されるアプリケーションプログラムが格納されているのに対して、引用刊行物１発明では、管理装置にクライアントプログラムは設けられているが、当該クライアントプログラムに従って通信ネットワーク経由で前記管理装置に転送され且つ前記クライアントプログラム上で実行されるアプリケーションプログラムを記憶手段に格納することは記載されていない点。
　
　
４．当審の判断
　
　
　［相違点１］について
　例えば、特開平６−３２４９７８号公報（【０００２】段落−【０００３】段落）に示されるように、サーバの提供する異なるサービスによって、異なるポートを用いることは、周知であるから、信号の変換を行うサーバについて、管理装置からの接続要求が通信対象機器と通信ネットワークの間の第一のポートを通してなされるようにし、ＷＷＷサーバについて、通信ネットワークとの間の第二のポートを通して接続することは、当業者が適宜なし得る事項である。
　
　［相違点２］について
　引用刊行物１発明のサーバーCは、インターネットに接続され且つシリアル回線に接続されていることからＴＣＰ／ＩＰの通信信号を、ＴＣＰ／ＩＰ以外の通信信号に変換する（もしくは、ＴＣＰ／ＩＰ以外の信号をＴＣＰ／ＩＰに変換する）ものである。
　そして、引用刊行物２発明では、通信対象機器である遠隔操作ロボットを操作する通信フォーマットについて、ＴＣＰ／ＩＰ通信コマンドとＲＳ２３２Ｃコマンド（ＴＣＰ／ＩＰ以外の信号）とで、コマンド文字、コマンド毎のパラメータ数及び解釈を共通化しており、さらに、例えば、当審の拒絶の理由に引用された特開平９−２２３９１号公報に示されるように、ＴＣＰ／ＩＰの通信信号をＴＣＰ／ＩＰ以外の通信信号に変換するものにおいて、要求がある毎に送受される信号を、ソケットサーバを用いて、前記ＴＣＰ／ＩＰの通信信号を前記ＴＣＰ／ＩＰ以外の通信信号に、前記ＴＣＰ／ＩＰ以外の通信信号を前記ＴＣＰ／ＩＰの通信信号に変換するプロトコル変換を行うことは周知である。
　したがって、引用刊行物１発明において、信号の変換を行うサーバについて、上記周知のように、プロトコル変換を行うソケットサーバとすることは、当業者が容易に想到し得ることである。
　
［相違点３］について
　当審の拒絶の理由に引用された河井保博著、「特集　より速く，より表現力豊かに　変貌するＷＷＷ」、日経インターネットテクノロジー８月号、日本、日経ＢＰ社、１９９７年　７月２２日、第１号、第８０頁−第１０３頁に示されるように、ＷＷＷサーバが、アプリケーションプログラムであるＪａｖａアプレットをクライアントに提供すること、クライアントが、クライアント・パソコンに設けられたクライアントプログラムであるＷＷＷブラウザを利用して、前記アプリケーションプログラムを前記ＷＷＷサーバから通信ネットワークであるインターネットを介してダウンロード（本願発明の「転送」に相当する。）すること及びアプリケーションプログラムであるＪａｖａアプレットがクライアントプログラムであるＷＷＷブラウザ上で実行されるものであることは、周知である。
　したがって、引用刊行物１発明において、上記周知のように、記憶手段に、管理装置に設けられたクライアントプログラムに従って通信ネットワーク経由で前記管理装置に転送され且つ前記クライアントプログラム上で実行されるアプリケーションプログラムを格納することは、当業者が容易に想到し得ることである。
　
　
　そして、本願発明の作用効果も、引用刊行物１発明、引用刊行物２発明及び周知技術から当業者が予測できる範囲のものである。
　
（なお、平成１８年１０月５日付け手続補正により明細書の段落【００１７】に「通信インタフェース装置としてプロトコル変換を行うソケットサーバにＷＷＷサーバを組み込むことにより」と「このため、対象機器が追加変更されるたびに、対応する機器データを追加する、ＷＷＷサーバを追加する、通信プログラムを追加する必要がなくなる。」とを追加する補正をしているが、当該補正事項は、願書に最初に添付された明細書又は図面に記載されておらず、同明細書又は図面からみて明らかということはできない。
（なお、引用刊行物１発明では、データベースサーバーは、サーバーAに組み込まれているから、１つのサーバーに他のサーバーを組み込むことが記載されている。））
　
　
５．むすび
　
　以上のとおり、本願発明は、引用刊行物１発明、引用刊行物２発明及び周知技術に基づいて、当業者が容易に発明をすることができたものであるから、特許法第２９条２項の規定により特許を受けることができない。
　
　
　よって、結論のとおり審決する。