特許 7574925 証明書発行支援システム、証明書発行支援方法及びプログラム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2024-10-21

(45)【発行日】2024-10-29

(54)【発明の名称】証明書発行支援システム、証明書発行支援方法及びプログラム

(51)【国際特許分類】

   G06F 21/44 20130101AFI20241022BHJP

   G06F 21/33 20130101ALI20241022BHJP

   G06F 21/64 20130101ALI20241022BHJP

   H04L 9/32 20060101ALI20241022BHJP

【ＦＩ】

G06F21/44

G06F21/33

G06F21/64 350

H04L9/32 200D

【請求項の数】 7

(21)【出願番号】P 2023527156

(86)(22)【出願日】2021-06-07

(86)【国際出願番号】 JP2021021568

(87)【国際公開番号】W WO2022259312

(87)【国際公開日】2022-12-15

【審査請求日】2023-09-19

(73)【特許権者】

【識別番号】000004226

【氏名又は名称】日本電信電話株式会社

(74)【代理人】

【識別番号】110004381

【氏名又は名称】弁理士法人ＩＴＯＨ

(74)【代理人】

【識別番号】100107766

【弁理士】

【氏名又は名称】伊東 忠重

(74)【代理人】

【識別番号】100070150

【弁理士】

【氏名又は名称】伊東 忠彦

(74)【代理人】

【識別番号】100124844

【弁理士】

【氏名又は名称】石原 隆治

(72)【発明者】

【氏名】鈴木 亮平

(72)【発明者】

【氏名】千田 浩司

(72)【発明者】

【氏名】奥田 哲矢

【審査官】辻 勇貴

(56)【参考文献】

【文献】特開２０１９－００４２８９（ＪＰ，Ａ）

【文献】特開２００５－０１０３０１（ＪＰ，Ａ）

【文献】特開２００４－２４０７０６（ＪＰ，Ａ）

【文献】特開２００３－１８８８７３（ＪＰ，Ａ）

【文献】米国特許出願公開第２０１５／０３４１３４２（ＵＳ，Ａ１）

【文献】坂本 勝，"ＥＶ ＳＳＬとは何か？"，ネットワークセキュリティＥｘｐｅｒｔ６，日本，（株）技術評論社，2007年06月10日，pp.10-17

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｇ０６Ｆ ２１／４４

Ｇ０６Ｆ ２１／３３

Ｇ０６Ｆ ２１／６４

Ｈ０４Ｌ ９／３２

(57)【特許請求の範囲】

【請求項1】

ＥＶ証明書の発行を認証局へ申請する第１の組織における証明書申請装置と、前記第１の組織の実在を保証する第２の組織が有する実在保証装置とを含む証明書発行支援システムであって、
前記実在保証装置は、
前記第１の組織の構成員が利用する端末からの要求に応じ、前記第１の組織の実在を保証する第１の情報に対して第１の電子署名を付与する第１の付与部と、
前記証明書申請装置が生成した、前記第１の組織への前記構成員の所属を保証する第２の情報に付与された第２の電子署名を、前記認証局と連携して検証する検証部と、
を有し、
前記証明書申請装置は、
前記ＥＶ証明書の発行の申請を承認する者の権限を示す第３の情報に対して第３の電子署名を付与する第２の付与部と、
前記第１の電子署名が付与された第１の情報、前記第２の電子署名が付与された前記第２の情報、及び前記第３の電子署名が付与された前記第３の情報を、前記ＥＶ証明書の発行を受けるために前記認証局へ送信する送信部と、
を有することを特徴とする証明書発行支援システム。

【請求項2】

前記第１の付与部は、前記証明書申請装置によって前記構成員が認証された場合に前記第１の情報に対して前記第１の電子署名を付与する、
ことを特徴とする請求項１記載の証明書発行支援システム。

【請求項3】

前記証明書申請装置は、ＡＣＭＥ（Automatic Certificate Management Environment）に従った手順に加えて、前記第１の情報、前記第２の情報及び前記第３の情報の前記認証局への送信を実行する、
ことを特徴とする請求項１又は２記載の証明書発行支援システム。

【請求項4】

ＥＶ証明書の発行を認証局へ申請する第１の組織における証明書申請装置と、前記第１の組織の実在を保証する第２の組織が有する実在保証装置とが実行する証明書発行支援方法であって、
前記実在保証装置が、
前記第１の組織の構成員が利用する端末からの要求に応じ、前記第１の組織の実在を保証する第１の情報に対して第１の電子署名を付与する第１の付与手順と、
前記証明書申請装置が生成した、前記第１の組織への前記構成員の所属を保証する第２の情報に付与された第２の電子署名を、前記認証局と連携して検証する検証手順と、
を実行し、
前記証明書申請装置が、
前記ＥＶ証明書の発行の申請を承認する者の権限を示す第３の情報に対して第３の電子署名を付与する第２の付与手順と、
前記第１の電子署名が付与された第１の情報、前記第２の電子署名が付与された前記第２の情報、及び前記第３の電子署名が付与された前記第３の情報を、前記ＥＶ証明書の発行を受けるために前記認証局へ送信する送信手順と、
を実行することを特徴とする証明書発行支援方法。

【請求項5】

前記第１の付与手順は、前記証明書申請装置によって前記構成員が認証された場合に前記第１の情報に対して前記第１の電子署名を付与する、
ことを特徴とする請求項４記載の証明書発行支援方法。

【請求項6】

前記証明書申請装置は、ＡＣＭＥ（Automatic Certificate Management Environment）に従った手順に加えて、前記第１の情報、前記第２の情報及び前記第３の情報の前記認証局への送信を実行する、
ことを特徴とする請求項４又は５記載の証明書発行支援方法。

