WO2023117072A1

WO2023117072A1 - Order capture system for a communication network

Info

Publication number: WO2023117072A1
Application number: PCT/EP2021/087244
Authority: WO
Inventors: Prafulla PRASHANT; Saravanan RAVICHANDRAN
Original assignee: Telefonaktiebolaget Lm Ericsson (Publ)
Priority date: 2021-12-22
Filing date: 2021-12-22
Publication date: 2023-06-29

Abstract

According to an aspect, there is provided a computer-implemented method of operating an order capture system node for products and/or services for use in a communication network. The method comprises receiving (801) a first order request for a first type of product and/or service for use in the communication network, the first order request indicating (i) a first quantity of the first type of product and/or service to be ordered, wherein the quantity is greater than one, and (ii) respective values for a plurality of attributes individually configured or selected for each of the ordered first type of product and/or service; creating (803) a first entry in an order database for the first order request, the first entry identifying: (i) the first type of product and/or service, (ii) the first quantity to be ordered; and (ill) the values of any attribute that is common to all of the ordered first type of product and/or service; and creating (805) sub-entries in the order database for the first entry, each sub-entry corresponding to a respective one of the ordered first type of product and/or service, and each sub-entry comprising values of any attribute that is not common to all of the other ones of the ordered first type product and/or service.

Description

Order capture system for a communication network

Technical Field

This disclosure relates to an order capture system for products and/or services that are to be used in a communication network.

A Charging System (CS) is a system that is used for different types of rating and charging needs of products and/or services used in a communication network. The rating typically means how much a product and/or service will cost per second/minute/etc. based on the user's location, another party's location, active discounts, etc. The charging takes an amount determined by the rating and debits the amount from a user balance/account. These products and/or services may have been purchased by a particular customer of the communication network, or a customer of the network operator of the communication network. A service can define a network capability provided to the customer or to a product of the customer, and such service is provided using one or more resources of the communication networks. The communication network therefore needs to have resources available to the services, with the resources denoting the communication id on which the services would be used. That is, any service used by a customer is based on a device (product) that they are using, with the device connected to the network. Any connected device uses an identifier, which in the case of a communication network can be a mobile number, an International Mobile Equipment Identity (I MEI) or a Mobile Station Integrated Services Digital Network (MSISDN) identifier. A charging system identifies such devices using the communication id so that the correct customer is rated and charged.

A Catalog Manager (CM) tool is a catalog management system that allows a network operator to create and manage business data such as products and/or services, and resources. This business data is referred to as "specifications” which define the characteristic of a specification, relations amongst them, prices, and rules that govern their instantiation during an order capturing phase.

An Order Care system includes an Order Capturing (OC) tool and an Order Management (OM) tool. The Order Capturing tool allows users (customers or prospective customers) to browse and select offers (specifications) created by the Catalog Manager and add them to their list of products and/or services that they want to buy. Once the products are added by the customer, the consolidated product view is submitted to the Order Management tool which, based on the services and resource(s) attached to the product, provisions them to the network and Charging System.

The Service Registry (SR) is a component inside the Order Care system which holds information on all the products and services bought by a customer. It also manages the complete lifecycle of products starting from activation till expiry.

Fig. 1 illustrates a part of a conventional solution for providing, ordering and provisioning of a product/service offering. Fig. 1 shows a Catalog Manager (CM) tool 2, an Order Care system 4 that includes Order Capturing (OC) and Order Management (OM), and a Service Registry (SR)ZChargi ng System (CS) 6. A representation of the customer user interface (Ul) 8 to the Order Care System 4 and SR/CS 6 is also shown.

The CM 2 stores information on one or more product/service offerings 10, where each product/service offering 10 has one or more configurable or selectable characteristics or attributes 12 (e.g. storage size, random access memory (RAM) size, colour, etc. in the case of a mobile smartphone product), and the price 14 of the product offering 10.

The order care system 4 provides a shopping cart 16 that customers add their desired products/services to. The shopping cart 16 provides a container 18 to which the products/services are added. In Fig. 1 , the customer has added three products to the shopping cart 16, as indicated by product instances 20, with each product instance 20 indicating the characteristicZattribute(s) 22 for that product instance as selected by the customer (e.g. 128GB storage, 8GB RAM, red, etc.).

Once the order is confirmed, the order is instantiated in the SR/CS 6. Thus, the information on the ordered products/services is added to the charging records 24 for the relevant customer. Therefore the information in the charging records 24 includes the product instances 20 and the selected characteristic/ attribute(s) 22 for that product instance.

Thus, end-to-end (E2E) solutions, such as shown in Fig. 1 , are available for modelling a product offering and ordering the same via quote and provisioning of the product offerings via order management. Traditionally these products are tuned towards ordering and managing a few instances of product offerings ordered for a customer. For example, each time a customer purchases an offer (i.e. a product and/or a service), an instance of the offer is created in the quote with all its characteristics/attributes and relations based on how offers are defined. So, if a customer purchases a quantity N of an offer, there would be N instances 20 created by the Order Care system 4. The configuration of those N instances 20 would be shown individually to the customer and that many instances will persist in the Service Registry 6.

In addition to the persistence of purchased products/services in the Service Registry 6, the products/services are also provisioned in the Charging System 6. The charging system 6 uses this information to perform the rating and charging of the products/services availed or used by the customers. For efficient access, the charging system caches all the provisioned products/services into memory, so typically the charging system 6 will replicate the information of N instances 20 into the memory.

For example, if the customer wants to buy five mobile smartphones, along with Subscriber Identity Modules (SIMs) and MSISDNs, then the phone product offering 10 must be added to the shopping cart 16 five times, and the necessary characteristics 12 like colour/memory must be configured on each product offering instance 20 added. In case the customer wants to manage lifecycle of their purchased products or change the characteristics of it, all the instances 20 from the service registry 6 would be loaded by the order capturing system 4. This solution is satisfactory for a customer that is an end user of the communication network or a Small office/Home office (SOHO) enterprise customer in a traditional business.

However, if an enterprise customer wants to buy, say, 1000 mobile lines/devices or if an enterprise customer wants to buy a Software-defined Wide Area Network (SD WAN) product for 1000 sites, the expected number of operations in the quote/order multiplies several fold. Furthermore, with the advent of more and more 5G/lnternet-of- Things (IOT) integration in an end user's business, the quantity of products/services to be managed in the quote/order exponentially increases. Traditional systems, such as those shown in Fig. 1 , will have to instantiate 1000s of such device specifications, which is unsustainable to display and allow the user configure each one, and also unsustainable to keep and process in memory. It is also unsustainable for the Service Registry and Charging System to serve user traffic with that many instances. This increases the memory requirements of the system and the hard disk (or other storage means) footprint exponentially.

In the growing IOT space, operators are starting to provide different lOT-based managed services. For example, one service/product may be a fully automated security system for an entire organisation with thousands of sensors. In this use-case of managed services, the network operator not only has to deal with the problem of how to provide its customer with a seamless interface for order capturing which allows for the ordering of 1000s of instances of a device, and also managing those instances from a day-to-day operational maintenance perspective, and allow its customers to make any changes to its existing installation as the need arises in future. Thus, the traditional approach becomes costly.

In the Charging System 6, for each quantity of product purchased, there will be that many services and resources provisioned and cached in memory. The resource which contains the communication ID should be replicated per product purchased but the services and the rating plans are same for all the quantities purchased. Traditionally the charging system 6 will replicate the services as well as the rating plan information N times and try to cache them all in memory. This is either inefficient, or not possible at all if there is a large quantity purchased which does not fit into the existing memory size. This will significantly slow down the performance of the charging system 6.

Another example would be a gaming company buying 5^th Generation (5G) network slices from the network operator, and allowing its users to use this/these network slices to obtain a rich or enhanced gaming experience. In such a scenario, the gaming company may buy thousands of network slices at once and the commercial implication of this quantity is very meagre.

The configuration required for loT services and the allowed actions after provisioning the service to the communication network is minimal in comparison to traditional service products such as Mobile/I nternet/Broad band/TV.

