• ポートフォリオ機能


ポートフォリオを新規に作成して保存
既存のポートフォリオに追加保存

  • この表をプリントする
PDF PDFをダウンロード
審決分類 審判 査定不服 2項進歩性 特許、登録しない。 G06F
審判 査定不服 特17条の2、3項新規事項追加の補正 特許、登録しない。 G06F
管理番号 1203243
審判番号 不服2006-25679  
総通号数 118 
発行国 日本国特許庁(JP) 
公報種別 特許審決公報 
発行日 2009-10-30 
種別 拒絶査定不服の審決 
審判請求日 2006-11-14 
確定日 2009-08-24 
事件の表示 特願2003-297417「サーバ・グループ間で操作を調整する方法」拒絶査定不服審判事件〔平成16年 3月11日出願公開、特開2004- 78967〕について、次のとおり審決する。 
結論 本件審判の請求は、成り立たない。 
理由 第1.手続の経緯
本願は、平成10年5月1日(パリ条約による優先権主張1997年5月8日、米国)に出願した特願平10-122395号の一部を平成15年8月21日に新たな特許出願としたものであって、平成17年12月16日付けで拒絶理由通知がなされ、平成18年3月1日付けで手続補正がなされ、同年4月24日付けで最後の拒絶理由通知がなされ、同年7月12日付けで手続補正がなされたが、同年8月10日付けで前記平成18年7月12日付け手続補正を補正却下するとともに、拒絶査定がなされ、これに対し、同年11月14日に審判請求がなされるとともに、同日付けで手続補正がなされたものである。そして、平成19年1月10日付けで審査官から前置報告がなされ、平成20年11月25日付けで当審より審尋がなされ、平成21年2月16日付けで回答書が提出されたものである。

第2.補正却下の決定
[補正却下の決定の結論]
平成18年11月14日付けの手続補正を却下する。

[理由]
1.補正の内容
平成18年11月14日付けの手続補正(以下、「本件補正」という。)の内容は、平成18年3月1日付けの手続補正により補正された特許請求の範囲の記載
「【請求項1】
1つ以上の参加サーバ・コンピュータ及び1つ以上のコントローラ・サーバ・コンピュータを含むサーバ・グループを有するクライアント/サーバ環境にて、前記サーバ・グループの前記サーバ・コンピュータ間でクライアント認証の操作を調整する方法であって、各参加サーバ・コンピュータが少なくとも1つのコントローラ・サーバ・コンピュータと通信でき、クライアント・コンピュータと前記少なくとも1つの前記サーバ・コンピュータとの間の通信において、クライアント・コンピュータと前記少なくとも1つの前記サーバ・コンピュータとの間で状態情報を受け渡すことについて制限されたまたは未定義の手順をもつプロトコルを使用し、
前記方法が、
クライアント・コンピュータが、認証を要求する参加サーバ・コンピュータに第1操作のリクエストを送信するステップと、
クライアント・コンピュータが、前記認証を要求する参加サーバ・コンピュータにクライアント認証情報を提供するステップと、
前記参加サーバ・コンピュータが前記クライアント認証情報を前記コントローラ・サーバ・コンピュータに確認するステップであって、前記コントローラ・サーバ・コンピュータが、前記クライアント・コンピュータによって前記参加サーバ・コンピュータに提供された前記クライアント認証情報を確認するステップと、
前記コントローラ・サーバ・コンピュータが、セッションIDを生成するステップと、
前記コントローラ・サーバ・コンピュータが、前記生成されたセッションIDを維持するステップと、
前記クライアント・コンピュータが、認証を要求するサーバ・コンピュータの1つに第2操作のリクエストを送信するステップと、
前記サーバ・コンピュータの1つが、前記クライアント・コンピュータを認証するために、前記維持されたセッションIDを使用して、前記クライアント・コンピュータの認証をするステップと、
を含む、方法。
【請求項2】
1つ以上の参加サーバ・コンピュータ及び1つ以上のコントローラ・サーバ・コンピュータを含むサーバ・グループを有するクライアント/サーバ環境にて、前記サーバ・グループの前記サーバ・コンピュータ間でクライアント認証の操作を調整する方法であって、各参加サーバ・コンピュータが少なくとも1つのコントローラ・サーバ・コンピュータと通信でき、クライアント・コンピュータと前記少なくとも1つの前記サーバ・コンピュータとの間の通信において、クライアント・コンピュータと前記少なくとも1つの前記サーバ・コンピュータとの間で状態情報を受け渡すことについて制限されたまたは未定義の手順をもつプロトコルを使用し、
前記方法が、
クライアント・コンピュータが、認証を要求するコントローラ・サーバ・コンピュータに第1操作のリクエストを送信するステップと、
クライアント・コンピュータが、前記認証を要求するコントローラ・サーバ・コンピュータにクライアント認証情報を提供するステップと、
前記コントローラ・サーバ・コンピュータが前記クライアント認証情報を確認するステップと、
前記コントローラ・サーバ・コンピュータが、セッションIDを生成するステップと、
前記コントローラ・サーバ・コンピュータが、前記生成されたセッションIDを維持するステップと、
前記クライアント・コンピュータが、認証を要求するサーバ・コンピュータの1つに第2操作のリクエストを送信するステップと、
前記サーバ・コンピュータの1つが、前記クライアント・コンピュータを認証するために、前記維持されたセッションIDを使用して、前記クライアント・コンピュータの認証をするステップと、
を含む、方法。
【請求項3】
前記クライアント・コンピュータが少なくとも1つのサーバ・コンピュータからプログラムを受け取って、該受け取ったプログラムを実行し、前記クライアント・コンピュータが前記サーバ・グループの少なくともいくつかの機能を実行するステップさらに含む、請求項1又は2に記載の方法。
【請求項4】
前記セッションIDが複数の前記コントローラ・サーバ・コンピュータに分散される、請求項3に記載の方法。
【請求項5】
前記クライアント認証情報がユーザID及びパスワードである、請求項1?3のいずれか一項に記載の方法。
【請求項6】
前記セッションIDから、ユーザIDを計算することが可能である、請求項5に記載の方法。
【請求項7】
前記維持されたセッションIDを使用して、前記クライアント・コンピュータの認証をするステップにおいて、前記ユーザIDをさらに使用する、請求項6に記載の方法。
【請求項8】
前記セッションIDの存続期間が制限される、請求項1?7のいずれか一項に記載の方法に記載の方法。」(以下、この特許請求の範囲に記載された請求項を「補正前の請求項」という。)を、

