Method and system for event ticket provision, artificial intelligence-based discount verification, seat chart data processing, and user behavior-based suspicious user detection

Abstract

The present invention relates to a method for providing a ticket message related to an event, which is performed by a processor of a server, the method comprising the steps of: generating one or more ticket messages; receiving a verification request, and a public key of a user terminal from the user terminal; when the user terminal is verified, encrypting a first ticket message from among the one or more ticket messages with the public key of the user terminal and transmitting same to the user terminal; receiving a verification request, and a public key of an electronic device from the electronic device; and when the electronic device is verified, encrypting the one or more ticket messages with the public key of the electronic device and transmitting same to the electronic device.

Description

Methods and systems for providing event tickets, verifying discounts based on artificial intelligence, processing seating chart data, and detecting suspicious users based on user behavior.

[0001] The present invention relates to artificial intelligence (AI)-based image processing technology, particularly in the field of computer vision utilizing a Vision Language Model (VLM). More specifically, the present invention relates to a method and a system for recognizing clusters of seats using raw data from seating charts of various spaces, such as concert halls, stadiums, and lecture halls, automatically extracting seat information within each cluster and generating structured data.

[0002] The present invention relates to a technology for detecting suspicious users by analyzing authentication request attempts based on data pattern analysis techniques. More specifically, the present invention relates to a method and system for tracking authentication attempts based on authentication requests and user behavior data received from a server and classifying normal and suspicious users through threshold comparison and data pattern analysis.

[0003] Facilities and services requiring user identification upon entry, including cultural and artistic performances, sporting events, exhibitions, films, concerts, musicals, sports, dance, conventions, and fairs, as well as accommodations, amusement parks, and theme parks, are becoming increasingly diverse and their scale is incomparably larger. Furthermore, the entities responsible for planning, producing, marketing, and operating these facilities and services are becoming increasingly specialized. Furthermore, improvements in ticket reservation and issuance methods have made accessing these facilities and services more convenient for modern users.

[0004] Currently, facilities and services requiring admission are a three-step process: reservation, ticketing, and admission. Each step is managed by a separate operator. Reservations are handled by the reservation operator, ticketing by the event organizer, and admission by the facility service operator. This structure, where each step is managed by a separate operator, presents three major problems.

[0005] First, event organizers face difficulties in leveraging user data. Currently, customers provide user information to ticketing companies. However, ticketing companies limit the scope of consent for third-party provision of user information (e.g., personal information) to "ticketing," preventing service providers other than ticketing companies from accessing customer user information. This makes it difficult for event organizers and service operators to leverage customer data, hindering business growth. This problem is common in all venues requiring identity verification, including concert halls, stadiums, exhibition halls, convention centers, accommodations, and amusement parks.

[0006] Second, there are stability issues with admission confirmation due to network failures. When multiple users access the network through their terminals to check their user or reservation information, increased traffic can cause communication failures. Furthermore, the lack of a service backup in the event of a network failure can lead to issues with event delivery procedures. This is particularly true for large-scale facilities or popular services, where ticket reservation sites frequently become overwhelmed by traffic, leading to site crashes. This same issue can also occur with current mobile ticketing services, where network overload can lead to significant service delays when numerous users simultaneously attempt to check their mobile tickets for admission. These issues can arise in any situation where large numbers of people enter simultaneously, such as major sporting events, popular performances, large-scale exhibitions, peak season accommodations, and weekend amusement parks.

[0007] Third, there's the issue of manual verification of eligibility for discounts. Previously, people verified and / or determined eligibility for discounts. This process often resulted in delays for users. Furthermore, the verification process often made it difficult for the individuals conducting the verification to apply consistent standards, potentially leading to discrepancies in the verification results. This issue is common across all facilities and services offering various discount policies, including welfare discounts, national merit discounts, group discounts, and membership discounts.

[0008] Meanwhile, verification and determination of discount eligibility requirements can be performed using rule-based algorithms. However, discount policies and requirements are diverse and can be newly introduced at any time. However, implementing these policies using rule-based algorithms presents limitations in defining various discount eligibility requirements and supporting documentation. Furthermore, each discount policy requires its own processing unit. Therefore, automating verification and / or determination of discount eligibility requirements using rule-based algorithms is extremely challenging. Therefore, to promote the revitalization of all facilities and services requiring identity verification, including cultural and artistic events, sports events, MICE (Meetings, Incentives, Incentives), accommodations, and amusement parks, a solution is needed that enables operators to gain customer data insights, provides a mobile ticketing system that operates reliably even in network failure situations, and utilizes AI models to automatically verify eligibility for discounts.

[0009] [Prior Art Literature]

[0010] [Patent Document]

[0011] Korean Patent Publication No. 10-2021-0124685 (Published: October 15, 2021)

[0012]

[0013] In spaces such as performance halls, stadiums, and conference halls that accommodate multiple seats, it is essential to systematically manage seating information and digitize seating charts to provide them to reservation systems or operating platforms.

[0014] This digital seating information construction process involved, for example, manually assigning each seat location and number to an image-based seating chart, and directly entering information like section names and labels. While this approach is applicable to simple layouts, it is labor-intensive, prone to errors, and difficult to maintain overall coordinate consistency.

[0015] Another way to build digital seating information is to define seats as vector objects, for example, using CAD-based drawings or templates provided by specific editing tools. While this approach is advantageous for regular structures, it presents significant limitations in expressing seating in complex curved arrangements, asymmetrical blocks, and individually named seating areas, as in actual performance halls or auditoriums, and it lacks consistency with intuitive layouts.

[0016] While these existing technologies can handle the extraction of information at the individual seat level to a certain extent, they have limitations in understanding the semantic structure of seat formations or sections and converting it into practically usable data for the system. Consequently, technologies for automatically interpreting and structuring seat information remain elusive. Consequently, the technological means for automatically constructing the seat information desired by operators (e.g., coordinates, numbers, section names, etc.) are inadequate. Consequently, constructing digital seat information remains a human-dependent and error-prone task.

[0017] Furthermore, mobile ticketing and management systems are widely used in various events, including performances, sporting events, and exhibitions. These mobile ticketing systems offer the advantage of reducing problems associated with paper tickets, such as loss, forgery, and duplicate use, and streamlining ticketing and verification processes. However, despite the prevalence of ticket scalping in actual operations, technological means to effectively detect and prevent this practice are lacking.

[0018] For example, if a ticket scalper creates multiple accounts, or if buyers and sellers share a public machine or account to disguise themselves as legitimate ticket holders, existing mobile ticketing systems can struggle to distinguish between these situations. In such situations, repeated log-ins from the same device or simultaneous access to the same account from multiple user devices can occur. However, existing systems often treat these as mere access records rather than identifying them as abnormal transactions.

[0019] Thus, while current mobile ticket management technology can perform the basic functions of issuing and verifying tickets, it lacks the structural and technological capabilities to detect and deter the frequent black market transactions that occur in the field. As a result, operators are unable to conduct in-depth analysis based on transaction patterns or terminal usage, and the prevention of black market transactions remains inadequate.

[0020] The present invention has been conceived with the above-described purpose in mind, and its purpose is to provide a solution that enables safe and easy utilization of user information in all facilities and services requiring entry.

[0021] Specifically, the purpose of the present invention is to provide a solution that enables event organizers to utilize user information collected by reservation service providers as data insights.

[0022] In addition, an object of the present invention is to provide an offline ticket verification service that can safely verify an encrypted ticket message even in a network failure situation.

[0023] In addition, an object of the present invention is to provide a system that can automatically verify whether discount eligibility requirements are met by utilizing an artificial intelligence model based on natural language processing.

[0024] In addition, the purpose of the present invention is to provide more advanced solutions utilizing data, such as ticket management based on transmission history data, audience management CRM service, and data marketing, by utilizing ticket event data.

[0025] The purpose of the present invention is to overcome the limitations of the existing technology described above and to provide a technology for efficiently and accurately digitizing a seating structure from original data of a seating chart.

[0026] Specifically, the problem that the present invention seeks to solve is to provide a means for automatically identifying visually distinct seat clusters or zone information from original data of a seating chart.

[0027] In addition, the problem to be solved by the present invention is to provide a method capable of precisely extracting information such as the location, number, and row / column label of an individual seat within an identified seat cluster.

[0028] In addition, the problem to be solved by the present invention is to provide a means for converting extracted seat information into structured data that can be linked with an external editor or reservation system without separate post-processing by maintaining the extracted seat information in a normalized state according to the entire image reference coordinate system.

[0029] In addition, the problem to be solved by the present invention is to provide a data structure that can express generated structured data in, for example, JSON format, but is not limited thereto and can be expanded into various formats.

[0030] In addition, the problem to be solved by the present invention is to provide an automated analysis method that can be flexibly applied to a seating chart having a non-standard or complex seating structure.

[0031] The purpose of the present invention is to overcome the limitations of the existing mobile ticket system described above and to provide a technology capable of effectively detecting and preventing black market ticket transactions.

[0032] Specifically, the problem that the present invention seeks to solve is to provide a means for distinguishing between normal usage behavior and abnormal black market ticket trading behavior by analyzing data such as the user terminal's access pattern, account usage history, and terminal characteristics.

[0033] In addition, the problem that the present invention seeks to solve is to provide a structure that can identify suspicious behavior such as multiple use of the same account or repeated logins in real time by linking the data flow between a user terminal, a server, and an external server throughout the entire process from ticket issuance to on-site verification.

[0034] In addition, the problem that the present invention seeks to solve is to provide a method that can suppress the act of ticket blacklisters and / or ticket owners disguising themselves as normal users through linkage with an external server, such as financial authentication or SMS / OTP authentication, at the time of ticket use.

[0035] In addition, the problem to be solved by the present invention is to provide a data feedback loop that can provide more sophisticated black market ticket detection performance over time by storing collected data and analysis results in a structured form within a server and learning repetitive transaction patterns based on the collected data and analysis results.

[0036] In addition, the problem to be solved by the present invention is to provide a structured analysis method that can be flexibly applied so that the detection and prevention function can be expanded to various event application environments such as performance halls, stadiums, exhibitions, and transportation reservations.

[0037] A method for managing user information according to the present invention comprises the steps of: uploading a user list to a storage means; transmitting a scheme related to ticketing for an event to user terminals of at least some of the users included in the user list; and storing the user information input through a GUI (Graphical User Interface) provided through the scheme.

[0038] In addition, the method may further include a step of generating ticket information regarding the event based on the user information; and a step of storing the ticket information.

[0039] A method for providing a service based on user information according to the present invention comprises the steps of: transmitting a scheme related to ticket issuance for an event to user terminals of at least some of one or more users listed in a user list; storing the user information input through a GUI (Graphical User Interface) provided through the scheme; analyzing the characteristics of the user based on the user information; and transmitting the analysis results on the characteristics of the user to an external server.

[0040] In addition, the method may further include a step of generating ticket information regarding the event based on the user information; and a step of transmitting the ticket information to the terminal.

[0041] A method for providing a ticket message of an event to a user terminal according to the present invention comprises the steps of: receiving verification data of the user terminal, electronic signature data encrypted by a public key from the verification data, and the public key from the user terminal; decrypting the encrypted electronic signature data using the received public key; verifying the user terminal by matching the decrypted electronic signature data with the received verification data; encrypting the ticket message using the public key; and transmitting the encrypted ticket message to the verified user terminal.

[0042] In addition, the method may further include a step of receiving a private key from the user terminal; a step of encrypting the ticket message with the received private key; and a step of causing the user terminal to generate an identification code or identification tag corresponding to the ticket message based on the ticket message encrypted with the private key.

[0043] In addition, the ticket message may include at least one of ticket information, event information, and user information, wherein the ticket information may include at least one of issuance information, a seat number, and delivery information of the ticket, and the event information may include at least one of the date and time and location of the event.

[0044] Additionally, the ticket message may further include at least one of discount code information and verification code information.

[0045] A method for providing an event ticket message to an electronic device according to the present invention comprises the steps of: verifying the electronic device; encrypting the ticket message using a public key; and transmitting the encrypted ticket message to the verified electronic device.

[0046] In addition, the method further includes a step of receiving verification data of the electronic device from the electronic device, electronic signature data encrypted by the public key from the verification data, and the public key; and a step of decrypting the encrypted electronic signature data using the received public key; and the step of verifying the electronic device may verify the electronic device by matching the decrypted electronic signature data with the received verification data.

[0047] Additionally, the step of verifying the electronic device may verify the electronic device based on an encrypted code or tag.

[0048] Additionally, the step of verifying the electronic device may verify the electronic device based on a code consisting of one or a combination of letters, numbers, and special characters.

[0049] In addition, the method further includes a step of encrypting a private key assigned to the event using the received public key; and a step of transmitting the encrypted private key to the electronic device; wherein the private key may be a key capable of decrypting the encrypted ticket message.

[0050] Additionally, the ticket message may include at least one of ticket information, event information, and user information, wherein the ticket information may include at least one of issuance information, a seat number, and delivery information of the ticket, and the event information may include at least one of the date and time and location of the event.

[0051] Additionally, the ticket message may further include at least one of discount code information and a verification code of the encrypted ticket message.

[0052] Additionally, at least one of the ticket information, the event information, and the user information may be encrypted by a symmetric key.

[0053] In addition, the method may further include a step of transmitting the symmetric key to the electronic device.

[0054] A method for verifying an encrypted ticket message according to the present invention comprises the steps of: receiving, from a user terminal, the encrypted ticket message, verification data of the user terminal, electronic signature data encrypted by a public key from the verification data, and the public key; decrypting the encrypted electronic signature data using the received public key; verifying the user terminal by matching the decrypted electronic signature data with the received verification data; decrypting the received ticket message using a pre-stored private key; and matching the decrypted ticket message with pre-stored ticket message verification data.

[0055] In addition, the method may further include a step of transmitting the result data of the matching to a server device when the decrypted ticket message matches the previously stored ticket message verification data.

[0056] In addition, the ticket message may include at least one of ticket information, event information, and user information, wherein the ticket information may include at least one of issuance information, a seat number, and delivery information of the ticket, and the event information may include at least one of the date and time of the event and the location of the event.

[0057] Additionally, the ticket message may further include at least one of discount code information and a verification code of the encrypted ticket message.

[0058] In addition, if there is no data matching the decrypted ticket message among the previously stored ticket message verification data, the method may further include a step of transmitting verification request information for the decrypted ticket message to the server device.

[0059] In addition, the method may further include a step of receiving verification result data transmitted based on the verification request information from the server device.

[0060] A method for verifying a ticket message including information encrypted by a symmetric key according to the present invention comprises the steps of: receiving, from a user terminal, the ticket message, verification data of the user terminal, electronic signature data encrypted by a public key from the verification data, and the public key; decrypting the encrypted electronic signature data using the received public key; verifying the user terminal by matching the decrypted electronic signature data with the received verification data; decrypting the received ticket message using the pre-stored symmetric key; and matching the decrypted ticket message with pre-stored ticket message verification data.

[0061] In addition, the method may further include a step of receiving user information from the user terminal; a step of encrypting the received user information with a pre-stored private key; and a step of matching the encrypted user information with pre-stored user information verification data.

[0062] In addition, the method may further include a step of storing the result data of the matching when the encrypted user information matches the previously stored user information verification data.

[0063] Additionally, the ticket message includes at least one of ticket information, information about the event, and user information, and the user information may be information encrypted with the private key.

[0064] Additionally, the ticket information may include at least one of issuance information, seat number, and delivery information of the ticket, and the event information may include at least one of the date and time of the event and the location of the event.

[0065] In addition, the method may include a step of requesting a discount certificate from a user, a step of receiving information and a certificate document for the discount certificate, a step of identifying the text of the certificate document, and a step of verifying the validity of the discount based on the input information and the identified text for the discount certificate.

[0066] In addition, the step of identifying the text of the supporting document may further include a step of identifying the text based on optical character recognition (OCR), and the step of verifying the validity of the discount may further include a step of verifying the validity of the discount based on an artificial intelligence model based on natural language processing.

[0067] In addition, the method further includes a step of identifying input data and a step of verifying the input data, and learning of the artificial intelligence model can be performed based on at least one of the result of identifying the input data and the result of verifying the input data.

[0068] Additionally, the information for the discount verification may include at least one of user identification information, event identification information, and discount identification information.

[0069] A method performed by a processor of a server according to one embodiment of the present invention, wherein the method for providing a ticket message related to an event may include the steps of: generating one or more ticket messages; receiving, from a user terminal, a verification request and a public key of the user terminal; when the user terminal is verified, encrypting a first ticket message among the one or more ticket messages with the public key of the user terminal and transmitting the same to the user terminal; receiving, from an electronic device, a verification request and a public key of the electronic device; and when the electronic device is verified, encrypting the one or more ticket messages with the public key of the electronic device and transmitting the same to the electronic device.

[0070] In addition, in a method for providing a ticket message related to an event, the ticket message includes user information, and the ticket message may include at least one of ID information for identifying the ticket message, ticket information, discount voucher information, and event information.

[0071] In addition, in a method for providing a ticket message related to an event, the user information includes user identification information, and the user information may be encrypted with a secret key of the user terminal.

[0072] In addition, in a method for providing a ticket message related to an event, the ticket information may include at least one of issuance information, seat information, and delivery information of the ticket, and the event information may include at least one of date and time information of the event and location information of the event.

[0073] Additionally, in a method for providing a ticket message related to an event, at least one of the user information, the ticket information, the discount voucher information, and the event information may be encrypted with a ticket secret key.

[0074] Meanwhile, a method performed by a processor of an electronic device according to an embodiment of the present invention, a method for verifying a ticket message related to an event may include the steps of: receiving, from a server, a public key assigned to the event, one or more ticket messages encrypted with the public key assigned to the event, and a private key assigned to the event; decrypting the encrypted one or more ticket messages with the private key assigned to the event; receiving, from a user terminal, a verification request, a public key of the user terminal, and a first ticket message encrypted with the public key assigned to the event; and, when the verification of the user terminal is completed, decrypting the encrypted first ticket message with the private key assigned to the event, and comparing the decrypted first ticket message with the one or more decrypted ticket messages to verify the first ticket message.

[0075] In addition, in a method for verifying a ticket message related to an event, the ticket message includes user information, and the ticket message may include at least one of ID information for identifying the ticket message, ticket information, discount voucher information, and event information.

[0076] Additionally, in a method for verifying a ticket message related to an event, the user information includes user identification information, and the user information may be encrypted with a secret key of the user terminal.

[0077] In addition, in a method for verifying a ticket message related to an event, the ticket information may include at least one of issuance information, seat information, and delivery information of the ticket, and the event information may include at least one of date and time information of the event and location information of the event.

[0078] Additionally, in a method for verifying a ticket message related to an event, at least one of the user information, the ticket information, the discount voucher information, and the event information may be encrypted with a ticket secret key.

[0079] In addition, a method for verifying a ticket message related to an event may further include a step of receiving the secret key of the user terminal from the user terminal, a step of decrypting the encrypted user information included in the decrypted first ticket message using the received secret key, and a step of performing verification on the user information based on the decrypted user information.

[0080] Additionally, the method for verifying a ticket message related to an event may further include a step of requesting additional verification of the first ticket message from the server.

[0081] A method performed by a processor of an electronic device according to one embodiment of the present invention, wherein the method for providing a ticket message related to an event may include the steps of: receiving a public key assigned to the event and a private key assigned to the ticket message from a server; receiving, from a user terminal, a verification request, a request for generating the ticket message, and a public key of the user terminal; generating, when the user terminal is verified, the ticket message, the ticket message including information encrypted with the private key assigned to the ticket message; encrypting the generated ticket message with the public key of the user terminal; and transmitting the encrypted ticket message to the user terminal.

[0082] In addition, in a method for providing a ticket message related to an event, the ticket message includes user information, and the ticket message may include at least one of ID information for identifying the ticket message, ticket information, discount voucher information, and event information.

[0083] In addition, in a method for providing a ticket message related to an event, the user information includes user identification information, and the user information may be encrypted with a secret key of the user terminal.

[0084] In addition, in a method for providing a ticket message related to an event, the ticket information may include at least one of issuance information, seat information, and delivery information of the ticket, and the event information may include at least one of date and time information of the event and location information of the event.

[0085] Additionally, in a method for providing a ticket message related to an event, at least one of the user information, the ticket information, the discount voucher information, and the event information may be encrypted with a ticket secret key.

[0086] Additionally, the method may include a step of receiving information and supporting documents for discount verification, a step of identifying text included in the input supporting documents, and a step of verifying the validity of the discount based on the input information and the identified text for discount verification through one or more agents.

[0087] Additionally, the one or more agents may include a first agent, a second agent, and a third agent, wherein the first agent is an agent for collecting and organizing the pressed information, the second agent is an agent for identifying and verifying the input information, and the third agent may be an agent for managing the overall operation of the artificial intelligence model.

[0088] Additionally, each of said one or more agents includes a system prompt including instructions about at least one of the role, purpose, instructions, constraints and tools of said respective agent, and a user prompt including at least one of a request, context and additional information input by a user, and each of said one or more agents may include at least one of a database access tool, a web search tool, an API integration tool, a natural language processing tool and an automated workflow tool.

[0089] In addition, the information for the discount verification includes name information for the discount policy, and at least one of the one or more agents defines a discount eligibility requirement necessary for discount validation based on the name information for the discount policy and the text identified from the input verification document, and at least one of the one or more agents can perform the discount validation based on the defined discount eligibility requirement.

[0090] Additionally, the information for the discount verification includes discount information, wherein the discount information includes name information about the discount policy and description information about the discount policy, and at least one of the one or more agents can perform the discount validity verification based on the discount information and the text identified from the input verification document.

[0091] In addition, the method further includes a step of performing a review of the input supporting document and a step of determining whether to re-enter the supporting document based on the result of the review, and the step of identifying text included in the input supporting document may include a step of identifying text included in the supporting document for which the review was performed.

[0092] In addition, the method may further include a step of generating a summary of the discount validation result through the one or more agents and a step of outputting the generated summary.

[0093] In addition, the method may further include a step of classifying the reliability of the discount validation result into one or more categories through the one or more agents and a step of outputting the classified categories.

[0094] In addition, the method may further include a preprocessing step of modifying at least one of the information for the discount verification and the identified text, and the step of verifying the discount validity may include a step of verifying the discount validity based on at least one of the preprocessed information and text.

[0095] A method performed on a server according to one embodiment of the present invention, wherein the method for generating seat data by analyzing original data of a seating chart may include: receiving, through a communication unit of the server, the original data of the seating chart input to a user terminal; inputting, through a processor unit of the server, the original data and a first prompt into a vision-language model (VLM) to extract a seat cluster data list of the seating chart; parsing, through the processor unit, one or more seat cluster data from the extracted seat cluster data list; inputting, through the processor unit, the parsed one or more seat cluster data and a second prompt into the VLM to extract one or more individual seat data within the one or more seat cluster data; parsing, through the processor unit, the extracted individual seat data; integrating, through the processor unit, the parsed individual seat data into a single structured data corresponding to the seating chart; and transmitting, through the communication unit, the integrated single structured data to the user terminal.

[0096] Additionally, the step of parsing the one or more seat cluster data may further include the step of outputting blank structured data if the seat cluster data does not exist.

[0097] Additionally, the step of parsing the one or more seat cluster data may include a step of extracting at least one of a cluster name and bounding box coordinate information from the extracted seat cluster data list.

[0098] Additionally, the step of parsing the individual seat data may include a step of extracting at least one of seat coordinate information, seat number information, row / column information of the seat, and additional text information from the extracted individual seat data.

[0099] Additionally, the first prompt may include instructions to identify visually independent seat clusters within the original data and to extract names and bounding box information of the seat clusters.

[0100] Additionally, the second prompt may include a name and bounding box information of the seat cluster, and an instruction to extract the individual seat data within the area of ​​the seat cluster.

[0101] A server for generating seat data by analyzing original data of a seating chart according to one embodiment of the present invention includes a communication unit; and a processor unit; wherein the communication unit is configured to receive the original data of the seating chart input to a user terminal, and the processor unit may be configured to: input the original data and a first prompt into a vision-language model (VLM) to extract a seat cluster data list of the seating chart; parse one or more seat cluster data from the extracted seat cluster data list; input the parsed one or more seat cluster data and a second prompt into the VLM to extract one or more individual seat data within the one or more seat cluster data; parse the extracted individual seat data; integrate the parsed individual seat data into a single structured data corresponding to the seating chart; and transmit the integrated single structured data to the user terminal.

[0102] Additionally, the processor may be configured to output blank structured data if the seat cluster data does not exist.

[0103] Additionally, the processor may be configured to extract at least one of cluster name and bounding box coordinate information from the extracted seat cluster data list.

[0104] Additionally, the processor may be configured to extract at least one of seat coordinate information, seat number information, seat row / column information, and additional text information from the extracted individual seat data.

[0105] Additionally, the first prompt may include instructions to identify visually independent seat clusters within the original data and to extract names and bounding box information of the seat clusters.

[0106] Additionally, the second prompt may include a name and bounding box information of the seat cluster, and an instruction to extract the individual seat data within the area of ​​the seat cluster.

[0107] In one embodiment of the present invention, a server for generating seat data by analyzing original data of a seating chart may be configured to: receive an authentication request from a user terminal or an electronic device through a communication unit of the server; track an authentication attempt based on information included in the authentication request through a processor unit of the server; compare the number of authentication attempts with a threshold value through the processor unit; classify a user as a suspicious user if the comparison result is greater than or equal to the threshold value through the processor unit, and determine to proceed with a normal procedure if the comparison result is less than the threshold value; store user behavior data during the authentication request processing through the processor unit; analyze a data pattern based on the user behavior data through the processor unit; update a suspicious user classification criterion based on a result of the data pattern analysis through the processor unit; and transmit a result value of the suspicious user classification to the user terminal or the electronic device through the communication unit.

[0108] In a server for generating seat data by analyzing original data of a seating chart according to one embodiment of the present invention, the authentication request may include at least one of user account identification information, request type, request time, network connection information, user terminal environment information, and session identification information.

[0109] In addition, the step of tracking the authentication attempt may include a step of tracking the authentication attempt history based on one or more pieces of information included in the authentication request, and tracking at least one of the request time, request result, authentication method, and authentication path of each authentication attempt included in the tracked authentication attempt history.

