JP2023001304A - Digital content provision device - Google Patents

Abstract

PROBLEM TO BE SOLVED: To enable provision of digital content in a highly convenient manner that reduces a burden on a user and is contingent on payment later.

SOLUTION: A digital content provision device including a log information acquisition part that acquires log information corresponding to user identification information and a service delivery unit that provides a digital content to a user pertaining to the user identification information based on the log information, subject to payment of the consideration by the user pertaining to the user identification information by a predetermined time period after the provision of the digital content delivery is disclosed.

SELECTED DRAWING: Figure 5

COPYRIGHT: (C)2023,JPO&INPIT

Description

Applied for Article 30, Paragraph 2 of the Patent Act Posted on the website on December 13, 2018 (https://games.gree.net/static/page/announcea_20181213?namespace=GGP.Announce.Info)

The present disclosure relates to a digital content providing device.

A service related to credit based on the information on the title given to the user, which gives the user a title that indicates the user's character based on behavioral information such as the user's request for content (news article) and posting of comments on the content. is known.

JP 2019-040607 A

However, with conventional technology, it is difficult to provide digital content on the condition of deferred payment in a highly convenient manner that reduces the burden on the user.

Accordingly, in one aspect, an object of the present invention is to make it possible to provide digital content on the condition of deferred payment in a highly convenient manner that reduces the burden on the user.

In one aspect, a log information acquisition unit that acquires log information associated with user identification information;
payment for the digital content, on the condition that the user pays for the user identification information by a predetermined deadline after the digital content is provided, the user identification information based on the log information; and a service providing unit that provides the digital content to the user.

In one aspect, according to the present invention, it is possible to provide digital content on the condition of deferred payment in a highly convenient manner that reduces the burden on the user.

1 is a block diagram of a service providing system according to one embodiment of the present invention; FIG. An example of a play screen for explaining an outline of a battle game part is shown. It is a figure which shows an example of the display screen of the site A in a terminal device. It is explanatory drawing of the flow of deferred payment. FIG. 4 is a functional block diagram relating to functions related to a postpay function among various functions realized by the server device; FIG. 4 is an explanatory diagram of data in a user information database; FIG. 4 is an explanatory diagram of information about a game; FIG. 4 is an explanatory diagram of data in a log information database; FIG. 4 is an explanatory diagram of data in an index value database; FIG. 4 is an explanatory diagram of data in a billing information database; FIG. 4 is an explanatory diagram of data in a deferred payment information database; It is a figure which shows an example of the output aspect of reminder information. It is a figure which shows another example of the output aspect of reminder information. 4 is a schematic flow chart showing an operation example related to determination of availability of a postpaid function; FIG. 10 is a schematic flowchart showing an operation example regarding a scene in which a user uses a deferred payment function; FIG. 4 is a schematic flow chart showing an operation example related to outputting bill information; 4 is a schematic flow chart showing an operation example related to activity restriction processing; FIG. 18 is a schematic flow chart showing an example of a payment status category update process (step S172 in FIG. 17) based on a payment notification; FIG. FIG. 18 is a schematic flow chart showing an example of bill information update processing (step S174 in FIG. 17) according to unpaid hours; FIG. FIG. 18 is a schematic flowchart showing an example of activity restriction processing (step S176 in FIG. 17) according to payment status category; FIG. It is a schematic flowchart which shows an example of output processing of the prompting information according to predetermined operation. FIG. 11 is a schematic flowchart showing an example of output processing of reminder information in response to a change in payment status category; FIG.

Hereinafter, each embodiment will be described in detail with reference to the accompanying drawings.

(Overview of service provision system)
An overview of a service providing system 1 according to an embodiment of the present invention will be described with reference to FIG. The service providing system 1 includes a server device 10 and one or more terminal devices 20 . Although three terminal devices 20 are illustrated in FIG. 1 for the sake of simplicity, the number of terminal devices 20 may be two or more.

The server device 10 is an information processing device such as a server managed by a service operator, for example. In this embodiment, as an example, the server device 10 implements a so-called service platform and provides various services via the service platform. Specifically, as an example, the server device 10 includes an application portal site (hereinafter also simply referred to as “site”), application software (hereinafter also simply referred to as “application”), social network function (hereinafter simply (also referred to as “SNS functionality”) to registered users (and guest users as appropriate). Hereinafter, registered users (and guest users if necessary) are also simply referred to as "users".

The number of sites provided by the server device 10 is arbitrary, but in this embodiment, as an example, it is assumed that there is one site (hereinafter also referred to as "site A").

The type and number of applications provided by the server device 10 are arbitrary. In addition, it may include various applications for using digital content (digital content other than game applications, which will be described later). A game application or the like may be made executable via the site A. Hereinafter, a game refers to a game related to a game application provided by the server device 10 .

The type and number of SNS functions provided by the server device 10 are arbitrary, but here, diary, chat, message board/bulletin board (community), comment, messenger, friend request, object transmission (gift transmission), etc. It may be a function such as SNS functionality may be enabled via Site A.

The terminal device 20 is an information processing device used by a user, such as a mobile phone, a smart phone, a tablet terminal, a PC (Personal Computer), or a game device. The terminal device 20 can execute various applications according to this embodiment. Various applications may be received by the terminal device 20 from the server device 10 or another predetermined application distribution server via the network 3, or stored in a storage device provided in the terminal device 20 or a memory readable by the terminal device 20. It may be stored in advance in a storage medium such as a card. The server device 10 and the terminal device 20 are communicably connected via the network 3 . For example, the server device 10 and the terminal device 20 cooperate to execute various processes related to services.

Note that the network 3 may include a wireless communication network, the Internet, a VPN (Virtual Private Network), a WAN (Wide Area Network), a wired network, or any combination thereof.

(Configuration of server device)
The configuration of the server device 10 will be specifically described. The server device 10 is configured by a server computer. The server device 10 may be implemented in cooperation with a plurality of server computers.

The server device 10 includes a server communication section 11 , a server storage section 12 and a server control section 13 .

The server communication unit 11 includes an interface that performs wireless or wired communication with an external device to transmit and receive information. The server communication unit 11 may include, for example, a wireless LAN (Local Area Network) communication module or a wired LAN communication module. The server communication unit 11 can transmit and receive information to and from the terminal device 20 via the network 3 .

The server storage unit 12 includes, for example, a primary storage device and a secondary storage device. For example, the server storage unit 12 may include semiconductor memory, magnetic memory, optical memory, or the like. The server storage unit 12 stores various information and programs used for service-related processing. At least part of the information and programs stored in the server storage unit 12 may be shared and synchronized with the terminal device 20 . Examples of information stored in the server storage unit 12 will be specifically described below.

Server control unit 13 includes one or more processors. The processor may include a general-purpose processor that implements a specific function by reading a specific program, and a dedicated processor that specializes in specific processing. The server control unit 13 controls the operation of the server device 10 as a whole. Details of the server control unit 13 will be described later.

(Configuration of terminal device)
The configuration of the terminal device 20 will be specifically described. As shown in FIG. 1 , the terminal device 20 includes a terminal communication section 21 , a terminal storage section 22 , a display section 23 , an input section 24 and a terminal control section 25 .

The terminal communication unit 21 includes an interface that communicates with an external device wirelessly or by wire to transmit and receive information. The terminal communication unit 21 may include a wireless communication module, a wireless LAN communication module, a wired LAN communication module, or the like compatible with mobile communication standards such as LTE (Long Term Evolution) (registered trademark). The terminal communication unit 21 can transmit and receive information to and from the server device 10 via the network 3 .

The terminal storage unit 22 includes, for example, a primary storage device and a secondary storage device. For example, the terminal storage unit 22 may include semiconductor memory, magnetic memory, optical memory, or the like. The terminal storage unit 22 stores various information and programs received from the server device 10 and used for service-related processing. Information and programs used for service-related processing may be acquired from an external device via the terminal communication unit 21 . For example, a game application may be acquired from a predetermined application distribution server.

The display unit 23 includes a display device such as a liquid crystal display or an organic EL (Electro-Luminescence) display. The display unit 23 can display various screens.

The input unit 24 includes an input interface including a touch panel provided integrally with the display unit 23, for example. The input unit 24 can accept user input to the terminal device 20 . Also, the input unit 24 may include physical keys, and may further include any input interface including a pointing device such as a mouse.

Terminal control unit 25 includes one or more processors. The terminal control unit 25 controls the operation of the terminal device 20 as a whole. An example of the operation of the terminal control unit 25 will be specifically described below.

The terminal control section 25 transmits and receives information via the terminal communication section 21 . For example, the terminal control unit 25 receives various information and programs used for service-related processing from at least one of the server device 10 and other external servers. The terminal control section 25 stores the received information and program in the terminal storage section 22 .

The terminal control unit 25 activates the site A, a game application in the site A, or the like according to the user's operation. The terminal control unit 25 cooperates with the server device 10 to execute processing related to services. For example, the terminal control unit 25 causes the display unit 23 to display various screens related to service-related processing. A GUI (Graphic User Interface) that detects user operations, for example, may be displayed on the screen. The terminal control unit 25 can detect user operations on the screen via the input unit 24 .

(Outline of the game app)
An overview of an example of a game application according to the present embodiment will be described. A game according to this embodiment includes one or more game parts. At least one game part of the one or more game parts may be performed using game media.

Game media are electronic data used in games, and include arbitrary media such as cards, items, points, virtual currency, tickets, characters, avatars, and parameters. Game media may also be game-related information such as level information, status information, parameter information (physical strength, attack power, etc.) or ability information (skills, abilities, spells, jobs, etc.). Game media are electronic data that can be acquired, owned, used, managed, exchanged, combined, enhanced, sold, discarded, or gifted by the user in the game. It is not limited to what is specified.

Hereinafter, unless otherwise specified, "game media owned by a user" refers to game media associated with a user ID that can uniquely identify the user as owned game media. Also, "providing game media to the user" indicates that the game media are associated with the user ID as possessed game media. Also, "destroy the game media owned by the user" indicates canceling the correspondence between the user ID and the owned game media. Also, "consuming game content owned by the user" indicates that some kind of effect or influence can be generated in the game according to the cancellation of the correspondence between the user ID and the owned game content. Also, "selling the game media owned by the user" means canceling the association between the user ID and the owned game media, and adding other game media (for example, virtual currency, items, etc.) to the user ID. Indicates that it is associated as a game medium. Also, "to transfer the game media owned by user A to user B" means that the correspondence between user A's user ID and owned game media is canceled and the user ID of user B owns the game media. Indicates that it is associated as a game medium. Also, "creating game content" indicates defining or determining at least part of information about game content.

A game part is content that a user can play in a game, and includes, for example, quests, missions, mini games, development, enhancement, and synthesis of game media, game media acquisition events, virtual space search events, and opponents ( For example, it includes battle events against other users, enemy characters, enemy buildings, etc.). One or more predetermined tasks (game tasks) may be set for each game part. For example, when it is determined that one or more game tasks set in the game part played by the user have been successfully achieved, the user may be rewarded with, for example, game media. The game tasks include, for example, a task of winning a match against an enemy character, a task of reaching a goal point in a virtual space, and a task that the user's character is in a predetermined state (for example, incapacitated state) until a predetermined time elapses. ) can be adopted according to the contents of the game part. Further, the achievement of a specific task (clear task) among one or more game tasks set for the game part is also called clearing of the game part. When the user who plays the game part succeeds in achieving the clear task, the game part may be determined to have been cleared and the game part may end.

The one or more game parts may include a single-play game part and a multi-play game part. The single-play game part may include, for example, a game part (for example, a single-player game part) that is executed based on a user operation on one terminal device 20 used by one user. For example, one terminal device 20 alone or one terminal device 20 and the server device 10 cooperate to execute a single-play game part. On the other hand, a game part for multiplay is, for example, a game part common to two or more users (for example, , multiplayer game parts). A game part common to two or more users is, for example, a game part in which at least part of the progress processing of the game part and at least part of the processing results are commonly applied to the two or more users. may include For example, two or more terminal devices 20 cooperate, or two or more terminal devices 20 and the server device 10 cooperate to execute a multi-play game part. One game part may support both single-play and multi-play.

The game according to the present embodiment includes, for example, a battle game part having elements of a side-scrolling action game and elements of a battle game in which the player battles against an opponent using game media. The user selects one or more game media to be used for the battle game part from the game media owned by the user (owned game media). Hereinafter, each game medium used in the battle game part will also be referred to as a first game medium. The one or more first game media are collectively called a deck or a team. The opponent is, for example, an automatically operated game medium such as an NPC (Non-Player Character), but is not limited to this. For example, an opponent may be a game medium operated by another user. The number of opponents may be arbitrarily determined in one battle game part.

An outline of the competitive game part according to the present embodiment will be outlined with reference to FIG. FIG. 2 shows an example of a play screen for explaining an overview of the competitive game part.

A user who uses the terminal device 20 to play a single-play battle game part operates, for example, a moving object 140 arranged in a virtual space to obtain a predetermined item while avoiding obstacles and the like. The moving object 140 corresponds to a predetermined game medium (second game medium). The second game content may include, for example, a motorcycle, an automobile, or a person running on the road surface 141 . In response to the acquisition of the item 142, the game media (first game media A1, B, C, D, E) included in the deck perform a predetermined action (for example, attack the opponent). The action of the first game content can cause damage to the opponent (in FIG. 2, an object 144 related to the opponent is displayed). On the other hand, the opponent performs a predetermined action (for example, attacking the user) at predetermined time intervals, for example. Damage may be given to the user (in FIG. 2, an object 143 relating to the user is displayed) due to the action of the opponent. The user and opponent each have predetermined parameters (total HP and HP) that are reduced by the amount of damage dealt. In FIG. 2, the image area 145 is an area for displaying the remaining total HP as a gauge, the image area 148 is an area for displaying the remaining HP of the opponent as a gauge, and the image area 149 is an area for displaying the remaining HP of the deck. This is an area indicating the state of each first game content included in the . When the relevant parameter of the opponent decreases to a predetermined value (eg, zero), it is determined that the user has won. On the other hand, when the user's parameter decreases to a predetermined value (eg, zero), it is determined that the user has lost. When it is determined that the user has won or lost, the competition game part may end.

On the other hand, the battle game part for multiplay is executed in the same manner as the above-described battle game part for single play, except that two or more users compete against a common opponent. Specifically, two or more users each use their own terminal devices 20 to play a common competitive game part. Each of the two or more users operates the second game content in the virtual space as described above. A common virtual space may be used for the two or more users, or an independent virtual space may be used for each user. The first game contents included in the decks of the two or more users each attack, for example, a common opponent. The aforementioned parameters of opponents are commonly applied to two or more users. For example, the parameters of the opponent may be synchronized between a plurality of terminal devices 20 used by two or more users. When the relevant parameter of the opponent decreases to a predetermined value (eg, zero), it is determined that two or more users win. On the other hand, when the parameter of each of two or more users decreases to a predetermined value (eg, zero), it is determined that the two or more users have lost. If it is determined that two or more users have won or lost, the competition game part may end.

The game described above is merely an example, and the present embodiment can be applied to fishing games, running games, dungeon games, Othello games, fighting games, city-building games, horse racing games, as well as general RPGs (Role Playing Games). It can also be applied to games, sports games such as baseball games, shooting games, and the like.

(Outline of the deferred payment function)
In this embodiment, the server device 10 further has a function of providing digital content to the user on the condition of post-payment via site A (hereinafter also referred to as a "post-payment function").

Here, digital content refers to various types of electronic data, such as viewable content such as music and videos, readable content such as e-books, playable content such as game applications, news and articles, and the like. including information content, etc. In this embodiment, digital content includes electronic data used at site A, and electronic data used at site A includes, for example, cards, items, points, virtual currency, tickets, characters, avatars, Includes arbitrary media such as parameters. Also, the electronic data used at site A includes game media used in game applications. The game media are as described above.

In this embodiment, as an example, the digital content provided by the deferred payment function is coins that can be used at site A (hereinafter referred to as "A coins"). Other digital content can be provided.

Here, the provision of digital content to one user refers to making the digital content available to the one user. It differs depending on the attributes of the digital content. For example, when the digital content is a predetermined number of A coins, the predetermined number may be added to the number of A coins associated with the user ID of the one user. Further, when the digital content is viewable content, the viewable content may be reproduced via the terminal device 20 associated with the user ID of the one user.

Next, with reference to FIGS. 3 and 4, the postpay function will be outlined.

FIG. 3 is a diagram showing an example of the display screen of the site A on the terminal device 20, and FIG. 4 is an explanatory diagram of the flow of deferred payment.

FIG. 3 shows a home screen (my page) G50 of site A. As shown in FIG. In the home screen G50, a button B50 related to the deferred payment function is set among the buttons B51 and the like that allow transition to the game corner. The button B50 is labeled with the words "Purchase with deferred payment", so that the user can easily understand that the A coin can be purchased with deferred payment. By operating the button B50, the user can switch from the site A home screen to an application screen (not shown) in which the number of A coins to be purchased by deferred payment can be specified. Note that, in a modification, the screen G50 may be a screen that can be transitioned from another home screen instead of the home screen.

Here, deferred payment, which has the usual meaning, is a payment settlement method in which the payment for the provision of digital content is postponed until after the provision of the digital content. In this embodiment, as an example, a user who uses the deferred payment function, after being provided with digital content, at a convenience store (hereinafter abbreviated as "convenience store"), a post office, an ATM (Automatic Teller Machine), etc. It is necessary to pay the price corresponding to the consideration.

In this embodiment, as an example, it is assumed that digital content that can be provided by deferred payment is A coin, and other digital content (digital content that requires payment of consideration) can be provided via A coin. . It should be noted that in the following description, the fact that the user receives the provision of the A coin is synonymous with the fact that the user purchases the A coin.

In the example shown in FIG. 4, if a certain month is N month, the user has purchased A coins three times from the first day of the N month to the last day of the N month (closing date). In this case, the payment due date is the last day of the next month (N+1 month), and the user pays the amount corresponding to the purchase of A coins three times during the payment period from the closing date to the payment due date. All you have to do is pay. In this case, the price corresponding to the three purchases of the A coin does not include interest or fees.

As described above, in the present embodiment, the service providing system 1 has the deferred payment function, so that the user's convenience can be enhanced. For example, even a user who does not have a credit card or the like can use the deferred payment function to receive A coins from the service providing system 1 . In addition, since the bill is combined into one bill for each month, the user does not need to pay each time (like a prepaid card). The payment corresponding to the purchase of the A coin can be completed, and the convenience is improved.

(details of postpay function)
Next, with reference to FIGS. 5 to 13, the details of the postpay function will be described.

FIG. 5 is a functional block diagram of functions related to the deferred payment function among various functions realized by the server device 10. As shown in FIG. FIG. 6 is an explanatory diagram of data in the user information database 50. As shown in FIG. In FIG. 6 (the same applies to FIGS. 7 to 11 described later), "***" means that some information is stored. FIG. 7 is an explanatory diagram of information about the game. FIG. 8 is an explanatory diagram of data in the log information database 52. As shown in FIG. FIG. 9 is an explanatory diagram of data in the index value database 54. As shown in FIG. FIG. 10 is an explanatory diagram of data in the billing information database 55. As shown in FIG. FIG. 11 is an explanatory diagram of data in the deferred payment information database 56. As shown in FIG. 12 and 13 are diagrams showing examples of output modes of prompting information.

The server device 10 cooperates with each terminal device 20 to implement various functions described below. As shown in FIG. 5, the server device 10 includes a user registration unit 30, a service providing unit 31, a log information storage unit 34, a log information acquisition unit 36, a determination unit 38, a billing information management unit 39, A reminder information output unit 40, an activity limit unit 42, an upper limit value setting unit 44, a user information database 50, a log information database 52, an index value database 54, a billing information database 55, and a deferred payment information database 56. include. The user registration unit 30 to the upper limit value setting unit 44 can be realized by the server communication unit 11 and the server control unit 13 described above, and the user information database 50 to the deferred payment information database 56 can be realized by the server storage unit 12 described above.

It should be noted that the distinction between the functional units from the user registration unit 30 to the upper limit value setting unit 44 is for convenience of explanation, and some or all of the functions of a specific functional unit (functions described below) may be may be implemented by a single functional unit of For example, part or all of the functions of the user registration unit 30 may be implemented by the content providing unit 313 . The same applies to the user information database 50 to the deferred payment information database 56, and part or all of the functions of one specific database (functions described below) may be realized by another database.

The user registration unit 30 registers user information related to users who use the site A in the user information database 50 .

As shown in FIG. 6, the user information is associated with a user ID (an example of user identification information), and includes a user name, password, phone number, SMS authentication result, owned coins, game information, SNS information, Including information related to digital content. User information may include, for example, initially registered information such as a user ID and user name, as well as post-accumulated information such as game-related information. Also, the user information does not have to include the user's real world information (age, income, address, etc.) other than the telephone number.

A user ID is information that can uniquely identify a user. Hereinafter, the user ID will be simply referred to as a user.

A user name is information indicating a user's name. A user name, unlike a user ID, may not uniquely identify a user. The user name may be arbitrarily determined and changed according to user operations on the terminal device 20 . Note that the user name is information that is initially registered, and may be essential information that should be registered.

The password is a password that enables login to site A using the user name. A plurality of types of passwords may be set according to usage. The password is information that is initially registered, and may be essential information that should be registered.

The phone number is the phone number for short message service (SMS) authentication. The telephone number is information to be registered initially, and may be essential information to be registered, or may be optional information.

The SMS authentication result indicates the result of SMS authentication using the registered phone number. In SMS authentication, a specific confirmation code is sent by SMS to a registered telephone number, and then authentication is realized depending on whether or not the confirmation code is entered. In FIG. 6, "O" indicates that SMS authentication was successful, and "X" indicates that SMS authentication was unsuccessful. Note that SMS authentication is performed only when a phone number is registered.

Possessed coins represent the number of A coins possessed (the number of currently usable A coins). It should be noted that the user can receive the provision of the A coin using the deferred payment function as described above. The initial value of owned coins is 0, for example. Possessed coins can be updated by the coin providing unit 3131, billing processing unit 314, billing information management unit 39, etc., as described later.

The game-related information may include, for each user ID, rank, owned game media information, used game media information, and friend information, as shown in FIG.

A rank is a parameter that indicates a user's proficiency level with respect to a game. In this embodiment, the rank value may increase as the user plays the game. The higher the rank, the higher the skill level of the user regarding the game.

The information about owned game media includes various information unique to the game media owned by the user in the game (owned game media). When game media are acquired by a user, the game media are associated with the user as owned game media. Although the details of the owned game media are omitted, each game media ID may include the game media name, rarity, level, cost, HP (HitPoint), attack power, resilience, and the like.

The information about the game media to be used is information indicating the game media (first game media) that the user is allowed to use in the battle game part. The first game media is selected from owned game media. In this embodiment, for example, up to five game media selected from one or more owned game media are associated with the user as first game media. Therefore, one game medium can be both the owned game medium and the first game medium. The first game content may be selected automatically or in response to a user operation, for example in a dedicated game part. For example, the dedicated game part may include a game part for so-called deck formation or team formation. A maximum of five first game media indicated in the information on the used game media constitutes one deck. The information on the game media used may include information on multiple decks.

Friend information represents user IDs that have a friend relationship in the game. For example, when user A is friends with users B and C, friend information associated with user A includes user IDs of users B and C. FIG. Note that a friend relationship is realized through a friend application or the like. Thus, friend information includes user IDs of other users who are unidirectionally or bidirectionally associated with the user. Note that users who are in a friend relationship may be able to communicate with each other, such as sending and receiving messages, during the game, for example. Note that the information about the user may include information indicating a group to which the user belongs (for example, a guild or party) instead of or in addition to the friend information.

In addition, the contents of the information about the game are not limited to those described above. For example, the information about the user may further include information indicating the predetermined points that the user has in the game. The points are consumed for the user to play the game part. The consumption amount of the points may differ for each game part. The points may increase, for example, according to the passage of time or according to the use of predetermined game media.

The information about SNS may include various types of information related to SNS functions. For example, the SNS-related information may include avatar-related information, friend information, and the like for each user ID. The information about the avatar may include clothing information for changing clothes, and the like. The friend information may represent user IDs and group IDs connected via the SNS function. The friend information may be the same as the friend information in the game, or may be different.

Information about digital content may include information for identifying digital content available to a user. The term “digital content available to the user” as used herein refers to digital content other than A coins, and may include one or more digital content provided by the user by consuming A coins. Information on digital content includes one or more game applications that can be played by the user (for example, one or more game applications provided by the user by consuming A coins, and/or other game applications). ).

The service providing unit 31 provides various services available to each user via the service platform.

Service providing unit 31 includes login managing unit 310 , game processing unit 311 , SNS function realizing unit 312 , content providing unit 313 , billing processing unit 314 , and digital content using unit 315 .

The login management unit 310 executes processing related to the site A service. Specifically, the login management unit 310 manages the login status of each user at the site A based on the user name, password, etc. in the user information database 50 . Basically, when the user name and password entered by the user match the user information in the user information database 50, the login management unit 310 permits login based on the user ID associated with the user name. However, in this embodiment, the login management unit 310 prohibits login to the site A for a user who is subject to the fourth level of restriction by the activity restriction unit 42 as described later.

The game processing unit 311 executes game processing related to game applications. At this time, the game processing unit 311 executes game processing using information about the game (see FIGS. 6 and 7). The aspect of the game realized by the game processing is as described above, but is arbitrary. After executing various game processes for one user, the game processing unit 311 appropriately updates the user information associated with the one user (information about the game in the user information shown in FIG. 6). In this embodiment, the game processing unit 311 prohibits the user who is subject to the third level of restriction by the activity restriction unit 42 from playing the game, as will be described later.

The SNS function implementation unit 312 executes the processing related to the SNS function described above. At this time, the SNS function implementation unit 312 uses the SNS-related information as shown in FIG. 6 to execute processing related to the SNS function. When the SNS function implementation unit 312 executes various SNS function-related processes for one user, the SNS function implementation unit 312 appropriately updates the user information associated with the one user (information about SNS in the user information shown in FIG. 6). .

The content providing unit 313 provides the digital content described above to the user via the site A. FIG. The content provider 313 includes a coin provider 3131 and a digital content provider 3132 .

The coin providing unit 3131 provides the user with a predetermined number N of A coins (an example of digital content) on the condition that the payment is made by the deferred payment function (payment for the amount of A coins provided) until the payment deadline date (an example of a predetermined deadline). offer. The value of each A coin may be fixed or variable. Assuming that the consideration for one A coin is, for example, β yen, the consideration for the predetermined number N of A coins is N×β yen. In this case, the coin providing unit 3131 provides the user with a predetermined number N of A coins on the condition that the user pays N×β yen by the payment deadline.

In the present embodiment, as an example, each user is provided with A coins any number of times (see FIG. 3) until the cumulative value of monthly consideration before payment reaches the upper limit value Nmax associated with the user. can receive That is, the coin providing unit 3131 provides A coins to the user in response to a request from the user until the monthly cumulative value of consideration before payment reaches the upper limit value Nmax associated with the user. . The monthly accumulated consideration before payment is a monthly accumulated consideration, which is the accumulated consideration of the provided A coins. In this case, the cumulative pre-payment value associated with one user is reset to "0" every month. The number of A coins that can be provided at one time may have an upper limit, or may be substantially unlimited. That is, the predetermined number N may be a predefined and fixed value, or may be selectable/adjustable by the user. In the latter case, the user can also receive the number of A coins corresponding to the upper limit value Nmax at one time.

However, in a modified example, each user receives A coins as many times as necessary (see FIG. 3) until the cumulative value of consideration before payment over the entire period reaches the upper limit value Nmax associated with the user. be able to. The cumulative value of consideration before payment over the entire period is not the cumulative value for each month, but the cumulative value over the entire period, which is the cumulative value of the received A coins. In this case, when the one user pays the price (full amount) corresponding to the cumulative value, the cumulative value is reset to "0".
In this embodiment, the payment due date is the same for each user, but it is not limited to this. For example, in a modification, the payment due date may be set in such a manner that the period until the payment due date varies depending on the credit information (for example, the maximum amount). In this case, a looser (longer) payment due date may be set for a user who is given higher credit.

In this embodiment, as an example, it is assumed that the consideration β per A coin fluctuates, and the upper limit value Nmax functions as an upper limit value for the consideration, but the present invention is not limited to this. For example, when the consideration β per A coin is fixed, equivalently, the upper limit value Nmax may be the upper limit value for the cumulative value of the number of A coins before payment of the consideration.

The upper limit value Nmax may be a fixed value that is constant for each user, but in this embodiment, as an example, it is set by the upper limit setting unit 44 for each user as described later. Note that, in the present embodiment, the coin providing unit 3131 determines the upper limit value Nmax (the upper limit value Nmax associated with the one user) obtained by referring to the deferred payment information database 56 for one user (see FIG. 11). and the billed amount obtained by referring to the billing information database 55 (the billed amount associated with the one user and equivalent to the cumulative value of consideration before payment) (see FIG. 10) , the maximum number of A coins that can be provided to the one user at this time can be grasped.

After providing a predetermined number N of A coins to one user, the coin providing unit 3131 updates the possessed coins (possessed coins in the user information shown in FIG. 6) associated with the one user. In this case, the coin providing unit 3131 adds a predetermined number N to the number of possessed coins associated with the one user.

The digital content providing unit 3132 provides various digital content other than A coins to the user on the condition that the A coins associated with the user are consumed (decrease in the number of A coins). Note that the amount of consumption of A coins may be associated with each digital content. That is, the consumption amount of A coins may be set according to the digital content in such a manner that the higher the value (consideration) of the provision of the digital content, the greater the consumption amount of A coins.

When digital content other than A coin is provided to one user, the digital content providing unit 3132 updates the possessed coin (possessed coin in the user information shown in FIG. 6) associated with the one user. In this case, the digital content providing unit 3132 subtracts the number of coins in possession associated with the one user by the number of A coins corresponding to the price of the provided digital content.

The billing processing unit 314 executes processing related to billing services. Specifically, when receiving a request for provision (purchase) of A coins from the user, the billing processing unit 314 provides the A coins to the user under predetermined conditions. Note that, unlike the coin providing unit 3131, the billing processing unit 314 provides the user with the A coin on the condition that the payment is made at that time, regardless of the deferred payment. Note that, in the present embodiment, the login management unit 310 prohibits the provision of charging services (that is, the acquisition of A coins) for users who are subject to the second level of restriction by the activity restriction unit 42 as will be described later. do.

The digital content utilization unit 315 executes processing related to digital content utilization services. Specifically, the digital content utilization unit 315 executes processing related to digital content other than processing related to A coin among the digital content that can be used via the service platform. For example, when the digital content usage unit 315 receives an e-book reading request from a certain user, it refers to the “information on digital content” in the user information (see FIG. 6) related to the one user, and It enables viewing of a requested e-book among one or more e-books linked to one user.

The log information accumulation unit 34 collects the log information of each user who uses the site A, and accumulates the log information in the log information database 52 for each user ID. The log information to be accumulated may be all log information or specific log information (for example, log information related to operation logs). The log information represents various activities (login, logout, use of digital content, access/use of SNS functions, billing, etc.) at site A based on each user ID. FIG. 8 shows an example of log information accumulated in the log information accumulation unit 34. As shown in FIG. In FIG. 8, for each user ID, information indicating operation date and time and information indicating operation details are accumulated as a set. Note that one set of such log information is generated for each operation. The log information accumulated in the log information database 52 may be raw data or processed data.

The log information acquisition unit 36 acquires (extracts) from the log information database 52 the log information related to the user to be judged by the judgment unit 38 . As described above, log information is accumulated in the log information database 52 in a form linked to the user ID. Note that the log information acquisition unit 36 may extract all of the log information associated with the user ID, or may extract a portion of the log information (for example, only the log information for a specific period).

Based on the log information acquired by the log information acquisition unit 36, the determination unit 38 determines whether or not the deferred payment function can be used for each user. That is, based on the log information associated with one user, the determining unit 38 determines whether or not the coin providing unit 3131 can provide the A coin to the user. The determination method by the determining unit 38 is arbitrary as long as the log information is used, but typically, the deferred payment function can be used for users who are likely to normally use the deferred payment function. is adapted to More specifically, the mode in which the user using the deferred payment function pays the price by the payment due date is defined as "normal use", and the user using the deferred payment function pays the price by the payment due date. "Abnormal use" is defined as a mode in which payment is delayed or stagnated without payment. When the mode to be triggered is "unrecoverable use", the determination method by the determination unit 38 is set so as to minimize the possibility of occurrence of "abnormal use" and/or "unrecoverable use". be adapted.

The determination method by the determination unit 38 may be based on a logic of inputting log information and outputting a binary value indicating whether or not the A coin is provided. In this specification, "inputting log information" is a concept that includes inputting a parameter (for example, an index value α described later) derived from the log information.

Alternatively, the determination method by the determination unit 38 may be implemented using artificial intelligence. In this case, it is also possible to input log information and output (generate) whether or not to provide A coins. In the case of artificial intelligence, it can be realized by implementing a convolutional neural network obtained by machine learning. In machine learning, for example, the weight of a convolutional neural network that minimizes the error may be learned using performance data related to log information of many users. Note that the error referred to here is based on the log information related to the user who performed "abnormal use" and/or "unrecoverable use", and outputs a value indicating that the provision of A coins is "possible". and outputting a value representing "impossible" to provide A coins based on the log information related to the user who performed "normal use".

Note that the determination unit 38 may calculate an index value representing the possibility that “normal use” can be expected when determining whether or not the A coin can be provided using binary values. At this time, the index values related to the one user are the degree of activity of the one user on site A, the activity period, the assets cultivated by the one user on site A (friends connected by SNS function, game media , game ability, etc.). In this case, the determination unit 38 may calculate the index value for each user, and determine that the provision of A coins is “allowed” for a user whose index value exceeds a predetermined threshold.

In this embodiment, the determination unit 38 calculates a plurality of index values α for each user and for each activity at the site A, as an example. The plurality of index values α are, for example, a first index value relating to the login status, a second index value relating to the billing status, a third index value relating to the SNS usage status, and a fourth index relating to the game play status. including values. Each index value α may be calculated in any manner as long as it represents various situations. After calculating the plurality of index values α, the determination unit 38 stores (updates) the plurality of index values α in the index value database 54 as shown in FIG. 9 . Note that the timing of calculating (updating) the plurality of index values α is arbitrary, and the plurality of index values α may be calculated regularly and/or irregularly. Further, the calculation (updating) timings of the plurality of index values α may be simultaneous, or may be different for each index value.

In this case, the determination unit 38 receives a plurality of index values α and determines whether or not the deferred payment function can be used for each user. The determination unit 38 updates part of the data in the deferred payment information database 56 (“possibility of deferred payment” in FIG. 11) according to the determination result. In FIG. 11, the user for whom the determination result by the determination unit 38 is "possible to use the deferred payment function" ("possible to use the deferred payment function") is represented by "o", and the determination result by the determination unit 38 is "can use the deferred payment function". Users who are "unable to pay later" ("cannot pay later") are indicated by "x".

In addition to the log information, the determination unit 38 may supplementarily use other predetermined information to determine whether or not the deferred payment function can be used for each user. Other predetermined information may include the user's real-world information (age, income, address, etc.), but preferably does not include the user's real-world information. Other predetermined information may be, for example, the SMS authentication result (see FIG. 6). In this case, the determination method by the determining unit 38 is such that it is more likely that a user whose SMS authentication is successful is determined to be able to use the deferred payment function than a user whose SMS authentication is unsuccessful. , may be configured. Alternatively, the determination unit 38 may extract users who can use the deferred payment function from among the users whose SMS authentication has been successful.

The billing information management unit 39 manages billing information for users who use the deferred payment function. The billing information management unit 39 generates billing information related to the deferred payment function, stores it in the billing information database 55, and updates the billing information in the billing information database 55. FIG. In the example shown in FIG. 10, the billing information database 55 stores information such as user ID, payment number, billing amount, closing date/payment due date, output necessity flag, and payment status category for each bill ID. held. Only one invoice ID is issued (generated) for each user ID every month. However, a bill ID need not be issued to users who do not use the deferred payment function.

A payment number is a number that enables payment by entering the same number at a convenience store, post office, or the like. The output necessity flag indicates whether or not the bill information (confirmed bill information) should be output to the corresponding user, and "0" indicates that the bill information should not be output. , "1" indicates that billing information should be output.

The payment status category is a payment status category that indicates the payment status. In this embodiment, "A" indicates that the payment has been completed, and "B0" to "B4" indicate that the payment has not been completed. ing. The payment status categories "B0" to "B4" change according to the degree of delay with respect to the payment due date (the length of unpaid time ΔT1, which will be described later), and will be described later. The initial value of the payment status category (that is, the value at the time the invoice ID is issued) may be "no classification". In this case, for example, when the billing information management unit 39 acquires a payment notice associated with one payment number (for example, when it is obtained from a convenience store or the like), the billing information management unit 39 The billing information is updated by rewriting the payment status category related to the bill ID obtained to "A".

The billing information management unit 39 adds up the billed amount by the consideration for the amount provided each time the user uses the deferred payment function and receives coins from the coin providing unit 3131 (that is, the cumulative value of the consideration before payment is added up). Update). Then, when the closing date arrives, the billing information management unit 39 generates billing information (billing information related to payment for the current month) requesting payment of the current billed amount (lump-sum payment). In this way, in this embodiment, when the closing date arrives, bill information is determined for each bill ID.

