TWI829435B - Metaverse application gateway connection mechanism for use in a private communication architecture - Google Patents

Abstract

A method for a connection mechanism in a public cloud network is disclosed. The method includes acquiring a plurality of connection credentials from a public cloud portal (PCP) Admin Device; pairing and registration with a metaverse virtual private network (VPN) server (MVVS) from a metaverse app gateway (MVAG); establishing a plurality of initial VPN tunnels between the MVVS and the MVAG; connecting to the MVAG on demand between a MVVS smart device client and the MVAG through the MVVS; and running a plurality of vertical peer-to-peer (P2P) private and secure MVVS smart device client applications.

Description

A Metaverse application gateway connection mechanism for private communication architecture

The present invention relates to a Metaverse application gateway connection mechanism for private communication architecture.

In an Internet-connected environment, smart device users including smartphones, tablets, e-book readers, laptops, personal computers and various smart gadgets are everywhere. In addition to connectivity, one of the values of smart device customers is the ability to connect anytime and anywhere to obtain services from one or more service providers or servers. Services include voice, image text, live or archived information and applications, social media, messaging, email, storage, backup, calendar, contacts, synchronization, sharing, remote desktop, Internet of Things (IoT) ) and so on. Another service includes real-time private and secure image, voice, text and app communications between at least two smart device clients. There are different types of servers that serve various requests from smart device clients. Generally speaking, server types can be divided into two categories: public cloud and private cloud. Servers in the public cloud, as the word "public" implies, provide free services with limited functionality or more complex services for a fee, as well as interact with the public. Examples of public cloud servers include data centers, social media services, and storage/text providers over the Internet. On the other hand, servers in private clouds tend to serve private needs. Compared with the services provided by the public cloud, the services provided by the private cloud are more private and personalized.

One example of a private cloud server (PCS) application is a private cloud storage server (PCSS). Private cloud storage servers are located within a user-managed local area network (LAN). It provides online and backup storage for users in a local area network or wide area network (WAN). Users can use smart device clients anytime and anywhere to access information in private cloud storage servers. Accordingly, the private cloud storage server and associated smart device clients form an embodiment of the private cloud server and client architecture.

Traditionally, there are many storage server solutions, including network attached storage (NAS), Windows/Mac/Linux servers and direct attached storage (DAS), to meet the needs of private clouds. Storage server requirements. However, the challenge for on-site smart device customers is how to avoid cumbersome setup to penetrate the firewall behind the router on the local area network to access a private cloud storage server in a home or office environment. There are at least four solutions to this challenge.

The first solution is to assign a fixed Internet Protocol (IP) address and open a specific port on the router in front of the private cloud storage server so that smart device customers can locate the private cloud storage from outside the local network. Servers and perform authentication, penetrate firewalls, and establish secure communication channels with private cloud storage servers.

The second solution is suitable when a fixed Internet Protocol address is not available. The user configures the local area network router of the private cloud storage server and opens specific ports to map to the private cloud storage server. Therefore, through the dynamic domain name service (DDNS) on the local area network, the router can be located by the target smart device client. Smart device customers can authenticate themselves, penetrate firewalls, and establish secure communication channels with private cloud storage servers.

A third solution relies on another routing server in the WAN to perform virtual private network (VPN) communication between the smart device client and the private cloud storage server. Virtual private network communication allows smart device customers to locate private cloud storage servers, self-authenticate, penetrate firewalls, and establish secure communication channels with private cloud storage servers.

The fourth solution relies on another routing server in the WAN to perform remote desktop protocol (RDP) or virtual network computing (VNC) communication between the smart device client and the private cloud storage server. Remote Desktop Protocol/Virtual Network Computing Communication allows smart device customers to locate private cloud storage servers, self-authenticate, penetrate firewalls, and establish secure communication channels with private cloud storage servers. Another solution could be a mix and match of the above solutions.

In the first case, a fixed Internet Protocol address is required, and the router needs to be set up and configured. The disadvantages are that fixed Internet protocols involve more cost and are often unavailable in home and small business environments. Router setup and settings can be very complicated and not user-friendly for most consumers.

In the second case, a dynamic zone name service is required, and the router requires a more complex setup. Likewise, setting up a dynamic zone name service involves additional cost and complexity to the system. Router setup and settings can be very complicated and not user-friendly for most consumers.

In the third and fourth cases, an external routing server or service needs to be established, and a router does not need to be set up. The external routing server or service controls and handles login/authentication between the smart device client and the server. With public cloud-based servers or services, private clouds become less private and less secure. If the server or service fails for any reason, the communication and availability of the private cloud storage server will be threatened.

All of these scenarios require technical expertise that is applicable to traditional enterprise environments, but these scenarios are not suitable for consumer-focused customer-centric deployments of smart devices.

In most traditional systems, external or public cloud-based routing servers are used by smart device clients during access to private cloud services. Using external servers creates many problems for smart device customer owners.

First, trust is always an issue because external or public cloud-based routing servers are the middlemen for all communication transactions between smart device customers and private cloud services. It saves all user accounts, such as passwords for smart device clients and private cloud services, and their corresponding Internet Protocol addresses. The routing server can detect any communication between the two and consider it unsafe.

Second, as external and public cloud-based routing servers, the server owner's business model cannot always be consistent or synchronized with the smart device customer owner. If a routing server goes out of service for any business reason, there will be no remedy or replacement option to restore service. Routing servers pose a huge business risk to users because important links in communications can be destroyed without recourse.

Traditionally, in the case of communication between two smart device clients, both parties need to log in to a public cloud-based server to perform real-time image, voice, text or application communication. As mentioned above, since communications must go through public cloud-based servers, privacy and security can easily be compromised.

In addition, IoT devices, which are components of home smart appliances, have been plagued by fragmentation from standards such as Matter, Apple HomeKit, Google Nest, Amazon Alexa, and many others. The adoption rate of smart home appliances has been lower than expected due to issues around interoperability, compatibility, and privacy and security of IoT devices.

Therefore, a system and method are needed to solve the above problems. Previous inventions have a private cloud VPN server (PCVS) and a private matter gateway (PMG) in a private metaverse (PM) environment to solve this problem. kind of need.

In addition, as the Internet evolved into Web 3.0, Metaverse began to emerge to provide use case scenarios for specific user groups to access a specific set of content in a private and secure manner. The use case scenarios in the public cloud metaverse mimic the previously invented private metaverse to a broader extent. The similarities are that the Private Cloud VPS was replaced by the Metaverse VPN Server (MVVS), and the Private Matter Gateway was replaced by the Metaverse App Gateway (Metaverse App Gateway, MVAG). The difference is that the Metaverse Application Gateway is deployed by the Metaverse Provider in its own Metaverse Application Environment, rather than being a private matter gateway deployed by the user in a private area network (LAN) The situation of Taoist tools. Additionally, the content of the Metaverse Application Gateway is specific to the virtual world application, such as archived content, live streaming events, and domain-specific content, unlike the content of the Private Matter Gateway. Private physical gateways prefer IoT devices or network services on the user's private local area network. The present invention addresses this need.

The invention discloses a method for a public cloud network. The method includes setting up at least one public cloud portal (PCP), at least one virtual machine server (VMS), and at least one public cloud portal in a client's server relationship in a master-slave manner. Management device, at least one metaverse virtual private network (VPN) server (metaverse VPN server, MVVS), at least one virtual private network channel (tunnel), at least one metaverse virtual private network server At least one Metaverse virtual private network server smart device client on one side provides a plurality of cloud-based network services, at least one Metaverse application (MA) including at least one private router, at least one private A local area network (LAN), at least one metaverse application gateway (MVAG), at least one metaverse application gateway management device, at least one metaverse application gateway network Road services and at least one Metaverse Application Gateway smart device client on one side of the Metaverse Application Gateway private area network. Metaverse VPS smart device customers such as smartphones, tablets, notebooks (NB) or Tesla Dashboards running in the public cloud, and Metaverse Application Gateway smart devices Customers such as laptops, Internet of Things (IoT) devices, network attached storage (NAS), set-top-box (STB), smart devices, and archived content servers server, live event content or media server, located on a private and secure LAN. The present invention is based on a decentralized peer-to-peer (P2P) communication architecture to provide user access convenience while also providing privacy and security. At least one public cloud portal and at least one virtual machine server containing a Metaverse virtual private network server typically located in a hyperscale data center on a public cloud network, and at least one Metaverse application along with ( Along with) the Metaverse Application Gateway and at least one Metaverse Application Gateway smart device client or network service located in the application environment of a plurality of Metaverse Providers. The Metaverse VPN Server relays communications between the Metaverse VPN Server smart device clients on the Metaverse VPN Server side and the Metaverse Application Gateway. Based on the Metaverse VPN Server smart device client request, the Metaverse VPN Server calls back to the Metaverse Application Gateway as needed. At least one virtual private network channel is enabled and established between the Metaverse Virtual Private Network Server and the Metaverse Application Gateway. At least one virtual private network channel is enabled and established between the Metaverse Virtual Private Network Server and the Metaverse Virtual Private Network Server smart device client. The two virtual private network channels are merged into a single virtual private network channel between the Metaverse VPN Server smart device client and the Metaverse Application Gateway through the Metaverse VPN Server. From this point on, through the Metaverse VPS, all communications between the Metaverse VPS smart device clients and the Metaverse Application Gateway are secure and private. All Metaverse Application Gateway smart device customers along with network services on the Metaverse Application's private LAN are accessible in LAN mode for use by Metaverse Virtual Private Network Server smart device customers. The virtual private network connection of the future. From this point forward, the Metaverse Application Gateway and the Metaverse VPN Server are in standby mode, awaiting future access from Metaverse VPN Server smart device customers in the public cloud on the Internet .

At least one public cloud portal is initially accessed by at least one Metaverse VPN server client to log in and obtain information including the Metaverse VPN server password, the VM server zone name, the Metaverse VPN server Link authentication of Route Server VPN Client Profile and Metaverse VPN Server VPN Client Password. The Metaverse VPN Server VPN Client Profile and the Metaverse VPN Server VPN Client Password can be sent to any authorized Metaverse VPN Server Client for use by Future access. Using these two authentications, authorized Metaverse VPS customers can connect to the target virtual machine server through the public cloud portal, and then connect to the corresponding Metaverse VPS server. After the connection, the first virtual private network channel between the Metaverse VPN server client and the Metaverse VPN server is enabled. Once (or if) appropriate authentication is established, at least one Metaverse Application Gateway in the Metaverse Application's private local area network and at least one Metaverse Virtual Private Network Server in the public cloud will Enable the third virtual private network channel as required. At least one Metaverse virtual private network server in the public cloud will sequentially call back at least one Metaverse application gateway in the private local area network to enable the first virtual private network channel. Once (or if) the first VPN channel is enabled by the Metaverse VPN server, at least one Metaverse application gateway in the Metaverse application's private area network communicates with the Metaverse application gateway in the public cloud. At least one Metaverse virtual private network server establishes the first virtual private network channel. The second VPN channel is also enabled by the Metaverse VPN Server, which is used by Metaverse VPN Server smart device customers. Through the Metaverse VPN Server VPN Client Profile, at least one Metaverse VPN Server Smart Device Client initiates a request for connecting to at least one Metaverse VPN Server to Establishing a third virtual private network channel on demand to prevent at least one Metaverse virtual private network server smart device client from attempting to access the area within the Metaverse application within the private area network of at least one Metaverse application Any Metaverse application gateway smart device client or Metaverse network service on the network. At least one Metaverse virtual private network server in the public cloud will in turn call back at least one Metaverse application gateway in the Metaverse application's private area network to establish a third virtual private network as needed. Private network channels and relays communications from the Internet between Metaverse VPN Server smart device clients and the Metaverse Application Gateway. The Metaverse Application Gateway is located on the Metaverse Application's private local network. The second virtual private network channel established on demand and the third virtual private network channel established on demand are merged into Metaverse Virtual Private Network Server Smart Device Client and Metaverse Application Gateway through Metaverse Virtual A single virtual private network channel for a private network server. From this point on, all communications between the Metaverse VPN Server smart device clients and the Metaverse Application Gateway via the Metaverse VPN Server are secure and private. All Metaverse Application Gateway smart device clients along with network services on the Metaverse Application's private LAN are accessible in LAN mode for smart device clients from the Metaverse Virtual Private Network Server future virtual private network connections. Both the Metaverse Application Gateway and the Metaverse VPN Server are in standby mode, awaiting future access from Metaverse VPN Server smart device customers in the public cloud on the Internet.

In summary, the present invention establishes at least one Metaverse virtual private network server and at least one Metaverse application gateway master-slave in a client-server relationship. Through the public cloud network, at least one Metaverse virtual private network server and at least one Metaverse application gateway communicate with each other privately and securely. The present invention establishes at least one Metaverse virtual private network server smart device client and at least one Metaverse virtual private network server master-slave in a client-server relationship. The present invention establishes a client-server relationship of at least one Metaverse application gateway smart device client, at least one Metaverse application gateway Metaverse network service and at least one Metaverse application gateway master-slave mode. middle. The present invention establishes at least one Metaverse virtual private network server smart device client and at least one Metaverse application gateway master-slave in a client-server relationship. Through the public cloud network, at least one Metaverse virtual private network server smart device client and at least one Metaverse application gateway communicate with each other. Through the public cloud network, at least one Metaverse virtual private network server smart device client and at least one Metaverse application gateway smart device client communicate with each other privately and securely. Through the public cloud network, at least one Metaverse virtual private network server smart device client and at least one Metaverse application gateway Metaverse network service communicate with each other privately and securely.

Virtual private network channels are based on industry standards to ensure privacy and security, as well as anti-obsolescence interoperability and compatibility in communications. Through a VPN connection that is implemented in a private and secure manner, all Metaverse Application Gateway clients, including IoT devices, as well as network services on the private area network, can access the Metaverse VPN servers from Client accesses in LAN mode. Existing technologies rely on cloud-mode access to clients or IoT devices on a private area network through a cloud-based relay server. Unlike the prior art, the present invention only relies on LAN mode access through a virtual private network channel. Due to the industry-recognized strength of virtual private network channels, the access text itself is never and cannot be monitored or logged. Therefore, the present invention is more private and secure in accessing communications than most other technologies provided by the prior art. Network connections are based on the Internet Protocol.

Therefore, the solution is platform agnostic and compatible with all existing fragmented IoT device platforms, whether it is Matter, Apple HomeKit, Google Nest or Amazon Alexa, as long as the IoT device is discoverable by the local network and internet-enabled. In order to further consider security, through the Internet, according to the request from the administrator account of the Metaverse Virtual Private Server customer in the cloud, the Metaverse Virtual Private Network server password, virtual machine server zone name, Link certificates for Metaverse VPN Server VPN Client Profiles and Metaverse VPN Server VPN Client Passwords may be revoked and reissued. The present invention requires future Metaverse application gateway clients, that is, IoT devices, to operate in local network mode instead of operating in cloud mode to achieve absolute privacy and security of users. With the above approach, IoT devices no longer need to provide their own cloud-based relay servers. The corresponding benefits to users are:

A. Break the monopoly of mobile operating system (OS) providers such as Apple and Google on access to applications and IoT devices;

B. Convenience of access from anywhere in the world via the Internet;

C. True access privacy and security;

D. Simultaneous interaction and compatibility with Matter, Apple HomeKit, Google Nest and Amazon Alexa;

E. Lower the entry barrier for IoT device manufacturing because IoT manufacturers no longer need cloud-based relay servers;

F. Re-instill consumer confidence to stimulate future IoT device sales;

G. Open up new vertical applications for the IoT market in secure chat, voice and imaging; and

H. Anti-obsolescence implementation of industrial Internet protocols and communications access in networks.

The invention provides another Metaverse virtual private network server smart device client from anywhere in the world to access the functions of a Metaverse application gateway smart device client or an IoT device at home; while also maintaining access Benefits of convenience, ease of deployment, extreme privacy and security, complete compatibility/interoperability and high performance.

