KR102457202B1 - Service providing method based on mutual authentication using direct communication - Google Patents

Abstract

Disclosed is a method for providing a service based on mutual authentication using direct communication. The method includes a direct authentication step in which two face-to-face user-specific mobile terminals communicate directly to mutually authenticate each other, and a service provision step in which a service server provides a requested service to mutually authenticated users.

Description

Service providing method based on mutual authentication using direct communication}

The present invention relates to a technology for providing an online service to two people who directly face each other offline, and more particularly, to a technology for mutual authentication between two people and an online service providing technology based on the authentication result.

A technique for providing a service such as exchanging business cards after authenticating users who have actually met offline is known. In relation to this, Korean Patent Publication No. 10-1789803 discloses a business card information exchange service providing method. This method performed by the server is to provide the user with an experience similar to the actual business card exchange even when exchanging electronic business cards through Bluetooth search of the portable terminal. After receiving the Bluetooth address list of each other terminal, the database is searched according to the received lists. Next, the server generates a business card exchange target list to be transmitted to each of the portable terminals with the search result, and transmits it to each portable terminal. Finally, the server receives the business card exchange action request for the business card exchange target list from each portable terminal, and processes the business card exchange action request accordingly.

Domestic Patent Publication No. 10-1789803 (Announced on October 25, 2017)

An object of the present invention is to provide a method for enabling two face-to-face users to mutually authenticate each other and use a desired service simply by placing their mobile terminals close to each other.

A mutual authentication-based service providing method using direct communication according to an aspect includes a direct authentication step in which two face-to-face user-specific mobile terminals communicate directly to mutually authenticate a counterpart, and a service server providing a request service to mutually authenticated users It may include a service provision step.

In the direct authentication step, each mobile terminal may mutually authenticate through sound wave communication using a microphone and a speaker.

In the direct authentication step, each of the two mobile terminals repeatedly transmits a preamble signal as sound waves, and during each transmission pause period, it is detected whether a preamble signal is received from the other terminal, and the first terminal that receives the preamble signal first among the two mobile terminals receives the preamble signal. Instead of stopping the repeated transmission of the signal, a response signal to the reception of the preamble signal is repeatedly transmitted as sound waves, and when the second terminal, which is the counterpart terminal of the first terminal, receives the response signal during the transmission pause period, the repeated transmission of the preamble signal is stopped, A synchronization step of establishing a synchronization session between the first terminal and the second terminal by transmitting a response signal to the reception of the response signal, and a mutual authentication step of mutual authentication between the two mobile terminals through sound wave communication when the synchronization session is established. can

In the mutual authentication step, the first terminal transmits the one-time authentication token generated by the terminal user's private key to the second terminal together with the terminal user's identifier (ID), the second terminal receives the user from the first terminal Converting a string composed of an ID and an authentication token into a hash function, and transmitting the hash value obtained through the conversion to the first terminal, the hash value generated by the first terminal and the hash value received from the other terminal Comparing and responding to the second terminal whether or not the match is matched, when the second terminal receives the match response from the first terminal, the second terminal user's identifier (ID) Transmitting to the first terminal together with, the first terminal converts the string comprising the user ID and authentication token received from the second terminal into a hash function, and transmits the hash value obtained through the conversion to the second terminal and comparing whether the hash value generated by the second terminal and the hash value received from the first terminal are the same, and responding to the first terminal.

In the service provision step, authentication processing is performed according to an authentication request for whether the user of the opposite terminal is a valid user from the first terminal and the second terminal, respectively, which have completed mutual authentication, and if both are authenticated as valid users, the requested service can provide The service providing step may receive the ID and authentication token of the second terminal user received from the first terminal to authenticate the validity, and receive the ID and the authentication token of the first terminal user received from the second terminal to authenticate the validity. have.

According to the present invention, two people who actually face each other can perform mutual authentication just by touching their smartphones, and based on the mutual authentication, various services provided by the server can be used. In other words, face-to-face users can share the other party's name, contact information, profile picture or business card simply by touching their smartphone, transfer money to the other party's account, and match actual sports events with the other party. A variety of services are available.

1 is a configuration diagram of a system for providing services based on mutual authentication according to an embodiment.
2 is a flowchart of a method for providing a service based on mutual authentication according to an embodiment.
3 is a reference diagram for explaining text data transmission using sound waves.
4 is an exemplary diagram of a data frame.
5 and 6 are reference diagrams for explaining a synchronization process between mobile terminals.
7 shows an example of signal transmission/reception when synchronization between mobile terminals fails.
FIG. 8 is a diagram illustrating the process of S120 shown in FIG. 2 .
9 is a flowchart of a method for providing a service based on mutual authentication for information sharing according to an embodiment.
10 is a flowchart of a method for providing a service based on mutual authentication for account remittance according to an embodiment.
11 is a flowchart of a method for providing a service based on mutual authentication for match matching according to an embodiment.
12 is an exemplary diagram of the game score status of two players displayed on the mobile terminal.
13 is a flowchart when a service is terminated in a method of providing a service based on mutual authentication according to an embodiment.

The foregoing and further aspects of the present invention will become more apparent through preferred embodiments described with reference to the accompanying drawings. Hereinafter, the present invention will be described in detail so that those skilled in the art can easily understand and reproduce it through these examples.

