System, program, and method for storing information about second user

Abstract

To provide a system, a program, and a method for managing information of others without using their IDs.SOLUTION: A system includes: a user terminal 3 of a first user; a first server 1 for accepting information about the first user from the user terminal 3 of the first user and storing information about the first user and an ID of the first user; and a second server 2 for receiving information about a second user from the user terminal 3 of the first user, generating a temporary ID of the second user, and storing the temporary ID, the information about the second user, and the ID of the first user for managing information about the second user, thereby associating the temporary ID of the second user with the ID of the first user.SELECTED DRAWING: Figure 3

Description

[Technical field]

[0001] The present invention relates to a system, program and method for storing information about a second user. [Background technology]

[0002] Conventionally, information such as a customer's purchase history, credit card usage history, etc. has been stored in a web server. Some such web servers allow customers to view their own purchase history, etc., and provide services according to the purchase amount (for example, see Patent Document 1).

[0003] The invention described in Patent Document 1 is as follows: A customer who wishes to view purchase history or the like on a web server accesses the web server, enters an ID and password on a login screen, and sends the ID and password to the server by pressing a login button, etc. The server authenticates the customer by verifying that the ID and password received from the customer match those registered in advance.

[0004] Once authenticated, the customer is able to view his or her purchase history and receive services. [Prior art documents] [Patent documents]

[0005] [Patent Document 1] JP 2002-203181 A Summary of the Invention [Problem to be solved by the invention]

[0006] Incidentally, for example, when a guardian wants to view or use information about his / her child, there is a need for the authority to manage information of others (the authority to access, view, update, delete, or use information) rather than his / her own information. However, with conventional methods, in order to manage information of others, the user must enter the ID and password of the other person (for example, the child) on a login screen and log in as the other person, which is troublesome.

[0007] In view of the above problems, an object of the present invention is to provide a system, a program, and a method for managing information about other people without using their IDs. [Means for solving the problem]

[0008] The above object of the present invention can be achieved by the following means. Note that the parentheses indicate reference symbols of the embodiments described below, but the present invention is not limited thereto.

[0009] The system according to claim 1 comprises: A system for storing information about a second user (e.g., nickname tbl_Bb, date of birth tbl_Bc, card number tbl_Be shown in FIG. 2(b), usage history tbl_Cb, points tbl_Cc shown in FIG. 2(c), purchase history tbl_Db, and product details tbl_Dc shown in FIG. 2(d)), A user terminal of a first user (for example, the user terminal 3 of the guardian A shown in FIG. 1 ); Information about the first user (for example, name tbl_Ab, telephone number tbl_Ac, email address tbl_Ad, date of birth tbl_Ae, address tbl_Af, and password tbl_Ag shown in FIG. 2(a)) is received from the user terminal of the first user (for example, user terminal 3 of guardian A shown in FIG. 1) (for example, step S11 shown in FIG. 3); Store information about the first user (for example, name tbl_Ab, telephone number tbl_Ac, email address tbl_Ad, date of birth tbl_Ae, address tbl_Af, and password tbl_Ag shown in FIG. 2(a)) and the ID of the first user (for example, ID tbl_Aa shown in FIG. 2(a)) (for example, step S12 shown in FIG. 3); A first computer (e.g., a first server 1 shown in FIG. 1 ); At least a part of the information about the second user (for example, the nickname tbl_Bb, the date of birth tbl_Bc, and the card number tbl_Be shown in FIG. 2(b)) is received from the user terminal of the first user (for example, the user terminal 3 of the guardian A shown in FIG. 1) (for example, step S1 shown in FIG. 3); A temporary ID (e.g., temporary IDtbl_Ba shown in FIG. 2(b)) of the second user is generated (e.g., step S2 shown in FIG. 3), The temporary ID (e.g., temporary IDtbl_Ba shown in FIG. 2(b)), at least a part of the information about the second user (e.g., nicknametbl_Bb, date of birthtbl_Bc, and card numbertbl_Be shown in FIG. 2(b)), and the ID of the first user who manages the information about the second user (e.g., guardian's IDtbl_Bf shown in FIG. 2(b)) are stored, thereby associating the temporary ID of the second user (e.g., temporary IDtbl_Ba shown in FIG. 2(b)) with the ID of the first user (e.g., guardian's IDtbl_Bf shown in FIG. 2(b)) (e.g., step S3 shown in FIG. 3); A second computer (e.g., the second server 2 shown in FIG. 1 ); The present invention is characterized in that it comprises:

[0010] The program according to claim 2 comprises: A program for storing information about a second user (for example, nickname tbl_Bb, date of birth tbl_Bc, card number tbl_Be shown in FIG. 2(b), usage history tbl_Cb, and points tbl_Cc shown in FIG. 2(c), A computer (for example, the second server 2 shown in FIG. 1) A step of generating a temporary ID (e.g., a temporary ID tbl_Ba shown in FIG. 2(b)) of the second user based on at least a part of information about the second user (e.g., a nickname tbl_Bb, a date of birth tbl_Bc, and a card number tbl_Be shown in FIG. 2(b)) (e.g., step S2 shown in FIG. 3); The method is characterized in that the method executes a step (e.g., step S3 shown in FIG. 3) of associating the temporary ID of the second user (e.g., temporary IDtbl_Ba shown in FIG. 2(b)) with the ID of the first user (e.g., guardian IDtbl_Bf shown in FIG. 2(b)) by storing the temporary ID (e.g., temporary IDtbl_Ba shown in FIG. 2(b)), at least a portion of the information about the second user (e.g., nickname tbl_Bb, date of birth tbl_Bc, card number tbl_Be shown in FIG. 2(b)), and the ID of the first user who manages the information about the second user (e.g., guardian IDtbl_Bf shown in FIG. 2(b)).

[0011] The program according to claim 3 is the program according to claim 2, When a request for processing information regarding the second user (for example, nickname tbl_Bb, date of birth tbl_Bc, card number tbl_Be, usage history tbl_Cb, and points tbl_Cc shown in Figure 2(b)) is received, the computer (for example, second server 2 shown in Figure 1) is further caused to execute a step (for example, step S5 shown in Figure 3) of permitting the requested processing only if the request is from the first user identified by the ID of the first user (for example, guardian ID tbl_Bf shown in Figure 2(b)) associated with the temporary ID of the second user (for example, temporary ID tbl_Ba shown in Figure 2(b)).

[0012] The program according to claim 4 is the program according to claim 2, When a request for processing information regarding the second user (for example, nickname tbl_Bb, date of birth tbl_Bc, card number tbl_Be, usage history tbl_Cb, and points tbl_Cc shown in Figure 2(b)) is received, if the request is from a person authorized by the first user (for example, ID authorized for viewing tbl_Bg shown in Figure 2(b)) identified by the ID of the first user (for example, guardian ID tbl_Bf shown in Figure 2(b)) associated with the temporary ID of the second user (for example, temporary ID tbl_Ba shown in Figure 2(b)), the computer (for example, second server 2 shown in Figure 1) is further caused to execute a step of authorizing the requested processing (for example, step S6 shown in Figure 3).

[0013] The program according to claim 5 is the program according to claim 2, The information about the first user (e.g., name tbl_Ab, telephone number tbl_Ac, email address tbl_Ad, address tbl_Af shown in FIG. 2(a)) stored in association with the ID of the first user (e.g., ID tbl_Aa shown in FIG. 2(a)) in a predetermined storage device (e.g., the first server 1 shown in FIG. 1) includes information that allows a third party to identify the first user. The information regarding the second user (e.g., nickname tbl_Bb, date of birth tbl_Bc, card number tbl_Be shown in FIG. 2(b), usage history tbl_Cb, and points tbl_Cc shown in FIG. 2(c)) stored in the computer (e.g., second server 2 shown in FIG. 1) is characterized in that it does not include information that would enable a third party other than the first user to identify the second user.

[0014] The program according to claim 6 is the program according to claim 2. The information regarding the second user is characterized in that it includes information regarding actions performed by the first user on behalf of the second user (e.g., purchase history tbl_Db shown in FIG. 2(d)) or actions performed by the second user (e.g., usage history tbl_Cb shown in FIG. 2(c)), or benefits obtained as a result of the actions (e.g., points tbl_Cc shown in FIG. 2(c)).

[0015] The program according to claim 7 is the program according to claim 6, The method further comprises causing the computer (e.g., the second server 2 shown in FIG. 1) to execute a step of permitting the use of the benefit (e.g., points tbl_Cc shown in FIG. 2(c)) only to the first user identified by the first user's ID (e.g., guardian's ID tbl_Bf shown in FIG. 2(b)) associated with the second user's temporary ID (e.g., temporary ID tbl_Ba shown in FIG. 2(b)).