The present invention relates to networking, and in particular to the use of 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 patent applications and their claims. Various modifications to the embodiments and general principles and features described herein will be apparent to those of ordinary skill 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.

Throughout the discussion herein, the term "customer" is interchangeable with "smart device customer." Throughout the discussion in this article, the term "router" is often used interchangeably with "gateway", "access point" (AP), and/or "network address translation" (NAT). ) interchange. "Platform" is often interchangeable with "ecosystem".

The system and method of the present invention solve the following challenges in consumer-oriented environments to enable smart device customers in a wide area network (WAN) to obtain data from a Private Cloud Storage Server (PCSS) or Any private cloud server (Private Cloud Server, PCS) obtains services:

1. Access private cloud servers anytime and anywhere.

2. Use fixed or dynamic Internet Protocol (IP) addresses to access private cloud servers behind the firewall.

3. No public cloud-based routing server is required in the WAN.

4. No need to set up additional routers in the local area network (LAN).

5. Authenticate with the private cloud server.

6. Establish a secure communication channel with the private cloud server.

If these challenges can be met and solved, the deployment of private cloud servers or services will increase exponentially due to plug-and-play simplicity and availability. By not using public cloud-based routing servers, technical and business issues are eliminated. Private cloud servers for storage, remote desktop services, and the Internet of Things (IoT) have become extremely affordable and ubiquitous in private cloud infrastructure.

In a private cloud environment, if there are multiple private cloud servers or services at the same time, it is advantageous to divide the functions of the private cloud server into two functional blocks. Functional blocks include Private Cloud Routing Service (PRS) and Metaverse Network Service (MVNS).

Metaverse Network Services are designed to be managed and accessed by smart device customers over a private network environment (whether wired or wireless). Examples of Metaverse network services include application servers to provide remote desktop protocol (RDP), virtual network computing (VNC), office tools, media players, and another user-specific application program. Metaverse Network Services can also be used as storage servers, which contain multiple terabyte (TB) storage devices serving private clouds. Then, the functions of the private cloud routing services of multiple Metaverse Application Gateways (MVAG) can be aggregated into one Metaverse Application Gateway. The Metaverse Application Gateway is often referred to as a private cloud router.

The systems and methods of the present invention address the following challenges for customers in consumer-facing environments using smart devices over wide area networks capable of managing and accessing Metaverse network services from Metaverse application gateways:

1. Access the Metaverse application gateway anytime, anywhere.

2. Use the Metaverse Application Gateway behind a fixed or dynamic access firewall.

3. No external or public cloud-based routing servers are required in the WAN.

4. No need to set up additional routers in the local network.

5. Authenticate with the Metaverse Application Gateway.

6. Establish a secure communication channel with the private cloud server for management and access.

If the Metaverse Application Gateway can meet the above challenges, heterogeneous private cloud servers from different manufacturers and vendors can be broken down into simpler Metaverse network services, and the private cloud settings can be removed. Complexity of setup and access.

The purpose of the system and method of the present invention is to provide the Metaverse application gateway, Metaverse network services and client architecture without using a routing server. The system and method of the present invention solve the above challenges to allow customers to access Metaverse network services anytime and anywhere. Systems and methods also use fixed or dynamic Internet protocols to access Metaverse network services behind firewalls, requiring no additional router setup or public cloud-based routing servers in the wide area network to interface with Metaverse applications The procedural gateway performs authentication and establishes a secure communication channel directly with Metaverse network services.

As shown in Figure 1, the cloud network infrastructure includes a public cloud 100, a public cloud server 113, a public routing server 112, a public virtual private network (VPN) routing server 114, and a wide area network Smart device client 101, Router_P 102 and Router_S 103 in . Router_S 103 is connected between the local network 105 and the Internet in the public cloud 100 . Router_S 102 connects the local network 104 and the Internet in the public cloud 100 . Smart device clients 106, 107 and private cloud server 108 are behind the local network 104. Smart device clients 109, 110 and 111 are behind local area network 105. Smart device customers can be PCs, laptops, tablets, Tesla dashboards, smartphones, e-book readers, GPS, smart TVs, set-top boxes, MP3 players or any internet-enabled embedded device device.

Smart device clients are represented in the cloud network infrastructure as 101, 106, 107, 109, 110 and 111. Any of the above smart device clients are interchangeable in the discussion of this article. The focus of this article is smart device customer 109, as the representative of this article.

In fact, there are three scenarios in which the smart device client 101, 107 or 109 can connect to the private cloud server 108. First, the smart device client 107 determines whether the target is in a locally accessible local network 104 and decides to connect directly to the private cloud server 108 . Second, the smart device client 101 determines that the target is not within the locally accessible local area network 104 and decides to connect to the public cloud 100 over the wide area network. WAN locates Router_P 102 and LAN 104, and connects to private cloud server 108. Third, the smart device client 109 determines that the target is not in the locally accessible local network 105 and decides to connect to the public cloud 100 in the wide area network through the local network 105 and Router_S 103 .

Smart device client 109 locates Router_P 102 and local area network 104, and connects to private cloud server 108. The first situation and the second situation are two special situations and derivative situations of the third situation. Therefore, it is useful to focus on the third case, which is broader in scope and complexity.

As shown in Figure 2, the cloud network infrastructure includes a public cloud 200, a public cloud server 213, a public routing server 212, a public virtual private network routing server 214, and a private cloud callback server in the wide area network (Private Cloud Call-Back Server, PCCBS) smart device client 201, Router_P 202 and Router_S 203. Router_S 203 connects the local network 205 and the Internet in the public cloud 200 . Router_S 203 is connected between the local network 205 and the Internet in the public cloud 200 . Route server message box (not shown) or client message box message_box_S 215 may be hosted within an email server, text message server, web server, or any type of server. Either type of server can host the services used in the Private Cloud Routing Server (PCRS) 208, Private Cloud Callback Server 216, Private Cloud Routing Server Smart Device Clients 206, 207, and Private Cloud Callback Security messages for exchanging messages between server smart device clients 209, 210, 211, 201, and 221, in which the private cloud routing server 208 and the private cloud callback server 216 serve as servers, and the private cloud routing server smart device client 206 , 207 and private cloud callback server smart device customers 209, 210, 211, 201, 221 as customers. The callback server message box (not shown) or the client message box message_box_S 215 is accessible as well as the private cloud routing server 208 acting as the server and the private cloud callback server 216 or the private cloud routing acting as the client The server smart device clients 206, 207 and the private cloud callback server smart device clients 209, 210, 211, 201, 221 are under the secure and private control. The security and business model of message boxes are well understood and expected by users in the industry. Any message box that is closed for any reason can be immediately replaced or redeployed without compromising communication between servers and customers in the private cloud infrastructure.

Figure 3 shows the first embodiment of the present invention based on the Metaverse application gateway, Metaverse virtual private network server, Metaverse application gateway smart device client and Metaverse virtual private network server smart device Schematic diagram of a cloud network infrastructure for secure connection mechanisms between clients to explore and access public metaverse network services. The connection mechanism between Metaverse VPN Server device clients in the cloud and Metaverse Application Gateway device clients on the private local area network has five stages:

The first stage: Manage the device from the public cloud portal and obtain multiple link certifications;

Phase 2: Pair and register with the Metaverse Virtual Private Network Server from the Metaverse Application Gateway;

The third stage: Establish a plurality of initial virtual private network channels between the Metaverse virtual private network server and the Metaverse application gateway;

Phase 4: Through the Metaverse Virtual Private Server, between the Metaverse Virtual Private Server smart device client and the Metaverse Application Gateway, connect to the Metaverse Application Gateway as required; and

Phase 5: At least one Metaverse Virtual Private Network Server Smart Device Client and at least one Metaverse Application Gateway Smart Device Client, at least one Metaverse Application Gateway Network Service or another Metaverse Virtual Between private network server smart device clients, run multiple vertical peer-to-peer (P2P) private and secure Metaverse virtual private network server smart device client applications.

In the first stage: multiple link authentications are obtained from the public cloud portal management device: first, the public cloud portal management device 377 itself, which is the Metaverse VPS device client 301, logs in to the public cloud portal 330 The Public Cloud Portal Installation Utility (not shown) obtains Metaverse VPN Server Installation Client Certification 379 and Metaverse VPN Server Certification 380. Metaverse VPS device client authentication 379 includes Metaverse VPS client configuration 383 and Metaverse VPS client login 382. Metaverse virtual private network server certification 380 includes Domain_MVVS 375 and Passcode_MVVS 376. Metaverse VPN Server Device Client Authentication 379 and Metaverse VPS Server Authentication 380 are both stored in Public Cloud Portal Device Client 378. The Metaverse VPN Server Authentication 380 is later sent via email to the Metaverse Application Gateway Management Device 373 to connect to the Metaverse Application Gateway 308. The Metaverse VPN Server Device Client Authentication 379 is later sent via email to the Metaverse VPN Server Device Client 321 to connect to the Metaverse VPN Server 316.

In the second phase: pairing and registering with the Metaverse VPN server from the Metaverse Application Gateway: the Metaverse Application Gateway management device 373 uses the MVAG_Device utility 374 to connect from the Metaverse Application The gateway management device 373 initializes and provides the Metaverse application gateway 308. As shown in Figure 3, the Metaverse application gateway 308 includes the MVAG_Device utility 371 and the MVAG_VPN utility 372. The Metaverse application gateway management device 373 is located on the same physical area network 304 as the Metaverse application gateway 308 to perform security purpose settings to avoid hacker attacks on the Internet or wide area network. The Metaverse application gateway management device 373 itself is the Metaverse application gateway smart device client 307 and includes the application utility MVAG_Device utility 374 . The MVAG_Device utility 374 includes an entry for Domain_MVVS 375 and an entry for Passcode_MVVS 376 . The entry of Domain_MVVS 375 is used to set the server area address of the corresponding Metaverse virtual private network server. The entry of Passcode_MVVS 376 is used to set the server password of the corresponding Metaverse Virtual Private Network server. First, the Metaverse Application Gateway Management Device 373 sets up the Metaverse Virtual Private Network Server authentication by setting its domain name through the entries of Domain_MVVS 375 and Passcode_MVVS 376. Metaverse Virtual Private Server Authentication, Domain_MVVS 375 and Passcode_MVVS 376 are used to communicate with the MVAG_Device utility 371 in the Metaverse Application Gateway 308.

In the third phase: Establish a plurality of initial virtual private network channels between the Metaverse VPN server and the Metaverse application gateway: between the Metaverse VPN server 316 and the Metaverse application gateway After the Metaverse Virtual Private Network Server 316 of the gateway 308 is paired and registered, the MVAG_VPN utility 372 is connected to the MVVS_VPN utility 3720, and the third virtual private network between the MVAG_VPN utility 372 and the MVVS_VPN utility 3720 is enabled. aisle. Next, the MVVS_VPN utility 3720 calls back the Metaverse application (MA) 370 to enable the first virtual private network channel between the MVVS_VPN utility 3720 and the MVAG_VPN utility 372 . Metaverse application 370 includes at least one Metaverse application gateway (eg, Metaverse application gateway 308). At least one Metaverse application gateway (eg, Metaverse application gateway 308) includes the MVAG_VPN utility 372. Between the MVVS_VPN utility 3720 and the MVAG_VPN utility 372, the MVVS_VPN utility 3720 can establish a third virtual private network channel as required. Alternatively, between the MVVS_VPN utility 3720 and the MVAG_VPN utility 372, the MVVS_VPN utility 3720 can establish a third virtual private network channel according to the demand, and wait for the Metaverse virtual private network server smart device clients 309, 310, 311 to be established according to the demand. Or the completion of the second virtual private network channel between 321 and the Metaverse virtual private network server 316. Thereafter, from the Internet cloud, between the MVAG_VPN utility 372 and the MVVS_VPN utility 3720, the MVAG_VPN utility 372 can establish a first virtual private network channel. The MVVS_VPN utility 3720 may also enable a second VPN channel between the MVVS_VPN utility 3720 and any Metaverse VPN server device client 301, 309, 310, 311 or 321. Then, based on the needs of any Metaverse VPN Server smart device client 301, 309, 310, 311 or 321, the Metaverse VPN Server 316 is ready to take further action. Within the Metaverse Virtual Private Network Server 316, the MVVS_VPN utility 3720 communicates with the MVVS_Device utility 3710. The MVVS_Device utility 3710 remains in a loop, waiting for future Metaverse Virtual Private Network Server smart device client requests.

In the fourth stage: Through the Metaverse Virtual Private Server, between the Metaverse Virtual Private Server smart device client and the Metaverse Application Gateway, connect to the Metaverse Application Gateway as required: Within the Metaverse virtual private network server 316, the MVVS_VPN utility 3720 communicates with the MVVS_Device utility 3710. The MVVS_VPN utility 3720 remains in a loop, waiting for a request from the Metaverse Virtual Private Network Server smart device client. First, the Metaverse VPS device client 321 registers the Metaverse VPS client authentication with the MVVS_Device utility 3710, including the Metaverse VPS client configuration file and the Metaverse VPN Log in to the server client. The MVVS_Device utility 3710 transmits Metaverse VPN server client authentication and connection requests within the Metaverse VPN server 316 to the MVVS_VPN utility 3720. After registration, the Metaverse Virtual Private Network Server Device Client 321 connects to the MVVS_VPN utility 3720, and between the Metaverse Virtual Private Network Server Device Client 321 and the MVVS_VPN Utility 3720, a second virtual private network is established as required. road passage. Next, between the MVVS_VPN utility 3720 and the Metaverse application 370, the MVVS_VPN utility 3720 establishes a third virtual private network channel as required. Metaverse application 370 includes at least one Metaverse application gateway (eg, Metaverse application gateway 308). At least one Metaverse application gateway (eg, Metaverse application gateway 308) includes the MVAG_VPN utility 372. The second on-demand virtual private network channel and the third on-demand virtual private network channel are merged into a single virtual private network channel between the Metaverse VPN server device client and the MVAG_VPN utility 372 . The MVAG_VPN utility 372 is in the Metaverse application gateway 308.

In Phase 5: At least one Metaverse Virtual Private Network Server Smart Device Client and at least one Metaverse Application Gateway Smart Device Client, at least one Metaverse Application Gateway Network Service or another Metaverse The virtual private network server smart device client operates multiple vertical node-to-node private and secure Metaverse virtual private network server smart device client applications. Through communication paths 322, 324 and 323 respectively, Metaverse VPN server smart device clients 301, 311 and 321 can locate the Metaverse application gateway 308 according to the mechanism disclosed in Figure 8-13. The Metaverse Application Gateway 308 and the Metaverse Virtual Private Network Server 316 build a virtual LAN (VLAN) 340 and a virtual local network 3400, allowing authorized Metaverse Virtual Private Network Server smart devices Clients 301, 311, and 321 join as members of VLAN 340 and VLAN 3400, and connect to Metaverse Application Gateway device client 306, or Metaverse Network Service 328 (e.g., Metaverse Application Gateway Router Network Service), or another Metaverse Virtual Private Server Device Client (not shown), assuming that another Metaverse Virtual Private Server Device Client (not shown) has also successfully connected to MVVS_VPN Utilities 3720. Please refer to Figure 8 for the virtual private network channel and connection process. The Metaverse Virtual Private Network Server smart device client 301 can act as a host to initiate private and secure communications through installed programs. Through the vertical node-to-node private and secure Metaverse VPS smart device client application (not shown) provided by the public cloud portal 330, the Metaverse VPS smart device client 311 or 321 Through the installed program, you can receive communication invitations as a guest and join a private and secure communication session with the Metaverse Virtual Private Network Server smart device client 301.