「【請求項1】
1つ以上の参加サーバ・コンピュータ及び1つ以上のコントローラ・サーバ・コンピュータを含むサーバ・グループを有するクライアント/サーバ環境にて、前記サーバ・グループの前記サーバ・コンピュータ間でクライアント認証の操作を調整する方法であって、各参加サーバ・コンピュータが少なくとも1つのコントローラ・サーバ・コンピュータと通信でき、クライアント・コンピュータと前記少なくとも1つの前記サーバ・コンピュータとの間の通信において、クライアント・コンピュータと前記少なくとも1つの前記サーバ・コンピュータとの間で状態情報を受け渡すことについて制限されたまたは未定義の手順をもつプロトコルを使用し、
前記方法が、
クライアント・コンピュータが、認証を要求する参加サーバ・コンピュータに第1操作のリクエストを送信するステップと、
クライアント・コンピュータが、前記認証を要求する参加サーバ・コンピュータにユーザID及びパスワードを含むクライアント認証情報を提供するステップと、
前記参加サーバ・コンピュータが前記クライアント認証情報を前記コントローラ・サーバ・コンピュータに確認するステップであって、前記コントローラ・サーバ・コンピュータが、前記クライアント・コンピュータによって前記参加サーバ・コンピュータに提供された前記クライアント認証情報を確認するステップと、
前記コントローラ・サーバ・コンピュータが、クライアント・コンピュータを認証するために用いられるセッションIDを生成するステップであって、前記セッションIDは、前記ユーザID及び前記クライアント・コンピュータによりアクセスされた参加サーバ・コンピュータを表すため情報をさらに含む、前記生成するステップと、
前記コントローラ・サーバ・コンピュータが、前記生成されたセッションIDを維持するステップと、
前記クライアント・コンピュータが、認証を要求するサーバ・コンピュータの1つに第2操作のリクエストを送信するステップと、
前記サーバ・コンピュータの1つが、前記クライアント・コンピュータを認証するために、前記維持されたセッションIDを使用して、前記クライアント・コンピュータの認証をするステップと、
を含む、方法。
【請求項2】
1つ以上の参加サーバ・コンピュータ及び1つ以上のコントローラ・サーバ・コンピュータを含むサーバ・グループを有するクライアント/サーバ環境にて、前記サーバ・グループの前記サーバ・コンピュータ間でクライアント認証の操作を調整する方法であって、各参加サーバ・コンピュータが少なくとも1つのコントローラ・サーバ・コンピュータと通信でき、クライアント・コンピュータと前記少なくとも1つの前記サーバ・コンピュータとの間の通信において、クライアント・コンピュータと前記少なくとも1つの前記サーバ・コンピュータとの間で状態情報を受け渡すことについて制限されたまたは未定義の手順をもつプロトコルを使用し、
前記方法が、
クライアント・コンピュータが、認証を要求するコントローラ・サーバ・コンピュータに第1操作のリクエストを送信するステップと、
クライアント・コンピュータが、前記認証を要求するコントローラ・サーバ・コンピュータにユーザID及びパスワードを含むクライアント認証情報を提供するステップと、
前記コントローラ・サーバ・コンピュータが前記クライアント認証情報を確認するステップと、
前記コントローラ・サーバ・コンピュータが、クライアント・コンピュータを認証するために用いられるセッションIDを生成するステップと、
前記コントローラ・サーバ・コンピュータが、前記生成されたセッションIDを維持するステップであって、前記セッションIDは、前記ユーザID及び前記クライアント・コンピュータによりアクセスされた参加サーバ・コンピュータを表すため情報をさらに含む、前記維持するステップと、
前記クライアント・コンピュータが、認証を要求するサーバ・コンピュータの1つに第2操作のリクエストを送信するステップと、
前記サーバ・コンピュータの1つが、前記クライアント・コンピュータを認証するために、前記維持されたセッションIDを使用して、前記クライアント・コンピュータの認証をするステップと、
を含む、方法。
【請求項3】
前記セッションIDの存続期間が制限される、請求項1又は2に記載の方法。」(以下、この特許請求の範囲に記載された請求項を「補正後の請求項」という。)
に補正するものである。

