# Patent

## Title
Service infrastructure for serving client nodes based on P2P connections

## Abstract

An infrastructure for serving client nodes is disclosed, wherein the infrastructure comprises: a first plurality of service nodes; a second plurality of client nodes; and at least one linking server for providing connecting information to enable the nodes to establish connections between each other, wherein each service node provides service to at least one of the second plurality of client nodes through P2P connections respectively, and a first service node of the first plurality of service nodes acts as a client node to receive service from a second service node of the first plurality of service nodes.

## Background
CROSS REFERENCE TO RELATED APPLICATIONS
This application is a continuation-in-part of U.S. patent application Ser. No. 13/950,282, filed Jul. 25, 2013, which is a continuation-in-part of U.S. patent application Ser. No. 13/293,506, filed Nov. 8, 2011, which claims the priority of TW100129888 filed Jan. 28, 2011 and the priority of TW 100201960 filed Jan. 28, 2011, each of which is incorporated by reference herein in their entirety.


FIELD OF THE INVENTION
The present invention relates to a communication system and more particularly to a communication system using point to point (P2P) connections.
DESCRIPTION OF THE PRIOR ART
P2P networks have become an increasingly important technology when building platforms with connectivity in mind. However, how to establish a P2P connection from node to node quickly without worrying about the complexity of the networking setup and to maximize the services that can be provided to all the client devices remains a big challenge. Therefore, present invention proposes an infrastructure to provide a solution to resolve the above-mentioned issues.
SUMMARY OF THE INVENTION
One objective of the present invention is to provide an integrated infrastructure for serving client terminals using P2P connections.
In one embodiment, an infrastructure for serving client nodes is disclosed, wherein the infrastructure comprises: a plurality of service nodes, wherein each of the plurality of service nodes has an identification for establishing a P2P connection; and at least one linking server for providing connecting information to enable nodes to establish connections between each other, wherein the identification of the first service node and the second service node are registered in the at least one linking server, wherein the plurality of service nodes provide services to the client nodes through P2P connections respectively, and a P2P connection is established between a first service node and a second service node of the plurality of service nodes.
In one embodiment, an infrastructure for serving client nodes is disclosed, wherein the infrastructure comprises: a plurality of service nodes; and at least one linking server for providing connecting information to enable nodes to establish connections between each other, wherein each service node of the plurality of service nodes provides a service to at least one of the client nodes through P2P connections respectively, and a first service node of the plurality of service nodes acts as a client node to receive service from a second service node of the plurality of service nodes.
In one embodiment, in the infrastructure described above, the identification of the second service node is registered in the at least one linking server, wherein the first service node communicates with the at least one link server to establish a P2P connection between the first service node and the second service node according to the connecting information provided by the at least one linking server.
In one embodiment, in the infrastructure described above, the identification of the first service node is registered in the at least one linking server, wherein a first client node communicates with the at least one link server to establish a P2P connection to the first service node according to the connecting information provided by the at least one linking server.
In one embodiment, an electronic device, comprising: a processor; and at least one module, comprises instructions, when executed by the processor, to establish P2P connections with a plurality of client nodes respectively, wherein the electronic device acts as a first service node to provide service to the plurality of client nodes; and to establish a P2P connection with a second service node, wherein the electronic device acts as a client node to receive service from the second service node.



BRIEF DESCRIPTION OF THE DRAWINGS
The foregoing aspects and many of the accompanying advantages of this invention will become more readily appreciated as the same becomes better understood by reference to the following detailed description, when taken in conjunction with the accompanying drawings, wherein:
FIG. 1 is a first diagram schematically showing the architecture of a remote information communication system according to a first embodiment of the present invention;
FIG. 2 is a second diagram schematically showing the architecture of a remote information communication system according to the first embodiment of the present invention;
FIG. 3 is a third diagram schematically showing the architecture of a remote information communication system according to the first embodiment of the present invention;
FIG. 4 is a fourth diagram schematically showing the architecture of a remote information communication system according to the first embodiment of the present invention;
FIG. 5 is a fifth diagram schematically showing the architecture of a remote information communication system according to the first embodiment of the present invention;
FIG. 6 is a sixth diagram schematically showing the architecture of a remote information communication system according to the first embodiment of the present invention;
FIG. 7 is a seventh diagram schematically showing the architecture of a remote information communication system according to the first embodiment of the present invention;
FIG. 8 schematically shows that a remote device registers in a plurality of linking server groups according to one embodiment of the present invention;
FIG. 9 shows a flowchart of the connection and interaction of a linking server and an administration server according to one embodiment of the present invention;
FIG. 10 shows a flowchart of the connection and interaction of a remote device and a linking server according to one embodiment of the present invention; and
FIG. 11 shows a flowchart of the connection and interaction of a proximal device and a remote device according to one embodiment of the present invention;
FIG. 12 illustrates the architecture of IOTC (Internet of Things Cross-platform) in accordance with one embodiment of present invention;
FIG. 13A-13D illustrates a block diagram of an integrated circuit in accordance with one embodiment of present invention; and
FIG. 14A-14B illustrates a block diagram of two connected devices when a P2P connection is established in accordance with one embodiment of present invention.
FIG. 15 depicts an infrastructure for serving client nodes; and
FIG. 16 illustrates a block diagram of an integrated service node.