【請求項7】

請求項４乃至６いずれか一項記載の証明書発行支援方法において前記証明書申請装置が実行する手順をコンピュータに実行させることを特徴とするプログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、証明書発行支援システム、証明書発行支援方法及びプログラムに関する。

【背景技術】

【0002】

Ｗｅｂサイトのアイデンティティを示す電子証明書は、信頼できる第三者が本人性を電子的に証明するものである。電子証明書には、本人確認の度合いによって、ＤＶ（Domain Validation）証明書、ＯＶ（Organization Validation）証明書、及びＥＶ（Extended Validation）証明書等が有る。ＤＶ証明書とは、申請者によるドメインの所有を確認し、発行される証明書をいう。ＯＶ証明書とは、申請者によるドメインの所有に加え、証明書申請組織の実在、申請者が組織に属するかを確認し、発行される証明書をいう。ＥＶ証明書とは、ＯＶ証明書に必要な確認に加え、発行申請が組織において権限の有る人物にも承認されているか等を確認し、発行される証明書をいう。

【0003】

ＤＶ証明書の発行に利用されるプロトコルとしてＡＣＭＥ（Automatic Certificate Management Environment）が知られている（非特許文献１）。ＡＣＭＥを利用することで、ＤＶ証明書の自動的な発行が可能となる。

【0004】

他方において、個人の身元を電子的に保証する技術として、ｅＫＹＣ（electoronic Know Your Customer）が知られている（非特許文献２）。

【先行技術文献】

【非特許文献】

【0005】

【文献】Automatic Certificate Management Environment（RFC8555）、［online］、インターネット＜ＵＲＬ：https://tools.ietf.org/html/rfc8555＞

【文献】宮川晃一、"本人確認手段としてのeKYCと今後の発展"、JNSA Press 第48号, pp.2-8, 2020/1、［online］、インターネット＜ＵＲＬ：https://www.jnsa.org/jnsapress/vol48/2_kikou.pdf＞

【発明の概要】

【発明が解決しようとする課題】

【0006】

しかしながら、ＡＣＭＥは、組織の実在確認や証明書の発行申請が組織内の権限の有る人物にも承認されているか等が考慮されていないため、そのままではＥＶ証明書の発行に適用することができない。従来、ＥＶ証明書の発行においては、発行対象の組織が何者であるのか、申請者は組織に属するのか、証明書の発行申請が組織内の権限の有る人物に承認されているか、という確認が書類や電話を用いるなど人手によって行われている。

【0007】

また、発行申請が組織内において権限の有る人物にも承認されていることを確認するためには、発行申請を承認した者が権限を有することである者であることを保証する必要があるが、ｅＫＹＣでは、組織内における構成員の情報（所属部署、役職）などを外部に保証できない。

【0008】

したがって、従来技術では、ＥＶ証明書の自動的な発行が困難である。

【0009】

本発明は、上記の点に鑑みてなされたものであって、ＥＶ証明書の自動的な発行を支援することを目的とする。

【課題を解決するための手段】

【0010】

そこで上記課題を解決するため、ＥＶ証明書の発行を認証局へ申請する第１の組織における証明書申請装置と、前記第１の組織の実在を保証する第２の組織が有する実在保証装置とを含む証明書発行支援システムにおいて、前記実在保証装置は、前記第１の組織の構成員が利用する端末からの要求に応じ、前記第１の組織の実在を保証する第１の情報に対して第１の電子署名を付与する第１の付与部と、前記証明書申請装置が生成した、前記第１の組織への前記構成員の所属を保証する第２の情報に付与された第２の電子署名を、前記認証局と連携して検証する検証部と、を有し、前記証明書申請装置は、前記ＥＶ証明書の発行の申請を承認する者の権限を示す第３の情報に対して第３の電子署名を付与する第２の付与部と、前記第１の電子署名が付与された第１の情報、前記第２の電子署名が付与された前記第２の情報、及び前記第３の電子署名が付与された前記第３の情報を、前記ＥＶ証明書の発行を受けるために前記認証局へ送信する送信部と、を有する。

【発明の効果】

【0011】

ＥＶ証明書の自動的な発行を支援することができる。

【図面の簡単な説明】

【0012】

【図1】第１の実施の形態における証明書発行支援システムの構成例を示す図である。

【図2】第１の実施の形態における実在保証装置１０のハードウェア構成例を示す図である。

【図3】第１の実施の形態における証明書発行支援システムの機能構成例を示す図である。

【図4】証明書発行支援システムにおいて実行される処理手順の一例を説明するためのシーケンス図である。

【図5】第１の実施の形態における法人の実在の確認処理の処理手順の一例を説明するためのシーケンス図である。

【図6】法人への担当者の所属の確認処理の処理手順の一例を説明するためのシーケンス図である。

【図7】証明書の発行申請が権限の有るものにも承認されていることの確認処理の処理手順の一例を説明するためのシーケンス図である。

【図8】第２の実施の形態における証明書発行支援システムの機能構成例を示す図である。

【図9】第２の実施の形態における法人の実在の確認処理の処理手順の一例を説明するためのシーケンス図である。

【発明を実施するための形態】

【0013】

本実施の形態では、ＡＣＭＥ（Automatic Certificate Management Environment）を拡張することで、従来のドメインの所持確認だけでなく、「申請組織の実在」、「組織への申請者の所属」、及び「権限の有る人物に承認されていること」を確認するフローを含む、ＥＶ証明書の電子的な発行手順が開示される。権限とは、組織内における権限（例えば、或る役職）のことを言う。なお、ＥＶ（Extended Validation）証明書とは、証明書発行時に申請者がドメインを所有していることに加え、証明書発行対象の組織が実在するか、申請者が証明書の発行対象の組織に属するか、発行申請が組織において権限の有る人物にも承認されているかなどを確認して発行される電子証明書をいう。

