WO2022034981A1

WO2022034981A1 - Blockchain decentralized identification-based ticket reservation method and apparatus

Info

Publication number: WO2022034981A1
Application number: PCT/KR2020/017054
Authority: WO
Inventors: 이승재; 이윤정; 이민수
Original assignee: 이승재
Priority date: 2020-08-13
Filing date: 2020-11-27
Publication date: 2022-02-17
Also published as: KR20220021151A; KR102398592B1

Abstract

A DID-based ticket reservation method comprises the steps of: receiving a first DID authentication request for reserving a ticket of a first user account, wherein the first DID authentication request includes an encrypted hash value corresponding to biometric information of the first user account; forwarding the first DID authentication request to a DID authentication network; receiving a result of the first DID authentication request from the DID authentication network; activating a ticket reservation function for the first user account when the first DID authentication request is successful as the result of the authentication request; when a ticket reservation is received from the first user account, transmitting a request for issuing a crypto ticket corresponding to a reserved ticket to a crypto ticket issuance network; and receiving a result of the request for issuing a crypto ticket from the crypto ticket issuance network.

Description

A method for ticket reservation based on blockchain distributed identity verification and a device therefor

This specification proposes a ticket reservation method based on blockchain decentralized identification (DID) and an apparatus therefor.

Blockchain is a data distribution processing technology that distributes and stores all data that is managed by all users participating in the network. It is also called 'Distributed Ledger Technology (DLT)' or 'Public Transaction Ledger' in that the ledger containing transaction information is not owned by the transaction subject or a specific institution, but is a technology shared by all network participants. . Blockchain is a name given to the fact that blocks containing transaction contents are linked like a chain.

Blockchain is a core concept of decentralization, which aims for P2P (Peer to Peer) transactions, away from the existing financial system that secures and manages all transactions in financial institutions. P2P refers to a communication network that connects personal computers without a server or client, and each connected computer acts as a server and client and shares information.

DID (Decentralized Identity) is a technology that allows individuals to have complete control over their information without being controlled by a central system, unlike existing identification methods. DID is also called distributed identity or decentralized identity. Representative DID services include Initial, an alliance of major Korean telecommunication companies and banks, MyID service centered on ICONLOOP, DID forum centered on SymVerse, and MyKeepin ( MyKeepin) service, and Omni One centered on Raon Secure Co., Ltd.

DID does not require centralized power because distributed ledgers or other decentralized systems are registered or anchored. Unlike existing identity verification, DID has the feature that users can manage it just like cryptocurrency users manage their funds. The core content of DID is that it can hold multiple DIDs, can be used in multiple chains such as public and private, access DID only through the user's key, identity request information stored off-chain, can have multiple identity hubs across multiple devices and crowds It is the fact that the characteristics of blockchain technology such as such are utilized.

Currently, when issuing tickets for various performances and sports, there is a frequent problem that end-users cannot obtain tickets for the performances and sports they want due to the large number of tickets purchased by illegal users who use illegal programs such as the automatic ticket reservation macro program. . In particular, it is common for illegal users to resell tickets at a high price by attaching a premium price to tickets purchased through the use of illegal programs, and the dissatisfaction of organizers/producers of performances and sports and end users is increasing day by day. In addition, with the popularity of ticket sales, ticket transfer fraudulent transactions also became popular, resulting in financial damage to end-users.

In order to prevent this type of ticket transaction, the organizers/producers of performances and sports placed a superstrength that performance tickets are non-transferable (that is, only the reserved ticket holders can enter), but this stiffens the market order and causes performances due to unavoidable reasons. However, there was a problem that the person had to bear the loss of the ticket price if he or she could not attend the sport.

In the ticket reservation method based on Decentralized IDentification (DID) according to an embodiment of the present invention, the step of receiving a first DID authentication request for ticket reservation of a first user account, wherein the first DID authentication request is 1 Contains an encrypted hash value corresponding to biometric information of a user account; forwarding the first DID authentication request to a DID authentication network; receiving a result of the first DID authentication request from the DID authentication network; activating a ticket reservation function for the first user account when the first DID authentication request is successful as a result of the authentication request; when a ticket reservation is received from the first user account, transmitting a crypto ticket issuance request corresponding to the reserved ticket to a crypto ticket issuing network; and receiving a crypto-ticket issuance request result from the crypto-ticket issuance network. may include

