Communication methods, communication systems, and communication programs

Abstract

The data transmission method includes: a step whereby multiple devices determine the IP address of each device based on a hash value calculated from a public key held by each device using a hash function; a step whereby multiple devices maintain status information reflecting the connection relationship of each device while also transmitting notification information displaying the status information content to other devices; a step whereby multiple devices update the status information maintained by each device based on the notification information received from other devices; and a step whereby, based on the logically defined set of devices maintained by each device, a step determines the routing table used for searching the data transmission receiving addresses maintained between devices within the set.

Description

Technical Field

[0001] This disclosure relates to data communication technology between devices with authenticated IP addresses. Prior Technology

[0002] The advancements in Information and Communication Technology (ICT) in recent years have been astonishing. Devices connected to the Internet and other networks are no longer limited to familiar information processing devices such as personal computers and smartphones, but have expanded to various objects. This technological trend, known as the "Internet of Things (IoT)," is constantly proposing and implementing various technologies, services, and practical applications. Imagine a future world where billions of people and tens of billions or trillions of devices are simultaneously connected. To realize such a networked world, it is necessary to provide solutions that enable simpler, more secure, and more flexible connectivity.

[0003] Typically, on a network, static or dynamic IP (Internet Protocol) addresses are used to enable data communication between devices.

[0004] To enable data communication between devices, data sent from the source device must be forwarded to the receiving device. This data forwarding process is called "routing." To achieve this routing, most routers are configured on the network.

[0005] As disclosed in Japanese Patent Publication No. 022293 of 2006 (Patent Document 1), a router has a path information table that stores path information. Based on the internetworking address in the receiver frame and the contents of the path information table, it determines the path for relaying within the receiver frame (see paragraph

[0005] of Japanese Patent Publication No. 022293 of 2006).

[0006] wait). [Preliminary Technology Documents] [Patent Literature]

[0006] [Patent Document 1] Japanese Patent Publication No. 022293, Heisei 5 Summary of the Invention

[0007] [The problem that the invention aims to solve] According to the aforementioned Patent Document 1, assuming a network with multiple devices, multiple routers are also required, and the workload of each router also increases. Therefore, in a network with multiple devices, a configuration in which each device can independently perform data communication is preferred. This disclosure provides a solution for implementing such a configuration. [Methods used to solve problems]

[0008] According to the present disclosure, a data transmission method is provided in a network connecting multiple devices. The data transmission method includes: the steps of multiple devices determining the IP address of each device based on a hash value calculated from a public key of each device using a hash function; the steps of multiple devices maintaining state information reflecting the connection relationship of each device while also transmitting notification information displaying the state information content to other devices; the steps of multiple devices updating the state information maintained by each device based on notification information received from other devices; and the steps of determining the routing table used for searching devices with data transmission receiving addresses maintained between devices within the set logically defined by the state information maintained by each device.

[0009] The notification information may also include identification information for each device, calculated based on the IP address determined for each device.

[0010] The data transmission method may further include: the step of multiple devices transmitting their respective public keys and electronic certificates linked to the public keys to other devices; and the step of the device receiving the public keys and electronic certificates determining the IP address of the device that is the source of the public keys and electronic certificates based on the hash value calculated from the public keys according to a hash function.

[0011] The determined IP address may include a pre-defined specific value. The determined IP address may also include a value corresponding to the type of device that determined the IP address.

[0012] According to other forms disclosed herein, a communication processing method is provided in a device connected to a network. The communication processing method includes: determining the IP address of the device based on a hash value calculated from a public key using a hash function; maintaining status information reflecting connection relationships with other devices while also transmitting notification information displaying the status information content to other devices; updating the status information based on notification information received from other devices; and maintaining a routing table used for searching data transmission receiving addresses among a logically defined set of devices based on the status information maintained by each device.

[0013] The notification information may also include identification information for explicitly specifying the self-device, calculated based on the determined self-device's IP address.

[0014] The communication processing method may also include: determining the routing table steps based on the state information when a device in the set acts as a root node.

[0015] The steps of maintaining the routing table may also include the steps of receiving the routing table from other devices.

[0016] Status information and notification information may also include identification information to explicitly designate the device as the root node. The update process may also include: when the device designated as the root node in the received notification information is inconsistent with the device designated as the root node in the status information, determining the device as the root node according to predetermined rules.

[0017] The communication processing method may further include: obtaining an electronic certificate from an authentication authority that links to the public key; and transmitting the public key and the electronic certificate to other devices.

[0018] The communication processing method may further include: when receiving a public key and an electronic certificate linked to the public key from another device, determining the legitimacy of the electronic certificate; and when determining the legitimacy of the electronic certificate, determining the IP address of the other device based on the hash value calculated from the public key using a hash function.

[0019] The determined IP address can also contain a pre-defined, specific, inherent value. The determined IP address may also include a value corresponding to the type of device that determined the IP address.

[0020] According to other embodiments disclosed herein, a communication processing method is provided for a device connected to a network. The communication processing method includes: receiving a public key possessed by another device and an electronic certificate linked to the public key; determining the validity of the electronic certificate; determining, when the electronic certificate is valid, using an IP address determined based on a hash value calculated from the public key using a hash function as the authenticated IP address of the other device; and responding to a request from the other device by providing a service corresponding to the authenticated IP address of the other device.

[0021] Alternatively, a public key can be determined such that the IP address determined based on the hash value calculated from the public key using a hash function is consistent with a predetermined format.

[0022] According to other forms of the device disclosed herein, there are network interfaces for connecting to a network and control units connected to the network interfaces. The control unit performs the following processes: determining the IP address of a device based on a hash value calculated from a public key using a hash function; maintaining status information reflecting connection relationships with other devices while also transmitting notification information displaying the status information to other devices; updating the status information based on notification information received from other devices; and maintaining routing tables used in searching for data transmission receiving addresses among a set of devices logically defined by the status information maintained by each device.

[0023] According to other forms disclosed herein, a communication processing program is provided for a computer having a network interface for connecting to a network. When the communication processing program is executed through the computer, it causes the computer to perform the aforementioned communication processing method. [Invention Effects]

[0024] According to this disclosure, in a network where most devices exist, there is a configuration that allows each device to independently achieve data communication. Simple Explanation of the Diagram

[0025] [Figure 1] is a schematic diagram showing an overall configuration example of a network system according to this embodiment. [Figure 2] is a schematic diagram showing an example of the hardware configuration of the device according to this embodiment. [Figure 3] is a schematic diagram showing an example of the configuration of the program and data of the device according to this embodiment. [Figure 4] is a diagram illustrating the IP address authentication procedure in a network system according to this embodiment. [Figure 5] is an example diagram showing a type of specific information embedded in an IP address used in a network system according to this embodiment. [Figure 6] is a flowchart showing the process of providing an authenticated IP address in a network system according to this embodiment. [Figure 7] is a diagram illustrating the processing of IP address notification in a network system according to this embodiment. [Figure 8] is a diagram illustrating the processing of IP address notification in a network system according to this embodiment. [Fig. 9] is a flowchart showing a processing procedure for IP address notification in the network system according to the present embodiment. [Fig. 10] is a diagram illustrating an example of application software for service provision using the network system according to the present embodiment. [Fig. 11] is a diagram illustrating another example of application software for service provision using the network system according to the present embodiment. [Fig. 12] is a diagram illustrating an example of routing in the network system according to the present embodiment. [Fig. 13] is a diagram illustrating a routing implementation method in the network system according to the present embodiment. [Fig. 14] is a diagram illustrating another routing implementation method in the network system according to the present embodiment. [Fig. 15] is a flowchart showing a processing procedure for routing implementation in the network system according to the present embodiment. [Fig. 16] is a diagram showing an example of a data structure of state information and state notification information used in the network system according to the present embodiment. [Fig. 17] is a diagram showing an update example of state information in state notification information in the network system according to the present embodiment. [Fig. 18] is a flowchart showing a processing procedure for routing table determination in the network system according to the present embodiment. [Fig. 19] is a flowchart showing a processing procedure for packet transmission and reception by each device in the network system according to the present embodiment. Embodiment

[0026] Embodiments of the present disclosure will be described in detail with reference to the drawings. In addition, the same or corresponding parts in the drawings are denoted by the same reference numerals, and repeated descriptions thereof will be omitted.

[0027] <A. Overall Configuration of Network 1> First, the overall configuration of the network system 1 according to the present embodiment will be described.

[0028] Figure 1 is a schematic diagram showing an overall configuration example of a network system 1 according to this embodiment. Referring to Figure 1, in any network 2 such as the Internet or an intranet, it is assumed that a plurality of devices 100-1, 100-2, 100-3, 100-4, 100-5, ... (hereinafter, sometimes collectively referred to as "device 100") are connected. Some of the devices 100 may be connected to the network 2 via wireless communication established with access point 4. Alternatively, other devices 100 may be connected to the network 2 via wireless communication established with mobile communication base station 6.