In the fifth phase, at least one Metaverse application gateway smart device client and the Metaverse virtual private network server smart device client application form a master-slave relationship. The Metaverse VPN Server smart device client application includes application utilities on public cloud networks. Functionality of at least one Metaverse application gateway smart device client is passed to a class code definition of the Metaverse VPN server smart device client application. Vendor-specific software modules or applications are loaded by the Metaverse VPN Server Smart Device Client Application to support corresponding Metaverse Application Gateway smart devices from different manufacturers. Device categories include voice, imaging, human interface devices, Internet protocol cameras, smart locks, smart lightbulbs, remote controls, thermostats, printers, mass storage devices, Bluetooth, and specific applications and specific suppliers, etc.

As shown in Figure 3, when the Metaverse Virtual Private Network Server smart device client 301, as the host, wants to start a communication session, the program installed on the host Metaverse Virtual Private Network Server smart device client first locates, and through Communication path 322 logs into public cloud portal 330. After the Metaverse virtual private network server 316 locates the Metaverse application gateway 308, it joins the virtual local network 340. Metaverse virtual private network server smart device customers commit to join the chat communication as host 301. The program allows the Metaverse Virtual Private Network Server smart device client 301 to create and host communication sessions. The program broadcasts the host session to invite communication guests 321. Afterwards, the program starts scanning the identifiable guest Metaverse VPN Server smart device client 321. Once the guest is authorized, the Metaverse VPN Server Smart Device Client 301 can act as a host to initiate private and secure communications with the authorized guest Metaverse VPN Server Smart Device Client 321. Private and secure communications include video, voice, text or applications. An application can be a program, utility, operation, or transaction that is identifiable to the host and guests.

If Metaverse VPN Server Smart Device Client 311 or 321 wishes to join the communication session as a guest, the program installed on the guest Metaverse VPN Server Smart Device Client first locates and communicates via communication path 324 or 323 respectively. Log in to the public cloud portal 330. After the Metaverse virtual private network server 316 locates the Metaverse application gateway 308, it joins the virtual local area network 340 under the server. The Metaverse Virtual Private Network Server smart device client 311 or 321 commits to join the communication as a guest. The program waits for a communication invitation. Once the communication invitation is received, the Metaverse VPN server smart device client 311 or 321 can join the communication session as a guest. Next, the program starts scanning for recognized hosts. After identifying the host, the program logs in and authenticates through the communication prompted by the host. Once authenticated, the Metaverse VPN server smart device client 311 or 321 can join the communication session. The Metaverse Virtual Private Network Server Smart Device Client 311 or 321 initiates private and secure communication with the Metaverse Virtual Private Network Server Smart Device Client 301 as a guest. Private and secure communications include video, voice, text or applications. An application can be a program, utility, operation, or transaction that is identifiable to both the host and the guest.

In another embodiment of the present invention, under the Metaverse Application Gateway and the Metaverse VPS, the Metaverse VPS smart device client can communicate with the physical area network LAN1 350 or Establish private and secure communications with any service reachable on VLANs 340 and 3400. As shown in Figure 3, once the Metaverse virtual private network server smart device client 301, 311 or 321 locates and logs into the public cloud portal 330, through the secure communication path 325, the Metaverse application gateway and Metaverse Under the universe virtual private network server, it can access any metaverse network service 328 reachable on the physical local area network LAN1 350 and LAN2 360 and the virtual local area network 340 and 3400. Yuanverse network services include the execution of voice, video, live or archived information and applications, social media, messaging, email, storage, backup, calendar, contacts, synchronization, sharing, remote desktop, Internet of Things, etc. .

Multiple entities are introduced to allow secure communication paths 325, and include, but are not limited to: administrators, management devices, Metaverse application gateway utilities, Metaverse Virtual Private Network Server utilities, Metaverse Universe application gateway smart device customers, Metaverse virtual private network server smart device customers. The above entities are defined as follows. Utilities are utilities that operate within the Metaverse Application Gateway. The management device is the device used by administrators to configure the Metaverse Application Gateway. The Metaverse Application Gateway Smart Device Client is the device used by invitees to communicate with the Metaverse Application Gateway. Invitees are entities invited by the administrator to access Metaverse Application Gateway services and resources. An invitee device is a Metaverse Application Gateway smart device client used by the invitee to communicate with the Metaverse Application Gateway.

Multiple terms are introduced, including Passcode_MVVS, Domain_MVVS_Client, MVVS_Client_Profile and MVVS_Client_Login. The above terms are defined below. Passcode_MVVS is the password generated by the public cloud portal for the corresponding Metaverse Virtual Private Network Server 316. Domain_MVVS_Client is a regional address authenticated by the Metaverse Virtual Private Network Server formed by the public cloud portal Passcode_MVVS and Domain_MVVS. MVVS_Client_Profile is the virtual private network profile of the Metaverse Virtual Private Network Server smart device client connected to the corresponding Metaverse Virtual Private Network Server 316. MVVS_Client_Login is the virtual private network login password for the Metaverse virtual private network server smart device client to connect to the corresponding metaverse virtual private network server 316. MVVS_Client_Profile and MVVS_Client_Login together form the Metaverse Virtual Private Network Server Authentication.

Other terms not related to Metaverse Application Gateway are: Metaverse Application and Virtual LAN Subnetwork, as defined below. The Metaverse Application is a private network subsystem, including a network router, a private local area network, the Metaverse Application Gateway, at least one Metaverse Network Service and at least one Metaverse Application Gateway smart device client. The VLAN subnet is the subnet configuration of the Metaverse Application Gateway Virtual Private Network. For security purposes, designated private subnets are configurable and changeable.

The device client 301 itself is the Metaverse virtual private network server smart device client, which includes an application utility and a public cloud portal device client utility 378. The Public Cloud Portal Installation Client Utility 378 includes Metaverse VPN Server Installation Client Authentication 379 and Metaverse VPN Server Authentication 380. Metaverse VPS device client authentication 379 includes Metaverse VPS client configuration and Metaverse VPS client login. Metaverse virtual private network server certification 380 includes Domain_MVVS and Passcode_MVVS.

A typical Metaverse Virtual Private Network Server smart device client 321 includes the MVVS_Device_Client utility 381. The MVVS_Device_Client utility 381 includes Metaverse Virtual Private Server client configuration 383 and Metaverse Virtual Private Server client login 382. Metaverse virtual private network server client configuration 383 is used to connect to the corresponding metaverse virtual private network server 316. The Metaverse Virtual Private Network Server Client Login 382 is used to log in to the Metaverse Virtual Private Network Server 316. Metaverse virtual private network server 316 includes MVVS_Device utility 3710 and MVVS_VPN utility 3720. The MVVS_Device utility 3710 is used to communicate with the Metaverse Application Gateway Management Device 373. The MVVS_VPN utility 3720 can communicate with the Metaverse application gateway 308 through at least one virtual private network channel. The Metaverse Virtual Private Server 316 acts as an intermediary to relay communications between the Metaverse Virtual Private Server smart device clients 321, 301, 311 and the Metaverse Application Gateway 308, and according to the Metaverse Virtual The private network server smart device client requests and calls back to the Metaverse application gateway 308 as needed.

Figure 4 is a schematic diagram of the second embodiment of the present invention. The Metaverse application gateway 408 is connected to the LAN 404 of the Router_P 402 in a manner similar to the way the private cloud routing server 208 is connected to the LAN 204 of the Router_P 202 in Figure 2 . The Metaverse Application Gateway 408 is also connected to the downstream physical area network LAN2 460. Metaverse network services 436 and Metaverse application gateway smart device clients 435 are connected downstream. Accessed via communications path 426, Metaverse network service 436 may connect to Metaverse application gateway 408 via local area network 434. As long as the virtual local area network 440 and the physical local area network LAN1 450 and LAN2 460 can be used by the Metaverse application gateway 408 and the Metaverse virtual private network server smart device across the cloud through the metaverse virtual private network server 416 Clients 411, 410, 409, 401 and 421 explore and access, all Metaverse web services 428 and 436 and Metaverse Application Gateway smart device clients 406, 407 and 435 become accessible.

Figure 5 is a schematic diagram of an embodiment of the present invention. The private substance gateway 508 is connected to the LAN 504 of the private LAN router 502 in a manner similar to the way the private cloud routing server 208 is connected to the LAN 204 of Router_P 202 in Figure 2 . As long as the private metaverse-1 550 and the physical area network 504 can be connected by the private physical gateway 508 and the private cloud virtual private network server across the cloud through the virtual machine server-1 531 and the private cloud virtual private network server 516 Smart device customers (e.g. VR glasses 551, laptop 552, smartphone 553, tablet 554, VR glasses 561, laptop 562, smartphone 563 and Tesla dashboard 564) explore and access , all private network services (not shown) and private physical gateway smart device clients 521, 522, 523, 524, 525 and 526 become accessible.

Figure 6 is a schematic diagram of the third embodiment of the present invention. Metaverse application gateway 680 is connected to the private area network 604 of the private area network router 602 in a manner similar to the third metaverse application gateway 308 being connected to the private area network 304 of the router 302 . As long as the Metaverse Application-1 650 and the physical LAN 604 are connected through the virtual machine server 631 and the Metaverse VPS 616 across the cloud Metaverse VPS smart device clients (e.g. virtual reality Glasses 651, laptop 652, smartphone 653, tablet 654, virtual reality glasses 661, tablet 662, smartphone 663 and Tesla dashboard 664) and Metaverse application gateway 608 exploration and access , Metaverse Application Gateway 608, all Metaverse network services (not shown), and Metaverse Application Gateway smart device clients 6250, 6251, 6252, and 622 become accessible. There may be many Metaverse providers in the public cloud 600. Each provider establishes Metaverse Cloud Provider-1 641, Metaverse Cloud Provider-2 642, Metaverse Cloud Provider-3 644, and Metaverse Cloud Provider-N 643. In Metaverse Cloud Provider-1 641, through the Metaverse Provider Portal-1 630, multiple Metaverse applications can be deployed, such as Metaverse Application-1 650, Metaverse Application-2 6320, Metaverse Application App-3 6330 and Metaverse App-N 6340. There is a corresponding virtual machine server-1 630 in the Metaverse application-1 650, which contains the Metaverse virtual private network server 616. Metaverse virtual private network server 616 is logically connected to application virtual network-1 640, which houses router 602, private area network 604. Beneath the application virtual network-1 640, there are multiple physical and logical devices, resources and services, such as the Metaverse application gateway 608, live streaming events 6250, 6251 and 6262, and archived content server 622. Live Streaming Event-A 6250, Live Streaming Event-B 6251, and Live Streaming Event-C 6252 are a set of Internet Protocol cameras set up by Metaverse Provider-1 (not shown) to create a specific Metaverse Applications (e.g., Metaverse Application-1 650) to stream specific live events for specific groups of Metaverse subscribers. Via the Metaverse VPS device client, Tesla dashboard 664, smartphone 663, tablet 662 and virtual reality glasses 661, or via other device clients under the guest area network router 603 (including Laptop 652, smartphone 653, tablet 654 and virtual reality glasses 651), Metaverse subscribers can access Metaverse event content. As shown in Figure 6, Metaverse Cloud Provider-1 641 is scalable and developable. In the public cloud 600, there may be multiple Metaverse Provider Clouds coexisting with each other, such as Metaverse Cloud Provider-1 641, Metaverse Cloud Provider-2 642, Metaverse Cloud Provider-3 644, and Metaverse Cloud Provider-3 644. ER-N 643. In the same Metaverse Cloud Provider-1 641, there can be multiple Metaverse Applications deployed by the same Metaverse Provider Portal, such as Metaverse Application-1 650, Metaverse Application-2 6320, Metaverse App-3 6330 and Metaverse App-N 6340. Metaverse providers can provide their subscribers with private and secure access to devices, services, content or events with the help of this invention. Types of devices, services, content or events include media content services, live event streaming, games, virtual tours, virtual museums, private conversations in text, voice, images, cryptocurrency transactions, virtual reality (VR) )/Augmented Reality (AR) experience and virtual avatar, etc.

Figure 7 is a flow chart of a communication process of a node-to-node connection mechanism between a private cloud relay server and a private cloud callback server smart device client through a cloud network according to an embodiment of the present invention. According to the present invention, a private cloud callback server smart device client does not require a public VPN route server to connect and access the private cloud route server 728, or another private cloud callback server smart device client. , or another private cloud routing server smart device client, or through network services under a cloud network server. As shown in Figure 7, without going through the public routing server 112 or the public virtual private network routing server 114 of Figure 1, the private cloud callback server smart device client 1 725 and the private cloud routing server on the cloud network 728 can communicate with each other. First, Private Cloud Callback Server Smart Device Client 1 725 requests a connection to the Private Cloud Callback Server Device Utility (Server part)724. The Internet Protocol address and port of the private cloud callback server smart device client 1 725 remains active with the PCCBS_Device utility 724. Through a callback server message box (not shown), the private cloud callback server installation utility (server part) 724 receives the registration. Next, also through the client message box message_box_S 215 in Figure 2, the private cloud callback server smart device client 1 725 requests the private cloud callback server device utility (server part) 724 with the PCCBS_VPN utility (client part) 723 link. The PCCBS_VPN utility (server part) 724 receives the request via a callback server message box (not shown) and notifies the private cloud callback server smart device client 1 725 of the Internet in TCP/User Data Message Protocol Route protocol address and port capabilities and its connection intent to the PCCBS_VPN utility (client part) 723 (step 703). Next, the PCCBS_VPN utility (client part) 723 replies with its own registration to the PCCBS_VPN utility (server part) 724. Registration includes the Internet Protocol address and port capabilities of the PCCBS_VPN utility (client part) 723 in TCP/User Data Message Protocol. The Internet Protocol address and port capabilities of the private cloud routing server installation client 2 726 remain active in connection with the PCCBS_VPN utility (server part) 724 . Next, via communication path 705 , via a Callback Server message box (not shown), the PCCBS_VPN utility (server portion) 724 uses the Internet Protocol in TCP/User Data Message Protocol of the PCRS_VPN utility 722 Address and port capabilities respond to private cloud callback server smart device client 1 725. PCRS_VPN utility 722 initiates node-to-node communication to connect to PCCBS_VPN utility 723. Afterwards, PCCBS_Device utility 724 begins listening in loop 702 for device client requests from private cloud callback server smart device client 1 725 . Once the private cloud callback server smart device client 1 725 initiates a communication request to the PCCBS_Device utility 724, it establishes a node-to-node communication channel 706 with the PCCBS_Device utility 724. This in turn triggers another node-to-node communication between PCCBS_VPN utility 723 and PCRS_VPN utility 722. From this point on, the private cloud callback server smart device client 1 725 is connected to the PCRS_VPN utility 722, and in turn can access any private cloud route server device client 720 or network service (not shown). Node-to-node communication is enabled between the private cloud callback server smart device client 1 725 and the PCRS_VPN utility 722. Private Cloud Callback Server Smart Device Client 1 725 can securely connect to the Virtual Private Area Network on the Private Cloud Route Server Private Area Network. Private cloud callback server smart device client 1 725 can access any private cloud routing server smart device client accessible under the private cloud routing server private area network (for example, private cloud route server device client 2 726 ) or private network services (not shown). Through the same connection mechanism as shown in Figure 7, the other private cloud callback server smart device clients 201, 221, 209, 210, 211 of Figure 2 can connect to the private substance gateway. Once any pair of private cloud routing server smart device clients and private cloud virtual private network server smart device clients are connected to the virtual area network 240 and virtual area network of the private cloud routing server 728 and the private cloud callback server 727 2400, which enables private and secure communications between them for text, voice, or video communications.

