JP6511749B2 - 情報処理装置及び情報処理プログラム - Google Patents

Description

本発明は、情報処理装置及び情報処理プログラムに関する。

特許文献１には、電子帳票サーバーの負荷及びネットワークの負荷を軽減することを目的とし、電子帳票に係るデータを格納するデータ格納手段と、クライアント情報を管理するクライアント情報管理手段と、クライアントからの電子帳票に対する操作要求に応じて、操作要求の目的となるクライアント情報を、クライアントに送信するクライアント情報送信手段と、クライアントからの電子帳票に係るデータの取得要求に応じて、電子帳票に係るデータを、クライアントに送信するデータ送信手段と、を有することが開示されている。

特許文献２には、システムのリソースの使用量を減少させることを目的とし、帳票ドキュメントセットを読み込む読込手段と、操作画面を介したユーザー操作に応じて、帳票ドキュメントセットに含まれるデータ取得指示情報を編集するデータ取得指示情報編集手段と、帳票ドキュメントセットに含まれるデータ取得指示情報に、保存手段に保存されている、編集前のデータ取得指示情報と、編集後のデータ取得指示情報との相違を示す相違情報を適用してデータ取得指示情報を更新する更新手段と、を有し、更新手段が更新したデータ取得指示情報と、帳票ドキュメントセット内の帳票テンプレートと、を組み合わせ、新たな帳票ドキュメントセットを作成することが開示されている。

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

従来は、クライアントに提供する電子帳票のデータを、内容にかかわらず一律にバッチで生成するか、もしくは要求に応じてオンデマンドで生成するかのどちらかであった。一律にバッチで生成すると、サーバーの記憶領域を圧迫し、また、一律にオンデマンドで生成すると、データの生成に時間がかかる。
本発明は、金銭の請求又は支払を示す情報を表示するための表示情報を生成するのに、当該情報が金銭の請求又は支払の概要を示す情報であるか、明細を示す情報であるかに応じて、生成するタイミングを異ならせるようにした情報処理装置及び情報処理プログラムを提供することを目的としている。

かかる目的を達成するための本発明の要旨とするところは、次の各項の発明に存する。
請求項１の発明は、金銭の請求又は支払の概要を示す第１の情報と該第１の情報の明細を示す第２の情報を記憶する記憶手段と、前記第１の情報を表示するための表示情報を、該第１の情報に対する要求がある前に予め生成する第１の生成手段と、前記第２の情報を表示するための表示情報を、該第２の情報に対する要求があった後に生成する第２の生成手段と、前記第１の情報又は前記第２の情報内の予め定められた項目の金額が閾値である額よりも高い又は以上である場合は、該第２の情報を表示するための表示情報を、該第２の情報に対する要求がある前に予め生成する第３の生成手段を具備することを特徴とする情報処理装置である。

請求項２の発明は、前記閾値である額を、前記第２の情報に対する過去の要求における前記予め定められた項目の金額に対する統計的処理によって算出する算出手段をさらに具備することを特徴とする請求項１に記載の情報処理装置である。

請求項３の発明は、コンピュータを、金銭の請求又は支払の概要を示す第１の情報と該第１の情報の明細を示す第２の情報を記憶する記憶手段と、前記第１の情報を表示するための表示情報を、該第１の情報に対する要求がある前に予め生成する第１の生成手段と、前記第２の情報を表示するための表示情報を、該第２の情報に対する要求があった後に生成する第２の生成手段と、前記第１の情報又は前記第２の情報内の予め定められた項目の金額が閾値である額よりも高い又は以上である場合は、該第２の情報を表示するための表示情報を、該第２の情報に対する要求がある前に予め生成する第３の生成手段として機能させるための情報処理プログラムである。

請求項１の情報処理装置によれば、金銭の請求又は支払を示す情報を表示するための表示情報を生成するのに、当該情報が金銭の請求又は支払の概要を示す情報であるか、明細を示す情報であるかに応じて、生成するタイミングを異ならせるようにすることができる。また、予め定められた項目の金額が閾値である額よりも高い又は以上である場合は、第２の情報を表示するための表示情報を、第２の情報に対する要求がある前に予め生成することができる。

請求項２の情報処理装置によれば、閾値である額を、第２の情報に対する過去の要求における予め定められた項目の金額に対して統計的処理によって算出することができる。

請求項３の情報処理プログラムによれば、金銭の請求又は支払を示す情報を表示するための表示情報を生成するのに、当該情報が金銭の請求又は支払の概要を示す情報であるか、明細を示す情報であるかに応じて、生成するタイミングを異ならせるようにすることができる。また、予め定められた項目の金額が閾値である額よりも高い又は以上である場合は、第２の情報を表示するための表示情報を、第２の情報に対する要求がある前に予め生成することができる。

本実施の形態の構成例についての概念的なモジュール構成図である。 本実施の形態を実現させた場合のシステム構成例を示す説明図である。 本実施の形態による処理例を示すフローチャートである。 本実施の形態による処理例を示すフローチャートである。 本実施の形態による処理例を示すフローチャートである。 本実施の形態による処理例を示すフローチャートである。 本実施の形態による処理例を示すフローチャートである。 本実施の形態による処理例を示すフローチャートである。 本実施の形態による処理例を示すフローチャートである。 本実施の形態による処理例を示すフローチャートである。 請求書データテーブル、明細データテーブル等のデータ構造例を示す説明図である。 閾値マスターテーブルのデータ構造例を示す説明図である。 ユーザー操作記録テーブルのデータ構造例を示す説明図である。 請求書データテーブルのデータ構造例を示す説明図である。 請求書データテーブルのデータ構造例を示す説明図である。 請求書データテーブルのデータ構造例を示す説明図である。 ユーザー操作記録テーブルのデータ構造例を示す説明図である。 請求書ダウンロード指定画面の表示例を示す説明図である。 本実施の形態を実現するコンピュータのハードウェア構成例を示すブロック図である。

