Method and system for automation and role-based control in a marketplace - Patent Application 20070122999

Abstract

A method and system for automated role-based control of a centralized marketplace for products, the method including: mapping a first role of a plurality of predefined roles of a marketplace participant to a first user based on first registration information; mapping a second role of the plurality of predefined roles of the marketplace participant to a second user based on second registration information; executing a first microservice for the first user based on the first role of the first user, the first role being a developer role; and executing a second microservice for the second user based on the second role of the second user, the second role being a customer role, the first microservice including a publishing process for publishing the first user's product on the centralized marketplace, and the second microservice including a deploying process for deploying the product to the second user's infrastructure.

Description

[Technical Field]

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS This application claims priority to Indian Provisional Application No. 202241049596, filed on August 30, 2022, the disclosure of which is incorporated herein by reference in its entirety.

[0002] Methods and systems consistent with exemplary embodiments of the present disclosure relate to automation and role-based control of end-to-end processes in a centralized marketplace. [Background technology]

[0003] Handling end-to-end processes such as publishing, deploying, and operating products or services is one of the most complex and tedious processes for market participants. Related technologies do not provide an end-to-end solution for integrating end-to-end processes such as publishing, deploying, and operating products or services in a centralized marketplace with all market participants (i.e., operators and customers on one side and developers and vendors on the other side). Therefore, guiding all user roles and providing the necessary information when many users with different roles are involved is a difficult challenge. To this end, related technologies separate marketplace platforms and provide different platforms for different user roles. For example, in related technologies, product and service procurement is separated into a procurement marketplace platform where only the marketplace role is provided, where vendors and customers fulfill their specific roles (i.e., presenting, selling, and purchasing products and services), excluding the platform administrator.

[0004] However, in a highly fragmented market where different customers (e.g., network operators) require different levels of information and formats from developers (e.g., vendors) to onboard products or services, meeting the information needs of their respective business partners is a difficult challenge for both customers and vendors.

[0005] As a result, in the related art, it is extremely difficult for all participants in a marketplace (e.g., vendors, customers, developers, administrators, reviewers, etc.) to immediately respond with the necessary level of information to seamlessly onboard (publish) a product or seamlessly deploy a published product into, for example, a network operator's existing infrastructure (e.g., telecommunications infrastructure). For example, in the related art, the task of integrating a network service into a network operator's existing telecommunications infrastructure is complex and can require a lead time of between six and ten months, involving multiple interaction steps (e.g., high levels of design clearance, countless configuration evaluations, etc.) that involve a high degree of planning and management effort. When the vendor is not the developer, multi-entity communication during product or service integration becomes even more difficult and prone to human and technical error. Therefore, communication between market participants in the related art has been slow and burdensome.

[0006] Furthermore, the significant effort required to deploy, for example, a network service on an existing telecommunications infrastructure is particularly inefficient if a vendor (or customer) discovers that the product or service is incompatible or does not function as expected only after the product or service has been integrated into the existing infrastructure. In the related art, such an undesirable outcome leaves the vendor with no choice but to, for example, halt the integration of the network service (i.e., withdraw the offered product and service from the procurement platform until the shortcomings are resolved by the developer) and find an appropriate solution to the problem. To this end, in the related art, the vendor (i.e., the developer, if the vendor is not the developer) requires the cooperation of the network operator (i.e., the customer) to, for example, schedule a site visit to install new infrastructure or upgrade the existing infrastructure (e.g., telecommunications infrastructure) so that it is compatible with the offered product or service. In some cases, the developer may end up redeveloping the product and service to be compatible with the existing infrastructure (e.g., telecommunications infrastructure) of another vendor (e.g., a network infrastructure manufacturer). In other cases, the dilemma may force the customer to select another developer (eg, vendor) for deployment of the product or service.

[0007] In either case, the complex interplay of roles to achieve successful procurement of a product or service and its deployment issues can further delay the delivery of products and services, resulting in wasted human resources and inevitable frustration, making it unsatisfactory for all participants in the marketplace.

[0008] Apart from the above-mentioned disclosure issues on the developer side, the actual performance of the products and services offered by the developer may vary depending on the environment and infrastructure. As a result, in the related art, it is very difficult for a customer (e.g., a network operator) to accurately evaluate the actual performance of a product or service until the product or service is deployed in an existing infrastructure (e.g., a telecommunications infrastructure), which places the risk of procurement solely on the customer. Summary of the Invention

[0009] According to example embodiments, a method and system for marketplace automation and role-based control is provided. Marketplace automation and role-based control enables all participants in a centralized marketplace to fulfill a role(s) within one marketplace platform without separating the marketplace platform by role (e.g., without separating it into a procurement system, a technology evaluation system, etc. for both developers and customers). To this end, the automated, role-based controlled marketplace provides a test system for product onboarding (publishing) on ​​the developer side and a test system for product deployment on the customer side.

[0010] In particular, the method and system enable a standardized and guided end-to-end process (e.g., a unified sign-up process for all participants, a standardized publishing process for developers (e.g., vendors), and a standardized deployment process for customers (e.g., network operators) to provide a common and easy-to-review standard / format for each market participant). A participant's role(s) depend on the market participant's registration information, and each user can be mapped (i.e., assigned) to one or more roles based on the user information, enabling an easy-to-operate environment (e.g., a role-based workflow environment) within the centralized marketplace and task sharing among users according to their specific roles (e.g., a vendor performing tests to publish a suitable product or service for a customer, a customer performing tests for product and service deployment based on the specifications of an existing telecommunications infrastructure, etc.). Role-based task sharing has the advantage of minimizing the time to publish and deploy a product or service (e.g., a software product) based on a two-sided lab (test) environment (i.e., separate test environments for developers and customers) within the centralized marketplace, eliminating human error. For example, when a vendor or developer registers with the marketplace, the marketplace platform determines their role and enables uploading and testing of products and services via public microservices in a guided manner that allows the vendor or developer to test the product or service in a predetermined test environment. For this purpose, the developer tests the product or service in a developer lab environment (public test environment) provided by either a customer in the marketplace or a platform operator (e.g., a network operator or platform administrator can determine the developer (public) test environment for the product or service). Meanwhile, for example, when a customer (e.g., a network operator) registers with the marketplace.The marketplace platform determines its role in the marketplace (e.g., reviewer, customer, administrator, etc.) and enables customers to test products or services in a deployment test environment. A customer (e.g., a customer or platform administrator) can determine a development test environment for a product or service within the marketplace or upload a product or service to the customer's existing telecommunications infrastructure to monitor the operation of the product or service in real-world conditions.

[0011] As a result, integrated testing and monitoring of products and services within the marketplace has the advantage that product performance, exact configuration, etc. can be determined before purchasing or during a trial period for the product or service. This role-based and controlled execution of end-to-end processes within the marketplace has the advantage of automating procurement management and creating a level playing field for all market participants, reducing risk and increasing speed of deployment.

[0012] According to an example embodiment, a system for automated role-based control of a centralized marketplace for products comprises a memory storing instructions and at least one processor, wherein the at least one processor maps a first role of a plurality of predefined roles of marketplace participants to a first user based on first registration information obtained from the first user, maps a second role of the plurality of predefined roles of marketplace participants to a second user based on second registration information obtained from the second user, and maps a first role of the first user to a developer based on a first role of the first user, the first role being a developer role. and at least one processor configured to execute instructions for executing at least one first microservice of the centralized marketplace for a user and for executing at least one second microservice of the centralized marketplace for a second user based on a second role of the second user, the second role being a customer role, wherein the at least one first microservice includes a publishing process for publishing a product of the first user on the centralized marketplace and the at least one second microservice includes a deployment process for deploying the product to a telecommunications infrastructure of the second user.

[0013] The at least one processor may be further configured to execute instructions to obtain first registration information from the first user and second registration information from the second user via a first screen for registering the user with the centralized marketplace, receive first login credentials of the first user and second login credentials of the second user via a second screen for logging in to the centralized marketplace, and grant different access rights to the first user and the second user based on the first role and the second role.

[0014] The at least one processor may be further configured to execute instructions for executing at least one first microservice to receive a product artifact that is a software application, assign the artifact to at least one public test environment for testing the product, obtain results of the testing, and present the results to a first user based on a first role.

[0015] At least one public testing environment will be hosted by the operator of the centralized marketplace.

[0016] Products may include enterprise software for telecommunications operators and virtualized network services.

[0017] The at least one processor may be further configured to execute instructions for executing at least one second microservice to receive a product artifact that is a software application, assign the artifact to at least one deployment test environment to test the first user's product, obtain results of the testing, and present the results to a second user based on a second role.

[0018] At least one deployment test environment is hosted by the operator of the centralized marketplace.

[0019] The products include published products of users mapped to the first role that have been tested in at least one public test environment and approved for publication.

[0020] The at least one processor is further configured to execute instructions to map a third role among the plurality of predetermined roles of the marketplace participant, the third role being a reviewer role, to a third user, and execute at least one third microservice of the centralized marketplace for the third user based on the third role of the third user, wherein the at least one third microservice includes a review process for reviewing products submitted by the first user for publication.

[0021] The at least one processor may be further configured to execute instructions to execute the at least one fourth microservice of the centralized marketplace for the fourth user based on the fourth role of the fourth user, the fourth role being an administrator role, and the at least one fourth microservice may include an approval process, wherein the at least one processor may be further configured to execute instructions to execute the at least one fourth microservice to: register the first user to have the first role based on the obtained first registration information and approval by the fourth user; register the second user to have the second role based on the obtained second registration information and approval by the fourth user; approve registration of the third user to have a third role among the plurality of predetermined roles, the third role being a reviewer role, based on approval by the fourth user; and approve publication of the first user's product on the marketplace based on the publication process and the review process performed by the third user.

[0022] According to an example embodiment, a method for automated role-based control of a centralized marketplace for products includes mapping a first role of a plurality of predefined roles of marketplace participants to a first user based on first registration information obtained from the first user; mapping a second role of the plurality of predefined roles of marketplace participants to a second user based on second registration information obtained from the second user; executing at least one first microservice of the centralized marketplace for the first user based on the first role of the first user, the first role being a developer role; and executing at least one second microservice of the centralized marketplace for the second user based on the second role of the second user, the second role being a customer role, wherein the at least one first microservice includes a publishing process for publishing products of the first user on the centralized marketplace and the at least one second microservice includes a deployment process for deploying products to a telecommunications infrastructure of the second user.

