Methods and systems for enrolling service providers and onboarding virtualized network services.

Abstract

A method, system, apparatus, and computer-readable medium for trading telecommunication-related services on a centralized marketplace network includes receiving a user request from a first user to access the centralized marketplace, authenticating the first user based on the received user request, obtaining product information for the authenticated first user's product, the product being a virtualized network service for a telecommunications network, based on a predetermined onboarding policy, obtaining the product for performing one or more onboarding tests of the product in a test environment of the centralized marketplace based on the predetermined onboarding policy, obtaining status information of the one or more onboarding tests, and publishing the product in the centralized marketplace for purchase based on results of the one or more onboarding tests.

Description

Technical Field

[0001] Methods and systems consistent with exemplary embodiments of the present disclosure relate to enrolling service providers in a centralized online marketplace platform and onboarding virtual network services.

Background Art

[0002] The conventional market for network-related services is highly fragmented. Specifically, the telecommunications industry has one of the most complex and time-consuming processes for network operators to find end-to-end solutions, service providers, vendors, or implementers to assist in the resolution and implementation of network operation business plans. Thus, it can be a difficult task for a network operator to guide when providing the necessary information to multiple service providers when multiple service providers are involved. For this purpose, before a vendor (e.g., a service provider) can provide network services to a network operator, the service provider needs to enroll as a registered dealer in the network operator's dealer network. For this purpose, a vendor (e.g., a service provider) may need to provide a network operator with high-level information regarding its business and the services offered. However, in a highly fragmented market where different network operators require different levels of information and formats to include a vendor (e.g., a service provider) in their dealer networks (e.g., marketplaces), it is a difficult challenge for both network operators and vendors (e.g., service providers) to meet the information requirements of their business partners.

[0003] When a vendor (e.g., a service provider) wishes to join a network operator's dealer network, it can be difficult for the vendor to immediately access the level of information necessary for the seamless onboarding of the offered services. Coordination is likely to be required, resulting in administrative communication between the vendor and the network operator. In particular, the task of integrating network services into the network operator's existing telecommunications infrastructure is complex and time-consuming for both parties (for example, scheduling an on-site visit to the telecommunications infrastructure to integrate network services requires a high level of coordination between the network operator and the vendor).

[0004] Furthermore, the considerable effort required to deploy network services onto existing telecommunications infrastructure is particularly inefficient if, for example, the vendor (e.g., service provider) discovers only after the network services have been integrated into the existing infrastructure that the offered network services are incompatible or do not function as expected. Such a result leaves the vendor (e.g., service provider) with no choice but to stop the integration of network services and find a suitable solution to the problem. To this end, the vendor (e.g., service provider) requires the cooperation of the network operator to schedule another on-site visit to install new infrastructure or to upgrade the existing telecommunications infrastructure to be compatible with the offered network services. In some cases, the vendor (e.g., service provider) may have no choice but to resort to reconfiguring the network services to be compatible with another vendor's (e.g., service provider's) existing telecommunications infrastructure as a last resort. In other cases, the network operator may find themselves in a dilemma and be forced to choose another vendor (e.g., service provider) for the deployment of network services.

[0005] In either case, the deployment of network services could be further delayed, leading to wasted human resources and frustration, making the issue unsatisfactory for both business partners.

[0006] As a result, network operators generally have no choice but to switch vendors (e.g., service providers) or update their network services if it is urgently necessary. Therefore, even if updated network services or services with better performance are available from other vendors (e.g., service providers), there is a long transition period before network operators decide to deploy these better services.

[0007] Apart from the deployment issues mentioned above, the actual performance of the offered network services can vary depending on the environment and infrastructure. Therefore, it is difficult for network operators to accurately assess the actual performance of the network services until they are actually deployed on the existing telecommunications infrastructure. [Overview of the project]

[0008] According to exemplary embodiments, a method and system are provided for admitting service providers to a centralized online marketplace platform, trading platform, and network, and for onboarding virtualized network services. Centralized admission and onboarding allows service providers to admit, onboard, and test network services before publishing them on the centralized online marketplace. In particular, the method and system implements a standardized, guided admission and onboarding process that provides a common and easily reviewable standard / format for network providers. Admitted service providers can upload network services in a guided manner to an onboarding portal, enabling network operators to test the network services. Service providers receive approval for the network services they offer before release to the online marketplace platform. This onboarding process provides service providers with security that only approved network services are sold to customers (e.g., network operators). Both users (e.g., service providers) and customers (e.g., network operators) can monitor the status of the onboarding process. Users (e.g., service providers) can customize (i.e., adjust) network services during the onboarding process without visiting existing network infrastructure on-site to obtain approval for their release to the marketplace. Network operators can customize the onboarding process (e.g., the network service test environment) in a standardized and guided manner to meet requirements for testing network services with less effort.In particular, network operators can control the onboarding process by, for example, providing service providers with different levels of permission for onboarding testing without the risk of human error or integration failures that could affect the network operator's existing telecommunications infrastructure.

[0009] By simplifying and automating the network service enrollment and onboarding process, both marketplace platform users (e.g., service providers) and customers (e.g., network operators) can save time and resources compared to manual on-site network service onboarding. Furthermore, the centralized enrollment and onboarding process minimizes human error and eliminates compatibility issues. Additionally, it reduces business risk for users (e.g., service providers) by providing a low-risk testing environment with minimal impact on network operators. As a result, the centralized enrollment and onboarding process enables a simple, flexible, cost-effective, efficient, and rapidly implementable solution for network service selection.

[0010] According to an exemplary embodiment, a system for admitting service providers to a centralized marketplace and onboarding virtualized network services comprises memory for storing instructions and at least one processor, the at least one processor being configured to receive a user request from a first user to access the centralized marketplace, authenticate the first user based on the received user request, retrieve product information of the authenticated first user's product, which is a virtualized network service for telecommunications networks, based on a predetermined onboarding policy, retrieve the product to run one or more onboarding tests of the product in a test environment of the centralized marketplace based on the predetermined onboarding policy, retrieve status information of the one or more onboarding tests, and execute an instruction to publish the product to the centralized marketplace for purchase based on the results of the one or more onboarding tests.

[0011] The system may be further configured such that, during authentication, at least one processor determines from among a plurality of predetermined roles, including the roles of a vendor and a customer, that the role of the first user registered in the centralized marketplace is the role of the vendor, and executes the instructions to provide access to the centralized marketplace based on the determination that the first user's role is the role of the vendor.

[0012] The system is further configured such that, when acquiring the product information, at least one processor receives an onboarding request from the first user, outputs a product information graphical user interface, and executes the instruction to request the first user to provide product information for the product.

[0013] The system is further configured such that, when acquiring the product information, at least one processor outputs an upload graphical user interface to request the first user to upload the product and to provide additional product information; acquires the additional product information and the product uploaded by the first user; and executes instructions to provide the additional product information of the product for verification by at least one second user.

[0014] The system is further configured to output an onboarding test graphical user interface to at least one second user, which includes information about the one or more onboarding tests of the product in the test environment, when acquiring the status information, and to execute the instructions to acquire the status information of the one or more onboarding tests from the at least one second user.

[0015] The system is further configured such that the at least one processor executes the instructions to provide the first user with access to update the product in response to the status information, based on an access request received from the first user or the at least one second user.

[0016] The system is further configured to receive a query input from the at least one second user requesting information from the second user relating to one or more onboarding tests when evaluating the product, and to execute the instruction to output the query input to the first user.

[0017] The system is further configured such that at least one processor executes instructions to output an onboarding test graphical user interface to the first user, which includes the status information of the one or more onboarding tests.

[0018] In the system, the status information includes at least one of the onboarding test completion status, onboarding test events and / or results, and the performance status of the product during one or more onboarding tests.

[0019] According to an exemplary embodiment, a method for admitting a service provider to a centralized marketplace and onboarding a virtualized network service may include: receiving a user request from a first user to access the centralized marketplace; authenticating the first user based on the received user request; obtaining product information of the authenticated first user's product, which is a virtualized network service for telecommunications networks, based on a predetermined onboarding policy; obtaining the product to run one or more onboarding tests of the product in a test environment of the centralized marketplace, based on the predetermined onboarding policy; obtaining status information of the one or more onboarding tests; and making the product available for purchase on the centralized marketplace based on the results of the one or more onboarding tests.

[0020] The authentication described above may include determining that the role of the first user registered in the centralized marketplace is the role of the vendor, from among a plurality of predetermined roles including the role of the vendor and the role of the customer, and providing access to the centralized marketplace based on the determination that the first user's role is the role of the vendor.

[0021] Acquiring the aforementioned product information may include receiving an onboarding request from the first user and outputting a product information graphical user interface to request the first user to provide product information for the said product.

[0022] Acquiring the product may include outputting an upload graphical user interface to provide additional product information and requesting the first user to upload the product, acquiring the additional product information and the product uploaded by the first user, and providing the additional product information of the product for verification by at least one second user.

[0023] Obtaining the status information may include outputting an onboarding test graphical user interface containing information about one or more onboarding tests of the product in the test environment to at least one second user, and obtaining the status information of the one or more onboarding tests from the at least one second user.

[0024] The method may further include providing the first user with access to update the product in response to the status information, based on an access request received from the first user or the at least one second user.

[0025] Evaluating the product may further include receiving query inputs from at least one second user requesting information from the second user relating to one or more onboarding tests, and outputting the query inputs to the first user.

