JP2017068778A - 情報処理装置 - Google Patents

Abstract

【課題】給与や報酬の支払者に対する効率的な個人番号の申告を支援する。【解決手段】スマートフォン１８ａは、ユーザの個人情報を含む開示データと、その個人情報の申告先となる企業Ａを指定する指定データを含む申告情報を番号確認ＧＷ１２へ送信する。番号確認ＧＷ１２は、ユーザの個人情報を記憶し、その個人情報を企業ＰＣ１４ａへ送信する。ユーザの個人情報を企業Ｂへ申告する必要が生じた場合に、スマートフォン１８ａは、個人情報の申告先となる企業Ｂを指定する指定データを含むが上記開示データを含まない申告情報を番号確認ＧＷ１２へ送信する。番号確認ＧＷ１２は、予め記憶したユーザの個人情報を企業ＰＣ１４ｂへ送信する。【選択図】図１

Description

この発明は、データ処理技術に関し、特に情報処理装置に関する。

平成２７年の１０月から、国民１人１人にマイナンバー（登録商標）が付与される予定である。予定では、マイナンバーは１２桁の数字から構成され、原則として、一生変更されないＩＤである。また、平成２８年から、社会保障、税、災害対策等の行政手続においてマイナンバーが必要となる予定である（例えば特許文献１参照）。マイナンバー制度の施行に伴い、金銭の受け取りや支払が発生するサービスを顧客へ提供する金融機関等の企業は、顧客のマイナンバーを取得する必要がある。

特開２０１５−７９４０６号公報

源泉徴収は、企業等が給与や報酬を支払う際にそれから所得税等を差し引いて行政機関に納付する制度であり、主に個人への支払が対象になる。給与や報酬の支払者は、源泉徴収票を作成する必要があるが、今後、支払を受ける個人のマイナンバーを源泉徴収票に設定することが求められる。これに伴い、マイナンバーを含む従業員の個人情報の収集や確認等のために企業に多大なコストが発生しうる。また、個人にとっても自身の個人情報の申告先が増加するほど負担も増大する。

本発明は、上記課題を鑑みてなされたものであり、主たる目的は、給与や報酬の支払者に対する個人情報の効率的な申告を支援することである。

上記課題を解決するために、本発明のある態様の情報処理装置は、通信網を介して、企業の装置と、ユーザの端末とに接続される情報処理装置であって、ユーザの個人情報を含む開示データと、その個人情報の申告先となる第１の企業を指定する指定データを含む情報をユーザの端末から受け付ける申告情報受付部と、申告情報受付部により受け付けられたユーザの個人情報を記憶する個人情報記憶部と、ユーザの個人情報を第１の企業の装置へ提供する個人情報提供部とを備える。申告情報受付部が、個人情報の申告先となる第２の企業を指定する指定データを含むが、開示データを含まない情報をユーザの端末から受け付けた場合、個人情報提供部は、個人情報記憶部に予め記憶されたユーザの個人情報を第２の企業の装置へ提供する。

本発明の別の態様もまた、情報処理装置である。この装置は、通信網を介して、企業の装置と、ユーザの端末とに接続される情報処理装置であって、ユーザの個人情報を含む開示データと、その個人情報の申告先となる第１の企業の指定する指定データを含む情報をユーザの端末から受け付ける申告情報受付部と、申告情報受付部により受け付けられたユーザの個人情報を記憶する個人情報記憶部と、ユーザの個人情報に基づく本人確認が完了したことを検出した場合に、ユーザの本人確認が完了したことを示す情報を第１の企業の装置へ提供する確認完了通知部とを備える。申告情報受付部が、個人情報の申告先となる第２の企業を指定する指定データを含むが、開示データを含まない情報をユーザの端末から受け付けた場合、確認完了通知部は、ユーザの個人情報に基づく本人確認が完了済であれば、ユーザの本人確認が完了したことを示す情報を第２の企業の装置へ提供する。

本発明のさらに別の態様はコンピュータプログラムである。このコンピュータプログラムは、個人情報の申告先の候補として複数の企業の情報を保持する機能と、ユーザの個人情報を含む開示データの入力を受け付ける機能と、複数の企業の中からユーザの個人情報の申告先となる第１の企業の選択を受け付ける機能と、第１の企業を指定するデータと開示データを含む申告情報を外部のサーバへ送信することにより、ユーザの個人情報をサーバから第１の企業へ提供させる申告情報送信機能とをコンピュータに実現させる。申告情報をサーバへ送信後に、個人情報の新たな申告先となる第２の企業が選択された場合、申告情報送信機能は、第２の企業を指定するデータを含むが、開示データを含まない申告情報をサーバへ送信し、サーバから第１の企業へ提供されたユーザの個人情報をサーバから第２の企業へ提供させる。

本発明のさらに別の態様もコンピュータプログラムである。このコンピュータプログラムは、個人情報の申告先の候補として複数の企業の情報を保持する機能と、ユーザの個人情報を含む開示データの入力を受け付ける機能と、複数の企業の中からユーザの個人情報の申告先となる第１の企業の選択を受け付ける機能と、第１の企業を指定するデータと開示データを含む申告情報を外部のサーバへ送信することにより、ユーザの本人確認が完了したことを示す情報をサーバから第１の企業へ提供させる申告情報送信機能とをコンピュータに実現させる。申告情報をサーバへ送信後に、個人情報の新たな申告先となる第２の企業が選択された場合、申告情報送信機能は、第２の企業を指定するデータを含むが、開示データを含まない申告情報をサーバへ送信し、ユーザの本人確認が完了したことを示す情報をサーバから第２の企業へ提供させる。

なお、以上の構成要素の任意の組合せ、本発明の表現を、装置、方法、システム、コンピュータプログラム、コンピュータプログラムを格納した記録媒体などの間で変換したものもまた、本発明の態様として有効である。

本発明によれば、給与や報酬の支払者に対する個人情報の効率的な申告を支援することができる。

第１実施形態の番号確認支援システムの構成を示す図である。 図１のユーザ端末の機能構成を示すブロック図である。 図１の番号確認ＧＷの機能構成を示すブロック図である。 第１実施形態の番号確認支援システムの動作を示すシーケンス図である。 図４に続く番号確認支援システムの動作を示すシーケンス図である。 第２実施形態の番号確認ＧＷの機能構成を示すブロック図である。 第２実施形態の番号確認支援システムの動作を示すシーケンス図である。 図７に続く番号確認支援システムの動作を示すシーケンス図である。

まず概要を説明する。企業は今後、報酬の支払に伴って作成すべき法定調書に、報酬を受け取る個人のマイナンバー（以下「個人番号」と呼ぶ。）を設定する必要があり、そのために個人番号の本人確認を行う必要がある。本人確認は、個人番号を提示する個人がその本人であることの確認と、個人番号が本人に通知された個人番号と一致することの確認の両方を含む。前者は、個人番号を提示する個人の本人性確認・身元確認と言え、後者は、個人番号の真正性確認・番号確認と言える。

ところで現在、知的生産力やコンテンツ等を、多数の人々から調達・集約し、事業成果を得ることを目的としたクラウドソーシングが普及しつつある。クラウドソーシングの普及等により、企業は、比較的少額の報酬を、従来より多くの個人に、従来より高い頻度で支払うようになっていくことが考えられる。また、報酬支払先の個人は、固定的な従業員とは異なり、都度変化するかもしれない。したがって、多くの個人の個人番号を収集するために企業には多大なコストが発生しうる。

クラウドソーシングの普及は、個人にとっても給与や報酬の支払元の増加につながり、個人番号を含む個人情報を多くの支払元へ申告する必要が生じると想定され、個人の負担も増大しうる。

