A novel web3 credential for enterprise device mobility for logistics and other use-cases

Abstract

In a system, apparatus, method, and non-transitory computer readable medium for implementing trustless authentication of enterprise devices on a private network using Web3 credentials, a network device may be caused to, provide a public key associated with the network device to an enterprise server, the enterprise server and the network device associated with an enterprise, obtain a decentralized identifier associated with the network device from the enterprise server in response to the provided public key, provide the decentralized identifier to an access server associated with a private network, the decentralized identifier enabling the access server to perform trustless authentication of the network device, and connect to the private network based on results of the trustless authentication.

Description

[0001] A NOVEL WEB3 CREDENTIAL FOR ENTERPRISE DEVICE MOBILITY FOR LOGISTICS AND OTHER USE-CASES

[0002] BACKGROUND

[0003] Field

[0004] HI Various example embodiments relate to methods, apparatuses, systems, and / or non-transitory computer readable media for implementing trustless authentication of enterprise devices, e.g., authentication without a trusted third party, on a private network using Web3-based credentials.

[0005] Description of the Related Art

[0006] [21 Typically, users of mobile devices are subscribed to a home private network, such as a mobile network operator (MNO), etc., and are assigned a subscriber identifier which is assigned by the home private network, such as a physical subscriber identifier module (SIM) card, an e-SIM, or the like. When the mobile device user travels (e.g., roams) to an area covered by a different private and / or public network, the mobile device user may connect to and use the roaming network if the MNO of the home network has agreements (e.g., roaming agreements) in place with the MNO of the roaming network without having to subscribe to and / or authenticate themselves to the roaming network. Otherwise, if the home network MNO does not have a roaming agreement in place with the MNO of the roaming network ahead of time, the mobile device of the user will fail to connect to the roaming network and the user will have to subscribe to the MNO of the roaming network. [31 Additionally, there are centralized virtual network operators which may contract access to a plurality of private networks and / or public networks (e.g., WiFi networks associated with various Universities, commercial buildings, airports / airplanes, etc., and / or private cellular networks, etc.), such that a user who is subscribed to the centralized virtual network operator is able to access the private and / or public networks of the contracted partners of the centralized virtual network operator without subscribing to the individual private and / or public networks.

[0007] SUMMARY

[0008] 141 At least one example embodiment relates to a network device.

[0009] 15 In at least one example embodiment, the network device may include a memory storing computer readable instructions, and processing circuitry configured to execute the computer readable instructions to cause the network device to, provide a public key associated with the network device to an enterprise server, the enterprise server and the network device being associated with an enterprise, obtain a decentralized identifier associated with the network device from the enterprise server in response to the provided public key, provide the decentralized identifier to an access server associated with a private network, the decentralized identifier enabling the access server to perform trustless authentication of the network device, and connect to the private network based on results of the trustless authentication.

[0010] 161 Some example embodiments provide that the decentralized identifier includes the public key associated with the network device, a device token account associated with the public key, and a connectivity token issued by the enterprise server.

[0011] 121 Some example embodiments provide that the device token account and the connectivity token are included in a blockchain record associated with a blockchain server, and the blockchain record is network accessible to the enterprise server and the access server.

[0012] 181 Some example embodiments provide that the device token account includes owner information associated with the network device and electronic financial information associated with the network device.

[0013] 121 Some example embodiments provide that the connectivity token includes a link to a smart contract program associated with the enterprise. Some example embodiments provide that the network device is further caused to, receive a challenge message from the access server, the challenge message including target data, sign the target data with a private key associated with the network device, the private key corresponding to the public key, and provide a response message to the access server, the response message including the signed target data, the response message enabling the access server to perform the trustless authentication of the network device by verifying the signature on the signed target data using the public key associated with the network device.

[0014] [Ill Some example embodiments provide that the network device is further caused to, obtain an encrypted data session key for the private network from the access server based on the signed target data and the decentralized identifier, and connect to the private network by establishing an encrypted data session with the private network using the data session key. [121 At least one example embodiment relates to a network server associated with an enterprise.

[0015] [131 In at least one example embodiment, the network server may include a memory storing computer readable instructions, and processing circuitry configured to execute the computer readable instructions to cause the network server to, obtain a public key from a network device, the public key associated with the network device, the network device associated with the enterprise, generate a decentralized identifier associated with the network device in response to the obtained public key, the decentralized identifier including the public key, a device token account associated with the public key, a connectivity token issued by the network server, and transmit the decentralized identifier to the network device, the transmission enabling the network device to start connecting to a private network via trustless authentication using the decentralized identifier.

[0016] [141 Some example embodiments provide that the network server is further caused to, transmit a mint token request to a blockchain server, the mint token request including the public key, the mint token request causing the blockchain server to generate the connectivity token associated with the network server on a blockchain record associated with the blockchain server, the blockchain record being network accessible to the network server and an access server associated with the private network, and receive the connectivity token from the blockchain server.

[0017] [151 Some example embodiments provide that the connectivity token includes at least one of: mint authority information associated with the network server, terms and conditions information set by the network server, a link to a smart contract associated with the network server stored on the blockchain record, a link to the smart contract associated with the network server not stored on the blockchain record, or any combinations thereof.

[0018] [161 Some example embodiments provide that the network server is further caused to, transmit a token account generation request to the blockchain server, the token account generation request including the public key, the token account generation request causing the blockchain server to generate the device token account associated with the public key on the blockchain record, and receive the device token account from the blockchain server. [171 Some example embodiments provide that the network server is further caused to add electronic financial information associated with the network device to the device token account.

[0019] [181 At least one example embodiment relates to a network server.

[0020] [191 In at least one example embodiment, the network server may include a memory storing computer readable instructions, and processing circuitry configured to execute the computer readable instructions to cause the network server to, obtain a decentralized identifier from a network device, the decentralized identifier including a public key associated with the network device, a device token account associated with the public key, and a connectivity token issued by an enterprise server, the enterprise server and the network device associated with an enterprise, perform trustless authentication of the network device based on the decentralized identifier, and grant access to a private network associated with the network server to the network device based on results of the trustless authentication of the network device.

[0021] [201 Some example embodiments provide that the network server is further caused to perform the trustless authentication by, providing a challenge message to the network device, the challenge message including target data to be signed by the network device, obtaining a response message from the network device, the response message including signed target data signed by the network device using a private key, verifying the signature on the signed target data using the public key associated with the network device, and denying access to the private network to the network device in response to failure of signature verification of the signed target data using the public key.

[0022] [211 Some example embodiments provide that the device token account and the connectivity token are included in a blockchain record associated with a blockchain server, and the blockchain record is network accessible to the enterprise server and the network server.

[0023] [221 Some example embodiments provide that the network server is further caused to perform the trustless authentication by, accessing a smart contract associated with the enterprise server via a link included in the connectivity token, and validating the smart contract based on contract criteria associated with the private network.

[0024] [231 Some example embodiments provide that the smart contract is stored on the blockchain record or the smart contract is stored at a network location not on the blockchain record. [241 Some example embodiments provide that the network server is further caused to perform the trustless authentication by, obtaining ownership information included in the device token account from the blockchain record, and determining whether the device token account is associated with the network device based on the ownership information and the public key.

[0025] [251 Some example embodiments provide that the network server is further caused to perform the trustless authentication by, obtaining terms and condition information included in the connectivity token, and validating the terms and condition information based on terms and condition criteria associated with the private network.

[0026] [261 Some example embodiments provide that the network server is further caused to grant access to the private network to the network device by providing an encrypted data session key for the private network to the network device, the encrypted data session key enabling the network device to establish an encrypted data session with the private network.

[0027] [271 At least one example embodiment relates to a network device.

[0028] [281 In at least one example embodiment, the network device may include means for providing a public key associated with the network device to an enterprise server, the enterprise server and the network device being associated with an enterprise, obtaining a decentralized identifier associated with the network device from the enterprise server in response to the provided public key, providing the decentralized identifier to an access server associated with a private network, the decentralized identifier enabling the access server to perform trustless authentication of the network device, and connecting to the private network based on results of the trustless authentication.

[0029] [291 Some example embodiments provide that the decentralized identifier includes the public key associated with the network device, a device token account associated with the public key, and a connectivity token issued by the enterprise server.

[0030] [301 Some example embodiments provide that the device token account and the connectivity token are included in a blockchain record associated with a blockchain server, and the blockchain record is network accessible to the enterprise server and the access server.

[0031] [311 Some example embodiments provide that the device token account includes owner information associated with the network device and electronic financial information associated with the network device. [321 Some example embodiments provide that the connectivity token includes a link to a smart contract program associated with the enterprise.

[0032] [331 Some example embodiments provide that the network device further includes means for, receiving a challenge message from the access server, the challenge message including target data, signing the target data with a private key associated with the network device, the private key corresponding to the public key, and providing a response message to the access server, the response message including the signed target data, the response message enabling the access server to perform the trustless authentication of the network device by verifying the signature on the signed target data using the public key associated with the network device.

[0033] [341 Some example embodiments provide that the network device further includes means for, obtaining an encrypted data session key for the private network from the access server based on the signed target data and the decentralized identifier, and connecting to the private network by establishing an encrypted data session with the private network using the data session key.

[0034] [351 At least one example embodiment relates to a network server associated with an enterprise.

[0035] [361 In at least one example embodiment, the network server may include means for, obtaining a public key from a network device, the public key associated with the network device, the network device associated with the enterprise, generating a decentralized identifier associated with the network device in response to the obtained public key, the decentralized identifier including the public key, a device token account associated with the public key, a connectivity token issued by the network server, and transmitting the decentralized identifier to the network device, the transmission enabling the network device to start connecting to a private network via trustless authentication using the decentralized identifier.

[0036] [371 Some example embodiments provide that the network server further includes means for, transmitting a mint token request to a blockchain server, the mint token request including the public key, the mint token request causing the blockchain server to generate the connectivity token associated with the network server on a blockchain record associated with the blockchain server, the blockchain record being network accessible to the network server and an access server associated with the private network, and receiving the connectivity token from the blockchain server. [381 Some example embodiments provide that the connectivity token includes at least one of: mint authority information associated with the network server, terms and conditions information set by the network server, a link to a smart contract associated with the network server stored on the blockchain record, a link to the smart contract associated with the network server not stored on the blockchain record, or any combinations thereof.

[0037] [391 Some example embodiments provide that the network server further includes means for, transmitting a token account generation request to the blockchain server, the token account generation request including the public key, the token account generation request causing the blockchain server to generate the device token account associated with the public key on the blockchain record, and receiving the device token account from the blockchain server.

[0038] [401 Some example embodiments provide that the network server further includes means for adding electronic financial information associated with the network device to the device token account.

[0039] [411 At least one example embodiment relates to a network server.

[0040] [421 In at least one example embodiment, the network server may include means for, obtaining a decentralized identifier from a network device, the decentralized identifier including a public key associated with the network device, a device token account associated with the public key, and a connectivity token issued by an enterprise server, the enterprise server and the network device associated with an enterprise, performing trustless authentication of the network device based on the decentralized identifier, and granting access to a private network associated with the network server to the network device based on results of the trustless authentication of the network device.

[0041] [431 Some example embodiments provide that the network server further includes means for performing the trustless authentication by, providing a challenge message to the network device, the challenge message including target data to be signed by the network device, obtaining a response message from the network device, the response message including signed target data signed by the network device using a private key, verifying the signature on the signed target data using the public key associated with the network device, and denying access to the private network to the network device in response to failure of signature verification of the signed target data using the public key. [441 Some example embodiments provide that the device token account and the connectivity token are included in a blockchain record associated with a blockchain server, and the blockchain record is network accessible to the enterprise server and the network server.

[0042] [451 Some example embodiments provide that the network server further includes means for performing the trustless authentication by, accessing a smart contract associated with the enterprise server via a link included in the connectivity token, and validating the smart contract based on contract criteria associated with the private network.

[0043] [461 Some example embodiments provide that the smart contract is stored on the blockchain record or the smart contract is stored at a network location not on the blockchain record.

[0044] [471 Some example embodiments provide that the network server further includes means for performing the trustless authentication by, obtaining ownership information included in the device token account from the blockchain record, and determining whether the device token account is associated with the network device based on the ownership information and the public key.

[0045] [481 Some example embodiments provide that the network server further includes means for performing the trustless authentication by, obtaining terms and condition information included in the connectivity token, and validating the terms and condition information based on terms and condition criteria associated with the private network.

[0046] [491 Some example embodiments provide that the network server further includes means for granting access to the private network to the network device by providing an encrypted data session key for the private network to the network device, the encrypted data session key enabling the network device to establish an encrypted data session with the private network.

[0047] BRIEF DESCRIPTION OF THE DRAWINGS

[0048] [501 The accompanying drawings, which are incorporated in and constitute a part of the specification, illustrate one or more example embodiments and, together with the description, explain these example embodiments. In the drawings:

[0049] [511 FIG. 1 illustrates a wireless network system according to at least one example embodiment; [521 FIG. 2 illustrates a block diagram of an example network node according to at least one example embodiment;

[0050] [531 FIG. 3 illustrates a block diagram of an example UE device according to at least one example embodiment;

[0051] [541 FIG. 4A illustrates an example transmission flow diagram for provisioning an enterprise user device according to some example embodiments;

[0052] [551 FIG. 4B illustrates an example decentralized identifier according to at least one example embodiment;

[0053] [561 FIG. 5 A illustrates an example transmission flow diagram for performing trustless authentication between an enterprise user device and a new private network according to some example embodiments; and

[0054] [571 FIG. 5B illustrates an example private network verification check according to some example embodiments.

[0055] DETAILED DESCRIPTION

[0056] [581 Various example embodiments will now be described more fully with reference to the accompanying drawings in which some example embodiments are shown.

[0057] [591 Detailed example embodiments are disclosed herein. However, specific structural and functional details disclosed herein are merely representative for purposes of describing the example embodiments. The example embodiments may, however, be embodied in many alternate forms and should not be construed as limited to only the example embodiments set forth herein.

[0058] [601 It will be understood that, although the terms first, second, etc. may be used herein to describe various elements, these elements should not be limited by these terms. These terms are only used to distinguish one element from another. For example, a first element could be termed a second element, and, similarly, a second element could be termed a first element, without departing from the scope of the example embodiments. As used herein, the term “and / or,” includes any and all combinations of one or more of the associated listed items.

[0059] [611 It will be understood that when an element is referred to as being “connected,” or “coupled,” to another element, it can be directly connected or coupled to the other element or intervening elements may be present. In contrast, when an element is referred to as being “directly connected,” or “directly coupled,” to another element, there are no intervening elements present. Other words used to describe the relationship between elements should be interpreted in a like fashion (e.g., “between,” versus “directly between,” “adjacent,” versus “directly adjacent,” etc.).

[0060] [621 The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the example embodiments. As used herein, the singular forms “a,” “an,” and “the,” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms “comprises,” “comprising,” “includes,” and / or “including,” when used herein, specify the presence of stated features, integers, steps, operations, elements, and / or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and / or groups thereof.

[0061] [631 It should also be noted that in some alternative implementations, the functions / acts noted may occur out of the order noted in the figures. For example, two figures shown in succession may in fact be executed substantially concurrently or may sometimes be executed in the reverse order, depending upon the functionality / acts involved.

[0062] [641 Specific details are provided in the following description to provide a thorough understanding of the example embodiments. However, it will be understood by one of ordinary skill in the art that example embodiments may be practiced without these specific details. For example, systems may be shown in block diagrams in order not to obscure the example embodiments in unnecessary detail. In other instances, well-known processes, structures and techniques may be shown without unnecessary detail in order to avoid obscuring example embodiments.

[0063] [651 Also, it is noted that example embodiments may be described as a process depicted as a flowchart, a flow diagram, a data flow diagram, a structure diagram, or a block diagram. Although a flowchart may describe the operations as a sequential process, many of the operations may be performed in parallel, concurrently or simultaneously. In addition, the order of the operations may be re-arranged. A process may be terminated when its operations are completed, but may also have additional steps not included in the figure. A process may correspond to a method, a function, a procedure, a subroutine, a subprogram, etc. When a process corresponds to a function, its termination may correspond to a return of the function to the calling function or the main function.

[0064] [661 Moreover, as disclosed herein, the term “memory” may represent one or more devices for storing data, including random access memory (RAM), magnetic RAM, core memory, and / or other machine readable mediums for storing information. The term “storage medium” may represent one or more devices for storing data, including read only memory (ROM), random access memory (RAM), magnetic RAM, core memory, magnetic disk storage mediums, optical storage mediums, flash memory devices and / or other machine readable mediums for storing information. The term “computer-readable medium” may include, but is not limited to, portable or fixed storage devices, optical storage devices, wireless channels, and various other mediums capable of storing, containing or carrying instruction(s) and / or data.

[0065] F671 Furthermore, example embodiments may be implemented by hardware circuitry and / or software, firmware, middleware, microcode, hardware description languages, etc., in combination with hardware (e.g., software executed by hardware, etc.). When implemented in software, firmware, middleware or microcode, the program code or code segments to perform the desired tasks may be stored in a machine or computer readable medium such as a non-transitory computer storage medium, and loaded onto one or more processors to perform the desired tasks.

[0066] [681 A code segment may represent a procedure, a function, a subprogram, a program, a routine, a subroutine, a module, a software package, a class, or any combination of instructions, data structures, or program statements. A code segment may be coupled to another code segment or a hardware circuit by passing and / or receiving information, data, arguments, parameters, or memory contents. Information, arguments, parameters, data, etc. may be passed, forwarded, or transmitted via any suitable means including memory sharing, message passing, token passing, network transmission, etc.

[0067] [691 As used in this application, the term “circuitry” and / or “hardware circuitry” may refer to one or more or all of the following: (a) hardware-only circuit implementation (such as implementations in only analog and / or digital circuitry); (b) combinations of hardware circuits and software, such as (as applicable): (i) a combination of analog and / or digital hardware circuit(s) with software / firmware, and (ii) any portions of hardware processor(s) with software (including digital signal processor(s)), software, and memory(ies) that work together to cause an apparatus, such as a mobile phone or server, to perform various functions); and (c) hardware circuit(s) and / or processor(s), such as microprocessor(s) or a portion of a microprocessor(s), that requires software (e.g., firmware) for operation, but the software may not be present when it is not needed for operation. For example, the circuitry more specifically may include, but is not limited to, a central processing unit (CPU), an arithmetic logic unit (ALU), a digital signal processor, a microcomputer, a field programmable gate array (FPGA), a System-on-Chip (SoC), a programmable logic unit, a microprocessor, application-specific integrated circuit (ASIC), etc.

[0068] 1701 This definition of circuitry applies to all uses of this term in this application, including in any claims. As a further example, as used in this application, the term circuitry also covers an implementation of merely a hardware circuit or processor (or multiple processors) or portion of a hardware circuit or processor and its (or their) accompanying software and / or firmware. The term circuitry also covers, for example and if applicable to the particular claim element, a baseband integrated circuit or processor integrated circuit for a mobile device or a similar integrated circuit in server, a cellular network device, or other computing or network device.

[0069] [711 While the various example embodiments of the present disclosure are discussed in connection with the 5G wireless communication standard for the sake of clarity and convenience, the example embodiments are not limited thereto, and one of ordinary skill in the art would recognize the example embodiments may be applicable to other wireless communication standards, such as the 4G standard, a Wi-Fi standard, a future 6G standard, a future 7G standard, etc.

[0070] [721 Various example embodiments are directed towards providing access to a private network for enterprise devices via trustless authentication of the enterprise devices, e.g., authentication of the enterprise devices without the services of a trusted third party, using Web3-based credentials. According to some example embodiments, the private network may be a private network which is previously unknown and / or unaccessed by either the enterprise and / or the enterprise devices. In particular, at least one example embodiment is directed towards enabling an enterprise device to access a private network of a private network operator which was previously unknown and / or unaccessed to either the enterprise and / or the enterprise devices using trustless authentication, e.g., by using a decentralized root of trust, such as a decentralized public ledger platform, a blockchain platform, etc. In some example embodiments, the decentralized root of trust may be a live (e.g., online) blockchain cluster, blockchain record, etc. In other example embodiments, the trustless authentication may be performed via an offline transaction corresponding to the permissioned or permissionless blockchain cluster, blockchain record, etc. While roaming agreements between MNOs and centralized virtual network operators (VNOs) are known, these types of services require the arrangement of agreements and / or contracts between MNOs and / or VNOs prior to a user of a first network to be able to access and / or use the network of a second network. Further, if no agreement is in place between the network operator of the first network and the network operator of the second network, the user of a first network may not access and / or use the second network without having to subscribe to the second network.

[0071] [731 Additionally, these roaming agreements and / or contractual centralized virtual network relationships require the sharing of security credentials, such as subscriber identifier information, security certificates, etc., with the other parties, which may introduce increased security risks, such as data breaches, etc., and / or may be administratively expensive, such as requiring that subscriber information and / or security credentials of newly provisioned users and / or devices, e.g., new users, new devices, etc., be shared with all of the partner MNOs and / or VNOs on a constant basis, requiring that a central certificate authority maintain millions of certificates, add new certificates, and / or revoke existing certificates, etc.

[0072] [741 While these types of centralized agreements may be feasible in instances where there are only a handful of MNOs in a desired geographical areas (e.g., five MNOs in a country, ten MNOs in a continent, etc.), they are not feasible and / or are not scalable in cases where there may be dozens to hundreds of private network operators within the desired geographical area and / or when there is expected to be thousands and / or millions of dynamically provisioned devices. Further, centralized agreements are not easy to scale to and / or are inefficient for dynamic addition of new private networks. Consequently, there is a desire to reduce the inefficiencies and costs of arranging and / or creating roaming agreements between network operators and / or enabling enterprises to dynamically provision user devices which may connect to private networks operated by other network operators with which the enterprise is not in a pre-existing contractual relationship.

[0073] [751 At least one example embodiment provides for a system wherein an enterprise may dynamically issue a decentralized identifier to enterprise devices and / or enterprise users, in contrast to conventional systems wherein a device identifier and / or network identifier may be issued by the private network and / or a trusted third party such as an eSIM vendor and / or an identity alliance, thereby allowing the enterprise to more quickly, efficiently, and / or cost effectively deploy and / or manage enterprise devices. The decentralized identifier of at least one example embodiment may allow the enterprise device and / or enterprise user to connect to a new private network which the enterprise and / or the enterprise device and / or enterprise user has not previously contracted with. Additionally, some example embodiments enable the new private network to perform trustless authentication (e.g., authenticate the enterprise device and / or the enterprise user, hereinafter referred to as “enterprise device”) on the enterprise device using the decentralized identifier without the participation of a trusted third party, such as a certificate authority and / or a central virtual network operator, the trustless authentication including the new private network and the enterprise organization entering into a network access agreement via Web3-based technology, such as smart contracts, blockchains, pairwise offline transactions backed by blockchain technologies, or the like. Consequently, the private networks may enter into “on-the-fly” connectivity agreements, e.g., offline signed transactions, smart contracts, Web3 contracts, etc., (referred to herein as “smart contracts”) with the never before contacted enterprise, enterprise user, and / or enterprise user device. According to some example embodiments, the trustless authentication may be performed by the private network operator without live access to a blockchain server and / or blockchain node supporting the smart contracts, and may instead be performed as an offline transaction which may be committed to a live blockchain by any entity holding the offline transactions if there are disputes between the enterprise, a user of the enterprise user device, and / or the private network operator, etc. Further, some example embodiments increase the security of the authentication system of the private network by providing increased protection against replay attacks during the authentication process of the private network by using cryptographic verification using the decentralized identifiers supported by blockchain technologies, which may or may not involve actual interaction with a live blockchain.

[0074] 1761 FIG. 1 illustrates a wireless communication system according to at least one example embodiment. While FIG. 1 illustrates a wireless communication system including a plurality of private wireless networks (PWNs), the example embodiments are not limited thereto, and for example, the system may additionally include one or more private wired networks and / or at least one PWN may be replaced by a private wired network, etc.

[0075] 1771 As shown in FIG. 1, a wireless communication system 1000 includes a private wireless network 100, an access server 140 associated with the private wireless network 100, a user equipment device (e.g., UE device or UE, etc.) 110 associated with an enterprise, an enterprise network node 120 associated with the enterprise, and / or a blockchain network node 130, etc., but the example embodiments are not limited thereto, and the example embodiments may include a greater or lesser number of constituent elements. For example, the wireless communication system 1000 may include an authentication server and / or an authorization server associated with the private wireless network 100, two or more enterprise network nodes, two or more blockchain network nodes, two or more UE devices, additional private wireless networks, additional TRPs (e.g., base stations, radio access network (RAN) nodes, routers, access points, gateways, etc.), but the example embodiments are not limited thereto.

[0076] [781 The UE device 110, the enterprise network node 120, the blockchain network node 130, and / or the access server 140 may be connected over a wireless network, such as a cellular wireless access network (e.g., a 3G wireless access network, a 4G-Long Term Evolution (LTE) network, a 5G-New Radio (e.g., 5G) wireless network, a 6G wireless network, a WiFi network, etc.), but is not limited thereto, and for example, one or more of these components may be connected over a wired network. According to at least one example embodiment, the access server 140 which is associated with the PWN 100 may act as an Authentication, Authorization, and / or Accounting (AAA) server for the PWN 100, but the example embodiments are not limited thereto, and for example, the authentication, authorization, and / or accounting roles may be performed by a plurality of separate servers, may be implemented as separate virtual servers on the same physical server, etc. Further, the access server 140 may be included in and / or connected to the PWN 100, but is not limited thereto, and for example, the access server 140 may be connected to a separate private network and / or a public network but is authorized to perform authentication services, including trustless authentication services, for the PWN 100. According to some example embodiments, the access server 140 may act as a proxy and / or a pass-through for one or more other servers associated with the PWN 100 and / or other networks, such as the enterprise network associated with the enterprise of the enterprise network node 120, the blockchain network associated with the blockchain network node 130, etc.

[0077] [791 According to at least one example embodiment, one or more of the PWN 100, the access server 140, the blockchain network node 130, the enterprise node 120, and / or the UE device 110, etc., may also be connected to a data network (not shown), such as the Internet, a wide area network, etc. [801 According to some example embodiments, the PWN 100 may be a private intranet, a private local area network, a private wide area network, etc., and may require a UE device user to have a subscription and / or other contractual agreement with the network operator of the PWN 100 (and / or a subscription with a contractual partner of the mobile operator of the PWN 100) before the UE device is allowed to connect to and / or access the PWN 100. Further, the enterprise network node 120 may be a server, RAN node, etc., associated with an enterprise organization. The enterprise may be a company, a governmental organization, etc., supporting a plurality of enterprise users and / or enterprise UE devices, such as the UE device 110. According to some example embodiments, the enterprise may be a network operator, a private network operator, and / or a virtual private network operator, etc., but the example embodiments are not limited thereto. The enterprise network node 120 may manage enterprise users and / or enterprise UE devices, such as UE device 110, including provisioning and / or onboarding new users and / or UE devices, removing users and / or UE devices from the enterprise, etc. The provisioning of new enterprise UE devices will be discussed in greater detail in connection with FIGS. 4A to 4B.

[0078] [811 Additionally, according to some example embodiments, the blockchain network node 130 may generate and / or mint tokens (e.g., nonfungible tokens (NFTs), fungible tokens, cryptocurrency coins, etc.), generate token accounts (e.g., wallets, etc.) associated with an enterprise UE device and / or an enterprise user, validate smart contracts, etc., but is not limited thereto. The blockchain network node 130 may be network accessible to the access server 140 and the enterprise network node 120, and optionally, the UE device 110. According to some example embodiments, at least one different blockchain network node (not shown), different from the blockchain network node 130 which generated the mint token, may receive a copy of the blockchain record from the blockchain network node 130 in accordance with the blockchain service protocols, and the blockchain record may be network accessible to the access server 140, the enterprise network node 120, and / or the UE device 110, etc. In other words, the access server 140, the enterprise network node 120, and / or the UE device 110 may communicate with any blockchain network node associated with the blockchain service in order to access the relevant blockchain record (and / or token, token account, smart contract, etc.) without necessarily communicating with the blockchain network node 130. [821 The LIE device 110 may be any one of, but not limited to, a mobile device, a smartphone, a tablet, a laptop computer, a wearable device, an Internet of Things (loT) device, a sensor (e.g., thermometers, humidity sensors, pressure sensors, motion sensors, accelerometers, etc.), actuators, robotic devices, robotics, drones, connected medical devices, eHealth devices, smart city related devices, a security camera, a ground vehicle, an aerial vehicle, autonomous devices (e.g., autonomous cars, etc.), a desktop computer and / or any other type of stationary or portable device capable of operating according to, for example, the 5G NR communication standard, and / or other wireless communication standard(s). According to some example embodiments, the UE device 110 may connect to one or more computer networks using a wired connection.

[0079] [831 The PWN 100 may further include at least one RAN node (e.g., a TRP, a base station, a wireless access point, etc.). According to some example embodiments, the access server 140 may operate as a PWN RAN node, but the example embodiments are not limited thereto, and for example, the PWN RAN node may be separate from the access server 140. The PWN RAN node may operate according to at least one underlying cellular and / or wireless radio access technology (RAT), such as 5G NR, LTE, Wi-Fi, etc. For example, the PWN RAN node may be a 5G gNB node, a LTE eNB node, or a LTE ng-eNB node, etc., but the example embodiments are not limited thereto. The PWN RAN node may perform an authorization operation to determine the types of activities, resources, and / or services the one or more authenticated and / or subscribed UE devices are authorized, and may provide access to the UE devices the authorized activities, resources, and / or services over the encrypted and / or otherwise secure wireless network associated with the PWN 100 within one or more cells (e.g., cell service areas, broadcast areas, serving areas, coverage areas, etc.) surrounding the respective physical location of the PWN RAN node. Further, the PWN RAN node may provide accounting services to the UE device and / or the enterprise associated with the UE device in relation to the activities of the UE device on the PWN 100.

[0080] [841 According to some example embodiments, the PWN RAN node may provide an unencrypted and / or unsecured wireless channel, e.g., a guest wireless channel, etc., to allow new UE devices unaffiliated with the PWN 100 (e.g., UE devices which have never previously connected to the PWN 100, UE devices which have not subscribed to the PWN 100, UE devices provisioned by an enterprise which is not in a contractual relationship with the PWN 100, etc.), such as the UE device 1 10, to perform a trustless authentication procedure for gaining access to the PWN 100, but the example embodiments are not limited thereto. The trustless authentication procedure will be discussed in greater detail in connection with FIGS. 5A to 5B.

[0081] [851 While certain components of a wireless communication network 1000 are shown in FIG. 1, the example embodiments are not limited thereto, and the wireless communication network 1000 may include other components which are desired, necessary, and / or beneficial for operation of the underlying networks within the wireless communication system, such as access points, switches, routers, nodes, servers, gateways, etc.

[0082] [861 FIG. 2 illustrates a block diagram of an example network node according to at least one example embodiment. The network node of FIG. 2 may correspond to the enterprise network node 120, the blockchain network node 130, the access server 140, etc., but the example embodiments are not limited thereto.

[0083] [871 Referring to FIG. 2, a network node 2000 may include processing circuitry 2100, at least one communication bus 2200, a memory 2300, at least one core network interface 2400, and / or at least one wireless antenna array 2500, etc., but the example embodiments are not limited thereto. For example, the core network interface 2400 and the wireless antenna array 2500 may be combined into a single network interface, etc., or the network node 2000 may include a plurality of wireless antenna arrays, a plurality of core network interfaces, etc., and / or any combinations thereof. The memory 2300 may include various special purpose program code including computer executable instructions which may cause the network node 2000 to perform the one or more of the methods discussed in connection with FIGS. 4A to 5B.

[0084] [881 In at least one example embodiment, the processing circuitry 2100 may include at least one processor (and / or processor cores, distributed processors, networked processors, etc.), which may be configured to control one or more elements of the network node 2000, and thereby cause the network node 2000 to perform various operations. The processing circuitry 2100 is configured to execute processes by retrieving program code (e.g., computer readable instructions) and data from the memory 2300 to process them, thereby executing special purpose control and functions of the entire network node 2000. Once the special purpose program instructions are loaded into the processing circuitry 2100, the processing circuitry 2100 executes the special purpose program instructions, thereby transforming the processing circuitry 2100 into a special purpose processor / special purpose processing circuitry.

[0085] [891 In at least one example embodiment, the memory 2300 may be a non-transitory computer-readable storage medium and may include a random access memory (RAM), a read only memory (ROM), and / or a permanent mass storage device such as a disk drive, or a solid state drive. Stored in the memory 2300 is program code (i.e., computer readable instructions) related to operating the network node 2000, such as the methods discussed in connection with FIGS. 4A to 5B, the at least one core network interface 2400, and / or at least one wireless antenna array 2500, etc. Such software elements may be loaded from a non-transitory computer-readable storage medium independent of the memory 2300, using a drive mechanism (not shown) connected to the network node 2000, or via the at least one core network interface 2400, and / or at least one wireless antenna array 2500, etc.

[0086] [901 In at least one example embodiment, the communication bus 2200 may enable communication and data transmission to be performed between elements of the network node 2000. The bus 2200 may be implemented using a high-speed serial bus, a parallel bus, and / or any other appropriate communication technology. According to at least one example embodiment, the network node 2000 may include a plurality of communication buses (not shown), such as an address bus, a data bus, etc.

[0087] [911 The network node 2000 may operate as, for example, a 4G RAN node, a 5G RAN node, etc., and may be configured to schedule time domain resource allocations (TDRAs), e.g., orthogonal frequency division multiplexing (OFDM) symbols, physical resource blocks (PRBs), resource elements, etc., for UE devices connected to the network node 2000, but the example embodiments are not limited thereto.

[0088] [921 The network node 2000 may also include at least one core network interface 2400, and / or at least one wireless antenna array 2500, etc. The at least one wireless antenna array 2500 may include an associated array of radio units (not shown) and may be used to transmit the wireless signals in accordance with a radio access technology, such as 4G LTE wireless signals, 5G NR wireless signals, WiFi, LoRa, and / or other PHY layer transmission technologies, to at least one UE device, such as UE 110, etc. According to some example embodiments, the wireless antenna array 2500 may be a single antenna, or may be a plurality of antennas, etc. For example, the wireless antenna array 2500 may be configured as a grid of beams (GoB) which transmits a plurality of beams in different directions, angles, frequencies, and / or with different delays, etc., but the example embodiments are not limited thereto.

[0089] [931 The network node 2000 may communicate with at least one core network (e.g., the private network 100, an enterprise network (not shown), other private networks (not shown), a backend network, backhaul network, backbone network, a Data Network, etc.) of the wireless communication network 1000 via a core network interface 2400. The core network interface 2400 may be a wired and / or wireless network interface and may enable the network node 2000 to communicate and / or transmit data to and from to network devices on the core network (e.g., the private network 100, etc.), such as a core network gateway (not shown), a Data Network (e.g., the Internet, intranets, wide area networks, telephone networks, VoIP networks, etc.), but is not limited thereto.

[0090] [941 While FIG. 2 depicts an example embodiment of a network node 2000, the network node is not limited thereto, and may include additional and / or alternative architectures that may be suitable for the purposes demonstrated.

[0091] [951 FIG. 3 illustrates a block diagram of an example UE device according to at least one example embodiment. The example UE device 3000 of FIG. 3 may correspond to the UE device 110 of FIG. 1 , but the example embodiments are not limited thereto.

[0092] [961 Referring to FIG. 3, a UE 3000 may include processing circuitry 3100, at least one communication bus 3200, a memory 3300, a plurality of wireless antennas and / or wireless antenna panels 3400, a display panel 3500 (e.g., a monitor, a touchscreen, etc.), and / or at least one input / output (I / O) device 3600 (e.g., a keyboard, a touchscreen, a mouse, a microphone, a camera, a speaker, etc.), but the example embodiments are not limited thereto. According to some example embodiments, the UE 3000 may include a greater or lesser number of constituent components, and for example, the UE 3000 may also include at least one sensor 3700, such as one or more proximity sensors (e.g., an infra-red proximity sensor, a capacitive proximity sensor, etc.), one or more location sensors (e.g., GPS, GLONASS, Beidou, Galileo, etc.), other sensors (e.g., thermometers, humidity sensors, pressure sensors, motion sensors, accelerometers, etc.), a battery, actuators, a single wireless antenna and / or a single wireless antenna panel, etc. Additionally, the display panel 3500, and / or I / O device 3600, etc., of UE 3000 may be optional.

[0093] [971 In at least one example embodiment, the processing circuitry 3100 may include at least one processor (and / or processor cores, distributed processors, networked processors, etc.), which may be configured to control one or more elements of the LIE 3000, and thereby cause the UE 3000 to perform various operations. The processing circuitry 3100 is configured to execute processes by retrieving program code (e.g., computer readable instructions) and data from the memory 3300 to process them, thereby executing special purpose control and functions of the entire UE 3000. Once the special purpose program instructions are loaded into the processing circuitry 3100, the processing circuitry 3100 executes the special purpose program instructions, thereby transforming the processing circuitry 3100 into a special purpose processor / special purpose processing circuitry.

[0094] 1981 In at least one example embodiment, the memory 3300 may be a non-transitory computer-readable storage medium and may include a random access memory (RAM), a read only memory (ROM), and / or a permanent mass storage device such as a disk drive, or a solid state drive. Stored in the memory 3300 is program code (i.e., computer readable instructions) related to operating the UE 3000, such as the methods discussed in connection with FIGS. 4A to 5B, etc. Such software elements may be loaded from a non- transitory computer-readable storage medium independent of the memory 3300, using a drive mechanism (not shown) connected to the UE 3000, or via the wireless antenna 3400, etc.

[0095] 1991 In at least one example embodiment, the at least one communication bus 3200 may enable communication and data transmission / reception to be performed between elements of the UE 3000. The bus 3200 may be implemented using a high-speed serial bus, a parallel bus, and / or any other appropriate communication technology. According to at least one example embodiment, the UE 3000 may include a plurality of communication buses (not shown), such as an address bus, a data bus, etc.

[0096] £100] The UE 3000 may also include at least one wireless antenna panel 3400, but is not limited thereto, and for example, may also include a wired network interface (e.g., a wired Ethernet interface, a copper-based network interface, a fiberoptic -based network interface, etc.) for connecting to a wired network. The at least one wireless antenna panel 3400 may include at least one associated radio unit (not shown) and may be used to transmit wireless signals in accordance with at least one desired radio access technology, such as 4G LTE, 5G NR, Wi-Fi, etc.

[0097]

[0101] While FIG. 3 depicts an example embodiment of a UE 3000, the UE device is not limited thereto, and may include additional and / or alternative architectures that may be suitable for the purposes demonstrated.

[0102] FIG. 4A illustrates an example transmission flow diagram for provisioning an enterprise user device according to some example embodiments. FIG. 4B illustrates an example decentralized identifier according to at least one example embodiment. While FIG. 4A illustrates a single UE device 110 to be provisioned by and / or associated with an enterprise, a single enterprise network node 120 associated with the enterprise, and a single blockchain network node 130, the example embodiments are not limited thereto, and for example, there may be a plurality of UE devices, a plurality of enterprise network nodes associated with the same enterprise, a plurality of enterprise network nodes each associated with different enterprises, a plurality of blockchain network nodes, etc.

[0098] 11031 Referring now to FIG. 4 A, in operation S4010, a new enterprise UE device 110 (e.g., a to-be-provisioned UE device, etc.) may generate and / or obtain a private key and a public key corresponding to the private key (e.g., a public / private key pair) based on a desired security and / or encryption protocol, but the example embodiments are not limited thereto, and for example the UE device 110 may receive the private key and public key from an external source associated with the PWN 100, such as the enterprise network node 120, etc. In operation S4020, the UE device 110 may transmit the public key to the enterprise network node 120. The communication between the UE device 110 and the enterprise network node 120 may be performed over a trusted network, such as a private network (e.g., intranet, etc.) associated with the enterprise, but the example embodiment is not limited thereto, and for example, the communication between the UE device 110 and the enterprise network node 120 may be encrypted and transmitted over a public network, such as the Internet, etc.

[0099]

[0104] In operation S4030, the enterprise network node 120 may transmit a message to the blockchain network node 130, the message requesting the generating and / or minting of a connectivity token on a blockchain record associated with and / or managed by the blockchain network. According to some example embodiments, the mint request may include metadata to be included in the minted connectivity token, such as terms and conditions (T&C) information associated with the enterprise and / or the UE device 110, an enterprise smart contract to be stored on the blockchain record, an address of an enterprise smart contract which is already stored on the blockchain record, an IP address and / or URL associated with an enterprise smart contract which is not stored on the blockchain record (e.g., off-chain, an oracle, etc.), etc., but the example embodiments are not limited thereto. The connectivity token may be used by the UE device 110 for trustless authentication with new private networks (e.g., private networks which were previously unknown and / or unvisited by the UE device 110, private networks which do not have a contractual relationship with the enterprise, etc.). According to some example embodiments, the connectivity token may be a nonfungible token (NFT), a fungible token, a cryptocurrency coin, etc., but the example embodiments are not limited thereto. In operation S4040, the blockchain network node 130 may mint and / or generate a connectivity token 430 based on the metadata included in the request, such as the T&C information 432, the on-block enterprise smart contract address 433, the off-block enterprise smart contract address 434, etc., and may transmit the newly minted connectivity token 430 (and / or a connectivity token identifier and / or pointer to the connectivity token) to the enterprise network node 120. This connectivity token may be implemented using non-fungible-token (NFT) or fungible- token semantics on the blockchain platform. Additionally, the blockchain network node 130 may further include mint authority information 431 to the connectivity token as well, the mint authority information indicating the blockchain network and / or other decentralized ledger system which minted the connectivity token, network address information to the blockchain record and / or the blockchain network node 130, etc., to allow a PWN access server, such as the PWN access server 140, to access and / or verify the contents of the connectivity token 430. According to some example embodiments, the blockchain network node 130 may be a network node of a blockchain network platform and / or other decentralized public ledger platform which may support smart contracts, such as Solana, Ethereum, HyperLedger, etc., but is not limited thereto.

[0100]

[0105] In operation S4050, the enterprise network node 120 may transmit a message to the blockchain network node 130, the message including a request to generate and / or create an account associated with the minted token (e.g., a wallet, a token account, etc.). Optionally, the enterprise network node 120 may include the public key of the UE device 110 and / or financial information (e.g., an electronic fund transfer, cryptocurrency account information, etc.) associated with the enterprise and / or the UE device 110, such that the token account is funded, to the token account creation request, but the example embodiments are not limited thereto. In operation S4060, the blockchain network node 130 may generate the token account 420 (e.g., wallet, etc.) and add the token account 420 to the blockchain record based on the request and transmit the token account information (e.g., token account identifier, etc.) to the enterprise network node 120. As shown in FIG. 4B, the token account 420 may include owner information associated with the token account 420, e.g. , information indicating that the UE device 110 is the owner of the token account 420, but the example embodiments are not limited thereto. For example, the owner of the token account 420 may be any identity and / or entity set by the enterprise. According to at least one example embodiment, the owner information may be set to and / or include the public key of the UE device 110, but is not limited thereto.

[0101]

[0106] In operation S4070, the enterprise network node 120 may generate a decentralized identifier based on the public key of the UE device 110, the token account associated with the public key of the UE device 110, and / or the connectivity token issued by the enterprise server as shown in FIG. 4B, but is not limited thereto, and in operation S4080, the enterprise network node 120 may transmit the decentralized identifier to the UE device 110. The decentralized identifier may be presented by the UE device 110 to a new PWN and / or the access server of a new PWN, such as the PWN 100 and / or the PWN access server 140, to gain access to the new PWN via trustless authentication. This decentralized identifier including the device public key, the device token account identifier, and the connectivity token, may also be referred to as a device triplet and / or or a web3 triplet.

[0102]

[0107] FIG. 5 A illustrates an example transmission flow diagram for performing trustless authentication between an enterprise user device and a new private network according to some example embodiments. FIG. 5B illustrates an example private network verification check according to some example embodiments.

[0103]

[0108] As shown in FIG. 5A, in operation S5010, when the UE device 110 enters the cell coverage area of a new private network (e.g., a private network the UE device 110 has not previously accessed and / or a private network the enterprise associated with the UE device 110 has not entered into a contractual relationship with, such as a roaming agreement, etc.), such as the PWN 100, the UE device 110 may request access to the PWN 100, the access request including its decentralized identifier (e.g., device triplet, etc.) to an access server associated with the PWN 100, such as the access server 140. In at least one example embodiment, the access server 140 may provide at least one public wireless channel and / or media to enable the new, roaming, and / or unauthenticated UE devices to perform trustless authentication on the PWN 100. For example, the access server 140 may implement the RADIUS protocol and support the use of 802. lx to exchange Extensible Authentication Protocol (EAP) encapsulated messages for authentication of unauthenticated WiFi UE devices and / or implement the Diameter protocol for authentication of cellular UE devices, etc. In operation S5020, in response to the access request, the PWN network node 140 may transmit a challenge message to the UE device 110. The challenge message may include target data, such as a “number used only once” (e.g., a cryptographic nonce) and / or a unique message generated by the PWN network node 140, etc., for use in verifying the validity of the decentralized identifier received from the UE device 110. In operation S5030, the UE device 110 may sign the target data using its private key and transmit a response message including the signed target data to the PWN network node 140. In operation S5040, the PWN network node 140 may verify the identity of the UE device 110 based on the signed target data and the previously received decentralized identifier of the UE device 110. More specifically, the PWN network node 140 may verify the signature on the target data using the public key of the UE device 110 received in the decentralized identifier associated with the UE device 110. Accordingly, the PWN access server 140 may reduce and / or prevent replay attacks against the PWN 100 by bad and / or malicious actors reusing the copied decentralized identifiers of other UE devices.

[0104] [1091 In operation S5O5O, if the PWN access server 140 determines that the signed target data was signed using a private key which does not correspond to the public key, the PWN access server 140 may reject the access request of the UE device 110. In operation S5060, if the PWN access server 140 determines that the signed target data was signed using a private key which corresponds to the public key, the PWN access server 140 may query the blockchain network node 130 and retrieve the information (e.g., metadata, etc.) stored in the token account 420 and / or the connectivity token 430 on the blockchain record associated with the decentralized identifier. In operation S5070, the blockchain network node 130 transmits the information and / or metadata associated with the decentralized identifier associated with the UE device 110. In operation S5080, the PWN access server 140 may determine whether to grant access to the PWN 100 to the UE device 110 based on the information and / or metadata stored on the blockchain record associated with the decentralized identifier. According to some example embodiments, the PWN access server 140 may cache and / or locally store one or more fields of the information and / or metadata stored on the blockchain record so that queries to the live blockchain record and / or queries to the blockchain network node 130 are not required. In other words, the PWN access server 140 may use the cached and / or locally stored copies of the decentralized identifier to perform offline verification of the access request of the UE device 110 without network access to the blockchain record and / or the blockchain network node 130, etc.

[0105]

[0110] More specifically, as shown in FIG. 5B, in operation S5O81, the PWN network node 140 may determine whether the token account 420 (and / or token account identifier) included in the decentralized identifier received from the UE device 110 is owned by the UE device 1 10. According to at least one example embodiment, the PWN network node 140 may determine whether the UE device 110 owns the token account 420 included in the decentralized identifier by comparing the public key 410 included in the received decentralized identifier associated with the UE device 110 with the owner information included in the token account 421 stored on the block. As an alternative to, or in addition to verifying the owner metadata on the token account, the PWN network node 140 may contact an enterprise end-point (e.g., a smart contract and / or an enterprise API included in the connectivity token, etc.) to verify that the device public key is indeed an authorized owner of the token account. In operation S5082, the PWN network node 140 may determine whether the connectivity token 430 was minted by an enterprise that the PWN 100 and / or the PWN network node 140 has previously contracted with via enterprise identifying information included in the connectivity token 430. In the event that the PWN 100 and / or the PWN network node 140 is already in a contractual relationship with the enterprise associated with the UE device 110, the PWN network node 140 may go to operation S5100.

[0106]

[0111] In the event that the PWN 100 and / or the PWN network node 140 is not in a valid contractual relationship with the enterprise associated with the UE device 110, the PWN network node 140 may determine whether the connectivity token 430 was minted by an enterprise holding a valid smart contract (e.g., Web3 contract, etc.) and / or determine whether the enterprise is capable of entering into a valid smart contract based on the PWN 100’s internal policies and the mint authority information 431, the on-block enterprise smart contract address 433 and / or the off-block enterprise oracle IP address and / or URL, but is not limited thereto. For example, the PWN 100 may have internal policies regarding “best-effort” service and / or value-added-services offered to subscribers and may determine whether the PWN 100’s internal policies match a service level desired and / or required by the enterprise as specified in the mint authority information 431, the smart contract, etc. Additionally, according to some example embodiments, the terms of the smart contract may include that the PWN network node 140 act as an intermediary, proxy, and / or pass-through between the UE device 110 and the enterprise network node 120 as a security measure to determine whether the access request is being initiated by a valid enterprise UE device and not initiated by a malicious UE device and / or a rogue PWN operator, etc. This may, for example, be done by having the enterprise network node 120 issue a cryptographic nonce which is then sent to the PWN network node 140 to be forwarded to the UE device 110 for signing using the private key of the UE device 110, but is not limited thereto. Once the UE device 110 signs the nonce and sends it back to the PWN network node 140, the PWN network node 140 may forward the signed nonce to the enterprise network node 120, which may then verify the signature on the signed nonce to see if it is a valid signature by a valid enterprise UE device, and then let the PWN 100 via the PWN network node 140 know of the result of the verification process. Following this, the enterprise and / or the enterprise network node 120 may transfer financial funds, e.g., electronic funds, cryptocurrency, etc., to a financial account associated with the PWN 100. The PWN 100 may then issue a Web3 contract (e.g., another NFT containing the terms and conditions of the connectivity) to the enterprise, the enterprise network node 120, and / or the UE device 110, etc.

[0107] [1121 Additionally, in operation S5O83, the PWN access server 140 may determine whether the T&C information 432 included in the connectivity token 430 is acceptable to the PWN 100 based on the PWN 100’s internal policies, etc. According to some example embodiments, in response to the smart contract being successfully verified and the T&C information being successfully verified, the PWN access server 140 may automatically receive a desired and / or predetermined monetary amount (e.g., in electronic funds, cryptocurrency, etc.) for issuing a Web3 contract that allows the UE device 110 to access the PWN 100 and / or the PWN network node 140 using the financial information and / or cryptocurrency stored in the token account associated with the UE device 110.

[0108] [1131 Returning to FIG. 5A, in operation S5090, if any one of the verification checks S5081 to S5083 fails, the PWN access server 140 may transmit a rejection message to the UE device 110 and deny access to the PWN 100 to the UE device 110. In operation S5080, in response to decentralized identifier of the UE device 110 being successfully verified in operations S5081 to S5083, the PWN access server 140 may grant access to the PWN 100 to the UE device 110. More specifically, the PWN access server 140 may transmit an encrypted data session key to the UE device 110. In operation S5110, the UE device 1 10 may establish an encrypted data session with the PWN 100 using the session key.

[0109]

[0114] This written description uses examples of the subject matter disclosed to enable any person skilled in the art to practice the same, including making and using any devices or systems and performing any incorporated methods. The patentable scope of the subject matter is defined by the claims, and may include other examples that occur to those skilled in the art. Such other examples are intended to be within the scope of the claims.

Claims

WHAT IS CLAIMED IS:

1. A network device, comprising: a memory storing computer readable instructions; and processing circuitry configured to execute the computer readable instructions to cause the network device to, provide a public key associated with the network device to an enterprise server, the enterprise server and the network device being associated with an enterprise, obtain a decentralized identifier associated with the network device from the enterprise server in response to the provided public key, provide the decentralized identifier to an access server associated with a private network, the decentralized identifier enabling the access server to perform trustless authentication of the network device, and connect to the private network based on results of the trustless authentication.

2. The network device of claim 1 , wherein the decentralized identifier includes: the public key associated with the network device, a device token account associated with the public key, and a connectivity token issued by the enterprise server.

3. The network device of any one of claims 1 to 2, wherein the device token account and the connectivity token are included in a blockchain record associated with a blockchain server; and the blockchain record is network accessible to the enterprise server and the access server.

4. The network device of any one of claims 1 to 3, wherein the device token account includes owner information associated with the network device and electronic financial information associated with the network device.

5. The network device of any one of claims 1 to 4, wherein the connectivity token includes a link to a smart contract program associated with the enterprise.

6. The network device of any one of claims 1 to 5, wherein the network device is further caused to: receive a challenge message from the access server, the challenge message including target data; sign the target data with a private key associated with the network device, the private key corresponding to the public key; and provide a response message to the access server, the response message including the signed target data, the response message enabling the access server to perform the trustless authentication of the network device by verifying the signature on the signed target data using the public key associated with the network device.

7. The network device of any one of claims 1 to 6, wherein the network device is further caused to: obtain an encrypted data session key for the private network from the access server based on the signed target data and the decentralized identifier; and connect to the private network by establishing an encrypted data session with the private network using the data session key.

8. A network server associated with an enterprise, comprising: a memory storing computer readable instructions; and processing circuitry configured to execute the computer readable instructions to cause the network server to, obtain a public key from a network device, the public key associated with the network device, the network device associated with the enterprise, generate a decentralized identifier associated with the network device in response to the obtained public key, the decentralized identifier including the public key, a device token account associated with the public key, a connectivity token issued by the network server, and transmit the decentralized identifier to the network device, the transmission enabling the network device to start connecting to a private network via trustless authentication using the decentralized identifier.

9. The network server of claim 8, wherein the network server is further caused to: transmit a mint token request to a blockchain server, the mint token request including the public key, the mint token request causing the blockchain server to generate the connectivity token associated with the network server on a blockchain record associated with the blockchain server, the blockchain record being network accessible to the network server and an access server associated with the private network; and receive the connectivity token from the blockchain server.

10. The network server of any one of claims 8 to 9, wherein the connectivity token includes at least one of: mint authority information associated with the network server, terms and conditions information set by the network server, a link to a smart contract associated with the network server stored on the blockchain record, a link to the smart contract associated with the network server not stored on the blockchain record, or any combinations thereof.

11. The network server of any one of claims 8 to 10, wherein the network server is further caused to: transmit a token account generation request to the blockchain server, the token account generation request including the public key, the token account generation request causing the blockchain server to generate the device token account associated with the public key on the blockchain record; and receive the device token account from the blockchain server.

12. The network server of any one of claims 8 to 11, wherein the network server is further caused to: add electronic financial information associated with the network device to the device token account.

13. A network server, comprising: a memory storing computer readable instructions; and processing circuitry configured to execute the computer readable instructions to cause the network server to,obtain a decentralized identifier from a network device, the decentralized identifier including a public key associated with the network device, a device token account associated with the public key, and a connectivity token issued by an enterprise server, the enterprise server and the network device associated with an enterprise, perform trustless authentication of the network device based on the decentralized identifier, and grant access to a private network associated with the network server to the network device based on results of the trustless authentication of the network device.

14. The network server of claim 13, wherein the network server is further caused to perform the trustless authentication by: providing a challenge message to the network device, the challenge message including target data to be signed by the network device; obtaining a response message from the network device, the response message including signed target data signed by the network device using a private key; verifying the signature on the signed target data using the public key associated with the network device; and denying access to the private network to the network device in response to failure of signature verification of the signed target data using the public key.

15. The network server of any one of claims 13 to 14, wherein the device token account and the connectivity token are included in a blockchain record associated with a blockchain server; and the blockchain record is network accessible to the enterprise server and the network server.

16. The network server of any one of claims 13 to 15, wherein the network server is further caused to perform the trustless authentication by: accessing a smart contract associated with the enterprise server via a link included in the connectivity token; and validating the smart contract based on contract criteria associated with the private network.

17. The network server of any one of claims 13 to 16, wherein the smart contract is stored on the blockchain record or the smart contract is stored at a network location not on the blockchain record.

18. The network server of any one of claims 13 to 17, wherein the network server is further caused to perform the trustless authentication by: obtaining ownership information included in the device token account from the blockchain record; and determining whether the device token account is associated with the network device based on the ownership information and the public key.

19. The network server of any one of claims 13 to 18, wherein the network server is further caused to perform the trustless authentication by: obtaining terms and condition information included in the connectivity token; and validating the terms and condition information based on terms and condition criteria associated with the private network.

20. The network server of any one of claims 13 to 19, wherein the network server is further caused to grant access to the private network to the network device by: providing an encrypted data session key for the private network to the network device, the encrypted data session key enabling the network device to establish an encrypted data session with the private network.

Images