[0016] The program according to claim 8 is the program according to claim 6, When the specified requirements are met, a consent request is sent to the user terminal of the first user (for example, the user terminal 3 of guardian A shown in FIG. 1) (for example, message 38a shown in FIG. 6(a), step S7). When approval is received from the user terminal of the first user (for example, the user terminal 3 of guardian A shown in FIG. 1), the computer (for example, the second server 2 shown in FIG. 1) is further caused to execute a step (for example, step S8 shown in FIG. 3) of disassociating the ID of the first user (for example, the guardian's ID tbl_Bf shown in FIG. 2(b)) with the temporary ID of the second user (for example, the temporary ID tbl_Ba shown in FIG. 2(b)) so that the first user cannot manage information about the second user (for example, the nickname tbl_Bb, date of birth tbl_Bc, card number tbl_Be shown in FIG. 2(b), usage history tbl_Cb, and points tbl_Cc shown in FIG. 2(c)).

[0017] The method according to claim 9, A method for storing information about a second user (for example, nickname tbl_Bb, date of birth tbl_Bc, card number tbl_Be shown in FIG. 2(b), usage history tbl_Cb, and points tbl_Cc shown in FIG. 2(c)), A step of accepting at least a part of information regarding the second user (for example, a nickname tbl_Bb, a date of birth tbl_Bc, and a card number tbl_Be shown in FIG. 2(b)) (for example, step S1 shown in FIG. 3); A step of generating a temporary ID of the second user (for example, a temporary ID tbl_Ba shown in FIG. 2(b)) (for example, step S2 shown in FIG. 3); The method further comprises a step (e.g., step S3 shown in FIG. 3) of associating the temporary ID of the second user (e.g., temporary IDtbl_Ba shown in FIG. 2(b)) with the ID of the first user (e.g., guardian IDtbl_Bf shown in FIG. 2(b)) by storing at least a portion of the information about the second user (e.g., nickname tbl_Bb, date of birth tbl_Bc, card number tbl_Be shown in FIG. 2(b)), the ID of the first user who manages the information about the second user (e.g., guardian IDtbl_Bf shown in FIG. 2(b)), and the temporary ID (e.g., temporary IDtbl_Ba shown in FIG. 2(b)). Effect of the Invention

[0018] Next, the effects of the present invention will be described with reference to the drawings. Note that the reference symbols in the parentheses are those of the embodiments described below, but the present invention is not limited thereto.

[0019] According to the invention of claims 1, 2 and 9, a second computer / computer (e.g., the second server 2 shown in FIG. 1) can identify information about a second user managed by a first user when given the ID of a first user (e.g., IDtbl_Aa shown in FIG. 2(a)) without being given the temporary ID of the second user (e.g., temporary IDtbl_Ba shown in FIG. 2(b)).

[0020] Therefore, by displaying information about the second user identified by the second computer / computer (e.g., the second server 2 shown in FIG. 1) on the first user terminal (e.g., the first user terminal 3 shown in FIG. 1) (see, for example, the display unit 3e shown in FIG. 4(b)), the first user can easily recognize the information about the second user that he or she manages.

[0021] Therefore, according to the present invention, as long as one is aware of one's own ID (for example, IDtbl_Aa shown in FIG. 2(a)), it becomes easy to manage information regarding the second user (for example, nickname tbl_Bb, date of birth tbl_Bc, card number tbl_Be shown in FIG. 2(b), usage history tbl_Cb and points tbl_Cc shown in FIG. 2(c)) without using the second user's temporary ID (for example, temporary IDtbl_Ba shown in FIG. 2(b)).

[0022] According to the invention of claim 3, only the first user can cause the second server 2 to execute processes such as viewing (see, for example, the "View registered information" button 33a and the "View usage history" button 33b shown in FIG. 4(d)), updating, deleting (see, for example, the "Detach / Delete" button 33c shown in FIG. 4(d)) information about the second user (for example, the nickname tbl_Bb, date of birth tbl_Bc, card number tbl_Be shown in FIG. 2(b), and the usage history tbl_Cb and points tbl_Cc shown in FIG. 2(c)), or using that information (see, for example, the "Assign to card" button 33e and the "Assign to card" button 33e shown in FIG. 4(d)). Therefore, the second user or others cannot perform these processes without permission.

[0023] According to the invention of claim 4, a person authorized by the first user (for example, ID tbl_Bg authorized to be viewed as shown in FIG. 2(b)) can also have the second server 2 execute processes such as viewing (for example, see the “View registered information” button 33a and the “View usage history” button 33b shown in FIG. 4(d)), updating, deleting (for example, see the “Detach / Delete” button 33c shown in FIG. 4(d)), or using the information (for example, see the “Assign to card” button 33e and the “Assign to card” button 33e shown in FIG. 4(d)). Therefore, information regarding the second user (for example, nickname tbl_Bb, date of birth tbl_Bc, card number tbl_Be shown in FIG. 2(b), usage history tbl_Cb, and points tbl_Cc shown in FIG. 2(c)) can be managed together with a person authorized by the first user.

[0024] According to the invention of claim 5, the burden of security measures on a computer (for example, the second server 2 shown in FIG. 1) can be reduced. That is, a predetermined storage device (for example, the first server 1 shown in FIG. 1) that stores information about a first user needs to take high-level security measures to prevent information leakage, but a computer (for example, the second server 2 shown in FIG. 1) that stores information about a second user does not contain information that can identify an individual, so a lower level of security measures can be adopted.

[0025] According to the invention of claim 6, by storing the information as belonging to the second user rather than the first user (see, for example, the usage history tbl_Cb shown in FIG. 2(c) and the purchase history tbl_Db shown in FIG. 2(d)), even if the association between the first user and the second user is released (see FIG. 6), the information stored up to that point can be recognized as information about the second user.

[0026] According to the invention of claim 7, only the first user can use the benefits stored as information about the second user (e.g., points tbl_Cc shown in FIG. 2(c)), so that the second user or any other person will not use them without permission.

[0027] According to the invention of claim 8, if a certain requirement is satisfied, the first user cannot manage information about the second user, and the second user can independently manage information about the second user. Moreover, information about the actions taken by the first user for the second user (e.g., purchase history tbl_Db shown in FIG. 2(d)), the actions taken by the second user (e.g., usage history tbl_Cb shown in FIG. 2(c)), and the benefits based on those actions (e.g., points tbl_Cc shown in FIG. 2(c)) are stored as information about the second user. Therefore, even if the association between the guardian's ID (e.g., IDtbl_Aa shown in FIG. 2(a)) and the temporary ID of the second user (e.g., temporary IDtbl_Ba shown in FIG. 2(b)) is released (see FIG. 6), the information can still be used as information about the second user. [Brief description of the drawings]

[0028] [Figure 1] FIG. 1 is a block diagram illustrating one embodiment of a system according to the present invention. [Diagram 2] FIG. 1A is a diagram for explaining a table stored in a database of a first server, and FIGS. 1B and 1C are diagrams for explaining tables stored in a database of a second server. [Diagram 3] FIG. 11 is a flowchart showing an example of use of the system according to the embodiment. [Figure 4] These figures show the screens of an application used by a guardian on a terminal in the same embodiment, where (a) shows the screen that is displayed when the application is launched, (b) shows the screen for selecting a child, (c) shows the screen that displays the child's registration information, and (d) shows the screen for selecting an operation to be performed on information about the child. [Diagram 5]These are figures showing the application screens used by a guardian on a terminal, where (a) shows the screen displayed when the “View usage history” operation is selected in FIG. 4(d), (b) shows the screen displayed when the “Delete” operation is selected in FIG. 4(d), (c) shows the screen displayed when the “Use points” operation is selected in FIG. 4(d), and (d) shows the screen displayed when the “Add to card” operation is selected in FIG. 4(d). [Figure 6] FIG. 13 shows an email that a parent receives on a terminal. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0029] Hereinafter, as an embodiment of the system for storing information about second users according to the present invention, a specific description will be given with reference to the drawings, taking as an example a case where information about children in a specific play facility is stored. Note that in the following description, when directions such as up, down, left, and right are indicated, they refer to up, down, left, and right as viewed from the front of the figure.

[0030] <System Overview> 1, in this embodiment, a first server 1, a second server 2, a user terminal 3 of a guardian A, and a user terminal 4 of a guardian B are connected via a network N. Each component will be described below.

[0031] Parent A (see FIG. 1) who owns user terminal 3 is the person who uses the system according to this embodiment to manage the information of two children (see FIGS. 2(b) and (c)) at a specific play facility. Furthermore, parent B (see FIG. 1) who owns user terminal 4 is the person who, with permission from parent A, views the information of the two children (see FIGS. 2(b) and (c)).

[0032] <First server> As shown in FIG. 1, the first server 1 is composed of a data processing unit 10 that processes various types of data, a communication unit 11 that can connect to a network N via communication means such as wireless LAN, wired LAN, dial-up, etc., and a database 12.

[0033] Incidentally, the database 12 shown in Fig. 1 stores a permanent registration table tbl_A as shown in Fig. 2(a). This permanent registration table tbl_A stores information about guardian A and guardian B (see Fig. 1). More specifically, as shown in Fig. 2(a), ID tbl_Aa, name tbl_Ab, telephone number tbl_Ac, email address tbl_Ad, date of birth tbl_Ae, address tbl_Af, password tbl_Ag, and temporary ID tbl_Ah are stored.

[0034] It should be noted that IDtbl_Aa is an ID that uniquely identifies a record in this registration table tbl_A.

[0035] Furthermore, this official registration table tbl_A may be a database dedicated to the system according to this embodiment, or may be a shared database that can be referenced by a plurality of services or companies.

[0036] In addition, this official registration table tbl_A includes information that allows a third party to identify an individual, such as name tbl_Ab, telephone number tbl_Ac, email address tbl_Ad, and address tbl_Af, as shown in Fig. 2(a). Therefore, the first server 1 shown in Fig. 1 needs to take advanced security measures to prevent information leakage.

[0037] The temporary IDtbl_Ah will be described later.

[0038] <Second Server> As shown in FIG. 1, the second server 2, like the first server 1, is made up of a data processing unit 20, a communication unit 21, and a database 22.

[0039] Incidentally, the database 22 shown in FIG. 1 stores a child table tbl_B and a usage history table tbl_C as shown in FIGS. 2(b) and (c).

[0040] First, the child table tbl_B shown in Fig. 2(b) will be explained. This child table tbl_B stores information about children managed by guardian A. More specifically, as shown in Fig. 2(b), temporary ID tbl_Ba, nickname tbl_Bb, date of birth tbl_Bc, card number tbl_Be, guardian ID tbl_Bf, and ID of guardian etc. permitted to view tbl_Bg are stored.

[0041] The temporary ID tbl_Ba is a temporary ID that uniquely identifies a record in the child table tbl_B.

[0042] The card number tbl_Be is a card number for uniquely identifying an IC card for charging electronic money that can be used at a specific amusement facility. The balance of the card number tbl_Be is stored in a separate server (not shown).

[0043] The IDtbl_Bf of the guardian and the IDtbl_Bg of the guardian etc. permitted to view will be described later.

[0044] Next, the use history table tbl_C shown in Fig. 2(c) will be explained. This use history table tbl_C stores information about children's play at a specific play facility. More specifically, as shown in Fig. 2(c), a temporary ID tbl_Ca, a use history tbl_Cb, and points tbl_Cc are stored.

[0045] The temporary ID tbl_Ca stores information about which child in the child table tbl_B shown in FIG. 2(b) the usage history relates to.

[0046] The usage history tbl_Cb stores the usage history of what games a child played and when in a given amusement facility.

[0047] In addition, the points tbl_Cc stores the points acquired through playing.

[0048] It should be noted that the purchase history table tbl_D shown in FIG. 2(d) is a data table used to explain the modified example, and therefore will not be explained here.

[0049] As shown in Fig. 2(b) and (c), the child table tbl_B and the usage history table tbl_C do not contain information that would allow a third party other than the guardian to identify the child. Therefore, even if information were to leak from the second server 2 shown in Fig. 1, it would not immediately become a serious situation. As a result, the second server 2 shown in Fig. 1 can adopt low-level security measures, reducing the burden of security measures.

[0050] <Parent A's user device> The user terminal 3 of the guardian A is composed of a smartphone such as an iPhone (registered trademark), a mobile phone, or a PC (Personal Computer), as shown in Fig. 1. Specifically, as shown in Fig. 1, the user terminal 3 of the guardian A is composed of a CPU 3a, an input unit 3b that can input predetermined data from the outside to the user terminal 3 of the guardian A using a mouse, a keyboard, a touch panel, or a USB connector, a Lightning connector, etc., a ROM 3c consisting of a writable flash ROM or the like that stores predetermined application programs, etc., a RAM 3d that functions as a working area, a buffer memory, etc., a display unit 3e that can display various images, and a communication unit 3f that can be connected to the network N by communication means such as wireless LAN, wired LAN, dial-up, etc.

[0051] The user terminal 3 thus configured is used by a guardian A who manages information about his or her child.

[0052] <Parent B's user device> 1, the user terminal 4 of guardian B has the same configuration as the user terminal 3 of guardian A, so a description thereof will be omitted. The user terminal 4 is used by guardian B who views information about his / her child with permission from guardian A.

[0053] <Description of processing contents of the system for storing information about the second user> Next, the processing contents of the system for storing information about the second user shown in this embodiment will be described with reference to the flowchart shown in Fig. 3. For ease of understanding, the processing will be described in parts including storage of information about guardian A, storage of information about the child, permission for guardian A to perform processing, permission for guardian B to perform a specific processing, release of management of information about the child who has reached a specific age, and use of information about the child after the management is released.

[0054] <Memorizing information about parents> Using the user terminal 3 of the guardian A, the guardian A first registers information about the guardian in the first server 1 (see FIG. 1).

[0055] To register, first, guardian A uses guardian A's user terminal 3 (see FIG. 1) to transmit information about guardian A to the first server 1 (see FIG. 1) (step S101). More specifically, guardian A first taps an icon (not shown) displayed on the display unit 3e (see FIG. 1) of the user terminal 3 shown in FIG. 1. In response to this, the CPU 3a (see FIG. 1, hereinafter sometimes simply referred to as guardian A's user terminal 3) of guardian A's user terminal 3 starts up a member application (see FIGS. 4 to 6) stored in the ROM 3c (see FIG. 1). Then, guardian A taps the "Guardian Menu" button 30a displayed on the display unit 3e of the user terminal 3 shown in FIG. 4(a). As a result, a registration screen (not shown) is displayed on guardian A's user terminal 3 (see FIG. 1).

