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

Abstract

A method for use with a public cloud network is disclosed. The method includes setting up at least one private cloud routing server (PCRS) and at least one smart device client on the side of the PCRS in a client server relationship. It also includes setting up at least another smart device client on the side of the PCCBS in a client server relationship with the at least one private cloud call-back server (PCCBS). The private cloud call-back server acts as a middleman to relay communication between the smart device client on the side of the PCCBS and the private cloud routing server. The PCCBS will call back the private cloud routing server on demand based on the smart device client request. The at least one private cloud call-back server includes a first message box associated therewith.

Description

Connection method and computer readable medium for 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 a floating domain name system (Dynamic 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 private cloud routing server (PCRS) and at least one smart device client on one side of the private cloud routing server, the at least one private cloud routing server and the private cloud At least one smart device client on the routing server side is in a client-server relationship. The method may further include setting at least one other smart device client on the side of the private cloud call-back server (PCCBS), the at least one other on the side of the private cloud call-back server The smart device client is in a client server relationship with the at least one private cloud routing server. 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 status through a system administrator, and modifying the private cloud callback server through the at least one smart device client the peer-to-peer password, reset the private cloud callback server peer-to-peer password and the state through a system administrator from a private cloud callback server LAN, and connect to the private cloud through the at least one smart device client Call back the 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 one other smart device client, the at least one other smart device client being a client server with the at least one private cloud routing server and the at least one private cloud callback server device relationship. 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 principles and features substantially the same as those 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: 1. Access your private cloud server anytime, anywhere. 2. Access a private cloud server with a fixed or floating Internet Protocol (hereinafter referred to as IP) address behind a firewall. 3. No need for a public cloud-based routing server in the WAN. 4. There is no need to set up additional routers in the local area network. 5. Verify the private cloud server. 6. 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 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: 1. Access PCRS anytime, anywhere. 2. Access PCRS with a fixed or a floating IP address behind a firewall. 3. No need for external or public cloud-based routing servers in the WAN. 4. There is no need to set up additional routers in the LAN. 5. Verify PCRS. 6. 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, 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 given 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 area under PCRS and PCCBS Any service that the 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. This 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: 1. Initialize and prepare a PCRS (via an administrator from the PCRS's local area network). 2. Initialize and prepare a PCCBS (through the WAN administrator from the PCCBS). 3. Create a PCRS client (via the PCRS administrator from the LAN). 4. Register to a PCCBS (via the PCCBS client from the WAN). 5. Connect to a PCCBS (through the PCCBS server client from the WAN). 6. View a PCCBS client (via the system administrator from the PCCBS WAN). 7. Reset a PCCBS peer-to-peer password and status (via the system administrator from the PCCBS's WAN). 8. 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.

A number of 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, and based on security considerations, the actual hashed password is never stored in the PCRS middle. 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, the actual user end-to-end password is 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, regarding the "Change P2P Password" command, for security reasons, after the WAN is securely connected to the VPN, the PCCBS device client must run PCCBS_Device_App on the PCCBS virtual network, because the P2P password is only Can be reset on 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.

Figure 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.

FIG. 4 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 items (Access_Code, Code_Expiration, Address_Invitee, Address_PCCBS_Device_Client, Hash_Password_PCCBS_Device_P2P, Password_PCCBS_Device_P2P_Expiration, Status) of the PCCBS device client database (PCCBS_Device Client database). 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 the "Register a PCCBS (Register a Private Cloud Call-Back Server)" command on the PCCBS_Device_App. 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, the Access_Code is verified (marked as 712); in step 713, the Code_Expiration on the Access_Code is verified in the PCCBS_Device Client 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, the Address_PCCBS_Device_Client, Hash_Password_PCCBS_Device_P2P, Password_PCCBS_Device_P2P_Expiration and Status are stored in items (Access_Code, Code_Expiration, Address_Invitee, Address_PCCBS_Device_Client, Hash_Password_PCCBS_Device_P2P, Password_PCCBS_Device_P2P_Expiration) of the PCCBS_Device Client database. 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 point-to-point 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 communicates with the PCCBS_VPN Utility (marked as 811). 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) is accepted. 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, the PCCBS_VPN Utility communicates with the PCCBS device client (labeled as 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, 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 is displayed based on the reference index.

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 (marked as 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 (marked as 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 the PCCBS_Device Utility (marked as 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, the existing peer-to-peer password is verified by checking whether the hash value matches the Hash_Password_PCCBS_Device_P2P entry (Access_Code, Code_Expiration, Address_Invitee, Address_PCCBS_Device_Client, Hash_Password_PCCBS_Device_P2P, Password_PCCBS_Device_P2P_Expiration, and Status) based on the Hash_Password_PCCBS_Device_Client of the PCCBS_Device Client database. 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, update Hash_Password_PCCBS_Device_P2P based on the Address_PCCBS_Device_Client (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. 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 (labeled 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 the Public VPN Routing Server Utility 1200 to connect to the Device Client 2 (marked as 1204); the Public VPN Routing Server Utility (marked as 1200) connects the device Client 1 informs Device Client 2 (marked as 1205) of the performance of the IP address and communication port of the TCP/UDP protocol and its connection intention; the Device Client2 App (marked as 1202) uses it Register and reply to Public VPN Routing Server Utility (marked as 1200), where the registration includes the IP address and port performance of the TCP/UDP protocol. The connection of the Server Utility (marked as 1200) remains active (marked as 1206); the Public VPN Routing Server Utility (marked as 1200) responds to the performance of the device client 2 in the IP address and port of the TCP/UDP protocol to the device client 1 (marked as 1207); after the device client 1 receives the device client 2's IP address and the capability of the communication port in the TCP/UDP protocol, the Device Client1 App (marked as 1201) passes the device client 2 The firewall of the device client 1 starts to perforate (marked as 1208); Device Client2 App (marked as 1202) also starts to perforate (marked as 1209) through the firewall of the device client 1; finally, both sides of the firewall are perforated, the device client 1 and the device The peer-to-peer communication (marked as 1210) between the client terminals 2 starts. 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 by calling back the server message box (not 1305, and notify PCRS Utility (client part) (marked as 1302) of the performance of the IP address and communication port of the PCRS device client 1 in the TCP/UDP protocol and its connection intentions; (Client part) (indicated as 1302) replies to PCRS Utility (Server part) (indicated as 1300) with its registration, which 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, the PCRS Device Client1 App (marked as 1301) passes the PCRS Utility (client part) The firewall begins to perforate (labeled 1308). 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 Clients (PCRS Device Clients) and PCCBS Device Clients (PCCBS Device Clients) are connected to the PCRS and PCCBS Virtual Private Area Networks 240, 2400, they can perform text, Private and secure communications for voice and video.

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 1 (marked as 1401 ) in FIG. 14 and FIG. 15 , register the PCCBS registration message with the PCCBS VPN Utility (marked as 1423 ), which includes the IP address and the capability of the communication port 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 capabilities 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 a request from the PCCBS device client. As shown in Figure 7, firstly, PCCBS Device Client1 (marked as 1405) uses the IP address and port performance of the TCP/UDP protocol to register with PCCBS_Device Utility (marked as 1424); through PCCBS_Device Utility (marked as 1424) , PCCBS Device Client1, IP address and communication port remain active (please refer to code 3-1 (marked as 1403) in Figure 7 and Figure 14). 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 FIG. 8 , after registration, PCCBS Device Client1 (marked as 1425 ) connects to PCCBS_VPN (refer to step 802 in FIG. 8 ), and connects between PCCBS Device Client1 (marked as 1424 ) and PCCBS_VPN (refer to step in FIG. 8 ) 817) 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 1422) and PCRS_VPN Utility (marked as 1423). When the callback action from PCCBS_VPN 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 A PCCBS device client 3 (PCCBS Device Client3) (marked as 1401), assuming that PCCBS Device Client3 is also successfully connected to the 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 Client has not been configured yet, 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, the Access_Code is verified (marked as 1512); in step 1513, the Code_Expiration on the Access_Code is verified in the PCCBS_Device Client 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, the Address_PCCBS_Device_Client, Hash_Password_PCCBS_Device_P2P, Password_PCCBS_Device_P2P_Expiration and Status are stored in items (Access_Code, Code_Expiration, Address_Invitee, Address_PCCBS_Device_Client, Hash_Password_PCCBS_Device_P2P, Password_Status_Device_P2P_Expiration) of PCCBS_Device Client database. 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.

Figure 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. At step 1641, the PCCBS_VPN communicates with the PCCBS_VPN Utility (labeled as 1611). 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) is accepted. 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). At step 1616, an 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 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).

Figure 17 illustrates a flow diagram of a 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. At step 1741, the PCRS_VPN communicates with the PCRS_VPN Utility (labeled as 1711). 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, the PCCBS establishes a point-to-point connection channel between the PCCBS_VPN Device Client and the 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) is accepted. In step 1715 , retrieve 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) of Address_PCRS_VPN_Client based on the PCCBS VPN client database (PCRS_VPN Client database). 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.

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.

