Methods and systems to process asynchronous transactions at a management system

A method comprises receiving an add instruction to add a new account to a subscriber database at the system, wherein the add instruction indicates a line identifier and a first source identifier, wherein the line identifier identifies a line activated by the new account, wherein a first source identifier identifies a first carrier billing system from which the request to add the new account is received, when an existing account indexed by the line identifier is present at the subscriber database, deleting, by the provisioning application, the existing account from the subscriber database, and adding, by the provisioning application, the new account associated with the line identifier at the subscriber database, wherein the new account indicates the first source identifier.

CROSS-REFERENCE TO RELATED APPLICATIONS

Not applicable.

REFERENCE TO A MICROFICHE APPENDIX

Not applicable.

BACKGROUND

Companies with many subscribers often aggregate subscriber data into large back-end systems to support their products and service offerings. As companies grow, they may acquire customers through mergers, which may have additional brands and lines of business. Subscribers who may be customers from different brands or lines of business may need to be consolidated into common back end systems.

Consolidation of subscriber data from multiple sources can create provisioning problems in back end systems. Race conditions, for example, may occur where subscriber data is deleted and re-added by different provisioning systems. If these provisioning transactions are sent to back-end systems out of order, the back end may not be able to process them in the correct order, invalidating the resulting data.

Telecommunications consolidation, in particular, can suffer from this problem in which phone numbers and SIM card numbers, often used as identifiers for subscribers, are reused and ported between brands and lines of business. If subscriber data is incorrectly provisioned, the user may not be able to use services and products correctly.

For example, a parent telecommunications service provider or carrier may own multiple sub-carriers or brands, some of which may include, for example, pre-paid wireless service providers, post-paid wireless service providers, mobile virtual network operators, etc. In this case, each of the sub-carriers may access the same carrier network resources (including, for example, a radio access network (RAN) and a core network) owned and operated by the parent carrier. Each of the sub-carriers may also be associated with a different set of subscribers, each of which may be respectively registered with the sub-carrier. The sub-carriers are included under the umbrella of the parent carrier, and the parent carrier may be contracted to manage subscribers using a single Identity and Access Management (IAM) system.

In this case, an IAM system may include a set of servers designed to implement a platform to provide the processes, technologies, and policies for managing digital identities and controlling how those identities can be used to access carrier network resources. A subscriber may access the IAM system by logging into a carrier website, mobile application, or sub-carrier website, to manage a subscriber account or use supported applications and services. The IAM system authenticates the subscriber upon log-in using, for example, a username, password, biometric information, and/or one-time codes. The IAM system also provides the subscriber access to subscriber account information, such as, for example, contracts, phone numbers associated with each contract, rate plans, billing features, etc. The IAM system also provides access to digital services such as Internet of Things (IoT) device access, banking, telephony and messaging.

SUMMARY

In an embodiment, a method performed by a system comprising consolidated subscriber data in communication with a plurality of provisioning middlewares to provision transactions asynchronously. The method comprises receiving, by a provisioning application at the system from a first provisioning middleware, an add instruction to add a new account to a subscriber database at the system, wherein the add instruction indicates a line identifier and a first source identifier, wherein the line identifier identifies a line activated by the new account, wherein a first source identifier identifies a first carrier billing system from which the first provisioning middleware received a request to add the new account, and wherein the first provisioning middleware is communicatively coupled to the first carrier billing system, determining, by the provisioning application, an existing account indexed by the line identifier that is present at the subscriber database after receiving the add instruction, and when the existing account indexed by the line identifier is present at the subscriber database, deleting, by the provisioning application, the existing account from the subscriber database, and adding, by the provisioning application, the new account associated with the line identifier at the subscriber database, wherein the new account indicates the first source identifier.

In another embodiment, a method performed by a system to provision transactions asynchronously. The method comprises receiving, by a provisioning application at the system from a provisioning middleware, an add instruction to add a new account to a subscriber database at the system, wherein the add instruction comprises a line identifier and a first source identifier, wherein the line identifier identifies a line activated by the new account, and wherein the first source identifier identifies a first carrier billing system from which the provisioning middleware received a request to add the new account, after receiving the add instruction to add a new account to a subscriber database, receiving, by the provisioning application from the provisioning middleware, a delete instruction to delete an existing account from the subscriber database at the system, wherein the delete instruction comprises the line identifier and a second source identifier, and wherein the second source identifier identifies a second carrier billing system from which the provisioning middleware received a request to delete the existing account, adding, by the provisioning application, the new account associated with the line identifier to the subscriber database, wherein the new account is indexed by the line identifier and indicates the first source identifier, determining, by the provisioning application, the existing account at the subscriber database that is also indexed by the line identifier, wherein the existing account indicates an existing source identifier, determining, by the provisioning application, whether the second source identifier in the delete instruction matches the existing source identifier in the existing account, and deleting, by the provisioning application, the existing account from the subscriber database when the second source identifier in the delete instruction matches the existing source identifier in the existing account.

In yet another embodiment, a system comprising at least one processor, at least one non-transitory memory, one or more provisioning middlewares communicatively coupled to a first carrier billing system and a second carrier billing system, and a provisioning application of the system, stored in the at least one non-transitory memory is disclosed. The one or more provisioning middlewares are configured to transmit, to a system, an add instruction to add a new account to a subscriber database at the system, wherein the add instruction indicates a line identifier and a first source identifier, wherein the line identifier identifies a line activated by the new account, and wherein a first source identifier identifies a first carrier billing system, and transmit, to a system, a delete instruction to delete an existing account from the subscriber database at the system, wherein the delete instruction indicates the line identifier and a second source identifier, and wherein the second source identifier identifies a second carrier billing system. The provisioning application, when executed by the at least one processor, causes the at least one processor to be configured to receive the add request, receive the delete request after the add request is received, add the new account associated with the line identifier at the subscriber database with the first source identifier such that the new account is indexed by the line identifier, determine the existing account at the subscriber database that is also indexed by the line identifier, wherein the existing account indicates an existing source identifier, determine whether the second source identifier in the delete instruction matches the existing source identifier in the existing account, and delete the existing account from the subscriber database when the second source identifier in the delete instruction matches the existing source identifier in the existing account.

DETAILED DESCRIPTION