The billing information management unit 39 outputs the billing information related to the payment for the current month (confirmed billing information for the current month) after the closing date (see FIG. 4) for the user using the deferred payment function. The method of outputting the invoice information is arbitrary, and the invoice information may be output on site A where the user is logged in, or the invoice information may be sent to the user's email address (if registered). may be sent. In this case, the billing information output may preferably include a transition button or link to a payment screen (not shown). In this case, the user can easily prepare for payment in response to the output of bill information. The payment screen may be a screen that describes a payment number and payment method. When the billing information management unit 39 outputs the billing information (confirmed billing information for the current month) related to one billing ID to the user associated with the billing ID, the billing information management unit 39 The output necessity flag (see FIG. 10) associated with the ID is set to "0". The initial value of the output necessity flag (that is, the value at the time the bill ID is issued) is "0", and is set to "1" after the closing date.

The prompting information output unit 40 provides prompting information for urging the corresponding user to pay the consideration for the A coin if the consideration for the provided A coin has not been paid by the payment deadline date (an example of the predetermined deadline). to output That is, when the consideration for the A coin provided to a certain user is not paid by the payment deadline, the prompting information output unit 40 outputs prompting information to the user. Hereinafter, a user who has not paid for the provided A-coin even after the payment deadline is referred to as an "unpaid user".

