【事件の表示】
　特願２００３−２９７４１７「サーバ・グループ間で操作を調整する方法」拒絶査定不服審判事件〔平成１６年　３月１１日出願公開、特開２００４−　７８９６７〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
第１．手続の経緯  
　本願は、平成１０年５月１日（パリ条約による優先権主張１９９７年５月８日、米国）に出願した特願平１０−１２２３９５号の一部を平成１５年８月２１日に新たな特許出願としたものであって、平成１７年１２月１６日付けで拒絶理由通知がなされ、平成１８年３月１日付けで手続補正がなされ、同年４月２４日付けで最後の拒絶理由通知がなされ、同年７月１２日付けで手続補正がなされたが、同年８月１０日付けで前記平成１８年７月１２日付け手続補正を補正却下するとともに、拒絶査定がなされ、これに対し、同年１１月１４日に審判請求がなされるとともに、同日付けで手続補正がなされたものである。そして、平成１９年１月１０日付けで審査官から前置報告がなされ、平成２０年１１月２５日付けで当審より審尋がなされ、平成２１年２月１６日付けで回答書が提出されたものである。
　  
第２．補正却下の決定
［補正却下の決定の結論］
　平成１８年１１月１４日付けの手続補正を却下する。
　
［理由］
１．補正の内容
　平成１８年１１月１４日付けの手続補正（以下、「本件補正」という。）の内容は、平成１８年３月１日付けの手続補正により補正された特許請求の範囲の記載
「【請求項１】
　１つ以上の参加サーバ・コンピュータ及び１つ以上のコントローラ・サーバ・コンピュータを含むサーバ・グループを有するクライアント／サーバ環境にて、前記サーバ・グループの前記サーバ・コンピュータ間でクライアント認証の操作を調整する方法であって、各参加サーバ・コンピュータが少なくとも１つのコントローラ・サーバ・コンピュータと通信でき、クライアント・コンピュータと前記少なくとも１つの前記サーバ・コンピュータとの間の通信において、クライアント・コンピュータと前記少なくとも１つの前記サーバ・コンピュータとの間で状態情報を受け渡すことについて制限されたまたは未定義の手順をもつプロトコルを使用し、
　前記方法が、
　クライアント・コンピュータが、認証を要求する参加サーバ・コンピュータに第１操作のリクエストを送信するステップと、
　クライアント・コンピュータが、前記認証を要求する参加サーバ・コンピュータにクライアント認証情報を提供するステップと、
　前記参加サーバ・コンピュータが前記クライアント認証情報を前記コントローラ・サーバ・コンピュータに確認するステップであって、前記コントローラ・サーバ・コンピュータが、前記クライアント・コンピュータによって前記参加サーバ・コンピュータに提供された前記クライアント認証情報を確認するステップと、
　前記コントローラ・サーバ・コンピュータが、セッションＩＤを生成するステップと、
　前記コントローラ・サーバ・コンピュータが、前記生成されたセッションＩＤを維持するステップと、
　前記クライアント・コンピュータが、認証を要求するサーバ・コンピュータの１つに第２操作のリクエストを送信するステップと、
　前記サーバ・コンピュータの１つが、前記クライアント・コンピュータを認証するために、前記維持されたセッションＩＤを使用して、前記クライアント・コンピュータの認証をするステップと、
　を含む、方法。
　　【請求項２】
　１つ以上の参加サーバ・コンピュータ及び１つ以上のコントローラ・サーバ・コンピュータを含むサーバ・グループを有するクライアント／サーバ環境にて、前記サーバ・グループの前記サーバ・コンピュータ間でクライアント認証の操作を調整する方法であって、各参加サーバ・コンピュータが少なくとも１つのコントローラ・サーバ・コンピュータと通信でき、クライアント・コンピュータと前記少なくとも１つの前記サーバ・コンピュータとの間の通信において、クライアント・コンピュータと前記少なくとも１つの前記サーバ・コンピュータとの間で状態情報を受け渡すことについて制限されたまたは未定義の手順をもつプロトコルを使用し、
　前記方法が、
　クライアント・コンピュータが、認証を要求するコントローラ・サーバ・コンピュータに第１操作のリクエストを送信するステップと、
　クライアント・コンピュータが、前記認証を要求するコントローラ・サーバ・コンピュータにクライアント認証情報を提供するステップと、
　前記コントローラ・サーバ・コンピュータが前記クライアント認証情報を確認するステップと、
　前記コントローラ・サーバ・コンピュータが、セッションＩＤを生成するステップと、
　前記コントローラ・サーバ・コンピュータが、前記生成されたセッションＩＤを維持するステップと、
　前記クライアント・コンピュータが、認証を要求するサーバ・コンピュータの１つに第２操作のリクエストを送信するステップと、
　前記サーバ・コンピュータの１つが、前記クライアント・コンピュータを認証するために、前記維持されたセッションＩＤを使用して、前記クライアント・コンピュータの認証をするステップと、
　を含む、方法。
　　【請求項３】
　前記クライアント・コンピュータが少なくとも１つのサーバ・コンピュータからプログラムを受け取って、該受け取ったプログラムを実行し、前記クライアント・コンピュータが前記サーバ・グループの少なくともいくつかの機能を実行するステップさらに含む、請求項１又は２に記載の方法。
　　【請求項４】
　前記セッションＩＤが複数の前記コントローラ・サーバ・コンピュータに分散される、請求項３に記載の方法。
　　【請求項５】
　前記クライアント認証情報がユーザＩＤ及びパスワードである、請求項１〜３のいずれか一項に記載の方法。
　　【請求項６】
　前記セッションＩＤから、ユーザＩＤを計算することが可能である、請求項５に記載の方法。
　　【請求項７】
　前記維持されたセッションＩＤを使用して、前記クライアント・コンピュータの認証をするステップにおいて、前記ユーザＩＤをさらに使用する、請求項６に記載の方法。
　　【請求項８】
　前記セッションＩＤの存続期間が制限される、請求項１〜７のいずれか一項に記載の方法に記載の方法。」（以下、この特許請求の範囲に記載された請求項を「補正前の請求項」という。）を、
　
「【請求項１】
　１つ以上の参加サーバ・コンピュータ及び１つ以上のコントローラ・サーバ・コンピュータを含むサーバ・グループを有するクライアント／サーバ環境にて、前記サーバ・グループの前記サーバ・コンピュータ間でクライアント認証の操作を調整する方法であって、各参加サーバ・コンピュータが少なくとも１つのコントローラ・サーバ・コンピュータと通信でき、クライアント・コンピュータと前記少なくとも１つの前記サーバ・コンピュータとの間の通信において、クライアント・コンピュータと前記少なくとも１つの前記サーバ・コンピュータとの間で状態情報を受け渡すことについて制限されたまたは未定義の手順をもつプロトコルを使用し、
　前記方法が、
　クライアント・コンピュータが、認証を要求する参加サーバ・コンピュータに第１操作のリクエストを送信するステップと、
　クライアント・コンピュータが、前記認証を要求する参加サーバ・コンピュータにユーザＩＤ及びパスワードを含むクライアント認証情報を提供するステップと、
　前記参加サーバ・コンピュータが前記クライアント認証情報を前記コントローラ・サーバ・コンピュータに確認するステップであって、前記コントローラ・サーバ・コンピュータが、前記クライアント・コンピュータによって前記参加サーバ・コンピュータに提供された前記クライアント認証情報を確認するステップと、
　前記コントローラ・サーバ・コンピュータが、クライアント・コンピュータを認証するために用いられるセッションＩＤを生成するステップであって、前記セッションＩＤは、前記ユーザＩＤ及び前記クライアント・コンピュータによりアクセスされた参加サーバ・コンピュータを表すため情報をさらに含む、前記生成するステップと、
　前記コントローラ・サーバ・コンピュータが、前記生成されたセッションＩＤを維持するステップと、
　前記クライアント・コンピュータが、認証を要求するサーバ・コンピュータの１つに第２操作のリクエストを送信するステップと、
　前記サーバ・コンピュータの１つが、前記クライアント・コンピュータを認証するために、前記維持されたセッションＩＤを使用して、前記クライアント・コンピュータの認証をするステップと、
　を含む、方法。
　　【請求項２】
　１つ以上の参加サーバ・コンピュータ及び１つ以上のコントローラ・サーバ・コンピュータを含むサーバ・グループを有するクライアント／サーバ環境にて、前記サーバ・グループの前記サーバ・コンピュータ間でクライアント認証の操作を調整する方法であって、各参加サーバ・コンピュータが少なくとも１つのコントローラ・サーバ・コンピュータと通信でき、クライアント・コンピュータと前記少なくとも１つの前記サーバ・コンピュータとの間の通信において、クライアント・コンピュータと前記少なくとも１つの前記サーバ・コンピュータとの間で状態情報を受け渡すことについて制限されたまたは未定義の手順をもつプロトコルを使用し、
　前記方法が、
　クライアント・コンピュータが、認証を要求するコントローラ・サーバ・コンピュータに第１操作のリクエストを送信するステップと、
　クライアント・コンピュータが、前記認証を要求するコントローラ・サーバ・コンピュータにユーザＩＤ及びパスワードを含むクライアント認証情報を提供するステップと、
　前記コントローラ・サーバ・コンピュータが前記クライアント認証情報を確認するステップと、
　前記コントローラ・サーバ・コンピュータが、クライアント・コンピュータを認証するために用いられるセッションＩＤを生成するステップと、
　前記コントローラ・サーバ・コンピュータが、前記生成されたセッションＩＤを維持するステップであって、前記セッションＩＤは、前記ユーザＩＤ及び前記クライアント・コンピュータによりアクセスされた参加サーバ・コンピュータを表すため情報をさらに含む、前記維持するステップと、
　前記クライアント・コンピュータが、認証を要求するサーバ・コンピュータの１つに第２操作のリクエストを送信するステップと、
　前記サーバ・コンピュータの１つが、前記クライアント・コンピュータを認証するために、前記維持されたセッションＩＤを使用して、前記クライアント・コンピュータの認証をするステップと、
　を含む、方法。
　　【請求項３】
　前記セッションＩＤの存続期間が制限される、請求項１又は２に記載の方法。」（以下、この特許請求の範囲に記載された請求項を「補正後の請求項」という。）
　に補正するものである。
　
２．補正の適否 
（１）補正の適否（特許法第１７条の２第３項に規定する要件についての検討）
　補正後の請求項１〜請求項３は、その記載からして、それぞれ少なくとも次の事項（ア）を含んでいる。
　 
（ア）コントローラ・サーバ・コンピュータの生成するセッションＩＤは、前記ユーザＩＤ及び前記クライアント・コンピュータによりアクセスされた参加サーバ・コンピュータを表すため情報をさらに含むこと。
　
　（ア）について検討する。
　願書に最初に添付した明細書の発明の詳細な説明（注意：下線は当審で付与したもの。）には、
「【００４２】
　有効なユーザＩＤ４０１及びパスワードがステップ２０７で入力された場合、コントローラはステップ２０８でセッションＩＤ４０２を生成する。セッションＩＤは、会話中にクライアントを認証するために用いられる。
セッションＩＤは、悪意あるユーザがセッションＩＤを類推しにくいように、充分に大きいキー・スペースからランダムに選択
セッションＩＤをデータベースに格納
「【００４３】
　ステップ２０８で、クライアントからコンタクトされたサーバは、会話でユーザＩＤ４０１及び
セッションＩＤ４０２を状態変数として保存
「【００４４】
　ステップ２０８でサーバはまた
そのＩＤをアクセス・ノード状態変数４０３にエンコード
アクセス・ノード状態変数４０３は
アクセスされた参加サーバを表す１つ以上の状態変数で構成
複数の変数を使用してより詳細な情報を表す
「【００４５】
　クライアントを認証するためにコントローラがそのデータベースに格納する状態情報と、会話で保存される状態情報は必ずしも同一ではない。他より若干多いかまたは少ない状態変数が格納されることもある。しかしそれでも、それぞれに格納される少なくともいくつかの変数は同じである。例えば好適な実施例で、
ユーザＩＤ及びセッションＩＤの変数は両方ともコントローラのデータベースに格納され、会話で保存
　
　よって、（ア）に記載された事項は、出願当初の明細書又は図面に記載されておらず、かつ、その記載から自明なものでもない。
　
　したがって、補正後の請求項１〜請求項３に記載された（ア）の事項は、出願当初の明細書又は図面に記載されておらず、かつ、その記載から自明なものでもないから、上記事項を追加する本件補正は、出願当初の明細書又は図面に記載した範囲内でしたものではないので、特許法第１７条の２第３項の規定に違反するものである。
　
３．結語
　以上のとおり、本件補正は、願書に最初に添付された明細書、特許請求の範囲又は図面に記載した範囲内にしたものでなく、平成１４年法律第２４号改正附則第３条第１項によりなお従前の例によるとされる同法による改正前の特許法第１７条の２第３項の規定に違反するので、同法第１５９条第１項において読み替えて準用する同法第５３条第１項の規定により却下すべきものである。 
　
第３．本願発明について
１．本願発明
　平成１８年１１月１４日付けの手続補正は上記のとおり却下されたので、本願の請求項１に係る発明（以下、「本願発明」という。）は、平成１８年３月１日付けの手続補正により補正された特許請求の範囲の請求項１に記載された事項により特定される、以下のとおりのものである。
　 
「１つ以上の参加サーバ・コンピュータ及び１つ以上のコントローラ・サーバ・コンピュータを含むサーバ・グループを有するクライアント／サーバ環境にて、前記サーバ・グループの前記サーバ・コンピュータ間でクライアント認証の操作を調整する方法であって、各参加サーバ・コンピュータが少なくとも１つのコントローラ・サーバ・コンピュータと通信でき、クライアント・コンピュータと前記少なくとも１つの前記サーバ・コンピュータとの間の通信において、クライアント・コンピュータと前記少なくとも１つの前記サーバ・コンピュータとの間で状態情報を受け渡すことについて制限されたまたは未定義の手順をもつプロトコルを使用し、
　前記方法が、
　クライアント・コンピュータが、認証を要求する参加サーバ・コンピュータに第１操作のリクエストを送信するステップと、
　クライアント・コンピュータが、前記認証を要求する参加サーバ・コンピュータにクライアント認証情報を提供するステップと、
　前記参加サーバ・コンピュータが前記クライアント認証情報を前記コントローラ・サーバ・コンピュータに確認するステップであって、前記コントローラ・サーバ・コンピュータが、前記クライアント・コンピュータによって前記参加サーバ・コンピュータに提供された前記クライアント認証情報を確認するステップと、
　前記コントローラ・サーバ・コンピュータが、セッションＩＤを生成するステップと、
　前記コントローラ・サーバ・コンピュータが、前記生成されたセッションＩＤを維持するステップと、
　前記クライアント・コンピュータが、認証を要求するサーバ・コンピュータの１つに第２操作のリクエストを送信するステップと、
　前記サーバ・コンピュータの１つが、前記クライアント・コンピュータを認証するために、前記維持されたセッションＩＤを使用して、前記クライアント・コンピュータの認証をするステップと、
　を含む、方法。」
　
２．引用発明
　原査定の拒絶の理由に引用された特開平８−２４９２５３号公報（以下、「引用文献」という。）には、図面とともに次の事項が記載されている。（備考：下線は当審で便宜上付与したものである。）
　
（ア）「【０００２】　・・・（中略）・・・　WWWは，HTML(HyperText Markup Language)と呼ばれる記述言語で記述された情報をサーバが保持し，クライアントはURL(Universal Resourece Locator)と呼ばれるリソースの場所（情報のありか）を示す識別子を頼りに，サーバから情報をリトリーブし，ユーザに呈示するものである。WWWでは，これまでのテキスト情報ばかりでなく，サーバ上にある画像や音声の情報に簡単にアクセスできる。そのため，企業や大学のピーアール，オンラインショッピング，電子図書館などに利用され，多くの利用者を集める結果となった。
【０００３】このWWW では、サーバが保持するデータ又はサービスがある特定のユーザだけにしかアクセスできないように制限を設ける必要がある場合は、ユーザＩＤとパスワードを用いて特定ユーザかどうかを認証するように構成している。またWWW ではクライアントからサーバへのアクセス要求が行われる度にコネクションが確立し、アクセス終了時点（先のアクセス要求に対する回答が返ってきた段階）でコネクションが切れるように構成されている。・・・（中略）・・・
【０００４】・・・（中略）・・・　しかしWWW ではあるアクセス要求に対する応答がなされる度にクライアント─サーバ間のコネクションが解消されるので、アクセス要求の度にクライアントからサーバに対してＩＤとパスワードとを送出し、認証を行う必要がある。
・・・（中略）・・・
【０００９】特に上記のWWW のように、クライアントが実行する
１回のセッション
で複数回のアクセス要求がある
　
（イ）「【００１９】このように本発明ではアクセス要求装置が実行するセッション中に行われる最初のアクセス要求の時のみ正当なユーザ認証情報を送受信し、その後のアクセス要求時には実行中のセッションにのみ有効なセッション認証情報を送受信するようにしたので、正当なユーザ認証情報が盗まれる機会を少なくなり、ユーザ認証情報の悪用の危険性が減少する。
　・・・（中略）・・・
【００２１】
【実施例】以下、図面を参照して本発明の実施例を説明する。図２は以下説明する本発明の各実施例が適用されるクライアント─サーバシステムの構成を示すブロック図である。図中、１はクライアント（アクセス要求装置）、２はサーバ（アクセス応答装置）である。複数のクライアント１と複数のサーバが３のネットワークに接続されている。
【００２２】また本実施例においては、クライアント１が各種のデータベースを検索したり、各種のサービスを受けることができるよう、複数のサーバ２が設けられている。例えばサーバ２─１は複数のクライアントがアクセスするデータベースを管理するために設けられたものであり、ＩＤ／パスワードデータベース４とセッションＩＤ／パスワードデータベース５と、
クライアントがアクセスする対象である本来のデータが格納されるデータベース
【００２３】ＩＤ／パスワードデータベース４は各ユーザに対応して設けられたＩＤとパスワードとの対応を登録しておくテーブルである。このデータベースには予めクライアントからＩＤとパスワードとを登録する処理が行われ、以後サーバ側ではクライアントから送られる
ＩＤとパスワードとを用いてユーザ認証処理を行う
【００２４】なお本実施例では
ＩＤ／パスワードデータベース４とセッションＩＤ／パスワードデータベース５は独立して設けているが、これを纏めて１つのデータベース
　
（ウ）「【００２８】このようなクライアント─サーバシステムの認証処理について、以下の実施例１〜実施例３により更に詳細に説明する。
〔実施例１〕本発明の実施例１の動作を、図３を用いて説明する。この図３では、データベース６を有するサーバ２─１をアクセスする例について説明する。（この説明単に「サーバ」と表記した場合は、サーバ２─１を示す。）
サーバは最初クライアントのアクセス要求の状態にある(200) 。この状態からサーバが
クライアントからのアクセス要求
【００２９】クライアントではユーザにＩＤ／パスワードを入力を求め(101) 、入力された
ＩＤ／パスワードをデータ要求と共にをサーバに対して送る
ＩＤ／パスワードの正当性をチェック
セッションＩＤ／パスワードを生成
セッションＩＤ／パスワードデータベース５に登録
【００３０】　・・・（中略）・・・　以後クライアントは現在実行中のセッションが終了するまで、
該セッションに係わるアクセス要求には、下記の通り全てセッションＩＤ／パスワードを付与
【００３１】
クライアントがデータ要求を行なう
セッションＩＤ／パスワードが正しいかどうかチェック
【００３２】さらに実行中のセッションの終了までに、該セッションに関してデータの要求がある場合、クライアントは上記(120) 〜(132) の処理，サーバは(220) 〜(230) の処理を繰り返す。即ちクライアントは先にサーバが発行したセッションＩＤ／パスワードをデータ要求の度に送出し、
サーバはこのセッションＩＤ／パスワードを用いて認証処理を行う
　
　ここで、（イ）の段落【００２２】における記載「また本実施例においては、クライアント１が各種のデータベースを検索したり、各種のサービスを受けることができるよう、複数のサーバ２が設けられている。例えばサーバ２─１は複数のクライアントがアクセスするデータベースを管理するために設けられたものであり、ＩＤ／パスワードデータベース４とセッションＩＤ／パスワードデータベース５と、クライアントがアクセスする対象である本来のデータが格納されるデータベース６とを有する。」、段落【００２３】における記載「ＩＤ／パスワードデータベース４は各ユーザに対応して設けられたＩＤとパスワードとの対応を登録しておくテーブルである。このデータベースには予めクライアントからＩＤとパスワードとを登録する処理が行われ、以後サーバ側ではクライアントから送られるＩＤとパスワードとを用いてユーザ認証処理を行う。」及び段落【００２４】における記載「ＩＤ／パスワードデータベース４とセッションＩＤ／パスワードデータベース５は独立して設けているが、これを纏めて１つのデータベースにして、ユーザＩＤと該ユーザＩＤのクライアントが実行しているセッションに付与されたセッションＩＤ／パスワードとを対応づけるように構成しても良い。」、並びに（ウ）の段落【００３２】における記載「即ちクライアントは先にサーバが発行したセッションＩＤ／パスワードをデータ要求の度に送出し、サーバはこのセッションＩＤ／パスワードを用いて認証処理を行う。」からすると、引用文献には、クライアントがアクセスするデータベースと、クライアント認証のためのＩＤ／パスワードデータベース及びセッションＩＤ／パスワードデータベースを１つのデータベースにしたもの（以下、「ＩＤ／パスワードデータベース及びセッションＩＤ／パスワードデータベースから構成される認証用データベース」と言う）を備え、前記認証用データベースを用いてクライアントを認証する手段（以下、「認証手段」と言う）とを有するサーバを有するクライアント／サーバ環境が記載されていると解される。
　また、（イ）の段落【００１９】の記載から、引用文献には、クライアント認証の操作を調整する方法が記載されていると解される。
　なお、（ア）の段落【０００２】における記載からすると、引用文献記載のクライアントとサーバとの間の通信において、クライアントと前記サーバとの間でＷＷＷにおいて使用されているプロトコル（すなわち、ＨＴＴＰプロトコル）を使用すると解される。
　
　（ウ）の段落【００２８】における記載「サーバは最初クライアントのアクセス要求の状態にある(200) 。この状態からサーバがクライアントからのアクセス要求(100があると、サーバはＩＤ／パスワード要求(201) をクライアントに対して行なう。」、段落【００２９】における記載「クライアントではユーザにＩＤ／パスワードを入力を求め(101) 、入力されたＩＤ／パスワードをデータ要求と共にをサーバに対して送る(102) 。」からすると、引用文献に記載された前記方法は、クライアントが、認証を要求するサーバに最初のアクセス要求を送信するステップと、クライアントが、前記認証を要求するサーバにＩＤ／パスワードを提供するステップとを含むと解される。
　そして、（ウ）の段落【００２９】における記載「サーバは予めＩＤ／パスワードが登録されているＩＤ／パスワードデータベース４を検索し，クライアントから送られてきたＩＤ／パスワードの正当性をチェックする(202) 。サーバはＩＤ／パスワードが正しければ，乱数を用いてランダムなセッションＩＤ／パスワードを生成し，クライアントへ送信すると共に(210) 、生成したセッションＩＤ／パスワードをセッションＩＤ／パスワードデータベース５に登録する。」からすると、引用文献に記載された前記方法は、認証を要求するサーバが前記ＩＤ／パスワードを前記認証手段に確認するステップであって、前記認証手段が、前記クライアントによって前記サーバに提供された前記ＩＤ／パスワードを確認するステップと、前記認証手段が、セッションＩＤ／パスワードを生成するステップと、前記認証手段が、前記生成されたセッションＩＤ／パスワードをセッションＩＤ／パスワードデータベースに維持するステップとを含むと解される。
　
　また、（ウ）の段落【００３０】における記載「以後クライアントは現在実行中のセッションが終了するまで、該セッションに係わるアクセス要求には、下記の通り全てセッションＩＤ／パスワードを付与する。」、段落【００３２】における記載「さらに実行中のセッションの終了までに、該セッションに関してデータの要求がある場合、クライアントは上記(120) 〜(132) の処理，サーバは(220) 〜(230) の処理を繰り返す。即ちクライアントは先にサーバが発行したセッションＩＤ／パスワードをデータ要求の度に送出し、サーバはこのセッションＩＤ／パスワードを用いて認証処理を行う。」からすると、引用文献に記載された前記方法は、前記クライアントが、認証を要求するサーバに該セッションに係わる２番目以降のアクセス要求を送信するステップと、前記認証を要求するサーバが、前記クライアントを認証するために、前記セッションＩＤ／パスワードデータベースに維持されたセッションＩＤ／パスワードを使用して、前記クライアントの認証をするステップとを含むと解される。
　
　したがって、引用文献には、次の発明（以下、「引用発明」という。）が記載されているものと認められる。
　
　クライアントがアクセスするデータベースと、ユーザ認証のためのＩＤ／パスワードデータベース及びセッションＩＤ／パスワードデータベースから構成される認証用データベースを用いてクライアントを認証する認証手段とを有するサーバを有するクライアント／サーバ環境にて、クライアント認証の操作を調整する方法であって、クライアントと前記サーバとの間の通信において、クライアントと前記サーバとの間でＷＷＷにおいて使用されるＨＴＴＰプロトコルを使用し、
　前記方法が、
　クライアントが、認証を要求するサーバに最初のアクセス要求を送信するステップと、
　クライアントが、前記認証を要求するサーバにＩＤ／パスワードを提供するステップと、
　前記サーバが前記ＩＤ／パスワードを前記認証手段に確認するステップであって、
　前記認証手段が、前記クライアントによって前記サーバに提供された前記ＩＤ／パスワードを確認するステップと、
　前記認証手段が、セッションＩＤ／パスワードを生成するステップと、
　前記認証手段が、前記生成されたセッションＩＤ／パスワードをセッションＩＤ／パスワードデータベースに維持するステップと、
　前記クライアントが、認証を要求するサーバに該セッションに係わる２番目のアクセス要求を送信するステップと、
　前記認証を要求するサーバが、前記クライアントを認証するために、前記セッションＩＤ／パスワードデータベースに維持されたセッションＩＤ／パスワードを使用して、前記クライアントの認証をするステップと、
　を含む、方法。
　
３．対比・判断
　ここで、本願発明と引用発明とを対比する。
　引用発明の「クライアント」、「最初のアクセス要求」、「ＩＤ／パスワード」、「セッションＩＤ／パスワード」、及び「該セッションに係わる２番目のアクセス要求」は、それぞれ、本願発明の「クライアント・コンピュータ」、「第１操作のリクエスト」、「クライアント認証情報」、「セッションＩＤ」及び「第２操作のリクエスト」に相当する。
　引用発明のクライアントとサーバとの間で使用される「ＷＷＷにおいて使用されるＨＴＴＰプロトコル」は、ステートレスである（すなわち、状態情報を受け渡すことについて制限されたまたは未定義の手順をもつプロトコルである）から、引用発明の「ＷＷＷにおいて使用されるＨＴＴＰプロトコル」は、本願発明の「状態情報を受け渡すことについて制限されたまたは未定義の手順をもつプロトコル」に相当する。
　
　引用発明の「クライアントがアクセスするデータベースと、ユーザ認証のためのＩＤ／パスワードデータベース及びセッションＩＤ／パスワードデータベースから構成される認証用データベースを用いてクライアントを認証する認証手段とを有するサーバ」は、クライアントがアクセスするデータベースを有するサーバであって、クライアントに対して認証を要求するサーバであることから、引用発明の「クライアントがアクセスするデータベースと、ユーザ認証のためのＩＤ／パスワードデータベース及びセッションＩＤ／パスワードデータベースから構成される認証用データベースを用いてクライアントを認証する認証手段とを有するサーバ」と、本願発明の「１つ以上の参加サーバ・コンピュータ」及び「認証を要求する参加サーバ・コンピュータ」とは、ともに、認証を要求するサーバ・コンピュータである点で共通する。
　そして、引用発明の前記サーバは、クライアントとの間の通信において、クライアントとの間でＷＷＷにおいて使用されるＨＴＴＰプロトコルを使用することから、引用発明の前記サーバは、本願発明のクライアント・コンピュータとの間の通信において、クライアント・コンピュータとの間で状態情報を受け渡すことについて制限されたまたは未定義の手順をもつプロトコルを使用する、「少なくとも１つの前記サーバ・コンピュータ」に相当する。
　また、引用発明の前記サーバは、クライアントが該セッションに係わる２番目のアクセス要求を送信するサーバであって、前記クライアントを認証するために、セッションＩＤ／パスワードデータベースに維持されたセッションＩＤ／パスワードを使用して、前記クライアントの認証をするサーバであることから、本願発明の、クライアント・コンピュータが、第２操作のリクエストを送信する「認証を要求するサーバ・コンピュータの１つ」であって、前記クライアント・コンピュータを認証するために、維持されたセッションＩＤを使用して、前記クライアント・コンピュータの認証をする、「認証を要求するサーバ・コンピュータの１つ」に相当する。
　また、引用発明の「認証手段」と、本願発明の「コントローラ・サーバ・コンピュータ」とは、ともに、認証手段である点で共通する。
　
　したがって、本願発明と引用発明とは、以下の点で一致し、また、相違している。
　
（一致点）
　認証を要求するサーバ・コンピュータを有するクライアント／サーバ環境にて、クライアント認証の操作を調整する方法であって、クライアント・コンピュータと少なくとも１つの前記サーバ・コンピュータとの間の通信において、クライアント・コンピュータと少なくとも１つの前記サーバ・コンピュータとの間で状態情報を受け渡すことについて制限されたまたは未定義の手順をもつプロトコルを使用し、
　前記方法が、
　クライアント・コンピュータが、認証を要求するサーバ・コンピュータに第１操作のリクエストを送信するステップと、
　クライアント・コンピュータが、前記認証を要求するサーバ・コンピュータにクライアント認証情報を提供するステップと、
　前記認証を要求するサーバ・コンピュータが前記クライアント認証情報を認証手段に確認するステップであって、前記認証手段が、前記クライアント・コンピュータによって前記認証を要求するサーバ・コンピュータに提供された前記クライアント認証情報を確認するステップと、
　前記認証手段が、セッションＩＤを生成するステップと、
　前記認証手段が、前記生成されたセッションＩＤを維持するステップと、
　前記クライアント・コンピュータが、認証を要求するサーバ・コンピュータの１つに第２操作のリクエストを送信するステップと、
　前記認証を要求するサーバ・コンピュータの１つが、前記クライアント・コンピュータを認証するために、前記維持されたセッションＩＤを使用して、前記クライアント・コンピュータの認証をするステップと、
　を含む、方法。
　
（相違点１）
　本願発明は、１つ以上の参加サーバ・コンピュータ及び１つ以上のコントローラ・サーバ・コンピュータを含むサーバ・グループを有するクライアント／サーバ環境にて、サーバ・グループのサーバ・コンピュータ間でクライアント認証の操作を調整する方法であるのに対し、引用発明は、クライアントがアクセスするデータベースと、ユーザ認証のためのＩＤ／パスワードデータベース及びセッションＩＤ／パスワードデータベースから構成される認証用データベースを用いてクライアントを認証する認証手段とを有するサーバを有するクライアント／サーバ環境にて、クライアント認証の操作を調整する方法である点。
　
（相違点２）
　本願発明は、クライアント・コンピュータが、認証を要求する参加サーバ・コンピュータに第１操作のリクエストを送信するステップと、クライアント・コンピュータが、前記認証を要求する参加サーバ・コンピュータにクライアント認証情報を提供するステップとを有するものであるのに対し、引用発明は、クライアントが、認証を要求するサーバに最初のアクセス要求を送信するステップと、クライアントが、前記認証を要求するサーバにＩＤ／パスワードを提供するステップとを有するものである点。
　
（相違点３）
　本願発明は、参加サーバ・コンピュータが少なくとも１つのコントローラ・サーバ・コンピュータと通信でき、参加サーバ・コンピュータがクライアント認証情報をコントローラ・サーバ・コンピュータに確認するステップであって、コントローラ・サーバ・コンピュータが、クライアント・コンピュータによって参加サーバ・コンピュータに提供されたクライアント認証情報を確認するステップと、コントローラ・サーバ・コンピュータが、セッションＩＤを生成するステップと、コントローラ・サーバ・コンピュータが、前記生成されたセッションＩＤを維持するステップと、前記クライアント・コンピュータが、認証を要求するサーバ・コンピュータの１つに第２操作のリクエストを送信するステップと、前記サーバ・コンピュータの１つが、前記クライアント・コンピュータを認証するために、維持されたセッションＩＤを使用して、前記クライアント・コンピュータの認証をするステップとを有するものであるに対し、引用発明は、認証を要求するサーバがＩＤ／パスワードを認証手段に確認するステップにおいて、前記認証手段が、前記クライアントによって前記サーバに提供された前記ＩＤ／パスワードを確認するステップと、前記認証手段が、セッションＩＤ／パスワードを生成するステップと、前記認証手段が、前記生成されたセッションＩＤ／パスワードをセッションＩＤ／パスワードデータベースに維持するステップと、前記クライアントが、認証を要求するサーバに該セッションに係わる２番目のアクセス要求を送信するステップと、前記認証を要求するサーバが、前記クライアントを認証するために、前記セッションＩＤ／パスワードデータベースに維持されたセッションＩＤ／パスワードを使用して、前記クライアントの認証をするステップとを有するものである点。
　
　相違点１〜相違点３について検討する。
　本願出願の優先権主張日の前の１９９６年９月１６日に頒布された刊行物（安東一真、「進化するイントラネットアクセス管理で作るセキュリティ・インフラ　ＰＡＲＴ２パスワード管理から始める」、日経コミュニケーション、第２３０号、日経ＢＰ社、１９９６年９月１６日、ｐ．１００−１０３）に、
「従来のＷＷＷサーバーでは，ユーザーＩＤとパスワードの管理，アクセス権の設定（読み出し，ＣＧＩプログラムの実行などは，サーバーごとに行う必要があった。
　アクセス権を一元管理し，シングル・ログインを可能にするＷＷＷサーバーは，マイクロソプトとノベルがそれぞれ９６年５月，４月に国内で出荷を始めた。
　マイクロソフトの「Ｉｎｔｅｒｎｅｔ　Ｉｎｆｏｒｍａｔｉｏｎ　Ｓｅｒｖｅｒ　１．０」（ＩＩＳ）は，ユーザーＩＤとパスワードの管理に，Ｗｉｎｄｏｗｓ　ＮＴ　Ｓｅｒｖｅｒが備える認証サーバー機能「ドメイン・コントローラ」を使う」（ｐ．１０１左欄下から６行目〜中欄１０行目。）、
「ＷｉｎｄｏｗｓＮＴが備える認証サーバー機能（ＮＴドメイン・コントローラ）を使って，ユーザーＩＤとパスワードを一元的に管理している。」（ｐ．１０２の「図２−２」欄）、
「Ｎｅｔｗａｒｅ４．１が備える認証サーバー機能（ＮＤＳ：Ｎｏｖｅｌｌ　ｄｉｒｅｃｔｏｒｙ　ｓｅｒｖｉｃｅｓ）を使って，ユーザーＩＤとパスワードを一元的に管理している。」（ｐ．１０２の「図２−３」欄）と記載され、
　また、本願出願の優先権主張日の前の１９９７年３月１日に頒布された刊行物（堀内周、「イントラネットの導入」、ＬＡＮ　ＴＩＭＥＳ、第７巻、第３号、ソフトバンク株式会社、１９９７年３月１日、ｐ．９１）に、
「個々のサーバ上に別々に認証機能を持たせたのでは，ユーザーはその都度ユーザー名／パスワードを入力しなければならず非常に不便だ。
　やはり、認証機能は１つのサーバ（認証サーバ）で行い，認証後は許可されたサービスを自由に使える環境の構築を目指すべきであろう。」（ｐ．９１の左欄１８行目〜２４行目）と記載されているように、認証用データベースを用いてクライアントを認証する機能（すなわち、認証手段）を有する、クライアントのアクセスするデータベースを備えるサーバを有するクライアント／サーバ環境について、認証手段を独立した１つのサーバ（認証サーバ）とし、認証を一元化すること、すなわち、認証用データベースを用いてクライアントを認証する認証手段をクライアントのアクセスするデータベースを備えるサーバ（以下、簡単のため「サーバ」という）とは別個の独立した１つの認証サーバ（「コントローラ・サーバ・コンピュータ」に相当）とすることで、前記クライアント／サーバ環境を１つ以上のサーバと１つ以上の認証サーバを含むサーバ・グループを有するクライアント／サーバ環境として、前記クライアント／サーバ環境にてサーバが前記（少なくとも１つの）認証サーバと通信でき、サーバがクライアント認証情報を認証サーバに確認することで、前記サーバと認証サーバのサーバ間でクライアント認証の操作を調整する方法は、当業者にとって周知の技術である。
　
　してみると、引用発明の「クライアントがアクセスするデータベースと、ユーザ認証のためのＩＤ／パスワードデータベース及びセッションＩＤ／パスワードデータベースから構成される認証用データベースを用いてクライアントを認証する認証手段とを有するサーバを有するクライアント／サーバ環境」に前記周知技術を適用し、引用発明の「認証手段」をクライアントがアクセスするデータベースを備えるサーバとは別個の独立した１つの認証サーバ（「コントローラ・サーバ・コンピュータ」に相当）とすることで、引用発明を、１つ（すなわち、１つ以上）の、クライアントのアクセスするデータベースを備えるサーバ及び１つ（すなわち、１つ以上）の認証サーバを含むサーバ・グループを有するクライアント／サーバ環境とし、前記サーバ・グループの前記クライアントのアクセスするデータベースを備えるサーバが前記認証サーバと通信でき、前記サーバ・グループの前記サーバ間でクライアント認証の操作を調整する方法とすることは、当業者であれば、容易に想到し得たことである。
　そして、その際に、前記方法が、
　クライアントが、クライアントのアクセスするデータベースを備えるサーバ、すなわち認証を要求するサーバ（「参加サーバ・コンピュータ」に相当）に最初のアクセス要求を送信するステップと、クライアントが、前記サーバにＩＤ／パスワードを提供するステップと、前記サーバが１つの認証サーバと通信でき、前記サーバがクライアント認証情報を前記認証サーバに確認するステップであって、前記認証サーバが、クライアントによって前記サーバに提供されたＩＤ／パスワードを確認するステップと、前記認証サーバが、セッションＩＤ／パスワードを生成するステップと、前記認証サーバが、前記生成されたセッションＩＤ／パスワードを維持するステップと、前記クライアントが、前記サーバに該セッションに係わる２番目以降のアクセス要求を送信するステップと、前記サーバが、前記クライアントを認証するために、維持されたセッションＩＤ／パスワードを使用して、前記クライアントの認証をするステップとを含む方法となることは、明らかである。
　
　よって、相違点１〜相違点３は格別なものではない。
　
　そして、本願発明の作用効果も、引用発明及び上記周知技術から当業者が予測できる範囲のものである。
　したがって、本願発明は、引用発明及び周知技術から容易に発明できたものであるから、特許法第２９条第２項の規定により特許を受けることができない。
　
４．むすび
　以上のとおり、本願の請求項１に係る発明は、その出願前日本国内又は外国において頒布された刊行物に記載された発明に基いて、その出願前にその発明の属する技術の分野における通常の知識を有する者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。
　
　よって、結論のとおり審決する。