第１および第２の実施の形態（以下「第１実施形態」等と呼ぶ。）の情報処理システムは、給与や報酬の受取主体にとって効率的な個人情報の申告を支援すること、また、給与や報酬の支払主体にとって効率的な個人情報の収集を支援することを目的とする。具体的には、クラウドソーシングにおける個人情報の申告と、法定調書の提出を支援するＳａａＳ（Software as a Service）を実現する。法定調書は、金銭支払先個人の個人番号等、金銭支払に関する事実を記載して公的機関へ提出すべき文書であり、例えば源泉徴収票や支払調書を含む。以下では支払調書を例に説明する。

各実施形態特有の特徴は以下の通りである。
第１実施形態：個人情報（個人番号）の確認書類や法定調書をＳａａＳ経由で電子的に送信する。すなわち個人情報等の中継処理をメインとする。
第２実施形態：個人情報（個人番号）の確認書類に基づく本人確認や、法定調書の作成・提出をＳａａＳ側で実行する。いわゆるＢＰＯ（Business Process Outsourcing）サービスを提供する。

以下の説明において、通知カードは、行政機関から個人に送付されたカードであり、個人番号、氏名、住所、性別、生年月日等が券面に印刷されたものである。なお、通知カードに代えて、行政機関が個人に対して発行する身分証明書である個人番号カードが使用されてもよい。

（第１実施形態）
図１は、第１実施形態の番号確認支援システム１０の構成を示す。番号確認支援システム１０は、番号確認ＧＷ１２、企業ＰＣ１４で総称される企業ＰＣ１４ａ、企業ＰＣ１４ｂ、企業ＰＣ１４ｃ、行政サーバ１６、ユーザ端末１８で総称されるスマートフォン１８ａ、タブレット端末１８ｂ、ＰＣ１８ｃを備える。

ユーザ端末１８は、自身の個人番号を含む個人情報を給与や報酬の支払元企業に対して申告すべき個人（企業の従業員とも言え、以下「ユーザ」とも呼ぶ。）により操作される情報処理装置である。ユーザ端末１８は、各種メッセージの表示や、ユーザが入力した情報を読み込む等、ユーザとのインタフェース機能を提供する。図１に示すようにユーザ端末１８は、スマートフォン、タブレット端末、ＰＣ等を含むがこれらには限定されない。ユーザ端末１８の詳細な機能は図２に関連して後述する。

企業ＰＣ１４は、ユーザに対して給与や報酬を支払う企業の担当者により操作される情報処理装置である。もちろんＰＣには限定されず、スマートフォンやタブレット端末、サーバ等であってもよい。行政サーバ１６は、国税庁（税務署）や自治体、年金機構等の行政機関が保持する情報処理装置である。行政サーバ１６は、支払調書等、法定調書の提出先として機能し、法定調書のデータをオンラインで受け付ける。

番号確認ＧＷ１２は、企業Ａ〜企業Ｃに対して、被雇用者であるユーザの個人情報（個人番号を含む）の収集支援サービスを提供する情報処理装置である。番号確認ＧＷ１２は、本来は企業Ａ〜企業Ｃが個別に実施すべき被雇用者の個人情報の収集業務を一括して代行するプラットフォーム、またゲートウェイとなる装置である。番号確認ＧＷ１２は、個人情報収集サービスを提供する業者が管理する装置であってもよい。

第１実施形態の企業Ａ〜企業Ｃは、番号確認ＧＷ１２を利用して被雇用者の個人番号を取得する。ただし、個人番号の本人確認や、ユーザへの金銭の支払に関する支払調書の作成は各社で実施する。第１実施形態の番号確認ＧＷ１２は、個人番号を含む本人確認書類や、支払調書等の情報連携を主に実行する。

図１の各装置は、インターネットや専用線網等を含む公知の通信網１９を介して接続される。また図１の各装置（例えば企業ＰＣ１４や行政サーバ１６）は、物理的に複数の装置により構成されてもよいことはもちろんである。

図２は、図１のユーザ端末１８の機能構成を示すブロック図である。ユーザ端末１８は、ＬＣＤ２０、カメラ２２、制御部２４、記憶部２６、通信部２８を備える。本明細書のブロック図において示される各ブロックは、ハードウェア的には、コンピュータのＣＰＵをはじめとする素子や機械装置で実現でき、ソフトウェア的にはコンピュータプログラム等によって実現されるが、ここでは、それらの連携によって実現される機能ブロックを描いている。したがって、これらの機能ブロックはハードウェア、ソフトウェアの組合せによっていろいろなかたちで実現できることは、当業者には理解されるところである。

例えば、制御部２４内の複数のブロックに対応する複数のモジュールを含むコンピュータプログラムがＤＶＤ等の記録媒体に格納され、ユーザ端末１８にインストールされてもよい。そしてユーザ端末１８のプロセッサ（ＣＰＵ等）が、ストレージに格納されたコンピュータプログラムをメインメモリに読出して実行することで、各ブロックの機能が発揮されてもよい。記憶部２６は、ユーザ端末１８のストレージやメモリがデータを記憶することで実現されてよい。図３に関連して後述する番号確認ＧＷ１２も同様である。

ＬＣＤ２０は、種々の電子コンテンツを表示する液晶ディスプレイである。カメラ２２は、ユーザの操作に応じて写真を撮影する撮像装置である。第１実施形態のＬＣＤ２０は、ユーザ端末１８の筐体と一体化されており、また、タッチパネルの機能を有し、情報入力手段でもある。ＬＣＤ２０やカメラ２２は外付けの装置であってもよく、またＬＣＤ２０とは別に情報入力手段が設けられてもよい。

制御部２４は、各種データ処理を実行する。記憶部２６は、制御部２４により参照、更新されるデータを記憶する記憶領域である。通信部２８は、所定の通信プロトコルにしたがって外部装置と通信する。例えば制御部２４は、通信部２８を介して、番号確認ＧＷ１２とデータを送受する。

記憶部２６は、申告先候補保持部３０、個人情報保持部３２、調書保持部３４を含む。申告先候補保持部３０は、個人情報の申告先候補となる複数の企業に関する情報を保持する。具体的には、申告先候補となる複数の企業の識別情報を含む企業リストを保持する。個人情報保持部３２は、ユーザの個人情報を一時的に保持する。具体的には個人情報保持部３２は、ユーザの個人情報を含むデータであり、例えば通知カードの券面を撮影した写真データ（画像データとも言える）と、身分証明書の券面を撮影した写真データを保持する。

調書保持部３４は、番号確認ＧＷ１２から提供された法定調書のデータであり、第１実施形態では支払調書のデータを保持する。なお、後述の番号登録支援Ａｐｐ４０がユーザ端末１へインストールされる際に、ユーザ端末１８の記憶部２６に、申告先候補保持部３０、個人情報保持部３２、調書保持部３４が設定されてもよい。

制御部２４は、操作検出部３６と表示制御部３８を備える。さらに制御部２４は、番号登録支援アプリケーション（以下「番号登録支援Ａｐｐ４０」と呼ぶ。）のプログラムモジュールとして実装されるアプリ画面表示部４２、個人情報記録部４４、申告先取得部４６、申告情報送信部４８、個人情報消去部５０、申告先候補更新部５２、調書取得部５４、調書提出部５６を備える。

操作検出部３６は、ユーザがＬＣＤ２０に対して入力した操作を検出し、操作内容を示す情報を他の機能ブロックへ通知する。表示制御部３８は、ＬＣＤ２０による電子コンテンツの表示を制御する。例えば表示制御部３８は、アプリ画面表示部４２の指示に応じて、番号登録支援Ａｐｐ４０の各種画面をＬＣＤ２０に表示させる。

アプリ画面表示部４２は、番号登録支援Ａｐｐ４０の画面のデータを、表示制御部３８を介してＬＣＤ２０に表示させる。番号登録支援Ａｐｐ４０の画面は、ユーザに通知カードの撮影を指示する撮影指示画面、ユーザに個人情報の申告先を選択させる申告先選択画面、支払調書の内容をユーザに提示する調書提示画面を含む。

