KR20030060465A - Digital cyber-lottery transmitting data format - Google Patents

Abstract

PURPOSE: A data format for transmitting a digital electronic lotto is provided to improve reliability for a digital lotto service through the Internet with high reliability by using an exclusive transmission data format and a protocol between servers. CONSTITUTION: The data format includes a tag field region discriminating an application program according to a fixed header text string, a value field region including the actual data operated by the application program discriminated by the tag field region, and a length field region expressing a total size of the value field region. The total length of the transmission data format is arranged by the multiple numbers of 4bytes.

Description

Digital electronic lottery transmission data format

The present invention relates to a transmission data format, and more particularly, to a digital electronic lottery transmission data format capable of providing higher reliability to a digital electronic lottery service through a communication network such as the Internet.

In general, the game system of the lottery is largely a lottery lottery game and an instant lottery game.

More specifically, the lottery lottery game is a number system that pays the lottery winnings when the lottery number specified in the lottery ticket is won through a lottery that is executed on a certain day when the buyer purchases a lottery ticket with the lottery number specified in advance. When a buyer selects a desired lottery number at the time of purchase, there is a lottery method that pays the lottery winnings when the number selected by the buyer is won through a lottery.

In order to operate the lottery lottery game method, a fair lottery method should be provided.

In the next instant lottery game, a random method of randomly drawing a prize immediately after purchase, a pool method of randomly drawing a winner with a predetermined number of winners, and a predetermined number of lottery tickets in advance There is a scratch method that stores the ticketed tickets electronically in a database and sells them sequentially when requested by a buyer.

Among the instant lottery game methods, the random method and the full method can be operated only on-line, whereas the scratch method can be operated more efficiently off-line. Such instant lottery games determine whether the user wins through a real-time lottery when purchasing a lottery ticket, and it is difficult for a large amount of winners to come out because it is difficult to operate in a structure that carries forward the winnings. In particular, since it is easy to operate online, it is widely applied to electronic lottery services through communication networks such as the Internet.

In the past, the game systems of various lotteries listed above were serviced based on a network (Internet, online or wireless communication network).

However, because many existing lottery game services have a lot of problems with security and reliability, they are applying encryption technology, digital signature, and related security standards to protect information on the network. However, several game services on the network must meet the following security requirements in order to operate safely online.

First, counterfeiting and duplication must be prevented. In other words, the buyer should not be able to receive the winnings in duplicate by duplicating the winning lottery ticket. Or they should not allow third parties to intercept or duplicate another person's lottery ticket.

Second, the contents (lottery information: data) of the lottery ticketed should be unpredictable. In this regard, the server side administrator who provides the lottery service should be unpredictable.

Third, after the lottery buyer purchases the lottery ticket, the issuer must not deny the sale of the lottery ticket. Conversely, a lottery buyer should not be able to deny the purchase of the lottery ticket after purchasing it.

Fourth, the random number generating module used in the lottery ticketing should be equipped with a proven pure random number generator that can generate unpredictable random numbers on both the buyer side and the server administrator side. This is especially true for running instant lottery game services.

Fifth, more thorough system security and information security are required. System security is to prevent illegal users from entering the system through the operating system and application programs of the computer system and security holes, and to use the computer system illegally. Information security is the information contained within the computer system. = data) to prevent information from being illegally intercepted or retransmitted after secretly correcting information that is being transmitted over the network, thereby delivering information more safely and reliably. Therefore, all unencrypted information conventionally transmitted over a network (Internet, online or wireless communication) is likely to be eavesdropped by a hacker who is an illegal user, or an external hacker can In the sense that there is a possibility to be deceived as if approached, the system hacker should not be able to control the service system and information at will. Of course, the administrator who operates the service system should not be able to control the service system and information arbitrarily.

Sixth, key management and security are required so that a key used for encryption and digital signature of lottery information is not exposed.

However, there is a problem that there are always various illegal items corresponding to the above security requirements.

As a result, the digital electronic lottery game service, which is gradually expanding its application, is required to have more reliable reliability of ticketing, release, and drawing through the digital electronic lottery network.

In particular, there is a need for a total operation solution of digital electronic lottery, which can provide more reliable reliability for ticketing, release and lottery of digital electronic lottery that can be serviced through internet, online or wireless communication network.

SUMMARY OF THE INVENTION An object of the present invention has been made in view of the above points, and in particular, a dedicated transmission data format and a protocol between servers are securely implemented to enable various lottery games that have been serviced off-line to be performed safely on-line. The present invention provides a digital electronic lottery transmission data format that provides higher reliability to digital electronic lottery services through a communication network such as the Internet.

According to an aspect of the present invention for achieving the above object, it includes a tag (TAG) field area for distinguishing the application program according to the set header string, and the actual data operated by the application program distinguished by the tag field area And a length field area indicating a total size of the value field area.

Preferably the total length of the transmission data format is aligned in multiples of 4 bytes.

Preferably, the transmission data format includes a 2 byte tag field area and a 2 byte value field area, or a 4 byte tag field area and a 4 byte value field area.

Preferably, the transmission data format is composed of a 2-byte tag field area, a 2-byte length field area, and a 4-byte value field area, or a 4-byte tag field area, a 4-byte length field area, and a 4-byte value field area. It consists of.

Preferably, when the value field area is an integer, the length field area is not included in the transmission data format, and when the value field area includes a character string, the length field area is included in the transmission data format.

Preferably, the tag field region includes string data corresponding to a digital electronic lottery purchase request, and the value field region includes version information and lottery type information of the digital electronic lottery transmission data format, sales agent server information of the lottery, and User information that purchased the lottery ticket, ticketing authority information of the lottery, prize information such as prize money prize prize of the lottery, time stamp token information (optional) of the lottery buyer, game information, security information data, and the length field The area includes full length information data of the information data of the value field area.

Preferably, the tag field region includes a string corresponding to a digital electronic lottery purchase request, and the value field region includes the actual lottery buyer or hidden lottery buyer information, the digital electronic lottery sales agent server information, and a unique tracking for ticketing. Serial information, version information of the hidden lottery buyer information, user identifier information of the lottery buyer, registration identifier information of the lottery buyer, the lottery seller identifier information, purchase request time stamp value information, random seed data (optional), the sale Time string information of the proxy server, information on whether the lottery is an instant or lottery, signer authentication information, and algorithm identifier information data used for signing are included, and the total length information of the information data of the value field area is included in the length field area. Included.

Preferably, the tag field region includes a string corresponding to digital electronic lottery ticketing management, the value field region includes a ticket request, lottery confirmation, lottery inquiry request, report and lottery winner inquiry information data, and the length field region. The full length information of the information data of the value field area is included.

Preferably, the tag field area includes a string corresponding to a server management protocol, the value field area includes server control, log / report control, and scoreboard control data, and the length field area includes the value of the value field area. Full length information of server control, log / report control and scoreboard control data is included.