[0110] Additionally, the threshold value may be set to a fixed value or may be dynamically adjusted by considering at least one of a time interval, a service type, an event attribute, a user group attribute, and an authentication failure type.

[0111] Additionally, the user behavior data may include at least one of authentication success or failure, authentication attempt interval, session duration, user terminal environment information, network connection information, user account identification information, and session identification information.

[0112] Additionally, the step of analyzing the data pattern may include a step of classifying a normal user group and a suspicious user group by performing statistical correlation analysis or clustering analysis of the user behavior data.

[0113] Additionally, the step of updating the above suspicious user classification criteria may include updating a statistical threshold, rule-based condition, or parameter of a machine learning model by reflecting the results of the data pattern analysis.

[0114] A server for detecting a suspicious user according to one embodiment of the present invention comprises: a communication unit; and a processor unit; wherein the communication unit is configured to receive an authentication request from a user terminal or an electronic device, and the processor unit is configured to: track authentication attempts based on information included in the authentication request; compare the number of authentication attempts with a threshold; classify the user as a suspicious user when the comparison result is greater than or equal to the threshold, and determine to proceed with a normal procedure when the comparison result is less than the threshold; store user behavior data during the authentication request processing; analyze a data pattern based on the user behavior data; and update a suspicious user classification criterion according to a result of the data pattern analysis, and the communication unit may be configured to transmit a result value of the suspicious user classification to the user terminal or the electronic device.

[0115] Additionally, the authentication request may include at least one of user account identification information, request type, request time, network connection information, user terminal environment information, and session identification information.

[0116] In addition, the processor unit may be configured to track authentication attempt history based on one or more pieces of information included in the authentication request, and to track at least one of a request time, a request result, an authentication method, and an authentication path of each authentication attempt included in the tracked authentication attempt history.

[0117] Additionally, the threshold value may be set to a fixed value or may be dynamically adjusted by considering at least one of a time interval, a service type, an event attribute, a user group attribute, and an authentication failure type.

[0118] Additionally, the user behavior data may include at least one of authentication success or failure, authentication attempt interval, session duration, user terminal environment information, network connection information, user account identification information, and session identification information.

[0119] Additionally, the processor unit may be configured to perform statistical correlation analysis or clustering analysis of the user behavior data to classify a normal user group and a suspicious user group.

[0120] Additionally, the processor unit may be configured to update a statistical threshold, a rule-based condition, or a parameter of a machine learning model by reflecting the results of the data pattern analysis.

[0121] The present invention facilitates the safe and easy utilization of user information, thereby facilitating the reservation and issuance of event tickets. Furthermore, the present invention enables ticket transfer history data-based ticket management.

[0122] The present invention can provide a solution that enables safe and easy utilization of user information in all facilities and services requiring entry.

[0123] The present invention can provide a solution that enables event organizers to utilize user information collected by reservation service providers as data insights.

[0124] The present invention can provide an offline ticket verification service that can safely verify an encrypted ticket message even in a network failure situation.

[0125] The present invention can provide a system that can verify whether discount eligibility requirements are met by utilizing an artificial intelligence model based on natural language processing.

[0126] The present invention can provide more advanced solutions utilizing data, such as ticket management based on transmission history data, audience management CRM service, and data marketing, by utilizing ticket event data.

[0127] The present invention can recognize seat clusters from original data of a seating chart, extract individual seat information within each cluster, and generate structured data.

[0128] The present invention enables automation of the work of constructing seat information, thereby drastically reducing the time and cost required for data construction compared to existing methods that depended on manual work.

[0129] The present invention enables interpretation of visual clustering and row / column information for various types of seating charts through VLM-based inference, thereby enabling high-accuracy data processing even for non-standard and complex structures that were difficult to automatically process using existing methods.

[0130] The present invention can effectively identify black market ticket trading activities by comprehensively analyzing ticket usage history, access patterns, and terminal characteristics through linkage between a user terminal and a server.

[0131] The present invention can include a financial authentication or OTP authentication procedure based on connection with an external server during the ticket use process, thereby preventing ticket scalpers or ticket owners from disguising themselves as legitimate owners in advance.

[0132] Figure 1a is a conceptual diagram illustrating the configuration of a system for providing a service according to the present invention.

[0133] FIG. 1b is a block diagram illustrating a server (100) according to one embodiment of the present invention.

[0134] FIG. 1c is a block diagram illustrating an electronic device (200) according to one embodiment of the present invention.

[0135] FIG. 1d is a block diagram illustrating a user terminal (300) according to one embodiment of the present invention.

[0136] FIG. 2 is a conceptual diagram illustrating a method for collecting and preparing user information according to one embodiment of the present invention.

[0137] FIG. 3 is a flowchart illustrating a first embodiment of a method for providing a service based on user information according to the present invention.

[0138] FIG. 4 is a flowchart illustrating a second embodiment of a method for providing a service based on user information according to the present invention.

[0139] FIG. 5 is a flowchart of a method for providing an event ticket message to a user terminal according to the present invention.

[0140] FIG. 6A and FIG. 6B are diagrams showing the structure of a ticket message according to embodiments of the present invention.

[0141] Figure 7 is a diagram illustrating various encryption methods.

[0142] Figure 8 is a diagram showing the process of creating and verifying an electronic signature.

[0143] Figures 9 to 12 illustrate each step of the flowchart of Figure 5.

[0144] FIG. 13 is a flowchart illustrating a method for providing an event ticket message to an electronic device according to the present invention.

[0145] FIG. 14 is a flowchart illustrating a detailed embodiment of a method for providing an event ticket message to an electronic device according to the present invention.

[0146] Figure 15 is a conceptual diagram for explaining the flowcharts of Figures 13 and 14.

[0147] Figure 16 is a flowchart of a method for verifying an encrypted ticket message according to the present invention.

[0148] Figures 17a and 17b are conceptual diagrams for explaining the flow chart of Figure 16.

[0149] Figures 18a and 18b are conceptual diagrams for explaining the flow chart of Figure 16.

[0150] FIG. 19 is a flowchart of a method for verifying a ticket message including information encrypted by a symmetric key according to the present invention.

[0151] FIG. 20 is a diagram illustrating a method for verifying a ticket message in an offline situation, according to one embodiment of the present invention.

[0152] FIG. 21a and FIG. 21b are diagrams for explaining a method for decrypting an encrypted ticket message according to one embodiment of the present invention.

[0153] FIG. 22a and FIG. 22b are diagrams for explaining a method for decrypting an encrypted ticket message according to one embodiment of the present invention.

[0154] FIG. 23 is a diagram for explaining a method of transmitting and receiving data between an electronic device (200) and a user terminal (300) to verify a ticket message according to one embodiment of the present invention.

[0155] FIG. 24 is a diagram for explaining a method of transmitting and receiving data between an electronic device (200) and a user terminal (300) to verify user information according to one embodiment of the present invention.

[0156] FIG. 25 is a diagram for explaining a method of transmitting and receiving data between an electronic device (200) and a server (100) after verifying a ticket message in an offline situation according to one embodiment of the present invention.

[0157] FIG. 26 and FIG. 27 are diagrams for explaining a method for providing a ticket message in an offline situation according to one embodiment of the present invention.

[0158] FIG. 28 is a drawing for explaining an encryption ticket system according to one embodiment of the present invention.

[0159] FIG. 29 is a drawing for explaining an encryption ticket system according to one embodiment of the present invention.

[0160] FIG. 30 is a drawing for explaining an encryption ticket system according to one embodiment of the present invention.

[0161] FIGS. 31A and 31B are flowcharts illustrating a method for automating verification of whether discount eligibility requirements are met based on artificial intelligence according to one embodiment of the present invention.

[0162] Figure 31c is a flowchart illustrating an artificial intelligence-based discount validity verification method and a method for improving a verification model according to one embodiment of the present invention.

[0163] FIGS. 32a to 32c are tables for explaining information for discount verification input and / or received in step (S710) illustrated in FIG. 31a or step (S710`) illustrated in FIG. 31b.

[0164] FIG. 32d is a drawing for explaining a supporting document input and / or received in step (S720) illustrated in FIG. 31a or step (S720`) illustrated in FIG. 31b.

[0165] FIGS. 33a and 33b are flowcharts illustrating the operation of agent components that perform a method for automating verification of whether artificial intelligence-based discount eligibility requirements are met according to one embodiment of the present invention.

[0166] Figure 34a is a flowchart for explaining the operation of the first agent (1000) component illustrated in Figure 33a.

[0167] Figure 34b is a flowchart for explaining the operation of the second agent (2000) component illustrated in Figure 33a.

[0168] Figures 35a to 35d are conceptual diagrams for explaining the configuration of a system for providing a service according to one embodiment of the present invention.

[0169] Fig. 36 is a block diagram for explaining an external server (20) according to one embodiment of the present invention.

[0170] Figure 37 is a flowchart for explaining a method for analyzing original data of a seating chart according to one embodiment of the present invention.

[0171] FIG. 38a is a drawing for explaining original data related to a seating arrangement according to one embodiment of the present invention.

[0172] FIG. 38b is a diagram illustrating bounding boxes corresponding to one or more clusters identified from original data related to a seating chart according to one embodiment of the present invention.

[0173] FIG. 38c is a diagram illustrating individual seat data included in one or more clusters according to one embodiment of the present invention.

[0174] Figure 39 is a flowchart illustrating a method for detecting a suspicious user according to one embodiment of the present invention.

[0175] FIG. 41 is a diagram illustrating a method for identifying normal users and suspicious user groups by analyzing patterns of user data according to one embodiment of the present invention.

[0176] In describing the embodiments disclosed in this specification, detailed descriptions of related known technologies will be omitted if it is determined that such detailed descriptions may obscure the gist of the embodiments disclosed in this specification. In addition, the attached drawings are provided solely to facilitate understanding of the embodiments disclosed in this specification, and the technical concepts disclosed in this specification are not limited by the attached drawings, and should be understood to include all modifications, equivalents, and substitutes included within the spirit and technical scope of the present invention.

[0177] Overall composition

[0178] FIG. 1A is a conceptual diagram illustrating the configuration of a system for providing a service according to the present invention. FIG. 1B is a block diagram illustrating a server (100) according to one embodiment of the present invention. FIG. 1C is a block diagram illustrating an electronic device (200) according to one embodiment of the present invention. FIG. 1D is a block diagram illustrating a user terminal (300) according to one embodiment of the present invention.

[0179] As illustrated in FIG. 1A, a system according to the present invention may include a server (100), an electronic device (200), and a user terminal (300). In the system according to the present invention, the server (100), the electronic device (200), and the user terminal (300) may mutually transmit and receive data for the system of the present invention via a network. Here, the system illustrated in FIG. 1A is according to one embodiment, and its components are not limited to the embodiment illustrated in FIG. 1A, and may be added, changed, or deleted as needed.

[0180] In one embodiment of the present invention, when a user terminal (300) inputs user information while requesting issuance and / or generation of a ticket to a server (100), the user information may be stored in the server (100). In addition, the server (100) may transmit an issuance and / or generation event ticket message to the user terminal (300) and / or the electronic device (200), and the user terminal (300) and / or the electronic device (200) may store the event ticket message.

[0181] When the user terminal (300) transmits the public key (e.g., RSA) of the user terminal to the electronic device (200) and requests verification of the user terminal (300), and transmits a ticket message (10) to the electronic device (200) and requests verification of the ticket message (10), the electronic device (200) can perform verification of the ticket message (10) using one or more keys (e.g., secret key, private key, etc.) that it has previously received from the server (100) and temporarily or non-temporarily stored. However, the role of each device is not limited thereto.

[0182] Specifically, the electronic device (200) may be implemented as a server (100), and the server (100) may perform the functions of the electronic device (200). Alternatively, both the server (100) and the electronic device (200) may be implemented as a user terminal (300), and the user terminal (300) may perform the functions of the server (100) and the electronic device (200). For example, at the request of the user terminal (300), the electronic device (200) may perform an issuing and / or generating operation of a ticket message (10), while the electronic device (200) may perform a verification operation of the ticket message (10). In addition, storing 'information' and / or 'key', etc., hereinafter may be understood to mean storing temporarily and / or non-temporarily. In addition, 'transmission', 'transmitting', and 'delivering' hereinafter may be used with the same meaning.

[0183] Server (100)

[0184] According to the present invention, the server (100) may be an electronic device equipped with a processor, memory, and computing power, such as a personal computer (PC), laptop computer, tablet PC, or mobile phone. Furthermore, the server (100) may be a web server that processes services.

[0185] According to the present invention, the server (100) may be a central server or a cloud server. The server (100) may consist of a single server or multiple servers. The types and configurations of servers described above are merely examples, and the present invention is not limited thereto.

[0186] FIG. 1B is a block diagram illustrating a server (100) according to one embodiment of the present invention. According to FIG. 1B, the server (100) may include a memory unit (110), a processor unit (120), and a communication unit (130). Since these components are not essential for implementing the server (100), the server (100) described in this specification may have more or fewer components than the components listed above.

[0187] Memory unit (110)

[0188] According to the present invention, the memory unit (110) serves as a memory means and can store a plurality of application programs run on the server (100), data for the operation of the server (100), commands or instructions. The application programs stored in the memory unit (110) can be driven by the processor unit (120) to perform the operation or function of the server (100).

[0189] According to the present invention, the memory unit (110) may include built-in memory or external memory. The built-in memory may include at least one of volatile memory (e.g., DRAM (Dynamic RAM), SRAM (Static RAM), SDRAM (Synchronous Dynamic RAM), etc.) or non-volatile memory (e.g., OTPROM (One Time Programmable ROM), PROM (Programmable ROM), EEPROM (Electrically Erasable and Programmable ROM), flash ROM, NAND flash memory, etc.). The description of the above-mentioned memory is merely an example, and the present invention is not limited thereto.

[0190] According to the present invention, the server (100) may include a database management system (not shown) for storing and / or managing user information or public MyData. Meanwhile, according to one embodiment of the present invention, the memory unit (110) may be implemented as a storage means of the database management system.

[0191] Processor section (120)

[0192] According to the present invention, the processor unit (120) can control the operation of the server (100). Specifically, the processor unit (120) can be composed of one or more cores, and can include a processor for data analysis, such as a central processing unit (CPU), a general purpose graphics processing unit (GPGPU), a tensor processing unit (TPU), and a neural processing unit (NPU).

[0193] According to the present invention, the processor unit (120) can read a program stored in the memory unit (110) and perform a method according to an embodiment of the present invention. The processor unit (120) can execute one or more instructions to perform a method / operation according to various embodiments of the present invention. According to one embodiment of the present invention, the processor unit (120) can read a computer program stored in the memory unit (110) and perform data processing according to the present invention.

[0194] Communications Department (130)

[0195] According to the present invention, the communication unit (130) enables communication between the server (100) and the electronic device (200), between the server (100) and the user terminal (300), or between the server (100) and another server. Specifically, the communication unit (130) can transmit the processing result by the processor unit (120) to the electronic device (200), the user terminal (300), or another server. In addition, the communication unit (130) can receive information transmitted by the electronic device (200), the user terminal (300), or another server.

[0196] According to the present invention, the server (100) can encrypt data using an encryption algorithm to ensure the security and stability of user information, and can encrypt communication during data transmission.

[0197] According to the present invention, the server (100) can be integrated with various tools capable of effectively processing and analyzing user information. For example, the server (100) can implement a system that efficiently processes large amounts of data using a data processing engine and provides event-related information based on user information through a machine learning model. Furthermore, the server (100) can be integrated with analysis tools to provide statistical analysis and visualization of user information.

[0198] Electronic devices (200)

[0199] According to the present invention, the electronic device (200) may be a terminal device or a server, and may include any type of device. The electronic device (200) may be an electronic device equipped with a processor and memory, such as a personal computer (PC), a laptop computer, a tablet PC, or a mobile phone, and may be an electronic device with computing capabilities.

[0200] FIG. 1C is a block diagram illustrating an electronic device (200) according to one embodiment of the present invention. As illustrated in FIG. 1C, the electronic device (200) according to the present invention may include a memory unit (210), a processor unit (220), a communication unit (230), an input unit (240), and an output unit (250). Since these components are not essential for implementing the electronic device (200), the electronic device (200) described in this specification may have more or fewer components than the components listed above.

[0201] Memory unit (210)

[0202] According to the present invention, the memory unit (210) can store various programs or data necessary for the operation of the electronic device (200). Specifically, various information, such as information for verifying a user terminal, user information, and ticket message information, can be stored in the memory unit (210). Meanwhile, at least one of the above-described information can be encrypted and stored in the memory unit (210).

[0203] According to the present invention, the memory unit (210) may include built-in memory or external memory. The built-in memory may include at least one of volatile memory (e.g., DRAM (Dynamic RAM), SRAM (Static RAM), SDRAM (Synchronous Dynamic RAM), etc.) or non-volatile memory (e.g., OTPROM (One Time Programmable ROM), PROM (Programmable ROM), EEPROM (Electrically Erasable and Programmable ROM), flash ROM, NAND flash memory, etc.). The description of the above-mentioned memory is merely an example, and the present invention is not limited thereto.

[0204] Processor section (220)

[0205] According to the present invention, the processor unit (220) may include at least one application processor (AP), at least one communication processor (CP), or at least one artificial intelligence processor (AI processor). The application processor, the communication processor, or the AI ​​processor may be each included in different integrated circuit (IC) packages or included in a single IC package.

[0206] According to the present invention, the processor unit (220) reads a computer program stored in the memory unit (210), and the processor unit (220) can perform data processing to provide a service according to the present invention, such as an operation of verifying a user terminal (300) and an operation of determining data transmission and reception with a user terminal (300) and / or a server (100).

[0207] Communications Department (230)

[0208] According to the present invention, the communication unit (230) enables communication between the electronic device (200) and the server (100), between the electronic device (200) and the user terminal (300), or between the electronic device (200) and another electronic device. Specifically, the processor unit (220) can transmit the processing result to the server (100), the user terminal (300), or another electronic device through the communication unit (230). In addition, the processor unit (220) can receive information transmitted by the server (100), the user terminal (300), or another electronic device through the communication unit (230).

[0209] Input section (240)

[0210] According to the present invention, the input unit (240) may include at least one of a touch screen, a tablet display, a mouse, a track pad, a track ball, a tablet pen, an electronic pen, a reader of a recognition code (such as a QR code, a barcode, an image code, and a color code), and a reader of a recognition tag (such as an RFID tag, an NFC tag, a Bluetooth tag, a BLE tag, and a UWB tag). Information or other input data received through the input unit (240) may be processed by the processor unit (220).

[0211] According to the present invention, the input unit (240) is for receiving a command or data from a user, and enables interaction between the user and the electronic device (200). For example, the electronic device (200) can sense a user input through the input unit (240). The processor unit (220) of the electronic device (200) according to one embodiment of the present invention can perform data processing operations for providing a service according to the present invention, such as verification of a user terminal, generation and / or issuance of a ticket message, based on the user input sensed through the input unit (240).

[0212] Output section (250)

[0213] According to the present invention, the output unit (250) is for outputting the result processed by the processor unit (220), and may include at least one of a monitor, a touchscreen display unit, a graphic tablet display, a projector, and a smart mirror. For example, the output unit (250) may output the graphical user interface generated by the processor unit (220) through a display module (not shown).

[0214] The electronic device (200) can display a graphical user interface through an output unit (250), or transmit data such as ticket message information to a user terminal (300) through a communication unit (230), so that the user terminal (300) can output a graphical user interface including data such as ticket message information.

[0215] According to the present invention, the input unit (240) and output unit (250) of the electronic device (200) may not be configured separately, but may be configured in the form of a single input / output interface.

[0216] User terminal (300)

[0217] According to the present invention, a user terminal (300) is a terminal capable of receiving input from a user for data exchange with at least one of a server (100), an electronic device (200), and another user terminal (300), and may refer to a terminal device carried by the user. In addition, the user terminal (300) may perform a function of receiving data generated or output by the server (100) or the electronic device (200) and outputting the same through a user interface.

[0218] The user terminal (300) according to the present invention may include a personal computer (PC), a laptop computer, a mobile terminal, a smart phone, a tablet PC, an artificial intelligence (AI) speaker, an artificial intelligence TV, and a wearable device (e.g., a smart watch, a smart glass, a head mounted display (HMD)), and may include all types of terminal devices that can connect to a wired / wireless network.

[0219] FIG. 1D is a block diagram illustrating a user terminal (300) according to one embodiment of the present invention. As illustrated in FIG. 1D, the user terminal (300) may include a memory unit (310), a processor unit (320), a communication unit (330), an input unit (340), and an output unit (350). Since these components are not essential for implementing the user terminal (300), the user terminal (300) described in this specification may have more or fewer components than the components listed above.

[0220] Memory unit (310)

[0221] According to the present invention, the memory unit (310) can store a plurality of application programs running on the user terminal (300), data, commands or instructions for the operation of the user terminal (300). The application programs stored in the memory unit (310) can be driven by the processor unit (320) to perform the operation or function of the user terminal (300).

[0222] According to the present invention, the memory unit (310) may include built-in memory or external memory. The built-in memory may include at least one of volatile memory (e.g., DRAM (Dynamic RAM), SRAM (Static RAM), SDRAM (Synchronous Dynamic RAM), etc.) or non-volatile memory (e.g., OTPROM (One Time Programmable ROM), PROM (Programmable ROM), EEPROM (Electrically Erasable and Programmable ROM), flash ROM, NAND flash memory, etc.). The description of the above-mentioned memory is merely an example, and the present invention is not limited thereto.

[0223] Processor section (320)

[0224] According to the present invention, the processor unit (320) can control the user terminal (300). Specifically, the processor unit (320) can be composed of one or more cores, and can include a processor for data analysis, such as a central processing unit (CPU), a general purpose graphics processing unit (GPGPU), a tensor processing unit (TPU), and a neural processing unit (NPU).

[0225] According to the present invention, the processor unit (320) can read a program stored in the memory unit (310) and perform a method according to one embodiment of the present invention. The processor unit (320) can execute one or more instructions to perform a method / operation according to various embodiments of the present invention.

[0226] Communications Department (330)

[0227] According to the present invention, the communication unit (330) enables wireless communication between a user terminal (300) and a server (100), a user terminal (300) and an electronic device (200), or a user terminal (300) and another user terminal. Specifically, the communication unit (330) can transmit the processing result by the processor unit (320) to the server (100), the electronic device (200), or another user terminal. In addition, the communication unit (330) can receive information transmitted by the server (100), the electronic device (200), or another user terminal. For example, the communication unit (330) can receive a graphical user interface generated by the electronic device (200).

[0228] Input section (340)

[0229] According to the present invention, the input unit (340) may include at least one of a touch screen, a tablet display, a mouse, a track pad, a track ball, a tablet pen, and an electronic pen. Information or other input data received from the input unit (340) may be processed by the processor unit (320).

[0230] According to the present invention, the input unit (340) is for receiving commands or data from a user, and enables interaction between the user and the user terminal (300). For example, the user terminal (300) can sense user input through the input unit (340).

[0231] According to the present invention, the input unit (340) is for receiving a command or data from a user, and enables interaction between the user and the user terminal (300). For example, the user terminal (300) can sense a user input through the input unit (340). The processor unit (320) of the user terminal (300) according to one embodiment of the present invention can perform data processing operations for providing a service according to the present invention, such as a verification request of the user terminal, a generation and / or issuance request of a ticket message, etc., based on the user input sensed through the input unit (340). In addition, information or other input data received through the input unit (340) can be transmitted to the electronic device (200) or the server (100) through the communication unit (330).

[0232] Output section (350)

[0233] According to the present invention, the output unit (350) is for outputting the result processed by the processor unit (320) or data received from the electronic device (200), and may include at least one of a monitor, a touchscreen display unit, a graphic tablet display, a projector, and a smart mirror. For example, the communication unit (330) of the user terminal (300) may receive a graphical user interface generated by the electronic device (200), and the output unit (350) may display the graphical user interface received by the communication unit (330).

[0234] The user terminal (300) can receive data such as ticket message information from the server (100) and / or electronic device (200) through the communication unit (330), and output a graphical user interface including data such as ticket message information through the output unit (350).

[0235] According to the present invention, the input unit (340) and output unit (350) of the user terminal (300) may not be configured separately, but may be configured in the form of a single input / output interface.

[0236] network

[0237] The network according to the present invention can use various wired communication systems such as Public Switched Telephone Network (PSTN), xDSL (x Digital Subscriber Line), RADSL (Rate Adaptive DSL), MDSL (Multi rate DSL), VDSL (Very High Speed ​​DSL), UADSL (Universal Asymmetric DSL), HDSL (High Bit Rate DSL), and local area network (LAN). In addition, the network presented herein can use various wireless communication systems such as CDMA (Code Division Multi Access), TDMA (Time Division Multi Access), FDMA (Frequency Division Multi Access), OFDMA (Orthogonal Frequency Division Multi Access), SC-FDMA (Single Carrier-FDMA), and other systems.

[0238] The network according to the present invention can be configured regardless of the communication mode, such as wired or wireless, and can be configured as various communication networks, such as a personal area network (PAN) and a wide area network (WAN). In addition, the network can be the well-known World Wide Web (WWW), and can also utilize wireless transmission technologies used for short-distance communication, such as infrared (IrDA: Infrared Data Association), Bluetooth, and ultra-wideband (UWB). The technologies described in this specification can be used not only in the networks mentioned above, but also in other networks.

[0239] Collection and processing of user information

[0240] Figure 2 is a conceptual diagram illustrating a method for collecting and preparing user information according to one embodiment of the present invention. Conventionally, due to the nature of the industry, it has been common for entities hosting events (e.g., performance planning companies) and entities issuing event tickets (e.g., ticket sales companies) to collect user-related data (e.g., user information) for different purposes. For example, an entity hosting an event may require user behavioral data, such as user preferred event styles and feedback on the event, for event planning and marketing purposes. On the other hand, an entity issuing event tickets may require ticket marketing-related data, such as ticket issuance details and payment information, to increase ticket sales. However, under the current structure, it is difficult for each entity to secure the data they need. This is due to various factors, including the separation of data ownership and access rights, regulations such as the Personal Information Protection Act, restrictions on data sharing due to commercial competition, differences in the data requirements of the two entities, and the lack of an integrated data platform.