[0026] The method may further include outputting, to the first user, an onboarding test graphical user interface including the status information of the one or more onboarding tests.

[0027] The status information includes at least one of an onboarding test completion status, an event and / or result of an onboarding test, and a performance status of the product during the one or more onboarding tests.

[0028] Additional aspects are in part described in the following description, in part will be apparent from the description, or can be realized by the implementation of the presented embodiments of the present disclosure.

[0029] Hereinafter, the features, advantages, and importance of exemplary embodiments of the present disclosure will be described with reference to the accompanying drawings, in which like reference numerals denote like elements. In the drawings,

Brief Description of the Drawings

[0030] [Figure 1] Shows a diagram of a general system architecture according to one or more embodiments.

[0031] [Figure 2] Shows a block diagram of a system for providing a marketplace platform according to one or more embodiments.

[0032] [Figure 3] Shows a block diagram of a system for onboarding a service provider and onboarding virtualized network services according to one or more embodiments.

[0033] [Figure 4]A flowchart illustrates a method for registering a service provider to a marketplace platform and onboarding a product (e.g., a network service) according to one or more embodiments.

[0034] [Figure 5A] A flowchart illustrating a method for registering a service provider to a marketplace platform, according to one or more embodiments, is provided.

[0035] [Figure 5B] A flowchart illustrating a guided registration process for service providers to a marketplace platform, according to one or another embodiment, is provided.

[0036] [Figure 6] A flowchart illustrating a method for creating user profiles and dashboards for a marketplace platform, according to one or more embodiments, is provided.

[0037] [Figure 7] A flowchart illustrating a method for onboarding network services to a marketplace platform, according to one or more embodiments, is shown.

[0038] [Figure 8] A flowchart shows a method for guided onboarding of network services to a marketplace platform, according to one or more embodiments.

[0039] [Figure 9] A flowchart shows a method for the guided upload of network services to a marketplace platform according to one or more embodiments.

[0040] [Figure 10]A flowchart shows a method for guided onboarding testing and network service release in a marketplace platform, according to one or more embodiments.

[0041] [Figure 11] This document presents one non-exclusive, exemplary embodiment of an onboarding GUI portal for onboarding products to a marketplace.

[0042] [Figure 12] This document presents one non-exclusive, illustrative embodiment of a product upload GUI portal for onboarding products to a marketplace.

[0043] [Figure 13] This document presents a non-limiting, exemplary embodiment of an onboarding test GUI portal for evaluating products that will be onboarded to a marketplace.

[0044] [Figure 14] This document presents another non-limiting, exemplary embodiment of an onboarding test GUI portal for evaluating products that will be onboarded to a marketplace.

[0045] [Figure 15A] One or more non-exclusive exemplary embodiments of an authorization GUI portal for evaluating products that will be onboarded to a marketplace are shown. [Figure 15B] One or more non-exclusive exemplary embodiments of an authorization GUI portal for evaluating products that will be onboarded to a marketplace are shown. [Modes for carrying out the invention]

[0046] A detailed description of exemplary embodiments follows with reference to the accompanying drawings. The same reference numerals in different drawings may identify the same or similar elements.

[0047] The foregoing disclosures are illustrative and illustrative, but are not intended to be exhaustive or to limit implementations to the exact forms disclosed. Modifications and variations are possible in light of the foregoing disclosures, or modifications and variations may be obtained from the implementations. Furthermore, one or more features or components of one embodiment may be incorporated into another embodiment (or one or more features of another embodiment), or combined with another embodiment (or one or more features of another embodiment). In addition, it should be understood that in the flowcharts and operation descriptions provided below, one or more operations may be omitted, one or more operations may be added, one or more operations may be performed (at least partially) simultaneously, and the order of one or more operations may be changed.

[0048] It will be apparent that the systems and / or methods described herein may be implemented in various forms of hardware, firmware, or combinations of hardware and software. The actual dedicated control hardware or software code used to implement these systems and / or methods is not limited to the implementation form. Therefore, it is understood that the operation and behavior of the systems and / or methods are described herein without reference to specific software code, and that software and hardware may be designed to implement the systems and / or methods based on the descriptions herein.

[0049] Even if certain combinations of features are described in the claims and / or disclosed herein, these combinations are not intended to limit the disclosure of possible implementations. In fact, many of these features may be combined in ways not specifically described in the claims and / or disclosed herein. Each of the dependent claims listed below may depend directly on only one claim, but the disclosure of possible implementations includes each dependent claim combined with all other claims in the set of claims.

[0050] Any elements, actions, or commands used herein should not be construed as important or essential unless otherwise specified. Furthermore, where used herein, the articles “a” and “an” are intended to include one or more items and may be used interchangeably with “one or more.” When only one item is intended, use the term “one” or a similar expression. Also, where used herein, terms such as “has,” “have,” “having,” “include,” and “including” are intended to be non-restrictive. Additionally, the phrase “based on” is intended to mean “at least partially based on” unless otherwise specified. Furthermore, expressions such as “at least one of [A] and [B]” or “at least one of [A] or [B]” should be understood to include only A, only B, or both A and B.

[0051] Throughout this specification, any reference to “one embodiment,” “a certain embodiment,” “a non-limiting exemplary embodiment,” or similar language means that a particular feature, structure, or characteristic described in relation to the embodiment shown is included in at least one embodiment of the Solution. Thus, throughout this specification, the phrases “in one embodiment,” “in a certain embodiment,” “in one non-limiting exemplary embodiment,” and similar language may, but not necessarily, all refer to the same embodiment.

[0052] Furthermore, the features, advantages, and characteristics described herein may be combined in any suitable manner in one or more embodiments. Those skilled in the art will recognize, in light of the description herein, that the disclosure can be practiced even without one or more of the specific features or advantages of a particular embodiment. In other examples, additional features and advantages may be recognized in certain embodiments, which may not be present in all embodiments of the disclosure.

[0053] In one implementation of the disclosure described herein, a display page may contain information residing in the memory of a computing device, which may be transmitted over a network from the computing device to a database center, or vice versa. The information may be stored in memory in the computing device, data storage located at the edge of the network, or a server in the database center. A computing device or mobile device may accept non-temporary computer-readable media, which may contain instructions, logic, data, or code that may be stored in the persistent or temporary memory of the mobile device, or that may have some effect on or initiate an action by the mobile device. Similarly, one or more servers may communicate with one or more mobile devices over a network and transmit computer files residing in memory. The network may include, for example, the internet, a wireless communication network, or any other network for connecting one or more mobile devices to one or more servers.

[0054] The description of either a computing or mobile device may also apply to any type of networked device, including, but not limited to, mobile devices such as cellular phones (e.g., any “smartphone”), personal computers, server computers, or laptop computers, and wireless devices such as telephones, personal digital assistants (PDAs), network-connected roaming devices, wireless email devices, or other devices capable of wirelessly communicating with computer networks, or any other type of network device capable of communicating over a network and processing electronic transactions. The description of any mobile device mentioned may also apply to other devices, including, among others, short-range ultra-high frequency (UHF) devices, near-field communication (NFC), infrared (IR), and devices with Wi-Fi functionality.

[0055] The terms and phrases "software," "application," "app," and "firmware" may include any non-temporary computer-readable medium that stores a program that, when executed by a computer, causes the computer to perform a method, function, or control action.

[0056] The same phrases and terms as “network” may include one or more data links that enable the transfer of electronic data between computer systems and / or modules. When information is transferred to or provided to a computer via a network or another communication connection (either hardwired, wireless, or a combination of hardwired and wireless), the computer uses that connection as computer-readable medium. Thus, as an example, and not an limitation, computer-readable medium may also include networks or data links that can be used to carry or store desired program code means in the form of computer-executable instructions or data structures and can be accessed by general-purpose or dedicated computers.

[0057] The terms and phrases "portal" or "terminal" may include intranet pages, internet pages, locally residing software or applications, mobile device graphical user interfaces, or digital presentations for users. A portal may also be any graphical user interface for accessing various modules, components, features, options, and / or attributes of the disclosures described herein. For example, a portal may be a web page accessed by a web browser, a mobile device application, or any application or software residing on a computing device.

[0058] Figure 1 shows a diagram of a general network architecture according to one or more embodiments. Referring to Figure 1, users 110, 120, and 130 can communicate bidirectionally with a central server or application server 100 according to one or more embodiments via a secure network. In addition, users 110, 120, and 130 can also communicate directly bidirectionally with each other via a marketplace platform network system according to one or more embodiments. Here, user 110 can be any type of vendor or service provider, such as vendor A, vendor B, and vendor C, which offers similar, identical, or different services or products with respect to the network operator or service operator to either user 120 or user 130. In particular, user 110 can provide any type of telecommunications-related services or products, such as cellular service network deployment, network capacity updates, operational monitoring, data analysis and reporting, and any other appropriate services. Each of users 110 can communicate with server 100 via their respective terminal or portal. User 120 may be Network Operator A, Network Operator B, and Service Provider C, which may offer similar, identical, or different services or products to User 130 or User 110. Here, User 110 or 120 may, in particular, be any type of telecommunications vendor or network service provider, network operator, carrier, broadband provider, Unified Communications as a Service (UCaaS) provider, wired or wireless cellular network service provider, radio access network (RAN), web host, or any network-related or telecommunications-related service provider or network provider. Each of User 120 may communicate with Server 100 via their respective terminal or portal.User 130 can be any type of end user or customer of User 120 or User 110, such as End User A or Customer B and Customer C, or an end user who purchases and / or receives telecommunications network-related services from User 110 or User 120. Each of User 130 can communicate with Server 100 via their respective terminal or portal.

