Patent Description:
The development of information and communication technology (ICT) has been remarkable in recent years, and devices connected to a network such as the Internet are not limited to conventional information processing devices, such as personal computers or smartphones, and are spreading to various things. Such a technology trend is called "IoT (Internet of Things)", and various technologies and services have been proposed and put into practical use. In the future, a world is envisioned in which billions of people on Earth and tens of billions or trillions of devices are connected at the same time. In order to realize such a networked world, it is necessary to provide a solution that is simpler, safer, and more freely connected.

Usually, on a network, data communication between devices is realized by using an IP (Internet Protocol) address statically or dynamically assigned to each device. For example, <CIT> (Patent Document <NUM>) discloses a network system using a new concept of authentication of a network address itself. According to this network system, it is possible to realize secure communication between devices by using an authenticated IP address.

Patent Document <NUM>: <CIT>
<CIT> describes a system and method for secure instant messaging. <CIT> describes a secure sockets layer cut through architecture. <CIT> describes a controller, communication method, and communication system.

According to the above Patent Document <NUM>, assuming that the concept of realizing secure communication using such an authenticated IP address is applied to an existing network, the device should not only communicate with a device having an authenticated IP address but also communicate with a device having only a normal IP address (that is, the assigned IP address is not authenticated).

The present disclosure provides one solution in a network including a device whose destination device cannot exchange encrypted packets.

According to an aspect of the present disclosure, a communication processing method in a device connected to a network is provided, in accordance with claim <NUM>. The communication processing method includes: a step of determining whether or not a destination device is able to exchange encrypted packets in response to a packet transmission request; a step of generating a first encrypted packet directed to the destination device according to the packet transmission request if the destination device is able to exchange encrypted packets; a step of transmitting the first encrypted packet to the destination device by P2P; a step of generating a second encrypted packet including a packet directed to the destination device according to the packet transmission request if the destination device is not able to exchange encrypted packets; and a step of transmitting the second encrypted packet to a device serving as a proxy server by P2P.

The communication processing method may further include: a step of specifying a device to be the proxy server; and a step of transmitting a request for enabling a proxy operation to the specified device.

The communication processing method may further include: a step of acquiring a private key and a public key; a step of determining an IP address of the device itself based on a hash value calculated from the public key according to a hash function; a step of acquiring a digital certificate associated with the public key from a certificate authority connected to a network; and a step of transmitting the public key and the digital certificate to another device.

The communication processing method may further include: a step in which, when the public key and a digital certificate associated with the public key are received from another device, validity of the digital certificate is determined; and a step in which, when it is determined that the digital certificate is valid, an IP address of the another device is determined based on a hash value calculated from the public key according to a hash function.

A device according to still another embodiment of the present disclosure includes: a network interface for connecting to a network; and a control unit connected to the network interface. The control unit is configured to be able to execute: processing for determining whether or not a destination device is able to exchange encrypted packets in response to a packet transmission request; processing for generating a first encrypted packet directed to the destination device according to the packet transmission request if the destination device is able to exchange encrypted packets; processing for transmitting the first encrypted packet to the destination device by P2P; processing for generating a second encrypted packet including a packet directed to the destination device according to the packet transmission request if the destination device is able to exchange encrypted packets; and processing for transmitting the second encrypted packet to a device serving as a proxy server by P2P.

According to still another embodiment of the present disclosure, a communication processing program for a computer having a network interface for connecting to a network is provided. When the communication processing program is executed by the computer, the communication processing program causes the computer to execute the communication processing method described above.

According to the present disclosure, even in a network including a device whose destination device cannot exchange encrypted packets, it is possible to maintain the secure level while maintaining processing affinity.

Hereinafter, an embodiment according to the present disclosure will be described in detail with reference to the diagrams. In addition, the same or corresponding portions in the diagrams are denoted by the same reference numerals, and the description thereof will not be repeated.

First, the overall configuration of the network system <NUM> according to the present embodiment will be described.

<FIG> is a schematic diagram showing an example of the overall configuration of the network system <NUM> according to the present embodiment. Referring to <FIG>, it is assumed that a plurality of devices <NUM>-<NUM>, <NUM>-<NUM>, and <NUM>-<NUM>, <NUM>-<NUM>, <NUM>-<NUM>,. (hereinafter, may be referred to collectively as a "device <NUM>") are connected to an arbitrary network <NUM> such as the Internet or an intranet. Some of the devices <NUM> may be connected to the network <NUM> through wireless communication established between the devices <NUM> and an access point <NUM>. Alternatively, some other devices <NUM> may be connected to the network <NUM> through wireless communication established between the devices <NUM> and a mobile base station <NUM>.

Thus, the network <NUM> may include any one of a local area network (LAN), a wide area network (WAN), a radio access network (RAN), and the Internet.

Each of the devices <NUM> connected to the network can be regarded as a "node" of the network, and in the following description, the device <NUM> may be referred to as a "node".

In the network system <NUM> according to the present embodiment, data communication is realized between the devices <NUM> according to a procedure described later. In addition, any physical connection method between the devices <NUM> may be used.

The device <NUM> includes any device having a function of performing data communication with other devices using the IP address of each device. The device <NUM> may be configured as a single communication device, may be configured as a part of any thing, or may be configured to be embedded in any thing.

More specifically, the device <NUM> may be, for example, a personal computer, a smartphone, a tablet, or a wearable device (for example, a smart watch or an AR glass) worn on the user's body (for example, an arm or a head). In addition, the device <NUM> may be a control device installed in a smart home appliance, a connected automobile, a factory, and the like or a part thereof.

The network system <NUM> according to the present embodiment further includes one or more certificate authorities <NUM>. Each of the certificate authorities <NUM> is a computer configured by one or more servers. The IP address of each device <NUM> is authenticated according to a procedure, which will be described later, by using one or more certificate authorities <NUM>. As a result, each device <NUM> has an authenticated IP address.

In this specification, the "authenticated IP address" means a state in which the validity of the IP address held by each device <NUM> is guaranteed for the communication destination or a third party. More specifically, the "authenticated IP address" means an IP address that is generated by an irreversible cryptographic hash function and is directly or indirectly authenticated by the certificate authority (details thereof will be described later). By using such an "authenticated IP address", it can be guaranteed that the IP address used by each device <NUM> for data communication is not spoofed.

As a result, any device <NUM> included in the network system <NUM> is uniquely identified based on the IP address of each device <NUM>. That is, each device can determine a device to be a destination or a transmission destination of data transmission based on the IP address of each device.

The IP address is assumed to be a global IP address that can also be used for data communication between the devices <NUM> connected to the Internet, but may be a private IP address that is used only in a specific network.

The number of bits that make up an IP address differs depending on the version. In the currently established IPv4 (Internet Protocol Version <NUM>), a <NUM>-bit address section is defined, and in the currently established IPv6 (Internet Protocol Version <NUM>), a <NUM>-bit address section is defined. In the present embodiment, an IP address according to IPv6 will be mainly described. However, the present disclosure can also be applied to a network address specified by a larger number of bits or a network address specified by a smaller number of bits.

Next, a configuration example of the hardware and software of the device <NUM> used in the network system <NUM> according to the present embodiment will be described.

<FIG> is a schematic diagram showing a hardware configuration example of the device <NUM> according to the present embodiment. Referring to <FIG>, the device <NUM> includes a control unit <NUM>, which is a processing circuitry, as a main component.

