WO2017003215A1

WO2017003215A1 - Routing method and network entity performing same

Info

Publication number: WO2017003215A1
Application number: PCT/KR2016/007027
Authority: WO
Inventors: 투이이피 주식회사; 조광현
Original assignee: 투이이피 주식회사
Priority date: 2015-06-30
Filing date: 2016-06-30
Publication date: 2017-01-05
Also published as: WO2017003215A8

Abstract

A method for operating a communication device is disclosed. One embodiment includes the steps of: generating an intermediary key corresponding to peer to peer (P2P) communication between a client and a counterpart client; transmitting the intermediary key to the counterpart client; obtaining an intermediary path corresponding to the intermediary key; receiving the data through the intermediary path from the client that did not receive an acknowledgement for data transmitted to the counterpart client because of a change of a network address of the counterpart client; and transmitting the data to the counterpart client if the counterpart client accesses the changed network address by using the intermediary key.

Description

Routing method and network entity performing it

The embodiments below relate to a routing method and a network entity performing the same.

In recent years, voice communication based legacy communication charge schemes have been shifted to data based schemes. The telecom market has evolved from analog 1G (generation) to digital 2G (digital), from 2G to 3G for data communication, and to 4G with more data transfer bandwidth than 3G.

Recently, mobile communication technology targets 5G. The evolution to 5G requires not only expansion of communication bandwidth but also improvement of data transmission speed. Various communication methods may be applied to improve the data transmission speed.

When using a peer-to-peer (P2P) or relay method among various communication methods, a network routing technique is required to guarantee a quality of service (QoS) that can support voice calls.

In addition, in the case of using a peer to peer (P2P) or relay method among various communication methods, that is, in the case of communication that does not go through a network entity directly managed by a mobile service provider, It is difficult to carry out the billing.

According to an aspect of an exemplary embodiment, a method of operating a communication device includes generating an intermediate key corresponding to peer to peer (P2P) communication between a client and a counterpart client; Transmitting the intermediate key to the counterpart client; Securing an intermediate path corresponding to the intermediate key; Receiving the data through the intermediary path from the client whose network address of the counterpart client has been changed and has not received an acknowledgment for the data sent to the counterpart client; And transmitting the data to the counterpart client when the counterpart client connects using the intermediate key.

The generating of the intermediate key may include generating the intermediate key when connected to the counterpart client that has received the client's P2P communication request from the server.

The server may receive the intermediate key from the counterpart client, transmit the intermediate key to the client, and the step of securing the intermediate path may include: receiving the intermediate key from the client; Securing may be included.

The intermediate path may include a dedicated room of the client holding the intermediate key and the counterpart client.

The transmitting of the data to the counterpart client may include: receiving a connection request including the intermediate key from the counterpart client having the changed network address; And allowing an access according to the access request based on the intermediate key.

The intermediate key may correspond to an arbitrary value or may be generated based on unique information of the client and the counterpart client.

The client may receive an acknowledgment for the data received by the counterpart client from the communication device, and may later transmit data to the changed network address of the counterpart client.

According to an aspect, an operation method of a server may include: receiving a P2P communication request from a client and transmitting the P2P communication request to a counterpart client; When the counterpart client accesses the server, generating an intermediate key and transmitting the intermediate key to the counterpart client and the client; Receiving the intermediate key from the client to secure an intermediate path corresponding to the intermediate key; Receiving the data through the intermediary path from the client whose network address of the counterpart client has been changed and has not received an acknowledgment for the data sent to the counterpart client; And transmitting the data to the counterpart client when the counterpart client reconnects using the intermediate key.

The transmitting of the data to the counterpart client may include: receiving a reconnection request including the intermediate key from the counterpart client having the changed network address; And allowing an access according to the reconnection request based on the intermediate key.

Receiving an address change notification from the counterpart client when the network address of the counterpart client changes; And notifying the client of the change of the network address.

The client may receive an acknowledgment for the data received by the counterpart client and may later transmit data to the changed network address of the counterpart client.

When receiving the P2P communication request of the client, the method may further include allocating a session identifier of the client to the client.

Sending a randomly generated question to the client that connected before receiving the P2P communication request; Receiving an answer from the client; And confirming whether the answer corresponds to the question.

The transmitting of the question may include transmitting, to the question, first cryptographic information generated by encrypting identification information received from the client and access time information of the client, and receiving the answer. The method may include receiving, as the answer, second cryptographic information generated by encrypting the first cryptographic information, and confirming whether the answer corresponds to the question by decrypting the second cryptographic information. And checking whether the extracted extraction information corresponds to the identification information and the access time information.

According to an aspect, an operation method of a client may include transmitting a P2P communication request to a server; Receiving, from the server, a media key generated by a communication mediator for mediating communication between the client and the counterpart client and a network address of the counterpart client; Connecting with the communication media device using the media key; Transmitting data to the counterpart client using the network address; And when the network address is changed and fails to receive an acknowledgment for the data transmitted to the counterpart client, transmitting the data to the communication mediator, wherein the counterpart client uses the intermediary key. Connect to the communication medium and receive the data from the communication medium.

When connected with the communication medium device, a medium path corresponding to the medium key can be secured.

The method may further include receiving a notification from the server that the network address has changed.

The counterpart client may further include receiving, from the counterpart client, an acknowledgment for the data received from the communication medium device.

The generating of the P2P communication path may include: sending a speed test request to the counterpart client; Receiving a test response to the speed test request from the counterpart client; And checking a response time of the counterpart client based on the test response.

The transmitting of the data may include transmitting the data to the communication medium device when the acknowledgment is not received within the response time.

Accessing the server and receiving a randomly generated question from the server prior to sending the P2P communication request; And transmitting an answer to the server.

Receiving the question comprises: transmitting identification information of the client to the server; And receiving, as the question, first cryptographic information generated by encrypting the identification information and the access time information of the client, and transmitting the answer, encrypting the first cryptographic information. And transmitting the encrypted second cryptographic information as the answer.

According to another aspect of the present invention, there is provided a method of operating a client, when receiving a P2P communication request of a requesting client from a server; Receiving an intermediate key from the communication intermediate device; Reconnecting to the communication media device using the media key when the network address of the client is changed; Receiving the data from the communication medium device, receiving the data from the requesting client that has not received an acknowledgment for the data sent to the client; And sending an acknowledgment for the data to the requesting client.

According to an aspect, there is provided a communication device including: a controller configured to generate a media key corresponding to peer-to-peer communication between a client and a counterpart client, and to secure a media path corresponding to the media key; And transmitting the media key to the counterpart client, and receiving the data through the intermediary path from the client that has changed the network address of the counterpart client and has not received an acknowledgment for the data sent to the counterpart client. And, when the counterpart client accesses using the intermediate key, transmits the data to the counterpart client.

The client according to one side sends a P2P communication request to the server, and receives from the server the media key and the network address of the counterpart client generated by the communication mediator for mediating communication between the client and the counterpart client, Connecting to the communication media device using a key, transmitting data to the counterpart client using the network address, and changing the network address, and failing to receive an acknowledgment for data transmitted to the counterpart client. A connection unit for transmitting the data to the communication medium device; And a processor for controlling the connection unit, wherein the counterpart client connects to the communication medium apparatus using the medium key and receives the data from the communication medium apparatus.

When the client according to the other side receives the P2P communication request of the requesting client from the server, access the communication medium device, receive the medium key from the communication medium device, if the network address of the client is changed, the medium key Reconnect to the communication media device using the device, wherein the communication media device receives the data from the device to the requesting client that has not received an acknowledgment for the data sent to the client. A connection unit receiving the data and transmitting an acknowledgment for the data to the requesting client; And a processor controlling the connection unit.

According to another aspect of the present invention, there is provided a method of operating a client, comprising: establishing a peer to peer (P2P) communication path with a counterpart client; Transmitting a shared key to the counterpart client; Receiving data encrypted with the shared key through the P2P communication path; Decrypting the encrypted data using the shared key; And when the data is decrypted, updating decryption number information related to data usage of the client.

The method may further include transmitting updated decryption number information to a server, and receiving guide information on the data usage amount from the server.

The guide information may include: excess information indicating whether the data usage amount exceeds a predetermined usage amount; Remaining information indicating available data capacity excluding the data usage amount among the predetermined usage amounts; And restriction information indicating whether there is a restriction on at least one of bandwidth and quality of the P2P communication of the client.