【0014】

また、斯かる確認について電子的な処理を可能とするため、構成員が組織に属することを保証するｅＫＹＣ方法が開示される。

【0015】

なお、本実施の形態において、ＥＶ証明書の発行を申請する特定の組織を「法人」という。また、組織（法人）の構成員を「社員」という。社員のうち、証明書発行の申請者としての特定の者を「担当者」という。また、担当者による証明書の発行申請を承認する社員を「上長」という。法人は、各社員に対して役職等の属性情報を付与する。上長とは、例えば、或る役職以上（例えば、課長以上等）の属性情報が付与された社員をいう。上長は、担当者の直属の上司であってもよいし、そうでなくてもよい。

【0016】

以下、図面に基づいて本発明の実施の形態を説明する。図１は、第１の実施の形態における証明書発行支援システムの構成例を示す図である。図１において、破線で囲まれた各領域は、組織を示す。本実施の形態では、法人、法人ｅＫＹＣプロバイダ及び認証局の３つの組織のコンピュータがネットワークを介して連携する。

【0017】

法人は、ＥＶ証明書の発行対象（発行の申請元）の組織の一例である。法人は、社員を認証できる状態にある。例えば、法人は、各社員にＩＤ／ＰＷなど発行し、法人内で社員を認証することができる。図１において、法人は、証明書申請装置２０、１以上の担当者端末３０ａ及び１以上の上長端末３０ｂを含む。

【0018】

担当者端末３０ａは、証明書発行申請作業を担当する社員である担当者が利用するＰＣ（Personal Computer）等の端末である。担当者端末３０ａは、法人内のネットワークＮ１を介して証明書申請装置２０及び上長端末３０ｂに接続されるとともに、ネットワークＮ１及びインターネット等のネットワークＮ２を介して実在保証装置１０及びＣＡサーバ４０に接続される。

【0019】

上長端末３０ｂは、上長が利用するＰＣ等の端末である。上長端末３０ｂは、法人内のネットワークＮ１を介して証明書申請装置２０及び担当者端末３０ａに接続される。

【0020】

証明書申請装置２０は、社員の認証を行うとともに、法人ｅＫＹＣプロバイダに対して法人の実在を保証する情報（以下、「実在保証情報」という。）」を要求するための権限（以下、単に、「権限」という。）を当該社員が有する場合に、拡張されたＡＣＭＥクライアントとして機能する。証明書申請装置２０は、拡張されたＡＣＭＥクライアントとして機能することで、実在保証装置１０に法人の実在を保証させると共に、社員の実在を実在保証装置１０に対して保証する。証明書申請装置２０は、更に、証明書の発行申請が権限の有る人物（本実施の形態では上長）にも承認されていることを保証する。なお、社員の実在とは、社員が法人に確かに所属することをいう。なお、証明書申請装置２０は、ネットワークＮ１及びネットワークＮ２を介して実在保証装置１０及びＣＡサーバ４０に接続される。

【0021】

法人ｅＫＹＣプロバイダは、本実施の形態においてその存在が仮定される組織であり、法人の実在（法人の主張）を保証する組織である。法人ｅＫＹＣプロバイダは、一般的なＰＫＩ認証基盤（以下、「法人ＰＫＩ」という。）としての機能を有し、法人ＰＫＩにより、法人は電子署名を利用することができる。法人ｅＫＹＣプロバイダは、また、ＰＫＩ認証基盤であるため、認証用の公開鍵証明書のＣＡ（Certificate Authority）としても機能する。なお、認証局は、法人のＷｅｂサーバを保証するためのＣＡ（ＥＶ証明書を発行するＣＡ）であるのに対し、法人ｅＫＹＣプロバイダは、認証基盤としてのＣＡとして機能する。すなわち、両者の役割は異なる。

【0022】

なお、法人ｅＫＹＣプロバイダは、行政又は第三者組織によって実現されてもよい。すなわち、法人の実在を行政などが電子的に保証してもよいし、法人の身元を確認した情報を提供する第三者組織が存在してもよい。いずれにせよ法人のアイデンティティを保証できるため、法人のアイデンティティ（実在又は身元）の保証者は、行政又は第三者のいずれでもよい。

【0023】

図１において、法人ｅＫＹＣプロバイダは、実在保証装置１０を有する。実在保証装置１０は、法人ｅＫＹＣプロバイダの機能を電子的に実現する１以上のコンピュータである。例えば、ブロバイダサーバは、法人の実在の保証や社員の実在（社員について法人への所属）の確認等を行う。

【0024】

認証局は、従来から存在する認証局である。図１において、認証局は、ＣＡサーバ４０を有する。本実施の形態において、ＣＡサーバ４０は、ＡＣＭＥに従って、法人に対してＥＶ（Extended Validation）証明書を発行する。

【0025】

図２は、第１の実施の形態における実在保証装置１０のハードウェア構成例を示す図である。図３の実在保証装置１０は、それぞれバスＢで相互に接続されているドライブ装置１００、補助記憶装置１０２、メモリ装置１０３、ＣＰＵ１０４、及びインタフェース装置１０５等を有する。

【0026】

実在保証装置１０での処理を実現するプログラムは、ＣＤ－ＲＯＭ等の記録媒体１０１によって提供される。プログラムを記憶した記録媒体１０１がドライブ装置１００にセットされると、プログラムが記録媒体１０１からドライブ装置１００を介して補助記憶装置１０２にインストールされる。但し、プログラムのインストールは必ずしも記録媒体１０１より行う必要はなく、ネットワークを介して他のコンピュータよりダウンロードするようにしてもよい。補助記憶装置１０２は、インストールされたプログラムを格納すると共に、必要なファイルやデータ等を格納する。