The control unit <NUM> is a calculation subject for providing functions and executing processes according to the present embodiment. The control unit <NUM> may be configured such that, by using a processor and a memory shown in <FIG>, the processor executes computer-readable instructions (an OS (Operating System) and a communication processing program shown in <FIG>) stored in the memory. Alternatively, the control unit <NUM> may be realized by using a hard-wired circuit such as an ASIC (Application Specific Integrated Circuit) in which a circuit corresponding to computer-readable instructions is provided. In addition, the control unit <NUM> may be realized by realizing a circuit corresponding to computer-readable instructions on an FPGA (field-programmable gate array). In addition, the control unit <NUM> may be realized by appropriately combining a processor, a memory, an ASIC, an FPGA, and the like.

In a configuration using the processor and the memory shown in <FIG>, the control unit <NUM> includes a processor <NUM>, a main memory <NUM>, a storage <NUM>, and a ROM (Read Only Memory) <NUM>.

The processor <NUM> is an arithmetic circuit that sequentially reads and executes computer-readable instructions. The processor <NUM> includes, for example, a CPU (Central Processing Unit), an MPU (Micro Processing Unit), and a GPU (Graphics Processing Unit). The control unit <NUM> may be realized by using a plurality of processors <NUM> (multiprocessor configuration), or the control unit <NUM> may be realized by using a processor having a plurality of cores (multicore configuration).

The main memory <NUM> is a volatile storage device, such as a DRAM (Dynamic Random Access Memory) or a SRAM (Static Random Access Memory). The processor <NUM> loads a designated program, among various programs stored in the storage <NUM> or the ROM <NUM>, into the main memory <NUM> and cooperates with the main memory <NUM> to realize various processes according to the present embodiment.

The storage <NUM> is, for example, a non-volatile storage device, such as an HDD (Hard Disk Drive), an SSD (Solid State Drive), or a flash memory. The storage <NUM> stores various programs executed by the processor <NUM> or various kinds of data described later.

The ROM <NUM> fixedly stores various programs executed by the processor <NUM> or various kinds of data described later.

In the configuration shown in <FIG> in which the processor <NUM> executes computer-readable instructions stored in the memory, the memory corresponds to the storage <NUM> and the ROM <NUM>.

Here, an example of a program and data stored in the memory of the device <NUM> will be described.

<FIG> is a schematic diagram showing a configuration example of a program and data of the device <NUM> according to the present embodiment. Referring to <FIG>, in the memory (the storage <NUM> and/or the ROM <NUM>) of the device <NUM>, for example, an OS <NUM>, a communication processing program <NUM>, and various applications <NUM> are stored as programs including computer-readable instructions.

The OS <NUM> is a program that provides basic functions for realizing the processing executed by the device <NUM>. The communication processing program <NUM> is mainly a program for providing the functions and executing the processes according to the present embodiment. In addition, the communication processing program <NUM> may provide the functions and execute the processes according to the present embodiment by using a library or the like provided by the OS <NUM>.

The various applications <NUM> are programs for realizing various functions provided by the device <NUM>, and can be arbitrarily installed by the user. Typically, the various applications <NUM> provide various processes using a data communication function provided by the communication processing program <NUM>.

In addition, in the memory (the storage <NUM> and/or the ROM <NUM>) of the device <NUM>, for example, a private key <NUM>, a public key <NUM>, and a digital certificate <NUM> are stored as data necessary for providing the functions and executing the processes according to the present embodiment. The private key <NUM> and the public key <NUM> are a so-called key pair generated according to an arbitrary encryption/decryption algorithm. The private key <NUM> is used for encrypted communication with other devices. The public key <NUM> is used to determine the IP address of each device <NUM> according to a procedure described later. The digital certificate <NUM> is issued to the public key <NUM> by the certificate authority <NUM>, and is for ensuring the validity of the IP address of the device <NUM>. Usually, the digital certificate <NUM> includes a hash value (digital signature) calculated from the public key <NUM> of each device <NUM> using the private key of the certificate authority <NUM>. The device <NUM> that has received the digital certificate <NUM> checks the validity of the digital certificate <NUM> and the public key <NUM> associated with the digital certificate <NUM> by using the public key of the certificate authority <NUM>.

The generation of a key pair (the private key <NUM> and the public key <NUM>), the acquisition of the digital certificate <NUM>, the procedure for using these pieces of data, and the like will be described later.

In addition, it is not necessary to provide both the storage <NUM> and the ROM <NUM>, and only one of the storage <NUM> and the ROM <NUM> may be provided depending on the mounting type. In addition, when both the storage <NUM> and the ROM <NUM> are provided, for example, the key pair (the private key <NUM> and the public key <NUM>) may be stored in the ROM <NUM> to enhance the confidentiality.

Referring back to <FIG>, the device <NUM> further includes a network interface <NUM> for connecting the device <NUM> to the network. The network interface <NUM> performs data communication with other devices through the network.

Examples of the network interface <NUM> include wired connection terminals, such as serial ports including an Ethernet (registered trademark) port, a USB (Universal Serial Bus) port, and an IEEE1394 and a legacy parallel port. Alternatively, the network interface <NUM> may include processing circuitries and antennas for wireless communication with devices, routers, mobile base stations, and the like. The wireless communication supported by the network interface <NUM> may be any of Wi-Fi (registered trademark), Bluetooth (registered trademark), ZigBee (registered trademark), LPWA (Low Power Wide Area), GSM (registered trademark), W-CDMA, CDMA200, LTE (Long Term Evolution), and 5th generation mobile communication system (<NUM>), for example.

The device <NUM> may include a display unit <NUM>, an input unit <NUM>, and a media interface <NUM> as optional components.

The display unit <NUM> is a component for presenting the processing result of the processor <NUM> to the outside. The display unit <NUM> may be, for example, an LCD (Liquid Crystal Display) or an organic EL (ElectroLuminescence) display. In addition, the display unit <NUM> may be a head-mounted display mounted on the user's head, or may be a projector that projects an image on the screen.

The input unit <NUM> is a component for receiving an input operation of a user who operates the device <NUM>. The input unit <NUM> may be, for example, a keyboard, a mouse, a touch panel arranged on the display unit <NUM>, or an operation button arranged in the housing of the device <NUM>.

The media interface <NUM> reads various programs and/or various kinds of data from a non-transitory media <NUM> in which various programs (computer-readable instructions) and/or various kinds of data are stored.

The media <NUM> may be, for example, an optical medium, such as a DVD (Digital Versatile Disc), or a semiconductor medium, such as a USB memory. The media interface <NUM> adopts a configuration according to the type of the media <NUM>. Various programs and/or various kinds of data read by the media interface <NUM> may be stored in the storage <NUM> or the like.

In addition, instead of installing various programs and/or various kinds of data on the device <NUM> through the media <NUM>, necessary programs and data may be installed on the device <NUM> from a distribution server on the network. In this case, the necessary programs and data are acquired through the network interface <NUM>.

As described above, since the display unit <NUM>, the input unit <NUM>, and the media interface <NUM> are optional components, the display unit <NUM>, the input unit <NUM>, and the media interface <NUM> may be connected from the outside of the device <NUM> through any interface such as a USB.

Providing the functions and executing the processes according to the present embodiment are realized by the control unit <NUM>, and the technical scope of this application includes at least the hardware and/or the software for realizing the control unit <NUM>. As described above, for the hardware, not only a configuration including a processor and a memory but also a configuration using a hard-wired circuit using an ASIC or the like or a configuration using an FPGA can be included. That is, the control unit <NUM> can be realized by installing a program on a general-purpose computer, or can be realized as a dedicated chip.