A crypto ticket is a digital ticket that gives ticket information to a blockchain token (cryptocurrency).

According to an embodiment of the present invention, it is possible to determine whether an illegal program is used before ticket reservation, it is possible to prevent a phenomenon of purchasing a large number of tickets by illegal users, and there is an effect that tickets can be issued to end users. .

In addition, according to an embodiment of the present invention, the size of the ticket transaction market is reduced due to restrictions on ticket purchases by illegal users, thereby reducing financial damage caused by fraudulent ticket purchases.

In addition, according to an embodiment of the present invention, since ticket reservation/issuance is possible only through self-authentication based on DID technology with high security and accuracy, it is possible to make a bulk reservation of tickets by illegal users using multiple other user accounts. The effect is that it is impossible.

1 is a diagram illustrating an embodiment of issuing a DID according to an embodiment of the present invention.

2 is a diagram briefly illustrating a DID-based ticket sales/reservation method according to an embodiment of the present invention.

3 is a flowchart illustrating an embodiment of DID registration according to an embodiment of the present invention.

4 is a flowchart illustrating an identity authentication method using a DID according to an embodiment of the present invention.

5 is a flowchart illustrating a method of determining whether an illegal program is used according to an embodiment of the present invention.

6 is a diagram illustrating a log vector generation method according to an embodiment of the present invention.

7 is a graph illustrating a change in cosine similarity over time according to an embodiment of the present invention.

8 is a graph illustrating self-similarity according to an embodiment of the present invention.

9 is a diagram illustrating examples of UI for finally determining whether to use a macro according to an embodiment of the present invention.

10 is a diagram illustrating a method for determining a ticket reservation macro program based on artificial intelligence (AI) technology according to an embodiment of the present invention.

11 is a flowchart illustrating a DID-based crypto ticket issuance and confirmation method according to an embodiment of the present invention.

12 is a block diagram of a ticket reservation server according to an embodiment of the present invention.

Since the technology to be described below may have various changes and may have various embodiments, specific embodiments will be illustrated in the drawings and described in detail. However, this is not intended to limit the technology described below to specific embodiments, and it should be understood to include all modifications, equivalents, and substitutes included in the spirit and scope of the technology described below.

Terms such as first, second, A, and B may be used to describe various components, but the components are not limited by the above terms, and only for the purpose of distinguishing one component from other components. is used only as For example, a first component may be referred to as a second component, and similarly, the second component may also be referred to as a first component without departing from the scope of the present invention. and/or includes a combination of a plurality of related listed items or any of a plurality of related listed items. For example, 'A and/or B' may be interpreted as meaning 'at least one of A or B'. Also, '/' may be interpreted as 'and' or 'or'.

In terms of terms used herein, the singular expression should be understood to include a plural expression unless the context clearly dictates otherwise, and terms such as "comprises" include the specified feature, number, step, operation, and element. , parts or combinations thereof are to be understood, but not to exclude the possibility of the presence or addition of one or more other features or numbers, step operation components, parts or combinations thereof.

Prior to a detailed description of the drawings, it is intended to clarify that the classification of the constituent parts in the present specification is merely a division according to the main function each constituent unit is responsible for. That is, two or more components to be described below may be combined into one component, or one component may be divided into two or more for each more subdivided function. In addition, each of the constituent units to be described below may additionally perform some or all of the functions of other constituent units in addition to the main function it is responsible for. Of course, it can also be performed by being dedicated to it.

In addition, in performing the method or method of operation, each process constituting the method may occur differently from the specified order unless a specific order is clearly described in context. That is, each process may occur in the same order as specified, may be performed substantially simultaneously, or may be performed in the reverse order. Also, in this specification, 'network' may be replaced with 'server' or 'device'.

DID is an identity verification technology based on blockchain technology that is not controlled by a central system and allows individuals to have complete control over their personal information (ie, store and manage them themselves). DID is establishing standards at W3C, an international web standards organization, and has recently been adopted as one of the five major strategies for spreading blockchain technology by the Ministry of Science and ICT. Let's look at the initial registration method of these DIDs. Embodiments to be described below assume that the DID issuance has been completed for each account.