Receiving information related to data usage of a shared client sharing a data quota assigned to the client; And updating the decoding count information based on the received information.

The received information may include updated decryption number information each time the shared client decrypts the encrypted data received through the P2P communication.

If the network address of the client changes, transmitting change information indicating that the network address of the client changes to a server; Accessing a communication mediation device that secures an intermediate path corresponding to the P2P communication path; And receiving other data encrypted with the shared key of the counterpart client from the communication medium device, wherein the counterpart client receives an acknowledgment for the other data transmitted to the client from the client. If not, the other data may be transmitted to the communication medium.

When decrypting the other data with the shared key, the method may further include updating the decryption number information.

The establishing of the P2P communication path may include transmitting a P2P communication request to a server; Receiving, from the server, a media key generated by a communication mediator for mediating communication between the client and the counterpart client and a network address of the counterpart client; Accessing the communication media device using the media key; And establishing a P2P communication path with the counterpart client based on the network address when accessing the communication medium device.

The establishing of the P2P communication path may include: receiving a P2P communication request of the counterpart client from a server; When receiving the P2P communication request, accessing a communication mediation device that mediates communication between the client and the counterpart client; Receiving a media key from the communication media device and transmitting the media key to the server; Receiving test data from the counterpart client and establishing the P2P communication path, wherein the counterpart client receives the client's network address and the intermediate key from the server, and uses the intermediate key; Access to the communication media device, and transmit the test data to the client using the network address.

According to another aspect of the present invention, a client establishes a peer-to-peer communication path with a counterpart client, transmits a shared key to the counterpart client, and receives data encrypted with the shared key through the P2P communication path. ; And a controller that decrypts the encrypted data using the shared key and updates decryption number information related to data usage of a client when the data is decrypted.

The communication interface may transmit the decryption number information to a server and receive guide information on the data usage amount from the server.

The communication interface may receive information related to data usage of a shared client sharing a data quota allocated to the client, and the controller may update the decryption count information based on the received information. have.

When the network address of the client is changed, the communication interface transmits change information indicating that the network address of the client is changed to a server, and accesses a communication medium device that secures an intermediate path corresponding to the P2P communication path. And receiving other data encrypted with the shared key of the counterpart client from the communication medium device, and when the counterpart client fails to receive an acknowledgment for the other data transmitted to the client from the client, Other data may be sent to the communication media device.

The controller may update the decryption number information when the other data is decrypted with the shared key.

The communication interface transmits a P2P communication request to a server, and receives from the server an intermediate key generated by a communication mediator for mediating communication between the client and the counterpart client and a network address of the counterpart client. When accessing the communication medium device using a key and accessing the communication medium device, the P2P communication path with the counterpart client may be established based on the network address.

The communication interface receives a P2P communication request of the counterpart client from a server, and when receiving the P2P communication request, connects to a communication mediator that communicates communication between the client and the counterpart client, and from the communication medium. Receiving the intermediate key, transmitting the intermediate key to the server, receiving test data from the counterpart client, and establishing the P2P communication path, wherein the counterpart client is configured to receive the client's network address and the A media key may be received, the media key may be used to access the communication media device, and the test data may be transmitted to the client using the network address.

According to embodiments, even if the P2P communication path is disconnected, the client may communicate through an intermediate path corresponding to the P2P communication path, thereby improving network throughput. In addition, according to embodiments, when a data-based call or messaging service is provided through P2P communication, charging for data usage of P2P communication may be performed. Further, according to embodiments, charging based information may be generated via communication software.

1A to 1B are flowcharts illustrating an example of an operation of a communication system according to an exemplary embodiment.

2 is a flowchart illustrating another example of an operation of a communication system according to an exemplary embodiment.

3A to 3B are block diagrams illustrating a communication system according to an embodiment.

4 is a diagram for describing an operation of a communication system, according to an exemplary embodiment.

5 is a flowchart illustrating a method of operating a communication device, according to an exemplary embodiment.

6 is a flowchart illustrating a method of operating a server, according to an exemplary embodiment.

7 is a flowchart illustrating an example of a method of operating a client, according to an exemplary embodiment.

8 is a flowchart illustrating another example of a method of operating a client, according to an exemplary embodiment.

9 is a flowchart illustrating session maintenance between a client and a server, according to an exemplary embodiment.

10A and 10B are diagrams for describing another example of a method of operating a client, according to an exemplary embodiment.

FIG. 11 illustrates a sharing of a data quota allocated to a client according to an exemplary embodiment.

12 is a block diagram illustrating an example of a client according to an exemplary embodiment.

FIG. 13 illustrates an example of a secure call dongle according to an exemplary embodiment.

Hereinafter, exemplary embodiments will be described in detail with reference to the accompanying drawings.

Various modifications may be made to the embodiments described below. The examples described below are not intended to be limited to the embodiments and should be understood to include all modifications, equivalents, and substitutes for them.

The terminology used herein is for the purpose of describing particular example embodiments only and is not intended to be limiting of examples. Singular expressions include plural expressions unless the context clearly indicates otherwise. In this specification, terms such as "comprise" or "have" are intended to indicate that there is a feature, number, step, action, component, part, or combination thereof described on the specification, and one or more other features. It is to be understood that the present invention does not exclude the possibility of the presence or the addition of numbers, steps, operations, components, components, or a combination thereof.

Unless defined otherwise, all terms used herein, including technical or scientific terms, have the same meaning as commonly understood by one of ordinary skill in the art. Terms such as those defined in the commonly used dictionaries should be construed as having meanings consistent with the meanings in the context of the related art, and are not to be construed in ideal or excessively formal meanings unless expressly defined herein. Do not.

In addition, in the description with reference to the accompanying drawings, the same components regardless of reference numerals will be given the same reference numerals and redundant description thereof will be omitted. In the following description of the embodiment, when it is determined that the detailed description of the related known technology may unnecessarily obscure the gist of the embodiment, the detailed description thereof will be omitted.

Referring to FIG. 1A, a communication system according to an embodiment includes a client 1, a server, an intermediary, and a client 2.

Although not shown in FIG. 1A, the server may establish a communication session (eg, a User Datagram Protocol (UDP) session) with each of Client 1 and Client 2.

Client 1 sends a communication request to the server (110). For example, the client 1 may transmit a P2P communication request to the server through a UDP session for peer to peer (P2P) communication with the client 2.

The server transmits a communication request of client 1 to client 2 (111).

When the client 2 receives the communication request from the client 1, the client 2 may connect with the intermediary 122. More specifically, when the client 2 receives the client 1's communication request from the server, the client 2 may attempt to connect to the intermediary, and the intermediary may allow the client 2 to connect. Accordingly, the client 2 can connect to the intermediary and maintain the connection.

According to an embodiment, the intermediary is a device that is physically distinct from the server, and may be an independent device on the network. In addition, depending on the implementation, the intermediary may be included in the server, and may be any one of a plurality of units logically separated within the server.

When the intermediary unit is connected to the client 2, the intermediary unit generates 113 an intermediary key. For example, the intermediary can generate an intermediary key with an arbitrary value. In addition, the intermediary may generate the intermediary key based on the unique information of the client 1 and / or the client 2. The unique information may include, for example, an identifier assigned to each of Client 1 and Client 2.

The intermediary sends the intermediary key to client 2 (114).

Client 2 sends the intermediate key to the server (115).

The server sends the client 2's network address and intermediate key to client 1 (116). The network address may include, for example, an IP (Internet Protocol) address.

Client 1 sends the intermediary key to the intermediary (117). Client 1 can access the intermediary by sending the intermediary key to the intermediary. In addition, the client 1 can maintain a connection with the intermediary.

If the interceptor receives the intermediary key from the client 1, the interceptor secures the intermediary path (118). In the example shown in FIG. 1A, an intermediary path may be formed that corresponds to the connection relationship of client 1-mediated-client 2. The intermediate path is a path to prepare for disconnection of the P2P communication path between the client 1 and the client 2. In one embodiment, the intermediary path may comprise dedicated rooms of Client 1 and Client 2 having the media key. Securing the intermediary path may mean that a dedicated room is created in the intermediary. When the intermediary receives the intermediary key from client 1, the intermediary may create a dedicated room where client 1 and client 2 can participate and other clients cannot participate.

