Serial publication management server, serial publication management system, and serial publication management program

Abstract

To achieve a virtuous circle of support and serial publication of serial publication type digital contents.SOLUTION: A serial publication management server comprises: a support money receiving unit 122 that executes processing of receiving support money from viewers for a publicized first range of a serial publication type digital contents; and a distribution unit 123 that executes processing of determining whether a second range that is a continuation of the first range is posted by a posting limit time, when the second range is posted by the posting limit time, pays a reward according to the cumulative amount of support money to a producer of the serial publication type digital contents, and when the second range is not posted by the posting limit time, executes processing of refunding the support money to the viewers.SELECTED DRAWING: Figure 1

Description

[Technical field]

[0001] The present invention relates to a serialization management server, a serialization management system, and a serialization management program for managing serialization of serialized digital content. [Background technology]

[0002] A function for comic sites that allows fans (viewers) to give "gifts" to creators (producers) who have posted comic content has already been proposed (see Non-Patent Document 1, etc.). For example, the "gifts" function disclosed in Non-Patent Document 1 accepts supportive messages and paid digital items from fans, and also returns royalties to creators that are determined by the frequency of posting comic content and gifts, etc.

[0003] Meanwhile, crowdfunding sites that solicit funding for projects are also well known (see Patent Document 1, Non-Patent Document 2, etc.). For example, the crowdfunding system disclosed in Patent Document 1 allows users to select one or more support courses from a number of support courses to provide support, and has a function for determining the type and amount of digital content to be provided to a user when the total amount of support received from that user reaches a certain amount. [Prior art documents] [Patent documents]

[0004] [Patent Document 1] Patent Publication No. 2021-77301 [Non-patent literature]

[0005] [Non-Patent Document 1] Internet article: "Manga fans can give gifts (tips) to creators! Manga Hack releases beta version of creator support program!", PR TIMES Inc., [Retrieved October 26, 2023], Internet<URL:https: / / prtimes.jp / main / html / rd / p / 000000010.000022028.html> [Non-Patent Document 2] Crowdfunding "CAMPFIRE", CAMPFIRE Inc., [Searched on October 26, 2023], Internet<URL:https: / / camp-fire.jp / > Summary of the Invention [Problem to be solved by the invention]

[0006] However, while typical serialized manga content is posted frequently, such as once a month, the creators of manga content can only earn income after posting multiple chapters, when the manga is published as a book (tankobon) and royalties are generated. For this reason, many creators, including new creators, are constantly struggling with a lack of funds and are always at risk of not receiving compensation that is commensurate with the production costs of each chapter. As a result, creators who lack the funds sometimes give up on continuing the series.

[0007] Incidentally, it is possible for creators of manga content to raise funds by using the crowdfunding site described in Patent Document 2, but since this site does not generally verify the progress of the project, even if funds are raised, it does not necessarily stimulate the desire to create the latest chapters.

[0008] The present invention has been made in consideration of the above problems, and aims to provide a serialization management server, a serialization management system, and a serialization management program for serialized digital content that can create a virtuous cycle of support and serialization. [Means for solving the problem]

[0009] In order to solve the above problems, one serialization management server of the present invention is a serialization management server that manages the serialization of serialized digital content, and is characterized in having a support money receiving unit that executes a process of receiving support money from the viewer for a first range of the serialized digital content that has been published, and a distribution unit that executes a process of determining whether a second range that is a continuation of the first range has been posted by the posting deadline, and if the second range has been posted by the posting deadline, pays a reward in an amount corresponding to the accumulated amount of the support money to the creator of the serialized digital content, and if the second range has not been posted by the posting deadline, executes a process of refunding the support money to the viewer.

[0010] In order to solve the above problem, in a serialization management server of the present invention, if the accumulated amount of the support funds does not reach the target amount by the deadline for collection, the distribution unit may execute a process of paying the reward to the creator regardless of whether or not there are any posts within the second range.

[0011] In order to solve the above problem, in one serial management server of the present invention, the distribution unit may execute a process of notifying the creator of the fact and the submission deadline when the cumulative amount of the support funds reaches the target amount during the period from the first range of submissions to the submission deadline.

[0012] In order to solve the above problem, in a serial management server of the present invention, the distribution unit may execute a process of notifying the creator of this fact and that the submission deadline has been lifted if the cumulative amount of the support funds does not reach the target amount during the period from the first range of submissions to the submission deadline.

[0013] In order to solve the above problem, a serial management server of the present invention may further include a submission acceptance unit that accepts submissions within the first range from the creator and executes a process of accepting at least one specification of the recruitment deadline, the target amount, and the submission deadline from the creator.