As mentioned above, a parent telecommunications carrier may own multiple sub-carriers or brands, some of which may include, for example, pre-paid wireless service providers, post-paid wireless service providers, mobile virtual network operators, etc. In some cases, each of the sub-carriers may share the same network resources belonging to the parent carrier network. The parent carrier network may be a network operated by the parent carrier company, and may include, for example, a RAN and a core network. Each of the sub-carriers may also include a different set of subscribers, and each subscriber may be registered with a separate sub-carrier billing system in a sub-carrier subscriber database.

The parent carrier may be contracted with a single IAM system, which is responsible for authenticating and managing subscriber accounts across all the sub-carriers. To this end, the IAM system may maintain a subscriber database with information describing each of the subscribers across all of the sub-carriers in individual subscriber accounts. For example, each subscriber account may include identification information of the subscriber (e.g., name, address, etc.), contracts with the carrier or sub-carrier, line identifiers associated with each contract, rate plans, etc. The IAM system may maintain different subscriber database or data stores for each sub-carrier, or the IAM system may maintain a single subscriber database or data store for the parent carrier, with different memory ranges allocated to each of the sub-carriers. For example, a line identifier may be Mobile Subscriber Integrated Services Digital Network (MSISDN) number uniquely identifying a subscription of the device, an International Mobile Subscriber Identity (IMSI) identifying a Subscriber Identity Module (SIM) card or profile of the device, or any other value uniquely assigned to a line or a device, which is to be registered or already registered with a sub-carrier or carrier network.

The core network of the carrier network may include a different carrier billing system (sometimes referred to herein as simply a “billing system”) for each sub-carrier. The billing system for a particular sub-carrier may be responsible for implementing the processes for billing and invoicing subscribers of the sub-carrier. Each carrier billing system may include servers and databases storing information describing the subscriber and billing details for each subscriber. For example, the carrier billing system may include payment functions for automating the process of collecting payments, sending out recurring invoices, expense tracking, invoice tracking, etc.

In some cases, a carrier billing system may communicate with other entities in a network through a provisioning middleware at the core network. For example, a provisioning middleware may be a Home Subscriber Server (HSS), Home Location Register (HLR), or any other component of the core network. In some cases, a single provisioning middleware may be coupled to and responsible for forwarding communications to and from multiple carrier billing systems. In other cases, a single provisioning middleware may be coupled to and responsible for forwarding communications to and from only one carrier billing system. In addition, each carrier billing system in the core network may operate completely independently, in the sense that the carrier billing systems do not coordinate or communicate with each other when processing transactions. This may result in the IAM system receiving transactions in an incorrect order, which may cause other technical issues at the core network and IAM system.

For example, a single subscriber account may include one or more lines, each associated with a different line identifier (e.g., MSISDN) and potentially a different contract. The term “account” as used herein may refer to an entire subscriber account or a line in a subscriber account indexed by a line identifier. A subscriber of a first sub-carrier may enter a retail store of the parent carrier, asking to transfer service of a line (e.g., phone number, line of service, device, etc.) from a first sub-carrier to a second sub-carrier (both owned by the same parent carrier). Alternatively, a subscriber of a first sub-carrier may manually request the transfer of service from the first sub-carrier to the second sub-carrier by cancelling an account at the first sub-carrier and adding a new account at the second sub-carrier. In either case, the transfer of service at the IAM system may include two provisioning transactions: (1) the deletion of a line at the first sub-carrier; and (2) the addition of a line at the second sub-carrier. A provisioning request device, which may be a subscriber device or a retail store device, may transfer the two requests respectively corresponding to the foregoing two provisioning transactions. For example, the provisioning request device transmits the request to delete the account linked to a carrier billing system of the first sub-carrier, and transmits the request to add the account linked to a carrier billing system of the second sub-carrier, and each request may include the line identifier of the line.

The carrier billing systems of the first sub-carrier and second sub-carrier separately receive these provisioning requests, and process these requests entirely independently, without considering the request received at the other carrier billing system. For example, the carrier billing system of the second sub-carrier may process the request first, by adding information regarding the added device to the carrier billing system, and forwarding the request to a provisioning middleware. The provisioning middleware may forward, to the IAM system, the request and other information used to add the account to, for example, subscriber data associated with the second sub-carrier.

At this stage, the IAM system has received the request to add the account at the second sub-carrier with the line identifier, before receiving the request to delete the account at the first sub-carrier with the same line identifier. The IAM system may be configured to reject this request to add the account because the IAM system may already recognize that the line identifier of the device being added is already indicated in the subscriber database at the IAM system. In other words, the IAM system may see the request to add the account as redundant or illegitimate due to the line identifier already being stored at the subscriber database, and deny the request.

Subsequently, the carrier billing system of the first sub-carrier may transmit, via a provisioning middleware to the IAM system, the request to delete the account linked to the device from the subscriber database at the IAM system. The IAM system may process this request to delete the account linked to the device, which results in the IAM system entirely cancelling the account linked to the device. After which, the owner of the device may not be able to use the IAM system to access an account linked to the line.

Therefore, the lack of synchronization between carrier billing systems while communicating with the IAM system results delayed in communications with the IAM system. The delay in communications may result in transactions being received at the IAM system in an incorrect order which, as described above, may result in the cancellation of the account associated with the device at the IAM system. The delays may also result in the cancellation of network services for the device when the network provisioning uses a similar architecture and process for provisioning subscriber data. In some cases, error handling may continuously try to re-send transactions to the carrier billing systems and the IAM system, when the transaction fails. This may cause additional technical problems, such as, for example, overloading transaction queues at the systems, causing some transactions to be lost completely, while significantly increasing the load on the network. Additional complications, such as redundant charges to the subscriber, may also arise in the case when transactions are re-sent due to initial failure.

Disclosed herein are embodiments directed to enhancing communications between the carrier billing systems and the IAM system, to prevent failure at the IAM system due to receiving provisioning transactions at the IAM system in an incorrect order. In some embodiments, a provisioning application at the IAM system may add an account linked to an identifier of the line to the subscriber database when a request to add the account is received, regardless of whether the line identifier is already present at the subscriber database. In the case when the line identifier is already present at the subscriber database, the provisioning application may automatically delete the existing account indexed by the line identifier, after receiving the request to add the account and without receiving a request to delete the account.

In an embodiment, a first carrier billing system may receive a request to add an account associated with a line identifier of a device, while a second carrier billing system receives a request to delete the account associated with the line identifier. The first carrier billing system may add the account into the billing system, and then forward a request to the provisioning middleware associated with the first carrier billing system. This request may include a source identifier of the first carrier billing system, which may be used to identify the source billing system of the request. The provisioning middleware may gather information related to the request, and generate an add instruction to add the account including the information and the source identifier of the first carrier billing system. The provisioning middleware may transmit the add instruction to the IAM system.

