JP2015219822A - ワンストップ申請システム、ワンストップ申請方法およびプログラム - Google Patents

Abstract

【課題】特定の申請先に特定の項目のみを開示し、かつ、トラヒック集中を抑えて装置等にかかるコストを低減できるワンストップ申請システム等を提供する。【解決手段】申請サーバ１００と、複数の申請受付装置３００、４００と、を備えるワンストップ申請システムであって、申請サーバは、利用者端末からの申請情報に応じた情報であって項目ごとに暗号化された本体部分と、申請先となる申請受付装置および申請の順番を指定するヘッダ情報と、を含む申請書を生成し、申請受付装置は、必要な項目を復号して所定の処理を実行し、ヘッダ情報に基づいて申請サーバまたは自装置とは異なる申請受付装置に申請書を送信する。【選択図】図１

Description

本発明は、情報開示の制御が可能なワンストップ申請システム、ワンストップ申請方法およびプログラムに関するものである。

近年、情報通信機器の発展によって、従来紙に印刷されていた書類の多くが電子化されるようになってきており、書類の審査、回覧、承認といった業務の処理が、ネットワークを利用した電子的なワークフローシステムを利用して行われるようになってきている。

そして、ワークフローシステム内でやり取りされる電子化された書類（電子文書）は、安全性の観点から、必要な者以外の者には開示しないことが望まれる。

例えば、特許文献１は、フロー制御装置で申請書の特定の項目を項目毎の項目共通鍵で暗号化した暗号化項目と、項目共通鍵を権限毎の暗号化鍵で暗号化した鍵暗号化情報と、権限毎に閲覧可能な項目を特定する閲覧箇所管理テーブルと、からなる暗号化申請書を生成する。暗号化申請書を受け取った承認装置では、権限に応じた項目のみを暗号化申請書から復号できる。そのため、特定の申請先に対して特定の情報（項目）のみが開示される。

特開２００９−１３４５９８号公報

しかし、特許文献１に記載の手法では、例えば特許文献１の図１７に示されるように、フロー制御装置にトラヒック（traffic）が集中し、トラヒック負荷（通信回数・容量、保持データ容量）が増大する。そのため、ワークフローシステムを構成する装置等にかかるコストも増大するという問題があった。

この問題点に鑑みてなされた本発明の目的は、特定の申請先に特定の項目のみを開示し、かつ、トラヒック集中を抑えて装置等にかかるコストを低減できるワンストップ申請システム、ワンストップ申請方法およびプログラムを提供することにある。なお、ワンストップ申請システムはワークフローシステムの一つであり、ワンストップサービスを申請できるようにするシステムのことである。ワンストップサービスとは一つの場所で様々なサービスが受けられる環境、場所のことである。また、サービスとして例えば公的な証明書の発行や行政サービスの申し込み等を挙げることができるが、これらに限られるものではない。

前記課題を解決するため、本発明に係るワンストップ申請システムは、申請サーバと、複数の申請受付装置と、を備えるワンストップ申請システムであって、前記申請サーバは、利用者端末からの申請情報に応じた情報であって項目ごとに暗号化された本体部分と、申請先となる前記申請受付装置および申請の順番を指定するヘッダ情報と、を含む申請書を生成し、前記申請受付装置は、必要な項目を復号して所定の処理を実行し、前記ヘッダ情報に基づいて前記申請サーバまたは自装置とは異なる前記申請受付装置に前記申請書を送信することを特徴とする。

また、本発明に係るワンストップ申請方法は、申請サーバと、複数の申請受付装置と、を備えるシステムのワンストップ申請方法であって、前記申請サーバが、利用者端末からの申請情報に応じた情報であって項目ごとに暗号化された本体部分と、申請先となる前記申請受付装置および申請の順番を指定するヘッダ情報と、を含む申請書を生成するステップと、前記申請受付装置が、必要な項目を復号して所定の処理を実行し、前記ヘッダ情報に基づいて前記申請サーバまたは自装置とは異なる前記申請受付装置に前記申請書を送信する送信ステップと、を含むことを特徴とする。

また、本発明に係るプログラムは、コンピュータを、申請サーバと、申請書の必要な項目を復号して所定の処理を実行し、前記申請書のヘッダ情報に基づいて前記申請サーバまたは自装置とは異なる申請受付装置に前記申請書を送信する、複数の前記申請受付装置と、を備えるシステムの前記申請サーバとして機能させるプログラムであって、前記コンピュータに、利用者端末からの申請情報に応じた情報であって項目ごとに暗号化された前記申請書の本体部分を生成させる処理と、申請先となる前記申請受付装置および申請の順番を指定する前記申請書の前記ヘッダ情報を生成させる処理と、を実行させることを特徴とする。