[0056] Guardian A inputs "Taro71" as the login ID, "Taro Ueda" as the name, "0353214567" as the phone number, "taro@abc.com" as the email address, "1976 / 7 / 1" as the date of birth, "Tokyo···" as the address, and ".dd5sdf3" as the password on the registration screen (not shown) displayed on guardian A's user terminal 3 (see FIG. 1). Finally, the "Send" button on the registration screen (not shown) is tapped or the like. This causes information about guardian A ("Taro71", "Taro Ueda", "0353214567", "taro@abc.com", "1976 / 7 / 1", "Tokyo···", ".dd5sdf3") to be sent from guardian A's user terminal 3 (see FIG. 1) to the first server 1 (see FIG. 1).

[0057] Then, the data processing unit 10 of the first server 1 (see FIG. 1; hereinafter, sometimes simply referred to as the first server 1) accepts information about parent A ("Taro71," "Taro Ueda," "0353214567," "taro@abc.com," "1976 / 7 / 1," "Tokyo...," ".dd5sdf3") (step S11).

[0058] Next, the first server 1 (see FIG. 1) stores information about guardian A together with guardian A's ID (step S12). More specifically, each piece of information sent by guardian A using guardian A's user terminal 3 (see FIG. 1) is stored in the ID tbl_Aa, name tbl_Ab, telephone number tbl_Ac, email address tbl_Ad, date of birth tbl_Ae, address tbl_Af, and password tbl_Ag of the main registration table tbl_A, as shown in FIG. 2(a).

