【事件の表示】
　特願２００１−　４５６２６「認証システムアクセス装置及び公開鍵証明証取得方法及び公開鍵証明証無効化確認方法及び、認証システムアクセスプログラム及び公開鍵証明証取得プログラム及び公開鍵証明証無効化確認プログラム及び認証システムアクセスプログラムを格納した記憶媒体及び公開鍵証明証取得プログラムを格納した記憶媒体及び公開鍵証明証無効化確認プログラムを格納した記憶媒体」拒絶査定不服審判事件〔平成１４年　８月３０日出願公開、特開２００２−２４４５５８、請求項の数（１２）〕について、次のとおり審決する。
【結　論】
　原査定を取り消す。
　本願の発明は、特許すべきものとする。
【理　由】
１．手続の経緯
　本願は、平成１３年２月２１日の出願であって、平成１５年１１月２８日付けで拒絶査定がなされたところ、平成１６年１月５日に審判請求がなされるとともに、平成１６年２月４日付けで手続補正がなされたものである。
　
２．平成１６年２月４日付け手続補正について
　平成１６年２月４日付け手続補正は、実質的に、特許請求の範囲の請求項１の「認証局（ＣＡ）方式定義テーブル」、及び、請求項５，６，８−１０，１２の「ＣＡ別方式定義テーブル」を、いずれも「認証局（ＣＡ）別方式定義テーブル」に補正し、また、請求項７の「前期」を「前記」に補正するものである。
　ここで願書に最初に添付した明細書を見ると、「認証局別方式定義テーブル」は、【００１１】段落をはじめとして多数記載されており、また【０００２】段落には、「ＣＡ（Certification Authority:認証局）」との記載があることから、「認証局（ＣＡ）別方式定義テーブル」は願書に最初に添付した明細書に記載した事項の範囲内であるといえる。
　また、特許請求の範囲を見ても、「認証局（ＣＡ）別方式定義テーブル」は各所に記載されているから、「認証局（ＣＡ）方式定義テーブル」、「ＣＡ別方式定義テーブル」は、何れも、「認証局（ＣＡ）別方式定義テーブル」の誤記であると認められる。
　また、「前期」については、文脈からみて「前記」の誤記であることは明らかである。
　よって、これらの補正は、いずれも特許法第１７条の２第３項に規定される、願書に最初に添付した明細書又は図面に記載した事項の範囲内のものであって、特許法第１７条の２第４項第３号の誤記の訂正を目的とするものであると認める。
　
３．本願請求項１−１２に係る発明
　本願の請求項１−１２に係る発明は、上記平成１６年２月４日付け手続補正による補正後の特許請求の範囲の請求項１−１２に記載されたとおりの以下のものである。
「【請求項１】　公開鍵暗号を用いて電子署名通信や暗号通信を行う際に必要な、公開鍵証明証の取得や無効化確認を行うための認証システムアクセス装置であって、
　公開鍵証明証の発行元の認証局毎に、利用可能な公開鍵証明証の取得及び無効化確認方式を、それぞれ優先順位を付けて定義した認証局（ＣＡ）別方式定義テーブルを作成する認証局（ＣＡ）別方式定義テーブル定義手段と、
　前記公開鍵証明証の取得処理及び無効化確認処理を行う際に、処理対象の公開鍵証明証を発行した発行元の認証局名の情報を取得する発行認証局名取得手段と、
　前記認証局（ＣＡ）別方式定義テーブルを参照し、処理対象の公開鍵証明証の発行認証局名に対応する公開鍵証明証の取得及び無効化確認方式を、優先順位に従って決定する処理方式決定手段と、
　前記処理方式決定手段により決定された方式を用いて、前記処理対象の公開鍵証明証を取得する公開鍵証明証取得手段と、
　前記処理方式決定手段により決定された方式を用いて、前記処理対象の公開鍵証明証の無効化の有無を確認する公開鍵証明証無効化確認手段とを有することを特徴とする認証システムアクセス装置。
　　【請求項２】　公開鍵暗号を用いて電子署名通信や暗号通信を行う際に必要な、公開鍵証明証の取得を行うための認証システムアクセス装置における公開鍵証明証取得方法において、
　認証局（ＣＡ）別方式定義テーブル部が、初期設定時に、公開鍵証明証の発行元の認証局毎に、利用可能な公開鍵証明証の取得方式を、それぞれ優先順位を付けて定義したＣＡ別方式定義テーブルを作成し、公開鍵証明証の取得時に、
　発行認証局（ＣＡ）名取得部が、前記公開鍵証明証の取得処理を行う際に、処理対象の公開鍵証明証を発行した発行元の認証局名の情報を取得し、
　処理方式決定部が、前記ＣＡ別方式定義テーブルを参照し，処理対象の公開鍵証明証の発行認証局名に対応する公開鍵証明証の取得方式を、優先順位に従って決定し、
　公開鍵証明証取得部が、決定された公開鍵証明証の取得方式に従って、前記処理対象の公開鍵証明証を取得することを特徴とする公開鍵証明証取得方法。
　　【請求項３】公開鍵証明証の取得ができなかった場合に、前記公開鍵証明証取得部が、前記決定された公開鍵証明証の取得方式の次の優先順位に相当する取得方式により、再度、公開鍵証明証の取得処理を行う請求項２記載の公開鍵証明証取得方法。
　　【請求項４】　公開鍵暗号を用いて電子署名通信や暗号通信を行う際に必要な、公開鍵証明証無効化確認方法において、
　　認証局（ＣＡ）別方式定義テーブル定義部が、初期設定時に、公開鍵証明証の発行元の認証局毎に、利用可能な公開鍵証明証の無効化確認方式を、それぞれ優先順位を付けて定義した認証局（ＣＡ）別方式定義テーブルを作成し、
　　前記発行者ＣＡ名取得部が、前記公開鍵証明証の無効化確認処理を行う際に、処理対象の公開鍵証明証を発行した発行元の認証局名の情報を取得し、
　　処理方式決定部が、前記ＣＡ別方式定義テーブルを参照し、取得した前記発行元の認証局名に対応する公開鍵証明証の無効化確認方式を優先順位に従って決定し、
　　公開鍵証明証無効確認部が、決定された前記公開鍵証明証の無効化確認方式に従って、前記処理対象の公開鍵証明証の無効化の有無を確認することを特徴とする公開鍵証明証無効化確認方法。
　　【請求項５】　認証システムアクセス装置で実行される、公開鍵暗号を用いて電子署名通信や暗号通信を行う際に必要な、公開鍵証明証の取得や無効化確認を行うための認証システムアクセスプログラムであって、
　　コンピュータを、
　　公開鍵証明証の発行元の認証局毎に、利用可能な公開鍵証明証の取得及び無効化確認方式を、それぞれ優先順位を付けて定義した認証局（ＣＡ）別方式定義テーブルを作成する認証局（ＣＡ）別方式定義テーブル定義と、
　　前記公開鍵証明証の取得処理及び、無効化確認処理を行う際に、処理対象の公開鍵証明証を発行した発行元の認証局名の情報を取得する発行ＣＡ名取得部と、
　　前記認証局（ＣＡ）別方式定義テーブルを参照し、処理対象の公開鍵証明証の発行者認証局名に対応する公開鍵証明証の取得及び無効化確認方式を、優先順位に従って決定する処理方式決定部と、
　　前記処理方式決定部により決定された方式を用いて、前記処理対象の公開鍵証明証を取得する公開鍵証明証取得部と、
　　前記処理方式決定部により決定された方式を用いて、前記処理対象の公開鍵証明証の無効化の有無を確認する公開鍵証明証無効化確認部として機能させることを特徴とする認証システムアクセスプログラム。
　【請求項６】　認証システムアクセス装置上で実行される、公開鍵暗号を用いて電子署名通信や暗号通信を行う際に必要な、公開鍵証明証を取得する公開鍵証明証取得プログラムであって、
　　コンピュータを、
　　初期設定時に、公開鍵証明証の発行元の認証局毎に、利用可能な公開鍵証明証の取得方式を、それぞれ優先順位を付けて定義した認証局（ＣＡ）別方式定義テーブルを作成する認証局（ＣＡ）別方式テーブル定義部と、
　　公開鍵証明証の取得時に、処理対象の公開鍵証明証を発行した認証局名の情報を取得する発行者認証局（ＣＡ）名取得部と、
　　前記認証局（ＣＡ）別方式定義テーブルを参照し、処理対象の公開鍵証明証の発行認証局名に対応する公開鍵証明証の取得方式を優先順位に従って決定する処理方式決定部と、
　　前記処理方式決定部により決定された公開鍵証明証の取得方式を用いて、前記処理対象の公開鍵証明証を取得する公開鍵証明証取得部として機能させることを特徴とする公開鍵証明証取得プログラム。
　　【請求項７】　前記公開鍵証明証取得部は、公開鍵証明証の取得ができなかった場合に、前記決定された公開鍵証明証の取得方式の次の優先順位に相当する取得方式により、再度、公開鍵証明証の取得処理を行う手段を含む請求項６記載の公開鍵証明証取得プログラム。
　　【請求項８】　認証システムアクセス装置上で実行される、公開鍵暗号を用いて電子署名通信や暗号通信を行う際に必要な、公開鍵証明証無効化確認プログラムであって、
　　コンピュータを、
　　初期設定時に、公開鍵証明証の発行元の認証局毎に、利用可能な公開鍵証明証の無効化確認方式を、それぞれ優先順位を付けて定義した認証局（ＣＡ）別方式定義テーブルを作成する認証局（ＣＡ）別方式テーブル定義部と、
　　前記公開鍵証明証の無効化確認処理時に、処理対象の公開鍵証明証を発行した発行元の認証局名の情報を取得する発行者認証局（ＣＡ）名取得部と、
　　前記認証局（ＣＡ）別方式定義テーブルを参照し、処理対象の公開鍵証明証の発行認証局名に対応する公開鍵証明証の無効化確認方式を優先順位に従って決定する処理方式決定部と、
　　前記処理方式決定部により決定された前記公開鍵証明証の無効化確認方式を用いて、対象の公開鍵証明証の無効化の有無を確認する公開鍵証明証婿か確認部として機能させることを特徴とする公開鍵証明証無効化確認プログラム。
　　【請求項９】　認証システムアクセス装置で実行される、公開鍵暗号を用いて電子署名通信や暗号通信を行う際に必要な、公開鍵証明証の取得や無効化確認を行うための認証システムアクセスプログラムを格納した記憶媒体であって、
　　コンピュータを
　　公開鍵証明証の発行元の認証局毎に、利用可能な公開鍵証明証の取得及び無効化確認方式を、それぞれ優先順位を付けて定義した認証局（ＣＡ）別方式定義テーブルを作成する認証局（ＣＡ）別方式定義テーブル定義部と、
　　前記公開鍵証明証の取得処理及び無効化確認処理を行う際に、処理対象の公開鍵証明証を発行した発行元の認証局名の情報を取得する発行認証局（ＣＡ）名取得部と、
　　前記認証局（ＣＡ）別方式定義テーブルを参照し、処理対象の公開鍵証明証の発行者認証局名に対応する公開鍵証明証の取得及び無効化確認方式を、優先順位に従って決定する処理方式決定部と、
　　前記処理方式決定部により決定された方式を用いて、前記処理対象の公開鍵証明証を取得する公開鍵証明証取得部と、
　　前記処理方式決定部により決定された方式を用いて、前記処理対象の公開鍵証明証の無効化の有無を確認する公開鍵証明証無効化確認部として機能させるプログラムを格納したことを特徴とする認証システムアクセスプログラムを格納した記憶媒体。
　　【請求項１０】　認証システムアクセス装置上で実行される、公開鍵暗号を用いて電子署名通信や暗号通信を行う際に必要な、公開鍵証明証を取得する公開鍵証明証取得プログラムを格納した記憶媒体であって、
　　コンピュータを
　　初期設定時に、公開鍵証明証の発行元の認証局毎に、利用可能な公開鍵証明証の取得方式を、それぞれ優先順位を付けて定義した認証局（ＣＡ）別方式定義テーブルを作成する認証局（ＣＡ）別方式定義テーブル定義部と、
　　公開鍵証明証の取得時に、処理対象の公開鍵証明証を発行した認証局名の情報を取得する発行者認証局（ＣＡ）名取得部と、
　　前記認証局（ＣＡ）別方式定義テーブルを参照し、処理対象の公開鍵証明証の発行認証局名に対応する公開鍵証明証の取得方式を優先順位に従って決定する処理方式決定部と、
　　前記処理方式決定部により決定された公開鍵証明証の取得方式を用いて、前記対象の公開鍵証明証を取得する公開鍵証明証取得部として機能させるプログラムを格納したことを特徴とする公開鍵証明証取得プログラムを格納した記憶媒体。
　　【請求項１１】　前記公開鍵証明証取得部は、公開鍵証明証の取得ができなかった場合に、前記決定された公開鍵証明証の取得方式の次の優先順位に相当する取得方式により、再度、公開鍵証明証の取得処理を行う手段を含む請求項１０記載の公開鍵証明証取得プログラムを格納した記憶媒体。
　　【請求項１２】　認証システムアクセス装置上で実行される、公開鍵暗号を用いて電子署名通信や暗号通信を行う際に必要な、公開鍵証明証無効化確認プログラムを格納した記憶媒体であって、
　　コンピュータを
　　初期設定時に、公開鍵証明証の発行元の認証局毎に、利用可能な公開鍵証明証の無効化確認方式を、それぞれ優先順位を付けて定義した認証局（ＣＡ）別方式定義テーブルを作成する認証局（ＣＡ）別方式定義テーブル定義部と、
　　前記公開鍵証明証の無効化確認処理時に、処理対象の公開鍵証明証を発行した発行元の認証局名の情報を取得する発行者認証局（ＣＡ）名取得部と、
　　前記認証局（ＣＡ）別方式定義テーブルを参照し、処理対象の公開鍵証明証の発行認証局名に対応する公開鍵証明証の無効化確認方式を優先順位に従って決定する処理方式決定部と、
　　前記処理方式決定部により決定された前記公開鍵証明証の無効化確認方式を用いて、前記処理対象の公開鍵証明証の無効化の有無を確認する公開鍵証明証無効確認部として機能させるプログラムを格納したことを特徴とする公開鍵証明証無効化確認プログラムを格納した記憶媒体。」
　
４．原査定の拒絶理由
　原査定の拒絶理由の要旨は、請求項１に係る発明が、特開２０００−４９７６６号公報、及び特開平１０−２１５２４５号公報に記載された発明から当業者が容易に想到しえたものであるから、特許法第２９条第２項の規定により特許を受けることができない、というものである。
　
５．引用例
　上記原査定の拒絶理由で引用される特開平２０００−４９７６６号公報（以下、「引用例１」という。）には、図面と共に、以下の事項が記載されている。
　
「【００１２】図１は、本発明実施の一形態の鍵管理サーバシステムの構成を示すブロック図である。
【００１３】１は、ユーザの鍵管理等を行う鍵管理サーバであり、鍵管理テーブル２とアプリケーション管理テーブル３と複数のクライアント端末４を管理する。
【００１４】２は、鍵管理サーバ１が管理するユーザごとにアプリケーションとそのアプリケーション接続時の認証に用いるアプリケーション用の公開鍵証明書と秘密鍵の対応情報を格納している鍵管理テーブルであり、詳細を図３に示している。
【００１５】３は、各アプリケーションとの接続時の認証で用いる鍵の生成アルゴリズムと、当該アプリケーション用公開鍵証明書の発行を行うアプリケーションＣＡ８と、当該アプリケーションにアクセス可能なユーザ名を格納したアクセス可能ユーザリストファイルの情報を格納するアプリケーション管理テーブルであり、詳細を図４に示している。
【００１６】４はクライアント端末、５はクライアント端末４から読み込み可能なリムーバブルメディア、６は各種アプリケーションサーバである。
【００１７】７は、本鍵管理サーバシステムが信頼し、本鍵管理サーバシステムに登録されたユーザと鍵管理サーバ１間の通信の暗号化に用いる鍵管理サーバシステム用公開鍵証明書を発行する鍵管理サーバシステムＣＡである。
【００１８】８は、各アプリケーションサーバ６が接続時の認証で用いるアプリケーション用公開鍵証明書の発行を行うアプリケーションごとのアプリケーションＣＡであり、各アプリケーションサーバ６が指定したＣＡである。
【００１９】図２は本鍵管理サーバシステムでの、クライアント端末４と、鍵管理サーバ１と、アプリケーションサーバ６と、アプリケーションサーバ６が認証で用いるアプリケーション用公開鍵証明書の発行をするアプリケーションＣＡ８の間のデータのやりとりの概略を示すブロック図である。図２に基づいて、鍵管理サーバシステムの概略動作を次に説明する。
【００２０】ユーザがアプリケーションサーバ６との接続を要求するとき、クライアント端末４はまず鍵管理サーバ１と接続し、アプリケーションサーバ６との接続時の認証に必要なアプリケーション用の公開鍵証明書と秘密鍵を鍵管理サーバ１から取得し、それらを用いてアプリケーションサーバ６に接続して認証を受け、通信を行う。
【００２１】アプリケーションサーバ６はクライアント端末４から接続要求があると、クライアント端末４を使用しているユーザのアプリケーション用の公開鍵証明書と秘密鍵を用いて、ユーザを認証し、認証すれば、クライアント端末４と通信を開始する。
　
……（中略）……
　
【００２５】鍵管理サーバ１は、ユーザの使用するクライアント端末４からアプリケーションサーバ６への接続要求を受けて、当該アプリケーション接続時の認証に必要なアプリケーション用の公開鍵証明書と秘密鍵が鍵管理テーブル２に存在するかどうか調べる。存在するならば鍵管理テーブル２から取り出し、それらをクライアント端末４へ送信する。存在しなければ、アプリケーション管理テーブル３からアプリケーション用公開鍵証明書発行要求を送るアプリケーションＣＡ８を得て、もしアプリケーションＣＡ８が鍵生成を行わないなら鍵生成アルゴリズムから鍵を生成し、アプリケーションＣＡ８へアプリケーション用公開鍵証明書発行の要求を送り、アプリケーション用秘密鍵とアプリケーションＣＡ８から受け取ったアプリケーション用公開鍵証明書をユーザの鍵管理テーブル２へ登録し、この秘密鍵と公開鍵証明書をクライアント端末４へ送信する。
【００２６】なお、この鍵管理サーバ１とクライアント端末４の間の通信は、鍵管理サーバシステムＣＡ７から鍵管理サーバ１とユーザに対して発行される鍵管理サーバシステム用公開鍵証明書とその対となる鍵管理サーバシステム用秘密鍵を用いて暗号化されている。
【００２７】次に鍵管理テーブル２の構成を図３に示す。ユーザ一人につき一つこのテーブルが作成され、ユーザが接続を要求するアプリケーションサーバ６に応じて、その接続時の認証に必要となるアプリケーション用の公開鍵証明書と秘密鍵が取り出されるようになっている。また鍵管理テーブル２は鍵管理サーバ１の鍵管理サーバシステム用公開鍵で暗号化されている。
【００２８】次にアプリケーション管理テーブル３の構成を図４に示す。各アプリケーションサーバ６につき接続時の認証で必要なアプリケーション用公開鍵証明書を発行するアプリケーションＣＡ８と、アプリケーションＣＡ８が鍵生成を行わない場合に必要となる鍵生成アルゴリズムとアクセス可能なユーザ名を格納したアクセス可能ユーザリストファイルからなる。」
　
　この記載において、「アプリケーション管理テーブル」がどのように作成されるのかは明らかではないが、「アプリケーション管理テーブル」が処理に利用されている以上、何らかの手段によってこれが作成されていることは明らかである。
　してみると、引用例１には
　
　公開鍵証明書と秘密鍵を用いた通信を行う際に必要な、公開鍵証明書の受け取りを行うための鍵管理サーバシステムであって、
　各アプリケーションサーバにつき、必要なアプリケーション用公開鍵証明書を発行するアプリケーションＣＡと、アプリケーションＣＡが鍵生成を行わない場合に必要となる鍵生成アルゴリズムとを格納したアプリケーション管理テーブルを作成する手段と、
　アプリケーション管理テーブルを参照し、アプリケーション接続時の認証に必要な公開鍵証明書の発行要求を送るアプリケーションＣＡと、アプリケーションＣＡが鍵生成を行わない場合に必要となる鍵生成アルゴリズムをを得て、もしアプリケーションＣＡが鍵生成を行わないなら鍵生成アルゴリズムから鍵を生成し、アプリケーションＣＡへアプリケーション用公開鍵証明書発行の要求を送り、アプリケーションＣＡからアプリケーション用公開鍵証明書受け取る鍵管理サーバとを有することを特徴とする鍵管理サーバシステム。
　
に関する発明が開示されているものと認める。（以下、「引用例１記載の発明」という。）
　
６．対比
　本願請求項１に係る発明（以下、「本願発明」という。）と、引用例１記載の発明とを比較する。
　
　まず、引用例１記載の発明の「アプリケーションＣＡ」、「公開鍵証明書」は、それぞれ、本願発明の「認証局」、「公開鍵証明証」に対応する。
　そして、引用例１記載の発明の「鍵管理サーバシステム」は、「アプリケーションＣＡ」という認証システムに、公開鍵証明証発行の要求を送って、公開鍵証明証を受け取るという点で、認証システムへのアクセスをおこなっているから、本願発明でいう、「認証システムアクセス装置」であるといえる。
　
　次に、引用例１記載の発明の「公開鍵証明書と秘密鍵を用いた通信を行う」ことと、本願発明の「公開鍵暗号を用いて電子署名通信や暗号通信を行う」こととは、「公開鍵暗号を用いて通信を行う」という点で共通する。
　また、引用例１記載の発明の「受け取り」は、本願発明の「取得」に相当する。
　
　そして、引用例１記載の発明の「アプリケーションＣＡが鍵生成を行わない場合に必要となる鍵生成アルゴリズム」は、認証局から公開鍵証明証を受け取るための手順の一部となるものであるから、本願発明でいうところの、「利用可能な公開鍵証明証の取得」の「方式」に相当する。
　そして、引用例１記載の発明において、「各アプリケーションサーバにつき、必要なアプリケーション用公開鍵証明書を発行するアプリケーションＣＡと、アプリケーションＣＡが鍵生成を行わない場合に必要となる鍵生成アルゴリズムとを格納した」ことは、各アプリケーションサーバに対応して、「認証局」と「利用可能な公開鍵証明証の取得」の「方式」の対を格納したものと言えるから、引用例１記載の発明の「各アプリケーションサーバにつき、必要なアプリケーション用公開鍵証明書を発行するアプリケーションＣＡと、アプリケーションＣＡが鍵生成を行わない場合に必要となる鍵生成アルゴリズムとを格納した」ことと、本願発明の「公開鍵証明証の発行元の認証局毎に、利用可能な公開鍵証明証の取得及び無効化確認方式を、それぞれ優先順位を付けて定義した」こととは、「認証局と利用可能な公開鍵証明証の取得方式の対を格納した」ものである点で一致する。また、このような共通性を持つ点で、引用例１記載の発明の「アプリケーション管理テーブル」と、該アプリケーション管理テーブルを作成する「手段」は、それぞれ、本願発明の「認証局（ＣＡ）別方式定義テーブル」と、「認証局（ＣＡ）別方式定義テーブル定義手段」に対応する。
　
　また、引用例１記載の発明において「公開鍵証明書の発行要求を送るアプリケーションＣＡ」を得るとは、アプリケーションＣＡを特定する情報、即ち、本願発明でいうところの「認証局名」を得るものと解されるから、引用例１記載の発明において、「鍵管理サーバ」が、「アプリケーション接続時の認証に必要な公開鍵証明書の発行要求を送るアプリケーションＣＡ」を得ることと、本願発明の「発行認証局名取得手段」が、「前記公開鍵証明証の取得処理及び無効化確認処理を行う際に、処理対象の公開鍵証明証を発行した発行元の認証局名の情報を取得する」こととは、「認証局名の情報を取得する」点で一致する。また、このような共通性を持つ点で、引用例１記載の発明の「鍵管理サーバ」は、本願発明の「発行認証局名取得手段」に対応する構成を含むものである。
　
　また、引用例１記載の発明において、「鍵管理サーバ」が、「アプリケーション管理テーブルを参照し」、「アプリケーションＣＡが鍵生成を行わない場合に必要となる鍵生成アルゴリズムをを得」ることと、本願発明において、「処理方式決定手段」が、「認証局（ＣＡ）別方式定義テーブルを参照し、処理対象の公開鍵証明証の発行認証局名に対応する公開鍵証明証の取得及び無効化確認方式を、優先順位に従って決定する」こととは、「認証局（ＣＡ）別方式定義テーブルを参照し、公開証明証の取得方式を決定する」点で一致する。また、このような共通性を持つ点で、引用例１記載の発明の「鍵管理サーバ」は、本願発明の「処理方式決定手段」に対応する構成を含むものである。
　
　また、引用例１記載の発明において、「鍵管理サーバ」が、「もしアプリケーションＣＡが鍵生成を行わないなら鍵生成アルゴリズムから鍵を生成し、アプリケーションＣＡへアプリケーション用公開鍵証明書発行の要求を送り、アプリケーションＣＡからアプリケーション用公開鍵証明書受け取る」ことは、本願発明において、「公開鍵証明証取得手段」が、「処理方式決定手段により決定された方式を用いて、前記処理対象の公開鍵証明証を取得する」ことに対応する。よって、引用例１記載の発明の「鍵管理サーバ」は、本願発明の「公開鍵証明証取得手段」に対応する構成を含むものである。
　
　してみると、本願発明と引用例１記載の発明は、
　
　公開鍵暗号を用いて通信を行う際に必要な、公開鍵証明証の取得を行うための認証システムアクセス装置であって、
　認証局と利用可能な公開鍵証明証の取得方式の対を格納した認証局（ＣＡ）別方式定義テーブルを作成する認証局（ＣＡ）別方式定義テーブル定義手段と、
　認証局名の情報を取得する発行認証局名取得手段と、
　認証局（ＣＡ）別方式定義テーブルを参照し、公開証明証の取得方式を決定する処理方式決定手段と、
　処理方式決定手段により決定された方式を用いて、前記処理対象の公開鍵証明証を取得する公開鍵証明証取得手段
　とを有することを特徴とする認証システムアクセス装置。
　
である点で一致し、以下の点で相違している。
　
（相違点１）
　本願発明では、「公開鍵暗号を用いて電子署名通信や暗号通信」を行うものであるのに対し、引用例１記載の発明では、「公開鍵証明書と秘密鍵を用いた通信」がどのような通信であるのかが不明確で、「電子署名通信や暗号通信」にあたるのかが判然としない点。
（相違点２）
　本願発明では、「発行認証局名取得手段」が取得する認証局名が「処理対象の公開鍵証明証を発行した発行元の認証局」であり、既に発行された公開鍵証明書の認証局を取得すると解されるのに対し、引用例１記載の発明で「発行認証局名取得手段」が取得する認証局は、「もしアプリケーションＣＡが鍵生成を行わないなら鍵生成アルゴリズムから鍵を生成し、アプリケーションＣＡへアプリケーション用公開鍵証明書発行の要求を送り、アプリケーションＣＡからアプリケーション用公開鍵証明書受け取る」という記載から、新たに生成した鍵についての公開鍵証明証を発行する認証局であると解される点。
（相違点３）
　本願発明では、「認証局（ＣＡ）別方式定義テーブル」が「公開鍵証明証」の「無効化確認方式」を定義するものであり、「公開鍵証明証無効化確認手段」が、この「無効化確認方式」を用いて公開鍵証明書の無効化確認を行うものであり、さらに、「発行認証局名取得手段」、「処理方式決定手段」についても、それぞれ公開鍵証明証の無効化確認のための構成を有するのに対し、引用例１記載の発明では、「認証局（ＣＡ）別方式定義テーブル」が「公開鍵証明証」の「無効化確認方式」についての何ら情報を有さず、「公開鍵証明証無効化確認手段」も備えておらず、「発行認証局名取得手段」、「処理方式決定手段」についても、公開鍵証明証の無効化確認のための構成を有さず、その結果、公開鍵証明書の無効化確認を行っていない点。
（相違点４）
　本願発明では、「認証局（ＣＡ）別方式定義テーブル」が、「公開鍵証明証の取得」の「方式」について、「優先順位」をつけて定義したものであり、「処理方式決定手段」が、この「優先順位」に従って処理を行うものであるのに対し、引用例１記載の発明では、この「優先順位」について何ら開示がない点。
　
７．当審の判断
（相違点１）
　公開鍵暗号を使用した通信として、電子署名通信や暗号通信は本願出願前においても一般的なものであると認められ、引用例１記載の発明において、「公開鍵証明書と秘密鍵を用いた通信」を、「電子署名通信や暗号通信」とすることに格別の困難性は認められない。
（相違点２）
　新たに生成した鍵についての公開鍵証明書を発行する認証局名を取得することと、既に発行された公開鍵証明書の認証局名を取得することは、全く異なるものであり、原査定の拒絶理由で引用されるもう一つの引用例である、特開平１０−２１５２４５号公報に開示された技術、あるいはその他周知技術を検討しても、新たに生成した鍵についての公開鍵証明書を発行する認証局名を取得することに代えて、既に発行された公開鍵証明書の認証局名を取得するものとする動機付けがないから、引用例１記載の発明において、新たに生成した鍵についての公開鍵証明書を発行する認証局名を取得することに代えて、既に発行された公開鍵証明書の認証局名を取得することが、当業者にとって容易に想到しえたものとは認められない。
（相違点３）
　上記相違点２についての検討から明らかなように、引用例１記載の発明は、新たに生成した鍵についての公開鍵証明証を得るものであり、このことと、公開鍵証明証の無効化確認を行うこととは直接的な関連がない。また、原査定の拒絶理由で引用されるもう一つの引用例である、特開平１０−２１５２４５号公報に開示された技術、あるいは周知の公開鍵証明証の無効化確認方法を組み合わせたとしても、「認証局（ＣＡ）別方式定義テーブル」が「公開鍵証明証」の「無効化確認方法」を定義し、「公開鍵証明証無効化確認手段」が、この「無効化確認方式」を用いて公開鍵証明書の無効化確認を行うといった構成は、当業者にとって容易に想到しえたものとは認められない。
（相違点４）
　一般に、複数の処理に優先順位を定め、優先順位の高い処理に何らかの支障がある時に、次の優先順位の処理を選択するといったことは、慣用手段に過ぎないから、引用例１記載の発明において、「認証局（ＣＡ）別方式定義テーブル」が、「公開鍵証明証の取得」の「方式」について、「優先順位」をつけて定義し、「処理方式決定手段」が、この「優先順位」に従って処理を行うものとすることに格別の困難性は認められない。
　
　以上のとおりであるから、本願発明の相違点２，３についての構成は、当業者が容易に想到し得たものでなく、この構成により、本願発明は、「運用方針の異なる複数のＣＡから公開鍵証明証の発行を受けた利用者が混在する環境においても、公開鍵証明証を扱う利用者システムは、発行者の運営方針に応じた公開鍵証明証の取得方式や、無効化確認方式の違いを意識することなく、公開鍵証明証の取得及び無効化確認のための処理が可能な認証システムアクセス装置」（明細書【０００７】段落）を提供するという、特有の効果を奏するものである。
　
　なお、特許請求の範囲の他の請求項に係る発明についても、請求項２，３，６，７，１０，１１について上記相違点２と同様の点で、請求項４，８，１２について上記相違点３と同様の点で、請求項５，９について、上記相違点２，３と同様の点で、何れも当業者が容易に想到し得たものでなく、特有の効果を奏するものである。
　
８．まとめ
　したがって、本願については、原査定の拒絶理由を検討してもその理由によって拒絶すべきものとすることはできない。
　また、他に本願を拒絶すべき理由を発見しない。
　よって、結論のとおり審決する。