JP7175841B2 - デジタルコンテンツ提供装置、デジタルコンテンツ提供方法、プログラム - Google Patents

Description

特許法第３０条第２項適用 平成３０年１２月１３日ウェブサイトにて掲戴（ｈｔｔｐｓ：／／ｇａｍｅｓ．ｇｒｅｅ．ｎｅｔ／ｓｔａｔｉｃ／ｐａｇｅ／ａｎｎｏｕｎｃｅａ＿２０１８１２１３？ｎａｍｅｓｐａｃｅ＝ＧＧＰ．Ａｎｎｏｕｎｃｅ．Ｉｎｆｏ）

本開示は、デジタルコンテンツ提供装置、デジタルコンテンツ提供方法、プログラムに関する。

ユーザによるコンテンツ（ニュース記事）の要求やコンテンツに対するコメントの投稿のような行動情報に基づいて、ユーザの性質を示す称号をユーザに付与し、ユーザに付与された称号に関する情報に基づいて与信に関するサービスを提供する技術が知られている。

特開２０１９－０４０６０７号公報

しかしながら、従来技術では、ユーザの負担を低減した利便性の高い態様で、後払いを条件としたデジタルコンテンツの提供を可能とすることが難しい。

そこで、１つの側面では、本発明は、ユーザの負担を低減した利便性の高い態様で、後払いを条件としたデジタルコンテンツの提供を可能とすることを目的とする。

１つの側面では、ユーザ識別情報に対応付けられたログ情報を取得するログ情報取得部と、
デジタルコンテンツに係る対価の支払いであって、前記デジタルコンテンツを提供した後の所定期限までの前記ユーザ識別情報に係るユーザによる対価の支払いを条件として、前記ログ情報に基づいて、前記ユーザ識別情報に係るユーザに前記デジタルコンテンツを提供するサービス提供部とを含む、デジタルコンテンツ提供装置が提供される。

１つの側面では、本発明によれば、ユーザの負担を低減した利便性の高い態様で、後払いを条件としたデジタルコンテンツの提供が可能となる。

本発明の一実施形態に係るサービス提供システムのブロック図である。 対戦ゲームパートの概要の説明用のプレイ画面の一例を示す。 端末装置におけるサイトＡの表示画面の一例を示す図である。 後払いの流れの説明図である。 サーバ装置が実現する各種機能のうちの、後払い機能に関連する機能に関する機能ブロック図である。 ユーザ情報データベース内のデータの説明図である。 ゲームに関する情報の説明図である。 ログ情報データベース内のデータの説明図である。 指標値データベース内のデータの説明図である。 請求情報データベース内のデータの説明図である。 後払い情報データベース内のデータの説明図である。 催促情報の出力態様の一例を示す図である。 催促情報の出力態様の他の一例を示す図である。 後払い機能の利用可否の判定に関する動作例を示す概略フローチャートである。 ユーザによる後払い機能の利用場面に関する動作例を示す概略フローチャートである。 請求書情報の出力に関連した動作例を示す概略フローチャートである。 活動制限処理に関連した動作例を示す概略フローチャートである。 支払い通知に基づく支払状況カテゴリの更新処理（図１７のステップＳ１７２）の一例を示す概略フローチャートである。 未払い時間に応じた請求書情報の更新処理（図１７のステップＳ１７４）の一例を示す概略フローチャートである。 支払状況カテゴリに応じた活動制限処理（図１７のステップＳ１７６）の一例を示す概略フローチャートである。 所定操作に応じた催促情報の出力処理の一例を示す概略フローチャートである。 支払状況カテゴリの変化に応答した催促情報の出力処理の一例を示す概略フローチャートである。

以下、添付図面を参照しながら各実施形態について詳細に説明する。

（サービス提供システムの概要）
図１を参照して、本発明の一実施形態に係るサービス提供システム１の概要について説明する。サービス提供システム１は、サーバ装置１０と、１つ以上の端末装置２０と、を備える。図１では簡便のため、３つの端末装置２０を図示しているが、端末装置２０の数は２つ以上であればよい。

サーバ装置１０は、例えばサービス運営者が管理するサーバ等の情報処理装置である。本実施形態では、一例として、サーバ装置１０は、いわゆるサービスプラットホームを実現し、サービスプラットホームを介して、各種のサービスを提供する。具体的には、サーバ装置１０は、一例として、アプリポータルサイト（以下、単に「サイト」とも称する）と、アプリケーション・ソフトウェア（以下、単に「アプリケーション」とも称する）と、ソーシャルネットワーク機能（以下、単に「ＳＮＳ機能」とも称する）とを、登録ユーザ（及び必要に応じてゲストユーザ）に提供する。以下、登録ユーザ（及び必要に応じてゲストユーザ）について、単に「ユーザ」とも称する。

サーバ装置１０が提供するサイトの数は、任意であるが、本実施形態では、一例として、１つのサイト（以下、「サイトＡ」とも称する）であるものとする。

サーバ装置１０が提供するアプリケーションの種類や数は、任意であるが、本実施形態では、一例として、サーバ装置１０が提供するアプリケーションは、ゲーム用のアプリケーション（以下、単に「ゲームアプリ」とも称する）を含み、その他、デジタルコンテンツ（ゲームアプリ以外のデジタルコンテンツであり、後述）を利用するための各種のアプリケーションを含んでよい。ゲームアプリ等は、サイトＡを介して実行可能とされてよい。以下、ゲームとは、サーバ装置１０が提供するゲームアプリに係るゲームを指す。

サーバ装置１０が提供するＳＮＳ機能の種類や数は、任意であるが、ここでは、日記や、チャット、伝言板／掲示板（コミュニティ）、コメント、メッセンジャー、友達リクエスト、オブジェクトの送信（贈り物の送信）等のような機能であってよい。ＳＮＳ機能は、サイトＡを介して実行可能とされてよい。

端末装置２０は、例えば携帯電話、スマートフォン、タブレット端末、ＰＣ（Ｐｅｒｓｏｎａｌ Ｃｏｍｐｕｔｅｒ）、又はゲーム装置等の、ユーザによって使用される情報処理装置である。端末装置２０は、本実施形態に係る各種アプリケーションを実行可能である。各種アプリケーションは、ネットワーク３を介してサーバ装置１０又は他の所定のアプリケーション配信サーバから端末装置２０に受信されてもよく、あるいは端末装置２０に備えられた記憶装置又は端末装置２０が読取可能なメモリカード等の記憶媒体に予め記憶されていてもよい。サーバ装置１０及び端末装置２０は、ネットワーク３を介して通信可能に接続される。例えば、サーバ装置１０及び端末装置２０が協働して、サービスに関する多様な処理を実行する。

なお、ネットワーク３は、無線通信網や、インターネット、ＶＰＮ（Ｖｉｒｔｕａｌ Ｐｒｉｖａｔｅ Ｎｅｔｗｏｒｋ）、ＷＡＮ（Ｗｉｄｅ Ａｒｅａ Ｎｅｔｗｏｒｋ）、有線ネットワーク、又はこれらの任意の組み合わせ等を含んでよい。

（サーバ装置の構成）
サーバ装置１０の構成について具体的に説明する。サーバ装置１０は、サーバコンピュータにより構成される。サーバ装置１０は、複数台のサーバコンピュータにより協動して実現されてもよい。

サーバ装置１０は、サーバ通信部１１と、サーバ記憶部１２と、サーバ制御部１３と、を備える。

サーバ通信部１１は、外部装置と無線又は有線によって通信し、情報の送受信を行うインタフェースを含む。サーバ通信部１１は、例えば無線ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）通信モジュール又は有線ＬＡＮ通信モジュール等を含んでもよい。サーバ通信部１１は、ネットワーク３を介して、端末装置２０との間で情報を送受信可能である。

サーバ記憶部１２は、例えば一次記憶装置及び二次記憶装置を含む。例えばサーバ記憶部１２は、半導体メモリ、磁気メモリ、又は光メモリ等を含んでもよい。サーバ記憶部１２は、サービスに関する処理に用いられる種々の情報及びプログラムを記憶する。サーバ記憶部１２に記憶された情報及びプログラムの少なくとも一部が、端末装置２０との間で共有及び同期されてもよい。以下、サーバ記憶部１２が記憶する情報の例について具体的に説明する。

サーバ制御部１３は、１つ以上のプロセッサを含む。プロセッサは、特定のプログラムを読み込むことにより特定の機能を実現する汎用プロセッサ、及び特定の処理に特化した専用プロセッサを含んでもよい。サーバ制御部１３は、サーバ装置１０全体の動作を制御する。サーバ制御部１３の詳細は後述する。

（端末装置の構成）
端末装置２０の構成について具体的に説明する。図１に示すように、端末装置２０は、端末通信部２１と、端末記憶部２２と、表示部２３と、入力部２４と、端末制御部２５とを備える。

端末通信部２１は、外部装置と無線又は有線によって通信し、情報の送受信を行うインタフェースを含む。端末通信部２１は、例えばＬＴＥ（Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ）（登録商標）等のモバイル通信規格に対応する無線通信モジュール、無線ＬＡＮ通信モジュール、又は有線ＬＡＮ通信モジュール等を含んでもよい。端末通信部２１は、ネットワーク３を介して、サーバ装置１０との間で情報を送受信可能である。

端末記憶部２２は、例えば一次記憶装置及び二次記憶装置を含む。例えば端末記憶部２２は、半導体メモリ、磁気メモリ、又は光メモリ等を含んでもよい。端末記憶部２２は、サーバ装置１０から受信する、サービスに関する処理に用いられる種々の情報及びプログラムを記憶する。サービスに関する処理に用いられる情報及びプログラムは、端末通信部２１を介して外部装置から取得されてもよい。例えば、ゲームアプリが、所定のアプリケーション配信サーバから取得されてもよい。

表示部２３は、例えば液晶ディスプレイ又は有機ＥＬ（Ｅｌｅｃｔｒｏ－Ｌｕｍｉｎｅｓｃｅｎｃｅ）ディスプレイ等の表示デバイスを含む。表示部２３は、多様な画面を表示可能である。

入力部２４は、例えば表示部２３と一体的に設けられたタッチパネルを含む入力インタフェースを含む。入力部２４は、端末装置２０に対するユーザ入力を受付可能である。また、入力部２４は、物理キーを含んでもよいし、マウス等のようなポインティングデバイスをはじめとする任意の入力インタフェースを更に含んでもよい。

端末制御部２５は、１つ以上のプロセッサを含む。端末制御部２５は、端末装置２０全体の動作を制御する。以下、端末制御部２５の動作の例について具体的に説明する。

端末制御部２５は、端末通信部２１を介して情報の送受信を行う。例えば、端末制御部２５は、サービスに関する処理に用いられる種々の情報及びプログラムを、サーバ装置１０及び他の外部サーバの少なくとも一方から受信する。端末制御部２５は、受信された情報及びプログラムを、端末記憶部２２に記憶する。

端末制御部２５は、ユーザの操作に応じて、サイトＡや、サイトＡ内のゲームアプリ等を起動する。端末制御部２５は、サーバ装置１０と協働して、サービスに関する処理を実行する。例えば、端末制御部２５は、サービスに関する処理に係る種々の画面を表示部２３に表示させる。画面上には、例えばユーザ操作を検出するＧＵＩ（Ｇｒａｐｈｉｃ Ｕｓｅｒ Ｉｎｔｅｒｆａｃｅ）が表示されてもよい。端末制御部２５は、入力部２４を介して、画面に対するユーザ操作を検出可能である。

（ゲームアプリの概要）
本実施形態に係るゲームアプリの一例の概要について説明する。本実施形態に係るゲームは、１つ以上のゲームパートを含む。１つ以上のゲームパートのうち少なくとも１つのゲームパートは、ゲーム媒体を用いて実行されてもよい。

ゲーム媒体は、ゲームに使用される電子データであり、例えば、カード、アイテム、ポイント、仮想通貨、チケット、キャラクタ、アバタ、パラメータ等、任意の媒体を含む。また、ゲーム媒体は、レベル情報、ステータス情報、パラメータ情報（体力値及び攻撃力等）又は能力情報（スキル、アビリティ、呪文、ジョブ等）のような、ゲーム関連情報であってもよい。また、ゲーム媒体は、ユーザによってゲーム内で取得、所有、使用、管理、交換、合成、強化、売却、廃棄、又は贈与等され得る電子データであるが、ゲーム媒体の利用態様は本明細書で明示されるものに限られない。

以下、特に明示した場合を除き、「ユーザが所有するゲーム媒体」とは、当該ユーザを一意に識別可能なユーザＩＤに所有ゲーム媒体として対応付けられたゲーム媒体を示す。また、「ゲーム媒体をユーザに付与する」とは、ゲーム媒体を所有ゲーム媒体としてユーザＩＤに対応付けることを示す。また、「ユーザが所有するゲーム媒体を破棄する」とは、ユーザＩＤと所有ゲーム媒体との対応付けを解消することを示す。また、「ユーザが所有するゲーム媒体を消費する」とは、ユーザＩＤと所有ゲーム媒体との対応付けの解消に応じて、何らかの効果又は影響をゲーム内で発生させ得ることを示す。また、「ユーザが所有するゲーム媒体を売却する」とは、ユーザＩＤと所有ゲーム媒体との対応付けを解消し、且つ、ユーザＩＤに他のゲーム媒体（例えば、仮想通貨又はアイテム等）を所有ゲーム媒体として対応付けることを示す。また、「ユーザＡが所有するゲーム媒体をユーザＢに譲渡する」とは、ユーザＡのユーザＩＤと所有ゲーム媒体との対応付けを解消し、且つ、ユーザＢのユーザＩＤに当該ゲーム媒体を所有ゲーム媒体として対応付けることを示す。また、「ゲーム媒体を作成する」とは、ゲーム媒体に関する情報の少なくとも一部を定義又は決定することを示す。

ゲームパートは、ゲーム内でユーザがプレイ可能なコンテンツであって、例えばクエスト、ミッション、ミニゲーム、ゲーム媒体の育成、強化、及び合成、ゲーム媒体入手イベント、仮想空間の探索イベント、並びに対戦相手（例えば、他のユーザ、敵キャラクタ、及び敵の建物等）との対戦イベント等を含む。各ゲームパートには、１つ以上の所定の課題（ゲーム課題）が設定されてもよい。例えば、ユーザによってプレイされるゲームパートに設定された１つ以上のゲーム課題の達成に成功したと判定された場合、ユーザに対して、例えばゲーム媒体等が報酬として付与されてもよい。ゲーム課題には、例えば敵キャラクタとの対戦に勝利するとの課題、仮想空間内のゴール地点まで到達するとの課題、及び所定時間が経過するまでユーザのキャラクタが所定の状態（例えば、行動不能の状態）にならないとの課題等、ゲームパートの内容に応じた任意の課題が採用可能である。また、ゲームパートに設定された１つ以上のゲーム課題のうち、特定の課題（クリア課題）が達成されることを、ゲームパートのクリアともいう。ゲームパートをプレイするユーザがクリア課題の達成に成功した場合、当該ゲームパートのクリアと判定され、当該ゲームパートが終了してもよい。

１つ以上のゲームパートには、シングルプレイ用のゲームパートと、マルチプレイ用のゲームパートと、が含まれてもよい。シングルプレイ用のゲームパートは、例えば、１人のユーザが使用する１つの端末装置２０に対するユーザ操作に基づいて実行されるゲームパート（例えば、一人用のゲームパート）を含んでもよい。例えば、１つの端末装置２０が単独で、又は１つの端末装置２０とサーバ装置１０とが協働して、シングルプレイ用のゲームパートを実行する。一方、マルチプレイ用のゲームパートは、例えば、２人以上のユーザがそれぞれ使用する２つ以上の端末装置２０に対するユーザ操作に基づいて実行される、当該２人以上のユーザに共通のゲームパート（例えば、複数人用のゲームパート）を含んでもよい。２人以上のユーザに共通のゲームパートは、例えば、当該ゲームパートの進行処理の少なくとも一部及び処理結果の少なくとも一部が、当該２人以上のユーザに対して共通して適用されるゲームパートを含んでもよい。例えば、２つ以上の端末装置２０が協働して、又は２つ以上の端末装置２０とサーバ装置１０とが協働して、マルチプレイ用のゲームパートを実行する。１つのゲームパートが、シングルプレイ及びマルチプレイの両方に対応してもよい。