Referring to FIG. 1 , first, the DID issuing server may perform initial identification of a user requesting issuance of a DID. Identification may be performed in various ways, for example, various methods such as text/call authentication through a communication company, authentication through biometric information (fingerprint/iris/face) recognition, and input of a unique identification code may be used. A user can request a DID issuance by inputting identification information for DID issuance through an application/web that supports DID issuance. The DID issuing server may perform identity authentication using the user's identity verification information received through the application/web, and if the identity authentication is successful, may issue a DID to the user who has successfully authenticated. The DID issued in this way may be transmitted and stored to the user terminal.

DID includes/based on a hash value including at least one of a key value uniquely assigned to the identity verification information for a user (or user account) for which identity verification has been completed, and a key value uniquely assigned to a user terminal that has requested DID issuance can be created with The hash value may be included in the DID in an encrypted state and transmitted to the user terminal and the blockchain network.

The DID issuance server can block DID issuance information (information about the DID and the user account for which the DID was issued) based on the block chain technology, and distribute it to a plurality of block chain nodes (ie, block chain network) and store it. Since DID issuance information is distributed and stored in multiple blockchain nodes within the blockchain network, it is difficult to duplicate and hack, and it has the advantage that it does not lead to personal information leakage even if it is leaked because it does not directly store personal information.

A user who has been issued a DID can receive identity confirmation/authentication using the issued DID when an identity confirmation/authentication event occurs later. More specifically, when an identity verification/authentication event occurs, the user terminal may submit/transmit a DID authentication request for the user account to the target server/web requesting identity verification/authentication, and the target server/web may request You can request verification of the received DID from the blockchain network.

The DID authentication request may include an encrypted hash value corresponding to the result of the user's first authentication performed by the user terminal. For example, when a user identity verification/authentication request event occurs, the user terminal may execute an application/web designed/installed for DID authentication, and the user may use the application/web to verify identity information (e.g., As biometric information, fingerprint/iris/face, etc.) may be input. The DID authentication application/web determines whether the received identification information matches the previously stored identification information, and if it does match, the hash value received from the DID issuing server and stored at the time of the first DID issuance is encrypted and included in the DID authentication request. It can be transmitted to the target server/web.

The blockchain network can perform verification of the requested DID. More specifically, the blockchain network can verify the DID by whether the encrypted hash value included in the DID authentication request matches the hash value stored for the user account that requested authentication. The blockchain network can determine that the DID authentication request is successful when the two values match, and that the DID authentication request has failed when they do not match, and can notify/transmit the verification result to the target server/web.

The DID issuance method can be performed in various ways other than the above-described embodiments, and in this specification, a DID-based ticket reservation method and an apparatus therefor will be proposed in detail on the premise that the DID issuance is completed. In particular, the following embodiments may be independently performed by a ticket sales/reservation agency platform/application/web server (hereinafter, collectively referred to as a 'ticket reservation server') acting on behalf of ticket sales/reservation.

Referring to FIG. 2 , the DID-based ticket sales/reservation method may be largely composed of an identity authentication step (S201) → a macro use determination step (S202) → a crypto ticket issuance step (S203). Among these steps, the step of determining whether to use a macro may or may not be selectively performed depending on the embodiment.

The self-authentication step S201 corresponds to a step of performing user self-authentication based on the above-described DID. In particular, this step (S201) is a step for determining whether the account of the user who applied for the ticket reservation is the user's account. . A more detailed embodiment of this step will be described below with reference to FIGS. 3 and 4 .

The macro use determination step S202 corresponds to a step of determining whether the user who applied for a ticket reservation is using an illegal program such as a ticket reservation macro program. In particular, this step (S202) may be performed using an illegal program use determination algorithm established based on artificial intelligence (AI), and the ticket reservation function may be deactivated for the account in which the illegal program use is determined. Conversely, a ticket reservation function may be activated for an account in which non-use of an illegal program is determined. A more detailed embodiment of this step will be described below with reference to FIGS. 5 to 9 .

The crypto-ticket issuance step S203 is a step for issuing a crypto-ticket to a user account that has requested a ticket reservation. Here, a crypto ticket may be issued in the form of a crypto currency/token including ticket information (ticket information, reservation information, etc.) reserved by a user by a block chain network based on block chain technology. In order to distinguish the blockchain network that issues crypto tickets from the blockchain network that issues DIDs, it may be referred to as a crypto ticket issuance network. Crypto tickets are also blocked based on blockchain technology and distributed and stored in the crypto ticket issuance network, so there is little risk of duplication/hacking. A more detailed embodiment of this step will be described below with reference to FIGS. 4 and 10 .