【0027】

メモリ装置１０３は、プログラムの起動指示があった場合に、補助記憶装置１０２からプログラムを読み出して格納する。ＣＰＵ１０４は、メモリ装置１０３に格納されたプログラムに従って実在保証装置１０に係る機能を実行する。インタフェース装置１０５は、ネットワークに接続するためのインタフェースとして用いられる。

【0028】

図３は、第１の実施の形態における証明書発行支援システムの機能構成例を示す図である。図３において、証明書申請装置２０は、社員認証基盤部２１と、社員情報基盤部２２と、拡張ＡＣＭＥクライアント部２３及び従来ＡＣＭＥクライアント部２４を有する。これら各部は、証明書申請装置２０にインストールされた１以上のプログラムが、証明書申請装置２０のＣＰＵに実行させる処理により実現される。但し、これら各部は、それぞれ異なるコンピュータによって実現されてもよい。証明書申請装置２０は、また、秘密鍵記憶部２５を利用する。秘密鍵記憶部２５は、例えば、証明書申請装置２０の補助記憶装置、又は証明書申請装置２０にネットワークを介して接続可能な記憶装置等を用いて実現可能である。

【0029】

社員認証基盤部２１は、社員の認証を行うと共に、社員について権限の有無を確認する。

【0030】

社員情報基盤部２２は、社員の属性情報（役職等を示す情報）を管理する。

【0031】

拡張ＡＣＭＥクライアント部２３及び従来ＡＣＭＥクライアント部２４は、本実施の形態におけるＡＣＭＥクライアントである。ＡＣＭＥクライアントとは、証明書自動発行プロトコルであるＡＣＭＥ（Automatic Certificate Management Environment）をサポートしているＣＡサーバ４０との間で、ＡＣＭＥに基づくやりとりを解釈し証明書発行申請等を行うソフトウェアをいう。

【0032】

拡張ＡＣＭＥクライアント部２３は、本実施の形態においてＡＣＭＥプロトコルに対して拡張されるフローを実行する。

【0033】

従来ＡＣＭＥクライアント部２４は、従来のＡＣＭＥプロトコルでＣＡサーバ４０と対話する。

【0034】

秘密鍵記憶部２５には、実在保証装置１０の法人ＰＫＩ部１２によって検証可能な署名の付与に利用される秘密鍵（以下、「法人秘密鍵」という。）が記憶されている。なお、法人秘密鍵は、法人ＰＫＩ部１２から提供される。

【0035】

実在保証装置１０は、法人ｅＫＹＣ部１１及び法人ＰＫＩ部１２を含む。これら各部は、実在保証装置１０にインストールされた１以上のプログラムが、ＣＰＵ１０４に実行させる処理により実現される。但し、これら各部は、それぞれ異なるコンピュータによって実現されてもよい。

【0036】

法人ｅＫＹＣ部１１は、法人の実在を保証する情報（実在保証情報）を法人に対して提供する。法人ｅＫＹＣ部１１は、法人の実在を保証する情報に対する法人ｅＫＹＣプロバイダによる電子署名の付与を法人ＰＫＩ部１２に実行させる。

【0037】

法人ＰＫＩ部１２は、法人に対して一般的なＰＫＩを提供する。例えば、法人ＰＫＩ部１２は、法人に対して公開鍵証明書や法人ｅＫＹＣプロバイダのルート証明書を配布する。

【0038】

ＣＡサーバ４０は、証明書発行部４１を有する。証明書発行部４１は、ＣＡサーバ４０にインストールされた１以上のプログラムが、ＣＡサーバ４０のＣＰＵに実行させる処理により実現される。

【0039】

証明書発行部４１は、証明書自動発行プロトコルであるＡＣＭＥに基づき電子証明書（本実施の形態では、ＥＶ証明書）の発行を行う。

【0040】

以下、証明書発行支援システムにおいて実行される処理手順について説明する。図４は、証明書発行支援システムにおいて実行される処理手順の一例を説明するためのシーケンス図である。なお、図４において、「法人」の軸は、担当者端末３０ａ、上長端末３０ｂ３０ｂ、従来ＡＣＭＥクライアント部２４、拡張ＡＣＭＥクライアント部２３及び社員認証基盤部２１の集合を表現する。また、図４において、ステップＳ１１～Ｓ１３、Ｓ１７及びＳ１８は、従来のＡＣＭＥに基づくステップである。したがって、拡張ＡＣＭＥクライアント部２３は、これらのステップには関与しない。一方、ステップＳ１４～Ｓ１６は、ＡＣＭＥに対する拡張のステップである。したがって、従来ＡＣＭＥクライアント部２４は、ステップＳ１４～Ｓ１６には関与しない。

【0041】

ステップＳ１１において、法人は、ＣＡサーバ４０に対して法人に対するアカウントを登録する。ＣＡサーバ４０は、アカウントの登録結果を返信する（Ｓ１２）。アカウントの登録では、法人の公開鍵（法人秘密鍵に対応する公開鍵（以下、「法人公開鍵」という。））もＣＡサーバ４０に登録される。そうすることで、ＣＡサーバ４０が、以降のステップにおいて法人の認証ができるようにする。すなわち、以降のステップにおいては、従来のＡＣＭＥと同様に、法人からＣＡサーバ４０へのリクエストごとに、ＣＡサーバ４０は、法人の認証を行う。なお、アカウント登録は、一度行われればよい。

【0042】