[0059] Continuing to refer to Figure 1, the central server 100 of the marketplace platform system according to one or more embodiments can further communicate bidirectionally with the management terminal / dashboard 140. Here, the management terminal / dashboard 140 can provide users 110, 120, 130, or the sales team or content / product creation team with various tools for managing various customers / end users and customer leads, such management can, among other things, include, according to one or more embodiments, the creation, editing, and promotion of promotional campaigns, advertisements, offers, and order options for various types of telecommunications network services or products for customers and other users of the marketplace platform. In addition, the management terminal / dashboard 140 may also include various types of access privileges for various users of the marketplace platform system according to one or more embodiments. Furthermore, the central server 100 according to one or more embodiments can further communicate bidirectionally with the database / third-party server 150. Here, Server 150 can provide various types of data storage (such as cloud-based storage), web services, content creation tools, data streams, data feeds, and / or various types of third-party support services to the central server 100 of the marketplace platform. However, within the scope of the present invention disclosures described herein, it is intended that one or more embodiment of the network service marketplace platform process and system may include any type of general network architecture.

[0060] Continuing to refer to Figure 1, one or more servers or terminals of elements 100-150 may include personal computers (PCs), printed circuit boards with computing devices, minicomputers, mainframe computers, microcomputers, telephone computing devices, wired / wireless computing devices (e.g., smartphones, personal digital assistants (PDAs)), laptops, tablets, smart devices, wearable devices, or any other similar functional devices.

[0061] In some embodiments, as shown in Figure 1, one or more servers, terminals, and users 100-150 may include a set of components such as a processor, memory, storage components, input components, output components, communication interfaces, and JSON UI rendering components. The set of device components may be coupled together communicatively via a bus.

[0062] The bus may comprise one or more components enabling communication between a set of components, one or more of the 100-150 servers or terminals. For example, the bus may be a communication bus, a crossover bar, a network, etc. The bus may be implemented using one or more (two or more) connections between the set of components, one or more of the 100-150 servers or terminals. This disclosure is not limited thereto.

[0063] One or more servers or terminals of elements 100-150 may comprise one or more processors. One or more processors may be implemented as hardware, firmware, and / or a combination of hardware and software. For example, one or more processors may comprise a central processing unit (CPU), graphics processing unit (GPU), accelerated processing unit (APU), microprocessor, microcontroller, digital signal processor (DSP), field-programmable gate array (FPGA), application-specific integrated circuit (ASIC), general-purpose single-chip or multi-chip processor, or other programmable logic devices, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. A general-purpose processor may be a microprocessor, or any conventional processor, controller, microcontroller, or state machine. One or more processors may also be implemented as a combination of computing devices, such as a combination of a DSP and a microprocessor, multiple microprocessors, one or more microprocessors working with a DSP core, or any other such configuration. In some embodiments, specific processes and methods may be performed by circuit configurations specific to a given function.

[0064] One or more processors may control the overall operation of one or more of the servers or terminals of elements 100 to 150, and / or a set of components (e.g., memory, storage components, input components, output components, communication interfaces, rendering components) of one or more of the servers or terminals of elements 100 to 150.

[0065] One or more of the servers or terminals of elements 100 to 150 may further comprise memory. In some embodiments, the memory may comprise random access memory (RAM), read-only memory (ROM), electrically erasable programmable ROM (EEPROM), flash memory, magnetic memory, optical memory, and / or other types of dynamic or static storage devices. The memory may store information and / or instructions for use by the processor (e.g., execution).

[0066] One or more storage components of the servers or terminals of elements 100 to 150 may store information and / or computer-readable instructions and / or code related to the operation and use of one or more of the servers or terminals of elements 100 to 150. For example, a storage component may include, along with a corresponding drive, a hard disk (e.g., magnetic disk, optical disk, magneto-optical disk, and / or solid-state disk), a compact disc (CD), a digital versatile disc (DVD), a universal serial bus (USB) flash drive, a Personal Computer Memory Card International Association (PCMCIA) card, a floppy disk, a cartridge, a magnetic tape, and / or another type of non-temporary computer-readable media.

[0067] One or more of the servers or terminals of element 100-150 may further comprise input components. The input components may include one or more components that enable one or more of the servers and terminals 110-140 to receive information via user input, etc. (e.g., touchscreen, keyboard, keypad, mouse, stylus, button, switch, microphone, camera, etc.). Alternatively, or in addition, the input components may include sensors for sensing information (e.g., global positioning system (GPS) components, accelerometer, gyroscope, actuator, etc.).

[0068] One or more output components among the servers or terminals of elements 100 to 150 may include one or more components that can provide output information from device 100 (e.g., a display, a liquid crystal display (LCD), light-emitting diodes (LEDs), organic light-emitting diodes (OLEDs), a haptic feedback device, a speaker, etc.).

[0069] One or more of the servers or terminals of elements 100 to 150 may further comprise a communication interface. The communication interface may include a receiver component, a transmitter component, and / or a transceiver component. The communication interface may enable one or more of the servers or terminals of elements 100 to 150 to establish connections with other devices (e.g., a server, another device) and / or to forward communications. Communications may be enabled via wired connections, wireless connections, or a combination of wired and wireless connections. The communication interface may enable one or more of the servers or terminals of elements 100 to 150 to receive information from and / or provide information to other devices. In some embodiments, the communication interface may provide communication with another device via a network such as a local area network (LAN), wide area network (WAN), metropolitan area network (MAN), private network, ad hoc network, intranet, internet, fiber optic network, cellular network (e.g., fifth generation (5G) network, long-term evolution (LTE) network, third generation (3G) network, code division multiple access (CDMA) network, etc.), public land mobile network (PLMN), telephone network (e.g., public switched telephone network (PSTN)), and / or a combination thereof or a combination of other types of networks.Alternatively, or in addition, the communication interface may provide communication with another device via a device-to-device (D2D) communication link such as FlashLinQ, WiMedia, Bluetooth, ZigBee, Wi-Fi, LTE, or 5G. In other embodiments, the communication interface may include an Ethernet interface, an optical interface, a coaxial interface, an infrared interface, a radio frequency (RF) interface, and the like.

[0070] Figure 2 shows a marketplace and trading platform system for telecommunications network services according to one or more embodiments. Referring to Figure 2, the marketplace platform module or portal 200 can be a portal for the marketplace platform and may include a Customer Management System (CMS) delivery node module 202 that communicates bidirectionally with a Business Support System (BSS) product stack module or portal 210 (including one or more of the modules 212-220 shown in Figure 2), as well as a CMS integration module or portal 206 for content management and integration with various repositories. A user / customer module or portal 224 (e.g., a user terminal or client device) can access the marketplace via communication with the CMS delivery node module or portal 202. In some embodiments, the user / customer module or portal 224 may also communicate with a Content Distribution Network (CDN) module or portal that further communicates with modules or portals 202 and 206. In some embodiments, the CMS delivery node module or portal 202 can handle interactions with a first customer when the customer accesses the marketplace platform 200 according to one or more embodiments. For example, the CMS delivery node module or portal 202 can receive requests from the customer's user terminal or portal 224 to browse available products / services, search for product / service data from a product catalog, and generate / display a graphical representation (e.g., columns, lists, etc.) of a user interface showing available products / services from the marketplace platform or one or more service providers or vendors.Furthermore, the product / content team module or portal 222 (e.g., terminals or client devices of sellers, service providers, vendors, etc.) can also communicate with the marketplace platform module or portal via communication with the CMS integration module or portal 206. In this case, the CMS integration module or portal 206 can generate and / or display a graphical user interface (e.g., a user interface for listing products for sale, configuring sales lists, generating or editing customer or product configuration profiles, facilitating sales activities, etc.) related to the seller, service provider, vendor, etc.

[0071] Continuing to refer to Figure 2, one or more embodiments of the marketplace platform module or portal 200 may also include a BSS product stack module or portal 210, where module 210 may further include a product catalog module or portal 212, which can be a repository / data storage for storing product / service data. Furthermore, module 212 may also include and store product / service level promotional offers, or discount indicators, or events related to one or more stored products / services. Module 210 may also include a customer information management (CIM) module or portal 214, which can be a repository / data storage for storing customer information (e.g., names, contact information, IDs, customer interest lists, customer level promotional offers, or discount events). Module 210 may also include a customer interaction management module or portal 216, which can serve as a repository / data storage for information about customer interactions with one or more embodiment marketplace platforms (e.g., interaction history between customer and interactive elements of a graphical user interface (GUI), communications between customer and service provider(s) or other customers(s)).

[0072] Continuing to refer to Figure 2, module 210 may also include a billing / invoice module or portal 218 that stores information related to customer billing / invoicing for services provided on the marketplace platform (e.g., previously created invoices, billing history, etc.). In addition, module 210 may also include a customer care / sales module or portal 220 that stores information on sales or customer-related activities (e.g., sales campaign history, promotional activities for specific types of customers, sales history analysis, etc.). In some embodiments, module 220 may identify data related to sales activities and user experience, retrieve / collect data from external data storage or from any of the modules or portals 212-218, store such data in a repository included in module 220, and provide such data to network service providers / vendors as needed. As shown in the figure, module 220 may also communicate with a product / content team module or portal 222, where the product / content team module or portal 222 may be a user (e.g., a vendor / service provider) seeking to promote / sell network services or a portal for such users. In addition, the product / content team module or portal 222 can be a lead conversion system, or a user that converts customer leads, analyzes customer activity, and facilitates pre-sales activities, post-sales activities, and marketing campaigns.