1 is a configuration diagram of a system for providing services based on mutual authentication using direct communication according to an embodiment. Each of the mobile terminals 100 and 200 is a communicable computing device used by different users, for example, a smart phone. An application (service app) for providing a service based on mutual authentication through direct communication to a user may be installed and executed in each of the mobile terminals 100 and 200 . The service server 300 is a server system configured to include one or more servers, and provides a service requested by the users through data communication with the mobile terminals 100 and 200 of two face-to-face users.

The mutual authentication-based service providing system including such configurations mutually authenticates the other in a state where two users face each other, and provides the service requested by the face-to-face users only when the authentication succeeds. Mutual authentication is performed through direct communication between two mobile terminals. In addition, service items provided to face-to-face users include information sharing service that shares users' information, account remittance service that sends money from one user's account to another user's account, and matches and manages sporting events to be played by two users offline. A match matching service may be used as an example.

2 is a flowchart of a method for providing a service based on mutual authentication using direct communication according to an embodiment. As shown in Fig. 2, the mutual authentication-based service providing method is largely divided into a direct authentication step (S100) and a service step (S200). The direct authentication step (S100) is a process of mutual authentication through direct communication between the mobile terminals (100, 200) possessed by two face-to-face users, and the service step (S200) is a service to face-to-face users mutually authenticated by S100 is the process of providing The direct authentication step (S100) is a synchronization step (S110) for establishing a synchronization session between the first terminal 100 and the second terminal 200, and the first terminal 100 and the second terminal 200 in which the synchronization session is established. ) can be divided into an authentication step (S120) of mutual authentication between each other. In addition, the service step (S200) can be divided into a step (S210) of verifying (authentication) the validity of two users mutually authenticated through S100, and a step (S220) of providing a service to the two users whose validity has been verified. According to the above procedure, two users who have met each other offline can receive information sharing service, account remittance service, match matching service, etc. simply by touching their smartphones. For example, each service app presents a plurality of service items to a user, and when two users select the same service item, the corresponding service is provided.

First, S100 will be described. The first terminal 100 and the second terminal 200 mutually authenticate each other through short-range direct wireless communication (S110). In an embodiment, the short-range direct wireless communication is sound wave communication using a microphone and a speaker of a mobile terminal. Sound wave communication is a method of transmitting data using a relatively high frequency band that is difficult to recognize by the human ear. Human audible frequency generally has a band of 20Hz to 20kHz, although there are slight differences depending on the person, but if applied in consideration of the phenomenon of hearing loss as people age, even if an audio frequency of about 16kHz or higher is used, it can affect the lives of ordinary people. Non-interruptible sonic communication is possible.

In case of performing sound wave communication using two terminals, the order and method such as which terminal waits for reception and which terminal performs transmission should be predefined. Hereinafter, in order to define the order and method or each role, a series of procedures such as each terminal performing communication establishing a session and determining a transmission order through a synchronization process will be described below. Sound wave communication has characteristics of low transmission speed and narrow bandwidth, so it is limited compared to other communication methods that can transmit and receive a lot of data for a long time. Therefore, we present a procedure for quickly exchanging data required for authentication in a relatively short time and creating a mutually trusted relationship through the authentication process using a server.

In a communication method using sound waves between two terminals, frequencies for signals such as preamble and acknowledgment required in the synchronization process are defined, and sound waves are is sampled and converted into a digital signal. In this case, by generating or not generating the defined sound wave frequency, it is possible to encode 1, 0, which is a signal in units of bits. Data is transmitted according to a predefined byte transmission order, and the receiving end decodes it according to a predefined clock timing. For example, when the cycle of the clock signal is set to 1 ms and the frequency of transmission data is 17 kHz, transmission is performed with the frequency of 17 kHz at 1 ms intervals (1) or not (0) before data is transmitted. In other words, if you want to transmit the character ‘A’, the value of decimal 65, which corresponds to the ASCII value of ‘A’, is transmitted in binary. Since the decimal number 65 is 01000001 in binary, the frequency of 17 kHz is transmitted as shown in FIG. 3 according to the period of 1 ms.

At this time, in data transmission, as shown in FIG. 4 , a start bit and a stop bit are included as flags indicating the start and end of the data, and a parity bit is added before the stop bit to enable error detection. When data transmission starts, the transmitting terminal starts to transmit a HIGH signal, and then transmits data starting with the start bit as shown in the frame below. On the other hand, when all data of the transmitting side is transmitted, the HIGH signal is changed to a LOW signal, and the reception mode is switched.

The preamble transmits a sound wave having a constant period in a high frequency band, and is repeatedly broadcasted at slightly different intervals depending on the terminal until it is detected by the other terminal. On the other hand, the terminal ignores the signal detected from the microphone to avoid overlap with the preamble signal it sends while the preamble is being sent, and during the pause period (transmission pause period) that is stopped for a certain time between the preamble and the preamble, the Monitor for outgoing preambles. The terminal that first detects the preamble of the counterpart terminal stops transmitting its own preamble and repeatedly sends an ACK signal to notify the counterpart terminal about whether the preamble is recognized. And when the terminal that has transmitted the preamble receives the ACK, it stops transmitting the preamble and transmits the ACK signal again in response to the ACK of the counterpart terminal.

