【事件の表示】
　特願２０１０−５１０９５３「ウェブページの真正性検証」拒絶査定不服審判事件〔平成２０年１２月１１日国際公開、ＷＯ２００８／１４９３３１、平成２２年　９月　２日国内公表、特表２０１０−５３００９７〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
第１．手続の経緯
 　 
　本件審判請求に係る出願（以下、「本願」という。）は、２００８年６月５日を国際出願日（パリ条約による優先権主張日；２００７年６月７日、米国）とする出願であって、平成２２年３月１７日付けで審査請求がなされ、平成２４年５月７日付けで拒絶理由通知（平成２４年５月１５日発送）がなされ、これに対して平成２４年１１月５日付けで意見書が提出されると共に同日付けで手続補正書が提出されたが、平成２４年１２月１８日付けで拒絶査定（平成２４年１２月２５日謄本送達）がなされたものである。
　本件審判請求は、これに対して、「原査定を取り消す、この出願の発明は特許をすべきものである、との審決を求める。」ことを請求の趣旨として平成２５年４月２３日付けで審判請求がなされたものであり、同日付けで手続補正書が提出され、平成２５年７月２３日付けで前置報告がされ、平成２５年１０月４日付け（平成２５年１０月８日発送）で審尋がなされ、平成２６年１月７日付けで回答がなされたものである。
　
第２．本願発明
 　 
　本願の請求項１に係る発明（以下、「本願発明」という。）は、平成２５年４月２３日付け手続補正により補正された特許請求の範囲の請求項１に記載された事項により特定される、以下のとおりのものである。
　
「情報プロバイダにより送信された情報の真正性を検証する方法であって、前記方法が、
　登録機関のコンピュータによって、複数の情報プロバイダの各プロバイダに発行された認証証明書と、前記認証証明書のすべてに対応するルート証明書とを含む証明書レジストリを作成し、前記認証証明書の各証明書が、該証明書のそれぞれの認証情報を、前記情報プロバイダの対応するプロバイダの識別情報に結び付け、前記認証証明書の各証明書が、前記情報プロバイダの対応するプロバイダと、該プロバイダのドメイン名情報との間のリンクを欠いており、さらに証明書レジストリの前記認証証明書が、前記情報プロバイダが提供する情報の特定のタイプ、前記情報プロバイダが関連している特定の組織、前記情報プロバイダが携わっている特定のタイプの職業、および前記情報プロバイダが位置している特定の地理的区域の少なくとも１つに少なくとも或る程度、依存する仕方で関連付けられること、
　情報受信者のコンピュータにルート証明書を提供すること、および
　情報受信者のコンピュータによってアクセスされ、さらに認証証明書が関連付けられているウェブページを情報受信者のコンピュータにより検証し、前記検証が、ルート証明書の中に含まれる認証情報を使用して、前記関連付けられた認証証明書の真正性を検証することに成功して、前記関連付けられた認証証明書が、証明書レジストリに属することを検証すること、および前記関連付けられた認証証明書の真正性を前記検証することに成功した後、前記関連付けられた認証証明書の中に含まれる認証情報を使用して、ウェブページの指定された所有者のＩＤを検証することに成功することを含む、方法。」
　
第３．引用文献記載事項
　
１．引用文献１
　原審の拒絶理由通知において引用された、本願の優先権主張日前に頒布又は電気通信回線を通じて公衆に利用可能となった文献である、特開２００３−３３８８１５号公報（以下、「引用文献１」という。）には、図面とともに、次の記載がある。 
 （当審注：下線は、参考のために当審で付与したものである。以下、同じ。） 
　