[0029] Thus, Network 2 can include any of the following: Local Area Network (LAN), Wide Area Network (WAN), Radio Access Network (RAN), and Internet.

[0030] The device 100 connected to the network can be regarded as a "node" of the network. In the following description, the device 100 is sometimes referred to as a "node".

[0031] In the network system 1 according to this embodiment, data communication is realized between the devices 100 according to the procedure described below. Furthermore, the physical connection method between the devices 100 can be any method.

[0032] Device 100 includes any device having the function of communicating data with other devices using its own IP address. Device 100 may be configured as a single communication device, or it may be part of or incorporated into a certain object.

[0033] More specifically, device 100 can be, for example, a personal computer, a smartphone, a tablet, or a wearable device (e.g., a smartwatch, AR glasses, etc.) installed on the user's body (e.g., wrist, head, etc.). Furthermore, device 100 can also be a control machine or part thereof installed in smart home appliances, connected cars, factories, etc.

[0034] The network system 1 according to this embodiment further includes one or more authentication authorities 200. Each authentication authority 200 is a computer configured as one or more servers. Using the one or more authentication authorities 200, the IP address of each device 100 is authenticated according to the procedure described below. As a result, each device 100 will have an authenticated IP address.

[0035] In this specification, "authenticated IP address", for a communication target or a third party, refers to a state that guarantees the legitimacy of the IP address maintained by each device 100. More specifically, an "authenticated IP address" refers to an IP address generated by an irreversible cryptographic hash function and authenticated directly or indirectly by a certification authority (details will be described later). By using such an "authenticated IP address", it can be guaranteed that the IP address used by each device 100 in data communication is not spoofed.

[0036] As a result, any device 100 included in the network system 1 will be uniquely and clearly specified according to the IP address possessed by each device 100. That is, each device can be determined as the destination address for data transmission or the device to be sent according to the IP address possessed by each device.

[0037] The IP address is assumed to be a Global IP address that can also be used in data communication between devices 100 connected to the Internet, but it can also be a private IP address used only within a specific network.

[0038] According to different versions of IP addresses, the number of bits constituting the address is different. The currently established IPv4 (Internet Protocol Version 4) specifies a 32-bit address range, and the currently established IPv6 (Internet Protocol Version 6) specifies a 128-bit address range. In this embodiment, the description is mainly based on the IP address of IPv6. However, the present disclosure can also be applied to network addresses specified with more bits or network addresses specified with fewer bits.

[0039] <B. Configuration Example of Device 100> Next, a description will be given of an example of the hardware and software configuration of the device 100 used in the network system 1 according to this embodiment.

[0040] FIG. 2 is a schematic diagram showing an example of the hardware configuration of the device 100 according to this embodiment. Referring to FIG. 2, the device 100, as a main component, includes a control unit 110 of processing circuitry.

[0041] The control unit 110 is a computing entity used to provide and process the functions according to this embodiment. The control unit 110 can also be configured as a processor using the processor and memory shown in FIG2, executing computer-readable instructions stored in the memory (OS (Operating System and Communication Processing Program) shown in FIG3). Alternatively, the control unit 110 can be implemented using hard-wired circuits such as an ASIC (Application-Specific Integrated Circuit) that incorporates circuitry equivalent to computer-readable instructions. Furthermore, the control unit 110 can also be implemented using an FPGA (Field-Programmable Gate Array) with circuitry equivalent to computer-readable instructions. Additionally, the control unit 110 can be implemented by appropriately combining a processor and memory, an ASIC, an FPGA, etc.

[0042] In the configuration of the processor and memory shown in Figure 2, the control unit 110 includes a processor 102, a main memory 104, a storage unit 106, and a ROM (read-only memory) 108.

[0043] The processor 102 is a computational circuit that sequentially reads and executes computer-readable instructions. The processor 102 may be configured as, for example, a CPU (Central Processing Unit), an MPU (Microprocessor Unit), or a GPU (Graphics Processing Unit). The control unit 110 may also be implemented using multiple processors 102 (multi-processor configuration), or the control unit 110 may be implemented using a processor with multiple cores (multi-core configuration).

[0044] The main memory 104 is a volatile memory device such as DRAM (Dynamic Random Access Memory) or SRAM (Static Random Access Memory). The processor 102 expands the programs specified in the various programs stored in the storage 106 or ROM (Read-Only Memory) 108 on the main memory 104, and performs various processing according to this embodiment by cooperating with the main memory 104.

[0045] Storage 106 is a non-volatile memory device such as HDD (hard drive), SSD (solid-state drive), or flash memory. Storage 106 stores various programs executed by processor 102 and various data as described later.

[0046] ROM108 is used to store various programs executed by processor 102 and various data as described later.

[0047] As shown in Figure 2, in the configuration of the processor 102 that executes computer-readable instructions stored in the memory, the memory is equivalent to storage 106 and ROM 108.

[0048] Here is an example of the programs and data stored in the memory of device 100.

[0049] Figure 3 is a schematic diagram showing an example of the configuration of the program and data of the device 100 according to this embodiment. Referring to Figure 3, the memory (storage 106 and / or ROM 108) of the device 100 contains, for example, a program containing computer-readable instructions, an OS 160, a communication processing program 170, and various application software 300.

[0050] OS160 provides the basic functions for implementing the processing performed by device 100. Communication processing program 170 is primarily used to implement the functions and processing according to this embodiment. Furthermore, communication processing program 170 sometimes also utilizes libraries provided by OS160 to implement the functions and processing according to this embodiment.

[0051] Various application software 300 are programs used to implement the various functions provided by device 100, and users can install them at will. Typically, various application software 300 provides various processing using the data communication functions provided in communication processing program 170.

[0052] Furthermore, the memory (storage 106 and / or ROM 108) of device 100 stores, for example, a private key 172, a public key 174, and an electronic certificate 176, as data required for providing functionality and processing according to this embodiment. The private key 172 and public key 174 are a so-called key pair generated according to any encryption / decryption algorithm. The private key 172 is used in encrypted communication with other devices. The public key 174 is used in determining the IP address of each device 100 according to the procedure described later. The electronic certificate 176 is issued by the authentication authority 200 based on the public key 174 to guarantee the legitimacy of the IP address of device 100. Typically, the electronic certificate 176 includes a hash value (electronic signature) calculated using the private key of the authentication authority 200 based on the public key 174 of each device 100. The device 100 that receives the electronic certificate 176 uses the public key of the authentication authority 200 to verify the legitimacy of the electronic certificate 176 and the public key 174 linked to the electronic certificate 176.

[0053] The following describes the generation of the key pair (private key 172 and public key 174), the acquisition of the electronic certificate 176, and the procedures for using this information.

[0054] Furthermore, it is not necessary to have both storage 106 and ROM (read-only memory) 108; depending on the assembly configuration, either one can be used. Alternatively, when both storage 106 and ROM (read-only memory) 108 are used, for example, regarding the key pair (private key 172 and public key 174), storing it within ROM 108 can improve confidentiality.

[0055] Referring again to Figure 2, device 100 further includes a network interface 120 for connecting device 100 to a network. The network interface 120 communicates data with other devices via the network.

[0056] Network interface 120 may include, for example, wired connection terminals such as Ethernet (trademarked) ports, USB (Universal Serial Bus) ports, IEEE 1394 serial ports, and conventional parallel ports. Alternatively, network interface 120 may also include processing circuitry and antennas for wireless communication with devices, routers, mobile communication base stations, etc. The wireless communication corresponding to network interface 120 may be, for example, any of the following: Wi-Fi (trademarked), Bluetooth (trademarked), ZigBee (trademarked), LPWA (Low Power Wide Area Network), GSM (trademarked), W-CDMA, CDMA200, LTE (Long Term Evolution), or 5G.

[0057] The device 100 may, as an optional component, include a display unit 130, an input unit 140, and a media interface 150.

[0058] The display unit 130 is used to display the processing results from the processor 102 to external components. The display unit 130 may be, for example, an LCD (liquid crystal display) or an organic EL (electric light emission) display. Alternatively, the display unit 130 may be a head-mounted display worn on the user's head or a projector that projects images onto a screen.

[0059] The input unit 140 is a component used to accept input operations from the user of the operating device 100. The input unit 140 may be, for example, a keyboard, a mouse, a touch panel disposed on the display unit 130, or operation keys disposed in the housing of the device 100.

[0060] The media interface 150 reads various programs and / or various data from a non-transitory medium 152 that stores various programs (computer-readable instructions) and / or various data.

[0061] The medium 152 may, for example, be an optical medium such as a DVD (Digital Versatile Disc), a semiconductor medium such as a USB memory, or the like. The media interface 150 adopts a configuration corresponding to the type of the medium 152. Various programs and / or various data read through the media interface 150 may also be stored in the storage 106 or the like.

[0062] Furthermore, instead of installing various programs and / or various data into the apparatus 100 via the medium 152, it is also possible to install required programs and data into the apparatus 100 from a distribution server on a network. In this case, the required programs and data are obtained via the network interface 120.