[0059] As shown in FIG. 2(a), the permanent registration table tbl_A also has a temporary ID tbl_Ah prepared therein, but in the case of a guardian, nothing is stored here.

[0060] In this way, guardian A first registers information about the guardian in the first server 1 (see FIG. 1). When the second server 2 (see FIG. 1) notifies the guardian A that the registration is complete, the user terminal 3 (see FIG. 1) of guardian A temporarily stores the login ID "Taro71" of guardian A in the RAM 3d (see FIG. 1).

[0061] <Memorizing information about children> Next, guardian A registers information about the child using guardian A's user terminal 3. By registering information about the child, guardian A acquires authority to manage information about the child (authority to access, view, update, delete, or use information).

[0062] To register information about the first child, first, guardian A uses guardian A's user terminal 3 (see FIG. 1) to transmit information about the first child and guardian A's ID to the second server 2 (step S102). More specifically, first, guardian A taps or otherwise operates the "Child Management Menu" button 30b displayed on the display unit 3e of the user terminal 3 shown in FIG. 4(a). This causes the "Register New Child" button 31a to be displayed on the display unit 3e of the user terminal 3 as shown in FIG. 4(b). Note that at this point, the button 31b displaying "Yoshiko" and the button 31c displaying "Takashi" shown in FIG. 4(b) are not yet displayed.

[0063] Then, when guardian A taps or otherwise performs a "Register new child" button 31a shown in Fig. 4(b), a screen displaying information about the child is displayed on the display unit 3e of the user terminal 3 as shown in Fig. 4(c). More specifically, a "nickname" field 32a, a "date of birth" field 32b, and a "card number" field 32d are displayed on the display unit 3e of the user terminal 3. Note that at this point, the "temporary ID" 32e shown in Fig. 4(c) is not yet displayed.

[0064] Then, guardian A taps or otherwise inputs "Yoshiko", "2010 / 8 / 1", ​​and "315-741" into each field as shown in Fig. 4(c). Finally, he or she taps or otherwise inputs the "Register" button 32f shown in Fig. 4(c). As a result, guardian A's user terminal 3 (see Fig. 1) transmits "Yoshiko", "2010 / 8 / 1", ​​"315-741", and guardian A's ID "Taro71" temporarily stored in the RAM 3d of guardian A's user terminal 3 (see Fig. 1) to the second server 2 (see Fig. 1).

[0065] Next, the data processing unit 20 of the second server 2 (see FIG. 1; hereinafter, sometimes simply referred to as the second server 2) accepts information about the child and the ID of guardian A (step S1). More specifically, it receives "Yoshiko", "2010 / 8 / 1", ​​"315-741", and guardian A's ID "Taro71" sent by the user terminal 3 of guardian A.

[0066] Next, the second server 2 (see FIG. 1) automatically generates a temporary ID (step S2). More specifically, the second server 2 (see FIG. 1) generates an ID that can uniquely identify a record in the child table tbl_B shown in FIG. 2(b), for example, "456123" (see temporary ID tbl_Ba in FIG. 2(b)), based on the information about the child received from the user terminal 3 of the guardian A.

[0067] Next, the second server 2 (see FIG. 1) stores information about the child and the ID of guardian A together with the temporary ID (step S3). More specifically, the generated temporary ID "456123", the information about the child received from guardian A's user terminal 3 (see FIG. 1) ("Yoshiko", "2010 / 8 / 1", ​​"315-741"), and guardian A's ID "Taro71" are stored in the child table tbl_B shown in FIG. 2(b). As a result, the temporary ID "456123" and guardian A's ID "Taro71" are associated with each other.

[0068] In the manner described above, Parent A registers the first child in the second server 2 (see FIG. 1). Parent A can similarly register information about the second child.

