【事件の表示】
　平成　９年特許願第２６７３７０号「情報処理システム及び装置及び方法及び記憶媒体」拒絶査定不服審判事件〔平成１１年　４月２３日出願公開、特開平１１−１１０３１１〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
１．手続の経緯
　本願は平成９年９月３０日の出願であって、平成１７年８月１１日付けで拒絶査定がなされ、これに対して平成１７年９月１４日に拒絶査定に対する審判が請求されるとともに、同年１０月１３日付けで手続補正がなされたものである。
　
２．平成１７年１０月１３日付け手続補正について
［補正却下の決定の結論］
　平成１７年１０月１３日付け手続補正（以下「本件補正」という。）を却下する。
［理由］
　補正後の本願発明
　本件補正により、特許請求の範囲の請求項８は次のとおり補正された。
「【請求項８】
　能動的にクライアントへ情報を転送することができないプロトコルであって、ネットワークを介してクライアントから転送された要求に対して応答を返すプロトコルを用いて情報処理を行う情報処理装置であって、
　前記プロトコルを用いて前記クライアントから転送された提供対象の状態の通知要求に応じて、前記提供対象の状態の変更を監視して前記通知要求したクライアントに通知するためのスレッドを生成し、監視を開始する監視手段と、
　前記監視手段による前記提供対象の状態の変更が監視された場合、前記プロトコルを用いて前記変更した提供対象の状態に関する情報を前記クライアントに通知する通知手段と、
　を備えることを特徴とする情報処理装置。」
　
　上記補正は、請求項８に記載した発明を特定するために必要な事項である、「要求に対して応答を返すプロトコル」に関し、「能動的にクライアントへ情報を転送することができないプロトコルであって、」と限定し、生成されるスレッドに関し、「状態の変更を監視するためのスレッドを生成し」とあるのを「状態の変更を監視して前記通知要求したクライアントに通知するためのスレッドを生成し」と限定するものであって、特許法第１７条の２第４項第２号の特許請求の範囲の減縮を目的とするものに該当する。
　そこで、本件補正後の前記請求項８に記載された発明（以下、「本願補正発明」という。）が特許出願の際独立して特許を受けることができるものであるか（特許法第１７条の２第５項において準用する同法第１２６条第５項の規定に適合するか）について以下に検討する。
　
（１）引用刊行物
　原査定の拒絶の理由に引用された、本願の出願日前に頒布された刊行物「特開平８−１６３４２２号公報」（以下「引用刊行物１」という。）には、図面とともに以下の記載がある。
「【０００１】
【産業上の利用分野】本発明は、パン、チルト等の動作が制御可能なカメラ装置の制御装置に関するものであり、特にビデオ会議システムに用いて好適なカメラ装置の制御装置に関するものである。」（第２頁左欄）
　
「【０００４】本発明は、上記課題を解決し、システムを停止することなく、多数のユーザーが必要に応じてネットワーク上に接続されたカメラ装置に対して制御できるようになるカメラ装置の制御システムを提供することを目的とする。
【０００５】また、ビデオ会議への参加、離脱を容易にするカメラ装置の制御システムを提供することを目的とする。」（第２頁右欄）
　
「【００１２】図２は、本実施例を実行するためのソフトウエアの構成を示す図である。ソフトウェアの構成として以下のものがある。カメラ装置１０に接続されたワークステーション２０（厳密には記憶部２２）には、遠隔地等他の地点にカメラ装置１０によって得られた画像情報を送信するソフトとしてのビデオ会議ソフト４０、およびカメラ、制御を行うソフトとしてのカメラ制御サーバ４１が格納されている。また、このカメラ制御サーバ４１は、カメラ装置１０の起動時に後述するカメラ管理サーバ４５にカメラ装置１０がビデオ会議システム（ネットワーク）に接続されたことを登録させる。したがって、本実施例においては、カメラ管理サーバ４５を登録手段と見ることができる。
【００１３】一方、表示装置１６に接続されたワークステーション２０（厳密には記憶部２２）には、送信されてきた画像情報の表示を行うソフトとしてのビデオ会議ソフト４２、カメラの遠隔制御を行うソフトとしてのカメラ制御パネル４３が格納されている。また、このカメラ制御パネル４３は、カメラ管理サーバ４５で管理されているリスト（詳しくは後述する）に対して参照、記述、訂正等を行うこともできる。したがって、本実施例においては、カメラ制御パネル４３は、設定手段の一部と見ることができる。また、カメラ管理サーバ４５によって、カメラ装置１０との接続が許可されると、カメラ制御パネル４３は、カメラ管理サーバ４５を介することなく、カメラ制御信号をカメラ制御サーバ４１に送信する。
【００１４】なお、以上のソフト４１，４３をまとめて以下「カメラ制御クライアント」と称して説明する。
【００１５】さらに、すべてのカメラ装置１０のアクセスを管理するソフトとしてカメラ管理サーバ４５が用意される。このカメラ管理サーバ４５は、システムに接続されたいずれか一つのワークステーション２０に格納されていればよい。なお、カメラ管理サーバ４５をいずれのワークステーション２０にも格納しておき、ネットワーク上でビデオ会議システムを起動する際に、いずれか一つのワークステーション２０をサーバとして機能させてもよい。また、上記説明では、ワークステーション２０をカメラ装置１０および表示装置１６にそれぞれ接続されたものとして説明したが、通常は各ユーザーがそれぞれカメラ装置１０および表示装置１６を使用しているので、図１のブロック図に見られるように、カメラ装置１０および表示装置１６に対してワークステーション２０は１つである。したがって、ビデオ会議ソフト４０，４２は、一つのソフトとして構成される。
【００１６】次に、本実施例の構成において、主要な動作である、カメラ制御サーバ４１によるカメラ装置１０の遠隔制御、カメラ管理サーバ４５によるユーザーの管理、カメラ管理サーバ４５によるアクセス管理について以下に説明する。
【００１７】まず、ネットワーク３０に接続されたワークステーション２０から任意の他のワークステーション２０に接続されたカメラ装置１０を遠隔制御可能とするための実現手段について説明する。
【００１８】カメラ装置１０は、カメラ制御サーバ４１の存在するワークステーション２０からＲＳ２３２Ｃを介してカメラ装置１０に対して制御信号を送信することにより制御が可能であるので、カメラ制御サーバ４１上に存在するパン、チルト、ズーム等のカメラ制御関数を、ＲＰＣ（Remote Procedure Call ）を用いて遠隔起動することにより、この動作に対応するコマンド列を雲台部１４の不図示のＲＳ２３２Ｃポートに出力するような方法を実現すればよい。なお、この制御信号（コマンド列）は、パン、チルト等雲台１４の動作に関するものが雲台１４の不図示の制御部に送信され、ズーム等のカメラ部１２の動作に関するものがカメラ部１２の不図示の制御部に送信される。」（第３頁左欄〜右欄）
　
「【００２０】次に、カメラ管理サーバ４５によるユーザーの管理について説明する。
【００２１】カメラ管理サーバ４５は、ユーザーの管理のために、図４に示すようなカメラ状態リスト５０を用いる。このカメラ状態リスト５０には、カメラ制御サーバ４１に登録されたホスト名すなわちネットワーク３０上に接続されているカメラ装置１０を示す名称、およびそのカメラ装置１０の使用状況（空き、他のユーザーがアクセス中）が格納されており、さらに、カメラ装置１０の位置（ｘ，ｙ，ｚ）および姿勢（パンニング角度，チルティング角度）のデータも格納されている。上記ホスト名は、本実施例で説明するように、カメラ制御装置２にカメラ装置１０が１台しか接続されていないときには、ユーザー名と一致させることができるが、複数台接続されているときには、一致させるべきではない。このリスト５０に示す例では、host1 ，host2 ，host3 ，host4 で示されるカメラ装置１０が接続されており、host2 のカメラ装置１０をhost3 のユーザーが、またhost4 のカメラ装置１０をhost1 のユーザーが制御可能な状態になっており、host1 およびhost3 はいずれのユーザーにも操作されていない状態を示している。
【００２２】ここで、ユーザーの登録／削除は、カメラ制御サーバ４１の起動時に、起動したユーザー名をカメラ管理サーバ４５に告知し、カメラ状態リスト５０に登録する処理、およびカメラ制御サーバ４１の停止時に、カメラ状態リスト５０からユーザ名を削除する処理を、ＲＰＣを用いた図３（ｂ）に示す関数を使用することで実現する。図３（ｂ）に示す関数において、[struct host_name{〜}host_name] は、ホスト名を設定するために、カメラ制御パネル４３からカメラ制御サーバ４１に引き渡されるパラメータを設定するデータ型の宣言であり、[MAXNAME] によって設定される名前の文字数が規定される。[append_camera_list_1]はカメラ制御サーバ４１によって起動され、カメラ管理サーバ４５内で実行される関数である。この関数が実行されると、すなわち図５（ａ）に示すように、カメラ制御サーバ４１が起動される（ステップＰ１）と、カメラ管理サーバ４５は、カメラ状態リスト５０にホスト名を登録する（ステップＰ２）。このホスト名は、図３（ｂ）からわかるように、host_name 型で構成され、[host_name-name] で示される。以降、そのカメラ装置１０がカメラ制御サーバ４１を通じて制御可能であることを記憶する。また、カメラ制御サーバ４１の停止時には、図５（ｂ）に示すように、別のプログラムから[delete_host_list_1]を起動するカメラ制御サーバ４１内の関数を呼び出し（ステップＰＰ１）、その後カメラ制御サーバ４１によりホスト名を削除してプロセスの実行を終了すればよい（ステップＰＰ２）。したがって、本実施例においては、カメラ管理サーバ４５を設定手段と見ることもできる。」（第４頁左欄〜右欄）
　
「【００３６】本実施例においては、さらに、アクセス状態をユーザーに正確に伝達し、かつ、アクセス要求やアクセス許可状態の変更等の処理を容易に行う手段を実現するために、図１０に示すようなＧＵＩ（Graphical User Interface）を画面１６ａ上に表示している。このＧＵＩにより、ユーザーは現在のカメラ装置１０の登録状況や、使用状況および使用許可状況に関する情報を得ることが可能である。また、カメラ装置１０の切り替えが可能であり、さらにアクセス許可状態の変更が可能である。以下に、図１０に示すＧＵＩによる操作の一例について説明する。
【００３７】ユーザーは、カメラ状態リスト更新ボタン７３を押下することにより、これまで述べてきたＲＰＣを用いる方法と同様な方法により、カメラ管理サーバ４５から現在の各カメラのアクセス情報を得ることができる。ボタンの押下は、マウス２６を操作してカーソル１８を移動させ、所望のボタン上に位置させ、第１ボタン２６ａをクリックすることにより行われる。得た情報はリストウインドウ７２に表示される。また、ユーザーは、このリストウインドウ７２上に表示されたカメラ状態リスト５０上において、マウス２６あるいはキーボード２７を操作することで制御したいカメラ装置１０の設定を行うことができる。」（第５頁左欄〜右欄）
　
　これら引用刊行物１の記載から、引用刊行物１には以下の発明（以下、「引用発明」という。）が記載されているものと認められる。
「ネットワーク上に、カメラ制御クライアントと、カメラ管理サーバが格納されたワークステーションと、カメラ装置が接続されたワークステーションとが設けられ、
　カメラ制御クライアントでカメラ状態リスト更新ボタンが押下されると、カメラ管理サーバは現在の各カメラ装置のアクセス情報をカメラ制御クライアントに送信する、カメラ装置の制御システム。」
　
　同じく、原査定の拒絶の理由に引用された、本願の出願日前に頒布された刊行物「特開平４−７１０６７号公報」（以下「引用刊行物２」という。）には、図面とともに以下の記載がある。
「２．特許請求の範囲
　アプリケーションプログラムからデータベースシステムのデータファイルを参照するためのデータベース通信方式において、
　アプリケーションプログラム側からデータベースシステムに対するデータファイル参照のアクセス状態を記録する参照記録手段と、
　データベースシステム内のデータファイルの更新を監視し、更新が発生した場合にはアプリケーションプログラム側にデータファイルの更新状況を通知する変更通知手段と、
　を備えたデータベース通信方式。」（第１頁左下欄第４行〜下から第６行）
　
「［従来の技術］
　ワークステーション等のホストコンピュータ上で動作しているエディタや表計算などの複数のアプリケーションプログラムから、そのワークステーションのネットワークが接続したデータベースシステム（以下、単にデータベースと称する）にアクセスしてそのデータファイルのデータを参照あるいは該ファイルを更新するリレーショナルデータベースでは、アプリケーションプログラムからデータベースに格納されているデータを変更することはできたが、あるアプリケーションプログラムがデータベースから取り出したデータがその後他のアプリケーションプログラムによる更新操作によって変更された場合には、そのデータを参照したアプリケーションプログラムにデータベース側からそのことを積極的に通知することはしていない。
　ここで、アプリケーションプログラムとは、ユーザが作業する適用業務システムを意味し、情報処理ネットワーク上で動作するワークステーション等に設定したアプリケーションプログラム実行環境をいう。
　なお、この種の従来技術を開示したものとしては、特開平１−１２０６２１号公報を挙げることができる。」（第１頁右下欄第４〜第２頁左上欄第８行）
　
「［課題を解決するための手段］
　上記目的を達成するために、本発明は、アプリケーションプログラム（第１図の１）からデータベースシステム（第１図の２）のデータファイル（第１図の２１）を参照するためのデータベース通信方式において、
　アプリケーションプログラム側からデータベースシステムに対するデータファイル参照のアクセス状態を記録する参照記録手段（第１図の２５）と、
　データベースシステム内のデータファイルの更新を監視し、更新が発生した場合にはアプリケーションプログラム側にデータファイルの更新状況を通知する変更通知手段（第１図の２４）と、を備えたことを特徴とし、
　アプリケーションプログラム側からデータベースに対するデータ参照のアクセス状態を上記参照記録手段に記録し、変更通知手段によってデータベース内のデータの更新を監視し、更新が発生した場合にはアプリケーションプログラム側にデータの更新状況を通知する構成とした。」（第２頁右上欄末行〜左下欄末行）
　
（２）対比
　本願補正発明と引用発明を対比すると、
　引用発明の「カメラ制御クライアント」及び「カメラ装置」は、それぞれ、本願補正発明の「クライアント」及び「提供対象」に相当する。
　また、引用発明のカメラ管理サーバが格納された「ワークステーション」は、本願補正発明の、情報処理を行う「情報処理装置」に相当する。
　また、引用発明において、カメラ状態リスト更新ボタンが押下されると、情報処理装置（カメラ管理サーバが格納されたワークステーション）は現在の各提供対象（カメラ装置）のアクセス情報をクライアントに送信しており、引用発明の提供対象の「アクセス情報」は、本願補正発明の提供対象の「状態に関する情報」ということができ、引用発明においてカメラ状態リスト更新ボタンが押下されることにより、クライアントから情報処理装置に「提供対象の状態の通知要求が転送」されているということができる。
　
　したがって、両者は
「情報処理を行う情報処理装置であって、
　クライアントから転送された提供対象の状態の通知要求に応じて、前記提供対象の状態に関する情報を前記クライアントに通知する通知手段と、
　を備えることを特徴とする情報処理装置。」の点で一致し、以下の点で相違している。
　
相違点１
　本願補正発明の情報処理装置は、能動的にクライアントへ情報を転送することができないプロトコルであって、ネットワークを介してクライアントから転送された要求に対して応答を返すプロトコルを用いて情報処理を行い、前記プロトコルを用いてクライアントから監視手段に提供対象の状態の通知要求がなされ、通知手段により提供対象の状態に関する情報がクライアントに通知されるのに対し、
、引用発明の情報処理装置はネットワークを介してクライアントから転送された要求に対して応答を返しているが、通信に使用されるプロトコルがどのようなものであるかについては記載がない点。
　
相違点２
　本願補正発明は、クライアントから転送された提供対象の状態の通知要求に応じて、前記提供対象の状態の変更を監視して前記通知要求したクライアントに通知するためのスレッドを生成し、監視を開始する監視手段を有しているのに対し、引用発明は、クライアントから転送された提供対象の状態の通知要求に応じて、通知手段がクライアントに通知を行っているが、引用発明には監視手段について記載がなく、また、本願補正発明の通知手段は、監視手段による提供対象の状態の変更が監視された場合、前記変更した提供対象の状態に関する情報を前記クライアントに通知しているのに対し、引用発明の通知手段は、提供対象の状態に関する情報を前記クライアントに通知しているが、監視手段による前記提供対象の状態の変更が監視された場合、変更した提供対象の状態を通知するものではない点。
　
（３）当審の判断
　以下、上記相違点について検討する。
相違点１について
　ネットワークを介してクライアントと情報処理装置が通信を行うに際し、ＨＴＴＰ等の能動的にクライアントへ情報を転送することができないプロトコルであって、ネットワークを介してクライアントから転送された要求に対して応答を返すプロトコルを使用することは周知であって、引用発明において当該周知技術を適用して本願補正発明のように構成することは当業者が適宜になし得ることである。
　
相違点２について
　一般に所定の要求に応じて、当該要求を処理するために所定のスレッドを生成することは周知である。また、状態を監視し、状態が変化した場合にネットワークを介して情報の送信を行うことも、引用刊行物２、特開平５−６３８５０号公報（【請求項１】、段落【０００５】〜【０００８】、【００１２】、図２には、通信状態の問い合わせメッセージを保持し、通信状態が変化した時（通信状態が監視されているということができる。）に当該変化に対応する端末装置からの問い合わせメッセージが保持されていると変化した通信状態を端末装置に通知することが記載されている。）、拒絶査定において周知文献として引用された、「井戸譲治外３名著、周期・非周期データを統合する実時間データサーバ、情報処理学会研究報告，日本，社団法人情報処理学会，１９９５年７月２０日，第９５巻　第６５号、第２９５−３０２頁」（マルチプロセス・マルチスレッド構成のサーバによるプラント等の監視システムに関し、定められたイベント（状態変化）が起こった時にデータ転送を行うこと（事象駆動転送）により、プラントの状態変化を検出し上位システムに通知すること（第２９７頁右欄）、が記載されている。）に記載されているように周知である。
　そして、これらの周知技術を引用発明に適用して、引用発明の監視手段を、クライアントから転送された提供対象の状態の通知要求に応じて、前記提供対象の状態の変更を監視して前記通知要求したクライアントに通知するためのスレッドを生成するように構成し、それに伴い、引用発明の通知手段を監視手段による前記提供対象の状態の変更が監視された場合に前記変更した提供対象の状態に関する情報を前記クライアントに通知するようにして本願補正発明のように構成することは当業者が容易に想到し得ることである。
　
　そして、本願補正発明のように構成したことによる効果も引用発明及び周知技術から予測できる程度のものである。
　
　したがって、本願補正発明（請求項８に係る発明）は、引用発明及び周知技術に基づいて当業者が容易に発明をすることができたものである。
　
（４）むすび
　以上のとおりであるから、本件補正は、平成１８年法律第５５号改正附則第３条第１項によりなお従前の例によるとされる同法による改正前の特許法第１７条の２第５項において準用する同法第１２６条第５項の規定に違反するので、同法第１５９条第１項において読み替えて準用する同法第５３条第１項の規定により却下すべきものである。
　
３．本願発明について
　平成１７年１０月１３日付け手続補正は上記のとおり却下されたので、本願の請求項８に係る発明（以下、「本願発明」という。）は、平成１７年７月１９日付け手続補正書の特許請求の範囲の請求項８に記載された事項により特定される、以下のとおりのものである。
「【請求項８】
　ネットワークを介してクライアントから転送された要求に対して応答を返すプロトコルを用いて情報処理を行う情報処理装置であって、
　前記プロトコルを用いて前記クライアントから転送された提供対象の状態の通知要求に応じて、前記提供対象の状態の変更を監視するためのスレッドを生成し、監視を開始する監視手段と、
　前記監視手段による前記提供対象の状態の変更が監視された場合、前記プロトコルを用いて前記変更した提供対象の状態に関する情報を前記クライアントに通知する通知手段と、
　を備えることを特徴とする情報処理装置。」
　
（１）引用刊行物
　原査定の拒絶の理由に引用された引用刊行物及びその記載事項は、前記「２．（１）」に記載したとおりである。
　
（２）対比・判断
　本願発明は、前記２．で検討した本願補正発明から、「要求に対して応答を返すプロトコル」に関し、「能動的にクライアントへ情報を転送することができないプロトコルであって、」と限定し、生成されるスレッドに関し、「状態の変更を監視するためのスレッドを生成し」とあるのを「状態の変更を監視して前記通知要求したクライアントに通知するためのスレッドを生成し」とする限定を削除したものである。
　そうすると、本願発明の構成要件を全て含みさらに限定を付したものに相当する本願補正発明が、前記「２．（３）」に記載したとおり、引用発明及び周知技術に基づいて、当業者が容易に発明をすることができたものであるから、本願発明も、同様の理由により、引用発明及び周知技術に基づいて、当業者が容易に発明をすることができたものである。
　
（３）むすび
　以上のとおり、本願発明（請求項８に係る発明）は、引用発明及び周知技術に基づいて当業者が容易に発明をすることができたものである。
　したがって、本願はその余の請求項について論及するまでもなく、特許法第２９条第２項の規定により特許を受けることができない。
　
　よって、結論のとおり審決する。