JP7361384B2 - 電子申請の補助方法、電子申請補助システム、電子申請補助システムのプログラム及びその記録媒体 - Google Patents
電子申請の補助方法、電子申請補助システム、電子申請補助システムのプログラム及びその記録媒体 Download PDFInfo
- Publication number
- JP7361384B2 JP7361384B2 JP2020017011A JP2020017011A JP7361384B2 JP 7361384 B2 JP7361384 B2 JP 7361384B2 JP 2020017011 A JP2020017011 A JP 2020017011A JP 2020017011 A JP2020017011 A JP 2020017011A JP 7361384 B2 JP7361384 B2 JP 7361384B2
- Authority
- JP
- Japan
- Prior art keywords
- data
- file
- application
- key
- managed
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Images
Landscapes
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
Description
本願発明は、電子申請の補助方法、電子申請補助システム、電子申請補助システムのプログラム及びその記録媒体に関する。
近年、従業員の社会保険の資格取得届の社会保険事務所への提出（届出）といった申請手続に関して、電子政府（ｅ－Ｇｏｖ）などへの電子申請が普及しつつあり、提出書類の入力作業を支援するものや書類提出の期限（進捗）管理を行うプログラムが提案されている（特許文献１及び２）。
この他税務署への法人税の確定申告について税務調整を容易にするプログラム（特許文献３）や、企業にクラウドコンピューティングによる給与計算を提供するための給与計算プログラムが提案されている（特許文献４）。
特に上記電子申請に際し、第１に企業組織といった管理者は被管理者である従業者本人に当人の個人情報のデータ（データファイル）を提出させて、管理者側にて当該個人情報を申請書類のデータファイルへ反映させた申請手続を行う。
また第２に、上記管理者において、上記電子申請の結果、登録証等の電子政府など発行された発行データ（公文書等のデータ）を安全に各被管理者へ届ける必要が生じる。
電子申請に関し上記第１及び第２の何れの個人情報のデータの取り扱いにも極めて高い機密性が求められる。場合によっては特許文献３及び４へ示す上記法人税の確定申告や給与計算では必要とされない高い機密性が求められるのである。
一例を挙げると、電子申請において上記個人情報の最たるものは、当人の顔写真の画像データであり、このような個人情報は、上記法人税の確定申告や給与計算では、特に必要とされない。
一方、上記電子申請の場合において、機密性を厳格に求めると、往々にしてデータ（データファイル）の受け渡しが複雑になり、申請手続に関与するシステムの利便性を損なう危惧がある。
電子申請においては、上記の顔写真に限らず個人が特定される、申請用データのファイルや公文書のデータのファイルの受け渡しが多発し、上記高い機密性の確保と円滑な運用が可能な利便性とが求められるのである。
上記の特許文献３及び４は勿論のこと、特許文献１及び２についても、上記データの受け渡しの機密性と利便性確保の手段について具体的な開示はない。
一例を挙げると、電子申請において上記個人情報の最たるものは、当人の顔写真の画像データであり、このような個人情報は、上記法人税の確定申告や給与計算では、特に必要とされない。
一方、上記電子申請の場合において、機密性を厳格に求めると、往々にしてデータ（データファイル）の受け渡しが複雑になり、申請手続に関与するシステムの利便性を損なう危惧がある。
電子申請においては、上記の顔写真に限らず個人が特定される、申請用データのファイルや公文書のデータのファイルの受け渡しが多発し、上記高い機密性の確保と円滑な運用が可能な利便性とが求められるのである。
上記の特許文献３及び４は勿論のこと、特許文献１及び２についても、上記データの受け渡しの機密性と利便性確保の手段について具体的な開示はない。
データの機密性を確保する手段に関し、データを暗号化し暗号化した当該データを復号するクラウドサービスとして、データキーとマスターキーという２種の暗号鍵を用いるＫＭＳ(Key Management System)が提案され利用されている。
クラウドサービスの上記利用者のデータを当該利用者の端末（ローカル）にて上記データキーにて暗号化させ、当該データキーをクラウド上にて当該クラウドの備えるマスターキーで暗号化させるのである。上記利用者から暗号化された上記データを受け取った他の利用者は、データキーにて暗号化した上記データを復号化するに際し、先ず上記クラウド上にてマスターキーにより暗号化されているデータキーを復号化する。復号化したデータキーを用いて他の利用者は当該他の利用者の端末（ローカル）にて上記データを復号化するのである。
上記ＫＭＳでは、上記２種の暗号鍵の管理がポイントとなり、暗号化された上記データ自体の受け渡しの安全性や利便性に重点が置かれたものではなかった。即ち、上記ＫＭＳについて、電子申請における電子申請用のデータのファイルや、申請により発行された公文書のデータ（発行データ）のファイルの受け渡しの安全性と利便性の確保に関して、更に具体的な方策が必要であった。
クラウドサービスの上記利用者のデータを当該利用者の端末（ローカル）にて上記データキーにて暗号化させ、当該データキーをクラウド上にて当該クラウドの備えるマスターキーで暗号化させるのである。上記利用者から暗号化された上記データを受け取った他の利用者は、データキーにて暗号化した上記データを復号化するに際し、先ず上記クラウド上にてマスターキーにより暗号化されているデータキーを復号化する。復号化したデータキーを用いて他の利用者は当該他の利用者の端末（ローカル）にて上記データを復号化するのである。
上記ＫＭＳでは、上記２種の暗号鍵の管理がポイントとなり、暗号化された上記データ自体の受け渡しの安全性や利便性に重点が置かれたものではなかった。即ち、上記ＫＭＳについて、電子申請における電子申請用のデータのファイルや、申請により発行された公文書のデータ（発行データ）のファイルの受け渡しの安全性と利便性の確保に関して、更に具体的な方策が必要であった。
そこで本発明は、電子申請に際し、上記管理者と被管理者との間においてデータの上記第１の受け渡しを安全且つ簡便に行えるデータの受け渡し手段（データの置き場）の提供を可能とし上記課題（第１の課題）の解決を図る。
また、本発明は、電子申請に際し、上記管理者と被管理者との間においてデータの上記第２の受け渡しを安全且つ簡便に行えるデータの受け渡し手段（データの置き場）の提供を可能として上記課題（第２の課題）の解決を図る。
本発明は、会社等組織といった管理者のオペレータが、前記管理者に管理される従業者等の複数の被管理者についてコンピュータを用いた申請手続を電子政府等の手続先へオンラインにより行うために、前記被管理者に関するデータのファイルを取得し収容する電子申請補助システムについて次の構成を採るものを提供する。
即ち本発明は、申請関連データのファイルを収容する申請データ収容部と、管理テーブル収容部と、システム制御部と、キー生成部とを備え、前記申請関連データのファイルは、前記申請手続に必要な前記被管理者の申請用データのファイルと前記申請手続きの手続き先にて発行された発行データのファイルの少なくとも何れかであり、前記申請データ収容部は、前記申請関連データのファイルを収容するファイル別収容部を、前記申請関連データのファイル毎に設けられるものであり、前記ファイル別収容部には識別子となるキーが付与され、前記ファイル別収容部は当該キーのみにて特定されるものであり、前記管理テーブル収容部には、少なくとも、前記ファイル別収容部へ収容される前記申請関連データのファイルのファイル名のデータと、当該申請関連データのファイルの被管理者の識別子のデータと、前記ファイル別収容部を特定する前記キーを生成する要素となる１つ又は複数の要素データとを備えたレコードを収容する、テーブルを設けることができ且つ、前記テーブルには前記申請関連データのファイル自体を収容しないものであり、特定の前記申請関連データのファイルへのアクセスの要求があった際、前記システム制御部は、前記管理テーブル収容部の前記テーブルを参照し当該申請関連データのファイルの前記ファイル名のデータを収容するレコードを検出して前記キー生成部に当該レコード中の前記要素データから前記キーを生成させ、生成した当該キーと一致する前記キーが付与された前記ファイル別収容部を検出し、検出した前記ファイル別収容部に収容された前記申請関連のファイルへのアクセスを可能とする電子申請補助システムを提供する。
尚、上記の会社等組織とは、会社組織を含む他、社団法人、組合、国、地方公共団体、非営利団体その他、複数の構成員を有する組織をいう。
また、上記の電子政府等の手続先とは、電子政府の他、民間企業や民間団体を含む、電子申請による手続を受け付ける団体をいう。
また本発明は、暗号生成部と、前記暗号生成部が暗号化したデータを復号化する復号部とを備え、前記キー生成部は、前記ファイル名のデータを、前記要素データの１つとするものであり、前記申請関連のファイルの前記ファイル別収容部への収容に際し、前記暗号生成部は、前記ファイル名のデータと他の前記要素データの夫々を暗号化し前記レコードの一部として前記管理テーブル収容部の前記テーブルへ収容するものであり、且つ、前記キー生成部は、前記暗号生成部にて暗号化した前記ファイル名のデータと他の前記要素データとを更に暗号化することで前記キーを生成し、前記申請関連データのファイルの収容時に、収容に用いる前記ファイル別収容部を形成して前記キーを付与するものであり、特定の前記被管理者の前記申請関連のファイルへのアクセスの要求があった際、前記システム制御部は前記管理テーブル収容部の前記テーブルから当該被管理者の識別子のデータを収容する前記レコードを検出し、前記復号部へ検出した前記レコード中の少なくとも前記ファイル名のデータを復号させ、要求のあったファイル名のデータを有するレコードを特定して、前記キー生成部により特定したレコードの備える、暗号化された前記ファイル名のデータと他の前記要素データとから前記キーを生成し、当該キーと一致する前記キーが付与された前記ファイル別収容部を検出し、当該ファイル別収容部へ収容された前記申請関連のファイルとのアクセスを可能とする電子申請補助システムを提供できた。
更に本発明は、アクセス制御部と、管理用表示部と、個別表示部とを備え、前記アクセス制御部は、前記被管理者の一人の端末から前記申請データ収容部の前記テーブルへのアクセスの要求があった際、当該被管理者に対し、当該被管理者の識別子のデータを有する前記レコードへのアクセスを許可し、他の被管理者の識別子のデータを有する前記レコードへのアクセスを制限するものであり、前記アクセス制御部は、少なくとも前記オペレータの端末から前記申請データ収容部へのアクセスの要求があった際、前記オペレータに対し全ての前記被管理者の前記レコードへのアクセスを許可するものであり、前記システム制御部は、前記管理表示部により前記オペレータの用いる端末において前記複数の被管理者の一覧表を表示させ、前記一覧表から前記オペレータが選択した被管理者の識別子を収容する前記レコードを前記復号部にて復号化させて表示させ、且つ前記オペレータの前記レコードの選択により前記キー生成部へ前記キーを生成させて前記オペレータの要求する前記被管理者の前記申請関連のファイルへの前記アクセスを可能とするものであり、前記システム制御部は、前記被管理者の用いる端末の操作にて前記個別表示部により、前記アクセス制御部がアクセスを許可した当該被管理者の前記レコードを前記復号部にて復号化して当該被管理者の端末へ表示させ、且つ前記被管理者の前記レコードの選択により前記キー生成部に前記キーを生成させて前記オペレータの要求する当該被管理者の前記申請関連のファイルへの前記アクセスを可能とするものであり、前記システム制御部は、当該被管理者以外の他の被管理者の前記レコードを前記個別表示部に隠蔽させ当該被管理者の端末へ表示させない電子申請補助システムを提供できた。
尚、ここで「オペレータの（用いる）端末」とは、管理者権限にてログインした端末を指し、上記の「被管理者の（用いる）端末」とは、被管理者権限にてログインした端末を指す。
また更に本発明では、少なくとも前記申請データ収容部と前記システム制御部と前記暗号生成部は、インターネット等のネットワークへ接続された１つ又は複数のサーバに設けられ、前記アクセス制御部にてアクセスが許可された前記被管理者の端末から、当該被管理者の前記申請データ収容部へ前記申請用データのファイルをアップロードすることができ、前記アップロード時、前記暗号生成部は、前記申請用データのファイルの前記ファイル名のデータと前記他の要素データの夫々を暗号化し前記レコードの一部として前記管理テーブル収容部の前記テーブルへ収容するものであり、且つ、前記キー生成部は、前記暗号生成部にて暗号化した前記ファイル名のデータと前記他の要素データとを更に暗号化することで前記キーを生成し、アップロードされた前記申請用データのファイルの収容に用いる前記ファイル別収容部を形成して前記キーを付与するものであり、前記他の要素データは、前記申請用データのファイルのアップロード元の所在を示すファイルパスのデータであり、前記システム制御部は、当該ファイルパスのデータを前記暗号生成部にて暗号化させて前記レコードの一部として前記テーブルへ収容し、前記オペレータの端末からの指定にて、前記被管理者の前記申請用データのファイルを前記キーでアクセスすることにより前記オペレータの端末へダウンロードすることができる電子申請補助システムを提供できた。
更にまた本発明では、少なくとも前記申請データ収容部と前記システム制御部と前記暗号生成部は、インターネット等のネットワークへ接続された１つ又は複数のサーバに設けられ、少なくとも前記手続先への前記申請手続後、前記オペレータの端末の操作により、インターネット等のネットワークを介して前記手続先からオンラインにて前記申請手続に対する前記手続先発行の前記発行データのファイルを前記オペレータの端末へダウンロードすることができ、前記暗号生成部は、前記ダウンロードした前記発行データのファイルを前記オペレータの端末から当該被管理者の前記申請データ収容部へアップロードすることができ、前記アップロード時、前記暗号生成部は、前記発行データのファイルの前記ファイル名のデータと前記他の要素データの夫々を暗号化して前記管理テーブル収容部の前記テーブルへ前記レコードの一部として収容するものであり、且つ、前記キー生成部は、前記暗号生成部にて暗号化した前記ファイル名のデータと前記他の要素データとを更に暗号化することで前記キーを生成し、前記システム制御部はアップロードされた前記発行データのファイルの収容に用いる前記ファイル別収容部を形成して前記キーを付与するものであり、前記他の要素データは前記発行データのファイルのダウンロード元の所在を示すダウンロードリンクのデータであり、前記システム制御部は前記暗号生成部にて暗号化させて前記レコードの一部として前記テーブルへ収容し、前記被管理者の端末の操作にて、当該被管理者の前記ファイル別収容部へ収容された前記発行データのファイルを前記キーにてアクセスすることにより当該被管理者の端末へダウンロードすることができる電子申請補助システムを提供できた。
また本発明では、前記管理テーブル収容部には前記テーブルとは別に、前記オペレータのメールアドレスのデータと前記オペレータによって事前に設定されたパスワードのデータと前記オペレータの識別子とを有するレコードを収容する、管理者認証テーブルが設けられ、
更に前記管理テーブル収容部には前記テーブル及び前記管理者認証テーブルとは別に、各被管理者のメールアドレスのデータと各被管理者によって事前に設定されたパスワードのデータと各被管理者の識別子とを有するレコードを収容する、被管理者認証テーブルが設けられ、端末からのログイン時に、前記アクセス制御部は、ログインする者のメールアドレスと識別子のうちの少なくとも何れか一方とパスワードの入力とを受け、前記管理者認証テーブルと前記被管理者認証テーブルの少なくとも何れか一方に収容されたレコードを参照して、ログインした者が管理者権限によるものか被管理者権限によるものか判断し必要な前記アクセスの制限を行うものである電子申請補助システムを提供できた。
更に本発明では、少なくとも前記申請データ収容部と前記システム制御部は、ウェブサービスを提供する業者の１つ又は複数のサーバに構築されるものであり、前記サーバは、負荷分散装置を有し、前記サーバの数を増減しても動作可能に構成された電子申請補助システムを提供できた。
また更に本発明は、上記の電子申請補助システムを用いた電子申請の補助方法を提供できた。
更にまた本発明は、上記の電子申請補助システムを構築する電子申請補助システムのプログラムを提供できた。
また本発明は、上記電子申請補助システムのプログラムが記録された記録媒体を提供できた。
即ち本発明は、申請関連データのファイルを収容する申請データ収容部と、管理テーブル収容部と、システム制御部と、キー生成部とを備え、前記申請関連データのファイルは、前記申請手続に必要な前記被管理者の申請用データのファイルと前記申請手続きの手続き先にて発行された発行データのファイルの少なくとも何れかであり、前記申請データ収容部は、前記申請関連データのファイルを収容するファイル別収容部を、前記申請関連データのファイル毎に設けられるものであり、前記ファイル別収容部には識別子となるキーが付与され、前記ファイル別収容部は当該キーのみにて特定されるものであり、前記管理テーブル収容部には、少なくとも、前記ファイル別収容部へ収容される前記申請関連データのファイルのファイル名のデータと、当該申請関連データのファイルの被管理者の識別子のデータと、前記ファイル別収容部を特定する前記キーを生成する要素となる１つ又は複数の要素データとを備えたレコードを収容する、テーブルを設けることができ且つ、前記テーブルには前記申請関連データのファイル自体を収容しないものであり、特定の前記申請関連データのファイルへのアクセスの要求があった際、前記システム制御部は、前記管理テーブル収容部の前記テーブルを参照し当該申請関連データのファイルの前記ファイル名のデータを収容するレコードを検出して前記キー生成部に当該レコード中の前記要素データから前記キーを生成させ、生成した当該キーと一致する前記キーが付与された前記ファイル別収容部を検出し、検出した前記ファイル別収容部に収容された前記申請関連のファイルへのアクセスを可能とする電子申請補助システムを提供する。
尚、上記の会社等組織とは、会社組織を含む他、社団法人、組合、国、地方公共団体、非営利団体その他、複数の構成員を有する組織をいう。
また、上記の電子政府等の手続先とは、電子政府の他、民間企業や民間団体を含む、電子申請による手続を受け付ける団体をいう。
また本発明は、暗号生成部と、前記暗号生成部が暗号化したデータを復号化する復号部とを備え、前記キー生成部は、前記ファイル名のデータを、前記要素データの１つとするものであり、前記申請関連のファイルの前記ファイル別収容部への収容に際し、前記暗号生成部は、前記ファイル名のデータと他の前記要素データの夫々を暗号化し前記レコードの一部として前記管理テーブル収容部の前記テーブルへ収容するものであり、且つ、前記キー生成部は、前記暗号生成部にて暗号化した前記ファイル名のデータと他の前記要素データとを更に暗号化することで前記キーを生成し、前記申請関連データのファイルの収容時に、収容に用いる前記ファイル別収容部を形成して前記キーを付与するものであり、特定の前記被管理者の前記申請関連のファイルへのアクセスの要求があった際、前記システム制御部は前記管理テーブル収容部の前記テーブルから当該被管理者の識別子のデータを収容する前記レコードを検出し、前記復号部へ検出した前記レコード中の少なくとも前記ファイル名のデータを復号させ、要求のあったファイル名のデータを有するレコードを特定して、前記キー生成部により特定したレコードの備える、暗号化された前記ファイル名のデータと他の前記要素データとから前記キーを生成し、当該キーと一致する前記キーが付与された前記ファイル別収容部を検出し、当該ファイル別収容部へ収容された前記申請関連のファイルとのアクセスを可能とする電子申請補助システムを提供できた。
更に本発明は、アクセス制御部と、管理用表示部と、個別表示部とを備え、前記アクセス制御部は、前記被管理者の一人の端末から前記申請データ収容部の前記テーブルへのアクセスの要求があった際、当該被管理者に対し、当該被管理者の識別子のデータを有する前記レコードへのアクセスを許可し、他の被管理者の識別子のデータを有する前記レコードへのアクセスを制限するものであり、前記アクセス制御部は、少なくとも前記オペレータの端末から前記申請データ収容部へのアクセスの要求があった際、前記オペレータに対し全ての前記被管理者の前記レコードへのアクセスを許可するものであり、前記システム制御部は、前記管理表示部により前記オペレータの用いる端末において前記複数の被管理者の一覧表を表示させ、前記一覧表から前記オペレータが選択した被管理者の識別子を収容する前記レコードを前記復号部にて復号化させて表示させ、且つ前記オペレータの前記レコードの選択により前記キー生成部へ前記キーを生成させて前記オペレータの要求する前記被管理者の前記申請関連のファイルへの前記アクセスを可能とするものであり、前記システム制御部は、前記被管理者の用いる端末の操作にて前記個別表示部により、前記アクセス制御部がアクセスを許可した当該被管理者の前記レコードを前記復号部にて復号化して当該被管理者の端末へ表示させ、且つ前記被管理者の前記レコードの選択により前記キー生成部に前記キーを生成させて前記オペレータの要求する当該被管理者の前記申請関連のファイルへの前記アクセスを可能とするものであり、前記システム制御部は、当該被管理者以外の他の被管理者の前記レコードを前記個別表示部に隠蔽させ当該被管理者の端末へ表示させない電子申請補助システムを提供できた。
尚、ここで「オペレータの（用いる）端末」とは、管理者権限にてログインした端末を指し、上記の「被管理者の（用いる）端末」とは、被管理者権限にてログインした端末を指す。
また更に本発明では、少なくとも前記申請データ収容部と前記システム制御部と前記暗号生成部は、インターネット等のネットワークへ接続された１つ又は複数のサーバに設けられ、前記アクセス制御部にてアクセスが許可された前記被管理者の端末から、当該被管理者の前記申請データ収容部へ前記申請用データのファイルをアップロードすることができ、前記アップロード時、前記暗号生成部は、前記申請用データのファイルの前記ファイル名のデータと前記他の要素データの夫々を暗号化し前記レコードの一部として前記管理テーブル収容部の前記テーブルへ収容するものであり、且つ、前記キー生成部は、前記暗号生成部にて暗号化した前記ファイル名のデータと前記他の要素データとを更に暗号化することで前記キーを生成し、アップロードされた前記申請用データのファイルの収容に用いる前記ファイル別収容部を形成して前記キーを付与するものであり、前記他の要素データは、前記申請用データのファイルのアップロード元の所在を示すファイルパスのデータであり、前記システム制御部は、当該ファイルパスのデータを前記暗号生成部にて暗号化させて前記レコードの一部として前記テーブルへ収容し、前記オペレータの端末からの指定にて、前記被管理者の前記申請用データのファイルを前記キーでアクセスすることにより前記オペレータの端末へダウンロードすることができる電子申請補助システムを提供できた。
更にまた本発明では、少なくとも前記申請データ収容部と前記システム制御部と前記暗号生成部は、インターネット等のネットワークへ接続された１つ又は複数のサーバに設けられ、少なくとも前記手続先への前記申請手続後、前記オペレータの端末の操作により、インターネット等のネットワークを介して前記手続先からオンラインにて前記申請手続に対する前記手続先発行の前記発行データのファイルを前記オペレータの端末へダウンロードすることができ、前記暗号生成部は、前記ダウンロードした前記発行データのファイルを前記オペレータの端末から当該被管理者の前記申請データ収容部へアップロードすることができ、前記アップロード時、前記暗号生成部は、前記発行データのファイルの前記ファイル名のデータと前記他の要素データの夫々を暗号化して前記管理テーブル収容部の前記テーブルへ前記レコードの一部として収容するものであり、且つ、前記キー生成部は、前記暗号生成部にて暗号化した前記ファイル名のデータと前記他の要素データとを更に暗号化することで前記キーを生成し、前記システム制御部はアップロードされた前記発行データのファイルの収容に用いる前記ファイル別収容部を形成して前記キーを付与するものであり、前記他の要素データは前記発行データのファイルのダウンロード元の所在を示すダウンロードリンクのデータであり、前記システム制御部は前記暗号生成部にて暗号化させて前記レコードの一部として前記テーブルへ収容し、前記被管理者の端末の操作にて、当該被管理者の前記ファイル別収容部へ収容された前記発行データのファイルを前記キーにてアクセスすることにより当該被管理者の端末へダウンロードすることができる電子申請補助システムを提供できた。
また本発明では、前記管理テーブル収容部には前記テーブルとは別に、前記オペレータのメールアドレスのデータと前記オペレータによって事前に設定されたパスワードのデータと前記オペレータの識別子とを有するレコードを収容する、管理者認証テーブルが設けられ、
更に前記管理テーブル収容部には前記テーブル及び前記管理者認証テーブルとは別に、各被管理者のメールアドレスのデータと各被管理者によって事前に設定されたパスワードのデータと各被管理者の識別子とを有するレコードを収容する、被管理者認証テーブルが設けられ、端末からのログイン時に、前記アクセス制御部は、ログインする者のメールアドレスと識別子のうちの少なくとも何れか一方とパスワードの入力とを受け、前記管理者認証テーブルと前記被管理者認証テーブルの少なくとも何れか一方に収容されたレコードを参照して、ログインした者が管理者権限によるものか被管理者権限によるものか判断し必要な前記アクセスの制限を行うものである電子申請補助システムを提供できた。
更に本発明では、少なくとも前記申請データ収容部と前記システム制御部は、ウェブサービスを提供する業者の１つ又は複数のサーバに構築されるものであり、前記サーバは、負荷分散装置を有し、前記サーバの数を増減しても動作可能に構成された電子申請補助システムを提供できた。
また更に本発明は、上記の電子申請補助システムを用いた電子申請の補助方法を提供できた。
更にまた本発明は、上記の電子申請補助システムを構築する電子申請補助システムのプログラムを提供できた。
また本発明は、上記電子申請補助システムのプログラムが記録された記録媒体を提供できた。
本発明では、電子申請を補助することを目的として、申請を行う管理者と申請の対象者である被管理者との間において電子申請に関するデータファイルを受け渡す、機密性と利便性の高いデータファイルの置き場を提供するシステムを構築できた。
具体的には、暗号化するキー生成の要素データを収容する管理テーブルとは別の申請データ収容部へ、申請関連データのファイルを収容するファイル別収容部を形成するものとし、上記要素データから生成するキー自体を、上記ファイル別収容部を特定する唯一の手段とすることで、高い機密性を確保した申請関連データのファイルの置き場即ち申請関連データのファイルの受け渡し場所を提供した。
特に本発明（請求項２）では、暗号化された要素データを復号化するのではなく更に暗号化することによって、ファイル別収容部を特定する唯一の手段を生成するという斬新なものであり、高い機密性と利便性との両立を得たものである。
本発明（特に請求項４）は、データの上記第１の受け渡しにおける課題を解決し、また本発明（特に請求項５）は、データの上記第２の受け渡しにおける課題を解決したのである。
また本発明（請求項７）は、電子申請を補助する上で、上記第３の課題を解決する、即ちウェブサービスを提供する業者のサーバに構築するのに好適なシステムを提供して、当該業者が提供するロードバランサ（負荷分散装置）を利用することで、オンプレミス(社内構築システム)では生じがちな資源の過不足を排除し、コスト抑制と拡張性とを両立できた。
具体的には、暗号化するキー生成の要素データを収容する管理テーブルとは別の申請データ収容部へ、申請関連データのファイルを収容するファイル別収容部を形成するものとし、上記要素データから生成するキー自体を、上記ファイル別収容部を特定する唯一の手段とすることで、高い機密性を確保した申請関連データのファイルの置き場即ち申請関連データのファイルの受け渡し場所を提供した。
特に本発明（請求項２）では、暗号化された要素データを復号化するのではなく更に暗号化することによって、ファイル別収容部を特定する唯一の手段を生成するという斬新なものであり、高い機密性と利便性との両立を得たものである。
本発明（特に請求項４）は、データの上記第１の受け渡しにおける課題を解決し、また本発明（特に請求項５）は、データの上記第２の受け渡しにおける課題を解決したのである。
また本発明（請求項７）は、電子申請を補助する上で、上記第３の課題を解決する、即ちウェブサービスを提供する業者のサーバに構築するのに好適なシステムを提供して、当該業者が提供するロードバランサ（負荷分散装置）を利用することで、オンプレミス(社内構築システム)では生じがちな資源の過不足を排除し、コスト抑制と拡張性とを両立できた。
以下、図面に基づき本願発明の実施の形態を説明する。
（概要）
本発明は、電子申請システムＥと共に用いられるのに適した電子申請補助システムＳに関する（図１）。
（概要）
本発明は、電子申請システムＥと共に用いられるのに適した電子申請補助システムＳに関する（図１）。
上記電子申請システムＥは、管理者である企業のオペレータの端末ＰＣＭから、電子政府等の手続先Ｇに対しインターネット或いは専用の通信網などのネットワークＮを通じて、被管理者である当該企業の従業員に関する電子申請の手続を行うことができるシステムである。即ち上記電子申請システムＥは、管理者側の電子政府等への電子申請のサポートを行う。
また、電子申請システムＥは、ネットワークを通じた電子申請の手続に対する手続先Ｇから通知書などの発行データの受領を上記管理者のオペレータの端末ＰＣＭ或いは当該管理者の管理する他の端末にて行う。
また、電子申請システムＥは、ネットワークを通じた電子申請の手続に対する手続先Ｇから通知書などの発行データの受領を上記管理者のオペレータの端末ＰＣＭ或いは当該管理者の管理する他の端末にて行う。
以下、電子政府（ｅ－Ｇｏｖ）を電子申請の手続先Ｇとして例示し説明する。
電子政府への電子申請は、現在申請手続ごとに行う単票形式による申請について従来通り電子政府のｗｅｂ上（e-Govのホームページ）で申請書を作成（入力）し電子申請まで行えるものとしている。一方電子政府に対し上記ｗｅｂから複数の申請手続を一括して行う一括申請について、電子政府は令和２年に運用の終了を予定している。
電子政府への電子申請は、現在申請手続ごとに行う単票形式による申請について従来通り電子政府のｗｅｂ上（e-Govのホームページ）で申請書を作成（入力）し電子申請まで行えるものとしている。一方電子政府に対し上記ｗｅｂから複数の申請手続を一括して行う一括申請について、電子政府は令和２年に運用の終了を予定している。
電子政府では、近年利用可能とした外部連携ＡＰＩ（Application Programming Interface）において、令和２年に廃止予定の従来のｗｅｂからの上記一括申請に代わり、利用者の端末からの一括申請を認める。外部連携ＡＰＩについては通常クラウドサービスの提供事業者が有償で利用者に利用させるものである。
上記の電子申請システムＥを含め一般的な外部連携ＡＰＩでは、上記ｗｅｂを介さず利用者の端末において電子申請書の作成と電子政府に対する電子申請とを可能とする。
上記の電子申請システムＥを含め一般的な外部連携ＡＰＩでは、上記ｗｅｂを介さず利用者の端末において電子申請書の作成と電子政府に対する電子申請とを可能とする。
この例において、上記の電子申請システムＥは、上記一括申請を可能とする。また、この例では、本発明に係る上記電子申請補助システムＳ（以下必要に応じて本システムＳと呼ぶ。）は、電子申請システムＥと連携し、電子申請システムＥを用いた申請に必要なデータや申請により発行されたデータのファイルについて、管理者と被管理者との間における安全で簡便な受け渡しを実現する。
本システムＳは上記電子申請システムＥと独立したものとしてもよいが、この例では、本システムＳは電子申請システムＥの一部として機能する。電子申請システムＥの本システムＳ以外の機能や構成、即ち電子申請の申請に関する機能や構成についての詳細を省略する。尚、電子申請に関する上記機能としては管理者（会社）へ電子申請の権限を付与するか制限するかに関するものや、社会保険労務士（社労士）による管理者（会社）に対する電子申請の許可の機能等が含まれ、社労士のログインに関する機能も含まれる。
この例では、電子政府に対する電子申請の手続については電子申請システムＥを利用して管理者が行い、被管理者は本システムＳを利用して、電子申請に必要なデータの管理者への提出と申請後の電子政府の発行したデータのファイルの管理者からの受取を行う。
またこの例では、管理者を会社（企業）とし、被管理者を当該会社の社員として説明するが、管理者（のオペレータ）を社労士とし、被管理者を企業或いは当該企業の社員としてもよい。
またこの例では、管理者を会社（企業）とし、被管理者を当該会社の社員として説明するが、管理者（のオペレータ）を社労士とし、被管理者を企業或いは当該企業の社員としてもよい。
また上記電子申請システムＥは、一括申請と単票形式の申請の双方を可能としてもよいが、一括申請のみ上記電子申請システムＥと別の電子申請システムにて行うものとし上記電子申請システムＥでは被管理者において単票形式の申請のみ行えるものとしてもよい。
一括申請に関し、上記電子申請システムＥにおいて、管理者として企業が電子政府へ電子申請を行う場合、複数の社員に関する手続を一括申請するものとしてもよいし、特定の社員の複数の手続を一括して行うことも可能である。また、管理者として社労士が電子政府へ電子申請を行う場合、複数の企業の社員について一括申請を行うものとすることもできる。また社労士において、それまで各省庁等所轄部署ごとに手続を行う必要があったが、電子政府への一括申請により、所轄部署ごとに手続をとる手間も省ける。
尚、この例のように本システムＳを電子申請システムＥに含まれるものとすることによって、管理者（のオペレータ）の端末ＰＣＭにて、電子申請に関連するデータファイルの取得の管理と申請の遂行の管理を一つのＵＩ（画面）にて一括して行える利点がある。
尚、この例のように本システムＳを電子申請システムＥに含まれるものとすることによって、管理者（のオペレータ）の端末ＰＣＭにて、電子申請に関連するデータファイルの取得の管理と申請の遂行の管理を一つのＵＩ（画面）にて一括して行える利点がある。
詳しくは、本システムＳは、上記端末ＰＣＭにおいて、電子申請手続と、電子申請のファイル作成に必要なデータの事前の収集と、電子申請後に手続先から受領した（発行データの）データファイルｆの複数の被管理者（従業員）への配布を一括して管理できる。上記配布に関しては、各被管理者の端末ＰＣｎ（その一つの端末ＰＣ１以外図示しない。）から、本システムＳヘアクセスすることにより、上記発行データのデータフィルｆを受け取ることができるのである。
上述の通り、電子申請システムＥは、手続先Ｇ（電子政府）への電子申請と当該手続先Ｇからの通知の受領とを、管理者のオペレータの上記端末ＰＣＭからの操作を受けネットワークＮを通じて当該手続先Ｇとの間にて行うのをサポートするものであり、電子申請システムＥは、電子申請補助システムＳを含む主機能をクラウド上に構築するのに適し、この例では、上述の外部連携ＡＰＩとして当該主機能について、Ｗｅｂサービスを提供する事業者の運営するクラウド上に置くものとする。
上述の通り、電子申請システムＥは、手続先Ｇ（電子政府）への電子申請と当該手続先Ｇからの通知の受領とを、管理者のオペレータの上記端末ＰＣＭからの操作を受けネットワークＮを通じて当該手続先Ｇとの間にて行うのをサポートするものであり、電子申請システムＥは、電子申請補助システムＳを含む主機能をクラウド上に構築するのに適し、この例では、上述の外部連携ＡＰＩとして当該主機能について、Ｗｅｂサービスを提供する事業者の運営するクラウド上に置くものとする。
具体的には、電子申請システムＥのプログラムは、電子申請システムＥの運用前サービスの提供事業者によって、ネットワークＮに接続されたクラウドサーバへインストールされ、利用契約した管理者へ管理者と被管理者の数に応じてアカウントが付与される。上記アカウントの取得により管理者と被管理者の夫々は、電子申請システムＥへログインして電子申請補助システムＳを利用することが可能となる。
上記電子申請システムＥに今後実施を展開するDirectHR(商標／株式会社エムケイシステム)を採用することができる。この例では、DirectHRの一部として本発明に係る電子申請補助システムＳ（mybox／商標／株式会社エムケイシステム）を含むものとする。
電子申請補助システムＳ（mybox）は、上記電子申請システムＥ（DirectHR）の一部として、電子申請について当該上記電子申請システムＥ（DirectHR）にて行う。
電子申請補助システムＳ（mybox）は、上記電子申請システムＥ（DirectHR）の一部として、電子申請について当該上記電子申請システムＥ（DirectHR）にて行う。
上記電子申請システムＥ（DirectHR）は、電子申請システムＥから発行された発行データのファイルであって管理者のオペレータの端末へダウンロードされたものを被管理者ごとに整理して表示することができる。
電子申請システムＥは、前述の外部連携ＡＰＩとして、一つのクラウド（一事業者が提供するクラウド）上から電子政府へ電子申請を行うことまで可能とする。
電子申請システムＥは、前述の外部連携ＡＰＩとして、一つのクラウド（一事業者が提供するクラウド）上から電子政府へ電子申請を行うことまで可能とする。
電子申請システムＥ（DirectHR）の機能として、上記の通り管理者のオペレータの端末ＰＣＭにおいて、電子政府への申請や発行データの受領の有無を一括して表示することができる。
電子申請補助システムＳ（mybox）は、管理者と被管理者との間のデータファイルの受け渡しにのみ使用し、管理者による電子申請は、上記電子申請システムＥ（DirectHR）とは別の電子申請システムＥＥを用いて行うものとしてもよい（図２）。
また、電子申請システムＥについて、申請の状況を管理するＵＩの提供を主機能とする、電子申請システムＥＥのサブセットとして実施することができる。
電子申請補助システムＳ（mybox）は、管理者と被管理者との間のデータファイルの受け渡しにのみ使用し、管理者による電子申請は、上記電子申請システムＥ（DirectHR）とは別の電子申請システムＥＥを用いて行うものとしてもよい（図２）。
また、電子申請システムＥについて、申請の状況を管理するＵＩの提供を主機能とする、電子申請システムＥＥのサブセットとして実施することができる。
図２へ示す別個の電子申請システムＥＥについては、社外のデータセンター（Datacenter）に設置されたサーバ上で稼働する「社労夢」を例示することができる。尚、電子申請システムＥＥの利用を前提とする場合、上記電子申請システムＥ（DirectHR）の電子申請に関する機能は不要であり、電子申請補助システムＳ（mybox）は、上記電子申請システムＥ（DirectHR）から独立したソフトウェアとサーバにて構築するものとしてもよい。
また、上記電子申請システムＥを用いない、即ち外部連携ＡＰＩを利用しない従来の電子申請においても、管理者と被管理者のデータファイルｆのやり取りのために本システムＳを用いることもできる。
また、上記電子申請システムＥを用いない、即ち外部連携ＡＰＩを利用しない従来の電子申請においても、管理者と被管理者のデータファイルｆのやり取りのために本システムＳを用いることもできる。
図２では、電子申請システムＥのクラウドサーバの置かれたデータセンターとは別のデータセンターのサーバに配置したWeb API Server（社労夢Web API Server）即ちウェブ・アプリケーション・プログラミング・インターフェース・サーバへAPI System（社労夢API System）即ちアプリケーション・プログラミング・インターフェースとデータベース(DB）を導入して電子申請システムＥＥを構築した例を示している。
尚、本発明の上記電子申請補助システムＳ（mybox）は、上記電子申請システムＥＥ（社労夢）に属するものとしてもよい。
また、図２に示すものは、上記電子申請システムＥＥを採用すること以外、図１及び図３へ示す例と同様であり、本発明に係る電子申請補助システムＳについては、図２に示すものも参照して説明を行う。
尚、本発明の上記電子申請補助システムＳ（mybox）は、上記電子申請システムＥＥ（社労夢）に属するものとしてもよい。
また、図２に示すものは、上記電子申請システムＥＥを採用すること以外、図１及び図３へ示す例と同様であり、本発明に係る電子申請補助システムＳについては、図２に示すものも参照して説明を行う。
特に、上記の一括申請や発行データの一括受領により、管理者において煩雑になりがちな複数の被管理者に関するデータファイルの取り扱いにおいて、本システムＳは、申請に必要な従業員の情報について当該情報のデータファイルの提出を従業員から受けるのに安全で利便性の高いシステムであると共に、電子申請システムＥを利用して得た発行データのファイルを該当する従業員へ安全に且つ円滑に配布することができる。
従業員（被管理者）の観点からは、当該従業員の端末ＰＣ１（コンピュータ）へ、クラウド上の電子申請補助システムＳに置かれた発行データのファイルをダウンロードすることができるという便利さがある。
従業員（被管理者）の観点からは、当該従業員の端末ＰＣ１（コンピュータ）へ、クラウド上の電子申請補助システムＳに置かれた発行データのファイルをダウンロードすることができるという便利さがある。
電子申請システムＥ（DirectHR）は、外部連携ＡＰＩとして、クラウド上にて手続先の発行する発行データのデータファイルｆを受領するものとしてもよいが、この例では発行データのデータファイルｆはネットワークＮを通じ管理者のオペレータの端末ＰＣＭにて受領するものとする。
即ち、この例では、電子政府に対する電子申請はクラウド上の電子申請システムＥから行い、電子政府から発行される公文書は管理者の（オペレータの）端末ＰＣＭへダウンロードされる。
即ち、この例では、電子政府に対する電子申請はクラウド上の電子申請システムＥから行い、電子政府から発行される公文書は管理者の（オペレータの）端末ＰＣＭへダウンロードされる。
詳しくは上記の電子申請は、管理者の端末にてクラウド上の電子申請システムＥを操作することによりクラウドから電子政府へデータを送信することで実行されるが、ここではクラウドも管理者の端末ＰＣＭの一部として、即ち管理者の端末ＰＣＭがクラウド上に拡張されたものとして説明する。但しこの例では上記の通り、電子政府が発行する公文書のデータファイルは、クラウド（クラウドサーバ）ではなく現実の管理者の端末ＰＣＭにて受領（受信）する。当該受領を直接管理者の端末ＰＣＭで一括して行い、当該端末ＰＣＭ上で、一括して受領したデータファイル（圧縮ファイル）を解凍して、該当する被管理者の夫々へ振分けるのである。
尚図１において、一名の従業員の端末ＰＣ１のみ示し他の従業員の端末ＰＣ２～ＰＣｎは省略する。以下当該端末ＰＣ１を複数の従業員（被管理者）の代表として説明する。
また、コンピュータである上記の端末ＰＣＭや端末ＰＣ１～ＰＣｎは、デスクトップやラップトップといった所謂パーソナルコンピュータの他、特にスマートフォンやタブレットといったモバイル機器を採用することができる。
また、コンピュータである上記の端末ＰＣＭや端末ＰＣ１～ＰＣｎは、デスクトップやラップトップといった所謂パーソナルコンピュータの他、特にスマートフォンやタブレットといったモバイル機器を採用することができる。
（電子申請補助システムＳの構成）
電子申請補助システムＳは、この例では、ウェブサービスを利用してクラウド上に構築されている。即ち、電子申請補助システムＳは、クラウドサーバへ導入された当該電子申請補助システムＳのプログラムと、クラウドサーバの協動により稼働する。
管理者のオペレータと各被管理者（従業員）は、夫々管理者の端末ＰＣＭや被管理者（従業員）の端末ＰＣ１から上記クラウドの電子申請補助システムＳへアクセスし、電子申請補助システムＳを操作する。
電子申請補助システムＳは、この例では、ウェブサービスを利用してクラウド上に構築されている。即ち、電子申請補助システムＳは、クラウドサーバへ導入された当該電子申請補助システムＳのプログラムと、クラウドサーバの協動により稼働する。
管理者のオペレータと各被管理者（従業員）は、夫々管理者の端末ＰＣＭや被管理者（従業員）の端末ＰＣ１から上記クラウドの電子申請補助システムＳへアクセスし、電子申請補助システムＳを操作する。
電子申請補助システムＳは、電子申請システムＥの一部として、管理者の端末ＰＣＭへのインストールと共に上記クラウドへ導入されるものとしてもよいが、この例のように、電子申請補助システムＳは、電子申請システムＥとは独立したものとして上記クラウド上に構築されるものとしても実施できる。
この電子申請補助システムＳは、システム制御部１と、申請データ収容部２と、管理テーブル収容部３と、キー生成部４と、暗号生成部５と、復号部６と、アクセス制御部７と、個別表示部８、管理用表示部９と、ログイン画面表示部１０と、認証データ仮収容部１１と、仮収容部１２と、キー仮収容部４０とを備える。
各構成について順に説明する。
各構成について順に説明する。
（システム制御部１）
システム制御部１は、電子申請補助システムＳの上記他の構成２～４０の動作を制御する。
システム制御部１は、電子申請補助システムＳの上記他の構成２～４０の動作を制御する。
（申請データ収容部２）
申請データ収容部２は、申請関連データのファイルを収容する。
申請関連データのファイルｆ（以下必要に応じて申請関連データのファイルｆを単にデータファイルｆと呼ぶ。）は、申請手続に必要な被管理者の申請用データのファイルと申請手続の手続先Ｇにて発行された発行データのファイルの少なくとも何れかである。
申請データ収容部２は、申請関連データのファイルを収容する。
申請関連データのファイルｆ（以下必要に応じて申請関連データのファイルｆを単にデータファイルｆと呼ぶ。）は、申請手続に必要な被管理者の申請用データのファイルと申請手続の手続先Ｇにて発行された発行データのファイルの少なくとも何れかである。
申請データ収容部２には、システム制御部１により、申請関連データのファイルｆを収容するファイル別収容部２１が、申請関連データのファイルｆ毎に形成される。
ファイル別収容部２１には識別子となるキーｋがシステム制御部１にて付与される。
申請データ収容部２において、ファイル別収容部２１は階層構造を採らず上層のディレクトリから下層のディレクトリを辿ることで目的とするファイル別収容部２１を特定することができない。ファイル別収容部２１は当該キーｋのみにて特定される。
ファイル別収容部２１には識別子となるキーｋがシステム制御部１にて付与される。
申請データ収容部２において、ファイル別収容部２１は階層構造を採らず上層のディレクトリから下層のディレクトリを辿ることで目的とするファイル別収容部２１を特定することができない。ファイル別収容部２１は当該キーｋのみにて特定される。
（管理テーブル収容部３）
システム制御部１の制御の下、管理テーブル収容部３には、ファイル別収容部２１へ収容される申請関連データのファイルｆのファイル名のデータ（暗号）と、当該申請関連データのファイルｆの被管理者の識別子（ＩＤ）のデータ（平文）と、ファイル別収容部２１を特定するキーｋを生成する要素となる１つ又は複数の要素データ（暗号）とを含むレコードを、収容するテーブルｔが形成される。この例では、上記の通り、管理者は企業であり、被管理者は当該企業の社員であり、被管理者の上記識別子は社員番号である。
システム制御部１の制御の下、管理テーブル収容部３には、ファイル別収容部２１へ収容される申請関連データのファイルｆのファイル名のデータ（暗号）と、当該申請関連データのファイルｆの被管理者の識別子（ＩＤ）のデータ（平文）と、ファイル別収容部２１を特定するキーｋを生成する要素となる１つ又は複数の要素データ（暗号）とを含むレコードを、収容するテーブルｔが形成される。この例では、上記の通り、管理者は企業であり、被管理者は当該企業の社員であり、被管理者の上記識別子は社員番号である。
具体的には、上記テーブルｔには、少なくとも、ファイル別収容部２１へ収容される申請関連データのファイル（データファイルｆ）の暗号化されたファイル名のデータと、当該データファイルｆの被管理者の暗号化されていない識別子と、申請データ収容部２へ収容されるデータファイルｆのロード元の場所（データのロード元）を示す暗号化されたデータと、当該データファイルの所有者即ち被管理者の氏名の暗号化されたデータを含むレコードが収容される（図４）。
但し、上記のテーブルｔには申請関連データのファイルｆ自体を収容しない。
但し、上記のテーブルｔには申請関連データのファイルｆ自体を収容しない。
図４には、最小構成のレコード（ロウ／行）の夫々を収容した状態のテーブルｔ示す（図４では、各レコードに含まれる他のデータ、言い換えると表中他のカラムは省略する）。図４（Ａ）は被管理者によるデータファイルｆのアップロードにて形成されるテーブルの（レコードの）要部を示し、図４（Ｂ）は管理者によるデータファイルのアップロードにて形成されるテーブルの（レコードの）要部を示すものであるが、何れのテーブルも被管理者の識別子に紐づけられており、テーブルｔを図４（Ａ）（Ｂ）へ示すように上記被管理者側と管理者側に分ける必要はない（但し分けてもよい）。
図４の各テーブルｔにおいて被管理者を特定する識別子以外のデータは、後述する暗号生成部５にて暗号化されている（図４では説明の便宜上識別子以外のデータ（ファイル名）も平文で示す）。
図４の各テーブルｔにおいて被管理者を特定する識別子以外のデータは、後述する暗号生成部５にて暗号化されている（図４では説明の便宜上識別子以外のデータ（ファイル名）も平文で示す）。
また管理テーブル収容部３には、上記テーブルｔとは別に、上記オペレータのメールアドレスのデータと上記オペレータによって事前に設定されたパスワードのデータが上記オペレータの識別子と関連付けて収容された、即ち上記オペレータのメールアドレスのデータと上記オペレータによって事前に設定されたパスワードのデータと上記オペレータの識別子とを含むレコードを収容する、管理者認証テーブルｔ１が設けられている。
更に管理テーブル収容部３には、上記テーブルｔ及び管理者認証テーブルｔ１とは別に、各被管理者のメールアドレスのデータと各被管理者によって事前に設定されたパスワードのデータと各被管理者の識別子と関連付けて収容された、即ち、各被管理者のメールアドレスのデータと各被管理者によって事前に設定されたパスワードのデータと各被管理者の識別子とを含むレコードを収容する、被管理者認証テーブルｔ２が設けられている。
更に管理テーブル収容部３には、上記テーブルｔ及び管理者認証テーブルｔ１とは別に、各被管理者のメールアドレスのデータと各被管理者によって事前に設定されたパスワードのデータと各被管理者の識別子と関連付けて収容された、即ち、各被管理者のメールアドレスのデータと各被管理者によって事前に設定されたパスワードのデータと各被管理者の識別子とを含むレコードを収容する、被管理者認証テーブルｔ２が設けられている。
（キー生成部４）
システム制御部１の制御の下、キー生成部４は、管理テーブル収容部３のテーブルｔに収容されたレコードが有する上記要素データを更に暗号化することによって、ファイル別収容部２１に付与する上記キーｋを生成する。
キー生成部４は、アップロード又はダウンロードするデータファイルの暗号化されたファイル名のデータを、上記要素データの１つとする。
上記の通り、この例では、データファイルｆの暗号化されたファイル名のデータ以外の上記要素データは、申請データ収容部２へ収容されるデータファイルｆの元の所在即ちロード元の場所（データのロード元のリンク）を示す暗号化されたデータと、当該データファイルの所有者即ち被管理者の氏名の暗号化されたデータとする。
システム制御部１の制御の下、キー生成部４は、管理テーブル収容部３のテーブルｔに収容されたレコードが有する上記要素データを更に暗号化することによって、ファイル別収容部２１に付与する上記キーｋを生成する。
キー生成部４は、アップロード又はダウンロードするデータファイルの暗号化されたファイル名のデータを、上記要素データの１つとする。
上記の通り、この例では、データファイルｆの暗号化されたファイル名のデータ以外の上記要素データは、申請データ収容部２へ収容されるデータファイルｆの元の所在即ちロード元の場所（データのロード元のリンク）を示す暗号化されたデータと、当該データファイルの所有者即ち被管理者の氏名の暗号化されたデータとする。
上記要素データのうち、データファイルｆの上記ロード元の場所を示すデータとは、被管理者がアップロードするデータファイルｆ即ち申請用データのファイルｆについては、被管理者の端末における当該データファイルｆのファイルパスを指し、管理者がアップロードするデータファイルｆ即ち発行データのファイルについては、当該データファイルｆを発行する手続先のダウンロードリンクを指す。この例では、上記の通り要素データとしてリソース名を採用するが、上記以外のデータを要素データとして実施することも可能である。例えばファイルの作成日時（後述するS3バケットのメタデータ）を要素データとして、他の要素データに代え或いは他の要素データと共に採用するものとしてもよい。
キー生成部４は、不可逆的に要素データから暗号を生成することができるものとするのが好ましい。キー生成部４については、暗号生成部５の生成する暗号のように、暗号化データの元の平文（プレーンテキスト）とするために復号部６により復号を行えるものとする必要がないからである。
この例では、キー生成部４は、ハッシュ関数を用い複数の要素データを纏めてハッシュ化し、キーｋとなる１つのデータを生成する。
キーｋは、ファイルデータｆを他のファイルデータｆと識別できるユニークなものであればよい。
従って、キー生成部４は、暗号化する入力データ同士を同一のデータとした場合出力データ同士も必ず同一とするものであればよく、本発明に係る電子申請補助システム（クラウド）上で復号化しない分機密性の高いデータファイルｆの取り扱いが行える。
この例では、キー生成部４は、ハッシュ関数を用い複数の要素データを纏めてハッシュ化し、キーｋとなる１つのデータを生成する。
キーｋは、ファイルデータｆを他のファイルデータｆと識別できるユニークなものであればよい。
従って、キー生成部４は、暗号化する入力データ同士を同一のデータとした場合出力データ同士も必ず同一とするものであればよく、本発明に係る電子申請補助システム（クラウド）上で復号化しない分機密性の高いデータファイルｆの取り扱いが行える。
暗号生成部５により暗号化されたデータファイルｆは、クラウド上で復号されずダウンロード先の端末にて復号される。事前に復号鍵を管理者（のオペレータ）や被管理者に供与しておく。またＳＳＬ（セキュア・ソケット・レイヤ）を利用して、端末に導入されているｗｅｂブラウザで復号化されたデータを見ることができるものとしてもよい。
キー生成部４には、クラウド上で要素データを暗号化する適切なインスタンスを提供するものであれば、クラウドサービスが用意するものを利用することができる。
キー生成部４は、例えばキー生成部４は、メッセージ要約（メッセージダイジェスト）関数を用いて、キーｋを生成するものとすることができる。
キー生成部４には、クラウド上で要素データを暗号化する適切なインスタンスを提供するものであれば、クラウドサービスが用意するものを利用することができる。
キー生成部４は、例えばキー生成部４は、メッセージ要約（メッセージダイジェスト）関数を用いて、キーｋを生成するものとすることができる。
メッセージ要約関数を用いることにより、各キー生成前の各要素データの合計サイズが一様でなくとも、生成するキーｋのデータサイズを常に一定（固定長）とすることができる。検索するキーｋの長さ（データ長）を常に一定とすることにより、検索対象の桁数を一定とすることができ、円滑な検索が行えるのである。
メッセージ要約関数の一例として、ＳＨＡ－０やＳＨＡ－１、ＳＨＡ－２、ＳＨＡ－３を挙げることができるが、周知の他のアルゴリズムを採用して実施することも可能である。また、キーｋに高い強度が要求されない場合、ＭＤ５を用いて実施するのを排除するものではない。
また、キー生成部４は、上記以外のハッシュ関数を用いてキーｋを生成するものとしてもよい。
キー生成部ｋにおいて、実用的な範囲内で、異なるデータの暗号化が同一の結果にならない（衝突しない）ものとできればよいのである。
例えば、後述するAmazon（登録商標）のウェブサービスを利用する場合、リージョンコード（どの国、地域へ設置されたサーバへデータを置くかを示す。）も要素データとすることができるが、本システムＳをオンプレミスなシステムとして構築した場合や国内のサーバを利用する場合は、リージョンコードは不要であり、国内や社内の利用において衝突しないキーｋであればよい。
メッセージ要約関数の一例として、ＳＨＡ－０やＳＨＡ－１、ＳＨＡ－２、ＳＨＡ－３を挙げることができるが、周知の他のアルゴリズムを採用して実施することも可能である。また、キーｋに高い強度が要求されない場合、ＭＤ５を用いて実施するのを排除するものではない。
また、キー生成部４は、上記以外のハッシュ関数を用いてキーｋを生成するものとしてもよい。
キー生成部ｋにおいて、実用的な範囲内で、異なるデータの暗号化が同一の結果にならない（衝突しない）ものとできればよいのである。
例えば、後述するAmazon（登録商標）のウェブサービスを利用する場合、リージョンコード（どの国、地域へ設置されたサーバへデータを置くかを示す。）も要素データとすることができるが、本システムＳをオンプレミスなシステムとして構築した場合や国内のサーバを利用する場合は、リージョンコードは不要であり、国内や社内の利用において衝突しないキーｋであればよい。
（暗号生成部５）
申請関連のファイルｆのファイル別収容部２１への収容に際し、暗号生成部５は、当該ファイルｆのファイル名のデータと他の上記要素データの夫々を暗号化して管理テーブル収容部３のテーブルｔへ収容する。
暗号生成部５の暗号を生成するアルゴリズムの一例を挙げると、AES（AES-256）、ARIA、Blowfish、Camellia、CAST-128、CAST-256、DES、DES-X、3DES、FEAL、IDEA、KASUMI、Lucifer、MISTY1、MULTI2、RC2、RC5、RC6、 SEED、Serpent、Square或いはTwofishを用いることができる。キー生成部４と同様のメッセージ要約関数を採用してもよいが、メッセージ要約関数は暗号化の所要時間が比較的大きいためキーｋなどの暗号前の平文のデータ長の比較的短いものの暗号化に適するものであり、ＳＳＬなどストリーミングに多用される上記ＲＣ２～ＲＣ６が暗号生成部５のアルゴリズムとしては適している。
但し暗号生成部５は、例示した以外の周知のアルゴリズムを採用するものとしてもよい。
申請関連のファイルｆのファイル別収容部２１への収容に際し、暗号生成部５は、当該ファイルｆのファイル名のデータと他の上記要素データの夫々を暗号化して管理テーブル収容部３のテーブルｔへ収容する。
暗号生成部５の暗号を生成するアルゴリズムの一例を挙げると、AES（AES-256）、ARIA、Blowfish、Camellia、CAST-128、CAST-256、DES、DES-X、3DES、FEAL、IDEA、KASUMI、Lucifer、MISTY1、MULTI2、RC2、RC5、RC6、 SEED、Serpent、Square或いはTwofishを用いることができる。キー生成部４と同様のメッセージ要約関数を採用してもよいが、メッセージ要約関数は暗号化の所要時間が比較的大きいためキーｋなどの暗号前の平文のデータ長の比較的短いものの暗号化に適するものであり、ＳＳＬなどストリーミングに多用される上記ＲＣ２～ＲＣ６が暗号生成部５のアルゴリズムとしては適している。
但し暗号生成部５は、例示した以外の周知のアルゴリズムを採用するものとしてもよい。
（復号部６）
復号部６は、暗号生成部５が暗号化したデータを復号化する。復号部６は、暗号生成部５の生成する暗号鍵と同時に生成される復号鍵にて、暗号生成部５の暗号化したデータを復号する。
復号部６は、暗号生成部５が暗号化したデータを復号化する。復号部６は、暗号生成部５の生成する暗号鍵と同時に生成される復号鍵にて、暗号生成部５の暗号化したデータを復号する。
（アクセス制御部７）
アクセス制御部７は、管理者及び被管理者の本発明に係る電子申請補助システムＳへのアクセスを認証し、管理者の場合管理者権限でのログインを許可し、と、被管理者の場合被管理者権限でのログインを許可する。
また、他の者（管理者及び被管理者以外の者）のログインを拒絶する。
この例では、端末からのログイン時に、アクセス制御部７が、ログインする者のメールアドレスとパスワードの入力を受けて、上記管理者認証テーブルｔ１と被管理者認証テーブルｔ２とを参照して、ログインを管理者権限によるものか被管理者権限によるものか判断し、必要なアクセスの制限を行う。但し、ログインに際して上記メールアドレスに代え、ログインする者の識別子を入力させるものとしてもよい。
アクセス制御部７は、管理者及び被管理者の本発明に係る電子申請補助システムＳへのアクセスを認証し、管理者の場合管理者権限でのログインを許可し、と、被管理者の場合被管理者権限でのログインを許可する。
また、他の者（管理者及び被管理者以外の者）のログインを拒絶する。
この例では、端末からのログイン時に、アクセス制御部７が、ログインする者のメールアドレスとパスワードの入力を受けて、上記管理者認証テーブルｔ１と被管理者認証テーブルｔ２とを参照して、ログインを管理者権限によるものか被管理者権限によるものか判断し、必要なアクセスの制限を行う。但し、ログインに際して上記メールアドレスに代え、ログインする者の識別子を入力させるものとしてもよい。
管理者のオペレータの端末ＰＣＭから適正なログインが行われた場合、アクセス制御部７は当該オペレータにはテーブルｔ中の被管理者全員のレコードへのアクセスを許可する。一方、被管理者の一人の端末ＰＣ１から適正なログインが行われた場合、アクセス制御部７はテーブルｔ中当該被管理者本人のレコードへのアクセスのみ許可しテーブルｔ中他の（本人以外の）被管理者のレコードを隠蔽して当該他の被管理者のレコードへのアクセスを制限する。
被管理者に対する上記認証に関し詳しくは、被管理者によるメールアドレスとパスワードの本発明に係る電子申請補助システムＳへの事前の設定（申告）において、他の被管理者と重複しないパスワード又はパスワードとメールアドレスの組み合わせを設定（申告）させる（重複する場合電子申請補助システムＳは設定を拒否する）。
電子申請補助システムＳは、被管理者のログイン時上記にて設定されているメールアドレスとパスワードと同一のメールアドレスとパスワードの入力を受け付けると、被管理者認証テーブルｔ２へ設定された上記メールアドレスとパスワードに対応する識別子の被管理者のテーブルｔのみログインした被管理者へアクセスを許可することで、他の被管理者のテーブルｔの上記隠蔽を行うことができる。
上述の通り、アクセス制御部７は、管理者権限のログインか被管理者権限のログインかを判断してログインした者に対しアクセス制限を行う。
上述の通り、アクセス制御部７は、管理者権限のログインか被管理者権限のログインかを判断してログインした者に対しアクセス制限を行う。
（個別表示部８）
個別表示部８は、本発明に係る電子申請補助システムＳへログインした被管理者の端末へ操作画面を表示させ、被管理者の操作を受け付ける。個別表示部８は、アクセス制御部７にて制限した即ち本人以外の被管理者以外の被管理者の情報を当該被管理者の端末へ表示させない。
個別表示部８は、本発明に係る電子申請補助システムＳへログインした被管理者の端末へ操作画面を表示させ、被管理者の操作を受け付ける。個別表示部８は、アクセス制御部７にて制限した即ち本人以外の被管理者以外の被管理者の情報を当該被管理者の端末へ表示させない。
（管理用表示部９）
管理用表示部９は、本発明に係る電子申請補助システムＳへログインした管理者の（オペレータの）端末ＰＣＭへ操作画面を表示させ、管理者のオペレータの操作を受け付ける。管理者用表示部９は、アクセス制御部７にて制限されていない、即ち被管理者全員の情報を管理者のオペレータの端末ＰＣＭへ表示させる。
管理用表示部９は、本発明に係る電子申請補助システムＳへログインした管理者の（オペレータの）端末ＰＣＭへ操作画面を表示させ、管理者のオペレータの操作を受け付ける。管理者用表示部９は、アクセス制御部７にて制限されていない、即ち被管理者全員の情報を管理者のオペレータの端末ＰＣＭへ表示させる。
（ログイン画面表示部１０）
ログイン画面表示部１０は、被管理者及び管理者のオペレータの端末の夫々に、ログイン画面を表示し、アクセス制限に必要なデータの入力を受け付ける。この例では、事前に被管理者認証テーブルｔ１又は管理者認証テーブルｔ２へ登録されているメールアドレスとパスワードの入力を受け付ける。
ログイン画面表示部１０は、被管理者及び管理者のオペレータの端末の夫々に、ログイン画面を表示し、アクセス制限に必要なデータの入力を受け付ける。この例では、事前に被管理者認証テーブルｔ１又は管理者認証テーブルｔ２へ登録されているメールアドレスとパスワードの入力を受け付ける。
（認証データ仮収容部１１）
認証データ仮収容部１１は、ログイン画面表示部１０の提供する上記ログイン画面にて入力されたアクセス制限に必要な上記データ、即ちメールアドレスとパスワードの各データを一時的に収容する。ここで一時的に収容するとは管理者又は被管理者のオペレータが本発明に係る電子申請補助システムからログアウトするとデータを揮発させる（消去する）か、後の処理にてデータで上書きするという意味である。
認証データ仮収容部１１は、ログイン画面表示部１０の提供する上記ログイン画面にて入力されたアクセス制限に必要な上記データ、即ちメールアドレスとパスワードの各データを一時的に収容する。ここで一時的に収容するとは管理者又は被管理者のオペレータが本発明に係る電子申請補助システムからログアウトするとデータを揮発させる（消去する）か、後の処理にてデータで上書きするという意味である。
上記アクセス制御部７は、認証データ仮収容部１１に収容された、ログインする者にて入力されたメールアドレスとパスワードの各データを参照すると共に、上記管理者認証テーブルｔ１と被管理者認証テーブルｔ２とを参照して、ログインした者が管理者権限によるものか被管理者権限によるものか判断し必要な前記アクセスの制限を行う。当該アクセスの制限により、被管理者は本システムＳに対するファイルのアップロード、ファイルのダウンロード及びファイルの削除の各処理ついて、自己のファイルに対し行うことができるが、他の被管理者のファイルに対し当該各処理を行うことができない。管理者のオペレータは、何れの被管理者のファイルについても、ダウンロードやアップロード、削除の各処理を行うことができる。
（仮収容部１２）
仮収容部１２は、被管理者又は管理者のオペレータから受け付けたアップロードするデータのファイルｆや、当該ファイルに関する暗号化前の即ちテーブルｔへ収容される前のデータの夫々を一時的に収容する。また、既にアップロードされているデータのファイルｆへのアクセスの過程において、当該データファイルｆに関するテーブルｔ内の暗号化されたファイル名、ファイルパス又はダウンロードリンク、ファイルの所有者名の各データを復号し、復号化されたデータ（平文）を一時的に収容する。
仮収容部１２は、被管理者又は管理者のオペレータから受け付けたアップロードするデータのファイルｆや、当該ファイルに関する暗号化前の即ちテーブルｔへ収容される前のデータの夫々を一時的に収容する。また、既にアップロードされているデータのファイルｆへのアクセスの過程において、当該データファイルｆに関するテーブルｔ内の暗号化されたファイル名、ファイルパス又はダウンロードリンク、ファイルの所有者名の各データを復号し、復号化されたデータ（平文）を一時的に収容する。
但し、仮収容部１２とは別途の副仮収容部を備えるものとして（図示しない。）、当該副仮収容部へ上記にて復号化されたデータ（平文）を一時的に収容するものとしてもよい。
ダウンロードするデータのファイルｆ自体は、暗号化されたまま、ダウンロードを要求した端末へダウンロードされ、当該端末にて復号するものとすればよい。特にＳＳＬを利用して、当該端末のブラウザにてダウンロードされたファイルを復号するものとしても実施できる。
ダウンロードするデータのファイルｆ自体は、暗号化されたまま、ダウンロードを要求した端末へダウンロードされ、当該端末にて復号するものとすればよい。特にＳＳＬを利用して、当該端末のブラウザにてダウンロードされたファイルを復号するものとしても実施できる。
（キー仮収容部４０）
キー仮収容部４０には、キー生成部４の生成したキーｋが一時的に収容される。
この例ではキー仮収容部４０には、ファイル別収容部２１を検索する際に生成されたキーｋが一時的に収容される。
キー仮収容部４０には、キー生成部４の生成したキーｋが一時的に収容される。
この例ではキー仮収容部４０には、ファイル別収容部２１を検索する際に生成されたキーｋが一時的に収容される。
（電子申請補助システムＳを構築するに適した環境の例）
この電子申請補助シテスムＳについて、例えばAmazon.com（Amazon／登録商標）により提供されているクラウドコンピューティングサービス（ウェブサービス）であるAmazon Web Services（アマゾン ウェブ サービス、AWS／登録商標）を利用することができる（図２）。詳しくは、この電子申請補助シテスムＳに関し、上記AWSのサービスであるAmazon Elastic Compute Cloud (EC2) とAmazon Simple Storage Service (S3) を利用して構築することができる。AWSは、クラウドのタイプとしてはIaaS（Infrastructure as a Service）に分類される。
この電子申請補助シテスムＳについて、例えばAmazon.com（Amazon／登録商標）により提供されているクラウドコンピューティングサービス（ウェブサービス）であるAmazon Web Services（アマゾン ウェブ サービス、AWS／登録商標）を利用することができる（図２）。詳しくは、この電子申請補助シテスムＳに関し、上記AWSのサービスであるAmazon Elastic Compute Cloud (EC2) とAmazon Simple Storage Service (S3) を利用して構築することができる。AWSは、クラウドのタイプとしてはIaaS（Infrastructure as a Service）に分類される。
IaaSは、情報システムの稼動に必要な仮想サーバをはじめとした機材やネットワークなどのインフラを、インターネット上のサービスとして提供する形態のことを指す。IaaSは、これまでのホスティングサービス（レンタルサーバや共用サーバ）とサーバを利用する際に必要なハードウェアのスペックやＯＳ（オペレーティングシステム）を、利用者が自分で自由に選定して、ネットワーク越しに利用することが可能な点について異なる。
Amazon Elastic Compute Cloudは、AWS クラウドでサイズ変更の可能なコンピューティングキャパシティーを提供する。（https://docs.aws.amazon.com/ja_jp/AmazonS3/latest/dev/bucket-encryption.html）。AmazonEC2 を使用して必要な数 (またはそれ以下) の仮想サーバを起動して、セキュリティおよびネットワーキングの設定と、ストレージの管理を行うことができる。
但し、本システムＳを、SaaS（Software as a Service）やPaaS（Platform as a Service）タイプのクラウドを利用して構築するものとしても良いし、完全にオンプレミスのシステムとして構築しても良い。
但し、本システムＳを、SaaS（Software as a Service）やPaaS（Platform as a Service）タイプのクラウドを利用して構築するものとしても良いし、完全にオンプレミスのシステムとして構築しても良い。
本発明に係る上記電子申請補助システムＳは、Amazon EC2の次の１）～５）の機能を利用して実現することができる。
１）インスタンスと呼ばれる仮想コンピューティング環境。
ここでは物理的な一台のコンピュータ上でソフトウェアとして実装された仮想的なコンピュータを起動したものを上記インスタンス（VMインスタンス、仮想化インスタンス）と呼ぶ。
１）インスタンスと呼ばれる仮想コンピューティング環境。
ここでは物理的な一台のコンピュータ上でソフトウェアとして実装された仮想的なコンピュータを起動したものを上記インスタンス（VMインスタンス、仮想化インスタンス）と呼ぶ。
２）サーバに必要なビットをパッケージ化した (オペレーティングシステム及び追加のソフトウェアを含む。)、Amazon Machine Image (AMI) と呼ばれる、インスタンス用に事前に設定されたテンプレート。
３）インスタンスタイプと呼ばれる、インスタンス用のCPU、メモリ、ストレージ、ネットワーキングキャパシティーの様々な構成。
３）インスタンスタイプと呼ばれる、インスタンス用のCPU、メモリ、ストレージ、ネットワーキングキャパシティーの様々な構成。
４）キーペアを使用したインスタンス用の安全なログイン情報 (AWS はパブリックキー（公開鍵）を保存し、ユーザはプライベートキー（秘密鍵）を安全な場所に保存する。
５）インスタンスストアボリュームと呼ばれる、インスタンスを停止または終了するときに削除される一時データ用のストレージボリューム。
５）インスタンスストアボリュームと呼ばれる、インスタンスを停止または終了するときに削除される一時データ用のストレージボリューム。
即ち、上記１）～５）（EC2 instance contents）にてインスタンスとデータベースにより本システムＳの上記各部１，３～４０を構成することができる（図２）。また、上記Ｓ３(Amazon S3)にて本発明の申請データ収容部２を構成することができる。
例えば暗号生成部５及び復号部６、アクセス制御部７は、上記キーペアを使用するものとして実施することができる。図４中「他のサーバーサービス」とは上記AWS以外のサーバーサービスを指す。
例えば暗号生成部５及び復号部６、アクセス制御部７は、上記キーペアを使用するものとして実施することができる。図４中「他のサーバーサービス」とは上記AWS以外のサーバーサービスを指す。
AWSにおける暗号化を使用したデータの保護について更に具体的に説明すると（https://docs.aws.amazon.com/ja_jp/AmazonS3/latest/dev/UsingEncryption.html）、データ保護には、
ａ）転送時 (Amazon S3 との間でデータを送受信するとき) のデータを保護するものと、
ｂ）保管時 (Amazon S3 データセンター内のディスクに格納されているとき) のデータを保護するものがある。
ａ）転送時 (Amazon S3 との間でデータを送受信するとき) のデータを保護するものと、
ｂ）保管時 (Amazon S3 データセンター内のディスクに格納されているとき) のデータを保護するものがある。
上記ａ）の例として、Secure Sockets Layer (SSL) またはクライアント側の暗号化を使用して、転送時のデータを保護できる。
上記ｂ）にはｂ－１）サーバ側の暗号化と、ｂ－２）クライアント側の暗号化というオプションがある。
上記ｂ－１）は、オブジェクトをデータセンター内のディスクに保存する前に暗号化し、オブジェクトをダウンロードするときに復号するようにAmazon S3にリクエストする。
上記ｂ－２）は、クライアント側でデータを暗号化し、暗号化したデータを Amazon S3 にアップロードする。この場合、暗号化プロセス、暗号化キー、関連ツールは利用者（管理者及び被管理者）の端末にて処理される。
この例では、本システムＳは、ｗｅｂ（クラウド）サービスを利用し、上記ａ）とｂ－２）とを採用する。具体的には、この例では、後述するMVC適合部を利用して上記ａ）及びｂ－２）を採用する。但し、本システムＳは、後述するMVC適合部と共に申請データ収容部２（ストレージサービス適合部）を備える上記S3の機能を利用して、上記ａ）とｂ－１）を採用して実施してもよい。
上記ｂ）にはｂ－１）サーバ側の暗号化と、ｂ－２）クライアント側の暗号化というオプションがある。
上記ｂ－１）は、オブジェクトをデータセンター内のディスクに保存する前に暗号化し、オブジェクトをダウンロードするときに復号するようにAmazon S3にリクエストする。
上記ｂ－２）は、クライアント側でデータを暗号化し、暗号化したデータを Amazon S3 にアップロードする。この場合、暗号化プロセス、暗号化キー、関連ツールは利用者（管理者及び被管理者）の端末にて処理される。
この例では、本システムＳは、ｗｅｂ（クラウド）サービスを利用し、上記ａ）とｂ－２）とを採用する。具体的には、この例では、後述するMVC適合部を利用して上記ａ）及びｂ－２）を採用する。但し、本システムＳは、後述するMVC適合部と共に申請データ収容部２（ストレージサービス適合部）を備える上記S3の機能を利用して、上記ａ）とｂ－１）を採用して実施してもよい。
上記S3バケットは、オブジェクトとして申請関連データのファイルを収容する上記ファイル別収容部２１を構成する。
上記ｂ）に関して、ファイル別収容部２１を構成する上記S3バケット（図２及び図３（Ｂ）のバケツの印）のAmazon S3によるデフォルトまたはS3バケットのデフォルト暗号化の動作を設定できる。尚、１つのS3バケットは、１つのファイル別収容部２１として、１つの申請関連データのファイルをオブジェクトとして収容するものであってもよいが、この他、複数のファイル別収容部２１として複数のオブジェクトを収容するものとしてもよい。即ち、被管理者毎に１つのS3バケットを割り当て、１つのS3バケットへ一人の被管理者に関する複数の申請関連データのファイルを収容する複数のファイル別収容部２１を形成するものとしてもよい。後述するようなファイルｆ別ではなく、被管理者毎にファイルｆを纏めてアップロードやダウンロードするものとしてもよいのである。
上記バケットにデフォルト暗号化を設定して、上記バケットに保存される際すべてのオブジェクトが暗号化されるようにすることもできるが、パケットへ収容されるデータファイルｆは収容時上記ａ）にて既に暗号化されているので、この例では、上記要素データのみ上記ａ)又はｂ）にて暗号化（キーｋを生成）するものとする。
上記ｂ）に関して、ファイル別収容部２１を構成する上記S3バケット（図２及び図３（Ｂ）のバケツの印）のAmazon S3によるデフォルトまたはS3バケットのデフォルト暗号化の動作を設定できる。尚、１つのS3バケットは、１つのファイル別収容部２１として、１つの申請関連データのファイルをオブジェクトとして収容するものであってもよいが、この他、複数のファイル別収容部２１として複数のオブジェクトを収容するものとしてもよい。即ち、被管理者毎に１つのS3バケットを割り当て、１つのS3バケットへ一人の被管理者に関する複数の申請関連データのファイルを収容する複数のファイル別収容部２１を形成するものとしてもよい。後述するようなファイルｆ別ではなく、被管理者毎にファイルｆを纏めてアップロードやダウンロードするものとしてもよいのである。
上記バケットにデフォルト暗号化を設定して、上記バケットに保存される際すべてのオブジェクトが暗号化されるようにすることもできるが、パケットへ収容されるデータファイルｆは収容時上記ａ）にて既に暗号化されているので、この例では、上記要素データのみ上記ａ)又はｂ）にて暗号化（キーｋを生成）するものとする。
上記の通りこの例では、本システムＳにおいて、当該オブジェクトは、上記要素データであり、AmazonS3で管理されたキー(SSE-S3)またはAWS KMSで管理されたキー(SSE-KMS)といった、サーバ側の暗号化（キー生成部４）を使用して暗号化される。
通常、サーバ側の上記暗号化を使用すると、Amazon S3 はオブジェクトをサーバ内のディスクに保存する前に暗号化し、上記の通りオブジェクトをダウンロードするときに復号する。
本システムＳでは、S3バケットポリシーを設定して、暗号化情報が含まれていないストレージリクエストを拒否するように設定する。
通常、サーバ側の上記暗号化を使用すると、Amazon S3 はオブジェクトをサーバ内のディスクに保存する前に暗号化し、上記の通りオブジェクトをダウンロードするときに復号する。
本システムＳでは、S3バケットポリシーを設定して、暗号化情報が含まれていないストレージリクエストを拒否するように設定する。
暗号化された複数の要素データからキーｋを生成する本システムＳの上記キー生成部４について、上記ａ）即ち、暗号生成部５及び復号部６、アクセス制御部７と異なり、上記ｂ）の通り暗号生成部５により暗号化されている要素データをオブジェクトとして、上記SSE-S3又はSSE-KMSによるサーバ側の暗号化を使用して暗号化される。
通常ダウンロード時の上記復号にて、オブジェクトは復号されるのであるが、本システムＳにおいて、キー生成部ｋによって生成されたキーｋは復号化されることなく、ダウンロード時キー生成部４によって再度生成され、S3バケット名として当該キーｋが付されたS3バケットの特定にのみ使用される。
このように本発明は、通常データの改ざん防止やデータの真正性の証明に利用される手法を、データの検索に用いるという斬新なものである。
通常ダウンロード時の上記復号にて、オブジェクトは復号されるのであるが、本システムＳにおいて、キー生成部ｋによって生成されたキーｋは復号化されることなく、ダウンロード時キー生成部４によって再度生成され、S3バケット名として当該キーｋが付されたS3バケットの特定にのみ使用される。
このように本発明は、通常データの改ざん防止やデータの真正性の証明に利用される手法を、データの検索に用いるという斬新なものである。
図３（Ａ）は本システムＳの構成を物理構成寄りに示したものであり、図３（Ｂ）は本システムの構成をソフトウエアアーキテクチャ寄りに示したものである。
図３（Ａ）へ示す通り、本システムＳは階層構造（多層アーキテクチャ）をなしている。
一般にＷｅｂアプリケーションは、Ｗｅｂサーバ、アプリケーションサーバ、ＤＢ（データベース）サーバの３種のサーバにて構成される。
上記３種のサーバのうち、上記アプリケーションサーバで稼働しているプログラムの内部構造について、この例では、プレゼンテーション層（ネットワーク層）、ビジネスロジック層（Ｗｅｂアプリケーション層）、データアクセス層（データベース層）の３層に分離した、３層アーキテクチャとして把握することができる（図３（Ａ））。後述するロードバランサは、上記３層アーキテクチャのネットワーク層にて稼働し、前述のインスタンスはＷｅｂアプリケーション層にて稼働し、前述のデータベースはデータベース層にて稼働する（図２及び図３（Ａ））。
尚、図２へ示す各層は、後述するＯＳＩ参照モデルの層（レイヤー）を指すものではない。
図３（Ａ）へ示す通り、本システムＳは階層構造（多層アーキテクチャ）をなしている。
一般にＷｅｂアプリケーションは、Ｗｅｂサーバ、アプリケーションサーバ、ＤＢ（データベース）サーバの３種のサーバにて構成される。
上記３種のサーバのうち、上記アプリケーションサーバで稼働しているプログラムの内部構造について、この例では、プレゼンテーション層（ネットワーク層）、ビジネスロジック層（Ｗｅｂアプリケーション層）、データアクセス層（データベース層）の３層に分離した、３層アーキテクチャとして把握することができる（図３（Ａ））。後述するロードバランサは、上記３層アーキテクチャのネットワーク層にて稼働し、前述のインスタンスはＷｅｂアプリケーション層にて稼働し、前述のデータベースはデータベース層にて稼働する（図２及び図３（Ａ））。
尚、図２へ示す各層は、後述するＯＳＩ参照モデルの層（レイヤー）を指すものではない。
一方、上記電子申請システムＥの中核をなし本システムＳを提供する上記DirectHR（DirectHR Core System）は、ユーザーインタフェースをもつアプリケーションソフトウェアを実装するためのデザインパターンとしてMVC（Model View Controller）を利用し、この例ではハイパーテキストプロセッサ（PHP／汎用スクリプト言語）にて記述されている（図３（Ｂ））。
アプリケーションソフトウェアの内部データ（テーブルｔ，ｔ１，ｔ２）を、ユーザ（端末ＰＣＭ，ＰＣｎの使用者）が直接参照・編集する情報から分離するために上記MVCでは、アプリケーションソフトウェア（プログラム）を３つの要素、Model（モデル）、View（ビュー）、Controller（コントローラ）に分割する。
アプリケーションソフトウェアの内部データ（テーブルｔ，ｔ１，ｔ２）を、ユーザ（端末ＰＣＭ，ＰＣｎの使用者）が直接参照・編集する情報から分離するために上記MVCでは、アプリケーションソフトウェア（プログラム）を３つの要素、Model（モデル）、View（ビュー）、Controller（コントローラ）に分割する。
上記のModel（モデル）については、アプリケーションデータ、ビジネスルール、ロジック、関数など、そのアプリケーションが扱う領域のデータと手続きを表現する要素である。また、データの変更をビューに通知するのもモデルが負う。
上記のView（ビュー）については、グラフや図など、モデルのデータを取り出してユーザが見るのに適した形で表示する要素である。即ち、ビューはUI（ユーザインターフェース）への出力を担当する。上記Viewは、ウェブアプリケーションではHTML文書を生成して動的にデータを表示するための主としてコードにあたる。上記Viewは、GUI（graphical user interface）において通常、階層構造をなす。この例では、Viewは、主として個別表示部８や管理用表示部９の機能を担う。
上記のView（ビュー）については、グラフや図など、モデルのデータを取り出してユーザが見るのに適した形で表示する要素である。即ち、ビューはUI（ユーザインターフェース）への出力を担当する。上記Viewは、ウェブアプリケーションではHTML文書を生成して動的にデータを表示するための主としてコードにあたる。上記Viewは、GUI（graphical user interface）において通常、階層構造をなす。この例では、Viewは、主として個別表示部８や管理用表示部９の機能を担う。
上記のController（コントローラ）については、入力を受け取りmodelとviewへの命令に変換する。コントローラは、ユーザからの入力（通常イベントとして通知される）をモデルへのメッセージへと変換してモデルに伝える要素である。即ち、UIからの入力を担当する。モデルに変更を引き起こす場合もあるが、モデルの内部データを直接操作したりはしない。ユーザ（端末ＰＣＭ，ＰＣｎ）とモデルの構成要素との対話のために各々の構成要素にもビュー・コントローラを持たせる拡張MVCの構成を採る。
テンプレートエンジンとしてPHPテンプレートエンジンを用いることができる。電子申請システムＥの中核をなす上記DirectHRはプラグイン(plugin)として機能を拡張する拡張モジュールを追加することができる。
前述のインスタンスは、ひな形（抽象データ型）であるクラス（Class）を基に作成したオブジェクトである（図２及び図３（Ｂ））。
この例では、上記Controllerが主としてシステム制御部１の機能を担い、上記Viewが主として個別表示部８や管理用表示部９の機能を担い、上記modelが主として管理テーブル収容部３（テーブルｔ，ｔ１，ｔ２）やキー生成部４、暗号生成部５、復号部６を担う。
テンプレートエンジンとしてPHPテンプレートエンジンを用いることができる。電子申請システムＥの中核をなす上記DirectHRはプラグイン(plugin)として機能を拡張する拡張モジュールを追加することができる。
前述のインスタンスは、ひな形（抽象データ型）であるクラス（Class）を基に作成したオブジェクトである（図２及び図３（Ｂ））。
この例では、上記Controllerが主としてシステム制御部１の機能を担い、上記Viewが主として個別表示部８や管理用表示部９の機能を担い、上記modelが主として管理テーブル収容部３（テーブルｔ，ｔ１，ｔ２）やキー生成部４、暗号生成部５、復号部６を担う。
尚、本発明において、採用するデザインパターンとしてMVCに限定するものではなく、他のデザインパターンを採用することができるし、既存のデザインパターンを使用しないものとすることもできる。
また、本システムＳにおいて、上記申請関連データのファイルｆの保管時に当該データファイルｆを暗号化することができる。
システム制御部１の機能の一部として、管理テーブル収容部３へ収容されるテーブルｔ，ｔ１，ｔ２の構築に用いるリレーショナルデータベースマネージメントシステム（RDBMS）には、Amazon Linux（登録商標）上で動作するMySQL（登録商標:https://www.mysql.com/jp/）を採用したが、周知の他のリレーショナルデータベースマネージメントシステムをすることも可能である。
また、各端末ＰＣＭ，ＰＣｎのブラウザに表示するＨＴＭＬのｗｅｂサーバソフトウエアにはApache（登録商標）を採用した。
また、本システムＳにおいて、上記申請関連データのファイルｆの保管時に当該データファイルｆを暗号化することができる。
システム制御部１の機能の一部として、管理テーブル収容部３へ収容されるテーブルｔ，ｔ１，ｔ２の構築に用いるリレーショナルデータベースマネージメントシステム（RDBMS）には、Amazon Linux（登録商標）上で動作するMySQL（登録商標:https://www.mysql.com/jp/）を採用したが、周知の他のリレーショナルデータベースマネージメントシステムをすることも可能である。
また、各端末ＰＣＭ，ＰＣｎのブラウザに表示するＨＴＭＬのｗｅｂサーバソフトウエアにはApache（登録商標）を採用した。
本システムＳは、ロードバランサー（負荷分散装置）を有するクラウドサービスのサーバの上で、複数の当該インスタンスを起動することで運用するのに好適なシステムである。従って、本システムＳは、ロードバランサーとして上記Amazon EC2のエラステックロードバランサーを利用するのに適する。
また、この例では、本システムＳはAmazon Linux（登録商標）を上記ＯＳとして採用（し、Amazon Linux（登録商標）の仮想マシンを構築）するが、他のＯＳを採用して実施してもよい。例えば他のディストリビューションのLinux（登録商標）を採用してもよいし、UNIX（登録商標）系のLinux（登録商標）以外の他のＯＳを採用してもよい。上記ＯＳとして、例えばWindows（登録商標）、macOS(登録商標)を採用してもよい。
また、この例では、本システムＳはAmazon Linux（登録商標）を上記ＯＳとして採用（し、Amazon Linux（登録商標）の仮想マシンを構築）するが、他のＯＳを採用して実施してもよい。例えば他のディストリビューションのLinux（登録商標）を採用してもよいし、UNIX（登録商標）系のLinux（登録商標）以外の他のＯＳを採用してもよい。上記ＯＳとして、例えばWindows（登録商標）、macOS(登録商標)を採用してもよい。
Amazon によれば、Elastic Load Balancing（エラステイク・ロードバランサー）では、単一のアベイラビリティーゾーン（物理的、ソフトウェア的に自律しているデータセンターの集合の単位）または複数のアベイラビリティーゾーンにある複数のターゲット(Amazon EC2 インスタンス、コンテナ、IPアドレスなど)にトラフィックを自動的に分散させる。また、Amazonによれば、エラステイク・ロードバランサーは、ＯＳＩ参照モデルの第４層（レイヤー４／トランスポート層）又は第７層（レイヤー７／アプリケーショ層）の負荷分散を行う。エラステイク・ロードバランサーの固有の機能として、上記第７層においてHTTP/HTTPS アプリケーションの負荷分散が可能である。TCP及びUDPプロトコルに依存するアプリケーションには、厳密なレイヤー４の負荷分散を使用できる。
尚、前述の通り、Amazon Web Services以外の既存のｗｅｂサービスを利用し、或いは全体をオンプレミスなシステムとして、本システムＳを構築するものであってもよい。
尚、前述の通り、Amazon Web Services以外の既存のｗｅｂサービスを利用し、或いは全体をオンプレミスなシステムとして、本システムＳを構築するものであってもよい。
（データの流れ）
図１において白抜きの矢印は、電子申請システムＥによるネットワークＮを介した管理者のオペレータの端末ＰＣＭと手続先Ｇとの間における電子申請のやり取りを示している。また図１において、破線は本発明に係る電子申請補助システムへログインした際の認証に必要なデータの流れを示している。
図１において、一点鎖線は、各端末と上記電子申請補助システムＳの管理テーブル収容部３のテーブルｔとの間のデータの流れを示している。
図１において、二点鎖線は、申請データ収容部２内へファイル別収容部２１を設けた際キー生成部ｋが生成したキーｋの流れを示している。
図１において、実線は、本発明係る電子申請補助システムＳの申請データ収容部２と各端末との間の申請関連データのファイル（申請用データのファイルと発行データのファイル）の流れを示している。
図１において白抜きの矢印は、電子申請システムＥによるネットワークＮを介した管理者のオペレータの端末ＰＣＭと手続先Ｇとの間における電子申請のやり取りを示している。また図１において、破線は本発明に係る電子申請補助システムへログインした際の認証に必要なデータの流れを示している。
図１において、一点鎖線は、各端末と上記電子申請補助システムＳの管理テーブル収容部３のテーブルｔとの間のデータの流れを示している。
図１において、二点鎖線は、申請データ収容部２内へファイル別収容部２１を設けた際キー生成部ｋが生成したキーｋの流れを示している。
図１において、実線は、本発明係る電子申請補助システムＳの申請データ収容部２と各端末との間の申請関連データのファイル（申請用データのファイルと発行データのファイル）の流れを示している。
（本システムＳの運用）
ここでは先ず被管理者（管理者である会社の従業員）が電子申請の手続に必要なデータのファイル（データファイルｆ）をアップロードする際の手順について説明する（図１）。
被管理者は、自己の端末から、本システムＳのウェブサイトへアクセスしてログイン画面表示部１０の提供するステップＳ１０１のログイン画面にて、ステップＳ１０２によりこの例では被管理者のメールアドレスを入力する（図５）。更に上記ログイン画面は、ステップＳ１０３にて被管理者のパスワードの入力を受け付ける。上記にて入力されたメールアドレスとパスワードのデータは、システム制御部１にて一時的に認証データ仮収容部１１へ収容される。
ここでは先ず被管理者（管理者である会社の従業員）が電子申請の手続に必要なデータのファイル（データファイルｆ）をアップロードする際の手順について説明する（図１）。
被管理者は、自己の端末から、本システムＳのウェブサイトへアクセスしてログイン画面表示部１０の提供するステップＳ１０１のログイン画面にて、ステップＳ１０２によりこの例では被管理者のメールアドレスを入力する（図５）。更に上記ログイン画面は、ステップＳ１０３にて被管理者のパスワードの入力を受け付ける。上記にて入力されたメールアドレスとパスワードのデータは、システム制御部１にて一時的に認証データ仮収容部１１へ収容される。
アクセス制御部７は、先ずステップＳ１０４にて管理テーブル収容部３の管理者認証テーブルｔ１を参照する。そしてステップＳ１０５において、アクセス制御部７は、上記参照した管理者認証テーブルｔ１に収容されている管理者のメールアドレス及び管理者のパスワードと、上記ステップＳ１０２乃至ステップＳ１０３の被管理者の入力により認証データ仮収容部１１へ収容された上記のメールアドレス及びパスワードを比較して、一致する否か判断する。
上記ステップＳ１０５において、アクセス制御部７が、管理者認証テーブルＳ１０４へ収容されている管理者のメールアドレス及びパスワードと、上記ステップＳ１０２及びステップＳ１０３にて受け付けた（認証データ仮収容部１１へ収容された）パスワードとメールアドレスが一致しないと判断することにより、ステップＳ１０７へ移行し、アクセス制御部７は、被管理者認証テーブルｔ２と認証データ仮収容部１１とを参照して、識別番号が付与されている被管理者のメールアドレス及びパスワードを順次、上記ステップＳ１０２乃至ステップＳ１０３にて入力されたメールアドレス及びパスワードと比較してゆき（ステップＳ１０８～Ｓ１１３）、一致するメールアドレス及びパスワードが収容されている被管理者認証テーブルｔ２の被管理者の識別子を特定する。
該当する被管理者の識別子が検出されなかった場合、システム制御部１は再びステップＳ１０１に戻り、ステップＳ１０２及びステップＳ１０３にて、メールアドレス又はパスワードの訂正、或いはメールアドレスとパスワードの再度の入力を求める。
本発明に係る電子申請補助システムにおいて、所定回数、メールアドレスとパスワードの入力を繰り返すと、当該端末からログイン不能とすればよい。ログイン不能とする方法としては、ブラックリストとなるテーブルの収容部を設けるものとし（図示しない）、アクセスしてきた端末のＩＰアドレス或いは当該端末のＭＡＣアドレスのデータを収容するブラックリストのテーブルを、上記収容部内のテーブルに追加するようにすればよい。勿論、ホワイトリストを用いて、リストアップされている管理者及び各被管理者以外のログインを遮断するようにしてもよい。
システム制御部１は、ステップＳ２００において、上記にて特定した被管理者の操作画面を個別表示部８にて被管理者の端末へ表示させる（図６、図１７）。
ここでは、システム制御部１は、アクセス制御部７によりステップＳ１０８にて識別子No.0001の被管理者を該当する判定したものとし（図５）、当該被管理者の端末ＰＣ１へ上記操作画面を表示させるものとする（図６、図１７）。
図１７では上記被管理者の端末に表示された画面において「ファイルダウンロード」「ファイルのアップロード」「ファイルの削除」と横並びに表示されたタブ（機能選択タブ）のうち「ファイルのダウンロード」にカーソルが置かれ当該「ファイルのダウンロード」の表示が暗色に反転して表示された状態となっている。
ここでは、システム制御部１は、アクセス制御部７によりステップＳ１０８にて識別子No.0001の被管理者を該当する判定したものとし（図５）、当該被管理者の端末ＰＣ１へ上記操作画面を表示させるものとする（図６、図１７）。
図１７では上記被管理者の端末に表示された画面において「ファイルダウンロード」「ファイルのアップロード」「ファイルの削除」と横並びに表示されたタブ（機能選択タブ）のうち「ファイルのダウンロード」にカーソルが置かれ当該「ファイルのダウンロード」の表示が暗色に反転して表示された状態となっている。
本システムＳへのアクセスを許可された上記被管理者は、次のステップＳ２０１において、ステップＳ２００により端末ＰＣ１へ表示された操作画面から本システムＳに実行させる機能を選択する（図６、図１９）。
上記ステップＳ２０１にて、ファイルのアップロードの選択を受け付けたシステム制御部１は、ステップＳ２１１において、当該被管理者の端末ＰＣ１内のアップロードするファイルの指定を上記操作画面にて当該被管理者へ求める（図６、図２０及び図２１）。
上記ステップＳ２０１にて、ファイルのアップロードの選択を受け付けたシステム制御部１は、ステップＳ２１１において、当該被管理者の端末ＰＣ１内のアップロードするファイルの指定を上記操作画面にて当該被管理者へ求める（図６、図２０及び図２１）。
上記ステップＳ２０１を示す図１９では、横並びの上記３つのタブのうち「ファイルのアップロード」タブにカーソルが置かれて当該タブが暗色に反転している。この「ファイルのアップロード」タブの選択状態において、図２０へ示す通り、被管理者は使用する上記端末ＰＣ１内に置かれたデータファイル（図２０中プルダウンメニューに表示された一連の書類）の中からアップロードするデータファイルを選択する。
ステップＳ２１１にて、被管理者の端末ＰＣ１からアップロードする上記ファイルの指定を受け付けたシステム制御部１は、ステップＳ２１２にて管理テーブル収容部３へ、当該被管理者の識別子No.0001を収容するテーブルを設け、当該識別子を収容する。
具体的には、システム制御部１は、被管理者認証テーブルｔ２を参照し、上記にてアクセス制御部７にてアクセスを許可した被管理者の識別子を取得し、上記にて管理テーブル収容部３へ設けたテーブルへ当該識別子を収容するのである。
具体的には、システム制御部１は、被管理者認証テーブルｔ２を参照し、上記にてアクセス制御部７にてアクセスを許可した被管理者の識別子を取得し、上記にて管理テーブル収容部３へ設けたテーブルへ当該識別子を収容するのである。
次のステップＳ２１３において、暗号生成部５は、アップロードする上記データファイルｆのファイル名のデータを暗号化し識別子No.0001を収容する上記テーブルに収容する。
またステップＳ２１４において、暗号生成部５は、識別子No.0001を収容する上記テーブルへ、アップロードする当該データファイルｆの上記端末ＰＣ１中の所在を示すファイルパスを暗号化し収容する。
またステップＳ２１４において、暗号生成部５は、識別子No.0001を収容する上記テーブルへ、アップロードする当該データファイルｆの上記端末ＰＣ１中の所在を示すファイルパスを暗号化し収容する。
更にステップＳ２１５において、暗号生成部５は、当該被管理者の名前（氏名）を暗号化し、識別子No.0001を収容する上記テーブルへ収容する。
尚上記のステップＳ２１３～ステップＳ２１５の各ステップは、上記した順序で処理されることに限定するものではなく、上記と異なる順序で或いは同時に処理されるものとしても実施できる。
ステップＳ２１６において、キー生成部４は、ステップＳ２１３～Ｓ２１５にて暗号化された、上記ファイル名のデータと上記ファイルパスのデータと上記被管理者の名前（被管理者名）のデータを纏めて更に暗号化することにより、キーｋを生成する。
尚上記のステップＳ２１３～ステップＳ２１５の各ステップは、上記した順序で処理されることに限定するものではなく、上記と異なる順序で或いは同時に処理されるものとしても実施できる。
ステップＳ２１６において、キー生成部４は、ステップＳ２１３～Ｓ２１５にて暗号化された、上記ファイル名のデータと上記ファイルパスのデータと上記被管理者の名前（被管理者名）のデータを纏めて更に暗号化することにより、キーｋを生成する。
ステップＳ２１７において、暗号生成部５は、アップロードする上記データファイルｆを暗号化し、申請データ収容部２へファイル別収容部２１を設けて暗号化した当該ファイルｆを収容すると共に、システム制御部１は当該ファイル別収容部２１へ上記にて生成したキーｋを付与する。
上記のキーｋを付与するというのは、この例では、ファイル別収容部２１であるS3バケットのバケット名をキーｋ（データ）として、当該バケットへ暗号化した上記データファイルｆを収容するとういうことである。
上記のキーｋを付与するというのは、この例では、ファイル別収容部２１であるS3バケットのバケット名をキーｋ（データ）として、当該バケットへ暗号化した上記データファイルｆを収容するとういうことである。
次に管理者が上記にてアップロードされたデータファイルｆをダウンロードする手順について説明する。
管理者のオペレータは、管理者の端末ＰＣＭからの操作にて、被管理者（従業員）と同様上記ステップＳ１０１～Ｓ１１３のログイン工程を本システムＳに遂行させる（図５）。
管理者のオペレータは、管理者の端末ＰＣＭからの操作にて、被管理者（従業員）と同様上記ステップＳ１０１～Ｓ１１３のログイン工程を本システムＳに遂行させる（図５）。
即ち、管理者のオペレータは、管理者の端末ＰＣＭから、本システムＳのウェブサイトへアクセスしてログイン画面表示部１０の提供する、ステップＳ１０１のログイン画面にて、ステップＳ１０２によりこの例では管理者のオペレータのメールアドレスを入力する（図５）。更に上記ログイン画面にて上記オペレータによるステップＳ１０３にて管理者のパスワードの入力を受け付け、認証データ仮収容部１１へ一時的に収容する。アクセス制御部７は、先ずステップＳ１０４にて管理テーブル収容部３の管理者認証テーブルｔ１を参照する。ステップＳ１０５においてアクセス制御部７は、上記参照した管理者認証テーブルｔ１に収容されている管理者のメールアドレス及び管理者のパスワードと、上記ステップＳ１０１のログイン画面で上記ステップＳ１０２乃至ステップＳ１０３にて認証データ仮収容部１１の被管理者から受け付けた上記のメールアドレス及びパスワードを、比較して一致する否か判断する。
上記ステップＳ１０５にて、アクセス制御部７が、管理者認証テーブルｔ１に収容されている管理者のメールアドレスと管理者のパスワードが認証データ仮収容部１１へ収容されているメールアドレスとパスワードと一致すると判断することにより、ステップＳ１０６にて管理者の識別子を取得したシステム制御部１は、制御をステップＳ３００へ移行させ、管理者のオペレータの端末ＰＣＭへ、管理用表示部９により操作画面を表示させる（図７、図８）。
ステップＳ３０１にて、上記オペレータにより上記操作画面からデータファイルのダウンロードの機能が選択されると、ステップＳ３１１にて、管理用表示部９は、ダウンロードするデータファイルｆの被管理者名の一覧を上記操作画面へ表示する（図７、図９）。ステップＳ３１２にて、被管理者名の上記一覧から、該当する被管理者を選択する（図７、図１０）。当該選択により、ステップＳ３１３にて、該当する被管理者の管理テーブル収容部３内のテーブルｔの保持するデータのうち端末ＰＣＭに表示するファイル名のデータが復号部６に復号される。そして仮収容部１２へ上記にて復号された上記ファイル名のデータ（平文データ）と当該ファイル名の暗号化されたデータの対が一時的に収容される。ステップＳ３１４にて、仮収容部１２内の当該データ（平文データ）が上記操作画面に表示される。
上記ステップＳ３１４において上記操作画面へ表示されたファイル名の一覧から、次のステップＳ３１５にて、上記オペレータからダウンロードするファイル（ファイル名）の指定を受け付ける（図７、図１４）。
ステップＳ３１５において、図１４へ示す通り上記被管理者のオペレータの端末ＰＣＭには、被管理者の上記端末ＰＣ１と同様の３つのタブ（機能選択タブ）が表示される。図１４では、「ファイルのダウンロード」タブが選択され、当該タブの直下に表示されているボックス（被管理者選択欄）には、既に被管理者の一覧から被管理者（従業員）である「意匠 大作」が選択されその氏名が表示された状態となっている。
ステップＳ３１５において、図１４へ示す通り上記被管理者のオペレータの端末ＰＣＭには、被管理者の上記端末ＰＣ１と同様の３つのタブ（機能選択タブ）が表示される。図１４では、「ファイルのダウンロード」タブが選択され、当該タブの直下に表示されているボックス（被管理者選択欄）には、既に被管理者の一覧から被管理者（従業員）である「意匠 大作」が選択されその氏名が表示された状態となっている。
図１４へ示す通り、上記被管理者選択欄であるボックスの直下に、更に別途のボックス（データファイル選択欄）が配置されている。図１４では、当該データファイル選択欄において、既に当該端末ＰＣ１内にあるダウンロードするデータファイルｔ（driverslicense.png「本人映像１」）が選択された状態となっている（データファイル選択欄であるボックス内に表示されている）。
ステップＳ３１６において、システム制御部１は、管理テーブル収容部３を検索し、上記オペレータにて指定されたファイル名と対をなす暗号化されたファイル名のデータと一致するファイル名のデータ（暗号文）を収容するテーブルｔを検出する。そしてシステム制御部１は、検出したテーブルｔに収容されている暗号化された、ファイル名のデータと当該ファイルのファイルパスのデータとファイルの所有者（被管理者）の氏名のデ―タから、キー生成部４へ上記ステップＳ２１６と同様の方法でキーｋを生成させ、生成したキーｋをキー仮収容部４０へ一時的に収容する。
ステップＳ３１７においてシステム制御部１は申請データ収容部２内を検索する。ステップＳ３１８にてキー仮収容部４０へ収容されたキーｋが付されたファイル別収容部２１を検出すると、システム制御部１は、ステップＳ３１９にて上記にて検出したファイル別収容部２１へ収容されているファイルｆを管理者のオペレータの端末ＰＣＭへダウンロードする。
上記にてダウンロードされたデータファイルｆに対応するテーブルｔには、ダウンロード済であることを示すフラグを立てるものとすればよい。
上記にてダウンロードされたデータファイルｆに対応するテーブルｔには、ダウンロード済であることを示すフラグを立てるものとすればよい。
管理者のオペレータは、ステップＳ３１９にてオペレータの端末ＰＣＭへダウンロードしたデータファイルｆを基に、電子申請システムＥにて申請用のデータファイルを作成し手続先Ｇ即ち電子政府へ電子申請を行う。
ここでは、管理者のオペレータは、自社の複数の社員（被管理者）について電子政府に対し前述の一括申請を行ったものとする。
上記一括申請の結果、手続先Ｇである電子政府は、申請手続に対する応答として発行データのデータファイルを、ネットワークＮを通じ一括して管理者のオペレータの端末へ送信する。
ここでは、管理者のオペレータは、自社の複数の社員（被管理者）について電子政府に対し前述の一括申請を行ったものとする。
上記一括申請の結果、手続先Ｇである電子政府は、申請手続に対する応答として発行データのデータファイルを、ネットワークＮを通じ一括して管理者のオペレータの端末へ送信する。
ここで手続先Ｇである電子政府（e-Gov）への電子申請（一括申請）手続の流れについて簡単に触れる。
（ステップ1）申請データの作成
管理者のオペレータ（申請者）は上記電子申請システムＥを用いて申請データを作成する。
（ステップ2）申請書類の指定（図２４～図２７）
管理者のオペレータ（申請者）はログイン後、端末ＰＣＭに表示された「送信案件一覧」の画面において、上記にて作成済の申請する書類（データファイルｆ）を「選択」する。
（ステップ3）申請データの送信
端末ＰＣＭに表示された「送信案件一覧」の画面において、「申請」ボタンをクリックする。当該クリックにて、上記ステップ２にて選択された複数の申請データのファイルは、電子申請システムＥによってＺＩＰ形式に圧縮され、電子政府へ送信される。
（ステップ1）申請データの作成
管理者のオペレータ（申請者）は上記電子申請システムＥを用いて申請データを作成する。
（ステップ2）申請書類の指定（図２４～図２７）
管理者のオペレータ（申請者）はログイン後、端末ＰＣＭに表示された「送信案件一覧」の画面において、上記にて作成済の申請する書類（データファイルｆ）を「選択」する。
（ステップ3）申請データの送信
端末ＰＣＭに表示された「送信案件一覧」の画面において、「申請」ボタンをクリックする。当該クリックにて、上記ステップ２にて選択された複数の申請データのファイルは、電子申請システムＥによってＺＩＰ形式に圧縮され、電子政府へ送信される。
（ステップ4）電子政府への申請データ到達・完了通知メールの受信
電子政府において、形式チェック処理が実行され、受信した各申請データの検証を行なったうえで、申請書を到達として扱う。
電子政府は、形式チェックの完了をメールにて管理者（申請者）に通知する。
（ステップ5）端末ＰＣＭにおける案件ごとの状況を確認
管理者（申請者）は、完了通知のメールを受け取った後、送信案件ごとに各申請の状況を確認することができる。
管理者（申請者）の端末ＰＣＭからの操作即ち「状況照会」のクリックにより（図２４及び図２５）、各申請案件の処理状況を当該端末ＰＣＭへ表示させることができる。
上記の状況照会の操作により「公文書」の発行が表示された案件について、端末ＰＣＭの画面からダウンロードを指定して上記端末ＰＣＭへ圧縮された電子公文書をダウンロードすることができる。
ここでは、電子政府から発行データのファイルを一括受領するものとする。
電子政府において、形式チェック処理が実行され、受信した各申請データの検証を行なったうえで、申請書を到達として扱う。
電子政府は、形式チェックの完了をメールにて管理者（申請者）に通知する。
（ステップ5）端末ＰＣＭにおける案件ごとの状況を確認
管理者（申請者）は、完了通知のメールを受け取った後、送信案件ごとに各申請の状況を確認することができる。
管理者（申請者）の端末ＰＣＭからの操作即ち「状況照会」のクリックにより（図２４及び図２５）、各申請案件の処理状況を当該端末ＰＣＭへ表示させることができる。
上記の状況照会の操作により「公文書」の発行が表示された案件について、端末ＰＣＭの画面からダウンロードを指定して上記端末ＰＣＭへ圧縮された電子公文書をダウンロードすることができる。
ここでは、電子政府から発行データのファイルを一括受領するものとする。
次に、電信政府から受領した発行データのデータファイルｆの展開と配布について説明する。
管理者(会社)のオペレータは、その端末ＰＣＭの操作にて、DirectHRの「送信案件一覧」（画面）からダウンロードした圧縮ファイル(ZIP形式)を展開して、従業員に配布するファイル(ＰＤＦ形式／Portable Document Format)を抽出してmyboxにアップロードする（図２４，図２６及び図２７）。
上記のＰＤＦファイル（ＰＤＦ形式のファイル）は、公共職業安定所が発行する通知書や証明書などのデータファイルとして用いられ、手続によっては事業主通知用、被保険者通知用のデータファイルに採用される。
公文書である上記ＰＤＦファイルについて、ファイル名は「到達番号＋連番＋帳票名.pdf 」とされる。
管理者(会社)のオペレータは、その端末ＰＣＭの操作にて、DirectHRの「送信案件一覧」（画面）からダウンロードした圧縮ファイル(ZIP形式)を展開して、従業員に配布するファイル(ＰＤＦ形式／Portable Document Format)を抽出してmyboxにアップロードする（図２４，図２６及び図２７）。
上記のＰＤＦファイル（ＰＤＦ形式のファイル）は、公共職業安定所が発行する通知書や証明書などのデータファイルとして用いられ、手続によっては事業主通知用、被保険者通知用のデータファイルに採用される。
公文書である上記ＰＤＦファイルについて、ファイル名は「到達番号＋連番＋帳票名.pdf 」とされる。
またＰＤＦファイル以外に、ＸＭＬファイルが電子政府の発行データのデータファイルｆとして用いられる。ＸＭＬファイルは、公共職業安定所の電子署名が付与されており、電子政府（e-Gov）の署名検証機能によって、電子公文書が改竄されていないか確認することができる。公文書である上記ＸＭＬファイルについて、ファイル名は「到達番号.XML」とされる。
また、上記のＰＤＦやＸＭＬ以外に、公文書のデータファイルとして、ＸＳＬファイルが用いられる。このＸＳＬファイルは、鑑文書を表示するためのファイルとして採用されるＸＳＬファイルについて、ファイル名は、「STYLESHEET1.XSL」とされる。
また、上記のＰＤＦやＸＭＬ以外に、公文書のデータファイルとして、ＸＳＬファイルが用いられる。このＸＳＬファイルは、鑑文書を表示するためのファイルとして採用されるＸＳＬファイルについて、ファイル名は、「STYLESHEET1.XSL」とされる。
上記オペレータは、当該発行データのファイルを、上記オペレータの端末ＰＣＭから、本システムＳへアップロードする。
次に管理者のオペレータによる各発行データの上記アップロードの手順について説明する。
次に管理者のオペレータによる各発行データの上記アップロードの手順について説明する。
上記オペレータは、端末ＰＣＭから上記ステップＳ１０１～Ｓ１０６を経て（図５）、ステップＳ３００の操作画面からステップＳ３０１にて、データファイルのアップロードの機能を選択する（図７、図１１）。
次にステップＳ３２１にて、システム制御部１は、管理用表示部９により上記操作画面にて、被管理者の指定の入力を受け付ける。即ち、管理用表示部９は、上記操作画面にて被管理者の入力を求め、管理者のオペレータの操作にて、被管理者の一覧を上記操作画面へ表示する。更にステップＳ３２２にて、上記オペレータの被管理者の指定を受け付ける（図７、図１２）。
次にステップＳ３２１にて、システム制御部１は、管理用表示部９により上記操作画面にて、被管理者の指定の入力を受け付ける。即ち、管理用表示部９は、上記操作画面にて被管理者の入力を求め、管理者のオペレータの操作にて、被管理者の一覧を上記操作画面へ表示する。更にステップＳ３２２にて、上記オペレータの被管理者の指定を受け付ける（図７、図１２）。
図１２へ示す通り、オペレータの端末ＰＣＭにおいて、本システムＳは、管理用表示部９の表示する画面により、被管理者のアップロードするデータファイルｆの指定を促す。
尚、図４（Ａ）（Ｂ）は本発明に係る電子申請補助システムＳの運用に必要な最小の項目（被管理者の識別子と要素データ）のみテーブルｔへ設けられる項目として示すものであり、本システムＳを含む電子申請システムＥの運用のため、図４（Ａ）（Ｂ）には示されていない、管理者の端末ＰＣＭにおける図２４～図２７に示す送信案件一覧は当該テーブルｔへ含まれる。但し、図４（Ａ）（Ｂ）に示されていない項目については、当該テーブルｔに被管理者の識別子にて紐づけられた他のテーブルを設けて、当該のテーブルへ収容するものとしても実施できる。
尚、図２６及び図２７において、送信案件一覧中、太線で囲んだ「公文書取得」欄（セル）にテーブルｔへ収容された前述の発行データのデータファイルのダウンロードリンクが表示される（図２６及び図２７では図面の煩雑を避けるため空欄としている）。管理者のオペレータは、当該リンクを操作（クリック）することによって、発行データのデータファイルｆを当該オペレータの端末ＰＣＭへダウンロードすることができる。
尚、図４（Ａ）（Ｂ）は本発明に係る電子申請補助システムＳの運用に必要な最小の項目（被管理者の識別子と要素データ）のみテーブルｔへ設けられる項目として示すものであり、本システムＳを含む電子申請システムＥの運用のため、図４（Ａ）（Ｂ）には示されていない、管理者の端末ＰＣＭにおける図２４～図２７に示す送信案件一覧は当該テーブルｔへ含まれる。但し、図４（Ａ）（Ｂ）に示されていない項目については、当該テーブルｔに被管理者の識別子にて紐づけられた他のテーブルを設けて、当該のテーブルへ収容するものとしても実施できる。
尚、図２６及び図２７において、送信案件一覧中、太線で囲んだ「公文書取得」欄（セル）にテーブルｔへ収容された前述の発行データのデータファイルのダウンロードリンクが表示される（図２６及び図２７では図面の煩雑を避けるため空欄としている）。管理者のオペレータは、当該リンクを操作（クリック）することによって、発行データのデータファイルｆを当該オペレータの端末ＰＣＭへダウンロードすることができる。
次にステップＳ３２３にて、システム制御部１は、上記操作画面にて、管理者の上記オペレータの端末ＰＣＭにあるアップロードしようとするデータファイルの上記オペレータによる指定を受け付ける（図７、図１３）。当該指定を受け付けるとシステム制御部１は、ステップＳ３２４にて管理テーブル収容部３へテーブルｔを追加し、追加したテーブルｔへアップロードしようとするデータファイルｆの被管理者の識別子を収容する（図７）。ステップＳ３２５において、システム制御部１は、暗号生成部５に、アップロードしようとする上記データファイルｆのファイル名を暗号化させ、上記テーブルｔに収容させる。
更にステップＳ３２６において、システム制御部１は、暗号生成部５に、アップロードしようする上記データファイルｆの手続先Ｇからのダウンロードリンクのデータを暗号化させて、アップロードしようとするデータファイルｆの被管理者の識別子のデータを収容するテーブルｔへ収容させる。
更に、ステップＳ３２７において、シスムテ制御部１は、暗号生成部５へ被管理者の氏名のデータを暗号化させて、アップロードしようとするデータファイルｆの被管理者の識別子のデータを収容する上記テーブルｔへ収容させる。
更に、ステップＳ３２７において、シスムテ制御部１は、暗号生成部５へ被管理者の氏名のデータを暗号化させて、アップロードしようとするデータファイルｆの被管理者の識別子のデータを収容する上記テーブルｔへ収容させる。
ステップＳ３２８において、キー生成部４は、ステップＳ３２５～Ｓ３２７にて暗号化された、上記ファイル名のデータと上記ファイルのダウンロードリンクのデータと上記被管理者の名前（被管理者名）のデータを纏めて更に暗号化することにより、キーｋを生成する。
ステップＳ３２９において、暗号生成部５は、アップロードする上記データファイルｆを暗号化し、申請データ収容部２へファイル別収容部２１を設けて暗号化した当該ファイルｆを収容すると共に、システム制御部１は当該ファイル別収容部２１へ上記にて生成したキーｋを付与する。
ステップＳ３２９において、暗号生成部５は、アップロードする上記データファイルｆを暗号化し、申請データ収容部２へファイル別収容部２１を設けて暗号化した当該ファイルｆを収容すると共に、システム制御部１は当該ファイル別収容部２１へ上記にて生成したキーｋを付与する。
次に管理者のオペレータにてアップロードされた発行データを、被管理者がダウンロードする手順について説明する。
被管理者は、被管理者の端末ＰＣ１からの操作にて、ファイルをアップロードする際と同様上記ステップＳ１０１～Ｓ１１３のログイン工程を本システムＳに遂行させる（図５）。
上記ステップＳ１０７からＳ１１３までの処理の遂行にて、アクセス制御部７が被管理者認証テーブルｔ２の中からステップＳ１０１～Ｓ１０３にて入力され認証データ仮収容部１１へ収容されたメールアドレス及びパスワードと、一致するメールアドレス及び被管理者のパスワードを収容しているものを検出することにより、当該被管理者の識別子を取得し当該被管理者の本システムＳへのアクセスを承認する。当該承認によりシステム制御部１は、制御をステップＳ２００へ移行させ、当該被管理者の端末ＰＣ１へ、個別表示部８により操作画面を表示させる（図６）。
被管理者は、被管理者の端末ＰＣ１からの操作にて、ファイルをアップロードする際と同様上記ステップＳ１０１～Ｓ１１３のログイン工程を本システムＳに遂行させる（図５）。
上記ステップＳ１０７からＳ１１３までの処理の遂行にて、アクセス制御部７が被管理者認証テーブルｔ２の中からステップＳ１０１～Ｓ１０３にて入力され認証データ仮収容部１１へ収容されたメールアドレス及びパスワードと、一致するメールアドレス及び被管理者のパスワードを収容しているものを検出することにより、当該被管理者の識別子を取得し当該被管理者の本システムＳへのアクセスを承認する。当該承認によりシステム制御部１は、制御をステップＳ２００へ移行させ、当該被管理者の端末ＰＣ１へ、個別表示部８により操作画面を表示させる（図６）。
ステップＳ２０１にて、上記被管理者により操作画面からデータファイルｆのダウンロードの機能が選択されると（図６、図１８）、ステップＳ２２１にて、個別表示部８は、管理テーブル収容部３を参照し当該被管理者の識別子を収容するテーブルｔ全てを抽出し、復号部６により抽出したテーブルｔ全てに収容されているファイル名のデータを復号させ仮収容部１２へ収容させる（図６）。
ステップＳ２２２にて、システム制御部１は、個別表示部８に仮収容部１２を参照させて上記被管理者のファイル名の一覧を当該被管理者の端末ＰＣ１に表示させる。
ステップＳ２２２にて、システム制御部１は、個別表示部８に仮収容部１２を参照させて上記被管理者のファイル名の一覧を当該被管理者の端末ＰＣ１に表示させる。
ステップＳ２２３において、被管理者の上記端末ＰＣ１にて上記ファイル名の一覧からダウンロードするデータファイルｆのファイル名の指定を受け付けると、システム制御部１は、キー生成部４に管理テーブル収容部３を参照させて指定されたファイル名を収容するテーブルｔから、暗号化されて収容されている上記ファイル名のデータと上記ファイルのダウンロードリンクのデータと上記被管理者の名前（被管理者名）のデータを纏めて更に暗号化することにより、キーｋを生成し、生成したキーｋをキー仮収容部４０へ収容する。
ステップＳ２２５において、システム制御部１は、ステップＳ２２４にて生成されてキー仮収容部４０へ収容されたキーｋを参照し、申請データ収容部２から同じキーｋが付与されているファイル別収容部２１を検索する。
ステップＳ２２６にて、キー仮収容部４０に収容されたキーｋと一致するキーｋが付与されているファイル別収容部２１を検出すると、システム制御部１にて、ステップＳ２２７にて当該被管理者の端末ＰＣ１へ検出したファイル別収容部２１内のデータファイルｆをダウンロードさせることができる。
システム制御部１は、上記にてダウンロードされたデータファイルｆと対応するテーブルｔへダウンロード済を示すフラグを立てるものとすればよい。
ステップＳ２２６にて、キー仮収容部４０に収容されたキーｋと一致するキーｋが付与されているファイル別収容部２１を検出すると、システム制御部１にて、ステップＳ２２７にて当該被管理者の端末ＰＣ１へ検出したファイル別収容部２１内のデータファイルｆをダウンロードさせることができる。
システム制御部１は、上記にてダウンロードされたデータファイルｆと対応するテーブルｔへダウンロード済を示すフラグを立てるものとすればよい。
上記ステップＳ２２１～Ｓ２２７の遂行により、発行データのファイルのダウンロードが完了した被管理者は、再度ステップＳ２０１に戻って、或いは再度本システムへログインした際ステップＳ２０１にて、ファイル削除の機能を選択してシステム制御部１に選択後のステップＳ２３１～Ｓ２３７の各ステップの処理を遂行させる。ステップＳ２３１～Ｓ２３７の遂行にて、管理者のオペレータにより電子申請の手続きの完了している即ち、使用済みとなったアップロード（ステップＳ２１１～Ｓ２１７）されているデータファイルｆのファイル別収容部２１を申請データ収容部２から削除し、同時に当該データファイルｆと対応するテーブルｔを管理テーブル収容部３から削除することができる（図６、図２２及び図２３）。
ファイルを削除するためのステップＳ２３１～Ｓ２３６の工程は、キーｋを生成する要素データの１つが上記のファイルパスのデータか上記のダウンロードリンクのデータであるかの相違を除いて、ファイルをダウンロードするステップＳ２２１～Ｓ２２６の工程と基本的に同じである（図６）。
尚、ステップＳ２３３にて、システム制御部１は、上記ステップＳ３２９の遂行完了により管理者のオペレータ又はシステム制御部１にてフラグを立てられたテーブルｔを指定するものとし、ステップＳ２３７にてシステム制御部１に使用済みのアップロード中のテータファイルｆのファイル別収容部２１を申請データ収容部２から削除させ、当該データファイルｆと対応するテーブルｔを管理テーブル収容部３から削除させる。
尚、ステップＳ２３３にて、システム制御部１は、上記ステップＳ３２９の遂行完了により管理者のオペレータ又はシステム制御部１にてフラグを立てられたテーブルｔを指定するものとし、ステップＳ２３７にてシステム制御部１に使用済みのアップロード中のテータファイルｆのファイル別収容部２１を申請データ収容部２から削除させ、当該データファイルｆと対応するテーブルｔを管理テーブル収容部３から削除させる。
またステップＳ２１１～Ｓ２１７にて被管理者によりアップロードされ、使用済み（電子申請の手続済み）となったテータファイルｆに関するファイル別収容部２１及び対応するテーブルｔの削除は、電子申請の手続を行った管理者のオペレータにより行うものとしてもよい（ステップＳ３３１～３３９）。
管理者のオペレータの本システムＳへのログイン時、ステップＳ３３１～３３９（図７）の処理により、被管理者によるステップＳ２２１～Ｓ２２７の遂行にてダウンロード済となりフラグが立てられたテーブルｔ及び対応するファイル別収容部２１を削除することができる（図７、図１５及び図１６）。
但し、ステップＳ２２１～Ｓ２２７の遂行によりダウンロードを完了させた被管理者により、ダウンロード済となったテーブルｔ及び対応するファイル別収容部２１を削除するものとしてもよい。
但し、ステップＳ２２１～Ｓ２２７の遂行によりダウンロードを完了させた被管理者により、ダウンロード済となったテーブルｔ及び対応するファイル別収容部２１を削除するものとしてもよい。
また、使用済みとなった否かに拘わらず、訂正や手続が不要となった場合を考慮して随時管理者及び被管理者において、上記ステップＳ２０１、Ｓ３０１でファイル削除の機能を選択することにより、アップロード中のデータファイルｆのテーブルｔ及び対応するファイル別収容部２１を削除する処理を遂行することができるものとする。
図示した例では、ログイン時ステップＳ１０２にてパスワードと共にログインした者のメールアドレスの入力を求め、メールアドレスとパスワードを用いてログインする者の認証を行うものとした。この他前述の通り、ログイン時ステップＳ１０２にて上記メールアドレスに代えログインする者のＩＤ（識別子）をバスワードと共に求め、パスワードと当該ＩＤにてログインする者を認証するものとしてもよい。
尚、Amazonにおいて現状でサポートされている、S3バケットのパス形式URLのリクエストが今後廃止されたとしても、当該リソース名に代わるデータを要素データとして、キーｋを生成すればよい。
尚、Amazonにおいて現状でサポートされている、S3バケットのパス形式URLのリクエストが今後廃止されたとしても、当該リソース名に代わるデータを要素データとして、キーｋを生成すればよい。
（付随事項）
本システムＳは、特にIaaSタイプのホスティングとして、前述のAWSやS3に代表される、webサービスとwebストレージの利用に適したものである。
具体的には、本システムＳは、デザインパターンとしてMVCの利用にて構築されるに適したMVC適合部と、上記webストレージにて構築されるに適したストレージサービス適合部とを備える。上記MVC適合部が、少なくとも前述の、システム制御部１と管理テーブル収容部３とキー生成部４と暗号生成部５と復号部６とアクセス制御部７と管理用表示部８と個別表示部９とを備え、上記ストレージサービス適合部が前述の申請データ収容部２を備えるのである。但し、キー生成部４は、更には暗号生成部５と復号部６は、上記ストレージサービス適合部が備えるものとしてもよい。
本システムＳは、所謂LAMP（Linux（登録商標）、Apache、MySQL、PHP）環境を利用して構築することができる。またAWSの利便性を必要としないのであれば、本システムＳを所謂WAMP（Windows、Apache、MySQL、PHP）環境を利用して構築することも可能である。例えば、AWSの他、Microsoft Azure（Microsoft ／登録商標、Azure／ベストライセンス社商標出願中）を利用して本システムＳを構築してもよい。
本システムＳは、特にIaaSタイプのホスティングとして、前述のAWSやS3に代表される、webサービスとwebストレージの利用に適したものである。
具体的には、本システムＳは、デザインパターンとしてMVCの利用にて構築されるに適したMVC適合部と、上記webストレージにて構築されるに適したストレージサービス適合部とを備える。上記MVC適合部が、少なくとも前述の、システム制御部１と管理テーブル収容部３とキー生成部４と暗号生成部５と復号部６とアクセス制御部７と管理用表示部８と個別表示部９とを備え、上記ストレージサービス適合部が前述の申請データ収容部２を備えるのである。但し、キー生成部４は、更には暗号生成部５と復号部６は、上記ストレージサービス適合部が備えるものとしてもよい。
本システムＳは、所謂LAMP（Linux（登録商標）、Apache、MySQL、PHP）環境を利用して構築することができる。またAWSの利便性を必要としないのであれば、本システムＳを所謂WAMP（Windows、Apache、MySQL、PHP）環境を利用して構築することも可能である。例えば、AWSの他、Microsoft Azure（Microsoft ／登録商標、Azure／ベストライセンス社商標出願中）を利用して本システムＳを構築してもよい。
１ システム制御部
２ 申請データ収容部
３ 管理テーブル収容部
４ キー生成部
５ 暗号生成部
６ 復号部
７ アクセス制御部
８ 管理用表示部
９ 個別表示部
１０ ログイン画面表示部
１１ 認証データ仮収容部
１２ 仮収容部
２１ ファイル別収容部
４０ キー仮収容部
Ｅ 電子申請システム
ｆ 申請関連データのファイル
Ｇ 手続先
ｋ キー
Ｎ ネットワーク
ＰＣＭ 管理者（のオペレータ）の端末
ＰＣ１ 被管理者の端末
Ｓ 電子申請補助システム
ｔ テーブル
ｔ１ 管理者認証テーブル
ｔ２ 被管理者認証テーブル
２ 申請データ収容部
３ 管理テーブル収容部
４ キー生成部
５ 暗号生成部
６ 復号部
７ アクセス制御部
８ 管理用表示部
９ 個別表示部
１０ ログイン画面表示部
１１ 認証データ仮収容部
１２ 仮収容部
２１ ファイル別収容部
４０ キー仮収容部
Ｅ 電子申請システム
ｆ 申請関連データのファイル
Ｇ 手続先
ｋ キー
Ｎ ネットワーク
ＰＣＭ 管理者（のオペレータ）の端末
ＰＣ１ 被管理者の端末
Ｓ 電子申請補助システム
ｔ テーブル
ｔ１ 管理者認証テーブル
ｔ２ 被管理者認証テーブル
Claims (10)
- 会社等組織といった管理者のオペレータが、前記管理者に管理される従業者等の複数の被管理者についてコンピュータを用いた申請手続を電子政府等の手続先へオンラインにより行うために、前記被管理者に関するデータのファイルを取得し収容する電子申請補助システムであって、
申請関連データのファイルを収容する申請データ収容部と、管理テーブル収容部と、システム制御部と、キー生成部とを備え、
前記申請関連データのファイルは、前記申請手続に必要な前記被管理者の申請用データのファイルと前記申請手続きの手続き先にて発行された発行データのファイルの少なくとも何れかであり、
前記申請データ収容部は、前記申請関連データのファイルを収容するファイル別収容部を、前記申請関連データのファイル毎に設けられるものであり、
前記ファイル別収容部には識別子となるキーが付与され、前記ファイル別収容部は当該キーのみにて特定されるものであり、
前記管理テーブル収容部には、少なくとも、前記ファイル別収容部へ収容される前記申請関連データのファイルのファイル名のデータと、当該申請関連データのファイルの被管理者の識別子のデータと、前記ファイル別収容部を特定する前記キーを生成する要素となる１つ又は複数の要素データとを備えたレコードを収容する、テーブルを設けることができ且つ、前記テーブルには前記申請関連データのファイル自体を収容しないものであり、
特定の前記申請関連データのファイルへのアクセスの要求があった際、前記システム制御部は、前記管理テーブル収容部の前記テーブルを参照し当該申請関連データのファイルの前記ファイル名のデータを収容するレコードを検出して前記キー生成部に当該レコード中の前記要素データから前記キーを生成させ、生成した当該キーと一致する前記キーが付与された前記ファイル別収容部を検出し、検出した前記ファイル別収容部に収容された前記申請関連のファイルへのアクセスを可能とする電子申請補助システム。
- 暗号生成部と、前記暗号生成部が暗号化したデータを復号化する復号部とを備え、
前記キー生成部は、前記ファイル名のデータを、前記要素データの１つとするものであり、
前記申請関連のファイルの前記ファイル別収容部への収容に際し、前記暗号生成部は、前記ファイル名のデータと他の前記要素データの夫々を暗号化し前記レコードの一部として前記管理テーブル収容部の前記テーブルへ収容するものであり、且つ、前記キー生成部は、前記暗号生成部にて暗号化した前記ファイル名のデータと他の前記要素データとを更に暗号化することで前記キーを生成し、前記申請関連データのファイルの収容時に、収容に用いる前記ファイル別収容部を形成して前記キーを付与するものであり、
特定の前記被管理者の前記申請関連のファイルへのアクセスの要求があった際、前記システム制御部は前記管理テーブル収容部の前記テーブルから当該被管理者の識別子のデータを収容する前記レコードを検出し、前記復号部へ検出した前記レコード中の少なくとも前記ファイル名のデータを復号させ、要求のあったファイル名のデータを有するレコードを特定して、前記キー生成部により特定したレコードの備える、暗号化された前記ファイル名のデータと他の前記要素データとから前記キーを生成し、当該キーと一致する前記キーが付与された前記ファイル別収容部を検出し、当該ファイル別収容部へ収容された前記申請関連のファイルとのアクセスを可能とする請求項１記載の電子申請補助システム。
- アクセス制御部と、管理用表示部と、個別表示部とを備え、
前記アクセス制御部は、前記被管理者の一人の端末から前記申請データ収容部の前記テーブルへのアクセスの要求があった際、当該被管理者に対し、当該被管理者の識別子のデータを有する前記レコードへのアクセスを許可し、他の被管理者の識別子のデータを有する前記レコードへのアクセスを制限するものであり、
前記アクセス制御部は、少なくとも前記オペレータの端末から前記申請データ収容部へのアクセスの要求があった際、前記オペレータに対し全ての前記被管理者の前記レコードへのアクセスを許可するものであり、
前記システム制御部は、前記管理表示部により前記オペレータの用いる端末において前記複数の被管理者の一覧表を表示させ、前記一覧表から前記オペレータが選択した被管理者の識別子を収容する前記レコードを前記復号部にて復号化させて表示させ、且つ前記オペレータの前記レコードの選択により前記キー生成部へ前記キーを生成させて前記オペレータの要求する前記被管理者の前記申請関連のファイルへの前記アクセスを可能とするものであり、
前記システム制御部は、前記被管理者の用いる端末の操作にて前記個別表示部により、前記アクセス制御部がアクセスを許可した当該被管理者の前記レコードを前記復号部にて復号化して当該被管理者の端末へ表示させ、且つ前記被管理者の前記レコードの選択により前記キー生成部に前記キーを生成させて前記オペレータの要求する当該被管理者の前記申請関連のファイルへの前記アクセスを可能とするものであり、
前記システム制御部は、当該被管理者以外の他の被管理者の前記レコードを前記個別表示部に隠蔽させ当該被管理者の端末へ表示させない請求項２記載の電子申請補助システム。
- 少なくとも前記申請データ収容部と前記システム制御部と前記暗号生成部は、インターネット等のネットワークへ接続された１つ又は複数のサーバに設けられ、
前記アクセス制御部にてアクセスが許可された前記被管理者の端末から、当該被管理者の前記申請データ収容部へ前記申請用データのファイルをアップロードすることができ、
前記アップロード時、前記暗号生成部は、前記申請用データのファイルの前記ファイル名のデータと前記他の要素データの夫々を暗号化し前記レコードの一部として前記管理テーブル収容部の前記テーブルへ収容するものであり、且つ、前記キー生成部は、前記暗号生成部にて暗号化した前記ファイル名のデータと前記他の要素データとを更に暗号化することで前記キーを生成し、アップロードされた前記申請用データのファイルの収容に用いる前記ファイル別収容部を形成して前記キーを付与するものであり、
前記他の要素データは、前記申請用データのファイルのアップロード元の所在を示すファイルパスのデータであり、前記システム制御部は、当該ファイルパスのデータを前記暗号生成部にて暗号化させて前記レコードの一部として前記テーブルへ収容し、
前記オペレータの端末からの指定にて、前記被管理者の前記申請用データのファイルを前記キーでアクセスすることにより前記オペレータの端末へダウンロードすることができる請求項３記載の電子申請補助システム。
- 少なくとも前記申請データ収容部と前記システム制御部と前記暗号生成部は、インターネット等のネットワークへ接続された１つ又は複数のサーバに設けられ、
少なくとも前記手続先への前記申請手続後、前記オペレータの端末の操作により、インターネット等のネットワークを介して前記手続先からオンラインにて前記申請手続に対する前記手続先発行の前記発行データのファイルを前記オペレータの端末へダウンロードすることができ、
前記暗号生成部は、前記ダウンロードした前記発行データのファイルを前記オペレータの端末から当該被管理者の前記申請データ収容部へアップロードすることができ、
前記アップロード時、前記暗号生成部は、前記発行データのファイルの前記ファイル名のデータと前記他の要素データの夫々を暗号化して前記管理テーブル収容部の前記テーブルへ前記レコードの一部として収容するものであり、且つ、前記キー生成部は、前記暗号生成部にて暗号化した前記ファイル名のデータと前記他の要素データとを更に暗号化することで前記キーを生成し、前記システム制御部はアップロードされた前記発行データのファイルの収容に用いる前記ファイル別収容部を形成して前記キーを付与するものであり、
前記他の要素データは前記発行データのファイルのダウンロード元の所在を示すダウンロードリンクのデータであり、前記システム制御部は前記暗号生成部にて暗号化させて前記レコードの一部として前記テーブルへ収容し、
前記被管理者の端末の操作にて、当該被管理者の前記ファイル別収容部へ収容された前記発行データのファイルを前記キーにてアクセスすることにより当該被管理者の端末へダウンロードすることができる請求項３記載の電子申請補助システム。
- 前記管理テーブル収容部には前記テーブルとは別に、前記オペレータのメールアドレスのデータと前記オペレータによって事前に設定されたパスワードのデータと前記オペレータの識別子とを有するレコードを収容する、管理者認証テーブルが設けられ、
更に前記管理テーブル収容部には前記テーブル及び前記管理者認証テーブルとは別に、各被管理者のメールアドレスのデータと各被管理者によって事前に設定されたパスワードのデータと各被管理者の識別子とを有するレコードを収容する、被管理者認証テーブルが設けられ、
端末からのログイン時に、前記アクセス制御部は、ログインする者のメールアドレスと識別子のうちの少なくとも何れか一方とパスワードの入力とを受け、前記管理者認証テーブルと前記被管理者認証テーブルの少なくとも何れか一方に収容されたレコードを参照して、ログインした者が管理者権限によるものか被管理者権限によるものか判断し必要な前記アクセスの制限を行うものである請求項３乃至５の何れかに記載の電子申請補助システム。
- 少なくとも前記申請データ収容部と前記システム制御部は、ウェブサービスを提供する業者の１つ又は複数のサーバに構築されるものであり、
前記サーバは、負荷分散装置を有し、前記サーバの数を増減しても動作可能に構成された請求項１乃至６の何れかに記載の電子申請補助システム。
- 請求項１乃至７の何れかに記載の電子申請補助システムが、前記オペレータによる手続先へのオンラインによる前記申請の補助を行う電子申請の補助方法。
- 請求項１乃至７の何れかに記載の電子申請補助システムとしてコンピュータを機能させるためのプログラム。
- 請求項９記載の電子申請補助システムとしてコンピュータを機能させるためのプログラムが記録された記録媒体。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2020017011A JP7361384B2 (ja) | 2020-02-04 | 2020-02-04 | 電子申請の補助方法、電子申請補助システム、電子申請補助システムのプログラム及びその記録媒体 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2020017011A JP7361384B2 (ja) | 2020-02-04 | 2020-02-04 | 電子申請の補助方法、電子申請補助システム、電子申請補助システムのプログラム及びその記録媒体 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2021124878A JP2021124878A (ja) | 2021-08-30 |
| JP7361384B2 true JP7361384B2 (ja) | 2023-10-16 |
Family
ID=77459012
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2020017011A Active JP7361384B2 (ja) | 2020-02-04 | 2020-02-04 | 電子申請の補助方法、電子申請補助システム、電子申請補助システムのプログラム及びその記録媒体 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP7361384B2 (ja) |
Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2002132566A (ja) | 2000-10-27 | 2002-05-10 | Ntt Me Corp | データ管理システム及び方法、並びにコンピュータ読取可能な記録媒体 |
| JP2003216474A (ja) | 2002-01-23 | 2003-07-31 | Hitachi Ltd | ネットワークストレージ仮想化方法 |
| JP2008250369A (ja) | 2007-03-29 | 2008-10-16 | Sorun Corp | 機密データファイルの管理方法、管理システム及びプロキシサーバ |
| JP2011100334A (ja) | 2009-11-06 | 2011-05-19 | Nec System Technologies Ltd | 文書ファイル検索システム、文書ファイル登録方法、文書ファイル検索方法、プログラム及び記録媒体 |
| JP2018013941A (ja) | 2016-07-20 | 2018-01-25 | 株式会社三菱電機ビジネスシステム | 電子申請支援システム、電子申請支援方法、及び電子申請支援プログラム |
-
2020
- 2020-02-04 JP JP2020017011A patent/JP7361384B2/ja active Active
Patent Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2002132566A (ja) | 2000-10-27 | 2002-05-10 | Ntt Me Corp | データ管理システム及び方法、並びにコンピュータ読取可能な記録媒体 |
| JP2003216474A (ja) | 2002-01-23 | 2003-07-31 | Hitachi Ltd | ネットワークストレージ仮想化方法 |
| JP2008250369A (ja) | 2007-03-29 | 2008-10-16 | Sorun Corp | 機密データファイルの管理方法、管理システム及びプロキシサーバ |
| JP2011100334A (ja) | 2009-11-06 | 2011-05-19 | Nec System Technologies Ltd | 文書ファイル検索システム、文書ファイル登録方法、文書ファイル検索方法、プログラム及び記録媒体 |
| JP2018013941A (ja) | 2016-07-20 | 2018-01-25 | 株式会社三菱電機ビジネスシステム | 電子申請支援システム、電子申請支援方法、及び電子申請支援プログラム |
Also Published As
| Publication number | Publication date |
|---|---|
| JP2021124878A (ja) | 2021-08-30 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US11323479B2 (en) | Data loss prevention techniques | |
| US10090998B2 (en) | Multiple authority data security and access | |
| US10474829B2 (en) | Virtual service provider zones | |
| US8539231B1 (en) | Encryption key management | |
| US11431757B2 (en) | Access control using impersonization | |
| CN111213147A (zh) | 用于基于区块链的交叉实体认证的系统和方法 | |
| CN111316303A (zh) | 用于基于区块链的交叉实体认证的系统和方法 | |
| US11290446B2 (en) | Access to data stored in a cloud | |
| US8848922B1 (en) | Distributed encryption key management | |
| CN108027799A (zh) | 用于在未受管理的并且未受防护的设备上的资源访问和安置的安全容器平台 | |
| US20200395107A1 (en) | Secure environment device management | |
| JP7361384B2 (ja) | 電子申請の補助方法、電子申請補助システム、電子申請補助システムのプログラム及びその記録媒体 | |
| JP2023539168A (ja) | 自己認証識別子及びそのためのアプリケーション | |
| JP7284957B2 (ja) | 情報管理装置 | |
| EP4322470A1 (en) | Data encryption system and method |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20211210 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20221019 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20221101 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20221102 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20230307 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20230309 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20230627 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20230704 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20230725 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20230803 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20230829 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20230926 |
|
| R150 | Certificate of patent or registration of utility model |
Ref document number: 7361384 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 |