[0023] The method may include obtaining first registration information from a first user and second registration information from a second user via a first screen for registering the user with the centralized marketplace; receiving first login credentials of the first user and second login credentials of the second user via a second screen for logging into the centralized marketplace; and granting different access rights to the first user and the second user based on the first role and the second role.

[0024] Executing the at least one first microservice may include receiving a product artifact that is a software application, assigning the artifact to at least one public test environment to test the product, obtaining results of the testing, and presenting the results to a first user based on a first role.

[0025] At least one public testing environment will be hosted by the operator of the centralized marketplace.

[0026] Products may include enterprise software for telecommunications operators and virtualized network services.

[0027] Executing the at least one second microservice may include receiving artifacts for a product that is a software application, assigning the artifacts to at least one deployment test environment to test the first user's product, obtaining results of the testing, and presenting the results to the second user based on the second role.

[0028] At least one deployment test environment is hosted by the operator of the centralized marketplace.

[0029] The products may be placed in at least one public test environment for testing the first user's products within the centralized marketplace and may include published products of users mapped to the first role.

[0030] The method further includes mapping a third role among the plurality of predetermined roles of the marketplace participant, the third role being a reviewer role, to a third user; and executing at least one third microservice of the centralized marketplace for the third user based on the third role of the third user, wherein the at least one third microservice includes a review process for reviewing the product submitted by the first user for publication.

[0031] The method further includes mapping a fourth role among the plurality of predetermined roles of the marketplace participant, the fourth role being an administrator role, to a fourth user; and executing at least one fourth microservice of the centralized marketplace for the fourth user based on the fourth role of the fourth user, wherein the at least one fourth microservice includes an approval process including: registering the first user to have the first role based on the obtained first registration information and an approval by the fourth user; registering the second user to have the second role based on the obtained second registration information and an approval by the fourth user; approving registration of the third user to have a third role among the plurality of predetermined roles, the third role being a reviewer role, based on the approval by the fourth user; and approving publication of the first user's product on the marketplace based on the publication process and the review process executed by the third user.

[0032] Additional aspects will be set forth in part in the description that follows, and in part will be apparent from the description, or may be learned by practice of presented embodiments of the present disclosure.

[0033] The features, advantages, and significance of exemplary embodiments of the present disclosure are described below with reference to the accompanying drawings, in which like reference numerals refer to like elements. [Brief explanation of the drawings]

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

[0035] [Figure 2] FIG. 1 illustrates a block diagram of a centralized marketplace according to one or more embodiments.

[0036] [Figure 3]FIG. 1 illustrates a block diagram of a security system for providing role-based access to a centralized marketplace according to one or more embodiments.

[0037] [Figure 4] 1 illustrates user roles and mapping to permissions according to one or more embodiments.

[0038] [Figure 5] FIG. 1 illustrates a block diagram of end-to-end role-based microservices in a centralized marketplace according to one or more embodiments.

[0039] [Figure 6] 1 illustrates a flowchart of a role-based sign-up process for a marketplace platform according to one or more embodiments.

[0040] [Figure 7] 1 illustrates a flowchart of a role-based product publishing process for a first-time user on a marketplace platform according to one or more embodiments.

[0041] [Figure 8] 1 illustrates a flowchart of a role-based product publishing process for authorized (published) users on a marketplace platform according to one or more embodiments.

[0042] [Figure 9] 1 illustrates a flowchart of a role-based deployment process on a marketplace platform according to one or more embodiments.

[0043] [Figure 10] 1 illustrates a flowchart of a role-based operational process on a marketplace platform according to one or more embodiments.

[0044] [Figure 11] FIG. 1 is a diagram of an example environment in which the systems and / or methods described herein may be implemented.

[0045] [Figure 12] FIG. 2 is a diagram of exemplary components of a device, according to one embodiment. DETAILED DESCRIPTION OF THE INVENTION

[0046] The following detailed description of exemplary embodiments refers to the accompanying drawings. The foregoing disclosure provides illustration and description, but is not intended to be exhaustive or to limit implementations to the precise form disclosed. Modifications and variations are possible in light of the above disclosure or may be acquired from practice of the implementations. Moreover, one or more features or components of one embodiment may be incorporated into or combined with another embodiment (or one or more features of another embodiment). Additionally, in the flowcharts and descriptions of operations provided below, it is understood that one or more operations may be omitted, one or more operations may be added, one or more operations may be performed (at least partially) concurrently, and the order of one or more operations may be permuted.

[0047] 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 intended to limit the implementation. Thus, the operation and behavior of the systems and / or methods are described herein without reference to specific software code, and it will be understood that software and hardware can be designed to implement the systems and / or methods based on the description herein.

[0048] Although particular combinations of features are recited in the claims and / or disclosed herein, these combinations are not intended to limit the disclosure of possible implementations. Indeed, many of these features may be combined in ways not specifically recited in the claims and / or disclosed herein. Although each dependent claim listed below may depend directly on only one claim, the disclosure of possible implementations includes each dependent claim in combination with all other claims in the claim set.

[0049] No element, act, or instruction used herein should be construed as critical or required unless expressly stated to be so. Also, as used herein, the articles "a" and "an" are intended to include one or more items and may be used interchangeably with "one or more." Where only one item is intended, the term "one" or similar language is used. Also, as used herein, terms such as "has," "have," "having," "include," and "including" are intended to be open-ended terms. Furthermore, the phrase "based on" is intended to mean "based at least in part on," unless specifically stated otherwise. Furthermore, phrases such as "at least one of [A] and [B]" or "at least one of [A] or [B]" should be understood to include A only, B only, or both A and B.

[0050] Throughout this specification, references to "one embodiment," "an embodiment," "a non-limiting exemplary embodiment," or similar language mean that a particular feature, structure, or characteristic described in connection with the illustrated embodiment is included in at least one embodiment of the solution. Thus, throughout this specification, the phrases "in one embodiment," "in an embodiment," "in one non-limiting exemplary embodiment," and similar language may, but do not necessarily, all refer to the same embodiment.

[0051] Furthermore, the features, advantages, and characteristics described in the present disclosure 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 present disclosure can be practiced without one or more of the specific features or advantages of a particular embodiment. In other instances, additional features and advantages may be recognized in certain embodiments that may not be present in all embodiments of the present disclosure.

[0052] In one implementation of the disclosure described herein, a display page can include information residing in the memory of a computing device, and this information can be transmitted from the computing device to a database center or vice versa over a network. The information can be stored in memory at the computing device, in data storage at the edge of the network, or in a server at the database center. A computing device or a mobile device can accept non-transitory computer-readable media that can contain instructions, logic, data, or code that can be stored in persistent or temporary memory on the mobile device or that can affect or initiate actions by the mobile device. Similarly, one or more servers can communicate with one or more mobile devices over a network and can transmit computer files residing in memory. The network can 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.

[0053] Any description of a computing or mobile device may also apply to any type of networked device, including, but not limited to, mobile devices such as mobile phones (e.g., any "smartphone"), personal computers, server computers, or laptop computers, and telephones, personal digital assistants (PDAs), roaming devices such as network-attached roaming devices, wireless devices such as wireless email devices or other devices capable of wirelessly communicating with a computer network, or any other type of networked device that may communicate over a network and process electronic transactions. Any description of any mobile device mentioned may also apply to other devices, such as short-range ultra-high frequency (UHF) devices, near-field communication (NFC), infrared (IR), and devices including Wi-Fi capabilities, among others.

[0054] "Software," "application," "app," and "firmware" and similar words and terms may include any non-transitory computer-readable medium that stores a program that, when executed by a computer, causes the computer to perform a method, function, or control operation.

[0055] "Network" and similar phrases and terms may include one or more data links that enable the transport of electronic data between computer systems and / or modules. When information is transferred or provided to a computer over a network or another communications connection (either hardwired, wireless, or a combination of hardwired or wireless), the computer uses the connection as a computer-readable medium. Thus, by way of example and not limitation, a computer-readable medium may also include a network or data link that may be used to carry or store desired program code means in the form of computer-executable instructions or data structures and that may be accessed by a general-purpose or special-purpose computer.

[0056] Similar phrases and terms such as "portal" or "terminal" may include an intranet page, an Internet page, locally residing software or application, a mobile device graphical user interface, or a digital presentation for a user. A portal may also be any graphical user interface for accessing the various modules, components, features, options, and / or attributes of the present disclosure described herein. For example, a portal may be a web page accessed with a web browser, a mobile device application, or any application or software residing on a computing device.

[0057] Exemplary embodiments disclosed herein relate to a centralized marketplace for products and services. While the exemplary embodiments refer to telecommunications-related products and services, it is understood that the disclosure is not limited thereto and the marketplace may be for telecommunications and / or non-telecommunications-related products. For example, the marketplace may offer applications and services generally targeted to businesses (e.g., customer service-related applications, inventory management applications, financial forecasting or planning applications, accounting applications, etc.).

[0058] FIG. 1 illustrates a general network architecture diagram, according to one or more embodiments. Referring to FIG. 1, users 110, 120, and 130 can bidirectionally communicate with a central server or application server 100 over a secure network, according to one or more embodiments. Additionally, users 110, 120, and 130 can also bidirectionally communicate directly with each other via a marketplace platform network system, according to one or more embodiments. Here, users 110 can be any type of vendor or service provider, such as Vendor A, Vendor B, or Vendor C, offering similar, identical, or different services or products to either user 120 or user 130 with respect to a network or service operator. In particular, users 110 can provide any type of telecommunications-related service or product, such as cellular service network deployment, network capacity updates, operational monitoring, data analysis and reporting, and any other suitable service. Each of users 110 can communicate with server 100 via a respective terminal or portal. The users 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 110 or user 130. Here, user 110 or 120 may be, among others, any type of 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 the users 120 may communicate with the server 100 through a respective terminal or portal.Users 130 may 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 end users who purchase and / or receive telecommunications network related services of user 110 or user 120. Each of users 130 may communicate with server 100 through a respective terminal or portal.

