【事件の表示】
　平成　９年特許願第１０４９９７号「遠隔操作方法、ネットワークを介して端末から遠隔操作されるサーバ及びＨＴＭＬファイルを格納する記憶媒体」拒絶査定不服審判事件〔平成１０年１１月１３日出願公開、特開平１０−３０１８７４〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
１．手続の経緯
　本願は、平成９年４月２２日に特許出願され、拒絶理由通知がなされ、平成１３年７月１９日付けで意見書が提出されると共に明細書について手続補正がなされ、再度拒絶理由通知がなされ、拒絶査定がなされ、査定不服の審判請求がなされ、平成１４年４月１７日付けで明細書について手続補正がなされたものである。
２．本願発明は平成１４年４月１７日付けで手続補正された明細書の特許請求の範囲の請求項１〜９に記載されたとおりのものであるところ、その請求項１に記載された発明（以下、本願発明１という。）は次のとおりである。
「ネットワーク上に存在し、被遠隔操作用のソフトウエアと遠隔操作用のソフトウエアを有するサーバが保有する前記サーバのＧＵＩ（Ｇｒａｐｈｉｃａｌ　Ｕｓｅｒ　Ｉｎｔｅｒｆａｃｅ）資源を、入力装置を有する端末から遠隔操作する方法であって、
　（ａ）前記端末において特定されたサーバアクセス情報に基づいて、前記ネットワークを介して前記サーバにアクセスする段階と、
　（ｂ）前記サーバから前記遠隔操作用のソフトウエアを前記端末にダウンロードする段階と、
　（ｃ）前記ダウンロードした遠隔操作用のソフトウエアを起動し、前記被遠隔操作用のソフトウエアと前記遠隔操作用のソフトウエアとの通信接続を確立する段階と、
　（ｄ）前記ダウンロードした遠隔操作用のソフトウエアに基づいて、前記端末側から前記サーバ側へ前記端末の入力装置から発生する入力情報を送信する段階と、
　（ｅ）前記被遠隔操作用のソフトウエアが、前記端末側から送信された入力情報を受領し、その入力情報に基づいて、前記ＧＵＩ資源に描画命令を生成することを命令する段階と、
　（ｆ）前記ＧＵＩ資源が前記サーバのＧＵＩ画面を書替える段階と、
　（ｇ）前記描画命令を前記サーバ側から前記端末側へ送信する段階と、
　（ｈ）前記端末側で、前記描画命令を受領する段階と、
　（Ｉ）前記端末側で、前記サーバの書替えられたＧＵＩ画面と同じイメージを表示する段階と、
　を含む遠隔操作方法。」
３．引用文献に記載の事項
　原審の拒絶の査定の理由に引用された引用文献１（真島馨，”複数のマシンを遠隔操作できる３２ビット版がぞくぞく登場”，日経バイト，日経ＢＰ社，平成８年１１月２２日，第１５９号，ｐ．３３６−３４１）には、リモートコントロールソフトウエアにおいて、ホスト・コンピュータとゲスト・コンピュータの双方でコントロールプログラムを動かし、ホスト・コンピュータのウインドウをゲスト・コンピュータに表示し、ゲスト・コンピュータのキー操作によってホスト・コンピュータをリモートコントロールすることが記載されている。。
　原審の拒絶の査定の理由に引用された引用文献２（後藤新，”モバイルコンピューティングを加速させるリモートアクセス製品”，ＬＡＮ　ＴＩＭＥＳ，ソフトバンク株式会社，平成８年９月１日，第６巻，第９号，ｐ．１５４?１６０）には、リモートコントロールのソフトウェアアプリケーションは電話回線やＩＳＤＮ、ＬＡＮなどで接続されたパソコンのホスト側アプリケーションとリモートコントロール用ビューワとで構成され、ホストＰＣの画面をリモートＰＣの画面の中に表示させてリモートＰＣによってホストＰＣをリモートコントロールすることが記載されている。
　原審の拒絶の査定の理由に引用された引用文献３（高橋三雄，”ユーザサポートのための通信ソフト”，ｂｉｔ，共立出版株式会社，平成３年６月１日，第２３巻，第７号，ｐ．８５?８７）には、通信回線で接続された２台のコンピュータにそれぞれＣａｒｂｏｎＣｏｐｙというソフトウエアを導入し、被制御コンピュータでは、”Ｂｅ　ａ　Ｈｏｓｔ”のソフトウエアを作動させ、制御を行うコンピュータでは、”Ｖｉｓｉｔ”のソフトウエアを動作させ、被制御コンピュータの画面を制御を行うコンピュータの画面に表示させ、制御を行うコンピュータによって被制御コンピュータをリモートコントロールすることが記載されている。
　原審の拒絶の査定の理由に引用された引用文献４（森永輔，”ＷＷＷソフトをビジュアルに開発”，日経コンピュータ，日経ＢＰ社，平成９年１月２０日，第４０９号，ｐ．２２６?２４０）には次の事項が記載されている。
「一つ目のクライアント配布型は、ＬＡＮで接続したクライアント・パソコン上のブラウザにWWWサーバーからアプリケーションをダウンロードし、それをクライアント上で実行する形態だ。」（２２８頁右欄「保守が容易なクライアント配布型」１行目〜６行目及び２３０頁図３）
「従来のＣ／Ｓシステムは、ＬＡＮで接続したクライアント機とサーバー機の双方にアプリケーションをあらかじめインストールしておく必要があった。これに対し、クライアント配布型では、WWW技術を使うことでクライアント・アプリケーションへのこうしたインストール作業をなくせる。
　クライアント上では、プラグ・イン形式で提供される実行エンジンやＪａｖａ仮想マシンを使ってアプリケーションを実行する。いったん配布された後は、通常のＣ／Ｓシステムと同様に、クライアント・アプリケーションがサーバー・アプリケーションと連携して処理を進める。
　クライアント配布型を利用するメリットは、「クライアント・アプリケーションのメンテナンスにかかる作業負荷を大幅に軽減できる」」（２２９頁左欄５行目〜中欄３行目）
　原審の拒絶の査定の理由に引用された引用文献５（森側真一，”９７年イントラネット最前線”，日経オープンシステム増刊，日経ＢＰ社，平成９年２月１０日，ｐ９６−１０１）には次の事項が記載されている。
「Plug-inは、WWWブラウザ上で別プログラムを動作させるための技術。各開発ツール用の実行モジュールをPlug-inとして組み込み、送信してきたアプリケーションをWWWブラウザ上で動作させる。この場合、一度アプリケーションをダウンロードしてしまえば、その後の実行形態はこれまでのＣ／Ｓシステムとまったく同じだ。アプリケーションは基本的にクライアント側で動作する。」（９９頁左欄下から２行目〜中欄９行目）
「VisualInterDevなど新たなイントラネット用開発ツールは現状のアーキテクチャだと、パフォーマンスと操作性にやや問題を残す。これを解決するために分散オブジェクト環境を用いる動きがある。
　問題点は、ＤＢから新たなデータを取り出すたびに、ＨＴＭＬを再表示すること。実際に使ってみた感じとしては、時間的には一瞬だが、やや気になる。これを解決するには、クライアントのコンポーネントとサーバーのコンポーネントが直接連携する仕組みが必要になる。そこで分散オブジェクト環境の出番となる。
　ActiveＸ環境では、コンポーネント間の連携インタフェースＣＯＭ（ComponentObjectModel）をリモート間までに拡張するＤＣＯＭ（DistributedＣＯＭ）が、WindowsNT4.0で登場した。VisualInterDevなどのツールもこれに追随することは想像に難くない。ＤＣＯＭを利用すれば、クライアント・アプリケーションを一度ダウンロードした後はコンポーネント間で必要なデータだけをやり取りでき、ＨＴＭＬを再表示するようなオーバーヘッドもない。」（１０１頁左欄「分散オブジェクト環境で問題解決」の１行目〜中欄４行目）
４．対比・判断
　引用文献１〜３には「ネットワーク上に存在して被遠隔操作用のソフトウエアを有するホスト（本願発明１のサーバに相当する。）を入力装置を有するゲスト（本願発明１の端末に相当する。）から遠隔操作する方法において、ゲスト側で遠隔操作用のソフトウエアを起動し、被遠隔操作用のソフトウエアと遠隔操作用のソフトウエアとの通信接続を確立し、ゲスト側でホストの画面と同じイメージを表示して、ゲスト側からホストを遠隔操作する」ことが記載され、当業者に周知の発明（以下、周知発明という。）である。
　そして、上記周知発明は、「端末側でサーバの画面と同じイメージを表示して、端末側からサーバを遠隔操作する」のであるから、「端末側からサーバ側へ端末の入力装置から発生する入力情報を送信する段階と、被遠隔操作用のソフトウエアが、端末側から送信された入力情報を受領し、その入力情報に基づいて、ＧＵＩ資源に描画命令を生成することを命令する段階と、ＧＵＩ資源がサーバのＧＵＩ画面を書替える段階と、描画命令をサーバ側から端末側へ送信する段階と、端末側で、描画命令を受領する段階と」を含むことは、引用文献１〜３に明示して記載されていないが、明らかである。
　そこで、本願発明１と周知発明とを対比すると、両者は「ネットワーク上に存在して被遠隔操作用のソフトウエアを有するサーバを入力装置を有する端末から遠隔操作する方法において、遠隔操作用のソフトウエアを起動し、被遠隔操作用のソフトウエアと遠隔操作用のソフトウエアとの通信接続を確立する段階と、遠隔操作用のソフトウエアに基づいて、端末側からサーバ側へ端末の入力装置から発生する入力情報を送信する段階と、被遠隔操作用のソフトウエアが、端末側から送信された入力情報を受領し、その入力情報に基づいて、ＧＵＩ資源に描画命令を生成することを命令する段階と、ＧＵＩ資源がサーバのＧＵＩ画面を書替える段階と、描画命令をサーバ側から端末側へ送信する段階と、端末側で、描画命令を受領する段階と、端末側で、前記サーバの書替えられたＧＵＩ画面と同じイメージを表示する段階と、を含む遠隔操作方法」であるという点で一致し、次の点（以下、相違点という。）で相違している。
　相違点について
　本願発明１は「サーバが被遠隔操作用のソフトウエアと遠隔操作用のソフトウエアを保有し、端末において特定されたサーバアクセス情報に基づいて、ネットワークを介してサーバにアクセスし、サーバから遠隔操作用のソフトウエアを端末にダウンロードする」のに対して、周知発明は「端末が遠隔操作用のソフトウエアを保有する」点。
　そこで、上記相違点について以下に検討する。
　「サーバがサーバ用のソフトウェアと端末用のソフトウェアとを保有し、端末においてネットワークを介してサーバにアクセスし、サーバから端末用のソフトウエアを端末にダウンロードし、端末上で実行し、サーバ用のソフトウェアと連携して処理する」ことは引用文献４及び５に記載されているように当業者に周知の慣用技術である。
　そして、上記周知の慣用技術と上記周知発明とはネットワーク上のＣ／Ｓ（クライアント／サーバ）システムという技術分野を共通にするものである。
　してみると、上記周知発明に上記周知の慣用技術を適用して本願発明１の如く構成することは当業者であれば適宜になし得ることである。
５．むすび
　以上のとおり、本願発明１は、引用文献１〜５に記載の発明及び周知の慣用技術に基づいて当業者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。
　よって、結論のとおり審決する。