[0069] When the registration of all the information about the child to be registered is completed, the second server 2 (see FIG. 1) then transmits a list of children to be managed to the user terminal 3 (see FIG. 1) of guardian A (step S4). More specifically, the second server 2 (see FIG. 1) identifies a record in which the guardian's ID tbl_Bf is "Taro71" from the child table tbl_B shown in FIG. 2(b). The user terminal 3 (see FIG. 1) of guardian A then receives the identified record from the second server 2 (see FIG. 1) and displays it on the display unit 3e of the user terminal 3 of guardian A as a button 31b displaying "Yoshiko" and a button 31c displaying "Takashi" as shown in FIG. 4(b).

[0070] In addition, parent A's user terminal 3 (see FIG. 1) temporarily stores in RAM 3d the temporary ID (456123) corresponding to button 31b displaying "Yoshiko" and the temporary ID (654321) corresponding to button 31c displaying "Takashi."

[0071] At the time when information about a child is registered, no data is stored in the IDtbl_Bg that is permitted to view the child table tbl_B shown in FIG. 2(b).

[0072] <Permission to process for Parent A> Next, we will explain how guardian A performs various processes on information about his / her child using guardian A's user terminal 3 (see FIG. 1). As shown in FIG. 4(d), the executable processes include "View registered information" (button 33a), "View usage history" (button 33b), "Delete" (button 33c), "Use points" (button 33d), and "Give to card" (button 33e). Since these processes have much in common, we will first explain "View registered information". We will then omit detailed explanations of the remaining processes and explain the similarities and differences with "View registered information".

[0073] <<Viewing registration information>> First, a description will be given of how parent A "views registered information" using parent A's user terminal 3 (see FIG. 1).

[0074] First, guardian A uses guardian A's user terminal 3 (see FIG. 1) to transmit a request for processing information related to the child and the guardian's ID to the second server 2 (see FIG. 1) (step S103).

[0075] More specifically, guardian A first taps or otherwise operates the "Child Management Menu" button 30b displayed on the display unit 3e of guardian A's user terminal 3 (see FIG. 1) shown in FIG. 4(a). As a result, as shown in FIG. 4(b), guardian A's user terminal 3 (see FIG. 1) displays buttons 31b displaying "Yoshiko" and buttons 31c displaying "Takashi," which indicate the children registered by guardian A, on the display unit 3e. Here, guardian A is assumed to tap or otherwise operate the button 31b displaying "Yoshiko."

[0076] In response to the tapping or the like of button 31b displaying "Yoshiko" as shown in Fig. 4(b), guardian A's user terminal 3 (see Fig. 1) temporarily stores in RAM 3d the fact that button 31b displaying "Yoshiko" has been tapped or the like. Then, as shown in Fig. 4(d), guardian A's user terminal 3 displays on display unit 3e a "View registered information" button 33a, a "View usage history" button 33b, a "Detach / Delete" button 33c, a "Use points" button 33d and a "Give to card" button 33e. Here, it is assumed that guardian A taps or the like on "View registered information" button 33a.

[0077] When the "View Registration Information" button 33a is tapped, the user terminal 3 of guardian A (see FIG. 1) reads guardian A's ID "Taro71" and the temporary ID "456123" corresponding to the button 31b displaying "Yoshiko" from the RAM 3d. Then, a request for "View Registration Information" is sent to the second server 2 together with the temporary ID "456123" and guardian A's ID "Taro71".

[0078] Next, the second server 2 (see FIG. 1) processes the request if it is the ID of guardian A (step S5). More specifically, the second server 2 (see FIG. 1) reads out the temporary ID "456123" from the information received from the user terminal 3 (see FIG. 1) of guardian A. The second server 2 (see FIG. 1) then searches the child table tbl_B shown in FIG. 2(b) for a record whose temporary ID tbl_Ba is "456123". From the record found, the second server 2 reads out the guardian's ID tbl_Bf "Taro71". Since the read out "Taro71" is equal to the ID of guardian A included in the information received from the user terminal 3 of guardian A, the second server 2 determines that the received request is a request from guardian A and permits the request to "view registered information" for the temporary ID "456123".

[0079] The second server 2 (see FIG. 1) does not permit the request if "Taro71" read from the guardian's ID tbl_Bf in the child table tbl_B shown in FIG. 2(b) is not equal to the guardian A's ID included in the information received from the guardian A's user terminal 3 (see FIG. 1). This allows only guardian A to make the second server 2 (see FIG. 1) execute the processes, so children and others cannot execute these processes without permission.

[0080] Upon receiving permission for the request to "view registration information", the second server 2 (see FIG. 1) reads "Yoshiko" (nickname tbl_Bb), "2010 / 8 / 1" (date of birth tbl_Bc), and "315-741" (card number tbl_Be) from the record with the temporary ID tbl_Ba of "456123" from the child table tbl_B shown in FIG. 2(b), and transmits them to the user terminal 3 (see FIG. 1) of the guardian A. Upon receiving the data from the second server 2 (see FIG. 1), the user terminal 3 (see FIG. 1) of the guardian A displays the data corresponding to the "nickname" column 32a, the "date of birth" column 32b, and the "card number" column 32d displayed on the display unit 3e, as shown in FIG. 4(c).

[0081] In this manner, Parent A can view the child's registration information as shown in FIG. 4(c).

[0082] <<Viewing usage history>> Next, a description will be given of how guardian A "views the usage history" using guardian A's user terminal 3 (see FIG. 1).

[0083] First, guardian A uses guardian A's user terminal 3 (see FIG. 1) to transmit a request for processing information about the child and the guardian's ID (step S103). This differs from viewing registered information in that guardian A taps or otherwise operates the "View usage history" button 33b, rather than the "View registered information" button 33a shown in FIG. 4(d). In response to guardian A's operation of tapping or otherwise operating the "View usage history" button 33b, guardian A's user terminal 3 transmits a request for viewing registered information, "View usage history", together with the temporary ID "456123" and guardian A's ID "Taro71", to the second server 2 (see FIG. 1).

[0084] Next, if the ID is that of guardian A, the second server 2 (see FIG. 1) processes the request accordingly (step S5). As with the viewing of registered information, the second server 2 (see FIG. 1) determines that the received request is a request from guardian A based on the information received from guardian A's user terminal 3 (see FIG. 1). Then, the second server 2 (see FIG. 1) processes the request based on the information received from guardian A's user terminal 3 (see FIG. 1). history Allow the "View" request.

[0085] "use history Upon receiving permission for the request to "view the game data", the second server 2 (see FIG. 1) searches for a record with the temporary ID tbl_Ba of "456123" from the usage history table tbl_C shown in FIG. 2(c), reads out "2023 / 8 / 3 Game A" "10", "2023 / 8 / 1 Game A" "30", and "2023 / 8 / 1 Game B" "25" (usage history tbl_Cb, points tbl_Cc), and transmits them to the user terminal 3 (see FIG. 1) of the guardian A. At this time, the second server 2 (see FIG. 1) calculates the total "65" from the read points "10", "30", and "25", and determines the rank to be "Silver" from a correspondence table (not shown) between points and ranks. Then, the information that the rank is "Silver" is also transmitted to the user terminal 3 (see FIG. 1) of the guardian A. When guardian A's user terminal 3 (see Figure 1) receives data from the second server 2 (see Figure 1), it displays data corresponding to "Usage History" 37a, "Acquired Points" 37b and "Rank" 37c on the display unit 3e, as shown in Figure 5(a).

[0086] The following methods can be considered as a method for accumulating the usage history and points.