Client 1 may send a speed test request to client 2 via the network address (119). When the client 1 accesses the intermediary unit or when the intermediate path is secured, the client 1 may transmit test data for testing the P2P communication speed to the client 2.

Client 2 may send a test response to the speed test request to client 1 (120). Client 1 can check the response time of Client 2. Client 1 can check the P2P communication speed between Client 1 and Client 2.

Client 2 may transmit a speed test request to client 1 (121). Client 1 may send a test response to the speed test request to client 2 (122). Client 2 can check the response time of Client 1.

The speed test of client 2 may be performed simultaneously with the speed test of client 1.

In one embodiment, the speed test of Client 1 and / or Client 2 may be repeated a predetermined number of times. For example, the speed test may be repeated two or more times. Client 1 can send an additional speed test request to Client 2 upon receiving a test response from Client 2. Client 2 may send a test response to the additional speed test request to client 1. Based on the repeated speed test, Client 1 can check the average response time of Client 2. Similarly, based on the repeated speed test, Client 2 can ascertain the average response time of Client 1.

A P2P communication path may be established between client 1 and client 2. Assume that client 1 is mapped to network address A, and client 2 is mapped to network address B. In this case, the P2P communication path A-B may be set.

Client 1 transmits the shared key to client 2 (123). The shared key is used for encrypting and / or decrypting data. The shared key may be transmitted through a P2P communication path.

In the example shown in FIG. 1A, after the speed test ends, Client 1 sends the shared key to Client 2. However, this is only an example according to an exemplary embodiment, and client 1 may simultaneously send a speed test request and a shared key to client 2. If client 1 does not receive a test response from client 2, it can resend the rate test request and the shared key to client 2 at the same time. When client 1 receives a test response from client 2, it does not send a shared key when sending an additional speed test request to client 2.

Also, in the example shown in FIG. 1A, Client 1 sends the shared key to Client 2 via a P2P communication path. However, this is merely exemplary in accordance with one embodiment. Client 1 may transmit the shared key to the server after connecting to the server, the server may transmit the shared key to the client 2. For example, client 1 may send a communication request and a shared key to a server at the same time, and the server may send a communication request and a shared key to client 2 at the same time.

Client 1 may send data 1 to client 2 (124). Here, data 1 may be encrypted with a shared key. Data 1 may be a data fragment of the entire data.

Client 2 receives data 1 and decrypts data 1 using the shared key. Although not shown in FIG. 1A, when the client 2 decrypts the data 1, the client 2 updates the decoding count information. Let n be the decoding count information _{client 2} recorded before the client 2 receives the data 1. When the client 2 decrypts the data 1, the _{client 2} may update the decryption count information _{client 2} to n + 1. Client 2 may send an acknowledgment for data 1 to client 1 (125).

When the client 1 receives the acknowledgment for the data 1, the client 1 may transmit data 2 to the client 2 (126). Data 2 may be a data fragment of the entire data and may be encrypted with a shared key, as described above.

In one embodiment, assume that client 2's network address is being changed due to client 2's movement or the like (136). If the network address of client 2 is changing, client 1 may or may not receive an acknowledgment for data 2 from client 2 later than the response time (or average response time). In this case, client 1 transmits data 2 intermediary (128). If the client 1 does not receive the acknowledgment for the data 2 within the response time confirmed in the speed test step, the client 1 may transmit the data 2 to the intermediary. In other words, since the client 1 maintains the connection with the intermediary before P2P communication, when detecting an event related to not receiving the acknowledgment for a predetermined time, the client 1 may transmit data 2 to the intermediary. Client 1 may send data 2 to the intermediary through the intermediary path.

The interceptor stores data 2 in memory when data 2 is received from client 1. The memory may include, for example, a memory corresponding to an intermediate path or a dedicated room.

When the change of the network address is completed, the client 2 may inform the server that the network address has changed (129). If the network address of client 2 is changed from B to B ', client 2 may inform the server that the network address has changed from B to B'. In other words, the server may receive change information indicating that the network address is changed from the client 2. Here, the change information may include the changed network address of the client 2. Accordingly, the server can confirm the changed network address of the client 2.

In one embodiment, the server may perform a question and answer process with Client 2 to determine if the network entity mapped to B 'is Client 2. The question and answer process will be described later with reference to FIG. 9.

In addition, when the network address of Client 2 is changed, it may be difficult to maintain a communication session with the established server before changing the network address of Client 2. In one embodiment, the server may maintain a communication session with Client 2 through a question and answer process.

Confirmation of the network entity mapped to the changed network address and maintenance of the communication session will be described later with reference to FIG. 9.

The server may inform client 1 that the network address of client 2 has changed (130). In other words, the client 1 may receive the change information of the network address from the server. Accordingly, the client 1 can confirm the changed network address of the client 2.

Client 2, whose network address is mapped to B ', connects to the intermediary with an intermediate key (131). In other words, the client 2 may attempt to connect to the intermediary by sending the intermediary key to the intermediary, and the intermediary may allow the client 2 to connect. Accordingly, the client 2 can connect to the intermediary. When the client 2 is connected with the intermediary, the intermediary may transmit data 2 to the client 2 (132). For example, client 2 can join a private room using an intermediate key. When the client 2 joins the private room, the client 2 may receive data 2 stored in a memory corresponding to the private room.

When the client 2 receives the data 2, the client 2 may decrypt the data 2 using the public key. In addition, the client 2 may update the decryption count information. In the example described above, the client 2 may update the decryption count information _{client 2} to n + 2. Client 2 may send an acknowledgment for data 2 to client 1 (133).

When the client 1 receives the acknowledgment for the data 2, the client 1 may transmit the data 3 to the client 2 (134). P2P communication path is changed from A-B to A-B '.

Data 3 can be encrypted with a shared key.

Client 2 may receive data 3 and decrypt data 3 using the shared key. Client 2 may update the decryption count information. In the example described above, the client 2 may update the decryption count information _{client 2} to n + 3. Client 2 may send an acknowledgment for data 3 to client 1 (135).

Referring to FIG. 1B, client 2 transmits data 4 to client 1 (136). Data 4 can be encrypted with a shared key.

Client 1 may receive data 4 and decrypt data 4 using the shared key. In addition, the client 1 may update its decryption number information. Assume that the decryption number information _{client 1} recorded before the client 1 receives the data 4 is m. When the client 1 decrypts the data 4, the decryption number information _client ₁ may be updated to m + 1.

Client 1 may send an acknowledgment for data 4 to client 2 (137).

Client 2 may send data 5 to client 1 (138). Here, the client 1 may change its network address due to movement. As a result, client 2 may not receive an acknowledgment for data 5 within a predetermined time. In this case, the client 2 may transmit data 5 to the intermediary (139).

Client 1 may inform the server that the network address has changed (140), and the server may inform client 2 that the network address of Client 1 has changed (141). Assume that Client 1's network address has changed from A to A '.

Client 1 can connect to the intermediary with the intermediary key (142). More specifically, the client 1 may attempt to connect to the intermediary by sending the intermediary key to the intermediary, and the intermediary may allow the client 1 to connect.

If the connection unit is connected to the client 1 mapped to the changed network address, the intermediate unit may transmit data 5 to the client 1 (143).

Client 1 can receive data five. Here, data 5 may be encrypted with a shared key. Client 1 can decrypt data 5 with the shared key and update the decryption number information. In the example described above, the decryption count information _client ₁ may be updated to m + 2.

Client 1 may send an acknowledgment for data 5 to client 2 (144).

In the example shown in FIGS. 1A-1B, data 1-3 are transmitted to client 2 via a mobile operator's switchboard equipment (eg, a device that determines a Quality of Service (QoS) or Service Level Agreement (SLA)). It doesn't work. Similarly, data 4 through 5 are not transmitted to Client 1 through the mobile operator's switchboard equipment. In this case, charging for data 1 to 5 may be difficult. Accordingly, as described above, the client 1 and the client 2 may update the decryption number information each time the received data is decrypted. The decryption count information is information related to data usage, and is information that is the basis for billing. The client 1 and the client 2 may transmit the decryption number information to the server according to a predetermined cycle so that charging for data usage may be performed. For example, Client 1 and Client 2 may transmit their decryption count information to the server once a day, once a week, or once a month. In addition, when the P2P communication ends, the client 1 and the client 2 may transmit the decryption number information to the server.

Client 1 and Client 2 may encrypt the decryption number information and transmit it to the server.