2.補正の適否
(1)補正の適否(特許法第17条の2第3項に規定する要件についての検討)
補正後の請求項1?請求項3は、その記載からして、それぞれ少なくとも次の事項(ア)を含んでいる。

(ア)コントローラ・サーバ・コンピュータの生成するセッションIDは、前記ユーザID及び前記クライアント・コンピュータによりアクセスされた参加サーバ・コンピュータを表すため情報をさらに含むこと。

(ア)について検討する。
願書に最初に添付した明細書の発明の詳細な説明(注意:下線は当審で付与したもの。)には、
「【0042】
有効なユーザID401及びパスワードがステップ207で入力された場合、コントローラはステップ208でセッションID402を生成する。セッションIDは、会話中にクライアントを認証するために用いられる。セッションIDは、悪意あるユーザがセッションIDを類推しにくいように、充分に大きいキー・スペースからランダムに選択される。コントローラはユーザID及びセッションIDをデータベースに格納する。」、
「【0043】
ステップ208で、クライアントからコンタクトされたサーバは、会話でユーザID401及びセッションID402を状態変数として保存する。」、
「【0044】
ステップ208でサーバはまたそのIDをアクセス・ノード状態変数403にエンコードし、会話でアクセス・ノード状態変数を保存する。アクセス・ノード状態変数403は、認証の間にクライアントによりアクセスされた参加サーバを表す1つ以上の状態変数で構成される。1つの変数を使用して、アクセスした全てのサーバを表すことが可能である。しかし複数の変数を使用してより詳細な情報を表すことが望ましい場合もある。例えば認証の前にアクセスした参加サーバ、認証の後にアクセスした参加サーバ、単純トランザクションが実行された参加サーバ等である。」、
「【0045】
クライアントを認証するためにコントローラがそのデータベースに格納する状態情報と、会話で保存される状態情報は必ずしも同一ではない。他より若干多いかまたは少ない状態変数が格納されることもある。しかしそれでも、それぞれに格納される少なくともいくつかの変数は同じである。例えば好適な実施例で、ユーザID及びセッションIDの変数は両方ともコントローラのデータベースに格納され、会話で保存される。」と記載されているように、コントローラ・サーバ・コンピュータの生成する「セッションID」は、悪意あるユーザがセッションIDを類推しにくいように、充分に大きいキー・スペースからランダムに選択され生成された一種の乱数であり、ユーザID及び前記クライアント・コンピュータによりアクセスされた参加サーバ・コンピュータを表すため情報をさらに含むものではない。

よって、(ア)に記載された事項は、出願当初の明細書又は図面に記載されておらず、かつ、その記載から自明なものでもない。

したがって、補正後の請求項1?請求項3に記載された(ア)の事項は、出願当初の明細書又は図面に記載されておらず、かつ、その記載から自明なものでもないから、上記事項を追加する本件補正は、出願当初の明細書又は図面に記載した範囲内でしたものではないので、特許法第17条の2第3項の規定に違反するものである。

3.結語
以上のとおり、本件補正は、願書に最初に添付された明細書、特許請求の範囲又は図面に記載した範囲内にしたものでなく、平成14年法律第24号改正附則第3条第1項によりなお従前の例によるとされる同法による改正前の特許法第17条の2第3項の規定に違反するので、同法第159条第1項において読み替えて準用する同法第53条第1項の規定により却下すべきものである。

第3.本願発明について
1.本願発明
平成18年11月14日付けの手続補正は上記のとおり却下されたので、本願の請求項1に係る発明(以下、「本願発明」という。)は、平成18年3月1日付けの手続補正により補正された特許請求の範囲の請求項1に記載された事項により特定される、以下のとおりのものである。

「1つ以上の参加サーバ・コンピュータ及び1つ以上のコントローラ・サーバ・コンピュータを含むサーバ・グループを有するクライアント/サーバ環境にて、前記サーバ・グループの前記サーバ・コンピュータ間でクライアント認証の操作を調整する方法であって、各参加サーバ・コンピュータが少なくとも1つのコントローラ・サーバ・コンピュータと通信でき、クライアント・コンピュータと前記少なくとも1つの前記サーバ・コンピュータとの間の通信において、クライアント・コンピュータと前記少なくとも1つの前記サーバ・コンピュータとの間で状態情報を受け渡すことについて制限されたまたは未定義の手順をもつプロトコルを使用し、
前記方法が、
クライアント・コンピュータが、認証を要求する参加サーバ・コンピュータに第1操作のリクエストを送信するステップと、
クライアント・コンピュータが、前記認証を要求する参加サーバ・コンピュータにクライアント認証情報を提供するステップと、
前記参加サーバ・コンピュータが前記クライアント認証情報を前記コントローラ・サーバ・コンピュータに確認するステップであって、前記コントローラ・サーバ・コンピュータが、前記クライアント・コンピュータによって前記参加サーバ・コンピュータに提供された前記クライアント認証情報を確認するステップと、
前記コントローラ・サーバ・コンピュータが、セッションIDを生成するステップと、
前記コントローラ・サーバ・コンピュータが、前記生成されたセッションIDを維持するステップと、
前記クライアント・コンピュータが、認証を要求するサーバ・コンピュータの1つに第2操作のリクエストを送信するステップと、
前記サーバ・コンピュータの1つが、前記クライアント・コンピュータを認証するために、前記維持されたセッションIDを使用して、前記クライアント・コンピュータの認証をするステップと、
を含む、方法。」