[0063] As described above, the display unit 130, the input unit 140, and the media interface 150 are optional components, and for example, they may be externally connected to the apparatus 100 via any interface such as USB.

[0064] The control unit 110 implements the function provision and processing execution according to the present embodiment, and the technical scope of the present application includes at least hardware and / or software for implementing the control unit 110. As described above, the hardware is not limited to a configuration formed only by a processor and / or a memory, and may also include a configuration including a hard-wired circuit using an ASIC or the like, or a configuration using an FPGA. That is, the control unit 110 may be implemented by installing a program in a general-purpose computer, or may be implemented as a dedicated chip.

[0065] Furthermore, the software executed by the processor is not only distributed via the medium 152, but may also be appropriately downloaded via a distribution server.

[0066] Furthermore, the configuration for implementing function provision and processing execution according to the present embodiment is not limited to the control unit 110 shown in FIG. 2, and any technical assembly suitable for the era of implementation may be used.

[0067] <C. Certified IP Addresses> Next, processing for providing certified IP addresses to each apparatus 100 and the like will be described.

[0068] (c1: IP Address Determination Processing) In the network system 1 according to this embodiment, typically, the IP addresses of each device 100 are authenticated using authenticated IP addresses. For example, a public key infrastructure (PKI) can be used to authenticate the IP addresses of each device 100.

[0069] Figure 4 is a diagram illustrating the IP address authentication procedure in network system 1 according to this embodiment. Furthermore, the symbols "S1" to "S4" in Figure 4 correspond to the step numbers shown in Figure 6.

[0070] Referring to Figure 4, device 100 has a key pair consisting of a private key 172 and a public key 174. By inputting the public key 174 into a predetermined hash function 180, a hash value 178 is calculated. All or part of the hash value 178 is used as the IP address 190 of device 100.

[0071] Following the determination of IP address 190, device 100 transmits public key 174 to authentication authority 200, along with an electronic certificate 176 issued by authentication authority 200 for public key 174. Device 100 then transmits its public key 174 and electronic certificate 176 to other devices. These other devices, based on the public key 174 and electronic certificate 176 transmitted by device 100, verify the legitimacy of device 100's IP address 190. Upon verification of IP address 190's legitimacy, data communication begins using the verified IP address 190. Device 100 and other devices can communicate directly with each other; in addition to direct communication processing, the process may also include query processing from authentication authority 200.

[0072] Thus, in the network system 1 according to this embodiment, the IP address 190 itself can be authenticated. By maintaining such an authenticated IP address 190 by the device itself, an independent network can be constructed without using the statically or dynamically assigned IP addresses to each device.

[0073] The following details the processing used to provide authenticated IP addresses in network system 1 according to this embodiment.

[0074] The private key 172 and public key 174 of the key pair can be generated by the device 100 itself, or they can be provided from an external source and pre-stored in the device 100. If they are provided from an external source, the device 100 only obtains the private key 172, and can generate the public key 174 itself.

[0075] As an example of a method for generating the public key 174 of the key pair, a predetermined length of bit example (e.g., 512 bits) generated by a random number generator can be used as the private key 172, while simultaneously generating a predetermined length of bit example (e.g., 256 bits) of public key 174 based on the private key 172 according to a well-known cryptographic algorithm (e.g., elliptic curve cryptography). Alternatively, if the device 100 itself generates the key pair, the random number generator can be implemented using the functions provided by OS160, or it can be implemented using hard-wired circuitry such as an ASIC.

[0076] Hash function 180 can utilize well-known irreversible cryptographic hash functions (e.g., BLAKE). Hash function 180 calculates a hash value 178 consisting of a given length of bits (e.g., 256 bits).

[0077] In hash function 180, not only the public key 174, but any key can be entered. Information linking to an established organization can also be used as the key. Information containing the trademark name of the established organization can also be used as the information linking to the established organization. For example, a registered trademark name held by an existing organization (e.g., "connectFree") can be used as the key entered into hash function 180. By adopting this assembly method, third parties other than the established organization can be prevented from implementing the network system 1 according to this embodiment and associated methods, programs, etc., without the permission of the established organization.

[0078] Use all or part of the hash value 178 calculated using hash function 180 as the IP address 190. For example, when calculating a 256-bit hash value 178 (64 bits in hexadecimal representation), you can choose any 32 bits (e.g., the first 32 bits) of the 64-bit hash value 178 as the corresponding IPv6 IP address 190 (128 bits). Alternatively, you can choose the first 8 bits of the 64-bit hash value 178 as the corresponding IPv4 IP address 190 (32 bits).

[0079] Alternatively, considering the corresponding IPv6 address 190 (128 bits), the 128-bit hash value 178 can be calculated using hash function 180. In this case, the calculated hash value 178 can be used entirely as the corresponding IPv6 address 190 (128 bits).

[0080] According to this embodiment, based on the public key 174 of device 100, the IP address 190 inherent in device 100 can be determined. Thus, using the IP address 190 determined by device 100, device 100 can connect to a network such as the Internet. Furthermore, even if the service provider (server) managing global IP addresses such as Internet Service Providers (ISPs) does not exist, device 100 can still use its own determined IP address 190 for data communication. Also, even if the server managing private IP addresses such as DHCP (Dynamic Host Configuration Protocol) servers installed at access points does not exist, device 100 can still use its own determined IP address 190 to connect to global networks such as the Internet for data communication. Therefore, the user experience and convenience regarding connecting to networks such as the Internet can be improved.

[0081] (c2: built-in text column) The IP address 190 determined by device 100 can also be explicitly specified as being determined according to the processing procedure of this embodiment. For example, to achieve such specificity, the IP address 190 may contain a predetermined specific intrinsic value (intrinsic text string). That is, the determined IP address may contain a predetermined specific intrinsic value (intrinsic text string).

[0082] For example, the first two digits (the first two digits) of the IP address 190, represented in hexadecimal, can be a predetermined set of characters (e.g., "FC"). Typically, because the hash function 180 is a directional function, the public key 174 cannot be calculated from the IP address 190. Therefore, the determined IP address 190 can be repeatedly used with a random number generator to generate the private key 172 and public key 174 until a predetermined condition is met (at which point the first two digits become a predetermined value). That is, the IP address 190, determined by the hash value calculated from the public key 174 according to the hash function, can also be determined to be consistent with a predetermined format.

[0083] Thus, since the IP address 190 contains a predetermined specific inherent value (e.g., the first two digits "FC"), a third party can determine whether the IP address 190 of the device 100 is determined by the device 100 itself.

[0084] (c3: Category-Specific Information) The IP address 190 determined by device 100 may also contain information that explicitly specifies the type of device 100. For example, to achieve this specificity, the IP address 190 may contain a value corresponding to the type of device 100. That is, the determined IP address 190 may contain a value corresponding to the type of device 100 that determined its IP address 190.

[0085] For example, the third and fourth digits of the IP address 190 in hexadecimal representation can be embedded with the value of type 100 (type-specific information) corresponding to device type 100.

[0086] Figure 5 shows an example of type-specific information embedded in the IP address used in the network system 1 according to this embodiment. The type-specific information shown in Figure 5 may also be pre-stored in the ROM 108 (see Figure 2) of the control unit 110 of each device 100. For example, values ​​corresponding to the device type shown in Figure 5 can be used.

[0087] As shown in Figure 5, for example, when device 100 is a personal computer, the third and fourth digits of the IP address 190 are set to the value "00" indicating a personal computer.

[0088] As mentioned above, typically, because hash function 180 is a directional function, the public key 174 cannot be calculated from IP address 190. Therefore, the determined IP address 190 can be repeatedly generated using a random number generator until a predetermined condition is met (at which point the first three and fourth bits become values ​​representing the type of device 100). That is, the IP address 190 determined by the public key 174 according to the hash value calculated from the public key 174 can also be determined in a format consistent with the predetermined format.

[0089] Thus, since IP address 190 contains a value indicating the type of device 100, a third party can explicitly specify the type of device 100 by using IP address 190 determined by device 100.

[0090] (c4: Login with public key 174 and acquisition of digital certificate 176) Secondly, the login for public key 174 and the acquisition of electronic certificate 176 are explained.

[0091] Device 100 obtains an electronic certificate 176 from authentication authority 200 to prove the legitimacy of public key 174. As part of the procedure for obtaining electronic certificate 176, while transmitting public key 174 from device 100 to authentication authority 200 for login, it also obtains electronic certificate 176 linked to the logged-in public key 174 from authentication authority 200.

[0092] More specifically, device 100 (control unit 110) transmits a public key 174 and a request for the issuance of an electronic certificate (hereinafter also referred to as a "certificate signing request") to certification authority 200 via a network. Certification authority 200 responds to the certificate signing request received from device 100, registering the public key 174 and simultaneously issuing an electronic certificate 176 linked to the registered public key 174. Then, certification authority 200 transmits the electronic certificate 176 to device 100 via the network.