以下、図面に基づき本発明を実現するにあたっての好適な一実施の形態の例を説明する。
図１は、本実施の形態の構成例についての概念的なモジュール構成図を示している。
なお、モジュールとは、一般的に論理的に分離可能なソフトウェア（コンピュータ・プログラム）、ハードウェア等の部品を指す。したがって、本実施の形態におけるモジュールはコンピュータ・プログラムにおけるモジュールのことだけでなく、ハードウェア構成におけるモジュールも指す。それゆえ、本実施の形態は、それらのモジュールとして機能させるためのコンピュータ・プログラム（コンピュータにそれぞれの手順を実行させるためのプログラム、コンピュータをそれぞれの手段として機能させるためのプログラム、コンピュータにそれぞれの機能を実現させるためのプログラム）、システム及び方法の説明をも兼ねている。ただし、説明の都合上、「記憶する」、「記憶させる」、これらと同等の文言を用いるが、これらの文言は、実施の形態がコンピュータ・プログラムの場合は、記憶装置に記憶させる、又は記憶装置に記憶させるように制御するの意である。また、モジュールは機能に一対一に対応していてもよいが、実装においては、１モジュールを１プログラムで構成してもよいし、複数モジュールを１プログラムで構成してもよく、逆に１モジュールを複数プログラムで構成してもよい。また、複数モジュールは１コンピュータによって実行されてもよいし、分散又は並列環境におけるコンピュータによって１モジュールが複数コンピュータで実行されてもよい。なお、１つのモジュールに他のモジュールが含まれていてもよい。また、以下、「接続」とは物理的な接続の他、論理的な接続（データの授受、指示、データ間の参照関係等）の場合にも用いる。「予め定められた」とは、対象としている処理の前に定まっていることをいい、本実施の形態による処理が始まる前はもちろんのこと、本実施の形態による処理が始まった後であっても、対象としている処理の前であれば、そのときの状況・状態に応じて、又はそれまでの状況・状態に応じて定まることの意を含めて用いる。「予め定められた値」が複数ある場合は、それぞれ異なった値であってもよいし、２以上の値（もちろんのことながら、すべての値も含む）が同じであってもよい。また、「Ａである場合、Ｂをする」という意味を有する記載は、「Ａであるか否かを判断し、Ａであると判断した場合はＢをする」の意味で用いる。ただし、Ａであるか否かの判断が不要である場合を除く。
また、システム又は装置とは、複数のコンピュータ、ハードウェア、装置等がネットワーク（一対一対応の通信接続を含む）等の通信手段で接続されて構成されるほか、１つのコンピュータ、ハードウェア、装置等によって実現される場合も含まれる。「装置」と「システム」とは、互いに同義の用語として用いる。もちろんのことながら、「システム」には、人為的な取り決めである社会的な「仕組み」（社会システム）にすぎないものは含まない。
また、各モジュールによる処理毎に又はモジュール内で複数の処理を行う場合はその処理毎に、対象となる情報を記憶装置から読み込み、その処理を行った後に、処理結果を記憶装置に書き出すものである。したがって、処理前の記憶装置からの読み込み、処理後の記憶装置への書き出しについては、説明を省略する場合がある。なお、ここでの記憶装置としては、ハードディスク、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）、外部記憶媒体、通信回線を介した記憶装置、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）内のレジスタ等を含んでいてもよい。

本実施の形態である情報処理装置１００は、金銭の請求又は支払を示す情報を表示するための表示情報を生成するものであって、図１の例に示すように、請求書データ生成モジュール１０５、請求書データ記憶モジュール１１０、請求書データ取得モジュール１１５、請求書データ処理方法判定モジュール１２０、請求書データバッチ処理モジュール１２５、請求書ファイル生成モジュール１３０、請求書ファイル記憶モジュール１３５、請求書データ閾値マスター記憶モジュール１４０、請求データ閾値自動生成モジュール１４５、請求書ダウンロード処理判定モジュール１５０、請求書ファイル取得モジュール１５５、ユーザー操作記録モジュール１６０、請求書ダウンロード要求受付モジュール１６５、請求書ダウンロード要求応答モジュール１７０を有している。
なお、以下の例では、主に金銭の請求を示す情報（以下、請求書データともいう）の表示（一般に、請求書等の生成が該当する）を扱うが、金銭の支払を示す情報の表示（一般に、支払通知書等の生成が該当する）も同様に扱うことができる。

請求書データ生成モジュール１０５は、請求書データ記憶モジュール１１０、請求書データ処理方法判定モジュール１２０と接続されている。請求書データ生成モジュール１０５は、他の情報処理装置（一般的には、基幹システムといわれる金銭の請求又は支払を管理するシステム、例えば、図２の例に示す会計処理サーバー２２０）からの各種データより請求書データを請求書データ記憶モジュール１１０へストアする（記憶させる）。また、請求書データ記憶モジュール１１０へストアした場合は、請求書データ処理方法判定モジュール１２０へ請求書データが新規に登録されたことを通知する。
請求書データ記憶モジュール１１０は、請求書データ生成モジュール１０５、請求書データ取得モジュール１１５と接続されている。請求書データ記憶モジュール１１０は、請求書データのデータベースである。
請求書データ取得モジュール１１５は、請求書データ記憶モジュール１１０、請求書データバッチ処理モジュール１２５と接続されている。請求書データ取得モジュール１１５は、請求書データを請求書データ記憶モジュール１１０から取り出す。

請求書データ処理方法判定モジュール１２０は、請求書データ生成モジュール１０５、請求書データバッチ処理モジュール１２５、請求書データ閾値マスター記憶モジュール１４０、請求データ閾値自動生成モジュール１４５と接続されている。請求書データ処理方法判定モジュール１２０は、金銭の請求又は支払の概要を示す第１の情報とその第１の情報の明細を示す第２の情報を受け付ける。以下、第１の情報と第２の情報は、親子関係を有しているという。第１の情報が親であり、第２の情報が子となる関係である。具体的には、たとえば、ある顧客に対して一定の期間（たとえば、月度）に提供した製品またはサービスに係る請求または支払いの概要、たとえば、請求額または支払い額の合計を表す情報が親である第１の情報にあたる。ここには、前記製品またはサービスごとの請求額が含まれていてもよい。子である第２の情報は第１の情報に記載されている請求の明細であり、たとえば、該製品またはサービスのより詳細な利用状況（データ利用量、印刷枚数、通話時間など）に関する情報が含まれる。第２の情報は製品またはサービスごとに独立して存在してもよいし、複数の製品またはサービスの情報をまとめた形であってもよい。親である第１の情報の場合は、請求書データバッチ処理モジュール１２５による処理を行わせる。子である第２の情報の場合は、その第２の情報に対する表示要求があった場合に、請求書ダウンロード処理判定モジュール１５０が第２の情報を表示するための表示情報を生成する。なお、表示要求には、表示装置に表示することの要求、ダウンロード要求、印刷要求等も含まれる。
具体的には、請求書データ処理方法判定モジュール１２０は、新規に請求書データ記憶モジュール１１０へ登録される請求書データからバッチ処理するか否かを条件（請求書の親子関係、請求金額、ユーザー操作履歴等）に基づいて判定する。バッチ処理する場合は、請求書データバッチ処理モジュール１２５を呼び出す。

