• ポートフォリオ機能


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

  • この表をプリントする
PDF PDFをダウンロード
審決分類 審判 査定不服 2項進歩性 特許、登録しない。 G06F
管理番号 1302716
審判番号 不服2013-7460  
総通号数 188 
発行国 日本国特許庁(JP) 
公報種別 特許審決公報 
発行日 2015-08-28 
種別 拒絶査定不服の審決 
審判請求日 2013-04-23 
確定日 2015-07-01 
事件の表示 特願2010-510953「ウェブページの真正性検証」拒絶査定不服審判事件〔平成20年12月11日国際公開、WO2008/149331、平成22年 9月 2日国内公表、特表2010-530097〕について、次のとおり審決する。 
結論 本件審判の請求は、成り立たない。 
理由 第1.手続の経緯

本件審判請求に係る出願(以下、「本願」という。)は、2008年6月5日を国際出願日(パリ条約による優先権主張日;2007年6月7日、米国)とする出願であって、平成22年3月17日付けで審査請求がなされ、平成24年5月7日付けで拒絶理由通知(平成24年5月15日発送)がなされ、これに対して平成24年11月5日付けで意見書が提出されると共に同日付けで手続補正書が提出されたが、平成24年12月18日付けで拒絶査定(平成24年12月25日謄本送達)がなされたものである。
本件審判請求は、これに対して、「原査定を取り消す、この出願の発明は特許をすべきものである、との審決を求める。」ことを請求の趣旨として平成25年4月23日付けで審判請求がなされたものであり、同日付けで手続補正書が提出され、平成25年7月23日付けで前置報告がされ、平成25年10月4日付け(平成25年10月8日発送)で審尋がなされ、平成26年1月7日付けで回答がなされたものである。

第2.本願発明

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

「情報プロバイダにより送信された情報の真正性を検証する方法であって、前記方法が、
登録機関のコンピュータによって、複数の情報プロバイダの各プロバイダに発行された認証証明書と、前記認証証明書のすべてに対応するルート証明書とを含む証明書レジストリを作成し、前記認証証明書の各証明書が、該証明書のそれぞれの認証情報を、前記情報プロバイダの対応するプロバイダの識別情報に結び付け、前記認証証明書の各証明書が、前記情報プロバイダの対応するプロバイダと、該プロバイダのドメイン名情報との間のリンクを欠いており、さらに証明書レジストリの前記認証証明書が、前記情報プロバイダが提供する情報の特定のタイプ、前記情報プロバイダが関連している特定の組織、前記情報プロバイダが携わっている特定のタイプの職業、および前記情報プロバイダが位置している特定の地理的区域の少なくとも1つに少なくとも或る程度、依存する仕方で関連付けられること、
情報受信者のコンピュータにルート証明書を提供すること、および
情報受信者のコンピュータによってアクセスされ、さらに認証証明書が関連付けられているウェブページを情報受信者のコンピュータにより検証し、前記検証が、ルート証明書の中に含まれる認証情報を使用して、前記関連付けられた認証証明書の真正性を検証することに成功して、前記関連付けられた認証証明書が、証明書レジストリに属することを検証すること、および前記関連付けられた認証証明書の真正性を前記検証することに成功した後、前記関連付けられた認証証明書の中に含まれる認証情報を使用して、ウェブページの指定された所有者のIDを検証することに成功することを含む、方法。」

第3.引用文献記載事項

1.引用文献1
原審の拒絶理由通知において引用された、本願の優先権主張日前に頒布又は電気通信回線を通じて公衆に利用可能となった文献である、特開2003-338815号公報(以下、「引用文献1」という。)には、図面とともに、次の記載がある。
(当審注:下線は、参考のために当審で付与したものである。以下、同じ。)

A.「【0007】
【発明が解決しようとする課題】しかしながら、上述した従来技術には、次のような問題点があった。
…(中略)…
【0009】第2の問題点は、公開鍵証明書を用いていないため、不特定の者の認証ができず、それにより、予めユーザ登録された者の電子署名の検証や、予めユーザ登録された者の認証しか行うことができないということである。
【0010】本発明の目的は、HTML文書とそのHTML文書に関連する外部データに対して一括して電子署名を施すことができるとともに、ユーザ登録されていない者の電子署名の検証やユーザ登録されていない者の認証を行うことができる電子署名システムおよび電子署名方法を提供することにある。
【0011】
【課題を解決するための手段】上記目的を達成するために本発明の電子署名システムは、HTML文書および当該HTML文書に関連付けられた外部データに対して一括して電子署名を施した電子署名データを生成する電子署名データ生成手段と、前記電子署名データをダウンロードし、ダウンロードした前記電子署名データの有効性を検証することにより、前記HTML文書および当該HTML文書に関連付けられた前記外部データの改竄検出を一括して行う電子署名データ検証手段とを有することを特徴とするものである。
…(中略)…
【0014】また、前記電子署名データ生成手段は、電子署名者の公開鍵証明書を含む鍵情報を前記電子署名データ中にさらに記述し、前記電子署名データ検証手段は、前記HTML文書および当該HTML文書に関連付けられた前記外部データの改竄検出を行う際に、前記電子署名データ中に記述された前記鍵情報に前記公開鍵証明書が含まれている場合、当該公開鍵証明書の有効性を検証することにより前記電子署名者の認証を行うこととしても良い。
…(中略)…
【0024】(作用)上記のように構成された本発明においては、HTML文書とその関連の外部データに対して一括して電子署名を施した電子署名データを作成し、その電子署名データの有効性を検証することによりHTML文書とその関連の外部データの改竄検出を一括して行う。さらに、電子署名データ中に記述された鍵情報に公開鍵証明書が含まれている場合、該公開鍵証明書の有効性を検証することにより電子署名者の認証を行う。
【0025】これにより、HTML文書とその関連の外部データに対するデータ完全性の保証、HTML文書とその関連の外部データの作成者の認証、当該作成者による否認の防止、および、HTML文書とその関連の外部データに対するアクセス制御を実現することが可能となる。」