Any method of outputting the reminder information may be used as long as it conveys to the unpaid user that the payment for the provided A coin has not been made. For example, the prompting information output method may be implemented via the terminal device 20 of the non-paying user. In this case, the prompting information output unit 40 may output the prompting information via the site A logged in by the unpaid user. The output of reminder information via site A is, for example, outputting a message to the home screen of site A (see FIG. 12), outputting a message of reminder information as a chat, or sending an alert notification related to the SNS function. It may be realized by outputting the prompting information by using it, by outputting a message of the prompting information on the game screen (see FIG. 13), or the like. FIG. 12 shows a home screen G51 on which a message M1 "Payment deadline for deferred payment has passed" is output as reminder information. FIG. 13 also shows a game screen G52 on which a message M2 "Deferred payment has expired" is output as prompting information.

Further, the prompting information output unit 40 may output the prompting information by sending a short message to the telephone number corresponding to the unpaid user. Further, the prompting information output unit 40 may output the prompting information by calling the telephone number corresponding to the user who has not paid and by playing an automatic voice of the prompting information. Further, the prompting information output unit 40 may output the prompting information by sending an e-mail to the user's e-mail address (if registered). Further, the prompting information output unit 40 may output prompting information when an operator (person) makes a call from a call center or the like to a telephone number corresponding to an unpaid user. In this way, there are various output means (means for transmitting reminder information) for outputting reminder information to unpaid users using telephone numbers corresponding to unpaid users (one element of user information in FIG. 6). It is also possible to combine a plurality of