本発明に係るワンストップ申請システム、ワンストップ申請方法およびプログラムによれば、特定の申請先に特定の項目のみを開示し、かつ、トラヒック集中を抑えて装置等にかかるコストを低減できる。

本実施形態のワンストップ申請システムの概略構成を示す図である。 申請サーバの構成例を示す図である。 アクセス権管理テーブルの例を示す図である。 申請先テーブルの例を示す図である。 申請書のヘッダ情報の構成例を示す図である。 申請書の全体の構成例を示す図である。 鍵発行管理サーバの構成概略を例示する図である。 鍵発行情報管理テーブルの例を示す図である。 ステータステーブルの例を示す図である。 申請受付装置の構成概略を例示する図である。 ワンストップ申請システムの処理について説明する図である。

以下、本発明の一つの実施形態について適宜図面を参照しながら説明する。図１は、本実施形態に係るワンストップ申請システム１０の構成を示す図である。まず、ワンストップ申請システム１０全体の構成について説明する。

（ワンストップ申請システムの概略構成）
図１は、本実施形態のワンストップ申請システムの概略構成を示す図である。図１のワンストップ申請システム１０は、利用者が利用者端末Ｙを用いてワンストップ申請ができるようにするシステムである。ワンストップ申請とはワンストップサービスにおいてサービスを申請することであり、ワンストップサービスは前記のように一つの場所で様々なサービスが受けられる環境、場所のことである。

ワンストップ申請システム１０は、ネットワークＸで相互に接続された申請サーバ１００、鍵発行管理サーバ２００、複数の申請受付装置を備える。本実施形態において、ワンストップ申請システム１０は、２つの申請受付装置３００および申請受付装置４００を備えるが、３つ以上であってもよい。また、本実施形態において、ネットワークＸはインターネットである。以下の説明において、申請受付装置のそれぞれを区別して説明する場合に、申請受付装置３００に代えて、その識別子である「申請先１」を用いることがある。また、申請受付装置４００に代えて、その識別子である「申請先２」を用いることがある。

ワンストップ申請システム１０は、ネットワークＸに接続される利用者端末Ｙを用いて、利用者からのワンストップ申請を受け付ける。また、ワンストップ申請システム１０は、申請が完了した旨の通知（申請完了通知）を利用者端末Ｙに送信する。このとき、申請の結果物が利用者端末Ｙに出力されてもよい。利用者が申請する内容としては、例えば住民票のような公的な証明書の発行、公共施設の使用申込、公共工事の入札等が挙げられるが、このようなものに限定されない。また、利用者端末Ｙは例えばディスプレイやプリンタを備えた一般的なパソコンであってもよいし、タッチパネル式のユーザーインターフェースを備える専用端末等であってもよい。

申請サーバ１００は、利用者端末Ｙからの申請情報に応じた申請書を生成する。申請情報とは、利用者が申請した内容を示すデータである。また、申請サーバ１００は、申請書を項目ごとに暗号化する。鍵発行管理サーバ２００は、申請受付装置３００、４００のそれぞれの要求に応じて復号のための鍵を発行する。申請受付装置３００、４００は、申請書に対して所定の処理を実行する。そのため、申請受付装置３００、４００は、自ら（以下、自装置とも表現する）が所定の処理を実行する前に、必要な項目について、鍵発行管理サーバ２００から受け取った鍵を用いて復号する。なお、申請受付装置ごとに所定の処理は異なり、例えば申請受付装置３００は第１の項目についての集計処理を、申請受付装置４００は第２の項目についての適否判定処理をしてもよい。この例において、申請受付装置３００は第２の項目については復号せずに第１の項目の集計処理を実行し、申請受付装置４００は第１の項目については復号せずに第２の項目の適否判定処理を実行することができる。つまり、ワンストップ申請システム１０では、特定の申請先に対して特定の情報（項目）のみを開示することが可能である。

（申請サーバの構成）
図２は申請サーバ１００の構成例を示す図である。申請サーバ１００は、申請書生成部１０１と、暗号化部１０２と、申請書送受信部１０３と、署名検証部１０４と、記憶部１０５と、通信部１０６と、を備える。