続くステップＳ１３～Ｓ１６の実行順序は順不同であり、これら各ステップは非同期に（それぞれ任意のタイミングで）実行されてよい。

【0043】

ステップＳ１３では、法人とＣＡサーバ４０との間で、ＡＣＭＥに従って法人がドメイン（証明書の申請に係るドメイン）を所持することの確認処理が実行される。

【0044】

ステップＳ１４では、法人とＣＡサーバ４０と実在保証装置１０との連携により、法人の実在の確認処理がされる。

【0045】

ステップＳ１５では、法人とＣＡサーバ４０と実在保証装置１０との連携により、法人への担当者の所属（担当者の実在）の確認処理が実行される。

【0046】

ステップＳ１６では、法人とＣＡサーバ４０との連携により、証明書の発行申請が権限の有る人物にも承認されていることの確認処理が実行される。

【0047】

なお、ＣＡサーバ４０は、ステップＳ１３～Ｓ１６が実行されるたびに、法人について何の確認が完了したのかを示す情報を、法人のアカウントに対応付けて記録する。すなわち、ステップＳ１３が正常終了すれば、ＣＡサーバ４０は、法人がドメインを所持することの確認が完了したことを示す情報を記録する。ステップＳ１４が正常終了すれば、ＣＡサーバ４０は、法人が実在することの確認が完了したことを示す情報を記録する。ステップＳ１５が正常終了すれば、ＣＡサーバ４０は、法人に担当者が所属することの確認が完了したことを示す情報を記録する。ステップＳ１６が正常終了すれば、ＣＡサーバ４０は、証明書の発行申請が権限の有るものにも承認されていることの確認が完了したことを示す情報を記録する。なお、ステップＳ１３～Ｓ１６の各ステップにおいて、法人の認証が行われるため、ＣＡサーバ４０は、いずれの法人についての確認であるのかを識別することができる。

【0048】

ステップＳ１３～Ｓ１６の実行後の任意のタイミングにおいて、法人（例えば、従来ＡＣＭＥクライアント部２４）は、証明書発行要求（ＣＳＲ（Certificate Signing Request））をＣＡサーバ４０へ送信する（Ｓ１７）。なお、証明書発行要求においても、ＣＡサーバ４０によって法人の認証が行われる。

【0049】

ＣＡサーバ４０は、証明書発行要求に応じ、当該証明書発行要求の送信元の法人（当該証明書発行要求に関して認証された法人）について、ステップＳ１３～Ｓ１６のいずれの確認が済んでいるのかを確認する。全ての確認が済んでいれば、ＣＡサーバ４０は、当該法人に対するＥＶ証明書を生成し、当該ＥＶ証明書を法人へ返信する（Ｓ１８）。

【0050】

続いて、ステップＳ１４の詳細について説明する。図５は、第１の実施の形態における法人の実在の確認処理の処理手順の一例を説明するためのシーケンス図である。

【0051】

ステップＳ１０１において、担当者端末３０ａは、担当者による入力（法人の実在保証情報の取得指示）に応じ、法人の実在保証情報を法人ｅＫＹＣ部１１へ要求する。法人ｅＫＹＣ部１１は、担当者端末３０ａからの要求に応じ、認証要求を担当者端末３０ａへ送信する（Ｓ１０２）。なお、当該認証要求が法人ｅＫＹＣ部１１から担当者端末３０ａへ送信されるのは、社員を認証可能な社員認証基盤部２１が法人内（証明書申請装置２０内）にあり、実在保証装置１０では社員を認証できないからである。そこで、法人ｅＫＹＣ部１１部は、当該認証要求が社員認証基盤部２１へリダイレクトされるように、当該認証要求を担当者端末３０ａへ送信する。

【0052】

当該認証要求に応じ、担当者端末３０ａは、証明書申請装置２０の社員認証基盤部２１と連携して担当者の認証を実行する（Ｓ１０３）。例えば、担当者端末３０ａは、斯かる認証のための担当者のＩＤ及びパスワードを入力させる画面を表示する。担当者端末３０ａは、当該画面に入力されたＩＤ及びパスワードを社員認証基盤部２１へ送信する。社員認証基盤部２１は、当該ＩＤ及びパスワードを、予め証明書申請装置２０に記憶されている正しいＩＤ及びパスワードと比較し、両者が一致すれば、担当者の認証を成功させる。なお、当該認証は、法人の実在保証情報の取得のため（すなわち、法人ｅＫＹＣ部１１を利用するため）の認証である。

【0053】

担当者の認証に成功した場合、社員認証基盤部２１は、「法人の実在保証情報を法人ｅＫＹＣ部１１に対して要求する」権限を担当者が有するか否かを確認する（Ｓ１０４）。例えば、法人の構成員ごとに権限の有無を示す情報が証明書申請装置２０に記憶されており、社員認証基盤部２１は、当該情報を参照して、担当者に権限が有るか否かを確認する。

【0054】

担当者に権限が有る場合、社員認証基盤部２１は、担当者に権限が有ることを法人ｅＫＹＣ部１１に通知する（Ｓ１０５）。なお、斯かる通知は、どのような手順で実行されてもよい。例えば、法人ｅＫＹＣ部１１は、担当者が権限を有することを示すデータであるトークンを担当者端末３０ａへ送信し、担当者端末３０ａが当該トークンを法人ｅＫＹＣ部１１に送信してもよい。この場合、法人ｅＫＹＣ部１１が当該トークンを伴って権限の有無を社員認証基盤部２１へ照会すると、社員認証基盤部２１が、当該トークンを検証し、当該トークンが正当であれば権限が有ることの通知を法人ｅＫＹＣ部１１へ応答してもよい。

【0055】