アプリ画面表示部４２は、申告先候補保持部３０に保持された申告先候補の企業リストを取得し、申告先とする企業をユーザが選択可能な態様で企業リストを申告先選択画面に表示させる。また、後述する申告済フラグがオンの場合、アプリ画面表示部４２は、撮影指示画面の表示をスキップして、申告先選択画面を表示させる。

個人情報記録部４４は、ユーザの操作によりユーザ端末１８に入力されたユーザの個人情報を受け付けて個人情報保持部３２へ格納する。具体的には個人情報記録部４４は、カメラ２２により撮像されたユーザの通知カードの写真データと、身分証明書（運転免許証等）の写真データを個人情報保持部３２へ格納する。申告先取得部４６は、申告先選択画面で特定の企業が申告先として選択された場合に、その特定の企業を申告先企業として取得する。

申告情報送信部４８は、申告先選択画面で特定の企業が申告先として選択された場合に、選択された企業宛の申告情報をユーザＩＤと対応づけて番号確認ＧＷ１２へ送信する。この申告情報は、申告先企業の識別情報を含む申告先指定データと、個人情報保持部３２に保持された通知カードおよび身分証明書の写真データを含む。

なお第１実施形態では、企業が、本人確認書類の送付をユーザへ依頼する際に、その企業がユーザに割当てたユーザＩＤをあわせてユーザへ通知することとする。ユーザＩＤは、企業が作成する支払調書とユーザとの紐付け用の識別子と言え、ユーザ端末１８のメールアドレスや電話番号等の連絡用識別子を使用してもよい。ユーザは、企業から通知されたユーザＩＤを番号登録支援Ａｐｐ４０へ登録する。

申告情報送信部４８は、番号確認ＧＷ１２への申告情報の送信が正常に完了した場合に、記憶部２６に記憶されたデータであり、個人情報を番号確認ＧＷ１２へアップロード済であることを示す申告済フラグ（初期値はオフ）をオンに設定する。申告情報送信部４８は、申告済フラグがオンの場合、申告先指定データを含むが、通知カードおよび身分証明書の写真データを含まない申告情報を番号確認ＧＷ１２へ送信する。

個人情報消去部５０は、申告情報送信部４８による番号確認ＧＷ１２への申告情報の送信が正常に完了した場合に、個人情報保持部３２に保持された通知カードおよび身分証明書の写真データを消去する。これにより、ユーザ端末１８からユーザの個人情報が漏洩するリスクを低減する。

申告先候補更新部５２は、申告先候補保持部３０に保持された申告先候補の企業リストを更新する。具体的には、申告先候補の新たな企業リストが番号確認ＧＷ１２から配信された場合に、それまでの企業リストを新たな企業リストへ更新する。なお、番号確認ＧＷ１２により作成された新たなリストを、インターネット上のアプリストアのウェブサイトを介して取得してもよいことはもちろんである。

調書取得部５４は、番号確認ＧＷ１２から提供された支払調書のデータを受け付けて調書保持部３４へ格納する。調書提出部５６は、調書提示画面に対して調書提出操作が入力された場合に、調書提示画面で表示中の支払調書のデータを行政サーバ１６へ送信する。例えば調書提出部５６は、行政サーバ１６に予め設けられた調書提出用のウェブサービスを、支払調書のデータを引数として呼び出すことにより、支払調書のデータを行政サーバ１６へアップロードしてもよい。

図３は、図１の番号確認ＧＷ１２の機能構成を示すブロック図である。番号確認ＧＷ１２は、制御部６０、記憶部６２、通信部６４を備える。これらのブロックは、ユーザ端末１８の制御部２４、記憶部２６、通信部２８に対応する。

記憶部６２は、申告先候補保持部６６、企業私書箱保持部６８、調書保持部７０を含む。申告先候補保持部６６は、ユーザの個人情報の申告先候補となる複数の企業に関する情報を保持する。具体的には、申告先候補となる複数の企業の識別情報を含む企業リストを保持する。調書保持部７０は、企業ＰＣ１４から提供された法定調書のデータ、第１実施形態では支払調書のデータをユーザＩＤと対応づけて保持する。

企業私書箱保持部６８は、番号確認ＧＷ１２を利用する企業の私書箱に相当する記憶領域（以下「企業私書箱」と呼ぶ。）を保持し、複数の企業に対応する複数の企業私書箱を保持する。企業私書箱保持部６８は、ある企業に割当てられた企業私書箱において、その企業宛に申告されたユーザの個人情報を記憶する。具体的には企業私書箱保持部６８は、通知カードの写真データおよび身分証明書の写真データを、ユーザＩＤおよびデータ格納日時と対応づけて保持する。企業私書箱保持部６８は、ユーザの個人情報を記憶する個人情報保持部とも言える。

制御部６０は、企業登録部７２、申告先候補配信部７４、申告情報受付部７６、個人情報記録部７８、個人情報提供部８０、調書受付部８２、調書提供部８４、個人情報消去部８６を含む。

企業登録部７２は、番号確認ＧＷ１２による個人情報収集サービスの利用を開始するための利用登録として、企業私書箱の開設要求を企業ＰＣ１４から受け付ける。企業登録部７２は、企業私書箱の開設要求に応じて、要求元企業の識別情報（企業名等）を申告先候補保持部６６に保持された申告先候補の企業リストへ追加する。

また企業登録部７２は、企業私書箱の開設要求に応じて、要求元企業用の企業私書箱を企業私書箱保持部６８に新たに設定する。例えば企業登録部７２は、ユーザの個人情報が格納される企業私書箱保持部６８のディレクトリ配下に、要求元企業用のディレクトリを企業私書箱として新規に作成してもよい。そして、要求元企業の識別情報と、企業私書箱のパス名との対応関係を記録することにより、複数の企業（例えば企業Ａ〜Ｃ）それぞれの企業私書箱を識別可能にしてもよい。

申告先候補配信部７４は、申告先候補保持部６６に保持された申告先候補の企業リストが更新された場合に、更新後の最新の企業リストを、番号登録支援Ａｐｐ４０をインストール済のユーザ端末１８へ送信する。インターネット上のアプリストアへアップロードし、アプリストアを介して最新の企業リストをユーザ端末１８へ送信してもよい。

申告情報受付部７６は、ユーザ端末１８から送信されたユーザＩＤと申告情報を受け付ける。個人情報記録部７８は、申告情報受付部７６が受け付けた申告情報にユーザの個人情報を示す開示データ（第１実施形態では通知カードの写真データおよび身分証明書の写真データ）が含まれる場合、その開示データをユーザＩＤに対応付けて企業私書箱保持部６８へ格納する。個人情報記録部７８は、企業私書箱保持部６８に設定された複数の企業私書箱のうち、申告情報に含まれる申告先指定データが示す企業の企業私書箱へ開示データを格納する。

申告情報受付部７６が受け付けた申告情報に開示データが含まれない場合、個人情報記録部７８は、企業私書箱保持部６８に予め保持された開示データの中から、申告情報が示すユーザＩＤに対応付けられた開示データを検索する。申告情報が示すユーザＩＤに対応付けられた開示データが存在すれば、個人情報記録部７８は、その開示データを、申告先指定データが示す企業の企業私書箱へ格納する。これにより、例えば事前に企業Ａへ提供したユーザの開示データを、企業Ｂへ提供することを可能にする。なお個人情報記録部７８は、開示データをＯＣＲ（Optical Character Recognition）処理して、ユーザの個人番号や氏名、住所等のテキストデータを企業私書箱に格納してもよい。

記憶部６２には、複数の企業の識別情報（企業Ａ〜企業Ｃ）と、複数の企業ＰＣ１４の識別情報（企業ＰＣ１４ａ〜企業ＰＣ１４ｃのメールアドレス等）との対応関係が予め格納される。個人情報提供部８０は、申告情報が受け付けられた場合に、ユーザの個人情報を保管した旨を申告先企業の企業ＰＣ１４へ通知する。例えば、申告情報が示すユーザＩＤと、通知カードおよび身分証明書の写真を保管した旨のメッセージを含む電子メールを申告先企業の企業ＰＣ１４へ送信する。