Step S202 may be selectively applied according to an embodiment, and as a result, step S203 may be performed immediately after step S201 is executed.

The ticket sales/reservation method illustrated in this drawing can be extended and applied to the system. In this case, the above three steps are interpreted as a self-certification module/device, a macro-use determination module/device, and a crypto-ticket issuing module/device, respectively. can be Similarly, this ticket sales/reservation method can be extended and applied to devices, and in this case, the three steps described above will be interpreted as a self-certifying unit/unit, a macro-use determining unit/unit, and a crypto-ticket issuing unit/unit, respectively. can

3 is a flowchart illustrating an embodiment of issuing a DID according to an embodiment of the present invention.

This figure is an extended embodiment of the embodiment of FIG. 1, and is a flow chart related to an embodiment of DID registration/issuance, particularly when identification is performed through a telecommunication company. Accordingly, the description of FIG. 1 may be applied to this embodiment.

Referring to FIG. 3 , first, the DID issuing server may receive a DID authentication registration request from the first user terminal ( S301 ).

Next, the DID issuing server may request identification/authentication for the first user terminal (S302). To this end, the ticket reservation server may use various identification/authentication means. As an example, the ticket reservation server, as shown in this figure, may use a communication company identity authentication means, and a UI (User Interface) (eg, user terminal information and user terminal subscriber information) for authentication of the communication company itself. A window for receiving input) may be provided to the first user terminal.

The first user may input personal authentication information such as his/her terminal information and terminal subscription information in the UI, and the ticket reservation server confirms the identity by transmitting the received personal authentication information to the identity authentication server (ie, the telecommunication company server) may request and receive a response thereto (S303).

Next, the DID issuing server may request the first user terminal to register identification information for running an application/program that submits/transmits DID to a target server that the user wants to use ( S304 ). The user's biosignal information (eg, fingerprint/iris/facial recognition information) may be used. Accordingly, the first user terminal may request the first user to input user biosignal information for executing the DID submission/transmission application, and execute/trigger the DID submission/transmission application using the biosignal information input by the user. can be used as information for Accordingly, the identification information may be interpreted as a kind of triggering key for triggering a DID-related function/application/execution within the user terminal. Since such identification information (especially, biosignal information) is stored only in the first user terminal and is not separately transmitted to the DID issuing server, a problem such as a large amount of personal information leakage due to hacking of the DID issuing server does not occur.

When the registration of the identification information is completed, the first user terminal may notify the DID issuing server that the registration is complete ( S305 ).

Next, the DID issuing server may issue a DID and transmit it to the first user terminal (S306), and distributedly transmit DID issuance information (DID issuance user information, issuance time, encrypted hash value, etc.) to the DID authentication network. (S307). Here, the DID authentication network may correspond to the block chain network of FIG. 1 , and a redundant description will be omitted.

Optionally, the ticket reservation server may additionally perform DID issuance verification to confirm whether the DID issuance was successful (S308), and since the DID issuance verification is the same as steps S403 to S407 of FIG. 4, refer to the drawings below. It will be described later in detail with reference.

In this flowchart, it may be assumed that the DID registration of the first user terminal to the ticket reservation server is completed according to the embodiment illustrated in FIG. 3 .

First, the first user terminal may log in to the ticket reservation server (S401). Since this step is the same as step S301 of FIG. 3 , a redundant description will be omitted.

Next, the first user terminal may request a ticket reservation to the ticket reservation server (S402). This step is an optional step, and may be excluded or replaced with another step depending on the embodiment (particularly, the ticket sales policy of the ticket reservation server).

Next, the ticket reservation server may request the first user terminal to input DID authentication information for self-authentication in order to achieve a limited ticket sales effect for the self-authenticated user account ( S403 ). The first user terminal that has been requested to input DID authentication information may receive identification information (eg, biometric information) for DID authentication from the user by executing an application/web for DID authentication.

When the authentication of the received identification information is completed, the first user terminal may include the stored hash value in the DID authentication request and transmit it to the ticket reservation server (S404). At this time, the hash value is generated based on the unique key value given to the first user terminal to which the first user account is logged in and the unique key value given to the first user biometric information recognized by the first user terminal, As described above.