[0014] In order to solve the above problem, in a serial management server of the present invention, the submission acceptance unit may execute a process of disclosing to the viewers at least one of the recruitment deadline, the target amount, the submission deadline, and the cumulative amount along with the first range.

[0015] In order to solve the above-mentioned problems, in one serialization management server according to the present invention, the serialized digital content may be serialized manga content.

[0016] In order to solve the above problems, a serialization management system according to the present invention is characterized in that it comprises a serialization management server according to the present invention and a data server that stores each range of the serialized digital content posted by the creator.

[0017] In order to solve the above-mentioned problems, one serial management program of the present invention is a computer-readable serial management program that causes a computer to function as one serial management server of the present invention, and is characterized in that it causes the computer to execute the following processes: a process of accepting financial support from the viewer for a first range of the serialized digital content that has already been published; a process of determining whether a second range that is a continuation of the first range has been posted by the posting deadline; and a process of paying a reward corresponding to the accumulated amount of the financial support to the creator of the serialized digital content if the second range has been posted by the posting deadline; and a process of refunding the financial support to the viewer if the second range has not been posted by the posting deadline. Effect of the Invention

[0018] The serialization management server, serialization management system, and serialization management program according to the present invention accept financial support from viewers for the first range of serialized content and pay a corresponding amount of remuneration to the creator, so that the more support viewers give, the more funds the creator can allocate to the production costs of the second range. This makes it possible to encourage support from viewers who are eagerly awaiting posts in the second range. However, if the second range is not posted by the posting deadline, the reward will not be paid to the creator and the support money will be refunded to the viewer. This makes it possible to encourage creators who wish to receive rewards to post the second range. As a result of the above, the serialization management server, serialization management system, and serialization management program of the present invention allow viewers to be involved in promoting serialization while also returning profits generated during the serialization to the creators, thereby creating a virtuous cycle of support and serialization.

[0019] In addition, in the serialization management server, serialization management system, and serialization management program according to the present invention, if the cumulative amount of donations does not reach the target amount by the deadline, no refund will be made to the viewers even if the second range is not posted by the posting deadline, so viewers who provide donations will be motivated to make the cumulative amount reach the target amount as soon as possible. This will encourage viewers who provide donations to provide more support, and it is believed that donation collection can be accelerated. And when collection is accelerated, the creators' motivation to create will be stimulated, so that an increase in the production speed of the second range can also be expected. As a result, the serialization management server, serialization management system, and serialization management program according to the present invention facilitate a more virtuous cycle of support and serialization. [Brief description of the drawings]

[0020] [Figure 1] FIG. 1 is a schematic block diagram illustrating a schematic configuration of a serialization management system according to an embodiment. [Diagram 2] FIG. 2 is a schematic block diagram illustrating the configuration of the serialization management server. [Diagram 3] Figure 3 is a sequence chart of the serialization management system. [Figure 4] FIG. 4 is an explanatory diagram for explaining the configuration of the user table. [Diagram 5] FIG. 5 is an explanatory diagram for explaining the configuration of the content table. [Figure 6] FIG. 6 is an explanatory diagram for explaining the configuration of the support history table. [Figure 7]FIG. 7 is an explanatory diagram for explaining the configuration of the settlement table. [Figure 8] FIG. 8 is a flowchart illustrating the operation of the posting acceptance unit. [Figure 9] FIG. 9 is a flowchart explaining the operation of the support money receiving unit. [Figure 10] FIG. 10 is a flowchart illustrating the operation of the distribution unit. [Figure 11] FIG. 11 is a flowchart explaining the operation of the distribution unit (at the time of settlement). DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0021] DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS Hereinafter, an embodiment of a serial management server, a serial management system, and a computer-readable serial management program according to the present invention will be described with reference to the drawings. 1.Serialization Management System First, a schematic configuration of the serialization management system of this embodiment will be described. Fig. 1 is a schematic block diagram for explaining the schematic configuration of the serialization management system according to the embodiment. As shown in Fig. 1, the serialization management system 100 includes a serialization management server 10, a data server 20, a settlement server 30, etc., and these serialization management server 10, data server 20, and settlement server 30 are connected to a plurality of terminals 50-1, 50-2, ... via a communication network 40 such as the Internet. The plurality of terminals 50-1, 50-2, ... are terminal devices used individually by a plurality of users 1, 2, 3, 4, ... registered in advance in the serialization management server 10. Note that "user 1", "user 2", "user 3", "user 4", ... are user IDs for distinguishing registered users (registered users) from each other.). Here, assume that the serial management system 100 of the present embodiment is a content platform that handles serial comic content as serial digital content. Also, here, assume that each of users 1, 2, 3, and 4 is a producer user who posts original serial comic content to the serial management system 100 (hereinafter referred to as "producer user i (i = 1, 2, 3, 4)"). Also, assume that each of users 5, 6,... is a viewer user who views at least one posted serial comic content (hereinafter referred to as "viewer user j (j = 5, 6,...)"). However, at least one producer user i can also be a viewer user j of the serial comic content posted by another producer user i, and at least one viewer user j can also be a producer user i who posts original serial comic content. Also, at least one producer user i can post multiple serials. Also, here, for simplicity, assume that the range of one post is one episode, but the range of one post is not limited to this, and for example, it may be multiple episodes or one comic book.

