CN115208603A

CN115208603A - Connection method and computer readable medium for private communication architecture

Info

Publication number: CN115208603A
Application number: CN202210016648.2A
Authority: CN
Inventors: 陈维斌
Original assignee: Kingston Digital Inc
Current assignee: Kingston Digital Inc
Priority date: 2021-04-13
Filing date: 2022-01-07
Publication date: 2022-10-18
Also published as: TW202241089A; GB2609677A; TWI769965B; GB202115368D0

Abstract

A method for use with a public cloud network is provided, comprising: the system comprises a setting virtual machine, a private cloud callback server, an intelligent device on one side of the private cloud callback server for providing cloud network service, a private cloud routing server and an intelligent device on one side of the private cloud routing server. The virtual machine and the private cloud callback server are installed in an ultra-large data center, and the private cloud routing server is installed in a far-end factory area of a user side. The private cloud callback server is used as a middle person to relay communication between the intelligent device user side and the private cloud routing server on one side of the private cloud callback server. And the private cloud callback server calls back the private cloud routing server according to the requirement of the intelligent device user side. The private cloud callback server comprises a first message box related to the private cloud callback server.

Description

Connection method and computer readable medium for private communication architecture

Technical Field

The present invention relates to networks. More particularly, the present invention relates to the application of private cloud networks.

Background

In the internet connection environment, smart device clients, including smart phones, tablet computers, e-book readers, notebook computers, personal computers, and various smart appliances, are very common and ubiquitous. In addition to Internet connectivity, one of the benefits of an intelligent device client is the ability to obtain services from one or more servers at any time and any place. These services include voice, video content, live or archived information, execution of applications, social media, messaging, email, storage media, backup, calendar, contacts, synchronization, sharing, remote desktop, and Internet of Things (IoT), among others. Other services include real-time private and secure video, voice, text, and application communications between at least two smart device clients.

The server with different types can be used to meet the requirements of various intelligent device clients. Generally, these types of servers can be divided into two groups: a public cloud and a private cloud. Public cloud servers, as their name "" public "", provide free but limited functionality or pay for more sophisticated services, and interact with the public. Examples of public cloud servers include data centers, social media services, and storage content providers on a network. On the other hand, private cloud servers tend to meet private requirements. Compared with the public cloud, the server in the private cloud provides more private and personalized services.

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 (LAN) managed by a user. It provides online and backup storage for users in Local Area Networks (LAN) or Wide Area Networks (WAN). The user can use the smart device client to access information from the private cloud storage server at any time and any place. The private cloud server and the associated smart device client thus form a framework of the private cloud server and the smart device client.

Traditionally, there are many Storage server solutions, including Network Attached Storage (NAS), windows/Mac/Linux servers, and Direct Attached Storage (DAS) to meet the demands of private cloud Storage servers. However, a challenge encountered by these smart device clients is to avoid cumbersome installations to penetrate the firewall behind the lan router to access private cloud storage servers in the home or office environment. There are at least four solutions to this challenge.

One solution is to arrange a fixed Internet Protocol (IP) address and open a port in the front-end router of the private cloud storage server, such that the smart device client can probe out of the private cloud storage server from outside the local area network and perform self-authentication, penetrate the firewall and establish a secure communication channel with the private cloud storage server.

The second solution is adapted to not obtain a fixed IP address. The user installs the router of the private cloud storage server LAN and opens the connection port corresponding to the private cloud storage server. The router can thus be detected by the intelligent device client via a floating Domain Name System (DDNS) service on the WAN. The intelligent device client can self-verify, penetrate the firewall and establish a secure communication channel connected with the private cloud storage server.

A third solution relies on another routing server in the WAN to connect a Virtual Private Network (VPN) between the intelligent device client and the Private cloud storage server. The VPN communication allows the intelligent device client to locate the private cloud storage server, self-authenticate, penetrate the firewall, and establish a secure communication channel to the private cloud storage server.

A fourth solution relies on another routing server in the wan to conduct Remote Desktop Protocol (RDP) or Virtual Network Computing (VNC) communications between the smart device client and the private cloud server. The RDP or VNC communication allows the smart device client to locate the private cloud server, self-authenticate, penetrate the firewall, and establish a secure communication channel with the private cloud server. Other solutions are combinations of the above solutions.

In the first scheme, a fixed IP address is required and the router needs to be installed. Fixed IP addresses are costly and generally not suitable for use in home and small business environments. Thus, the router installation is very complex and not easy to handle for most consumers.

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

In the third and fourth schemes, when installation of a router is not necessary, an external routing server or service needs to be installed. The external routing server or service is used to control and manage the login or authentication between the intelligent device client and the server. Through the public cloud server or service, the 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 is compromised.

The technical expertise required for the above approach may be applicable to the traditional overall environment, but is not applicable to consumer-oriented smart device user-side centric arrangements.

In most conventional systems, a routing server at an external or public cloud is used by the smart device client during access to private cloud services. The use of external servers poses a number of concerns for the owner of the intelligent customer premises.

First, the sense of trust is always a problem because the routing server of the outside or public cloud plays a role as a middleman in the communication process between the smart client and the private cloud service. It will master the account information, password and IP address of all the intelligent device clients and users of private cloud services. The routing server becomes insecure because it can discover any communication in between.

Second, a routing server that is an external or public cloud, may not always have a business model of the owner of the server consistent with the owner of the smart device client. If the routing server is out of service for any business reason, there is no patching method or alternative selection method to restore service. Routing servers potentially pose a significant business risk to users, for example, the requisite connections in a communication can be easily destroyed without expending resources.

Traditionally, in the case of communication between two smart device clients, both parties need to log into a common cloud server to perform real-time video, voice, text and application communication. As described above, since the communication must pass through the public cloud server, privacy and security are easily compromised.

In view of the foregoing, a need exists for a system and method that addresses the foregoing problems. The present invention satisfies this need.

Disclosure of Invention

To solve at least the above problems, embodiments of the present invention provide a method for use with a public cloud network. The method can include setting at least one virtual machine, at least one private cloud callback server, at least one intelligent device user on the private cloud callback server side for providing cloud network services, at least one private cloud routing server, and the at least one intelligent device user on the private cloud routing server side, where the at least one virtual machine, the at least one private cloud callback server, the at least one intelligent device user on the private cloud callback server side for providing cloud network services, the at least one private routing server, and the at least one intelligent device user on the private cloud routing server side are in a user server relationship. The virtual machine and the private cloud callback server are typically installed in an ultra-large data center, and the private cloud routing server is installed in a remote factory device at a user end.

The private cloud callback server is used as a middle person to relay communication between the intelligent device user side and the private cloud routing server on one side of the private cloud callback server. The private cloud callback server can call back to the private cloud routing server according to the requirements of the intelligent 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 related to the private cloud routing server is located in the private cloud callback server on the public cloud network. The method also includes communicating a session message between the first message box and the second message box, and communicating a session message between the second message box and the third message box in a secure manner.

The secure session message connection mechanism between the private cloud routing server, the private cloud callback server, and at least one smart device client comprises: initializing and preparing the private cloud callback server, creating a private cloud callback server user side, checking the private cloud callback server user side, editing a private cloud callback server point-to-point password and a state through a system manager, modifying the private cloud callback server point-to-point password through the at least one intelligent device user side, resetting the private cloud callback server point-to-point password and the state from a private cloud callback server area network through a system manager, and connecting to the private cloud callback server through the at least one intelligent device user side. Wherein the session message is verified by the private cloud routing server, the private cloud callback server, and at least one smart device client. The intelligent device user side, the private cloud routing server and the private cloud callback server can communicate with each other after the session message is verified.

According to the verified session message, the at least one smart device client securely accesses a private network service through the public cloud network. The method also includes setting the at least one other smart device client in a client server relationship with the at least one private cloud routing server and the at least one private cloud callback server. The at least two intelligent device clients can communicate with each other after the session message is verified. The at least two intelligent device clients can perform private and secure communication through a public cloud network. By adopting the private cloud callback server between the intelligent device client and the private cloud routing server, all types of Network Address Translation (NAT) routers in a local area Network environment can be more effectively passed without using the traditional Hole-punching technology (Home-punching). Due to the advent of 5G, 6G and Wi-Fi 6 networking technologies, the performance of communication is significantly enhanced by the private cloud callback server to minimize latency of communication. The invention has the advantages of easy deployment, high privacy and security, complete compatibility and high performance in order to access an internet of things device from one smart device client to another or from the home anywhere in the world.

Drawings

Fig. 1 illustrates a schematic diagram of a conventional cloud network architecture.

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

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

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

Fig. 5 illustrates a flowchart of the private cloud routing server administrator initializing and provisioning 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 flowchart of the private cloud callback server device client registering with a private cloud callback server according to the present invention.

Fig. 8 illustrates a flow chart from the private cloud callback server device client to the private cloud callback server in accordance with the present invention.

Fig. 9 illustrates a flow diagram of an administrator viewing a client side of a private cloud routing server in accordance with the present invention.

Fig. 10 illustrates a flowchart of administrator resetting private cloud callback server device client side point-to-point password and editing attributes according to the present invention.

Fig. 11 illustrates a flow chart of modifying a private cloud callback server device user side point-to-point password according to the present invention.

Fig. 12 illustrates a flow chart of a peer-to-peer connection mechanism between device client1 and device client2 through a 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 over a cloud network (prior art).

Fig. 14 illustrates a flow diagram 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 server device client through a cloud network.

Fig. 15 illustrates a flow chart of the private cloud routing server registering with the private cloud callback server vpn according to the present invention.

FIG. 16 is a flow chart illustrating the private cloud routing server to private cloud callback server VPN according to the present invention.

Fig. 17 illustrates a flow chart of the private cloud callback server callback to the private cloud routing server vpn according to the present invention.

Fig. 18 illustrates a flow chart of a peer-to-peer connection mechanism for a private cloud routing server, a private cloud callback server, a private cloud routing server client, and a private cloud callback server client through a cloud network based on server clusters, computer resource aggregation, and virtual machines.

Description of the symbols

As shown below:

0. 1-8, 3-1, 3-3, 4-1, 4-3, 6-3: code number

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: intelligent device user side

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 route server

201. 209, 210, 211, 221, 301, 309, 310, 311, 321, 401, 409, 410, 411, 421: PCCBS device user side

206. 207, 306, 307, 335, 435: PCRS device user side

208、308、408：PCRS

216、316、416：PCCBS

215. 315, 415: user end information box

222. 223, 224, 225, 322, 323, 324, 325, 326, 422, 423, 424, 426: communication path

228. 328, 336, 436: private network service

240、2400、340、440：VLAN

360、460：LAN2

270、1300、1302：PCRS Utility

271: PCRS client database

272. 276, 280, 282: user end information 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 user end 1

1202: device user end 2

1301: PCRS device user side 1App

1420: PCCBS administrator device

1421: PCRS device Utility

1422：PCRS VPN Utility

1423：PCCBS VPN Utility

1424: PCCBS device Utility

1425: PCCBS device user side 1

1830: server cluster