A diagram of such a synchronization process is shown in FIG. 5 . For reference, in FIG. 5 , each mobile terminal may randomly determine an end time for each start time of the transmission pause period, so that the transmission pause period may be different each time. Alternatively, the transmission pause period of each mobile terminal may be set differently. And a schematic representation of FIG. 5 procedurally is the same as FIG. 6 . In the above method, the first terminal (terminal A) and the second terminal (terminal B), which want to achieve sound wave communication, complete a mutual synchronization process and establish one session (S110). On the other hand, unlike the normal processing method, if the preamble is sensed for a predetermined time and a response for sending an ACK does not appear, synchronization will fail. In addition, if the ACK for the response is not sent after receiving the ACK for the preamble, the preamble receiving terminal processes the retransmission of the ACK three times, and if there is no response after that, the synchronization will fail. This is illustrated in FIG. 7 .

When the synchronization session is established, the two terminals 100 and 200 communicate for mutual authentication (S120). Through the above synchronization process, the signal transmission order in S120 is determined. As shown in FIGS. 5 and 6 , it is determined that the signal transmission starts from the terminal A 100 that has received the final ACK, and the terminal B 200 receives placed on standby Therefore, S120 starts from the terminal A 100, the process of which is shown in FIG. Looking at it, the terminal A 100 generates an authentication token using a private key for the terminal user (referred to as user A or the first user) issued from the service server 300 , and the generated authentication token is converted into sound waves together with user A's ID and sent. And the terminal B 200, which was waiting for reception, receives the sound wave data of terminal A and converts it into digital data, and the user A's ID and authentication token obtained therefrom, and the data including the delimiter flag that distinguishes the two, is converted into one string. is converted into a hash function and the hash value is transmitted as a response. Terminal A 100 receives the response of terminal B 200 and compares the hash value obtained by converting it into digital data with the hash value generated by itself and confirms whether it matches, and in response to the confirmation result, ACK or NAK to send

When the terminal B 200 receives the ACK from the terminal A 100, the terminal user (referred to as the user B or the second user) issued from the service server 300 uses a dedicated secret key for a one-time authentication token. , and converts the generated one-time authentication token into sound waves together with user B's ID and sends it. And the terminal A 100, which was waiting for reception, receives the sound wave data of the terminal B 200 and converts it into digital data, and the user B's ID and authentication token obtained therefrom, and data including a separator flag to distinguish the two It converts a single string into a hash function and transmits the hash value as a response. Terminal B 200 receives the response of terminal A 100 and compares the hash value obtained by converting it into digital data with the hash value generated by itself and confirms whether it matches, and in response to the confirmation result, ACK or NAK to send

According to the above, if the ID and authentication token of user A and the ID and authentication token of user B are well communicated and recognized without any problem, and all ACKs are exchanged, mutual authentication between user A and user B is completed and terminal A (100) The sound wave communication between the and B terminal 200 is terminated. Meanwhile, in the above process, if terminal B 200 receives a NAK from terminal A, terminal B 200 retransmits the hash value to terminal A 100, but the number of retransmissions is limited to terminal A 100. Ensure that the issued authentication token is verified within the valid time.

Next, S200 will be described. The service server 300 directly provides the requested service to the mutually authenticated users through S100 or provides the requested service after verifying (authentication) whether the users are valid users respectively (S210) (S220). In the latter case, the service server 300 processes the service subscription step of users in advance for valid user authentication, and provides the service after authenticating the validity of the users through the validity authentication step after completion of S100, and the service provision is completed When done, the channel termination step is performed. Hereinafter, each step will be described.

■ Service Subscription Steps

The subscription request process includes user authentication, personal information input, and agreement to terms and conditions similar to the general subscription procedure for other services. At this time, the secret key generated by the server (service server) matches the user ID 1:1, and the authentication token is generated using the secret key and used for verification. As the authentication token, TOTP (Time-based One-time Password) may be used. TOTP is a one-time password valid only for a limited time, which is advantageous for security in processing authentication between mobile users. In particular, the process of sharing information with the other party through sound wave communication can be vulnerable to security due to the environment where sound waves are exposed. can However, the authentication token is not necessarily limited to TOTP, and OTP (One-time Password) or HOTP (HMAC-baxed Ont-time Password) may be used.

■ Validation Steps

The user 1:1 authentication process receives a request for authentication for user B from terminal A and returns the result. In order to process the request of terminal A, the authentication process requires the user B's ID and authentication token to be authenticated. Accordingly, terminal A transmits the ID and authentication token of user B obtained through S120 to the server, and the server first checks whether user A is a valid user. If user A is valid, next, it is checked whether the ID of user B, which is the object of authentication, is valid, followed by checking whether user B's authentication token is valid. If all the test results are valid in this way, the server considers that terminal A and terminal B are communicating with each other. Here, the fact that terminal A and terminal B are communicating means that, if terminal A makes an authentication request for terminal B, relatively terminal B should also request authentication for terminal A. That is, the server considers that user B, the authentication target requested from terminal A, has already made a request for user A or that the request will be made within a short time.

Accordingly, the server generates an event when it is considered that the terminal A and the terminal B are communicating, and the event is assumed to be waiting for both parties to complete the authentication request for the counterpart for a certain period of time. If neither side makes an authentication request for the other, the server considers that the communication between the two users is terminated. That is, the event for communication between terminal A and terminal B is terminated, and a communication termination message is transmitted to each terminal. If both authentication requests are registered in the event for communication between terminal A and terminal B, the server assures that communication is occurring between the two users and activates the event. The communication event between terminal A and terminal B is a virtual authentication channel, and now terminal A and terminal B can receive service through this virtual authentication channel.