In addition, the software executed by the processor may include not only software distributed through the media <NUM> but also software appropriately downloaded through a distribution server.

In addition, the configuration for providing the functions and executing the processes according to the present embodiment is not limited to the control unit <NUM> shown in <FIG>, and can be implemented by using any technology according to the time of the implementation.

Next, a process for providing an authenticated IP address to each device <NUM> and the like will be described.

In the network system <NUM> according to the present embodiment, typically, the IP address of each device <NUM> is authenticated by using an authenticated IP address. As an example, the IP address of each device <NUM> may be authenticated by using a public key infrastructure (PKI).

<FIG> is a diagram for describing an IP address authentication procedure in the network system <NUM> according to the present embodiment. In addition, reference numerals such as "S1" to "S4" in <FIG> correspond to step numbers shown in <FIG>.

Referring to <FIG>, the device <NUM> has a key pair of the private key <NUM> and the public key <NUM>. A hash value <NUM> is calculated by inputting the public key <NUM> into a predetermined hash function <NUM>, and the entirety or part of the calculated hash value <NUM> is used as an IP address <NUM> of the device <NUM>.

According to such a process of determining the IP address <NUM>, the device <NUM> transmits the public key <NUM> to the certificate authority <NUM>, and associates the digital certificate <NUM> issued by the certificate authority <NUM> with the public key <NUM>. The device <NUM> transmits the public key <NUM> and the digital certificate <NUM> of the device itself to another device. Another device checks the validity of the IP address <NUM> of the device <NUM> based on the public key <NUM> and the digital certificate <NUM> published by the device <NUM>. When the validity of the IP address <NUM> is confirmed, data communication is started using the IP address <NUM> whose validity has been confirmed. The device itself and another device can communicate directly with each other, but in addition to the direct communication processing, inquiry processing at the certificate authority <NUM> may be included.

As described above, in the network system <NUM> according to the present embodiment, the IP address <NUM> itself can be authenticated. By holding such an authenticated IP address <NUM> in the device itself, it is possible to build an independent network without using a statically or dynamically assigned IP address for each device.

Hereinafter, the details of the process for providing the authenticated IP address in the network system <NUM> according to the present embodiment will be described.

The private key <NUM> and the public key <NUM>, which are a key pair, may be generated by the device <NUM> itself, or may be provided from the outside and stored in the device <NUM> in advance. When the private key <NUM> and the public key <NUM> are provided from the outside, the device <NUM> may acquire only the private key <NUM> and generate the public key <NUM> by itself.

As an example of a method of generating the private key <NUM> and the public key <NUM> which are a key pair, a bit string of a predetermined length (for example, <NUM> bits) generated by a random number generator may be used as the private key <NUM>, and the public key <NUM> having a bit string of a predetermined length (for example, <NUM> bits) may be generated from the private key <NUM> according to a known cryptographic algorithm (for example, an elliptic curve cryptographic algorithm). In addition, when the device <NUM> itself generates the key pair, the random number generator may be realized by using the function provided by the OS <NUM>, or may be realized by using a hard-wired circuit, such as an ASIC.

As the hash function <NUM>, a known irreversible cryptographic hash function (for example, BLAKE) can be used. The hash function <NUM> calculates the hash value <NUM> having a bit string of a predetermined length (for example, <NUM> bits).

Not only the public key <NUM> but also an arbitrary keyword may be input to the hash function <NUM>. As an arbitrary keyword, a message associated with a predetermined organization may be used. As the message associated with a predetermined organization, a message including the name of the trademark owned by the predetermined organization may be used. For example, the name (for example, "connectFree") of a registered trademark owned by the predetermined organization may be used as a keyword to be input to the hash function <NUM>. By adopting such an implementation method, it is possible to prevent a third party other than the predetermined organization from implementing the network system <NUM> according to the present embodiment, a relevant method or program, and the like without the permission of the predetermined organization.

The entirety or part of the hash value <NUM> calculated by the hash function <NUM> is used as the IP address <NUM>. For example, when a <NUM>-bit (<NUM> digits in hexadecimal notation) hash value <NUM> is calculated, any <NUM> digits (for example, first <NUM> digits) of the <NUM>-digit hash value <NUM> may be used as the IP address <NUM> (<NUM> bits) corresponding to IPv6. Alternatively, the first eight digits of the <NUM>-digit hash value <NUM> may be determined as the IP address <NUM> (<NUM> bits) corresponding to IPv4.

Alternatively, a <NUM>-bit hash value <NUM> may be calculated from the hash function <NUM> in consideration of the IP address <NUM> (<NUM> bits) corresponding to IPv6. In this case, the entirety of the calculated hash value <NUM> can be determined as the IP address <NUM> (<NUM> bits) corresponding to IPv6.

According to the present embodiment, the IP address <NUM> unique to the device <NUM> can be determined based on the public key <NUM> of the device <NUM>. Thus, the device <NUM> can be connected to a network, such as the Internet, by using the IP address <NUM> determined by the device <NUM>. In addition, even if there is no service provider (server) that manages the global IP address, such as an Internet service provider (ISP), the device <NUM> can perform data communication using the IP address <NUM> determined by itself. In addition, even if there is no server that manages private IP addresses such as a DHCP (Dynamic Host Configuration Protocol) server mounted on an access point or the like, the device <NUM> can perform data communication by making a connection to a global network, such as the Internet, using the IP address <NUM> determined by itself. Therefore, it is possible to improve the user experience and user convenience for connecting to a network, such as the Internet.

It may be possible to identify that the IP address <NUM> determined by the device <NUM> has been determined according to the processing procedure according to the present embodiment. In order to perform such identification, for example, the IP address <NUM> may include a predetermined eigenvalue (unique character string) for identification. That is, the determined IP address may include a predetermined eigenvalue (unique character string) for identification.

As an example, the first two digits (first and second digits from the beginning) of the IP address <NUM> in hexadecimal notation may be fixed to a predetermined unique character string (for example, "FC"). Usually, since the hash function <NUM> is a one-way function, the public key <NUM> cannot be calculated back from the IP address <NUM>. For this reason, the private key <NUM> and the public key <NUM> may be repeatedly generated using a random number generator until the determined IP address <NUM> satisfies predetermined conditions (in this case, the first two digits become a predetermined eigenvalue). That is, the public key <NUM> may be determined so that the IP address <NUM> determined based on the hash value calculated from the public key <NUM> according to the hash function conforms to a predetermined format.

In this manner, by making a predetermined eigenvalue (for example, the first two digits are "FC") for identification be included in the IP address <NUM>, a third party can determine whether or not the IP address <NUM> of the device <NUM> has been determined by the device <NUM> itself.

The IP address <NUM> determined by the device <NUM> may include information by which the type of the device <NUM> can be identified. In order to perform such identification, for example, the IP address <NUM> may include a value corresponding to the type of the device <NUM>. That is, the determined IP address <NUM> may include a value corresponding to the type of the device <NUM> that has determined the IP address <NUM>.

As an example, a value (type identification information) corresponding to the type of the device <NUM> may be embedded in the third and fourth digits from the beginning of the IP address <NUM> in hexadecimal notation.