[0093] Typically, electronic certificate 176 includes owner information (in this example, device 100), issuer information (in this example, certification authority 200), issuer's digital signature, and validity period of electronic certificate 176.

[0094] The authentication authority 200 can be operated through an established organization or as an intermediate authentication authority linked to a path authentication authority operated through an established organization. Furthermore, when the public key 174 is logged in and the electronic certificate 176 linked to the public key 174 is issued, it is also permissible for the established organization to pay the established fees and / or maintenance fees.

[0095] According to this embodiment, through the login and acquisition of public key 174, since public key 174 is directly authenticated through authentication authority 200, the IP address 190 determined by public key 174 is also indirectly authenticated through authentication authority 200. Through such authentication by authentication authority 200, device 100 can also realize data communication via network using the authenticated IP address 190.

[0096] Furthermore, to enhance confidentiality, the electronic certificate 176 linked to the public key 174 may also include information about the attributes of the associated device 100 (hereinafter also referred to as "attribute information"). The attribute information of the associated device 100 may include, for example, the OS 160 of the device 100, the version information of the communication processor 170, or the serial number of the hardware constituting the device 100 (e.g., processor, storage, etc.). In this case, when the device 100 transmits the public key 174 and the certificate signing request, it may also transmit the attribute information of the device 100 to the authentication authority 200. Furthermore, the device 100 attribute information contained in the electronic certificate 176 may be encrypted using well-known irreversible cryptographic hash functions, etc.

[0097] In this way, since the attribute information of device 100 is included in the electronic certificate 176, the electronic certificate 176 can be authenticated and issued in response to certificate signing requests from device 100 itself. That is, it can better prevent devices other than device 100 from impersonating device 100 and using device 100's public key 174 and electronic certificate 176.

[0098] (c5: Processor) Secondly, the procedure for providing the authenticated IP addresses in each device 100 is explained.

[0099] Figure 6 is a flowchart showing the processing procedure for providing an authenticated IP address in the device 100 of the network system 1 according to this embodiment. The processing procedure shown in Figure 6 is implemented in each device 100, and each step shown in Figure 6 is implemented through the control unit 110 of each device 100.

[0100] Referring to Figure 6, device 100 obtains a key pair (private key 172 and public key 174) generated according to any algorithm (step S1). This key pair can be generated by device 100 itself or obtained by device 100 from an external source. Alternatively, device 100 can obtain only private key 172 from an external source and generate public key 174 internally.

[0101] Next, device 100 calculates a hash value 178 by inputting the public key 174 into a predetermined hash function 180, and determines the IP address 190 of device 100 based on all or part of the calculated hash value 178 (step S2). That is, device 100 determines its own IP address based on the hash value 178 calculated from the public key 174 according to the hash function 180.

[0102] Furthermore, in order that the IP address 190 includes a unique character string (for example, the first digit and the second digit from the start of the IP address 190) and / or type specifying information (for example, the third digit and the fourth digit from the start of the IP address 190), an appropriate key pair (private key 172 and public key 174) may alternatively be generated.

[0103] Furthermore, the device 100 transmits the public key 174 and an issuance request for an electronic certificate (certificate signature request) to the certification authority 200 (step S3). In response to the certificate signature request received from the device 100, the certification authority 200 registers the public key 174 and issues an electronic certificate 176 linked to the registered public key 174. Then, the certification authority 200 transmits the electronic certificate 176 to the device 100 via the network. Then, the device 100 receives and stores the electronic certificate 176 from the certification authority 200 (step S4).

[0104] In this way, the device 100 obtains the electronic certificate 176 linked to the public key 174 from the certification authority.

[0105] Furthermore, the execution order of the processing of step S2 and the processing of steps S3 and S4 is not limited.

[0106] <D. Data Communication Processing> Next, the data communication processing between the devices 100 using the authenticated IP address will be described.

[0107] (d1: Notification of IP address) First, the processing of IP address notification between the devices 100 in the network system 1 according to the present embodiment will be described.

[0108] FIG. 7 and FIG. 8 are processing diagrams for explaining the IP address notification in the network system 1 according to the present embodiment. In FIG. 7 and FIG. 8, IP address exchange between three devices 100-1, 100-2 and 100-3 is exemplified. Furthermore, the same processing can also be performed between two devices 100, and the same processing can also be performed between more devices 100.

[0109] In the states shown in Figures 7 and 8, devices 100-1, 100-2, and 100-3, according to the above procedure, respectively determine IP addresses 190-1, 190-2, and 190-3, and also respectively complete the login of public keys 174-1, 174-2, and 174-3 to the authentication authority 200 and obtain electronic certificates 176-1, 176-2, and 176-3 from the authentication authority 200.

[0110] As shown in Figures 7 and 8, each device 100 periodically or during each activity transmits (broadcasts) its public key 174 and the electronic certificate 176 linked to the public key 174. That is, each device 100 transmits the public key 174 and the electronic certificate 176 to other devices. Furthermore, if the public key 174 is included within the electronic certificate 176, only the electronic certificate 176 may be transmitted.

[0111] Figure 7 shows, for example, device 100-1, transmitting (propagating) a public key 174-1 and an electronic certificate 176-1 linked to the public key 174-1. In the example shown in Figure 7, devices 100-2 and 100-3 can receive the public key 174-1 and electronic certificate 176-1 transmitted by device 100-1. Then, in determining whether the electronic certificate 176-1 is valid, if valid, devices 100-2 and 100-3 determine the IP address 190-1 of device 100-1 based on the linked public key 174-1, and log in to connection tables 194-2 and 194-3 respectively.

[0112] Here, the connection table is used because data communication includes information from each device 100. Each device 100, referring to the connection table, specifies the IP address of the receiving address of the device 100, and also establishes the required communication session.

[0113] More specifically, device 100-2 first determines whether the electronic certificate 176-1 broadcast by device 100-1 is legitimate. In the process of determining this legitimacy, the integrity of electronic certificate 176-1 is verified.

[0114] As an example of integrity verification, device 100-2 first verifies the existence of the owner information, issuer information, and digital signature of electronic certificate 176-1. Then, device 100-2 determines whether electronic certificate 176-1 is within its validity period. Furthermore, device 100-2 determines whether the issuing source of electronic certificate 176-1 can be trusted. Specifically, when electronic certificate 176-1 is issued by an intermediate authentication authority, device 100-2 explicitly specifies the path authentication authority linked to the intermediate authentication authority that issued electronic certificate 176-1, and also determines whether the explicitly specified path authentication authority can be trusted. For example, if the explicitly specified path authentication authority matches any one of the one or more path authentication authorities included in device 100-1, it is determined that the issuing source of electronic certificate 176-1 can be trusted.

[0115] Through the above-described judgment process, device 100-2 determines that the electronic certificate 176-1 broadcast by device 100-1 is legitimate. Therefore, device 100-2, by inputting the public key 174-1 broadcast by device 100-1 into a predetermined hash function 180, calculates a hash value 178-1, and uses all or part of the calculated hash value 178-1 to determine the IP address 190-1 of device 100-1. Here, devices 100-1 and 100-2 share the same hash function 180. Furthermore, the process of determining the IP address 190-1 based on the hash value 178-1 is also shared between devices 100-1 and 100-2.

[0116] Based on the above processing, device 100-2 can determine the IP address 190-1 of device 100-1. Then, device 100-2 appends the determined entry for the IP address 190-1 of device 100-1 to the connection table 194-2. Alternatively, it can also link to the public key 174-1 for IP address 190-1.

[0117] Furthermore, in device 100-3, the same process as in device 100-2 is performed. In the connection table 194-3 of device 100-3, the entry of the determined IP address 190-1 of device 100-1 is added to the connection table 194-2. Alternatively, the public key 174-1 can also be entered into the IP address 190-1.

[0118] Through the processing shown in Figure 7, devices 100-2 and 100-3 can obtain the IP address 190-1 of device 100-1.

[0119] Figure 8 shows, for example, device 100-2 transmitting (broadcasting) public key 174-2 and digital certificate 176-2 linked to public key 174-2. In the example shown in Figure 8, it is assumed that devices 100-1 and 100-3 can receive public key 174-2 and digital certificate 176-2 transmitted by device 100-2. Then, in determining whether digital certificate 176-2 is legitimate, devices 100-1 and 100-3, when the determination is correct, determine the IP address 190-2 of device 100-2 based on the linked public key 174-2, and log in to connection tables 194-1 and 194-3 respectively.

[0120] The series of processes performed in devices 100-1 and 100-3 are the same as those described with reference to FIG7, and will not be described in detail again. Through the processes shown in FIG8, devices 100-1 and 100-3 can obtain the IP address 190-2 of device 100-2.

