JP6869004B2 - 文書管理装置および文書管理方法 - Google Patents

Description

この発明は、データ処理技術に関し、特に文書の電子データを管理する技術に関する。

企業の経済活動では個人番号等が記載される様々な重要書類が作成されるが、近年、一定の要件を満たせば、紙媒体の重要書類を電子データに変換して保存することが認められている。その一方、マイナンバー法や改正電子帳簿保存法等が施行され、個人番号等が記載された重要書類の適切な管理が企業に求められている。

特開２００８−４０４１号公報

重要書類の電子データは、単に保存すればよいわけではなく、様々な業務イベントに応じて、適切なタイミングで破棄することが必要になることもある。また、書類の種類に応じて破棄すべきタイミングが異なることもある。本発明は、こうした課題に鑑みてなされたものであり、主たる目的は、利便性の高い文書データの管理を実現する技術を提供することである。

上記課題を解決するために、本発明のある態様の文書管理装置は、複数種類の文書のデータを保存する文書データ記憶部と、予め定められた文書の種類ごとの保存期間であって、所定イベントの発生を起算日とする保存期間を記憶する文書属性記憶部と、所定イベントの発生に基づく破棄対象文書の破棄指示を取得する指示取得部と、破棄指示が指定する破棄対象文書のデータの破棄処理を、文書属性記憶部に記憶された破棄対象文書の種類に応じた保存期間が経過した後に実行する文書破棄部と、を備える。

本発明の別の態様は、文書管理方法である。この方法は、コンピュータが実行する文書管理方法であって、予め定められた文書の種類ごとの保存期間であって、所定イベントの発生からの保存期間を記憶部に記憶させるステップと、複数種類の文書のデータを記憶部に記憶させるステップと、所定イベントの発生に基づく破棄対象文書の破棄指示を取得するステップと、破棄指示が指定する破棄対象文書のデータの破棄処理を、破棄対象文書の種類に応じた保存期間が経過した後に実行するステップと、を備える。

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

本発明によれば、利便性の高い文書データの管理を実現できる。

実施例の文書管理システムの構成を示す図である。 図１の企業端末の機能構成を示すブロック図である。 マスタ登録画面の例を示す図である。 帳票登録画面の例を示す図である。 登録内容確認画面の例を示す図である。 帳票検索画面の例を示す図である。 承認対象明細の例を示す図である。 検索結果画面の例を示す図である。 図１の文書管理装置の機能構成を示すブロック図である。 帳票データ記憶部に記憶される登録帳票データの情報項目を示す図である。 実施例の３つの破棄パターンを模式的に示す図である。 帳票データの属性値の更新例を示す図である。

本発明の実施例を説明する前にまず概要を説明する。一部既述したように、現在、企業には、個人番号や様々な個人情報が記載された文書を適切に管理することが求められている。実施例では、文書の電子化から、その電子データの保存、破棄まで、一気通貫の文書管理ソリューションを実現する技術を提案する。実施例の文書管理装置は、複数の企業に対して、各企業が管理すべき種々の文書の電子データを安全に保存し、また、正しいタイミングで破棄するサービスを提供する。

実施例の文書管理装置が保存する文書は、例えば、口座開設申込書、口座振替依頼書、ローン契約書等、個人番号（マイナンバー）を含む個人情報が記載された書類を含む。また、契約書、図面、手術同意書、取締役会議事録等、個人番号を含まない重要書類を含む。
このように実施例の文書管理装置は、様々な種類・形式の文書を管理可能であるが、以下では管理される文書を「帳票」ともいう。実施例の帳票は、金銭や物品、役務の取引や出入りを記録した、帳簿や伝票などの定型的な書類だけでなく、口座開設申込書等、企業の経済活動で作成される種々の文書を広く含む。

図１は、実施例の文書管理システムの構成を示す。文書管理システム１０は、文書管理装置１２、企業端末１４で総称される企業端末１４ａ、企業端末１４ｂ、企業端末１４ｃ、スキャナ１６で総称されるスキャナ１６ａ、スキャナ１６ｂ、スキャナ１６ｃ、個人番号管理装置１８を備える。

企業端末１４ａ、企業端末１４ｂ、企業端末１４ｃは、互いに異なる企業Ａ、企業Ｂ、企業Ｃに配置され、各企業の文書管理担当者（以下「企業担当者」とも呼ぶ。）により操作されるＰＣである。企業Ａ、企業Ｂ、企業Ｃは、改正電子帳簿保存法における文書の保存義務者に該当し、顧客の個人情報が記載された文書を適切に保存することが求められる。そこで企業Ａ、企業Ｂ、企業Ｃは、文書管理装置１２が提供する文書保存サービスを利用する。企業端末１４ａ、企業端末１４ｂ、企業端末１４ｃは、それぞれスキャナ１６ａ、スキャナ１６ｂ、スキャナ１６ｃに接続される。各企業の担当者は、保存すべき紙媒体の帳票をスキャナ１６に読み取らせる。スキャナ１６から出力された帳票の画像データは文書管理装置１２へアップロードされる

個人番号管理装置１８は、政府が個人に対して付与した一身専属的なＩＤである個人番号を管理する情報処理装置である。個人番号管理装置１８は、個人番号が登録された場合に、登録された個人番号とは異なる個人の識別子（以下「個人コード」と呼ぶ。）を採番して、その個人コードを登録元へ提供し、個人番号と個人コードを対応付けて保持する。例えば、個人番号管理装置１８は、利用者から個人コードが記載された文書データを受け付けると、その個人コードを対応する個人番号に置換し、置換後の文書データを官公庁提出用の文書データとして利用者へ送信してもよい。

文書管理装置１２は、企業Ａ、企業Ｂ、企業Ｃ（すなわち改正電子帳簿保存法における文書の保存義務者）に対してＡＳＰ（Application Service Provider）型の文書保存サービスを提供する情報処理装置である。文書管理装置１２は、企業端末１４から登録された複数種類の帳票の電子データ（実施例ではＰＤＦデータ、以下「帳票ＰＤＦデータ」とも呼ぶ。）を保存し、適切なタイミングで破棄する。文書管理装置１２は、物理的に複数台の装置（例えばアプリケーションサーバとデータベースサーバ）が連携することにより実現されてもよい。

文書管理装置１２は、専用線２０を介して企業端末１４ａ、企業端末１４ｂ、企業端末１４ｃ、個人番号管理装置１８と通信する。これにより、文書管理装置１２に対する不正アクセスや、文書管理装置１２からの情報漏洩を防止しやすくなる。なお、文書管理装置１２の情報セキュリティを一層高めるために、文書管理装置１２は、インターネットに接続されなくてもよい。同様に、企業端末１４ａ、企業端末１４ｂ、企業端末１４ｃ、個人番号管理装置１８もインターネットに接続されなくてもよい。

図２は、図１の企業端末１４の機能構成を示すブロック図である。企業端末１４は、制御部２２、入力部２４、スキャナドライバ２６、通信部２８を備える。制御部２２は、文書管理装置１２が提供する文書保存サービスの利用者としての各種データ処理を実行する。入力部２４は、キーボードやマウスを含み、企業担当者による操作を制御部２２へ入力する。スキャナドライバ２６は、スキャナ１６とのインタフェースを提供する。通信部２８は、所定の通信プロトコルにしたがって外部装置と通信する。制御部２２は、スキャナドライバ２６を介してスキャナ１６とデータを交換し、通信部２８および専用線２０を介して文書管理装置１２とデータを交換する。図２には不図示だが、企業端末１４は、制御部２２により参照・更新されるデータを記憶する記憶部をさらに備える。