申請書生成部１０１は申請情報に応じて申請書を生成する。申請書生成部１０１が生成する申請書は、申請受付装置３００、４００による一連の処理が実施される前の初期の申請書である。後述するように、申請受付装置３００、４００は所定の処理を実行した後に申請書に署名（電子署名）する。初期の申請書は、申請情報に応じた必要な項目が用意されているが、申請受付装置３００、４００による署名がされていない申請書である。

暗号化部１０２は申請書を項目ごとに暗号化する。暗号化部１０２は、各項目の暗号鍵を用いて暗号化を実施する。後述するように、各項目の申請先（開示先）および暗号鍵は、アクセス権管理テーブルとして記憶部１０５に記憶されている。

申請書送受信部１０３は、通信部１０６を介して、申請受付装置３００、４００との間で申請書を送受信する。申請書送受信部１０３は、申請書生成部１０１が生成した初期の申請書を送信して、必要な全ての署名を有する最終的な申請書を受信する。

ここで、従来のシステムでは、複数の申請受付装置のそれぞれが申請書に対して処理を実行して署名した後にフロー制御装置（本実施形態における申請サーバ１００に対応）に申請書を送信し、フロー制御装置は受け取った申請書を次の申請受付装置へと送信していた。そのため、従来のシステムではフロー制御装置にアクセスが集中していた。本実施形態において、申請サーバ１００の申請書送受信部１０３は、初期の申請書を送信し、最終的な申請書を受信するため、申請サーバ１００にアクセスが集中する問題は生じない。

署名検証部１０４は、申請書送受信部１０３が受信する最終的な申請書に、全ての署名が正しく含まれているかを検証する。署名検証部１０４によって署名が検証されて、正しいと判定されると申請完了通知が利用者端末Ｙに送信される。

記憶部１０５は、申請書の処理制御に関するデータ（例えば、後述するアクセス権管理テーブル、申請先テーブル）の他、申請書やその生成過程における中間データを記憶する。記憶部１０５は、例えば不揮発性メモリ、揮発性メモリ、ハードディスク等の少なくとも１つの記憶装置を備えて構成される。

通信部１０６は、利用者端末Ｙから申請情報を受け取る。また、通信部１０６は、申請受付装置３００、４００との間で申請書を送受信したり、申請完了通知を利用者端末Ｙに出力したりする。通信部１０６と利用者端末Ｙ、申請受付装置３００、４００との通信は、ネットワークＸを介して実行される。

ここで、申請サーバ１００は、記憶部１０５に記憶されるプログラムに従って動作するコンピュータであってもよい。つまり、申請書生成部１０１、暗号化部１０２、申請書送受信部１０３、署名検証部１０４、および通信部１０６の一部または全てがソフトウェアで実現されてもよい。例えば、記憶部１０５に記憶されるプログラムが、コンピュータを申請サーバ１００の申請書生成部１０１として機能させて、後述するヘッダ情報を含む申請書を生成させてもよい。

図３、図４は、それぞれ本実施形態におけるアクセス権管理テーブル、申請先テーブルを示す図である。本実施形態において、これらのテーブルは記憶部１０５に記憶されている。また図５、図６は、それぞれ本実施形態におけるヘッダ情報、申請書の構成例を説明するための図である。

申請書生成部１０１は、図６に示されるように、申請書生成部１０１は本体部分以外にヘッダ情報を含む申請書１１４を生成する。ここで、本体部分は申請情報に応じて生成される。一方、ヘッダ情報は、ワンストップ申請システム１０において最終的な申請書を生成するまでの処理に関する情報を含む。

申請書生成部１０１は、申請書１１４を生成する際に、アクセス権管理テーブル、申請先テーブルを参照する。図３に示されるように、アクセス権管理テーブル１１１は、申請種別、申請書項目、暗号鍵、申請先の情報を含む。また、図４に示されるように、申請先テーブル１１２は、申請種別、申請先、送信アドレスの情報を含む。

申請種別は、申請書１１４の種類を示すものである。図３、図４の例では“Ｘ０１”のみが示されているが、一般に複数の種類が存在し得る。

申請書項目は、申請書１１４の種類に応じて定まる、本体部分の項目を示すものである。図３の例では“項目１”〜“項目４”までが示されており、それぞれが個別に暗号化されて復号される。

暗号鍵は、“項目１”〜“項目４”のそれぞれの暗号化に用いる鍵の種類を表す。図３の例では“項目１”および“項目４”については、暗号鍵Ａが使用され、“項目２”、“項目３”については、それぞれ暗号鍵Ｂ、Ｃが使用される。