<FIG> is a diagram showing an example of type identification information embedded in the IP address used in the network system <NUM> according to the present embodiment. The type identification information shown in <FIG> may be stored in advance in the ROM <NUM> (see <FIG>) of the control unit <NUM> of each device <NUM>. As an example, a value corresponding to the type of device shown in <FIG> can be used.

As shown in <FIG>, for example, when the type of the device <NUM> is a personal computer, a value "<NUM>" indicating the personal computer is set in the third and fourth digits from the beginning of the IP address <NUM>.

As described above, since the hash function <NUM> is usually a one-way function, the public key <NUM> cannot be calculated back from the IP address <NUM>. For this reason, the private key <NUM> and the public key <NUM> may be repeatedly generated using a random number generator until the determined IP address <NUM> satisfies predetermined conditions (in this case, the third and fourth digits from the beginning become a value indicating the type of the device <NUM>). That is, the public key <NUM> may be determined so that the IP address <NUM> determined based on the hash value calculated from the public key <NUM> according to the hash function conforms to a predetermined format.

In this manner, by making the value indicating the type of the device <NUM> be included in the IP address <NUM>, a third party can identify the type of the device <NUM> from the IP address <NUM> determined by the device <NUM>.

Next, the registration of the public key <NUM> and the acquisition of the digital certificate <NUM> will be described.

The device <NUM> acquires the digital certificate <NUM> for proving the validity of the public key <NUM> from the certificate authority <NUM>. As a procedure for acquiring the digital certificate <NUM>, the public key <NUM> is transmitted from the device <NUM> to the certificate authority <NUM> for registration, and the digital certificate <NUM> associated with the registered public key <NUM> is acquired from the certificate authority <NUM>.

More specifically, the device <NUM> (control unit <NUM>) transmits the public key <NUM> and a digital certificate issuance request (hereinafter, also referred to as a "certificate signing request") to the certificate authority <NUM> through the network. In response to the certificate signing request received from the device <NUM>, the certificate authority <NUM> registers the public key <NUM> and issues the digital certificate <NUM> associated with the registered public key <NUM>. Then, the certificate authority <NUM> transmits the digital certificate <NUM> to the device <NUM> through the network.

Typically, the digital certificate <NUM> includes owner information of the digital certificate <NUM> (in this example, the device <NUM>), issuer information of the digital certificate <NUM> (in this example, the certificate authority <NUM>), digital signature of the issuer, expiration date of the digital certificate <NUM>, and the like.

The certificate authority <NUM> may be operated by a predetermined organization, or may be an intermediate certificate authority associated with a root certificate authority operated by a predetermined organization. In addition, in registering the public key <NUM> and issuing the digital certificate <NUM> associated with the public key <NUM>, a predetermined fee and/or a maintenance fee may be required for a predetermined organization.

According to the present embodiment, the public key <NUM> is directly authenticated by the certificate authority <NUM> through the registration of the public key <NUM> and the acquisition of the public key <NUM>, so that the IP address <NUM> determined based on the public key <NUM> is indirectly authenticated by the certificate authority <NUM>. By such authentication by the certificate authority <NUM>, the device <NUM> can realize data communication through the network by using the authenticated IP address <NUM>.

In addition, the digital certificate <NUM> associated with the public key may include information relevant to the attributes (hereinafter, also referred to as "attribute information") of the device <NUM> in order to improve confidentiality. As the attribute information of the device <NUM>, for example, the version information of the OS <NUM> of the device <NUM> or the communication processing program <NUM> and the serial number of the hardware (for example, a processor or a storage) forming the device <NUM> can be used. In this case, the device <NUM> may transmit the attribute information of the device <NUM> to the certificate authority <NUM> when transmitting the public key <NUM> and the certificate signing request. In addition, the attribute information of the device <NUM> included in the digital certificate <NUM> may be encrypted by a known irreversible cryptographic hash function or the like.

In this manner, by making the attribute information of the device <NUM> be included in the digital certificate <NUM>, it is possible to authenticate that the digital certificate <NUM> has been issued in response to the certificate signing request from the device <NUM> itself. That is, it is possible to more reliably prevent a device other than the device <NUM> from impersonating the device <NUM> and using the public key <NUM> and the digital certificate <NUM> of the device <NUM>.

Next, a processing procedure for providing an authenticated IP address in each device <NUM> will be described.

<FIG> is a flowchart showing a processing procedure in which the device <NUM> provides an authenticated IP address in the network system <NUM> according to the present embodiment. The processing procedure shown in <FIG> is executed in each device <NUM>, and each step shown in <FIG> is executed by the control unit <NUM> of each device <NUM>.

Referring to <FIG>, the device <NUM> acquires a key pair (the private key <NUM> and the public key <NUM>) generated according to an arbitrary algorithm (step S1). This key pair may be generated by the device <NUM> itself, or may be acquired from the outside by the device <NUM>. Alternatively, the device <NUM> may acquire only the private key <NUM> from the outside and generate the public key <NUM> internally.

Then, the device <NUM> calculates the hash value <NUM> by inputting the public key <NUM> to the predetermined hash function <NUM>, and determines the IP address <NUM> of the device <NUM> from the entirety or part of the calculated hash value <NUM> (step S2). That is, the device <NUM> determines the IP address of the device itself based on the hash value <NUM> calculated from the public key <NUM> according to the hash function <NUM>.

In addition, an appropriate key pair (the private key <NUM> and the public key <NUM>) may be generated so that a unique character string (for example, the first and second digits from the beginning of the IP address <NUM>) and/or type identification information (for example, the third and fourth digits from the beginning of the IP address <NUM>) are included in the IP address <NUM>.

In addition, the device <NUM> transmits the public key <NUM> and a digital certificate issuance request (certificate signing request) to the certificate authority <NUM> (step S3). In response to the certificate signing request received from the device <NUM>, the certificate authority <NUM> registers the public key <NUM> and issues the digital certificate <NUM> associated with the registered public key <NUM>. Then, the certificate authority <NUM> transmits the digital certificate <NUM> to the device <NUM> through the network. Then, the device <NUM> receives the digital certificate <NUM> from the certificate authority <NUM> and stores the digital certificate <NUM> (step S4).

In this manner, the device <NUM> acquires the digital certificate <NUM> associated with the public key <NUM> from the certificate authority.

In addition, the execution order of the processing of step S2 and the processing of steps S3 and S4 does not matter.

Next, a process relevant to IP address notification between the devices <NUM> in the network system <NUM> according to the present embodiment will be described.

<FIG> and <FIG> are diagrams for describing the process relevant to the IP address notification in the network system <NUM> according to the present embodiment. <FIG> and <FIG> show examples of exchanging IP addresses between three devices <NUM>-<NUM>, <NUM>-<NUM>, and <NUM>-<NUM>. In addition, the same processing can be performed between the two devices <NUM>, or the same processing can be performed among a larger number of devices <NUM>.

In the state shown in <FIG> and <FIG>, it is assumed that the devices <NUM>-<NUM>, <NUM>-<NUM>, and <NUM>-<NUM> have determined IP addresses <NUM>-<NUM>, <NUM>-<NUM>, and <NUM>-<NUM>, respectively, according to the procedure described above and the devices <NUM>-<NUM>, <NUM>-<NUM>, and <NUM>-<NUM> have completed the registration of public keys <NUM>-<NUM>, <NUM>-<NUM>, and <NUM>-<NUM> in the certificate authority <NUM> and the acquisition of digital certificates <NUM>-<NUM>, <NUM>-<NUM>, and <NUM>-<NUM> from the certificate authority <NUM>.