Ａ．「【０００７】
【発明が解決しようとする課題】しかしながら、上述した従来技術には、次のような問題点があった。
…（中略）…
【０００９】第２の問題点は、公開鍵証明書を用いていないため、不特定の者の認証ができず、それにより、予めユーザ登録された者の電子署名の検証や、予めユーザ登録された者の認証しか行うことができないということである。
【００１０】
本発明の目的は、ＨＴＭＬ文書とそのＨＴＭＬ文書に関連する外部データに対して一括して電子署名を施すことができるとともに、ユーザ登録されていない者の電子署名の検証やユーザ登録されていない者の認証を行うことができる電子署名システムおよび電子署名方法を提供することにある
【００１１】
【課題を解決するための手段】上記目的を達成するために本発明の電子署名システムは、
ＨＴＭＬ文書および当該ＨＴＭＬ文書に関連付けられた外部データに対して一括して電子署名を施した電子署名データを生成する電子署名データ生成手段
前記電子署名データをダウンロードし、ダウンロードした前記電子署名データの有効性を検証する
…（中略）…
【００１４】また、前記電子署名データ生成手段は、電子署名者の公開鍵証明書を含む鍵情報を前記電子署名データ中にさらに記述し、前記電子署名データ検証手段は、前記ＨＴＭＬ文書および当該ＨＴＭＬ文書に関連付けられた前記外部データの改竄検出を行う際に、前記電子署名データ中に記述された前記鍵情報に前記公開鍵証明書が含まれている場合、当該公開鍵証明書の有効性を検証することにより前記電子署名者の認証を行うこととしても良い。
…（中略）…
【００２４】（作用）上記のように構成された本発明においては、ＨＴＭＬ文書とその関連の外部データに対して一括して電子署名を施した電子署名データを作成し、その
電子署名データの有効性を検証することによりＨＴＭＬ文書とその関連の外部データの改竄検出を一括して行う。さらに、電子署名データ中に記述された鍵情報に公開鍵証明書が含まれている場合、該公開鍵証明書の有効性を検証することにより電子署名者の認証を行う
【００２５】これにより、ＨＴＭＬ文書とその関連の外部データに対するデータ完全性の保証、ＨＴＭＬ文書とその関連の外部データの作成者の認証、当該作成者による否認の防止、および、ＨＴＭＬ文書とその関連の外部データに対するアクセス制御を実現することが可能となる。」
　
Ｂ．「【００４６】次に、
クライアント計算機２側で行われる電子署名検証処理動作
【００４７】まず、
Ｗｅｂブラウザ２０は、クライアントに指示されたＨＴＭＬ文書１００をサーバ計算機１からダウンロードする
ＨＴＭＬ文書１００中に外部データ識別情報１０１が記述されている場合は、その外部データ識別情報１０１に対応する外部データ１１０をＨＴＭＬ文書１００と共にダウンロードする
【００４８】次に、
Ｗｅｂブラウザ２０は、ＨＴＭＬ文書１００中に電子署名データ識別情報１０２が記述されているかを確認する
【００４９】次に、
Ｗｅｂブラウザ２０は、ＨＴＭＬ文書１００中の外部データ識別情報１０１、電子署名データ識別情報１０２、および、ＨＴＭＬ文書１００自体の識別情報を併せて、電子署名データ検証部２１に渡し、電子署名の検証処理を行わせる
【００５０】次に、
電子署名データ検証部２１は、電子署名データ識別情報１０２を元に電子署名データ１２０をサーバ計算機１からダウンロードする
【００５１】次に、
電子署名データ検証部２１は、電子署名データ１２０中のＨＴＭＬ文書ＵＲＬ情報１２１とＨＴＭＬ文書自体の識別情報とが等しく整合性があるかを確認する
【００５２】次に、
電子署名データ検証部２１は、ＨＴＭＬ文書自体の識別情報を元にサーバ計算機１からダウンロードしたＨＴＭＬ文書１００のハッシュ値を計算し、電子署名データ１２０中に記述されているＨＴＭＬ文書ハッシュ値１２２と等しいかを確認する
等しくない場合は検証失敗
【００５３】次に、
電子署名データ検証部２１は、外部データ識別情報１０１を元にサーバ計算機１からダウンロードした各外部データ１１０のハッシュ値を計算し、電子署名データ１２０中に記述されている外部データハッシュ値１２４と等しいかを確認する
等しくない場合は検証失敗
【００５４】次に、
電子署名データ検証部２１は、電子署名データ１２０中のＨＴＭＬ文書ＵＲＬ情報１２１、ＨＴＭＬ文書ハッシュ値１２２、外部データＵＲＬ情報１２３、外部データハッシュ値１２４、および、鍵情報１２５の全てに対してハッシュ計算を行い得られたハッシュ値と、鍵情報１２５に対応する公開鍵を用いて電子署名値１２６を復号して得られた結果とが等しいかを確認する
等しくない場合は検証失敗
【００５５】次に、
電子署名データ検証部２１は、電子署名データ１２０中の鍵情報１２５が電子署名者の公開鍵証明書を含んでいるかを確認する
【００５６】最後に、
電子署名データ検証部２１は、電子署名データ１２０中の鍵情報１２５に含まれている公開鍵証明書の有効性を検証する
検証に成功した場合、電子署名検証成功、および、電子署名者の認証成功として処理を終了する。
【００５７】以下に、図１に示した電子署名システムにおける電子署名処理に関する動作について、具体例を挙げて図４を参照して説明する。
【００５８】まず、電子署名者により電子署名データ生成部１３に電子署名計算対象のＨＴＭＬ文書１００のＵＲＬが入力される。
【００５９】電子署名データ生成部１３は、ＨＴＭＬ文書１００および外部データ１１０を元に、電子署名データ１２０を生成する。この電子署名データ１２０は、ＨＴＭＬ文書１００および外部データ１１０と共にサーバ計算機１上に保存される。
【００６０】Ｗｅｂブラウザ２０は、クライアント計算機１のクライアントの要求に応じてサーバ計算機１からＨＴＭＬ文書１００をダウンロードし、ＨＴＭＬ文書１００中のＨＴＭＬ文書１００中の外部データ識別情報１０１、電子署名データ識別情報１０２、および、ＨＴＭＬ文書１００自体の識別情報を電子署名データ検証部２１に渡す。
【００６１】電子署名データ検証部２１は、Ｗｅｂブラウザ２０から渡された情報を元に電子署名の検証を行い、ＨＴＭＬ文書１００の電子署名の有効性の合否、および、鍵情報１２５に電子署名者の公開鍵証明書が含まれていた場合にはその公開鍵証明書の有効性の合否を判定し、その判定結果をＷｅｂブラウザ２０に通知する。
【００６２】これにより、外部データ１１０、電子署名データ１２０を含むＨＴＭＬ文書１００の改竄の検出と、電子署名者の認証を実現することができる。」
　
　引用文献１に記載された事項を検討する。
（Ａ）Ａ．の「電子署名データ生成手段」は、図１、図４に記載されたサーバ計算機の電子署名データ生成部１３のことであり、「前記電子署名データをダウンロードし、ダウンロードした前記電子署名データの有効性を検証する」電子署名検証処理動作は、Ｂ．の「クライアント計算機２側で行われる」処理であり、前記サーバ計算機の電子署名データ生成部１３とクライアント計算機２との関係は、図１、図４にも示されている。検証についてＡ．の「電子署名データの有効性を検証することによりＨＴＭＬ文書とその関連の外部データの改竄検出を一括して行う。さらに、電子署名データ中に記述された鍵情報に公開鍵証明書が含まれている場合、該公開鍵証明書の有効性を検証することにより電子署名者の認証を行う」との記載から、「電子署名データの有効性を検証することによりＨＴＭＬ文書とその関連の外部データの改竄検出を一括して行い、さらに、電子署名データ中に記述された鍵情報に公開鍵証明書が含まれている場合、該公開鍵証明書の有効性を検証することにより電子署名者の認証を行う方法」をよみとることができる。
　
（Ｂ）前記（Ａ）で言及した「電子署名データの有効性を検証することによりＨＴＭＬ文書とその関連の外部データの改竄検出を一括して行い、さらに、電子署名データ中に記述された鍵情報に公開鍵証明書が含まれている場合、該公開鍵証明書の有効性を検証することにより電子署名者の認証を行う方法」と、Ｂ．の下線部（当審付与の
　
　Ｗｅｂブラウザは、クライアントに指示されたＨＴＭＬ文書をサーバ計算機からダウンロードするとともにＨＴＭＬ文書中に外部データ識別情報が記述されている場合は、対応する外部データを前記ＨＴＭＬ文書と共にダウンロードし、
　Ｗｅｂブラウザは、ＨＴＭＬ文書中に電子署名データ識別情報が記述されているかを確認して、ＨＴＭＬ文書中の外部データ識別情報、電子署名データ識別情報、および、ＨＴＭＬ文書自体の識別情報を併せて、電子署名データ検証部に渡し、
　電子署名データ検証部は、電子署名データ識別情報を元に電子署名データをサーバ計算機からダウンロードし、電子署名データ中のＨＴＭＬ文書ＵＲＬ情報とＨＴＭＬ文書自体の識別情報とが等しく整合性があるか確認して検証し、
　ＨＴＭＬ文書自体の識別情報を元にサーバ計算機からダウンロードしたＨＴＭＬ文書のハッシュ値を計算し、電子署名データ中に記述されているＨＴＭＬ文書ハッシュ値と等しいかを確認して検証し、
　外部データ識別情報を元にサーバ計算機からダウンロードした各外部データのハッシュ値を計算し、電子署名データ中に記述されている外部データハッシュ値と等しいかを確認して検証し、
　電子署名データ中のＨＴＭＬ文書ＵＲＬ情報、ＨＴＭＬ文書ハッシュ値、外部データＵＲＬ情報、外部データハッシュ値、および、鍵情報の全てに対してハッシュ計算を行い得られたハッシュ値と、鍵情報に対応する公開鍵を用いて電子署名値を復号して得られた結果とが等しいかを確認して検証し、電子署名データ中の鍵情報が電子署名者の公開鍵証明書を含んでいると、電子署名データ中の鍵情報に含まれている公開鍵証明書の有効性を検証し、検証に成功した場合、電子署名検証成功、および、電子署名者の認証成功として処理を終了する、クライアント計算機側で行われる電子署名検証処理」がよみとれる。
　よって、引用文献１には、Ａ．の段落【００１０】に記載された目的、即ち、ＨＴＭＬ文書とそのＨＴＭＬ文書に関連する外部データに対して一括して電子署名を施すことができるとともに、ユーザ登録されていない者の電子署名の検証やユーザ登録されていない者の認証を行うことができる電子署名方法を提供すること、を目的とした次の発明（以下「引用文献１発明」という。）が示されている。
　
「電子署名データの有効性を検証することによりＨＴＭＬ文書とその関連の外部データの改竄検出を一括して行い、さらに、電子署名データ中に記述された鍵情報に公開鍵証明書が含まれている場合、該公開鍵証明書の有効性を検証することにより電子署名者の認証を行う方法であって、
　Ｗｅｂブラウザは、クライアントに指示されたＨＴＭＬ文書をサーバ計算機からダウンロードするとともにＨＴＭＬ文書中に外部データ識別情報が記述されている場合は、対応する外部データを前記ＨＴＭＬ文書と共にダウンロードし、
　Ｗｅｂブラウザは、ＨＴＭＬ文書中に電子署名データ識別情報が記述されているかを確認して、ＨＴＭＬ文書中の外部データ識別情報、電子署名データ識別情報、および、ＨＴＭＬ文書自体の識別情報を併せて、電子署名データ検証部に渡し、
　電子署名データ検証部は、電子署名データ識別情報を元に電子署名データをサーバ計算機からダウンロードし、電子署名データ中のＨＴＭＬ文書ＵＲＬ情報とＨＴＭＬ文書自体の識別情報とが等しく整合性があるか確認して検証し、
　ＨＴＭＬ文書自体の識別情報を元にサーバ計算機からダウンロードしたＨＴＭＬ文書のハッシュ値を計算し、電子署名データ中に記述されているＨＴＭＬ文書ハッシュ値と等しいかを確認して検証し、
　外部データ識別情報を元にサーバ計算機からダウンロードした各外部データのハッシュ値を計算し、電子署名データ中に記述されている外部データハッシュ値と等しいかを確認して検証し、
　電子署名データ中のＨＴＭＬ文書ＵＲＬ情報、ＨＴＭＬ文書ハッシュ値、外部データＵＲＬ情報、外部データハッシュ値、および、鍵情報の全てに対してハッシュ計算を行い得られたハッシュ値と、鍵情報に対応する公開鍵を用いて電子署名値を復号して得られた結果とが等しいかを確認して検証し、電子署名データ中の鍵情報が電子署名者の公開鍵証明書を含んでいると、電子署名データ中の鍵情報に含まれている公開鍵証明書の有効性を検証し、検証に成功した場合、電子署名検証成功、および、電子署名者の認証成功として処理を終了する、クライアント計算機側で行われる電子署名検証処理を含む、方法。」
　
２．引用文献２
　原審の拒絶理由において引用された、本願の優先権主張日前に頒布又は電気通信回線を通じて公衆に利用可能となった文献である、浅野昌和，ＰＫＩ基礎講座　第２回　電子証明書と認証局，@IT Master of IP Network，アイティメディア株式会社，［ｏｎｌｉｎｅ］，２０００年１１月２１日，［平成２４年５月２日検索］ＵＲＬ，http://www.atmarkit.co.jp/fnetwork/rensai/pki02/pki01.htmlには、関連する画面１〜画面５、図１〜図２とともに、次の記載がある。
　
「電子証明書は実世界における印鑑証明書にたとえられることが多い（図１）。印鑑証明書の目的は自治体がその印鑑の持ち主を証明することだ。
　
印鑑証明書の内容は、
　
１．登録された印鑑の印影
２．その印鑑の持ち主の情報
３．印鑑証明書を発行した自治体名
４．その自治体の印
　
といったものだろう。
　
この
「登録された印鑑」を「公開鍵」に、「発行自治体」を「認証局」に読み替えたものが電子証明書
電子証明書
　
１．登録された公開鍵
２．その公開鍵の持ち主の情報
３．証明書を発行した認証局の情報
４．発行元認証局の署名
　…（中略）…
【コラム】Ｘ．５０９証明書フォーマット
　
　Ｘ．５０９の証明書フォーマットは、現在バージョン３となっている。バージョン２でいくつかの拡張項目が設けられ、さらにバージョン３では任意の拡張情報が埋め込めるようになっている。
　
●バージョン１項目（必須）
バージョン情報（ｖｅｒｓｉｏｎ）
シリアル番号（ｓｅｒｉａｌＮｕｍｂｅｒ）
署名アルゴリズム情報（ｓｉｇｎａｔｕｒｅ．ａｌｇｏｒｉｔｈｍＩｄｅｎｔｉｆｉｅｒ）
発行認証局名（ｉｓｓｕｅｒ）
有効期限（ｖａｌｉｄｉｔｙ）
被発行者名（ｓｕｂｊｅｃｔ）
公開鍵情報（ｓｕｂｊｅｃｔＰｕｂｌｉｃＫｅｙＩｎｆｏ）
　
●バージョン２項目（任意）
認証局のオブジェクトＩＤ（ｉｓｓｕｅｒＵｎｉｑｕｅＩＤ）
被発行者のオブジェクトＩＤ（ｓｕｂｊｅｃｔＵｎｉｑｕｅＩＤ）
　
●バージョン３項目（任意）
鍵の利用目的（ＫｅｙＵｓａｇｅ）
証明書ポリシー（ｃｅｒｔｉｆｉｃａｔｅＰｏｌｉｃｉｅｓ）
…（中略）…
　公開鍵暗号方式の場合、公開鍵はどのような方法で配布してもよく、だれが知っていても問題はない。ただ、公開鍵で暗号化されたものは、ここで１つ問題がある。…（中略）…公開鍵を受け取ったとする。しかし、その公開鍵を送ってきたのが本当にＢさんであるかどうかを検証することができないのである。…（中略）…そこで、ＡさんとＢさんの双方が信頼できる認証局から証明書を発行してもらい、それをもってＡさんが受け取った公開鍵が本当にＢさんのものであることを証明するのである。
　
　ここで重要なのは「ＡさんとＢさんがともに認証局を信頼できること」である。
…（中略）…
「信頼の基盤」として認証局が行わなければならないことは非常に多い。
　
　例えば、証明書には認証局の署名がされている…（中略）…第三者に成りすましたものへの証明書の発行を行わないよう、十分な本人確認も必要だし、…（中略）…
　
　このような認証局運用のガイドラインというものがいくつかあるが、日本では
電子商取引推進協議会（ＥＣＯＭ）
…（中略）…
ということは
認証局の証明書
　
　これには以下の２つの方法がある。
　
１．その認証局が自分で発行する
２．さらに上位の認証局が存在し、その認証局が発行する
　
　上記２の場合でも、結局その根本をたどっていくと１の方式で証明書を発行した認証局が存在する。このような
認証局を「ルート（Ｒｏｏｔ）認証局」という。そのような認証局の証明書には、その認証局自身の署名がされている
…（中略）…
　ルート認証局と信頼のモデル
　
　話を証明書の階層に戻そう。図２を見てほしい。
ＡさんがＳｕｂ１、ＢさんがＳｕｂ２という異なる２つの認証局から証明書の発行を受けていたとしよう。そして、この２つの認証局は、同じｒｏｏｔという認証局から認証されている（証明書を発行されている）とすると、ＡさんもＢさんもｒｏｏｔ認証局を信頼している必要がある
…（中略）…
　では
ＡさんがＢさんから証明書（公開鍵）を受け取ったら、Ａさんはどのようにしてこれを検証していけばよいのだろうか。まず、ＡさんはＢさんの証明書のほかにＳｕｂ２認証局の証明書を受け取らなければならない。そして、Ｓｕｂ２認証局の証明書が自分の信頼するｒｏｏｔ認証局から発行されていることをＳｕｂ２認証局の証明書の署名を検証することで確認し、さらにＢさんの証明書が確かにＳｕｂ２認証局から発行されたものであることを、Ｂさんの証明書に付いている署名を検証して確認するのである。
　
　引用文献２には、「電子証明書」の中身に「１．登録された公開鍵、２．その公開鍵の持ち主の情報、３．証明書を発行した認証局の情報、４．発行元認証局の署名」が含まれること、具体的には「【コラム】Ｘ．５０９証明書フォーマット」に、証明書の中に被発行者名(subject)（「情報プロバイダの対応するプロバイダの識別情報」に相当）と公開鍵情報(subjectPublicKeyInfo)（本願発明における「認証情報」に相当）とが存在し、これらの存在からみて、公開鍵情報を、被発行者名に結び付けることが示されていると共に、当該証明書には被発行者のドメイン名情報を含んでいないことから、被発行者と、該被発行者のドメイン名情報との間のリンクを欠いているとみることができる。また、認証局自身の署名がされている「ルート（Ｒｏｏｔ）認証局」の証明書（「ルート証明書」）と、「ＡさんがＳｕｂ１、ＢさんがＳｕｂ２という異なる２つの認証局から証明書の発行を受けていたとしよう。そして、この２つの認証局は、同じｒｏｏｔという認証局から認証されている（証明書を発行されている）とすると、ＡさんもＢさんもｒｏｏｔ認証局を信頼している必要がある。」「ではＡさんがＢさんから証明書（公開鍵）を受け取ったら、Ａさんはどのようにしてこれを検証していけばよいのだろうか。まず、ＡさんはＢさんの証明書のほかにＳｕｂ２認証局の証明書を受け取らなければならない。そして、Ｓｕｂ２認証局の証明書が自分の信頼するｒｏｏｔ認証局から発行されていることをＳｕｂ２認証局の証明書の署名を検証することで確認し、さらにＢさんの証明書が確かにＳｕｂ２認証局から発行されたものであることを、Ｂさんの証明書に付いている署名を検証して確認するのである。」との記載から、「発行された認証証明書（電子証明書）と、前記認証証明書のすべてに対応するルート証明書（ルート（Ｒｏｏｔ）認証局の証明書）とを含む証明書レジストリ（ＣＡ；認証局）を作成し、前記認証証明書（電子証明書）の各証明書が、該証明書のそれぞれの認証情報（電子証明書の中身の情報、例えば、登録された公開鍵）を、識別情報（登録された公開鍵、その公開鍵の持ち主の情報、証明書を発行した認証局の情報）に結び付け、前記認証証明書の各証明書が、ドメイン名情報との間のリンクを欠いており（当該証明書にはドメイン名情報を含んでいない）」、に相当する事項が示されている。
３．引用文献３
　原審において、電子署名技術分野における常識的・基礎的な事項（周知技術）を示すために引用された、本願の優先権主張日前に頒布又は電気通信回線を通じて公衆に利用可能となった文献である電子商取引推進協議会（ＥＣＯＭ）　認証・公証ＷＧ「証明書利用形態に関する考察」２００２年３月発行，p.1-p.24，（ＵＲＬ，http://www.jipdec.or.jp/archives/ecom/results/h13seika/h13results-07.pdf）には、関連する図とともに、次の記載がある。
　
「１．２．１．２　ネット社会における例
　ＩＤ、および属性情報のネット社会における例としては、次のような情報、証明書が挙げられる。
（１）ＩＤ
　
ＩＤの例としては、秘密鍵の対となる公開鍵を含む証明書
（２）属性情報
　
属性情報としては、発行者情報、所有者情報、および有効期限
…（中略）…
１．２．２．２　個別証明書の世界
　
各発行機関（サービス提供会社）は個人に対して一枚しか発行しないが、利用者一人に同種の証明書が結果的に複数枚発行される
利用するサービスごとにユニークに個人を特定できるＩＤを含む証明書
　
１．２．２．３　マルチ証明書の世界
　一人に複数枚発行されるが、それぞれの証明書が通用する領域が異なる世界で、一枚の証明書で複数のサービスが利用できる。
　
クローズドな世界（国、地域、業界、特定の世界）の中で、ユニークに個人を特定できるＩＤを含む証明書
…（中略）…
３．２．２　個別証明書世界モデル
　…（中略）…
（３）認証局と登録機関
　サービス・アプリケーション毎に認証局が存在し、認証機関と登録機関が分離されていない。
　…（中略）…
３．３．１　マルチ証明書について
（１）定義
　閉じた世界（国、地域、業界、あるいは個人が決めた特定の世界であっても良い）の中で、ユニークに個人を特定できるＩＤを含む証明書。
…（中略）…
（４）発行審査
　トレーサビリティを確保するための厳密な本人性確認手段は必要となる。証明書の記載事項になる属性情報の確認のため属性を証明する公的文書の提示が求められる。
…（中略）…
３．３．２　マルチ証明書世界モデル
（１）定義および特徴
　シングル証明書の世界と個別証明書の世界の中間解。利用者は行政・業界（マーケットプレイス）毎に発行された証明書を何枚か使い分ける。
…（中略）…
（３）認証局と登録機関
　認証局は業界毎に１つ存在し、その認証局に対応する登録機関が複数存在する。
…（中略）…
リポジトリへの登録およびサービスからの検証を受付ける登録機関が存在する。
…（中略）…
サービス利用窓口は提示された
マルチ証明書が登録されているか登録機関に検証依頼を行う
」（６頁３行〜２１頁３行）
　
　引用文献３の「認証局と登録機関」が電子商取引のためにコンピュータを用いるものであることは電子商取引推進協議会（ＥＣＯＭ）が発表している「認証局運用ガイドライン」に関することから明らかであり、「リポジトリへの登録」は当該登録とは「証明書が登録されているか登録機関に検証依頼を行う」などの記載から「証明書」が「登録」された登録機関のレジストリ（例えば、データベース）などのレジストリであり、これらから「登録機関のコンピュータ」「証明書レジストリ」がよみとれる。
　また、「ＩＤの例としては、秘密鍵の対となる公開鍵を含む証明書」「属性情報としては、発行者情報、所有者情報、および有効期限等」との記載から、「証明書のそれぞれの認証情報（公開鍵など）を、」「識別情報（所有者情報、ＩＤ）に結び付け」をよみとることができる。また、「各発行機関（サービス提供会社）は個人に対して一枚しか発行しないが、利用者一人に同種の証明書が結果的に複数枚発行される世界で、」「利用するサービスごとにユニークに個人を特定できるＩＤを含む証明書」、「閉じた世界（国、地域、業界、あるいは個人が決めた特定の世界であっても良い）のなかで、ユニークに個人を特定できるＩＤを含む証明書」との記載から「複数の」情報プロバイダ（サービス提供会社など）、「それぞれの」証明書（認証情報）をよみとることができ、ドメイン名情報との間のリンクが記載されていないことから「ドメイン名情報との間のリンクを欠いており」をよみとることができ、さらに、前記「各発行機関（サービス提供会社）」「閉じた世界（国、地域、業界、あるいは個人が決めた特定の世界」との記載から「さらに証明書レジストリの前記認証証明書が、前記情報プロバイダが提供する情報の特定のタイプ、前記情報プロバイダが関連している特定の組織、前記情報プロバイダが携わっている特定のタイプの職業、および前記情報プロバイダが位置している特定の地理的区域の少なくとも１つに少なくとも或る程度、依存する仕方で関連付けられること」 をよみとることができる。また、「 マルチ証明書が登録されているか登録機関に検証依頼を行う 」との記載から「認証証明書が、証明書レジストリに属することを検証すること」をよみとることができる。
　
第４．対比
　
１．引用文献１発明の「クライアントに指示されたＨＴＭＬ文書を」「ダウンロードする」「サーバ計算機」は本願発明の「情報プロバイダ」に相当し、引用文献１発明の「電子署名データの有効性を検証すること」、「公開鍵証明書の有効性を検証すること」において当該「有効性を検証すること」は本願発明の「情報の真正性を検証する」ことと実質的な差異はない。この点を加味すれば、引用文献１発明の「ＨＴＭＬ文書をダウンロードする」「サーバ計算機」および「電子署名データの有効性を検証することによりＨＴＭＬ文書とその関連の外部データの改竄検出を一括して行い、さらに、電子署名データ中に記述された鍵情報に公開鍵証明書が含まれている場合、該公開鍵証明書の有効性を検証することにより電子署名者の認証を行う方法」と本願発明の「情報プロバイダにより送信された情報の真正性を検証する方法」とに実質的な差異はない。
　
２．引用文献１発明の「公開鍵証明書」はクライアントに指示された「ＨＴＭＬ文書を」「ダウンロードする」「サーバ計算機」に（対して通常、認証局により）発行された証明書であり、証明書中に「公開鍵」や「被発行者名」等の情報を有することは慣用のものである（必要なら、引用文献２の「【コラム】Ｘ．５０９証明書フォーマット」に、被発行者名(subject)（「情報プロバイダの対応するプロバイダの識別情報」に相当）と公開鍵情報(subjectPublicKeyInfo)（「認証情報」に相当）参照）。認証局に関し「登録機関」「レジストリ」も慣用のものであり「登録機関のコンピュータ」を用いることは慣用のものである。これらの点をふまえると、引用文献１発明と本願発明とは「登録機関のコンピュータによって、情報プロバイダのプロバイダに発行された認証証明書と、前記認証証明書を含む証明書レジストリを作成」する点で共通する。
　
３．引用文献１発明のＷｅｂブラウザと電子署名データ検証部を有する「クライアント計算機」は本願発明の「情報受信者のコンピュータ」に相当し、引用文献１発明の電子署名者の認証に用いられる「電子署名者の公開鍵証明書（単に「公開鍵証明書」ということがある。）」、および、ＷｅｂブラウザがＨＴＭＬ文書自体の識別情報を元にサーバ計算機からダウンロードした「ＨＴＭＬ文書」と「その関連の外部データ」は、それぞれ本願発明の「認証証明書」、および「ウェブページ」に相当する。また、前記「ＨＴＭＬ文書」と「公開鍵証明書」は、引用文献１発明の全体を構成する部分であり前記「ＨＴＭＬ文書」のダウンロードに付随して前記「公開鍵証明書」の有効性が検証されることから前記ダウンロードした「ＨＴＭＬ文書」と「公開鍵証明書」とは「関連している」といえる。また、「公開鍵証明書」の真正性を検証することに成功すれば、当該「公開鍵証明書」の中に含まれる情報（例えば、公開鍵）は検証された認証情報とみることができると共に（公開鍵のような認証情報に含まれる情報が）使用できることは技術常識であり、引用文献１発明の「電子署名検証成功、および、電子署名者の認証成功」と本願発明の「ウェブページの指定された所有者のＩＤを検証」とは上位概念ではソース（持ち主）の検証とみることができる。してみれば、引用文献１発明の「電子署名データ検証部は、」「ＨＴＭＬ文書自体の識別情報を元にサーバ計算機からダウンロードしたＨＴＭＬ文書のハッシュ値を計算し、電子署名データ中に記述されているＨＴＭＬ文書ハッシュ値と等しいかを確認して検証し、」「電子署名データ中の」「ＨＴＭＬ文書ハッシュ値、」「外部データハッシュ値」、「および、鍵情報の全てに対してハッシュ計算を行い得られたハッシュ値と、鍵情報に対応する公開鍵を用いて電子署名値を復号して得られた結果とが等しいかを確認して検証し」「電子署名データ中の鍵情報が電子署名者の公開鍵証明書を含んでいる」と、「電子署名データ中の鍵情報に含まれている公開鍵証明書の有効性を検証し、検証に成功した場合、電子署名検証成功、および、電子署名者の認証成功として処理を終了する」ことと本願発明の「情報受信者のコンピュータによってアクセスされ、さらに認証証明書が関連付けられているウェブページを情報受信者のコンピュータにより検証し、前記検証が、ルート証明書の中に含まれる認証情報を使用して、前記関連付けられた認証証明書の真正性を検証することに成功して、前記関連付けられた認証証明書が、証明書レジストリに属することを検証すること、および前記関連付けられた認証証明書の真正性を前記検証することに成功した後、前記関連付けられた認証証明書の中に含まれる認証情報を使用して、ウェブページの指定された所有者のＩＤを検証することに成功することを含む」とは、上位概念において「情報受信者のコンピュータによってアクセスされ、さらに認証証明書が関連付けられているウェブページを情報受信者のコンピュータにより検証し、前記検証が、前記関連付けられた認証証明書の真正性を検証することに成功して、前記関連付けられた認証証明書が、前記関連付けられた認証証明書の真正性を前記検証することに成功した後、前記関連付けられた認証証明書の中に含まれる認証情報を使用して、ソースを検証することに成功することを含む」点で共通する。
　
　前記１．〜３．の検討をふまえると、本願発明と引用文献１発明とは次の事項を有する発明である点では一致し、そして、次の点で相違する。
　
［一致点］
「情報プロバイダにより送信された情報の真正性を検証する方法であって、前記方法が、
　登録機関のコンピュータによって、情報プロバイダのプロバイダに発行された認証証明書と、前記認証証明書を含む証明書レジストリを作成し、
　情報受信者のコンピュータによってアクセスされ、さらに認証証明書が関連付けられているウェブページを情報受信者のコンピュータにより検証し、前記検証が、前記関連付けられた認証証明書の真正性を検証することに成功して、前記関連付けられた認証証明書が
、
　
［相違点１］
　本願発明が、登録機関のコンピュータによって、「複数の」情報プロバイダの「各」プロバイダに発行された認証証明書と、前記認証証明書の「すべてに対応するルート証明書」とを含む証明書レジストリを作成し、前記認証証明書の「各」証明書が、該証明書の「それぞれの」認証情報を、「前記情報プロバイダの対応するプロバイダの識別情報に結び付け、前記認証証明書の各証明書が、前記情報プロバイダの対応するプロバイダと、該プロバイダのドメイン名情報との間のリンクを欠いており、さらに証明書レジストリの前記認証証明書が、前記情報プロバイダが提供する情報の特定のタイプ、前記情報プロバイダが関連している特定の組織、前記情報プロバイダが携わっている特定のタイプの職業、および前記情報プロバイダが位置している特定の地理的区域の少なくとも１つに少なくとも或る程度、依存する仕方で関連付けられること、」としているのに対し、引用文献１発明は、そのようであるか不明である点。
　
［相違点２］
　本願発明が、「情報受信者のコンピュータにルート証明書を提供すること」としているのに対し、引用文献１発明は、そのようであるか不明である点。 
　
［相違点３］
　検証に関し、本願発明が、検証が、「ルート証明書の中に含まれる認証情報を使用して、」としているとともに、認証証明書が、「証明書レジストリに属することを検証すること、」としているのに対し、引用文献１発明はそのようであるか不明である点。
　
［相違点４］
　ソースを検証することが、本願発明は「ウェブページの指定された所有者のＩＤを検証すること」であるのに対し、引用文献１発明は、電子署名検証成功、および、電子署名者の認証成功である点。
　
第５．判断
　
１．相違点１について
　引用文献２には、「電子証明書」の中身に「１．登録された公開鍵、２．その公開鍵の持ち主の情報、３．証明書を発行した認証局の情報、４．発行元認証局の署名」が含まれること、具体的には「【コラム】Ｘ．５０９証明書フォーマット」に、証明書の中に被発行者名(subject)（「情報プロバイダの対応するプロバイダの識別情報」に相当）と公開鍵情報(subjectPublicKeyInfo)（本願発明における「認証情報」に相当）とが記載されていて、公開鍵情報を、被発行者名に結び付けることが示されていると共に、当該証明書には被発行者のドメイン名情報を含んでいないことから、被発行者と、該被発行者のドメイン名情報との間のリンクを欠いていることが示されている。また、同様に引用文献２には「発行された認証証明書（電子証明書）と、前記認証証明書のすべてに対応するルート証明書（ルート（Ｒｏｏｔ）認証局の証明書）とを含む証明書レジストリ（ＣＡ；認証局）を作成し、前記認証証明書（電子証明書）の各証明書が、該証明書のそれぞれの認証情報（電子証明書の中身の情報、例えば、登録された公開鍵）を、識別情報（登録された公開鍵、その公開鍵の持ち主の情報、証明書を発行した認証局の情報）に結び付け、前記認証証明書の各証明書が、ドメイン名情報との間のリンクを欠いており（当該証明書にはドメイン名情報を含んでいない）」、に相当する事項が示されている。
　また、電子署名の技術分野において常識的・基礎的な事項を示すものとして示した引用文献３には、「登録機関のコンピュータ」「証明書レジストリ」に相当する事項が示され、また、「証明書のそれぞれの認証情報（公開鍵など）を、」「識別情報（所有者情報、ＩＤ）に結び付け」ること、「複数の」情報プロバイダ（サービス提供会社など）、「それぞれの」証明書（認証情報）、および「ドメイン名情報との間のリンクを欠いており」、「さらに証明書レジストリの前記認証証明書が、前記情報プロバイダが提供する情報の特定のタイプ、前記情報プロバイダが関連している特定の組織、前記情報プロバイダが携わっている特定のタイプの職業、および前記情報プロバイダが位置している特定の地理的区域の少なくとも１つに少なくとも或る程度、依存する仕方で関連付けられること」 に相当する事項が示されている。
　そして、引用文献２、３はいずれも証明書に係る技術を示すものであり、引用文献１発明において、証明書に関して、登録機関のコンピュータによって、「複数の」情報プロバイダの「各」プロバイダに発行された認証証明書と、前記認証証明書の「すべてに対応するルート証明書」とを含む証明書レジストリを作成し、前記認証証明書の「各」証明書が、該証明書の「それぞれの」認証情報を、「前記情報プロバイダの対応するプロバイダの識別情報に結び付け、前記認証証明書の各証明書が、前記情報プロバイダの対応するプロバイダと、該プロバイダのドメイン名情報との間のリンクを欠いており、さらに証明書レジストリの前記認証証明書が、前記情報プロバイダが提供する情報の特定のタイプ、前記情報プロバイダが関連している特定の組織、前記情報プロバイダが携わっている特定のタイプの職業、および前記情報プロバイダが位置している特定の地理的区域の少なくとも１つに少なくとも或る程度、依存する仕方で関連付けられること、」となすことは、引用文献２、３の証明書に係る技術を参酌することにより当業者が容易になし得ることである。
　
２．相違点２について
　引用文献２の「２つの認証局は、同じｒｏｏｔという認証局から認証されている（証明書を発行されている）とすると」、「Ｓｕｂ２認証局の証明書が自分の信頼するｒｏｏｔ認証局から発行されていることをＳｕｂ２認証局の証明書の署名を検証することで確認」するのに、Ｂさんから証明書（公開鍵）を受け取ったＡさんは「情報受信者のコンピュータ（Ａさん）にルート証明書を提供すること」は自明である（ルート証明書が提供される点について、必要なら、周知技術として特開２００５−６０７６号公報の段落【００１７】「クライアント２００は、証明書を検証する際に、クライアント２００にインストール済みのルート証明書２２０の公開鍵を用いて証明書を復号して検証を行い、身元が保証された証明書と判断する。」との記載参照。）。
　引用文献１発明において、「情報受信者のコンピュータにルート証明書を提供すること」は、引用文献２の技術を参酌することにより当業者が容易になし得ることである。
　
３．相違点３について
　ルート証明書にルート（Ｒｏｏｔ）認証局の公開情報（ルート認証局の公開鍵）を含むことは技術常識である。　　
　引用文献１発明において、検証が、「ルート証明書の中に含まれる認証情報を使用して、」とすることは当業者が当然になすことである。
　また、引用文献３には「認証証明書が、証明書レジストリに属することを検証する」技術が示されており、引用文献１発明において、認証証明書が、「証明書レジストリに属することを検証すること、」とすることは当業者が容易になし得ることである。
　
４．相違点４について
　ＨＴＭＬ文書をダウンロードする場合に、そのソース（持ち主）を検証することは、証明書の認証情報（例えば、引用文献２のＸ．５０９証明書フォーマットの被発行者のオブジェクトＩＤなど）を用いることにより適宜なし得る事項である。
　引用文献１発明において、ソースを検証することが、電子署名検証成功、および、電子署名者の認証成功であるところを、「ウェブページの指定された所有者のＩＤを検証すること」となすことは、引用文献２の事項を参酌することにより当業者が適宜なし得ることである。
　
５．小括
　以上のとおりであるから、本願発明の構成は、引用文献１発明、引用文献２〜３記載のごとき証明書の周知技術に基いて、当業者が容易に想到し得るものであり、本願発明の奏する作用効果は、前記引用文献１発明、引用文献２ないし３に記載のごとき周知技術から当然予測される範囲内のものにすぎず、格別顕著なものということはできない。
　したがって、本願発明は、前記引用文献１発明、引用文献２ないし３に記載の事項に基づいて、当業者が容易に発明をすることができたものである。
　
第６．むすび
　
　以上のとおり、本願発明は、特許法第２９条第２項の規定により特許を受けることができないから、他の請求項に係る発明について検討するまでもなく、本願は拒絶されるべきものである。
　
　よって、上記結論のとおり審決する。