2.引用発明
原査定の拒絶の理由に引用された特開平8-249253号公報(以下、「引用文献」という。)には、図面とともに次の事項が記載されている。(備考:下線は当審で便宜上付与したものである。)

(ア)「【0002】 ・・・(中略)・・・ WWWは,HTML(HyperText Markup Language)と呼ばれる記述言語で記述された情報をサーバが保持し,クライアントはURL(Universal Resourece Locator)と呼ばれるリソースの場所(情報のありか)を示す識別子を頼りに,サーバから情報をリトリーブし,ユーザに呈示するものである。WWWでは,これまでのテキスト情報ばかりでなく,サーバ上にある画像や音声の情報に簡単にアクセスできる。そのため,企業や大学のピーアール,オンラインショッピング,電子図書館などに利用され,多くの利用者を集める結果となった。
【0003】このWWW では、サーバが保持するデータ又はサービスがある特定のユーザだけにしかアクセスできないように制限を設ける必要がある場合は、ユーザIDとパスワードを用いて特定ユーザかどうかを認証するように構成している。またWWW ではクライアントからサーバへのアクセス要求が行われる度にコネクションが確立し、アクセス終了時点(先のアクセス要求に対する回答が返ってきた段階)でコネクションが切れるように構成されている。・・・(中略)・・・
【0004】・・・(中略)・・・ しかしWWW ではあるアクセス要求に対する応答がなされる度にクライアント─サーバ間のコネクションが解消されるので、アクセス要求の度にクライアントからサーバに対してIDとパスワードとを送出し、認証を行う必要がある。
・・・(中略)・・・
【0009】特に上記のWWW のように、クライアントが実行する1回のセッション(アクセス制限があるデータ/サービスの利用開始から終了までの期間)で複数回のアクセス要求がある場合に、アクセス要求の度にID/パスワードを送出する必要のあるシステムでは、クライアントが実行する1回のセッション中にも複数回のID/パスワードの送受信がなされることになるので、ID/パスワードを盗まれる機会が多く、セキュリティの面で問題がある。」

(イ)「【0019】このように本発明ではアクセス要求装置が実行するセッション中に行われる最初のアクセス要求の時のみ正当なユーザ認証情報を送受信し、その後のアクセス要求時には実行中のセッションにのみ有効なセッション認証情報を送受信するようにしたので、正当なユーザ認証情報が盗まれる機会を少なくなり、ユーザ認証情報の悪用の危険性が減少する。
・・・(中略)・・・
【0021】
【実施例】以下、図面を参照して本発明の実施例を説明する。図2は以下説明する本発明の各実施例が適用されるクライアント─サーバシステムの構成を示すブロック図である。図中、1はクライアント(アクセス要求装置)、2はサーバ(アクセス応答装置)である。複数のクライアント1と複数のサーバが3のネットワークに接続されている。
【0022】また本実施例においては、クライアント1が各種のデータベースを検索したり、各種のサービスを受けることができるよう、複数のサーバ2が設けられている。例えばサーバ2─1は複数のクライアントがアクセスするデータベースを管理するために設けられたものであり、ID/パスワードデータベース4とセッションID/パスワードデータベース5と、クライアントがアクセスする対象である本来のデータが格納されるデータベース6とを有する。
【0023】ID/パスワードデータベース4は各ユーザに対応して設けられたIDとパスワードとの対応を登録しておくテーブルである。このデータベースには予めクライアントからIDとパスワードとを登録する処理が行われ、以後サーバ側ではクライアントから送られるIDとパスワードとを用いてユーザ認証処理を行う。セッションID/パスワードデータベース5は、後で詳述するようにサーバがセッション毎に発行するセッションIDとパスワードとを登録するものである。
【0024】なお本実施例ではID/パスワードデータベース4とセッションID/パスワードデータベース5は独立して設けているが、これを纏めて1つのデータベースにして、ユーザIDと該ユーザIDのクライアントが実行しているセッションに付与されたセッションID/パスワードとを対応づけるように構成しても良い。」