[0059] 1 , the central server 100 of the marketplace platform system, according to one or more embodiments, can further be in bidirectional communication with an administrative terminal / dashboard 140. Here, the administrative terminal / dashboard 140 can provide users 110, 120, and 130, or a sales or content / product creation team, with various tools for managing various customers / end-users and customer leads, including, among other things, creating, editing, and promoting promotional campaigns, advertisements, offers, and ordering options for various types of telecommunications network services or products to customers and other users of the marketplace platform, according to one or more embodiments. In addition, the administrative terminal / dashboard 140 can 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 be in bidirectional communication with a database / third-party server 150. Here, the server 150 may provide various types of data storage (e.g., cloud-based storage), web services, content creation tools, data streams, data feeds, and / or various types of third-party support services to the marketplace platform central server 100. However, within the scope of the present disclosure described herein, it is contemplated that the network services marketplace platform processes and systems according to one or more embodiments may include any type of general network architecture.

[0060] With further reference to FIG. 1, one or more of the servers or terminals of elements 100-150 may include a personal computer (PC), a printed circuit board with a computing device, a minicomputer, a mainframe computer, a microcomputer, a telephone computing device, a wired / wireless computing device (e.g., a smartphone, a personal digital assistant (PDA)), a laptop, a tablet, a smart device, a wearable device, or any other similarly functional device.

[0061] 1, one or more of the 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 components of a device may be communicatively coupled via a bus.

[0062] A bus may comprise one or more components that enable communication between a set of components, such as one or more of the servers or terminals of elements 100-150. For example, a bus may be a communications bus, a crossover bar, a network, etc. A bus may be implemented using a single or multiple (two or more) connections between a set of components, such as one or more of the servers or terminals of elements 100-150. The present disclosure is not limited in this respect.

[0063] One or more of the servers or terminals of elements 100-150 may include one or more processors. The one or more processors may be implemented in hardware, firmware, and / or a combination of hardware and software. For example, the one or more processors may include a central processing unit (CPU), a graphics processing unit (GPU), an accelerated processing unit (APU), a microprocessor, a microcontroller, a digital signal processor (DSP), a field-programmable gate array (FPGA), an application-specific integrated circuit (ASIC), a general-purpose single-chip or multi-chip processor, or other programmable logic device, 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. The 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 in conjunction with a DSP core, or any other such configuration. In some embodiments, particular processes and methods may be performed by circuitry that is 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-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-150.

[0065] One or more of the servers or terminals of elements 100-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 another type of dynamic or static storage device. The memory may store information and / or instructions for use (e.g., execution) by the processor.

[0066] A storage component of one or more of the servers or terminals of elements 100-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-150. For example, the storage component may include a hard disk (e.g., a 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-transitory computer-readable medium, along with a corresponding drive.

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

[0068] The server or terminal output components of any one or more of elements 100-150 may include one or more components that may 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-150 may further comprise a communications interface. The communications interface may include a receiver component, a transmitter component, and / or a transceiver component. The communications interface may enable one or more of the servers or terminals of elements 100-150 to establish connections and / or transfer communications with other devices (e.g., a server, another device). Communications may be enabled via a wired connection, a wireless connection, or a combination of wired and wireless connections. The communications interface may enable one or more of the servers or terminals of elements 100-150 to receive information from and / or provide information to another device. In some embodiments, the communication interface may provide for communication with another device over a network such as a local area network (LAN), a wide area network (WAN), a metropolitan area network (MAN), a private network, an ad-hoc network, an intranet, the Internet, an optical fiber-based network, a cellular network (e.g., a fifth generation (5G) network, a long-term evolution (LTE) network, a third generation (3G) network, a code division multiple access (CDMA) network, etc.), a public land mobile network (PLMN), a telephone network (e.g., a public switched telephone network (PSTN)), etc., and / or combinations of these or other types of networks.Alternatively, or in addition, the communication interface may provide for communication with another device via a device-to-device (D2D) communication link, such as FlashLinQ, WiMedia, Bluetooth, ZigBee, Wi-Fi, LTE, 5G, etc. 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, etc.

[0070] FIG. 2 illustrates a centralized marketplace and trading platform system according to one or more embodiments. Referring to FIG. 2 , marketplace platform module or portal 200 may be a portal for the marketplace platform and may include a Customer Management System (CMS) delivery node module 202 in bidirectional communication with a Business Support System (BSS) product stack module or portal 210 (which may include any one or more of modules 212-220 shown in FIG. 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 through communication with CMS delivery node module or portal 202. In some embodiments, user / customer module or portal 224 may also communicate with a Content Distribution Network (CDN) module or portal, which further communicates with modules or portals 202 and 206. In some embodiments, the CMS delivery node module or portal 202 can handle a first customer interaction when the customer accesses one or more embodiments of the marketplace platform 200. For example, the CMS delivery node module or portal 202 can receive a request from the customer's user terminal or portal 224 to browse available products / services, retrieve product / service data from a product catalog, and generate / display a graphical user interface representation (e.g., columns, lists, etc.) showing available products / services of the marketplace platform or one or more service providers or vendors.Additionally, product / content team modules or portals 222 (e.g., terminals or client devices of sellers, service providers, vendors, etc.) may also communicate with the marketplace platform module or portal through communication with the CMS integration module or portal 206. In this case, the CMS integration module or portal 206 may generate and / or display graphical user interfaces related to sellers, service providers, vendors, etc. (e.g., user interfaces for listing products for sale, configuring sales listings, creating or editing customer or product configuration profiles, facilitating sales activities, etc.).

[0071] 2 , the marketplace platform module or portal 200, according to one or more embodiments, may also include a BSS product stack module or portal 210. Here, module 210 may further include a product catalog module or portal 212, which may be a repository / data storage for storing product / service data. Additionally, module 212 may also include and store product / service-level promotional offers, or price drop indicators or events associated with one or more stored products / services. Module 210 may also include a customer information management (CIM) module or portal 214, which may be a repository / data storage for storing customer information (e.g., name, contact information, ID, customer interest list, customer-level promotional offers or price drop events, etc.). Module 210 may also include a customer interaction management module or portal 216, which may be a repository / data storage that stores information about customer interactions with the marketplace platform (e.g., customer interaction history with interactive elements of a graphical user interface (GUI), communications between the customer and service provider(s) or other customer(s), etc.), according to one or more embodiments.

[0072] Continuing with reference to FIG. 2 , module 210 may also include a billing / invoicing module or portal 218 that stores information associated with customer billing / invoicing for services offered on the marketplace platform (e.g., previously generated 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, promotions for specific types of customers, sales history analysis, etc.). In some embodiments, module 220 may identify data related to sales activities and user experiences, retrieve / collect data from external data storage or from any of 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, module 220 may also communicate with a product / content team module or portal 222, which may be a user (e.g., a vendor / service provider) or a portal for such users who want to promote / sell network services. Additionally, the product / content team module or portal 222 can be a lead conversion system, or a user wanting to convert customer leads, analyze customer activity, and facilitate pre-sales and post-sales activities and marketing campaigns.

[0073] Continuing with reference to FIG. 2 , marketplace platform module or portal 200 can also communicate with orchestrator module 230 (e.g., via an application programming interface (API)). In particular, any one or more of modules or portals 212-220 of modules 210 can communicate with and / or be supported by any one of modules or portals 238-240 of modules 230. Specifically, orchestrator module 230 can include product / service management module 238 and cloud orchestration module 240. In particular, any of modules 238-240 can be containerized and stored in a “cloud” or cloud cluster on external servers and databases. In some embodiments, product / service management module 238 comprises a repository / data storage that stores products and services offered 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 and offer products and services to users of the network services marketplace platform.

[0074] 3 illustrates a block diagram of a security system 310 according to one or more embodiments. The security system 310 controls role-based user access to the centralized marketplace 320 according to one embodiment. To this end, the security system 310 performs onboarding (i.e., onboarding or registration) of new users to the centralized marketplace 320 by registering the user with one of a plurality of predefined roles, each associated with a different set of access rights and / or privileges. The security system 310 further identifies the user's previously registered role and grants access to the centralized marketplace 320 based on that role and its associated rights / privileges.

[0075] 3 , a security system 310 communicates with (or may be included in) a centralized marketplace 320 and communicates with at least one user module 301 (i.e., a user terminal or device). In an exemplary environment, the security system 310 can connect to the at least one user module 301 and control role-based user access to the centralized marketplace 320. In another exemplary environment, the at least one user module 301 can communicate with the centralized marketplace 320, and the security system 310 communicates with the centralized marketplace 320 to control role-based user access to the centralized marketplace. The security system 310 includes an identity management module 311, a user management module 312, and a role-based access control module 313.

[0076] As described above, the security system 310 performs onboarding of new users to the centralized marketplace 320. In particular, the security system 310 receives registration information for the new user from the user module 301, where the registration information includes the user's selection of a role from among a plurality of predefined roles (e.g., developer, vendor, customer, etc.). The role-based access control module 313 of the security system 310 can identify privileges associated with the selected role and provide the privileges to a system user (e.g., the user and a member of the administrative team, a security administrator, etc.) for approval. According to another embodiment, the role-based access control module 313 can provide the selected role to the system user for approval. Based on the approval of the selected role, the identity management module 311 can generate (or receive from the user) a user ID for the user and provide the ID to the user management module 312. The user management module 312 can map (i.e., assign) the user ID to the approved user's role and associated privileges. According to other embodiments, at least some roles may be automatically assigned or approved to the user, for example, based on predefined rules or keywords included in the registration information. The mapped role may then be stored in association with the user ID (eg, stored in a database or storage of the security system 310).

[0077] Additionally, as described above, security system 310 further identifies a user's previously registered role and grants access to centralized marketplace 320 based on the role and its associated rights / privileges. In this regard, based on marketplace 320 receiving login credentials (e.g., user ID and password) of a user accessing marketplace 320 (e.g., via marketplace 320's login page or user interface), the credentials are provided from marketplace 320 to user management module 312. User management module 312 retrieves (e.g., from storage) the registered role mapped to the user ID and provides it to marketplace 320 (e.g., generates / provides a GUI including functionality and information associated with the user's privileges according to the user's role and displays the GUI to the user) so that the marketplace provides access according to the rights / privileges associated with the role.

[0078] Based on the user's role, the user module 301 can be similar to the user / customer module 224 of Figure 2. Additionally, based on the user's role, the user module 301 can also be similar to the product / content team module 222 of Figure 2. Communication between the user module 301 and the marketplace platform module 320 can be similar to communication between the user / customer module 224 and the product / content team module 222 in the marketplace platform 200 of Figure 2, and the security system 310 controls role-based user access to the marketplace 320.

[0079] 3, marketplace 320 includes product and service testing module 330. Product and service testing module 330 may be a role-based system emulator for virtualizing a network operator's public test environment or telecommunications infrastructure to provide a secure test environment (e.g., a test environment isolated from the network operator's existing telecommunications infrastructure) for testing products (e.g., network services) to be published or deployed within the centralized marketplace.