Traditionally, systems which provide quote/order capturing interfaces are tuned towards the ordering of limited quantities of devices, which could be in the range of tens of products. Any (larger) bulk order is processed offline, which requires a lot of human resource to manage part of the entire infrastructure.

With more adaptation of networks towards the IOT industry, the requirement for ordering and managing the devices will grow exponentially, and human-oriented processes would soon suffer in trying to manage such a huge surge in this space. This would lead to the time taken by a network operator in launching a product up to managing it to increase significantly, and this will lead to dissatisfied users who are not able to manage their requirements at their own will.

Therefore, it is important for an order capture system, and subsequent tools in an ordering and provisioning system, it to minimise the memory footprint of the system. Traditionally, the charging system will also replicate the information of N instances into the memory which will not be manageable for IOT domains where large number of instances are ordered.

Thus, a system is desired which caters to this specific problem and provides an efficient user interface and operation method which allows customers to customise and create orders of that magnitude and manage them on a day-to-day basis without requiring human resource to intervene in the order and/or provisioning process provided by operator.

It will be a noted that a significant drawback of existing quantity-based shopping carts is that complete personalisation or customisation of the product being ordered is not possible. To use a retail-based example, a customer may wish to order a number of t-shirts, and if "large” is selected as the size for, say, 10 t-shirts, then all the t-shirts in that instance in the shopping cart will have the same size. It is not possible to personalise the size and colour of each t-shirt in the shopping cart as of today. In the retail business, the number of properties or characteristics of products or services available to personalise are much less that the products and services available in the communications industry and communications products often get decomposed into a product specification, services and resources, i.e. 10 products become 50 different items in the shopping cart.