(ウ)「【0028】このようなクライアント─サーバシステムの認証処理について、以下の実施例1?実施例3により更に詳細に説明する。
〔実施例1〕本発明の実施例1の動作を、図3を用いて説明する。この図3では、データベース6を有するサーバ2─1をアクセスする例について説明する。(この説明単に「サーバ」と表記した場合は、サーバ2─1を示す。)
サーバは最初クライアントのアクセス要求の状態にある(200) 。この状態からサーバがクライアントからのアクセス要求(100があると、サーバはID/パスワード要求(201) をクライアントに対して行なう。
【0029】クライアントではユーザにID/パスワードを入力を求め(101) 、入力されたID/パスワードをデータ要求と共にをサーバに対して送る(102) 。サーバは予めID/パスワードが登録されているID/パスワードデータベース4を検索し,クライアントから送られてきたID/パスワードの正当性をチェックする(202) 。サーバはID/パスワードが正しければ,乱数を用いてランダムなセッションID/パスワードを生成し,クライアントへ送信すると共に(210) 、生成したセッションID/パスワードをセッションID/パスワードデータベース5に登録する。
【0030】 ・・・(中略)・・・ 以後クライアントは現在実行中のセッションが終了するまで、該セッションに係わるアクセス要求には、下記の通り全てセッションID/パスワードを付与する。
【0031】クライアントがデータ要求を行なうと(120) 、サーバはセッションID/パスワードを要求する(220) 。クライアントはセッションID/パスワードをサーバに対して送信する(121)。サーバはセッションID/パスワードデータベース5を検索して、送られてきたセッションID/パスワードが正しいかどうかチェックする(221) 。セッションID/パスワードが正しい場合,サーバが保持しているデータ6をクライアントへ送信する(230) 。クライアントはサーバから送られるデータを受信し、画面表示や音声出力等を用いてユーザに当該データを呈示する(132) 。
【0032】さらに実行中のセッションの終了までに、該セッションに関してデータの要求がある場合、クライアントは上記(120) ?(132) の処理,サーバは(220) ?(230) の処理を繰り返す。即ちクライアントは先にサーバが発行したセッションID/パスワードをデータ要求の度に送出し、サーバはこのセッションID/パスワードを用いて認証処理を行う。」

ここで、(イ)の段落【0022】における記載「また本実施例においては、クライアント1が各種のデータベースを検索したり、各種のサービスを受けることができるよう、複数のサーバ2が設けられている。例えばサーバ2─1は複数のクライアントがアクセスするデータベースを管理するために設けられたものであり、ID/パスワードデータベース4とセッションID/パスワードデータベース5と、クライアントがアクセスする対象である本来のデータが格納されるデータベース6とを有する。」、段落【0023】における記載「ID/パスワードデータベース4は各ユーザに対応して設けられたIDとパスワードとの対応を登録しておくテーブルである。このデータベースには予めクライアントからIDとパスワードとを登録する処理が行われ、以後サーバ側ではクライアントから送られるIDとパスワードとを用いてユーザ認証処理を行う。」及び段落【0024】における記載「ID/パスワードデータベース4とセッションID/パスワードデータベース5は独立して設けているが、これを纏めて1つのデータベースにして、ユーザIDと該ユーザIDのクライアントが実行しているセッションに付与されたセッションID/パスワードとを対応づけるように構成しても良い。」、並びに(ウ)の段落【0032】における記載「即ちクライアントは先にサーバが発行したセッションID/パスワードをデータ要求の度に送出し、サーバはこのセッションID/パスワードを用いて認証処理を行う。」からすると、引用文献には、クライアントがアクセスするデータベースと、クライアント認証のためのID/パスワードデータベース及びセッションID/パスワードデータベースを1つのデータベースにしたもの(以下、「ID/パスワードデータベース及びセッションID/パスワードデータベースから構成される認証用データベース」と言う)を備え、前記認証用データベースを用いてクライアントを認証する手段(以下、「認証手段」と言う)とを有するサーバを有するクライアント/サーバ環境が記載されていると解される。
また、(イ)の段落【0019】の記載から、引用文献には、クライアント認証の操作を調整する方法が記載されていると解される。
なお、(ア)の段落【0002】における記載からすると、引用文献記載のクライアントとサーバとの間の通信において、クライアントと前記サーバとの間でWWWにおいて使用されているプロトコル(すなわち、HTTPプロトコル)を使用すると解される。

(ウ)の段落【0028】における記載「サーバは最初クライアントのアクセス要求の状態にある(200) 。この状態からサーバがクライアントからのアクセス要求(100があると、サーバはID/パスワード要求(201) をクライアントに対して行なう。」、段落【0029】における記載「クライアントではユーザにID/パスワードを入力を求め(101) 、入力されたID/パスワードをデータ要求と共にをサーバに対して送る(102) 。」からすると、引用文献に記載された前記方法は、クライアントが、認証を要求するサーバに最初のアクセス要求を送信するステップと、クライアントが、前記認証を要求するサーバにID/パスワードを提供するステップとを含むと解される。
そして、(ウ)の段落【0029】における記載「サーバは予めID/パスワードが登録されているID/パスワードデータベース4を検索し,クライアントから送られてきたID/パスワードの正当性をチェックする(202) 。サーバはID/パスワードが正しければ,乱数を用いてランダムなセッションID/パスワードを生成し,クライアントへ送信すると共に(210) 、生成したセッションID/パスワードをセッションID/パスワードデータベース5に登録する。」からすると、引用文献に記載された前記方法は、認証を要求するサーバが前記ID/パスワードを前記認証手段に確認するステップであって、前記認証手段が、前記クライアントによって前記サーバに提供された前記ID/パスワードを確認するステップと、前記認証手段が、セッションID/パスワードを生成するステップと、前記認証手段が、前記生成されたセッションID/パスワードをセッションID/パスワードデータベースに維持するステップとを含むと解される。

また、(ウ)の段落【0030】における記載「以後クライアントは現在実行中のセッションが終了するまで、該セッションに係わるアクセス要求には、下記の通り全てセッションID/パスワードを付与する。」、段落【0032】における記載「さらに実行中のセッションの終了までに、該セッションに関してデータの要求がある場合、クライアントは上記(120) ?(132) の処理,サーバは(220) ?(230) の処理を繰り返す。即ちクライアントは先にサーバが発行したセッションID/パスワードをデータ要求の度に送出し、サーバはこのセッションID/パスワードを用いて認証処理を行う。」からすると、引用文献に記載された前記方法は、前記クライアントが、認証を要求するサーバに該セッションに係わる2番目以降のアクセス要求を送信するステップと、前記認証を要求するサーバが、前記クライアントを認証するために、前記セッションID/パスワードデータベースに維持されたセッションID/パスワードを使用して、前記クライアントの認証をするステップとを含むと解される。

したがって、引用文献には、次の発明(以下、「引用発明」という。)が記載されているものと認められる。

クライアントがアクセスするデータベースと、ユーザ認証のためのID/パスワードデータベース及びセッションID/パスワードデータベースから構成される認証用データベースを用いてクライアントを認証する認証手段とを有するサーバを有するクライアント/サーバ環境にて、クライアント認証の操作を調整する方法であって、クライアントと前記サーバとの間の通信において、クライアントと前記サーバとの間でWWWにおいて使用されるHTTPプロトコルを使用し、
前記方法が、
クライアントが、認証を要求するサーバに最初のアクセス要求を送信するステップと、
クライアントが、前記認証を要求するサーバにID/パスワードを提供するステップと、
前記サーバが前記ID/パスワードを前記認証手段に確認するステップであって、
前記認証手段が、前記クライアントによって前記サーバに提供された前記ID/パスワードを確認するステップと、
前記認証手段が、セッションID/パスワードを生成するステップと、
前記認証手段が、前記生成されたセッションID/パスワードをセッションID/パスワードデータベースに維持するステップと、
前記クライアントが、認証を要求するサーバに該セッションに係わる2番目のアクセス要求を送信するステップと、
前記認証を要求するサーバが、前記クライアントを認証するために、前記セッションID/パスワードデータベースに維持されたセッションID/パスワードを使用して、前記クライアントの認証をするステップと、
を含む、方法。

3.対比・判断
ここで、本願発明と引用発明とを対比する。
引用発明の「クライアント」、「最初のアクセス要求」、「ID/パスワード」、「セッションID/パスワード」、及び「該セッションに係わる2番目のアクセス要求」は、それぞれ、本願発明の「クライアント・コンピュータ」、「第1操作のリクエスト」、「クライアント認証情報」、「セッションID」及び「第2操作のリクエスト」に相当する。
引用発明のクライアントとサーバとの間で使用される「WWWにおいて使用されるHTTPプロトコル」は、ステートレスである(すなわち、状態情報を受け渡すことについて制限されたまたは未定義の手順をもつプロトコルである)から、引用発明の「WWWにおいて使用されるHTTPプロトコル」は、本願発明の「状態情報を受け渡すことについて制限されたまたは未定義の手順をもつプロトコル」に相当する。

引用発明の「クライアントがアクセスするデータベースと、ユーザ認証のためのID/パスワードデータベース及びセッションID/パスワードデータベースから構成される認証用データベースを用いてクライアントを認証する認証手段とを有するサーバ」は、クライアントがアクセスするデータベースを有するサーバであって、クライアントに対して認証を要求するサーバであることから、引用発明の「クライアントがアクセスするデータベースと、ユーザ認証のためのID/パスワードデータベース及びセッションID/パスワードデータベースから構成される認証用データベースを用いてクライアントを認証する認証手段とを有するサーバ」と、本願発明の「1つ以上の参加サーバ・コンピュータ」及び「認証を要求する参加サーバ・コンピュータ」とは、ともに、認証を要求するサーバ・コンピュータである点で共通する。
そして、引用発明の前記サーバは、クライアントとの間の通信において、クライアントとの間でWWWにおいて使用されるHTTPプロトコルを使用することから、引用発明の前記サーバは、本願発明のクライアント・コンピュータとの間の通信において、クライアント・コンピュータとの間で状態情報を受け渡すことについて制限されたまたは未定義の手順をもつプロトコルを使用する、「少なくとも1つの前記サーバ・コンピュータ」に相当する。
また、引用発明の前記サーバは、クライアントが該セッションに係わる2番目のアクセス要求を送信するサーバであって、前記クライアントを認証するために、セッションID/パスワードデータベースに維持されたセッションID/パスワードを使用して、前記クライアントの認証をするサーバであることから、本願発明の、クライアント・コンピュータが、第2操作のリクエストを送信する「認証を要求するサーバ・コンピュータの1つ」であって、前記クライアント・コンピュータを認証するために、維持されたセッションIDを使用して、前記クライアント・コンピュータの認証をする、「認証を要求するサーバ・コンピュータの1つ」に相当する。
また、引用発明の「認証手段」と、本願発明の「コントローラ・サーバ・コンピュータ」とは、ともに、認証手段である点で共通する。

したがって、本願発明と引用発明とは、以下の点で一致し、また、相違している。

(一致点)
認証を要求するサーバ・コンピュータを有するクライアント/サーバ環境にて、クライアント認証の操作を調整する方法であって、クライアント・コンピュータと少なくとも1つの前記サーバ・コンピュータとの間の通信において、クライアント・コンピュータと少なくとも1つの前記サーバ・コンピュータとの間で状態情報を受け渡すことについて制限されたまたは未定義の手順をもつプロトコルを使用し、
前記方法が、
クライアント・コンピュータが、認証を要求するサーバ・コンピュータに第1操作のリクエストを送信するステップと、
クライアント・コンピュータが、前記認証を要求するサーバ・コンピュータにクライアント認証情報を提供するステップと、
前記認証を要求するサーバ・コンピュータが前記クライアント認証情報を認証手段に確認するステップであって、前記認証手段が、前記クライアント・コンピュータによって前記認証を要求するサーバ・コンピュータに提供された前記クライアント認証情報を確認するステップと、
前記認証手段が、セッションIDを生成するステップと、
前記認証手段が、前記生成されたセッションIDを維持するステップと、
前記クライアント・コンピュータが、認証を要求するサーバ・コンピュータの1つに第2操作のリクエストを送信するステップと、
前記認証を要求するサーバ・コンピュータの1つが、前記クライアント・コンピュータを認証するために、前記維持されたセッションIDを使用して、前記クライアント・コンピュータの認証をするステップと、
を含む、方法。

(相違点1)
本願発明は、1つ以上の参加サーバ・コンピュータ及び1つ以上のコントローラ・サーバ・コンピュータを含むサーバ・グループを有するクライアント/サーバ環境にて、サーバ・グループのサーバ・コンピュータ間でクライアント認証の操作を調整する方法であるのに対し、引用発明は、クライアントがアクセスするデータベースと、ユーザ認証のためのID/パスワードデータベース及びセッションID/パスワードデータベースから構成される認証用データベースを用いてクライアントを認証する認証手段とを有するサーバを有するクライアント/サーバ環境にて、クライアント認証の操作を調整する方法である点。

(相違点2)
本願発明は、クライアント・コンピュータが、認証を要求する参加サーバ・コンピュータに第1操作のリクエストを送信するステップと、クライアント・コンピュータが、前記認証を要求する参加サーバ・コンピュータにクライアント認証情報を提供するステップとを有するものであるのに対し、引用発明は、クライアントが、認証を要求するサーバに最初のアクセス要求を送信するステップと、クライアントが、前記認証を要求するサーバにID/パスワードを提供するステップとを有するものである点。

(相違点3)
本願発明は、参加サーバ・コンピュータが少なくとも1つのコントローラ・サーバ・コンピュータと通信でき、参加サーバ・コンピュータがクライアント認証情報をコントローラ・サーバ・コンピュータに確認するステップであって、コントローラ・サーバ・コンピュータが、クライアント・コンピュータによって参加サーバ・コンピュータに提供されたクライアント認証情報を確認するステップと、コントローラ・サーバ・コンピュータが、セッションIDを生成するステップと、コントローラ・サーバ・コンピュータが、前記生成されたセッションIDを維持するステップと、前記クライアント・コンピュータが、認証を要求するサーバ・コンピュータの1つに第2操作のリクエストを送信するステップと、前記サーバ・コンピュータの1つが、前記クライアント・コンピュータを認証するために、維持されたセッションIDを使用して、前記クライアント・コンピュータの認証をするステップとを有するものであるに対し、引用発明は、認証を要求するサーバがID/パスワードを認証手段に確認するステップにおいて、前記認証手段が、前記クライアントによって前記サーバに提供された前記ID/パスワードを確認するステップと、前記認証手段が、セッションID/パスワードを生成するステップと、前記認証手段が、前記生成されたセッションID/パスワードをセッションID/パスワードデータベースに維持するステップと、前記クライアントが、認証を要求するサーバに該セッションに係わる2番目のアクセス要求を送信するステップと、前記認証を要求するサーバが、前記クライアントを認証するために、前記セッションID/パスワードデータベースに維持されたセッションID/パスワードを使用して、前記クライアントの認証をするステップとを有するものである点。

相違点1?相違点3について検討する。
本願出願の優先権主張日の前の1996年9月16日に頒布された刊行物(安東一真、「進化するイントラネットアクセス管理で作るセキュリティ・インフラ PART2パスワード管理から始める」、日経コミュニケーション、第230号、日経BP社、1996年9月16日、p.100-103)に、
「従来のWWWサーバーでは,ユーザーIDとパスワードの管理,アクセス権の設定(読み出し,CGIプログラムの実行などは,サーバーごとに行う必要があった。
アクセス権を一元管理し,シングル・ログインを可能にするWWWサーバーは,マイクロソプトとノベルがそれぞれ96年5月,4月に国内で出荷を始めた。
マイクロソフトの「Internet Information Server 1.0」(IIS)は,ユーザーIDとパスワードの管理に,Windows NT Serverが備える認証サーバー機能「ドメイン・コントローラ」を使う」(p.101左欄下から6行目?中欄10行目。)、
「WindowsNTが備える認証サーバー機能(NTドメイン・コントローラ)を使って,ユーザーIDとパスワードを一元的に管理している。」(p.102の「図2-2」欄)、
「Netware4.1が備える認証サーバー機能(NDS:Novell directory services)を使って,ユーザーIDとパスワードを一元的に管理している。」(p.102の「図2-3」欄)と記載され、
また、本願出願の優先権主張日の前の1997年3月1日に頒布された刊行物(堀内周、「イントラネットの導入」、LAN TIMES、第7巻、第3号、ソフトバンク株式会社、1997年3月1日、p.91)に、
「個々のサーバ上に別々に認証機能を持たせたのでは,ユーザーはその都度ユーザー名/パスワードを入力しなければならず非常に不便だ。
やはり、認証機能は1つのサーバ(認証サーバ)で行い,認証後は許可されたサービスを自由に使える環境の構築を目指すべきであろう。」(p.91の左欄18行目?24行目)と記載されているように、認証用データベースを用いてクライアントを認証する機能(すなわち、認証手段)を有する、クライアントのアクセスするデータベースを備えるサーバを有するクライアント/サーバ環境について、認証手段を独立した1つのサーバ(認証サーバ)とし、認証を一元化すること、すなわち、認証用データベースを用いてクライアントを認証する認証手段をクライアントのアクセスするデータベースを備えるサーバ(以下、簡単のため「サーバ」という)とは別個の独立した1つの認証サーバ(「コントローラ・サーバ・コンピュータ」に相当)とすることで、前記クライアント/サーバ環境を1つ以上のサーバと1つ以上の認証サーバを含むサーバ・グループを有するクライアント/サーバ環境として、前記クライアント/サーバ環境にてサーバが前記(少なくとも1つの)認証サーバと通信でき、サーバがクライアント認証情報を認証サーバに確認することで、前記サーバと認証サーバのサーバ間でクライアント認証の操作を調整する方法は、当業者にとって周知の技術である。

してみると、引用発明の「クライアントがアクセスするデータベースと、ユーザ認証のためのID/パスワードデータベース及びセッションID/パスワードデータベースから構成される認証用データベースを用いてクライアントを認証する認証手段とを有するサーバを有するクライアント/サーバ環境」に前記周知技術を適用し、引用発明の「認証手段」をクライアントがアクセスするデータベースを備えるサーバとは別個の独立した1つの認証サーバ(「コントローラ・サーバ・コンピュータ」に相当)とすることで、引用発明を、1つ(すなわち、1つ以上)の、クライアントのアクセスするデータベースを備えるサーバ及び1つ(すなわち、1つ以上)の認証サーバを含むサーバ・グループを有するクライアント/サーバ環境とし、前記サーバ・グループの前記クライアントのアクセスするデータベースを備えるサーバが前記認証サーバと通信でき、前記サーバ・グループの前記サーバ間でクライアント認証の操作を調整する方法とすることは、当業者であれば、容易に想到し得たことである。
そして、その際に、前記方法が、
クライアントが、クライアントのアクセスするデータベースを備えるサーバ、すなわち認証を要求するサーバ(「参加サーバ・コンピュータ」に相当)に最初のアクセス要求を送信するステップと、クライアントが、前記サーバにID/パスワードを提供するステップと、前記サーバが1つの認証サーバと通信でき、前記サーバがクライアント認証情報を前記認証サーバに確認するステップであって、前記認証サーバが、クライアントによって前記サーバに提供されたID/パスワードを確認するステップと、前記認証サーバが、セッションID/パスワードを生成するステップと、前記認証サーバが、前記生成されたセッションID/パスワードを維持するステップと、前記クライアントが、前記サーバに該セッションに係わる2番目以降のアクセス要求を送信するステップと、前記サーバが、前記クライアントを認証するために、維持されたセッションID/パスワードを使用して、前記クライアントの認証をするステップとを含む方法となることは、明らかである。

よって、相違点1?相違点3は格別なものではない。

そして、本願発明の作用効果も、引用発明及び上記周知技術から当業者が予測できる範囲のものである。
したがって、本願発明は、引用発明及び周知技術から容易に発明できたものであるから、特許法第29条第2項の規定により特許を受けることができない。

4.むすび
以上のとおり、本願の請求項1に係る発明は、その出願前日本国内又は外国において頒布された刊行物に記載された発明に基いて、その出願前にその発明の属する技術の分野における通常の知識を有する者が容易に発明をすることができたものであるから、特許法第29条第2項の規定により特許を受けることができない。

よって、結論のとおり審決する。
 
審理終結日 2009-03-30 
結審通知日 2009-03-31 
審決日 2009-04-13 
出願番号 特願2003-297417(P2003-297417)
審決分類 P 1 8・ 121- Z (G06F)
P 1 8・ 561- Z (G06F)
最終処分 不成立  
前審関与審査官 久保 光宏  
特許庁審判長 赤川 誠一
特許庁審判官 石田 信行
冨吉 伸弥
発明の名称 サーバ・グループ間で操作を調整する方法  
代理人 上野 剛史  
代理人 坂口 博  
復代理人 松井 光夫  
代理人 市位 嘉宏  

プライバシーポリシー   セキュリティーポリシー   運営会社概要   サービスに関しての問い合わせ