【事件の表示】
　平成　８年特許願第１５８２３４号「疎結合多重センタシステムのホスト選択方式」拒絶査定に対する審判事件［平成１０年　１月１６日出願公開、特開平１０−　１１３９６］について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
１．手続の経緯・本願発明
　本願は、平成８年６月１９日の出願であって、その請求項１に係る発明（以下、本願発明という。）は、平成１５年１月１７日付けの手続補正書によって補正された明細書及び図面の記載からみて、その特許請求の範囲の請求項１に記載された次の事項により特定されるものと認められる。
「通信処理装置およびファイル共用装置を共有する複数の疎結合のホストコンピュータで構成され広域通信網を介して複数の端末システムにオンラインサービスを提供する疎結合多重センタシステムのホスト選択方式において、
　前記通信処理装置は、
　前記疎結合多重センタシステムが提供するオンライン業務アプリケーションプログラムごとにそれぞれ固有の接続アドレスと、この接続アドレスにアクセスした通信情報を当該オンライン業務アプリケーションプログラムが動作しているホストコンピュータに振り分けるための対応関係を保持するアクセス管理テーブルと、前記アクセス管理テーブルに保持されている前記対応関係に基づいて、前記広域通信網から着信した通信情報を前記ホストコンピュータへ振り分ける振り分け手段とを備え、
　前記疎結合多重センタシステムを構成する各ホストコンピュータは、
　待機状態にあるオンライン業務アプリケーションプログラムを認識し対応する稼働状態のオンライン業務アプリケーションプログラムが動作しているホストコンピュータとの間で相互に監視し、稼働状態のオンライン業務アプリケーションプログラムに障害が発生したときに待機状態にあるオンライン業務アプリケーションプログラムを稼働状態に変更するホットスタンバイ監視手段と、前記オンライン業務アプリケーションプログラムが待機状態から稼働状態に切り替わったことを確認すると、前記アクセス管理テーブルの更新要求を行うネットワーク監視手段と、前記更新要求に基づいて、前記アクセス管理テーブルに保持されている前記対応関係を変更するＴセレクタ切替手段とを備えたこと
　を特徴とする疎結合多重センタシステムのホスト選択方式。」
　
２．引用例
　これに対して、当審の拒絶の理由に引用された特開昭６３−７０３６７号公報（昭和６３年３月３０日出願公開。以下、引用例１という。）には、複数のホスト計算機が一つの通信制御装置を介して相手端末や相手計算機システムと接続し、相手端末や相手計算機システムからの接続要求で指定された応用プログラム名により、複数のホスト計算機上のどこかに存在する応用プログラムを選択する方式に関して、図面とともに次の事項が記載されている。
（１）複数のホスト計算機が通信回線およびチャネルの少なくとも一方を通して接続される一つの通信制御装置を介して、端末や相手計算機システムとの通信を行うシステムにおいて、各ホスト計算機は、応用プログラム管理表と、応用プログラムの動作状態に連動して、前記応用プログラム管理表の内容を更新し、通信制御装置にも応用プログラムの状態を通知する応用プログラム管理手段・・・を備え、通信制御装置は、応用プログラム名の示す応用プログラムがどのホスト計算機で動作しているかを管理する応用プログラム名−ホスト計算機対応表と、応用プログラムの起動に応答して、前記応用プログラム管理手段からの要求により、前記応用プログラム名−ホスト計算機対応表へ応用プログラム名を登録する応用プログラム名登録手段と、・・・端末および相手計算機システムの少なくとも一方からの接続要求に応答して、本応用プログラム名−ホスト計算機対応表により、接続要求をどのホスト計算機に転送するかを決定するホスト計算機選択手段とを具備したことを特徴とする複数計算機上の応用プログラム選択制御方式。（特許請求の範囲）
（２）第１図を参照すると、本発明の一実施例は、２つのホスト計算機１と２と、通信制御装置３と、２つのホスト計算機１と２および通信制御装置３を接続するチャネル４と５と端末装置６１，６２，６３，・・・，６ｎと、通信制御装置３と端末装置６１，６２，６３・・・６ｎとを接続する通信回線７１，７２，７３，・・・，７ｎとを有している。（３頁右上欄１０行乃至１６行）
（３）ホスト計算機１内の応用プログラム管理手段１２は、応用プログラムの起動に応答して、・・・応用プログラム管理表１１に応用プログラム名を登録し、さらに応用プログラム名の登録を通信制御装置３に要求する。・・・応用プログラム管理表１１・・・は、応用プログラム毎に１エントリを形成し、各エントリの内容は応用プログラム名フィールド２０１、応用プログラム番号フィールド２０２、および応用プログラム状態フィールド２０３から構成されている。・・・応用プログラム管理手段１２・・・では、・・・空きのエントリの存在が判定されたら、・・・応用プログラム名とその応用プログラム番号とがこの応用プログラム管理表に登録され、初期状態が活性化処理中に変化する。その後、・・・通信制御装置に対して応用プログラムの登録が要求され、・・・その応答が待ち合わされる。（３頁左下欄１２行乃至４頁左上欄５行）
（４）通信制御装置３では、転送されてきた応用プログラム名が応用プログラム名登録手段３２により応用プログラム名−ホスト計算機対応表３１にホスト計算機１を識別する情報とともに格納される。・・・応用プログラム名−ホスト計算機対応表３１は応用プログラム名毎に１エントリを形成しており、各エントリは応用プログラム名フィールド４０１とホスト計算機番号フィールド４０２から構成されている。・・・応用プログラム名登録手段３２では、・・・空きのエントリが存在すると判定されたら、・・・応用プログラム名と転送元のホスト計算機の番号とがこの応用プログラム名−ホスト計算機対応表に登録され、・・・ホスト計算機に対して登録の完了が通知される。（４頁左上欄６行乃至右上欄１３行）
（５）ホスト計算機１内の応用プログラム管理手段１２では、・・・応用プログラム登録要求に対する応答を通信制御装置から受けると、・・・応答が登録完了か、拒否応答かが判定される。登録完了と判定されれば、・・・応用プログラム管理表の状態が活性中にされ、・・・応用プログラム番号で示される応用プログラムに通信開始要求の受理が通知される。（４頁右上欄１４行乃至左下欄３行）
　
　また、上記応用プログラム選択方式の従来例について、引用例１には、次の事項が記載されている。
（６）第１の方式では、相手端末または相手計算機システムからの接続要求の中にどのホスト計算機に接続要求を転送するのかを識別する情報を載せ、これにより通信制御装置が該当するホスト計算機を選択し、そのホスト計算機に接続要求を転送する。・・・まず、第１の方式では、相手端末または相手計算機システムが応用プログラムがどのホスト計算機で動作しているかを知っていなければならず、ホスト計算機を２重化して障害時に応用プログラムの存在するホスト計算機を変更するような運用形態では、何らかの手段により、相手端末または相手計算機システムに応用プログラムの動作しているホスト計算機の変わったことを通知しなければならない。（２頁左上欄１８行乃至右下欄１６行）
　
　上記摘記事項（２）に一実施例として記載された、２つのホスト計算機１と２と、通信制御装置３と、２つのホスト計算機１と２および通信制御装置３を接続するチャネル４と５からなるシステムは、上記摘記事項（６）に記載されたような２重化した運用を排除するものではないことを勘案すると、引用例１に記載された応用プログラム選択制御方式の複数のホスト計算機は、多重センタシステムを構成するものを含むと認められるので、引用例１には
「通信制御装置を共有する複数のホスト計算機で構成され通信回線を通して複数の端末または相手計算機システムと通信を行う多重センタシステムの複数ホスト計算機上の応用プログラム選択制御方式において、
　前記通信制御装置は、
　応用プログラム名の示す応用プログラムがどのホスト計算機で動作しているかを管理する応用プログラム名−ホスト計算機対応表と、端末および相手計算機システムの少なくとも一方からの接続要求に応答して、応用プログラム名−ホスト計算機対応表により、接続要求をどのホスト計算機に転送するかを決定するホスト計算機選択手段とを備え、
　前記多重センタシステムを構成する各ホスト計算機は、
　応用プログラムの起動に応答して、通信制御装置に応用プログラム名−ホスト計算機対応表への応用プログラムの登録を要求する応用プログラム管理手段とを備えたこと
　を特徴とする多重センタシステムの複数ホスト計算機上の応用プログラム選択制御方式」（以下、引用例１に記載された発明という。）が記載されていると認められる。
　同じく当審の拒絶の理由に引用された特公平７−６０３９８号公報（平成７年６月２８日出願公告。以下、引用例２という。）には、ＯＳＩシステムに接続されたフロントエンドプロセッサを備えた疎結合マルチプロセッサにおいて、予備系を常時サービス可能な状態で待機させておくホットスタンバイ方式を採用し、稼働系アプリケーションプログラムが稼働系業務を実行している稼働系ホストコンピュータに障害が発生すると、稼働系ホストコンピュータの中核ＯＳ、待機系ホストコンピュータの中核ＯＳおよび専用線経由で待機系ホストコンピュータへ他系障害が通知され、他系障害を通知された待機系ホストコンピュータは、フロントエンドプロセッサに稼働系自己Ｔセレクタを通知し、フロントエンドプロセッサは待機系ホストコンピュータの自己Ｔセレクタが稼働系Ｔセレクタであることを記憶し、それ以降、ＯＳＩシステムから稼働系Ｔセレクタを指定された着信通知を受信すると、それを待機系ホストコンピュータに振り分け、待機系ホストコンピュータ上で稼働系アプリケーションプログラムが稼働系業務を実行するものが記載されている。
　　
３．対比
　本願発明と引用例１に記載された発明を対比すると、引用例１に記載された発明の「通信制御装置」、「ホスト計算機」及び「端末または相手計算機システム」は、それぞれ本願発明の「通信処理装置」、「ホストコンピュータ」及び「端末システム」に相当し、引用例１に記載された発明の「複数ホスト計算機上の応用プログラム選択制御方式」は、応用プログラムの動作しているホスト計算機を選択しているから、本願発明の「ホスト選択方式」に相当する。
　また、引用例１に記載された発明において、応用プログラムが複数の端末または相手計算機システムと通信を行うことは、本願発明において、
複数の端末システムにオンラインサービスを提供することに対応し、引用例１に記載された発明の「応用プログラム」は、本願発明の「オンライン業務アプリケーションプログラム」に相当する。
　さらに、引用例１に記載された発明の「応用プログラム名」は、応用プログラムに固有なものであって、それを用いて応用プログラムへの接続がなされるものであるから、本願発明の「固有の接続アドレス」に該当し、したがって、引用例１に記載された発明の「応用プログラム名−ホスト計算機対応表」と「ホスト計算機選択手段」は、それぞれ本願発明の「アクセス管理テーブル」と「振り分け手段」に相当する。
　そして、本願発明において、オンライン業務アプリケーションプログラムが「待機状態から稼働状態に切り替わる」ことと、引用例１に記載された発明において、応用プログラムが「起動する」ことは、それぞれのプログラムがアクセス可能な状態になることで一致するから、本願発明の「ネットワーク監視手段」と引用例１に記載された発明の「応用プログラム管理手段」は、オンライン業務アプリケーションプログラムがアクセス可能な状態になったことを確認すると、前記アクセス管理テーブルの更新要求を行うテーブル更新要求手段である点で一致する。
　また、本願発明の「Ｔセレクタ切替手段」は、ネットワーク監視手段の更新要求に基づいて、前記アクセス管理テーブルに保持されている前記対応関係を変更するものであるとは定義されているが、Ｔセレクタ自体は、本願発明において、プログラムの固有の接続アドレスであるとの定義はなされていないことから、いわゆる「Ｔセレクタ」を切り替えるものとは認められず、さらに、前記定義における「前記アクセス管理テーブルに保持されている前記対応関係を変更する」は、発明の詳細な説明の段落１５の記載と技術常識から、「通信処理装置に要求を行うことにより、前記アクセス管理テーブルに保持されている前記対応関係を変更する」ことを意味すると認められるから、結局、「ネットワーク監視手段」からの「アクセス管理テーブルの更新要求」を単に中継しているものにすぎないから、本願発明の「ネットワーク監視手段」及び「Ｔセレクタ切替手段」と引用例１に記載された「応用プログラム管理手段」は、オンライン業務アプリケーションプログラムがアクセス可能な状態になったことを確認すると、前記アクセス管理テーブルの更新要求を行うテーブル更新要求手段である点で一致する。
　したがって、両者は、
「通信処理装置を共有する複数のホストコンピュータで構成され通信網を介して複数の端末システムにオンラインサービスを提供する多重センタシステムのホスト選択方式において、
　前記通信処理装置は、
　前記多重センタシステムが提供するオンライン業務アプリケーションプログラムごとにそれぞれ固有の接続アドレスと、この接続アドレスにアクセスした通信情報を当該オンライン業務アプリケーションプログラムが動作しているホストコンピュータに振り分けるための対応関係を保持するアクセス管理テーブルと、前記アクセス管理テーブルに保持されている前記対応関係に基づいて、前記通信網から着信した通信情報を前記ホストコンピュータへ振り分ける振り分け手段とを備え、
　前記多重センタシステムを構成する各ホストコンピュータは、
　前記オンライン業務アプリケーションプログラムがアクセス可能な状態に切り替わったことを確認すると、前記アクセス管理テーブルの更新要求を行うテーブル更新要求手段とを備えたこと
　を特徴とする多重センタシステムのホスト選択方式。」であることで一致し、以下の点で相違する。
（相違点１）
　本願発明の多重センタシステムは、疎結合多重センタシステムであり、ファイル共用装置を共有し、広域通信網を介して複数の端末システムと接続されたものであるのに対して、引用例１には、複数のホスト計算機が疎結合であること、ファイル共用装置を共有すること、および通信回線７１，７２，７３，・・・，７ｎが広域通信網を用いたものであることのいずれも明記されていない点。
（相違点２）
　本願発明においては、各ホストコンピュータは、待機状態にあるオンライン業務アプリケーションプログラムを認識し対応する稼働状態のオンライン業務アプリケーションプログラムが動作しているホストコンピュータとの間で相互に監視し、稼働状態のオンライン業務アプリケーションプログラムに障害が発生したときに待機状態にあるオンライン業務アプリケーションプログラムを稼働状態に変更するホットスタンバイ監視手段を備え、テーブル更新要求手段はネットワーク監視手段とＴセレクタ切替手段で構成され、ネットワーク監視手段がアクセス管理テーブルの更新要求を行うのは、オンライン業務アプリケーションプログラムが待機状態から稼働状態に切り替わったことを確認した場合であるのに対して、引用例１には、そもそもホットスタンバイについては何も記載されておらず、また、テーブル更新要求手段を要求を発する手段とその要求を中継する手段とに分割していない点。
　
４．当審の判断
　上記相違点について検討する。
（相違点１について）
　複数のホスト計算機間の結合を疎結合とすること、複数のホスト計算機がファイル共用装置を共有すること、及び通信回線として広域通信網を用いることは、いずれも周知であって、引用例１に記載された発明においても、それらの構成を採用することに何らかの困難な点があったとは認めることができないから、相違点１を格別のものと認めることはできない。
（相違点２について）
　引用例２に記載されているように、障害対策のためにホットスタンバイ方式を採用することは周知であり、引用例１に記載された発明においても、ある応用プログラムをあるホスト計算機上で動作させ、同じ応用プログラムを他のホスト計算機上でホットスタンバイさせることは、当業者が容易に推量可能であったと認められる。
　そして、ホットスタンバイ方式を採用したホスト計算機には、待機状態にあるオンライン業務アプリケーションプログラムを認識し対応する稼働状態のオンライン業務アプリケーションプログラムが動作しているホストコンピュータとの間で相互に監視し、稼働状態のオンライン業務アプリケーションプログラムに障害が発生したときに待機状態にあるオンライン業務アプリケーションプログラムを稼働状態に変更する何らかの手段が必要なことは明らかであり、オンライン業務アプリケーションプログラムが待機状態から稼働状態に切り替わったことを確認した場合には、アクセス管理テーブルの更新要求を行う必要のあることも明らかである。
　次に、アクセス管理テーブルの更新要求を行うにあたって、「Ｔセレクタ切替手段」を設け、「ネットワーク監視手段」からのテーブル更新要求を中継している点については、これらホストコンピュータ上の各手段の機能はソフトウェアにより実現されると認められ、ソフトウェアによりある機能を実現する場合にソフトウェアを細かい機能にモジュール分けすることは当業者の常套手段であるから、通信処理装置に直接更新要求を行う手段を設けることは設計的事項に属するものと認められる。
　以上のとおりであるから、相違点２についても、格別のものは認めることができない。
　
５．むすび
　したがって、本願発明は、引用例１、２に記載された発明に基いて、当業者が容易に発明をすることができたものと認められるから、特許法第２９条第２項の規定により特許を受けることができない。
　
　よって、結論のとおり審決する。