個人情報提供部８０は、企業ＰＣ１４からのログインを受け付けると、ログインした企業を申告先とする個人情報を企業ＰＣ１４へ提供する。具体的には個人情報提供部８０は、ログインした企業の企業私書箱に格納された通知カードの写真データ、身分証明書の写真データ、ユーザＩＤを取得し、それらのデータを企業ＰＣ１４へ送信する。それらのデータを含むウェブページを企業ＰＣ１４へ送信して表示させてもよい。

個人情報提供部８０は、各企業によるユーザの個人情報（通知カードおよび身分証明書の写真）へのアクセス権を、そのアクセスが可能になってから、または、企業ＰＣ１４に対して写真の保管を通知してから一定期間経過後に無効にする。言い換えれば、一定期間経過後は、ユーザにより指定された申告先企業であっても、ユーザの個人情報の取得や閲覧を禁止する。この期間は、例えば２週間〜１ヶ月であってもよく、国の指針や企業等のセキュリティポリシに応じて決定されてよい。

調書受付部８２は、企業側で作成された支払調書のデータをユーザＩＤとともに企業ＰＣ１４から受け付ける。調書受付部８２は、受け付けた支払調書のデータをユーザＩＤに対応付けて調書保持部７０へ格納する。

記憶部６２には、ユーザＩＤとユーザ端末１８（例えばメールアドレス等）との対応関係が予め格納される。この対応関係はユーザ端末１８から事前に登録されてよい。調書提供部８４は、新たな支払調書のデータが調書保持部７０に格納された場合に、そのデータに対応付けられたユーザＩＤで特定されるユーザ端末１８へ支払調書の完成を通知する。例えば、支払調書の作成が完成した旨の電子メールを、ユーザＩＤに対応するユーザ端末１８へ送信してもよい。

調書提供部８４は、支払調書ダウンロード用ウェブページをユーザ端末１８へ提供する。ユーザはユーザＩＤを入力してこのウェブページにログインする。調書提供部８４は、支払調書ダウンロード用ウェブページでダウンロードが要求されると、ログイン時に入力されたユーザＩＤに対応付けられた支払調書のデータを調書保持部７０から取得し、そのデータをユーザ端末１８へ送信する。

調書提供部８４は、ユーザによる支払調書へのアクセス権を、そのアクセスが可能になってから、または、ユーザ端末１８に対して支払調書の完成を通知してから一定期間経過後に無効にする。言い換えれば、一定期間経過後は、ユーザによる支払調書のダウンロードを禁止する。この期間は、例えば２週間〜１ヶ月であってもよく、国の指針や企業等のセキュリティポリシに応じて決定されてよい。

個人情報消去部８６は、企業私書箱保持部６８に格納されたユーザの個人情報（通知カードおよび身分証明書の写真）について、格納日時を参照して、企業私書箱保持部６８に格納された期間を監視する。個人情報消去部８６は、格納期間が所定の閾値以上になった個人情報を企業私書箱保持部６８から消去する。この閾値は、例えば１年〜２年であってもよく、国の指針や企業等のセキュリティポリシに応じて決定されてよい。

個人情報消去部８６は、個人情報を消去したユーザＩＤにより特定されるユーザ端末１８へ、写真の再アップロードを促す所定の通知を送信してもよい。この通知を受け付けたユーザ端末１８の申告情報送信部４８は、記憶部２６の申告済フラグをオンからオフに切り替えてもよい。これにより、新たな申告時にはユーザ端末１８で撮影指示画面が表示される。また、番号確認ＧＷ１２の申告情報受付部７６は、開示データを含まない申告情報を受け付けた場合に、そのユーザの個人情報が企業私書箱保持部６８に存在しなければ（すなわち消去済であれば）、写真の再撮影とアップロードを促すメッセージをユーザ端末１８へ返信して表示させてもよい。

以上の構成による番号確認支援システム１０の動作を説明する。
図４は、第１実施形態の番号確認支援システム１０の動作を示すシーケンス図である。ここでは、ユーザ端末１８はスマートフォン１８ａとする。ユーザは、支払調書への設定が必要な個人番号を企業Ａへ申告するために、本人確認書類として通知カードの写真と身分証明書の写真を企業Ａへ提供する。図４の企業Ａは企業ＰＣ１４ａに対応し、行政機関は行政サーバ１６に対応する。

まず、企業ＰＣ１４ａは、自社の企業私書箱の開設を番号確認ＧＷ１２に要求する（Ｓ１０）。番号確認ＧＷ１２の企業登録部７２は、企業Ａの情報を申告先候補の企業リストへ追加するともに、企業Ａ用の企業私書箱を企業私書箱保持部６８に設定する。企業ＰＣ１４ａは、番号登録支援Ａｐｐ４０による本人確認書類の送付を依頼する内容の電子メールであり、企業Ａが定めたユーザＩＤを通知する電子メールをスマートフォン１８ａへ送信する（Ｓ１１）。

ユーザは、スマートフォン１８ａを操作して、所定のアプリストアから番号登録支援Ａｐｐ４０をダウンロードし、スマートフォン１８ａへインストールする（Ｓ１２）。ユーザは、スマートフォン１８ａで番号登録支援Ａｐｐ４０を起動し、個人情報申告メニューを選択する。申告済フラグがオフであるため、スマートフォン１８ａのアプリ画面表示部４２は撮影指示画面を表示させる。ユーザが通知カードと身分証明書をスマートフォン１８ａのカメラ２２で撮影すると、スマートフォン１８ａの個人情報記録部４４は、それらの写真データを個人情報保持部３２に格納する（Ｓ１３）。

次にアプリ画面表示部４２は申告先選択画面を表示させる。ユーザは個人情報の申告先であり、写真の送付先となる企業Ａを選択する（Ｓ１４）。申告情報送信部４８は、企業Ａを指定するデータ、写真データ、ユーザＩＤを含む申告情報を番号確認ＧＷ１２へ送信する（Ｓ１５）。送信完了後、申告情報送信部４８は申告済フラグをオンに切り替え、個人情報消去部５０は、個人情報保持部３２に格納された写真データを消去する。

番号確認ＧＷ１２の申告情報受付部７６は、スマートフォン１８ａから送信された申告情報を受信する。個人情報記録部７８は、受信された申告情報が含む写真データを、ユーザＩＤと現在日時に対応付けて、企業Ａに割当てられた企業私書箱へ格納する（Ｓ１６）。個人情報提供部８０は、受信された申告情報に含まれるユーザＩＤを提示する電子メールであり、ユーザの個人情報を保管した旨の電子メールを企業ＰＣ１４ａへ送信する（Ｓ１７）。

企業Ａの担当者は、企業ＰＣ１４ａを操作して番号確認ＧＷ１２の企業向けウェブサイトへログインする（Ｓ１８）。企業Ａの担当者は、番号確認ＧＷ１２の企業向けウェブページに、電子メールにて通知されたユーザＩＤを入力する。この操作に応じて、企業ＰＣ１４ａは、そのユーザＩＤを指定した個人情報閲覧要求を番号確認ＧＷ１２へ送信する。番号確認ＧＷ１２の個人情報提供部８０は、個人情報閲覧要求で指定されたユーザＩＤにより特定される写真データを企業Ａに割当てられた企業私書箱から検索する。

指定されたユーザＩＤに対応付けられた写真データが存在すれば、個人情報提供部８０はその写真データ（すなわち通知カードと身分証明書の画像）を含むウェブページを企業ＰＣ１４ａへ送信して表示させる（Ｓ１９）。なお、番号確認ＧＷ１２は、企業Ａを申告先とする複数のユーザの個人情報を集約したデータであり、例えばＯＣＲ処理で読み込んだ複数のユーザの個人番号を含むＣＳＶファイルを企業ＰＣ１４ａに送信してもよい。このように、企業ＰＣ１４ａは、自社宛の複数のユーザの個人情報を一括ダウンロードしてもよい。