[0080] For example, product and service testing module 330 may include security testing, application testing, integration testing, etc. Here, security testing can ensure that a product meets one or more predetermined security policies (e.g., industry-standard security policies). For example, testing can be performed on all images, configuration files, Helm charts, etc., each time a user uploads them to the marketplace. Security checks can include image scanning and test results, based on which a user (e.g., a vendor) can proceed with installing the application in their respective environment. Security checks can further include validating configuration files and Helm charts for proper indentation (i.e., to ensure zero indentation errors) and verifying whether any credentials are exposed as plain text.

[0081] Integration testing can validate and clarify integration between a product (e.g., a vendor application) and other dependent services such as monitoring, performance, fault, inventory control, etc. In an exemplary embodiment, integration testing can include integrating an application with one or more specific services (e.g., inventory control, monitoring, ticketing, etc.), verifying valid connections of the integrated application to these services, and verifying whether the application is reachable within a particular cluster, for example, via ping, telnet, ssh, etc.

[0082] Application testing can allow users (e.g., vendors) to use their own specific test scripts, which can be triggered as part of pre- or post-installation of the vendor's product (application). For this purpose, users can upload different types of scripts (e.g., yaml, shell, json, python, etc.) to test the application. These scripts can be stored in a specific storage location from which developers or operations can initiate application testing.

[0083] In an exemplary embodiment, product and service testing module 330 may be or include a system emulator for virtualizing a telecommunications infrastructure for developers (e.g., vendors) testing their products or services in order to publish them in a centralized marketplace.

[0084] In another exemplary embodiment, product and service testing module 330 may be or include a system emulator for virtualizing a telecommunications infrastructure for a customer (e.g., a network operator) or platform administrator testing products or services for deploying published products on an existing telecommunications infrastructure.

[0085] According to an exemplary embodiment, role-based user access and role-based type tests performed on product and service test module 330 may be controlled by security system 310 or may be subject to roles / privileges registered and managed by security system 310 as described above.

[0086] According to another exemplary embodiment, security system 310 may comprise or be communicatively connected to an operations support system that facilitates or enables the creation of marketplace roles and / or the configuration of permissions (i.e., privileges) for each role.

[0087] User roles and permissions (i.e., predefined roles and permissions) may include at least one of: a visitor, who can browse the landing place and access the marketplace platform's leap courses or tutorials; a developer, who can browse and publish telecommunications-related and non-telecommunications-related products and services (e.g., products such as software, virtualized network functions, etc.); an operator, who can browse products and services published in the marketplace and deploy new applications to the operator's existing telecommunications infrastructure, among other information; a reviewer, who can browse products and services published in the marketplace and review products and services requested by developers; and an administrator, who can browse all deployed and published products and services (e.g., software applications) and publish and deploy new products and services (e.g., software applications) in the marketplace. Furthermore, if the administrator is also an operator, the administrator can deploy new applications (i.e., products) from the marketplace to its existing telecommunications infrastructure. Furthermore, the above developer roles may further include a vendor role. A vendor may be a third-party seller of the developer's products and services or the developer himself.

[0088] 4 illustrates a mapping of users to roles and permissions, according to one or more embodiments. A user management module, a role-based access control module, and an identity management module. Referring to FIG. 4, each of a plurality of users is registered by the security system 310 with one or more roles from among a plurality of predefined roles. Each role is associated with a respective permission object that includes or defines the permissions or access rights of the corresponding role. For example, the plurality of predefined roles may include visitor, developer, operator, reviewer, and administrator, and the permissions associated with each role may be as shown in Table 1 below. [Table 1] Table 1. Roles and associated permissions

[0089] 5 illustrates a block diagram of end-to-end microservices 520 based on roles in a centralized marketplace, according to one or more embodiments. In this exemplary embodiment, the centralized marketplace and its various operations are provided by executing instructions embodied in a microservices architecture, i.e., an application architecture comprised of multiple independently executable services. It is understood that one or more other embodiments are not so limited and may utilize a different application or software design architecture (e.g., monolithic).

[0090] Referring to FIG. 5 , the centralized marketplace platform includes role-based end-to-end microservices 520. In an exemplary embodiment, role-based end-to-end microservices 520 may include sign-up microservice 521, publishing microservice 522, deployment microservice 523, and operations (i.e., application operations) microservice 524. Each of the above microservices may be provided as one or more microservices. As shown, different types of users (i.e., roles) may be involved in each process of each microservice 520. For example, all users are involved in the sign-up process, only users with a developer (e.g., vendor) role and a reviewer role are involved in the publishing process, and only users with at least one of an operator (e.g., customer) role, an administrator role, and a reviewer role are involved in the deployment and operations processes. Additionally, each microservice may provide a different set of operations and / or graphical user interfaces (GUIs) for the corresponding process based on the user's role (e.g., a public microservice may provide a first set of operations and GUIs to users with a developer role and a second set of operations and GUIs to users with a reviewer role, with at least some differences between the two sets).

[0091] The signup microservice 521 is configured to guide any marketplace participant through a signup process, allowing the marketplace participant to be onboarded and / or authenticated as a user of the marketplace (i.e., in a predefined user schema with predefined roles and privileges) in a standardized manner.

[0092] Publishing microservice 522 is configured to provide a secure and fast onboarding process for products and services to users with developer roles (e.g., vendors) for the marketplace. Publishing microservice 522 may include multiple security and validation tests that are run before finalizing the publication of products and services on the marketplace.

[0093] The deployment microservice 523 is configured to provide a secure and rapid deployment process of products and services to users with operator roles (e.g., customers) for the marketplace. The deployment microservice 523 may include multiple compatibility and performance tests that are performed before completing the deployment of the products and services on the operator's (e.g., customer's) existing system infrastructure (i.e., telecommunications infrastructure).

[0094] The operations (i.e., application operations) microservice 524 is configured to provide product and service monitoring and lifecycle control processes to operators (customers) in the marketplace. The operations microservice 524 may include multiple monitoring processes that are executed during the operation of products and services (e.g., during the operation of software applications on the operator's existing telecommunications infrastructure). For example, a user with an operator role can view the monitoring and maintenance status of existing products and services, and a user with a developer role (e.g., vendor) can offer maintenance / updates for products or services according to the lifecycle management information provided by the operations microservice 524 in the marketplace.

[0095] In an exemplary embodiment, publishing microservice 522 can generate and display GUIs that enable a user with a developer role to upload a product or service (e.g., a software application), product information, parameters, artifacts, etc. Additionally, publishing microservice can enable a user with a developer role to test a product in a testing environment for the developer (i.e., a public testing environment). By way of example, testing can be permitted based on approval by a user with a particular role (e.g., a reviewer role or an administrator role). The testing environment can be a staging environment (e.g., in a staging server(s)) or a sandbox environment associated with the marketplace. Once the developer successfully completes testing, the product or service (e.g., a software application) can be published in the marketplace. In an exemplary embodiment, a user with a reviewer role can be provided, via publishing microservice 522, one or more GUIs for monitoring testing (e.g., test results) and / or approving the publication of the product or service based on the test results.

[0096] In an exemplary embodiment, deployment microservice 523 can provide a user with an operator (e.g., customer) role with a set of operations and a GUI for deploying a published product or service from the marketplace. For example, deployment microservice 523 can enable a user with an operator role to select a published product or service (e.g., a software application) and upload it to a deployment test environment (e.g., a staging server). The deployment test environment can be provided within the marketplace platform or on the operator's (e.g., customer's) system infrastructure (e.g., an existing telecommunications infrastructure or its staging or test server(s)). For example, a user with one of the operator role (e.g., customer), reviewer role, and administrator role can test a product in the marketplace deployment test environment. In an exemplary embodiment, once a user with an operator role (e.g., customer) successfully completes the deployment test, the user with the operator role can deploy the product or service (e.g., software application) to the operator's existing telecommunications infrastructure (e.g., finalize the purchase, etc.). Alternatively, the deployment microservice 523 may enable users with a reviewer role to approve (e.g., provide operations and GUIs for) the deployment of a communications-related or non-communications-related product or service based on the results of deployment tests.

[0097] In an exemplary embodiment, operations (i.e., software application operations) microservice 524 can provide a user with an operator role with a set of operations and GUIs to connect to and select existing (e.g., deployed, purchased, licensed, etc.) products or services (e.g., software applications), monitor their lifecycle, and manage their maintenance. To this end, operations microservice 524 can connect to a monitoring environment provided by (or associated with) the marketplace. In an exemplary embodiment, users with a particular role (e.g., one of operator role, reviewer role, and administrator role) can access operations microservice 524 to manage the maintenance of existing products and services based on respective offers by users with developer role in the marketplace.

[0098] 6 illustrates a flowchart of a role-based sign-up process for a marketplace platform according to one or more embodiments. The method of FIG. 6 may be performed by the sign-up microservice described above (e.g., in conjunction with the security system described with reference to FIG. 3).

[0099] 6, the marketplace platform receives an access request via a user terminal / module in step 601. In an exemplary embodiment, the marketplace platform generates and presents a login page (e.g., in the form of a GUI) to the user, requesting the user to log in (i.e., provide authentication information such as a user ID and password).

[0100] In step 602, the marketplace platform determines whether the user requesting access to the marketplace platform is a registered user (e.g., the user clicks a "Register" button in the GUI or does not provide valid login credentials).