申請先は、項目ごとに申請する（開示する）申請受付装置を、識別子を用いて示したものである。図３の例では、項目１は申請先１および申請先２に開示されて、項目３は申請先２だけに開示される。ここで、申請先テーブルにおける申請先は候補の全てを含み、図４の例では、申請種別が“Ｘ０１”である場合に申請先１および申請先２に申請される可能性があることを示す。

送信アドレスは申請先の固有のアドレスであるとともにＩＤとしても使用され得る。図４の例では、申請先１の送信アドレスは“ＡＡＡＡ”であり、申請先２の送信アドレスは“ＢＢＢＢ”である。これにより申請サーバ１００が初期の申請書を適切な申請先（申請受付装置３００または４００）に送信することを可能にするとともに、ワンストップ申請システム１０においてＩＤベース暗号（ＩＢＥ：ID-Based Encryption）が実行されることを可能にする。

図５はヘッダ情報１１３の例を示す。図５の例では上から＜申請先１＞、＜申請先２＞と記載されており、申請書１１４の申請（開示）先は申請先１および申請先２であり、申請の順番は最初に申請先１、最後に申請先２であることがわかる。また、図５のヘッダ情報１１３の例では、固有の申請書番号がＸ０１０００１であることも記載されている。なお、＜申請種別＞の欄も設けられているが、最初の３桁（Ｘ０１）が申請種別を示すように申請書番号が付されているため“Ｘ０１”の記載は省略されている。このように、申請書１１４にヘッダ情報１１３が含まれることで、申請書１１４を受け取る申請受付装置３００、４００は、申請書１１４の処理の流れ、申請種別等を把握することが可能である。

（鍵発行管理サーバの構成）
図７は鍵発行管理サーバ２００の構成例を示す図である。鍵発行管理サーバ２００は、鍵発行情報受信部２０１と、鍵発行部２０２と、ステータス管理部２０３と、記憶部２０４と、通信部２０５と、を備える。

鍵発行情報受信部２０１は、通信部２０５を介して、申請書１１４のヘッダ情報１１３を取得する。そして、鍵発行情報受信部２０１は、後述する鍵発行情報管理テーブルに必要な情報を格納する。

鍵発行部２０２は、複数の申請受付装置のうち、申請書１１４に対して所定の処理を実行するものに対して鍵を発行する。鍵発行部２０２は、鍵を発行する際に、鍵発行情報管理テーブルを参照する。

図８は鍵発行情報管理テーブル２１１の一例を示す図である。なお、図８の項目のうち申請書番号および申請先は図３〜図５と同じであるため説明を省略する。図８に示されるように、鍵発行情報管理テーブル２１１は、申請書番号、申請先、および復号鍵を発行するための情報である“復号鍵発行情報”を含む。共通鍵暗号方式での暗号化が行われる場合には、復号鍵発行情報は共通鍵そのものであってもよい（図８の“ＺＺＺＺ”、“ＥＥＥＥ”）。また、公開鍵暗号方式の一種であるＩＤベース暗号が用いられる場合には、復号鍵発行情報は申請先の固有の属性（例えば“送信アドレス”）であってもよい（図８の“ＡＡＡＡ”、“ＢＢＢＢ”）。なお、図８の鍵発行情報管理テーブル２１１の例では、申請先ごとに復号鍵発行情報を設定しているが、申請先および項目ごとに復号鍵発行情報を設定してもよい。このとき、例えば項目別に共通鍵を用意するといった、さらに細かい設定への対応が可能になる。

本実施形態のワンストップ申請システム１０においては、共通鍵暗号方式とＩＤベース暗号とを選択可能である。鍵発行部２０２は、鍵発行情報管理テーブル２１１を参照して、申請先および暗号の方式に応じて適切な復号鍵発行情報を選択し、選択した復号鍵発行情報に基づいて鍵を発行する。

再び、図７を参照する。ステータス管理部２０３は、申請書番号ごとの進捗状況をステータステーブルにまとめて管理する。ステータス管理部２０３は、利用者端末Ｙから進捗状況の問い合わせがある場合には、ステータステーブルを参照して利用者端末Ｙに回答する。

ここで、従来のシステムでは、各申請先との間の申請書の送受信に基づいてフロー制御装置（本実施形態における申請サーバ１００に対応）が進捗管理をしていた。前記のように、本実施形態において申請サーバ１００は、初期の申請書を送信し、最終的な申請書を受信するだけであるため、申請書１１４の送受信によっては細かい進捗状況を把握できない。しかし、利用者は、必要に応じて利用者端末Ｙから鍵発行管理サーバ２００にアクセスすることで進捗状況を把握可能である。つまり、本実施形態においても従来の手法と同様に進捗状況を把握することができ、申請サーバ１００の処理の負担は軽減されている。