B.「【0046】次に、クライアント計算機2側で行われる電子署名検証処理動作について、図3のフローチャートを参照して説明する。
【0047】まず、Webブラウザ20は、クライアントに指示されたHTML文書100をサーバ計算機1からダウンロードする(ステップ301)。このとき、HTML文書100中に外部データ識別情報101が記述されている場合は、その外部データ識別情報101に対応する外部データ110をHTML文書100と共にダウンロードする。
【0048】次に、Webブラウザ20は、HTML文書100中に電子署名データ識別情報102が記述されているかを確認する(ステップ302)。電子署名データ識別情報102が記述されていない場合は、処理が終了する。
【0049】次に、Webブラウザ20は、HTML文書100中の外部データ識別情報101、電子署名データ識別情報102、および、HTML文書100自体の識別情報を併せて、電子署名データ検証部21に渡し、電子署名の検証処理を行わせる(ステップ303)。
【0050】次に、電子署名データ検証部21は、電子署名データ識別情報102を元に電子署名データ120をサーバ計算機1からダウンロードする(ステップ304)。
【0051】次に、電子署名データ検証部21は、電子署名データ120中のHTML文書URL情報121とHTML文書自体の識別情報とが等しく整合性があるかを確認する(ステップ305)。等しくない場合は検証失敗として処理を終了する。
【0052】次に、電子署名データ検証部21は、HTML文書自体の識別情報を元にサーバ計算機1からダウンロードしたHTML文書100のハッシュ値を計算し、電子署名データ120中に記述されているHTML文書ハッシュ値122と等しいかを確認する(ステップ306)。等しくない場合は検証失敗として処理を終了する。
【0053】次に、電子署名データ検証部21は、外部データ識別情報101を元にサーバ計算機1からダウンロードした各外部データ110のハッシュ値を計算し、電子署名データ120中に記述されている外部データハッシュ値124と等しいかを確認する(ステップ307)。等しくない場合は検証失敗として処理を終了する。
【0054】次に、電子署名データ検証部21は、電子署名データ120中のHTML文書URL情報121、HTML文書ハッシュ値122、外部データURL情報123、外部データハッシュ値124、および、鍵情報125の全てに対してハッシュ計算を行い得られたハッシュ値と、鍵情報125に対応する公開鍵を用いて電子署名値126を復号して得られた結果とが等しいかを確認する(ステップ308)。等しくない場合は検証失敗として処理を終了する。
【0055】次に、電子署名データ検証部21は、電子署名データ120中の鍵情報125が電子署名者の公開鍵証明書を含んでいるかを確認する(ステップ309)。含んでいない場合、HTML文書100の電子署名検証成功として処理を終了する。
【0056】最後に、電子署名データ検証部21は、電子署名データ120中の鍵情報125に含まれている公開鍵証明書の有効性を検証する(ステップ310)。検証に成功した場合、電子署名検証成功、および、電子署名者の認証成功として処理を終了する。検証に失敗した場合、電子署名検証失敗として処理を終了する。
【0057】以下に、図1に示した電子署名システムにおける電子署名処理に関する動作について、具体例を挙げて図4を参照して説明する。
【0058】まず、電子署名者により電子署名データ生成部13に電子署名計算対象のHTML文書100のURLが入力される。
【0059】電子署名データ生成部13は、HTML文書100および外部データ110を元に、電子署名データ120を生成する。この電子署名データ120は、HTML文書100および外部データ110と共にサーバ計算機1上に保存される。
【0060】Webブラウザ20は、クライアント計算機1のクライアントの要求に応じてサーバ計算機1からHTML文書100をダウンロードし、HTML文書100中のHTML文書100中の外部データ識別情報101、電子署名データ識別情報102、および、HTML文書100自体の識別情報を電子署名データ検証部21に渡す。
【0061】電子署名データ検証部21は、Webブラウザ20から渡された情報を元に電子署名の検証を行い、HTML文書100の電子署名の有効性の合否、および、鍵情報125に電子署名者の公開鍵証明書が含まれていた場合にはその公開鍵証明書の有効性の合否を判定し、その判定結果をWebブラウザ20に通知する。
【0062】これにより、外部データ110、電子署名データ120を含むHTML文書100の改竄の検出と、電子署名者の認証を実現することができる。」

引用文献1に記載された事項を検討する。
(A)A.の「電子署名データ生成手段」は、図1、図4に記載されたサーバ計算機の電子署名データ生成部13のことであり、「前記電子署名データをダウンロードし、ダウンロードした前記電子署名データの有効性を検証する」電子署名検証処理動作は、B.の「クライアント計算機2側で行われる」処理であり、前記サーバ計算機の電子署名データ生成部13とクライアント計算機2との関係は、図1、図4にも示されている。検証についてA.の「電子署名データの有効性を検証することによりHTML文書とその関連の外部データの改竄検出を一括して行う。さらに、電子署名データ中に記述された鍵情報に公開鍵証明書が含まれている場合、該公開鍵証明書の有効性を検証することにより電子署名者の認証を行う」との記載から、「電子署名データの有効性を検証することによりHTML文書とその関連の外部データの改竄検出を一括して行い、さらに、電子署名データ中に記述された鍵情報に公開鍵証明書が含まれている場合、該公開鍵証明書の有効性を検証することにより電子署名者の認証を行う方法」をよみとることができる。