Figure 8 shows an embodiment of the present invention through the cloud network on the Metaverse Application Gateway, the Metaverse Virtual Private Network Server, the Metaverse Application Gateway Smart Device Client and the Metaverse Virtual Private Network Server Intelligence Schematic diagram of a communication process of the node-to-node connection mechanism between device clients. The present invention discloses that Metaverse Virtual Private Network Server smart device clients do not need a public cloud routing server to connect and access the server Metaverse Application Gateway 828, Metaverse Virtual Private Network Server 827, or otherwise. A Metaverse application gateway smart device client, or through network services under a cloud network server. As shown in Figure 8, without going through the public routing server 112 or the public VPN routing server 114 of Figure 1, the Metaverse VPN server on the cloud network installs the client 1 825 and the Metaverse application Gateways 828 can communicate with each other. Unlike the prior art of Figure 7, initially, one of the Metaverse VPN server device clients (public cloud portal management device 850) connects to the public cloud portal 851 (circle 1 and step 803). The public cloud portal 851 is a cloud-based public cloud portal that includes the PCP_Device utility 847. The public cloud portal management device 850 obtains Metaverse VPS server authentication and Metaverse VPS client authentication from the PCP_Device utility 847 . The Metaverse Virtual Private Server certification includes the Metaverse Virtual Private Server area Domain_MVVS and the Metaverse Virtual Private Server password Passcode_MVVS. Yuanverse virtual private network server customer authentication includes the customer login profile MVVS Client Profile and the customer-configured login password MVVS Client Login. The Metaverse VPN server certificate is sent to the Metaverse application gateway management device 820 via email or other means. Metaverse VPN Server Client Authentication is sent to authorized Metaverse VPN Server Device Client (e.g. Metaverse VPN Server Device Client 1 825) for use with the Metaverse Application Gateway A node-to-node connection to one of the server device clients, such as Metaverse Application Gateway Device Client 2 826 on the private local area network of Metaverse Application Gateway 828 . The public cloud portal 851 contains at least one PCP_Device utility (eg, PCP_Device utility 847). At least one PCP_Device utility contains at least one virtual machine server (eg virtual machine server 832). At least one virtual machine server includes at least one Metaverse virtual private network server (eg, Metaverse virtual private network server 827). At least one Metaverse virtual private network server includes the MVVS_Device utility 824 and the MVVS_VPN utility 823. The virtual machine server 832 together with the Metaverse virtual private network server 827 form a one-to-one correspondence with the Metaverse application gateway 828 deployed in the private area network. PCP_Device utility 847 is a scalable public cloud portal and may correspond to at least one virtual machine server (eg, virtual machine server 832) and at least one Metaverse virtual private network server (eg, metaverse virtual private network Server 827).

First, after receiving the Metaverse Virtual Private Network Server Authentication, the Metaverse Application Gateway Management Device 820 initializes and provides server authentication to the Metaverse Application Gateway 828 through the MVAG_Device utility 821 (circle 2 and step 800). Next, the MVAG_Device utility 821 passes the information within the Metaverse application gateway 828 to the MVAG_VPN utility 822. Through TCP/User Data Message Protocol, it registers the Metaverse Virtual Private Server authentication information containing Domain_MVVS and Passcode_MVVS to the MVVS_VPN utility 823 (circle 4 and step 801). The MVVS_VPN utility 823 calls back to the Metaverse application 852 (circle 3 and step 805). Metaverse application 852 includes at least one Metaverse application gateway (eg, Metaverse application gateway 828). At least one Metaverse application gateway includes the MVAG_VPN utility 822 to enable the first virtual private network channel between the MVVS_VPN utility 823 and the MVAG_VPN utility 822 . Afterwards, between the MVAG_VPN utility 822 and the MVVS_VPN utility 823, the MVAG_VPN utility 822 establishes the first virtual private network channel (circle 5 and step 813). After registration, the MVAG_VPN utility 822 connects to the MVVS_VPN utility 823 and enables a third virtual private network channel between the MVAG_VPN utility 822 and the MVVS_VPN utility 823 as needed. Between the MVVS_VPN utility 823 and the MVAG_VPN utility 822, the MVVS_VPN utility 823 can establish a third virtual private network channel as required (circle 6 and step 807). Alternatively, between the MVVS_VPN utility program 823 and the MVAG_VPN utility program 822, the MVVS_VPN utility program 823 can establish a third virtual private network channel as required, and wait for the completion of the second virtual private network channel established as required (circle 10 and step 806) . The MVVS_VPN utility 823 also enables the MVVS_VPN utility 823 and any Metaverse VPN Server smart device client from the cloud over the Internet (such as Metaverse VPN Server Device Client 1 825 or Metaverse VPN Server The second virtual private network channel (circle 9 and step 845 or 846) between the server and client 3 853). Then, upon request from any Metaverse VPN server device client (for example, Metaverse VPN server device client 1 825) from the cloud on the Internet, the Metaverse VPN server 827 is ready. Take further action. Within the Metaverse Virtual Private Network Server 827, the MVVS_VPN utility 823 communicates with the MVVS_Device utility 824. The MVVS_Device utility 824 remains in a loop, waiting for a request from the Metaverse Virtual Private Network Server smart device client (circle 7 and step 802). First, Metaverse VPS Device Client 1 825 registers Metaverse VPS Client authentication to the MVVS_Device utility 824 (circle 8 and step 804 or 814). Metaverse virtual private network server client authentication includes MVVS Client Profile and MVVS Client Login. The MVVS_Device utility 824 passes Metaverse VPN server client authentication and Metaverse VPN server 827 internal connection requests to the MVVS_VPN utility 823 . After registration, the Metaverse Virtual Private Network Server Installation Client 1 825 connects to the MVVS_VPN utility 823, and between the Metaverse Virtual Private Network Server Installation Client 1 825 and the MVVS_VPN utility 823, a second virtual machine is created as required. Private network channel (circle 10 and step 806 or 816). Next, between the MVVS_VPN utility 823 and the Metaverse application 852, the MVVS_VPN utility 823 establishes a third virtual private network channel as required (circle 6 and step 807). Metaverse application 852 includes at least one Metaverse application gateway (eg, Metaverse application gateway 828). At least one Metaverse application gateway contains the MVAG_VPN utility 822. Assuming that another Metaverse Virtual Private Network Server Device Client (e.g., Metaverse Virtual Private Network Server Device Client 3 853) has also successfully connected to the MVVS_VPN utility 823, the first client created as required in Circle 10 and Step 806 The two virtual private network channels and the third virtual private network channel established on demand in circle 6 and step 807 are merged into a single virtual private network between the Metaverse virtual private network server device client 1 825 and the MVAG_VPN utility 822 network channel, and connect to the Metaverse Application Gateway Device Client 2 826 (circle 11 and step 811), or the Metaverse Application Gateway Network Service 836 (circle 11 and step 831), or another metaverse Universe VPN Server Device Client (eg, Metaverse VPN Server Device Client 3 853) (circle 10 and step 816). Therefore, the Metaverse Virtual Private Network Server Device Client 1 825 and the Metaverse Virtual Private Network Server Device Client 3 853 form a node-to-node private and secure communication channel between them. Communication channels are the basis for further secure chat applications in text, voice and video, including cryptocurrency transactions.

Compared with the prior art in Figure 7, the present invention is more scalable and developable because it introduces some new entities, including public cloud portal 851, PCP_Device utility 847, virtual machine server 832, metadata Universe application 852, public cloud portal management device 850, Metaverse application gateway management device 820, Metaverse VPS server authentication and Metaverse VPS client authentication. It first connects to the public cloud portal 851, then connects to at least one MVVS_Device utility (eg, MVVS_Device utility 824), then connects to at least one virtual machine server (eg, virtual machine server 832), then connects to at least one element A universe virtual private network server (e.g., metaverse virtual private network server 827), which in turn is connected to at least one metaverse application (e.g., metaverse application 852), which is in turn connected to at least one metaverse application gateway (e.g., Metaverse Application Gateway 828), and then connects to at least one Metaverse Application Gateway Device Client (e.g., Metaverse Application Gateway Device Client 2 826), or connects to the Metaverse Application Gateway server network service (such as Metaverse Application Gateway Network Service 836), or to another Metaverse VPN Server Device Client (such as Metaverse VPN Server Device Client 3 853). The public cloud portal management device 850 begins to obtain the Metaverse virtual private network server authentication and client authentication from the public cloud portal 851 . The Metaverse VPS credentials are then sent to the Metaverse Application Gateway Manager 820 to set up the Metaverse Application Gateway 828 with the virtual machine server 832 located within the public cloud portal 851 The link corresponding to the Metaverse virtual private network server 827. Furthermore, at least three virtual private network channels are bound together before the last two virtual private network channels form a single virtual private network channel for a vertical node-to-node private and secure metaverse virtual private network. Metaverse Virtual Private Network Server Device Client 1 825 and Metaverse Application Gateway Device Client 2 826 in the Route Server Smart Device Client Application, Metaverse Application Gateway Network Service 836 or another Metaverse Node-to-node communication between Universe VPS device clients (such as Metaverse VPS device client 3 853).

Figure 9 shows an embodiment of the present invention based on the server farm, computer resource aggregation and virtual machine server through the cloud network in the Metaverse Application Gateway, Metaverse Virtual Private Network Server, Metaverse Application Gateway A flow chart of a communication process of the node-to-node connection mechanism between smart device clients and Metaverse virtual private network server smart device clients. Further, by adding a server farm 930 and a computer resource aggregation 931, Figure 9 extends Figure 8 to illustrate the implementation of the Metaverse application gateway connection point mechanism in a hyperscale data center. The hyperscale data center has at least one server farm (eg, server farm 930), at least one computer resource aggregation (eg, computer resource aggregation 931), at least one private cloud portal (eg, private cloud portal 951), and at least one virtual machine Server (e.g. virtual machine server 932). The virtual machine servers 932 are scalable in number and size. In the corresponding virtual machine server (such as virtual machine server 932), a hyperscale data center or service provider can build and deploy at least one private cloud portal (such as private cloud portal 951) and a large number of independent Metaverse virtual machines. A private network server (e.g., Metaverse Virtual Private Network Server 927) to serve the corresponding Metaverse Application Gateway (e.g., Metaverse Application Gateway 928) and the corresponding Metaverse Application Gateway Smart device clients (e.g. Metaverse Application Gateway Device Client 2 926). Essentially, regardless of whether there is a topology of computer resource aggregation 931 and server farm 930 , the communication between the Metaverse virtual private network server smart device client 1 925 and the Metaverse application gateway smart device client 2 926 The group pairing of the relationship is built and deployed by the Metaverse provider responsible for maintaining the virtual machine server 932. For example, a possible business model is for an Internet Metaverse provider to offer a large number of users to host their private and secure Metaverse virtual private network servers 927 in a virtual machine server 932 . In addition, a separate private and secure Metaverse Application Gateway 928 is also provided to allow Metaverse providers to install the Metaverse Application Gateway 928 in their private local networks. Through the present invention, Metaverse subscribers can create Metaverse Virtual Private Network Server smart device clients (such as Metaverse Virtual Private Network Server smart device clients 1 925) from anywhere (such as smartphones, tablets or Tesla Dashboard) and Metaverse Application Gateway Smart Device Customers (e.g. Metaverse Application Gateway Smart Device Customer 2 926) (e.g. laptops, IoT devices, network attached storage devices, set-top boxes, Node-to-node communication between smart devices or media servers) on the Metaverse provider's private and secure local area network. Figure 9 shows that the Metaverse Virtual Private Network Server smart device client of the present invention (such as the Metaverse Virtual Private Network Server smart device client 1 925) does not require a public cloud routing server to connect to and access the server. Metaverse Application Gateway 928, Metaverse Virtual Private Network Server 927, or another Metaverse Application Gateway smart device client (e.g., Metaverse Application Gateway Smart Device Client 2 926), or via the cloud Network services under the server (not shown). As shown in Figure 9, without going through the public routing server 112 or the public VPN routing server 114 in Figure 1, the Metaverse Virtual Private Network Server smart device client 1 925 and Metaverse in the cloud network Universe application gateways 928 can communicate with each other. First, the Metaverse VPN server management device 950 is one of the Metaverse VPN server smart device clients and is connected to the private cloud portal 951 (circle 1 and step 903). The private cloud portal 951 is a cloud-based public cloud portal that includes the PCP_Device utility 947. The Metaverse VPS management device 950 obtains the Metaverse VPS server authentication and the Metaverse VPS client authentication from the PCP_Device utility 947 . The Metaverse Virtual Private Server certification includes the Metaverse Virtual Private Server area Domain_MVVS and the Metaverse Virtual Private Server password Passcode_MVVS. Yuanverse virtual private network server customer authentication includes the customer login profile MVVS Client Profile and the customer-configured login password MVVS Client Login. The Metaverse VPN server certificate is sent to the Metaverse application gateway management device 920 via email or other means. Metaverse VPN Server Client Authentication is sent to authorized Metaverse VPN Server Device Client (e.g. Metaverse VPN Server Device Client 1 925) for use with the Metaverse Application Gateway A node-to-node connection to one of the server device clients, such as Metaverse Application Gateway Device Client 2 926 on the private area network of Metaverse Application Gateway 928 . The public cloud portal 951 contains at least one PCP_Device utility (eg, PCP_Device utility 947). At least one PCP_Device utility includes at least one virtual machine server (eg, virtual machine server 932). At least one virtual machine server includes at least one Metaverse virtual private network server (eg, Metaverse virtual private network server 927). At least one Metaverse virtual private network server includes the MVVS_Device utility 924 and the MVVS_VPN utility 923. The virtual machine server 932 together with the Metaverse virtual private network server 927 form a one-to-one correspondence with the Metaverse application gateway 928 deployed in the private area network. PCP_Device utility 947 is an extensible public cloud portal and may correspond to at least one virtual machine server (eg, virtual machine server 932) and at least one Metaverse virtual private network server (eg, metaverse virtual private network Server 927).

First, after receiving the Metaverse Virtual Private Network Server Authentication, the Metaverse Application Gateway Management Device 920 initializes and provides server authentication to the Metaverse Application Gateway 928 through the MVAG_Device utility 921 (circle 2 and step 900). Next, the MVAG_Device utility 921 passes the information within the Metaverse application gateway 928 to the MVAG_VPN utility 922. Through TCP/User Data Message Protocol, it registers the Metaverse Virtual Private Server authentication information containing Domain_MVVS and Passcode_MVVS to the MVVS_VPN utility 923 (circle 4 and step 901). After registration, the MVAG_VPN utility 922 connects to the MVVS_VPN utility 923, and a third virtual private network channel is enabled between the MVAG_VPN utility 922 and the MVVS_VPN utility 923. Next, the MVVS_VPN utility 923 calls back to the Metaverse application 952 (circle 3 and step 905). Metaverse application 952 includes at least one Metaverse application gateway (eg, Metaverse application gateway 928). At least one Metaverse application gateway includes the MVAG_VPN utility 922 to enable the first virtual private network channel between the MVVS_VPN utility 923 and the MVAG_VPN utility 922 . Between the MVVS_VPN utility 923 and the MVAG_VPN utility 922, the MVVS_VPN utility 923 establishes a third virtual private network channel as required (circle 6 and step 907). It is also possible to establish a third virtual private network channel as required between the MVVS_VPN utility program 923 and the MVAG_VPN utility program 922, and wait for the completion of the second virtual private network channel established as required (circle 10 and step 906). Afterwards, between the MVAG_VPN utility 922 and the MVVS_VPN utility 923, the MVAG_VPN utility 922 establishes the first virtual private network channel (circle 5 and step 913). The MVVS_VPN utility 923 also enables a second virtual connection between the MVVS_VPN utility 923 and any Metaverse Virtual Private Server smart device client (eg, Metaverse Virtual Private Server Device Client 1 925 ) from the cloud over the Internet. Private network channel (circle 9 and step 945). Then, according to the needs of any Metaverse VPN server device client (for example, Metaverse VPN server device client 1 925) from the cloud on the Internet, the Metaverse VPN server 927 is ready Take further action. Within the Metaverse Virtual Private Network Server 927, the MVVS_VPN utility 923 communicates with the MVVS_Device utility 924. The MVVS_Device utility 924 remains in a loop, waiting for a request from the Metaverse Virtual Private Network Server smart device client (circle 7 and step 902). First, Metaverse VPS Device Client 1 925 registers Metaverse VPS Client authentication to the MVVS_Device utility 924 (circle 8 and step 904 or 914). Metaverse virtual private network server client authentication includes MVVS Client Profile and MVVS Client Login. The MVVS_Device utility 924 passes Metaverse VPN server client authentication and Metaverse VPN server 927 internal connection requests to the MVVS_VPN utility 923 . After registration, the Metaverse Virtual Private Network Server Installation Client 1 925 connects to the MVVS_VPN utility 923, and between the Metaverse Virtual Private Network Server Installation Client 1 925 and the MVVS_VPN utility 923, a second virtual machine is created as required. Private network channel (circle 10 and step 906 or 916). Next, between the MVVS_VPN utility 923 and the Metaverse application 952, the MVVS_VPN utility 923 establishes a third virtual private network channel as required (circle 6 and step 907). Metaverse application 952 includes at least one Metaverse application gateway (eg, Metaverse application gateway 928). At least one Metaverse application gateway contains the MVAG_VPN utility 922. The second virtual private network channel established on demand in circle 10 and step 906 and the third virtual private network channel established on demand in circle 6 and step 907 are merged into the Metaverse virtual private network server device client A single virtual private network channel between 1 925 and the MVAG_VPN utility 922, and connecting to the Metaverse Application Gateway device client 2 926 (circle 11 and step 911), or the Metaverse Application Gateway Network Service ( Not labeled) (circle 11 and step 911).

