Connection method and computer-readable medium for use in a private communication architecture

Connection method and computer readable medium for private communication architecture

CONNECTION METHOD AND COMPUTER-READABLE MEDIUM FOR USE IN A PRIVATE COMMUNICATION ARCHITECTURE

The present invention is related to the Internet. Specifically, the present invention relates to an application on a private cloud network.

In the Internet-connected environment, smart device clients, including smart phones, tablet computers, e-book readers, notebook computers, personal computers, and various smart devices, are very common and ubiquitous. . In addition to an Internet connection, one of the values of a smart device client is that it can access services from one or more servers anytime, anywhere. These services include voice, video content, live or archived information, application execution, social media, messaging, email, stored media, backup, calendaring, contacts, synchronization, sharing, remote desktop, and Internet of Things ( Internet of Things; IoT), etc. Other services include real-time private and secure video, voice, text and application communication between at least two smart device clients.

There are different types of servers to meet the needs of various smart device clients. Generally speaking, these types of servers can be divided into two groups: a public cloud and a private cloud. Public cloud servers, as the name suggests, "public", provide free but limited functionality or paid and more refined services, as well as interact with the public. Examples of public cloud servers include data centers, social media services, and storage content providers on the Internet. On the other hand, private cloud servers tend to cater for private needs. Compared to public clouds, servers in private clouds provide more privacy and personalization.

An example of a private cloud server application is a private cloud storage server (PCSS). The private cloud storage server is located in a local area network (Local Area Network; LAN) managed by a user. It provides users with online and backup storage in the local area network or wide area network (Wide Area Network; WAN). Users can use the smart device client to access information from the private cloud storage server at any time and anywhere. The private cloud server and the related smart device client thus form a structure of the private cloud server and the client.

Traditionally, there are many solutions for storage servers, including Network Attached Storage (NAS), Windows/Mac/Linux servers, and Direct Attached Storage (DAS) for private cloud storage server requirements. However, the challenge faced by smart device clients in the field is how to avoid cumbersome installation to penetrate the firewall behind the LAN router to access the private cloud storage server in the home or office environment. There are at least four solutions to this challenge.

One solution is to assign a fixed Internet Protocol (IP) address and open a port on the front-end router of the private cloud storage server, such as smart device clients that can probe the private cloud from outside the local area network Storage server and self-authentication, penetrating firewall and establishing a secure communication channel with private cloud storage server.

The second solution is for when a fixed IP address is not obtained. The user installs the router of the private cloud storage server LAN and opens the port corresponding to the private cloud storage server. The router can thus be detected by the smart device client via the floating Domain Name System (DDNS) service on the WAN. The smart device client can authenticate itself, penetrate the firewall and establish a secure communication channel connected to the private cloud storage server.

The third solution relies on another routing server in the WAN to connect the virtual private network (VPN) between the smart device client and the private cloud storage server. The virtual private network communication allows the smart device client to find out the location of the private cloud storage server, authenticate itself, penetrate firewalls, and establish a secure communication channel connected to the private cloud storage server.

The fourth solution relies on another routing server in the WAN to communicate the Remote Desktop Protocol (RDP) or Virtual Network Computing (Virtual Network Computing) between the smart device client and the private cloud server; VNC) communication. The RDP or VNC communication allows the smart device client to find out the location of the private cloud server, authenticate itself, penetrate firewalls, and establish a secure communication channel with the private cloud server. Other solutions are combinations of the above solutions.

In the first scenario, a fixed Internet Protocol address is required, and the router needs to be installed. Fixed Internet Protocol addresses involve higher costs and are generally not suitable for use in home and small business environments. Therefore, the router installation is very complicated and not easy for most consumers to use.

In the second scenario, a DDNS service is required and the router requires a more complex installation. The DDNS involves additional cost and system complexity. Therefore, the router installation is very complicated and not easy for most consumers to use.

In the third and fourth scenarios, when the installation of a router is not necessary, an external routing server or service needs to be installed. An external routing server or service is used to control and manage the login or authentication between the smart device client and the server. With a public cloud server or service, a private cloud becomes less private and less secure. In addition, if the server or service is weakened for any reason, the communication or availability of the private cloud server will be compromised.

The technical expertise required for the above solution may be applicable in a traditional monolithic environment, but not in a consumer-oriented smart device client-centric arrangement.

In most traditional systems, an external or public cloud routing server is used by smart device clients to access private cloud services. Using an external server raises many concerns for smart client owners.

First, trust has always been an issue because routing servers on the outside or in the public cloud act as a middleman in the handling of communications between smart smart clients and private cloud services. It holds account information, passwords, and their Internet Protocol addresses for all smart device clients and users of private cloud services. It becomes insecure because the routing server can detect any kind of communication in between.

Second, as a routing server in an external or public cloud, the business model of the owner of the server may not always be the same as the owner of the smart device client. If the routing server is out of service for any business reason, there is no remedy or alternative option to restore service. Routing servers potentially pose a huge business risk to users, such as links that are essential to communication being destroyed without cost.

Traditionally, in the case of communication between two smart device clients, both parties need to log in to a public cloud server for real-time video, voice, text and application communication. As mentioned above, privacy and security are easily compromised because the communication has to go through a public cloud server.

In view of this, there is an urgent need for a system and method for solving the above problems. The present invention meets this need.

To solve at least the above problems, embodiments of the present invention provide a method for use with a public cloud network. The method may include configuring at least one virtual machine, at least one private cloud callback server, at least one smart device client on the side of the private cloud callback server for providing cloud network services, at least one private cloud router The server and the at least one smart device client on the side of the private cloud routing server, the at least one virtual machine, the at least one private cloud callback server, and the private cloud callback for providing cloud network services The at least one smart device client on the server side, the at least one private cloud routing server, and the at least one smart device client on the private cloud routing server side are in a client server relationship. The virtual machine and the private cloud callback server are usually set up in a super-large data center, and the private cloud routing server is set up on the remote factory equipment of the client.

The private cloud callback server acts as a middleman to relay the communication between the smart device client on the side of the private cloud callback server and the private cloud routing server. The private cloud callback server can call back to the private cloud routing server according to the request of the smart device. The at least one private cloud callback server includes a first message box associated therewith. The first message box is located in the private cloud callback server on a public cloud network. The smart device client includes a second message box associated therewith. The second message box is located in the private cloud callback server on the public cloud network. The at least one private cloud callback server is located in a public cloud network. The third message box associated with the private cloud routing server is located in the private cloud callback server on the public cloud network. The method also includes transmitting a conference message between the first message box and the second message box, and transferring a conference message between the second message box and the third message box by a secure method.

The secure conversation message connection mechanism between the private cloud routing server, the private cloud callback server and at least one smart device client includes: initializing and preparing the private cloud callback server, creating a private cloud callback Server client, viewing the private cloud callback server client, editing a private cloud callback server peer-to-peer password and a state through a system administrator, and modifying the private cloud callback through the at least one smart device client server peer-to-peer password, reset the private cloud callback server peer-to-peer password and the status from a private cloud callback server LAN via a system administrator, and connect to the private cloud via the at least one smart device client Cloud callback server. The meeting message is verified by the private cloud routing server, the private cloud callback server and at least one smart device client. The smart device client, the private cloud routing server and the private cloud callback server can communicate with each other after the meeting message is authenticated.

According to the verified conversation message, the at least one smart device client securely accesses a private network service through the public cloud network. The method also includes configuring the at least another smart device client, the at least another smart device client being in a client server relationship with the at least one private cloud routing server and the at least one private cloud callback server middle. The at least two smart device clients can communicate with each other after the meeting message is authenticated. The at least two smart device clients can communicate privately and securely through the public cloud network. By using the private cloud callback server between the smart device client and the private cloud routing server, all types of IP address translation (Network Address Translation) in a local area network environment can be passed more efficiently. ; NAT) routers without using traditional hole-punching techniques. Due to the emergence of 5G, 6G and Wi-Fi 6 network technologies, the communication performance is significantly improved through the private cloud callback server to minimize the communication delay. In order to access from one smart device client anywhere in the world to another smart device client or an IoT device in the home, the present invention has the advantages of easy deployment, high privacy and security, full compatibility and high performance .

The present invention is related to the Internet. Specifically, the present invention relates to an application on a private cloud network. The following description is provided for those of ordinary skill in the art to which the present invention pertains to know and use the present invention, and to present the relevant content required for filing a patent application of the present invention. Those skilled in the art to which the present invention pertains can easily understand other embodiments of the present invention based on the embodiments described below and the principles and features substantially the same as those of the present invention. Therefore, the present invention is not limited to the embodiments of the following embodiments, but is to be accorded the widest scope consistent with the substantially same principles and features of the present invention.

In the following description, "client" may be equivalent to "smart device client", and "router" may be equivalent to "gateway", "access point" or "Internet Protocol Address Translation".

The smart device client in the wide area network of the present invention can obtain services from a private cloud storage server (Private Cloud Storage Server; PCSS) or any private cloud server (Private Cloud Server; PCS), so the system of the present invention and The method addresses the following challenges faced by users in the usage environment: <br/>.Access your private cloud server anytime, anywhere. <br/>.Access a private cloud server with a fixed or floating Internet Protocol (hereinafter referred to as IP) address behind a firewall. <br/>.No need for a public cloud-based routing server in the WAN. <br/>. No need to set up additional routers in the local area network. <br/>.Authenticate to the private cloud server. <br/>. Establish a secure communication channel with the private cloud server.

If the present invention can overcome and solve the above-mentioned challenges, the deployment of private cloud servers or services will be able to grow exponentially due to the simple plug-and-play feature of the present invention. Even without the use of public cloud-based routing servers, technical and commercial issues related to the field of the present invention are eliminated. As a result, private cloud servers for storage, remote desktops, and IoT will become very affordable and pervasive in private cloud infrastructure.

