Techniques for allowing online charging in cases where the online charging system (OCS) is unreachable or partially unreachable are discussed herein. For example, when the OCS cannot be reached and is unable to authorize the requested services, the services can be provided (e.g., a voice communication session established between two devices) without having to wait for authorization from the OCS. Upon completion of the communication session, the OCS is contacted to report the actual number of units used during the session so that the account of the subscriber can be adjusted. In some examples, the IMS tags the CDR provided to the billing system to indicate that the OCS was not able to authorize the communication session. In this way, the billing system is notified that the OCS is to be contacted so that the subscriber's balance can be adjusted.

A mechanism to insert a correct call identifier as a session identifier in an accounting request (AR) record and a mechanism for a charging control function (CCF) device to check the value and generate an error as required. A method can comprise receiving a session initiation protocol packet representing a first attribute value pair; based on the session initiation protocol packet, checking for an existence of an identity between a first field associated with the session initiation protocol packet and a second field associated with a second attribute value pair; and in response to a result of the checking being that the existence of the identity is not determined to be presents between the first field and the second field, updating a third attribute value pair.

Device identification data, network connection data, and other related data may be analyzed to determine an account classification, particularly before the account has even been used (or before extensive use has occurred). An account with direct or indirect access to databases may be created by a user, where a service provider may wish to assess the account's creation to detect if a bad actor is generating the account to engage in malicious computing actions or fraud. The account's creation data may be scored by an intelligent engine that detects malicious or fraudulent account creations, for example, based on whether a virtual private network is used to create the account, whether a VoIP phone number is being used, etc. The account may be monitored over a period of time and the account activities analyzed again to determine whether technical data associated with the account indicates a particular risk classification is appropriate.

The proposed solution relates to a method and an apparatus in a communication system. The solution comprises creating (400) a bearer for user terminal communication; transmitting (402) a credit control request message to Online Charging System, storing (404) the message to a transmission buffer, receiving (406) a credit control answer message as a reply to the request message and, if the credit control answer message comprises an error code: opening (412) a charging data record and timestamping the opening with the time the bearer was created, copying (414) the message from the transmission buffer to the charging data record, adding (416) information regarding rating groups affected by the error to the charging data record as containers and closing the containers and updating (418) result code-field of the charging data record according to the error code.

A wireless service provider system for authorizing wireless service on a wireless device includes a backend system. The backend system configured receive a request for the wireless service along with a monetary value of the wireless service in any requested amount from the connected device, receive a payment authorization or a verification of payment for the wireless service in the requested amount from the connected device, and receive a request from the connected device for allocating the wireless service.

Technology to respond to a termination reason of an accounting record via an improved charging component is disclosed. The disclosed subject matter can be backwards compatible to support responding to a conventional SIP BYE method and a conventional SIP CANCEL method. Additionally, the disclosed subject matter can respond to other SIP methods, empty reason-headers, etc. In an aspect, a reason-header can be forced into an accounting record based on received session termination information. In an embodiment, the reason-header can be determined to satisfy a rule related to acceptable reason-headers. Where the rule is determined to be unsatisfied, a query can be generated toward a device that supported the now terminated communication, wherein a response to the query can comprise another reason-header that can be determined to satisfy the rule. The accounting record can be updated based on the other reason-header and employed in generating a charging data record that can alter corresponding billing.

An intelligent gateway device provided at a premise (home or business) for providing and managing application services associated with use and support of a plurality of digital endpoint devices associated with the premises. The device includes a communications and processing infrastructure integrated with a peer and presence messaging based communications protocol for enabling communications between the device and an external support network and between the device and connected digital endpoint devices. A services framework at the gateway device implements the communications and processing infrastructure for enabling service management, service configuration, and authentication of user of services at the intelligent gateway. The framework provides a storage and execution environment for supporting and executing received service logic modules relating to use, management, and support of the digital endpoint devices. Thus, the gateway device provides a network-based services point of presence for a plurality of digital endpoint devices at the premises.

Provided are an apparatus failure influence range recognition apparatus, an apparatus failure influence range recognition method, and a program capable of billing for a proper call charge for a call suspected of non-provision of a service. An apparatus failure influence range recognition apparatus (10) includes a reception unit (11) configured to receive apparatus failure information which is failure information of an element constituting a network, user information which is information regarding a user of a service, and call details information of an IP telephone, and a calculation unit (13) configured to calculate, by linking the appa.rakus failure information, the user information, and the call details information with each other, a subtracted call charge with respect to a call charge for a suspected call influenced by an apparatus failure.

Techniques for allowing online charging in cases where the online charging system (OCS) is unreachable or partially unreachable are discussed herein. For example, when the OCS cannot be reached and is unable to authorize the requested services, the services can be provided (e.g., a voice communication session established between two devices) without having to wait for authorization from the OCS. Upon completion of the communication session, the OCS is contacted to report the actual number of units used during the session so that the account of the subscriber can be adjusted. In some examples, the IMS tags the CDR provided to the billing system to indicate that the OCS was not able to authorize the communication session. In this way, the billing system is notified that the OCS is to be contacted so that the subscriber's balance can be adjusted.

A computer implemented method for decreasing latency in a billing cycle, the method comprising receiving a first charging data report (CDR) including a sent data volume from a vendor and comparing the first CDR to an operator received data volume and when the first CDR does not match the operator received data volume, rejecting the first charging report. The method further comprising providing a second CDR having the operator received data volume to the vendor, receiving a charging data acceptance including a negotiated data volume from the vendor, constructing a publicly verifiable proof of charging based on the charging data acceptance, and sending the publicly verifiable proof of charging to the vendor.