[0121] Furthermore, device 100-3 can also transmit (broadcast) the public key 174-3 and the digital certificate 176-3 linked to the public key 174-3. Assume devices 100-1 and 100-2 can receive the public key 174-3 and digital certificate 176-3 transmitted by device 100-3. Then, in determining the legitimacy of the digital certificate 176-3, if the determination is correct, devices 100-1 and 100-2 determine the IP address 190-3 of device 100-3 based on the linked public key 174-3 and log into the connection tables 194-1 and 194-2 respectively. Through this process, devices 100-1 and 100-2 can obtain the IP address 190-3 of device 100-3.

[0122] Figure 9 is a flowchart showing the processing procedure for IP address notification in the network system 1 according to this embodiment. In Figure 9, corresponding to Figures 7 and 8, the processing procedures in the three devices 100-1, 100-2, and 100-3 are shown.

[0123] Device 100–1 transmits (broadcasts) public key 174–1 and electronic certificate 176–1 (program SQ10) linked to public key 174–1.

[0124] Upon receiving the public key 174-1 and electronic certificate 176-1 transmitted by device 100-1, device 100-2 verifies the legitimacy of electronic certificate 176-1 (procedure SQ11). If electronic certificate 176-1 is deemed legitimate, device 100-2 determines the IP address 190-1 of device 100-1 based on the public key 174-1 (procedure SQ12) and logs the determined IP address 190-1 of device 100-1 into the connection table 194-2 (procedure SQ13).

[0125] Similarly, upon receiving the public key 174-1 and electronic certificate 176-1 transmitted by device 100-1, device 100-3 determines the legitimacy of electronic certificate 176-1 (procedure SQ14). If electronic certificate 176-1 is deemed legitimate, device 100-3 determines the IP address 190-1 of device 100-1 based on the public key 174-1 (procedure SQ15) and logs the determined IP address 190-1 of device 100-1 into the connection table 194-3 (procedure SQ16).

[0126] Furthermore, device 100–2 transmits (broadcasts) public key 174–2 and electronic certificate 176–2 (program SQ20) linked to public key 174–2.

[0127] Upon receiving the public key 174-2 and electronic certificate 176-2 transmitted by device 100-2, device 100-1 determines the legitimacy of electronic certificate 176-2 (procedure SQ21). If electronic certificate 176-2 is deemed legitimate, device 100-1 determines the IP address 190-2 of device 100-2 based on the public key 174-2 (procedure SQ22) and logs the determined IP address 190-2 of device 100-2 into the connection table 194-1 (procedure SQ23).

[0128] Similarly, upon receiving the public key 174-2 and electronic certificate 176-2 transmitted by device 100-2, device 100-3 determines the legitimacy of electronic certificate 176-2 (procedure SQ24). If electronic certificate 176-2 is deemed legitimate, device 100-3 determines the IP address 190-2 of device 100-2 based on the public key 174-2 (procedure SQ25) and logs the determined IP address 190-2 of device 100-2 into the connection table 194-3 (procedure SQ26).

[0129] Furthermore, device 100–3 transmits (broadcasts) public key 174–3 and electronic certificate 176–3 (program SQ30) linked to public key 174–3.

[0130] Upon receiving the public key 174-3 and electronic certificate 176-3 transmitted by device 100-3, device 100-1 verifies the legitimacy of electronic certificate 176-3 (procedure SQ31). If electronic certificate 176-3 is deemed legitimate, device 100-1 determines the IP address 190-3 of device 100-3 based on the public key 174-3 (procedure SQ32) and logs the determined IP address 190-3 of device 100-3 into the connection table 194-1 (procedure SQ33).

[0131] Similarly, upon receiving the public key 174-3 and electronic certificate 176-3 transmitted by device 100-3, device 100-2 determines the legitimacy of electronic certificate 176-3 (procedure SQ34). If electronic certificate 176-3 is deemed legitimate, device 100-2 determines the IP address 190-3 of device 100-3 based on the public key 174-3 (procedure SQ35) and logs the determined IP address 190-3 of device 100-3 into the connection table 194-2 (procedure SQ36).

[0132] Furthermore, the processing of programs SQ10 to SQ16, SQ20 to SQ26, and SQ30 to SQ36 can be performed in any order or side by side.

[0133] Thus, upon receiving the public key 174 and the electronic certificate 176 linked to the public key 174 from other devices, each device 100 verifies the legitimacy of the electronic certificate 176 (procedures SQ11, SQ14, SQ21, SQ24, SQ31, SQ34). Then, when each device 100 determines that the electronic certificate 176 is legitimate, it determines the IP address of the other devices based on the hash value calculated from the public key 174 according to the hash function (procedures SQ12, SQ15, SQ22, SQ25, SQ32, SQ35).

[0134] As described above, in the network system 1 according to this embodiment, the electronic certificate 176 transmitted by other devices 100 is deemed legitimate as a condition, and the IP address 190 of the other devices 100 is determined based on the public key 174 linked to the electronic certificate 176. The determination that the electronic certificate 176 linked to the public key 174 is legitimate is used as a condition because determining the IP address 190 based on the public key 174 ensures the legitimacy of both the public key 174 and the IP address 190. Therefore, reliable data communication can be achieved between the devices 100.

[0135] Furthermore, in the network system 1 according to this embodiment, since the IP addresses of each device 100 are known based on the public key 174 broadcast by each device 100, the devices 100 can directly connect even if a server managing the IP addresses does not exist. In particular, even if a Virtual Private Network (VPN) server does not exist, the devices 100 can achieve privacy-enhancing communication, thereby reducing the cost and power consumption of maintaining a VPN server.

[0136] (d2: Application Example) In the network system 1 according to this embodiment, since each device 100 can mutually authenticate IP addresses, the communication target can be explicitly specified based solely on the IP address. By utilizing such authenticated IP addresses, various servers can be provided. The following describes an example of a server provided using authenticated IP addresses.

[0137] Figure 10 is a diagram illustrating an example of application software provided using the services of network system 1 according to this embodiment. In the application software example shown in Figure 10, it is assumed that a web-based application software server and a mobile terminal accessing the application software server are both device 100. The application software server provides a built-in webpage with an authenticated IP address corresponding to the access source of the mobile terminal.

[0138] Figure 10(a) shows an example of a network management table 210 maintained by the application software server. The network management table 210 specifies the authenticated IP addresses 212 of mobile terminals that have previously accessed or connected to the intended access points, initial screen information 214 for displaying the initial screen, and information about favorite applications 216. The content of the network management table 210 can be updated manually by the user, or updated via the application software server based on the user's actions.

[0139] Upon receiving an access request from a mobile terminal, the application software server uses the authenticated IP address provided to the mobile terminal as a key, and refers to the network management table 210 to determine the corresponding initial screen information 214 and application software information 216. Then, based on the determined initial screen information 214 and application software information 216, the application software server determines the webpage content to provide to the accessing mobile terminal.

[0140] Figure 10(b) shows an example of a web screen when an application software server provides a server for online banking. For example, in web screen example 220A displayed on the screen of a mobile terminal with authenticated IP address 1, buttons for basic account management such as "Deposit Procedure", "Account Balance Confirmation", and "Transfer Procedure" are configured. On the other hand, in web screen example 220B displayed on the screen of a mobile terminal with authenticated IP address 2, a graph of exchange rate changes over time is displayed, along with buttons related to foreign exchange such as "Foreign Exchange Buy" and "Foreign Exchange Sell".

[0141] Such an initial screen can be determined, for example, by referring to the initial screen information 214 in the network management table 210. Furthermore, by referring to the application software information 216 in the network management table 210, not only the initial screen can be provided, but also services that are preferred by each mobile terminal (i.e., the user operating the mobile terminal).

[0142] As mentioned above, the web page application software server responds to requests from mobile terminals by providing a server with the authenticated IP address corresponding to the mobile terminal. This allows for customization of the initial screen and various services provided when accessing the application software, based on the authenticated IP address of the mobile terminal.

[0143] Figure 11 is a diagram illustrating other application software examples provided using the services of the network system 1 according to this embodiment. In the application software example shown in Figure 11, it is assumed that a hotel management server and a mobile terminal accessing the management server are both devices 100. In the application software example shown in Figure 11, a mobile terminal can be used as an electronic lock (access card).

[0144] Figure 11(a) shows an example of a utilization management table 230 maintained by the server. The utilization management table 230 contains the reservation information (room number 234 and available time 236) made through a reservation website, etc., and links to the network address 232 of the mobile terminal used in the above reservation operation.

[0145] When a user uses their mobile terminal to book accommodation through a reservation website, the server provides the network address of the mobile terminal used for the accommodation reservation and also adds the reservation details to the usage management table 230.

[0146] As shown in Figure 11(b), a wireless communication unit 242 is installed in front of each room of the accommodation facility 240. Users who have made reservations have mobile terminals for booking accommodations. When a user approaches the reserved room, the wireless communication unit 242 initiates wireless communication with the mobile terminal. Furthermore, the wireless communication between the mobile terminal and the wireless communication unit 242 can either start automatically or after the user performs a clearly indicated operation.

[0147] When the network address of the user's mobile terminal matches any login using network address 232 in management table 230, the user unlocks the reserved room based on the corresponding room number 234 and available time 236. In this way, the server responds to requests from the mobile terminal by providing services corresponding to the authenticated IP address of the aforementioned mobile terminal.