A provisioning application at the IAM system may receive the add instruction and add the account associated with the line identifier to the subscriber database at the IAM system. In an embodiment, the provisioning application may additionally store the source identifier of the first carrier billing system with the newly added account, in which the source identifier indicates the source of the newly added account. In another embodiment in which different data stores or portions of the subscriber database store information for subscribers of different sub-carriers, the provisioning application may ensure that the newly added account is stored in the data store or in the portion of the subscriber database dedicated to the first carrier and/or the first carrier billing system.

In an embodiment, the provisioning application may also search the subscriber database to determine whether the line identifier is already indicated with an existing subscriber account in the subscriber database. If so, the provisioning application may automatically delete the existing account before completing the request to add the subscriber data. In this case, since the billing system holds the master copy of the data, the provisioning application may be configured to prioritize the new request to add data over the data already in the database. The newly added subscriber data may include the source identifier of the first carrier billing system. The provisioning application may also send a response to the provisioning request to indicate success.

After receiving the request to delete, the second carrier billing system may delete the account associated with the line identifier from the billing system, and then forward the request to the provisioning middleware associated with the second carrier billing system. This request may include a source identifier of the second carrier billing system, which may be used to identify the source of the data. The provisioning middleware may gather information related to the request to delete, and generate a delete instruction to delete the account including the information and the source identifier of the second carrier billing system. The provisioning middleware may transmit the delete instruction to the IAM system.

At this stage, the IAM system may search the subscriber database and, using the source identifier stored in the IAM subscriber database, recognize that the line identifier stored at the subscriber database is associated with a source identifier of the first carrier billing system, since this account was recently added. Meanwhile, the delete instruction includes a source identifier of the second carrier billing system. In this case, the source identifier received in the delete instruction is different from the source identifier stored with the line identifier at the subscriber database of the IAM system. The provisioning application may recognize that the delete instruction may be ignored due to the mismatch of source identifiers, and ensure that the delete transaction does not delete data from the database. Nevertheless, the provisioning application may still transmit a response with an acknowledgment back to the carrier billing systems and/or the provisioning request device indicating success. In other words, the provisioning application may still transmit an acknowledgement that both transactions from the first and second billing systems were successful, even though the transaction requests or instructions were received out of order.

Subsequently, the provisioning request device103may transmit a request to update a subscriber account at the IAM system110through the first carrier billing system. The first carrier billing system may be updated locally, and then the first carrier billing system may forward the request to update including details regarding the update to the provisioning middleware. In an embodiment, the request to update also includes a source identifier of the first carrier billing system. The provisioning middleware may generate an update instruction including the source identifier of the first carrier billing system, and send the update instruction to the IAM system.

The provisioning application at the IAM system may search the subscriber database and recognize that the line identifier stored at the subscriber database is associated with a source identifier of the first carrier billing system, since this account was recently added. Meanwhile, the update instruction also includes a source identifier of the first carrier billing system. In this case, the source identifier received in the instruction is the same as the source identifier stored with the line identifier at the subscriber database of the IAM system. The provisioning application may recognize that the source identifiers match, and permit processing the update of the subscriber account at the subscriber database of the IAM system based on the update instruction.

In another case, the source identifier received in the instruction may not match the source identifier stored with the line identifier at the subscriber database of the IAM system. In this case, the provisioning application may not the update in the IAM subscriber database since the initial request to update was received from an incorrect source carrier billing system, as indicated by the source identifier in the update instruction. Nevertheless, the provisioning application may still transmit a response including an acknowledgement that the update was successful, even though the update may not have been actually performed.

As described, the embodiments disclosed herein provide a technical solution to the foregoing technical problem, by configuring the IAM system to process requests to transfer accounts between sub-carriers or brands regardless of the order of the received requests. This prevents the IAM system from inadvertently cancelling an account related to a device that should still be activated at the IAM. Further, by sending an acknowledgment indicating success of transfer or update, regardless of whether the transfer or update was performed, the provisioning requests are prevented from being repeatedly re-sent. Failure alarms are also prevented from unnecessarily consuming computing resources at the systems. Thus, the acknowledgements may provide a technical solution to the foregoing technical problem by reducing the queries to the IAM system and/or carrier billing systems, while also significantly reducing the load on network resources at the carrier network (i.e., to increase bandwidth and capacity at the carrier network).

Turning now toFIG.1, a communication system100is described. The system100comprises a provisioning request device103, a carrier network108, an IAM system111, a cell site114, and a network117. The provisioning request device103may be communicatively coupled to the carrier network108, network117, and/or the IAM system111via the cell site114.

The provisioning request device103may be a cell phone, a mobile phone, a smart phone, a personal digital assistant (PDA), an Internet of things (IoT) device, a wearable computer, a headset computer, a laptop computer, a tablet computer, or a notebook computer. As mentioned above, the provisioning request device103may be a subscriber device, a device at a retail store of a carrier, or any other device capable of transmitting requests to add/delete/transfer accounts between carriers. The cell site114provides the provisioning request device103a wireless communication link to the carrier network108, network117, and/or the IAM system111according to a 5G, a long term evolution (LTE), a code division multiple access (CDMA), or a global system for mobile communications (GSM) wireless telecommunication protocol. The cell site114also provides the IAM system111a wireless communication link to the carrier network108, network117, and/or the provisioning request device103according to a 5G, a LTE, a CDMA, or a GSM wireless telecommunication protocol.

The network117may be one or more private networks, one or more public networks, the Internet, or a combination thereof. WhileFIG.1shows the carrier network108as being separate from the network117, it should be appreciated that, in some embodiments, at least a portion of the carrier network108may be part of the network117. The carrier network108may be a network including a RAN and a core network109. The RAN may include the access network containing the radio elements of a cell network, and the core network109may include the elements that manage the subscriber information, call setup and routing, and related system supports. In an embodiment, the core network109may be an evolved packet core (EPC) core network. The core network109may be configured to implement a 5G, a LTE, a CDMA, or a GSM wireless telecommunication protocol. In one embodiment, the core network109may be a 3rd Generation Partnership Project (3GPP) Evolved Packet System (EPS).