In the private cloud environment, if multiple private cloud servers or services coexist at the same time, the private cloud servers are divided into Private Cloud Routing Service (PRS) and Private Network Service (Private Network Service); PNS) two functional blocks are advantageous. Through smart device clients, private network services are managed and accessed in a private network environment (wired or wireless). For example: Remote Desktop Protocol (RDP), VNC software (Virtual Network Computing), Office Tools software, media players and other special user applications. The private network service can also act as a storage server, which can include multiple terabytes of storage space for the private cloud. Then, the private network service functions of a plurality of private cloud routing servers (hereinafter referred to as "PCRS") can be integrated into one PCRS. PCRS is also commonly referred to as "Private Cloud Router".

The smart device client in the WAN of the present invention can manage and access private network services from the PCRS, so the system and method of the present invention solve the following challenges faced by users in the usage environment: <br/>.Access PCRS anytime, anywhere. <br/>.Access PCRS with a fixed or a floating IP address behind a firewall. <br/>. No need for external or public cloud-based routing servers in the WAN. <br/>. No additional routers are required in the LAN. <br/>.Validate PCRS. <br/>. Establish a secure communication channel with the private network service.

If the PCRS of the present invention can solve the above-mentioned challenges, the disparate private cloud servers of different manufacturers and suppliers can be split into simpler private network services, and the complexity of private cloud setup, configuration and access can be eliminated issue of sex.

The purpose of the system and method of the present invention is to provide a PCRS, private network server and client architecture without using a routing server. The system and method of the present invention meet the above challenges, that is, a client can access the private network server anytime and anywhere. The system and method can also access the private web server behind a fixed or floating IP firewall to authenticate with the PCRS and establish a secure communication channel directly with the private web server without Requires additional routing settings in the WAN or routing servers in the public cloud.

As shown in FIG. 1 , a cloud network architecture includes a public cloud 100 , a public cloud server 113 , a public routing server 112 , a virtual private network (hereinafter referred to as VPN) routing server 114 , in the wide area network A smart device client 101 , a router (Router_P) 102 and a router (Router_S) 103 . The router 103 is used to connect the local area network (LAN) 105 and the network of the public cloud 100 . The router 102 is used to connect the local area network (LAN) 104 and the network of the public cloud 100 . At the back end of the local area network 104 , there are smart device clients 106 and 107 and a private cloud server 108 . At the back end of the local area network 105 , there are smart device clients 109 , 110 and 111 . These smart device clients can be a personal computer, notebook computer, tablet computer, e-book reader, GPS, smart TV, set-top box, MP3 player or any embedded device with internet access.

They are labeled 101, 106, 107, 109, 110, and 111 in the cloud network architecture. Any of the above-mentioned smart device client terminals can be arbitrarily replaced in this document. The following description will be made with a representative smart device client 109 .

Physically, there are three situations in which the smart device client 101 , 107 or 109 is connected to the private cloud server 108 . First, the smart device client 107 determines whether the target is located in an accessible area of the local area network 104 , and decides to directly connect to the private cloud server 108 . Second, the smart device client 101 determines that the target is not located in the accessible area of the local area network 104, and decides to connect to the public cloud 100 via the WAN. The WAN can find out the location of the router 102 and the local area network 104 , and then connect to the private cloud server 108 . Third, the smart device client 109 determines that the target is not located in the accessible area of the local area network 105 , and decides to connect to the public cloud 100 in the WAN through the local area network 105 and the router 103 .

The smart device client 109 then finds out the location of the router 102 and the local area network 104 and connects to the private cloud server 108 . The above-mentioned first and second cases are two derivative special cases of the above-mentioned third case. Therefore, the third case, which has a wider range and complexity of applications, is beneficial.

The routing server message box (not shown) or client message box 215 may be hosted on one of an email server, a text message server, a web server, or any type of server that Can host a server (PCRS 208 and private cloud callback server (hereinafter referred to as "PCCBS") 216) and a client (smart device client 206, 207, 209, 210, 211, 201 and 221) of A secure message for the exchange of information between. The callback server message box (not shown) or client message box_S (Client Message Box Message_box_S) 215 is accessible, and a server (PCRS 208 and PCCBS 216) and a client (intelligent under the secure and private control of the device clients 206, 207, 209, 210, 211, 201 and 221). The security and business model of the message box have been fully understood and expected by users in the industry. For whatever reason, when the message box is stopped, it can be replaced or redeployed immediately without compromising the communication between the server and the client in the private cloud architecture.

The first embodiment of the present invention is a cloud network infrastructure, which is depicted in FIG. 2 . In this embodiment, the secure connection mechanism between PCRS, PCCBS and smart device client is used for exploring and accessing private network services across public clouds. As shown in FIG. 5 to FIG. 15 , the smart device clients 201 , 211 and 221 pass through the communication paths 222 , 224 and 223 , respectively, to locate the PCRS 208 . Additionally, PCRS 208 and PCCBS 216 build a virtual local area network (VLAN) 240 and a virtual local area network 2400 that allow authorized smart device clients 201, 211 and 221 to join the virtual local area network 240 and virtual local area network Road 2400 as a member. The smart device client 201 can act as a host through the installed program to initiate a private and secure communication. The smart device client 201 or 221 can act as a guest through the installed program to receive the communication invitation and join the private and secure communication session with the smart device client 201 .

As shown in FIG. 2 , when the smart device client 201 as a host wants to start a communication session, the program installed on the smart device client as the host first locates and logs into the PCCBS 216 through the communication path 222 . After PCCBS 216 locates PCRS 208 , it joins virtual area network 240 . The smart device client as the host 201 promises to join the chat communication. The program allows the smart device client to create and host a communication session. The program broadcasts the host talk to invite the newsletter guest 221. Next, the program starts scanning for identifiable visitors. Once the identity of the visitor is authenticated, the smart device client 201 can act as a host for private and secure communication with the authenticated visitor (smart device client) 221 . This private and secure communication includes video, voice, text and application communication. The application communication can be a program, utility (hereinafter referred to as Utility), operation or remote desktop recognized by both the host and the guest.

If the smart device client 211 or 221 as a guest wants to join a communication session, the program installed in the guest (smart device client) first locates and logs into the PCCBS 216 through the communication path 224 or 223 respectively. After the PCCBS 216 locates the PCRS 208, it joins the virtual local area network 240 under the server. The smart device client as the client promises to join the chat communication. The program waits for a newsletter invitation. Once it receives the communication invitation, the smart device client 211 or 221 can join a communication session as a guest. Next, the program starts scanning for identifiable visitors. After the program recognizes the host, it performs the communication login verification prompted by the host. Once authenticated, the smart device client can join the communication session. The smart device client 211 or 221 performs private and secure communication with the host (smart device client) 201 as a guest. This private and secure communication includes video, voice, text and application communication. The application communication can be a program, utility, operation or remote desktop recognized by both the host and the guest.

In another embodiment of the present invention, the smart device client can establish a private and secure communication with any service, as long as it is the physical area network 250 or the virtual area network 240 and virtual Any service that the local area network 2400 can reach. As shown in FIG. 2 , once the smart device client 201 , 211 or 221 locates and logs into the PCCBS 216 , it can access the virtual area network under the physical area network 250 , 260 or PCRS and PCCBS through the communication path 225 240 and the private network service 228 reachable by the virtual area network 2400. The private network service includes voice, video content, live or archived information, application execution, social media, messaging, email, stored media, backup, calendar, contacts, synchronized video, sharing, remote desktop And the Internet of Things (Internet of Things; IoT), etc.

In some embodiments, the communication path 225 between the PCRS, the PCCBS and the smart device client may include the following complex set of instructions: <br/>.Initialize and prepare a PCRS (through the administrator of the local area network from the PCRS). <br/>.Initialize and prepare a PCCBS (through the WAN administrator from the PCCBS). <br/>.Create a PCRS client (via the PCRS administrator from the local area network). <br/>.Register to a PCCBS (via the PCCBS client from the WAN). <br/>.Connect to a PCCBS (through the PCCBS server client from the WAN). <br/>.View a PCCBS client (via the system administrator from the PCCBS WAN). <br/>.Reset a PCCBS peer-to-peer password and status (via the system administrator from the PCCBS WAN). <br/>. Modify a PCCBS peer-to-peer password and status (via the PCCBS client from the WAN and via a VPN).

Many kinds of entities are introduced as the secure communication channel 225, including but not limited to: System Administrator, Administrator Device, PCRS Utility, PCCBS Utility, PCRS Device Client, PCCBS Device Client, Invitee, Invitee Device . These entities are defined below. Utility refers to the utility running in the PCRS. The administrator device refers to the device used by the system administrator to configure the PCRS. The PCRS device client refers to the device used by the invitee to communicate with the PCRS. Invitee means an entity party who is invited to access the PCRS's services and resources through an administrator. The invitee device refers to a smart device client used by the invitee to communicate with the PCRS.

Many related terms are introduced, including: Access Code (Access_Code), Code Expiration Time (Code_Expiration), Invitee Address (Address_Invitee), PCRS Client Address (Address_PCRS_Client), PCRS Client Peer-to-Peer Hash Password ( Hash_Password_PCRS_P2P), PCRS peer-to-peer password expiration time (Password_PCRS_P2P_Expiration), and PCRS client database status (Status in PCRS Client database). The definitions of these terms are as follows. Access_Code refers to an invitee access code issued by the PCRS via the message box 216 by the administrator. Code_Expiration refers to the expiration date/time of the access code for security purposes. Address_Invitee refers to the Invitee's message box address. Address_PCRS_Client refers to the message box address of the PCRS client, which may be different from the message box address of the invitee. Hash_Password_PCRS_P2P refers to a hashed password used for peer-to-peer communication with the PCRS, which is stored in the PCRS client database (PCRS Client database), and for security reasons, the actual hashed password is never stored in the PCRS. Password_PCRS_P2P_Expiration refers to the expiration time of Hash_Password_PCRS_P2P. Status in PCRS Client database refers to the in-service, non-in-service or deleted status of the PCRS client recorded in the PCRS Client database.