企業Ａの担当者は、ウェブページに表示されたユーザの個人情報に基づいて、ユーザの本人確認を実施する。例えば、通知カードの画像と身分証明書の画像を参照して、ユーザの本人性確認と個人番号の真正性確認を実施してもよい。本人確認が終了すると、企業Ａの担当者は、ユーザの個人情報を企業Ａの不図示のシステムへ入力し、記憶させる（Ｓ２０）。例えば、ユーザの個人番号をユーザＩＤと対応づけて自社のシステム（被雇用者の個人番号を登録すべきデータベース等）へ登録してもよい。

その後、企業Ａからユーザへ報酬が支払われる。企業Ａの担当者は、企業ＰＣ１４ａにてユーザの個人情報（特に個人番号）を含む支払調書を作成する（Ｓ２１）。企業ＰＣ１４ａは、支払調書のデータをユーザＩＤとともに番号確認ＧＷ１２へアップロードする（Ｓ２２）。番号確認ＧＷ１２の調書受付部８２は、企業ＰＣ１４ａから送信された支払調書のデータをユーザＩＤと対応付けて調書保持部７０へ格納する。

番号確認ＧＷ１２の調書提供部８４は、支払調書完成のメッセージとユーザＩＤを含む電子メールをユーザ端末１８へ送信する（Ｓ２３）。ユーザは、スマートフォン１８ａを操作して番号確認ＧＷ１２の個人向けウェブサイトへログインし、個人向けウェブページへユーザＩＤを入力する。この操作に応じて、スマートフォン１８ａは、ユーザＩＤを指定した支払調書のダウンロード要求を番号確認ＧＷ１２へ送信する。番号確認ＧＷ１２の調書提供部８４は、ダウンロード要求で指定されたユーザＩＤにより特定される支払調書のデータを調書保持部７０から取得してスマートフォン１８ａへ送信する（Ｓ２４）。そして支払調書の内容を示す調書提示画面がスマートフォン１８ａに表示される。

以降、企業Ａはオフラインで支払調書を行政機関へ提出し、または、企業ＰＣ１４ａはオンラインで支払調書のデータを行政サーバ１６へ送信する（Ｓ２５）。ユーザが番号登録支援Ａｐｐ４０の調書提出メニューを選択すると、ユーザ端末１８の調書提出部５６は、支払調書のデータを行政サーバ１６へ送信する（Ｓ２６）。

所定期間が経過すると、番号確認ＧＷ１２は個人情報保護のためのデータ処理を実行する（Ｓ２７）。具体的には個人情報提供部８０は、企業Ａの企業私書箱に格納されたユーザの個人情報に対する企業Ａのアクセス権を削除する。また個人情報消去部８６は、企業Ａの企業私書箱に格納されたユーザの個人情報を消去する。さらにまた調書提供部８４は、調書保持部７０に格納されたユーザの支払調書に対するユーザ端末１８のアクセス権を削除する。

図５は、図４に続く番号確認支援システム１０の動作を示すシーケンス図である。ここでは、企業Ａへ個人情報を申告済のユーザが、後日、企業Ｂの仕事を請け負うこととなり、企業Ｂへ個人情報を新たに申告することを想定する。図５の企業Ｂは企業ＰＣ１４ｂに対応する。これまで企業Ｂは番号確認ＧＷ１２を利用しなかったこととし、まず企業ＰＣ１４ｂは、自社の企業私書箱の開設を番号確認ＧＷ１２に要求する（Ｓ３０）。番号確認ＧＷ１２の企業登録部７２は、企業Ｂの情報を申告先候補の企業リストへ追加するともに、企業Ｂ用の企業私書箱を企業私書箱保持部６８に設定する。

番号確認ＧＷ１２の申告先候補配信部７４は、企業登録部７２により更新された最新の企業リストをスマートフォン１８ａへ送信する（Ｓ３１）。最新の企業リストを含む番号登録支援Ａｐｐ４０の更新モジュールが、インターネット上のアプリストアからスマートフォン１８ａへ提供されてもよい。企業ＰＣ１４ｂは、番号登録支援Ａｐｐ４０による本人確認書類の送付を依頼する内容の電子メールであり、企業Ｂが定めたユーザＩＤを通知する電子メールをスマートフォン１８ａへ送信する（Ｓ３２）。

ユーザは、スマートフォン１８ａで番号登録支援Ａｐｐ４０を起動し、個人情報申告メニューを選択する。申告済フラグがオンであるため、スマートフォン１８ａのアプリ画面表示部４２は、撮影指示画面の表示をスキップして申告先選択画面を表示させる。ユーザは、個人情報の申告先となる企業Ｂを申告先選択画面で選択する（Ｓ３３）。スマートフォン１８ａの申告情報送信部４８は、個人情報申告先の企業Ｂを指定するデータとユーザＩＤを含むが、通知カードと身分証明書の写真データを含まない申告情報を番号確認ＧＷ１２へ送信する（Ｓ３４）。

番号確認ＧＷ１２の個人情報記録部７８は、ユーザＩＤにより特定される写真データであり、この例では企業Ａの企業私書箱に格納済の写真データを検出し、その写真データをユーザＩＤと現在日時に対応付けて、企業Ｂに割当てられた企業私書箱へコピーする（Ｓ３５）。以降のＳ３６〜Ｓ４６の処理は、図４のＳ１７〜Ｓ２７の処理と同様である。例えばＳ３８では、企業Ｂの企業私書箱に格納された写真データであり、すなわち企業Ａに提供された写真データを企業ＰＣ１４ｂへ送信する。

このように第１実施形態の番号確認ＧＷ１２およびユーザ端末１８（特に番号登録支援Ａｐｐ４０）によると、ユーザは、通知カード等を一度撮影し、その写真等の個人情報を一旦いずれかの企業へ申告すれば、別の企業へ個人情報を申告する際に再度通知カード等を撮影することが不要になる。例えば、番号登録支援Ａｐｐ４０の申告先選択画面で上記別の企業を選択するだけで、その企業への個人情報（個人番号）の申告が完了する。これにより、クラウドソーシング等の進展に伴って、個人情報の申告先、言い換えれば、個人番号の告知先が増加する場合にも、ユーザの負担増加を抑制できる。

また、ユーザの個人情報を収集すべき企業にとっても、番号登録支援Ａｐｐ４０経由での本人確認書類送付をユーザに依頼すれば、番号確認ＧＷ１２を経由して、本人確認書類が企業へ提供される。これにより、クラウドソーシング等の進展に伴って、給与や報酬の支払対象となる個人が増加する場合にも企業の負担増加を抑制できる。

以上、本発明を第１実施形態をもとに説明した。この実施の形態は例示であり、各構成要素や各処理プロセスの組合せにいろいろな変形例が可能なこと、またそうした変形例も本発明の範囲にあることは当業者に理解されるところである。以下変形例を示すが、これらの変形例は後述の第２実施形態にも適用可能である。

第１変形例を説明する。第１実施形態では企業私書箱保持部６８に企業毎の企業私書箱を設け、企業私書箱単位にユーザの個人情報を記憶することとした。変形例として、番号確認ＧＷ１２は、企業私書箱保持部６８に代えて、ユーザの個人情報をユーザ単位、言い換えればユーザＩＤ単位に記憶する個人情報保持部を備えてもよい。具体的には、個人情報保持部は、ユーザの個人情報と、その申告先となる１つ以上の企業の識別情報と、各企業への申告日時（第１実施形態の格納日時に相当）を対応付けて保持してもよい。