As shown inFIG.1, the core network109includes the carrier billing system120A-C (shown inFIG.1as “CBS120A-C”) and provisioning middleware123A-B, among other components of the core network109not otherwise shown inFIG.1or described herein. In an embodiment, carrier billing systems120A-C are each respectively associated with a different sub-carrier (also referred to hereinafter as “carrier”), all of which are owned and operated by the same parent carrier company. For example, the carrier billing system120A is associated with a first carrier A, the carrier billing system120B is associated with a second carrier B, and the carrier billing system120C is associated with a third carrier C. Each carrier billing system120A-C may include servers and databases storing information describing the subscriber and billing details for each subscriber. The carrier billing system120A-C for a particular carrier may be responsible for implementing the processes for billing and invoicing customers or subscribers of the carrier.

Provisioning middleware123A-B are intermediate entities in the core network109through which different components of the core network109may communicate. The provisioning middleware123A-B may convert information received from, for example, the carrier billing systems120A-C, determine the elements in the network to which to forward the information, and transmit the information over various interfaces in the correct format to the respective elements in the network. In an embodiment, the provisioning middleware123A-B may be an HSS, an HLR, or any other component of the core network109. Each provisioning middleware123A-B may be responsible for forwarding communication to and from one or more carrier billing systems120A-B. As shown inFIG.1, provisioning middleware123A is communicatively coupled to both the carrier billing systems120A and120B, while the provisioning middleware123B is communicatively coupled to only the carrier billing system120C. In an embodiment, the carrier billing systems120A-C may communicate with the provisioning middlewares123A-B over an interface126, which may be a wired or wireless link or interface.

The IAM system111may be a system of servers implementing a framework of policies and technologies to ensure that the subscribers of the carrier have the appropriate access to technology resources in the carrier network108. Subscribers may access and manage subscriber accounts133at the subscriber database130through the IAM system111. For example, a subscriber may access the subscriber account133using a carrier website, which communicates with the IAM system111, to make, view, and update the subscriber account133. For example, the subscriber may transfer services of a device, add a new line and corresponding device to a family plan, remove a line from a family plan, purchase a device, pay a bill, change a payment type or method, edit subscriber information, etc., through the IAM system111.

The IAM system111may maintain a subscriber database130storing multiple subscriber accounts133, which are accounts including information of subscribers registered with the carrier of the carrier network108. The subscriber accounts133may each indicate information regarding lines registered with the carrier, such as, line identifiers139, contracts136associated with each line, information regarding voice and data plans subscribed to by the subscriber, etc. The line identifier139may be an MSISDN, an IMSI, and/or any other value identifying the line. The contracts136represent one or more agreements between the subscriber and a carrier, regarding one or more devices. Each device registered with the subscriber account133may be considered a “line” of the subscriber account. In an embodiment, each subscriber MSISDN in the subscriber account133, may also be associated with a source identifier141. The source identifier141may identify a carrier billing system120A-B, and consequently, a carrier/sub-carrier to which the subscriber account133or line is linked, as further described herein. The source identifier141may be a unique value (e.g., alphanumeric) identifying a carrier billing system120A-B.

The subscriber accounts133may also be associated with credentials, such as a username and password, created by the subscriber upon creating the subscriber account, and other authentication information, such as biometrics and one-time passwords. The subscriber accounts133may also include identification information describing the subscriber, such as, for example, a name, address of the subscriber, account number of the subscriber, etc.

As mentioned above, when a carrier includes multiple sub-carriers and is contracted with a single IAM system111, the subscriber database130may store the subscriber data of all the subscribers across all of the sub-carriers. WhileFIG.1shows only one subscriber database130, in another embodiment, the IAM system111may maintain different subscriber databases130, or data stores, for subscribers of each of the different sub-carriers. In another embodiment, the subscriber database130may associate certain memory ranges for different sub-carriers, and the subscriber data for each of the sub-carriers may be stored in the memory ranges accordingly. The subscriber database130for the parent carrier may only include a single instance of the line identifier139, such that if multiple instances of the line identifier139are found, the IAM system111may determine that an error has occurred.

The IAM system111also includes the provisioning application145. The provisioning application145may add, delete, and update subscriber accounts133, or lines within the subscriber account133, according to communications received from the provisioning middlewares123A-B, as further described herein. The provisioning application145in the IAM system111may be communicatively coupled to the provisioning middlewares123A-B at the core network109via links151, which may be a wired or wireless link. While the links151are depicted inFIG.1as passing directly between the IAM system111and the carrier network108, it should be understood that the links151may pass via the network117. Alternatively, the provisioning application145and the provisioning middlewares123A-B may communicate with one another using one or more APIs148. The IAM system111may include the APIs148, which are interfaces used to communicate with one or more entities in the system100, such as, for example, the provisioning middlewares123A-B or the carrier billing systems120A-C. In some embodiments, the IAM system111may not include the provisioning middlewares123A-B, and instead the carrier billing systems120A-C may directly couple and communicate with the IAM system111.

In an embodiment, the IAM system111may also store mappings142, which may include a list of associations between source identifiers141of carrier billing systems120A-C and the identifiers or address of the attached provisioning middlewares123A-B. For example, the mappings142may indicate that the carrier billing systems120A and120B communicate through the provisioning middleware123A, while the carrier billing system120C communicates through the provisioning middleware123B.

Turning now toFIGS.2A-B, shown are message sequence diagrams250and275illustrating different examples of messages sent between the provisioning request device103, carrier billing systems120A-B, provisioning middleware123A, and IAM system111according to various embodiments of the disclosure.

Referring now toFIG.2A, shown is a message sequence diagram250illustrating an example case in which the IAM system111may delete the existing account linked to a line identifier139, before a delete instruction233is received. At step203, the provisioning request device103transmits a request to transfer an account associated with a device of a subscriber having a line identifier139from a carrier B to a carrier A. In other words, the subscriber may presently be a subscriber of carrier B, but may desire to change service providers to carrier A. Carrier B may own and operate the carrier billing system120B, while carrier A may own and operate the carrier billing system120A. The subscriber account113may already be provisioned in the IAM system111.

The request to transfer the account may be split into two requests: a request to add a new account at carrier A and a request to delete an existing account from carrier B. At step206, the request to delete an existing account from carrier B may be sent to the carrier billing system120B. The request to delete the existing account may include information regarding the subscriber, the existing subscriber account133, the line identifier139, an existing contract136linked to the line identifier139that is to be cancelled, and/or any other information used to delete the existing account from carrier B. Upon receiving the request to delete the existing account, the carrier billing system120B may process the request to delete the existing account locally at the carrier billing system120B based on the data in the request.