The ticket reservation server may forward/transmit the received DID authentication request to the DID authentication network (S405). In this case, the DID authentication network may perform the received DID authentication and notify the authentication result to the ticket reservation server and the first user terminal (S406 and S407). DID authentication may be determined based on whether a decryption result value of an encrypted hash value included in the DID authentication request matches a hash value previously stored for the first user account in the DID authentication network.

When the DID authentication request is successful as a result of the authentication request, the ticket reservation server may activate a ticket reservation function for the first user account. That is, the ticket reservation server may allow ticket reservation (or proceed with the ticket reservation procedure) to the first user account whose identity authentication has been completed, and the first user may perform ticket reservation through the ticket reservation server (S408). ).

When a ticket reservation is received from the first user account, the ticket reservation server may transmit a crypto ticket issuance request corresponding to the reserved ticket to the crypto ticket issuing network (S409). The request for issuing a crypto ticket may include ticket reservation information (reservation information, performance date/date/place information, seat information, etc.), and the crypto ticket issuance network will You can issue crypto tickets for The crypto ticket issuance network can be formed of block chain nodes based on block chain technology, and crypto tickets can be issued in the form of crypto currency including ticket reservation information. It's like a bar.

Next, the crypto-ticket issuance network may transmit the crypto-ticket issuance result to the ticket reservation server and/or the first user terminal (S410). The crypto ticket issuance result may be transmitted only to the ticket reservation server, and in this case, the ticket reservation server may transmit the crypto ticket issuance result to the first user terminal.

Although the ticket reservation method through the DID-based self-authentication of FIG. 4 can prevent a large part of ticket sellers from purchasing tickets, as long as the DID verification is completed, tickets can still be reserved by other people. Complete blockade is still impossible. Therefore, in the following, a method for preventing an illegal user from booking a ticket by determining whether an illegal program is used is proposed. In particular, the ticket reservation server according to an embodiment of the present invention is configured in advance to determine the ticket reservation macro program. Algorithms/models/artificial intelligence (AI)/systems may be used to determine illegal/illegal programs (eg, ticket reservation macro programs).

In particular, this flowchart is a flowchart of a method for determining whether to use a ticket reservation macro program that automatically performs ticket reservation through a program. This method may be performed on an account for which login and DID authentication have been completed, and as a result, it may be performed after steps S406 and S407 of FIG. 4 .

First, the ticket reservation server may record a log for each account for the user accounts for which the DID authentication request is successful, and generate a log vector based on the recorded log information (S501). Here, the log vector may correspond to a vector in which a row is a log time and a column is set to the number of log times for each account. In order to generate such a log vector, the ticket reservation server may generate log vectors for each log cluster/group by arranging logs in chronological order, and clustering/grouping logs sorted in chronological order by a preset time unit.

In FIG. 6, the left table 601 is an example table in which log records of a specific user account are arranged in chronological order, and the right table 602 is a row by clustering/grouping the log records of the left table 601 into a specific time range. is an example table in which the log time and column are set to account and the number of logins per account and time is organized. In this case, the log vector is [0, 1, 1, 3]; [2, 1, 1, 1]; [0, 1, 1, 1]; It can be derived as [0, 0, 0, 1].

Referring back to FIG. 5 , next, the ticket reservation server may measure the cosine similarity with the unit vector for each log vector generated for each cluster/group ( S502 ). The cosine similarity may be calculated based on Equation (1).

Here, A denotes a log vector and B denotes a unit vector, respectively.

7 is a graph for recording the cosine similarity change over time according to an embodiment of the present invention, and FIG. 8 is a graph from which self-similarity is derived according to an embodiment of the present invention.

In particular, FIG. 7(a) is a cosine similarity graph when a ticket is reserved using a ticket reservation program, FIG. 7(b) is a cosine similarity graph when a general user makes a ticket reservation, and FIG. 8(a) is a ticket reservation program A self-similarity graph when a ticket is reserved using , and FIG. 8(b) shows a self-similarity graph when a general user makes a ticket reservation, respectively.

Referring to FIG. 7 , when the ticket reservation program is used, since the same/similar operation is repeated, the cosine similarity is maintained within a similar range without significant change, but it can be seen that the cosine similarity of the general user fluctuates greatly. Taking this into consideration, the self-similarity index of the cosine similarity is calculated, and it can be determined that the higher the self-similarity (that is, the closer the self-similarity index value is to 1), the higher the probability of using the ticket reservation macro program.