番号確認ＧＷ１２の個人情報記録部７８は、ユーザ端末１８からアップロードされた個人情報に申告先企業の識別情報を対応付けて個人情報保持部へ格納してもよい。また、申告先指定データを含むが開示データを含まない申告情報を受け付けた場合、個人情報記録部７８は、既に個人情報保持部に記憶された申告元ユーザの個人情報に対して、申告先企業の識別情報と申告日時を新たに付加して記録してもよい。個人情報提供部８０は、特定の企業の識別情報に対応付けられた個人情報を、その特定の企業の企業ＰＣ１４へ提供してもよい。

第２変形例を説明する。図４のＳ２６、図５のＳ４５では、ユーザ端末１８の番号登録支援Ａｐｐ４０から、法定調書（支払調書）のデータをオンラインで行政サーバ１６へ送信することとした。変形例として、ユーザ端末１８の番号登録支援Ａｐｐ４０は、番号確認ＧＷ１２から提供された法定調書を、ユーザ等が保有する所定のプリンタに印刷させてもよい。ユーザは、印刷された法定証書を、郵送等のオフラインで行政機関へ提出してもよい。

第３変形例として、個人情報保護処理の変形例を説明する。企業私書箱を開設した企業は、企業単位、個人単位等の任意の粒度で、予め定められた複数種類の個人情報保護のポリシー（パターン）の中から特定のポリシーを選択可能であってもよい。例えば、（１）所定期間の経過を条件として、企業私書箱に格納されたユーザの属性情報に対するアクセス権を剥奪すること、（２）所定期間の経過を条件として、企業私書箱に格納されたユーザの属性情報から個人番号部分を消去（非表示処理、マスク処理）すること、（３）所定期間の経過を条件として、企業私書箱に格納されたユーザの特定の個人情報（例えば氏名や住所等）部分を消去すること、の中から所望のポリシーを選択可能であってもよい。個人情報提供部８０、個人情報消去部８６、調書提供部８４は、各企業により選択されたポリシーに応じて、各企業の企業私書箱に対する個人情報保護処理を実行してもよい。

企業では、マイナンバー法、個人情報保護法、税法等の法律毎に定められた書類保管期限の違いや罰則の違い等のために、マイナンバー法の対象からは外したいが、誰に、いつ、どのような報酬を支払ったかは把握しておきたいというケースがあり得る。また、重要な個人情報を保管したくはないが、これまでいくらの金銭を支払ってきたかは把握したいというケースがあり得る。第３変形例によると、企業毎に異なりうる情報保管のポリシーに柔軟に対応した付加価値の高いサービスを提供できる。

（第２実施形態）
第２実施形態の番号確認支援システム１０の構成は第１実施形態（図１）と同様であり、第２実施形態のユーザ端末１８の機能構成も第１実施形態（図２）と同様である。その一方、第２実施形態の企業Ａ〜企業Ｃは、個人番号の本人確認や、支払調書の作成を番号確認ＧＷ１２へ委託する。すなわち、第２実施形態の番号確認ＧＷ１２は、個人番号の本人確認や支払調書の作成に関するデータ処理を自律的に実行する。

図６は、第２実施形態の番号確認ＧＷ１２の機能構成を示すブロック図である。番号確認ＧＷ１２は、本人確認状況保持部７１、本人確認処理部８８、確認完了通知部９０、指示受付部９２、調書作成部９４、調書提出部９６をさらに備える。その一方、第１実施形態の番号確認ＧＷ１２と異なり、個人情報提供部８０と調書受付部８２を含まない。

図６に示すブロックのうち、第１実施形態で説明済のブロックと同一または対応するブロックには同一の符号を付している。以下、第１実施形態と重複する説明は適宜省略し、異なる点を主に説明する。

企業私書箱保持部６８の企業私書箱は、ユーザの個人情報として、第１実施形態の写真データに代えて、通知カードが示すユーザの属性情報のテキストデータを保持する。ユーザの属性情報は典型的には、個人番号と、基本４情報と呼ばれる氏名、性別、生年月日、住所を含む。本人確認状況保持部７１は、番号登録支援Ａｐｐ４０を利用する複数のユーザそれぞれの本人確認が完了したか否かを示す情報を保持する。具体的には、あるユーザの本人確認が問題なく完了した場合に、そのユーザのユーザＩＤと、本人確認完了を示す所定のフラグ（「本人確認済フラグ」と呼ぶ。）とを対応付けて記憶する。

個人情報記録部７８は、申告情報受付部７６により受信された申告情報が含む通知カードと身分証明書それぞれの画像データに対してＯＣＲ処理を実行し、通知カードをソースとする属性情報のテキストデータと、身分証明書をソースとする属性情報のテキストデータを読み込む。個人情報記録部７８は、ユーザＩＤおよび申告先企業の識別情報に対応付けて、通知カードをソースとする属性情報のテキストデータと、身分証明書をソースとする属性情報のテキストデータの両方を本人確認処理部８８に渡す。さらに個人情報記録部７８は、通知カードをソースとする属性情報のテキストデータをユーザＩＤに対応付けて申告先企業の企業私書箱へ格納する。

なお第１実施形態と同様に、申告情報受付部７６により受信された申告情報は、申告先指定データを含むが、開示データ（通知カードと身分証明書の画像データ）を含まない場合がある。この場合、個人情報記録部７８は、第１実施形態と同様に、ユーザの属性情報が予め格納された企業私書箱から、今回の申告先企業の企業私書箱へユーザの属性情報をコピーする。そして個人情報記録部７８は、ユーザＩＤおよび申告先企業の識別情報を本人確認処理部８８へ渡す。

個人情報消去部８６は、第１実施形態と同様に、企業私書箱保持部６８に格納されたユーザの個人情報について、格納日時を参照して、企業私書箱保持部６８に格納された期間を監視する。個人情報消去部８６は、格納期間が所定の閾値以上になった個人情報を企業私書箱保持部６８から消去する。

本人確認処理部８８は、申告情報受付部７６により受信された申告情報に基づいて、申告元ユーザの本人確認処理を自動的に実行する。本人確認処理部８８は、本人確認状況保持部７１を参照して申告情報が示すユーザＩＤに対して本人確認済フラグが未設定であれば本人確認処理を実行する。具体的には、本人確認処理部８８は、個人情報記録部７８から入力された、通知カードをソースとするユーザの属性情報と、身分証明書をソースとするユーザの属性情報とを比較、照合する。両者が一致する場合、本人確認処理部８８は、本人確認に成功したと判定する。

本人確認に成功したと判定すると、本人確認処理部８８は、ユーザＩＤと本人確認済フラグを対応づけて本人確認状況保持部７１へ格納する。さらに本人確認処理部８８は、ユーザＩＤと申告先企業の識別情報を確認完了通知部９０へ渡し、本人確認の完了を申告先企業へ通知させる。変形例として、本人確認処理部８８は、通知カードと身分証明書それぞれの画像データに含まれるユーザの顔写真を公知の手法でマッチングし、顔の特徴情報が一致することをさらなる条件として、本人確認に成功したと判定してもよい。

本人確認処理部８８は、本人確認状況保持部７１を参照して、申告情報が示すユーザＩＤに対して本人確認済フラグが設定済であれば本人確認処理をスキップする。この場合、典型的には個人情報記録部７８からユーザＩＤと申告先企業の識別情報が入力される。本人確認処理部８８は、本人確認処理を実行した場合と同様に、ユーザＩＤと申告先企業の識別情報を確認完了通知部９０へ渡し、本人確認の完了を申告先企業へ通知させる。

なお、本人確認処理部８８が本人確認を自動実行する構成に代えて、番号確認ＧＷ１２のオペレータ等が、通知カードと身分証明書の画像データを目視比較して本人確認を実施してもよい。本人確認の実施者は、本人確認に成功したと判断すると、ユーザＩＤと本人確認済フラグを対応付けて本人確認状況保持部７１へ記録し、また、ユーザＩＤと申告先企業の識別情報を確認完了通知部９０へ渡すための所定の作業を実施してもよい。