[0148] Figure 11 illustrates, as a typical example, the use of a mobile terminal as a room key in accommodation facilities such as hotels, but it is not limited to this and can be used as any kind of access card. For example, the mobile terminal itself can be used as an admission ticket for various facilities such as entertainment venues and concerts. Furthermore, the mobile terminal itself can also be used as a ticket for railways and airplanes.

[0149] In the network system 1 according to this embodiment, since the IP address of the authentication device 100 itself, like existing technology, does not require application software to display tickets, the device 100 itself can be used as a certificate of use.

[0150] Thus, in the network system 1 according to this embodiment, since the authenticated IP address of the mobile terminal can be obtained, there is no need for application software to perform authentication processing, and the inherent services can be provided to each mobile terminal. Furthermore, since data communication between the mobile terminal and devices such as servers means obtaining the authenticated IP address, the time required to provide the inherent services of the mobile terminal becomes extremely short. Compared to a configuration that uses application software for authentication processing, the waiting time required to provide services can be shortened.

[0151] (d3: Routing) Next, the processing of data communication between the devices 100 will be explained. In the network system 1 according to this embodiment, each device 100 has routing and data forwarding functions, through which a network capable of independent data communication can be realized.

[0152] This section describes the routing used in network system 1 according to this embodiment. In the following description, as a typical example, it is assumed that data is transmitted in the form of "packets".

[0153] Figure 12 is a routing example diagram illustrating a network system 1 according to this embodiment. In Figure 12, for example, a routing diagram is illustrated in a network comprising seven devices 100-1 to 100-7.

[0154] As shown in Figure 12, through the aforementioned IP address notification process, a connection 10 can be established between the devices 100 that exchange IP addresses. The devices 100 that have established connection 10 exchange data in a peer-to-peer manner. Furthermore, any protocol, including TCP (Transmission Control Protocol) and UDP (User Datagram Protocol), can be used within the connection 10 between the devices 100.

[0155] For example, when considering transmitting a send packet with the receiving address being device 100-1 to device 100-7, the send packet is transmitted from device 100-1 to device 100-5 (path RT1) via the route in device 100-1. Then, the send packet is transmitted from device 100-5 to device 100-6 (path RT2) via the route in device 100-5. Finally, the send packet is transmitted from device 100-6 to device 100-7 (path RT3) via the route in device 100-6.

[0156] Each device 100 included in the network system 1 according to this embodiment has the following functions in order to realize the routing shown in FIG12.

[0157] Figure 13 is a diagram illustrating the routing implementation method in the network system 1 according to this embodiment. Referring to Figure 13, in the network system 1 according to this embodiment, the logically segmented network system 1 includes one or a plurality of node groups 30 (node ​​groups 30-1, 30-2, 30-3, ...), and each node group 30 shares a routing table 32 (routing table 32-1, 32-2, 32-3, ...).

[0158] Node group 30 means a logically defined set of devices 100, as described later, determined by the state information 40 maintained by each device 100.

[0159] The routing table 32 is used by the device 100 to search for the receiving address (the receiving address of the sending packet) of the data transmission. Typically, it can be implemented using a Distributed Hash Table (DHT). The routing table 32 contains identification information and the location of the device 100 (node) contained in the corresponding node group 30.

[0160] Each node group 30 includes a device 100 that becomes a root node 34 (root nodes 34–1, 34–2, 34–3, …). In the root node 34, a hierarchical logical connection is formed by the device 100 that becomes one or a complex number of nodes 36.

[0161] Figure 14 is a diagram illustrating other routing implementation methods in network system 1 according to this embodiment.

[0162] Referring to Figure 14, each device 100 included in the network system 1 maintains status information 40 (status information 40-1, 40-2, 40-3, ...) reflecting the connection relationship (logical or physical connection relationship) of each device 100. The status information 40 reflects the connection relationship between each device 100 and other devices.

[0163] Furthermore, each device 100 transmits status notification information 42 containing the displayed and maintained status information 40 to other devices 100 that are present in the vicinity periodically (e.g., every few minutes). Each device 100 updates its own status information 40 as needed based on the status notification information 42 from the other devices 100.

[0164] Figure 14 shows an example of device 100-1 transmitting status notification information 42. Each device 100 included in the network system 1 transmits status notification information 42 respectively. By updating status information 40 according to status notification information 42 from other devices 100, the tree structure shown in Figure 13 is logically defined.

[0165] Furthermore, it is not necessary to pre-determine whether any device 100 should be the root node 34. The status information 40 of each device 100 initially displays the value when the aforementioned device is operating as the root node 34. Subsequently, based on the status notification information 42 received from other devices, the device 100 that should operate as the root node 34 and the device 100 that should operate as the normal node 36 are automatically determined by updating the status information 40.

[0166] Figure 15 is a flowchart showing the processing procedure for routing implementation in network system 1 according to this embodiment. Figure 15 shows the switching of devices 100-1, 100-2, 100-5, and 100-4 shown in Figure 14.

[0167] Referring to Figure 15, when connected to network system 1, devices 100-1, 100-2, 100-5, and 100-4 first initialize their respective status information 40 (program SQ100).

[0168] Therefore, device 100-1 transmits status notification information 42, which displays the status information 40 of its own device, to the surrounding devices 100 (procedure SQ102). Each device that receives the status notification information 42 from device 100-1 performs update processing on its own status information 40 according to the received status notification information 42 (procedure SQ104).

[0169] Similarly, device 100-2 transmits status notification information 42, which displays the status information 40 of the device itself, to surrounding devices 100 (procedure SQ106). Each device that receives the status notification information 42 from device 100-2 performs update processing on its own status information 40 based on the received status notification information 42 (procedure SQ108).

[0170] Similarly, device 100-5 transmits status notification information 42, which displays the status information 40 of its own device, to surrounding devices 100 (procedure SQ110). Each device that receives the status notification information 42 from device 100-5 performs update processing on its own status information 40 based on the received status notification information 42 (procedure SQ112).

[0171] Similarly, device 100-4 transmits status notification information 42, which displays the status information 40 of its own device, to surrounding devices 100 (procedure SQ114). Each device that receives the status notification information 42 from device 100-4 performs update processing on its own status information 40 based on the received status notification information 42 (procedure SQ116).

[0172] In this way, the multiple devices 100, while maintaining status information 40 reflecting the connection relationship of each device 100 (program SQ100), also transmit status notification information 42 displaying the content of the status information 40 to other devices (programs SQ102, SQ106, SQ110, SQ114). Furthermore, the multiple devices 100 update the status information 40 maintained by each device 100 according to the status notification information 42 received from other devices (programs SQ104, SQ108, SQ112, SQ116). These processes can also be performed periodically.

[0173] Furthermore, programs SQ102 and SQ104, programs SQ106 and SQ108, programs SQ110 and SQ112, and programs SQ114 and SQ116 can be executed in an independent sequence. Therefore, they can be executed in any order or in parallel.

[0174] Based on the transmission results of the status notification information 42 of each device 100, when a device 100 is determined to act as the root node 34, the device 100 acting as the root node 34 (in the example shown in FIG15, device 100-1) determines the routing table 32 (program SQ120). Thus, based on the status information 40 maintained by each device 100, the logically defined node group 30 (the set of devices 100) performs the process of determining the routing table 32 maintained between the devices 100 included in the aforementioned node group 30. Furthermore, the routing table 32 is used for device search to become the receiving address for data transmission.

[0175] Therefore, the device 100 that acts as the root node 34 transmits the determined routing table 32 to other devices 100 that act as descendant nodes of other self-devices (program SQ122).

[0176] Therefore, the processing of procedures SQ102 to SQ120 is repeated. For ease of explanation, Figure 15 shows an example of the initial configuration status information 40 of each device 100. However, in reality, it is assumed that any device 100 is added to the network system 1 or any device 100 is removed from the network system 1. In such cases, processing is performed such as changing the device 100 that acts as the root node 34 or updating the contents of the routing table 32.

[0177] Next, details regarding status information 40 and status notification information 42 will be explained. In the network system 1 of this embodiment, based on the status notification information 42 exchanged between adjacent devices 100, each device 100 updates its own status information 40 in sequence, and logically constructs a node group 30 of the hierarchical connection of devices 100 as shown in FIG13.

[0178] Figure 16 is a data structure example of the status information 40 and status notification information 42 used in the network system 1 according to this embodiment. Figure 16(a) shows an example of the data structure of the status information 40, and Figure 16(b) shows an example of the data structure of the status notification information 42.

[0179] Referring to Figure 16(a), status information 40, as a setting item, includes Parent ID 401, Children 402, Root ID 403, height 404, and binary representation 405.

[0180] Parent ID401 contains identification information (typically, the Key ID described later) used to explicitly identify the parent node device of each device 100.