請求書ファイルの生成方法を一定の条件でバッチ処理する場合とオンデマンド処理する場合に分けて処理することで、情報処理装置１００での帳票ファイル保存領域を減少させ、クライアントからのダウンロード速度も損なわないようにする。条件については以下の項目を利用する。
（１）請求書の親子関係
請求書には親子関係が存在することが多い。例えば、請求概要を記載した親請求書と概要に記載された各項目の明細を示す複数の子請求書（明細書）のような構成を取ることが多い。また、一般的にユーザーは請求概要を見るが明細まで見ないことが多い。そこで、親請求書ファイルのみをバッチ処理で事前に生成しておき、子請求書ファイルは明細の表示要求があった時にオンデマンドで生成するようにする。
（２）請求書の親子関係と請求金額
（１）に記載したとおり、一般的にユーザーは請求概要を見るが明細まで見ないことが多い。しかし、月額課金系の請求書では、請求明細内の項目（例えば、合計額（総請求金額）の欄）が月額で変わることがあるため、その項目の請求金額が一定レベルを超えた場合に、その項目の明細まで閲覧することが多くなる。そこで、明細まで参照するであろう金額を閾値として、項目毎にマスター定義しておき、閾値を超える場合はバッチ処理としてその明細書ファイルを事前に生成しておく。
（３）請求書の親子関係と請求金額とユーザーモニタリング結果
（２）に記載した方法は予め閾値を情報処理装置１００内に用意しているが、実際にこの閾値はユーザー毎に金銭感覚が異なっているため、意図通り設定できないことが多い。そこで、ユーザーがどのような項目に対してどのような請求金額の場合に明細まで表示させるかを記録しておき、その統計情報に照らし合わせて閾値を動的に決定する。情報の収集範囲（スコープ）は個人ユーザー、同一業種などで層別されたユーザー、全ユーザーのいずれでもよいし、すべてを総合して判定するようにしてもよい。
（４）請求書の請求項目数又は総請求金額の前月比差分
月度の請求書などは月により請求項目の増減がある。一般的にユーザーは請求項目又は総請求金額の前月比差分が大きい月度の場合に明細を見る場合が多い。そこで、請求項目数又は総請求金額の前月比が閾値よりも変化した場合はバッチ処理として明細書ファイルを事前に生成しておく。
（５）請求書の請求項目数と総請求金額の前月比差分とユーザーモニタリング結果
（４）に記載した方法は予め閾値を情報処理装置１００内に用意しているが、実際にこの閾値はユーザーの趣向や項目毎に異なっているため、意図通り設定できないことが多い。そこで、ユーザーがどの項目に対してどれくらいの請求項目数又は総請求金額の変化で明細を表示するかを記録しておき、その統計情報に照らし合わせて閾値を動的に決定する。情報の収集スコープは個人ユーザー、同一業種などで層別されたユーザー、全ユーザーのいずれでもよいし、すべてを総合して判定するようにしてもよい。

・（１）〜（３）の使い分けについて
請求明細額が月額で大きく変わらない特徴がある請求書については、（２），（３）で閾値を参照、計算するためのコストが無駄となるため、（１）の方法を用いるように情報処理装置１００が自動的に切り替えるようにしてもよい。（３）のモニタリング手法を採用した後に、閾値の変動が少ないようなケース、又は、モニタリングを一定期間実施した結果として閾値の変動が少ないケースを検出した場合に、（２）の方法へ情報処理装置１００が自動的に切り替えるようにしてもよい。
・（１）〜（３）と（４）〜（５）の使い分けについて
請求書が請求概要と明細とに分割されている場合（親子関係がある場合）は（１）〜（３）の方法を用い、請求概要と明細とが分割されず１つの請求書に含まれている場合（親子関係がない場合）は（４）〜（５）の方法を用いる。これについても、情報処理装置１００が自動的に切り替えるようにしてもよい。
・（１）〜（３）と（４）〜（５）の組み合わせについて
（１）〜（３）の方法でバッチ処理に振り分けられなかった請求データに対して、さらに（４）〜（５）の処理を組み合わせてバッチ処理の振り分けを行うようにしてもよい。具体的な処理について、図１０の例に示すフローチャートを用いて後述する。
・モニタリングの情報収集スコープ（個人、層別ユーザー、全ユーザー等）について
個人、層別ユーザー、全ユーザーのモニタリングを一定期間実施した結果から閾値の偏差（ばらつき）を計算する。偏差が小さいものはスコープとして有意性が高いとみなす。そして、情報処理装置１００が収集スコープを一定期間で自動的に見直すようにしてもよい。

請求書データバッチ処理モジュール１２５は、請求書データ取得モジュール１１５、請求書データ処理方法判定モジュール１２０、請求書ファイル生成モジュール１３０と接続されている。請求書データバッチ処理モジュール１２５は、第１の情報を表示するための表示情報を、その第１の情報に対する表示要求がある前に予め生成する。「表示要求がある前に」とは、いわゆるバッチ処理であって、生成した表示情報を請求書ファイル記憶モジュール１３５に記憶させる。ここでの生成するタイミングは、表示要求がある前であればいつでもよいが、一般的には、第１の情報を受け付けたときに生成処理を行う。そして、表示要求があった場合は、その時点から表示情報を生成するのではなく、請求書ファイル取得モジュール１５５が、請求書ファイル記憶モジュール１３５から該当する表示情報を抽出する。
また、請求書データバッチ処理モジュール１２５は、第１の情報又は第２の情報内の予め定められた項目の金額が予め定められた額よりも高い又は以上である場合は、その第２の情報を表示するための表示情報を、その第２の情報に対する表示要求がある前に予め生成する。ここで「予め定められた項目」として、例えば、合計額の欄等がある。
また、親子関係がない場合には、請求書データバッチ処理モジュール１２５は、金銭の請求又は支払に関する情報の項目の数又は予め定められた項目の額と、過去における項目の数又はその予め定められた項目の額との差が予め定められた閾値よりも多い又は以上である場合は、その情報を表示するための表示情報を、その情報に対する表示要求がある前に予め生成する。なお、差分は、（１）対象としている金銭の請求又は支払に関する情報の項目の数と、過去における項目の数、又は（２）金銭の請求又は支払に関する情報の予め定められた項目の額と、過去におけるその予め定められた項目の額、である。そして、この場合、請求データ閾値自動生成モジュール１４５は、請求書データバッチ処理モジュール１２５の処理に用いる「予め定められた閾値」を、情報に対する過去の表示要求における項目の数又は予め定められた項目の額に対して統計的処理によって算出するようにしてもよい。
具体的には、請求書データバッチ処理モジュール１２５は、非同期で請求書データを読み出して請求書ファイル生成モジュール１３０を呼び出してファイル生成する。

請求書ファイル生成モジュール１３０は、請求書データバッチ処理モジュール１２５、請求書ファイル記憶モジュール１３５、請求書ダウンロード処理判定モジュール１５０と接続されている。請求書ファイル生成モジュール１３０は、請求書データから請求書ファイルを生成する。請求書ファイルは、請求書である文書であり、例えば、予め定められたフォームに、請求または支払いの概要や明細に係るデータを流し込んで生成される画像ファイルである。フォーマットとしては、たとえばＰＤＦ（Ｐｏｒｔａｂｌｅ Ｄｏｃｕｍｅｎｔ Ｆｏｒｍａｔ）、Ｗｅｂページ等である。本発明の実施例においては、この請求書ファイルを表示情報とも呼ぶ。
請求書ファイル記憶モジュール１３５は、請求書ファイル生成モジュール１３０、請求書ファイル取得モジュール１５５と接続されている。請求書ファイル記憶モジュール１３５は、請求書ファイル生成モジュール１３０によって生成された請求書ファイルの保存装置である。