本明細書のブロック図において示される各ブロックは、ハードウェア的には、コンピュータのＣＰＵ・メモリをはじめとする素子や機械装置で実現でき、ソフトウェア的にはコンピュータプログラム等によって実現されるが、ここでは、それらの連携によって実現される機能ブロックを描いている。したがって、これらの機能ブロックはハードウェア、ソフトウェアの組合せによっていろいろなかたちで実現できることは、当業者には理解されるところである。

実施例において、制御部２２の各ブロックの機能は、文書管理装置１２の文書保存サービスを利用するアプリケーションプログラム（以下「文書管理Ａｐｐ」とも呼ぶ。）として実装され、文書管理Ａｐｐが企業端末１４のストレージにインストールされる。企業端末１４のＣＰＵは、文書管理Ａｐｐをメインメモリへ読み出して実行することにより、制御部２２の各ブロックの機能を発揮させる。変形例として、制御部２２の各ブロックの機能は、文書管理装置１２から提供されるウェブページに実装されてもよく、企業端末１４にインストールされたウェブブラウザが、当該ウェブページ（Ｊａｖａｓｃｒｉｐｔ（登録商標）プログラム等）を実行することにより、制御部２２の各ブロックの機能を発揮させてもよい。

制御部２２は、マスタ処理部３０、帳票処理部３２、検索処理部３４、破棄処理部３６を備える。マスタ処理部３０は、帳票マスタの登録に関する処理を実行し、帳票処理部３２は、帳票データの登録に関する処理を実行する。また、検索処理部３４は、帳票データの検索と承認に関する処理を実行し、破棄処理部３６は帳票データの破棄に関する処理を実行する。

マスタ処理部３０は、マスタ登録画面表示部３８とマスタ登録部４０を含む。マスタ登録画面表示部３８は、帳票マスタを登録する画面であるマスタ登録画面をディスプレイに表示させる。帳票マスタは、帳票の種類（例えば口座開設申込書、口座振替依頼書）ごとに定められる帳票の属性項目を定めたデータであり、帳票のメタデータとも言える。図３はマスタ登録画面の例を示す。マスタ登録画面１１０で設定可能な帳票マスタの情報項目は、帳票コード、帳票名、法定書類分類、個人情報有無、起算基準、破棄指示区分、保存期間開始区分、保存期間、承認要否区分を含む。

帳票コードには、口座開設申込書、口座振替依頼書等の帳票の種類ごとにユニークなＩＤであり、言い換えれば、複数種類の帳票の中から１つの種類の帳票を特定可能なＩＤが設定される。法定書類分類には、改正電子帳簿保存法における重要書類、一般書類、または改正電子帳簿保存法の対象外の書類のいずれかが設定される。個人情報有無には、特定個人情報あり（個人番号を含む個人情報あり）、個人情報あり（個人番号を含まない個人情報あり）、個人情報なしのいずれかが設定される。起算基準は、帳票データの保存期間の起算日の設定基準が設定される。例えば、「登録日基準」、「破棄指示基準」を含む複数の候補の中からいずれかが設定される。

破棄指示区分には、帳票データの破棄指示を自動とするか、手動とするかが設定される。自動の場合、保存期限が自動設定され、手動の場合、企業端末１４からの明示的な破棄指示に応じて保存期限が設定される。保存期間開始区分は、保存期間の始期が設定される。例えば、「起算日」、「起算日の翌年」を含む複数の候補の中からいずれかが設定される。保存期間には、帳票データの保存期間であり、起算日からの時間の長さが設定される。承認要否区分には、帳票データ登録時に承認を必要とするか否かが設定される。

マスタ登録部４０は、マスタ登録画面１１０において登録ボタン１１２が選択された場合に、マスタ登録画面１１０に入力された帳票マスタの情報項目値（属性値）を文書管理装置１２へ送信し、登録する。

図２に戻り、帳票処理部３２は、帳票登録画面表示部４２、画像取得部４４、画像登録部４６、帳票登録部４８を含む。帳票登録画面表示部４２は、企業が保存すべき実際の帳票（例えば複数の顧客の複数の口座開設申込書）を登録するための帳票登録画面をディスプレイに表示させる。図４は帳票登録画面の例を示す。帳票登録画面１２０は、スキャンボタン１２２ａ、スキャンボタン１２２ｂ、帳票検索ボタン１２４、帳票情報エリア１２６、特定キー入力エリア１２８、検索項目入力エリア１３０、サムネイルエリア１３２、帳票画像エリア１３４、登録確認ボタン１３６を含む。

画像取得部４４は、スキャンボタン１２２ａまたはスキャンボタン１２２ｂが選択された場合に、紙媒体の帳票を読み取るように指示するデータをスキャナ１６へ送信する。画像取得部４４は、上記指示に応じてスキャナ１６から出力された１つ以上の画像データ（例えばＪＰＥＧファイル、以下「帳票画像データ」とも呼ぶ。）を取得する。例えば、複数枚の帳票に対応する複数個の帳票画像データを取得する。画像登録部４６は、画像取得部４４により取得された１つ以上の帳票画像データを文書管理装置１２へ送信する。

帳票登録画面表示部４２は、画像取得部４４により取得された１つ以上の帳票画像データを縮小した１つ以上のサムネイル画像を生成し、生成したサムネイル画像をサムネイルエリア１３２に表示させる。また、帳票登録画面表示部４２は、サムネイルエリア１３２において選択された１つのサムネイル画像に対応する１つの帳票画像データ（サムネイルエリア１３２でサムネイル画像が未選択であれば１枚目の帳票画像データ）を帳票画像エリア１３４に表示させる。

帳票登録画面表示部４２は、帳票登録画面１２０の帳票検索ボタン１２４が選択されると、登録済みの帳票マスタのデータを文書管理装置１２から取得し、帳票マスタの一覧を別画面（不図示）にポップアップ表示させる。その別画面にてスキャン対象の帳票のマスタが選択されると、帳票登録画面表示部４２は、選択された帳票マスタのデータ（帳票コード、帳票名等）を帳票情報エリア１２６に表示させる。

変形例として、文書管理装置１２は、帳票マスタごとに帳票画像の雛形の登録を企業端末１４から予め受け付け、企業端末１４から送信された帳票画像データに整合する帳票マスタを検出し、その帳票マスタのデータを画像登録元の企業端末１４へ送信してもよい。帳票登録画面表示部４２は、企業端末１４から提供された帳票マスタのデータを帳票情報エリア１２６に表示させることにより、スキャンされた帳票に対応する帳票マスタのデータを帳票情報エリア１２６に自動で設定してもよい。これにより、帳票の種類を手作業で選択することが不要になり、企業担当者の負担を軽減できる。

特定キー入力エリア１２８には、帳票に記載された個人をユニークに特定可能な情報項目であり、文書管理装置１２で予め定められた情報項目である特定キーが入力される。例えば、企業担当者は、登録対象の帳票を確認しつつ、会社コード予備、組織コード、個人コード、帳票記載日付（例えば取引日付）、帳票記載金額（例えば取引金額）を特定キーとして手入力してもよい。個人番号管理装置１８を利用する企業の場合、個人コードには、個人番号管理装置１８から発行された個人コード（個人番号とは異なるＩＤ）が入力されてもよい。個人番号管理装置１８を利用しない企業の場合、個人コードとして個人番号が入力されてもよい。検索項目入力エリア１３０には、帳票の検索に使用される検索項目が入力される。例えば企業担当者は、登録対象の帳票を確認しつつ、予め定められた検索項目（例えば取引先名称等）を手入力する。