At step209, the request to add a new account at carrier A may be sent to the carrier billing system120A. The request to add a new account may include information regarding the subscriber, an existing subscriber account133if applicable, the line identifier139, a new contract136linked to the line identifier139, a rate plan, billing details, and/or any other information used to add the new account to carrier A. Upon receiving the request to add the new account, the carrier billing system120A may process the request to add the new account locally at the carrier billing system120A based on the data in the request.

The two carrier billing systems120A-B operate completely independently and do not coordinate the sequence or timing of processing the requests, and as such, the carrier billing systems120A-B may forward the requests to the provisioning middleware123A at arbitrary times relative to one another. The provisioning middleware123A may by a transactional system that does not coordinate multiple transactions for the same subscriber account. The provisioning middleware123A process transactions in the order they are received from each carrier billing system120A-B, but may not synchronize transactions from different carrier billing system120A-B. In an embodiment, the provisioning middleware123A may be a cluster of worker processes that work independently at their own rate. In the example shown inFIG.2A, the carrier billing system120A forwards the request to add the new account before the carrier billing system120B forwards the request to delete the existing account.

At step251, the carrier billing system120A forwards the request to add the new account, in some cases with additional information, to the provisioning middleware123A associated with the carrier billing system120A. In an embodiment, the forwarded request additionally includes a source identifier141identifying the source of the received request to add the new line (i.e., the carrier billing system120A). The source identifier141, and other information, may be included as a parameter in this request, to identify the source of the transaction in the request.

At step253the provisioning middleware123A may then use the data in the request to generate an add instruction216. The add instruction216may include subscriber and device information, which may be used to add the account as a new subscriber account133or a new line of an existing subscriber account133at the subscriber database130of the IAM system111. For example, the add instruction216may include subscriber information such as name, address, account number, billing details, etc. In an embodiment, the add instruction216may also include the line identifier139of the device being transferred to carrier A. In an embodiment, the add instruction216may also include a new contract136, which may be an agreement between the subscriber and the carrier A behind the carrier billing system120A, with regard to the line identified by the line identifier139.

In an embodiment, the provisioning middleware123A may also add the source identifier141to the add instruction216. The source identifier141again identifies the source billing system from which the original request was received, and in this case, the source identifier141identifies the carrier billing system120A associated with carrier A. After generating the add instruction216, the provisioning middleware123A may transmit the add instruction216to the IAM system111via link151, at step255.

At step257, after receiving the add instruction216, the provisioning application145at the IAM system111determines that the line identifier139already exists in the database130and that source identifier141stored in association with the line identifier139at the subscriber database130indicates billing system120B. Meanwhile, the source identifier in the add instruction216indicates billing system120A. Therefore, the source identifier141stored in association with the line identifier139at the IAM system111does not match the source identifier141included in the add instruction216, and since the add instruction216is an instruction to add data, the IAM system111prioritizes the add instruction216above the existing data stored at the subscriber database130.

In some embodiments, the provisioning application145may automatically begin to delete an existing account linked to the line identifier139of the account that will be added at step259only based on the add instruction216(i.e., not based on receiving any instruction to delete an existing account). That is, the provisioning application145is programmed to automatically search for and delete accounts linked to a line identifier139upon receiving a corresponding add instruction216.

At step259, the provisioning application145begins the transaction to add the new account to the subscriber database130. The provisioning application145may add a new subscriber account133with the data included in the add instruction216, in which the line identifier139is linked to a line in the newly added subscriber account133. The provisioning application145may also add a new line, linked to the line identifier139, in an existing subscriber account133. In an embodiment, the provisioning application145may also store the source identifier141of the carrier billing system120A in the subscriber account133, to which the line identifier139has been newly added.

At step260, the provisioning application145may transmit a response to the carrier billing system120A, or to the provisioning request device103, with an acknowledgement indicating that the account was successfully added to the subscriber database130at the IAM system111.

Subsequent to step259, the carrier billing system120B may forward the request to delete the existing account from carrier B to the provisioning middleware123A associated with the carrier billing system120B, at step261. In an embodiment, the forwarded request may include the source identifier141of the carrier billing system120B.

At step262, the provisioning middleware123A may use the data received in the request to delete the existing account to generate the delete instruction223. The delete instruction223may include subscriber and device information, which may be used to delete the existing account from an existing subscriber account133or a line at the subscriber database130of the IAM system111. For example, the delete instruction223may include subscriber information such as name, address, account number, billing details, etc. The delete instruction223may also include the line identifier139of the device being removed from carrier B.

In an embodiment, the provisioning middleware123A may also add the source identifier141to the delete instruction223. The source identifier141again identifies the carrier billing system120B associated with carrier B. After generating the delete instruction223, the provisioning middleware123A may transmit the delete instruction223to the IAM system111via link151, at step263.

At step265, the provisioning application145may search the subscriber database for the line identifier139, and determine that the line identifier139is stored in association with the source identifier141identifying the carrier billing system120A. However, the delete instruction223includes the source identifier141of the carrier billing system120B. Therefore, the source identifier141stored with the line identifier139at the subscriber database130does not match the source identifier141included in the delete instruction223. Since these source identifiers do not match and since the delete instruction223is an instruction to delete data, the IAM system111prioritizes the existing data above the delete instruction223. In this case, the provisioning application145may determine that the line identifier139has already been re-associated with another source carrier billing system120A, at step257, and confirm that the previous account associated with the line identifier139has already been deleted. The provisioning application145may drop or discard the delete instruction233, but still transmit a response to the carrier billing system120B, or the provisioning request device103, with an acknowledgement at step268, indicating that the success of the transferring service of the device from carrier B to carrier A at the IAM system111. In an embodiment, the IAM system may use the API148to communicate with the provisioning request device103, to transmit the acknowledgment.

Referring now toFIG.2B, shown is a message sequence diagram270illustrating an example case in which a request to delete or update an account is received at the IAM system111before the IAM system111receives a request to add the account in association with a different carrier.

Message sequence diagram250includes steps203,206, and209, which are similar to the steps203,206, and209of message sequence diagram250ofFIG.2A. However, unlike message sequence diagram250, the request at step203in message sequence diagram270may additionally include a request to update an account at carrier B. In this way, the request to delete that is sent at step209may also include a request to update an account at carrier B. For example, the request to update the account may include a request to change billing information to a cancelled state or a request to change a rate plan associated with the account.