The output of reminder information may preferably include a transition button or link to a screen for payment (not shown), similar to the output of bill information. In this case, the unpaid user can easily prepare for payment in response to the output of the reminder information. The payment screen may be a screen that describes a payment number and payment method. For example, a message of reminder information such as message M1 shown in FIG. 12 and message M2 shown in FIG. 13 may function as a transition button to a payment screen (not shown).

The prompting information output unit 40 preferably changes the output mode of the prompting information according to the elapsed time (hereinafter also referred to as "unpaid time ΔT1") from the payment due date (an example of the predetermined first timing). In this embodiment, as an example, the unpaid time ΔT1 is counted from 0:00 am on the due date of payment. The unpaid time ΔT1 may be calculated in units of hours, or may be calculated in relatively long units such as days, weeks, and months.

Here, "changing the output mode of the prompting information" is a concept including changing the output method of the prompting information, and changing the level of alerting even though the method of outputting the prompting information is the same.

For example, the reminder information output unit 40 may change the contents of the messages M1 and M2 (see FIGS. 12 and 13) so that the longer the unpaid time ΔT1, the higher the degree of attention. The content of the messages M1 and M2 (see FIGS. 12 and 13) may include the content of the action (penalty) in case the payment is still not executed (that is, the content of the restriction by the activity restriction unit 42, which will be described later).

Further, the prompting information output unit 40 may change the output positions of the messages M1 and M2 (see FIGS. 12 and 13) so that the longer the unpaid time ΔT1, the higher the degree of attention. For example, the message M2 (see FIG. 13) may be output at a position where the longer the unpaid time ΔT1 is, the more the game play is hindered. Also, the message M2 (see FIG. 13) may be expanded to a larger size such that the longer the unpaid time ΔT1 is, the more the game play is hindered. Also, the messages M1 and M2 (see FIGS. 12 and 13) may be accompanied by motion such as blinking, popping up, or moving on the screen to increase the level of alertness.

Further, the prompting information output unit 40 may change the color, brightness, etc. of the messages M1 and M2 (see FIGS. 12 and 13) so that the longer the unpaid time ΔT1, the higher the degree of attention.

Further, the prompting information may be enhanced in the degree of alerting by using the functions provided in the terminal device 20 . For example, if the terminal device 20 has a vibration function, vibration may be generated in the terminal device 20 when the prompting information is output.

In this embodiment, as an example, when the unpaid time ΔT1 exceeds 0 (an example of the first predetermined time), the prompting information output unit 40 outputs the prompting information via the site A logged in by the unpaid user ( 12 and 13), when the unpaid time ΔT1 exceeds a predetermined time Th1 (an example of a second predetermined time), a short message is sent to the telephone number corresponding to the unpaid user. The short message may include the same content as the message M1 (see FIG. 12). The predetermined time Th1 is any time significantly longer than 0, but may be on the order of weeks or months, for example. Moreover, although the predetermined time Th1 is the same for each user, it is not limited to this. For example, in a modified example, the predetermined time Th1 may be changed according to credit information related to each user (such as information calculated based on unpaid balance and maximum amount information), deferred payment information described below, and the like. For example, when using deferred payment information, a relatively long predetermined time Th1 is set for a user who has a sufficient track record (number of times) of using the deferred payment function and has no delay history (thus, a user whose average delay days is 0), A relatively short predetermined time Th1 may be set for a user with an insufficient usage history (number of times) and a delay history (thus, a user with an average number of delay days greater than 0).

In the case of outputting the prompting information via the site A, if the unpaid user is logged in to the site A when the unpaid time ΔT1 exceeds 0, the prompting information output unit 40 outputs the prompting information from that point. can be output. On the other hand, if the unpaid user has not logged in to site A when the unpaid time ΔT1 exceeds 0, the prompting information output unit 40 outputs prompting information when the unpaid user logs in to site A thereafter. you can

When the unpaid time ΔT1 exceeds 0, the prompting information output unit 40 may continue outputting the prompting information to the site A until payment is made. In this case, when the unpaid time ΔT1 further exceeds the predetermined time Th1, the prompting information output unit 40 outputs the prompting information via the site A where the unpaid user is logged in, and short-circuits the telephone number corresponding to the unpaid user. will send a message. In this case, the message related to the reminder information output via the site A may be changed so that the longer the non-payment time ΔT1 is, the higher the alerting degree becomes, as described above.

The prompting information output unit 40 immediately stops outputting the prompting information when the unpaid user pays for the provided A coin (that is, when the unpaid amount is cleared) and the payment is confirmed. you can