[0073] Continuing to refer to Figure 2, the Marketplace Platform Module or Portal 200 can also communicate with the Orchestrator Module 230 (for example, via an Application Programming Interface (API)). In particular, one or more modules of Module 210 or portals 212-220 can communicate with and / or be supported by any of the modules of Module 230 or portals 238-240. Specifically, the Orchestrator Module 230 may include a Product / Service Management Module 238 and a Cloud Orchestration Module 240. In particular, any of modules 238-240 can be containerized and stored in the "cloud" or a cloud cluster on external servers and databases. In some embodiments, the Product / Service Management Module 238 includes a repository / data storage for storing products and services provided by vendors / service providers. In some embodiments, the products and services are virtualized or software-based. In some embodiments, the cloud orchestration module 240 is configured to schedule products and services and deliver them to users of the network services marketplace platform.

[0074] Figure 3 shows a block diagram of a system for enrolling service providers and onboarding virtualized network services according to one or more embodiments. Referring to Figure 3, the orchestration module 350 may include product manager module 351 and cloud orchestration module 352, similar to the product manager module 238 and cloud orchestration module 240 in Figure 2. Furthermore, referring to Figure 3, the marketplace platform module 300 may include an enrollment and onboarding processing (EOP) module 310, a user information management (UIM) module 320, a product catalog module 330 (similar to the product catalog module 214 in Figure 2), a temporary repository 340, and a service test module 360.

[0075] In Figure 3, the user module 370 (similar to the user / customer module 224) and the platform management module 380 (similar to the product / content team module 222) can communicate with the marketplace platform module 300. The communication between the user module 370 and the platform management module 380 and the marketplace platform module 300 is similar, for example, to the communication between the user / customer module 224 and the product / content team module 222 in the marketplace platform 200 in Figure 2.

[0076] Continuing to refer to Figure 3, the EOP module 310 can serve as a portal for the marketplace platform 300 and communicates bidirectionally with the UIM module 320, temporary repository 340, product catalog module 330, orchestration module 350, service test module 360 ​​portal 210, user module 370, and platform management module 380.

[0077] In Figure 3, the temporary repository 340 is a data repository that can store software applications, such as network service software applications, that will be onboarded to the marketplace platform 300. The service test module 360 ​​can be a system emulator for virtualizing the network operator's telecommunications infrastructure to provide a secure test environment (e.g., a test environment isolated from the network operator's existing telecommunications infrastructure) for review / test teams to test products (e.g., network services) that will be onboarded to the centralized marketplace.

[0078] In Figure 3, within the scope of the disclosure described herein, it is intended that any user of the marketplace platform may first log in to the EOP module 310 to determine the user type or role (e.g., a service provider on the seller side of the marketplace, or a network operator on the buyer side of the marketplace), or the user's access privileges (i.e., user privileges for a service provider and platform administrator privileges for a network operator), such as the appropriate user for the module or portals 222, 224.

[0079] Figure 4 shows a flowchart of Method 400 for admitting a service provider to a marketplace platform and onboarding a product (e.g., network services) according to one or more embodiments. Referring to Figure 4, in step 401, the EOP module 310 generates and displays a graphical user interface (GUI) to prompt a user (e.g., a service provider, network operator, customer, etc.) to log in to the marketplace based on a centralized login policy defined by a second user (e.g., a network operator, administrator, etc.). In an exemplary embodiment, the EOP module 310 may generate and display a GUI that allows a second user (e.g., a network operator, administrator, etc.) to retrieve user profile information of a first user (e.g., a service provider, customer) based on a centralized login policy defined by the second user (e.g., a network operator, administrator, etc.). A centralized login policy is the process of enrolling users (e.g., service providers, customers, etc.) into a centralized marketplace (e.g., marketplace platform 300) defined by a second user (e.g., network operator, administrator, etc.) based on a centralized standard / format of user profile information for the first user of the centralized marketplace (e.g., service providers, customers, etc.).

[0080] In step 402, the EOP module 310 generates and displays a GUI that prompts the first user (e.g., a service provider) to provide information about the first user's product (e.g., virtualized network services) based on a centralized onboarding policy defined by the second user (e.g., a network operator). In an exemplary embodiment, the EOP module 310 can generate and display a GUI that enables the second user (e.g., a network operator) to obtain product information about the first user's product based on a centralized onboarding policy defined by the second user. The centralized onboarding policy is a process for onboarding (e.g., launching or offering) a new product (e.g., network services) to a centralized marketplace (e.g., marketplace platform 300) defined by the second user (e.g., a network operator) for all users of the marketplace (e.g., service providers, customers, sellers).

[0081] In step 403, the EOP module 310 generates and displays a GUI prompting the first user (e.g., a service provider) to upload products to a centralized marketplace. In an exemplary embodiment, the EOP module 310 may generate and display a GUI enabling a second user (e.g., a network operator) to retrieve the products and product information of the first user's products.

[0082] In step 404, the EOP module 310 connects to the temporary repository 340 to store the product in the centralized marketplace.

[0083] In step 405, the EOP module 310 generates and displays a GUI prompting a second user (e.g., a network operator) to test the product in a test environment (e.g., a service test module 360). In an exemplary embodiment, the EOP module 310 can generate and display a GUI prompting a review / test team to submit the product for onboarding testing in the service test module 360 ​​of the marketplace platform 300.

[0084] In step 406, the EOP module 310 generates and displays a GUI that prompts a second user (e.g., a network operator) to evaluate the product based on onboarding tests in a centralized marketplace. In an exemplary embodiment, the EOP module 310 may generate and display a GUI that enables a review / test team to, for example, perform tests on the product or review test results based on a centralized onboarding policy.

[0085] In step 407, the EOP module 310 may generate and display a GUI that enables a second user (e.g., a network operator) to determine the suitability of the product based on a centralized onboarding policy. In an exemplary embodiment, the EOP module 310 may generate and present a GUI that enables a second user (e.g., a network operator) to display information regarding the evaluation of the onboarding tests in step 407 to a first user (e.g., a service provider).

[0086] In an exemplary embodiment, in step 407, the EOP module 310 generates and displays a GUI that enables a second user (e.g., a network operator) to manage and control the role of the first user (e.g., a service provider) in evaluating the product during onboarding testing. In an exemplary embodiment, the EOP module 310 may generate and display a GUI that enables the second user (e.g., a network operator) to query information or adjustments regarding the first user's product (e.g., a service provider's network service) in order to continue the evaluation in step 406 so that the second user can determine the suitability of the first user's product.

[0087] In step 407, based on the above evaluation and determination, the product to be onboarded to the centralized marketplace may be suitable for a second user (e.g., a network operator). In this case, the EOP module 310 requests the temporary repository 340 to transfer the first user's product (e.g., a service provider's network service) to the product manager module 351. In an exemplary embodiment, the product manager module 351 can display the first user's product to at least one second user (e.g., at least one network operator) within the centralized marketplace (e.g., the marketplace platform 300).

[0088] Referring further to step 407, in an exemplary embodiment, the cloud orchestration module 352 may release (e.g., transfer) product information to the product catalog module 330 of the marketplace platform 300. In an exemplary embodiment, the orchestration module 352 may display or provide a schedule for the release (e.g., transfer to the product catalog module 330) of products (e.g., network services) in a centralized marketplace (e.g., the marketplace platform 300).

[0089] Figure 5A shows a flowchart of a method for registering a service provider 500 to a centralized marketplace according to one or more embodiments. Referring to Figure 5A, in order to access the marketplace platform 300, any user of the marketplace (e.g., a service provider, customer, seller, network operator, administrator, etc.) must be registered (e.g., a registered user). For this purpose, in step 501, the EOP module 310 detects unregistered users (e.g., a first user who has not logged in, such as a service provider or customer). In the case of an unregistered user, the EOP module 310 generates and displays an interactive element for the user. In an exemplary embodiment, the first user (e.g., a service provider or customer) can trigger an access request by the interactive element. For example, the first user can trigger an access request by a relevant interactive element on the registration GUI (e.g., a "Login" button, a "Create Account" button, etc.), such as selecting the login page of the marketplace platform 300.

[0090] In step 502, upon receiving an access request from a new (i.e., unregistered) user, the EOP module 310 requests activation information that enables (e.g., guides) the unregistered user to enter their user credentials. Based on the user's input, the EOP module 310 verifies the user's credentials. For example, the EOP module 310 verifies the unregistered user's credentials by email verification.

[0091] In step 503, once the activation information is verified, the EOP module 310 creates a user (e.g., service provider) profile. For this purpose, the EOP module 310 may request the UIM module 320 to provide a user profile template. The EOP module 310 generates and displays a user profile GUI to enable (e.g., guide) the user to enter their user profile information. In an exemplary embodiment, the EOP module 310 may create a user profile dashboard (e.g., a service provider dashboard) based on the acquired user profile information. For this purpose, the EOP module 310 may process the user's profile information in a standardized format for the marketplace platform 300.