1 is a view for explaining the basic structure of the digital electronic lottery transmission data format according to the present invention

2 is a diagram for describing a transmission data format according to the first embodiment of the present invention.

3 is a diagram for describing a transmission data format according to a second embodiment of the present invention.

4 is a diagram for describing a transmission data format according to a third embodiment of the present invention.

5 is a diagram for describing a transmission data format according to a fourth embodiment of the present invention.

FIG. 6 is a diagram illustrating a tag range and the number of tags supported in the digital electronic lottery transmission data format of the present invention.

7 illustrates a digital electronic lottery service system to which the present invention digital electronic lottery transmission data format is applied.

Hereinafter, a digital electronic lottery transmission data format according to the present invention will be described with reference to the accompanying drawings.

1 is a view for explaining a digital electronic lottery transmission data format according to the present invention.

First, the transmission data format according to the present invention is referred to as softforum tag length value (STLV) format.

The STLV is a data encoding method using a tag, a length, and a value as one data unit as needed. The STLV packet is shown in FIG. As shown, the TAG field includes a TAG field, a length field (optional), and a value in value field that is extended as defined in the length field.

That is, the size of the value field can be extended as defined in the length field. In addition, the value of the value field can include not only data types such as integers and strings, but also other STLV data, which are understood when exchanging data between different applications. If a TAG field is included that cannot be understood (e.g. different versions or need not be understood in order to prevent a drop in transmission speed), the corresponding STLV is ignored and the next STLV data is processed. This makes the program's error handling much more flexible.

Here, STLV has the following characteristics.

The first format is aligned with 4 bytes.

That is, in order to avoid high speed processing and bus error during data encoding / decoding, the length of one STLV data is a multiple of 4 bytes. If the value field is a string or binary data and is not a multiple of exactly 4 bytes, the value field is also padded to 4 bytes.

The second supports a data format without a length field.

That is, in the case of integral value, the length field is omitted to reduce the amount of data transmission.

The STLV transmission data format structure according to the present invention has one of four structures as shown in FIGS.

2 is a transmission data format structure according to the first embodiment of the present invention, FIG. 3 is a transmission data format structure according to the second embodiment of the present invention, and FIG. 4 is a transmission data format structure according to the third embodiment of the present invention. 5 is a transmission data format structure according to the third embodiment of the present invention.

2 and 4 are 2-byte integral data and 4-byte integral data format structures, respectively. FIGS. 3 and 5 are short strings and long strings, respectively. Data format structure for transmitting data including (Long string). In this case, since the length of the character string data included in the value field of FIGS. 3 and 5 is variable, the length field includes information about the length of the value field. However, the 2-byte and 4-byte integer data formats shown in Figs. 2 and 4 do not require a length field. And the value of tag's T0 should be other than 0x00.

Hereinafter, the transmission data format of FIG. 2 is referred to as INT2 (2-byte integral data), the transmission data format of FIG. 4 is referred to as INT4 (4-byte integral data), and the transmission data format of FIG. 3 is referred to as STR (short STRing). This transmission data format of FIG. 5 is called LSTR (Long STRing).

The format encoding of the STLV of the present invention having such four format structures defines only a range of a tag according to an encoding method, and the meaning of a specific tag is required by an application programmer. Accordingly used as defined in the following examples.

If such STLV data is transmitted, the meaning of the data may be interpreted differently depending on the application program receiving the STLV data. Therefore, a specific header string is inserted into the first 4 bytes of the STLV stream. Separate

The tag TAG range and the number of tags supported in the STLV format of the present invention are shown in FIG. 6.