The carrier billing system120B may first process the request to delete and/or update the account locally at the carrier billing system120B based on the data in the request. At step273, the carrier billing system120B forwards the request to delete and/or update the account, in some cases with additional information, to the provisioning middleware123A associated with the carrier billing system120B. The request may include the line identifier139of the device that is to be deleted from the account, the line identifier139or account number linked to the subscriber account133to be updated, and/or other subscription information. In an embodiment, the request may also include a source identifier141identifying the carrier billing system120B.

At step275, the provisioning middleware123A may use the data in the request to delete and/or update the account to generate a delete and/or update instruction276. The delete and/or update instruction276may include subscriber and device information, which may be used to delete and/or update the account in a subscriber account133at the subscriber database130of the IAM system111. In an embodiment, the provisioning middleware123A may also add the source identifier141identifying the carrier billing system120B to the delete and/or update instruction276. After generating the delete and/or update instruction276, the provisioning middleware123A may transmit the delete and/or update instruction276to the IAM system111via link151, at step277.

At step279, the provisioning application145at the IAM system111may search for the subscriber account133in the subscriber database130using the line identifier139indicated in the delete and/or update instruction276. The provisioning application145may then determine the source identifier141stored with the line identifier139at the subscriber database130. The provisioning application145may compare the source identifier141at the subscriber database130with the source identifier141identifying the carrier billing system120B in the delete and/or update instruction276. When the source identifier141at the subscriber database130matches the source identifier141identifying the carrier billing system120B in the delete and/or update instruction276, the provisioning application145may successfully process the transaction to delete the account or update the account at the subscriber database130. When the source identifier141at the subscriber database130fails to match the source identifier141identifying the carrier billing system120B in the delete and/or update instruction276, the provisioning application141may drop or discard delete and/or update instruction276. In this case, the provisioning application145may not perform the transaction to delete the account or update the account at the subscriber database130.

At step280, the provisioning application145transmits, to carrier billing system120B or the provisioning request device103, a response including an acknowledgement indicating the success of the deleting or updating service performed at step279.

At any point after step273is performed, the carrier billing system120A may transmit a request to add a new account to the provisioning middleware123A, at step281. Step281may be similar to step251of the messaging sequence diagram250. At step283, the provisioning middleware123A may then use the data in the request to generate an add instruction216, similar to step253of the messaging sequence diagram250. At step285, the provisioning middleware123A may transmit the add instruction216to the IAM system111via link151.

At step288, the provisioning application145at the IAM system may add the new account to the subscriber database130, if the account is not already present in the subscriber database130. If the account (e.g., the line identifier139) is already present in the subscriber database130, the provisioning application145may delete the already present account, using the techniques described herein.

At step291, the provisioning application145transmits, to the carrier billing system120A or the provisioning request device103, a response including an acknowledgement indicating the success of the adding service to carrier A at the IAM system111.

Turning now toFIG.3, shown is a message sequence diagram300illustrating a method implemented by the system ofFIG.1. Message sequence diagram300shows examples of messages sent between the provisioning request device103, carrier billing systems120A and120C, provisioning middleware123A and123B, and IAM system111according to various embodiments of the disclosure. Message sequence diagram300is similar to the message sequence diagrams250and270, except that message sequence diagram300is implemented by the carrier billing system120C instead of carrier billing system120B, and that the message sequence diagram300further includes messages transmitted to and from the provisioning middleware123B. Since the carrier billing system120C is sending messages in message sequence diagram300, the provisioning middleware123B associated with the carrier billing system120C may also be included in the method as an intermediary entity used to forward messages to and from the carrier billing system120C.

Steps303,306, and309of message sequence diagram300are similar to steps203,206, and209of message sequence diagram250and270ofFIGS.2A-B, respectively. However, unlike message sequence diagram250and270, the provisioning request device103transmits a request to transfer a device identified by line identifier139from carrier C associated with the carrier billing system120C to carrier A associated with the carrier billing system120A. In addition, at step309, the request to delete the existing account is sent to the carrier billing system120C.

At step311, the carrier billing system120A may forward the request to add the new account to the provisioning middleware123A associated with the carrier billing system120A. Step313may be similar to step251of the message sequence diagram250.

At step313, the carrier billing system120C may forward the request to delete the existing account from carrier C to the provisioning middleware123C associated with the carrier billing system120C. Step313may be similar to step261of the message sequence diagram250.

At step315, the provisioning middleware123A may generate an add instruction317, which may be similar to the add instruction216described above. The add instruction317may include a source identifier141identifying the carrier billing system120A. In an embodiment, the add instruction317may include an identifier or address of the provisioning middleware123A. At step321, the provisioning middleware123A may transmit the add instruction317to the IAM system111via link151. In an embodiment, the add instruction317may include an identifier or address of the provisioning middleware123B.

At step323, the provisioning middleware123B may generate a delete instruction324, which may be similar to the delete instruction223described above, except that the delete instruction may not include the source identifier141identifying the carrier billing system120C. In some embodiments, the carrier billing systems120A-C or the provisioning middlewares123A-B may determine the source identifier141identifying the carrier billing system120A-C, and either the carrier billing systems120A-C or the provisioning middlewares123A-B may add the source identifier141to an instruction223. In other embodiments, the IAM system111may determine the source identifier141from certain data, or authentication (e.g., the username of the API request). At step327, the provisioning middleware123B may transmit the delete instruction324to the IAM system111via link151.

In this case, the provisioning middleware123B may not need to add the source identifier141to the delete instruction324because the provisioning middleware123B is only attached to one carrier billing system120C, which may be indicated in the locally stored mappings142. As mentioned above, the mappings142include a list of associations between source identifiers141of carrier billing systems120A-C and the identifiers or address of the attached provisioning middlewares123A-B.

In this embodiment, when the IAM system111receives the delete instruction324, the provisioning application145may perform a look-up at the mappings142using the address or identifier of the provisioning middleware123B received in the delete instruction324, at step330. Based on the look-up, the provisioning application145may determine the source identifier141corresponding to the address or identifier of the provisioning middleware123B.

At step333, the provisioning application145at the IAM system111adds the new account to the subscriber database130, using the techniques described above with reference to message sequence diagrams250and270. At step336, the provisioning application145may delete an existing account linked to the line identifier139, based on the source identifier141determined at step330. In this case, the add instruction317may succeed because the source identifier141in the add instruction317does not match the source identifier141stored in the subscriber database130in association with the line identifier139, and because the add instruction317is an instruction to add data to the IAM system111. In this case, the provisioning middleware123B prioritizes the add instruction317, and may drop the delete instruction324.

