CN117014177A - Meta universe application gateway linking mechanism for private communication architecture - Google Patents
Meta universe application gateway linking mechanism for private communication architecture Download PDFInfo
- Publication number
- CN117014177A CN117014177A CN202211522375.5A CN202211522375A CN117014177A CN 117014177 A CN117014177 A CN 117014177A CN 202211522375 A CN202211522375 A CN 202211522375A CN 117014177 A CN117014177 A CN 117014177A
- Authority
- CN
- China
- Prior art keywords
- virtual private
- private network
- metauniverse
- network server
- server
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
- 230000007246 mechanism Effects 0.000 title claims abstract description 38
- 238000004891 communication Methods 0.000 title claims description 96
- 238000000034 method Methods 0.000 claims abstract description 37
- 238000003860 storage Methods 0.000 claims description 39
- 230000006870 function Effects 0.000 claims description 3
- 230000002452 interceptive effect Effects 0.000 claims description 3
- 230000004044 response Effects 0.000 claims 3
- 238000012544 monitoring process Methods 0.000 claims 1
- 230000002093 peripheral effect Effects 0.000 claims 1
- 238000010586 diagram Methods 0.000 description 12
- 239000000126 substance Substances 0.000 description 8
- 239000011521 glass Substances 0.000 description 6
- 230000009471 action Effects 0.000 description 5
- 230000008901 benefit Effects 0.000 description 5
- 230000005540 biological transmission Effects 0.000 description 4
- JJWKPURADFRFRB-UHFFFAOYSA-N carbonyl sulfide Chemical compound O=C=S JJWKPURADFRFRB-UHFFFAOYSA-N 0.000 description 4
- 230000004048 modification Effects 0.000 description 4
- 238000012986 modification Methods 0.000 description 4
- 101100048435 Caenorhabditis elegans unc-18 gene Proteins 0.000 description 3
- 230000000903 blocking effect Effects 0.000 description 3
- 229920003258 poly(methylsilmethylene) Polymers 0.000 description 3
- 230000002776 aggregation Effects 0.000 description 2
- 238000004220 aggregation Methods 0.000 description 2
- 230000003190 augmentative effect Effects 0.000 description 2
- 230000001010 compromised effect Effects 0.000 description 2
- 238000010276 construction Methods 0.000 description 2
- 238000013467 fragmentation Methods 0.000 description 2
- 238000006062 fragmentation reaction Methods 0.000 description 2
- 230000006855 networking Effects 0.000 description 2
- 238000013519 translation Methods 0.000 description 2
- 241000509228 Thalasseus maximus Species 0.000 description 1
- 230000004075 alteration Effects 0.000 description 1
- 238000013459 approach Methods 0.000 description 1
- 238000010420 art technique Methods 0.000 description 1
- 238000003490 calendering Methods 0.000 description 1
- 239000000470 constituent Substances 0.000 description 1
- 238000002296 dynamic light scattering Methods 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 238000004519 manufacturing process Methods 0.000 description 1
- 239000000463 material Substances 0.000 description 1
- 238000013061 process characterization study Methods 0.000 description 1
- 230000000246 remedial effect Effects 0.000 description 1
- 239000000523 sample Substances 0.000 description 1
- 230000001360 synchronised effect Effects 0.000 description 1
- 238000012546 transfer Methods 0.000 description 1
- 238000012795 verification Methods 0.000 description 1
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
- H04L63/0272—Virtual private networks
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/66—Arrangements for connecting between networks having differing types of switching systems, e.g. gateways
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
- H04L63/083—Network architectures or network communication protocols for network security for authentication of entities using passwords
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
- H04L63/0876—Network architectures or network communication protocols for network security for authentication of entities based on the identity of the terminal or configuration, e.g. MAC address, hardware or software configuration or device fingerprint
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/18—Network architectures or network communication protocols for network security using different networks or channels, e.g. using out of band channels
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
- H04L67/125—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks involving control of end-device applications over a network
Abstract
A method for a linking mechanism in a public cloud network, comprising: obtaining a plurality of link authentications from a public cloud portal management device; pairing and registering with a universe virtual private network server from a universe application program gateway; establishing a plurality of initial virtual private network channels between the metauniverse virtual private network server and the metauniverse application program gateway; connecting to the metauniverse application program gateway according to the requirement between the intelligent device client of the metauniverse virtual private network server and the metauniverse application program gateway through the metauniverse virtual private network server; and running a plurality of vertical point-to-point private and secure metauniverse virtual private network server smart device client applications.
Description
Technical Field
The present invention relates to a meta-universe application gateway linking mechanism for private communication architecture.
Background
In the internet connection environment, smart device clients including smart phones, tablet computers, electronic book readers, notebook computers, personal computers, and various smart gadgets are ubiquitous. In addition to connectivity, one of the value of smart device clients is the ability to connect anywhere and anytime to obtain services from one or more service parties or servers. Services include the execution of voice, image text, live or stock information, applications, social media, messaging, email, storage, backup, calendaring, contacts, synchronization, sharing, remote desktop, internet of things (Internet of Things, ioT), etc. Another service includes real-time private and secure image, voice, text, and application communications between at least two smart device clients. Servers that serve multiple requests from smart device clients are of different types. In general, the types of servers can be divided into two categories: public cloud and private cloud. Servers in the public cloud, as implied by the term "public", offer free services of limited functionality or more complex services requiring charges, and interact with the public. Embodiments of the public cloud server include data centers, social media services, and storage/text providers via the internet. On the other hand, servers in the private cloud tend to meet private needs. The services provided by the private cloud are more private and personalized than the services provided by the public cloud.
One embodiment of a private cloud server (private cloud server, PCS) application is a private cloud storage server (private cloud storage server, PCSs). The private cloud storage server is located within a user managed local area network (local area network, LAN). It provides online and backup storage for users in a local or wide area network (wide area network, WAN). The user can use the smart device client anywhere and anytime to access information in the private cloud storage server. Thus, the private cloud storage server and associated smart device client form an embodiment of a private cloud server and client architecture.
Conventionally, there are many storage server solutions, including network attached storage (network attached storage, NAS), windows/Mac/Linux servers, and direct attached storage (direct attached storage, DAS) to meet the private cloud storage server requirements. However, the challenge faced by on-site smart device customers is how to avoid cumbersome settings to penetrate the firewall behind a router on a 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 (Internet Protocol, IP) address and open a specific port of the router in front of the private cloud storage server so that the smart device client can locate the private cloud storage server and authenticate from outside the local area network, penetrate the firewall and establish a secure channel with the private cloud storage server.
The second solution is applicable when a fixed internet protocol address is not available. The user sets a local area network router of the private cloud storage server and opens a specific port to image to the private cloud storage server. Thus, through the dynamic zone name service (dynamic domain name service, DDNS) on the local area network, the router can be located by the target smart device client. The smart device client can verify itself, penetrate through the firewall, and establish a secure channel with the private cloud storage server.
A third solution relies on another routing server in the wide area network to perform virtual private network (virtual private network, VPN) communication between the smart device client and the private cloud storage server. Virtual private network communications allow smart device clients to locate private cloud storage servers, authenticate themselves, penetrate firewalls, and establish secure channels with private cloud storage servers.
A fourth solution is to rely on another routing server in the wide area network to perform remote desktop protocol (remote desktop protocol, RDP) or Virtual Network Computing (VNC) communications between the smart device client and the private cloud storage server. Remote desktop protocol/virtual network computing communications allow smart device clients to locate private cloud storage servers, authenticate themselves, penetrate firewalls, and establish secure channels with private cloud storage servers. Another solution may be a hybrid collocation of the above solutions.
In the first case, a fixed internet protocol address is required, and the router needs to be set and configured. The disadvantage is that fixed internet protocols involve more costs and are often not available in home and small business environments. The setting up and setting up of routers can be very complex and not friendly to most consumers.
In the second case, a dynamic zone name service is required, and a router requires more complex setup. Likewise, dynamic zone name service settings involve additional cost and complexity of the system. The setting up and setting up of routers can be very complex and not friendly to 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. An external routing server or service controls and handles login/authentication between the smart device client and the server. By a public cloud-based server or service, private clouds become less private and unsafe. If for any reason the server or service fails, the communication and availability of the private cloud storage server will be compromised.
All these situations require technical expertise that is applicable to traditional enterprise environments, but these situations are not suitable for consumers that are primarily deployed in smart device customer centers.
In most conventional systems, an external or public cloud-based routing server is used by smart device clients during access to private cloud services. The use of an external server creates a number of problems to the smart device client owners.
First, trust is a continuing problem because external or public cloud-based routing servers are intermediaries of all communication transactions between smart device clients and private cloud services. It can hold all user accounts such as passwords for smart device clients and private cloud services and their corresponding internet protocol addresses. The routing server can probe for any communication between the two and consider it unsafe.
Second, as an external and public cloud-based routing server, the business model of the server's owner cannot always be consistent or synchronized with the smart device client's owner. If the routing server stops servicing for any commercial reason, there will be no remedial action or replacement option to resume servicing. Routing servers present a significant business risk to users because important links in communications may be broken without recourse.
Conventionally, in the case of communication between two smart device clients, both parties need to log into a public cloud-based server to perform real-time image, voice, text or application communication. As described above, privacy and security are easily compromised because the communication must pass through a public cloud-based server.
In addition, the internet of things device is a constituent of home smart appliances and has been plagued by fragmentation (fragmentation) from many standards such as Matter, apple HomeKit, google post, amazon Alexa, etc. Due to the problems of interactive operation, compatibility, privacy and safety of the Internet of things device, the adoption rate of the household intelligent household appliance is always lower than expected.
Accordingly, there is a need for a system and method that addresses the above-described problems. The existing invention addresses this need by having a private cloud virtual private network server (private cloud VPN server, PCVS) and a private mass gateway (private matter gateway, PMG) in the context of a private meta-universe (private metaverse, PM).
In addition, as the Internet evolves to Web 3.0, meta-boundaries begin to appear to provide a use case scenario for a particular user group, accessing a particular set of content in a private and secure manner. In the use case scene in the public cloud universe, the private universe of the prior invention is simulated in a wider range. The similarities are that the private cloud virtual private network server is replaced by a metauniverse virtual private network server (Metaverse VPN Server, MVVS) and the private substance gateway is replaced by a metauniverse application gateway (Metaverse App Gateway, MVAG). The difference is that the metauniverse application gateway is deployed by the metauniverse provider in its metauniverse application environment, rather than by the user in the case of a private substance gateway deployed in a private local area network (local area network, LAN). Furthermore, the content of the metauniverse application gateway is virtual world application specific, such as archived content, live streaming events, and domain specific content, unlike the content of the private substance gateway. Private mass gateways are more prone to internet of things devices or web services on a user's private lan. The present invention addresses this need.
Disclosure of Invention
A method for a public cloud network is disclosed. The method includes providing at least one public cloud portal (public cloud portal, PCP), at least one virtual machine server (virtual machine server, VMS), at least one public cloud portal management device, at least one metacosmic virtual private network (virtual private network, VPN) server (metaverse VPN server, MVVS), at least one virtual private network channel (tunnel), at least one metacosmic virtual private network server smart device client on the side of the at least one metacosmic virtual private network server to provide a plurality of cloud-based network services, at least one metacosmic application (metaverse application, MA) including at least one private router, at least one private local area network (local area network, LAN), at least one metacosmic application gateway (metaverse application gateway, MVAG), at least one metacosmic application gateway management device, at least one metacosmic application gateway network service, and at least one metacosmic application gateway smart device client on the side of the metacosmic application gateway. Metauniverse virtual private network server smart device clients, such as smartphones, tablet computers, notebook computers (NB) or tesla dashboards running in public clouds, and metauniverse application gateway smart device clients, such as notebook computers, internet of things (Internet of Things, ioT) devices, network attached storage (network attached storage, NAS), set-top-boxes (STB), smart devices, archived content servers, live activity content or media servers, are located on private and secure local area networks. The invention is based on a decentralised 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 comprising a metauniverse virtual private network server are typically located in one very large scale data center on a (side) public cloud network, and at least one metauniverse application along with (along with) a metauniverse application gateway and at least one metauniverse application gateway smart device client or network service are located in the application environments of a plurality of metauniverse providers. The metauniverse virtual private network server relays (relay) communication between the metauniverse virtual private network server smart device client and the metauniverse application gateway on the metauniverse virtual private network server side. According to the client request of the intelligent device of the metauniverse virtual private network server, the metauniverse virtual private network server dials back the metauniverse application program gateway according to the requirement. At least one virtual private network channel is enabled and established between a metauniverse virtual private network server and a metauniverse application gateway. At least one virtual private network channel is enabled and established between the metauniverse virtual private network server and the metauniverse virtual private network server smart device client. The two virtual private network channels are combined into a single virtual private network channel between the metauniverse virtual private network server smart device client and the metauniverse application gateway through the metauniverse virtual private network server. From this point on, all communications between the smart device client and the metauniverse application gateway through the metauniverse virtual private network server are secure and private. All metauniverse application gateway smart device clients along with network services on the metauniverse application's private local area network are accessible in local area network mode for future virtual private network links from metauniverse virtual private network server smart device clients. From this point forward, the metauniverse application gateway and metauniverse virtual private network server are in standby mode waiting for future access by metauniverse virtual private network server smart device clients in the public cloud of the internet.
The at least one public cloud portal is initially accessed by the at least one metauniverse virtual private network server client to log in and obtain a link authentication comprising a metauniverse virtual private network server password, a virtual machine server area name, a metauniverse virtual private network server virtual private network client configuration file, and a metauniverse virtual private network server virtual private network client password. The metauniverse virtual private network server virtual private network client configuration file and the metauniverse virtual private network server virtual private network client password can be transmitted to any authorized metauniverse virtual private network server client for future access. Using these two authentications, an authorized metauniverse virtual private network server client may connect to a target virtual machine server through a public cloud portal, and then to a corresponding metauniverse virtual private network server. After connection, the first virtual private network channel between the metauniverse virtual private network server client and the metauniverse virtual private network server is enabled. Once (or if) multiple proper authentications are established, at least one metauniverse application gateway in the metauniverse application's private lan and at least one metauniverse virtual private network server in the public cloud will enable a third virtual private network channel as required. At least one metauniverse virtual private network server in the public cloud will dial back at least one metauniverse application gateway in the private local area network in sequence to enable the first virtual private network channel. Once (or if) the first virtual private network channel is enabled by the metaverse virtual private network server, at least one metaverse application gateway in the metaverse application's private local area network establishes the first virtual private network channel with at least one metaverse virtual private network server in the public cloud. The second virtual private network channel is also enabled by the metauniverse virtual private network server for the metauniverse virtual private network server smart device client. The at least one metaspacecraft virtual private network server smart device client initiates a request to connect to the at least one metaspacecraft virtual private network server through the metaspacecraft virtual private network server virtual private network client configuration file to establish a third virtual private network channel as required in case the at least one metaspacecraft virtual private network server smart device client attempts to access any metaspacecraft application gateway smart device client or metaspacecraft network service on the metaspacecraft application's local area network. At least one metaverse virtual private network server in the public cloud will dial back at least one metaverse application gateway in the metaverse application's private local area network in order to establish a third virtual private network channel as required, and relay communications between the metaverse virtual private network server smart device client and the metaverse application gateway from the internet. The metacosmic application gateway is located on the private local area network of the metacosmic application. The second virtual private network channel established according to the requirement and the third virtual private network channel established according to the requirement are combined into a single virtual private network channel passing through the metauniverse virtual private network server between the intelligent device client of the metauniverse virtual private network server and the gateway of the metauniverse application program. From this point forward, all communications between the metauniverse virtual private network server smart device client and the metauniverse application gateway through the metauniverse virtual private network server are secure and private. All metauniverse application gateway smart device clients along with network services on the metauniverse application's private lan may be accessed in lan mode for future virtual private network links from the metauniverse virtual private network server smart device clients. The metauniverse application gateway and metauniverse virtual private network server are both in standby mode awaiting future access by metauniverse virtual private network server smart device clients in the public cloud of the internet.
In summary, the invention establishes at least one metauniverse virtual private network server and at least one metauniverse application gateway master-slave in a client server relationship. The at least one metauniverse virtual private network server and the at least one metauniverse application gateway communicate with each other privately and securely over a public cloud network. The invention establishes at least one metauniverse virtual private network server intelligent device client and at least one metauniverse virtual private network server master-slave mode in a server relation of a client. The invention establishes that at least one metauniverse application gateway intelligent device client, at least one metauniverse application gateway metauniverse network service and at least one metauniverse application gateway master-slave mode are in a server relation of a client. The invention establishes at least one metauniverse virtual private network server intelligent device client and at least one metauniverse application program gateway master-slave mode in a server relation of a client. At least one metauniverse virtual private network server smart device client and at least one metauniverse application gateway communicate with each other through a public cloud network. The at least one metauniverse virtual private network server smart device client and the at least one metauniverse application gateway smart device client communicate with each other privately and securely over the public cloud network. The at least one metauniverse virtual private network server smart device client and the at least one metauniverse application gateway metauniverse network service are privately and securely in communication with each other through the public cloud network.
The vpn channel is based on industry standards, ensuring privacy and security, and anti-outdated interworking (interoperability) and compatibility (compatibility) in communications. All metaverse application gateway clients, including internet of things devices, along with network services on private local area networks are accessible in local area network mode from metaverse virtual private network server clients through virtual private network links that are performed in a private and secure manner. The prior art relies on cloud-mode access by clients or internet of things devices on a private local area network through cloud-based relay servers. Unlike the prior art, the present invention relies solely on lan mode access through a virtual private network channel. Due to industry accepted strength of the virtual private network channel, the access text itself is never monitored or recorded. Thus, the present invention is more private and secure in accessing communications than most other prior art techniques. The network link is based on the internet protocol.
Thus, the solution is platform independent and compatible with all existing fragmented (fragmented) internet of things device platforms, whether Matter, apple HomeKit, google Nest, or Amazon Alexa, so long as the internet of things device is discoverable and networking-capable by a local area network. To further consider security, link authentication including a metauniverse virtual private network server password, a virtual machine server area name, a metauniverse virtual private network server virtual private network client profile, and a metauniverse virtual private network server virtual private network client password may be revoked and reissued via the internet according to a request from an administrator account of a cloud metauniverse virtual private network server client. The invention requests future meta-universe application gateway clients, i.e. Internet of things devices, to operate in a local area network mode instead of in a cloud mode to achieve absolute privacy and security of users. By doing so, the internet of things devices no longer need to provide their own cloud-based relay servers. The corresponding benefits brought to the user are:
A. Breaking monopoly of application programs and access of the Internet of things devices by mobile Operating System (OS) providers such as Apple and Google;
B. convenience of access from anywhere in the world via the internet;
C. real access privacy and security;
D. meanwhile, the interactive operation and compatibility with the Matter, apple Homekit, google Nest and Amazon Alexa are realized;
E. the entrance threshold of the internet of things device manufacturing is reduced because the internet of things manufacturer no longer needs a cloud-based relay server;
F. reinfusion of consumer confidence to stimulate future internet of things device sales;
G. the method opens up a new vertical application program for the market of the Internet of things in the aspects of safe chat, voice, image and the like; and
H. based on industry internet protocol in the network and the implementation of anti-obsolete communication access.
The invention provides the function of accessing a metauniverse application program gateway intelligent device client or an Internet of things device in home from another metauniverse virtual private network server intelligent device client anywhere in the world; while also maintaining the benefits of access convenience, ease of deployment, great privacy and security, complete compatibility/interoperability and high performance.
Drawings
Fig. 1 is a schematic diagram of a conventional cloud network infrastructure according to an embodiment of the present invention.
Fig. 2 is a schematic diagram of a cloud network infrastructure of a link mechanism based on session information frame communication in a private cloud routing server, a private cloud callback server, a meta-space network service, a private cloud routing server smart device client, and a private cloud callback server smart device client according to an embodiment of the present invention.
Fig. 3 is a schematic diagram of a cloud network infrastructure based on a linking mechanism of multiple vpn channels between a metacosmic application gateway, a metacosmic vpn server, a metacosmic network service, a metacosmic application gateway smart device client, and a metacosmic vpn server smart device client according to a first embodiment of the present invention.
Fig. 4 is a schematic diagram of a cloud network infrastructure based on a linking mechanism of multiple vpn channels between a metacosmic application gateway, a metacosmic vpn server, a metacosmic network service, a metacosmic application gateway smart device client, and a metacosmic vpn server smart device client according to a second embodiment of the present invention.
Fig. 5 is a schematic diagram of a cloud network infrastructure based on a linking mechanism of multiple virtual private network channels among a private substance gateway, a private cloud virtual private network server, a private network service, a private substance gateway smart device client, and a private cloud virtual private network server smart device client according to an embodiment of the present invention.
Fig. 6 is a schematic diagram of a cloud network infrastructure based on a linking mechanism of multiple vpn channels between a metacosmic application gateway, a metacosmic vpn server, a metacosmic network service, a metacosmic application gateway smart device client, and a metacosmic vpn server smart device client according to a third embodiment of the present invention.
Fig. 7 is a flowchart of a communication flow of a point-to-point link mechanism between a private cloud routing server, a private cloud callback server smart device client, and a private cloud routing server smart device client through a cloud network according to an embodiment of the present invention.
Fig. 8 is a schematic diagram of a communication flow of a point-to-point linking mechanism between a metacosmic application gateway, a metacosmic virtual private network server smart device client, and a metacosmic application gateway smart device client through a cloud network according to an embodiment of the present invention.
FIG. 9 is a flow chart of a communication flow of a point-to-point linking mechanism between a metauniverse application gateway, a metauniverse virtual private network server smart device client, and a metauniverse application gateway smart device client over a cloud network based on a server farm, a computer resource aggregate, and a virtual machine server in accordance with an embodiment of the present invention.
Fig. 10 is a flowchart of a communication flow of registering a public cloud portal management device to a public cloud portal according to an embodiment of the present invention.
FIG. 11 is a flow chart of a communication flow for initializing and configuring a metacosmic application gateway by a metacosmic application gateway management device according to an embodiment of the invention.
Fig. 12 is a flow chart of one communication flow of links from mvvs_vpn utility to mvag_vpn utility and links between a metaverse virtual private network server device client and a metaverse application gateway device client in a private lan according to an embodiment of the present invention.
Fig. 13 is a flowchart of a communication flow of a metauniverse virtual private network server device client according to an embodiment of the present invention.
Fig. 14 is a flow chart of a communication flow of a point-to-point linking mechanism between a metacosmic application gateway, a metacosmic virtual private network server smart device client, and a metacosmic application gateway smart device client through a cloud network according to a third embodiment of the invention.
Fig. 15 is a flowchart of a communication flow based on a point-to-point linking mechanism between a metauniverse application gateway, a metauniverse virtual private network server smart device client, and a metauniverse application gateway smart device client by a cloud network based on a server farm, a computer resource aggregate, and a virtual machine server according to a third embodiment of the present invention.
Fig. 16 is a flow chart of a communication flow of links from mvvs_vpn utility to mvag_vpn utility and links between a metauniverse virtual private network server device client and a metauniverse application gateway device client in a private lan according to a third embodiment of the present invention.
Detailed Description
The present invention relates to networking (networking), and more particularly, to 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 a patent application and its requirements. Various modifications to the embodiments and the generic principles and features described herein will be readily apparent to those skilled in the art. Thus, the present invention is not intended to be limited to the embodiments shown, but is to be accorded the widest scope consistent with the principles and features described herein.
Throughout the discussion herein, the term "client" is interchangeable with "smart device client". Throughout the discussion herein, the term "router" is generally interchangeable with "gateway," "access point," and/or "network address translation" (network address translation, NAT). "platform" is generally interchangeable with "ecosystem".
The system and method of the present invention addresses the following challenges in a consumer oriented environment to enable smart device clients in a local area network (wide area network, WAN) to obtain services from a private cloud storage server (Private Cloud Storage Server, PCSS) or any private cloud server (Private Cloud Server, PCS):
1. the private cloud server is accessed anytime and anywhere.
2. A private cloud server behind a firewall is accessed using a fixed or dynamic internet protocol (Internet Protocol, IP) address.
3. A public cloud-based routing server is not required in a wide area network.
4. No additional routers need be provided in the local area network (local area network, LAN).
5. And carrying out identity authentication with the private cloud server.
6. And establishing a secure channel with the private cloud server.
If these challenges can be met and resolved, the deployment of private cloud services or services will increase exponentially due to the simplicity and availability of plug and play. By not using a public cloud based routing server, technical and business problems are eliminated. Private cloud servers for storage, remote desktop services, and internet of things (Internet of Things, ioT) are becoming very 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 servers into two functional blocks. The functional blocks include private cloud routing services (PrivateCloud Routing Service, PRS) and metacosmic network services (Metaverse Network Service, MVNS).
Metacosmic network services are designed to be implemented by smart device clients in private network environments (whether wired
Whether wireless) are managed and accessed. An embodiment of the metacosmic network service includes an application program 5 server to provide remote desktop protocol (remote desktop protocol, RDP), virtual network
Computing (VNC), office tools, media player, and another user-specific application. The metacosmic network service may also be used as a storage server that contains multiple megabyte (TB) storage that serves the private cloud. The functionality of the private cloud routing services of multiple Metaverse application gateways (Metaverse ApplicationGateway, MVAG) may then be aggregated into one Metaverse application gateway. The 0-tuple application gateway may be commonly referred to as a private cloud router.
The system and method of the present invention solves the following challenges in a consumer-oriented environment using smart device customers in a wide area network that can manage and access metacosmic network services from a metacosmic application gateway:
1. the meta-space application gateway is accessed anytime and anywhere.
52. A metauniverse application gateway behind a fixed or dynamic access firewall is used.
3. No external or public cloud-based routing servers are required in the wide area network.
4. No additional router is required to be provided in the local area network.
5. And carrying out identity verification with the meta-universe application gateway.
6. And establishing a secure channel with the private cloud server for management and access.
The 0-ary universe application gateway can meet the challenges described above, from different manufacturers and suppliers
A class (hierarchical) private cloud server can be broken down into simpler metauniverse web services, and the complexity of private cloud setup, and access removed.
The system and method of the present invention aims to provide a meta-universe without using a routing server
Application gateway, meta-cosmic network services, and client architecture. The system and method of the present invention solves 5 the above-described challenges to allow clients to access metacosmic network services at any time and place. The system and method also use
The fixed or dynamic internet protocol accesses the metacosmic network service behind the firewall without additional router setup or public cloud-based routing servers in the wide area network to perform authentication with the metacosmic application gateway and directly establish a secure channel with the metacosmic network service.
As shown in fig. 1, the cloud network infrastructure includes public cloud 100, public cloud server 113, public 0 common routing server 112, and public virtual private network (virtual private network, VPN) routing
Server 114, smart device client 101 in wide area network, router_p 102 and router_s 103.Router_s 103 is connected between the local area network 105 and the internet in public cloud 100. Router_s 102 connects between the local area network 104 and the internet in public cloud 100. Smart device clients 106, 107 and private cloud server 108 are behind local area network 104. Smart device clients 109, 110, and 111 follow local network 105. The smart device client may be a personal computer, a notebook computer, a tablet computer, a tesla dashboard, a smart phone, an electronic book reader, a global positioning system, a smart television, a set top box, an MP3 player, or any networking-enabled embedded device.
Smart device clients are represented in the cloud network infrastructure as 101, 106, 107, 109, 110, and 111. Any of the smart device clients described above are interchangeable in the discussion herein. The discussion herein focuses on smart device client 109 as representative of this document.
Indeed, there are three contexts in which a smart device client 101, 107, or 109 may connect to a private cloud server 108. First, the smart device client 107 decides whether the target is in a locally accessible local area network 104 and decides to connect directly to the private cloud server 108. Second, the smart device client 101 decides that the target is not in the locally accessible local area network 104 and decides to connect to the public cloud 100 through the wide area network. The wide area network locates router_p 102 and local area network 104, and connects to private cloud server 108. Third, the smart device client 109 decides that the target is not in the local area network 105 that is locally accessible and decides to connect to the public cloud 100 in the wide area network through the local area 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 context and the second context are two special cases and derivative cases of the third context. Therefore, a third case of broader scope and complexity is of benefit.
As shown in fig. 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, a private cloud callback Server (PCCBS) smart device client 201, router_p202 and router_s 203 in the wide area network. Router_s203 connects to the internet in local area network 205 and public cloud 200. Router_s203 is connected between the local area network 205 and the internet in public cloud 200. The routing server box (not shown) or the customer box message box S215 may be hosted within an email server, a text message server, a web server, or any type of server. Any type of server may host security information for exchanging information among private cloud routing server (Private Cloud Routing Server, PCRS) 208, private cloud callback server 216, private cloud routing server smart device clients 206, 207, and private cloud callback server smart device clients 209, 210, 211, 201, 221, with private cloud routing server 208 and private cloud callback server 216 serving as servers, and private cloud routing server smart device clients 206, 207 and private cloud callback server smart device clients 209, 210, 211, 201, 221 serving as clients. Callback server information boxes (not shown) or customer information boxes message box S215 are accessible and under security and private control of private cloud routing server 208 and private cloud callback server 216 as servers or private cloud routing server smart device customers 206, 207 and private cloud callback server smart device customers 209, 210, 211, 201, 221 as customers. The security and business model of the information box is well understood and appreciated by the user in the industry. Any of the information boxes can be immediately replaced or redeployed, regardless of the reason for closing, without jeopardizing communication between the servers and clients in the private cloud infrastructure.
Fig. 3 is a schematic diagram of a cloud network infrastructure based on a security linking mechanism between a metacosmic application gateway, a metacosmic virtual private network server, a metacosmic application gateway smart device client, and a metacosmic virtual private network server smart device client for exploring and accessing a public-on-end metacosmic network service according to a first embodiment of the present invention. The mechanism of linking between metauniverse virtual private network server device clients and metauniverse application gateway device clients on private local area networks in the cloud has five phases:
the first stage: obtaining a plurality of link authentications from a public cloud portal management device;
and a second stage: pairing and registering with a metauniverse virtual private network server from a metauniverse application program gateway;
and a third stage: establishing a plurality of initial virtual private network channels between a metauniverse virtual private network server and a metauniverse application program gateway;
fourth stage: connecting the intelligent device client of the metauniverse virtual private network server and the metauniverse application program gateway to the metauniverse application program gateway according to requirements through the metauniverse virtual private network server; and
Fifth stage: running (run) multiple vertical peer-to-peer (P2P) private and secure metaspacecraft virtual private network server smart device applications between at least one metaspacecraft virtual private network server smart device client and at least one metaspacecraft application gateway smart device client, at least one metaspacecraft application gateway network service, or another metaspacecraft virtual private network server smart device client.
In the first stage: obtaining a plurality of link authentications from a public cloud portal management apparatus: first, the public cloud portal website management device 377, which itself is the metauniverse virtual private network server device client 301, logs into the public cloud portal website device utility (not labeled) of the public cloud portal website 330 to obtain the metauniverse virtual private network server device client authentication 379 and the metauniverse virtual private network server authentication 380. The metauniverse virtual private network server device client authentication 379 includes metauniverse virtual private network server client configuration 383 and metauniverse virtual private network server client login 382. The meta-cosmic vpn web server authentication 380 includes domain_mvvs 375 and passcode_mvvs 376. The metauniverse virtual private network server device client authentication 379 and metauniverse virtual private network server authentication 380 are both stored in the public cloud portal website device client 378. The metauniverse virtual private network server authentication 380 is transmitted later by email to the metauniverse application gateway management device 373 to connect to the metauniverse application gateway 308. The metauniverse virtual private network server device client authentication 379 is later transmitted by email to the metauniverse virtual private network server device client 321 to connect to the metauniverse virtual private network server 316.
In the second stage: pairing and registering with a metauniverse virtual private network server from a metauniverse application gateway: the MVAG_device utility 374 is used by the metaspace application gateway management Device 373 to initialize and provision the metaspace application gateway 308 from the metaspace application gateway management Device 373. As shown in FIG. 3, meta-space application gateway 308 includes MVAG_device utility 371 and MVAG_VPN utility 372. The meta-cosmic application gateway management device 373 is located on the same entity lan 304 as the meta-cosmic application gateway 308 to perform security purpose setting, and to avoid hacking on the internet or wide area network. The meta-space application gateway management Device 373 is itself a meta-space application gateway smart Device client 307, which includes an application utility mvag_device utility 374.MVAG_device utility 374 includes an entry (entry) for Domain_MVVS 375 and an entry for passcode_MVVS 376. The portal of Domain MVVS 375 is used to set the server area address of the corresponding metauniverse virtual private network server. The entry of passcode_mvvs 376 is used to set the server password of the corresponding metauniverse virtual private network server. First, the metauniverse application gateway management device 373 sets the metauniverse virtual private network server authentication by setting its area name through the entries of the domain_mvvs 375 and passcode_mvvs 376. The metauniverse virtual private network server authentication, domain_mvvs 375, and passcode_mvvs 376 are used to communicate with mvag_device utility 371 in metauniverse application gateway 308.
In the third stage: establishing a plurality of initial virtual private network channels between a metauniverse virtual private network server and a metauniverse application gateway: after the metauniverse virtual private network server 316 is paired and registered with the metauniverse virtual private network server 316 from the metauniverse application gateway 308, mvag_vpn utility 372 connects to mvvs_vpn utility 3720 and enables a third virtual private network channel between mvag_vpn utility 372 and mvvs_vpn utility 3720. The mvvs_vpn utility 3720 then dials back the meta-universe application (Metaverse application, MA) 370 to enable the first virtual private network channel between the mvvs_vpn utility 3720 and the mvag_vpn utility 372. The metacosmic application 370 includes at least one metacosmic application gateway (e.g., metacosmic application gateway 308). At least one metauniverse application gateway (e.g., metauniverse application gateway 308) includes mvag_vpn utility 372. Between mvvs_vpn utility 3720 and mvag_vpn utility 372, mvvs_vpn utility 3720 may establish a third virtual private network channel as needed. The MVVS VPN utility 3720 may also wait for completion of the establishment of the second virtual private network channel between the metauniverse virtual private network server smart device client 309, 310, 311, or 321 and the metauniverse virtual private network server 316 as needed for the third virtual private network channel established as needed between the MVVS VPN utility 3720 and mvag_vpn utility 372. Thereafter, from the cloud of the internet, mvag_vpn utility 372 may establish a first virtual private network channel between mvag_vpn utility 372 and mvvs_vpn utility 3720. MVVS VPN utility 3720 may also enable a second virtual private network channel between MVVS VPN utility 3720 and any of the universe virtual private network server device clients 301, 309, 310, 311, or 321. The metaspacecraft virtual private network server 316 is then ready to take further action as required by any of the metaspacecraft virtual private network server smart device clients 301, 309, 310, 311, or 321. Within metauniverse virtual private network server 316, mvvs_vpn utility 3720 communicates with mvvs_device utility 3710. MVVS Device utility 3710 remains in the loop waiting for the future metauniverse virtual private network server smart Device client request.
In the fourth phase: through the metauniverse virtual private network server, the intelligent device client of the metauniverse virtual private network server and the metauniverse application program gateway are connected to the metauniverse application program gateway according to requirements: within metauniverse virtual private network server 316, mvvs_vpn utility 3720 communicates with mvvs_device utility 3710. Mvvs_vpn utility 3720 stays in the loop waiting for the meta-space virtual private network server smart device client request. First, the metauniverse virtual private network server Device client 321 registers metauniverse virtual private network server client authentication with the mvvs_device utility 3710, including a metauniverse virtual private network server client profile and a metauniverse virtual private network server client login. MVVS Device utility 3710 communicates a metauniverse virtual private network server client authentication and a link request internal to metauniverse virtual private network server 316 to MVVS VPN utility 3720. After registration, the metauniverse virtual private network server device client 321 connects to the mvvs_vpn utility 3720, and a second virtual private network channel is established as needed between the metauniverse virtual private network server device client 321 and the mvvs_vpn utility 3720. Next, between mvvs_vpn utility 3720 and meta-space application 370, mvvs_vpn utility 3720 establishes a third virtual private network channel as needed. The metacosmic application 370 includes at least one metacosmic application gateway (e.g., metacosmic application gateway 308). At least one metauniverse application gateway (e.g., metauniverse application gateway 308) includes mvag_vpn utility 372. The second virtual private network channel established on demand and the third virtual private network channel established on demand are combined into a single virtual private network channel between the metauniverse virtual private network server device client and mvag_vpn utility 372. Mvag_vpn utility 372 resides in meta-cosmic application gateway 308.
In the fifth stage: running multiple vertical point-to-point private and secure metauniverse virtual private network server smart device client applications between at least one metauniverse virtual private network server smart device client and at least one metauniverse application gateway smart device client, at least one metauniverse application gateway network service, or another metauniverse virtual private network server smart device client. Via communication paths 322, 324, and 323, respectively, the metaspacecraft virtual private network server smart device clients 301, 311, and 321 are able to locate the cosmic application gateway 308 according to the mechanisms disclosed in FIGS. 8-13. The metaspace application gateway 308 and metaspace virtual private network server 316 construct a Virtual LAN (VLAN) 340 and a virtual LAN 3400, allowing authorized metaspace virtual private network server smart device clients 301, 311, and 321 to join as members of the virtual LAN 340 and virtual LAN 3400 and connect to the metaspace application gateway device client 306, or the metaspace network service 328 (e.g., metaspace application gateway network service), or another metaspace virtual private network server device client (not shown), assuming that the other metaspace virtual private network server device client (not shown) has also successfully connected to the MVVS VPN utility 3720. Please refer to fig. 8 for the vpn channel and the connection flow. The metauniverse virtual private network server smart device client 301 may initiate private and secure communications as a host through an installed program. Through a vertical point-to-point private and secure metauniverse virtual private network server smart device client application (not shown) provided by public cloud portal 330, metauniverse virtual private network server smart device client 311 or 321 may receive a communication invitation as a guest through an installed program and join a private and secure communication session with metauniverse virtual private network server smart device client 301.
In the fifth stage, at least one metauniverse application gateway smart device client and metauniverse virtual private network server smart device client application form a master-slave relationship. The metauniverse virtual private network server smart device client application comprises an application utility on a public cloud network. The functionality of at least one metauniverse application gateway smart device client is transferred to a class code (class code) definition of the metauniverse virtual private network server smart device client application. Vendor specific software modules or applications are loaded by the metauniverse virtual private network server smart device client application to support corresponding metauniverse application gateway smart devices from different manufacturers. The device classes include voice, image, human interface devices, internet protocol cameras, smart locks, smart lights (Smart lights), remote controls, thermostats, printers, mass storage devices, bluetooth, specific applications, specific vendors, and the like.
As shown in fig. 3, when a metauniverse virtual private network server smart device client 301 wants to initiate a communication session as a host, a program installed on the host metauniverse virtual private network server smart device client first locates and logs in to public cloud portal 330 through communication path 322. After metacosmic virtual private network server 316 locates cosmic application gateway 308, it joins virtual local area network 340. The metauniverse virtual private network server smart device client promises to join the chat communication as host 301. The program allows the metauniverse virtual private network server smart device client 301 to create and host a communication session. The program broadcasts a host session to invite the communication guest 321. Thereafter, the program initiates scanning for identifiable guest-meta-universe virtual private network server smart device clients 321. Once the guest is authorized, the metauniverse virtual private network server smart device client 301 may initiate private and secure communications as a host with the authorized guest metauniverse virtual private network server smart device client 321. Private and secure communications include images, voice, text, or applications. The application may be a host and guest recognizable program, utility, operation, or transaction.
If the metauniverse virtual private network server smart device client 311 or 321 wants to join the communication session as a guest, the program installed on the guest metauniverse virtual private network server smart device client first locates and logs into the public cloud portal 330 via communication path 324 or 323, respectively. After the metaspacecraft virtual private network server 316 locates the spacecraft application gateway 308, it joins the virtual local area network 340 under the server. The metauniverse 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. Upon receiving the communication invitation, the metauniverse virtual private network server smart device client 311 or 321 may join the communication session as a guest. The program then initiates scanning of the identifiable host. After the host is identified, the program logs in to the authentication through communication prompted by the host. Once authenticated, the metauniverse virtual private network server smart device client 311 or 321 may join the communication session. The metauniverse virtual private network server smart device client 311 or 321 initiates private and secure communications as a guest with the metauniverse virtual private network server smart device client 301. Private and secure communications include images, voice, text, or applications. The application may be a host and guest recognizable program, utility, run, or transaction.
In another embodiment of the present invention, under the metauniverse application gateway and metauniverse virtual private network server, the metauniverse virtual private network server smart device client may establish private and secure communications with any service reachable over the physical local area network LAN1 350 or virtual local area networks 340 and 3400. As shown in FIG. 3, once the metaverse VPN server smart device client 301, 311, or 321 locates and logs into the public cloud portal 330, it can access any metaverse Web service 328 reachable over the physical local area networks LAN1 and LAN2 360 and virtual local area networks 340 and 3400 under the metaverse application gateway and metaverse VPN Web server through the secure communication path 325. Metauniverse network services include the execution of voice, image, live or stock information, applications, social media, information transfer, email, storage, backup, calendar, contacts, synchronization, sharing, remote desktop, internet of things, and the like.
Multiple entities (entities) are introduced to allow secure communication path 325, and include, but are not limited to: an administrator, a management device, a metauniverse application gateway utility, a metauniverse virtual private network server utility, a metauniverse application gateway smart device client, and a metauniverse virtual private network server smart device client. The definition of the above entities is as follows. The utility is a utility running in the meta-space application gateway. The management device is a device used by an administrator to set up the meta-space application gateway. A metauniverse application gateway smart device client is a device used by an invitee to communicate with a metauniverse application gateway. The invitees are the entity parties invited by the administrator to access the meta-cosmic application gateway services and resources. The invitee device is a metauniverse application gateway smart device client used by the invitee to communicate with the metauniverse application gateway.
A number of terms are introduced, including Passcode MVVS, domain MVVS Client, MVVS Client Profile, and MVVS Client logic. The definition of the above terms is as follows. Passcode MVVS is the password generated by the public cloud portal for the corresponding metauniverse virtual private network server 316. Domain_mvvs_client is an area address generated by the authentication of a metauniverse virtual private network server formed by the public cloud portal sites passcode_mvvs and domain_mvvs together. Mvvs_client_profile is a virtual private network Profile of a metacosmic virtual private network server smart device Client connected to a corresponding metacosmic virtual private network server 316. Mvvs_client_login is a virtual private network Login password for a metauniverse virtual private network server smart device Client connected to a corresponding metauniverse virtual private network server 316. MVVS_client_Profile and MVVS_client_Login together form a meta-cosmic virtual private network server authentication.
Other terms that are not related to the meta-space application gateway are: the meta-universe application and virtual local area network subnet are defined as follows. The metauniverse application program is a private network subsystem and comprises a network router, a private local area network, a metauniverse application program gateway, at least one metauniverse network service and at least one metauniverse application program gateway intelligent device client. The virtual local area network subnet is a subnet setting of the element universe application gateway virtual private network. The designated private subnetwork is configurable and variable for security purposes.
The device client 301 is itself a metauniverse virtual private network server smart device client that includes an application utility, a public cloud portal device client utility 378. Public cloud portal device client utility 378 includes metauniverse virtual private network server device client authentication 379 and metauniverse virtual private network server authentication 380. The metauniverse virtual private network server device client authentication 379 includes metauniverse virtual private network server client configuration and metauniverse virtual private network server client login. The meta-space virtual private network server authentication 380 includes domain_mvvs and passcode_mvvs.
Typical metauniverse virtual private network server smart Device Client 321 includes MVVS Device Client utility 381.MVVS_device_client utility 381 contains metacosmic virtual private network server Client configuration 383 and metacosmic virtual private network server Client login 382. The metauniverse virtual private network server client configuration 383 is used to connect to the corresponding metauniverse virtual private network server 316. The metauniverse virtual private network server client login 382 is used to login to the metauniverse virtual private network server 316. The metauniverse virtual private network server 316 includes mvvs_device utility 3710 and mvvs_vpn utility 3720.MVVS Device utility 3710 is for communication with metaspace application gateway management Device 373. Mvvs_vpn utility 3720 is capable of communicating with metauniverse application gateway 308 through at least one virtual private network channel. The metaspacecraft virtual private network server 316 serves as a broker to relay communications between the metaspacecraft virtual private network server smart device clients 321, 301, 311 and the metaspacecraft application gateway 308, and to call back the metaspacecraft application gateway 308 as required according to the metaspacecraft virtual private network server smart device client request.
Fig. 4 is a schematic diagram of a second embodiment of the present invention. The meta-space application gateway 408 is connected to the local area network 404 of router_p 402 in a similar manner to the local area network 204 of fig. 2 where the private cloud routing server 208 is connected to router_p 202. The meta-cosmic application gateway 408 is also connected to the physical local area network LAN2 460 downstream. A metacosmic network service 436 and a metacosmic application gateway smart device client 435 are connected downstream. The metacosmic network service 436 may be connected to the metacosmic application gateway 408 through the local area network 434, accessed through the communication path 426. So long as virtual local area network 440 and physical local area networks LAN1 450 and LAN2 460 can be explored and accessed by metacosmic application gateway 408 and metacosmic virtual private network server smart device clients 411, 410, 409, 401, and 421 across clouds through metacosmic virtual private network server 416, all metacosmic network services 428 and 436 and metacosmic application gateway smart device clients 406, 407, and 435 become accessible.
Fig. 5 is a schematic diagram of an embodiment of the present invention. The private mass gateway 508 is connected to the local area network 504 of the private local area network Router 502 in a similar manner to the local area network 204 of the private cloud routing server 208 to router_p 202 in fig. 2. As long as the private meta space-1 550 and physical local area network 504 can be explored and accessed by the private substance gateway 508 and private cloud virtual private network server smart device clients (e.g., virtual reality glasses 551, notebook 552, smartphones 553, tablet 554, virtual reality glasses 561, notebook 562, smartphones 563, and tesla dashboards 564) that cross the cloud through the virtual machine server-1 531 and private cloud virtual private network server 516, all private network services (not labeled) and private substance gateway smart device clients 521, 522, 523, 524, 525, and 526 become accessible.
Fig. 6 is a schematic diagram of a third embodiment of the present invention. In a manner similar to the 3 rd pixel cosmic application gateway 308 being connected to the private lan 304 of the router 302, the metacosmic application gateway 680 is connected to the private lan 604 of the private lan router 602. As long as the metaspace application-1 650 and the physical local area network 604 are explored and accessed by the virtual machine server 631 and the metaspace virtual private network server 616 across the cloud of metaspace virtual private network server smart device clients (e.g., virtual reality glasses 651, notebook 652, smart phone 653, tablet 654, virtual reality glasses 661, tablet 662, smart phone 663, and tesla dashboard 664) and the metaspace application gateway 608, all metaspace network services (not labeled), and the metaspace application gateway smart device clients 6250, 6251, 6252, and 622 become accessible. There may be many meta-universe providers in public cloud 600. Each provider builds a metaspace cloud provider-1 641, a metaspace cloud provider-2 642, a metaspace cloud provider-3 644, and a metaspace cloud provider-N643. In metaspace cloud provider-1 641, a plurality of metaspace applications, such as metaspace application-1 650, metaspace application-2 6320, metaspace application-3 6330, and metaspace application-N6340, may be deployed through metaspace provider portal-1 630. Within metauniverse application program-1 650 is a corresponding virtual machine server-1 630 that contains metauniverse virtual private network server 616. The metauniverse virtual private network server 616 is logically connected to the application virtual network-1 640, which houses the router 602, private lan 604. Below the application virtual network-1 640, there are a number of entities and logical devices, resources, and services, such as a metauniverse application gateway 608, live streaming events 6250, 6251, and 6262, and an archive content server 622. Live streaming event-a 6250, live streaming event-B6251, and live streaming event-C6252 are a set of internet protocol cameras set by metacosmic provider-1 (not shown) for creating a specific metacosmic application (e.g., metacosmic application-1 650) to stream specific live events for a specific population of metacosmic subscribers. The metauniverse subscriber can access metauniverse event content through a metauniverse virtual private network server device client, tesla dashboard 664, smart phone 663, tablet 662, and virtual reality glasses 661, or through other device clients (including notebook 652, smart phone 653, tablet 654, and virtual reality glasses 651) under guest lan router 603. As shown in FIG. 6, the metaspace cloud provider-1 641 is scalable and developable. In public cloud 600, there may be multiple metacosmic provider clouds that coexist with each other, such as metacosmic cloud provider-1 641, metacosmic cloud provider-2 642, metacosmic cloud provider-3 644, and metacosmic cloud provider-N643. In the same metaspace cloud provider-1641, there may be multiple metaspace applications deployed by the same metaspace provider portal, such as metaspace application-1 650, metaspace application-2 6320, metaspace application-3 6330, and metaspace application-N6340. A metauniverse provider can provide its subscribers with private and secure access to devices, services, content, or events with the aid of the present invention. Types of devices, services, content, or events include media content services, live event streams, games, virtual tours, virtual museums, private conversations in text, voice, images, cryptocurrency transactions, virtual Reality (VR)/augmented Reality (Augmented Reality, AR) experiences, virtual avatars, and the like.
Fig. 7 is a flowchart of a communication flow of a point-to-point link 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, the private cloud callback server smart device client does not need a public virtual private network routing server to connect and access to the private cloud routing server 728, or another private cloud callback server smart device client, or another private cloud routing server smart device client, or through a network service under the cloud network server. As shown in fig. 7, private cloud callback server smart device client 1 and private cloud routing server 728 on the cloud network can communicate with each other without going through public routing server 112 or public virtual private network routing server 114 of fig. 1. First, private cloud callback server smart device client 1 725 requests to connect to private cloud callback server device utility (server component) 724 with its internet protocol address and port capabilities in the transmission control protocol/user data information protocol. The internet protocol address and port of private cloud callback server smart Device client 1 725 and pccbs_device utility 724 remain active. Private cloud callback server device utility (server component) 724 receives registration through callback server info box (not shown). Next, also through the customer information box message_box_s 215 of fig. 2, the private cloud callback server smart device client 1 725 requests a link to the pccbs_vpn utility (client part) 723 from the private cloud callback server device utility (server part) 724. The pccbs_vpn utility (server portion) 724 receives the request through a callback server info box (not labeled) and notifies the private cloud callback server smart device client 1 of the internet protocol address and port capabilities in the transmission control protocol/user data info protocol and its connection intention to the pccbs_vpn utility (client portion) 723 (step 703). Next, the pccbs_vpn utility (client portion) 723 replies to itself with registration to the pccbs_vpn utility (server portion) 724. The registration includes the internet protocol address and port capabilities of the pccbs_vpn utility (client portion) 723 in the transmission control protocol/user data information protocol. The internet protocol address and port capability of private cloud routing server apparatus client 2 726 remains active with the pccbs_vpn utility (server portion) 724 link. Next, pccbs_vpn utility 724 responds to private cloud callback server smart device client 1 725 with the internet protocol address and port capabilities in the transmission control protocol/user data information protocol of pcrs_vpn utility 722 via communication path 705 through a callback server information box (not shown). Pcrs_vpn utility 722 initiates a point-to-point communication to connect to pccbs_vpn utility 723. Thereafter, pccbs_device utility 724 begins listening in loop 702 to wait for a Device client request 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 pccbs_device utility 724, it establishes point-to-point channel 706 with pccbs_device utility 724. Which in turn triggers another point-to-point communication between pccbs_vpn utility 723 and pcrs_vpn utility 722. From this point on, private cloud callback server smart device client 1 725 connects to pcrs_vpn utility 722 and is in turn able to access any private cloud routing server device client 720 or web service (not shown). Point-to-point communication is initiated between private cloud callback server smart device client 1 725 and pcrs_vpn utility 722. Private cloud callback server smart device client 1 725 can securely connect to a virtual private local area network on the private cloud routing server private local area network. Private cloud callback server smart device client 1 725 can access any private cloud routing server smart device client (e.g., private cloud routing server device client 2 726) or private network service (not shown) that is accessible under the private cloud routing server private lan. Other private cloud callback server smart device clients 201, 221, 209, 210, 211 of fig. 2 may connect to the private substance gateway through the same linking mechanism as shown in fig. 7. Once any pair of private cloud routing server smart device clients and private cloud virtual private network server smart device clients connect to the virtual local area network 240 and virtual local area network 2400 of private cloud routing server 728 and private cloud callback server 727, they can conduct private and secure communications between them for text, voice, or image communications.
Fig. 8 is a schematic diagram of a communication flow of a point-to-point linking mechanism between a metauniverse application gateway, a metauniverse virtual private network server, a metauniverse application gateway smart device client, and a metauniverse virtual private network server smart device client through a cloud network according to an embodiment of the present invention. The present invention discloses that the metauniverse virtual private network server smart device client does not need a public cloud routing server to connect and access to the server metauniverse application gateway 828, the metauniverse virtual private network server 827, or another metauniverse application gateway smart device client, or through a network service under a cloud network server. As shown in fig. 8, the metauniverse virtual private network server device client 1 and the metauniverse application gateway 828 on the cloud network can communicate with each other without going through the public routing server 112 or the public virtual private network routing server 114 of fig. 1. Unlike the prior art of fig. 7, initially, one of the metauniverse virtual private network server device clients (public cloud portal website management device 850) connects to the public cloud portal website 851 (circle 1 and step 803). Public cloud portal 851 is a cloud-based public cloud portal that contains PCP Device utility 847. The public cloud portal website management apparatus 850 obtains the metauniverse virtual private network server authentication and the metauniverse virtual private network server client authentication from the pcp_device utility 847. The metauniverse virtual private network server authentication comprises a metauniverse virtual private network server area domain_MVVS and a metauniverse virtual private network server password passcode_MVVS. The meta-universe virtual private network server client authentication includes a client login profile MVVS Client Profile and a client configured login password MVVS Client Login. The metauniverse virtual private network server authentication is transmitted to the metauniverse application gateway management device 820 by email or other means. The metaverse virtual private network server client authentication is communicated to an authorized metaverse virtual private network server device client (e.g., metaverse virtual private network server device client 1 825) for point-to-point linking with one of the metaverse application gateway device clients (e.g., metaverse application gateway device client 2 826 on the private local area network of metaverse application gateway 828). Public cloud portal 851 contains at least one PCP Device utility (e.g., PCP Device utility 847). The at least one PCP Device utility includes at least one virtual machine server (e.g., virtual machine server 832). The at least one virtual machine server includes at least one metauniverse virtual private network server (e.g., metauniverse virtual private network server 827). At least one metauniverse virtual private network server includes MVVS Device utility 824 and MVVS VPN utility 823. Virtual machine server 832, along with metauniverse virtual private network server 827, forms a one-to-one correspondence with metauniverse application gateway 828 deployed in a private local area network. PCP Device utility 847 is an extensible public cloud portal and may correspond to at least one virtual machine server (e.g., virtual machine server 832) and at least one metacosmic virtual private network server (e.g., metacosmic 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 the server authentication to the metaverse application gateway 828 through the mvag_device utility 821 (circle 2 and step 800). The MVAG Device utility 821 then passes information internal to the meta-cosmic application gateway 828 to the MVAG VPN utility 822. Through the tcp/userdata protocol, it registers meta-VPN server authentication information including Domain MVVS and Passcode MVVS to MVVS VPN utility 823 (circle 4 and step 801). MVVS_VPN utility 823 dials back to meta-universe application 852 (circle 3 and step 805). The metacosmic application 852 includes at least one metacosmic application gateway (e.g., metacosmic application gateway 828). At least one metauniverse application gateway includes mvag_vpn utility 822 to enable a first virtual private network channel between mvvs_vpn utility 823 and mvag_vpn utility 822. Thereafter, the mvag_vpn utility 822 establishes a first virtual private network channel between the mvag_vpn utility 822 and the mvvs_vpn utility 823 (circle 5 and step 813). After registration, mvag_vpn utility 822 connects to mvvs_vpn utility 823 and enables a third virtual private network channel as needed between mvag_vpn utility 822 and mvvs_vpn utility 823. Between mvvs_vpn utility 823 and mvag_vpn utility 822, mvvs_vpn utility 823 may establish a third virtual private network channel as needed (circle 6 and step 807). The MVVS VPN utility 823 may also establish a third virtual private network channel on demand between the MVVS VPN utility 823 and the MVAG VPN utility 822, waiting for completion of the second virtual private network channel established on demand (circle 10 and step 806). The mvvs_vpn utility 823 also enables a second virtual private network channel between the mvvs_vpn utility 823 and any metauniverse virtual private network server smart device client (e.g., metauniverse virtual private network server device client 1 825 or metauniverse virtual private network server device client 3 853) from the cloud of the internet (circle 9 and steps 845 or 846). Then, the metaspacecraft virtual private network server 827 is ready to take further action as required by any metaspacecraft virtual private network server device client (e.g., metaspacecraft virtual private network server device client 1) from the cloud of the internet. Within metauniverse virtual private network server 827, mvvs_vpn utility 823 communicates with mvvs_device utility 824. MVVS Device utility 824 stays in loop waiting for a request from a metauniverse virtual private network server smart Device client (circle 7 and step 802). First, metauniverse virtual private network server Device client 1 825 registers that the metauniverse virtual private network server client authenticates to MVVS Device utility 824 (circle 8 and steps 804 or 814). The meta-universe virtual private network server client authentication includes MVVS Client Profile and MVVS Client Login. MVVS_device utility 824 passes meta-cosmic VPN server client authentication and a link request inside meta-cosmic VPN server 827 to MVVS_VPN utility 823. After registration, metauniverse virtual private network server device client 1 825 connects to mvvs_vpn utility 823, and a second virtual private network channel is established as needed between metauniverse virtual private network server device client 1 825 and mvvs_vpn utility 823 (circle 10 and step 806 or 816). Next, between mvvs_vpn utility 823 and metauniverse application 852, mvvs_vpn utility 823 establishes a third virtual private network channel as needed (circle 6 and step 807). The metacosmic application 852 includes at least one metacosmic application gateway (e.g., metacosmic application gateway 828). At least one metauniverse application gateway contains 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 mvvs_vpn utility 823, the second virtual private network channel established on demand in circles 10 and 806 and the third virtual private network channel established on demand in circles 6 and 807 are combined into a single virtual private network channel between metaverse virtual private network server device client 1 825 and mvag_vpn utility 822, and connected to metaverse application gateway device client 2 826 (circles 11 and 811), or metaverse application gateway network service 836 (circles 11 and 831), or another metaverse virtual private network server device client (e.g., metaverse virtual private network server device client 3 853) (circles 10 and 816). Thus, metauniverse virtual private network server device client 1 825 and metauniverse virtual private network server device client 3 853 form a point-to-point private and secure channel between them. The channel is the basis for further secure chat applications in text, voice and images, including encrypted (crypto) currency (currency) transactions.
Compared with the prior art of fig. 7, the present invention is more scalable and expandable because it introduces some new entities, including public cloud portal 851, pcp_device utility 847, virtual machine server 832, meta-cosmic application 852, public cloud portal management Device 850, meta-cosmic application gateway management Device 820, meta-cosmic virtual private network server authentication, and meta-cosmic virtual private network server client authentication. It connects first to the public cloud portal 851, then to at least one MVVS Device utility (e.g., MVVS Device utility 824), then to at least one virtual machine server (e.g., virtual machine server 832), then to at least one metauniverse virtual private network server (e.g., metauniverse virtual private network server 827), then to at least one metauniverse application (e.g., metauniverse application 852), then to at least one metauniverse application gateway (e.g., metauniverse application gateway 828), then to at least one metauniverse application gateway Device client (e.g., metauniverse application gateway Device client 2), or to a metauniverse application gateway network service (e.g., metauniverse application gateway network service 836), or to another metauniverse virtual private network server Device client (e.g., metauniverse virtual private network server Device client 3 853). The public cloud portal management device 850 starts obtaining meta-universe virtual private network server authentication and client authentication from the public cloud portal 851. Thereafter, the metauniverse virtual private network server authentication is transferred to the metauniverse application gateway management device 820 to set the link of the metauniverse application gateway 828 with the corresponding metauniverse virtual private network server 827 located inside the virtual machine server 832 inside the public cloud portal 851. Still further, at least three virtual private network channels are bound together for point-to-point communication between metacosmic virtual private network server device client 1 825 and metacosmic application gateway device client 2 826, metacosmic application gateway network service 836, or another metacosmic virtual private network server device client (e.g., metacosmic virtual private network server device client 3 853) in a vertical point-to-point private and secure metacosmic virtual private network server smart device client application before the last two virtual private network channels form a single virtual private network channel.
FIG. 9 is a flow chart of a communication flow of a point-to-point linking mechanism between a metauniverse application gateway, a metauniverse virtual private network server, a metauniverse application gateway smart device client, and a metauniverse virtual private network server smart device client over a cloud network based on a server farm, a computer resource aggregate, and a virtual machine server in accordance with an embodiment of the present invention. Further, FIG. 9 extends FIG. 8 by adding a server farm 930 and a computer resource aggregate 931 to illustrate the implementation of the metaspace application gateway link point mechanism in a very large scale data center. The very large scale data center has at least one server farm (e.g., server farm 930), at least one computer resource aggregate (e.g., computer resource aggregate 931), at least one private cloud portal (e.g., private cloud portal 951), and at least one virtual machine server (e.g., virtual machine server 932). The virtual machine server 932 is scalable in number and size. In a corresponding virtual machine server (e.g., virtual machine server 932), a very large scale data center or service provider may build and provision at least one private cloud portal (e.g., private cloud portal 951) and a large number of independent metacosmic virtual private network servers (e.g., metacosmic virtual private network servers 927) to serve a corresponding metacosmic application gateway (e.g., metacosmic application gateway 928) and a corresponding metacosmic application gateway smart device client (e.g., metacosmic application gateway device client 2 926). Essentially, whether or not having the topology (topology) of the computer resource aggregate 931 and the server farm 930, the community pairing of the metauniverse virtual private network server smart device client 1 925 and the metauniverse application gateway smart device client 2 926 is responsible for maintaining the metauniverse provider construction and deployment of the virtual machine server 932. For example, a possible business model is that an internet metauniverse provider provides to a large number of users to host their private and secure metauniverse virtual private network servers 927 in virtual machine servers 932. In addition, separate private and secure metauniverse application gateways 928 are also provided to allow metauniverse providers to install metauniverse application gateways 928 in their private local area networks. With the present invention, a metauniverse subscriber can establish point-to-point communication from anywhere between a metauniverse virtual private network server smart device client (e.g., metauniverse virtual private network server smart device client 1 925) (e.g., a smartphone, tablet, or tesla dashboard) and a metauniverse application gateway smart device client (e.g., metauniverse application gateway smart device client 2 926) (e.g., a notebook, an internet of things device, a network connected storage device, a set top box, a smart appliance, or a media server), which is located on a private and secure local area network of a metauniverse provider. Fig. 9 shows that the metaspacecraft virtual private network server smart device client of the present invention (e.g., metaspacecraft virtual private network server smart device client 1 925) does not need a public cloud routing server to connect and access to a server metaspacecraft application gateway 928, a metaspacecraft virtual private network server 927, or another metaspacecraft application gateway smart device client (e.g., metaspacecraft application gateway smart device client 2 926), or a network service under a server through a cloud network (not shown). As shown in fig. 9, the metauniverse virtual private network server smart device client 1 925 and the metauniverse application gateway 928 in the cloud network can communicate with each other without going through the public routing server 112 or the public virtual private network routing server 114 of fig. 1. First, the metauniverse virtual private network server management device 950 is one of metauniverse virtual private network server smart device clients, and connects to the private cloud portal site 951 (circle 1 and step 903). Private cloud portal 951 is a cloud-based public cloud portal that contains PCP Device utility 947. The metauniverse virtual private network server management Device 950 obtains metauniverse virtual private network server authentication and metauniverse virtual private network server client authentication from the pcp_device utility 947. The metauniverse virtual private network server authentication comprises a metauniverse virtual private network server area domain_MVVS and a metauniverse virtual private network server password passcode_MVVS. The meta-universe virtual private network server client authentication includes a client login profile MVVS Client Profile and a client configured login password MVVS Client Login. The metauniverse virtual private network server authentication is transmitted to the metauniverse application gateway management device 920 by email or other means. The metaverse virtual private network server client authentication is communicated to an authorized metaverse virtual private network server device client (e.g., metaverse virtual private network server device client 1 925) for point-to-point linking with one of the metaverse application gateway device clients (e.g., metaverse application gateway device client 2 926 on the private local area network of metaverse application gateway 928). Public cloud portal 951 includes at least one PCP Device utility (e.g., PCP Device utility 947). The at least one PCP Device utility includes at least one virtual machine server (e.g., virtual machine server 932). The at least one virtual machine server includes at least one metauniverse virtual private network server (e.g., metauniverse virtual private network server 927). The at least one metauniverse virtual private network server includes mvvs_device utility 924 and mvvs_vpn utility 923. The virtual machine server 932 together with the metauniverse virtual private network server 927 form a one-to-one correspondence with the metauniverse application gateway 928 deployed in the private lan. PCP Device utility 947 is an extensible public cloud portal and may correspond to at least one virtual machine server (e.g., virtual machine server 932) and at least one metauniverse virtual private network server (e.g., metauniverse 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 the server authentication to the metaverse application gateway 928 through the mvag_device utility 921 (circle 2 and step 900). MVAG Device utility 921 then passes information inside meta-space application gateway 928 to MVAG VPN utility 922. Through the tcp/userdata protocol, it registers meta-VPN server authentication information including Domain MVVS and Passcode MVVS to MVVS VPN utility 923 (circle 4 and step 901). After registration, mvag_vpn utility 922 connects to mvvs_vpn utility 923 and a third virtual private network channel is enabled between mvag_vpn utility 922 and mvvs_vpn utility 923. Then, mvvs_vpn utility 923 dials back to meta-universe application 952 (circle 3 and step 905). The metacosmic application 952 includes at least one metacosmic application gateway (e.g., metacosmic application gateway 928). At least one metauniverse application gateway includes mvag_vpn utility 922 to enable a first virtual private network channel between mvvs_vpn utility 923 and mvag_vpn utility 922. Between mvvs_vpn utility 923 and mvag_vpn utility 922, mvvs_vpn utility 923 establishes a third virtual private network channel as needed (circle 6 and step 907). A third VPN channel may also be established on demand between mvvs_vpn utility 923 and mvag_vpn utility 922, awaiting completion of the second VPN channel established on demand (circle 10 and step 906). Thereafter, between mvag_vpn utility 922 and mvvs_vpn utility 923, mvag_vpn utility 922 establishes a first virtual private network channel (circle 5 and step 913). Mvvs_vpn utility 923 also enables a second virtual private network channel between mvvs_vpn utility 923 and any metaverse virtual private network server smart device client (e.g., metaverse virtual private network server device client 1 925) from the cloud of the internet (circle 9 and step 945). Then, the metaspacecraft virtual private network server 927 is ready to take further action as required by any metaspacecraft virtual private network server device client from the cloud of the internet (e.g., metaspacecraft virtual private network server device client 1 925). Inside the metauniverse virtual private network server 927, the mvvs_vpn utility 923 communicates with the mvvs_device utility 924. MVVS Device utility 924 stays in loop waiting for a request by the metauniverse virtual private network server smart Device client (circle 7 and step 902). First, metauniverse virtual private network server Device client 1 925 registers that the metauniverse virtual private network server client authenticates to MVVS Device utility 924 (circle 8 and steps 904 or 914). The meta-universe virtual private network server client authentication includes MVVS Client Profile and MVVS Client Login. MVVS Device utility 924 communicates a meta-cosmic VPN server client authentication and a link request inside meta-cosmic VPN server 927 to MVVS VPN utility 923. After registration, metauniverse virtual private network server device client 1 925 connects to mvvs_vpn utility 923, and a second virtual private network channel is established as needed between metauniverse virtual private network server device client 1 925 and mvvs_vpn utility 923 (circle 10 and step 906 or 916). Next, between mvvs_vpn utility 923 and metauniverse application 952, mvvs_vpn utility 923 establishes a third virtual private network channel as needed (circle 6 and step 907). The metacosmic application 952 includes at least one metacosmic application gateway (e.g., metacosmic application gateway 928). At least one metauniverse application gateway contains mvag_vpn utility 922. The second virtual private network channel established on demand in circles 10 and 906 and the third virtual private network channel established on demand in circles 6 and 907 are combined into a single virtual private network channel between metauniverse virtual private network server device client 1 925 and mvag_vpn utility 922 and connected to metauniverse application gateway device client 2926 (circles 11 and 911) or metauniverse application gateway network service (not labeled) (circles 11 and 911).
Fig. 10 is a flowchart of a communication flow of registering a public cloud portal management device to a public cloud portal according to an embodiment of the present invention. First, from the wide area network, the private cloud portal management device opens a private cloud portal device utility (step 1000). Next, a "register public cloud portal" command on the private cloud portal device utility is selected (step 1001). The metauniverse virtual private network server authentication and metauniverse virtual private network server client authentication are required (step 1002). The metauniverse virtual private network server authentication comprises a metauniverse virtual private network server area domain_MVVS and a metauniverse virtual private network server password passcode_MVVS. The meta-universe virtual private network server client authentication includes a client login profile MVVS Client Profile and a client configured login password MVVS Client Login. The metaverse virtual private network server authentication including domain_mvvs and passcode_mvvs is transmitted to the metaverse application gateway management device (step 1003). The metaverse virtual private network server client authentication including MVVS Client Profile and MVVS Client Login is transmitted to the MVVS Device client (step 1004) for the target metaverse application gateway Device client, the metaverse application gateway network service, or another metaverse virtual private network server Device client.
At the same time, the PCP Device utility begins accepting commands from the private cloud portal management Device to register with the private cloud portal (step 1010). The metauniverse virtual private network server authentication and the metauniverse virtual private network server client authentication are generated or retrieved by the PCP Device utility (step 1011). Next, the two authentications are transmitted back to the private cloud portal management device (step 1040).
FIG. 11 is a flow chart of a communication flow for initializing and configuring a metacosmic application gateway by a metacosmic application gateway management device according to an embodiment of the invention. As shown in fig. 11, first, the metaspace application gateway management Device opens the mvag_device utility from the metaspace application gateway local area network (step 1101). Thus, a metauniverse application gateway is discovered and selected on the local area network (step 1102). Next, an "initialize and configure" command on the MVAG_device utility is selected (step 1103). Thus, by setting the metaverse virtual private network server authentication including the metaverse virtual private network server area domain_mvvs and the metaverse virtual private network server password passcode_mvvs as the unique metaverse application gateway identity, the metaverse application gateway is set (step 1104). The meta-universe virtual private network server authentication is transferred to the MVAG Device utility (step 1140).
The metauniverse virtual private network server authentication (domain_mvvs, passcode_mvvs) is accepted (step 1110) and stored as the identity of the metauniverse application gateway (step 1111). Next, the metauniverse application gateway is registered as a corresponding client with the metauniverse virtual private network server (step 1112).
Fig. 12 is a flow chart of one communication flow of the links from mvvs_vpn utility to mvag_vpn utility and between a metauniverse virtual private network server device client and a metauniverse application gateway device client in a private lan and from mvvs_vpn utility to mvag_vpn utility in an embodiment of the present invention. First, the mvag_vpn utility uses meta-universe virtual private network server authentication to connect to the mvvs_vpn utility through the wide area network (step 1200). The mvvs_vpn utility accepts the metauniverse virtual private network server authentication from the mvag_vpn utility through the wide area network (step 1210). The mvvs_vpn utility then communicates further linking or update information to the mvag_vpn utility if needed (steps 1211 and 1241). If desired, the MVAG_VPN utility receives further linking or update information from the MVVS_VPN utility (step 1201). The MVVS VPN utility then dials back 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 a second virtual private network channel to be established on demand from the metauniverse virtual private network server device client to the mvvs_vpn utility (step 1215). The mvvs_vpn utility establishes a second virtual private network channel from the metauniverse virtual private network server device client to the mvvs_vpn utility on demand (steps 1216 and 1246). The mvag_vpn utility waits to establish a second virtual private network channel from the metauniverse virtual private network server device client to the mvvs_vpn utility on demand (step 1205). The mvag_vpn utility establishes a point-to-point channel from the metauniverse virtual private network server device client to the mvag_vpn utility, steps 1208 and 1248. Next, the mvvs_vpn utility establishes a point-to-point channel from the metauniverse virtual private network server device client to the mvag_vpn utility (step 1218). Thereafter, the second virtual private network channel established on demand and the third virtual private network channel established on demand are combined into a single virtual private network channel between the metauniverse virtual private network server device client and the mvag_vpn utility. After the third virtual private network channel established on demand and the second virtual private network channel established on demand are combined into a single virtual private network channel between the metauniverse virtual private network server Device client and the mvag_vpn utility, the metauniverse virtual private network server Device client may initiate a private and secure link to at least one metauniverse application gateway Device client, a metauniverse application gateway network service (not shown) on the private metauniverse application gateway lan, or another mvvs_device client (not shown) on the public cloud of the internet (step 1231).
The first embodiment has the advantage over the third embodiment of a true on-demand linking mechanism, wherein the linking is between the metavpn server device client and the MVVS VPN utility, between the MVVS VPN utility and the MVAG VPN utility, and ultimately to at least one metauniverse application gateway device client through a second virtual private network channel established on demand. Superficially, it appears to be safer than the third embodiment. However, since the commonality of the second virtual private network channel established on demand is applied in both the first and third embodiments, the final single virtual private network channel in both embodiments is equally secure from the nature of the virtual private network linking mechanism. Because of the complexity of applying the third virtual private network channel established on demand, the first embodiment may provide a true virtual private network link on demand. The third virtual private network channel and the second virtual private network channel are combined into a single virtual private network channel between the metauniverse virtual private network server device client and the MVAG_VPN practical program according to the requirement, and finally the single virtual private network channel is finally transmitted to the metauniverse application program gateway device client. By using three virtual private network channels instead of two as in the third embodiment, the architecture is more complex. The first embodiment does not require the third vpn channel to be always on or to remain active. Thus, less energy is consumed in the nature of the linking mechanism on demand. In so doing, it appears to be more secure in terms of the on-demand nature of the third virtual private network channel. But the fact is that the linking mechanism from the second virtual private network channel established on demand solves the security problem in the final single virtual private network channel between the metauniverse virtual private network server device client and the mvag_vpn utility. Therefore, the third embodiment is a preferred embodiment in terms of link simplicity, efficiency and security.
Fig. 13 is a flowchart of a communication flow of a metauniverse 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 turned on from the wide area network (step 1300). Next, the metaverse VPN Server Device client registers the metaverse VPN Server client authentication to the MVVS_device utility including MVVS Client Profile and MVVS Client Login (step 1301). It initiates point-to-point negotiations using meta-universe virtual private network server client authentication to communicate with the MVVS VPN utility (steps 1302 and 1341). The corresponding MVVS Device utility also initiates point-to-point negotiations using metauniverse virtual private network server client authentication to communicate with metauniverse virtual private network server Device clients (step 1311). Next, a VPN channel is established between the metauniverse VPN server device client and the MVVS_VPN utility (steps 1303, 1312, and 1342). The metauniverse virtual private network server device client initiates secure point-to-point communications with the MVVS VPN utility (steps 1304 and 1343). In terms of the MVVS Device utility, it passes control to the MVVS VPN utility (step 1313).
Fig. 14 is a flow chart of a communication flow of a point-to-point linking mechanism between a metauniverse application gateway, a metauniverse virtual private network server, a metauniverse application gateway smart device client and a metauniverse virtual private network server smart device client through a cloud network according to a third embodiment of the present invention. The present invention discloses that a metauniverse virtual private network server smart device client does not need a public cloud routing server to connect and access to a server metauniverse application gateway 1428, a metauniverse virtual private network server 1427, or another metauniverse application gateway smart device client, or through a network service under a cloud network server. As shown in fig. 14, the metaverse virtual private network server device client 11425 and the metaverse application gateway 1428 on the cloud network can communicate with each other without going through the public routing server 112 or the public virtual private network routing server 114 of fig. 1. Unlike the prior art of fig. 7, initially, one of the metauniverse virtual private network server device clients (public cloud portal site management device 1450) connects to public cloud portal site 1451 (circle 1 and step 1403). Public cloud portal 1451 is a cloud-based public cloud portal that contains PCP Device utility 1447. The public cloud portal website management apparatus 1450 obtains the metauniverse virtual private network server authentication and the metauniverse virtual private network server client authentication from the pcp_device utility 1447. The metauniverse virtual private network server authentication comprises a metauniverse virtual private network server area domain_MVVS and a metauniverse virtual private network server password passcode_MVVS. The meta-universe virtual private network server client authentication includes a client login profile MVVS Client Profile and a client configured login password MVVS Client Login. The metauniverse virtual private network server authentication is transmitted to the metauniverse application gateway management device 1420 by email or other means. The metaverse virtual private network server client authentication is communicated to an authorized metaverse virtual private network server device client (e.g., metaverse virtual private network server device client 1 1425) for point-to-point linking with one of the metaverse application gateway device clients (e.g., metaverse application gateway device client 2 1426 on the private local area network of metaverse application gateway 1428). Public cloud portal 1451 includes at least one PCP Device utility (e.g., PCP Device utility 1447). The at least one PCP Device utility includes at least one virtual machine server (e.g., virtual machine server 1432). The at least one virtual machine server includes at least one metauniverse virtual private network server (e.g., metauniverse virtual private network server 1427). The at least one metauniverse virtual private network server includes an mvvs_device utility 1424 and an mvvs_vpn utility 1423. The virtual machine server 1432 together with the metacosmic virtual private network server 1427 form a one-to-one correspondence with the metacosmic application gateway 1428 deployed in the private lan. PCP Device utility 1447 is an extensible public cloud portal and may correspond to at least one virtual machine server (e.g., virtual machine server 1432) and at least one metacosmic virtual private network server (e.g., metacosmic 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 the server authentication to the metaverse application gateway 1428 through the mvag_device utility 1421 (circle 2 and step 1400). The MVAG_device utility 1421 then passes on the information inside the meta-space application gateway 1428 to the MVAG_VPN utility 1422. Through the tcp/userdata protocol, it registers meta-VPN server authentication information including Domain MVVS and Passcode MVVS to MVVS VPN utility 1423 (circle 4 and step 1401). Mvvs_vpn utility 1423 dials back to meta-universe application 1452 (circle 3 and step 1405). The metacosmic application 1452 includes at least one metacosmic application gateway (e.g., metacosmic application gateway 1428). The at least one metauniverse application gateway includes a mvag_vpn utility 1422 to enable a first virtual private network channel between mvvs_vpn utility 1423 and mvag_vpn utility 1422. Thereafter, the mvag_vpn utility 822 establishes a first virtual private network channel between the mvag_vpn utility 1422 and the mvvs_vpn utility 1423 (circle 5 and step 1413). Mvvs_vpn utility 1423 also enables the second virtual private network channel (circle 9 and steps 1445 or 1446) between mvvs_vpn utility 1423 and any metauniverse virtual private network server smart device client (e.g., metauniverse virtual private network server device client 1 1425 or metauniverse virtual private network server device client 3 1453) from the cloud of the internet. Then, the metaspacecraft virtual private network server 1427 is ready to take further action as required by any metaspacecraft virtual private network server device client (e.g., metaspacecraft virtual private network server device client 1 1425) from the cloud of the internet. Within metauniverse virtual private network server 1427, mvvs_vpn utility 1423 communicates with mvvs_device utility 1424. MVVS Device utility 1424 stays in loop waiting for a request from the metauniverse virtual private network server smart Device client (circle 7 and step 1402). First, metauniverse virtual private network server Device client 1 1425 registers that the metauniverse virtual private network server client authenticates to MVVS Device utility 1424 (circle 8 and steps 1404 or 1414). The meta-universe virtual private network server client authentication includes MVVS Client Profile and MVVS Client Login. MVVS Device utility 1424 passes meta-cosmic virtual private network server client authentication and a link request inside meta-cosmic virtual private network server 1427 to MVVS VPN utility 1423. After registration, metauniverse virtual private network server device client 1 1425 connects to mvvs_vpn utility 1423, and a second virtual private network channel is established as needed between metauniverse virtual private network server device client 1 1425 and mvvs_vpn utility 1423 (circle 10 and step 1406 or 1416). Assuming that another metaverse VPN server device client (e.g., metaverse VPN server device client 3 1453) has also successfully connected to mvvs_vpn utility 1423, the second virtual private network channel established on demand in circles 10 and step 1406 and the first virtual private network channel established on demand in circles 5 and step 1413 are combined into a single virtual private network channel between metaverse VPN server device client 1 1425 and mvag_vpn utility 1422 and connected to metaverse application gateway device client 2 1426 (circles 11 and step 1411), or metaverse application gateway web service 1436 (circles 11 and step 831), or another metaverse VPN server device client (e.g., metaverse VPN server device client 3 1453) (circles 10 and step 1416). Thus, metauniverse virtual private network server device client 1 1425 and metauniverse virtual private network server device client 3 1453 form a point-to-point private and secure channel between them. The channel is the basis for further secure chat applications in text, voice and images, including encrypted (crypto) currency (currency) transactions.
Compared with the prior art of fig. 7, the present invention is more scalable and expandable because it introduces some new entities, including public cloud portal 1451, pcp_device utility 1447, virtual machine server 1432, metacosmic application 1452, public cloud portal management Device 1450, metacosmic application gateway management Device 1420, metacosmic virtual private network server authentication, and metacosmic virtual private network server client authentication. It connects first to the public cloud portal 1451, then to at least one MVVS Device utility (e.g., MVVS Device utility 1447), then to at least one virtual machine server (e.g., virtual machine server 1432), then to at least one metauniverse virtual private network server (e.g., metauniverse virtual private network server 1427), then to at least one metauniverse application gateway (e.g., metauniverse application 1452), then to at least one metauniverse application gateway (e.g., metauniverse application gateway 1428), then to at least one metauniverse application gateway Device client (e.g., metauniverse application gateway Device client 2 1426), or to a metauniverse application gateway network service (e.g., metauniverse application gateway network service 1436), or to another metauniverse virtual private network server Device client (e.g., metavirtual private network server Device client 1453). The public cloud portal management device 1450 starts to obtain meta-universe virtual private network server authentication and client authentication from the public cloud portal 1451. Thereafter, the metauniverse virtual private network server authentication is transferred to the metauniverse application gateway management device 1420 to set the link of the metauniverse application gateway 1428 with the corresponding metauniverse virtual private network server 1427 located inside the virtual machine server 1432 inside the public cloud portal 1451. Still further, at least three virtual private network channels are bound together for point-to-point communication between metacosmic virtual private network server device client 1 1425 and metacosmic application gateway device client 2 1426, metacosmic application gateway network service 1436, or another metacosmic virtual private network server device client (e.g., metacosmic virtual private network server device client 3 1453) in a vertical point-to-point private and secure metacosmic virtual private network server smart device client application before the last two virtual private network channels form a single virtual private network channel.
FIG. 15 is a flow chart of a communication flow of a point-to-point linking mechanism between a metauniverse application gateway, a metauniverse virtual private network server, a metauniverse application gateway smart device client, and a metauniverse virtual private network server smart device client over a cloud network based on a server farm, a computer resource aggregate, and a virtual machine server in accordance with a third embodiment of the present invention. Further, FIG. 15 extends FIG. 14 by way of the newly added server farm 1530 and computer resource aggregate 1531 to illustrate the implementation of the metaspace application gateway chaining point mechanism in a very large scale data center. The very large scale data center has at least one server farm (e.g., server farm 1530), at least one computer resource aggregate (e.g., computer resource aggregate 1531), at least one private cloud portal (e.g., private cloud portal 1551), and at least one virtual machine server (e.g., virtual machine server 1532). Virtual machine server 1532 is scalable in number and size. In a corresponding virtual machine server (e.g., virtual machine server 1532), a very large scale data center or service provider may build and provision at least one private cloud portal (e.g., private cloud portal 1551) and a large number of independent metacosmic virtual private network servers (e.g., metacosmic virtual private network servers 1527) to serve a corresponding metacosmic application gateway (e.g., metacosmic application gateway 1528) and a corresponding metacosmic application gateway smart device client (e.g., metacosmic application gateway device client 2 1526). Essentially, whether or not having the topology of the computer resource aggregation 1531 and the server farm 1530, the community pairing of the point-to-point communication relationship between the metauniverse virtual private network server smart device client (e.g., metauniverse virtual private network server smart device client 1 1525) and the metauniverse application gateway smart device client (e.g., metauniverse application gateway smart device client 2 1526) is responsible for maintaining the metauniverse provider construction and deployment of the virtual machine server 1532. For example, a possible business model is that an internet metauniverse provider provides to a large number of users to host their private and secure metauniverse virtual private network servers 1527 in virtual machine servers 1532. In addition, a separate private and secure metauniverse application gateway 1528 is also provided to allow metauniverse subscribers to install metauniverse application gateway 1528 in their private local area network. With the present invention, platform subscribers can establish point-to-point communications from anywhere between metauniverse virtual private network server smart device clients (e.g., metauniverse virtual private network server smart device client 1 1525) (e.g., a smart phone, tablet computer, or tesla dashboard) and metauniverse application gateway smart device clients (e.g., metauniverse application gateway smart device client 2 1526) (e.g., notebook computer, internet of things device, network connected storage device, set top box, smart appliance, or media server) on a private and secure local area network of a metauniverse provider. Fig. 15 shows that the metaspacecraft virtual private network server smart device client of the present invention (e.g., metaspacecraft virtual private network server smart device client 1 1525) does not need a public cloud routing server to connect and access to the server metaspacecraft application gateway 1528, the metaspacecraft virtual private network server 1527, or another metaspacecraft application gateway smart device client (e.g., metaspacecraft application gateway smart device client 2 1526), or a web service under the server through a cloud network (not shown). As shown in fig. 15, the metauniverse virtual private network server smart device client 1 1525 and the metauniverse application gateway 1528 in the cloud network can communicate with each other without passing through the public routing server 112 or the public virtual private network routing server 114 of fig. 1. First, the metauniverse virtual private network server management device 1550 is one of the metauniverse virtual private network server smart device clients, and connects to the private cloud portal 1551 (circle 1 and step 1503). Private cloud portal 1551 is a cloud-based public cloud portal that contains PCP Device utility 1547. The metauniverse virtual private network server management Device 1550 obtains the metauniverse virtual private network server authentication and the metauniverse virtual private network server client authentication from the pcp_device utility 1547. The metauniverse virtual private network server authentication comprises a metauniverse virtual private network server area domain_MVVS and a metauniverse virtual private network server password passcode_MVVS. The meta-universe virtual private network server client authentication includes a client login profile MVVS Client Profile and a client configured login password MVVS Client Login. The metauniverse virtual private network server authentication is transmitted to the metauniverse application gateway management device 1520 by email or other means. The metaverse virtual private network server client authentication is communicated to an authorized metaverse virtual private network server device client (e.g., metaverse virtual private network server device client 1 1525) for point-to-point linking with one of the metaverse application gateway device clients (e.g., metaverse application gateway device client 2 1526 on the private local area network of metaverse application gateway 1528). Public cloud portal 1551 contains at least one PCP Device utility (e.g., PCP Device utility 1547). The at least one PCP Device utility includes at least one virtual machine server (e.g., virtual machine server 1532). The at least one virtual machine server includes at least one metauniverse virtual private network server (e.g., metauniverse virtual private network server 1527). The at least one metauniverse virtual private network server includes MVVS Device utility 1524 and MVVS VPN utility 1523. Virtual machine server 1532 together with metacosmic virtual private network server 1527 forms a one-to-one correspondence with metacosmic application gateway 1528 deployed in a private local area network. PCP Device utility 1547 is an extensible public cloud portal and may correspond to at least one virtual machine server (e.g., virtual machine server 1532) and at least one metauniverse virtual private network server (e.g., metauniverse virtual private network server 1527).
First, after receiving the metaverse virtual private network server authentication, the metaverse application gateway management Device 1520 initializes and provides the server authentication to the metaverse application gateway 1528 through the mvag_device utility 1521 (circle 2 and step 1500). The MVAG Device utility 1521 then passes information inside the meta-cosmic application gateway 1528 to the MVAG VPN utility 1522. Through the tcp/userdata protocol, it registers meta-VPN server authentication information including Domain MVVS and Passcode MVVS to MVVS VPN utility 1523 (circle 4 and step 1501). After registration, mvvs_vpn utility 1523 dials back meta-cosmic application 1552 (circle 3 and step 1505). The metacosmic application 1552 includes at least one metacosmic application gateway (e.g., metacosmic application gateway 1528). At least one metauniverse application gateway includes mvag_vpn utility 1522 to enable a first virtual private network channel between mvvs_vpn utility 1523 and mvag_vpn utility 1522. Between mvvs_vpn utility 1523 and mvag_vpn utility 1522, mvvs_vpn utility 1523 also establishes the second virtual private network channel on demand, waiting for completion of the second virtual private network channel established on demand (circle 10 and step 1506). Thereafter, the mvag_vpn utility 1522 establishes a first virtual private network channel between the mvag_vpn utility 1522 and the mvvs_vpn utility 1523 (circle 5 and step 1513). Mvvs_vpn utility 1523 also enables a second virtual private network channel between mvvs_vpn utility 1523 and any metaverse virtual private network server smart device client (e.g., metaverse virtual private network server device client 1 1525) from the cloud of the internet (circle 9 and step 1545). Then, the metaspacecraft virtual private network server 1527 is ready to take further action as required by any metaspacecraft virtual private network server device client from the cloud of the internet (e.g., metaspacecraft virtual private network server device client 1 1525). Inside the metauniverse virtual private network server 1527, the mvvs_vpn utility 1523 communicates with the mvvs_device utility 1524. MVVS Device utility 1524 stays in loop waiting for a request from a metauniverse virtual private network server smart Device client (circle 7 and step 1502). First, meta-universe virtual private network server Device client 1 1525 registers that the meta-universe virtual private network server client authenticates to MVVS Device utility 1524 (circle 8 and step 1504). The meta-universe virtual private network server client authentication includes MVVS Client Profile and MVVS Client Login. MVVS Device utility 1524 communicates meta-cosmic VPN server client authentication and a link request inside meta-cosmic VPN web server 1527 to MVVS VPN utility 1523. After registration, metauniverse virtual private network server device client 1 1525 connects to mvvs_vpn utility 1523, and a second virtual private network channel is established as needed between metauniverse virtual private network server device client 1 1525 and mvvs_vpn utility 1523 (circle 10 and step 1506). The second VPN network channel established on demand in circles 10 and 906 and the first VPN network channel established on demand in circles 5 and 1513 are combined into a single VPN network channel between the metaverse VPN server device client 1 1525 and the mvag_vpn utility 1522 and connected to the metaverse application gateway device client 2 1526 (circles 11 and 1511) or the metaverse application gateway network service (not shown) (circles 11 and 1511).
Fig. 16 is a flow chart of a communication flow of links from mvvs_vpn utility to mvag_vpn utility and links between a metauniverse virtual private network server device client and a metauniverse application gateway device client in a private lan according to a third embodiment of the present invention. First, the mvag_vpn utility authenticates the connection to the mvvs_vpn utility using the metauniverse virtual private network server over the wide area network (step 1600). The mvvs_vpn utility accepts the metauniverse virtual private network server authentication from the mvag_vpn utility over the wide area network (step 1610). The mvvs_vpn utility then communicates further linking or update information to the mvag_vpn utility if needed (steps 1611 and 1641). If desired, the MVAG_VPN utility receives further linking or update information from the MVVS_VPN utility (step 1601). The mvvs_vpn utility dials 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 a second virtual private network channel to be established from the metaverse virtual private network server device client to the mvvs_vpn utility (step 1615). Next, the mvvs_vpn utility establishes a second virtual private network channel from the metauniverse virtual private network server device client to the mvvs_vpn utility as needed (steps 1616 and 1646). The mvag_vpn utility waits for a second virtual private network channel to be established from the metauniverse virtual private network server device client to the mvvs_vpn utility (step 1605). The mvag_vpn utility establishes a point-to-point channel from the metauniverse virtual private network server device client to the mvag_vpn utility (steps 1608, 1618, and 1648). Thereafter, the second virtual private network channel and the first virtual private network channel are merged into one single virtual private network channel between the metauniverse virtual private network server device client and the MVAG_VPN utility. After the second VPN network channel and the first VPN network channel established as required are combined into a single VPN network channel between the metaverse VPN network server Device client and the mvag_vpn utility, the metaverse VPN network server Device client may initiate a private and secure link to at least one metaverse application gateway Device client, a metaverse application gateway network service (not shown) on the private metaverse application gateway local area network, or another mvvs_device client (not shown) on the public cloud of the internet (step 1631).
The third embodiment has the advantage of a simpler architecture than the first embodiment 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 on, or at least must remain active at all times. This seems to be less secure because the first virtual private network channel is always on. But the fact is that the linking mechanism from the second virtual private network channel established on demand solves the security problem in the final single virtual private network channel between the metauniverse virtual private network server device client and the mvag_vpn utility. Therefore, the third embodiment is a preferred embodiment in terms of link simplicity, efficiency and security.
Most text providers, such as Netflix, HBO, amazon, pandora, etc., implement a mechanism called geographic blocking (geo-blocking) to enforce their proprietary digital territory rights (digital territorial right). Conversely, geographic home (geo-home) is a mechanism that allows online content to be accessed in the home, and geographic portal (geo-portal) is a mechanism that allows online content to be accessed on the portal. Although the legitimacy of performing geographic blocking is controversial, and region-by-region, some international travelers use virtual private network relay services to circumvent internet protocol-based geographic blocking to access home or foreign based online content that is not available outside of the country in which they are located. In addition to legitimacy, this approach has the disadvantage that it involves additional subscriptions to virtual private network services and limited choices by selecting either geographic households or geographic portals. In addition to the original functionality of allowing private and secure access to metauniverse application gateway device clients and web services in private local area networks from any location in the cloud through the internet, the present invention provides a mechanism for metauniverse providers to dynamically set metauniverse virtual private web servers as desired to flexibly provide a user's choice among geographically blocked, geographically imported websites, or geographically pinned when accessing online content.
While the invention has been described in terms of the illustrated embodiments, those skilled in the art will recognize that the embodiments can be practiced with modification and alteration within the spirit and scope of the claims. Accordingly, modifications may be made by one of ordinary skill in the art without departing from the spirit or scope of the appended claims.
The foregoing description is only of the preferred embodiments of the invention, and all changes and modifications that come within the meaning and range of equivalency of the claims are therefore intended to be embraced therein.
[ description of the symbols ]
100,200,300,400,500,600: public cloud
101,106,107,109,110,111 Smart device client
102,103,202,203,302,303,402,403 Router
104,105,204,205,304,305,404,405,434,504,505 local area network
108 private cloud server
112,212,312,412: public route server
113,213,313,413 public cloud server
114,214 public virtual private network route server
117,119,217,219,317,319,417,419 public network protocol address
118,120,218,220,318,320,418,420 private network protocol address
201,209,210,211,221,701,725,726 private cloud callback server (PCCBS) device client
206,207 Private Cloud Routing Server (PCRS) device client
208,728 private cloud routing server
215 customer information frame
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 Meta-universe network service
240,2400,340,3400,440 virtual local area network
250,350,360,450,460 physical local area network
270 private cloud routing server utility
271 private cloud routing server customer database
272 route server information 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 information frame 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 information frame utility
301,309,310,311,321,401,409,410,411,421,825,853,925,1425,1453,1525 Meta-universe virtual private network server (MVVS) device client
306,307,406,407,435,826,926,1426,1526 Meta-universe application gateway (MVAG) device client
308,408,828,928,1428,1528 Meta-universe application gateway
316,416,827,927,1427,1527 Meta universe virtual private network server
330,430,530,851,951,1451,1551 public cloud entry website (PCP)
331,431,531,532,533,534,832,932,1432,1532 virtual machine Server
370,470,852,952,1452,1552 Meta-universe application
371,374,821,921,1421,1521: MVAG_device utility
372,822,922,1422,1522: mvag_vpn utility
373,820,920,1420,1520 Meta-universe application gateway (MVAG) management device
375 Yuan cosmic virtual private network server region (Domain_MVVS)
376 Meta universe virtual private network server password (passcode_MVVS)
377,850,950,1450,1550 public cloud entry site (PCP) management device
378 public cloud portal device client utility
379 Meta-universe virtual private network server (MVVS) device client authentication
380 Meta-universe virtual private network server (MVVS) server authentication
381 MVVS_device_client utility
382 Meta-universe virtual private network server (MVVS) client login
383 Meta-universe virtual private network Server (MVVS) customer configuration
3710,824,924,1424,1524 MVVS_device utility
3720,823,923,1423,1523: MVVS_VPN utility
502,602 private LAN router
503 visitor local area network router
508 private Material gateway
516 private cloud virtual private network server
541,542,543,544 Internet platform owner cloud
550 private meta universe
551,552,553,554,561,562,563,564 private cloud virtual private network server (PCVS) Smart device client
521,522,523,524,525,526 Private Mass Gateway (PMG) smart device client
603 visitor local area network router
604 private LAN
608 Meta universe application gateway
616 metauniverse virtual private network server
622 archive content server
630 meta space provider portal site
631,632,633,634 virtual machine Server
640 application virtual network
641,642,643,644 Meta-universe cloud provider
650,6320,6330,6340 Meta-universe application
651,652,653,654,661,662,663,664 Meta-universe virtual private network server (MVVS) Smart device client
6250,6251,6262 live streaming event
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,1242,1243,1246,1248,1300,1301,1302,1303,1304,1311,1312,1313,1341,1342,1343,1400,1401,1402,1403,1404,1405,1406,1411,1413,1414,1416,1431,1445,1446,1500,1501,1502,1503,1504,1505,1506,1511,1513,1545,1600,1601,1603,1605,1608,1610,1611,1612,1615,1616,1618,1630,1640,1641,1642,1646,1648 PCRS_device utility, step 721
722 PCRS_VPN utility
723 PCCBS_VPN utility
724 PCCBS_device utility
847,947,1447,1557 PCP_device utility
836,1436 Meta-universe application gateway (MVAG) network services
930,1530 Server farm
931,1531 computer resource aggregation
Claims (28)
1. A method for a linking mechanism in a public cloud network, comprising:
in a client server relationship, setting at least one public cloud portal PCP, at least one virtual machine server VMS, at least one public cloud portal management device, at least one metauniverse virtual private network VPN server MVVS, at least one virtual private network channel, at least one metauniverse virtual private network server smart device client on the at least one metauniverse virtual private network server side to provide a plurality of cloud-based network services, at least one metauniverse application (metaverse application, MA) including at least one private router, at least one private local area network (local area network, LAN), at least one metauniverse application gateway (metaverse application gateway, MVAG), at least one metauniverse application gateway management device, at least one metauniverse application gateway network service, and at least one metauniverse application gateway smart device client on the one metauniverse application gateway private local area network side;
Obtaining a plurality of link authentications from a public cloud portal management device of the at least one public cloud portal management device;
pairing and registering from a meta-cosmic application gateway of the at least one meta-cosmic application gateway with a meta-cosmic virtual private network server of the at least one meta-cosmic virtual private network server;
establishing a plurality of initial virtual private network channels between the metauniverse virtual private network server and the metauniverse application program gateway;
connecting, by the metauniverse virtual private network server, to the metauniverse application gateway as required between a metauniverse virtual private network server smart device client of the at least one metauniverse virtual private network server smart device client and the metauniverse application gateway; and
running a plurality of vertical peer-to-peer P2P private and secure metauniverse virtual private network server smart device client applications between the at least one metauniverse virtual private network server smart device client and one of the at least one metauniverse application gateway smart device client, the at least one metauniverse application gateway network service, or another metauniverse virtual private network server smart device client;
Wherein the linking mechanism is a point-to-point private and secure linking mechanism between the at least one metacosmic virtual private network server smart device client and at least one of the metacosmic application gateway, the at least one metacosmic application gateway smart device client, the at least one metacosmic application gateway network service, or the another metacosmic virtual private network server smart device client;
wherein the at least one public cloud portal site and the at least one virtual machine server comprising the at least one metauniverse virtual private network server are located at a very large scale data center on the public cloud network;
wherein the at least one metauniverse application is located at a plurality of customer remote sites along with the at least one metauniverse application gateway.
2. The method of claim 1, wherein the plurality of link authentications comprise a plurality of metauniverse virtual private network server authentications and a plurality of metauniverse virtual private network server client authentications.
3. The method of claim 2, wherein the at least one public cloud portal is accessed by the at least one public cloud portal management device to log in and obtain the plurality of metauniverse virtual private network server authentications and the plurality of metauniverse virtual private network server client authentications.
4. The method of claim 2, wherein the plurality of metaverse virtual private network server authentications are transmitted to a metaverse application gateway management device of the at least one metaverse application gateway management device, and the plurality of metaverse virtual private network server client authentications are transmitted to the metaverse virtual private network server smart device client for a link.
5. The method of claim 2, wherein the plurality of metaspacecraft virtual private network server authentications include a metaspacecraft virtual private network server area name and a metaspacecraft virtual private network server login password, and the plurality of metaspacecraft virtual private network server client authentications include a metaspacecraft virtual private network server smart device client virtual private network configuration file and a metaspacecraft virtual private network server smart device client virtual private network login password.
6. The method of claim 2, wherein the plurality of metaverse virtual private network server authentications are entered by a metaverse application gateway management device of the at least one metaverse application gateway management device to set to the metaverse application gateway for pairing and registering with the metaverse virtual private network server.
7. The method of claim 1, wherein the step of establishing the plurality of initial virtual private network channels between the metaverse virtual private network server and the metaverse application gateway comprises:
the at least one metauniverse virtual private network server in the public cloud network reverts to the at least one metauniverse application gateway in a private local area network of the at least one metauniverse application to enable a first virtual private network channel;
if the first virtual private network channel is enabled by the at least one metauniverse virtual private network server, the at least one metauniverse application gateway and the at least one metauniverse virtual private network server establish a first virtual private network channel;
enabling a third virtual private network channel with the at least one metauniverse application gateway and the at least one metauniverse virtual private network server if a plurality of proper authentications are established;
the meta-space virtual private network server establishes a third virtual private network channel between the meta-space virtual private network server and the meta-space application gateway according to the requirement, and waits for completion of establishing a second virtual private network channel between the intelligent device client of the meta-space virtual private network server and the meta-space virtual private network server according to the requirement;
Enabling the metauniverse virtual private network server as required by the metauniverse virtual private network server and a second virtual private network channel between intelligent device clients of the at least one metauniverse virtual private network server from a cloud in the Internet; and
the at least one metauniverse virtual private network server intelligent device client establishes the second virtual private network channel between the metauniverse virtual private network server and the at least one metauniverse virtual private network server intelligent device client according to the requirement;
wherein the second virtual private network channel established on demand and the third virtual private network channel established on demand are consolidated into a single virtual private network channel between the metaspacecraft virtual private network server smart device client and the metaspacecraft application gateway through the metaspacecraft virtual private network server, and the single virtual private network channel is ultimately destined for the at least one metaspacecraft application gateway smart device client, the at least one metaspacecraft application gateway network service and the another metaspacecraft virtual private network server smart device client.
8. The method of claim 1, wherein the step of establishing the plurality of initial virtual private network channels between the metaverse virtual private network server and the metaverse application gateway comprises:
the at least one metauniverse virtual private network server in the public cloud network reverts to the at least one metauniverse application gateway in a private local area network of the at least one metauniverse application to enable a first virtual private network channel;
if the first virtual private network channel is enabled by the at least one metauniverse virtual private network server, the at least one metauniverse application gateway and the at least one metauniverse virtual private network server establish a first virtual private network channel;
enabling the metauniverse virtual private network server as required by the metauniverse virtual private network server and a second virtual private network channel between intelligent device clients of the at least one metauniverse virtual private network server from a cloud in the Internet; and
the at least one metauniverse virtual private network server intelligent device client establishes the second virtual private network channel between the metauniverse virtual private network server and the at least one metauniverse virtual private network server intelligent device client according to the requirement;
Wherein the first virtual private network channel and the second virtual private network channel established as required are combined into a single virtual private network channel between the metaspacecraft virtual private network server smart device client and the metaspacecraft application gateway through the metaspacecraft virtual private network server, and the single virtual private network channel is finally transmitted to the at least one metaspacecraft application gateway smart device client, the at least one metaspacecraft application gateway network service and the another metaspacecraft virtual private network server smart device client.
9. The method of claim 1, wherein the step of connecting to the metaspacecraft gateway on demand between the metaspacecraft virtual private network server smart device client and the metaspacecraft application gateway through the metaspacecraft virtual private network server comprises:
the at least one metaverse virtual private network server smart device client initiates a request for connecting to the at least one metaverse virtual private network server through a metaverse virtual private network server virtual private network client configuration to establish a second virtual private network channel as required in case the at least one metaverse 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 in a private local area network of the at least one metaverse application.
10. The method of claim 1, wherein the step of running the plurality of vertical peer-to-peer private and secure metaspacecraft virtual private network server smart device applications between the at least one metaspacecraft virtual private network server smart device client and the at least one metaspacecraft application gateway smart device client, the at least one metaspacecraft application gateway network service, or the another metaspacecraft virtual private network server smart device client comprises:
the metauniverse virtual private network server intelligent device client in the public cloud network is used as a visitor and a host metauniverse virtual private network server intelligent device client to join a private and safe communication session;
wherein the metauniverse virtual private network server smart device client is accessible in a local area network mode for a virtual private network link from the at least one metauniverse virtual private network server smart device client;
wherein the private and secure communication session comprises at least one of an image, a voice, a text, or an application, and the application comprises a program, a utility, an operation, or a transaction recognizable by the metauniverse virtual private network server smart device client and the host metauniverse virtual private network server smart device client;
Wherein the at least one metaspace application gateway smart device client is accessible in the local area network mode along with the at least one metaspace application gateway network service on a private local area network of the at least one metaspace application gateway, the access for the virtual private network link from the at least one metaspace virtual private network server smart device client.
11. The method of claim 10, wherein the application is a cryptocurrency application comprising a program, a utility, a run or a transaction identifiable by the metaspacecraft virtual private network server smart device client and the host metaspacecraft virtual private network server smart device client when the plurality of vertical point-to-point private and secure metaspacecraft virtual private network server smart device client applications between the at least one metaspacecraft virtual private network server smart device client and the another metaspacecraft virtual private network server smart device client are run.
12. The method of claim 10, wherein the metaspacecraft virtual private network server is configured as needed to provide a geographic seal, a geographic portal, or a plurality of choices between a geographic residence when accessing an online content when the plurality of vertical point-to-point private and secure metaspacecraft virtual private network server smart device client applications between the at least one metaspacecraft virtual private network server smart device client and the another metaspacecraft virtual private network server smart device client are running.
13. The method of claim 1, wherein the at least one public cloud portal comprises:
an internet service; and
a program for executing instructions stored in a memory to instruct the at least one public cloud portal to:
creating and managing an authorized client list to accommodate the at least one public cloud portal management device;
creating and managing the plurality of link authentications including a plurality of metauniverse virtual private network server authentications and a plurality of metauniverse virtual private network server client authentications; and
the step of obtaining the plurality of link authentications from the public cloud portal management apparatus is performed.
14. The method of claim 1, wherein the at least one virtual machine server comprises:
an internet service; and
a program for executing instructions stored in memory to instruct the at least one virtual machine server to:
creating and managing an authorized client list to accommodate the at least one public cloud portal management device, the at least one metauniverse application gateway, and the at least one metauniverse virtual private network server; and
Managing a communication between the metauniverse virtual private network server and the metauniverse virtual private network server smart device client.
15. The method of claim 1, wherein the at least one public cloud portal management device comprises:
a computing device;
a link to a network; and
a program for executing instructions stored in a memory to instruct the at least one public cloud portal management device to:
establishing a first network service operating in a local area network mode;
establishing a second network service according to the internet protocol;
establishing a third network service according to an industry standard network protocol; and
the step of obtaining the plurality of link authentications from the public cloud portal management apparatus is performed.
16. The method of claim 1, wherein the at least one metauniverse virtual private network server comprises:
a computing device;
a link to a network; and
a program for executing instructions stored in a memory to instruct the at least one metauniverse virtual private network server to:
Creating and managing a first list of authorized clients via at least one virtual private network link to accommodate the at least one metauniverse virtual private network server smart device client;
creating and managing a second list of authorized clients via the at least one virtual private network link to accommodate the at least one metauniverse application gateway;
executing the step of pairing and registering with the metauniverse virtual private network server from the metauniverse application program gateway;
executing the step of establishing the plurality of initial virtual private network channels between the metauniverse virtual private network server and the metauniverse application gateway; and
the step of connecting to the metauniverse application gateway as required between the metauniverse virtual private network server smart device client and the metauniverse application gateway through the metauniverse virtual private network server is performed.
17. The method of claim 1, wherein the at least one metauniverse virtual private network server smart device client comprises:
a computing device;
a link to a network; and
a program for executing instructions stored in memory to instruct the at least one metauniverse virtual private network server smart device client to:
Establishing a first network service according to an internet protocol;
establishing a second network service according to an industry standard network protocol;
creating and managing an internet link with the at least one virtual machine server and the at least one metauniverse virtual private network server through a virtual private network link;
creating and managing a link with the at least one metauniverse application gateway intelligent device client via the virtual private network link;
executing the step of connecting to the metauniverse application gateway as required between the metauniverse virtual private network server smart device client and the metauniverse application gateway through the metauniverse virtual private network server; and
executing the step of running the plurality of vertical point-to-point private and secure metaspacecraft virtual private network server smart device client applications between the at least one metaspacecraft virtual private network server smart device client and the at least one metaspacecraft application gateway smart device client, the at least one metaspacecraft application gateway network service, or the another metaspacecraft virtual private network server smart device client.
18. The method of claim 1, wherein the at least one metauniverse application comprises:
an internet router;
at least one private local area network;
at least one metauniverse network service;
the at least one metauniverse application gateway smart device client; and
the at least one metauniverse application gateway.
19. The method of claim 1, wherein the at least one meta-space application gateway comprises:
a computing device;
a link to a network; and
a program for executing instructions stored in a memory to instruct the at least one metauniverse application gateway to perform operations comprising:
creating and managing an authorized client list via a virtual private network link to accommodate the at least one metauniverse virtual private network server;
executing the step of pairing and registering with the metauniverse virtual private network server from the metauniverse application program gateway;
executing the step of establishing the plurality of initial virtual private network channels between the metauniverse virtual private network server and the metauniverse application gateway;
executing the step of connecting to the metauniverse application gateway as required between the metauniverse virtual private network server smart device client and the metauniverse application gateway through the metauniverse virtual private network server; and
Executing the step of running the plurality of vertical point-to-point private and secure metaspacecraft virtual private network server smart device client applications between the at least one metaspacecraft virtual private network server smart device client and the at least one metaspacecraft application gateway smart device client, the at least one metaspacecraft application gateway network service, or the another metaspacecraft virtual private network server smart device client.
20. The method of claim 1, wherein the at least one metaverse application gateway web service comprises:
a first network service operating in a LAN mode that avoids external monitoring and logging due to the strength of an industry-accepted VPN channel;
a second web service based on an agreement of the internet;
a third network service based on a protocol of an industry standard network;
a fourth network service that is peripheral platform independent and compatible with all existing fragmented internet of things IoT devices; and
and a fifth network service, based on the passing through the metauniverse virtual private network server, connecting to the metauniverse application gateway as required between the metauniverse virtual private network server intelligent device client and the metauniverse application gateway.
21. The method of claim 1, wherein the at least one metauniverse application gateway smart device client comprises:
a computing device;
a link to a network; and
a program for executing instructions stored in a memory to instruct the at least one metauniverse application gateway smart device client to:
establishing a first network service operating in a local area network mode;
establishing a second network service according to the internet protocol;
establishing a third network service according to an industry standard network protocol;
executing the step of connecting to the metauniverse application gateway as required between the metauniverse virtual private network server smart device client and the metauniverse application gateway through the metauniverse virtual private network server; and
executing the step of running the plurality of vertical point-to-point private and secure metaspacecraft virtual private network server smart device client applications between the at least one metaspacecraft virtual private network server smart device client and the at least one metaspacecraft application gateway smart device client.
22. The method of claim 1, wherein the at least one meta-space application gateway management device comprises:
a computing device;
a link to a network; and
a program for executing instructions stored in a memory to instruct the at least one metauniverse application gateway management device to perform the following operations:
establishing a first network service operating in a local area network mode;
establishing a second network service according to the internet protocol;
establishing a third network service according to an industry standard network protocol; and
the step of pairing and registering with the metauniverse virtual private network server from the metauniverse application gateway is performed.
23. The method of claim 1, wherein the at least one virtual private network channel comprises:
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-staling interactive operation and compatibility in the communication;
access through a local area network mode of the at least one virtual private network channel;
At least one first virtual private network channel of the plurality of initial virtual private network channels between the metauniverse virtual private network server and the metauniverse application gateway; and
at least one second virtual private network channel between the metauniverse virtual private network server smart device client and the metauniverse application gateway through the metauniverse virtual private network server.
24. A method for a linking mechanism between at least one metauniverse virtual private network VPN server MVVS smart device client and one of at least one metauniverse application gateway MVAG smart device client or at least one metauniverse application gateway network service through a public cloud network, comprising:
connecting, by a metauniverse virtual private network server, between a metauniverse virtual private network server intelligent device client and a metauniverse application gateway of the at least one metauniverse virtual private network server intelligent device client, as required, to the metauniverse application gateway; and
running a plurality of vertical peer-to-peer P2P private and secure metauniverse virtual private network server smart device client applications between the at least one metauniverse virtual private network server smart device client and one of the at least one metauniverse application gateway smart device client, the at least one metauniverse application gateway network service, or another metauniverse virtual private network server smart device client;
Wherein the at least one metauniverse virtual private network server smart device client and the one of the at least one metauniverse application gateway smart device client, the at least one metauniverse application gateway network service, or another metauniverse virtual private network server smart device client are in private and secure communication over the public cloud network.
25. A non-transitory computer readable medium storing executable instructions that cause a computer to perform, in response to:
setting a meta-universe virtual private network VPN server MVVS and a meta-universe virtual private network server intelligent device client in a server relation of a client;
executing the method between the metauniverse virtual private network server and a metauniverse application program gateway MVAG to establish a plurality of initial virtual private network channels; and
executing the operation of connecting the meta-cosmic virtual private network server intelligent device client and the meta-cosmic application gateway to the meta-cosmic application gateway according to the requirement;
wherein in a public cloud network, the metauniverse virtual private network server comprises an mvvs_device utility program.
26. A non-transitory computer readable medium storing executable instructions that cause a computer to perform, in response to:
setting a metauniverse virtual private network VPN server MVVS and a metauniverse application program gateway MVAG in a server relation of a client;
executing the matching and registering between the meta-universe application program gateway and the meta-universe virtual private network server;
executing the first virtual private network channel between the meta space virtual private network server and the meta space application program gateway, and establishing a plurality of initial virtual private network channels;
executing the process of connecting the client of the intelligent device of the metauniverse virtual private network server and the metauniverse application program gateway to the metauniverse application program gateway according to the requirement through the metauniverse virtual private network server; and
executing a plurality of vertical peer-to-peer P2P private and secure metauniverse virtual private network server smart device client applications between at least one metauniverse virtual private network server smart device client and one of the at least one metauniverse application gateway smart device client, at least one metauniverse application gateway network service, or another metauniverse virtual private network server smart device client.
27. A method for communication, comprising:
in a client server relationship, setting at least one virtual machine server VMS, at least one metacosmic virtual private network VPN server MVVS, at least one metacosmic virtual private network server smart device client on the side of the at least one metacosmic virtual private network server to provide a plurality of cloud-based network services, at least one metacosmic application gateway MVAG and at least one metacosmic application gateway smart device client on the side of the at least one metacosmic application gateway;
wherein the at least one virtual machine server comprises the at least one metauniverse virtual private network server to provide the plurality of cloud-based network services;
wherein the at least one virtual machine server and the at least one metauniverse virtual private network server are located in a very large scale data center, and the at least one metauniverse application gateway is located in application environments of a plurality of metauniverse providers;
wherein the at least one virtual machine server is scalable in number and size;
wherein at least one of the very large scale data center and a service provider builds and configures a plurality of independent metauniverse virtual private network servers in a plurality of corresponding virtual machine servers to serve a plurality of corresponding metauniverse application gateways and a plurality of corresponding metauniverse application gateway smart device clients;
Wherein a community pairing of the at least one metauniverse virtual private network server smart device client and a peer-to-peer P2P communication relationship between the at least one metauniverse application gateway smart device client is established and deployed by an internet metauniverse provider maintaining the at least one virtual machine server;
wherein the internet metauniverse provider provides to a metauniverse provider hosting the metauniverse virtual private network server in the at least one virtual machine server;
wherein the Internet metacosmic provider provides a separate private and secure metacosmic application gateway to the metacosmic provider to install the metacosmic application gateway in the metacosmic provider's local area network;
one of the metacosmic subscribers is located in a private and secure local area network of the metacosmic provider and establishes a point-to-point communication from anywhere between the at least one metacosmic virtual private network server smart device client and the at least one metacosmic application gateway smart device client.
28. A non-transitory computer readable medium storing executable instructions that cause a computer to perform, in response to:
Setting at least one metauniverse application program gateway MVAG intelligent device client and one metauniverse virtual private network VPN server MVVS intelligent device client application program in a server relation of a client;
wherein the metauniverse virtual private network server smart device client application comprises an application utility in a public cloud network;
wherein a function of the at least one metauniverse application gateway smart device client is transferred to a class code definition of the metauniverse virtual private network server smart device client application;
wherein a plurality of vendor-specific software modules or applications are loaded by the metacosmic virtual private network server smart device client application to support a corresponding metacosmic application gateway smart device client of the at least one metacosmic application gateway smart device client from a different manufacturer;
the device categories of the at least one metaspace application gateway smart device client include a voice, an image, a human interface device, an internet protocol IP camera, a smart lock, a smart light bulb, a remote control, a thermostat, a printer, a mass storage device, a bluetooth, a specific application, and a specific vendor.
Applications Claiming Priority (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US17/736,103 | 2022-05-04 | ||
| US17/849,741 US20220329569A1 (en) | 2011-09-09 | 2022-06-27 | Metaverse Application Gateway Connection Mechanism for Use in a Private Communication Architecture |
| US17/849,741 | 2022-06-27 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN117014177A true CN117014177A (en) | 2023-11-07 |
Family
ID=88566114
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202211522375.5A Pending CN117014177A (en) | 2022-05-04 | 2022-11-30 | Meta universe application gateway linking mechanism for private communication architecture |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN117014177A (en) |
-
2022
- 2022-11-30 CN CN202211522375.5A patent/CN117014177A/en active Pending
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US11356417B2 (en) | Private cloud routing server connection mechanism for use in a private communication architecture | |
| US9515875B2 (en) | Zero touch deployment of multi-tenant services in a home network environment | |
| US9781087B2 (en) | Private and secure communication architecture without utilizing a public cloud based routing server | |
| US20140359704A1 (en) | Private cloud routing server, private network service and smart device client architecture without utilizing a public cloud based routing server | |
| TWI574164B (en) | Private cloud routing server connection mechanism for use in a private communication architecture | |
| US20150195270A1 (en) | Private and secure communication architecture without utilizing a public cloud based routing server | |
| US11863529B2 (en) | Private cloud routing server connection mechanism for use in a private communication architecture | |
| TWI632465B (en) | Method for use with a public cloud network, private cloud routing server and smart device client | |
| US20230254292A1 (en) | Private and Secure Chat Connection Mechanism for Use in a Private Communication Architecture | |
| US20220329569A1 (en) | Metaverse Application Gateway Connection Mechanism for Use in a Private Communication Architecture | |
| US20220385638A1 (en) | Private Matter Gateway Connection Mechanism for Use in a Private Communication Architecture | |
| GB2531831A (en) | Private and secure communication architecture without utilizing a public cloud based routing server | |
| US11683292B2 (en) | Private cloud routing server connection mechanism for use in a private communication architecture | |
| US11888898B2 (en) | Network configuration security using encrypted transport | |
| GB2607362A (en) | Private cloud routing server connection mechanism for use in a private communication architecture | |
| TWI829435B (en) | Metaverse application gateway connection mechanism for use in a private communication architecture | |
| TWI829487B (en) | Private matter gateway connection mechanism for use in a private communication architecture | |
| CN117014177A (en) | Meta universe application gateway linking mechanism for private communication architecture | |
| TWI836974B (en) | Private and secure chat connection mechanism for use in a private communication architecture | |
| US20230083939A1 (en) | Private Matter Gateway Connection Mechanism for Use in a Private Communication Architecture | |
| CN117014251A (en) | Private substance gateway linking mechanism for private communication architecture | |
| CN117014435A (en) | Private secure chat join mechanism for private communication architecture | |
| TW202345559A (en) | Private and secure chat connection mechanism for use in a private communication architecture | |
| TWI769965B (en) | Connection method and computer-readable medium for use in a private communication architecture | |
| GB2532832A (en) | Private and secure communication architecture without utilizing a public cloud based routing server |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination |