JP7451945B2 - 課金管理装置及びプログラム - Google Patents

Description

本発明は、課金管理装置及びプログラムに関する。

従来、ネットワーク管理システムとして、例えば、料金不払い加入者の検出を行い、当該料金不払い加入者が検出された場合、当該加入者の一定期間の電話サービスを停止する自動サービス停止監視システムが提案されている（例えば、特許文献１参照）。

特開平１０－２１０１９１号公報

しかしながら、上記特許文献１に開示されているシステムでは、電話サービスを停止するまでの猶予期間が無いため料金不払い加入者に酷であるという問題がある。また、料金不払い加入者の電話サービスへの加入期間に関係なく電話サービスが停止されてしまうため、当該電話サービスに継続して加入するメリットが少ないという問題がある。

本発明は、このような問題に鑑みてなされたものであり、課金アイテムの支払い期限を徒過してしまったユーザーを当該課金アイテムの購入継続期間に応じた処遇により適切に救済することを目的とする。

上記課題を解決するため、本発明に係る課金管理装置は、
次回分の支払期限が過ぎた課金アイテムの今回分の利用が制限されるまでの猶予期間を設定する設定手段を備え、
前記設定手段は、前記猶予期間を設定する際、前回又は今回までの前記課金アイテムの購入継続期間の長さに応じて当該猶予期間の長さを異ならせることを特徴とする。

本発明によれば、課金アイテムの支払い期限を徒過してしまったユーザーを当該課金アイテムの購入継続期間に応じた処遇により適切に救済することができる。

本実施形態のアプリ内課金システムを示す概略構成図である。 端末装置の機能構成を示すブロック図である。 クラウドサーバーの機能構成を示すブロック図である。 課金管理サーバーの機能構成を示すブロック図である。 管理データテーブルを示す図である。 猶予制御パラメータ情報を示す図である。 課金アイテムが購入されたときのアプリ内課金システムの動作の一例を示すフローチャートである。 モバイルアプリへのログイン操作が行われたときのアプリ内課金システムの動作の一例を示すフローチャートである。 課金管理サーバーとストアサーバーとによるポーリング動作の一例を示すフローチャートである。

以下に、本発明について、図面を用いて具体的な態様を説明する。

≪アプリ内課金システム１の構成≫
まず、図１を参照して、本実施形態の構成を説明する。図１は、本実施形態のアプリ内課金システム１を示す概略構成図である。

図１に示すように、アプリ内課金システム１は、端末装置１０、ストアサーバー２０、クラウドサーバー３０、課金管理サーバー４０等を備える。端末装置１０、ストアサーバー２０、クラウドサーバー３０及び課金管理サーバー４０は、通信ネットワークＮを介して情報通信可能に接続される。

端末装置１０は、例えば、ユーザーが使用するスマートフォンやタブレット端末である。具体的には、端末装置１０は、Ａｐｐｌｅ（登録商標）社が提供するｉＰｈｏｎｅ（登録商標）やｉＰａｄ（登録商標）、Ｇｏｏｇｌｅ（登録商標）社が提供するＡｎｄｒｏｉｄ（登録商標）版のスマートフォンやタブレット端末である。なお、端末装置１０の台数は特に限定されない。

ストアサーバー２０は、端末装置１０において起動されたモバイルアプリ１２ａ（後述）内で課金アイテム（課金アイテム３２ａ（後述）を含む）が購入された際に、当該課金アイテムの購入によるレシートを発行するサーバーである。また、ストアサーバー２０は、後述する課金管理サーバー４０によってレシート（ストアサーバー２０により発行されたレシート）の検証要求がなされた場合、当該レシートが正当なものであるか否かを検証するサーバーである。なお、ストアサーバー２０は、上述したｉＰｈｏｎｅ（登録商標）やｉＰａｄ（登録商標）に対応したストアサーバーと、上述したＡｎｄｒｏｉｄ（登録商標）版のスマートフォンやタブレット端末に対応したストアサーバーと、の少なくとも２種類のストアサーバーによって構成されている。

クラウドサーバー３０は、端末装置１０において起動されたモバイルアプリ１２ａ（後述）の使用にあたりクラウドサービス（例えば、課金アイテム３２ａの利用等）を提供するサーバーである。

課金管理サーバー４０は、端末装置１０において起動されたモバイルアプリ１２ａ内で購入することができる課金アイテム３２ａ等の課金状態を管理するサーバーである。

＜端末装置１０の構成＞
次に、図２を参照して、端末装置１０の構成を説明する。図２は、端末装置１０の機能構成を示すブロック図である。

図２に示すように、端末装置１０は、制御部１１、記憶部１２、操作部１３、表示部１４、通信部１５等を備える。

制御部１１は、記憶部１２に記憶されている各種のプログラムを実行して所定の演算や各部の制御を行うＣＰＵとプログラム実行時の作業領域となるメモリとを備えている（いずれも図示省略）。制御部１１は、記憶部１２に記憶されているプログラムとの協働により、各種の処理を実行する。