The activity restriction unit 42 restricts activities at site A based on the user ID of the unpaid user (hereinafter simply referred to as "site (also referred to as “activity by non-paying users in A”). Hereinafter, the restriction processing executed by the activity restriction unit 42 is also simply referred to as "activity restriction processing". Activities at site A based on the user ID are arbitrary, but include, for example, login, logout, use of digital content, access/use of SNS functions, billing, etc., as described above. Of the various activities at Site A, the activities to be restricted by the activity restriction unit 42 may be part (that is, some of the various services that can be used via the service platform) or all (that is, service platform itself). In addition, among the various activities at site A, the activity to be restricted by the activity restriction unit 42 may be the same as the activity related to the log information accumulated in the log information database 52, or may be partially different. OK, everything can be different.

Here, the use of digital content that can be restricted by the activity restriction unit 42 may include not only the use of digital content provided by paying A coins, but also the use of other digital content that can be used free of charge. . The manner in which the digital content is used differs depending on the attributes of the digital content. For example, when the digital content is a moving image or an electronic book, the use of the digital content means browsing of the digital content. Moreover, when the digital content is a game application, the use of the digital content means playing the game.

The activity restriction unit 42 preferably changes the mode of restriction on the activity of the non-payment user at the site A according to the elapsed time (unpaid time ΔT1) from the payment due date (an example of the predetermined second timing). Note that, in the present embodiment, as an example, the activity restriction unit 42, similar to the prompting information output unit 40 described above, restricts the activity of the unpaid user at the site A based on the elapsed time from the payment due date (unpaid time ΔT1). Although the mode of restriction is changed, it is not limited to this. For example, unlike the reminder information output unit 40 described above, the activity restriction unit 42 restricts the activities of the non-paying user at the site A according to the elapsed time from the closing date (another example of the predetermined second timing). You can change it. The same applies to the reminder information output unit 40, and the elapsed time from another reference date may be used. In either case, the concept is the same, and substantially equivalent configurations can be realized.

The method of restricting activities by unpaid users on site A is arbitrary, but for example, restricting login time, restricting new acquisition of A coins, restricting access/use frequency to SNS functions. , restricting the frequency of playing the game, restricting the upper limit of billing, prohibiting the use of the deferred payment function, restricting the use of A coins currently possessed, and the like.

Also, the method of restricting activities by non-paying users at Site A may differ depending on the attributes of the non-paying users. For example, if the frequency of game play by a certain non-paying user is significantly higher than the frequency of use of the SNS function, the method of restricting the activity of the one non-paying user is such that the degree of restriction related to game play is It may be a mode in which the degree of restriction is higher than the degree of restriction according to
Also, the restriction method may be changed according to the credit information of each user (unpaid amount and information calculated based on information on the upper limit of the amount, etc.), deferred payment information described later, and the like. In this case, it is possible to flexibly control the amount of processing for ensuring the normal operation of the deferred payment function, and reduce the control load on the server device 10 . For example, when using deferred payment information, a user who has a sufficient track record (number of times) of using the deferred payment function and has no delay history (thus, a user whose average number of delay days is 0) will have a relatively late timing for the restriction to be activated. , and for users with insufficient usage records (number of times) and delay history (thus users with average delay days greater than 0), the timing of the restriction is set to be activated relatively early. may be

Here, changing the mode of restricting activities by unpaid users at site A means changing the method of restricting activities by unpaid users at site A, while the method of restricting activities by unpaid users at site A is the same. This is a concept that includes changing the degree of restriction.

Specifically, the activity restriction unit 42 may change the mode of restriction on the activity of the unpaid user at the site A such that the longer the unpaid time ΔT1, the higher the restriction level. For example, if the method of restricting activities by unpaid users at site A is to limit the upper limit of charges, the activity limiter 42 may lower the upper limit of charges as the unpaid time ΔT1 increases. In this case, the activity limiter 42 may eventually lower the upper limit of the charge to 0 and prohibit the charge.

In this embodiment, as an example, the activity restriction unit 42 changes the mode of restricting the activity of the unpaid user at the site A in four stages according to the unpaid time ΔT1. In addition, in a modification, 2 steps, 3 steps, or 5 steps or more may be used.

Specifically, as the first stage, the activity restriction unit 42 determines that the unpaid time ΔT1 exceeds the time (an example of the third predetermined time) until the last day of the month following the payment due date (that is, the next payment due date). , to stop the postpay function. Therefore, in this case, only two months worth of claims (unpaid claims) are accumulated.

As a second stage, the activity restriction unit 42, when the unpaid time ΔT1 exceeds the last day of the month following the payment due date (i.e., the next payment due date) + 10 days (another example of the third predetermined time), Stop using A coin acquisition means (acquisition means other than the postpay function). Note that means for acquiring A coins may include a method of acquiring A coins using a prepaid card service, a method of acquiring A coins as rewards for answering questionnaires, and the like. As a result, non-paying users who are subject to the second level of restriction are substantially unable to play the game by charging. However, non-paying users who are subject to the second stage restriction can still play the game without paying. Note that, in the modified example, the activity restriction unit 42, when the time (another example of the third predetermined time) of the last day of the month following the payment due date (that is, the next payment due date) + 10 days has passed, may restrict the use of some of the various services available through

As a third step, the activity restriction unit 42 determines that the unpaid time ΔT1 exceeds the time (another example of the third predetermined time) until the last day of the month after the month following the payment due date (that is, the next next payment due date). and prohibit playing the game. In other words, non-paying users who are subject to the third level of restriction are not allowed to play games without charging, in addition to playing games with charging. In the modified example, the activity restriction unit 42 limits the unpaid time ΔT1 to the last day of the month two months after the payment due date (that is, the next payment due date) (still another example of the fourth predetermined time). When exceeded, usage of all of the various services available through the service platform may be restricted. In this case, the non-paying user can use the service platform itself, but cannot use any service through the service platform. However, in this case, a state in which the unpaid user can view the prompting information (that is, the prompting information output unit 40 outputs the prompting information to the unpaid user) may be maintained.

As a fourth stage, the activity restriction unit 42 determines that the unpaid time ΔT1 is the time from the payment due date to the last day of four months (that is, the next payment due date) (an example of a fifth predetermined time). If you exceed it, your account will be suspended. In other words, the activity restriction unit 42 prohibits all activities by non-paying users at site A. FIG. As a result, non-paying users who are subject to the fourth level of restrictions will not be able to log in (login on site A) based on the user ID they have been using until now, and the game media etc. linked to the user ID will be effectively lost. will be frozen (deleted) to In other words, the non-paying user who is subject to the fourth level restriction cannot use the service platform itself realized by the server device 10 (use based on the corresponding user ID).

The activity restriction unit 42 partially or fully cancels the restriction immediately or after a certain period of time when the unpaid user pays for the provided A coin (that is, when the unpaid amount is canceled). you can In this embodiment, as an example, the activity restriction unit 42 unconditionally imposes all restrictions when an unpaid user who is subject to up to the third level of restriction pays for the provided A coin. To release.

On the other hand, the activity restriction unit 42 does not unconditionally completely release the restriction for the unpaid user who has reached the fourth level of restriction, even if the consideration for the provided A coin is paid. In this case, the administrator or the like of the service providing system 1 individually determines whether or not to lift the restriction on the unpaid users who have reached the fourth level of restriction (that is, whether or not to revive the suspended account). . When the manager or the like determines that the restriction on the unpaid user who has reached the fourth level of restriction is lifted, the activity restriction unit 42 receives an input to that effect from the manager or the like, and partially or fully restricts the restriction. can be removed automatically.

The upper limit value setting unit 44 sets the upper limit value Nmax (the upper limit value of the number of A coins that can be provided by the coin providing unit 3131) for each user based on the log information associated with the user. That is, the upper limit value setting unit 44 sets the upper limit value Nmax for one user based on the log information associated with the user. After calculating the upper limit Nmax for each user, the upper limit setting unit 44 updates (sets) the upper limit for each user (see FIG. 11) stored in the deferred payment information database 56 . Note that the upper limit value Nmax may be updated (reviewed) periodically or irregularly for each user.

The method of setting the upper limit value Nmax by the upper limit value setting unit 44 is arbitrary as long as the log information is used. The value Nmax is adapted to be high. More specifically, the method of setting the upper limit value Nmax by the upper limit setting unit 44 is adapted so as to minimize the possibility of occurrence of "abnormal use" and/or "unrecoverable use". The log information used for setting the upper limit value Nmax may be the same as or different from the log information used for determination by the determining unit 38 described above. Further, when the upper limit value Nmax is set as a binary value such as "high" or "low", the logic used in setting the upper limit value Nmax is the same as the logic used in the determination by the determination unit 38 described above. They may be the same or different.

A method of setting the upper limit value Nmax by the upper limit value setting unit 44 may be based on a logic of inputting log information and outputting a candidate value for the upper limit value Nmax. Alternatively, the method of setting the upper limit Nmax by the upper limit setting unit 44 may be realized using artificial intelligence. In this case, it is also possible to input log information and output (generate) a candidate value for the upper limit value Nmax (for example, one category out of three categories). In the case of artificial intelligence, it can be realized by implementing a convolutional neural network obtained by machine learning. In machine learning, for example, using performance data related to log information of a large number of users, the frequency of calculation of candidate values for the upper limit value Nmax that causes "abnormal use" and/or "unrecoverable use" is minimized. Weights and the like of the convolutional neural network may be learned such that

In the present embodiment, as an example, the upper limit value setting unit 44 calculates a candidate value for the upper limit value Nmax for each user based on the plurality of index values α derived for each user, and the calculated upper limit value An upper limit value Nmax is set based on the candidate value of Nmax. In this case, the candidate value for the upper limit value Nmax may be equal to the upper limit value Nmax. If the candidate value for the upper limit value Nmax includes a fraction, the upper limit value Nmax is set by rounding down the fraction. good too.

Specifically, the upper limit value setting unit 44 appropriately weights each index value α based on a plurality of index values α in the index value database 54 shown in FIG. Calculate candidate values. In this case as well, the weighting may be adapted by learning or the like so as to minimize the frequency of calculation of candidate values for the upper limit value Nmax that cause "abnormal use" and/or "unrecoverable use". .

Here, the upper limit value setting unit 44 sets the upper limit value Nmax for each user by using information regarding the status of postpayment for each user (hereinafter also referred to as “postpayment information”) in addition to or instead of the log information. may By using the deferred payment information, it is possible to increase the possibility of setting an appropriate upper limit value Nmax for each user. The appropriate upper limit value Nmax corresponds to the maximum value or a value close thereto within a range that does not cause "abnormal use" and/or "unrecoverable use".

In this case, the upper limit setting unit 44 may use the data in the deferred payment information database 56 (see FIG. 11) to set the upper limit Nmax for each user. In the example shown in FIG. 11, the deferred payment information database 56 stores, for each user ID, whether deferred payment is possible (determination result by the determination unit 38 described above), upper limit value (upper limit value Nmax), usage record (number of times), delay history, and The average days of delay are stored. The usage history (number of times) indicates the usage history of the deferred payment function, and the delay history indicates the presence and frequency of payment delays (if payment is not made by the payment deadline) when using the deferred payment function. and the average days of delay represents the average number of days of delay. In this case, the deferred payment information is the usage history (number of times), the delay history, and the average delay days. In the postpayment information database 56, as other postpayment information, information is stored such as whether or not the activity restriction unit 42 has imposed a restriction, how many of the four levels of restriction have been applied, and the like. good too.

When such deferred payment information is used, for example, a relatively high candidate value for the upper limit value Nmax is given to a user who has a sufficient usage record (number of times) and no delay history (thus, a user whose average number of delay days is 0). A relatively low candidate value for the upper limit value Nmax may be calculated for a user with an insufficient track record (number of times) and a delay history (thus, a user with an average number of delay days greater than 0). By using the deferred payment information in this way, it is possible to further increase the possibility of setting an appropriate upper limit value Nmax for each user.

User information (see FIG. 6) is stored in the user information database 50 as described above. The user information in the user information database 50 is appropriately updated as described above.

As described above, the log information database 52 stores log information (see FIG. 8) for each user. The log information in the log information database 52 is updated from time to time as described above. The log information in the log information database 52 may be discarded or transferred to another database after a relatively long predetermined period of time has passed since it was stored.

The index value database 54 stores each index value α (calculation result) (see FIG. 9) as described above. Each index value α is appropriately updated during determination processing by the determination unit 38 .

The billing information database 55 stores the billing information (see FIG. 10) as described above. The billing information in the billing information database 55 is stored in an extractable form for each bill ID. Among the billing information in the billing information database 55, information related to the bill ID associated with the payment status category "A" is discarded after a predetermined period of time has passed since the payment status category became "A". or be transferred to another database.

As described above, the deferred payment information database 56 stores various types of information including deferred payment information and related to the deferred payment function (see FIG. 11). The information in the deferred payment information database 56 is appropriately updated by the determination unit 38, the upper limit value setting unit 44, and the like.

By the way, in the present embodiment, as described above, the user information (see FIG. 6) in the user information database 50 does not contain the user's real-world information (age, income, address, etc.). However, its authenticity is not questioned (for example, its authenticity is not verified by an identification card, etc.). Therefore, unlike the credit provided by financial institutions, credit card companies, etc., it is difficult to provide highly reliable credit based on the user information in the user information database 50 .

Also, in a site that handles digital content (for example, site A), the user's real world information (age, income, address, etc.) is not important from the viewpoint of enjoying the digital content. It is a burden for the user to require input to the . In particular, users who only enjoy digital content such as videos and games are likely to feel uncomfortable if they are required to input accurate information about the real world. This is the same for users who want to enjoy not only the enjoyment of digital content but also the convenience of the postpayment function. It is better from the viewpoint of user-friendliness to enjoy the convenience of

Moreover, even if users are forced to enter real-world information (age, income, address, etc.) on sites that handle digital content, they cannot be expected to enter accurate information. This is because even if the digital content is purchased, the digital content is not sent to a real-world address. This is in contrast to EC (Electronic Commerce) sites dealing with clothing, furniture, etc. where accurate entry of a real-world address is important to the user.

In this regard, according to the present embodiment, as described above, whether or not a certain user can use the postpay function is determined based on the log information of the user. Therefore, according to the present embodiment, each user is not forced to input accurate real-world information (age, income, address, etc.), but the user's log information is used to determine whether or not the deferred payment function can be used. can judge. As a result, according to the present embodiment, it is possible to provide A coins (and other digital contents associated therewith) on the condition of deferred payment in a highly convenient manner that reduces the burden on the user.
Further, in this embodiment, as described above, in addition to the determination unit 38, the upper limit value setting unit 44 is provided. can be determined. This makes it possible to evaluate the usability of the deferred payment function for each user from multiple perspectives (that is, to flexibly evaluate the characteristics of each user), making it easier for a wide range of users to use the deferred payment function, and ensuring the normal operation of the deferred payment function. It can be easily secured. In addition, since the upper limit value setting unit 44 sets the upper limit value Nmax only for users who are determined to be able to use the deferred payment function by the determination unit 38 among all users, The processing load on the server device 10 can be reduced as compared with the case of performing complicated processing such as determining whether the postpaid function can be used and setting the upper limit at the same time.

In addition, in the present embodiment, as described above, the activity restriction unit 42 is provided. usage pattern) can be expected with high probability (that is, a relatively high collection rate of receivables can be expected). This is because the restrictions imposed by the activity restriction unit 42 include account suspension, as described above. Suspension of an account is a penalty that users who enjoy site A most want to avoid. This is because once the account is suspended, all previous activity will be for naught. In particular, users who frequently use site A or users who have used site A for a long period of time tend to have large amounts of assets cultivated on site A (friends connected via SNS functions, game media, etc.), and the actual damage caused by account suspension tends to be large. There is In addition, users who own e-books and the like tend to suffer substantial damage due to account suspension as the number and types of digital content such as e-books they own increase. Accordingly, such users can be expected to be more likely to use the Postpaid feature in ways other than "irrecoverable use" to avoid account suspension.