[0087] That is, first, when a child plays a game machine (not shown) in a given amusement facility, the child inserts an IC card linked to the card number tbl_Be stored in the child table tbl_B shown in FIG. 2(b) into the game machine (not shown). As a result, the game machine (not shown) recognizes the card number, and after the game ends, transmits the recognized card number, the model of the game machine (not shown), the date of the game, and the acquired points to the second server 2 (see FIG. 1). The second server 2 (see FIG. 1) searches the child table tbl_B shown in FIG. 2(b) for the received card number, and reads out the temporary ID tbl_Ba of the found record. Then, the temporary ID tbl_Ba and the received information such as the model of the game machine (not shown) are stored in the usage history table tbl_C shown in FIG. 2(c).

[0088] In this way, information regarding children's play in a given play facility is stored in the use history table tbl_C shown in FIG. 2(c).

[0089] <<Erase>> Next, how guardian A performs "deletion" using guardian A's user terminal 3 (see FIG. 1) will be described.

[0090] First, guardian A uses guardian A's user terminal 3 (see FIG. 1) to transmit a request for processing information on the child and guardian A's ID (step S103). This differs from viewing registered information in that guardian A taps or otherwise operates the "Delete" button 33c instead of the "View registered information" button 33a shown in FIG. 4(d). In response to guardian A's operation of tapping or otherwise operating the "Delete" button 33c, guardian A's user terminal 3 (see FIG. 1) displays the "Delete data" button 34a on the display unit 3e of guardian A's user terminal 3 (see FIG. 1) as shown in FIG. 5(b). Then, as guardian A taps or otherwise operates the "Delete data" button 34a, guardian A's user terminal 3 transmits a "Delete" request to the second server 2 (see FIG. 1) together with the temporary ID "456123" and guardian A's ID "Taro71".

[0091] Next, the second server 2 (see FIG. 1) processes the request if it is parent A's ID (step S5). As with the viewing of registered information, the second server 2 (see FIG. 1) determines from the information received from parent A's user terminal 3 (see FIG. 1) that the received request is a request from parent A. Then, it permits the request to "delete" the temporary ID "456123".

[0092] Upon receiving permission for the "delete" request, the second server 2 (see FIG. 1) searches for a record with a temporary ID tbl_Ba of "456123" in the child table tbl_B shown in FIG. 2(b) and deletes the record. Once the deletion is complete, the user terminal 3 (see FIG. 1) of guardian A no longer displays the button 31b showing "Yoshiko" shown in FIG. 4(b).

[0093] <<Using points>>

[0094] Next, how guardian A uses guardian A's user terminal 3 (see FIG. 1) to "use points" will be described.

[0095] First, guardian A uses guardian A's user terminal 3 (see FIG. 1) to transmit a request for processing information about the child and the guardian's ID (step S103). This differs from viewing registered information in that guardian A taps, etc., on the "Use points" button 33d instead of the "View registered information" button 33a shown in FIG. 4(d). In response to guardian A's operation of tapping, etc., on the "Use points" button 33d, guardian A's user terminal 3 (see FIG. 1) displays a "Use points" field 35a on the display unit 3e of guardian A's user terminal 3 (see FIG. 1) as shown in FIG. 5(c). Then, parent A enters "200" into the "Points to be used" field 35a and taps, etc., the OK button 35b, causing parent A's user terminal 3 (see Figure 1) to send a request to "use points" along with the temporary ID "456123" and parent A's ID "Taro71", as well as the information "200 points to be used" to the second server 2 (see Figure 1).

[0096] Next, the second server 2 (see FIG. 1) processes the request if it is guardian A's ID (step S5). As with the viewing of registered information, the second server 2 (see FIG. 1) determines from the information received from guardian A's user terminal 3 (see FIG. 1) that the received request is a request from guardian A. Then, it permits the request to "use points" for the temporary ID "456123."

[0097] Upon receiving permission for the request to "use points," the second server 2 (see FIG. 1) searches for a record with a temporary ID tbl_Ba of "456123" from the child table tbl_B shown in FIG. 2(b) and reads out "315-741" (card number tbl_Be). The second server 2 (see FIG. 1) then sends an instruction to add an amount equivalent to "200 use points" to the balance of this card number "315-741," which is stored in another server (not shown).

[0098] <<Adding to a card>>

[0099] Next, a description will be given of how parent A performs "crediting to card" using parent A's user terminal 3 (see FIG. 1). Crediting to card refers to charging an IC card with electronic money that can be used at a specific amusement facility.

[0100] First, guardian A's user terminal 3 (see FIG. 1) transmits a request to process information about the child and the guardian's ID (step S103). This differs from viewing registered information in that guardian A taps or otherwise operates the "Give to card" button 33e instead of the "View registered information" button 33a shown in FIG. 4(d). In response to guardian A's operation of tapping or otherwise operating the "Give to card" button 33e, guardian A's user terminal 3 (see FIG. 1) displays the "Give Amount" field 36a on the display unit 3e of guardian A's user terminal 3 (see FIG. 1) as shown in FIG. 5(d). Then, guardian A enters "1,000" in the "Amount Granted" field 36a and taps the OK button 36b, etc., causing guardian A's user terminal 3 (see Figure 1) to send the temporary ID "456123", guardian A's ID "Taro71", a request for "granting to card", and the information "Amount Granted of 1,000" to the second server 2 (see Figure 1).

[0101] Next, the second server 2 (see FIG. 1) processes the request if it is guardian A's ID (step S5). As with the viewing of registered information, the second server 2 (see FIG. 1) determines from the information received from guardian A's user terminal 3 (see FIG. 1) that the received request is a request from guardian A. Then, the second server 2 (see FIG. 1) permits the request to "add to card" the temporary ID "456123".

[0102] Upon receiving permission for the request to "add to card," the second server 2 (see FIG. 1) searches for a record with a temporary ID tbl_Ba of "456123" from the child table tbl_B shown in FIG. 2(b) and reads out "315-741" (card number tbl_Be). The second server 2 then transmits an instruction to add "1,000" yen to the balance of this card number "315-741," which is stored in another server (not shown).

[0103] The second server 2 searches for the received ID of guardian A, "Taro71," in the main registration table tbl_A shown in Fig. 2(a) and then debits the 1,000 yen credited to the card from the bank account or the like (not shown) of guardian A linked to the found record.

[0104] <Permission to process specified request to Parent B> Next, a description will be given of a process in which guardian B uses guardian B's user terminal 4 (see FIG. 1) to request a specific process for the information on the child registered by guardian A. In this embodiment, the process that can be permitted to others is described as viewing.

[0105] First, guardian B uses guardian B's user terminal 4 (see FIG. 1) to request permission to view (step S111). More specifically, guardian B uses guardian B's user terminal 4 (see FIG. 1) to notify guardian A that he / she wishes to view information about the child managed by guardian A. This notification may be made by any method. For example, guardian B may contact guardian A by email or the like, providing guardian B's ID "HanakoU" (see ID tbl_Aa in the main registration table tbl_A shown in FIG. 2(a)) and the name of the child that he / she wishes to view.