At step338, the IAM system111may transmit a response to the carrier billing system120C or the provisioning request device103indicating whether the request at step306(i.e., the delete instruction324) was successful or not. At step339, the IAM system111may transmit a response to the carrier billing system120A or the provisioning request device103indicating whether the request at step309(i.e., the add instruction317) was successful or not, in a manner to prevent re-attempting transmission of the request.

Turning now toFIG.4, a method400is described. Method400may be performed by the provisioning application145at the IAM system111after the provisioning application145receives the add instruction216and delete instruction223. At block403, method400comprises receiving, by a provisioning application145at the IAM system111from a provisioning middleware123A, an add instruction216to add a new account to a subscriber database130at the IAM system111. In an embodiment, the add instruction216comprises a line identifier139and a first source identifier141. The line identifier139may identify a device activated by the new account or a new line to an existing account. The first source identifier141may identify a first carrier billing system120A from which the provisioning middleware123A received a request to add the new account.

After receiving the add instruction216, at block406, method400comprises receiving, by the provisioning application145from the provisioning middleware123A, a delete instruction223to delete the existing account, or an existing line, from the subscriber database130at the IAM system111. In an embodiment, the delete instruction223comprises the line identifier139and a second source identifier141. The second source identifier141may identify a second carrier billing system120B from which the provisioning middleware123A received a request to delete the existing account.

At block409, method400comprises adding, by the provisioning application145, the new account associated with the line identifier139at the subscriber database130with the first source identifier141, such that the new account is indexed by the line identifier139. At block412, method400comprises determining, by the provisioning application145, the existing account at the subscriber database130that is also indexed by the line identifier139. The existing account may indicate an existing source identifier141. At block415, method400comprises determining, by the provisioning application145, whether the second source identifier141in the delete instruction223matches the existing source identifier141in the existing account. At block418, method400comprises deleting, by the provisioning application145, the existing account from the subscriber database130when the second source identifier141in the delete instruction116matches the existing source identifier141in the existing account.

Turning now toFIG.5, a method500is described. Method500may be performed by the provisioning application145at the IAM system111after the provisioning application receives the add instruction216or317. At block503, method500comprises receiving, by a provisioning application145at the IAM system111from a first provisioning middleware123A, an add instruction216or317to add a new account to a subscriber database130at the IAM system111. In an embodiment, the add instruction216or317comprises a line identifier139and a first source identifier141. The line identifier139may identify a line activated by the new account. The first source identifier141may identify a first carrier billing system120A from which the first provisioning middleware123A received a request to add the new account. The first provisioning middleware123A may be communicatively coupled to the first carrier billing system120A.

At block506, method500comprises determining, by the provisioning application145, an existing account indexed by the line identifier139that is present at the subscriber database130, after receiving the add instruction216or317. When the existing account indexed by the line identifier is present at the subscriber database130, method500proceeds to blocks509and518. At block509, method500comprises deleting, by the provisioning application145, the existing account from the subscriber database130. The existing account may be deleted from the subscriber database130, without receiving any delete instructions223or324. At block518, method500comprises adding, by the provisioning application145, the new account associated with the line identifier139at the subscriber database130with the first source identifier141, such that the new account is indexed by the line identifier139.

In an embodiment, subsequent to deleting the existing account from the subscriber database130, method500may comprise receiving, by the provisioning application145, a delete instruction223or324to delete the existing account from the subscriber database130. The delete instruction223or324may indicate the line identifier139. In an embodiment, the second carrier billing system120may be the only billing system coupled to the second provisioning middleware123B. After receiving the delete instruction223or324, method500may comprise determining, by the provisioning application145, a second source identifier141identifying the second carrier billing system120C from which the second provisioning middleware123B received the request to delete the existing account. In an embodiment, the provisioning application145may determine that the existing account stored in association with the second source identifier141has already been deleted. In another embodiment, the provisioning application145may determine that the second source identifier141in the delete instruction223or324does not match the first source identifier141stored in association with the newly added account, indexed by the line identifier139. In either case, the provisioning application145may ignore or discard the delete instruction223or324, and transmit, via an API148, a response to the provisioning request device103indicating a success of deleting the existing account.

Turning now toFIG.6A, an exemplary communication system550is described. In an embodiment, the communication system550may be implemented in the system100ofFIG.1. The communication system550includes a number of access nodes554that are configured to provide coverage in which UEs552, such as cell phones, tablet computers, machine-type-communication devices, tracking devices, embedded wireless modules, and/or other wirelessly equipped communication devices (whether or not user operated), or devices such as the carrier hotspot device105, can operate. The access nodes554may be said to establish an access network556. The access network556may be referred to as RAN in some contexts. In a 5G technology generation an access node554may be referred to as a gigabit Node B (gNB). In 4G technology (e.g., LTE technology) an access node554may be referred to as an eNB. In 3G technology (e.g., CDMA and GSM) an access node554may be referred to as a base transceiver station (BTS) combined with a base station controller (BSC). In some contexts, the access node554may be referred to as a cell site or a cell tower. In some implementations, a picocell may provide some of the functionality of an access node554, albeit with a constrained coverage area. Each of these different embodiments of an access node554may be considered to provide roughly similar functions in the different technology generations.

In an embodiment, the access network556comprises a first access node554a, a second access node554b, and a third access node554c. It is understood that the access network556may include any number of access nodes554. Further, each access node554could be coupled with a core network558that provides connectivity with various application servers559and/or a network560. In an embodiment, at least some of the application servers559may be located close to the network edge (e.g., geographically close to the UE552and the end user) to deliver so-called “edge computing.” The network560may be one or more private networks, one or more public networks, or a combination thereof. The network560may comprise the public switched telephone network (PSTN). The network560may comprise the Internet. With this arrangement, a UE552within coverage of the access network556could engage in air-interface communication with an access node554and could thereby communicate via the access node554with various application servers and other entities.

The communication system550could operate in accordance with a particular radio access technology (RAT), with communications from an access node554to UEs552defining a downlink or forward link and communications from the UEs552to the access node554defining an uplink or reverse link. Over the years, the industry has developed various generations of RATs, in a continuous effort to increase available data rate and quality of service for end users. These generations have ranged from “1G,” which used simple analog frequency modulation to facilitate basic voice-call service, to “4G”—such as Long Term Evolution (LTE), which now facilitates mobile broadband service using technologies such as orthogonal frequency division multiplexing (OFDM) and multiple input multiple output (MIMO).