The value field provided by the STLV module according to the present invention can be largely classified into a string type and a 4-byte binary type (ie, integer data) type, and the string type is a value ( The middle of the value field does not contain a null (0x00) character and the last byte ends with 0x00.

The binary type includes a null (0x00) character in the middle of the value field and does not end with 0x00 in the last byte.

7 is a diagram illustrating a digital electronic lottery service system to which the present invention digital electronic lottery transmission data format is applied.

7, the digital electronic lottery game operating system of the present invention, a lottery server (lotto server) 30, a sales proxy server (sales proxy server) 20, a client computer (client PC) 10 And a log / report server 40. Here, the sales agent server 20 is illustrated as being separately implemented, but the sales agent server 20 may be implemented in a structure that is included in the lottery server 30.

The lottery server 30 performs a lottery generation and verification service according to a user's request, and must be installed in a physically isolated place, and the protocol (SFLP: SoftForum) for the lottery game service of the present invention with an external (particularly a sales agent server). Only with Lotto Protocol).

The log / report server 40 is installed outside the lottery server 30, and the log data (for example, the total number of winnings and the total winnings) and the report required by the administrator are reported. Record it.

Sales proxy server (sales proxy server) 20 is a server that provides the user registration and game services, the lottery data (Lotto Server) request a lottery ticket to the lottery server (Lotto Server) 30 when the user's request (Lotto Data) is used to provide a lottery game.

The client PC 10 includes an encryption module (XecureProxy) for data encryption and a signature tool (XecureSignTool) for electronic signature of data therein. The encryption module (XecureProxy) encrypts the data transmitted and received in the interval on the Internet, the signature tool (XecureSignTool) performs a digital lottery ticket request using the digital signature and the signed data. Such an encryption module and signature tool are provided from the sales representative server 20 to the client computer 10.

The operation procedure of the digital electronic lottery service system will be described.

The first step is a request for purchasing a lottery ticket by the client PC 10. In the first step, the user logs on to a sales proxy server 20. The user then generates a lottery purchase request message using a signature tool (XecureSignTool) provided inside the client PC 10.

Thereafter, the generated lottery purchase request message is transmitted to the sales proxy server 20 in an encrypted state through an encryption module (XecureProxy) provided in the client computer 10.

The second step is a lottery ticketing step by the lottery server 30. In a second step, a sales proxy server 20 transmits a lotto request LR to the lottery server 30. At this time, the lottery server 30 generates lottery data using the lottery purchase request message LR.

At the same time, the sales proxy server 20 performs payment for the lottery purchase amount if there is no error after verifying the user signature of the lottery data LD.

The next third step is a lottery game service step by a sales proxy server 20, and the sales proxy server 20 uses a blind identifier (BID) information to play a game. Create and provide the created game to the user. Here, in the case of the instant lottery game service, the game ends immediately, and when the user wins, payment is made as much as the winning amount.

The fourth step is a lottery check step only for the lottery game. After the lottery is over in this stage and the winner is confirmed, the determined winning information is updated in the lottery server 30. Here, when the lottery server 30 can know the identity of the buyer, the winning information is delivered to the winning user, and the sales agency server 20 performs the settlement of the winnings. Of course, the winning information is selectively delivered to the failed user, and the winning information is delivered through a short message service using an e-mail or a wireless communication network.

On the other hand, in the case where the identity of the buyer is not known in the fourth step, the user inquires whether or not to win the sales proxy server 20 using his social security number. Accordingly, the sales proxy server 20 transmits the lottery data of the individual unique identifier such as the purchaser's social security number and the user to the lottery server 30, and inquires whether or not the prize is won.

After that, the lottery server 30 transmits the identity of the buyer and whether the buyer wins the sales proxy server 20.

The following describes the lottery game service dedicated protocol (SFLP) of the present invention.

In the present invention, a dedicated protocol for the lottery game service is used. The dedicated protocol is a protocol for communication between the lottery server 30 and the external sales agent server 20, and has the following features.

First, the lottery game service dedicated protocol (SFLP) of the present invention is short in the length of a data packet and has excellent scalability in encoding / decoding.

Second, by using the lottery game service dedicated protocol (SFLP), in developing the sales agency server 20, a simpler development environment is provided. In addition, since it can be easily interlocked with a plurality of sales agency server 20, it is excellent in scalability.

Third, the lottery game service dedicated protocol (SFLP) provides a service function for lottery sales. In other words, it performs the sales function such as ticketing and verification of the lottery.

Fourth, the lottery game service dedicated protocol (SFLP) provides a management function for management of the lottery server 30 such as start / stop of the lottery server 30, recharging the lottery ticket, and the like.

The message specification of the lottery game service dedicated protocol (SFLP) having the above characteristics is defined as messages by a service protocol and messages by an administration protocol.

First of all, the messages by the service protocol include a lotto request message for lottery release, a lotto verifying message for the purchaser's identity confirmation, and a lottery inquiry request message used for inquiring lottery details by lottery number. lotto query), and messages by the Administration Protocol include server startup messages for server startup, server shutdown messages for server startup, and server shutdown messages for lottery charging and exhaustion. A server reload message, a server reporting message for writing a report to the log / report server 40, is defined.

The following describes the B-type digital lottery game service that determines the winner and the winning prize through the drawing after the lottery ticket of the lottery number selected by the buyer is sold.

In the digital electronic lottery game service of type B according to the present invention, a user selects a desired lottery number, electronically signs the selected lottery number, and requests a ticket from the server.

Thereafter, the lottery server 30 generates lottery data based on the ticketing request and delivers the lottery data to the user.

If the draw date comes after a certain time, the winner is decided by drawing.

Next, the user requests the server side to verify whether or not the lottery number is won, and through the verification process, the user pays the winnings.

In particular, when the lottery is made through on-line in the present invention, the lottery game service is guaranteed by performing a lottery using a pure random generator, thereby ensuring fairness of the lottery game service.

A feature of the system for digital electronic lottery game service of type B is that a server for lottery sale is operated based on a dedicated protocol for lottery game service.

In addition, it provides a dedicated protocol (SFLP) for lottery sales and server management, and provides a web-based management environment by providing a computer graphic interface (CGI) type management menu using the dedicated protocol (SFLP). do.

In addition, when the service program is activated, the user is authenticated using a smart card. The server starts up directly by inserting a smart card.

The lottery server of the present invention is activated in a standby mode (standby mode) and performs authentication with an integrated circuit (IC) card from a personal computer (PC) through a service dedicated protocol (SFLP).

The type B lottery game service of the present invention is provided to the purchaser after issuing a ticket based on the electronic signature of the user when the lottery ticketing request is made. When verification of the lottery data is required, the verification is performed and the verification result is provided. Finally, the lottery data is input to provide a search result of the winner information.

Using the transmission data format according to the first and fourth embodiments of the present invention, 1. transmission data format of digital electronic lottery, 2. transmission data format for digital lottery purchase, 3. digital electronic lottery management The transmission data format for transmission, the transmission data format for server management, and the transmission data format for confirmation of lottery winnings will be described.

1. An embodiment of the transmission data format of the digital electronic lottery will be described.

The first data format sequence is a general wrapper and includes a tag indicating that it is a digital lottery and lottery data.

Here, the digital lottery data format is represented by, for example, 0x05464C44 in a long character string (hereinafter referred to as LSTR (Long STRing)) included in a tag range (see FIG. 7). In this case, the tag is a symbolic value in which a bit pattern except for the most significant bit (MSB) becomes an ASCII (American Standard Code for Information Interchange) value and becomes a softforum lotto data (SFLD). In the following, the LSTR indicating the digital electronic lottery data format, the digital electronic lottery purchase data format, the digital electronic lottery ticketing management data format, the server management data format, and the lottery winning confirmation data format is a bit except the most significant bit (MSB). Bit pattern indicates that it is SFLD as an American Standard Code for Information Interchange (ASCII) value.

The second data format sequence is lottery data information data including version information of the lottery data format and the lottery type.

That is, version information is the first thing to be informed when the lottery data is transmitted according to the data transmission format according to the present invention. After checking the version information, proceed to the next operation according to the version.

The lottery types can be divided according to various lottery game types.

For example, A type (TypeA) = number type, B type (TypeB) = lottery type, R type (TypeR) = random number type, P type (TypeP) = full type, S type (TypeS) = scratch type Form A determines the winner and the prize by lottery after the lottery ticket of the lottery number specified in advance is sold.Type B determines the winner and the prize by the lottery after the lottery ticket of the buyer has selected. In the case of the user, when the user purchases a lottery ticket, the R-type determines probability of winning and winning the prize. In the P-type, the manager of the lottery server decides the number of winners of each ranking in advance. In order to determine the winning order, the S-type generates a certain amount of lottery tickets in advance, encrypts and stores them, and when a user requests to purchase a lottery ticket, decrypts the stored lottery tickets and decides whether or not to win the prize.

At this time, the version information is included in 2-byte integer data (that is, INT2), and the value of STLV adds a value in '()'. That is, when the version information is INT2 (100), the version information is included in INT2, and the value of STLV becomes 0x8100, which is 100, 0x8000 which is the basic value of the tag range as shown in FIG.

In the case of a type A (Type A), the lottery type is INT2 (110), and a type B (20), a type R (30), a type S (40), and a type P (50).

The third data format sequence is generated by the need of a proxy information server. The third data format sequence is information that is not related to ticketing and security. At the time of lottery purchase, the sales agent server information (Proxy Info) included in the lottery data is generated. ) Data.

Here, the sales agent server identifier (Proxy ID) is included in the STR 210, and if necessary, a unique track for request ticketing (Request track serial) is included in the INT4 (211).

The fourth data format sequence is GID information data, which is user information that reveals actual user information (e.g., a social security number) among lotto users.

Here, the actual user information (User IDN) is included in the STR 310, and the buyer (or user) identifier (User ID), which is a unique identifier registered in the reseller account, is included in the STR 311.

The seller identifier Reseller ID, which is a unique identifier of the seller site, is included in the STR 312.

The signature used in the purchase request of the buyer is included in the STR 390.