確認完了通知部９０は、ユーザの本人確認が完了したことを検出した場合に、ユーザの本人確認が完了した旨の情報（以下「本人確認完了通知」と呼ぶ。）を申告先の企業ＰＣ１４ａへ送信する。具体的には、確認完了通知部９０は、本人確認処理部８８からユーザＩＤと申告先企業の識別情報が入力された場合に、そのユーザＩＤを含む本人確認完了通知を、申告先企業の企業ＰＣ１４へ送信する。このように、本人確認完了通知は、申告先企業が予めユーザに対して割当てたユーザＩＤを含む一方、通知カードが示すユーザの個人情報のうち少なくとも個人番号を含まない。

指示受付部９２は、支払調書の作成を要求するデータ（以下「調書作成要求」と呼ぶ。）と、行政機関への支払調書の提出を要求するデータ（以下「調書提出要求」と呼ぶ。）を企業ＰＣ１４から受け付ける。調書作成要求は、支払調書に設定すべき情報であり、ユーザへの金銭支払に関する情報（以下「金銭支払情報」と呼ぶ。）と、ユーザＩＤ、要求元企業の識別情報を含む。調書提出要求は、提出対象となる支払調書のＩＤを含む。調書作成要求（金銭支払情報）と調書提出要求はいずれもユーザの個人番号を含まない。

調書作成部９４は、調書作成要求が示す企業の識別情報に基づいて要求元企業の企業私書箱を識別し、その企業私書箱に格納された個人情報のうち、調書作成要求が示すユーザＩＤに対応付けられた個人情報を取得する。調書作成部９４は、調書作成要求が含む金銭支払情報と、企業私書箱から取得した個人情報のうち少なくとも個人番号を設定した支払調書のデータを生成し、支払調書ＩＤを払い出す。調書作成部９４は、支払調書の本文データ、支払調書ＩＤ、ユーザＩＤ、調書作成要求元企業の識別情報を対応付けて調書保持部７０へ格納する。

調書提供部８４は、第１実施形態と同様に支払調書をユーザ端末１８へ提供し、第２実施形態ではさらに企業ＰＣ１４へも提供する。具体的には、調書作成部９４により支払調書のデータが調書保持部７０へ格納された場合に、調書作成要求元企業の企業ＰＣ１４へ、支払調書の内容を確認させるための確認データを支払調書ＩＤとともに送信する。

調書提供部８４は、調書保持部７０に格納された支払調書のオリジナルデータを、ユーザの個人番号を非表示の態様へ変更したデータを確認データとして生成する。個人番号を非表示の態様とは、個人番号を削除、消去、隠蔽、排除した態様とも言える。調書提供部８４は、支払調書のデータ（例えば画像データ）を含むウェブページを企業ＰＣ１４へ送信してもよい。その場合、調書提供部８４は、ページ内の個人番号表示領域に対して所定のマスク処理を施したウェブページを送信してもよい。

調書提供部８４は、調書作成要求元企業による支払調書へのアクセス権、具体的にはユーザの個人番号が非表示に編集された支払調書確認データへのアクセス権を、そのアクセスが可能になってから一定期間経過後に無効にする。例えば調書提供部８４は、支払調書を作成した旨、または確認データを閲覧可能である旨を調書作成要求元企業の企業ＰＣ１４へ通知してもよい。そして、その通知から例えば２週間〜１ヶ月後に確認データへのアクセス権を削除し、また番号確認ＧＷ１２に記憶された確認データを消去してもよい。

調書提出部９６は、調書提出要求が受け付けられた場合に、調書保持部７０に格納された支払調書のうち、調書提出要求が示す支払調書ＩＤで特定される支払調書のデータを行政サーバ１６へ送信する。例えば、ユーザ端末１８の調書提出部５６と同様に、行政サーバ１６が公開するウェブサービスを利用して支払調書のデータを行政サーバ１６へアップロードしてもよい。

以上の構成による番号確認支援システム１０の動作を説明する。
図７は、第２実施形態の番号確認支援システム１０の動作を示すシーケンス図である。ここでは、ユーザ端末１８はスマートフォン１８ａとする。ユーザは、支払調書への設定が必要な個人番号を企業Ａへ申告するために、本人確認書類として通知カードの写真と身分証明書の写真を提供する。図４の企業Ａは企業ＰＣ１４ａに対応し、行政機関は行政サーバ１６に対応する。図７のＳ５０〜Ｓ５５は、第１実施形態の番号確認支援システム１０の動作（図４のＳ１０〜Ｓ１５）と同様である。

番号確認ＧＷ１２の申告情報受付部７６は、スマートフォン１８ａから送信された申告情報を受信する。個人情報記録部７８は、受信された申告情報が含む写真データをＯＣＲ処理して、通知カードが示すユーザの属性情報を、ユーザＩＤと現在日時に対応づけて、企業Ａに割当てられた企業私書箱へ格納する。本人確認処理部８８は、ＯＣＲ処理で取得された通知カードが示すユーザの属性情報と、身分証明書が示すユーザの属性情報とを照合して本人確認の成否を判定する（Ｓ５６）。本人確認に成功したと判定すると、本人確認処理部８８は、ユーザに対する本人確認済フラグを設定し、確認完了通知部９０は、本人確認完了通知を企業ＰＣ１４ａへ送信する（Ｓ５７）。

その後、企業Ａからユーザへ報酬が支払われる。企業Ａの担当者は、報酬支払の事実を示すデータである金銭支払情報（ユーザの個人番号を含まない）を企業ＰＣ１４ａで作成する。企業Ａの担当者は、企業ＰＣ１４ａを操作して、番号確認ＧＷ１２の企業向けウェブサイトへログインする（Ｓ５８）。企業Ａの担当者は、番号確認ＧＷ１２の企業向けウェブページを介して、ユーザＩＤと金銭支払情報を含む調書作成要求を企業ＰＣ１４ａから番号確認ＧＷ１２へ送信させる（Ｓ５９）。番号確認ＧＷ１２の調書作成部９４は、調書作成要求に応じて支払調書を作成し、企業Ａの企業私書箱に格納されたユーザの個人番号をその支払調書内に設定する（Ｓ６０）。

調書提供部８４は、調書作成部９４により作成された支払調書の確認画面であり、ユーザの個人番号を非表示に設定した確認画面のデータを企業ＰＣ１４ａへ送信して表示させる（Ｓ６１）。企業Ａの担当者は確認画面を見て、行政機関への提出を指示する操作を確認画面へ入力する。この操作に応じて、企業ＰＣ１４ａは、確認画面で表示された支払調書のＩＤを含む調書提出要求を番号確認ＧＷ１２へ送信する（Ｓ６２）。番号確認ＧＷ１２の調書提出部９６は、調書提出要求が示すＩＤで特定される支払調書であり、ユーザの個人番号が設定された支払調書のデータを行政サーバ１６へ送信する（Ｓ６３）。

図７のＳ６４〜Ｓ６６は、第１実施形態の番号確認支援システム１０の動作（図４のＳ２３、Ｓ２４、Ｓ２６）と同様である。所定期間が経過すると、番号確認ＧＷ１２は個人情報保護のためのデータ処理を実行する（Ｓ６７）。具体的には、調書提供部８４は、支払調書の確認データに対する企業Ａのアクセス権を削除し、また、調書保持部７０に格納された支払調書に対するユーザのアクセス権を削除する。個人情報消去部８６は、企業Ａの企業私書箱に格納されたユーザの個人情報を消去する。

図８は、図７に続く番号確認支援システム１０の動作を示すシーケンス図である。ここでは、企業Ａへ個人情報を申告済のユーザが、後日、企業Ｂの仕事を請け負うこととなり、企業Ｂへ個人情報を新たに申告することを想定する。図５の企業Ｂは企業ＰＣ１４ｂに対応する。図８のＳ７０〜Ｓ７４は、第１実施形態の番号確認支援システム１０の動作（図５のＳ３０〜Ｓ３４）と同様である。Ｓ７４でスマートフォン１８ａから番号確認ＧＷ１２へ送信される申告情報は、申告先の企業Ｂを指定するデータとユーザＩＤを含むが、通知カードと身分証明書の写真データを含まない。