本実施形態に係るゲームは、一例として、例えば横スクロール型のアクションゲームの要素と、ゲーム媒体を用いて対戦相手と対戦する対戦ゲームの要素と、を有する対戦ゲームパートを含む。ユーザは、自身が所有するゲーム媒体（所有ゲーム媒体）のうちから、対戦ゲームパートに使用する１つ以上のゲーム媒体を選択する。以下、対戦ゲームパートに使用される各ゲーム媒体を、第１ゲーム媒体ともいう。当該１つ以上の第１ゲーム媒体を纏めてデッキ又はチームともいう。対戦相手は、例えばＮＰＣ（Ｎｏｎ－Ｐｌａｙｅｒ Ｃｈａｒａｃｔｅｒ）等の自動的に操作されるゲーム媒体であるが、これに限られない。例えば、対戦相手は、他のユーザによって操作されるゲーム媒体であってもよい。１つの対戦ゲームパートにおいて、対戦相手の数は任意に定められてもよい。

本実施形態に係る対戦ゲームパートの概要について図２を参照して概説する。図２は、対戦ゲームパートの概要の説明用のプレイ画面の一例を示す。

端末装置２０を用いてシングルプレイ用の対戦ゲームパートをプレイするユーザは、例えば仮想空間内に配置された移動オブジェクト１４０を操作して、障害物等を避けつつ所定のアイテムを取得する。移動オブジェクト１４０は、所定のゲーム媒体（第２ゲーム媒体）に対応する。第２ゲーム媒体は、例えば、路面１４１上を走行するバイク、自動車、又は人物等を含んでもよい。アイテム１４２の取得に応じて、デッキに含まれるゲーム媒体（第１ゲーム媒体Ａ１、Ｂ、Ｃ、Ｄ、Ｅ）が、所定の行動（例えば、対戦相手に対する攻撃）を行う。第１ゲーム媒体の行動によって、対戦相手（図２では、対戦相手に係るオブジェクト１４４が表示）にダメージを与えられ得る。一方、対戦相手は、例えば所定の時間間隔で、所定の行動（例えば、ユーザに対する攻撃）を行う。対戦相手の行動によって、ユーザ（図２では、ユーザに係るオブジェクト１４３が表示）にダメージが与えられ得る。ユーザ及び対戦相手それぞれには、与えられたダメージの量だけ減少する所定のパラメータ（合計ＨＰ及びＨＰ）が設定されている。なお、図２において、画像領域１４５は、合計ＨＰの残りをゲージで表示する領域であり、画像領域１４８は、対戦相手のＨＰの残りをゲージで表示する領域であり、画像領域１４９は、デッキに含まれる各第１ゲーム媒体の状態を示す領域である。対戦相手の当該パラメータが所定値（例えば、ゼロ）まで減少すると、ユーザの勝利と判定される。一方、ユーザの当該パラメータが所定値（例えば、ゼロ）まで減少すると、ユーザの敗北と判定される。ユーザの勝利又は敗北と判定された場合、当該対戦ゲームパートが終了してもよい。

一方、マルチプレイ用の対戦ゲームパートは、２人以上のユーザが共通の対戦相手と対戦する点を除き、上述したシングルプレイ用の対戦ゲームパートと同様に実行される。具体的には、２人以上のユーザそれぞれは、自身の端末装置２０を用いて、共通の対戦ゲームパートをプレイする。当該２人以上のユーザそれぞれは、上述のように仮想空間内の第２ゲーム媒体を操作する。当該２人以上のユーザに共通の仮想空間が用いられてもよいし、ユーザごとに独立した仮想空間が用いられてもよい。当該２人以上のユーザそれぞれのデッキに含まれる第１ゲーム媒体が、例えば共通の対戦相手に対して攻撃を行う。対戦相手の上述したパラメータは、２人以上のユーザに対して共通に適用される。例えば、２人以上のユーザがそれぞれ使用する複数の端末装置２０の間で、対戦相手の当該パラメータが同期されてもよい。対戦相手の当該パラメータが所定値（例えば、ゼロ）まで減少すると、２人以上のユーザの勝利と判定される。一方、２人以上のユーザそれぞれの当該パラメータが所定値（例えば、ゼロ）まで減少すると、２人以上のユーザの敗北と判定される。２人以上のユーザの勝利又は敗北と判定された場合、当該対戦ゲームパートが終了してもよい。

なお、上述したゲームは、あくまで一例であり、本実施形態は、一般的なＲＰＧ（Ｒｏｌｅ Ｐｌａｙｉｎｇ Ｇａｍｅ）以外にも、釣りゲーム、ランゲーム、ダンジョンゲーム、オセロゲーム、格闘ゲーム、街づくりゲーム、競馬ゲーム、野球ゲームのようなスポーツゲーム、シューティングゲーム等にも適用できる。

（後払い機能の概要）
本実施形態では、サーバ装置１０は、更に、サイトＡを介して、後払いを条件としてユーザにデジタルコンテンツを提供できる機能（以下、「後払い機能」とも称する）を有する。

ここで、デジタルコンテンツとは、各種の電子データであり、音楽や動画のような視聴可能なコンテンツや、電子書籍のような可読なコンテンツ、ゲームアプリのようなプレイ可能なコンテンツ、ニュースや記事などの情報コンテンツ等を含む。また、本実施形態では、デジタルコンテンツとは、サイトＡで使用される電子データを含み、サイトＡで使用される電子データは、例えば、カード、アイテム、ポイント、仮想通貨、チケット、キャラクタ、アバタ、パラメータ等、任意の媒体を含む。また、サイトＡで使用される電子データは、ゲームアプリで使用されるゲーム媒体を含む。ゲーム媒体は、上述したとおりである。

本実施形態では、一例として、後払い機能が提供するデジタルコンテンツは、サイトＡで利用できるコイン（以下、「Ａコイン」と称する）であるとし、ユーザは、所持するＡコインを消費することで、他のデジタルコンテンツの提供を受けることができる。

ここで、一のユーザへのデジタルコンテンツの提供とは、当該一のユーザに対して、当該デジタルコンテンツを利用可能な状態にすることを指し、“利用可能な状態”の“利用”とは、当該デジタルコンテンツの属性に応じて異なる。例えば、当該デジタルコンテンツが所定数のＡコインである場合、当該一のユーザに係るユーザＩＤに対応付けられたＡコイン数に、所定数を付加することであってよい。また、当該デジタルコンテンツが視聴可能なコンテンツである場合、当該一のユーザに係るユーザＩＤに対応付けられた端末装置２０を介して、当該視聴可能なコンテンツを再生することであってよい。

次に、図３及び図４を参照して、後払い機能について概説する。

図３は、端末装置２０におけるサイトＡの表示画面の一例を示す図であり、図４は、後払いの流れの説明図である。

図３には、サイトＡのホーム画面（マイページ）Ｇ５０が示される。ホーム画面Ｇ５０は、ゲームコーナへの遷移が可能なボタンＢ５１等の中に、後払い機能に係るボタンＢ５０が設定されている。ボタンＢ５０には、“後払いで購入”という文字が付され、後払いでＡコインが購入可能であることがユーザに伝わりやすくなっている。ユーザは、ボタンＢ５０を操作することで、サイトＡのホーム画面から、後払いで購入するＡコインの数等を指定できる申込み画面（図示せず）へと遷移させることができる。なお、変形例では、画面Ｇ５０は、ホーム画面ではなく、別のホーム画面から遷移可能な画面であってもよい。

ここで、後払いとは、通常通りの意味であるが、デジタルコンテンツの提供に対する対価の支払いが、デジタルコンテンツの提供の後まで猶予される支払い決済方法である。本実施形態では、一例として、後払い機能を利用するユーザは、デジタルコンテンツの提供を受けた後に、コンビニエンスストア（以下、「コンビニ」と略する）や郵便局、ＡＴＭ（Ａｕｔｏｍａｔｉｃ Ｔｅｌｌｅｒ Ｍａｃｈｉｎｅ）等で、対価に対応する代金を支払う必要がある。

本実施形態では、一例として、後払いで提供可能なデジタルコンテンツは、Ａコインであり、他のデジタルコンテンツ（対価の支払いが必要なデジタルコンテンツ）は、Ａコインを介して提供可能であるものとする。なお、以下の説明において、ユーザがＡコインの提供を受けることは、ユーザがＡコインを購入することと同義である。

図４に示す例では、ある月をＮ月とすると、ユーザは、Ｎ月１日からＮ月末日（締め日）までの間に、３回、Ａコインを購入している。そして、この場合、支払い期限日は、翌月（Ｎ＋１月）の末日であり、ユーザは、締め日以降から当該支払い期限日までの支払い期間中に、３回のＡコインの購入分に対応する代金を支払えばよいことになる。なお、この場合、３回のＡコインの購入分に対応する代金は、利息や手数料を含まない代金である。

このように、本実施形態では、サービス提供システム１が後払い機能を有するので、ユーザの利便性を高めることができる。例えば、クレジットカード等を所持しないユーザでも、後払い機能を利用して、サービス提供システム１からＡコインの提供を受けることができる。また、月ごとに請求が１つにまとめられているため、ユーザは（プリペイドカードのように）都度、支払う必要がなく、１ヶ月分をまとめて１回の支払いを行うだけで、複数回のＡコインの購入に応じた代金の支払いを済ませることができ、利便性が向上する。

（後払い機能の詳細）
次に、図５から図１３を参照して、後払い機能の詳細を説明する。

図５は、サーバ装置１０が実現する各種機能のうちの、後払い機能に関連する機能に関する機能ブロック図である。図６は、ユーザ情報データベース５０内のデータの説明図である。図６（後出の図７から図１１も同様）において、「＊＊＊」は、何らかの情報が格納されていることを意味する。図７は、ゲームに関する情報の説明図である。図８は、ログ情報データベース５２内のデータの説明図である。図９は、指標値データベース５４内のデータの説明図である。図１０は、請求情報データベース５５内のデータの説明図である。図１１は、後払い情報データベース５６内のデータの説明図である。図１２及び図１３は、催促情報の出力態様の各一例を示す図である。

サーバ装置１０は、各端末装置２０と協動して、以下で説明する各種機能を実現する。サーバ装置１０は、図５に示すように、ユーザ登録部３０と、サービス提供部３１と、ログ情報蓄積部３４と、ログ情報取得部３６と、判定部３８と、請求情報管理部３９と、催促情報出力部４０と、活動制限部４２と、上限値設定部４４と、ユーザ情報データベース５０と、ログ情報データベース５２と、指標値データベース５４と、請求情報データベース５５と、後払い情報データベース５６とを含む。ユーザ登録部３０から上限値設定部４４は、上述したサーバ通信部１１及びサーバ制御部１３により実現でき、ユーザ情報データベース５０から後払い情報データベース５６は、上述したサーバ記憶部１２により実現できる。

なお、ユーザ登録部３０から上限値設定部４４の各機能部の区別は、説明の都合上であり、特定の一の機能部の機能（以下で説明する機能）の一部又は全部が、他の一の機能部により実現されてもよい。例えば、ユーザ登録部３０の機能の一部又は全部が、コンテンツ提供部３１３により実現されてもよい。ユーザ情報データベース５０から後払い情報データベース５６についても同様であり、特定の一のデータベースの機能（以下で説明する機能）の一部又は全部が、他の一のデータベースにより実現されてもよい。

ユーザ登録部３０は、サイトＡを利用するユーザに係るユーザ情報をユーザ情報データベース５０に登録する。

ユーザ情報は、図６に示すように、ユーザＩＤ（ユーザ識別情報の一例）に対応付けられる態様で、ユーザ名、パスワード、電話番号、ＳＭＳ認証結果、所持コイン、ゲームに関する情報、ＳＮＳに関する情報、デジタルコンテンツに関する情報等を含む。ユーザ情報は、例えば、ユーザＩＤやユーザ名のような初期的に登録される情報とともに、ゲームに関する情報のような、事後的に蓄積される情報を含んでよい。また、ユーザ情報は、ユーザの現実世界の情報（年齢、収入、住所など）については、電話番号以外、含まなくてよい。

ユーザＩＤは、ユーザを一意に識別可能な情報である。以下、ユーザＩＤを単にユーザともいう。

ユーザ名は、ユーザの名前を示す情報である。ユーザ名は、ユーザＩＤとは異なり、ユーザを一意に識別可能でなくてもよい。ユーザ名は、端末装置２０に対するユーザ操作に応じて任意に決定及び変更が可能であってもよい。なお、ユーザ名は、初期的に登録される情報であり、登録すべき必須情報であってよい。

パスワードは、ユーザ名によるサイトＡへのログインを可能とするためのパスワードである。パスワードは、用途に応じて複数種類設定されてもよい。パスワードは、初期的に登録される情報であり、登録すべき必須情報であってよい。

電話番号は、ショートメッセージサービス（ＳＭＳ）認証用の電話番号である。電話番号は、初期的に登録される情報であり、登録すべき必須情報であってもよいし、任意的な情報であってよい。

ＳＭＳ認証結果は、登録される電話番号を用いたＳＭＳ認証の結果を表す。ＳＭＳ認証では、登録された電話番号宛てに特定の確認コードをＳＭＳにより送信し、その後、当該確認コードが入力されるか否かに応じて認証が実現される。図６において、“○”はＳＭＳ認証が成功であったことを表し、“×”はＳＭＳ認証が不成功であったことを表す。なお、ＳＭＳ認証は、電話番号が登録される場合にのみ実行される。

所持コインは、所持するＡコインの数（現在利用可能なＡコインの数）を表す。なお、ユーザは、上述のように後払い機能を利用して、Ａコインの提供を受けることができる。所持コインの初期値は、例えば０である。所持コインは、後述のように、コイン提供部３１３１や、課金処理部３１４、請求情報管理部３９等により更新されうる。

ゲームに関する情報は、図７に示すように、ユーザＩＤごとに、ランクと、所有ゲーム媒体に関する情報と、使用ゲーム媒体に関する情報と、フレンド情報とを含んでよい。

ランクは、ゲームに関するユーザの熟練度を示すパラメータである。本実施形態において、ランクの値は、ユーザによるゲームのプレイに応じて増加してもよい。ランクが高いほど、ゲームに関するユーザの熟練度が高い。

所有ゲーム媒体に関する情報は、ユーザがゲーム内で所有するゲーム媒体（所有ゲーム媒体）に固有の種々の情報を含む。ゲーム媒体がユーザに取得された場合、当該ゲーム媒体は、所有ゲーム媒体としてユーザに対応付けられる。所有ゲーム媒体に関する情報の詳細は省略するが、ゲーム媒体ＩＤごとに、ゲーム媒体名や、レアリティ、レベル、コスト、ＨＰ（ＨｉｔＰｏｉｎｔ）、攻撃力、回復力等を含んでよい。

使用ゲーム媒体に関する情報は、対戦ゲームパートにおいてユーザに使用させるゲーム媒体（第１ゲーム媒体）を示す情報である。第１ゲーム媒体は、所有ゲーム媒体のうちから選択される。本実施形態において、１つ以上の所有ゲーム媒体のうちから選択された、例えば最大５つのゲーム媒体が、それぞれ第１ゲーム媒体としてユーザに対応付けられる。従って、１つのゲーム媒体が、所有ゲーム媒体であると同時に第１ゲーム媒体でもあり得る。第１ゲーム媒体は、例えば専用のゲームパートにおいて、自動的に又はユーザ操作に応じて選択されてもよい。例えば、当該専用のゲームパートは、いわゆるデッキ編成又はチーム編成等を行うゲームパートを含んでもよい。使用ゲーム媒体に関する情報に示される最大５つの第１ゲーム媒体が、１つのデッキを構成する。使用ゲーム媒体に関する情報は、複数のデッキの情報を含んでもよい。

フレンド情報は、ゲームにおけるフレンド関係にあるユーザＩＤを表す。例えば、ユーザＡが、ユーザＢ、Ｃとフレンド関係である場合、ユーザＡに対応付けられたフレンド情報は、ユーザＢ、ＣのユーザＩＤを含む。なお、フレンド関係は、フレンド申請等を介して実現される。このように、フレンド情報は、ユーザとの間で一方向的又は双方向的に関連付けられた他のユーザのユーザＩＤを含む。なお、フレンド関係にあるユーザ同士は、例えばゲーム中、メッセージの送受信等のコミュニケーションが可能であってもよい。なお、ユーザに関する情報において、フレンド情報に代えて又は加えて、所属するグループ（例えばギルドやパーティ）を示す情報が含められてもよい。