In the fifth data format sequence, a BID (User BID), which is a blind user identifier, of a Lotto request user, includes a value hashed by User IDN, UserID, and ResellerID in the STR 313.

The hidden user signature (Buyer Signature) is included in the STR 392 as the signature used at the buyer's request.

The sixth data format sequence is ticketing agency information data representing a seller information.

For example:

Ticket Authority ID: STR (400).

Lottery ID: STR 401.

Lottery order: INT4 (402).

Lottery serial: INT4 (403).

Draw date: INT4 (404) (time_t value).

Expiry date: INT4 (405) (time_t value).

Consecutive Purchases: INT4 (410) (Total Purchases when Consecutive Purchases).

Serial number: INT4 (411) (starting with serial number 1 if purchased continuously).

The seventh data format sequence is Prize Info data such as ranking, prize money, points or prizes.

For example:

Elevation: INT4 420.

Prize: INT4 (421).

Point: INT4 (422).

Item # 1: STR 430.

Item # 2: STR 431.

The eighth data format sequence is included in the STR 440 as Time Stamp Token (optional) Information (Info.) Data proving the time signed by the user.

The ninth data format sequence is Game Info data.

For example, as game specific data having a value of 500 to 699, data for generating a game is stored in the case of TypeR, TypeS, and TypeP, and data such as a number selected by the user is stored in the case of TypeB.

That is, scratch game data, which is a structure of a game for generating a scratch game, is included in the STR 500.

In addition, Match Game Data (STR 501), Maze Game Data (STR 502), Bingo Game Data (STR 503), 6/49 Lottery Game Data ( STR 520) (the number of balls selected by the buyer is stored as a character type, for example, characters from 0 to 255 come in succession).

The number of balls selected by the purchaser in the user's selection for the 6/49 Powerball lottery game is stored in character type (strings of 0-255 are consecutive) STR 521. At this time, internally, the first string is regarded as a power ball.

The tenth data format sequence is Security Info data.

The security information data is included in the STR 900 in the BIN format of the lottery ticket authority certificate, and the algorithm identifier (Sign Algorithm ID) used for signing is included in the INT2 901, and the signer certificate ( The BIN format of the OCSP token of the Signer Cert is included in the STR 902 (optional), and the signature value of the entire first to ninth lottery data is included in the STR 910.

2. The transmission data format for the digital electronic lottery purchase will be described.

The transmission data format for the digital electronic lottery purchase is applicable to the first and third stage services of the digital lottery service system described above, and the transmission data requested from the client computer 10 to the sales representative server 20. Is the format of.

First, when requesting a digital electronic lottery purchase request, the user request data includes a real user identifier (GID) data request format required by a real user and a BID data request format required by a blind user.

In other words, when purchasing a lottery, a user generates a data called GID (Genuine ID) and presents it to a sales representative server (), which is in principle authenticated with a social security number and his certificate. However, buyers who do not want to reveal their identity at the time of purchase should purchase using a hidden ID (BID) instead of GID. In the case of using such a hidden ID (BID), the user must go through the user verification (Verify) process to verify the hidden ID when the prize money is paid.

The lotto request includes a client lotto request (CLR) generated by a user and a proxy lotto request (PLR) generated by a sales proxy server. Typically, when a user creates a CLR and sends it to a sales proxy, the sales proxy verifies the CLR and replaces the certificate and signature with the sales proxy's certificate and signature. It is made of PLR and delivered to Lotto Server. At this time, the sales proxy server stores a pair of CLR-PLR in case of a future problem.

An embodiment of a digital electronic lottery purchase request data format will be described.

First, the actual identifier (GID) data request format is as follows.

The first general wrapper includes a tag indicating a GID data request format that reveals actual user information among lottery purchase request users, and a length field and a value field which are detailed information of the lottery purchase request data.

Herein, the digital electronic lottery purchase request data format is represented as 0x05464C52 in the LSTR included in the tag range.

The second data format sequence is a proxy server identifier (Proxy ID) data.

This information includes the sales agent server identifier (Sales Proxy ID) generated by the need of the sales proxy server (Sales Proxy) requested to purchase the digital electronic lottery ticket, and is not related to ticketing and security. . In some implementations, this information may be included only in the lottery request LR and not in the lottery data LD.

The third data format sequence contains unique request track serial data for ticketing tracking.

This information is also generated by the needs of the Sales Proxy and is not related to ticketing and security and is included in INT4 211, which, depending on the implementation, is only included in the lottery request (LR) and the lottery. It may not be included in the data LD.

The fourth data format sequence is included in the INT2 300 as version info data of the GID format.

The fifth data format sequence is user IDN data, for example, using a social security number, and included in the STR 310.

The sixth data format sequence is registered user identifier (User ID) data. For example, the sixth data format sequence is included in the STR 311 as unique ID data registered in a sales representative server account.

The seventh data format sequence is included in the STR 312 as Reseller ID data.

The eighth data format sequence is included in the STR 320 as Time Stamp Value (optional) data.

The ninth data format sequence is included in the STR 321 as random seed (optional) data.

The tenth data format sequence is included in the INT4 322 as an optional (Time) data of the proxy server.

The eleventh data format sequence is data indicating whether it is an instant or a lottery, and is included in the INT2 330 in the case of an instant, and this field is omitted in the case of a lottery. In the case of a raffle, it is included in INT2 340, and this field is omitted in the case of an instant meal. At this time, in the lottery ceremony, the following Ball selection field comes by a given number.

That is, the twelfth data format sequence is included in the STR 341 in the case of a lottery, when the 6/49 lottery game is selected, and the number of balls selected by the buyer is stored as a character type.

The thirteenth data format sequence is included in the STR 342 when a 6/49 Powerball game is selected and the number of balls is stored in character type.

The fourteenth data format sequence is Sign Cert data that contains the BIN format of the buyer (or seller) certificate in the STR 390.

The fifteenth data format sequence is included in INT2 391 as the Signal Algorithm ID data used for signing.

The sixteenth data format sequence is included in the STR 392 as signature value data of the entire GID data up until the Signer Cert data.

The following hidden identifier data request format is as follows.

The BID Data Request format, which reveals hidden user information among digital e-lottery purchase request users, is registered with the fifth, sixth and seventh data format sequences (User IDN) of the data sequence of the GID data request format. User ID and Reseller ID items are deleted, and the following two data fields are added.

Firstly, the Hidden User Identifier (User BID) data is stored in the STR 313, the Hidden User Identifier (User IDN), the Unique ID (USER ID) registered in the Seller (Reseller Account), and the Seller Identifier (Reseller ID). ) Is stored in the STR 313.

Secondly, the algorithm data used in the BID hash is included in the INT2 314.

3. The transmission data format for digital electronic lottery ticket management will be described.

The transmission data format for ticketing management corresponds to the second and fourth stages of the service operation of the digital electronic lottery service system described above.