The use of global product instances, for example as described in WO 2017/182085, do not solve the above problem because customers might buy different numbers of t-shirts with different personalisations (size, colour). Storing one product instance for the whole install base is not an option. When it comes to loT devices and services, it should be noted that each device typically has a communication network resource or another identifier (e.g. a Subscription Permanent Identifier (SUPI), otherwise the device cannot register with the network. Thus, an array of these identifiers must be managed by the ordering capture system.

The techniques described herein leverage the fact that for the above-mentioned scenarios (e.g. the retail scenario) there wouldn't be a need for extensive configurability per instance of the product purchased/ordered. When ordered with quantities of the order of thousands or more, there would be a group of thousands and more products having the exact same characteristics and hence, there is no need to create a unique instance for every product ordered.

The disclosed solutions introduce quantity and quantity-based characteristics into the catalog modelling. A product offering modeller would be able to denote a characteristic as quantity-based on not. This will help in the ordering time configuration. For example, if 1000 connected security cameras (each having its own SIM) are ordered with high definition (HD) resolution and another 1000 (each with their own SIM) are ordered with low resolution, then instead of instantiating 2000 instances in memory (RAM) and persisting them on disk in the database, the system can store only one instance of each category of connected security camera ordered. In this case, one instance of a connected security camera with HD quality and another instance of a connected security camera with low resolution would be created. These two instances would hold the quantity of products ordered, which in the current example would be 1000 for each instance.

A concept of "slim associated instances” or "slim instances” is introduced whereby only characteristics which can be personalised per product ordered can be created per quantity ordered, and can be associated with the main product instance. For example, during ordering, the system may need to keep (store) the serial number of each connected security camera that was shipped to the customer. Conventionally, along with all other characteristics of the connected security camera (which could be in the range of tens of different connected security camera characteristics), the serial number will be stored in each instance (2000 instances) that were created. According to the techniques described herein, with this example 2000 "slim instances” can be created that contain only the serial number characteristic, thus reducing the memory footprint by a significant margin.

In further embodiments, the Charging System can subsequently be provisioned with a single product comprising service and resource for 2000 instances. The individual communication IDs derived from the SIM and/or a serial number or other unique number for the product, will be stored in the slim associated instances. Hence, the charging system is able to refer only to a single instance of services and resource for any rating and charging related business use-cases. In addition, the memory footprint required to service these instances will not grow linearly with the number of connected security cameras purchased.

The techniques described herein make it more feasible to showcase the products ordered for/by a customer. Since, in the above connected security camera example, there will be only two instances created in the database representing 1000 connected security cameras ordered under each category, it will be trivial to display it on a Ul. Since thousands of such products were ordered, customers are less likely to be interested in seeing the individually personalised details stored per instance, if any.

In some embodiments, in case the customer wants to further drill down and see the individual personalised details like serial number of each device, the Ul can enable that and only in that case the system can load those details, for example in a paginated way.

Some embodiments enable a customer to modify the products in bulk. For example, a customer can deactivate the last 500 instances without having to go to each database entry of the instances and deactivate them individually.

According to a first specific aspect, there is provided a computer-implemented method of operating an order capture system node for products and/or services for use in a communication network. The method comprises receiving a first order request for a first type of product and/or service for use in the communication network, the first order request indicating (I) a first quantity of the first type of product and/or service to be ordered, wherein the quantity is greater than one, and (ii) respective values for a plurality of attributes individually configured or selected for each of the ordered first type of product and/or service; creating a first entry in an order database for the first order request, the first entry identifying: (I) the first type of product and/or service, (ii) the first quantity to be ordered; and (ill) the values of any attribute that is common to all of the ordered first type of product and/or service; and creating sub-entries in the order database for the first entry, each sub-entry corresponding to a respective one of the ordered first type of product and/or service, and each sub-entry comprising values of any attribute that is not common to all of the other ones of the ordered first type product and/or service.

According to a second aspect, there is provided a computer program product comprising a computer readable medium having computer readable code embodied therein, the computer readable code being configured such that, on execution by a suitable computer or processor, the computer or processor is caused to perform the method according to the first aspect or any embodiment thereof.

According to a third aspect, there is provided an order capture system node. The order capture system node is for orders for products and/or services for use in a communication network. The order capture system node is configured to receive a first order request for a first type of product and/or service for use in the communication network, the first order request indicating (i) a first quantity of the first type of product and/or service to be ordered, wherein the quantity is greater than one, and (ii) respective values for a plurality of attributes individually configured or selected for each of the ordered first type of product and/or service; create a first entry in an order database for the first order request, the first entry identifying: (i) the first type of product and/or service, (ii) the first quantity to be ordered; and (ill) the values of any attribute that is common to all of the ordered first type of product and/or service; and create subentries in the order database for the first entry, each sub-entry corresponding to a respective one of the ordered first type of product and/or service, and each sub-entry comprising values of any attribute that is not common to all of the other ones of the ordered first type product and/or service.

According to a fourth aspect, there is provided an order capture system node. The order capture system node is for orders for products and/or services for use in a communication network. The order capture system node comprises a processor and a memory, said memory containing instructions executable by said processor whereby said order capture system node is operative to receive a first order request for a first type of product and/or service for use in the communication network, the first order request indicating (i) a first quantity of the first type of product and/or service to be ordered, wherein the quantity is greater than one, and (ii) respective values for a plurality of attributes individually configured or selected for each of the ordered first type of product and/or service; create a first entry in an order database for the first order request, the first entry identifying: (i) the first type of product and/or service, (ii) the first quantity to be ordered; and (ill) the values of any attribute that is common to all of the ordered first type of product and/or service; and create sub-entries in the order database for the first entry, each sub-entry corresponding to a respective one of the ordered first type of product and/or service, and each sub-entry comprising values of any attribute that is not common to all of the other ones of the ordered first type product and/or service.

The aspects and/or embodiments discussed herein may provide one or more of the following advantages. The aspects and/or embodiments may enable the user to create quotes and orders for a bulk quantity. The aspects and/or embodiments may enable Uls to represent orders where quantities ordered are very large. The aspects and/or embodiments may enable Uls to efficiently present the installed products/services for viewing in case a large quantity of products/services is ordered or similar types of products/services were ordered previously. The aspects and/or embodiments may enable Uls to 'lazily' load individual product/service details only in the event that the user requests these, and specify pagination while doing so, making it possible to scroll through details of products/services that exist in large quantities. Some aspects and/or embodiments may provide that, since products/services of similar features are grouped together as a single instance, customers can efficiently manage them in bulk. Some aspects and/or embodiments provide a very low memory footprint for use-cases where the quantity of products/services ordered is large. Some aspects and/or embodiments provide that less storage space is taken up the data representing a large order of products/services. Some aspects and/or embodiments provide for a considerable reduction in central processing unit (CPU) utilisation because of the minimal number of instances created to represent large groups of similar products/services. Some aspects and/or embodiments provide, that one-time configured quantity-related attributes can be externalised and stored into a low cost secondary storage, avoiding high cost database operations. Those skilled in the art will be aware of other benefits and advantages of the techniques described herein.

Brief Description of the Drawings

Some of the embodiments contemplated herein will now be described more fully with reference to the accompanying drawings, in which:

Fig. 1 illustrates a part of a conventional solution for providing, ordering and provisioning of a product/service offering;

Fig. 2 is an illustration of a conventional approach to a catalog model used by a catalog manager, and a representation of a product offer in an order capture system;

Fig. 3 is an illustration of an alternative approach to a catalog model used by a catalog manager and a representation of a product offer in an order capture system in accordance with the techniques described herein;

Fig. 4 shows part of a solution for providing, ordering and provisioning of a product/service offering according to embodiments of the techniques described herein;

Fig. 5 is a signalling/sequence diagram illustrating various operations according to the aspects and embodiments described herein;

Fig. 6 is a block diagram of a system node in accordance with various aspects described herein;

Fig. 7 is a block diagram illustrating a virtualization environment in which functions implemented by some embodiments may be virtualized; and

Fig. 8 is a flow chart illustrating a method in accordance with some embodiments.

Detailed Description

Some of the embodiments contemplated herein will now be described more fully with reference to the accompanying drawings. Embodiments are provided by way of example to convey the scope of the subject matter to those skilled in the art.

Figs. 2 illustrates a conventional approach to a catalog model used by a catalog manager (CA) and a representation of a product offer in an order capture system. The catalog model 50 includes a specification 52 for a particular product or service, which in this illustrated example is a smartphone model called "PhoneA”. PhoneA has a number of attributes/characteristics 54 for which respective values 56 can be selected by the customer. In this example, the attributes/characteristics 54 for PhoneA include 'colour', 'memory', ‘serial number', 'unlocked' (i.e. whether PhoneA is restricted to use with a particular network operator), 'battery' (i.e. battery capacity) and 'camera'.

In this example, the customer orders 5 PhoneAs with three different configurations. Block 58 represents the shopping cart into which the order is placed, and block 58 also represents the instantiation of the products in the Service Registry/Charging System. Using the traditional approach, the shopping cart/SR/CS 58 includes an instance for each ordered PhoneA, even if several instances have the same configuration and/or differences in only a small number of attributes. These instances are labelled 60a-e. Instances 60a-c have the same configuration, with the PhoneAs having values 56 of 'black' for the colour, '128GB' for the memory, and 'true' for unlocked. Instances 60d-e have respectively different configurations to instances 60a-c, with instance 60d of PhoneA having values 56 of 'blue' for the colour, '128GB' for the memory, and 'true' for unlocked, and instance 60e of PhoneA having values 56 of 'red' for the colour, '128GB' for the memory, and 'true' for unlocked. The traditional approach therefore leads to unnecessary wastage of memory footprint, CPU utilisation and disk space. The problem is aggravated when this example is imagined for an IOT use-case with thousands of instances being ordered.

Fig. 3 illustrates an alternative approach to the catalog model and a representation of a product offer in an order capture system according to the techniques described herein. The catalog model 70 includes a specification 72 for a particular product or service, which in this illustrated example is the smartphone model called "PhoneA”. The specification for PhoneA has a quantity field 74 for indicating the number of PhoneAs covered by the instance, and a number of attributes/characteristics 76 for which respective values 78 can be selected by the customer. As in the example in Fig. 2, the attributes/characteristics 76 for PhoneA include 'colour', 'memory', ‘serial number', 'unlocked', 'battery' and 'camera'. A further difference with the conventional approach is that one or more of the attributes 76 can be marked as ‘quantity aware', and in this example the colour, memory and serial number have been so marked.

As in the example in Fig. 2, the customer orders 5 PhoneAs with three different configurations (the same configurations as in Fig. 2). Block 80 represents the shopping cart into which the order is placed, and block 80 also represents the instantiation of the products in the Service Registry/Charging System. Using the new approach, the shopping cart/SR/CS 80 includes an instance 82a for the PhoneA in black and with 128 GB of memory, and the instance 82a indicates a quantity of 3. The shopping cart/SR/CS 80 also includes an instance 82b for the other two PhoneAs in the order. Instance 82b indicates the attributes that are common to those PhoneAs, i.e. 128 GB of memory, and indicates the number of PhoneAs instance 82b relates to. The shopping cart/SR/CS 80 also includes a quantity-related instance 84 that indicates the different colour configurations for the two PhoneAs covered by instance 82b. Thus, quantity-related instance 84 indicates the colours red and blue. Thus, using this approach, the first PhoneAs having the same attribute values are grouped into one instance 82a with a quantity field representing the actual number of realized instances (i.e. 3). The other two PhoneAs are grouped into a separate instance 82b with quantity-related attributes being associated with them which represents the customization done during the order by the customer.

The new approach for managing instances shown in Fig. 3 would save a lot of memory and disk footprint as well as reduce the CPU cycles needed to manipulate them. In some embodiments, the quantity-related attributes can be 'lazily' loaded only when needed, either for display, or for modification purposes. For example, usually the customer is only interested in viewing the product(s)/service(s) they have ordered and how many they have ordered, and are less interested in viewing unique information such as a serial number of each product purchased. Hence, the system doesn't need to always load unique information such as serial numbers for thousands of products and send it to the user interface system. Therefore ‘lazy loading' is used so that the database entries including the serial numbers are not automatically retrieved, and they are only loaded if the customer requests it.

Fig. 4 illustrates a part of a solution for providing, ordering and provisioning of a product/service offering according to embodiments of the techniques described herein. The solution in Fig. 4 is shown as comprising a number of different systems, which are also referred to herein as "system nodes”. While these systems/system nodes are illustrated in Fig. 4 as separate components, it will be appreciated that the functionality of multiple system nodes can be comprised in, or provided by, a single apparatus, computing device, server, etc. Fig. 4 shows a Catalog Manager (CM) system/system node 102, an Order Care system/system node 104 that includes an Order Capturing (OC) system/system node and an Order Management (OM) system/system node, and a Service Registry (SR)ZCharging System (OS) system/system node 106. A representation of the customer user interface (Ul) 108 to the Order Care system/system node 104 and SR/CS 106 is also shown.

The CM 102 offers modelling supporting large quantities of products/services. Thus, the CM 102 stores information on one or more product/service offerings/specifications 110, where each product/service offering 110 has one or more configurable or selectable quantity-independent characteristics or attributes 112, a configurable or selectable quantity 114, one or more configurable or selectable quantity-dependent characteristics or attributes 116 (i.e. attributes that are configurable per quantity 114) and the price 118 of the product offering 1 10. The product offering price 118 may depend on the quantity 114. Thus, the CM 102 supports offerings/specifications 110 which are ‘quantity aware'. The CM 102 can also have the capability to define characteristics where the number of instances depends on the quantity.

Continuing the 'PhoneA' example in Fig. 3, the memory size, serial number and colour are quantity aware (i.e. quantity dependent) characteristics 116, and battery size and camera specifications are quantity independent characteristics 112. The price the user has to pay for the order will depend on how many PhoneAs have been ordered. Therefore, it would be possible in the Catalog Manager system node 102 to determine the total price as the quantity times the price per product.

In general, a product/service offering 110 can be classified into quantity aware or quantity unaware offerings. The CM 102, during creation of a product/service offering would be able to choose between the offering being quantity aware or quantity unaware. Quantity unaware offerings are the traditional offerings for the business-to-consumer (B2C) mobile domain like use-cases, and are not the subject of this disclosure. Instead, the disclosure relates to quantity aware offerings. Thus, a quantity aware offering 110 has the quantity field 114 which is used during ordering and installed base time to hold or store the quantity ordered by the customer. The CM 102 will also support the creation of characteristics/attributes 112, 116 (a pattern which enables extending any specification), and classify each attribute/characteristic as either quantity independent characteristics 112 (these are the set of characteristics which represents same value for the entire quantity of product ordered, for example, the resolution of a connected security camera) or quantity dependent characteristics 116 (these are the set of characteristics whose value will be unique for each instance ordered, for example, the serial number for each connected security camera). The product/service offering price 118 of the offering 110 can also be enhanced to understand the quantity attribute 114. This can help build a pricing model based on the quantity ordered.

The order capturing system should understand the product modelling and support the ordering of large quantities of products/services. The order management system should understand the large-quantity ordering and orchestrate to underlying integrations accordingly. Thus, the order care system 104 provides a shopping cart 120 that customers add their desired products/services to. The shopping cart 120 provides a container 122 to which the products/services are added. In Fig. 4, the customer has added one product to the shopping cart 120, as indicated by entity instance 124, with each entity instance 124 indicating the quantity-independent characteristic/attribute(s) 126 selected for that entity instance by the customer (e.g. 128GB storage, 8GB RAM, red, etc.), and a quantity 128. The container 122 also includes quantity-related instances 130 (also known as the ‘slim instances') with the associated characteristics/attributes 132.

Continuing the 'PhoneA' example in Fig. 3, the memory size, serial number and colour selected for the order are quantity aware (i.e. quantity dependent) characteristics 130 since they vary across the ordered PhoneAs, and battery size and camera specifications are quantity independent characteristics 126 since they are the same for all ordered PhoneAs. It will be appreciated that specific characteristics may be quantity dependent in one customer's order, but quantity independent in another customer's order if those characteristics are different for different PhoneAs in that customer's order.

The order care system 104 also includes a qualification block 134 that communicates with the CM 102 to obtain the quantity-based specifications and provides these to the container 122. Thus, the qualification block 134 fetches and displays product offers, which are made available to be purchased by a customer (e.g. an operator).

Following the catalog-driven architecture, the order capture system should be able to understand quantity aware specifications 110 created by the Catalog Manager 102. If a quantity-based specification 110 is ordered by the customer, the order capture system should only instantiate only one product instance (i.e. one entity instance 124) of this specification 110, where the quantity is determined by the quantity field 128 exposed by the specification 110. In case there are quantity dependent characteristics 130 defined, an on-demand capability would be introduced by these systems which can provide customisation of each instance based on the quantity ordered and served in a paginated way. The order capture system will be able to store the quantity dependent characteristics 130 as associated instances to the main instance 124. The order capture system will be able to pass on this complete information to an order management system for order fulfilment. The order management system should be able to understand if the ordered instance is based on a quantity-based specification 110. It should be able to obtain the quantity information 128 and based on fulfilment logic built for the customer use-case, should be able to procure/provision that many instances for delivery/provisioning for the customer. The order management system should also be able to provision the entity instance 124 with the quantity information 128 and its associated instances 130 to the installed base system (the SR 106).

Thus, according to the operation of the order care system 104, only one instance of the specification is created in the shopping cart 120 (the instance being the entity instance 124). Based on the quantity 128, related instances 130 are created, with the number of related instances 130 being equal to the value of the quantity 128.

Once the order is confirmed, the order is instantiated in the SR/CS 106. The SR 106, also referred to as the customer installed base system, should be able to persist the purchased products/services and its related slim associated instances. The SR 106 should be able to paginate and return slim associated instances as needed. The SR 106 may also be able to provide a 'lazy' loading capability for the quantity based related instances so that the loading of the installed base on user interfaces 108 is faster and the per instance-based details are only loaded when needed by the customer.

The information on the products/services ordered via the order capture system is added to the charging records 136 for the relevant customer in the charging system 106. The charging system 106 should be able to persist single product/service instances 138 and their attributes 140, along with quantity based associated instances 144. The charging system 106 should also be able use the associated quantity information for rating.

Therefore the information in the charging records 136 includes the entity instance 138, with each entity instance 138 indicating the quantity-independent characteristic/attribute(s) 140 selected for that entity instance by the customer (e.g. 128GB storage, 8GB RAM, red, etc.), the quantity 142, the quantity-related instances 144 with the associated characteristics/attributes 146. The SR/CS 106 also includes a smart queries block 148 that receives queries from the customer via the Ul 108, so that the customer can view details of the products/services. In particular, the smart queries block 148 provides capability to return minimum information about the customer's install base without providing details of quantity-based information. Queries can support fine grained criteria to load a subset or a complete set of quantitybased information as needed by the end user.

The Ul 108 (which may be or include separate Uls for the different systems, 102, 104 and 106, should be able to understand the large quantities concept and render the Ul accordingly, including providing paginated quantity based related instances in case they are required. The Ul 108 provides a visual graphic 150 of the shopping cart, enables the customer to place queries to the SR/Cs 106 via a customer 360 Ul element 152, and includes a discovery element 154. The discovery element 154 operates in a similar way to the qualification block 134 to fetch and display product/service offers to the customer.

Fig. 5 is a signalling/sequence diagram illustrating various operations of the above systems/system nodes according to the aspects and embodiments described herein. Fig. 5 shows the signalling/sequences between a user/customer 200, a Ul 201 , an OC system node 202, an OM/CS system node 203, a customer installed based system node 204, a CM system node 205 and an Inventory system node 206.

The signalling/sequence diagram in Fig. 5 relates to a product offering named "Sensor”. This product has been created in the CM 205, and the Sensor is a quantity aware product offering. Hence, it has the quantity attribute as well as two categories of attributes which are quantity independent attributes and quantity dependent attributes. In this example, the quantity independent attributes include the Region, which describes the geographical region in which the sensors would be installed (with possible values of, e.g. North and South), and Sensitivity, which describes the sensitivity level of the sensors (with possible values of, e.g. High and Medium). The quantity dependent attributes include the Serial Number, which is the serial number of each Sensor instance. The sequence in Fig. 5 represents a scenario in which the customer 200 orders 1000 instances of the sensor which are dedicated for Region: North, and 500 instances of the sensor which are dedicated for Region: South. In order to depict how the independent and dependent attributes are treated, the sequence diagram shows Order Capture system node 202 interacting with the inventory system 206 to obtain the serial numbers for the sensors. The serial number is a quantity dependent attribute and is represented as related attributes created under an instance of sensors. It should be noted that the quantity independent attributes are not repeated with the quantity of sensors ordered which saves a lot of memory and disk space when storing and retrieving the details of the order. A new instance of sensors is only created when the value of any quantity independent attribute is different from an existing sensor instance. Hence, sensors purchased for Region: North and Region: South have led to the creation of two instances of Sensors. Since the quantity of the sensors ordered is represented by the quantity attribute, it does not require N number of instances of the same sensors to be created in the system. For related instances, the flow in Fig. 5 depicts only one way of accessing the related information lazily, though there could be multiple ways of ‘lazy loading' that could be implemented.

Thus, at 211 , the user 200 browses for available product offerings using the user interface 201. The User Interface 201 forwards the request to the Catalog Manager 205, which returns the Sensor as a product offering. This request and return of information is represented by signal 212.

The User interface 201 interprets the product offering as a quantity aware product offering and displays the quantity of sensors to be ordered as well as other attributes based on its category accordingly. The display of the information to the user 200 is represented by signal 213.

At 214, the user 200 customises the Sensors to be ordered by setting the quantity to 1000, the Region to North, and Sensitivity to high in the Ul 201. The User interface 201 forwards the received request (the customised order) to the Order Capturing system 202, as shown by signal 215.

The OC system 202 examines the product offering for the received order and identifies it to be a quantity aware specification. Therefore, the OC system 202 creates one instance for all 1000 quantities ordered (step 216). The OC system 202 sets the quantity independent attributes Region and Sensitivity in the instance that was created to the required values (i.e. North and high, respectively).

The Order Capturing system 202 then sends one or more requests 217 to the Inventory system 206 to obtain the serial numbers for each sensor, and creates 1000 related 'slim' instances allocating serial numbers to each slim instance. Block 218 illustrates the single instance for 1000 sensors created by the OC system 202 at step 216, and the slim instances indicating the respective serial numbers.

The User 200 then makes another order of 500 sensors with Region: South and Sensitivity: medium. Thus, at 219, the user 200 customises the Sensors to be ordered by setting the quantity to 500, the Region to South, and Sensitivity to medium in the Ul 201. The User interface 201 forwards the received request (the customised order) to the Order Capturing system 202, as shown by signal 220.

The OC system 202 examines the product offering for the received order and identifies it to be a quantity aware specification. The OC system 202 attempts to match the quantity independent attributes specified for the order with existing instances created in the shopping cart. Since the values for Region and Sensitivity don't match, the OC system 202 creates a new instance for all 500 quantities ordered (step 221), and this is a separate instance to the 1000- quantity instance created in step 216. For the new instance, the OC system 202 sets the quantity independent attributes Region and Sensitivity in the instance to the required values (i.e. South and medium, respectively).

The Order Capturing system 202 then sends one or more requests 222 to the Inventory system 206 to obtain the serial numbers for each sensor, and creates 500 related 'slim' instances allocating serial numbers to each slim instance. Block 223 illustrates the single instance for 1000 sensors created by the OC system 202 at step 216, and the slim instances indicating the respective serial numbers.

At 224 the user 200 submits the order via the Ul 201 . The User Interface 201 forwards the submit order request to the Order Capturing System 202 (signal 225).

The Order Capturing System 202 then creates an order towards the Order Management System 203, as shown by signal 226. The Order Management System 203 also understands the quantity aware specification and runs customer specific provisioning logic (step 227). The customer specific provisioning logic refers to a set of steps where the Order Management System 203 looks into the associated service and resource attached to the product purchased and determines how to handle them. For example, if the product enables a 5G service for the user, then it will issue a command to the network to enable a 5G service. In another example, if the user has provided a 'top-up' to their account balance, then that amount would be noted by the Charging System 203.

The Order Management system 203 calls the Customer Installed Base 204/Charging System 203 to persist the ordered instance information in the Installed Base 204, as shown by signal 228. Thus, the Order Management system

203 provides the order information to the Charging System 203 and to the Installed Base 204, so that these systems store the order information. In particular, both systems store the order information using the ‘slim instances' format, so they persist the two instances of the sensors, and their related slim instances (the serial numbers).

Block 229 illustrates the information stored at the Installed Base 204. This information corresponds to that shown in block 223 for the shopping cart.

Subsequently, the user 200 may wish to access its installed base 204 to find out details of their products/services. Thus, at 230 the User 200 requests access to its installed base 204 via the Ul 201. The User Interface 201 forwards the request to Customer Installed base system 204 (signal 231). The customer installed base

204 by default returns only the main instance to the Ul 201 (signal 232), which depicts the grouped information of ordered sensors. This may be the most frequently accessed use-case for the user 200. This returned main instance information is shown in block 233, and includes the main instances of the two types of sensors, but does not include the information in the ‘slim instances'. The Ul 201 renders the information provided from the installed base for viewing by the user 200 (step 234).

If the user 200 is interested in viewing details associated with each individual instance of the sensors (for example if the user 200 wants to view the serial number), at step 235 the user 200 requests the User interface 201 to provide the details. The User interface 201 forwards the request to the Customer Installed base system 204 (signal 236). In some embodiments, the request 235/236 may only require the retrieval of the specific information for only a subset of the products, for example for the first few instances. As noted in Fig. 5, the request 236 can specify that ‘n’ related instances of the Sensor should be retrieved (where n is much smaller than N, the total number of Sensors), or specify specific instances to be retrieved (i.e. by indicating specific serial numbers). This approach will avoid the system from having to load thousands of instances at the same time. The Customer Installed base 204 returns the requested information (e.g. all of the instances, or a subset of the instances) - signal 237. The User Interface 201 renders the received information for viewing by the user 200.

So, as noted above, the techniques described herein address the problem of how a specification can be modelled in a commercial catalog manager to enable the ordering of that specification by a customer in large quantities. The techniques described herein enable the specification to be rendered so that the customer is able to provide the quantity that they intend to order, and also to efficiently configure and store the attributes associated with the specification, which conventionally would be applied to each instance ordered. In particular, the techniques described herein captures orders in a very memory and CPU efficient manner as it creates only one instance depicting n quantities ordered. Thus the order capture system creates a minimal set of instances which holds information per quantity ordered, thus saving memory footprint and computation overheads in a significant way. The techniques described herein also enable Order Management systems to understand the quantity, and stream the custom processing per instance in a sequential or parallel way as per customer requirements using minimal memory footprint. Further, the techniques described herein enable the Customer installed base to be represented with minimal memory and storage footprint. The techniques described herein can also allow the Customer Installed base to allow lazy loading and rendering of related instances as they are typically not needed by the customer every time, thus reducing memory and CPU footprint on itself as well as on client systems. The techniques described herein also allows bulk order modifications with minimal footprint, as most of the attributes are common across multiple instances of sensors and they are represented by one instance in memory. For example, if the customer wanted to change the Region attribute for all 1000 sensors, this change could be applied by changing only the single instance in the memory representing all 1000 sensors. The techniques described herein can provide a 0(1) time and space complexity for handling n number of quantities ordered for a product in case there is no instance specific characteristics associated, whereas conventional implementations would have O(n) time and space complexity. Finally, the techniques described herein can provide that if a product offering has an instance-specific characteristic, it is assumed that for IOT use-cases it will be very small in number when compared to common characteristics. Therefore, in those cases too, the compute and memory requirements will increase only for handling those additional characteristics. As an example, if 10% of the characteristics are instance specific, then there is a saving of 90% in space and time complexity in handling those instances.

Fig. 6 is a block diagram of a system node 600 in accordance with various aspects described herein. The system node 600 can implement any one or more of the Catalog Manager 102, 205, Order Capture system 202, Order Management system 203, Order Care system 104, Service Registry 106, Charging System 106, 203, the Ul 108, 201, customer installed base 204, and inventory system 206. As used herein, the system node 600 may be or comprise various combinations hardware and/or software, including a standalone server, a blade server, a cloud-implemented server, a distributed server, a virtual machine, container, or processing resources in a server farm.

The system node 600 includes processing circuitry 602 that is operatively coupled via a bus 604 to an input/output interface 606, a network interface 608, a power source 610, and a memory 612. Other components may be included in other embodiments.

The processing circuitry 602 may comprise a combination of one or more of a microprocessor, controller, microcontroller, central processing unit, digital signal processor, application-specific integrated circuit, field programmable gate array, or any other suitable computing device, resource, or combination of hardware, software and/or encoded logic operable to provide, either alone or in conjunction with other system node 600 components, such as the memory 612, to provide system node 600 functionality. For example, the processing circuitry 602 may be configured to cause the system node 600 to perform the methods as described with reference to Figs. 4, 5 and 8. In some embodiments, the processing circuitry 602 includes a system on a chip (SOC).

The memory 612 may comprise any form of volatile or non-volatile computer-readable memory including, without limitation, persistent storage, solid-state memory, remotely mounted memory, magnetic media, optical media, random access memory (RAM), read-only memory (ROM), mass storage media (for example, a hard disk), removable storage media (for example, a flash drive, a Compact Disk (CD) or a Digital Video Disk (DVD)), and/or any other volatile or non-volatile, non-transitory device-readable and/or computer-executable memory devices that store information, data, and/or instructions that may be used by the processing circuitry 602. The memory 612 may store any suitable instructions, data, or information, including a computer program, software, an application including one or more of logic, rules, code, tables, and/or other instructions capable of being executed by the processing circuitry 602 and utilized by the system node 600. The memory 612 may be used to store any calculations made by the processing circuitry 602 and/or any data received via the input/output interface 606 or network interface 608. In some embodiments, the processing circuitry 602 and memory 612 are integrated.

The input/output interface 606 and/or network interface 608 are used in wired or wireless communication of signalling and/or data between system nodes 600, for example the signalling shown in Fig. 5.

The input/output interface 606, network interface 608 and/or the processing circuitry 602 may be configured to perform any operations described herein as being performed by a system node. Any information, data and/or signals may be received from a user via a Ul, or from another system node 600.

The power source 610 provides power to the various components of system node 600 in a form suitable for the respective components (e.g. at a voltage and current level needed for each respective component). The power source 610 may further comprise, or be coupled to, power management circuitry to supply the components of the system node 600 with power for performing the functionality described herein. For example, the system node 600 may be connectable to an external power source (e.g. the power grid, an electricity outlet) via an input circuitry or interface such as an electrical cable, whereby the external power source supplies power to power circuitry of the power source 610. As a further example, the power source 610 may comprise a source of power in the form of a battery or battery pack which is connected to, or integrated in, power circuitry. The battery may provide backup power should the external power source fail.

Embodiments of the system node 600 may include additional components beyond those shown in Fig. 6 for providing certain aspects of the system's functionality, including any of the functionality described herein and/or any functionality necessary to support the subject matter described herein. For example, the system node 600 may include user interface equipment to allow input of information into the system node 600 and to allow output of information from the system node 600. This may allow a user to perform diagnostic, maintenance, repair, and other administrative functions for the system node 600.

The memory 612 may include one or more computer programs including one or more application programs 614 and data 616, which may include customer data, e.g. data relating to a customer and/or a customer's order. Embodiments of the system node 600 may utilize only a subset or all of the components shown. The application programs 614 may be implemented in a container-based architecture. The application programs 614 may be configured to cause the system node 600 to operate as any of the Catalog Manager 102, 205, Order Capture system 202, Order Management system 203, Order Care system 104, Service Registry 106, Charging System 106, 203, the Ul 108, 201 , customer installed base 204, and inventory system 206.

Fig. 7 is a block diagram illustrating a virtualization environment 700 in which functions implemented by some embodiments may be virtualized. In the present context, virtualizing means creating virtual versions of apparatuses or devices which may include virtualizing hardware platforms, storage devices and networking resources. As used herein, virtualization can be applied to any system node described herein, or components thereof, and relates to an implementation in which at least a portion of the functionality is implemented as one or more virtual components. Some or all of the functions described herein may be implemented as virtual components executed by one or more virtual machines (VMs) implemented in one or more virtual environments 700 hosted by one or more hardware nodes, such as a hardware computing device that operates as system node 600.

Applications 702 (which may alternatively be called software instances, virtual appliances, virtual nodes, virtual functions, etc.) are run in the virtualization environment 700 to implement some of the features, functions, and/or benefits of some of the embodiments disclosed herein.

Hardware 704 includes processing circuitry, memory that stores software and/or instructions executable by hardware processing circuitry, and/or other hardware devices as described herein, such as a network interface, input/output interface, and so forth. Software may be executed by the processing circuitry to instantiate one or more virtualization layers 706 (also referred to as hypervisors or virtual machine monitors (VMMs)), provide VMs 708a and 708b (one or more of which may be generally referred to as VMs 708), and/or perform any of the functions, features and/or benefits described in relation with some embodiments described herein. The virtualization layer 706 may present a virtual operating platform that appears like networking hardware to the VMs 708.

The VMs 708 comprise virtual processing, virtual memory, virtual networking or interface and virtual storage, and may be run by a corresponding virtualization layer 706. Different embodiments of the instance of a virtual appliance 702 may be implemented on one or more of VMs 708, and the implementations may be made in different ways. Virtualization of the hardware is in some contexts referred to as function virtualization (FV). FV may be used to consolidate many types of system node onto industry standard high volume server hardware, physical switches, and physical storage, which can be located in data centers, and customer premise equipment.

In the context of FV, a VM 708 may be a software implementation of a physical machine that runs programs as if they were executing on a physical, non-virtualized machine. Each of the VMs 708, and that part of hardware 704 that executes that VM, be it hardware dedicated to that VM and/or hardware shared by that VM with others of the VMs, forms separate virtual elements. Still in the context of FV, a virtual function is responsible for handling specific functions that run in one or more VMs 708 on top of the hardware 704 and corresponds to the application 702.

Hardware 704 may be implemented in a standalone system with generic or specific components. Hardware 704 may implement some functions via virtualization. Alternatively, hardware 704 may be part of a larger cluster of hardware (e.g. such as in a data center) where many hardware nodes work together and are managed via management and orchestration 710, which, among others, oversees lifecycle management of applications 702. In some embodiments, some signalling can be provided with the use of a control system 712 which may alternatively be used for communication between system nodes.

Although the computing devices described herein (e.g. system nodes) may include the illustrated combination of hardware components, other embodiments may comprise computing devices with different combinations of components. It is to be understood that these computing devices may comprise any suitable combination of hardware and/or software needed to perform the tasks, features, functions and methods disclosed herein. Determining, calculating, obtaining or similar operations described herein may be performed by processing circuitry, which may process information by, for example, converting the obtained information into other information, comparing the obtained information or converted information to information stored in the system node, and/or performing one or more operations based on the obtained information or converted information, and as a result of said processing making a determination. Moreover, while components are depicted as single boxes located within a larger box, or nested within multiple boxes, in practice, computing devices may comprise multiple different physical components that make up a single illustrated component, and functionality may be partitioned between separate components. For example, a communication interface may be configured to include any of the components described herein, and/or the functionality of the components may be partitioned between the processing circuitry and the communication interface. In another example, non-computationally intensive functions of any of such components may be implemented in software or firmware and computationally intensive functions may be implemented in hardware.

In certain embodiments, some or all of the functionality described herein may be provided by processing circuitry executing instructions stored on in memory, which in certain embodiments may be a computer program product in the form of a non-transitory computer-readable storage medium. In alternative embodiments, some or all of the functionality may be provided by the processing circuitry without executing instructions stored on a separate or discrete device-readable storage medium, such as in a hard-wired manner. In any of those particular embodiments, whether executing instructions stored on a non-transitory computer-readable storage medium or not, the processing circuitry can be configured to perform the described functionality. The benefits provided by such functionality are not limited to the processing circuitry alone or to other components of the computing device, but are enjoyed by the computing device as a whole and/or by end users generally.

Fig. 8 is a flow chart illustrating a method according to various embodiments performed by an order capture system node 600, such as OC/OM node 104 in Fig. 4, or the order capture system node 202 in Fig 5. The order capture system node 600 is provided to capture and manage orders for products and/or services in a communication network. The order capture system node 600 may perform the method in response to executing suitably formulated computer readable code. The computer readable code may be embodied or stored on a computer readable medium, such as a memory chip, optical disc, or other storage medium. The computer readable medium may be part of a computer program product.

In a first step, 801 , the order capture system node 600 receives a first order request for a first type of product and/or service for use in the communication network. The first order request indicates (I) a first quantity of the first type of product and/or service to be ordered (with the quantity being greater than one), and (ii) respective values for a plurality of attributes individually configured or selected for each of the ordered first type of product and/or service.

In step 803, the order capture system node 600 creates a first entry in an order database for the first order request. The first entry identifies (I) the first type of product and/or service, (ii) the first quantity to be ordered; and (ill) the values of any attribute that is common to all of the ordered first type of product and/or service.

In step 805, the order capture system node 600 creates sub-entries in the order database for the first entry. Each sub-entry corresponds to a respective one of the ordered first type of product and/or service, and each sub-entry comprises values of any attribute that is not common to all of the other ones of the ordered first type product and/or service. In some embodiments, the method further comprises the order capture system node 600 sending the first entry and associated sub-entries to an order management system and/or a charging system.

In some embodiments, the method further comprises the order capture system node 600 receiving a specification for the first type of product and/or service from a catalog manager system node. The specification indicates the attributes that are to be configured or selected for the first type of product and/or service. In these embodiments, the received specification may indicate a subset of the plurality of attributes that have values common to any instance of the first type of product and/or service. These attributes are the quantity-independent attributes. In some embodiments, the received specification indicates a subset of the plurality of attributes that can have different values for different instances of the first type of product and/or service. These attributes are the quantity-dependent attributes.

In some embodiments, the method further comprises receiving a second order request for the first type of product and/or service for use in the communication network, the second order request indicating (i) a second quantity of the first type of product and/or service to be ordered (with the second quantity being greater than one), and (ii) respective values for a plurality of attributes individually configured or selected for each of the first type of product and/or service in the second order request, where the attributes for which the values are common to all of the ones of the first type of product and/or service in the second order request are different to the attributes in the first order request. The method can then comprise the step of creating a second entry in the order database for the second order request, the second entry identifying: (i) the first type of product and/or service, (ii) the second quantity to be ordered; and (iii) the values of any attribute that is common to all of the ordered first type of product and/or service in the second order request; and creating sub-entries in the order database for the second entry, each sub-entry corresponding to a respective one of the ordered first type of product and/or service, and each sub-entry comprising values of any attribute that is not common to all of the other ones of the ordered first type product and/or service in the second order request.

In some embodiments, the first order request relates to a first type of product, and values of one or more of the plurality of attributes are unique to each instance of the first type of product. In these embodiments, the method further comprises sending a first inventory request to an inventory system to allocate stock of the first type of product to the first order request, and to provide values of one or more attributes that are unique to each instance of the first product in the allocated stock; receiving a first inventory response from the inventory system that indicates the unique values of the one or more attributes for each instance of the first product in the allocated stock; and storing the received unique values in respective sub-entries of the first entry in the order database.

In some embodiments, the attributes that are not common to all of the other ones of the ordered first type comprise one or more attributes that are unique to each instance of the product and/or service. In these embodiments, the one or more attributes that are unique to each instance of the product and/or service comprises any of: a product serial number, a unique device identifier, and an International Mobile Equipment Identity, IMEI.

A method of operating a system may also be provided. The system comprises an order capture system node 600 that operates as described above, and a charging system. The charging system operates to maintain a charging system database comprising a first entry corresponding to the first entry stored in the order database; and when a product and/or service is used in the communication network, the charging system receives a value of one or more attributes of the used product and/or service. The charging system can then query the charging system database to identify a sub-entry corresponding to the used product and/or service; and store information relating to the use of the product and/or service in the communication network in the charging system database. In embodiments where there are one or more attributes that are unique to each instance of the product and/or service, the order capture system node 600 can receive a value of the one or more attributes that are unique to an instance of the product and/or service.

The foregoing merely illustrates the principles of the disclosure. Various modifications and alterations to the described embodiments will be apparent to those skilled in the art in view of the teachings herein. It will thus be appreciated that those skilled in the art will be able to devise numerous systems, arrangements, and procedures that, although not explicitly shown or described herein, embody the principles of the disclosure and can be thus within the scope of the disclosure. Various exemplary embodiments can be used together with one another, as well as interchangeably therewith, as should be understood by those having ordinary skill in the art.

Claims

1. A computer-implemented method of operating an order capture system node for products and/or services for use in a communication network, the method comprising: receiving (801) a first order request for a first type of product and/or service for use in the communication network, the first order request indicating (i) a first quantity of the first type of product and/or service to be ordered, wherein the quantity is greater than one, and (ii) respective values for a plurality of attributes individually configured or selected for each of the ordered first type of product and/or service; creating (803) a first entry in an order database for the first order request, the first entry identifying: (i) the first type of product and/or service, (ii) the first quantity to be ordered; and (iii) the values of any attribute that is common to all of the ordered first type of product and/or service; and creating (805) sub-entries in the order database for the first entry, each sub-entry corresponding to a respective one of the ordered first type of product and/or service, and each sub-entry comprising values of any attribute that is not common to all of the other ones of the ordered first type product and/or service.

2. A method as claimed in claim 1 , wherein the method further comprises: sending the first entry and associated sub-entries to an order management system and/or a charging system.

3. A method as claimed in claim 1 or 2, wherein the method further comprises: receiving a specification for the first type of product and/or service from a catalog manager system node, wherein the specification indicates the attributes that are to be configured or selected for the first type of product and/or service.

4. A method as claimed in claim 3, wherein the received specification indicates a subset of the plurality of attributes that have values common to any instance of the first type of product and/or service.

5. A method as claimed in claim 3 or 4, wherein the received specification indicates a subset of the plurality of attributes that can have different values for different instances of the first type of product and/or service.

6. A method as claimed in any of claims 1 -5, wherein the method further comprises: receiving a second order request for the first type of product and/or service for use in the communication network, the second order request indicating (i) a second quantity of the first type of product and/or service to be ordered, wherein the second quantity is greater than one, and (ii) respective values for a plurality of attributes individually configured or selected for each of the first type of product and/or service in the second order request, wherein the attributes for which the values are common to all of the ones of the first type of product and/or service in the second order request are different to the attributes in the first order request; creating a second entry in the order database for the second order request, the second entry identifying: (I) the first type of product and/or service, (ii) the second quantity to be ordered; and (ill) the values of any attribute that is common to all of the ordered first type of product and/or service in the second order request; and creating sub-entries in the order database for the second entry, each sub-entry corresponding to a respective one of the ordered first type of product and/or service, and each sub-entry comprising values of any attribute that is not common to all of the other ones of the ordered first type product and/or service in the second order request.

7. A method as claimed in any of claims 1-6, wherein the first order request relates to a first type of product, and wherein values of one or more of the plurality of attributes are unique to each instance of the first type of product, wherein the method further comprises: sending a first inventory request to an inventory system, wherein the first inventory request is a request to allocate stock of the first type of product to the first order request, and to provide values of one or more attributes that are unique to each instance of the first product in the allocated stock; receiving a first inventory response from the inventory system that indicates the unique values of the one or more attributes for each instance of the first product in the allocated stock; and storing the received unique values in respective sub-entries of the first entry in the order database.

8. A method as claimed in any of claims 1-7, wherein the attributes that are not common to all of the other ones of the ordered first type comprises one or more attributes that are unique to each instance of the product and/or service.

9. A method as claimed in claim 8, wherein the one or more attributes that are unique to each instance of the product and/or service comprises any of: a product serial number, a unique device identifier, and an International Mobile Equipment Identity, IMEI.

10. A computer-implemented method of operating a system, the method comprising: operating an order capture system node (600) as claimed in any of claims 1-9; and operating a charging system by: maintaining a charging system database, the charging system database comprising a first entry corresponding to the first entry stored in the order database; when a product and/or service is used in the communication network, receiving a value of one or more attributes of the used product and/or service; querying the charging system database to identify a sub-entry corresponding to the used product and/or service; and storing information relating to the use of the product and/or service in the communication network in the charging system database.

11. A method as claimed in claim 10, wherein the order capture system node is operated as claimed in claim 8 or 9; and wherein the step of receiving a value of one or more attributes of the used product and/or service comprises receiving a value of one or more attributes that are unique to an instance of the product and/or service.

12. A computer program product comprising a computer readable medium having computer readable code embodied therein, the computer readable code being configured such that, on execution by a suitable computer or processor, the computer or processor is caused to perform the method of any of claims 1-11 .

13. An order capture system node (600) for capturing orders for products and/or services for use in a communication network, the order capture system node (600) configured to: receive a first order request for a first type of product and/or service for use in the communication network, the first order request indicating (I) a first quantity of the first type of product and/or service to be ordered, wherein the quantity is greater than one, and (ii) respective values for a plurality of attributes individually configured or selected for each of the ordered first type of product and/or service; create a first entry in an order database for the first order request, the first entry identifying: (I) the first type of product and/or service, (ii) the first quantity to be ordered; and (ill) the values of any attribute that is common to all of the ordered first type of product and/or service; and create sub-entries in the order database for the first entry, each sub-entry corresponding to a respective one of the ordered first type of product and/or service, and each sub-entry comprising values of any attribute that is not common to all of the other ones of the ordered first type product and/or service.

14. An order capture system node (600) as claimed in claim 13, further configured to: send the first entry and associated sub-entries to an order management system (203) and/or a charging system (203).

15. An order capture system node (600) as claimed in claim 13 or 14, further configured to: receive a specification for the first type of product and/or service from a catalog manager system node (205), wherein the specification indicates the attributes that are to be configured or selected for the first type of product and/or service.

16. An order capture system node (600) as claimed in claim 15, wherein the received specification indicates a subset of the plurality of attributes that have values common to any instance of the first type of product and/or service.

17. An order capture system node (600) as claimed in claim 15 or 16, wherein the received specification indicates a subset of the plurality of attributes that can have different values for different instances of the first type of product and/or service.

18. An order capture system node (600) as claimed in any of claims 13-17, further configured to: receive a second order request for the first type of product and/or service for use in the communication network, the second order request indicating (I) a second quantity of the first type of product and/or service to be ordered, wherein the second quantity is greater than one, and (ii) respective values for a plurality of attributes individually configured or selected for each of the first type of product and/or service in the second order request, wherein the attributes for which the values are common to all of the ones of the first type of product and/or service in the second order request are different to the attributes in the first order request; create a second entry in the order database for the second order request, the second entry identifying: (I) the first type of product and/or service, (ii) the second quantity to be ordered; and (ill) the values of any attribute that is common to all of the ordered first type of product and/or service in the second order request; and create sub-entries in the order database for the second entry, each sub-entry corresponding to a respective one of the ordered first type of product and/or service, and each sub-entry comprising values of any attribute that is not common to all of the other ones of the ordered first type product and/or service in the second order request.

19. An order capture system node (600) as claimed in any of claims 13-18, wherein the first order request relates to a first type of product, and wherein values of one or more of the plurality of attributes are unique to each instance of the first type of product, wherein the order capture system node (600) is further configured to: send a first inventory request to an inventory system (206), wherein the first inventory request is a request to allocate stock of the first type of product to the first order request, and to provide values of one or more attributes that are unique to each instance of the first product in the allocated stock; receive a first inventory response from the inventory system (206) that indicates the unique values of the one or more attributes for each instance of the first product in the allocated stock; and store the received unique values in respective sub-entries of the first entry in the order database.

20. An order capture system node (600) as claimed in any of claims 13-19, wherein the attributes that are not common to all of the other ones of the ordered first type comprises one or more attributes that are unique to each instance of the product and/or service.

21 . An order capture system node (600) as claimed in claim 20, wherein the one or more attributes that are unique to each instance of the product and/or service comprises any of: a product serial number, a unique device identifier, and an International Mobile Equipment Identity, IMEI.

22. A system, the system comprising: an order capture system node (600) as claimed in any of claims 13-21 ; and a charging system (203) configured to: maintain a charging system database, the charging system database comprising a first entry corresponding to the first entry stored in the order database; when a product and/or service is used in the communication network, receive a value of one or more attributes of the used product and/or service; query the charging system database to identify a sub-entry corresponding to the used product and/or service; and store information relating to the use of the product and/or service in the communication network in the charging system database.

23. A system as claimed in claim 22, wherein the order capture system node (600) is configured as claimed in claim 20 or 21 ; and wherein the charging system (203) is configured to receive a value of one or more attributes of the used product and/or service that are unique to an instance of the product and/or service.

24. An order capture system node for capturing orders for products and/or services for use in a communication network, the order capture system node comprises a processor and a memory, said memory containing instructions executable by said processor whereby said order capture system node is operative to: receive a first order request for a first type of product and/or service for use in the communication network, the first order request indicating (i) a first quantity of the first type of product and/or service to be ordered, wherein the quantity is greater than one, and (ii) respective values for a plurality of attributes individually configured or selected for each of the ordered first type of product and/or service; create a first entry in an order database for the first order request, the first entry identifying: (i) the first type of product and/or service, (ii) the first quantity to be ordered; and (ill) the values of any attribute that is common to all of the ordered first type of product and/or service; and create sub-entries in the order database for the first entry, each sub-entry corresponding to a respective one of the ordered first type of product and/or service, and each sub-entry comprising values of any attribute that is not common to all of the other ones of the ordered first type product and/or service.

25. An order capture system node as claimed in claim 24, further operative to: send the first entry and associated sub-entries to an order management system and/or a charging system.

26. An order capture system node as claimed in claim 24 or 25, further operative to: receive a specification for the first type of product and/or service from a catalog manager system node, wherein the specification indicates the attributes that are to be configured or selected for the first type of product and/or service.

27. An order capture system node as claimed in claim 26, wherein the received specification indicates a subset of the plurality of attributes that have values common to any instance of the first type of product and/or service.

28. An order capture system node as claimed in claim 26 or 27, wherein the received specification indicates a subset of the plurality of attributes that can have different values for different instances of the first type of product and/or service.

29. An order capture system node as claimed in any of claims 24-28, further operative to: receive a second order request for the first type of product and/or service for use in the communication network, the second order request indicating (I) a second quantity of the first type of product and/or service to be ordered, wherein the second quantity is greater than one, and (ii) respective values for a plurality of attributes individually configured or selected for each of the first type of product and/or service in the second order request, wherein the attributes for which the values are common to all of the ones of the first type of product and/or service in the second order request are different to the attributes in the first order request; create a second entry in the order database for the second order request, the second entry identifying: (I) the first type of product and/or service, (ii) the second quantity to be ordered; and (ill) the values of any attribute that is common to all of the ordered first type of product and/or service in the second order request; and create sub-entries in the order database for the second entry, each sub-entry corresponding to a respective one of the ordered first type of product and/or service, and each sub-entry comprising values of any attribute that is not common to all of the other ones of the ordered first type product and/or service in the second order request.

30. An order capture system node as claimed in any of claims 24-29, wherein the first order request relates to a first type of product, and wherein values of one or more of the plurality of attributes are unique to each instance of the first type of product, wherein the order capture system node is further operative to: send a first inventory request to an inventory system, wherein the first inventory request is a request to allocate stock of the first type of product to the first order request, and to provide values of one or more attributes that are unique to each instance of the first product in the allocated stock; receive a first inventory response from the inventory system that indicates the unique values of the one or more attributes for each instance of the first product in the allocated stock; and store the received unique values in respective sub-entries of the first entry in the order database.

31. An order capture system node as claimed in any of claims 24-30, wherein the attributes that are not common to all of the other ones of the ordered first type comprises one or more attributes that are unique to each instance of the product and/or service.

32. An order capture system node as claimed in claim 31 , wherein the one or more attributes that are unique to each instance of the product and/or service comprises any of: a product serial number, a unique device identifier, and an International Mobile Equipment Identity, IMEI.

33. A system, the system comprising: an order capture system node as claimed in any of claims 24-32; and a charging system that comprises a processor and a memory, said memory containing instructions executable by said processor whereby said charging system is operative to: maintain a charging system database, the charging system database comprising a first entry corresponding to the first entry stored in the order database; when a product and/or service is used in the communication network, receive a value of one or more attributes of the used product and/or service; query the charging system database to identify a sub-entry corresponding to the used product and/or service; and store information relating to the use of the product and/or service in the communication network in the charging system database.

34. A system as claimed in claim 33, wherein the order capture system node is operative as claimed in claim 31 or 32; and wherein the charging system is operative to receive a value of one or more attributes of the used product and/or service that are unique to an instance of the product and/or service.