Recently, the industry has been exploring developments in “5G” and particularly “5G NR” (5G New Radio), which may use a scalable OFDM air interface, advanced channel coding, massive MIMO, beamforming, mobile mmWave (e.g., frequency bands above 24 GHz), and/or other features, to support higher data rates and countless applications, such as mission-critical services, enhanced mobile broadband, and massive Internet of Things (IoT). 5G is hoped to provide virtually unlimited bandwidth on demand, for example providing access on demand to as much as 20 gigabits per second (Gbps) downlink data throughput and as much as 10 Gbps uplink data throughput. Due to the increased bandwidth associated with 5G, it is expected that the new networks will serve, in addition to conventional cell phones, general internet service providers for laptops and desktop computers, competing with existing ISPs such as cable internet, and also will make possible new applications in internet of things (IoT) and machine to machine areas.

In accordance with the RAT, each access node554could provide service on one or more radio-frequency (RF) carriers, each of which could be frequency division duplex (FDD), with separate frequency channels for downlink and uplink communication, or time division duplex (TDD), with a single frequency channel multiplexed over time between downlink and uplink use. Each such frequency channel could be defined as a specific range of frequency (e.g., in radio-frequency (RF) spectrum) having a bandwidth and a center frequency and thus extending from a low-end frequency to a high-end frequency. Further, on the downlink and uplink channels, the coverage of each access node554could define an air interface configured in a specific manner to define physical resources for carrying information wirelessly between the access node554and UEs552.

Without limitation, for instance, the air interface could be divided over time into frames, subframes, and symbol time segments, and over frequency into subcarriers that could be modulated to carry data. The example air interface could thus define an array of time-frequency resource elements each being at a respective symbol time segment and subcarrier, and the subcarrier of each resource element could be modulated to carry data. Further, in each subframe or other transmission time interval (TTI), the resource elements on the downlink and uplink could be grouped to define physical resource blocks (PRBs) that the access node could allocate as needed to carry data between the access node and served UEs552.

In addition, certain resource elements on the example air interface could be reserved for special purposes. For instance, on the downlink, certain resource elements could be reserved to carry synchronization signals that UEs552could detect as an indication of the presence of coverage and to establish frame timing, other resource elements could be reserved to carry a reference signal that UEs552could measure in order to determine coverage strength, and still other resource elements could be reserved to carry other control signaling such as PRB-scheduling directives and acknowledgement messaging from the access node554to served UEs552. And on the uplink, certain resource elements could be reserved to carry random access signaling from UEs552to the access node554, and other resource elements could be reserved to carry other control signaling such as PRB-scheduling requests and acknowledgement signaling from UEs552to the access node554.

The access node554, in some instances, may be split functionally into a radio unit (RU), a distributed unit (DU), and a central unit (CU) where each of the RU, DU, and CU have distinctive roles to play in the access network556. The RU provides radio functions. The DU provides L1 and L2 real-time scheduling functions; and the CU provides higher L2 and L3 non-real time scheduling. This split supports flexibility in deploying the DU and CU. The CU may be hosted in a regional cloud data center. The DU may be co-located with the RU, or the DU may be hosted in an edge cloud data center.

Turning now toFIG.6B, further details of the core network558are described. In an embodiment, the core network558is a 5G core network. 5G core network technology is based on a service based architecture paradigm. Rather than constructing the 5G core network as a series of special purpose communication nodes (e.g., an HSS node, an MME node, etc.) running on dedicated server computers, the 5G core network is provided as a set of services or network functions. These services or network functions can be executed on virtual servers in a cloud computing environment which supports dynamic scaling and avoidance of long-term capital expenditures (fees for use may substitute for capital expenditures). These network functions can include, for example, a user plane function (UPF)579, an authentication server function (AUSF)575, an access and mobility management function (AMF)576, a session management function (SMF)577, a network exposure function (NEF)570, a network repository function (NRF)571, a policy control function (PCF)572, a unified data management (UDM)573, a network slice selection function (NSSF)574, and other network functions. The network functions may be referred to as virtual network functions (VNFs) in some contexts.

Network functions may be formed by a combination of small pieces of software called microservices. Some microservices can be re-used in composing different network functions, thereby leveraging the utility of such microservices. Network functions may offer services to other network functions by extending application programming interfaces (APIs) to those other network functions that call their services via the APIs. The 5G core network558may be segregated into a user plane580and a control plane582, thereby promoting independent scalability, evolution, and flexible deployment.

The UPF579delivers packet processing and links the UE552, via the access network556, to a data network590(e.g., the network560illustrated inFIG.6A). The AMF576handles registration and connection management of non-access stratum (NAS) signaling with the UE552. Said in other words, the AMF576manages UE registration and mobility issues. The AMF576manages reachability of the UEs552as well as various security issues. The SMF577handles session management issues. Specifically, the SMF577creates, updates, and removes (destroys) protocol data unit (PDU) sessions and manages the session context within the UPF579. The SMF577decouples other control plane functions from user plane functions by performing dynamic host configuration protocol (DHCP) functions and IP address management functions. The AUSF575facilitates security processes.

The NEF570securely exposes the services and capabilities provided by network functions. The NRF571supports service registration by network functions and discovery of network functions by other network functions. The PCF572supports policy control decisions and flow based charging control. The UDM573manages network user data and can be paired with a user data repository (UDR) that stores user data such as customer profile information, customer authentication number, and encryption keys for the information. An application function592, which may be located outside of the core network558, exposes the application layer for interacting with the core network558. In an embodiment, the application function592may be executed on an application server559located geographically proximate to the UE552in an “edge computing” deployment mode. The core network558can provide a network slice to a subscriber, for example an enterprise customer, that is composed of a plurality of 5G network functions that are configured to provide customized communication service for that subscriber, for example to provide communication service in accordance with communication policies defined by the customer. The NSSF574can help the AMF576to select the network slice instance (NSI) for use with the UE552.

FIG.7illustrates a computer system700suitable for implementing one or more embodiments disclosed herein. In an embodiment, provisioning request device103, IAM system111, provisioning application145, provisioning middlewares123A-B and/or carrier billing systems120A-B may be implemented as the computer system700. The computer system700includes a processor382(which may be referred to as a central processor unit or CPU) that is in communication with memory devices including secondary storage384, read only memory (ROM)386, random access memory (RAM)388, input/output (I/O) devices390, and network connectivity devices392. The processor382may be implemented as one or more CPU chips.