帳票登録画面１２０において登録確認ボタン１３６が選択されると、帳票登録部４８は、帳票登録画面１２０に入力されたデータ、具体的には、帳票情報エリア１２６、特定キー入力エリア１２８、検索項目入力エリア１３０に入力されたデータを含む帳票登録要求を文書管理装置１２へ送信する。帳票登録画面表示部４２は、帳票登録要求に対する文書管理装置１２の応答内容にしたがって、登録内容確認画面をポップアップ表示させる。

図５の（ａ）（ｂ）（ｃ）は、登録内容確認画面の例を示す。図５（ａ）は、登録要求に対する応答内容が第１パターンである場合の登録内容確認画面１４０を示している。第１パターンは、帳票登録画面１２０に入力された会社コード（会社コード予備）が個人番号管理装置１８の利用者を示し、かつ、帳票登録画面１２０に入力された特定キー（例えば会社コード予備、組織コード、個人コードの組み合わせ）が個人番号管理装置１８に登録済の場合の応答である。また、第１パターンの応答は、帳票登録画面１２０に入力された特定キーに対応付けて個人番号管理装置１８が保持する氏名を含む。図５（ａ）の登録内容確認画面１４０では、帳票に記載された個人が個人番号管理装置１８に登録済みであることを示すメッセージ、帳票登録画面１２０に入力された特定キー、および特定キーに対応する氏名が表示される。

図５（ｂ）は、登録要求に対する応答内容が第２パターンである場合の登録内容確認画面１４０を示している。第２パターンは、帳票登録画面１２０に入力された会社コードが示す企業が個人番号管理装置１８の利用者であるが、帳票登録画面１２０に入力された特定キーが個人番号管理装置１８に未登録の場合の応答である。図５（ｂ）の登録内容確認画面１４０では、帳票に記載された個人が個人番号管理装置１８に未登録であることを示すメッセージと、特定キーの正誤を再度確認するように促すメッセージが表示される。

図５（ｃ）は、登録要求に対する応答内容が第３パターンである場合の登録内容確認画面１４０を示している。第３パターンは、帳票登録画面１２０に入力された会社コードが個人番号管理装置１８の利用者に該当しない場合の応答である。図５（ｃ）の登録内容確認画面１４０では、帳票登録画面１２０に入力された特定キーが表示される。このように、実施例の文書管理システム１０では、文書管理装置１２が個人番号管理装置１８と連携して、企業担当者による登録内容確認を支援する（例えば図５（ａ））。また、企業端末１４から文書管理装置１２への登録内容に誤りがある可能性が高い場合、その旨を企業担当者に通知する（例えば図５（ｂ））。

登録内容確認画面１４０にて登録ボタン１４２が選択されると、帳票登録部４８は、帳票の登録確定を指示するデータ（以下「登録確定指示」とも呼ぶ。）を文書管理装置１２へ送信する。後述するように、文書管理装置１２は、登録確定指示にしたがって、帳票データ（帳票の画像を含むＰＤＦデータ）の保存を実行する。

図２に戻り、検索処理部３４は、検索画面表示部５０、検索要求部５２、承認画面表示部５４、承認結果登録部５６、検証要求部５８、ＣＳＶ出力部６０を含む。検索画面表示部５０は、文書管理装置１２へ登録された帳票を検索するための帳票検索画面をディスプレイに表示させる。図６は帳票検索画面の例を示す。帳票検索画面１５０では、帳票種類（すなわち帳票コード）、特定キー、ステータス、任意の検索項目１〜３、各種日付（期間）を含む検索条件が指定可能である。

文書管理装置１２で管理される帳票のステータスは、例えば「登録中」「承認待ち」「保管済」「登録取消」「破棄済」を含む。帳票検索画面１５０において選択可能なステータスは、さらに「全て（ＡＬＬ）」を含み、「破棄済」を選択できないようにしてもよい。「登録中」は帳票画像を登録済みであるが登録確定前の状態であり、「承認待ち」は登録確定済みであるが承認または非承認が未定の状態である。「保管済」は帳票の登録が承認された状態であり、「登録取消」は帳票の登録が非承認となった状態であり、「破棄済」は登録された帳票が保存期限満了により破棄された状態である。

検索画面表示部５０は、ログインユーザが、業務管理者権限（帳票登録の承認権限）を有する者であり、かつ、ステータスとして承認待ちを選択した場合に、帳票検索画面１５０の承認明細ボタン１５２を選択可能に表示される。帳票検索画面１５０において承認明細ボタン１５２が選択されると、検索要求部５２は、ステータスが承認待ちの帳票データ（ここでは「承認対象明細」とも呼ぶ。）の提供を文書管理装置１２へ要求し、１つ以上の承認対象明細を文書管理装置１２から取得する。検索画面表示部５０は、取得された１つ以上の承認対象明細を帳票検索画面１５０に表示させる。

図７は承認対象明細の例を示す。承認対象明細１５６は、承認対象明細のＰＤＦデータ、各種属性情報、審査ボタン１５７を含む。承認対象明細１５６において審査ボタン１５７が選択されると、承認画面表示部５４は、承認または非承認の選択入力が可能な承認画面をポップアップ表示させる。承認画面において承認または非承認が選択入力されると、承認結果登録部５６は、承認または非承認を示す承認結果データを文書管理装置１２へ送信する。

図６に戻り、帳票検索画面１５０の検索ボタン１５４が選択されると、検索要求部５２は、帳票検索画面１５０で指定された１つ以上の検索条件を含む検索要求を文書管理装置１２へ送信する。検索要求部５２は、検索要求への応答であり、検索条件に合致する１つ以上の帳票データを含む検索結果を文書管理装置１２から取得する。検索画面表示部５０は、文書管理装置１２から提供された検索結果を示す検索結果画面をディスプレイに表示させる。

図８は検索結果画面の例を示す。検索結果画面１５８には、検索結果に含まれる１つ以上の帳票データを並べた帳票リスト１６０が配置される。なお、図７の承認対象明細１５６および図８の帳票リスト１６０は、帳票データに関する他の属性（例えば保存期限や検索項目等）と、帳票マスタの他の属性（例えば起算基準、破棄指示区分等）をさらに含んでもよい。

図８の検索結果画面１５８において一括検証ボタン１６２が選択されると、検証要求部５８は、帳票リスト１６０に表示された１つ以上の帳票データに対する一括検証の要求を文書管理装置１２へ送信する。一括検証の要求は、帳票リスト１６０に表示された各帳票データのユニークＩＤである帳票画像ＩＤを含む。また、図８の検索結果画面１５８においてＣＳＶ出力ボタン１６４が選択されると、ＣＳＶ出力部６０は、帳票リスト１６０に表示された１つ以上の帳票データの各項目の値を並べたＣＳＶファイルをローカルのストレージ（不図示の記憶部）内に生成する。ユーザは、このＣＳＶファイルを編集することで、後述の破棄指示ファイルを容易に作成できる。

図２に戻り、破棄処理部３６は、破棄指示画面表示部６２と破棄指示送信部６４を含む。破棄指示画面表示部６２は、破棄指示を入力するための破棄指示画面をディスプレイに表示させる。企業担当者は、破棄指示画面において破棄指示ファイルを指定する。破棄指示ファイルは、破棄対象となる帳票のユニークＩＤである帳票画像ＩＤを指定し、さらに特定キー、帳票コード、帳票コード予備、起算日を指定するＣＳＶファイルである。なお、起算日の指定は、帳票の起算基準（帳票マスタで定められた起算基準）が破棄指示基準の場合に必須であるが、起算基準が登録日基準の場合は不要である。