(B)前記(A)で言及した「電子署名データの有効性を検証することによりHTML文書とその関連の外部データの改竄検出を一括して行い、さらに、電子署名データ中に記述された鍵情報に公開鍵証明書が含まれている場合、該公開鍵証明書の有効性を検証することにより電子署名者の認証を行う方法」と、B.の下線部(当審付与の 部(下線部)を参照)の記載、即ち、「クライアント計算機2側で行われる電子署名検証処理動作」についての「Webブラウザ20は、クライアントに指示されたHTML文書100をサーバ計算機1からダウンロードする」、「HTML文書100中に外部データ識別情報101が記述されている場合は、その外部データ識別情報101に対応する外部データ110をHTML文書100と共にダウンロードする」、次に、「Webブラウザ20は、HTML文書100中に電子署名データ識別情報102が記述されているかを確認する」、次に、「Webブラウザ20は、HTML文書100中の外部データ識別情報101、電子署名データ識別情報102、および、HTML文書100自体の識別情報を併せて、電子署名データ検証部21に渡し、電子署名の検証処理を行わせる」、次に、「電子署名データ検証部21は、電子署名データ識別情報102を元に電子署名データ120をサーバ計算機1からダウンロードする」、次に、「電子署名データ検証部21は、電子署名データ120中のHTML文書URL情報121とHTML文書自体の識別情報とが等しく整合性があるかを確認する」、次に、「電子署名データ検証部21は、HTML文書自体の識別情報を元にサーバ計算機1からダウンロードしたHTML文書100のハッシュ値を計算し、電子署名データ120中に記述されているHTML文書ハッシュ値122と等しいかを確認」し、「等しくない場合は検証失敗」とし、次に、「電子署名データ検証部21は、外部データ識別情報101を元にサーバ計算機1からダウンロードした各外部データ110のハッシュ値を計算し、電子署名データ120中に記述されている外部データハッシュ値124と等しいかを確認」し「等しくない場合は検証失敗」とし、次に、「電子署名データ検証部21は、電子署名データ120中のHTML文書URL情報121、HTML文書ハッシュ値122、外部データURL情報123、外部データハッシュ値124、および、鍵情報125の全てに対してハッシュ計算を行い得られたハッシュ値と、鍵情報125に対応する公開鍵を用いて電子署名値126を復号して得られた結果とが等しいかを確認」し、「等しくない場合は検証失敗」とし、次に、「電子署名データ検証部21は、電子署名データ120中の鍵情報125が電子署名者の公開鍵証明書を含んでいるかを確認」し、「電子署名データ検証部21は、電子署名データ120中の鍵情報125に含まれている公開鍵証明書の有効性を検証」し、「検証に成功した場合、電子署名検証成功、および、電子署名者の認証成功として処理を終了する」との記載から、「電子署名データの有効性を検証することによりHTML文書とその関連の外部データの改竄検出を一括して行い、さらに、電子署名データ中に記述された鍵情報に公開鍵証明書が含まれている場合、該公開鍵証明書の有効性を検証することにより電子署名者の認証を行う方法であって、
Webブラウザは、クライアントに指示されたHTML文書をサーバ計算機からダウンロードするとともにHTML文書中に外部データ識別情報が記述されている場合は、対応する外部データを前記HTML文書と共にダウンロードし、
Webブラウザは、HTML文書中に電子署名データ識別情報が記述されているかを確認して、HTML文書中の外部データ識別情報、電子署名データ識別情報、および、HTML文書自体の識別情報を併せて、電子署名データ検証部に渡し、
電子署名データ検証部は、電子署名データ識別情報を元に電子署名データをサーバ計算機からダウンロードし、電子署名データ中のHTML文書URL情報とHTML文書自体の識別情報とが等しく整合性があるか確認して検証し、
HTML文書自体の識別情報を元にサーバ計算機からダウンロードしたHTML文書のハッシュ値を計算し、電子署名データ中に記述されているHTML文書ハッシュ値と等しいかを確認して検証し、
外部データ識別情報を元にサーバ計算機からダウンロードした各外部データのハッシュ値を計算し、電子署名データ中に記述されている外部データハッシュ値と等しいかを確認して検証し、
電子署名データ中のHTML文書URL情報、HTML文書ハッシュ値、外部データURL情報、外部データハッシュ値、および、鍵情報の全てに対してハッシュ計算を行い得られたハッシュ値と、鍵情報に対応する公開鍵を用いて電子署名値を復号して得られた結果とが等しいかを確認して検証し、電子署名データ中の鍵情報が電子署名者の公開鍵証明書を含んでいると、電子署名データ中の鍵情報に含まれている公開鍵証明書の有効性を検証し、検証に成功した場合、電子署名検証成功、および、電子署名者の認証成功として処理を終了する、クライアント計算機側で行われる電子署名検証処理」がよみとれる。
よって、引用文献1には、A.の段落【0010】に記載された目的、即ち、HTML文書とそのHTML文書に関連する外部データに対して一括して電子署名を施すことができるとともに、ユーザ登録されていない者の電子署名の検証やユーザ登録されていない者の認証を行うことができる電子署名方法を提供すること、を目的とした次の発明(以下「引用文献1発明」という。)が示されている。