Referring to FIG. 8 , as a result of the actual experiment, the self-similarity in the case of using the ticket reservation program was derived to a value close to 1, and the self-similarity of the general user was derived to a value less than this (or a number not close to 1). could check

Referring back to FIG. 5 based on the above content, the ticket reservation server may convert the standard deviation of the cosine similarity into a self-similarity index (S503). The self-similarity index may be calculated based on Equation (2).

Here, H corresponds to the self-similarity index, and δ corresponds to the standard deviation of the cosine similarity.

Next, the ticket reservation server may determine whether the self-similarity index value derived in step S503 is close to 1 (S504). The ticket reservation server may read that the closer the self-similarity index value to 1 is, the higher the probability of using the ticket reservation macro program. In this case, the specific determination criterion value may be set to a specific value by the ticket reservation sales server operator/manager/designer. For example, the determination criterion value may be set to 0.9975 by the ticket reservation sales server operator/administrator/designer. can be discerned.

If, as a result of the determination in step S504, it is determined that the ticket reservation macro program is not in use, the ticket reservation server may continue to allow/maintain the progress of ticket reservation for the corresponding user account (S505).

Conversely, when it is determined that the ticket reservation macro program is being used as a result of the determination in step S504, the ticket reservation server may provide a user interface (UI) for finally determining whether to use the macro to the determined user terminal ( S506).

The ticket reservation server may finally determine whether to use the ticket reservation macro program by utilizing various automatic program detection technologies such as reCAPTCHA, CAPTCHA, or random character input UI illustrated in FIG. 9 ( S507 ).

As a result of the final determination, when it is determined that the ticket reservation macro program is being used, the ticket reservation server may disallow the ticket reservation for the user account (S508).

As such, the ticket reservation server according to an embodiment of the present invention reads whether the ticket reservation macro program is used for each account for the user accounts for which the DID authentication request is successful, and the result of the reading is that the ticket reservation macro program is not used. By allowing limited ticket reservations only for user accounts, it is possible to prevent the bulk purchase of tickets by ticket sellers in advance.

In particular, this figure is a diagram illustrating a method of determining a ticket reservation macro program using the K-NN algorithm among artificial intelligence (AI) technologies.

The K-NN (Nearest Neighbor Algorithm) algorithm corresponds to an algorithm that determines the type of data based on the distance between the received data. For example, the K-NN algorithm corresponds to an algorithm that determines the type of data by clustering/grouping K objects located at a close distance, and K can be set to various values by the user. If this is applied to the method of determining the ticket reservation macro program, it is as follows.

As a result of reading S507, if the ticket reservation server reads that a specific user account 1010-1 is using the ticket reservation macro program, using the K-NN algorithm, the usage or log pattern of the user account is K Accounts (1010-2 to 1010-4) can be clustered/grouped. Furthermore, ticket reservations for the clustered/grouped (1010) specific user account 1010-1 and K accounts 1010-2 to 1010-4 may be disallowed. As a result, it is possible to prevent one illegal user from purchasing tickets in bulk using the ticket reservation macro program in the name of another person.

Referring to FIG. 11 , first of all, the first user terminal may transmit a DID authentication request including a hash value stored in the first user terminal to the ticket reservation server, and the ticket reservation server transmits the DID authentication request to the DID authentication network. It can be delivered (S1101). Furthermore, the DID authentication network may perform DID authentication based on the received hash value, and may transmit the authentication result to the ticket reservation server and the first user terminal (S1102). Since the description of these steps corresponds to steps S404 to S407 of FIG. 4 , a redundant description will be omitted.

As a result of the authentication request, when the second DID authentication request is successful, the ticket reservation server may transmit/issuance of a crypto ticket reserved for the first user to the crypto ticket issuing network. The crypto-ticket issuing network may transmit a crypto ticket reserved for the first user terminal to a ticket reservation server, and the ticket reservation server may transmit the received crypto ticket to the first user terminal.

This flowchart is an embodiment continuation of FIG. 4 , and may be performed immediately after completion of FIG. 4 , but may also be performed with a predetermined time difference. That is, the first user may be issued a crypto ticket right after completing the ticket reservation or may be issued for the purpose of confirming the ticket reservation right before the actual entrance to the performance/sports.

The admission management staff of performances/sports will allow admission/re-entry to performances/sports by checking the crypto ticket issued to the user.