[0022] In the above serial management system 100, the serial management server 10 is a server device that manages the serial of serial digital content. The details of this serial management server 10 will be described later.

[0023] The data server 20 executes processes such as storing the content data file of each episode of the serial comic content uploaded from the terminal 50-i of the producer user i under the instruction from the serial management server 10, and making the content data file viewable on the terminal 50-j for the viewer user j. Making it viewable includes, in addition to making the page images of the corresponding episode viewable on the terminal, granting the right to download the content data file of the corresponding episode to the terminal. Note that the operator of the data server 20 may be the same person as the operator of the serial management server 10 or may be another person (such as a file storage provider).

[0024] The payment server 30 executes the processing required when the viewer user j pays (settles) the support money via the terminal 50-j to the operator of the serial management server 10. The operator of the payment server 30 may be the same person as the operator of the serial management server 10, or may be a different person (such as a payment agent).

[0025] Each of the terminals 50-1, 50-2, ... is composed of a desktop PC, a laptop PC, a tablet PC, a smartphone, a head-mounted display PC, a home game machine, etc., and each of the terminals 50-1, 50-2, ... has an application program (including a web browser, a game program, etc.) provided by the serialization management server 10 or pre-installed therein in advance. This application program, by using a display device, an input device, etc. mounted on the terminal devices 50-1, 50-2, ..., causes the terminals 50-1, 50-2, ... to function as a user interface required for user registration, viewing each episode of serialized manga content, posting each episode of manga content, payment of support funds, etc.

[0026] 2.Serialization Management Server Next, a schematic configuration of the serial management server 10 of this embodiment will be described. Fig. 2 is a schematic block diagram illustrating the configuration of the serial management server. As shown in Fig. 2, the serial management server 10 includes a communication unit 11, a control unit 12, a storage unit 13, and the like.

[0027] The communication unit 11 is a communication interface for the serialization management server 10 to transmit and receive data between the data server 20, the settlement server 30, and the terminals 50-1, 50-2, . . . via the network 40.

[0028] The storage unit 13 is a storage device that stores programs and data necessary for the processing of the serial management server 10, and is a storage device that is disposed inside or outside the serial management server 10. The storage unit 13 stores a serial management program 131, a user table 132, a content table 133, a support history table 134, a settlement table 135, etc. The user table 132, the content table 133, the support history table 134, and the settlement table 135 will be described in detail later.

[0029] The control unit 12 is a processor (CPU) that executes various processes by executing a serialization management program 131, and functions as a submission receiving unit 121, a support money receiving unit 122, and a distribution unit 123 as appropriate.

[0030] 3. Overview of operation of each part Next, an overview of the operations of the post receiving unit 121, the support money receiving unit 122, and the distribution unit 123 will be described. Fig. 3 is a sequence chart of the serialization management system. Here, attention is focused on the nth episode of a certain serialized manga content.

[0031] Step S1 in Figure 3: The submission acceptance unit 121 executes a process of accepting a submission of the nth episode of a serialized manga content created by the creator user i from the terminal 50-i, a process of accepting a donation deadline, a target amount of donation, and a submission deadline for the (n+1)th episode from the terminal 50-i when accepting a submission from the terminal 50-i, and a process of publishing the posted nth episode to registered users. The submission acceptance unit 121 also executes a process of publishing the donation deadline, the target amount, and the submission deadline, and the cumulative amount of donation for the nth episode, together with the nth episode posted by the creator user i, to registered users. Note that at least one of the donation deadline, the target amount, and the submission deadline may be automatically determined, but here it is assumed that the production speed and production cost differ depending on the creator and the serialization, and the creator user i can arbitrarily specify them. Incidentally, when automatically determined, the donation deadline may be a predetermined period after the posting date and time, or a predetermined period after the posting date and time or the donation deadline.

[0032] Step S2 in Figure 3: The financial support receiving unit 122 executes a process of receiving a financial support from the terminal 50-j of the viewer user j for the released episode n (n: any natural number), a process related to the settlement of the financial support, and the like.