[0181] Children402 contains identification information (typically, Key ID, described later) for clearly identifying each device 100's child node devices. Furthermore, since there is no limit to one child node device, Children402 contains one or more devices in a list format.

[0182] The Root ID 403 contains identification information (typically, the Key ID described later) used to explicitly identify the device 100 that acts as the root node 34 of the node group 30 to which each device belongs.

[0183] Within height404, the height of each device in the node group 30 to which each device belongs is stored. Height means the maximum number of edges from the root node 34 to the leaf node in the node group 30 to which each device belongs. That is, the depth from the root node 34 to the leaf node in the node group 30 can be determined according to the height.

[0184] The binary representation 405 contains the identification information of the device (node) to which each device belongs in the node group 30, which is used to clearly specify the search target.

[0185] Furthermore, status information 40, as a newly set item, may also include a time stamp. The time stamp may be, for example, information displaying the update time of each device 100, or information displaying the time of status notification information 42.

[0186] Each device 100 has identification information, namely a Key ID, which is used to explicitly identify the device 100. The Key ID, used in network system 1, is the identification information that can uniquely identify a device 100. Typically, the Key ID uses the IP address of each device 100, or a hash value calculated from the IP address using a hash function.

[0187] Referring to Figure 16(b), status notification information 42 displays the content of status information 40. More specifically, status notification information 42 includes Parent ID 421, Root ID 422, height 423, and Key ID 424.

[0188] Parent ID 421 contains the same value as Parent ID 401 in status information 40. Root ID 422 contains the same value as Root ID 403 in status information 40. Height 423 contains the same value as height 404 in status information 40. Key ID 424 contains the device's identification information, i.e., the Key ID.

[0189] Thus, the status information 40 and the status notification information 42 include a Key ID (identification information of the self-device), which serves as identification information to explicitly identify each device 100. In this case, the Key ID (identification information of the self-device) can also be a value calculated based on the IP address determined for each device 100.

[0190] Furthermore, the status information 40 and status notification information 42 include identification information (Key ID) to explicitly designate the device 100 that is regarded as the root node 34 of each device 100.

[0191] In Figure 16, both the status information 40 and status notification information 42 are in their initial settings. That is, Parent ID 401 is set to "null", Root ID 403 is set to the value of the device's Key ID (Key ID1 in the example of Figure 16), and height 404 is set to "0".

[0192] As shown in Figure 16(a), the initially set status information 40 is updated appropriately based on the status information 40 from other devices. The following describes an example of updating the status information 40.

[0193] Figure 17 is an example diagram showing the update of status information 40 in the status notification information 42 according to this embodiment of the network system 1. In Figure 17, for example, in the network system 1 shown in Figure 12, the status information 40 is updated when the display devices 100-1, 100-5, and 100-6 are arranged in a tree structure in this order.

[0194] After initial setup, the status information 40 of devices 100-1, 100-5, and 100-6 is updated sequentially based on status notification information 42 from other devices. As a result, in any status information 40, the Root ID 403 also contains "Key ID1" representing device 100-1, and the height 404 contains "2", which is the maximum number of edges from the root node 34 to the leaf node in the node group.

[0195] The Parent ID 401 and Children 402 in each status information 40 contain the Key ID of the connection relationship between the corresponding nodes.

[0196] Within binary representation 405, for example, identification information is stored corresponding to the number of bits at a distance from a leaf node. Figure 17 shows, for example, three types of examples ("0", "01", and "001"). This also means that the more bits constituting the value of binary representation 405, the farther away it is from a leaf node. That is, it means that a device 100 with "0" as binary representation 405 is closer to the corresponding leaf node, while a device 100 with "001" as binary representation 405 is farther away from the corresponding leaf node.

[0197] Based on the status information 40 of each device shown in Figure 17, the tree structure of the node group is explicitly specified. The device 100, which acts as the root node 34, determines the routing table 32 according to the explicitly specified tree structure and provides it to each device belonging to the same node table. Through this procedure, the determination of the node group and the root node 34 of the aforementioned node group, as well as the determination of the routing table 32 in the root node 34, can be realized.

[0198] Furthermore, since the timing of the transmission of status notification information 42 from each device 100 is arbitrarily determined by each device 100, the status information 40 may not be updated in all devices. Therefore, when updating the status information 40, it is preferable for each device 100 to perform version management that continues for several generations. That is, it is preferable to maintain the content of the status information 40 before and after the update. At this time, the device 100, which acts as the root node 34, determines the routing table 32 based on the appropriate version of the status information 40 maintained by each device 100.

[0199] Figure 18 is a flowchart showing the routing table determination process in the network system 1 according to this embodiment. The routing table determination process shown in Figure 18 includes the determination of node group 30 and the updating of status information 40. Each step shown in Figure 18 is implemented by the control unit 110 of the device 100 (see Figure 2) (typically implemented through the cooperation of the processor and memory).

[0200] Referring to Figure 18, when connected to one of the networks, device 100 initially sets the device status information 40 (step S100).

[0201] Next, device 100 determines whether the conditions for transmitting status notification information 42 are met (step S102). For example, it determines whether the elapsed time since the last status notification information 42 has reached a predetermined time.

[0202] When the conditions for transmitting status notification information 42 are met (YES in step S102), device 100 generates status notification information 42 based on the current status information 40 and transmits status notification information 42 to other devices (step S104). Alternatively, if the conditions for transmitting status notification information 42 are not met (NO in step S102), the processing in step S104 is skipped.

[0203] In this way, while maintaining the status information 40 that reflects the connection relationship with other devices, the device 100 also performs the processing of transmitting status notification information 42 containing the display status information 40 to other devices (steps S100 to S104).

[0204] Next, device 100 determines whether it has received status notification information 42 from another device (step S106). If it has received status notification information 42 from another device (YES in step S106), device 100 determines whether updating status information 40 is necessary based on the received status notification information 42 (step S108). If updating status information 40 is necessary (YES in step S108), device 100 updates the status information 40 from the receiving device (step S110). If updating status information 40 is not necessary (NO in step S108), the process in step S110 is skipped.

[0205] Thus, device 100 performs the process of updating status information 40 based on status notification information 42 received from other devices (steps S106 to S110).

[0206] On the other hand, if no status notification information 42 is received from other devices (NO in step S106), the processing of steps S108 and S110 is skipped.

[0207] Here, we will explain the processing details of steps S18 and S110. The node group 30 shown in Figure 13 can determine the devices contained in each tree structure by deciding any device as the root node 34. The device 100 that acts as such a root node 34 can also be determined based on the Key ID value of each device 100. That is, in the process of updating the status information 40, if the device considered as the root node contained in the received status notification information 42 (the device 100 explicitly specified by the Key ID stored in Root ID 422) is inconsistent with the device considered as the root node contained in the status information 40 (the device 100 explicitly specified by the Key ID stored in Root ID 403), the device 100 that is determined to be the root node is implemented according to a predetermined rule.

[0208] In this embodiment, as an example of a predetermined rule, the size relationship of Key IDs is utilized. For example, among devices within a certain range, the device with the smallest Key ID can be determined as the root node 34 of the aforementioned range. In this case, each device 100 refers to the Root ID 422 contained in the status notification information 42 received from other devices that are equivalent to the parent node (see Figure 16(b)) to determine whether to update the status information 40.

[0209] Specifically, when the following conditions (1) and (2) are met, the content of status information 40 is updated.

[0210] (1) The Root ID 403 value of status information 40 > the Root ID 422 value of status notification information 42 received from the parent node and (2) The height404 value of status information 40 is less than the height423 value of status notification information 42 received from the parent node. Here, condition (1) means that the Key ID of the root node 34 identified by the mother node is smaller than the Key ID of the root node 34 identified by the above device, and condition (2) means that the mother node belongs to a tree structure that is deeper than the tree structure identified by the above device.

[0211] Therefore, when conditions (1) and (2) are met, the above-mentioned device, in order to incorporate the parent node update status information 40, updates the values ​​contained in the status notification information 42 received from the parent node, specifically, as shown below, the Parent ID 401, Root ID 403, and height 404 of the status information 40.

[0212] Status information 40: Parent ID 401 ← Status notification information received from the parent node: Key ID 424 value .Status information 40: Root ID 403 ← Status notification information received from the parent node: Root ID 422 value The height404 of status information 40 is incremented by 1 (incrementing the height423 value) by the height423 value received from the parent node. Furthermore, the rules for determining the root node 34 are arbitrary. It is possible to determine that the device with the largest Key ID among the devices in a certain range is the root node 34 of the range, or to determine that the device with the closest set value of Key ID is the root node 34. In this case, it is possible to simply change the conditions in (1) above.

[0213] Next, device 100 determines whether it has received a sufficient number of status notification messages 42 from other devices (step S112). If it has received a sufficient number of status notification messages 42 from other devices (YES in step S112), device 100 performs the following process: based on the status information 40 maintained by each device 100, it maintains the routing table 32 used in the device search for data transmission receiving addresses among the node group 30 (a logically defined set of devices 100) (S116, S118, S122, S124).

