Service Utilization Control Manager
Claim Score by NHIP
Abstract
Aspects of the invention allow mobile network users as well as mobile network providers to define policies that are managed across several applications and services. Thus, several application servers and network elements are coordinated to implement a service policy. More specifically, aspects of the invention define service level policies for any service be within an IMS based or non-IMS based wireless network implemented by SIP or non-SIP network elements. A service policy is a set of rules that is applied when a subscriber uses a specific service (Web Browsing, Location, Presence, MMS, SMS, PoC, etc). The policy may be applicable on a per-need, per-subscriber basis. A service policy enhances or restricts use of the service functionality by the subscriber. A service level policy should also allow definition of service utilization rules that constrain how the service may be used by the subscriber. For example, a parent may restrict the use of her child's cell phone for all voice and messaging type communication to only one hour per day between the time of 12 noon to 1 pm and 4 pm to 6 pm. Thus, aspects of the inventions allow mobile service subscribers to receive a level of customization for services rendered by a mobile network service provider. Further, mobile network service providers may provide not only custom service to subscribers but also simplifies the provisioning by allowing a single-point of configuration for subscriber based service control policies. Service level policies have wider scope than bearer level policies such as quality of service in the form of on-demand bandwidth, committed rates of throughput, committed reduction in delay/jitter/latency.