As shown in <FIG> and <FIG>, each device <NUM> transmits (broadcasts) the public key <NUM> and the digital certificate <NUM> associated with the public key <NUM> of each device regularly or every event. That is, each device <NUM> transmits the public key <NUM> and the digital certificate <NUM> to another device.

<FIG> shows an example in which the device <NUM>-<NUM> transmits (broadcasts) the public key <NUM>-<NUM> and the digital certificate <NUM>-<NUM> associated with the public key <NUM>-<NUM>. In the example shown in <FIG>, it is assumed that the devices <NUM>-<NUM> and <NUM>-<NUM> can receive the public key <NUM>-<NUM> and the digital certificate <NUM>-<NUM> transmitted from the device <NUM>-<NUM>. Then, the devices <NUM>-<NUM> and <NUM>-<NUM> determine whether or not the digital certificate <NUM>-<NUM> is valid. If it is determined that the digital certificate <NUM>-<NUM> is valid, the devices <NUM>-<NUM> and <NUM>-<NUM> determine the IP address <NUM>-<NUM> of the device <NUM>-<NUM> based on the associated public key <NUM>-<NUM> and register these in connection tables <NUM>-<NUM> and <NUM>-<NUM>, respectively.

Here, the connection table includes information of each device <NUM> for data communication, and each device <NUM> identifies the IP address of the destination device <NUM> or the like and establishes a necessary session with reference to the connection table.

More specifically, the device <NUM>-<NUM> first determines whether or not the digital certificate <NUM>-<NUM> broadcast from the device <NUM>-<NUM> is valid. In the process of determining the validity, the integrity of the digital certificate <NUM>-<NUM> is verified.

As an example of the process for verifying integrity, first, the device <NUM>-<NUM> checks the owner information of the digital certificate <NUM>-<NUM>, the issuer information of the digital certificate <NUM>-<NUM>, and the presence of the issuer's digital signature. Then, the device <NUM>-<NUM> determines whether or not the digital certificate <NUM>-<NUM> is within the expiration date. In addition, the device <NUM>-<NUM> determines whether or not the issuer of the digital certificate <NUM>-<NUM> is reliable. In particular, when the digital certificate <NUM>-<NUM> is issued by an intermediate certificate authority, the device <NUM>-<NUM> identifies the root certificate authority associated with the intermediate certificate authority that has issued the digital certificate <NUM>-<NUM>, and determines whether or not the identified root certificate authority is reliable. For example, when the identified root certificate authority matches one root certificate authority or any of a plurality of root certificate authorities stored in the device <NUM>-<NUM>, it is determined that the issuer of the digital certificate <NUM>-<NUM> is reliable.

If the determination process described above is passed, the device <NUM>-<NUM> determines that the digital certificate <NUM>-<NUM> broadcast from the device <NUM>-<NUM> is valid. Then, the device <NUM>-<NUM> calculates a hash value <NUM>-<NUM> by inputting the public key <NUM>-<NUM> broadcast from the device <NUM>-<NUM> to the predetermined hash function <NUM>, and determines the IP address <NUM>-<NUM> of the device <NUM>-<NUM> using the entirety or part of the calculated hash value <NUM>-<NUM>. Here, it is assumed that the devices <NUM>-<NUM> and <NUM>-<NUM> have a common hash function <NUM>. In addition, it is assumed that the process of determining the IP address <NUM>-<NUM> from the hash value <NUM>-<NUM> is also common between the devices <NUM>-<NUM> and <NUM>-<NUM>.

Through the above processing, the device <NUM>-<NUM> can determine the IP address <NUM>-<NUM> of the device <NUM>-<NUM>. Then, the device <NUM>-<NUM> adds the entry of the determined IP address <NUM>-<NUM> of the device <NUM>-<NUM> to the connection table <NUM>-<NUM>. In addition, the public key <NUM>-<NUM> may be registered in association with the IP address <NUM>-<NUM>.

In addition, the same processing as in the device <NUM>-<NUM> is executed in the device <NUM>-<NUM>, and the entry of the determined IP address <NUM>-<NUM> of the device <NUM>-<NUM> is added to the connection table <NUM>-<NUM> of the device <NUM>-<NUM>. The public key <NUM>-<NUM> may be registered in association with the IP address <NUM>-<NUM>.

By the processing shown in <FIG>, the device <NUM>-<NUM> and the device <NUM>-<NUM> can acquire the IP address <NUM>-<NUM> of the device <NUM>-<NUM>.

Since a series of processes executed by the devices <NUM>-<NUM> and <NUM>-<NUM> are the same as the processes described with reference to <FIG>, the detailed description will not be repeated. By the processing shown in <FIG>, the device <NUM>-<NUM> and the device <NUM>-<NUM> can acquire the IP address <NUM>-<NUM> of the device <NUM>-<NUM>.

In addition, the device <NUM>-<NUM> may transmit (broadcast) the public key <NUM>-<NUM> and the digital certificate <NUM>-<NUM> associated with the public key <NUM>-<NUM>. It is assumed that the devices <NUM>-<NUM> and <NUM>-<NUM> can receive the public key <NUM>-<NUM> and the digital certificate <NUM>-<NUM> transmitted from the device <NUM>-<NUM>. Then, the devices <NUM>-<NUM> and <NUM>-<NUM> determine whether or not the digital certificate <NUM>-<NUM> is valid. If it is determined that the digital certificate <NUM>-<NUM> is valid, the devices <NUM>-<NUM> and <NUM>-<NUM> determine the IP address <NUM>-<NUM> of the device <NUM>-<NUM> based on the associated public key <NUM>-<NUM> and register these in the connection tables <NUM>-<NUM> and <NUM>-<NUM>, respectively. By such processing, the device <NUM>-<NUM> and the device <NUM>-<NUM> can acquire the IP address <NUM>-<NUM> of the device <NUM>-<NUM>.

<FIG> is a sequence chart showing a processing procedure relevant to IP address notification in the network system <NUM> according to the present embodiment. <FIG> shows processing procedures in the three devices <NUM>-<NUM>, <NUM>-<NUM>, and <NUM>-<NUM> so as to correspond to <FIG> and <FIG>.

The device <NUM>-<NUM> transmits (broadcasts) the public key <NUM>-<NUM> and the digital certificate <NUM>-<NUM> associated with the public key <NUM>-<NUM> (sequence SQ10).

Upon receiving the public key <NUM>-<NUM> and the digital certificate <NUM>-<NUM> transmitted from the device <NUM>-<NUM>, the device <NUM>-<NUM> determines the validity of the digital certificate <NUM>-<NUM> (sequence SQ11). When it is determined that the digital certificate <NUM>-<NUM> is valid, the device <NUM>-<NUM> determines the IP address <NUM>-<NUM> of the device <NUM>-<NUM> based on the public key <NUM>-<NUM> (sequence SQ12), and registers the determined IP address <NUM>-<NUM> of the device <NUM>-<NUM> in the connection table <NUM>-<NUM> (sequence SQ13).

Similarly, upon receiving the public key <NUM>-<NUM> and the digital certificate <NUM>-<NUM> transmitted from the device <NUM>-<NUM>, the device <NUM>-<NUM> determines the validity of the digital certificate <NUM>-<NUM> (sequence SQ14). When it is determined that the digital certificate <NUM>-<NUM> is valid, the device <NUM>-<NUM> determines the IP address <NUM>-<NUM> of the device <NUM>-<NUM> based on the public key <NUM>-<NUM> (sequence SQ15), and registers the determined IP address <NUM>-<NUM> of the device <NUM>-<NUM> in the connection table <NUM>-<NUM> (sequence SQ16).