The digital electronic lottery data format includes an electronic lottery service protocol developed in-house during ticketing management as a set, and the ticket management data format is largely divided into (1) ticketing request and (2) lottery. , (3) lottery query request, (4) Report, and (5) Lottery Winner Query.

(1) The data format sequence at the time of ticketing request may be divided into a request format, a request response format, and an internal process format.

The first data format sequence is a general wrapper of the request format and indicates, for example, 0x05464C50 in the LSTR included in the tag range that it is a ticketing management request data format for lottery.

The version information of the SFLP is included in the INT2 (1000) as the data format sequence, 'REQUEST' is included in the INT2 (1100) as the data format sequence as a command for requesting lottery ticketing, and the request defined in the buyer's request. Lotto Request (SFLR), which is data, is included in the LSTR as, for example, 0x05464C52.

The second data format sequence is a general wrapper of the ticketing request response format and indicates that the ticketing request response data format is, for example, 0x05464C50 in the LSTR included in the tag range.

The response value for the administration protocol is included in the INT4 1010 as a return code, the lottery count indicating the number of lottery tickets issued is included in the INT2 1020, and the lottery data defined in the lottery data is included. A sequence of SFLD (Lotto Data) indicated is represented by 0x05464C53 in the LSTR.

And the return code can be set as follows.

0: Normal success.

100: Syntax error.

200: Signature validation error.

300: Lottery Pool Empty.

310: Request Timeout.

800: Server operation unavailable (Internal Error).

The third data format sequence is an internal process data format when requesting a ticket, including protocol parsing, lottery ticketing request data and lottery data storage data (save (SFLR, LD) pair) and lottery data (LD). ) Return data is included.

(2) When checking lottery, the data format sequence can also be divided into request format, request response format, and internal process format.

The first data format sequence is a general wrapper of the request format, indicating that it is a Verify request data format in the LSTR included in the tag range, for example, 0x05464C50.

The version information of the SFLP format is included in the INT2 (1000) as a data format sequence, and 'VERIFY' is included in the INT2 (1110) as a data format sequence as a command for requesting lottery confirmation, and the request data and the user identifier as parameters. (User IDN: STR 310), Registration Identifier (User ID: STR (311)) Seller Identifier (Reseller ID: STR (312)), Ticketing Authority Identifier (ID: STR (400)) Lottery Identifier (STR (401) )) There is a lottery order (INT4 (402)) and a lottery number (INT4 (403)). Regardless of the value, echo data sent by attaching the lottery data LD to the ticketing confirmation response (REPLY) data described below is included in, for example, the INT2 1111.

The second data format sequence is a response data format for the ticketing confirmation request, and is indicated by 0x05464C50 in the LSTR included in the tag range that the ticketing confirmation response data is a general wrapper of the response data format.

The response value for the administration protocol is included in the INT4 1010 as a return code, and the sequence of SFLD representing the lottery data defined in the data and the lottery data is included in the LSTR as 0x05464C44.

The return code can be set as follows:

Data: Reply value for Admin Protocol.

100: Syntax error.

400: Lotto serial not valid.

500: Lottery cannot be confirmed (BID not matches).

800: Server operation unavailable (Internal Error).

The third data format sequence is an internal process data format at the time of ticketing request.

The internal process data format may include protocol parsing data, matched lotto number and verify BID data, and return data of results and lottery data.

(3) The data format sequence can also be divided into request format, request response, and internal process.

First, the data format sequence is a general wrapper of the lottery inquiry request format and indicates that the lottery inquiry request is, for example, 0x05464C50 in the LSTR included in the tag range.

The version information of the SFLP format is included in the INT2 (1000) as the data format sequence, and the command for requesting the lottery is included in the query (QUERY) in the INT2 (1120) as the data format sequence, and includes various parameter information. do.

Such various parameter information includes a ticketing authority ID (STR (400)), a lottery ID (STR (401)), a lottery order (INT4 (402)) and a lottery number (serial: INT4 (403)). There is a server identifier (Sales Proxy ID: STR 210) and a request track serial (INT4 211), which is a serial number for ticketing tracking if necessary.

The second data format sequence is a response format for the first request format, and is represented as 0x05464C50 in the LSTR included in the tag range that the lottery inquiry response data format is a general wrapper.

The return code is included in the response value INT4 1010 for the Admin Protocol. For example, if the return code is 0, normal success is succeeded, if it is 100, the syntax error is used, if it is 400, the lotto serial not valid, and if it is 800, the server It responds with an internal error. Finally, the sequence of SFLD representing the lottery data defined in the lottery data is represented by 0x05464C53 in the LSTR.

The third data format sequence includes protocol parsing, lottery number matching, and result and lottery number return data in an internal proto-data format upon inquiry request.

(4) The data format sequence at the time of report can be divided into request format, response and internal process.

The first data format sequence is the general wrapper for the request format, indicating that it is a report data format, for example, 0x05464C50 in the LSTR included in the tag range.

Version information of the SFLP is included in the INT2 1000 as a data format sequence, and 'REPORT' is included in the INT2 1130 as a data format sequence as a command for requesting a report.

Subsequently, parameter information is included, the lottery order is included in INT2 2401, and a ticketing turn may be included (optional). At this time, if there is no parameter, information on the currently issued round is output.

The second data format sequence is the general wrapper of the response format, and the LSTR included in the tag range is represented, for example, 0x05464C50.

The response value for the Admin protocol is included in the INT4 1010 as a return code.

For example, the return code can be set to 0 for success, 100 for syntax error, 410 for round round not valid, and 800 for server internal error. do.

The length field or value field of the other response format includes data for various prize structures.

In other words, the overall prize structure,

INT2 (2401): Ticketing rounds.

INT2 (2402): Number of total ranks.

INT4 (2403): Total number of tickets issued.

INT4 2405: Lottery expiration time (time_t value).

INT4 (2409): Total sales.

1st prize structure,

INT4 (2410): First prize amount.

INT4 (2411): Number of winning lottery tickets.

INT4 (2414): Number of consecutive first place.

Second prize money structure,

INT4 (2420): Second prize money.

INT4 (2421): Number of winning lotteries.

Third prize prize structure,

INT4 (2430): Third prize amount.

INT4 (2431): Number of winning lottery tickets.

Fourth prize structure,

INT4 (2440): 4th prize money.

INT4 (2441): Number of winning lottery tickets.

The fifth prize prize structure,

INT4 (2450): 5th Prize.

INT4 (2451): Number of winning lottery tickets.

The sixth prize structure,

INT4 (2460): 6th Prize.

INT4 (2461): Number of winning lottery tickets.

The seventh prize structure,

STR (2470): 7th class name.

INT4 (2471): Number of winning lottery tickets.

The eighth prize prize structure,

STR (2480): 8th class name.

INT4 (2481): Number of winning lottery tickets.

9th prize structure,

STR (2490): 9th class name.

INT4 (2491): 9th place winning lottery.

10th prize structure,

STR (2600): 10 points.