なお、ゲームに関する情報の内容は、上述したものに限られない。例えば、ユーザに関する情報は、ユーザがゲーム内で保有する所定のポイントを示す情報を更に含んでもよい。当該ポイントは、ユーザがゲームパートをプレイするために消費される。ゲームパートごとに、当該ポイントの消費量が異なってもよい。当該ポイントは、例えば時間経過に応じて、又は所定のゲーム媒体の使用に応じて、増加してもよい。

ＳＮＳに関する情報は、ＳＮＳ機能に関連する各種情報を含んでよい。例えば、ＳＮＳに関する情報は、ユーザＩＤごとに、アバタに関する情報や、友達情報等を含んでよい。アバタに関する情報は、着せ替え用の衣類情報等を含んでよい。友達情報は、ＳＮＳ機能を介してつながるユーザＩＤやグループＩＤを表してよい。友達情報は、ゲームにおけるフレンド情報と同一であってもよいし、別であってもよい。

デジタルコンテンツに関する情報は、ユーザが利用可能なデジタルコンテンツを特定するための情報を含んでよい。ここでいう「ユーザが利用可能なデジタルコンテンツ」とは、Ａコイン以外のデジタルコンテンツであって、ユーザがＡコインを消費して提供を受けた１つ以上のデジタルコンテンツを含んでよい。なお、デジタルコンテンツに関する情報は、ユーザがプレイ可能な１つ以上のゲームアプリ（例えば、ユーザがＡコインを消費して提供を受けた１つ以上のゲームアプリ、及び／又は、それ以外のゲームアプリ）を表す情報を含んでよい。

サービス提供部３１は、サービスプラットホームを介して各ユーザが利用可能な各種のサービスを提供する。

サービス提供部３１は、ログイン管理部３１０と、ゲーム処理部３１１と、ＳＮＳ機能実現部３１２と、コンテンツ提供部３１３と、課金処理部３１４と、デジタルコンテンツ利用部３１５とを含む。

ログイン管理部３１０は、サイトＡの利用サービスに関する処理を実行する。具体的には、ログイン管理部３１０は、ユーザ情報データベース５０内のユーザ名及びパスワード等に基づいて、各ユーザによるサイトＡにおけるログイン状態を管理する。基本的には、ログイン管理部３１０は、ユーザにより入力されるユーザ名及びパスワードがユーザ情報データベース５０内のユーザ情報と整合する場合は、当該ユーザ名に係るユーザＩＤに基づくログインを許可する。ただし、本実施形態では、後述のように活動制限部４２による４段階目の制限を受けているユーザに対しては、ログイン管理部３１０は、サイトＡへのログインを禁止する。

ゲーム処理部３１１は、ゲームアプリに係るゲーム処理を実行する。この際、ゲーム処理部３１１は、ゲームに関する情報（図６及び図７参照）を利用して、ゲーム処理を実行する。ゲーム処理により実現されるゲームの態様は、上述したとおりであるが、任意である。ゲーム処理部３１１は、一のユーザに関して各種のゲーム処理を実行すると、当該一のユーザに対応付けられたユーザ情報（図６に示したユーザ情報におけるゲームに関する情報）を適宜更新する。本実施形態では、後述のように活動制限部４２による３段階目の制限を受けているユーザに対しては、ゲーム処理部３１１は、ゲームのプレイを禁止する。

ＳＮＳ機能実現部３１２は、上述したＳＮＳ機能に係る処理を実行する。この際、ＳＮＳ機能実現部３１２は、図６に示したようなＳＮＳに関する情報を利用して、ＳＮＳ機能に係る処理を実行する。ＳＮＳ機能実現部３１２は、一のユーザに関して各種のＳＮＳ機能に係る処理を実行すると、当該一のユーザに対応付けられたユーザ情報（図６に示したユーザ情報におけるＳＮＳに関する情報）を適宜更新する。

コンテンツ提供部３１３は、サイトＡを介して上述したデジタルコンテンツをユーザに提供する。コンテンツ提供部３１３は、コイン提供部３１３１と、デジタルコンテンツ提供部３１３２とを含む。

コイン提供部３１３１は、支払い期限日（所定期限の一例）まで後払い機能による支払い（提供分のＡコインの対価の支払い）を条件として、所定数ＮのＡコイン（デジタルコンテンツの一例）をユーザに提供する。なお、Ａコインは、１個あたりの対価が一定であってもよいし、可変であってもよい。Ａコインは、１個あたりの対価が、例えばβ円であるとすると、所定数ＮのＡコインの対価は、Ｎ×β円である。この場合、コイン提供部３１３１は、支払い期限日までのＮ×β円の支払いを条件として、所定数ＮのＡコインをユーザに提供する。

本実施形態では、一例として、各ユーザは、ユーザに対応付けられた上限値Ｎｍａｘに、月ごとの支払い前の対価の累積値が達するまで、何度でも（図３参照）、Ａコインの提供を受けることができる。すなわち、コイン提供部３１３１は、ユーザに対応付けられた上限値Ｎｍａｘに、月ごとの支払い前の対価の累積値が達するまで、同ユーザからの要求に応じて、同ユーザにＡコインを提供する。月ごとの支払い前の対価の累積値とは、月ごとの累積値であって、提供を受けたＡコインの対価の累積値である。この場合、一のユーザに対応付けられた支払い前の対価の累積値は、月ごとに、“０”にリセットされる。なお、一度に提供を受けることができるＡコインの数は、上限が規定されていてもよいし、実質的に無制限であってもよい。すなわち、所定数Ｎは、予め規定されて固定値であってもよいし、ユーザにより選択／調整可能であってもよい。なお、後者の場合、ユーザは、一度に、上限値Ｎｍａｘに対応する対価となる数のＡコインの提供を受けることもできる。

ただし、変形例では、各ユーザは、ユーザに対応付けられた上限値Ｎｍａｘに、全期間にわたる支払い前の対価の累積値が達するまで、何度でも（図３参照）、Ａコインの提供を受けることができる。全期間にわたる支払い前の対価の累積値とは、月ごとの累積値ではなく、全期間にわたる累積値であって、提供を受けたＡコインの対価の累積値である。この場合、当該一のユーザが、当該累積値に対応する代金（全額）の支払いを行うと“０”にリセットされる。
なお、本実施形態では、支払い期限日は、各ユーザで同じであるが、これに限られない。例えば、変形例では、与信情報（例えば、上限額）に応じて支払い期限日までの期間が変動する態様で、支払い期限日が設定されてもよい。この場合、高い信用が与えられるユーザほど緩い（長い）支払い期限日が設定されてもよい。

なお、本実施形態では、一例として、Ａコインの１個あたりの対価βが変動する場合を想定し、上限値Ｎｍａｘは、対価に対する上限値として機能するが、これに限られない。例えば、Ａコインの１個あたりの対価βが固定である場合、等価的に、上限値Ｎｍａｘは、対価の支払い前のＡコインの数の累積値に対する上限値であってもよい。

上限値Ｎｍａｘは、ユーザごとに一定の固定値であってもよいが、本実施形態では、一例として、後述のようにユーザごとに上限値設定部４４により設定される。なお、本実施形態では、コイン提供部３１３１は、一のユーザに関して、後払い情報データベース５６を参照して得られる上限値Ｎｍａｘ（当該一のユーザに対応付けられた上限値Ｎｍａｘ）（図１１参照）と、請求情報データベース５５を参照して得られる請求額（当該一のユーザに対応付けられた請求額であり、支払い前の対価の累積値に相当）（図１０参照）との関係に基づいて、現時点で当該一のユーザに提供可能なＡコインの最大数を把握できる。

コイン提供部３１３１は、一のユーザに所定数ＮのＡコインを提供すると、当該一のユーザに対応付けられた所持コイン（図６に示したユーザ情報における所持コイン）を更新する。この場合、コイン提供部３１３１は、当該一のユーザに対応付けられた所持コインの数値を所定数Ｎだけ加算する。

デジタルコンテンツ提供部３１３２は、ユーザに対応付けられたＡコインの消費（Ａコイン数の減少）を条件として、Ａコイン以外の各種のデジタルコンテンツをユーザに提供する。なお、Ａコインの消費量は、デジタルコンテンツごとに対応付けられてよい。すなわち、デジタルコンテンツの提供の価値（対価）が高いほど、Ａコインの消費量が多くなる態様で、デジタルコンテンツに応じてＡコインの消費量が設定されてよい。

デジタルコンテンツ提供部３１３２は、Ａコイン以外のデジタルコンテンツを、一のユーザに提供すると、当該一のユーザに対応付けられた所持コイン（図６に示したユーザ情報における所持コイン）を更新する。この場合、デジタルコンテンツ提供部３１３２は、当該一のユーザに対応付けられた所持コインの数値を、提供したデジタルコンテンツの対価に相当するＡコインの数だけ、減算する。

課金処理部３１４は、課金サービスに関する処理を実行する。具体的には、課金処理部３１４は、ユーザからＡコインの提供（購買）の要求を受けると、所定条件の下で、ユーザにＡコインを提供する。なお、課金処理部３１４は、コイン提供部３１３１とは異なり、後払いによらず、その時点での決済を条件として、ユーザにＡコインを提供する。なお、本実施形態では、後述のように活動制限部４２による２段階目の制限を受けているユーザに対しては、ログイン管理部３１０は、課金サービスの提供（すなわちＡコインの獲得）を禁止する。

デジタルコンテンツ利用部３１５は、デジタルコンテンツの利用サービスに関する処理を実行する。具体的には、デジタルコンテンツ利用部３１５は、サービスプラットホームを介して利用可能なデジタルコンテンツのうちの、Ａコインに関する処理以外のデジタルコンテンツに関する処理を実行する。例えば、デジタルコンテンツ利用部３１５は、ある一のユーザから電子書籍の閲覧要求を受けると、当該一のユーザに係るユーザ情報（図６参照）のうちの“デジタルコンテンツに関する情報”を参照し、当該一のユーザに紐付けられた１つ以上の電子書籍のうちの、要求された電子書籍の閲覧を可能とする。

ログ情報蓄積部３４は、サイトＡを利用する各ユーザのログ情報を収集し、ユーザＩＤごとにログ情報をログ情報データベース５２内に蓄積する。蓄積対象のログ情報は、すべてのログ情報であってもよいし、特定のログ情報（例えば操作ログに関するログ情報）であってもよい。ログ情報は、各ユーザＩＤに基づくサイトＡにおける各種活動（ログインや、ログアウト、デジタルコンテンツの利用、ＳＮＳ機能へのアクセス／利用、課金等）を表す。図８には、ログ情報蓄積部３４に蓄積されるログ情報の一例が示される。図８では、ユーザＩＤごとに、操作日時を表す情報と操作内容を表す情報とがセットとなって蓄積されている。なお、このようなログ情報に係る一のセットは、操作ごとに生成される。ログ情報データベース５２内に蓄積されるログ情報は、生データであってもよいし、加工されたデータであってもよい。

ログ情報取得部３６は、判定部３８による判定対象のユーザに係るログ情報をログ情報データベース５２から取得（抽出）する。なお、ログ情報データベース５２には、上述したように、ユーザＩＤに紐付けられる態様でログ情報が蓄積されている。なお、ログ情報取得部３６は、ユーザＩＤに紐付けられるログ情報のすべてを抽出してもよいし、一部（例えば特定の期間のログ情報のみ）を抽出してもよい。

判定部３８は、ログ情報取得部３６が取得するログ情報に基づいて、ユーザごとに、後払い機能が利用可能であるか否かを判定する。すなわち、判定部３８は、一のユーザに対応付けられたログ情報に基づいて、当該ユーザへのコイン提供部３１３１によるＡコインの提供の可否を判定する。判定部３８による判定方法は、ログ情報を利用する限り任意であるが、典型的には、後払い機能を正常に利用してもらえる可能性が高いユーザに対しては、後払い機能が利用可能となるように適合される。より具体的には、後払い機能を利用したユーザが、支払い期限日までに代金を支払うような態様を、“正常な利用”とし、後払い機能を利用したユーザが、支払い期限日までに代金を支払わずに支払いが遅延又は滞るような態様を、“非正常な利用”とし、また、“非正常な利用”のうちの、支払い期限日以降も代金を支払わずに後述のアカウントの停止という制限が発動されるような態様を“回収不能な利用”とした場合、“非正常な利用”及び／又は“回収不能な利用”が生じる可能性が最小化するように、判定部３８による判定方法が適合される。

判定部３８による判定方法は、ログ情報を入力して、Ａコインの提供の可否を２値で出力するロジックに基づくものであってもよい。なお、本明細書において、「ログ情報を入力する」とは、ログ情報から導出されるパラメータ（例えば後述の指標値α）を入力することを含む概念である。

あるいは、判定部３８による判定方法は、人工知能を利用して実現されてもよい。この場合、ログ情報を入力して、Ａコインの提供の可否を出力（生成）することも可能である。人工知能の場合は、機械学習により得られる畳み込みニューラルネットワークを実装することで実現できる。機械学習では、例えば、多数のユーザのログ情報に係る実績データを用いて、誤差が最小になるような畳み込みニューラルネットワークの重み等が学習されてよい。なお、ここでいう誤差とは、“非正常な利用”及び／又は“回収不能な利用”を行ったユーザに係るログ情報に基づいて、Ａコインの提供が“可”を表す値を出力することと、“正常な利用”を行ったユーザに係るログ情報に基づいて、Ａコインの提供が“不可”を表す値を出力することとを含む。

なお、判定部３８は、Ａコインの提供の可否を２値で判定する際に、“正常な利用”が期待できる可能性を表す指標値を算出してもよい。この際、一のユーザに係る指標値は、サイトＡにおける当該一のユーザの活動の活発度合いや、活動期間、サイトＡにおいて当該一のユーザが培った資産（ＳＮＳ機能でつながる友達や、ゲーム媒体、ゲーム能力等）の価値等に相関する値であってよい。この場合、判定部３８は、ユーザごとに当該指標値を算出し、当該指標値が所定閾値を超えるユーザに対しては、Ａコインの提供が“可”であると判定してもよい。

本実施形態では、一例として、判定部３８は、ユーザごと、かつ、サイトＡにおける活動ごとに、複数の指標値αを算出する。複数の指標値αは、例えば、ログイン状況に係る第１指標値と、課金状況に係る第２指標値と、ＳＮＳの利用状況に係る第３指標値と、ゲームのプレイ状況に係る第４指標値とを含む。各指標値αは、各種状況を表している限り任意の態様で算出されてもよい。判定部３８は、複数の指標値αを算出すると、図９に示すように、指標値データベース５４内に複数の指標値αを保存（更新）する。なお、複数の指標値αの算出（更新）タイミングは、任意であり、複数の指標値αは、定期的に及び／又は不定期的に算出されてもよい。また、複数の指標値αの算出（更新）タイミングは、同時であってもよいし、指標値ごとに異なってもよい。

この場合、判定部３８は、複数の指標値αを入力として、ユーザごとに、後払い機能が利用可能であるか否かを判定する。判定部３８は、判定結果に応じて、後払い情報データベース５６内のデータの一部（図１１の“後払い可否”）を更新する。図１１では、判定部３８による判定結果が“後払い機能の利用が可能である”（“後払い可”）であるユーザは“○”で表され、判定部３８による判定結果が“後払い機能の利用が可能でない”（“後払い不可”）であるユーザは“×”で表されている。

なお、判定部３８は、ログ情報に加えて、他の所定情報を補足的に利用して、ユーザごとに、後払い機能が利用可能であるか否かを判定してもよい。他の所定情報は、ユーザの現実世界の情報（年齢、収入、住所など）を含んでもよいが、好ましくは、ユーザの現実世界の情報を含まない。他の所定情報は、例えばＳＭＳ認証結果（図６参照）であってよい。この場合、判定部３８による判定方法は、ＳＭＳ認証が成功であったユーザに対しては、ＳＭＳ認証が不成功であったユーザよりも、後払い機能が利用可能であると判定されやすくなるように、構成されてよい。あるいは、判定部３８は、ＳＭＳ認証が成功であったユーザのうちから、後払い機能が利用可能なユーザを抽出してもよい。

請求情報管理部３９は、後払い機能を利用したユーザに係る請求情報を管理する。請求情報管理部３９は、後払い機能に係る請求情報を生成して請求情報データベース５５内に格納するとともに、請求情報データベース５５内の請求情報を更新する。図１０に示す例では、請求情報データベース５５には、請求書ＩＤごとに、ユーザＩＤ、支払い用の番号、請求額、締め日／支払い期限日、出力要否フラグ、及び支払状況カテゴリの各情報が保持されている。請求書ＩＤは、１ヶ月ごとに、ユーザＩＤごとに１つだけ発行（生成）される。ただし、後払い機能を利用していないユーザに対しては、請求書ＩＤは発行されなくてよい。