In addition, the device <NUM>-<NUM> transmits (broadcasts) the public key <NUM>-<NUM> and the digital certificate <NUM>-<NUM> associated with the public key <NUM>-<NUM> (sequence SQ20).

Upon receiving the public key <NUM>-<NUM> and the digital certificate <NUM>-<NUM> transmitted from the device <NUM>-<NUM>, the device <NUM>-<NUM> determines the validity of the digital certificate <NUM>-<NUM> (sequence SQ21). When it is determined that the digital certificate <NUM>-<NUM> is valid, the device <NUM>-<NUM> determines the IP address <NUM>-<NUM> of the device <NUM>-<NUM> based on the public key <NUM>-<NUM> (sequence SQ22), and registers the determined IP address <NUM>-<NUM> of the device <NUM>-<NUM> in the connection table <NUM>-<NUM> (sequence SQ23).

Similarly, upon receiving the public key <NUM>-<NUM> and the digital certificate <NUM>-<NUM> transmitted from the device <NUM>-<NUM>, the device <NUM>-<NUM> determines the validity of the digital certificate <NUM>-<NUM> (sequence SQ24). When it is determined that the digital certificate <NUM>-<NUM> is valid, the device <NUM>-<NUM> determines the IP address <NUM>-<NUM> of the device <NUM>-<NUM> based on the public key <NUM>-<NUM> (sequence SQ25), and registers the determined IP address <NUM>-<NUM> of the device <NUM>-<NUM> in the connection table <NUM>-<NUM> (sequence SQ26).

In addition, the device <NUM>-<NUM> transmits (broadcasts) the public key <NUM>-<NUM> and the digital certificate <NUM>-<NUM> associated with the public key <NUM>-<NUM> (sequence SQ30).

Upon receiving the public key <NUM>-<NUM> and the digital certificate <NUM>-<NUM> transmitted from the device <NUM>-<NUM>, the device <NUM>-<NUM> determines the validity of the digital certificate <NUM>-<NUM> (sequence SQ31). When it is determined that the digital certificate <NUM>-<NUM> is valid, the device <NUM>-<NUM> determines the IP address <NUM>-<NUM> of the device <NUM>-<NUM> based on the public key <NUM>-<NUM> (sequence SQ32), and registers the determined IP address <NUM>-<NUM> of the device <NUM>-<NUM> in the connection table <NUM>-<NUM> (sequence SQ33).

Similarly, upon receiving the public key <NUM>-<NUM> and the digital certificate <NUM>-<NUM> transmitted from the device <NUM>-<NUM>, the device <NUM>-<NUM> determines the validity of the digital certificate <NUM>-<NUM> (sequence SQ34). When it is determined that the digital certificate <NUM>-<NUM> is valid, the device <NUM>-<NUM> determines the IP address <NUM>-<NUM> of the device <NUM>-<NUM> based on the public key <NUM>-<NUM> (sequence SQ35), and registers the determined IP address <NUM>-<NUM> of the device <NUM>-<NUM> in the connection table <NUM>-<NUM> (sequence SQ36).

In addition, the processes of sequences SQ10 to SQ16, the processes of sequences SQ20 to SQ26, and the processes of sequences SQ30 to SQ36 can be executed in any order or in parallel.

Thus, when the public key <NUM> and the digital certificate <NUM> associated with the public key <NUM> are received from another device, each device <NUM> determines the validity of the digital certificate <NUM> (sequences SQ11, SQ14, SQ21, SQ24, SQ31, and SQ34). Then, when it is determined that the digital certificate <NUM> is valid, each device <NUM> determines the IP address of another device based on the hash value calculated from the public key <NUM> according to the hash function (sequences SQ12, SQ15, SQ22, SQ25, SQ32, and SQ35).

As described above, in the network system <NUM> according to the present embodiment, on the condition that the digital certificate <NUM> transmitted from another device <NUM> is determined to be valid, the IP address <NUM> of another device <NUM> is determined based on the public key <NUM> associated with the digital certificate <NUM>. Since the IP address <NUM> is determined based on the public key <NUM> on the condition that the digital certificate <NUM> associated with the public key <NUM> is valid, the validity of the public key <NUM> and the validity of the IP address <NUM> can be guaranteed. Therefore, it is possible to realize reliable data communication between the devices <NUM>.

In addition, in the network system <NUM> according to the present embodiment, since the IP address of each device <NUM> can be known based on the public key <NUM> broadcast from each device <NUM>, the devices <NUM> can be directly connected to each other even if there is no server that manages IP addresses. In particular, even if there is no virtual private network (VPN) server or the like, it is possible to realize communication in which confidentiality is ensured between the devices <NUM>, so that the cost and power consumption for maintaining the VPN server can be reduced.

Next, data communication processing in the network system <NUM> according to the present embodiment will be described.

In the network system <NUM> according to the present embodiment, data is exchanged between the devices <NUM> by so-called P2P (Peer to Peer). In addition, each device <NUM> has a routing function and a data transmission function, and data transmission by P2P is repeated until the destination device is reached. With such a function, it is possible to realize a network capable of independently performing data communication.

Since the data (typically, a packet or a frame) communicated by P2P is encrypted by the encryption key set between the devices <NUM> involved in each P2P, it is possible to realize secure data communication. In the following description, as a typical example, data is transmitted in the form of "packets".

<FIG> is a schematic diagram showing an example of the network configuration of the network system <NUM> according to the present embodiment. The network system <NUM> shown in <FIG> includes a local line <NUM> including an access point <NUM>, an Internet <NUM>, and a restricted network <NUM>. A proxy server <NUM> that also functions as a gateway is arranged between the local line <NUM> and the Internet <NUM>. A relay server <NUM> that also functions as a gateway is arranged between the local line <NUM> and the restricted network <NUM>.

The Internet <NUM> includes one or more servers <NUM> that provide various network services. The restricted network <NUM> is, for example, a network that is completely or partially isolated from the Internet <NUM> and is accessible only by the device <NUM> (or the user) belonging to a particular company or organization. The restricted network <NUM> includes one or more servers <NUM> that provide various network services. Here, examples of various network services include Web, mail, and database. In addition, the proxy server <NUM> and the relay server <NUM> can also be regarded as servers that provide network services.

As an example, in the network system <NUM> shown in <FIG>, the device <NUM>, the proxy server <NUM>, the relay server <NUM>, and the server <NUM> all correspond to devices having authenticated IP addresses. That is, these devices can perform data communication using the authenticated IP address as described above. On the other hand, it is assumed that one or more servers <NUM> on the Internet <NUM> are having only a normal IP address (that is, the assigned IP address is not authenticated).

When a known network is assumed, as shown in <FIG>, there may be data exchanged between devices that do not support data communication using an authenticated IP address. Therefore, by implementing the following functions, the device <NUM> according to the present embodiment can exchange data not only with a device that supports data communication using an authenticated IP address but also a device that does not have an authenticated IP address or does not support data communication using an authenticated IP address.

First, data communication between devices having authenticated IP addresses will be described. As an example, in the network system <NUM> shown in <FIG>, data communication between the device <NUM> and the server <NUM> will be described.