[0033] Step S3 in Figure 3: The distribution unit 123 executes a process of determining whether the (n+1)th episode has been posted by the posting deadline. If the (n+1)th episode has been posted by the posting deadline, the distribution unit 123 transfers (pays) a remuneration corresponding to the amount of the support money to a remittance destination designated in advance by the creator user i of the serialized digital content, and if the (n+1)th episode has not been posted by the posting deadline, the distribution unit 123 executes a process of refunding the support money to the viewer user j instead of transferring (paying) the remuneration to a remittance destination designated in advance by the creator user i. However, if the amount of the support money does not reach the target amount by the collection deadline, the distribution unit 123 executes a process of transferring (paying) the remuneration to a remittance destination designated in advance by the creator user i, regardless of whether the (n+1)th episode has been posted. If the accumulated amount of support funds reaches the target amount during the period from the posting of episode n to the deadline for collection, the distribution unit 123 executes a process of notifying the terminal 50-i of creator user i of this fact and of the posting deadline, and if the accumulated amount of support funds does not reach the target amount during the period from the posting of episode n to the deadline for collection, the distribution unit 123 executes a process of notifying the terminal 50-i of creator user i of this fact and that the posting deadline has been lifted.

[0034] 4.User table Next, the user table 132 will be described. FIG. 4 is an explanatory diagram for explaining the configuration of the user table. As shown in FIG. 4, the user table 132 stores information such as user registration details and user sales for each user. Of these, the user registration details include user-specific information such as email address, password, and remittance destination. Meanwhile, the user sales include sales of serialized manga content posted by the user. For example, the amount recorded as this sales is the accumulated amount of support money for manga content minus a management fee (for example, 5%). The user table 132 is updated when a user is registered, when the user registration details are changed, when the support money is settled, when the reward is paid to the user, etc. The sales recorded in the user table 132 are, for example, the sales amount from the previous closing date to the current time, and are reset to zero when a specified closing date such as the end of the month arrives and the reward amount obtained by deducting, for example, a remittance fee (bank transfer fee) from the sales amount is remitted to the remittance destination designated by the user (settlement is completed).

[0035] 5. Table of Contents Next, the content table 133 will be described. Fig. 5 is an explanatory diagram for explaining the configuration of the content table. As shown in Fig. 5, the content table 133 stores information such as the user ID of the creator user i, the storage location of the content data file of each story, the posting date and time, the deadline for collecting donations, the posting deadline, and the target amount of donations for each posted serialized manga content and for each story. The timing at which this content table 133 is updated is, for example, the timing of posting.

[0036] 6. Support History Table Next, the support history table 134 will be described. Fig. 6 is an explanatory diagram illustrating the configuration of the support history table. As shown in Fig. 6, the support history table 134 stores, for each support, the ID of the viewer user who paid the support money, the ID of the serialized content and episode number to be supported, a payment ID, etc. The support history table 134 is updated, for example, when the payment of the support money is completed.

[0037] 7. Payment Table Next, the payment table 135 will be described. Fig. 7 is an explanatory diagram for explaining the configuration of the payment table. As shown in Fig. 7, in the payment table 135, information such as the ID of the user who made the payment (of the support money), the payment amount, and the date and time of payment is recorded for each payment. The payment table 135 is updated, for example, when the payment of the support money by the viewer user j is completed, when a refund (negative payment) to the viewer user is completed, etc.

[0038] 8. Posting flow The flow of accepting submissions will be described below, assuming that a creator user i submits each chapter of an original serialized manga content in sequence. FIG. 8 is a flowchart for explaining the operation of the submission acceptance unit. As shown in FIG. 8, the submission receiving unit 121 executes the following steps S11 to S191 for each series.

[0039] Step S11: The post receiving unit 121 sets the value of the episode number n to "1" and proceeds to the next step S12.

[0040] Step S12: The submission acceptance unit 121 determines whether or not a submission request for the nth episode has been received from the terminal 50-i of the creator user i, and if so, proceeds to the next step S13, and if not, waits.

[0041] Step S13: The submission acceptance unit 121 determines whether or not a submission deadline has been specified from the terminal 50-i of the creator user i, and if so, proceeds to the next step S14, and if not, waits. Note that in this step, the submission acceptance unit 121 may have the creator user i specify the number of days (e.g., 30 days, 60 days, etc.) counted from the posting date of the nth episode, instead of directly specifying the submission deadline.

[0042] Step S14: The submission acceptance unit 121 determines whether or not a target amount of the financial contribution has been specified from the terminal 50-i of the creator user i, and if so, proceeds to the next step S15, and if not, waits.