In addition, other terms not related to the PCRS client database include: PCRS address (Address_PCRS), PCRS password (Password_PCRS), PCRS client password (Password_PCRS_Client), and virtual LAN subnet (Virtual LAN subnet). The definitions of these terms are as follows. Address_PCRS and Password_PCRS are the message box accounts used to configure the PCRS, which are only used once during initialization and preparation of the PCRS, and are not stored for security purposes. Address_PCRS_Client and Password_PCRS_Client are used to configure the message box account of the PCRS client and are only used once during the creation of the PCRS client in the database. Although Address_PCRS_Client is stored in the database, Password_PCRS_Client is never stored for security purposes. Virtual LAN subnet refers to the subnet of the VPN, which is configurable and modifiable for security purposes.

As shown in FIG. 2 , the PCRS 208 includes a PCRS_Utility 270 , which further includes a PCRS Client database 271 and a router server message box Utility 272 . The PCRS Client database 271 contains the registration list of PCRS clients. The router server message box Utility 272 can communicate with the callback server message box (not shown).

The administrator device 273 is a smart device client 207, which includes a PCRS application Utility (PCRS_App) 274, which further includes a PCRS Server database 275 and a client message box Utility 276 . PCRS Server database 275 contains a list of PCRS registrations. The client message box Utility 276 can communicate with the client message box 215 .

The PCCBS device client 201 is a smart device client, which includes a PCCBS application Utility (PCCBS_App) 278, which further includes a PCCBS Server database (PCCBS Server database) 279 and a client message box Utility ( Client Message Box utility) 280. PCCBS Server database 279 contains the registration list of PCCBS. A message box utility (Message Box utility) 280 can communicate with the client message box 215 .

The Invitee Device 281 is a smart device client 221 , which includes a Client Message Box utility 282 . The client message box utility 282 can communicate with the client message box 215 . As shown in FIG. 5, the system administrator uses the PCRS_App 274 from the administrator device 207 to initialize and prepare the PCRS 208. Both the administrator device 207 and the PCRS 208 are located on the physical area network 204, and are configured for security purposes to avoid hacker attacks on the Internet or WAN. First, the system administrator configures the authentication of the PCRS message box by setting his account name and password. Afterwards, the authentication of the PCRS message box is sent to the PCRS Utility 270 in the PCRS 208.

The PCCBS 216 includes a PCCBS Utility 2700 , which further includes a PCCBS Client database 2710 and a Routing Server Message Box utility 2720 . PCCBS Client database 2710 contains the registration list of PCCBS clients. The message box Utility 2720 can communicate with the callback server message box (not shown). As shown in Figure 6, the system administrator 277 also uses the PPCBS_App 278 to create a PCCBS client account. The system administrator 277 is a PCCBS device client 201 , which sets the invitee notification address in the PCCBS_Device_App (marked as 605 ). Next, the PCCBS is required to send the connection invitation to the callback server message box (not shown) through the callback server message box Utility 2720, and finally to the invitee device 281 through the client message box 215, and the invitee device 281 is the client message box Utility 282. It should be noted that both the callback server message box and the client message box 215 are hosted in the message box server. Examples: email servers, web servers, and message servers. In addition, logically, the callback server box and the client box 215 may be the same or different. After the invitee receives the invitation (marked as 620 ), it will retrieve the PCCBS_Device_App from the PPCBS_App link (marked as 621 ), and install the PPCBS_App on the intended PCCBS device client 201 . On the same physical device as the PCCBS device client 201, the invitee device 281 is not required. The system administrator must know the invitee's message box address (labeled 605) in order to issue an invitation.

As shown in FIG. 7 , on the intended PCCBS device client 201 , the invitee launches the PCCBS_Device_App (marked as 700 ) and registers with the PCCBS (marked as 701 ). At this time, the role of the invitee is changed to the PCCBS client on the PCCBS device client 201 . Afterwards, the PCCBS client configures the authentication of the client message box by setting the account name and password, and registers the authentication to the client message box 215 . Next, the previously received Address_PCCBS and Access_Code are retrieved from the invitee device 281 and sent to the PCCBS (marked as 710 ) with the client message account Address_PCCBS_Client via 740 . After authentication through PCCBS Utility 2700 within PCCBS 216, a set of peer-to-peer connection authentication 714 including Password_PCCBS_P2P is generated. The actual password is sent to the invitee device 281 via the client message box 215 . The hashed password and other client authentications are stored in the PCCBS Client database. For security reasons, actual user end-to-end passwords are never stored in PCCBS 216. However, the hash value is stored for comparison in authentication 716 . Once the PCCBS device client 201 receives its confirmation of the registration 707 from the PCCBS 216 , it records the Address_PCCBS of the PCCBS in the PCCBS server database 279 in the PCCBS_Device_App 278 .

As shown in Figures 6, 9 and 10, PCCBS_Device_App provides the following four commands for the administrator device: Initialize and Provision, Create a Client, View PCCBS Client And reset PCCBS P2P Password/Edit Attributes (Reset PCCBS P2P Password/Edit Attributes). Whenever an administrator operates, access to the PCCBS is only allowed from the PCCBS virtual area network (physical or virtual) for security reasons. Due to access restrictions, the PCCBS settings and configurations are only performed on the PCCBS virtual area network to avoid network traffic monitoring and hacker attacks.

As shown in Figures 7, 8 and 11, PCCBS_Device_App provides the following three commands for PCCBS clients: "Register to a PCCBS", "Change P2P Password" and "Connect to PCCBS ( Connect to PCCBS)". As shown in Figure 7, regarding the "Register to a PCCBS" command, the PCCBS client can run PCCBS_Device_App and connect to the PCCBS Utility from the WAN or the PCCBS virtual network, because the PCCBS client is connected to the PCCBS utility. The communication exchange between the PCCBS Utility registered to a PCCBS is through the client message box 215 and the callback server message box (not shown). As shown in Figure 11, about "Change P2P Password (Change P2P Password)" command, for security reasons, after the WAN is securely connected to the VPN, the PCCBS device client must run the PCCBS_Device_App on the PCCBS virtual network, because the peer-to-peer password can only be reset on the PCCBS virtual network. The only way for PCCBS device clients to connect to the PCCBS virtual network is to connect through a secure VPN. As shown in Figure 8, regarding the "Connect to PCCBS" command, the PCCBS device client has not yet connected to the PCCBS from the WAN or the PCCBS virtual network. A secure and private connection between the PCCBS device client and the PCCBS is a condition for this command to run PCCBS_Device_App. The PCCBS 216 acts as a middleman to relay communications between the smart device clients 201 , 211 , 221 and the PCRS 218 . It will call back the PCRS according to the request of the client of the smart device.

FIG. 3 illustrates a second embodiment of the present invention. Similar to the method disclosed in FIG. 2 , that is, the PCRS 208 is connected to the router (Router_P) 202 of the local area network, wherein the PCRS 308 is connected to the router (Router_P) 302 of the local area network. PCRS 308 may also be connected to a downstream physical virtual network 360. A private network service 336 and a smart device client 335 are connected downstream. The private network service 336 is accessible through the communication path 326 and can be connected to the PCRS 308 through the local area network 334 . As long as the PCCBS 316 is used, the virtual area network 340, the physical area network 350, 360 can be explored and accessed across the cloud by the smart device clients 311, 309, 301, 321, 306 and 335, and the PCRS 308, private Both web services 328, 336 and smart device clients 306, 335 become accessible.

Figure 3 illustrates a third embodiment of the present invention. PCRS 408 is connected to the cloud and has a public IP (public_IP_P) 417 . PCRS 408 is also connected to a downstream physical area network 460 . A private network service 436 and a smart device client 435 are connected downstream. Private network service 436 is accessible through communication path 426 and can be connected to PCRS 408 through local area network 434 . As long as the PCCBS 416 is used, the virtual area network 440, the physical area network 450, 460 can be explored and accessed across the cloud by the smart device clients 411, 410, 409, 401, 421 and 435, and the PCRS 408, private Both the web service 436 and the smart device client 435 become accessible.

FIG. 5 illustrates a flow diagram of initializing and preparing communications for the PCRS by the PCRS administrator according to the present invention. As shown in FIG. 5 , from the perspective of a PCRS Admin Device, in step 500 , the PCRS Admin Device is connected to the PCRS network on the local area network. In step 501, the PCRS_Device_App is opened on the PCRS local area network. In step 502, the PCRS Address_PCRS on the local area network is detected and selected. In step 503, select the "Initialize and Provision" command on PCRS_Device_App. In step 504, the identity of the PCRS is set by setting the address (Address_PCRS) and the password (Password_PCRS). In step 505, use the administrator's authentication (Initialize and Provision, Admin_name, Admin_password, Address_PCRS, Password_PCRS) to log in to PCRS. At step 540, the authentication is sent to PCRS Utility (labeled 510). At step 506, the administrator waits for PCRS verification. In step 507, configure the subnet of the virtual local area network and the PCRS App link. At step 542, the PCRS Utility (marked as 514) is sent. In step 508, if necessary, the PCRS is used as a client to join the existing AP router. At step 543, this information is sent to PCRS Utility (labeled 516).

In step 510, from the perspective of PCRS Utility, the identity verification (Initialize and Provision, Admin_name, Admin_password, Address_PCRS, Password_PCRS) of the PCRS administrator (PCRS Admin) is accepted. In step 511, the authentication of the administrator (Admin_name, Admin_password) is verified. In step 541, the authentication (Address_PCRS, Password_PCRS) is transmitted to the administrator device (marked as 506). In step 512, the identity verification (Address_PCRS, Password_PCRS) is stored as the identity of the PCRS. In step 513, the identity verification (Address_PCRS, Password_PCRS) is registered to the router server message box. In step 514, the subnet of the virtual local area network and the PCRS App link are stored. At step 515, a PCRS_Profile file is generated and saved, which includes the interface protocol, certificate and key. In step 516, if necessary, join the existing AP router as a client.