「電子署名データの有効性を検証することによりHTML文書とその関連の外部データの改竄検出を一括して行い、さらに、電子署名データ中に記述された鍵情報に公開鍵証明書が含まれている場合、該公開鍵証明書の有効性を検証することにより電子署名者の認証を行う方法であって、
Webブラウザは、クライアントに指示されたHTML文書をサーバ計算機からダウンロードするとともにHTML文書中に外部データ識別情報が記述されている場合は、対応する外部データを前記HTML文書と共にダウンロードし、
Webブラウザは、HTML文書中に電子署名データ識別情報が記述されているかを確認して、HTML文書中の外部データ識別情報、電子署名データ識別情報、および、HTML文書自体の識別情報を併せて、電子署名データ検証部に渡し、
電子署名データ検証部は、電子署名データ識別情報を元に電子署名データをサーバ計算機からダウンロードし、電子署名データ中のHTML文書URL情報とHTML文書自体の識別情報とが等しく整合性があるか確認して検証し、
HTML文書自体の識別情報を元にサーバ計算機からダウンロードしたHTML文書のハッシュ値を計算し、電子署名データ中に記述されているHTML文書ハッシュ値と等しいかを確認して検証し、
外部データ識別情報を元にサーバ計算機からダウンロードした各外部データのハッシュ値を計算し、電子署名データ中に記述されている外部データハッシュ値と等しいかを確認して検証し、
電子署名データ中のHTML文書URL情報、HTML文書ハッシュ値、外部データURL情報、外部データハッシュ値、および、鍵情報の全てに対してハッシュ計算を行い得られたハッシュ値と、鍵情報に対応する公開鍵を用いて電子署名値を復号して得られた結果とが等しいかを確認して検証し、電子署名データ中の鍵情報が電子署名者の公開鍵証明書を含んでいると、電子署名データ中の鍵情報に含まれている公開鍵証明書の有効性を検証し、検証に成功した場合、電子署名検証成功、および、電子署名者の認証成功として処理を終了する、クライアント計算機側で行われる電子署名検証処理を含む、方法。」

2.引用文献2
原審の拒絶理由において引用された、本願の優先権主張日前に頒布又は電気通信回線を通じて公衆に利用可能となった文献である、浅野昌和,PKI基礎講座 第2回 電子証明書と認証局,@IT Master of IP Network,アイティメディア株式会社,[online],2000年11月21日,[平成24年5月2日検索]URL,http://www.atmarkit.co.jp/fnetwork/rensai/pki02/pki01.htmlには、関連する画面1?画面5、図1?図2とともに、次の記載がある。

「電子証明書は実世界における印鑑証明書にたとえられることが多い(図1)。印鑑証明書の目的は自治体がその印鑑の持ち主を証明することだ。

印鑑証明書の内容は、

1.登録された印鑑の印影
2.その印鑑の持ち主の情報
3.印鑑証明書を発行した自治体名
4.その自治体の印

といったものだろう。

この「登録された印鑑」を「公開鍵」に、「発行自治体」を「認証局」に読み替えたものが電子証明書だと思ってよいだろう。つまり、電子証明書の中身はざっと以下のようなものということになる。

1.登録された公開鍵
2.その公開鍵の持ち主の情報
3.証明書を発行した認証局の情報
4.発行元認証局の署名
…(中略)…
【コラム】X.509証明書フォーマット

X.509の証明書フォーマットは、現在バージョン3となっている。バージョン2でいくつかの拡張項目が設けられ、さらにバージョン3では任意の拡張情報が埋め込めるようになっている。

●バージョン1項目(必須)
バージョン情報(version)
シリアル番号(serialNumber)
署名アルゴリズム情報(signature.algorithmIdentifier)
発行認証局名(issuer)
有効期限(validity)
被発行者名(subject)
公開鍵情報(subjectPublicKeyInfo)

●バージョン2項目(任意)
認証局のオブジェクトID(issuerUniqueID)
被発行者のオブジェクトID(subjectUniqueID)

●バージョン3項目(任意)
鍵の利用目的(KeyUsage)
証明書ポリシー(certificatePolicies)
…(中略)…
公開鍵暗号方式の場合、公開鍵はどのような方法で配布してもよく、だれが知っていても問題はない。ただ、公開鍵で暗号化されたものは、ここで1つ問題がある。…(中略)…公開鍵を受け取ったとする。しかし、その公開鍵を送ってきたのが本当にBさんであるかどうかを検証することができないのである。…(中略)…そこで、AさんとBさんの双方が信頼できる認証局から証明書を発行してもらい、それをもってAさんが受け取った公開鍵が本当にBさんのものであることを証明するのである。

ここで重要なのは「AさんとBさんがともに認証局を信頼できること」である。
…(中略)…
「信頼の基盤」として認証局が行わなければならないことは非常に多い。

例えば、証明書には認証局の署名がされている…(中略)…第三者に成りすましたものへの証明書の発行を行わないよう、十分な本人確認も必要だし、…(中略)…

このような認証局運用のガイドラインというものがいくつかあるが、日本では電子商取引推進協議会(ECOM)が発表している「認証局運用ガイドライン」…(中略)…がわかりやすいだろう。
…(中略)…
ということは認証局の証明書というものが・・・・・・実は存在するのである。では、その証明書を発行するのはいったいだれなのだろうか。

これには以下の2つの方法がある。

1.その認証局が自分で発行する
2.さらに上位の認証局が存在し、その認証局が発行する

上記2の場合でも、結局その根本をたどっていくと1の方式で証明書を発行した認証局が存在する。このような認証局を「ルート(Root)認証局」という。そのような認証局の証明書には、その認証局自身の署名がされている。
…(中略)…
ルート認証局と信頼のモデル