[0043] Step S15: The submission acceptance unit 121 determines whether or not a submission deadline for the (n+1)th episode has been received from the terminal 50-i of the creator user i. If so, the process proceeds to the next step S16. If not, the process waits. Note that the submission acceptance unit 121 in this step may have the creator user i specify the number of days (e.g., 30 days, 60 days, etc.) from the deadline instead of directly specifying the submission deadline. However, the submission acceptance unit 121 may limit the range that the creator user i can specify so that the submission deadline is set before the number of days (e.g., 180 days) that can be refunded by credit card has elapsed, counting from the first day of accepting the support money for the nth episode (here, the date of posting the nth episode). This is because, in this embodiment, there is a possibility that the support money will be refunded to the viewer user j.

[0044] Step S16: The submission receiving unit 121 determines whether or not uploading of the content data file of episode n has started from the terminal 50-i of creator user i, and if uploading has started, proceeds to the next step S17, and if uploading has not started, waits.

[0045] Step S17: The submission receiving unit 121 stores the uploaded content data file of the nth episode in the data server 20, and when the storage is complete, the process proceeds to the next step S18.

[0046] Step S18: The submission acceptance unit 121 writes the storage location in the data server 20 of the content data file for episode n, the current date and time (posted date and time / uploaded date and time), the collection deadline specified by creator user i, the target amount, and the submission deadline for episode (n+1) to the content table 133. As a result, episode n is registered in the content table 133.

[0047] Step S19: The submission acceptance unit 121 makes the nth episode public to registered users (both creator user i and viewer user j) (makes it viewable on the terminal), and also makes public the deadline and target amount of the donation for the nth episode, and proceeds to the next step S191. Here, the deadline and target amount of the donation for the nth episode are made public on, for example, a thumbnail screen for the nth episode, a viewing screen for the nth episode, a screen showing the end of viewing the nth episode, and a donation acceptance screen for the nth episode. Incidentally, the accumulated amount of donations for the nth episode is also made public on these screens. If the accumulated amount is made public, viewer user j can easily make decisions such as "the accumulated amount will reach the target amount soon, so I'll pay the donation", "the deadline is soon, so I'll pay the donation", and "the accumulated amount will reach the target amount with 1000 yen, so I'll make the donation 1000 yen".

[0048] Step S191: The post receiving unit 121 increments the value of the number of stories n, and then proceeds to step S12.

[0049] The order of the above steps S11 to S191 can be changed as appropriate. For example, the order of some or all of steps S12, S13, S14, and S15 may be changed.

[0050] 9. Flow of accepting donations Hereinafter, a flow related to the support money reception will be described assuming that a viewer user j views serialized manga content posted by a creator user i. Fig. 9 is a flowchart for explaining the operation of the support money reception unit. As shown in FIG. 9, the support fund receiving unit 122 executes the following steps S21 to S291 for each series.

[0051] Step S21: The support money receiving unit 122 sets the value of the episode number n to "1" and proceeds to the next step S22.

[0052] Step S22: The financial support receiving unit 122 refers to the content table 133 to determine whether the nth episode of the serialized manga content has already been posted, and if it has already been posted, proceeds to the next step S23, and if it has not yet been posted, waits.

[0053] Step S23: The support money receiving unit 122 determines whether or not a support money payment request has been received from the terminal 50-j of the viewer user j, and if so, proceeds to the next step S24, and if not, waits. In this embodiment, for example, a support money receiving screen is displayed together with a thumbnail screen of the nth episode, a viewing screen of the nth episode, and a viewing end screen of the nth episode. The support money receiving screen is a screen for the viewer user j to determine the support amount, select a payment method, and pay the support money.

[0054] Step S24: The support money receiving unit 122 determines whether or not a designation of the amount of support money has been received from the terminal 50-j of the viewer user j, and if so, proceeds to the next step S25, and if not, waits.

[0055] Step S25: The support money receiving unit 122 transmits a payment request for the support money of the amount designated by the viewer user 50-j to the payment server 30, and proceeds to the next step S26. Note that the payment method that the viewer user 50-j can adopt is, for example, credit card payment.

[0056] Step S26: The support money receiving unit 122 determines whether or not a payment completion notice has been received from the payment server 30, and if so proceeds to the next step S27, and if not, waits.

[0057] Step S27: The support money receiving unit 122 updates the payment table 135 by writing the ID of the viewer user j who paid the support money, the payment amount, and the payment date and time, and then proceeds to the next step S28.

[0058] Step S28: The support money receiving unit 122 updates the support machine table 134 by writing the ID of the viewer user j, the ID of the serial that was supported, the ID of the episode that was supported, and the payment ID. The support money receiving unit 122 also updates the cumulative amount (the cumulative amount of support for episode n) currently being displayed on the thumbnail screen for episode n, the viewing screen for episode n, the end of viewing screen for episode n, the support money receiving screen for episode n, and the like, and proceeds to the next step S29.