6 illustrates a flow chart of creating a client communication for PCCBS through the PCRS Admin (PCCBS Admin) according to the present invention. From the perspective of the PCRS Admin Device 201 (PCCBS Admin Device 201 ), first, in step 600 , the PCCBS_Device_App is opened on the WAN. In step 601, the PCCBS 216 located at the Address_PCCBS is detected and selected. In step 602, select the "Create a Client" command on the PCCBS_Device_App. In step 603, the invitee notification address Address_Invitee is set. In step 604, log in to PCCBS 216 using the administrator's authentication (Create a Client, Admin_name, Admin_password, Address_Invitee). At step 640, the authentication is sent to PCCBS_Device Utility. At step 605, the system administrator 277 waits for PCCBS verification.

In step 610, from the perspective of the utility of the PCCBS device, firstly accept the identity verification (Create a Client, Admin_name, Admin_password, Address_Invitee) of the PCCBS administrator (PCCBS Admin). In step 611, the identity authentication (Admin_name, Admin_password) of the administrator is verified. In step 641, the authentication is transmitted to the administrator device. In step 612, the Access_Code is generated, and its Code_Expiration is generated. In step 613, the Access_Code, Code_Expiration, and Address_Invitee are stored in the PCCBS device client database (PCCBS_Device Client database) items (Access_Code, Code_Expiration, Address_Invitee, Address_PCCBS_Device_Client, Hash_Password_PCCBS_Device_P2P, Password_PCCBS_Device_P2P_Expiration, Status). In step 614, an invitation is sent to the invitee notification address Address_Invitee, which includes the PCCBS_Device application link, Address_PCCBS_Device, Access_Code and Code_Expiration. At step 642, it is sent to the invitees (labeled 620).

From the perspective of the invitee device (Invitee Device), in step 620, the invitations for Address_Invitee, PCCBS_Device app link, Address_PCCBS_Device, Access_Code and Code_Expiration are accepted. In step 621, PCCBS_Device_App is retrieved from PCCBS_Device app link. In step 622 , install the PCCBS_Device_App on the PCCBS device client 201 , 209 , 210 or 211 .

FIG. 7 illustrates a flow chart of the communication of the PCCBS Device Client registering with the PCCBS according to the present invention. From the perspective of the PCCBS device client, in step 700, the PCCBS_Device_App is opened on the WAN or PCRS local area network. In step 701, if necessary, first create a PCCBS device client address (Address_PCCBS_Device_Client) (not shown), and then select "Register a Private Cloud Call-Back (Register a Private Cloud Call-Back) on the PCCBS_Device_App. Server)" command. In step 702, if the PCCBS device client has not been configured, the Address_PCCBS_Device_Client and Password_PCCBS_Device_Client are set. In addition, in step 702, Password_PCCBS_Device_P2P is the message box password associated with the address of the message box (not shown) of the client side of Address_PCCBS_Device_Client used for peer-to-peer communication, and Address_PCCBS_Device_Client and Password_PCCBS_Device_Client are registered to the message box of the client side. In step 703, the Address_PCCBS_Device and the Access_Code are retrieved from the invitee. This information is initially received by the invitee's device (designated 620).

Next, in step 704 , send Address_PCCBS_Device, Access_Code and client authentication (Register a Private Cloud Call-Back Server, Address_PCCBS_Device, Address_PCCBS_Device_Client, Access_Code) to the PCCBS through the client message box. At step 740, the Address_PCCBS_Device and Access_Code are sent to the PCCBS device (labeled 710). In step 705, the PCCBS device client waits for PCCBS verification through the client message box. In step 706, the PCCBS device client waits for the confirmation of the completion of the PCCBS registration through the client message box. In step 707, if the item is a new item, the Address_PCCBS_Device item in the PCCBS_Device Server database is registered on the PCCBS_Device_App.

In step 710, from the perspective of PCCBS_Device Utility, the authentication of the PCCBS device client (Register a Private Cloud Call-Back Server, Address_PCCBS_Device, Address_PCCBS_Device_Client and Access_Code) is accepted. In step 711, verification is performed to check whether the Address_PCCBS_Device_Client is in the PCCBS device client database (PCCBS_Device Client database). If so, the PCCBS device client address (Address_PCCBS_Device_Client) and PCCBS device address (Address_PCCBS_Device) specified by the invitee are confirmed (marked as 719), and then returned. If not, Access_Code is verified (marked as 712); in step 713, Code_Expiration on Access_Code is on PCCBS_Device Client verified in the database. In step 741, the Code_Expiration on the Access_Code is sent to the PCCBS device client (marked as 705). In step 714, Password_PCCBS_Device_P2P, Password_PCCBS_Device_P2P_Expiration and Status and related Access_Code, Code_Expiration, Address_Invitee and Address_PCCBS_Device_Client are generated. In step 715, the hash value of Password_PCCBS_Device_P2P is stored as Hash_Password_PCCBS_Device_P2P. In step 716, save Address_PCCBS_Device_Client, Hash_Password_PCCBS_Device_P2P, Password_PCCBS_Device_P2P_Expiration and Status to PCCBS_Device Client Database items (Access_Code, Code_Expiration, Address_Invitee, Address_PCCBS_Device_Client, Hash_Password_PCCBS_Device_P2P, Password_PCCBS_Device_P2P_Expiration and Status). In step 717, the Password_PCCBS_Device_P2P is sent to the invitee notification address Address_Invitee. In step 743, transmit Password_PCCBS_Device_P2P to the invitee (marked as 720); in step 718, clear Password_PCCBS_Device_P2P. In step 719 , the PCCBS device client address (Address_PCCBS_Device_Client) and the PCCBS device address (Address_PCCBS_Device) specified by the invitee are confirmed. In step 744, the PCCBS device client address specified by the invitee is transmitted to the PCCBS device client (marked as 706); in step 720, from the perspective of the invitee's device, the Password_PCCBS_Device_P2P is accepted and saved for future use use.

FIG. 8 illustrates a flow chart of the communication of the PCCBS device client connected to the PCCBS according to the present invention. From the perspective of the PCCBS device client, in step 800, the PCCBS_VPN_App is opened on the WAN. In step 801, select an Address_PCCBS_VPN from the registered PCCBS VPN database (PCCBS_VPN database). In step 802, the "Connect to PCCBS_VPN (Connect to PCCBS_VPN)" command is selected on the PCCBS_VPN_App. In step 803, the point-to-point connection request is sent to Address_PCCBS_VPN. At step 840, the peer-to-peer connection request is sent to the PCCBS_VPN Utility (marked as 810). In step 804, the point-to-point negotiation starts using the Address_PCCBS_VPN_Client to communicate with the PCCBS_VPN located at the Address_PCCBS_VPN. In step 841, the PCCBS device client and PCCBS_VPN Utility (labeled 811) communication. In step 805, accept the PCCBS_VPN_Profile file to initiate a smart VPN connection with PCCBS_VPN at Address_PCCBS_VPN. In step 806, a point-to-point connection between the PCCBS_VPN and the device client is established. In step 843, the PCCBS device client communicates with the PCCBS_VPN Utility (marked as 813). In step 807, use the client's authentication (Connect to PCCBS_VPN, Address_PCCBS_VPN, Address_PCCBS_VPN_Client and Password_PCCBS_VPN_P2P) to log in to PCCBS_VPN. At step 844, the authentication of the client is sent to PCCBS_VPN Utility (labeled 814). In step 808, the PCCBS device client waits for verification. In step 809, secure peer-to-peer communication is initiated. At step 846, the PCCBS device client communicates with the PCCBS_VPN Utility (labeled as 817). In step 820, the PCCBS device client is securely connected to the virtual private area network located in the PCCBS_VPN.

From the perspective of PCCBS_VPN Utility, in step 810, the point-to-point connection request from Address_PCCBS_VPN_Client is accepted. In step 811, the point-to-point negotiation starts using Address_PCCBS_VPN to communicate with the PCCBS_VPN Client located at Address_PCCBS_VPN_Client. In step 841, the PCCBS_VPN Utility communicates with the PCCBS device client (marked as 804). In step 812, the PCCBS_VPN_Profile file is sent to the Address_PCCBS_VPN_Client to enable the smart VPN connection. In step 842, the PCCBS_VPN_Profile file is transmitted to the PCCBS device client (marked as 805). In step 813, a point-to-point connection between the PCCBS_VPN and the device client is established. In step 843, the PCCBS_VPN Utility communicates with the PCCBS device client (marked as 806). In step 814, the authentication of the PCCBS_VPN client (Connect to PCCBS_VPN, Address_PCCBS_VPN, Address_PCCBS_VPN_Client and Password_PCCBS_VPN_P2P). In step 815 , retrieve the item list (Access_Code, Code_Expiration, Address_Invitee, Address_PCCBS_VPN_Client, Hash_Password_PCCBS_VPN_P2P, Password_PCCBS_VPN_P2P_Expiration and Status) of Address_PCCBS_VPN_Client based on PCCBS_VPN Client database (PCCBS_VPN Client database). At step 816, the existing peer-to-peer (P2P) password is verified by checking whether the hash value matches the Hash_Password_PCCBS_VPN_P2P entry of Address_PCCBS_VPN_Client based on the PCCBS_VPN Client database. At step 845, the existing peer-to-peer (P2P) password is transmitted to the PCCBS device client (labeled 808). At step 817, secure peer-to-peer communication is enabled. At step 846, PCCBS_VPN Utility communicates with the PCCBS device client (labeled 809). At step 818, the PCCBS_VPN Utility calls back to the PCRS and initiates peer-to-peer communication with the PCRS. At step 847, the PCCBS device client is securely connected to the virtual private area network (labeled 820) on the PCRS. In step 819, the PCCBS_VPN Utility establishes a point-to-point communication channel between the PCRS device client and the PCCBS device client or another PCCBS device client. At step 848, the PCCBS device client starts to connect to the PCRS device client or another PCCBS device client (labeled 821).