[0092] Continuing to refer to step 503, the EOP module 310 connects to the platform administrator module 380 to request the platform administrator to review and approve the user (e.g., service provider) profile dashboard information. Based on the successful review and approval by the platform administrator, the EOP module 310 may receive an approval notification from the platform administrator module 380. In an exemplary embodiment, the EOP module 310 may create a notification to the user regarding successful user enrollment and provide a user status notification to update the relevant user information in the UIM module 320 based on the successful user enrollment.

[0093] Figure 5B shows a flowchart of Method 510 for Guided Enrollment of a Service Provider to a Centralized Marketplace, according to one or more embodiments. Referring to Figure 5B, a user (e.g., a service provider) accesses the marketplace platform 300. In step 511, the EOP module 310 detects that the user is not logged into the marketplace platform 300 (e.g., is an unregistered user). In an exemplary embodiment, the EOP module 310 generates and displays interactive elements for the user (e.g., a "Login" button, a "Create Account" button, etc.) so that the user (e.g., a service provider) can select to log in to the marketplaces 200, 300. In an exemplary embodiment, if the user is a registered user (e.g., a service provider), the user can select the Login button. Then, in step 512, the user can provide login data such as username, user ID, email address, password, ticket number, etc., to log in via a GUI (e.g., a login GUI) that is later generated and displayed by the EOP module 310. Once the login credentials are successfully verified, the user logs on to the marketplace 300.

[0094] Continuing to refer to step 512, in the case of an unregistered user (e.g., a service provider), the EOP module 310 generates an interactive element (e.g., a "Create Account" button) and displays it to the new (e.g., unregistered) user. The new user can select the Create Account button, which can trigger an access request through the interactive element. The EOP module 310 detects the access request from the new (e.g., unregistered) user.

[0095] In step 513, in an exemplary embodiment, the EOP module 310 requests either a login template for a registered user or a signup template for an unregistered user from the UIM module 320. The login (e.g., signup) template may include user activation information such as username, user ID, email address, password, ticket number, and authentication request to the identity platform.

[0096] In step 514, in an exemplary embodiment, the EOP module 310 obtains a login (e.g., sign-up) template from the UIM module 320. Based on the login (e.g., sign-up) template, the EOP module 310 generates and displays a user activation information GUI, e.g., a login (e.g., sign-up) information GUI. The GUI may include a number of input fields for requesting user activation information determined by the network operator in a guided manner, e.g., pre-filled input fields, pull-down menus, or an autocomplete function that allows (e.g., guides) the user to directly enter the requested information into the required fields. For this purpose, the network operator can obtain a common standard / format for all new users (e.g., service providers).

[0097] In step 516, the EOP module 310 displays a GUI to the new user and prompts the user to enter user activation information. In an exemplary embodiment, the EOP module 310 checks the user input. If the user input does not conform to a standard / format defined by the network operator, the EOP module responds in step 516B with a notification prompting the user to correct the user information to conform to the requested standard / format (e.g., by creating and providing an additional graphical user interface), or in step 516A with autocorrection of the input information to conform to the requested standard / format. Steps 516, 516A, and 516B are repeated until the input information is standardized.

[0098] In step 517, the EOP module 310 validates the standardized input information. For example, in an exemplary embodiment, the EOP module can initiate the email validation process. Specifically, in this example, the EOP module requests a validation email template from the EOP module 310. Based on the received validation email template, the EOP module 310 can generate a validation email containing the standardized user information received in step 516 and send the validation email to a new user (e.g., an unregistered user). In this way, the validity of the email can be validated. The validation in step 517 completes the collection of user activation information in Figure 5B.

[0099] Figure 6 shows a flowchart of Method 600 for creating user profiles and dashboards for a centralized marketplace according to one or more embodiments. Referring to Figure 6, in an exemplary embodiment, the success verification in step 517 relates to the first login of a new user (e.g., an unregistered user without a user profile) to the marketplace platform 300. In this case, the user activation information has been verified, and the EOP module 310 sends a notification to the new user. In an exemplary embodiment, the EOP module 310 may generate a confirmation GUI in the form of a welcome page for the new user.

[0100] In step 601, in the case of the exemplary embodiment described above (i.e., an unregistered user without a user profile), the EOP module 310 requests a user profile (e.g., a service provider profile) template from the UIM module 320. In step 603, the UIM module 320 provides the user profile template.

[0101] In step 603, the EOP module 310 generates a service provider profile GUI based on the user profile template.

[0102] In step 604, the EOP module displays a graphical user interface to the new user (e.g., a new service provider) and prompts the user for their profile information. For example, the graphical user interface may include a number of input fields for requesting user profile information determined by the network operator in a guided manner, such as pre-filled input fields, pull-down menus, or an autocomplete function that allows (e.g., guides) the user to directly enter the requested information into the required fields. For this purpose, the network operator maintains a common standard or format for all new users (e.g., service providers) within the marketplace platform 300.

[0103] Continuing to refer to step 603, the user profile GUI may include all types of business-related information defined by the network operator. In an exemplary embodiment, the EOP module 310 can generate at least one graphical user interface, which may take the form of a multi-level (e.g., multi-stage) wizard comprising a set of graphical user interfaces that may include numerous interactive pages (e.g., graphical user interfaces prompting input of input information) for various information categories. In this way, user profile information queries are structured intuitively and efficiently. For example, categories for querying user profile information may include vendor information, sales / pricing information, product information (e.g., virtualized network service information), customer service information, etc.

[0104] In step 603, when the EOP module 310 determines that the input of user profile information is complete, the EOP module 310 stores the user profile information in the UIM module 302.

[0105] In step 604, the EOP module 310 sends a notification to the marketplace platform administrator (e.g., the content / product team) informing them that a new user profile (e.g., a new service provider profile) has been created and requires approval.

[0106] In step 605, the platform administrator accesses the marketplace platform 300 via the platform management module 380. In an exemplary embodiment, the EOP module 310 can generate a user profile dashboard from user (e.g., service provider) profile information and display it to the platform administrator. In an exemplary embodiment, the user (e.g., service provider) profile information dashboard can be reviewed based on user profile information stored in the UIM module 320, or based on updated user profile information stored in the UIM module 320.

[0107] In an exemplary embodiment, in step 605, the platform administrator may review the user profile dashboard information and approve it if it meets the standard / format requirements defined by the network operator. In an exemplary embodiment, the platform administrator of this patent may review and approve either user profile information entered directly by a new user or user profile information edited by the EOP module 310 (e.g., user profile dashboard information). In an exemplary embodiment, the platform administrator of this patent may review and approve user profile information stored in the UIM module 320.

[0108] Continuing with step 605, in an exemplary embodiment, the EOP module 310 may generate and display interactive elements for user profile information approval (e.g., by clicking an "Approve" button in a graphical user interface) or a graphical user interface for checking the approval status of user profile information. In an exemplary embodiment, if the platform administrator cannot approve the user profile dashboard information, steps 603 to 605 may be interactively repeated based on the user profile information GUI displayed by the EOP module 310 until a set of appropriable user profile information can be collected.

[0109] In step 606, based on platform management approval, the EOP module 310 connects to the UIM module 320 to update the user information status with the relevant user information within the EOP module 310. For example, the updated status may include information elements such as "Under Review" or "Successful Registration". In an exemplary embodiment, step 606 can complete the registration flow of method 600 in Figure 6.

[0110] Figure 7 shows a flowchart of a method 700 for onboarding network services to a marketplace platform according to one or more embodiments. Referring to Figure 7, only users who have logged into the marketplace platform 300 (e.g., registered users) can request onboarding of a product (e.g., virtualized network services). For this purpose, in order for a user (e.g., a service provider) to request onboarding of a product (e.g., virtualized network services) to the marketplace platform (200, 300), they must successfully log into the marketplace portal (300) (e.g., complete registration).

[0111] Based on a user's successful registration (e.g., a service provider), the user can add a product (e.g., a virtualized network service) to the marketplace platform 300 by logging into the marketplace platform 300, selecting the onboarding page, and requesting onboarding for the product (e.g., a virtualized network service). In an exemplary embodiment, for this purpose, the EOP module 310 generates an onboarding page on the landing page in the form of a GUI or the like and displays it to new or existing users (e.g., new or existing service providers).

[0112] In step 701, the EOP module 310 detects a user's onboarding request via the marketplace platform 300.

[0113] In step 702, the EOP module 310 requests a template(s) of product information from the UIM module 320. Based on the template(s), the EOP module 310 generates and displays a GUI(s) for requesting product information(s) (e.g., network service information) so that a user(s) (e.g., a service provider) can enter (e.g., be guided) product information(s) (e.g., network service information) for a product to be onboarded to the marketplace platform 300.

[0114] In step 703, the EOP module 310 determines that the user has finished entering product information. The EOP module 310 requests a template from the UIM module to generate and display a GUI that prompts (e.g., guides) the user to upload a product (e.g., a network service) to the temporary repository 340 within the marketplace platform 300. In an exemplary embodiment, the upload GUI may include input fields that prompt the user to enter additional user information into the upload GUI.

[0115] In step 704, in an exemplary embodiment, the EOP module 310 can collect any remaining product information (e.g., any additional product information that may have been uploaded along with the product) and determine that the product information entry is complete. Accordingly, the EOP module 310 connects to the platform administrator to request review and approval of the product information. In an exemplary embodiment, the review and approval process may be similar to the review and approval process in steps 603 to 605 of Figure 6 (e.g., step 503 in Figure 5A).