1831: computer resource aggregation

1832: virtual machine

2700：PCCBS Utility

2710: PCCBS client database

2720: server message box Utility

500-508, 510-516, 540-543: step (ii) of

600 to 605, 610 to 614, 620 to 622, 640 to 642: step (ii) of

700 to 707, 710 to 720, 740 to 744: step (ii) of

800-821, 840-848: step (ii) of

900 to 906, 910 to 912, 940 to 942: step (ii) of

1000-1008, 1010-1017, 1020, 1040-1045: step (ii) of

1100 to 1105, 1110 to 1116, 1140 to 1142: step (ii) of

1203 to 1210: step (ii) of

1303 to 1310: step (ii) of

1400 to 1407, 1411, 1413 to 1414, 1416, 1427 to 1428: step (ii) of

1500 to 1507, 1510 to 1520, 1540 to 1544: step (ii) of

1600-1617, 1619-1620, 1640-1646, 1648: step (ii) of

1700 to 1717, 1719, 1721, 1740 to 1746, and 1748: step (ii) of

1801 to 1807, 1811, 1827 to 1828: step (ii) of

Detailed Description

The present invention relates to networks. More particularly, the present invention relates to a private cloud network. The following description is presented to enable one of ordinary skill in the art to make and use the invention and is provided in the context of a patent application. Other embodiments of the present invention will be readily apparent to those skilled in the art from the following description of the embodiments, the principles and features of which are essentially the same as those of the present invention. Thus, the present invention is not intended to be limited to the embodiments shown below, but is to be accorded the widest scope consistent with the principles and features disclosed herein.

In the following description, the "client" may be equivalent to the "smart device client", and the "router" may be equivalent to the "gateway", "access point", or "IP address translation".

The intelligent device user in the WAN of the present invention can obtain services from a Private Cloud Storage Server (PCSS) or any Private Cloud Server (PCS), so the system and method of the present invention solve the following challenges faced by users in the use environment:

1. the private cloud server is accessed anytime and anywhere.

2. A private cloud server having a fixed or a floating Internet protocol (hereinafter IP) address behind a firewall is accessed.

3. There is no need for a public cloud based routing server in the wide area network.

4. No additional routers need to be provided in the local area network.

5. And verifying the private cloud server.

6. And establishing a secure communication channel with the private cloud server.

If the present invention can overcome and solve the above-mentioned challenges, the deployment of the private cloud server or service will grow exponentially due to the simple plug and play feature of the present invention. Even without the use of a public cloud-based routing server, the technical and commercial problems associated with the present invention are eliminated. Therefore, private cloud servers for storage, remote desktop, and internet of things will become very affordable and popular in the infrastructure of private cloud.

In the Private Cloud environment, if a plurality of Private Cloud servers or services coexist, it is advantageous to divide the Private Cloud servers into two functional blocks, namely, a Private Cloud Routing Service (PRS) and a Private Network Service (PNS). Through the intelligent device client, the private network service is managed and accessed in the 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 web service can also be used as a storage server, which can include a plurality of TB storage spaces provided 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 a PCRS. The PCRS may also be commonly referred to as a "private cloud router".

The intelligent 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 in the use environment for users:

1. the PCRS is accessed anytime and anywhere.

2.PCRS with a fixed or a floating IP address behind a firewall is accessed.

3. There is no need for routing servers based on external or public clouds in wide area networks.

4. No additional routers need to be provided in the local area network.

5. And verifying the PCRS.

6. A secure communication channel is established with the private network service.

If the PCRS of the present invention can solve the above-mentioned challenges, it can split the different private cloud servers of different manufacturers and suppliers into simpler private web services, and eliminate the complexity of private cloud configuration, configuration and access.

The system and method of the present invention are directed to provide a PCRS, private network server and client architecture without using a routing server. The system and method of the present invention satisfies the above-mentioned challenge, i.e., a client can access the private network server anytime and anywhere. The system and method also access the private network server behind a fixed or floating IP firewall to authenticate with the PCRS and establish a secure communication channel directly with the private network server without adding additional routing settings or public cloud routing servers in a wide area network.

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 (VPN) routing server 114, an intelligent device client 101 in a wide area network, a Router (Router _ P) 102, and a Router (Router _ S) 103. The router 103 is used to connect a Local Area Network (LAN) 105 with the network of the public cloud 100. The router 102 is used to connect a Local Area Network (LAN) 104 with the network of the public cloud 100. At the back end of the LAN 104, there are

smart device clients

106, 107 and a private cloud server 108. At the back end of the LAN 105, there are

smart device clients

109, 110, and 111. The smart device client may be a personal computer, a notebook computer, a tablet computer, an e-book reader, a GPS, a smart tv, a set-top box, an MP3 player, or any internet-enabled embedded device.

They are denoted 101, 106, 107, 109, 110 and 111 in the cloud network architecture. Any of the above smart device clients may be replaced as desired herein. The following description will be made with reference to the representative smart device client 109.

Physically, there are three situations where 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 LAN 104 and determines to connect directly to the private cloud server 108. Second, the smart device client 101 determines that the target is not located in an accessible area of the lan 104 and determines to connect to the public cloud 100 via the wan. The WAN can locate the router 102 and LAN 104 and then connect to the private cloud server 108. Third, the smart device client 109 determines that the target is not located in an accessible area of the local area network 105, and determines 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 locates the router 102, LAN 104 and connects to the private cloud server 108. The first and second cases are two specific examples of derivatives of the third case. Therefore, a third case of wider range and complexity of applications is beneficial.

The routing server message box (not shown) or the client message box 215 can be hosted by one of an email server, a text message server, a web server, or any type of server that hosts a secure message for information exchange between a server (PCRS 208 and private cloud callback server (hereinafter "PCCBS") 216) and a client (

smart device clients

206, 207, 209, 210, 211, 201, and 221). Callback server boxes (not shown) or Client Box _ S (Client Message Box _ Message _ Box _ S) 215 are accessible and under secure and private control of a server (PCRS 208 and PCCBS 216) and a Client (

smart device clients

206, 207, 209, 210, 211, 201, and 221). The security and business model of the message box is well understood and expected by the user in the industry. For any reason, when the message box is stopped, it can be replaced or re-deployed immediately without jeopardizing the communication between the server and the client in the private cloud infrastructure.

A first embodiment of the present invention is a cloud-based network infrastructure, which is depicted in fig. 2. In this embodiment, the secure connection mechanism between the PCRS, PCCBS and the smart device client is used for the discovery and access of private network services across the public cloud. As disclosed in fig. 5-15, the

smart device clients

201, 211, and 221 locate the PCRS 208 via

communication paths

222, 224, and 223, respectively. In addition, the PCRS 208 and PCCBS 216 construct 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 VLAN 240 and the VLAN 2400 as members. 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 visitor through the installed program to receive the communication invitation and join in a private and secure communication session with the smart device client 201.

As shown in fig. 2, when the smart device client 201 acts as a host to start a communication session, the process installed on the smart device client acting as the host first locates and registers to the PCCBS 216 via the communication path 222. After PCCBS 216 locates PCRS 208, it joins virtual LAN 240. The smart device client 201 acts as a host to promise chat communications. The process allows the smart device client to create and host a communication session. The program broadcasts the host session to invite communication guest 221. The program then begins scanning for identifiable visitors. Once the visitor's identity is verified, the smart device user 201 may act as a host for private and secure communications with the verified visitor (smart device user) 221. The private and secure communications include video, voice, text, and application communications. The application communication may 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 is to participate in a communication session as a visitor, the process installed on the visitor (smart device client) first locates and logs into the PCCBS 216 via the

communication path

224 or 223, respectively. After the PCCBS 216 is located to the PCRS 208, it joins the virtual LAN 240 under the server. The intelligent device user end is used as a user end to promise to join the chat communication. The process waits for a communication invitation. Once it receives the communication invitation, the

smart device client

211 or 221 may join a communication session as a visitor. The program then begins scanning for identifiable visitors. And after the program identifies the host, carrying out communication login verification prompted by the host. Once authenticated, the smart device client may join the communication session. The

smart device client

211 or 221 acts as a guest to communicate with the host (smart device client) 201 in a private and secure manner. The private and secure communications include video, voice, text, and application communications. The application communication may 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 that is reachable by the virtual local area network 240 and the virtual local area network 2400 under the physical local area network 250 or the PCRS and PCCBS. As shown in FIG. 2, once the

smart device client

201, 211 or 221 locates and registers with the PCCBS 216, it can access the private network services 228 accessible to the virtual LAN 240 and the virtual LAN 2400 under the physical LAN 250, 260 or the PCRS and PCCBS via the communication path 225. The private web services include voice, video content, live or archived information, application execution, social media, messaging, email, storage media, backup, calendar, contacts, synchronized video, sharing, remote desktop, and Internet of Things (IoT).

In some embodiments, the communication path 225 between the PCRS, PCCBS and the smart device client may include a plurality of instructions:

1. a PCRS is initialized and provisioned (via an administrator of the LAN from the PCRS).

2. A PCCBS is initialized and provisioned (via an administrator of a wide area network from the PCCBS).

3. A PCRS client is created (via an administrator of the PCRS from the local area network).

4. Register to a PCCBS (via the PCCBS client from the wide area network).

5. Connected to a PCCBS (via the PCCBS server client from the wide area network).