Further, in the present embodiment, as described above, the activity restriction unit 42 gradually restricts the activity of the unpaid user at the site A according to the unpaid time ΔT1. There is no risk of immediate account suspension due to non-payment), and it is possible to realize a deferred payment function that is easy to use.

Further, in this embodiment, as described above, the reminder information output unit 40 is provided, so that the possibility of the user unintentionally receiving the final disposition (fourth-level restriction) of suspending the account can be reduced.

In particular, in the present embodiment, the prompting information output unit 40 outputs the prompting information via the site A, so that the prompting information can be output in a manner that is easy for users using the site A to understand. A user who uses the deferred payment function may use the site A relatively frequently, which can effectively increase the chances of coming into contact with the reminder information. In other words, it is possible to make it easier for the determining unit 38 to determine that the deferred payment function can be used for users who use the site A relatively frequently. payment (deferred payment) can be expected with a high degree of certainty.

Further, in the present embodiment, as described above, the prompting information output unit 40 changes the level of attention of the prompting information according to the unpaid time ΔT1. It is possible to output the prompting information in a relatively less annoying mode, and to output the prompting information in a relatively more annoying mode so as to strongly urge payment for a user with a relatively long unpaid time ΔT1. becomes possible. As a result, the convenience of the reminder information (convenience as a notification function for users who have unintentionally delayed payment) can be enhanced, while ensuring the original function of the reminder information (function of prompting unpaid users to pay).

In particular, in this embodiment, when the unpaid time ΔT1 becomes relatively long, the prompting information output unit 40 outputs the prompting information in a form of sending a short message to the unpaid user. function to prompt payment). This is because the prompting information transmitted by a short message tends to be more effective than the prompting information output in other modes. In the case of a short message, unlike the notification via site A, the user does not have to display the screen related to site A on the terminal device 20 (activation of site A, login to site A, etc.). ), users can be notified when viewing short messages, which they tend to do on a daily basis. In addition, since the short message is a notification method linked to information (telephone number) that is difficult to change, highly effective notification (reminder) can be realized.

(Operation example of service providing system)
Next, an operation example of the server device 10 will be described with reference to FIGS. 14 to 22. FIG. Note that the operation example described below is merely an example, and various modifications are possible.

14 to 22 are schematic flow charts showing examples of operations of the server device 10 related to the postpay function.

FIG. 14 is a schematic flow chart showing an operation example related to determination of availability of the deferred payment function. The processing illustrated in FIG. 14 may be performed periodically (for example, once a month).

In step S1402, the server device 10 extracts a plurality of users to be determined from among all users (all registered user IDs). The user to be judged is arbitrary, but may be a user who has accumulated more than a certain amount of log information since the previous judgment, or a user who has passed a predetermined period since the previous judgment. .

In step S1404, the server device 10 selects one user from among the users extracted in step S1402.

In step S<b>1406 , the server apparatus 10 extracts log information related to the selected user from the log information database 52 .

In step S1408, the server device 10 determines whether or not the deferred payment function is available for the one selected user based on the log information extracted in step S1406. Note that the determination method is as described above. Here, as an example, the determination method involves calculation of the index value α described above.

In step S1410, the server device 10 calculates the upper limit value Nmax for the deferred payment function for the one selected user based on the log information extracted in step S1406. The calculation method (setting method) of the upper limit value Nmax is as described above. If the past payment status of the selected user is taken into account in the calculation of the upper limit value Nmax, as described above, the deferred payment information associated with the selected user ("Usage record" in FIG. 11, etc.) ) may be used.

In step S1412, the server device 10 updates the information in the database associated with the one selected user based on the determination result in step S1408 and the calculation result in step S1410. Specifically, the server device 10 updates the “possibility of deferred payment” and the “upper limit” in the deferred payment information database 56 and each index value α in the index value database 54 .

In step S1414, the server device 10 determines whether or not all the users extracted in step S1402 have been selected. If the determination result is "YES", the process ends. Otherwise, the process returns to step S1406 via step S1416.

In step S1416, the server device 10 newly selects one unselected user from among the users extracted in step S1402. In this case, the processing from step S1406 to step S1412 is executed for the newly selected user.

In this manner, according to the process shown in FIG. 14, it is possible to determine whether or not the deferred payment function can be used based on the log information for each user, and set the upper limit value Nmax based on the log information.

FIG. 15 is a schematic flow chart showing an operation example related to a scene in which the user uses the deferred payment function. The processing shown in FIG. 15 may be repeatedly executed, for example, at predetermined intervals.

In step S1502, the server device 10 determines whether or not a request for providing A coins using the deferred payment function has been received from an arbitrary user (user logged in to site A). Note that the request for provision of A coins may be generated, for example, on an application screen (not shown) that the user advances by operating the button B50 shown in FIG. The request for provision of A coins may include information on the number of A coins to be provided. If the determination result is "YES", the process advances to step S1504; otherwise, the process for this cycle ends.

Here, as an example, it is assumed that the button B50 shown in FIG. 3 is displayed in an operable mode on the site A for all users. However, in a modified example, the button B50 shown in FIG. 3 may be displayed in an operable manner only on the site A associated with the user who can use the deferred payment function. Further, in this modification, the number of A coins that can be applied for by a certain user may be a number that does not exceed the upper limit value Nmax associated with the user. In this case, steps S1504, S1506, and S1516, which will be described later, are unnecessary.

In step S1504, the server apparatus 10 retrieves information associated with the user (hereinafter referred to as "requesting user") related to the provision request received in step S1502, which is stored in the deferred payment information database 56 as "possibility of deferred payment". ” and “upper limit”, and “billing amount (cumulative value of consideration before payment at present)” in the billing information database 55 are extracted.

In step S1506, the server apparatus 10 determines whether or not it is possible to provide the requesting user with the number of A coins requested, based on the information extracted in step S1504. do. That is, the server device 10 determines whether or not it is possible to respond to the provision request. Specifically, the server device 10 determines that the requesting user is a user who can use the deferred payment function, and that the number of A coins related to the provision request is equal to the upper limit value Nmax associated with the requesting user. , and the billed amount associated with the same user (accumulated value of consideration before payment at present), it is determined that the provision request can be met. If the determination result is "YES", the process proceeds to step S1508; otherwise, the process proceeds to step S1516.

At step S1508, the server device 10 responds to the request for providing A coins received at step S1502. That is, the server device 10 updates the owned coins (the owned coins in the user information shown in FIG. 6) associated with the requesting user. In this case, the server device 10 increases the number of owned coins associated with the user by the number of A coins requested.

In step S1510, the server apparatus 10 determines whether or not the provision request received in step S1502 is the first provision request of the current month by the same user (that is, the first use of the deferred payment function of the current month). If the determination result is "YES", the process proceeds to step S1512; otherwise, the process proceeds to step S1514.

In step S1512, the server apparatus 10 issues a new invoice ID and generates invoice information related to the new invoice ID (see FIG. 10). At this time, the "billing amount" of the invoice information corresponds to the amount of the A coin provided in response to this provision request.

In step S1514, server device 10 updates the bill information related to the already issued bill ID for the current month among the bill information associated with the requesting user. At this time, the "billing amount" (see FIG. 10) of the invoice information is increased by the amount of the A coin provided in response to the current provision request.

In step S1516, the server apparatus 10 notifies the requesting user that the current provision request cannot be met (that is, the A coin cannot be provided). Note that the notification may be realized via the site A. The notification may also include information on the number of A coins that can be provided (the difference between the upper limit value Nmax associated with the requesting user and the billed amount associated with the same user).

According to the process shown in FIG. 15, when a request for provision of A coins is received using the deferred payment function, provision The number of A coins requested can be provided to the requesting user. In the processing shown in FIGS. 14 and 15, before receiving a request for provision of A coins from the user, it is determined whether or not the user can use the deferred payment function, but the present invention is not limited to this. In a modified example, when a request for provision of A coins is received from a user, it may be determined whether or not the user can use the deferred payment function.

FIG. 16 is a schematic flow chart showing an operation example related to outputting bill information. The processing shown in FIG. 16 may be repeatedly executed, for example, at predetermined intervals.

In step S1602, the server device 10 determines whether or not any user has newly logged in to the site A. If the determination result is "YES", the process advances to step S1604; otherwise, the process for this cycle ends.

In step S1604, the server apparatus 10 extracts from the billing information database 55 all invoice IDs associated with the user who newly logged in in step S1602.

In step S1606, the server apparatus 10 determines whether or not an invoice ID associated with an output necessity flag (see FIG. 10) whose state is "1" exists among the invoice IDs extracted in step S1604. judge. If the determination result is "YES", the process advances to step S1608; otherwise, the process for this cycle ends.