Referring to FIG. 12 , the ticket reservation server may include a processor 1110 , a memory unit 1120 , and a communication unit 1130 .

The processor 1110 is a CPU (Central Processing Unit), MPU (Micro Processor Unit), MCU (Micro Controller Unit), AP (Application Processor), AP (Application Processor), or any form well known in the art. It may be configured to include at least one processor. The processor 1110 may perform an operation on at least one application or program for executing the method according to the embodiments of the present invention. The processor 1110 may execute various applications stored in the storage unit 10 and process data inside the server. In addition, it may control units to be described later and manage data transmission/reception between the units.

The memory unit 1120 may store various digital data such as video, audio, photo, moving picture, and application. The memory unit 1120 represents various digital data storage spaces such as a flash memory, a hard disk drive (HDD), and a solid state drive (SSD).

The communication unit 1130 may transmit/receive data by performing communication with the outside using various communication protocols. The communication unit 1130 may transmit/receive digital data by connecting to an external network by wire or wirelessly. In particular, the communication unit 1130 of the present invention may communicate with a user terminal, a DID authentication network, and a crypto-ticket issuance network.

This block diagram can be extended and applied not only to a ticket reservation server, but also to a user terminal, a DID authentication network, and a crypto-ticket issuance network. That is, the user terminal, the DID authentication network, and the crypto-ticket issuing network may also include a processor, a memory unit, and a communication unit, and the description of each unit is as described above.

Embodiments according to the present invention may be implemented by various means, for example, hardware, firmware, software, or a combination thereof. In the case of implementation by hardware, an embodiment of the present invention provides one or more application specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), FPGAs ( field programmable gate arrays), a processor, a controller, a microcontroller, a microprocessor, and the like.

In addition, in the case of implementation by firmware or software, an embodiment of the present invention is implemented in the form of a module, procedure, function, etc. that performs the functions or operations described above, and is stored in a recording medium readable through various computer means. can be recorded. Here, the recording medium may include a program command, a data file, a data structure, etc. alone or in combination. The program instructions recorded on the recording medium may be specially designed and configured for the present invention, or may be known and available to those skilled in the art of computer software. For example, the recording medium includes a magnetic medium such as a hard disk, a floppy disk, and a magnetic tape, an optical recording medium such as a compact disk read only memory (CD-ROM), a digital video disk (DVD), and a floppy disk. Magneto-Optical Media, such as a disk, and hardware devices specially configured to store and execute program instructions, such as ROM, RAM, flash memory, and the like. Examples of program instructions may include high-level language codes that can be executed by a computer using an interpreter or the like as well as machine language codes such as those generated by a compiler. Such hardware devices may be configured to operate as one or more software modules to perform the operations of the present invention, and vice versa.

In addition, the device or terminal according to the present invention may be driven by a command to cause one or more processors to perform the functions and processes described above. For example, such instructions may include interpreted instructions, such as script instructions, such as JavaScript or ECMAScript instructions, or executable code or other instructions stored on a computer-readable medium. Furthermore, the device according to the present invention may be implemented in a distributed manner across a network, such as a server farm, or may be implemented in a single computer device.

Further, a computer program (also known as a program, software, software application, script or code) mounted on the device according to the invention and executing the method according to the invention includes compiled or interpreted language or a priori or procedural language. It can be written in any form of programming language, and can be deployed in any form, including stand-alone programs, modules, components, subroutines, or other units suitable for use in a computer environment. A computer program does not necessarily correspond to a file in a file system. A program may be in a single file provided to the requested program, or in multiple interacting files (eg, files that store one or more modules, subprograms, or portions of code), or portions of files that hold other programs or data. (eg, one or more scripts stored within a markup language document). The computer program may be deployed to be executed on a single computer or multiple computers located at one site or distributed over a plurality of sites and interconnected by a communication network.

Although each drawing is described separately for convenience of description, it is also possible to design to implement a new embodiment by merging the embodiments described in each drawing. In addition, the present invention is not limited to the configuration and method of the described embodiments as described above, but the above-described embodiments are configured by selectively combining all or part of each embodiment so that various modifications can be made. it might be

In addition, although preferred embodiments have been illustrated and described above, the present specification is not limited to the specific embodiments described above, and those of ordinary skill in the art to which the specification belongs without departing from the gist of the claims Various modifications are possible by a person, of course, and these modifications should not be individually understood from the technical spirit or perspective of the present specification.