記憶部１２は、不揮発性の半導体メモリ等により構成される。記憶部１２には、制御部１１で実行されるシステムプログラムやアプリケーションプログラム、これらのプログラムの実行に必要なデータ等が記憶されている。また、記憶部１２には、例えば、ストアサーバー２０より通信ネットワークＮを介してダウンロードされた或るモバイルアプリ１２ａが記憶されている。

モバイルアプリ１２ａは、所謂アプリ内課金用のＡＰＩ（Application Programming Interface）が組み込まれており、当該ＡＰＩを用いることにより課金アイテム３２ａ（後述）を購入することができるようになっている。より詳細には、この課金アイテム３２ａの課金方式は、月額課金方式となっており、ユーザーは定期購読（自動更新の継続課金）の契約手続きを行うことで、この課金アイテム３２ａを利用することができるようになっている。

操作部１３は、各種機能キーを備え、ユーザーによる各キーの押下入力を受け付けてその操作情報を制御部１１に出力する。また、操作部１３は、表示部１４の表面を覆うように透明電極を格子状に配置したタッチパネル等を有し、手指やタッチペン等で押下された位置を検出し、その位置情報を操作情報として制御部１１に出力する。

表示部１４は、ＬＣＤ（Liquid Crystal Display）等により構成され、制御部１１からの表示制御信号に従って、画面上に各種表示を行う。

通信部１５は、無線により通信ネットワークＮに接続し、通信ネットワークＮに接続された外部機器との通信を行う。

＜クラウドサーバー３０の構成＞
次に、図３を参照して、クラウドサーバー３０の構成を説明する。図３は、クラウドサーバー３０の機能構成を示すブロック図である。

図３に示すように、クラウドサーバー（課金アイテム提供手段）３０は、制御部３１、記憶部３２、通信部３３等を備える。

制御部３１は、記憶部３２に記憶されている各種のプログラムを実行して所定の演算や各部の制御を行うＣＰＵとプログラム実行時の作業領域となるメモリとを備えている（いずれも図示省略）。制御部３１は、記憶部３２に記憶されているプログラムとの協働により、各種の処理を実行する。

記憶部３２は、不揮発性の半導体メモリ等により構成される。記憶部３２には、制御部３１で実行されるシステムプログラムやアプリケーションプログラム、これらのプログラムの実行に必要なデータ等が記憶されている。

また、記憶部３２には、上述のモバイルアプリ１２ａ内で使用することができる課金アイテム３２ａ等が記憶されている。制御部３１は、一のユーザーによる課金アイテム３２ａの支払い（定期購読）が承認されると、次回の支払い期限日までの間、当該一のユーザーが端末装置１０を介してログインしたモバイルアプリ１２ａ内において課金アイテム３２ａを利用できるようにする。

通信部３３は、モデム、ルータ、ネットワークカード等により構成される。通信部３３は、通信ネットワークＮを介して接続された外部機器とのデータ送受信を行う。

＜課金管理サーバー４０の構成＞
次に、図４を参照して、課金管理サーバー４０の構成を説明する。図４は、課金管理サーバー４０の機能構成を示すブロック図である。

図４に示すように、課金管理サーバー（課金管理装置）４０は、制御部４１、記憶部４２、通信部４３等を備える。

制御部（判定手段、第１の設定手段（設定手段）、第２の設定手段、報告手段）４１は、記憶部４２に記憶されている各種のプログラムを実行して所定の演算や各部の制御を行うＣＰＵとプログラム実行時の作業領域となるメモリとを備えている（いずれも図示省略）。制御部４１は、記憶部４２に記憶されているプログラムとの協働により、各種の処理を実行する。

記憶部４２は、不揮発性の半導体メモリ等により構成される。記憶部４２には、制御部４１で実行されるシステムプログラムやアプリケーションプログラム、これらのプログラムの実行に必要なデータ（猶予制御パラメータ情報４２ｂ（後述）を含む）等が記憶されている。

また、記憶部４２には、課金管理ＤＢ４２ａが設けられている。この課金管理ＤＢ４２ａには、課金アイテム３２ａを含む各種の課金アイテムを定期購読している各ユーザーの課金状態をそれぞれ管理するための管理データテーブルが記憶されている。

図５は、上記管理データテーブルを示す図である。なお、図５に示すデータテーブルは、例えば、２０１９年９月１０日の時点での課金状態を示すデータテーブルである。
図５に示すように、管理データテーブルには、例えば、「ユーザーコード」、「コンテンツ番号」、「購入デバイス」、「現レシート状態」、「初回の購入日」、「レシートの期限日」、「期限切れ理由」、「購入継続期間」、「承認購入継続期間」、「猶予期限」、「不承認（ペナルティ）回数」、「契約」等の項目が設けられており、これらの項目に関するデータが互いに対応付けられて記憶されるようになっている。

ここで、「ユーザーコード」とは、各ユーザーを識別するためのコードである。「コンテンツ番号」とは、各課金アイテムを識別するための番号である。「購入デバイス」とは、課金アイテムを購入する際に用いられた端末装置１０の種類を表すものである。「現レシート状態」とは、現レシート（課金管理サーバー４０で把握している最新のレシート）を基準として判断される支払いの状態（正常又は期限切れ）を示すものである。「初回の購入日」とは、対象となる課金アイテムを初めて購入した日である。「レシートの期限日」とは、次回の支払い期限日である。