■ Channel Termination Phase

The life cycle of the authentication channel is one-time for the purpose of authentication, and when mutual authentication between terminals is completed, the service is made and terminated according to the procedure of the service model using authentication. Since the authentication channel is valid for the purpose of sharing between two terminals, another authentication channel cannot be created while one authentication channel is being used for one terminal. When the channel is terminated, each terminal becomes idle again and another authentication request becomes possible.

Hereinafter, a process for each service item will be described. First, an information sharing service will be described. 9 is a flowchart illustrating a method for providing a service based on mutual authentication for information sharing. Terminal A 100 and terminal B 200 perform mutual authentication through sound wave communication (S100). When the mutual authentication is successfully completed, the terminal A 100 requests validity authentication for the user B while transferring the authentication information of the user B to the service server 300 to use the information sharing service, and the terminal B 200 ) S200 starts with requesting validity authentication for user A while transmitting authentication information of user A to the service server 300 to use the information sharing service as well. As described above, the service server 300 verifies the validity of the users and matches the two users communicating with each other, and when the validity is normally verified, an event for information sharing is generated. And according to the generated event, the user B's personal information is delivered to the terminal A 100 and the sharing process of delivering the user A's personal information to the B terminal 200 is performed. When the sharing process is completed, the communication is terminated.

This will be described in detail. As described above, if the mutual authentication process using sound waves is followed, a trusted virtual channel is formed between the two mobile terminals, and now it is possible to share each other's contacts, profile pictures, business cards, etc. through this channel. The process for this is the step of registering the personal information to be shared → the step of selecting the information to be shared → the step of requesting mutual authentication between the two parties → the step of creating a meeting event → the step of exchanging the information to be shared → saving the received information It may consist of a step of managing and managing the information of the counterparty → a step of already possessing the counterparty information. Each step is described.

■ Step to register personal information you want to share

In order for a user who has subscribed to the service to share an individual's contact information or business card, the personal information to be shared must be registered in the database in advance. That is, this step is a preliminary step for using the information sharing service. Personal information to be shared may include name, nickname, phone number, home address, office address, email address, company name, department, position, occupation, business card, brief profile and profile picture. The user can manage such personal information by dividing it into groups. The management purpose of the group is to divide and share the information to be delivered according to the type of person to be shared in sharing personal information. According to user selection, personal information items are classified into groups and stored as records. For example, in the group 'Business', names, phone numbers, e-mail addresses, company-related information, and business cards can be shared as shared items, and in the group 'Friends', names, home addresses, and business cards can be shared as shared items. In the group 'group', names, nicknames, phone numbers, and profile pictures can be shared as items.

■ Steps to select the information you want to share

In order to share information with each other, such as contact information or business cards, the mobile terminal selects information to be shared. Selectable information can be selected for each item or group defined in ‘Registering personal information to be shared’. When an item or group to be shared is selected, the mobile terminal switches the user screen to the authentication process screen in order to proceed with the mutual authentication process (S100) using sound waves, and notifies the user of the next progress by vibration or a notification sound. On the other hand, the mobile terminal is in a simple standby mode as an "IDLE" state that does not currently do anything.

■ Step to request mutual authentication between both parties

The information to be shared is selected and the procedure of the mutual authentication process (S100) using sound waves in each mobile terminal is started. When S100 is normally completed, the status of each terminal is changed to “BUSY” until the exchange of information such as contact information or business card, that is, data sharing between each other is completed, and this value is managed by the server. Until the in-use state is converted to the IDLE state, other mutual authentication is restricted to prevent duplicate authentication from occurring. The status of the mobile terminal managed by the server is simply “READY” and “BUSY”. does not On the other hand, the terminal transmits an authentication request message to the server and at the same time switches to the "authentication waiting" state, and enters the "authentication complete" state while receiving a message about the authentication result.

■ Steps to create an encounter event

When the mutual authentication between users is completed, the server confirms that the two users are actually facing each other offline, and generates an event for the meeting. In the meeting event, a record including the user ID, time and place (location information), and information of each user to be shared is created and stored in the database based on the new ID according to the event. At this time, the meeting event is in an “off” state when each piece of information to be shared has not yet been exchanged, and then converted to a “closed” state after each piece of information to be shared is exchanged.

■ Steps to exchange information you want to share

When a meeting event is generated in the server, a push message is transmitted to the terminal participating in the event. In this push message, information about the meeting event and shared information that the other party wants to deliver are included in the payload. At this time, the payload consists only of general text information, and image information such as a profile picture or business card can be stored in the server. do. Meanwhile, as soon as the terminal receives the push message from the server, the terminal switches from the previous state of “authentication waiting” to “information sharing” state.

■ Steps to store and manage the received information

When the status of the mobile terminal is “information sharing”, the process from authentication between two users to sharing personal information is completed. Accordingly, the terminal requests the server to terminate the channel with the counterpart for communication completion processing. As for the request of the terminal, the request of the two users should be requested to the server as a pair like the authentication request performed previously, and at this time, the ID of the meeting event and the ID of the requesting user are included and transmitted. If the channel termination is not normally performed, the server separately manages the meeting event that is still “off” and transmits a request message for the termination request to the terminal that has not made the termination request. This process continues until the server's timeout time or limit on the number of retransmissions, and then ends at the server's own discretion. On the other hand, the terminal may receive the information of the other party as text or URL and store this information in the contact information in the terminal and/or the address book of the server.