Figure 10 is a flow chart of a communication process for the public cloud portal management device to register to the public cloud portal according to the embodiment of the present invention. First, from the wide area network, the private cloud portal management device starts the private cloud portal device utility (step 1000). Next, the "Register Public Cloud Portal" command on the private cloud portal device utility is selected (step 1001). Metaverse VPS server authentication and Metaverse VPS client authentication are required (step 1002). The Metaverse Virtual Private Server certification includes the Metaverse Virtual Private Server area Domain_MVVS and the Metaverse Virtual Private Server password Passcode_MVVS. Yuanverse virtual private network server customer authentication includes the customer login profile MVVS Client Profile and the customer-configured login password MVVS Client Login. The Metaverse VPS certificate containing Domain_MVVS and Passcode_MVVS is sent to the Metaverse Application Gateway Management Device (step 1003). Metaverse Virtual Private Server Client Authentication including MVVS Client Profile and MVVS Client Login is sent to the MVVS_Device client (step 1004) for the target Metaverse Application Gateway device client, Metaverse Application Gateway Network service or another Metaverse Virtual Private Server installation client.

At the same time, the PCP_Device utility starts accepting commands from the private cloud portal management device to register with the private cloud portal (step 1010). The Metaverse VPN Server Authentication and the Metaverse VPN Server Client Authentication are generated or retrieved by the PCP_Device utility (step 1011). Next, both certificates are sent back to the private cloud portal management device (step 1040).

Figure 11 is a flow chart of a communication process of initializing and configuring the Metaverse application gateway management device according to an embodiment of the present invention. As shown in Figure 11, first, from the Metaverse Application Gateway LAN, the Metaverse Application Gateway management device opens the MVAG_Device utility (step 1101). Therefore, the Metaverse application gateway is discovered and selected on the local network (step 1102). Next, the "Initialization and Configuration" command on the MVAG_Device utility is selected (step 1103). Therefore, by setting the Metaverse VPN Server Authentication containing the Metaverse VPN Server Domain Domain_MVVS and the Metaverse VPN Server Passcode Passcode_MVVS as the only Metaverse Application Gateway Identity, the Metaverse VPN Server The universe application gateway is configured (step 1104). The Metaverse VPN server authentication is passed to the MVAG_Device utility (step 1140).

The Metaverse Virtual Private Server authentication (Domain_MVVS, Passcode_MVVS) is accepted (step 1110), and the identity of the Metaverse Application Gateway is stored (step 1111). Next, the Metaverse application gateway is registered to the Metaverse virtual private network server as the corresponding client (step 1112).

Figure 12 shows the link from the MVVS_VPN utility to the MVAG_VPN utility and the link between the Metaverse virtual private network server device client and the Metaverse application gateway device client in the private area network according to the embodiment of the present invention. Flowchart of a communication process linking the MVVS_VPN utility to the MVAG_VPN utility. First, the MVAG_VPN utility uses Metaverse Virtual Private Network Server authentication to connect to the MVVS_VPN utility over the WAN (step 1200). Over the wide area network, the MVVS_VPN utility accepts the Metaverse VPN server authentication from the MVAG_VPN utility (step 1210). Then, if necessary, the MVVS_VPN utility sends further links or update information to the MVAG_VPN utility (steps 1211 and 1241). If necessary, the MVAG_VPN utility receives further link or update information from the MVVS_VPN utility (step 1201). Next, the MVVS_VPN utility calls back to the MVAG_VPN utility to enable the first virtual private network channel (steps 1212 and 1242). The MVAG_VPN utility connects to the MVVS_VPN utility to enable the third virtual private network channel (step 1202). The MVAG_VPN utility connects to the MVVS_VPN utility to establish a first virtual private network channel from the MVAG_VPN utility to the MVVS_VPN utility (steps 1203 and 1243). The MVVS_VPN utility establishes a third virtual private network channel from the MVVS_VPN utility to the MVAG_VPN utility (step 1213). Next, the MVVS_VPN utility waits for the second virtual private network channel from the Metaverse VPN server device client to the MVVS_VPN utility to be established as required (step 1215). The MVVS_VPN utility creates a second virtual private network channel from the Metaverse VPN server device client to the MVVS_VPN utility as required (steps 1216 and 1246). The MVAG_VPN utility waits to establish a second virtual private network channel from the Metaverse VPN server device client to the MVVS_VPN utility as required (step 1205). The MVAG_VPN utility establishes a node-to-node communication channel from the Metaverse Virtual Private Network Server device client to the MVAG_VPN utility (steps 1208 and 1248). Next, the MVVS_VPN utility establishes a node-to-node communication channel from the Metaverse Virtual Private Network Server device client to the MVAG_VPN utility (step 1218). Thereafter, the second on-demand VPC channel and the third on-demand VPC channel were merged into a single VPC channel between the Metaverse VPN server device client and the MVAG_VPN utility . After the third virtual private network channel created on demand and the second virtual private network channel created on demand are merged into a single virtual private network channel between the Metaverse VPN server device client and the MVAG_VPN utility , a Metaverse Virtual Private Server device client can initiate a private and secure connection to at least one Metaverse Application Gateway device client, the Metaverse Application Gateway on the private Metaverse Application Gateway local network server network service (not shown) or another MVVS_Device client (not shown) on the public cloud on the Internet (step 1231).

Compared with the third embodiment, the first embodiment has the advantage of a true on-demand connection mechanism, in which the connection is through a second virtual private network channel established on demand in the Metaverse virtual private network server installation client and MVVS_VPN between the utilities, between the MVVS_VPN utility and the MVAG_VPN utility, and ultimately through a third virtual private network channel established on demand to at least one Metaverse Application Gateway device client. On the surface, it appears to be more secure than the third embodiment. However, due to the commonality of the second virtual private network channel established on demand in both the first and third embodiments, the final single virtual private network channel in the two embodiments is connected from the virtual private network Judging from the nature of the mechanism, it is equally safe. Because of the complexity of applying the third virtual private network channel established on demand, the first embodiment can provide a true on-demand virtual private network connection. The third virtual private network channel and the second virtual private network channel are combined as needed into a single virtual private network channel between the Metaverse VPN server device client and the MVAG_VPN utility, and finally to the Metaverse application gateway Device installation customer. By using three virtual private network channels instead of two virtual private network channels in the third embodiment, the architecture is more complex. The first embodiment does not require that the third virtual private network channel is always open or must be kept active. Therefore, less energy is consumed in accordance with the nature of the connection mechanism on demand. Doing so seems to be more secure based on the nature of the demand for the third virtual private network channel. But the fact is that the connection mechanism from the second on-demand VPN channel solves the security issue in the final single VPN channel between the Metaverse VPN server device client and the MVAG_VPN utility. Therefore, the third embodiment is the preferred embodiment in terms of connection simplicity, efficiency and security.

Figure 13 is a flow chart of a communication process of the Metaverse Virtual Private Network Server of the Metaverse Virtual Private Network Server device client according to an embodiment of the present invention. From the perspective of the Metaverse Virtual Private Network Server device client, the MVVS_Device utility is launched from the WAN (step 1300). Next, the Metaverse Virtual Private Server device client registers the Metaverse Virtual Private Server client including MVVS Client Profile and MVVS Client Login and authenticates to the MVVS_Device utility (step 1301). It initiates node-to-node negotiation using the Metaverse Virtual Private Server client authentication to communicate with the MVVS_VPN utility (steps 1302 and 1341). The corresponding MVVS_Device utility also initiates node-to-node negotiation using Metaverse VPS client authentication to communicate with the Metaverse VPS device client (step 1311). Next, a virtual private network channel between the Metaverse virtual private network server device client and the MVVS_VPN utility is established (steps 1303, 1312 and 1342). The Metaverse Virtual Private Network Server device client initiates secure node-to-node communication with the MVVS_VPN utility (steps 1304 and 1343). On the MVVS_Device utility side, it passes control to the MVVS_VPN utility (step 1313).

Figure 14 shows the third embodiment of the present invention in the Metaverse Application Gateway, the Metaverse Virtual Private Network Server, the Metaverse Application Gateway smart device client and the Metaverse Virtual Private Network Server through the cloud network. A flow chart of a communication process of a node-to-node connection mechanism between intelligent device clients. The present invention discloses that Metaverse Virtual Private Network Server smart device clients do not need a public cloud routing server to connect and access the server Metaverse Application Gateway 1428, Metaverse Virtual Private Network Server 1427, or otherwise. A Metaverse application gateway smart device client, or through network services under a cloud network server. As shown in Figure 14, without going through the public routing server 112 or the public VPN routing server 114 of Figure 1, the Metaverse VPN server on the cloud network installs the client 1 1425 and the Metaverse application Gateways 1428 can communicate with each other. Unlike the prior art of Figure 7, initially, one of the Metaverse VPN server device clients (public cloud portal management device 1450) connects to public cloud portal 1451 (circle 1 and step 1403). The public cloud portal 1451 is a cloud-based public cloud portal that includes the PCP_Device utility 1447. The public cloud portal management device 1450 obtains the Metaverse VPS server authentication and the Metaverse VPS client authentication from the PCP_Device utility 1447 . The Metaverse Virtual Private Server certification includes the Metaverse Virtual Private Server area Domain_MVVS and the Metaverse Virtual Private Server password Passcode_MVVS. Yuanverse virtual private network server customer authentication includes the customer login profile MVVS Client Profile and the customer-configured login password MVVS Client Login. The Metaverse VPN server certificate is sent to the Metaverse application gateway management device 1420 via email or other means. Metaverse VPN Server Client Authentication is sent to authorized Metaverse VPN Server Device Client (e.g. Metaverse VPN Server Device Client 1 1425) for use with the Metaverse Application Gateway A node-to-node connection to one of the server device clients, such as Metaverse Application Gateway Device Client 2 1426 on the private area network of Metaverse Application Gateway 1428. The public cloud portal 1451 contains at least one PCP_Device utility (eg, PCP_Device utility 1447). At least one PCP_Device utility includes at least one virtual machine server (eg, virtual machine server 1432). At least one virtual machine server includes at least one Metaverse virtual private network server (eg, Metaverse virtual private network server 1427). At least one Metaverse virtual private network server includes the MVVS_Device utility 1424 and the MVVS_VPN utility 1423. The virtual machine server 1432 together with the Metaverse virtual private network server 1427 form a one-to-one correspondence with the Metaverse application gateway 1428 deployed in the private area network. PCP_Device utility 1447 is an extensible public cloud portal and may correspond to at least one virtual machine server (eg, virtual machine server 1432) and at least one Metaverse virtual private network server (eg, Metaverse virtual private network Server 1427).

First, after receiving the Metaverse Virtual Private Network Server Authentication, the Metaverse Application Gateway Management Device 1420 initializes and provides server authentication to the Metaverse Application Gateway 1428 through the MVAG_Device utility 1421 (circle 2 and step 1400). Next, the MVAG_Device utility 1421 passes the information within the Metaverse application gateway 1428 to the MVAG_VPN utility 1422. Through TCP/User Data Message Protocol, it registers the Metaverse Virtual Private Server authentication information containing Domain_MVVS and Passcode_MVVS to the MVVS_VPN utility 1423 (circle 4 and step 1401). The MVVS_VPN utility 1423 calls back to the Metaverse application 1452 (circle 3 and step 1405). Metaverse Application 1452 includes at least one Metaverse Application Gateway (eg, Metaverse Application Gateway 1428). At least one Metaverse application gateway includes the MVAG_VPN utility 1422 to enable the first virtual private network channel between the MVVS_VPN utility 1423 and the MVAG_VPN utility 1422 . Afterwards, between the MVAG_VPN utility 1422 and the MVVS_VPN utility 1423, the MVAG_VPN utility 822 establishes the first virtual private network channel (circle 5 and step 1413). The MVVS_VPN utility 1423 also enables the MVVS_VPN utility 1423 and any Metaverse VPN Server smart device client from the cloud on the Internet (e.g. Metaverse VPN Server Device Client 1 1425 or Metaverse VPN A second virtual private network channel (circle 9 and step 1445 or 1446) between client 3 (circle 9 and step 1446) of the path server device 1453). Then, upon demand from any Metaverse VPN server device client (for example, Metaverse VPN server device client 1 1425) from the cloud on the Internet, the Metaverse VPN server 1427 is ready Take further action. Within the Metaverse Virtual Private Network Server 1427, the MVVS_VPN utility 1423 communicates with the MVVS_Device utility 1424. The MVVS_Device utility 1424 remains in a loop, waiting for a request from the Metaverse Virtual Private Network Server smart device client (circle 7 and step 1402). First, Metaverse VPS Device Client 1 1425 registers Metaverse VPS Client authentication to the MVVS_Device utility 1424 (circle 8 and step 1404 or 1414). Metaverse virtual private network server client authentication includes MVVS Client Profile and MVVS Client Login. The MVVS_Device utility 1424 passes Metaverse VPN server client authentication and Metaverse VPN server 1427 internal connection requests to the MVVS_VPN utility 1423 . After registration, the Metaverse Virtual Private Network Server Installation Client 1 1425 connects to the MVVS_VPN utility 1423, and between the Metaverse Virtual Private Network Server Installation Client 1 1425 and the MVVS_VPN utility 1423, a second virtual machine is created as required. Private network channel (circle 10 and step 1406 or 1416). Assuming that another Metaverse Virtual Private Network Server Device Client (e.g., Metaverse Virtual Private Network Server Device Client 3 1453) has also successfully connected to the MVVS_VPN utility 1423, the third client created as required in Circle 10 and Step 1406 The two virtual private network channels and the first virtual private network channel established on demand in circle 5 and step 1413 are merged into a single virtual private network between the Metaverse virtual private network server device client 1 1425 and the MVAG_VPN utility 1422 network channel, and connects to the Metaverse Application Gateway Device Client 2 1426 (circle 11 and step 1411), or the Metaverse Application Gateway Network Service 1436 (circle 11 and step 831), or another metaverse Universe VPN Server Device Client (eg, Metaverse VPN Server Device Client 3 1453) (circle 10 and step 1416). Therefore, Metaverse VPS device client 1 1425 and Metaverse VPS device client 3 1453 form a node-to-node private and secure communication channel between them. Communication channels are the basis for further secure chat applications in text, voice and video, including cryptocurrency transactions.