「期限切れ理由」とは、上述の「レシートの期限日」の項目に示されている期限日を徒過した理由を示すものであり、“課金エラー”、“キャンセル”、“無し”のいずれかにより表される。“課金エラー”は、例えば、クレジットカードの有効期限が切れてしまったりプリペイドカードの残高が不足してしまったことが原因で支払い代金を回収することができなった場合に表記される。また、“キャンセル”は、対象となる課金アイテムの定期購読の契約をユーザーが解約した場合に表記される。また、“無し”は、期限日を徒過していない場合に表記される。「購入継続期間」とは、対象となる課金アイテムを継続して定期購読した期間である。つまり、「初回の購入日」から「レシートの期限日」までの期間を表している。「承認購入継続期間」とは、支払い期限を徒過することなく対象となる課金アイテムを継続して定期購読した期間である。したがって、一度支払い期限を徒過した場合は当該徒過した日から現在までの期間ということになる。なお、過去の課金アイテム３２ａの購読期間（購入期間）の中で支払い期限を徒過していない最長の期間を承認購入継続期間としてもよい。「猶予期限」とは、支払い期限を徒過した場合に設定される猶予期間（後述）に基づき導出される期限日である。なお、猶予期間を設定するタイミングは、支払期限を徒過したときに限定されるものではなく、例えば、課金アイテム３２ａの購入（購読の更新）時など他のタイミングであってもよい。「不承認（ペナルティ）回数」とは、過去に支払い期限を徒過した回数である。「契約状況」とは、現在の契約状況を示すものであり、モバイルアプリ１２ａにログインすることができるとともに対象となる課金アイテムを利用することもできる状態である“契約中”、モバイルアプリ１２ａにログインすることはできるが対象となる課金アイテムを利用することができない状態である“利用停止”、モバイルアプリ１２ａにログインすることも対象となる課金アイテムを利用することもできない状態である“自動解約”、モバイルアプリ１２ａにログインすることはできるが対象となる課金アイテムの定期購読の契約を解約したことにより当該課金アイテムを利用することができない状態である“自己解約”のいずれかにより表される。

ここで、上述した猶予期間の設定方法について説明する。
制御部４１は、上記管理データテーブルの「現レシート状態」の項目の情報が“正常”から“期限切れ”に変わったデータを対象として記憶部４２に記憶されている猶予制御パラメータ情報４２ｂを用いて猶予期間を設定する。
具体的には、制御部４１は、図６に示す猶予制御パラメータ情報４２ｂを用いることによって、承認購入継続期間が１０年以上の場合は２０日間、５年以上の場合は１０日間、３年以上の場合は５日間、１年以上の場合は３日間、１年未満の場合は０日間と、猶予期間の設定を行う。

また、上述した「契約状況」の項目の情報の設定方法について説明する。
制御部４１は、上記管理データテーブルの「猶予期限」の項目に示す猶予期限が過ぎたデータを対象として記憶部４２に記憶されている猶予制御パラメータ情報４２ｂを用いて「契約状況」の項目の情報を設定する。
具体的には、制御部４１は、図６に示す猶予制御パラメータ情報４２ｂを用いることによって、承認購入継続期間が５年以上の場合は、不承認回数に関わらず「契約状況」の項目の情報を“利用停止”と設定する。また、承認購入継続期間が１年以上、５年未満の場合は、不承認回数が３回未満であれば「契約状況」の項目の情報を“利用停止”と設定し、不承認回数が３回以上であれば「契約状況」の項目の情報を“自動解約”と設定する。また、承認購入継続期間が１年未満の場合は、不承認回数に関わらず「契約状況」の項目の情報を“自動解約”と設定する。なお、「契約状況」の項目の情報が“利用停止”と設定された場合、図５に示すように、この「契約状況」の項目には利用停止となった日（例えば、2019/8/30）が併せて記されるようになっている。また、「契約状況」の項目の情報が“自動解約”と設定された場合、図５に示すように、この「契約状況」の項目には自動解約となった日（例えば、2019/8/28）が併せて記されるようになっている。
また、制御部４１は、上記管理データテーブルの「猶予期限」の項目の情報が未設定の状態、又は、「猶予期限」の項目の情報は設定済の状態だが当該猶予期限が過ぎていないデータに関しては、「契約状況」の項目の情報を“契約中”と設定する。但し、対象となる課金アイテムの定期購読の契約をユーザーが解約している場合、制御部４１は、「契約状況」の項目の情報を“自己解約”と設定する。なお、「契約状況」の項目の情報が“自己解約”と設定された場合、図５に示すように、この「契約状況」の項目には自己解約の手続きを行った日（例えば、2019/7/25）が併せて記されるようになっている。

通信部４３は、モデム、ルータ、ネットワークカード等により構成される。通信部４３は、通信ネットワークＮを介して接続された外部機器とのデータ送受信を行う。

≪アプリ内課金システム１の動作≫
次に、各局面におけるアプリ内課金システム１の動作について、図７～図９を用いて説明する。

＜課金アイテム３２ａが購入されたときのアプリ内課金システム１の動作＞
図７は、課金アイテム３２ａが購入されたときのアプリ内課金システム１の動作の一例を示すフローチャートである。