■ Steps in case you already have the other party's information

Based on the information stored in the server, if the terminal already has the counterpart's information, the server transmits limited update information for newly changed content in the counterpart's information possessed by the mobile terminal. That is, only the information stored in the terminal, such as when a phone number is changed, when a name is changed, or when an email address used as a representative is changed, information that needs to be updated can be updated. In addition, in this case, since the information of the other party is already possessed, it is possible to update and manage the record of the number of times, time, and place of meeting with the other party. That is, in the case of having the information of the other party in the process of sharing information with the other party, only meeting information such as the number of meetings with the other party, meeting time, location information, etc. can be recorded and updated and managed. And this is not only initiated by the mutual information sharing process, but also can be automatically performed in an environment in which mobile terminals can communicate with each other through sound waves at any time according to background settings. In other words, if two mobile terminals are set to enable direct communication in the background, when they are placed in a short distance from each other, mutual communication can be initiated without a user's selection to update and manage meeting information.

If the server manages the address book of users, information of the other party can be checked through the address book. Accordingly, the server may check whether the user personal information to be shared is not registered in the other party's address book, and if it is not registered, the server may provide the user personal information to the other party. On the other hand, if it is already registered in the address book, the server updates the relationship record between the user and the other party, and at this time, the number of meetings with the other party is increased, and the date and time of the meeting event and related information can be stored and stored together. On the other hand, since information such as the number of times, time, and place of meeting with the other party can be used as individual statistical data, using data analysis techniques, it is possible to provide a service by drawing up a relationship map for each individual or a relationship map for each user group. And since the record that records the meeting event in the personal interpersonal relationship map can collect data based on time information, successive interpersonal records become time series data, and the time series data can be analyzed by a regression model. . In this analysis, it is possible to analyze the user's pattern and the number of meetings by each user, the number of meetings by each user, and the user's pattern, and it is possible to predict the future with this pattern. The data reproduced by this method can be classified into data by age, industry, gender, place, and time period, so that it can be supplied as data necessary for related industries.

The server can store and manage log records for all meeting events regardless of the user's selection, and, depending on the user's request, by inquiring the event records under conditions such as schedule, region, task, and group. can provide In addition, if big data analysis techniques are applied, data on the user's preferred time zone, region, and place, etc. classified by age, occupation, type, etc. of the user can be derived, and the data is provided to the user by utilizing such data in the industry to which it is applied. We can produce customized services that you can do.

Next, an account remittance service will be described. 10 is a flowchart illustrating a method of providing a service based on mutual authentication for account remittance. First, user A is the sender and user B is the recipient. When the user A and the user B face-to-face and the terminal A 100 and the terminal B 200 face-to-face, the terminal A 100 and the terminal B 200 perform mutual authentication through sound wave communication (S100). When the mutual authentication is successfully completed, the A terminal 100 requests validation of the payee while delivering the payee's authentication information to the service server 300 to use the account remittance service, and the B terminal 200 also S200 starts with requesting validity authentication for the sender while transmitting the authentication information of the sender to the service server 300 . At this time, the terminal A 100 also transmits the remittance amount information input from the remitter to the service server 300 . As described above, the service server 300 verifies the validity of users and matches two users communicating with each other, and when the validity is normally verified, an event for account remittance is generated. A transfer transaction is performed to transfer the remittance amount from the sender's account to the recipient's account according to the generated event. When the transfer transaction process is completed, the communication is terminated.

This will be described in detail. The process for account remittance service is the step of registering a personal account → the sender decides the amount to be remitted → the sender and the recipient request approval for the transfer transaction → the step of creating a transfer transaction event → the step in which the transfer transaction is in progress → the sender It may consist of a step of confirming the transaction between the recipient and the recipient → completing the transaction. Each step is described.

■ Steps to register a personal account

A user who wants to use the remittance service must register an account in the name of the person to be used for the transaction. The personal account is registered through the authentication process of the financial institution with which the transaction is made, and the server may request the user to input a profile picture. Since this service is characterized by direct remittance transactions to the face-to-face recipient, a procedure may be required to enable the sender to verify that the recipient matches the actual counterparty. On the other hand, the terminal in this state is in the "IDLE" state, and the state of the terminal managed by the server is "READY".

■ The step in which the sender decides the amount to send.

When a sender and a recipient are determined between users using the service, the sender determines the amount to be remitted on the screen of the terminal. Before setting the remittance amount, the sender can check the balance and determine the remittance amount through account inquiry. On the other hand, the sender's terminal is switched to the “remittance ready” state. On the other hand, the recipient terminal has not yet entered the remittance service.

■ A step in which the sender and the recipient request approval of the transfer transaction.

When the sender determines the amount to be remitted to the recipient, each user selects “transfer transaction” on the terminal, and each terminal switches to the “transaction request” state. The two terminals perform authentication according to the authentication process procedure between mutual devices using sound waves. At this time, the terminal of the remitter that has determined the remittance amount transmits a transfer transaction request message including the remittance amount and a one-time password in the payload to the server. On the other hand, since the “transaction” is started in a state where there is no separate state, the payee terminal is automatically set to the payee mode and transmits a transfer transaction request message to the server in the receiving state.