[0214] More specifically, device 100 determines, based on state information 40, whether the device itself should act as the root node 34 (S114).

[0215] When the self device acts as the root node 34 (YES in step S114), device 100 determines the routing table 32 based on the self device's status information 40 and the status information 40 of other devices (step S116), and transmits the determined routing table 32 to other devices (step S118).

[0216] Thus, based on the status information 40, when device 100 determines that it is acting as the root node in node group 30, it performs the processing of routing table 32.

[0217] On the other hand, when the self-device is not acting as a root node (NO in step S114), device 100 transmits its status information 40 to the device set as the root node (step S120) and determines whether to receive routing table 32 from the device acting as the root node (step S122). If routing table 32 is received from the device acting as the root node (YES in step S122), device 100 accepts the received routing table 32 (step S124). In this way, device 100 maintains routing table 32 because it receives routing table 32 from other devices 100.

[0218] Furthermore, if the routing table 32 is not received from the device acting as the root node (NO in step S122), skip the processing in step S124. Furthermore, if a sufficient number of status notification messages 42 are not received from other devices (NO in step S112), repeat the processing from step S102 onwards.

[0219] Therefore, the processes shown in Figure 18, steps S102 to S124, are repeated. Figure 19 is a flowchart showing the packet transmission and reception process of each device 100 in the network system 1 according to this embodiment. Figure 19(a) shows the processing when a packet to be transmitted is generated from a device, and Figure 19(b) shows the processing when a packet is received from another device. The steps shown in Figures 19(a) and 19(b) are performed by the control unit 110 of the device 100 (see Figure 2) (typically implemented through the cooperation of the processor and memory).

[0220] Referring to Figure 19(a), the device 100, through various application software 300, determines whether to send a packet with another device as the receiving address (step S200). If no packet is sent with another device as the receiving address (NO in step S200), the process below step S200 is repeated.

[0221] On the other hand, if a send packet is given with another device as the receiving address (YES in step S200), device 100, referring to routing table 32, transmits the send packet to the other device on the path corresponding to the receiving address device (step S202). At this time, if the receiving address device is included in a descendant node of its own device, device 100 transmits the send packet to the child node on the path corresponding to the descendant node. On the other hand, if the receiving address device is not included in a descendant node of its own device, the send packet is transmitted to the parent node of its own device. Based on the above, the send packet transmission process ends.

[0222] Referring to Figure 19(b), determine whether a transmission packet has been received from another device (step S250). If no transmission packet has been received from another device (NO in step S250), repeat the process of step S250.

[0223] On the other hand, if a transmission packet is received from another device (YES in step S250), device 100 determines whether the received transmission packet should be transmitted to its own device (step S252). If the received transmission packet is transmitted to its own device (YES in step S252), device 100 receives the aforementioned transmission device and outputs it to the corresponding application software 300 (step S254). Thus, the packet reception process ends.

[0224] In contrast, if the received packet is not destined for the receiving device (NO in step S252), device 100, referring to routing table 32, transmits the packet to another device on the path corresponding to the receiving address device (step S256). The processing of the sending end is determined by referring to this routing table 32, the same as in step S202. Thus, the packet receiving process ends.

[0225] As described above, in the network system 1 according to the present embodiment, the shared routing table 32 is determined for each node group (a logically defined set of devices 100). Thus, by adopting the routing table 32 shared by each node group, when data is transmitted to any device included in the network system 1, the transmission path can be determined in a shorter time.

[0226] In the network system 1 according to the present embodiment, each device 100 included in the network system 1 transmits status notification information 42 indicating the content of the held status information 40 to other devices 100. Then, when each device 100 receives the status notification information 42 from other devices 100, it appropriately updates the content of the status information 40 held by the device itself according to the content of the received status notification information 42. By periodically performing such update processing of the status notification information 42 and the status information 40, an appropriate routing table 32 can be maintained even when a device 100 in the network system 1 joins or leaves, or the connection topology changes.

[0227] <E. Advantages> According to the network system 1 of the present embodiment, in a network where a plurality of devices exist, a solution in which each device can independently implement data communication can be provided.

[0228] The embodiments disclosed herein are illustrative in all respects and should not be considered as restrictive. The scope of the present invention is defined by the claims rather than the above description, and is intended to include all modifications within the meaning and scope equivalent to the claims.

[0229] 1: Network system 2: Network 4: Access point 6: Mobile phone base station 10: Connection 30: Node group 32: Routing table 34: Root node 34–1, 34–2, 34–3: Root node 36: Node 40: Status information 42: Status notification information 100: Device 102: Processor 104: Main memory 106: Storage 108:ROM (Read-Only Memory) 110: Control Department 120: Network Interface 130: Display Section 140: Input Section 150: Media Interface 152: Media 160: OS (Operating System) 170: Communication Processing Program 172: Private Key 174: Public Key 176: Electronic Certificate 178: Hash value 180: Hash function 190: IP address 194: Join Table 200: Certification Authority 210: Network Management Table 212: Authenticated IP address 214: Initial Screenshots 216: Application Software Information 220A, 220B: Screen example: 230: Using management tables 232: Network address 234: Room Number 236: Usable Time 240: Accommodation facilities 242: Wireless Communication Unit 300: Application Software 405:2 carry representation RT1,RT2,RT3: Path

Claims

1. A communication method in a network connecting multiple devices, comprising: Each of the aforementioned multiple devices includes the following steps: determining the address of each device based on a hash value calculated using a hash function according to the public key held by each device; maintaining state information for each device; wherein the state information of each device includes information specifying the depth from the root node to the device, first identification information for specifying the parent node of each device, and second identification information for specifying the root node; determining whether a first condition and a second condition are satisfied when each device receives a message containing state information of other devices; wherein the first condition is that the value of the second identification information of the state information maintained by each device is greater than the value of the second identification information of the state information contained in the aforementioned message; the second condition is that the depth maintained by each device is less than the depth contained in the state information contained in the aforementioned message; and updating the maintained state information based on the state information contained in the aforementioned message when both the first and second conditions are satisfied.

2. The communication method as described in claim 1 further includes: The process of periodically sending messages containing state information maintained by the device to other devices.

3. The communication method as described in request item 1, wherein, The status information maintained by each device also includes the device's identification information.

4. The communication method as described in claim 3, wherein, The aforementioned first identification information and the aforementioned second identification information are specified using the identification information of each device contained in the status information maintained by the target device.

5. The communication method as described in claim 3, wherein, The initial value of the aforementioned first identification information is set to null, and the initial value of the aforementioned second identification information is set to the identification information of each device.

6. The communication method described in any of claims 3 to 5, wherein, The identification information for each device is based on the address value held by each device.

7. The communication method described in any of claims 1 to 5, wherein, The status information maintained by each device also includes timestamps indicating the update time or the time when the aforementioned message was received.

8. The communication method described in any of the requests 1 to 5 further includes the step of determining the routing table used in the search for the device that becomes the data transmission receiving address based on the state information maintained by each device.

9. The communication method described in claim 8 further includes the step of transmitting data between devices by referring to the aforementioned routing table.

10. A communication program for causing devices to perform the communication methods described in any one of claims 1 to 9.

11. A communication system comprising a plurality of devices connected to a network, comprising: The method of determining the address of each device based on the hash value calculated by a hash function using the public key held by each device; The means for maintaining state information; wherein the state information of each device includes information specifying the depth from the root node to the device, first identification information for specifying the parent node of each device, and second identification information for specifying the root node; means for determining whether a first condition and a second condition are satisfied when a message containing state information of other devices is received; wherein the first condition is that the value of the second identification information of the state information maintained by each device is greater than the value of the second identification information of the state information contained in the aforementioned message; the second condition is that the depth maintained by each device is less than the depth contained in the state information contained in the aforementioned message; and means for updating the maintained state information based on the state information contained in the aforementioned message when both the first condition and the second condition are satisfied.

12. The communication system as described in claim 11 further includes: A means by which each device periodically sends messages to other devices, including information contained in the state information maintained by the device itself.

13. The communication system as described in claim 11, wherein, The status information maintained by each device also includes the device's identification information.

14. The communication system as described in claim 13, wherein, The aforementioned first identification information and the aforementioned second identification information are specified using the identification information of each device contained in the state information maintained by the target device.

15. The communication system as described in claim 13, wherein, The initial value in the aforementioned first identification information is set to null, and the initial value in the aforementioned second identification information is set to the identification information of each device.

16. A communication system as described in any of claims 13 to 15, wherein, The identification information for each device is based on the address value held by each device.

17. The communication system described in any of claims 11 to 15, wherein, The status information maintained by each device also includes timestamps indicating the update time or the time when the aforementioned message was received.

18. The communication system described in any of claims 11 to 15 further includes means for using a routing table to determine the device that becomes the data transmission receiving address based on the status information maintained by each device.

19. The communication system as described in claim 18 further includes means for transmitting data between devices by referring to the aforementioned routing table.

Images