[0059] Step S29: The support money receiving unit 122 refers to the content table 133 to determine whether the deadline for collecting support money for the nth episode has arrived or not, and if the deadline has not arrived, returns to step S22, and if the deadline has arrived, proceeds to the next step S291.

[0060] Step S291: The support money receiving unit 122 increments the value of the number of episodes n and then returns to step S22.

[0061] The order of the above steps S21 to S291 can be changed as appropriate. For example, the order of some or all of steps S22, S23, and S24 may be changed.

[0062] 10.Serialization management flow Hereinafter, a flow relating to distribution will be described on the assumption that a serialized manga content posted by a creator user i is viewed by a viewer user j. Fig. 10 is a flowchart for explaining the operation of the distribution unit. As shown in FIG. 10, the distribution unit 123 executes the following steps S31 to S395 for each series.

[0063] Step S31: The distributor 123 sets the value of the number of episodes n to "1" and proceeds to the next step S32.

[0064] Step S32: The distribution unit 123 refers to the content table 133 to determine whether the nth episode of the serialized manga content has already been posted, and if it has already been posted, proceeds to the next step S33, and if it has not yet been posted, waits.

[0065] Step S33: The distribution unit 123 calculates the cumulative amount of support money for the nth episode by referring to the support history table 134 and the payment table 135, and then determines whether the cumulative amount has reached the target amount for the nth episode recorded in the content table 133.If it has reached the target amount, the process proceeds to step S34; if it has not reached the target amount, the process proceeds to step S35.

[0066] Step S34: The distribution unit 123 notifies the creator user i that the accumulated amount of support money has reached the target amount and the posting deadline by sending the notification to the email address registered in the user table 132, and then proceeds to the next step S35. This can improve the motivation of the creator user i.

[0067] Step S35: The distribution unit 123 refers to the content table 133 and determines whether the deadline for collecting support funds for the nth episode has arrived, and if it has not arrived, returns to step S32, and if it has arrived, proceeds to step S36.

[0068] Step S36: The distribution unit 123 calculates the cumulative amount of support money for the nth episode by referring to the support history table 134 and the payment table 135, and then determines whether the cumulative amount has reached the target amount for the nth episode recorded in the content table 133.If the cumulative amount has reached the target amount, the process proceeds to step S37, and if the cumulative amount has not reached the target amount, the process proceeds to step S371.

[0069] Step S37: The distribution unit 123 notifies the creator user i that the accumulated amount of support funds has reached the target amount and the posting deadline by sending the notification to the email address registered in the user table 132, and then proceeds to the next step S38. This allows the creator user i to understand that an obligation to post (a condition for receiving a reward) has arisen.

[0070] Step S371: The distribution unit 123 notifies the creator user i that the accumulated amount of support funds did not reach the target amount by the deadline for collection and that the posting deadline has been lifted by sending a message to the email address registered in the user table 132, and then proceeds to step S391. This allows the creator user i to understand that the obligation to post (the condition for receiving a reward) has been lifted.

[0071] Step S38: The distribution unit 123 refers to the content table 133 to determine whether or not the posting deadline for the nth episode has passed, and if it has not passed, it waits, and if it has passed, it moves to the next step S39.

[0072] Step S39: The distribution unit 123 refers to the content table 133 to determine whether or not the (n+1)th episode has been posted. If it has been posted, the process proceeds to the next step S391. If it has not been posted, the process proceeds to step S392.

[0073] Step S391: The distribution unit 123 refers to the support history table 134 and the settlement table 135 to calculate the accumulated amount of support money for the nth episode, and then records the amount obtained by subtracting the management fee from the accumulated amount as the sales of the producer user i in the user table 132.

[0074] Step S392: The distribution unit 123 refers to the support history table 134 and the payment table 135 to identify all viewer users j who supported episode n and the amount of support money paid by each of those viewer users j, and requests the payment server 30 to refund those support moneys to the viewer users j, and then proceeds to the next step S393.

[0075] Step S393: The distribution unit 123 determines whether or not a completion notice of the refund process (negative settlement process) has been received from the settlement server 30, and if not, waits, but if received, proceeds to the next step S394.

[0076] Step S394: The distribution unit 123 updates the payment table 135 by writing the ID, payment amount, and payment date and time of the viewer user j related to the negative payment. The distribution unit 123 also updates the support history table 134 by writing information on the negative support history (refund history) corresponding to the negative payment. The distribution unit 123 also subtracts the sales amount corresponding to the accumulated amount of the nth episode from the sales of the producer user i in the user table, and proceeds to the next step S395.