[0116] In step 705, in an exemplary embodiment, the product information may be approved as a result of a review by the platform administrator. According to this embodiment, the EOP module 310 connects to the review / test team. In an exemplary embodiment, the EOP module 310 may notify the review / test team of the creation of new onboarding product information for the uploaded product (e.g., uploaded network service). The EOP module 310 may forward the uploaded product to the review / test team for further evaluation of the product based on the guided onboarding test.

[0117] In step 706, the EOP module 310 generates one or more onboarding test GUIs based on the onboarding test template of the UIM module 320, and displays the information received from the review / test team to the user (e.g., service provider) via the said onboarding test GUI.

[0118] Continuing to refer to step 706, in an exemplary embodiment, the review / test team approves or rejects network services based on test results from onboarding tests of the uploaded product.

[0119] In step 707, once the review / test team is able to approve the network service, the EOP module 310 requests the temporary repository 340 to transfer the network service to the product manager module 351.

[0120] In step 708, the cloud orchestration module 352 releases the network service to the marketplace platform 300. In an exemplary embodiment, the cloud orchestration module 352 may schedule the release of a product (e.g., network service) on the marketplace platform 300. For example, the cloud orchestration module 352 may transfer product information records (e.g., description, version number, price, etc.) to the product catalog module 330. The product catalog module 330 publishes the product information records (e.g., product information dashboard) as a product available to all and / or selected customers / users within the marketplace platform 300.

[0121] Figure 8 shows a flowchart of Method 800 for Guided Onboarding of Network Services to a Marketplace Platform, according to one or more embodiments. Referring to Figure 8, in step 801, according to one or more exemplary embodiments, a user (e.g., a service provider) may onboard a network service to the Marketplace Platform 300 via an onboarding page, landing page, user profile dashboard, etc. The onboarding page, landing page, user profile dashboard, etc. may include relevant interactive elements (e.g., a "Add Service" button). For example, in the case of a user who has already launched a product on the Marketplace Platform 300 (e.g., onboarded), the EOP module 310 may generate and display a GUI (e.g., a user profile dashboard) which may include relevant interactive elements (e.g., a "Add Service" button, etc.). In an exemplary embodiment, when a user (e.g., a service provider) attempts to onboard a product (e.g., a virtualized network service) for the first time, the user can select relevant interactive elements on the onboarding page that trigger the onboarding request for the product (e.g., a virtualized network service) after logging into the marketplace platform 300.

[0122] Although not limited to illustrative embodiments, the user may, after logging into the marketplace platform 300, trigger relevant interactive elements (such as an "Add a Service" button) displayed by the EOP module 310.

[0123] In step 802, the EOP module 310 requests a product information (e.g., network service information) template from the UIM module 320.

[0124] In step 803, the UIM module 320 provides a product information (e.g., network service information) template.

[0125] In step 804, the EOP module 310 generates a product information GUI (e.g., a network service information GUI). The product information GUI may include all types of product-related information defined by the network operator. In an exemplary embodiment, the EOP module 310 can generate at least one graphical user interface, which may take the form of a multi-level (e.g., multi-stage) wizard comprising a set of graphical user interfaces that may include numerous interactive pages for various information categories. In this way, product information (e.g., network service information) queries are structured intuitively and efficiently. For example, categories for product information (e.g., network service information) queries may include technical specifications, test specifications, implementation specifications, user manuals, performance specifications, compatibility information, release status information, sales / pricing information, customer service information, etc.

[0126] In step 805, the EOP module 310 displays a graphical user interface to the user (e.g., a new service provider). In an exemplary embodiment, the graphical user interface may include a number of input fields for requesting user profile information determined by the network operator in a guided manner, such as pre-filled input fields, pull-down menus, or an autocomplete function that allows (e.g., guides) the user to directly enter the requested information into the required fields. For this purpose, the network operator maintains a common standard / format for all new users (e.g., service providers) within the marketplaces 200, 300.

[0127] In step 806, the EOP module 310 displays a GUI to the new user and prompts the user to enter product information (e.g., network service information). In an exemplary embodiment, the EOP module 310 can check the user input.

[0128] In step 807, if the user input does not conform to the standards / format defined by the network operator, the EOP module responds with a notification prompting the user to modify the product information (e.g., network service information) to conform to the requested standards / format (e.g., by creating and providing an additional graphical user interface), or by autocorrecting the input information to conform to the requested standards / format. Steps 806 and 807 are repeated until the input information is standardized.

[0129] In step 808, when the EOP module 310 determines that the input of product information (e.g., network service information) is complete, the EOP module 310 stores the recorded product information (e.g., network service information) in the UIM module 302. In an exemplary embodiment, the EOP module 310 may create a product information dashboard.

[0130] In step 809, the EOP module 310 enables the user to upload a product (e.g., a network service) to the temporary repository 340. In an exemplary embodiment, before enabling the user to upload a product in step 809, the EOP module 310 may verify the recorded product information (e.g., network service information), similar to step 517 in Figure 5.

[0131] Figure 9 shows a flowchart of Method 900 for Guided Upload of Network Services to a Marketplace Platform, according to one or more embodiments. Referring to Figure 9, in an exemplary embodiment, a user has logged into a marketplace platform 220, 300 and has successfully completed entering product information (e.g., network service information).

[0132] In step 901, the EOP module 310 requests a template from the UIM module 320 for generating and displaying the upload GUI.

[0133] In step 902, the EOP module 310 obtains the product upload template from the UIM module 320.

[0134] In step 903, the EOP module 310 generates an upload GUI to enable (e.g., guide) the user to upload a product (e.g., a network service) to a temporary repository 340 within the marketplace platform 300. In an exemplary embodiment, the upload GUI may prompt the user to enter additional product information (e.g., network service information).

[0135] In step 904, the EOP module 310 displays an upload GUI to the user (e.g., a new service provider) and prompts them to upload a product (e.g., a network service) to the temporary repository 340. In an exemplary embodiment, the graphical user interface may include a number of input fields, e.g., pre-filled input fields, pull-down menus, or an autocomplete function that allows (e.g., guides) the user to directly enter the requested information into the required fields, for user profile information and / or product information determined by the network operator. Furthermore, in an exemplary embodiment, the prompt to upload a product (e.g., a network service) to the temporary repository 340 may include a drag-and-drop field. For this purpose, the network operator maintains a common standard or format for onboarding (e.g., product upload) for all new users (e.g., service providers) within the marketplaces 200, 300.

[0136] In step 905, the user uploads a product (e.g., a network service) to a temporary repository 340 within the marketplace platform 300. In an exemplary embodiment, the input of information into the upload GUI may be similar to steps 806 and 807 in Figure 8.

[0137] Continuing with step 905, in an exemplary embodiment, the EOP module 310 can supplement the product information collected in step 904 (e.g., network service information) with the recorded product information in step 808 in Figure 8. In an exemplary embodiment, the EOP module 310 can store the product information in the UIM module 320.

[0138] In step 906, the EOP module 310 connects to the temporary repository 340 and stores the product (e.g., network service) in the temporary repository 340 for further processing (e.g., testing the network service with the service test module 360).

[0139] In step 907, when the EOP module 310 determines that the product information has been entered and the product (e.g., network service) has been uploaded, the EOP module 310 may send a notification to the marketplace platform administrator (e.g., content / product team) informing them that the product information has been entered and the product (e.g., network service) has been uploaded and that approval is required.

[0140] Refer to step 907. The platform administrator accesses the marketplace platform 300 via the platform management module 380. In an exemplary embodiment, the EOP module 310 can generate a dashboard from product information and uploaded product information (e.g., network services). In an exemplary embodiment, the platform administrator's review / approval process is similar to step 705 in Figure 7 (i.e., steps 604 and 605 in Figure 6). In an exemplary embodiment, based on the platform administrator's approval of the product, the EOP module 310 may forward the product information to the test engineers of the review / test team.

[0141] Figure 10 shows a flowchart of Method 1000 for Guided Onboarding Testing and Release of Network Services in a Marketplace Platform, according to one or more embodiments. Referring to Figure 10, in step 1001, the EOP module 310 connects to the review / test team to notify (e.g., guide) the team to begin onboarding testing of the product (e.g., network services). For this purpose, in step 1002, the EOP module 310 may request a template for onboarding testing from the UIM module 320. In step 1004, in an exemplary embodiment, the UIM module 320 may provide the EOP module 310 with an onboarding testing template.

[0142] In step 1002, in an exemplary embodiment, the EOP module 310 may request a template from the service test module 360 ​​for guiding the review / test team through onboarding testing. According to this embodiment, in step 1003, the service test module 360 ​​may provide the EOP module 310 with a template for guiding the test.

[0143] In step 1004, the EOP module 310 generates an onboarding test GUI so that the review / test team (i.e., the platform management side, such as the content / product team) can work through the onboarding test information defined by the network operator (e.g., guide them).

[0144] In step 1004, in one exemplary embodiment, the onboarding test information may include test states such as sandbox, staging, and productivity testing phases. In particular, the onboarding test information may include information on the preparation of the test environment and test routine information regarding which onboarding tests to initiate and how to initiate them, as defined by the network operator. The onboarding test information may have the advantage for the network operator of maintaining a common standard or format for onboarding tests of products for all new users (e.g., service providers) of the marketplace platform 300.