6. Look at a PCCBS client (through a system administrator from the PCCBS's wide area network).

7. A PCCBS point-to-point password and status is reset (via a system administrator from the PCCBS wide area network).

8. Modify a PCCBS point-to-point password and status (through the PCCBS client from the wide area network and through a VPN).

A wide variety of entities are introduced as secure communication channels 225, including but not limited to: system administrator, administrator device, PCRS Utility, PCCBS Utility, PCRS device client, PCCBS device client, invitee device. The definition of these entities is as follows. Utility refers to a Utility running in the PCRS. An administrator device refers to a device used by a system administrator to configure the PCRS. A PCRS device user refers to a device that an invitee uses to communicate with the PCRS. Invitees refer to a physical party that is invited to access the services and resources of the PCRS through an administrator. The invitee device is an intelligent device client that the invitee uses to communicate with the PCRS.

A number of related terms are introduced, including: access Code (Access Code), code Expiration (Code Expiration), invitee Address (Address _ invite), PCRS Client Address (Address _ PCRS _ Client), PCRS Client peer-to-peer Hash Password (Hash _ passed _ PCRS _ P2P), PCRS Client peer-to-peer Password Expiration (passed _ PCRS _ P2P _ Expiration), and Status of PCRS Client database (Status in PCRS Client database). These terms are defined as follows. Access Code refers to an invitee Access Code sent by the PCRS via message box 216 through an administrator. Code _ Expiration refers to the Expiration date/time of the access Code for security purposes. Address _ Invite refers to the Address of the message box of the Invitee. Address _ PCRS _ Client refers to the box Address of the PCRS ue, which may be different from the box Address of the invitee. Hash _ Password _ PCRS _ P2P refers to a Hash code used to communicate point-to-point with the PCRS, which is stored in the PCRS Client database (PCRS Client database), and the actual Hash code is never stored in the PCRS for security reasons. The passage _ PCRS _ P2P _ Expiration refers to the Expiration time of the Hash _ passage _ PCRS _ P2P. Status in PCRS Client database means that the PCRS Client records in-service, out-of-service or deleted state of the PCRS Client database.

In addition, other terms unrelated to the PCRS ue library include: the PCRS Address (Address _ PCRS), the PCRS Password (PassWord _ PCRS), the PCRS Client Password (PassWord _ PCRS _ Client), and the Virtual LAN subnet (Virtual LAN subnet). The definitions of these terms are as follows. Address _ PCRS and Passsword _ PCRS are message box accounts used to configure the PCRS, which are used only once during initialization and preparation of the PCRS, and are not stored for security purposes. Address _ PCRS _ Client and passed _ PCRS _ Client are message box accounts used to configure the PCRS Client, which are used only once during the creation of the PCRS Client in the database. Although the Address _ PCRS _ Client is stored in the repository, the Password _ PCRS _ Client is never stored for security purposes. Virtual LAN subnet refers to a subnet of a VPN that is configurable and modifiable for security purposes.

As shown in FIG. 2, the PCRS 208 includes a PCRS _ Utility 270, which in turn includes a PCRS Client database (PCRS Client database) 271 and a router server message box Utility272. The PCRS Client database 271 contains a registration list of the PCRS ue. The router server message box Utility272 may communicate with a callback server message box (not shown).

The administrator device 273 is an intelligent device client 207 that includes a PCRS application Utility (PCRS _ App) 274, which in turn includes a PCRS Server database (PCRS Server database) 275 and a client message box Utility 276. The PCRS Server database275 contains a registration list of PCRS. The client message box Utility 276 may communicate with the client message box 215.

The PCCBS device Client 201 is a smart device Client that includes a PCCBS application Utility (PCCBS _ App) 278, which includes a PCCBS Server database (PCCBS Server database) 279 and a Client Message Box Utility 280. The PCCBS Server database 279 contains a registration list of PCCBS. The Message Box Utility 280 may communicate with the client Message Box 215.

The Invitee Device 281 is an intelligent Device Client 221 that includes a Client Message Box utility 282. The client message box utility 282 may communicate with the client message box 215. As shown in FIG. 5, the system administrator uses a PCRS _ App 274 from administrator device 207 to initialize and prepare a PCRS 208. The administrator device 207 and the PCRS 208 are both located on the physical LAN 204, and are configured for security purposes to prevent hacking on the Internet or WAN. First, the system administrator configures the PCRS message box for authentication by setting the account name and password. Thereafter, the PCRS message box identity is transmitted to the PCRS Utility 270 in the PCRS 208.

The PCCBS 216 includes a PCCBS Utility 2700, which includes a PCCBS Client database (PCCBS Client database) 2710 and a Routing Server Message Box (Routing Server Message Box) 2720. The PCCBS Client database 2710 contains a registration list of PCCBS clients. The message box Utility 2720 may communicate with a callback server message box (not shown). As shown in FIG. 6, the system administrator 277 also creates a PCCBS client account using the PPCBS _ App 278. The system administrator 277 is a PCCBS Device client 201 that sets the invitee notification address in the PCCBS _ Device _ App (denoted as 605). The PCCBS is then requested to send a connection invitation to the callback server message box (not shown) through the callback server message box Utility 2720, through the client message box 215, and finally to the invitee device 281, the invitee device 281 being the client message box Utility 282. It is noted that both the callback server message box and the client message box 215 are hosted within the message box server. For example: an e-mail server, a web page server and a message server. In addition, the callback server box and the client box 215 may be the same or different logically. After the invitee receives the invitation (denoted 620), it retrieves the PCCBS _ Device _ App from the PPCBS _ App link (denoted 621) and installs 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 necessary. The system administrator must know the message box address of the invitee (labeled 605) to issue the invitation.

As shown in fig. 7, on the intended PCCBS Device client 201, the invitee starts the PCCBS _ Device _ App (denoted as 700) and registers to the PCCBS (denoted as 701). The role of the invitee is now modified to be a PCCBS client on the PCCBS device client 201. The PCCBS ue configures the authentication of its ue message box by setting the account name and password, and registers the authentication with the ue message box 215. The previously received Address _ PCCBS and Access _ Code are then retrieved from invitee device 281 and sent to the PCCBS (710) via 740 with the Client message account Address _ PCCBS _ Client. After verification through PCCBS Utility 2700 within PCCBS 216, a set of point-to-point connection IDs 714 is generated that contains Passsword _ PCCBS _ P2P. The actual password is sent to the invitee device 281 through the client message box 215. The hashed password and the authentication of other clients are stored in the PCCBS Client database. For security reasons, the actual customer-side point-to-point password is never stored in the PCCBS 216. However, the hash value is stored for comparison in authentication 716. Once the PCCBS Device client 201 receives its confirmation of registration 707 from the PCCBS 216, the Address _ PCCBS of the PCCBS is recorded in the PCCBS server database (PCCBS server database) 279 in the PCCBS _ Device _ App 278.

As shown in fig. 6, 9, and 10, the PCCBS _ Device _ App provides the following four instructions to the administrator Device: initialization and provisioning (initialization and provisioning), creating a Client (Create a Client), viewing PCCBS Client (View PCCBS Client), and resetting PCCBS Point-to-Point Password/Edit Attributes (Reset PCCBS P2P Password/Edit Attributes). Whenever an administrator operates, access to the PCCBS is only allowed from the PCCBS virtual local area network (physical or virtual) for security reasons. Due to the limitation of access, the setting and configuration of the PCCBS are only carried out on the PCCBS virtual local area network, so as to avoid the monitoring and hacker attack of network traffic.

As shown in fig. 7, 8 and 11, the PCCBS _ Device _ App provides the following three commands to the PCCBS ue: "Register to PCCBS (Register to a PCCBS)," modified Point-to-Point Password (Change P2P Password), "and" Connect to PCCBS "(Connect to PCCBS). As shown in FIG. 7, with respect to the registration being a PCCBS (Register to a PCCBS) command, the PCCBS client may run the PCCBS _ Device _ App and connect to the PCCBS Utility from the WAN or PCCBS virtual network because the communication exchange between the PCCBS client and the PCCBS Utility for Register to a PCCBS is through the client message box 215 and the callback server message box (not shown). As shown in fig. 11, in the "modify peer-to-peer Password (Change P2P Password)" command, after the wan securely connects to the VPN, the PCCBS Device client must run the PCCBS _ Device _ App on the PCCBS virtual network for security reasons, because the peer-to-peer Password can only be reset on the PCCBS virtual network. The only way PCCBS device clients connect to the PCCBS virtual network is through a secure VPN. As shown in FIG. 8, with respect to the Connect to private cloud callback server (Connect to PCCBS) command, the PCCBS device client has not yet connected to the PCCBS from the WAN or PCCBS virtual network. A secure and private connection between a PCCBS Device client and the PCCBS is a condition of the command when running the PCCBS _ Device _ App. The PCCBS 216 acts as a man-in-the-middle relay for communication between the

smart device clients

201, 211, 221 and the PCRS 218. It will call back the PCRS according to the requirements of the intelligent device user side.

Fig. 3 illustrates a second embodiment of the present invention. Similar to the method disclosed in fig. 2, that is, the PCRS 208 is connected to the Router of the local area network (Router _ P) 202, wherein the PCRS 308 is connected to the Router of the local area network (Router _ P) 302. The PCRS 308 may also be connected to a downstream physical virtual network 360. A private network service 336 and an intelligent device client 335 are connected downstream. Private network services 336 are accessible over communication path 326 and are connected to the PCRS 308 through the LAN 334. As long as the PCCBS316 is passed, the virtual LAN network 340, the physical LAN networks 350, 360 can be explored and accessed across the cloud by the

smart device clients

311, 309, 301, 321, 306, 335, and the PCRS 308, the

private network services

328, 336, and the

smart device clients

306, 335 become accessible.

Fig. 3 illustrates a third embodiment of the present invention. The PCRS 408 is connected to the cloud and has a public IP (public _ IP _ P) 417. The PCRS 408 is also connected to a downstream physical area network 460. A private network service 436 and an intelligent device client 435 are connected in the downstream. Private network services 436 are accessible via communication path 426 and are connected to the PCRS 408 via a local area network 434. As long as the PCCBS416 is passed, the virtual LAN network 440, the physical LAN networks 450, 460 are all accessible and cloud-wide to the

smart device clients

411, 410, 409, 401, 421, 435, and the PCRS 408, the private network services 436, and the smart device client 435 are all accessible.

FIG. 5 illustrates a flow diagram for initiating and preparing communications via a PCRS administrator in accordance with the invention. As shown in fig. 5, from the perspective of a PCRS administrator Device (PCRS Admin Device), the PCRS administrator Device is connected to a PCRS network on a local area network at step 500. In step 501, a PCRS _ Device _ App is turned on in a PCRS area network. At step 502, a PCRS Address _ PCRS on the LAN is detected and selected. At step 503, an "Initialize and prepare (initialization and provisioning) instruction on the PCRS _ Device _ App is selected. In step 504, address _ PCRS and Password (Password _ PCRS) are set as PCRS identities. At step 505, the PCRS is logged in using the administrator's authentication (Initialize and Provision, admin _ name, admin _ Password, address _ PCRS, passWord _ PCRS). At step 540, the identity verification is transmitted to the PCRS Utility (denoted as 510). At step 506, the administrator waits for a PCRS authentication. In step 507, the sub-network and PCRS App link of the virtual local area network are configured. At step 542, a PCRS Utility (labeled 514) is transmitted. In step 508, the PCRS is used as a client to join the existing ap router, if needed. In step 543, this information is sent to the PCRS Utility (labeled 516).

At step 510, from the perspective of PCRS availability, the identity verification (Initialize and Provision, admin _ name, admin _ Password, address _ PCRS, passsword _ PCRS) of the PCRS administrator (PCRS Admin) is accepted. In step 511, the administrator's authentication is verified (Admin _ name, admin _ password). At step 541, the identity verification (Address _ PCRS, passsword _ PCRS) is transmitted to an administrator device (denoted 506). At step 512, the identity verification (Address _ PCRS, passsword _ PCRS) is stored as the identity of the PCRS. In step 513, the authentication (Address _ PCRS, password _ PCRS) is registered to the router server message box. In step 514, the subnet routes and PCRS App link of the virtual local area network are stored. At step 515, a PCRS _ Profile file is generated and saved, including the interface protocol, the certificate, and the key. In step 516, the existing ap router is added as a client, if necessary.

FIG. 6 illustrates a flow chart for establishing a client-side communication for PCCBS via a PCRS Admin manager in accordance with the present invention. From the perspective of the PCRS administrator Device 201 (PCCBS Admin Device 201), first, at step 600, the PCCBS _ Device _ App is turned on in the wide area network. At step 601, PCCBS 216 at Address _ PCCBS is detected and selected. In step 602, a Create a Client command on the PCCBS _ Device _ App is selected. In step 603, the Address _ invite of the Invitee notification is set. At step 604, the PCCBS 216 is logged in using the administrator's authentication (Create a Client, admin _ name, admin _ password, address _ Invite). At step 640, the identity verification is sent to the PCCBS _ Device Utility. At step 605, the system administrator 277 waits for the PCCBS to verify.

At step 610, from the perspective of the PCCBS device Utility, the PCCBS administrator (PCCBS Admin) is first accepted for authentication (Create a Client, admin _ name, admin _ password, address _ invite). In step 611, the administrator's authentication is verified (Admin _ name, admin _ password). At step 641, the authentication is transmitted to an administrator device. In step 612, access _ Code is generated, and its Code _ Expiration is generated. In step 613, the Access _ Code, code _ Expiration, and Address _ invite are stored in the entries (Access _ Code, code _ Expiration, address _ invite, address _ PCCBS _ Device _ Client, hash _ transmitted _ PCCBS _ Device _ P2P, transmitted _ PCCBS _ Device _ P2P _ Expiration, status) of the PCCBS Device Client database (PCCBS _ Device Client database). In step 614, an invite is sent to the Invitee notification Address _ invite, which includes PCCBS _ Device application link, address _ PCCBS _ Device, access _ Code, and Code _ Expiration. At step 642, delivery is made to the invitee (labeled 620).

From the perspective of the Invitee Device (invite Device), at step 620, an invitation for Address _ invite, PCCBS _ Device app link, address _ PCCBS _ Device, access _ Code, and Code _ Expiration is accepted. At step 621, the PCCBS _ Device _ App is retrieved from the PCCBS _ Device App link. At step 622, the PCCBS _ Device _ App is installed on the PCCBS

Device user side

201, 209, 210 or 211.

Fig. 7 illustrates a flow chart of communication for registering a PCCBS Device Client (PCCBS Device Client) to a PCCBS according to the present invention. From the perspective of the PCCBS Device client, at step 700, a PCCBS _ Device _ App is launched in a WAN or PCRS LAN. In step 701, if necessary, an Address _ PCCBS _ Device _ Client (not shown) of the PCCBS Device Client is created, and then a Register a Private clock Call-Back Server command on the PCCBS _ Device _ App is selected. In step 702, if the PCCBS Device ue is not configured, address _ PCCBS _ Device _ Client and Password _ PCCBS _ Device _ Client are set. In addition, in step 702, the access _ PCCBS _ Device _ p2p is a box Password associated with the Address of the box (not shown) of the Client for the Address _ PCCBS _ Device _ Client for peer-to-peer communication, and the Address _ PCCBS _ Device _ Client and the access _ PCCBS _ Device _ Client are registered to the Client box. In step 703, address _ PCCBS _ Device and Access _ Code are retrieved from the invitee. The information is initially received by the invitee device (denoted as 620).

Then, in step 704, the Address _ PCCBS _ Device, the Access _ Code and the Client id (Register a Private clock Call-Back Server, address _ PCCBS _ Device _ Client, access _ Code) are transmitted to the PCCBS through the Client message box. At step 740, the Address _ PCCBS _ Device and the Access _ Code are transmitted to the PCCBS Device (denoted as 710). In step 705, the PCCBS device client waits for PCCBS authentication through the client message box. At step 706, the PCCBS device client waits for confirmation of completion of the PCCBS registration through the client message box. In step 707, if it is a new entry, the Address _ PCCBS _ Device entry in the PCCBS Device Server database (PCCBS _ Device Server database) is registered with the PCCBS _ Device _ App.

At step 710, from the perspective of PCCBS _ Device Utility, the identity verification (Register a Private Cloud Call-Back Server, address _ PCCBS _ Device _ Client, and Access _ Code) of the PCCBS Device Client is accepted. In step 711, a verification is performed to check whether the Address _ PCCBS _ Device _ Client is in the PCCBS Device Client database (PCCBS _ Device Client database). If yes, the Address _ PCCBS _ Device _ Client and the Address _ PCCBS _ Device specified by the invitee are confirmed (denoted 719) and then returned. If not, the Access _ Code is verified (denoted as 712); in step 713, the Code _ exception on the Access _codeis verified in the PCCBS _ Device Client database. At step 741, the Code _ exception on the access \ucode is transmitted to the PCCBS device client (denoted as 705). In step 714, pass _ PCCBS _ Device _ P2P _ exception, and Status are generated, along with the associated Access _ Code, code _ exception, address _ invite, and Address _ PCCBS _ Device _ Client. At step 715, the Hash value of Password _pccbs _device _p2P is saved as Hash _ Password _ PCCBS _ Device _ P2P. In step 716, the Address _ PCCBS _ Device _ Client, the Hash _ passage _ PCCBS _ Device _ P2P, the passage _ PCCBS _ Device _ P2P _ exception, and the Status are stored in the entries (Access _ Code, code _ exception, address _ invoke, address _ PCCBS _ Device _ Client, hash _ passage _ PCCBS _ Device _ P2P _ exception, and Status) of the PCCBS _ Device database. In step 717, the Password _ PCCBS _ Device _ P2P is transmitted to the Invitee notification Address _ invite. At step 743, the passed PCCBS Device P2P is transmitted to the invitee (denoted 720); at step 718, the passed PCCBS Device P2P is cleared. In step 719, the Address of the PCCBS Device Client (Address _ PCCBS _ Device _ Client) and the Address of the PCCBS Device Client (Address _ PCCBS _ Device) specified by the invitee are confirmed. In step 744, the address of the PCCBS device client specified by the invitee is transmitted to the PCCBS device client (denoted 706); at step 720, the Passsword _ PCCBS _ Device _ P2P is accepted from the perspective of the invitee Device and saved for future use.

Figure 8 illustrates a flow diagram of communications for a PCCBS device client to connect to a PCCBS in accordance with the present invention. From the perspective of the PCCBS device client, at step 800, the PCCBS _ VPN _ App is turned on in the WAN. In step 801, an Address _ PCCBS _ VPN is selected from the registered PCCBS VPN database (PCCBS _ VPN database). In step 802, a 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 transmitted to the Address _ PCCBS _ VPN. At step 840, the point-to-point connection request is transmitted to the PCCBS _ VPN Utility (labeled 810). In step 804, the peer-to-peer negotiation initiates communication with the PCCBS _ VPN located in the Address _ PCCBS _ VPN using the Address _ PCCBS _ VPN _ Client. At step 841, the PCCBS device subscriber communicates with a PCCBS _ VPN Utility (denoted as 811). At step 805, the PCCBS _ VPN _ Profile file is accepted to initiate an intelligent VPN connection with the PCCBS _ VPN at Address _ PCCBS _ VPN. At step 806, a point-to-point connection between the PCCBS _ VPN and the device user side is established. At step 843, the PCCBS device client communicates with a PCCBS _ VPN Utility (labeled 813). In step 807, login to PCCBS _ VPN using authentication of the user side (Connect to PCCBS _ VPN, address _ PCCBS _ VPN _ Client, and passed _ PCCBS _ VPN _ P2P). At step 844, the identity verification of the customer premises is sent to the PCCBS _ VPN Utility (labeled 814). At step 808, the pccbs device user side waits for authentication. At step 809, secure peer-to-peer communication is initiated. At step 846, the PCCBS device user side communicates with the PCCBS _ VPN Utility (labeled 817). At step 820, the PCCBS device client securely connects to the virtual private LAN located in the PCCBS _ VPN.

From the perspective of PCCBS _ VPN Utility, a point-to-point connection request from Address _ PCCBS _ VPN _ Client is accepted at step 810. In step 811, the peer-to-peer negotiation begins to communicate with the PCCBS _ VPN Client located in the Address _ PCCBS _ VPN _ Client using Address _ PCCBS _ VPN. At step 841, PCCBS _VPNutility communicates with the PCCBS device user end (labeled 804). At step 812, the PCCBS _ VPN _ Profile file is transferred to the Address _ PCCBS _ VPN _ Client to initiate the intelligent VPN connection. At step 842, the PCCBS _ VPN _ Profile file is transmitted to the PCCBS device client (denoted as 805). In step 813, a point-to-point connection between the PCCBS _ VPN and the device user side is established. At step 843, PCCBS _VPNutility communicates with the PCCBS device user side (denoted 806). In step 814, the PCCBS _ VPN Client is authenticated (Connect to PCCBS _ VPN, address _ PCCBS _ VPN _ Client, and passed _ PCCBS _ VPN _ P2P). In step 815, the entry list of Address _ PCCBS _ VPN _ Client (Access _ Code, code _ Expiration, address _ update, address _ PCCBS _ VPN _ Client, hash _ payload _ PCCBS _ VPN _ P2P, payload _ PCCBS _ VPN _ P2P _ Expiration, and Status) based on the PCCBS VPN Client database (PCCBS _ VPN Client database) is retrieved. In step 816, the existing point-to-point (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 PCCBS _ VPN Client database. At step 845, the existing point-to-point (P2P) password is transmitted to the PCCBS device user side (denoted as 808). In step 817, secure peer-to-peer communication is initiated. At step 846, PCCBS _VPNutility communicates with the PCCBS device client (labeled 809). In step 818, PCCBS _VPNUtility calls back to the PCRS and initiates point-to-point communication with the PCRS. At step 847, the PCCBS device client securely connects to the virtual private LAN over the PCRS (denoted 820). In step 819, the PCCBS _vpnutility establishes a point-to-point communication channel between the PCCBS device client and either the PCCBS device client or another PCCBS device client. At step 848, the PCCBS device subscriber starts to connect to the PCRS device subscriber or another PCCBS device subscriber (labeled 821).

FIG. 9 illustrates a flow diagram for a PCCBS administrator viewing communications at a client of the PCCBS in accordance with the present invention. From the perspective of the administrator Device, the PCCBS _ Device _ App is turned on in step 900 over the wide area network. In step 901, an Address _ PCCBS _ Device is selected from the registered PCCBS Device database (PCCBS _ Device database). In step 902, a View private cloud callback server Device Client command is selected on the PCCBS _ Device _ App. In step 903, a lookup entry in the PCCBS Device Client database (PCCBS _ Device Client database) is selected as a lookup index. At step 904, the PCCBS is logged in using the administrator's authentication (View PCCBS _ Device Client, admin _ name, admin _ password, and View entry). At step 940, the identity verification is transmitted to the PCCBS _ Device Utility (labeled 910). At step 905, the administrator device waits for PCCBS authentication. In step 906, an entry list (Access _ Code, code _ Expiration, address _ invite, address _ PCCBS _ Device _ Client, hash _ passed _ PCCBS _ Device _ P2P, pass _ PCCBS _ Device _ P2P _ Expiration, and Status) of the PCCBS _ Device database is displayed based on the reference index.

At step 910, from the perspective of the PCCBS _ Device Utility, the identity verification of the PCCBS _ Device Client (View PCCBS _ Device Client, admin _ name, admin _ password, and View entry) is accepted. At step 911, the administrator's authentication (Admin _ name, admin _ password) is verified. At step 941, the administrator's authentication is transmitted to an administrator device (labeled 905). In step 912, the view item is used as the reference index to reply from the item list (Access _ Code, code _ Expiration, address _ invite, address _ PCCBS _ Device _ Client, hash _ Password _ PCCBS _ Device _ P2P, password _ PCCBS _ Device _ P2P _ Expiration, and Status) of PCCBS _ Device Client database based on the reference index. At step 942, the reply is transmitted to the administrator device (labeled 906).

FIG. 10 illustrates a flow diagram of the communication of a PCCBS administrator to reset point-to-point passwords and edit attributes for a PCCBS device client in accordance with the present invention. From the perspective of the administrator Device, the PCCBS _ Device _ App is turned on in step 1000 over the WAN. In step 1001, an Address _ PCCBS _ Device is selected from the registered PCCBS Device database (PCCBS _ Device database). In step 1002, a "Reset P2P Password" or "Edit Attributes (Edit Attributes)" command is selected at PCCBS _ Device _ App. In step 1003, an Invitee notification Address _ invite is input as a reference index. At step 1004, the PCCBS is logged in using the administrator's authentication (Reset P2P passage/Edit Attributes, admin _ name, admin _ Password, and Address _ Invite). At step 1040, the administrator's identity verification is transmitted to the PCCBS _ Device Utility (denoted 1010). At step 1005, the administrator device waits for PCCBS device authentication. In step 1006, an Address _ invite display item list (Access _ Code, code _ exception, address _ invite, address _ PCCBS _ Device _ Client, hash _ Password _ PCCBS _ Device _ P2P, password _ PCCBS _ Device _ P2P _ exception, status) based on the PCCBS Device Client database (PCCBS _ Device database) is displayed. At step 1007, if the "reset point-to-point password" command is selected, the administrator device waits for completion. At step 1008, if the "edit property" command is selected, the properties are edited as needed. The attributes include, but are not limited to, the status of the PCCBS device client (Active, inactive, deleted), the subnet of the virtual area network, and the PPCBS _ App link. At step 1044, the attributes are transferred to the PCCBS _ Device Utility (denoted as 1017).

From the perspective of PCCBS _ Device availability, at step 1010, the PCCBS administrator's identity verification (P2P passed/edit attribute, admin _ name, admin _ Password, and Address _ invite) is accepted. At step 1011, the administrator's authentication (Admin _ name, admin _ password) is verified. At step 1041, the identity verification of the PCCBS administrator is transmitted to an administrator device (denoted 1005). In step 1012, the Address _ Invite is used as the reference index to reply based on the entry list (Access _ Code, code _ exception, address _ Invite, address _ PCCBS _ Device _ Client, hash _ pass _ PCCBS _ Device _ P2P, pass _ PCCBS _ Device _ P2P _ exception, and Status) of the Address _ Invite in the PCCBS _ Device Client database. At step 1042, the reply is transmitted to the PCCBS _ Device Utility (labeled 1006). At step 1013, if the reset point-to-point password command is selected. In step 1014, a new Password PCCBS Device P2P is generated and the Hash value of the Password PCCBS Device P2P at the Hash PCCBS P2P is saved. In step 1043, the new Password _ PCCBS _ Device _ P2P is transmitted to an administrator Device (denoted as 1007). In step 1015, the Access _ Code and the passage _ PCCBS _ Device _ P2P are transmitted to the Invitee notification Address _ invite, and the passage _ PCCBS _ Device _ P2P is cleared. In step 1045, access _ Code, passed _ PCCBS _ Device _ P2P is transmitted to the invitee (denoted 1020). At 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 Device, at step 1020, the Invitee notification Address, address _ Invite, accepts the Access _ Code and the Passsword _ PCCBS _ Device _ P2P.

Fig. 11 illustrates a flow chart of communication for modifying a point-to-point password of a 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 in the WAN. In step 1101, an Address _ PCCBS _ Device is selected from the registered PCCBS Device database (PCCBS _ Device database). In step 1102, a "modify point-to-point Password (Change P2P Password)" command is selected at PCCBS _ Device _ App. In step 1103, the PCCBS is registered using the identity authentication of the ue (Change P2P Password, address _ PCCBS _ Device _ Client, and Password _ PCCBS _ Device _ P2P). At step 1140, the identity verification of the ue is transmitted to the PCCBS _ Device Utility (denoted 1110). At step 1104, the PCCBS device client waits for the PCCBS device authentication. At step 1105, a new point-to-point password is entered and re-entered until they match. At step 1142, the new password is transmitted to the PCCBS _ Device Utility (denoted 1113).

From the perspective of PCCBS _ Device availability, at step 1110, identity verification (Change P2P pass, address _ PCCBS _ Device _ Client, and pass _ PCCBS _ Device _ P2P) of the PCCBS Device Client is accepted. In step 1111, retrieve the Hash _ pass _ PCCBS _ Device _ P2P entry 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 _ pass _ PCCBS _ Device _ P2P entry (Access _ Code, code _ Expiration, address _ invite, address _ PCCBS _ Device _ Client, hash _ pass _ PCCBS _ Device _ P2P, and Status) of the Address _ PCCBS _ Device _ Client based on the PCCBS _ Device database. At step 1141, the existing point-to-point password is transmitted to the PCCBS Device Client (denoted 1104). At step 1113, the new peer-to-peer Password _ PCCBS _ Device _ P2P is accepted. In step 1114, the new point-to-point Password is hashed to Hash _ passed _ PCCBS _ Device _ P2P. In step 1115, update Hash _ payload _ PCCBS _ Device _ P2P based on the Address _ PCCBS _ Device _ Client (Access _ Code, code _ Expiration, address _ invite, address _ PCCBS _ Device _ Client, hash _ payload _ PCCBS _ Device _ P2P, payload _ PCCBS _ Device _ P2P _ Expiration, and Status) of the PCCBS _ Device Client database. And clearing the point-to-point Password Passsword _ PCCBS _ Device _ P2P.

Fig. 12 illustrates a flow chart of communication between a Device Client1 and a Device Client2 via a cloud internet (prior art) peer-to-peer connection mechanism. The device client1 and the device client2 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 Client 1App (1201) uses its performance in the Transmission Control Protocol (TCP)/User data packet Protocol (UDP) IP address and port to register to the Public VPN Routing Server Utility (1200), and the Device Client 1App, IP address and port remain active with the Routing Server (1203). Next, the application (Device Client1 App) (1201) of the Device Client1 requests the Public VPN Routing Server Utility 1200 to connect to the Device Client2 (1204); public VPN Routing Server Utility (denoted 1200) informs device client2 of the device client1 capabilities and its connection intention at the IP address and communication port of the TCP/UDP protocol (denoted 1205); the Device Client2 application (Device Client2 App) (reference 1202) replies with its registration to a Public VPN Routing Server Utility (reference 1200), where the registration includes the IP address and capabilities of the communication port in the TCP/UDP protocol, and the IP address and capabilities of the communication port of the Device Client2 remain active (reference 1206) through a connection with the Public VPN Routing Server Utility (reference 1200); public VPN Routing Server Utility (denoted 1200) responds to device client1 (denoted 1207) with device client 2's capabilities at the IP address and communication port of the TCP/UDP protocol; after the Device Client1 receives the IP address and the performance of the communication port of the Device Client2 under the TCP/UDP protocol, a Device Client 1App (marked as 1201) starts to puncture through the firewall of the Device Client2 (marked as 1208); the Device Client2 App (denoted 1202) also starts puncturing (denoted 1209) through the firewall of the Device Client 1; finally, both sides of the firewall are punctured and point-to-point communication is initiated between device client1 and device client2 (labeled 1210). It should be noted that without the Public VPN Routing Server, it is impossible to have a Routing Server Utility and a connection mechanism between the device ue 1 or the device ue 2, and the basic flow of the connection mechanism must depend on the Public VPN Routing Server.

FIG. 13 illustrates a flow diagram of the communication of a point-to-point connection mechanism between PCRS and PCCBS over a cloud-based Internet (prior art). As shown in fig. 13, the device client through the cloud network according to the present invention does not need a Public VPN Routing Server (Public VPN Routing Server) to connect and access to another equipment client or network service under the Server. The PCCBS on the device client1 and 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 Client 1App (denoted 1301) requests connection to the PCRS Utility (server part) (denoted 1300) through the Client message box 215, and as shown in fig. 8, the PCRS Utility has the capability of IP address and port communication in the TCP/UDP protocol. PCRS Device Client 1App, IP address and port and PCRS Utility remain active (denoted 1303); the PCRS Utility receives registration (not shown) by calling back to the Server message Box; the PCRS device client1 requests a PCRS Utility (server part) to connect to a PCRS Utility (client part) (designated 1304) via the client message box 215; the PCRS availability 1300 receives the request via a callback server message box (not shown), indicated by 1305, and informs the PCRS availability (client part), indicated by 1302, of the capability of the PCRS device client1 at the IP address and communication port of the TCP/UDP protocol and its connection intention; the PCRS Utility (client part) (designated 1302) replies with its registration, designated 1300, including the IP address of the TCP/UDP protocol and the capabilities of the communication port. The IP address and port capabilities of device client2 are kept active by connection to the PCRS Utility (designated 1300). The PCRS Utility (server part) (designated 1300) responds to the Device Client 1App (designated 1301) with the Device Client2 performance at the IP address and communication port of the TCP/UDP protocol by calling back the server message box (not shown). After receiving the PCRS availability (Client part) capability at the IP address and port of the TCP/UDP protocol via the Client message Box 215, the PCRS Device Client 1App (referenced 1301) initiates a puncture (referenced 1308) through the firewall of the PCRS availability (Client part). The PCRS Utility (Client part) (referenced 1302) also starts puncturing (referenced 1309) through the firewall of the PCRS Device Client 1; finally, both sides of the firewall are punctured and point-to-point communication is initiated between the PCRS Utility (subscriber premise) and the PCRS Utility (subscriber premise) (reference 1310). All information exchange between the PCRS Utility and the PCRS Device Client1 is through the callback server message box (not shown), rather than through a public routing server 212 or a public VPN routing server 214. The PCRS Device Client1 can securely connect to the virtual private area network on the PCRS, as shown in step 820. The PCRS Device Client1 can access any Device clients 206 or private network services 228 accessible under the PCRS. As shown in fig. 13, other PCRS Device Client1 (not 201, 221, 209, 210, and 211) can be connected to the PCRS through the same connection mechanism. Once any pair of PCRS Device Clients (PCRS devices Clients) and PCCBS Device Clients (PCCBS devices Clients) are connected to the PCRS and

PCCBS vpns

240, 2400, private and secure communications for text, voice and video can be made between each other.

Fig. 14 illustrates a flow diagram of a peer-to-peer connection mechanism communication between PCRS, PCCBS, PCRS Device Clients (PCRS devices Clients) and PCCBS Device Clients (PCCBS devices Clients) over a cloud-based 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 the PCCBS, another device client or another network service under a server. As shown in fig. 14, the PCRS on the device client1 and the cloud network can communicate with each other without going through a public routing server 112 or a public VPN routing server 114. As shown in fig. 5 and reference numeral 0 (reference numeral 1400) of fig. 14, a PCCBS administrator Device (reference numeral 1420) first initializes and prepares a PCCBS (reference numeral 1428) with a PCRS Device Utility (reference numeral 1421). Thereafter, the PCRS Utility (indicated at 1421) transmits messages internal to the PCCBS (indicated at 1428) to the PCRS _ VPN Utility (indicated at 1422). Next, referring to reference numeral 1 (designated 1401) of FIG. 14 and FIG. 15, a PCCBS registration message is registered with the PCCBS VPN Utility (designated 1423), which includes the IP address and the capabilities of the communication port in the TCP/UDP protocol. As shown in fig. 16, a PCCBS Tuple (Tuple) and a Communication Socket (designated 1600) are also established. The IP address of the device client2 and the performance of the communication port remain active through the connection to the PCCBS Utility (labeled 1401). After registration, the PCRS _ VPN Utility is connected to the PCCBS _ VPN (designated 1602), and a point-to-point communication channel is established between the PCRS _ VPN and the PCCBS _ VPN (designated 1619). The PCCBS _ VPN Utility (designated 1423) communicates with the PCCBS _ Device Utility (designated 1424) via messages internal to the PCCBS (designated 1427). Referring to reference numeral 2 (labeled 1402) of fig. 14, the PCCBS _ Device Utility remains in a loop and waits for requests from the PCCBS Device clients. As shown in FIG. 7, first, the PCCBS Device Client1 (reference numeral 1405) uses the capability of IP address and communication port in TCP/UDP protocol to register to the PCCBS _ Device availability (reference numeral 1424); with the PCCBS _ Device availability (labeled 1424), the PCCBS Device Client1, IP address, and communication port remain active (see reference number 3-1 (labeled 1403) of fig. 7 and 14). The PCCBS _ Device Utility (designated 1424) communicates registration and connection requests internal to The PCCBS (designated 1427) to The PCCBS _ VPN Utility (designated 1423). As shown in fig. 8, after registration, the PCCBS Device Client1 (1425) connects to the PCCBS _ VPN (please refer to step 802 in fig. 8), and a peer-to-peer communication channel is established between the PCCBS Device Client1 (1424) and the PCCBS _ VPN (please refer to 817 in fig. 8). Referring to code number 5 (designated 1405) and code number 7 (designated 1407) of FIG. 14 and step 818 of FIG. 8, the PCCBS _VPNUtility (designated 1423) calls back to the PCRS _ VPN Utility (designated 1422) to establish a point-to-point communication channel between the PCCBS _ VPN Utility (designated 1423) and the PCRS _ VPN Utility (designated 1422). After the call back from PCCBS _ VPN Utility (1423) to PCRS _ VPN Utility (1422) is successful, a point-to-point communication channel is finally established between PCCBS _ Device Client1 and PCRS _ VPN to connect to PCRS Device Client2 (1426) or another PCCBS Device Client3 (PCCBS Device Client 3) (1423), assuming that PCCBS Device Client3 is also successfully connected to PCCBS _ VPN Utility (1423). Figure 17 illustrates the call back action from PCCBS _ VPN Utility to PCRS _ VPN (see step 818 of figure 8).

Fig. 15 illustrates a flow chart of the communication of PCRS registration to PCCBS according to the present invention. From the perspective of the PCRS, at step 1500, a PCCBS tuple and communication interface is established. If necessary (not shown), a PCCBS Device Client Address (Address _ PCCBS _ Device _ Client) is created. Next, in step 1501, a Register a Private Cloud Call-Back Server instruction is issued. In step 1502, if the PCCBS _ Device Client is not configured, then Address _ PCCBS _ Device _ Client and passed _ PCCBS _ Device _ Client are configured. Wherein the pass _ PCCBS _ Device _ P2P is a box Password associated with the Address of the message box (not shown) of the ue, and the box Address is used for the peer-to-peer communication of Address _ PCCBS _ Device _ Client. In step 1502, the address _PCCBS _ Device _ Client and the Passsword _ PCCBS _ Device _ Client are registered to the Client message Box. In step 1503, address _ PCCBS _ Device and Access _ Code are retrieved from the invitee. The information is initially received via invitee device 620.

In step 1504, the Address _ PCCBS _ Device, the Access _ Code, and the Client id (Register a Private Cloud Call-Back Server, address _ PCCBS _ Device _ Client, and Access _ Code) are transmitted to the PCCBS through the Client message box. In step 1540, the Address _ PCCBS _ Device and Access _ Code are transmitted to the PCCBS (designated 1510). At step 1505, the PCRS waits for authentication of the PCCBS through a customer premises cartridge. At step 1506, the PCRS waits for registration completion acknowledgement of the PCCBS through the customer premises box. At step 1507, if the entry is new, the Address _ PCCBS _ Device entry in the PCCBS Device Server database (PCCBS _ Device Server database) is registered with the PCCBS _ Device _ App.

From the perspective of PCCBS _ Device Utility, at step 1510, the identity verification (Register a Private Cloud Call-Back Server, address _ PCCBS _ Device _ Client, and Access _ Code) of the PCCBS Device Client (PCCBS _ Device Client) is received. In step 1512, a verification is performed to check whether Address _ PCCBS _ Device _ Client is in the PCCBS Device Client database (PCCBS _ Device Client database). If so, the Address of the invitee-specified PCCBS Device Client (Address _ PCCBS _ Device _ Client) and PCCBS Device Address (Address _ PCCBS _ Device) are confirmed (indicated by 1519) and returned. If not, the Access _ Code is verified (denoted as 1512); in step 1513, the Code _ extension on the Access _codeis verified in the PCCBS _ Device Client database. At 1541, the Code _ extension on the access _codeis transmitted to the PCCBS device client (denoted as 1505). In step 1514, pass _ PCCBS _ Device _ P2P _ exception, and Status are generated along with the associated Access _ Code, code _ exception, address _ invite, and Address _ PCCBS _ Device _ Client. In step 1515, the Hash value of the Password PCCBS Device P2P is saved as Hash _ Password PCCBS Device P2P. In step 1516, the Address _ PCCBS _ Device _ Client, the Hash _ passage _ PCCBS _ Device _ P2P, the passage _ PCCBS _ Device _ P2P _ exception, and the Status are stored in the entry of the PCCBS _ Device database (Access _ Code, code _ exception, address _ invoke, address _ PCCBS _ Device _ Client, hash _ passage _ PCCBS _ Device _ P2P _ exception, and Status). In step 1517, the passed _ PCCBS _ Device _ P2P is sent to the PCRS box. At step 1518, the passed PCCBS Device P2P is cleared. In step 1519, the Address of the PCCBS Device Client (Address _ PCCBS _ Device _ Client) and the Address of the PCCBS Device Client (Address _ PCCBS _ Device) specified by the invitee are confirmed. At 1544, the address of the invitee-specified PCCBS device client is transmitted to the PCCBS device client (labeled 1506). At step 1520, the Passsword _ PCCBS _ Device _ P2P is accepted from the perspective of the invitee Device and saved for future use.

FIG. 16 illustrates a flow chart of communication of a PCRS to a PCCBS in accordance with the present invention. From the perspective of the PCRS, at step 1600, a PCCBS tuple and communication interface is established. In step 1601, an Address _ PCCBS _ VPN is selected from the registered PCCBS VPN database (PCCBS _ VPN database). In step 1602, the Connect to PCCBS _ VPN (Connect to PCCBS _ VPN) command is selected at PCCBS _ VPN _ App. At step 1603, the point-to-point connection request is transmitted to Address _ PCCBS _ VPN. At step 1640, a point-to-point connection request is transmitted to the PCCBS _ VPN Utility (labeled 1610). The point-to-point negotiation starts to use Address _ PCCBS _ VPN _ Client to communicate with PCCBS _ VPN located in Address _ PCCBS _ VPN. At step 1641, the PCCBS _VPNcommunicates with the PCCBS _ VPN Utility (labeled 1611). At step 1605, the PCCBS _ VPN _ Profile file is accepted to initiate an intelligent VPN connection with the PCCBS _ VPN at Address _ PCCBS _ VPN. In step 1606, a point-to-point connection between the PCCBS _ VPN and the device user side is established. In step 1643, the PCCBS _VPNcommunicates with the PCCBS _ VPN Utility (labeled 1613). In step 1607, login is performed to the PCCBS _ VPN using the authentication of the user end (Connect to PCCBS _ VPN, address _ PCCBS _ VPN _ Client, and pass _ PCCBS _ VPN _ P2P). At step 1644, the identity verification of the customer premises is sent to the PCCBS _ VPN Utility (denoted 1614). At step 1608, the PCCBS _VPNwaits for verification. At step 1609, secure peer-to-peer communication is initiated. In step 1646, the PCCBS _VPNcommunicates with the PCCBS _ VPN Utility (labeled 1617). At step 1620, the PCCBS _VPNsecurely connects to the virtual private area network at the PCCBS _ VPN.

From the perspective of PCCBS _ VPN Utility, a point-to-point connection request from Address _ PCCBS _ VPN _ Client is accepted, at step 1610. In step 1611, the peer-to-peer negotiation begins using Address _ PCCBS _ VPN to communicate with the PCCBS _ VPN Client located at Address _ PCCBS _ VPN _ Client. In step 1641, PCCBS _VPNutility communicates with a PCRS _ VPN (labeled 1604). In step 1612, the PCCBS _ VPN _ Profile file is transferred to the Address _ PCCBS _ VPN _ Client to initiate the intelligent VPN connection. In step 1642, the PCCBS _ VPN _ Profile file is transferred to the PCRS _ VPN (denoted 1605). At step 1613, a point-to-point connection between the PCCBS _ VPN and the device user side is established. At step 1643, PCCBS _VPNutility communicates with PCCBS _ VPN (labeled 1606). At step 1614, the PCCBS _ VPN Client is authenticated (Connect to PCCBS _ VPN, address _ PCCBS _ VPN _ Client, and passed _ PCCBS _ VPN _ P2P). In step 1615, the entry list (Access _ Code, code _ exception, address _ invoke, address _ PCCBS _ VPN _ Client, hash _ pass _ PCCBS _ VPN _ P2P, pass _ PCCBS _ VPN _ P2P _ exception, and Status) of Address _ PCCBS _ VPN _ Client based on the PCCBS VPN Client database (PCCBS _ VPN database) is retrieved. At step 1616, the existing point-to-point (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 PCCBS _ VPN Client database. At step 1645, the existing point-to-point (P2P) cipher is transmitted to the PCRS _ VPN (denoted as 1608). At step 1617, secure peer-to-peer communication is initiated. In step 1646, PCCBS _VPNutility communicates with a PCRS _ VPN (labeled 1609). In step 1619, PCCBS _VPNutility establishes a point-to-point communication channel between the PCRS _ VPN and the PCCBS _ VPN. At step 1645, the PCRS _VPNbegins connecting to the PCCBS _ VPN (labeled 1621).

Figure 17 illustrates a flow chart of PCCBS callback-to-PCRS communication according to the present invention. From the perspective of PCCBS, at step 1700, a PCCBS tuple and communication interface is established. In step 1701, an Address _ PCRS _ VPN is selected from the registered PCRS VPN database (PCRS _ VPN database). In step 1702, a Connect to PCRS _ VPN command is selected at PCRS _ VPN _ App. In step 1703, the point-to-point connection request is transmitted to an Address _ PCRS _ VPN. At step 1740, a point-to-point connection request is communicated to the PCRS _ VPN Utility (labeled 1710). The point-to-point negotiation begins to use Address _ PCRS _ VPN _ Client to communicate with the PCRS _ VPN located in the Address _ PCRS _ VPN. In step 1741, the PCRS _VPNcommunicates with the PCRS _ VPN Utility (labeled 1711). At step 1705, the PCRS _ VPN _ Profile file is accepted to initiate an intelligent VPN connection with the PCRS _ VPN at Address _ PCRS _ VPN. In step 1706, a point-to-point connection between the PCRS _ VPN and the device user side is established. At step 1743, the PCRS \uVPN communicates with the PCRS _ VPN Utility (labeled 1713). At step 1707, the PCCBS _ VPN is logged in using the authentication (Connect to PCRS _ VPN, address _ PCRS _ VPN _ Client, and passed _ PCRS _ VPN _ P2P) of the user side. At step 1744, the identity verification of the user end is sent to the PCRS _ VPN Utility (denoted 1714). At step 1708, the PCRS _VPNwaits for verification. At step 1709, secure peer-to-peer communication is initiated. At step 1746, the PCRS _VPNcommunicates with the PCRS _ VPN Utility (labeled 1717). PCCBS _ VPN Utility establishes a point-to-point connection channel between PCRS _ VPN and PCCBS _ VPN (denoted 1719). 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, a point-to-point connection request from Address _ PCRS _ VPN _ Client is accepted at step 1710. In step 1711, the peer-to-peer negotiation begins using Address _ PCRS _ VPN to communicate with the PCRS _ VPN Client located in Address _ PCRS _ VPN _ Client. In step 1741, PCRS _VPNUtility communicates with a PCRS _ VPN (labeled 1704). In step 1712, the PCRBS _ VPN _ Profile file is transferred to Address _ PCRS _ VPN _ Client to initiate the intelligent VPN connection. At step 1742, the PCRS _ VPN _ Profile file is transferred to the PCRS _ VPN (denoted as 1705). In step 1713, a point-to-point connection between the PCRS _ VPN and the device user side is established. At step 1743, the PCRS _VPNUtility communicates with a PCRS _ VPN (labeled 1706). In step 1714, the PCRS _ VPN Client receives the authentication (Connect to PCRS _ VPN, address _ PCRS _ VPN _ Client, and passed _ PCRS _ VPN _ P2P). In step 1715, the entry list of Address _ PCRS _ VPN _ Client (Access _ Code, code _ Expiration, address _ update, address _ PCRS _ VPN _ Client, hash _ payload _ PCRS _ VPN _ P2P, payload _ PCRS _ VPN _ P2P _ Expiration, and Status) based on the PCCBS VPN Client database (PCRS _ VPN Client database) is retrieved. At step 1716, the existing point-to-point (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 PCRS _ VPN Client database. At step 1745, the existing point-to-point (P2P) password is transmitted to the PCRS _ VPN (denoted as 1708). At step 1717, secure peer-to-peer communication is initiated. In step 1746, PCCBS _VPNUtility communicates with a PCRS _ VPN (labeled 1709). PCCBS _ VPN Utility establishes a point-to-point communication channel between PCRS _ VPN and PCCBS _ VPN (denoted as 1709). In step 1748, the PCRS establishes a point-to-point connection channel (labeled 1721) between the PCCBS _ VPN Device Client and the PCRS Device Client or another PCCBS _ VPN Device Client.

FIG. 18 illustrates a flow diagram of the peer-to-peer connection mechanism for PCRS, PCCBS, PCRS device clients and PCCBS device clients through a cloud network based on server clusters, computer resource aggregation and virtual machines. In addition, fig. 18 is an extension of fig. 14 with the addition of server clusters 1830, computer resource aggregates 1831, and virtual machines 1832 to illustrate the implementation of the PCRS connection mechanism in a very large data center. The very large data center may have at least one server cluster 1830, at least one computer resource aggregation 1831, and at least one virtual machine 1832. The number and size of the at least one virtual machine is extensible. At least one of the very large data center or the service provider may construct a large number of independent PCCBS in a corresponding plurality of corresponding virtual machines to provide services to corresponding PCRS and PCRS device clients. In essence, a social pair of point-to-point communication relationships between the PCCBS device client and the PCRS device client is constructed and deployed through the network platform owner, which is responsible for maintaining the virtual machines in a topology with or without computer resource aggregation and server clusters. For example, one possible business model is a network platform owner that provides their private and secure PCCBS hosting of PCCBS to a large number of individual users in the virtual machines. Furthermore, the network platform owner also provides a separate private and secure PCRS for individual users to install the PCRS in their own local area network. By the invention, the platform user can establish the PCCBS device user terminal (such as a smart phone or a Tablet) and the PCRS device user terminal (such as a Notebook (NB), an Internet of things device, a Network Attached Storage (NAS) or a media server) from any place, and the PCCBS device user terminal and the PCRS device user terminal are erected on a private and safe local area Network of the user. FIG. 18 illustrates a device client connecting and accessing the PCRS, PCCBS, other device clients or web services through a cloud network under a server without a public cloud routing server in accordance with the techniques of the present invention. As shown in fig. 18, a PCCBS Device Client1 (PCCBS Device Client 1) 1825 and a PCRS on the cloud network can communicate with each other without going through a public routing server 112 (not shown) or a public VPN routing server 114 (not shown). The PCRS Utility (labeled 1821) transmits messages internal to the PCRS (labeled 1828) to the PCRS _ VPN Utility (labeled 1822). As shown in FIG. 15 and reference numeral 1 of FIG. 18, the PCRS _ VPN Utility (labeled 1822) registers with the PCCBS VPN Utility (labeled 1823) using a PCRS registration message that includes the capabilities of the IP address and communication port of the TCP/UDP protocol. As shown in fig. 16, the PCRS _ VPN Utility (labeled 1822) also establishes a PCCBS tuple and a communication interface (labeled 1600). The IP address of the device client2 (labeled 1826) and the performance of the communication port remain active through the connection with the PCCBS Utility (labeled 1801). After registration, the PCRS _ VPN Utility is connected to the PCCBS _ VPN (reference 1602), and a peer-to-peer communication channel is established between the PCRS _ VPN and the PCCBS _ VPN (reference 1619). The PCCBS _ VPN Utility (labeled 1823) communicates with the PCCBS _ Device Utility (labeled 1824) via messages internal to the PCCBS (labeled 1827). Referring to reference numeral 2 (designated 1802) of fig. 18, the PCCBS _ Device Utility remains in a loop and waits for requests by the PCCBS Device clients. As shown in fig. 7, first, the PCCBS Device Client1 (1805) uses the capability of IP address and communication port in TCP/UDP protocol to register with the PCCBS _ Device Utility (1824); with PCCBS _ Device Utility (labeled 1824), PCCBS Device Client1, IP address and communication port remain active (see fig. 7 and reference number 3-1 (labeled 1803) of fig. 14. The PCCBS _ Device Utility (labeled 1824) transmits registration and connection requests within The PCCBS (labeled 1827) to The PCCBS _ VPN Utility (labeled 1823). As shown in fig. 8, after registration, PCCBS Device Client1 (labeled 1825) connects to The PCCBS _ VPN (see step 802 of fig. 8) and establishes a communication channel between PCCBS Device Client1 (labeled 1824) and PCCBS _ VPN (see step 817 of fig. 8). See reference numbers 5 (labeled 1805) of fig. 18, 7 (labeled cnt 7) and step 1802, labeled PCCBS _ VPN) (labeled PCCBS _ VPN 1822) and PCRS 1822. After registration, the successful establishment of a communication channel between PCCBS Device Client1 (labeled PCCBS _ VPN) and PCCBS _ VPN (labeled 1822) is initiated by PCCBS _ VPN (labeled pccbrs call back to PCRS 1822).

While the present invention has been described in terms of the above embodiments, it will be readily apparent to those of ordinary skill in the art that many more modifications are possible in the embodiments without departing from the basic spirit of the invention. Accordingly, many modifications may be made to the embodiments of the invention by one of ordinary skill in the art without departing from the scope of the appended claims.

Claims

1. A method for use with a public cloud network, the method comprising:

setting at least one private cloud routing server, at least one private cloud callback server and at least one intelligent device user side in a user side server relationship;

wherein the at least one private cloud routing server comprises a first message box associated with the at least one private cloud routing server, the first message box being located in the public cloud network;

wherein the at least one smart device client comprises a second message box associated with the at least one smart device client, the second message box being located in the public cloud network; and

wherein the at least one private cloud callback server manages the first message box and the second message box on behalf of the public cloud network;

communicating a session message between said first message box and said second message box using a secure method;

wherein a secure session message connection mechanism hosted by the at least one private cloud callback server 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 private cloud routing server and the at least one private cloud callback server, creating a private cloud callback server client, viewing the private cloud callback server client, editing a private cloud callback server point-to-point password and a state of the private cloud callback server, modifying the private cloud callback server point-to-point password 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 session 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 session message being verified;

wherein the at least one smart device client securely accesses a private network service via the public cloud network based on the verified session message;

setting at least one private cloud callback server, wherein the at least one private cloud callback server and the 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 session message being verified;

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 intelligent device user side, wherein the at least one intelligent device user side and the at least one private cloud callback server are in a user side server relationship; and

setting at least one other intelligent device user side, the at least one other intelligent device user side and the at least one private cloud routing server being in a user side server relationship;

wherein the at least one smart device client and the at least another 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 session message being verified; and

wherein the at least one smart device client and the at least one other smart device client communicate with each other privately and securely over the public cloud network.

2. 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 executing instructions stored in a memory to cause the at least one private cloud callback server to:

creating and managing a list of authenticated clients to accommodate a plurality of smart device clients;

sending a session invitation to the second message box;

retrieving a session access request from the first message box at the at least one smart device client; and

sending a session acknowledgement to the second message box.

3. The method of claim 2, wherein the program further executes instructions stored in the memory to cause the at least one private cloud callback server to:

transmitting a communication request to the at least one smart device client;

transmitting 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;

enabling access to the at least one private web service from the at least one smart device client on the side of the at least one private cloud routing server;

calling back to the at least one private cloud routing server to connect to the at least one other smart device client according to the request of the smart device client, the at least one private cloud routing server being accessible to the at least one other smart device client in a VPN of the at least one private cloud routing server; and

enabling private and secure communications between the at least one smart device user side of the at least one private cloud callback server and the at least one other smart device user side of the at least one private cloud routing server.

4. 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;

wherein the router has a program that executes instructions stored in the memory to cause the at least one smart device client to:

retrieving a session invitation from the at least one smart device client message box;

transmitting 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;

transmitting a communication request to the at least one private cloud callback server;

transmitting 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 a new request from the at least one private cloud callback server to the at least one smart device client;

establishing a secure point-to-point communication with the at least one private cloud callback server;

accessing the at least one private network service through the at least one private cloud callback server; and

and communicating with at least one other intelligent device user side on one side of the at least one private cloud routing server through the at least one private cloud routing server.

5. The method of claim 2, wherein the at least one smart device user side of the at least one private cloud routing server comprises:

a computing device;

a connection to a network, either by wire or wirelessly; and

a program executing instructions stored in the memory to cause the at least one smart device client to perform the following actions:

transmitting a session reply to the at least one private cloud routing server message box;

retrieving a session acknowledgement from the at least one smart device client message box;

transmitting an access request to the at least one private cloud callback server;

waiting for the at least one private cloud routing server to reply;

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;

accessing the at least one private web service through the at least one private cloud routing server; and

and communicating with the at least one other intelligent device user side on one side of the at least one private cloud callback server through the at least one private cloud callback server.

6. The method of claim 4, wherein the program further comprises:

accessing the at least one private cloud routing server at any time and any place;

accessing the at least one private cloud routing server having 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 a local area network, and establishes a secure peer-to-peer communication channel with the at least one private cloud routing server;

accessing the at least one private network service through the at least one private cloud callback server and the at least one private cloud routing server; and

communicating with at least one other intelligent device user side of the at least one private cloud routing server through the at least one private cloud routing server.

7. The method of claim 5, wherein the program further comprises:

accessing the at least one private cloud routing server having a fixed or floating IP address behind a firewall;

the intelligent device client does not need a public cloud routing server in a wide area network, does not need additional router setting in a local area network, and establishes safe point-to-point communication with the server;

accessing private web services through the at least one private cloud routing server; and

and communicating with the at least one other intelligent device user side through the at least one private cloud routing server.

8. The method of claim 4, wherein the program further comprises:

the intelligent device client does not need a public cloud routing server in a wide area network, does not need additional router setting in a local area network, and establishes a safe point-to-point communication channel with the private cloud routing server;

mapping a region entity input and output to a virtual private cloud routing server input and output;

accessing a private network service through the at least one private cloud routing server; and

9. The method of claim 5, wherein the program further comprises:

mapping a local physical input/output to a virtual server input/output;

accessing private network services through the at least one private cloud routing server; and

10. 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 executing instructions stored in the storage to cause the at least one private cloud routing server to:

sending a session invitation to the second message box;

sending a session acknowledgement to the second message box.

11. The method of claim 10, wherein the program further executes instructions stored in the memory to cause the at least one private cloud routing server to:

transmitting a communication request to the at least one smart device client;

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 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 web service from the at least one smart device client on the side of the at least one private cloud routing server; and

enabling private and secure communication between the at least one smart device user on one side of the at least one private cloud callback server and the at least one other smart device user on the side of the at least one private cloud routing server.

12. A method for providing a secure session message connection mechanism between a private cloud callback server and at least one smart device client in a network of private cloud callback servers, the method comprising:

initializing and preparing the private cloud callback server;

creating a private cloud callback server user end;

checking the private cloud callback server user end;

editing a private cloud callback server point-to-point password and a state of the private cloud callback server;

modifying the private cloud callback server point-to-point password through the at least one intelligent device user side;

resetting the private cloud callback server point-to-point password and the state from a private cloud callback server local area network through a system manager; and

and the private cloud callback server is connected to the at least one intelligent device user side.

13. A method for a communication process of a connection mechanism between at least one private cloud callback server device client and at least one private cloud callback server device client through a cloud network, the method comprising:

connecting to a private cloud callback server portion public program through a client message box by the at least one private cloud callback server device client application request, wherein the private cloud callback server portion public program receives a registration through a routing server message box;

registering a private cloud routing server public program through the at least one private cloud routing server device user side;

registering a private cloud callback server user side part public program through the private cloud routing server public program;

receiving the request from the private cloud callback server portion public program through the private cloud callback server user side portion public program;

calling back to the private cloud routing server public program through the private cloud call-back server user side part public program with a connection intention;

transmitting a communication request from the private cloud routing server utility to the at least one private cloud routing server device client; and

starting point-to-point communication, wherein the point-to-point communication is from the at least one private cloud callback server device user side to the private cloud callback server user side part public program, to the private cloud callback server part public program, to the private cloud callback server user side part public program, to the private cloud routing server public program and to the private cloud routing server device user side in sequence.

14. The method of claim 13, wherein the callback server message box or the client message box is hosted by one of an email server, a text message server, a web server, or a server 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 message box or the client message box is accessible and under secure and private control of the private cloud callback server or the private cloud callback server device client; and

when the callback server message box or the client message box stops, the callback server message box or the client message box can be replaced or relocated immediately without endangering the communication between the private cloud callback server in the cloud network and the client of the private cloud callback server device.

15. The method of claim 13, further comprising providing a secure session messaging connection between a private cloud routing server and at least one smart device client in a network of private cloud routing servers, wherein the secure session messaging connection comprises:

initializing and preparing the private cloud routing server;

creating a private cloud routing server user end;

viewing the private cloud routing server user side;

editing a private cloud routing server point-to-point password and a state;

modifying the private cloud routing server point-to-point password through the at least one intelligent device user side;

resetting the private cloud routing server point-to-point password and the status from a private cloud routing server local area network through a system manager;

the user end portion connected to the private cloud callback server; and

16. A non-transitory computer readable medium storing executable instructions that, when executed, cause a computer to:

setting a private cloud callback server and an intelligent device user side in a user side server relationship;

wherein the private cloud callback server comprises a routing server message box public program for accessing a first message box located on a public cloud network;

wherein the private cloud callback server registers public and private IP addresses of the intelligent 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; and

wherein the private cloud callback server sends a session confirmation with public and private IP addresses to the second message box;

in a secure process, passing a session message between the first message box and the second message box through the routing server message box public program of the private cloud callback server;

wherein the secure process for transferring the session message between the private cloud callback server and the first message box and the second message box of the smart device client, respectively, comprises:

initializing and preparing the private cloud callback server;

creating a private cloud callback server user end;

checking the private cloud callback server user end;

editing the point-to-point password of the private cloud callback server and a state of the private cloud callback server; and

modifying a point-to-point password of a private cloud callback server through the intelligent device user side, and connecting to the private cloud callback server through the intelligent device user side;

wherein the smart device client is connected to the private cloud callback server via at least one of the following connections:

the intelligent device client judges that a target is located in a local area network with local access and determines to be directly connected to the private cloud callback server;

the smart device client determines that the target is not located in the local area network with local access and determines to connect to the public cloud via a wide area network, wherein the wide area network locates a router and the local area network, and connects to the private cloud callback server; and

the intelligent device client judges that the target is not located in the local area network with local access and determines to pass through the local area network and the router and connect to the public cloud network in the wide area network;

wherein a secure session message is verified by the private cloud callback server and the smart device client;

wherein the intelligent device client and the private cloud callback server communicate with each other after the session message is verified; and

wherein the smart device client securely accesses a private network service via the public cloud network according to the verified session message;

setting at least one other intelligent device user side, wherein the at least one other intelligent device user side and the private cloud callback server are in a user side server relationship;

wherein the smart device client and the at least one other smart device client communicate with the private cloud callback server after the session message is verified; and

wherein the smart device client and the at least one other smart device client communicate with each other privately and securely over the public cloud network.

17. A non-transitory computer readable medium storing executable instructions that, when executed, cause a computer to:

requesting, by a client device application, a connection to a private cloud callback server public program through a client message box, wherein a server portion of the private cloud callback server public program receives a registration through a routing server message box;

a private cloud callback server user end device requests the server part of the private cloud callback server public program to be connected to a user end part of the private cloud callback server public program through the user end message box;

the server part of the private cloud callback server public program receives the request through a routing server message box;

the server part of the private cloud callback server public program notifies the user end part of the private cloud callback server public program of an intention to be connected by the server part;

the user end part of the private cloud callback server public program replies a registration to the server part of the private cloud callback server public program;

the server part of the public program of the private cloud callback server responds to the application program of the client device through the routing server message box;

transmitting a communication request to the at least one private cloud routing server via the user side portion of the private cloud callback server public program;

registering the public and private IP addresses of the private cloud callback server client device through the private cloud callback server public program;

transmitting a session confirmed according to the public and private Internet addresses to the client message box through the public program of the private cloud callback server; and

starting a point-to-point communication between the private cloud callback server user end device and the user end part of the private cloud callback server public program;

wherein the private cloud callback server public program and the private cloud callback server user end device exchange information through the routing server message box and the user end message box;

wherein the private cloud callback server client device is connected to the client portion of the private cloud callback server public program through at least one of the following connections:

the private cloud callback server client device judges that the client part of the private cloud callback server public program is located in a local area network which can be accessed locally, and determines to be directly connected to the private cloud callback server public program;

the private cloud callback server client device judges that the client part of the private cloud callback server public program is not located in the local area network which can be locally accessed, and determines to connect to the public cloud via a wide area network, wherein the wide area network locates a router and the position of the local area network, and is connected to the private cloud callback server public program; and

the private cloud callback server client device judges that the client part of the private cloud callback server public program is not located in the local area network which can be locally accessed, and determines to pass through the local area network and the router and connect to the cloud network in the wide area network.

18. A method of communication, the method comprising:

in a client server relationship, setting at least one virtual machine, at least one private cloud callback server, at least one intelligent device client on one side of the private cloud callback server for providing cloud network service, at least one private cloud routing server and at least one intelligent device client on one side of the private cloud routing server;

wherein the at least one virtual machine comprises the at least one private cloud callback server to provide the cloud networking service;

the at least one virtual machine and the at least one private cloud callback server are configured in an ultra-large data center, and the at least one private cloud routing server is configured in a remote factory area of a user end.

Wherein the number and size of the at least one virtual machine is extensible;

wherein at least one of the very-large data center or the service provider constructs a plurality of independent private cloud callback servers in a corresponding plurality of corresponding virtual machines to provide services to a corresponding plurality of private cloud routing servers and a plurality of private cloud routing server device clients;

wherein a network platform owner maintaining the at least one virtual machine constructs and deploys a social pair of peer-to-peer communication relationships between the at least one private cloud callback server device client and a private cloud routing server device client;

wherein in the at least one virtual machine, the web platform owner provides a personal user with the hosting of the private cloud callback server;

wherein the network platform owner provides a separate private and secure private cloud routing server to individual users for installing the private cloud routing server in the local area network owned by the individual users; and

the platform user establishes point-to-point communication between the at least one private cloud callback server device user side and the private cloud routing server device user side from any place, and the private cloud routing server device user side is erected on a private and safe area network of the user.