番号確認ＧＷ１２の個人情報記録部７８は、ユーザＩＤにより特定される個人情報であり、この例では企業Ａの企業私書箱に格納済であるユーザの属性情報をユーザＩＤと現在日時に対応付けて、企業Ｂの企業私書箱へコピーする（Ｓ７５）。ユーザの本人確認が完了済（すなわちユーザに本人確認済フラグが設定済）であるため、本人確認処理部８８は、ユーザの本人確認処理をスキップし、確認完了通知部９０は、本人確認完了通知を企業ＰＣ１４ｂへ送信する（Ｓ７６）。その後、企業Ｂからユーザへ報酬が支払われる。以降のＳ７７〜Ｓ８６は、報酬支払元が企業Ａの場合の動作、すなわち図７のＳ５８〜Ｓ６７と同様である。

このように第２実施形態の番号確認ＧＷ１２およびユーザ端末１８（特に番号登録支援Ａｐｐ４０）によると、第１実施形態と同様の効果を奏する。例えばユーザは、通知カード等を一度撮影し、その写真等の個人情報を一旦いずれかの企業へ申告すれば、別の企業へ個人情報を申告する際に再度通知カード等を撮影することが不要になる。例えば、番号登録支援Ａｐｐ４０の申告先選択画面で上記別の企業を選択するだけで、その企業への個人情報（個人番号）の申告が完了する。これにより、クラウドソーシング等の進展に伴って、個人情報の申告先、言い換えれば、個人番号の告知先が増加する場合にも、ユーザの負担増加を抑制できる。

また第２実施形態では、企業は、本人確認書類の収集、本人確認の実施、法定調書の作成および提出を番号確認ＧＷ１２へアウトソーシングできる。これにより、クラウドソーシング等の進展に伴って、給与や報酬の支払対象となる個人が増加する場合にも企業の負担増加を抑制できる。さらに第２実施形態では、ユーザの個人番号の保管主体は番号確認ＧＷ１２となり、ユーザの個人番号は企業側へ開示されない。これにより、厳重な管理が求められ、漏洩が許されない個人番号を企業が保管することが不要になり、企業の負担を一層低減できる。

以上、本発明を第２実施形態をもとに説明した。この実施の形態は例示であり、各構成要素や各処理プロセスの組合せにいろいろな変形例が可能なこと、またそうした変形例も本発明の範囲にあることは当業者に理解されるところである。

上述した実施の形態および変形例の任意の組み合わせもまた本発明の実施の形態として有用である。組み合わせによって生じる新たな実施の形態は、組み合わされる実施の形態および変形例それぞれの効果をあわせもつ。また、請求項に記載の各構成要件が果たすべき機能は、実施の形態および変形例において示された各構成要素の単体もしくはそれらの連携によって実現されることも当業者には理解されるところである。

１０ 番号確認支援システム、 １２ 番号確認ＧＷ、 １４ 企業ＰＣ、 １８ ユーザ端末、 ６８ 企業私書箱保持部、 ７６ 申告情報受付部、 ８０ 個人情報提供部、 ８４ 調書提供部、 ９０ 確認完了通知部、 ９４ 調書作成部。

Claims (6)

1. 通信網を介して、企業の装置と、ユーザの端末とに接続される情報処理装置であって、
   前記ユーザの個人情報を含む開示データと、その個人情報の申告先となる第１の企業を指定する指定データを含む情報を前記ユーザの端末から受け付ける申告情報受付部と、
   前記申告情報受付部により受け付けられた前記ユーザの個人情報を記憶する個人情報記憶部と、
   前記ユーザの個人情報を前記第１の企業の装置へ提供する個人情報提供部と、
   を備え、
   前記申告情報受付部が、個人情報の申告先となる第２の企業を指定する指定データを含むが、前記開示データを含まない情報を前記ユーザの端末から受け付けた場合、前記個人情報提供部は、前記個人情報記憶部に予め記憶された前記ユーザの個人情報を前記第２の企業の装置へ提供することを特徴とする情報処理装置。
2. 通信網を介して、企業の装置と、ユーザの端末とに接続される情報処理装置であって、
   前記ユーザの個人情報を含む開示データと、その個人情報の申告先となる第１の企業の指定する指定データを含む情報を前記ユーザの端末から受け付ける申告情報受付部と、
   前記申告情報受付部により受け付けられた前記ユーザの個人情報を記憶する個人情報記憶部と、
   前記ユーザの個人情報に基づく本人確認が完了したことを検出した場合に、前記ユーザの本人確認が完了したことを示す情報を前記第１の企業の装置へ提供する確認完了通知部と、
   を備え、
   前記申告情報受付部が、個人情報の申告先となる第２の企業を指定する指定データを含むが、前記開示データを含まない情報を前記ユーザの端末から受け付けた場合、前記確認完了通知部は、前記ユーザの個人情報に基づく本人確認が完了済であれば、前記ユーザの本人確認が完了したことを示す情報を前記第２の企業の装置へ提供することを特徴とする情報処理装置。
3. 支払情報受付部と調書作成部をさらに備え、
   前記確認完了通知部は、前記ユーザの本人確認が完了したことを示す情報であって、前記ユーザの個人情報のうち少なくとも個人番号を含まない情報を前記第１の企業の装置へ提供し、
   前記支払情報受付部は、前記ユーザに対する金銭の支払を示す情報であって、前記ユーザの個人番号を含まない支払情報を前記第１の企業の装置から受け付け、
   前記調書作成部は、前記支払を示す情報に基づいて、前記個人情報記憶部に記憶された前記ユーザの個人番号を設定した金銭の支払に関する法定調書を作成することを特徴とする請求項２に記載の情報処理装置。
4. 前記調書作成部により作成された法定調書の確認データであって、その法定調書に設定された前記ユーザの個人番号を非表示とした確認データを前記第１の企業の装置へ提供する法定調書提供部をさらに備えることを特徴とする請求項３に記載の情報処理装置。
5. 個人情報の申告先の候補として複数の企業の情報を保持する機能と、
   ユーザの個人情報を含む開示データの入力を受け付ける機能と、
   前記複数の企業の中から前記ユーザの個人情報の申告先となる第１の企業の選択を受け付ける機能と、
   前記第１の企業を指定するデータと前記開示データを含む申告情報を外部のサーバへ送信することにより、前記ユーザの個人情報を前記サーバから前記第１の企業へ提供させる申告情報送信機能と、
   をコンピュータに実現させ、
   前記申告情報を前記サーバへ送信後に、個人情報の新たな申告先となる第２の企業が選択された場合、前記申告情報送信機能は、前記第２の企業を指定するデータを含むが、前記開示データを含まない申告情報を前記サーバへ送信し、前記サーバから前記第１の企業へ提供された前記ユーザの個人情報を前記サーバから前記第２の企業へ提供させることを特徴とするコンピュータプログラム。
6. 個人情報の申告先の候補として複数の企業の情報を保持する機能と、
   ユーザの個人情報を含む開示データの入力を受け付ける機能と、
   前記複数の企業の中から前記ユーザの個人情報の申告先となる第１の企業の選択を受け付ける機能と、
   前記第１の企業を指定するデータと前記開示データを含む申告情報を外部のサーバへ送信することにより、前記ユーザの本人確認が完了したことを示す情報を前記サーバから前記第１の企業へ提供させる申告情報送信機能と、
   をコンピュータに実現させ、
   前記申告情報を前記サーバへ送信後に、個人情報の新たな申告先となる第２の企業が選択された場合、前記申告情報送信機能は、前記第２の企業を指定するデータを含むが、前記開示データを含まない申告情報を前記サーバへ送信し、前記ユーザの本人確認が完了したことを示す情報を前記サーバから前記第２の企業へ提供させることを特徴とするコンピュータプログラム。

Images