[0106] Next, the user terminal 3 of the guardian A (see FIG. 1) gives permission for viewing to the guardian B (step S104). More specifically, the guardian A uses the user terminal 3 of the guardian A (see FIG. 1) to notify the second server 2 (see FIG. 1) that the guardian B is permitted to view. This notification may be made by any method. For example, the guardian A may input the temporary ID "456123" of the child that the guardian B wishes to view and the ID "HanakoU" notified from the user terminal 4 of the guardian B (see FIG. 1) on a predetermined screen (not shown) of the user terminal 3 of the guardian A (see FIG. 1), and tap a button (not shown) for permitting viewing. The guardian A can confirm the temporary ID 32e as shown in FIG. 4(c) by tapping the "View registered information" button 33a shown in FIG. 4(d) on the user terminal 3 of the guardian A (see FIG. 1).

[0107] When a button (not shown) permitting viewing is tapped, etc., parent A's user terminal 3 (see Figure 1) sends a request for "permission to view" along with the temporary ID "456123" and parent A's ID "Taro71", as well as the information "HanakoU" to the second server 2 (see Figure 1).

[0108] Next, if the ID is that of guardian A, the second server 2 (see FIG. 1) stores the viewing permission for guardian B (step S6). More specifically, similar to the viewing of registered information, the second server 2 (see FIG. 1) determines that the received request is a request from guardian A based on the information received from guardian A's user terminal 3 (see FIG. 1). Then, according to the information received from guardian A's user terminal 3 (see FIG. 1), the second server 2 (see FIG. 1) searches the child table tbl_B shown in FIG. 2(b) for a record with a temporary ID tbl_Ba of "456123", and stores guardian B's ID "HanakoU" in the ID tbl_Bg (see FIG. 2(a)) that is permitted to be viewed of the record found.

[0109] As described above, by storing parent B's ID "HanakoU" in the ID tbl_Bg that is permitted to view the child table tbl_B, parent B is permitted to view the record with the temporary ID tbl_Ba "456123" in the child table tbl_B shown in Figure 2(b) and the usage history table tbl_C shown in Figure 2(c).

[0110] Here, a method for guardian B to view information about a child will be described. First, guardian B taps an icon (not shown) displayed on the display unit 4e of guardian B's user terminal 4 (see FIG. 1). In response to this, the CPU 4a (see FIG. 1, hereinafter simply referred to as guardian B's user terminal 4) of guardian B's user terminal 4 starts up the member application (see FIGS. 4 to 6) stored in the ROM 4c. Then, guardian B logs in to the member application using his / her ID "HanakoU" and password "···" because guardian B has already registered as a member (see main registration table tbl_A shown in FIG. 2(a)). At this time, guardian B's ID is temporarily stored in the RAM 4d of guardian B's user terminal 4 (see FIG. 1).

[0111] Then, when the "Child Management Menu" button 40b (see FIG. 4(a)) displayed on the user terminal 4 of guardian B (see FIG. 1) is tapped, the user terminal 4 of guardian B (see FIG. 1) reads guardian B's ID "HanakoU" from the RAM 4d and inquires the second server 2 (see FIG. 1) about the child whose information guardian B manages together with this ID. The second server 2 (see FIG. 1) identifies a record in which the guardian's ID tbl_Bf or the ID tbl_Bg permitted to be viewed is "HanakoU" from the child table tbl_B shown in FIG. 2(b). The user terminal 4 of guardian B (see FIG. 1) receives the identified record from the second server 2 (see FIG. 1) and displays a button 41b displaying "Yoshiko" on the display unit 4e of the user terminal 4 of guardian B, as shown in FIG. 4(b).

[0112] Then, when guardian B taps or otherwise performs an action on button 41b displaying "Yoshiko" on guardian B's user terminal 4 (see FIG. 1), a "View registered information" button 43a and a "View usage history" button 43b are displayed on display unit 4e, as shown in FIG. 4(d). By tapping or otherwise performing an action on these buttons, information can be viewed. Note that the process performed when these buttons are tapped or otherwise performed is the same as when guardian A taps or otherwise performs an action on guardian A's user terminal 3 (see FIG. 1), and therefore a description thereof will be omitted.

[0113] This allows Parent A and Parent B to jointly manage information regarding their child.

[0114] <Cancellation of management of information on children who have reached a certain age> Next, a description will be given of releasing the management of information relating to a child when the child reaches a predetermined age.

[0115] First, the second server 2 (see FIG. 1) requests approval for the release of management because the child has reached a predetermined age (step S7). More specifically, the second server 2 (see FIG. 1) periodically checks whether the child has reached a predetermined age. More specifically, the second server 2 calculates the difference between the date of birth tbl_Bc in the child table tbl_B shown in FIG. 2(b) and the current date, and checks whether the child has reached a predetermined age (for example, 12 years old). When a record that has reached the predetermined age is found, the second server 2 reads out the guardian ID tbl_Bf "Taro71" of that record, and searches for a record with ID tbl_Aa "Taro71" in the main registration table tbl_A shown in FIG. 2(a). Then, to the email address tbl_Ad of the found record, an email is sent that includes a message 38a saying "Hanako has reached a predetermined age. Do you want to release management?", a field 38b for inputting the child's email address, and an "Allow" button 38c, as shown in FIG. 6.

[0116] Next, the user terminal 3 of the guardian A (see FIG. 1) transmits a notice of approval (step S105). More specifically, after reading the message 38a shown in FIG. 6, the guardian A inputs an email address in the field 38b for inputting the child's email address, and taps the "Allow" button 38c, etc. In response to this operation, the user terminal 3 of the guardian A (see FIG. 1) transmits the temporary ID "456123", the ID of the guardian A "Taro71", a request for "release of management", and the email address input in the field 38b for inputting the child's email address to the second server 2 (see FIG. 1) by a process preset in the "Allow" button 38c.

[0117] Next, the second server 2 (see FIG. 1) cancels the management (step S8). More specifically, an email containing a message urging the transfer of data to the permanent registration table tbl_A shown in FIG. 2(a), input fields for various information, and a button to approve the data transfer is sent to the child's email address received from the user terminal 3 (see FIG. 1) of guardian A (not shown). The various information includes the name, ID, password, phone number, address, etc. of the child whose management has been released.

[0118] Then, various information is input in the input field of the email on the child's terminal (not shown) and the send button is tapped or the like, whereby various information is transmitted from the child's terminal (not shown) to the second server 2 (see FIG. 1). As a result, the second server 2 (see FIG. 1) deletes the record of the temporary ID tbl_Ba "456123" from the child table tbl_B shown in FIG. 2(b) and registers a new record in the main registration table tbl_A shown in FIG. 2(a). That is, the temporary ID tbl_Ah of the main registration table tbl_A shown in FIG. 2(a) stores the temporary ID tbl_Ba "456123" of the child table tbl_B shown in FIG. 2(b). Then, the received information is stored in the ID tbl_Aa, name tbl_Ab, telephone number tbl_Ac, email address tbl_Ad, date of birth tbl_Ae, address tbl_Af, and password tbl_Ag. In addition, the guardian's ID tbl_Bf "Taro71" in the child table tbl_B shown in Figure 2(b) is not transferred to the main registration table tbl_A. Therefore, the association between the guardian A's ID and the child's temporary ID is released.

[0119] In this way, the release of management of information about a child who has reached a certain age is completed. In other words, the child who has been released from management will independently manage the information registered in the main registration table tbl_A shown in FIG. 2(a).

