(57)【要約】【課題】通帳アプリケーションを利用して表示される取引明細における齟齬を改善することが可能な情報処理装置およびプログラムを提供する。【解決手段】上位装置から少なくとも取引金額と現在高を含む口座の取引明細を取得する取得部と、前記取得部により前回取得した第１の取引明細と、新たに取得した第２の取引明細とが連続するか否かを判断する判断部と、前記判断部により不連続であると判断された場合、前記第１の取引明細と前記第２の取引明細とを区別して表示するよう制御する表示制御部と、を備える、情報処理装置。【選択図】図２
2015162046.tif 000002
【特許請求の範囲】
【請求項１】
上位装置から少なくとも取引金額と現在高を含む口座の取引明細を取得する取得部と、
前記取得部により前回取得した第１の取引明細と、新たに取得した第２の取引明細とが連続するか否かを判断する判断部と、
前記判断部により不連続であると判断された場合、前記第１の取引明細と前記第２の取引明細とを区別して表示するよう制御する表示制御部と、
を備える、情報処理装置。
【請求項２】
上位装置から少なくとも取引金額と現在高を含む口座の取引明細を取得する取得部と、
前記取得部により前回取得した第１の取引明細と、新たに取得した第２の取引明細とが連続するか否かを判断する判断部と、
前記判断部により不連続であると判断された場合、前記第１の取引明細と第２の取引明細とを連続させるための補間取引明細を生成する生成部と、
前記生成した補間取引明細が前記第１の取引明細および前記第２の取引明細の間に表示するよう制御する表示制御部と、
を備える、情報処理装置。
【請求項３】
前記判断部は、前記第１の取引明細の残高と前記第２の取引明細の残高との整合性に基づいて、前記第１の取引明細と前記第２の取引明細とが連続するか否かを判断する、請求項２に記載の情報処理装置。
【請求項４】
前記表示制御部は、前記判断部により不連続であると判断された場合、前記第１の取引明細と前記第２の取引明細とを区別して表示するよう制御する、請求項２または３に記載の情報表示装置。
【請求項５】
前記表示制御部は、前記第１の取引明細と前記第２の取引明細とを異なる表示態様で表示することで区別する、請求項４に記載の情報処理装置。
【請求項６】
前記表示制御部は、前記第１の取引明細と前記第２の取引明細との間に空白行を入れることで区別する、請求項４に記載の情報処理装置。
【請求項７】
前記生成部は、前記第１の取引明細における直近残高と、前記第２の取引明細における最古の取引金額、取引内容、および残高に基づいて、前記補間取引明細の取引金額および残高を算出する、請求項２〜６のいずれか１項に記載の情報処理装置。
【請求項８】
前記表示制御部は、表示した前記補間取引明細に対する手動入力の指示が認識された場合、少なくとも取引金額を含む取引明細情報が入力可能な取引手入力画面を表示し、
前記生成部は、前記取引手入力画面から入力された取引明細情報に基づいて手動入力取引明細を生成し、
前記判断部は、前記第１の取引明細と、前記手動入力取引明細と、前記第２の取引明細とが連続するか否かを判断する、請求項２〜７のいずれか１項に記載の情報処理装置。
【請求項９】
前記表示制御部は、前記判断の結果、連続する場合、前記補間取引明細を削除して前記手動入力取引明細を表示する、請求項８に記載の情報処理装置。
【請求項１０】
前記生成部は、前記判断の結果、不連続の場合、前記手動入力取引明細と前記第２の取引明細とが連続するよう前記補間取引明細を再生成し、
前記表示制御部は、前記手動入力取引明細と前記再生成した補間取引明細とを、前記第１の取引明細と前記第２の取引明細との間に表示する、請求項８に記載の情報処理装置。
【請求項１１】
前記生成部は、表示した前記補間取引明細に対する自動補足の指示が認識された場合、前記第１の取引明細および前記第２の取引明細から定期的な取引明細を抽出して定期補足取引明細を生成し、
前記判断部は、前記第１の取引明細と、前記定期補足取引明細と、前記第２の取引明細とが連続するか否かを判断する、請求項２〜１０のいずれか１項に記載の情報処理装置。
【請求項１２】
前記生成部は、前記第１の取引明細および前記第２の取引明細に含まれる各取引日および取引内容に基づいて前記定期的な取引明細を抽出し、抽出した各定期な取引明細の取引金額に基づいて、前記定期補足取引明細の取引金額を算出する、請求項１１に記載の情報処理装置。
【請求項１３】
前記表示制御部は、前記判断の結果、連続する場合、前記補間取引明細を削除して前記定期補足取引明細を表示する、請求項１１または１２に記載の情報処理装置。
【請求項１４】
前記生成部は、前記判断の結果、不連続の場合、前記定期補足取引明細と前記第２の取引明細とが連続するよう前記補間取引明細を再生成し、
前記表示制御部は、前記定期補足取引明細と前記再生成した補間取引明細とを、前記第１の取引明細と前記第２の取引明細との間に表示する、請求項１１または１２に記載の情報処理装置。
【請求項１５】
コンピュータを、
上位装置から少なくとも取引金額と現在高を含む口座の取引明細を取得する取得部と、
前記取得部により前回取得した第１の取引明細と、新たに取得した第２の取引明細とが連続するか否かを判断する判断部と、
前記判断部により不連続であると判断された場合、前記第１の取引明細と前記第２の取引明細とを区別して表示するよう制御する表示制御部と、
として機能させるためのプログラム。
【請求項１６】
コンピュータを、
上位装置から少なくとも取引金額と現在高を含む口座の取引明細を取得する取得部と、
前記取得部により前回取得した第１の取引明細と、新たに取得した第２の取引明細とが連続するか否かを判断する判断部と、
前記判断部により不連続であると判断された場合、前記第１の取引明細と第２の取引明細とを連続させるための補間取引明細を生成する生成部と、
前記生成した補間取引明細が前記第１の取引明細および前記第２の取引明細の間に表示するよう制御する表示制御部と、
として機能させるためのプログラム。
【請求項１７】
前記判断部は、前記第１の取引明細の残高と前記第２の取引明細の残高との整合性に基づいて、前記第１の取引明細と前記第２の取引明細とが連続するか否かを判断する、請求項１６に記載のプログラム。
【請求項１８】
前記表示制御部は、前記判断部により不連続であると判断された場合、前記第１の取引明細と前記第２の取引明細とを区別して表示するよう制御する、請求項１６または１７に記載の情報表示装置。
【請求項１９】
前記表示制御部は、前記第１の取引明細と前記第２の取引明細とを異なる表示態様で表示することで区別する、請求項１８に記載のプログラム。
【請求項２０】
前記表示制御部は、前記第１の取引明細と前記第２の取引明細との間に空白行を入れることで区別する、請求項１８に記載のプログラム。
【請求項２１】
前記生成部は、前記第１の取引明細における直近残高と、前記第２の取引明細における最古の取引金額、取引内容、および残高に基づいて、前記補間取引明細の取引金額および残高を算出する、請求項１６〜２０のいずれか１項に記載のプログラム。
【請求項２２】
前記表示制御部は、表示した前記補間取引明細に対する手動入力の指示が認識された場合、少なくとも取引金額を含む取引明細情報が入力可能な取引手入力画面を表示し、
前記生成部は、前記取引手入力画面から入力された取引明細情報に基づいて手動入力取引明細を生成し、
前記判断部は、前記第１の取引明細と、前記手動入力取引明細と、前記第２の取引明細とが連続するか否かを判断する、請求項１６〜２１のいずれか１項に記載のプログラム。
【請求項２３】
前記表示制御部は、前記判断の結果、連続する場合、前記補間取引明細を削除して前記手動入力取引明細を表示する、請求項２２に記載のプログラム。
【請求項２４】
前記生成部は、前記判断の結果、不連続の場合、前記手動入力取引明細と前記第２の取引明細とが連続するよう前記補間取引明細を再生成し、
前記表示制御部は、前記手動入力取引明細と前記再生成した補間取引明細とを、前記第１の取引明細と前記第２の取引明細との間に表示する、請求項２２に記載のプログラム。
【請求項２５】
前記生成部は、表示した前記補間取引明細に対する自動補足の指示が認識された場合、前記第１の取引明細および前記第２の取引明細から定期的な取引明細を抽出して定期補足取引明細を生成し、
前記判断部は、前記第１の取引明細と、前記定期補足取引明細と、前記第２の取引明細とが連続するか否かを判断する、請求項１６〜２４のいずれか１項に記載のプログラム。
【請求項２６】
前記生成部は、前記第１の取引明細および前記第２の取引明細に含まれる各取引日および取引内容に基づいて前記定期的な取引明細を抽出し、抽出した各定期な取引明細の取引金額に基づいて、前記定期補足取引明細の取引金額を算出する、請求項２５に記載のプログラム。
【請求項２７】
前記表示制御部は、前記判断の結果、連続する場合、前記補間取引明細を削除して前記定期補足取引明細を表示する、請求項２５または２６に記載のプログラム。
【請求項２８】
前記生成部は、前記判断の結果、不連続の場合、前記定期補足取引明細と前記第２の取引明細とが連続するよう前記補間取引明細を再生成し、
前記表示制御部は、前記定期補足取引明細と前記再生成した補間取引明細とを、前記第１の取引明細と前記第２の取引明細との間に表示する、請求項２５または２６に記載のプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、情報処理装置およびプログラムに関する。
【背景技術】
【０００２】
従来から、銀行などの金融機関では、口座の開設時において紙の通帳を発行し、利用者に提供している。このような紙の通帳の発行の他、近年では、紙の通帳に記載される取引明細の内容を、例えばＰＣ（Personal Computer）、タブレット端末、スマートフォン等の情報処理装置の表示画面に提示し、利用者がいつでもどこでも確認できるようにする電子通帳システムの技術が提案されている。
【０００３】
ここで、一般的に、電子通帳システム（通帳アプリケーション）において、利用者の情報処理装置は、通帳の明細データをインターネットバンキングからダウンロードして情報処理装置内に保存し、表示部に表示する。しかし、インターネットバンキングに格納される明細データは、通常１〜２ヵ月程度で削除されるので、利用者は、定期的にインターネットバンキングにアクセスして明細データの抜けを防止する必要があった。
【０００４】
また、通帳の記帳技術に関し、例えば下記特許文献１では、顧客の指定により未記帳取引を合算記帳する技術が提案されている。また、下記特許文献２では、顧客の指示により、通帳記帳内容を合算して印字する技術が提案されている。
【０００５】
また、電子通帳システムに関し、例えば下記引用文献３では、画面上に通帳の如く取引明細を表示する技術が提案されている。また、下位特許文献４では、預金残高と入出金明細をダウンロードして繰越金額を生成する技術が提案されている。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開２００１−１４３１２６号公報
【特許文献２】特開平８−１２９６６５号公報
【特許文献３】特開平６−１３１３８２号公報
【特許文献４】特開平１１−１３４４１８号公報
【発明の概要】
【発明が解決しようとする課題】
【０００７】
しかしながら、上述したインターネットバンキングから明細データをダウンロードする方式では、ユーザがインターネットバンキングにアクセスして明細データをダウンロードする操作を一定期間実施しないと、明細データに抜けが生じてしまい、明細の内容に齟齬が生じてしまうという問題があった。
【０００８】
たとえば、１ヵ月しか明細データが保管されないインターネットバンキングの場合、１月１日に明細データをダウンロードしたのち、３月１日までダウンロード処理を実施しないと、３月１日時点では１月３１日以前の明細データが削除される。したがって、３月１日以降にダウンロードした明細データを表示した場合、１月２日〜１月３１日までの明細データが欠落するため、１月１日までの明細データと不連続になり、取引残高に齟齬が生じる。
【０００９】
このように明細データが不連続になる場合の表示例（取引明細画像５２）を図１２に示す。図１２に示す取引明細画像５２は、利用者の情報処理装置の表示部５０に表示され、１行目の取引明細行５２１では、取引年月日が「２５年１２月２８日」であって、取引内容が「入金（ＡＴＭ）」であって、取引金額が「２０，０００」であって、残高が「１００，０００」であることが示される。続く２行目の取引明細行５２２では、取引年月日が「２６年２月１５日」であって、取引内容が「入金（ＡＴＭ）」であって、取引金額が「３０，０００」であって、残高が「５０，０００」であることが示される。
【００１０】
この場合、取引明細行５２１と取引明細行５２２の取引情報を参照すると、取引明細行５２２の残高は「１３０，０００」になるはずだが、１月２日〜１月３１日の間に発生した取引（例えば出金「８０，０００」など）の明細データが削除されてしまっているので、取引内容と残高が連続しないという状態が生じる。
【００１１】
このような明細取引の齟齬の発生を防ぐために、通帳アプリケーションがバックグラウンドにおいて任意のタイミングで定期的にインターネットバンキングにアクセスして、明細データをダウンロードするという方式も考え得る。しかしながら、当該方式を利用する場合は通帳アプリケーション内にインターネットバンキングのＩＤと暗証番号情報を保存する必要があり、情報漏えいのリスクがある。
【００１２】
また、通帳アプリケーションには、通常、「任意の取引明細行を削除」する機能が備わっているが、利用者が当該機能を実行すると、削除した取引明細行の前後の取引明細行において取引内容と残高に齟齬が発生するという問題があった。
【００１３】
そこで、本発明は、上記問題に鑑みてなされたものであり、本発明の目的とするところは、通帳アプリケーションを利用して表示される取引明細における齟齬を改善することが可能な、新規かつ改良された情報処理装置およびプログラムを提供することにある。
【課題を解決するための手段】
【００１４】
上記課題を解決するために、本発明のある観点によれば、上位装置から少なくとも取引金額と現在高を含む口座の取引明細を取得する取得部と、前記取得部により前回取得した第１の取引明細と、新たに取得した第２の取引明細とが連続するか否かを判断する判断部と、前記判断部により不連続であると判断された場合、前記第１の取引明細と前記第２の取引明細とを区別して表示するよう制御する表示制御部と、を備える、情報処理装置が提供される。
【００１５】
上記課題を解決するために、本発明のある観点によれば、上位装置から少なくとも取引金額と現在高を含む口座の取引明細を取得する取得部と、前記取得部により前回取得した第１の取引明細と、新たに取得した第２の取引明細とが連続するか否かを判断する判断部と、前記判断部により不連続であると判断された場合、前記第１の取引明細と第２の取引明細とを連続させるための補間取引明細を生成する生成部と、前記生成した補間取引明細が前記第１の取引明細および前記第２の取引明細の間に表示するよう制御する表示制御部と、を備える、情報処理装置が提供される。
【００１６】
また、前記判断部は、前記第１の取引明細の残高と前記第２の取引明細の残高との整合性に基づいて、前記第１の取引明細と前記第２の取引明細とが連続するか否かを判断してもよい。
【００１７】
また、前記表示制御部は、前記判断部により不連続であると判断された場合、前記第１の取引明細と前記第２の取引明細とを区別して表示するよう制御してもよい。
【００１８】
また、前記表示制御部は、前記第１の取引明細と前記第２の取引明細とを異なる表示態様で表示することで区別してもよい。
【００１９】
また、前記表示制御部は、前記第１の取引明細と前記第２の取引明細との間に空白行を入れることで区別してもよい。
【００２０】
また、前記生成部は、前記第１の取引明細における直近残高と、前記第２の取引明細における最古の取引金額、取引内容、および残高に基づいて、前記補間取引明細の取引金額および残高を算出してもよい。
【００２１】
また、前記表示制御部は、表示した前記補間取引明細に対する手動入力の指示が認識された場合、少なくとも取引金額を含む取引明細情報が入力可能な取引手入力画面を表示し、前記生成部は、前記取引手入力画面から入力された取引明細情報に基づいて手動入力取引明細を生成し、前記判断部は、前記第１の取引明細と、前記手動入力取引明細と、前記第２の取引明細とが連続するか否かを判断してもよい。
【００２２】
また、前記表示制御部は、前記判断の結果、連続する場合、前記補間取引明細を削除して前記手動入力取引明細を表示してもよい。
【００２３】
また、前記生成部は、前記判断の結果、不連続の場合、前記手動入力取引明細と前記第２の取引明細とが連続するよう前記補間取引明細を再生成し、前記表示制御部は、前記手動入力取引明細と前記再生成した補間取引明細とを、前記第１の取引明細と前記第２の取引明細との間に表示してもよい。
【００２４】
また、前記生成部は、表示した前記補間取引明細に対する自動補足の指示が認識された場合、前記第１の取引明細および前記第２の取引明細から定期的な取引明細を抽出して定期補足取引明細を生成し、
前記判断部は、前記第１の取引明細と、前記定期補足取引明細と、前記第２の取引明細とが連続するか否かを判断してもよい。
【００２５】
また、前記生成部は、前記第１の取引明細および前記第２の取引明細に含まれる各取引日および取引内容に基づいて前記定期的な取引明細を抽出し、抽出した各定期な取引明細の取引金額に基づいて、前記定期補足取引明細の取引金額を算出してもよい。
【００２６】
また、前記表示制御部は、前記判断の結果、連続する場合、前記補間取引明細を削除して前記定期補足取引明細を表示してもよい。
【００２７】
また、前記生成部は、前記判断の結果、不連続の場合、前記定期補足取引明細と前記第２の取引明細とが連続するよう前記補間取引明細を再生成し、前記表示制御部は、前記定期補足取引明細と前記再生成した補間取引明細とを、前記第１の取引明細と前記第２の取引明細との間に表示してもよい。
【００２８】
また、上記課題を解決するために、本発明の別の観点によれば、コンピュータを、上位装置から少なくとも取引金額と現在高を含む口座の取引明細を取得する取得部と、前記取得部により前回取得した第１の取引明細と、新たに取得した第２の取引明細とが連続するか否かを判断する判断部と、前記判断部により不連続であると判断された場合、前記第１の取引明細と前記第２の取引明細とを区別して表示するよう制御する表示制御部と、として機能させるためのプログラムが提供される。
【００２９】
また、上記課題を解決するために、本発明の別の観点によれば、コンピュータを、上位装置から少なくとも取引金額と現在高を含む口座の取引明細を取得する取得部と、前記取得部により前回取得した第１の取引明細と、新たに取得した第２の取引明細とが連続するか否かを判断する判断部と、前記判断部により不連続であると判断された場合、前記第１の取引明細と第２の取引明細とを連続させるための補間取引明細を生成する生成部と、前記生成した補間取引明細が前記第１の取引明細および前記第２の取引明細の間に表示するよう制御する表示制御部と、として機能させるためのプログラムが提供される。
【発明の効果】
【００３０】
以上説明したように本発明によれば、通帳アプリケーションを利用して表示される取引明細における齟齬を改善することができる。
【図面の簡単な説明】
【００３１】
【図１】本実施形態による電子通帳システムの基本構成について説明するための図である。
【図２】本実施形態による情報処理装置１０の構成を示した機能ブロック図である。
【図３】本実施形態による表示制御処理を示すフローチャートである。
【図４】本実施形態による表示制御処理を示すフローチャートである。
【図５】メニュー画像の表示例を示した説明図である。
【図６】補間取引明細行の取引情報の設定例１、２を説明する図である。
【図７】補間取引明細行の取引情報の設定例３、４を説明する図である。
【図８】取引明細画像の表示例を示した説明図である。
【図９】本実施形態の変形例１による取引明細行の不連続の明示について説明する図である。
【図１０】本実施形態の変形例２による取引明細の手動入力例について説明する図である。
【図１１】本実施形態の変形例３による定期取引明細の生成例について説明する図である。
【図１２】従来の取引明細画像における明細データの不連続について説明する図である。
【発明を実施するための形態】
【００３２】
以下に添付図面を参照しながら、本発明の好適な実施の形態について詳細に説明する。なお、本明細書及び図面において、実質的に同一の機能構成を有する構成要素については、同一の符号を付することにより重複説明を省略する。
【００３３】
また、本明細書及び図面において、実質的に同一の機能構成を有する複数の構成要素を、同一の符号の後に異なるアルファベットを付して区別する場合もある。
【００３４】
また、以下に示す順序に従って当該「発明を実施するための最良の形態」を説明する。
１．背景
２．電子通帳システムの基本構成
３．実施形態の詳細な説明
３−１．構成
３−２．動作
４．変形例
５．まとめ
【００３５】
＜＜１．背景＞＞
従来、銀行などの金融機関では、口座の開設時において紙の通帳を発行し、利用者に提供している。利用者は、例えば金融機関に設置されたＡＴＭ（Automated Teller Machine）において記帳を行うことにより、取引の明細を通帳に印字させることができる。
【００３６】
また、近年、紙の通帳に記載される取引明細の内容を、ＰＣやスマートフォン等の情報処理装置の表示画面に提示して、利用者がいつでもどこでも確認できるようにすることができる。
【００３７】
しかしながら、インターネットバンキングから明細データをダウンロードする場合、ユーザがインターネットバンキングにアクセスして明細データをダウンロードする操作を一定期間実施しないと、明細データに抜けが生じてしまい、明細の内容に齟齬が生じてしまうという問題があった。また、通帳アプリケーションにおいて「任意の取引明細行を削除」する機能を実行すると、削除した取引明細行の前後の取引明細行において取引内容と残高に齟齬が発生するという問題があった。
【００３８】
そこで、上記事情を一着眼点にして本発明の実施形態による情報処理装置１０を創作するに至った。本実施形態による情報処理装置１０は、通帳アプリケーションを利用して表示される取引明細における齟齬を改善することが可能である。
【００３９】
＜＜２．電子通帳システムの基本構成＞＞
本発明は、一例として「３．実施形態の詳細な説明」において詳細に説明するように、多様な形態で実施され得る。以下では、まず、本実施形態による電子通帳システムの基本構成について図１を参照して説明する。
【００４０】
図１に示したように、本実施形態による電子通帳システムは、情報処理装置１０、通信網１２、専用網１４、およびＩＢサーバ２０を含む。
【００４１】
＜２−１．情報処理装置１０＞
情報処理装置１０は、例えば無線通信により、通信網１２に接続可能な装置である。この情報処理装置１０は、例えば、スマートフォンなどの携帯電話、タブレット端末、ＰＤＡ（Personal Digital Assistant）、ＰＣなどであってもよい。
【００４２】
また、情報処理装置１０のハードウェア構成としては、ＣＰＵ（Central Processing Unit）、ＲＯＭ（Read Only
Memory）、およびＲＡＭ（Random Access Memory）が内部バスを介して入出力インターフェースに接続され、入出力インターフェースには入力装置、出力装置、ＨＤＤ（Hard Disk Drive）、およびネットワークインターフェースが接続される構成を有する。
【００４３】
＜２−２．通信網１２＞
通信網１２は、通信網１２に接続されている装置から送信される情報の無線、または有線の伝送路である。例えば、通信網１２は、インターネット、電話回線網、衛星通信網などの公衆回線網や、Ｅｔｈｅｒｎｅｔ（登録商標）を含む各種のＬＡＮ（Local Area Network）、ＷＡＮ（Wide Area Network）などを含んでもよい。また、通信網１２は、ＩＰ−ＶＰＮ（Internet Protocol-Virtual Private Network）などの専用回線網を含んでもよい。
【００４４】
＜２−３．専用網１４＞
専用網１４は、金融機関のネットワークであり、例えばＩＰ−ＶＰＮにより構成される。
【００４５】
＜２−４．ＩＢサーバ２０＞
ＩＢサーバ２０は、インターネットバンキングシステム（銀行システム２）を管理する装置である。
【００４６】
また、ＩＢサーバ２０は、口座番号ごとに取引内容の明細データが記憶されている明細ＤＢ２１に対するデータの登録や抽出など、明細データを管理する。また、ＩＢサーバ２０は、利用者からのアクセスに応じて明細データを明細ＤＢ２１から抽出して送信する際、所定の認証方式により、口座番号ごとにログイン用パスワード等が記憶されている認証ＤＢ２２を用いて認証を行う。
【００４７】
明細ＤＢ２１は、例えば利用者の口座番号と、口座番号に対応づけて登録された取引内容の明細データ（例えば取引日時、口座番号、取引種別、取引金額など）が記録されたデータベースである。
【００４８】
認証ＤＢ２２は、例えば利用者の口座番号と、口座番号に対応づけて登録されたログイン用パスワード等が記録されたデータベースである。
【００４９】
なお、ＩＢサーバ２０、明細ＤＢ２１、および認証ＤＢ２２は、別々の装置として構成されてもよいし、ＩＢサーバ２０が明細ＤＢ２１および認証ＤＢ２２を内部に含んでもよい。
【００５０】
さらに、ＩＢサーバ２０は、預金管理や、口座管理等を行うホストコンピュータとしても機能し得る。例えば、ＩＢサーバ２０は、インターネットバンキングシステムにおいて利用者により指示された入金や振込などの金銭取引（勘定の取引処理）を実行する。また、ＩＢサーバ２０は、口座番号、暗証番号、氏名、住所、年齢、生年月日、電話番号、職業、家族構成、年収、預金残高などの顧客情報（口座の元帳）を管理する。
【００５１】
＜２−５．中継サーバ３０＞
中継サーバ３０は、通信網１２と専用網１４とを接続する装置である。例えば、中継サーバ３０は、通信網１２から専用網１４へ送信されるデータに関して、金融機関のシステム（銀行システム２）において処理可能な形式にデータを加工する。また、中継サーバ３０は、専用網１４から通信網１２へ送信されるデータに関して、情報処理装置１０において処理可能な形式にデータを加工する。
【００５２】
＜＜３．実施形態の詳細な説明＞＞
＜３−１．構成＞
以上、本実施形態による電子通帳システムの基本構成について説明した。続いて、本実施形態による構成について詳細に説明する。
【００５３】
図２は、本実施形態による情報処理装置１０の構成を示した機能ブロック図である。図２に示したように、情報処理装置１０は、制御部１００、通信部１２０、操作表示部１２２、および記憶部１２４を有する。
【００５４】
［３−１−１．制御部１００］
制御部１００は、情報処理装置１０に内蔵されるＣＰＵ、ＲＡＭなどのハードウェアを用いて、情報処理装置１０の動作を全般的に制御する。また、図２に示したように、制御部１００は、アプリ認証部１０２、明細取得制御部１０４、操作認識部１０６、表示制御部１０８、連続性判断部１１０、および取引明細生成部１１２を有する。
【００５５】
［３−１−２．アプリ認証部１０２］
アプリ認証部１０２は、制御部１００による通帳アプリケーション起動時に、所定の認証方式で、利用者により入力される認証情報を認証する。この際、アプリ認証部１０２は、記憶部１２４に記憶されている通帳アプリ認証ＤＢ１２５から抽出した認証データを参照して、ユーザのログインの正当性を判断する。アプリ認証部１０２によりユーザのログインの正当性が確認されると、制御部１００は通帳アプリケーションを起動する。通帳アプリケーションの起動により、金融機関の明細データに基づく通帳表示等が可能となる。
【００５６】
［３−１−３．明細取得制御部１０４］
明細取得制御部１０４は、明細データを上位装置であるＩＢサーバ２０から取得する機能を有する。明細取得制御部１０４は、通帳アプリケーションが起動した場合に、当該通帳アプリケーションの一機能として用いられる。具体的には、明細取得制御部１０４は、通信部１２０から、通信網１２、中継サーバ３０、および専用網１４を介して銀行システム２にアクセスし、明細ＤＢ２１に格納されている明細データを、ＩＢサーバ２０からダウンロードする。ダウンロードされた明細データは、銀行明細ＤＢ１２７に格納される。
【００５７】
ここで、銀行明細ＤＢ１２７には、明細データとして、例えば取引明細番号、取引日時、取引種別、取引内容、取引金額、および口座残高が対応づけて記憶される。
【００５８】
また、明細ダウンロード時には、上述したアプリ認証で用いられた認証とは別に、各銀行システム（インターネットバンキング）において所定の認証方式により再度認証が行われる。この際用いられる認証データは、情報処理装置１０の銀行認証ＤＢ１２６に格納されている。
【００５９】
［３−１−４．操作認識部１０６］
操作認識部１０６は、操作表示部１２２に表示された表示画面における利用者のタッチ操作を認識する。例えば、図５に示すメニュー画像４０が表示されている表示画面において、利用者により明細データＤＬボタン４０２がタップ操作された場合には、操作認識部１０６は、当該タップ操作を、明細データのダウンロードを指示するための利用者の操作として認識する。
【００６０】
［３−１−５．表示制御部１０８］
表示制御部１０８は、利用者の口座の通帳画像を後述する操作表示部１２２に表示させることが可能である。なお、口座の通帳画像は、表紙画像、および取引明細画像の順に配列された画像である。また、口座の通帳画像は、紙の通帳に記載される内容とほぼ同じ内容を表示する画像である。
【００６１】
例えば、表示制御部１０８は、第１の機能として、予め利用者により情報処理装置１０にダウンロードされている通帳アプリケーションの起動時において、通帳アプリケーションの指示に従って、メニュー画像、または利用者の口座の通帳画像を操作表示部１２２に表示させる。
【００６２】
表紙画像は、例えば口座情報種別ＤＢ１２９に記憶されている口座情報種別データを参照して生成され得る。すなわち、表示制御部１０８は、口座情報種別データに含まれる銀行名、種別、店番、口座番号を、表紙画像と共に表示する。また、取引明細画像は、銀行明細ＤＢ１２７に記憶されている銀行明細データに基づいて生成される。
【００６３】
ここで、口座情報種別ＤＢ１２９には、口座情報種別データとして、例えば通帳番号、銀行名、口座種別、店番、口座番号、開始明細番号、終了明細番号、および通帳表紙画像が対応づけて記憶される。
【００６４】
また、表示制御部１０８は、第２の機能として、後述する取引明細生成部１１２により生成した補間取引明細を、前回ダウンロードした第１の取引明細群と、今回ダウンロードした第２の取引明細群との間に表示させる。
【００６５】
［３−１−６．連続性判断部１１０］
連続性判断部１１０は、前回ダウンロードした第１の取引明細群と、今回新たにダウンロードした第２の取引明細群とが連続するか否かを判断する。具体的には、連続性判断部１１０は、前回ダウンロードした第１の取引明細群の直近（最終）取引明細の残高と、新たにダウンロードした第２の取引明細群の最古の取引明細の残高との整合性に基づいて、これらが連続するか否かを判断する。
【００６６】
［３−１−７．取引明細生成部１１２］
取引明細生成部１１２は、上述した連続性判断部１１０により不連続であると判断された場合、上記第１の取引明細と第２の取引明細とを連続させるための補間取引明細を生成する。具体的には、取引明細生成部１１２は、第１の取引明細における直近残高と、第２の取引明細における最古の取引金額、取引内容、および残高に基づいて、補間取引明細の取引金額および残高を算出し、補間取引明細を生成する。
【００６７】
［３−１−８．通信部１２０］
通信部１２０は、本発明における取得部の一例である。通信部１２０は、通信網１２を介して通信網１２に接続された各種の装置との間で情報を送受信する。例えば、通信部１２０は、制御部１００の指示に従って、利用者の口座に対応づけて登録されている明細データの取得要求（銀行認証データを含んでもよい）をＩＢサーバ２０へ送信する。また、通信部１２０は、明細データをＩＢサーバ２０から受信する。
【００６８】
［３−１−９．操作表示部１２２］
操作表示部１２２は、本発明における表示部の一例である。表示部は、例えば、液晶ディスプレイ（ＬＣＤ:Liquid Crystal Display）装置や、ＯＬＥＤ（Organic
Light Emitting Diode）装置などにより実現される。操作表示部１２２は、表示制御部１０８の制御に従って、例えば口座の通帳画像など、各種の表示画像を表示画面に表示する。
【００６９】
また、操作表示部１２２は、利用者による情報処理装置１０に対する各種の入力操作を受け付ける。具体的には、表示部に積層されたタッチパネルにより受け付ける。操作表示部１２２は、例えばメニュー画面に表示されたメニューボタンに対する選択操作（タップ操作）を受け付ける。
【００７０】
［３−１−１０．記憶部１２４］
記憶部１２４は、各種ソフトウェアや、様々なデータなどを記憶する。例えば、記憶部１２４は、通帳アプリ認証ＤＢ１２５、銀行認証ＤＢ１２６、銀行明細ＤＢ１２７、および口座情報種別ＤＢ１２９を記憶する。
【００７１】
以上、本実施形態による情報処理装置１０の構成について説明した。なお情報処理装置１０の構成は、上述した構成に限定されない。例えば、銀行認証ＤＢ１２６は、情報処理装置１０に含まれる代わりに、情報処理装置１０が通信可能な他の装置に備えられてもよい。
【００７２】
＜３−２．動作＞
続いて、本実施形態による動作について図３、図４を参照して説明する。図３、図４は、本実施形態による表示制御処理を示すフローチャートである。
【００７３】
図３に示すように、まず、ステップＳ１０３において、情報処理装置１０の制御部１００は、操作表示部１２２に対する利用者の操作により、通帳アプリケーションを起動する。この際、表示制御部１０８は、通帳アプリ起動用の認証情報を入力するための認証情報入力画像を操作表示部１２２に表示させ、利用者に認証情報を入力させ、アプリ認証部１０２により通帳アプリ起動用の認証が行われる。利用者の正当性が確認されると、制御部１００は通帳アプリケーションを起動する。
【００７４】
次に、ステップＳ１０６において、表示制御部１０８は、メニューを操作表示部１２２に表示する。
【００７５】
‐メニュー画像‐
ここで、図５を参照して、表示制御部１０８によるメニュー画像の表示例について説明する。図５は、メニュー画像の表示例（メニュー画像４０）を示した説明図である。
【００７６】
図５に示したように、メニュー画像４０は、例えば明細データＤＬボタン４０２、通帳表示ボタン４０４、パスワード変更ボタン４０６、および終了ボタン４１６を含む。
【００７７】
明細データＤＬボタン４０２がタップされると、各銀行の明細データのダウンロードが開始され、通帳表示ボタン４０４がタップされると通帳画像が表示される。また、パスワード変更ボタン４０６がタップされると、通帳アプリケーションの認証に用いられていた認証情報であるパスワード情報の変更画像が表示される。そして、終了ボタン４１６がタップされると、通帳アプリケーションが終了される。
【００７８】
次いで、ステップＳ１０９において、操作認識部１０６は、メニュー画像４０に含まれるいずれかのメニューボタンに対するタップ操作を認識する。
【００７９】
次に、操作認識部１０６が「明細データＤＬボタン４０２」に対する利用者のタップ操作を認識し、明細データのダウンロードを指示するための利用者の操作として認識した場合（Ｓ１０９／明細データＤＬ）、ステップＳ１１２において、明細取得制御部１０４は銀行システム２（インターネットバンキング）へアクセスし、正当性が確認されると銀行システム２にログインする。
【００８０】
次いで、ステップＳ１１５において、明細取得制御部１０４は、明細ＤＢ２１に格納されている明細データをダウンロードする。ダウンロードされた明細データは、銀行明細ＤＢ１２７に記憶される。
【００８１】
次に、ステップＳ１１８において、連続性判断部１１０は、銀行明細ＤＢ１２７に記憶されている前回ダウンロードした明細データ（取引明細群）における最終行（取引日時が最も新しい直近の取引明細行）の残高Ａを参照して、前回ダウンロードした第１の明細データと今回ダウンロードした第２の明細データとの連続性の判断を開始する。
【００８２】
具体的には、続くステップＳ１２１において、連続性判断部１１０は、今回ダウンロード（ＤＬ）した第２の明細データの最も古い取引明細行の取引内容Ｂ、取引金額Ｃ、残高Ｄ、および取引日付Ｙを確認する。
【００８３】
次いで、ステップＳ１２４において、連続性判断部１１０は、上記確認した最古の取引明細行の情報のうち、取引内容Ｂが「入金」と「支払」のいずれであるかを確認する。
【００８４】
次に、取引内容Ｂが「入金」の場合、ステップＳ１２７において、連続性判断部１１０は、前回ＤＬした最終取引明細行の残高Ａと今回ＤＬした最古取引明細行の取引金額Ｃを加算した額が、今回ＤＬした最古取引明細行の残高Ｄになるか否かを確認する。
【００８５】
次いで、残高Ｄにならない場合（Ｓ１２７／Ｎｏ）、前回ＤＬした最終取引明細行と今回ＤＬした最古取引明細行は不連続と判断され、補間取引明細の生成が開始される。具体的には、まず、ステップＳ１３０において、取引明細生成部１１２は、今回ＤＬした最古取引明細行の残高Ｄから取引金額Ｃを減算して値Ｅを算出する。
【００８６】
次に、ステップＳ１３３において、取引明細生成部１１２は、前回ＤＬした最終取引明細行の残高Ａから上記算出した値Ｅを減算して値Ｆを算出する。
【００８７】
そして、ステップＳ１３６において、取引明細生成部１１２は、前回ＤＬした（旧明細の）最終取引明細行と今回ＤＬした最古取引明細行との間に、補間取引明細行を追加する。当該補間取引明細行の取引金額等は以下の処理により設定される。
【００８８】
まず、ステップＳ１３９において、上記算出した値Ｆの正負が判断される。
【００８９】
次いで、値Ｆが正の場合、ステップＳ１４２において、取引明細生成部１１２は、補間取引明細行の取引日付を「（今回ＤＬした最古取引明細行の取引日付Ｙ−１）日」とし、取引内容「支払（自動入力）」とし、取引金額を上記算出した「値Ｆ」とし、残高を上記算出した「値Ｅ」とする。
【００９０】
−設定例１−
ここで、上記Ｓ１４２による補間取引明細行の取引情報の設定例を図６に示す。図６左に示す例１は、上記Ｓ１４２による補間取引明細行の取引情報における、取引金額Ｆ、残高Ｅの設定例である。
【００９１】
例１では、前回ＤＬした最終取引明細行４２１−１の残金Ａ１が「１００，０００」であって、最古取引明細行４２２−１の取引金額Ｃ１が「３０，０００」であって、残高Ｄ１が「５０，０００」であることが示される。この場合、最古取引明細行４２２−１の取引内容が入金（Ｓ１２４／入金）であって、かつＡ１＋Ｃ１＝Ｄ１が成立しないので（Ｓ１２７／Ｎｏ）、「Ｄ１−Ｃ１」により算出された「Ｅ１：２０，０００」（Ｓ１３０）が、追加された補間取引明細行４４０−１の残高として設定される（Ｓ１４２）。また、「Ａ１−Ｅ１」により算出された「Ｆ１：８０，０００」（Ｓ１３３）は、正の値であるため、追加された補間取引明細行４４０−１の支払いの取引金額として設定される（Ｓ１４２）。
【００９２】
一方、上記Ｓ１３９において値Ｆが負と判断された場合、ステップＳ１４５において、取引明細生成部１１２は、補間取引明細行の取引日付を「（今回ＤＬした最古取引明細行の取引日付Ｙ−１）日」とし、取引内容「入金（自動入力）」とし、取引金額に上記算出した値Ｆを正の値に変換した「値Ｆ×−１」を設定し、残高を上記算出した「値Ｅ」とする。
【００９３】
−設定例２−
ここで、図６右に示す例２を用いて、上記Ｓ１４５による補間取引明細行の取引情報の設定例について説明する。
【００９４】
例２では、前回ＤＬした最終取引明細行４２１−２の残金Ａ２が「１００，０００」であって、最古取引明細行４２２−２の取引金額Ｃ２が「３０，０００」であって、残高Ｄ２が「１５０，０００」であることが示される。この場合、最古取引明細行４２２−２の取引内容が入金（Ｓ１２４／入金）であって、かつＡ２＋Ｃ２＝Ｄ２が成立しないので（Ｓ１２７／Ｎｏ）、「Ｄ２−Ｃ２」により算出された「Ｅ２：１２０，０００」（Ｓ１３０）が、追加された補間取引明細行４４０−２の残高として設定される（Ｓ１４５）。また、「Ａ２−Ｅ２」により算出された「Ｆ２：−２０，０００」（Ｓ１３３）は、負の値であるため、これに「−１」を乗算して正の値に変換した値「２０，０００」が、追加された補間取引明細行４４０−２の入金の取引金額として設定される（Ｓ１４５）。
【００９５】
続いて、今回ＤＬした最古取引明細行の取引内容Ｂが「支払」の場合（Ｓ１２４／支払）、ステップＳ２２７において、連続性判断部１１０は、前回ＤＬした最終取引明細行の残高Ａから今回ＤＬした最古取引明細行の取引金額Ｃを減算した額が、今回ＤＬした最古取引明細行の残高Ｄになるか否かを確認する。
【００９６】
次いで、残高Ｄにならない場合（Ｓ２２７／Ｎｏ）、前回ＤＬした最終取引明細行と今回ＤＬした最古取引明細行は不連続と判断され、補間取引明細の生成が開始される。具体的には、まず、ステップＳ２３０において、取引明細生成部１１２は、今回ＤＬした最古取引明細行の残高Ｄと取引金額Ｃを加算して値Ｇを算出する。
【００９７】
次に、ステップＳ２３３において、取引明細生成部１１２は、前回ＤＬした最終取引明細行の残高Ａから上記算出した値Ｇを減算して値Ｈを算出する。
【００９８】
そして、ステップＳ２３６において、取引明細生成部１１２は、前回ＤＬした（旧明細の）最終取引明細行と今回ＤＬした最古取引明細行との間に、補間取引明細行を追加する。当該補間取引明細行の取引金額等は以下の処理により設定される。
【００９９】
まず、ステップＳ２３９において、上記算出した値Ｈの正負が判断される。
【０１００】
次いで、値Ｈが正の場合、ステップＳ２４２において、取引明細生成部１１２は、補間取引明細行の取引日付を「（今回ＤＬした最古取引明細行の取引日付Ｙ−１）日」とし、取引内容「支払（自動入力）」とし、取引金額を上記算出した「値Ｈ」とし、残高を上記算出した「値Ｇ」とする。
【０１０１】
−設定例３−
ここで、上記Ｓ２４２による補間取引明細行の取引情報の設定例を図７に示す。図７左に示す例３は、上記Ｓ２４２による補間取引明細行の取引情報における、取引金額Ｈ、残高Ｇの設定例である。
【０１０２】
例３では、前回ＤＬした最終取引明細行４２１−３の残金Ａ３が「１００，０００」であって、最古取引明細行４２２−３の取引金額Ｃ３が「３０，０００」であって、残高Ｄ３が「５０，０００」であることが示される。この場合、最古取引明細行４２２−３の取引内容が支払（Ｓ１２４／支払）であって、かつＡ３−Ｃ３＝Ｄ３が成立しないので（Ｓ２２７／Ｎｏ）、「Ｄ３＋Ｃ３」により算出された「Ｇ３：８０，０００」（Ｓ２３０）が、追加された補間取引明細行４４０−３の残高として設定される（Ｓ２４２）。また、「Ａ３−Ｇ３」により算出された「Ｈ３：２０，０００」（Ｓ２３３）は、正の値であるため、追加された補間取引明細行４４０−３の支払いの取引金額として設定される（Ｓ２４２）。
【０１０３】
一方、上記Ｓ２３９において値Ｈが負と判断された場合、ステップＳ２４５において、取引明細生成部１１２は、補間取引明細行の取引日付を「（今回ＤＬした最古取引明細行の取引日付Ｙ−１）日」とし、取引内容「入金（自動入力）」とし、取引金額に上記算出した値Ｈを正の値に変換した「値Ｈ×−１」を設定し、残高を上記算出した「値Ｇ」とする。
【０１０４】
−設定例４−
ここで、図７右に示す例４を用いて、上記Ｓ２４５による補間取引明細行の取引情報の設定例について説明する。
【０１０５】
例４では、前回ＤＬした最終取引明細行４２１−４の残金Ａ４が「１００，０００」であって、最古取引明細行４２２−４の取引金額Ｃ４が「３０，０００」であって、残高Ｄ４が「１５０，０００」であることが示される。この場合、最古取引明細行４２２−４の取引内容が支払（Ｓ１２４／支払）であって、かつＡ４−Ｃ４＝Ｄ４が成立しないので（Ｓ２２７／Ｎｏ）、「Ｄ４＋Ｃ４」により算出された「Ｇ４：１８０，０００」（Ｓ２３０）が、追加された補間取引明細行４４０−４の残高として設定される（Ｓ２４５）。また、「Ａ４−Ｇ４」により算出された「Ｈ４：−８０，０００」（Ｓ２３３）は、負の値であるため、これに「−１」を乗算して正の値に変換した値「８０，０００」が、追加された補間取引明細行４４０−４の入金の取引金額として設定される（Ｓ２４５）。
【０１０６】
続いて、補間取引明細行の追加が完了（Ｓ１４２、Ｓ１４５、Ｓ２４２、Ｓ２４５）、または、連続性判断部１１０により前回ＤＬした最終取引明細行と今回ＤＬした最古取引明細行とが連続すると判断されると（Ｓ１２７／Ｙｅｓ、Ｓ２２７／Ｙｅｓ）、ステップＳ２５０において、表示制御部１０８は通帳画像の初めに配列されている表紙画像を操作表示部１２２に表示する。
【０１０７】
そして、ステップＳ２５３において、表紙画像に対する利用者によるページめくり操作（例えばフリック操作）が操作認識部１０６により認識されると、表示制御部１０８は、取引明細画像を操作表示部１２２に表示する。
【０１０８】
‐取引明細画像‐
ここで、図８を参照して、補間取引明細行の追加された取引明細画像の表示例について説明する。図８は、取引明細画像の表示例（取引明細画像４４）を示した説明図である。なお、取引明細画像は、紙の通帳における取引明細ページに対応する画像であり、口座の通帳画像において２ページ目以降に表示される。
【０１０９】
取引明細画像４４には、例えば取引日、取引内容、取引金額、口座残高、および備考欄などが表示される。また、図８に示すように、複数の明細データは時系列順に並べられている。
【０１１０】
ここで、図８に示す取引明細画像４４では、前回ＤＬした取引明細群の最終取引明細行４２１と、今回ＤＬした取引明細群の最古取引明細行４２２とが連続しないと連続性判断部１１０により判断されたために、最終取引明細行４２１と最古取引明細行４２２との間に、取引明細生成部１１２により生成された補間取引明細行４４０が追加される。
【０１１１】
図８に示す例では、補間取引明細行４４０の取引内容が「支払（自動入力）」と示されることで、当該取引明細行が、最終取引明細行４２１と最古取引明細行４２２との間の連続性の整合をとるために自動的に生成されたものであること（ダウンロードデータとは異なること）が明示される。なお、補間取引明細行４４０の明示方法はこれに限定されず、例えば他の通常の取引明細行とは異なる色で表示したり、補間取引明細行４４０特定部分に所定の印を付加したりして、ダウンロードデータとの違いを表現することも可能である。
【０１１２】
以上説明したように、本実施形態では、最終取引明細行４２１と最古取引明細行４２２とが不連続の場合に、これらを連続させるための補間取引明細行を追加することで、通帳アプリケーションを利用して表示される取引明細における齟齬を改善することができる。
【０１１３】
＜＜４．変形例＞＞
続いて、本実施形態の変形例について図９〜図１１を参照して説明する。
【０１１４】
＜４−１．変形例１＞
図９は、本実施形態の変形例１による取引明細行の不連続の明示について説明する図である。例えば、図９（１）では、前回ＤＬした最終取引明細行と今回ＤＬした最古取引明細行とが不連続の場合に、最終取引明細行４５１と今回ＤＬした取引明細群４５３との間に、空白行４５０が挿入される。
【０１１５】
このように、前回ＤＬした最終取引明細行と今回ＤＬした最古取引明細行とが不連続であっても、空白行４５０の挿入によりこれらが区別されることで、この間に何らかの取引があったことが想定され、通帳アプリケーションを利用して表示される取引明細における齟齬を改善することができる。
【０１１６】
また、図９（２）では、前回ＤＬした最終取引明細行と今回ＤＬした最古取引明細行とが不連続の場合に、最終取引明細行４５１’と今回ＤＬした取引明細群４５３’とが異なる表示態様（背景色または文字色等）で表示される。
【０１１７】
このように、前回ＤＬした最終取引明細行と今回ＤＬした最古取引明細行とが不連続であっても、前記ＤＬした取引明細群と今回ＤＬした取引明細群の表示態様が異なることによりこれらが区別され、通帳アプリケーションを利用して表示される取引明細における齟齬を改善することができる。
【０１１８】
以上、変形例１について説明した。なお、挿入した空白行４５１、表示態様が変更された最終取引明細行４５１’、または今回ＤＬした取引明細群４５３’がタップ若しくは長押しされた際に、表示制御部１０８により補間取引明細自動生成の可否を確認する確認画像を表示させてもよい。利用者により自動生成が許可された場合は、上記実施形態で説明した取引明細生成部１１２による補間取引明細の生成が実行される。
【０１１９】
＜４−２．変形例２＞
次に、本実施形態の変形例２について図１０を参照して説明する。本変形例では、上記実施形態において取引明細生成部１１２により自動生成された補間取引明細に代わり、若しくはこれに加えて、手動で取引明細行を追加することが可能である。
【０１２０】
図１０は、本実施形態の変形例２による取引明細の手動入力例について説明する図である。図１０上に示すように、取引明細画像において、不連続の最終取引明細行と最古取引明細行とを連続させるために、これらの間に追加された補間取引明細行４４０に対して、利用者が指５でタップまたは長押しすると、表示制御部１０８により、取引明細の手動入力の実行を確認する確認画像４６０がポップアップ表示される。
【０１２１】
次に、確認画像４６０に含まれる「はい」のボタンをタップすると、図１０中央に示すように、表示制御部１０８により、取引明細情報を入力するための入力画像４６１がポップアップ表示される。入力画像４６１は、年月日入力欄と、取引内容入力欄と、支払金額欄と、預かり金額欄と、登録ボタンとを含む。利用者は、入力画像４６１の各入力欄に取引明細情報を入力して登録ボタンをタップする。なお入力された取引明細情報が不適切な場合はエラー表示される。例えば、明細データが欠如している期間以外の年月日が入力された場合はエラーとなる。
【０１２２】
取引明細生成部１１２は、入力画像４６１から入力された取引明細情報に基づいて手動入力取引明細行４４２を生成する。この場合、連続性判断部１１０は、前回ＤＬした最終取引明細行と、手動入力取引明細行４４２と、今回ＤＬした最古取引明細行とが連続するか否かを判断する。連続する場合、表示制御部１０８は、補間取引明細行４４０を削除して手動入力取引明細行４４２を追加表示する。
【０１２３】
一方、不連続の場合、取引明細生成部１１２により、手動入力取引明細行４４２と最古取引明細行とが連続するよう補間取引明細４４０’が再生成され、表示制御部１０８により、図１０下に示すように、手動入力取引明細行４４２および再生成された補間取引明細と４４０’が、最終取引明細行と最古取引明細行との間に表示される。
【０１２４】
このように、変形例２によれば、手動で取引明細行を挿入することが可能である。
【０１２５】
＜４−３．変形例３＞
次いで、本実施形態の変形例３について図１１を参照して説明する。本変形例では、ダウンロードされた明細データを参照して、自動生成された補間取引明細に代わり、若しくはこれに加えて、定期的な取引明細行を追加することが可能である。
【０１２６】
図１１は、本実施形態の変形例３による定期取引明細の生成例について説明する図である。図１１上に示すように、取引明細画像において、不連続の最終取引明細行と最古取引明細行とを連続させるために、これらの間に追加された補間取引明細行４４６に対して、利用者が指５でタップまたは長押しすると、表示制御部１０８により、定期的な取引明細の自動入力の実行を確認する確認画像４７０がポップアップ表示される。
【０１２７】
次に、確認画像４７０に含まれる「はい」のボタンをタップすると、取引明細生成部１１２は、前回および今回ＤＬした明細データに基づいて定期取引明細行４４７を生成する。具体的には、定期取引明細行４４７は、ＤＬした明細データに含まれる各取引日および取引内容に基づいて定期的な取引明細を抽出し、定期補足取引明細を生成する。
【０１２８】
例えば、図１１に示す例では、「２５年１２月２５日」の「振込（キウヨ）」取引と、「２６年２月２５日」の「振込（キウヨ）」取引に基づいて、取引明細生成部１１２により「２６年１月２５日」の「振込（キウヨ）」取引が、定期取引明細行４４７として生成される。定期取引明細行４４７の取引金額は、抽出された各定期的な取引明細の取引金額に基づいて算出される。例えば、取引明細生成部１１２は、「２５年１２月２５日」の「振込（キウヨ）」取引における入金額「２５０，０００」と、「２６年２月２５日」の「振込（キウヨ）」取引における入金額「２００，０００」との平均額「２２５，０００」を取引金額（入金）として算出してもよい。
【０１２９】
また、図１１に示す例では、「２５年１２月２８日」の「ＣＣカード」取引と、「２６年２月２８日」の「ＣＣカード」取引に基づいて、取引明細生成部１１２により「２６年１月２８日」の「ＣＣカード」取引が、定期取引明細行４４８として生成される。定期取引明細行４４８の取引金額は、抽出された各定期的な取引明細の取引金額に基づいて算出される。例えば、取引明細生成部１１２は、「２５年１２月２８日」の「ＣＣカード」取引における支払額「１５０，０００」と、「２６年２月２８日」の「ＣＣカード」取引における支払額「８０，０００」との平均額「１１５，０００」を取引金額（支払）として算出してもよい。
【０１３０】
また、取引明細生成部１１２により生成された定期取引明細行４４７、定期取引明細行４４８の取引内容の欄には、例えば「推測」の文字を示すことで、本取引明細行が自動生成されたものであることが明示される。
【０１３１】
そして、連続性判断部１１０は、前回ＤＬした最終取引明細行と、定期取引明細行４４７、４４８と、今回ＤＬした最古取引明細行とが連続するか否かを判断する。連続する場合、表示制御部１０８は、補間取引明細行４４６を削除して定期取引明細行４４７、４４８を追加表示する。
【０１３２】
一方、不連続の場合、取引明細生成部１１２により、定期取引明細行４４７、４４８と最古取引明細行とが連続するよう補間取引明細４４６’が再生成され、表示制御部１０８により、定期取引明細行４４７、４４８、および再生成された補間取引明細と４４６’が、最終取引明細行と最古取引明細行との間に表示される。
【０１３３】
このように、変形例３によれば、ＤＬした明細データに基づいて、自動的に定期的な取引明細行を生成し、挿入することが可能である。なお予め利用者により定期取引情報が入力されている場合、取引明細生成部１１２は、当該定期取引情報に基づいて定期取引明細を生成することも可能である。
【０１３４】
＜＜５．まとめ＞＞
以上説明したように、本実施形態による情報処理装置１０は、通帳アプリケーションを利用して表示される取引明細における齟齬を改善することが可能である。具体的には、不連続の取引明細行を区別することで、また、不連続の取引明細行の間に補間取引明細行を自動挿入することで、取引明細における明細データの欠如状態、不整合状態を改善する。
【０１３５】
また、補間取引明細行を自動追加して明細データの正当性を確保することで、明細データのグラフ表示やソートなどの機能が利用者により実行された場合にも、収支の状態が合致し、グラフの整合性を保つことが可能となる。
【０１３６】
また、自動追加した補間取引明細行を通常の取引明細行とは異なる表示態様で表示することで（例えば取引内容欄への特定文言の追加、背景色／文字色の変更、特定記号の挿入など）、利用者は、明細データのＤＬを必要な期日までに実行していなかったこと（明細データの欠如）を視覚的に理解できるので、以後、ＤＬ実行処理の実施忘れを防止することも可能である。
【０１３７】
なお、添付図面を参照しながら本発明の好適な実施形態について詳細に説明したが、本発明はかかる例に限定されない。本発明の属する技術の分野における通常の知識を有する者であれば、特許請求の範囲に記載された技術的思想の範疇内において、各種の変更例または修正例に想到し得ることは明らかであり、これらについても、当然に本発明の技術的範囲に属するものと了解される。
【０１３８】
例えば通帳アプリケーションのソート機能を活用して自動追加した補間取引明細のみを表示させることも可能である。これにより、利用者は自身がどの程度ＤＬの実施を行っていなかったかを把握することが可能である。
【０１３９】
また、各取引明細行の幅は、利用者が指でタッチできる程度の幅で表示される。
【０１４０】
また、本発明の実施形態によれば、ＣＰＵ、ＲＯＭ、およびＲＡＭなどのハードウェアを、上述した情報処理装置１０の各構成と同等の機能を発揮させるためのコンピュータプログラムも提供可能である。また、該コンピュータプログラムが記録された記録媒体も提供される。
【符号の説明】
【０１４１】
１０  情報処理装置
１２  通信網
１４  専用網
２０  ＩＢサーバ
２１  明細ＤＢ
２２  認証ＤＢ
３０  中継サーバ
１００  制御部
１０２  アプリ認証部
１０４  明細取得制御部
１０６  操作認識部
１０８  表示制御部
１１０  連続性判断部
１１２  取引明細生成部
１２０  通信部
１２２  操作表示部
１２４  記憶部
１２５    通帳アプリ認証ＤＢ
１２６    銀行認証ＤＢ
１２７    銀行明細ＤＢ
１２９    口座情報種別ＤＢ
【図１】
2015162046.tif 000003
【図２】
2015162046.tif 000004
【図３】
2015162046.tif 000005
【図４】
2015162046.tif 000006
【図５】
2015162046.tif 000007
【図６】
2015162046.tif 000008
【図７】
2015162046.tif 000009
【図８】
2015162046.tif 000010
【図９】
2015162046.tif 000011
【図１０】
2015162046.tif 000012
【図１１】
2015162046.tif 000013
【図１２】
2015162046.tif 000014