(57)【要約】【課題】利用者の取引履歴を過不足なく情報処理端末に取得させることが可能な、情報処理装置、情報処理システム、情報処理方法、及びプログラムを提供する。【解決手段】取引履歴の取得に関する条件が満たされた場合に、管理装置に記憶されている情報処理端末の利用者の取引履歴のうち前記利用者が未取得の取引履歴を前記管理装置から取得する取得部と、前記利用者が利用する情報処理端末から受信される要求に応じて、取得された取引履歴の前記情報処理端末への送信を制御する送信制御部と、を備える、情報処理装置。【選択図】図１２
2016021128.tif 000002
【特許請求の範囲】
【請求項１】
取引履歴の取得に関する条件が満たされた場合に、管理装置に記憶されている情報処理端末の利用者の取引履歴のうち前記利用者が未取得の取引履歴を前記管理装置から取得する取得部と、
前記利用者が利用する情報処理端末から受信される要求に応じて、取得された取引履歴の前記情報処理端末への送信を制御する送信制御部と、
を備える、情報処理装置。
【請求項２】
前記情報処理装置は、前記未取得の取引履歴が次回の取得前に消去されるか否かを判断する判断部をさらに備え、
前記条件は、前記判断部により前記未取得の取引履歴が取得前に消去されると判断されることを含む、請求項１に記載の情報処理装置。
【請求項３】
前記判断部は、前記未取得の取引履歴に対応づけて定められた保存期限日と次回の取得予定日とを比較することにより、前記未取得の取引履歴が取得前に消去されるか否かを判断する、請求項２に記載の情報処理装置。
【請求項４】
前記条件は、前記情報処理端末における取引履歴の取得機能が停止したことが前記情報処理端末から通知されることを含む、請求項１〜３のいずれか一項に記載の情報処理装置。
【請求項５】
前記条件は、前回の取得時から所定の期間が経過することを含む、請求項１〜４のいずれか一項に記載の情報処理装置。
【請求項６】
前記条件は、前記情報処理端末における取引履歴の次回取得予定日時を経過することを含む、請求項１〜５のいずれか一項に記載の情報処理装置。
【請求項７】
前記取得部は、前記未取得の取引履歴のうち前記判断部により次回の取得前に消去されると判断された取引履歴を取得する、請求項２または３に記載の情報処理装置。
【請求項８】
前記取得部は、前記未取得の取引履歴のうち次回取得予定日時を経過した取引履歴を取得する、請求項６に記載の情報処理装置。
【請求項９】
前記情報処理装置は、前記管理装置から取得された取引履歴を記憶する記憶部と、
前記記憶部に記憶されている取引履歴が前記情報処理端末へ送信された場合には、送信された取引履歴を前記記憶部から削除する取引履歴管理部と、をさらに備える、請求項１〜８のいずれか一項に記載の情報処理装置。
【請求項１０】
前記情報処理装置は、前記管理装置に記憶されている前記利用者の取引履歴のうち前記情報処理端末が未取得の取引履歴が有るか否かを判定する未取得履歴有無判定部をさらに備える、請求項１〜９のいずれか一項に記載の情報処理装置。
【請求項１１】
取引履歴の取得に関する条件が満たされた場合に、管理装置に記憶されている情報処理端末の利用者の取引履歴のうち前記利用者が未取得の取引履歴を前記管理装置から取得する取得部と、
前記利用者が利用する情報処理端末から受信される要求に応じて、取得された取引履歴の前記情報処理端末への送信を制御する送信制御部と、
を備える、情報処理システム。
【請求項１２】
取引履歴の取得に関する条件が満たされた場合に、管理装置に記憶されている情報処理端末の利用者の取引履歴のうち前記利用者が未取得の取引履歴を前記管理装置から取得するステップと、
前記利用者が利用する情報処理端末から受信される要求に応じて、取得された取引履歴の前記情報処理端末への送信を制御するステップと、
を備える、情報処理方法。
【請求項１３】
コンピュータを、
取引履歴の取得に関する条件が満たされた場合に、管理装置に記憶されている情報処理端末の利用者の取引履歴のうち前記利用者が未取得の取引履歴を前記管理装置から取得する取得部と、
前記利用者が利用する情報処理端末から受信される要求に応じて、取得された取引履歴の前記情報処理端末への送信を制御する送信制御部、
として機能させるための、プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、情報処理装置、情報処理システム、情報処理方法、及びプログラムに関する。
【背景技術】
【０００２】
従来、金融機関における利用者の取引履歴を、利用者が所持する端末で確認可能にする技術が開発されている。例えば、特許文献１には、ネットバンキングのユーザから過去の取引履歴の照会があった場合に、入出金項目名や入出金額をカレンダー形式の通帳インターフェース上で表示する技術が記載されている。また、特許文献２には、個人ＰＣから記帳明細データが照会された時に、記帳明細ＤＢに保存されている記帳明細データをブラウザに表示可能な形式に編集する技術が記載されている。
【０００３】
また、例えば利用履歴の取得漏れの防止などを図るために、利用者の利用履歴を代行取得する技術も提案されている。例えば、特許文献３には、代行サーバが、水道サーバ、電気サーバ及びガスサーバから毎日レートを取得し、そして、携帯電話機からの料金の問合せのあった時点で、代行サーバが、現時点の複数の公共料金が整理された料金表を含むメールを携帯電話機へ送信する技術が記載されている。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２００５−２１６０９７号公報
【特許文献２】特開２０１３−１０１４１８号公報
【特許文献３】特開２００５−３５２６３１号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
ところで、利用者の取引履歴を記憶する管理装置から情報処理端末が直接取引履歴を取得可能な場面に特許文献３に記載の技術を適用することを想定すると、特許文献３に記載の技術では、情報処理端末により取得される取引履歴に過不足が生じる恐れがある。例えば、特許文献３に記載の技術では、代行サーバは、携帯電話機による水道サーバなどの各事業者のサーバ装置からのデータの取得状況を把握していないので、利用履歴が携帯電話機により各事業者のサーバ装置から取得済みであるか否かに関わらずに利用履歴を代行取得する。このため、携帯電話機は、すでに取得済みの利用履歴を代行サーバから再度取得してしまう恐れがある。
【０００６】
そこで、本発明は、上記問題に鑑みてなされたものであり、本発明の目的とするところは、利用者の取引履歴を過不足なく情報処理端末に取得させることが可能な、新規かつ改良された情報処理装置、情報処理システム、情報処理方法、及びプログラムを提供することにある。
【課題を解決するための手段】
【０００７】
上記課題を解決するために、本発明のある観点によれば、取引履歴の取得に関する条件が満たされた場合に、管理装置に記憶されている情報処理端末の利用者の取引履歴のうち前記利用者が未取得の取引履歴を前記管理装置から取得する取得部と、前記利用者が利用する情報処理端末から受信される要求に応じて、取得された取引履歴の前記情報処理端末への送信を制御する送信制御部と、を備える、情報処理装置が提供される。
【０００８】
前記情報処理装置は、前記未取得の取引履歴が次回の取得前に消去されるか否かを判断する判断部をさらに備え、前記条件は、前記判断部により前記未取得の取引履歴が取得前に消去されると判断されることを含んでもよい。
【０００９】
前記判断部は、前記未取得の取引履歴に対応づけて定められた保存期限日と次回の取得予定日とを比較することにより、前記未取得の取引履歴が取得前に消去されるか否かを判断してもよい。
【００１０】
前記条件は、前記情報処理端末における取引履歴の取得機能が停止したことが前記情報処理端末から通知されることを含んでもよい。
【００１１】
前記条件は、前回の取得時から所定の期間が経過することを含んでもよい。
【００１２】
前記条件は、前記情報処理端末における取引履歴の次回取得予定日時を経過することを含んでもよい。
【００１３】
前記取得部は、前記未取得の取引履歴のうち前記判断部により次回の取得前に消去されると判断された取引履歴を取得してもよい。
【００１４】
前記取得部は、前記未取得の取引履歴のうち次回取得予定日時を経過した取引履歴を取得してもよい。
【００１５】
前記情報処理装置は、前記管理装置から取得された取引履歴を記憶する記憶部と、前記記憶部に記憶されている取引履歴が前記情報処理端末へ送信された場合には、送信された取引履歴を前記記憶部から削除する取引履歴管理部と、をさらに備えてもよい。
【００１６】
前記情報処理装置は、前記管理装置に記憶されている前記利用者の取引履歴のうち前記情報処理端末が未取得の取引履歴が有るか否かを判定する未取得履歴有無判定部をさらに備えてもよい。
【００１７】
また、上記課題を解決するために、本発明の別の観点によれば、取引履歴の取得に関する条件が満たされた場合に、管理装置に記憶されている情報処理端末の利用者の取引履歴のうち前記利用者が未取得の取引履歴を前記管理装置から取得する取得部と、前記利用者が利用する情報処理端末から受信される要求に応じて、取得された取引履歴の前記情報処理端末への送信を制御する送信制御部と、を備える、情報処理システムが提供される。
【００１８】
また、上記課題を解決するために、本発明の別の観点によれば、取引履歴の取得に関する条件が満たされた場合に、管理装置に記憶されている情報処理端末の利用者の取引履歴のうち前記利用者が未取得の取引履歴を前記管理装置から取得するステップと、前記利用者が利用する情報処理端末から受信される要求に応じて、取得された取引履歴の前記情報処理端末への送信を制御するステップと、を備える、情報処理方法が提供される。
【００１９】
また、上記課題を解決するために、本発明の別の観点によれば、コンピュータを、取引履歴の取得に関する条件が満たされた場合に、管理装置に記憶されている情報処理端末の利用者の取引履歴のうち前記利用者が未取得の取引履歴を前記管理装置から取得する取得部と、前記利用者が利用する情報処理端末から受信される要求に応じて、取得された取引履歴の前記情報処理端末への送信を制御する送信制御部、として機能させるための、プログラムが提供される。
【発明の効果】
【００２０】
以上説明したように本発明によれば、利用者の取引履歴を過不足なく情報処理端末に取得させることができる。
【図面の簡単な説明】
【００２１】
【図１】本発明の実施形態による情報処理システムの構成例を示した説明図である。
【図２】モバイル端末２０による取引明細取得処理の一例を示したシーケンス図である。
【図３】モバイル端末２０による取引明細取得処理の一例を示したシーケンス図である。
【図４】同実施形態によるＷＥＢ・ＤＢサーバ１０の構成を示した機能ブロック図である。
【図５】同実施形態によるユーザＤＢ１２４の構成例を示した説明図である。
【図６】同実施形態による明細保存ＤＢ１２６の構成例を示した説明図である。
【図７】同実施形態による動作例１を示したシーケンス図である。
【図８】同実施形態による動作例２を示したシーケンス図である。
【図９】同実施形態による明細保存ＤＢ１２６における取引明細の記憶例を示した説明図である。
【図１０】同実施形態による動作例３を示したシーケンス図である。
【図１１】同実施形態による明細保存ＤＢ１２６における取引明細の記憶例を示した説明図である。
【図１２】同実施形態による動作例４を示したシーケンス図である。
【図１３】同実施形態による明細保存ＤＢ１２６における取引明細の記憶例を示した説明図である。
【図１４】同実施形態によるＷＥＢ・ＤＢサーバ１０のハードウェア構成を示した説明図である。
【発明を実施するための形態】
【００２２】
以下に添付図面を参照しながら、本発明の好適な実施の形態について詳細に説明する。なお、本明細書及び図面において、実質的に同一の機能構成を有する構成要素については、同一の符号を付することにより重複説明を省略する。
【００２３】
また、以下に示す項目順序に従って当該「発明を実施するための形態」を説明する。
１．情報処理システムの基本構成
１−１．基本構成
１−２．課題の整理
２．実施形態の詳細な説明
２−１．構成
２−２．動作
２−３．効果
３．ハードウェア構成
４．変形例
【００２４】
＜＜１．情報処理システムの基本構成＞＞
＜１−１．基本構成＞
本発明は、一例として「２．実施形態の詳細な説明」において詳細に説明するように、多様な形態で実施され得る。最初に、本発明の実施形態による情報処理システムの基本構成について図１を参照して説明する。
【００２５】
図１に示したように、本実施形態による情報処理システムは、ＷＥＢ・ＤＢサーバ１０、通信網１２、モバイル端末２０、およびＩＢ（Ｉｎｔｅｒｎｅｔ  Ｂａｎｋｉｎｇ）サーバ３０を含む。
【００２６】
［１−１−１．ＷＥＢ・ＤＢサーバ１０］
ＷＥＢ・ＤＢサーバ１０は、本発明における情報処理装置の一例である。このＷＥＢ・ＤＢサーバ１０は、後述するモバイル端末２０がＩＢサーバ３０と通信を行う際の中継サーバである。例えば、ＷＥＢ・ＤＢサーバ１０は、モバイル端末２０から取引明細の取得要求を受信し、そして、受信した取得要求をＩＢサーバ３０へ送信する。また、ＷＥＢ・ＤＢサーバ１０は、モバイル端末２０のユーザの取引明細をＩＢサーバ３０から受信し、そして、受信した取引明細をモバイル端末２０へ送信する。なお、取引明細とは、ユーザの取引履歴のうち例えば取引一件分の明細データである。
【００２７】
［１−１−２．通信網１２］
通信網１２は、通信網１２に接続されている装置から送信される情報の有線、または無線の伝送路である。例えば、通信網１２は、電話回線網、インターネット、衛星通信網などの公衆回線網や、Ｅｔｈｅｒｎｅｔ（登録商標）を含む各種のＬＡＮ、ＷＡＮ（Ｗｉｄｅ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）などを含む。また、通信網１２は、ＩＰ−ＶＰＮ（Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ−Ｖｉｒｔｕａｌ  Ｐｒｉｖａｔｅ  Ｎｅｔｗｏｒｋ）などの専用回線網を含んでもよい。
【００２８】
［１−１−３．ＩＢサーバ３０］
ＩＢサーバ３０は、本発明における管理装置の一例である。ＩＢサーバ３０は、金融機関のインターネットバンキングシステムを管理するための装置である。例えば、ＩＢサーバ３０は、モバイル端末２０のユーザと対応づけて、ユーザの取引履歴を記憶する。
【００２９】
［１−１−４．モバイル端末２０］
モバイル端末２０は、本発明における情報処理端末の一例である。このモバイル端末２０は、タッチパネルを備えたディスプレイを有する。また、モバイル端末２０は、通信網１２に接続するための通信インターフェースを有する。なお、モバイル端末２０は、例えばスマートフォンや、タブレット端末であってもよい。
【００３０】
また、モバイル端末２０は、ＷＥＢ・ＤＢサーバ１０を介してＩＢサーバ３０から取引明細を取得し、そして、自端末に記憶することが可能である。さらに、モバイル端末２０は、記憶している取引明細を一覧化して、ディスプレイに表示することも可能である。
【００３１】
（１−１−４−１．取引明細取得処理）
ここで、モバイル端末２０によるＩＢサーバ３０からの取引明細の取得の具体的な処理内容について、図２〜図３を参照して説明する。
【００３２】
‐取得例１‐
図２は、モバイル端末２０による取引明細取得処理の一例を示した説明図である。なお、図２に示した例は、モバイル端末２０のＯＳ（Ｏｐｅｒａｔｉｏｎ  Ｓｙｓｔｅｍ）に、アプリケーションの起動および状態管理を行うサービス管理機能が実装されていることを前提とした取得処理の例である。
【００３３】
図２に示したように、まず、モバイル端末２０は、例えば、スマートフォン通帳アプリをモバイル端末２０にインストールした直後、またはモバイル端末２０のＯＳが通常に起動した際などに、スマートフォン通帳サービスを起動する（Ｓ１１）。続いて、モバイル端末２０は、サービス開始通知をＷＥＢ・ＤＢサーバ１０へ送信する（Ｓ１２）。
【００３４】
その後、ＷＥＢ・ＤＢサーバ１０は、サービス開始通知が受信された際に、モバイル端末２０に対応するサービス状態を「開始」としてデータベースに記録する（Ｓ１３）。
【００３５】
Ｓ１２の後、モバイル端末２０は、取引明細の自動取得の設定（以下、明細自動取得設定とも称する）がユーザによりなされているか否かを判定する（Ｓ１４）。明細自動取得設定がされている場合には（Ｓ１４：Ｙｅｓ）、モバイル端末２０は、次に、現在が、設定されている明細取得日時に該当するか否かを判定する（Ｓ１５）。現在が明細取得日時に該当しない場合には（Ｓ１５：Ｎｏ）、モバイル端末２０は、後述するＳ２０の動作を行う。一方、現在が明細取得日時に該当する場合には（Ｓ１５：Ｙｅｓ）、モバイル端末２０は、未取得の取引明細の取得要求をＷＥＢ・ＤＢサーバ１０へ送信する（Ｓ１６）。
【００３６】
その後、ＷＥＢ・ＤＢサーバ１０は、受信された取引明細の取得要求をＩＢサーバ３０へ送信する（Ｓ１７）。その後、ＩＢサーバ３０は、受信された取引明細の取得要求に基づいて、該当の取引明細を抽出し、そして、抽出した取引明細をＷＥＢ・ＤＢサーバ１０へ送信する（Ｓ１８）。その後、ＷＥＢ・ＤＢサーバ１０は、受信された取引明細をモバイル端末２０へ送信する。そして、モバイル端末２０は、受信された取引明細を自端末に保存する（Ｓ１９）。
【００３７】
その後、モバイル端末２０は、スマートフォン通帳サービスを終了する（Ｓ２０）。続いて、モバイル端末２０は、サービス終了通知をＷＥＢ・ＤＢサーバ１０へ送信する。そして、モバイル端末２０は、処理を終了する（Ｓ２１）。
【００３８】
その後、ＷＥＢ・ＤＢサーバ１０は、サービス終了通知が受信された際に、モバイル端末２０に対応するサービス状態を「終了」としてデータベースに記録する（Ｓ２２）。
【００３９】
一方、モバイル端末２０において明細自動取得設定がされていない場合には（Ｓ１４：Ｎｏ）、モバイル端末２０は、ユーザによる操作に応じて、スマートフォン通帳アプリを起動する（Ｓ２３）。続いて、モバイル端末２０は、ユーザによる操作に応じて、未取得の取引明細の取得要求をＷＥＢ・ＤＢサーバ１０へ送信する（Ｓ２４）。
【００４０】
なお、図２に示したＳ２５〜Ｓ２７の動作は、上記のＳ１７〜Ｓ１９と概ね同様である。
【００４１】
‐取得例２‐
また、図３は、モバイル端末２０による取引明細取得処理の別の例を示した説明図である。なお、図３に示した例は、モバイル端末２０に、アプリケーションタスクスケジュール機能が実装されていることを前提とした取得処理の例である。
【００４２】
図３に示したように、まず、モバイル端末２０は、例えば、モバイル端末２０のＯＳが通常に起動した際などに、タスクスケジュール機能を起動する（Ｓ３１）。続いて、モバイル端末２０は、スマートフォン通帳アプリがユーザによりスケジュール登録されているか否かを判定する（Ｓ３２）。スマートフォン通帳アプリがスケジュール登録されている場合には（Ｓ３２：Ｙｅｓ）、モバイル端末２０は、次に、スケジュール登録された日時に現在が該当するか否かを判定する（Ｓ３３）。スケジュール登録された日時に現在が該当しない場合には（Ｓ３３：Ｎｏ）、モバイル端末２０は、後述するＳ４０の動作を行う。一方、スケジュール登録された日時に現在が該当する場合には（Ｓ３３：Ｙｅｓ）、モバイル端末２０は、スマートフォン通帳アプリを起動する（Ｓ３４）。続いて、モバイル端末２０は、スマートフォン通帳アプリの機能により、未取得の取引明細の取得要求をＷＥＢ・ＤＢサーバ１０へ送信する（Ｓ３５）。
【００４３】
なお、図３に示したＳ３６〜Ｓ３８の動作は、図２におけるＳ１７〜Ｓ１９と同様である。
【００４４】
Ｓ３８の後、モバイル端末２０は、スマートフォン通帳アプリを終了させる（Ｓ３９）。続いて、モバイル端末２０は、タスクの実行結果を自端末に記録する。そして、モバイル端末２０は、処理を終了する（Ｓ４０）。
【００４５】
一方、スマートフォン通帳アプリがスケジュール登録されていない場合には（Ｓ１４：Ｎｏ）、モバイル端末２０は、ユーザによる操作に応じて、スマートフォン通帳アプリを起動する（Ｓ４１）。なお、図３に示したＳ４２〜Ｓ４５の動作は、図２におけるＳ２４〜Ｓ２７と同様である。
【００４６】
＜１−２．課題の整理＞
上述した取引明細取得処理により、モバイル端末２０は、未取得の取引明細をＩＢサーバ３０からほぼ定期的に取得することができる。しかしながら、例えば、モバイル端末２０の電源がＯＦＦであったり、モバイル端末２０が故障していたり、またはユーザによる設定が不適切であるなどの理由により、未取得の取引明細の取得漏れが生じる恐れがある。
【００４７】
通常、ＩＢサーバ３０では、取引明細の保存期間が例えば数か月など所定の期間に定められている。このため、未取得のまま取引明細の保存期限が経過した場合には、モバイル端末２０は、該当の取引明細を取得できなくなる。
【００４８】
そこで、上記事情を一着眼点にして本実施形態によるＷＥＢ・ＤＢサーバ１０を創作するに至った。本実施形態によるＷＥＢ・ＤＢサーバ１０は、利用者の取引履歴を過不足なくモバイル端末２０に取得させることが可能である。
【００４９】
＜＜２．実施形態の詳細な説明＞＞
＜２−１．構成＞
次に、本実施形態による構成について詳細に説明する。図４は、本実施形態によるＷＥＢ・ＤＢサーバ１０の構成を示した機能ブロック図である。図４に示したように、ＷＥＢ・ＤＢサーバ１０は、制御部１００、通信部１２０、および記憶部１２２を有する。
【００５０】
［２−１−１．制御部１００］
制御部１００は、ＷＥＢ・ＤＢサーバ１０に内蔵される、後述するＣＰＵ（Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）１５０、ＲＡＭ（Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ）１５４などのハードウェアを用いて、ＷＥＢ・ＤＢサーバ１０の動作を全般的に制御する。また、図４に示したように、制御部１００は、未取得履歴有無判定部１０２、判断部１０４、送信制御部１０６、およびデータベース管理部１０８を有する。
【００５１】
［２−１−２．未取得履歴有無判定部１０２］
未取得履歴有無判定部１０２は、ＩＢサーバ３０に記憶されているモバイル端末２０のユーザの取引明細のうちモバイル端末２０が未取得の取引明細が有るか否かを判定する。例えば、未取得履歴有無判定部１０２は、まず、モバイル端末２０のユーザの取引明細のうち未取得の取引明細の有無の問合せをＩＢサーバ３０へ通信部１２０に送信させる。そして、未取得履歴有無判定部１０２は、ＩＢサーバ３０から受信される回答結果に基づいて、未取得の取引明細が有るか否かを判定する。
【００５２】
［２−１−３．判断部１０４］
判断部１０４は、取引明細の取得に関する所定の条件が満たされているか否かを判断する。
【００５３】
（２−１−３−１．判断例１）
例えば、判断部１０４は、モバイル端末２０の電源がＯＮからＯＦＦに切り替えられるなど、モバイル端末２０における取引明細の取得機能が停止したことがモバイル端末２０から通知されたか否かを判断する。
【００５４】
この判断例１によれば、モバイル端末２０における取引明細の取得機能が停止したことを検知することにより、モバイル端末２０の未取得の取引明細の保存期限切れが発生する恐れがあることを検知することができる。
【００５５】
（２−１−３−２．判断例２）
または、判断部１０４は、モバイル端末２０が取引明細を前回取得した時から所定の期間が経過したか否かを判断する。
【００５６】
この判断例２によれば、モバイル端末２０が取引明細を前回取得した時から所定の期間が経過したことを検知することにより、未取得の取引明細が長期間取得されておらず、未取得の取引明細の保存期限切れが発生する恐れがあることを検知することができる。
【００５７】
（２−１−３−３．判断例３）
または、判断部１０４は、事前に定められた取引明細の次回取得予定日時を現在が経過したか否かを判断する。
【００５８】
この判断例３によれば、事前に定められた取引明細の次回取得予定日時を現在が経過したことを検知することにより、未取得の取引明細が予定通りに取得されてはおらず、未取得の取引明細の保存期限切れが発生する恐れがあることを検知することができる。
【００５９】
（２−１−３−４．判断例４）
または、判断部１０４は、モバイル端末２０のユーザの取引明細のうち未取得の取引明細が次回の取得前に消去されるか否かを判断する。より詳細には、判断部１０４は、ＩＢサーバ３０における未取得の取引明細の保存期限日時と、事前に定められた、次回の取得予定日時とを比較することにより、未取得の取引明細が取得前に消去されるか否かを判断する。
【００６０】
この判断例４によれば、次回の取得予定日時が未取得の取引明細の保存期限日時よりも後になっていることを検知することにより、モバイル端末２０の未取得の取引明細の保存期限切れが発生する恐れがあることを検知することができる。
【００６１】
なお、変形例として、判断部１０４は、上記の判断例１〜判断例４のうち２個以上をＯＲ条件またはＡＮＤ条件により組み合わせて判断することも可能である。
【００６２】
［２−１−４．送信制御部１０６］
送信制御部１０６は、モバイル端末２０から受信される取引明細の取得要求に応じて、後述する明細保存ＤＢ１２６に記録されているモバイル端末２０のユーザの取引明細をモバイル端末２０へ通信部１２０に送信させる。
【００６３】
また、送信制御部１０６は、取引明細の取得に関する所定の条件が満たされていると判断部１０４により判断された場合には、取引明細の取得要求をＩＢサーバ３０へ通信部１２０に送信させる。例えば、送信制御部１０６は、未取得の取引明細のうち次回の取得予定日時を経過したと判断部１０４により判断された取引明細の取得要求をＩＢサーバ３０へ通信部１２０に送信させる。または、送信制御部１０６は、未取得の取引明細のうちモバイル端末２０の次回の取得前に消去されると判断部１０４により判断された取引明細の取得要求をＩＢサーバ３０へ通信部１２０に送信させる。
【００６４】
［２−１−５．データベース管理部１０８］
データベース管理部１０８は、本発明における取引履歴管理部の一例である。データベース管理部１０８は、後述するユーザＤＢ１２４および明細保存ＤＢ１２６に対して、データの記録、抽出、または削除などの管理を行う。例えば、データベース管理部１０８は、明細保存ＤＢ１２６に記憶されている取引明細が送信制御部１０６によりモバイル端末２０へ送信された場合には、送信された取引明細を明細保存ＤＢ１２６から削除する。
【００６５】
なお、ユーザＤＢ１２４は、モバイル端末２０ごとのユーザ名、明細取得の設定内容、および明細取得状況を記憶するためのデータベースである。また、明細保存ＤＢ１２６は、ＩＢサーバ３０から受信された、モバイル端末２０のユーザの取引明細を一時的に保存するためのデータベースである。
【００６６】
（２−１−５−１．ユーザＤＢ１２４）
ここで、図５を参照して、ユーザＤＢ１２４の構成例について説明する。図５に示したように、ユーザＤＢ１２４では、例えば、ユーザ名１２４０、サービス状態１２４２、明細取得方法１２４４、次回明細取得予定日時１２４６、前回明細取得日時１２４８、ＩＢ未取得明細保存期限１２５０、および、明細一時保存１２５２が対応づけて記録される。ここで、ユーザ名１２４０には、各モバイル端末２０のユーザの名前が記録される。また、サービス状態１２４２には、該当のモバイル端末２０のサービス状態が記録される。また、明細取得方法１２４４には、該当のモバイル端末２０が取引明細をＩＢサーバ３０から自動取得するか手動取得するかの区別が記録される。また、次回明細取得予定日時１２４６には、該当のモバイル端末２０が取引明細をＩＢサーバ３０から次回取得する予定の日時が記録される。また、前回明細取得日時１２４８には、該当のモバイル端末２０が取引明細をＩＢサーバ３０から前回取得した日時が記録される。また、ＩＢ未取得明細保存期限１２５０には、該当のモバイル端末２０の未取得の取引明細の保存期限が記録される。なお、未取得の取引明細が複数存在する場合には、複数の保存期限のうち最も早い保存期限が記録される。また、明細一時保存１２５２には、該当のモバイル端末２０のユーザの取引明細が１件以上明細保存ＤＢ１２６に記録されているか否かが記録される。
【００６７】
例えば、図５に示した１レコード目のデータは、該当のモバイル端末２０に関して、ユーザ名は「ユーザＡ」であり、サービス状態は「終了」しており、明細取得方法は「自動取得」が設定されており、モバイル端末２０による次回の取引明細の取得予定日時は「２０１４年２月２６日  １２：０５」であり、モバイル端末２０による前回の明細取得日時は「２０１４年２月２６日  １１：０５」であり、未取得の取引明細の保存期限は「２０１４年３月２日  ２３：５９」であり、そして、該当のモバイル端末２０のユーザの取引明細が１件以上明細保存ＤＢ１２６に記録されていることを示している。
【００６８】
（２−１−５−２．明細保存ＤＢ１２６）
次に、図６を参照して、明細保存ＤＢ１２６の構成例について説明する。図６に示したように、明細保存ＤＢ１２６では、例えば、ユーザ名１２６０、取引日時１２６２、取引内容１２６４、支払金額１２６６、預り金額１２６８、差引残高１２７０、および、備考１２７２が対応づけて記録される。ここで、取引日時１２６２、取引内容１２６４、支払金額１２６６、預り金額１２６８、差引残高１２７０、および、備考１２７２にはそれぞれ、該当の取引明細に含まれる取引日時、取引内容、支払金額、預り金額、口座の差引残高、および備考欄の内容が記録される。
【００６９】
例えば、図６に示した１レコード目のデータは、該当のユーザ名は「ユーザＡ」であり、該当の取引明細に含まれる取引日時が「２０１４年２月２６日  １２：１５」であり、取引内容が「支払」であり、支払金額が「２，０００円」であり、口座の差引残高が「２００，０００円」であり、備考欄の内容が「ガス料金」であることをそれぞれ示している。
【００７０】
［２−１−６．通信部１２０］
通信部１２０は、本発明における取得部の一例である。通信部１２０は、通信網１２を介して、他の装置との間で情報の送受信を行う。例えば、通信部１２０は、送信制御部１０６の制御に従って、モバイル端末２０のユーザの取引明細の取得要求をＩＢサーバ３０へ送信する。また、通信部１２０は、明細保存ＤＢ１２６に記録されている取引明細の取得要求をモバイル端末２０から受信する。
【００７１】
［２−１−７．記憶部１２２］
記憶部１２２は、例えばユーザＤＢ１２４や明細保存ＤＢ１２６などの各種データや、ソフトウェアを記憶する。
【００７２】
＜２−２．動作＞
以上、本実施形態による構成について説明した。続いて、本実施形態による動作について、「２−２−１．動作例１」〜「２−２−４．動作例４」において説明を行う。なお、以下では、モバイル端末２０のユーザの未取得の取引明細をＷＥＢ・ＤＢサーバ１０が代行取得する場面における動作の例について説明する。
【００７３】
［２−２−１．動作例１］
図７は、本実施形態による動作例１を示したシーケンス図である。なお、この動作例１は、２−１−３−１節で述べた判断例１に対応する動作例である。
【００７４】
図７に示したように、まず、ＷＥＢ・ＤＢサーバ１０の判断部１０４は、ユーザＤＢ１２４の登録内容を確認し、モバイル端末２０のサービス状態が終了しているユーザがいるか否かを判断する（Ｓ１０１）。
【００７５】
サービス状態が終了しているユーザがいない場合には（Ｓ１０１：Ｎｏ）、ＷＥＢ・ＤＢサーバ１０は、後述するＳ１０９の動作を行う。一方、サービス状態が終了しているユーザがいる場合には（Ｓ１０１：Ｙｅｓ）、未取得履歴有無判定部１０２は、該当のユーザ一人ひとりに関して、未取得の取引明細の有無の問合せをＩＢサーバ３０へ通信部１２０に送信させる（Ｓ１０２）。
【００７６】
その後、ＩＢサーバ３０は、受信された問合せに基づいて、該当のユーザの未取得の取引明細が有るか否かを確認する（Ｓ１０３）。そして、ＩＢサーバ３０は、確認結果をＷＥＢ・ＤＢサーバ１０へ送信する（Ｓ１０４）。
【００７７】
その後、未取得履歴有無判定部１０２は、受信された確認結果に基づいて、未取得の取引明細が有るか否かを判定する（Ｓ１０５）。未取得の取引明細がない場合には（Ｓ１０５：Ｎｏ）、ＷＥＢ・ＤＢサーバ１０は、後述するＳ１０９の動作を行う。
【００７８】
一方、未取得の取引明細がある場合には（Ｓ１０５：Ｙｅｓ）、該当のユーザの未取得の取引明細の取得要求をＩＢサーバ３０へ通信部１２０に送信させる（Ｓ１０６）。その後、ＩＢサーバ３０は、受信された取引明細の取得要求に基づいて、該当のユーザの未取得の取引明細を抽出し、そして、抽出した取引明細をＷＥＢ・ＤＢサーバ１０へ送信する（Ｓ１０７）。
【００７９】
その後、ＷＥＢ・ＤＢサーバ１０のデータベース管理部１０８は、ＩＢサーバ３０から受信された取引明細を、該当のユーザ名と対応づけて明細保存ＤＢ１２６に追加記録する（Ｓ１０８）。例えば、図５に示したユーザＤＢ１２４の例では、サービス状態が終了しているユーザは、ユーザＡだけであるので、ＷＥＢ・ＤＢサーバ１０は、まず、ユーザＡの未取得の取引明細をＩＢサーバ３０から受信する。そして、データベース管理部１０８は、図６に示したように、受信されたユーザＡの取引明細を明細保存ＤＢ１２６に追加記録する。
【００８０】
その後、ＷＥＢ・ＤＢサーバ１０は、一定時間待機する（Ｓ１０９）。そして、ＷＥＢ・ＤＢサーバ１０は、Ｓ１０１の動作を再び繰り返す。
【００８１】
Ｓ１０１〜Ｓ１０９の動作の途中において、モバイル端末２０は、例えば、スマートフォン通帳アプリをモバイル端末２０にインストールした直後、またはモバイル端末２０のＯＳが通常に起動した際などに、スマートフォン通帳サービスを起動する（Ｓ１１０）。
【００８２】
続いて、モバイル端末２０は、自動的、またはユーザの操作により、取引明細の取得要求をＷＥＢ・ＤＢサーバ１０へ送信する（Ｓ１１１）。その後、ＷＥＢ・ＤＢサーバ１０のデータベース管理部１０８は、該当のモバイル端末２０のユーザの取引明細を明細保存ＤＢ１２６から全て抽出する。そして、送信制御部１０６は、抽出された取引明細をモバイル端末２０へ通信部１２０に送信させる（Ｓ１１２）。そして、データベース管理部１０８は、抽出した取引明細を全て明細保存ＤＢ１２６から削除する（Ｓ１１３）。
【００８３】
その後、モバイル端末２０は、取引明細の取得結果を記録するとともに、受信された取引明細を自端末に保存する（Ｓ１１４）。
【００８４】
［２−２−２．動作例２］
また、図８は、本実施形態による動作例２を示したシーケンス図である。なお、この動作例２は、２−１−３−２節で述べた判断例２に対応する動作の例である。
【００８５】
図８に示したように、まず、ＷＥＢ・ＤＢサーバ１０の判断部１０４は、ユーザＤＢ１２４の登録内容を確認し、明細取得方法が手動取得に設定されているユーザがいるか否かを判断する（Ｓ２０１）。
【００８６】
明細取得方法が手動取得に設定されているユーザがいない場合には（Ｓ２０１：Ｎｏ）、ＷＥＢ・ＤＢサーバ１０は、後述するＳ２１０の動作を行う。一方、明細取得方法が手動取得に設定されているユーザがいる場合には（Ｓ２０１：Ｙｅｓ）、判断部１０４は、次に、現在が所定の日時に該当するか否かを判断する（Ｓ２０２）。現在が所定の日時に該当しない場合には（Ｓ２０２：Ｎｏ）、ＷＥＢ・ＤＢサーバ１０は、後述するＳ２１０の動作を行う。
【００８７】
一方、現在が所定の日時に該当する場合には（Ｓ２０２：Ｙｅｓ）、未取得履歴有無判定部１０２は、該当のユーザ一人ひとりに関して、未取得の取引明細の有無の問合せをＩＢサーバ３０へ通信部１２０に送信させる（Ｓ２０３）。
【００８８】
なお、図８に示したＳ２０４〜Ｓ２０８の動作は、図７におけるＳ１０３〜Ｓ１０７と同様である。
【００８９】
その後、ＷＥＢ・ＤＢサーバ１０のデータベース管理部１０８は、ＩＢサーバ３０から受信された取引明細を、該当のユーザ名と対応づけて明細保存ＤＢ１２６に追加記録する（Ｓ２０９）。例えば、図５に示したユーザＤＢ１２４の例では、明細取得方法が手動取得に設定されているユーザは、ユーザＢだけであるので、ＷＥＢ・ＤＢサーバ１０は、まず、ユーザＢの未取得の取引明細をＩＢサーバ３０から受信する。そして、データベース管理部１０８は、図９に示したように、受信されたユーザＢの取引明細を明細保存ＤＢ１２６に追加記録する。
【００９０】
その後、ＷＥＢ・ＤＢサーバ１０は、一定時間待機する（Ｓ２１０）。そして、ＷＥＢ・ＤＢサーバ１０は、Ｓ２０１の動作を再び繰り返す。
【００９１】
Ｓ２０１〜Ｓ２１０の動作の途中において、モバイル端末２０は、ユーザによる操作に応じて、スマートフォン通帳アプリを起動する（Ｓ２１１）。続いて、モバイル端末２０は、ユーザによる操作により、取引明細の取得要求をＷＥＢ・ＤＢサーバ１０へ送信する（Ｓ２１２）。
【００９２】
なお、図８に示したＳ２１３〜Ｓ２１５の動作は、図７におけるＳ１１２〜Ｓ１１４と同様である。
【００９３】
［２−２−３．動作例３］
また、図１０は、本実施形態による動作例３を示したシーケンス図である。なお、この動作例３は、２−１−３−３節で述べた判断例３に対応する動作例である。
【００９４】
図１０に示したように、まず、ＷＥＢ・ＤＢサーバ１０の判断部１０４は、ユーザＤＢ１２４の登録内容を確認し、明細取得方法が自動取得に設定されているユーザがいるか否かを判断する（Ｓ３０１）。
【００９５】
明細取得方法が自動取得に設定されているユーザがいない場合には（Ｓ３０１：Ｎｏ）、ＷＥＢ・ＤＢサーバ１０は、後述するＳ３１０の動作を行う。一方、明細取得方法が自動取得に設定されているユーザがいる場合には（Ｓ３０１：Ｙｅｓ）、判断部１０４は、次に、ユーザＤＢ１２４の登録内容を確認し、各ユーザに対応づけて登録されている次回の明細取得予定日時を現在が経過しているユーザがいるか否かを判断する（Ｓ３０２）。全てのユーザの次回の明細取得予定日時を現在が経過していない場合には（Ｓ３０２：Ｎｏ）、ＷＥＢ・ＤＢサーバ１０は、後述するＳ３１０の動作を行う。
【００９６】
一方、いずれかのユーザの次回の明細取得予定日時を現在が経過している場合には（Ｓ３０２：Ｙｅｓ）、未取得履歴有無判定部１０２は、該当のユーザ一人ひとりに関して、未取得の取引明細の有無の問合せをＩＢサーバ３０へ通信部１２０に送信させる（Ｓ３０３）。
【００９７】
なお、図１０に示したＳ３０４〜Ｓ３０８の動作は、図７におけるＳ１０３〜Ｓ１０７と同様である。
【００９８】
その後、ＷＥＢ・ＤＢサーバ１０のデータベース管理部１０８は、ＩＢサーバ３０から受信された取引明細を、該当のユーザ名と対応づけて明細保存ＤＢ１２６に追加記録する（Ｓ３０９）。例えば、図５に示したユーザＤＢ１２４の例において、仮に現在が「２０１４年２月２５日  １３：００」である場合には、明細取得方法が自動取得に設定されており、かつ、次回の明細取得予定日時を現在が経過しているユーザは、ユーザＣだけである。このため、ＷＥＢ・ＤＢサーバ１０は、まず、ユーザＣの未取得の取引明細をＩＢサーバ３０から受信する。そして、データベース管理部１０８は、図１１に示したように、受信されたユーザＣの取引明細を明細保存ＤＢ１２６に追加記録する。
【００９９】
その後、ＷＥＢ・ＤＢサーバ１０は、一定時間待機する（Ｓ３１０）。そして、ＷＥＢ・ＤＢサーバ１０は、Ｓ３０１の動作を再び繰り返す。
【０１００】
Ｓ３０１〜Ｓ３１０の動作の途中において、モバイル端末２０は、図７におけるＳ１１０と同様に、スマートフォン通帳サービスを起動する（Ｓ３１１）。なお、図１０に示したＳ３１２〜Ｓ３１５の動作は、図７におけるＳ１１１〜Ｓ１１４と同様である。
【０１０１】
［２−２−４．動作例４］
また、図１２は、本実施形態による動作例４を示したシーケンス図である。なお、この動作例４は、２−１−３−４節で述べた判断例４に対応する動作例である。
【０１０２】
図１２に示したように、まず、ＷＥＢ・ＤＢサーバ１０の判断部１０４は、ユーザＤＢ１２４の登録内容を確認し、明細取得方法が自動取得に設定されているユーザがいるか否かを判断する（Ｓ４０１）。
【０１０３】
明細取得方法が自動取得に設定されているユーザがいない場合には（Ｓ４０１：Ｎｏ）、ＷＥＢ・ＤＢサーバ１０は、後述するＳ４１０の動作を行う。一方、明細取得方法が自動取得に設定されているユーザがいる場合には（Ｓ４０１：Ｙｅｓ）、未取得履歴有無判定部１０２は、該当のユーザ一人ひとりに関して、未取得の取引明細の有無の問合せをＩＢサーバ３０へ通信部１２０に送信させる（Ｓ４０２）。
【０１０４】
なお、図１２に示したＳ４０３〜Ｓ４０７の動作は、図７におけるＳ１０３〜Ｓ１０７と同様である。
【０１０５】
その後、ＷＥＢ・ＤＢサーバ１０の判断部１０４は、ＩＢサーバ３０から受信された取引明細のうち、各ユーザに対応づけて登録されている次回の明細取得予定日時が、取引明細の保存期限よりも後である取引明細が存在するか否かを判断する（Ｓ４０８）。次回の明細取得予定日時が保存期限よりも後である取引明細が存在しない場合には（Ｓ４０８：Ｎｏ）、ＷＥＢ・ＤＢサーバ１０は、後述するＳ４１０の動作を行う。
【０１０６】
一方、次回の明細取得予定日時が保存期限よりも後である取引明細が存在する場合には（Ｓ４０８：Ｙｅｓ）、データベース管理部１０８は、該当の取引明細を、該当のユーザ名と対応づけて明細保存ＤＢ１２６に追加記録する（Ｓ４０９）。例えば、図５に示したユーザＤＢ１２４の例では、明細取得方法が自動取得に設定されており、かつ、次回の明細取得予定日時が、未取得の取引明細の保存期限よりも後であるユーザは、ユーザＤだけであるので、ＷＥＢ・ＤＢサーバ１０は、まず、ユーザＤの未取得の取引明細をＩＢサーバ３０から受信する。そして、データベース管理部１０８は、図１３に示したように、受信されたユーザＤの取引明細を明細保存ＤＢ１２６に追加記録する。
【０１０７】
その後、ＷＥＢ・ＤＢサーバ１０は、一定時間待機する（Ｓ４１０）。そして、ＷＥＢ・ＤＢサーバ１０は、Ｓ４０１の動作を再び繰り返す。
【０１０８】
Ｓ４０１〜Ｓ４１０の動作の途中において、モバイル端末２０は、図７におけるＳ１１０と同様に、スマートフォン通帳サービスを起動する（Ｓ４１１）。なお、図１２に示したＳ４１２〜Ｓ４１５の動作は、図７におけるＳ１１１〜Ｓ１１４と同様である。
【０１０９】
＜２−３．効果＞
以上、例えば図４、図７、図８、図１０、および図１２等を参照して説明したように、本実施形態によるＷＥＢ・ＤＢサーバ１０は、取引明細の取得に関する条件が満たされた場合に、ＩＢサーバ３０に記憶されているモバイル端末２０のユーザの取引明細のうちモバイル端末２０が未取得の取引明細をＩＢサーバ３０から取得し、そして、取得された取引明細を、モバイル端末２０から受信される要求に応じてモバイル端末２０へ送信させる。
【０１１０】
つまり、モバイル端末２０が未取得の取引明細をＷＥＢ・ＤＢサーバ１０が代行取得するので、仮にモバイル端末２０の電源がＯＦＦであったり、モバイル端末２０が故障している場合であっても、未取得の取引明細の取得漏れを防止することができる。その結果、モバイル端末２０に表示される取引明細の一覧画面において、一部の取引明細の表示抜けが発生することを防止することができる。
【０１１１】
例えば、ＷＥＢ・ＤＢサーバ１０は、モバイル端末２０の次回の取得予定日時が、ＩＢサーバ３０における未取得の取引明細の保存期限よりも後になっている場合には、未取得の取引明細をＩＢサーバ３０から取得する。このため、未取得の取引明細がモバイル端末２０により取得される前に消去される事象を確実に防止することができる。
【０１１２】
また、ＷＥＢ・ＤＢサーバ１０は、明細保存ＤＢ１２６に記憶されている取引明細がモバイル端末２０へ送信された場合には、送信された取引明細を明細保存ＤＢ１２６から削除する。このため、ＷＥＢ・ＤＢサーバ１０により代行取得された取引明細が明細保存ＤＢ１２６に長期間残り続けることを防止できるので、例えば悪意のある人物により明細保存ＤＢ１２６から取引明細が取得されるリスクを低く抑えることができる。
【０１１３】
＜＜３．ハードウェア構成＞＞
以上、本発明の実施形態について説明した。次に、本実施形態によるＷＥＢ・ＤＢサーバ１０のハードウェア構成について、図１４を参照して説明する。図１４に示したように、ＷＥＢ・ＤＢサーバ１０は、ＣＰＵ１５０、ＲＯＭ（Ｒｅａｄ  Ｏｎｌｙ  Ｍｅｍｏｒｙ）１５２、ＲＡＭ１５４、内部バス１５６、入出力インターフェース１５８、ＨＤＤ（Ｈａｒｄ  Ｄｉｓｋ  Ｄｒｉｖｅ）１６０、およびネットワークインターフェース１６２を備える。
【０１１４】
＜３−１．ＣＰＵ１５０＞
ＣＰＵ１５０は、演算処理装置および制御装置として機能し、各種プログラムに従ってＷＥＢ・ＤＢサーバ１０内の動作全般を制御する。また、ＣＰＵ１５０は、ＷＥＢ・ＤＢサーバ１０において制御部１００の機能を実現する。なお、ＣＰＵ１５０は、マイクロプロセッサなどのプロセッサにより構成される。
【０１１５】
＜３−２．ＲＯＭ１５２＞
ＲＯＭ１５２は、ＣＰＵ１５０が使用するプログラムや演算パラメータ等を記憶する。
【０１１６】
＜３−３．ＲＡＭ１５４＞
ＲＡＭ１５４は、ＣＰＵ１５０の実行において使用するプログラムや、その実行において適宜変化するパラメータ等を一時記憶する。
【０１１７】
＜３−４．内部バス１５６＞
内部バス１５６は、ＣＰＵバスなどから構成される。この内部バス１５６は、ＣＰＵ１５０、ＲＯＭ１５２、およびＲＡＭ１５４を相互に接続する。
【０１１８】
＜３−５．入出力インターフェース１５８＞
入出力インターフェース１５８は、ＨＤＤ１６０、およびネットワークインターフェース１６２を、内部バス１５６と接続する。例えばＨＤＤ１６０は、この入出力インターフェース１５８および内部バス１５６を介して、ＲＡＭ１５４などとの間でデータをやり取りする。
【０１１９】
＜３−６．ＨＤＤ１６０＞
ＨＤＤ１６０は、記憶部１２２として機能する、データ格納用の装置である。このＨＤＤ１６０は、例えば、記憶媒体、記憶媒体にデータを記録する記録装置、記憶媒体からデータを読み出す読出し装置、および記憶媒体に記録されたデータを削除する削除装置などを含む。また、ＨＤＤ１６０は、ＣＰＵ１５０が実行するプログラムや各種データを格納する。
【０１２０】
＜３−７．ネットワークインターフェース１６２＞
ネットワークインターフェース１６２は、例えばインターネットなどの通信網に接続するための通信デバイス等で構成された通信インターフェースである。このネットワークインターフェース１６２は、通信部１２０として機能する。なお、ネットワークインターフェース１６２は、無線ＬＡＮ対応通信装置、ＬＴＥ（Ｌｏｎｇ  Ｔｅｒｍ  Ｅｖｏｌｕｔｉｏｎ）対応通信装置、または有線による通信を行うワイヤー通信装置であってもよい。
【０１２１】
＜＜４．変形例＞＞
なお、添付図面を参照しながら本発明の好適な実施形態について詳細に説明したが、本発明はかかる例に限定されない。本発明の属する技術の分野における通常の知識を有する者であれば、特許請求の範囲に記載された技術的思想の範疇内において、各種の変更例または修正例に想到し得ることは明らかであり、これらについても、当然に本発明の技術的範囲に属するものと了解される。
【０１２２】
＜４−１．変形例１＞
例えば、上記の動作例４では、Ｓ４０６〜Ｓ４０８において、ＷＥＢ・ＤＢサーバ１０（の判断部１０４）が、ＩＢサーバ３０から受信される取引明細のうち、次回の明細取得予定日時が、取引明細の保存期限よりも後である取引明細が存在するか否かを判断する例について説明したが、かかる例に限定されない。Ｓ４０６〜Ｓ４０８の変形例として、ＷＥＢ・ＤＢサーバ１０の代わりに、ＩＢサーバ３０が、次回の明細取得予定日時が、取引明細の保存期限よりも後である取引明細が存在するか否かを判断し、そして、該当する取引明細だけをＷＥＢ・ＤＢサーバ１０へ送信することも可能である。
【０１２３】
より具体的には、まず、ＷＥＢ・ＤＢサーバ１０の送信制御部１０６は、Ｓ４０５の条件を満たすユーザに関する、次回の明細取得予定日時が保存期限よりも後である取引明細の取得要求をＩＢサーバ３０へ通信部１２０に送信させる。
【０１２４】
その後、ＩＢサーバ３０は、受信された取得要求に基づいて、各ユーザに対応づけて登録されている次回の明細取得予定日時が、取引明細の保存期限よりも後である取引明細が存在するか否かを確認する。そして、次回の明細取得予定日時が保存期限よりも後である取引明細が存在する場合には、ＩＢサーバ３０は、該当の取引明細を全て抽出し、そして、抽出した取引明細をＷＥＢ・ＤＢサーバ１０へ送信する。
【０１２５】
＜４−２．変形例２＞
また、２−２節で述べたＳ１１２（または、Ｓ２１３、Ｓ３１３、Ｓ４１３）の変形例として、以下のような動作も適用可能である。まず、ＷＥＢ・ＤＢサーバ１０の送信制御部１０６は、モバイル端末２０が未取得の取引明細のうち明細保存ＤＢ１２６に記憶されていない取引明細（つまり、Ｓ１１２の時点においてＷＥＢ・ＤＢサーバ１０がＩＢサーバ３０から未取得の取引明細）の取得要求をＩＢサーバ３０へ通信部１２０に送信する。
【０１２６】
その後、ＩＢサーバ３０は、該当のユーザの未取得の取引明細のうちＷＥＢ・ＤＢサーバ１０へ送信していない取引明細が有るか否かを確認する。そして、送信していない取引明細が有る場合には、ＩＢサーバ３０は、該当の取引明細をＷＥＢ・ＤＢサーバ１０へ送信する。
【０１２７】
そして、ＷＥＢ・ＤＢサーバ１０の送信制御部１０６は、明細保存ＤＢ１２６から抽出した取引明細に加えて、ＩＢサーバ３０から受信された取引明細をモバイル端末２０へ通信部１２０に送信させることが可能である。
【０１２８】
＜４−３．変形例３＞
また、２−２節で述べた動作例１〜動作例４における各ステップは、必ずしも記載された順序に沿って処理されなくてもよい。例えば、各ステップは、適宜順序が変更されて処理されてもよい。また、ＷＥＢ・ＤＢサーバ１０は、動作例１〜動作例４における各ステップを適宜組み合わせて処理することも可能である。
【０１２９】
＜４−４．変形例４＞
また、本実施形態によれば、ＣＰＵ１５０、ＲＯＭ１５２、およびＲＡＭ１５４などのハードウェアを、上述したＷＥＢ・ＤＢサーバ１０の各構成と同等の機能を発揮させるためのコンピュータプログラムも提供可能である。また、該コンピュータプログラムが記録された記録媒体も提供される。
【符号の説明】
【０１３０】
１０  ＷＥＢ・ＤＢサーバ
１２  通信網
２０  モバイル端末
３０  ＩＢサーバ
１００  制御部
１０２  未取得履歴有無判定部
１０４  判断部
１０６  送信制御部
１０８  データベース管理部
１２０  通信部
１２２  記憶部
１５０  ＣＰＵ
１５２  ＲＯＭ
１５４  ＲＡＭ
１５６  内部バス
１５８  入出力インターフェース
１６０  ＨＤＤ
１６２  ネットワークインターフェース
【図１】
2016021128.tif 000003
【図２】
2016021128.tif 000004
【図３】
2016021128.tif 000005
【図４】
2016021128.tif 000006
【図５】
2016021128.tif 000007
【図６】
2016021128.tif 000008
【図７】
2016021128.tif 000009
【図８】
2016021128.tif 000010
【図９】
2016021128.tif 000011
【図１０】
2016021128.tif 000012
【図１１】
2016021128.tif 000013
【図１２】
2016021128.tif 000014
【図１３】
2016021128.tif 000015
【図１４】
2016021128.tif 000016