[0241] Entities issuing event tickets may have little incentive to provide the data (e.g., user behavioral data) required by the event organizer. Furthermore, the event organizer may have limited access to the data collected by the ticketing entity. Furthermore, users often lack a clear understanding of how their data will be used, making them reluctant to provide data. This can further limit the scope of data collection on both sides. These structural issues hinder the efficient exchange of data through collaboration between ticketing entities and event organizers, or the integrated analysis and utilization of data.

[0242] The present invention was conceived to address these issues, and according to one embodiment, a method for collecting and preparing user information is disclosed. To address the problems encountered in prior art, the present invention clearly establishes relationships among clients (e.g., ticket sales companies, performance planning companies, etc.), service providers according to the present invention, and users (e.g., audience members), thereby enabling legal and efficient data collection and utilization.

[0243] Referring to FIG. 2, according to one embodiment of the present invention, a client (e.g., an entity hosting an event, an entity issuing event tickets, etc.) may enter into a contract for a ticket issuance service and / or personal information processing consignment. Specifically, the client may be an entity that plans and operates an event, utilizes marketing information, etc. Furthermore, the client may be an entity that issues or verifies ticket messages, etc. Furthermore, the client may be an entity that monitors real-time ticket verification status, manages user information, etc.

[0244] Meanwhile, referring to FIG. 2, a service provider according to the present invention can digitally implement a client company's ticket issuance process and provide consignment services such as issuance, management, and verification of tickets (e.g., mobile tickets, etc.). Furthermore, during this process, consignment services such as collecting basic information required for ticket issuance and user authentication, and processing essential personal information among user information can be provided. Furthermore, referring to FIG. 2, a service provider according to the present invention can operate an integrated user platform to build a single system that transcends boundaries such as event venues and event types, and can also acquire behavioral and preference data on users' overall cultural lives, analyze the acquired data, and derive insights and provide customized services based on the acquired data.

[0245] Referring to Figure 2, users can provide the service provider of the present invention with the user information necessary for event participation. This allows data generated during the user's use of the service of the present invention to be accumulated as an asset of the service provider. Beyond simple data accumulation, this serves as a foundation for comprehensively understanding user behavior and preferences in events encompassing various fields, including culture and the arts. Discount certificates and MyData provided by users can be utilized to further enrich this data ecosystem.

[0246] In summary, clients can entrust event ticket issuance and user information processing to service providers according to the present invention to provide their services. This reduces the legal and technical burdens that may arise from directly managing user data, and allows clients to receive and utilize the necessary data from service providers according to the present invention.

[0247] A service provider according to the present invention processes user information and ticket issuance data entrusted by a client company in a lawful manner and can ensure transparency in data collection and utilization by obtaining explicit consent from the user. Furthermore, the service provider according to the present invention can comply with personal information protection regulations by applying technologies such as encryption or anonymization of user information to protect user privacy during the data processing process. Accordingly, users can use the service according to one embodiment of the present invention with greater peace of mind by ensuring that their data is safely managed and utilized. Furthermore, the client company can analyze and utilize user information through the service provider according to the present invention to generate various added value, such as increased sales, personalized marketing, and more efficient event production.

[0248] This structure addresses the data fragmentation inherent in conventional technologies and provides essential data insights to both ticket issuers (e.g., ticket sales companies) and event organizers (e.g., performance organizers). Furthermore, by providing users with an integrated service experience and the industry with data-driven decision-making opportunities, it will become a key driver of the digital transformation of the arts and culture industry.

[0249] According to one embodiment of the present invention, a service provider according to the present invention can provide a method according to the present invention (e.g., ticket reservation and issuance service, user terminal (300) verification service, ticket message verification service, etc.) through mutual data transmission and reception with an electronic device of an entity issuing an event ticket and / or an electronic device of an entity hosting an event, using a cloud-based service. The service provider can manage user information or public MyData through one or more databases.

[0250] When a service provider receives a request for a SaaS (Software as a Service) service that can utilize user information from an electronic device of an event ticket issuer and / or an event organizer, the service provider may assign a database that can utilize user information to the electronic device of the event ticket issuer and / or the event organizer. In addition, if the electronic device of the event ticket issuer and / or the event organizer has requested in advance that it can receive user information via an API, the service provider may prepare to collect and process user information by establishing a data communication API with the electronic device of the event ticket issuer and / or the event organizer.

[0251] According to one embodiment of the present invention, a service provider executing a method according to the present invention may have as its clients an entity that issues event tickets (e.g., a ticket reservation business operator) and / or an entity that organizes an event (e.g., a performance planning company, etc.), and may provide ticket reservation and issuance services to the client(s) using a cloud-based web service such as AWS. The service provider manages member user information or public MyData through a database, and when a performance planning company requests a SaaS (Software as a Service) service that can utilize user information, the service provider may allocate system resources that can utilize the user information to the client.

[0252] In relation to the process of FIG. 2, FIG. 3 is a flowchart illustrating a first embodiment of a method for providing a service based on user information according to the present invention. Here, a user may refer to a person who wishes to reserve and / or issue a performance ticket.

[0253] A method for providing a service based on user information according to the present invention may include a step (S100) in which a service provider (or server) uploads a user list to a storage device. Furthermore, the method may include a step (S110) in which a scheme related to event ticketing issuance is transmitted to the user terminals of at least some of the users included in the user list. In this case, the transmission of the scheme may be based on a request from a ticket reservation service provider.

[0254] A user terminal may be, but is not limited to, a smartphone, tablet PC, laptop, or wearable device. Here, the term "scheme" refers to moving to a specific app screen or executing a specific GUI (Graphical User Interface), and can be interpreted to encompass URI Scheme, Universal Link, App Link, and Deep Link.

[0255] A method for providing a service based on user information according to the present invention may include a step (S120) of storing user information input through a GUI (Graphic User Interface) provided through a scheme.

[0256] Meanwhile, although not shown in FIG. 3, after storing user information, a step of generating ticket information about an event based on the user information and storing the ticket information may be further included.

[0257] Also, in relation to the process of FIG. 2, FIG. 4 is a flowchart illustrating a second embodiment of a method for providing a service based on user information according to the present invention.

[0258] A method for providing a service based on user information according to the present invention may include a step (S200) of transmitting a scheme related to event ticket issuance to at least some user terminals among one or more users listed in a user list. Furthermore, the method may include a step (S210) of storing user information entered through a GUI (Graphical User Interface) provided through the scheme. Subsequently, the method may include a step (S220) of analyzing user characteristics based on the user information. User characteristics may include, but are not limited to, purchase history, purchase timing, purchase frequency, purchase size, purchase trends, performances of interest, and genres of interest based on the user's age, gender, region, income level, environment, birthday, and anniversary, but is not limited thereto. Furthermore, the method may include a step (S230) of transmitting the analysis results of the user characteristics to an external server. In this case, the external server may be a server of a performance planning company, etc.

[0259] Meanwhile, although not shown in FIG. 4, after storing user information, a step of generating ticket information about an event based on the user information and storing the ticket information may be further included.

[0260] Provide the event's ticket message to the user terminal.

[0261] FIG. 5 is a flowchart of a method for providing a ticket message of an event to a user terminal according to the present invention, and FIGS. 6a and 6b are diagrams showing the structure of a ticket message according to embodiments of the present invention.

[0262] Referring to FIG. 6A, a ticket message (10) may be configured to verify the validity of a ticket regardless of network conditions. Specifically, a ticket message (10) according to one embodiment of the present invention may include at least one of ticket information (11), event information (12), and user information (13). Here, at least one of the ticket information (11), event information (12), and user information (13) may be protected using one or more encryption methods, and the ticket message (10) may be configured to enable verification regardless of network conditions. In addition, according to one embodiment of the present invention, at least one of discount information (14) and verification information (15) may be additionally included, if necessary.

[0263] Referring to FIG. 6b, the ticket message (10) may include an encrypted code layer including ticket information (11), event information (12), user information (13), and discount voucher information (16), and ticket ID information (17). In addition, as illustrated in FIG. 6b, when the ticket message (10) includes encrypted discount voucher information (16), it may not include a discount code layer including a discount code (14) and a verification code layer including a verification code (15). Meanwhile, although not illustrated in FIG. 6b, when the ticket message (10) includes ticket ID information (17), the ticket message (10) may not include other information discussed above (e.g., ticket information, event information, user information, discount voucher information, etc.). In this case, as described later, other information discussed above may be stored in the server (100) and / or electronic device (200) according to embodiments of the present invention, and may be verified and / or identified by ticket ID information (17).

[0264] Ticket information (11) according to one embodiment of the present invention may include at least one of an issuance number, issuance information, a seat number, and ticket transfer information (ticket transfer information). In this case, the ticket transfer information may include transfer details when a ticket is transferred. Furthermore, according to one embodiment of the present invention, ticket information (11) may further include ticket ID information (17), which will be described later. That is, ticket information (11) may include ticket ID information (17), or ticket ID information (17) may be included separately in a ticket message (10) without being included in ticket information (11).

[0265] Event information (12) according to one embodiment of the present invention may include at least one of a performance date, a performance venue, and a ticket manager authentication value. In this case, the ticket manager authentication value may be a device authentication value used to authenticate the ticket manager's device.

[0266] User information (13) according to one embodiment of the present invention may include the user's name, phone number (mobile phone number), discount information, and other information. The user information (13) may be encrypted with a unique key value or secret key (e.g., a user Secret Key) generated for the user. Here, the user may refer to a person who wishes to receive a service according to the present invention. Meanwhile, according to one embodiment of the present invention, the user information (13) may be encrypted with a first secret key (e.g., a user Secret Key) and then encrypted with a second secret key (e.g., a ticket Secret Key) together with other information. According to further embodiments, the user information (13) may be encrypted with a second secret key (e.g., a ticket Secret Key) together with other information without being encrypted with the first secret key (e.g., a user Secret Key).

[0267] A discount code (14) according to one embodiment of the present invention may include information for determining whether the person is eligible for a discount due to being a child, youth, senior citizen, military personnel, disabled person, person with national merit, or other preferential treatment.

[0268] Discount proof information (16) according to one embodiment of the present invention may include a result as to whether a discount was applied at the time of ticket issuance, and the result as to whether a discount was applied may be based on a result of verifying whether discount eligibility requirements are met by an artificial intelligence model according to embodiments of the present invention.

[0269] Ticket ID information (17) according to one embodiment of the present invention is connected to information (e.g., ticket information, user information, discount voucher information, event information, etc.) included in a ticket message (10) according to embodiments of the present invention, and at least one of the server (100), the electronic device (200), and the user terminal (300) according to embodiments of the present invention can identify and / or verify at least one of the information included in the ticket message (10) using the ticket ID information (17).

[0270] Meanwhile, the ticket information (11), event information (12), and user information (13) may be encrypted using a two-way encryption method or a symmetric encryption method, and the key value may be managed by the ticket issuing office. For example, the ticket information (11), event information (12), and user information (13) may be encrypted using a two-way method (e.g., AES256 GCM, etc.) using a secret key (e.g., ticket Secret Key), but the specific encryption method is only a specific example to help understanding of the invention, and the two-way or symmetric encryption method of the present invention is not limited thereto.

[0271] Here, to aid understanding of the invention, the encryption algorithm and electronic signature of the ticket message (10) are briefly described. Fig. 7 is a diagram illustrating various encryption methods, and Fig. 8 is a diagram illustrating the process of creating and verifying an electronic signature.

[0272] Referring to Figure 7, AES256 GCM (Galois / Counter Mode) is an authenticated encryption mode that uses AES256, a block encryption algorithm. AES uses symmetric encryption, which means that the same key must be used for both encryption and decryption. In addition, AES uses a 128-bit block cipher and performs data encryption and integrity verification simultaneously. In addition, parallel processing is possible, supporting high-speed encryption, and using an initialization vector, even if encryption is performed with the same key, different results are generated. The present invention utilizes AES encryption to achieve high security (combination of the strong encryption and authentication of AES256), fast processing speed (performance improvement due to parallelization), guaranteed data integrity (possible detection of tampering attempts), and various applications (network protocols, disk encryption, etc.).

[0273] Meanwhile, asymmetric encryption, or public key encryption, is a public key encryption algorithm with high security and scalability. It performs encryption and decryption using different keys, the public and private keys, offering high security and scalability. For example, RSA encryption offers high security (impossible to decrypt based on algebraic problems), excellent scalability (can be used for digital signatures, key exchange, and authentication encryption), and standardization (encryption standardized by the International Organization for Standardization).

[0274] Referring to Figure 8, after User A creates a public key and a private key, he encrypts a document using the private key to create an electronic signature (encrypted message), and then User B decrypts the electronic signature (encrypted message) using User A's public key and performs verification.

[0275] Various methods according to the present invention can provide event ticket messages to user terminals using the encryption and electronic signature techniques described above. However, in other embodiments, various encryption techniques different from those described above can be applied to the present invention. For example, ticket information (11), event information (12), and user information (13) can be encrypted using various bidirectional encryption methods or symmetric encryption methods.

[0276] Again, referring to FIG. 5, a method for providing a ticket message to a user terminal according to the present invention may first include a step (S300) of receiving verification data of the user terminal, electronic signature data encrypted by a public key from the verification data, and the public key. Then, the method may include a step (S310) of decrypting the encrypted electronic signature data using the received public key.

[0277] If the electronic signature data is decrypted, a step (S320) may be included to verify the user terminal by matching it with the verification data received in step S300. Furthermore, a step (S330) may be included to encrypt the ticket message using a public key and a step (S330) may be included to transmit the encrypted ticket message to the verified user terminal.

[0278] Meanwhile, although not shown in FIG. 5, a method for providing a ticket message to a user terminal according to the present invention may include receiving a private key from the user terminal, encrypting the ticket message with the received private key, and then causing the user terminal to generate an identification code or identification tag corresponding to the ticket message based on the ticket message encrypted with the private key.

[0279] At this time, the recognition code may be any one of a QR code, a barcode, an image code, and a color code, and the recognition tag may be any one of an RFID tag, an NFC tag, a Bluetooth tag, a BLE tag, and a UWB tag, but is not limited thereto.

[0280] Figures 9 to 12 illustrate each step of the flowchart of Figure 5.

[0281] First, as illustrated in FIG. 9, a user requests the server (100) to issue a ticket for an event using a user terminal (300). At this time, an electronically signed request signal along with the public key of the user terminal (300) is transmitted to the server (100).

[0282] Next, as illustrated in FIG. 10, the server (100) transmits a ticket message (10) encrypted with a public key (e.g., user public key) received from the user terminal (300) to the user terminal (300). Specifically, the server (100) performs identity verification (electronic signature verification) of the user terminal (300), verifies the validity of user information and the ticket, and encrypts the ticket information, event information, and user information. At this time, a ticket message including discount information and a verification code is generated, encrypted with a public key (e.g., RSA encryption method), and then the encrypted data is transmitted to the user terminal (300). The public key here may be a public key received from the user terminal (300), but the specific encryption method is not limited thereto.