■ Steps to create a transfer transaction event

When a transfer transaction request message is received from the sender terminal and the payee terminal, respectively, the server authenticates the validity of the other party according to the authentication request included in the transfer transaction request message, and then starts the authentication operation for the transfer transaction event. The verification process for the transfer transaction event starts with a determination as to whether the remittance amount requested by the sender can be transferred within the balance limit. The server initiates communication with an external open banking system (Open Banking Center), and verifies the suitability of the remittance amount by requesting a balance inquiry and transfer limit inquiry of the account registered by the sender. In addition, the server verifies the sender's one-time password. The server checks whether the one-time password is valid using the sender's private key stored in the internal database. Next, the server checks whether the remittance presented by the remitter can receive the remittance. It is to check whether the payee has registered a personal account and to check whether the payee's account is valid and acceptable by requesting an account real name inquiry to the Open Banking Center. In addition, the server checks whether a transfer transaction request message including a status value of waiting for receipt is received from the recipient terminal.

If all conditions are satisfied in the result of such check, the server creates a new record as a transfer transaction event, including items such as the ID of the sender and recipient who participated in the transfer transaction, transaction date and time, location, remittance amount, and transaction result. When a transfer transaction event is generated, the server transmits a push message including information on the transfer transaction event to the sender terminal and the receiver terminal to notify that the transfer transaction has started. On the other hand, the sender terminal and the recipient terminal change the status of the terminal to “in transaction” according to the transfer transaction start notification from the server, and then wait for a message to be transmitted from the server.

■ The stage of the transfer transaction

While the sender terminal and the payee terminal request a transfer transaction to the server and wait for the result, the server initiates communication with the open banking center to transfer the remittance amount from the sender account to the payee account according to the requested contents.

■ Steps to confirm the transaction between the sender and the recipient

The transfer transaction event is now left with only final approval from the sender. The details of the transfer transaction performed according to the above procedure are transmitted from the server to the remitter terminal. The remitter checks the remittance amount and remittee information through the remittee transfer transaction specification, and if necessary, has a procedure to check the remittance by requesting a photo of the remittee and comparing it with the actual remittee. That is, the remitter terminal requests and receives the remittee photo from the server according to the remitter command, and displays the received remittee photo on the screen so that the remitter can check it. Thereafter, the remitter terminal transmits a remittance request message to the server according to the remittance approval input of the remitter, and the server initiates the transfer according to the prepared transfer transaction specification.

■ Steps to complete the transaction

As the remittance is completed, the server ends the transfer transaction event and transmits a remittance completion message to the remitter terminal and the recipient terminal. Accordingly, each terminal terminates the transfer transaction and restores the state.

Finally, the match matching service will be described. 11 is a flowchart illustrating a method of providing a service based on mutual authentication for match matching. Terminal A 100 and terminal B 200 perform mutual authentication through sound wave communication after receiving a sports event selection from user A and user B, respectively (S100). When the mutual authentication is successfully completed, the terminal A 100 requests validation of the user B while transmitting the authentication information of the user B to the service server 300 to use the sports match matching service, and the terminal B ( 200) In order to use the information sharing service, S200 starts with requesting validity authentication for user A while delivering authentication information of user A to the service server 300 . In this case, the terminal A 100 transmits the item code selected by the user A to the service server 300 , and the terminal B 200 may also transmit the item code selected by the user B to the service server 300 . Alternatively, the item code may be transmitted to the service server 300 through a separate procedure.

The service server 300 verifies the validity of the users and whether the event codes received from the two terminals match, matches the two users communicating with each other, and generates an event for match matching if the verification is successful. The service server 300 notifies the A terminal 100 and the B terminal 200 that authentication and matching have been completed so that the match can start and manages the match progress status, from the A terminal 100 and the B terminal 200 You can mediate by receiving meta-information related to the game. Here, the meta information may include at least some of score information (score status), the number of participants in the game, and record information of participating players. That is, the participants in the actual match are not necessarily limited to only user A and user B. Thereafter, the end standby state is maintained until there is a request to end the game from the terminal A 100 and the terminal B 200 . And the service server 300 records and manages the match result in the match result table according to the match matching event after the match is over. That is, the match result can be recorded and managed in the match result table between two users.

This will be described in detail. The process for match matching service is the stage of requesting approval of the match including the event code → the stage of setting up a new match → the stage of running the match and managing the score → the stage of pausing or ending the match → the stage of viewing and sharing the match can be composed of Each step is described.

■ Approval request stage for competitions including event codes

Two users wishing to play a sport select the same sport through their respective service apps and initiate the process with “Start”. Accordingly, each terminal proceeds with a mutual authentication procedure (S100) using sound waves. When S100 is normally completed, each terminal requests authentication for the sports match matching service to the server, and the server authenticates the validity of the users accordingly. Each terminal receives an authentication completion message from the server, and may notify the user of this fact by vibration or a notification sound.

Meanwhile, each terminal may transmit the sports event code selected by the user together when an authentication request is made to the server. The server approves the start of the offline sports game only when the two terminals requesting match matching transmit the same event code, and rejects the start of the game if the event codes are not the same. For example, when user A and user B start a sporting event of table tennis, both users must select an event code assigned to table tennis, and in this state, a game start authentication request must be transmitted. In addition, when both users are valid users and the same item code is presented as a result of the authentication, the server matches the two users and sends an authentication completion message to each terminal, and as both terminals receive the authentication completion message from the server, Switches to the start screen for the sports match matching service.