The present invention can be applied to various blockchain-based identification methods/systems.

Claims

In the ticket reservation method based on DID (Decentralized IDentification),

receiving a first DID authentication request for ticket reservation of a first user account, wherein the first DID authentication request includes an encrypted hash value corresponding to biometric information of the first user account;

forwarding the first DID authentication request to a DID authentication network;

receiving a result of the first DID authentication request from the DID authentication network;

activating a ticket reservation function for the first user account when the first DID authentication request is successful as a result of the authentication request;

when a ticket reservation is received from the first user account, transmitting a crypto ticket issuance request corresponding to the reserved ticket to a crypto ticket issuing network; and

receiving a crypto-ticket issuance request result from the crypto-ticket issuance network; Including, DID-based ticket reservation method.
The method of claim 1,

The hash value is a DID-based ticket generated based on a unique key value assigned to a device to which the first user account is logged in and a unique key value assigned to the first user biometric information recognized by the device How to book.
The method of claim 1,

Whether the first DID authentication request is successful or not,

DID-based ticket reservation method, which is determined by whether a decryption result value of an encrypted hash value included in the first DID authentication request matches a hash value previously stored for the first user account in the DID authentication network .
The method of claim 1,

The crypto-ticket issuance network is formed of blockchain nodes based on blockchain technology, and the crypto-ticket is issued in the form of crypto currency including information about the reserved ticket, a DID-based ticket reservation method.
5. The method of claim 4,

The information about the reserved ticket is blocked and stored in a distributed manner in the blockchain nodes, a DID-based ticket reservation method.
The method of claim 1,

reading whether a ticket reservation macro program is used for each account for the user accounts for which the first DID authentication request is successful; and

restrictingly allowing reservation of the ticket only for a user account that is read as not using the ticket reservation macro program as a result of the reading; Further comprising, DID-based ticket reservation method.
7. The method of claim 6,

The step of reading whether the ticket reservation macro program is used,

recording a log for each account for the user accounts for which the first DID authentication request has been successful, and arranging the log in chronological order;

clustering the logs sorted in the chronological order by a preset time unit;

generating a log vector for each clustered log; Including, DID-based ticket reservation method.
8. The method of claim 7,

A DID-based ticket reservation method, in which a row of the log vector is set to a time, and a column is set to the number of logs for each account.
8. The method of claim 7,

The step of reading whether the ticket reservation macro program is used,

measuring a cosine similarity with a unit vector for each of the log vectors; and

converting the standard deviation of the cosine similarity into a self-similarity index;

reading a higher probability of using the ticket reservation macro program as the value of the self-similarity index is closer to 1; Further comprising, DID-based ticket reservation method.
10. The method of claim 9,

The cosine similarity is calculated based on Equation 1, a DID-based ticket reservation method.

[Equation 1]

A is the log vector, and B is the unit vector.
11. The method of claim 10,

The self-similarity index is calculated based on Equation 2, a DID-based ticket reservation method.

[Equation 2]

wherein H is the self-similarity index, and δ is a standard deviation of the cosine similarity.
10. The method of claim 9,

As a result of the reading, when the use of the ticket reservation macro program of a specific user account is read, K accounts located in close proximity to the specific user account and usage or log pattern using K-NN (Nearest Neighbor Algorithm) algorithm clustering; and

reading the clustered K accounts as accounts using the ticket reservation macro program; Further comprising, DID-based ticket reservation method.
13. The method of claim 12,

providing a reCAPTCHA, CAPTCHA, or random character input UI for the specific user account and the K accounts to finally read whether the specific user account and the K accounts are the ticket reservation macro program users; Further comprising, DID-based ticket reservation method.
5. The method of claim 4,

receiving a second DID authentication request for confirming whether the first user account holds a ticket, wherein the second DID authentication request includes an encrypted hash value corresponding to biometric information of the first user account;

forwarding the second DID authentication request to a DID authentication network;

As a result of the above authentication request:

when the second DID authentication request is successful, sending a crypto ticket issued for the first user account from the crypto ticket issuing network to the first user account;

if the second DID authentication request is successful, transmitting a crypto ticket issued for the first user account from the crypto ticket issuing network to the first user account; Including, DID-based ticket reservation method.