(57)【要約】【課題】多様なパターンの周期課金の課金日を統一した処理で管理できるようにする。【解決手段】周期課金における課金日をコンピュータで管理するためのデータ構造であって、課金金額を計算する課金周期の時間単位を示す課金周期単位と、課金金額を計算する１周期を課金周期単位の繰返し数で示した１周期単位数と、前記課金周期単位と前記１周期単位数で特定された１周期のうち何単位目の課金周期単位にある日に課金処理を行うかを示す課金日周期と、前記課金日周期により特定される課金処理を行う課金周期単位の中で、課金処理を行う日を特定する情報である課金日情報と、前記課金周期単位、前記１周期単位数、前記課金日周期、及び前記課金日情報に基づいて計算された次回課金日とを対応付けて構成する。【選択図】　　　図６
2004021335.tif 000002
【特許請求の範囲】
【請求項１】
周期課金における課金日をコンピュータで管理するためのデータ構造であって、
課金金額を計算する課金周期の時間単位を示す課金周期単位と、
課金金額を計算する１周期を前記課金周期単位の繰返し数で示した１周期単位数と、
前記課金周期単位と前記１周期単位数で特定された１周期のうち何単位目の課金周期単位にある日に課金処理を行うかを示す課金日周期と、
前記課金日周期により特定される課金処理を行う課金周期単位の中で、課金処理を行う日を特定する情報である課金日情報と、
前記課金周期単位、前記１周期単位数、前記課金日周期、及び前記課金日情報に基づいて計算された次回課金日と、
を対応付けて有することを特徴とするデータ構造。
【請求項２】
前記課金周期単位は、日、週、月、又は年を特定する情報であることを特徴とする請求項１に記載のデータ構造。
【請求項３】
前記データ構造は、課金周期の区切りとなる１つの日付である周期区切り日をさらに対応付けて有することを特徴とする請求項１又は請求項２に記載のデータ構造。
【請求項４】
前記データ構造は、課金日が対応する課金期間の前、中、又は後のいずれであるかを示す期間前後払い区分をらに対応付けて有することを特徴とする請求項１から請求項３のいずれか一項に記載のデータ構造。
【請求項５】
前記課金日情報は、前記課金周期単位で年が特定された場合に参照される定期的な課金月と、前記課金周期単位で年又は月が特定された場合に参照される定期的な課金日付と、前記課金周期単位で週が特定された場合に参照される定期的な課金曜日とを備えてなることを特徴とする請求項２に記載のデータ構造。
【請求項６】
請求項１から請求項５のいずれか一項に記載のデータ構造を用いてコンピュータにより周期課金における課金日を管理する方法であって、
コンピュータ内の処理装置が、コンピュータ内に備えられたタイマから当日の日付を取得する第１ステップと、
前記処理装置が前記データ構造のあるレコードから次回課金日を取得する第２ステップと、
前記処理装置が、第１ステップで取得した日付と第２ステップで取得した次回課金日を比較して、
同日であれば課金を指示すると共に、課金周期単位、１周期単位、課金日周期、及び課金日情報を取得又は設定し、これらのデータに基づいて次回課金日を計算し、次回課金日を更新した新たなデータ構造を格納する第３ステップとを有することを特徴とする周期課金における課金日の管理方法。
【請求項７】
前記第３ステップにおける次回課金日の計算は、前記処理装置が課金周期単位に１周期単位数を乗じて得た値を、前記第２ステップで取得した当日の日付に足すことにより行うことを特徴とする請求項６に記載の周期課金における課金日の管理方法。
【請求項８】
前記した課金の指示は、決済システムに対して課金額の決済を指示する信号であることを特徴とする請求項６又は請求項７に記載の周期課金における課金日の管理方法。
【請求項９】
周期課金を行うため、コンピュータに、
課金金額を計算する課金周期の時間単位を示す課金周期単位、
課金金額を計算する１周期を課金周期単位の繰返し数で示した１周期単位数、
前記課金周期単位と前記１周期単位数で特定された１周期のうち何単位目の課金周期単位にある日に課金処理を行うかを示す課金日周期、
前記課金日周期により特定される課金処理を行う課金周期単位の中で、課金処理を行う日を特定する情報である課金日情報
を取得又は設定するステップ、
前記次回課金日と比較対照する対照日付を設定するステップ、
前記設定した次回課金日と対照日付を比較して、同日であれば課金を指示すると共に、前記１周期単位数、前記課金日周期、前記課金日情報、に基づいて次回課金日を設定するステップ、
を実行させることを特徴とする周期課金管理プログラム。
【請求項１０】
前記対照日付を設定するステップは、前記コンピュータが有するタイマから当日の日付を取得するステップであることを特徴とする請求項９に記載の周期課金管理プログラム。
【請求項１１】
前記次回課金日を設定するステップは、課金周期単位に１周期単位数を乗じて得た値を当日の日付に足すステップであることを特徴とする請求項９又は請求項１０に記載の周期課金管理プログラム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、予め指定された金額や、一定期間内の利用料に応じた金額を周期的に課金する場合において、任意の周期やタイミングで課金処理をすることができるように管理するためのデータ構造及びこれを用いた課金日の管理方法並びに周期課金管理プログラムに関する。
【０００２】
【従来の技術】
電気、ガス、携帯電話、新聞、電話等われわれが生活の中で利用するサービスは、一般的に１月に一回等、周期的に課金することが行われている。これらの周期的な課金の課金日は、これまでコンピュータを利用した周期課金管理システムにより管理されていた。
【０００３】
従来の周期課金管理システムは、一般に、（１）周期の開始日、（２）周期の期間、（３）課金日、（４）該当料金期間指定、（５）決済日の項目（フィールド）を設定して課金日を管理していた。ここで、周期の期間とは、課金するサービス提供期間の１周期のことであり、例えば１ヶ月とか、１年間などである。そして、課金日は、毎月２５日に課金する場合には、２５日という日付である。また、該当料金期間指定とは、どの周期分の課金を行うのかを特定する情報である。つまり、前のサービス提供期間分の課金をするのか、サービス提供中の期間分の課金をするのか等を特定する情報である。
【０００４】
一例として、従来の周期課金管理システムにおける課金の管理方法を説明する。例えば、毎月１０日〜翌月９日までの１ヶ月間（周期の期間）を１料金月とし、毎月期間の最終日である９日（課金日）に利用した期間分の利用料金を課金するとする。そして、毎月月末にそれまで課金されていた課金データを決済システムへ引き渡すとすると、各項目の格納値は次のようになる。
周期の開始日　　：１０日
周期の期間　　　：１ヶ月毎
課金日　　　　　：９日
該当料金期間指定：期間中に課金
決済日　　　　　：月末日
このように、１ヶ月に一回課金する場合のように、課金方法が１種類の場合には、従来のようなデータ構造で対応することが可能であった。
【０００５】
【発明が解決しようとする課題】
しかし、近年、ブロードバンドコンテンツ販売においては、ＰｅｙＰｅｒＷｅｅｋやＰａｙＰｅｒＤａｙといった多様な課金方法が利用され始めている。また、サービス提供者にとっては、一定期間以上契約している長期契約者には、優遇した料金設定をしたい場合もある。さらに、月額３００円という課金パターンから日額１０円という課金パターンに自由に変更できるようにするなど、利用者の自由度を拡大させて利便性を向上させたい場合もある。
【０００６】
このように、課金パターンは、従来のように１ヵ月毎の一辺倒ではなく、日単位、週単位、月単位、年単位等任意に設定、変更できるのが、利用者に対するサービス向上の点で望ましい。
【０００７】
ところで、サービス提供事業者は、提供したサービスに対する対価をなるべく早期に利用者から回収することを望む。ここで、決済日を課金日に近付けることができれば、課金したデータを早期に決済システムに引き渡すことが可能になり、サービス提供事業者は早期に代金を回収できる。しかし、実際には、決済日は決済手段や決済業者によって決められていることから、サービス提供事業者が事由に設定することはできない。そのため、周期課金システムに対しては、課金日を任意に設定できることが望まれる。
【０００８】
これらの要望は、従来の周期課金システムでは満たすことはできなかった。すなわち、従来は、課金日の設定を利用期間の初日もしくは最終日、又はシステムで決めた一定の日に限定されており、自由度がなかった。また、周期の期間を変更した場合にも、その変更に伴い課金日を変更させることはできなかった。
【０００９】
一方、２ヶ月毎や３週間毎等、異なる課金パターンがある場合に、周期課金システムで課金日を指定するためには、それぞれの課金パターンに応じて必要な情報が異なってくる。かといって、１つの周期課金システムにおいて複数の課金パターンに応じたデータ構造をそれぞれ用意するのでは、管理システムの容量上も無駄が生じ、動作も複雑になることから好ましくない。
【００１０】
これらの背景をもとに、本発明がなされたもので、本発明は、任意の周期、任意の課金日等の課金パターンを１つの周期管理システムで効率的に可能にするためのデータ構造及びこれを用いた周期課金における課金日の管理方法を提供することを目的とする。
【００１１】
【課題を解決するための手段】
前記した課題を解決するため、本発明では、周期課金における課金日をコンピュータで管理するためのデータ構造であって、課金金額を計算する課金周期の時間単位を示す課金周期単位と、課金金額を計算する１周期を課金周期単位の繰返し数で示した１周期単位数と、前記課金周期単位と前記１周期単位数で特定された１周期のうち何単位目の課金周期単位にある日に課金処理を行うかを示す課金日周期と、前記課金日周期により特定される課金処理を行う課金周期単位の中で、課金処理を行う日を特定する情報である課金日情報と、前記課金周期単位、前記１周期単位数、前記課金日周期、及び前記課金日情報に基づいて計算された次回課金日と、を対応付けて有することを特徴とするデータ構造を提供する。
【００１２】
このようなデータ構造によれば、課金周期単位と、周期単位数を乗じた値により、サービス等について課金する１周期の長さが特定される。また、課金日周期課金日周期と、課金日情報により、１周期の中のどの日に課金をするのかが特定される。そして、これらの情報から計算された次回課金日が新たなデータ構造として格納されるので、自由な周期、課金日の設定をすることができるとともに、次回課金日の管理をすることが可能となる。このように、共通の定義方法を用いて多様な周期の課金を設定できる結果、周期課金の管理が効率的になる。
なお、本明細書において、課金日とは、コンピュータで課金の処理、指示を行う日であり、必ずしも実際にお金が引き渡される決済日と同日にはならない。
【００１３】
また、前記したデータ構造においては、前記課金周期単位は、日、週、月、又は年を特定する情報であるのが好ましい。
このように、日、週、月、又は年のいずれかを課金周期として選択、指定できるようにすることで、われわれの実生活に即した周期で課金周期を管理することが可能となる。
【００１４】
さらに、前記したデータ構造においては、課金周期の区切りとなる１つの日付である周期区切り日をさらに対応付けて有するのが好ましい。
このように、周期区切り日をデータとして有することにより、サービス等の開始時や契約時が不規則な場合でも、周期の区切りを特定することで、対応が可能となる。
【００１５】
また、前記したデータ構造においては、課金日が対応する課金期間の前、中、又は後のいずれであるかを示す期間前後払い区分をらに対応付けて有するのが好ましい。
このような期間前後払い区分を管理することにより、サービスの提供期間に対して前後にずれた時期に課金する場合も明確に管理することが可能となる。
【００１６】
また、前記したデータ構造においては、前記課金日情報は、前記課金周期単位で年が特定された場合に参照される定期的な課金月と、前記課金周期単位で年又は月が特定された場合に参照される定期的な課金日付と、前記課金周期単位で週が特定された場合に参照される定期的な課金曜日とを備えるように構成してもよい。
【００１７】
このようなデータ構造では、課金周期単位で、周期の単位が年、月、週が特定されている場合に、より詳細な課金日を特定するための情報を管理可能にする。すなわち、課金周期単位が年の場合には、課金月及び課金日付で課金日の月、日付を特定する。そして、課金周期単位が月の場合には、課金日付で課金日の日付を特定する。また、課金周期単位が週の場合には、課金曜日で課金日の曜日を特定する。
【００１８】
なお、前記した各データ構造において、各データは、複数の記憶装置や、ファイルに分かれて設けられていてもよい。すなわち、各データがある項目をキーとして関連付けてあり、一定の対応関係を持っているならば十分であり、必ずしも一つのファイル内に構成される必要はない。
【００１９】
また、本発明においては、前記した各データ構造を用いて、課金日を管理する方法が提供される。すなわち、コンピュータにより周期課金における課金日を管理する方法であって、コンピュータ内の処理装置が、コンピュータ内に備えられたタイマから当日の日付を取得する第１ステップと、前記処理装置が前記データ構造のあるレコードから次回課金日を取得する第２ステップと、前記処理装置が、第１ステップで取得した日付と第２ステップで取得した次回課金日を比較して、同日であれば課金を指示すると共に、課金周期単位、１周期単位、課金日周期、及び課金日情報を取得し、取得したこれらのデータに基づいて次回課金日を計算し、次回課金日を更新した新たなデータ構造を格納する第３ステップとを有することを特徴とする周期課金における課金日の管理方法が提供される。
【００２０】
このような周期課金における課金日の管理方法によれば、第１ステップでコンピュータ内の処理装置が当日の日付をタイマから取得し、第２ステップにおいて、あるレコードの次回課金日を取得する。そして、第３ステップにおいて、当日の日付と次回課金日とを比較した上で、日次処理の動作をする。すなわち、当日の日付と、取得した次回課金日の日付が同日である場合には、当日が課金日に相当しているということなので、処理装置が課金を指示した後に、次回課金日を計算して、算出された次回課金日で更新した新たなデータ構造を格納する。一方、当日の日付と次回課金日とが異なる日であれば、次回課金日に変更はなく、課金処理を行う必要もないので、課金日の管理については処理を終了すればよい。なお、ここでの課金を指示は、外部又はコンピュータ自身に対する課金の指示があればどのようなものでも良く、請求書を表示、印刷する処理でもいいし、決済用のコンピュータに決済の指示をする信号を出力するのでもよい。また、コンピュータ内の決済用プログラムに指示を出力してもよい。
【００２１】
また、前記した周期課金における課金日の管理方法では、前記第３ステップにおける次回課金日の計算は、前記処理装置が課金周期単位に１周期単位数を乗じて得た値を、前記第２ステップで取得した当日の日付に足すことにより行うことができる。
【００２２】
通常の周期課金では、課金は、１周期ごとに行われるので、１周期の日数を、課金周期単位と１周期単位数を乗じることにより算出し、これを今までの次回課金日フィールドに格納されていた次回課金日に足すことにより、次の課金日を容易に算出することができる。
【００２３】
さらに、前記した周期課金における課金日の管理方法では、前記した課金を指示する出力は、決済システムに対して課金額の決済を指示する信号としてもよい。
このような課金日の管理方法によれば、金融機関等が有する決済システムに対して決済の指示がなされて、自動的に決済が執行される。なお、ここでいう金融機関とは、決済を行うことができるシステムを有する機関であればどのような機関でも良く、典型的には、銀行、カード会社であるが、例えばサービスを提供する業者自身であっても構わない。
【００２４】
また、本発明においては、前記した各データ構造を用いて、課金日を管理するコンピュータプログラムが提供される。すなわち、周期課金を行うため、コンピュータに、課金金額を計算する課金周期の時間単位を示す課金周期単位、課金金額を計算する１周期を課金周期単位の繰返し数で示した１周期単位数、前記課金周期単位と前記１周期単位数で特定された１周期のうち何単位目の課金周期単位にある日に課金処理を行うかを示す課金日周期、前記課金日周期により特定される課金処理を行う課金周期単位の中で、課金処理を行う日を特定する情報である課金日情報を取得又は設定するステップ、前記次回課金日と比較対照する対照日付を設定するステップ、前記設定した次回課金日と対照日付を比較して、同日であれば課金を指示すると共に、前記１周期単位数、前記課金日周期、前記課金日情報、に基づいて次回課金日を設定するステップ、を実行させることを特徴とする周期課金管理プログラムが提供される。
【００２５】
このようなコンピュータプログラムをコンピュータに実行させれば、コンピュータ内の処理装置が、課金周期単位、１周期単位、課金日周期、課金日情報をデータベースから取得したり、又は入力装置から入力させたりする。そして、次回課金日と比較対照する対照日付、例えば当日の日付をタイマから取得するなどして設定する。さらに、対照日付と次回課金日とを比較した上で、日次処理の動作をする。すなわち、対照日付と次回課金日とが同日である場合には、当日が課金日に相当しているということなので、処理装置が課金を指示した後に、次回課金日を計算、記憶するなどして設定する。一方、当日の日付と次回課金日とが異なる日であれば、次回課金日に変更はなく、課金処理を行う必要もないので、課金日の管理については処理を終了すればよい。なお、ここでの課金を指示は、外部又はコンピュータ自身に対する課金の指示があればどのようなものでもよく、例えば請求書を表示、印刷する処理でもよいし、決済用のコンピュータに決済の指示をする信号を出力するのでもよい。
【００２６】
なお、前記した周期課金管理プログラムにおいて、前記対照日付を設定するステップは、前記コンピュータが有するタイマから当日の日付を取得するステップとすることができる。また、前記次回課金日を設定するステップは、課金周期単位に１周期単位数を乗じて得た値を当日の日付に足すステップとしてもよい。
【００２７】
【発明の実施の形態】
次に、本発明の実施の形態について、適宜図面を参照しながら説明する。
図１は、本発明の実施形態に係る周期課金管理システムの利用形態を示した図であり、図２は、周期課金管理システムの構成を示すシステム構成図である。
図１に示すように、周期課金管理システム１は、サービス提供業者２が各ユーザＵ１，Ｕ２，Ｕ３・・・に提供したサービスに対する料金を管理するシステムである。各ユーザＵ１，Ｕ２，Ｕ３・・・は、サービス提供業者２のサービスを受けるときに、課金されるスパンとしての周期や、課金される日等のパターンを決めて申し込み、そのパターンが周期課金管理システム１に登録される。そして、課金日になった日に、対応する料金期間の料金の決済が周期課金管理システム１から決済システム３へ指示される。決済システム３では、各ユーザＵ１，Ｕ２，Ｕ３・・・が有する口座Ｄ１，Ｄ２，Ｄ３・・・から、その料金を引き落として決済を執行する。
なお、この実施の形態では、料金を請求する主体として電気、ガス、電話等のサービスを提供する業者を想定しているが、この業者は特に限定されるものではなく、商品を販売する業者、例えばネットワークを通じて商品の通信販売や、デジタルコンテンツの配信をする業者等であってもよい。
【００２８】
［周期課金管理システム１］
図２に示すように、周期課金管理システム１は、記憶装置１０、入力装置１１、出力装置１２、処理装置２０を有する一般的なコンピュータにより構成されている。これらの各装置は、バス１５にそれぞれ接続され、処理装置２０によりデータの転送が可能になっている。
記憶装置１０は、ハードディスク等の一般的な記憶装置であり、特に限定されるものではない。図２においては、課金管理データベース（以下「ＤＢ」と記載する。）として、課金日管理ＤＢ３０と、課金額管理ＤＢ４０とを示しているが、これらの他にも、図示はしないが、コンピュータのオペレーティングシステムや、周期課金管理プログラムが実行可能なファイルとして格納されている。
入力装置１１は、周期課金管理システム１の外部からデータを受け入れる装置であり、キーボードや、他のコンピュータと通信を行うための装置等が含まれる。
出力装置１２は、周期課金管理システムの外部へデータ等を出力する装置であり、ディスプレイや、請求書を印刷するためのプリンタ、他のコンピュータと通信を行うための装置等が含まれる。
処理装置２０は、演算、記憶、入力、出力等の基本動作を行う中央処理装置（ＣＰＵ）であり、記憶装置１０に格納されたコンピュータプログラムを適宜メモリ上にロードして実行することで各種の手段を実現する。処理装置２０は、データ入力手段２１、データ取得手段２２、日付取得手段２３、日付比較手段２４、次回課金日計算手段２５、課金指示出力手段２６の各手段を有するが、これらの詳細については後述する
【００２９】
次に、図２から図５を参照しながら、課金管理ＤＢの詳細について説明する。なお、図３は、横軸を時間軸として、本明細書の用語の意味を図示したものであり、図４は、課金日管理ＤＢが有する各フィールドの値の形式と、その値の意味を簡単に示した表であり、図５は、課金周期単位フィールドに格納された値に応じた各フィールドの参照の有無を示した表である。
【００３０】
［課金日管理ＤＢ３０］
課金日管理ＤＢ３０は、各ユーザＵ１，Ｕ２，Ｕ３・・・が提供されたサービスに対して支払う料金を周期的に決済するために、主として次の課金日がいつであるかを管理するためのデータベースである。課金日管理ＤＢ３０は、入力、更新可能なフィールドとして、課金周期単位フィールド３１、１周期単位数フィールド３２、課金日周期フィールド３３、課金日情報フィールド３４、周期区切り日フィールド３５、期間前後払いフィールド３６、次回課金日フィールド３７を有する。
【００３１】
［課金周期単位フィールド３１］
課金周期単位フィールド３１は、課金を行う周期を数える単位として、どのような期間を使用するかを特定する情報である課金周期単位を格納するフィールドである。図４に示すように、課金周期単位フィールド３１には数字が格納される。そして、０が格納された場合には、日を単位とし、１が格納された場合には、週を単位とし、２が格納された場合には、月を単位とし、３が格納された場合には、年を単位とすることとされている。
本実施の形態では、一般的に良く使われる時間を特定する単位として日、週、月、年を一例としてあげたが、本発明はこれらに限定されることなく、例えば六曜のように６日を一単位としてもよいし、時、分などを単位としても構わない。
【００３２】
［１周期単位数フィールド３２］
１周期単位数フィールド３２は、課金周期単位を何回繰り返すと、料金を支払うべきサービス提供期間である１周期になるかを特定する情報である１周期単位数を格納するフィールドである。図４に示すように、１周期単位数フィールド３２には、数字が格納される。そして、図３に示すように、１周期単位数が２であるときには、周期課金管理システム１で時間を数える単位である課金周期単位を２倍して特定される期間が料金を支払うべきサービス提供期間、すなわち１周期を規定する。
【００３３】
［課金日周期フィールド３３］
課金日周期フィールド３３は、課金周期単位と１週期単位数で特定された１周期のうち、何単位目の課金周期単位にある日に課金処理を行うかを示す課金日周期を格納するフィールドである。図４に示すように、課金日周期フィールド３３には、数字が格納される。そして、図３に示すように、例えば１周期単位数が２で、周期の始めから数えて２単位目の課金周期単位の中に課金日が来るような場合には、課金日周期が２となる。
【００３４】
［課金日情報フィールド３４］
課金日情報フィールド３４は、課金日周期により特定された課金日が来る課金周期単位の中で、課金日をより詳細に特定する情報である課金日情報を格納するフィールドである。本実施の形態では、課金周期単位として、日、週、月、又は年のいずれかを選択するようにしているため、課金日情報フィールド３４は、課金月フィールド３４ａ、課金日付フィールド３４ｂ、課金曜日フィールド３４ｃの３つのフィールドから構成されている。
【００３５】
課金月フィールド３４ａは、課金日が来る（含まれる）年のうち、何月に課金日を指定するかを特定する課金月を格納するフィールドである。したがって、図４に示すように、課金月は、１〜１２の数字（整数）で格納される。そして、図５に示すように、課金月フィールド３４ａは、課金周期単位として年が指定された場合に参照される。
【００３６】
課金日付フィールド３４ｂは、課金日が来る（含まれる）月のうち、何日に課金日を指定するかを特定する課金日付を格納するフィールドである。したがって、図４に示すように、課金日付は０〜３１の数字（整数）で格納され、０を指定したときには、月末が課金日になる。そして、図５に示すように、課金日付フィールド３４ｂは、課金周期単位として、年又は月が指定された場合に参照される。
【００３７】
課金曜日フィールド３４ｃは、課金日が来る（含まれる）週のうち、何曜日に課金日を指定するかを特定する課金曜日を格納するフィールドである。課金曜日は、図４に示すように０〜６の整数で格納され、０が格納された場合には日曜日、１が格納された場合には月曜日、２が格納された場合には火曜日、３が格納された場合には水曜日、４が格納された場合には木曜日、５が格納された場合には金曜日、６が格納された場合には土曜日が指定されるように規定されている。
【００３８】
［周期区切りフィールド３５］
周期区切り日フィールド３５は、料金を課金するサービス提供期間である１周期の区切りを示す周期区切り日を格納するフィールドである。図３に示すように、周期区切り日は、例えばある１周期の初日が指定される。なお、図３においては、１周期の初日が周期区切り日として図示されているが、次の周期に時間が進んだ場合には、周期区切り日はそのままの日としておいてもよいし、次の周期の初日に更新しても構わない。一般的には、ユーザがサービス提供を申し込んだ周期の初日を設定しておき、以後、その値を保持しておけば簡便である。
周期区切り日は、日を特定するので、図４に示すように、日付が格納される。
【００３９】
［期間前後払いフィールド３６］
期間前後払いフィールド３６は、サービスの提供を受けている期間（１周期）中に課金するか、その前又は後に課金するかを特定する期間前後払いを格納するフィールドである。図３及び図４に示すように、期間前後払いは、０，１，２の数字で格納され、０が格納された場合にはサービス提供期間に相当する周期の前が指定され、１が格納された場合には周期中、２が格納された場合には周期後が指定される。
なお、期間前後払いフィールド３６は、必ずしも必要ではない。期間前後払いを指定する代わりに、課金日周期を負の値や、１周期単位数より大きな値を使うことで、期間の前後を特定できるからである。例えば、１周期単位数を３として、サービス提供期間の２単位前の課金周期単位で課金したい（期間前払い）場合には、課金日周期を−１（＝１−２）に設定し、サービス提供期間の２単位後に課金したい（期間後払い）場合には、課金日周期を５（＝３＋２）に設定すればよい。
【００４０】
［次回課金日フィールド３７］
次回課金日フィールド３７は、次回の課金日を格納するフィールドである。次回課金日は、課金日管理ＤＢ３０の他のフィールドを参照して算出された日付が格納される。したがって、次回課金日には日付が格納される。
【００４１】
次に、図６及び図７を参照して、課金日管理ＤＢ３０のレコードの内容の具体例を説明する。図６は、課金日管理ＤＢの各フィールドに格納されたデータの一例を示した図であり、図７（ａ）はユーザＵ１の課金パターンを図示したものであり、（ｂ）はユーザＵ２の課金パターンを図示したものであり、（ｃ）はユーザＵ３の課金パターンを図示したものである。
【００４２】
なお、図２においては、１つのコンピュータ内に接続された記憶装置１０にこれらの各フィールドがまとめて記憶されるように示しているが、このように１つのコンピュータ内に構成される場合には限られない。すなわち、各フィールドが一定の関連付けを持って存在していればよく、互いに離れたコンピュータの記憶装置内に分散して各フィールドが設けられていてもよい。また、本実施の形態では、分かりやすくするためにフィールドという明確な格納部分を想定しているが、必ずしもこのような形態で格納されている必要はない。例えば、図６に示したユーザＵ１のレコードを上のフィールドから順に繋げて２３２−２３−・・・と１つの文字列にして格納したり、課金周期単位に２ｂｉｔ、１周期単位数に４ｂｉｔ、課金日周期に４ｂｉｔなどと最低限必要なｂｉｔ数を割り当てて、１つの数字として格納したりすることもできる。
【００４３】
［ユーザＵ１］
ユーザＵ１が、２００２年３月１０日にサービスの申し込みをしたとする。そして、周期の開始日は毎年１月１日からで、料金計算上の周期の期間が３ヵ月毎とし、その２ヶ月目の２３日に課金したい、すなわち期間中払いにしたいとする。
【００４４】
この場合、図７（ａ）に示すように、初回の周期は、２００２年１月１日−２００２年３月３１日となる。申込日は、２００２年３月１０日であり、期間中払いなので、２００２年３月１０日−２００２年３月３１日までの料金は、申込時（２００２年３月１０日）に課金する。次回課金日は、次の周期の２月目の５月の２３日となる。
【００４５】
ユーザＵ１の課金日管理ＤＢ３０のデータとしては、図６に示すように、課金周期単位は月で数えるので課金周期単位フィールド３１は２であり、３ヶ月毎に１周期となるので、１周期単位数フィールド３２は３となる。課金日は、１周期の中の２月目なので課金日周期フィールド３３は２となる。課金日は２月目の２３日なので、課金日付フィールド３４ｂが２３となる。そして、周期区切り日フィールド３５は、周期の開始日で区切って２００２年１月１日とし、期間前後払いフィールド３６は、期間中払いなので１が設定される。周期区切りフィールド３５は、ユーザＵ１や、サービス提供業者２の都合により、適宜設定しても構わない。次回課金日フィールド３７は、周期区切り日２００２年１月１日に課金周期単位及び１周期単位数に基づき３ヶ月を足して、次の周期の初日が計算され、さらに、課金日周期及び課金日付から、次の課金日である２００２年５月２３日が算出され、この日付が格納される。
【００４６】
［ユーザＵ２］
ユーザＵ２が、２００２年１月１０日にサービスの申し込みをしたとする。そして、周期の開始日は２００１年３月１日からで、料金計算上の周期の期間が２年毎とし、その２年目の最終日に、次回の周期分の料金を課金したい、すなわち期間前払いにしたいとする。
【００４７】
この場合、図７（ｂ）に示すように、初回の周期は、２００１年３月１日−２００２年２月２８日となる。申込みは、２００２年１月１０日であり、期間前払いなので、２００１年３月１日−２００２年２月２８日までの料金は、申込時（２００２年１月１０日）に課金する。次回課金日は、次の周期の最終日である２００３年の２月２８日となる。
【００４８】
ユーザＵ２の課金日管理ＤＢ３０のデータとしては、図６に示すように、課金周期単位は年で数えるので課金周期単位フィールド３１は３であり、２年毎に１周期となるので、１周期単位数フィールド３２は２となる。課金日は、１周期の中の２年目なので課金日周期フィールド３３は２となる。課金日は毎年２月の最終日なので、課金月フィールド３４ａは２月の２が設定され、課金日付フィールド３４ｂは、最終日の０が設定される。そして、周期区切り日フィールド３５は、周期の開始日で区切って２００１年３月１日とし、期間前後払いフィールド３６は、期間前払いなので０が設定される。周期区切りフィールド３５は、ユーザＵ２や、サービス提供業者２の都合により決まった周期開始日を設定しても構わない。次回課金日フィールド３７は、周期区切り日２００１年３月１日に課金周期単位及び１周期単位数に基づき２年を足して、次の周期の初日が計算され、さらに、課金日周期、課金月、課金日付から、次の課金日である２００３年２月２８日が算出され、この日付が格納される。
【００４９】
［ユーザＵ３］
ユーザＵ３が、２００２年３月８日にサービスの申し込みをしたとする。そして、周期の開始日は２００２年３月４日からで、料金計算上の周期の期間が２週間毎とし、その周期の初日に、前回の周期分の料金を課金したい、すなわち期間後払いにしたいとする。
【００５０】
この場合、図７（ｃ）に示すように、初回の周期は、２００２年３月４日の月曜日−２００２年３月１７日の日曜日となる。申込みは、２００２年３月８日の金曜日であり、期間後払いなので、２００２年３月４日−２００２年３月１７日までの料金は、２００２年３月１８日の月曜日に課金する。次回課金日は、申込時から見て２回先の周期の初日である２００２年の４月１日の月曜日となる。
【００５１】
ユーザＵ３の課金日管理ＤＢ３０のデータとしては、図６に示すように、課金周期単位は週で数えるので課金周期単位フィールド３１は１であり、２週毎に１周期となるので、１周期単位数フィールド３２は２となる。課金日は、１周期の中の１週目なので課金日周期フィールド３３は１となる。課金曜日は、周期の初日が月曜日であることから、月曜日を意味する１が設定される。そして、周期区切り日フィールド３５は、周期開始日で区切って２００２年３月４日とし、期間前後払いフィールド３６は、期間後払いなので２が設定される。周期区切りフィールド３５は、ユーザＵ２や、サービス提供業者２の都合により、任意の日付としても構わない。次回課金日フィールド３７は、周期区切り日２００２年３月４日に課金周期単位及び１周期単位数に基づき２週間を足して、２つ先の周期の初日が計算され、さらに、課金日周期、課金曜日から、次の課金日である２００２年４月１日が算出され、この日付が格納される。
【００５２】
［課金額管理ＤＢ４０］
課金額管理ＤＢ４０は、サービス提供期間内にユーザＵ１，Ｕ２，Ｕ３・・・が利用したサービスに応じて料金を管理するためのデータベースである。課金額管理ＤＢ４０の構成は、サービス提供業者２のサービス内容や課金方法により適宜決められる。例えば、利用時間に応じて課金する場合には、時間あたりの単価、利用時間、請求額等の項目が設定され１周期内の利用料金が管理される。これらの各項目の内容は、サービス提供業者２から入力装置１１を通じて入力された利用時間などを、処理装置が課金額管理ＤＢ内に書き込むことで更新される。
【００５３】
次に、処理装置２０内の各手段について説明する。
［データ入力手段２１］
データ入力手段２１は、入力装置１１を介して、外部からデータの入力を受け付ける手段である。例えば、新規のサービス申込があった場合に、通信手段やキーボードを介して新しいユーザの課金パターンを特定する各項目の入力を受け付け、課金日管理ＤＢ３０の該当するフィールドにデータを格納する。また、サービス提供業者２からユーザのサービス利用状況が送信されるごとに、必要なデータを受け付けて、課金額管理ＤＢ４０へそのデータを格納する。
【００５４】
［データ取得手段２２］
データ格納手段２２は、課金管理ＤＢの必要なフィールドから、データを読み出す手段である。取得したデータは、処理装置２０内のメモリ上に保持される。
【００５５】
［日付取得手段２３］
日付取得手段２３は、コンピュータが有するタイマ（図示せず）から、当日の日付を取得する手段である。取得した日付は、処理装置２０内のメモリ上に保持される。
【００５６】
［日付比較手段２４］
日付比較手段２４は、データ取得手段２２で取得した次回課金日の日付と日付取得手段２３で取得した当日の日付とを比較する手段である。日付比較手段２４は、比較した結果に応じてフラグを立て、次回課金日計算手段に処理を続行させる。
【００５７】
［次回課金日計算手段２５］
次回課金日計算手段２５は、日付比較手段２４のフラグに応じて、次回課金日を更新し、又は処理を終了する。次回課金日を更新する場合には、データ取得手段で取得した、課金周期単位、１周期単位数、課金日周期、課金日情報（課金月、課金日付、課金曜日）、周期区切り日、期間前後払いのデータの内、必要なデータを用いて計算し、計算した新たな次回課金日を次回課金日フィールド３７に格納する。なお、次回課金日の計算方法は、種々の方法を利用することができるが、初回以外の計算であって、課金日において次回の課金日を計算する場合には、単に、１周期分日付を遅らせるだけなので、課金周期単位に１周期単位数を掛けて得られる期間をそれまでの課金日又は当日の日付に足せばよい。
【００５８】
［課金指示出力手段２６］
課金日指示出力手段２６は、日付比較手段２４の比較の結果、当日が課金日であった場合に、課金をするためのアクションを起こす手段である。具体的には、カード会社や銀行が有する決済システム３に対して、対象となるユーザの口座から課金額管理ＤＢ４０で管理されていた額の決済を指示する信号である。このように、決済システム３に対して直接決済の指示をすれば、決済が自動的に行われる。なお、決済システム３に指示をする場合だけでなく、請求書をプリンタから印刷するようにプリンタに指示してもよい。
【００５９】
前記した各手段は、コンピュータに所定の動作をさせるコンピュータプログラムを処理装置２０が実行することにより実現される。すなわち、課金周期単位、１周期単位数、課金日周期、課金日情報を取得するステップを実行させることにより、データ取得手段２２が実現される。また、これらのデータを入力させるなど設定させることにより、データ入力手段２１が実現される。
同様に、次回課金日と比較対照する対照日付、例えば当日の日付を取得するステップを実行させることにより日付取得手段２３が実現される。また、次回課金日と対照日付を比較するステップを実行させることにより、日付比較手段２４が実現される。さらに、前記１周期単位数、前記課金日周期、前記課金日情報、に基づいて次回課金日を計算するステップを実行することにより次回課金日計算手段２５が実現される。また、次回課金日と当日の日付の比較の結果、同日であれば課金を指示する出力を行うステップを実行させることにより課金指示出力手段２６が実現される。
【００６０】
以上のような周期課金管理システム１による課金日の管理方法について、図８及び図９のフローチャートを参照しながら説明する。図８は、初回注文時（申込時）の課金日の管理処理のフローチャートであり、図９は、課金日の管理の日次処理のフローチャートである。
【００６１】
新たに、サービスの提供を申し込んだ場合、図８に示すように、周期課金管理システム１には、サービス提供業者２から、コンピュータネットワーク等を介してユーザの課金パターンを特定する条件、すなわち課金日管理ＤＢ３０に入力するべき課金周期単位、１周期単位数、課金日周期、課金日情報、周期区切り日、期間前後払いの各情報が入力される（ステップＳ１１）。そして、次回課金日計算手段２５により、初回課金日が計算される（ステップＳ１２）。初回課金日の計算は、前記した各ユーザＵ１，Ｕ２，Ｕ３の設定例のように、周期区切り日を基準として課金周期単位、１周期単位数、課金日周期、課金日情報を基にして計算される。もちろん、条件によっては、これらの全部の項目を参照する必要がない場合もある。次に、計算された初回課金日を次回課金日フィールド３７に格納して（ステップＳ１３）処理を終了する。なお、この初回課金日が当日であった場合には、さらに次の日次処理をも行う。
【００６２】
日常の毎日の処理、いわゆる日次処理は、図９に示すように、まず、日付取得手段２３により、当日の日付がコンピュータのタイマから取得され、メモリ上に保持される（ステップＳ２１）。また、データ取得手段２２により、次回課金日フィールド３７から次回課金日を、課金周期単位フィールド３１から課金周期単位を、１周期単位数フィールド３２から１周期単位数を、課金日周期フィールド３３から課金日周期を、課金日情報フィールド３４から課金日情報を、周期区切り日フィールド３５から周期区切り日を、期間前後払いフィールド３６から期間前後払いをそれぞれ取得する（ステップＳ２１）。なお、次回課金日の計算の仕方次第で、これらのうち、必要な項目のみ取得すればよいことはもちろんである。
次に、取得した当日の日付と次回課金日の日付を日付比較手段２４が比較する（ステップＳ２２）。比較した結果、２つの日付が異なれば、次回課金日を変更する必要は無いので日次処理を終了する。一方、当日が次回課金日と一致していた場合には、まず、課金を実施する（ステップＳ２３）。すなわち、データ取得手段２２が、課金願区管理ＤＢ４０から、該当するユーザの課金額を取得した上で、課金指示出力手段２６により、その課金額の決済を決済システム３へ指示する信号を送信する。
次に、次回課金日計算手段２５により、次回課金日を計算する（ステップＳ２４）。次回課金日の計算方法は、いろいろな方法があるが、課金周期単位と１周期単位数を掛け合わせて求めた１周期の期間を当日の日付に足して求めるのが簡便である。
次に、計算された新しい次回課金日を次回課金日フィールド３７に格納して処理を終了する（ステップＳ２５）。
以上のようにして、日次処理が行われ、当日が課金日であれば、課金処理をした上で、新たな課金日が次回課金日フィールド３７で管理される。なお、課金処理の実施と次回課金日の計算の順序は逆であっても構わない。
【００６３】
このように、本実施形態の課金日管理ＤＢ３０を有する周期課金管理システム１を利用した課金管理方法によれば、個別のユーザ毎にいろいろなパターンの課金周期を設定し、それらの課金日を統一した処理で管理することが可能となる。
【００６４】
以上、本発明の実施形態について説明したが、本発明は、前記した実施の形態には限定されず、適宜変更して実施することが可能である。
例えば、周期課金システム１は１台のコンピュータで構成せずとも、複数のコンピュータにデータ、プログラムの一部を持たせて処理を分担させることもできる。また、現に課金しようとする周期分の課金日だけでなく、将来来るべき先の課金日をも管理するようにすることもできる。さらに、ユーザが多様な支払いパターンを選択できるように、課金周期単位等（図４参照）ユーザが任意に入力できるようにシステムを構成してもよい。また、支払いパターンと課金テープル、割引テーブルを関連付けておいて、ユーザへのサービス向上を図ることもできる。
【００６５】
【発明の効果】
以上詳述したとおり、本発明のデータ構造、周期課金管理プログラム、周期課金における課金日の管理方法によれば、多様なパターンの周期課金を、統一した処理で管理することが可能となる。
【図面の簡単な説明】
【図１】本発明の実施形態に係る周期課金管理システムの利用形態を示した図である。
【図２】周期課金管理システムの構成を示すシステム構成図である。
【図３】横軸を時間軸として、本明細書の用語の意味を図示したものである。
【図４】課金日管理ＤＢが有する各フィールドの値の形式と、その値の意味を簡単に示した表である。
【図５】課金周期単位フィールドに格納された値に応じた各フィールドの参照の有無を示した表である。
【図６】課金日管理ＤＢの各フィールドに格納されたデータの一例を示した図である。
【図７】（ａ）はユーザＵ１の課金パターンを図示したものであり、（ｂ）はユーザＵ２の課金パターンを図示したものであり、（ｃ）はユーザＵ３の課金パターンを図示したものである。
【図８】初回注文時（申込時）の課金日の管理処理のフローチャートである。
【図９】課金日の管理の日次処理のフローチャートである。
【符号の説明】
１　　　周期課金管理システム
２　　　サービス提供業者
３　　　決済システム
３１　　課金周期単位フィールド
３２　　１周期単位フィールド
３３　　課金日周期フィールド
３４　　課金日情報フィールド
３４ａ　課金月フィールド
３４ｂ　課金日付フィールド
３４ｃ　課金曜日フィールド
３５　　周期区切り日フィールド
３６　　期間前後払いフィールド
３７　　次回課金日フィールド
【図１】
2004021335.tif 000003
【図２】
2004021335.tif 000004
【図３】
2004021335.tif 000005
【図４】
2004021335.tif 000006
【図５】
2004021335.tif 000007
【図６】
2004021335.tif 000008
【図７】
2004021335.tif 000009
【図８】
2004021335.tif 000010
【図９】
2004021335.tif 000011