[0120] <Use of information about children after release of management> Incidentally, the information accumulated so far about the child whose information has been transferred to the permanent registration table tbl_A can be utilized. More specifically, the temporary ID tbl_Ah shown in FIG. 2(a) stores the temporary ID "456123" of the child whose information has been released. Therefore, the usage history of the play facility accumulated so far in the usage history table tbl_C shown in FIG. 2(c) can be linked to the child whose information has been transferred to the permanent registration table tbl_A. As a result, for example, the points and rank (see FIG. 5(a)) acquired so far at the play facility can be used as those of the child whose information has been transferred to the permanent registration table tbl_A. Also, the tastes of the child whose information has been transferred to the permanent registration table tbl_A can be understood from the "usage history" 37a, and can be utilized for sales promotions to the child whose information has been transferred to the permanent registration table tbl_A.

[0121] According to the present embodiment described above, as shown in Fig. 2(b), the temporary ID tbl_Ba and the guardian's ID tbl_Bf are stored in association with each other in the child table tbl_B. Therefore, if guardian A logs in using his / her own ID (guardian's ID tbl_Bf shown in Fig. 2(b)), the second server 2 can identify information about the child managed by guardian A without being given the child's temporary ID (temporary ID tbl_Ba shown in Fig. 2(b)).

[0122] Therefore, the second server 2 can display information regarding the identified child on the user terminal 3 of guardian A (see Figure 1) (see display unit 3e shown in Figure 4(b)), allowing guardian A to easily view information regarding the child under his or her management.

[0123] As described above, according to this embodiment, as long as guardian A's ID (IDtbl_Aa shown in Figure 2(a)) is known, it becomes easy to manage information about the child (nickname tbl_Bb, date of birth tbl_Bc, card number tbl_Be shown in Figure 2(b), usage history tbl_Cb and points tbl_Cc shown in Figure 2(c)) without logging in using the child's temporary ID (temporary IDtbl_Ba shown in Figure 2(b)).

[0124] <Description of Modifications> The system shown in this embodiment is merely an example, and various modifications and changes are possible within the scope of the gist of the present invention described in the claims. For example, in this embodiment, the guardian's ID consists of numbers and letters, and the child's temporary ID consists of numbers only, but the ID and temporary ID can be any identifier that uniquely identifies the record in the database. In addition, they may be automatically generated on the server side, or may be IDs determined by the user side.

[0125] In this embodiment, as shown in the usage history table tbl_C in Fig. 2(c), the history of when and with which game machine the child played at a specific amusement facility and the points acquired as a result are accumulated, but this is not limited to this. For example, as shown in the purchase history table tbl_D in Fig. 2(d), information such as products purchased by a guardian for his / her child at a specific commercial facility (purchase history tbl_Db in Fig. 2(d)) and details of the products (product details tbl_Dc in Fig. 2(d)) may be accumulated. As a method of accumulating such information, for example, the following method is conceivable.

[0126] That is, first, when purchasing a product for a child at a predetermined commercial facility, the guardian presents the temporary ID 32e displayed on the display unit 3e shown in FIG. 4(c) to an employee. Next, the employee enters the temporary ID "456123" into a computer and transmits it to the second server 2 (see FIG. 1) together with information on the purchased product, etc., "2023 / 5 / 1 Toys" and "Plastic Models". Finally, the second server 2 (see FIG. 1) receives this information and stores it in the purchase history table tbl_D as shown in FIG. 2(d).

[0127] In this way, the information accumulated in the purchase history table tbl_D as shown in Fig. 2(d) can continue to be used as information about the child even if the association between the guardian's ID (IDtbl_Aa shown in Fig. 2(a)) and the child's temporary ID (temporary IDtbl_Ba shown in Fig. 2(b)) is released. For example, the preferences of the child whose information has been transferred to the permanent registration table tbl_A can be understood from the purchase history table tbl_D, and this can be used for sales promotions for the child whose information has been transferred to the permanent registration table tbl_A.

[0128] In the present embodiment, the process that can be permitted to a third party is only viewing, but it is not limited to this. It may be "adding to a card" or "using points." In other words, anything is acceptable.

[0129] Moreover, the processes described in this embodiment as being performed by the second server 2 (see FIG. 1) may be implemented as appropriate in a member application installed in the user terminal 3 of the guardian A. [Explanation of symbols]

[0130] 1. First server (first computer, predetermined storage device) 2 Second Server (Second Computer, Computer) 3. Parent A's user terminal (first user's user terminal) tbl_Aa~tbl_Ah Information about parent A (information about the first user) tbl_Ba~tbl_Bg Information about children (information about second users) tbl_Ca~tbl_Cc Information about children (information about second users) tbl_Cb Usage history (information about the second user, information about actions taken by the second user) tbl_Cc Points (information about the second user, information about rewards obtained by actions) tbl_Db Purchase history (information about the second user, information about actions taken by the first user on behalf of the second user) tbl_Dc Product details (information about the second user, information about actions taken by the first user on behalf of the second user)

Claims

1. 1. A system for storing information about a second user, comprising: A user terminal of a first user; and receiving information about the first user from a user terminal of the first user; storing information about the first user and an ID of the first user; A first computer; and receiving at least a portion of information regarding the second user from a user terminal of the first user; generating a pseudo ID for the second user; storing the temporary ID, at least a part of information about the second user, and an ID of the first user who manages information about the second user, thereby associating the temporary ID of the second user with the ID of the first user; A second computer; and A system consisting of:

2. A program for storing information about a second user, On the computer, generating a provisional ID for the second user based on at least a portion of the information about the second user; A program that executes a step of associating the temporary ID of the second user with the ID of the first user by storing the temporary ID, at least a portion of the information regarding the second user, and the ID of the first user that manages the information regarding the second user.

3. The program of claim 2, further causing the computer to execute a step of, when receiving a request for processing information regarding the second user, allowing the requested processing only if the request is from the first user identified by the ID of the first user associated with the temporary ID of the second user.

4. The program of claim 2, further causing the computer to execute a step of permitting the requested processing when a request for processing information regarding the second user is received and the request is from a person authorized by the first user identified by the ID of the first user associated with the temporary ID of the second user.

5. The information about the first user that is stored in a predetermined storage device in association with the ID of the first user includes information that allows a third party to identify the first user, The program according to claim 2 , wherein the information about the second user stored in the second computer does not include information that would enable a third party other than the first user to identify the second user.

6. The program according to claim 2 , wherein the information about the second user includes information about an action taken by the first user for the second user or an action taken by the second user, or information about a benefit obtained by the action.

7. The program according to claim 6 , further causing the computer to execute a step of permitting use of the benefit only to a first user identified by an ID of the first user associated with a temporary ID of the second user.

8. The program of claim 6, further causing the computer to execute a step of sending an approval request to the user terminal of the first user when specified requirements are met, and upon receiving approval from the user terminal of the first user, disassociating the ID of the first user from the temporary ID of the second user so that the first user cannot thereafter manage information regarding the second user.

9. 1. A method for storing information about a second user, comprising: receiving at least a portion of information about the second user; generating a pseudo ID for the second user; A method comprising a step of associating the temporary ID of the second user with the ID of the first user by storing at least a portion of the information related to the second user, the ID of the first user who manages the information related to the second user, and the temporary ID.

Images