[0283] Referring to FIGS. 9 and 10, when the server (100) receives a ticket issuance request from a user terminal (300), the server (100) may generate ticket ID information (17) linked to information (e.g., ticket information, user information, discount voucher information, event information, etc.) included in a ticket message (10) according to embodiments of the present invention, and store the same in the server (100). The ticket ID information generated in the server (100) may be transmitted to the user terminal (300) together with or separately from the ticket message (10). Meanwhile, according to one embodiment of the present invention, the ticket ID information may be encrypted before the server (100) generates and transmits the ticket ID information to the user terminal (300). In this case, encryption (e.g., RSA encryption method) may be performed using a public key (e.g., a public key previously transmitted from the user terminal (300), but the specific encryption method is not limited thereto.

[0284] According to one embodiment of the present invention, when the server (100) generates ticket ID information from a ticketing request of a user terminal (300) and transmits a ticket message (10) including the generated ticket ID information (17) to the user terminal (300), other information (e.g., ticket information, user information, discount voucher information, event information, etc.) discussed above as being included in the ticket message (10) may be stored in the database of the server (100) without being included in the ticket message (10) transmitted to the user terminal (300) (this type of ticket message is not shown). In this case, the user terminal (300) can use the received ticket ID information (17) to request verification of other information stored in the electronic device (200) and / or the server (100).

[0285] Thereafter, as illustrated in FIG. 11, the user terminal (300) decrypts the encrypted ticket message (10) using the user terminal's private key (e.g., user Private Key). Then, after verifying the ticket message, the issuance information is stored in internal storage (e.g., memory). Then, the user terminal (300) encrypts the ticket message (10) using the public key (e.g., event Public Key) assigned to the event received from the server (100) (e.g., performing RSA encryption).

[0286] As illustrated in FIG. 12, a recognition code or recognition tag is generated based on an encrypted ticket message (10). In FIG. 12, a QR code is illustrated as being generated, but in other embodiments, any one of a barcode, an image code, a color code, an RFID tag, an NFC tag, a Bluetooth tag, a BLE tag, and a UWB tag may be generated.

[0287] Providing the event ticket message (10) to the electronic device (200)

[0288] FIG. 13 is a flowchart illustrating a method for providing an event ticket message to an electronic device according to the present invention.

[0289] As illustrated, a method for a server (100) to provide an event ticket message (10) to an electronic device (200) may first include a step (S410) in which the server (100) verifies the electronic device (200). At this time, the electronic device (200) may be a device equipped at a ticket booth that verifies a ticket reserved by a user, or a device equipped by a ticket inspector, but is not limited thereto. In addition, the electronic device (200) may be implemented as two or more different electronic devices, such as a first electronic device for verifying the ticket message (10) and a second electronic device for providing the ticket message (10), so that each of the electronic devices may perform its own function.

[0290] Verification of the electronic device (200) can be performed in various ways. For example, verification of the electronic device (200) can be performed based on an encrypted code or tag. In this case, the encrypted code can be any one of a QR code, a barcode, an image code, and a color code, and the encrypted tag can be any one of an RFID tag, an NFC tag, a Bluetooth tag, a BLE tag, and an UWB tag. As another example, verification of the electronic device (200) can be performed based on a code composed of any one or a combination of letters, numbers, and special characters.

[0291] A method for providing an event ticket message (10) to an electronic device (200) by a server (100) according to the present invention may include a step (S420) of encrypting the ticket message (10) with a public key assigned to the event (e.g., an event public key) when verification of the electronic device (200) is performed. In addition, the method may include a step (S430) of transmitting the encrypted ticket message (10) to the verified electronic device (200).

[0292] FIG. 14 is a flowchart illustrating a detailed embodiment of a method for providing an event ticket message (10) to an electronic device (200) according to the present invention. In this embodiment, the verification procedure for the electronic device (200) can be performed in more detail.

[0293] As illustrated in FIG. 14, a method for providing an event ticket message to an electronic device according to the present invention may first include a step (S401) of receiving verification data of the electronic device, electronic signature data encrypted by a public key from the verification data, and the public key from the electronic device.

[0294] Afterwards, the method may include a step of decrypting the encrypted electronic signature data using the received public key (S402) and a step of matching the decrypted electronic signature data with the verification data (S410). The method may include a step of verifying the electronic device based on the matching result (S410) and, if verification is performed, a step of encrypting the ticket message with the public key assigned to the event (e.g., the event public key) (S420). In addition, the method may include a step of transmitting the encrypted ticket message to the verified electronic device (S430).

[0295] Meanwhile, the method according to the embodiments of FIGS. 13 and 14 may further include a step of encrypting a private key assigned to an event (e.g., an event private key) using the received public key and transmitting the encrypted private key to an electronic device. In this case, the private key may be a key for decrypting an encrypted ticket message.

[0296] Referring to FIG. 6a, a ticket message (10) includes an encryption code layer including at least one of ticket information (11), event information (12) and user information (13), wherein the ticket information (11) includes at least one of issuance information, seat number and delivery information of the ticket, and ticket ID information, and the event information (12) may include at least one of the date and time and location of the event.

[0297] Furthermore, the ticket message (10) may further include at least one of discount code information (14) and a verification code (15) of the encrypted ticket message. At this time, at least one of the ticket information, event information, and user information may be encrypted using a symmetric key. Furthermore, referring to FIG. 6b, the ticket message (10) may include ticket ID information (17). Furthermore, as illustrated in FIG. 6b, the ticket message may further include an encryption code layer including ticket information (11), event information (12), user information (13), and discount verification information (16).

[0298] In this regard, the method according to the embodiments of FIGS. 13 and 14 may further include a step of transmitting a symmetric key to an electronic device.

[0299] Figure 15 is a conceptual diagram for explaining the flowcharts of Figures 13 and 14.

[0300] When requesting event (performance) information from an electronic device, the electronic device's public key, verification data, and encrypted electronic signature data are transmitted to the service provider (or server). The service provider then transmits the ticket information encrypted with the electronic device's public key to the electronic device. The service provider then encrypts the private key assigned to the event with the electronic device's public key and transmits it to the electronic device. The electronic device then decrypts the data using the private key assigned to the event and stores it in a secure location.

[0301] At this time, in order to support offline ticketing and verification in case of an issue, the secret key assigned to the ticket (e.g., ticket Secret Key) may be set to be transmitted. At this time, the secret key may be configured as a symmetric key used for two-way encryption and decryption of the ticket message (10) described above. Meanwhile, user information, etc. are encrypted and stored, and since there is a risk that all information may be decrypted if any of the information is decrypted, the private key assigned to the event is inserted to prevent information leakage. The private key assigned to the event may be configured as a private key capable of decrypting the ticket message (10) encrypted using an asymmetric encryption method. Meanwhile, according to embodiments of the present invention, the electronic device (200) may issue or verify the ticket message (10) using the secret key (e.g., ticket Secret Key) assigned to the ticket received from the server (100). The method for issuing and verifying the ticket message (10) in the electronic device (200) will be described in detail later.

[0302] Encrypted ticket message issuance / verification system

[0303] Overall overview of the system according to embodiments of the present invention

[0304] Figure 28 is a diagram illustrating an encryption ticket system according to one embodiment of the present invention. Figure 29 is a diagram illustrating an encryption ticket system according to one embodiment of the present invention. Figure 30 is a diagram illustrating an encryption ticket system according to one embodiment of the present invention. Hereinafter, the overall encryption system of the present invention illustrated in Figures 28 to 30 will be described in detail using the drawings.

[0305] Referring to FIG. 28, a user terminal (300) may request the server (100) to issue and / or generate a ticket message (10). In this case, the server (100) may, in response to the request from the user terminal (300), issue and / or generate a ticket message (10) and then transmit it to the user terminal (300). In addition, the server (100) may transmit the generated ticket message (10) to an electronic device (200).

[0306] When a user terminal (300) requests verification of a ticket message (10) from an electronic device (200), the electronic device (200) may perform a verification operation of the ticket message (10) in response to the verification request of the user terminal (300) and then generate a verification result. The electronic device (200) may transmit the verification result (e.g., admission information, etc.) generated in response to the verification request of the user terminal (300) to the server (100). Alternatively, the electronic device (200) may transmit a verification request to the server (100) if additional verification is required. In this case, the server (100) may transmit the verification result to the electronic device (200).

[0307] Referring to FIG. 29, the user terminal (300) can transmit the public key of the user terminal (300) together with an electronic signature verification request to the server (100). When the electronic signature is verified using the public key of the user terminal (300) received from the user terminal (300), the server (100) issues and / or generates a ticket message (10), encrypts it using the public key of the user terminal (300), and transmits the encrypted ticket message (10) to the user terminal (300). In this case, the server (100) can also transmit the public key assigned to the event to the user terminal (300). The user terminal (300) can decrypt the ticket message (10) encrypted using the public key of the user terminal (300) using the private key of the user terminal (user private key).

[0308] Referring to FIG. 29, the electronic device (200) can transmit the public key of the electronic device (200) together with the electronic signature verification request to the server (100). When the electronic signature is verified using the public key of the electronic device (200) received from the electronic device (200), the server (100) can encrypt one or more ticket messages (10) issued and / or generated with the public key assigned to the event (including encrypting multiple ticket messages (10) in bulk in addition to individually encrypting each ticket message (10)), and can further encrypt the encrypted ticket message (10) with the public key of the electronic device and transmit it to the electronic device (200).

[0309] At this time, the server (100) can transmit the public key assigned to the event and the private key assigned to the event (event private key) to the electronic device (200). The electronic device (200) can decrypt one or more encrypted ticket messages (10) using the private key of the electronic device (electronic device private key). In addition, one or more ticket messages (10) decrypted using the private key of the electronic device are still encrypted with the public key assigned to the event, and the electronic device (200) can decrypt one or more ticket messages (10) using the private key assigned to the event received from the server (100).

[0310] Referring to FIG. 29, the user terminal (300) can transmit the public key of the user terminal (300) together with an electronic signature verification request to the electronic device (200). In addition, the user terminal (300) can encrypt a ticket message (10) decrypted using the private key (user private key) of the user terminal with the public key assigned to the event and transmit it to the electronic device (200).

[0311] When verification of an electronic signature is performed using the public key of the user terminal (300) received from the user terminal (300), the electronic device (200) can decrypt the ticket message (10) received from the user terminal (300) using the private key (event private key) assigned to the event and then compare it with one or more ticket messages (10) previously stored in the electronic device (200). When the information included in the ticket message (10) received from the user terminal (300) matches the information included in at least one of the one or more ticket messages (10) previously received from the server, verification of the ticket message (10) is performed, and the verification result thereof can be stored in the electronic device (200) and / or transmitted to the server (100).

[0312] Referring to FIG. 30, the user terminal (300) can transmit the public key of the user terminal (300) together with an electronic signature verification request to the server (100). When verification of the electronic signature is performed using the public key of the user terminal (300) received from the user terminal (300), the server (100) can encrypt at least one piece of information using the ticket Secret Key and issue and / or generate a ticket message (10) including at least one piece of encrypted information.

[0313] In addition, the server (100) can encrypt the generated ticket message (10) using the public key of the user terminal (300). The server (100) can transmit the encrypted ticket message (10) to the user terminal (300) and simultaneously transmit the public key assigned to the event to the user terminal (300). The user terminal (300) can decrypt the ticket message (10) encrypted using the public key of the user terminal (300) using the user's private key. In addition, the user terminal (300) can encrypt the user information (13) included in the decrypted ticket message (10) using the user's secret key.

[0314] Referring to FIG. 30, the electronic device (200) can transmit the public key of the electronic device (200) together with an electronic signature verification request to the server (100). When verification of the electronic signature is performed using the public key of the electronic device (200) received from the electronic device (200), the server (100) can encrypt one or more ticket messages (10) issued and / or generated with the public key assigned to the event (including encrypting multiple ticket messages (10) in bulk in addition to individually encrypting each ticket message (10).

[0315] In addition, the server (100) can further encrypt one or more ticket messages (10) encrypted with the public key assigned to the event using the public key of the electronic device (200) and transmit them to the electronic device (200). Meanwhile, in this case, the server (100) can transmit the public key assigned to the event, the event Private Key, and the ticket Secret Key together to the electronic device (200). The electronic device (200) can decrypt one or more ticket messages (10) encrypted using the public key of the electronic device (200) using the electronic device Private Key. In addition, one or more ticket messages (10) decrypted using the electronic device Private Key are still encrypted with the public key assigned to the event, and the electronic device (200) can decrypt one or more ticket messages (10) using the event Private Key received from the server (100).

[0316] Referring to FIG. 30, the user terminal (300) can transmit the public key of the user terminal (300) together with an electronic signature verification request to the electronic device (200). In addition, the user terminal (300) can encrypt a ticket message (10) decrypted using the user's private key with the public key assigned to the event and transmit it to the electronic device (200).

[0317] When verification of an electronic signature is performed using the public key of the user terminal (300) received from the user terminal (300), the electronic device (200) can decrypt the encrypted ticket message (10) received from the user terminal (300) using the event Private Key previously received from the server (100). In addition, the electronic device (200) can decrypt at least one piece of information included in the decrypted ticket message (10) using the ticket Secret Key previously received from the server (100).

[0318] The electronic device (200) can verify whether at least one piece of decrypted information included in a ticket message (10) received from a user terminal (300) matches at least one piece of information included in one or more ticket messages (10) previously received from a server. If the electronic device (200) determines that additional verification of the encrypted user information (13) is necessary, the electronic device (200) can receive a user Secret Key from the user terminal (300) and use the same to decrypt the user information (13). When verification of the ticket message (10) is performed, the verification result thereof can be stored in the electronic device (200) and / or transmitted to the server (100).

[0319] Referring to FIG. 30, since the electronic device (200) has received a key (a public key assigned to the event, a private key assigned to the event (event Private Key) and a secret key assigned to the ticket (ticket Secret Key)) for issuing and / or generating a ticket message (10) from the server (100), when receiving a request for issuing and / or generating a ticket message (10) from the user terminal (300), it is also possible to issue and / or generate a ticket message (10) using the public key assigned to the event, the private key assigned to the event (event Private Key) and the secret key assigned to the ticket (ticket Secret Key). This will be described later.

[0320] Hereinafter, a method for issuing, generating and / or verifying a ticket message according to embodiments of the present invention will be described in detail.

[0321] How to verify ticket messages in an online setting

[0322] Figure 16 is a flowchart of a method for verifying an encrypted ticket message according to the present invention. The method for verifying an encrypted ticket message according to the present invention may first include a step (S500) of receiving an encrypted ticket message from a user terminal, verification data from the user terminal, electronic signature data encrypted using a public key from the verification data, and the public key.

[0323] Thereafter, it may include a step (S510) of decrypting encrypted electronic signature data using the received public key and a step (S520) of verifying the user terminal by matching the decrypted electronic signature data with the received verification data.

[0324] Next, the method may include a step (S530) of decrypting the received ticket message using a secret key (e.g., ticket Secret Key) temporarily or non-temporarily stored in advance, and a step (S540) of matching the decrypted ticket message with previously stored ticket message verification data.

[0325] At this time, if the decrypted ticket message matches the previously stored ticket message verification data, the matching result data can be transmitted to the server device.

[0326] Alternatively, if there is no data matching the decrypted ticket message among the previously stored ticket message verification data, verification request information for the decrypted ticket message can be transmitted to the server device. Furthermore, verification result data transmitted based on the verification request information can be received from the server device.

[0327] In this embodiment, the ticket message includes at least one of ticket information, event information, and user information. The ticket information may include at least one of issuance information, seat number, and delivery information for the ticket, and the event information may include at least one of the date and time of the event and the location of the event. In addition, the ticket message may further include at least one of discount code information and a verification code for an encrypted ticket message.

[0328] Figures 17a and 17b are conceptual diagrams for explaining the flowchart of Figure 16. Figures 18a and 18b are conceptual diagrams for explaining the flowchart of Figure 16.

[0329] FIG. 17a is a diagram illustrating a situation in which verification of an encrypted ticket message (10) is performed in an electronic device (200). Referring to FIG. 17a, the electronic device (200) may temporarily or non-temporarily store a private key (e.g., an event private key) required in the process of verifying information received from a user terminal (300) by receiving it in advance from a server (100). Here, the event private key is a private key capable of decrypting a ticket message (10) encrypted using an asymmetric encryption method.

[0330] Specifically, the user terminal (300) may request verification along with an electronic signature while transmitting an encrypted ticket message (10) to the electronic device (200). In this case, the user terminal (300) may transmit the public key of the user terminal (300) to the electronic device (200). The electronic device (200) may verify whether the contents of the electronic signature of the user terminal (300) are correct using the public key of the user terminal received from the user terminal (300).

[0331] When the contents of the electronic signature are verified, the electronic device (200) decrypts the encrypted ticket message (10) received from the user terminal (300) using a pre-stored private key (e.g., an event private key), and if the encrypted ticket message (10) information matches the information of the ticket message (10) pre-stored in the electronic device (200), the user's entry can be approved. In addition, if the information of the encrypted ticket message (10) received from the user matches the information of the ticket message (10) pre-stored in the electronic device (200), information indicating that the two pieces of information match each other and information indicating that entry has been approved can be stored in the database of the electronic device (200). In addition, information indicating that the two pieces of information match each other and information indicating that entry has been approved can be transmitted to the server (100).

[0332] Figure 17b is a diagram illustrating a situation in which verification of an encrypted ticket message (10) is performed on a server (100). Referring to Figure 17b, the server (100) may temporarily or non-temporarily store in advance a private key (e.g., an event private key) required in the process of verifying information received from a user terminal (300).

[0333] Specifically, the user terminal (300) may request verification along with an electronic signature while transmitting an encrypted ticket message (10) to the electronic device (200). In this case, the user terminal (300) may transmit the public key of the user terminal (300) to the electronic device (200). The electronic device (200) may verify whether the contents of the electronic signature of the user terminal (300) are correct using the public key of the user terminal received from the user terminal (300).

[0334] When the content of the electronic signature is verified, the electronic device (200) can transmit a verification request for the encrypted ticket message (10) received from the user terminal (300) to the server (100). According to one embodiment of the present invention, the electronic device (200) may have previously received and temporarily or non-temporarily stored a private key (e.g., an event private key). When the content of the electronic signature is verified, the electronic device (200) can attempt verification by decrypting the encrypted ticket message (10) received from the user terminal (300) using the temporarily or non-temporarily stored private key. However, if verification is not possible, such as when the ticket message (10) does not match the ticket message (10) previously stored in the electronic device (200), the electronic device (200) can transmit a verification request for the encrypted ticket message (10) to the server (100).

[0335] When the electronic device (200) transmits a verification request for an encrypted ticket message (10) to the server (100), the electronic device (200) may transmit the encrypted ticket message (10) received from the user terminal (300) to the server (100). The server (100) may decrypt the encrypted ticket message (10) received from the electronic device (200) using a pre-stored private key (e.g., an event private key), and if the encrypted ticket message (10) information matches the information in the ticket message (10) pre-stored in the server (100), the server may transmit the user's entry approval information to the electronic device (200). In addition, if the information in the encrypted ticket message (10) received from the user matches the information in the ticket message (10) pre-stored in the server (100), the server may store information indicating that the two pieces of information match and that entry has been approved in the database of the server (100).

[0336] FIG. 18a is a diagram for explaining a situation in which verification of an encrypted ticket message (10) is performed in an electronic device (200). Referring to FIG. 18a, similarly to the case of FIG. 17a, the electronic device (200) can perform verification of an electronic signature of a user terminal (300) and verification of an encrypted ticket message (10) received from the user terminal (300). When verification of the electronic signature of the user terminal (300) and verification of the encrypted ticket message (10) are performed, the electronic device (200) can store admission information in the electronic device (200) and transmit it to the server (100).

[0337] FIG. 18b is a diagram for explaining a situation in which verification of an encrypted ticket message (10) is performed on a server (100). Referring to FIG. 17b, the server (100) may temporarily or non-temporarily store in advance a private key (e.g., an event private key) required in the process of verifying information received from a user terminal (300). In addition, the server (100) may temporarily or non-temporarily store in advance a secret key (e.g., a ticket secret key) required in the process of verifying additional encrypted information included in a ticket message (10) received from a user terminal (300). Here, the ticket secret key is a secret key that can decrypt information encrypted by a two-way key (symmetric key) encryption method among the information included in the ticket message (10).

[0338] Specifically, the user terminal (300) may send an encrypted ticket message (10) to the electronic device (200) and request verification along with an electronic signature. In this case, the user terminal (300) may also send the public key of the user terminal (300) to the electronic device (200). The electronic device (200) may verify whether the contents of the electronic signature of the user terminal (300) are correct using the public key of the user terminal received from the user terminal (300). Once the contents of the electronic signature are verified, the electronic device (200) may transmit a verification request for the encrypted ticket message (10) received from the user terminal (300) to the server (100).

[0339] According to one embodiment of the present invention, the electronic device (200) may have previously received a private key (e.g., an event private key) and temporarily or non-temporarily stored it. When the content of the electronic signature is verified, verification may be attempted by decrypting the encrypted ticket message (10) received from the user terminal (300) using the temporarily or non-temporarily stored private key. However, if verification is not possible, such as when the ticket message (10) does not match the ticket message (10) previously stored in the electronic device (200), the electronic device (200) may transmit a verification request for the encrypted ticket message (10) to the server (100).

[0340] When the electronic device (200) transmits a verification request for an encrypted ticket message (10) to the server (100), the electronic device (200) may transmit the encrypted ticket message (10) received from the user terminal (300) together with the server (100). The server (100) may decrypt the encrypted ticket message (10) received from the electronic device (200) using a pre-stored private key (e.g., an event private key), and if the encrypted ticket message (10) matches the information in the ticket message (10) pre-stored in the server (100), the server may transmit the user's entry approval information to the electronic device (200). In addition, if it is necessary to verify additional encrypted information included in the encrypted ticket message (10) received from the user terminal (300), the server may decrypt the encrypted information using a pre-stored secret key (e.g., a ticket secret key), and perform verification based on whether the encrypted information matches the information in the pre-stored information.

[0341] In this way, if the information of the encrypted ticket message (10) received from the user and the information of the ticket message (10) stored in the server (100) match each other, information that the two pieces of information match each other and information that entry has been approved can be stored in the database of the server (100).

[0342] Fig. 19 is a flowchart of a method for verifying a ticket message including information encrypted by a symmetric key according to the present invention. As illustrated in Fig. 19, the method for verifying a ticket message including information encrypted by a symmetric key according to the present invention may first include a step (S600) of receiving a ticket message, verification data of the user terminal, electronic signature data encrypted by a public key from the verification data, and the public key from a user terminal. Thereafter, the method may include a step (S610) of decrypting the encrypted electronic signature data using the received public key and a step (S620) of verifying the user terminal by matching the decrypted electronic signature data with the verification data.

[0343] In addition, it may include a step (S630) of decrypting the received ticket message using a pre-stored symmetric key and a step (S640) of matching the decrypted ticket message with pre-stored ticket message verification data.

[0344] At this time, although not illustrated in FIG. 19, a step of receiving user information from a user terminal, encrypting the received user information with a pre-stored secret key (e.g., a user secret key), and then matching the encrypted user information with pre-stored user information verification data may be further included. If the encrypted user information matches the pre-stored user information verification data, the matching result data may be stored in an electronic device, etc.

[0345] Here, the ticket message includes at least one of ticket information, information about the event, and user information, wherein the user information may be information encrypted with the secret key (e.g., the user secret key). Furthermore, the ticket information may include at least one of issuance information, seat number, and ticket delivery information, and the event information may include at least one of the date and time of the event and the location of the event.

[0346] How to validate ticket messages in offline situations

[0347] Hereinafter, a method for verifying a ticket message in an offline situation according to embodiments of the present invention will be described with reference to FIGS. 20 to 25. An offline situation may refer to a situation in which communication between at least one of a user terminal (300) and an electronic device (200) and a server (100) is not smooth. However, although an offline situation will be described below with reference to FIGS. 20 to 25, the present invention is not limited to providing a method for verifying a ticket message in an offline situation. That is, it should be understood that a method for verifying a ticket message in a manner identical or similar to the method described below can be provided even in an online situation (e.g., a situation in which communication between at least one of a user terminal (300) and an electronic device (200) and a server (100) is smooth).

[0348] FIG. 20 is a diagram illustrating a method for verifying a ticket message in an offline situation, according to one embodiment of the present invention.

[0349] As illustrated in FIG. 20, the user terminal (300) may request verification of the ticket message (10) from the electronic device (200). According to one embodiment of the present invention, the ticket message (10) is encrypted using a public key, and the user terminal (300) may transmit the encrypted ticket message (10) and the public key to the electronic device (200) along with a verification request of the encrypted ticket message (10). The electronic device (200) may verify whether the electronically signed content is correct using the public key received from the user terminal (300). In addition, for example, the electronic device (200) may decrypt the encrypted ticket message (10) received from the user terminal (300) using a private key (e.g., an event private key) previously received from the user terminal (300), and compare it with information in at least one of a plurality of ticket messages previously stored in the electronic device (200) to determine whether they match.

[0350] If the electronic device (200) has ticket message information that matches the ticket message (10) received from the user terminal (300), the verification of the ticket message (10) received from the user terminal (300) in the electronic device (200) is completed, and the verification completion processing and entry information can be stored in pairs in the electronic device (200). However, if there is no ticket message information that matches the ticket message (10) received from the user terminal (300), verification can be requested from the service provider (or server (100)).

[0351] In the case of an offline situation, since a verification request cannot be made to the server (100) in real time, the ticket message (10) received from the user must be decrypted using the private key (e.g., event Private Key) and the secret key (e.g., ticket Secret Key) previously received from the server (100). According to one embodiment of the present invention, the event Private Key is a private key that can decrypt a ticket message (10) encrypted by an asymmetric encryption method, and the ticket Secret Key is a secret key that can decrypt information included in the ticket message (10) encrypted by a two-way key (symmetric key) encryption method.

[0352] FIGS. 21A and 21B are diagrams for explaining a method for decrypting an encrypted ticket message according to an embodiment of the present invention. FIGS. 22A and 22B are diagrams for explaining a method for decrypting an encrypted ticket message according to an embodiment of the present invention. In an offline situation according to an embodiment of the present invention, an electronic device (200) can decrypt a ticket message (10) using a private key (event private key) previously received from a server (100), and can decrypt encrypted information (information encrypted using a bidirectional encryption method such as AES256-GCM or a symmetric encryption method) included in the ticket message using a secret key (ticket secret key) previously received (see FIGS. 21A to 22B).

[0353] As shown in FIGS. 21a and 21b, a ticket message (10) can be decrypted using a private key (event Private Key), and encrypted information (e.g., ticket information (11), event information (12), user information (13)) can be decrypted and verified using a secret key (ticket Secret Key). However, the user information (13) here may have already undergone additional encryption (e.g., two-way encryption), and may only be verified if decrypted using a secret key (e.g., user Secret Key).

[0354] As illustrated in FIGS. 22a and 22b, ticket ID information (17) can be verified by decrypting the ticket message (10) using a private key (event Private Key). In addition, as illustrated in FIGS. 22a and 22b, at least one of encrypted information (e.g., ticket information (11), event information (12), user information (13), and discount voucher information (16)) can be decrypted and verified using a secret key (ticket Secret Key). However, the user information (13) here has already undergone additional encryption, and may only be verified by decrypting it using a secret key (user Secret Key).

[0355] FIG. 23 is a diagram illustrating a method for transmitting and receiving data between an electronic device (200) and a user terminal (300) to verify a ticket message according to one embodiment of the present invention. FIG. 24 is a diagram illustrating a method for transmitting and receiving data between an electronic device (200) and a user terminal (300) to verify user information according to one embodiment of the present invention. FIG. 25 is a diagram illustrating a method for transmitting and receiving data between an electronic device (200) and a server (100) after verifying a ticket message in an offline situation according to one embodiment of the present invention.

[0356] Referring to FIG. 23, the electronic device (200) can decrypt the encrypted ticket message (10) received from the user and the encrypted information contained therein using the private key (e.g., event Private Key) and the secret key (e.g., ticket Secret Key) previously received from the server (100), thereby verifying at least one of the pieces of information contained in the ticket message (10). In this way, verification can be performed even in an offline situation by comparing the information contained in the ticket message (10) with the information previously stored in the electronic device (200).

[0357] Meanwhile, as illustrated in FIG. 24, when user information (13) needs to be verified, there may be cases where the user information (13) is encrypted. For example, there may be cases where user information (13) needs to be verified to confirm whether a user who wishes to participate in an event is eligible for a discount, has made a reservation for the event, or is the true owner of the ticket. However, information such as ticket information (11) and event information (12) included in the ticket message (10) can be compared with information already stored in the electronic device (200), but if the user information (13) already stored in the electronic device (200) is separately encrypted (for example, encrypted in a two-way manner using a secret key, etc.), this must be verified separately so that the electronic device (200) can verify the user information even in an offline situation.

[0358] Accordingly, for the verification, when the electronic device (200) receives a request from the user terminal (300) through various information transmission media (e.g., any one of a QR code, a barcode, an image code, and a color code, and the recognition tag is an RFID tag, an NFC tag, a Bluetooth tag, a BLE tag, and a UWB tag, etc.), the electronic device (200) may cause the user terminal (300) to separately transmit information encrypted with a secret key (e.g., a user Secret Key) for user information (13). The user Secret Key is a secret key that can encrypt the user information (13) in a bidirectional manner or a symmetric key manner, and is also used to decrypt the encrypted user information (13). In this case, as illustrated in FIG. 24, the user information can be verified by comparing the value of the encrypted user information received from the user terminal (300) with the encrypted user information (13) previously stored.

[0359] Meanwhile, according to one embodiment of the present invention, user information (13) stored in a user terminal can be encrypted in a two-way manner using a secret key (e.g., a user Secret Key). The encrypted user information (13) in the user terminal may have the same value as the encrypted user information (13) stored when issuing a ticket. Meanwhile, this secret key (e.g., a user Secret Key) may be exchanged in advance with the electronic device (200) and / or the server (100) and temporarily or non-temporarily stored in the electronic device (200) and / or the server (100). If the encrypted user information (13) and the encrypted user information (13) of the electronic device previously received from the server (100) match, it is determined that the ticket issuance is normal.

[0360] Through this, encrypted user information (13) can be audited in the future. If there is a need to decrypt an encrypted value according to business needs, a secret key value (e.g., user Secret Key) for decrypting the encrypted user information is received from the user terminal by encrypting it with the public key value of the electronic device, and the history of sending this value is stored in the user terminal (or the application installed thereon) and the electronic device (200). The electronic device (200) can decrypt and verify the encrypted user information (13) with the received personal secret key (e.g., user Secret Key).

[0361] According to FIG. 25, when a ticket message (10) is verified according to FIG. 23 or FIG. 24, the verification completion processing and entry information of the ticket message (10) can be stored in pairs in the electronic device (200). The verification completion processing and entry information stored in the electronic device (200) can be transmitted to the server (100) when the offline situation is resolved later.

[0362] How to issue a ticket message (10) from an electronic device (200)

[0363] Meanwhile, according to embodiments of the present invention, ticket messages (10) can be issued from an electronic device (200). FIGS. 26 and 27 are diagrams illustrating a method for providing ticket messages in an offline environment according to one embodiment of the present invention. Hereinafter, a method for issuing a ticket message (10) according to embodiments of the present invention will be described using FIGS. 26 and 27.

[0364] As illustrated in FIGS. 26 and 27, when issuing a ticket message in an electronic device (200) according to one embodiment of the present invention, the electronic device (200) may be implemented as an electronic device (200a) for issuing a ticket message and an electronic device (200b) for verifying the ticket message, but is not limited thereto. Hereinafter, the electronic device (200a) for issuing a ticket message and the electronic device (200b) for verifying the ticket message are described as being implemented as being distinct from each other, but it should be understood that the electronic device for issuing a ticket message and the electronic device for verifying the ticket message may be implemented as a single electronic device (200).

[0365] As illustrated in FIG. 26, an electronic device (200a) for issuing a ticket message may temporarily or non-temporarily store in advance a private key assigned to an event (e.g., an event private key), a public key assigned to an event (e.g., an event public key), and a secret key assigned to a ticket (e.g., a ticket secret key). In addition, information required to create a ticket message (10) (e.g., ticket information (11), event information (12), etc.) may be temporarily or non-temporarily stored in advance.

[0366] Meanwhile, the electronic device (200a) may generate one or more ticket ID information (17) corresponding to each ticket message (10) to be generated later. Meanwhile, as illustrated in FIG. 26, the electronic device (200b) for verifying the ticket message may temporarily or non-temporarily store a private key (e.g., event Private Key) and a secret key (e.g., ticket Secret Key) in advance. In addition, the electronic device (200b) for verifying the ticket message may receive one or more ticket ID information (17) corresponding to each ticket message (10) from the electronic device (200a) for issuing the ticket message, and temporarily or non-temporarily store the received ticket ID information.

[0367] Referring to FIG. 26, the user terminal (300) may store encrypted user information (13) and discount voucher information (16), etc. In FIG. 26, the discount voucher information (16) is illustrated as being stored only in the user terminal (300), but according to embodiments of the present invention, when the electronic device (200a) provides discount information to the user terminal (300), receives a discount voucher request from the user terminal (300), and verifies whether the discount eligibility requirements of the user terminal (300) are met, the electronic device (200a) may also include the discount voucher information (16).

[0368] According to embodiments of the present invention, the electronic device (200a) may receive and store user verification information (16) from the server (100) in advance. According to FIG. 26, the user terminal (300) may transmit a signal requesting the generation of a ticket message (10) to the electronic device (200a) along with information necessary for generating the ticket message (10), such as encrypted user information (13) and discount verification information (16).

[0369] As illustrated in FIG. 27, an electronic device (200a) that receives a signal requesting the creation of a ticket message (10) from a user terminal (300) may encrypt (e.g., encrypt in AES256 format) information necessary for creating a ticket message (10), such as ticket information (11), event information (12), encrypted user information (13), and discount voucher information (16), using a pre-stored secret key (e.g., ticket Secret Key), and create a ticket message (10) that includes the encrypted information and pre-created ticket ID information (17).

[0370] The electronic device (200a) can encrypt a ticket message (10) using a public key assigned to an event (e.g., an event Public Key) and transmit it to a user terminal (300). In this case, the ticket message encrypted using the public key assigned to the event (e.g., an event Public Key) can be encrypted using a public key previously received from the user (e.g., a user Public Key), and then the doubly encrypted ticket message (10) can be transmitted to the user terminal (300).

[0371] An artificial intelligence model-based system for automating verification of whether discount eligibility requirements are met.

[0372] Overview of the automated system for verifying whether discount eligibility requirements are met

[0373] Previously, humans had to verify and / or determine whether a user met the eligibility requirements for a discount. When humans verified and / or determined whether a user met the eligibility requirements for a discount, the verification process caused delays in user / audience access. Furthermore, when human verification was performed, consistent and objective verification could be difficult to achieve, or discrepancies in the verification results could occur, depending on the circumstances.

[0374] Meanwhile, verification and / or determination of whether a discount eligibility requirement is met can be performed using a rule-based algorithm. However, given the diverse nature of discount policies and / or requirements, and the potential for new policies and / or requirements to be introduced at any time, implementing this with a rule-based algorithm presents limitations in defining the various eligibility requirements and supporting documentation. Furthermore, additional processing units must be implemented for each discount policy. Therefore, it is impossible to automate verification and / or determination of whether a discount eligibility requirement is met using a rule-based algorithm.

[0375] Conversely, if a natural language processing-based artificial intelligence model is used to verify and / or determine whether eligibility for a discount is met, and a program is developed based on the natural language understanding (NLU), natural language generation (NLG), and reasoning capabilities of the artificial intelligence model, the judgment criteria can be varied according to the eligibility requirements for each discount policy, thereby enabling automation of the verification and / or determination of whether eligibility for a discount is met. Accordingly, the present invention discloses a method for automating the verification of whether eligibility for a discount is met using a natural language processing-based artificial intelligence model.

[0376] A discount verification system according to one embodiment of the present invention can utilize artificial intelligence to verify and / or determine whether discount eligibility requirements are met. A method for verifying whether discount eligibility requirements are met according to one embodiment of the present invention may include at least one of the following steps: receiving at least one of user information, event information, and discount information; inputting and / or receiving supporting document data; analyzing the content of the received supporting document data; and verifying whether discount eligibility requirements are met based on the input data. Furthermore, the discount verification system may verify the authenticity of the input supporting document data, verify and / or determine whether discount eligibility requirements are met according to a discount policy, and provide the results. According to one embodiment of the present invention, the verification results for whether discount eligibility requirements are met may be recorded for tracking and auditing purposes.

[0377] Furthermore, an automated verification system according to one embodiment of the present invention enables consistent and objective verification of whether discount eligibility requirements are met. The discount verification system according to one embodiment of the present invention can operate based on predefined verification criteria or verification criteria actively generated by an agent, enabling automated verification operations and ensuring the consistency and reliability of verification results.

[0378] Artificial intelligence model based on natural language processing

[0379] According to one embodiment of the present invention, a natural language processing-based artificial intelligence (AI) model can be designed to understand, interpret, generate, and manipulate human language. This model utilizes various computing technologies to analyze and process natural language-based data (e.g., text or speech data), enabling machines to perform tasks such as language translation, sentiment analysis, text summarization, text recognition, discount eligibility verification, and chatbots.

[0380] Typically, the first step in a natural language processing-based AI model is to divide text into smaller units, such as words, subwords, or characters. These units are called tokens. For example, in the sentence "The cat is sleeping," each word can be treated as a token. Once tokenized, the text must be represented in a numerical format that the AI ​​model can understand. To represent text in numerical form, techniques such as one-hot encoding, word embeddings (such as Word2Vec, GloVe, or FastText), and contextual embeddings can be used.

[0381] According to one embodiment of the present invention, the artificial intelligence model based on natural language processing may include large language models (LLMs), multimodal large language models (MLLMs), small language models (SLMs), vision language models (VLMs), etc. Specifically, the language models include statistical language models that use statistical methods based on the probability of word sequences, and neural language models that use deep learning techniques, and the neural language models include artificial intelligence models based on RNNs, LSTM Transformers, etc.

[0382] Here, the Transformer architecture may include an Encoder to process the input sequence and transform it into a hidden representation, a Decoder to take the hidden representation and produce an output such as a translation or summary, and Attention Layers to enable the Encoder and Decoder models to focus on relevant parts of the input text.

[0383] Agent configuration used in artificial intelligence models based on natural language processing

[0384] In artificial intelligence, particularly natural language-based AI models, an agent can be a software system or component designed to autonomously perform tasks using language understanding and generation capabilities. In other words, an agent can be a software system or component designed to perform specific tasks, make decisions, or interact with the environment, using a natural language processing-based AI model with reasoning or deductive capabilities as its underlying engine.

[0385] Agents can interpret user input, respond to questions, and perform tasks based on programmed goals or learned behaviors. In natural language processing-based artificial intelligence model systems, prompts and tools are components of the agent that guide the model's output, improve responses, and activate specific functions to achieve the objectives of the present invention.

[0386] The design of agents that use natural language processing-based artificial intelligence models with reasoning or inference capabilities (e.g., Large Language Models (LLM) or Multimodal Large Language Model (MLLM)) as their basic engine can be broadly divided into the Finite State Machine (FSM) method and the Turing Complete method.

[0387] The Finite State Machine (FSM) method is a method for designing a logical model composed of states and transitions. In other words, the FSM method can be a method for designing a logical model in which a system or process starts from a specific state and moves to the next predefined state based on external inputs or conditions. Here, a state represents the current state of the system. For example, a vending machine may be in a "waiting state" or, when a user presses a button, it may change to a "coin input state."

[0388] A transition refers to a condition or action that moves from one state to another. In other words, a transition can be a rule that dictates "go from this state to that state" based on input, such as a button click or data entry. Therefore, using the FSM method, a finite set of states can be defined in advance, transition rules can be created based on possible inputs or conditions in each state, and then the agent can be designed to transition to a new state according to the rule when a specific input is received.

[0389] The Turing Complete approach, unlike the FSM approach where states and transitions are finitely defined, refers to a design method that allows agents to dynamically generate and process states and transitions. For example, the Turing Complete approach allows for the creation of agents that generate new states in specific situations by performing various logic and complex calculations using basic control structures like conditional statements and loops.

[0390] Designing agents using the Turing Complete method offers the advantage of being able to flexibly handle complex and unstructured problems, adapt to dynamic environmental changes and emerging requirements, and design universal agents capable of implementing virtually any logic. In other words, the FSM method can be used to design agents suited to predefined, limited situations, while the Turing Complete method can be used to design agents that can adapt to unpredictable or dynamic environmental changes.

[0391] Composition of the prompt

[0392] A prompt is a predefined instruction or message provided to an AI model that guides responses, tone, or actions within a conversation. Specifically, in the agent design of a natural language processing-based AI model, a prompt serves as an element that defines and guides the agent's actions. According to one embodiment of the present invention, prompts can be categorized into system prompts and user prompts.

[0393] According to one embodiment of the present invention, a system prompt determines the basic behavioral patterns and response styles of the model, and provides an overall framework for how the model should respond, including the agent's role, purpose, guidelines, constraints, and available tools, and can maintain the consistency and quality of the conversation. According to one embodiment of the present invention, a system prompt may include a 'Role' configuration that defines what role the agent performs, a 'Purpose' configuration that specifies the final goal the agent must achieve, an 'Instructions' configuration for specifying the model's response style, tone, and course of action, a 'Constraints' configuration that specifies what the model should avoid or policies it should adhere to, and a 'Tools and Capabilities' configuration for describing the tools or functions the model can use. For example, 'Role' configurations that may be included in a system prompt include, "You are a customer support agent who verifies discount eligibility requirements," and "You are a knowledgeable customer support agent." It can be expressed as a directive such as:

[0394] The 'Purpose' configuration that can be included in a system prompt according to one embodiment of the present invention may be expressed as instructions such as "Accurately determine whether the user is eligible for a discount and, if necessary, request additional information to provide smooth service" and "Provide quick and accurate service to the user to increase satisfaction."

[0395] The 'Instructions' configuration that can be included in the system prompt according to one embodiment of the present invention may be expressed as instructions such as "If the required information is insufficient, request additional information", "Convey the judgment result to the user in a clear and understandable manner", "Try to talk to the user in a friendly and casual manner", and "Use a polite and friendly tone".

[0396] The 'Constraints' configuration that may be included in a system prompt according to one embodiment of the present invention may be expressed as directives such as "Do not request or share personal information", "Do not use inappropriate language", etc.

[0397] The 'Tools and Capabilities' configuration that can be included in the system prompt according to one embodiment of the present invention can be expressed as instructions such as "You can access an external database to check user information," "You can calculate a discount rate using a calculator tool," "You can understand the intent of user input using a natural language processing tool," and "You can update shipping information."

[0398] According to one embodiment of the present invention, a user prompt is an input that a user delivers to a model in a conversation, and may include a problem that the model must solve or a question that the model must answer. Accordingly, the model can generate an appropriate response based on the user prompt and according to the instructions of the system prompt. According to one embodiment of the present invention, a user prompt may include a "Request" component expressing a question or request that the user delivers to the model, a "Context" component providing background information or a situation necessary for the model to understand the user's request, and an "Additional Information" component containing detailed information necessary for the model to process the request.

[0399] For example, a 'Request' construct that can be included in a user prompt can be expressed as a request such as, "I want to know the status of my order." or "I want to know if I have proof of a discount." In addition, a 'Context' construct that can be included in a user prompt can be expressed as a request such as, "I ordered a laptop last week, but I haven't received any delivery notification yet." or "I'm trying to participate in an event, and I'm wondering if I can qualify for a welfare discount." In addition, an 'Additional Information' construct that can be included in a user prompt can be expressed as information such as, "The order number is ABC123.", "The ticket ID is ABC123.", or "The name of the discount policy is the welfare discount for the disabled."

[0400] Prompts according to one embodiment of the present invention provide clear instructions to the model, thereby clearly conveying what the model should do and improving the quality and consistency of the model's responses. Furthermore, prompts according to one embodiment of the present invention can provide a more satisfying conversational experience for users and enhance the user experience by enabling the model to generate appropriate responses that align with the user's intent. Furthermore, prompts according to one embodiment of the present invention can reduce repetitive tasks and facilitate efficient conversation design. Furthermore, prompts can be easily applied to a variety of situations, thereby reducing development time.

[0401] Tool for providing the service of the present invention

[0402] Meanwhile, in natural language processing-based AI models (e.g., LLM), agents can utilize various tools to achieve a given goal. According to one embodiment of the present invention, tools expand the agent's capabilities and enable actions such as performing complex tasks or accessing external information.

[0403] According to one embodiment of the present invention, the tool may include at least one of various tools, such as a calculator tool for accurately and quickly processing calculations such as mathematical calculations, currency conversions, and date calculations; a database access tool for allowing an agent to access a structured database to look up or update necessary information; a web search tool for searching for information on the Internet to obtain or search for real-time information or the latest data such as news updates and weather information, general knowledge, etc.; an API integration tool for performing various functions by calling the API of an external service or application such as social media updates, payment processing, and map service use; a natural language processing tool for supporting more natural conversations by performing intent identification, sentiment analysis, and keyword extraction of user input; and an automated workflow tool for automating repetitive or complex tasks such as reservation management, notification setting, and email sending.

[0404] According to one embodiment of the present invention, an agent can be designed by selecting at least one of the above tools, or by combining them, and thereby perform various roles. For example, the agent can be designed to provide customized information by using a combination of database query tools and calculation tools at the user's request. The types of tools can be added or removed as needed, and can be updated as the agent's functionality expands.

[0405] For example, according to one embodiment of the present invention, an agent may select and / or combine at least one of various tools to perform at least one of the following roles. Specifically, the tools may be selected and / or combined to perform at least one of the following roles: a Functionality Extension role to enable tasks that the agent cannot perform by default; an External Data Access role to enable the agent to retrieve and utilize information from external sources; an Understanding User Input role to help the agent accurately understand user intent and generate appropriate responses; an Automation of Complex Tasks role to manage and execute tasks or workflows consisting of multiple steps; and a Data Processing and Analysis role to process large amounts of data and extract meaningful information.

[0406] For example, the Functionality Extension role may be for the agent to perform at least one of the following actions: mathematical calculation, date and time processing, language translation, etc. Additionally, the External Data Access role may be for the agent to perform at least one of the following actions: database query, web search, API call, etc. Additionally, the Understanding User Input role may be for the agent to perform at least one of the following actions: natural language processing (NLP) tools, sentiment analysis, intent classification, etc.

[0407] The role of Automation of Complex Tasks according to one embodiment of the present invention may be to perform at least one of the following operations: multi-step process management, schedule reservation, order processing, etc., through an agent.

[0408] The data processing and analysis role according to one embodiment of the present invention may be to perform at least one of operations such as data analysis, pattern recognition, and statistical processing through an agent.

[0409] In this way, the agent can be designed to efficiently select and / or combine tools to provide services to the user, and through appropriate design according to the present invention, the interface between the agent and the tool can operate smoothly, thereby reducing delays or errors, the agent can understand the context of the conversation, utilize the tool at an appropriate time to provide the user with necessary information, and the agent can utilize the tool to shorten the response time and provide more accurate and useful information.

[0410] Hereinafter, based on the content of the above-described natural language processing-based artificial intelligence model, an artificial intelligence model according to embodiments of the present invention will be discussed. The description of the structure, function, etc. of the artificial intelligence model, such as the artificial intelligence model for verifying whether the discount eligibility requirements are met, discussed below, can be applied throughout the present invention, and the artificial intelligence model according to embodiments of the present invention can be implemented in at least one of the memory unit (110) of the server (100), the memory unit (210) of the electronic device (200), and the memory (310) of the user terminal (300), and executed by at least one of the respective processor units (120, 220, 320).

[0411] Overall overview of the automation system

[0412] At least one step of a method for automating verification of whether AI-based discount eligibility requirements are met according to an embodiment of the present invention may be performed by a processor unit of at least one of a server (100), an electronic device (200), and a user terminal (300) according to the present invention. The processor unit according to embodiments of the present invention may further include a processing unit (not shown) that processes data input by a user and / or an administrator during the AI-based discount verification process.

[0413] Figures 31a and 31b are flowcharts illustrating a method for automating AI-based verification of discount eligibility requirements according to one embodiment of the present invention. According to one embodiment of the present invention, a service may be provided that automates discount verification using user information based on AI (e.g., when user identification and / or user information identification is required for discount verification).

[0414] According to one embodiment of the present invention, an AI-based service can be provided that automates discount verification without utilizing user information. For example, if a document, screenshot, or file containing information for discount verification is entered, and if it is possible to verify whether a discount eligibility requirement is met solely with documents that do not contain user information, discount verification can be automated without utilizing user information. Furthermore, an AI model according to one embodiment of the present invention can generate at least one of a guidance message or a summary of inferences for a user or administrator requesting a discount verification.

[0415] According to FIG. 31a, a method for automating verification of whether discount eligibility requirements are met may include a step of requesting discount proof (S700), a step of entering information for discount proof (S710), a step of entering proof documents (S720), and a step of verifying discount validity based on input data (S730).

[0416] As illustrated in Figure 31a, a step (S721) may be further included in which the user reviews the entered supporting document. In this case, based on the user's review of the entered supporting document, the process may proceed to the supporting document text identification step (S722) by entering approval for the entered supporting document. Alternatively, the process may return to the supporting document input step (S720) by re-entering the supporting document.

[0417] According to one embodiment of the present invention, the method may further include a step (S722) of identifying text from a supporting document. Furthermore, according to one embodiment of the present invention, the method may further include a step (not shown) in which a user reviews the text identified through the step (S722) of identifying text from a supporting document. In this case, if the user reviews the identified text and, based on the text identification result, enters approval for the identified text, the method proceeds to the discount validity verification step (S730), and if a re-request is entered, at least one of the supporting document input step (S720) and the supporting document text identification step (S722) may be performed again.

[0418] According to FIG. 31b, a method for automating verification of whether discount eligibility requirements are met may include a step of requesting discount evidence (S700`), a step of inputting information for discount evidence (S710`), a step of inputting evidence documents (S720`), a step of determining forgery or alteration of evidence documents (S722`), and a step of verifying discount validity based on input data (S730`).

[0419] According to one embodiment of the present invention, a step (S721`) may be further included in which the user reviews the input supporting document. In this case, if the user approves the input supporting document based on the results of the review, the process may proceed to the step (S722`) of determining whether the supporting document is falsified or altered. Alternatively, the process may return to the step (S720`) of entering the supporting document again by re-entering the supporting document.

[0420] A method according to one embodiment of the present invention may further include a step (S724`) of identifying text from the supporting document after the step (S722`) of determining forgery or alteration of the supporting document. According to one embodiment of the present invention, if the supporting document is determined to be forged or altered in the step (S722`) of determining forgery or alteration of the supporting document, the method of verifying whether the discount eligibility requirements are met may be terminated (S740`).

[0421] Although not shown in the drawing, if the supporting document is determined to be falsified in the step of determining falsification of the supporting document (S722`), a step (not shown) in which the user reviews the falsification determination result before the verification method is terminated (S740`) may be further performed. In this case, if the user determines that falsification has occurred through the review, the method is terminated (S740`), and if it is determined that falsification has not occurred, the method may proceed to the step of identifying text from the supporting document (S724`).

[0422] As illustrated, in the step (S722`) of determining whether the supporting document has been forged, if it is determined that the supporting document has not been forged, the process may proceed to the step (S724`) of identifying text from the supporting document. Meanwhile, if it is determined that the supporting document has not been forged, a step (S723`) of having the user review the forgery determination result may be further performed. In this case, after the user reviews the input forgery determination result and inputs approval for the forgery determination result, the process may proceed to the step (S724`) of identifying text from the supporting document, or return to the step (S720`) of entering the supporting document again by re-entering the supporting document.

[0423] According to one embodiment of the present invention, the step of identifying text from a supporting document (S724`) may further include a step (not shown) in which the user reviews the identified text. In this case, if the user reviews the identified text and, based on the text identification result, enters approval for the identified text, the method proceeds to the discount validity verification step (S730`). If a re-request is entered, at least one of the supporting document input step (S720`), the supporting document forgery / alteration determination step (S722`), and the supporting document text identification step (S724`) may be performed again.

[0424] Input data for learning and / or inference

[0425] FIGS. 32A to 32C are tables illustrating information for discount verification input and / or received in step (S710) illustrated in FIG. 31A or step (S710`) illustrated in FIG. 31B. According to FIGS. 32A to 32C, information for discount verification according to one embodiment of the present invention may include at least one of user information, event information, and discount information.

[0426] According to one embodiment of the present invention, user information may include user identification information (e.g., user's name, user's gender, user's date of birth, user's contact information, etc.). Event information according to one embodiment of the present invention may include event identification information (e.g., event name, event date and time, event location, event venue, etc.). Discount information according to one embodiment of the present invention may include discount identification information (e.g., discount policy or discount name, items to be checked to verify whether discount eligibility requirements are met, description of discount policy, etc.).

[0427] According to Figure 32c, the discount policy (or discount name) may include information on discount policies or discount names, such as discounts based on the user's status (e.g., discounts for the disabled, national meritorious persons, families with many children, artists, pregnant women, people over 65, senior citizens, families with distinguished military service, youth discounts, etc.), discounts linked to affiliated cards (e.g., discounts for library membership card holders, youth pass card holders, happiness card holders, etc.), discounts linked to social network services (SNS) (e.g., discounts for subscribers to specific SNS services), and discounts based on event participation history (e.g., discounts based on the number of event participations).

[0428] In addition, the items to be checked to verify whether the discount eligibility requirements are met or the description of the discount policy may include information on the eligibility requirements for the discount in advance (e.g., in the case of a discount based on status, information on the status for the discount to be applied, in the case of a discount linked to an affiliated card, information on the affiliated card for the discount to be applied, in the case of a discount linked to a social network service, information to be determined for the discount to be applied, in the case of a discount based on event participation history, information on past reservation history or information on tickets issued / verified in the past, etc.). However, as described below, the items to be checked to verify whether the discount eligibility requirements are met or the description of the discount policy may not be predefined, and an artificial intelligence model (or agent) according to embodiments of the present invention may define the information on its own and perform a verification operation.

[0429] Although not illustrated in FIG. 32c, the AI ​​model may additionally receive information already stored in the database of the server (100) or electronic device (200) and perform verification operations. Furthermore, the AI ​​model may access resources on the web and networks to additionally search or explore information, and perform verification operations based on the retrieved information.

[0430] According to one embodiment of the present invention, although information necessary for verifying eligibility for a discount may be difficult to determine solely based on data contained in the entered supporting document, or may not be verifiable based on the data contained in the entered supporting document. For example, a "library membership card" document may be entered as supporting documentation to verify eligibility for a discount policy related to "holders of a library membership card located in Gyeonggi Province" for a discount linked to an affiliated card.

[0431] However, the "Library Membership Card" document may only contain the library name and user information, and may not include information regarding whether the library is located in Gyeonggi Province. This information may be pre-stored in the system, and an agent according to one embodiment of the present invention can use API tools to search and retrieve this information from the system's database or network resources.

[0432] According to one embodiment of the present invention, the information stored in the database is reference information pre-written by developers or administrators, and the agent can use API tools to search and reference this reference information in a preset manner. Alternatively, according to one embodiment of the present invention, the agent can use web search tools to search for and reference necessary data on network resources accessible to it while performing its tasks.

[0433] According to one embodiment of the present invention, at least one of the user information, event information, and discount information may be registered in the system according to the present invention and pre-stored in a database. In the step of receiving information for discount verification (S710 or S710`), by retrieving at least one of the user information, event information, and discount information pre-stored in the database, the retrieved information can be used as input data for determining whether the discount eligibility requirements are met. For example, at least one of the user information, event information, and discount information retrieved from the database can be used to review or verify the content of the verification document input and / or received in step (S720 or S720`) and / or whether the discount eligibility requirements are met.

[0434] FIG. 32d is a diagram for explaining a supporting document input and / or received in step (S720) illustrated in FIG. 31a or step (S720`) illustrated in FIG. 31b. A supporting document according to one embodiment of the present invention is a document that can prove that the discount eligibility requirements are met according to a discount policy, and may include, for example, a document that can prove the number of performances viewed (existing performance tickets, reservation details, payment details, etc.), a document that can prove user information (resident registration card, national merit certificate, family relationship certificate, etc.), and / or a document that can confirm whether other welfare benefit requirements are met (disability certification, welfare card, etc.). According to embodiments of the present invention, the supporting document may be input and / or received in the form of a file in various formats, such as a JPEG format, a PNG format, a GIF format, a Photoshop format, a TIFF format, a PDF format, etc.

[0435] The step (S722 or S724`) of identifying text from a supporting document according to one embodiment of the present invention may include a step of recognizing text included in the supporting document using optical character recognition (OCR) and / or a natural language processing-based model (e.g., large language models (LLMs), multimodal large language models (MLLMs), small language models (SLMs), etc.) for the input and / or received supporting document. The natural language processing-based model according to one embodiment of the present invention is a model having an inference ability or a reasoning ability, and can infer or reason and output a result value based on a user's input. Meanwhile, the output token decoded by the artificial intelligence model may be output in a stringified state of semi-structured data such as JSON, HTML, XLM, MARKDOWN, etc., or in at least one of the forms of general document unstructured data.

[0436] The step (S722 or S724`) of identifying text from a supporting document according to one embodiment of the present invention may be a step of converting data for input into an artificial intelligence model based on natural language processing. Specifically, the step (S722 or S724`) of identifying text from a supporting document according to one embodiment of the present invention is a step of extracting text data based on at least one algorithm from data (e.g., supporting document data) input and / or received in the form of files in various formats such as JPEG format, PNG format, GIF format, Photoshop format, TIFF format, PDF format, etc., and various algorithms for extracting text data from input data in various formats may be used here.

[0437] At least one algorithm that can be used in the step (S722 or S724`) of identifying text from a supporting document according to one embodiment of the present invention may include at least one of compression and decompression algorithms, Discrete Cosine Transform (DCT), Run-Length Encoding (RLE), Deflate Compression, Arithmetic Coding, PackBits Compression, etc.), Optical Character Recognition (OCR) algorithms, Pattern Matching Algorithms, Data Parsing and Extraction Algorithms, Image Processing Algorithms, Machine Learning and Deep Learning Models, Steganography Detection Algorithms, Graph-based Algorithms (e.g., Connected Components Analysis, Hough Transform, etc.), Data Structure Algorithms (e.g., Tree Traversal, DOM parsing, Graph Parsing, etc.), and Signal Processing Algorithms (e.g., Wavelet Transform, Fourier Transform, etc.). For example, the step of identifying text from a supporting document (S722 or S724`) may include a step of extracting text data from PDF data by an algorithm that parses text data when data in PDF format is input and / or received.

[0438] The step (S722 or S724`) of identifying text from a supporting document according to one embodiment of the present invention may include a step of directly inputting text by a user and / or an administrator based on data input and / or received in the form of files in various formats such as JPEG format, PNG format, GIF format, Photoshop format, TIFF format, PDF format, etc. In this case, the text may be input by the user and / or the administrator without performing conversion based on an algorithm.

[0439] According to embodiments of the present invention, the supporting document file input for verifying whether the discount eligibility requirements are met may be a general image file or a file containing structured data. If the supporting document is a general image file, the text contained in the supporting document may be identified using a learning-based algorithm such as OCR and / or a multi-modal language model. Alternatively, if the supporting document is a file containing structured data, the supporting document may be converted into an image and the text contained in the supporting document may be identified using a learning-based algorithm such as OCR and / or a multi-modal language model, or the text contained in the supporting document may be identified using a rule-based algorithm such as an algorithm that parses and / or extracts structured data.

[0440] According to FIG. 32d, after recognizing or identifying text contained in an input and / or received supporting document, at least a portion of the recognized text, such as the last digits of a resident registration number, may be processed to be de-identified. Furthermore, the method of de-identifying at least a portion of the recognized text may include methods such as text masking.

[0441] According to one embodiment of the present invention, the model's inference result may be affected depending on whether additional strings or blank spaces are displayed in the user information included in the submitted supporting document. For example, if the user's name is stored as "Hong Gil-dong" in the system database, but the user's name included in the submitted supporting document is "Hong Gil-dong (myself)" or "Hong Gil-dong", or if the user's name is stored as "Hong Gil-dong" in the system database, but the user's name included in the submitted supporting document is "Hong Gil-dong" or "Hong Gil-dong (myself)", etc., the model's inference result may be affected.

[0442] To minimize such influences and improve the model's inference results, according to one embodiment of the present invention, user information previously stored in the system's database can be intentionally modified before inference is performed. For example, before tokenizing a user's name, spaces can be added between the characters of the name to improve comparison accuracy at the text embedding level (i.e., adding or modifying spaces between characters, such as "Hong Gil-dong" to "Hong Gil-dong").

[0443] In this way, the AI ​​model can be made to compare "Hong Gil-dong" with the "Hong Gil-dong" described in the submitted supporting document. According to one embodiment of the present invention, if differences are intentionally introduced at the tokenization and / or text embedding level and then the AI ​​model performs a review, even in cases where the name in the submitted supporting document is followed by a string other than the name without a space, such as "Hong Gil-dong (myself)", the AI ​​model according to one embodiment of the present invention can actively respond by making inferences regarding differences that may occur at the tokenization and text embedding levels, and as a result, the model's inference results can be improved.

[0444] Meanwhile, since this tokenization process can be performed before the discount validity verification step (S730) illustrated in FIG. 31a or the discount validity verification step (S730`) illustrated in FIG. 31b, a preprocessing step that intentionally creates data modification or differences can be performed before the tokenization process described above. In addition, according to one embodiment of the present invention, a text embedding process can be performed before determining whether the discount requirements are met (S740 or S760) during the discount validity verification step (S730 or S730`) illustrated in FIG. 31c.

[0445] How to Validate Discount Validation Methods and Improve Validation Models

[0446] According to one embodiment of the present invention, a method for improving a model for verifying discount validity is disclosed. "Verifying discount validity" here may refer to determining whether discount eligibility requirements are met. Figure 31c is a flowchart illustrating an AI-based discount validity verification method and a method for improving a verification model according to one embodiment of the present invention. According to one embodiment of the present invention, a service that verifies discount validity using user information based on AI can be provided.

[0447] According to FIG. 31c, the method for improving the AI-based discount validity verification method and verification model according to one embodiment of the present invention may include a step (S750) of terminating discount verification if it is determined (S740) that the discount eligibility requirements are met in the step (S730 or S730`) of verifying discount validity. In addition, the method according to one embodiment of the present invention may include a step (S770) of terminating discount verification if it is determined (S760) that the discount eligibility requirements are not met in the step (S730 or S730`) of verifying discount validity.

[0448] As illustrated in FIG. 31c, the method of the present invention may further include a data processing step (S741) so that, when it is determined that the discount eligibility requirements are met (S740), the administrator can optionally determine whether to terminate the discount voucher based on the administrator's review. For example, even if the verification model determines that the discount eligibility requirements are met (S740) in the discount validity verification step (S730 or S730'), there may be cases where the discount eligibility requirements are actually met. In this case, in the data processing step (S741), the administrator can optionally review whether the discount eligibility requirements are met, and modify and / or supplement the verification model's output result (a result indicating that the requirements are met) to a verification result indicating that the requirements are not met. A subsequent evaluation step (S780) may also be performed based on the modification and / or supplementation of such verification results.