話を証明書の階層に戻そう。図2を見てほしい。AさんがSub1、BさんがSub2という異なる2つの認証局から証明書の発行を受けていたとしよう。そして、この2つの認証局は、同じrootという認証局から認証されている(証明書を発行されている)とすると、AさんもBさんもroot認証局を信頼している必要がある。
…(中略)…
ではAさんがBさんから証明書(公開鍵)を受け取ったら、Aさんはどのようにしてこれを検証していけばよいのだろうか。まず、AさんはBさんの証明書のほかにSub2認証局の証明書を受け取らなければならない。そして、Sub2認証局の証明書が自分の信頼するroot認証局から発行されていることをSub2認証局の証明書の署名を検証することで確認し、さらにBさんの証明書が確かにSub2認証局から発行されたものであることを、Bさんの証明書に付いている署名を検証して確認するのである。」(1/9頁11行?8/9頁10行)

引用文献2には、「電子証明書」の中身に「1.登録された公開鍵、2.その公開鍵の持ち主の情報、3.証明書を発行した認証局の情報、4.発行元認証局の署名」が含まれること、具体的には「【コラム】X.509証明書フォーマット」に、証明書の中に被発行者名(subject)(「情報プロバイダの対応するプロバイダの識別情報」に相当)と公開鍵情報(subjectPublicKeyInfo)(本願発明における「認証情報」に相当)とが存在し、これらの存在からみて、公開鍵情報を、被発行者名に結び付けることが示されていると共に、当該証明書には被発行者のドメイン名情報を含んでいないことから、被発行者と、該被発行者のドメイン名情報との間のリンクを欠いているとみることができる。また、認証局自身の署名がされている「ルート(Root)認証局」の証明書(「ルート証明書」)と、「AさんがSub1、BさんがSub2という異なる2つの認証局から証明書の発行を受けていたとしよう。そして、この2つの認証局は、同じrootという認証局から認証されている(証明書を発行されている)とすると、AさんもBさんもroot認証局を信頼している必要がある。」「ではAさんがBさんから証明書(公開鍵)を受け取ったら、Aさんはどのようにしてこれを検証していけばよいのだろうか。まず、AさんはBさんの証明書のほかにSub2認証局の証明書を受け取らなければならない。そして、Sub2認証局の証明書が自分の信頼するroot認証局から発行されていることをSub2認証局の証明書の署名を検証することで確認し、さらにBさんの証明書が確かにSub2認証局から発行されたものであることを、Bさんの証明書に付いている署名を検証して確認するのである。」との記載から、「発行された認証証明書(電子証明書)と、前記認証証明書のすべてに対応するルート証明書(ルート(Root)認証局の証明書)とを含む証明書レジストリ(CA;認証局)を作成し、前記認証証明書(電子証明書)の各証明書が、該証明書のそれぞれの認証情報(電子証明書の中身の情報、例えば、登録された公開鍵)を、識別情報(登録された公開鍵、その公開鍵の持ち主の情報、証明書を発行した認証局の情報)に結び付け、前記認証証明書の各証明書が、ドメイン名情報との間のリンクを欠いており(当該証明書にはドメイン名情報を含んでいない)」、に相当する事項が示されている。