[0101] If the user is not a registered user (step 602: No), then in step 603 the marketplace platform generates and displays at least one GUI to guide the new user to provide the required information to register with the marketplace platform.

[0102] In step 604, the marketplace platform receives information for registering a new user (i.e., registration information) via the GUI. Upon receiving the registration information, the marketplace platform provides the registration information to the security system (e.g., the registration information may include a role selection from among a plurality of predefined roles, as described above).

[0103] In step 605, the security system identifies the user privileges for the marketplace (i.e., what is permissible for the user with respect to the marketplace) associated with the user's selected role. In an example embodiment, the role-based access control module 313 of FIG. 3 can provide the privileges and / or selected role to a marketplace administrator (e.g., a member of the user management team, a security administrator, etc.) for approval (e.g., based on business needs and security checks of the user requesting the role).

[0104] In step 606, based on the selected role being approved, an approval decision is provided to identity management module 312, which then generates (or obtains from the registration information) a user ID for the user and provides the user ID to user management module 312 of Figure 3. In an exemplary embodiment, a user with an administrator role (e.g., member of a user management team, security administrator, etc.) can approve the registered user's roles before role-based access control module 313 provides the registration information to identity management module 312. Alternatively, the security system may be configured to automatically assign at least some of the roles or automatically approve at least some of the roles for a user based on, for example, predetermined rules, keywords included in the registration information, etc.

[0105] In step 607, the user management module 312 maps the user ID to the user's approved role (e.g., an administrator-approved role or an automatically approved role) and associated privileges. In an exemplary embodiment, the security system provides the registered role mapped to the user ID to the marketplace platform (e.g., from the user management module 312 or storage) so that the marketplace platform provides access according to the rights / privileges associated with the role (e.g., generates / provides a GUI including functionality and information associated with the user's privileges according to the user's role and displays the GUI to the user). In an exemplary embodiment, the user onboarding process for the unregistered user may end in step 607. In an exemplary embodiment, the marketplace platform or security system may send a confirmation (including the generated user ID) to the newly registered user via email. In another exemplary embodiment, the marketplace platform or security system may generate and display a GUI that directs the newly registered user back to a login page and enters the user's credentials to enter the marketplace.

[0106] In step 608, the marketplace platform generates and displays a GUI to request login (user) credentials (e.g., user ID and password) from the user, whereupon a previously registered user ("Yes" in step 602) or a newly registered user (steps 603 through 607) can log into the marketplace.

[0107] In step 609, the marketplace platform provides login (user) credentials (eg, user ID) to a user management module of the security system.

[0108] In step 610, based on the login (user) credentials, the user management module obtains the user's information (eg, the user's role and associated privileges mapped to the user ID) and provides this information to the marketplace platform.

[0109] In step 611, based on the information received in step 610, the marketplace platform provides access in accordance with the rights / privileges associated with the role (e.g., generates / provides a GUI that includes functionality and information associated with the user's privileges in accordance with the user's role and displays the GUI to the user).

[0110] 7 illustrates a flowchart of a role-based product publishing process on a marketplace platform (e.g., for a user in the role of developer who does not have a previously published product on the marketplace) according to one or more embodiments. The method of FIG. 7 may be performed by the publishing microservice described above with reference to FIG. 5.

[0111] 7, in step 701, the marketplace platform generates and displays at least one GUI for engaging with registered users (i.e., the GUI is displayed only to registered users). In an exemplary embodiment, the GUI may include (or be included within) a landing page for registered users to initiate a product publication process for onboarding their products and services (e.g., software products) with a developer role (e.g., vendor). The landing page may be output upon successful login of a user (e.g., a user with a developer role) according to the method of FIG. 6.

[0112] In step 702, the marketplace platform obtains information (e.g., user input on a landing page) regarding whether the user wants to publish a new application or service to the marketplace or whether the user wants to access a previously published application in the user's workspace. If the user requests publication of a new application, the method proceeds to step 703. Conversely, if the user requests access to a previous workspace (e.g., to access and verify a previously published application), the method proceeds to step 712.

[0113] In step 703, the marketplace platform generates and displays a GUI for onboarding a product or service (e.g., a software product) on the marketplace. In an exemplary embodiment, the marketplace platform may unlock a workspace for a user with a developer role, allowing the user to upload and test artifacts, configuration files, etc. of the software product (i.e., application or service) to the workspace. In an exemplary embodiment, the marketplace platform may be configured to provide a workspace that may include a lab management portal for managing testing and release activities for a user with a developer role (e.g., vendor) in the marketplace. In another exemplary embodiment, the workspace may include a sandbox testing environment (e.g., a development environment) and a staging testing environment (e.g., a pre-production environment) on the marketplace platform.

[0114] Further, in an exemplary embodiment, the lab management portal may include an application programming interface (API) manager. Based on the API manager, third-party API developers can offer APIs to marketplace participants (e.g., users with a developer role). For example, users with a developer role can sign in to a workspace (e.g., the lab management portal) and select and subscribe to third-party APIs to leverage their products and services (e.g., software applications) in the marketplace. In an exemplary embodiment, the workspace (e.g., the lab management portal) can use industry-standard APIs, and each microservice (e.g., a microservice of a third party or a marketplace platform operator) can publish its API in an OpenAPI specification (i.e., Swagger format) for onboarding to the marketplace platform's API gateway.

[0115] At step 704, the marketplace platform generates and displays multiple GUIs (e.g., an onboarding wizard and / or one or more forms for publishing a new product that allow the user to onboard a product or service (e.g., a software product) with the marketplace) that allow the user to provide product information and upload the product to a workspace in the marketplace. Thus, at step 704, the marketplace platform can receive information about the product.

[0116] In step 705, the marketplace platform generates and displays multiple GUIs that allow the user to dimension hardware requirements within the marketplace workspace (i.e., the public microservices allow the user to select the hardware resources needed to test the product, for example, in a sandbox or staging environment). As an example, a marketplace operator may provide a hardware cluster for running products or services in a secure test environment at the marketplace. Thus, in step 705, the marketplace platform receives a dimensioning selection for the product or application from the user.

[0117] In step 706, the marketplace platform generates and displays a number of GUIs that allow users to upload artifacts for products and services (i.e., software products) to be published. Thus, in step 706, the marketplace platform receives the upload of the software artifacts.

[0118] In an exemplary embodiment, based on dimensioning the test environment for a product or service within the workspace and uploading the artifacts required to run the tests, a user in a developer role can initiate multiple preparation activities. To this end, the marketplace platform can generate and display a GUI that allows the user to initiate, for example, virtual private network (VPN) creation, resource allocation, application-centric infrastructure (ACI) network preparation, perimeter network (or screened subnet) (DMZ) network preparation, open batch factory (OBF) integration, load balancer (LB) integration, etc.

[0119] In step 707, the marketplace platform obtains test results, for example, security and compatibility test results (e.g., static test results). In an exemplary embodiment, the security and compatibility tests are performed as static tests to identify and resolve shortcomings in a product or service (e.g., a software application) to be published on the marketplace. Based on the test results, the marketplace platform (or a user with a particular role, e.g., a reviewer, an administrator, a developer, etc.) determines whether the product or service passed the static test. If it is determined that the product or service failed the static test, the marketplace platform may generate and display a GUI that allows the user (with the role of developer) to upload a modified (e.g., corrected) version of the product or service (i.e., return to step 706) or return to the landing page (i.e., return to step 702). If the static test passes, the method proceeds to step 708.

[0120] In step 708, the marketplace platform may generate and display a GUI that allows the user to upload a configuration file for the product or service to be published for product validation at the target location (e.g., on a predetermined hardware (cluster) of the marketplace). Thus, in step 708, the marketplace platform receives the configuration file from the user.

[0121] At step 709, validation of the product or service is performed. In this case, the marketplace platform may obtain test results, such as system architecture compatibility tests, performance tests, etc. If the marketplace platform determines that the product or service does not pass validation, the marketplace platform may generate and display GUI(s) that allow the user to upload a modified (adjusted) version of the product or service (return to step 706) or return to the landing page (i.e., return to step 702). If validation is successful, the method proceeds to step 710.

[0122] In step 710, the marketplace platform generates and displays at least one GUI that allows the user to upload documentation for the product or service (e.g., upload technical documentation, manuals, specifications, sales documents, pricing documents, etc.).

[0123] In step 711, based on successful testing and validation of the product or service (e.g., a software product), the marketplace platform provides a preview of the publication in the user's workspace, and the user may request publication of the application. In an exemplary embodiment, the marketplace platform may generate a dashboard GUI for the product or service on the marketplace. In another exemplary embodiment, the preview in the workspace may be approved for publication by a user in an administrator role. In another exemplary embodiment, the marketplace platform may publish the approved product or service to other users on the marketplace (e.g., customers, network operators, etc.). Upon successful publication, the marketplace platform may redirect the user in a developer role to a landing page (step 701).

[0124] On the other hand, if the user requests access to a previous workspace in step 702 (e.g., to access and validate a previously published application), the method proceeds to step 712. In step 712, the marketplace platform generates and displays a GUI that enables the user (i.e., developer, vendor) to enter a previous workspace for a product or service that has been published (or onboarded) in the marketplace, where the user can select a published communications-related or non-communications-related application (or service), select a cluster on which to install the application, import and install one or more files of the application into the selected cluster, perform validation (e.g., integration and security testing) of the application, receive validation feedback and critiques and resubmit a different or modified version based thereon, store the published and validated application in the workspace, and / or request publication of the validated application.

[0125] Figure 8 illustrates a flowchart of a product publishing process based on the role of a registered user who previously published a product on the marketplace platform, according to one or more embodiments. The method of Figure 8 may proceed from step 712 of Figure 7. Additionally, the method of Figure 8 may be performed by the publishing microservice described above with reference to Figure 5.

[0126] Referring to FIG. 8, in step 801, the marketplace platform generates and displays a GUI that allows a registered user (e.g., a user with a developer role) to enter a workspace (e.g., a test environment for publishing a product or service on the marketplace).

[0127] In step 802, the marketplace platform generates and displays a GUI that allows registered users to initiate testing on the product or service and validate the product or service to be published.