as shown below: 0, 1~8, 3-1, 3-3, 4-1, 4-3, 6-3: code 100, 200, 300, 400: public cloud 102, 103, 202, 203, 302, 303, 403: Router, Router_P, Router_S 104, 105, 204, 205, 304, 305, 334, 405, 434: Local Area Network, LAN, Local Area Network 101, 106, 107, 109, 110, 111: Smart Device Client 108: Private Cloud Server 112, 212, 312, 412, 1200: public routing server 113, 213, 313, 413: public cloud server 114, 214, 314, 414: Public VPN routing server 201, 209, 210, 211, 221, 301, 309, 310, 311, 321, 401, 409, 410, 411, 421: PCCBS device client 206, 207, 306, 307, 335, 435: PCRS device client 208, 308, 408: PCRS 216, 316, 416: PCCBS 215, 315, 415: Client message box 222, 223, 224, 225, 322, 323, 324, 325, 326, 422, 423, 424, 426: Communication path 228, 328, 336, 436: Private Internet Services 240, 2400, 340, 440: VLAN 360, 460: LAN2 270, 1300, 1302: PCRS Utility 271: PCRS client database 272, 276, 280, 282: Client message box Utility 273: PCRS Administrator Device 274: PCRS Device App 275: PCRS database 277: PCCBS administrator device 278: PCCBS Device App 279: PCCBS database 281: Invitee Device 1201: Device Client 1 1202: Device Client 2 1301: PCRS Device Client 1 App 1420: PCCBS administrator device 1421: PCRS Device Utility 1422:PCRS VPN Utility 1423:PCCBS VPN Utility 1424: PCCBS Device Utility 1425: PCCBS device client 1 2700: PCCBS Utility 2710: PCCBS Client Database 2720: Server Message Box Utility 500~508, 510~516, 540~543: Steps 600~605, 610~614, 620~622, 640~642: Steps 700~707, 710~720, 740~744: Steps 800~821, 840~848: Steps 900~906, 910~912, 940~942: Steps 1000~1008, 1010~1017, 1020, 1040~1045: Steps 1100~1105, 1110~1116, 1140~1142: Steps 1203~1210: Steps 1303~1310: Steps 1400~1407, 1413~1414, 1416, 1427~1428: Steps 1500~1507, 1510~1520, 1540~1544: Steps 1600~1617, 1619~1620, 1640~1646, 1648: Steps 1700~1717, 1719, 1721, 1740~1746, 1748: Steps

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 of an administrator viewing 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 (prior art).

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.