INT4 (2601): Number of winning 10 lottery points.

The 11th prize structure,

STR (2610): 11 points.

INT4 (2611): Number of points winning 11 lotteries.

The 12th prize structure,

STR (2620): 12 points.

INT4 (2621): It can consist of 12 winning points.

The third data format sequence is an internal process data format for reporting, including protocol parsing, collect report information, and return result data.

(5) During the lottery winner query, the data format sequence can also be divided into request format, request response, and internal process.

The first data format sequence is a general wrapper of the winner inquiry request format and indicates that the winner inquiry request data format is, for example, 0x05464C50 in the LSTR included in the tag range.

The version information of the SFLP is included in the INT2 1000 as a data format sequence. For example, 'LOTTOBQUERY' is included in the INT2 1140 as a command for requesting a winner inquiry of a type B digital lottery.

Subsequently, parameter information is included, which includes information on the lottery order INT2 2401 and the ticketing turn (optional), where information on the last lottery is drawn if this parameter is not present.

The second data format sequence is the general wrapper of the response format, and the LSTR included in the tag range is represented, for example, 0x05464C50.

The response value for the management protocol is included in the INT4 1010 as a return code.

For example, a return code of 0 may be set to 100 for successful execution, 100 for a syntax error, 410 for a round round not valid, and 800 for a server internal error.

In addition, data for various prize structures is included in the response format.

In other words, the overall prize structure.

INT2 (2401): Ticketing rounds.

INT2 (2402): Number of total ranks.

INT4 (2403): Total number of tickets issued.

INT4 2405: Lottery expiration time (time_t value).

INT4 (2409): Total sales.

And other winning information includes:

The INT4 2610 contains the number data of first prize winners, and the LSTR 2611 includes LD data of the first prize winners (the number of LDs is repeated by the number of winners).

For example, the INT2 2620 contains the number data of the second prize winner, and the LSTR 2621 contains the LD data of the second prize winner (the number of LDs is repeated by the number of winners).

As another example, the INT4 2630 includes the number data of the third prize winner, and the LSTR 2631 includes LD data of the third prize winner (the number of LDs is repeated by the number of winners).

The third data format sequence is an internal process data format and includes protocol parsing, collect report information, and return result data.

4. The transmission data format for server management will be described.

The transmission data format for server management is a data format between the lottery server 30 and the log / report server 40.

An embodiment of a server management protocol data format such as ticketing and sales of a digital electronic lottery will be described.

In this server management (SFLP Admin) protocol data format, a protocol developed by itself is also provided as ?? (SET), and the server management protocol includes (1) server control, (2) log / report control, and (3) scoreboard. There is control.

Unlike the Service Protocol, which was provided as an SFLP pair for ticketing management, the server management protocol must be signed with the challenge seed presented by the server each time a command is executed. have. According to such a signature, a replay attack can be prevented in advance.

(1) The data format sequence for server control can be divided into server challenge, client command and server response.

The server control command is a basic command for starting, stopping, terminating, and reloading the lottery. Each command checks the validity of the command with an administrator's signature without additional parameters.

In the first data format sequence, the server challenge is included in INT4 (2980), and when a server is connected to prevent a replay atttack, the server generates a random number.

The second data format sequence is a general wrapper for the client instruction format, which is represented as 0x05464C50 in the LSTR included in the tag range.

Version information of the SFLP format is included in the INT2 1000.

The command comes with one of the following commands.

For example, start (START: INT2 (2100)) is a server start command, stop (STOP: INT2 (2110)) is a server stop command, and shutdown (SHUTDOWN: INT2 (2120)) is a server complete shutdown (server). program exit), flush (FLUSH: INT2 (2200)) clears all lottery tickets in the pool, and reload (RELOAD: INT2 (2210)) fills the lottery pools according to the rules. , AUTOLOAD (INT2 (2220)) is an automatic reload (RELOAD) command when the lottery runs out, and NOAUTOLOAD: INT2 (2230) is an automatic reload release command.