図９はステータステーブル２１２の一例を示す図である。なお、図９における申請種別、申請書番号は、図３〜図５、図８と同じであり説明を省略する。また、図９における申請先１、申請先２は、鍵発行管理サーバ２００がそれぞれ申請受付装置３００、申請受付装置４００に鍵を発行したか（発行済）、否か（未）を示すものである。つまり、図９における申請先１、申請先２は、鍵の発行の有無を示す。また、図９における申請処理は、申請受付装置３００、４００による申請書１１４に対する一連の処理が完了したか（完了）、完了していないか（処理中）を示すものである。

ステータス管理部２０３は、鍵発行部２０２が申請先１、申請先２に鍵を発行したか否かの情報を取得して、ステータステーブル２１２に反映させる。また、ステータス管理部２０３は、申請書１１４のヘッダ情報１１３を取得することで、申請書１１４が申請（開示）される順番を把握可能であるため、ステータステーブル２１２の申請処理の項目についても反映させることができる。

再び、図７を参照する。記憶部２０４は、鍵発行情報管理テーブル２１１、ステータステーブル２１２の他、鍵発行部２０２が発行する鍵やその生成過程における中間データを記憶する。記憶部２０４は、例えば不揮発性メモリ、揮発性メモリ、ハードディスク等の少なくとも１つの記憶装置を備えて構成される。

通信部２０５は、鍵発行管理サーバ２００が利用者端末Ｙから進捗状況の問い合わせを受け付けて回答を送信する際に用いられる。また、通信部２０５は、鍵発行管理サーバ２００が申請サーバ１００からヘッダ情報１１３等を取得する際に用いられる。また、通信部２０５は、鍵発行管理サーバ２００が申請受付装置３００、４００からの鍵の発行リクエストを受け付けて鍵を発行する際に用いられる。通信部２０５と利用者端末Ｙ、申請受付装置３００、４００との通信は、ネットワークＸを介して実行される。

（申請受付装置の構成）
図１０は申請受付装置３００、４００の構成例を示す図である。ワンストップ申請システム１０では、同じ構成の申請受付装置を複数含み、申請受付装置３００の構成は申請受付装置４００の構成と同じである。そこで、以下では申請受付装置３００のみについて説明する。申請受付装置３００は、申請書送受信部３０１と、復号鍵取得部３０２と、復号部３０３と、申請書処理部３０４と、署名部３０５と、記憶部３０６と、通信部３０７と、を備える。

申請書送受信部３０１は、通信部３０７を介して、申請書１１４を送受信する。申請書送受信部３０１は、申請サーバ１００から初期の申請書を受信してもよいし、自装置以外の申請受付装置からの申請書１１４を受信してもよい。申請書送受信部３０１は受信した申請書１１４を復号鍵取得部３０２に出力する。

また、申請書送受信部３０１は、受信した申請書のヘッダ情報１１３を解析して、次の送付先を決定する。前記のように、ヘッダ情報１１３には申請書１１４が申請（開示）される順が記載されているため、自装置（この例では“申請先１”）が申請書１１４に対して実行する所定の処理が、最後の処理であるか否かを判定できる。申請書送受信部３０１は、自装置が申請書１１４に対する最後の処理を実行する場合には、“最終的な申請書”を送信することになるので、次の送付先を申請サーバ１００に設定する。それ以外の場合には、申請書送受信部３０１は、次の送付先をヘッダ情報１１３で指定される自装置とは異なる申請受付装置に設定する。

復号鍵取得部３０２は、申請書送受信部３０１が申請書１１４を受信した後にヘッダ情報１１３を取得して、例えば申請書番号等を特定してから、鍵発行管理サーバ２００に鍵の発行リクエストを行う。そして、復号鍵取得部３０２は、通信部３０７を介して、鍵発行管理サーバ２００から鍵を取得する。

復号部３０３は、復号鍵取得部３０２が取得した鍵を受け取り、申請書送受信部３０１が受信した申請書１１４の必要な項目を復号する。そして、復号部３０３は、必要な項目の復号がされた申請書１１４をオリジナルの申請書１１４とともに申請書処理部３０４に出力する。

申請書処理部３０４は所定の処理を実行する。所定の処理とは、例えば復号された項目に対する承認、適否判定等であってもよいし、復号された項目のデータを用いた演算処理等であってもよい。このとき、自装置の申請書処理部３０４が実行する所定の処理と関係ない項目については、暗号化されているため申請書１１４の安全性が保たれる。