In one embodiment, the server may determine the data usage of each of the client 1 and the client 2 based on the number of decryption information, and transmit the data usage of each of the client 1 and the client 2 to the billing system. The billing system may generate billing information and transmit it to the server. In another embodiment, the server may generate the charging information based on the decoding count information.

Decryption number information related to the data usage of the P2P communication of the client 1 and the client 2 may be transmitted to the server, so that charging for the data usage of the P2P communication of the client 1 and the client 2 may be performed.

Referring to FIG. 2, the communication system includes a client 1, a server, and a client 2. The intermediate unit described with reference to FIG. 1 may be included in the server.

Client 1 may send a communication request to the server (210). For example, the communication request may be a P2P communication request. The server may send a communication request from client 1 to client 2 (211).

Upon receiving the communication request from the client 1, the client 2 may connect with the server (212). In other words, client 2 can connect to the server.

When the client 2 connects, the server may generate an intermediate key (213). The server may send the intermediate key to client 2 (214).

The server may send the intermediate key and the network address of client 2 to client 1 (215). Here, let's say client 1's network address is A and client 2's network address is B.

Client 1 may transmit the intermediate key to the server (216). The server receiving the intermediate key may secure an intermediate path corresponding to the intermediate key (217).

If the intermediate path is secured, client 1 may send a speed test request to client 2 (218), and client 2 may send a test response to the speed test request to client 1 (219). Client 1 can check the response speed of Client 2. Similarly, client 2 may send a speed test request to client 1 (220) and may send a test response to client 2 driving speed test request to client 2 (221).

A P2P communication path may be established between client 1 and client 2.

Client 1 sends the shared key to client 2 (222).

Client 1 may encrypt data 1 with a shared key and transmit encrypted data 1 to client 2 (223). Client 2 receives the encrypted data 1 and decrypts the encrypted data 1 using the shared key. Client 2 updates the decryption count information. Client 2 may send an acknowledgment to client 1 (224).

When the client 1 receives the acknowledgment for the data 1, the client 1 may encrypt the data 2 with the shared key and transmit the encrypted data 2 to the client 2 (225). Here, when the network address of the client 2 is being changed (235), the response speed of the client 2 may be lower than the response speed confirmed in the speed test or there may be no response from the client 2.

Client 1 may or may not receive an acknowledgment for encrypted data 2 later than the response rate identified in the rate test. In this case, the client 1 may transmit the encrypted data 2 to the server through the intermediate path (227). The server may store encrypted data 2 in a memory corresponding to each path or dedicated room.

If the network address of client 2 is changed from B to B ', client 2 may inform the server that the network address has changed (228). The server may inform client 1 that the network address of client 2 has changed (229).

Since the client 2 has an intermediate key, the client 2 can connect to the server using the intermediate key (230). The server may send the encrypted data 2 to the client 2 (231). Client 2 may receive the encrypted data 2 and decrypt it using the shared key. In addition, the client 2 may update the decryption count information.

Client 2 may send an acknowledgment to client 1 (232).

When the client 1 receives the acknowledgment for the data 2, the client 1 may transmit data 3 encrypted with the shared key to the client 2 (233). P2P communication through the P2P communication path A-B 'is started. When the client 2 receives the data 3, the client 2 may decrypt the data 3 with the shared key, and update the decryption number information. Client 2 may send an acknowledgment for data 3 to client 1 (234).

Although not shown in FIG. 2, the client 2 may transmit data encrypted with the shared key to the client 1, and the client 1 may decrypt the encrypted data using the shared key. Client 1 may update the decoding count information.

The matters described with reference to FIGS. 1A to 1B may be applied to the matters described with reference to FIG. 2, and thus detailed descriptions thereof will be omitted.

Referring to FIG. 3A, the client 310 includes a connector 311 and the client 320 includes a connector 321. The server 330 includes a detector 331, a manager 332, and an intermediary 333.

The connection unit 311 and the connection unit 321 may include a communication interface capable of P2P communication.

The client 310 may further include a processor (not shown) and a memory (not shown).

The processor may control the connection unit 311, and the memory may store intermediate keys. Depending on the implementation, the intermediate key may be stored in a secure call dongle which will be described later.

The client 320 may further include a processor (not shown) and a memory (not shown). The processor controls the connection unit 321, and the memory may store intermediate keys. Depending on the implementation, the intermediate key may be stored in a secure call dongle which will be described later.

The detector 331, the manager 332, and the intermediary 333 may be implemented by a processor or a controller.

The connection unit 311 may transmit a P2P communication request to the server 330, and the server 330 may transmit a P2P communication request to the connection unit 321. When the connection unit 321 receives the P2P communication request, the connection unit 321 may access the intermediate unit 333. The intermediate unit 333 may generate an intermediate key when the connection unit 321 connects. The intermediary unit 333 may transmit the intermediary key to the connection unit 321. Here, the connection unit 321 may maintain a connection with the intermediate unit 333.

The connection unit 321 may transmit the intermediate key to the management unit 332, and the management unit 332 may transmit the intermediate key and the network address of the counterpart client 330 to the connection unit 311. The connection unit 311 may transmit the intermediate key to the intermediate unit 333 and may be connected to the intermediate unit 333 using the intermediate key. Herein, the connection part 311 may maintain a connection with the intermediate part 333.

Each of the connection portion 311 and the connection portion 321 can maintain a connection to the intermediate portion 333 so that the intermediate path (or bypass path) having a connection relationship between the connection portion 311-the mediation 333-the connection portion 321 can be obtained. Can be secured. Each path is a direct path between the connection part 311 and the connection part 321, that is, a path for preparing for disconnection of the P2P communication path. In addition, since the intermediate path corresponds to the intermediate key, the client 310 and the client 320 having the intermediate key can use the intermediate path, and other clients cannot use the intermediate path.

When the intermediate path is secured, the connection part 311 and the connection part 321 may be connected through a direct path. For example, when a network address of the client 310 is called A and a network address of the client 320 is called B, the connection part 311 and the connection part 321 may be connected to each other through a P2P communication path A-B.

Client 310 and client 320 may share a shared key.

The client 310 may receive data encrypted with the shared key from the client 320 and decrypt the data using the shared key. The client 310 may update the decryption count information whenever decrypting. Similarly, the client 320 may receive data encrypted with the shared key from the client 310 and decrypt it using the shared key. The client 320 may update the decryption count information whenever decrypting.

The decryption number information of the client 310 may be encrypted and recorded in a memory and / or a secure call dongle which will be described later. Similarly, the decryption number information of the client 320 may be encrypted and recorded in a memory and / or a secure call dongle.

In one embodiment, the network address of the client 320 may be changing. In this case, the P2P communication path A-B may be disconnected, and the connection unit 321 may not receive data transmitted by the connection unit 311. Data may be missing. As a result, the connection unit 311 may not receive an acknowledgment for the data. The connection unit 311 may transmit data to the intermediate unit 333.

When the network address of the client 320 is changed from B to B ', the connection unit 321 may inform the sensing unit 331 that the network address of the client 320 has been changed. The sensing unit 331 may inform the management unit 332 that the network address of the client 320 has changed, and the management unit 332 may inform the connection unit 311 that the network address of the client 320 has changed.

The connection of the connection unit 321 to the intermediary unit 333 may be lost due to the change of the network address of the client 320. The connection unit 321 may attempt to reconnect to the intermediate unit 333 by transmitting the intermediate key to the intermediate unit 333. Since the intermediate unit 333 has received the intermediate key corresponding to the client 320, the intermediate unit 333 may allow reconnection. When the connection unit 321 reconnects to the intermediate unit 333, the connection unit 321 may receive data from the intermediate unit 333.

The connector 321 may transmit an acknowledgment for data to the connector 311.

The matters described with reference to FIGS. 1A through 2 may be applied to FIG. 3A, and thus a detailed description thereof will be omitted.

Referring to FIG. 3B, the intermediary 333 may be physically distinguished from the server 330. In addition, the intermediary unit 333 may be an independent device in the network.

The matters described with reference to FIGS. 1 to 3A may be applied to FIG. 3B, and thus detailed descriptions thereof will be omitted.

4, the client is mapped to network address A, and the counterpart client is mapped to network address B. Client and counterpart client communicate through P2P communication path A-B.