3.引用文献3
原審において、電子署名技術分野における常識的・基礎的な事項(周知技術)を示すために引用された、本願の優先権主張日前に頒布又は電気通信回線を通じて公衆に利用可能となった文献である電子商取引推進協議会(ECOM) 認証・公証WG「証明書利用形態に関する考察」2002年3月発行,p.1-p.24,(URL,http://www.jipdec.or.jp/archives/ecom/results/h13seika/h13results-07.pdf)には、関連する図とともに、次の記載がある。

「1.2.1.2 ネット社会における例
ID、および属性情報のネット社会における例としては、次のような情報、証明書が挙げられる。
(1)ID
IDの例としては、秘密鍵の対となる公開鍵を含む証明書が相当する。
(2)属性情報
属性情報としては、発行者情報、所有者情報、および有効期限等が相当する。
…(中略)…
1.2.2.2 個別証明書の世界
各発行機関(サービス提供会社)は個人に対して一枚しか発行しないが、利用者一人に同種の証明書が結果的に複数枚発行される世界で、…(中略)…利用するサービスごとにユニークに個人を特定できるIDを含む証明書。

1.2.2.3 マルチ証明書の世界
一人に複数枚発行されるが、それぞれの証明書が通用する領域が異なる世界で、一枚の証明書で複数のサービスが利用できる。
クローズドな世界(国、地域、業界、特定の世界)の中で、ユニークに個人を特定できるIDを含む証明書。
…(中略)…
3.2.2 個別証明書世界モデル
…(中略)…
(3)認証局と登録機関
サービス・アプリケーション毎に認証局が存在し、認証機関と登録機関が分離されていない。
…(中略)…
3.3.1 マルチ証明書について
(1)定義
閉じた世界(国、地域、業界、あるいは個人が決めた特定の世界であっても良い)の中で、ユニークに個人を特定できるIDを含む証明書。
…(中略)…
(4)発行審査
トレーサビリティを確保するための厳密な本人性確認手段は必要となる。証明書の記載事項になる属性情報の確認のため属性を証明する公的文書の提示が求められる。
…(中略)…
3.3.2 マルチ証明書世界モデル
(1)定義および特徴
シングル証明書の世界と個別証明書の世界の中間解。利用者は行政・業界(マーケットプレイス)毎に発行された証明書を何枚か使い分ける。
…(中略)…
(3)認証局と登録機関
認証局は業界毎に1つ存在し、その認証局に対応する登録機関が複数存在する。
…(中略)…
リポジトリへの登録およびサービスからの検証を受付ける登録機関が存在する。
…(中略)…
サービス利用窓口は提示されたマルチ証明書が登録されているか登録機関に検証依頼を行う。
」(6頁3行?21頁3行)

引用文献3の「認証局と登録機関」が電子商取引のためにコンピュータを用いるものであることは電子商取引推進協議会(ECOM)が発表している「認証局運用ガイドライン」に関することから明らかであり、「リポジトリへの登録」は当該登録とは「証明書が登録されているか登録機関に検証依頼を行う」などの記載から「証明書」が「登録」された登録機関のレジストリ(例えば、データベース)などのレジストリであり、これらから「登録機関のコンピュータ」「証明書レジストリ」がよみとれる。
また、「IDの例としては、秘密鍵の対となる公開鍵を含む証明書」「属性情報としては、発行者情報、所有者情報、および有効期限等」との記載から、「証明書のそれぞれの認証情報(公開鍵など)を、」「識別情報(所有者情報、ID)に結び付け」をよみとることができる。また、「各発行機関(サービス提供会社)は個人に対して一枚しか発行しないが、利用者一人に同種の証明書が結果的に複数枚発行される世界で、」「利用するサービスごとにユニークに個人を特定できるIDを含む証明書」、「閉じた世界(国、地域、業界、あるいは個人が決めた特定の世界であっても良い)のなかで、ユニークに個人を特定できるIDを含む証明書」との記載から「複数の」情報プロバイダ(サービス提供会社など)、「それぞれの」証明書(認証情報)をよみとることができ、ドメイン名情報との間のリンクが記載されていないことから「ドメイン名情報との間のリンクを欠いており」をよみとることができ、さらに、前記「各発行機関(サービス提供会社)」「閉じた世界(国、地域、業界、あるいは個人が決めた特定の世界」との記載から「さらに証明書レジストリの前記認証証明書が、前記情報プロバイダが提供する情報の特定のタイプ、前記情報プロバイダが関連している特定の組織、前記情報プロバイダが携わっている特定のタイプの職業、および前記情報プロバイダが位置している特定の地理的区域の少なくとも1つに少なくとも或る程度、依存する仕方で関連付けられること」 をよみとることができる。また、「 マルチ証明書が登録されているか登録機関に検証依頼を行う 」との記載から「認証証明書が、証明書レジストリに属することを検証すること」をよみとることができる。

第4.対比

1.引用文献1発明の「クライアントに指示されたHTML文書を」「ダウンロードする」「サーバ計算機」は本願発明の「情報プロバイダ」に相当し、引用文献1発明の「電子署名データの有効性を検証すること」、「公開鍵証明書の有効性を検証すること」において当該「有効性を検証すること」は本願発明の「情報の真正性を検証する」ことと実質的な差異はない。この点を加味すれば、引用文献1発明の「HTML文書をダウンロードする」「サーバ計算機」および「電子署名データの有効性を検証することによりHTML文書とその関連の外部データの改竄検出を一括して行い、さらに、電子署名データ中に記述された鍵情報に公開鍵証明書が含まれている場合、該公開鍵証明書の有効性を検証することにより電子署名者の認証を行う方法」と本願発明の「情報プロバイダにより送信された情報の真正性を検証する方法」とに実質的な差異はない。

2.引用文献1発明の「公開鍵証明書」はクライアントに指示された「HTML文書を」「ダウンロードする」「サーバ計算機」に(対して通常、認証局により)発行された証明書であり、証明書中に「公開鍵」や「被発行者名」等の情報を有することは慣用のものである(必要なら、引用文献2の「【コラム】X.509証明書フォーマット」に、被発行者名(subject)(「情報プロバイダの対応するプロバイダの識別情報」に相当)と公開鍵情報(subjectPublicKeyInfo)(「認証情報」に相当)参照)。認証局に関し「登録機関」「レジストリ」も慣用のものであり「登録機関のコンピュータ」を用いることは慣用のものである。これらの点をふまえると、引用文献1発明と本願発明とは「登録機関のコンピュータによって、情報プロバイダのプロバイダに発行された認証証明書と、前記認証証明書を含む証明書レジストリを作成」する点で共通する。

3.引用文献1発明のWebブラウザと電子署名データ検証部を有する「クライアント計算機」は本願発明の「情報受信者のコンピュータ」に相当し、引用文献1発明の電子署名者の認証に用いられる「電子署名者の公開鍵証明書(単に「公開鍵証明書」ということがある。)」、および、WebブラウザがHTML文書自体の識別情報を元にサーバ計算機からダウンロードした「HTML文書」と「その関連の外部データ」は、それぞれ本願発明の「認証証明書」、および「ウェブページ」に相当する。また、前記「HTML文書」と「公開鍵証明書」は、引用文献1発明の全体を構成する部分であり前記「HTML文書」のダウンロードに付随して前記「公開鍵証明書」の有効性が検証されることから前記ダウンロードした「HTML文書」と「公開鍵証明書」とは「関連している」といえる。また、「公開鍵証明書」の真正性を検証することに成功すれば、当該「公開鍵証明書」の中に含まれる情報(例えば、公開鍵)は検証された認証情報とみることができると共に(公開鍵のような認証情報に含まれる情報が)使用できることは技術常識であり、引用文献1発明の「電子署名検証成功、および、電子署名者の認証成功」と本願発明の「ウェブページの指定された所有者のIDを検証」とは上位概念ではソース(持ち主)の検証とみることができる。してみれば、引用文献1発明の「電子署名データ検証部は、」「HTML文書自体の識別情報を元にサーバ計算機からダウンロードしたHTML文書のハッシュ値を計算し、電子署名データ中に記述されているHTML文書ハッシュ値と等しいかを確認して検証し、」「電子署名データ中の」「HTML文書ハッシュ値、」「外部データハッシュ値」、「および、鍵情報の全てに対してハッシュ計算を行い得られたハッシュ値と、鍵情報に対応する公開鍵を用いて電子署名値を復号して得られた結果とが等しいかを確認して検証し」「電子署名データ中の鍵情報が電子署名者の公開鍵証明書を含んでいる」と、「電子署名データ中の鍵情報に含まれている公開鍵証明書の有効性を検証し、検証に成功した場合、電子署名検証成功、および、電子署名者の認証成功として処理を終了する」ことと本願発明の「情報受信者のコンピュータによってアクセスされ、さらに認証証明書が関連付けられているウェブページを情報受信者のコンピュータにより検証し、前記検証が、ルート証明書の中に含まれる認証情報を使用して、前記関連付けられた認証証明書の真正性を検証することに成功して、前記関連付けられた認証証明書が、証明書レジストリに属することを検証すること、および前記関連付けられた認証証明書の真正性を前記検証することに成功した後、前記関連付けられた認証証明書の中に含まれる認証情報を使用して、ウェブページの指定された所有者のIDを検証することに成功することを含む」とは、上位概念において「情報受信者のコンピュータによってアクセスされ、さらに認証証明書が関連付けられているウェブページを情報受信者のコンピュータにより検証し、前記検証が、前記関連付けられた認証証明書の真正性を検証することに成功して、前記関連付けられた認証証明書が、前記関連付けられた認証証明書の真正性を前記検証することに成功した後、前記関連付けられた認証証明書の中に含まれる認証情報を使用して、ソースを検証することに成功することを含む」点で共通する。

前記1.?3.の検討をふまえると、本願発明と引用文献1発明とは次の事項を有する発明である点では一致し、そして、次の点で相違する。

[一致点]
「情報プロバイダにより送信された情報の真正性を検証する方法であって、前記方法が、
登録機関のコンピュータによって、情報プロバイダのプロバイダに発行された認証証明書と、前記認証証明書を含む証明書レジストリを作成し、
情報受信者のコンピュータによってアクセスされ、さらに認証証明書が関連付けられているウェブページを情報受信者のコンピュータにより検証し、前記検証が、前記関連付けられた認証証明書の真正性を検証することに成功して、前記関連付けられた認証証明書が、前記関連付けられた認証証明書の真正性を前記検証することに成功した後、前記関連付けられた認証証明書の中に含まれる認証情報を使用して、ソースを検証することに成功することを含む、方法。」

[相違点1]
本願発明が、登録機関のコンピュータによって、「複数の」情報プロバイダの「各」プロバイダに発行された認証証明書と、前記認証証明書の「すべてに対応するルート証明書」とを含む証明書レジストリを作成し、前記認証証明書の「各」証明書が、該証明書の「それぞれの」認証情報を、「前記情報プロバイダの対応するプロバイダの識別情報に結び付け、前記認証証明書の各証明書が、前記情報プロバイダの対応するプロバイダと、該プロバイダのドメイン名情報との間のリンクを欠いており、さらに証明書レジストリの前記認証証明書が、前記情報プロバイダが提供する情報の特定のタイプ、前記情報プロバイダが関連している特定の組織、前記情報プロバイダが携わっている特定のタイプの職業、および前記情報プロバイダが位置している特定の地理的区域の少なくとも1つに少なくとも或る程度、依存する仕方で関連付けられること、」としているのに対し、引用文献1発明は、そのようであるか不明である点。

[相違点2]
本願発明が、「情報受信者のコンピュータにルート証明書を提供すること」としているのに対し、引用文献1発明は、そのようであるか不明である点。

[相違点3]
検証に関し、本願発明が、検証が、「ルート証明書の中に含まれる認証情報を使用して、」としているとともに、認証証明書が、「証明書レジストリに属することを検証すること、」としているのに対し、引用文献1発明はそのようであるか不明である点。

[相違点4]
ソースを検証することが、本願発明は「ウェブページの指定された所有者のIDを検証すること」であるのに対し、引用文献1発明は、電子署名検証成功、および、電子署名者の認証成功である点。

第5.判断

1.相違点1について
引用文献2には、「電子証明書」の中身に「1.登録された公開鍵、2.その公開鍵の持ち主の情報、3.証明書を発行した認証局の情報、4.発行元認証局の署名」が含まれること、具体的には「【コラム】X.509証明書フォーマット」に、証明書の中に被発行者名(subject)(「情報プロバイダの対応するプロバイダの識別情報」に相当)と公開鍵情報(subjectPublicKeyInfo)(本願発明における「認証情報」に相当)とが記載されていて、公開鍵情報を、被発行者名に結び付けることが示されていると共に、当該証明書には被発行者のドメイン名情報を含んでいないことから、被発行者と、該被発行者のドメイン名情報との間のリンクを欠いていることが示されている。また、同様に引用文献2には「発行された認証証明書(電子証明書)と、前記認証証明書のすべてに対応するルート証明書(ルート(Root)認証局の証明書)とを含む証明書レジストリ(CA;認証局)を作成し、前記認証証明書(電子証明書)の各証明書が、該証明書のそれぞれの認証情報(電子証明書の中身の情報、例えば、登録された公開鍵)を、識別情報(登録された公開鍵、その公開鍵の持ち主の情報、証明書を発行した認証局の情報)に結び付け、前記認証証明書の各証明書が、ドメイン名情報との間のリンクを欠いており(当該証明書にはドメイン名情報を含んでいない)」、に相当する事項が示されている。
また、電子署名の技術分野において常識的・基礎的な事項を示すものとして示した引用文献3には、「登録機関のコンピュータ」「証明書レジストリ」に相当する事項が示され、また、「証明書のそれぞれの認証情報(公開鍵など)を、」「識別情報(所有者情報、ID)に結び付け」ること、「複数の」情報プロバイダ(サービス提供会社など)、「それぞれの」証明書(認証情報)、および「ドメイン名情報との間のリンクを欠いており」、「さらに証明書レジストリの前記認証証明書が、前記情報プロバイダが提供する情報の特定のタイプ、前記情報プロバイダが関連している特定の組織、前記情報プロバイダが携わっている特定のタイプの職業、および前記情報プロバイダが位置している特定の地理的区域の少なくとも1つに少なくとも或る程度、依存する仕方で関連付けられること」 に相当する事項が示されている。
そして、引用文献2、3はいずれも証明書に係る技術を示すものであり、引用文献1発明において、証明書に関して、登録機関のコンピュータによって、「複数の」情報プロバイダの「各」プロバイダに発行された認証証明書と、前記認証証明書の「すべてに対応するルート証明書」とを含む証明書レジストリを作成し、前記認証証明書の「各」証明書が、該証明書の「それぞれの」認証情報を、「前記情報プロバイダの対応するプロバイダの識別情報に結び付け、前記認証証明書の各証明書が、前記情報プロバイダの対応するプロバイダと、該プロバイダのドメイン名情報との間のリンクを欠いており、さらに証明書レジストリの前記認証証明書が、前記情報プロバイダが提供する情報の特定のタイプ、前記情報プロバイダが関連している特定の組織、前記情報プロバイダが携わっている特定のタイプの職業、および前記情報プロバイダが位置している特定の地理的区域の少なくとも1つに少なくとも或る程度、依存する仕方で関連付けられること、」となすことは、引用文献2、3の証明書に係る技術を参酌することにより当業者が容易になし得ることである。

2.相違点2について
引用文献2の「2つの認証局は、同じrootという認証局から認証されている(証明書を発行されている)とすると」、「Sub2認証局の証明書が自分の信頼するroot認証局から発行されていることをSub2認証局の証明書の署名を検証することで確認」するのに、Bさんから証明書(公開鍵)を受け取ったAさんは「情報受信者のコンピュータ(Aさん)にルート証明書を提供すること」は自明である(ルート証明書が提供される点について、必要なら、周知技術として特開2005-6076号公報の段落【0017】「クライアント200は、証明書を検証する際に、クライアント200にインストール済みのルート証明書220の公開鍵を用いて証明書を復号して検証を行い、身元が保証された証明書と判断する。」との記載参照。)。
引用文献1発明において、「情報受信者のコンピュータにルート証明書を提供すること」は、引用文献2の技術を参酌することにより当業者が容易になし得ることである。

3.相違点3について
ルート証明書にルート(Root)認証局の公開情報(ルート認証局の公開鍵)を含むことは技術常識である。
引用文献1発明において、検証が、「ルート証明書の中に含まれる認証情報を使用して、」とすることは当業者が当然になすことである。
また、引用文献3には「認証証明書が、証明書レジストリに属することを検証する」技術が示されており、引用文献1発明において、認証証明書が、「証明書レジストリに属することを検証すること、」とすることは当業者が容易になし得ることである。

4.相違点4について
HTML文書をダウンロードする場合に、そのソース(持ち主)を検証することは、証明書の認証情報(例えば、引用文献2のX.509証明書フォーマットの被発行者のオブジェクトIDなど)を用いることにより適宜なし得る事項である。
引用文献1発明において、ソースを検証することが、電子署名検証成功、および、電子署名者の認証成功であるところを、「ウェブページの指定された所有者のIDを検証すること」となすことは、引用文献2の事項を参酌することにより当業者が適宜なし得ることである。

5.小括
以上のとおりであるから、本願発明の構成は、引用文献1発明、引用文献2?3記載のごとき証明書の周知技術に基いて、当業者が容易に想到し得るものであり、本願発明の奏する作用効果は、前記引用文献1発明、引用文献2ないし3に記載のごとき周知技術から当然予測される範囲内のものにすぎず、格別顕著なものということはできない。
したがって、本願発明は、前記引用文献1発明、引用文献2ないし3に記載の事項に基づいて、当業者が容易に発明をすることができたものである。

第6.むすび

以上のとおり、本願発明は、特許法第29条第2項の規定により特許を受けることができないから、他の請求項に係る発明について検討するまでもなく、本願は拒絶されるべきものである。

よって、上記結論のとおり審決する。
 
審理終結日 2015-01-30 
結審通知日 2015-02-03 
審決日 2015-02-16 
出願番号 特願2010-510953(P2010-510953)
審決分類 P 1 8・ 121- Z (G06F)
最終処分 不成立  
前審関与審査官 宮司 卓佳  
特許庁審判長 辻本 泰隆
特許庁審判官 田中 秀人
山崎 達也
発明の名称 ウェブページの真正性検証  
代理人 特許業務法人川口國際特許事務所  

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