署名部３０５は、オリジナルの申請書１１４を取得して電子署名を付す。そして、署名を付された申請書１１４は、申請書送受信部３０１が定めた次の送付先に送信される。

記憶部３０６は、例えば署名部３０５が付す電子署名を記憶したり、復号部３０３が復号の際に生成する中間データを記憶したりする。記憶部３０６は、例えば不揮発性メモリ、揮発性メモリ、ハードディスク等の少なくとも１つの記憶装置を備えて構成される。

通信部３０７は、申請受付装置３００が鍵の発行リクエストをし、鍵発行管理サーバ２００から発行された鍵を取得する際に用いられる。また、通信部３０７は、申請受付装置３００が申請書１１４を申請サーバ１００、または他の申請受付装置と送受信する際に用いられる。通信部３０７と申請サーバ１００、鍵発行管理サーバ２００、他の申請受付装置４００との通信は、ネットワークＸを介して実行される。

（ワンストップ申請システムの処理）
図１１は本実施形態のワンストップ申請システム１０の処理を説明するフローチャートである。以下に、ワンストップ申請システム１０の処理（ワンストップ申請方法）についてステップごとに説明する。なお、図１１において、利用者端末Ｙ、申請サーバ１００、鍵発行管理サーバ２００、申請受付装置３００および申請受付装置４００は、図１〜図１０と同じであるため個別の説明を省略する。

最初に、申請サーバ１００の申請書生成部１０１は、通信部１０６を介して利用者端末Ｙから申請情報を受け付け、申請書１１４を生成する（ステップＳ１）。

申請サーバ１００は、記憶部１０５の申請先テーブル１１２を参照してヘッダ情報１１３を生成し、申請書１１４に埋め込んで、暗号化部１０２に渡す。申請サーバ１００の暗号化部１０２は、申請書生成部１０１より、申請書１１４を受け取り、記憶部１０５のアクセス権管理テーブル１１１を参照して申請書１１４の項目ごとに暗号化を行う。例えば、図３のようなアクセス権管理テーブル１１１が記憶部１０５に格納されている場合、項目１と項目４を暗号鍵Ａで暗号化し、項目２を暗号鍵Ｂで暗号化し、項目３を暗号鍵Ｃで暗号化する。そして、申請サーバ１００は、申請書１１４、ヘッダ情報１１３、項目ごとの開示先情報、復号鍵発行に必要な情報を、鍵発行管理サーバ２００および申請受付装置の１つに渡す（ステップＳ２）。図１１の例では、申請サーバ１００の申請書送受信部１０３はヘッダ情報１１３を参照して、申請受付装置３００へ申請書１１４を送信する。そして、申請サーバ１００は、鍵発行管理サーバ２００にヘッダ情報１１３、項目ごとの開示先情報、復号鍵発行に必要な情報を送信する。

ここで、申請サーバ１００から送信される情報は、前記の内容に限定されるものではなく、例えば暗号化方式によっても異なる。共通鍵暗号方式であれば暗号化に用いた暗号鍵が送信されてもよいし、ＩＤベース暗号であれば暗号鍵の送信は不要である。

鍵発行管理サーバ２００の鍵発行情報受信部２０１は、通信部２０５を介してヘッダ情報１１３等を受け取り、記憶部２０４の鍵発行情報管理テーブル２１１に格納する。

申請受付装置３００の申請書送受信部３０１は、通信部３０７を介して申請書１１４を受け取り、復号鍵取得部３０２に渡す。復号鍵取得部３０２は申請書１１４のヘッダ情報１１３から申請書番号を抽出し、申請書番号と自装置の識別子（この例では申請先１）を鍵発行管理サーバ２００に送信して復号鍵の要求、すなわち鍵の発行リクエストを行う（ステップＳ３）。

鍵発行管理サーバ２００の鍵発行部２０２は、通信部２０５を介して、申請書番号等を受信する。そして、鍵発行部２０２は、記憶部２０４の鍵発行情報管理テーブル２１１を参照して、該当する復号鍵を発行し、通信部２０５を介して鍵を申請受付装置３００に送信する（ステップＳ４）。なお、ステップＳ４において、鍵発行管理サーバ２００は申請受付装置３００（または、申請受付装置３００の操作者）の認証を行ってから鍵を発行してもよい。このとき、誤って鍵発行管理サーバ２００が復号鍵を発行することを防止することができる。