Compared with the prior art in Figure 7, the present invention is more scalable and developable because it introduces some new entities, including public cloud portal 1451, PCP_Device utility 1447, virtual machine server 1432, metadata Universe application 1452, public cloud portal management device 1450, Metaverse application gateway management device 1420, Metaverse VPS server authentication and Metaverse VPS client authentication. It first connects to the public cloud portal 1451, then connects to at least one MVVS_Device utility (eg, MVVS_Device utility 1447), then connects to at least one virtual machine server (eg, virtual machine server 1432), then connects to at least one element A universe virtual private network server (e.g., Metaverse virtual private network server 1427), which in turn connects to at least one Metaverse application (e.g., Metaverse application 1452), which in turn connects to at least one Metaverse application gateway (e.g., Metaverse Application Gateway 1428), and then connects to at least one Metaverse Application Gateway Device Client (e.g., Metaverse Application Gateway Device Client 2 1426), or connects to the Metaverse Application Gateway server network service (such as Metaverse Application Gateway Network Service 1436), or to another Metaverse VPN Server Device Client (such as Metaverse VPN Server Device Client 3 1453). The public cloud portal management device 1450 begins to obtain the Metaverse virtual private network server authentication and client authentication from the public cloud portal 1451. The Metaverse VPS credentials are then sent to the Metaverse Application Gateway Manager 1420 to set up the Metaverse Application Gateway 1428 with the virtual machine server 1432 located within the public cloud portal 1451 The link corresponding to the Metaverse virtual private network server 1427. Furthermore, at least three virtual private network channels are bound together before the last two virtual private network channels form a single virtual private network channel for a vertical node-to-node private and secure metaverse virtual private network. Metaverse Virtual Private Network Server Device Client 1 1425 and Metaverse Application Gateway Device Client 2 1426 in the Route Server Smart Device Client Application, Metaverse Application Gateway Network Service 1436 or another Metaverse Node-to-node communication between Universe VPS device clients (such as Metaverse VPS device client 3 1453).

Figure 15 shows the third embodiment of the present invention based on the server farm, computer resource aggregation and virtual machine server through the cloud network in the Metaverse application gateway, Metaverse virtual private network server, Metaverse application gateway A flow chart of a communication process of the node-to-node connection mechanism between the Daoqi smart device client and the Metaverse virtual private network server smart device client. Furthermore, by adding a server farm 1530 and a computer resource aggregation 1531, Figure 15 extends Figure 14 to illustrate the implementation of the Metaverse application gateway connection point mechanism in a hyperscale data center. The hyperscale data center has at least one server farm (eg, server farm 1530), at least one computer resource aggregation (eg, computer resource aggregation 1531), at least one private cloud portal (eg, private cloud portal 1551), and at least one virtual machine Server (e.g. virtual machine server 1532). The virtual machine servers 1532 are scalable in number and size. In the corresponding virtual machine server (such as virtual machine server 1532), a hyperscale data center or service provider can build and deploy at least one private cloud portal (such as private cloud portal 1551) and a large number of independent Metaverse virtual machines. A private network server (such as Metaverse Virtual Private Network Server 1527) to serve the corresponding Metaverse Application Gateway (such as Metaverse Application Gateway 1528) and the corresponding Metaverse Application Gateway Smart device client (e.g. Metaverse Application Gateway Device Client 2 1526). Essentially, regardless of whether there is a topology of computer resource aggregation 1531 and server farm 1530 , Metaverse VPN server smart device clients (such as Metaverse VPN server smart device clients 1 1525 ) and Metaverse applications A collective pairing of node-to-node communication relationships between gateway smart device clients (eg, Metaverse application gateway smart device client 2 1526 ) is built and deployed by the Metaverse provider responsible for maintaining the virtual machine server 1532 . For example, a possible business model is for an Internet Metaverse provider to offer a large number of users to host their private and secure Metaverse virtual private network servers 1527 in a virtual machine server 1532 . In addition, a separate private and secure Metaverse Application Gateway 1528 is also provided to allow Metaverse subscribers to install the Metaverse Application Gateway 1528 in their private local network. Through the present invention, platform subscribers can create Metaverse Virtual Private Network Server smart device clients (such as Metaverse Virtual Private Network Server smart device clients 1 1525) from anywhere (such as smartphones, tablets or Tesla Dashboard) and Metaverse Application Gateway Smart Device Customers (e.g. Metaverse Application Gateway Smart Device Customer 2 1526) (e.g. laptops, IoT devices, network attached storage devices, set-top boxes, smart devices Node-to-node communication between devices or media servers) on the Metaverse provider's private and secure LAN. Figure 15 shows that the Metaverse Virtual Private Network Server smart device client of the present invention (such as Metaverse Virtual Private Network Server Smart Device Client 1 1525) does not require a public cloud routing server to connect to and access the server. Metaverse Application Gateway 1528, Metaverse Virtual Private Network Server 1527, or another Metaverse Application Gateway Smart Device Client (e.g., Metaverse Application Gateway Smart Device Client 2 1526), or via the cloud Network services under the server (not shown). As shown in Figure 15, without going through the public routing server 112 or the public VPN routing server 114 in Figure 1, the Metaverse Virtual Private Network Server smart device client 1 1525 and Metaverse in the cloud network Universe application gateways 1528 can communicate with each other. First, the Metaverse VPS management device 1550 is one of the Metaverse VPS smart device clients and is connected to the private cloud portal 1551 (circle 1 and step 1503). The private cloud portal 1551 is a cloud-based public cloud portal that contains the PCP_Device utility 1547. The Metaverse VPS management device 1550 obtains the Metaverse VPS server authentication and the Metaverse VPS client authentication from the PCP_Device utility 1547. The Metaverse Virtual Private Server certification includes the Metaverse Virtual Private Server area Domain_MVVS and the Metaverse Virtual Private Server password Passcode_MVVS. Yuanverse virtual private network server customer authentication includes the customer login profile MVVS Client Profile and the customer-configured login password MVVS Client Login. The Metaverse VPN server certificate is sent to the Metaverse application gateway management device 1520 via email or other means. Metaverse VPN Server Client Authentication is sent to authorized Metaverse VPN Server Device Client (e.g. Metaverse VPN Server Device Client 1 1525) for use with the Metaverse Application Gateway A node-to-node connection to one of the device device clients, such as Metaverse Application Gateway Device Client 2 1526 on the private area network of Metaverse Application Gateway 1528. The public cloud portal 1551 contains at least one PCP_Device utility (eg, PCP_Device utility 1547). At least one PCP_Device utility includes at least one virtual machine server (eg, virtual machine server 1532). At least one virtual machine server includes at least one Metaverse virtual private network server (eg, Metaverse virtual private network server 1527). At least one Metaverse virtual private network server includes the MVVS_Device utility 1524 and the MVVS_VPN utility 1523. The virtual machine server 1532 together with the Metaverse virtual private network server 1527 form a one-to-one correspondence with the Metaverse application gateway 1528 deployed in the private area network. PCP_Device utility 1547 is an extensible public cloud portal and may correspond to at least one virtual machine server (eg, virtual machine server 1532) and at least one Metaverse virtual private network server (eg, Metaverse virtual private network Server 1527).

First, after receiving the Metaverse VPN server authentication, the Metaverse Application Gateway Management Device 1520 initializes and provides server authentication to the Metaverse Application Gateway 1528 through the MVAG_Device utility 1521 (circle 2 and step 1500). Next, the MVAG_Device utility 1521 passes the information within the Metaverse application gateway 1528 to the MVAG_VPN utility 1522. Through TCP/User Data Message Protocol, it registers the Metaverse Virtual Private Server authentication information containing Domain_MVVS and Passcode_MVVS to the MVVS_VPN utility 1523 (circle 4 and step 1501). After registration, the MVVS_VPN utility 1523 calls back to the Metaverse application 1552 (circle 3 and step 1505). Metaverse application 1552 includes at least one Metaverse application gateway (eg, Metaverse application gateway 1528). At least one Metaverse application gateway includes the MVAG_VPN utility 1522 to enable the first virtual private network channel between the MVVS_VPN utility 1523 and the MVAG_VPN utility 1522 . Between the MVVS_VPN utility program 1523 and the MVAG_VPN utility program 1522, the MVVS_VPN utility program 1523 also establishes a second virtual private network channel as required, and waits for completion of the second virtual private network channel established as required (circle 10 and step 1506). Afterwards, between the MVAG_VPN utility 1522 and the MVVS_VPN utility 1523, the MVAG_VPN utility 1522 establishes the first virtual private network channel (circle 5 and step 1513). The MVVS_VPN utility 1523 also enables a second virtual connection between the MVVS_VPN utility 1523 and any Metaverse VPN Server smart device client (eg, Metaverse VPN Server Device Client 1 1525 ) from the cloud over the Internet. Private network channel (circle 9 and step 1545). Then, upon demand from any Metaverse VPN server device client (for example, Metaverse VPN server device client 1 1525) from the cloud on the Internet, the Metaverse VPN server 1527 is ready Take further action. Within the Metaverse Virtual Private Network Server 1527, the MVVS_VPN utility 1523 communicates with the MVVS_Device utility 1524. The MVVS_Device utility 1524 remains in a loop, waiting for a request from the Metaverse Virtual Private Network Server smart device client (circle 7 and step 1502). First, Metaverse VPS Device Client 1 1525 registers Metaverse VPS Client authentication to the MVVS_Device utility 1524 (circle 8 and step 1504). Metaverse virtual private network server client authentication includes MVVS Client Profile and MVVS Client Login. The MVVS_Device utility 1524 passes Metaverse VPN server client authentication and Metaverse VPN server 1527 internal connection requests to the MVVS_VPN utility 1523 . After registration, the Metaverse Virtual Private Network Server Installation Client 1 1525 connects to the MVVS_VPN utility 1523, and between the Metaverse Virtual Private Network Server Installation Client 1 1525 and the MVVS_VPN utility 1523, a second virtual machine is created as required. Private network channel (circle 10 and step 1506). The second virtual private network channel established on demand in circle 10 and step 906 and the first virtual private network channel established on demand in circle 5 and step 1513 are merged into the Metaverse virtual private network server device client A single virtual private network channel between 1 1525 and the MVAG_VPN utility 1522, and connected to the Metaverse Application Gateway device Client 2 1526 (circle 11 and step 1511), or the Metaverse Application Gateway Network Service ( Not labeled) (circle 11 and step 1511).

Figure 16 shows the link from the MVVS_VPN utility to the MVAG_VPN utility and the link between the Metaverse virtual private network server device client and the Metaverse application gateway device client in the private area network according to the third embodiment of the present invention. A flow chart of a communication process. First, over the WAN, the MVAG_VPN utility uses Metaverse VPN server authentication to connect to the MVVS_VPN utility (step 1600). Over the WAN, the MVVS_VPN utility accepts the Metaverse VPN server authentication from the MVAG_VPN utility (step 1610). Then, if necessary, the MVVS_VPN utility sends further links or update information to the MVAG_VPN utility (steps 1611 and 1641). If necessary, the MVAG_VPN utility receives further link or update information from the MVVS_VPN utility (step 1601). The MVVS_VPN utility calls back the MVAG_VPN utility to enable the first virtual private network channel (steps 1612 and 1642). The MVAG_VPN utility connects to the MVVS_VPN utility to establish a first virtual private network channel from the MVAG_VPN utility to the MVVS_VPN utility (steps 1603 and 1642). The MVVS_VPN utility waits for the second virtual private network channel from the Metaverse VPN server device client to the MVVS_VPN utility to be established (step 1615). Next, the MVVS_VPN utility establishes a second virtual private network channel from the Metaverse VPN server device client to the MVVS_VPN utility as required (steps 1616 and 1646). The MVAG_VPN utility waits for the second virtual private network channel from the Metaverse VPN server device client to the MVVS_VPN utility to be established (step 1605). The MVAG_VPN utility establishes a node-to-node communication channel from the Metaverse Virtual Private Network Server device client to the MVAG_VPN utility (steps 1608, 1618, and 1648). Thereafter, the second VPN channel and the first VPN channel are merged into a single VPN channel between the Metaverse VPN server device client and the MVAG_VPN utility. After the second virtual private network channel and the first virtual private network channel established on demand are merged into a single virtual private network channel between the Metaverse virtual private network server device client and the MVAG_VPN utility, the Metaverse Virtual Private Network A private network server device client can initiate a private and secure connection to at least one Metaverse Application Gateway device client, the Metaverse Application Gateway network service on the private Metaverse Application Gateway local network (not shown) or another MVVS_Device client (not shown) on a public cloud on the Internet (step 1631).

Compared to the first embodiment, the third embodiment has the advantage of a simpler architecture by using only two virtual private network channels instead of the three virtual private network channels of the first embodiment. However, the third embodiment requires that the first virtual private network channel is always open, or at least must remain active. This seems less secure because the first virtual private network channel is always online. But the fact is that the connection mechanism from the second on-demand VPN channel solves the security issue in the final single VPN channel between the Metaverse VPN server device client and the MVAG_VPN utility. Therefore, the third embodiment is the preferred embodiment in terms of connection simplicity, efficiency and security.

Most text providers, such as Netflix, HBO, Amazon, Pandora, etc., implement a mechanism called geo-blocking to enforce their exclusive digital territorial rights. In contrast, a geo-home is a mechanism that allows access to online content at home, and a geo-portal is a mechanism that allows access to online content on a portal. While the legality of enforcing geo-blocking is controversial and varies by region, some international travelers use VPN relay services to circumvent Internet Protocol-based geo-blocking to access access outside the country in which they are located. Unavailable domestic or foreign-based online content. Legality aside, the disadvantages of this approach are that it involves an additional subscription to a virtual private network service and limited options by choosing a geo-home or geo-portal. In addition to the original functionality of allowing private and secure access to Metaverse Application Gateway device clients and network services in a private local area network from anywhere in the cloud over the Internet, the present invention provides Metaverse It provides a mechanism that can dynamically configure Metaverse virtual private network servers according to needs to flexibly provide users with the choice of geo-blocking, geo-portal or geo-residential when accessing online content.

Although the present invention has been described in terms of illustrated embodiments, those of ordinary skill in the art will readily appreciate that variations may be made in the embodiments that are within the spirit and scope of the invention. Accordingly, one of ordinary skill in the art may make modifications without departing from the spirit and scope of the appended claims. The above are only preferred embodiments of the present invention, and all equivalent changes and modifications made in accordance with the patentable scope of the present invention shall fall within the scope of the present invention.