The random number received by the challenge is included in the INT4 (2980), the BIN format of the administrator certificate related to the Signer Cert is included in the STR (2990), and the algorithm identifier (ID) used for signing is INT2 ( 2991, and the entire signature value of the GID data is included in the STR 2992 until the signer authentication.

The third data format sequence is a general wrapper of the server response format and is represented by, for example, 0x05464C50 in the LSTR included in the tag range.

As a return code, a response value for the management protocol is included in INT4 (2010).

Such a return code is, for example, 0 for successful execution, 100 for syntax error, 110 for parameter error, 200 for signature invalid, and 800 for server operation. The return code can be set to Internal Error.

(2) The data format sequence for Log / Report Control can also be divided into Server Challenges, Client Commands, and Server Responses.

The log / report control command is an administrative command that logs the status of the server as a log or controls the log level. Each command checks the validity of the command with an administrator's signature.

The first data format sequence is included in the server challenge INT4 2980, and generates random numbers when the server is connected to prevent a replay attack.

The second data format sequence is a general wrapper for the client instruction format, which is represented as 0x05464C50 in the LSTR included in the tag range.

Version information of the SFLP format is included in the INT2 1000.

And Command is one of the following commands.

REPORT: INT2 (2300) (Record current server's status in Log Server).

LOGLEVEL: INT2 (2310) (Set the level of logs to be automatically recorded on the log server).

In this case, the parameter for REPORT is recorded in INT2 2301. If this value is 1, the information for recording the server status is transmitted to the reply field as an echo field.

The parameter for LOGLEVEL is recorded in INT2 (2311), and is set to a log level of 0 to 9 (for example, 0 for no log and 9 for maximum log).

The random number received in the challenge is included in the INT4 2980.

The Signer Cert is included in the STR 2902, which includes the BIN format data of the administrator's certificate.

The algorithm identifier (Sign Algorithm ID) used for signing is included in INT2 2991.

The signature value of the entire GID data until the signer cert is included in the STR 2992.

The third data format sequence is the general wrapper of the server response and is represented by, for example, 0x05464C50 in the LSTR included in the tag range.

As a return code, a response value for the management protocol is included in INT4 (2010).

Such a return code is 0 for successful execution, 100 for syntax error, 110 for parameter error, 200 for signature invalid, and 410 for low round. not valid, 800 can be set to Server Internal Error.

The parameter for the report is included in the LSTR 2302, and the content recorded in the report server is transmitted as it is in the protocol.

(3) The data format sequence for Scoreboard Control can also be divided into server challenge, client command and server response.

The scoreboard command is a command for setting the number of lottery tickets, the prize structure, and the amount of the prize money. The basic command skeleton is the same as that of the SFLP Administration Protocol. Parameters following a Scoreboard command indicate the total number of copies, prizes, slot quotas, and random quotas, respectively.

If the sum of slots and slots and random allocations does not match for each ranking, or if the sum of total ticketing and purchases for each ranking does not match, a parameter error occurs.

The first data format sequence, Server Challenge, is included in INT4 (2980). When a server is connected to prevent a replay attack, the server generates a random number.

The second data format sequence is a general wrapper for the client instruction format, which is represented as 0x05464C50 in the LSTR included in the tag range.

Version information of the SFLP format is included in the INT2 1000.

Command comes with one of the following commands.

SETSCOREBOARD: INT2 (2400) (sets the number and rank and prize of the lottery).

GETSCOREBOARD: INT2 (2500) (to read the number of lotteries, ranking and prize money).

The parameter (Parameter (for SETSCOREBOARD)) for setting the scoreboard is as follows.

Global prize structure setting parameters.

INT2 (2401): Ticketing rounds.

INT2 (2402): Number of total ranks.

INT4 (2403): Total number of tickets issued.

INT4 (2404): Total number of slots.

INT4 2405: Lottery expiration time (time_t value).

1 prize structure setting parameters.

INT4 (2410): First prize amount.

INT4 (2411): Number of winning lottery tickets.

INT4 (2412): Quota quota.

INT4 (2413): Random quota.

INT4 (2414): Number of consecutive first place.

Second prize structure setup parameter.

INT4 (2420): Second prize money.

INT4 (2421): Number of winning lotteries.

INT4 (2422): Quota of slot.

INT4 (2423): Random quota.

Third prize structure setup parameter.

INT4 (2430): Third prize amount.

INT4 (2431): Number of winning lottery tickets.

INT4 (2432): Quota quota.

INT4 (2433): Random quota.

Fourth prize structure setup parameter.

INT4 (2440): 4th prize money.

INT4 (2441): Number of winning lottery tickets.

INT4 (2445): Number of winners of GLEPS Type A.

INT4 (2446): Number of winners of GLEPS Type B.

INT4 (2447): Number of winners of GLEPS Type C.

INT4 (2448): Number of winners of GLEPS Type D.

INT4 (2449): Amount of winnings in GLEPS Type E.

5th prize structure setting parameter.

INT4 (2450): 5th Prize.

INT4 (2451): Number of winning lottery tickets.

INT4 (2455): Number of winners of GLEPS Type A.

INT4 (2456): Number of winners of GLEPS Type B.

INT4 (2457): Number of winners of GLEPS Type C.

INT4 (2458): Number of winners of GLEPS Type D.

INT4 (2459): Number of winners of GLEPS Type E.

6th prize structure setting parameter.

INT4 (2460): 6th Prize.

INT4 (2461): Number of winning lottery tickets.

INT4 (2465): Number of winners of GLEPS Type A.

INT4 (2466): Number of winners of GLEPS Type B.

INT4 (2467): Number of winners of GLEPS Type C.

INT4 (2468): Number of winners of GLEPS Type D.

INT4 (2469): Number of winners of GLEPS Type E.

7th prize structure setting parameter.

STR (2470): 7th class name.

INT4 (2471): Number of winning lottery tickets.

INT4 (2472): Slot quota.

INT4 (2473): Random number quota.

8th prize structure setting parameter.

STR (2480): 8th class name.

INT4 (2481): Number of winning lottery tickets.

INT4 (2482): The quota of the slot.

INT4 (2483): Random number quota.

9th prize structure setting parameter.

STR (2490): 9th class name.

INT4 (2491): 9th place winning lottery.

INT4 (2492): Quota quota.

INT4 (2493): Random number quota.

10th prize structure setting parameter.

STR (2600): 10 points.

INT4 (2601): Number of winning 10 lottery points.

INT4 (2602): Quota quota.

INT4 (2603): Random number quota.

-11 prize structure setting parameters.

STR (2610): 11 points.

INT4 (2611): Number of points winning 11 lotteries.

INT4 (2612): Quota quota.

INT4 (2613): Random number quota.

12th prize structure setting parameter.

STR (2620): 12 points.

INT4 (2621): Number of winning lottery tickets for 12th place.

INT4 (2622): Quota quota.

INT4 (2623): Random number quota.

In addition, the parameter for obtaining the score board (Parameter (for GETSCOREBOARD)) is included in the INT2 2401, and the lottery round data is included.

The random number value received from the challenge is included in INT4 2980.

The BIN format of the administrator certificate associated with the Signer Cert is contained in the STR 2990, the Algorithm ID used for signing is included in the INT2 2991, and the Signer Certificate is signed. Until the Cert), the signature of the entire GID data is included in the STR 2992.

The third data format sequence is represented as 0x05464C50 in the LSTR included in the tag range as a general wrapper of the server response, and the return code, which is the response format of the management protocol, is included in INT4 (2010).

At this time, 0 is returned to normal execution success, 100 is a protocol error, 110 is a parameter error, 200 is a signature verification failure, and 800 is a server internal failure. You can set the code.

The parameter for obtaining the scoreboard (Parameter (for GETSCOREBOARD)) is the same as the parameter for obtaining the scoreboard described above (Parameter (for SETSCOREBOARD)).

5. An embodiment of the transmission data format for checking the lottery winning will be described. In this case, a parameter for checking whether or not the B-type lottery is won will be described.

The QueryBLotto command is a command for the administrator to check whether the B-type lottery is won or not. If the administrator inputs the result of drawing the lottery off-line to the lottery server, the lottery server searches the lottery information of the winner. Print out and pay the prize based on this.

In the first data format sequence, the server challenge is included in INT4 2980, and when the server is connected to prevent a replay attack, the server generates a random number.

The second sequence of data formats is the general wrapper for the client instruction format, which is represented as 0x05464C50 in the LSTR included in the tag range.

Version information of the SFLP format is included in the INT2 1000.

The command is QUERYBLOTTO (INT2 (2600)), which queries the winner of a type B lottery ticket (eg 6/49, Powerball).

Whether or not the lottery is won, the lottery ticket information is included in the INT2 (2601), the STR (2602) is the user's choice (for example, 6/49 lottery game), the buyer selected ball (ball) ) Are stored as a character type (0 to 255), followed by a sequence of characters.

The STR 2603 is, for example, a user's choice for a Powerball game, and the number of balls selected by the buyer is stored as a character type (0-255). This character comes in a series (implicitly the first character is considered a Power Ball).

The random number value received by the challenge is contained in INT4 (2980), the BIN format of the administrator certificate associated with the Signer Cert is contained in the STR 2990, and the algorithm ID used for signing is INT2 (2991). ), And the entire signature value of the GID data until the Signer Cert is included in the STR 2992.

A third data format sequence, represented as 0x05464C50 in the LSTR included in the tag range as a general wrapper of the server response format.

The response value for the management protocol is included in the INT4 (2010) as a return code.

The return code can be set as follows:

0: Normal execution success

100: Syntax error

110: parameter error

200: Signature Invalid

800: Server not working (Internal Error)

Server response parameters include the following:

INT4 2610; Number of winners.