■ Steps to set up a new match

As the match approval request succeeds, the server creates a new match event. It creates a record containing information such as event code, ID of the method (rule set), participating users' IDs, and other time and place, and creates a match. It issues a new ID for the event and stores it in the storage. When a new game event is generated, the generated game event information is transmitted as a push message to the terminal of each user participating in the game. Accordingly, each terminal uses the received game event information to switch to the game start and progress screen. The server sets the count for the game time and sends the count information as a push message at regular intervals until the game is over. In addition, each terminal counts in synchronization with the count information of the server, and displays the score status board along with the game progress time and each user's name or nickname. Set scores should also be displayed on the status board. For reference, the score status information displayed on the terminal is exemplified in FIG. 12 . In the same way as described above, the two users are ready to start the sports game mediated by the server.

■ Steps to play matches and manage scores

The scoreboard of each player participating in the game is configured to adjust the score by inputting a touch on the terminal screen. Swipe up on the screen to increase your score, and scroll down to decrease your score. In the internal processing, when a touch input is generated on the screen, the terminal obtains the coordinates of the touched screen and determines which action the user requests. If the touch input is made on the scoreboard, it is determined whether the sweeping direction is upward or downward, and the addition or subtraction of the score is determined. Since the input touched on the screen can occur continuously, the addition or subtraction information of the score desired by the user is determined with a time difference at which the input is no longer generated. If the score information requested by the user is determined, the terminal requests and receives the current score information from the server, calculates the addition or subtraction of the score generated by the user's touch on the score information, and sends the result back to the server to request an update do. The server updates the score information according to the score update request transmitted from the terminal and transmits the result back to the terminal participating in the game. Then, the terminal updates the score information of the terminal according to the score information received from the server.

Since simultaneity may occur in the process of requesting the above score information from the terminal to the server, the processing for this is solved in the following way. If a cycle in which new score information generated from a terminal is requested from the server and updated to all participating terminals is a single transaction, even if there is another request during one transaction, it should be queued without reflecting it. Therefore, the server has a queue for the request of the terminal and processes the request according to the order of entering the queue. ID of the user who is playing and the score information that the user wants to update is included.

■ Steps to pause or end the match

When the game pause is touched, the game time is paused and the game resume button is activated to wait. At this time, a stop request including the ID of the user requesting the stop and the corresponding match event ID is transmitted to the server, and the server causes the count of the match to be paused. This status can then be changed to the status of restarting the game or ending the game. When there is a touch input for ending the game, a request to end the game is transmitted from the terminal to the server, and the server stores the corresponding game event ID and the ID of the user who requested the end of the game. Thereafter, a game end message is transmitted to the terminal participating in the match, and the terminal requests the user to process the end approval.

The end approval process allows the user to perform sonic communication by bringing the terminal close to each other in the same way as when requesting the game approval for the first time with the other user who played the game together, and to request the end approval. The method of game end approval is the same as that of the initial match approval request, but the data sent to the server additionally includes an ongoing match event ID. The server side closes the match event upon request to end the match, considers the user who participated in the match to have ended the match by agreement, organizes the match record, distinguishes winners from losers, and records the results in the match result table record If the game end processing by sound wave communication is not performed, the server waits for the time-out time for the game event, and then the game ends at the judgment of the service server.

■ Steps to view and share matches

Views of a match can be shared with users participating in the match as well as other users that the user allows. Match inquiry is possible from the time a game starts and a new match event is created, and users who view this match can share stories related to the sporting event in progress by writing comments or uploading photos and videos. Whenever a comment is added, the current score status is automatically added from the server below the comment. Therefore, you can broadcast or enjoy the game while viewing the status of the game at the time of commenting.

In addition to the 1:1 sports events discussed above, the mutual authentication process using a mobile terminal is also used for doubles and team matches in which multiple people form a team, mountaineering, trekking, and record events such as cycling and marathon. An extensible service model can be further proposed.

Meanwhile, FIG. 13 is a flowchart at the time of service termination. Even at the end of the service, mutual authentication may be performed between the A terminal 100 and the B terminal 200 through sound wave communication, and when the mutual authentication is successfully completed, the A terminal 100 and the B terminal 200 are each service server ( 300) to request service termination. Accordingly, the service server 300 performs a procedure of verifying the validity of the user A and the user B, similar to that for the service provision. In addition, the service server 300 terminates the event after verifying the event generated for providing the service. Thereafter, communication with the terminal A 100 and the terminal B 200 is terminated. This process may be applied only to the match matching service among the above-described services, or may be applied to other services.

So far, with respect to the present invention, the preferred embodiments have been looked at. Those of ordinary skill in the art to which the present invention pertains will understand that the present invention may be implemented in a modified form without departing from the essential characteristics of the present invention. Therefore, the disclosed embodiments are to be considered in an illustrative rather than a restrictive sense. The scope of the present invention is indicated by the claims rather than the foregoing description, and all differences within an equivalent scope should be construed as being included in the present invention.

100: first terminal (A terminal) 200: second terminal (B terminal)
300 : service server

Claims (17)

