まず概要を説明する。企業は今後、報酬の支払に伴って作成すべき法定調書に、報酬を受け取る個人のマイナンバー(以下「個人番号」と呼ぶ。)を設定する必要があり、そのために個人番号の本人確認を行う必要がある。本人確認は、個人番号を提示する個人がその本人であることの確認と、個人番号が本人に通知された個人番号と一致することの確認の両方を含む。前者は、個人番号を提示する個人の本人性確認・身元確認と言え、後者は、個人番号の真正性確認・番号確認と言える。
ところで現在、知的生産力やコンテンツ等を、多数の人々から調達・集約し、事業成果を得ることを目的としたクラウドソーシングが普及しつつある。クラウドソーシングの普及等により、企業は、比較的少額の報酬を、従来より多くの個人に、従来より高い頻度で支払うようになっていくことが考えられる。また、報酬支払先の個人は、固定的な従業員とは異なり、都度変化するかもしれない。したがって、多くの個人の個人番号を収集するために企業には多大なコストが発生しうる。
クラウドソーシングの普及は、個人にとっても給与や報酬の支払元の増加につながり、個人番号を含む個人情報を多くの支払元へ申告する必要が生じると想定され、個人の負担も増大しうる。
第1および第2の実施の形態(以下「第1実施形態」等と呼ぶ。)の情報処理システムは、給与や報酬の受取主体にとって効率的な個人情報の申告を支援すること、また、給与や報酬の支払主体にとって効率的な個人情報の収集を支援することを目的とする。具体的には、クラウドソーシングにおける個人情報の申告と、法定調書の提出を支援するSaaS(Software as a Service)を実現する。法定調書は、金銭支払先個人の個人番号等、金銭支払に関する事実を記載して公的機関へ提出すべき文書であり、例えば源泉徴収票や支払調書を含む。以下では支払調書を例に説明する。
各実施形態特有の特徴は以下の通りである。
第1実施形態:個人情報(個人番号)の確認書類や法定調書をSaaS経由で電子的に送信する。すなわち個人情報等の中継処理をメインとする。
第2実施形態:個人情報(個人番号)の確認書類に基づく本人確認や、法定調書の作成・提出をSaaS側で実行する。いわゆるBPO(Business Process Outsourcing)サービスを提供する。
以下の説明において、通知カードは、行政機関から個人に送付されたカードであり、個人番号、氏名、住所、性別、生年月日等が券面に印刷されたものである。なお、通知カードに代えて、行政機関が個人に対して発行する身分証明書である個人番号カードが使用されてもよい。
(第1実施形態)
図1は、第1実施形態の番号確認支援システム10の構成を示す。番号確認支援システム10は、番号確認GW12、企業PC14で総称される企業PC14a、企業PC14b、企業PC14c、行政サーバ16、ユーザ端末18で総称されるスマートフォン18a、タブレット端末18b、PC18cを備える。
ユーザ端末18は、自身の個人番号を含む個人情報を給与や報酬の支払元企業に対して申告すべき個人(企業の従業員とも言え、以下「ユーザ」とも呼ぶ。)により操作される情報処理装置である。ユーザ端末18は、各種メッセージの表示や、ユーザが入力した情報を読み込む等、ユーザとのインタフェース機能を提供する。図1に示すようにユーザ端末18は、スマートフォン、タブレット端末、PC等を含むがこれらには限定されない。ユーザ端末18の詳細な機能は図2に関連して後述する。
企業PC14は、ユーザに対して給与や報酬を支払う企業の担当者により操作される情報処理装置である。もちろんPCには限定されず、スマートフォンやタブレット端末、サーバ等であってもよい。行政サーバ16は、国税庁(税務署)や自治体、年金機構等の行政機関が保持する情報処理装置である。行政サーバ16は、支払調書等、法定調書の提出先として機能し、法定調書のデータをオンラインで受け付ける。
番号確認GW12は、企業A〜企業Cに対して、被雇用者であるユーザの個人情報(個人番号を含む)の収集支援サービスを提供する情報処理装置である。番号確認GW12は、本来は企業A〜企業Cが個別に実施すべき被雇用者の個人情報の収集業務を一括して代行するプラットフォーム、またゲートウェイとなる装置である。番号確認GW12は、個人情報収集サービスを提供する業者が管理する装置であってもよい。
第1実施形態の企業A〜企業Cは、番号確認GW12を利用して被雇用者の個人番号を取得する。ただし、個人番号の本人確認や、ユーザへの金銭の支払に関する支払調書の作成は各社で実施する。第1実施形態の番号確認GW12は、個人番号を含む本人確認書類や、支払調書等の情報連携を主に実行する。
図1の各装置は、インターネットや専用線網等を含む公知の通信網19を介して接続される。また図1の各装置(例えば企業PC14や行政サーバ16)は、物理的に複数の装置により構成されてもよいことはもちろんである。
図2は、図1のユーザ端末18の機能構成を示すブロック図である。ユーザ端末18は、LCD20、カメラ22、制御部24、記憶部26、通信部28を備える。本明細書のブロック図において示される各ブロックは、ハードウェア的には、コンピュータのCPUをはじめとする素子や機械装置で実現でき、ソフトウェア的にはコンピュータプログラム等によって実現されるが、ここでは、それらの連携によって実現される機能ブロックを描いている。したがって、これらの機能ブロックはハードウェア、ソフトウェアの組合せによっていろいろなかたちで実現できることは、当業者には理解されるところである。
例えば、制御部24内の複数のブロックに対応する複数のモジュールを含むコンピュータプログラムがDVD等の記録媒体に格納され、ユーザ端末18にインストールされてもよい。そしてユーザ端末18のプロセッサ(CPU等)が、ストレージに格納されたコンピュータプログラムをメインメモリに読出して実行することで、各ブロックの機能が発揮されてもよい。記憶部26は、ユーザ端末18のストレージやメモリがデータを記憶することで実現されてよい。図3に関連して後述する番号確認GW12も同様である。
LCD20は、種々の電子コンテンツを表示する液晶ディスプレイである。カメラ22は、ユーザの操作に応じて写真を撮影する撮像装置である。第1実施形態のLCD20は、ユーザ端末18の筐体と一体化されており、また、タッチパネルの機能を有し、情報入力手段でもある。LCD20やカメラ22は外付けの装置であってもよく、またLCD20とは別に情報入力手段が設けられてもよい。
制御部24は、各種データ処理を実行する。記憶部26は、制御部24により参照、更新されるデータを記憶する記憶領域である。通信部28は、所定の通信プロトコルにしたがって外部装置と通信する。例えば制御部24は、通信部28を介して、番号確認GW12とデータを送受する。
記憶部26は、申告先候補保持部30、個人情報保持部32、調書保持部34を含む。申告先候補保持部30は、個人情報の申告先候補となる複数の企業に関する情報を保持する。具体的には、申告先候補となる複数の企業の識別情報を含む企業リストを保持する。個人情報保持部32は、ユーザの個人情報を一時的に保持する。具体的には個人情報保持部32は、ユーザの個人情報を含むデータであり、例えば通知カードの券面を撮影した写真データ(画像データとも言える)と、身分証明書の券面を撮影した写真データを保持する。
調書保持部34は、番号確認GW12から提供された法定調書のデータであり、第1実施形態では支払調書のデータを保持する。なお、後述の番号登録支援App40がユーザ端末1へインストールされる際に、ユーザ端末18の記憶部26に、申告先候補保持部30、個人情報保持部32、調書保持部34が設定されてもよい。
制御部24は、操作検出部36と表示制御部38を備える。さらに制御部24は、番号登録支援アプリケーション(以下「番号登録支援App40」と呼ぶ。)のプログラムモジュールとして実装されるアプリ画面表示部42、個人情報記録部44、申告先取得部46、申告情報送信部48、個人情報消去部50、申告先候補更新部52、調書取得部54、調書提出部56を備える。
操作検出部36は、ユーザがLCD20に対して入力した操作を検出し、操作内容を示す情報を他の機能ブロックへ通知する。表示制御部38は、LCD20による電子コンテンツの表示を制御する。例えば表示制御部38は、アプリ画面表示部42の指示に応じて、番号登録支援App40の各種画面をLCD20に表示させる。
アプリ画面表示部42は、番号登録支援App40の画面のデータを、表示制御部38を介してLCD20に表示させる。番号登録支援App40の画面は、ユーザに通知カードの撮影を指示する撮影指示画面、ユーザに個人情報の申告先を選択させる申告先選択画面、支払調書の内容をユーザに提示する調書提示画面を含む。
アプリ画面表示部42は、申告先候補保持部30に保持された申告先候補の企業リストを取得し、申告先とする企業をユーザが選択可能な態様で企業リストを申告先選択画面に表示させる。また、後述する申告済フラグがオンの場合、アプリ画面表示部42は、撮影指示画面の表示をスキップして、申告先選択画面を表示させる。
個人情報記録部44は、ユーザの操作によりユーザ端末18に入力されたユーザの個人情報を受け付けて個人情報保持部32へ格納する。具体的には個人情報記録部44は、カメラ22により撮像されたユーザの通知カードの写真データと、身分証明書(運転免許証等)の写真データを個人情報保持部32へ格納する。申告先取得部46は、申告先選択画面で特定の企業が申告先として選択された場合に、その特定の企業を申告先企業として取得する。
申告情報送信部48は、申告先選択画面で特定の企業が申告先として選択された場合に、選択された企業宛の申告情報をユーザIDと対応づけて番号確認GW12へ送信する。この申告情報は、申告先企業の識別情報を含む申告先指定データと、個人情報保持部32に保持された通知カードおよび身分証明書の写真データを含む。
なお第1実施形態では、企業が、本人確認書類の送付をユーザへ依頼する際に、その企業がユーザに割当てたユーザIDをあわせてユーザへ通知することとする。ユーザIDは、企業が作成する支払調書とユーザとの紐付け用の識別子と言え、ユーザ端末18のメールアドレスや電話番号等の連絡用識別子を使用してもよい。ユーザは、企業から通知されたユーザIDを番号登録支援App40へ登録する。
申告情報送信部48は、番号確認GW12への申告情報の送信が正常に完了した場合に、記憶部26に記憶されたデータであり、個人情報を番号確認GW12へアップロード済であることを示す申告済フラグ(初期値はオフ)をオンに設定する。申告情報送信部48は、申告済フラグがオンの場合、申告先指定データを含むが、通知カードおよび身分証明書の写真データを含まない申告情報を番号確認GW12へ送信する。
個人情報消去部50は、申告情報送信部48による番号確認GW12への申告情報の送信が正常に完了した場合に、個人情報保持部32に保持された通知カードおよび身分証明書の写真データを消去する。これにより、ユーザ端末18からユーザの個人情報が漏洩するリスクを低減する。
申告先候補更新部52は、申告先候補保持部30に保持された申告先候補の企業リストを更新する。具体的には、申告先候補の新たな企業リストが番号確認GW12から配信された場合に、それまでの企業リストを新たな企業リストへ更新する。なお、番号確認GW12により作成された新たなリストを、インターネット上のアプリストアのウェブサイトを介して取得してもよいことはもちろんである。
調書取得部54は、番号確認GW12から提供された支払調書のデータを受け付けて調書保持部34へ格納する。調書提出部56は、調書提示画面に対して調書提出操作が入力された場合に、調書提示画面で表示中の支払調書のデータを行政サーバ16へ送信する。例えば調書提出部56は、行政サーバ16に予め設けられた調書提出用のウェブサービスを、支払調書のデータを引数として呼び出すことにより、支払調書のデータを行政サーバ16へアップロードしてもよい。
図3は、図1の番号確認GW12の機能構成を示すブロック図である。番号確認GW12は、制御部60、記憶部62、通信部64を備える。これらのブロックは、ユーザ端末18の制御部24、記憶部26、通信部28に対応する。
記憶部62は、申告先候補保持部66、企業私書箱保持部68、調書保持部70を含む。申告先候補保持部66は、ユーザの個人情報の申告先候補となる複数の企業に関する情報を保持する。具体的には、申告先候補となる複数の企業の識別情報を含む企業リストを保持する。調書保持部70は、企業PC14から提供された法定調書のデータ、第1実施形態では支払調書のデータをユーザIDと対応づけて保持する。
企業私書箱保持部68は、番号確認GW12を利用する企業の私書箱に相当する記憶領域(以下「企業私書箱」と呼ぶ。)を保持し、複数の企業に対応する複数の企業私書箱を保持する。企業私書箱保持部68は、ある企業に割当てられた企業私書箱において、その企業宛に申告されたユーザの個人情報を記憶する。具体的には企業私書箱保持部68は、通知カードの写真データおよび身分証明書の写真データを、ユーザIDおよびデータ格納日時と対応づけて保持する。企業私書箱保持部68は、ユーザの個人情報を記憶する個人情報保持部とも言える。
制御部60は、企業登録部72、申告先候補配信部74、申告情報受付部76、個人情報記録部78、個人情報提供部80、調書受付部82、調書提供部84、個人情報消去部86を含む。
企業登録部72は、番号確認GW12による個人情報収集サービスの利用を開始するための利用登録として、企業私書箱の開設要求を企業PC14から受け付ける。企業登録部72は、企業私書箱の開設要求に応じて、要求元企業の識別情報(企業名等)を申告先候補保持部66に保持された申告先候補の企業リストへ追加する。
また企業登録部72は、企業私書箱の開設要求に応じて、要求元企業用の企業私書箱を企業私書箱保持部68に新たに設定する。例えば企業登録部72は、ユーザの個人情報が格納される企業私書箱保持部68のディレクトリ配下に、要求元企業用のディレクトリを企業私書箱として新規に作成してもよい。そして、要求元企業の識別情報と、企業私書箱のパス名との対応関係を記録することにより、複数の企業(例えば企業A〜C)それぞれの企業私書箱を識別可能にしてもよい。
申告先候補配信部74は、申告先候補保持部66に保持された申告先候補の企業リストが更新された場合に、更新後の最新の企業リストを、番号登録支援App40をインストール済のユーザ端末18へ送信する。インターネット上のアプリストアへアップロードし、アプリストアを介して最新の企業リストをユーザ端末18へ送信してもよい。
申告情報受付部76は、ユーザ端末18から送信されたユーザIDと申告情報を受け付ける。個人情報記録部78は、申告情報受付部76が受け付けた申告情報にユーザの個人情報を示す開示データ(第1実施形態では通知カードの写真データおよび身分証明書の写真データ)が含まれる場合、その開示データをユーザIDに対応付けて企業私書箱保持部68へ格納する。個人情報記録部78は、企業私書箱保持部68に設定された複数の企業私書箱のうち、申告情報に含まれる申告先指定データが示す企業の企業私書箱へ開示データを格納する。
申告情報受付部76が受け付けた申告情報に開示データが含まれない場合、個人情報記録部78は、企業私書箱保持部68に予め保持された開示データの中から、申告情報が示すユーザIDに対応付けられた開示データを検索する。申告情報が示すユーザIDに対応付けられた開示データが存在すれば、個人情報記録部78は、その開示データを、申告先指定データが示す企業の企業私書箱へ格納する。これにより、例えば事前に企業Aへ提供したユーザの開示データを、企業Bへ提供することを可能にする。なお個人情報記録部78は、開示データをOCR(Optical Character Recognition)処理して、ユーザの個人番号や氏名、住所等のテキストデータを企業私書箱に格納してもよい。
記憶部62には、複数の企業の識別情報(企業A〜企業C)と、複数の企業PC14の識別情報(企業PC14a〜企業PC14cのメールアドレス等)との対応関係が予め格納される。個人情報提供部80は、申告情報が受け付けられた場合に、ユーザの個人情報を保管した旨を申告先企業の企業PC14へ通知する。例えば、申告情報が示すユーザIDと、通知カードおよび身分証明書の写真を保管した旨のメッセージを含む電子メールを申告先企業の企業PC14へ送信する。
個人情報提供部80は、企業PC14からのログインを受け付けると、ログインした企業を申告先とする個人情報を企業PC14へ提供する。具体的には個人情報提供部80は、ログインした企業の企業私書箱に格納された通知カードの写真データ、身分証明書の写真データ、ユーザIDを取得し、それらのデータを企業PC14へ送信する。それらのデータを含むウェブページを企業PC14へ送信して表示させてもよい。
個人情報提供部80は、各企業によるユーザの個人情報(通知カードおよび身分証明書の写真)へのアクセス権を、そのアクセスが可能になってから、または、企業PC14に対して写真の保管を通知してから一定期間経過後に無効にする。言い換えれば、一定期間経過後は、ユーザにより指定された申告先企業であっても、ユーザの個人情報の取得や閲覧を禁止する。この期間は、例えば2週間〜1ヶ月であってもよく、国の指針や企業等のセキュリティポリシに応じて決定されてよい。
調書受付部82は、企業側で作成された支払調書のデータをユーザIDとともに企業PC14から受け付ける。調書受付部82は、受け付けた支払調書のデータをユーザIDに対応付けて調書保持部70へ格納する。
記憶部62には、ユーザIDとユーザ端末18(例えばメールアドレス等)との対応関係が予め格納される。この対応関係はユーザ端末18から事前に登録されてよい。調書提供部84は、新たな支払調書のデータが調書保持部70に格納された場合に、そのデータに対応付けられたユーザIDで特定されるユーザ端末18へ支払調書の完成を通知する。例えば、支払調書の作成が完成した旨の電子メールを、ユーザIDに対応するユーザ端末18へ送信してもよい。
調書提供部84は、支払調書ダウンロード用ウェブページをユーザ端末18へ提供する。ユーザはユーザIDを入力してこのウェブページにログインする。調書提供部84は、支払調書ダウンロード用ウェブページでダウンロードが要求されると、ログイン時に入力されたユーザIDに対応付けられた支払調書のデータを調書保持部70から取得し、そのデータをユーザ端末18へ送信する。
調書提供部84は、ユーザによる支払調書へのアクセス権を、そのアクセスが可能になってから、または、ユーザ端末18に対して支払調書の完成を通知してから一定期間経過後に無効にする。言い換えれば、一定期間経過後は、ユーザによる支払調書のダウンロードを禁止する。この期間は、例えば2週間〜1ヶ月であってもよく、国の指針や企業等のセキュリティポリシに応じて決定されてよい。
個人情報消去部86は、企業私書箱保持部68に格納されたユーザの個人情報(通知カードおよび身分証明書の写真)について、格納日時を参照して、企業私書箱保持部68に格納された期間を監視する。個人情報消去部86は、格納期間が所定の閾値以上になった個人情報を企業私書箱保持部68から消去する。この閾値は、例えば1年〜2年であってもよく、国の指針や企業等のセキュリティポリシに応じて決定されてよい。
個人情報消去部86は、個人情報を消去したユーザIDにより特定されるユーザ端末18へ、写真の再アップロードを促す所定の通知を送信してもよい。この通知を受け付けたユーザ端末18の申告情報送信部48は、記憶部26の申告済フラグをオンからオフに切り替えてもよい。これにより、新たな申告時にはユーザ端末18で撮影指示画面が表示される。また、番号確認GW12の申告情報受付部76は、開示データを含まない申告情報を受け付けた場合に、そのユーザの個人情報が企業私書箱保持部68に存在しなければ(すなわち消去済であれば)、写真の再撮影とアップロードを促すメッセージをユーザ端末18へ返信して表示させてもよい。
以上の構成による番号確認支援システム10の動作を説明する。
図4は、第1実施形態の番号確認支援システム10の動作を示すシーケンス図である。ここでは、ユーザ端末18はスマートフォン18aとする。ユーザは、支払調書への設定が必要な個人番号を企業Aへ申告するために、本人確認書類として通知カードの写真と身分証明書の写真を企業Aへ提供する。図4の企業Aは企業PC14aに対応し、行政機関は行政サーバ16に対応する。
まず、企業PC14aは、自社の企業私書箱の開設を番号確認GW12に要求する(S10)。番号確認GW12の企業登録部72は、企業Aの情報を申告先候補の企業リストへ追加するともに、企業A用の企業私書箱を企業私書箱保持部68に設定する。企業PC14aは、番号登録支援App40による本人確認書類の送付を依頼する内容の電子メールであり、企業Aが定めたユーザIDを通知する電子メールをスマートフォン18aへ送信する(S11)。
ユーザは、スマートフォン18aを操作して、所定のアプリストアから番号登録支援App40をダウンロードし、スマートフォン18aへインストールする(S12)。ユーザは、スマートフォン18aで番号登録支援App40を起動し、個人情報申告メニューを選択する。申告済フラグがオフであるため、スマートフォン18aのアプリ画面表示部42は撮影指示画面を表示させる。ユーザが通知カードと身分証明書をスマートフォン18aのカメラ22で撮影すると、スマートフォン18aの個人情報記録部44は、それらの写真データを個人情報保持部32に格納する(S13)。
次にアプリ画面表示部42は申告先選択画面を表示させる。ユーザは個人情報の申告先であり、写真の送付先となる企業Aを選択する(S14)。申告情報送信部48は、企業Aを指定するデータ、写真データ、ユーザIDを含む申告情報を番号確認GW12へ送信する(S15)。送信完了後、申告情報送信部48は申告済フラグをオンに切り替え、個人情報消去部50は、個人情報保持部32に格納された写真データを消去する。
番号確認GW12の申告情報受付部76は、スマートフォン18aから送信された申告情報を受信する。個人情報記録部78は、受信された申告情報が含む写真データを、ユーザIDと現在日時に対応付けて、企業Aに割当てられた企業私書箱へ格納する(S16)。個人情報提供部80は、受信された申告情報に含まれるユーザIDを提示する電子メールであり、ユーザの個人情報を保管した旨の電子メールを企業PC14aへ送信する(S17)。
企業Aの担当者は、企業PC14aを操作して番号確認GW12の企業向けウェブサイトへログインする(S18)。企業Aの担当者は、番号確認GW12の企業向けウェブページに、電子メールにて通知されたユーザIDを入力する。この操作に応じて、企業PC14aは、そのユーザIDを指定した個人情報閲覧要求を番号確認GW12へ送信する。番号確認GW12の個人情報提供部80は、個人情報閲覧要求で指定されたユーザIDにより特定される写真データを企業Aに割当てられた企業私書箱から検索する。
指定されたユーザIDに対応付けられた写真データが存在すれば、個人情報提供部80はその写真データ(すなわち通知カードと身分証明書の画像)を含むウェブページを企業PC14aへ送信して表示させる(S19)。なお、番号確認GW12は、企業Aを申告先とする複数のユーザの個人情報を集約したデータであり、例えばOCR処理で読み込んだ複数のユーザの個人番号を含むCSVファイルを企業PC14aに送信してもよい。このように、企業PC14aは、自社宛の複数のユーザの個人情報を一括ダウンロードしてもよい。
企業Aの担当者は、ウェブページに表示されたユーザの個人情報に基づいて、ユーザの本人確認を実施する。例えば、通知カードの画像と身分証明書の画像を参照して、ユーザの本人性確認と個人番号の真正性確認を実施してもよい。本人確認が終了すると、企業Aの担当者は、ユーザの個人情報を企業Aの不図示のシステムへ入力し、記憶させる(S20)。例えば、ユーザの個人番号をユーザIDと対応づけて自社のシステム(被雇用者の個人番号を登録すべきデータベース等)へ登録してもよい。
その後、企業Aからユーザへ報酬が支払われる。企業Aの担当者は、企業PC14aにてユーザの個人情報(特に個人番号)を含む支払調書を作成する(S21)。企業PC14aは、支払調書のデータをユーザIDとともに番号確認GW12へアップロードする(S22)。番号確認GW12の調書受付部82は、企業PC14aから送信された支払調書のデータをユーザIDと対応付けて調書保持部70へ格納する。
番号確認GW12の調書提供部84は、支払調書完成のメッセージとユーザIDを含む電子メールをユーザ端末18へ送信する(S23)。ユーザは、スマートフォン18aを操作して番号確認GW12の個人向けウェブサイトへログインし、個人向けウェブページへユーザIDを入力する。この操作に応じて、スマートフォン18aは、ユーザIDを指定した支払調書のダウンロード要求を番号確認GW12へ送信する。番号確認GW12の調書提供部84は、ダウンロード要求で指定されたユーザIDにより特定される支払調書のデータを調書保持部70から取得してスマートフォン18aへ送信する(S24)。そして支払調書の内容を示す調書提示画面がスマートフォン18aに表示される。
以降、企業Aはオフラインで支払調書を行政機関へ提出し、または、企業PC14aはオンラインで支払調書のデータを行政サーバ16へ送信する(S25)。ユーザが番号登録支援App40の調書提出メニューを選択すると、ユーザ端末18の調書提出部56は、支払調書のデータを行政サーバ16へ送信する(S26)。
所定期間が経過すると、番号確認GW12は個人情報保護のためのデータ処理を実行する(S27)。具体的には個人情報提供部80は、企業Aの企業私書箱に格納されたユーザの個人情報に対する企業Aのアクセス権を削除する。また個人情報消去部86は、企業Aの企業私書箱に格納されたユーザの個人情報を消去する。さらにまた調書提供部84は、調書保持部70に格納されたユーザの支払調書に対するユーザ端末18のアクセス権を削除する。
図5は、図4に続く番号確認支援システム10の動作を示すシーケンス図である。ここでは、企業Aへ個人情報を申告済のユーザが、後日、企業Bの仕事を請け負うこととなり、企業Bへ個人情報を新たに申告することを想定する。図5の企業Bは企業PC14bに対応する。これまで企業Bは番号確認GW12を利用しなかったこととし、まず企業PC14bは、自社の企業私書箱の開設を番号確認GW12に要求する(S30)。番号確認GW12の企業登録部72は、企業Bの情報を申告先候補の企業リストへ追加するともに、企業B用の企業私書箱を企業私書箱保持部68に設定する。
番号確認GW12の申告先候補配信部74は、企業登録部72により更新された最新の企業リストをスマートフォン18aへ送信する(S31)。最新の企業リストを含む番号登録支援App40の更新モジュールが、インターネット上のアプリストアからスマートフォン18aへ提供されてもよい。企業PC14bは、番号登録支援App40による本人確認書類の送付を依頼する内容の電子メールであり、企業Bが定めたユーザIDを通知する電子メールをスマートフォン18aへ送信する(S32)。
ユーザは、スマートフォン18aで番号登録支援App40を起動し、個人情報申告メニューを選択する。申告済フラグがオンであるため、スマートフォン18aのアプリ画面表示部42は、撮影指示画面の表示をスキップして申告先選択画面を表示させる。ユーザは、個人情報の申告先となる企業Bを申告先選択画面で選択する(S33)。スマートフォン18aの申告情報送信部48は、個人情報申告先の企業Bを指定するデータとユーザIDを含むが、通知カードと身分証明書の写真データを含まない申告情報を番号確認GW12へ送信する(S34)。
番号確認GW12の個人情報記録部78は、ユーザIDにより特定される写真データであり、この例では企業Aの企業私書箱に格納済の写真データを検出し、その写真データをユーザIDと現在日時に対応付けて、企業Bに割当てられた企業私書箱へコピーする(S35)。以降のS36〜S46の処理は、図4のS17〜S27の処理と同様である。例えばS38では、企業Bの企業私書箱に格納された写真データであり、すなわち企業Aに提供された写真データを企業PC14bへ送信する。
このように第1実施形態の番号確認GW12およびユーザ端末18(特に番号登録支援App40)によると、ユーザは、通知カード等を一度撮影し、その写真等の個人情報を一旦いずれかの企業へ申告すれば、別の企業へ個人情報を申告する際に再度通知カード等を撮影することが不要になる。例えば、番号登録支援App40の申告先選択画面で上記別の企業を選択するだけで、その企業への個人情報(個人番号)の申告が完了する。これにより、クラウドソーシング等の進展に伴って、個人情報の申告先、言い換えれば、個人番号の告知先が増加する場合にも、ユーザの負担増加を抑制できる。
また、ユーザの個人情報を収集すべき企業にとっても、番号登録支援App40経由での本人確認書類送付をユーザに依頼すれば、番号確認GW12を経由して、本人確認書類が企業へ提供される。これにより、クラウドソーシング等の進展に伴って、給与や報酬の支払対象となる個人が増加する場合にも企業の負担増加を抑制できる。
以上、本発明を第1実施形態をもとに説明した。この実施の形態は例示であり、各構成要素や各処理プロセスの組合せにいろいろな変形例が可能なこと、またそうした変形例も本発明の範囲にあることは当業者に理解されるところである。以下変形例を示すが、これらの変形例は後述の第2実施形態にも適用可能である。
第1変形例を説明する。第1実施形態では企業私書箱保持部68に企業毎の企業私書箱を設け、企業私書箱単位にユーザの個人情報を記憶することとした。変形例として、番号確認GW12は、企業私書箱保持部68に代えて、ユーザの個人情報をユーザ単位、言い換えればユーザID単位に記憶する個人情報保持部を備えてもよい。具体的には、個人情報保持部は、ユーザの個人情報と、その申告先となる1つ以上の企業の識別情報と、各企業への申告日時(第1実施形態の格納日時に相当)を対応付けて保持してもよい。
番号確認GW12の個人情報記録部78は、ユーザ端末18からアップロードされた個人情報に申告先企業の識別情報を対応付けて個人情報保持部へ格納してもよい。また、申告先指定データを含むが開示データを含まない申告情報を受け付けた場合、個人情報記録部78は、既に個人情報保持部に記憶された申告元ユーザの個人情報に対して、申告先企業の識別情報と申告日時を新たに付加して記録してもよい。個人情報提供部80は、特定の企業の識別情報に対応付けられた個人情報を、その特定の企業の企業PC14へ提供してもよい。
第2変形例を説明する。図4のS26、図5のS45では、ユーザ端末18の番号登録支援App40から、法定調書(支払調書)のデータをオンラインで行政サーバ16へ送信することとした。変形例として、ユーザ端末18の番号登録支援App40は、番号確認GW12から提供された法定調書を、ユーザ等が保有する所定のプリンタに印刷させてもよい。ユーザは、印刷された法定証書を、郵送等のオフラインで行政機関へ提出してもよい。
第3変形例として、個人情報保護処理の変形例を説明する。企業私書箱を開設した企業は、企業単位、個人単位等の任意の粒度で、予め定められた複数種類の個人情報保護のポリシー(パターン)の中から特定のポリシーを選択可能であってもよい。例えば、(1)所定期間の経過を条件として、企業私書箱に格納されたユーザの属性情報に対するアクセス権を剥奪すること、(2)所定期間の経過を条件として、企業私書箱に格納されたユーザの属性情報から個人番号部分を消去(非表示処理、マスク処理)すること、(3)所定期間の経過を条件として、企業私書箱に格納されたユーザの特定の個人情報(例えば氏名や住所等)部分を消去すること、の中から所望のポリシーを選択可能であってもよい。個人情報提供部80、個人情報消去部86、調書提供部84は、各企業により選択されたポリシーに応じて、各企業の企業私書箱に対する個人情報保護処理を実行してもよい。
企業では、マイナンバー法、個人情報保護法、税法等の法律毎に定められた書類保管期限の違いや罰則の違い等のために、マイナンバー法の対象からは外したいが、誰に、いつ、どのような報酬を支払ったかは把握しておきたいというケースがあり得る。また、重要な個人情報を保管したくはないが、これまでいくらの金銭を支払ってきたかは把握したいというケースがあり得る。第3変形例によると、企業毎に異なりうる情報保管のポリシーに柔軟に対応した付加価値の高いサービスを提供できる。
(第2実施形態)
第2実施形態の番号確認支援システム10の構成は第1実施形態(図1)と同様であり、第2実施形態のユーザ端末18の機能構成も第1実施形態(図2)と同様である。その一方、第2実施形態の企業A〜企業Cは、個人番号の本人確認や、支払調書の作成を番号確認GW12へ委託する。すなわち、第2実施形態の番号確認GW12は、個人番号の本人確認や支払調書の作成に関するデータ処理を自律的に実行する。
図6は、第2実施形態の番号確認GW12の機能構成を示すブロック図である。番号確認GW12は、本人確認状況保持部71、本人確認処理部88、確認完了通知部90、指示受付部92、調書作成部94、調書提出部96をさらに備える。その一方、第1実施形態の番号確認GW12と異なり、個人情報提供部80と調書受付部82を含まない。
図6に示すブロックのうち、第1実施形態で説明済のブロックと同一または対応するブロックには同一の符号を付している。以下、第1実施形態と重複する説明は適宜省略し、異なる点を主に説明する。
企業私書箱保持部68の企業私書箱は、ユーザの個人情報として、第1実施形態の写真データに代えて、通知カードが示すユーザの属性情報のテキストデータを保持する。ユーザの属性情報は典型的には、個人番号と、基本4情報と呼ばれる氏名、性別、生年月日、住所を含む。本人確認状況保持部71は、番号登録支援App40を利用する複数のユーザそれぞれの本人確認が完了したか否かを示す情報を保持する。具体的には、あるユーザの本人確認が問題なく完了した場合に、そのユーザのユーザIDと、本人確認完了を示す所定のフラグ(「本人確認済フラグ」と呼ぶ。)とを対応付けて記憶する。
個人情報記録部78は、申告情報受付部76により受信された申告情報が含む通知カードと身分証明書それぞれの画像データに対してOCR処理を実行し、通知カードをソースとする属性情報のテキストデータと、身分証明書をソースとする属性情報のテキストデータを読み込む。個人情報記録部78は、ユーザIDおよび申告先企業の識別情報に対応付けて、通知カードをソースとする属性情報のテキストデータと、身分証明書をソースとする属性情報のテキストデータの両方を本人確認処理部88に渡す。さらに個人情報記録部78は、通知カードをソースとする属性情報のテキストデータをユーザIDに対応付けて申告先企業の企業私書箱へ格納する。
なお第1実施形態と同様に、申告情報受付部76により受信された申告情報は、申告先指定データを含むが、開示データ(通知カードと身分証明書の画像データ)を含まない場合がある。この場合、個人情報記録部78は、第1実施形態と同様に、ユーザの属性情報が予め格納された企業私書箱から、今回の申告先企業の企業私書箱へユーザの属性情報をコピーする。そして個人情報記録部78は、ユーザIDおよび申告先企業の識別情報を本人確認処理部88へ渡す。
個人情報消去部86は、第1実施形態と同様に、企業私書箱保持部68に格納されたユーザの個人情報について、格納日時を参照して、企業私書箱保持部68に格納された期間を監視する。個人情報消去部86は、格納期間が所定の閾値以上になった個人情報を企業私書箱保持部68から消去する。
本人確認処理部88は、申告情報受付部76により受信された申告情報に基づいて、申告元ユーザの本人確認処理を自動的に実行する。本人確認処理部88は、本人確認状況保持部71を参照して申告情報が示すユーザIDに対して本人確認済フラグが未設定であれば本人確認処理を実行する。具体的には、本人確認処理部88は、個人情報記録部78から入力された、通知カードをソースとするユーザの属性情報と、身分証明書をソースとするユーザの属性情報とを比較、照合する。両者が一致する場合、本人確認処理部88は、本人確認に成功したと判定する。
本人確認に成功したと判定すると、本人確認処理部88は、ユーザIDと本人確認済フラグを対応づけて本人確認状況保持部71へ格納する。さらに本人確認処理部88は、ユーザIDと申告先企業の識別情報を確認完了通知部90へ渡し、本人確認の完了を申告先企業へ通知させる。変形例として、本人確認処理部88は、通知カードと身分証明書それぞれの画像データに含まれるユーザの顔写真を公知の手法でマッチングし、顔の特徴情報が一致することをさらなる条件として、本人確認に成功したと判定してもよい。
本人確認処理部88は、本人確認状況保持部71を参照して、申告情報が示すユーザIDに対して本人確認済フラグが設定済であれば本人確認処理をスキップする。この場合、典型的には個人情報記録部78からユーザIDと申告先企業の識別情報が入力される。本人確認処理部88は、本人確認処理を実行した場合と同様に、ユーザIDと申告先企業の識別情報を確認完了通知部90へ渡し、本人確認の完了を申告先企業へ通知させる。
なお、本人確認処理部88が本人確認を自動実行する構成に代えて、番号確認GW12のオペレータ等が、通知カードと身分証明書の画像データを目視比較して本人確認を実施してもよい。本人確認の実施者は、本人確認に成功したと判断すると、ユーザIDと本人確認済フラグを対応付けて本人確認状況保持部71へ記録し、また、ユーザIDと申告先企業の識別情報を確認完了通知部90へ渡すための所定の作業を実施してもよい。
確認完了通知部90は、ユーザの本人確認が完了したことを検出した場合に、ユーザの本人確認が完了した旨の情報(以下「本人確認完了通知」と呼ぶ。)を申告先の企業PC14aへ送信する。具体的には、確認完了通知部90は、本人確認処理部88からユーザIDと申告先企業の識別情報が入力された場合に、そのユーザIDを含む本人確認完了通知を、申告先企業の企業PC14へ送信する。このように、本人確認完了通知は、申告先企業が予めユーザに対して割当てたユーザIDを含む一方、通知カードが示すユーザの個人情報のうち少なくとも個人番号を含まない。
指示受付部92は、支払調書の作成を要求するデータ(以下「調書作成要求」と呼ぶ。)と、行政機関への支払調書の提出を要求するデータ(以下「調書提出要求」と呼ぶ。)を企業PC14から受け付ける。調書作成要求は、支払調書に設定すべき情報であり、ユーザへの金銭支払に関する情報(以下「金銭支払情報」と呼ぶ。)と、ユーザID、要求元企業の識別情報を含む。調書提出要求は、提出対象となる支払調書のIDを含む。調書作成要求(金銭支払情報)と調書提出要求はいずれもユーザの個人番号を含まない。
調書作成部94は、調書作成要求が示す企業の識別情報に基づいて要求元企業の企業私書箱を識別し、その企業私書箱に格納された個人情報のうち、調書作成要求が示すユーザIDに対応付けられた個人情報を取得する。調書作成部94は、調書作成要求が含む金銭支払情報と、企業私書箱から取得した個人情報のうち少なくとも個人番号を設定した支払調書のデータを生成し、支払調書IDを払い出す。調書作成部94は、支払調書の本文データ、支払調書ID、ユーザID、調書作成要求元企業の識別情報を対応付けて調書保持部70へ格納する。
調書提供部84は、第1実施形態と同様に支払調書をユーザ端末18へ提供し、第2実施形態ではさらに企業PC14へも提供する。具体的には、調書作成部94により支払調書のデータが調書保持部70へ格納された場合に、調書作成要求元企業の企業PC14へ、支払調書の内容を確認させるための確認データを支払調書IDとともに送信する。
調書提供部84は、調書保持部70に格納された支払調書のオリジナルデータを、ユーザの個人番号を非表示の態様へ変更したデータを確認データとして生成する。個人番号を非表示の態様とは、個人番号を削除、消去、隠蔽、排除した態様とも言える。調書提供部84は、支払調書のデータ(例えば画像データ)を含むウェブページを企業PC14へ送信してもよい。その場合、調書提供部84は、ページ内の個人番号表示領域に対して所定のマスク処理を施したウェブページを送信してもよい。
調書提供部84は、調書作成要求元企業による支払調書へのアクセス権、具体的にはユーザの個人番号が非表示に編集された支払調書確認データへのアクセス権を、そのアクセスが可能になってから一定期間経過後に無効にする。例えば調書提供部84は、支払調書を作成した旨、または確認データを閲覧可能である旨を調書作成要求元企業の企業PC14へ通知してもよい。そして、その通知から例えば2週間〜1ヶ月後に確認データへのアクセス権を削除し、また番号確認GW12に記憶された確認データを消去してもよい。
調書提出部96は、調書提出要求が受け付けられた場合に、調書保持部70に格納された支払調書のうち、調書提出要求が示す支払調書IDで特定される支払調書のデータを行政サーバ16へ送信する。例えば、ユーザ端末18の調書提出部56と同様に、行政サーバ16が公開するウェブサービスを利用して支払調書のデータを行政サーバ16へアップロードしてもよい。
以上の構成による番号確認支援システム10の動作を説明する。
図7は、第2実施形態の番号確認支援システム10の動作を示すシーケンス図である。ここでは、ユーザ端末18はスマートフォン18aとする。ユーザは、支払調書への設定が必要な個人番号を企業Aへ申告するために、本人確認書類として通知カードの写真と身分証明書の写真を提供する。図4の企業Aは企業PC14aに対応し、行政機関は行政サーバ16に対応する。図7のS50〜S55は、第1実施形態の番号確認支援システム10の動作(図4のS10〜S15)と同様である。
番号確認GW12の申告情報受付部76は、スマートフォン18aから送信された申告情報を受信する。個人情報記録部78は、受信された申告情報が含む写真データをOCR処理して、通知カードが示すユーザの属性情報を、ユーザIDと現在日時に対応づけて、企業Aに割当てられた企業私書箱へ格納する。本人確認処理部88は、OCR処理で取得された通知カードが示すユーザの属性情報と、身分証明書が示すユーザの属性情報とを照合して本人確認の成否を判定する(S56)。本人確認に成功したと判定すると、本人確認処理部88は、ユーザに対する本人確認済フラグを設定し、確認完了通知部90は、本人確認完了通知を企業PC14aへ送信する(S57)。
その後、企業Aからユーザへ報酬が支払われる。企業Aの担当者は、報酬支払の事実を示すデータである金銭支払情報(ユーザの個人番号を含まない)を企業PC14aで作成する。企業Aの担当者は、企業PC14aを操作して、番号確認GW12の企業向けウェブサイトへログインする(S58)。企業Aの担当者は、番号確認GW12の企業向けウェブページを介して、ユーザIDと金銭支払情報を含む調書作成要求を企業PC14aから番号確認GW12へ送信させる(S59)。番号確認GW12の調書作成部94は、調書作成要求に応じて支払調書を作成し、企業Aの企業私書箱に格納されたユーザの個人番号をその支払調書内に設定する(S60)。
調書提供部84は、調書作成部94により作成された支払調書の確認画面であり、ユーザの個人番号を非表示に設定した確認画面のデータを企業PC14aへ送信して表示させる(S61)。企業Aの担当者は確認画面を見て、行政機関への提出を指示する操作を確認画面へ入力する。この操作に応じて、企業PC14aは、確認画面で表示された支払調書のIDを含む調書提出要求を番号確認GW12へ送信する(S62)。番号確認GW12の調書提出部96は、調書提出要求が示すIDで特定される支払調書であり、ユーザの個人番号が設定された支払調書のデータを行政サーバ16へ送信する(S63)。
図7のS64〜S66は、第1実施形態の番号確認支援システム10の動作(図4のS23、S24、S26)と同様である。所定期間が経過すると、番号確認GW12は個人情報保護のためのデータ処理を実行する(S67)。具体的には、調書提供部84は、支払調書の確認データに対する企業Aのアクセス権を削除し、また、調書保持部70に格納された支払調書に対するユーザのアクセス権を削除する。個人情報消去部86は、企業Aの企業私書箱に格納されたユーザの個人情報を消去する。
図8は、図7に続く番号確認支援システム10の動作を示すシーケンス図である。ここでは、企業Aへ個人情報を申告済のユーザが、後日、企業Bの仕事を請け負うこととなり、企業Bへ個人情報を新たに申告することを想定する。図5の企業Bは企業PC14bに対応する。図8のS70〜S74は、第1実施形態の番号確認支援システム10の動作(図5のS30〜S34)と同様である。S74でスマートフォン18aから番号確認GW12へ送信される申告情報は、申告先の企業Bを指定するデータとユーザIDを含むが、通知カードと身分証明書の写真データを含まない。
番号確認GW12の個人情報記録部78は、ユーザIDにより特定される個人情報であり、この例では企業Aの企業私書箱に格納済であるユーザの属性情報をユーザIDと現在日時に対応付けて、企業Bの企業私書箱へコピーする(S75)。ユーザの本人確認が完了済(すなわちユーザに本人確認済フラグが設定済)であるため、本人確認処理部88は、ユーザの本人確認処理をスキップし、確認完了通知部90は、本人確認完了通知を企業PC14bへ送信する(S76)。その後、企業Bからユーザへ報酬が支払われる。以降のS77〜S86は、報酬支払元が企業Aの場合の動作、すなわち図7のS58〜S67と同様である。
このように第2実施形態の番号確認GW12およびユーザ端末18(特に番号登録支援App40)によると、第1実施形態と同様の効果を奏する。例えばユーザは、通知カード等を一度撮影し、その写真等の個人情報を一旦いずれかの企業へ申告すれば、別の企業へ個人情報を申告する際に再度通知カード等を撮影することが不要になる。例えば、番号登録支援App40の申告先選択画面で上記別の企業を選択するだけで、その企業への個人情報(個人番号)の申告が完了する。これにより、クラウドソーシング等の進展に伴って、個人情報の申告先、言い換えれば、個人番号の告知先が増加する場合にも、ユーザの負担増加を抑制できる。
また第2実施形態では、企業は、本人確認書類の収集、本人確認の実施、法定調書の作成および提出を番号確認GW12へアウトソーシングできる。これにより、クラウドソーシング等の進展に伴って、給与や報酬の支払対象となる個人が増加する場合にも企業の負担増加を抑制できる。さらに第2実施形態では、ユーザの個人番号の保管主体は番号確認GW12となり、ユーザの個人番号は企業側へ開示されない。これにより、厳重な管理が求められ、漏洩が許されない個人番号を企業が保管することが不要になり、企業の負担を一層低減できる。
以上、本発明を第2実施形態をもとに説明した。この実施の形態は例示であり、各構成要素や各処理プロセスの組合せにいろいろな変形例が可能なこと、またそうした変形例も本発明の範囲にあることは当業者に理解されるところである。
上述した実施の形態および変形例の任意の組み合わせもまた本発明の実施の形態として有用である。組み合わせによって生じる新たな実施の形態は、組み合わされる実施の形態および変形例それぞれの効果をあわせもつ。また、請求項に記載の各構成要件が果たすべき機能は、実施の形態および変形例において示された各構成要素の単体もしくはそれらの連携によって実現されることも当業者には理解されるところである。