<FIG> is a sequence diagram showing a procedure of data communication between devices having authenticated IP addresses in the network system <NUM> according to the present embodiment. <FIG> shows a data transmission method in a network to which a plurality of devices are connected. <FIG> shows a case where an arbitrary request is transmitted from the device <NUM> to the server <NUM> and the server <NUM> responds to the device <NUM> with a result of executing the processing according to the request. In addition, the same sequence numbers as the sequence numbers corresponding to the main process shown in <FIG> are shown in <FIG>.

Referring to <FIG>, the device <NUM> generates an encrypted packet including a request to the server <NUM> (sequence SQ100). A session is established in advance between the device <NUM> and the server <NUM>, and the packet from the device <NUM> to the server <NUM> is encrypted according to the encryption method agreed upon in the established session. The generated encrypted packet is addressed to the server <NUM>.

Then, the device <NUM> establishes a session with the relay server <NUM> and transmits the encrypted packet by P2P (sequence SQ102). That is, the process of transmitting the generated encrypted packet from the device <NUM> to the server <NUM> by P2P is executed. In the P2P transmission, the encrypted packet may be further encrypted. In this case, the encryption is performed according to the encryption method agreed upon in the session established between the device <NUM> and the relay server <NUM>.

The relay server <NUM> further transmits the encrypted packet received from the device <NUM> to the server <NUM>. That is, the relay server <NUM> establishes a session with the server <NUM> and transmits an encrypted packet by P2P (sequence SQ104). In addition, in the P2P transmission, the encrypted packet may be further encrypted.

The server <NUM> determines that the encrypted packet received from the relay server <NUM> is addressed to the device itself, and decrypts the encrypted packet (sequence SQ106). Then, the server <NUM> executes the processing according to the request included in the decryption result of the encrypted packet (sequence SQ108). The server <NUM> generates an encrypted packet including the execution result of the processing (sequence SQ110). The server <NUM> transmits the encrypted packet to the relay server <NUM> by P2P (sequence SQ112). The relay server <NUM> further transmits the encrypted packet received from the server <NUM> to the device <NUM>. That is, the relay server <NUM> transmits the encrypted packet to the device <NUM> by P2P (sequence SQ114).

The device <NUM> determines that the encrypted packet received from the relay server <NUM> is addressed to the device itself, and decrypts the encrypted packet (sequence SQ116). Then, the device <NUM> executes processing, such as displaying the result, by using the execution result of the process included in the decryption result of the encrypted packet (sequence SQ118).

As described above, since the encrypted packets are sequentially transmitted by P2P between the devices having the authenticated IP addresses, data can be securely exchanged.

Next, data communication with a device that does not support an authenticated IP address will be described. As an example, in the network system <NUM> shown in <FIG>, data communication between the device <NUM> and the server <NUM> will be described.

<FIG> is a sequence diagram showing a procedure of data communication between devices having authenticated IP addresses in the network system <NUM> according to the present embodiment. <FIG> shows a case where an arbitrary request is transmitted from the device <NUM> to the server <NUM> and the server <NUM> responds to the device <NUM> with a result of executing the processing according to the request. At this time, the proxy server <NUM> serves as a proxy server between the device <NUM> and the server <NUM>. In addition, the same sequence numbers as the sequence numbers corresponding to the main process shown in <FIG> are shown in <FIG>.

In the following description, as a typical example, only the proxy operation of the proxy server <NUM> will be described. However, since it is not necessary to execute completely the same processing as the proxy operation, processing similar to the processing relevant to the proxy operation may be adopted. In addition, without being limited to the proxy operation, for example, a virus check function or a filtering function may be included.

Referring to <FIG>, when a packet satisfying predetermined conditions is given by an arbitrary application or the like, the device <NUM> transmits a proxy operation request to the proxy server <NUM> (sequence SQ200). The predetermined conditions include, for example, that a packet addressed to a device that does not support data communication using an authenticated IP address is given. Upon receiving the proxy operation request, the proxy server <NUM> enables the proxy operation for the device <NUM>. In this manner, the process of transmitting a request for enabling the proxy operation from the device <NUM> to the proxy server <NUM> is executed.

The proxy operation request may also be transmitted from the device <NUM> to the proxy server <NUM> by P2P. In addition, the proxy operation request transmitted by P2P may be encrypted.

The proxy operation request from the proxy server <NUM> and the device <NUM> may be executed by using a known protocol. More specifically, a protocol such as SOCKS (SOCKS4, SOCKS4a, and SOCKS5) can be used.

Then, the device <NUM> generates an encrypted packet including a request to the server <NUM> (sequence SQ202). A session is established in advance between the device <NUM> and the proxy server <NUM>, and the packet from the device <NUM> to the proxy server <NUM> is encrypted according to the encryption method agreed upon in the established session. The generated encrypted packet is addressed to the proxy server <NUM>, but also includes a packet addressed to the server <NUM>.

Then, the device <NUM> transmits the encrypted packet to the proxy server <NUM> by P2P (sequence SQ204). That is, the process of transmitting the generated encrypted packet from the device <NUM> to the proxy server <NUM> by P2P is executed. In the P2P transmission, the encrypted packet may be further encrypted. In this case, the encryption is performed according to the encryption method agreed upon in the session established between the device <NUM> and the proxy server <NUM>.

The proxy server <NUM> first decrypts the encrypted packet received from the device <NUM> (sequence SQ206). This is because a normal communication protocol using an IP address is used in the route ahead of the proxy server <NUM>. Then, according to the request included in the decryption result of the encrypted packet, the server <NUM> performs data communication with the server <NUM> on behalf of the device <NUM>. That is, the proxy server <NUM> generates a normal packet including a request included in the decryption result of the encrypted packet (sequence SQ208). Then, the proxy server <NUM> transmits the generated normal packet to the server <NUM> (sequence SQ210). In this manner, the proxy server <NUM> executes the process of transmitting the normal packet, which is generated by decrypting the encrypted packet, to the server <NUM>.

In addition, when generating the normal packet, the proxy server <NUM> may appropriately change the header information and the like included in the packet from the device <NUM>.

Then, the proxy server <NUM> transmits the generated normal packet to the server <NUM> (sequence SQ210). The transmission of the normal packet does not necessarily have to be P2P, and the packet may be appropriately transmitted according to normal TCP/IP, UDP/IP, or the like.

Upon receiving the normal packet from the proxy server <NUM>, the server <NUM> executes the process according to the request included in the normal packet (sequence SQ212). Then, the server <NUM> transmits a normal packet (response packet) including the execution result of the processing to the proxy server <NUM> (sequence SQ214).

The proxy server <NUM> receives the response packet from the server <NUM> and generates an encrypted packet including the received normal packet (sequence SQ216). The generated encrypted packet is addressed to the device <NUM>. Then, the proxy server <NUM> transmits the generated encrypted packet to the device <NUM> by P2P (sequence SQ218). In this manner, the process of transmitting the encrypted packet from the proxy server <NUM> to the device <NUM> by P2P is executed.

The device <NUM> determines that the encrypted packet received from the proxy server <NUM> is addressed to device itself, and decrypts the encrypted packet (sequence SQ220). Then, the device <NUM> executes processing, such as displaying the result, by using the processing execution result included in the decryption result of the encrypted packet (sequence SQ222).

As described above, since the encrypted packets are sequentially transmitted by P2P between the devices having the authenticated IP addresses, data can be securely exchanged. On the other hand, in the exchange of data with a device that does not support the authenticated IP address, data can be exchanged with any device by the proxy server <NUM> responding on behalf of the user.