支払い用の番号とは、コンビニや郵便局等で同番号を入力することで、支払いが可能となる番号である。出力要否フラグは、対応するユーザに、請求書情報（確定した請求書情報）を出力すべき状態であるか否かを表し、“０”は請求書情報を出力すべき状態でないことを表し、“１”は請求書情報を出力すべき状態であることを表す。

支払状況カテゴリとは、支払い状況を表す支払状況カテゴリであり、本実施形態では、支払い済の場合は“Ａ”で表され、支払いが済んでいない場合は“Ｂ０”から“Ｂ４”で表されている。支払状況カテゴリ“Ｂ０”から“Ｂ４”は、支払い期限日に対する遅延度合い（後述の未払い時間ΔＴ１の長さ）に応じて変化し、後述する。なお、支払状況カテゴリの初期値（すなわち請求書ＩＤの発行時の値）は“分類なし”であってよい。この場合、請求情報管理部３９は、例えば、ある一の支払い用の番号に対応付けられた支払い通知を取得すると（例えば、コンビニ等から取得すると）、当該一の支払い用の番号に対応付けられた請求書ＩＤに係る支払状況カテゴリを“Ａ”に書き換えることで、請求情報を更新する。

請求情報管理部３９は、ユーザが後払い機能を利用してコイン提供部３１３１によりコインの提供を受けるごとに、提供分の対価だけ請求額を積算していく（すなわち支払い前の対価の累積値を更新する）。そして、請求情報管理部３９は、締め日が到来すると、現在の請求額の支払い（一括での支払い）を求める請求書情報（今月分の支払いに係る請求書情報）を生成する。このようにして、本実施形態では、締め日が到来すると、請求書ＩＤごとに請求書情報が確定される。

請求情報管理部３９は、後払い機能を利用したユーザに向けて、締め日（図４参照）以降に、今月分の支払いに係る請求書情報（確定した今月分の請求書情報）を出力する。請求書情報の出力方法は、任意であり、ユーザがログインしているサイトＡ上に請求書情報が出力されてもよいし、ユーザのメールアドレス（登録している場合）に請求書情報のメールが送信されてもよい。この場合、請求書情報の出力は、好ましくは、支払い用の画面（図示せず）への遷移ボタンやリンクを含んでよい。この場合、ユーザは、請求書情報の出力に応答して、支払いの準備を容易に行うことができる。支払い用の画面は、支払い用の番号や支払い方法の説明を記載する画面であってよい。請求情報管理部３９は、一の請求書ＩＤに係る請求書情報（確定した今月分の請求書情報）を、当該請求書ＩＤに対応付けられたユーザに向けて出力すると、当該一の請求書ＩＤに対応付けられた出力要否フラグ（図１０参照）を“０”にセットする。なお、出力要否フラグは、初期値（すなわち請求書ＩＤの発行時の値）が“０”であり、締め日以降に“１”にセットされる。

催促情報出力部４０は、提供したＡコインに係る対価が支払い期限日（所定期限の一例）までに支払われていない場合に、Ａコインに係る対価を支払うように、対応するユーザに促す催促情報を出力する。すなわち、ある一のユーザに提供したＡコインに係る対価が、支払い期限日までに支払われていない場合に、催促情報出力部４０は、当該一のユーザに向けて催促情報を出力する。以下では、提供されたＡコインに係る対価を支払い期限日を過ぎても支払っていないユーザを、「未払いユーザ」とも称する。

催促情報の出力方法は、任意であり、未払いユーザに、提供したＡコインに係る対価の支払いが行われていないことが伝わる態様であればよい。例えば、催促情報の出力方法は、未払いユーザの端末装置２０を介して実現されてもよい。この場合、催促情報出力部４０は、未払いユーザがログインしているサイトＡを介して催促情報を出力してもよい。サイトＡを介した催促情報の出力は、例えば、サイトＡのホーム画面等にメッセージを出力すること（図１２参照）や、チャットとして催促情報のメッセージを出力すること、ＳＮＳ機能に係るアラート通知を利用して催促情報を出力すること、ゲーム画面上に催促情報のメッセージを出力すること（図１３参照）等により実現されてもよい。図１２では、催促情報としてメッセージＭ１“後払いの支払い期限が過ぎています”が出力されたホーム画面Ｇ５１が示される。また、図１３では、催促情報としてメッセージＭ２“後払いの支払い期限が過ぎています”が出力されたゲーム画面Ｇ５２が示される。

また、催促情報出力部４０は、未払いユーザに対応する電話番号にショートメッセージを送信することにより、催促情報の出力を実現してもよい。また、催促情報出力部４０は、未払いユーザに対応する電話番号を発呼して催促情報の自動音声を流すことにより、催促情報の出力を実現してもよい。また、催促情報出力部４０は、ユーザのメールアドレス（登録している場合）にメールを送信することにより、催促情報の出力を実現してもよい。また、催促情報出力部４０は、未払いユーザに対応する電話番号にコールセンター等からオペレータ（人）が電話をかけることで、催促情報の出力を実現してもよい。このようにして、未払いユーザに対応する電話番号（図６のユーザ情報の一要素）を利用して、未払いユーザに催促情報の出力する出力手段（催促情報の伝達手段）は多様であり、これらの複数を組み合わせることも可能である。

催促情報の出力は、好ましくは、請求書情報の出力と同様、支払い用の画面（図示せず）への遷移ボタンやリンクを含んでよい。この場合、未払いユーザは、催促情報の出力に応答して、支払いの準備を容易に行うことができる。支払い用の画面は、支払い用の番号や支払い方法の説明を記載する画面であってよい。例えば、図１２に示すメッセージＭ１や図１３に示すメッセージＭ２のような催促情報のメッセージは、支払い用の画面（図示せず）への遷移ボタンとして機能してもよい。

催促情報出力部４０は、好ましくは、支払い期限日（所定の第１タイミングの一例）からの経過時間（以下、「未払い時間ΔＴ１」とも称する）に応じて、催促情報の出力態様を変化させる。なお、本実施形態では、一例として、未払い時間ΔＴ１は、支払い期限日の午前０時からカウントされるものとする。未払い時間ΔＴ１は、時間単位で算出されてもよいし、日や週、月等のような比較的長い単位で算出されてもよい。

ここで、「催促情報の出力態様を変化させる」とは、催促情報の出力方法を変化させることや、催促情報の出力方法は同じであるが注意喚起度を変化させることを含む概念である。

例えば、催促情報出力部４０は、未払い時間ΔＴ１が長くなるほど、注意喚起度が高くなるようにメッセージＭ１、Ｍ２（図１２及び図１３参照）の内容を変化させてもよい。メッセージＭ１、Ｍ２（図１２及び図１３参照）の内容は、支払いがなお実行されない場合の措置（ペナルティ）の内容（すなわち、後述する活動制限部４２による制限内容）を含んでもよい。

また、催促情報出力部４０は、未払い時間ΔＴ１が長くなるほど、注意喚起度が高くなるようにメッセージＭ１、Ｍ２（図１２及び図１３参照）の出力位置を変化させてもよい。例えば、メッセージＭ２（図１３参照）は、未払い時間ΔＴ１が長くなるほど、ゲームのプレイが阻害されるような位置に出力されてもよい。また、メッセージＭ２（図１３参照）は、未払い時間ΔＴ１が長くなるほど、ゲームのプレイが阻害されるような大きなサイズに拡張されてもよい。また、メッセージＭ１、Ｍ２（図１２及び図１３参照）は、点滅や、ポップアップ、画面上の移動のような動きを伴うことで、注意喚起度が高められてもよい。

また、催促情報出力部４０は、未払い時間ΔＴ１が長くなるほど、注意喚起度が高くなるようにメッセージＭ１、Ｍ２（図１２及び図１３参照）の色や輝度等を変化させてもよい。

また、催促情報は、端末装置２０が備える機能を利用して注意喚起度が高められてもよい。例えば、端末装置２０が振動機能を備える場合は、催促情報の出力時に端末装置２０に振動が生成されてもよい。

本実施形態では、一例として、催促情報出力部４０は、未払い時間ΔＴ１が０（第１所定時間の一例）を超えると、未払いユーザがログインしているサイトＡを介して催促情報を出力し（図１２及び図１３参照）、未払い時間ΔＴ１が所定時間Ｔｈ１（第２所定時間の一例）を超えると、未払いユーザに対応する電話番号にショートメッセージを送信する。ショートメッセージには、メッセージＭ１（図１２参照）の内容と同様の内容が記載されてよい。所定時間Ｔｈ１は、０よりも有意に長い任意の時間であるが、例えば週や月のオーダーであってもよい。また、所定時間Ｔｈ１は、各ユーザで同じであるが、これに限られない。例えば、変形例では、所定時間Ｔｈ１は、各ユーザに係る与信情報（未払い金と、金額上限の情報を基に算出した情報など）や後述の後払い情報等に応じて変化させてもよい。例えば、後払い情報を利用する場合、後払い機能の利用実績（回数）が十分あり、遅延履歴がないユーザ（従って平均遅延日数が０であるユーザ）には、比較的長い所定時間Ｔｈ１が設定され、利用実績（回数）が不十分あり、遅延履歴があるユーザ（従って平均遅延日数が０よりも大きいユーザ）には、比較的短い所定時間Ｔｈ１が設定されてよい。

なお、サイトＡを介した催促情報の出力の場合、未払い時間ΔＴ１が０を超えた時点で未払いユーザがサイトＡにログインしている場合は、催促情報出力部４０は、その時点から催促情報を出力できる。他方、未払い時間ΔＴ１が０を超えた時点で未払いユーザがサイトＡにログインしていない場合は、催促情報出力部４０は、その後、未払いユーザがサイトＡにログインする際に、催促情報を出力してよい。

催促情報出力部４０は、未払い時間ΔＴ１が０を超えると、対価の支払いが行われるまで、サイトＡに催促情報を出力し続けてよい。この場合、未払い時間ΔＴ１が更に所定時間Ｔｈ１を超えると、催促情報出力部４０は、未払いユーザがログインしているサイトＡを介して催促情報を出力するとともに、未払いユーザに対応する電話番号にショートメッセージを送信することになる。この場合、サイトＡを介して出力する催促情報に係るメッセージは、上述のように、未払い時間ΔＴ１が長くなるほど、注意喚起度が高くなるように変化してよい。

催促情報出力部４０は、未払いユーザにより、提供したＡコインに係る対価が支払われた場合（すなわち未払いが解消された場合）、当該支払いが確認されると即座に、催促情報の出力を停止してよい。

活動制限部４２は、提供したＡコインに係る対価が支払い期限日（所定期限の一例）までに支払われていない場合に、未払いユーザに係るユーザＩＤに基づくサイトＡにおける活動（以下、単に「サイトＡにおける未払いユーザによる活動」とも称する）を制限する。以下、活動制限部４２により実行される制限処理を、単に「活動制限処理」とも称する。なお、ユーザＩＤに基づくサイトＡにおける活動とは、任意であるが、例えば、上述のように、ログインや、ログアウト、デジタルコンテンツの利用、ＳＮＳ機能へのアクセス／利用、課金等である。サイトＡにおける各種活動のうちの、活動制限部４２による制限対象の活動は、一部（すなわちサービスプラットホームを介して利用可能な各種サービスのうちの一部）であってもよいし、全部（すなわちサービスプラットホーム自体）であってもよい。また、サイトＡにおける各種活動のうちの、活動制限部４２による制限対象の活動は、ログ情報データベース５２に蓄積されるログ情報に係る活動と同じであってもよいし、部分的に異なってもよいし、すべてが異なってもよい。

ここで、活動制限部４２により制限されうるデジタルコンテンツの利用とは、Ａコインの支払いによって提供を受けたデジタルコンテンツの利用のみならず、無償で利用可能な他のデジタルコンテンツの利用を含んでもよい。デジタルコンテンツの利用の態様は、デジタルコンテンツの属性に応じて異なるが、例えばデジタルコンテンツが動画や電子書籍の場合は、デジタルコンテンツの利用とは、デジタルコンテンツの閲覧を意味する。また、デジタルコンテンツがゲームアプリの場合は、デジタルコンテンツの利用とは、ゲームのプレイを意味する。

活動制限部４２は、好ましくは、支払い期限日（所定の第２タイミングの一例）からの経過時間（未払い時間ΔＴ１）に応じて、サイトＡにおける未払いユーザによる活動に対する制限態様を変化させる。なお、本実施形態では、一例として、活動制限部４２は、上述した催促情報出力部４０と同様、支払い期限日からの経過時間（未払い時間ΔＴ１）に基づいて、サイトＡにおける未払いユーザによる活動に対する制限態様を変化させるが、これに限られない。例えば、活動制限部４２は、上述した催促情報出力部４０とは異なり、締め日（所定の第２タイミングの他の一例）からの経過時間に応じて、サイトＡにおける未払いユーザによる活動に対する制限態様を変化させてもよい。催促情報出力部４０についても同様であり、他の基準日からの経過時間を利用してもよい。いずれの場合も、考え方は同じであり、実質的に等価の構成を実現できる。

サイトＡにおける未払いユーザによる活動に対する制限方法は、任意であるが、例えば、ログイン時間を制限することや、Ａコインの新たな獲得を制限すること、ＳＮＳ機能へのアクセス／利用頻度を制限すること、ゲームのプレイ頻度を制限すること、課金の上限値を制限すること、後払い機能の利用を禁止すること、現在所持しているＡコインの利用を制限すること等であってよい。

また、サイトＡにおける未払いユーザによる活動に対する制限方法は、未払いユーザの属性に応じて異なってもよい。例えば、ある一の未払いユーザによるゲームのプレイ頻度がＳＮＳ機能の利用頻度よりも有意に高い場合は、当該一の未払いユーザによる活動に対する制限方法は、ゲームのプレイに係る制限度合いがＳＮＳ機能の利用に係る制限度合いよりも高くなる態様であってもよい。
また、制限方法は、各ユーザに係る与信情報（未払い金と、金額上限の情報を基に算出した情報など）や後述の後払い情報等に応じて変化させてもよい。この場合、後払い機能の正常な運用が担保されるようにするための処理の多寡を柔軟に制御でき、サーバ装置１０の制御負荷を減らすことができる。例えば、後払い情報を利用する場合、後払い機能の利用実績（回数）が十分あり、遅延履歴がないユーザ（従って平均遅延日数が０であるユーザ）には、制限が発動されるタイミングが比較的遅くなるように設定され、利用実績（回数）が不十分あり、遅延履歴があるユーザ（従って平均遅延日数が０よりも大きいユーザ）には、制限が発動されるタイミングが比較的早くなるように設定されてよい。

ここで、サイトＡにおける未払いユーザによる活動に対する制限態様を変化させることは、サイトＡにおける未払いユーザによる活動に対する制限方法を変化させることや、サイトＡにおける未払いユーザによる活動に対する制限方法は同じであるが制限度合いを変化させることを含む概念である。

具体的には、活動制限部４２は、未払い時間ΔＴ１が長くなるほど、制限度合いが高くなるように、サイトＡにおける未払いユーザによる活動に対する制限態様を変化させてもよい。例えば、サイトＡにおける未払いユーザによる活動に対する制限方法が、課金の上限値を制限することである場合、活動制限部４２は、未払い時間ΔＴ１が長くなるほど、課金の上限値を低下させてよい。この場合、活動制限部４２は、最終的には、課金の上限値を０まで低下させて、課金を禁止してもよい。

本実施形態では、一例として、活動制限部４２は、未払い時間ΔＴ１に応じて、サイトＡにおける未払いユーザによる活動に対する制限態様を４段階で変化させる。なお、変形例では、２段階や３段階、５段階以上であってもよい。

具体的には、１段階目として、活動制限部４２は、未払い時間ΔＴ１が、支払い期限日の翌月の末日（すなわち次の支払い期限日）までの時間（第３所定時間の一例）を超えると、後払い機能を停止する。従って、この場合、最大で２ヶ月分の債権（未払いによる債権）しか蓄積されない。