The client may transmit data 1 to the counterpart client 410, and the counterpart client may transmit an acknowledgment for data 1 to the client 411.

The network address of the counterpart client may be changed from B to B '(420). The counterpart client may inform the server that its network address has changed (421), and the server may inform the client that the network address of the counterpart client has changed (422). Accordingly, the client may transmit data 2 to the counterpart client mapped to the network address B '(423). That is, the client may transmit data 2 to the counterpart client through the P2P communication path A-B '. The counterpart client may send an acknowledgment for data 2 to the client (424). Upon receiving the acknowledgment for data 2, the client may transmit data 3 to the counterpart client (425).

The network address of the counterpart client may be changed from B 'to B "(430). In this case, the client may not receive an acknowledgment for data 3 from the counterpart client or may receive it late. If it is slow, the client may send data 3 intermediary 431. The counterpart client may inform the server that the network address has changed (432), and the server can inform the client that the client's network address has changed. There is (433).

Since the partner client has an intermediate key, the partner client can access the intermediate unit using the intermediate key (434). When the partner client accesses the intermediary, the intermediary may transmit data 3 to the counterpart client (435). The counterpart client may send an acknowledgment for data 3 to the client (436). The client may then transmit data to the counterpart client via the P2P communication path A-B ".

If the IP address of client 2 is changed, the P2P communication path is disconnected, so that client 1 and client 2 cannot maintain P2P communication continuously. According to an embodiment, before the P2P communication, since the intermediate path is secured, even if the P2P communication path is disconnected, the client 1 and the client 2 may transmit and receive data with the intermediate unit by temporarily communicating with the intermediate unit. As a result, data loss can be prevented. In addition, network throughput may be improved.

The matters described with reference to FIGS. 1A through 3B may be applied to the matters described with reference to FIG. 4, and thus detailed descriptions thereof will be omitted.

The communication device according to an embodiment may correspond to the intermediate unit described above.

Referring to FIG. 5, the communication device generates an intermediate key corresponding to peer to peer (P2P) communication between a client and a counterpart client (510).

The communication device transmits the intermediate key to the counterpart client (520).

The communication device secures an intermediate path corresponding to the intermediate key (530).

The communication device receives data through the intermediary path from the client whose network address of the counterpart client has changed and fails to receive an acknowledgment for the data sent to the counterpart client (540). In other words, when the client transmits data to the counterpart client, but the network address of the counterpart client changes and the client does not receive an acknowledgment of the data from the counterpart client, the client may transmit the data to the communication device.

When the counterpart client accesses the changed network address using the intermediate key, the communication device transmits data to the counterpart client (550).

1A to 4 may apply to the matters described with reference to FIG. 5, and thus detailed descriptions thereof will be omitted.

Referring to FIG. 6, the server receives a P2P communication request from the client and transmits the P2P communication request to the counterpart client (610).

When the other client connects, the server generates an intermediate key and transmits the intermediate key to the other client and the client (620).

The server receives the intermediate key from the client to secure the intermediate path corresponding to the intermediate key (630).

Since the network address of the counterpart client is changed, the server receives the data through the intermediate path from the client that has not received the acknowledgment for the data transmitted to the counterpart client (640).

When the counterpart client reconnects to the changed network address using the intermediate key, the server transmits data to the counterpart client (650).

1A to 4 may be applied to the matters described with reference to FIG. 6, and thus detailed descriptions thereof will be omitted.

Referring to FIG. 7, the client transmits a P2P communication request to the server (710).

The client receives 720 from the server an intermediate key generated by the communication mediator for mediating communication between the client itself and the counterpart client and the network address of the counterpart client. The communication mediator may correspond to the mediator described above.

The client connects to the communication media device using the media key (730).

The client transmits data to the counterpart client using the network address (740).

If the network address of the counterpart client is changed and the client does not receive an acknowledgment for the data transmitted to the counterpart client, the data is transmitted to the communication mediator (750). The counterpart client connects to the communication mediator using the media key with the changed network address and receives data from the communication mediator.

The client receives an acknowledgment for data from the counterpart client (760).

1A to 4 may be applied to the matters described with reference to FIG. 7, and thus detailed description thereof will be omitted.

The client described with reference to FIG. 8 may correspond to client 2 of FIGS. 1A to 2.

Referring to FIG. 8, when a client receives a P2P communication request of a requesting client from a server, the client accesses a communication medium device (810). The requesting client may correspond to client 1 of FIGS. 1A-2.

The client receives an intermediate key from the communication intermediate device (820). The communication mediator may correspond to the mediator described above.

If the network address of the client is changed, the client reconnects to the communication media device using the media key (830).

If the network address of the client has changed, the requesting client does not receive an acknowledgment for the data sent to the client. In this case, the requesting client transmits data to the communication medium device. Communication mediated devices store data.

The client receives the data from the communication mediating device (840).

The client sends an acknowledgment for the data to the requesting client (850).

1A to 4 may apply to the matters described with reference to FIG. 8, and thus detailed descriptions thereof will be omitted.

Referring to FIG. 9, the client 910 connects to the server 911 (920). In step 920, the connection of the client 910 may be the initial connection. The server 911 may receive identification information of the client 910 from the client 910, and may check a time value. Here, the time value may represent the time that the client 910 accesses the server 911.

The server 911 may encrypt the identification information and the time value of the client 910 using its E _server {}. For example, the server 911 may encrypt the identification information and the time value of the client 910 using the session key.

The server 911 may transmit a question to the client 910 (921). The questions can be generated randomly. For example, the server 911 may transmit the encrypted identification information and the time value, that is, the E _server {identification information, time value}, to the client 910 as a query. That is, the client 910 may receive the E _server {identification information, time value} from the server 911.

When the client 910 receives the question from the server 911, the client 910 may transmit an answer to the server 911 (922). For example, the client 910 may encrypt the E _server {identification information, time value} using E _client {}, which is its encryption method, and the E _client {E _server {identification information, time value}}. In response, it may transmit to the server 911.