[0449] As illustrated, the method of the present invention may further include a data processing step (S761) so that, when it is determined that the discount eligibility requirements are not met (S760), the administrator can selectively determine whether to terminate the discount voucher based on the administrator's review. For example, even if the verification model determines that the discount eligibility requirements are not met (S760) in the discount validity verification step (S730 or S730'), there may be cases where the discount eligibility requirements are actually met. In this case, in the data processing step (S761), the administrator can selectively review whether the discount eligibility requirements are met, and modify and / or supplement the verification model's output result (a result indicating that the requirements are not met) to a verification result indicating that the requirements are met. A subsequent evaluation step (S780) may also be performed based on the modification and / or supplementation of such verification results.

[0450] According to FIG. 31c, after the discount verification is completed, a step (S780) of performing a follow-up evaluation based on the model verification results and a step (S790) of generating and / or supplementing Ground Truth to improve the model through the follow-up evaluation may be further included. Furthermore, according to one embodiment of the present invention, a step (S791) of improving the verification model based on the generated and / or supplemented Ground Truth may be further included, and the improved model based on the generated and / or supplemented Ground Truth learning data set may be utilized in the discount validity verification step (S730 or S730`).

[0451] Meanwhile, after the step (S780) of performing a follow-up evaluation based on the model verification results, the step (S791) of improving and / or learning the verification model may be performed directly without going through the step (S790) of generating and / or supplementing the ground truth. According to embodiments of the present invention, the step (S791) of improving and / or learning the verification model may be performed by at least one of a method of tuning a prompt, a method of adjusting a learning data set, and a learning-based method of modifying parameters of a language model. In addition, according to embodiments of the present invention, the performance of the model may also be improved by a method of improving the design of the agent.

[0452] As mentioned above, the design of agents that use Large Language Models (LLM) or Multimodal Large Language Models (MLLM) as reasoning engines can be broadly divided into the Finite State Machine (FSM) method and the Turing Complete method. It should be understood that the performance of the model can be improved by improving the design of the agent through these methods.

[0453] According to embodiments of the present invention, supervised learning and / or reinforcement learning may be used as model learning methods. Furthermore, according to embodiments of the present invention, the model may be improved by tuning prompts.

[0454] An agent that performs a method to automate verification of whether AI-based discount eligibility requirements are met.

[0455] Figures 33a and 33b are flowcharts illustrating the operations of agent components that perform a method for automating verification of whether AI-based discount eligibility requirements are met according to embodiments of the present invention. The operations of the agent components according to embodiments of the present invention may be performed by the processor unit of at least one of the server (100), the electronic device (200), and the user terminal (300). Meanwhile, the agent according to embodiments of the present invention may perform the data verification operation according to the present invention by utilizing a pre-written code program.

[0456] An agent according to embodiments of the present invention may perform rule-based verification operations, such as actively writing code programs, rather than utilizing pre-written code programs. For example, if the user's name information included in the user information previously stored in the database of the server (100) is 'Hong Gil-dong', and the user's name information extracted from the input supporting document is 'Hong Gil-sun', the agent may actively create a rule to perform additional operations to identify or verify the user information. Here, the rule created by the agent is not pre-defined by the agent developer or service provider, and in this case, the agent can provide a discount verification service according to the present invention by adapting to an unpredictable or dynamic environment.

[0457] According to FIGS. 33a and 27b, an agent component according to one embodiment of the present invention may include a first agent (1000) that performs data collection and organization operations, a second agent (2000) that performs data verification operations, and a third agent (3000) that manages the overall operations and data, including the first agent (1000) and the second agent (2000). The third agent (3000) reviews the collation results, such as whether an error has occurred in the data collected by the first agent (1000), and then decides whether to transmit the collated data to the second agent (2000). In addition, even after the second agent (2000) verifies the data, the third agent (3000) may review the verification results of the second agent (2000), such as whether there is a problem with the verification results.

[0458] If there is an error in the data verification result, an operation may be performed to determine whether the error originated from the first agent (1000) or the second agent (2000). In addition, the third agent (3000) may perform an operation to retransmit a work instruction to at least one of the first agent (1000) and the second agent (2000) to correct the error in the verification result after determining whether the error in the verification result originated from the first agent (1000) or the second agent (2000).

[0459] As illustrated in FIGS. 33a and 33b, after the first agent (1000) performs data collection and organization operations, the model's inference process can be improved by performing a feedback loop based on the operation results. After the second agent (2000) performs data verification operations, the model's inference process can be improved by performing a feedback loop based on the operation results. After the third agent (3000) performs an operation to determine whether an error in the data verification result is caused by the first agent (1000) or the second agent (2000), if an error is found in the data verification result, the third agent (3000) can perform an operation to retransmit a work instruction to at least one of the first agent (1000) and the second agent (2000) to correct an error in the verification result, and furthermore, based on this determination, the overall model's inference process can be improved through a feedback loop.

[0460] As illustrated in FIGS. 33a and 33b, after performing data collection and organization operations, the first agent (1000) may perform operations to supplement the context for model inference and / or inference enhancement through a feedback loop based on the operation results. The second agent (2000) may perform operations to supplement the context for model inference and / or inference enhancement through a feedback loop based on the operation results, after performing data verification operations.

[0461] If there is an error in the data verification result, the third agent (3000) can perform an operation to determine whether the error originated from the first agent (1000) or the second agent (2000), and then, based on this determination, perform an operation to supplement the context for inference and / or inference enhancement of the overall model through a feedback loop.

[0462] In addition, as illustrated in FIGS. 33a and 27b, the first agent (1000) and the second agent (2000) may exchange data, such as input data or output data, with each other during the process of performing data collection and organization operations and data verification operations, and may exchange feedback with each other based on the results of the operations. In addition, as illustrated in FIG. 33b, at least one of the first agent (1000), the second agent (2000), and the third agent (3000) may perform operations according to embodiments of the present invention, and then improve the agent so that the model's inference process is improved through a self-feedback loop based on the results of the operations.

[0463] According to one embodiment of the present invention, the artificial intelligence model can provide its own feedback on the inference result and classify or evaluate the degree of reliability into categories such as "very low," "low," "average," "high," or "very high." In this way, the inference result can be reviewed by classifying or evaluating one of the categories having linguistic meaning as the reliability of the inference result using a multi-classification method. Meanwhile, an additional inference process may be included before classifying or evaluating the category of the inference result in this way. By assigning categories to reliability in this way and reviewing the inference result, the evaluation process of the model's inference result can be simplified, and the service for determining whether the discount eligibility requirements according to the present invention are met can be effectively assisted.

[0464] Agent actions to understand data

[0465] Figure 34a is a flowchart illustrating the operation of the first agent (1000) component illustrated in Figures 33a and 33b. The step (S730 or S730') of verifying the validity of a discount according to one embodiment of the present invention may include a step of identifying the content of input data (at least one of information and supporting documents for discount verification) using a natural language processing-based artificial intelligence model, and verifying the validity of the discount based on the identified content.

[0466] Specifically, as illustrated in FIG. 34a, the step (S730 or S730`) of verifying the validity of a discount according to one embodiment of the present invention may include at least one of a step of receiving a discount validity verification request and data (S731), a step of identifying the input data (S732), and a step of outputting the data identification result (S733). Here, identifying the data may mean identifying the content of the data.