図７に示すように、まず、端末装置１０は、自装置において起動中のモバイルアプリ１２ａ内で課金アイテム３２ａを購入するための手続き操作が操作部１３を介してなされると、当該課金アイテム３２ａの購入処理を行い、ストアサーバー２０に対して決済要求を行う（ステップＳ１）。

次いで、上記決済要求を受けたストアサーバー２０は、課金アイテム３２ａの購入に対するレシートを発行し、当該レシートを端末装置１０に送信する（ステップＳ２）。

次いで、上記レシートを受信した端末装置１０は、当該レシートと、自装置よりモバイルアプリ１２ａにログインしているユーザーのログイン情報とをクラウドサーバー３０に転送する（ステップＳ３）。

次いで、クラウドサーバー３０は、転送されてきたレシートを課金管理サーバー４０に転送するとともに、ログイン情報から抽出されたユーザーコードも課金管理サーバー４０に転送する（ステップＳ４）。

次いで、課金管理サーバー４０は、上記レシート及び上記ユーザーコードを受信すると、当該レシートが正当なレシートであるか否かの検証をストアサーバー２０に要求する（ステップＳ５）。

次いで、ストアサーバー２０は、課金管理サーバー４０による上記レシートの検証要求に基づいて、当該レシートの検証を行い、当該検証の結果を課金管理サーバー４０に送信する（ステップＳ６）。そして、ストアサーバー２０による処理を終了する。

次いで、課金管理サーバー４０は、受信した検証の結果をクラウドサーバー３０に報告する（ステップＳ７）。また、課金管理サーバー４０は、受信した検証の結果に基づいて、課金管理ＤＢ４２ａの情報を更新する（ステップＳ８）。具体的には、課金管理サーバー４０は、上記管理データテーブル（図５参照）のうちステップＳ１で課金アイテム３２ａを購入したユーザーのデータを更新する。例えば、ユーザーコードが“ａａａａａ”であるユーザーが契約中の課金アイテム３２ａの購読が２０１９年９月２５日に更新された場合、図５に示す「レシートの期限日」の項目の情報が“2019/10/25”に更新され、「購入継続期間」及び「承認購入継続期間」の項目の情報がそれぞれ“３年５ヶ月”に更新される。また、ユーザーコードが“ｄｄｄｄｄ”であるユーザーによって２０１９年９月２５日に課金アイテム３２ａの購読手続きが行われた場合、図５に示す「現レシート状態」の項目の情報が“正常”に更新され、「レシートの期限日」の項目の情報が“2019/10/25”に更新され、「期限切れ理由」の項目の情報が“無し”に更新され、「購入継続期間」の項目の情報が“４年６ヶ月”に更新され、「承認購入継続期間」の項目の情報が“０年１ヶ月”に更新され、「不承認回数」の項目の情報が“１”に更新され、「契約状況」の項目の情報が“契約中”に更新される。そして、課金管理サーバー４０による処理を終了する。

次いで、上記検証の結果の報告を受けたクラウドサーバー３０は、当該報告が正当なレシートである旨の報告である場合（ステップＳ９；ＹＥＳ）、ステップＳ１で課金アイテム３２ａを購入したユーザーによる当該課金アイテム３２ａの利用を許可し、当該ユーザーの端末装置１０に課金アイテム３２ａを提供する（ステップＳ１０）。そして、クラウドサーバー３０による処理を終了する。
一方、クラウドサーバー３０は、上記報告が正当なレシートでない旨の報告である場合（ステップＳ９；ＮＯ）、ステップＳ１で課金アイテム３２ａを購入したユーザーによる当該課金アイテム３２ａの利用を不許可とし、当該ユーザーの端末装置１０に対してエラー通知を行う（ステップＳ１１）。そして、クラウドサーバー３０による処理を終了する。

＜モバイルアプリ１２ａへのログイン操作が行われたときのアプリ内課金システム１の動作＞
図８は、モバイルアプリ１２ａへのログイン操作が行われたときのアプリ内課金システム１の動作の一例を示すフローチャートである。

図８に示すように、まず、端末装置１０は、モバイルアプリ１２ａへログインするための操作が操作部１３を介してなされると、当該モバイルアプリ１２ａへのログイン処理を行い、このとき操作部１３を介して入力されたログイン情報をクラウドサーバー３０に送信する（ステップＳ２１）。

次いで、上記ログイン情報を受信したクラウドサーバー３０は、当該ログイン情報からユーザーコードを抽出して当該ユーザーコードを課金管理サーバー４０に転送する（ステップＳ２２）。

次いで、上記ユーザーコードを受信した課金管理サーバー４０は、課金管理ＤＢ４２ａの管理データテーブル（図５参照）を用いて当該ユーザーコードを照合する（ステップＳ２３）。そして、課金管理サーバー４０は、当該ユーザーコードに関する照合結果をクラウドサーバー３０に報告する（ステップＳ２４）。そして、課金管理サーバー４０による処理を終了する。

次いで、クラウドサーバー３０は、課金管理サーバー４０からの報告に基づいて、上記ユーザーコードについての契約状況が“自己解約”であるか否かを判定する（ステップＳ２５）。