２段階目として、活動制限部４２は、未払い時間ΔＴ１が、支払い期限日の翌月の末日（すなわち次の支払い期限日）＋１０日までの時間（第３所定時間の他の一例）を超えると、Ａコインの獲得手段（後払い機能以外の獲得手段）の利用を停止する。なお、Ａコインの獲得手段は、プリペイドカードサービスを利用して獲得する方法や、アンケートの回答等に対する報酬として獲得する方法等を含んでよい。これにより、２段階目の制限を受ける未払いユーザは、課金によるゲームのプレイが実質的に不能となる。ただし、２段階目の制限を受ける未払いユーザは、無課金によるゲームのプレイは、依然として可能である。なお、変形例では、活動制限部４２は、支払い期限日の翌月の末日（すなわち次の支払い期限日）＋１０日までの時間（第３所定時間の他の一例）を超えると、サービスプラットホームを介して利用可能な各種のサービスの一部の利用を制限してもよい。

３段階目として、活動制限部４２は、未払い時間ΔＴ１が、支払い期限日の翌々月の末日（すなわち次の次の支払い期限日）までの時間（第３所定時間の更なる他の一例）を超えると、ゲームのプレイを禁止する。すなわち、３段階目の制限を受ける未払いユーザは、課金によるゲームのプレイに加えて、無課金によるゲームのプレイも不能となる。なお、変形例では、活動制限部４２は、未払い時間ΔＴ１が、支払い期限日の翌々月の末日（すなわち次の次の支払い期限日）までの時間（第４所定時間の更なる他の一例）を超えると、サービスプラットホームを介して利用可能な各種のサービスのすべての利用を制限してもよい。この場合、未払いユーザは、サービスプラットホーム自体は利用できるものの、サービスプラットホームを介して如何なるサービスも利用できなくなる。ただし、この場合、未払いユーザによる催促情報の閲覧（すなわち催促情報出力部４０による当該未払いユーザに対する催促情報の出力）は可能な状態が維持されてよい。

４段階目として、活動制限部４２は、未払い時間ΔＴ１が、支払い期限日から四月後の末日（すなわち次の次の次の次の支払い期限日）までの時間（第５所定時間の一例）を超えると、アカウントを停止する。すなわち、活動制限部４２は、サイトＡにおける未払いユーザによる活動のすべてを禁止する。これにより、４段階目の制限を受ける未払いユーザは、今まで使用していたユーザＩＤに基づくログイン（サイトＡ上のログイン）も不能となり、当該ユーザＩＤに紐付けられたゲーム媒体等が実質的に凍結（消去）されることになる。すなわち、４段階目の制限を受ける未払いユーザは、サーバ装置１０が実現するサービスプラットホーム自体の利用（対応するユーザＩＤに基づく利用）が不能となる。

活動制限部４２は、未払いユーザにより、提供したＡコインに係る対価が支払われた場合（すなわち未払いが解消された場合）、即座に又は一定時間後に、制限を部分的に又は全面的に解除してよい。本実施形態では、一例として、活動制限部４２は、３段階目までの制限を受けている未払いユーザにより、提供したＡコインに係る対価が支払われた場合、無条件に、制限を全面的に解除する。

他方、活動制限部４２は、４段階目の制限まで至った未払いユーザについては、提供したＡコインに係る対価が支払われた場合でも、無条件に制限を全面的に解除することは、しない。この場合、サービス提供システム１の管理者等が、個別に、４段階目の制限まで至った未払いユーザに対する制限を解除するか否か（すなわち停止中のアカウントを復活させるか否か）を判断する。管理者等が４段階目の制限まで至った未払いユーザに対する制限を解除すると判断した場合は、活動制限部４２は、管理者等からその旨の入力を受けることで、制限を部分的に又は全面的に解除してよい。

上限値設定部４４は、ユーザごとに、ユーザに対応付けられたログ情報に基づいて、上述した上限値Ｎｍａｘ（コイン提供部３１３１による提供が可能なＡコインの数の上限値）を設定する。すなわち、上限値設定部４４は、一のユーザに対応付けられたログ情報に基づいて、当該ユーザに係る上限値Ｎｍａｘを設定する。上限値設定部４４は、ユーザごとの上限値Ｎｍａｘを算出すると、後払い情報データベース５６内に格納されるユーザごとの上限値（図１１参照）を更新（設定）する。なお、上限値Ｎｍａｘは、ユーザごとに、定期的又は不定期的に更新（見直し）されてもよい。

上限値設定部４４による上限値Ｎｍａｘの設定方法は、ログ情報を利用する限り任意であるが、典型的には、後払い機能を正常に利用してもらえる可能性が高いユーザに対しては、上限値Ｎｍａｘが高くなるように適合される。より具体的には、“非正常な利用”及び／又は“回収不能な利用”が生じる可能性が最小化するように、上限値設定部４４による上限値Ｎｍａｘの設定方法が適合される。なお、上限値Ｎｍａｘの設定で利用されるログ情報は、上述した判定部３８による判定で利用されるログ情報と同じであってもよいし、異なってもよい。また、上限値Ｎｍａｘが“高”又は“低”のような２値で設定される場合は、上限値Ｎｍａｘの設定で利用されるロジックは、上述した判定部３８による判定で利用されるロジックと同じであってもよいし、異なってもよい。

上限値設定部４４による上限値Ｎｍａｘの設定方法は、ログ情報を入力して、上限値Ｎｍａｘの候補値で出力するロジックに基づくものであってもよい。あるいは、上限値設定部４４による上限値Ｎｍａｘの設定方法は、人工知能を利用して実現されてもよい。この場合、ログ情報を入力して、上限値Ｎｍａｘの候補値（例えば３段階のカテゴリのうちの、一のカテゴリ）を出力（生成）することも可能である。人工知能の場合は、機械学習により得られる畳み込みニューラルネットワークを実装することで実現できる。機械学習では、例えば、多数のユーザのログ情報に係る実績データを用いて、“非正常な利用”及び／又は“回収不能な利用”が生じるような上限値Ｎｍａｘの候補値の算出頻度が最小になるような畳み込みニューラルネットワークの重み等が学習されてよい。

本実施形態では、一例として、上限値設定部４４は、ユーザごとに導出された上述の複数の指標値αに基づいて、ユーザごとに、上限値Ｎｍａｘの候補値を算出し、算出した上限値Ｎｍａｘの候補値に基づいて、上限値Ｎｍａｘを設定する。なお、この場合、上限値Ｎｍａｘの候補値＝上限値Ｎｍａｘとされてもよいし、上限値Ｎｍａｘの候補値が端数を含む場合は、端数が切り捨て等されることで上限値Ｎｍａｘが設定されてもよい。

具体的には、上限値設定部４４は、図９に示した指標値データベース５４内に複数の指標値αに基づいて、それぞれの指標値αに適切な重み付けを行うことで、上限値Ｎｍａｘの候補値を算出する。この場合も、同様に重み付けは、“非正常な利用”及び／又は“回収不能な利用”が生じるような上限値Ｎｍａｘの候補値の算出頻度が最小になるように学習等により適合されてよい。

ここで、上限値設定部４４は、ログ情報に加えて又は代えて、ユーザごとの後払い状況に関する情報（以下、「後払い情報」とも称する）を利用して、ユーザごとに上限値Ｎｍａｘを設定してもよい。後払い情報を利用することで、ユーザごとに適切な上限値Ｎｍａｘを設定できる可能性を高めることができる。なお、適切な上限値Ｎｍａｘとは、“非正常な利用”及び／又は“回収不能な利用”が生じないような範囲内での最大値又はそれに近い値に対応する。

この場合、上限値設定部４４は、後払い情報データベース５６内のデータ（図１１参照）を利用して、ユーザごとに上限値Ｎｍａｘを設定してもよい。図１１に示す例では、後払い情報データベース５６には、ユーザＩＤごとに、後払い可否（上述した判定部３８による判定結果）、上限値（上限値Ｎｍａｘ）、利用実績（回数）、遅延履歴、及び平均遅延日数が記憶されている。利用実績（回数）は、後払い機能の利用実績を表し、遅延履歴は、後払い機能を利用した際の支払いの遅延（支払い期限日までに支払いがなされなかった場合は、遅延）の有無や頻度を表し、平均遅延日数は、当該遅延の平均日数を表す。この場合、後払い情報は、利用実績（回数）、遅延履歴、及び平均遅延日数である。なお、後払い情報データベース５６内には、他の後払い情報として、活動制限部４２による制限の発動の有無や、４段階のうちの何段階までの制限の実績があるか等の情報が格納されてもよい。

このような後払い情報を利用する場合、例えば、利用実績（回数）が十分あり、遅延履歴がないユーザ（従って平均遅延日数が０であるユーザ）には、比較的高い上限値Ｎｍａｘの候補値が算出され、利用実績（回数）が不十分あり、遅延履歴があるユーザ（従って平均遅延日数が０よりも大きいユーザ）には、比較的低い上限値Ｎｍａｘの候補値が算出されてよい。このようにして、後払い情報を利用することで、ユーザごとに適切な上限値Ｎｍａｘを設定できる可能性を更に高めることができる。

ユーザ情報データベース５０には、上述のように、ユーザ情報（図６参照）が格納される。ユーザ情報データベース５０内のユーザ情報は、上述のように、適宜更新される。

ログ情報データベース５２には、上述のように、ユーザごとにログ情報（図８参照）が格納される。ログ情報データベース５２内のログ情報は、上述のように、随時更新される。なお、ログ情報データベース５２内のログ情報は、格納されてから比較的長い所定期間経過した後は、破棄されてもよいし、別のデータベースに移管されてもよい。

指標値データベース５４には、上述のように、各指標値α（算出結果）（図９参照）が格納される。各指標値αは、判定部３８による判定処理時に適宜更新される。

請求情報データベース５５には、上述のように、請求情報（図１０参照）が格納される。請求情報データベース５５内の請求情報は、請求書ＩＤごとに抽出可能な態様で格納される。請求情報データベース５５内の請求情報のうちの、支払状況カテゴリ“Ａ”が対応付けられた請求書ＩＤに係る情報は、支払状況カテゴリが“Ａ”となってから所定期間経過した後は、破棄されてもよいし、別のデータベースに移管されてもよい。

後払い情報データベース５６には、上述のように、後払い情報を含む各種情報であって、後払い機能に関する各種情報（図１１参照）が格納される。後払い情報データベース５６内の情報は、判定部３８や上限値設定部４４等により適宜更新される。

ところで、本実施形態では、上述のように、ユーザ情報データベース５０内のユーザ情報（図６参照）は、ユーザの現実世界の情報（年齢、収入、住所など）を含まないか、含んでいたとしても、その真偽は不問とされる（例えば身分証明書等によりその真偽を検証することはしない）。従って、金融機関やクレジットカード会社等が行う与信とは異なり、ユーザ情報データベース５０内のユーザ情報に基づいて信頼性の高い与信を行うことは難しい。

また、デジタルコンテンツを扱うサイト（例えばサイトＡ）では、デジタルコンテンツを楽しむ観点からは、ユーザの現実世界の情報（年齢、収入、住所など）は重要でなく、このような現実世界の情報をユーザに入力することを要求することは、ユーザにとって負担となる。特に、動画やゲーム等のようなデジタルコンテンツを楽しむだけのユーザに、現実世界の正確な情報の入力を求めることは、違和感を与えやすい。これは、デジタルコンテンツを楽しむだけでなく、その中で後払い機能という利便性を享受したいと考えるユーザにとっても同様であり、かかるユーザにとっても、少ない負担（例えばユーザ情報の入力負担）で、後払い機能の利便性を享受できる方が、ユーザフレンドリーの観点からも良い。

また、デジタルコンテンツを扱うサイトでは、仮に現実世界の情報（年齢、収入、住所など）の入力をユーザに強いたとしても、正確な情報の入力を期待できない。これは、デジタルコンテンツを購入した場合でも、当該デジタルコンテンツは、現実世界の住所に送付されるわけでないためである。これは、現実世界の住所の正確な入力がユーザにとっても重要となる、衣類や家具などを扱うＥＣ（Ｅｌｅｃｔｒｏｎｉｃ Ｃｏｍｍｅｒｃｅ：電子商取引）サイトとは対照的である。

この点、本実施形態によれば、上述のように、ある一のユーザが後払い機能を利用できるか否かは、当該一のユーザのログ情報に基づいて判定される。従って、本実施形態によれば、各ユーザに、現実世界の正確な情報（年齢、収入、住所など）の入力を強いることなく、各ユーザのログ情報を利用して、後払い機能の利用可否を判断することができる。この結果、本実施形態によれば、ユーザの負担を低減した利便性の高い態様で、後払いを条件としたＡコインの提供（及びそれに伴う他のデジタルコンテンツの提供）が可能となる。
また、本実施形態では、上述のように、判定部３８に加えて、上限値設定部４４が設けられるので、実質的に２段階で各ユーザの後払い機能の利用条件（利用可否や利用態様）を判定できる。これにより、各ユーザの後払い機能の利用可能性を多面的に評価でき（すなわち各ユーザの特性を柔軟に評価でき）、幅広いユーザに後払い機能を利用しやすくしつつ、後払い機能の正常の運用を担保しやすくすることができる。また、すべてのユーザのうちの、判定部３８により後払い機能の利用が可能と判定されたユーザについてのみ上限値設定部４４による上限値Ｎｍａｘの設定処理が行われるため、すべてのユーザに対して、後払い機能の利用の可否判定と上限値の設定とを同時に実現するような複雑な処理を行う場合より、サーバ装置１０の処理負荷を軽減できる。

また、本実施形態では、上述のように、活動制限部４２が設けられるので、ユーザのログ情報を利用するだけの与信によっても、後払い機能を利用したユーザによる支払い（“回収不能な利用”以外の利用態様）を高い確度で期待できる（すなわち比較的高い債権の回収率を期待できる）。これは、上述のように、活動制限部４２による制限は、アカウントの停止を含むためである。サイトＡを楽しむユーザにとっては、アカウントの停止は、最も避けたいペナルティである。これは、アカウントが停止すると、それまでの活動を無に帰することになるためである。特に、サイトＡの利用頻度の高いユーザや利用期間が長いユーザは、サイトＡで培った資産（ＳＮＳ機能でつながる友達やゲーム媒体等）が大きく、アカウントの停止による実質的な損害は大きくなる傾向がある。また、電子書籍などを所有するユーザは、所有する電子書籍などのデジタルコンテンツの数や種類等が多いほど、アカウントの停止による実質的な損害は大きくなる傾向がある。従って、かかるユーザは、アカウントの停止を避けるべく、“回収不能な利用”以外の態様で後払い機能を利用する可能性が高いことを期待できる。

また、本実施形態では、上述のように、活動制限部４２は、未払い時間ΔＴ１に応じて、サイトＡにおける未払いユーザによる活動を段階的に制限するので、ユーザにとっては、不用意な未払い（意図しない未払い）による即座にアカウントの停止といったリスクがなく、気軽に利用しやすい態様の後払い機能を実現できる。

また、本実施形態では、上述のように、催促情報出力部４０が設けられるので、ユーザが意図せずアカウントの停止という最終処分（４段階目の制限）を受ける、という可能性を低減できる。

特に、本実施形態では、催促情報出力部４０は、サイトＡを介して催促情報を出力するので、サイトＡを利用するユーザには伝わりやすい態様で、催促情報を出力できる。後払い機能を利用するユーザは、サイトＡを利用する頻度が比較的高い可能性があり、催促情報に接する機会を効果的に増やすことができる。換言すると、サイトＡを利用する頻度が比較的高いユーザに対して、後払い機能の利用が可能であると判定部３８により判定されやすくすることも可能であり、この結果、後払い機能を利用したユーザによる支払い（後払い）を高い確度で期待できる。

また、本実施形態では、催促情報出力部４０は、上述のように、未払い時間ΔＴ１に応じて、催促情報の注意喚起度を変化させるので、未払い時間ΔＴ１が比較的短いユーザに対しては、煩わしさが比較的小さい態様での催促情報の出力が可能となるとともに、未払い時間ΔＴ１が比較的長いユーザに対しては、支払いを強く促すべく煩わしさが比較的大きい態様での催促情報の出力が可能となる。これにより、催促情報の利便性（意図せずに遅延が発生したユーザに対するお知らせ機能としての利便性）を高めつつ、催促情報の本来の機能（未払いユーザに支払いを催促する機能）を確保できる。

特に、本実施形態では、催促情報出力部４０は、未払い時間ΔＴ１が比較的長くなると、未払いユーザにショートメッセージを送信する態様で催促情報を出力するので、催促情報の本来の機能（未払いユーザに支払いを催促する機能）を高めることができる。これは、ショートメッセージで送信される催促情報は、他の態様で出力される催促情報に比べて、効力が高い傾向があるためである。また、ショートメッセージの場合、サイトＡを介した通知とは異なり、サイトＡに係る画面をユーザが端末装置２０上に表示させなくても（サイトＡの立ち上げ、サイトＡへのログイン等の操作を必要とすることなく）、ユーザが日常的に行う傾向が高いショートメッセージの閲覧の際にユーザに通知できる。また、ショートメッセージは、変更が難しい情報（電話番号）に紐づく通知方法であるため、実効性が高い通知（催促）を実現できる。