[0467] Specifically, the step of identifying the input data (S732) may further include a step of identifying the content of the input data by utilizing an OCR and / or natural language processing-based model. Specifically, the step of identifying the content of the input data (S732) may include at least one of a step of identifying the details of a discount policy and the validity conditions of the discount (S732a), a step of identifying information on users and events (S732b), a step of identifying verifiable information in supporting documents (S732c), a step of identifying the integrity of the content of supporting documents (S732d), a step of identifying the relationship between data (S732e), a step of generating data by integrating the input data (S732f), and a step of standardizing the format of the data (S732g).

[0468] According to embodiments of the present invention, the content of data input into the model may be the same, but the formats may be different. For example, data indicating a date of birth or a specific date may be entered in various formats such as 'August 1, 1985', '1985-08-01', or '850801'. However, in the system database, data indicating a date of birth or a specific date may be stored in the format '1985-08-01'. In this case, in order for the model to infer results through the input data, the input data indicating a date of birth or a specific date needs to be standardized into a format such as '1985-08-01'. In the step of standardizing the format of the data (S732g), an operation of standardizing data input in various formats may be performed.

[0469] As illustrated in FIG. 34a, the first agent (1000) may perform a feedback loop to improve the model's inference process based on the data identification result (S733). Through the feedback loop, at least one of the above-described processes may be modified and / or supplemented, or the configuration of the model performing the above-described process may be modified and / or improved. For example, based on the data identification result (S733), the data input in the discount validity verification request and data input step (S731) may be fed back, or a model for performing one or more operations included in the input data identification step (S732) may be fed back.

[0470] Agent actions to verify data

[0471] Figure 34b is a flowchart illustrating the operation of the second agent (2000) component illustrated in Figures 33a and 33b. The second agent (2000) performs an operation of outputting a data verification result based on the data identification result performed by the first agent (1000). Here, data verification may mean verifying whether the identified and / or identified data satisfies the discount eligibility requirements.