A direct authentication step in which two face-to-face user-specific mobile terminals communicate directly to mutually authenticate each other, wherein each mobile terminal mutually authenticates through sound wave communication using a microphone and a speaker; and
A service providing step in which the service server provides a requested service to mutually authenticated users;
Direct authentication steps are:
Each of the two mobile terminals repeatedly transmits the preamble signal as sound waves, and during each transmission pause period, whether a preamble signal is received from the other terminal is detected. Instead of stopping, it repeatedly transmits a response signal to the reception of the preamble signal as sound waves. a synchronization step of transmitting a response signal to establish a synchronization session between the first terminal and the second terminal; and
When the synchronization session is established, mutual authentication between the two mobile terminals through sound wave communication, and a mutual authentication step of starting signal transmission for mutual authentication from the first terminal receiving a response signal from the second terminal through the synchronization step; and ,
Mutual authentication steps are:
transmitting, by the first terminal, the one-time authentication token generated with the private key of the terminal user to the second terminal together with the identifier (ID) of the terminal user;
converting, by the second terminal, a string including the user ID and the authentication token received from the first terminal into a hash function, and transmitting the hash value obtained through the conversion to the first terminal;
Comparing the hash value generated by the first terminal itself with the hash value received from the other terminal, and responding to the second terminal whether or not they match;
transmitting, by the second terminal, a one-time authentication token generated with the secret key of the user of the second terminal to the first terminal together with the identifier (ID) of the user of the second terminal when the second terminal receives the matching response from the first terminal;
converting, by the first terminal, a string including the user ID and the authentication token received from the second terminal into a hash function, and transmitting the hash value obtained through the conversion to the second terminal; and
Comparing whether the hash value generated by the second terminal and the hash value received from the first terminal are the same, responding to the first terminal;
A method of providing a mutual authentication-based service using direct communication comprising a. The method of claim 1,
A mutual authentication-based service providing method using direct communication in which the transmission pause period of each mobile terminal is randomly determined at each start time. The method of claim 1,
In the service provision step, authentication processing is performed according to an authentication request for whether the user of the opposite terminal is a valid user from the first terminal and the second terminal, respectively, which have completed mutual authentication, and if both are authenticated as valid users, the requested service A method of providing a mutual authentication-based service using direct communication that provides 4. The method of claim 3,
The service providing step is a direct method of receiving the ID and authentication token of the second terminal user received from the first terminal to authenticate the validity, and receiving the ID and the authentication token of the first terminal user received from the second terminal to authenticate the validity A method of providing services based on mutual authentication using communication. 5. The method according to any one of claims 1 to 4, wherein the step of providing a service comprises:
An information sharing service providing step of providing the personal information of the two users registered in the database to each other's mobile terminal;
A method of providing a mutual authentication-based service using direct communication comprising a. 6. The method of claim 5,
The information sharing service providing step is a mutual authentication-based service providing method using direct communication that provides only the personal information belonging to the group selected by the user to the other party's mobile terminal when the user's personal information registered in the database is grouped into a plurality of groups. 6. The method of claim 5,
In the information sharing service provision step, it is checked whether the personal information of the user to be shared is registered in the address book of the other party managed in the internal database, and only if it is not registered, the personal information is provided to the other party's mobile terminal through mutual authentication using direct communication. How to provide the underlying services. 6. The method of claim 5, wherein the step of providing a service comprises:
creating a relationship record indicating a relationship between two users sharing information and managing the database; and
updating the relationship record with meeting information including at least a part of the number, time, and place of meeting between the two users according to the mutual authentication of the mobile terminal performed every time the two users meet;
Mutual authentication-based service providing method using direct communication further comprising a. 5. The method according to any one of claims 1 to 4, wherein the step of providing a service comprises:
an account remittance service providing step of processing remittance from one user's account to another user's account among the two mutually authenticated users;
A method of providing a mutual authentication-based service using direct communication comprising a. The method of claim 9, wherein the step of providing an account remittance service comprises:
receiving a transfer transaction request message including a remittance amount from a mobile terminal of one user among two mutually authenticated users and receiving a transfer transaction request message including no remittance amount from a mobile terminal of another user; and
designating one user as a remitter and designating another user as a remittee, and then performing a remittance transfer transaction from the remitter account to the remittee account in connection with the open banking system;
A method of providing a mutual authentication-based service using direct communication comprising a. 11. The method of claim 10,
In the transfer transaction process, before the remittance amount is transferred, the transfer transaction details and a photo image of the recipient are provided to the sender's mobile terminal for approval of the remittance, and when the sender's remittance is approved from the sender's mobile terminal, the remittance amount is transferred from the sender's account to the recipient's account A method of providing services based on mutual authentication using direct communication that proceeds with 5. The method according to any one of claims 1 to 4, wherein the step of providing a service comprises:
providing a match matching service for managing the progress of an offline sporting event in conjunction with mutually authenticated mobile terminals;
A method of providing a mutual authentication-based service using direct communication comprising a. The method of claim 12, wherein the step of providing a match matching service comprises:
Receiving a game approval request message including a sports event code from each of the mutually authenticated mobile terminals;
Approving the start of a game when the sport event codes included in each game approval request message received from the mobile terminals are the same, generating a new game event, and transmitting the new game event information to the mobile terminals;
Receiving and mediating game-related meta information from mobile terminals that have received the new game event information; and
Recording and managing the match result in the match result table between the two users after the match is over;
A method of providing a mutual authentication-based service using direct communication comprising a. delete delete delete delete

Images