Term
5.1 yearsto projected expiry
Projected expiry 8 November 2031, counted from filing; an application has no term until it is granted.
- Priority and filed
- Published
- Today
- Projected expiry
20 claims: 3 independent, 17 dependent
- 1A method of managing a plurality of mobile network services on a subscriber basis across several networks, the method comprising:receiving a service request from a subscriber across an application interface requesting authorization to provide a service to a subscriber from a service authorization and utilization control function;authorizing a service request by a service authorization and utilization control function based on a service policy;and denying a service request by a service authorization and utilization control function based on a service policy.
- 9A system of managing a plurality of mobile network services on a subscriber basis across several networks, the system comprising:a service authorization and utilization control function that authorizes or denies a requested mobile network service from a network element;a plurality of subscriber service utilization accounts that store available credit for subscribers;a plurality of network elements that request authorization from a service authorization and utilization control function to provide a mobile network service to a subscriber;an application interface that carries messages between one or more network elements and a service authorization and utilization control function;an application interface that carries messages between a service authorization and utilization control function and a subscriber service utilization account;a plurality of networks that provide mobile network services from one or more network elements to a plurality of subscriber mobile devices;and a plurality of subscriber mobile devices that configures a service policy incorporated into the service authorization and utilization control function and requests services from one or more network elements.
- 15Broadest claimClaim Score 63, broad(NHIP)An apparatus for managing a plurality of mobile network services on a subscriber basis across several networks, the apparatus comprising:a service authorization and utilization control function;a plurality of service policy rules;a subscriber service utilization account;a real time utilization interface;and an interface that carries messages between a network element and a service authorization and utilization control function.
Independent claims3
48 paragraphs in 4 sections, as filed
BACKGROUND OF THE INVENTION
p-0004Mobile networks have evolved such that 3rd generation mobile networks offer many different services that include multimedia messaging, streaming video, parental control, and mobile phone advertisements. The IP Multimedia Subsystem (IMS) is an architectural framework for delivering internet protocol (IP) multimedia to mobile users. The 3GPP developed IMS to evolve mobile networks beyond GSM. IMS allows service providers to deliver Internet services over a variety of networks that include, but are not limited to, GPRS, Wireless LAN, CDMA2000, and fixed line.
p-0005To ease the integration with the Internet, IMS uses Internet protocols such as Session Initiation Protocol (SIP). The purpose of IMS is to aid access of multimedia and voice applications across wireless and wireline terminals. This is done by having a service plane and a bearer plane. The service plane provides different services to wireless terminals across wireless networks. Alternatively, the bearer plane allocates the physical network recourses (i.e. network bandwidth) necessary to provide the services provisioned by the service plane. Further, IMS has allowed Application Servers to apply policies for certain applications to the bearer plane via a functional element known as the Policy and Charging Rules Function (PCRF). The policy framework defined in IMS, for example, allows a subscriber to receive appropriate bandwidth and reductions in latency for viewing of a streaming video (service application). The IMS and MMD standards define how the PCRF is used by application servers (AS) to push or pull policy information about how a user is to use the resources provided by the bearer plane (RF and IP resources at the access network).
BRIEF SUMMARY OF THE INVENTION
p-0006Aspects of the invention allow mobile network users as well as mobile network providers to define policies that are managed across several applications and services. Thus, several application servers and network elements are coordinated to implement a service policy. More specifically, aspects of the invention define service level policies for any service be within an IMS based or non-IMS based wireless network implemented by SIP or non-SIP network elements.
p-0007A service policy is a set of rules that is applied when a subscriber uses a specific service (Web Browsing, Location, Presence, MMS, SMS, PoC, etc). The policy may be applicable on a per-need, per-subscriber basis. A service policy enhances or restricts use of the service functionality by the subscriber. In addition, a service level policy allows definition of service utilization rules that constrain how the service may be used by a subscriber. For example, a parent may restrict the use of her child's cell phone to only one hour per day between the time of 12 noon to 1 pm and 4 pm to 6 pm. Thus, aspects of the inventions allow mobile service subscribers to receive a level of customization for services rendered by a mobile network service provider. Further, mobile network service providers may provide not only custom service to subscribers but also simplifies the provisioning by allowing a single-point of configuration for subscriber based service control policies. Consequently, service level policies have wider scope than bearer level policies such as quality of service in the form of on-demand bandwidth, committed rates of throughput, committed reduction in delay/jitter/latency.
BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWING(S)
p-0008<figref idrefs="DRAWINGS">FIG. 1</figref> is a schematic diagram illustrating an exemplary IMS network environment, wherein a mobile device communicates with an application server located in an IMS core network via one or more access networks, as contemplated by an embodiment of the present invention;
p-0009<figref idrefs="DRAWINGS">FIG. 2</figref> is a schematic diagram illustrating an exemplary implementation of the IMS core network and access networks of <figref idrefs="DRAWINGS">FIG. 1</figref> in more detail, in accordance with an embodiment of the invention;
p-0010<figref idrefs="DRAWINGS">FIG. 3</figref> illustrates an exemplary implementation of a service policy authorization and utilization control function (SAUCF) that applies a service policy across several applications and services interacting with IMS and non-IMS network elements;
p-0011<figref idrefs="DRAWINGS">FIG. 4</figref> illustrates the details in an exemplary process of requesting authorization by an Network Element to a SAUCF;
p-0012<figref idrefs="DRAWINGS">FIG. 5</figref> illustrates an exemplary implementation of a SAUCF in network;
p-0013<figref idrefs="DRAWINGS">FIG. 6</figref> is an exemplary SAUCF High Level Message flow chart;
p-0014<figref idrefs="DRAWINGS">FIG. 7</figref> illustrates an exemplary binding of an individual subscriber to a “trusted group” of subscribers;
p-0015<figref idrefs="DRAWINGS">FIGS. 8-11</figref> are flow charts that illustrate an exemplary implementation of service policy rules;
p-0016<figref idrefs="DRAWINGS">FIG. 12</figref> is an exemplary message flow diagram that illustrates the mapping of SAUCF messages to Real Time Utilization (Ru) interface messages; and
p-0017<figref idrefs="DRAWINGS">FIG. 13</figref> is a flow chart illustrating an exemplary application of service utilization bonuses.
DETAILED DESCRIPTION OF THE INVENTION
p-0018The following examples further illustrate the invention but, of course, should not be construed as in any way limiting its scope.
p-0019<figref idrefs="DRAWINGS">FIG. 1</figref> is an exemplary implementation of a system contemplated by an aspect of the invention is shown with reference to an IP multimedia network environment with an IMS enabled core. Note that aspects of the invention are not limited to the type of network depicted in <figref idrefs="DRAWINGS">FIG. 1</figref>, but may include other non-IMS networks. <figref idrefs="DRAWINGS">FIG. 1</figref> shows one exemplary environment where mobile services are managed on a per subscriber basis. In this aspect, a user device <b>100</b> is a mobile device, such as a wireless telephone or a portable computer capable of wireless communication with a plurality of radio access networks (<b>102</b>, <b>104</b>), such as those employing a CDMA-based, GSM-based, or a WCDMA-based standard.
p-0020To enhance the user experience with multimedia based services, the access networks (<b>102</b>, <b>104</b>) are connected to an IP Multimedia Subsystem (IMS) core network <b>106</b> that manages IP network sessions in a mobile environment. The IMS core network <b>106</b> further includes an application server (AS) <b>108</b>, which hosts one or more applications available to the mobile device <b>100</b>. The applications hosted by AS <b>108</b> include multimedia applications, such as streaming media applications, as well as other applications which require the maintenance of specific quality of service (QoS) guarantees. To expand the variety of applications available to the mobile device <b>100</b> via the access networks (<b>102</b>, <b>104</b>), the IMS core network <b>106</b> includes a connection to the public Internet <b>110</b>. Preferably, the mobile device <b>100</b> is a multi-mode entity capable of accessing a plurality of access networks operating based on different network technologies. Examples of a mobile device include but not limited to a mobile phone, Personal Digital Assistant (PDA), and a laptop computer.
p-0021<figref idrefs="DRAWINGS">FIG. 2</figref> illustrates an exemplary implementation of the IMS core network <b>200</b> and access networks (<b>216</b>, <b>218</b>) of <figref idrefs="DRAWINGS">FIG. 1</figref> in more detail. The mobile device <b>220</b> and the application server <b>202</b> communicate via access networks (<b>216</b>, <b>218</b>) and the IMS core network <b>200</b> to establish and maintain a service session for an application launched by a user. In addition to the application server <b>202</b>, the IMS core network <b>200</b> includes other IMS functions, such as those described in G. Camarillo, M. Garcia-Martin, “The 3G IP Multimedia Subsystem (IMS) Merging The Internet And The Cellular Worlds,” John Wiley & Sons, Ltd., 2006 (second edition), which is incorporated herein by reference in its entirety for everything that it teaches. To this end, the AS <b>202</b> is connected to a Serving Call/Session Control Function (S-CSCF) <b>204</b>, which is a Session Initiation Protocol (SIP) server that performs session control, SIP registrar, authentication, and other IMS functions via SIP protocol signaling described in J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. Peterson, R. Sparks, M. Handley, E. Schooler, “SIP: Session Initiation Protocol,” RFC 3261, IETF, June 2002, which is incorporated herein by reference in its entirety for everything that it teaches. The IMS core network <b>200</b> includes a number S-CSCFs, wherein each S-CSCF has a certain capacity in terms of a maximum number of supported mobile devices (MD) <b>220</b>.
p-0022The S-CSCF <b>204</b>, in turn, connects to a Proxy Call/Session Control Function (P-CSCF) <b>206</b>, which, among other IMS functions, includes user authentication functions and acts as an inbound and outbound SIP proxy server by relaying the SIP requests and responses to and from the mobile device <b>220</b> and to and from the IMS core network <b>200</b>. As with the S-CSCF <b>204</b>, the IMS core network <b>200</b> includes a number of P-CSCFs, wherein each P-CSCF has a certain capacity of being able to support a predefined number of mobile devices <b>220</b>. The Home Subscriber Server (HSS) <b>208</b> is a database of user-related information and contains user subscription data necessary for authentication and authorization of an IP multimedia session associated with a given application. The HSS serves the S-CSCF as shown in <figref idrefs="DRAWINGS">FIG. 2</figref>. The user subscription data is contained in a user profile that indicates, among other things, the types of services to which the user subscribes. Additionally, a Policy Function (PF) <b>210</b> This in the MMD (3GPP2 specs) is the “Policy and Charging Rule Function (PCRF) is used to authorize the media plane resources and supervise the QoS over the media plane by interfacing with a plurality of Access Gateways (<b>212</b>, <b>214</b>), which, in turn, allocate the access network resources within the corresponding access networks (<b>216</b>, <b>218</b>) in accordance with the QoS constraints required by the multimedia application. Note that the PF <b>210</b> is analogous to the Policy and Charging Rule Function (PCRF) in an MMD network architecture. Finally, the Home Agent (HA) <b>215</b> is a router typically involved in the Mobile IP (MIP) session registration process, as well as in tunneling of packets when the MD <b>220</b> is roaming.
p-0023<figref idrefs="DRAWINGS">FIG. 3</figref> illustrates an exemplary implementation of a service policy authorization and utilization control function (SAUCF) <b>310</b> that applies a service policy across several applications and services interacting with IMS and non-IMS network elements. Generally, <figref idrefs="DRAWINGS">FIG. 3</figref> shows a SAUCF interfacing with different network elements in the context of an IMS network. IMS application servers (AS<sub>1</sub>-AS<sub>n</sub>) (<b>312</b>, <b>314</b>) and the CSCF <b>316</b> utilize the services of the SAUCF <b>310</b> via the unique Service Authorization & Utilization Diameter Application (SAUDA) interface. The S-CSCF <b>316</b> plays an important part in Voice over IP calls because all calls for a given subscriber traverse the S-CSCF <b>316</b>. When no AS (<b>312</b>-<b>314</b>) is involved in a VOIP call, the S-CSCF <b>316</b> may request service level policies for a subscriber from the SAUCF. <figref idrefs="DRAWINGS">FIG. 3</figref> also shows legacy (non-IMS) application servers such as the MMSC <b>318</b> and a Web Proxy <b>308</b>. Legacy network elements also utilize the Service Authorization & Utilization Diameter Application interface to the SAUCF <b>310</b> to support service level policies. Finally, the services provided by the SAUCF <b>310</b> may be utilized by network elements other than application servers. For example, <figref idrefs="DRAWINGS">FIG. 3</figref> shows a firewall <b>306</b> communicating with the SAUCF <b>310</b> that may provide restriction or privacy services to a subscriber. Note that interfaces <b>332</b>-<b>340</b> carry the Service Authorization and Utilization Diameter Application.
p-0024<figref idrefs="DRAWINGS">FIG. 3</figref> also shows network elements and functions shown in <figref idrefs="DRAWINGS">FIG. 2</figref> that include the PCRF <b>326</b> and HSS <b>324</b>. The SAUCF also enforces subscriber level policies for access to the Web Servers <b>304</b> through the Internet <b>302</b> across a firewall <b>306</b>. Further, the CSCF <b>316</b> routes signaling for subscribers services to one or more mobile devices <b>330</b> through a plurality of Access Gateways (<b>320</b>-<b>322</b>). Note that interfaces <b>344</b>-<b>350</b> are on the User Plane and carry the data between the mobile and the servers (client-server) and or other mobiles (peer-to-peer). Interfaces <b>360</b>-<b>362</b> are Tx/Ty interfaces while interfaces <b>356</b>-<b>358</b> are Sh/Cx Diameter interfaces. In addition, interfaces <b>352</b>-<b>354</b> are SIP Signaling interfaces.
p-0025<figref idrefs="DRAWINGS">FIG. 4</figref> illustrates the details in an exemplary process of requesting authorization by a Network Element <b>405</b> to a SAUCF <b>420</b>. A Network Element (i.e. application server, firewall, etc.) <b>405</b> requests service authorization <b>410</b> from a SAUCF <b>420</b>. An SAUCF <b>420</b> may have several sub-functions that may include a Communication Authorization Sub-Function <b>425</b>, Access Authorization Sub-Function <b>430</b>, and a Charge Sub-Function <b>435</b>. Communication Authorization Sub-Function may include restrictions to certain members of a subscriber in terms of their call destination, calling minutes (time), usage, and content. For example, a family subscriber group may restrict a son's call destination to only his parents' mobile phones. Access Authorization Sub-Functions may include service access and privacy controls to certain members of a subscriber group. For example, a subscriber group may elect not to disclose to advertisers personal subscriber information for coupons on advertiser products and services. Charge Authorization Sub-Function checks the subscriber account to ensure that there are credits available to the subscriber use the requested service. The SAUCF Charging Authorization Sub-Function is used when a charging discount is applicable based on the fact that the subscriber is communicating (any form of communication) with members of the “trusted group.” For other forms of charging that do not involve the “trusted group” the SAUCF defers to the Online Charging System (See <figref idrefs="DRAWINGS">FIG. 5</figref>). After the SAUCF <b>420</b> determines whether to deny or authorize the requested service by the Network Element <b>405</b>, it sends a Service Authorization or Denial message <b>415</b> to the Network Element <b>405</b>.
p-0026<figref idrefs="DRAWINGS">FIG. 5</figref> illustrates an exemplary implementation of a SAUCF in network. <figref idrefs="DRAWINGS">FIG. 5</figref> shows two novel interfaces <b>555</b> and <b>515</b> and a unique subscriber specific data store with respect to managing mobile services on a subscriber basis. Note that the SAUCF may be implemented in any network element such as, but not limited to an AAA or a HSS. However, the SAUCF may also be implemented as a separate entity. The SAUCF <b>510</b> acts as a service manager for all services in the network between network elements for a subscriber group. With respect to the On Line Charging System (OCS) <b>520</b> the SAUCF may act as a charging proxy. Authorization requests <b>555</b> are sent by any network element (such as an application server) <b>505</b> to the SAUCF <b>510</b>. In addition, authorization requests may utilize the new “Service Authorization & Utilization Diameter Application” interface with Attribute Value Pair commands (AVPs) that will be described later in this specification. Charging based authorization requests may also be made by network elements as Credit Control Request (CCR) AVPs to describe the way a service is charged. In certain aspects of the invention, the SAUCF supports RFC 4006 (CCR/CCA) because the SAUCF may proxy for the OCS. The SAUCF <b>510</b> may pass charging requests to the OCS <b>520</b> in the form of a CCR Diameter messages. The SAUCF <b>510</b> may apply “trusted groups” discounts for subscribers that qualify. Trusted groups will be described in more details later in this specification.
p-0027<figref idrefs="DRAWINGS">FIG. 5</figref> also shows an application server <b>505</b> that communicates with a PCRF <b>542</b> across a Tx interface <b>545</b> and a PCRF <b>542</b> that communicates to an access gateway across a Ty interface <b>550</b>. Alternatively, the SAUCF <b>510</b> uses a Ru interface <b>615</b> and bypasses the OCS <b>520</b> for network elements that do not require charging authorization but require service level utilization authorization. The Ru interface <b>515</b> maps authorization messages <b>555</b> to service utilization messages sent to a Subscriber Service Utilization Account <b>525</b>. The OCS <b>520</b> communicates with the SAUCF <b>510</b> across a standard IMS Ro interface <b>560</b>.
p-0028The Ru interface <b>515</b> may use a modified Diameter application where the Diameter protocol is defined in RFC 3588. The Diameter Ru interface allows network elements to query the service usage credit balance for a given subscriber from the Subscriber Service Utilization Account <b>525</b> and provide the ability to withdraw and deposit into the balance. The “Subscriber Service Utilization Account” <b>525</b> allows definition of service utilization “buckets” based on “bundled services”. For instance, a “message bundled service” bucket for a subscriber has defined the category “messages” as MMS and SMS. <figref idrefs="DRAWINGS">FIG. 5</figref> also shows exemplary available subscriber service credits <b>530</b>. For example, the subscriber has service credits equal to 5 MMS/SMS messages, one hour of talk time using VOIP/PTT, and 10 MB of Browsing data.
p-0029<figref idrefs="DRAWINGS">FIG. 6</figref> is an exemplary SAUCF High Level Message flow chart. The Service Authorization and Utilization Control Function (SAUCF) <b>610</b> becomes a repository of subscriber service level policies. These policies are defined in Policy Decision Points such as the SAUCF <b>610</b> and enforced via Policy Enforcement Points such as an Application Server or Application Policy Function (network Element <b>605</b>).
p-0030SAUCF implements policies designed by a subscriber or subscriber group with regard to services provided to a subset of subscribers within a subscriber group. For example, a SAUCF incorporates a parental control service into its policy for a subscriber group. The parental controls include restricting all communication by children to only members of the family (father or mother). Further, parents may restrict their children to only 10 MMS or SMS messages per day between noon and 1 pm and 4 pm-6 pm. In addition parents may restrict children to voice services (such as VOIP or PTT) to only between noon and 1 pm and 4 pm-6 pm.
p-0031The SAUCF service policy may also contain rules for providing advertising services to a subscriber. For example, a subscriber may opt in for discounts or refunds by allowing reception of advertisement messages. For example, no more than 10 advertisement messages (MMS or SMS) per month. Further, SAUCF service policy may also contain rules for subscriber privacy. For example, a subscriber may opt in to disclose personal information to advertisers for a coupon/discount for given products. Subscriber may only allow no more than 10 personal location fixes or presence updates per month. In addition, the SAUCF may incorporate family charging services into its service policy for subscriber group. For example, all communication among members of the family is free, or all messages (MMS and SMS) send to members of the family is 50% off during evening hours.
p-0032As shown in <figref idrefs="DRAWINGS">FIG. 6</figref>, a first step is to determine if a subscriber is authorized to use a service is to send a “Service Access Request” message <b>625</b> to the SAUCF <b>610</b>. The network element <b>605</b> may use a Diameter protocol via a modified Diameter Application, namely a “Service Authorization & Utilization Diameter Application”. This modified diameter application is defined with a diameter application ID assigned by the Internet Assigned Numbers Authority (IANA). This Diameter application defines a set of additional attribute-value pairs (AVP) commands to describe the set of service policies desired by the subscriber. Table 1 below describes an exemplary set of additional Diameter AVPs that is supported by the Service Authorization & Utilization Diameter Application.
p-0033<tables id="TABLE-US-00001" num="00001"><table frame="none" colsep="0" rowsep="0" pgwide="1"><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="1" colwidth="77pt" align="left" /><colspec colname="2" colwidth="84pt" align="left" /><colspec colname="3" colwidth="133pt" align="left" /><thead><row><entry namest="1" nameend="3" rowsep="1">TABLE 1</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row><row><entry>Command Name</entry><entry>Parameters</entry><entry>Description</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>Communication-Request</entry><entry /><entry>This command requests communication</entry></row><row><entry /><entry /><entry>permission between two end points.</entry></row><row><entry /><entry>Source-Address</entry><entry>This is the IP address associated with the</entry></row><row><entry /><entry /><entry>subscriber.</entry></row><row><entry /><entry>Destination-Address</entry><entry>This is the IP address associated with the</entry></row><row><entry /><entry /><entry>destination of any communication</entry></row><row><entry /><entry /><entry>originating from the Source-Address.</entry></row><row><entry /><entry>Content</entry><entry>This can be a “URL” or a Media Type such</entry></row><row><entry /><entry /><entry>as Audio and Video.</entry></row><row><entry>Privacy-Request</entry><entry /><entry>This command requests permission to</entry></row><row><entry /><entry /><entry>release to the requestor subscriber (target)</entry></row><row><entry /><entry /><entry>specific data.</entry></row><row><entry /><entry>Requestor</entry><entry>Identity of source of this request. The</entry></row><row><entry /><entry /><entry>identity may be but not limited to: SIP-URI,</entry></row><row><entry /><entry /><entry>MDN, MIN, Email-Address, IM Address,</entry></row><row><entry /><entry /><entry>and NAI.</entry></row><row><entry /><entry>Target</entry><entry>Identity of target of this request. The</entry></row><row><entry /><entry /><entry>identity may be but not limited to: SIP-URI,</entry></row><row><entry /><entry /><entry>MDN, MIN, Email-Address, IM Address,</entry></row><row><entry /><entry /><entry>and NAI.</entry></row><row><entry /><entry>Location</entry><entry>Requestor is requesting “Location”</entry></row><row><entry /><entry /><entry>information about Target. Location</entry></row><row><entry /><entry /><entry>information such as Latitude, Longitude,</entry></row><row><entry /><entry /><entry>and Altitude.</entry></row><row><entry /><entry>Presence</entry><entry>Requestor is requesting “Terminal Status”</entry></row><row><entry /><entry /><entry>information about Target. The status may</entry></row><row><entry /><entry /><entry>be but not limited to Reachable,</entry></row><row><entry /><entry /><entry>Unreachable, and Busy.</entry></row><row><entry /><entry>Identity</entry><entry>Requestor is requesting personal</entry></row><row><entry /><entry /><entry>information about the target. Identity</entry></row><row><entry /><entry /><entry>information may be but not limited to Full</entry></row><row><entry /><entry /><entry>Name, Full Address, Mobile Phone</entry></row><row><entry /><entry /><entry>Number, Email Address, SIP-URI, and IM</entry></row><row><entry /><entry /><entry>Address.</entry></row><row><entry>Service-Authorization-</entry><entry /><entry>This command requests permission to use a</entry></row><row><entry>Request</entry><entry /><entry>particular service identified by Service-ID</entry></row><row><entry /><entry /><entry>and possibly includes the desired service</entry></row><row><entry /><entry /><entry>utilization.</entry></row><row><entry /><entry>Requestor</entry><entry>Identity of source of this request. The</entry></row><row><entry /><entry /><entry>identity may be but not limited to: SIP-URI,</entry></row><row><entry /><entry /><entry>MDN, MIN, Email-Address, IM Address,</entry></row><row><entry /><entry /><entry>and NAI.</entry></row><row><entry /><entry>Target-Subscriber</entry><entry>Identity of target of this request. The</entry></row><row><entry /><entry /><entry>identity may be: SIP-URI, MDN, MIN,</entry></row><row><entry /><entry /><entry>Email-Address, IM Address, and NAI.</entry></row><row><entry /><entry>Target-Service-Content</entry><entry>URL used to identifies the content of a</entry></row><row><entry /><entry /><entry>specific service.</entry></row><row><entry /><entry>Service-ID</entry><entry>ID identifying the specific service for</entry></row><row><entry /><entry /><entry>which authorization is being requested.</entry></row><row><entry /><entry /><entry>Example: MMS, LBS, PTT, etc</entry></row><row><entry /><entry>Utilization-Request-Type</entry><entry>Specifies the type of utilization request.</entry></row><row><entry /><entry /><entry>Exemplary session based types may be:</entry></row><row><entry /><entry /><entry>Initial-Request</entry></row><row><entry /><entry /><entry>Update-Request</entry></row><row><entry /><entry /><entry>Final-Request</entry></row><row><entry /><entry /><entry>Exemplary event based types may be:</entry></row><row><entry /><entry /><entry>One-Time-Event</entry></row><row><entry /><entry>Requested-Service-Units</entry><entry>Contains the amount “service” units desired</entry></row><row><entry /><entry /><entry>by the requestor. For example, for MMS</entry></row><row><entry /><entry /><entry>Requested-Service-Units may be the</entry></row><row><entry /><entry /><entry>number of MMS messages. Another</entry></row><row><entry /><entry /><entry>example may be a VOIP call where the</entry></row><row><entry /><entry /><entry>Requested-Service-Units may be the</entry></row><row><entry /><entry /><entry>number of minutes of conversation. This</entry></row><row><entry /><entry /><entry>parameter forces a response containing the</entry></row><row><entry /><entry /><entry>“Granted-Service-Units” AVP which</entry></row><row><entry /><entry /><entry>defines the number of service units granted</entry></row><row><entry /><entry /><entry>by the SAUCF.</entry></row><row><entry /><entry>Used-Service-Units</entry><entry>Contains the amount “service” units</entry></row><row><entry /><entry /><entry>consumed by the requestor.</entry></row><row><entry>Identity-Request</entry><entry>Subscriber-Address</entry><entry>This is the IP address associated with the</entry></row><row><entry /><entry /><entry>subscriber. If this subscriber has a live data</entry></row><row><entry /><entry /><entry>session for which the AAA has successfully</entry></row><row><entry /><entry /><entry>authenticated this subscriber then the</entry></row><row><entry /><entry /><entry>response to this command is the private-</entry></row><row><entry /><entry /><entry>identifier known as Network Access</entry></row><row><entry /><entry /><entry>Identifier (NAI) corresponding to the</entry></row><row><entry /><entry /><entry>subscriber. If no valid session exists for this</entry></row><row><entry /><entry /><entry>subscriber then the AAA returns an error</entry></row><row><entry /><entry /><entry>code.</entry></row><row><entry /><entry>Target-Address</entry><entry>This is the IP address associated with the</entry></row><row><entry /><entry /><entry>target of the subscriber communication. If</entry></row><row><entry /><entry /><entry>this target has a live data session for which</entry></row><row><entry /><entry /><entry>the AAA has successfully authenticated this</entry></row><row><entry /><entry /><entry>subscriber then the response to this</entry></row><row><entry /><entry /><entry>command is the private-identifier known as</entry></row><row><entry /><entry /><entry>Network Access Identifier (NAI)</entry></row><row><entry /><entry /><entry>corresponding to the target. If no valid</entry></row><row><entry /><entry /><entry>session exists for this target subscriber then</entry></row><row><entry /><entry /><entry>the AAA returns an error code.</entry></row><row><entry>Charge-Request</entry><entry /><entry>This command is required for any charge</entry></row><row><entry /><entry /><entry>authorization request and may include</entry></row><row><entry /><entry /><entry>Credit Control Diameter parameters</entry></row><row><entry /><entry /><entry>destined for the On Line Charging System.</entry></row><row><entry /><entry>Requestor</entry><entry>Identity of source of this request. The</entry></row><row><entry /><entry /><entry>identity may be but not limited to: SIP-URI,</entry></row><row><entry /><entry /><entry>MDN, MIN, Email-Address, IM Address,</entry></row><row><entry /><entry /><entry>and NAI.</entry></row><row><entry /><entry>Charged-Service-ID</entry><entry>ID identifying the specific service for</entry></row><row><entry /><entry /><entry>which charging is being requested.</entry></row><row><entry /><entry /><entry>Example: MMS, LBS, PTT, etc.</entry></row><row><entry /><entry>Any Additional AVPs in</entry></row><row><entry /><entry>Credit Control Application</entry></row><row><entry /><entry>as defined in RFC 4006</entry></row><row><entry /><entry>“Credit Control</entry></row><row><entry /><entry>Application”</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>
p-0034As shown in <figref idrefs="DRAWINGS">FIG. 6</figref>, in a step <b>1</b>, a “Service Access Request” message is a subset of the Service Authorization & Utilization Diameter Application AVPs defined in Table 1. For example, when the SAUCF receives the Communication-Request AVP, the SAUCF then sends the Authentication, Authorization and Accounting (AAA) server <b>615</b> an Identity-Request, in a step <b>2</b><b>630</b>, with the Subscriber-Address and Target-Address set to be the Source-Address and the Destination-Address, respectively. These parameters may have been previously received from a Communication-Request. The AAA <b>615</b> determines whether a valid data session exists for this subscriber/target and returns the Network Address Identifier (NAI) that uniquely identifies the subscriber and target to the operator network.
p-0035The service level policies defined in the Service Authorization and Utilization Control Function are bound to a given subscriber based on the NAI. The NAI is used in the SAUCF to bind subscribers to service policy rules associated with this subscriber. Further, each NAI in the SAUCF is also bound to a set of public-identities (aliases) associated with this subscriber as shown in <figref idrefs="DRAWINGS">FIG. 7</figref>. The following minimal aliases are defined but are not exhaustive SIP-URI, MDN, MIN, Email Address, and Instant Message Address.
p-0036Each subscriber in the SAUCF is bound to a “trusted group” of subscribers defined in <figref idrefs="DRAWINGS">FIG. 7</figref>. Each subscriber is also identified via NAIs and aliases. Service policy rules govern the binding between a given subscriber and the trusted group as shown in <figref idrefs="DRAWINGS">FIG. 7</figref>. In a step <b>3</b> (<b>635</b>) of <figref idrefs="DRAWINGS">FIG. 6</figref> the SAUCF using the NAI for this subscriber, retrieves his/her aliases and also other aliases of the trusted group. The SAUCF then proceeds to apply the service policy rules <b>620</b>.
p-0037<figref idrefs="DRAWINGS">FIG. 7</figref> illustrates that each subscriber is bound to a “trusted group” of subscribers. Each subscriber is also identified via NAIs and aliases. Service policy rules govern the binding between a given subscriber and the trusted group. For example, a trusted group <b>710</b> may be the mother <b>715</b> and father <b>720</b> of a subscriber group. A son <b>705</b> is bound by the service rules imposed by the mother <b>715</b> and father <b>720</b>. An exemplary service rule may be that the son may only call mother and father and no one else. Thus, if the son <b>705</b> requests to call another person, then the SAUCF implements the service rule and denies the request to the son.
p-0038<figref idrefs="DRAWINGS">FIGS. 8-11</figref> are flow charts that illustrate an exemplary application of service policy rules. A first set of steps may be to apply communication service rules. For example, a son may be restricted to call only his parents. Consequently, at a first step <b>805</b>, a SAUCF may match the Target NAI against the Subscriber Trusted Group (parents) NAIs. If a match is not found then service access is denied <b>820</b> as shown in step <b>4</b>.<i>b </i><b>645</b> in <figref idrefs="DRAWINGS">FIG. 6</figref>. If a match is found, then the SAUCF may match the allowed communication times by the requesting subscriber with the requesting time of the subscriber at a step <b>810</b>. If a match is not found then service access is denied <b>820</b> as shown in step <b>4</b>.<i>b </i><b>645</b> in <figref idrefs="DRAWINGS">FIG. 6</figref>. For example, if the requesting subscriber is a son who is calling his mother at 3 pm but is only allowed to call his parents between 5 pm and 7 pm, then service access is denied to him. At a next step <b>815</b>, a SAUCF matches the requested content against the disallowed content for the subscriber. If a match is found (content disallowed) then service access is denied <b>820</b> as shown in step <b>4</b>.<i>b </i><b>645</b> in <figref idrefs="DRAWINGS">FIG. 6</figref>. For example, if a subscriber requests streaming video from a particular website, and the trusted group has assigned the particular website as disallowed content, and then the subscriber is denied service <b>820</b>. However, if a match is not found, the SAUCF may continue by applying Security and Privacy Service rules <b>825</b>.
p-0039At a next step <b>905</b>, the SAUCF determines whether to apply Security and Privacy rules based on whether a Privacy Request AVP is present (See Table 1). It may then match the Location, Presence, or Identity parameter against the setting for the subscriber's trusted group. If a match is found then service access is denied <b>920</b> as shown in step <b>4</b>.<i>b </i><b>645</b> in <figref idrefs="DRAWINGS">FIG. 6</figref>. Next, the SAUCF may apply Service Authorization and Utilization rules. At a next step <b>910</b>, the SAUCF matches the Service ID against the Service ID allowed for the subscriber. If a match is found and the Target Service Content parameter is present (See Table 1), then the SAUCF matches the Target Service Content against the disallowed content for the subscriber at a next step <b>915</b>. If a match is found then service access is denied <b>920</b> as shown in step <b>4</b>.<i>b </i><b>645</b> in <figref idrefs="DRAWINGS">FIG. 6</figref>. However, if a match is not found the SAUCF may continue to apply further service authorization and utilization rules <b>925</b>.
p-0040A set of steps <b>1005</b>-<b>1025</b> apply further exemplary service authorization and utilization rules. At a next step <b>1005</b>, the SAUCF applies service utilization bonuses if it determines that the subscriber has not exceeded its service utilization quota. For example, if a Charging Request is present and a Charged Service ID does not match the Service ID, then the SAUCF checks if the Requested-Service-Units parameter (See Table 1) is present and a charge discount is applicable. If so, then a bonus is applied. Note that checking whether the Charging Request is present and a Charged Service ID does not match the Service ID shows that the SAUCF is a proxy for the OCS and that any charging requests are handled by the OCS. Further, it ensures that the “Subscriber Service Utilization Account” is accessed by either the SAUCF or the OCS but not both. At a next step <b>1010</b>, if the Requested Service Units or Used Service Unit AVP are present (See Table 1) then they are mapped to the Ru interface as shown in <figref idrefs="DRAWINGS">FIG. 12</figref> to send to the Subscriber Service Utilization Account. At a next step <b>1015</b>, the SAUCF determines whether the Subscriber Service Utilization Account can satisfy the requested service. If not, then the requested service is denied <b>1020</b>. If so, then the SAUCF may apply “Trusted Group” charge service rules <b>1025</b>.
p-0041A set of steps <b>1105</b>-<b>1120</b> implement exemplary “Trusted Group” charge service rules. At a next step <b>1105</b>, the SAUCF determines whether a “Trusted Group” charge discount is applicable. At a next step <b>1110</b>, the SAUCF then applies the discount. At a next step <b>1115</b>, the request message is forwarded to the OCS. At a next step <b>1125</b>, the service is allowed as shown in Step <b>4</b>.<i>a </i>(<b>640</b>) in <figref idrefs="DRAWINGS">FIG. 7</figref>.
p-0042As discussed previously, the Ru (Real Time Utilization) interface is a modified Diameter application that allows network elements to query the service usage credit balance (held in a network element called the “Subscriber Service Utilization Account”) for a given subscriber, and provide the ability to withdraw and deposit into the balance. The “Subscriber Service Utilization Account” allows definition of service utilization “buckets” based on “bundled services”. For instance, a “message bundled service” bucket for a subscriber has messages defined as MMS and SMS.
p-0043The table below describes a modified set of Diameter AVP commands that may be supported by the Real Time Service Utilization Diameter application.
p-0044<tables id="TABLE-US-00002" num="00002"><table frame="none" colsep="0" rowsep="0" pgwide="1"><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="1" colwidth="84pt" align="left" /><colspec colname="2" colwidth="77pt" align="left" /><colspec colname="3" colwidth="119pt" align="left" /><thead><row><entry namest="1" nameend="3" rowsep="1">TABLE 2</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row><row><entry>Command Name</entry><entry>Parameters</entry><entry>Description</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>Service-Utilization-Query</entry><entry /><entry>This command queries the balance of</entry></row><row><entry /><entry /><entry>the subscriber utilization account. The</entry></row><row><entry /><entry /><entry>response is the number of units</entry></row><row><entry /><entry /><entry>available for the requestor for this</entry></row><row><entry /><entry /><entry>Service-ID.</entry></row><row><entry /><entry>Service-ID</entry><entry>ID identifying the specific service for</entry></row><row><entry /><entry /><entry>which balance query is being requested.</entry></row><row><entry /><entry /><entry>Example: MMS, LBS, PTT, etc.</entry></row><row><entry /><entry>Requestor</entry><entry>Identity of source of this request. The</entry></row><row><entry /><entry /><entry>identity may be: SIP-URI, MDN, MIN,</entry></row><row><entry /><entry /><entry>Email-Address, IM Address, and NAI.</entry></row><row><entry>Service-Utilization-</entry><entry /><entry>This command request a service unit</entry></row><row><entry>Withdrawal</entry><entry /><entry>balance withdrawal from this</entry></row><row><entry /><entry /><entry>subscriber's utilization account. The</entry></row><row><entry /><entry /><entry>response is the number of units granted</entry></row><row><entry /><entry /><entry>for this request.</entry></row><row><entry /><entry>Service-ID</entry><entry>ID identifying the specific service for</entry></row><row><entry /><entry /><entry>which a balance service unit withdrawal</entry></row><row><entry /><entry /><entry>is being requested. Example: MMS,</entry></row><row><entry /><entry /><entry>LBS, PTT, etc.</entry></row><row><entry /><entry>Requestor</entry><entry>Identity of source of this request. The</entry></row><row><entry /><entry /><entry>identity may be: SIP-URI, MDN, MIN,</entry></row><row><entry /><entry /><entry>Email-Address, IM Address, and NAI.</entry></row><row><entry /><entry>Service-Units-Withdrawn</entry><entry>The number of service units to be</entry></row><row><entry /><entry /><entry>withdrawn from the subscriber's</entry></row><row><entry /><entry /><entry>utilization account</entry></row><row><entry>Service-Utilization-Deposit</entry><entry /><entry>This command requests a service unit</entry></row><row><entry /><entry /><entry>deposit to the balance of this</entry></row><row><entry /><entry /><entry>subscriber's utilization account.</entry></row><row><entry /><entry>Service-ID</entry><entry>ID identifying the specific service for</entry></row><row><entry /><entry /><entry>which a balance service unit deposit is</entry></row><row><entry /><entry /><entry>being requested. Example: MMS, LBS,</entry></row><row><entry /><entry /><entry>PTT, etc.</entry></row><row><entry /><entry>Requestor</entry><entry>Identity of source of this request. The</entry></row><row><entry /><entry /><entry>identity may be: SIP-URI, MDN, MIN,</entry></row><row><entry /><entry /><entry>Email-Address, IM Address, and NAI.</entry></row><row><entry /><entry>Service-Units-Deposited</entry><entry>The number of service units to be</entry></row><row><entry /><entry /><entry>deposited into the subscriber's</entry></row><row><entry /><entry /><entry>utilization account</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>
p-0045<figref idrefs="DRAWINGS">FIG. 12</figref> shows the service utilization messages received by the SAUCF are mapped to the Ru Interface. The Ru interface is between the SAUCF <b>1205</b> and the Subscriber Service Utilization Account <b>1210</b>. For example, a Service Authorization Request and a Requested Service Units message <b>1215</b> received by the SAUCF <b>1205</b> are mapped to the Ru interface as a Service Utilization Withdrawal message <b>1220</b> to the Subscriber Service Utilization Account <b>1210</b>. Another example is that a Service Authorization Request and a Used Service Units message <b>1225</b> received by the SAUCF are mapped to the Ru interface as a Service Utilization Deposit message <b>1230</b> to the Subscriber Service Utilization Account <b>1210</b>.
p-0046<figref idrefs="DRAWINGS">FIG. 13</figref> is a flow chart illustrating an exemplary application of service utilization bonuses. Discounts may be defined in the SAUCF as part of the charging rules. Discounts in the SAUCF apply both to the price of the service as well as the number of units utilized for that service. For the number of units utilized for that service the discount becomes a cumulative bonus. For example, sending an MMS message may cost 10 cents and sending MMS messages to members of the family produces a 50% discount. Then sending the first MMS message costs 5 cents and sending the second also costs 5 cents but the subscriber has gained an additional MMS message as a bonus. That is, the subscriber sent two MMS messages but consumed only one. Note that the SAUCF accumulates bonuses on a per service basis. So if the 50% discount continues to apply and the subscriber sends 2 MMS messages and 2 SMS messages than the subscriber will only have consumed one MMS and one SMS messages, respectively. The SAUCF may need to maintain a per-subscriber, per-service counter called a Service-Units-Bonus to support the cumulative bonus for service unit discounts as shown in <figref idrefs="DRAWINGS">FIG. 13</figref>. At a step <b>1305</b>. a Service-Units-Bonus counter is initialized with a value of zero (0%) units for this subscriber for this service. Each time a service unit is consumed the discount is applied. A service unit may be considered consumed when a one time service utilization or charging event is received (<b>1310</b>) or when a service session is over (<b>1315</b>). Thus, at a step <b>1302</b>, the SAUCF determines whether a completed service unit has been consumed. If so then it applies the bonus at a step <b>1325</b>, for example, Service-Units-Bonus=Service-Units-Bonus+Discount-Rate. At a step <b>1330</b> the SAUCF sets the value of “Service-Utilization-Deposit” to zero. At a step <b>1335</b> the SAUCF determines whether Service-Units-Bonus greater than or equal to 100%. If so, then at a step <b>1340</b> value of “Service-Utilization-Deposit” is incremented by 1 unit. At step <b>1345</b>, Service-Units-Bonus=Service-Units-Bonus−100%. However, if Service-Units-Bonus is less than 100%, then the SAUCF sends a “Service-Utilization-Deposit” to the Subscriber Service Utilization Account at step <b>1350</b>.
p-0047A service unit is consumed when a one time service utilization or charging event occurs or when a service session is over. A one time service utilization or charging event may be the following: (a) A Service-Authorization-Request AVP with a Requested-Service-Units AVP is received by the SAUCF and the unit-type is (a) One-Time-Event; or (b) A Credit Control (RFC4006) request with “Event-Request” AVP is received. A service session is over when the following occurs: (a) the SAUCF keeps track of units consumed for Service-Authorization-Requests by tracking the “Granted-Service-Units” returned by the Subscriber Service Utilization Account; (b) the SAUCF keeps track of chargeable consumed units by tracking the “Granted-Units” returned by the On Line Charging System; (c) a service session is over when a Service-Authorization-Request AVP with a Requested-Service-Units AVP is received by the SAUCF and the unit-type is Final-Request and “Used-Service-Units” AVP; and (d) a chargeable service session is over when a Credit Control message is received with a request type of “Terminate” and Used-Units. Note that time constraints may also be included in the calculation of the discount. For example, time constraints may indicate when discounts apply.
p-0048The SAUCF may also apply charging discounts to a subscriber for being a member of Trusted Groups. The SAUCF may apply special discounts that cover multiple services tied to certain communication constraints such as the constraint of communication within a “trusted group”. This is not possible by utilizing an On Line Charging System (OCS) alone. An exemplary application of Trusted-Group discounts may be that the SAUCF on receipt of a Charge-Request AVP may do the following: (1) retrieve the price for this service from the OCS; (2) send a Credit Control message with Price-Inquiry AVP to the OCS for this Charged-Service-ID; (3) apply the Trusted-Group discount for this subscriber using price returned in the Credit Control Answer message; (4) Compute Discount=Service Price*Trusted Group Discount Rate; and (5) send a Credit Control message with Refund AVP which reflects the Discount:
p-0049All references, including publications, patent applications, and patents, cited herein are hereby incorporated by reference to the same extent as if each reference were individually and specifically indicated to be incorporated by reference and were set forth in its entirety herein.
p-0050The use of the terms “a” and “an” and “the” and similar referents in the context of describing the invention (especially in the context of the following claims) are to be construed to cover both the singular and the plural, unless otherwise indicated herein or clearly contradicted by context. The terms “comprising,” “having,” “including,” and “containing” are to be construed as open-ended terms (i.e., meaning “including, but not limited to,”) unless otherwise noted. Recitation of ranges of values herein are merely intended to serve as a shorthand method of referring individually to each separate value falling within the range, unless otherwise indicated herein, and each separate value is incorporated into the specification as if it were individually recited herein. All methods described herein can be performed in any suitable order unless otherwise indicated herein or otherwise clearly contradicted by context. The use of any and all examples, or exemplary language (e.g., “such as”) provided herein, is intended merely to better illuminate the invention and does not pose a limitation on the scope of the invention unless otherwise claimed. No language in the specification should be construed as indicating any non-claimed element as essential to the practice of the invention.
p-0051Preferred embodiments of this invention are described herein, including the best mode known to the inventors for carrying out the invention. Variations of those preferred embodiments may become apparent to those of ordinary skill in the art upon reading the foregoing description. The inventors expect skilled artisans to employ such variations as appropriate, and the inventors intend for the invention to be practiced otherwise than as specifically described herein. Accordingly, this invention includes all modifications and equivalents of the subject matter recited in the claims appended hereto as permitted by applicable law. Moreover, any combination of the above-described elements in all possible variations thereof is encompassed by the invention unless otherwise indicated herein or otherwise clearly contradicted by context.
Contents4
14 sheets
Sheet 1 Sheet 2 Sheet 3 Sheet 4 Sheet 5 Sheet 6 Sheet 7 Sheet 8 Sheet 9 Sheet 10 Sheet 11 Sheet 12 Sheet 13 Sheet 14
Every citation, both ways
| Document | Relation | Office | Cited during |
|---|---|---|---|
| WO2012145902A1 | Cited by | World Intellectual Property Organization (WIPO) | International search |
| CN106717041A | Cited by | China | Search report |
| US10158579B2 | Cited by | United States of America | Applicant |
| US2012096139A1 | Cited by | United States of America | Pre-grant |
| US10929240B2 | Cited by | United States of America | Applicant |
| US2011066491A1 | Cited by | United States of America | Pre-grant |
| US2016021146A1 | Cited by | United States of America | Pre-grant |
| US2010135190A1 | Cited by | United States of America | Pre-grant |
| US2013179583A1 | Cited by | United States of America | Pre-grant |
| US10776395B2 | Cited by | United States of America | Applicant |
| US9762624B2 | Cited by | United States of America | Search report |
| US8966034B1 | Cited by | United States of America | Applicant |
| US9143548B2 | Cited by | United States of America | Search report |
| US9923965B2 | Cited by | United States of America | Applicant |
| US8595267B2 | Cited by | United States of America | Applicant |
| US10182322B2 | Cited by | United States of America | Applicant |
| US9116862B1 | Cited by | United States of America | Applicant |
| US9191804B1 | Cited by | United States of America | Search report |
| CN104168276A | Cited by | China | Search report |
| US10334440B2 | Cited by | United States of America | Applicant |
| US11388043B2 | Cited by | United States of America | Applicant |
| US10608870B2 | Cited by | United States of America | Applicant |
| US10057327B2 | Cited by | United States of America | Applicant |
| US11625273B1 | Cited by | United States of America | Applicant |
| US2014130138A1 | Cited by | United States of America | Pre-grant |
| US10231120B2 | Cited by | United States of America | Search report |
| US9432459B2 | Cited by | United States of America | Applicant |
| US9871828B2 | Cited by | United States of America | Search report |
| CN103477587A | Cited by | China | Search report |
| US11894972B2 | Cited by | United States of America | Applicant |
| US9559900B1 | Cited by | United States of America | Applicant |
| US9069827B1 | Cited by | United States of America | Applicant |
| US10877669B1 | Cited by | United States of America | Applicant |
| US10177993B2 | Cited by | United States of America | Applicant |
| US12413635B2 | Cited by | United States of America | Applicant |
| US9680811B2 | Cited by | United States of America | Search report |
| WO2016011302A1 | Cited by | World Intellectual Property Organization (WIPO) | International search |
| US9923839B2 | Cited by | United States of America | Applicant |
| US11609697B2 | Cited by | United States of America | Applicant |
| US10216441B2 | Cited by | United States of America | Applicant |
| US10581680B2 | Cited by | United States of America | Applicant |
| US10015042B2 | Cited by | United States of America | Applicant |
| US8943415B2 | Cited by | United States of America | Applicant |
| US2014105103A1 | Cited by | United States of America | Pre-grant |
| US9367252B2 | Cited by | United States of America | Applicant |
| US9886348B2 | Cited by | United States of America | Applicant |
| US10715967B1 | Cited by | United States of America | Search report |
| US12393607B2 | Cited by | United States of America | Applicant |
| US8918435B2 | Cited by | United States of America | Applicant |
| US2012030331A1 | Cited by | United States of America | Pre-grant |
| US11252475B2 | Cited by | United States of America | Search report |
| US10764727B2 | Cited by | United States of America | Applicant |
| US9923784B2 | Cited by | United States of America | Applicant |
| US2011173545A1 | Cited by | United States of America | Pre-grant |
| US9332036B2 | Cited by | United States of America | Search report |
| US11899684B2 | Cited by | United States of America | Applicant |
| US8565722B1 | Cited by | United States of America | Search report |
| US10244005B2 | Cited by | United States of America | Search report |
| US10015671B2 | Cited by | United States of America | Applicant |
| US10715967B1 | Cited by | United States of America | Search report |
| US12316489B2 | Cited by | United States of America | Applicant |
| US9754009B2 | Cited by | United States of America | Applicant |
| US10608952B2 | Cited by | United States of America | Applicant |
| CN104270734A | Cited by | China | Search report |
| US10700925B2 | Cited by | United States of America | Applicant |
| US9894560B2 | Cited by | United States of America | Applicant |
| US2002068545A1 | Cites | United States of America | Pre-grant |
| US2003092383A1 | Cites | United States of America | Pre-grant |
| US2003097403A1 | Cites | United States of America | Pre-grant |
| US2004102182A1 | Cites | United States of America | Pre-grant |
| US2004192364A1 | Cites | United States of America | Pre-grant |
| US2004259574A1 | Cites | United States of America | Pre-grant |
| US2006046714A1 | Cites | United States of America | Pre-grant |
| US2006111135A1 | Cites | United States of America | Pre-grant |
| US2006112427A1 | Cites | United States of America | Pre-grant |
| US2006250956A1 | Cites | United States of America | Pre-grant |
| US2007117558A1 | Cites | United States of America | Pre-grant |
| US2008052258A1 | Cites | United States of America | Pre-grant |
| US2008065746A1 | Cites | United States of America | Pre-grant |
| US2008098062A1 | Cites | United States of America | Pre-grant |
| US6424706B1 | Cites | United States of America | Pre-grant |
| Kim, Sang-ki, Modeling of policy-based mobile payment, February 2004, The 6th International Conference of Advanced Communication Technology, vol. 2, pp. 1009-1011. | Non-patent | – | Pre-grant |
4 members in 1 office; this record represents the family
Members4
| Document | Office | Kind | |
|---|---|---|---|
| US2009172782A1 | United States of America | A1 | |
| US8505073B2 | United States of America | B2 | |
| US2014165157A1 | United States of America | A1 | |
| US8756663B1 | United States of America | B1 |
64 transactions on the USPTO file
Allowed after 1 non-final rejection, 1 final rejection and 1 RCE.
- Non-final rejections
- 1
- Final rejections
- 1
- RCEs
- 1
- Appeals
- 0
Over time
Point at a mark for the transactionTransactions
| Event | Code | |
|---|---|---|
| Payment of Maintenance Fee, 12th Year, Large EntityM1553 | M1553 | |
| Payment of Maintenance Fee, 8th Year, Large EntityM1552 | M1552 | |
| Recordation of Patent Grant MailedPGM/ | PGM/ | |
| Patent Issue Date Used in PTA CalculationAllowedPTAC | PTAC | |
| Email NotificationEML_NTR | EML_NTR | |
| Issue Notification MailedAllowedWPIR | WPIR | |
| Dispatch to FDCD1935 | D1935 | |
| Email NotificationEML_NTR | EML_NTR | |
| Printer Rush- No mailingTCPB | TCPB | |
| Mailing Corrected Notice of AllowabilityMCNOA | MCNOA | |
| Examiner's Amendment CommunicationEX.A | EX.A | |
| Corrected Notice of AllowabilityCNOA | CNOA | |
| Interview Summary - Examiner InitiatedEXIE | EXIE | |
| Pubs Case Remand to TCPUBTC | PUBTC | |
| Application Is Considered Ready for IssuePILS | PILS | |
| Issue Fee Payment VerifiedN084 | N084 | |
| Issue Fee Payment ReceivedIFEE | IFEE | |
| Electronic ReviewELC_RVW | ELC_RVW | |
| Email NotificationEML_NTF | EML_NTF | |
| Mail Notice of AllowanceAllowedMN/=. | MN/=. | |
| Notice of Allowance Data Verification CompletedAllowedN/=. | N/=. | |
| Reasons for AllowanceEX.R | EX.R | |
| Examiner's Amendment CommunicationEX.A | EX.A | |
| Interview Summary - Examiner InitiatedEXIE | EXIE | |
| Date Forwarded to ExaminerFWDX | FWDX | |
| Supplemental ResponseSA.. | SA.. | |
| Date Forwarded to ExaminerFWDX | FWDX | |
| Disposal for a RCE / CPA / R129AbandonedABN9 | ABN9 | |
| Miscellaneous Incoming LetterLET. | LET. | |
| Request for Continued Examination (RCE)RCEX | RCEX | |
| Request for Extension of Time - GrantedXT/G | XT/G | |
| Workflow - Request for RCE - BeginBRCE | BRCE | |
| Email NotificationEML_NTR | EML_NTR | |
| Mail Applicant Initiated Interview SummaryMEXIA | MEXIA | |
| Interview Summary- Applicant InitiatedEXIA | EXIA | |
| Electronic ReviewELC_RVW | ELC_RVW | |
| Email NotificationEML_NTF | EML_NTF | |
| Mail Final Rejection (PTOL - 326)Final rejectionMCTFR | MCTFR | |
| Final RejectionFinal rejectionCTFR | CTFR | |
| Date Forwarded to ExaminerFWDX | FWDX | |
| Response after Non-Final ActionA... | A... | |
| Electronic ReviewELC_RVW | ELC_RVW | |
| Email NotificationEML_NTF | EML_NTF | |
| Mail Non-Final RejectionNon-final rejectionMCTNF | MCTNF | |
| Non-Final RejectionNon-final rejectionCTNF | CTNF | |
| Case Docketed to Examiner in GAUDOCK | DOCK | |
| PG-Pub Issue NotificationPG-ISSUE | PG-ISSUE | |
| Case Docketed to Examiner in GAUDOCK | DOCK | |
| IFW TSS Processing by Tech Center CompleteTSSCOMP | TSSCOMP | |
| Application Dispatched from OIPEOIPE | OIPE | |
| Information Disclosure Statement consideredIDSC | IDSC | |
| Electronic Information Disclosure StatementEIDS. | EIDS. | |
| Information Disclosure Statement (IDS) FiledWIDS | WIDS | |
| Filing Receipt - UpdatedFLRCPT.U | FLRCPT.U | |
| Application Is Now CompleteCOMP | COMP | |
| Sent to Classification ContractorPGPC | PGPC | |
| Additional Application Filing FeesADDFLFEE | ADDFLFEE | |
| Applicant has submitted new drawings to correct Corrected Papers problemsCORRDRW | CORRDRW | |
| A statement by one or more inventors satisfying the requirement under 35 USC 115, Oath of the ApplicOATHDECL | OATHDECL | |
| Notice Mailed--Application Incomplete--Filing Date AssignedINCD | INCD | |
| Filing ReceiptFLRCPT.O | FLRCPT.O | |
| Cleared by OIPE CSRL194 | L194 | |
| IFW Scan & PACR Auto Security ReviewSCAN | SCAN | |
| Initial Exam Team nnIEXX | IEXX |
10 legal events, as the office reported them to INPADOC
Over the term
Point at a mark for the eventEvents
| Event | Code | |
|---|---|---|
| AssignmentAS | AS | |
| AssignmentAS | AS | |
| AssignmentAS | AS | |
| AssignmentAS | AS | |
| Maintenance fee paymentMAFP | MAFP | |
| Maintenance fee paymentMAFP | MAFP | |
| Fee paymentFPAY | FPAY | |
| Information on status: patent grantGrantedPATENTED CASESTCF | STCF | |
| Fee payment procedurePAYOR NUMBER ASSIGNED (ORIGINAL EVENT CODE: ASPN); ENTITY STATUS OF PATENT OWNER: LARGE ENTITYFEPP | FEPP | |
| AssignmentAS | AS |
Numbers
- Application
- 96790907
Titles
- English
- Service Utilization Control Manager
Patent term adjustment
- A delay
- +1,156 daysthe office missed an examination deadline
- B delay
- +282 dayspendency past three years
- Overlap
- −19 daysdelays counted once
- Applicant delay
- −11 days
- Net adjustment
- 1,408 days
Classification
- CPC, 8
- H04W12/08
- G06Q30/06
- H04L63/102
- H04L65/1016
- H04L65/1069
- H04W28/16
- H04W88/14
- H04W12/37
- IPC, 2
- H04L9 32
- G06Q99 00