[0128] In step 803, a user may select or request that the published product or service (e.g., a software application) be loaded (i.e., transferred) onto a server (e.g., a selected cluster within the marketplace). In an exemplary embodiment, the published product or service may be loaded into, for example, a sandbox, staging, or pre-production environment for testing the product or service in the marketplace.

[0129] In step 804, the marketplace platform obtains a request for hardware resource allocation (i.e., a request for hardware dimensions for running the product in a test environment). In an exemplary embodiment, the test environment may be instantiated on a cluster (e.g., a server cluster) of the marketplace platform operator.

[0130] In step 805, in an exemplary embodiment, the marketplace platform allocates hardware resources for the products or services to be executed within the allocated hardware resources (e.g., the selected cluster). The marketplace platform then generates and displays a GUI that allows a user to load (e.g., upload) the products or services to be executed on the allocated hardware resources.

[0131] In step 806, the marketplace platform generates and displays at least one GUI that includes functionality and information related to the user's roles and privileges for testing and verifying the product (i.e., the product selected in step 803).

[0132] In step 807, validation of the product or service is performed. If the product is validated (e.g., if the product passes static tests (e.g., integration and / or security tests)), the method proceeds to step 808. In an example embodiment, the validation in step 807 (and in step 709 of FIG. 7 ) may be performed by a user with a reviewer role or a user with a platform administrator role. A user with a reviewer role and / or a platform administrator role may approve the publication of the validated product after successful validation.

[0133] In step 808, the marketplace platform obtains the results of the verification and determines that the product or service passes the verification. In this case, the verified and approved product or service (e.g., a software application) can be published on the marketplace. For example, the product may be published on the marketplace as verified.

[0134] If the product does not pass the validation of step 808, the method proceeds to step 809. In step 809, the marketplace platform generates and displays at least one GUI that allows a user in the role of developer to manage and review the validation attempt and any feedback. In an exemplary embodiment, the marketplace platform generates and displays at least one GUI that allows a user to resolve feedback from reviewers or platform administrators in order to gain successful validation and approval for publishing the product or service to the marketplace.

[0135] 9 illustrates a flowchart of a role-based deployment process (including deployment testing) on ​​a marketplace platform according to one or more embodiments. The method of FIG. 9 may be performed by the deployment microservice described above with reference to FIG. 5.

[0136] Referring to FIG. 9 , in step 901, the marketplace platform generates and displays (e.g., on a landing page) a GUI that enables a user with an operator role (e.g., customer, network operator, etc.) to deploy a product or service. Here, the landing page may be output upon successful login of a user (e.g., a user with a customer or developer role) according to the method of FIG. 6 . In an exemplary embodiment, a product or service is approved and published in the marketplace before deployment testing of the product can begin in the marketplace. In this case, the product or service (e.g., a software application) can be loaded from the marketplace into the user's (customer / operator's) deployment workspace. In another embodiment, the product or service may have already passed static testing (e.g., passed security testing in the marketplace) and is in a pre-publication or pre-validation state in the marketplace.