[0472] As illustrated in FIG. 34b, the step (S730 or S730`) of verifying the validity of a discount according to one embodiment of the present invention may include at least one of a step of establishing a data verification plan (S734), a step of verifying data (S735), and a step of outputting a data verification result (S736). According to one embodiment of the present invention, the third agent (3000) may perform the step of establishing a data verification plan (S734) based on the data identification result (S733), and the second agent (2000) may perform the step of verifying data (S735) and the step of outputting a data verification result (S736) based on the established data verification plan.

[0473] In the step (S734) of establishing a data verification plan according to one embodiment of the present invention, the verification plan is comprehensively established by the third agent (3000), and the operation of a task can be instructed to the first agent (1000) and / or the second agent (2000) based on the established plan. The verification plan can be modified even while the third agent (3000) is reviewing the results of the operation performed by the first agent (1000) and / or the second agent (2000), thereby enabling the advancement of the task at the overall process level.

[0474] There may be cases where the given discount information contains items other than the name of the discount policy. In this case, in the data verification plan development step (S734), at least one agent according to embodiments of the present invention may define its own discount eligibility requirements, or define its own rules regarding which items should be verified, by considering the remaining information about the discount policy and the content of the entered data.

[0475] In this way, even if the discount eligibility requirements or rules for what to check are not pre-established, the AI ​​model can automatically define the discount eligibility requirements or rules for what to check, thereby reducing or minimizing human intervention in the process of verifying whether the discount eligibility requirements are met.

[0476] With this type of automation, the agent automatically sets the rules for defining discount eligibility requirements or determining what to check, rather than the existing method of treating discount eligibility requirements as hyper-parameters of the model and having the model verify whether the eligibility requirements are met based on the contents of the preset discount eligibility requirements.

[0477] Specifically, information previously stored in the database and information about input supporting documents (including information converted to text information based on algorithms such as OCR) can be included in the prompt that the agent operates on and entered as contextual information. Here, even if the items to be checked to verify whether the discount eligibility requirements are met or the description of the discount policy is not previously entered as contextual information, the agent can proceed with subsequent processes such as automatically defining the discount eligibility requirements by utilizing (relatively) limited information such as the name and / or type of the discount policy and the entered supporting documents. That is, in the step (S734) of establishing a data verification plan according to one embodiment of the present invention, the agent can establish and / or modify the data verification plan based on contents inferred from other input information even if the description of the discount policy is not previously entered as contextual information.

[0478] Referring to Figure 32c, discount information may be registered in the system and previously stored in the database. If discount information previously stored in the database is entered as contextual information in the step of receiving discount verification information (S710), the data verification plan may be established and / or modified based on the discount information entered as contextual information in the step of establishing the data verification plan (S734). However, even if the discount information illustrated in Figure 32c does not include information to be verified to verify whether discount eligibility requirements are met or a description of the discount policy, the agent may establish and / or modify the data verification plan based on information inferred from other entered information.

[0479] According to one embodiment of the present invention, the step of verifying data (S735) may include at least one of the step of verifying whether a discount benefit is applied (S735a) and the step of converting the format of the data (S735b). Here, the step of converting the format of the data (S735b) may be a step of converting the format of the data to enhance data verification. The step of converting the format of the data (S735b) according to one embodiment of the present invention may be a step of converting the input data into a data type that can be handled by a rule-based model or an artificial intelligence model.

[0480] As illustrated in FIG. 34b, the second agent (2000) may perform a feedback loop to improve the model's inference process based on the data verification result (S736). Through model learning, at least one of the above-described processes may be modified and / or supplemented, or the configuration of the model performing the above-described process may be modified and / or improved. For example, based on the data verification result (S736), the data identification result (S733) may be fed back, and / or a model for performing one or more operations included in the input data identification step (S732) may be fed back. Alternatively, based on the data verification result (S736), the plan established in the data verification plan establishment step (S734) may be fed back, and / or a model for performing one or more operations included in the data verification step (S735) may be fed back.

[0481] Figures 35a to 35d are conceptual diagrams for explaining the configuration of a system for providing a service according to one embodiment of the present invention.

[0482] A system according to one embodiment of the present invention may include a server (100), an external server (20), and a user terminal (300). The server (100), the external server (20), and the user terminal (300) may exchange data with each other via a network.

[0483] A system according to one embodiment of the present invention may include a server (100) and a user terminal (300). The server (100) and the user terminal (300) may exchange data with each other via a network.

[0484] A system according to one embodiment of the present invention may include an external server (20) and a user terminal (300). In the system according to one embodiment of the present invention, the external server (20) and the user terminal (300) may exchange data with each other via a network.

[0485] A system according to the present invention may include a server (100), an electronic device (200), and a user terminal (300). In the system according to the present invention, the server (100), the electronic device (200), and the user terminal (300) may mutually transmit and receive data for the system of the present invention via a network. Here, the system illustrated in FIG. 1D is according to one embodiment, and its components are not limited to the embodiment illustrated in FIG. 1D, and may be added, changed, or deleted as needed.

[0486] According to embodiments of the present invention, when original data (raw data) related to a seating chart is input to a user terminal (300), the server (100) and / or an external server (20) may analyze the input original data to generate seat cluster data included in the seating chart or individual seat data included in the seat cluster. The generated seat cluster data and / or individual seat data may be output through the user terminal (300) and provided to the user.

[0487] However, the role of each device is not limited thereto. Specifically, the external server (20) may be implemented as a server (100), and thus the server (100) may perform at least some of the functions of the external server (20). Alternatively, the server (100) may be implemented as an external server (20), and thus the external server (20) may perform at least some of the functions of the server (100). Alternatively, both the server (100) and the external server (20) may be implemented as a user terminal (300), and the user terminal (300) may perform at least some of the functions of the server (100) and / or the external server (20).

[0488] For example, since a model for performing operations of the server (100) and the external server (20) is implemented in the user terminal (300), both the input and analysis operations of the original data can be performed in the user terminal (300). Alternatively, since a model for performing operations of the external server (20) is implemented in the server (100), the server (100) can perform all analysis operations of the original data without calling the API of the external server (20). Alternatively, since a model for performing operations of the server (100) is implemented in the external server (20), the external server (20) can perform at least a part of the operations of the server (100).

[0489] Fig. 36 is a block diagram illustrating an external server (20) according to one embodiment of the present invention. According to the present invention, the external server (20) may be a terminal device or a server, and may include any type of device. The external server (20) may be an electronic device, such as a personal computer (PC), a laptop computer, a tablet PC, or a mobile phone, equipped with a processor and memory and capable of computing. The external server (20) may include a memory unit (21), a processor unit (22), and a communication unit (23).

[0490] Analysis of raw data and data generation methods for seating charts

[0491] Figure 37 is a flowchart for explaining a method for analyzing original data of a seating chart according to one embodiment of the present invention.

[0492] A method for analyzing original data of a seating chart according to one embodiment of the present invention may include a seating chart original data input step (S1011), a seat cluster identification step (S1101), a received seat cluster data parsing step (S1201), an individual seat data extraction step (S1301) within a seat cluster, an individual seat data parsing step (S1401) within a seat cluster, a step of integrating seat cluster data (S1501), an integrated data output step (S1031), and a conditional branching step (S1021) for outputting blank data when no seat cluster data exists.

[0493] A seat cluster identification step (S1101) according to one embodiment of the present invention may include a step of inputting seat map data and a first prompt into a VLM (S1111), a step of extracting a seat cluster data list through the VLM (S1121), and a step of receiving a seat cluster data list (S1131).

[0494] The step (S1301) of extracting individual seat data within a seat cluster according to one embodiment of the present invention may include a step (S1311) of transmitting seat map data and a second prompt and inputting them into a VLM, and a step (S1321) of receiving individual seat data analysis results. The step (S1301) of extracting individual seat data within a seat cluster may include a step of repeatedly performing an individual seat data extraction operation via the VLM for each cluster.

[0495] Seating chart original data input step (S1011)

[0496] The seating chart original data input step (S1011) according to one embodiment of the present invention is a step of inputting the seating chart original data to be analyzed into the system through a user terminal (300), and this data can be transmitted to the server (100) via a network. The seating chart original data according to one embodiment of the present invention may vary depending on various space types such as a performance hall, a stadium, an auditorium, etc., and may generally be provided in an image file format such as PNG, JPEG, BMP, etc. Alternatively, the seating chart original data according to one embodiment of the present invention may be implemented in any other data format other than an image file format.

[0497] According to one embodiment of the present invention, the input prompt displayed through the input unit (340) and / or the input / output interface of the user terminal (300) may include a file upload interface for the original data of the seating chart, and the user may select the original data of the seating chart located in the local storage or an external server through this prompt and transmit it to the system.

[0498] Furthermore, according to one embodiment of the present invention, the user terminal (300) can receive not only the original data of the seating chart, but also auxiliary information for the analysis request. For example, analysis requests or analysis conditions such as "analysis centered on the first floor seating area," "request for analysis of the area including the VIP block," and "analysis centered on the area facing the front of the stage" can be input from the user as natural language-based analysis conditions or natural language commands, and the information can be used later as prompt configuration or filtering criteria.

[0499] According to one embodiment of the present invention, input image data is transmitted to the server (100) via the communication unit (130) of the server (100), temporarily / non-temporarily stored in the internal server memory or storage by the memory unit (110), and then can be utilized in a subsequent processing step (S1101). At this time, data temporarily / non-temporarily stored in the internal server memory or storage by the memory unit (110) can be preserved based on the original resolution.

[0500] Seat cluster identification step (S1101)

[0501] The seat cluster identification step (S1101) according to one embodiment of the present invention is a step of identifying visually distinct seat clusters (zones) within the image based on the input original seat map data. The seat cluster identification step (S1101) may be performed on the server (100).

[0502] The seat cluster identification step (S1101) according to one embodiment of the present invention may be a step of inputting the original data of the seating chart and the first prompt into an artificial intelligence model to extract visually distinct seat cluster data. The seat cluster identification step (S1101) according to one embodiment of the present invention may include a step of inputting the seating chart data and the first prompt into a VLM (S1111), a step of extracting a seat cluster data list through the VLM (S1121), and a step of receiving the seat cluster data list (S1131).

[0503] The step (S1111) of inputting the first prompt into the VLM according to one embodiment of the present invention may be a step of transmitting the entire seating arrangement original data and the first prompt stored in the memory unit (110) of the server (100) to an external server (20) and processing them as inputs of the VLM installed in the external server (20).

[0504] According to one embodiment of the present invention, a first prompt may be comprised of a set of commands that instruct the VLM to identify visually independent seat clusters or sections within an input image and extract a name and bounding box for each cluster. Specifically, the first prompt may include instructions for the model to consider when analyzing data and information regarding the analysis items of the target data. For example, the first prompt may include instructions such as, "Identify visually distinct seat clusters from the original data of the seating chart. Clusters are visual blocks distinguished by aisles, labels, price zones, etc., and for each cluster, extract a bounding box (x, y, width, height) and a cluster name. Infer the name from adjacent text, but generate a logical name if an explicit label is not provided." By means of system prompts including such instructions, the VLM model can be designed to infer semantic segmentation of the seating structure.

[0505] According to one embodiment of the present invention, the first prompt for seat cluster identification may be predefined as a system prompt within the system, but may be designed to be modified during development or flexibly adjusted based on user requests. For example, in some embodiments, analysis items within the prompt, output data format, bounding box coordinate precision, etc. may be variably adjusted based on image resolution, seat arrangement density, or analysis purposes.

[0506] The step (S1121) of extracting a seat cluster data list according to one embodiment of the present invention may be a step in which a VLM installed in an external server (20) analyzes an input image based on a first prompt and the entire seat map original data (e.g., input data such as a seat map original image) and infers information about visually independent seat clusters within the image.

[0507] According to one embodiment of the present invention, the VLM can identify semantically separated seat clusters (clusters) based on visual cues such as aisles, price zones, and text labels on the entire image, according to the analysis purpose and guidelines described in the first prompt. At this time, each identified cluster object includes a unique cluster name and bounding box information (x, y, width, height), and the corresponding coordinates are expressed as coordinates based on the origin (e.g., the upper left corner) of the entire image. The bounding box coordinate information (e.g., x, y, width, height, etc.) referred to herein is based on a pixel-unit global coordinate system whose origin is (0,0) at the upper left corner of the original data of the original seating chart, unless otherwise specified. Meanwhile, in some embodiments, when the input image is resized or rotated, the bounding box coordinates can be calculated as corrected values ​​corresponding to the transformation, and even after the correction, they can be converted and stored in the global coordinate system, and a transformation rule can be applied so as to be mapped to the global coordinate system.

[0508] The names of the identified seating clusters can be inferred based on directly identifiable text labels in the image, or on surrounding semantic cues (e.g., block-by-block arrangement, color areas, label proximity, etc.), as guided by the prompt. If text is clearly labeled, it can be used as is. If no label is provided, names for the corresponding items can be generated based on visual patterns (e.g., "top left block," "1st floor center section," "2nd floor balcony seats left block").

[0509] According to one embodiment of the present invention, the VLM can generate such cluster information in the form of a list of objects configured in a standardized structure, and the list is transmitted to the server (100) in a subsequent step (S1131). The data generated as a result of this step is defined according to the global coordinate system based on the original data of the entire seating chart, and therefore can be utilized as is without separate coordinate transformation in the subsequent step of individually extracting and integrating seat data within each cluster.

[0510] The seat cluster data list transmission step (S1131) according to one embodiment of the present invention may be a step of transmitting the result data generated by the VLM through the seat cluster data list extraction step (S1121) from an external server (20) to the server (100).

[0511] According to one embodiment of the present invention, the external server (20) may generate a response in the form of structured data including one or more seat cluster objects generated by the VLM and transmit the response to the server (100) in the form of a response to an API call. The response data may be composed of an array of cluster objects including a name identified for each seat cluster and bounding box information defining the cluster (e.g., coordinate information (x, y) of the bounding box and size information (width, height) of the bounding box).

[0512] The transmitted data is received through the communication unit (130) of the server (100), and then temporarily / non-temporarily stored in the memory unit (110), and can be parsed in a subsequent step (S1201) to be utilized as a list of individual analysis targets for each seat cluster. At this time, all coordinates within the response data are defined according to a global coordinate system normalized based on the original data of the entire seating chart, and thus can be directly used for subsequent seat information extraction and integrated processing. Through this step (S1131), the server (100) receives the analysis results for each seat cluster from the VLM of the external server (20), thereby defining the block structure within the entire seating chart and contributing to securing reference data for subsequent seat data extraction flows.

[0513] Parsing the received seat cluster data step (S1201)

[0514] The seat cluster data parsing step (S1201) according to one embodiment of the present invention may be a step of receiving a seat cluster data list transmitted to the server (100) from the VLM of the external server (20), and then parsing each cluster object to convert it into an internal reference structure for subsequent individual analysis steps.

[0515] In the seat cluster data parsing step (S1201), the processor unit (120) of the server (100) normalizes the received cluster data structure into a common data structure that can be used in the internal processing module, and extracts fields such as cluster name and bounding box coordinates (x, y, width, height) from each cluster object. Example JSON field names may be expressed as "type", "x", "y", "clusterName", "seatNumber", "row", "rowLabel", etc., but it should be understood that they may be replaced with different equivalent notations depending on the implementation.

[0516] The coordinate information extracted at this time maintains the global coordinate system based on the original data of the entire seating arrangement defined in step S1101, so it can be directly referenced in the subsequent seat data extraction step (S1301) without a separate coordinate conversion process.

[0517] Meanwhile, in some embodiments of the present invention, a dedicated conversion module can be called for each input data format to convert it into an internal common data structure. The extracted fields are then used as criteria for identifying and referencing each cluster in the cluster-specific seat information extraction step (S1301), which is performed repeatedly thereafter.

[0518] Additionally, according to one embodiment of the present invention, exception handling, such as data integrity verification, duplicate object removal, and checking for missing required fields, can be performed during the parsing process. For example, cluster objects that are invalid or have format errors can be configured to be excluded from the analysis. For example, if the bounding box coordinates are outside the image area, the cluster name is empty, or the field value is abnormally negative, the object can be determined to be invalid and excluded from the analysis. In some embodiments, the history of such invalid objects and errors can be logged and utilized for future reprocessing or quality verification.

[0519] As a result of the seat cluster data parsing step (S1201), the seat cluster list is stored in the memory unit (110) of the server (100) in a parsed and verified state, and can be used as reference data for repeated execution in the individual seat data extraction step (S1301) within the seat cluster. As a result, the transmitted seat cluster data is organized in a formally and logically consistent state, thereby improving the processing stability and efficiency of the subsequent analysis step.

[0520] Step 1: Extract individual seat data within a seat cluster (S1301)

[0521] The step (S130) of extracting individual seat data within a seat cluster according to one embodiment of the present invention is a step repeatedly performed for each cluster object extracted through the seat cluster data parsing step (S1201), and may be a process of identifying and extracting individual seat information included in the cluster area based on metadata for each cluster.

[0522] The step (S1301) of extracting individual seat data within a seat cluster according to one embodiment of the present invention can be performed by calling a VLM (Vision Language Model) running on an external server (20) in an API manner from the server (100), and in this process, a second prompt including the original data of the entire seating chart and cluster meta information for each cluster object is configured and transmitted to the external server (20) (S1311), and the individual seat data analysis result can be received from the analysis response of the VLM in response (S1321).

[0523] The individual seat data analysis result according to one embodiment of the present invention may include individual seat information, and the identified individual seat information may include information such as coordinate (x, y) information corresponding to each seat location within a bounding box, a seat number, a name of a row or block including the seat, and visually identifiable row / column labels.

[0524] According to one embodiment of the present invention, the second prompt includes the name of the cluster that is currently the subject of analysis and bounding box information (e.g., bounding box location information (x, y) and bounding box size information (width, height)), and may include instructions for instructing the VLM to perform analysis based on the corresponding area. According to one embodiment of the present invention, the second prompt for extracting individual seat information may be in a form predefined as a system prompt within the system, but may be designed so that some of its contents may be changed during development or so that it may be dynamically adjusted according to user request conditions. For example, in some embodiments, it may be configured so that it is dynamically modified according to changes in the development environment or user request conditions.

[0525] According to one embodiment of the present invention, the server (100) may provide the original data of the entire seating chart and the second prompt for each cluster to the VLM installed on the external server (20). Given this context, the VLM performs an analysis centered on a designated bounding box area within the entire image and can identify individual seat information contained within the area. The individual seat data analysis results returned by the VLM may include information such as the coordinates (x, y) of each seat within the bounding box, the seat number, the row or block name to which the seat belongs, and visually identifiable row / column labels. Since this information is provided based on the global coordinate system defined in step S110, separate coordinate transformation may not be necessary during subsequent parsing, sorting, etc.

[0526] According to one embodiment of the present invention, cluster-by-cluster analysis can be performed independently and repeatedly for each cluster, and even when multiple clusters exist in the original data of a single seating chart, analysis can be performed in parallel or sequentially by referencing the same original image. Furthermore, in some embodiments, validity verification (e.g., seat count discrepancies, coordinate range errors, reliability information calculation, etc.) and / or error logging of VLM responses can be performed to enhance analysis reliability and ensure the possibility of subsequent reprocessing.

[0527] The individual seat information extracted at this stage may be data corresponding to each individual seat arranged in the seating chart cluster image, and may be converted into structured data format and stored and utilized in the individual seat data parsing step (S1401) within the seat cluster.

[0528] Parsing individual seat data within a seat cluster (S1401)

[0529] The step (S1401) of parsing individual seat data within a seat cluster according to one embodiment of the present invention may be a process of normalizing individual seat data analyzed for each cluster through the step (S130) of extracting individual seat data within the seat cluster into a structured format. This step is performed on the server (100), and may include a process of analyzing a list of seat data accumulated and received for multiple clusters, and then converting it into an internal format that can be processed in the data integration step (S1501). In some embodiments, errors occurring during parsing or excluded cluster objects may be logged, which can be used for later reprocessing or quality verification.

[0530] According to one embodiment of the present invention, in the individual seat data parsing step (S1401) within a seat cluster, the individual seat data parsed may include coordinates (x, y), a seat number, a name of a row or block containing a seat, a label type, and other visually recognizable additional information (text, etc.), and these fields may be mapped according to a predefined schema format. The individual seat data parsing step (S1401) within a seat cluster may perform a consistency judgment procedure such as detecting overlap or duplication between clusters, checking for missing fields, and verifying consistency between fields, based on the fact that the coordinates (x, y) are defined based on the original data of the entire seating chart.

[0531] In some embodiments, in addition to individual seat objects, row labels and explicit zone tags (e.g., objects of type rectangle) identified within the same cluster may also be parsed. These objects can be classified based on predefined type fields (e.g., dots, row labels, rectangles, etc.) and then stored separately in the integration target structure. The parsed results are preserved while maintaining the coordinate system relative to the entire image, allowing them to be directly utilized during subsequent data integration and output processes without additional coordinate system transformation.

[0532] Step for integrating seat cluster data (S1501)

[0533] The step (S1501) of integrating seat cluster data according to one embodiment of the present invention may be a process of collecting data for each cluster that has been standardized in the step (S140) of parsing individual seat data within the seat cluster and merging them into a single structured data based on the entire seating chart. The step (S1501) of integrating seat cluster data is performed on the server (100), and object data that has been sorted for each cluster is merged so that a consistent output structure corresponding to the entire seating chart can be formed.

[0534] According to one embodiment of the present invention, the data to be integrated includes fields included in each seat object (e.g., type, x, y, seat number, row, row label, row label type, text, etc.) and visual additional information (fill, stroke, width, height, etc.). The integrated result is configured in the form of a single array and can be generated as a single output JSON object or a similar format (e.g., XML, CSV, Protobuf, Avro, internal binary format, etc.). Example JSON keys can be "type", "x", "y", "seatNumber", "row", "rowLabel", etc. In addition, since the coordinate information of all objects is defined based on the global coordinate system of the original data of the entire seating chart, they can be merged without location duplication or coordinate conflict between clusters.

[0535] In some embodiments, the integration step may include post-processing such as removing or merging duplicate coordinates between objects, supplementing missing fields or setting default values, unifying the sort order of objects (such as sorting by row or cluster), and integrating classifications by type.

[0536] The single structured data generated as a result of the step of integrating seat cluster data (S1501) can be converted into a format that can be transmitted to an external reservation system, etc., in the subsequent output step (S103). Therefore, the step of integrating seat cluster data (S1501) may correspond to the final matching step that expands the results of the cluster-level analysis to the global seating chart level, thereby generating actual digital seat structure data from the input image that was the subject of visual analysis.

[0537] Integrated data output step (S1031)

[0538] The integrated data output step (S1031) according to one embodiment of the present invention may include a process of converting the single structured data generated in the step of integrating seat cluster data (S1501) into a final output format. The integrated data output step (S1031) may be performed on a server (100) and / or a user terminal (300), and may output a result configured in a single JSON or similar data format including an array of seat objects sorted based on the original data of the entire seating chart.

[0539] According to one embodiment of the present invention, the output structured data may include various object types such as dots, row labels, and named objects (rectangles), and each object may have fields such as location coordinates (x, y), visual properties (width, height, fill, etc.), seat numbers, row information, and additional text. This output data may be linked to an external system such as a seating chart editor or a reservation system to intuitively provide information on seat location, number, and zone.

[0540] The format of the data output at this stage may be, for example, JSON, but is not limited thereto and may be implemented to be converted into various structured representation methods (XML, CSV, Protobuf, Avro, internal binary format, etc.). The output target may be displayed on the user terminal (300) as needed or automatically transmitted through an interface linked to an external system.

[0541] Conditional branching step (S1021) that outputs blank data

[0542] The conditional branching step (S1021) according to one embodiment of the present invention may be a step for outputting empty structured data as an exception handling procedure corresponding to a case where valid seat cluster data is not extracted through the seat cluster identification step (S1101), i.e., a case where the cluster list is empty. In this specification, empty structured data may refer to output data in which the schema is maintained but the seat object arrangement is empty.

[0543] According to one embodiment of the present invention, if the server (100) detects that the cluster list does not exist (or is empty) as a result of performing steps S1101 to S1131, it skips the flow leading to the subsequent seat data extraction (S1301) to integration (S1501) steps and outputs structured data with empty content in a predefined format. This structured data does not include seat objects and may typically include an empty list or a blank structure.

[0544] Example of analyzing seating chart data

[0545] Figure 38a is a diagram illustrating original data related to a seating chart according to one embodiment of the present invention. Figure 38b is a diagram illustrating bounding boxes corresponding to one or more clusters identified from the original data related to the seating chart according to one embodiment of the present invention. Figure 38c is a diagram illustrating individual seat data included in one or more clusters according to one embodiment of the present invention.

[0546] Original data related to the seating chart

[0547] Figure 38a is a diagram illustrating original data related to a seating chart according to one embodiment of the present invention. The original data may be input data, such as an original image of a seating chart. The original data of the seating chart illustrated in Figure 38a represents the overall seating arrangement structure installed in a small theater, with the seats arranged left and right and front and back based on the performance stage. Figure 38a is an example of an original image that is the target of seat information extraction, including the seat arrangement method, the naming system of rows and columns, the aisle structure, and special seating areas.

[0548] Referring to an image of a seating chart according to one embodiment of the present invention, the rows of seats included in the seating chart form a front-back axis from the front of the stage to the rear of the theater from A to M, and the seat numbers (1 to n) within each row are arranged in a left-right direction. The central aisle divides the seat blocks into left, center, and right, and the seat number progression direction of the left and right blocks can be indicated from outside to inside or inside to right, respectively.

[0549] In the example of Figure 38a, the numbers are displayed from larger to smaller from the outside to the inside of the left block, while the numbers are displayed from smaller to larger from the outside to the inside of the right block. This notation system can be dynamically modified based on user requests, etc., providing visually clear divisions for seat number and location recognition, and can be used as a basis for subsequent cluster naming and seat number consistency verification.

[0550] In the original data related to the seating chart illustrated in Figure 38a, row names are identical on both the left and right sides, visually indicating that the same row corresponds to both sides. For example, both the left and right sides of row A are labeled "A," which can be utilized as key information when identifying clusters or blocks. Furthermore, special seats, such as wheelchair-accessible seats, are identifiable at the bottom center of row M. Such section information can be recognized as an object type in the seating information analysis prompt of the present invention and stored as tags.

[0551] According to one embodiment of the present invention, the original data of the seating chart illustrated in FIG. 38a may correspond to the original image input in the original data input step (S1011), and thereafter, through the seat cluster identification step (S1101), it is divided into clusters such as a left block, a right block, and a center block, and information such as seat location (x, y coordinates), number, and row within each cluster may be extracted through second prompt analysis.

[0552] One or more clusters identified in the seating chart

[0553] FIG. 38b is a diagram illustrating bounding boxes corresponding to one or more clusters identified from original data related to a seating chart according to one embodiment of the present invention.

[0554] The original data of the illustrated seating chart is an image based on the same small theater seating chart as in Fig. 38a, and a number of bounding boxes representing the visual boundaries of seat clusters derived from the analysis results of the VLM (Vision Language Model) are illustrated.

[0555] According to one embodiment of the present invention, the bounding box illustrated in FIG. 38b defines visually independent seat blocks based on the instructions of the first prompt, and is subsequently utilized as an analysis target area for extracting information such as seat location (x, y), number, and row included in each cluster. This visual cluster structure effectively segments the semantic compartments of a complex seating chart, thereby serving as a basis for precisely extracting individual seat information within a global coordinate system based on the entire image.

[0556] As illustrated in FIG. 38b, the original data of the seating chart shows a total of six bounding boxes (Bounding Box 1 to Bounding Box 6), which are the final result of seat cluster identification, as a result of analysis performed by calling the VLM of the external server (20) in step S1101 based on the first prompt. Specifically, step S1101 of the present invention may include a step (S1111) of inputting the original data of the entire seating chart and the first prompt into the VLM of the external server (20), a step (S1121) of extracting a list of cluster data through the VLM, and a step (S1131) of receiving the corresponding data by the server (100), and the bounding boxes of FIG. 38b visually depict the seat cluster structure identified through this series of analysis flows.

[0557] Each bounding box is a visual region that identifies a cluster of seating blocks, which can be separated from each other so as not to overlap. For example, Bounding Box 1 encompasses the upper left block, consisting of some seats in Rows A through F on the upper left of the stage. Bounding Box 2 corresponds to the main seating block located at the center of the stage. Bounding Box 3 defines the upper right area of ​​the stage. Bounding Boxes 4, 5, and 6 are the left, center, and right areas, respectively, located at the bottom of the seating chart.

[0558] Each cluster illustrated in Figure 38b may be provided with information on the upper left position (x, y) and size (width, height) of the bounding box, which may be defined based on the pixel-unit global coordinate system of the original data of the entire original seating chart. Each bounding box may have a field structure expressed as, for example, {x=220, y=110, width=300, height=180}, but is not limited thereto.

[0559] One or more of the above-described information may be inferred or generated by the VLM based on text labels, zone markings, or arrangement patterns within the original data of the seating chart, which may then be used as reference information in cluster-based seating analysis through the second prompt.

[0560] Each cluster depicted in Figure 38b can be assigned a name, such as a bounding box name. These names can be inferred or generated by the VLM through text labels (OCR results) within the original seating chart data, zone markings, or analysis of seating patterns. For example, intuitive names such as "Left Front Block" and "Right Rear Block" can be assigned, which can be used as Regions of Interest (ROIs) in the subsequent second prompt-based individual seat data extraction step (S1301) and parsing step (S1401).

[0561] Individual seat data included in one or more clusters

[0562] FIG. 38c is a diagram illustrating individual seat data included in one or more clusters identified in FIG. 38b, according to one embodiment of the present invention. The image depicted in FIG. 38c is an example of a result of visually displaying the coordinates and attributes of individual seats located within each cluster (bounding box) described with reference to FIG. 38b, extracted based on the original seating chart image (see FIG. 38a).

[0563] In one embodiment of the present invention, individual seat data may include attribute information such as the center point location (x, y) of each seat, seat number, row information, and optionally, section name or seat grade. The x, y coordinates are defined based on the pixel-unit global coordinate system of the original data of the entire original seating chart, which ensures consistency in the mapping between clusters and seats by using the same reference system as the bounding box coordinate system of FIG. 4b.

[0564] Step (S1301) may include a step of configuring a second prompt including the original data of the entire seating chart and cluster meta information for each cluster object and transmitting it to an external server (20) (S1311), and receiving an individual seat data analysis result from the analysis response of VLM (S1321). The individual seat data analysis result may be expressed as the seat data illustrated in FIG. 4c.

[0565] For example, the seats contained in Bounding Box 2 (see Figure 38b) are located in the main block at the center of the stage, and the number and row information for each seat within the cluster (Bounding Box 2) are extracted by VLM, along with coordinate data. This data can then be directly utilized in various application services, such as seat reservation, occupancy analysis, and route simulation. This individual seat data analysis can be performed for Bounding Box 2, as well as Bounding Boxes 1 through 6.

[0566] The individual seat data presented in Figure 38c enables precise seat-level identification and, when combined with cluster-level visual segmentation (Figure 38b), provides a foundation for systematic analysis of complex performance hall, auditorium, and theater seating structures. This enables hierarchical cluster-to-seat references in the global coordinate system and can serve as the foundation for subsequent analyses (e.g., detecting empty seats within specific clusters and analyzing the distribution of seating classes within clusters).

[0567] How to detect suspicious users

[0568] Figure 39 is a flowchart illustrating a method for detecting a suspicious user according to one embodiment of the present invention.

[0569] As illustrated, the method for detecting a suspicious user may include a step of receiving an authentication request (S5101), a step of tracking authentication attempts (S5201), a step of comparing the number of authentication attempts with a threshold value (S5301), a step of classifying a user as a suspicious user based on the comparison result of step S5301 (S5311), a step of determining whether to proceed with a normal procedure based on the comparison result of step S5301 (S5401), a step of storing user behavior data (S5501), a step of analyzing a pattern of data (S5601), and a step of updating a classification criterion (S5701).

[0570] Step of receiving an authentication request (S5101)

[0571] The step (S5101) of receiving an authentication request according to one embodiment of the present invention is a step in which the server (100) receives an authentication-related request (e.g., a login request, a user authentication request, a one-time authentication request via SMS / alarm talk, etc.) generated via a user terminal (300) or an electronic device (200). The authentication request via the user terminal (300) or the electronic device (200) may be transmitted to the communication unit (130) of the server (100) via a network.

[0572] According to one embodiment of the present invention, the authentication request may include at least some of user account identification information, ticket identification information, request type, request time (Timestamp), network connection information, environment information of the user terminal (300), and session identification information.

[0573] In some embodiments, for the purpose of protecting personal information, identification information for terminals, sessions, tokens, etc. may be replaced with hash values, tokenized, pseudonymized, and then received and / or stored. An authentication request received by the communication unit (130) of the server (100) may be temporarily / non-temporarily stored by the memory unit (110) of the server (100), and the processor unit (120) may perform subsequent steps (S5201) based on the authentication request.

[0574] According to one embodiment of the present invention, the communication unit (130) of the server (100) can receive external linkage signals such as OTP / SMS authentication results and financial institution identity verification responses received from the communication unit (230) of the external server (20) in addition to the authentication-related request received from the communication unit (330) of the user terminal (300).

[0575] The processor unit (120) of the server (100) can combine the above signals into the context of an authentication request, temporarily / non-temporarily store them in the memory unit (110), and generate a tracking key (e.g., account, terminal, session, network identifier hash, etc.) in a subsequent step (S5201). In some embodiments, a pre-check can be performed to cross-check a user input (e.g., a one-time code) obtained from the input unit (340) of the user terminal (300) and a response from an external server (20).

[0576] Step 5: Tracking Authentication Attempts (S5201)

[0577] The step (S5201) of tracing an authentication attempt according to one embodiment of the present invention is a step in which the processor unit (120) of the server (100) traces the authentication attempt history for each user terminal (300) or electronic device (200) based on information included in the received authentication request.

[0578] According to one embodiment of the present invention, the server (100) can track authentication attempts based on the same account, the same terminal, the same network section, or the same session. Specifically, metadata such as the request time, request result, authentication method (e.g., password input, SMS authentication, app push authentication, etc.), and authentication path (e.g., web, app, API request) for each authentication attempt may be recorded together, and the server (100) can track one or more pieces of information included in such metadata.

[0579] According to one embodiment of the present invention, the server (100) can store authentication attempt information in a memory unit (110) or a separate log storage, and the stored data can be accumulated and managed in chronological order and used for later abnormal pattern analysis (S5601) and classification criterion update (S5701).

[0580] In a second embodiment, the server (100) may store authentication attempt information in conjunction with additional context data (e.g., location information, device identifier, network fluctuations, etc.) transmitted from the terminal (300) or electronic device (200).

[0581] Meanwhile, the server (100) can perform real-time monitoring during the authentication attempt tracking process via the processor unit (120). If excessive authentication requests or abnormal patterns are detected within a specific time period, the processor unit (120) can generate a warning signal or utilize it for threshold comparison in the subsequent conditional branching step (S5301). Thus, step S5201 can serve not only as a simple record but also as a source of basic data for real-time security monitoring and post-analysis.

[0582] According to one embodiment of the present invention, the processor unit (120) of the server (100) can track the authentication history accumulated in the memory unit (110), including the external server (20) response code, delay time, retry pattern, etc. In this process, mapping can be performed with the log of the external server (20) through the communication unit (130), and a real-time alarm flag can be set when an abnormal increase is detected within a specific period. This result can be utilized as a weight in the branch decision of the subsequent step (S5301), and, if necessary, can be displayed as a warning message on the output unit (350) of the user terminal (300) or the output unit (250) of the electronic device (200).

[0583] Step of comparing the number of authentication attempts with the threshold value (S5301)

[0584] The step (S5301) of comparing the number of authentication attempts with a threshold value according to one embodiment of the present invention is a step in which the processor unit (120) of the server (100) compares the number of authentication attempts with a predetermined reference threshold value based on the authentication attempt history tracked in step S5201 to determine whether the authentication procedure is normal.

[0585] According to one embodiment of the present invention, a predetermined threshold value against which the number of authentication attempts is compared may be set in advance by the system operator or variably adjusted by a dynamic calculation algorithm based on machine learning. For example, if the number of repeated authentication failures occurring within a short period of time for the same account or user terminal (300) exceeds a predetermined threshold value, the user's access behavior may be determined to be abnormal.

[0586] According to one embodiment of the present invention, the threshold value may be set to a fixed value, but in other embodiments, it may be variably adjusted according to a time period, a service type, characteristics of a ticket event (e.g., in the case of a popular performance, game, event, etc.), user group attributes (e.g., new account / existing account), etc. Furthermore, the server (100) may perform threshold comparison by comprehensively considering not only the number of authentication attempts but also the type of failure (e.g., incorrect password, expired OTP, unauthorized access path), the interval between authentication requests, network fluctuation patterns, etc.

[0587] According to one embodiment of the present invention, the result of comparing the number of authentication attempts with a threshold value can be used as basic data for determining whether to proceed with a normal procedure (S5401) or classify a suspicious user (S5801) in a subsequent conditional branch step (S5311). Specifically, if the number of authentication attempts is less than the threshold value, the control flow can proceed to the normal procedure proceed step (S5401). On the other hand, if the number of authentication attempts is greater than the threshold value, the access behavior of the user who sent the authentication request is considered abnormal, and the control flow can branch to the step (S5311) of classifying the user as a suspicious user.

[0588] According to one embodiment of the present invention, the processor unit (120) of the server (100) can transmit the result of classifying a user as a suspicious user to the communication unit (430) of the electronic device (200) through the communication unit (130). The processor unit (220) of the electronic device (200) can verify the ticket data presented by the user terminal (300) on site by utilizing the verification key or recent ticket status information stored in the memory unit (210). In this process, the input unit (240) of the electronic device (200) can collect additional verification procedures such as rescanning or identification input, and the output unit (250) can display whether access is permitted, requires additional verification, or is blocked.

[0589] According to one embodiment of the present invention, the processor unit (120) can precisely determine whether to branch by additionally considering the type of authentication failure, authentication request interval, change in network connection location, environmental properties of the user terminal (300) and the electronic device (200), etc., rather than simply based on whether the threshold is exceeded. For example, if repeated failures are detected at short time intervals in the same terminal environment, the user may be classified as a suspect user even before the threshold is reached and branched to step S5311. Conversely, failures distributed over a long period of time may be considered as a normal category even if the threshold is exceeded and branched to step S5401.

[0590] In addition, according to one embodiment of the present invention, the processor unit (120) of the server (100) can comprehensively consider not only the number of authentication attempts, but also the OTP response from the external server (20), the type of financial identity verification failure, and the distribution of delay time via the communication unit (330) of the user terminal (300). The failure type or time interval deviation of the same identification group (account, terminal, session, network band) can be utilized as a factor in the weighted criticality judgment, and the result can be recorded in the memory unit (110) and used as a basis for subsequent steps (S5311, S5401).

[0591] Step (S5401) for deciding whether to proceed with normal procedures based on the comparison results

[0592] The step (S5401) of determining normal procedure progress according to one embodiment of the present invention may include a step of controlling the processor unit (120) of the server (100) to consider the user's authentication request as normal access and continue the subsequent procedure if the number of authentication attempts is determined to be less than the threshold value as a result of the comparison in step S5301.

[0593] According to one embodiment of the present invention, normal procedure progress may include normally performing subsequent processes related to ticket services, such as ticket reservation, payment, issuance, and verification. In addition, the memory unit (110) of the server (100) may store session data, authentication logs, user environment information, etc. generated during the normal procedure progress, and such data may be additionally utilized in a subsequent user behavior data storage step (S5501). According to some embodiments, the normal procedure progress step (S5401) may not only allow service use, but may also update the user's account status to a normal user or dynamically reflect classification criteria to include the user in a normal user group during a subsequent analysis step.

[0594] According to one embodiment of the present invention, when normal procedure progress is determined, the processor unit (120) of the server (100) can perform payment approval or financial identity verification by linking with the communication unit (230) of the external server (20) via the communication unit (130). The processor unit (220) of the external server (20) stores the processing result in the memory unit (210), and the response can be displayed on the output unit (350) of the user terminal (300) or the output unit (250) of the electronic device (200) via the server (100). At this time, the approval identifier and response details can be recorded in the memory unit (110) of the server (100) and utilized in subsequent steps (S5501, S5601, S5701).

[0595] Step for saving user behavior data (S5501)

[0596] The step (S5501) of storing user behavior data according to one embodiment of the present invention is a step in which the processor unit (120) of the server (100) stores user-related behavior data collected during the authentication request processing process. The user behavior data may include, for example, whether the authentication attempt was successful or failed, the authentication attempt interval, the request occurrence time (Timestamp) and session duration, environment information of the user terminal (300) (operating system, browser, app / web classification, etc.), network access information (IP address, bandwidth / ASN, connection region, etc.), input account identification information or tokenized identifier, and log data generated during the authentication processing process. According to some embodiments, the user behavior data may be stored in a state in which a technique such as a hash value, pseudonymization, or tokenization is applied to protect personal information.

[0597] According to one embodiment of the present invention, user behavior data may be temporarily / non-temporarily stored in the memory unit (110) of the server (100), and according to another embodiment, it may be stored in an external database (DB) or distributed storage. In this case, the external database may be linked through the communication unit (130) of the server (100), and encrypted transmission or access control may be performed to ensure the security and integrity of the data. In addition, the stored data may be utilized as input data for pattern analysis performed in a subsequent step (S5601). According to embodiments of the present invention, short-term storage may be used for real-time detection purposes, and long-term storage may be used for machine learning-based model training or long-term user behavior analysis.

[0598] According to one embodiment of the present invention, the processor unit (120) of the server (100) may store, in the memory unit (110), the results of field verification performed on the electronic device (200), the financial approval details and OTP authentication response with the external server (20), and whether a warning has been displayed on the output unit (350) of the user terminal (300) along with user behavior data. When storing, account, terminal, session, and network information are anonymized in the form of hashing or tokenization, and in some embodiments, a log for auditing purposes may also be stored in parallel in the memory unit (210) of the external server (20).

[0599] Step of analyzing data patterns (S5601)

[0600] Step (S5601) of analyzing data patterns according to one embodiment of the present invention is a step of receiving user behavior data stored in step (S5501) as input, extracting features for determining whether a user is suspicious from the data, and analyzing the pattern. The pattern analysis may be performed by the processor unit (120) of the server (100), and in some embodiments, may be performed in conjunction with an external analysis module or a separate artificial intelligence server.

[0601] FIG. 41 is a diagram illustrating a method for identifying normal users and suspicious user groups by analyzing patterns of user data according to one embodiment of the present invention.

[0602] Pattern analysis of user data according to one embodiment of the present invention may include a process of classifying groups of suspected users through statistical correlation and / or clustering analysis.

[0603] Pattern analysis of user data according to one embodiment of the present invention may consist of the following flow: raw user data collection, feature extraction and correlation analysis, clustering and group determination, and designation of additional verification waiting for cluster units.

[0604] The set of dots on the left side of Figure 41 represents user data accumulated in the system. Each dot represents an abstraction of an analysis unit, such as an account, session, or ticket. Data may include information such as login / authentication time, access IP address, terminal information, browser information, and SMS authentication request history.

[0605] As illustrated, the data analysis engine can analyze user data based on one or more characteristics, such as authentication time patterns, IP addresses, device information, login attempt intervals, and SMS request patterns, and can detect user behavior patterns by considering statistical correlations between each characteristic. Specifically, the behaviors of normal and suspicious users can be distinguished based on the time intervals of authentication attempts, repetition frequency, changes in access locations, network bandwidth / ASN distribution, abnormal fluctuation patterns in terminal environments (terminal information, access browser, operating system, etc.), and session duration included in the user behavior data.

[0606] For example, if the authentication time interval is constant or abnormally short, if multiple accounts attempt authentication simultaneously from a specific IP address range, if authentication is attempted while rapidly switching between multiple IP ranges, if repeated connection attempts are made by disguising the same terminal environment, or if SMS requests frequently occur after repeated failures from the same device, the user may be classified as a suspicious user group distinct from normal users.

[0607] According to one embodiment of the present invention, the data analysis engine can go beyond analyzing individual user characteristics and cluster multiple users to analyze group-level behavior. If a small number of users in a specific group are identified as suspicious, the remaining user group with a high correlation can be identified as additional verification targets. This allows for the effective detection of organizational and clustered patterns that are difficult to identify through individual rule-based detection.

[0608] Specifically, the right area of ​​Figure 41 illustrates how the analysis results are expressed in clusters (dotted circles). The node-link structure within each dotted circle represents a cluster of users with relatively similar authentication behaviors, and the links (edges) visualize the similarity and connectivity between users. As illustrated in the right area of ​​Figure 41, there may be clusters identified / classified as suspicious user groups and clusters identified / classified as having normal usage patterns based on the engine's judgment.

[0609] In some embodiments, pattern analysis can go beyond simple rule-based detection and utilize machine learning-based classification techniques or graph-based correlation analysis algorithms. In this case, a model trained from a dataset of past normal and suspicious users can be configured to probabilistically determine whether new user data falls within a normal pattern, and the entire user data can be classified into clusters of normal usage patterns and / or clusters of suspicious user patterns.

[0610] According to one embodiment of the present invention, the processor unit (120) of the server (100) can extract features such as field verification results, linkage delay and error code distribution of the external server (20), payment approval / rejection patterns, etc. from the data accumulated in the memory unit (110) and perform statistical correlation analysis. In some embodiments, the processor unit (220) of the external server (20) can return the results of analysis by applying a pre-learned model to the server (100), and the server (100) can synthesize the results to make a final decision.

[0611] The verification results from the step of analyzing data patterns (S5601) can be used as judgment criteria or verification data for the analysis engine through the step of updating classification criteria (S5701).

[0612] Step to update classification criteria (S5701)

[0613] The step (S5701) of updating the classification criteria according to one embodiment of the present invention is a step of updating the classification criteria for distinguishing between normal users and suspicious users by reflecting the pattern analysis results performed in step (S5601).

[0614] The step of updating the classification criteria (S5701) may be performed by the processor unit (120) of the server (100), and in some embodiments, may be performed in conjunction with an external machine learning server or data analysis engine.

[0615] According to one embodiment of the present invention, classification criteria may include statistical thresholds, rule-based conditions, machine learning model parameters, and the like, and may be updated periodically or event-based based on changes in user data and the discovery of new suspicious user patterns. For example, if the distribution of the number of repeated attempts within a specific time interval deviates from the existing normal user range, a new threshold may be automatically reset to reflect this distribution.

[0616] Additionally, in a machine learning-based embodiment, the normal user and suspicious user data determined in step (S5601) may be reflected in the learning dataset, and a classification model update may be performed to improve future determination accuracy.

[0617] In some embodiments, classification criteria updates can be performed in real-time or batch processing, and new classification criteria can be applied immediately or after an administrator's verification process. Through this classification criteria update process, the user authentication system according to the present invention can proactively respond to changes in user behavior and new attack patterns, maintaining a highly reliable and secure authentication environment over the long term.

[0618] According to one embodiment of the present invention, the processor unit (120) of the server (100) stores the updated classification criteria by reflecting the analysis results of step S5601 in the memory unit (110), and, if necessary, synchronizes them with the memory unit (210) of the external server (20) to maintain a consistent policy. In addition, a notification or guidance screen according to the new classification criteria can be provided to the output unit (350) of the user terminal (300) or the output unit (250) of the electronic device (200) through the communication unit (130), and the history can be stored for auditing purposes.

[0619] Event ticket authentication process

[0620] FIG. 40 is a drawing for explaining an authentication method of an event ticket according to one embodiment of the present invention.

[0621] As illustrated, the method for authenticating an event ticket may include a step of scanning a ticket (S6101), a step of checking a ticket message (S6201), a step of providing a ticket message so that an administrator can check it (S6211), a step of determining whether to request an additional authentication method (S6301), a step of verifying the additional authentication method (S6401), and a step of determining whether the provided additional authentication method is correct (S6501). In addition, based on the determination result in step S6501, if it is determined that a correct authentication method has been provided, the method may proceed to a step of allowing entry with a warning record (S6511), and if not, the method may proceed to a step of determining whether to deny entry with a warning record (S6521), and a step of invalidating the ticket message (S6531). After the step of allowing / denying entry with a warning record, a step of updating the verification result in a database (S6601-1, S6601-2) may be included.

[0622] According to one embodiment of the present invention, a server-based suspicious user detection procedure and an on-site ticket authentication procedure can operate complementarily. Specifically, the server (100) analyzes abnormal behavior based on data collected from a user terminal (300), electronic device (200), and / or an external server (20) and reflects the results in the on-site verification process. Accordingly, the present invention provides a multi-layered security system that combines pre-detection and post-authentication, effectively blocking large-scale macro purchases or resale attempts that would be difficult to prevent with a single procedure.

[0623] Step 1: Scan the ticket (S6101)

[0624] Step (S6101) of scanning a ticket according to one embodiment of the present invention is a process of reading an event ticket held by a user through an electronic device (200), and may be a step of extracting one or more pieces of identification information from the event ticket. Here, the event ticket held by the user may be a ticket printed in the form of a paper ticket, but may also be a digital ticket message output through the output unit (350) of the user terminal (300).

[0625] An electronic device (200) according to one embodiment of the present invention is a device configured to recognize a ticket and may be implemented as a QR code reader, a barcode reader, an RFID reader, or a similar scanning device. In the step of scanning a ticket (S6101), one or more pieces of identification information included in the ticket, such as ticket information, event information, user information, discount voucher information, ticket ID information, issuance time, and encryption code, are extracted, and the extracted information may be transmitted to a server (100) for reference in a subsequent authentication procedure.

[0626] In one embodiment of the present invention, the step of scanning a ticket (S6101) may not only read the code through image recognition, but also verify security elements to prevent counterfeiting. For example, the use of simply copied tickets can be prevented by verifying special ink, holograms, or encrypted signature values ​​provided by the issuing system printed on the surface of the ticket. Furthermore, the data acquired during the scanning process may be temporarily / non-temporarily stored in the memory unit (110) of the server (100) and / or the memory unit (210) of the electronic device (200), or managed in conjunction with an external database. The data acquired during the scanning process may be utilized as basic data for the ticket message verification and administrator provision procedures performed in subsequent steps (S6201, S6211).

[0627] Step to check ticket message (S6201)

[0628] Step (S6201) of verifying a ticket message according to one embodiment of the present invention is a process of determining whether the ticket has been validly issued based on one or more pieces of identification information extracted in step S6101. Here, the ticket message is digital authentication data issued by a device that issued the ticket (e.g., a server device, etc.), and may include a ticket ID, event name, event date and location, user account information, issuance time, and an encrypted signature value.

[0629] According to one embodiment of the present invention, the processor unit (120) of the server (100) may perform a comparison with the issuance history stored in the memory unit (110) and / or an external database by referring to the identification information transmitted in step S610. During this process, if an unissued ID, an expired ticket, a previously used ticket, or forged or altered data is detected, the ticket message may be determined to be invalid. In addition, the step of verifying the ticket message (S6201) may include not only a simple comparison with the issuance history but also data integrity verification. For example, the server (100) may detect whether data has been forged or altered by verifying an encrypted signature value or hash value, and may perform an operation such as invalidating the ticket based on the detection result, thereby preventing the use of illegally copied or illegally generated tickets. At this time, the determination result generated during the ticket message verification process may be recorded in the form of a log in the memory unit (110) or an external database in a subsequent step, so that it can be utilized for future security audits and user behavior analysis.

[0630] Step 6: Providing a security ticket message to the administrator (S6211)

[0631] In an authentication method for an event ticket according to one embodiment of the present invention, the step (S6211) of providing a security ticket message to an administrator is a step performed through the output unit (250) of the electronic device (200) using the ticket message verified in step S6201, and is a process of displaying the security ticket message on the output unit (250) of the electronic device (200). At this time, the output unit (250) of the electronic device (200) may be equipped with an administrator-only interface separate from the user terminal (300), through which the administrator can directly check the authenticity of the ticket, the issuance status, the usage history, etc.

[0632] According to one embodiment of the present invention, the electronic device (200) may provide security information (e.g., separate verification data, which may be referred to as a security ticket) that can only be verified by an administrator, along with the ticket message. The security ticket is provided in a form that is not exposed to general users and may include an encryption code provided by the ticket issuing server (100), a hash value for anti-counterfeiting, or a unique authentication marker. Using this information, the administrator can additionally determine whether a ticket, even if it appears normal on the surface, is susceptible to forgery or alteration.

[0633] Additionally, in one embodiment of the present invention, security ticket information is provided only through an administrator-only channel and is not displayed on the user terminal (300) or a general display. This maintains transparency during the authentication process while preventing unauthorized users from tampering with or circumventing the security verification logic. Furthermore, the provided security ticket information is recorded in the memory unit (110) of the server (100) or in an external database, where it can be used as basic data for future authentication history management and security audits.

[0634] Step to determine whether to request additional authentication methods (S6301)

[0635] In an event ticket authentication method according to one embodiment of the present invention, the step (S6301) of determining whether to request an additional authentication means is a step performed by the processor unit (220) of the electronic device (200), and is a process of determining whether an additional authentication procedure is necessary for the user's identity based on the determination result of the ticket message confirmed in step S6201 and / or the security ticket confirmed in step S6211. The request for an additional authentication means may be directly determined by the administrator through the input unit (240) of the electronic device (200), but may also be determined by the processor unit (220) of the electronic device (200) through pattern analysis and / or algorithmic operation.

[0636] Specifically, if the ticket message is validated and there are no issues with the security ticket, the entry process can proceed without requesting additional authentication methods. However, if some of the ticket information is incomplete or potential risks (e.g., repeated authentication attempts, potential for forgery, exceeding a risk threshold set by the administrator policy, etc.) are detected during the security ticket verification process, the control flow may proceed to step S6301, where the electronic device (200) requests the user terminal (300) to provide additional authentication methods.

[0637] These additional authentication methods can be implemented, for example, through biometric authentication information (fingerprint, face, iris, etc.) provided through the user terminal (300), a secondary password, a one-time passcode (OTP), or a separate administrator approval request. Therefore, this step can improve the reliability of the authentication procedure by applying the concept of multi-factor authentication (MFA) rather than relying solely on single ticket information.

[0638] Step for verifying additional authentication methods (S6401)

[0639] In the method for authenticating an event ticket according to one embodiment of the present invention, the step (S6401) of verifying an additional authentication means is a process in which the processor unit (120) of the server (100) and / or the processor unit (220) of the electronic device (200) receives the additional authentication means requested in the step S6301 through the user terminal (300) or a separate input device, and verifies or determines the same. Specifically, the additional authentication means received in the step (S6401) of verifying an additional authentication means may be implemented in various ways, such as biometric authentication data (e.g., fingerprint, face, iris), one-time passcode (OTP), secondary password, administrator approval signal, etc., and the electronic device (200) may compare the same with pre-registered user information or authentication criteria within a storage such as the memory unit (110) of the server (100), the memory unit (210) of the electronic device (200), or an external database, to determine authenticity.

[0640] In addition, the step of verifying the additional authentication means (S6401) does not simply check whether the authentication means are in formal conformity, but rather comprehensively verifies the validity period, issuing entity, and security signature value of the authentication means, thereby preventing the use of forged or altered authentication means.

[0641] Additionally, in the step (S6401) of verifying an additional authentication method, a financial authentication procedure performed by the server (100) and / or the electronic device (200) in conjunction with a financial institution API via the communication unit (230) of the external server (20) may be processed. Through this, the authenticity of the user's payment method can be quickly confirmed, and the result can be transmitted to the server (100) and / or the electronic device (200) to be utilized for verifying the additional authentication method.

[0642] The verification result is provided as a judgment criterion in the subsequent step (S6501), and if the correct authentication method is provided, the normal procedure is maintained, but if not, it may branch to the warning recording and entry denial step (S6521).

[0643] Step (S6501) for determining whether the provided additional authentication method is correct

[0644] In the method for authenticating an event ticket according to one embodiment of the present invention, the step (S6501) of determining whether the provided additional authentication means is correct is a process in which the processor unit (220) of the electronic device (200) finally determines the validity of the authentication means based on the verification result performed in step S6401. Specifically, in the step (S6501) of determining whether the provided additional authentication means is correct, whether the provided additional authentication means matches pre-registered user information, whether it was provided within the validity period, whether there are any traces of forgery or alteration, etc. are comprehensively considered to determine whether it is a normal authentication means.

[0645] In one embodiment of the present invention, the electronic device (200) can consider the security log generated during the verification process, the number of authentication successes / failures, the results of cross-verification with the server (100), etc., and through this, a reliable judgment beyond simple matching can be made.

[0646] If the result of the judgment is confirmed to be the correct authentication method, the process can proceed to the entry permission and warning recording step (S6511), and if not, the process can branch to the entry denial and warning recording step (S6521) and ticket message invalidation step (S6531).

[0647] Meanwhile, a series of user input and / or result display processes performed in steps S6101 to S6501 may be provided through an input unit (340) and / or an output unit (350) of a user terminal (300), or an input unit (240) and / or an output unit (250) of an electronic device (200). For example, the electronic device (200) may display ticket information transmitted from the user terminal (300), perform additional input or confirmation procedures, and intuitively provide the judgment result received from the server (100) to the user and / or operator.

[0648]

[0649] Step to allow entry with warning record (S6511)

[0650] In an event ticket authentication method according to one embodiment of the present invention, the step (S6511) of allowing entry with a warning record is a subsequent process performed when the processor unit (220) of the electronic device (200) determines that the additional authentication means provided in step S6501 is correct. Specifically, in the step (S6511) of allowing entry with a warning record, since the ticket presented by the user is determined to be normal, a control signal may be generated to allow the user to enter the event. For example, a gate control device, a door opening device, or a similar control module may be activated to allow the user to enter.

[0651] However, since the fact that an additional authentication method is requested during the authentication process may itself be considered a suspicious situation in terms of security, the processor unit (220) may allow entry while simultaneously recording the fact as a warning record.

[0652] The warning record can be stored in the memory unit (110) of the server (100), the memory unit (210) of the electronic device (200), or an external database, and can be used as basis data for user behavior pattern analysis (S5601) or classification criteria update (S5701). Therefore, the step of allowing entry with the warning record (S6511) simultaneously considers security and user convenience, and serves to ensure the possibility of tracking potential threat factors while guaranteeing the entry of normal users.

[0653]

[0654] Steps to determine whether to record a warning and deny entry (S6521)

[0655] In an event ticket authentication method according to one embodiment of the present invention, the step (S6521) of recording a warning and determining whether entry is denied is a subsequent step performed when the processor unit (220) of the electronic device (200) determines that the additional authentication means provided in step S6501 is incorrect. Specifically, in the step (S6521) of recording a warning and determining whether entry is denied, a control signal may be generated to deny the user entry to the event because the ticket and additional authentication means presented by the user are determined to be unreliable. For example, a gate control device or door opening device may be controlled to not operate, and a blocking log along with the reason for the operation may be transmitted to the administrator.

[0656] Additionally, in the step (S6521) of recording a warning and determining whether to deny entry, the fact that the authentication attempt failed may be recorded as a warning through the user terminal (300) or electronic device (200). The warning record may include ticket information, user information, failure reason (e.g., incorrect additional authentication method input, counterfeit ticket determination, etc.), occurrence time, etc., and this information may be stored in the memory unit (110) of the server (100), the memory unit (210) of the electronic device (200), or an external database.

[0657] In one embodiment of the present invention, such warning records can be reused in the user behavior pattern analysis (S5601) and classification criteria update (S5701) steps, thereby contributing to the establishment of an authentication policy with enhanced security.

[0658] Step to invalidate the ticket message (S6531)

[0659] In the authentication method of an event ticket according to one embodiment of the present invention, the step (S6531) of invalidating a ticket message is a process performed by the processor unit (220) of the electronic device (200) when the user's entry is denied in step S6521.

[0660] In this step, the ticket message can be invalidated on the server (100) and / or an external database to prevent the reuse of tickets that have already been determined to have failed authentication. For example, the unique identifier (ID) or encryption code assigned to the ticket message can be added to a blacklist database, or the issuing system can change the status to "unusable." In addition, the invalidated ticket message can be displayed on an administrator-only screen or a secure ticket interface, enabling immediate identification if the same user attempts to repeatedly use the same ticket. This can fundamentally prevent the reuse of simple duplicates or forged tickets. Furthermore, the records generated during the invalidation process can be stored in the memory unit (110) of the server (100), the memory unit (210) of the electronic device (200), or an external database. These records can be utilized in the step (S5601) of analyzing data patterns in conjunction with a method for detecting suspicious users, or can be utilized as basic data in the step (S5701) of updating classification criteria.

[0661] Step for updating the verification results to the database (S6601-1, S6601-2)

[0662] In the authentication method of an event ticket according to one embodiment of the present invention, the data update step (S6601-1) in the case where entry is permitted is a step performed by the processor unit (220) of the electronic device (200), and is a subsequent process performed by reflecting the determination result of step S6511.

[0663] In the data update step (S6601-1) when entry is permitted, the user's ticket message is updated to a "used" status, and a warning record for the user may be stored together in the memory unit (110) of the server (100), the memory unit (210) of the electronic device (200), and / or an external database. This allows reuse of the same ticket to be fundamentally blocked, and users with accumulated warnings to be identified as subjects for future management. In addition, the updated information is reflected in the memory unit (110) of the server (100), the memory unit (210) of the electronic device (200), and / or an external database, and can be confirmed in real time through a security ticket interface exclusive to the administrator. Furthermore, the stored confirmation result record can be utilized as basic data for the pattern analysis step (S5601) and the classification criteria update step (S5701) in conjunction with a method for detecting suspicious users, thereby contributing to continuously strengthening the security of the authentication system.

[0664] In the authentication method of an event ticket according to one embodiment of the present invention, the data update step (S6601-2) in the case where entry is denied is a step performed by the processor unit (220) of the electronic device (200), and is a subsequent process performed by reflecting the result of step S6521 or S6531.

[0665] In the data update step (S6601-2) when entry is denied, the user's ticket message is changed to an "invalidated" status, and the reason for denial (e.g., suspected forgery, duplicate use, authentication failure, etc.) and related user information may be recorded in the memory unit (110) of the server (100), the memory unit (210) of the electronic device (200), and / or an external database. These records can be checked in real time on an administrator-only screen, and support the rapid detection of repeated forgery attempts by the same user or the same device in the future. Furthermore, the stored verification result records and / or invalidation records can be utilized as basic data for the data pattern analysis step (S5601) and the classification criteria update step (S5701) in conjunction with a method for detecting suspicious users, thereby contributing to continuously strengthening the security of the authentication system. Through this, the authentication system can provide an intelligent and dynamically evolving security framework that goes beyond a simple ticket verification procedure.

[0666] According to one embodiment of the present invention, the judgment results and warning records generated in the event ticket authentication process (S6101 to S6601) described with reference to FIG. 40 may be stored in the memory unit (110) of the server (100), the memory unit (210) of the external server (20), the memory unit (210) of the electronic device (200), and / or an external database.

[0667] The judgment results and warning records generated during the event ticket authentication process (S6101 to S6601) can be utilized in conjunction with the data storage (S5501), pattern analysis (S5601), and classification criteria update (S5701) steps of the suspicious user detection method. Accordingly, the individual ticket authentication process performed on-site can be integrated with server-based anomaly detection and user behavior analysis, allowing the data obtained during repetitive ticket authentication processes to contribute to improving the accuracy of the suspicious user detection algorithm in the long term.

[0668] According to one embodiment of the present invention, the judgment results and user behavior records generated in each step (S6101 to S6601) of FIG. 40 may be stored in the server (100) and / or the external server (20), and then fed back to the data collection and pattern analysis steps illustrated in FIG. 39. Through this feedback loop, cases detected in on-site authentication are reflected in the criteria of a server-based detection algorithm in real time or post-facto, thereby implementing a self-learning structure in which detection performance continuously improves over time.

[0669] Although the above description focuses on examples, these are merely examples and do not limit the present invention. Those skilled in the art will appreciate that various modifications and applications not exemplified above are possible without departing from the essential characteristics of the present invention. For example, each component specifically shown in the examples can be modified and implemented. In addition, differences related to such modifications and applications should be construed as being included within the scope of the present invention defined in the appended claims.

[0670] [Explanation of symbols]

[0671] 10: Ticket Message

[0672] 11: Ticket Information

[0673] 12: Event Information

[0674] 13: User Information

[0675] 14: Discount Code

[0676] 15: Verification code

[0677] 16: Discount Proof Information

[0678] 17: Ticket ID information

[0679] 100: Server

[0680] 110: Memory section

[0681] 120: Processor section

[0682] 130: Communications Department

[0683] 200: Electronic devices

[0684] 200a: Electronic devices

[0685] 200b: Electronic devices

[0686] 210: Memory section

[0687] 220: Processor section

[0688] 230: Communications Department

[0689] 240: Input section

[0690] 250: Output section

[0691] 300: User terminal

[0692] 310: Memory section

[0693] 320: Processor section

[0694] 330: Communications Department

[0695] 340: Input section

[0696] 350: Output section

Claims

1. A method for providing a ticket message related to an event, the method being performed by a server processor, A step of generating one or more ticket messages; A step of receiving a verification request and a public key of the user terminal from a user terminal; When the user terminal is verified, a step of encrypting a first ticket message among the one or more ticket messages with the public key of the user terminal and transmitting the encrypted message to the user terminal; A step of receiving a verification request and a public key of the electronic device from an electronic device; and When the electronic device is verified, a step of encrypting the one or more ticket messages with the public key of the electronic device and transmitting the encrypted message to the electronic device; including, A method for providing ticket messages related to an event.

2. In paragraph 1, The above ticket message is, Contains user information and includes at least one of ID information for identifying the ticket message, ticket information, discount voucher information, and event information. A method for providing ticket messages related to an event.

3. In paragraph 2, The above user information is: Contains the user's identification information and is encrypted with the user terminal's secret key. A method for providing ticket messages related to an event.

4. In paragraph 2, The above ticket information is, Contains at least one of ticketing information, seat information, and delivery information of the ticket; The above event information is, Including at least one of the date and time information of the above event and the location information of the above event, A method for providing ticket messages related to an event.

5. In any one of paragraphs 1 to 4, At least one of the above user information, the above ticket information, the above discount voucher information and the above event information is encrypted with a ticket secret key. A method for providing ticket messages related to an event.

6. A method for verifying a ticket message related to an event, the method being performed by a processor of an electronic device, A receiving step of receiving a public key assigned to the event from a server, one or more ticket messages encrypted with the public key assigned to the event, and a private key assigned to the event; A step of decrypting the one or more encrypted ticket messages with the private key assigned to the event; A step of receiving, from a user terminal, a verification request, a public key of the user terminal, and a first ticket message encrypted with the public key assigned to the event; and When the user terminal is verified, a step of decrypting the encrypted first ticket message with a private key assigned to the event, comparing the decrypted first ticket message with one or more decrypted ticket messages, and performing verification on the first ticket message is included. A method for validating ticket messages related to an event.

7. In paragraph 6, The above receiving step is, A step of including user information, wherein the above ticket message includes user information; and The ticket message further includes a ticket message identification step, wherein the ticket message includes at least one of ID information for identifying the ticket message, ticket information, discount voucher information, and event information; A method for validating ticket messages related to an event.

8. In paragraph 7, The above user information inclusion step is: A step in which the user information includes the user's identification information; and A step of encrypting the user information with a secret key of the user terminal is further included; A method for validating ticket messages related to an event.

9. In paragraph 7, The above ticket message identification step is: A step in which the ticket information includes at least one of issuance information, seat information, and delivery information of the ticket; and A step in which the event information includes at least one of the date and time information of the event and the location information of the event; A method for validating ticket messages related to an event.

10. In any one of paragraphs 6 to 9, A step of encrypting at least one of the user information, the ticket information, the discount voucher information, and the event information with a ticket secret key; A method for validating ticket messages related to an event.

11. In paragraph 8, A step of receiving the secret key of the user terminal from the user terminal; A step of decrypting the encrypted user information included in the decrypted first ticket message using the received secret key; and Further comprising a step of performing verification on the user information based on the decrypted user information; A method for validating ticket messages related to an event.

12. In any one of paragraphs 6 to 9 and paragraph 11, further comprising a step of requesting additional verification of the first ticket message from the server; A method for validating ticket messages related to an event.

13. A method for providing a ticket message related to an event, the method being performed by a processor of an electronic device, A receiving step of receiving a public key assigned to the event and a private key assigned to the ticket message from the server; A step of receiving, from a user terminal, a verification request, a request for generating the ticket message, and a public key of the user terminal; When the user terminal is verified, a step of generating the ticket message, wherein the ticket message includes information encrypted with the secret key assigned to the ticket message; A step of encrypting the generated ticket message with the public key of the user terminal; and a step of transmitting the encrypted ticket message to the user terminal; A method for providing ticket messages related to an event.

14. In paragraph 13, The above receiving step is, A step of including user information, wherein the above ticket message includes user information; and The ticket message further includes a ticket message identification step, wherein the ticket message includes at least one of ID information for identifying the ticket message, ticket information, discount voucher information, and event information; A method for validating ticket messages related to an event.

15. In paragraph 14, The above user information inclusion step is: A step in which the user information includes the user's identification information; and A step of encrypting the user information with a secret key of the user terminal; A method for providing ticket messages related to an event.

16. In paragraph 14, The above ticket message identification step is: A step in which the ticket information includes at least one of issuance information, seat information, and delivery information of the ticket; and A step in which the event information further includes at least one of the date and time information of the event and the location information of the event; A method for providing ticket messages related to an event.

17. In any one of paragraphs 13 to 16, A step of encrypting at least one of the user information, the ticket information, the discount voucher information, and the event information with a ticket secret key; A method for providing ticket messages related to an event.

Images