FIG. 9 illustrates a flow chart of the PCCBS administrator checking the communication of the PCCBS client according to the present invention. From the perspective of the administrator device, in step 900, the PCCBS_Device_App is opened on the WAN. In step 901, select an Address_PCCBS_Device from the registered PCCBS device database (PCCBS_Device database). In step 902, select the "View PCCBS_Device Client" command on the PCCBS_Device_App. In step 903, a viewing item of the PCCBS device client database (PCCBS_Device Client database) is selected as a viewing index. In step 904, use the administrator's authentication (View PCCBS_Device Client, Admin_name, Admin_password and View entry) to log in to PCCBS. At step 940, the authentication is sent to the PCCBS_Device Utility (labeled as 910). At step 905, the administrator device waits for PCCBS verification. In step 906, display PCCBS_Device Client based on the reference index The item list of the database (Access_Code, Code_Expiration, Address_Invitee, Address_PCCBS_Device_Client, Hash_Password_PCCBS_Device_P2P, Password_PCCBS_Device_P2P_Expiration and Status).

In step 910, from the perspective of PCCBS_Device Utility, the authentication of the PCCBS_Device client (View PCCBS_Device Client, Admin_name, Admin_password and View entry) is accepted. In step 911, the authentication of the administrator (Admin_name, Admin_password) is verified. At step 941, the identity verification of the administrator is transmitted to the administrator device (labeled 905). In step 912, the viewing item is used as the viewing index to reply from the item list (Access_Code, Code_Expiration, Address_Invitee, Address_PCCBS_Device_Client, Hash_Password_PCCBS_Device_P2P, Password_PCCBS_Device_P2P_Expiration and Status) of the PCCBS_Device Client database based on the viewing index. At step 942, the reply is sent to the administrator device (labeled 906).

FIG. 10 illustrates a flow chart of the communication of the PCCBS administrator to reset the peer-to-peer password and edit the properties to the PCCBS device client according to the present invention. From the perspective of the administrator device, in step 1000, the PCCBS_Device_App is opened on the WAN. In step 1001, select an Address_PCCBS_Device from the registered PCCBS device database (PCCBS_Device database). In step 1002, select "Reset P2P Password" or "Edit Attributes" command in PCCBS_Device_App. In step 1003, the invitee notification address Address_Invitee is input as the reference index. In step 1004, use the administrator's authentication (Reset P2P Password/Edit Attributes, Admin_name, Admin_password and Address_Invitee) to log in to PCCBS. In step 1040, the identity verification of the administrator is sent to PCCBS_Device Utility (labeled 1010). At step 1005, the administrator device waits for PCCBS device authentication. In step 1006, a list of items (Access_Code, Code_Expiration, Address_Invitee, Address_PCCBS_Device_Client, Hash_Password_PCCBS_Device_P2P, Password_PCCBS_Device_P2P_Expiration and Status) is displayed based on the Address_Invitee of the PCCBS device client database (PCCBS_Device Client database). In step 1007, if the "reset peer-to-peer password" command is selected, the administrator device waits for completion. In step 1008, if the "edit attribute" command is selected, the attribute is edited as required. Wherein, the attribute includes the status (Active, Inactive, Deleted) of the PCCBS device client, the subnet of the virtual local area network and the PPCBS_App link, but not limited thereto. In step 1044, the attribute is sent to PCCBS_Device Utility (marked as 1017).

From the perspective of PCCBS_Device Utility, in step 1010, the authentication of the PCCBS administrator (P2P Password/Edit Properties, Admin_name, Admin_password and Address_Invitee) is accepted. In step 1011, the authentication of the administrator (Admin_name, Admin_password) is verified. In step 1041, the authentication of the PCCBS administrator is transmitted to the administrator device (labeled 1005). In step 1012, use Address_Invitee as the reference index, and reply based on the item list (Access_Code, Code_Expiration, Address_Invitee, Address_PCCBS_Device_Client, Hash_Password_PCCBS_Device_P2P, Password_PCCBS_Device_P2P_Expiration and Status) of Address_Invite in the PCCBS_Device Client database. In step 1042, the reply is sent to PCCBS_Device Utility (labeled 1006). In step 1013, if the command "reset peer-to-peer password" is selected. In step 1014, a new Password_PCCBS_Device_P2P is generated, and the hash value of Password_PCCBS_Device_P2P located in Hash_Password_PCCBS_Device_P2P is stored. In step 1043, the new Password_PCCBS_Device_P2P is transmitted to the administrator device (marked as 1007). In step 1015, the Access_Code and Password_PCCBS_Device_P2P are sent to the invitee notification address Address_Invitee, and Password_PCCBS_Device_P2P is cleared. In step 1045, the Access_Code, Password_PCCBS_Device_P2P are sent to the invitee (marked as 1020). In step 1016, if the "edit attribute" command is selected. In step 1017, the edit attribute is accepted and stored in the PCCBS device (PCCBS_Device).

From the perspective of the invitee's device, in step 1020, the invitee notifies the address Address_Invitee to accept the Access_Code and Password_PCCBS_Device_P2P.

FIG. 11 illustrates a flow chart of the communication of the PCCBS device client (PCCBS Device Client) modifying the peer-to-peer password of the PCCBS device client according to the present invention. From the perspective of the PCCBS device client, in step 1100, after establishing a secure VPN connection from the WAN, the PCCBS_Device_App is opened on the WAN. In step 1101, select an Address_PCCBS_Device from the registered PCCBS device database (PCCBS_Device database). In step 1102, select the "Change P2P Password" command in PCCBS_Device_App. In step 1103 , log in to PCCBS using the client's authentication (Change P2P Password, Address_PCCBS_Device, Address_PCCBS_Device_Client and Password_PCCBS_Device_P2P). In step 1140, the authentication of the client is sent to PCCBS_Device Utility (labeled 1110). In step 1104, the PCCBS device client waits for PCCBS device verification. At step 1105, new peer-to-peer passwords are entered and re-entered until they match. In step 1142, the new password is sent to PCCBS_Device Utility (marked as 1113).

From the perspective of PCCBS_Device Utility, in step 1110, the authentication of the PCCBS device client (Change P2P Password, Address_PCCBS_Device, Address_PCCBS_Device_Client and Password_PCCBS_Device_P2P) is accepted. In step 1111, the Hash_Password_PCCBS_Device_P2P item is retrieved based on the Address_PCCBS_Device_Client of the PCCBS device client database (PCCBS_Device Client database). In step 1112, by checking whether the hash value is the same as that based on the PCCBS_Device Client The Hash_Password_PCCBS_Device_P2P items (Access_Code, Code_Expiration, Address_Invitee, Address_PCCBS_Device_Client, Hash_Password_PCCBS_Device_P2P, Password_PCCBS_Device_P2P_Expiration and Status) of the Address_PCCBS_Device_Client of the database are matched to verify the existing peer-to-peer password. In step 1141, the existing peer-to-peer password is transmitted to the PCCBS Device Client (marked as 1104). In step 1113, accept the new P2P password Password_PCCBS_Device_P2P. In step 1114, the new P2P password is hashed into Hash_Password_PCCBS_Device_P2P. In step 1115, based on the PCCBS_Device Client The Address_PCCBS_Device_Client of the database (Access_Code, Code_Expiration, Address_Invitee, Address_PCCBS_Device_Client, Hash_Password_PCCBS_Device_P2P, Password_PCCBS_Device_P2P_Expiration and Status) updates Hash_Password_PCCBS_Device_P2P. Clear the peer-to-peer password Password_PCCBS_Device_P2P.

FIG. 12 illustrates a flow chart of the communication of a peer-to-peer connection mechanism between a device client (Device Client1) 1 and a device client (Device Client2) 2 via a cloud internet (prior art). The device client 1 and the device client 2 on the cloud network can communicate with each other through a public routing server (Public Routing Server) 112 or a public VPN routing server (Public VPN Routing Server) 114 . First, the Device Client1 App (marked as 1201) uses its IP address in Transmission Control Protocol (TCP)/User Datagram Protocol (UDP) and The performance of the port is registered to the Public VPN Routing Server Utility (Public VPN Routing Server Utility) (marked as 1200), and the Device Client1 App, IP address, and port and routing server remain active (marked as 1203). Next, the Device Client1 App (marked as 1201) requests Public VPN Routing Server Utility 1200 is connected to Device Client 2 (marked as 1204); Public VPN Routing Server Utility (marked as 1200) informs the device of the performance of the IP address and port of Device Client 1 in the TCP/UDP protocol and its connection intent Client 2 (marked as 1205); Device Client2 App (marked as 1202) replies with the Public VPN Routing Server Utility (marked as 1200) with its registration, which is included in the TCP/UDP protocol The IP address and port performance of the device client 2 remain active (marked as 1206) through the connection to the Public VPN Routing Server Utility (marked as 1200); Public VPN The Routing Server Utility (marked as 1200) sends the device client 2's IP address and the performance of the communication port in the TCP/UDP protocol to the device client 1 (marked as 1207); the device client 1 receives the device client 2 in the After the IP address of the TCP/UDP protocol and the performance of the communication port, Device Client1 App (marked as 1201) starts to pierce through the firewall of Device Client 2 (marked as 1208); Device Client2 App (marked as 1202) also starts to perforate (marked as 1209) through the firewall of Device Client 1; Both sides are perforated, and point-to-point communication (marked as 1210) between the device client 1 and the device client 2 begins. It should be noted that if there is no Public VPN Routing Server, there cannot be a connection mechanism between the Routing Server Utility and the Device Client 1 or Device Client 2. The basic flow of the connection mechanism must depend on the Public VPN Routing Server.