[0145] Continuing with step 1004, in an exemplary embodiment, the onboarding test GUI may include test preparation information, test routine information, test authorization information, etc. In an exemplary embodiment, the onboarding test GUI may include test preparation information, test routine information, test authorization information, etc. for each test state (e.g., sandbox state, staging state, productivity state, etc.). In an exemplary embodiment, each test state may refer to a milestone in the onboarding test. In one exemplary embodiment, a test state may indicate the test progress of the product in the test environment (e.g., in the Service Test Module 360, etc.).

[0146] In exemplary embodiments, the onboarding test GUI may include test preparation information such as pre-arbitration (pre-ARB), application prioritization and scheduling, creation of an identity management system (IDM), creation of a virtual private network (VPN), resource allocation, preparation of an application-centric infrastructure (ACI) network, preparation of a perimeter network (or screen subnet) (DMZ) network, integration of an open batch factory (OBF), and integration of a load balancer (LB).

[0147] In an exemplary embodiment, the onboarding test GUI may include test routine information such as lifecycle management (LCM) testing, user acceptance testing (UAT), security assurance testing, user interface (UI) / user experience (UX) validation, stress testing, system architecture compatibility testing at the target location, and performance testing.

[0148] In an exemplary embodiment, the onboarding test GUI may include the above-mentioned test preparation information and / or test routine information as part of the sandbox test state.

[0149] Continuing with step 1004, in an exemplary embodiment, the EOP module 310 can generate an onboarding test GUI so that a user (i.e., a vendor / user such as a service provider) can monitor (e.g., guide) the progress of onboarding their products to the marketplace platform 300.

[0150] Referring to Figure 10, in one exemplary embodiment, as described above, in step 1004, based on the onboarding test information, the EOP module 310 generates an onboarding test GUI so that the user (i.e., a vendor / user side such as a service provider) can monitor the project status of the onboarding test. In one exemplary embodiment, the onboarding GUI may include project planning tools such as progress bars, timelines, milestone diagrams, and Gantt diagrams that show each process step of the onboarding test. For this purpose, in the exemplary embodiment, the review / test team's work schedule for the product onboarding test can be shared with the user via the onboarding test GUI.

[0151] Continuing to refer to Figure 10, in an exemplary embodiment, the EOP module 310 can generate an onboarding test GUI (e.g., dashboard information, onboarding portal, onboarding portal welcome page, etc.) to enable the user to monitor the onboarding test progress of the product.

[0152] In an exemplary embodiment, the EOP module 310 can generate an onboarding test GUI to enable the user to monitor the performance status of the product in each test state (e.g., sandbox state, staging state, productivity state, etc.). For this purpose, the GUI can generate and display an overview (e.g., a list or table) showing the performance of the product (e.g., a network service application) in different test states during onboarding testing.

[0153] In an exemplary embodiment, the EOP module 310 may generate an onboarding test GUI that allows the user to obtain information about test routines, such as block diagrams and schematics, that describe the content of the tests applied to the product in the test environment.

[0154] In an exemplary embodiment, the EOP module 310 can generate an onboarding test GUI to allow the user to monitor when and where (e.g., in which test state or in which module of the test environment). In an exemplary embodiment, the onboarding test GUI may allow the user to monitor which test events were applied to the product (e.g., network services).

[0155] In an exemplary embodiment, the EOP module 310 can generate an onboarding test GUI to allow a user to monitor whether a product (e.g., a network service) passed or failed test events performed by a review / test team. Alternatively, in an exemplary embodiment, the EOP module 310 can generate an onboarding test GUI to allow a user to monitor when, where, and which test events were completed during onboarding.

[0156] In an exemplary embodiment, the EOP module 310 can generate an onboarding test GUI to enable a user (e.g., a staff member of a user who has the right to access the product (e.g., a network service) in the test environment and / or during testing) to manage access to the product during testing.

[0157] Continuing with step 1004, in an exemplary embodiment, the EOP module 310 can generate an onboarding test GUI to enable (e.g., guide) interaction between the review / test team (i.e., platform management side such as the content / product team) and the user (i.e., vendor / user side such as a service provider) during onboarding testing. In an exemplary embodiment, the EOP module 310 can generate a user control GUI based on the onboarding test GUI. The user control GUI can enable a network operator to manage user access tasks. The user control GUI may display user access requests to modules in the test environment (e.g., user access requests to functions within the test environment).

[0158] In an exemplary embodiment, the user control GUI may display user access requests to the product under test (e.g., a network service). In an exemplary embodiment, the user control GUI may allow the review / test team to schedule the time and location of user access. For example, the review / test team (i.e., the platform management side, such as the content / product team) may create work orders for the user based on the user's access status, etc.

[0159] The user control GUI may be defined by the network operator to maintain a common standard or format for onboarding testing of products for all new users (e.g., service providers) of the Marketplace Platform 300.

[0160] In an exemplary environment, the onboarding test GUI could generate a permissions GUI to allow the review / test team (i.e., the platform management side, such as the content / product team) to manage (e.g., guide) user permissions for accessing the test environment.

[0161] Continuing to refer to step diagram 10, in step 1005, the EOP module 310 may, depending on the exemplary embodiment, display the onboarding test GUI to the review / test team (i.e., the platform management side, such as the content / product team) or the user (i.e., the vendor / user side, such as the service provider).

[0162] In step 1006, the review / test team reviews the onboarding test and approves or rejects the product (e.g., network service). In an exemplary embodiment, if the product (e.g., network service) fails some test events but passes others, the EOP module 310 may generate and display an onboarding test GUI to allow the review / test team and the user to interact (e.g., guide) during the onboarding test.

[0163] As described above, in steps 1004 and 1005, the EOP module 310 generates an onboarding test GUI for interaction between the review / test team and the user. For this purpose, in exemplary embodiments, the onboarding test GUI may include input fields requesting comments on the onboarding test, which may allow the user to directly enter the requested information into required fields (e.g., guides), and which may provide the review / test team (i.e., platform management side such as the content / product team) with additional product information (e.g., information queries for troubleshooting during the onboarding test).

[0164] In step 1007, once the review / test team (i.e., the platform management side such as the content / product team) approves the onboarding test, the EOP module 310 requests the temporary repository 340 to transfer the network services to the product manager module 351.

[0165] In step 1008, the cloud orchestration module 352 releases the network service to the marketplace platform 300 (for example, step 1008 is similar to step 708 in Figure 7).

[0166] Figure 11 shows one non-limiting exemplary embodiment of a product information GUI portal for onboarding a product to the marketplace. From here, the user enters information about the product to be onboarded to the marketplace. In one exemplary embodiment, the product information GUI portal of Figure 11 may be generated and / or populated by the EOP module 310 based on product information data retrieved from the UIM module 320.

[0167] Figure 12 shows one non-limiting exemplary embodiment of a product upload GUI portal for onboarding products to a marketplace. From here, the user uploads products and enters information about the products to be onboarded to the marketplace. In one exemplary embodiment, the product information GUI portal in Figure 12 may be generated and / or populated by the EOP module 310 based on product information data retrieved from the UIM module 320.

[0168] Figure 13 shows one or more non-exclusive exemplary embodiments of an onboarding test GUI portal for evaluating products that will be onboarded to the marketplace. From here, users can obtain the evaluation progress of products that will be onboarded to the marketplace. Users who may have already onboarded products to the marketplace can request to onboard their products to the marketplace. For example, EOP module 310 may provide an interactive element (e.g., an "Add Application" button) for detecting a user's new onboarding request. In an exemplary embodiment, the onboarding test GUI portal of Figure 13 may be generated and / or populated by EOP module 310 based on product information data retrieved from UIM module 320. In another exemplary embodiment, the onboarding test GUI portal of Figure 13 may be generated and / or populated by EOP module 310 based on product information data retrieved from service test module 360.

[0169] Figure 14 shows one or more non-limiting exemplary embodiments of an onboarding test GUI portal for evaluating products to be onboarded to the marketplace. From this, the user can obtain information such as the test environment, product test priority, start and target dates for test events, and the status of test events. In exemplary embodiments, the onboarding test GUI portal of Figure 14 may be generated and / or populated by the EOP module 310 based on product information data retrieved from the UIM module 320. In exemplary embodiments, the onboarding test GUI portal of Figure 14 may be generated and / or populated by the EOP module 310 based on product information data retrieved from the service test module 360.

[0170] Figures 15A and 15B show one or more non-limiting exemplary embodiments of an authorization GUI portal for evaluating products to be onboarded to the marketplace. Herein, in Figure 15A, a platform administrator (e.g., a network operator or review / test team) inputs (i.e., manages) user authorizations for accessing the test environment (e.g., service test module 360) on the marketplace platform 300. In Figure 15B, in an exemplary embodiment, the platform administrator (e.g., a network operator or review / test team) can manage (e.g., modify or cancel) user authorizations. In an exemplary embodiment, the onboarding test GUI portals in Figures 15A and 15B may be generated and / or populated by the EOP module 310 based on product information data retrieved from the service test module 360.

[0171] Exemplary embodiments of this disclosure provide methods and systems for simplifying and automating the network service enrollment and onboarding process, in contrast to manual onboarding of network services on-site. The centralized enrollment and onboarding process can save time and resources, and automation, in particular, minimizes human error and compatibility failures, improves customer satisfaction, and reduces business risk for the user (e.g., service provider), among other benefits. Furthermore, by automating user (e.g., service provider) enrollment and onboarding in a centralized and guided manner, the online marketplace platform provides customers (e.g., network operators) with an easy, flexible, cost-effective, efficient, and rapidly implementable solution for network service selection. For the user (e.g., service provider), the network service enrollment and onboarding process provides a low-risk testing environment with minimal impact on customers (e.g., network operators) so that high-quality services can be provided without imposing excessive demands on customers.