請求書データ閾値マスター記憶モジュール１４０は、請求書データ処理方法判定モジュール１２０と接続されている。請求書データ閾値マスター記憶モジュール１４０は、項目（例えば、サービス項目）毎に請求明細を参照する金額の閾値を定義したマスターである。
請求データ閾値自動生成モジュール１４５は、請求書データ処理方法判定モジュール１２０、請求書ダウンロード処理判定モジュール１５０、ユーザー操作記録モジュール１６０と接続されている。請求データ閾値自動生成モジュール１４５は、請求書データバッチ処理モジュール１２５が処理を行うための条件として用いられる「予め定められた額」を、第２の情報に対する過去の表示要求における予め定められた項目の金額に対する統計的処理によって算出する。ここでの統計的処理として、例えば、平均値、中央値、最頻値等を算出する処理がある。
具体的には、請求データ閾値自動生成モジュール１４５は、ユーザー操作記録モジュール１６０から、ユーザーの個別データ（操作履歴に関する情報）を集計し、統計的処理を行って、項目毎に請求明細を参照する金額の閾値を生成する。具体的には、たとえば、あるユーザー（またはあるスコープに属するユーザー）が過去に明細の表示要求を行ったサービスまたは製品の請求額の平均が２００００円だった場合に、生成される閾値は２００００円となる。このことは、当該ユーザー（または、当該スコープに属するユーザー）のある月度の当該サービスに係る請求額が２００００円以上またはより高額であった場合に、当該製サービスまたは製品の明細の表示情報を、当該ユーザーが表示要求を行う前にバッチで生成しておくことを意味する。
請求書ダウンロード処理判定モジュール１５０は、請求書ファイル生成モジュール１３０、請求データ閾値自動生成モジュール１４５、請求書ファイル取得モジュール１５５、請求書ダウンロード要求受付モジュール１６５と接続されている。請求書ダウンロード処理判定モジュール１５０は、第２の情報を表示するための表示情報を、その第２の情報に対する表示要求があった後に生成する。
請求書ダウンロード処理判定モジュール１５０は、請求書データバッチ処理モジュール１２５によって表示情報が生成されなかった情報を表示するための表示情報を、その情報に対する表示要求があった後に生成する。
具体的には、請求書ダウンロード処理判定モジュール１５０は、請求書ダウンロードの要求から対応する請求書を特定し、請求書ファイルが存在する場合は請求書ダウンロード要求応答モジュール１７０へ応答を返す。請求書ファイルが存在しない場合は請求書ファイル生成モジュール１３０を呼び出して請求書ファイルを生成後に請求書ダウンロード要求応答モジュール１７０へ応答を返す。

請求書ファイル取得モジュール１５５は、請求書ファイル記憶モジュール１３５、請求書ダウンロード処理判定モジュール１５０、請求書ダウンロード要求応答モジュール１７０と接続されている。請求書ファイル取得モジュール１５５は、請求書ダウンロード処理判定モジュール１５０からの指示に基づいて、請求書ファイルを請求書ファイル記憶モジュール１３５から取り出す。
請求書ダウンロード要求受付モジュール１６５は、請求書ダウンロード処理判定モジュール１５０、ユーザー操作記録モジュール１６０と接続されている。請求書ダウンロード要求受付モジュール１６５は、請求書ダウンロードの要求をクライアント（ユーザーが操作する情報処理端末、図２の例に示すユーザー用端末２００）から受け付ける。その要求に関する操作をユーザー操作記録モジュール１６０に記録する。
請求書ダウンロード要求応答モジュール１７０は、請求書ファイル取得モジュール１５５、ユーザー操作記録モジュール１６０と接続されている。請求書ダウンロード要求応答モジュール１７０は、請求書ダウンロードの応答（請求書ファイルを含む）をクライアントへ返す。その応答処理の履歴をユーザー操作記録モジュール１６０に記録する。クライアントでは、請求書ファイルを表示する。
ユーザー操作記録モジュール１６０は、請求データ閾値自動生成モジュール１４５、請求書ダウンロード要求受付モジュール１６５、請求書ダウンロード要求応答モジュール１７０と接続されている。ユーザー操作記録モジュール１６０は、ユーザーがダウンロードを要求したＷｅｂページ、請求書ファイルのデータ、操作履歴を記録するデータベースである。

図２は、本実施の形態を実現させた場合のシステム構成例を示す説明図である。
情報処理装置１００、ユーザー用端末２００Ａ、ユーザー用端末２００Ｂ、ユーザー用端末２００Ｃ、会計処理サーバー２２０は、通信回線２９０を介してそれぞれ接続されている。通信回線２９０は、無線、有線、これらの組み合わせであってもよく、例えば、通信インフラとしてのインターネット等であってもよい。情報処理装置１００はサーバーとして構成されている。ユーザー用端末２００は、情報処理装置１００を利用するユーザーが使用する端末であって、例えば、Ｗｅｂブラウザを搭載したパソコン、携帯情報端末（スマートフォンを含む携帯電話であってもよい）等が該当する。会計処理サーバー２２０は、ユーザー用端末２００のユーザー等が購入した商品又は利用するサービスに関する会計処理を行うものであって、情報処理装置１００に対して請求書データを提供する。

図３は、本実施の形態による処理例を示すフローチャートである。これは、主に、請求書データが親だった場合にバッチ処理を行うフローを示している。
ステップＳ３０２では、請求書データ記憶モジュール１１０から請求書データを取得する。
ステップＳ３０４では、請求書データから請求書の親子関係を取得する。
ステップＳ３０６では、請求書データは親であるか否かを判断し、親である場合はステップＳ３０８へ進み、それ以外の場合は処理を終了する（ステップＳ３９９）。
ステップＳ３０８では、バッチ処理で請求書ファイルを生成する。

図４は、本実施の形態による処理例を示すフローチャートである。これは、主に、請求書データが親だった場合、又は、子だった場合には子データの請求額が予め定義した閾値を超えた場合にバッチ処理を行うフローを示している。
ステップＳ４０２では、請求書データ記憶モジュール１１０から請求書データを取得する。
ステップＳ４０４では、請求書データから請求書の親子関係を取得する。
ステップＳ４０６では、請求書データは親であるか否かを判断し、親である場合はステップＳ４１０へ進み、それ以外の場合はステップＳ４０８へ進む。
ステップＳ４０８では、子データの請求額が閾値マスターで定義された値を超えているか否かを判断し、超えている場合はステップＳ４１０へ進み、それ以外の場合は処理を終了する（ステップＳ４９９）。
ステップＳ４１０では、バッチ処理で請求書ファイルを生成する。