[0077] Step S395: The distribution unit 123 increments the value of the number of episodes n, and then proceeds to step S32.

[0078] The order of steps S31 to S395 can be changed as appropriate within the scope of not impairing the function of distribution unit 123.

[0079] 11. Settlement flow The flow of the clearing process will be described below. Figure 11 is a flowchart for explaining the operation of the distribution unit (during clearing). As shown in FIG. 11, the distributor 123 executes the following steps S396 to S398.

[0080] Step S396: The distribution unit 123 determines whether or not a predetermined closing date, such as the end of the month, has arrived, and if it has not arrived, waits, but if it has arrived, proceeds to the next step S397.

[0081] Step S397: The distribution unit 123 refers to the sales of each user written in the user table 132, executes a process of transferring the remuneration, the amount of which is the sales minus a predetermined remittance fee (bank transfer fee), to the remittance destination of the creator user i registered in advance in the user table 132, and then proceeds to the next step S398. Note that the process of transferring money to a bank account or the like designated in advance by the creator user i is well known, so a description thereof will be omitted here.

[0082] Step S398: The distributor 123 resets the sales amount in the user table 132 and then returns to step S396.

[0083] 12. Effects of the embodiment As explained above, the serialization management server 10, serialization management system 100, and serialization management program 131 according to this embodiment accept financial support from the terminal 50-j of the viewer user j for the nth episode of serialized manga content (S23) and pay the corresponding remuneration to a remittance destination designated in advance by the creator user i (S391, S397), so that the more support the viewer user j provides, the more funds the creator user i can allocate to the production costs of the latest episode. Thus, it is possible to encourage support from the viewer user j who is eagerly awaiting the posting of the latest episode. However, if the latest episode is not posted by the posting deadline (S39NO), the reward is not paid to creator user i and the support money is returned to viewer user j (S392-S394). Therefore, creator user i who desires the reward can be encouraged to post the latest episode. As a result of the above, the serialization management server 10, serialization management system 100, and serialization management program 131 according to this embodiment can involve viewer user j in promoting the serialization and can also return profits generated during the serialization to creator user i, thereby creating a virtuous cycle of support and serialization.

[0084] Moreover, in the serialization management server 10, serialization management system 100, and serialization management program 131 according to this embodiment, if the cumulative amount of support funds does not reach the target amount by the deadline for collection (S36NO), no refund is made to the viewer user j even if the latest episode is not posted by the posting deadline (S371, S391), so the viewer user j who provides support is also conscious of wanting the cumulative amount to reach the target amount as soon as possible. This can encourage the viewer user j who provides support to provide stronger support, and it is thought that collection of support funds can be accelerated. And when collection is accelerated, the creator user i's motivation for production is stimulated, and an increase in the production speed of the latest episode can be expected. As a result, the serialization management server 10, serialization management system 100, and serialization management program 131 according to this embodiment of the present invention can achieve a further virtuous cycle of support and serialization.

[0085] 13. Supplementary information on display format In the above embodiment or modified example, when the recruitment deadline or posting deadline is made public, the number of days remaining until the deadline may be displayed. In the above embodiment or modified example, when the accumulated amount of support money is made public, the achievement rate of the accumulated amount with respect to the target amount (target achievement rate) may be displayed. In addition, in the above embodiment or modified example, the remaining days or the goal achievement rate can be displayed by text (such as XX days, XX%) or by graphs (such as bar graphs or pie charts).

[0086] 14. Currency Variations In the above embodiment or variant, currency is used to pay the support money, but it goes without saying that currency usable on the platform (serial management system 100), points, coupons, or other exchange means may be used instead of or in addition to currency.

[0087] 15. Modifications to Content The product (or service) handled by the serialization management system 100 in the above-described embodiment or modified example is serialized manga content (or the provision thereof), but it may be other serialized digital content (or the provision thereof). The "serialized digital content" referred to here includes serialized e-book content (manga content, novel content, magazine content, etc.), serialized audio content (novel audiobooks, magazine audiobooks, etc.), serialized game content, and serialized video content with audio (animation content, serial drama content, etc.), which are composed of data that can be made public on the network 40.

[0088] 16. Changes in the scope of support content In the serialization management system 100 of the embodiment or variant example described above, the range of serialized content eligible for support is the range of serialized content that can be viewed by registered users (both creator users i and viewer users j), but this is not limited to this and may be narrowed down to, for example, the range of serialized content that can be viewed by registered users, particularly paying users who have paid membership fees.