破棄指示送信部６４は、帳票登録画面１２０において破棄指示の登録を指示する所定操作が入力された場合に、帳票登録画面１２０で指定された破棄指示ファイルのデータを文書管理装置１２へ送信する。

図９は、図１の文書管理装置１２の機能構成を示すブロック図である。文書管理装置１２は、制御部７０、記憶部７２、通信部７４を含む。制御部７０は、文書管理のための各種データ処理を実行する。記憶部７２は、制御部７０により参照・更新されるデータを記憶する記憶領域である。通信部７４は、所定の通信プロトコルにしたがって外部装置と通信する。制御部７０は、通信部７４を介して、企業端末１４および個人番号管理装置１８とデータを交換する。

記憶部７２は、帳票マスタ記憶部７６、帳票データ記憶部７８、検証結果記憶部８０を含む。検証結果記憶部８０は、一括検証の結果を示すＣＳＶファイルである一括検証結果ファイルを記憶する。

帳票マスタ記憶部７６は、企業端末１４から登録された帳票マスタのデータを記憶する。帳票マスタ記憶部７６は、図３で示した複数の情報項目を含む帳票マスタのデータを記憶する。帳票マスタ記憶部７６は、複数種類の帳票それぞれについて予め定められた保存期間を記憶し、言い換えれば、帳票の種類（すなわち帳票コード）ごとの保存期間を記憶する。ここで、或る帳票マスタにおける起算基準が破棄指示基準であり、かつ、破棄指示区分が手動である場合、その帳票マスタでは、帳票登録後の所定イベントの発生を始期（言い換えれば起算日）とする保存期間が設定される。例えば、個人番号の確認書類の場合、イベント「口座解約」の発生後に当該書類を即時に破棄するため、保存期間が「０」に設定されるかもしれない。また、口座開設申込書の場合、イベント「口座解約」の発生後、７年の保管が必要であるため、保存期間が「７年」に設定されるかもしれない。

帳票データ記憶部７８は、企業端末１４から登録された複数種類（言い換えれば複数形式）の帳票に関する電子データ（以下「登録帳票データ」とも呼ぶ。）を記憶する。既述したように、複数種類の帳票は、口座開設申込書、口座振替依頼書、ローン契約書等を含む。図１０の（ａ）（ｂ）（ｃ）は、帳票データ記憶部７８に記憶される登録帳票データの情報項目を示す。帳票データ記憶部７８は、企業端末１４から登録された帳票ごとに、図１０の（ａ）（ｂ）（ｃ）に示す項目を含む登録帳票データを記憶する。例えば、登録帳票データは、帳票の画像を含むＰＤＦデータ（以下「帳票ＰＤＦデータ」とも呼ぶ。）と、文書の種類を示す帳票コードと、帳票管理におけるステータスを含む。

図９に戻り、制御部７０は、マスタ保存部８２、画像取得部８４、登録内容確認部８６、タイムスタンプ取得部８８、帳票保存部９０、帳票属性更新部９２、破棄指示取得部９４、破棄実行部９６、検索実行部９８、検証実行部１００を含む。これらのブロックの機能は、文書管理プログラムのモジュールとして実装され、文書管理装置１２のストレージにインストールされてもよい。そして文書管理装置１２のＣＰＵが文書管理プログラムをメインメモリへ読み出して実行することにより、各ブロックの機能が発揮されてもよい。

マスタ保存部８２は、企業端末１４から送信された帳票マスタの登録要求を受け付け、登録要求に含まれる帳票マスタのデータを帳票マスタ記憶部７６へ格納する。画像取得部８４は、企業端末１４から送信された帳票画像データを取得する。

登録内容確認部８６は、企業端末１４から送信された帳票登録要求を受け付け、個人番号管理装置１８と連携して登録内容確認処理を実行する。具体的には、登録内容確認部８６は、特定キーの会社コード（会社コード予備）を個人番号管理装置１８へ照会し、帳票登録要求の要求元が個人番号管理装置１８の利用者か否かを判定する。帳票登録要求の要求元が個人番号管理装置１８の利用者である場合、登録内容確認部８６は、特定キー（例えば会社コード予備、組織コード、個人コードの組み合わせ）が個人番号管理装置１８に登録済か否かを個人番号管理装置１８に問い合わせる。

登録内容確認部８６は、帳票登録要求の要求元が個人番号管理装置１８の利用者か否かを示す情報を企業端末１４へ送信する。また、帳票登録要求の要求元が個人番号管理装置１８の利用者である場合には、特定キーが個人番号管理装置１８に登録済みか否かを示す情報をさらに企業端末１４へ送信する。すなわち登録内容確認部８６は、帳票登録要求への応答として、予め設定されたパターンの中から選択した応答（例えば既述の第１パターン〜第３パターンいずれかの応答）を企業端末１４へ送信する。

タイムスタンプ取得部８８は、企業端末１４から送信された登録確定指示が受け付けられた場合に、所定のタイムスタンプサーバ（不図示）から、現在日時を示す「認証された時刻情報」を取得する。

帳票保存部９０は、企業端末１４から登録確定指示が受け付けられた場合に、画像取得部８４により取得済の帳票画像データを含むＰＤＦデータであり、タイムスタンプ取得部８８により取得された、認証された時刻情報を埋め込んだ帳票ＰＤＦデータを生成する。それとともに帳票保存部９０は、所定のハッシュ関数に基づいて帳票ＰＤＦデータのハッシュ値を取得する。帳票保存部９０は、帳票データのユニークキーとして帳票画像ＩＤを採番し、帳票画像ＩＤ、帳票ＰＤＦデータ、ハッシュ値、認証された時刻情報、帳票登録要求で指定された各種属性値（特定キーや検索項目等）を対応付けた登録帳票データ（図１０）を帳票データ記憶部７８へ格納する。

帳票属性更新部９２は、帳票データに関するデータが受け付けられた場合（例えば新規登録時または破棄指示受付時）に、帳票データの各種属性（例えばステータス、登録日、登録時刻、破棄指示日、起算日、保存期限等）を更新する。破棄指示取得部９４は、企業端末１４から送信された破棄指示のデータを取得する。

破棄実行部９６は、帳票データ記憶部７８に記憶された複数の登録帳票データについて、各登録帳票データの属性であるステータスと保存期限を参照し、ステータスが保管済であり、かつ、保存期限が経過した（現在日時において保存期限が過ぎている）登録帳票データを破棄対象として検出する。破棄実行部９６は、破棄対象の登録帳票データに対する破棄処理として、登録帳票データ内の帳票ＰＤＦデータを削除する。ただし、帳票ＰＤＦデータ以外の属性データは削除せずに残す。帳票属性更新部９２は、登録帳票データのステータスを破棄済へ更新する。

実施例の文書管理装置１２は、帳票データ記憶部７８に格納された複数の登録帳票データのそれぞれに対して、保存期間の起算基準が登録日基準と破棄指示基準のいずれであるか、また、起算基準が登録日基準である場合に破棄指示区分が自動と手動のいずれであるかに基づいて、３つの破棄パターンのうちいずれかを適用する。

図１１は、実施例の３つの破棄パターンを模式的に示す。図１１（ａ）は、保存期間の起算基準が登録日基準であり、かつ、破棄指示区分が自動である登録帳票データに適用される第１破棄パターンを示している。第１破棄パターンでは、企業担当者による破棄指示の入力は不要であり、登録帳票データの破棄処理を自動的に実行する。具体的には、帳票データの登録時に、登録日を起算日として設定するとともに、起算日から所定の保存期間が経過する時点を保存期限として設定する。そして保存期限が経過した後に帳票ＰＤＦデータを削除する。第１破棄パターンは、登録日を基準として、機械的に破棄することが許容される帳票に対して適用され、企業担当者の負担は最も低い。