DETAILED DESCRIPTION OF THE INVENTION
The detailed explanation of the present invention is described as following. The described preferred embodiments are presented for purposes of illustrations and description, and they are not intended to limit the scope of the present invention.
The present invention pertains to a remote information communication system and linking method thereof. The technical contents of the present invention are described in cooperation with the drawings below.
The remote information communication system of the present invention comprises at least one remote device, an administration server, and at least one linking server. The remote information communication system is requested by at least one proximal device to establish a link between the proximal device and the remote device. The linking method of the remote information communication system comprises steps of: A. at least one remote device requesting an administration server to provide an address of at least one linking server supporting the remote device via the Internet; B. the remote device registering the information thereof in the linking server according to the address provided by the administration server; C. a proximal device requesting the administration server to find out a specified remote device via the Internet; D. the administration server responding the address of the linking server that the specified remote device registers to the proximal device; E. a proximal device requesting the linking server to establish a link with the specified remote device according to the responded address; F. the linking server establishing a link between the proximal device and the specified remote device according to the request of the proximal device. The present invention has the following features: the linking server and the remote device needn't open the domain names or IPs to the public; all proximal devices can request the administration server to find out a specified remote server; the administration server provides IP of the linking server for the proximal device; the proximal server requests the linking server to establish a link between the proximal device and the remote server. Thereby is reduced the probability that the linking server or the remote device is invaded by hackers. It is unnecessary for the proximal device to have a fixed IP or remember fixed IPs or domain names. Thus, the user of the proximal device is exempted from many technical problems of linking.
In order to demonstrate the above-mentioned method in detail, the present invention further discloses a practical remote information communication system, which comprises at least one administration server, at least one linking server and at least one remote device. Refer to FIG. 1 a diagram schematically showing the architecture of a remote information communication system according to one embodiment of the present invention. As shown in FIG. 1, two administration servers 11 and 12 constitute an administration server group 1 that back up with each other. Each of the administration servers 11 and 12 stores a device list and a server list. The device list stores the data of a plurality of remote devices allowed for registering. The server list stores the information of a plurality of linking servers. In one embodiment, the server list contains a plurality of linking servers managed by different service providers. In one embodiment, the server list contains a plurality linking servers supporting different types of devices. In one embodiment, the server list contains a plurality linking servers distributed at different geographic locations. In one embodiment, the device list and the server list have a mapping relationship therebetween. As shown in FIG. 1, the remote information communication system includes a linking server 201 and a linking server 211. In this embodiment, the linking server 201 and a linking server 202 are respectively managed by different service providers. As shown in FIG. 1, the linking server 201 and the linking server 202 constitute a linking server group A (20) that back up with each other. Similarly, the linking server 211 and a linking server 212 constitute a linking server group B (21) that back up with each other. In order to describe the present invention conveniently, the administration server group 1, the linking server group A (20) and the linking server group B (21) are used to represent the servers of the linked targets thereinafter. The remote information communication system also includes a remote device A (31), a remote device B (32) and a remote device C (33). As stated hereinbefore, the device list stores the information of a plurality of remote devices. The remote devices A, B and C (31, 32 and 33) respectively have their unique IDs. The information of the service providers managing the remote devices A, B and C (31, 32 and 33) are stored in the device list of the administration server group 1 beforehand. When the linking server group A (20), linking server group B (21), remote device A (31), remote device B (32) and remote device C (33) have just accessed the Internet, the linking server group A (20) and linking server group B (21) transmit server-register information 92 to the administration server group 1 via the Internet to register the IPs and configurations thereof (such as the specifications, linking states, etc.). The administration server group 1 then verifies whether the linking server group A (20) and linking server group B (21) are the legal server groups pre-stored in the server list. If they are legal server groups, the administration server group 1 respectively responds to the linking server group A (20) and linking server group B (21) that their registers are done. When the remote device A, B or C (31, 32 or 33) intend to find out servers able to support them, it sends out linking server requesting information 91 to the administration server group 1 via the Internet. The administration server group 1 then verifies whether the remote device A, B or C (31, 32 or 33) is the legal device pre-stored in the device list. If the remote device A, B or C (31, 32 or 33) is a legal device, the administration server group 1 responds linked targets to it.
In practical application, the linking server group A (20) and the linking server group B (21) may be respectively managed by different service providers. In such a case, the administration server group 1 would assign the remote device A (31) to the linking server group A (20), which is managed by the service provider supporting the remote device A (31). Similarly, the administration server group 1 assigns the remote device B (32) and the remote device C (33) to the linking server group B (21) which is managed by the service provider supporting the remote device B (32) and the remote device C (33). In one embodiment, the remote devices A, B and C (32, 32 and 33) respectively belong to different types of products, and the administration server group 1 respectively assigns them to the linking server group A (20) and the linking server group B (21). In one embodiment, the remote devices A, B and C (31, 32 and 33) are respectively at different geographic locations, and the administration server group 1 assigns each to the nearer linking server group A (20) or nearer linking server group B (21).
Refer to FIG. 2. According to the linking address the administration server group 1 responds to the remote device A (31), the remote device A (31) links to the linking server group A (20) and registers the information thereof in the linking server group A (20), whereby the linking server group A (20) learns IP of the remote device A (31). According to the linking address the administration server group 1 responds to the remote device B (32) and the remote device C (33), the remote device B (32) and the remote device C (33) link to the linking server group B (21) and register the information thereof in the linking server group B (21) whereby the linking server group B (21) learns IPs of the remote device B (32) and the remote device C (33).
Refer to FIG. 3. The remote information communication system of the present invention can accept one or more proximal devices 4 linked thereto. The proximal devices 4 need API (Application Programming Interface) supporting the linking to the administration server group 1. The proximal device 4 can select a specified remote device via API. Suppose that the proximal device 4 chooses the remote device A (31) as the linked target via API. The proximal device 4 sends a linked target requesting information 94 to the administration server group 1 via API to ask which linking server group can link the proximal device 4 to the remote device A (31). The administration server group 1 provides the location of the linking server group A (20) that the specified remote device A (31) registers. Via API, the proximal device 4 links to the linking server group A (20) according to the location that the administration server group 1 responds to the proximal device 4. Refer to FIG. 4, Then, the proximal device 4 sends link requesting information 95 to the linking server group A (20) for being linked to the remote device A (31). Refer to FIG. 5. The linking server group A (20) takes priority to use the hole punching technology and respectively sends hole-punching information 960 and hole-punching information 961 to the proximal device 4 and the remote device A (31) so as to establish a point-to-point link 97 between the proximal device 4 and the specified remote device A (31). The proximal device 4 can obtain the information of the remote device A (31) or control the remote device A (31) via the point-to-point link 97. Refer to a U.S. publication No. 2009/0100309 and a GB publication No. 2475279 for the hole punching technology. As the hole punching technology is not a technical feature of the present invention but a prior art, it does not repeat herein. Refer to FIG. 6. If the linking server group A (20) does not complete the hole punching process, the linking server group A (20) forwards data packets between the proximal device 4 and the specified remote device A (31).
The proximal device 4 cannot obtain the IPs of the linking server group A (20) and the linking server group B (21) unless via the administration server group 1. Therefore, the variation of IP or mechanical specification of the linking server group A (20) and the linking server group B (21) would not hinder the proximal device 4 from finding a linked target. Favored by the abovementioned feature, the architecture of the linking server group (such as quantity, specification, type, etc.) can be modified according to the market requirement. For example, when some type of products increases on line, the linking servers supporting the type of products can be increased to meet the load capacity required by the type of products.
Refer to FIG. 7. When new linking server groups are added, or when the linking information (such as IP) is varied, or when the number of the machines inside a linking server group is varied, what needs doing is only renewing the server list and making the linking server group send the server-register information 92 to register in the administration server group 1 again. When the number or type of the remote devices is varied or when the linking server group that the remote device registers is varied, the device list has to be updated and the remote device has to request the linking server groups with the information of the linking server groups.
FIG. 7 is a diagram illustrating schematically an embodiment of expanding the remote information communication system. In this embodiment, a remote device D (34) is added to the system. In the present invention, the number or addresses of the supported remote devices can be varied via renewing the device list of the administration server group 1. The remote devices A-D (31-34) can ask and learn new available linking server groups via sending the linking server requesting information 91 to the administration server group 1 again. As shown in FIG. 7, a new linking server 213 is added to the linking server group B (21), and a new linking server group C (22) consisting of linking servers 221, 222 and 223 is added to the system. Similarly, the content of the linking servers of the remote information communication system is expanded via renewing the server list of the administration server group 1 in this embodiment. In the present invention, the quantities, specifications and types of the remote devices or linking servers can be expanded or varied according to requirement via only renewing the server list or device list and registering in the administration server group 1 once more. Thereby, the manufacturers can easily vary the load capacity of the system according to requirement.
The remote information communication system of the present invention allows an identical remote device to register in several different linking servers. As shown in FIG. 8, the remote information communication system includes the linking server groups A, D and E (20, 23, and 24). The linking server group D (23) includes linking servers 231 and 232. The linking server group E (24) includes linking servers 241 and 242. After the remote device A (31) sends the linking server requesting information 91 to the administration server group 1, the administration server group 1 responds to the remote device A (31) that it can register in the server groups A, D and E (20, 23, and 24). Favored by the feature, the server groups A, D and E (20, 23, and 24) can jointly support the remote device A (31). When the linking server group A (20) is out of order or off-line, the remote device A (31) can still register in the linking server group D (23) or the linking server group E (24). Further, if the remote device A (31) is a mobile one, the administration server group 1 may assign the remote device A (31) to a linking server group nearest to the remote device A (31).
The mapping relationship between the remote devices and the linking server groups is shown in Table.1.