[0089] 17. Variations in the division of functions Furthermore, in the serialization management system 100 of the above-described embodiment or modified example, the information stored in the memory unit 13 may be divided and stored in multiple storage devices, or some or all of the information stored in the memory unit 13 may be stored on the data server 20 side. In the serialization management system 100 of the above-described embodiment or modification, at least a part of the functions of the data server 10 or the settlement server 30 may be installed on the serialization management server 10 side. Furthermore, in the serialization management system 100 of the above-described embodiment or modified example, at least a portion of the functions of the serialization management server 10 may be mounted on the data server 10 or the settlement server 30 side, or may be mounted on a separate server. In the serialization management system 100 of the above-described embodiment or modification, part of the functions of the serialization management server 10 may be installed on the terminals 50-1, 50-1, . . . .

[0090] 18. Accounting In the above-described embodiment or modified example, the closing date (S396) is common to all creator users i, but a closing date may be set for each creator user i. In addition, in the above-described embodiment or variant embodiment, the closing date (S396) is a predetermined date, but it may also be a date designated in advance by each creator user i, or it may be the timing when creator user i takes a specific action (e.g., issuing a settlement request, issuing a posting request, etc.). Furthermore, in the above-described embodiment or variant, when the operator of the serialization management server 10 receives a donation from the viewer user j, the operator collects a portion of the donation as a management fee, and when paying the reward to the creator user i, the operator collects a portion of the sales as a remittance fee. However, the method of collecting the fee (such as the name of the fee) is not limited to this, and any known method may be adopted.

[0091] 19.Other The present invention is not limited to the above-described embodiment or modification, and can be embodied by appropriately modifying the components without departing from the spirit of the present invention. In addition, various inventions can be formed by appropriately combining the multiple components disclosed in each embodiment. [Explanation of symbols]

[0092] 100 Serialization Management System 1 User 2. Users 3 Users 4. Users 10 Serialization Management Server 20 Data Server 30 Payment Server 40 Network 50-1 Terminal 50-2 Terminal 50-3 Terminal 50-4 Terminal 50-5 Terminal 50-6 Terminal 11 Communications Department 12 Control section 121 Submission Reception Department 122 Donation Reception Department 123 Distribution section 13 Storage section 131 Serialization Management Program 132 User Table 133 Table of Contents 134 Support History Table 135 Settlement Table

Claims

1. A serialization management server for managing serialization of serialized digital content, a support money receiving unit that executes a process of receiving a support money from the viewer for a first range of the serialized digital content that has been released; a distribution unit that executes a process of determining whether a second range, which is a continuation of the first range, has been posted by a posting deadline, and if the second range has been posted by the posting deadline, pays a reward according to the accumulated amount of the support money to the creator of the serialized digital content, and if the second range has not been posted by the posting deadline, refunds the support money to the viewer; A serialization management server comprising:

2. 2. The serialization management server according to claim 1, The distribution unit includes: If the accumulated amount of the support money does not reach the target amount by the deadline for collection, a process is executed to pay the reward to the creator regardless of whether or not there is a post in the second range.

4. A serialization management server comprising:

3. The sales support server according to claim 2, The distribution unit includes: If the accumulated amount of the support money reaches the target amount during the period from the submission of the first range to the deadline for collection, a process is executed to notify the creator of the fact and the deadline for submission.

4. A serialization management server comprising:

4. The sales support server according to claim 2, The distribution unit includes: If the cumulative amount of the support money does not reach the target amount during the period from the submission of the first range to the deadline for collection, a process is executed to notify the creator of that fact and that the submission deadline has been lifted.

4. A serialization management server comprising:

5. 3. The serialization management server according to claim 2, a submission receiving unit that receives submissions within the first range from the creator and receives from the creator at least one of the collection deadline, the target amount, and the submission deadline.

4. A serialization management server comprising:

6. 6. The serialization management server according to claim 5, The submission reception unit, Execute a process of disclosing to the viewers at least one of the collection deadline, the target amount, the posting deadline, and the accumulated amount together with the first range.

4. A serialization management server comprising:

7. 2. The serialization management server according to claim 1, The serialized digital content is serialized manga content.

4. A serialization management server comprising:

8. A serialization management server according to any one of claims 1 to 7; a data server that stores each range of the serialized digital content posted by the creator; A serialization management system comprising:

9. A computer-readable serialization management program for causing a computer to function as the serialization management server according to claim 1, A process of accepting financial contributions from the viewers for a first range of the serialized digital content that has been released; executing a process of determining whether a second range, which is a continuation of the first range, has been posted by a posting deadline, and if the second range has been posted by the posting deadline, paying a reward according to the accumulated amount of the support money to the creator of the serialized digital content, and if the second range has not been posted by the posting deadline, refunding the support money to the viewer; A computer-readable serialization management program for causing a computer to execute the above steps.

Images