Note that, in the modified example, in step S1604, the server device 10 sets the output necessity flag ( 10) may be extracted. In this case, step S1606 may be omitted. That is, if the invoice ID associated with the output necessity flag (see FIG. 10) whose state is "1" can be extracted, the process proceeds to step S1608, and if not extracted, the processing for this cycle ends. do.

In step S1608, the server apparatus 10 newly logs in the bill information (confirmed bill information) associated with the bill ID associated with the output necessity flag whose status is "1" in step S1602. Send to the user. That is, the server device 10 outputs the invoice information to the site A logged in by the user.

In step S1610, the server device 10 sets the output necessity flag associated with the bill ID associated with the bill information output in step S1608 to "0".

According to the process shown in FIG. 16, invoice information can be output to each user via the site A. FIG. Note that, apart from the processing shown in FIG. 16, the invoice information may be sent to the e-mail address associated with each user on the notification date after the closing date, or may be notified to each user by another means. good too.

Note that in the process shown in FIG. 16, the output necessity flag is set to "0" by outputting the invoice information to the site A, but the present invention is not limited to this. For example, instead of or in addition to outputting the invoice information on the site A, the invoice information is sent to the mail address associated with the user, so that the output necessity flag is set to "0". may Alternatively, instead of or in addition to outputting bill information on site A, when a transition to a screen for payment (not shown) is realized, the output necessity flag is set to "0". may

17 to 20 are schematic flow charts for explaining examples of operations related to activity restriction processing. FIG. 17 is a schematic flow chart showing an operation example related to activity restriction processing. The processing shown in FIG. 17 may be repeatedly executed, for example, every day.

In step S172, the server device 10 executes update processing of bill information (payment status category) based on the payment notification. This update processing will be described later with reference to FIG.

In step S174, the server device 10 executes update processing of bill information (payment status category) according to the unpaid time ΔT1. This update processing will be described later with reference to FIG.

In step S176, the server device 10 executes activity restriction processing according to the payment status category based on the processing result in step S174. The activity restriction process according to the payment status category will be described later with reference to FIG.

FIG. 18 is a schematic flow chart showing an example of the payment status category updating process (step S172 in FIG. 17) based on the payment notification.

In step S1802, the server device 10 extracts unprocessed payment notifications. Note that the payment notification is transmitted to the server device 10 from a terminal (not shown) of the convenience store or the like when the user completes the payment at the convenience store or the like. When the server device 10 receives the payment notification, it stores it in a predetermined storage device (database) (not shown) for accumulating unprocessed payment notifications. In this case, the server device 10 extracts all outstanding payment notifications from the predetermined storage device.

In step S1804, the server device 10 selects one payment notice from the unprocessed payment notices extracted in step S1802.

In step S1806, the server device 10 identifies the invoice ID associated with the payment number associated with the selected payment notification, and changes the payment status category associated with the invoice ID to "A".

In step S1808, the server device 10 determines whether or not all unprocessed payment notifications extracted in step S1802 have been selected. If the determination result is "YES", the process ends. Otherwise, the process returns to step S1806 via step S1810.

In step S1810, the server device 10 newly selects one unselected payment notice from among the unprocessed payment notices extracted in step S1802. In this case, the process of step S1806 is executed for the newly selected payment notification.

In this manner, according to the processing shown in FIG. 18, when a payment is made by the user using the deferred payment function, the payment status category for the corresponding invoice ID is changed to "A".

FIG. 19 is a schematic flow chart showing an example of bill information update processing (step S174 in FIG. 17) according to the unpaid time ΔT1.

In step S1902, the server apparatus 10 extracts all invoice IDs associated with payment status categories other than "A" from the invoice information database 55 (see FIG. 10).

In step S1904, the server apparatus 10 selects one invoice ID from among the invoice IDs extracted in step S1902.

In step S1906, the server device 10 determines that the unpaid time ΔT1 for the bill ID selected in step S1904 is the threshold value related to the fourth-level limitation (in this embodiment, as an example, as described above, four days from the payment due date). It is determined whether or not the time until the last day of the month after the month has passed. If the determination result is "YES", the process proceeds to step S1908; otherwise, the process proceeds to step S1910.

At step S1908, the server device 10 sets the payment status category associated with the invoice ID selected at step S1904 to "B4".

In step S1910, the server apparatus 10 sets the unpaid time ΔT1 to the third-stage limit threshold (in this embodiment, as an example, as described above, the bill ID selected in step S1904 is the month after the month after the payment due date). It is determined whether or not the time until the end of the period) has passed. If the determination result is "YES", the process proceeds to step S1912; otherwise, the process proceeds to step S1914.

In step S1912, the server device 10 sets (or maintains) the payment status category associated with the invoice ID selected in step S1904 to "B3".

In step S1914, the server device 10 sets the unpaid time ΔT1 to the second-stage limit threshold (in the present embodiment, as an example, the month following the payment due date as described above) for the invoice ID selected in step S1904. It is determined whether or not the time has exceeded the last day of +10 days). If the determination result is "YES", the process proceeds to step S1916; otherwise, the process proceeds to step S1918.

In step S1916, the server device 10 sets (or maintains) the payment status category associated with the invoice ID selected in step S1904 to "B2".

In step S1918, the server device 10 determines that the unpaid time ΔT1 for the invoice ID selected in step S1904 is the threshold for the first stage limit (in this embodiment, as an example, as described above, the month following the payment due date). It is determined whether or not the time until the end of the period) has passed. If the determination result is "YES", the process proceeds to step S1920; otherwise, the process proceeds to step S1922.

In step S1920, server device 10 sets (or maintains) the payment status category associated with the invoice ID selected in step S1904 to "B1".

In step S1922, server device 10 determines whether or not unpaid time ΔT1 is greater than 0 (that is, after the due date of payment) for the invoice ID selected in step S1904. If the determination result is "YES", the process proceeds to step S1924; otherwise, the process proceeds to step S1926.

In step S1924, the server device 10 sets (or maintains) the payment status category associated with the invoice ID selected in step S1904 to "B0".

In step S1926, the server apparatus 10 determines whether or not all invoice IDs have been selected from among the invoice IDs extracted in step S1902. If the determination result is "YES", the process for this cycle ends. Otherwise, the process returns to step S1906 via step S1928.

In step S1928, the server device 10 newly selects one unselected invoice ID from among the invoice IDs extracted in step S1902. In this case, the processing from step S1906 to step S1924 is executed for the newly selected invoice ID.

Thus, according to the processing shown in FIG. 19, the payment status category can be updated according to the unpaid time ΔT1 for each invoice ID.

FIG. 20 is a schematic flow chart showing an example of activity restriction processing (step S176 in FIG. 17) according to the payment status category.

In step S2002, server device 10 extracts all user IDs that can use the deferred payment function from deferred payment information database 56 (see FIG. 11). A user ID that can use the deferred payment function can be extracted based on "deferred payment availability" in the deferred payment information database 56 .

At step S2004, the server apparatus 10 selects one user ID from among the user IDs extracted at step S2002.

In step S2006, server device 10 extracts all bill IDs associated with the selected user ID from bill information database 55 (see FIG. 10). If the invoice ID associated with the selected user ID cannot be extracted, steps S2008 and S2010 may be omitted for that user ID.

In step S2008, the server device 10 identifies the worst payment status category among the payment status categories associated with the invoice ID extracted in step S2006. As described above, the payment status categories include "no classification", "A", and "B0" to "B4". "No classification" or "A" is the best, and "B0" to "B4 ” shall be worse in the order of

In step S2010, server device 10 determines the degree of restriction for the user associated with the selected user ID according to the worst payment status category identified in step S2008. implement restrictions on activities by

Specifically, if the payment status category specified in step S2008 is "no classification", "A", or "B0", the server device 10 does not implement any particular restriction. In addition, in a state where some restrictions (that is, restrictions from the first stage to the third stage described above) are implemented for the selected user ID, the server device 10 cancels the restrictions.

Also, if the payment status category identified in step S2008 is "B1", the server device 10 implements the first stage of restriction (in the present embodiment, suspension of the deferred payment function as described above). In this case, for example, the server device 10 changes the "possibility of postpayment" in the postpayment information database 56 associated with the selected user ID to "x". In this case, the “possibility of postpayment” associated with the user ID may be disabled according to the determination result of the determination unit 38 . Alternatively, the server device 10 may set the upper limit value Nmax associated with the selected user ID to "0", thereby substantially disabling the use of the deferred payment function by the user associated with the user ID.

Further, if the payment status category specified in step S2008 is "B2", the server device 10 imposes the second-level restriction (in this embodiment, as described above, the use of A coin acquisition means other than the deferred payment function is prohibited). stop). In this case, for example, the server device 10 prohibits execution of any processing that increases the owned coins (see FIG. 6) associated with the selected user ID.

Also, if the payment status category specified in step S2008 is "B3", the server device 10 implements the third level of restriction (prohibition of playing the game as described above in this embodiment). In this case, for example, the game processing unit 311 prohibits the play of the game based on the selected user ID.

Also, if the payment status category specified in step S2008 is "B4", the server device 10 implements the fourth level of restriction (account suspension as described above in this embodiment). In this case, for example, the server device 10 cancels the login state of site A based on the selected user ID (forcibly logs out), and thereafter prohibits login to site A based on the user ID. Further, the server device 10 may notify the administrator of the service providing system 1 or the like of the occurrence of the payment status category “B4”.

In step S2012, the server device 10 determines whether or not all user IDs extracted in step S2002 have been selected. If the determination result is "YES", the process ends. Otherwise, the process returns to step S2006 via step S2014.

In step S2014, the server device 10 newly selects one unselected user ID from among the user IDs extracted in step S2002. In this case, the processing from step S2006 to step S2010 is executed for the newly selected user ID.

In this way, according to the processing shown in FIG. 20, when the payment status category is updated, the degree of restriction for each user (the degree of restriction related to restriction of activity at site A) can be changed (updated) accordingly.

21 and 22 are schematic flow charts for explaining an operation example related to the output of prompting information.

FIG. 21 is a schematic flow chart showing an example of output processing of prompting information according to a predetermined operation. The processing shown in FIG. 21 may be repeatedly executed at predetermined intervals.

In step S2100, server device 10 determines whether or not a predetermined operation at site A by an arbitrary user has been detected. The predetermined operation is an operation that triggers the output of the prompting information, and is arbitrary, but for example, an operation related to various activities (login, access/use of SNS functions, game play, billing, etc.) on site A. It's okay. If the determination result is "YES", the process advances to step S2102; otherwise, the process for this cycle ends. Note that when two or more predetermined operations (predetermined operations by different users) are detected at the same time, the processing from step S2102 onward may be executed for each predetermined operation.

In step S2102, server device 10 extracts all invoice IDs associated with the user ID associated with the predetermined operation detected in step S2100 from billing information database 55 (see FIG. 10).

In step S2104, server device 10 identifies the worst payment status category among the payment status categories associated with the invoice ID extracted in step S2102.

In step S2106, the server device 10 determines whether the worst payment status category specified in step S2104 is "A" or "no classification". If the determination result is "YES", the processing for this cycle ends. In this case, the reminder information is not output. On the other hand, if the determination result is "NO", the process proceeds to step S2108.

At step S2108, the server device 10 determines whether or not the worst payment status category specified at step S2104 is "B0". If the determination result is "YES", the process proceeds to step S2110; otherwise, the process proceeds to step S2112.

In step S2110, server device 10 outputs the prompting information having the first level of alertness to the user having the user ID related to the predetermined operation detected in step S2100. For example, if the predetermined operation detected in step S2100 is logging in to site A, server device 10 outputs prompting information having a first-level level of attention on the screen after login. The prompting information having the first-level alerting degree is the prompting information with the lowest alerting degree, and may be, for example, the message M1 shown in FIG.