Server 911 may extract or acquire {E _server identification information, the time value is generated from the _client E {{E _server identification information, the time value}} via the decoding corresponding to the _client E {}. In addition, the server 911 may extract or obtain identification information and time value by decoding the E _server {identification information, time value}.

The server 911 may check whether the answer corresponds to the question (923). For example, the server 911 may check whether the identification information and the time value obtained from the E _client {E _server {identification information, time value}} correspond to the identification information and the confirmed time value received in step 910. have.

If the answer corresponds to the question, server 911 may maintain a communication session with client 910 (924). The session can be, for example, a UDP session. If the answer does not correspond to the question, the server 911 may send a reconnection request to the client 910 (925).

In a state in which a session between the client 910 and the server 911 is maintained, the client 910 may transmit a P2P communication request to the server 911. With the session maintained between the client 910 and the server 911, the client 910 may execute step 110 of FIG. 1A or step 210 of FIG. 2.

The session maintenance described with reference to FIG. 9 may be applied to the client 2 and the server described with reference to FIG. 1. More specifically, in step 129 of FIG. 1, client 2 may connect to the server to inform the server that the network address has changed, and send its identification information to the server. Here, the server receives the identification information of the client 2 from a third party mapped to a network address different from that of the client 2 already known. In other words, the server does not know exactly whether the third party is Client 2 or a hacker. The server can send the E _server {client 2's identification information, time value} to the third party as a question, and the E _client ₂ {E _server {identification information of client 2, time value}} can be received as an answer. The server uses the decryption technique corresponding to E _client ₂ {} and the decryption technique corresponding to E _server {} to identify and time client 2's identification information from E _client ₂ {E _server {identification information, time value}} of E client 2. You can extract the value. That is, the answer corresponds to the question. The server may confirm that the third is Client 2 and maintain a session with Client 2. In step 130, the server may inform that Client 2's network address has changed. In other words, the server can inform Client 1 that Client 2 has been mapped to a different network address.

According to another embodiment, a session identifier may be used to maintain a communication session. More specifically, when receiving a P2P communication request from the client 910, the server 911 may assign a session identifier to the client 910. The session identifier can be used to identify the client 910 on the network. The session identifier may be included in a header of a transmission unit of the client 910 (eg, a packet that the client 910 exchanges with the server 911, an intermediary, or a counterpart client). Even when the network address of the client 910 is changed, when the server 911 receives a transmission unit including a session identifier, the server 911 may maintain a communication session with the client 910.

1A to 8 may apply to the matters described with reference to FIG. 9, and thus a detailed description thereof will be omitted. In addition, the matters described with reference to FIG. 9 may be applied to the matters described with reference to FIGS. 1A through 8.

Referring to FIG. 10A, a flowchart of a method of operating a client is shown.

The client establishes a P2P communication path with the counterpart client (1010).

The client transmits the shared key to the counterpart client (1020).

The client receives the data encrypted with the shared key through the P2P communication path (1030).

The client decrypts the encrypted data using the shared key (1040).

When the client decrypts the data, the client updates the decryption number information related to charging for the data usage of the client (1050).

The client may transmit the updated decryption number information to the server.

In one embodiment, the server may determine the data usage based on the updated number of decryption information. For example, the server may determine the data usage of the client by referring to a table in which a correspondence relationship between the number of decryption information and the data usage is recorded. The server can send the data usage to the charging system. The billing system may generate billing information using the data usage.

In another embodiment, the server may generate the charging information based on the updated number of decryption information. For example, the server may generate charging information by referring to a table in which a correspondence relationship between decryption number information and charging information is recorded.

The server and / or billing system may check whether the data usage of the client exceeds a predetermined usage. The predetermined usage amount may be a data quota corresponding to a communication plan subscribed to by a user of the client. That is, the predetermined usage amount may be a data quota allocated to the client. The server and / or the billing system may generate guide information on data usage based on the verification result information. The server and / or billing system may send the guide information to the client.

The guide information includes excess information indicating whether the data usage of the client has exceeded the predetermined usage, remaining information indicating available data capacity excluding the data usage among the predetermined usage, and bandwidth and quality for P2P communication. It may include at least one of the restriction information indicating whether there is a restriction on at least one of. For example, a predetermined usage amount is 2 GB (gigabyte) and data usage is 1 GB. The guide information may include remaining amount information indicating that 1 GB of data capacity remains. In addition, the guide information may include excess information indicating that data usage does not exceed a predetermined usage amount and / or restriction information indicating that bandwidth and quality for P2P communication are not limited. As another example, assume that the predetermined usage amount is 2 GB and the usage information is 2.5 GB. The guide information may include excess information indicating that the usage information has exceeded a predetermined usage amount, remaining information indicating that there is no available data capacity, and restriction information indicating that there is a limitation on at least one of bandwidth and quality for P2P communication. have. In addition, the guide information may include information that 0.5GB, which is a data usage exceeding a predetermined usage amount, will be additionally charged.

The client can visually display the guide information on the display.

In an embodiment, the client may transmit a request for providing guide information to the server based on the user's input information, and the server may transmit the guide information to the client.

In one embodiment, a client may share its assigned data quota with at least one other client. For example, assume that the data quota allocated to clients is 5GB. Clients can share 5GB of data quota with other clients. In other words, a client may form a shared group to share its data quota with shared clients in the shared group. The client may receive information related to the data usage of the shared client from the server and / or the shared client, and update the decryption number information of the client based on the received information. The received information may include, for example, updated decryption number information each time the shared client decrypts the encrypted data received through the P2P communication.

1A to 9 may apply to the matters described with reference to FIG. 10A, and thus detailed descriptions thereof will be omitted.

Referring to FIG. 10B, the client 1 sets up a P2P communication path with each of the clients 2 to 4 and receives data through each P2P communication path. More specifically, client 1 receives data a encrypted with shared key 1 from client 2, receives data b encrypted with shared key 2 from client 3, and receives data c encrypted with shared key 3 from client 4 do. Each of the shared keys 1 to 3 may be identical to each other. Alternatively, the shared keys 1 to 3 may each be different. Alternatively, the shared keys 1 and 2 may be identical to each other and may be different from the shared key 3.

Client 1 can decrypt data a using shared key 1 and update decryption number information. Client 1 can decrypt data b using shared key 2 and update the decryption count information. Similarly, the client 1 can decrypt the data c using the shared key 3 and update the decryption number information. Assume that the decoding number information _{client 1} recorded before the _{client 1} performs P2P communication with each of the clients 2 to 4 is n. The decryption count information _client ₁ may be updated to n + 3.

The decryption count information may be information related to billing for data usage or data usage of the client 1. For charging, the client 1 may transmit its decryption number information to the server.

The matters described with reference to FIGS. 1A through 10A may be applied to the matters described with reference to FIG. 10B, and thus detailed descriptions thereof will be omitted.

Referring to FIG. 11, the client 1110 may share its data quota with a sharing client in the sharing group 1120.

The sharing group 1120 may be formed based on the identifier. More specifically, an identifier is assigned to communication software that enables P2P communication of the client 1110. Communication software that enables P2P communication of

clients

1121 and 1122 is assigned an identifier.

Client 1121 and client 1122 may display on the display a visual code (eg, a QR code) for registering client 1110 as a parent or master. Each QR code may be, for example, an encoded key corresponding to each of client 1121 and client 1122.

The client 1110 may capture the visual code via optical means (eg, a camera) and extract a key from the captured QR code. The client 1110 may send its identifier and key to the server, and the server may verify that the key is valid. For example, the server can check whether the number of available keys is zero. If the key is valid, the server may manage the client 1110 as the master or parent of the client 1121 and the client 1122, and the client 1121 and the client 1122 as slaves of the client 1110. Or it can be managed as a child. The identifiers of the client 1121 and the client 1122 may be managed by grouping with the identifiers of the client 1110.

The server may also update the number of times the key is available.

In the example shown in FIG. 11, client 1110 is a master and

clients

1121 and 1122 are slaves.

Clients

1121 and 1122 may be defined as shared clients that can share the data quota assigned to client 1110.

The sharing

clients

1121 and 1122 may receive the encrypted data by performing P2P communication. The shared

clients

1121 and 1122 may decrypt data using the shared key shared with the other party, and update the decryption number information. When the P2P communication is terminated, the shared

clients

1121 and 1122 may transmit the decryption number information to the server and / or the client 1110. The client 1110 may receive information related to data usage of the shared

clients

1121 and 1122, and may update its decryption number information based on the received information. For example, it is assumed that decryption number information of each of the shared client 1121 and the shared client 1122 is 100 and 200, respectively. The client 1110 may receive decryption number information of the shared

clients

1121 and 1122, and may add 300 to its decryption number information.

The matters described with reference to FIGS. 1 through 10B may be applied to the matters described with reference to FIG. 11, and thus detailed descriptions thereof will be omitted.

Referring to FIG. 12, the client 1200 includes a communication interface 1210 and a controller 1220. In addition, the client 1200 includes a memory (not shown). The memory stores communication software, and the controller 1220 executes the communication software.

As the communication software is executed, an operation of the communication interface 1210 and an operation of the controller 12720 may be performed. For example, the communication interface 1210 establishes a peer to peer (P2P) communication path with a counterpart client. The communication interface 1210 transmits a shared key to the counterpart client, and receives data encrypted with the shared key through a P2P communication path. The controller 1220 decrypts the encrypted data using the shared key. When the controller 1220 decrypts the data, the controller 1220 updates decryption number information related to data usage of the client. Billing-based information can be generated via communication software.

The decryption number information may be stored in a memory and / or a secure call dongle.

1 to 11 may be applied to the items described with reference to FIG. 12, and thus detailed descriptions thereof will be omitted.

Referring to FIG. 13, an example of a client 1300 and a secure call dongle 1310 is shown.

The secure call dongle 1310 may be detachable from the input / output interface of the client 1300. Input and output interfaces include a micro USB port and an Apple® Lightning port. In addition, the secure call dongle 1310 may be designed to be compatible with various input / output interfaces developed in the future.

The secure call dongle 1310 and the client 1300 may be connected through short-range wireless communication without physical contact. Short-range wireless communication is, for example, Bluetooth, NFC, or Wi-Fi. Near field communication is not limited to the above-described example.

The secure call dongle 1310 may include a certain amount of memory. The memory may store communication software, a call history through the communication software, a messaging history, a message content, an attached file, and the like.

The secure call dongle 1310 may include a battery of a predetermined capacity. When the battery of the client 1300 is low, the secure call dongle 1310 may supply power to the client 1300 to allow a call for a predetermined time or more. Here, when the secure call dongle 1310 is connected to the client 1300 without physical contact, the secure call dongle 810 may wirelessly transmit power to the client 1300.

When the secure call dongle 1310 is connected with the client 1300, communication software may be visually displayed on the display of the client 1300. As another example, when the secure call dongle 1310 is connected with the client 1300, communication software may be executed.

A secure call dongle 1310 may be distributed that includes a memory in which an identifier corresponding to the communication software is stored. When communication software is installed in the client 1300 and the secure call dongle 1310 is connected to the client 1300, an identifier required for the secure call may be allocated to the communication software.

The secure call dongle 1310 may store decryption number information of the client 1300. For example, while the secure call dongle 1310 is connected with the client 1300, the client 1300 may receive the encrypted data by performing P2P communication, and update the decryption count information each time the data is decrypted. The secure call dongle 1310 may be stored.

The secure call dongle 1310 may store messages and / or contents transmitted and received through a chat room. Attributes are defined in data such as messages and / or content, so the data may or may not be moved out of the secure call dongle 1310. When an event occurs for data stored in the secure call dongle 1310, the user may need to obtain permission from the original owner of the data to perform the event. For example, the client 1300 may transmit a file stored in the secure call dongle 1310 to the outside only by obtaining a movement permission for the file from the original owner (or security manager) of the file. If the file is stored in the secure call dongle 1310, it may mean that an assigned identifier (where the identifier is an identifier assigned to the file) is recorded on the server, and the client 1300 indicates that the file is stored externally. A message may be sent to the original owner (or security manager) 's client that it will be sent or moved. If the original owner (or security administrator) approves the transfer or movement of the file, the properties of the file may be overridden or modified. Accordingly, the file may be transmitted or moved outside the secure call dongle 1310.

The apparatus described above may be implemented as a hardware component, a software component, and / or a combination of hardware components and software components. For example, the devices and components described in the embodiments are, for example, processors, controllers, arithmetic logic units (ALUs), digital signal processors, microcomputers, field programmable gate arrays (FPGAs). Can be implemented using one or more general purpose or special purpose computers, such as a programmable logic unit (PLU), a microprocessor, or any other device capable of executing and responding to instructions. The processing device may execute an operating system (OS) and one or more software applications running on the operating system. The processing device may also access, store, manipulate, process, and generate data in response to the execution of the software. For convenience of explanation, one processing device may be described as being used, but one of ordinary skill in the art will appreciate that the processing device includes a plurality of processing elements and / or a plurality of types of processing elements. It can be seen that it may include. For example, the processing device may include a plurality of processors or one processor and one controller. In addition, other processing configurations are possible, such as parallel processors.

The software may include a computer program, code, instructions, or a combination of one or more of the above, and configure the processing device to operate as desired, or process it independently or collectively. You can command the device. Software and / or data may be any type of machine, component, physical device, virtual equipment, computer storage medium or device in order to be interpreted by or to provide instructions or data to the processing device. Or may be permanently or temporarily embodied in a signal wave to be transmitted. The software may be distributed over networked computer systems so that they may be stored or executed in a distributed manner. Software and data may be stored on one or more computer readable recording media.

The method according to the embodiment may be embodied in the form of program instructions that can be executed by various computer means and recorded in a computer readable medium. The computer readable medium may include program instructions, data files, data structures, etc. alone or in combination. The program instructions recorded on the media may be those specially designed and constructed for the purposes of the embodiments, or they may be of the kind well-known and available to those having skill in the computer software arts. Examples of computer-readable recording media include magnetic media such as hard disks, floppy disks, and magnetic tape, optical media such as CD-ROMs, DVDs, and magnetic disks, such as floppy disks. Magneto-optical media, and hardware devices specifically configured to store and execute program instructions, such as ROM, RAM, flash memory, and the like. Examples of program instructions include not only machine code generated by a compiler, but also high-level language code that can be executed by a computer using an interpreter or the like. The hardware device described above may be configured to operate as one or more software modules to perform the operations of the embodiments, and vice versa.

Although the embodiments have been described by the limited embodiments and the drawings as described above, various modifications and variations are possible to those skilled in the art from the above description. For example, the described techniques may be performed in a different order than the described method, and / or components of the described systems, structures, devices, circuits, etc. may be combined or combined in a different form than the described method, or other components. Or even if replaced or substituted by equivalents, an appropriate result can be achieved.

Therefore, other implementations, other embodiments, and equivalents to the claims are within the scope of the following claims.

Claims

Generating an intermediate key corresponding to peer-to-peer communication between the client and the counterpart client;

Transmitting the intermediate key to the counterpart client;

Securing an intermediate path corresponding to the intermediate key;

Receiving the data through the intermediary path from the client whose network address of the counterpart client has been changed and has not received an acknowledgment for the data sent to the counterpart client; And

Transmitting the data to the counterpart client when the counterpart client connects using the intermediate key;

Including,

Method of operation of a communication device.
The method of claim 1,

Generating the intermediate key,

Generating the intermediate key when connected to the counterpart client that has received the client's P2P communication request from the server;

Including,

Method of operation of a communication device.
The method of claim 2,

The server,

Receiving the intermediate key from the counterpart client, transmitting the intermediate key to the client,

Securing the intermediate path,

If the media key is received from the client, securing the media path

Including,

Method of operation of a communication device.
The method of claim 3,

The intermediate route is,

A dedicated room of the client holding the median key and the counterpart client;

Method of operation of a communication device.
The method of claim 3,

The step of transmitting the data to the counterpart client,

Receiving a connection request including the intermediate key from the counterpart client having the changed network address; And

Allowing access according to the access request based on the intermediate key

Including,

Method of operation of a communication device.
The method of claim 1,

The intermediate key is

Corresponding to an arbitrary value or generated based on unique information of the client and the counterpart client,

Method of operation of a communication device.
The method of claim 1,

The client receives an acknowledgment for the data received by the counterpart client from the communication device, and subsequently transmits the data to the changed network address of the counterpart client.

Method of operation of a communication device.
In the operation method of the server,

Receiving a P2P communication request from a client and transmitting the P2P communication request to a counterpart client;

When the counterpart client accesses the server, generating an intermediate key and transmitting the intermediate key to the counterpart client and the client;

Receiving the intermediate key from the client to secure an intermediate path-mediated path corresponding to the intermediate key;

Receiving the data through the intermediary path from the client whose network address of the counterpart client has been changed and has not received an acknowledgment for the data sent to the counterpart client; And

Transmitting the data to the counterpart client when the counterpart client reconnects using the intermediate key;

Including,

How the server works.
The method of claim 8,

The intermediate route is,

A dedicated room of the client holding the median key and the counterpart client;

How the server works.
The method of claim 8,

The step of transmitting the data to the counterpart client,

Receiving a reconnection request including the intermediate key from the counterpart client having the changed network address; And

Allowing access according to the reconnection request based on the intermediate key

Including,

How the server works.
The method of claim 8,

Receiving an address change notification from the counterpart client when the network address of the counterpart client changes; And

Notifying the client of the change of the network address

Further comprising,

How the server works.
The method of claim 8,

The intermediate key is

Corresponding to an arbitrary value or generated based on unique information of the client and the counterpart client,

How the server works.
The method of claim 8,

The client receives an acknowledgment for the data received by the counterpart client, and subsequently transmits data to the changed network address of the counterpart client.

How the server works.
The method of claim 8,

Assigning a session identifier of the client to the client when receiving a P2P communication request from the client

Further comprising,

How the server works.
The method of claim 8,

Sending a randomly generated question to the client that connected before receiving the P2P communication request;

Receiving an answer from the client; And

Confirming that the answer corresponds to the question

Further comprising,

How the server works.
The method of claim 15,

Sending the question,

Transmitting the first cipher information generated by encrypting the identification information received from the client and the access time information of the client, to the question.

Including,

Receiving the answer,

Receiving, as the answer, second cryptographic information generated by encrypting the first cryptographic information.

Including,

Checking whether the answer corresponds to the question,

Verifying whether the extracted extracted information corresponding to the identification information and the access time information is decrypted by decrypting the second cryptographic information;

Including,

How the server works.
In the operation method of the client,

Sending a P2P communication request to a server;

Receiving, from the server, a media key generated by a communication mediator for mediating communication between the client and the counterpart client and a network address of the counterpart client;

Connecting with the communication media device using the media key;

Transmitting data to the counterpart client using the network address;

Transmitting the data to the communication medium device when the network address is changed and the acknowledgment of the data transmitted to the counterpart client is not received.

Including,

The counterpart client connects to the communication media device using the media key and receives the data from the communication media device.

How the client works.
The method of claim 17,

When connected with the communication medium device, a medium path corresponding to the medium key is secured,

How the client works.
The method of claim 18,

The intermediate route is,

A dedicated room of the client holding the median key and the counterpart client;

How the client works.
The method of claim 17,

Receiving a notification from the server that the network address has changed

Further comprising,

How the client works.
The method of claim 17,

Receiving, by the counterpart client, an acknowledgment for data received from the communication medium device from the counterpart client;

Further comprising,

How the client works.
The method of claim 17,

Generating the P2P communication path,

Sending a rate test request to the counterpart client;

Receiving a test response to the speed test request from the counterpart client; And

Confirming a response time of the counterpart client based on the test response

Including,

How the client works.
The method of claim 22,

The step of transmitting the data,

If the acknowledgment is not received within the response time, transmitting the data to the communication medium device;

Including,

How the client works.
The method of claim 17,

Accessing the server and receiving a randomly generated question from the server prior to sending the P2P communication request; And

Sending an answer to the server

Further comprising,

How the client works.
The method of claim 24,

Receiving the question,

Transmitting identification information of the client to the server; And

Receiving the first encryption information generated by encrypting the identification information and the access time information of the client as the question

Including,

The step of transmitting the answer,

Transmitting second encryption information generated by encrypting the first encryption information as the answer.

Including,

How the client works.
In the operation method of the client,

If a P2P communication request of the requesting client is received from the server, accessing the communication medium device;

Receiving an intermediate key from the communication intermediate device;

Reconnecting to the communication media device using the media key when the network address of the client is changed;

Receiving the data from the communication medium device, receiving the data from the requesting client that has not received an acknowledgment for the data sent to the client; And

Sending an acknowledgment for the data to the requesting client

Including,

How the client works.
A controller for generating an intermediate key corresponding to peer-to-peer communication between the client and the counterpart client, and for securing an intermediate path corresponding to the intermediate key; And

The media key is transmitted to the counterpart client, the network address of the counterpart client is changed, and the data is received through the intermediary path from the client that has not received an acknowledgment for the data transmitted to the counterpart client. A communication unit for transmitting the data to the counterpart client when the counterpart client connects using the intermediate key;

Including,

Communication device.
For the client,

Sends a P2P communication request to a server, receives a media key generated by a communication mediator for mediating communication between the client and the counterpart client and a network address of the counterpart client from the server, and uses the intermediary key to communicate Connecting to an intermediate device, transmitting data to the counterpart client using the network address, and when the network address is changed to receive an acknowledgment for the data transmitted to the counterpart client, the data is transmitted to the counterpart client. A connection for transmitting to the intermediate device; And

Processor for controlling the connection

Including,

The counterpart client connects to the communication media device using the media key and receives the data from the communication media device.

Client.
For the client,

When receiving the P2P communication request of the requesting client from the server, access the communication medium device, receive the medium key from the communication medium device, if the network address of the client is changed, the communication medium device using the medium key Reconnecting to the communication medium device, the communication medium device receiving the data from the requesting client that has not received an acknowledgment for the data sent to the client and receiving the data; A connection unit transmitting an acknowledgment for the data to the user; And

Processor for controlling the connection

Including,

Client.
Establishing a peer to peer communication path with a counterpart client;

Transmitting a shared key to the counterpart client;

Receiving data encrypted with the shared key through the P2P communication path;

Decrypting the encrypted data using the shared key; And

If the data is decrypted, updating decryption number information related to data usage of the client;

Including,

How the client works.
The method of claim 30,

Transmitting the updated decryption number information to the server: And

Receiving guide information on the data usage from the server

Further comprising,

How the client works.
The method of claim 31, wherein

The guide information,

Excess information indicating whether the data usage amount exceeds a predetermined usage amount;

Remaining information indicating available data capacity excluding the data usage amount among the predetermined usage amounts; And

Restriction information indicating whether there is a restriction on at least one of bandwidth and quality for P2P communication of the client

Including at least one of,

How the client works.
The method of claim 30,

Receiving information related to data usage of a shared client sharing a data quota assigned to the client; And

Updating the decryption number information based on the received information.

Further comprising,

How the client works.
The method of claim 33, wherein

The received information is,

Updated decryption number information each time the shared client decrypts the encrypted data received through the P2P communication

Including,

How the client works.
The method of claim 30,

If the network address of the client changes, transmitting change information indicating that the network address of the client changes to a server;

Accessing a communication mediation device that secures an intermediate path corresponding to the P2P communication path; And

Receiving other data encrypted with the shared key of the counterpart client from the communication medium device;

More,

The counterpart client,

If the acknowledgment for the other data sent to the client is not received from the client, to transmit the other data to the communication medium device,

How the client works.
36. The method of claim 35 wherein

Updating the decryption number information when the other data is decrypted with the shared key.

Further comprising,

How the client works.
The method of claim 30,

Setting the P2P communication path,

Sending a P2P communication request to a server;

Receiving, from the server, a media key generated by a communication mediator for mediating communication between the client and the counterpart client and a network address of the counterpart client;

Accessing the communication media device using the media key; And

Establishing a P2P communication path with the counterpart client based on the network address when connected to the communication medium device;

Including,

How the client works.
The method of claim 30,

Setting the P2P communication path,

Receiving a P2P communication request of the counterpart client from a server;

When receiving the P2P communication request, accessing a communication mediation device that mediates communication between the client and the counterpart client;

Receiving a media key from the communication media device and transmitting the media key to the server;

Receiving test data from the counterpart client and establishing the P2P communication path

Including,

The counterpart client,

Receiving the network address and the intermediate key of the client from the server, accessing the communication intermediate apparatus using the intermediate key, and transmitting the test data to the client using the network address,

How the client works.
A computer readable storage medium storing instructions for causing the computing hardware to execute the method of claim 30.
A communication interface for establishing a peer-to-peer communication path with a counterpart client, transmitting a shared key to the counterpart client, and receiving data encrypted with the shared key through the P2P communication path; And

A controller that decrypts the encrypted data using the shared key and updates decryption number information related to data usage of a client when the data is decrypted

Including,

Client.
The method of claim 40,

The communication interface,

Transmitting the decryption number information to a server and receiving guide information on the data usage amount from the server,

Client.
The method of claim 41, wherein

The guide information,

Excess information indicating whether the data usage amount exceeds a predetermined usage amount;

Remaining information indicating available data capacity excluding the data usage amount among the predetermined usage amounts; And

Restriction information indicating whether there is a restriction on at least one of bandwidth and quality for P2P communication of the client

Including at least one of,

Client.
The method of claim 40,

The communication interface,

Receive information related to data usage of a shared client sharing a data quota assigned to the client,

The controller,

Updating the decoding count information based on the received information;

Client.
The method of claim 43,

The received information is,

Updated decryption number information each time the shared client decrypts the encrypted data received through the P2P communication

Including,

Client.
The method of claim 40,

The communication interface,

When the network address of the client is changed, the server transmits change information indicating that the network address of the client is changed to the server, accesses a communication mediator that secures an intermediate path corresponding to the P2P communication path, and the communication mediator Receiving other data encrypted with the shared key of the counterpart client from

The counterpart client,

If the acknowledgment for the other data sent to the client is not received from the client, to transmit the other data to the communication medium device,

Client.
The method of claim 45,

The controller,

Updating the decryption number information when the other data is decrypted with the shared key;

Client.
The method of claim 40,

The communication interface,

Sends a P2P communication request to a server, receives a media key generated by a communication mediator for mediating communication between the client and the counterpart client, and a network address of the counterpart client, using the media key Connecting to a communication medium device and, when connected to the communication medium device, establishing a P2P communication path with the counterpart client based on the network address;

Client.
The method of claim 40,

The communication interface,

Receiving a P2P communication request of the counterpart client from a server, and when receiving the P2P communication request, accesses a communication mediator that mediates communication between the client and the counterpart client, and receives an intermediate key from the communication mediator. Transmit the intermediate key to the server, receive test data from the counterpart client, establish the P2P communication path,

The counterpart client,

Receiving the network address and the intermediate key of the client from the server, accessing the communication intermediate apparatus using the intermediate key, and transmitting the test data to the client using the network address,

Client.