TABLE 1







the mapping relationship between the remote


devices and the linking server groups











Codes of





Linking
Serial Numbers of




Servers
Remote Devices
Notes





Service
Ser 01
D01, D02, D03, D04,
Ser 01: Shanghai


Provider A
Ser 02
D05
Ser 02: Tokyo



Ser 03

Ser 03: Los Angeles



Ser 04
D06, D07, D08, D09
Ser 04: New York



Ser 05

Ser 05: Berlin


Service
Ser 11
D11, D12, D13, D14
Ser 11: Paris


Provider B
Ser 12

Ser 12: Cairo









In the example shown in Table.1, the server list of the administration server stores the linking servers Ser 01-Ser 05 managed by Service Provider A and the linking servers Ser 11-Ser 12 managed by Service Provider B. Remote devices D01-D05 are assigned to register in the linking servers Ser 01-Ser 03. D01-D05 are respectively the serial numbers of remote devices. As mentioned above, each remote device has a unique serial number, whereby the administration server or the linking server can verify or recognize the remote device. Requested by proximal devices, the linking servers Ser 01-Ser 03 establish links between the proximal devices and the remote devices D01-D05. As the linking servers Ser 01-Ser 03 have identical functions, they can back up with each other. The linking servers Ser 01-Ser 03 can be respectively arranged in different geographic locations. For example, the linking servers Ser 01-Ser 03 are respectively located in Shanghai, Tokyo and Los Angeles, whereby the remote devices D01-D05 can register in the nearer linking servers. Similarly, remote devices D06-D09 are assigned to register in the linking servers Ser 04-Ser 05. Remote devices D11-D14 are assigned to register in the linking servers Ser 11-Ser 12 managed by Service Provider B. When the remote device D01 accesses the Internet to ask the administration server a linking server, the administration server can simultaneously provide the addresses of the linking servers Ser 01-Ser 05 for the remote device D01, whereby the remote device D01 can find a normal linking server anytime.
In the remote information communication system, the linking server groups back up with each other. Moreover, there are a plurality of linking servers in one linking server group, thus the present invention is formed in a multi-backup structure. Therefore, the present invention is very stable and still operates well even when there are few malfunctions occurring.
Refer to FIG. 9 showing a flowchart of the operation of the linking servers and the administration server. When one or more linking servers access the Internet (Step S01) or when the IPs or ports of one or more linking servers are varied (Step S02), the linking server connects with the administration server via the Internet and transmits a piece of server-registering information to the administration server (Step S03). The administration server verifies the server-registering information and determines whether the linking server is legal in the server list (Step S04). If the linking server is determined to be legal in the server list, the administration server renews the server list according to the server-registering information (Step S05) and acknowledges the linking server that the register is done (Step S06). Thus, the linking server receives the acknowledge (Step S07). In order to guarantee that the administration server records the latest status of the linking server group, Step S03 is executed periodically (Step S09). If the register is unsuccessful in Step S04, it means that linking server does not exist in the server list and is an illegal linking server. In such a case, the administration server acknowledges the linking server that register fails (Step S08), and the linking server receives the acknowledge (Step S07).
Refer to FIG. 10 showing a flowchart of the process that a remote device accesses the Internet to ask the administration server to provide linking servers. Firstly, the remote device sends a request to the administration server for providing the address of a linking server (Step S11). Next, the administration server examines whether the request is valid (Step S12). If the request is valid, the administration server responds to the remote device the addresses of the linking servers (Step S13). If the request is invalid, the administration server responds to the remote device a refusal message (Step S14). Next, the remote device connects with the linking server provided by the administration server. The remote device sends a piece of device-registering information to the linking server (Step S15), and the linking server receives the device-registering information (Step S16). Next, the linking server sends a response to the remote device (Step S17). Thus, the linking server learns the IP and information necessary for communicating with the remote device. To guarantee that the linking server can access the remote device, the remote device returns to Step S15 periodically to resend the information thereof to the linking server (Step S18). The period can be adjustable, for example, it may be preset to be 10 minutes, half an hour, or other suitable time intervals. Thereby, the linking server can frequently learn the latest status of the remote device. By a longer period, the remote device periodically requests the administration server to provide the latest addresses and related information of the linking servers (Step S19). The longer period may be preset to be 24 hours.
Refer to FIG. 11 showing a flowchart of the process that the user uses a proximal device to ask for connecting with a remote device. The user uses API of a proximal device to select a specified remote device. Then, the proximal device requests the administration sever to find out the specified remote device via API (Step S21). The administration server responds to the proximal device with the address of a linking server that the remote device registers (Step S22). Thus, the proximal device learns the linking server whereby it can connects with the specified remote device. Next, the proximal device asks the linking server to establish a link between the proximal device and the remote device (Step S23). The linking server takes priority to perform a hole punching process on the proximal device and the remote device (Step S24). If the hole punching process is successful, the proximal device and the remote device undertake point-to-point transmission (Step S25). If the hole punching process fails, the linking server forwards data packets between the proximal device and the remote device (Step S26).
Via the technique set forth above, the remote device and the linking server needn't directly disclose the IPs and domain names thereof. Therefore, the present invention can reduce the risk of hacker invasion. Further, the proximal device can merely use the administration server to find out a linking server that a specified remote device registers, neither needing a fixed IP nor remembering the IP addresses or domain names of the linking servers. As long as a proximal device has an API supported by the administration server, the user can merely select a remote device to request the administration server to find out the linking address. The remaining procedures, such as interactions with the administration server and the linking server, are all automatically executed by API. Therefore, the present invention can greatly reduce complexity of operation. Furthermore, the present invention allows the manufacturers to vary the quantities, specifications and types of the remote devices and the linking servers as long as the manufacturers log in the administration server and update the device list and the server list. Therefore, the manufacturers can vary the quantities, specifications and types of the remote devices and the linking servers according to load of the apparatuses. In the present invention, the remote devices may be security apparatuses (such as surveillance cameras, anti-theft systems, and smoke/fire alarms) or home electric appliances (such as refrigerators and air-conditioners). In the present invention, the proximal devices should be devices having AV playing functions, such as mobile phones, computers, and personal digital assistants, which are able to play AV information.
In one embodiment, a communication system for establishing a P2P connection, wherein the communication system comprises: a networked device or service device having an identification; at least one linking server for providing connecting information to enable a terminal device or client device to establish a P2P connection between the service device and the client device, wherein the identification of service device is registered in the at least one linking server, wherein the client device communicates with the at least one link server to establish a P2P connection to the service device according to the connecting information provided by the at least one linking server, wherein the client device has not been registered into the at least one linking server when the P2P is established.
Please note that it is not necessary for the client device have an identification in the first place before establishing the P2P connection, which is different from existing technology in which a client device must have an identification and have it registered in the server in order to establish the P2P connection.
In one embodiment, the functionalities of the administration server and the linking server can be integrated into a single connecting server, wherein a service device can register its UID into the connecting server, and a client device can then communicate with the connecting server to establish a P2P connection from the client device to the service device. As long as a client device has the information of the UID of the service device, the client device can contact the connecting server to make a P2P connection to the service node, which means that it is not necessary for the client device to have its own UID. The number of servers needed depends on the scale of the network for serving the client and service devices.
In one embodiment, in addition to the administration server group and the linking server group, a backend management server group can be added to report any failure of the administration servers and/or the linking servers and to perform load balancing among administration servers and/or the linking servers. For example, if one of the administration servers fails, the backend management server can detect such a scenario and redirect all the requests destined to the failed administration server to another administration server. Likewise, if one of the administration servers or linking server is overloaded, the backend management server can detect such a scenario and redirect a portion of the requests destined to an overloaded server to another server for load balancing
In one embodiment, API modules can be integrated into many different platforms. FIG. 12 illustrates the architecture of the IOTC (Internet of Things Cross-platform) 1200 in accordance with one embodiment of present invention. An application layer requests P2P service through an API (application programming interface) 1201, 1202, 1203, 1204, 1205, 1206 for establishing P2P connections through IOTC platform 1210, thereby providing an uniform and integrated solution across platforms with different processors, such as ARM, X86, MIPS, etc., or operating systems, such as Windows, Linux, IOS, Android, etc. Furthermore, a networking layer is provided to communicate with another IOTC platform; and a sensing layer or a device layer for connecting to other devices such as IP cam, RFID, etc.
As integrated circuit technology advances rapidly, more and more designs can be integrated into one IC. By doing so, it not only saves cost but also enables plug and play for connecting devices through P2P connections. FIG. 13A illustrates a block diagram of an integrated circuit 1300 in accordance with one embodiment of present invention. The integrated circuit 1300, comprises: a CPU 1301 or a processor; and IOTC API modules 1303, for establishing a connection to a pre-specified remote device, wherein the IOTC API modules 1303 comprise instructions, when executed by the processor, to request an administration server to provide addressing information of a linking server in which the pre-specified remote device is registered, wherein the IOTC API modules 1303 request the linking server to establish a P2P connection between the integrated circuit and the pre-specified remote device, according to the addressing information of the linking server provided by the administration server.
In one embodiment, as shown in FIG. 13B, the integrated circuit 1350 has IOTC API modules 1303, an operating system module 1304 and a networking module 1305.
In one embodiment, as shown in FIG. 13C, the integrated circuit 1360 has a UID (Unique Identification) module 1302, IOTC API modules 1303, an operating system module 1304 and a networking module 1305. The UID module 1302 performs a registration process to register an electronic device encompassing the integrated circuit 1360 into administration and linking servers so that other devices can establish P2P connections with the electronic device.
In one embodiment, as shown in FIG. 13D, the integrated circuit 1370 has a browser or an application module 1306, IOTC API modules 1303, an operating system module 1304 and a networking module 1305. The browser or application module 1306 can establish P2P connections with a remote device through the API modules.
Please note that API modules, operating system modules, networking modules or CPUs can be packaged in an electronic device such as an IP camera, a mobile phone or a storage device. That is, the CPU and API modules can be packaged into two or more integrated circuits as well. The above description for the integrated circuit can be used for an electronic device as well; therefore it is not further described herein.
FIG. 14A illustrates a block diagram of two connected devices when a P2P connection is established by an administration server and a linking server, wherein one of the two connected devices is a client device 1400, and the other one is a remote service device 1410. The client device 1400 can be integrated into an integrated circuit (IC) or packaged into an electronic device; and the remote service device 1410 can be integrated into an integrated circuit (IC) or packaged into an electronic device. As shown in FIG. 14A, the remote service device 1410 has a CPU 1411, a UID (Unique Identification) module 1412, IOTC API modules 1413, an operating system module 1414 and a networking module 1415. The UID module 1412 performs a registration process to register the remote service device 1410 into administration and linking servers so that the client device 1400 can establish P2P connections with the remote service device 1410. The client device 1400 has a CPU 1401, a browser or an application module 1402, IOTC API modules 1403, an operating system module 1404 and a networking module 1405. The browser or application module 1402 can establish P2P connections with the remote service device 1410 through the API module.
An image sensor can be used to generate an image of a pattern, such as a one dimensional Bar Code or a QR code, for inputting identification information for a terminal equipment, a client device, a networking equipment or an electronic device, so that the inputted identification information can be used to establish P2P connections. Please note that a proxy device such as a mobile phone can input identification information for other terminal equipment or electronic devices through an input device of the proxy mobile phone, such as an image sensor, a keyboard, touch screen, etc.
In one embodiment, FIG. 14B illustrates a block diagram of two connected devices when a P2P connection is established by an administration server and a linking server, wherein one of the two connected devices is a client device 1400, and the other one is a service device 1410. As shown in FIG. 14B, the service device 1410 has a CPU 1411, a UID (Unique Identification) module 1412, IOTC API modules 1413, an operating system module 1414 and a networking module 1415. The UID module 1412 performs a registration process to register the service device 1410 into administration and linking servers, so that the client device 1400 can establish a P2P connection with the service device 1410. The UID module 1412 inputs an image of a pattern, such as a one dimensional Bar Code or a QR code, for inputting identification information of the service device 1410, so that the registration process can use the inputted identification information to register the service device 1410 into the administration and linking servers. The client device 1400 has a CPU 1401, a UID inputting module 1406 to input the identification information of a service device, IOTC API modules 1403, an operating system module 1404 and a networking module 1405. For example, the UID inputting module 1406 inputs the identification information of the service device 1410 in order to establish a P2P connection with the service device 1410 through the IOTC API modules 1403.
In one embodiment, an infrastructure for serving client nodes is disclosed, wherein the infrastructure comprises: a plurality of service nodes, wherein each of the plurality of service nodes has an identification for establishing a P2P connection; and at least one linking server for providing connecting information to enable nodes to establish connections between each other, wherein the identification of the first service node and the second service node are registered in the at least one linking server, wherein the plurality of service nodes provide services to the client nodes through P2P connections respectively, and a P2P connection is established between a first service node and a second service node of the plurality of service nodes.
FIG. 15 depicts an infrastructure for serving client nodes, wherein all the nodes are connected through a network with at least one linking server 1550 for establishing P2P connection among nodes. As shown in FIG. 15, the infrastructure includes a first service node with a IP cam 1501 and a second service node with a storage device 1502 and a plurality of client nodes, such as a mobile phone 1503 or a PAD 1504, but not limited to, wherein P2P connections can be established between the mobile phone 1503, or the PAD 1504, and the first service node with a IP cam 1501 or the second service node with a storage device 1502 through the at least one linking server, wherein the identification of the first serve node and the identification of the first serve node are registered in the at least one linking server for establishing P2P connections among nodes. The storage device 1502 can establish a P2P connection 1510 with the IP cam 1501 to receive the images taken by the IP cam 1501. That is, a service node can not only provide services to client devices, but also can act as a client device to receive services from other service nodes. In addition, a service node can receive services from more than one service node and present a joint presentation to client devices automatically.
The client terminals such as a mobile phone 1503 or a PAD 1504 can receive images from the first service node IP cam 1501, or access the data in the storage device of the second service node 1502 through P2P connections 1511, 1512, 1513, and 1514, respectively. In addition, a connection can be made to connect the second service node 1502 to the first service node 1501 such that the second service node 1502 can act as a client terminal to receive images of the first service node 1501 and store them into the storage device. A mobile phone 1503 can access the stored images of the IP cam or live images from the IP cam directly. That is, a machine to machine connection can be set up for providing more dynamic and useful services to client devices such a mobile phone, notebook, pad, etc. In one embodiment, a plurality of IP cam service nodes can transfer images to the storage device of the second service node so that a client terminal such as a mobile phone can access all the images of the IP cam(s) from the second service node. In one embodiment, the second service node is located in a cloud storage farm. That is, a machine to machine interface can be established between service nodes, and a service node can integrate a client node into itself to provide an integrated service to client devices.
In one embodiment, in the infrastructure described above, the identifications of service nodes are registered in the at least one linking server, wherein the management interface can be provided to provision a connection between any two service nodes to provide more services to client devices. In one embodiment, the identifications of service nodes are registered in the at least one linking server, wherein each service node can input the identification of a remote service node to establish a connection between them dynamically. In summary, there are many ways to connect the service nodes such that any number of the service nodes can be connected to one another to provide integrated services to client terminals.
In one embodiment, the identification of the second service node is registered in the at least one linking server, wherein the first service node communicates with the at least one link server to establish a P2P connection between the first service node and the second service node, according to the connecting information provided by the at least one linking server.
In one embodiment, in the infrastructure described above, the identification of the first service node is registered in the at least one linking server, wherein a first client node communicates with the at least one link server to establish a P2P connection to the first service node according to the connecting information provided by the at least one linking server.
In one embodiment, an electronic device, comprising: a processor; and at least one module, comprises instructions, when executed by the processor, to establish P2P connections with a plurality of client nodes respectively, wherein the electronic device acts as a first service node to provide service to the plurality of client nodes; and to establish a P2P connection with a second service node, wherein the electronic device acts as a client node to receive service from the second service node.
In one embodiment, FIG. 16 illustrates a block diagram of an integrated service node which can provide service to client devices and can act as a client node to receive services from other service nodes. As shown in FIG. 16, the service device 1600 has a CPU 1601; a UID (Unique Identification) module 1602 for registration to a link server for establishing P2P connections with client devices; a UID (Unique Identification) inputting module 1603 for inputting an identification of a remote service node and for establishing a P2P connection with the remote service node; IOTC API modules 1614, an operating system module 1615 and a networking module 1616. The UID module 1602 performs a registration process to register the service device 1600 into administration and/or linking servers, so that client devices can establish a P2P connection with the service device 1600. The UID inputting module 1603 inputs an identification of a remote service node for establishing a P2P connection with the remote service node, wherein the input format can be an image pattern, such as a one dimensional Bar Code or a QR code, for inputting identification information of the remote service node, so that the registration process can use the inputted identification information to establish a P2P connection between the service device 1600 and the remote service node.
The foregoing descriptions of specific embodiments of the present invention have been presented for purposes of illustrations and description. They are not intended to be exclusive or to limit the invention to the precise forms disclosed, and obviously many modifications and variations are possible in light of the above teaching. The embodiments were chosen and described in order to best explain the principles of the invention and its practical application, to thereby enable others skilled in the art to best utilize the invention and various embodiments with various modifications as are suited to particular use contemplated. It is intended that the scope of the invention be defined by the claims appended hereto and their equivalents.