Figure 13 illustrates a flow chart of the communication of the point-to-point connection mechanism between PCRS and PCCBS over a cloud internet (prior art). As shown in FIG. 13 , according to the device client through the cloud network according to the present invention, it does not need a public VPN routing server (Public VPN Routing Server) to connect and access to another device client or a server under the server. internet service. The device client 1 and the PCCBS on the cloud network can communicate with each other without going through a public routing server 112 or a public VPN routing server 114 . The Device Client1 App (marked as 1301) requests to connect to the PCRS Utility (server part) (marked as 1300) through the client message box 215, and as shown in Figure 8, the PCRS Utility has IP address and port capabilities in the TCP/UDP protocol. PCRS Device Client1 App, IP address and port remain active with PCRS Utility (labeled 1303); PCRS Utility (server part) receives registrations via callback server message box (not shown); Terminal message box 215, PCRS device client 1 requires PCRS Utility (server part) to connect to PCRS Utility (client part) (marked as 1304); PCRS Utility (server part) 1300 receives the request through a callback server message box (not shown), marked at 1305, and sends the PCRS device client 1 to TCP/UDP The protocol IP address and the performance of the communication port and its connection intention notify PCRS Utility (client part) (marked as 1302); PCRS Utility (client part) (marked as 1302) replies to PCRS Utility (server part) with its registration (marked as 1300), where the register contains the IP address and port capabilities of the TCP/UDP protocol. The IP address and port capabilities of the device client 2 are kept active through the connection to the PCRS Utility (server part) (labeled 1300). PCRS Utility (server part) (marked as 1300) returns the device client 2's IP address and port performance in the TCP/UDP protocol to the Device Client1 App ( marked as 1301). After receiving the TCP/UDP protocol IP address and port performance of PCRS Utility (client part) through the client message box 215, PCRS Device Client1 The App (marked as 1301) starts punching (marked as 1308) through the firewall of PCRS Utility (the client part). PCRS Utility (client part) (marked as 1302) also begins to perforate (marked as 1309) through the firewall of PCRS Device Client1; finally, both sides of the firewall are perforated, PCRS Utility (client part) and PCRS Utility (client side) part) to start peer-to-peer communication (labeled 1310). All information exchange between PCRS Utility and PCRS Device Client1 is through a callback server message box (not shown), not through a public routing server 212 or a public VPN routing server 214 . As shown in step 820, the PCRS Device Client1 can securely connect to the virtual private area network on the PCRS. PCRS Device Client1 can access any device client 206 or private network service 228 accessible under PCRS. As shown in Figure 13, other PCRS Device Client1 (not 201, 221, 209, 210 and 211) can connect to PCRS through the same connection mechanism. Once any pair of PCRS device client (PCRS Device Clients) and PCCBS Device Clients (PCCBS Device Clients) are connected to the virtual private area networks 240 and 2400 of PCRS and PCCBS, that is, private and secure communication for text, voice and video can be performed between them.

FIG. 14 illustrates a flow chart of the communication of the point-to-point connection mechanism between PCRS, PCCBS, PCRS Device Clients, and PCCBS Device Clients through a cloud Internet. The device client through the cloud network according to the present invention does not require a public cloud routing server to connect and access to PCCBS, PCCBS, another device client, or another network service under the server. As shown in FIG. 14 , the device client 1 and the PCRS on the cloud network can communicate with each other without going through a public routing server 112 or a public VPN routing server 114 . 5 and 14, the PCCBS administrator device (1420) initializes and prepares the PCCBS (1428) through PCRS Device Utility (1421). After that, PCRS Utility (marked as 1421) transmits the internal information of PCCBS (marked as 1428) to PCRS_VPN Utility (marked as 1422). Next, please refer to the code number 1 (marked as 1401) in FIG. 14 and FIG. 15, to the PCCBS VPN Utility (marked as 1423) registers the PCCBS registration message, which includes the IP address and port capabilities in the TCP/UDP protocol. As shown in FIG. 16 , a PCCBS tuple (Tuple) and a communication interface (Communication Socket) (marked as 1600 ) are also established. Through the connection with PCCBS Utility (labeled 1401), the IP address of the device client 2 and the capability of the communication port remain active. After registration, PCRS_VPN Utility connects to PCCBS_VPN (marked as 1602), and establishes a point-to-point communication channel between PCRS_VPN and PCCBS_VPN (marked as 1619). PCCBS_VPN Utility (marked as 1423) communicates with PCCBS_Device Utility (marked as 1424) through messages inside PCCBS (marked as 1427). Please refer to code 2 (marked as 1402 ) in FIG. 14 , the PCCBS_Device Utility keeps in a loop and waits for the request from the PCCBS device client. As shown in Figure 7, first PCCBS Device Client1 (marked as 1405) uses the IP address and port properties of the TCP/UDP protocol to register with PCCBS_Device Utility (labeled 1424); with PCCBS_Device Utility (labeled 1424), PCCBS Device Client1, IP address, and port remain active (see Figure 7 and Figure 14, code 3-1 (labeled 1403)). The PCCBS_Device Utility (marked as 1424) transmits the registration and connection requests within the PCCBS (marked as 1427) to the PCCBS_VPN Utility (marked as 1423). As shown in Figure 8, after registration, PCCBS Device Client1 (marked as 1425) connects to PCCBS_VPN (refer to step 802 in Figure 8), and connects between PCCBS Device Client1 (marked as 1424) and PCCBS_VPN (refer to 817 in Figure 8). ) to establish a point-to-point communication channel. Please refer to code 5 (labeled as 1405), code 7 (labeled as 1407) in FIG. 14, and step 818 in FIG. 8, PCCBS_VPN Utility (labeled as 1423) calls back to PCRS_VPN Utility (labeled as 1422) A point-to-point communication channel is established between PCRS_VPN Utility (marked as 1423) and PCRS_VPN Utility (marked as 1422). When PCCBS_VPN After the callback from Utility (marked as 1423) to PCRS_VPN Utility (marked as 1422) is successful, a point-to-point communication channel is finally established between PCCBS_Device Client1 and PCRS_VPN, and then connected to PCRS Device Client2 (marked as 1426), or another PCCBS Device client 3 (PCCBS Device Client3) (marked as 1401), assuming that PCCBS Device Client3 is also successfully connected to PCCBS_VPN Utility (marked as 1423). FIG. 17 illustrates the callback action from PCCBS_VPN Utility to PCRS_VPN (please refer to step 818 of FIG. 8 ).

Figure 15 illustrates a flow chart of the communication of PCRS registration to PCCBS according to the present invention. From a PCRS perspective, in step 1500, a PCCBS tuple and a communication interface are established. If necessary (not shown), create a PCCBS device client address (Address_PCCBS_Device_Client). Next, in step 1501, a "Register a PCCBS (Register a Private Cloud Call-Back Server)" command is issued. In step 1502, if PCCBS_Device has not been configured Client, configure Address_PCCBS_Device_Client and Password_PCCBS_Device_Client. Among them, Password_PCCBS_Device_P2P is the password of the message box related to the address of the message box (not shown) of the client, and the address of the message box is used for the point-to-point communication of Address_PCCBS_Device_Client. In step 1502, Address_PCCBS_Device_Client and Password_PCCBS_Device_Client are registered to the client message box. In step 1503, the Address_PCCBS_Device and the Access_Code are retrieved from the invitee. This information is initially received through the invitee device 620 .

In step 1504, Address_PCCBS_Device, Access_Code and client authentication (Register a Private Cloud Call-Back Server, Address_PCCBS_Device, Address_PCCBS_Device_Client and Access_Code) are sent to PCCBS through the client message box. At step 1540, the Address_PCCBS_Device and Access_Code are sent to the PCCBS (labeled as 1510). In step 1505, the PCRS waits for the verification of the PCCBS via the client message box. In step 1506, the PCRS waits for the registration completion confirmation of the PCCBS through the client message box. In step 1507, if it is a new item, register the Address_PCCBS_Device item in the PCCBS_Device Server database (PCCBS_Device Server database) on the PCCBS_Device_App.

From the perspective of PCCBS_Device Utility, in step 1510, the identity verification (Register a Private Cloud Call-Back Server, Address_PCCBS_Device, Address_PCCBS_Device_Client and Access_Code) of the PCCBS device client (PCCBS_Device Client) is received. In step 1512, verification is performed to check whether the Address_PCCBS_Device_Client is in the PCCBS device client database (PCCBS_Device Client database). If so, the PCCBS device client address (Address_PCCBS_Device_Client) and PCCBS device address (Address_PCCBS_Device) specified by the invitee are confirmed (marked as 1519), and then returned. If not, Access_Code is verified (marked as 1512); in step 1513, Code_Expiration on Access_Code is on PCCBS_Device Client verified in the database. In step 1541, the Code_Expiration on the Access_Code is sent to the PCCBS device client (marked as 1505). In step 1514, Password_PCCBS_Device_P2P, Password_PCCBS_Device_P2P_Expiration and Status and related Access_Code, Code_Expiration, Address_Invitee and Address_PCCBS_Device_Client are generated. In step 1515, the hash value of Password_PCCBS_Device_P2P is saved as Hash_Password_PCCBS_Device_P2P. In step 1516, save Address_PCCBS_Device_Client, Hash_Password_PCCBS_Device_P2P, Password_PCCBS_Device_P2P_Expiration and Status to PCCBS_Device Client Database items (Access_Code, Code_Expiration, Address_Invitee, Address_PCCBS_Device_Client, Hash_Password_PCCBS_Device_P2P, Password_PCCBS_Device_P2P_Expiration and Status). In step 1517, the Password_PCCBS_Device_P2P is sent to the PCRS message box. In step 1518, Password_PCCBS_Device_P2P is cleared. In step 1519, the PCCBS device client address (Address_PCCBS_Device_Client) and the PCCBS device address (Address_PCCBS_Device) specified by the invitee are confirmed. In step 1544, the PCCBS device client address specified by the invitee is transmitted to the PCCBS device client (marked as 1506). In step 1520, from the perspective of the invitee's device, the Password_PCCBS_Device_P2P is accepted and saved for future use.