図５は、本実施の形態による処理例を示すフローチャートである。これは、主に、請求書データが親だった場合、又は、子だった場合にはユーザーモニタリングで得た請求額が閾値を超えた場合にバッチ処理を行うフローを示している
ステップＳ５０２では、請求書データ記憶モジュール１１０から請求書データを取得する。
ステップＳ５０４では、請求書データから請求書の親子関係を取得する。
ステップＳ５０６では、請求書データは親であるか否かを判断し、親である場合はステップＳ５１０へ進み、それ以外の場合はステップＳ５０８へ進む。
ステップＳ５０８では、子データの請求額がモニタリングで得た閾値を超えているか否かを判断し、超えている場合はステップＳ５１０へ進み、それ以外の場合は処理を終了する（ステップＳ５９９）。
ステップＳ５１０では、バッチ処理で第１の情報および請求額が閾値を超えている製品またはサービスに係る第２の情報の請求書ファイルを生成する。

図６は、本実施の形態による処理例を示すフローチャートである。これは、主に、第１の情報の請求書データの請求項目数又は総請求金額が予め定義した閾値を超えた場合にバッチ処理を行うフローを示している
ステップＳ６０２では、請求書データ記憶モジュール１１０から第１の情報の請求書データを取得する。
ステップＳ６０４では、請求書データの請求項目数若しくは総請求金額がシステム（情報処理装置１００）が定義した前月比差分の閾値を超えているか否かを判断し、超えている場合はステップＳ６０６へ進み、それ以外の場合は処理を終了する（ステップＳ６９９）。
ステップＳ６０６では、バッチ処理で第１の情報と第２の情報に係る請求書ファイルを生成する。

図７は、本実施の形態による処理例を示すフローチャートである。これは、主に、請求書データの請求項目数又は総請求金額がユーザーモニタリングで得た閾値を超えた場合にバッチ処理を行うフローを示している
ステップＳ７０２では、請求書データ記憶モジュール１１０から請求書データを取得する。
ステップＳ７０４では、請求書データの請求項目数若しくは総請求金額がモニタリングで得た前月比差分の閾値を超えているか否かを判断し、超えている場合はステップＳ７０６へ進み、それ以外の場合は処理を終了する（ステップＳ７９９）。
ステップＳ７０６では、バッチ処理で請求書ファイルを生成する。

図８は、本実施の形態による処理例を示すフローチャートである。これは、主に、ユーザー操作記録から請求書データの請求項目数の前月比差分の平均値を求めて、その項目の閾値を決定するフローを示している
ステップＳ８０２では、ユーザー操作記録モジュール１６０から条件指定されたユーザーの操作記録レコードを取得する。
ステップＳ８０４では、バッチ処理するかどうかを判定するサービスの月度の請求項目数の前月比差分を計算する。
ステップＳ８０６では、前月比差分を累積する。
ステップＳ８０８では、次の請求月があるか否かを判断し、ある場合はステップＳ８０４へ戻り、それ以外の場合はステップＳ８１０へ進む。
ステップＳ８１０では、累積差分を全月度数で割り、請求項目数の前月比差分平均を求めてサービス（項目）の閾値とする。

図９は、本実施の形態による処理例を示すフローチャートである。これは、主に、ユーザー操作記録から請求書データの総請求金額の前月比差分の平均値を求めて、その項目の閾値を決定するフローを示している
ステップＳ９０２では、ユーザー操作記録モジュール１６０から条件指定されたユーザーの操作記録レコードを取得する。
ステップＳ９０４では、バッチ処理するかどうかを判定するサービス（項目）における月度の総請求額の前月比差分を計算する。
ステップＳ９０６では、前月比差分を累積する。
ステップＳ９０８では、次の請求月があるか否かを判断し、ある場合はステップＳ９０４へ戻り、それ以外の場合はステップＳ９１０へ進む。
ステップＳ９１０では、累積差分を全月度数で割り、総請求額の前月比差分平均を求めてサービス（項目）の閾値とする。

図１０は、本実施の形態による処理例を示すフローチャートである。これは、主に、前述した（１）〜（５）の処理の振り分けを決定するフローを示している
ステップＳ１００２では、請求書が子明細を持つか否かを判断し、持つ場合はステップＳ１００４へ進み、それ以外の場合はステップＳ１０１６へ進む。
ステップＳ１００４では、月度の明細金額の変動幅が大きいか否かを判断し、大きい場合はステップＳ１００６へ進み、それ以外の場合はステップＳ１０１０へ進む。
ステップＳ１００６では、月度の明細金額の閾値の変動幅が大きいか否かを判断し、大きい場合はステップＳ１００８へ進み、それ以外の場合はステップＳ１０１２へ進む。
ステップＳ１００８では、ユーザーモニタリングの結果から閾値の変動幅が大きいか否かを判断し、大きい場合はステップＳ１０１４へ進み、それ以外の場合はステップＳ１０１２へ進む。

ステップＳ１０１０では、請求書の親子関係から処理振り分け（バッチ、オンデマンド）を実施する。
ステップＳ１０１２では、請求書の親子関係と請求金額から処理振り分け（バッチ、オンデマンド）を実施する。
ステップＳ１０１４では、バッチ処理であるか否かを判断し、バッチ処理である場合はステップＳ１０２０へ進み、それ以外の場合はステップＳ１０１６へ進む。
ステップＳ１０１６では、請求書の請求項目数若しくは総請求金額の前月比差分による処理振り分け（バッチ、オンデマンド）を実施する。又は、請求書の請求項目数若しくは総請求金額の前月比差分＋ユーザーモニタリング結果による処理振り分け（バッチ、オンデマンド）を実施する。

ステップＳ１０１８では、バッチ処理であるか否かを判断し、バッチ処理である場合はステップＳ１０２０へ進み、それ以外の場合はステップＳ１０２２へ進む。
ステップＳ１０２０では、バッチ処理を行う。
ステップＳ１０２２では、オンデマンド処理を行う。
ステップＳ１００４、Ｓ１００６、Ｓ１００８の順番はいずれが先であってもよいし、並列的に処理を行ってもよい。ただし、ステップＳ１００４、Ｓ１００６、Ｓ１００８の順番で行うのが、処理量の関係上好ましい。この順番で判断を行うための処理量が減少するからである。

図１１は、請求書データ記憶モジュール１１０内に記憶されている請求書データテーブル１１００、明細データテーブル１１２０等のデータ構造例を示す説明図である。なお、請求書データテーブル１１００と明細データテーブル１１２０、請求書データテーブル１１００と明細データテーブル１１３０、請求書データテーブル１１００と明細データテーブル１１４０は、それぞれ親子関係を有している。
図１１（ａ）は、請求書データテーブル１１００のデータ構造例を示す説明図である。請求書データテーブル１１００は、請求書番号欄１１０２、発行日欄１１０４、請求額欄１１０６、明細番号欄１１０８、明細金額欄１１１０を有している。請求書番号欄１１０２は、請求書の請求書番号を記憶している。発行日欄１１０４は、その請求書の発行日を記憶している。請求額欄１１０６は、その請求書の請求額を記憶している。明細番号欄１１０８は、その請求額の明細番号（明細データテーブル１１２０等へのポインタの機能を有している番号）を記憶している。明細金額欄１１１０は、その請求額の内訳である明細金額を記憶している。