100, 200, 300, 400, 500, 600: Public cloud 101, 106, 107, 109, 110, 111: Smart device customers 102, 103, 202, 203, 302, 303, 402, 403: Router 104, 105, 204, 205, 304, 305, 404, 405, 434, 504, 505: LAN 108:Private cloud server 112, 212, 312, 412:Public routing server 113, 213, 313, 413:Public cloud server 114, 214:Public VPN Route Server 117, 119, 217, 219, 317, 319, 417, 419: Public IP address 118, 120, 218, 220, 318, 320, 418, 420: Private IP address 201, 209, 210, 211, 221, 701, 725, 726: Private Cloud Callback Server (PCCBS) installation customers 206, 207: Private Cloud Routing Server (PCRS) installation customer 208, 728:Private cloud routing server 215:Customer message box 216, 727: Private Cloud Callback Server 222, 223, 224, 225, 322, 323, 324, 325, 422, 423, 424, 425, 426, 540: Communication path 228, 328, 428, 436: Metaverse network service 240, 2400, 340, 3400, 440: Virtual LAN 250, 350, 360, 450, 460: physical area network 270:Private Cloud Route Server Utility 271:Private cloud routing server customer database 272:Route Server Message Box Utility 273, 720: Private Cloud Routing Server (PCRS) Management Device 274: Private Cloud Routing Server Device Application (PCRS_Device_App) 275:Private Cloud Routing Server (PCRS) Server Database 276, 280, 282: Customer Message Box Utility 277:Private Cloud Callback Server (PCCBS) Management Device 278: Private Cloud Callback Server Device Application (PCCBS_Device_App) 279:Private Cloud Callback Server (PCCBS) Server Database 281:Invitee device 2700: Private Cloud Callback Server (PCCBS) Utility 2710: Private Cloud Callback Server (PCCBS) Customer Database 2720: Callback server message box utility 301, 309, 310, 311, 321, 401, 409, 410, 411, 421, 825, 853, 925, 1425, 1453, 1525: Metaverse Virtual Private Server (MVVS) installation client 306, 307, 406, 407, 435, 826, 926, 1426, 1526: Metaverse Application Gateway (MVAG) Device Client 308, 408, 828, 928, 1428, 1528: Metaverse Application Gateway 316, 416, 827, 927, 1427, 1527: Metaverse Virtual Private Network Server 330, 430, 530, 851, 951, 1451, 1551: Public Cloud Portal (PCP) 331, 431, 531, 532, 533, 534, 832, 932, 1432, 1532: Virtual machine server 370, 470, 852, 952, 1452, 1552: Metaverse Application 371, 374, 821, 921, 1421, 1521: MVAG_Device utility 372, 822, 922, 1422, 1522: MVAG_VPN utility 373, 820, 920, 1420, 1520: Metaverse Application Gateway (MVAG) Management Device 375: Metaverse Virtual Private Network Server Area (Domain_MVVS) 376: Metaverse Virtual Private Network Server Password (Passcode_MVVS) 377, 850, 950, 1450, 1550: Public Cloud Portal (PCP) management device 378: Public Cloud Portal Installation Client Utility 379: Metaverse Virtual Private Server (MVVS) Device Client Authentication 380: Metaverse Virtual Private Server (MVVS) Server Certification 381: MVVS_Device_Client utility 382: Metaverse Virtual Private Server (MVVS) customer login 383: Metaverse Virtual Private Server (MVVS) Customer Configuration 3710, 824, 924, 1424, 1524: MVVS_Device utility 3720, 823, 923, 1423, 1523: MVVS_VPN utility 502,602: Private area network router 503:Guest Area Network Router 508:Private material gateway 516:Private Cloud Virtual Private Network Server 541, 542, 543, 544: Internet platform owner cloud 550:Private Metaverse 551, 552, 553, 554, 561, 562, 563, 564: Private Cloud Virtual Private Server (PCVS) smart device customers 521, 522, 523, 524, 525, 526: Private Material Gateway (PMG) smart device customers 603: Guest Area Network Router 604: Private LAN 608:Metaverse Application Gateway 616: Metaverse Virtual Private Network Server 622:Archived content server 630:Metaverse Provider Portal 631, 632, 633, 634: Virtual machine server 640:Application Virtual Network 641, 642,643,644: Metaverse cloud provider 650, 6320, 6330, 6340: Metaverse Application 651,652,653,654,661,662,663,664: Metaverse Virtual Private Server (MVVS) smart device customers 6250,6251,6262: Live streaming events 700, 701, 702, 703, 704, 705, 706, 707, 711, 713, 714, 716, 800, 801, 802, 803, 804, 805, 806, 807, 811, 813, 814, 816, 831 , 845, 846, 900, 901, 902, 903, 904, 905, 906, 907, 911, 913, 945, 1000, 1001, 1002, 1003, 1004, 1010, 1011, 1040, 1101, 1102 , 1103, 1104, 1110, 1111, 1112, 1140, 1200, 1201, 1202, 1203, 1205, 1208, 1210, 1211, 1212, 1213, 1215, 1216, 1218, 1231, 1240, 1241, 124 2, 1243, 1246, 1248, 1300, 1301, 1302, 1303, 1304, 1311, 1312, 1313, 1341, 1342, 1343, 1400, 1401, 1402, 1403, 1404, 1405, 1406, 1411, 1413, 1414, 141 6, 1431, 1445, 1446, 1500, 1501, 1502, 1503, 1504, 1505, 1506, 1511, 1513, 1545, 1600, 1601, 1603, 1605, 1608, 1610,1611, 1612, 1615, 1616, 1618, 163 0, 1640, 1641, 1642, 1646, 1648: steps 721:PCRS_Device utility 722:PCRS_VPN utility 723:PCCBS_VPN utility 724:PCCBS_Device utility 847, 947, 1447, 1557:PCP_Device utility 836, 1436: Metaverse Application Gateway (MVAG) network service 930, 1530:Server farm 931, 1531:Computer resource aggregation

Figure 1 is a schematic diagram of a traditional cloud network infrastructure according to Embodiment 1 of the present invention. Figure 2 shows an embodiment of the present invention based on session messages in a private cloud routing server, a private cloud callback server, a metaverse network service, a private cloud routing server smart device client, and a private cloud callback server smart device client. A schematic diagram of a cloud network infrastructure for box communication connection mechanism. Figure 3 shows the first embodiment of the present invention based on the Metaverse application gateway, Metaverse virtual private network server, Metaverse network service, Metaverse application gateway smart device client and Metaverse virtual private A schematic diagram of a cloud network infrastructure that connects multiple virtual private network channels between network server smart device clients. Figure 4 shows the second embodiment of the present invention based on the Metaverse application gateway, Metaverse virtual private network server, Metaverse network service, Metaverse application gateway smart device client and Metaverse virtual private A schematic diagram of a cloud network infrastructure that connects multiple virtual private network channels between network server smart device clients. Figure 5 shows an embodiment of the present invention based on a private material gateway, a private cloud virtual private network server, a private network service, a private material gateway smart device client, and a private cloud virtual private network server smart device client. A schematic diagram of a cloud network infrastructure connecting multiple virtual private network channels. Figure 6 shows the third embodiment of the present invention based on the Metaverse application gateway, Metaverse virtual private network server, Metaverse network service, Metaverse application gateway smart device client and Metaverse virtual private A schematic diagram of a cloud network infrastructure that connects multiple virtual private network channels between network server smart device clients. Figure 7 shows the node-to-node connection between the private cloud routing server, the private cloud callback server, the private cloud callback server smart device client and the private cloud routing server smart device client through the cloud network according to an embodiment of the present invention. A flowchart of the communication process of the mechanism. Figure 8 shows an embodiment of the present invention through the cloud network on the Metaverse Application Gateway, the Metaverse Virtual Private Server, the Metaverse Virtual Private Server smart device client and the Metaverse Application Gateway Smart Schematic diagram of a communication process of the node-to-node connection mechanism between device clients. Figure 9 shows an embodiment of the present invention based on the server farm, computer resource aggregation and virtual machine server through the cloud network in the Metaverse application gateway, Metaverse virtual private network server, Metaverse virtual private network server A flow chart of a communication process of the node-to-node connection mechanism between the device smart device client and the Metaverse application gateway smart device client. Figure 10 is a flow chart of a communication process for the public cloud portal management device to register to the public cloud portal according to the embodiment of the present invention. Figure 11 is a flow chart of a communication process of initializing and configuring the Metaverse application gateway management device according to an embodiment of the present invention. Figure 12 is an example of a link from the MVVS_VPN utility to the MVAG_VPN utility and a link between the Metaverse Virtual Private Network Server Device Client and the Metaverse Application Gateway Device Client in the private area network according to an embodiment of the present invention. Flowchart of communication process. Figure 13 is a flow chart of a communication process of the Metaverse Virtual Private Network Server of the Metaverse Virtual Private Network Server device client according to an embodiment of the present invention. Figure 14 shows the third embodiment of the present invention through the cloud network on the Metaverse Application Gateway, the Metaverse Virtual Private Network Server, the Metaverse Virtual Private Network Server smart device client and the Metaverse Application Gateway. A flow chart of a communication process of a node-to-node connection mechanism between intelligent device clients. Figure 15 shows the third embodiment of the present invention based on the server farm, computer resource aggregation and virtual machine server through the cloud network in the Metaverse application gateway, Metaverse virtual private network server, Metaverse virtual private network A flow chart of a communication process of the node-to-node connection mechanism between the road server smart device client and the Metaverse application gateway smart device client. Figure 16 shows the link from the MVVS_VPN utility to the MVAG_VPN utility and the link between the Metaverse virtual private network server device client and the Metaverse application gateway device client in the private area network according to the third embodiment of the present invention. A flow chart of a communication process.

300:Public cloud 301, 309, 310, 311, 321: Metaverse Virtual Private Server (MVVS) Device Client 302, 303:Router 304, 305:Local area network 306, 307: Metaverse Application Gateway (MVAG) installation client 308: Metaverse Application Gateway 312:Public routing server 313:Public cloud server 316: Metaverse Virtual Private Network Server 317, 319: Public IP address 318, 320: Private IP address 322, 323, 324, 325: Communication path 328: Yuanverse Network Service 330:Public Cloud Portal 331:Virtual machine server 340, 3400: Virtual LAN 350, 360: Physical area network 370:Metaverse Application 371: MVAG_Device utility 372: MVAG_VPN utility 373: Metaverse Application Gateway (MVAG) Management Device 374: MVAG_Device utility 375: Metaverse Virtual Private Network Server Area (Domain_MVVS) 376: Metaverse Virtual Private Network Server Password (Passcode_MVVS) 377: Public Cloud Portal (PCP) Management Appliance 378: Public Cloud Portal (PCP) Installation Client Utility 379: Metaverse Virtual Private Server (MVVS) Device Client Authentication 380: Metaverse Virtual Private Server (MVVS) Server Certification 381: MVVS_Device_Client utility 382: Metaverse Virtual Private Server (MVVS) customer login 383: Metaverse Virtual Private Server (MVVS) Customer Configuration 3710: MVVS_Device utility 3720: MVVS_VPN utility

Claims (28)