none

200: Public Cloud

202, 203: Router

204, 205: Local Area Network

201, 209, 210, 211, 221: PCCBS device client

216: PCCBS

206, 207: PCRS device client

208:PCRS

212: Public routing server

213: Public cloud server

214: Public VPN routing server

215: Client message box

222, 223, 224, 225: Communication path

228: Private Network Services

240, 2400: VLAN

270:PCRS Utility

271: PCRS client database

272, 276, 280, 282: Client message box Utility

273: PCRS Administrator Device

274: PCRS Device App

275: PCRS database

277: PCCBS administrator device

278: PCCBS Device App

279: PCCBS database

281: Invitee Device

2700: PCCBS Utility

2710: PCCBS Client Database

2720: Server Message Box Utility

Claims (17)

A method for use with a public cloud network, the method comprising: In a client server relationship, at least one private cloud routing server, at least one private cloud callback server and at least one smart device client are set; wherein the at least one private cloud routing server includes a first message box associated with the at least one private cloud routing server, and the first message box is located in the public cloud network; wherein the at least one smart device client includes a second message box associated with the at least one smart device client, the second message box is located in the public cloud network; and wherein the at least one private cloud callback server hosts the first message box and the second message box on the public cloud network; transmitting a conversation message between the first message box and the second message box by a secure method; wherein a secure session message connection mechanism hosted by the at least one private cloud callback server located between the at least one private cloud routing server and the at least one smart device client comprises: initializing and preparing the at least one The private cloud routing server and the at least one private cloud callback server, create a private cloud callback server client, view the private cloud callback server client, edit a private cloud callback server peer-to-peer password and the A state of the private cloud callback server, modifying the peer-to-peer password of the private cloud callback server through the at least one smart device client, and connecting to the at least one private cloud routing server through the at least one smart device client ; wherein the meeting message is verified by the at least one private cloud callback server and the at least one smart device client; wherein the at least one smart device client communicates with the at least one private cloud callback server in response to the verification of the meeting message; wherein according to the verified meeting message, the at least one smart device client securely accesses a private network service through the public cloud network; Setting at least one private cloud callback server, the at least one private cloud callback server and at least one private cloud routing server are in a client server relationship; wherein the at least one private cloud callback server and the at least one private cloud routing server communicate with each other in response to the verification of the meeting message; wherein the at least one private cloud callback server and the at least one private cloud callback server communicate with each other privately and securely through the public cloud network; Setting the at least one smart device client, the at least one smart device client is in a client server relationship with the at least one private cloud callback server; and Setting at least one other smart device client, the at least one other smart device client is in a client server relationship with the at least one private cloud routing server; wherein the at least one smart device client and the at least one other smart device client communicate with the at least one private cloud callback server and the at least one private cloud routing server in response to the meeting message being authenticated; as well as Wherein the at least one smart device client and the at least one other smart device client communicate with each other privately and securely through the public cloud network. The method of claim 1, wherein the at least one private cloud callback server comprises: a computing device; a connection to a network; and a program that executes instructions stored in a memory to cause the at least one private cloud callback server to perform the following actions: Create and manage a list of authenticated clients to accommodate multiple smart device clients; sending a meeting invitation to the second message box; retrieving a session access request from the at least one smart device client from the first message box; and Send a session confirmation to the second message box. The method of claim 2, wherein the program further executes an instruction stored in the storage to cause the at least one private cloud callback server to perform the following actions: sending a communication request to the at least one smart device client; sending a communication request to the at least one private cloud routing server; binding the network connection between the at least one private cloud callback server and the at least one private cloud routing server; routing a new incoming request from the at least one smart device client on the side of the at least one private cloud callback server to the at least one private cloud routing server; establishing a secure peer-to-peer communication with the at least one smart device client on the side of the at least one private cloud callback server; Enable access to the at least one private network service from the at least one smart device client on the side of the at least one private cloud routing server; Call back to the at least one private cloud routing server according to the request of the smart device client to connect to the at least one other smart device client, the at least one private cloud routing server in the at least one private cloud routing server The at least one other smart device client can be reached in a virtual private network of the server; and Enabling private and Secure communication. The method of claim 2, wherein the at least one smart device client on the side of the at least one private cloud callback server comprises: a computing device; and a connection to a network through a router; The router has a program, and the program executes the instructions stored in the storage, so as to make the at least one smart device client perform the following actions: retrieving a meeting invitation from the at least one smart device client message box; sending a session access request to the at least one private cloud routing server message box; retrieving a session confirmation from the at least one smart device client message box; sending a communication request to the at least one private cloud callback server; sending a communication request to the at least one smart device client; binding the network connection between the at least one private cloud callback server and the at least one smart device client; routing an incoming request from the at least one private cloud callback server to the at least one smart device client; establishing a secure peer-to-peer communication with the at least one private cloud callback server; access the at least one private network service through the at least one private cloud callback server; and Communication is performed with at least one other smart device client on the side of the at least one private cloud routing server through the at least one private cloud routing server. The method of claim 2, wherein the at least one smart device client on the side of the at least one private cloud routing server comprises: a computing device; a connection to a network, either wired or wireless; and A program that executes the instructions stored in the memory to cause the at least one smart device client to perform the following actions: retrieving a meeting invitation from the at least one smart device client message box; sending a meeting reply to the at least one private cloud routing server message box; retrieving a session confirmation from the at least one smart device client message box; sending an access request to the at least one private cloud callback server; waiting for a reply from the at least one private cloud routing server; binding the network connection between the at least one private cloud routing server and the at least one smart device client; routing an incoming request from the at least one private cloud routing server to the at least one smart device client; establishing a secure peer-to-peer communication with the at least one private cloud routing server; access the at least one private network service through the at least one private cloud routing server; and Communication is performed with the at least one other smart device client on the side of the at least one private cloud callback server through the at least one private cloud callback server. The method of claim 4, wherein the program further: Access the at least one private cloud routing server anytime and anywhere; accessing the at least one private cloud routing server with a fixed or a floating IP address behind a firewall; Wherein the at least one smart device client on the side of the at least one private cloud callback server does not require a public cloud routing server in a wide area network, does not require additional router settings in the local area network, and is compatible with The at least one private cloud routing server establishes a secure peer-to-peer communication channel; accessing a private network service through the at least one private cloud callback server and the at least one private cloud routing server; and Communication is performed with at least one other smart device client on the side of the at least one private cloud routing server through the at least one private cloud routing server. The method of claim 5, wherein the program further comprises: Access the at least one private cloud routing server anytime and anywhere; accessing the at least one private cloud routing server with a fixed or a floating IP address behind a firewall; Wherein the at least one smart device client does not require a public cloud routing server in a wide area network, does not require additional router settings in the local area network, and establishes a secure peer-to-peer communication with the server; access private network services through the at least one private cloud routing server; and Communicate with the at least one other smart device client through the at least one private cloud routing server. The method of claim 4, wherein the program further comprises: Access the at least one private cloud routing server anytime and anywhere; accessing the at least one private cloud routing server with a fixed or a floating IP address behind a firewall; The at least one smart device client does not require a public cloud routing server in a WAN, does not require additional router settings in a local area network, and establishes a secure peer-to-peer connection with the at least one private cloud routing server communication channel; mapping a regional entity input and output to a virtual private cloud routing server input and output; access a private network service through the at least one private cloud routing server; and Communicate with at least one other smart device client through the at least one private cloud routing server. The method of claim 5, wherein the program further comprises: Access the at least one private cloud routing server anytime and anywhere; accessing the at least one private cloud routing server with a fixed or a floating IP address behind a firewall; Wherein the at least one smart device client does not require a public cloud routing server in a wide area network, does not require additional router settings in the local area network, and establishes a secure peer-to-peer communication with the server; mapping a region entity I/O to a virtual server I/O; access private network services through the at least one private cloud routing server; and Communicate with the at least one other smart device client through the at least one private cloud routing server. The method of claim 1, wherein the at least one private cloud routing server comprises: a computing device; a connection to a network; and a program that executes instructions stored in a memory to cause the at least one private cloud routing server to perform the following actions: Create and manage an authenticated client list to accommodate a plurality of smart device clients; sending a meeting invitation to the second message box; retrieving a session access request from the at least one smart device client from the first message box; and Send a session confirmation to the second message box. The method of claim 10, wherein the program further executes instructions stored in the storage to cause the at least one private cloud routing server to perform the following actions: sending a communication request to the at least one smart device client; sending a communication request to the at least one private cloud routing server; binding the network connection between the at least one private cloud routing server and the at least one private cloud routing server; routing a new incoming request from the at least one smart device client on the side of the at least one private cloud routing server to the at least one private cloud routing server; establishing a secure peer-to-peer communication with the at least one smart device client on the side of the at least one private cloud routing server; enabling access to the at least one private network service from the at least one smart device client on the side of the at least one private cloud routing server; and enabling privacy and security between the at least one smart device client on the side of the at least one private cloud callback server and the at least one other smart device client on the side of the at least one private cloud routing server communication. A method for providing a secure conversation message connection mechanism between a private cloud callback server and at least one smart device client in a private cloud callback server network, the method comprising: Initialize and prepare the private cloud callback server; Create a private cloud callback server client; View the private cloud callback server client; Edit a private cloud callback server peer-to-peer password and a state of the private cloud callback server; Modifying the P2P password of the private cloud callback server through the at least one smart device client; resetting the private cloud callback server peer-to-peer password and the status from a private cloud callback server LAN through a system administrator; and Connecting to the private cloud callback server through the at least one smart device client. A method for a communication process of a connection mechanism between the at least one private cloud callback server device client and the at least one private cloud routing server device client through a cloud network , the method contains: Through at least one private cloud callback server device client application requests to connect to a server part utility of a private cloud callback server through a client message box, wherein the server part of the private cloud callback server is common The program receives a registration via a routing server message box; registering with the private cloud routing server utility through the at least one private cloud routing server device client; the client part utility registered to the private cloud callback server through the private cloud routing server utility; receiving requests from the server part utility of the private cloud callback server through the client part utility of the private cloud callback server; callback to the private cloud routing server utility through the client part utility of the private cloud callback server with a connection intent; sending a communication request from the private cloud routing server utility to the at least one private cloud routing server device client; and Initiate peer-to-peer communication from the private cloud callback server device client to the client part utility of the private cloud callback server, and then to the server part utility of the private cloud callback server , then to the client part utility of the private cloud callback server, then to the private cloud routing server utility, and finally to the private cloud routing server device client. A method as claimed in claim 13, wherein the callback server message box or the client message box is hosted on one of an email server, a text message server, a web server, or a server, and the servers are configured to host A secure message for information exchange between the private cloud callback server and the private cloud callback server device client; wherein the callback server box or the client box is accessible and under the secure and private control of the private cloud callback server or the private cloud callback server device client; and Wherein, when the callback server message box or the client message box is stopped, it can be replaced or redeployed immediately without compromising the private cloud callback server and the private cloud callback server in the cloud network communication between server device clients. The method of claim 13, further comprising providing a secure conversation message connection mechanism between a private cloud routing server and at least one smart device client in a private cloud routing server network, wherein the secure The conference message connection mechanism includes: initialize and prepare the private cloud routing server; Create a private cloud routing server client; View the private cloud routing server client; Edit a P2P password and a status of a private cloud routing server; Modifying the peer-to-peer password of the private cloud routing server through the at least one smart device client; reset the private cloud routing server peer-to-peer password and the status from a private cloud routing server LAN through a system administrator; connecting to the client portion of the private cloud callback server; and Connecting to the private cloud callback server through the at least one smart device client. A non-transitory computer-readable medium storing executable instructions that, when executed, cause a computer to perform the following operations: In a client server relationship, set a private cloud callback server and a smart device client, wherein the private cloud callback server includes a routing server message box utility for accessing a first message box on a public cloud network, wherein the private cloud callback server registers the public and private Internet Protocol addresses of the smart device client, wherein the smart device client includes a client message box utility for accessing a second message box located in the public cloud network, wherein the private cloud callback server transmits a session acknowledgment with public and private internet protocol addresses to the second message box; In a secure process, a session message is transmitted between the first message box and the second message box through the routing server message box utility of the private cloud callback server, Wherein the secure process for transmitting the meeting message between the private cloud callback server and the first message box and the second message box of the smart device client respectively includes: Initialize and prepare the private cloud callback server, Create a private cloud callback server client, View the private cloud callback server client, edit a peer-to-peer password and a state of the private cloud callback server, and Modifying a peer-to-peer password of a private cloud callback server through the smart device client, and connecting to the private cloud callback server through the smart device client, The smart device client is connected to the private cloud callback server through at least one of the following connection methods: The smart device client determines that a target is located in a local area network with regional access, and decides to directly connect to the private cloud callback server, The smart device client determines that the target is not located in the area-accessible local area network, and determines to connect to the public cloud via a wide area network, wherein the wide area network locates a router and the location of the local area network, and connect to the private cloud callback server, The smart device client determines that the target is not located in the local area network with regional access, and determines to connect to the public cloud network in the wide area network through the local area network and the router, One of the secure chat messages is verified by the private cloud callback server and the smart device client, Wherein the smart device client and the private cloud callback server communicate with each other after the meeting message is authenticated, wherein the smart device client securely accesses a private network service through the public cloud network according to the verified conversation message; and Setting at least one other smart device client, the at least one other smart device client is in a client server relationship with the private cloud callback server, wherein the smart device client and the at least one other smart device client communicate with the private cloud callback server after the meeting message is authenticated, and Wherein the smart device client and the at least one other smart device client communicate with each other privately and securely through the public cloud network. A non-transitory computer-readable medium storing executable instructions that, when executed, cause a computer to perform the following operations: A request from a client device application to connect to a private cloud callback server utility through a client message box, wherein a server portion of the private cloud callback server utility receives a register; the private cloud callback server client device requests the server part of the private cloud callback server utility through the client message box to connect to a client part of the private cloud callback server utility; The server portion of the private cloud callback server utility receives the request through a routing server message box; The server portion of the private cloud callback server utility notifies the client portion of the private cloud callback server utility of an intent for the server portion to connect; the client portion of the private cloud callback server utility responds with a registration to the server portion of the private cloud callback server utility; The server portion of the private cloud callback server utility responds to the client device application through the routing server message box; transmit a communication request to the at least one private cloud routing server through the client portion of the private cloud callback server utility; registering the public and private Internet Protocol addresses of the private cloud callback server client device through the private cloud callback server utility; sending a session identified according to the public and private Internet addresses to the client message box through the private cloud callback server utility; and enabling peer-to-peer communication between the private cloud callback server client device and the client portion of the private cloud callback server utility; wherein the private cloud callback server utility and the private cloud callback server client device exchange information through the routing server message box and the client message box; wherein the private cloud callback server client device is connected to the client portion of the private cloud callback server utility through at least one of the following connection methods: The private cloud callback server client device determines that the client part of the private cloud callback server utility is located in a local area network with local access, and decides to directly connect to the private cloud callback server utility program, The private cloud callback server client device determines that the client portion of the private cloud callback server utility is not in the area-accessible local area network, and determines to connect to the cloud network via a wide area network , wherein the wide area network locates a router and the location of the local area network and is connected to the private cloud callback server utility, and The private cloud callback server client device determines that the client portion of the private cloud callback server utility is not located in the local area network that can be accessed locally, and determines to go through the local network and the router, and Connect to the cloud network in the WAN.

Images