Next, a processing procedure in the device <NUM> and a processing procedure in the proxy server <NUM> will be described.

<FIG> is a flowchart showing a processing procedure in which the device <NUM> according to the present embodiment exchanges packets. <FIG> shows an example of a communication processing method in the device <NUM> connected to the network. Each step shown in <FIG> is executed by the control unit <NUM> (see <FIG>) of the device <NUM> (typically realized by the cooperation of a processor and a memory).

Referring to <FIG>, it is determined whether or not a request to transmit a packet addressed to another device has been given from an arbitrary application <NUM> or the like executed on the device <NUM> (step S100). If a request to transmit a packet addressed to another device is not given (NO in step S100), the processing of step S150 and steps subsequent thereto is executed.

On the other hand, if a request to transmit a packet addressed to another device is given (YES in step S100), the device <NUM> determines whether or not the destination device is a device that supports data communication using an authenticated IP address (step S102). Determining whether or not the destination device is a device that supports data communication using an authenticated IP address means determining whether or not the destination device can exchange the encrypted packet.

In step S102, the determination may be made based on, for example, whether or not the IP address of the destination device has a value shown in <FIG>. Alternatively, only when the IP address of the destination device matches the IP address registered in the list held in advance by the device <NUM>, it may be determined that the destination device is a device that supports data communication using an authenticated IP address. In other cases, it may be determined that the destination device is not a device that supports data communication using an authenticated IP address.

If the destination device is a device that supports data communication using an authenticated IP address (YES in step S102), the device <NUM> generates an encrypted packet addressed to designated another device according to the encryption method agreed upon in the session between the device <NUM> and the destination device (step S104). That is, if the destination device can exchange the encrypted packet, the device <NUM> generates an encrypted packet directed to the destination device according to the packet transmission request. Then, the device <NUM> transmits the generated encrypted packet to the adjacent device by P2P (step S106). Finally, the encrypted packet is transmitted to the destination device by P2P. Then, the processing of step S150 and steps subsequent thereto is executed.

On the other hand, if the destination device is not a device that supports data communication using an authenticated IP address (NO in step S102), the device <NUM> specifies the proxy server <NUM> serving as a proxy server for the device <NUM> (step S108). Typically, the proxy server <NUM> is specified by using the IP address.

Then, the device <NUM> determines whether or not the proxy operation request has been transmitted to the specified proxy server <NUM> (step S110). If the proxy operation request has not been transmitted to the specified proxy server <NUM> (NO in step S110), the device <NUM> transmits the proxy operation request to the specified proxy server <NUM> (step S112). The proxy operation request corresponds to a request for enabling the proxy operation. If the proxy operation request has already been transmitted to the specified proxy server <NUM> (YES in step S110), the processing of step S112 is skipped.

Then, the device <NUM> generates a normal packet addressed to designated another device (step S114), and further generates an encrypted packet, which includes the generated normal packet and is addressed to the specified proxy server <NUM>, according to the encryption method agreed upon in the session between the device <NUM> and the specified proxy server <NUM> (step S116). That is, if the destination device cannot exchange the encrypted packet, the device <NUM> generates an encrypted packet including a packet directed to the destination device according to a packet transmission request. Then, the device <NUM> transmits the generated encrypted packet to the adjacent device by P2P (step S106). Finally, the encrypted packet is transmitted to the proxy server <NUM> serving as a proxy server for the device <NUM> by P2P. Then, the processing of step S150 and steps subsequent thereto is executed.

The processing of steps S100 to S116 corresponds to the processing relevant to packet transmission. The processing of step S150 and steps subsequent thereto corresponds to the processing relevant to packet reception.

In step S150, the device <NUM> determines whether or not an encrypted packet has been received from another device (step S150). If the encrypted packet has not been received from another device (NO in step S150), the processing of step S100 and steps subsequent thereto is repeated.

If the encrypted packet has been received from another device (YES in step S150), the device <NUM> determines whether or not the received encrypted packet is addressed to the device itself (step S152). If the received encrypted packet is addressed to the device itself (YES in step S152), the device <NUM> decrypts the received encrypted packet (step S154), and executes necessary processing based on the decryption result of the encrypted packet (step S156). Then, the processing of step S100 and steps subsequent thereto is repeated.

On the other hand, if the received encrypted packet is not addressed to the device itself (NO in step S152), the device <NUM> transmits the received encrypted packet to another device by P2P (step S158). Then, the processing of step S100 and steps subsequent thereto is repeated.

<FIG> is a flowchart showing a processing procedure in which the proxy server <NUM> according to the present embodiment exchanges packets. Each step shown in <FIG> is executed by the control unit of the proxy server <NUM> (typically realized by the cooperation of a processor and a memory).

Referring to <FIG>, the proxy server <NUM> determines whether or not a proxy operation request has been received from any device (step S200). If a proxy operation request has been received from any device (YES in step S200), the proxy server <NUM> establishes a session relevant to the proxy operation for the requesting device (step S202). If a proxy operation request has not been received from any device (NO in step S200), the processing of step S202 is skipped.

Then, the proxy server <NUM> determines whether or not an encrypted packet addressed to the device itself has been received from any device (step S204). If an encrypted packet addressed to the device itself has been received from any device (YES in step S204), the proxy server <NUM> decrypts the received encrypted packet (step S206), and executes the processing according to the request included in the decryption result of the encrypted packet (step S208). If an encrypted packet addressed to the device itself has not been received from any device (NO in step S204), the processing of steps S206 and S208 is skipped.

Then, the proxy server <NUM> determines whether or not a normal packet addressed to the device itself has been received from any device (step S210). As the normal packet, a packet including a response from the above-described server <NUM> or the like is assumed. If a normal packet addressed to the device itself has been received from any device (YES in step S210), the proxy server <NUM> generates an encrypted packet including the received normal packet (step S212). Then, the proxy server <NUM> transmits the generated encrypted packet to the device <NUM> by P2P (step S214). If a normal packet addressed to the device itself has not been received from any device (NO in step S210), the processing of steps S212 and S214 is skipped. Then, the processing of step S200 and steps subsequent thereto is repeated.

As described above, there can be a network in which a device having an authenticated IP address and capable of exchanging encrypted packets and a device having no authenticated IP address and unable to exchange encrypted packets coexist. Even in such a network, the network system <NUM> according to the present embodiment uses a device serving as a proxy server, so that required data communication can be realized by the same procedure as when exchanging encrypted packets with a device having an authenticated IP address from the viewpoint of the device as a transmission source.

According to the network system <NUM> according to the present embodiment, even in a network including a device whose destination device cannot exchange encrypted packets, it is possible to realize data communication by P2P capable of maintaining a secure level while maintaining processing affinity.

Claim 1:
A communication processing method in a device (<NUM>) connected to a network (<NUM>), the method comprising:
a step of determining (S102) whether or not a destination device is able to exchange encrypted packets in response to a packet transmission request based on an IP address of the destination device;
a step of generating (S104) a first encrypted packet directed to the destination device according to the packet transmission request if the destination device is able to exchange encrypted packets;
a step of transmitting (S106) the first encrypted packet to the destination device by P2P;
a step of generating (S114) a second encrypted packet including a packet directed to the destination device according to the packet transmission request if the destination device is not able to exchange encrypted packets; and
a step of transmitting (S106) the second encrypted packet to a device serving as a proxy server for the destination device by P2P.