担当者に権限が有ることの通知に応じ、法人ｅＫＹＣ部１１は、法人の実在保証情報を生成する（Ｓ１０６）。例えば、法人ｅＫＹＣ部１１は、ＪＳＯＮ（JavaScript（登録商標） Object Notation）形式によって、以下のような実在保証情報を生成する。
{"iss":"https://ekyc.example.com","aud":"xxxx","name":"xxxx Corp",・・・}
なお、上記の実在保証情報において、「xxxx」は、例えば、法人の名称を示す文字列である。

【0056】

続いて、法人ｅＫＹＣ部１１は、当該実在保証情報を法人ＰＫＩ部１２に送信して、当該実在保証情報に対する署名（電子署名）の付与を法人ＰＫＩ部１２に要求する（Ｓ１０７）。法人ＰＫＩ部１２は、法人ＰＫＩを用いて、法人ｅＫＹＣプロバイダの秘密鍵によって当該実在保証情報へ署名を行い（当該実在保証情報へ署名を付与し）、署名済みの実在保証情報を法人ｅＫＹＣ部１１へ応答する（Ｓ１０８）。当該署名により、ＣＡサーバ４０は、当該実在保証情報の真正性を確認することができる。

【0057】

続いて、法人ｅＫＹＣ部１１は、署名済みの当該実在保証情報を証明書申請装置２０の拡張ＡＣＭＥクライアント部２３へ送信する（Ｓ１０９）。但し、当該実在保証情報は、担当者端末３０ａを経由して拡張ＡＣＭＥクライアント部２３へ送信されてもよい。この場合、法人ｅＫＹＣ部１１は、ステップＳ１０１に対する応答として、当該実在保証情報を担当者端末３０ａへ送信する。担当者端末３０ａは、当該実在保証情報を拡張ＡＣＭＥクライアント部２３へ送信する。

【0058】

続いて、拡張ＡＣＭＥクライアント部２３は、当該実在保証情報をＣＡサーバ４０の証明書発行部４１へ送信する（Ｓ１１０）。証明書発行部４１は、当該実在保証情報を受信すると、当該実在保証情報に付与された署名の検証を法人ＰＫＩ部１２に実行させる（Ｓ１１１）。法人ＰＫＩ部１２によって当該署名が正しいことが確認されると、証明書発行部４１は、当該実在保証情報の検証結果を拡張ＡＣＭＥクライアント部２３へ送信する（Ｓ１１２）。なお、証明書発行部４１は、当該実在保証情報を、法人が実在することの確認が完了したことを示す情報としてＣＡサーバ４０に記録する。

【0059】

なお、図４では、実在保証情報は、拡張ＡＣＭＥクライアント部２３によって証明書発行部４１へ送信されるが、最終的に実在保証情報が証明書発行部４１に到達するのであれば、どのような手順が採用されてもよい。ＣＡと法人ｅＫＹＣプロバイダが直接連携し、情報を取得してもよい。その際はＯＡｕｔｈ ２．０をベースとする技術が利用されてもよい。

【0060】

続いて、図４のステップＳ１５の詳細について説明する。図６は、法人への担当者の所属の確認処理の処理手順の一例を説明するためのシーケンス図である。

【0061】

ステップＳ２０１において、担当者端末３０ａは、担当者による入力（担当者の実在保証の要求指示）に応じ、担当者の実在保証を社員認証基盤部２１へ要求する。社員認証基盤部２１は、担当者端末３０ａと連携して担当者の認証を実行する（Ｓ２０２）。認証により、担当者が本人であるか否かが確認される。

【0062】

担当者の認証に成功すると、社員認証基盤部２１は、担当者の実在保証情報を生成する（Ｓ２０３）。例えば、社員認証基盤部２１は、ＪＳＯＮ形式によって、以下のような実在保証情報を生成する。
{"affiliation":"xxx Corp.","name":"yyy",・・・}
なお、上記の実在保証情報において、「xxx」は、例えば、法人の名称を示す文字列であり、「yyy」は、担当者の氏名を示す文字列である。

【0063】

なお、社員認証基盤部２１は、生成した実在保証情報に対して法人秘密鍵を用いて署名を行う（署名を付与する）。法人秘密鍵を用いて当該実在保証情報に対して署名が付与されることで、法人によって担当者の実在（所属）が保証される。また、証明書発行部４１は、当該署名により当該実在保証情報の真正性を確認することができる。なお、署名は、外部のサービスによって行われてもよい。例えば、法人秘密鍵の管理機能や署名機能が外部サービスによって行われてもよい。

【0064】

続いて、社員認証基盤部２１は、署名された当該実在保証情報を拡張ＡＣＭＥクライアント部２３へ送信する（Ｓ２０４）。但し、当該実在保証情報は、担当者端末３０ａを経由して拡張ＡＣＭＥクライアント部２３へ送信されてもよい。この場合、社員認証基盤部２１は、ステップＳ２０１に対する応答として、当該実在保証情報を担当者端末３０ａへ送信する。担当者端末３０ａは、当該実在保証情報を拡張ＡＣＭＥクライアント部２３へ送信する。

【0065】

続いて、拡張ＡＣＭＥクライアント部２３は、当該実在保証情報をＣＡサーバ４０の証明書発行部４１へ送信する（Ｓ２０５）。証明書発行部４１は、当該実在保証情報を受信すると、法人ＰＫＩ部１２と連携して、当該実在保証情報に付与された署名を検証する（Ｓ２０６）。換言すれば、法人ＰＫＩ部１２は、証明書発行部４１と連携して、当該実在保証情報に付与された署名を検証する。例えば、証明書発行部４１は、法人ＰＫＩ部１２から法人公開鍵の配布を受けて、当該署名を検証する。但し、法人公開鍵の配布は他の方法（他のタイミング）で行われてもよい。又は、法人ＰＫＩ部１２が、当該実在保証情報に付与された署名を検証し、その結果を証明書発行部４１へ送信してもよい。