明細データテーブル１１２０、明細データテーブル１１３０、明細データテーブル１１４０は、詳細な明細を示すデータである。
図１１（ｂ）は、明細データテーブル１１２０のデータ構造例を示す説明図である。明細データテーブル１１２０は、明細番号欄１１２２、サービス番号欄１１２４、明細金額欄１１２６を有している。明細番号欄１１２２は、明細番号を記憶している。サービス番号欄１１２４は、サービス番号（項目番号）を記憶している。明細金額欄１１２６は、その項目における明細金額を記憶している。
図１１（ｃ）は、明細データテーブル１１３０のデータ構造例を示す説明図である。
明細データテーブル１１３０は、明細番号欄１１３２、サービス番号欄１１３４、明細金額欄１１３６を有している。
明細番号欄１１３２は、明細番号を記憶している。サービス番号欄１１３４は、サービス番号（項目番号）を記憶している。明細金額欄１１３６は、その項目における明細金額を記憶している。
図１１（ｄ）は、明細データテーブル１１４０のデータ構造例を示す説明図である。
明細データテーブル１１４０は、明細番号欄１１４２、サービス番号欄１１４４、明細金額欄１１４６を有している。
明細番号欄１１４２は、明細番号を記憶している。サービス番号欄１１４４は、サービス番号（項目番号）を記憶している。明細金額欄１１４６は、その項目における明細金額を記憶している。

図１２は、請求書データ閾値マスター記憶モジュール１４０に記憶されている閾値マスターテーブル１２００のデータ構造例を示す説明図である。
閾値マスターテーブル１２００は、サービス番号欄１２０２、明細閾値欄１２０４を有している。サービス番号欄１２０２は、サービス番号（項目番号）を記憶している。明細閾値欄１２０４は、その項目における閾値（明細閾値）を記憶している。図１２の場合、「Ｓ０００３−０１」の項目の場合、「５０，０００円」より高いならば、バッチ処理の対象とすることを示している。

図１３は、ユーザー操作記録モジュール１６０に記憶されているユーザー操作記録テーブル１３００のデータ構造例を示す説明図である。
ユーザー操作記録テーブル１３００は、ユーザーＩＤ欄１３０２、操作時刻欄１３０４、操作ページ欄１３０６、ページ明細金額欄１３０８、操作内容欄１３１０を有している。ユーザーＩＤ欄１３０２は、本実施の形態において、ユーザーを一意に識別するための情報（ユーザーＩＤ：ＩＤｅｎｔｉｆｉｃａｔｉｏｎ）を記憶している。操作時刻欄１３０４は、そのユーザーによって操作が行われた時刻（年、月、日、時、分、秒、秒以下、又はこれらの組み合わせであってもよい）を記憶している。操作ページ欄１３０６は、そのユーザーによって操作が行われたページを記憶している。ページ明細金額欄１３０８は、そのページにおける明細金額を記憶している。ページ明細金額欄１３０８は、一般の操作記録のログに付加した項目であり、この金額である場合に、このユーザーは詳細な明細書を閲覧したことを示している。操作内容欄１３１０は、そのユーザーによって行われた操作の内容を記憶している。

図１１〜図１３の例を用いて説明する。
・請求書ファイルの親子関係から判定する例
図１１（ａ）の例に示す請求書データテーブル１１００と図１１（ｂ）〜（ｄ）の例に示す明細データテーブル１１２０、明細データテーブル１１３０、明細データテーブル１１４０の親子関係から、請求書データテーブル１１００（親データ）をバッチ処理で請求書ファイルとして生成しておく。
・請求書ファイルの親子関係と請求金額から判定する例
図１１（ａ）の例に示す請求書データテーブル１１００と図１１（ｂ）〜（ｄ）の例に示す明細データテーブル１１２０、明細データテーブル１１３０、明細データテーブル１１４０の親子関係から、請求書データテーブル１１００（親データ）をバッチ処理で請求書ファイルとして生成しておく。さらに、図１２の例に示す閾値マスターテーブル１２００の該当するサービスの閾値を参照し、明細番号１０００００−００００００４のサービス番号Ｓ０００３−０１の明細金額が閾値の５０，０００円を超えていることより、図１１（ｄ）の例に示す明細データテーブル１１４０もバッチ処理で請求書ファイルとして生成しておく。
・請求書ファイルの親子関係と請求金額とユーザーモニタリング結果から判定する例
図１１（ａ）の例に示す請求書データテーブル１１００と図１１（ｂ）〜（ｄ）の例に示す明細データテーブル１１２０、明細データテーブル１１３０、明細データテーブル１１４０の親子関係から、請求書データテーブル１１００（親データ）をバッチ処理で請求書ファイルとして生成しておく。さらに、図１３の例に示すユーザー操作記録テーブル１３００から各明細のサービス番号の詳細ページを開いた回数を集計し、その場合の明細金額の平均値を計算する。
例えば、サービス番号Ｓ０００３−０１の明細が全ユーザーで１００回参照されており、それらの明細金額の平均値を計算したところ５０，０００円であった。この場合、明細番号１０００００−００００００４のサービス番号Ｓ０００３−０１の明細をユーザーが開く確率は高いとみなし、図１１（ｄ）の例に示す明細データテーブル１１４０もバッチ処理で請求書ファイルとして生成しておく。

図１４は、請求書データ記憶モジュール１１０に記憶されている請求書データテーブル１４００のデータ構造例を示す説明図である。請求書データテーブル１４００は、請求書番号欄１４０２、発行日欄１４０４、請求額欄１４０６、明細番号欄１４０８、明細金額欄１４１０を有している。請求書番号欄１４０２は、請求書番号を記憶している。発行日欄１４０４は、発行日を記憶している。請求額欄１４０６は、請求額を記憶している。明細番号欄１４０８は、明細番号を記憶している。明細金額欄１４１０は、明細金額を記憶している。
図１５は、請求書データ記憶モジュール１１０に記憶されている請求書データテーブル１５００のデータ構造例を示す説明図である。請求書データテーブル１５００は、請求書番号欄１５０２、発行日欄１５０４、請求額欄１５０６、明細番号欄１５０８、明細金額欄１５１０を有している。請求書番号欄１５０２は、請求書番号を記憶している。発行日欄１５０４は、発行日を記憶している。請求額欄１５０６は、請求額を記憶している。明細番号欄１５０８は、明細番号を記憶している。明細金額欄１５１０は、明細金額を記憶している。
図１６は、請求書データ記憶モジュール１１０に記憶されている請求書データテーブル１６００のデータ構造例を示す説明図である。請求書データテーブル１６００は、請求書番号欄１６０２、発行日欄１６０４、請求額欄１６０６、明細番号欄１６０８、明細金額欄１６１０を有している。請求書番号欄１６０２は、請求書番号を記憶している。発行日欄１６０４は、発行日を記憶している。請求額欄１６０６は、請求額を記憶している。明細番号欄１６０８は、明細番号を記憶している。明細金額欄１６１０は、明細金額を記憶している。
請求書データテーブル１４００、請求書データテーブル１５００、請求書データテーブル１６００は、前述した請求書データテーブル１１００と同等の構造を有している。ただし、請求書データテーブル１４００、請求書データテーブル１５００、請求書データテーブル１６００の間に親子関係はない。