LSTR 2611: LD of the first prize winner (the number of LDs is repeated by the number of winners).

INT4 (2620): Number of winners in second place.

LSTR 2621: LD of the second-place winner (the number of LDs is repeated by the number of winners).

INT4 (2630): Number of winners in third place

LSTR (2631): LD of 3rd prize winners (number of LDs repeated as many as winners).

The present invention described above has the following effects.

First, various lottery services that were serviced off-line can be performed on-line such as the Internet as well as maintaining high reliability by using a dedicated protocol (SFLP).

Second, in developing a server for sales by using a dedicated protocol using a transmission data format dedicated to lottery services, a simpler development environment is provided.

Those skilled in the art will appreciate that various changes and modifications can be made without departing from the spirit of the present invention.

Therefore, the technical scope of the present invention should not be limited to the contents described in the embodiments, but should be defined by the claims.

Claims (17)

A tag field area for classifying an application program according to a set header string, and a value field area including actual data operated by an application program distinguished by the tag field area, and the value field area. And optionally including a length field area representing the total size of the digital lottery ticket data format. 2. The digital electronic lottery transmission data format according to claim 1, wherein the total length of the transmission data format is arranged in multiples of 4 bytes. The transmission data format according to claim 2, wherein the transmission data format includes a 2-byte tag field region and a 2-byte value field region, or a 4-byte tag field region and a 4-byte value field region. 3. The transmission data format of claim 2, wherein the transmission data format includes a 2-byte tag field area, 2-byte length field area, and 4-byte value field area, or 4-byte tag field area, 4-byte length field area, and 4-byte multiples. A digital electronic lottery transmission data format comprising a value field area. 2. The method of claim 1, wherein the length field area is not included in the transmission data format when the value field area includes integers, and the length field area is included in the transmission data format when the value field area includes a character string. And digital electronic lottery transmission data format. The tag field region of claim 1, wherein the tag field region includes string data corresponding to a digital electronic lottery purchase request, and the value field region includes version information of the digital electronic lottery transmission data format, lottery type information, and sales representative of the lottery. Server information, user information of purchasing the lottery ticket, ticketing authority information of the lottery ticket, prize information such as prize money prize prize of the lottery ticket, time stamp token information of the lottery buyer (optional), game information, security information data, and the like. And total length information data of the information data of the value field area is included in the length field area. The tag field region of claim 1, wherein the tag field region includes a string corresponding to a digital electronic lottery purchase request, and the value field region includes the actual lottery purchaser or hidden lottery purchaser information, the digital electronic lottery sales agent server information, and ticketing tracking. Unique serial information, version information of the hidden lottery buyer information, user identifier information of the lottery buyer, registration identifier information of the lottery buyer, the lottery seller identifier information, purchase request time stamp value information, random seed data (optional) ), Time string information of the sales representative server, information that the lottery is an instant or lottery, signer authentication information, algorithm identifier information data used for signing, and the information data of the value field area in the length field area. D, characterized in that the full length information of the Digital Electronic Lottery Transfer Data Format. The tag field region of claim 1, wherein the tag field region includes a character string corresponding to digital electronic lottery ticketing management, the value field region includes a ticketing request, lottery confirmation, lottery inquiry request, report, and lottery winner inquiry information data. And the total length information of the information data of the value field area is included in the length field area. The method of claim 8, wherein the data format at the time of ticketing request, A request format including a character string corresponding to the ticketing management request data format, protocol version information of the lottery ticket, and a command for requesting the lottery ticketing ticket; A request response format including a character string corresponding to a ticketing management request response data format for the ticketing management request, a lottery count indicating a return code for the protocol and the number of lottery tickets, and a sequence of lottery data defined in the lottery data; , And an internal process format consisting of interpretation data of the protocol, lottery ticketing request data, lottery data storage data pairs, and lottery data return data. The method of claim 8, wherein the data format at the time of lottery confirmation, A request format including a character string corresponding to the lottery confirmation request data format, protocol version information of the lottery, and a command for requesting the lottery confirmation; A request response format including a character string corresponding to a ticketing confirmation request response data format for the ticketing confirmation request, a return code for the protocol, and a sequence of lottery data defined in the lottery data of the lottery; And an internal process format consisting of interpretation data of the protocol, ticketing lottery number and hidden identifier matching confirmation data, and result and return data of the lottery data. The method of claim 8, wherein the data format of the lottery inquiry request is A request format including a character string corresponding to the lottery inquiry request data format, protocol version information of the lottery, and a command for requesting the report; A request response format including a character string corresponding to a report lottery inquiry response data format for the report, a return code for the protocol, and a sequence of lottery data defined in the lottery data of the lottery; And an internal process format consisting of the interpretation data of the protocol, the lottery number matching data, and the result and return data of the lottery data. The method of claim 8, wherein the data format at the time of report, A request format including a character string corresponding to the report data format, protocol version information of the lottery ticket, a command for requesting the lottery inquiry, and a ticketing sequence; A request response format comprising a character string corresponding to a report response data format for the report request, a return code for the protocol, and a lottery prize structure sequence; And an internal process format consisting of interpretation data of the protocol, report information collection and report return result data. The method of claim 8, wherein the data format at the time of querying the lottery winner, A request format including a character string corresponding to the winner inquiry request data format, protocol version information of the lottery, the lottery order, and ticketing turn information; A request response format consisting of a character string corresponding to a data format for the lottery winner inquiry, a return code for the protocol, and a prize structure sequence of the lottery; And an internal process format consisting of interpretation data of the protocol, report information collection and report return result data. The method of claim 1, wherein a string corresponding to a server management protocol is included in the tag field area, server control, log / report control, and scoreboard control data are included in the value field area, and the value is included in the length field area. And digital data of the server control, log / report control, and scoreboard control data of the field area. 15. The method of claim 14, wherein the data format related to server control, A server channel that generates random numbers on the server to prevent replay attacks, A command for executing the server, starting, stopping, terminating, recharging the lottery, a client command including algorithm identifier data used for signer authentication, signer authentication, and Digital electronic lottery transmission data format, characterized in that consisting of server response data consisting of a return code for the server management protocol. 15. The method of claim 14, wherein the data format related to the log / report, A server channel that generates random numbers on the server to prevent replay attacks, A client command comprising the status of the current server, a log level, random numbers received by a fingerprint, algorithm identifier data used for signer authentication and signature, and Digital electronic lottery transmission data format, characterized in that consisting of server response data consisting of a return code for the server management protocol. The method of claim 14, wherein the data format associated with the scoreboard control is: A server channel that generates random numbers on the server to prevent replay attacks, A scoreboard that sets the number, rank, and prize of the lottery, and instructions related to the scoreboard that reads the number, rank, and prize of the lottery, random values received by the challenge, and algorithm identifier data used for signer authentication and signature Client commands, Digital electronic lottery transmission data format, characterized in that consisting of server response data consisting of a return code for the server management protocol.