（サービス提供システムの動作例）
次に、図１４から図２２を参照して、サーバ装置１０の動作例について説明する。なお、以下で説明する動作例は、あくまで一例であり、多様な変更が可能である。

図１４から図２２は、後払い機能に関連するサーバ装置１０の動作例を示す概略フローチャートである。

図１４は、後払い機能の利用可否の判定に関する動作例を示す概略フローチャートである。図１４に示す処理は、定期的に（例えば１ヶ月に１回）実行されてもよい。

ステップＳ１４０２では、サーバ装置１０は、全ユーザ（登録されたすべてのユーザＩＤ）のうちの、判定対象の複数のユーザを抽出する。判定対象のユーザは、任意であるが、前回の判定時から一定量以上のログ情報が更に蓄積されたユーザであってもよいし、前回の判定時から所定期間経過したユーザであってもよい。

ステップＳ１４０４では、サーバ装置１０は、ステップＳ１４０２で抽出したユーザのうちから、一のユーザを選択する。

ステップＳ１４０６では、サーバ装置１０は、選択した一のユーザに係るログ情報をログ情報データベース５２から抽出する。

ステップＳ１４０８では、サーバ装置１０は、ステップＳ１４０６で抽出したログ情報に基づいて、選択した一のユーザについて後払い機能が利用可能であるか否かを判定する。なお、判定方法は、上述のとおりである。ここでは、判定方法は、一例として、上述した指標値αの算出を伴うものとする。

ステップＳ１４１０では、サーバ装置１０は、ステップＳ１４０６で抽出したログ情報に基づいて、選択した一のユーザについて、後払い機能に係る上限値Ｎｍａｘを算出する。なお、上限値Ｎｍａｘの算出方法（設定方法）は、上述のとおりである。上限値Ｎｍａｘの算出に、選択した一のユーザに係る過去の支払い状況を加味する場合は、上述のように、選択した一のユーザに対応付けられた後払い情報（図１１の“利用実績”等）が利用されてよい。

ステップＳ１４１２では、サーバ装置１０は、ステップＳ１４０８での判定結果及びステップＳ１４１０の算出結果に基づいて、選択した一のユーザに対応付けられたデータベース内の情報を更新する。具体的には、サーバ装置１０は、後払い情報データベース５６内の“後払い可否”及び“上限値”、及び指標値データベース５４内の各指標値αを更新する。

ステップＳ１４１４では、サーバ装置１０は、ステップＳ１４０２で抽出したすべてのユーザをそれぞれ選択したか否かを判定する。判定結果が“ＹＥＳ”の場合は、そのまま終了し、それ以外の場合は、ステップＳ１４１６を経て、ステップＳ１４０６に戻る。

ステップＳ１４１６では、サーバ装置１０は、ステップＳ１４０２で抽出したユーザのうちから、未選択の一のユーザを新たに選択する。この場合、新たに選択された一のユーザに関して、ステップＳ１４０６からステップＳ１４１２の処理が実行される。

このようにして図１４に示す処理によれば、ユーザごとに、ログ情報に基づいて後払い機能の利用可否を判定するとともに、ログ情報に基づいて上限値Ｎｍａｘを設定できる。

図１５は、ユーザによる後払い機能の利用場面に関する動作例を示す概略フローチャートである。図１５に示す処理は、例えば所定周期ごとに繰り返し実行されてよい。

ステップＳ１５０２では、サーバ装置１０は、任意のユーザ（サイトＡにログイン中のユーザ）から、後払い機能の利用によるＡコインの提供要求を受信したか否かを判定する。なお、Ａコインの提供要求は、例えばユーザが図３に示したボタンＢ５０を操作することで進む申込み画面（図示せず）で生成され、サーバ装置１０に送信されてよい。Ａコインの提供要求は、提供を受けたいＡコインの数の情報を含んでよい。判定結果が“ＹＥＳ”の場合は、ステップＳ１５０４に進み、それ以外の場合は、今回周期の処理は終了する。

ここでは、一例として、図３に示したボタンＢ５０は、全ユーザに係るサイトＡ上において、操作可能な態様で表示されるものとする。ただし、変形例では、図３に示したボタンＢ５０は、後払い機能が利用可能なユーザに係るサイトＡ上においてのみ、操作可能な態様で表示されてもよい。また、この変形例では、ある一のユーザが申込み可能なＡコインの数は、当該一のユーザに対応付けられた上限値Ｎｍａｘを超えない数であってよい。この場合、後述のステップＳ１５０４、ステップＳ１５０６、及びステップＳ１５１６は不要である。

ステップＳ１５０４では、サーバ装置１０は、ステップＳ１５０２で受信した提供要求に係るユーザ（以下、「要求元のユーザ」と称する）に対応付けられた情報であって、後払い情報データベース５６内の“後払い可否”及び“上限値”、及び請求情報データベース５５内の“請求額（現時点での支払い前の対価の累積値）”を抽出する。

ステップＳ１５０６では、サーバ装置１０は、ステップＳ１５０４で抽出した情報に基づいて、要求元のユーザに対して、提供要求に係るＡコインの数で、Ａコインの提供が可能であるか否かを判定する。すなわち、サーバ装置１０は、提供要求に応えることができるか否かを判定する。具体的には、サーバ装置１０は、要求元のユーザが後払い機能を利用可能なユーザであり、かつ、提供要求に係るＡコインの数が、要求元のユーザに対応付けられた上限値Ｎｍａｘと、同ユーザに対応付けられた請求額（現時点での支払い前の対価の累積値）との差に対応する数以下である場合に、提供要求に応えることができると判定する。判定結果が“ＹＥＳ”の場合は、ステップＳ１５０８に進み、それ以外の場合は、ステップＳ１５１６に進む。

ステップＳ１５０８では、サーバ装置１０は、ステップＳ１５０２で受信したＡコインの提供要求に応える。すなわち、サーバ装置１０は、要求元のユーザに対応付けられた所持コイン（図６に示したユーザ情報における所持コイン）を更新する。この場合、サーバ装置１０は、当該ユーザに対応付けられた所持コインの数値を、提供要求に係るＡコインの数だけ増加する。

ステップＳ１５１０では、サーバ装置１０は、ステップＳ１５０２で受信した提供要求が、同ユーザによる今月の初回の提供要求（すなわち、今月の初回の後払い機能の利用）であるか否かを判定する。判定結果が“ＹＥＳ”の場合は、ステップＳ１５１２に進み、それ以外の場合は、ステップＳ１５１４に進む。

ステップＳ１５１２では、サーバ装置１０は、新たな請求書ＩＤを発行し、当該請求書ＩＤに係る請求書情報を生成する（図１０参照）。このとき、請求書情報の“請求額”は、今回の提供要求に応じて提供したＡコインの対価に対応する。

ステップＳ１５１４では、サーバ装置１０は、要求元のユーザに対応付けられた請求書情報のうちの、既に発行済みの今月分の請求書ＩＤに係る請求書情報を更新する。このとき、当該請求書情報の“請求額”（図１０参照）は、今回の提供要求に応じて提供したＡコインの対価分だけ増加する。

ステップＳ１５１６では、サーバ装置１０は、要求元のユーザに対して、今回の提供要求に応えられない旨（すなわちＡコインを提供できない旨）を通知する。なお、当該通知は、サイトＡを介して実現されてもよい。また、当該通知は、提供可能なＡコインの数（要求元のユーザに対応付けられた上限値Ｎｍａｘと、同ユーザに対応付けられた請求額との差）の情報を含んでよい。

図１５に示す処理によれば、Ａコインの提供要求であって後払い機能の利用によるＡコインの提供要求が受信されると、所定の条件（ステップＳ１５０６参照）が満たされることを前提として、提供要求に係るＡコインの数を、要求元のユーザに提供できる。なお、図１４及び図１５に示す処理では、ユーザからＡコインの提供要求を受信する前に、当該ユーザによる後払い機能の利用可否が判定されているが、これに限られない。変形例では、ユーザからＡコインの提供要求が受信された場合に、当該ユーザによる後払い機能の利用可否が判定されてもよい。

図１６は、請求書情報の出力に関連した動作例を示す概略フローチャートである。図１６に示す処理は、例えば所定周期ごとに繰り返し実行されてよい。

ステップＳ１６０２では、サーバ装置１０は、サイトＡに任意のユーザが新たにログインしたか否かを判定する。判定結果が“ＹＥＳ”の場合は、ステップＳ１６０４に進み、それ以外の場合は、今回周期の処理は終了する。

ステップＳ１６０４では、サーバ装置１０は、請求情報データベース５５内から、ステップＳ１６０２で新たなログインを行ったユーザに対応付けられたすべての請求書ＩＤを抽出する。

ステップＳ１６０６では、サーバ装置１０は、ステップＳ１６０４で抽出した請求書ＩＤのうちに、状態が“１”の出力要否フラグ（図１０参照）が対応付けられた請求書ＩＤが存在するか否かを判定する。判定結果が“ＹＥＳ”の場合は、ステップＳ１６０８に進み、それ以外の場合は、今回周期の処理は終了する。

なお、変形例では、サーバ装置１０は、ステップＳ１６０４において、ステップＳ１６０２で新たなログインを行ったユーザに対応付けられたすべての請求書ＩＤのうちの、状態が“１”の出力要否フラグ（図１０参照）が対応付けられた請求書ＩＤを抽出してもよい。この場合、ステップＳ１６０６は省略されてよい。すなわち、状態が“１”の出力要否フラグ（図１０参照）が対応付けられた請求書ＩＤを抽出できた場合は、ステップＳ１６０８に進み、抽出できなかった場合は、今回周期の処理は終了する。

ステップＳ１６０８では、サーバ装置１０は、状態が“１”の出力要否フラグが対応付けられた請求書ＩＤに係る請求書情報（確定した請求書情報）を、ステップＳ１６０２で新たなログインを行ったユーザに向けて送信する。すなわち、サーバ装置１０は、当該ユーザがログインしているサイトＡ上に請求書情報を出力する。

ステップＳ１６１０では、サーバ装置１０は、ステップＳ１６０８で出力した請求書情報に係る請求書ＩＤに対応付けられた出力要否フラグを、“０”にセットする。

図１６に示す処理によれば、サイトＡを介して各ユーザに向けて請求書情報を出力することができる。なお、図１６に示す処理とは別に、請求書情報は、締め日以降の通知日に、各ユーザに対応付けられたメールアドレスに送信されてもよいし、各ユーザに別の手段で通知されてもよい。

なお、図１６に示す処理では、サイトＡ上に請求書情報が出力されることで、出力要否フラグが“０”にセットされるが、これに限られない。例えば、サイトＡ上に請求書情報を出力することに代えて又は加えて、ユーザに対応付けられたメールアドレスに請求書情報が送信されることで、出力要否フラグが“０”にセットされてもよい。あるいは、サイトＡ上に請求書情報を出力することに代えて又は加えて、支払い用の画面（図示せず）への遷移が実現された場合に、出力要否フラグが“０”にセットされてもよい。

図１７から図２０は、活動制限処理に関連した動作例を説明するための概略フローチャートである。図１７は、活動制限処理に関連した動作例を示す概略フローチャートである。図１７に示す処理は、例えば日ごとに繰り返し実行されてよい。

ステップＳ１７２では、サーバ装置１０は、支払い通知に基づく請求書情報（支払状況カテゴリ）の更新処理を実行する。本更新処理については、図１８を参照して後述する。

ステップＳ１７４では、サーバ装置１０は、未払い時間ΔＴ１に応じた請求書情報（支払状況カテゴリ）の更新処理を実行する。本更新処理については、図１９を参照して後述する。

ステップＳ１７６では、サーバ装置１０は、ステップＳ１７４での処理結果に基づいて、支払状況カテゴリに応じた活動制限処理を実行する。支払状況カテゴリに応じた活動制限処理については、図２０を参照して後述する。

図１８は、支払い通知に基づく支払状況カテゴリの更新処理（図１７のステップＳ１７２）の一例を示す概略フローチャートである。

ステップＳ１８０２では、サーバ装置１０は、未処理の支払い通知を抽出する。なお、支払い通知は、コンビニ等でユーザが支払いを済ますとコンビニ等の端末（図示せず）からサーバ装置１０に送信される。サーバ装置１０は、支払い通知を受信すると、未処理の支払い通知を蓄積するための所定の記憶装置（データベース）（図示せず）に記憶していく。この場合、サーバ装置１０は、当該所定の記憶装置からすべての未処理の支払い通知を抽出する。

ステップＳ１８０４では、サーバ装置１０は、ステップＳ１８０２で抽出した未処理の支払い通知のうちの、一の支払い通知を選択する。

ステップＳ１８０６では、サーバ装置１０は、選択した一の支払い通知に係る支払い用の番号に対応付けられた請求書ＩＤを特定し、当該請求書ＩＤに係る支払状況カテゴリを“Ａ”に変更する。

ステップＳ１８０８では、サーバ装置１０は、ステップＳ１８０２で抽出した未処理の支払い通知のすべてを選択したか否かを判定する。判定結果が“ＹＥＳ”の場合は、そのまま終了し、それ以外の場合は、ステップＳ１８１０を経て、ステップＳ１８０６に戻る。

ステップＳ１８１０では、サーバ装置１０は、ステップＳ１８０２で抽出した未処理の支払い通知のうちから、未選択の一の支払い通知を新たに選択する。この場合、新たに選択された一の支払い通知に関して、ステップＳ１８０６の処理が実行される。

このようにして図１８に示す処理によれば、後払い機能を利用したユーザによる支払いがあると、対応する請求書ＩＤに係る支払状況カテゴリが“Ａ”に変更される。

図１９は、未払い時間ΔＴ１に応じた請求書情報の更新処理（図１７のステップＳ１７４）の一例を示す概略フローチャートである。

ステップＳ１９０２では、サーバ装置１０は、請求情報データベース５５内（図１０参照）から、“Ａ”以外の支払状況カテゴリが対応付けられたすべての請求書ＩＤを抽出する。

ステップＳ１９０４では、サーバ装置１０は、ステップＳ１９０２で抽出した請求書ＩＤのうちから、一の請求書ＩＤを選択する。

ステップＳ１９０６では、サーバ装置１０は、ステップＳ１９０４で選択した請求書ＩＤに関して、未払い時間ΔＴ１が４段階目の制限に係る閾値（本実施形態では、一例として、上述したように、支払い期限日から四月後の末日までの時間）を超えたか否かを判定する。判定結果が“ＹＥＳ”の場合は、ステップＳ１９０８に進み、それ以外の場合は、ステップＳ１９１０に進む。

ステップＳ１９０８では、サーバ装置１０は、ステップＳ１９０４で選択した請求書ＩＤに対応付けられた支払状況カテゴリを“Ｂ４”にセットする。

ステップＳ１９１０では、サーバ装置１０は、ステップＳ１９０４で選択した請求書ＩＤに関して、未払い時間ΔＴ１が３段階目の制限に係る閾値（本実施形態では、一例として、上述したように、支払い期限日の翌々月の末日までの時間）を超えたか否かを判定する。判定結果が“ＹＥＳ”の場合は、ステップＳ１９１２に進み、それ以外の場合は、ステップＳ１９１４に進む。

ステップＳ１９１２では、サーバ装置１０は、ステップＳ１９０４で選択した請求書ＩＤに対応付けられた支払状況カテゴリを“Ｂ３”にセット（又は維持）する。

ステップＳ１９１４では、サーバ装置１０は、ステップＳ１９０４で選択した請求書ＩＤに関して、未払い時間ΔＴ１が２段階目の制限に係る閾値（本実施形態では、一例として、上述したように、支払い期限日の翌月の末日＋１０日までの時間）を超えたか否かを判定する。判定結果が“ＹＥＳ”の場合は、ステップＳ１９１６に進み、それ以外の場合は、ステップＳ１９１８に進む。

ステップＳ１９１６では、サーバ装置１０は、ステップＳ１９０４で選択した請求書ＩＤに対応付けられた支払状況カテゴリを“Ｂ２”にセット（又は維持）する。

