Management device, management method, and management program
The management system addresses the challenge of evaluating community member activities across DAO communities by using blockchain to share and verify activity records, optimizing evaluations and ensuring data quality through a decentralized autonomous organization management device.
Patent Information
- Application Number
- JP2024110523
- Authority / Receiving Office
- JP · JP
- Patent Type
- Applications
- Current Assignee / Owner
- Filing Date
- 2024-07-09
- Publication Date
- 2026-01-22
AI Technical Summary
Existing systems do not adequately evaluate the activities of community members who engage with managed objects across different decentralized autonomous organizations (DAO communities), leading to fragmented activity records and uncertain quality of data contributions.
A management system utilizing blockchain technology to share and verify activity records and data contributions across multiple DAO communities, enabling the transfer of tokens that certify participant activities and ensuring the legitimacy of data quality through a decentralized autonomous organization (DAO) community management device.
Enables seamless sharing and evaluation of activity records and data contributions across DAO communities, optimizing the appropriateness of participant evaluations and ensuring data quality, thereby enhancing the effectiveness of community management.
Smart Images

Figure 2026010568000001_ABST
Abstract
Description
[Technical Field]
[0001] The present invention relates to a management device, a management method, and a management program for managing a management target. [Background technology]
[0002] Patent Document 1 discloses an infrastructure appearance information collection system. This infrastructure appearance information collection system distributes a playful character to commonly used smartphones, and uses augmented reality technology to display the character in association with the facility being photographed, guiding ordinary residents to the photographed object, and by offering rewards such as points, allows ordinary residents in the neighborhood to perform visual inspections instead of professional maintenance personnel. [Prior art documents] [Patent documents]
[0003] [Patent Document 1] International Publication No. WO2021 / 229712 Summary of the Invention [Problem to be solved by the invention]
[0004] However, Patent Document 1 does not take into consideration the guarantee of evaluation of the activities of those in the community who have verified the managed objects provided within the community.
[0005] The present invention aims to improve the appropriateness of evaluations of people who have engaged in activities related to the management target. [Means for solving the problem]
[0006] A management device that is one aspect of the invention disclosed in the present application has a processor that executes a program and a storage device that stores the program, and is a management device that manages a group of managed objects with multiple participants, and is capable of communicating with a database that stores the number of points held by the participants that evaluate the participants' activities regarding the managed objects of the managed object group, and is characterized in that the processor executes the following processes: an acquisition process that receives a verification result for the managed object from the communication terminal of a verifier other than the photographer who photographed the managed object among the multiple participants, after sending a verification request for the managed object of the managed object to the communication terminal of the verifier; a calculation process that calculates a reliability for the managed object based on the verification result acquired by the acquisition process; and an update process that grants the points to the verifier based on the reliability calculated by the calculation process and updates the number of points held by the verifier. [Effects of the Invention]
[0007] According to the exemplary embodiment of the present invention, it is possible to appropriately evaluate the activities of those who have engaged in activities related to the management target. Problems, configurations, and effects other than those described above will become clear from the following description of the embodiment. [Brief explanation of the drawings]
[0008] [Figure 1] FIG. 1 is an explanatory diagram showing an example of a DAO community. [Figure 2] FIG. 2 is an explanatory diagram illustrating an example of the system configuration of the management system. [Figure 3] FIG. 3 is a block diagram illustrating an example of the hardware configuration of a computer. [Figure 4] FIG. 4 is an explanatory diagram showing an example of the configuration of the participant DB 211A. [Figure 5] FIG. 5 is an explanatory diagram showing an example of the configuration of the participant DB 211B. [Figure 6] FIG. 6 is an explanatory diagram showing an example of the configuration of the image DB 212A. [Figure 7] FIG. 7 is an explanatory diagram showing an example of the configuration of the image DB 212B. [Figure 8] FIG. 8 is an explanatory diagram showing an example of the token DB 213A. [Figure 9] FIG. 9 is an explanatory diagram showing an example of the token DB 213B. [Figure 10] FIG. 10 is an explanatory diagram illustrating an example of a token master. [Figure 11] FIG. 11 is an explanatory diagram showing an example of the token ledger 215A. [Figure 12] FIG. 12 is an explanatory diagram showing an example of the token ledger 215B. [Figure 13] FIG. 13 is an explanatory diagram illustrating an example of the correspondence DB. [Figure 14] FIG. 14 is a sequence diagram illustrating an example of an activity performance transition sequence. [Figure 15] FIG. 15 is an explanatory diagram illustrating an example of a performance certificate. [Figure 16] FIG. 16 is a sequence diagram showing an example of an image providing sequence. [Figure 17] FIG. 17 is a sequence diagram illustrating an example of a remote verification sequence. [Figure 18] FIG. 18 is a sequence diagram illustrating an example of an on-site verification sequence. [Figure 19] FIG. 19 is a sequence diagram illustrating an example of a label determination sequence. DETAILED DESCRIPTION OF THE INVENTION
[0009] <Figure 1 DAO Community> Figure 1 is an explanatory diagram showing an example of a DAO community. A DAO community is a collective that constitutes a decentralized autonomous organization. A DAO community is made up of participants and businesses that provide services to participants within the DAO community. A business might be, for example, an electric power company, and participants are residents who receive electricity. Participants may belong to multiple DAO communities.
[0010] In Figure 1, operator 101A and participant 102A belong to DAO community 100A, and operator 101B and participant 102B belong to DAO community 100B. A participant 102 who belongs to both DAO communities 100A and 100B is referred to as participant 102AB. When there is no need to distinguish between DAO communities 100A and 100B, they are referred to as DAO community 100. When there is no need to distinguish between operators 101A and 101B, they are referred to as operator 101. When there is no need to distinguish between participants 102A, 102B, and 102AB, they are referred to as participant 102.
[0011] In DAO community 100, tokens are used to evaluate the activity performance of participants 102. However, for example, the activity performance in DAO community 100A is recognized only within that DAO community 100A and cannot be utilized in DAO community 100B.
[0012] Specifically, when participant 102A belonging to DAO community 100A starts activities in DAO community 100B, he or she cannot inherit the activity records from DAO community 100A. As a result, participant 102A must build up new activity records in DAO community 100B. Furthermore, when providing image data to DAO community 100B, the quality of the image data cannot be guaranteed.
[0013] In this embodiment, for example, if participant 102A belonging to DAO community 100A joins DAO community 100B and becomes participant 102AB, blockchain is used to enable participant 102AB's activity record in DAO community 100A to be shared with DAO community 100B. Furthermore, this embodiment aims to optimize the evaluation of each participant's 102 activities by verifying the legitimacy of the activity record of each participant 102 in DAO community 100.
[0014] <Figure 2 System configuration example> Figure 2 is an explanatory diagram showing an example system configuration of a management system. Note that in Figure 2 and subsequent figures, the reference numerals for the configuration of DAO community 100A will have an A suffix, and the reference numerals for the configuration of DAO community 100B will have a B suffix. If there is no need to distinguish between the configurations of DAO communities 100A and 100B, the A and B suffixes will be omitted.
[0015] The management system 200 includes management devices 201A and 201B. In Fig. 2, the management system 200 includes two management devices 201A and 201B, but there may be three or more management devices 201.
[0016] The management device 201 has a front end 221 and a back end 222. The front end 221 is a computer that communicates with the communication terminal 202 via a network 203 such as the Internet, a local area network (LAN), or a wide area network (WAN). The back end 222 is a computer that is communicatively connected to the front end 221 and manages various databases (DBs) such as a participant DB 211, an image DB 212, a token DB 213, a token master 214, a token ledger 215, and a correspondence DB 216. Although the management device 201 is configured as being divided into the front end 221 and the back end 222, the management device 201 may be implemented as a single computer.
[0017] The communication terminal 202 is a computer owned by the participant 102, and is capable of communicating with the front end 221 via the network 203. The communication terminal 202 displays information entered by the participant 102 and transmits the information to the front end 221, and receives and displays information from the front end 221.
[0018] Furthermore, the communication terminal 202 can acquire current location information from a Global Navigation Satellite System (GNNS), which includes a Global Positioning System (GPS).
[0019] The communication terminal 202 has a camera so that participants can take pictures of the subject to be managed 603. Also, even if the communication terminal 202 does not have a camera, it is sufficient as long as it can communicate with a camera. This allows the communication terminal 202 to transmit image data taken with the camera to the front end 221.
[0020] <Fig. 3: Example of hardware configuration of computers (management device 201, communication terminal 202)> FIG. 3 is a block diagram showing an example of the hardware configuration of a computer (management device 201, communication terminal 202). The computer 300 includes a processor 301, a storage device 302, an input device 303, an output device 304, and a communication interface (communication IF) 305. The processor 301, the storage device 302, the input device 303, the output device 304, and the communication IF 305 are connected via a bus 306. The processor 301 controls the computer 300. The storage device 302 serves as a working area for the processor 301. The storage device 302 is a non-transitory or temporary recording medium that stores various programs and data. Examples of the storage device 302 include a read-only memory (ROM), a random access memory (RAM), a hard disk drive (HDD), and a flash memory. The input device 303 inputs data. Examples of the input device 303 include a keyboard, a mouse, a touch panel, a numeric keypad, a scanner, a microphone, and a sensor. The output device 304 outputs data. Examples of the output device 304 include a display, a printer, and a speaker. The communication IF 305 connects to the network 203 and transmits and receives data.
[0021] <Figure 4, Figure 5 Participant DB211> Fig. 4 is an explanatory diagram showing an example of the configuration of participant DB 211A. Fig. 5 is an explanatory diagram showing an example of the configuration of participant DB 211B. Participant DB 211 has the following fields: participant ID 401, participant name 402, and message address 403. A combination of values in each field on the same line forms an entry that defines the participant information of one participant 102.
[0022] The participant ID 401 is identification information that uniquely identifies the participant 102. The participant name 402 is the name of the participant 102. The message address 403 is an address used for communication with the front end 221. The message address 403 is, for example, an email address or a telephone number.
[0023] <Figure 6, Figure 7 Image DB212> Fig. 6 is an explanatory diagram showing an example of the configuration of image DB 212A. Fig. 7 is an explanatory diagram showing an example of the configuration of image DB 212B. Image DB 212 has the following fields: image ID 601, storage location 602, management target 603, location information 604, shooting date and time 605, photographer ID 606, verifier ID 607, verification result 608, and label 609. A combination of values in each field on the same line forms an entry that defines the image information of one piece of image data.
[0024] The image ID 601 is identification information that uniquely identifies the image data. The storage location 602 is information that specifies the location where the image data is stored. The storage location 602 is specified by, for example, a URL (Uniform Resource Locator). The management target 603 is information that indicates the main subject in the image data. The management target 603 is input from the communication terminal 202 and transmitted to the management device 201.
[0025] The location information 604 is information indicating the location of the communication terminal 202 that captured an image of the subject to be managed 603 and generated the image data, and is, for example, latitude and longitude. The location information 604 is, for example, extracted from Exif information in the image data. The shooting date and time 605 is the date and time when the communication terminal 202 captured an image of the subject to be managed 603 and generated the image data. The shooting date and time 605 is, for example, extracted from the Exif information in the image data.
[0026] The photographer ID 606 is the participant ID 401 of the participant 102 who took the image data. The verifier ID 607 is the participant ID 401 of the participant 102 who verified the image data (hereinafter referred to as the verifier 102). One or more verifier IDs 607 are recorded in one entry of image information. The verification result 608 is information indicating the authenticity of the subject photographed by the verifier 102 in the image data, i.e., the identity of the subject. The label 609 is identification information assigned to the image data.
[0027] The image ID 601 to photographer ID 606 are registered in step S1602, which will be described later. The image data is stored in an area specified by a storage location 602 in the backend 222. The verifier ID 607 and verification result 608 are registered in step S1707, which will be described later. The label 609 is registered in step S1907, which will be described later.
[0028] <Figure 8, Figure 9 Token DB213> Fig. 8 is an explanatory diagram showing an example of the token DB 213A. Fig. 9 is an explanatory diagram showing an example of the token DB 213B. The token DB 213 has the following fields: participant ID 401, number of held achievement tokens 801, number of held penalty tokens 802, and number of held reward tokens 803. A combination of values in each field on the same line forms an entry that defines the token information of the participant 102.
[0029] The number of achievement tokens held 801 is the number of achievement tokens held by the participant 102. An achievement token is a native token (virtual currency; hereinafter simply referred to as a token) that indicates the achievements of the participant 102 in the DAO community 100 to which the participant 102 belongs. The token is an example of a point used to evaluate the participant 102 for their activities regarding the managed object.
[0030] The penalty token holding count 802 is the number of penalty tokens held by the participant 102. A penalty token is a token that indicates a penalty that is imposed when the participant 102 interferes with the evaluation of image data by other participants 102 in the DAO community 100 to which the participant 102 belongs.
[0031] The number of reward tokens held 803 is the number of reward tokens held by the participant 102. A reward token is a token that indicates a reward given when the participant 102 contributes to the evaluation of image data of other participants 102 in the DAO community 100 to which the participant 102 belongs.
[0032] The number of achievement tokens held 801 of the participant 102 is the sum of the number of penalty tokens held 802 of the participant 102 and the number of reward tokens held 803 of the participant 102. The number of reward tokens held 803 is recalculated every time the number of achievement tokens held 801 or the number of penalty tokens held 802 is updated.
[0033] The entries 800A and 800B in the first row are entries for the administrator. In the entries 800A and 800B for the administrator, the number of achievement tokens held 801, the number of penalty tokens held 802, and the number of reward tokens held 803 are set to maximum values (e.g., 1000). When a token is issued to a participant 102, the number is subtracted from the entries 800A and 800B for the administrator and added to the entry for the participant 102.
[0034] <Figure 10 Token Master 214> 10 is an explanatory diagram showing an example of the token master 214. The token master 214 has the following fields: token ID 1001, token type 1002, transferability 1003, and total number of issues 1004. The token ID 1001 is identification information that uniquely identifies the token. The token type 1002 is the type of the token (achievement, reward, penalty). The transferability 1003 is information indicating whether the token is transferable (if true, transferable; if false, not transferable). The total number of issues 1004 is the maximum number of tokens that can be issued within the DAO community 100.
[0035] The management device 201 does not accept a request for transfer of achievement tokens or penalty tokens from one participant 102 to another participant 102. On the other hand, when the management device 201 accepts a request for transfer of reward tokens from one participant 102 to another participant 102, the management device 201 updates the number of reward tokens held 803 of each of the one participant and the other participant.
[0036] <Figure 11, Figure 12 Token Ledger 215> Fig. 11 is an explanatory diagram showing an example of the token ledger 215A. Fig. 12 is an explanatory diagram showing an example of the token ledger 215B. The token ledger 215 has the following fields: token ID 1001, token storage location 1101, destination participant ID 1102, and token issue date and time 1103. A combination of values in each field on the same line forms an entry that specifies token information related to a token issued in one transaction.
[0037] The token storage location 1101 is information specifying the location where the token is stored. The token storage location 1101 is specified by, for example, a URL. The issuer participant ID 1102 is the participant ID 401 of the participant 102 to whom the token is issued. The token issue date and time 1103 is the date and time when the token was issued.
[0038] <Figure 13 Correspondence DB216> Figure 13 is an explanatory diagram showing an example of correspondence DB 216. Figure 13 explains correspondence DB 216B within DAO community 100B. Correspondence DB 216A within DAO community 100A has the same data structure as correspondence DB 216B, but in this embodiment, an example is given of a case where participant 102A belonging to DAO community 100A also belongs to DAO community 100B, so it is assumed that no entries exist in correspondence DB 216A.
[0039] The correspondence DB 216B includes a transfer destination participant ID 1301 , a transfer source operator 1302 , a transfer source participant ID 1303 , a transfer source actual token holding count 1304 , and a transfer source penalty token holding count 1305 .
[0040] The destination participant ID 130 is the participant ID 401 of participant 102AB who migrated from DAO community 100A to DAO community 100B. The source operator 1302 is the operator 101A of DAO community 100A from which participant 102AB migrated. The source participant ID 1303 is the participant ID 401 of DAO community 100A from which participant 102AB migrated.
[0041] The number of achievement tokens held from the transfer source 1304 is the number of achievement tokens held from the participant 102AB in the DAO community 100A from which the transfer source is transferred 801. The number of penalty tokens held from the transfer source 1305 is the number of penalty tokens held from the participant 102AB in the DAO community 100A from which the transfer source is transferred 802.
[0042] Even after the transfer of achievement token holdings 801 and penalty token holdings 802, the data of participant 102AB remains in participant DB 211A, image DB 212A, token DB 213A, and token ledger 215A in DAO community 100A. Therefore, participant 102AB can receive services from business operator 101A, and participant 102AB's activities in DAO community 100A update participant DB 211A, image DB 212A, token DB 213A, and token ledger 215A.
[0043] <Figure 14 Activity results transition sequence> Figure 14 is a sequence diagram showing an example of an activity record migration sequence. The activity record migration sequence is a sequence for migrating the activity record of a participant 102 from the DAO community 100 to which that participant 102 belongs to another DAO community 100. Figure 14 illustrates an example in which the activity record of participant 102A, whose participant ID 401 is "UA5," is transferred from DAO community 100A to DAO community 100B. Note that the source of the migration is not limited to DAO community 100A, the source participant 102 is not limited to participant 102A of DAO community 100A, and the destination of the migration is not limited to DAO community 100B.
[0044] (Step S1401) The communication terminal 202 of the participant 102A:UA5 sends a request for issuance of a certificate of achievement to the front end 221A of the management device 201A of the DAO community 100A through an input operation by the participant 102A:UA5. The certificate of achievement is data (achievement certification data) that certifies the achievement of the participant 102A:UA5. The request for issuance of the certificate of achievement includes "UA5", which is the participant ID 401 of the participant 102A:UA5.
[0045] (Step S1402) When the front end 221A receives the request to issue a certificate of achievement in step S1401, it performs participant authentication. In participant authentication, the front end 221A checks whether an entry for "UA5", which is the participant ID 401 included in the request to issue a certificate of achievement, exists in the participant DB 211A of the back end 211A. If not, the front end 221A transmits a notification that the certificate of achievement cannot be issued to the communication terminal 202 of the participant 102A:UA5 (not shown). On the other hand, if the entry exists, the process proceeds to step S1403.
[0046] (Step S1403) The front end 221A issues a performance certificate 1400A for the participant 102A:UA5, and proceeds to step S1404. When issuing the performance certificate 1400A, the front end 221A refers to the image DB 212 to obtain the number of provided images and the latest image provision date, which will be described later.
[0047] (Step S1404) The front end 221A transmits the performance certificate 1400A issued in step S1403 to the communication terminal 202 of the participant 102A:UA5. The communication terminal 202 of the participant 102A:UA5 stores the performance certificate 1400A in the storage device 302 or displays it on a display, which is an example of the output device 304.
[0048] (Step S1405) The front end 221A transmits the performance certificate 1400A issued in step S1403 to the back end 222A.
[0049] (Step S1406) The backend 222A stores the performance certificate 1400A.
[0050] (Step S1407) The communication terminal 202 of the participant 102A:UA5 sends a verification request for the achievement certificate 1400A to the front end 221B of the management device 201B of the DAO community 100B through an input operation by the participant 102A:UA5. The verification request for the achievement certificate 1400A includes the achievement certificate 1400A of the participant 102A:UA5, the number of achievement tokens held 801, and the number of penalty tokens held 802.
[0051] The communication terminal 202 of the participant 102A (UA5) acquires the number of held achievement tokens 801 and the number of held penalty tokens 802 from the token DB 213A of the backend 222A via the frontend 221A prior to requesting verification of the achievement certificate 1400A.
[0052] (Step S1408) When the front end 221B of the management device 201B receives the verification request for the performance certificate 1400A in step S1407, it acquires the performance certificate 1400B of the participant 102A:UA5 from the back end 222A of the management device 201B. The performance certificate 1400B is data copied from the performance certificate 1400A in the back end 222A.
[0053] (Step S1409) The front end 221B verifies the performance certificate 1400A included in the received verification request using the performance certificate 1400B acquired in step S1408. That is, the front end 221B determines whether the performance certificate 1400A and the performance certificate 1400B are identical.
[0054] (Step S1410) If the performance certificate 1400A and the performance certificate 1400B are not the same, the verification fails (step S1410: No), and if the performance certificate 1400A and the performance certificate 1400B are the same, the verification succeeds (step S1410: Yes).
[0055] (Step S1411) If the verification fails (step S1410: No), the front end 221B transmits the verification result indicating the verification failure to the communication terminal 202 of the participant 102A:UA5. The participant 102A:UA5 displays the verification result indicating the verification failure on the communication terminal 202 of the participant 102A:UA5 for confirmation.
[0056] (Step S1412) If the verification is successful (step S1410: Yes), the front end 221B updates the participant DB 211B, the token DB 213B, and the correspondence DB 216. Specifically, for example, for participant 102A:UA5, the front end 221B assigns, for example, "UB5" as the participant ID 401 in the DAO community 100B, extracts the participant name 402 from the track record certificate 1400B, and extracts the sender address of the verification request from the track record certificate 1400A as the message address 403 to generate an entry 500, which is then registered in the participant DB 211B.
[0057] The front end 221B also registers in the token DB 213B an entry 900 in which the participant ID 401 is "UB5" and the number of held achievement tokens 801, the number of held penalty tokens 802, and the number of held reward tokens 803 are all "0".
[0058] In addition, the front end 221B sets the source participant ID 1303 to "UB5", sets the issuer name of the performance certificate 1400B to the source operator 1302, extracts the number of performance tokens held 801 of participant 102A:UA5 from the verification request as the source performance token holding number 1304, and extracts the number of penalty tokens held 802 of participant 102A:UA5 from the verification request as the source penalty token holding number 1305, and registers the generated entry in the correspondence DB 216B.
[0059] (Step S1413) The front end 221B transmits the verification result indicating successful verification to the communication terminal 202 of the participant 102A:UA5. The participant 102A:UA5 displays the verification result indicating successful verification on the communication terminal 202 of the participant 102A:UA5 for confirmation.
[0060] <Figure 15 Achievement Certificate 1400A> 15 is an explanatory diagram showing an example of the performance certificate 1400A. The performance certificate 1400A includes, for example, a certificate ID, an issuer ID, an issuer (the name of the business operator 101A), a participant ID 401, a participant 102 (name), the number of provided images, an average image quality score, the latest image provided date, a purpose (performance certificate), an issue date (the date the performance certificate 1400A was issued), and a signature (a digital signature of the management device 201A).
[0061] The certificate ID is identification information that uniquely identifies the performance certificate 1400A. The issuer ID is identification information that uniquely identifies the issuer, the business entity 101A. The number of provided images is the number of image data provided by the participant 102A:UA5 to the management device 201A. Specifically, for example, the number of provided images is the number of entries in the image DB 212A whose photographer ID 606 is the participant 102A:UA5.
[0062] The latest image provision date is the shooting date and time 605 of the latest image data provided by the participant 102A:UA5 to the management device 201A.
[0063] In this way, the management system 200 using blockchain technology aims to enable activity results to be shared between DAO communities 100, but if a participant 102A belonging to DAO community 100A also belongs to another DAO community 100B, the tokens that certify the activity results obtained in DAO community 100A can be transferred to the other DAO community 100B.
[0064] <Reward Token Distribution> The management device 201 periodically (for example, once a month) distributes reward tokens to the participant 102 according to the reward token holding count 803. Specifically, for example, the management device 201 issues a reward token for each participant 102. Next, the management device 201 generates an entry of token information for the reward token and registers it in the token ledger 215. Specifically, for example, the backend 222 assigns TK2, which is the token ID 1001 of the reward token, sets the token storage location 1101 of the reward token, sets the participant ID 401 of the participant 102 as the issuer participant ID 1102, and registers an entry in the token ledger 215 that sets the reward token issuance date and time as the token issuance date and time 1103.
[0065] <Figure 16 Image provision sequence> Figure 16 is a sequence diagram showing an example of an image provision sequence. The image provision sequence is a sequence in which image data obtained by capturing an image of a participant 102 is provided to the management device 201 of the DAO community 100 to which the participant 102 belongs. In Figure 16, as an example, the participant 102B:UB1 of the DAO community 100B who provides the image data is the photographer 102B:UB1. The communication terminal 202 of the photographer 102B:UB1 has already generated image data 1600 by capturing an image taken by the photographer 102B:UB1. The image provision destination is the DAO community 100B to which the photographer 102B:UB1 belongs.
[0066] (Step S1601) The communication terminal 202 of the photographer 102B:UB1 inputs the management target 603 through the operation of the photographer 102B:UB1, and transmits an image data save request to the front end 221B of the management device 201B. The image data save request includes the participant ID 401 of the photographer 102B:UB1, the image data 1600, and the management target 603.
[0067] (Step S1602) The front end 221B of the management device 201B generates an entry of image information for the received participant ID 401 of photographer 102B:UB1 and image data 1600, and stores it in the image DB 212B. That is, the front end 221B assigns a new image ID 601 (for example, "IMGB1"), sets a storage location 602 for the image data 1600, sets a management target 603 from the image data storage request, extracts location information 604 and shooting date and time 605 from the image data 1600, generates an entry in which the participant ID 401 of photographer 102B:UB1 is used as the photographer ID 606, and registers it in the image DB 212B.
[0068] (Step S1603) The front end 221B also transmits an achievement token issuance request to the back end 222B. The achievement token issuance request includes the participant ID 401 of the photographer 102B:UB1.
[0069] (Step S1604) The backend 222B issues an achievement token to the photographer 102B:UB1. In the case of providing an image, the achievement token points may be set to 1, for example.
[0070] (Step S1605) The backend 222B generates an entry of token information for the achievement token issued in step S1604 and registers it in the token ledger 215B. Specifically, for example, the backend 222B assigns TK1, which is the token ID 1001 of the achievement token, sets the token storage location 1101 of the achievement token, sets the participant ID 401 of the photographer 102B:UB1 as the issue destination participant ID 1102, and registers an entry in the token ledger 215B that sets the issuance date and time of the achievement token in step S1604 as the token issuance date and time 1103.
[0071] (Step S1606) The backend 222B updates the token DB 213B with the achievement token issued in step S1604. Specifically, for example, the backend 222B subtracts one point from the number of held achievement tokens 801 of the entry 800B for the administrator whose participant ID 401 is "B0", and adds one point to the number of held achievement tokens 801 of the entry for photographer 102B:UB1. The backend 222B also updates the number of held reward tokens 803 with the updated number of held achievement tokens 801 and number of held penalty tokens 802.
[0072] (Step S1607) The backend 222B sends a result notification to the frontend 221B. The result notification includes token information 1601 of the photographer 102B:UB1. The token information 1601 is the entries of the token DB 213B of the photographer 102B:UB1 (participant ID 401, number of achievement tokens held 801, number of penalty tokens held 802, number of reward tokens held 803).
[0073] (Step S1608) The front end 221B transmits a result notification to the communication terminal 202 of the photographer 102B:UB1. The photographer 102B:UB1 displays the token information 1601 included in the result notification on the communication terminal 202 of the participant 102B:UB1 for confirmation.
[0074] <Figure 17 Remote verification sequence> 17 is a sequence diagram showing an example of a remote verification sequence. The remote verification sequence is a sequence in which an image of image data obtained by a participant 102 in the DAO community 100 is remotely verified by another participant 102 in the same DAO community 100. Remote verification is the act of another participant 102 confirming what kind of subject is depicted in the image of the image data.
[0075] In Figure 17, as an example, participant 102B:UB2 of DAO community 100B who remotely verifies the image data is referred to as remote verifier 102B:UB2. Remote verifier 102B:UB2 evaluates the image data of another participant 102B other than himself (in Figure 17, image data 1600 (image ID 601:IMGB1) of participant 102B:UB1). The evaluation is performed by DAO community 100B to which remote verifier 102B:UB2 belongs.
[0076] (Step S1701) The front end 221B of the management device 201B acquires the image data 1600 and image ID 601:IMGB1 of the participant 102B:UB1 to be remotely verified from the back end 222B, and selects a remote verifier. Specifically, for example, the front end 221B selects one or more remote verifiers 102B from among the participants 102B other than the photographer 102B:UB1 of the image data 1600. The remote verifiers 102B may be selected randomly or based on the number of tokens held.
[0077] When selecting based on the number of tokens held, for example, the participant 102B is selected from among participants 102B with the highest actual token holding number 801, whose actual token holding number 801 is equal to or greater than the first threshold, or participants 102B with the lowest penalty token holding number 802, whose penalty token holding number 802 is less than the second threshold (< the first threshold).
[0078] (Step S1702) The front end 221B of the management device 201B obtains the image data 1600 and image ID 601:IMGB1 of the participant 102B:UB1 to be remotely verified from the back end 222B, and sends a remote verification request to the communication terminal 202 of the remote verifier 102B:UB2. The remote verification request includes the participant ID 401 of the remote verifier 102B:UB2, the image data 1600 of the participant 102B:UB1, and the image ID 601:IMGB1 of the image data 1600. (Step S1703) When the communication terminal 202 of the remote verifier 102B:UB2 receives the remote verification request in step S1701, it reads the image data 1600 of the participant 102B:UB1 and displays the image.
[0079] (Step S1704) The communication terminal 202 of the remote verifier 102B:UB2 inputs the remote verification result 1700 through operation by the remote verifier 102B:UB2. The remote verification result 1700 is information indicating the authenticity of the image captured by the remote verifier 102B:UB2 as the image data 1600, i.e., the identity of the subject. Here, the remote verification result 1700 is assumed to be a "telephone pole" as an example.
[0080] (Step S1705) The communication terminal 202 of the remote verifier 102B:UB2 sends a remote verification result notification to the front end 221B through an operation of the remote verifier 102B:UB2. The remote verification result notification includes the participant ID 401 of the remote verifier 102B:UB2, the image ID 601:IMGB1 of the image data 1600, and the remote verification result 1700.
[0081] (Step S1706) The front end 221B sends an achievement token issuance request to the back end 222B. The achievement token issuance request includes the participant ID 401 of the remote verifier 102B:UB2 extracted from the remote verification result notification, the image ID 601:IMGB1 of the image data 1600, and the remote verification result 1700.
[0082] (Step S1707) The backend 222B registers the remote verification result 1700 in the image DB 212B. Specifically, for example, the backend 222B extracts the image ID 601:IMGB1 of the image data 1600 from the achievement token issuance request, identifies the entry, registers the participant ID 401 of the remote verifier 102B:UB2 extracted from the achievement token issuance request in the verifier ID 607 of the identified entry, and registers the remote verification result 1700 (electric pole) extracted from the achievement token issuance request in the verification result 608 of the identified entry.
[0083] (Step S1708) The backend 222B issues an achievement token to the remote verifier 102B:UB2. In the case of remote verification, the achievement token has a point value of 1, for example.
[0084] (Step S1709) The backend 222B generates an entry of token information for the achievement token issued in step S1707 and registers it in the token ledger 215B. Specifically, for example, the backend 222B assigns TK1, which is the token ID 1001 of the achievement token, sets the token storage location 1101 of the achievement token, sets the participant ID 401 of the remote verifier 102B:UB2 as the issue destination participant ID 1102, and registers an entry in the token ledger 215B that sets the issuance date and time of the achievement token in step S1707 as the token issuance date and time 1103.
[0085] (Step S1710) The backend 222B updates the token DB 213B with the achievement token issued in step S1707. Specifically, for example, the backend 222B subtracts one point from the achievement token holding number 801 of the entry 800B for the administrator whose participant ID 401 is "B0", and adds one point to the achievement token holding number 801 of the entry for the remote verifier 102B:UB2. In addition, the backend 222B updates the reward token holding number 803 with the updated achievement token holding number 801 and penalty token holding number 802.
[0086] (Step S1711) The backend 222B sends a result notification to the frontend 221B. The result notification includes the token information 1701 of the remote verifier 102B:UB2. The token information 1701 is the entries (participant ID 401, number of achievement tokens held 801, number of penalty tokens held 802, number of reward tokens held 803) in the token DB 213B of the remote verifier 102B:UB2.
[0087] (Step S1712) The front end 221B transmits the result notification to the communication terminal 202 of the remote verifier 102B:UB2. The remote verifier 102B:UB2 displays the token information 1701 included in the result notification on the communication terminal 202 of the remote verifier 102B:UB2 for confirmation.
[0088] <Figure 18 On-site verification sequence> 18 is a sequence diagram showing an example of an on-site verification sequence. The on-site verification sequence is a sequence in which image data obtained by a participant 102 in the DAO community 100 is verified on-site by another participant 102 in the same DAO community 100. On-site verification is an act in which another participant 102 confirms whether or not a subject similar to the image in the image data exists at the shooting position of the participant 102 (photographer 102) who photographed the subject, which is a managed object 603, displayed in the image of the image data.
[0089] In Figure 18, as an example, participant 102B:UB3 of DAO community 100B performing on-site verification is designated as on-site verifier 102B:UB3. On-site verifier 102B:UB3 performs on-site verification of image data of another participant 102B other than himself (in Figure 18, image data 1600 (image ID 601:IMGB1) of participant 102B:UB1). The on-site verification is performed on the DAO community 100B to which on-site verifier 102B:UB3 belongs. Note that on-site verifier 102B:UB3 may be the same person as remote verifier 102B.
[0090] (Step S1801) The front end 221B of the management device 201B acquires the image data 1600 and image ID 601:IMGB1 of the participant 102B:UB1 to be verified on-site from the back end 222B, and selects an on-site verifier. Specifically, for example, the front end 221B selects one or more on-site verifiers 102B from among the participants 102B other than the photographer 102B:UB1 of the image data 1600. The on-site verifiers 102B may be selected randomly or based on the number of tokens held.
[0091] When selecting based on the number of tokens held, for example, the participant 102B is selected from among participants 102B with the highest actual token holding number 801, whose actual token holding number 801 is equal to or greater than the first threshold, or participants 102B with the lowest penalty token holding number 802, whose penalty token holding number 802 is less than the second threshold (< the first threshold).
[0092] In addition, if the address of participant 102B is registered in participant DB 211B, front end 221B may select participant 102B in order of the shortest distance between the address of participant 102B and the shooting location related to image data 1600, or the distance may be less than a predetermined distance.
[0093] In addition, the front end 221B may request current location information from the communication terminal 202 of the participant 102B, and select the participant 102B in order of the shortest distance between the current location information transmitted from the communication terminal 202 of the participant 102B and the shooting position for the image data 1600, or the distance may be less than a predetermined distance.
[0094] (Step S1802) The front end 221B transmits an on-site verification request to the communication terminal 202 of the on-site verifier 102B:UB3 selected in step S1801. The on-site verification request includes the participant ID 401 of the on-site verifier 102B:UB3, the image data 1600 to be verified on-site, and its image ID 601:IMGB1.
[0095] (Step S1803) When the communication terminal 202 of the on-site verifier 102B:UB3 receives the on-site verification request in step S1802, it displays the image of the image data 1600 and a map showing the shooting location of the image. The shooting location of the image of the image data 1600 is extracted from the Exif information attached to the image data 1600, for example.
[0096] The on-site verifier 102B:UB3 moves to the shooting location displayed on the map.
[0097] (Step S1804) The communication terminal 202 of the remote verifier 102B:UB3 is operated by the on-site verifier 102B:UB3 to input the on-site verification result 1800. The on-site verification result 1800 is information indicating the authenticity of the image captured by the on-site verifier 102B:UB3 as the image data 1600, i.e., the identity of the subject. Here, the on-site verification result 1800 is taken as an example to be a "telephone pole."
[0098] (Step S1805) The communication terminal 202 of the on-site verifier 102B:UB3 transmits an on-site verification result notification to the front end 221B through an operation by the on-site verifier 102B:UB3. The on-site verification result notification includes the participant ID 401 of the on-site verifier 102B:UB3, the image ID 601:IMGB1 of the image data 1600, and the on-site verification result 1800. The on-site verification result notification may also include current location information of the communication terminal 202 of the on-site verifier 102B:UB3.
[0099] (Step S1806) The front end 221B sends a performance token issuance request to the back end 222B. The performance token issuance request includes the participant ID 401 of the on-site verifier 102B:UB3 extracted from the on-site verification result notification, the image ID 601:IMGB1 of the image data 1600, and the on-site verification result 1800.
[0100] If the on-site verification result notification includes current location information of the communication terminal 202 of the on-site verifier 102B:UB3, the front end 221B calculates the distance between the shooting position of the image in the image data 1600 and the current location information. The front end 221B may send an achievement token issuance request to the back end 222B only if the calculated distance is within a predetermined distance. Furthermore, the front end 221B may include a distance determination result indicating whether the calculated distance is within a predetermined distance in the achievement token issuance request and send it to the back end 222B.
[0101] (Step S1807) The backend 222B registers the on-site verification result 1800 in the image DB 212B. Specifically, for example, the backend 222B extracts the image ID 601:IMGB1 of the image data 1600 from the achievement token issuance request, identifies the entry, registers the participant ID 401 of the on-site verifier 102B:UB3 extracted from the achievement token issuance request in the verifier ID 607 of the identified entry, and registers the on-site verification result 1800 (electric pole) extracted from the achievement token issuance request in the verification result 608 of the identified entry.
[0102] (Step S1808) The backend 222B issues an achievement token to the on-site verifier 102B:UB3. In the case of on-site verification, the points of the achievement token are, for example, 1. Furthermore, if the distance determination result is included in the achievement token issuance request in step S1806, the points of the achievement token may be increased or decreased according to the distance determination result. For example, the backend 222B may further increase the points of the achievement token if the distance determination result is within a predetermined distance. Furthermore, the backend 222B may further decrease the points of the achievement token if the distance determination result is not within the predetermined distance.
[0103] (Step S1809) The backend 222B generates an entry of token information for the achievement token issued in step S1808 and registers it in the token ledger 215B. Specifically, for example, the backend 222B assigns TK1, which is the token ID 1001 of the achievement token, sets the token storage location 1101 of the achievement token, sets the participant ID 401 of the local verifier 102B:UB3 as the issue destination participant ID 1102, and registers an entry in the token ledger 215B that sets the issuance date and time of the achievement token in step S1808 as the token issuance date and time 1103.
[0104] (Step S1810) The backend 222B updates the token DB 213B with the achievement token issued in step S1808. Specifically, for example, the backend 222B subtracts one point from the achievement token holding number 801 of the entry 800B for the administrator whose participant ID 401 is "B0", and adds one point to the achievement token holding number 801 of the entry for the local verifier 102B:UB3. In addition, the backend 222B updates the reward token holding number 803 with the updated achievement token holding number 801 and penalty token holding number 802.
[0105] (Step S1811) The backend 222B sends a result notification to the frontend 221B. The result notification includes the token information 1701 of the local verifier 102B:UB3. The token information 1701 is the entries of the token DB 213B of the local verifier 102B:UB3 (participant ID 401, number of achievement tokens held 801, number of penalty tokens held 802, number of reward tokens held 803).
[0106] (Step S1812) The front end 221B transmits a result notification to the communication terminal 202 of the on-site verifier 102B:UB3. The on-site verifier 102B:UB3 displays the token information 1701 included in the result notification on the communication terminal 202 of the on-site verifier 102B:UB3 for confirmation.
[0107] <Figure 19 Label determination sequence> 19 is a sequence diagram showing an example of a label determination sequence. The label determination sequence is a sequence for determining a label to be assigned to image data obtained by a photograph taken by a participant 102 (photographer 102) in the DAO community 100. The label determination is performed based on the verification results 608 of participants 102 other than the photographer 102 in the DAO community 100.
[0108] 19, an example of determining a label for image data 1600 of photographer 102B:UB1 of DAO community 100B will be described. The remote verifiers 102B and on-site verifiers 102B other than photographer 102B:UB1 of DAO community 100B are referred to as verifiers 102B:UBv.
[0109] (Step S1901) The front end 221B of the management device 201B selects the image data to be determined. The image data to be determined is image data to which the label 609 has not been assigned in the image DB 212B. In this example, the image data to be determined is the image data 1600 of the photographer 102B:UB1. Therefore, the front end 221B acquires the image data 1600 of the photographer 102B:UB1 and its image ID 601:IMGB1 from the back end 222B. Note that image data to which the label 609 has already been assigned may also be selected as the image data to be determined. In this case, the label 609 is updated by the label determination.
[0110] (Step S1902) The front end 221B refers to the image DB 212B to identify the verifier 102B:UBv of the determination target image data 1600. The verifier is, for example, the remote verifier 102B:UB2 shown in Fig. 17 and the on-site verifier 102B:UB3 shown in Fig. 18. The front end 221B obtains the verifier ID 607 of the verifier 102B:UBv from the entry of image ID 601:IMGB1 indicating the determination target image data 1600 in the image DB 212B.
[0111] (Step S1903) The front end 221B calculates the reliability of all verifiers for the photographer 102B:UB1 with respect to the determination target image data 1600. The reliability of all verifiers is calculated, for example, as the agreement ratio A below using the following formula (1).
[0112]
number
[0113] In the above formula (1), n is the number of verifiers 102B:UBv, i.e., the number of verifier IDs 607. i is an ascending value starting from 1 to n, and uniquely specifies a verifier ID 607. ri is the number of achievement tokens 801 held by the i-th verifier 102B:UBv. pi is the number of penalty tokens 802 held by the i-th verifier 102B:UBv. ri-pi indicates the reliability of the i-th verifier 102B:UBv.
[0114] vi is the verification result 608 of the i-th verifier 102B:UBv. In this example, if the verification result 608 is "telephone pole", vi=1, and if the verification result 608 is other than "telephone pole", vi=0.
[0115] In step S1903, the front end 221B calculates the agreement ratio A, but may count the number of verifier IDs 607 for each type of verification result 608 (for example, "utility pole" and "not utility pole").
[0116] (Step S1904) The front end 221B determines the label 1900 to be assigned to the determination target image data 1600 of the photographer 102B:UB1 based on the agreement ratio A. Specifically, for example, if the agreement ratio A is a predetermined ratio or more, the front end 221B determines the label 1900 to be assigned to the determination target image data 1600 to be "utility pole," and if the agreement ratio A is not the predetermined ratio or more, the front end 221B determines the label 1900 to be assigned to the determination target image data 1600 to be "not utility pole."
[0117] In addition, when the number of verifier IDs 607 is counted for each type of verification result 608 (for example, "utility pole" and "not utility pole"), the front end 221B determines the label 1900 to be assigned to the determination target image data 1600 of photographer 102B:UB1 to be the type with the most.
[0118] (Step S1905) The front end 221B sends the label 1900 determined in step S1904 and its image ID 601:IMGB1 to the back end 222B.
[0119] (Step S1906) The backend 222B receives the label 1900 and its image ID 601:IMGB1 sent in step S1905, and registers the label 1900 in the label 609 of the entry for image ID 601:IMGB1 in the image DB 212B.
[0120] (Step S1907) The front end 221B determines the penalty for each verifier 102B:UBv. That is, the front end 221B identifies the person to whom a penalty token is to be issued. Specifically, for example, the front end 221B identifies the verifier 102B:UBv that registered a verification result 608 that differs from the label 1900 as the penalty token issuance person 102B:UBvp. The verifier ID 607 of the penalty token issuance person 102B:UBvp is represented as the penalty target verifier ID 607p.
[0121] (Step S1908) The front end 221B transmits a penalty token issuance request for the penalty token issuance target 102B:UBvp to the back end 222B. The penalty token issuance request includes the penalty target verifier ID 607p.
[0122] (Step S1909) The backend 222B issues a penalty token for each of the penalty target verifier IDs 607p. The penalty token points are set to 1, for example.
[0123] (Step S1910) The backend 222B generates an entry of token information for the penalty token issued in step S1909 and registers it in the token ledger 215B. Specifically, for example, the backend 222B assigns TK3, which is the token ID 1001 of the penalty token, sets the token storage location 1101 of the penalty token, sets the penalty target verifier ID 607p of the penalty token issue target 102B:UBvp as the issuance destination participant ID 1102, and registers an entry in the token ledger 215B that sets the issuance date and time of the penalty token in step S1909 as the token issuance date and time 1103.
[0124] (Step S1911) The backend 222B updates the token DB 213B with the penalty token issued in step S1909. Specifically, for example, the backend 222B subtracts one point from each of the number of held achievement tokens 801 and the number of held penalty tokens 802 of the entry 800B for the administrator whose participant ID 401 is "B0", and adds one point to each of the number of held achievement tokens 801 and the number of held penalty tokens 802 of the entry for the penalty token issuance target 102B:UBvp. In addition, the backend 222B updates the number of held reward tokens 803 with the updated number of held achievement tokens 801 and the number of held penalty tokens 802.
[0125] (Step S1912) The backend 222B sends a result notification to the frontend 221B. The result notification includes token information 1701 of the local verifier 102B:UB3. The token information 1701 is the entry (participant ID 401, number of achievement tokens held 801, number of penalty tokens held 802, number of reward tokens held 803) in the token DB 213B of the penalty token issuance target 102B:UBvp.
[0126] (Step S1913) The front end 221B transmits the result notification to the communication terminal 202 of the penalty token issuance target 102B:UBvp. The penalty token issuance target 102B:UBvp displays the token information 1901 included in the result notification on the communication terminal 202 of the penalty token issuance target 102B:UBvp for confirmation.
[0127] In this way, by distributing achievement tokens for verification achievements and distributing penalty tokens for inappropriate verifications, it is possible to reduce the number of inappropriate verifications for which penalty tokens are distributed.
[0128] Also, when the verifier 102B:UBv is the participant 102AB, in calculating the agreement ratio A, the backend 222B may use the source actual token holding number 1304 and source penalty token holding number 1305 in the correspondence DB 216B instead of the verifier 102B:UBv's actual token holding number 801 and penalty token holding number 802 in the token DB 213B.
[0129] For example, the backend 222B may use the previously set DB of the token DB 213B or the correspondence DB 216B. The backend 222B may also compare the reliability of the participant 102AB, who is the verifier 102B:UBv, in the token DB 213B (= the number of actual tokens held 801 - the number of penalty tokens held 802) with the reliability of the correspondence DB 216B (= the number of original actual tokens held 1304 - the number of original penalty tokens held 1305), and use the higher reliability.
[0130] This makes it possible to determine labels (step S1904) using tokens handed over to other DAO communities 100B, thereby improving the accuracy of label determination.
[0131] <Variation 1> In the above example, the points of the issued token are set to "1", but the points are not limited to "1".
[0132] <Variation 2> In the above example, the authenticity of the managed object 603 (subject) is verified, but the state (normal, abnormal, etc.) of a specific managed object 603 (subject) may be verified instead of the authenticity of the managed object 603 (subject). In this case, the label 609 also becomes the state (normal, abnormal, etc.) of the specific managed object 603 (subject).
[0133] The present invention is not limited to the above-described embodiments, and includes various modifications and equivalent configurations within the spirit and scope of the appended claims. For example, the above-described embodiments have been described in detail to clearly explain the present invention, and the present invention is not necessarily limited to configurations including all of the described configurations. Furthermore, part of the configuration of one embodiment may be replaced with the configuration of another embodiment. Furthermore, the configuration of another embodiment may be added to the configuration of one embodiment. Furthermore, part of the configuration of each embodiment may be added to, deleted from, or replaced with other configurations.
[0134] Furthermore, the aforementioned configurations, functions, processing units, processing means, etc. may be realized in part or in whole in hardware, for example by designing them as integrated circuits, or may be realized in software by having a processor interpret and execute a program that realizes each function.
[0135] Information such as programs, tables, files, etc. that realize each function can be stored in storage devices such as memory, hard disks, SSDs (Solid State Drives), or recording media such as IC (Integrated Circuit) cards, SD cards, and DVDs (Digital Versatile Discs).
[0136] In addition, the control lines and information lines shown are those that are considered necessary for explanation, and do not necessarily represent all the control lines and information lines that are necessary for implementation. In reality, it can be assumed that almost all components are interconnected. [Explanation of symbols]
[0137] 100 DAO Community 102 participants (photographers, remote verifiers, on-site verifiers, penalty token issue recipients) 200 Management System 201 Management device 211 Participant DB 212 Image DB 213 Token DB 221 Front End 222 Backend 214 Token Master 215 Token Ledger 301 processor 302 Storage Devices 603 Managed 604 Location information 608 Verification Results 609 Label 801 achievement tokens held 802 Penalty Tokens held 1600 image data 1700 Remote Verification Results 1800 On-site verification results 1900 Labels
Claims
1. A management device that manages a group of management targets by a plurality of participants, the management device having a processor that executes a program and a storage device that stores the program, a database capable of communicating with the database that maintains a number of points that evaluate the participant for the participant's activity on managed objects in the managed object group; The processor: an acquisition process of transmitting a verification request for the managed object to a communication terminal of a verifier other than the photographer who photographed the managed object among the plurality of participants, and then receiving a verification result for the managed object from the communication terminal of the verifier; a calculation process for calculating a reliability of the managed object based on the verification result acquired by the acquisition process; an update process of granting the points to the verifier based on the reliability calculated by the calculation process and updating the number of points held by the verifier; A management device that executes the above.
2. The management device according to claim 1 , The database stores, as the points, the number of achievement points held by the participant, which indicates the participant's achievements in the managed object; In the update process, the processor grants the achievement points to the verifier who transmitted the verification result, and updates the number of achievement points held by the verifier. A management device characterized by:
3. The management device according to claim 2, The database holds, as the points, a number of penalty points indicating a penalty to be imposed on the verifier for verifying the managed object, in addition to the achievement points; In the calculation process, the processor calculates the reliability based on a difference between the number of achievement points held by the verifier and the number of penalty points held by the verifier. A management device characterized by:
4. The management device according to claim 2, The database holds, as the points, a number of penalty points indicating a penalty to be imposed on the verifier for verifying the managed object, in addition to the achievement points; The processor: execute a determination process to determine whether or not to impose the penalty on the verifier based on the reliability; In the update process, the processor grants the penalty points to the verifier who has been determined to be penalized by the determination process, and updates the number of penalty points held by the verifier. A management device characterized by:
5. 5. The management device according to claim 4, The processor: performing a determination process for determining a label to be assigned to the managed object based on the reliability; In the determination process, the processor determines whether to impose the penalty on the verifier based on the label determined in the determination process and the verification result. A management device characterized by:
6. The management device according to claim 5, In the determination process, the processor determines that the penalty should be imposed on the verifier if the label and the verification result do not match. A management device characterized by:
7. The management device according to claim 1 , In the acquisition process, the processor transmits a request to verify the authenticity of the managed object to the verifier's communication terminal, and receives a verification result of the authenticity of the managed object from the verifier's communication terminal; In the calculation process, the processor calculates a reliability of the authenticity of the managed object based on the verification result. A management device characterized by:
8. The management device according to claim 1 , In the acquisition process, the processor transmits a request to verify the state of the managed object to the verifier's communication terminal, and receives a verification result of the state of the managed object from the verifier's communication terminal; In the calculation process, the processor calculates a reliability of the state of the managed object based on the verification result. A management device characterized by:
9. The management device according to claim 1 , In the acquisition process, the processor transmits the verification request including the image data of the management target to the communication terminal of the verifier, and receives a verification result for the management target from the communication terminal of the verifier. A management device characterized by:
10. The management device according to claim 1 , In the acquisition process, the processor transmits the verification request including the location information of the managed object to the communication terminal of the verifier, and receives a verification result for the managed object from the communication terminal of the verifier. A management device characterized by:
11. The management device according to claim 2, In the acquisition process, the processor transmits the verification request including the location information of the managed object to the verifier's communication terminal, and receives a verification result for the managed object including current location information of the verifier's communication terminal from the verifier's communication terminal; In the update process, the processor grants the achievement points to the verifier who transmitted the verification result based on the location information of the managed object and current location information of the verifier's communication terminal, and updates the number of achievement points held by the verifier. A management device characterized by:
12. The management device according to claim 1 , execute a selection process for selecting the verifier based on the points; In the acquisition process, the processor transmits the verification request to the communication terminal of the verifier selected by the selection process, and receives a verification result for the managed object from the communication terminal of the verifier selected by the selection process. A management device characterized by:
13. The management device according to claim 1 , The points are set to be non-transferable to other participants. A management device characterized by:
14. A management method executed by a management device that has a processor that executes a program and a storage device that stores the program, and that manages a group of management targets with a plurality of participants, comprising: a database capable of communicating with the database that maintains a number of points that evaluate the participant for the participant's activity on managed objects in the managed object group; The processor: an acquisition process of transmitting a verification request for the managed object of the managed object group to a communication terminal of a verifier other than the photographer who photographed the managed object among the plurality of participants, and then receiving a verification result for the managed object from the communication terminal of the verifier; a calculation process for calculating a reliability of the managed object based on the verification result acquired by the acquisition process; an update process of granting the points to the verifier based on the reliability calculated by the calculation process and updating the number of points held by the verifier; A management method comprising:
15. A management program executed by a processor of a management device that manages a group of managed objects by a plurality of participants, the management device is capable of communicating with a database that stores a number of points that evaluate the participant for the participant's activity regarding the managed object of the managed object group; the processor, an acquisition process of transmitting a verification request for the managed object of the managed object group to a communication terminal of a verifier other than the photographer who photographed the managed object among the plurality of participants, and then receiving a verification result for the managed object from the communication terminal of the verifier; a calculation process for calculating a reliability of the managed object based on the verification result acquired by the acquisition process; an update process of granting the points to the verifier based on the reliability calculated by the calculation process and updating the number of points held by the verifier; A management program characterized by causing the program to execute the above.
Citation Information
Patent Citations
Resident participation type preservation activities assistance system and method
WO2021229712A1