"料金計算サーバとネットワークで接続された携帯可能なハンディターミナルを用いて料金計算を行なう料金計算方法であって、前記料金計算サーバにて、料金プランと料金単価とを備える料金計算テーブルから、前記ハンディターミナルが対象とする顧客に関する情報を抽出する抽出ステップと、当該抽出した情報を前記ハンディターミナルに送信する送信ステップと、前記ハンディーターミナルにて、前記抽出した情報に基づいて料金計算を実行する計算ステップと、を備えることを特徴とする料金計算方法。請求項1に記載の料金計算方法において、前記料金プランは、複数の計算プランの組み合わせであり、前記計算ステップは、前記料金プランに関連する複数の計算プランを順次計算することで、前記料金計算を実行することを特徴とする料金計算方法。請求項2に記載の料金計算方法において、前記計算プランは、複数の前記料金プランに関連付けられていることを特徴とする料金計算方法。請求項3に記載の料金計算方法において、前記複数の計算プランには計算する順序が定められており、前記計算ステップは、当該順序に基いて前記料金計算を実行することを特徴とする料金計算方法。料金計算サーバと、携帯可能なハンディターミナルと、当該料金計算サーバと当該ハンディターミナルとを接続するネットワークと、を備えた料金計算システムであって、前記料金計算サーバは、料金プランと料金単価とを備える料金計算テーブルを格納する記憶部と、前記料金計算テーブルから、前記ハンディターミナルが対象とする顧客に関する情報を抽出するダウンロード用料金計算テーブル作成処理部と、前記抽出した情報を前記ハンディターミナルに送信する送信部と、を備え、前記ハンディターミナルは、前記送信された情報を格納する記憶部と、前記送信された情報に基づき料金計算を実行する実行処理部と、を備え、ることを特徴とする料金計算システム。請求項5に記載の料金計算システムにおいて、前記料金プランは、複数の計算プランの組み合わせであり、前記実行処理部は、前記料金プランに関連する複数の計算プランを順次計算することで、前記料金計算を実行することを特徴とする料金計算システム。請求項6に記載の料金計算システムにおいて、前記計算プランは、複数の前記料金プランに関連付けられていることを特徴とする料金計算システム。請求項7に記載の料金計算システムにおいて、前記複数の計算プランには計算する順序が定められており、前記実行処理部は、当該順序に基いて前記料金計算を実行することを特徴とする料金計算システム。スマートメータの導入により、30分ごとの検針値の導入が可能となる。そのため、時間帯によって単価を変化させるなど、より多種多様な料金プランが提供されると考えられる。特許文献1では、料金プランごとに料金計算テーブルを1つ用意している。よって、料金取得のための引数の次元が増えることで、料金計算テーブルのデータ量が増大する。また、料金プランが追加される度、新たな料金計算テーブルが必要となる。そのため、データ量が増大し、ハンディターミナル等容量の小さい媒体での適用が困難となる。そこで本願発明では、料金計算ロジックを分割し、複数を組合せることで料金計算結果を取得する。料金プランが異なる場合であっても、基本料金、従量料金単価×使用量という単位に分割することによって、結果の一部を共通化することが可能となる。よって、料金計算テーブルを分割した単位で保持し、それらを足し合わせることで料金計算結果の取得を可能とする。本実施例によれば、1料金プランに対して、複数料金計算テーブルを定義することで、例えば平日使用量と休日使用量が入力として存在する場合に、平日料金の入力引数には平日使用量、休日料金の入力引数には休日使用量というように、それぞれ関連する情報のみを引数に定義することができる。その結果、料金計算テーブルのデータ量を削減することできる。ひいては、別料金プラン同士で料金計算テーブルの共通化を行ったり、新たな料金プランが追加された場合でも、既に存在する料金計算テーブルを利用することで、データ量削減が可能となり、容量、処理能力の低いハンディターミナル等で使用することができる。以下、図面を用いて本発明に関する実施の形態を説明する。図1に示すように料金計算システムは、DBサーバ20に接続されたバッチサーバ10と利用企業側の料金計算システム30とをネットワーク40を介して接続することで構成する。ここで、料金計算システム30料金計算サーバは会社毎に複数設けることができる。パッケージ開発会社等が所有するバッチサーバ10は、料金計算テーブル作成処理部100を有し、DBサーバ内の各種テーブルに対してデータの読み込み、書き込みを実行し、セカンダリテーブルと、セカンダリテーブルから一部データを抽出した検索用テーブルとからなるA社用料金計算テーブル311を作成する。DBサーバはネットワーク40を用いて作成したA社用料金計算テーブル311を料金計算システム30へ送信する。DBサーバ20は、計算対象料金プラン定義テーブル201、料金計算テーブル定義情報202、料金計算単価テーブル203、料金計算ルールテーブル204、料金計算テーブル205、計算対象特定テーブル206を有する。料金計算システム30は、CPUなどの演算装置300とハードディスクなどの記憶装置310と送受信装置320とを備える。演算装置300は各種プログラムを実行することにより、ダウンロード用料金計算テーブル作成処理部301と料金取得処理部302とを機能させる。記憶装置310には、バッチサーバ10から送信されたA社用料金計算テーブル311と、顧客情報312が格納されている。ここで、顧客情報は、顧客を示す顧客識別子と、この顧客が契約している料金プランを示す料金プランコードと、この顧客の情報を処理するハンディーターミナルを識別するハンディータミナル識別子とを備えている。送受信装置320は、バッチサーバ10との間で料金計算テーブルに関する情報の送受信、及びハンディータミナル50との間でダウンロード用料金計算テーブルに関する情報の送受信を行なう。ここで、ハンディータミナル50との間の通信は、ネットワーク60を用いて行なう。なお、通信に暗号処理などを適用することにより、ネットワーク40とネットワーク60を合わせて、ひとつのネットワークで実現してもよい。ハンディータミナル50は、料金取得処理部を実現する演算装置500と、ダウンロード用料金計算テーブルを格納する記憶装置と、ダウンロード用料金計算テーブルに関する情報を料金計算システムとの間で送受信する送受信装置とを有する。図2、図3、図4を用いて、バッチサーバの料金計算テーブル作成処理部による料金計算テーブルの作成処理について説明する。この料金計算テーブルの作成処理は、システム新規導入時や、料金プラン新規追加時、単価改定時に行う。例として、料金プランRYOKIN01を新規追加し、検索用とセカンダリテーブルを作成するための、基本料金取得用の料金計算テーブルの作成と、計算対象特定テーブルの更新処理を示す。RYOKIN01は平日と休日の基本料金と従量料金から料金が算出される料金プランである。単価は、平日と休日それぞれに決められており、更に、基本料金と単価は地区と使用量によって変化する料金プランである。まず、PLAN01とキー2から基本料金を取得するテーブルとなっている。平日単価も同様にキー1とキー2から単価を取得するテーブルとなっている。平日従量料金は、キー1とキー2から従量料金を取得するテーブルとなっている。休日料金に関しても同様のテーブルが作成される。このデータパターンにおいて特許文献1の方式で料金計算テーブルを作成すると、地区3パターン×平日使用量1000パターン×休日使用量1000パターン3000000レコードの設定が必要となる。しかし、本願発明では、平日料金と休日料金を別々に求めることが出来るため、平日基本料金は、地区3パターン×平日使用量1000パターン3000レコード、平日単価は、地区3パターン×平日使用量1000パターン3000レコード、平日従量料金は、単価15パターン×平日使用量1000パターン=15,000レコード、休日基本料金は、地区3パターン×休日使用量1000パターン3000レコード、休日単価は、地区3パターン×休日使用量1000パターン3000レコード、休日従量料金は、単価15パターン×休日使用量1000パターン15000レコード、となり、合計42000レコードと、およそ14程度のデータ量で定義を行うことが出来る。図10は、時間帯によって単価を変える料金プランを仮定した場合の、本実施例を適用させた場合と、適用させなかった場合の比較説明グラフである。横軸は時間帯分割数を示している。ここで時間帯分割数とは、一日の間に存在する料金体系の数を指している。例えば、昼間と夜間で単価を変える場合は2となる。また2時間単位で単価を変える場合12となる。縦軸は料金計算テーブルのレコード数を表わす。ある時間帯の基本料金、単価パターンを図11に示す。基本料金、従量料金は地区3パターンと使用量1~100によって定まり、1地区につき5パターンの単価が存在する。従量料金は単価×使用量で算出する。以上の前提において、図10の通り、時間帯の分割数が多くなれば多くなるほど、本願発明のデータ量削減効果は大きくなる。ハンディターミナルは容量が小さいため、作成した料金計算テーブルを全てダウンロードすることは困難である。そのため、ダウンロードするデータを選別する必要がある。図6、図7、図8を用いてデータ選別処理について説明する。まず、検針範囲に存在する顧客の料金プランを取得し、図7の計算対象特定テーブルで料金対象プランコードをキーに、検索用テーブル、セカンダリテーブルのダウンロード対象を決定する6-1。例として、RYOKIN02とRYOKIN03の料金プランを契約している顧客が存在すると仮定する。つまり、PLAN11、12、13、14、15それぞれの検索用テーブルとセカンダリテーブルのダウンロードが必要となる。まずPLAN11について、セカンダリテーブルTABLE11が今回のダウンロード対象となる他料金プランで使用しているかを判定する6-2。ここで判定をセカンダリテーブルに限定しているのは、それぞれの料金プランコードによって、検索テーブルに退避したいレコードが異なり、検索テーブルを共通化してしまうとレスポンスの低下を招くためである。また、検索テーブルは、元々セカンダリテーブルから一部データを抜粋したものであり、共通化することによるデータ量削減効果も低いと考えられる。セカンダリテーブルは検索テーブルにデータが存在しない場合のみ使用するため、共通化してもレスポンスへの影響は小さいと想定される。更に、全入力パターンのレコードを保持していることから、定義されているレコード数は多く、共通化することによるデータ量縮小の効果は大きい。よって、セカンダリテーブルのみを共通化の対象とする。セカンダリテーブルTABLE11は今回のダウンロード対象であるRYOKIN03では使用されていないため、図7の計算対象特定テーブルに定義されているRYOKIN02のPLAN11の開始位置、終了位置、対象行からそのままダウンロード対象を特定する。つまり、~の範囲の中で、行が地区A、地区B、地区Cとなるレコードのみをダウンロードし、セカンダリテーブルとする。ダウンロード対象のテーブルに対して全て処理が完了するまで6-2から繰り返し処理を行う6-4。PLAN12のセカンダリテーブルTABLE12もRYOKIN03では使用していないため、PLAN11の場合と同様にセカンダリテーブルを決定する。次に、PLAN13の処理を行う。PLAN13のセカンダリテーブルはRYOKIN03でも使用されている。そのため、複数料金プランの計算対象特定テーブルから、必要なセカンダリテーブルのレコード数を決定する6-3。図7計算対象特定テーブルの、RYOKIN01とRYOKIN02のPLAN13の開始位置、終了位置、対象行、対象列の設定値をマージし、ダウンロード対象を特定する。開始位置はそれぞれの最小値から定まるので、となる。終了位置は最大値から定まるため1000500となる。対象行、列は単純にマージし、重複を取り除きソートする。今回は、対象行は共に設定がないため、設定無し、対象列は、マージした結果である、100、150、200、250、300、350、400、500となる。つまり、~1000500の範囲の中で100、150、200、250、300、350、400、500となるレコードのみをダウンロード対象とする。そのため、それぞれセカンダリテーブルを用意した場合に比べ、図8に示すように、単価200と300のデータを共通化することで、2割のデータを削減することができる。また、仮に検針範囲にRYOKIN02を契約している顧客のみが存在する場合、単価が100、200、300、400、500のレコードのみをダウンロードするため、セカンダリテーブルを共通化してはいるが、余分なデータの保持は防ぐことができる。ハンディターミナル等で料金取得を行う処理について図5、7、9で説明する。まず、顧客が契約している料金プランコードをキーに、対象の料金計算テーブルを特定する。9-1。例として、顧客はRYOKIN01を契約していることとする。地区は地区A、平日使用量は2、休日使用量は1とする。まず、PLAN01の料金計算テーブルを取得する。図7からPLAN01の検索用テーブルはTABLE07、セカンダリテーブルはTABLE17であることがわかる。次に、料金計算テーブルから金額情報を取得する9-2。図5から、地区A、平日使用量1の場合の単価は1000となる。続いて、返却値がWORKであるか判定する9-3。PLAN01の返却値はWORKではないため、取得した金額を加算する9-4。PLAN01は最初の計算対象プランであるため、加算結果は1000となる。対象の料金プランに紐づく計算対象プランが全て実行されていない場合は、9-2から再度処理を行う9-5。続いて、PLAN02について料金を取得する。図5より、返却値は300となる。PLAN02の返却値はWORKであるため、加算処理は行わない。同様に、PLAN03について処理を行う。PLAN03の返却値は600であり、WORKではないため、加算結果は1600となる。同様に休日料金も算出する。計算対象プランが全て実行された場合は、加算後の料金を結果として返却する9-6。更に、顧客数分処理が終了するまで、9-1から再度処理を行う9-7。"