ステップＳ２５において、上記ユーザーコードについての契約状況が“自己解約”であると判定された場合（ステップＳ２５；ＹＥＳ）、クラウドサーバー３０は、上記ユーザーコードのユーザーによる課金アイテム３２ａの利用を不許可とし、当該ユーザーの端末装置１０に対して課金アイテム３２ａを利用できない旨の通知を行う（ステップＳ２６）。
一方、ステップＳ２５において、上記ユーザーコードについての契約状況が“自己解約”ではないと判定された場合（ステップＳ２５；ＮＯ）、クラウドサーバー３０は、上記ユーザーコードについての課金アイテム３２ａの支払いの猶予期限が過ぎているか否かを判定する（ステップＳ２７）。

ステップＳ２７において、課金アイテム３２ａの支払いの猶予期限はまだ過ぎていないと判定された場合（ステップＳ２７；ＮＯ）、クラウドサーバー３０は、上記ユーザーコードのユーザーによる当該課金アイテム３２ａの利用を許可し、当該ユーザーの端末装置１０に課金アイテム３２ａを提供する（ステップＳ２８）。
一方、ステップＳ２７において、課金アイテム３２ａの支払いの猶予期限が過ぎていると判定された場合（ステップＳ２７；ＹＥＳ）、クラウドサーバー３０は、課金管理サーバー４０からの報告に基づいて、上記ユーザーコードについての契約状況が“利用停止”であるか否かを判定する（ステップＳ２９）。

ステップＳ２９において、上記ユーザーコードについての契約状況が“利用停止”であると判定された場合（ステップＳ２９；ＹＥＳ）、クラウドサーバー３０は、上記ユーザーコードのユーザーによる課金アイテム３２ａの利用を不許可とし、当該ユーザーの端末装置１０に対して課金アイテム３２ａを利用できない旨の通知を行う（ステップＳ３０）。
一方、ステップＳ２９において、上記ユーザーコードについての契約状況が“利用停止”ではないと判定された場合（ステップＳ２９；ＮＯ）、クラウドサーバー３０は、課金管理サーバー４０からの報告に基づいて、上記ユーザーコードについての契約状況が“自動解約”であるか否かを判定する（ステップＳ３１）。

ステップＳ３１において、上記ユーザーコードについての契約状況が“自動解約”であると判定された場合（ステップＳ３１；ＹＥＳ）、クラウドサーバー３０は、上記ユーザーコードのユーザーによるモバイルアプリ１２ａへのログインを不許可とし、当該ユーザーの端末装置１０に対してログインすることができない旨の通知を行う（ステップＳ３２）。そして、クラウドサーバー３０による処理を終了する。
一方、ステップＳ３１において、上記ユーザーコードについての契約状況が“自動解約”ではないと判定された場合（ステップＳ３１；ＮＯ）、クラウドサーバー３０による処理を終了する。

＜課金管理サーバー４０とストアサーバー２０とによるポーリング動作＞
図９は、課金管理サーバー４０とストアサーバー２０とによるポーリング動作の一例を示すフローチャートである。

図９に示すように、まず、課金管理サーバー４０は、毎日、所定の時刻になると課金管理ＤＢ４２ａの管理データテーブルから猶予期間中であるユーザーコードのレシート情報を抽出し当該レシート情報をもとにストアサーバー２０に対してレシート状況を順次問い合わせる（ステップＳ３１）。ここで、レシート情報には、例えば、図５に示すように、管理データテーブルのうちの「ユーザーコード」及び「コンテンツ番号」以外の項目の情報、並びに、当該管理データテーブルでは図示を省略しているが「最終レシートデータ」の項目の情報が含まれる。

次いで、ストアサーバー２０は、問い合わせの結果を課金管理サーバー４０に対して報告する（ステップＳ３２）。そして、ストアサーバー２０による処理を終了する。

次いで、課金管理サーバー４０は、ストアサーバー２０から受けた報告は進捗が有る旨の報告であるか否かを判定する（ステップＳ３３）。

ステップＳ３３において、進捗が有る旨の報告であると判定された場合（ステップＳ３３；ＹＥＳ）、課金管理サーバー４０は、進捗が有ったユーザーコードの上記レシート情報を更新、より詳細には、例えば、図５に示す「現レシート状態」、「レシートの期限日」、「期限切れ理由」、「購入継続期間」、「承認購入継続期間」、「不承認回数」の各項目の情報を適宜修正して（ステップＳ３４）、処理をステップＳ３５へ進める。 一方、ステップＳ３３において、進捗が有る旨の報告ではないと判定された場合（ステップＳ３３；ＮＯ）、課金管理サーバー４０は、処理をステップＳ３５へ進める。

次いで、課金管理サーバー４０は、猶予期間中であるユーザーコードのレシート情報（対象レシート情報）のレシート状況を全て問い合わせしたか否かを判定する（ステップＳ３５）。

ステップＳ３５において、対象レシート情報のレシート状況を全て問い合わせしたと判定された場合（ステップＳ３５；ＹＥＳ）、課金管理サーバー４０による処理を終了する。
一方、ステップＳ３５において、対象レシート情報のレシート状況を全て問い合わせしていないと判定された場合（ステップＳ３５；ＮＯ）、課金管理サーバー４０は、処理をステップＳ３１へ戻し、それ以降の処理を繰り返し行う。