図１１（ｂ）は、保存期間の起算基準が登録日基準であり、かつ、破棄指示区分が手動である登録帳票データに適用される第２破棄パターンを示している。第２破棄パターンでは、企業担当者による破棄指示の入力を条件として登録帳票データに対する破棄処理を実行する。具体的には、破棄指示の入力時に、登録日を起算日として設定するとともに、起算日から所定の保存期間が経過する時点を保存期限として設定する。そして保存期限が経過した後に帳票ＰＤＦデータを削除する。第２破棄パターンは、破棄指示が入力されない限り帳票ＰＤＦデータの保存を継続するため、帳票ＰＤＦデータの削除をより慎重に行うべき場合に好適である。

図１１（ｃ）は、保存期間の起算基準が破棄指示基準である登録帳票データに適用される第３破棄パターンを示している。第２破棄パターンと同様に第３破棄パターンにおいても、破棄指示の入力を条件として登録帳票データに対する破棄処理を実行し、言い換えれば、破棄指示が入力されない限り破棄処理の実行を抑制する。具体的には、破棄指示の入力時に、破棄指示で指定された起算日を設定するとともに、起算日から所定の保存期間が経過する時点を保存期限として設定する。そして保存期限が経過した後に帳票ＰＤＦデータを削除する。第３破棄パターンは、帳票データの登録後に所定イベントが発生したことを契機として（言い換えれば所定イベントの発生を起算日として）、その発生から一定期間後に帳票データを破棄する運用を実現できる。また、企業担当者が起算日を任意に指定できることで、帳票データに対する破棄処理の実行タイミングを柔軟に設定することができる。

図１２は、帳票データ記憶部７８に記憶されるデータの一部を示し、帳票データの属性値の更新例を示す。図１２（ａ）は、帳票データの新規登録時の更新例（登録日は２０１６／４／１）を示し、図１２（ｂ）は、破棄指示受付時の更新例（破棄指示日は２０１７／４／１）を示している。また、図１２（ａ）および（ｂ）の１番目のレコード（Ｎｏ．１）は、第１破棄パターンが適用される登録帳票データを示し、２番目のレコード（Ｎｏ．２）は、第２破棄パターンが適用される登録帳票データを示し、３番目のレコード（Ｎｏ．３）は、第３破棄パターンが適用される登録帳票データを示している。

ここで図１１（ａ）で示した第１破棄パターンを実現する構成を、図１２（ａ）（ｂ）の１番目のレコードを参照しつつ説明する。図１２（ａ）のＮｏ．１で示すように、帳票データ記憶部７８に新たな帳票データが格納され（すなわち帳票データの新規登録時）、その帳票コードにより特定される帳票マスタにおいて保存期間の起算基準が登録日基準であり、かつ、破棄指示区分が自動である場合、帳票属性更新部９２は、登録帳票データの属性「登録日」「破棄指示日」「起算日」のいずれにも現在日時（例えばシステム日時）を設定する。また、帳票属性更新部９２は、登録帳票データの属性「保存期限」に起算日から所定の保存期間が経過する日付を設定する。既述したように保存期間は、帳票コードにより特定される帳票データの種類ごと、言い換えれば、帳票マスタの種類ごとに定められるものであり、保存期限も帳票データの種類ごとに定まる。

図１２（ｂ）のＮｏ．１で示すように、第１破棄パターンでは、登録帳票データの登録日、破棄指示日、起算日、保存期限は登録時点で決まり、破棄指示は不要である。破棄実行部９６は、複数の登録帳票データそれぞれの保存期限を定期的に（１日１回等）参照し、保存期限が過ぎた登録帳票データに対する破棄処理を実行する。

次に、図１１（ｂ）で示した第２破棄パターンを実現する構成を、図１２（ａ）（ｂ）の２番目のレコードを参照しつつ説明する。図１２（ａ）のＮｏ．２で示すように、帳票データ記憶部７８に新たな帳票データが格納され（すなわち帳票データの新規登録時）、その帳票コードにより特定される帳票マスタにおいて保存期間の起算基準が登録日基準であり、かつ、破棄指示区分が手動である場合、帳票属性更新部９２は、登録帳票データの属性「登録日」に現在日時を設定する。また帳票属性更新部９２は、登録帳票データの属性「破棄指示日」「起算日」「保存期限」に予め定められた初期値を設定する。

企業端末１４から破棄指示が受け付けられると、帳票属性更新部９２は、破棄指示に含まれる帳票画像ＩＤにより特定される登録帳票データを破棄対象として識別する。図１２（ｂ）のＮｏ．２で示すように、帳票属性更新部９２は、破棄対象の登録帳票データの属性「破棄指示日」に現在日時を設定し、属性「起算日」に登録日を設定し、属性「保存期限」に起算日から所定の保存期間が経過する日付を設定する。第２破棄パターンにおいても、保存期限は帳票データの種類ごとに定まる。破棄実行部９６は、複数の登録帳票データそれぞれの保存期限を定期的に参照し、保存期限が過ぎた登録帳票データに対する破棄処理を実行する。

次に、図１１（ｃ）で示した第３破棄パターンを実現する構成を、図１２（ａ）（ｂ）の３番目のレコードを参照しつつ説明する。図１２（ａ）のＮｏ．３で示すように、帳票データ記憶部７８に新たな帳票データが格納され（すなわち帳票データの新規登録時）、その帳票コードにより特定される帳票マスタにおいて保存期間の起算基準が破棄指示基準である場合、帳票属性更新部９２は、登録帳票データの属性「登録日」に現在日時を設定する。また帳票属性更新部９２は、登録帳票データの属性「破棄指示日」「起算日」「保存期限」に予め定められた初期値を設定する。

企業端末１４から破棄指示が受け付けられると、帳票属性更新部９２は、破棄指示に含まれる帳票画像ＩＤにより特定される登録帳票データを破棄対象として識別する。図１２（ｂ）のＮｏ．３で示すように、帳票属性更新部９２は、破棄対象の登録帳票データの属性「破棄指示日」に現在日時を設定し、属性「起算日」に破棄指示で指定された起算日を設定し、属性「保存期限」に起算日から所定の保存期間が経過する日付を設定する。第３破棄パターンにおいても、保存期限は帳票データの種類ごとに定まる。破棄実行部９６は、複数の登録帳票データそれぞれの保存期限を定期的に参照し、保存期限が過ぎた登録帳票データに対する破棄処理を実行する。

図１１（ｃ）で示す第３破棄パターンの構成は、次のように表現できる。すなわち、破棄指示取得部９４は、所定イベントの発生を契機として企業端末１４から送信された破棄指示であって、破棄対象文書と当該文書の保存期間の起算日とを指定する破棄指示を取得する。破棄実行部９６は、破棄指示が指定する破棄対象の帳票データに対する破棄処理を、破棄指示が指定する起算日から、帳票データ記憶部７８に記憶された破棄対象の帳票データの種類に応じた保存期間が経過した後に実行する。なお、実際に破棄処理が実行されるタイミングは、保存期間経過後の任意の日であってよく、例えば保存期限を過ぎた月の翌月の第２金曜等であってもよい。

図９に戻り、検索実行部９８は、企業端末１４から送信された検索要求が受け付けられると、帳票データ記憶部７８に記憶された複数の登録帳票データの中から、検索要求で指定された検索条件に合致する登録帳票データを検索する。検索実行部９８は、検索条件に合致する登録帳票データを検索要求元の企業端末１４へ送信して、検索結果を企業端末１４のディスプレイに表示させる。

