知財求人 - 知財ポータルサイト「IP Force」
特開2024-153279情報処理システム、情報処理方法及び情報処理プログラム
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公開特許公報(A)
(11)【公開番号】P2024153279
(43)【公開日】2024-10-29
(54)【発明の名称】情報処理システム、情報処理方法及び情報処理プログラム
(51)【国際特許分類】
G06Q 50/26 20240101AFI20241022BHJP
【ＦＩ】
G06Q50/26
【審査請求】未請求
【請求項の数】12
【出願形態】ＯＬ
(21)【出願番号】P 2023067069
(22)【出願日】2023-04-17
(71)【出願人】
【識別番号】000136136
【氏名又は名称】株式会社ＰＦＵ
(74)【代理人】
【識別番号】100145838
【弁理士】
【氏名又は名称】畑添 隆人
(74)【代理人】
【識別番号】100103137
【弁理士】
【氏名又は名称】稲葉 滋
(74)【代理人】
【識別番号】100216367
【弁理士】
【氏名又は名称】水谷 梨絵
(72)【発明者】
【氏名】奥山 幸也
(72)【発明者】
【氏名】山田 良太
(72)【発明者】
【氏名】児平 哲彦
(72)【発明者】
【氏名】岩山 暁
【テーマコード（参考）】
5L049
5L050
【Ｆターム（参考）】
5L049CC35
5L049EE01
5L050CC35
5L050EE01
(57)【要約】
【課題】帳票フォームの選択を容易に行うことを課題とする。
【解決手段】情報処理システムに、最上層と最下層を含む複数の階層からなる階層構造で特定される用途毎に、該用途と、帳票の様式を定義した１以上の帳票フォームとを対応付けて記憶する帳票記憶部と、前記最上層から順に前記最下層までの用途要素の選択を受け付けることで、用途の選択を受け付ける用途選択受付部と、選択された前記用途に対応する前記１以上の帳票フォームを、選択された前記用途に適した１以上の帳票データを生成するための帳票フォームとして選択する選択部と、を備えた。
【選択図】図２
【解決手段】情報処理システムに、最上層と最下層を含む複数の階層からなる階層構造で特定される用途毎に、該用途と、帳票の様式を定義した１以上の帳票フォームとを対応付けて記憶する帳票記憶部と、前記最上層から順に前記最下層までの用途要素の選択を受け付けることで、用途の選択を受け付ける用途選択受付部と、選択された前記用途に対応する前記１以上の帳票フォームを、選択された前記用途に適した１以上の帳票データを生成するための帳票フォームとして選択する選択部と、を備えた。
【選択図】図２
【特許請求の範囲】
【請求項1】
最上層と最下層を含む複数の階層からなる階層構造で特定される用途毎に、該用途と、帳票の様式を定義した１以上の帳票フォームとを対応付けて記憶する帳票記憶手段と、
前記最上層から順に前記最下層までの用途要素の選択を受け付けることで、用途の選択を受け付ける用途選択受付手段と、
選択された前記用途に対応する前記１以上の帳票フォームを、選択された前記用途に適した１以上の帳票データを生成するための帳票フォームとして選択する選択手段と、
を備える情報処理システム。
前記最上層から順に前記最下層までの用途要素の選択を受け付けることで、用途の選択を受け付ける用途選択受付手段と、
選択された前記用途に対応する前記１以上の帳票フォームを、選択された前記用途に適した１以上の帳票データを生成するための帳票フォームとして選択する選択手段と、
を備える情報処理システム。
【請求項2】
帳票に記載される対象のデータである入力データを取得するデータ取得手段と、
選択された前記１以上の帳票フォームに対して前記入力データを配置することで、該入力データが記載された前記１以上の帳票データを生成する帳票生成手段と、を更に備える、
請求項１に記載の情報処理システム。
選択された前記１以上の帳票フォームに対して前記入力データを配置することで、該入力データが記載された前記１以上の帳票データを生成する帳票生成手段と、を更に備える、
請求項１に記載の情報処理システム。
【請求項3】
前記データ取得手段は、前記入力データとして、ユーザに係る情報が記録された媒体を読み取る読取手段により読み取られた該ユーザに係る情報を取得する、
請求項２に記載の情報処理システム。
請求項２に記載の情報処理システム。
【請求項4】
前記帳票記憶手段は、少なくとも１つの前記用途を、複数の前記帳票フォームと対応付けて記憶する、
請求項１に記載の情報処理システム。
請求項１に記載の情報処理システム。
【請求項5】
前記帳票フォームを生成する帳票フォーム生成手段を更に備え、
前記帳票フォーム生成手段は、前記階層構造の前記最下層より上の層において同一の前記用途要素を有する複数の前記用途に夫々対応させる複数の前記帳票フォームとして、同一のレイアウトに対して互いに異なる帳票項目定義が組み合せられた複数の帳票フォームを生成可能である、
請求項１に記載の情報処理システム。
前記帳票フォーム生成手段は、前記階層構造の前記最下層より上の層において同一の前記用途要素を有する複数の前記用途に夫々対応させる複数の前記帳票フォームとして、同一のレイアウトに対して互いに異なる帳票項目定義が組み合せられた複数の帳票フォームを生成可能である、
請求項１に記載の情報処理システム。
【請求項6】
前記帳票フォーム生成手段は、
前記帳票の前記レイアウトの下敷きとなる下敷きデータを取得する下敷きデータ取得手段を備え、
前記階層構造の前記最下層より上の層において同一の前記用途要素を有する複数の前記用途に夫々対応させる複数の前記帳票フォームとして、前記同一のレイアウトとしての同一の前記下敷きデータに対して互いに異なる前記帳票項目定義が組み合わせられた前記複数の帳票フォームを生成可能である、
請求項５に記載の情報処理システム。
前記帳票の前記レイアウトの下敷きとなる下敷きデータを取得する下敷きデータ取得手段を備え、
前記階層構造の前記最下層より上の層において同一の前記用途要素を有する複数の前記用途に夫々対応させる複数の前記帳票フォームとして、前記同一のレイアウトとしての同一の前記下敷きデータに対して互いに異なる前記帳票項目定義が組み合わせられた前記複数の帳票フォームを生成可能である、
請求項５に記載の情報処理システム。
【請求項7】
前記用途は、複数の用途のうちの１つの用途であり、
前記用途選択受付手段は、前記複数の用途の選択を受け付け、
前記選択手段は、選択された前記複数の用途に対応する複数の前記帳票フォームを、前記選択された複数の用途に適した複数の前記帳票データを生成するための複数の帳票フォームとして選択する、
請求項１に記載の情報処理システム。
前記用途選択受付手段は、前記複数の用途の選択を受け付け、
前記選択手段は、選択された前記複数の用途に対応する複数の前記帳票フォームを、前記選択された複数の用途に適した複数の前記帳票データを生成するための複数の帳票フォームとして選択する、
請求項１に記載の情報処理システム。
【請求項8】
帳票に記載される対象のデータである入力データを取得するデータ取得手段と、
選択された前記複数の用途に対応する前記複数の帳票フォームに対して前記入力データを配置することで、該入力データが記載された前記複数の帳票データを生成する帳票生成手段と、を更に備える、
請求項７に記載の情報処理システム。
選択された前記複数の用途に対応する前記複数の帳票フォームに対して前記入力データを配置することで、該入力データが記載された前記複数の帳票データを生成する帳票生成手段と、を更に備える、
請求項７に記載の情報処理システム。
【請求項9】
前記階層構造は、
手続きの種類を示す前記用途要素の層と、
前記手続きの種類に関する層の下層に位置する、前記手続きを行うユーザ又は前記手続きの対象者の属性を示す前記用途要素の層と、を含む、
請求項１に記載の情報処理システム。
手続きの種類を示す前記用途要素の層と、
前記手続きの種類に関する層の下層に位置する、前記手続きを行うユーザ又は前記手続きの対象者の属性を示す前記用途要素の層と、を含む、
請求項１に記載の情報処理システム。
【請求項10】
前記帳票フォームは、前記帳票における複数の帳票項目の帳票項目毎に、項目データの記載位置と、該記載位置に記載される前記項目データに関する記載条件とを定義した帳票フォームであり、
選択された前記帳票フォームで定義された前記帳票項目に係る前記記載条件と、情報が記録された読取対象の媒体に基づいて得られる、前記帳票項目に関連する情報である、媒体情報とを照合する照合手段と、
選択された前記帳票フォームを用いて前記項目データを記載した前記帳票データを生成する帳票生成手段であって、前記照合結果に応じて、前記帳票項目の前記記載位置における記載内容を異ならしめる前記帳票生成手段と、を更に備える、
請求項１に記載の情報処理システム。
選択された前記帳票フォームで定義された前記帳票項目に係る前記記載条件と、情報が記録された読取対象の媒体に基づいて得られる、前記帳票項目に関連する情報である、媒体情報とを照合する照合手段と、
選択された前記帳票フォームを用いて前記項目データを記載した前記帳票データを生成する帳票生成手段であって、前記照合結果に応じて、前記帳票項目の前記記載位置における記載内容を異ならしめる前記帳票生成手段と、を更に備える、
請求項１に記載の情報処理システム。
【請求項11】
最上層と最下層を含む複数の階層からなる階層構造で特定される用途毎に、該用途と、帳票の様式を定義した１以上の帳票フォームとを対応付けて記憶する帳票記憶手段を備えるコンピュータが、
前記最上層から順に前記最下層までの用途要素の選択を受け付けることで、用途の選択を受け付ける用途選択受付ステップと、
選択された前記用途に対応する前記１以上の帳票フォームを、選択された前記用途に適した１以上の帳票データを生成するための帳票フォームとして選択する選択ステップと、
を実行する情報処理方法。
前記最上層から順に前記最下層までの用途要素の選択を受け付けることで、用途の選択を受け付ける用途選択受付ステップと、
選択された前記用途に対応する前記１以上の帳票フォームを、選択された前記用途に適した１以上の帳票データを生成するための帳票フォームとして選択する選択ステップと、
を実行する情報処理方法。
【請求項12】
最上層と最下層を含む複数の階層からなる階層構造で特定される用途毎に、該用途と、帳票の様式を定義した１以上の帳票フォームとを対応付けて記憶する帳票記憶手段を備えるコンピュータを、
前記最上層から順に前記最下層までの用途要素の選択を受け付けることで、用途の選択を受け付ける用途選択受付手段と、
選択された前記用途に対応する前記１以上の帳票フォームを、選択された前記用途に適した１以上の帳票データを生成するための帳票フォームとして選択する選択手段と、
として機能させる情報処理プログラム。
前記最上層から順に前記最下層までの用途要素の選択を受け付けることで、用途の選択を受け付ける用途選択受付手段と、
選択された前記用途に対応する前記１以上の帳票フォームを、選択された前記用途に適した１以上の帳票データを生成するための帳票フォームとして選択する選択手段と、
として機能させる情報処理プログラム。
【発明の詳細な説明】
【技術分野】
【0001】
本開示は、帳票フォームを選択するための技術に関する。
【背景技術】
【0002】
従来、ユーザの情報を埋め込むための雛形の選択を受け付ける入力受付部と、ユーザの情報を取得するために、情報出力装置がネットワークに接続されているか否かを判断する判断部と、ネットワークに接続されていないと判断された場合に、ユーザの情報が記録された記録媒体から該ユーザの情報を読み取る読取部と、読み取られたユーザの情報を選択された雛形の決められた領域に埋め込む埋込処理部と、ユーザの情報が埋め込まれた雛形を出力する出力部とを含む情報出力装置（特許文献１を参照）が提案されている。
【0003】
また、行政システムにおいて、申請者のライフイベントとライフイベントに応じた登録情報の入力がなされる場合に、ライフイベントと関連する１又は複数の手続きとの対応関係が記憶されている記憶部を参照し、入力された申請者のライフイベントと関連づけられた手続きを特定し、特定した手続きを処理する処理装置に対して、入力された申請者の登録情報を送信する装置（特許文献２を参照）が提案されている。
【0004】
また、帳票を選択するためのメインメニュー画面及び各種のサブメニュー画面が表示され、メニュー画面及び各種のサブメニュー画面を用いて所望の帳票が選択され、印刷が指示されると、選択された帳票の印刷指令を管理用コンピュータに送信し、管理用コンピュータから当該帳票の印刷データを取得することにより、当該帳票の印刷処理を行う電子帳票システム（特許文献３を参照）が提案されている。
【0005】
更に、申請者の申請手続の申請種別を受信すると、受信された申請種別に基づいて、申請種別に対して申請者が行うべき他の申請手続を記憶した他申請手続記憶部を参照し、申請者が行うべき他の申請手続を判定する装置（特許文献４を参照）が提案されている。
【先行技術文献】
【特許文献】
【0006】
【特許文献1】特開２０１７－９８６９０号公報
【特許文献2】特開２０１５－４６１２９号公報
【特許文献3】特開２０１０－２１３２０６号公報
【特許文献4】特開２０１７－４１１３８号公報
【発明の概要】
【発明が解決しようとする課題】
【0007】
従来、各種帳票についての帳票フォーム（帳票テンプレート）が提供されている。利用者は、自身がやりたいこと（用途）に応じて、使用する帳票（帳票フォーム）を選択し、選択された帳票フォームに基づき所望の帳票を作成する。しかし、利用者自身が、やりたいこと（用途）に必要な帳票（帳票フォーム）を漏れなく選択することが容易でない場合がある。
【0008】
本開示は、上記した問題に鑑み、帳票フォームの選択を容易に行うことを課題とする。
【課題を解決するための手段】
【0009】
本開示の一例は、最上層と最下層を含む複数の階層からなる階層構造で特定される用途毎に、該用途と、帳票の様式を定義した１以上の帳票フォームとを対応付けて記憶する帳票記憶手段と、前記最上層から順に前記最下層までの用途要素の選択を受け付けることで、用途の選択を受け付ける用途選択受付手段と、選択された前記用途に対応する前記１以上の帳票フォームを、選択された前記用途に適した１以上の帳票データを生成するための帳票フォームとして選択する選択手段と、を備える情報処理システムである。
【0010】
本開示は、情報処理装置、システム、コンピュータによって実行される方法またはコンピュータに実行させるプログラムとして把握することが可能である。また、本開示は、そのようなプログラムをコンピュータその他の装置、機械等が読み取り可能な記録媒体に記録したものとしても把握できる。ここで、コンピュータ等が読み取り可能な記録媒体とは、データやプログラム等の情報を電気的、磁気的、光学的、機械的又は化学的作用によって蓄積し、コンピュータ等から読み取ることができる記録媒体をいう。
【発明の効果】
【0011】
本開示によれば、帳票フォームの選択を容易に行うことが可能となる。
【図面の簡単な説明】
【0012】
【図1】実施形態に係るシステムの構成を示す概略図である。
【図2】実施形態に係る情報処理装置及び読取装置の機能構成の概略を示す図である。
【図3】実施形態に係る記載条件の一例を示す図である。
【図4】実施形態に係る媒体定義の一例を示す図である。
【図5】実施形態に係る下敷きデータの一例を示す図である。
【図6】実施形態に係る下敷きデータの一例を示す図である。
【図7】実施形態に係る下敷きデータを用いて項目定義を行う方法（本人申請の場合）についての説明を行うための図である。
【図8】実施形態に係る下敷きデータを用いて項目定義を行う方法（代理人申請の場合）についての説明を行うための図である。
【図9】実施形態に係る下敷きデータを用いて項目定義を行う方法（本人申請の場合）についての説明を行うための図である。
【図10】実施形態に係る下敷きデータを用いて項目定義を行う方法（代理人申請の場合）についての説明を行うための図である。
【図11】実施形態に係る帳票フォーム生成画面の一例である。
【図12】実施形態に係る帳票フォームの項目定義の一例を示す図である。
【図13】実施形態に係る帳票リストの一例を示す図である。
【図14】実施形態に係る帳票リスト生成画面（カテゴリ１の生成画面）の一例を示す図である。
【図15】実施形態に係る帳票リスト生成画面（カテゴリ２の生成画面）の一例を示す図である。
【図16】実施形態に係る帳票リスト生成画面（帳票フォームとの対応付け画面）の一例を示す図である。
【図17】実施形態に係る用途と対応付けられた帳票フォームの概要の一例を示す図である。
【図18】実施形態に係る帳票フォーム選択画面（用途要素（カテゴリ１）の選択画面）の一例を示す図である。
【図19】実施形態に係る帳票フォーム選択画面（用途要素（カテゴリ２）の選択画面）の一例を示す図である。
【図20】実施形態に係る読取項目についての読取データの一例を示す図である。
【図21】実施形態に係るデータの記載例（変換例）を示す図である。
【図22】実施形態に係る出力イメージ確認画面の一例を示す図である。
【図23】実施形態に係るＣＳＶ情報の一例を示す図である。
【図24】実施形態に係る帳票フォーム生成処理の流れの概要を示すフローチャートである。
【図25】実施形態に係る帳票リスト生成・対応付け処理の流れの概要を示すフローチャートである。
【図26】実施形態に係る帳票生成・出力処理の流れの概要を示すフローチャートである。
【図27】実施形態に係る帳票生成・出力処理（裏面読取指示あり）の流れの概要を示すフローチャートである。
【図28】実施形態に係る帳票フォーム選択処理の流れの概要を示すフローチャートである。
【図29】実施形態に係る帳票生成処理の流れの概要を示すフローチャートである。
【図30】バリエーションに係る帳票フォーム（項目定義）の一例を示す。
【発明を実施するための形態】
【0013】
以下、本開示に係る情報処理装置、システム、方法及びプログラムの実施の形態を、図面に基づいて説明する。但し、以下に説明する実施の形態は、実施形態を例示するものであって、本開示に係る情報処理装置、システム、方法及びプログラムを以下に説明する具体的構成に限定するものではない。実施にあたっては、実施の態様に応じた具体的構成が適宜採用され、また、種々の改良や変形が行われてよい。
【0014】
本実施形態では、本開示に係る情報処理装置、システム、方法及びプログラムを、カードリーダーにより読み取られた身分証明書の情報を用いて帳票（帳票データ）を生成するシステムにおいて実施した場合の実施の形態について説明する。但し、本開示に係る情報処理装置、システム、方法及びプログラムは、帳票（帳票データ）を作成するための技術について広く用いることが可能であり、本開示の適用対象は、実施形態において示した例に限定されない。
【0015】
＜システムの構成＞
図１は、本実施形態に係るシステムの構成を示す概略図である。本実施形態に係るシステムは、情報処理装置１が、ネットワーク又はその他の通信手段を介して、読取装置９と互いに通信可能に接続されたシステムである。本実施形態では、読取ユニットを備えるカードリーダー（読取装置９）と、当該カードリーダーと有線又は無線接続される情報処理装置１とが接続されたシステムにおいて、本開示に係る技術を実施する態様を説明する。但し、本実施形態に係るシステムは、ユーザに係る情報が記録された媒体から情報を読み取る読取装置９と情報処理装置１とが接続された情報処理システムであればよく、例えば、スキャナ装置と情報処理装置１とが接続されたシステムにおいても、本開示に係る技術は適用可能である。
図１は、本実施形態に係るシステムの構成を示す概略図である。本実施形態に係るシステムは、情報処理装置１が、ネットワーク又はその他の通信手段を介して、読取装置９と互いに通信可能に接続されたシステムである。本実施形態では、読取ユニットを備えるカードリーダー（読取装置９）と、当該カードリーダーと有線又は無線接続される情報処理装置１とが接続されたシステムにおいて、本開示に係る技術を実施する態様を説明する。但し、本実施形態に係るシステムは、ユーザに係る情報が記録された媒体から情報を読み取る読取装置９と情報処理装置１とが接続された情報処理システムであればよく、例えば、スキャナ装置と情報処理装置１とが接続されたシステムにおいても、本開示に係る技術は適用可能である。
【0016】
情報処理装置１は、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）１１、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）１２、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）１３、ＥＥＰＲＯＭ（Ｅｌｅｃｔｒｉｃａｌｌｙ Ｅｒａｓａｂｌｅ ａｎｄ Ｐｒｏｇｒａｍｍａｂｌｅ Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）やＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）等の記憶装置１４、キーボードやマウス、タッチパネル等の入力デバイス１５、ディスプレイ等の出力デバイス１６、及びＮＩＣ（Ｎｅｔｗｏｒｋ Ｉｎｔｅｒｆａｃｅ Ｃａｒｄ）等の通信ユニット１７、等を備えるコンピュータである。但し、情報処理装置１の具体的なハードウェア構成に関しては、実施の態様に応じて適宜省略や置換、追加が可能である。また、情報処理装置１は、単一の筐体からなる装置に限定されず、所謂クラウドや分散コンピューティングの技術等を用いた、複数の装置によって実現されてよい。そのため、例えば、帳票フォーム（帳票定義）を生成する機能と、帳票（帳票データ）を生成する機能は、夫々別の装置（システム）が備える機能であってもよい。情報処理装置１は、読取装置９により読み取られた、身分証明書等の媒体に記録された情報に基づき、帳票データを生成する。
【0017】
読取装置９は、読取ユニット９１、カメラ（顔撮影用カメラ）９２、ＣＰＵ９３、ＲＯＭ９４、ＲＡＭ９５、記憶装置９６、タッチパネル等の入力デバイス９７、ディスプレイ等の出力デバイス９８、及び通信ユニット９９、等を備えるコンピュータである。但し、読取装置９の具体的なハードウェア構成に関しては、実施の態様に応じて適宜省略や置換、追加が可能である。また、読取装置９は、単一の筐体からなる装置に限定されず、所謂クラウドや分散コンピューティングの技術等を用いた、複数の装置によって実現されてよい。
【0018】
読取装置９（読取ユニット９１）は、帳票に関連するユーザ（手続きを行う者や手続きの対象者等）に係る情報が記録（「記載」を含む）された媒体（身分証明書等）の情報を読み取る装置である。以下、「ユーザに係る（関連する）情報」を、「ユーザ情報」と称する。また、本実施形態では、ユーザ情報が記録された媒体として、身分証明書（本人確認書類）を例示する。但し、媒体は、ユーザ情報が記録された媒体であれば、身分証明書以外の他のカードや書類等であってもよい。また、ユーザ情報が記録された媒体は、カード形式であることに限定されず、カードサイズとは異なるサイズを有する媒体であってもよい。また、媒体には、任意の情報が記録されていてよい。例えば、媒体には、ユーザ情報として、氏名や、住所、変更後の住所、生年月日、番号（運転免許書番号や旅券番号など）、有効期限（運転期限やパスポート期限など）、顔写真等が記録される。なお、本実施形態では、ユーザ情報が記録された媒体からユーザ情報を読み取ることで、帳票データを生成する実施態様について説明するが、媒体から読み取られたユーザ情報以外の情報に基づき帳票データを生成する実施態様も、本開示の適用対象となる。そのため、媒体に記録される情報は、ユーザ情報以外の情報であってもよい。
【0019】
本実施形態では、読取装置９として、身分証明書の情報を読み取るカードリーダーを例示する。読取装置９は、読み取った情報を情報処理装置１に対して送信する。読取ユニット９１は、例えば、身分証明書（ＩＤ券面）を撮影するカメラ（証明書撮影カメラ）及び／又はＩＣチップに記録された情報を読み取るＩＣリーダーである。読取装置９は、例えば、証明書撮影カメラが身分証明書を撮像することで得られた画像に対して文字認識処理（ＯＣＲ（Ｏｐｔｉｃａｌ Ｃｈａｒａｃｔｅｒ Ｒｅｃｏｇｎｉｔｉｏｎ、光学文字認識）処理）を行うことで、身分証明書に記載された情報を読み取る。また、読取装置９は、例えば、身分証明書（ＩＣカード）に内蔵された、ユーザ情報が記録されたＩＣチップを読み取ることで、ＩＣチップに記録された情報を読み取る。なお、読取装置９は、カードリーダーに限定されず、ユーザがセットした身分証明書を撮像することで、画像を取得する装置であってもよい。例えば、スキャナや、デジタルカメラ、スマートフォン／タブレットに内蔵されているカメラセンサを用いて対象の身分証明書を撮像し、画像を得ることとしてもよい。この場合、読取装置９において、得られた画像に対するＯＣＲ処理が行われることにより、身分証明書の情報が読み取られる。但し、ＯＣＲ処理については、読取装置９ではなく情報処理装置１で行われるようにしてもよい。この場合、撮像された画像が、読取装置９から情報処理装置１に対して送信され、当該画像を受信した情報処理装置１においてＯＣＲ処理が行われる。
【0020】
このように、本実施形態に係る読取装置９は、媒体から読み取られたデータを、ネットワークを介して情報処理装置１に送信する機能を有する。また、読取装置９は、タッチパネルディスプレイやキーボード等の、文字入出力や用途選択等を可能とするためのユーザインターフェース、及びＷｅｂブラウズ機能やサーバー機能を更に有していてもよい。本実施形態に係る方法を採用可能な読取装置９の通信手段及びハードウェア構成等は、本実施形態における例示に限定されない。
【0021】
図２は、本実施形態に係る情報処理装置及び読取装置の機能構成の概略を示す図である。情報処理装置１は、記憶装置１４に記録されているプログラムが、ＲＡＭ１３に読み出され、ＣＰＵ１１によって実行されて、情報処理装置１に備えられた各ハードウェアが制御されることで、条件記憶部２１、媒体定義記憶部２２、表示制御部２３、帳票フォーム生成部２４、帳票リスト生成部２５、帳票記憶部２６、帳票フォーム選択部２７、データ取得部２８、照合部２９、帳票生成部３０及び出力部３１を備える。なお、本実施形態及び後述する他の実施形態では、情報処理装置１の備える各機能は、汎用プロセッサであるＣＰＵ１１によって実行されるが、これらの機能の一部又は全部は、１又は複数の専用プロセッサによって実行されてもよい。
【0022】
条件記憶部２１は、各帳票項目（項目の種類）について指定（定義）可能な１又は複数の記載条件（記載条件を定義した条件定義）を記憶する。本実施形態において、記載条件とは、帳票項目の項目データに関する条件である。記載条件は、例えば、取得されたユーザ情報（ユーザ情報に含まれる、帳票項目に対する入力データである入力情報）に基づいて項目データを記載する際の表現方法に関する条件及び／又は帳票項目の項目データを記載するための条件（項目データを記載する場合又はしない場合を示す条件）等である。以下、「項目データを記載する際の表現方法に関する条件」を「表現方法条件」と称し、「帳票項目の項目データを記載するための条件」を「記載するための条件」と称する。記載するための条件とは、帳票項目の項目データを記載するための、媒体（身分証明書）の種類に関する条件、及び／又は、帳票項目の項目データを記載するための、本人確認の結果に関する条件等である。詳細は後述するが、帳票フォーム生成部２４は、各帳票項目について、条件記憶部２１に記憶された記載条件の中からユーザが選択（選択入力）した記載条件を受け付けることで、各帳票項目についての記載条件が定義（指定）された帳票フォームを生成する。
【0023】
図３は、本実施形態に係る記載条件の一例を示す図である。図３に示すように、条件記憶部２１は、「氏名」、「住所」、「住所変更予備（変更後の住所）」、「生年月日」、「番号」、「有効期限」、「固定文字」等の帳票項目（項目の種類）毎に、定義可能な１又は複数の記載条件を記憶する。なお、図３に示すように、定義可能な記載条件として記憶される条件の数は、帳票項目毎に異なってよい。以下、各項目について定義可能な記載条件の一例を示す。但し、定義可能な記載条件は、下記の記載条件の例に限定されず、他の記載条件を含んでもよく、また、下記の記載条件の一部を含んでいなくてもよい。また、帳票項目（項目の種類）は、図３に例示した項目に限定されず、任意の項目であってよい。以下、氏名や住所、住所変更予備、生年月日、番号、有効期限、固定文字等の項目（帳票項目）の種類を、「項目種類」と称する。
【0024】
（帳票項目「氏名」についての記載条件）
図３では、帳票項目「氏名」について定義可能な記載条件として、「条件なし」、「空白を除去」、「空白を固定」、「アルファベット」が例示されている。「空白を除去」とは、帳票項目「氏名」に係る入力データ（入力情報）において氏と名との間に空白が存在する場合、この空白を除去した上で当該データを記載することを示す条件である。また、「空白を固定」とは、帳票項目「氏名」については、氏と名との間に、所定のサイズ（全角スペース１つ分等）の空白が入った状態で項目データを記載することを示す条件である。つまり、帳票項目「氏名」に係る入力データ（入力情報）の氏と名との間に空白がない場合は、所定のサイズの空白を入れた状態で当該データを記載することを示す。また「アルファベット」とは、帳票項目「氏名」に係る入力データ（入力情報）がアルファベット以外の文字種であった場合に、アルファベットに変換した上で当該データを記載することを示す条件である。なお、これら３つの条件は全て、上述した表現方法条件に該当する。
図３では、帳票項目「氏名」について定義可能な記載条件として、「条件なし」、「空白を除去」、「空白を固定」、「アルファベット」が例示されている。「空白を除去」とは、帳票項目「氏名」に係る入力データ（入力情報）において氏と名との間に空白が存在する場合、この空白を除去した上で当該データを記載することを示す条件である。また、「空白を固定」とは、帳票項目「氏名」については、氏と名との間に、所定のサイズ（全角スペース１つ分等）の空白が入った状態で項目データを記載することを示す条件である。つまり、帳票項目「氏名」に係る入力データ（入力情報）の氏と名との間に空白がない場合は、所定のサイズの空白を入れた状態で当該データを記載することを示す。また「アルファベット」とは、帳票項目「氏名」に係る入力データ（入力情報）がアルファベット以外の文字種であった場合に、アルファベットに変換した上で当該データを記載することを示す条件である。なお、これら３つの条件は全て、上述した表現方法条件に該当する。
【0025】
（帳票項目「住所」についての記載条件）
図３では、帳票項目「住所」について定義可能な記載条件として、「条件なし」、「都道府県を補完」、「番地を補完」、「背景塗りつぶし」が例示されている。「都道府県を補完」とは、帳票項目「住所」に係る入力データ（入力情報）において都道府県が省略されている場合、郵便番号や市町村情報等から都道府県情報を補完（追加）した上で、当該データを記載することを示す条件である。この条件は、例えば、都道府県情報を記載する必要のある帳票（申請書類等）において定義（選択）される条件である。「番地を補完」とは、帳票項目「住所」に係る入力データ（入力情報）において番地がハイフン（例えば、「１－２」等）で表現されている場合、「番」や「号」等の漢字を用いた表現（例えば、「１番２号」等）に変換した上で、当該データを記載することを示す条件である。この条件は、例えば、番地情報を記載する必要のある帳票（申請書類等）において定義される条件である。また、「背景塗りつぶし」とは、帳票項目「住所」の項目データを記載する領域の背景を塗りつぶすことを示す条件である。なお、「都道府県を補完」及び「番地を補完」は、上述した表現方法条件に該当する。記載条件には、上述した「背景塗りつぶし」のように、項目データが記載される領域に関する条件を含んでもよい。また、記載条件には、項目データとして記載する内容に関する条件を含んでもよい。
図３では、帳票項目「住所」について定義可能な記載条件として、「条件なし」、「都道府県を補完」、「番地を補完」、「背景塗りつぶし」が例示されている。「都道府県を補完」とは、帳票項目「住所」に係る入力データ（入力情報）において都道府県が省略されている場合、郵便番号や市町村情報等から都道府県情報を補完（追加）した上で、当該データを記載することを示す条件である。この条件は、例えば、都道府県情報を記載する必要のある帳票（申請書類等）において定義（選択）される条件である。「番地を補完」とは、帳票項目「住所」に係る入力データ（入力情報）において番地がハイフン（例えば、「１－２」等）で表現されている場合、「番」や「号」等の漢字を用いた表現（例えば、「１番２号」等）に変換した上で、当該データを記載することを示す条件である。この条件は、例えば、番地情報を記載する必要のある帳票（申請書類等）において定義される条件である。また、「背景塗りつぶし」とは、帳票項目「住所」の項目データを記載する領域の背景を塗りつぶすことを示す条件である。なお、「都道府県を補完」及び「番地を補完」は、上述した表現方法条件に該当する。記載条件には、上述した「背景塗りつぶし」のように、項目データが記載される領域に関する条件を含んでもよい。また、記載条件には、項目データとして記載する内容に関する条件を含んでもよい。
【0026】
（帳票項目「住所変更予備」についての記載条件）
図３では、帳票項目「住所変更予備（変更後の住所の記載欄）」について定義可能な記載条件として、「条件なし」、「画像を記載」、「ＯＣＲ結果を記載」が例示されている。「画像を記載」とは、帳票項目「住所変更予備」の項目データとして、変更後の住所が記載された箇所（住所記載欄）の画像を記載することを示す条件である。「ＯＣＲ結果を記載」とは、帳票項目「住所変更予備」の項目データとして、変更後の住所が記載された箇所の画像に対してＯＣＲ処理を行った結果を記載することを示す条件である。なお、これら２つの条件は、上述した表現方法条件に該当する。
図３では、帳票項目「住所変更予備（変更後の住所の記載欄）」について定義可能な記載条件として、「条件なし」、「画像を記載」、「ＯＣＲ結果を記載」が例示されている。「画像を記載」とは、帳票項目「住所変更予備」の項目データとして、変更後の住所が記載された箇所（住所記載欄）の画像を記載することを示す条件である。「ＯＣＲ結果を記載」とは、帳票項目「住所変更予備」の項目データとして、変更後の住所が記載された箇所の画像に対してＯＣＲ処理を行った結果を記載することを示す条件である。なお、これら２つの条件は、上述した表現方法条件に該当する。
【0027】
（帳票項目「生年月日」についての記載条件）
図３では、帳票項目「生年月日」について定義可能な記載条件として、「条件なし」、「和暦」、「西暦」、「背景塗りつぶし」が例示されている。「和暦」とは、帳票項目「生年月日」の項目データを和暦表記で記載することを示す条件である。「西暦」とは、帳票項目「生年月日」に係る項目データを西暦表記で記載することを示す条件である。「背景塗りつぶし」とは、帳票項目「生年月日」に係る項目データを記載する領域の背景を塗りつぶすことを示す条件である。なお、「和暦」と「西暦」は、上述した表現方法条件に該当する。
図３では、帳票項目「生年月日」について定義可能な記載条件として、「条件なし」、「和暦」、「西暦」、「背景塗りつぶし」が例示されている。「和暦」とは、帳票項目「生年月日」の項目データを和暦表記で記載することを示す条件である。「西暦」とは、帳票項目「生年月日」に係る項目データを西暦表記で記載することを示す条件である。「背景塗りつぶし」とは、帳票項目「生年月日」に係る項目データを記載する領域の背景を塗りつぶすことを示す条件である。なお、「和暦」と「西暦」は、上述した表現方法条件に該当する。
【0028】
（帳票項目「番号」についての記載条件）
図３では、帳票項目「番号」について定義可能な記載条件として、「条件なし」、「マイナンバーカードはセキュリティコードを記載」等が例示されている。「マイナンバーカードはセキュリティコードを記載」とは、後述する読取部８１により判別された身分証明書の種類がマイナンバーカードである場合には、マイナンバーカードから読み取られたセキュリティコードを記載すること、を示す条件である。本条件は、例えば、マイナンバーカードが機密情報であるため申請書への記載が適切でない場合に指定される条件である。なお、「マイナンバーカードはセキュリティコードを記載」は、上述した表現方法条件に該当する。
図３では、帳票項目「番号」について定義可能な記載条件として、「条件なし」、「マイナンバーカードはセキュリティコードを記載」等が例示されている。「マイナンバーカードはセキュリティコードを記載」とは、後述する読取部８１により判別された身分証明書の種類がマイナンバーカードである場合には、マイナンバーカードから読み取られたセキュリティコードを記載すること、を示す条件である。本条件は、例えば、マイナンバーカードが機密情報であるため申請書への記載が適切でない場合に指定される条件である。なお、「マイナンバーカードはセキュリティコードを記載」は、上述した表現方法条件に該当する。
【0029】
（帳票項目「有効期限」についての記載条件）
図３では、帳票項目「有効期限」については、定義可能な記載条件として、「条件なし」、「和暦」、「西暦」、「期限切れの通知」等が例示されている。「和暦」とは、帳票項目「有効期限」に係る項目データを和暦表記で記載することを示す条件である。「西暦」とは、帳票項目「有効期限」に係る項目データを西暦表記で記載することを示す条件である。「期限切れの通知」とは、帳票項目「有効期限」に係る入力データ（入力情報）に基づき対象の身分証明書が期限切れであると判定された場合に、期限切れであることを通知する（期限切れを示すマーク（＊印等）を記載する）ことを示す条件である。なお、「和暦」、「西暦」は表現方法条件に該当し、「期限切れ通知」は記載するための条件に該当する。但し、固定文字の種類（＊印等）の指定については、期限切れを＊印で表現することを意味するため、表現方法条件に該当する。
図３では、帳票項目「有効期限」については、定義可能な記載条件として、「条件なし」、「和暦」、「西暦」、「期限切れの通知」等が例示されている。「和暦」とは、帳票項目「有効期限」に係る項目データを和暦表記で記載することを示す条件である。「西暦」とは、帳票項目「有効期限」に係る項目データを西暦表記で記載することを示す条件である。「期限切れの通知」とは、帳票項目「有効期限」に係る入力データ（入力情報）に基づき対象の身分証明書が期限切れであると判定された場合に、期限切れであることを通知する（期限切れを示すマーク（＊印等）を記載する）ことを示す条件である。なお、「和暦」、「西暦」は表現方法条件に該当し、「期限切れ通知」は記載するための条件に該当する。但し、固定文字の種類（＊印等）の指定については、期限切れを＊印で表現することを意味するため、表現方法条件に該当する。
【0030】
（帳票項目「固定文字」についての記載条件）
図３では、帳票項目「固定文字」について定義可能な記載条件として、「条件なし」、「所定の身分証明書であること」、「期限切れであること」、「本人確認がＮＧであること」が例示されている。「所定の身分証明書であること」には、該当する身分証明書の種類が指定される。例えば、「マイナンバーカードであること」等の条件が指定される。例えば、「マイナンバーカードであること」と指定された条件は、読み取られた身分証明書（の種類）がマイナンバーカードである場合に限り、固定文字（例えば〇印）を記載することを示す条件である。「期限切れであること」とは、例えば、有効期限が期限切れであると判定された場合に限り、固定文字（例えば＊印）を記載することを示す条件である。「本人確認がＮＧであること」は、身分証明書に基づく本人確認の結果がＮＧである場合に限り、固定文字（例えば※印）を記載することを示す条件である。なお、これら３つの条件は全て、上述した、記載するための条件に該当する。但し、固定文字の種類の指定については、マイナンバーカードであることや、期限切れであること、本人確認がＮＧであることを、夫々、〇印、＊印、※印で表現することを意味するため、夫々、表現方法条件に該当する。
図３では、帳票項目「固定文字」について定義可能な記載条件として、「条件なし」、「所定の身分証明書であること」、「期限切れであること」、「本人確認がＮＧであること」が例示されている。「所定の身分証明書であること」には、該当する身分証明書の種類が指定される。例えば、「マイナンバーカードであること」等の条件が指定される。例えば、「マイナンバーカードであること」と指定された条件は、読み取られた身分証明書（の種類）がマイナンバーカードである場合に限り、固定文字（例えば〇印）を記載することを示す条件である。「期限切れであること」とは、例えば、有効期限が期限切れであると判定された場合に限り、固定文字（例えば＊印）を記載することを示す条件である。「本人確認がＮＧであること」は、身分証明書に基づく本人確認の結果がＮＧである場合に限り、固定文字（例えば※印）を記載することを示す条件である。なお、これら３つの条件は全て、上述した、記載するための条件に該当する。但し、固定文字の種類の指定については、マイナンバーカードであることや、期限切れであること、本人確認がＮＧであることを、夫々、〇印、＊印、※印で表現することを意味するため、夫々、表現方法条件に該当する。
【0031】
以上の通り、表現方法条件には、例えば、文字の種類に関する条件（漢字、アルファベット等）、日付の表現形式に関する条件（西暦、和暦等）、時刻のデータ形式に関する条件、入力情報に基づいて項目データを記載する際のデータ補完の要否に関する条件（都道府県を補完等）、入力情報に基づいて項目データを記載する際の入力情報の一部データ削除の要否に関する条件、入力情報に基づいて項目データを記載する際の入力情報の他のデータとの入れ替え（置換）の要否に関する条件、画像で記載することを指定する条件及び文字認識結果で記載することを指定する条件等のうち、少なくとも一つの条件を含んでよい。
【0032】
媒体定義記憶部２２は、媒体の種類毎に媒体に記録される各記録項目についての表現方法を定義した媒体定義（証明書定義）を記憶する。身分証明書では、身分証明書の種類によって、記載される情報についての文字の種類や、記載される箇所、情報の記載度合い等が異なる場合がある。そのため、本実施形態に係る媒体定義（媒体定義情報）では、複数の身分証明書における記録項目の表現方法の違いが定義される。より具体的には、媒体定義には、身分証明書に記録される項目である各記録項目の、当該身分証明書における表現方法が、身分証明書の種類毎に記憶される。本実施形態において、記録項目の表現方法とは、身分証明書において記録項目のデータ（情報）がどのように表現されるか（表現方法）を意味する。表現方法としては、表現形式（使用される文字の種類や、日付や時刻の形式、記録される情報の程度（例えば、住所についての「都道府県のみ」）等）や情報の記載面（表面、裏面）等が例示され、媒体定義において定義される表現方法は、これらの表現方法のうち少なくとも何れかであってよい。なお、媒体定義には、表現方法に加え、番号の種類（意味合い）や有効期限の種類（意味合い）等のように、記録されている情報の種類（意味合い）が定義されてもよい。
【0033】
図４は、本実施形態に係る媒体定義の一例を示す図である。図４に示すように、媒体定義には、身分証明書毎に、身分証明書に記録（記載）される各項目の表現方法が定義される。例えば、図４に示すように、マイナンバーカードの場合、記録項目「氏名」、「住所」、「住所変更予備」及び「生年月日」及び「番号」の表現方法として、夫々、「漢字（外字あり）」、「空白」、「表面（手書き）」、「和暦、西暦（外国籍の場合）」及び「なし（表面）、マイナンバー（裏面）」が定義される。この場合、「漢字（外字あり）」は、記録項目である氏名が、漢字（但し外字あり）で記録されることを示す。「空白」は、住所の一部が省略されず記載されることを示す。「表面に手書き」は、記録項目である住所変更予備（変更後の住所）が、マイナンバーカード（身分証明書）の表面に手書きで記録（記載）されることを示す。「和暦、西暦（外国籍の場合）」は、記録項目である生年月日が、カード所有者が外国籍でない場合は和暦で記録され、外国籍の場合は西暦で記載されることを示す。「なし（表面）、マイナンバー（裏面）」は、記録項目である番号（マイナンバー）が、マイナンバーカードの表面には記載されず、裏面に記載されることを示す。
【0034】
また、図４に示す媒体定義には、身分証明書における各記録項目についての表現方法に加え、身分証明書に記録される番号の種類（「マイナンバー」、「運転免許証番号」、「在留番号」、「旅券番号」等）や有効期限の種類（「利用期限」、「運転期限」、「在留期限」、「パスポート期限」等）等の、情報の種類（意味合い）が定義されている。
【0035】
マイナンバーカードと同様に、運転免許証、在留カード及びパスポート等の各種身分証明書における表現方法が、媒体定義において定義される（図４を参照）。例えば、図４に示すように、運転免許証の場合、記録項目「住所」の表現方法として、「都道府県を省略する場合あり」が定義される。「都道府県を省略する場合あり」は、記録項目である住所について、都道府県が省略されて記載される場合があることを示す。また、例えば、図４に示すように、パスポートの場合、記録項目「氏名」の表現方法として、「アルファベット」が定義される。「アルファベット」は、記録項目である氏名が、アルファベットで記録されることを示す。また、図４に示すように、パスポートの場合、記録項目「住所」の表現方法として、「都道府県のみ」が定義される。「都道府県のみ」は、記録項目である住所について、都道府県のみが記載されることを示す。また、例えば、図４に示すように、パスポートの場合、記録項目「住所変更予備」の表現方法として、「記載なし」が定義される。「記載なし」は、記録項目である住所変更予備（変更後の住所）が、パスポートには記載されないことを示す。なお、記録項目は、図４に示した記録項目に限定されず、任意の項目が含まれていてよい。
【0036】
表示制御部２３は、出力デバイス１６を介して、各種画面を表示させる。例えば、表示制御部２３は、帳票フォーム生成画面や、帳票リスト生成画面、帳票フォーム選択画面（用途選択画面）、出力イメージ確認画面等を表示させる。表示制御部２３により表示される各種画面の詳細については、後述する。
【0037】
帳票フォーム生成部２４は、帳票の様式等を定義した帳票フォームを１以上生成する。帳票フォーム生成部２４は、帳票における複数の帳票項目の帳票項目毎に、帳票項目の項目データの記載位置と、当該記載位置に記載される当該帳票項目の項目データに関する記載条件とを定義した帳票フォームを生成する。本実施形態における「帳票フォーム（帳票定義（情報））」は、帳票の見た目や帳票項目定義等の帳票の様式を定義した情報（帳票様式情報）と、帳票の出力方法や出力時の動作等を定義した情報とから構成される情報（出力情報）とから構成される。但し、実施の態様によっては、出力情報を含まない帳票定義情報であってもよい。本実施形態では、帳票フォーム（帳票レイアウト）を生成する方法として、下敷きデータ（下敷きイメージ等）を用いる方法を例示する。なお、下敷きデータを用いる場合、下敷きデータに沿ってユーザが罫線や固定文字列等をレイアウトすることで帳票フォームを作成してもよく、また、下敷きデータ自体を出力対象としてもよい。本実施形態では、一例として、下敷きデータ自体を出力対象とする。つまり、下敷きデータの上に項目を定義するだけで帳票フォーム（帳票レイアウト）を生成する方法を例示する。以下、下敷きデータを用いた帳票フォーム生成方法について例示する。帳票フォーム生成部２４は、下敷きデータ取得部２４１、入力受付部２４２及び生成部２４３を備える。
【0038】
下敷きデータ取得部２４１は、ユーザ（帳票フォーム作成者）から、帳票のレイアウトの下敷き（帳票のベース）となる下敷きデータを取得する。下敷きデータは、任意のデータ形式であってよい。下敷きデータは、例えば、紙媒体の帳票を撮像することで得られた帳票画像（ビットマップデータやＪＰＥＧデータ等のイメージデータ）や、Ｗｏｒｄファイル（データ）、Ｅｘｃｅｌファイル（データ）、ＰＤＦファイル（データ）等であってよい。また、下敷きデータは、画像に対してＯＣＲ処理を行うことにより得られる電子ファイルであってもよい。例えば、市役所等で使用される紙媒体の申請書類がスキャンされることで得られたスキャン画像を、下敷きデータとして採用することが可能である。
【0039】
図５及び図６は、本実施形態に係る下敷きデータの一例を示す図である。図５には、下敷きデータとして、１ページ（１枚）からなる住民票申請書をスキャンすることで得られたスキャン画像を示す。また、図６には、下敷きデータとして、２ページ（２枚）からなる住民票申請書をスキャンすることで得られたスキャン画像を示す。このような下敷きデータが、表示制御部２３により帳票フォーム生成画面に表示されると、ユーザ（帳票フォーム作成者）は、当該下敷きデータ上に項目を定義するだけで帳票フォームを容易に作成することが可能である。なお、帳票フォーム生成部２４により生成される帳票フォームには、同一のレイアウト（帳票の見た目）に対して互いに異なる項目定義が組み合わせられた複数の帳票フォームが含まれてもよい。例えば、後述するように、階層構造の最下層より上の層において同一の用途要素を有する複数の用途に夫々対応させる複数の帳票フォームとして、同一の下敷きデータに対して互いに異なる項目定義が組み合わせられた複数の帳票フォームを生成することが可能である。
【0040】
入力受付部２４２は、ユーザ（帳票フォーム作成者）から、各帳票項目に関する、項目データの記載位置（記載領域）、項目種類（項目名等）及び１又は複数の記載条件についての入力（選択入力を含む）を受け付ける。ユーザは、所望する帳票の帳票フォームを生成する（帳票項目の定義を行う）ために、下敷きデータにおいて、帳票項目の項目データの記載領域の指定、項目種類の選択、及び帳票項目に対する１又は複数の記載条件の選択（選定）を行う。ユーザはこれらの操作を各帳票項目について行う。なお、ユーザは、例えば、表示制御部２３により表示される帳票フォーム生成画面に下敷きデータが表示された状態で、上記操作を行う。
【0041】
図７は、本実施形態に係る下敷きデータを用いて項目定義を行う方法（本人申請の場合）についての説明を行うための図である。図７の太枠で示すように、ユーザは、例えば、項目種類である「住所」、「氏名」、「生年月日」、「固定文字（身分証明書の種類が記載された箇所）」、「番号（括弧の箇所）」の夫々について、帳票の中の記載領域の指定を行う。当該操作が行われると、入力受付部２４２は、この記載領域の指定（入力）を受け付ける。記載領域の指定方法には任意の方法が用いられてよく、例えば、下敷きデータ上で所望する領域をマウスドラッグで指定する方法や座標指定を行う方法が用いられる。また、下敷きデータがエクセルファイルである場合、領域指定として、セル指定を行う方法が用いられてもよい。なお、図７における点線枠の領域は、例えば、変更後の住所が記載される領域（住所変更予備の領域）として指定されてもよい。
【0042】
ユーザは、領域指定した帳票項目の夫々について、項目種類と記載条件の選択（選択入力）を行う。例えば、定義可能な項目種類を含むリストが帳票フォーム生成画面（項目種類選択画面）に表示されると、ユーザは、当該リストから、定義したい項目種類を選択する。項目種類は、例えば、氏名、住所、住所変更予備、生年月日、作成日時、固定文字等である。また、例えば、帳票項目について定義可能な１又は複数の記載条件（図３を参照）を含むリストが帳票フォーム生成画面（記載条件選択画面）に表示されると、ユーザは、当該リストから、定義したい記載条件を選択する。なお、帳票項目に対して選択（定義）される記載条件の数は、１つであっても複数であってもよい。また、選択（定義）される記載条件の数は、帳票項目間で異なっていてもよい。ユーザにより、項目種類と記載条件の選択が行われると、入力受付部２４２は、これらの選択（選択入力）を受け付ける。
【0043】
なお、上述の通り、同一の下敷きデータに対して互いに異なる項目定義がなされた複数の帳票フォームが生成されてよい。例えば、図７では、本人申請の場合の領域指定について例示したが、代理人申請の場合は、図７に示す下敷きデータ（図５の下敷きデータ）に対して、図７とは異なる項目定義が行われてよい。
【0044】
図８は、本実施形態に係る下敷きデータを用いて項目定義を行う方法（代理人申請の場合）についての説明を行うための図である。図７と同様に、項目種類である「住所」、「氏名」、「生年月日」、「固定文字」、「番号」の夫々について記載領域の指定が行われている。図７では、本人申請の欄（本人記載の領域）に該当する、「住所」、「氏名」及び「生年月日」の領域が指定されているが、図８では、代理人申請の欄（代理人記載の領域）に該当する、「住所」、「氏名」及び「生年月日」の領域が指定されている。このように、同一の下敷きデータに対して、互いに異なる項目定義がなされた複数の帳票フォームが生成されてよい。
【0045】
図９は、本実施形態に係る下敷きデータを用いて項目定義を行う方法（本人申請の場合）についての説明を行うための図である。図１０は、本実施形態に係る下敷きデータを用いて項目定義を行う方法（代理人申請の場合）についての説明を行うための図である。図９及び図１０では、２ページからなる住民票申請書の下敷きデータ（図６の下敷きデータ）に対して、項目データの記載領域が指定されている。図９及び図１０では、項目種類である「住所」、「氏名」、「固定文字」及び「番号」の夫々について、記載領域の指定が行われている。
【0046】
図１１は、本実施形態に係る帳票フォーム生成画面の一例である。図１１に示すような帳票フォーム生成画面が、表示制御部２３により表示される。ユーザは、この帳票フォーム生成画面において、上述の通り各帳票項目についての項目定義を行うようにしてよい。図１１では、各フィールド（領域）が設定されており、項目種類「氏名」についての項目属性（例えば、項目名、最大フォントサイズ等）が定義されている状態を示す。
【0047】
生成部２４３は、下敷きデータ取得部２４１により取得された下敷きデータと、入力受付部２４２により受け付けられた記載位置、項目種類及び記載条件とを組み合わせた帳票フォームを生成する。
【0048】
図１２は、本実施形態に係る帳票フォームの項目定義の一例を示す図である。図１２では、一例として、帳票中の９つのフィールド（帳票項目）の属性が定義された項目定義を示す。図１２に示す帳票フォーム（項目定義）では、各フィールドについて、項目種類、記載位置（領域）及び記載条件が定義されている。領域には、ユーザにより指定された領域の領域情報（例えば、帳票における位置（Ｘ座標、Ｙ座標）とその領域の大きさ（幅や高さ））が定義されている。なお、領域情報は、例えば、ユーザが帳票フォーム生成画面においてマウスドラッグで領域指定を行うと、自動的に抽出されるようにしてもよい。また、図１２では、記載条件の一例として、帳票項目の項目データを記載するための条件（記載するための条件）と、項目データを記載する際の表現方法に関する条件（表現方法条件）と、帳票項目のデータが記載される領域に関する条件とが定義される。なお、図１２では、項目属性として、フォントの種類やフォントサイズ等についての定義を行っていないが、必要に応じてこれらの属性も定義されることとする。
【0049】
図１２では、記載するための条件として、例えば、フィールド１について、項目種類「氏名」、領域「ｘ１，ｙ１，ｗ１，ｈ１」、記載するための条件「すべて」、表現方法条件「条件なし」、及び領域に関する条件「なし」が定義されている。記載するための条件「すべて」は、項目種類「氏名」の項目データについては、どの種類の身分証明書であっても記載対象とすること示す。表現方法条件「条件なし」は、項目種類「氏名」の項目データに対する表現方法条件はないことを示している。領域に関する条件「なし」は、項目種類「氏名」の項目データが記載される領域の背景の塗りつぶしをしないことを示す。また、例えば、フィールド７について、項目種類「固定文字」、領域「ｘ７，ｙ７，ｗ７，ｈ７」、記載するための条件「マイナンバーカード」、表現方法条件「固定文字：〇」、及び領域に関する条件「なし」が定義されている。表現方法条件「固定文字：〇」は、項目種類「固定文字」の項目データを、固定文字である「〇」とすることを示す。なお、フィールド５の項目種類「作成日時」には、身分証明書が読み取られた日時が項目データとして記載される。
【0050】
なお、上記では、下敷きデータを用いて帳票フォームを生成する方法を例示したが、帳票フォームは、下敷きデータを用いず生成されてもよい。その場合、ユーザ（帳票フォーム作成者）は、罫線や帳票に固定して記載される文字列等を決定することにより帳票のレイアウト（見た目）を生成すればよい。
【0051】
帳票リスト生成部２５は、帳票の用途（帳票を作成するユーザの用途（やりたいこと））を定義した帳票リスト（用途リスト）を生成する。帳票リストは、最上層と最下層を含む複数の階層からなる階層構造で構成され、帳票リストに含まれる各用途は、１又は複数の階層で特定（構成）される。つまり、各用途は、各階層の用途要素により一意に特定される。本実施形態では、二階層からなる階層構造（最上層と最下層のみからなる階層構造）で構成される帳票リストを例示する。そのため、各用途は、一階層又は二階層で特定される。以下、最上層を「カテゴリ１」、最下層を「カテゴリ２」と称する。なお、階層数は２に限定されず、３以上であってよい。
【0052】
図１３は、本実施形態に係る帳票リストの一例を示す図である。図１３では、二階層で構成される帳票リストを例示しており、カテゴリ１の用途要素として、「住民票申請」、「転入申請」、「印鑑証明」及び「マイナンバーカードの更新」が例示されている。住民票申請に関する用途は、二つの階層（カテゴリ）からなる用途として定義されており、帳票リストにおいて、カテゴリ１の用途要素である「住民票申請」に紐づくカテゴリ２の用途要素として、「本人用」及び「代理人用」が定義されている。つまり、カテゴリ１「住民票申請」及びカテゴリ２「本人用」により、本人による住民票申請という用途が定義（特定）され、カテゴリ１「住民票申請」及びカテゴリ２「代理人用」により、代理人による住民票申請という用途が定義（特定）されている。同様に、転入申請に関する用途は、二つの階層からなる用途として定義されており、帳票リストにおいて、カテゴリ１の用途要素である「転入申請」に紐づくカテゴリ２の用途要素として、「市外からの引っ越し」、「市内からの引っ越し」及び「国外からの引っ越し」が定義されている。
【0053】
また、印鑑証明に関する用途は、一つの階層からなる用途として定義されており、帳票リストにおいて、カテゴリ１の用途要素である「印鑑証明」に紐づくカテゴリ２の用途要素は定義されていない（省略される）。また、同様に、マイナンバーカードの更新に関する用途は、一つの階層からなる用途として定義されているが、カテゴリ１の用途要素である「マイナンバーカードの更新」に対して、カテゴリ２の用途要素として「マイナンバーカードをお持ちですか？」が定義されている。これは、カテゴリ１に紐づくカテゴリ２（最上層に紐づくカテゴリ）の用途要素が１つのみである場合に、ユーザに対して注意（確認）を促す画面（例えば、ユーザが選択した用途で帳票を作成しても良いことを確認（同意）させる画面）が表示されることを意味している。図１３の例では、ユーザがカテゴリ１の用途要素として「マイナンバーカードの更新」を選択した場合、「マイナンバーカードをお持ちですか？」とのメッセージを含む画面が表示される。
【0054】
このように、階層構造は、手続きの種類を示す用途要素（「住民票申請」、「印鑑証明」等の申請書種別）の層と、当該手続きの種類に関する層の下層に位置する、ユーザ（手続きを行うユーザ又は手続きの対象者）の属性を示す用途要素（「本人」、「代理人」、「市外からの引っ越し」等）の層と、を含むものであってよい。但し、階層構造はこの例に限定されず、任意の種類の用途要素の層から構成されてよい。また、帳票リストに含まれる用途は、任意の用途であってよい。また、ユーザ（システムの設置者等）は、帳票リスト及び帳票リストに保持される用途（用途要素）を必要に応じて、変更、追加、削除することが可能である。
【0055】
また、図１３に示すように、各用途には、１以上の帳票フォームが対応付け（紐づけ）られている。例えば、カテゴリ１「住民票申請」及びカテゴリ２「本人用」により定義された、本人による住民票申請という用途に対して、「住民票申請（本人）」及び「住民票申請（共通裏面）」の２つの帳票フォームが対応付けられている。また、同様に、カテゴリ１「住民票申請」及びカテゴリ２「代理人用」により定義された、代理人による住民票申請という用途に対して、「住民票申請（代理人）」及び「住民票申請（共通裏面）」の２つの帳票フォームが対応付けられている。このように、１つの用途に対して、複数の帳票フォームが対応付けられてよい。
【0056】
また、例えば、カテゴリ１「転入申請」及びカテゴリ２「市外からの引っ越し」により定義された、転入申請（市外から）という用途に対して、「転入申請（市外から）」の帳票フォームが対応付けられている。また、カテゴリ１「印鑑証明」により定義された、印鑑証明という用途に対して、「印鑑証明書」という１つの帳票フォームが対応付けられている。また、カテゴリ１「マイナンバーカードの更新」により定義されたマイナンバーカードを更新する用途に対して、「マイナンバーカードの更新申請書」という１つの帳票フォームが対応付けられている。このように、後述する帳票記憶部２６は、各用途（各用途の最下層の用途要素）に対して、１又は複数の帳票フォームを対応付けて記憶しておく。以下、帳票リストの生成、及び、用途と帳票フォームとの対応付けを行う方法について例示する。
【0057】
図１４は、本実施形態に係る帳票リスト生成画面（カテゴリ１の生成画面）の一例を示す図である。図１４では、カテゴリ１の用途要素として、「住民票申請」、「印鑑証明」及び「転入手続き」が生成された例を示す。このように、ユーザ（システムの設置者等）は、帳票リスト生成画面上で、カテゴリ１の用途要素に対応する表示（ボタン等）を生成する。
【0058】
図１５は、本実施形態に係る帳票リスト生成画面（カテゴリ２の生成画面）の一例を示す図である。図１５では、カテゴリ１の用途要素「住民票申請」に対するカテゴリ２の用途要素として、「申請者本人の申請」及び「代理人の方による申請」が生成された例を示す。このように、ユーザ（システムの設置者等）は、帳票リスト生成画面上で、カテゴリ２の用途要素に対応する表示（ボタン等）を生成する。
【0059】
図１６は、本実施形態に係る帳票リスト生成画面（帳票フォームとの対応付け画面）の一例を示す図である。図１６では、カテゴリ１の用途要素「住民票申請」及びカテゴリ２の用途要素「申請者本人の申請」で定義（特定）される用途に対して対応付ける帳票フォーム（帳票定義）の選択画面を示す。図１６に示された画面において、ユーザは、帳票定義名が「住民票申請（本人）」である帳票定義を選択することで、カテゴリ１の用途要素「住民票申請」及びカテゴリ２の用途要素「申請者本人の申請」で特定される用途と、帳票定義名が「住民票申請（本人）」である帳票フォームとを対応付けることが可能である。なお、図１４から図１６では、画面上で帳票リストの生成及び対応付け処理を行う場合について例示したが、帳票リストの生成及び対応付け処理は、画面を使用することなく行われてもよい。例えば、これらの処理を、エクセルファイル（表）やテキストファイル等を用いることで行うようにしてもよい。
【0060】
図１７は、本実施形態に係る用途と対応付けられた帳票フォームの概要の一例を示す図である。図１７では、カテゴリ１の用途要素が「住民票申請」である場合、その下層のカテゴリ２の用途要素として「本人用」と「代理人用」が例示されるが、本人が申請する場合（本人用の場合）と、代理人が申請する場合（代理人用の場合）では、対応付けられている帳票フォームに違いがある。具体的には、両者は、住民票申請の表面について、使用される下敷きデータは共通であるが、項目の定義（氏名及び住所の記載位置や、窓口に来られた方についての記載有無）に違いがある。このように、階層構造の最下層より上の層において同一の用途要素（例えば、「住民票申請」）を有する複数の用途に夫々対応させる複数の帳票フォームとして、同一の下敷きデータに対して互いに異なる項目定義が組み合わせられた複数の帳票フォームを生成することが可能である。なお、住民票申請の裏面については、本人用の場合と代理人用の場合とで、対応付けられている帳票フォームに違いはない（同一の帳票フォームが対応付けられている）。
【0061】
このように、階層化された用途の最下層の用途要素と、当該用途に適した帳票フォームとを対応付けることで、ユーザの用途に適した帳票フォームを選択し提示することが可能となる。また、ユーザ（利用者）は、やりたいことを階層的に選択することが可能となる。
【0062】
帳票記憶部２６は、帳票の用途（利用者の用途）と１以上の帳票フォームを記憶する。帳票記憶部２６は、帳票フォーム記憶部２６１及び帳票リスト記憶部２６２を備える。帳票フォーム記憶部２６１は、帳票フォーム生成部２４により生成された、帳票の様式を定義した帳票フォーム（「住民票申請（本人）」、「住民票申請（代理人）」等）を記憶する。なお、帳票フォーム記憶部２６１は、外部装置において生成された帳票フォームを記憶してもよい。帳票リスト記憶部２６２は、帳票リスト生成部２５により生成された帳票リストを記憶する。帳票記憶部２６は、用途毎に、用途（最下層の用途要素）と当該用途に適した１以上の帳票フォームとを対応付けて記憶する。図１６で示すように、画面上でユーザが用途に対応付ける帳票フォームを選択すると、帳票リストにおいて、選択された帳票フォームのフォーム名が、対応する用途（最下層の用途要素）に対応付く形で記憶（格納）されるようにしてもよい（図１３を参照）。また、他の方法として、図１３に示すように帳票リストに対して帳票フォームのフォーム名が対応付けられた表をユーザが作成することで、用途と帳票フォームが対応付けられて記憶されるようにしてもよい。
【0063】
帳票フォーム選択部２７は、帳票（帳票データ）を生成するための帳票フォームを選択する。帳票フォーム選択部２７は、ユーザから、帳票フォームの選択に係る入力を受け付けることで、帳票を生成するための帳票フォームを、帳票フォーム記憶部２６１に記憶された帳票フォームの中から選択する。本実施形態では、帳票フォーム選択部２７は、用途選択受付部２７１及び選択部２７２を備える。用途選択受付部２７１は、帳票フォームの選択に係る入力として、ユーザから用途要素の選択入力を受け付ける。より具体的には、用途選択受付部２７１は、最上層から順に最下層までの用途要素の選択をユーザから受け付けることで、ユーザの用途選択を受け付ける。なお、用途選択受付部２７１は、ユーザから、１又は複数の用途を受け付ける。選択部２７２は、ユーザにより選択された最上層から最下層までの用途要素により特定される用途（選択された用途）に対応する１以上の帳票フォームを、ユーザの用途（選択された用途）に適した１以上の帳票データを生成するための帳票フォームとして選択する。なお、選択部２７２は、帳票フォーム記憶部２６１に記憶された帳票フォームの中から、ユーザの用途に対応する１以上の帳票フォームを選択する。
【0064】
図１８は、本実施形態に係る帳票フォーム選択画面（用途要素（カテゴリ１）の選択画面）の一例を示す図である。図１８に示すような帳票フォーム選択画面において、ユーザは、申請書類（カテゴリ１の用途要素）を１又は複数選択することが可能である。図１８では、全てのカテゴリ１の用途要素である「住民票申請」、「印鑑証明」、「転入手続き」及び「転出手続き」についてのボタンが表示（配置）されている。なお、図１８では、カテゴリ１の用途要素として、「住民票申請」と「印鑑証明」とがユーザにより選択された（「住民票申請」のカテゴリ２の用途要素も選択済みの）状態を示す。この状態で、ユーザにより「転入手続き」のボタンが押下される（それに伴いチェックマークが表示される）と、カテゴリ１の用途要素「転入手続き」に紐づくカテゴリ２の用途要素を選択する画面（図１９を参照）が表示される（画面が遷移する）。
【0065】
図１９は、本実施形態に係る帳票フォーム選択画面（用途要素（カテゴリ２）の選択画面）の一例を示す図である。図１９に示すような帳票フォーム選択画面において、ユーザは、カテゴリ２の用途要素を１又は複数選択することが可能である。図１９では、カテゴリ１の用途要素「転入手続き」に対するカテゴリ２の全ての用途要素である「市外からのお引越し」、「市内の他の区からのお引越し」及び「国外からのお引越し」についてのボタンが表示（配置）されている。図１９に示す画面において、ユーザが所望する用途要素が選択され（ボタンが押下され）、「確認」ボタンが押下されると、用途について最上層から最下層まで選択されたため、カテゴリ１の用途要素を選択する画面（図１８を参照）に遷移する（戻る）。つまり、所望の用途についての用途要素が最上層から最下層まで選択されると、ユーザは別の用途を選択可能となる。ユーザが所望する全ての用途が選択された場合、遷移した画面（図１８を参照）において、「次に進む」ボタンがユーザにより押下される。
【0066】
このように、ユーザにより用途が選択されると、用途選択受付部２７１は、ユーザによる用途の選択入力を受け付ける。また、ユーザによる用途の選択操作が終了すると、選択された用途に対応する帳票フォームが選択部２７２により選択される。なお、ユーザが複数の用途（例えば、印鑑証明と、転入手続き（市外からのお引越し）と、住民票申請（本人用））を選択した場合、選択部２８２は、各用途について対応付けられている帳票フォームを選択する。つまり、選択部２８２は、選択された複数の用途に対応する複数の帳票フォームを、ユーザの複数の用途に適した複数の帳票データを生成するための複数の帳票フォームとして選択する。この場合、当該複数の帳票フォームに対して入力データ（入力情報）が配置されることで、入力データが配置された複数の帳票データが生成される。このように、ユーザは、複数の用途を、同時に選択することが可能である。なお、本実施形態では、図１８の画面における「次に進む」ボタンが押下されることで、読取部８１による身分証明書の読取処理が開始される。
【0067】
なお、図１８及び図１９の帳票フォーム選択画面において表示される用途要素の表示（「市外からのお引越し」等）には、帳票リストに格納されている用途要素のデータ（用途要素名）がそのまま用いられてもよいし、表示用に用意されたデータ（要素名）が用いられても良い。この場合、帳票リストに格納されている用途要素のデータ（用途要素名）と、表示用に用意されたデータ（要素名）とを対応付けて記憶しておくこととする。
【0068】
データ取得部２８は、帳票に記載される対象のデータ（入力データ）を取得する。本実施形態では、データ取得部２８は、入力データとして、ユーザ情報が記録された読取対象の媒体（身分証明書）に記録された当該ユーザ情報を取得する。また、データ取得部２８は、読取対象の媒体の種類（媒体種類の情報）及び本人確認の結果を示す情報を取得する。データ取得部２８は、後述するデータ送信部８３から送信されたこれらの情報を受信（取得）する。
【0069】
図２０は、本実施形態に係る読取項目についての読取データの一例を示す図である。図２０の例では、各列が夫々、１つの身分証明書の読取データ（読み取られたユーザ情報）を示している。図２０の例では、データ取得部２８は、「氏名」、「住所」、「生年月日」、「性別」及び「番号」等の読取項目について、夫々、「ＡＡ ＢＢ」、「ＣＣＣＣＣＣＣ」、「ＤＤＤＤ年Ｅ月Ｆ日」、「男」、「ＧＧＧＧＧＧ」等のデータを取得する。なお、読取データの形式は、図２０に示した形式に限定されず、任意の形式が採用されてよい。データ取得部２８は、図２０に示されるようなユーザ情報と併せて、身分証明書の種類及び本人確認の結果を示す情報を取得する。
【0070】
照合部２９は、帳票フォームで定義された帳票項目に係る記載条件と、読取対象の媒体（身分証明書）に基づいて得られる当該帳票項目に関連する情報（以下、「媒体情報」と称する）とを照合する。照合部２９は、帳票フォーム選択部２７により選択された帳票フォームにおける複数の帳票項目の帳票項目毎に、記載条件と媒体情報との照合を行う。媒体情報及び照合方法については、帳票生成方法と併せて詳細を後述する。
【0071】
帳票生成部３０は、帳票フォーム選択部２７により選択された１以上の帳票フォームに対してデータ（媒体に記録されたユーザ情報や固定文字等の項目データ）を配置する（埋め込む）ことで、当該データが記載された１以上の帳票データを生成する。本実施形態では、帳票生成部３０は、照合部２９による照合結果に応じて、帳票項目の記載位置における記載内容を異ならしめる。データを記載位置に記載（配置）する方法には、任意の方法が用いられてよく、例えば、データに係るテキストオブジェクトを下敷きデータ（複製した下敷きデータ）に配置する方法や、エクセル等の場合、指定されたセル（領域）にデータを入力する方法等が用いられてよい。
【0072】
ここで、本実施形態では、記載条件と照合する対象である媒体情報として、（１）身分証明書から読み取られた情報（ユーザ情報）、（２）判別された身分証明書の種類に対して定義された記録項目の表現方法、（３）判別された身分証明書の種類、及び（４）身分証明書に基づき得られる本人確認結果を例示する。以下、上記（１）～（４）の夫々の場合の照合方法と、夫々の場合の帳票生成方法について、説明する。以下、選択された帳票フォームが、図１２に示された帳票フォーム（項目定義）であり、身分証明書から読み取られた情報が、図２０に示された情報である場合を例示する。上記（１）～（４）は、以下で説明するケース１～ケース４の場合に夫々対応する。なお、上記（１）～（４）は、媒体情報の一例であり、媒体情報は他の情報を含んでもよい。また、ケース１～ケース４は、記載条件と媒体情報との照合方法及び帳票生成方法（項目データ記載方法）の一例であり、記載条件と媒体情報との照合方法及び帳票生成方法は、以下のケース１～ケース４に限定されない。
【0073】
（ケース１：記載条件とユーザ情報との照合）
ケース１では、照合部２９は、帳票項目に係る記載条件（表現方法条件）と、身分証明書から読み取られたユーザ情報（当該帳票項目に対する入力情報）とを照合する。照合対象の記載条件は、帳票フォームにおいて定義されている表現方法条件である。また、照合対象の入力情報は、データ取得部２８により取得された情報である。照合部２９は、表現方法条件と入力情報とを照合することで、入力情報の表現方法を表現方法条件に合わせて変更（文字種の変換やデータ補完等）する必要があるか否かを判定する。
ケース１では、照合部２９は、帳票項目に係る記載条件（表現方法条件）と、身分証明書から読み取られたユーザ情報（当該帳票項目に対する入力情報）とを照合する。照合対象の記載条件は、帳票フォームにおいて定義されている表現方法条件である。また、照合対象の入力情報は、データ取得部２８により取得された情報である。照合部２９は、表現方法条件と入力情報とを照合することで、入力情報の表現方法を表現方法条件に合わせて変更（文字種の変換やデータ補完等）する必要があるか否かを判定する。
【0074】
例えば、照合部２９は、項目種類「住所」についての表現方法条件である「都道府県を補完」と、住所に係る入力情報「ＣＣＣＣＣＣＣ」とを照合する。入力情報「ＣＣＣＣＣＣＣ」が都道府県情報を省略した住所表記である場合、照合部２９は、入力情報の表現方法を変更（都道府県情報を補完）する必要があると判定する。また、例えば、照合部２９は、項目種類「生年月日」についての表現方法条件である「西暦」と、生年月日に係る入力情報「ＤＤＤＤ年Ｅ月Ｆ日（西暦表記）」とを照合する。この場合、生年月日に係る入力情報は西暦表示であり表現方法条件を満たすものであるため、照合部２９は、入力情報の表現方法の変更を行う必要はないと判定する。また、照合部２９は、項目種類「住所変更予備」についての表現方法条件である「画像を記載」と、住所変更予備（変更後の住所）に係る入力情報（画像及び／又は画像のＯＣＲ結果）とを照合する。入力情報として住所変更箇所の画像を取得している場合、表現方法条件を満たすものであるため、照合部２９は、入力情報の表現方法の変更を行う必要はないと判定する。なお、項目種類「住所変更予備」についての表現方法条件が「ＯＣＲ結果を記載」であり、入力情報が住所変更箇所の画像である場合は、照合部２９は、入力情報の表現方法を変更（画像からＯＣＲ情報への変換）する必要があると判定する。なお、項目種類「氏名」についての表現方法条件は「条件なし」であるため、照合部２９は、「氏名」に係る入力情報の表現方法については変更する必要がない（入力情報をそのまま項目データとして配置すればよい）と判定する。なお、上述した項目種類「番号」についての「マイナンバーカードはセキュリティコードを記載」との表現方法条件の場合、照合部２９は、読み取られた身分証明書がマイナンバーカードである場合に、当該表現方法条件と、番号に係る入力情報とを照合する。番号に係る入力情報が、マイナンバーカードとセキュリティコードである場合、照合部２９は、入力情報の表現方法を変更（入力情報の一部データ（マイナンバー）の削除）する必要があると判定する。また、番号に係る入力情報が、マイナンバーのみである場合、照合部２９は、入力情報の表現方法を変更（他のデータ（セキュリティコード）で置換（入れ替える））する必要があると判定する。なお、照合部２９は、「マイナンバーカードはセキュリティコードを記載」との表現方法条件と番号に係る入力情報とを照合することなく、判別された身分証明書の種類と当該条件とを照合することで、判別された身分証明書の種類がマイナンバーカードである場合に、読み取られたセキュリティコードを記載すると判定するようにしてもよい。この場合、帳票生成部３０により、帳票項目「番号」の記載位置に読み取られたセキュリティコードが記載される。
【0075】
帳票生成部３０は、照合部２９により、入力情報の表現方法を変更する必要があると判定された場合、帳票項目に対する入力情報の表現方法を、記載条件を満たすように変更することで項目データを生成し、生成された項目データ（表現方法が変更された入力情報）を帳票項目の記載位置に記載（配置）する。例えば、帳票生成部３０は、住所に係る入力情報に対して都道府県情報を補完し、都道府県情報が補完された入力情報を、帳票項目「住所」の記載位置（図１２の場合、「ｘ２，ｙ２，ｗ２，ｈ２」で示される領域）に記載する（埋め込む）。帳票生成部３０は、表現方法の変更が必要な全ての入力情報について、当該処理を行う。なお、帳票生成部３０は、表現方法の変更が必要ない入力情報については、変更を行うことなく、項目データとして、対応する帳票項目の記載位置に記載（配置）する。上述したケース１の方法は、図１２の場合、フィールド１～フィールド４及びフィールド９の項目に対して適用可能な方法である。
【0076】
（ケース２：記載条件と記録項目の表現方法（媒体定義）との照合）
ケース２では、照合部２９は、帳票項目に係る記載条件（表現方法条件）と、読み取られた身分証明書の種類に対して定義された記録項目の表現方法とを照合する。照合対象の記載条件は、帳票フォームにおいて定義されている表現方法条件である。また、照合対象の表現方法は、判別された身分証明書の種類に対して媒体定義で定義されている、記録項目（帳票項目に対応する記録項目）についての表現方法である。照合部２９は、帳票項目に係る表現方法条件と、当該帳票項目に対応する記録項目についての表現方法とを照合することで、当該帳票項目に対する入力情報（ユーザ情報）の表現方法を表現方法条件に合わせて変更（文字種の変換やデータ補完等）する必要があるか否かを判定する。また、照合部２９は、表現方法条件と表現方法とを照合することで、照合結果に応じて、読取部８１に対して追加の読取指示（例えば、裏面についても読取を行うよう指示）を行うようにしてもよい。以下、図４に示す媒体定義の場合の照合方法について例示する。また、ユーザにより提示された身分証明書の種類が「運転免許証」と判別された場合について例示する。
ケース２では、照合部２９は、帳票項目に係る記載条件（表現方法条件）と、読み取られた身分証明書の種類に対して定義された記録項目の表現方法とを照合する。照合対象の記載条件は、帳票フォームにおいて定義されている表現方法条件である。また、照合対象の表現方法は、判別された身分証明書の種類に対して媒体定義で定義されている、記録項目（帳票項目に対応する記録項目）についての表現方法である。照合部２９は、帳票項目に係る表現方法条件と、当該帳票項目に対応する記録項目についての表現方法とを照合することで、当該帳票項目に対する入力情報（ユーザ情報）の表現方法を表現方法条件に合わせて変更（文字種の変換やデータ補完等）する必要があるか否かを判定する。また、照合部２９は、表現方法条件と表現方法とを照合することで、照合結果に応じて、読取部８１に対して追加の読取指示（例えば、裏面についても読取を行うよう指示）を行うようにしてもよい。以下、図４に示す媒体定義の場合の照合方法について例示する。また、ユーザにより提示された身分証明書の種類が「運転免許証」と判別された場合について例示する。
【0077】
例えば、項目種類「住所」についての表現方法条件である「都道府県を補完」と、記録項目「住所」についての表現方法「都道府県を省略する場合あり」とを照合する。この場合、住所に関する入力情報が都道府県を含まない場合があるため、照合部２９は、表現方法条件を満たさない場合があると判定する。この場合、照合部２９は、入力情報「ＣＣＣＣＣＣＣ」が都道府県情報を省略した住所表記であるか否かを判定し、都道府県情報を省略した表記である場合、入力情報の表現方法を変更（都道府県情報を補完）する必要があると判定する。判別された身分証明書の種類が「パスポート」の場合は、媒体定義において「都道府県のみ」と表現方法が定義されており、都道府県情報は省略して記録されないため、入力情報の表現方法を変更（都道府県を補完）する必要がないと判定する。なお、この場合、都道府県のみが帳票に記載されることになる（市町村については空白となる）が、市町村や番地情報等については、帳票生成時にユーザが手入力で追加するようにしてもよい。
【0078】
また、例えば、照合部２９は、項目種類「生年月日」についての表現方法条件である「西暦」と、記録項目「生年月日」についての表現方法「和暦」とを照合する。この場合、記録項目「生年月日」についての表現方法は、表現方法条件を満たすものではないため、照合部２９は、入力情報の表現方法の変更（西暦への変換（表現形式の変換））を行う必要があると判定する。
【0079】
また、項目種類「住所変更予備」についての表現方法条件である「画像を記載」と、記録項目「住所変更予備」についての表現方法「裏面（手書き）」とを照合する。この場合、照合部２９は、照合の結果、帳票に、住所変更予備に関する画像を記載する必要があるため、提示された身分証明書（運転免許証）の裏面についての追加の読取が必要であると判定する。そして、照合部２９は、読取部８１に対して、身分証明書についての追加の読取指示（裏面の読取指示（画像取得指示））を行う。なお、項目種類「氏名」についての表現方法条件は「条件なし」であるため、照合部２９は、「氏名」に係る入力情報の表現方法については変更する必要がない（入力情報を項目データとしてそのまま配置すればよい）と判定する。なお、判別された身分証明書の種類が「マイナンバーカード」である場合は、媒体定義において「表面（手書き）」と表現方法が定義されている。この場合、照合部２９は、表面については既に読取処理が行われているため、追加の読取指示を行わず、読み取られた画像（住所変更予備欄についての画像）が記載されることとなる。このように、身分証明書の種類に応じて、裏面読取指示を行うことが可能である。
【0080】
帳票生成部３０は、照合部２９により、入力情報の表現方法を変更する必要があると判定された場合、帳票項目に対する入力情報の表現方法を、記載条件を満たすように変更することで項目データを生成し、生成された項目データ（表現方法が変更された入力情報）を帳票項目の記載位置に記載（配置）する。なお、帳票生成部３０は、表現方法の変更が必要ない入力情報（追加読取指示により得られた情報も含む）については、変更を行うことなく、項目データとして、対応する帳票項目の記載位置に記載（配置）する。上述したケース２の方法は、図１２の場合、フィールド１～フィールド４及びフィールド９の項目に対して適用可能な方法である。
【0081】
上述の通り、ケース１及びケース２では、表現方法条件と媒体情報とを照合することで、入力情報の表現方法を表現方法条件に合わせて変更する必要があるか否かを判定し、変更の必要があると判定された場合は、入力情報の表現方法を、表現方法条件を満たすように変更することで項目データが生成され、生成された項目データ（表現方法が変更された入力情報）が記載された帳票データが生成される。
【0082】
（ケース３：記載条件と身分証明書の種類との照合）
ケース３では、照合部２９は、帳票項目に係る記載条件（記載するための条件）と、身分証明書から読み取られた当該身分証明書の種類とを照合する。照合対象の記載条件は、帳票フォームにおいて定義されている、記載するための条件（身分証明書の種類に関する条件（媒体種類条件））である。また、照合対象の身分証明書の種類（情報）は、データ取得部２８により取得された情報である。照合部２９は、記載するための条件と身分証明書の種類とを照合することで、取得された身分証明書の種類が、記載するための条件に該当するか否かを判定する。
ケース３では、照合部２９は、帳票項目に係る記載条件（記載するための条件）と、身分証明書から読み取られた当該身分証明書の種類とを照合する。照合対象の記載条件は、帳票フォームにおいて定義されている、記載するための条件（身分証明書の種類に関する条件（媒体種類条件））である。また、照合対象の身分証明書の種類（情報）は、データ取得部２８により取得された情報である。照合部２９は、記載するための条件と身分証明書の種類とを照合することで、取得された身分証明書の種類が、記載するための条件に該当するか否かを判定する。
【0083】
例えば、図１２におけるフィールド７についての項目種類「固定文字」についての記載するための条件である「マイナンバーカード」と、データ取得部２８により取得された、身分証明書の種類情報とを照合する。身分証明書の種類情報がマイナンバーカードを示す場合、照合部２９は、取得された身分証明書の種類が、記載するための条件に該当すると判定する。一方、身分証明書の種類情報がマイナンバーカード以外を示す場合、照合部２９は、取得された身分証明書の種類が、記載するための条件に該当しないと判定する。
【0084】
また、例えば、図１２におけるフィールド９についての項目種類「番号」についての記載するための条件である「運転免許証、在留カード」と、データ取得部２８により取得された、身分証明書の種類情報とを照合する。身分証明書の種類情報が運転免許証又は在留カードを示す場合、照合部２９は、取得された身分証明書の種類が、記載するための条件に該当すると判定する。一方、身分証明書の種類情報が運転免許証及び在留カード以外を示す場合、照合部２９は、取得された身分証明書の種類が、記載するための条件に該当しないと判定する。
【0085】
照合部２９により、取得された身分証明書の種類が記載するための条件に該当すると判定された場合にのみ、帳票生成部３０は、帳票項目の記載位置に項目データを記載（配置）する。図１２におけるフィールド７の場合、表現方法条件として「固定文字：〇」が定義されているため、判別された身分証明書の種類がマイナンバーカードである場合、記載位置（ｘ７，ｙ７，ｗ７，ｈ７）に、表現方法条件で定められたデータである「〇」が記載（配置）される。このように、読み取られた身分証明書に対応する記載を行うことが可能である。なお、固定文字として「〇」を例示したが、固定文字（固定文字列）は、「〇」以外のマークや、文字、記号、それらの組合せ等であってよく、また、媒体定義で定義されている、記録されている情報の種類（例えば、番号の種類（例えば、「在留番号」の文字）や有効期限の種類等）であってもよい。また、図１２におけるフィールド９の場合、表現方法条件として「条件なし」が定義されているため、判別された身分証明書の種類が運転免許証又は在留カードである場合、記載位置（ｘ９，ｙ９，ｗ９，ｈ９）に、番号に係る入力情報が記載（配置）される。上述したケース３の方法は、図１２の場合、フィールド７及びフィールド９の項目に対して適用可能な方法である。
【0086】
（ケース４：記載条件と本人確認結果との照合）
ケース４では、照合部２９は、帳票項目に係る記載条件（記載するための条件）と、身分証明書に基づき得られる本人確認の結果とを照合する。照合対象の記載条件は、帳票フォームにおいて定義されている、記載するための条件（本人確認の結果に関する条件（本人確認条件））である。また、照合対象の本人確認の結果（本人確認の結果を示す情報）は、データ取得部２８により取得された情報である。照合部２９は、記載するための条件と本人確認の結果とを照合することで、本人確認の結果が、記載するための条件に該当するか否かを判定する。
ケース４では、照合部２９は、帳票項目に係る記載条件（記載するための条件）と、身分証明書に基づき得られる本人確認の結果とを照合する。照合対象の記載条件は、帳票フォームにおいて定義されている、記載するための条件（本人確認の結果に関する条件（本人確認条件））である。また、照合対象の本人確認の結果（本人確認の結果を示す情報）は、データ取得部２８により取得された情報である。照合部２９は、記載するための条件と本人確認の結果とを照合することで、本人確認の結果が、記載するための条件に該当するか否かを判定する。
【0087】
例えば、図１２におけるフィールド８についての項目種類「固定文字」についての記載するための条件である「本人確認がＮＧであること」と、データ取得部２８により取得された、本人確認の結果とを照合する。本人確認の結果がＮＧであった場合、照合部２９は、本人確認の結果が、記載するための条件に該当すると判定する。一方、本人確認の結果がＯＫ（適切）であった場合、照合部２９は、本人確認の結果が、記載するための条件に該当しないと判定する。
【0088】
照合部２９により、本人確認の結果が、記載するための条件に該当すると判定された場合、帳票生成部３０は、帳票項目の記載位置に、項目データ（表現方法条件で定められたデータ）を記載（配置）する。図１２におけるフィールド８の場合、表現方法条件として「固定文字：※」が定義されているため、本人確認の結果がＮＧである場合、記載位置（ｘ８，ｙ８，ｗ８，ｈ８）に、表現方法条件で定められたデータである「※」が記載（配置）される。なお、固定文字として「※」を例示したが、固定文字（固定文字列）は、「※」以外のマークや、文字、記号、それらの組合せ等であってよい。上述したケース４の方法は、図１２の場合、フィールド８の項目に対して適用可能な方法である。
【0089】
上述の通り、ケース３及びケース４では、記載するための条件と媒体情報とを照合することで、媒体情報が、記載するための条件に該当するか否かを判定し、条件に該当すると判定された場合にのみ、対象の帳票項目の記載位置に項目データが記載される。この場合、記載位置に記載される項目データは、帳票フォームにおいて指定された所定の情報（文字列やマーク等）及び取得されたユーザ情報に含まれる対象の帳票項目に対する入力情報のうち少なくとも一方であってよい。以上より、各帳票項目についての項目データが、夫々、例えば、ケース１～ケース４の少なくとも何れかの方法により記載（配置）されると、帳票データが生成される。
【0090】
図２１は、本実施形態に係るデータの記載例（変換例）を示す図である。図２１では、帳票定義（所定の記載条件）に対して、データがどのように帳票に記載されるか（データの記載例）を身分証明書毎に示している。図２１及び上述の通り、帳票定義に記載条件を定義しておくことにより、どのような種類の身分証明書がユーザにより提示された場合であっても、記載条件を満たしたデータが自動的に記載（配置）された帳票データが生成されるため、帳票を容易に作成することが可能となる。つまり、表現方法条件に定義された表現方法（書式等）に合わせて、各身分証明書から読み取られた情報の表現方法等を自動で揃える（変換する）ことが可能となる。
【0091】
出力部３１は、帳票生成部３０により生成された帳票データ（データ変換された帳票データを含む）の出力、及び／又は、帳票データに基づく帳票の出力（又は出力指示）を行う。帳票データ又は帳票データに基づく帳票の出力方法及び出力指示方法には、種々の方法が用いられてよい。例えば、出力部３１は、情報処理装置１とネットワーク又はその他の通信手段を介して通信可能に接続された外部装置や外部システムに対して、帳票データ（イメージデータ、ＰＤＦデータ等）又はデータ変換した帳票データを出力（送信する）。なお、データ変換した帳票データとは、例えば、ＣＳＶ変換やＴｅｘｔ変換等が行われた帳票データ（ＣＳＶ情報やＴｅｘｔ情報等）である。なお、ＣＳＶ情報等のデータを取得した外部装置（例えば、データベース入力システム等）では、取得したデータについてのユーザによる目視確認等が行われた後、当該データに基づくデータベースの更新が行われてもよい。例えば、ＣＳＶ情報に住所変更に係る情報が含まれている場合、自治体側のデータベースに記憶された情報を、変更後の住所の情報に基づき更新するようにしてもよい。
【0092】
また、他の出力方法として、例えば、情報処理装置１が印刷機能として出力部３１を備える場合は、出力部３１は、帳票生成部３０により生成された帳票データに基づく紙媒体の帳票を印刷（出力）する。また、例えば、情報処理装置１が、ネットワーク又はその他の通信手段を介して印刷装置（プリンタ）と互いに通信可能に接続されている場合は、出力部３１は、印刷装置に対して帳票データを送信した上で、当該帳票データに基づく紙媒体の帳票を印刷するよう指示を行う。
【0093】
図２２は、本実施形態に係る出力イメージ確認画面の一例を示す図である。図２２に示すように、入力データ（入力情報）が帳票フォームに埋め込まれた（配置された）状態で、出力イメージ確認画面に表示されることより、ユーザは帳票の出力イメージ（記載内容）を確認することが可能である。なお、複数の帳票データが生成された場合、出力イメージ確認画面において、これら複数の帳票データを確認することが可能である。この画面上で「印刷する」ボタンが押下されることで、表示された出力イメージで、帳票が出力（印刷等）される。
【0094】
図２３は、本実施形態に係るＣＳＶ情報の一例を示す図である。図２３には、帳票生成部３０により生成された帳票データ（図２２に示された帳票データ）をＣＳＶ変換することで得られるＣＳＶ情報の例を示す。出力部３１は、図２３に示すようなＣＳＶ情報を他の装置やシステム等に出力（送信）するようにしてよい。
【0095】
次に、読取装置９の機能構成について説明する。読取装置９は、記憶装置９６に記録されているプログラムが、ＲＡＭ９５に読み出され、ＣＰＵ９３によって実行されて、読取装置９に備えられた各ハードウェアが制御されることで、読取部８１、本人確認部８２及びデータ送信部８３を備える。なお、本実施形態及び後述する他の実施形態では、読取装置９の備える各機能は、汎用プロセッサであるＣＰＵ９３によって実行されるが、これらの機能の一部又は全部は、１又は複数の専用プロセッサによって実行されてもよい。
【0096】
読取部８１は、ユーザ情報が記録された媒体の種類（種別）を判別する。本実施形態では、ユーザ情報が記録された媒体として、身分証明書（本人確認書類）を例示するため、読取部８１は、ユーザ情報が記録された媒体が、マイナンバーカードや、運転免許書、在留カード、パスポート等の各種身分証明書のうち何れの身分証明書であるか（身分証明書の種類）を、当該媒体から判別（取得）する。身分証明書の種類を判別する方法には種々の方法が用いられてよい。例えば、身分証明書（媒体）を読み取ることで、身分証明書に記載された文字や写真等の配置を解析することにより、身分証明書の種類を判別する方法が用いられてよい。また、その他の方法として、身分証明書に搭載されたＩＣチップを読み取ることで、ＩＣチップに記録された、身分証明書の種類を示す情報を取得する方法（ＩＣリーダーを用いる方法）が用いられてよい。また、他の方法として、身分証明書の画像を読み取り、当該画像に対してＯＣＲ処理を施すことにより、身分証明書に記載された身分証明書を示す文字（例えば、「運転免許証」等の文字）を取得する方法等が用いられてよい。なお、本実施形態では、読取部８１は、身分証明書を用いて当該身分証明書の種類を判別（取得）するが、ユーザから読取対象の媒体の種類の入力を受け付けることで、読取対象の媒体の種類を取得するようにしてもよい。
【0097】
また、読取部８１は、媒体（身分証明書等）を読み取ることで、当該媒体に記録されたユーザ情報を取得する。身分証明書（媒体）に記録された情報を取得する方法には種々の方法が用いられてよい。例えば、身分証明書（身分証明書の画像）に対してＯＣＲ処理を施すことで、身分証明書の表面に記載（記録）された情報を取得する方法が用いられてよい。この場合、判別された身分証明書の種類の様式に応じた情報（項目）についての読取処理が行われてよい。また、その他の方法として、身分証明書に搭載されたＩＣチップを読み取ることで、ＩＣチップに記録されたユーザ情報を取得する方法が用いられてよい。
【0098】
本人確認部８２は、媒体に記録されたユーザ情報を用いて本人確認を行う。本人確認の方法には、種々の方法が用いられてよい。例えば、本人確認部８２は、身分証明書（ＩＣチップ）に記録された顔写真データと、読取装置９のカメラ９２により撮影されたユーザの顔写真とを照合し、例えば、これらの顔写真のそれぞれから得られる顔特徴が異なる場合に、「本人確認が出来なかった（本人確認がＮＧ）」と判定する。また、例えば、ＩＣチップと表面の情報とを照合した結果、両者の整合が取れなかった場合（身分証明書のＩＣチップに記録された情報（氏名や住所）と身分証明書表面の情報（氏名や住所）とが異なる場合、身分証明書の表面のレイアウトは運転免許証のレイアウトであるが身分証明書にＩＣチップが搭載されていない（通常運転免許証にはＩＣチップあり）場合、ＩＣチップの内容はマイナンバーカードであるが身分証明書の表面のレイアウトは運転免許証である場合等）に、本人確認がＮＧと判定してもよい。また、得られたユーザの年齢が指定年齢未満である場合に、本人確認がＮＧと判定してもよい。なお、本実施形態では、読取装置９が本人確認部８２を備えることで、読取装置９において本人確認処理が行われるが、情報処理装置１が本人確認部８２を備えることで、情報処理装置１において本人確認処理が行われるようにしてもよい。
【0099】
データ送信部８３は、各種データ（情報）を情報処理装置１に対して送信する。具体的には、データ送信部８３は、読取部８１により取得（判別）された媒体の種類（媒体種類に係る情報）と、読取部８１により読み取られたユーザ情報と、本人確認部８２による本人確認の結果を示す情報を、情報処理装置１へ送信する。
【0100】
図２４は、本実施形態に係る帳票フォーム生成処理の流れの概要を示すフローチャートである。本フローチャートに示された処理は、情報処理装置１においてユーザ（帳票生成システムの設置者（運用者）等）から帳票フォームの作成指示を受け付けたこと等を契機として開始される。なお、本フローチャートに示された処理は、ユーザが作成したい帳票フォーム毎に実行される。また、本フローチャートに示された処理は、表示制御部２３により表示された帳票フォーム生成画面（図１１を参照）上でユーザが各種操作を行うことにより実行されてよい。
【0101】
ステップＳ１０１では、下敷きデータが取得される。下敷きデータ取得部２４１は、帳票のベースとなる下敷きデータを取得する。下敷きデータ取得部２４１は、ユーザから下敷きデータ（例えば、紙媒体の帳票のスキャン画像）が入力されると、入力された下敷きデータを取得する（図５を参照）。その後、ステップＳ１０２へ進む。
【0102】
ステップＳ１０２～ステップＳ１０４では、ユーザから、１つの帳票項目について入力（指定）された、項目データの記載領域、項目種類及び記載条件が取得される。ステップＳ１０２において、入力受付部２４２は、ユーザにより入力（指定）された、項目データの記載領域を取得する（図７を参照）。その後、処理はステップＳ１０３へ進む。
【0103】
ステップＳ１０３において、入力受付部２４２は、ユーザにより入力（選択）された項目種類を取得する。項目種類（氏名、住所、生年月日、性別等）を含むリストが帳票フォーム生成画面上に表示されることで、ユーザは、当該リストから所望の項目種類（例えば、「氏名」や「固定文字」）を選択する。例えば、ユーザは、ステップＳ１０２において図７における氏名の右側領域を選択した場合、項目種類として「氏名」を選択する。また、例えば、ユーザは、ステップＳ１０２において図７における本人確認欄の「個人番号カード」の文字列の先頭領域を選択した場合、項目種類として「固定文字」を選択する。その後、処理はステップＳ１０４へ進む。
【0104】
ステップＳ１０４において、入力受付部２４２は、ユーザにより入力（選択）された、１又は複数の記載条件を取得する。例えば、条件記憶部２１に記憶された記載条件（図３を参照）のうち、ステップＳ１０３で取得された項目種類に対して定義可能な記載条件を含むリストが、帳票フォーム画面上に表示されるようにしてもよい。これより、ユーザは、当該リストから所望の記載条件を選択することが可能である。例えば、ステップＳ１０３において項目種類「氏名」が選択された場合、ステップＳ１０４では、「空白除去」や「条件なし」等の記載条件を含むリストが表示され、ユーザにより例えば「空白除去」が選択される。また、例えば、ステップＳ１０３において項目種類「固定文字」が選択された場合、ステップＳ１０４では、「マイナンバーカード（のみ）」や「運転免許証のみ」等の記載条件を含むリストが表示され、ユーザにより例えば「マイナンバーカード」や「〇（固定文字）」が選択される。その後、処理はステップＳ１０５へ進む。
【0105】
ステップＳ１０５では、全帳票項目（全フィールド）の定義が完了したか判定される。帳票フォーム生成部２４は、ユーザが必要とする全ての項目についての項目定義（ステップＳ１０２～Ｓ１０４の処理）が完了したか否かを判定する。例えば、帳票フォーム生成部２４は、ユーザにより、帳票フォーム生成画面上で完了ボタン等が押下されたことにより、全項目の定義が完了したと判定する。全項目の定義が完了していない場合（ステップＳ１０５のＮо）、処理はステップＳ１０２へ戻り、項目定義が完了していない帳票項目についての定義（ステップＳ１０２～Ｓ１０４の処理）を行う。一方、全項目の定義が完了した場合（ステップＳ１０５のＹｅｓ）、処理はステップＳ１０６へ進む。
【0106】
ステップＳ１０６では、帳票フォームが生成される。生成部２４３は、ステップＳ１０１で取得された下敷きデータと、ステップＳ１０２～Ｓ１０４で取得されたデータ（項目定義）とを合わせた帳票フォーム（帳票定義データ）を生成する。その後、処理はステップＳ１０７へ進む。
【0107】
ステップＳ１０７では、帳票フォームが保存される。帳票フォーム記憶部２６１は、ステップＳ１０６で生成された帳票フォームを記憶する。その後、本フローチャートに示された処理は終了する。なお、ステップＳ１０４とステップＳ１０５との間で、ユーザによりラベルの入力処理が行われることで、入力受付部２４２は、ラベル入力を受け付けるようにしてもよい。ラベルは、項目種類（帳票項目名）である「氏名」や「住所」等の上位（上位概念）の情報（例えば、「本人申請」や「代理人申請」等）である。ラベル入力処理が行われることで、帳票データがＣＳＶ情報に変換された際等に、各帳票項目がどのような情報を示しているかをより詳細に理解することが可能である。例えば、「氏名」や「住所」等が本人のものであるか、それとも、代理人のものであるかの理解を助ける情報となる。なお、ラベルの入力方法には任意の方法が用いられてよく、記載領域の周辺に位置する文字（例えば、図５に示す「本人申請」や「代理人申請」の文字）の位置を指定することで、当該文字の情報をラベルとして取得してもよいし、ユーザがラベルの文字を直接入力するようにしてもよい。
【0108】
図２５は、本実施形態に係る帳票リスト生成・対応付け処理の流れの概要を示すフローチャートである。本フローチャートに示された処理は、情報処理装置１においてユーザ（帳票生成システムの設置者（運用者）等）から帳票リストの作成・対応付け指示を受け付けたこと等を契機として開始される。なお、本フローチャートに示された処理は、帳票フォームが予め生成されていることを前提とする。また、本フローチャートでは、帳票リストが２つの階層で構成される（用途が最大２階層で特定される）場合について例示するが、上述の通り、帳票リストは３階層以上で構成されてもよい。また、本フローチャートに示された処理は、表示制御部２３により表示された帳票リスト生成画面（図１４～図１６を参照）上でユーザが各種操作を行うことにより実行されてよい。
【0109】
ステップＳ２０１では、カテゴリ１の用途要素が生成される。帳票リスト生成部２５は、ユーザによる、カテゴリ１のボタンの生成（選択）及び当該ボタンへの名前の入力（編集入力）を受け付けることで、カテゴリ１の用途要素（例えば、「住民票申請」）を生成する。例えば、図１４に示すように、「住民票申請」や「印鑑証明」、「転入手続き」のボタンが帳票リスト生成画面において生成される。その後、処理はステップＳ２０２へ進む。
【0110】
ステップＳ２０２では、カテゴリ２の用途要素を生成するか否かが判定される。帳票リスト生成部２５は、ステップＳ２０１で生成されたカテゴリ１の用途要素（例えば、「住民票申請」）に紐づくカテゴリ２の用途要素を生成するか（ユーザが生成を所望しているか）否かを判定する。例えば、帳票リスト生成画面において、帳票フォームとの対応付けを行うためのボタン等が押下されると、帳票リスト生成部２５は、カテゴリ２の用途要素を生成しないと判定する。このように、カテゴリ２の用途要素を生成しないと判定された場合（ステップＳ２０２のＮｏ）、処理はステップＳ２０３へ進む。また、例えば、帳票リスト生成画面において、生成されたカテゴリ１の用途要素に対するカテゴリ２の用途要素を生成するためのボタン等が押下されることで、帳票リスト生成部２５は、カテゴリ２の用途要素を生成すると判定する。このように、カテゴリ２の用途要素を生成すると判定された場合（ステップＳ２０２のＹｅｓ）、処理はステップＳ２０４へ進む。
【0111】
ステップＳ２０３では、帳票フォーム（帳票フォーム名）との対応付けが行われる。帳票リスト生成部２５は、ステップＳ２０１で生成されたカテゴリ１の用途要素（カテゴリ１の用途要素で特定される用途）と、当該用途に必要な１以上の帳票（帳票フォーム）との対応付けを行う。例えば、カテゴリ１の用途要素「印鑑証明」のみで特定される用途「印鑑証明」に対して、印鑑証明を行うために必要な１以上の帳票フォームを対応付ける。帳票リスト生成部２５は、例えばユーザが、帳票リスト生成画面において、ステップＳ２０１で生成されたボタン（「印鑑証明」のボタン）を選択した上で、図１６に示すような画面上で、対応付けたい１以上の帳票フォームを選択すると、当該用途（最下層（カテゴリ１）の用途要素）と当該１以上の帳票フォームとの対応付けを行う。その後、処理はステップＳ２０７へ進む。
【0112】
ステップＳ２０４では、カテゴリ２の用途要素が生成される。帳票リスト生成部２５は、ユーザによる、カテゴリ２のボタンの生成（選択）及び当該ボタンへの名前の入力（編集入力）を受け付けることで、カテゴリ２の用途要素（例えば、「申請者本人の申請」）を生成する。その後、処理はステップＳ２０５へ進む。
【0113】
ステップＳ２０５では、帳票フォーム（帳票フォーム名）との対応付けが行われる。帳票リスト生成部２５は、ステップＳ２０４で生成されたカテゴリ２の用途要素（ステップＳ２０１で生成されたカテゴリ１の用途要素とステップＳ２０４で生成されたカテゴリ２の用途要素で特定される用途）と、当該用途に必要な１以上の帳票フォームとの対応付けを行う。例えば、カテゴリ１の用途要素「住民票申請」及びカテゴリ２の用途要素「申請者本人の申請」で特定される用途である住民票申請（本人）に対して、申請者本人が住民票申請を行うために必要な１以上の帳票フォームを対応付ける。帳票リスト生成部２５は、例えばユーザが、帳票リスト生成画面において、ステップＳ２０４で生成されたボタン（「申請者本人の申請」のボタン）を選択した上で、図１６に示すような画面上で、対応付けたい１以上の帳票フォームを選択すると、当該用途（最下層（カテゴリ２）の用途要素）と当該１以上の帳票フォームとの対応付けを行う。その後、処理はステップＳ２０６へ進む。
【0114】
ステップＳ２０６では、カテゴリ２の用途要素の生成が全て完了したか判定される。帳票リスト生成部２５は、ステップＳ２０１で生成されたカテゴリ１の用途要素（例えば、「住民票申請」）に紐づけたいカテゴリ２の用途要素が全て生成されたかを判定する。例えば、帳票リスト生成画面において、ステップＳ２０１で生成されたカテゴリ１の用途要素に対するカテゴリ２の生成を完了するためのボタン等が押下されることで、帳票リスト生成部２５は、カテゴリ２の用途要素の生成が全て完了したと判定する。このように、カテゴリ２の用途要素の生成が全て完了したと判定された場合（ステップＳ２０６のＹｅｓ）、処理はステップＳ２０７へ進む。また、例えば、帳票リスト生成画面において、ステップＳ２０１で生成されたカテゴリ１の用途要素に対するカテゴリ２の用途要素を追加で生成するためのボタン等が押下されることで、帳票リスト生成部２５は、カテゴリ２の用途要素の生成が全て完了していないと判定する。このように、カテゴリ２の用途要素の生成が全て完了していないと判定された場合（ステップＳ２０６のＮｏ）、処理はステップＳ２０４へ戻り、まだ生成されていないカテゴリ２の用途要素（例えば、「代理人の方による申請」）が生成される。
【0115】
ステップＳ２０７では、カテゴリ１の用途要素の作成が完了したかが判定される。帳票リスト生成部２５は、ユーザの所望するカテゴリ１の用途要素の作成が全て完了したかを判定する。例えば、帳票リスト生成画面において帳票リストの作成を完了するためのボタンが押下されると、帳票リスト生成部２５は、カテゴリ１の全ての用途要素の作成が完了したと判定する。このように、カテゴリ１の全ての用途要素の生成が完了した場合（ステップＳ２０７のＹｅｓ）、帳票リストが生成され、本フローチャートに示された処理は終了する。また、例えば、帳票リスト生成画面においてカテゴリ１の用途要素を追加で生成するためのボタン等が押下されることで、帳票リスト生成部２５は、カテゴリ１の全ての用途要素の生成が完了していないと判定する。このように、カテゴリ１の全ての用途要素の生成が完了していない場合（ステップＳ２０７のＮｏ）、処理はステップＳ２０１へ戻り、まだ生成されていないカテゴリ１の用途要素（例えば、「転入手続き」）が生成される。
【0116】
なお、本フローチャートでは、最上層の用途要素を作成する毎に、当該用途要素に紐づく下層の用途要素を生成することで、帳票リストを生成する方法を例示した。但し、帳票リストの生成方法はこの例に限定されず、最上層から順に、その層の全ての用途要素を生成していくことで、帳票リストを生成してもよい。
【0117】
図２６は、本実施形態に係る帳票生成・出力処理の流れの概要を示すフローチャートである。本フローチャートに示された処理は、情報処理装置１においてユーザ（帳票生成システムの利用者等）から帳票の作成・出力指示を受け付けたこと等を契機として開始される。
【0118】
ステップＳ３０１では、帳票フォームが選択される。帳票フォーム選択部２７は、帳票の生成に使用される帳票フォームを選択する。帳票フォームの選択処理の詳細は、図２８を参照して後述する。その後、処理はステップＳ３０２へ進む。
【0119】
ステップＳ３０２では、身分証明書のセット指示を行う。表示制御部２３は、ユーザに対して、身分証明書を読取装置９にセット（提示）するよう指示するメッセージを画面に表示させる。なお、表示制御部２３ではなく、情報処理装置１の他の機能部や読取装置９が、身分証明書をセット（提示）するようユーザに指示するようにしてもよい。なお、指示する方法は、音やメッセージの送信等の、画面表示以外の方法であってもよい。当該指示を行うことにより、ユーザによって、読取装置９に身分証明書がセットされる。また、読取装置９に身分証明書がセットされると、本人確認部８２による本人確認が行われる。これより、データ取得部２８は、本人確認の結果を示す情報を、データ送信部８３から取得する。その後、処理はステップＳ３０３へ進む。
【0120】
ステップＳ３０３では、身分証明書の種類が取得される。読取部８１がステップＳ３０２でセットされた身分証明書を読み取ることで当該身分証明書の種類を判定（判別）すると、データ取得部２８は、この判定された身分証明書の種類（種類情報）を、データ送信部８３から取得する。例えば、データ取得部２８は、ステップＳ３０２でセットされた身分証明書の種類がマイナンバーカードであることを示す情報を取得する。その後、処理はステップＳ３０４へ進む。
【0121】
ステップＳ３０４では、身分証明書からユーザ情報（入力情報）が取得される。読取部８１が、ステップＳ３０２でセットされた身分証明書を読み取ることで当該身分証明書に記録されたユーザ情報を取得すると、データ取得部２８は、この取得された情報を、データ送信部８３から取得する。例えば、データ取得部２８は、図２０に示すユーザ情報を取得する。なお、データ取得部２８は、セットされた身分証明書の種類情報と当該身分証明書に記録されたユーザ情報を纏めてデータ送信部８３から取得するようにしてもよい。その後、処理はステップＳ３０５へ進む。
【0122】
ステップＳ３０５では、帳票（帳票データ）が生成される。帳票生成部３０は、ステップＳ３０１で選択された１以上の帳票フォームと、ステップＳ３０４で取得されたユーザ情報（入力情報）とを合わせることで、帳票（帳票データ）を生成する。帳票の生成処理の詳細は、図２９を参照して後述する。また、ステップＳ３０５では、生成された帳票データが記憶されてよい。その後、処理はステップＳ３０６へ進む。
【0123】
ステップＳ３０６では、帳票が出力される。出力部３１は、ステップＳ３０５で生成された帳票データ又は当該帳票データに基づく紙媒体の帳票を出力する。その後、本フローチャートに示された処理は終了する。なお、ステップＳ３０６の処理を実行する前に、ステップＳ３０５で生成された帳票データをユーザに対して提示（表示）するようしてもよい。また、表示制御部２３が、出力イメージ確認画面に帳票データを表示することで、当該帳票データを確認したユーザが当該帳票データを修正又は追記可能とするようにしてもよい。
【0124】
図２７は、本実施形態に係る帳票生成・出力処理（裏面読取指示あり）の流れの概要を示すフローチャートである。図２７に示すフローチャートは、図２６に示すフローチャートにおいて、裏面読取指示を行う処理を追加したフローチャートである。つまり、片面（表面）の読取設定により表面についての読取処理が行われた後に、裏面読取指示を行うための処理を含むフローチャートである。図２７に示された処理のうち、図２６と同一の番号が付与された処理については、上述した説明と同様であるため、説明を省略する。
【0125】
ステップＳ１では、身分証明書の裏面の読取が必要であるか否かが判定される。照合部２９は、ステップＳ３０１で選択された帳票フォームにおいて定義された各帳票項目について、帳票項目に係る表現方法条件と、ステップＳ３０３で取得された身分証明書の種類に対して定義された、当該帳票項目と対応する記録項目についての表現方法とを照合する。例えば、照合部２９は、「住所変更予備」に係る表現方法条件「画像を記載」と、ステップＳ３０３で取得された身分証明書の種類（例えば、運転免許証）に対して定義された、「住所変更予備」についての表現方法「裏面（手書き）」とを照合する。この場合、照合部２９は、帳票に、住所変更予備に関する画像を記載する必要があるため、提示された身分証明書の裏面についての追加の読取（裏面の読取）が必要であると判定する。このように、裏面の読取が必要と判定された場合（ステップＳ１のＹｅｓ）、処理はステップＳ２へ進む。一方、裏面の読取が必要ないと判定された場合（ステップＳ１のＮｏ）、処理はステップＳ３０５へ進む。
【0126】
ステップＳ２では、身分証明書の裏面の読取指示が行われる。照合部２９は、読取部８１に対して、身分証明書についての追加の読取指示（裏面の読取指示（画像取得指示））を行う。その後、処理はステップＳ３０２へ戻る。
【0127】
なお、ステップＳ１は、ステップＳ３０３とステップＳ３０４の間で行われてもよい。また、ステップＳ２の後にステップＳ３０２の処理が実行された後は、ステップＳ３０３を省略してステップＳ３０４の処理が実行されてよい。以上の通り、媒体定義と記載条件とを照合することにより、必要な情報が裏面に記載されている場合の追加の読取指示が可能となる。
【0128】
図２８は、本実施形態に係る帳票フォーム選択処理の流れの概要を示すフローチャートである。本フローチャートは、図２６に示されたステップＳ３０１の処理の詳細を示すフローチャートである。本フローチャートに示された処理は、情報処理装置１においてユーザ（帳票生成システムの利用者等）から帳票の作成・出力指示を受け付けたこと等を契機として開始される。また、本フローチャートに示された処理は、表示制御部２３により表示された帳票フォーム選択画面（図１８及び図１９を参照）上でユーザが各種操作を行うことにより実行されてよい。
【0129】
ステップＳ４０１では、帳票リストのカテゴリ１の用途要素が取得される。表示制御部２３は、帳票リスト記憶部２６２から、カテゴリ１について記憶されている全ての用途要素を取得する。その後、処理はステップＳ４０２へ進む。
【0130】
ステップＳ４０２では、カテゴリ１の用途要素が表示される。表示制御部２３は、ステップＳ４０１で取得された、カテゴリ１の全ての用途要素を帳票フォーム選択画面（図１８を参照）に表示させる。その後、処理はステップＳ４０３へ進む。
【0131】
ステップＳ４０３では、カテゴリ１の用途要素の選択が受け付けられる。用途選択受付部２７１は、ステップＳ４０２で表示されたカテゴリ１の用途要素からユーザが１つの用途要素を選択することで、カテゴリ１の用途要素の選択を受け付ける。その後、処理はステップＳ４０４へ進む。
【0132】
ステップＳ４０４では、ステップＳ４０３で選択されたカテゴリ１の用途要素に紐づくカテゴリ２の用途要素が存在するか判定する。表示制御部２３は、ステップＳ４０３で選択されたカテゴリ１の用途要素に基づき帳票リスト記憶部２６２に記憶された帳票リストを参照することで、当該用途要素に対応するカテゴリ２の用途要素が存在するか否かを判定する。対応するカテゴリ２の用途要素が存在しない場合（ステップＳ４０４のＮｏ）、処理はステップＳ４０５へ進む。一方、対応するカテゴリ２の用途要素が存在する場合（ステップＳ４０４のＹｅｓ）、処理はステップＳ４０６へ進む。
【0133】
ステップＳ４０５では、帳票フォームが取得（選択）される。選択部２７２は、ステップＳ４０３で選択されたカテゴリ１の用途要素に対応付けられた１以上の帳票フォームを取得（選択）する。例えば、図１３に示すデータ（帳票リスト記憶部２６２が保持するデータ）において、カテゴリ１の用途要素に対応付けられた帳票フォーム名に該当する帳票フォームを帳票フォーム記憶部２６１から取得する。例えば、選択部２７２は、ステップＳ４０３でカテゴリ１の用途要素「印鑑証明」が選択された場合、当該用途要素に対応付けられた帳票フォーム「印鑑証明書」を取得する（図１３を参照）。なお、ステップＳ４０５では、カテゴリ２を選択する画面を表示させないが、上述したように、ユーザに対して確認を促す画面（メッセージ）を表示するようにしてもよい。その後、処理はステップＳ４１０へ進む。
【0134】
ステップＳ４０６では、帳票リストのカテゴリ２の用途要素が取得される。表示制御部２３は、帳票リスト記憶部２６２から、ステップＳ４０３で選択されたカテゴリ１の用途要素に紐づくカテゴリ２の全ての用途要素を取得する。その後、処理はステップＳ４０７へ進む。
【0135】
ステップＳ４０７では、カテゴリ２の用途要素が表示される。表示制御部２３は、ステップＳ４０６で取得された、カテゴリ２の用途要素を帳票フォーム選択画面（図１９を参照）に表示させる。その後、処理はステップＳ４０８へ進む。
【0136】
ステップＳ４０８では、カテゴリ２の用途要素の選択が受け付けられる。用途選択受付部２７１は、ステップＳ４０７で表示されたカテゴリ２の用途要素からユーザが１又は複数の用途要素を選択することで、カテゴリ２の用途要素の選択を受け付ける。その後、処理はステップＳ４０９へ進む。
【0137】
ステップＳ４０９では、帳票フォームが取得（選択）される。選択部２７２は、ステップＳ４０８で選択されたカテゴリ２（最下層）の用途要素に対応付けられた１以上の帳票フォームを取得（選択）する。例えば、図１３に示すデータにおいて、カテゴリ２の用途要素に対応付けられた帳票フォーム名に該当する帳票フォームを帳票フォーム記憶部２６１から取得する。例えば、選択部２７２は、ステップＳ４０３でカテゴリ１の用途要素「住民票申請」が選択され、ステップＳ４０８でカテゴリ２の用途要素「本人用」が選択された場合、当該用途要素に対応付けられた帳票フォームである「住民票申請（本人）」と「住民票申請（共通裏面）」を取得する（図１３を参照）。なお、最下層であるカテゴリ２の用途要素が選択されると、画面が、図１９に示す画面から図１８に示す画面に遷移する。その後、処理はステップＳ４１０へ進む。
【0138】
ステップＳ４１０では、用途の選択が完了したかが判定される。帳票フォーム選択部２７は、ユーザが所望する用途（やりたい用途）が全て選択されたか否かを判定する。例えば、図１８に示す帳票フォーム選択画面において、「次に進む」ボタンがユーザにより押下されると、帳票フォーム選択部２７は、用途の選択が完了したと判定する。このように、用途の選択が完了したと判定された場合（ステップＳ４１０のＹＥＳ）、本フローチャートに示された処理は終了する。一方、用途の選択が完了していないと判定された場合（ステップＳ４１０のＮｏ）、処理はステップＳ４０３へ戻り、選択が完了していない用途の選択が行われる。なお、用途が全て選択された後に、帳票フォームが選択されるようにしてもよい。
【0139】
図２９は、本実施形態に係る帳票生成処理の流れの概要を示すフローチャートである。本フローチャートは、図２６に示されたステップＳ３０５の処理の詳細を示すフローチャートである。本フローチャートに示された処理は、図２６に示されたステップＳ３０４の処理が終了したことを契機として開始される。なお、ステップＳ３０１において複数の帳票フォームが選択された場合、選択された帳票フォーム毎に、本フローチャートに示された処理が行われることとする。以下の説明では、ステップＳ３０１において選択された帳票フォームの１つを帳票フォームＡとして説明する。なお、帳票フォームＡは、図１２に示す項目定義を有することとする。
【0140】
ステップＳ５０１及びステップＳ５０２では、帳票フォームＡにおいて定義されている帳票項目についての領域情報及び条件情報が取得される。照合部２９は、帳票フォームＡにおいて定義されている帳票項目のうち、１つの帳票項目についての領域情報の取得（ステップＳ５０１）、及び、当該帳票項目の条件情報の取得（ステップＳ５０２）を行う。ここでは、フィールド２（項目種類「住所」）について、領域情報「ｘ２，ｙ２，ｗ２，ｈ２」と、条件情報として、記載するための条件「すべて」、表現方法条件「都道府県を補完」及び領域に関する条件「なし」を取得した場合について例示する。その後、処理はステップＳ５０３へ進む。
【0141】
ステップＳ５０３では、帳票項目に関連する情報（媒体情報）が取得される。照合部２９は、ステップＳ５０１及びステップＳ５０２で取得された領域情報及び条件情報に係る帳票項目に関連する媒体情報を取得する。例えば、項目種類「氏名」、「住所」、「住所変更予備」及び「生年月日」（フィールド１～４）については、夫々、媒体情報として、項目種類に対応する記録項目について読み取られたユーザ情報（ケース１の場合）又は読み取られた身分証明書の種類に対して定義された、帳票項目に対応する記録項目の表現方法（ケース２の場合）が取得される。例えば、ケース１の方法を用いる場合、照合部２９は、図１２に示すフィールド２（項目種類「住所」）に関連（対応）する媒体情報として、図２６のステップＳ３０４で取得された、記録項目「住所」についてのユーザ情報（入力情報）である「ＣＣＣＣＣＣＣ」を取得する。また、例えば、ケース２の方法を用いる場合、媒体情報として、読み取られた身分証明書の種類（例えば「パスポート」）に対して定義された「住所」についての表現方法「都道府県のみ」を取得する。
【0142】
また、項目種類「固定文字」（フィールド７）については、媒体情報として、図２６のステップＳ３０３で取得された身分証明書の種類が取得される。また、項目種類「固定文字」（フィールド８）については、媒体情報として、図２６のステップＳ３０２で行われた本人確認の結果が取得される。また、項目種類「番号」（フィールド９）については、媒体情報として、番号に係る入力情報と、図２６のステップＳ３０３で取得された身分証明書の種類が取得される。なお、項目種類「固定文字」（フィールド６）については、記載するための条件が条件なしであり、かつ固定された文字が入力される項目種類であるため、ステップＳ５０３で取得される情報はない。また、項目種類「作成日時」については、媒体情報ではなく、帳票作成時の日時情報が取得される。その後、処理はステップＳ５０４へ進む。
【0143】
ステップＳ５０４では、条件が指定されているか否かが判定される。照合部２９は、ステップＳ５０２で取得された条件情報を参照することで、条件が指定されているか否かを判定する。本実施形態では、表現方法条件及び記載するための条件の何れにも条件が指定されていない場合に、条件が指定されていないと判定する。例えば、条件情報（記載条件）において、記載するための条件が「すべて（全ての身分証明書）」であり、且つ、表現方法条件が「条件なし」である場合に、条件が指定されていないと判定される。図１２の例では、項目種類「氏名」について、条件が指定されていないと判定される。条件が指定されていないと判定された場合（ステップＳ５０４のＮｏ）、処理はステップＳ５０５へ進む。一方、条件が指定されていると判定された場合（ステップＳ５０４のＹｅｓ）、処理はステップＳ５０６へ進む。
【0144】
ステップＳ５０５では、情報が指定領域に記載される。帳票生成部３０は、ステップＳ３０４で取得された帳票項目に対する入力情報（ユーザ情報等）をそのまま、項目データとして、下敷きデータ（複製された下敷きデータ）の指定領域（ステップＳ５０１で取得された領域情報が示す領域）に記載（配置）する。上述の例では、項目種類「氏名」の場合、項目種類「氏名」についての入力情報「ＡＡ ＢＢ」が、「ｘ１，ｙ１、ｗ１，ｈ１」で示す記載領域にそのまま記載される。例えば、マイナンバーカードや運転免許証の場合は漢字のまま記載され、在留カードやパスポートの場合、アルファベットのまま記載される。なお、在留カードの場合、一部漢字が記録される場合があるため、その場合当該情報もそのまま記載される。その後、処理はステップＳ５１０へ進む。
【0145】
ステップＳ５０６では、記載するための条件に該当するか否かが判定される。照合部２９は、ステップＳ５０２で取得された条件情報（記載するための条件）と、ステップＳ５０３で取得された媒体情報（図２６のステップＳ３０３で取得された身分証明書の種類やステップＳ３０２で取得された本人確認の結果を示す情報）とを照合することで、記載するための条件に該当するか否かを判定する（上述したケース３及びケース４）。例えば、図１２に示すフィールド８の項目種類「固定文字」の場合、記載するための条件は、「マイナンバーカード」であるため、ステップＳ３０２で読み取られた身分証明書がマイナンバーカードである場合は、記載条件に該当すると判定され、マイナンバーカード以外である場合は、記載条件に非該当と判定される。また、記載するための条件が「すべて」である場合は、どの身分証明書が読み取られた場合であっても、記載条件に該当すると判定される。
【0146】
また、例えば、図１２に示すフィールド９の項目種類「番号」の場合、記載するための条件は、「運転免許証、在留カード」であるため、ステップＳ３０２で読み取られた身分証明書が運転免許証又は在留カードである場合は、記載条件に該当すると判定され、運転免許証及び在留カード以外である場合は、記載条件に非該当と判定される。また、例えば、図１２に示すフィールド８の項目種類「固定文字」の場合、記載するための条件は、「本人確認がＮＧであること」であるため、ステップＳ３０２で取得された本人確認結果がＮＧである場合は、記載条件に該当すると判定され、本人確認結果がＮＧでない場合は、記載条件に非該当と判定される。非該当と判定された場合（ステップＳ５０６のＮｏ）、処理はステップＳ５１０へ進む。一方、該当すると判定された場合（ステップＳ５０６のＹｅｓ）、処理はステップＳ５０７へ進む。
【0147】
ステップＳ５０７では、帳票項目に対する入力情報（ユーザ情報等）の表現方法について変更が必要か否か判定される。照合部２９は、ステップＳ５０２で取得された条件情報（表現方法条件）と、ステップＳ５０３で取得された媒体情報とを照合することで、ステップＳ３０４で取得された、帳票項目に対する入力情報の表現方法の変更が必要か否かを判定する（上述したケース１及びケース２）。
【0148】
なお、表現方法条件と照合する対象の媒体情報は、上述の通り、読み取られたユーザ情報（ケース１）であっても、読み取られた身分証明書の種類に対して定義された、帳票項目に対応する記録項目の表現方法（ケース２）であってもよい。例えば、ケース１の方法を採用する場合、図１２に示すフィールド２の項目種類「住所」の表現方法条件「都道府県を補完」と、読み取られた「住所」に係るユーザ情報「ＣＣＣＣＣＣＣ」とを照合する。この場合、「ＣＣＣＣＣＣＣ」において都道府県情報が省略されていると判定されると、表現方法の変更（都道府県情報の補完）が必要と判定される。また、例えば、ケース２の方法を採用する場合、図１２に示すフィールド２の項目種類「住所」の表現方法条件「都道府県を補完」と、読み取られた身分証明書の種類（例えば「パスポート」）に対して定義された「住所」についての表現方法「都道府県のみ」とが照合され、表現方法の変更（都道府県データの補完）が不要と判定される。
【0149】
表現方法の変更が必要と判定された場合（ステップＳ５０７のＹｅｓ）、処理はステップＳ５０８へ進む。一方、表現方法の変更が必要ないと判定された場合（ステップＳ５０７のＮｏ）、処理はステップＳ５０９へ進む。なお、固定文字を記載する帳票項目（図１２のフィールド６～８）の場合、項目の種類や表現方法条件により、固定文字を記載する項目であることが明確であるため、上述の照合を行うことなく情報の表現方法の変更が不要と判定され、処理はステップＳ５０９へ進む。
【0150】
ステップＳ５０８では、入力情報の表現方法が変更（条件処理）された上で指定領域に記載（配置）される。帳票生成部３０は、ステップＳ３０４で取得された、帳票項目に対する入力情報の表現方法を、ステップＳ５０２で取得された条件情報（表現方法条件）に合わせて変更する。そして、帳票生成部３０は、表現方法が変更された入力情報（項目データ）を、下敷きデータ（複製された下敷きデータ）の指定領域（ステップＳ５０１で取得された領域情報が示す領域）に記載（配置）する。その後、処理はステップＳ５１０へ進む。例えば、項目種類「住所」の入力情報に対して都道府県情報が補完された上で、指定領域に記載される。その後、処理はステップＳ５１０へ進む。
【0151】
ステップＳ５０９では、情報が指定領域に記載される。帳票生成部３０は、ステップＳ３０４で取得された、帳票項目に対する入力情報をそのまま、項目データとして、下敷きデータ（複製された下敷きデータ）の指定領域（ステップＳ５０１で取得された領域情報が示す領域）に記載（配置）する。例えば、上述の例では、「住所」についての入力情報「ＣＣＣＣＣＣＣ」が都道府県情報を含むものである場合、入力情報「ＣＣＣＣＣＣＣ」は、データ補完が行われることなく指定領域に記載される。また、固定文字を記載する帳票項目（図１２のフィールド６～８）の場合は、表現方法条件で指定された固定文字（例えば、「〇」や「※」）が指定領域に記載される。その後、処理はステップＳ５１０へ進む。
【0152】
ステップＳ５１０では、全ての帳票項目について処理が終了したか判定される。照合部２９は、帳票フォームＡにおいて定義されている全ての帳票項目について、ステップＳ５０１～ステップＳ５０９の処理が終了したか否かを判定する。全ての帳票項目について処理が終了していないと判定された場合（ステップＳ５１０のＮｏ）、処理はステップＳ５０１へ戻り、まだ処理が終了していない帳票項目（別のフィールドの帳票項目）についての処理が行われる。一方、全ての帳票項目について処理が終了していると判定された場合（ステップＳ５１０のＹｅｓ）、帳票生成部３０により各フィールドにデータが配置された帳票データが生成され、本フローチャートに示された処理は終了する。なお、本フローチャートに示す処理では、領域に関する条件を使用する処理について触れていないが、ステップＳ５０５、ステップＳ５０９、ステップＳ５１０等において、領域に関する条件を参照することにより、背景の塗りつぶし処理等が帳票生成部３０により行われてよい。
【0153】
以上より、本実施形態によれば、帳票フォームに定義された記載条件と媒体情報とを照合した結果に応じて、帳票項目の記載位置における記載内容を異ならしめることにより、媒体の種類を意識することなく帳票を容易に作成することが可能となる。つまり、本実施形態によれば、帳票フォームで記載条件を定義することにより、身分証明書における表現方法と帳票における表現方法に関する決まり（条件）との間に違いがある場合であっても、自動で、当該帳票フォームに必要な内容（読み取った情報等）が、適した表現方法で記載された帳票を生成することが可能である。そのため、ユーザは、読み取る（提示する）身分証明書の種類を意識することなく、帳票を容易に作成することが可能である。つまり、本実施形態によれば、記載条件を定義することにより、複数の身分証明書に対応した帳票作成方法を提供することが可能である。
【0154】
また、本実施形態によれば、帳票フォームに記載条件を定義することで複数の身分証明書に対応することが可能であるため、複数の身分証明書に対応するための帳票フォームの修正や追加等の手間を削減することが可能である。そのため、身分証明書の種類間で、記録されている項目の種類（記録事項）や表現方法に違いがあっても、容易に帳票フォームを生成（設定）することが可能である。つまり、身分証明書について精通していないユーザであっても、身分証明書の種類（身分証明書毎の記録事項や表現方法）を意識することなく、帳票フォームを容易に生成することが可能である。
【0155】
更に、本実施形態によれば、記載条件と、読み取られた身分証明書の種類に対して媒体定義で定義された表現方法とを照合することで、当該身分証明書から読み取られた情報の表現方法を変更した上で帳票に記載すべきか否かを判定することが可能となる。これより、帳票（帳票フォーム）に合わせて当該情報の表現方法を変更する必要があるか否かを容易に判定することが可能である。
【0156】
また、本実施形態によれば、身分証明書から読み取られた情報又は表現方法が変更された後の読み取られた情報が自動で帳票に転記されることで、記載済みの帳票を作成することができるため、ユーザが帳票に情報を手書き又は手入力する手間を削減することが可能となる。また、身分証明書から読み取られた情報又は表現方法が変更された後の読み取られた情報が自動で帳票に転記されるため、ユーザが帳票に情報を手書きする場合に発生する誤字、脱字を防ぐことが可能となり、その結果、作成された帳票をチェックする手間を削減することが可能となる。
【0157】
また、本実施形態によれば、下敷きデータ（申請書の撮像画像等）に対して印字したい場所（領域）を選択し、印字する情報（項目の種類）と記載条件とを選択することで帳票フォームを生成することが可能であるため、帳票フォームを容易に作成、変更することが可能である。
【0158】
また、本実施形態によれば、利用者の用途と、用途に沿って必要となる帳票（帳票フォーム）とを対応付けておき、ユーザから用途の選択を受け付けると、選択された用途に対応付けられた１以上の帳票フォームを、用途に適した帳票フォームとして選択することにより、帳票フォームの選択を容易に行うことが可能である。つまり、用途と、用途に沿って必要な帳票フォームとを対応付けておくことにより、帳票フォームの選択を容易に行うことが可能となる。また、本実施形態によれば、用途に沿って必要となる全ての帳票フォームを当該用途と対応付けて記憶しておくことにより、ユーザにより用途が選択された場合に、当該用途に必要な帳票フォームを漏れなく選択（提供）することが可能となる。例えば、市役所にて戸籍謄本が必要だが、代理人が申請を行う場合は、戸籍謄本申請書類以外に追加で委任状が必要な場合がある。このような場合に、代理人が戸籍謄本を行うという用途に対して、戸籍謄本申請書及び委任状の夫々についての帳票フォームを対応付けて記憶しておく。これより、代理人が、当該用途を選択した場合に、戸籍謄本申請書の帳票フォームだけでなく、委任状についての帳票フォームについても選択されることとなる。このように、利用者のやりたいこと（用途）と、用途に合った１又は複数の帳票（帳票フォーム）とを対応付けることで、利用者は、用途に適した帳票フォームを使用（選択）することが可能となる。
【0159】
また、本実施形態では、用途（帳票リスト）を階層構造で定義するため、ユーザは、やりたいことを階層的に選択することが可能となり、用途の選択が容易になる。また、用途（帳票リスト）を、手続きの種類を示す用途要素の層と、当該手続きの種類に関する層の下層に位置する、ユーザの属性（手続を行うユーザや手続きの対象者の属性）を示す用途要素の層とを含む階層構造にすることで、手続きの種類が同一であってもユーザの属性が異なる場合は、異なる帳票フォームが選択（提供）されるようにすることが可能となる。
【0160】
また、本実施形態によれば、用途に対応づける帳票フォームを変更したい場合や、用途に対応付ける帳票フォームを追加したい場合には、用途と帳票フォームとの対応付け関係を変更すれば済むため、容易に、用途に対応付ける帳票フォームの変更、追加を行うことが可能である。
【0161】
更に、本実施形態によれば、利用者は、用途（申請書種別等）を選択し、身分証明書を読取装置９にセットするだけで、簡単かつ即座に記載済み申請書を作成することが可能となる。また、本実施形態によれば、用途を複数選択することで、複数の帳票データ（複数枚の申請書）を纏めて作成することができるため、帳票を作成したいユーザが、複数枚の帳票を夫々作成する手間を削減することが可能となる。
【0162】
［バリエーション１］
上述した実施形態では、ユーザが用途（用途要素）を選択することで帳票フォームが選択される実施態様について説明したが、帳票フォームの選択方法には、任意の方法が用いられてよい。本バリエーションでは、ユーザが、用途を選択することなく、直接帳票（帳票フォーム）を選択する実施態様について説明する。
上述した実施形態では、ユーザが用途（用途要素）を選択することで帳票フォームが選択される実施態様について説明したが、帳票フォームの選択方法には、任意の方法が用いられてよい。本バリエーションでは、ユーザが、用途を選択することなく、直接帳票（帳票フォーム）を選択する実施態様について説明する。
【0163】
本バリエーションにおけるシステムの構成及び情報処理装置１の機能構成は、夫々図１及び図２に示す構成と概略同様であるため、説明を省略する。但し、本バリエーションでは、ユーザが所望する帳票を作成するために使用する帳票フォームを直接選択するため、情報処理装置１は、必ずしも帳票リストを作成及び記憶しておく必要がなく、また同様に、用途と帳票フォームとの対応付けを必ずしも行う必要がない。そのため、本バリエーションのように、用途を選択することで帳票フォームを選択する方法以外の方法が用いられる場合、情報処理装置１は、帳票リスト生成部２５、帳票リスト記憶部２６２及び用途選択受付部２７１を必ずしも備えなくてよい。
【0164】
また、本バリエーションに係る帳票フォーム生成処理、帳票生成・出力処理及び帳票生成処理は、夫々、図２４、図２６（図２７）及び図２９に示す処理と概略同様であるため、説明を省略する。また、本バリエーションでは、図２５に示された処理（帳票リスト生成・対応付け処理）を行わない。また、本バリエーションでは、帳票フォーム選択処理として、図２８に示された処理は行わないこととする。本バリエーションでは、図２６におけるステップＳ３０１において、帳票フォーム選択部２７（選択部２７２）は、ユーザから帳票フォームの選択入力を受け付けると、選択入力に係る帳票フォームを、帳票フォーム記憶部２６１に記憶された帳票フォームの中から選択する。
【0165】
なお、帳票フォームを選択する方法には、ユーザが直接帳票フォームを選択する方法以外に、階層構造で構成されない用途と帳票フォームとを対応付けておくことで、ユーザにより選択された用途に対応する帳票フォームを選択する方法が採用されてもよい。
【0166】
［バリエーション２］
上述した実施形態では、記載条件を定義した帳票フォーム（図１２を参照）を生成し、当該帳票フォームを帳票作成に用いる実施態様について説明したが、帳票フォームには任意の帳票フォームが用いられてよい。本バリエーションでは、記載条件が定義されていない帳票フォーム（帳票項目定義）を用いる実施態様について説明する。また、本バリエーションでは、記載条件を定義しないため、上述した、記載条件と媒体情報との照合処理を行わないこととする。
上述した実施形態では、記載条件を定義した帳票フォーム（図１２を参照）を生成し、当該帳票フォームを帳票作成に用いる実施態様について説明したが、帳票フォームには任意の帳票フォームが用いられてよい。本バリエーションでは、記載条件が定義されていない帳票フォーム（帳票項目定義）を用いる実施態様について説明する。また、本バリエーションでは、記載条件を定義しないため、上述した、記載条件と媒体情報との照合処理を行わないこととする。
【0167】
本バリエーションにおけるシステムの構成及び情報処理装置１の機能構成は、夫々図１及び図２に示す構成と概略同様であるため、説明を省略する。但し、本バリエーションでは、記載条件を帳票フォームに定義せず、また、記載条件と媒体情報との照合処理も行わない。そのため、情報処理装置１は、条件記憶部２１、媒体定義記憶部２２及び照合部２９を必ずしも備えなくてよい。
【0168】
また、本バリエーションに係る帳票フォーム生成処理、帳票リスト生成・対応付け処理、帳票生成・出力処理及び帳票フォーム選択処理は、夫々、図２４、図２５、図２６（図２７）及び図２８に示す処理と概略同様であるため、説明を省略する。但し、本バリエーションでは帳票フォームにおいて記載条件を定義しないため、本バリエーションでは、図２４におけるステップＳ１０４の処理は行わない（省略する）こととする。また、本バリエーションでは、帳票生成処理として、図２９に示された処理は行わないこととする。本バリエーションでは、図２６におけるステップＳ３０５において、帳票生成部３０は、ステップＳ３０１で選択された帳票フォームにおける帳票項目についての項目データ（ステップＳ３０４で取得されたユーザ情報等）を帳票フォームで定義された記載領域に記載した帳票（帳票データ）を生成する。以下、本バリエーションに係る帳票フォームの一例を示すが、本バリエーションでは、任意の帳票フォームを採用可能である。
【0169】
図３０は、本バリエーションに係る帳票フォーム（項目定義）の一例を示す。図３０に示すように、本バリエーションにおける帳票フォームでは、記載条件が定義されていない。図３０に示す帳票フォームでは、帳票項目の種類（項目種類）毎に、複数の身分証明書の夫々に対応する記載領域（項目データの記載領域）が定義されている。同一の帳票項目（項目種類）であっても、読み取られた身分証明書の種類に応じて記載領域が異なるよう、帳票フォームに定義されてよい。
【符号の説明】
【0170】
１ 情報処理装置
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】
【図15】
【図16】
【図17】
【図18】
【図19】
【図20】
【図21】
【図22】
【図23】
【図24】
【図25】
【図26】
【図27】
【図28】
【図29】
【図30】