以上のように、本実施形態のアプリ内課金システム１の課金管理サーバー４０は、次回分の支払い期限が過ぎた課金アイテム３２ａの今回分の利用が制限されるまでの猶予期間を設定する。また、課金管理サーバー４０は、猶予期間を設定する際、前回又は今回までの課金アイテム３２ａの承認購入継続期間の長さに応じて当該猶予期間の長さを異ならせたこととなる。
したがって、本実施形態の課金管理サーバー４０によれば、課金アイテム３２ａの支払い期限を徒過してしまったユーザーを当該課金アイテム３２ａの承認購入継続期間に応じた処遇により適切に救済することができる。
また、猶予期間の設定を可能にする仕組みをアップル（登録商標）社やグーグル（登録商標）社などがそれぞれ独自に提供しているが、各社によって設定できる猶予期間は異なるため、ユーザーがどのストアサーバーを利用するかによって享受できる猶予期間が異なってしまい公平ではない。そこで、上記の仕組みを利用することなく、課金管理サーバー４０による独自の猶予期間の設定を行うことで、ユーザーがどのストアサーバーを利用したとしても統一された猶予期間を設定することができるので、ユーザーの救済にあたって公平性を維持することができる。

また、本実施形態の課金管理サーバー４０は、支払い期限が過ぎたと判定された場合、当該支払い期限が過ぎた課金アイテム３２ａの利用が制限されるまでの猶予期間を設定する。
したがって、本実施形態の課金管理サーバー４０によれば、支払い期限が過ぎたタイミングを基準として猶予期間を設定するので、当該猶予期間の設定を公正に行うことができる。

また、本実施形態の課金管理サーバー４０によれば、予め設定された複数の閾値によって区分される各区分期間に対応させて互いに長さが異なる猶予期間が設定されており、支払い期限が過ぎた課金アイテム３２ａのそれまでの承認購入継続期間の長さが当てはまる上記区分期間に対応する猶予期間を設定するので、当該猶予期間の設定を公正に且つ効率良く行うことができる。

また、本実施形態の課金管理サーバー４０は、上記猶予期間の間に支払いが行われなかった場合に、課金アイテム３２ａの利用を停止とするか当該課金アイテム３２ａが用いられるモバイルアプリ１２ａの契約を解約（自動解約）とするかを設定し、設定された課金アイテム３２ａの利用停止又はモバイルアプリ１２ａの契約の解約（自動解約）を当該課金アイテム３２ａを提供するクラウドサーバー（課金アイテム提供手段）３０に報告する。
したがって、本実施形態の課金管理サーバー４０によれば、猶予期間の間に支払いが行われなかった場合におけるクラウドサーバー３０の対象ユーザーへの対処を効率良くすることができる。

また、本実施形態の課金管理サーバー４０は、上記猶予期間の間に支払いが行われなかった場合、不承認回数が３回以上であって、且つ、課金アイテム３２ａの承認購入継続期間の長さが５年（閾値）以上であるとき、当該課金アイテム３２ａの利用を停止とする設定を行う一方で、不承認回数が３回以上であって、且つ、当該課金アイテム３２ａの承認購入継続期間の長さが５年（閾値）未満の場合、モバイルアプリ１２ａの契約を解約（自動解約）とする設定を行う。また、課金管理サーバー４０は、不承認回数が３回未満であって、且つ、課金アイテム３２ａの承認購入継続期間の長さが１年（閾値）以上であるとき、当該課金アイテム３２ａの利用を停止とする設定を行う一方で、不承認回数が３回未満であって、且つ、当該課金アイテム３２ａの承認購入継続期間の長さが１年（閾値）未満の場合、モバイルアプリ１２ａの契約を解約（自動解約）とする設定を行う。
したがって、本実施形態の課金管理サーバー４０によれば、課金アイテム３２ａの支払い猶予期間を徒過してしまったユーザーを当該課金アイテム３２ａの承認購入継続期間及び不承認回数に応じた処遇により適切に救済することができる。

以上、本発明を実施形態に基づいて具体的に説明してきたが、本発明は上記実施形態に限定されるものではなく、その要旨を逸脱しない範囲で変更可能である。
例えば、上記実施形態において、アプリ内課金システム１はセキュリティの観点からクラウドサーバー３０と課金管理サーバー４０とに分けているが、クラウドサーバー３０と課金管理サーバー４０を一つのサーバーとして統合してもよい。

また、上記実施形態において、課金管理サーバー４０は、猶予期間を設定する際、前回又は今回までの課金アイテム３２ａの承認購入継続期間の長さに応じて当該猶予期間の長さを異ならせるようにしたが、例えば、次回分の支払い期限が過ぎた課金アイテム３２ａについて過去に支払い期限が過ぎた回数に応じて当該猶予期間の長さを異ならせるようにしてもよい。かかる場合には、過去に支払い期限が過ぎた回数が増えれば増えるほど、猶予期間の長さが短くなるようにする。

また、上記実施形態において、「承認購入継続期間」の長さに応じて猶予期間の設定を行っていたが、単に「購入継続期間」の長さに応じて猶予期間の長さを異ならせるような構成にしてもよい。