また、鍵発行部２０２は、ステータス管理部２０３に申請受付装置３００からの申請書番号等を渡す。ステータス管理部２０３は、記憶部２０４のステータステーブル２１２に申請受付装置３００に復号鍵が発行されたことを書き込む。

申請受付装置３００の復号鍵取得部３０２は、通信部３０７を介して復号鍵を受け取り、復号鍵と申請書１１４を復号部３０３に渡す。復号部３０３は申請書１１４を複製した上で一方を復号し、オリジナルの申請書１１４と復号した申請書１１４とを申請書処理部３０４に渡す。申請書処理部３０４では、復号した申請書１１４の項目を用いて所定の処理が実行される。なお、所定の処理の処理内容は、例えば承認、適否判定等であってもよいが特に限定されるものではない。申請書処理部３０４は所定の処理を実行した後、復号していないオリジナルの申請書１１４を署名部３０５に渡す。署名部３０５は、オリジナルの申請書１１４に電子署名を施して申請書送受信部３０１に渡す。申請書送受信部３０１はヘッダ情報１１３を参照して自装置とは異なる申請受付装置にオリジナルの申請書１１４を送信する（ステップＳ５、本発明の送信ステップに対応）。図１１の例では、申請受付装置３００は申請書１１４を申請受付装置４００に送信する。

続くステップＳ６、Ｓ７、Ｓ８は、申請受付装置３００と申請受付装置４００とが異なるが、それぞれステップＳ３、Ｓ４、Ｓ５と同様の処理であるため説明を省略する。ただし、ステップＳ８（本発明の送信ステップに対応）において、申請受付装置４００は、ヘッダ情報１１３から自装置が終点である、すなわち自装置が実行する所定の処理が申請書１１４に対する最後の処理であると判定して、申請サーバ１００に申請書１１４を送信する。

申請サーバ１００の申請書送受信部１０３は、通信部１０６を介して申請書１１４を受信し、署名検証部１０４へ渡す。署名検証部１０４は、記憶部１０５の申請先テーブル１１２と例えば申請先に対応する公開鍵等を参照し、署名の真正性と署名の順番を確認する。申請サーバ１００は、記憶部１０５による署名が適切であると確認した後に、申請が完了した旨の通知（申請完了通知）を利用者端末Ｙに送信する（ステップＳ９）。

ここで、利用者は、申請完了通知を受け取る前に、利用者端末Ｙを用いて進捗状況を確認することが可能である。鍵発行管理サーバ２００のステータス管理部２０３は、通信部２０５を介して利用者端末Ｙから申請書番号および進捗確認要求を受信する（ステップＳ２１）。

鍵発行管理サーバ２００のステータス管理部２０３は、記憶部２０４のステータステーブル２１２を参照し、申請書番号に基づいて、申請書１１４に所定の処理を行う申請書受付装置のそれぞれについて復号鍵を発行しているか否かの情報を利用者端末Ｙに回答する（ステップＳ２２）。ワンストップ申請システム１０は、例えば利用者端末Ｙに回答結果を表示することにより、利用者に対して進捗状況を示すことが可能である。なお、利用者端末Ｙからの進捗確認要求がない場合には、ステップＳ２１およびステップＳ２２は省略される。

以上のように、本実施形態のワンストップ申請システム１０、ワンストップ申請方法およびプログラムによれば、申請サーバが生成する申請書の本体部分は項目ごとに暗号化されるため、特定の申請先に特定の項目のみを開示することができる。また、申請サーバが生成する申請書のヘッダ情報は、申請書の申請先および申請順を指定する。申請書を受け取った申請受付装置は、所定の処理を実施した後に、ヘッダ情報に基づいて次の申請先に、正しい順番で申請書を送信できる。そのため、従来の手法のようにフロー制御装置（本実施形態における申請サーバ１００に対応）が各申請先での処理の後に申請書を受け取る必要はなく、特定の装置にアクセスが集中することがない。よって、トラヒック集中を抑えることが可能であり、トラヒック負荷（通信回数・容量、保持データ容量）が従来よりも削減されるため、ワンストップ申請システム１０を構成する装置にかかるコストを低減できる。

ここで、従来の手法ではフロー制御装置（本実施形態における申請サーバ１００に対応）が、各申請先との間の申請書の送受信に基づいて進捗状況を管理していた。本実施形態において申請サーバ１００は、初期の申請書を送信し、最終的な申請書を受信するだけであるため、申請書１１４の送受信によっては細かい進捗状況を把握できない。しかし、利用者は、利用者端末Ｙから鍵発行管理サーバ２００にアクセスすることで進捗状況を把握可能である。つまり、本実施形態においても、従来の手法と同様に進捗状況を把握することができる。