FIG. 16 illustrates a flow chart of the communication of PCRS connected to PCCBS according to the present invention. From a PCRS perspective, in step 1600, a PCCBS tuple and a communication interface are established. In step 1601, select an Address_PCCBS_VPN from the registered PCCBS VPN database (PCCBS_VPN database). In step 1602, the "Connect to PCCBS_VPN (Connect to PCCBS_VPN)" command is selected in the PCCBS_VPN_App. In step 1603, the point-to-point connection request is sent to Address_PCCBS_VPN. At step 1640, the point-to-point connection request is sent to the PCCBS_VPN Utility (labeled as 1610). Point-to-point negotiation starts using Address_PCCBS_VPN_Client to communicate with PCCBS_VPN at Address_PCCBS_VPN. In step 1641, PCCBS_VPN and PCCBS_VPN Utility (labeled 1611) communication. In step 1605, the PCCBS_VPN_Profile file is accepted to initiate a smart VPN connection with PCCBS_VPN at Address_PCCBS_VPN. In step 1606, a point-to-point connection between the PCCBS_VPN and the device client is established. At step 1643, the PCCBS_VPN communicates with the PCCBS_VPN Utility (labeled as 1613). In step 1607, use the client's authentication (Connect to PCCBS_VPN, Address_PCCBS_VPN, Address_PCCBS_VPN_Client and Password_PCCBS_VPN_P2P) to log in to PCCBS_VPN. At step 1644, the authentication of the client is sent to PCCBS_VPN Utility (labeled 1614). At step 1608, PCCBS_VPN waits for verification. In step 1609, secure peer-to-peer communication is started. At step 1646, PCCBS_VPN communicates with the PCCBS_VPN Utility (labeled 1617). At step 1620, PCCBS_VPN securely connects to the virtual private area network located at PCCBS_VPN.

From the perspective of PCCBS_VPN Utility, in step 1610, the point-to-point connection request from Address_PCCBS_VPN_Client is accepted. In step 1611, the point-to-point negotiation starts using the Address_PCCBS_VPN to communicate with the PCCBS_VPN Client located at the Address_PCCBS_VPN_Client. At step 1641, PCCBS_VPN Utility communicates with PCRS_VPN (labeled 1604). In step 1612, the PCCBS_VPN_Profile file is sent to the Address_PCCBS_VPN_Client to enable the smart VPN connection. At step 1642, the PCCBS_VPN_Profile file is sent to PCRS_VPN (labeled 1605). In step 1613, a point-to-point connection between the PCCBS_VPN and the device client is established. At step 1643, the PCCBS_VPN Utility communicates with the PCCBS_VPN (labeled 1606). In step 1614, the authentication of the PCCBS_VPN client (Connect to PCCBS_VPN, Address_PCCBS_VPN, Address_PCCBS_VPN_Client and Password_PCCBS_VPN_P2P). In step 1615 , retrieve the item list (Access_Code, Code_Expiration, Address_Invitee, Address_PCCBS_VPN_Client, Hash_Password_PCCBS_VPN_P2P, Password_PCCBS_VPN_P2P_Expiration and Status) of Address_PCCBS_VPN_Client based on PCCBS_VPN Client database (PCCBS_VPN Client database). In step 1616, by checking whether the hash value is consistent with the PCCBS_VPN Client based The database's Address_PCCBS_VPN_Client matches the Hash_Password_PCCBS_VPN_P2P item to verify existing peer-to-peer (P2P) passwords. At step 1645, the existing peer-to-peer (P2P) password is transmitted to PCRS_VPN (labeled 1608). In step 1617, secure peer-to-peer communication is enabled. At step 1646, PCCBS_VPN Utility communicates with PCRS_VPN (labeled 1609). In step 1619, PCCBS_VPN Utility establishes a point-to-point communication channel between PCRS_VPN and PCCBS_VPN. At step 1645, PCRS_VPN starts connecting to PCCBS_VPN (labeled 1621).

FIG. 17 illustrates a flow diagram of PCCBS callback-to-PCRS communication according to the present invention. From a PCCBS perspective, in step 1700, a PCCBS tuple and a communication interface are established. In step 1701, select an Address_PCRS_VPN from the registered PCRS VPN database (PCRS_VPN database). In step 1702, the "Connect to PCRS_VPN (Connect to PCRS_VPN)" command is selected in the PCRS_VPN_App. In step 1703, the point-to-point connection request is sent to Address_PCRS_VPN. At step 1740, the point-to-point connection request is sent to PCRS_VPN Utility (labeled as 1710). Point-to-point negotiation starts using Address_PCRS_VPN_Client to communicate with PCRS_VPN at Address_PCRS_VPN. In step 1741, PCRS_VPN and PCRS_VPN Utility (labeled 1711) communication. In step 1705, the PCRS_VPN_Profile file is accepted to initiate a smart VPN connection with PCRS_VPN at Address_PCRS_VPN. In step 1706, a point-to-point connection between the PCRS_VPN and the device client is established. At step 1743, PCRS_VPN communicates with PCRS_VPN Utility (labeled 1713). In step 1707 , log in to PCCBS_VPN using the client authentication (Connect to PCRS_VPN, Address_PCRS_VPN, Address_PCRS_VPN_Client and Password_PCRS_VPN_P2P). At step 1744, the authentication of the client is sent to PCRS_VPN Utility (labeled 1714). At step 1708, PCRS_VPN waits for verification. At step 1709, secure peer-to-peer communication is initiated. At step 1746, PCRS_VPN communicates with the PCRS_VPN Utility (labeled 1717). PCCBS_VPN Utility establishes a point-to-point connection channel (marked as 1719) between PCRS_VPN and PCCBS_VPN. In step 1721, PCCBS in PCCBS_VPN Device A point-to-point connection channel is established between the Client and PCRS Device Client or another PCCBS_VPN Device Client.

From the perspective of PCRS_VPN Utility, in step 1710, the point-to-point connection request from Address_PCRS_VPN_Client is accepted. In step 1711, the point-to-point negotiation starts using Address_PCRS_VPN to communicate with the PCRS_VPN Client located at Address_PCRS_VPN_Client. At step 1741, PCRS_VPN Utility communicates with PCRS_VPN (labeled 1704). In step 1712, the PCRBS_VPN_Profile file is sent to the Address_PCRS_VPN_Client to enable the smart VPN connection. At step 1742, the PCRS_VPN_Profile file is sent to PCRS_VPN (labeled 1705). In step 1713, a point-to-point connection between the PCRS_VPN and the device client is established. At step 1743, PCRS_VPN Utility communicates with PCRS_VPN (labeled 1706). In step 1714, the authentication of the PCRS_VPN client (Connect to PCRS_VPN, Address_PCRS_VPN, Address_PCRS_VPN_Client, and Password_PCRS_VPN_P2P). In step 1715, the item list (Access_Code, Code_Expiration, Address_Invitee, Address_PCRS_VPN_Client, Hash_Password_PCRS_VPN_P2P, Password_PCRS_VPN_P2P_Expiration, and Status) based on the PCCBS VPN client database (PCRS_VPN Client database) of Address_PCRS_VPN_Client is retrieved. At step 1716, an existing peer-to-peer (P2P) password is verified by checking whether the hash value matches the Hash_Password_PCRS_VPN_P2P entry of Address_PCRS_VPN_Client based on the PCRS_VPN Client database. At step 1745, the existing peer-to-peer (P2P) password is transmitted to PCRS_VPN (labeled 1708). At step 1717, secure peer-to-peer communication is enabled. At step 1746, PCCBS_VPN Utility communicates with PCRS_VPN (labeled 1709). PCCBS_VPN Utility establishes a point-to-point communication channel (marked as 1709) between PCRS_VPN and PCCBS_VPN. In step 1748, PCRS establishes a point-to-point connection channel (marked as 1721) between the PCCBS_VPN Device Client and the PCRS Device Client or another PCCBS_VPN Device Client.

