【事件の表示】
　特願２００５−１０２７９９「証明書検証装置及び方法並びに証明書検証サーバ」拒絶査定不服審判事件〔平成１８年１０月１９日出願公開、特開２００６−２８７４５５〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
その１．手続の経緯
　本願は、平成１７年３月３１日の出願であって、
　平成１８年４月１４日付けで審査請求がなされ、平成２１年１０月２０日付けで審査官により拒絶理由が通知され、これに対して同年１２月２４日付けで意見書が提出されると共に手続補正がなされ、平成２２年７月２３日付けで審査官により拒絶理由が通知され、これに対して同年９月２４日付けで意見書が提出されたが、同年１０月８日付けで審査官により拒絶査定がなされ、これに対して平成２３年１月１８日付けで審判請求がなされたものである。
　
その２．本願発明について
　本願の請求項１に係る発明は、平成２１年１２月２４日付けの手続補正により補正された特許請求の範囲の請求項１に記載された次のとおりのものである。（以下、これを「本願発明」という）
　
「電子署名されたデータの認証パスを構築して証明書の有効性検証を行なう際に、キャッシュ部から既に有効性を検証済みの認証パスである「検証済み認証パス」を検索し、
　キャッシュが存在している場合には、キャッシュされた前記検証済み認証パスを用い、
　キャッシュが存在していない場合には、認証局が発行した公開鍵証明書及び失効リストを登録して公開するディレクトリサーバを検索して、パス構築に必要な証明書を取得し、検索結果を前記検証済み認証パスとしてキャッシュすることを特徴とする証明書検証装置。」
　
その３．引用刊行物に記載の発明
　一方、原審が拒絶理由に引用した、本願の出願時点で既に公知である、
「羽根慎吾，藤城孝宏，橋本洋子，手塚悟，“Ｘ．５０９証明書の高速認証パス検証アルゴリズム”，情報処理学会研究報告，日本，社団法人情報処理学会，Vol.2005,No.33,2005-DPS-122,マルチメディア通信と分散処理，2005-CSEC-28,コンピュータセキュリティ,2005年　3月23日,p.55-60」（以下、「引用刊行物１」という）
　には、次の事項が記載されている。
　
Ａ．「２．３．証明書検証方法
証明書で作られた認証のチェーンを認証パスと呼び、相互認証方式においては認証のチェーンの検証を行うことで証明書の検証が行われる。この認証パスを構築して証明書の検証を行う例を図１に示す。証明書検証機能は、ＴＡからＥＥ証明書までの認証パスを構築し、検証を行っている。この例では、検証のために扱われる認証情報は相互認証証明書３枚と、ＣＲＬ／ＡＲＬ４枚を含めて全部で９つある。これらの証明書とＣＲＬ／ＡＲＬはそれぞれリポジトリと呼ばれるディレクトリサーバを検索して収集する。」（５６頁左欄末行〜右欄１２行）、
　
Ｂ．「２．４．サーバ方式
上記、相互認証方式における証明書の検証は処理が重く、クライアントが証明書を受け取るたびにすべての検証作業を行うことは負担になる。そのため、証明書の検証処理をサーバで行う方法が有効であると考えられ、プロトコルや検証方法７），８）の検討が行われている。このような証明書を検証するためのプロトコルには、日本政府におけるＯＣＳＰ９）の拡張を使ったプロトコル５）や、ＩＥＴＦで検討されているＳＣＶＰ１０）などがある。本報告において、証明書の検証処理を行うサーバを証明書検証サーバと呼び、研究の対象とした。」（５６頁右欄１３〜２６行）
　
Ｃ．「３．証明書検証の高速化
今回、以下の３つの手法により高速化を行った。
３．１．証明書のキャッシュによる高速化
証明書検証処理において、一度取得した証明書と失効情報をキャッシュすることで高速化する。従来の手法では、検証のたびにそれに必要な証明書と失効情報をディレクトリサーバにアクセスして取得していた。高速化した検証アルゴリズムでは、図１のように認証局の証明書や失効情報をキャッシュすることで、ディレクトリサーバヘのアクセスを減らし、高速化を図る。
・・・・（中略）・・・・
３．２．パスキャッシュによる高速化
一度構築した認証パスをキャッシュすることで高速化する。認証パスの構築は、証明書の記載内容をもとに行うが、最適化された手法がない。現状では、考えられるすべての証明書を収集し、それを用いて認証パスを構築する必要がある。そのため、認証パスの構築処理はサーバに負荷が大きいと予想され、図２のように一度構築した認証パスをサーバ上でキャッシュする。前記の証明書と失効情報のキャッシュに加え、認証パスをキャッシュすることでリクエストのたびに毎回行っていた認証パスの構築作業を簡略化し、高速化を図る。」（５７頁左欄６行〜右欄３行）
　
Ｄ．「４．高速化の評価方法
４．１．評価方法
３章で述べた処理能力の向上手法を評価するために、証明書検証サーバにアルゴリズムを組み込み、処理能力の測定をおこなった。測定項目は、証明書検証サーバの時間当たりの平均処理件数と、平均応答時間の測定であり、下に示す条件で行った。
４．１．１．証明書、ＣＲＬ、認証パスキャッシュの効果
おのおの同時処理数が５で５００回試行を行い、中間の約３００回をサンプルとして抽出して平均をとった。認証パスの長さは４で行った。
Ａ-１キャッシュ機能を用いずに証明書検証を行う
Ａ-２証明書とＣＲＬのキャッシュを行う
Ａ-３証明書、ＣＲＬ、認証パスのキャッシュを行う」（５８頁左欄１〜１８行）、
　
（あ）上記Ａの「証明書で作られた認証のチェーンを認証パスと呼び、相互認証方式においては認証のチェーンの検証を行うことで証明書の検証が行われる」、「証明書検証機能は、ＴＡからＥＥ証明書までの認証パスを構築し、検証を行っている」との記載、及び、上記Ｃの「認証パスの構築処理はサーバに負荷が大きいと予想され」との記載、並びに、上記Ｂの「証明書の検証処理をサーバで行う方法が有効である」との記載、及び、「証明書の検証処理を行うサーバを証明書検証サーバと呼び」との記載から、
　引用刊行物１には、
“証明書で作られた認証のチェーンである認証パスを構築し、前記証明書の検証を行う証明書検証サーバ”について記載されていることが読み取れる。
　
（い）上記Ｃの「証明書検証処理において、一度取得した証明書と失効情報をキャッシュすることで高速化する」、「一度構築した認証パスをサーバ上でキャッシュする」との記載、及び、上記Ｄの「Ａ-３証明書、ＣＲＬ、認証パスのキャッシュを行う」との記載から、
　引用刊行物１には、
“一度構築した認証パス、ＣＲＬ、証明書をサーバ上にキャッシュする”点が記載されていることが読み取れる。
　
（う）上記Ａの「証明書までの認証パスを構築し、検証を行っている。この例では、検証のために扱われる認証情報は相互認証証明書３枚と、ＣＲＬ／ＡＲＬ４枚を含めて全部で９つある。これらの証明書とＣＲＬ／ＡＲＬはそれぞれリポジトリと呼ばれるディレクトリサーバを検索して収集する」との記載、及び、上記Ｃの「従来の手法では、検証のたびにそれに必要な証明書と失効情報をディレクトリサーバにアクセスして取得していた。高速化した検証アルゴリズムでは、図１のように認証局の証明書や失効情報をキャッシュすることで、ディレクトリサーバヘのアクセスを減らし、高速化を図る」との記載、並びに、上記（い）において検討した事項から、
　引用刊行物１には、
“認証パスを構築し、検証を行う場合に、キャッシュされた一度構築した認証パスを検索して、それを用いて認証パスを構築する”点が記載されていることが読み取れる。
　
（え）上記（Ａ）〜（Ｄ）に引用した記載、及び、上記（あ）〜（う）で検討した事項、並びに、キャッシュに関する技術常識から、
　引用刊行物に記載の「証明書検証サーバ」は、「証明書」の「検証」を行うために必要な「認証パス」が、前記「証明書検証サーバ」にキャッシュされているか検索し、前記必要な「認証パス」が、キャッシュ上に存在する、即ち、キャッシュ上でヒットした場合には、前記「認証パス」を用いて、「認証パス」を構築し、無ければ、「リポジトリと読まれるディレクトリサーバを検索して収集」した「証明書」、「ＣＲＬ」から、「認証パス」を構築するものであることは明らかであるから、
　引用刊行物１には、
“証明書検証サーバは、前記証明書検証サーバに、認証パスが、キャッシュされている場合には、それを用い、キャッシュされていなければ、ディレクトリサーバを検索して、証明書、及び、ＣＲＬを取得して、認証パスを構築する”ことが記載されているものと認められる。
　
　以上（あ）〜（え）において検討した事項から、引用刊行物１には、次の発明（以下、「引用発明」という）が記載されているものと認める。
　
　証明書で作られた認証のチェーンである認証パスを構築し、前記証明書の検証を行う証明書検証サーバであって、
　前記証明書検証サーバは、認証パスを構築し、検証を行う場合に、キャッシュされた一度構築した認証パスを検索して、認証パスが、キャッシュされている場合には、それを用い、キャッシュされていなければ、ディレクトリサーバを検索して、証明書、及び、ＣＲＬを取得して、認証パスを構築し、
　一度構築した認証パス、ＣＲＬ、証明書を前記証明書検証サーバ上にキャッシュする、
　証明書検証サーバ。
　
その４．本願発明と引用発明との対比
　ここで、本願発明と引用発明とを対比する。
　
（イ）
　引用発明における「証明書」、「ＣＲＬ」、「認証パス」、「証明書検証サーバ」が、
　本願発明における「公開鍵証明書」、「失効リスト」、「電子署名されたデータの認証パス」、「証明書検証装置」に相当するので、
　引用発明における「証明書で作られた認証のチェーンである認証パスを構築し、前記証明書の検証を行う」ことが、
　本願発明における「電子署名されたデータの認証パスを構築して証明書の有効性検証を行なう」ことに相当し、
（ロ）引用発明においても、「証明証検証サーバ」上に、「ＣＲＬ」、「認証パス」等が「キャッシュ」されているのであるから、前記「証明書検証サーバ」が、「キャッシュ」するための「キャッシュ手段」を有することは明らかであり、該「キャッシュ手段」が、
　本願発明における「キャッシュ部」に相当するので、
　引用発明において、
「認証パスを構築し、検証を行う場合に、キャッシュされた一度構築した認証パスを検索」することも、
　本願発明において、
「キャッシュ部から既に有効性を検証済みの認証パスである「検証済み認証パス」を検索」することも、
“キャッシュ部から認証パスを検索”する点で共通し、
（ハ）引用発明における「認証パスが、キャッシュされている場合には、それを用い」と、
　本願発明における「キャッシュが存在している場合には、キャッシュされた前記検証済み認証パスを用い」とは、
“キャッシュが存在している場合には、キャッシュされた認証パスを用い”る点で共通し、
（ニ）引用発明においる「キャッシュされていなければ、ディレクトリサーバを検索して、証明書、及び、ＣＲＬを取得して、認証パスを構築し」が、
　本願発明における「キャッシュが存在していない場合には、認証局が発行した公開鍵証明書及び失効リストを登録して公開するディレクトリサーバを検索して、パス構築に必要な証明書を取得し」に相当し、
（ホ）引用発明において、「キャッシュ」されていない「認証パス」を「構築」するためには、「ディレクトリサーバを検索」するのであるから、
　引用発明における「一度構築した認証パス、ＣＲＬ、証明書を前記証明書検証サーバ上にキャッシュする」と、
　本願発明における「検索結果を前記検証済み認証パスとしてキャッシュする」とは、
「検索結果を認証パスとしてキャッシュする」点で共通する。
　
　よって、上記（イ）〜（ホ）で検討した事項から、本願発明と引用発明との一致点・相違点は、次のとおりである。
　
［一致点］
　電子署名されたデータの認証パスを構築して証明書の有効性検証を行なう際に、キャッシュ部から認証パスを検索し、
　キャッシュが存在している場合には、キャッシュされた認証パスを用い、
　キャッシュが存在していない場合には、認証局が発行した公開鍵証明書及び失効リストを登録して公開するディレクトリサーバを検索して、パス構築に必要な証明書を取得し、検索結果を認証パスとしてキャッシュすることを特徴とする証明書検証方法
　
［相違点］
　本願発明においては、「キャッシュ部」に「キャッシュ」されているのが、「既に有効性を検証済みの認証パスである「検証済み認証パス」」であるのに対して、
　引用発明においては、「証明書」、「ＣＲＬ」、及び、「一度構築した認証パス」である点、
　
その５．当審の判断
　次に、上記相違点について検討する。
　「検証済みの認証パス」を記憶する点については、原審が拒絶理由に引用した、本願の出願時点で既に公知である、特開２００２−０７２８７６号公報（平成１４年３月１２日公開、以下、「引用刊行物２」という）に、
　
Ｅ．「【００１６】すなわち、任意の認証局を起点認証局とし、当該起点認証局が発行した公開鍵証明書の発行先を調べ、当該発行先に認証局が含まれる場合は当該認証局が発行した公開鍵証明書の発行先をさらに調べる処理を、当該公開鍵証明書の発行先が全て端末となるまで続けることにより、前記起点認証局から任意の端末に対して公開鍵証明書を発行した端末収容認証局までのパスを検索するパス検索ステップと、前記パス検索ステップにより検出されたパスについて、前記起点認証局を上流とし、当該パス上の端末収容認証局が発行した公開鍵証明書の署名を１つ上流側の認証局が発行した公開鍵証明書で検証し、検証が成立した場合は当該１つ上流側の認証局が発行した公開鍵証明書の署名をさらに１つ上流側の認証局が発行した公開鍵証明書で検証する処理を、当該１つ上流側の認証局が前記起点認証局となるまで続けることにより、
当該パスを検証するパス検証ステップと、前記パス検証ステップにより検証が成立したパスをデータベースに登録する
【００１７】そして、
ある端末から、当該端末が信頼する認証局とは異なる端末収容認証局が発行した公開鍵証明書の有効性確認依頼があった場合に、前記端末が信頼する認証局と前記起点認証局との間のパス、および、前記異なる端末収容認証局と前記起点認証局との間のパスが、前記データベースに登録されているか否かを調べることで、前記公開鍵証明書の有効性を確認する
【００１８】本発明によれば、ある端末から公開鍵証明書の有効性確認依頼を受けた場合に、それから、上記の、に示した、当該端末のトラストアンカーから当該公開鍵証明書の発行元認証局までのパスの検索、および、検出したパスの検証を行う必要がない。したがって、公開鍵証明書の有効性確認を依頼してから、当該有効性が確認されるまでにかかる時間を短縮できる。」（下線は、当審が説明の都合上附加したものである。）
　
　と記載され、上記記載中の「パス」が、引用発明における「認証パス」に相当することは明らかであるから、上記引用の記載中の、
「パスを検証するパス検証ステップと、前記パス検証ステップにより検証が成立したパスをデータベースに登録する」、及び、
「前記データベースに登録されているか否かを調べることで、前記公開鍵証明書の有効性を確認する」から、
　上記引用の記載中の、「検証が成立したパス」とは、「検証済みの認証パス」を意味し、「パスをデータベースに登録する」ことは、即ち、“パスをデータベースに記憶する”ことに他ならないことを加味すれば、
“検証済みの認証パスを記憶し、該記憶された認証パスを用いて、証明書の有効性を確認する”ことは、本願の出願時点で当業者には公知の技術事項である。
　そして、引用発明も、引用刊行物２に記載の発明も、記憶されている「認証パス」を用いて、「証明書」の有効性を確認する技術である点で共通し、
　引用発明における「キャッシュする」ことも、“記憶する”ことを意味することは、当業者に自明の事項であるから、
　引用発明において、「キャッシュ」される「認証パス」として、「一度構築した認証パス」に替えて、「検証済みの認証パス」とすることは、当業者が適宜なし得たものである。
　よって、相違点は、格別のものでない。
　
　そして、本願発明の構成によってもたらされる効果も、引用発明、及び、引用刊行物２に記載の発明から当業者ならば容易に予測することができる程度のものであって、格別のものとはいえない。
　以上のとおりであるから、本願発明は、引用発明、及び、引用刊行物２に記載の発明から、当業者が容易になし得たものである。
　
その６．むすび
　したがって、本願発明は、本願の特許出願前に日本国内又は外国において頒布された刊行物に記載された発明に基づいて当業者が容易に発明をすることができたものであるので、特許法第２９条第２項の規定により特許を受けることができない。
　
　よって、結論のとおり審決する。