ステップＳ１９１８では、サーバ装置１０は、ステップＳ１９０４で選択した請求書ＩＤに関して、未払い時間ΔＴ１が１段階目の制限に係る閾値（本実施形態では、一例として、上述したように、支払い期限日の翌月の末日までの時間）を超えたか否かを判定する。判定結果が“ＹＥＳ”の場合は、ステップＳ１９２０に進み、それ以外の場合は、ステップＳ１９２２に進む。

ステップＳ１９２０では、サーバ装置１０は、ステップＳ１９０４で選択した請求書ＩＤに対応付けられた支払状況カテゴリを“Ｂ１”にセット（又は維持）する。

ステップＳ１９２２では、サーバ装置１０は、ステップＳ１９０４で選択した請求書ＩＤに関して、未払い時間ΔＴ１が０より大きいか（すなわち支払い期限日以降であるか）否かを判定する。判定結果が“ＹＥＳ”の場合は、ステップＳ１９２４に進み、それ以外の場合は、ステップＳ１９２６進む。

ステップＳ１９２４では、サーバ装置１０は、ステップＳ１９０４で選択した請求書ＩＤに対応付けられた支払状況カテゴリを“Ｂ０”にセット（又は維持）する。

ステップＳ１９２６では、サーバ装置１０は、ステップＳ１９０２で抽出した請求書ＩＤのうちの、すべての請求書ＩＤを選択したか否かを判定する。判定結果が“ＹＥＳ”の場合は、今回周期の処理は終了し、それ以外の場合は、ステップＳ１９２８を経て、ステップＳ１９０６に戻る。

ステップＳ１９２８では、サーバ装置１０は、ステップＳ１９０２で抽出した請求書ＩＤのうちから、未選択の一の請求書ＩＤを新たに選択する。この場合、新たに選択された一の請求書ＩＤに関して、ステップＳ１９０６からステップＳ１９２４の処理が実行される。

このようにして図１９に示す処理によれば、請求書ＩＤごとに、未払い時間ΔＴ１に応じて支払状況カテゴリを更新できる。

図２０は、支払状況カテゴリに応じた活動制限処理（図１７のステップＳ１７６）の一例を示す概略フローチャートである。

ステップＳ２００２では、サーバ装置１０は、後払い情報データベース５６（図１１参照）内から、後払い機能を利用可能なすべてのユーザＩＤを抽出する。後払い機能を利用可能なユーザＩＤは、後払い情報データベース５６内の“後払い可否”に基づいて抽出できる。

ステップＳ２００４では、サーバ装置１０は、ステップＳ２００２で抽出したユーザＩＤのうちの、一のユーザＩＤを選択する。

ステップＳ２００６では、サーバ装置１０は、請求情報データベース５５（図１０参照）内から、選択したユーザＩＤに対応付けられたすべての請求書ＩＤを抽出する。選択したユーザＩＤに対応付けられた請求書ＩＤを抽出できない場合、当該ユーザＩＤについてはステップＳ２００８及びステップＳ２０１０が省略されてよい。

ステップＳ２００８では、サーバ装置１０は、ステップＳ２００６で抽出した請求書ＩＤに対応付けられた支払状況カテゴリのうちの、最も悪い支払状況カテゴリを特定する。なお、支払状況カテゴリは、上述のように、“分類なし”、“Ａ”、及び“Ｂ０”から“Ｂ４”まであり、“分類なし”又は“Ａ”が最も良く、“Ｂ０”から“Ｂ４”の順に悪くなるものとする。

ステップＳ２０１０では、サーバ装置１０は、選択したユーザＩＤに係るユーザに対して、ステップＳ２００８で特定した最も悪い支払状況カテゴリに応じて制限度合いを決定し、決定した制限度合いで、サイトＡにおける未払いユーザによる活動に対する制限を実現する。

具体的には、ステップＳ２００８で特定した支払状況カテゴリが“分類なし”、“Ａ”又は“Ｂ０”である場合、サーバ装置１０は、特段の制限を実現しない。また、選択したユーザＩＤに対して何らかの制限（すなわち、上述の１段階目から３段階目の制限）が実現されている状態では、サーバ装置１０は、当該制限を解除する。

また、ステップＳ２００８で特定した支払状況カテゴリが“Ｂ１”である場合、サーバ装置１０は、１段階目の制限（本実施形態では、上述のように後払い機能の停止）を実現する。この場合、例えば、サーバ装置１０は、後払い情報データベース５６内の“後払い可否”であって、選択したユーザＩＤに対応付けられた“後払い可否”を“×”に変更する。この場合、当該ユーザＩＤに対応付けられた“後払い可否”は、判定部３８による判定結果に応じて書き換え不可とされてよい。あるいは、サーバ装置１０は、選択したユーザＩＤに対応付けられた上限値Ｎｍａｘを“０”にすることで、当該ユーザＩＤに係るユーザによる後払い機能の利用を実質的に不能としてもよい。

また、ステップＳ２００８で特定した支払状況カテゴリが“Ｂ２”である場合、サーバ装置１０は、２段階目の制限（本実施形態では、上述のように後払い機能以外のＡコインの獲得手段の利用を停止）を実現する。この場合、例えば、サーバ装置１０は、選択したユーザＩＤに対応付けられた所持コイン（図６参照）を増加させる如何なる処理の実行も禁止する。

また、ステップＳ２００８で特定した支払状況カテゴリが“Ｂ３”である場合、サーバ装置１０は、３段階目の制限（本実施形態では、上述のようにゲームのプレイの禁止）を実現する。この場合、例えば、ゲーム処理部３１１は、選択したユーザＩＤに基づくゲームのプレイを禁止する。

また、ステップＳ２００８で特定した支払状況カテゴリが“Ｂ４”である場合、サーバ装置１０は、４段階目の制限（本実施形態では、上述のようにアカウントの停止）を実現する。この場合、例えば、サーバ装置１０は、選択したユーザＩＤに基づくサイトＡのログイン状態を解除し（強制的にログアウトさせ）、以後、当該ユーザＩＤに基づくサイトＡのログインを禁止する。また、サーバ装置１０は、支払状況カテゴリ“Ｂ４”の発生をサービス提供システム１の管理者等に通知してもよい。

ステップＳ２０１２では、サーバ装置１０は、ステップＳ２００２で抽出したすべてのユーザＩＤをそれぞれ選択したか否かを判定する。判定結果が“ＹＥＳ”の場合は、そのまま終了し、それ以外の場合は、ステップＳ２０１４を経て、ステップＳ２００６に戻る。

ステップＳ２０１４では、サーバ装置１０は、ステップＳ２００２で抽出したユーザＩＤのうちから、未選択の一のユーザＩＤを新たに選択する。この場合、新たに選択された一のユーザＩＤに関して、ステップＳ２００６からステップＳ２０１０の処理が実行される。

このようにして図２０に示す処理によれば、支払状況カテゴリが更新されると、それに応じて各ユーザに対する制限度合い（サイトＡにおける活動の制限に係る制限度合い）を変更（更新）できる。

図２１及び図２２は、催促情報の出力に関連した動作例を説明するための概略フローチャートである。

図２１は、所定操作に応じた催促情報の出力処理の一例を示す概略フローチャートである。図２１に示す処理は、所定周期ごとに繰り返し実行されてよい。

ステップＳ２１００では、サーバ装置１０は、任意のユーザによるサイトＡにおける所定操作を検出したか否かを判定する。所定操作は、催促情報の出力のトリガとなる操作であり、任意であるが、例えばサイトＡにおける各種活動（ログインや、ＳＮＳ機能へのアクセス／利用、ゲームのプレイ、課金等）に係る操作であってよい。判定結果が“ＹＥＳ”の場合は、ステップＳ２１０２に進み、それ以外の場合は、今回周期の処理は終了する。なお、２つ以上の所定操作（異なるユーザによる所定操作）が同時に検出された場合は、それぞれの所定操作ごとに、ステップＳ２１０２以降の処理が実行されてよい。

ステップＳ２１０２では、サーバ装置１０は、請求情報データベース５５（図１０参照）内から、ステップＳ２１００で検出した所定操作に係るユーザＩＤに対応付けられたすべての請求書ＩＤを抽出する。

ステップＳ２１０４では、サーバ装置１０は、ステップＳ２１０２で抽出した請求書ＩＤに対応付けられた支払状況カテゴリのうちの、最も悪い支払状況カテゴリを特定する。

ステップＳ２１０６では、サーバ装置１０は、ステップＳ２１０４で特定した最も悪い支払状況カテゴリが“Ａ”又は“分類なし”であるか否かを判定する。判定結果が“ＹＥＳ”の場合は、今回周期の処理は終了する。この場合、催促情報が出力されることはない。他方、判定結果が“ＮＯ”の場合は、ステップＳ２１０８に進む。

ステップＳ２１０８では、サーバ装置１０は、ステップＳ２１０４で特定した最も悪い支払状況カテゴリが“Ｂ０”であるか否かを判定する。判定結果が“ＹＥＳ”の場合は、ステップＳ２１１０に進み、それ以外の場合は、ステップＳ２１１２に進む。

ステップＳ２１１０では、サーバ装置１０は、第１段階の注意喚起度を有する催促情報を、ステップＳ２１００で検出した所定操作に係るユーザＩＤのユーザに向けて出力する。例えば、ステップＳ２１００で検出した所定操作がサイトＡへのログインである場合は、サーバ装置１０は、ログイン後の画面に、第１段階の注意喚起度を有する催促情報を出力する。第１段階の注意喚起度を有する催促情報は、注意喚起度が最も低い催促情報であり、例えば図１２に示したメッセージＭ１であってよい。

ステップＳ２１１２では、サーバ装置１０は、ステップＳ２１０４で特定した最も悪い支払状況カテゴリが“Ｂ１”であるか否かを判定する。判定結果が“ＹＥＳ”の場合は、ステップＳ２１１４に進み、それ以外の場合は、ステップＳ２１１６に進む。

ステップＳ２１１４では、サーバ装置１０は、第２段階の注意喚起度を有する催促情報を、ステップＳ２１００で検出した所定操作に係るユーザＩＤのユーザに向けて出力する。第２段階の注意喚起度を有する催促情報は、注意喚起度が第１段階よりも高い催促情報であり、例えば、図１２に示したメッセージＭ１よりもサイズが大きい同様のメッセージ（図示せず）であってよい。また、第２段階の注意喚起度を有する催促情報は、１段階目の制限（本実施形態では、上述のように後払い機能の停止）が実現されている現況情報や、未払いがなお継続した場合は次の２段階目の制限が実現されることの予告情報を含んでもよい。

ステップＳ２１１６では、サーバ装置１０は、ステップＳ２１０４で特定した支払状況カテゴリが“Ｂ２”であるか否かを判定する。判定結果が“ＹＥＳ”の場合は、ステップＳ２１１８に進み、それ以外の場合（すなわちステップＳ２１０４で特定した支払状況カテゴリが“Ｂ３”である場合）は、ステップＳ２１２０に進む。

ステップＳ２１１８では、サーバ装置１０は、第３段階の注意喚起度を有する催促情報を、ステップＳ２１００で検出した所定操作に係るユーザＩＤのユーザに向けて出力する。第３段階の注意喚起度を有する催促情報は、注意喚起度が第２段階よりも高い催促情報である。第３段階の注意喚起度を有する催促情報は、２段階目の制限が実現されている現況情報や、未払いがなお継続した場合は次の３段階目の制限が実現されることの予告情報を含んでもよい。

ステップＳ２１２０では、サーバ装置１０は、第４段階の注意喚起度を有する催促情報を、ステップＳ２１００で検出した所定操作に係るユーザＩＤのユーザに向けて出力する。第４段階の注意喚起度を有する催促情報は、注意喚起度が第３段階よりも高い催促情報である。第４段階の注意喚起度を有する催促情報は、３段階目の制限が実現されている現況情報や、未払いがなお継続した場合は次の４段階目の制限が実現されることの予告情報を含んでもよい。

図２１に示す処理によれば、催促情報の出力対象のユーザに、サイトＡを介して催促情報を効率的に出力できる。なお、図２１に示す処理では、第１段階から第４段階の注意喚起度を有する各催促情報は、同じ所定操作をトリガとして出力されるが、これに限られない。例えば、注意喚起度が高い催促情報ほど出力機会が増えるように、催促情報の出力のトリガとなる所定操作の種類が、注意喚起度が高い催促情報ほど多くなるように構成されてもよい。

図２２は、支払状況カテゴリの変化に応答した催促情報の出力処理の一例を示す概略フローチャートである。図２２に示す処理は、図１７に示したステップＳ１７４の処理と連携して実行されてよい。

ステップＳ２２０２では、サーバ装置１０は、請求情報データベース５５（図１０参照）内から、図１７に示した処理のステップＳ１７６の結果として支払状況カテゴリが“Ｂ２”から“Ｂ３”に変化したすべてのユーザＩＤを抽出する。

ステップＳ２２０４では、サーバ装置１０は、ステップＳ２２０２で抽出したすべてのユーザＩＤのうちから、一のユーザＩＤを選択する。

ステップＳ２２０６では、サーバ装置１０は、選択したユーザＩＤに対応付けられた電話番号に、催促情報に係るショートメッセージを送信する。なお、変形例では、ショートメッセージに代えて又は加えて、選択したユーザＩＤに対応付けられた電話番号を発呼して催促情報に係る自動音声を流すことにより、催促情報の出力を実現してもよい。

ステップＳ２２０８では、サーバ装置１０は、ステップＳ２２０２で抽出したすべてのユーザＩＤをそれぞれ選択したか否かを判定する。判定結果が“ＹＥＳ”の場合は、そのまま終了し、それ以外の場合は、ステップＳ２２１０を経て、ステップＳ２２０６に戻る。

ステップＳ２２１０では、サーバ装置１０は、ステップＳ２２０２で抽出したユーザＩＤのうちから、未選択の一のユーザＩＤを新たに選択する。この場合、新たに選択された一のユーザＩＤに関して、ステップＳ２２０６の処理が実行される。

このようにして図２２に示す処理によれば、支払状況カテゴリが更新され、支払状況カテゴリが“Ｂ３”（３段階目の制限が実現されるユーザ）が発生すると、対応するユーザに対して、ショートメッセージという比較的高い注意喚起度を有する出力態様で催促情報を出力できる。

以上、各実施形態について詳述したが、特定の実施形態に限定されるものではなく、特許請求の範囲に記載された範囲内において、種々の変形及び変更が可能である。また、前述した実施形態の構成要素を全部又は複数を組み合わせることも可能である。

例えば、上述した実施形態では、上述したように、サイトＡのユーザは、Ａコインのみを介して他のデジタルコンテンツの提供を受けることが可能であるが、これに限られない。すなわち、サイトＡのユーザは、Ａコインを介さずに、他のデジタルコンテンツの提供を受けることが可能であってよい。すなわち、サイトＡのユーザは、他のデジタルコンテンツの対価を直接的に支払うことを上限として、他のデジタルコンテンツの提供を受けることが可能であってよい。この場合も、後払い機能を利用可能とすることで、上述した実施形態と同様の効果が奏される。

また、上述した実施形態では、上述したように、後払い機能を利用するためのユーザの負荷を最小限にするために、ユーザの現実世界の情報（年齢、収入、住所など）を利用せずに、当該ユーザによる後払い機能の利用の可否を判定しているが、これに限られない。ログ情報とともに、ユーザの現実世界の情報を利用して、当該ユーザによる後払い機能の利用の可否を判定してもよい。

また、上述した実施形態では、サービス提供システム１においてサービスプラットホームを介して提供可能とされるサービスは、デジタルコンテンツに係るレイヤに関するが、通信ネットワークや端末等のような他のレイヤに関するサービスを含んでもよい。

また、上述した実施形態では、後払い機能は、一のサービスプラットホームにおいて、閉じて実現されているが、複数のサービスプラットホーム間で連携して実現されてもよい。この場合、判定部３８が利用するログ情報も、複数のサービスプラットホームで収集されたものであってもよい。