【0066】

当該署名が正しいことが確認されると、証明書発行部４１は、当該署名の検証結果を担当者端末３０ａへ送信する（Ｓ２０７）。なお、証明書発行部４１は、当該実在保証情報を、法人へ担当者が所属することの確認が完了したことを示す情報としてＣＡサーバ４０に記録する。

【0067】

続いて、図４のステップＳ１６の詳細について説明する。図７は、証明書の発行申請が権限の有るものにも承認されていることの確認処理の処理手順の一例を説明するためのシーケンス図である。

【0068】

ステップＳ３０１において、担当者端末３０ａは、担当者による入力（証明書の発行申請に関する承認の要求指示）に応じ、証明書の発行申請の承認要求を上長端末３０ｂへ送信する。上長端末３０ｂは、当該承認要求を表示等することにより上長へ通知する。上長は、当該承認要求に係る発行申請を確認し、承認が可能であれば承認する旨を上長端末３０ｂへ入力する（Ｓ３０２）。

【0069】

上長端末３０ｂは、承認する旨の入力に応じ、上長に権限が有ることの保証を社員認証基盤部２１へ要求する。社員認証基盤部２１は、上長端末３０ｂと連携して上長の認証を実行する（Ｓ３０４）。認証により、上長が本人であるか否かが確認される。なお、認証方法は、担当者の場合と同様でよい。

【0070】

上長の認証に成功すると、社員認証基盤部２１は、上長の権限を示す属性情報を社員情報基盤部２２へ要求する（Ｓ３０５）。この際、上長のＩＤが社員情報基盤部２２へ通知される。社員情報基盤部２２は、当該ＩＤに対応する、属性情報（すなわち、上長の属性情報）を含む応答を社員認証基盤部２１へ送信する（Ｓ３０６）。なお、各社員の属性情報は、例えば、各社員のＩＤに対応付けられて補助記憶装置１０２等に記憶されている。当該属性情報は、例えば、以下のような形式で、上長の役職や部署等を含む情報である。
{"Position":"Manager","Department":"yyy",…}
続いて、社員認証基盤部２１は、当該属性情報に対して法人秘密鍵を用いて署名を行う（署名を付与する）（Ｓ３０７）。法人秘密鍵を用いて当該実在保証情報に対して署名が付与されることで、当該属性情報が法人によって保証される。

【0071】

続いて、社員認証基盤部２１は、署名された当該属性情報を拡張ＡＣＭＥクライアント部２３へ送信する（Ｓ３０８）。但し、当該属性情報は、上長端末３０ｂ及び担当者端末３０ａを経由して拡張ＡＣＭＥクライアント部２３へ送信されてもよい。この場合、社員認証基盤部２１は、ステップＳ３０３に対する応答として、当該属性情報を上長端末３０ｂへ送信する。上長端末３０ｂは、ステップＳ３０１に対する応答として、当該属性情報を担当者端末３０ａへ送信する。担当者端末３０ａは、当該属性情報を拡張ＡＣＭＥクライアント部２３へ送信する。

【0072】

続いて、拡張ＡＣＭＥクライアント部２３は、当該属性情報をＣＡサーバ４０の証明書発行部４１へ送信する（Ｓ３０９）。証明書発行部４１は、当該属性情報を受信すると、法人ＰＫＩ部１２と連携して、当該属性情報に付与された署名を検証する（Ｓ３１０）。換言すれば、法人ＰＫＩ部１２は、証明書発行部４１と連携して、当該属性情報に付与された署名を検証する。例えば、証明書発行部４１は、法人ＰＫＩ部１２から法人公開鍵の配布を受けて、当該署名を検証する。但し、法人公開鍵の配布は他の方法（他のタイミング）で行われてもよい。又は、法人ＰＫＩ部１２が、当該属性情報に付与された署名を検証し、その結果を証明書発行部４１へ送信してもよい。

【0073】

当該署名が正しいことが確認されると、証明書発行部４１は、当該属性情報を、証明書の発行申請が権限の有る人物にも承認されたことの確認が完了したことを示す情報としてＣＡサーバ４０に記録する。

【0074】

なお、属性情報が都度確認されたことを明らかにするため（リプレイされることを防ぐため）、証明書発行部４１がチャレンジトークンを発行し、社員認証基盤部２１が、そのチャレンジトークンを含めて属性情報に署名してもよい。

【0075】

なお、上長が取締役などの場合は、図７のシーケンスとは異なる手順で、権限の有るものにも承認されていることの確認を実施することができる。図７では、法人内の情報（役職など）の真正性を外部に示すため、法人秘密鍵を用いて属性情報を保証した。一方、取締役の場合、商業登記により情報が公開されているので、客観的に「役職」の確認ができる。そのため、取締役が承認した（個人の）署名などの証跡が検証できればよい。この場合の署名は、公的な機関が個人に発行する秘密鍵により生成されたものなどが考えられる（マイナンバーカード内の秘密鍵を利用するなど。）。

【0076】

上述したように、第１の実施の形態によれば、ＡＣＭＥを拡張することで、法人の実在を電子的に確認することができると共に、法人への担当者（申請者）の所属を保証するｅＫＹＣ（（個人の）電子的な身元確認）を実現することができる。更に、証明書の発行申請が法人内（組織内）において権限の有る人物にも承認されていることを保証することができる。その結果、ＥＶ証明書の申請を全て電子的に実行することができ、ひいてはＥＶ証明書の自動的な発行を支援することができる。