[0137] In step 902, the marketplace platform generates and displays a GUI that allows a user with an operator / customer role to enter a deployment workspace within the marketplace platform (i.e., the user's deployment workspace). In this case, the marketplace platform may generate and display a GUI that allows the user to enter the workspace and view previously selected products (i.e., products that the user previously selected to deploy from the marketplace). Here, the user may have previously viewed products offered in the marketplace and selected a product for deployment. In an example embodiment, the marketplace platform may generate and display a GUI that allows the user to view the deployment status of a product or service.

[0138] In step 903, the marketplace platform generates and displays a GUI that allows the user to select a product or service from among the previously selected product(s) from the marketplace. Additionally, in an exemplary embodiment, the marketplace platform may generate and display a GUI that allows the user to request a pre-publication product release on the marketplace platform (e.g., from a user with a developer role). Thus, in step 903, the marketplace platform receives a product selection from the user.

[0139] In step 904, the marketplace platform generates and displays a GUI that allows the user to select hardware dimensions for running a deployment test in the test environment. Thus, in step 904, the marketplace platform receives the dimension selection from the user. The hardware dimensions (i.e., hardware resources) for running a product or service for deployment testing may be different from those for static testing, validation, and performance testing in the public workspace. If the hardware dimensions (i.e., hardware resources) do not match the requirements of the product or service, the marketplace platform can generate and display a GUI that allows the user to go back and select a different product or service (e.g., select a different version of the product or service in step 903) to satisfy the specified hardware dimensions for deployment of the product or service.

[0140] In step 905, the marketplace platform generates and displays a GUI that allows the user to select a product or service configuration to be deployed. Thus, in step 905, the marketplace platform receives a configuration selection from the user. In an exemplary embodiment, the marketplace platform generates and displays a GUI that allows the user to request a change to the product or service configuration to meet the deployment requirements. If the product or service configuration does not match the product or service requirements, the marketplace platform can generate and display a GUI that allows the user to go back and select a different product or service (e.g., select a different version of the product or service in step 903) to meet the specified hardware dimensions for deployment.

[0141] In step 906, the marketplace platform generates and displays a GUI that allows the user to select a cluster (i.e., hardware resources, hardware location such as a specific cluster within a data center, etc.). Thus, in step 906, the marketplace platform receives the cluster selection from the user. In an exemplary embodiment, the cluster may be a marketplace platform operator's cluster. In another embodiment, the cluster may be a cluster or its server (e.g., a staging server, sandbox, etc.) within the existing telecommunications infrastructure of a user in the role of customer / operator. In an exemplary embodiment, the deployment workspace can connect to third-party hardware resources, and the marketplace platform can generate and display a GUI that allows the user to select the third-party hardware resources to begin deployment testing. If suitable hardware resources are not available (e.g., no cluster meets the product or service requirements), the marketplace platform can generate and display a GUI that allows the registered user (i.e., customer, network operator) to go back and select a different product or service (e.g., select a different version of the product or service in step 903) to meet the specified hardware resources for deployment of the product or service.

[0142] Selecting clusters from different hardware resource providers has the advantage that users can test their products or services in a test environment that takes into account (e.g., emulates) the existing hardware conditions of their existing telecommunications infrastructure (or the cloud infrastructure in which the selected product will be deployed).

[0143] In step 907, the marketplace platform generates and displays a GUI that allows the user to install (e.g., upload, run, etc.) the product or service on the selected cluster. Thus, in step 907, the marketplace platform installs the product on the selected cluster. If the installation is unsuccessful, the method can return to step 903.

[0144] At step 908, tests (e.g., integration and acceptance tests) are performed on the installed application, and the marketplace platform obtains the test results. The marketplace platform may then generate and display a GUI that allows the user to view the test results of the deployment tests (i.e., tests of the product or service (e.g., software application) in the deployment workspace). In an exemplary embodiment, the deployment tests are acceptance tests of the product or service (e.g., software application). If the tests fail, the method may return to step 903.

[0145] In step 909, the marketplace platform generates and displays a GUI that allows users to finalize the deployment of a product or service (e.g., a software application) on the existing infrastructure. In an exemplary embodiment, the marketplace platform generates and displays a GUI that allows users in one or more specific roles (e.g., operator role, reviewer role, and administrator role) to review the deployment results and finalize the purchase of the product or service between users in the marketplace with developer roles (e.g., vendors) and users in the marketplace with operator roles (e.g., customers).

[0146] 10 illustrates a flowchart of a role-based operations process on a marketplace platform, according to one or more embodiments. The method of FIG. 10 may be performed by the operations microservice described above with reference to FIG. 5.

[0147] 10, in step 1001, the marketplace platform generates and displays (e.g., on a landing page) a GUI that enables a user with an operator role (e.g., customer, network operator, etc.) to manage (e.g., monitor and maintain) deployed products or services, where the landing page may be output upon successful login of a user (e.g., a user with an operator role) according to the method of FIG. 6. The landing page may be the same landing page as described for FIG. 9 or a different landing page.

[0148] In step 1002, the marketplace platform generates and displays a GUI that allows the user to select an application (e.g., a product) from among the user's applications (e.g., previously deployed products). In an exemplary embodiment, the product or service (e.g., a software application) may already be deployed or uploaded to the user's existing infrastructure. Thus, in an exemplary embodiment, the marketplace platform provides management, maintenance, and lifecycle services to users who have the role of operator in the marketplace workspace.

[0149] Additionally, in step 1002, the marketplace platform receives a selection of an application and a selection of a management operation from among a plurality of predetermined operations, which in this exemplary embodiment include retire, upgrade, monitor, and operate.

[0150] If the selected action is retire, the method proceeds to step 1003, where the application is retired. In this case, the marketplace platform may remove the product or service (e.g., software application) from the user's inventory of applications (e.g., a list of applications deployed by the user that is stored in the marketplace and presented to the user on its GUI) or may change the status of the application in the user's inventory to retired (or the like). That is, in an exemplary embodiment, retiring a product or service (e.g., software application) may be the removal of the product from a registered user's listed (deployed) products or services (e.g., software application) in the marketplace.

[0151] If the selected operation of step 1002 is an upgrade, the method proceeds to step 1004. In step 1004, the marketplace platform receives a user selection of at least one of versioning, dimensioning, and configuration of the upgrade.

[0152] In step 1005, based on the user selection in step 1004, the marketplace platform retrieves the corresponding artifact, adds the selected configuration to it, and offers it to the user for upgrade.

[0153] In step 1006, the upgrade is performed. In step 1007, the upgraded application is validated. If the validation is successful, the upgrade is determined to be successful in step 1008. Conversely, if the validation is unsuccessful, the method proceeds to step 1009, where the upgrade is reverted. With respect to steps 1006 through 1009, the marketplace platform may provide one or more GUIs to the user that include status information of the upgrade. Alternatively, if the product is deployed to the marketplace platform itself (e.g., if the customer / operator is the marketplace operator or the customer / operator's infrastructure is at least partially integrated with the marketplace platform), the marketplace platform itself performs the upgrade, validation, and revert steps.

[0154] Next, if the selected operation of step 1002 is an upgrade, the method proceeds to step 1010. In step 1010, the marketplace platform generates and displays a GUI that enables a user (i.e., customer, network operator) to monitor products or services (e.g., software applications) that are in the user's inventory (i.e., deployed from the marketplace). If the products are deployed on or accessible to the marketplace platform itself, or the marketplace platform can receive the results of such monitoring and maintenance via API calls and / or communication / collaboration with the user's infrastructure (operator communication or cloud infrastructure) and display them on the GUI, the marketplace platform can perform the monitoring and maintenance (e.g., application logs and traces (OBF), fault management, performance management, etc.) itself.

[0155] If the selected operation in step 1002 is operation (i.e., operating an application / product), the marketplace platform provides one or more GUIs for operation of the selected application in step 1011. For example, the marketplace platform can instantiate hardware resources (e.g., hardware resources for a virtual network service) to operate a product or service (e.g., a software application) on the user's telecommunications infrastructure.

[0156] 11 is a diagram of an example environment 1100 in which the systems and / or methods described herein may be implemented. As shown in FIG. 11, environment 1100 may include a user device 1110, a platform 1120, and a network 1130. The devices in environment 1100 may be interconnected via wired connections, wireless connections, or a combination of wired and wireless connections. In embodiments, any of the functions and operations described with reference to FIGS. 1-10 above may be performed by any combination of elements shown in FIG. 11.

[0157] The user device 1110 includes one or more devices capable of receiving, generating, storing, processing, and / or providing information related to the platform 1120. For example, the user device 1110 may include a computing device (e.g., a desktop computer, a laptop computer, a tablet computer, a handheld computer, a smart speaker, a server, etc.), a mobile phone (e.g., a smartphone, a wireless phone, etc.), a wearable device (e.g., smart glasses or a smart watch), or a similar device. In some implementations, the user device 1110 may receive information from and / or transmit information to the platform 1120.

[0158] Platform 1120 includes one or more devices capable of receiving, generating, storing, processing, and / or providing information. In some implementations, platform 1120 may include a cloud server or a group of cloud servers. In some implementations, platform 1120 may be designed to be modular, such that particular software components can be swapped in or out depending on particular needs. As such, platform 1120 may be easily and / or quickly reconfigured for different uses.

[0159] In some implementations, as shown, platform 1120 may be hosted in a cloud computing environment 1122. In particular, although the implementations described herein describe platform 1120 as being hosted within cloud computing environment 1122, in some implementations platform 1120 may not be cloud-based (i.e., may be implemented outside of a cloud computing environment) or may be partially cloud-based.

[0160] Cloud computing environment 1122 includes an environment that hosts platform 1120. Cloud computing environment 1122 can provide services such as computation, software, data access, storage, etc. that do not require end-user (e.g., user device 1110) knowledge of the physical location and configuration of the system(s) and / or device(s) that host platform 1120. As shown, cloud computing environment 1122 can include a group of computing resources 1124 (collectively referred to as “computing resources 1124” and individually referred to as “computing resource 1124”).

[0161] Computing resources 1124 include one or more personal computers, clusters of computing devices, workstation computers, server devices, or other types of computing and / or communication devices. In some implementations, computing resources 1124 can host platform 1120. Cloud resources may include compute instances executing within computing resources 1124, storage devices provided within computing resources 1124, data transfer devices provided by computing resources 1124, etc. In some implementations, computing resources 1124 may communicate with other computing resources 1124 via wired connections, wireless connections, or a combination of wired and wireless connections.

[0162] As further shown in FIG. 11, computing resources 1124 include a group of cloud resources such as one or more applications ("applications, APP") 1124-1, one or more virtual machines ("virtual machines, VM") 1124-2, virtualized storage ("virtualized storage, VS") 1124-3, and one or more hypervisors ("hypervisors, HYP") 1124-4.

[0163] Applications 1124-1 include one or more software applications that may be provided to or accessed by user device 1110. Applications 1124-1 may obviate the need to install and run software applications on user device 1110. For example, applications 1124-1 may include software associated with platform 1120 and / or any other software that may be provided via cloud computing environment 1122. In some implementations, one application 1124-1 may send information to or receive information from one or more other applications 1124-1 via virtual machine 1124-2.

[0164] Virtual machine 1124-2 includes a software-implemented machine (e.g., a computer) that executes programs like a physical machine. Virtual machine 1124-2 can be either a system virtual machine or a process virtual machine, depending on the application and the degree to which virtual machine 1124-2 represents an actual machine. A system virtual machine can provide a complete system platform that supports the execution of a complete operating system (“OS”). A process virtual machine can execute a single program and support a single process. In some implementations, virtual machine 1124-2 can run on behalf of a user (e.g., user device 1110) and manage the infrastructure of cloud computing environment 1122, such as data management, synchronization, or long-term data transfer.

[0165] Virtualized storage 1124-3 includes one or more storage systems and / or one or more devices that use virtualization technology within the storage systems or devices of computing resources 1124. In some implementations, in the context of storage systems, types of virtualization can include block virtualization and file virtualization. Block virtualization can refer to the abstraction (or separation) of logical storage from physical storage such that the storage system can be accessed regardless of the physical storage or heterogeneous structure. The separation can allow administrators flexibility in how they manage the storage for end users. File virtualization can eliminate the dependency between data accessed at the file level and where the file is physically stored. This can enable optimization of storage usage, server consolidation, and / or non-disruptive file migration.

[0166] The hypervisor 1124-4 may provide hardware virtualization technology that allows multiple operating systems (e.g., "guest operating systems") to run simultaneously on a host computer, such as the computing resource 1124. The hypervisor 1124-4 may provide a virtual operating platform for the guest operating systems and may manage the execution of the guest operating systems. Multiple instances of different operating systems may share the virtualized hardware resources.

[0167] Network 1130 may include one or more wired and / or wireless networks. For example, network 1130 may include a cellular network (e.g., a fifth-generation (5G) network, a long-term evolution (LTE) network, a third-generation (3G) network, a code division multiple access (CDMA) network, etc.), a public land mobile network (PLMN), a local area network (LAN), a wide area network (WAN), a metropolitan area network (MAN), a telephone network (e.g., a public switched telephone network (PSTN)), a private network, an ad hoc network, an intranet, the Internet, an optical fiber-based network, etc., and / or a combination of these or other types of networks.

[0168] The number and arrangement of devices and networks shown in Figure 11 are provided as an example. In practice, there may be additional, fewer, different, or differently arranged devices and / or networks than those shown in Figure 11. Furthermore, two or more devices shown in Figure 11 may be implemented within a single device, or a single device shown in Figure 11 may be implemented as multiple distributed devices. Additionally, or instead, a set of devices (e.g., one or more devices) of environment 1100 may perform one or more functions that are described as being performed by another set of devices in environment 1100.

[0169] 12 is a diagram of example components of device 1200. Device 1200 may correspond to user device 1110 and / or platform 1120. As shown in FIG. 12, device 1200 may include a bus 1210, a processor 1220, a memory 1230, a storage component 1240, an input component 1250, an output component 1260, and a communication interface 1270.

[0170] Bus 1210 includes components that enable communication between components of device 1200. Processor 1220 may be implemented in hardware, firmware, or a combination of hardware and software. Processor 1220 may be 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), or another type of processing component. In some implementations, processor 1220 includes one or more processors that can be programmed to perform functions. Memory 1230 includes random access memory (RAM), read-only memory (ROM), and / or another type of dynamic or static storage device (e.g., flash memory, magnetic memory, and / or optical memory) that stores information and / or instructions for use by processor 1220.

[0171] Storage component 1240 stores information and / or software related to the operation and use of device 1200. For example, storage component 1240 may include a hard disk (e.g., a magnetic disk, optical disk, magneto-optical disk, and / or solid-state disk), a compact disk (CD), a digital versatile disk (DVD), a floppy disk, a cartridge, magnetic tape, and / or another type of non-transitory computer-readable medium, along with a corresponding drive. Input component 1250 includes components that enable device 1200 to receive information via user input (e.g., a touchscreen display, a keyboard, a keypad, a mouse, buttons, switches, and / or a microphone). Additionally or alternatively, input component 1250 may include sensors for sensing information (e.g., a global positioning system (GPS) component, an accelerometer, a gyroscope, and / or an actuator). Output component 1260 includes components that provide output information from device 1200 (e.g., a display, a speaker, and / or one or more light-emitting diodes (LEDs)).

[0172] Communication interface 1270 includes transceiver-like components (e.g., a transceiver and / or a separate receiver and transmitter) that enable device 1200 to communicate with other devices, such as via a wired connection, a wireless connection, or a combination of wired and wireless connections. Communication interface 1270 may enable device 1200 to receive information from and / or provide information to another device. For example, communication interface 1270 may include an Ethernet interface, an optical interface, a coaxial interface, an infrared interface, a radio frequency (RF) interface, a universal serial bus (USB) interface, a Wi-Fi interface, a cellular network interface, etc.

[0173] Device 1200 may perform one or more processes described herein. Device 1200 may perform these processes in response to processor 1220 executing software instructions stored by a non-transitory computer-readable medium, such as memory 1230 and / or storage component 1240. A computer-readable medium is defined herein as a non-transitory memory device. A memory device includes memory space within a single physical storage device or memory space spread across multiple physical storage devices.

[0174] The software instructions may be loaded into memory 1230 and / or storage component 1240 from another computer-readable medium or from another device via communication interface 1270. When executed, the software instructions stored in memory 1230 and / or storage component 1240 may cause processor 1220 to perform one or more processes described herein.

[0175] Additionally, or instead, hardwired circuitry may be used in place of or in combination with software instructions to implement one or more processes described herein. Thus, implementations described herein are not limited to any specific combination of hardware circuitry and software.

[0176] The number and arrangement of components shown in Figure 12 are provided as an example. In practice, device 1200 may include additional, fewer, different, or differently arranged components than those shown in Figure 12. Additionally or alternatively, a set of components (e.g., one or more components) of device 1200 may include:

[0177] One or more functions described as being performed by another set of components of device 1200 may be performed.

[0178] In embodiments, any one of the operations or processes of FIGS. 1 through 10 may be performed by or using any one of the elements shown in FIGS.

[0179] Exemplary embodiments of the present disclosure provide methods and systems in which the network service onboarding and onboarding process is simplified and automated, as opposed to manually onboarding network services on-site. A centralized onboarding and onboarding process can save time and resources, and automation, among other benefits, minimizes human error and compatibility issues, improves customer satisfaction, and reduces business risk for users (e.g., service providers). Furthermore, by automating user (e.g., service provider) onboarding and onboarding in a centralized and guided manner, online marketplace platforms provide customers (e.g., network operators) with an easy, flexible, cost-effective, efficient, and quickly implementable solution for network service selection. For users (e.g., service providers), such a network service onboarding and onboarding process provides a low-risk testing environment with minimal impact on customers (e.g., network operators) to deliver high-quality services without imposing heavy demands on customers.

[0180] It is understood that the specific order or hierarchy of blocks in the processes / flowcharts disclosed herein is an example of an example approach. It is understood that the specific order or hierarchy of blocks in the processes / flowcharts may be rearranged based on design preferences. Furthermore, some blocks may be combined or omitted. Although the accompanying method claims present elements of various blocks in an example order, the elements of the blocks are not limited to the specific order or hierarchy shown.

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

[0182] A computer-readable storage medium may be any tangible device capable of retaining and storing instructions for use by an instruction-execution device. A computer-readable storage medium may be, for example, 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 of the foregoing. 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 versatile disks (DVDs), memory sticks, floppy disks, mechanically encoded devices such as punch cards or ridge-in-groove structures on which instructions are recorded, and any suitable combination of the foregoing. As used herein, computer-readable storage media should not be construed as being transitory signals per se, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through a waveguide or other transmission medium (e.g., light pulses passing through a fiber optic cable), or electrical signals transmitted through wires.

[0183] 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 storage device over 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 fiber, wireless transmission, routers, firewalls, switches, gateway computers, and / or edge servers. A network adapter card or network interface within each computing / processing device receives the computer-readable program instructions from the network and forwards the computer-readable program instructions for storage on a computer-readable storage medium within the respective computing / processing device.

[0184] The computer-readable program code / instructions for carrying out operations may be either source code or object code written in any combination of one or more programming languages, including assembler instructions, instruction-set-architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state-setting data, integrated circuit configuration data, or object-oriented programming languages ​​such as Smalltalk, C++, and procedural programming languages ​​such as the "C" programming language or similar programming languages. The computer-readable program instructions may execute entirely on the user's computer, partially on the user's computer, as a stand-alone 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 may be connected to an external computer (e.g., via the Internet using an Internet service provider). In some embodiments, electronic circuitry including, for example, a programmable logic circuit, a field programmable gate array (FPGA), or a programmable logic array (PLA) can execute computer-readable program instructions by utilizing state information of the computer-readable program instructions to personalize the electronic circuitry to perform an aspect or operation.

[0185] These computer-readable program instructions may be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, executing on the processor of the computer or other programmable data processing apparatus, produce means for implementing the functions / acts specified in one or more blocks of the flowcharts and / or block diagrams. These computer-readable program instructions may also be stored on a computer-readable storage medium capable of directing a computer, programmable data processing apparatus, and / or other device to function in a particular manner, such that the computer-readable storage medium on which the instructions are stored comprises an article of manufacture containing instructions that implement aspects of the functions / acts specified in one or more blocks of the flowcharts and / or block diagrams.

[0186] The computer-readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable apparatus, or other device to generate a computer-implemented process, such that the instructions executing on the computer, other programmable apparatus, or other device perform the functions / acts specified in one or more blocks of the flowcharts and / or block diagrams.

[0187] 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 the flowcharts or block diagrams may represent a module, segment, or portion of instructions, including one or more executable instructions for implementing a particular logical function(s). The methods, computer systems, and computer-readable media may include additional, fewer, different, or differently arranged blocks compared to the blocks shown in the figures. In some alternative implementations, the functions noted in the blocks may occur in a different order than noted in the figures. For example, two blocks shown in succession may actually be executed concurrently or substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending on the functionality involved. It should also be noted that each block of the block diagrams and / or flowchart diagrams, and combinations of blocks in the block diagrams and / or flowchart diagrams, can be implemented by a dedicated hardware-based system that performs the specified functions or actions or executes a combination of dedicated hardware and computer instructions.

[0188] 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 intended to limit the implementation. Thus, the operation and behavior of the systems and / or methods are described herein without reference to specific software code, and it will be understood that software and hardware can be designed to implement the systems and / or methods based on the description herein.

Claims

1. 1. A system for automated, role-based control of a centralized marketplace of products, comprising: a memory for storing instructions; and at least one processor, wherein the at least one processor: mapping a first role of a plurality of predetermined marketplace participant roles to the first user based on first registration information obtained from the first user; mapping a second role of the plurality of predetermined roles of the marketplace participant to the second user based on second registration information obtained from the second user; Execute at least one first microservice of the centralized marketplace for the first user based on the first role of the first user, the first role being a developer role; configured to execute the instructions to execute at least one second microservice of the centralized marketplace for the second user based on the second role of the second user, the second role being a customer role; the at least one first microservice includes a publishing process for publishing the first user's product on the centralized marketplace; the at least one second microservice includes a deployment process for deploying the product to the second user's infrastructure; system.

2. the at least one processor: obtaining the first registration information from the first user and the second registration information from the second user via a first screen for registering a user with the centralized marketplace; receiving first login credentials of the first user and second login credentials of the second user via a second screen for logging into the centralized marketplace; The system of claim 1 , further configured to execute the instructions to grant different access rights to the first user and the second user based on the first role and the second role.

3. the at least one processor: receiving an artifact of said product that is a software application; assigning the artifact to at least one public test environment for testing the product; obtaining the results of said test; Presenting the results to the first user based on the first role.

10. The system of claim 1, further configured to execute the instructions for executing the at least one first microservice such that:

4. The system of claim 3 , wherein the at least one public test environment is hosted by an operator of the centralized marketplace.

5. The product is Enterprise software for telecommunications operators and and a virtualized network service.

6. the at least one processor: receiving an artifact of said product that is a software application; assigning the artifact to at least one deployment test environment for testing the product of the first user; obtaining the results of said test; Presenting the results to the second user based on the second role.

10. The system of claim 1, further configured to execute the instructions for executing the at least one second microservice such that:

7. The system of claim 6 , wherein the at least one deployment test environment is hosted by an operator of the centralized marketplace.

8. The product is The system of claim 6 , including published products of users mapped to the first role that have been tested in at least one public test environment and approved for publication.

9. the at least one processor: mapping a third role of the plurality of predetermined roles of the marketplace participant, the third role being a reviewer role, to a third user; Execute at least one third microservice of the centralized marketplace for the third user based on the third role of the third user. further configured to execute the instructions to 10. The system of claim 1, wherein the at least one third microservice includes a critique process for critique the product submitted by the first user for publication.

10. the at least one processor: mapping a fourth role of the plurality of predetermined roles of the marketplace participant, the fourth role being an administrator role, to a fourth user; Execute at least one fourth microservice of the centralized marketplace for the fourth user based on the fourth role of the fourth user. further configured to execute the instructions to the at least one fourth microservice includes an approval process; the at least one processor: registering the first user to have the first role based on the obtained first registration information and authorization by the fourth user; registering the second user to have the second role based on the obtained second registration information and authorization by the fourth user; approve, based on approval by the fourth user, registration of a third user to have a third role among the plurality of predetermined roles, the third role being a reviewer role; Approving the publication of the first user's product on the marketplace based on the publication process and a review process performed by the third user. and further configured to execute the instructions to execute the at least one fourth microservice such that The system of claim 1 .

11. 1. A method for automated, role-based control of a centralized marketplace of products, comprising: mapping a first role of a plurality of predetermined marketplace participant roles to a first user based on first registration information obtained from the first user; mapping a second role of the plurality of predetermined roles of the marketplace participant to the second user based on second registration information obtained from the second user; Executing at least one first microservice of the centralized marketplace for the first user based on the first role of the first user, the first role being a developer role; executing at least one second microservice of the centralized marketplace for the second user based on the second role of the second user, the second role being a customer role; the at least one first microservice includes a publishing process for publishing the first user's product on the centralized marketplace; the at least one second microservice includes a deployment process for deploying the product to an infrastructure of the second user.

12. obtaining the first registration information from the first user and the second registration information from the second user via a first screen for registering users with the centralized marketplace; receiving first login credentials of the first user and second login credentials of the second user via a second screen for logging into the centralized marketplace; The method of claim 11 , further comprising granting different access rights to the first user and the second user based on the first role and the second role.

13. executing the at least one first microservice; receiving an artifact of said product, said artifact being a software application; assigning the artifact to at least one public test environment for testing the product; obtaining results of said tests; and presenting the results to the first user based on the first role.

14. The method of claim 13 , wherein the at least one public test environment is hosted by an operator of the centralized marketplace.

15. The product is Enterprise software for telecommunications operators and and a virtualized network service.

16. executing the at least one second microservice; receiving an artifact of said product, said artifact being a software application; assigning the artifact to at least one deployment test environment for testing the product of the first user; obtaining results of said tests; and presenting the results to the second user based on the second role.

17. The method of claim 16 , wherein the at least one deployment test environment is hosted by an operator of the centralized marketplace.

18. The product is 17. The method of claim 16, further comprising placing at least one public test environment for testing the product of the first user within the centralized marketplace, the public test environment including a published product of a user mapped to the first role.

19. mapping a third role of the plurality of predetermined roles of the marketplace participant to a third user, the third role being a reviewer role; executing at least one third microservice of the centralized marketplace for the third user based on the third role of the third user; 12. The method of claim 11, wherein the at least one third microservice includes a critique process for critique the product submitted by the first user for publication.

20. mapping a fourth role of the plurality of predetermined roles of the marketplace participant, the fourth role being an administrator role, to a fourth user; executing at least one fourth microservice of the centralized marketplace for the fourth user based on the fourth role of the fourth user; the at least one fourth microservice includes an approval process, registering the first user to have the first role based on the obtained first registration information and authorization by the fourth user; registering the second user to have the second role based on the obtained second registration information and authorization by the fourth user; approving registration of a third user to have a third role of the plurality of predetermined roles, the third role being a reviewer role, based on approval by the fourth user; and approving the first user's publication of the product on the marketplace based on the publication process and a review process performed by the third user.

Images