検証実行部１００は、企業端末１４から送信された一括検証要求が受け付けられると、その要求で指定された１つ以上の帳票画像ＩＤにより特定される１つ以上の登録帳票データを検証対象として識別する。検証実行部１００は、検証対象とした１つ以上の登録帳票データそれぞれについて、帳票ＰＤＦデータに基づくハッシュ値を動的に生成し、生成したハッシュ値と、帳票データ記憶部７８のハッシュ値欄の値とを照合し、両者のハッシュ値が一致するか否かを判定する。また検証実行部１００は、帳票ＰＤＦデータに埋め込まれた、認証された時刻情報の値と、帳票データ記憶部７８の認証された時刻情報の値とを照合し、両者の認証された時刻情報が一致するか否かを判定する。

検証実行部１００は、ハッシュ値と認証された時刻情報の両方が一致する場合、帳票ＰＤＦデータには改ざんがないと判定し、ハッシュ値と認証された時刻情報の少なくとも一方が不一致の場合、帳票ＰＤＦデータに改ざんの疑いがあると判定する。検証実行部１００は、検証対象とした１つ以上の登録帳票データそれぞれに対する判定結果を示す一括検証結果ファイルを生成し、一括検証結果ファイルを検証結果記憶部８０に格納する。検証結果記憶部８０に格納された一括検証結果ファイルは、企業端末１４からの要求に応じて企業端末１４へ提供される。企業担当者は、一括検証結果ファイルを参照して、帳票ＰＤＦデータの改ざん有無を判断できる。また、税務監査等において、帳票ＰＤＦデータの改ざんがないことを示す証左物として、一括検証結果ファイルを活用することができる。

以上の構成による文書管理システム１０の動作を説明する。
ここでは、文書管理装置１２の複数の利用者（複数の企業）のうち特定の企業が文書管理装置１２を利用する際の動作を説明する。文書管理装置１２は、会社コードやログインＩＤ等により利用者を識別して、異なる利用者からの要求を並行処理してもよい。また、利用者ごとにデータベースのテーブルやインスタンスを分離してもよい。

まず、帳票の登録に関する動作を説明する。企業担当者（例えば登録権限を有するオペレータ等）は、企業端末１４において文書管理Ａｐｐを起動し、文書管理装置１２へログインする。企業担当者が文書管理Ａｐｐでマスタ登録メニューを選択すると、企業端末１４のマスタ登録画面表示部３８は、マスタ登録画面１１０（図３）を表示させる。企業端末１４のマスタ登録部４０は、マスタ登録画面１１０に入力された帳票マスタのデータを文書管理装置１２へ送信し、文書管理装置１２のマスタ保存部８２は、帳票マスタのデータを帳票マスタ記憶部７６へ格納する。

企業担当者が文書管理Ａｐｐで帳票登録メニューを選択すると、企業端末１４の帳票登録画面表示部４２は、帳票登録画面１２０（図４）を表示させる。企業担当者は、紙媒体の帳票をスキャナ１６にセットし、スキャンボタン１２２ａまたはスキャンボタン１２２ｂを選択する。帳票登録画面表示部４２は、スキャナ１６により読み取られた帳票画像を帳票登録画面１２０に表示させる。企業担当者は、帳票の記載を確認しつつ、特定キーおよび検索項目を帳票登録画面１２０へ手入力し、登録確認ボタン１３６を選択する。帳票登録部４８は、登録対象の帳票に関する各種属性情報（帳票コード、特定キー、検索項目等）を企業端末１４へ送信する。

変形例として、特定キーと検索項目の少なくとも一部について、帳票に記載された文字をＯＣＲ（Optical Character Recognition）により自動認識し、帳票登録画面１２０に自動設定する構成としてもよい。ただしＯＣＲでは文字の誤認識も発生しやすく、修正作業が頻繁に発生しうる。そのため、現実には実施例のように、帳票の記載内容を人が確認して手入力する方が効率的であり、正確度も高い。

文書管理装置１２の登録内容確認部８６は、個人番号管理装置１８と連携して企業端末１４からの登録内容を確認し、その確認結果を企業端末１４へ通知する。企業端末１４の帳票登録画面表示部４２は、登録内容の正誤を判断させるための登録内容確認画面１４０（図５）を表示させる。登録内容確認画面１４０において登録内容が確定されると、文書管理装置１２の帳票保存部９０は、帳票ＰＤＦデータ、ステータス（承認待ち）、認証された時刻情報、ハッシュ値、各種属性情報を対応付けた登録帳票データを帳票データ記憶部７８へ格納する。帳票属性更新部９２は、登録帳票データの種類に応じて、登録帳票データの保存期間の起算日と保存期限を設定する。

次に、承認時の動作を説明する。企業担当者（例えば承認権限を有する管理者）は、文書管理Ａｐｐにログインし、帳票検索メニューを選択する。企業端末１４の検索画面表示部５０は、帳票検索画面１５０（図６）を表示させる。帳票検索画面１５０においてステータスが承認待ちに設定され、承認明細ボタン１５２が選択されると、企業端末１４の検索要求部５２は、承認待ちの登録帳票データを文書管理装置１２から取得し、検索画面表示部５０は、承認対象明細１５６（図７）を帳票検索画面１５０に表示させる。企業担当者は、承認対象明細１５６の審査ボタン１５７を選択し、登録内容に問題がなければ承認を選択する。文書管理装置１２の帳票属性更新部９２は、承認された承認対象明細１５６に対応する登録帳票データのステータスを保管済へ更新する。

次に、検索時の動作を説明する。特定の登録帳票データを参照したい企業担当者は、文書管理Ａｐｐで帳票検索メニューを選択し、帳票検索画面１５０（図６）を表示させる。企業担当者は、帳票検索画面１５０に対して所望の登録帳票データに関する検索条件（特定キー、検索項目の値等）を入力し、検索ボタン１５４を選択する。企業端末１４の検索要求部５２は、帳票検索画面１５０に入力された検索条件に整合する登録帳票データを文書管理装置１２から取得し、検索画面表示部５０は、検索結果画面１５８（図８）を表示させる。企業担当者は、必要に応じて、検索結果画面１５８の一括検証ボタン１６２を選択する。文書管理装置１２の検証実行部１００は、検索結果画面１５８に表示された１つ以上の登録帳票データについて、各帳票データの改ざんの有無を判定し、判定結果を記録する。

次に、帳票破棄時の動作を説明する。口座解約等の所定の業務イベントが発生した場合に企業担当者は、破棄対象となる登録帳票データを帳票検索画面１５０（図６）で検索する。検索画面表示部５０は、企業担当者が入力した検索条件に応じて、破棄対象となる登録帳票データの一覧を検索結果画面１５８（図８）に表示させる。業務担当者は、検索結果画面１５８のＣＳＶ出力ボタン１６４を選択し、得られたＣＳＶファイルを編集して破棄指示ファイルを作成する。企業担当者は、文書管理Ａｐｐで破棄指示メニューを選択して破棄指示画面を表示させ、作成した破棄指示ファイルを破棄指示画面で指定する。企業端末１４の破棄指示送信部６４は、破棄指示画面で指定された破棄指示ファイルを文書管理装置１２へ送信する。

