Abstract:
A method and system for use with a public cloud network is disclosed, wherein the public cloud network includes at least one private cloud server and at least one smart client device in communication therewith. The method and system comprise setting up the at least one private cloud server and the at least one smart client device in a client server relationship. The at least one private cloud server includes a message box associated therewith. The first message box is located in the public network. The at least one smart client includes a second message box associated therewith. The second message box is located on the public network. The method includes passing session based message information between the at least one private cloud server and the at least one smart client device via the first message box and the second message box in a secure manner. The session base information is authenticated by the private cloud server and the at least one smart client device. The smart client device and the private cloud server can then communicate with each other after the session based information is authenticated.

Description:
FIELD OF THE INVENTION 
       [0001]    The present invention relates generally to networking and more particularly to the use of private cloud networks. 
       BACKGROUND OF THE INVENTION 
       [0002]    In the Internet connected environment, the Smart Device Clients including smart phone, tablet, eBook reader, notebook, PC and various smart gadgets are ubiquitous and omnipresent. Other than connectivity, one of the values of the Smart Device Clients is to be able to connect at any time and any place to retrieve services from one or many serving parties or servers. The services include audio, video contents, live or archived information, execution of applications, social media, messaging, email, storage, backup, calendar, contact, synchronization and others. There are different types of servers that serve these various requests from the Smart Device Clients. In general, these types of servers can be categorized to fall into two groups: a public cloud and a private cloud. Servers in the public cloud, implied by the name “public”, provide services that tend to be free with limited functionality or fee-based with more sophisticated services and interact with the public. Examples of the public cloud server include data center, social media services and storage/content provider through the Internet. On the other hand, servers in the private cloud tend to address the private need. The services provided are more private and personal as opposed to those offered by the public cloud. 
         [0003]    One example of the application of the private cloud server is a private cloud storage server (PCSS). The PCSS sits within the local area network (LAN) managed by the user. It provides on-line and backup storage for the user either within the LAN or in the wide area network (WAN). The user is able to use a Smart Device Client to access information within the private cloud storage server at anytime from anywhere. The private cloud storage server and the associated Smart Device Client therefore form an example of the Private Cloud Server and Client architecture. 
         [0004]    Conventionally, there are many storage server solutions exist, including network attached storage (NAS), Windows/Mac/Linux server, and direct attached storage (DAS) to fulfill the PCSS requirement. But the challenge for the Smart Device Clients in the field has been how to avoid the cumbersome setup and penetrate the firewall behind the router on the LAN to access the PCSS in a home or office environment. There are at least four kinds of solutions to this challenge. 
         [0005]    One solution is to assign a fixed IP address and open certain ports for the router in front of the PCSS, such that the Smart Device Client is able to locate the PCSS from outside the LAN and to authenticate itself, penetrate the firewall and establish a secure communication channel with the PCSS. 
         [0006]    The second solution applies when a fixed IP address is not available. The user configures the LAN router of the PCSS and open certain ports to map to the PCSS. The router is therefore able to be located by the intended Smart Device Client through a dynamic DNS (DDNS) service on the WAN. The Smart Device Client can authenticate itself, penetrate the firewall and establish a secure communication channel with the PCSS. 
         [0007]    The third solution is to rely on another routing server in the WAN to conduct the virtual private network (VPN) communication between the Smart Device Client and the PCSS. The VPN communication allows the Smart Device Client to locate the PCSS, authenticate itself, penetrate the firewall and establish a secure communication channel with the PCSS. 
         [0008]    The fourth solution is to rely on another routing server in the WAN to conduct the remote desktop protocol (RDP) or virtual network computing (VNC) communication between the Smart Device Client and the PCSS. The RDP/VNC communication allows the Smart Device Client to locate the PCSS, authenticate itself, penetrate the firewall and establish a secure communication channel with the PCSS. Other solutions can be mix-and match of the above mentioned solutions. 
         [0009]    In the first scenario, a fixed IP address is required and the router needs to be set up and configured. The down side is that a fixed IP involves more cost and is usually not available in the home and small business environment. The router set up and configuration can be very complicated and are not user friendly with most consumers. 
         [0010]    In the second scenario, a DDNS service is required and the router needs yet more complex set up. Again, the DDNS set up involves additional cost and complexity into the system. The router set up and configuration can be very complicated and is not user friendly with most consumers. 
         [0011]    In the third and fourth scenarios, an outside routing server or service needs to be established, while a router set up is not necessary. The outside routing server or service controls and handles login/authentication between the Smart Device Client and the server. The private cloud becomes less private and less secure through the third party server or service. If for any reason the server or service is down, the communication and availability of the private cloud storage server will be jeopardized. 
         [0012]    All of these scenarios require technical expertise that may be suitable for conventional corporate environment, but these scenarios are not suitable for consumer oriented Smart Device Client centric deployment. 
         [0013]    In most conventional systems, an outside or third party routing server is used by the Smart Device Client during access to the Private Cloud Server. Using an outside server creates a number of concerns to the Smart Device Client owner. First, the sense of trust is always in question, because the outside or third party routing server is a middleman during all communication transactions between the Smart Device Client and the Private Cloud Server. It may hold all user account info, password and their corresponding IP addresses of the Smart Device Client and the Private Cloud Server. The routing server is able to sniff any communication in-between and render it insecure. Second, being an outside and third party routing server, its business model may not always be in-line or in-sync with the Smart Device Client owner. If the routing server is out of service due to any business reason, there is no remedy or option of replacement to restore the service. It potentially poses a tremendous business risk to the user, as the vital link in the communication can be broken without recourse. 
         [0014]    What is needed in the consumer oriented environment is for the Smart Device Client in the WAN to be able to obtain services from a Private Cloud Storage Server (PCSS) or any Private Cloud Server (PCS) solving the following challenges: 
         [0015]    1. Access the Private Cloud Server (PCS) at anytime from anywhere. 
         [0016]    2. Access the PCS behind the firewall with fixed or dynamic IP address. 
         [0017]    3. Require no outside or third party routing server in the WAN. 
         [0018]    4. Require no additional router setup in the LAN. 
         [0019]    5. Authenticate with the PCS. 
         [0020]    6. Establish a secure communication channel with the PCS. 
         [0021]    If such challenges can be met and resolved, it will increase the deployment of the Private Cloud Server or service exponentially, due to the plug and play simplicity and availability. It also removes the technical and business concern by not utilizing a third party routing server. The Private Cloud Server covering storage and remote desktop service becomes very affordable and ubiquitous in the private cloud infrastructure. Accordingly, the present invention addresses such a need. 
       SUMMARY OF THE INVENTION 
       [0022]    A method and system for use with a public cloud network is disclosed, wherein the public cloud network includes at least one private cloud server and at least one smart client device in communication therewith. The method and system comprise setting up the at least one private cloud server and the at least one smart client device in a client server relationship. The at least one private cloud server includes a message box associated therewith. The first message box is located in the public network. The at least one smart client includes a second message box associated therewith. The second message box is located on the public network. The method includes passing session based message information between the at least one private cloud server and the at least one smart client device via the first message box and the second message box in a secure manner. The session base information is authenticated by the private cloud server and the at least one smart client device. The smart client device and the private cloud server can then communicate with each other after the session based information is authenticated. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0023]      FIG. 1A  is a block diagram of a conventional Cloud Network Infrastructure. 
           [0024]      FIG. 1B  is a block diagram of a Cloud Network Infrastructure in accordance with an embodiment. 
           [0025]      FIG. 2  shows a conventional implementation of how the Private Cloud Server can be accessed physically through the configuration of its Router_P on the LAN. 
           [0026]      FIG. 3  shows a conventional implementation of how the Private Cloud Server can be accessed logically through registration with a VPN Routing Server. 
           [0027]      FIG. 4  shows an implementation of how the Private Cloud Server can be accessed logically through registration with an Intermediate Routing Server. 
           [0028]      FIG. 5  shows a conventional implementation of how the Private Cloud Server can be accessed logically through peer-to-peer communication registering with an Intermediate Routing Server. 
           [0029]      FIG. 6  illustrates an Initial Setup of the Private Cloud Server and the Smart Device Client in accordance with the present invention. 
           [0030]      FIG. 7  shows the communication flow of the Smart Device Client in accordance with the present invention. 
           [0031]      FIG. 8  shows the communication flow of the Private Cloud Server in accordance with the present invention. 
           [0032]      FIG. 9  shows a block diagram of the Private Cloud Server in accordance with the present invention. 
           [0033]      FIG. 10  shows a block diagram of the Smart Device Client in accordance with the present invention. 
       
    
    
     DETAILED DESCRIPTION 
       [0034]    The present invention relates generally to networking and more particularly to the use of private cloud networks. 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 and its requirements. Various modifications to the embodiments and the generic principles and features described herein will be readily apparent to those skilled in the art. Thus, the present invention is not intended to be limited to the embodiments shown, but is to be accorded the widest scope consistent with the principles and features described herein. 
         [0035]    The term “Client” is interchangeable with “Smart Device Client” throughout discussion in the context. The term “router” is in general interchangeable with “gateway”, “access point” and/or “NAT” (network address translation) in the discussion. 
         [0036]    The purpose of a system and method in accordance with the invention is to provide a Private Cloud Server and Client architecture without utilizing a routing server. The system and invention addresses all challenges that allows a Client to be able to access the Private Cloud Server (PCS) from anywhere at anytime. The system also accesses the PCS behind the firewall with fixed or dynamic IP, requires no additional router setup and no third party routing server in the WAN, to authenticate with the PCS, and to establish a secure communication channel directly with the PCS. 
         [0037]    As shown in  FIG. 1 , a cloud network infrastructure includes a public cloud  100 , a public cloud server  113 , an intermediate routing server  112 , a VPN routing server  114 , a Smart Device Client  101  in the WAN, a Router_P  102  and a Router_S  103 . The Router_S  103  connects between a LAN  105  and the Internet in public cloud  100 . The Router_P  102  connects between a LAN  104  and the Internet in public cloud  100 . Behind the LAN  104 , there are Smart Device Clients  106 ,  107  and a Private Cloud Server (PCS)  108 . Behind the LAN  105 , there are Smart Device Clients  109 ,  110  and  111 . The Smart Device Client can be a PC, notebook, tablet, eBook reader, GPS, smart TV, set top box, MP3 player, or any networkable embedded device. They are denoted in the Cloud Network Infrastructure as  101 ,  106 ,  107 ,  109 ,  110 , and  111 . Any one of the Smart Device Clients above is interchangeable in the context and discussion. The focus on this discussion is the Smart Device Client  109 , as the representative in this context. 
         [0038]    Physically, there are three scenarios that a Smart Device Client  101 ,  107  or  109  can connect to the Private Cloud Server  108 . First, a Smart Device Client  107  determines whether the target is in the locally accessible LAN  104  and decides to connect to the Private Cloud Server  108  directly. Second, the Smart Device Client  101  determines the target is not in the locally accessible LAN  104  and decides to connect through the WAN to the public cloud  100 . The WAN locates the Router_P  102  and LAN  104 , then connects to the Private Cloud Server  108 . Third, the Smart Device Client  109  determines the target is not in the locally accessible LAN  105  and decides to passes through LAN  105 , Router_S  103 , and connects to the public cloud  100  in the WAN. The Smart Device Client  109  then locates Router_P  102 , LAN  104  and connects to the Private Cloud Server  108 . The first and the second scenario are two special cases and derivatives of the third scenario. Therefore, it is beneficial for the invention to focus on the third scenario that is with broader scope and complexity in real life application. 
         [0039]      FIG. 2  shows a conventional implementation of how the Private Cloud Server  108  can be accessed physically through the configuration of its Router_P  102  on the LAN  104 . There are two steps involved in configuring the Router_P  102 . First, the user needs to map the private IP address of the Private Cloud Server  108 , to a specific port in Router_P  102 , as in step  200 . Second, the user needs to register the public IP address of the Router_P  102 , that hosts the Private Cloud Server  108 , with an Intermediate Routing Server  112  in the WAN, as in step  201 . Before the Smart Device Client  109  can access the Private Cloud Server  108 , it looks up the Intermediate Routing Server  112  to locate the public IP address of the Private Cloud Server  108 , as in step  202 . It then can start accessing, as in step  203 , the predetermined port of the Router_P  102 , which is correctly mapped to the private IP address of the Private Cloud Server  108 . 
         [0040]    The configuration of the Router_P  102  and the setup of the Intermediate Routing Server  112  are not really trivial and can be very difficult for most of the end users. Further, by mapping the private IP address of the Private Cloud Server  108  to a port that is directly and permanently addressable by the outside world, it conceivably creates a big security risk for the Private Cloud Server  108 . 
         [0041]    The Private Cloud Server  108  is directly and permanently exposed to the outside world that can invite many vicious attacks. Also, the Intermediate Routing Server  112  is a third party server. It creates a number of concerns to the Smart Device Client  109  owner. First, the sense of trust is always in question, because the Intermediate Routing Server  112  is a middleman during all communication transactions between the Smart Device Client  109  and the Private Cloud Server  108 . It may hold all user account information, password and their corresponding IP addresses of the Smart Device Client  109  and the Private Cloud Server  108 . The Intermediate Routing Server  112  is able to sniff any communication in-between and render it insecure. 
         [0042]    Second, being an outside and third party routing server, the business model of the Intermediate Routing Server  112  may not always be in-line or in-sync with the Smart Device Client  109  owner. If the Intermediate Routing Server  112  is out of service due to any business reason, there is no remedy or option of replacement to restore the service. It potentially poses a tremendous business risk to the user, as the vital link in the communication can be broken without recourse. 
         [0043]      FIG. 3  shows a conventional implementation of how the Private Cloud Server  108  can be accessed logically through registration with a VPN Routing Server  114 . During setup of a virtual private network, the Private Cloud Server  108  first registers its public IP address and its private IP address with a VPN (virtual private network) Routing Server  114  and stays logging in, as in  300 . The Smart Device Client  109  also registers its public IP address and its private IP address with the same VPN Routing Server  114 , in step  301 . The VPN Routing Server  114  allocates virtual IP addresses for both Private Cloud Server and the Smart Device Client  109  and sets up a Virtual Private Network  302 . By this time, the Smart Device Client  109  and the Private Cloud Server  108  are in the same virtual IP domain under the control of the VPN Routing Server  114 . All communication between the Smart Device Client  109  and the Private Cloud Server  108  are encapsulated under the VPN protocol. 
         [0044]    The Smart Device Client  109  then logs in to the VPN Routing Server  114  and looks up the virtual IP address of the Private Cloud Server  108 , in step  303 . All communication between the Smart Device Client  109  and the Private Cloud Server  108  are intercepted and encapsulated by the VPN Routing Server  114 , in step  304 . The Smart Device Client  109  can then start accessing the Private Cloud Server  108 , as in step  305 . 
         [0045]    As opposed to the prior art in  FIG. 2 , the VPN Routing Server approach in this prior art benefits by eliminating the router configuration. It therefore makes the setup much easier for the user. But it suffers the same, if not more serious business concerns on the issue of having to have all communication going through a third party routing server. Being a third party server, the VPN Routing Server  114  creates a number of concerns to the Smart Device Client  109  owner. First, the sense of trust is always in question, because the VPN Routing Server  114  is a middleman during all communication transactions between the Smart Device Client  109  and the Private Cloud Server  108 . It may hold all user account information, password and their corresponding IP addresses of the Smart Device Client  109  and the Private Cloud Server  108 . The VPN Routing Server  114  is able to sniff any communication in-between and render it insecure. Second, being an outside and third party routing server, the business model of the VPN Routing Server  114  may not always be in-line or in-sync with the Smart Device Client  109  owner. If the VPN Routing Server  114  is out of service due to any business reason, there is no remedy or option of replacement to restore the service. Unless the user has total control over the VPN routing server, it potentially poses a tremendous business risk to the user, as the vital link in the communication can be broken without recourse. 
         [0046]      FIG. 4  shows an implementation of how the Private Cloud Server  108  can be accessed logically through registration with an Intermediate Routing Server  112 . The Private Cloud Server  108  first registers its public IP address and its private IP address with an Intermediate Routing Server  112  and obtains a set of ID and Password from the server, in step  400 . The Smart Device Client  109  then registers its public IP address and its private IP address with the same Intermediate Routing Server  112  and obtains a set of ID and Password, as in step  401 . The Private Cloud Server  108  logs in to the Intermediate Routing Server  112 , as in step  402 . 
         [0047]    Before the Smart Device Client  109  is able to access the Private Cloud Server  108 , a number of steps have to happen. First, the Smart Device Client  109  obtains the ID and Password of the Private Cloud Server  108  from the server through a secure channel, such as phone call, email, text message or snail mail, as in step  403 . The Smart Device Client  109  then logs in to the Intermediate Routing Server  112  with the its own ID and the obtained ID and Password of the Private Cloud Server  108 , as in step  404 . All communication between the Smart Device Client  109  and the Private Cloud Server  108  are intercepted and encapsulated by the Intermediate Routing Server  112 , as in step  405 . Finally, the Smart Device Client  109  can start accessing the Private Cloud Server  108 , as in step  406 . 
         [0048]    As opposed to the conventional approach in  FIG. 2 , the Intermediate Routing Server approach benefits from doing away with the router configuration. It therefore makes the setup much easier for the user. But it suffers the same, if not more serious business concerns on the issue of having to have all communication going through a third party routing server. 
         [0049]    Being a third party server, the Intermediate Routing Server  112  creates a number of concerns to the Smart Device Client  109  owner. First, the sense of trust is always in question, because the Intermediate Routing Server  112  is a middleman during all communication transactions between the Smart Device Client  109  and the Private Cloud Server  108 . It may hold all user account information, password and their corresponding IP addresses of the Smart Device Client  109  and the Private Cloud Server  108 . The Intermediate Routing Server  112  is able to sniff any communication in-between and render it insecure. 
         [0050]    Second, being an outside and third party routing server, the business model of the Intermediate Routing Server  112  may not always be in-line or in-sync with the Smart Device Client  109  owner. If the Intermediate Routing Server  112  is out of service due to any business reason, there is no remedy or option of replacement to restore the service. It potentially poses a tremendous business risk to the user, as the vital link in the communication can be broken without recourse. 
         [0051]      FIG. 5  shows a conventional implementation of how the Private Cloud Server  108  can be accessed logically through peer-to-peer communication registering with an Intermediate Routing Server  112 . The Private Cloud Server  108  first registers its public IP address and its private IP address with an Intermediate Routing Server  112  and obtains a set of ID and Password from the server, in step  500 . The Smart Device Client  109  then registers its public IP address and its private IP address with the same Intermediate Routing Server  112  and obtains a set of ID and Password, as in step  501 . The Private Cloud Server  108  and the Smart Device Client  109  log in to the Intermediate Routing Server  112 , as in step  502 . 
         [0052]    Before the Smart Device Client  109  is able to access the Private Cloud Server  108 , a number of steps have to happen. First, the Smart Device Client  109  and the Private Cloud Server  108  obtain the public IP and private IP addresses of the other party from the Intermediate Routing Server, as in step  503 . Both parties punch a hole in their respective routers during initial outgoing communication attempt with each other, as in step  504 . All communication between the Smart Device Client  109  and the Private Cloud Server  108  are bound together, establishing a peer-to-peer communication channel in between, as in step  505 . Finally, the Smart Device Client  109  can start accessing the Private Cloud Server  108 , as in step  506 . 
         [0053]    As opposed to the conventional approaches of  FIG. 2 ,  FIG. 3  and  FIG. 4 , the Intermediate Routing Server approach in this prior art has the benefit of establishing peer-to-peer communication between the client and the server and offers better performance. But it still suffers from the problem of “single point of failure” where all communication go through a single third party routing server. Being a third party server, the Intermediate Routing Server  112  creates a number of concerns to the Smart Device Client  109  owner. First, the sense of trust is always in question, because the Intermediate Routing Server  112  is a middleman holding all user account information, password and their corresponding IP addresses of the Smart Device Client  109  and the Private Cloud Server  108 . 
         [0054]    Second, being an outside and third party routing server, the business model of the Intermediate Routing Server  112  may not always be in-line or in-sync with the Smart Device Client  109  owner. If the Intermediate Routing Server  112  is out of service due to any business reason, there is no remedy or option of replacement to restore the service. It potentially poses a tremendous business risk to the user, as the vital link in the communication can be broken without recourse. 
         [0055]    One of the biggest advantages of a system and method in accordance with the present invention over the above cited conventional approaches is to eliminate with the role of the third party routing server during access, as in the case of either the VPN Routing Server or the Intermediate Routing Server. Another advantage of the invention is that no secret information such as password of the account is ever exchanged between the Smart Device Client  109  and the Private Cloud Server  108 . 
         [0056]      FIG. 1B  is a block diagram of a Cloud Network Infrastructure in accordance with an embodiment. Those elements that are the same as those described with respect to  FIG. 1A  have the same designators. However, in this embodiment, there are also two message boxes, message_box_S  115  and message_box_P  116  which purposes will be described in detail hereinafter. As in  FIG. 1A , behind the LAN  104 , there are Smart Device Clients  106 ,  107  and a Private Cloud Server (PCS)  108 . Behind the LAN  105 , there are Smart Device Clients  109 ,  110  and  111 . The Smart Device Client can be a PC, notebook, tablet, eBook reader, GPS, smart TV, set top box, MP3 player, or any networkable embedded device. They are denoted in the Cloud Network Infrastructure as  101 ,  106 ,  107 ,  109 ,  110 , and  111 . Any one of the Smart Device Clients above is interchangeable in the context and discussion. The focus on this discussion is the Smart Device Client  109 , as the representative in this context. 
         [0057]    To describe the features of the present invention in more detail, refer now to  FIG. 6 ,  FIG. 7  and  FIG. 8 , which cover the initial setup phase and the access phase of the invention. 
         [0058]      FIG. 6  illustrates an Initial Setup of the Private Cloud Server  108  and the Smart Device Client  109  in accordance with the present invention. The Private Cloud Server  108  and the Smart Device Client  109  form a server-client relationship. The server  108  first creates an authorized client list with the client account name and the corresponding message box information. The message box information can be in the form of an email account, text message account or other unique public account information of the client. On the Private Cloud Server  108  side, it sends a session based invitation to message_box_S  115  of the intended Smart Device Client  109  as one of the authorized users, in step  601 . The session based invitation may include the server message box address message_box_P  116 . The Private Cloud Server  108  then attempts to retrieve session based access request that includes the client message box address message_box_S  115 , client public IP Public_IP_ 5119  and private IP private_IP_S 120  addresses from the server message box message_box_P  116 , as in step  602 . If the access request is invalid, then it loops back to step  601 . If the access request is valid, the Private Cloud Server  108  then registers the client message box  115 , public IP  119  and the private IP  120  addresses of the Smart Device Client  109 , as in step  604 . The Private Cloud Server  108  sends to the client message box message_box_S  115 , a session based acknowledgement with its current server public IP and private IP addresses, public_IP_P  117  and private_IP_P  118 , as in step  605 . The Private Cloud Server  108  can start the communication request to the Smart Device Client  109 , as in step  606 . 
         [0059]    On the Smart Device Client  109  side, it first retrieves the session based invitation from its own message_box_S  115 , as in step  611 . The session based invitation includes the message box address message_box_P  116  of the Private Cloud Server. If the invitation from the Private Cloud Server  108  is invalid, then it loops back to step  611 . If the invitation is valid from the Private Cloud Server  108 , the Smart Device Client  109  may reply to the Private Cloud Server  108  message box message_box_P  116  with a session based access request, to register its current client message box address, public IP and private IP addresses whenever it needs to access to the Private Cloud Server  108 , as in step  613 . The session based access request may include the Smart Device Client  109  message box address, message_box_S  115 , and the client public and private IP addresses, public_IP_S  119  and private_IP_S  120 . The Smart Device Client  109  then retrieves from the client message_box_S  115 , the session based acknowledgement with the Private Cloud Server current public IP and private IP addresses, public_IP_P  117  and private_IP_P  118 , as in step  614 . The Smart Device Client  109  can start the communication request to the Private Cloud Server, as in step  615 . These two independent processes conclude the initial setup of the Private Cloud Server  108  and the Smart Device Client  109 . 
         [0060]    The message box servers, hosting either server or client message boxes, can be an email server, text message server, or any kind of server that can host secure message for information exchange between the Private Cloud Server  108 , as a server, and the Smart Device Client  109 , as a client. The security and business model of the message box server is well understood and expected in the industry by the user. For any reason the message box server is down, it can be replaced or redeployed immediately without jeopardizing the communication between the server and the client in the private cloud infrastructure. 
         [0061]      FIG. 7  shows the communication flow of the Smart Device Client  109  in accordance with the present invention. The Smart Device Client  109  can start peer-to-peer communication with the Private Cloud Server  108  without going through an Intermediate Routing Server  112  or a VPN Routing Server  114 . The Smart Device Client  109  first sends a communication request passing through its Router_S  103  to the Router_P  102  of the Private Cloud Server  108 , as in step  700 . The Router_S  103  registers the public IP and private IP addresses of the Smart Device Client  109  and the Private Cloud Server  108 , as in step  701 . The Router_S  103  outgoing route stays open, punching a hole and waiting for response from the Private Cloud Server  108 , as in step  702 . The Router_S  103  then checks if the incoming response is from the Private Cloud Server  108 , as in step  703 . If the incoming response is invalid and it has timed out, then the initialization process of the Smart Device Client  109  starts over again, as in step  708 . If it has not timed out, then it loops back to step  702 . But, if the incoming response is valid, the Router_S  103  will bind the incoming public IP address and the private IP address of the Private Cloud Server  108 , with the registered outgoing private IP address of the Smart Device Client  109 , as in step  704 . The incoming request from the Private Cloud Server  108  is then routed to the Smart Device Client  109 , as in step  705 . The Smart Device Client  109  can start secure peer-to-peer communication with the Private Cloud Server  108  and access services from it, as in step  706 . 
         [0062]      FIG. 8  shows the communication flow of the Private Cloud Server  108  in accordance with the present invention. The Private Cloud Server  108  can start peer-to-peer communication with the Smart Device Client  109  without going through an Intermediate Routing Server  112  or a VPN Routing Server  114 . The Private Cloud Server  108  first sends a communication request passing through its Router_P  102  to the Router_S  103  of the Smart Device Client  109 , as in step  800 . The Router_P  102 , in response to the outgoing communication request, then registers the public IP and private IP addresses of the Smart Device Client  109  and the Private Cloud Server  108 , as in step  801 . The Router_P  102  outgoing route stays open, punching a hole and waiting for response from the Smart Device Client  109 , as in step  802 . The Router_P  102  checks for incoming response to see if it is from the Smart Device Client  109 , as in step  803 . If the incoming response is invalid and it has timed out, then the initialization process of the Private Cloud Server  108  starts over again, as in step  808 . If it has not timed out, then it loops back to step  802 . But, if the incoming response is valid, the Router_P  102  will bind the incoming public IP address and the private IP address of the Smart Device Client  109 , with the registered outgoing private IP address of the Private Cloud Server  108 , as in step  804 . The incoming request from the Smart Device Client  109  is then routed to the Private Cloud Server  108 . The Private Cloud Server  108  can start secure peer-to-peer communication with the Smart Device Client  109  and accept access of services from it, as in step  806 . 
         [0063]    In order to ensure the peer-to-peer communication channel secure, a number of security measures are deployed, including AES encryption and/or SSL (secure socket layer), TLS (transport layer security). The session based communication between the server and client, including invitation, access request and acknowledgement, also utilizes random number seeds, time stamp, encryption and hashing to defeat man-in-the middle and reply attack from the third party to ensure the security and integrity of the communication. 
         [0064]    Because the invention does not rely on a third party routing server, it solves and eases a number of concerns to the Smart Device Client owner. First, there is no single point of failure between the client and the server. Second, there is no middleman during any communication transactions between the Smart Device Client  109  and the Private Cloud Server  108 . The performance is therefore better. Third, no sniffing of any communication in-between is possible and therefore makes the process very secure for the client and server. The user account information, password and their corresponding IP addresses of the Smart Device Client  109  and the Private Cloud Server  108  are never exposed to a third party. The only outside communication channels utilized in information exchange between the Smart Device Client  109  and the Private Cloud Server  108  are the two private message boxes message_box_S  115  and message_box_P  116 . The password information is never exchanged between the Private Cloud Server  108  and the Smart Device Client  109 , as a client. The security of the communication is as good as the message box servers hosting message_box_S  115  and message_box_P  116 . If for any reason either message box is compromised or out of service, another replacement or backup message box can be deployed immediately. In this invention, any key component, including router, network switch, message box, Smart Device Client  109 , or even Private Cloud Server  108 , can be replaced without affecting the efficiency and integrity of the communication link between the Smart Device Client  109  and the Private Cloud Server  108 . 
         [0065]      FIG. 9  shows a block diagram of the Private Cloud Server  108  in accordance with the present invention. It includes a processor  900 , ROM  901 , RAM  902 , network interface  903 , input/output (I/O)  904 , and non-volatile mass storage  905 . The non-volatile storage  905  further contains an operating system (OS)  909 , device driver  908 , and cloud server driver  907 . If the Private Cloud Server  108  is to serve applications, it will contain an Application Programs Server  906 , which may include remote desktop protocol (RDP), VNC, office tools, media player, and other user specific applications. If the Private Cloud Server  108  is to be used as a storage server, it may include a non-volatile mass storage server  910  that contain multiple terabytes of storage serving the private cloud. 
         [0066]    The network interface  903  can connect to LAN, WAN or 3G/4G network. The I/O  904  is for user interface to the outside world, including input/output devices such as keyboard, mouse, audio and video. The non-volatile storage can be hard disk storage or flash based solid state disk. Inside the non-volatile mass storage  905 , it is loaded with necessary software including OS and device drivers. 
         [0067]    The Cloud Server Driver  907  is deployed to communicate with the corresponding Cloud Client Driver from the Smart Client Device  109 . The Cloud Server Driver  907  initiates invitation, processes the access request, and then sends acknowledgement back to the Smart Device Client  109 . Later, it sends communication request to the Smart Device Client  109  and opens a hole in its router in the outgoing direction. Once the incoming request from the Smart Device Client reaches the opened hole, the two-way communication channel is bound together. The Cloud Server Driver  907  can start secure peer-to-peer communication with the Smart Device Client  109 . 
         [0068]      FIG. 10  shows a block diagram of the Smart Device Client  109  in accordance with the present invention. The Smart Device Client  109  includes a processor  1000 , ROM  1001 , RAM  1002 , network interface  1003 , input/output (I/O)  1004 , and non-volatile mass storage  1005 . The non-volatile storage  1005  further contains an operating system (OS)  1009 , device driver  1008 , and Cloud Client Driver  1007 . The Smart Device Client  109  will also be loaded with Application Programs  1006  to communicate with the Private Cloud Server  108 . 
         [0069]    The network interface  1003  can connect to LAN, WAN or 3G/4G network. The I/O  1004  is for user interface to the outside world, including input/output devices such as touch pad, audio and video. The non-volatile storage can be hard disk storage or flash based solid state disk. Inside the non-volatile mass storage  1005 , it is loaded with necessary software including OS and device drivers. The Cloud Client Driver  1007  is deployed to communicate with the corresponding Cloud Server Driver  907  from the Private Cloud Server  108 . The Cloud Client Driver  1007  responds to server invitation, replies with the access request, and then accepts acknowledgement from the Private Cloud Server  108 . Later, it sends communication request to the Private Cloud Server  108  and opens a hole in its router in the outgoing direction. Once the incoming request from the Private Cloud Server  108  reaches the opened hole, the two-way communication channel is bound together. The Smart Device Client  109  can start secure peer-to-peer communication with the Private Cloud Server  108 . 
         [0070]    Although the present invention has been described in accordance with the embodiments shown, one of ordinary skill in the art will readily recognize that there could be variations to the embodiments and those variations would be within the spirit and scope of the present invention. Accordingly, many modifications may be made by one of ordinary skill in the art without departing from the spirit and scope of the appended claims.