図１７は、ユーザー操作記録モジュール１６０に記憶されているユーザー操作記録テーブル１７００のデータ構造例を示す説明図である。
ユーザー操作記録テーブル１７００は、ユーザーＩＤ欄１７０２、操作時刻欄１７０４、操作ページ欄１７０６、請求月度欄１７０８、請求額欄１７１０、明細数欄１７１２、操作内容欄１７１４を有している。ユーザーＩＤ欄１７０２は、ユーザーＩＤを記憶している。操作時刻欄１７０４は、操作時刻を記憶している。操作ページ欄１７０６は、操作ページを記憶している。請求月度欄１７０８は、請求月度を記憶している。請求額欄１７１０は、請求額を記憶している。明細数欄１７１２は、明細数を記憶している。操作内容欄１７１４は、操作内容を記憶している。
ユーザー操作記録テーブル１７００は、ユーザー操作記録テーブル１３００と比較して、ページ明細金額欄１３０８のかわりに請求月度欄１７０８、請求額欄１７１０、明細数欄１７１２を有している。

図１４〜図１７の例を用いて説明する。
・請求書ファイルの請求項目数の前月比差分から判定する例
図１４の例に示す請求書データテーブル１４００と図１５の例に示す請求書データテーブル１５００の前月比請求項目数の差は３である。情報処理装置１００が前月比請求項目数差分の閾値を３とした場合、図１５の例に示す請求書データテーブル１５００はバッチ処理で請求書ファイルとして生成しておく。
・請求書ファイルの総請求金額の前月比差分から判定する例
図１４の例に示す請求書データテーブル１４００と図１６の例に示す請求書データテーブル１６００の前月比総請求金額の差は７０，４４５円である。情報処理装置１００が前月比総請求金額差分の閾値を５０，０００円とした場合、図１６の例に示す請求書データテーブル１６００はバッチ処理で請求書ファイルとして生成しておく。

・請求書ファイルの請求項目数の前月比差分とユーザーモニタリングから判定する例
図１４の例に示す請求書データテーブル１４００と図１５の例に示す請求書データテーブル１５００の前月比請求項目数の差は３である。図１７の例に示すユーザー操作記録テーブル１７００から明細を閲覧した月度の前月比差分を集計し、その平均値を計算する。
例えば、明細を閲覧した月度の請求項目数の前月比差分の平均が全ユーザーで２．５であったとすると、図１５の例に示す請求書データテーブル１５００をユーザーが開く確率は高いとみなし、請求書データテーブル１５００もバッチ処理で請求書ファイルとして生成しておく。
・請求書ファイルの総請求金額の前月比差分とユーザーモニタリングから判定する例
図１４の例に示す請求書データテーブル１４００と図１６の例に示す請求書データテーブル１６００の前月比総請求金額の差は７０，４４５円である。図１７の例に示すユーザー操作記録テーブル１７００から明細を閲覧した月度の前月比差分を集計し、その平均値を計算する。
例えば、明細を閲覧した月度の総請求金額の前月比差分の平均が全ユーザーで５０，０００円であったとすると、図１６の例に示す請求書データテーブル１６００をユーザーが開く確率は高いとみなし、請求書データテーブル１６００もバッチ処理で請求書ファイルとして生成しておく。

図１８は、ユーザー用端末２００の表示装置における請求書ダウンロード指定画面１８００の表示例を示す説明図である。
請求書ダウンロード指定画面１８００は、請求書を一覧するためのページであり、その請求書ダウンロード指定画面１８００には、Ｎｏ欄１８１０、請求書名欄１８２０、更新日欄１８３０、最終ダウンロード日欄１８４０、ダウンロード指示欄１８５０が表示される。
親請求書行１８６２を親として、子請求書行１８６４、子請求書行１８６６が子となっている。親請求書行１８６２の「ダウンロード」ボタンがユーザーの操作によって選択された場合は、請求書をダウンロードする。ただし、子となる子請求書行１８６４、子請求書行１８６６の請求書（明細書）はダウンロードの対象とならない。また、親請求書行１８６２の「明細書一括ダウンロード」ボタンがユーザーの操作によって選択された場合は、その請求書と子請求書行１８６４、子請求書行１８６６の請求書（明細書）を一括してダウンロードする。子請求書行１８６４の「ダウンロード」ボタンがユーザーの操作によって選択された場合は、その請求書（明細書）をダウンロードする。
請求書ファイルの親子関係から判定する例の場合、親請求書行１８６２の「ダウンロード」ボタンがユーザーの操作によって選択された場合は、バッチ処理された（既に生成された）請求書をダウンロードすることになる。親請求書行１８６２の「明細書一括ダウンロード」ボタンがユーザーの操作によって選択された場合は、バッチ処理された（既に生成された）請求書と、そのボタン選択後（表示要求があった後）に生成された子請求書行１８６４、子請求書行１８６６の請求書（明細書）をダウンロードすることになる。

なお、本実施の形態としてのプログラムが実行されるコンピュータのハードウェア構成は、図１９に例示するように、一般的なコンピュータであり、具体的にはパーソナルコンピュータ、サーバーとなり得るコンピュータ等である。つまり、具体例として、処理部（演算部）としてＣＰＵ１９０１を用い、記憶装置としてＲＡＭ１９０２、ＲＯＭ１９０３、ＨＤ１９０４を用いている。ＨＤ１９０４として、例えばハードディスク、ＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）を用いてもよい。請求書データ生成モジュール１０５、請求書データ取得モジュール１１５、請求書データ処理方法判定モジュール１２０、請求書データバッチ処理モジュール１２５、請求書ファイル生成モジュール１３０、請求データ閾値自動生成モジュール１４５、請求書ダウンロード処理判定モジュール１５０、請求書ファイル取得モジュール１５５、請求書ダウンロード要求受付モジュール１６５、請求書ダウンロード要求応答モジュール１７０等のプログラムを実行するＣＰＵ１９０１と、そのプログラムやデータを記憶するＲＡＭ１９０２と、本コンピュータを起動するためのプログラム等が格納されているＲＯＭ１９０３と、補助記憶装置（フラッシュメモリ等であってもよい）であるＨＤ１９０４と、キーボード、マウス、タッチパネル等に対する利用者の操作に基づいてデータを受け付ける受付装置１９０６と、ＣＲＴ、液晶ディスプレイ等の出力装置１９０５と、ネットワークインタフェースカード等の通信ネットワークと接続するための通信回線インタフェース１９０７、そして、それらをつないでデータのやりとりをするためのバス１９０８により構成されている。これらのコンピュータが複数台互いにネットワークによって接続されていてもよい。