文書管理装置１２の帳票属性更新部９２は、破棄指示ファイルで指定された登録帳票データの種類に応じて、それらの登録帳票データの保存期間の起算日と保存期限を設定する。文書管理装置１２の破棄実行部９６は、帳票データ記憶部７８に記憶された複数の登録帳票データのうち保存期限が過ぎた登録帳票データを破棄対象として識別する。破棄実行部９６は、破棄対象の登録帳票データに対する破棄処理を、保存期限経過後の所定タイミングで実行する。

ここで、１人の個人に関する３種類の帳票であり、毎月の報酬に関する支払調書と、個人番号通知書と、口座開設申込書に対する破棄処理の例を説明する。支払調書の起算基準は登録日基準、破棄指示区分は自動、保存期間は５年とする。個人番号通知書の起算基準は破棄指示基準、破棄指示区分は手動、保存期間は０とする。口座開設申込書の起算基準は破棄指示基準、破棄指示区分は手動、保存期間は７年とする。個人番号通知書および口座開設申込書について破棄指示が出される契機は、業務イベント「口座解約」の発生とする。なお、いずれの帳票も保存期間開始区分は起算日とする。

毎月の支払調書は、企業端末１４から文書管理装置１２へ毎月登録されていき、業務イベント「口座解約」の発生有無にかかわらず、登録から５年が経過したものから順次自動的に破棄される。業務イベント「口座解約」が発生すると、企業担当者は、口座解約を行った個人の個人コードを用いて検索し、破棄すべき帳票（この例では個人番号通知書と口座開設申込書）を特定する。企業担当者は、個人番号通知書と口座開設申込書を破棄対象として指定する破棄指示ファイルを作成し、企業端末１４は、破棄指示ファイルを文書管理装置１２へ送信する。破棄指示ファイルでは、個人番号通知書に対する起算日が口座解約日に設定され、口座開設申込書に対する起算日も口座解約日に設定される。

文書管理装置１２は、破棄指示ファイルを受け付けると、個人番号通知書の保存期限を口座解約日（すなわち起算日＋０）に設定し、口座開設申込書の保存期限を口座解約日の７年後の日付に設定する。この結果、文書管理装置１２は、破棄指示の受け付け後、即時に個人番号通知書を破棄可能な状態になる。なお、実際の破棄処理は、破棄可能な状態になってから所定期間後に実行されるかもしれない。その一方、文書管理装置１２は、口座解約日から７年後に、口座開設申込書を破棄可能な状態になる。

本実施例の文書管理装置１２によると、文書の保存義務者により登録された文書を安全に保存し、また、文書の保存義務者により予め定められた条件に基づいて登録済みの文書を適切なタイミングで破棄することができる。これにより、利便性の高い文書データの管理を実現する。

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

第１変形例を説明する。上記実施例では、破棄指示ファイルにおいて、破棄対象を帳票の画像単位（登録単位とも言え、実施例ではＰＤＦ単位）で指定し、具体的には、破棄対象の登録帳票データを帳票画像ＩＤにより１つ１つ指定した。変形例として、破棄指示ファイルは、破棄対象帳票をＰＤＦ単位で指定することに代えて、個人コードと、文書の種類を示すＩＤである帳票コードを指定するものであってもよい。

文書管理装置１２の検索実行部９８は、帳票データ記憶部７８に記憶された登録帳票データの中から、破棄指示ファイルで指定された個人コードおよび帳票コードに対応付けられた１つ以上の登録帳票データ（「破棄対象帳票データ」とも呼ぶ。）を検索してもよい。ここで検索される破棄対象帳票データは、同じ帳票種類であるが、異なるタイミングで文書管理装置１２に登録された複数の帳票を含みうる。文書管理装置１２の帳票属性更新部９２および破棄実行部９６は、検索実行部９８により検索された１つ以上の破棄対象帳票データの破棄処理を一括して実行してもよい。具体的には、破棄指示が指定する起算日から、破棄指示が指定する帳票コードの帳票マスタが定める保存期間が経過する日付を各破棄対象帳票データの保存期限として設定し、保存期限が過ぎた後に破棄処理を実行してもよい。

第１変形例によると、個人および帳票種類を単位とした、１つ以上の登録帳票データの包括的な破棄を実現できる。企業担当者は、同じ個人コードかつ同じ帳票コードが付与された複数の帳票データ、例えば同一個人に対して定期的に繰り返し作成された帳票（法定調書等）を破棄すべき場合、１つの個人コードと１つの帳票コードを破棄指示ファイルで指定すればよい。例えば、毎月作成される支払調書の保存期間が７年とすると、８４個（７年分）の支払調書が保存中となる可能性があるが、破棄指示ファイルにおいて８４個の帳票データを１つ１つ指定する必要がなく、１つの帳票コードを指定すれば足りる。これにより、登録帳票データの破棄を指示する際の企業担当者の負担を低減することができる。

第１変形例に関連する第２変形例を説明する。１人の個人に関する登録帳票データにおけるＩＤの関係は、「個人コード：帳票コード＝１：Ｍ」（Ｍは１以上の整数）、「帳票コード：帳票画像ＩＤ＝１：Ｎ」（Ｎは１以上の整数）となる。第２変形例の破棄指示ファイルでは、登録帳票データの種類として個人コード単体を指定することにより、１つ以上の登録帳票データを包括的に指定する。

文書管理装置１２の検索実行部９８は、帳票データ記憶部７８に記憶された登録帳票データの中から、破棄指示ファイルで指定された個人コードに対応付けられた１つ以上の登録帳票データ（すなわち破棄対象帳票データ）を検索してもよい。ここで検索される破棄対象帳票データは、同一個人に関して作成された複数種類の帳票であり、異なるタイミングで文書管理装置１２に登録された複数の帳票を含みうる。文書管理装置１２の破棄実行部９６は、第１変形例と同様に、検索実行部９８により検索された１つ以上の破棄対象帳票データの破棄処理を一括して実行してもよい。

第２変形例によると、個人を単位として、登録帳票データの効率的な破棄を実現できる。企業担当者は、同じ個人コードが付与された複数種類の帳票データを破棄すべき場合、１つの個人コードを破棄指示ファイルで指定すればよい。これにより、登録帳票データの破棄を指示する際の企業担当者の負担を低減することができる。

第３変形例を説明する。第３変形例では、企業の基幹業務システムにおける業務イベントの発生に応じて登録帳票データを自動で破棄する。企業端末１４は、基幹業務システムと接続されてもよい。基幹業務システムは、例えば顧客管理システム、口座管理システム（金融機関の場合）であってもよい。

企業端末１４は、対応関係保持部、イベント検出部、破棄指示作成部をさらに備えてもよい。イベント定義保持部は、基幹業務システムで発生しうる業務イベント（例えばサービス解約、口座解約、口座名義変更等）であり、文書管理装置１２に登録済みの帳票データを破棄するべき業務イベントの定義情報を記憶する。例えば、業務イベントのＩＤと検出条件とを対応付けて記憶してもよい。

対応関係保持部は、基幹業務システムで発生しうる複数種類の業務イベント（例えばサービス解約、口座解約、口座名義変更等）と、各業務イベント発生時に破棄すべき帳票の識別子との対応関係を記憶する。例えば、業務イベントとして、個人コードと業務イベントＩＤとの組み合わせを記憶し、帳票の識別子として登録帳票データの帳票画像ＩＤを記憶してもよい。企業端末１４の帳票登録部４８は、帳票データの登録時に、登録する個人コードと、文書管理装置１２で採番された帳票画像ＩＤを取得し、さらに帳票の種類に予め対応付けられた業務イベントＩＤを取得し、これらの対応関係を対応関係保持部へ格納してもよい。