[0172] It is understood that the specific order or hierarchy of blocks in the process / flowchart disclosed herein is an example of an exemplary technique. It is understood that the specific order or hierarchy of blocks in the process / flowchart can be rearranged based on design preferences. Furthermore, some blocks may be combined or omitted. The appended method claims display elements of various blocks in an exemplary order and are not intended to be limited to the specific order or hierarchy shown.

[0173] Some embodiments may relate to systems, methods, and / or computer-readable media in integration at any possible level of technical detail. Furthermore, one or more of the above-described components may be implemented as instructions stored in a computer-readable medium and executable by at least one processor (and / or include at least one processor). The computer-readable medium may include one or more computer-readable non-temporary storage media having computer-readable program instructions for causing a processor to perform an operation.

[0174] A computer-readable storage medium can be a tangible device capable of holding and storing instructions for use by an instruction execution device. A computer-readable storage medium may, but is not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination thereof. A non-exhaustive list of more specific examples of computer-readable storage media includes portable computer diskettes, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), portable compact disc read-only memory (CD-ROM), digital multipurpose discs (DVDs), memory sticks, floppy disks, mechanically encoded devices such as punched cards or grooved raised structures on which instructions are recorded, and any suitable combination thereof. As used herein, computer-readable storage media should not be construed as transient signals themselves, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through waveguides or other transmission media (e.g., light pulses passing through optical fiber cables), or electrical signals transmitted through wires.

[0175] The computer-readable program instructions described herein can be downloaded from a computer-readable storage medium to each computing / processing device, or to an external computer or external storage device via a network, such as the Internet, a local area network, a wide area network, and / or a wireless network. The network may include copper transmission cables, optical transmission fibers, wireless transmissions, routers, firewalls, switches, gateway computers, and / or edge servers. A network adapter card or network interface within each computing / processing device receives computer-readable program instructions from the network and transfers the computer-readable program instructions for storage in a computer-readable storage medium within each computing / processing device.

[0176] The computer-readable program code / instructions for performing an operation may be assembler instructions, instruction-set-architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state-setting data, configuration data for integrated circuit configurations, or source code or object code written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Smalltalk and C++, and procedural programming languages ​​such as the C programming language or similar programming languages. The computer-readable program instructions may be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer via any type of network, including a local area network (LAN) or a wide area network (WAN), or it may be connected to an external computer (for example, via the Internet using an Internet service provider). In some embodiments, for example, an electronic circuit configuration including a programmable logic circuit configuration, a field-programmable gate array (FPGA), or a programmable logic array (PLA) may execute computer-readable program instructions by personalizing the electronic circuit configuration using state information of computer-readable program instructions in order to perform an action or operation.

[0177] These computer-readable program instructions may be provided to a general-purpose computer, a dedicated computer, or a processor of another programmable data processing device to generate a machine such that instructions executed via the processor of the computer or other programmable data processing device generate means for performing functions / actions specified in one or more blocks of a flowchart and / or block diagram. These computer-readable program instructions may also be stored in a computer-readable storage medium that can instruct a computer, a programmable data processing device, and / or other device to function in a particular way such that the computer-readable storage medium storing the instructions internally contains a product containing instructions that perform a mode of function / action specified in one or more blocks of a flowchart and / or block diagram.

[0178] Computer-readable program instructions may also be loaded into a computer, another programmable data processing device, or another device to generate a computer implementation process by causing the computer, another programmable device, or other device to execute a series of operational steps so that the instructions executed on the computer, another programmable device, or other device perform a function / action specified in one or more blocks of a flowchart and / or block diagram.

[0179] The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer-readable media according to various embodiments. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of an instruction containing one or more executable instructions for implementing a specific logical function(s). Methods, computer systems, and computer-readable media may include additional blocks, fewer blocks, different blocks, or blocks with different configurations compared to the blocks shown in the figures. In some alternative implementations, the functions described in the blocks may be executed in a different order than shown in the figures. For example, two consecutively shown blocks may be executed simultaneously or substantially simultaneously, or blocks may sometimes be executed in reverse order depending on the relevant functionality. It should also be noted that each block in a block diagram and / or flowchart, and combinations of blocks within a block diagram and / or flowchart, can be implemented by a dedicated hardware-based system that performs a specified function or operation, or a combination of dedicated hardware and computer instructions.

[0180] It will be apparent that the systems and / or methods described herein may be implemented in various forms of hardware, firmware, or combinations of hardware and software. The actual dedicated control hardware or software code used to implement these systems and / or methods is not limited to the implementation form. Therefore, it is understood that the operation and behavior of the systems and / or methods are described herein without reference to specific software code, and that software and hardware may be designed to implement the systems and / or methods based on the descriptions herein.

Claims

1. A system for adding service providers to a centralized marketplace and onboarding virtualized network services, Upon receiving a user request from a first user to access the aforementioned centralized marketplace, Based on the received user request, the first user is authenticated. Based on the prescribed onboarding policy, the product information of the authenticated first user, which is a virtualized network service for telecommunications networks, is obtained. Based on the predetermined onboarding policy, the product is acquired in order to perform one or more onboarding tests for the product in the test environment of the centralized marketplace. Obtain the status information of one or more of the aforementioned onboarding tests, A system configured to publish the product on the centralized marketplace for purchase based on the results of one or more of the aforementioned onboarding tests.

2. During authentication, From among a number of predetermined roles, including the roles of a vendor and a customer, it is determined that the role of the first user registered in the centralized marketplace is the role of the vendor. The system according to claim 1, further configured to provide access to the centralized marketplace based on the determined role of the first user being the role of the vendor.

3. When acquiring the product information, Upon receiving an onboarding request from the first user, The system according to claim 1, further configured to output a product information graphical user interface and to request the first user to provide product information of the said product.

4. When acquiring the product information, The system outputs an upload graphical user interface and requests the first user to provide additional product information and upload the product. The additional product information and the product uploaded by the first user are retrieved. The system according to claim 1, further configured to provide the additional product information of the product for verification by at least one second user.

5. When acquiring the status information, Output an onboarding test graphical user interface to at least one second user, which includes information about one or more onboarding tests of the product in the test environment. The system according to claim 1, further configured to obtain the status information of one or more onboarding tests from the at least one second user.

6. The system according to claim 5, further configured to provide the first user with access to update the product in response to the status information, based on an access request received from the first user or the at least one second user.

7. When evaluating the product, A query input requesting information from the second user relating to one or more onboarding tests is received from at least one of the second users. The system according to claim 6, further configured to output the query input to the first user.

8. The system according to claim 1, further configured to output to the first user an onboarding test graphical user interface including the status information of the one or more onboarding tests.

9. The aforementioned status information, Onboarding test completion status, Onboarding test events and / or results, and The system according to claim 8, comprising at least one of the performance statuses of the product during one or more onboarding tests.

10. A method for onboarding a virtualized network service, which is performed on a computer that communicates with multiple communication devices of multiple users, and which enrolls a service provider in a centralized marketplace, Receiving a user request from a first user to access the aforementioned centralized marketplace, Based on the received user request, the first user is authenticated, Based on a prescribed onboarding policy, the product information of the authenticated first user, which is a virtualized network service for telecommunications networks, is obtained. Acquire the product in order to perform one or more onboarding tests for the product in the test environment of the centralized marketplace, based on the predetermined onboarding policy. Obtaining status information for one or more of the aforementioned onboarding tests, A method comprising, based on the results of one or more of the aforementioned onboarding tests, publishing the product on the centralized marketplace for purchase.

11. The aforementioned authentication is From among a number of predetermined roles, including the roles of a vendor and a customer, it is determined that the role of the first user registered in the centralized marketplace is the role of the vendor. The method according to claim 10, further comprising providing access to the centralized marketplace based on the determined role of the first user being the role of the vendor.

12. Obtaining the aforementioned product information Receiving an onboarding request from the first user, The method according to claim 10, further comprising outputting a product information graphical user interface and requesting the first user to provide product information for the said product.

13. To obtain the aforementioned product, To output an upload graphical user interface and provide additional product information, and to request the first user to upload the product, To obtain the additional product information and the product uploaded by the first user, The method according to claim 10, further comprising providing the additional product information of the product for verification by at least one second user.

14. Obtaining the aforementioned status information Outputting an onboarding test graphical user interface to at least one second user, which includes information about one or more onboarding tests of the product in the test environment; The method according to claim 10, further comprising obtaining the status information of one or more onboarding tests from the at least one second user.

15. The further includes providing the first user with access to update the product in response to the status information, based on an access request received from the first user or the at least one second user, The method according to claim 14.

16. To evaluate the aforementioned product, Receiving query inputs from at least one second user requesting information from the second user relating to one or more onboarding tests, The method according to claim 15, further comprising outputting the query input to the first user.

17. Further comprising outputting an onboarding test graphical user interface, including the status information of one or more onboarding tests, to the first user, The method according to claim 10.

18. The aforementioned status information, Onboarding test completion status, Onboarding test events and / or results, and The method according to claim 17, comprising at least one of the performance statuses of the product during the one or more onboarding tests.

Images