また、上記実施形態において、「初回の購入日」から「レシートの期限日」までを「購入継続期間」として設定していたが、「初回の購入日」から「前回の課金アイテム購入日」までの期間を「購入継続期間」として設定してもよい。

また、上記実施形態において、課金管理サーバー４０の制御部４１は、図６に示す猶予制御パラメータ情報４２ｂを用いて猶予期間や当該猶予期間を過ぎた場合の契約の状態を設定するようにしたが、例えば、課金管理サーバー４０を管理するユーザーの操作に基づいて、制御部（変更手段）４１が当該猶予制御パラメータ情報４２ｂのパラメータを変更することができるようにしてもよい。

また、上記実施形態において、課金管理サーバー４０の制御部（通知手段）４１は、課金アイテム３２ａの支払い期限が過ぎたことにより猶予期間の設定がなされた場合、該当するユーザーの端末装置１０に対して当該猶予期間の設定がなされた旨を通知するようにしてもよい。

また、上記した実施形態では、本発明に係るプログラムのコンピューター読み取り可能な媒体として不揮発性の半導体メモリ等を使用した例を開示したが、この例に限定されない。その他のコンピューター読み取り可能な媒体として、ＣＤ－ＲＯＭ等の可搬型記録媒体を適用することが可能である。また、本発明に係るプログラムのデータを通信回線を介して提供する媒体として、キャリアウェーブ（搬送波）も適用される。

本発明の実施の形態を説明したが、本発明の範囲は、上述の実施の形態に限定するものではなく、特許請求の範囲に記載された発明の範囲とその均等の範囲を含む。
以下に、この出願の願書に最初に添付した特許請求の範囲に記載した発明を付記する。付記に記載した請求項の項番は、この出願の願書に最初に添付した特許請求の範囲の通りである。
〔付記〕
＜請求項１＞
次回分の支払期限が過ぎた課金アイテムの今回分の利用が制限されるまでの猶予期間を設定する第１の設定手段を備え、
前記第１の設定手段は、前記猶予期間を設定する際、前回又は今回までの前記課金アイテムの購入継続期間の長さに応じて当該猶予期間の長さを異ならせることを特徴とする課金管理装置。
＜請求項２＞
前記課金アイテムの次回分の支払期限が過ぎたか否かを判定する判定手段を備え、
前記第１の設定手段は、前記判定手段によって前記支払期限が過ぎたと判定された場合、当該支払期限が過ぎた課金アイテムの利用が制限されるまでの猶予期間を設定することを特徴とする請求項１に記載の課金管理装置。
＜請求項３＞
予め設定された複数の閾値によって区分される各区分期間に対応させて互いに長さが異なる猶予期間が設定されており、
前記第１の設定手段は、前記支払期限が過ぎた課金アイテムのそれまでの購入継続期間の長さが当てはまる前記区分期間に対応する猶予期間を設定することを特徴とする請求項１又は２に記載の課金管理装置。
＜請求項４＞
次回分の支払期限が過ぎた課金アイテムの今回分の利用が制限されるまでの猶予期間を設定する第１の設定手段を備え、
前記第１の設定手段は、前記猶予期間を設定する際、前記次回分の支払期限が過ぎた課金アイテムについて過去に支払期限が過ぎた回数に応じて当該猶予期間の長さを異ならせることを特徴とする課金管理装置。
＜請求項５＞
前記猶予期間の間に支払いが行われなかった場合に、前記課金アイテムの利用を停止とするか当該課金アイテムが用いられるアプリケーションの契約を解約とするかを設定する第２の設定手段と、
前記第２の設定手段によって設定された前記課金アイテムの利用停止又は前記アプリケーションの契約の解約を当該課金アイテムを提供する課金アイテム提供手段に報告する報告手段と、
を備えることを特徴とする請求項１～４のいずれか一項に記載の課金管理装置。
＜請求項６＞
前記第２の設定手段は、前記課金アイテムの前記購入継続期間の長さが閾値以上の場合、当該課金アイテムの利用を停止とする設定を行う一方で、当該課金アイテムの前記購入継続期間の長さが閾値未満の場合、前記アプリケーションの契約を解約とする設定を行うことを特徴とする請求項５に記載の課金管理装置。
＜請求項７＞
前記第２の設定手段は、更に、前記次回分の支払期限が過ぎた課金アイテムについて過去に支払期限が切れた回数に応じて前記閾値の値を異ならせることを特徴とする請求項６に記載の課金管理装置。
＜請求項８＞
前記第１の設定手段により前記猶予期間を設定する際の条件と、前記第２の設定手段により前記課金アイテムの利用を停止とするか前記アプリケーションの契約を解約とするかを設定する際の条件と、のうちの少なくともいずれか一の条件をユーザー操作に基づき変更可能とする変更手段を備えることを特徴とする請求項６又は７に記載の課金管理装置。
＜請求項９＞
前記第１の設定手段により前記猶予期間が設定された場合、当該猶予期間が設定された課金アイテムの購入者に対して当該猶予期間が設定された旨の通知を行う通知手段を備えることを特徴とする１～８のいずれか一項に記載の課金管理装置。
＜請求項１０＞
課金管理装置のコンピューターを、
次回分の支払期限が過ぎた課金アイテムの利用が制限されるまでの猶予期間を設定する設定手段を備え、
前記設定手段は、前記猶予期間を設定する際、前回又は今回までの前記課金アイテムの購入継続期間の長さに応じて当該猶予期間の長さを異ならせることを特徴とするプログラム。
＜請求項１１＞
課金管理装置のコンピューターを、
次回分の支払期限が過ぎた課金アイテムの今回分の利用が制限されるまでの猶予期間を設定する設定手段を備え、
前記設定手段は、前記猶予期間を設定する際、前記次回分の支払期限が過ぎた課金アイテムについて過去に支払期限が過ぎた回数に応じて当該猶予期間の長さを異ならせることを特徴とするプログラム。

