Patent Grant
10142868
Embodiments of the invention relate to services provided to consumers and operators of wireless networks.
The continued evolution of wireless network technology allows consumers today to communicate with each other by voice, data and text messaging through highly sophisticated network architectures. A consumer can make a phone call, download data and send text messages using a single wireless communication device, such as a smartphone. Typically, a consumer would purchase a plan from a network operator and be constrained by the rules defined in the plan for the duration of the plan period. For example, if the plan's policy does not allow roaming outside of a predetermined region, the consumer would be unable to make any calls from his smartphone once he leaves that region. The consumer may be unaware of the cause of the problem, and cannot easily find help at a time when he cannot make phone calls. As another example, if the plan has a set quota for data usage and the consumer has reached a predetermined threshold (e.g., 90%) of that quota before the end of a billing cycle, the consumer's future data traffic can be throttled (e.g., the Quality of Service (QoS) is lowered) until the next billing cycle starts. With the conventional operator's system, a consumer cannot easily monitor his data usage and cannot easily request his QoS be maintained at the same level throughout a billing cycle. Thus, the conventional operator's system for managing usage, offers, pricing and policy is inflexible and cannot easily adapt to consumers' needs.
The present invention is illustrated by way of example and not limitation in the figures of the accompanying drawings, in which like references indicate similar elements and in which:
In the following description, numerous specific details are set forth. However, it is understood that embodiments of the invention may be practiced without these specific details. In other instances, well-known circuits, structures and techniques have not been shown in detail in order not to obscure the understanding of this description. It will be appreciated, however, by one skilled in the art, that the invention may be practiced without such specific details. Those of ordinary skill in the art, with the included descriptions, will be able to implement appropriate functionality without undue experimentation.
In one embodiment, base station 102 includes a radio transmitter and receiver for communicating with cellular devices (e.g., cellular device 100), and a communications system for communicating with base station controller 104. Base station controller 104 controls base station 102 and enables communication with operator network 110. In various embodiments, base station controller 104 can control any number of base stations.
Network switching subsystem 106 controls voice network switching, maintains a register of cellular device locations, and connects operator network 110 with an external voice network, such as a public switched telephone network, a private voice telephony network, or any other appropriate voice telephony network. In one embodiment, network switching subsystem 106 includes a mobile switching center (MSC) 111, a home location register (HLR) 113, and a visitor location register (VLR) 114. MSC 111 controls, sets up and releases a voice connection using signaling protocols such as signaling system No. 7 (SS7). In some embodiments, MSC 111 additionally tracks the time of a voice connection for the purposes of charging cellular devices, decrementing available usage, tracking monetary balance, monitoring battery status, and other purposes. In one embodiment, operator network 110 may include any number of MSCs. Each of these MSCs serves cellular devices within a network area, which may include one or more base stations and one or more base station controllers. Some of the cellular devices may be registered to use this network area as their “home network,” and some of the other cellular devices may be registered to use other network areas as their home networks. HLR 113 maintains a list of cellular devices whose home network is served by MSC 111. VLR 114 maintains a list of cellular devices that have roamed into the area served by MSC 111. When a cellular device leaves its home network (e.g., the network area served by MSC 111), the VLR (“target VLR”) of the network (“target network”) to which the device has roamed communicates with HLR 113 in the home network of the device. When HLR 113 has confirmed to the target VLR that it can allow the device to use the target network, the device is added to the target VLR, and the MSC in the target network sets up the communication for the roaming cellular device.
SGSN 127 and GGSN 102 are two of the main components in the core data network of operator network 110. SGSN 127 is responsible for the delivery of data packets from and to the cellular devices within its geographical service area. The tasks of SGSN 127 include packet routing and transfer, mobility management (attach/detach and location management), logical link management, authentication and charging functions. GGSN 107 controls data communications switching and connects operator network 110 with an external data network, such as a local area network, a wide area network, a wired network, a wireless network, the Internet, a fiber network, a storage area network, or any other appropriate networks. In some embodiments, GGSN 107 is one of the core components in the core data network of operator network 110. Although not shown in
Messaging gateway 108 provides short messages transit between cellular devices and other communication devices. Messaging gateway 108 can be a Short Message Service Center (SMSC), a multi-media messaging center (MMSC), or a network node coupled to the SMSC or MMSC. Messaging gateway 108 delivers text messages through operator network 110 to/from external networks via standard protocols such as Short Message Peer-to-Peer Protocol (SMPP) or Universal Computer Protocol (UCP).
In some embodiments, operator network 110 is coupled to a hosted service platform 120 via a Core Service Platform (CSP) network 170 and a number of network nodes. Hosted service platform 120 serves as a service management platform for wireless communication devices such as cellular device 100. Hosted service platform 120 may include multiple data centers in multiple geographical locations with each data center including multiple server computers. Hosted service platform 120 includes a number of CSP engines 122 that provide a suite of functions to automate both the sales and support processes towards wireless users. Hosted service platform and CSP network 170, as well as software hosted thereon, form a CSP system. An overview of the CSP system will be described below in connection with
CSP network 170 provides connections between the data centers in the hosted service platform 120 and operator network 110. In one embodiment, CSP network 170 includes a GGSN 171 that implements PCRF 173 and OCS 174. Depending on the agreements between the operator/owner of operator network 110 and operator/owner of CSP network 170, both sets of (PCRF 123, OCS 124) and (PCRF 173, OCS 174) can be active at the same time or at different stages of service deployment. In some alternative embodiments, CSP network 170 does not implement PCRF 173 and OCS 174. Instead, host service platform 120 collects subscription data, policy and charging information from operator network 110.
The network nodes between operator network 110 and CSP network 170 are represented in
In some embodiments, an operator IT system 150 is coupled to operator network 110 via operator network node 130. Operator IT system 150 receives subscribers' data and usage from operator network 110, and provides the functions of Customer Relationship Management (CRM)/care, provisioning/order entry, billing/mediation (or payments), and reporting/data warehouse (DWH) (or business intelligence). Operator IT system 150 also provides a user interface (such as a desktop interface or a Web interface) for a system administrator to monitor and manage these functions. In one embodiment, operator IT system 150 includes a control center that hosts CSP operator Web applications 154. CSP operator Web applications 154 allow an operator to manage its marketing campaign, offers (equivalently, rate plans), pricing, billing and customer care in an integrated environment. Functionality of CSP operator Web applications 154 will be described later in further detail with reference to
In some embodiments, cellular device 100 stores and runs CSP device application (CDA) 140. CDA 140 displays alerts and notifications to consumers in response to the consumers' current usage and condition, provides customized contextual offers in real time, and allows consumers to select and purchase wireless products and services from their devices. Moreover, using CDA 140, consumers can diagnose and solve their own service questions and problems directly from their wireless device. For example, CDA 140 can query multiple sources, including cellular device 100 itself, to perform a diagnosis. Functionality of CDA 140 will be described later in further detail with an example shown in
It is understood that hosted service platform 120 of
In one embodiment, SIM 312 is a removable module storing an identifying number for wireless communication device 300 to identify the device to the network. In various embodiments, SIM 312 stores an International Mobile Subscriber Identity (IMSI) number, an Integrated Circuit Card Identifier (ICCID) number, a serial number, or any other appropriate identifying number.
Referring to
Consumers experience CSP system 530 through CDA 140 on their wireless communication devices. CDA 140 provides consumer-side functions that include, but are not limited to: storefront, payment, offers and alerts, self-support, account status, and device diagnostics. Operators experience CSP system 530 through CSP operator Web applications 154. CSP operator Web applications 154 provide operator-side functions that include, but are not limited to: offer and policy management, campaign and alert management, business and eligibility rules management, product catalog, customer relationship management, merchandising and content management, campaign analytics, retail store activation, customer care application, and reporting. For the operator, this CSP experience translates to the following three main benefits: (1) CSP system 530 provides a retail store on every wireless communication device, thereby increasing Average Revenue per User (ARPU) through real-time contextual selling; (2) CSP system 530 drives support cost towards zero by providing a self-support experience for consumers; and (3) CSP system 530 drives cost of sales towards zero using dedicated on-device channels.
In order to provide these benefits and reduce time to market, CSP system 530 integrates with four functions of operator IT system 150. The four functions are: CRM/care 610, provisioning/order entry 620, billing/payments 630 and reporting/DWH 640. CSP system 530 also integrates with two functions of operator network 110. The two functions are GGSN 107/PCEF 122 (which represents PCEF 122 implemented by GGSN 107) and Messaging Gateway 108.
The integration with operator network 110 will be described below with reference to
CSP—Network Integration
As shown in the embodiment of
The network integration enables fast time to market without compromising network integrity or service quality. In one embodiment, the integration is achieved through the use of standard 3GPP interfaces (Gx, Gy) and standard Short Message Peer-to-Peer (SMPP) interface.
Referring to
The (Gx, Gy) interfaces are defined in accordance with the Diameter protocol. The (Gx, Gy) interfaces are situated between GGSN 107/PCEF 122 and PCRF/OCS 710. More specifically, the Gx interface is between PCEF 122 and PCRF for policy, QoS control and redirection. The Gy interface is between PCEF 122 and OCS for real-time usage control and online data charging.
The following describes a number of scenarios that illustrate the possible use cases in a network system with integrated operator network and CSP functions. Some of these use cases can be combined.
Case 1: Metering subscriber traffic with no overage allowed and no redirect to portal. In this scenario, a subscriber is assigned a monthly quota of X MB and a threshold is set at Y %. A notification is sent to the subscriber when the subscriber exceeds the usage threshold of Y %. No subsequent session is allowed. Quota is reset at the end of the billing cycle.
Case 2: Metering subscriber traffic with redirect to offer portal. In this scenario, a subscriber is assigned a static monthly quota of X MB and a threshold is set at Y %. A notification is sent to the subscriber when the subscriber exceeds the usage threshold of Y %. When the subscriber reaches 100% of the monthly quota, the subscriber session is redirected to a portal with specific offers. The subscriber selects a top-up offer and is allowed to continue passing traffic.
Case 3: Policy to throttle traffic at the end of usage quota. In one scenario, the subscriber can have unlimited usage at a lower speed with a monthly quota at a higher speed. After the monthly quota is consumed, the subscriber's data traffic is reduced (throttled) to the lower speed. In another scenario, a subscriber is assigned a static monthly quota of X MB and a threshold is set at Y %. A notification is sent to the subscriber when the subscriber exceeds the usage threshold of Y %. When the usage reaches 90% (or any configurable percentage) of the monthly quota, the subscriber's data traffic is reduced (throttled) to an externally specified speed (e.g., a speed specified by the operator of the network). When the subscriber reaches 100% of the monthly quota, the subscriber session is redirected to a portal with specific offers. The subscriber can select a top-up offer and be allowed to continue passing traffic at the original Quality of Service (QoS). The subscriber can also pay for a higher speed (e.g., “throttle up”) if the subscriber is accessing a selected service (e.g., an online video) or wants more bandwidth to download a specified song or other type of file.
Case 4: Day pass. In this scenario, a subscriber is assigned a fixed duration pass. The subscriber maintains its session until expiration of the time quota, at which point the subscriber session gets disconnected. The subscriber is subsequently not able to reconnect until a new pass is purchased.
Case 5: Usage control around user data volume. In this scenario, a subscriber is assigned a static monthly quota of X MB and a threshold is set at Y %. The subscriber is also restricted to use no more than Z MB of data in a 30-minute sliding window. The subscriber is redirected to a portal if data volume exceeds this restriction. Redirect in this case is one-time only. If the subscriber declines a top-up offer, then the subscriber is reduced (throttled) to an externally specified speed (e.g., a speed specified by the operator of the network) until the 30-minute sliding window is over. (Note that the QoS restrictions are settable.)
Case 6: Usage restricted to specific Public Land Mobile Networks (PLMNs). This can be combined with other use cases. In this scenario, a subscriber is only allowed to use specific PLMNs. At some point, the subscriber leaves the allowed networks and camps on another network. The subscriber attempts to setup Packet Data Protocol (PDP) context and is blocked by PCRF. Notification is sent to subscriber to offer a targeted roaming package.
Case 7: Changed QoS on Radio Access Technology (RAT) Change. This use case assumes that the subscribers are allowed (whether as part of the plan or by explicit purchase) to have a specific QoS based on how they are connecting to the network. In one scenario, a subscriber has no QoS restrictions on the 3G network. At some point, the subscriber goes into an EDGE network. Subscriber gets reduced QoS while on the EDGE network. The subscriber is provided with unrestricted speed upon returning to the 3G network. This use case may be combined with other use cases.
Case 8: Subscriber has no quota limit within home network but has a 100 MB quota while roaming (redirect at end of roaming quota). In this scenario, a subscriber has no set quota while on the home network. The subscriber has a 100 MB quota for roaming. When the subscriber enters a roaming network, a notification update is sent to the subscriber to advise roaming usage. At some point, the subscriber exceeds roaming usage threshold (e.g. 90% of quota). A notification update is sent to the subscriber indicating that roaming limit has been reached. When the subscriber reaches 100% of the roaming quota, the subscriber session is redirected to a portal for additional roaming top-up offers. This use case can be extended to a scenario in which a local area is covered by a group of cellular sites (cells). When a subscriber moves from one cell to another, he is not roaming (switching between networks) but traveling (going to discrete areas in the same network). In one scenario, the subscriber has no set quota while in the home cell, but has a set quota for travelling to other cells.
Case 9: Detect a subscriber's access to a selected (type of) website or service. In this scenario, through the use of Deep Packet Inspection (DPI), the subscriber's access to a selected (type of) website or service can be detected. The subscriber needs to pay for the access to the selected (type of) website or service. This scenario is similar to another scenario where subscribers would be redirected if they go to a web site or location not explicitly allowed and they need to pay for the access.
Integration with GGSN/PCEF.
Because the various Diameter interfaces above have many options, the integration with one GGSN vendor may not be the same as the integration with another. For each make and model of GGSN and Packet Data Network Gateway (PGW), specific GGSN templates can be used. These specific templates include only the parameters and settings that have been proven against the corresponding make and model of GGSN. In terms of Diameter interfaces, only the Access Point Names (APNs) (i.e., the network addresses used to identify one or more GGSNs) that have been proven for the PCRF/OCS and the particular GGSN are used.
The CSP-integrated PCRF and OCS include an upwards-facing API (also referred to as northbound-facing) and Java Message Service (JMS) queue. These are used for passing usage information and event information to the higher layers of CSP system 530 (
The use of CSP-integrated PCRF and OCS allows for fast time to market and retains the full value proposition of the CSP solution. However, the higher-layer functions of CSP can integrate with any PCRF and OCS (e.g., an operator's own PCRF and OCS) that can provide the required interfaces for notification and control of the PCRF and OCS functions themselves.
As the PCRF and OCS may be tightly integrated with CSP system 530, when a user selects a new plan, that plan can be provisioned through the PCRF and OCS in real time. Thus, the subscriber can be served immediately. It is necessary that the other systems, such as customer care, within the IT infrastructure are aware of the new plan being provisioned. For that reason, as explained later, CSP system 530 interfaces to the operator's provisioning/order entry system. In one embodiment, CSP system 530 may manage the provisioning/order entry of data service upgrades with the CSP-integrated PCRF and OCS.
Integration with Messaging Gateway.
CSP system 530 (
In some embodiments, operators have SMSCs to forward text messages to/from external systems. These SMSCs support protocols such as SMPP or UCP. Some operators also use messaging gateways as an interface to the external systems, thereby minimizing direct connections from external systems to the SMSCs. These gateways also support SMPP or UCP, and most also have other APIs that can be made available. In alternative embodiments, the SMSCs may be part of CSP system 530.
In some embodiments, CSP system 530 has built-in SMPP client functionality. CSP system 530 can integrate with the operator's messaging gateway 108 using SMPP. In one embodiment, a specific short code can be assigned to CSP system 530 and that short code is zero-rated. Thus, messages between CSP system 530 and the user device will not be charged to the user's account.
CSP—Application Integration on a Wireless Communication Device
While CDA 140 is a device-based application, a majority of its data and experience (e.g., displayed layout and content) are generated and served from CSP system 530. This provides the ability to dynamically display and change elements of the experience without pushing application updates to the user device. In one embodiment, CDA 140 communicates with CSP system 530 over Hyper-Text Transfer Protocol Secure (HTTPS), which uses multi-layer authentication architecture to validate CDA 140, handset and user, before allowing access to data and functions such as purchasing upgrades. Alerts and notifications may be delivered to the user device via SMS through the CSP-Messaging integration described above, as well as through Mobile OS-specific notification methods; e.g., APNS for iOS devices and ACDM for Android® devices.
In one embodiment, the recommendation engine (which is one of CSP engines 122 in CSP system 530 shown in
The “My Account” feature allows a user to check his current usage information whenever he wants to. If the user does not take the initiative to check his current usage and limits, he can be notified by alerts of situations that can lower his QoS or disable his network connections. Alerts will be described with reference to
In one embodiment, the “My Account” feature also allows a user to monitor the billing; e.g., the amount of money he spent on network services before receiving a billing statement. For example, if the user is roaming and incurring roaming charges, he can monitor the amount of roaming charges in his account by clicking on the “billing” tab on the top right corner.
Referring to
Referring to
As shown in the example above, the “Help” feature not only discovers a problem, but also provides a resolution to the problem in a user-friendly way. In another scenario, a user may find out from the diagnosis that he does not have coverage. This diagnosed problem (coverage) can re-direct him to one or more proposed solutions, such as moving down the road 10 miles or purchasing an upgrade to the network coverage.
CSP—IT Integration
Referring again to
The CSP experience provides both the consumer and the operator a number of self-service tools that can be used anytime and anywhere to manage their services. For the consumer, CSP system 530 offers the ability to see, select and purchase new services, as well as perform account management and self-support activities, such as account balance inquires, payment method changes; all from their smartphones (or another wireless communication device) and all in real time.
For the operator, CSP system 530 provides a suite of tools that enables the creation and management of all of the services and experiences received by the customer. For example, the operator's CRM system 610 can integrate with CSP system 530 to provide details on offers and services that CSP system 530 can recommend to the customer as upsells or standard sales offers, to view current account balances and usage, manage payments and to provide diagnostics to assist the user with self-service resolution of common support issues. CSP system 530 can also integrate with the operator's reporting and data warehouse systems 640 to provide financial, marketing and management reporting.
In one embodiment, integration between CSP system 530 and operator IT system 150 is based upon the availability of interfaces to selected systems and/or groups of systems. As CSP system 530 uses a model that abstracts its interfaces to the operator platform using an adaptation layer, these interfaces can vary from standards-based Web services APIs to secure file transfers.
In one embodiment, the interfaces enable not only the integration of CSP system 530 with operator IT system 150, but also the ability for an operator to manage its marketing campaign, offers, pricing, billing and customer care in an integrated environment. In one embodiment, this integrated environment is presented to the operator via CSP operator Web applications 154. CSP operator Web applications 154 may be run on a computer in the control center of operator IT system 150.
In one embodiment, some of the task modules, such as pricing workstation 1610 and offers workstation 1611, allow the administrators to create offers and set pricing. In one embodiment, CSP system 530 can provide offers and pricing templates for the operator to fill in the details. Through subscriber portal 1612, an operator can design subscriber's on-device experience, also using the templates provided by CSP system 530. These templates allow the operator to set a pricing plan and package the pricing plan into an offer associated with a policy. The pricing, offer and policy are sent to CSP system 530 to allow CSP system 530 to deliver the right offers with the right pricing to the right subscribers at the right time. CSP system 530 can also provide other templates that can be used by the operator with a click on any of task modules 1610-1618.
In one embodiment, an operator can view the details (e.g., activities and history) about subscribers through the task module of subscriber details 1613, and perform operations on their accounts; e.g., activate or deactivate the accounts, change offers, apply promotions and other account administrative tasks. Custom alerts 1614 allow administrators of the operator to configure rules for alert-triggering events. These alerts may be accompanied by automated response to specific events for resolving the condition causing the alerts. The task module of reports 1615 allows the operator to review and analyze subscriber and financial data. For example, the operator can run a report to find out when a particular offer or a particular group of offers have reached a set market share or set usage.
In one embodiment, an operator can design campaigns to send offers and incentives to specific subscribers using campaign center 1616. In one embodiment, the offers and incentives can be delivered to CDA 140 on the user device via CSP system 530 (
In one embodiment, an operator can use customer alerts 1617 to set up an alert for specific subscribers and the rules associated with the alert. The alert can be displayed on the user device to allow a subscriber to take remedial action; e.g., to accept a top-up offer that is delivered with the alert to the subscriber. In one embodiment, the task module of analytics 1618 is backed by the recommendation engine of CSP system 530. Analytics 1618 allows the operator to identify trends and opportunities based on the subscribers' behavior and campaign results. For example, if the subscriber reaches his usage limit for the first time, analytics 1618 can recommend a top-up offer (which is valid only for this current billing cycle). If this is the fifth time within a five-month period that the subscriber has reached the threshold, analytics 1618 can recommend an upgrade offer such that the subscriber can switch to an upgraded plan and receive a higher quota limit every billing cycle.
As mentioned before, the integration of CSP system 530 and operator IT system 150 (
CRM Integration.
CRM Integration Area (I): Rating, Policy and Offer Management (Product Catalog).
Through the integrated rating, policy and offer management functions, CSP system 530 provides the operator a powerful set of tools to create, edit, approve and manage rate plans and policy actions for consumers. As the front-end interface to an integrated OCS and PCRF facility, CSP's Pricing and Offers engines (e.g., CSP engine 122 of
Depending on the nature of the product deployment, CSP system 530 can replicate offers currently in the operator's product catalog, create and push offers to the operator, or act as the master product catalog for rating. In all of these three cases, CSP CRM API 1701 provides proper synchronization between CSP system 530 and operator IT system 150, as well as ensuring availability of offers and policies. CSP CRM API 1701 allows CSP system 530 to access and pull offers. CSP CRM API 1701 also facilitates a submit/approve/publish method to push offers to the operator.
Through CSP CRM API 1701, CSP system 530 pulls all applicable offers, catalog rules, offer parameters and policy descriptions into an easy-to-use, self-service user interface that the operator's marketing personnel can use to quickly create new offers and promotions. In practice, the process to create and approve an offer touches many internal operator departments and may need some level of internal coordination and process to accomplish. To properly engage with and manage this need, CSP system 530 has an integrated approval workflow to prevent the use of these offers and policies until they are reviewed and approved by the appropriate operator-designated personnel. Once approved, the offers and policies can be pushed to the operator using CSP CRM API 1701 or a similar API.
A sample product catalog/rating/policy template is shown below.
In case an API is not or cannot be made available, a manual synchronization process can be used to perform the actions that would be taken by the API. In this manual approach, the operator uses the CSP Pricing and Offer engines to create and publish the appropriate offers and policies. A key to success in this approach will be the creation of business processes that govern the speed and frequency of updates.
CRM Integration Area (II): Campaign Management.
In one embodiment, CSP system 530 includes Customer Alerts and Campaign engines (e.g., one or more of CSP engines 122 of
CRM Integration Area (III): Customer Management—Customer Profile.
CSP system 530 is designed to address the sensitivity of the operator's customer data and the number of regulatory and legal issues. Integration between CSP system 530 and the operator's CRM customer profile is needed to enable several functions: authentication of CDA 140, personalization of offers and alerts, and knowledge of customer offers for recommendations and account management. In all cases, CSP system 530 looks to the operator's CRM system 610 as the master record for all customer data.
To protect end-customer data, all of the end-customer data is stored within the CSP customer database and managed in a manner that enables it to be secure and auditable at all times. Any changes made to the customer data are tracked using an audit trail that can be made available for reports, audits, etc. In addition, the CSP data centers can be deployed in specific geographical locations to accommodate data security, privacy and location requirements.
The integration that is required to store and update this data inside CSP system 530 can be accomplished using an API (e.g., CSP CRM API 1701 of
Since the customer profile data feeds CSP's customer database and contains all of the customer's current plan information, the CRM integration also enables changes made outside of CSP system 530 to be reflected in the CDA 140 and CSP system 530. Thus, any changes to rating or policy parameters can be properly synchronized between CSP system 530 and the operator. To that end, changes made within the operator's customer care and/or retail ordering systems are pushed (recommended) or pulled periodically from the operator's CRM system 610 to CSP system 530. The CRM integration allows CSP system 530 to be constantly up-to-date with the operator's systems. In one embodiment, the API (e.g., CSP CRM API 1701 of
In one embodiment, CSP system 530 uses the following information in the customer profile for CRM integration:
CRM Integration Area (VI): Customer Management—Customer Care.
CSP system 530 has a number of customer management capabilities that can be useful to the operator's customer care and customer management teams.
In one embodiment, CSP system 530 does not directly push data into the operator's CRM system 610. Rather, it assumes that integrations are already in place within the operator's infrastructure to pass information, for example, from the product catalog, provisioning/ordering and similar systems to the CRM system 610. If a direct push integration to the CRM system is necessary, CSP system 530 can provide information via an API to the CRM system 610 on a per-event or time-basis.
In one embodiment, CSP system 530 can, via an API, allow the operator's CRM system 610 to provide diagnostic, current offer and current usage data. Since CSP system 530 is both the rating and policy management engine, a customer current usage and policy status, e.g. throttled or not throttled can be made available to the CRM system 610. One key component of the CSP system 530 is the ability to push advanced service and network-level diagnostics to the handset and provide the user timely and actionable feedback to solve issues.
While one of the key attributes of the CSP system 530 and CDA is the ability to allow a customer to perform a majority of account management and self-support issues, it may be unavoidable that sometimes the customer will call customer care. When the customer does call customer care, the customer care agent (or a technical support representative) can, via the API, pull diagnostic information into their normal systems and provide assistance to the customer. In the case where the CRM system cannot integrate to an external data source, CSP system 530 can be setup to launch-in-context (LIC) along with the customer care representative's existing tools.
Provisioning/Order Entry Integration.
Prior to the description of provisioning/order entry integration, it is useful to differentiate between order management and provisioning/order entry functions. Order management functions aggregate customer selections for offers, payment methods and any other updates and pass that information to a provisioning/order entry system that allows access to those ordered services on the network.
Since CSP system 530 may be the master rating and policy engine, it can enable access to the selected services and then integrate with the order management system to feed data to downstream systems, e.g. care, reporting and CRM. This integration assumes the existence of interfaces between the order management and related downstream systems (e.g., CRM and reporting) to manage activities such as customer activation, service changes, device changes and updating financial and marketing reports.
In one embodiment, CSP system 530 is provided with the appropriate identifiers for all available provisioned services. These codes (and associated parameters) are known as service offer codes (SOC) and can be used by CSP system 530 to inform the provisioning/order entry system to allow a customer access to their selected offers. For data services, CSP system 530 can provision service access on its integrated PCRF based upon the customer's selections, and submit, via CSP provisioning/order entry API 1901, the appropriate SOC, any relevant parameters and a customer identifier (IMSI or MSISDN) directly to the provisioning/order entry system for fulfillment. In parallel, CSP system 530 can send the same information via a Web services interface to the operator's order management system for further processing and population of downstream systems. In an alternative embodiment, the operator can choose to provision its PCRF with the same information as CSP system 530.
CSP system 530 also offers the ability to offer and provision other mobile (voice, messaging) and non-mobile services (DSL, insurance) that are not rated by CSP system 530. In this case, CSP system 530 can, using the same mechanisms noted above, provide the provisioning/order entry and ordering systems the appropriate SOC (or equivalent) code, allowing the appropriate network elements (e.g., HLRs) and IT platforms (CRM) to be updated. To that end, all of the products and services offered by the operator need to be provided to CSP system 530, placed in the product catalog and synchronized.
As previously noted, CSP system 530 receives information about a customer's current services and selections from the customer profile database. If a change is made to the customer's plans or services via the Care or Retail system, these changes and their associated provisioning/order entry changes are sent to CSP system 530.
Billing Integration.
In one embodiment, CSP system 530 integrates with the operator's billing system in the following areas: Rating of Data Usage, Self-Service Account Management and Risk Management and Payment.
Billing Integration Area (I): Rating of Data Usage.
In one embodiment, a CSP-integrated OCS can be used to rate data usage for customers that are managed by CSP system 530. The rates and policies used by the OCS can be stored and managed by CSP system 530.
In one embodiment, CSP system 530 can rate usage and calculate charges on a per session basis. Depending on the nature of the product deployment, CSP system 530 can either store, aggregate and format usage into an invoice-ready format, or send rated, per-session usage to the operator's CRM or other system. If the former, CSP system 530 can provide the invoice-ready data feeds to a mutually agreed sFTP site for the operator to pick up and include into its billing process a set number of days prior to the close of the billing cycle.
In the latter option, CSP system 530 can post, on a per-session basis, aggregated usage including the customer identifier (IMSI or MSISDN), plan code and total usage. In one embodiment, this integration will be managed through the use of an API (e.g., CSP billing API 2101) that can directly feed the operator billing system. A known analogue to this type of integration is one where a third party provides a “bill on behalf of” service to an operator. In this case, CSP system 530 will be charging data usage on behalf of the operator and providing that rated usage for use by downstream financial systems (e.g., taxation) as well as CRM and reporting systems. If an API cannot be made available, these data can be posted to a sFTP site.
Billing Integration Area (II): Self Service Account Management.
A key feature of the CDA 140 is the ability for the customer to view, in real time, current service usage. In an embodiment where CSP system 530 is rating data and the operator is rating voice and SMS, it is necessary to integrate with the operator's usage management systems to get rated and/or aggregated usage for those services. Depending on the operator system that sources this data, a push API or sFTP file transfer can be used to get these data. A key factor in determining how to perform this integration is how fast the usage information can be made available via the interface. If there is a delay greater than a pre-defined time period (e.g., 15 minutes between usage completion and CDR delivery), a secondary method may be used to enable the “real-time” nature of the CDA 140 account management function. In this case, the customer profile integration may be a candidate to pull current, aggregated usage.
Billing Integration Area (III): Risk Management and Payment.
Depending on the nature of the product deployment, CSP system 530 can also integrate with the operator's risk management and payment systems. The integration with these services is highly dependent on the service used and where it sits within the operator infrastructure. The ideal integration with CSP system 530 is to use an existing interface, e.g. the customer profile to determine the risk score for a customer and use that along with the catalog rules sourced from the product catalog integration to determine payment risk.
In addition, CSP system 530 can, as part of the order management and provisioning/order entry transaction, send a payment type and payment details. This is necessary if the operator wants to enable prepaid or credit card payments for services purchased via CDA 140. In this case, the integration is also highly dependent on the target system and its location within the operator infrastructure. Typically, CSP system 530 can interface with but does not actually store or process any payments.
Data Warehouse/Business Intelligence Integration.
In some embodiments, CSP system 530 provides over twenty reports for use by an operator, such as daily subscriber report, usage detail reports, reports on charges of all kinds, and the like. Reports can be generated daily and/or monthly, and delivered to the operator.
Thus, a method, system and apparatus for a Core Service Platform (CSP) has been described. It is to be understood that the techniques shown in the figures can be implemented using code and data stored and executed on one or more electronic devices (e.g., an end station, a network element, etc.). Such electronic devices store and communicate (internally and/or with other electronic devices over a network) code and data using non-transitory machine-readable or computer-readable media, such as non-transitory machine-readable or computer-readable storage media (e.g., magnetic disks; optical disks; random access memory; read only memory; flash memory devices; and phase-change memory). In addition, such electronic devices typically include a set of one or more processors coupled to one or more other components, such as one or more storage devices, user input/output devices (e.g., a keyboard, a touch screen, and/or a display), and network connections. The coupling of the set of processors and other components is typically through one or more busses and bridges (also termed as bus controllers). The storage devices represent one or more non-transitory machine-readable or computer-readable storage media and non-transitory machine-readable or computer-readable communication media. Thus, the storage device of a given electronic device typically stores code and/or data for execution on the set of one or more processors of that electronic device. Of course, one or more parts of an embodiment of the invention may be implemented using different combinations of software, firmware, and/or hardware.
It is to be understood that the above description is intended to be illustrative and not restrictive. Many other embodiments will be apparent to those of skill in the art upon reading and understanding the above description. The scope of the invention should, therefore, be determined with reference to the appended claims, along with the full scope of equivalents to which such claims are entitled.
This application is a continuation of U.S. patent application Ser. No. 13/236,401 filed Sep. 19, 2011 which is the Non-Provisional filing of Provisional Patent Application No. 61/501,131, filed on Jun. 24, 2011, the entire contents of which are incorporated herein by reference.
| Number | Name | Date | Kind |
|---|---|---|---|
| 6473738 | Garrett | Oct 2002 | B1 |
| 6516190 | Linkola | Feb 2003 | B1 |
| 6956820 | Zhu et al. | Oct 2005 | B2 |
| 7483849 | Voudrie | Jan 2009 | B2 |
| 7610045 | Little et al. | Oct 2009 | B2 |
| 7613648 | Fortes et al. | Nov 2009 | B2 |
| 7620162 | Aaron et al. | Nov 2009 | B2 |
| 7769342 | Tabe | Aug 2010 | B2 |
| 7885636 | Taglienti et al. | Feb 2011 | B2 |
| 8018955 | Agarwal et al. | Sep 2011 | B2 |
| 8023425 | Raleigh | Sep 2011 | B2 |
| 8099078 | Lazaridis | Jan 2012 | B2 |
| 8112062 | Pattabiraman | Feb 2012 | B2 |
| 8122062 | Brendle et al. | Feb 2012 | B2 |
| 8214536 | Zhao | Jul 2012 | B2 |
| 8229812 | Raleigh | Jul 2012 | B2 |
| 8250207 | Raleigh | Aug 2012 | B2 |
| 8290471 | Jones et al. | Oct 2012 | B1 |
| 8306534 | Yach et al. | Nov 2012 | B2 |
| 8321526 | Raleigh | Nov 2012 | B2 |
| 8346225 | Raleigh | Jan 2013 | B2 |
| 8351898 | Raleigh | Jan 2013 | B2 |
| 8355337 | Raleigh | Jan 2013 | B2 |
| 8391834 | Raleigh | Mar 2013 | B2 |
| 8411604 | Reif | Apr 2013 | B2 |
| 8730823 | Mohammed et al. | May 2014 | B2 |
| 8762188 | Abercrombie | Jun 2014 | B2 |
| 20020186827 | Griffiths | Dec 2002 | A1 |
| 20030018558 | Heffner et al. | Jan 2003 | A1 |
| 20040002794 | Pillar | Jan 2004 | A1 |
| 20040049394 | Burger et al. | Mar 2004 | A1 |
| 20040203766 | Jenniges | Oct 2004 | A1 |
| 20050020243 | Benco et al. | Jan 2005 | A1 |
| 20050060250 | Heller et al. | Mar 2005 | A1 |
| 20050233733 | Roundtree et al. | Oct 2005 | A1 |
| 20050266825 | Clayton | Dec 2005 | A1 |
| 20060203739 | Padmanabhan et al. | Sep 2006 | A1 |
| 20080015958 | Vanker et al. | Jan 2008 | A1 |
| 20080076419 | Khetawat et al. | Mar 2008 | A1 |
| 20080084993 | Peddireddy et al. | Apr 2008 | A1 |
| 20080114513 | Pillar | May 2008 | A1 |
| 20080120129 | Seubert et al. | May 2008 | A1 |
| 20080306871 | Grannan | Dec 2008 | A1 |
| 20090150218 | Brunner et al. | Jun 2009 | A1 |
| 20090168660 | Bhatia et al. | Jul 2009 | A1 |
| 20100010922 | Foottit et al. | Jan 2010 | A1 |
| 20100056114 | Roundtree et al. | Mar 2010 | A1 |
| 20100080128 | Hovey | Apr 2010 | A1 |
| 20100125495 | Smith et al. | May 2010 | A1 |
| 20100159902 | Roundtree et al. | Jun 2010 | A1 |
| 20100248690 | Biggs et al. | Sep 2010 | A1 |
| 20100262487 | Edwards et al. | Oct 2010 | A1 |
| 20100273456 | Wolovitz et al. | Oct 2010 | A1 |
| 20100332072 | Ishiko et al. | Dec 2010 | A1 |
| 20110151831 | Pattabiraman | Jun 2011 | A1 |
| 20120004974 | Burger et al. | Jan 2012 | A1 |
| 20120028620 | Roundtree et al. | Feb 2012 | A1 |
| 20120101952 | Raleigh et al. | Apr 2012 | A1 |
| 20120151533 | Kandanala et al. | Jun 2012 | A1 |
| 20130003613 | Raleigh | Jan 2013 | A1 |
| 20130090096 | Zubas et al. | Apr 2013 | A1 |
| 20130143522 | Rege et al. | Jun 2013 | A1 |
| 20130196655 | Zabawskyj | Aug 2013 | A1 |
| 20130301627 | Chen et al. | Nov 2013 | A1 |
| 20130304870 | Knight et al. | Nov 2013 | A1 |
| 20130318187 | Knight et al. | Nov 2013 | A1 |
| 20140040975 | Raleigh et al. | Feb 2014 | A1 |
| 20160210578 | Raleigh | Jul 2016 | A1 |
| Number | Date | Country |
|---|---|---|
| 2249514 | Nov 2010 | EP |
| Entry |
|---|
| Office action from corresponding U.S. Appl. No. 13/341,800 dated May 13, 2014. |
| Extended European search report from corresponding EP application dated Nov. 21, 2014. |
| Number | Date | Country | |
|---|---|---|---|
| 20140242943 A1 | Aug 2014 | US |
| Number | Date | Country | |
|---|---|---|---|
| 61501131 | Jun 2011 | US |
| Number | Date | Country | |
|---|---|---|---|
| Parent | 13236401 | Sep 2011 | US |
| Child | 14267323 | US |