18 illustrates a flow chart of the point-to-point connection mechanism of PCRS, PCCBS, PCRS device client and PCCBS device client through the cloud network based on server cluster, computer resource aggregation and virtual machine. In addition, FIG. 18 is an extension of FIG. 14, which adds a server cluster 1830, a computer resource aggregation 1831, and a virtual machine 1832 to illustrate the implementation of the PCRS connection mechanism in a hyperscale data center. The hyperscale data center may have at least one server cluster 1830 , at least one computer resource aggregate 1831 and at least one virtual machine 1832 . The number and size of the at least one virtual machine is scalable. The ultra-large data center or at least one of the service providers can construct a large number of independent PCCBSs in a corresponding plurality of corresponding virtual machines to provide services to the corresponding PCRS and PCRS device clients. In essence, a community pair of peer-to-peer communication relationships between the PCCBS device client and the PCRS device client is constructed and deployed through the web platform owner, where the web platform owner is responsible for maintaining a peer-to-peer communication relationship with or without The virtual machine has a topology of computer resource aggregation and server clustering. For example, one possible business model involves a network platform owner providing hosting of their private and secure PCCBS to a large number of individual users in the virtual machine. Furthermore, the web platform owner also provides a separate private and secure PCRS for individual users to install in their own local area network. Through the present invention, the platform user can build his own PCCBS device client (for example: a smart phone or a tablet) and the PCRS device client (for example: a notebook computer (Notebook; NB) from anywhere. ), IoT devices, Network Attached Storage (NAS) or media servers), and are hosted on the user's private and secure local area network. 18 illustrates that a device client does not require a public cloud routing server to connect and access the PCRS, PCCBS, other device clients, or network services via a cloud network under the server, according to the technology of the present invention. As shown in Figure 18, a PCCBS device client 1 (PCCBS Device Client1) 1825 and a PCRS on the cloud network can communicate with each other without going through a public routing server 112 (not shown) or public VPN routing server 114 (not shown). PCRS Utility (marked as 1821) transmits the information inside PCRS (marked as 1828) to PCRS_VPN Utility (marked as 1822). As shown in code 1 in Figure 15 and Figure 18, PCRS_VPN Utility (marked as 1822) registers with the PCCBS VPN Utility (marked as 1823) using the PCRS registration message, wherein the registration message includes the IP address and communication of the TCP/UDP protocol port performance. As shown in Figure 16, PCRS_VPN Utility (marked as 1822) also creates a PCCBS tuple and a communication interface (marked as 1600). The IP address and port capabilities of Device Client 2 (labeled 1826) remain active through the connection to PCCBS Utility (labeled 1801). After registration, PCRS_VPN Utility connects to PCCBS_VPN (marked as 1602), and establishes a point-to-point communication channel between PCRS_VPN and PCCBS_VPN (marked as 1619). PCCBS_VPN Utility (labeled as 1823) communicates with PCCBS_Device Utility (labeled as 1824) through messages inside PCCBS (labeled as 1827). Please refer to code 2 (marked as 1802 ) in FIG. 18 , the PCCBS_Device Utility remains in a loop and waits for a request from the PCCBS device client. As shown in Figure 7, first, PCCBS Device Client1 (marked as 1805) uses the IP address and communication port performance of the TCP/UDP protocol to register with PCCBS_Device Utility (marked as 1824); through PCCBS_Device Utility (marked as 1824) , PCCBS Device Client1, IP address and communication port remain active (please refer to code 3-1 (labeled 1803) in Figure 7 and Figure 14. The PCCBS_Device Utility (labeled as 1824) converts the internal PCCBS (labeled as 1827) Registration and connection requests are sent to PCCBS_VPN Utility (labeled 1823). As shown in Figure 8, after registration, PCCBS Device Client1 (marked as 1825) connects to PCCBS_VPN (refer to step 802 in Figure 8), and connects between PCCBS Device Client1 (marked as 1824) and PCCBS_VPN (refer to step in Figure 8) 817) to establish a point-to-point communication channel. Please refer to code 5 (labeled as 1805), code 7 (labeled as 1807) in FIG. 18, and step 818 in FIG. 8, PCCBS_VPN Utility (labeled as 1823) calls back to PCRS_VPN Utility (labeled as 1822) It is marked as 1823) and the PCRS_VPN Utility (marked as 1822) establishes a point-to-point communication channel. After the callback from PCCBS_VPN Utility (marked as 1823) to PCRS_VPN Utility (marked as 1822) is successful, establish a point-to-point communication channel between PCCBS_Device Client1 (marked as 1825) and PCRS_VPN, and connect to PCRS Device Client2 (marked with 1826) ). FIG. 17 illustrates the callback action from PCCBS_VPN Utility to PCRS_VPN (please refer to step 818 of FIG. 8 ). After the callback action of Utility (marked as 1822) is successful, a point-to-point communication channel is established between PCCBS_Device Client1 (marked as 1825) and PCRS_VPN, and connected to PCRS Device Client2 (marked as 1826). FIG. 17 illustrates the callback action from PCCBS_VPN Utility to PCRS_VPN (please refer to step 818 of FIG. 8 ). After the callback action of Utility (marked as 1822) is successful, a point-to-point communication channel is established between PCCBS_Device Client1 (marked as 1825) and PCRS_VPN, and connected to PCRS Device Client2 (marked as 1826). FIG. 17 illustrates the callback action from PCCBS_VPN Utility to PCRS_VPN (please refer to step 818 of FIG. 8 ).

Although the present invention has been described in terms of the above-mentioned embodiments, those skilled in the art will readily appreciate that further variations of these embodiments are possible without departing from the basic spirit of the present invention. Accordingly, those skilled in the art can make more changes to the embodiments of the present invention without departing from the scope of the patent application.

<p>as shown below: &lt;br/&gt;, 1~8, 3-1, 3-3, 4-1, 4-3, 6-3: code &lt;br/&gt;00, 200, 300, 400: public cloud &lt;br/&gt;02, 103, 202, 203, 302, 303, 403: Router, Router_P, Router_S &lt;br/&gt;04, 105, 204, 205, 304, 305, 334, 405, 434: Local Area Network, LAN, Local Area Network &lt;br/&gt;01, 106, 107, 109, 110, 111: Smart Device Client &lt;br/&gt;08: Private Cloud Server &lt;br/&gt;12, 212, 312, 412, 1200: public routing server &lt;br/&gt;13, 213, 313, 413: Public cloud server &lt;br/&gt;14, 214, 314, 414: Public VPN routing server &lt;br/&gt;01, 209, 210, 211, 221, 301, 309, 310, 311, 321, 401, 409, 410, 411, 421: PCCBS device client &lt;br/&gt;06, 207, 306, 307, 335, 435: PCRS device client &lt;br/&gt;08, 308, 408: PCRS &lt;br/&gt;16, 316, 416: PCCBS &lt;br/&gt;15, 315, 415: Client message box &lt;br/&gt;22, 223, 224, 225, 322, 323, 324, 325, 326, 422, 423, 424, 426: Communication path &lt;br/&gt;28, 328, 336, 436: Private Internet Services &lt;br/&gt;40, 2400, 340, 440: VLAN &lt;br/&gt;60, 460:LAN2 &lt;br/&gt;70, 1300, 1302: PCRS Utility &lt;br/&gt;71:PCRS client database &lt;br/&gt;72, 276, 280, 282: Client message box Utility &lt;br/&gt;73: PCRS Administrator Device &lt;br/&gt;74:PCRS Device App &lt;br/&gt;75:PCRS database &lt;br/&gt;77: PCCBS administrator device &lt;br/&gt;78: PCCBS Device App &lt;br/&gt;79: PCCBS database &lt;br/&gt;81: Invitee Device &lt;br/&gt;201: Device Client 1 &lt;br/&gt;202: Device Client 2 &lt;br/&gt;301:PCRS device client 1 App &lt;br/&gt;420: PCCBS administrator device &lt;br/&gt;421:PCRS Device Utility &lt;br/&gt;422:PCRS VPN Utility &lt;br/&gt;423:PCCBS VPN Utility &lt;br/&gt;424:PCCBS Device Utility &lt;br/&gt;425: PCCBS device client 1 &lt;br/&gt;830:Server Cluster &lt;br/&gt;831: Computer resource aggregation &lt;br/&gt;832:Virtual machine &lt;br/&gt;700:PCCBS Utility &lt;br/&gt;710: PCCBS client database &lt;br/&gt;720:Server Message Box Utility &lt;br/&gt;00~508, 510~516, 540~543: Steps &lt;br/&gt;00~605, 610~614, 620~622, 640~642: Steps &lt;br/&gt;00~707, 710~720, 740~744: Steps &lt;br/&gt;00~821, 840~848: Steps &lt;br/&gt;00~906, 910~912, 940~942: Steps &lt;br/&gt;000~1008, 1010~1017, 1020, 1040~1045: Steps &lt;br/&gt;100~1105, 1110~1116, 1140~1142: Steps &lt;br/&gt;203~1210: Steps &lt;br/&gt;303~1310: Steps &lt;br/&gt;400~1407, 1411, 1413~1414, 1416, 1427~1428: Steps &lt;br/&gt;500~1507, 1510~1520, 1540~1544: Steps &lt;br/&gt;600~1617, 1619~1620, 1640~1646, 1648: Steps &lt;br/&gt;700~1717, 1719, 1721, 1740~1746, 1748: Steps &lt;br/&gt;801~1807, 1811, 1827~1828: Steps </p>

FIG. 1 illustrates a schematic diagram of a traditional cloud network architecture.

FIG. 2 illustrates a schematic diagram of a connection mechanism according to the first embodiment of the present invention. The connection mechanism is between a private cloud routing server, a private cloud callback server and a smart device client.

FIG. 3 illustrates a schematic diagram of a connection mechanism according to a second embodiment of the present invention. The connection mechanism is between the private cloud routing server, the private cloud callback server and the smart device client.

FIG. 4 illustrates a schematic diagram of a connection mechanism according to a third embodiment of the present invention. The connection mechanism is between the private cloud routing server, the private cloud callback server and the smart device client.

FIG. 5 illustrates a flow chart of the private cloud routing server administrator initializing and preparing the private cloud routing server according to the present invention.

FIG. 6 illustrates a flow chart of the private cloud callback server administrator creating a client for the private cloud callback server according to the present invention.

FIG. 7 illustrates a flow chart of the private cloud callback server device client registering with a private cloud callback server according to the present invention.

FIG. 8 illustrates a flowchart from the private cloud callback server device client to the private cloud callback server according to the present invention.

FIG. 9 illustrates a flowchart for an administrator to view the client of the private cloud routing server according to the present invention.

FIG. 10 illustrates a flow chart of an administrator resetting a user's peer-to-peer password and editing properties of a private cloud callback server device according to the present invention.

FIG. 11 illustrates a flow chart of modifying the user's peer-to-peer password of the private cloud callback server device according to the present invention.

FIG. 12 illustrates a flow chart of a peer-to-peer connection mechanism between the device client 1 and the device client 2 through the cloud network (prior art).

FIG. 13 illustrates a flow chart of a peer-to-peer connection mechanism between a private cloud routing server and a private cloud routing server device client through a cloud network (prior art).

FIG. 14 illustrates a flow chart of a peer-to-peer connection mechanism between a private cloud routing server, a private cloud callback server, a private cloud routing server device client, and a private cloud callback through a cloud network between server device clients.

FIG. 15 illustrates a flow chart of the private cloud routing server registering with the private cloud callback server virtual private network according to the present invention.

16 illustrates a flow chart of a private cloud routing server to a private cloud callback server virtual private network according to the present invention.

FIG. 17 illustrates a flowchart of the private cloud callback server calling back to the private cloud routing server virtual private network according to the present invention.

Figure 18 illustrates a private cloud routing server, a private cloud callback server, a private cloud routing server device client, and a private cloud callback server through a cloud network based on server clusters, computer resource aggregation, and virtual machines The flow chart of the point-to-point connection mechanism of the device client.

none