また、上述した実施形態では、上述したように、活動制限部４２によるゲームのプレイに関する制限は、ゲームのプレイの禁止であるが、これに限られない。活動制限部４２は、ゲームのプレイの禁止に代えて、ゲームのプレイを部分的に制限してもよい。ゲームのプレイを部分的に制限する方法は、任意であるが、プレイ時間を制限することで実現されてもよい。また、活動制限部４２は、ゲーム媒体の一部の利用を制限する（例えばデッキに組み込むことができる第１ゲーム媒体のコストを制限することや、デッキに組み込むことができる第１ゲーム媒体の種類を制限すること等）ことで、ゲームのプレイを部分的に制限してもよい。また、活動制限部４２は、未払い時間ΔＴ１の増加に連動して、ゲームのプレイの制限度合いを高めることとしてもよい。この場合、活動制限部４２は、未払い時間ΔＴ１が最終的な所定時間を超えると、ゲームのプレイを禁止してもよい。これは、ゲームのプレイに関する制限についても同様である。例えば、活動制限部４２が、他のデジタルコンテンツの利用（電子書籍や、映像視聴など）に関する制限を行う場合、当該制限は、利用の禁止であってもよいし、利用の部分的な制限であってもよい。この場合、部分的な制限は、デジタルコンテンツの利用時間（例えば一定期間あたりの利用時間や、総利用時間等）が制限されてもよいし、利用可能な時間帯等が制限されてもよい。また、活動制限部４２は、未払い時間ΔＴ１の増加に連動して、他のデジタルコンテンツの利用の制限度合いを高めることとしてもよい。この場合、活動制限部４２は、未払い時間ΔＴ１が最終的な所定時間を超えると、当該他のデジタルコンテンツの利用を禁止してもよい。

なお、以上の実施形態に関し、さらに以下の付記を開示する。

［付記１］
ユーザ識別情報に対応付けられたログ情報を取得するログ情報取得部と、
デジタルコンテンツに係る対価の支払いであって、前記デジタルコンテンツを提供した後の所定期限までの前記ユーザ識別情報に係るユーザによる対価の支払いを条件として、前記ログ情報に基づいて、前記ユーザ識別情報に係るユーザに前記デジタルコンテンツを提供するサービス提供部とを含む、デジタルコンテンツ提供装置。

［付記２］
前記ログ情報に基づいて、前記ログ情報に対応付けられた前記ユーザ識別情報に係るユーザへの前記サービス提供部による前記デジタルコンテンツの提供の可否を判定する判定部を更に含み、
前記サービス提供部は、前記判定部の判定結果に基づいて、前記ユーザ識別情報に係るユーザに前記デジタルコンテンツを提供する、付記１に記載のデジタルコンテンツ提供装置。

［付記３］
前記デジタルコンテンツに係る対価が前記所定期限までに支払われていない場合に、前記デジタルコンテンツに係る対価を支払うように前記ユーザ識別情報に係るユーザに促す催促情報を出力する催促情報出力部を更に含む、付記１又は２に記載のデジタルコンテンツ提供装置。

［付記４］
前記催促情報出力部は、所定の第１タイミングからの経過時間に応じて、前記催促情報の出力態様を変化させる、付記３に記載のデジタルコンテンツ提供装置。

［付記５］
前記催促情報出力部は、前記第１タイミングからの経過時間が第１所定時間を超えると、前記ユーザ識別情報に基づきログインしているサイトを介して前記催促情報を出力する、付記４に記載のデジタルコンテンツ提供装置。

［付記６］
前記催促情報出力部は、前記第１タイミングからの経過時間が第２所定時間を超えると、前記ユーザ識別情報に対応付けられた電話番号にショートメッセージを送信する態様で、前記催促情報を出力する、付記４又は５に記載のデジタルコンテンツ提供装置。

［付記７］
前記デジタルコンテンツに係る対価が前記所定期限までに支払われていない場合に、前記ユーザ識別情報に基づく活動を制限する活動制限部を更に含む、付記１～６のうちのいずれか１項に記載のデジタルコンテンツ提供装置。

［付記８］
前記活動制限部は、所定の第２タイミングからの経過時間に応じて、前記ユーザ識別情報に基づく活動に対する制限態様を変化させる、付記７に記載のデジタルコンテンツ提供装置。

［付記９］
前記活動制限部は、前記第２タイミングからの経過時間が第３所定時間を超えると、前記ユーザ識別情報に基づく活動の一部を禁止する、付記８に記載のデジタルコンテンツ提供装置。

［付記１０］
前記活動制限部は、前記第２タイミングからの経過時間が前記第３所定時間よりも長い第５所定時間を更に超えると、前記ユーザ識別情報に基づく活動のすべてを禁止する、付記９に記載のデジタルコンテンツ提供装置。

［付記１１］
前記サービス提供部は、サービスプラットホームを介して、前記デジタルコンテンツの提供を含む各種のサービスを提供し、
前記活動制限部は、所定の第２タイミングからの経過時間が第３所定時間を超えると、前記ユーザ識別情報に基づく前記各種のサービスの一部の利用を制限し、かつ、前記第２タイミングからの経過時間が前記第３所定時間よりも長い第４所定時間を更に超えると、前記ユーザ識別情報に基づく前記各種のサービスのすべての利用を制限し、前記第２タイミングからの経過時間が前記第４所定時間よりも長い第５所定時間を更に超えると、前記ユーザ識別情報に基づく前記サービスプラットホームの利用を不能とする、付記７に記載のデジタルコンテンツ提供装置。

［付記１２］
前記サービス提供部は、前記ユーザ識別情報に対応付けられた上限値に支払い前の前記対価の累積値が達するまで、前記ユーザ識別情報に係るユーザからの要求に応じて、前記ユーザ識別情報に係るユーザに１つ以上の前記デジタルコンテンツを提供し、
前記ログ情報に基づいて前記上限値を設定する上限値設定部を更に含む、付記１～１１のうちのいずれか１項に記載のデジタルコンテンツ提供装置。

［付記１３］
前記上限値設定部は、前記ログ情報とともに、前記ユーザ識別情報に対応付けられた過去の前記対価の支払い状況に基づいて、前記上限値を設定する、付記１２に記載のデジタルコンテンツ提供装置。

［付記１４］
前記デジタルコンテンツは、視聴可能なコンテンツ、情報コンテンツ、消費可能なコンテンツ、及びゲーム媒体のうちの少なくともいずれか１つを含む、付記１～１３のうちのいずれか１項に記載のデジタルコンテンツ提供装置。

［付記１５］
前記ログ情報は、前記ユーザ識別情報に基づく活動に関する、付記１～１４のうちのいずれか１項に記載のデジタルコンテンツ提供装置。

［付記１６］
前記ユーザ識別情報に基づく活動は、前記ユーザ識別情報に基づくログイン、前記ユーザ識別情報に基づく課金、前記ユーザ識別情報に基づく前記デジタルコンテンツ又は他のデジタルコンテンツの利用、及び前記ユーザ識別情報に基づくＳＮＳの利用のうちの、少なくともいずれ１つに関する、付記１５に記載のデジタルコンテンツ提供装置。

［付記１７］
前記サービス提供部は、サービスプラットホームを介して、前記デジタルコンテンツの提供を含む各種のサービスを提供し、
前記ユーザ識別情報に基づく活動は、前記各種のサービスのうちの少なくとも一部の利用に関する、付記１５に記載のデジタルコンテンツ提供装置。

［付記１８］
ユーザ識別情報に対応付けられたログ情報を取得し、
デジタルコンテンツに係る対価の支払いであって、前記デジタルコンテンツを提供した後の所定期限までの前記ユーザ識別情報に係るユーザによる対価の支払いを条件として、前記ログ情報に基づいて、前記ユーザ識別情報に係るユーザに前記デジタルコンテンツを提供することを含む、コンピュータにより実行されるデジタルコンテンツ提供方法。

［付記１９］
ユーザ識別情報に対応付けられたログ情報を取得し、
デジタルコンテンツに係る対価の支払いであって、前記デジタルコンテンツを提供した後の所定期限までの前記ユーザ識別情報に係るユーザによる対価の支払いを条件として、前記ログ情報に基づいて、前記ユーザ識別情報に係るユーザに前記デジタルコンテンツを提供する、処理をコンピュータに実行させるプログラム。

１ サービス提供システム
１０ サーバ装置
１１ サーバ通信部
１２ サーバ記憶部
１３ サーバ制御部
２０ 端末装置
２１ 端末通信部
２２ 端末記憶部
２３ 表示部
２４ 入力部
２５ 端末制御部
３０ ユーザ登録部
３１ サービス提供部
３１１ ゲーム処理部
３１２ ＳＮＳ機能実現部
３１３ コンテンツ提供部
３１３１ コイン提供部
３１３２ デジタルコンテンツ提供部
３１４ 課金処理部
３１５ デジタルコンテンツ利用部
３４ ログ情報蓄積部
３６ ログ情報取得部
３８ 判定部
３９ 請求情報管理部
４０ 催促情報出力部
４２ 活動制限部
４４ 上限値設定部
５０ ユーザ情報データベース
５２ ログ情報データベース
５４ 指標値データベース
５５ 請求情報データベース
５６ 後払い情報データベース

Claims (19)

1. ユーザ識別情報に対応付けられた、前記ユーザ識別情報に基づく活動に関するログ情報を取得するログ情報取得部であって、前記ログ情報は、前記ユーザ識別情報に基づきログインすることにより利用可能な各種のサービスに関連し、前記各種のサービスは、デジタルコンテンツの提供を含む、前記ログ情報取得部と、
   前記ログ情報に基づいて、前記ユーザ識別情報に係るユーザの活動の活発度合いに相関する指標値を算出して閾値と対比し、前記ログ情報に対応付けられた前記ユーザ識別情報に係るユーザへの前記デジタルコンテンツの提供の可否を判定する判定部と、
   前記デジタルコンテンツに係る対価の支払いであって、前記デジタルコンテンツを提供した後の所定期限までの前記ユーザ識別情報に係るユーザによる対価の支払いを条件として、前記判定部の判定結果に基づいて、前記ユーザ識別情報に係るユーザに前記デジタルコンテンツを提供するサービス提供部とを含む、デジタルコンテンツ提供装置。
2. 前記デジタルコンテンツの提供は、前記各種のサービスにおける仮想的な電子データの利用を含み、
   前記ユーザ識別情報に対応付けられるユーザ情報は、電話番号以外、当該ユーザの現実世界の情報を含まない、請求項１に記載のデジタルコンテンツ提供装置。
3. 前記デジタルコンテンツに係る対価が前記所定期限までに支払われていない場合に、前記デジタルコンテンツに係る対価を支払うように前記ユーザ識別情報に係るユーザに促す催促情報を出力する催促情報出力部を更に含む、請求項１又は２に記載のデジタルコンテンツ提供装置。
4. 前記催促情報出力部は、所定の第１タイミングからの経過時間に応じて、前記催促情報の出力態様を変化させる、請求項３に記載のデジタルコンテンツ提供装置。
5. 前記催促情報出力部は、前記第１タイミングからの経過時間が第１所定時間を超えると、前記ユーザ識別情報に基づきログインしているサイトを介して前記催促情報を出力する、請求項４に記載のデジタルコンテンツ提供装置。
6. 前記催促情報出力部は、前記第１タイミングからの経過時間が第２所定時間を超えると、前記ユーザ識別情報に対応付けられた電話番号にショートメッセージを送信する態様で、前記催促情報を出力する、請求項４又は５に記載のデジタルコンテンツ提供装置。
7. 前記支払いの状況に応じて、前記ユーザ識別情報に基づく活動を段階的に制限する活動制限部を更に含む、請求項１～６のうちのいずれか１項に記載のデジタルコンテンツ提供装置。
8. 前記活動制限部は、前記デジタルコンテンツに係る対価が前記所定期限までに支払われていない場合に、前記ユーザ識別情報に基づく活動を制限する、請求項７のうちのいずれか１項に記載のデジタルコンテンツ提供装置。
9. 前記活動制限部は、所定の第２タイミングからの経過時間に応じて、前記ユーザ識別情報に基づく活動に対する制限態様を変化させる、請求項８に記載のデジタルコンテンツ提供装置。
10. 前記活動制限部は、前記第２タイミングからの経過時間が第３所定時間を超えると、前記ユーザ識別情報に基づく活動の一部を禁止する、請求項９に記載のデジタルコンテンツ提供装置。
11. 前記活動制限部は、前記第２タイミングからの経過時間が前記第３所定時間よりも長い第５所定時間を更に超えると、前記ユーザ識別情報に基づく活動のすべてを禁止する、請求項１０に記載のデジタルコンテンツ提供装置。
12. 前記サービス提供部は、サービスプラットホームを介して、前記デジタルコンテンツの提供を含む前記各種のサービスを提供し、
    前記活動制限部は、所定の第２タイミングからの経過時間が第３所定時間を超えると、
    前記ユーザ識別情報に基づく前記各種のサービスの一部の利用を制限し、かつ、前記第２タイミングからの経過時間が前記第３所定時間よりも長い第４所定時間を更に超えると、前記ユーザ識別情報に基づく前記各種のサービスのすべての利用を制限し、前記第２タイミングからの経過時間が前記第４所定時間よりも長い第５所定時間を更に超えると、前記ユーザ識別情報に基づく前記サービスプラットホームの利用を不能とする、請求項８に記載のデジタルコンテンツ提供装置。
13. 前記サービス提供部は、前記ユーザ識別情報に対応付けられた上限値に支払い前の前記対価の累積値が達するまで、前記ユーザ識別情報に係るユーザからの要求に応じて、前記ユーザ識別情報に係るユーザに１つ以上の前記デジタルコンテンツを提供し、
    前記ログ情報に基づいて前記上限値を設定する上限値設定部を更に含む、請求項１～１２のうちのいずれか１項に記載のデジタルコンテンツ提供装置。
14. 前記上限値設定部は、前記ログ情報とともに、前記ユーザ識別情報に対応付けられた過去の前記対価の支払い状況に基づいて、前記上限値を設定する、請求項１３に記載のデジタルコンテンツ提供装置。
15. 前記デジタルコンテンツは、視聴可能なコンテンツ、情報コンテンツ、消費可能なコンテンツ、及びゲーム媒体のうちの少なくともいずれか１つを含む、請求項１～１４のうちのいずれか１項に記載のデジタルコンテンツ提供装置。
16. 前記ユーザ識別情報に基づく活動は、前記ユーザ識別情報に基づくログイン、前記ユーザ識別情報に基づく課金、前記ユーザ識別情報に基づく前記デジタルコンテンツ又は他のデジタルコンテンツの利用、及び前記ユーザ識別情報に基づくＳＮＳの利用のうちの、少なくともいずれ１つに関する、請求項１～１５のうちのいずれか１項に記載のデジタルコンテンツ提供装置。
17. 前記サービス提供部は、サービスプラットホームを介して、前記デジタルコンテンツの提供を含む前記各種のサービスを提供し、
    前記ユーザ識別情報に基づく活動は、前記各種のサービスのうちの少なくとも一部の利用に関する、請求項１～１６のうちのいずれか１項に記載のデジタルコンテンツ提供装置。
18. ユーザ識別情報に対応付けられた、前記ユーザ識別情報に基づく活動に関するログ情報を取得し、前記ログ情報は、前記ユーザ識別情報に基づきログインすることにより利用可能な各種のサービスに関連し、前記各種のサービスは、デジタルコンテンツの提供を含み、
    前記ログ情報に基づいて、前記ユーザ識別情報に係るユーザの活動の活発度合いに相関する指標値を算出して閾値と対比し、前記ログ情報に対応付けられた前記ユーザ識別情報に係るユーザへの前記デジタルコンテンツの提供の可否を判定し、
    前記デジタルコンテンツに係る対価の支払いであって、前記デジタルコンテンツを提供した後の所定期限までの前記ユーザ識別情報に係るユーザによる対価の支払いを条件として、先立つ判定結果に基づいて、前記ユーザ識別情報に係るユーザに前記デジタルコンテンツを提供することを含む、コンピュータにより実行されるデジタルコンテンツ提供方法。
19. ユーザ識別情報に対応付けられた、前記ユーザ識別情報に基づく活動に関するログ情報を取得し、前記ログ情報は、前記ユーザ識別情報に基づきログインすることにより利用可能な各種のサービスに関連し、前記各種のサービスは、デジタルコンテンツの提供を含み、
    前記ログ情報に基づいて、前記ユーザ識別情報に係るユーザの活動の活発度合いに相関する指標値を算出して閾値と対比し、前記ログ情報に対応付けられた前記ユーザ識別情報に係るユーザへの前記デジタルコンテンツの提供の可否を判定し、
    前記デジタルコンテンツに係る対価の支払いであって、前記デジタルコンテンツを提供した後の所定期限までの前記ユーザ識別情報に係るユーザによる対価の支払いを条件として、先立つ判定結果に基づいて、前記ユーザ識別情報に係るユーザに前記デジタルコンテンツを提供する、処理をコンピュータに実行させるプログラム。
    

Images