イベント検出部は、基幹業務システムにおいて所定の業務イベントが発生したことを検出する。例えば、基幹業務システムは、所定の業務イベント（口座解約等）が発生した場合に、その業務イベントＩＤと、当該イベントの主体を示す個人コードとを企業端末１４へ通知してもよい。イベント検出部は、この通知を受け付けることにより、業務イベントの発生を検出し、業務イベントＩＤと個人コードを取得してもよい。

破棄指示作成部は、発生した業務イベントに対応する登録帳票データの破棄を指示する破棄指示ファイルを自動で生成する。具体的には、対応関係保持部を検索して、イベント検出部により検出された業務イベントＩＤおよび個人コードに対応する帳票画像ＩＤを識別し、その帳票画像ＩＤを指定する破棄指示ファイルを生成する。破棄指示作成部は、破棄指示ファイルにおける起算日として、業務イベントの発生日を指定してもよく、基幹業務システムからの通知日を指定してもよく、これら発生日または通知日に基づいて所定の計算式にて算出される日付を指定してもよい。企業端末１４の破棄指示送信部６４は、破棄指示作成部により生成された破棄指示ファイルを文書管理装置１２へ送信する。

第３変形例によると、企業の基幹業務システムにおいて所定の業務イベントが発生した場合に、関連する登録帳票データの破棄処理を自動実行することができる。これにより、企業担当者による破棄対象帳票データの検索と、破棄指示ファイルの作成が不要になり、企業担当者の負担を低減することができる。特に、実施例に記載の第２破棄パターンまたは第３破棄パターンを適用すべき登録帳票データの管理において好適な態様である。

第３変形例の別の態様として、第１変形例と組み合わせてもよい。すなわち、対応関係保持部は、業務イベントＩＤおよび個人コードと、帳票コードとの対応関係を記憶してもよい。破棄指示作成部は、対応関係保持部を検索して、イベント検出部により検出された業務イベントＩＤおよび個人コードに対応する帳票コードを識別し、その帳票コードを指定する破棄指示ファイルを生成してもよい。第３変形例のさらに別の態様として、第２変形例と組み合わせてもよい。すなわち、破棄指示作成部は、イベント検出部により検出された個人コードを指定する破棄指示ファイルを生成してもよい。

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

なお、実施例および変形例に記載の技術は、以下の項目によって特定されてもよい。
［項目１］
外部装置から登録された複数種類の文書のデータを保存する文書データ記憶部と、予め定められた文書の種類ごとの保存期間であって、文書登録後の所定イベントの発生からの保存期間を記憶する文書属性記憶部と、所定イベントの発生を契機として外部装置から送信された指示であって、破棄対象文書と、当該文書の保存期間の起算日とを指定する破棄指示を取得する指示取得部と、破棄指示が指定する破棄対象文書のデータの破棄処理を、破棄指示が指定する起算日から、文書属性記憶部に記憶された破棄対象文書の種類に応じた保存期間が経過した後に実行する文書破棄部と、を備える文書管理装置。
［項目２］
文書データ記憶部は、文書の種類を示す文書種類ＩＤと、その種類に属する１つ以上の文書のデータとを対応付けて記憶し、破棄指示は、破棄対象文書に代えて文書種類ＩＤを指定するものであり、文書破棄部は、破棄指示が指定する文書種類ＩＤに対応付けられた１つ以上の文書のデータの破棄処理を、破棄指示が指定する起算日から当該文書種類ＩＤに応じた保存期間が経過した後に一括して実行してもよい。
［項目３］
文書の保存義務者の装置と、文書管理装置と、を備える文書管理システム。文書管理装置は、保存義務者の装置から登録された複数種類の文書のデータを保存する文書データ記憶部と、保存義務者により予め定められた文書の種類ごとの保存期間であって、文書登録後の所定イベントの発生からの保存期間を記憶する文書属性記憶部と、所定イベントの発生を契機として保存義務者の装置から送信された破棄指示であって、破棄対象文書と、当該文書の保存期間の起算日とを指定する破棄指示を取得する指示取得部と、破棄指示が指定する破棄対象文書のデータの破棄処理を、破棄指示が指定する起算日から、文書属性記憶部に記憶された破棄対象文書の種類に応じた保存期間が経過した後に実行する文書破棄部と、を含む。保存義務者の装置は、保存義務者の基幹業務システムにおいて文書管理装置に登録済みの文書を破棄するべき所定の業務イベントが発生したこと検出する検出部と、検出部により所定の業務イベントの発生が検出された場合に、登録済みの文書を破棄対象文書として指定する破棄指示を文書管理装置へ送信する送信部と、を含む。
［項目４］
コンピュータが実行する文書管理方法であって、予め定められた文書の種類ごとの保存期間であって、文書登録後の所定イベントの発生からの保存期間を記憶部に記憶させるステップと、外部装置から登録された複数種類の文書のデータを記憶部に記憶させるステップと、所定イベントの発生を契機として外部装置から送信された破棄指示であって、破棄対象文書と、当該文書の保存期間の起算日とを指定する破棄指示を取得するステップと、破棄指示が指定する破棄対象文書のデータの破棄処理を、破棄指示が指定する起算日から、破棄対象文書の種類に応じた保存期間が経過した後に実行するステップと、を備える文書管理方法。

１０ 文書管理システム、 １２ 文書管理装置、 １４ 企業端末、 １６ スキャナ、 ７６ 帳票マスタ記憶部、 ７８ 帳票データ記憶部、 ９０ 帳票保存部、 ９２ 帳票属性更新部、 ９４ 破棄指示取得部、 ９６ 破棄実行部。

Claims (2)

1. 外部装置から登録された複数種類の文書のデータを記憶する文書データ記憶部と、
   予め定められた文書の種類ごとの保存期間であって、文書登録後の所定イベントの発生からの保存期間を記憶する文書属性記憶部と、
   前記所定イベントの発生を契機として外部装置から送信された破棄指示であって、破棄対象文書と、当該文書の保存期間の起算日とを指定する破棄指示を取得する指示取得部と、
   前記破棄指示が指定する破棄対象文書のデータの破棄処理を、前記破棄指示が指定する起算日から、前記文書属性記憶部に記憶された破棄対象文書の種類に応じた保存期間が経過した後に実行する文書破棄部と、
   を備え、
   前記文書データ記憶部に記憶される文書のデータは、当該文書の画像と、当該文書に関する属性情報とを含み、
   前記文書破棄部は、前記破棄対象文書のデータの破棄処理において、前記破棄対象文書の画像を削除する一方、前記破棄対象文書に関する属性情報を削除せずに残すことを特徴とする文書管理装置。
2. コンピュータが実行する文書管理方法であって、
   予め定められた文書の種類ごとの保存期間であって、文書登録後の所定イベントの発生からの保存期間を記憶部に記憶させるステップと、
   外部装置から登録された複数種類の文書のデータを記憶部に記憶させるステップと、
   前記所定イベントの発生を契機として外部装置から送信された破棄指示であって、破棄対象文書と、当該文書の保存期間の起算日とを指定する破棄指示を取得するステップと、
   前記破棄指示が指定する破棄対象文書のデータの破棄処理を、前記破棄指示が指定する起算日から、破棄対象文書の種類に応じた保存期間が経過した後に実行する文書破棄ステップと、
   を備え、
   前記記憶部に記憶される文書のデータは、当該文書の画像と、当該文書に関する属性情報とを含み、
   前記文書破棄ステップは、前記破棄対象文書のデータの破棄処理において、前記破棄対象文書の画像を削除する一方、前記破棄対象文書に関する属性情報を削除せずに残すことを特徴とする文書管理方法。

Images