１ アプリ内課金システム
１０ 端末装置
１２ａ モバイルアプリ
２０ ストアサーバー
３０ クラウドサーバー（課金アイテム提供手段）
３２ａ 課金アイテム
４０ 課金管理サーバー（課金管理装置）
４１ 制御部（判定手段、第１の設定手段（設定手段）、第２の設定手段、報告手段）

Claims (11)

1. 次回分の支払期限が過ぎた課金アイテムの今回分の利用が制限されるまでの猶予期間を設定する第１の設定手段を備え、
   前記第１の設定手段は、前記猶予期間を設定する際、前回又は今回までの前記課金アイテムの購入継続期間の長さに応じて当該猶予期間の長さを異ならせることを特徴とする課金管理装置。
2. 前記課金アイテムの次回分の支払期限が過ぎたか否かを判定する判定手段を備え、
   前記第１の設定手段は、前記判定手段によって前記支払期限が過ぎたと判定された場合、当該支払期限が過ぎた課金アイテムの利用が制限されるまでの猶予期間を設定することを特徴とする請求項１に記載の課金管理装置。
3. 予め設定された複数の閾値によって区分される各区分期間に対応させて互いに長さが異なる猶予期間が設定されており、
   前記第１の設定手段は、前記支払期限が過ぎた課金アイテムのそれまでの購入継続期間の長さが当てはまる前記区分期間に対応する猶予期間を設定することを特徴とする請求項１又は２に記載の課金管理装置。
4. 次回分の支払期限が過ぎた課金アイテムの今回分の利用が制限されるまでの猶予期間を設定する第１の設定手段を備え、
   前記第１の設定手段は、前記猶予期間を設定する際、前記次回分の支払期限が過ぎた課金アイテムについて過去に支払期限が過ぎた回数に応じて当該猶予期間の長さを異ならせることを特徴とする課金管理装置。
5. 前記猶予期間の間に支払いが行われなかった場合に、前記課金アイテムの利用を停止とするか当該課金アイテムが用いられるアプリケーションの契約を解約とするかを設定する第２の設定手段と、
   前記第２の設定手段によって設定された前記課金アイテムの利用停止又は前記アプリケーションの契約の解約を当該課金アイテムを提供する課金アイテム提供手段に報告する報告手段と、
   を備えることを特徴とする請求項１～３のいずれか一項に記載の課金管理装置。
6. 前記第２の設定手段は、前記課金アイテムの前記購入継続期間の長さが閾値以上の場合、当該課金アイテムの利用を停止とする設定を行う一方で、当該課金アイテムの前記購入継続期間の長さが閾値未満の場合、前記アプリケーションの契約を解約とする設定を行うことを特徴とする請求項５に記載の課金管理装置。
7. 前記第２の設定手段は、更に、前記次回分の支払期限が過ぎた課金アイテムについて過去に支払期限が切れた回数に応じて前記閾値の値を異ならせることを特徴とする請求項６に記載の課金管理装置。
8. 前記第１の設定手段により前記猶予期間を設定する際の条件と、前記第２の設定手段により前記課金アイテムの利用を停止とするか前記アプリケーションの契約を解約とするかを設定する際の条件と、のうちの少なくともいずれか一の条件をユーザー操作に基づき変更可能とする変更手段を備えることを特徴とする請求項６又は７に記載の課金管理装置。
9. 前記第１の設定手段により前記猶予期間が設定された場合、当該猶予期間が設定された課金アイテムの購入者に対して当該猶予期間が設定された旨の通知を行う通知手段を備えることを特徴とする請求項１～８のいずれか一項に記載の課金管理装置。
10. 課金管理装置のコンピューターを、
    次回分の支払期限が過ぎた課金アイテムの利用が制限されるまでの猶予期間を設定する設定手段を備え、
    前記設定手段は、前記猶予期間を設定する際、前回又は今回までの前記課金アイテムの購入継続期間の長さに応じて当該猶予期間の長さを異ならせることを特徴とするプログラム。
11. 課金管理装置のコンピューターを、
    次回分の支払期限が過ぎた課金アイテムの今回分の利用が制限されるまでの猶予期間を設定する設定手段を備え、
    前記設定手段は、前記猶予期間を設定する際、前記次回分の支払期限が過ぎた課金アイテムについて過去に支払期限が過ぎた回数に応じて当該猶予期間の長さを異ならせることを特徴とするプログラム。

Images