Caller Information Provision via Dynamic Communication Path Selection

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Existing solutions for providing caller information during a call in telecommunications networks are limited, as they require pre-stored contact details, network query applications, or both parties to support Rich Communication Service (RCS), and can be hindered by limited network coverage or the inability to identify the caller's MSISDN, leading to delayed or unavailable information.

Innovation Solution

A method and system that determine a communication channel for providing content data from caller to callee by generating an inquiry to assess the callee's capability to support a specific communication framework, such as RCS, and transmitting data over that framework if supported, or through the connected network if not, ensuring successful data delivery and call setup.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Loss of information

If a query is initiated towards a network element to retrieve caller information, then information on unknown callers can be provided to the callee, but the retrieval may take too long when network coverage is limited, causing delay during the call setup

Engineering Contradiction:
Improvecaller information availabilityVSAvoidcall setup time
Core Design Contradiction:
Loss of informationVSLoss of time

Solution Approach 1:

The patent applies preliminary action by determining the callee's capability to support RCS communication framework before initiating the call setup process. This capability determination is performed in advance during the call setup phase, allowing the system to prepare the appropriate communication path for content data delivery. By assessing RCS support capability beforehand, the system avoids time-consuming network queries during the call ringing phase, thus resolving the contradiction between providing caller information and maintaining fast call setup.

Inventive Principle:
Principle #10Preliminary action

2Loss of information

If an application is installed in the user equipment to perform queries to network nodes, then information on callers can be retrieved, but the user equipment may restrict giving the MSISDN of the caller to the installed application, thus the application not being able to identify the caller MSISDN

Engineering Contradiction:
Improvecaller identificationVSAvoidapplication installation and permission management
Core Design Contradiction:
Loss of informationVSDevice complexity

Solution Approach 1:

The patent introduces an intermediary approach by using the RCS communication framework as a mediator between the caller and callee. Instead of requiring a separate application with special permissions to query network elements, the RCS framework itself provides the capability discovery and information delivery mechanisms. The framework acts as an trusted intermediary that can access and share caller information (including MSISDN) with the callee's equipment without requiring the callee to install additional applications or grant special permissions, thus resolving the contradiction between caller identification capability and device complexity.

Inventive Principle:
Principle #24Intermediary (Mediator)

3Loss of information

If both parties support the RCS environment, then information can be provided during call setup using the call composer procedure, but the provision of information is not possible if one party does not support RCS

Engineering Contradiction:
Improvecaller information deliveryVSAvoidcompatibility with different communication frameworks
Core Design Contradiction:
Loss of informationVSAdaptability or versatility

Solution Approach 1:

The patent applies parameter changes by dynamically adjusting the communication method based on the callee's RCS capability parameter. The system first determines whether the callee supports RCS communication framework, and then changes the information delivery parameter accordingly: if RCS is supported, content data is delivered through the RCS call composer procedure; if RCS is not supported, alternative information delivery methods are used. This parameter-based adaptation resolves the contradiction between information delivery capability and framework compatibility, allowing the system to work with both RCS-supported and non-RCS devices.

Inventive Principle:
Principle #35Parameter changes

Data Source

PatentEP3367631B1Provision of content data to callee
Publication Date: 2020.05.20 TELIASONERA AB
  • EP3367631B1 patent drawingFigure 1~2
  • EP3367631B1 patent drawingFigure 3
  • EP3367631B1 patent drawingFigure 4~5

AI summary

A solution according to the invention relates to a method for determining a communication channel for providing content data in a context of call setup from a subscriber A (110) to a subscriber B (120). In the method a capability of the subscriber B (120) to support a specific communication framework is determined and in response to a detection that the subscriber B (120) supports the predetermined communication framework triggering a transmission of the content data over the specific communication framework (340). Otherwise, the content data is transmitted to the subscriber B (120) over a communication network into which the subscriber B (120) is connected to (350). The invention also relates to a user equipment, a computer program product and a system.