前述の実施の形態のうち、コンピュータ・プログラムによるものについては、本ハードウェア構成のシステムにソフトウェアであるコンピュータ・プログラムを読み込ませ、ソフトウェアとハードウェア資源とが協働して、前述の実施の形態が実現される。
なお、図１９に示すハードウェア構成は、１つの構成例を示すものであり、本実施の形態は、図１９に示す構成に限らず、本実施の形態において説明したモジュールを実行可能な構成であればよい。例えば、一部のモジュールを専用のハードウェア（例えば特定用途向け集積回路（Ａｐｐｌｉｃａｔｉｏｎ Ｓｐｅｃｉｆｉｃ Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔ：ＡＳＩＣ）等）で構成してもよく、一部のモジュールは外部のシステム内にあり通信回線で接続しているような形態でもよく、さらに図１９に示すシステムが複数互いに通信回線によって接続されていて互いに協調動作するようにしてもよい。また、特に、パーソナルコンピュータの他、情報家電、複写機、ファックス、スキャナ、プリンタ、複合機（スキャナ、プリンタ、複写機、ファックス等のいずれか２つ以上の機能を有している画像処理装置）などに組み込まれていてもよい。

なお、前述の実施の形態の説明では、前月比差分を用いたが、過去の額と対象としている期間（一般的には今月）の額の比較であればよい。例えば、前年同月と今月の額の比較、前四半期と今期の額の比較等である。

なお、説明したプログラムについては、記録媒体に格納して提供してもよく、また、そのプログラムを通信手段によって提供してもよい。その場合、例えば、前記説明したプログラムについて、「プログラムを記録したコンピュータ読み取り可能な記録媒体」の発明として捉えてもよい。
「プログラムを記録したコンピュータ読み取り可能な記録媒体」とは、プログラムのインストール、実行、プログラムの流通等のために用いられる、プログラムが記録されたコンピュータで読み取り可能な記録媒体をいう。
なお、記録媒体としては、例えば、デジタル・バーサタイル・ディスク（ＤＶＤ）であって、ＤＶＤフォーラムで策定された規格である「ＤＶＤ−Ｒ、ＤＶＤ−ＲＷ、ＤＶＤ−ＲＡＭ等」、ＤＶＤ＋ＲＷで策定された規格である「ＤＶＤ＋Ｒ、ＤＶＤ＋ＲＷ等」、コンパクトディスク（ＣＤ）であって、読出し専用メモリ（ＣＤ−ＲＯＭ）、ＣＤレコーダブル（ＣＤ−Ｒ）、ＣＤリライタブル（ＣＤ−ＲＷ）等、ブルーレイ・ディスク（Ｂｌｕ−ｒａｙ（登録商標） Ｄｉｓｃ）、光磁気ディスク（ＭＯ）、フレキシブルディスク（ＦＤ）、磁気テープ、ハードディスク、読出し専用メモリ（ＲＯＭ）、電気的消去及び書換可能な読出し専用メモリ（ＥＥＰＲＯＭ（登録商標））、フラッシュ・メモリ、ランダム・アクセス・メモリ（ＲＡＭ）、ＳＤ（Ｓｅｃｕｒｅ Ｄｉｇｉｔａｌ）メモリーカード等が含まれる。
そして、前記のプログラム又はその一部は、前記記録媒体に記録して保存や流通等させてもよい。また、通信によって、例えば、ローカル・エリア・ネットワーク（ＬＡＮ）、メトロポリタン・エリア・ネットワーク（ＭＡＮ）、ワイド・エリア・ネットワーク（ＷＡＮ）、インターネット、イントラネット、エクストラネット等に用いられる有線ネットワーク、又は無線通信ネットワーク、さらにこれらの組み合わせ等の伝送媒体を用いて伝送させてもよく、また、搬送波に乗せて搬送させてもよい。
さらに、前記のプログラムは、他のプログラムの一部分であってもよく、又は別個のプログラムと共に記録媒体に記録されていてもよい。また、複数の記録媒体に分割して記録されていてもよい。また、圧縮や暗号化等、復元可能であればどのような態様で記録されていてもよい。

１００…情報処理装置
１０５…請求書データ生成モジュール
１１０…請求書データ記憶モジュール
１１５…請求書データ取得モジュール
１２０…請求書データ処理方法判定モジュール
１２５…請求書データバッチ処理モジュール
１３０…請求書ファイル生成モジュール
１３５…請求書ファイル記憶モジュール
１４０…請求書データ閾値マスター記憶モジュール
１４５…請求データ閾値自動生成モジュール
１５０…請求書ダウンロード処理判定モジュール
１５５…請求書ファイル取得モジュール
１６０…ユーザー操作記録モジュール
１６５…請求書ダウンロード要求受付モジュール
１７０…請求書ダウンロード要求応答モジュール
２００…ユーザー用端末
２００Ａ…ユーザー用端末
２００Ｂ…ユーザー用端末
２００Ｃ…ユーザー用端末
２２０…会計処理サーバー
２９０…通信回線

Claims (3)

1. 金銭の請求又は支払の概要を示す第１の情報と該第１の情報の明細を示す第２の情報を記憶する記憶手段と、
   前記第１の情報を表示するための表示情報を、該第１の情報に対する要求がある前に予め生成する第１の生成手段と、
   前記第２の情報を表示するための表示情報を、該第２の情報に対する要求があった後に生成する第２の生成手段と、
   前記第１の情報又は前記第２の情報内の予め定められた項目の金額が閾値である額よりも高い又は以上である場合は、該第２の情報を表示するための表示情報を、該第２の情報に対する要求がある前に予め生成する第３の生成手段
   を具備することを特徴とする情報処理装置。
2. 前記閾値である額を、前記第２の情報に対する過去の要求における前記予め定められた項目の金額に対する統計的処理によって算出する算出手段
   をさらに具備することを特徴とする請求項１に記載の情報処理装置。
3. コンピュータを、
   金銭の請求又は支払の概要を示す第１の情報と該第１の情報の明細を示す第２の情報を記憶する記憶手段と、
   前記第１の情報を表示するための表示情報を、該第１の情報に対する要求がある前に予め生成する第１の生成手段と、
   前記第２の情報を表示するための表示情報を、該第２の情報に対する要求があった後に生成する第２の生成手段と、
   前記第１の情報又は前記第２の情報内の予め定められた項目の金額が閾値である額よりも高い又は以上である場合は、該第２の情報を表示するための表示情報を、該第２の情報に対する要求がある前に予め生成する第３の生成手段
   として機能させるための情報処理プログラム。

Images