In step S2112, server device 10 determines whether or not the worst payment status category identified in step S2104 is "B1". If the determination result is "YES", the process proceeds to step S2114; otherwise, the process proceeds to step S2116.

In step S2114, server device 10 outputs the prompting information having the second level of alertness to the user having the user ID related to the predetermined operation detected in step S2100. Reminder information having a second level of alertness is reminder information with a higher level of alertness than the first level, for example, a similar message (not shown) larger in size than message M1 shown in FIG. can be In addition, the reminder information having the second level of attention is the current situation information in which the first level restriction (in the present embodiment, suspension of the deferred payment function as described above) is realized, and the case where the non-payment continues may contain advance notice information that the next second level restriction will be implemented.

At step S2116, the server device 10 determines whether or not the payment status category specified at step S2104 is "B2". If the determination result is "YES", the process proceeds to step S2118; otherwise (ie, if the payment status category specified in step S2104 is "B3"), the process proceeds to step S2120.

In step S2118, server device 10 outputs the prompting information having the third level of alertness to the user having the user ID related to the predetermined operation detected in step S2100. Reminder information having a third level of alertness is reminder information with a higher level of attention than the second level. Reminder information with a level of 3rd level attention includes information on the current situation that the 2nd level restriction has been implemented, and notice information that the next 3rd level restriction will be implemented if non-payment continues. may contain.

In step S2120, server device 10 outputs the prompting information having the fourth level of alertness to the user having the user ID related to the predetermined operation detected in step S2100. The prompting information having the fourth level of alertness is reminder information with a higher level of alerting than the third level. Reminder information with a level of alertness of the fourth level includes information on the current situation that the third level of restriction has been implemented, and notice information that the next fourth level of restriction will be implemented if non-payment continues. may contain.

According to the process shown in FIG. 21, the prompting information can be efficiently output via the site A to the user to whom the prompting information is to be output. Note that in the process shown in FIG. 21 , each of the prompting information having the first to fourth levels of alerting levels is output with the same predetermined operation as a trigger, but the present invention is not limited to this. For example, the number of types of predetermined operations that trigger the output of prompting information may be increased for prompting information with a higher alerting degree so that the number of output opportunities increases for prompting information with a higher alerting degree.

FIG. 22 is a schematic flow chart showing an example of processing for outputting reminder information in response to a change in payment status category. The process shown in FIG. 22 may be executed in cooperation with the process of step S174 shown in FIG.

In step S2202, server device 10 selects all users whose payment status category has changed from "B2" to "B3" as a result of step S176 of the processing shown in FIG. Extract the ID.

At step S2204, the server device 10 selects one user ID from among all the user IDs extracted at step S2202.

In step S2206, server device 10 transmits a short message related to the reminder information to the telephone number associated with the selected user ID. In the modified example, in place of or in addition to the short message, the prompting information is output by calling the telephone number associated with the selected user ID and playing an automatic voice related to the prompting information. good too.

In step S2208, the server device 10 determines whether or not all user IDs extracted in step S2202 have been selected. If the determination result is "YES", the process ends. Otherwise, the process returns to step S2206 via step S2210.

In step S2210, the server device 10 newly selects one unselected user ID from among the user IDs extracted in step S2202. In this case, the process of step S2206 is executed for the newly selected user ID.

In this way, according to the processing shown in FIG. 22, when the payment status category is updated and the payment status category is "B3" (a user for whom the third-level restriction is implemented), the corresponding user Reminder information can be output in an output form having a relatively high level of alerting, that is, a short message.

Although each embodiment has been described in detail above, it is not limited to a specific embodiment, and various modifications and changes are possible within the scope described in the claims. It is also possible to combine all or more of the constituent elements of the above-described embodiments.

For example, in the embodiment described above, as described above, the user of site A can be provided with other digital content only through A coins, but the present invention is not limited to this. That is, the user of site A may be able to receive other digital content without using A coins. That is, the user of site A may be able to receive other digital content up to the limit of directly paying for the other digital content. In this case as well, by enabling the use of the deferred payment function, the same effects as in the above-described embodiment can be obtained.

Also, in the above-described embodiments, as described above, in order to minimize the user's burden for using the postpaid function, the user's real-world information (age, income, address, etc.) is not used. , determines whether or not the user can use the deferred payment function, but is not limited to this. A user's real-world information may be used along with the log information to determine whether the user can use the deferred payment function.

In the above-described embodiment, the services that can be provided via the service platform in the service providing system 1 relate to layers related to digital content, but services related to other layers such as communication networks and terminals may also be included. good.

Also, in the above-described embodiment, the deferred payment function is realized in a single service platform, but it may be realized in cooperation with a plurality of service platforms. In this case, the log information used by the determination unit 38 may also be collected by a plurality of service platforms.

Further, in the above-described embodiment, as described above, the restriction on game play by the activity restriction unit 42 is prohibition of game play, but is not limited to this. The activity restriction unit 42 may partially restrict game play instead of prohibiting game play. Although the method of partially restricting game play is arbitrary, it may be realized by restricting the play time. In addition, the activity restriction unit 42 restricts the use of some game media (for example, restricts the cost of the first game media that can be incorporated into the deck, limits the types of first game media that can be incorporated into the deck, and may partially restrict game play, such as by restricting In addition, the activity restriction unit 42 may increase the degree of restriction on game play in conjunction with an increase in the unpaid time ΔT1. In this case, the activity restriction unit 42 may prohibit the play of the game when the unpaid time ΔT1 exceeds the final predetermined time. The same applies to restrictions on game play. For example, when the activity restriction unit 42 restricts the use of other digital content (e-books, video viewing, etc.), the restriction may be a prohibition of use, or a partial restriction of use. There may be. In this case, the partial restriction may be limited to the usage time of the digital content (for example, the usage time per certain period, the total usage time, etc.), or may be limited to the available time zone. Also, the activity restriction unit 42 may increase the degree of restriction on the use of other digital content in conjunction with the increase in the unpaid time ΔT1. In this case, the activity restriction unit 42 may prohibit use of the other digital content when the unpaid time ΔT1 exceeds the final predetermined time.

In addition, the following additional remarks are disclosed regarding the above embodiment.

[Appendix 1]
a log information acquisition unit that acquires log information associated with user identification information;
payment for the digital content, on the condition that the user pays for the user identification information by a predetermined deadline after the digital content is provided, the user identification information based on the log information; and a service providing unit that provides the digital content to the user.

[Appendix 2]
further comprising a determining unit that determines whether or not the digital content can be provided by the service providing unit to the user associated with the user identification information associated with the log information, based on the log information;
The digital content providing apparatus according to appendix 1, wherein the service providing unit provides the digital content to the user associated with the user identification information based on the determination result of the determining unit.

[Appendix 3]
further comprising a prompting information output unit for outputting prompting information prompting the user associated with the user identification information to pay the fee for the digital content if the fee for the digital content has not been paid by the predetermined time limit; , appendix 1 or 2 digital content providing apparatus.

[Appendix 4]
The digital content providing device according to appendix 3, wherein the prompting information output unit changes the output mode of the prompting information according to the elapsed time from a predetermined first timing.

[Appendix 5]
4. The prompting information output unit according to appendix 4, wherein when the elapsed time from the first timing exceeds a first predetermined time, the prompting information output unit outputs the prompting information via the logged-in site based on the user identification information. Digital content providing device.

[Appendix 6]
The prompting information output unit outputs the prompting information in such a manner that a short message is sent to the telephone number associated with the user identification information when the elapsed time from the first timing exceeds a second predetermined time. , appendix 4 or 5, the digital content providing device.

[Appendix 7]
7. The item according to any one of Appendices 1 to 6, further comprising an activity restriction unit that restricts activities based on the user identification information when the price for the digital content is not paid by the predetermined deadline. Digital content providing device.

[Appendix 8]
8. The digital content providing apparatus according to supplementary note 7, wherein the activity restriction unit changes the mode of restricting the activity based on the user identification information according to the elapsed time from a predetermined second timing.

[Appendix 9]
9. The digital content providing apparatus according to appendix 8, wherein the activity restriction unit prohibits part of the activity based on the user identification information when the elapsed time from the second timing exceeds a third predetermined time.

[Appendix 10]
The activity restriction unit according to appendix 9, wherein when the elapsed time from the second timing exceeds a fifth predetermined time longer than the third predetermined time, all activities based on the user identification information are prohibited. Digital content providing device.

[Appendix 11]
The service providing unit provides various services including provision of the digital content via the service platform,
The activity restriction unit restricts the use of a part of the various services based on the user identification information when the elapsed time from a predetermined second timing exceeds a third predetermined time, and from the second timing exceeds a fourth predetermined time longer than the third predetermined time, use of all of the various services based on the user identification information is restricted, and the elapsed time from the second timing is the fourth predetermined time. 8. The digital content providing apparatus according to appendix 7, wherein the use of the service platform based on the user identification information is disabled when a fifth predetermined time period longer than the 4 predetermined time period is exceeded.

[Appendix 12]
The service providing unit, in response to a request from a user relating to the user identification information, until the cumulative value of the consideration before payment reaches an upper limit value associated with the user identification information. providing one or more of said digital content to a user;
12. The digital content providing apparatus according to any one of Appendices 1 to 11, further comprising an upper limit value setting unit that sets the upper limit value based on the log information.

[Appendix 13]
13. The digital content providing apparatus according to appendix 12, wherein the upper limit value setting unit sets the upper limit value based on the past payment status of the consideration associated with the user identification information together with the log information.

[Appendix 14]
14. The digital content providing device according to any one of Appendices 1 to 13, wherein the digital content includes at least one of viewable content, information content, consumable content, and game media. .

[Appendix 15]
15. The digital content providing apparatus according to any one of Appendixes 1 to 14, wherein the log information relates to activities based on the user identification information.

[Appendix 16]
Activities based on the user identification information include login based on the user identification information, billing based on the user identification information, use of the digital content or other digital content based on the user identification information, and SNS based on the user identification information. 16. The apparatus for providing digital content according to appendix 15, for at least any one of the utilization of.

[Appendix 17]
The service providing unit provides various services including provision of the digital content via the service platform,
16. The apparatus for providing digital content according to appendix 15, wherein the activity based on the user identification information relates to utilization of at least some of the various services.

[Appendix 18]
Acquiring log information associated with user identification information,
payment for the digital content, on the condition that the user pays for the user identification information by a predetermined deadline after the digital content is provided, the user identification information based on the log information; A computer-implemented method of providing digital content, comprising providing said digital content to such a user.

[Appendix 19]
Acquiring log information associated with user identification information,
payment for the digital content, on the condition that the user pays for the user identification information by a predetermined deadline after the digital content is provided, the user identification information based on the log information; A program that causes a computer to execute a process of providing the digital content to the user.

1 Service providing system 10 Server device 11 Server communication unit 12 Server storage unit 13 Server control unit 20 Terminal device 21 Terminal communication unit 22 Terminal storage unit 23 Display unit 24 Input unit 25 Terminal control unit 30 User registration unit 31 Service provision unit 311 Game Processing unit 312 SNS function realizing unit 313 Content providing unit 3131 Coin providing unit 3132 Digital content providing unit 314 Billing processing unit 315 Digital content using unit 34 Log information storage unit 36 Log information acquisition unit 38 Judging unit 39 Billing information management unit 40 Reminder information Output unit 42 Activity restriction unit 44 Upper limit setting unit 50 User information database 52 Log information database 54 Index value database 55 Billing information database 56 Deferred payment information database

Claims (1)

a log information acquisition unit that acquires log information associated with user identification information;
payment for the digital content, on the condition that the user pays for the user identification information by a predetermined deadline after the digital content is provided, the user identification information based on the log information; and a service providing unit that provides the digital content to the user.

Images