A method for a connection mechanism in a public cloud network, comprising: setting up at least one public cloud portal (PCP), at least one virtual server in a client-server relationship in a master-slave manner Virtual machine server (VMS), at least one public cloud portal management device, at least one metaverse virtual private network (VPN) server (metaverse VPN server, MVVS), at least one virtual private network tunnel, at least one Metaverse virtual private network server smart device client on one side of the at least one Metaverse virtual private network server to provide a plurality of cloud-based network services, including at least one private At least one metaverse application (MA) of the router, at least one private area network (LAN), at least one metaverse application gateway (MVAG), at least one metaverse The Application Gateway management device, at least one Metaverse Application Gateway network service and at least one Metaverse Application Gateway smart device client on the one side of a Metaverse Application Gateway private area network; Obtain a plurality of connection authentications from a public cloud portal management device of the at least one public cloud portal management device; and obtain a plurality of connection authentications from a Metaverse application gateway of the at least one Metaverse application gateway, and the at least one Metaverse application gateway. Pairing and registration with a Metaverse Virtual Private Network server of the Metaverse Virtual Private Network server; establishing a plurality of initial Virtual Private Networks between the Metaverse Virtual Private Network server and the Metaverse Application Gateway Network tunnels; establishing a plurality of initial virtual private network channels between the Metaverse Virtual Private Network Server and the Metaverse Virtual Private Network Server smart device clients; Combine the above two virtual private network tunnels into one virtual private network tunnel between a Metaverse virtual private network server smart device client and the Metaverse application gateway; and between the at least one metaverse virtual private network tunnel The Universe Virtual Private Network Server Smart Device Client and the at least one Metaverse Application Gateway Smart Device Client, the at least one Metaverse Application Gateway Network Service or another Metaverse Virtual Private Server Intelligence One of the device clients runs a plurality of vertical peer-to-peer (P2P) private and secure Metaverse virtual private network server smart device client applications; wherein the The linking mechanism is between the at least one Metaverse virtual private network server smart device client and the Metaverse application gateway, the at least one Metaverse application gateway smart device client, the at least one Metaverse application gateway A node-to-node private and secure connection mechanism between at least one of the Taoist Network Services or the other Metaverse Virtual Private Network Server smart device client; wherein the at least one public cloud portal and includes the at least one The at least one virtual machine server of the Metaverse virtual private network server is located in a hyperscale data center on the public cloud network; wherein the at least one Metaverse application is along with the at least one Metaverse application. Universal application gateways are located at multiple client's remote premises. The method of claim 1, wherein the plurality of link authentications include a plurality of Metaverse Virtual Private Network server authentications and a plurality of Metaverse Virtual Private Network server client authentications. The method of claim 2, wherein the at least one public cloud portal is accessed by the One less public cloud portal management device has access to log in and obtain metaverse virtual private server authentication and metaverse virtual private server client authentication. The method of claim 2, wherein the plurality of Metaverse virtual private network server certificates are transmitted to a Metaverse application gateway management device of the at least one Metaverse application gateway management device, and The plurality of Metaverse VPS client certificates are sent to the Metaverse VPS smart device client for a connection. The method of claim 2, wherein the plurality of Metaverse Virtual Private Server certificates include a Metaverse Virtual Private Server virtual machine server zone name and a Metaverse Virtual Private Server virtual server domain name. The machine server login password, and the plurality of Metaverse VPN server client authentications include a Metaverse VPN server smart device client VPN profile and a Metaverse VPN server Smart device customer VPN login password. The method of claim 2, wherein the plurality of Metaverse virtual private network server certificates are imported by a Metaverse application gateway management device of the at least one Metaverse application gateway management device. ) to be configured to the Metaverse application gateway management device so that the Metaverse application gateway management device can be paired and registered with the Metaverse virtual private network server. The method of claim 1, wherein the step of establishing the plurality of initial virtual private network tunnels between the Metaverse virtual private network server and the Metaverse application gateway includes: The at least one Metaverse virtual private network server in the public cloud network calls back the at least one Metaverse application gateway in a private area network of the at least one Metaverse application server to enable a first virtual private network tunnel (channel); if the first virtual private network tunnel is enabled by the at least one Metaverse virtual private network server, the at least one Metaverse application gateway The gateway establishes a first virtual private network tunnel with the at least one Metaverse virtual private network server; if a plurality of appropriate authentications are established, the at least one Metaverse application gateway with the at least one Metaverse virtual private network server The network server activates a third virtual private network tunnel; the Metaverse virtual private network server establishes a third virtual private network tunnel between the Metaverse virtual private network server and the Metaverse application gateway as required The private network tunnel is waiting for the completion of establishing a second virtual private network tunnel between the Metaverse Virtual Private Network Server smart device client and the Metaverse Virtual Private Network Server as required; the Metaverse Virtual Private Network The network server enables on demand a second virtual private network tunnel between the Metaverse VPN server and the at least one Metaverse VPN server smart device client from a cloud in the Internet ; and the at least one Metaverse virtual private network server smart device client establishes the second virtual private network between the Metaverse virtual private network server and the at least one Metaverse virtual private network server smart device client as required Network tunnel; wherein the second virtual private network tunnel established on demand and the third virtual private network tunnel established on demand are merged into the Metaverse virtual private network server smart device client and the Metaverse application A single virtual private network tunnel between the application gateways through the Metaverse virtual private network server, and the single virtual private network tunnel ultimately to the at least one Metaverse application gateway smart device client, the at least A metaverse application gateway server network service and the other Metaverse virtual private network server smart device customer. The method of claim 1, wherein the step of establishing the plurality of initial virtual private network tunnels between the Metaverse virtual private network server and the Metaverse application gateway includes: The at least one Metaverse virtual private network server in the cloud network dials back the at least one Metaverse application gateway in a private area network of the at least one Metaverse application to enable a first Virtual private network tunnel; if the first virtual private network tunnel is enabled by the at least one Metaverse virtual private network server, the at least one Metaverse application gateway and the at least one Metaverse virtual private network server The server establishes a first virtual private network tunnel; the metaverse virtual private network server activates the metaverse virtual private network server and the at least one metaverse virtual private network from a cloud in the Internet on demand a second virtual private network tunnel between the server smart device clients; and the at least one Metaverse virtual private network server smart device client establishes the Metaverse virtual private network server and the at least one Metaverse virtual private network server as required The second virtual private network tunnel between virtual private network server smart device clients; wherein the first virtual private network tunnel and the second virtual private network tunnel established on demand are merged into the metaverse virtual private network A single virtual private network tunnel between the network server smart device client and the metaverse application gateway through the metaverse virtual private network server, and the single virtual private network tunnel ultimately to the at least one metaverse The universe application gateway smart device client, the at least one Metaverse application gateway network service and the other Metaverse virtual private network server smart device client. The method as described in claim 1, wherein through the Metaverse Virtual Private Network Server, between the Metaverse Virtual Private Network Server smart device client and the Metaverse Application Gateway, connect to the Metaverse Virtual Private Network Server as required. This step of the Metaverse Application Gateway includes: configuring through a Metaverse VPN Server VPN client, the at least one Metaverse VPN Server smart device client enabling to connect to the A request from at least one Metaverse virtual private network server to establish a second virtual private network tunnel on demand in case the at least one Metaverse application The virtual private network server smart device client attempts to access the at least one metaverse application gateway smart device client or a metaverse network service (MVNS). The method of claim 1, wherein in the at least one Metaverse virtual private network server smart device client and the at least one Metaverse application gateway smart device client, the at least one Metaverse application gateway Between the network service or the other one of the Metaverse Virtual Private Network Server Smart Device Clients, operating the plurality of vertical node-to-node private and secure Metaverse Virtual Private Network Server Smart Device Client applications The step includes: joining a private and secure communication session as a guest with a host Metaverse VPN server smart device client in the public cloud network. ; wherein the Metaverse Virtual Private Network Server Smart Device Client is accessible in a local area network mode, the access being for a Virtual Private Network from the at least one Metaverse Virtual Private Network Server Smart Device Client link; wherein the private and secure communication session includes at least one of an image, a voice, a text, or an application, and the application includes the Metaverse Virtual Private Network Server Intelligence A program, a utility, an operation or a transaction identifiable by the device client and the host Metaverse virtual private network server smart device client; wherein the at least one Metaverse Application gateway smart device clients may access the at least one Metaverse application gateway network service in the LAN mode along with the at least one Metaverse application gateway network service on a private local area network of the at least one Metaverse application gateway , the access is for the virtual private network connection from the at least one Metaverse virtual private network server smart device client. The method of claim 10, wherein when the plurality of vertical nodes between the at least one Metaverse virtual private network server smart device client and the another Metaverse virtual private network server smart device client are private to the node When the secure Metaverse Virtual Private Network Server Smart Device Client application is run, the application includes the Metaverse Virtual Private Network Server Smart Device Client and the host Metaverse Virtual Private Network Server Smart Device A cryptocurrency application that installs a program, a utility, an operation, or a transaction that is identifiable to the client. The method of claim 10, wherein when the plurality of vertical nodes between the at least one Metaverse virtual private network server smart device client and the another Metaverse virtual private network server smart device client are private to the node When the secure Metaverse Virtual Private Network Server smart device client application is run, the Metaverse Virtual Private Network Server is configured as required to provide a Multiple choices between geo-blocking, a geo-portal or a geo-home. The method of claim 1, wherein the at least one public cloud portal includes: an Internet service; and a program for executing instructions stored in the memory to instruct the at least one public cloud portal Perform the following operations: create and manage a list of authorized customers to accommodate the at least one public cloud portal management device; create and manage a plurality of Metaverse virtual private network server certificates and a plurality of Metaverse virtual private network servers The plurality of connection authentications for server client authentication; and executing (conducting) the step of obtaining the plurality of connection authentications from the public cloud portal management device. The method of claim 1, wherein the at least one virtual machine server includes: an Internet service; and a program for executing instructions stored in the memory to instruct the at least one virtual machine server Perform the following operations: create and manage a list of authorized customers to accommodate the at least one public cloud portal management device, the at least one Metaverse application gateway, and the at least one Metaverse virtual private network server; and manage the at least one Metaverse virtual private network server A communication between the Metaverse Virtual Private Network Server and the Smart Device Client of the Metaverse Virtual Private Network Server. The method of claim 1, wherein the at least one public cloud portal management device includes: a computing device; a link to a network; and a program for executing instructions stored in memory to instruct the at least one public cloud portal management device to: create a first network operating in a local area network mode a network service; establishing a second network service in accordance with the Internet protocol; establishing a third network service in accordance with an industry standard network protocol; and executing the public cloud portal management device to obtain the plurality of This step of link authentication. The method of claim 1, wherein the at least one Metaverse virtual private network server includes: a computing device; a link to a network; and a program for executing instructions stored in the memory , to instruct the at least one Metaverse virtual private network server to perform the following operations: create and manage a first authorized client list through at least one virtual private network link to accommodate the at least one Metaverse virtual private network server Smart device client; create and manage a second authorized client list to accommodate the at least one Metaverse application gateway through the at least one virtual private network link; execute from the Metaverse application gateway, and the The step of pairing and registering the Metaverse Virtual Private Network Server; executing the step of establishing the plurality of initial Virtual Private Network tunnels between the Metaverse Virtual Private Network Server and the Metaverse Application Gateway Steps; and execute through the Metaverse Virtual Private Network Server, between the Metaverse Virtual Private Network Server smart device client and the Metaverse Application Gateway, connect to the Metaverse Virtual Private Network Server as required. This step for the Metaverse Application Gateway. The method of claim 1, wherein the at least one Metaverse virtual private network server smart device client includes: a computing device; a link to a network; and a program for executing stored in the memory instructions in to instruct the at least one Metaverse virtual private network server smart device client to perform the following operations: establish a first network service in accordance with the Internet protocol; establish a second network service in accordance with an industry standard network protocol Network services; creating and managing an Internet connection with the at least one virtual machine server and the at least one Metaverse virtual private network server through a virtual private network link; through the virtual private network link, Create and manage a connection with the at least one Metaverse application gateway smart device client; execute through the Metaverse virtual private network server, between the Metaverse virtual private network server smart device client and the Metaverse Between the application gateway, the step of connecting to the Metaverse application gateway as required; and executing the step between the at least one Metaverse virtual private network server smart device client and the at least one Metaverse application gateway Operate the plurality of vertical nodes privately and securely between the server smart device client, the at least one Metaverse application gateway network service, or the other Metaverse virtual private network server smart device client. This step of the Metaverse VPN Server smart device client application. The method as described in request item 1, wherein the at least one Metaverse application includes: An Internet router; at least one private area network; at least one Metaverse network service; the at least one Metaverse application gateway smart device client; and the at least one Metaverse application gateway. The method of claim 1, wherein the at least one Metaverse application gateway includes: a computing device; a link to a network; and a program for executing instructions stored in the memory, To instruct the at least one Metaverse application gateway to perform the following operations: create and manage a list of authorized clients to accommodate the at least one Metaverse virtual private network server through a virtual private network link; perform the following operations from the metaverse virtual private network server: The step of pairing and registering the Metaverse Application Gateway with the Metaverse Virtual Private Network Server; executing the step of establishing the plurality between the Metaverse Virtual Private Network Server and the Metaverse Application Gateway This step of an initial VPN tunnel; executing through the Metaverse VPN server, connecting on demand between the Metaverse VPN server smart device client and the Metaverse application gateway The step to the Metaverse Application Gateway; and executing on the at least one Metaverse Virtual Private Network Server smart device client and the at least one Metaverse Application Gateway smart device client, the at least one Metaverse Application Gateway Network Service or the other Metaverse Virtual Private Network Server smart device The step of running the plurality of vertical node-to-node private and secure Metaverse virtual private network server smart device client applications among the clients. The method of claim 1, wherein the at least one Metaverse application gateway network service includes: a first network service operating in a local area network mode because there is an industry recognized (recognized) The strength of the virtual private network tunnel prevents external monitoring and recording; the second network service is based on a protocol of the Internet; the third network service is based on an industry standard network protocol; the fourth network service , the fourth network service is independent of peripheral platforms and compatible with all existing fragmented Internet of Things (IoT) devices; and the fifth network service is based on the Metaverse Virtual Private Network A path server, between the Metaverse virtual private network server smart device client and the Metaverse application gateway, connects to the Metaverse application gateway as required. The method of claim 1, wherein the at least one Metaverse Application Gateway smart device client includes: a computing device; a link to a network; and a program for executing stored in memory instructions to instruct the at least one Metaverse Application Gateway smart device client to perform the following operations: establish a first network service operating in a local area network mode; establish a second network service in accordance with the Internet Protocol network service; establishing a third network service based on an industry standard network protocol; Execute through the Metaverse Virtual Private Network Server, between the Metaverse Virtual Private Network Server smart device client and the Metaverse Application Gateway, connecting to the Metaverse Application Gateway as required Steps; and executing the plurality of vertical node-to-node private and secure Metaverse virtual devices between the at least one Metaverse virtual private network server smart device client and the at least one Metaverse application gateway smart device client. This step of the private web server smart device client application. The method of claim 1, wherein the at least one Metaverse application gateway management device includes: a computing device; a link to a network; and a program for executing a program stored in the memory. Instructions to instruct the at least one Metaverse application gateway management device to perform the following operations: establish a first network service operating in a local area network mode; establish a second network service in accordance with the Internet Protocol ; Establishing a third network service based on an industry standard network protocol; and performing the steps of pairing and registering from the Metaverse application gateway with the Metaverse virtual private network server. The method of claim 1, wherein the at least one virtual private network tunnel includes: at least one first network service based on Internet Protocol; at least one second network service based on an industry standard network protocol ; A privacy and a security in a communication, and an anti-obsolescence interoperability and compatibility in the communication; a LAN mode access through the at least one virtual private network tunnel; at least one first virtual private network tunnel of the plurality of initial virtual private network tunnels between the metaverse virtual private network server and the metaverse application gateway; and through the metaverse virtual private network Server, at least one second virtual private network tunnel between the metaverse virtual private network server smart device client and the metaverse application gateway. A method for connecting at least one metaverse virtual private network (VPN) server (metaverse VPN server, MVVS) smart device client and at least one metaverse application gateway (metaverse application) through a public cloud network gateway, MVAG) smart device client or at least one of the Metaverse application gateway network services, including: on demand, in the Metaverse virtual private network server smart device client Establish a virtual private network tunnel between the Metaverse Virtual Private Network Server and the Metaverse Virtual Private Network Server; establish a virtual private network tunnel between the Metaverse Virtual Private Network Server and the Metaverse Application Gateway; combine the above Two virtual private network tunnels are combined into one virtual private network tunnel between a Metaverse virtual private network server smart device client and the Metaverse application gateway; and between the at least one Metaverse virtual private network tunnel Private network server smart device client and the at least one Metaverse application gateway smart device client, the at least one Metaverse application gateway network service or another Metaverse virtual private network server smart device client one of the rooms, Run multiple vertical peer-to-peer (P2P) private and secure Metaverse virtual private network server smart device client applications; among which, through the public cloud network, the at least A Metaverse virtual private network server smart device client and the at least one Metaverse application gateway smart device client, the at least one Metaverse application gateway network service or another Metaverse virtual private network server Communicate privately and securely with that person among the client's smart device clients. A non-transitory computer-readable medium for storing executable instructions that cause a computer to perform the following operations in response to execution: Master-slave setting up a Metaverse virtual world in a client-server relationship Private network (virtual private network, VPN) server (metaverse VPN server, MVVS) and a metaverse virtual private network server smart device client; execution (conduct) on the metaverse virtual private network server and a metaverse virtual private network server Establish a plurality of initial virtual private network tunnels between the metaverse app gateway (PMMGMVAG); execute between the metaverse virtual private network server and a metaverse virtual private network server smart device client , establish a plurality of initial virtual private network tunnels; and combine the above two virtual private network tunnels into one virtual private network tunnel, between a Metaverse virtual private network server smart device client, and the Metaverse application Between gateways; in a public cloud network, the Metaverse Virtual Private Network Server contains an MVVS_Device utility. A non-transitory computer-readable medium for storing executable instructions that cause a computer to perform the following operations, in response to execution: The master-slave mode sets up a metaverse virtual private network (VPN) server (metaverse VPN server, MVVS) and a metaverse application gateway (metaverse application gateway) in a client's server relationship. MVAG); execute (conduct) from the Metaverse Application Gateway to pair and register with the Metaverse Virtual Private Network Server; execute (conduct) between the Metaverse Virtual Private Network Server and the Metaverse Application Gate Establish the plurality of initial virtual private network tunnels between the containers; execute the establishment of the plurality of initial virtual private network tunnels between the metaverse virtual private network server and the metaverse virtual private network server smart device client ; Combine the above two virtual private network tunnels into one virtual private network tunnel between a Metaverse virtual private network server smart device client and the Metaverse application gateway; and execute on at least one Metaverse Virtual Private Network Server Smart Device Client and the at least one Metaverse Application Gateway Smart Device Client, at least one Metaverse Application Gateway Network Service or another Metaverse Virtual Private Network Server Intelligence One of the device clients runs multiple vertical peer-to-peer (P2P) private and secure Metaverse virtual private network server smart device client applications. A method for communication, including: setting up at least one virtual machine server (VMS) and at least one Metaverse virtual private network (virtual private network) in a client-server relationship in a master-slave manner. VPN) server (metaverse VPN server, MVVS), at least one metaverse virtual private network server smart device client on the at least one metaverse virtual private network server side to provide a plurality of cloud-based network services , at least one metaverse should A metaverse application gateway (MVAG) and at least one metaverse application gateway smart device client on one side of the at least one metaverse application gateway; wherein the at least one virtual machine server includes The at least one Metaverse virtual private network server is used to provide the plurality of cloud-based network services; wherein the at least one virtual machine server and the at least one Metaverse virtual private network server are located in (reside) a Hyperscale data center, and the at least one Metaverse application gateway is located in a plurality of Metaverse provider's application environments (metaverse provider's application environments); wherein the at least one virtual machine server can be in number and size Scalable; wherein in a plurality of corresponding virtual machine servers, at least one of the hyperscale data center and a service provider builds and configures a plurality of independent metaverse virtual private network servers to serve a plurality of The corresponding Metaverse Application Gateway and a plurality of corresponding Metaverse Application Gateway smart device clients; wherein the at least one Metaverse Virtual Private Network Server smart device client and the at least one Metaverse Application Gateway A community pair of a peer-to-peer (P2P) communication relationship between intelligent device clients is built and deployed by an Internet Metaverse provider that maintains the at least one virtual machine server ; wherein the Internet Metaverse provider provides to the Metaverse provider, the Metaverse virtual private network server hosted in the at least one virtual machine server; wherein the Internet Metaverse provider Providing a single private and secure Metaverse Application Gateway to the Metaverse Provider to install the Metaverse Application Gateway in the Metaverse Provider's local network; one of the Metaverse Providers Subscribers are located on the Metaverse provider's private and secure LAN Establishing a node-to-node communication between the at least one Metaverse virtual private network server smart device client and the at least one Metaverse application gateway smart device client from anywhere. A non-transitory computer-readable medium for storing executable instructions that cause a computer to perform the following operations in response to execution: master-slave setting at least one metaverse in a client-server relationship An application gateway (metaverse application gateway, MVAG) smart device client and a metaverse virtual private network (virtual private network, VPN) server (metaverse VPN server, MVVS) smart device client application; wherein the The Metaverse Virtual Private Network Server smart device client application includes an application utility in a public cloud network; wherein a functionality of the at least one Metaverse Application Gateway smart device client ) is a class code definition of a smart device client application sent to the Metaverse Virtual Private Network server; wherein a plurality of vendor-specific software modules or applications are served by the Metaverse Virtual Private Network Loading a Metaverse Application Gateway Smart Device Client application to support a corresponding Metaverse Application Gateway Smart Device Client of the at least one Metaverse Application Gateway Smart Device Client from a different manufacturer; wherein the at least one Metaverse Application Gateway Smart Device Client Multiple device categories of gateway smart device customers include a voice, a video, a human interface device, an Internet Protocol (IP) camera, a smart lock, a smart light bulb, a remote remote control, A thermostat, a printer, a large storage device, a Bluetooth, a specific application and a specific vendor.

Images