【0077】

なお、図７は、証明書発行に特化した処理手順だが、「組織内で付与された属性情報の確認」自体は、構成員のｅＫＹＣとして、その他のユースケースにも利用可能である。例えば、証券口座開設時には、インサイダー取引の未然防止を目的に、勤め先や役職の登録を行う。現在は、自身で情報の入力を行うため、必ずしもその情報が正しくない場合がある。口座開設時に構成員のｅＫＹＣを行い、会社から保証された正しい情報を証券会社に提供する、といった使い方が考えられる。 次に、第２の実施の形態について説明する。第２の実施の形態では第１の実施の形態と異なる点について説明する。第２の実施の形態において特に言及されない点については、第１の実施の形態と同様でもよい。

【0078】

第２の実施の形態では、図４のステップＳ１４の処理手順（すなわち、図５の処理手順）の変形例を示す。

【0079】

図８は、第２の実施の形態における証明書発行支援システムの機能構成例を示す図である。図８において、実在保証装置１０は、更に、実在保証用認証部１３を有する。実在保証用認証部１３は、実在保証装置１０にインストールされた１以上のプログラムが、ＣＰＵ１０４に実行させる処理により実現される。

【0080】

実在保証用認証部１３は、法人の実在保証のための担当者の認証を行う。斯かる認証を可能にするため、第２の実施の形態では、実在保証の要求が許可される担当者のアカウントが実在保証装置１０に事前に登録される。斯かるアカウントの登録には、ＳＣＩＭ（System for Cross-Domains Identity Management）が利用されてもよい。

【0081】

図９は、第２の実施の形態における法人の実在の確認処理の処理手順の一例を説明するためのシーケンス図である。図９中、図５と同一ステップには同一ステップ番号を付し、その説明は適宜省略する。

【0082】

図９では、図５のステップＳ１０２～Ｓ１０５が、ステップＳ１０２ａ～Ｓ１０５ａに置き換わる。

【0083】

ステップＳ１０２ａにおいて、法人ｅＫＹＣ部１１は、担当者の認証を実在保証用認証部１３へ要求する。当該認証の要求に応じ、実在保証用認証部１３は、担当者端末３０ａと連携して担当者の認証を実行する（Ｓ１０３ａ）。例えば、実在保証用認証部１３は、斯かる認証のための担当者のＩＤ及びパスワードを入力させる画面を表示させるＷｅｂページを担当者端末３０ａへ送信する。担当者端末３０ａは、当該Ｗｅｂページに基づき当該画面を表示する。担当者端末３０ａは、当該画面に入力されたＩＤ及びパスワードを実在保証用認証部１３へ送信する。実在保証用認証部１３は、当該ＩＤ及びパスワードを、予め登録されているアカウント（正しいＩＤ及びパスワード）と比較し、両者が一致すれば、担当者の認証を成功させる。なお、実在保証用認証部１３は、社員認証基盤部２１と連携して担当者の認証を行ってもよい。

【0084】

担当者の認証に成功した場合、実在保証用認証部１３は、「法人の実在保証情報を法人ｅＫＹＣ部１１に対して要求する」権限を担当者が有するか否かを確認する（Ｓ１０４ａ）。例えば、斯かる権限を有する者を示す情報が実在保証装置１０に記憶されており、実在保証用認証部１３は、当該情報を参照して、担当者に権限が有るか否かを確認する。

【0085】

担当者に権限がある場合、実在保証用認証部１３は、担当者に権限があることを法人ｅＫＹＣ部１１に通知する（Ｓ１０５ａ）。以降は、図５と同様である。

【0086】

第２の実施の形態では、担当者の認証機能が実在保証装置１０内に存在するため、実在保証装置１０が担当者に直接的に認証機能を提供することが可能となる。また、担当者に権限が有ることの通知も実在保証装置１０内の連携で済むようになる。

【0087】

なお、第１の実施の形態の場合、実在保証装置１０は、実在保証の要求元（申請者）がどの社員であるかまで知る必要はない（法人ｅＫＹＣプロバイダは、権限の有る社員が要求したことしか分からず、社員の誰が要求しているのかまで分からない。）。一方、第２の実施の形態では、法人ｅＫＹＣプロバイダは、当該申請者が社員の誰であるかが分かる。

【0088】

なお、上記各実施の形態において、法人は、第１の組織の一例である。法人ｅＫＹＣプロバイダは、第２の組織の一例である。法人ＰＫＩ部１２は、第１の付与部及び検証部の一例である。法人の実在保証情報は、第１の情報の一例である。社員の実在保証情報は、第２の情報の一例である。社員情報基盤部２２は、第２の付与部の一例である。拡張ＡＣＭＥクライアント部２３は、送信部の一例である。属性情報は、第３の情報の一例である。

【0089】

以上、本発明の実施の形態について詳述したが、本発明は斯かる特定の実施形態に限定されるものではなく、請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。

【符号の説明】

【0090】

１０ 実在保証装置
１１ 法人ｅＫＹＣ部
１２ 法人ＰＫＩ部
１３ 実在保証用認証部
２０ 証明書申請装置
２１ 社員認証基盤部
２２ 社員情報基盤部
２３ 拡張ＡＣＭＥクライアント部
２４ 従来ＡＣＭＥクライアント部
２５ 秘密鍵記憶部
３０ａ 担当者端末
３０ｂ 上長端末
４０ ＣＡサーバ
４１ 証明書発行部
１００ ドライブ装置
１０１ 記録媒体
１０２ 補助記憶装置
１０３ メモリ装置
１０４ ＣＰＵ
１０５ インタフェース装置
Ｂ バス

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】