本発明を諸図面や実施例に基づき説明してきたが、当業者であれば本開示に基づき種々の変形や修正を行うことが容易であることに注意されたい。従って、これらの変形や修正は本発明の範囲に含まれることに留意されたい。また、前記実施形態では、申請サーバ１００としてコンピュータを例示したが、これらに限らずタブレット、スマートフォン、携帯電話等を用いることが可能である。また、鍵発行管理サーバ２００、申請受付装置３００、４００等も、コンピュータ、タブレット等で実現可能である。また、前記実施形態では、ネットワークＸはインターネットであるが、インターネットに代えてＬＡＮ、ＷＡＮ等のネットワークが用いられてもよい。

１０ ワンストップ申請システム
１００ 申請サーバ
１０１ 申請書生成部
１０２ 暗号化部
１０３ 申請書送受信部
１０４ 署名検証部
１０５ 記憶部
１０６ 通信部
１１１ アクセス権管理テーブル
１１２ 申請先テーブル
１１３ ヘッダ情報
１１４ 申請書
２００ 鍵発行管理サーバ
２０１ 鍵発行情報受信部
２０２ 鍵発行部
２０３ ステータス管理部
２０４ 記憶部
２０５ 通信部
２１１ 鍵発行情報管理テーブル
２１２ ステータステーブル
３００ 申請受付装置
３０１ 申請書送受信部
３０２ 復号鍵取得部
３０３ 復号部
３０４ 申請書処理部
３０５ 署名部
３０６ 記憶部
３０７ 通信部
４００ 申請受付装置

Claims (7)

1. 申請サーバと、複数の申請受付装置と、を備えるワンストップ申請システムであって、
   前記申請サーバは、利用者端末からの申請情報に応じた情報であって項目ごとに暗号化された本体部分と、申請先となる前記申請受付装置および申請の順番を指定するヘッダ情報と、を含む申請書を生成し、
   前記申請受付装置は、必要な項目を復号して所定の処理を実行し、前記ヘッダ情報に基づいて前記申請サーバまたは自装置とは異なる前記申請受付装置に前記申請書を送信する、ワンストップ申請システム。
2. 前記申請受付装置は、自装置の申請の順番が最後である場合に前記申請サーバに前記申請書を送信し、それ以外の場合には自装置とは異なる前記申請受付装置に前記申請書を送信する、請求項１に記載のワンストップ申請システム。
3. 暗号化された項目を復号するための鍵を発行する鍵発行管理サーバ、をさらに備え、
   前記鍵発行管理サーバは、前記鍵の発行の有無に基づいて進捗状況を管理する、請求項１または２に記載のワンストップ申請システム。
4. 申請サーバと、複数の申請受付装置と、を備えるシステムのワンストップ申請方法であって、
   前記申請サーバが、利用者端末からの申請情報に応じた情報であって項目ごとに暗号化された本体部分と、申請先となる前記申請受付装置および申請の順番を指定するヘッダ情報と、を含む申請書を生成するステップと、
   前記申請受付装置が、必要な項目を復号して所定の処理を実行し、前記ヘッダ情報に基づいて前記申請サーバまたは自装置とは異なる前記申請受付装置に前記申請書を送信する送信ステップと、を含むワンストップ申請方法。
5. 前記送信ステップにおいて、前記申請受付装置が、自装置の申請の順番が最後である場合に前記申請サーバに前記申請書を送信し、それ以外の場合には自装置とは異なる前記申請受付装置に前記申請書を送信する、請求項４に記載のワンストップ申請方法。
6. 前記システムは鍵発行管理サーバをさらに備え、
   前記鍵発行管理サーバが、暗号化された項目を復号するための鍵を発行し、前記鍵の発行の有無に基づいて進捗状況を管理するステップ、をさらに含む請求項４または５に記載のワンストップ申請方法。
7. コンピュータを、
   申請サーバと、申請書の必要な項目を復号して所定の処理を実行し、前記申請書のヘッダ情報に基づいて前記申請サーバまたは自装置とは異なる申請受付装置に前記申請書を送信する、複数の前記申請受付装置と、を備えるシステムの前記申請サーバとして機能させるプログラムであって、
   前記コンピュータに、
   利用者端末からの申請情報に応じた情報であって項目ごとに暗号化された前記申請書の本体部分を生成させる処理と、
   申請先となる前記申請受付装置および申請の順番を指定する前記申請書の前記ヘッダ情報を生成させる処理と、
   を実行させるプログラム。

Images