## Claims

1. An infrastructure, comprising:
a plurality of service devices and at least one linking server, wherein each of the plurality of service devices has a unique identification to identify a corresponding Internet protocol address of the service device for establishing a point-to-point (P2P) connection
wherein each of the unique identifications are registered in the at least one linking server, wherein the at least one linking server comprises a mapping to map each of the unique identifications to a corresponding Internet protocol address for establishing P2P connections, wherein a first identification of a first service device and a second identification of a second service device are registered in the at least one linking server, wherein the plurality of service devices provide services to a plurality of client devices through P2P connections respectively, wherein a first client device communicates with the at least one linking server to establish a first P2P connection between the first service device and the first client device according to the first unique identification of the first service device, and the second service device communicates with the at least one link server to establish a second P2P connection between the first service device and the second service device according to the said first unique identification of the first service device, the second service device acting as a client device to receive a service from the first service device through the second P2P connection.

2. The infrastructure according to claim 1, further comprising an administration server connected to the at least one linking server for establishing P2P connections through Internet, wherein the administration server associates a linking server of at least one linking server to each of the plurality of service devices, wherein each of the service device registers in a corresponding linking server, respectively.

3. The infrastructure according to claim 1, wherein the first service device communicates with the at least one link server to establish a third P2P connection between the first service device and the second service device according to the said second unique identification of the second service device.

4. The infrastructure according to claim 1, wherein the first client device communicates with the at least one link server to establish a fourth P2P connection to the second service device according to the said second unique identification of the second service device.

5. The infrastructure according to claim 1, wherein a second client device communicates with the at least one link server to establish a fifth P2P connection between the second client device and the second service device according to the said second unique identification of the second service device.

6. The infrastructure according to claim 1, wherein a second client device communicates with the at least one link server to establish a sixth P2P connection-between the second client device and the first service device according to the said first unique identification of the first service device.

7. The infrastructure according to claim 1, wherein each of the client devices is not registered in the at least one linking server to identify the corresponding Internet protocol address of the client device.