BRPI0419223B1 - "method for enabling first and second terminals of a communication network, and method for enabling use of at least one combinatorial service on at least one first terminal of a first user of a communication network" - Google Patents

Abstract

method for enabling use of at least one combinatorial service on at least one first terminal of a first user of a communication network, software application, terminal adapted for use on a mobile communication network, method for enabling a first and second terminals of a communication network using a combinatorial service, software program, communication network, and combinatorial service enjoyable by at least a first terminal of a first user of a communication network a combinatorial service is made enjoyable at the a user of a communication network in a simplified way. If a user establishes a call in the circuit domain and at his terminal, menu options are made available related to the enjoyment of the combinatorial service as a result of establishing such a call in the circuit domain.

Description

(54) Title: METHOD FOR ENABLING A FIRST AND SECOND TERMINALS OF A COMMUNICATION NETWORK, AND METHOD FOR ENABLING THE USE OF AT LEAST ONE COMBINATION SERVICE AT LEAST ONE FIRST TERMINAL OF A FIRST USER OF A COMMUNICATION NETWORK (51 ) Int.CI .: H04W76 / 14; H04W 76/15 (73) Holder (s): TELECOM ITALIA S.P.A.

(72) Inventor (s): GIANNI GUGLIELMI; ANDRÉA DE MARTIN; BRUNO BOTTIERO; FRANCESCO BAIETTO; LUCA BOSONETTO; DARIO SESTITO; GIORGIO CASTELLI; SÉRGIO COLLESEI / 44 “METHOD FOR ENABLING A FIRST AND SECOND TERMINALS OF A COMMUNICATION NETWORK, AND, METHOD FOR ENABLING THE USE OF AT LEAST ONE COMBINATION SERVICE AT LEAST ONE FIRST TERMINATION OF A FIRST USER OF A COMMUNICATION NETWORK”

Field of the Invention

The present invention relates in general to the field of communication networks, and in particular to mobile communication networks. The present invention relates more particularly to the enjoyment of combinatorial services by users of communication networks, particularly mobile communication networks.

Background of the Invention

Mobile phone networks were initially designed to allow voice communications, in a similar way to Public Switched Telephone Networks, PSTNs for short, but between mobile users. Mobile telephone networks have experienced and are experiencing a huge expansion, especially after the introduction of second generation mobile networks, and particularly digital mobile networks, such as those conforming to the GSM (Global System for Mobile Communications) standard, and corresponding systems adopted in the United States and Japan.

Similar to PSTNs, second generation mobile networks are circuit switched networks; this greatly limits the bandwidth that can be allocated to a given user, especially on second generation mobile networks. On the contrary, data communication networks such as computer networks and, among them, the Internet, adopt packet switched schemes, which allow for much higher data transfer rates.

Some solutions have been proposed to overcome the limitations

Petition 870180034773, of 04/27/2018, p. 11/59 / 44 of mobile networks switched by traditional circuits such as GSM networks, thus allowing users of mobile terminals to efficiently exploit the services offered by the Internet. One of the solutions that is gaining significant popularity is GPRS (General Packet Radio Service). GPRS is a digital mobile telephony technology compatible with GSM networks (in fact, it is built on the existing GSM network architecture) that allows data transfer at a higher speed than that allowed by pure GSM. Essentially, GPRS can be seen as a complement to GSM, which supports and enables packet data communication. Although third generation wireless communication systems such as those conforming to the standard UMTS (Universal Mobile Telecommunication System) are more promising in terms of data transfer speed, GPRS is an affordable solution to improve data exchange capabilities data on existing GSM networks.

The services offered by these mobile networks in addition to simple voice communications have rapidly increased in number and quality; just to name a few examples, in the past few years, short message services (Short Message System, SMS for short) and multimedia messaging services (Multimedia Message System, or MMS), and Internet connectivity services have been made available.

In particular, there is a strong interest in providing multimedia services to users of mobile communication networks, that is, services thanks to which it is possible to add images, video, data access over the Internet or by electronic mail, for communication between users that is made up of voice only. Among these services, the so-called combinatorial services are attracting great attention from mobile operators. For the purposes of the present description, by combinatorial service, in general, a service is intended for which a terminal of a communication network (not necessarily mobile) can open and use

Petition 870180034773, of 04/27/2018, p. 12/59 / 44 simultaneously two connections, typically a circuit connection (circuit switched or CS) and a packet connection (packet switched, PS).

U. Olsson and M. Nilsson, in the article Combinational services The pragmatic first step toward all-IP, Ericsson N ° 2, 2003, describe, inter alia, an example of so-called combinatorial services, in which the ability to simultaneously control traffic in a circuit connection and a packet connection is used: sharing images during a conversation. The authors note that the possibility of simultaneously operating traffic on a circuit connection and on a packet connection is allowed both with WCDMA (Broadband Code Division Multiple Access), giving the possibility to use multiple and parallel carriers on the interface through donates air (multiple Radio Access Carriers, multi-RAB), and with GSM, in which a standardized mechanism - Dual Transfer Mode, or DTM - produces similar possibilities. In the article, the authors note, however, that the mere technical possibility of successfully crossing the air is not enough. It is sometimes overlooked that the average end user is not interested in the complications of channel coding and wave propagation. Instead, the end user wants a mobile terminal that is reliable, simple to use, and well adapted to the current context. In other words, some entity on the mobile terminal has to interpret what the user is trying to do and translate it into a sequence of operations. An example described in the article relates to a woman and her husband during a conversation about an extraordinary garden exhibition. During the conversation, the woman decides to show her husband what she is describing. Ideally, the user interface (Human Machine Interface or MMI) should be simple enough, so that it only needs to press the key to turn on the video camera. The mobile terminal should contain enough intelligence to discover how

Petition 870180034773, of 04/27/2018, p. 13/59

4/44 locate the other party for the call over a packet connection and send the images. According to the authors, in order to allow this to happen, the following basic blocks are necessary:

- a coordination function on the mobile terminal (at least, an extended address book with information related to the reach of all relevant networks);

- a reachability mechanism on the packet connection part. According to the authors, the long-term solution is likely to be based on IMS (IP Multimedia Subsystem), using a SIP (Session Initiation Protocol) session protocol to find the other participant and negotiate the session parameters;

- a mechanism for distributing information capacity that allows applications based on terminals and the network to make intelligent use of information related to subscription, session state, bearer states, user preferences and so on. In this respect, the authors suggest, among other things, SIP, the use of the HTTP protocol and XML Web services.

Another description of a service enjoyed by mobile terminals is given in the Document Video sharing - Enrich your voice call with video, by Nokia Corporation, publicly available for download on the Internet site:

http://www.nokra.com/BaseProject/Sites/NOKIA MAIN 18022 / CDA / Categories / Phones / Technologies / VideoSharing / Content / Static Files / video_sharing_a4_2510.pdf

The real-time video sharing service allows users, during a phone conversation, to easily enrich their communication. One or the other of the users can share a live video taken by a video camera or video clips from the terminal. Both users see the same video and can discuss it

Petition 870180034773, of 04/27/2018, p. 14/59 / 44 while they are continuing their voice call. In an example described in the Document, Keith and Malcom are on a regular call over a circuit connection (CS) and Keith wants to share live video with Malcom. They have devices capable of video sharing and are registered for the service. The following flow is described in the Document:

- During the ongoing CS voice call, Keith chooses to share the live video.

- Keith confirms Malcom as a receiver.

- Malcom receives Keith's video request and accepts it.

- The system shows acceptance to Keith, who activates the sending of the video stream.

- Malcom's device starts showing the same video as Keith's device. They can discuss this by voice call.

- Keith finishes the video sharing when he showed what he wanted. The voice call between Keith and Malcom remains active.

The technology used by the video sharing service described in the Document mentioned above is the general SIP or IMS infrastructure.

In another document, entitled Document; IP Convergence Based on SIP: Enhanced Person-to-Person Communications, made publicly available by Nokia Forum for download on the Internet site http://www.forum.nokia.com/main/1.040,00.html?fsrParam=2- 3- /main.html&filelD=5336 the use of the SIP protocol is described to establish the type of peer-to-peer connections between terminals capable of supporting the IP protocol. As described in the Document, in order to communicate, IP-based applications must have a mechanism to achieve the corresponding. Today, fixed and mobile telephone networks perform this critical task of establishing a

Petition 870180034773, of 04/27/2018, p. 15/59 / 44 connection. By dialing the other user's phone number, the network can establish an ad-hoc connection between any two terminals. This critical connectivity capability does not yet exist widely on the Internet. According to this Document, SIP-based session management, complemented by other critical mobile network capabilities (ie, authentication, relocation and network interconnection provided by the IMS standard) provides the required structure. With the implementation of such a system, it is possible to establish an IP connection between two terminals. Once the connection is established, it can be used to exchange all types of media (voice, video, content, etc.). Like HTTP, SIP is a text-based client-server protocol. SIP was designed to establish, modify and terminate multimedia sessions or calls, and differs from HTTP in that a SIP terminal (or User Agent, UA) can act as both a client and a server. Therefore, it is possible to establish a customer-to-customer communication. Version 6 of the IP protocol (IPv6) provides, in accordance with this Document, a robust basis for SIP-based services. The most important benefit of IPv6 is the large address space. In reality, a problem also highlighted in this document is that version 4 of the IP protocol (IPv4) and that this protocol was designed for a smaller number of Internet hosts, compared to what the Internet is experiencing today. The problem of address space will become even greater when hundreds of millions (or billions) of cell phones are connected to the Internet. Among the possible applications of the SIP protocol described in this Document, the real-time video sharing service is mentioned.

Summary of the Invention

The Applicant notes that the solutions proposed above for the implementation of combinatorial services, based on the SIPIMS infrastructure, are not without problems.

Petition 870180034773, of 04/27/2018, p. 16/59 / 44

A first problem noted by the Applicant is the fact that the SIP-IMS infrastructure requires a large number of IP addresses available to the network operator, since every SIP terminal consumes an IP address, typically for the entire time during which remains connected. In the future, this problem will be solved with the widespread use of IPv6, instead of the currently used IPv4: the Claimant thinks, however, that it is desirable to implement combinatorial services that can be enjoyed by a high number of users also by IPv4 addresses, in such a way. to make such services available in a short time.

A second problem noted by the Applicant is the fact that the use of such services can be complicated for the average end user, who typically simply uses his own terminal to make phone calls, or send SMS (Short Message Service) messages. In particular, the Applicant notes that combinatorial services of the type of video sharing or image sharing, in which two users of a communication network can exchange still images or video (clips recorded or taken in real time by an embedded video camera) during a call voice, can be quite complex to be used in case many interactions with its own terminals are required from users. For this reason, the enjoyment of combinatorial services, which gives different simultaneous communication possibilities to the user, should be made as simple and efficient as possible, thus to minimize requests for terminal configuration and complications of use. This would allow for a strong diffusion of combinatorial services.

A third problem noted by the Applicant is the fact that the use of the SIP-IMS structure, while on the one hand allows great versatility of use (particularly for users registered in different types of network, for example fixed-mobile), on the other hand requires search engines for registered users and messages

Petition 870180034773, of 04/27/2018, p. 17/59 / 44 proceeding for customers residing in the users' terminals, which may delay the enabling of the packet connection between two users already involved in a circuit call, that is, the enabling of the combinatorial service between the two users. The Applicant therefore believes that it may be convenient to simplify the messaging protocol necessary to enable connection in the packet domain, as well as to make such activation faster.

Regarding the second and third problems exposed above, the Applicant notes that in a combinatorial service in which two users have to be able to exchange video or images over a packet connection, in addition to chatting over a normal circuit connection, some information necessary to establish the connection in the packet domain can be derived by the communication network by the fact that a circuit connection is already established between the two. This allows to simplify the protocol needed to enable the packet connection, reducing the number of signaling messages and the interactions of users with their own terminals.

In a first aspect, the invention relates to a combinatorial service that is made enjoyable at a user's terminal in a simplified way. The user establishes a call in the circuit domain and menu options in his terminal are available related to the enjoyment of the combinatorial service as a result of the establishment of such a call.

In a second aspect, the invention relates to a method for enabling the use of at least one combinatorial service in at least one first terminal of a first user of a communication network. The method includes establishing a first connection in a circuit domain of said communication network, from said first terminal to a second terminal of a second user of said communication network; receiving, in said first terminal, an acknowledgment of the establishment of said first connection; and the automatic establishment of a second connection

Petition 870180034773, of 04/27/2018, p. 18/59 / 44 of said first terminal for a packet domain of said communication network, as a result of receiving said recognition.

In a third aspect, the invention relates to an application adapted to be installed in a first terminal of a first user of a communication network, to enable the use of at least one combinatorial service in said first terminal. The application includes portions of software code adapted to receive recognition related to the establishment of a first connection in a circuit domain of said communication network of said first terminal to a second terminal of a second user of said communication network, and to establish automatically a second connection from said first terminal to a packet domain of said communication network, as a result of receiving said recognition.

In a fourth aspect, the invention relates to a terminal adapted for use in a mobile communication network. The mobile terminal, for example a cell phone, includes modules adapted to receive an acknowledgment related to the establishment of a first connection in a circuit domain of said communication network of said first terminal to a second terminal of a second user of said network of communication, and automatically establish a second connection of said first terminal to a packet domain of said communication network, as a result of receiving said recognition.

In a fifth aspect, the invention relates to a method for enabling a first and a second terminal of a communication network to use a combinatorial service. Said first and said second terminals are connected to each other by a first connection established in a circuit domain of said communication network, and they have respectively associated a first and a second identifier in said circuit domain of said communication network. Furthermore, said

Petition 870180034773, of 04/27/2018, p. 19/59 / 44 first and said second terminals have respectively a first and a second address in a packet domain of said communication network. The method includes, in a first device included in said packet domain of said communication network:

- receiving a first request for said first terminal, said first request including said first address and said second identifier;

- associating said first address with said first identifier of said first terminal;

- receiving a second request from said second terminal, said second request including said second address and said first identifier;

- associating said second address with said second identifier of said second terminal;

- enabling the establishment of a second connection in said packet domain of said communication network between said first and said second terminals based on said association between said first address and said first identifier and said association between said second address and said second identifier.

In a sixth aspect, the invention relates to a software program adapted to be installed on a first device included in a packet domain of a communication network, to enable a first and a second terminal of said communication network to be used. of a combinatorial service, in which said first and said second terminals are connected to each other by a first connection established in a circuit domain of said communication network. Said first and said second terminals respectively have a first and a second identifier in said circuit domain of said communication network. Additionally, said first and said second terminals have respectively

Petition 870180034773, of 04/27/2018, p. 20/59 / 44 associated with a first and a second address in said packet domain of said communication network. The program includes portions of software code adapted to:

- receiving a first request for said first terminal, said first request including said first address and said second identifier;

- associating said first address with said first identifier of said first terminal;

- receiving a second request from said second terminal, said second request including said second address and said first identifier;

- associating said second address with said second identifier of said second terminal;

- enabling the establishment of a second connection in said packet domain of said communication network between said first and said second terminals based on said association between said first address and said first identifier and said association between said second address and said second identifier.

In a seventh aspect, the invention relates to a method for enabling a first and a second terminal of a communication network to use a combinatorial service. The method includes:

- establishing a first connection in a circuit domain of said communication network between said first terminal and said second terminal;

- receiving, in said first and said second terminals, an acknowledgment of the establishment of said first connection;

- automatically connecting said first and said second terminals to a packet domain of said communication network, as a result of receiving said recognition;

Petition 870180034773, of 04/27/2018, p. 21/59 / 44

- assigning said first and second terminals a first and, respectively, a second address in said packet domain of said communication network, said first and said second addresses being respectively associated with a first and a second identifier of said first and said second terminals in said circuit domain of said communication network;

- automatically sending a first request from said first terminal to an apparatus included in said packet domain of said communication network, said first request including said first address and said second identifier, as a result of receiving said first address;

- automatically sending a second request from said second terminal to said device, said second request including said second address and said first identifier, as a result of receiving said second address;

- enabling the establishment of a second connection in said packet domain of said communication network between said first and said second terminals, based on a first association between said first identifier and said first address and a second association between said second identifier and said second address, said first and said second associations being executed by said apparatus as a result of receiving said first and said second requests.

Brief Description of Drawings

Figure 1 shows, by way of example, a mobile communication network capable of supporting a combinatorial service;

Figure 2 shows in a schematic way the enjoyment of a combinatorial service by two users of a mobile communication network;

Figure 3 shows schematically and in terms of function blocks an example of a mobile terminal capable of using a service

Petition 870180034773, of 04/27/2018, p. 22/59 / 44 combinatory;

Figure 4 shows, in an extremely simplified way, an architecture to enjoy a combinatorial service of the type of video sharing by two users of a mobile communication network;

Figure 5 shows in detail an example of an operation flow to enable two users of a mobile communication network to use a combinatorial service such as video sharing;

Figure 6a and Figure 6b show two possible procedures between two terminals in a pairwise connection, to avoid transmission collisions in the connection.

Detailed Description of the Invention

Figure 1 shows an example of a mobile communication network 20 capable of providing mobile telephone services according to the GSM / GPRS standard. It is observed that a mobile network capable of providing mobile telephone services according to the UMTS standard has a structure very similar to the mobile network shown in Figure 1. Mobile network 20 supports both communications over circuit connections, and communications over connections of package. To that end, the mobile network 20 includes a circuit network (or domain) portion 35 and a packet network (or domain) portion 51. Mobile terminals 12, 14 (for example, cell phones, PDAs or Personal Digital Assistants) , etc.) communicate on a radio interface with one or more radio base stations (BTS, Base Transmitter Station) 32. Every radio base station 32 provides mobile phone services in a corresponding geographic area 30 generally known under the name cell name. It is to be understood that the mobile network 20 provides services to several cells and to several mobile terminals much higher than those shown by way of example in Figure 1. Different radio base stations 32 are connected to a Base Station Controller (BSC) 34, which manages the

Petition 870180034773, of 04/27/2018, p. 23/59 / 44 allocation and deallocation of radio resources and controls the transfer of passages from mobile terminals on the move from one radio base station to another. A BSC and its associated radio base stations are typically referred to as a Base Station Subsystem (BSS). BSC 34 is connected to a Mobile Switching Center (MSC) 36 in circuit domain 35, by which circuit connections can also be established to other networks 38, such as for example PSTN or ISDN (Digital Services Network) Integrated). Typically, in mobile capillary networks, a plurality of BSCs such as BSC 34 shown in Figure 1, are connected to a single MSC.

The MSC 36 is also connected, via a signaling network 40 (for example, a signaling network according to Signaling System No. 7 or SS7), to a Home Location Register (HLR) 42, and to a Home Register. Visitor's Location (VLR) 44. VLR 44 includes a database containing information related to all mobile terminals immediately present in a corresponding geographical area, as well as containing temporary registration data for mobile telephone service subscribers, necessary for the MSC provide services in such a geographical area. HLR 42 includes a database that stores and manages the subscriptions of users of the mobile network 20, such as, for example, the users to which the mobile terminals 12, 14 belong. For every subscriber in this, the HLR contains permanent subscription data, such as the telephone number (ISDN or Mobile Station MSISDN), also known as the Client Line Identifier (CLI), which identifies the subscription of the mobile terminal in the numbering plan of the PSTN network and an international mobile subscriber identifier (IMSI), that is, a unique identifier at the international level allocated to every subscriber and used for signaling in the circuit domain of mobile networks. The HLR 42 additionally contains a list of services

Petition 870180034773, of 04/27/2018, p. 24/59 / 44 that a subscriber to a mobile network is authorized to use (in a so-called profile), and the address of the VLR that is immediately serving that subscriber.

Every BSC 34 is also connected to the packet domain, corresponding to the GPRS network 51 in Figure 1, to a Service GPRS Support Node (SGSN) 50, which is responsible for delivering the packages to the mobile terminals that are located in its service area. In mobile capillary networks, a plurality of BSCs are connected to a single SGSN. A Portal GPRS Support Node (GGSN) 54 acts as a logical interface for external packet networks, such as for example the IP network 56 (for example, the Internet). The SGSN 50 and GGSN 54 nodes are typically connected to each other by an IP 52 spine.

The mobile communication network 20 of Figure 1 is therefore part of a wider communication network, which involves external circuit networks (exemplified by network 38), and external packet networks (exemplified by network 56). Users of the mobile communication network 20 can communicate with users belonging to the external network 38 over a circuit connection, as well as be connected to a website to their own e-mail server on the IP network 56 over a packet connection. . Additionally, users of the mobile communication network 20 can use at least one combinatorial service, that is, a service thanks to which a user, for example the user to which the mobile terminal 12 in Figure 2 belongs, can simultaneously open, from his mobile terminal 12 itself, a circuit connection and a packet connection for another user (from mobile network 20 or external network 38). The user can, for example, check one or more web pages from his mobile terminal 12, exploring the packet connection, and at the same time discuss the content of such pages with his own interlocutor exploring the circuit connection. In another example, the user can load the content of his own

Petition 870180034773, of 04/27/2018, p. 25/59 / 44 e-mail box, exploring the packet connection, and at the same time discussing the content of one or more e-mail messages received with your own interlocutor exploring the circuit connection. In another example, the user can send a series of still images or a video (a clip recorded or taken in real time by a built-in video camera) from his own mobile terminal 12 to his own interlocutor's terminal, exploring the packet connection, and at the same time commenting together with your own interlocutor the images that appear in both terminals. For the purposes of the present invention, it will be intended in the following that the term video is meant to include any type of image, both still and moving, taken in real time or recorded and stored in a memory area.

For example, with reference to Figure 2, a first user of the mobile network 20 to which the mobile terminal 12 belongs, places a call to a second user of the mobile network 20, to which the mobile terminal 14 belongs. The first mobile terminal 12 is served by a BTS 32 and the second mobile terminal 14 is served by a BTS 32 ', which may be the same as that serving the first mobile terminal 32 or a different one. A first C1 connection is established, upon acceptance of the call by the second user, to support voice communication between the first and second users. The connection C1 is typically established bidirectionally in the circuit domain 35 of the mobile network 20. A second connection C2 is established between the mobile terminal 12 and the mobile terminal 14, in the packet domain 51 of the mobile network 20, to allow the first and second users share any video during their phone conversation. The C2 connection can be established in a unidirectional or bidirectional way: higher bit rates can be achieved by connections of the unidirectional type. Known technologies can be exploited to allow mobile terminals 12, 14 to simultaneously keep both connections C1 and C2 active: for example,

Petition 870180034773, of 04/27/2018, p. 26/59 / 44 multi-RAB technologies already mentioned for third generation mobile terminals, and DTM technology for second generation mobile terminals.

Figure 3 shows, schematically and in terms of function blocks, an example of mobile terminal 12 capable of using a combinatorial service. Mobile terminal 12 includes an antenna 121 adapted for transmission / reception, a radio frequency transceiver 122, a GPRS module 123, an encoding / decoding unit 124, a speaker 125, a video camera 126, a microphone 127 , a screen 128, a keyboard 129, a processor (or CPU, Central Processing Unit) 130 with a memory 131 associated with it. Mobile terminal 12 is typically associated with a SIM (Subscriber Identity Module), not shown in Figure 3, by suitable electrical contacts.

Antenna 121 and radio frequency transceiver 122 conventionally allow communication to and from mobile network radio base stations. Loudspeaker 125 and microphone 127 conventionally transform an electrical signal corresponding to the voice into an audible signal by a user of mobile terminal 12, and vice versa. The keyboard 129 conventionally allows the user to manually interact with the handset, send related commands, for example, choosing a menu option, or selecting a phone number, etc. Screen 128 can be, for example, a liquid crystal display (LCD, Liquid Crystal Display), and is conventionally adapted to display a video. The video camera 126, for example a CCD (Load-Coupled Device) camera, is conventionally adapted to capture video. The GPRS 123 module conventionally includes a packaging / unpacking device and a temporary memory, and is capable of encapsulating radio blocks from the mobile network in packages, or unpacking the packages provided by the upper protocol layers into radio blocks, for transmission to the mobile network, via radio frequency transceiver 122 and antenna 121. The

Petition 870180034773, of 04/27/2018, p. 27/59 / 44 encoding / decoding unit 124 (for example, an H.263 video codec) is connected to speaker 125, microphone 127, display 128 and video camera 126: conventionally manages encoding / decoding the video captured by the video camera 126 or to be displayed on the screen 128, and / or the audio component captured by the microphone 127 or to be transmitted to the speaker 125. Processor 130 supervises the operation and activities of the different modules included in mobile terminal 12. Memory 131, in combination with processor 130, includes software applications to manage communication. In particular, according to one aspect of the present invention, memory 131 includes application software for the control and administration of at least one combinatorial service. It is further observed that although in Figure 3 the encoding / decoding unit 124 is shown as a separate entity, it can also be performed by means of a software program resident in the memory 131 of the mobile terminal 12.

As mentioned above, in accordance with an aspect of the present invention, on a user's mobile terminal enabled to use a combinatorial service, a software application is installed for the control and administration of the combinatorial service. Such a software application can be implemented as a separate client application, which can be installed on the mobile terminal's operating system, or wired into the mobile terminal's firmware. In particular, the software application includes modules configured to control the establishment of connections from the mobile terminal to the circuit domain and to the package domain. The software application can be started automatically when starting a mobile terminal. However, it can be provided that the user can disable the automatic start of the application, or that the application is run manually by the user. Preferably, the software application operates in the background to be practically invisible to the user during normal use of the mobile terminal.

Petition 870180034773, of 04/27/2018, p. 28/59 / 44

Once running, the software application is able to recognize event signals related to calls made to and / or to the mobile terminal. In particular, the application is able to recognize at least:

- a signaling related to an incoming call established in the circuit domain; and / or

- a signal related to an established outgoing call made in the circuit domain; and / or

- a signal related to the interruption of a call in progress in the circuit domain, executed locally; and / or

- a signal related to the interruption of an ongoing call in the circuit domain, executed remotely.

It is noted that the last two cases listed above also include the possibility that the call is terminated in the event that the mobile terminal (or a remote mobile terminal) happens to be out of radio coverage during the call. In addition, it is noted that the cases listed above are not an exhaustive list of possible events that the software application can recognize.

In the event that the user to which the mobile terminal belongs wants to make a call to another user (belonging to the same mobile network or to a different, fixed or mobile network), the software application does not intervene during the conventional selection of the telephone number of the user to call (typically executed from the keyboard or selected from a phone directory stored on the mobile terminal, or on the SIM associated with it). The calling user can start the call to his / her own party in a completely conventional way, typically by pressing an appropriate key on the handset keypad. The call is routed conventionally in the circuit domain.

In the response of the called user, in the circuit domain of the

Petition 870180034773, of 04/27/2018, p. 29/59 / 44 communication network, a connection is established between the calling user's mobile terminal and the called user's terminal. When establishing such a connection, an acknowledgment is sent to the calling user's mobile terminal, which enables the calling user to use the newly established connection to communicate with his own interlocutor. The software application intercepts such recognition signals and automatically initiates (that is, without user interaction with the terminal) a connection procedure in the packet domain of the mobile network. Typically, the procedure provides a connection to an access point (APN, Access Point Name) in the packet domain. The connection procedure provides that the GGSN 54 signals the APN, typically through the RADIUS protocol, the telephone number of the terminal requesting the connection. The APN associates the phone number with a unique address in the packet domain (typically an IP address), after verifying its credentials, and communicates it to GGSN 54, which in turn refers the same to the terminal that requested the connection. The APN also maintains the association between the mobile terminal phone number (or the mobile terminal identifier in the circuit domain) and the designated IP address (or mobile terminal address in the packet domain), in a database appropriate. This association can also be communicated to other devices on the network, such as for example a WAP Portal. The connection to the packet domain is typically completed by opening a PDP context from the mobile terminal to an SGSN and a GGSN from the GPRS network core of the mobile network.

Since the packet connection has also been established, the calling user has available the circuit connection to communicate conventionally by voice with his own interlocutor, and a packet connection to simultaneously access data services. In other words, the calling user is enabled to use at least one combinatorial service. For example, the calling user can check from their

Petition 870180034773, of 04/27/2018, p. 30/59 / 44 mobile terminal one or more web pages, exploring the packet connection, and at the same time he can discuss the content of such pages with his own interlocutor exploring the circuit connection. In another example, the user can load the contents of his own electronic mailbox on his mobile terminal, exploring the packet connection, and at the same time he can discuss the contents of one or more of the received electronic messages with his own interlocutor, exploring the circuit connection. If the called user's terminal is also connected to the packet network (or typically has an IP address), a peer-to-peer connection between the terminals of the two users can be established in the packet domain, to allow the calling user to send / receive video calls to / from the called user, and at the same time he can comment together with his own interlocutor the images that appear on both terminals. To establish a peer-to-peer connection, the terminals of the two users exchange their own addresses in the packet domain (typically their IP addresses). In order to perform such an exchange, the software application running on the terminal of at least one of the two users is capable, for example, of commanding the delivery of a message addressed to the remote user's terminal, containing his IP address. Such message can be, for example, a type of SMS message (Short Message Service) or USSD (Unstructured Complementary Service Data). A preferred mechanism for establishing the peer connection will be presented subsequently in the present description.

In order to make the service enjoyable, after the packet connection is established, the software application typically makes one or more menu options available on the terminal for the use of the private data services available through the packet connection. Typically, such menu options can be made activable by the software application using appropriate keys (or softkeys) on the keyboard. For example, in

Petition 870180034773, of 04/27/2018, p. 31/59 / 44 In case of simple web browsing or mail loading, the related menu option can be made available on receipt of the IP address coming from the APN. In the case of video sharing with the remote user, it may be convenient to activate the related menu option after receiving an acknowledgment, for example coming from the remote user, establishing the peer-to-peer connection, and / or the user's ability use the combinatorial service. Among the menu options made available for a combinatorial video sharing service, there may be, for example, an option to start delivering video, and / or an option to stop delivering video, and / or a pause option video (or image freeze). In particular, in the case of an image freeze and / or interruption of video delivery, it may be convenient to make the last image (or frame) taken by the video camera and encoded by the encoding unit in the instant preceding the interruption of the video capture available on the terminal of the two users. In fact, such a last image may result in better quality at the terminal receiving the video, compared to the overall quality of the transmitted video: this depends on the fact that the encoding of a still image is more efficient, since substantially no interpolation in the frames is performed to derive any subsequent frame (since the image in practice is always the same).

The procedure for enabling the use of the combinatorial service, described above with reference to the execution of a user's call, can be applied, with few changes, also in the case that the user receives an incoming call in his own terminal. In this case, the connection activation procedure in the packet domain can be activated by signaling the call establishment coming from the network, which is communicated after the user accepts the external call, typically by pressing a suitable key on the terminal keyboard.

Petition 870180034773, of 04/27/2018, p. 32/59 / 44

When the calling user or the called user decides to end the voice call in the circuit domain, one of the two users ends the call, typically by pressing an appropriate key on their own terminal. The connection in the circuit domain is thus interrupted. Preferably, upon receiving acknowledgment of the connection drop in the circuit domain, the software application residing on the user's mobile terminal enabled to the combinatorial service automatically commands the connection drop in the packet domain. In addition, menu options related to combinatorial services are disabled by the software application. The same procedure can also be applied in case of termination of the call in the circuit domain due to lack of radio coverage (in the case of use of mobile terminals). The mobile terminal therefore returns to its normal waiting state, ready to receive or execute calls (and with the software application managing to enable the use of combinatorial services running in the background).

The procedure described above for establishing the two connections, circuit and package, and enabling the use of combinatorial services, has several advantages. First, such enabling takes place in a completely transparent way to the user, who in practice makes or accepts a call in the circuit domain in a totally conventional way, finding his own terminal also configured for the use of the packet connection when the call is made. successfully established. In addition, the fact that the packet connection is only open in practice during the voice call, allows potentially making combinatorial services available to a high number of users, without the need to explore a packet network in which the IPv6 protocol is implemented, and without the need, from the point of view of a network operator, to have available groups of IP addresses of significant size, in the case that addresses according to the IPv4 protocol are used. In reality, addresses in the packet domain are only

Petition 870180034773, of 04/27/2018, p. 33/59 / 44 assigned after the voice call has been established, and they are preferably released at the end of the same call.

In addition to avoid wasting IP addresses, the software application managing the combinatorial service can be configured in such a way that it does not activate the connection procedure to the packet network in some particular cases of circuit calls. For example, in the case that the application software only enables the use of a combinatorial service in which two users can exchange some video, the connection to the packet network procedure can be disabled in the case of calls made to or received by private numbers: for example, during calls to toll-free numbers, or during calls to numbers corresponding to information services and / or telephone answering services, or during calls to and from foreign numbers (in the event that such a service is not made available during communication with distant resident users), or during calls to and from users belonging to networks of other operators or using different technologies (or for mixed calls from fixed to mobile or vice versa), etc. The configuration of the software application to exclude the opening of the package connection in these particular cases can be updated by typical airborne operations. Additionally, especially in the case that video delivery to a mobile terminal is made available within a combinatorial service, it may prove convenient not to activate the connection procedure to the packet network in the event that the quality or the strength of the radio signal is below certain critical threshold. The same consideration also remains in the case that the service is made available only on third generation networks (3G, for example UMTS), and there is not enough 3G coverage (however, coverage is guaranteed by a second generation network, for example GSM / GPRS, to make normal voice calls).

In the following description, by way of example, a

Petition 870180034773, of 04/27/2018, p. 34/59 / 44 preferred embodiment of a combinatorial service between two users User_A, User_B of a mobile communication network will be presented in detail, in accordance with an aspect of the present invention. Users User_A and User_B are provided with a mobile terminal UE_A and UE_B, respectively. The combinatorial service is, for example, a See What I See (SWIS) or video sharing service, that is, a service in which User_A and User_B can exchange video taken by a video camera embedded in their own mobile terminals UE_A and UE_B by a type of peer-to-peer connection in the packet domain, during a normal telephone conversation established in the circuit domain. The service is made possible and administered by a device included in the packet domain of the mobile communication network, denoted by SWIS in Figure 4 (hereinafter, SWIS server), connected to an APN to access the packet domain of the communication network mobile, with which the mobile terminals UE_A and UE_B are able to communicate. Figure 4 shows a very general outline of the architecture described above.

Figure 5 shows the flow of the different operations performed, in this example, to enable users User_A and User_B to use the service. When energizing the terminals UE_A and UE_B (501, 502), users User_A and User_B are registered on the mobile communication network. In addition to such a registration, the terminals UE_A and UE_B activate, preferably in automatic mode, a software application (then SWIS application) that manages the enabling of the use, as well as the use itself, of the combinatorial service of See what I see. The SWIS application is preferably loaded in the background on terminals UE_A and UE_B, in such a way that the administration of the SWIS service takes place in a transparent way for users User_A and User_B.

At a certain point, user User_A calls user User_B (503). The call can be started by user User_A according to

Petition 870180034773, of 04/27/2018, p. 35/59 / 44 with any typical modality, for example the insertion, by the keyboard of the UE_A terminal, of the telephone number of the User_B user or the search for such number in a telephone directory stored in the UE_A terminal or on the SIM associated with it. The User_A user, typically pressing a suitable key on the keyboard of his own UE_A terminal, starts the call to the User_B user. The call is routed through the MSC MSC_A, under which the UE_A terminal is registered, to the MSC MSC_B, under which the UE_B terminal is registered, and from there to the UE_B terminal. A notification (504) of the incoming call is sent to the terminal UE_B: typically, a message corresponds to such notification, shown on the display of the terminal UE_B of the user called User_B, with the indication of the telephone number of the terminal of the calling user User_A. The User_B user accepts the call (505), typically by pressing a suitable key on the keyboard of his own UE_B terminal. Acceptance of the call by user User_B is notified to terminal UE_A of user User_A (506) and the call between terminal UE_A and terminal UE_B is thus established. The two users User_A and User_B can thus talk to each other over the connection established in the circuit domain of the mobile communication network. The call establishment was outlined in Figure 5 by a thick gray line between MSCs MSC_A, MSC_B.

Upon receipt of the notification (506) of the acceptance of the call by the User_B user, the SWIS application running on the UE_A terminal of the User_A user automatically activates (that is, without interaction with the User_A user on the UE_A terminal) a connection (507) to the packet domain of the mobile communication network, simultaneously with the connection activated in the circuit domain. Typically, the connection to the packet domain requires a connection to an APN access point (for example, a RADIUS server), where the user_A user's credentials (ie, their entitlement to packet services) are verified. If the User_A user is entitled to

Petition 870180034773, of 04/27/2018, p. 36/59 / 44 packet services, a unique IP_addA address on the packet network is dynamically assigned to its UE_A terminal, typically an IP address. At the access point, an association is typically maintained between the CLI_A phone number of the User_A user terminal (or another identifier of the User_A user UE_A terminal in the circuit domain) and the IP_addA IP address assigned to the UE_A terminal (or other identifier) UE_A terminal of user User_A in the package domain). Such association can also be maintained on other devices included in the packet domain of the mobile communication network. Through the packet connection, the UE_A terminal of the User_A user can access the PS packet network core of the mobile communication network and the services made available by it. In a GPRS or UMTS network, this corresponds to opening a PDP context from the UE_A terminal to the packet network PS core.

Similarly, upon accepting the call from the User_B user, the SWIS application running on the User_B user UE_B terminal automatically activates (that is, without interaction with the User_B user on the UE_B terminal) a connection (508) to the domain of packet of the mobile communication network, simultaneously with the connection activated in the circuit domain. Typically, the connection to the packet domain asks for a connection to an APN access point (for example a RADIUS server), where the User_B user's credentials (or their entitlement to the packet services) are verified. The APN access point to which the UE_B Terminal is connected can be the same as the access point to which the UE_A Terminal is connected, or a different access point. If the User_B user is entitled to packet services, a unique IP_addB address is dynamically assigned on the packet network to his UE_B terminal, typically an IP address. At the access point, an association is typically maintained between the User_B user's CLI_B phone number (or another user_B user's UE_B terminal identifier in the circuit domain) and the

Petition 870180034773, of 04/27/2018, p. 37/59 / 44

IP IP_addB assigned to the UE_B terminal (or other identifier of the UE_B terminal of the User_B user in the packet domain). Such association can also be maintained on other devices included in the packet domain of the mobile communication network. Through the packet connection, the UE_B terminal of the User_B user can access the packet PS core of the mobile communication network and the services made available by it. In a GPRS or UMTS network, this corresponds to opening a PDP context from the UE_B terminal to the packet network PS core.

After receiving the IP_addA address, the SWIS application running on the UE_A terminal of user User_A activates the delivery of a registration request (509) to the SWIS server. Order activation takes place automatically, so as to be transparent to the User_A user. With request (509), the UE_A terminal signals the SWIS server its presence in the packet domain of the mobile network. Advantageously, in the registration application (509), the UE_A terminal may also require the enabling of a connection to the UE_B terminal, through the packet domain of the mobile communication network, simultaneous to that already established in the circuit domain. For this purpose, the UE_A terminal must know the UE_B terminal address in the packet domain, that is, the IP_addB address. In a preferred implementation, the request sent by the UE_A terminal includes at least the address assigned to the UE_A terminal in the packet domain (typically, the IP address IP_addA) and the identifier of the UE_B terminal in the circuit domain (typically, the telephone number CLI_B of user User_B) with which user User_A is connected by the call already established in the circuit domain. In a preferred embodiment, the request sent by the UE_A terminal may include one or more TCP or UDP packets carrying the IP_addA address, on which the CLI_B identifier is carried. The SWIS server receives the request from the UE_A terminal, and stores the IP_addA address of the UE_A terminal in a memory area and

Petition 870180034773, of 04/27/2018, p. 38/59 / 44 the CLI_B identifier of user User_B. By interrogating (510) a suitable device included in the packet domain of the mobile communication network, for example the APN access point to which the terminal UE_A is connected (or a WAP Portal), the SWIS server obtains the identifier CLI_A the terminal UE_A in the circuit domain of the mobile communication network corresponding to the IP_addA address of the terminal UE_A in the packet domain of the mobile communication network. Such CLI_A identifier is also stored in a memory area by the SWIS server in association with the IP_addA address received by the request sent by the UE_A terminal.

Similarly, after receiving the IP_addB address, the SWIS application running on the UE_B terminal of user User_B activates the delivery of an order (512) to the SWIS server by enabling and administering the service. The activation of the order happens automatically, so as to be transparent to the User_B user. With request (512), the UE_B terminal signals the SWIS server its presence in the packet domain of the mobile network. Advantageously, in the registration request (512), the terminal UE_B may also require the enabling of a connection to the terminal UE_A, through the packet domain of the mobile communication network, simultaneous to that already established in the circuit domain. For this purpose, the UE_B terminal must know the UE_A terminal address in the packet domain, that is, the IP_addA address. In a preferred implementation, the request sent by the UE_B terminal includes at least the address assigned to the UE_B terminal in the packet domain (typically, the IP address IP_addB) and the identifier of the UE_A terminal in the circuit domain (typically, the telephone number CLI_A of user User_A) with which user User_B is connected by the call already established in the circuit domain. In a preferred embodiment, the request sent by the UE_B terminal can include one or more TCP or UDP packets carrying the IP_addB address on which the CLI_A identifier is carried. The SWIS server

Petition 870180034773, of 04/27/2018, p. 39/59 / 44 receives the request from the UE_B terminal, and stores in a memory area the IP_addB address of the UE_B terminal and the CLI_A identifier of the User_A user. By interrogating (513) a suitable device included in the packet domain of the mobile communication network, for example the access point to which the UE_B terminal is connected (or a WAP portal), the SWIS server acquires the CLI_B identifier from the terminal UE_B in the circuit domain of the mobile communication network corresponding to the IP_addB address of the terminal UE_B in the packet domain of the mobile communication network. Such CLI_B identifier is also stored in the memory area by the SWIS server in association with the IP_addB address received by the request sent by the UE_B terminal.

At this moment, the SWIS server has the following pieces of information available: the terminal having the IP_addA address, corresponding to the CLI_A identifier, asks to connect to the terminal having the CLI_B identifier; the terminal having the IP__addB address, corresponding to the CLI_B identifier, asks to connect to the terminal having the CLI_A identifier. From the matching of these pieces of information, which the SWIS server can store in appropriate records of a table, the SWIS server can recognize that terminals UE_A and UE_B are already connected in the circuit domain, and thus enable a peer-to-peer connection. parallel between the two terminals in the packet domain. Such enabling can happen by exchanging, between the UE_A and UE_B terminals, the IP_addA and IP_addB addresses in the packet domain.

The exchange of the IP_addA and IP_addB addresses between the UE_A and UE_B terminals can be triggered by the SWIS server, by inserting such addresses in the respective recognition signs of its previous registration request (509, 512), to be sent to a or both of the terminals UE_A, UE_B. In a preferred embodiment, the address of the interlocutor terminal in the packet domain is inserted into a signal

Petition 870180034773, of 04/27/2018, p. 40/59 / 44 of acknowledgment sent only to one terminal. Such acknowledgment can for example be sent to terminal UE_B (514), including the IP_addA address of terminal UE_A, while an empty acknowledgment (511) is sent to terminal UE_A. Upon receipt of acknowledgment (514), the SWIS application running on the UE_B terminal extracts the IP_addA address and stores it in a memory area of the UE_B terminal. Additionally, when extracting the IP_addA address from the UE_A terminal, the SWIS application running on the UE_B terminal responds with the automatic dispatch of a message (515) in the packet domain to the UE_A terminal, using the related IP_addA address just received, including your own IP_addB address: such a message can be a type of peer-to-peer message receptacle, performed by a TCP or UDP packet, which includes a predefined series of characters. The SWIS application running on the UE_A terminal extracts the IP_addB address of the UE_B terminal from this message, and stores it in a UE_A terminal memory area. In addition, upon receipt of the IP_addB address of the UE_B terminal, the SWIS application running on the UE_A terminal automatically activates, typically on the UE_A terminal display, a menu option that can be exploited by an appropriate key (or 'softkey') on the keyboard of the same terminal. , by which the User_A user can activate the video camera incorporated in his own UE_A terminal and send a video to the UE_B terminal, containing the images taken in real time by the video camera. In addition, the SWIS application running on the UE_A terminal automatically sends an acknowledgment to the UE_B terminal (516) for the receipt of the message (515) previously sent by the UE_B terminal. Upon receipt of such an acknowledgment (516), the SWIS application running on the UE_B terminal automatically activates, typically on the UE_B terminal display, a menu option exploitable by an appropriate key (or 'softkey') on the keyboard of the same terminal, by which the User_B user can activate the video camera embedded in its own terminal

Petition 870180034773, of 04/27/2018, p. 41/59 / 44

UE_B and send a video to the UE_A terminal, containing the images taken in real time by the video camera.

The UE_A and UE_B terminals of the two users User_A and User_B are currently fully enabled to use the SWIS service. Advantageously, the enabling of the two terminals UE_A and UE_B to the combinatorial service of SWIS does not involve any additional action by the users User_A and User_B at the terminals UE_A and UE_B, in addition to the normal telephone call action performed by the user User_A and the normal action of accepting such a call executed by the User_B user. Such an advantage is achieved in particular thanks to the fact that requests (509, 512) sent by terminals UE_A and UE_B to the SWIS server, to request the address in the packet domain of the interlocutor already connected in the circuit domain, are not sent by the SWIS server for the terminals themselves (ie, the request sent by the UE_A terminal is not sent to the UE_B terminal, and vice versa), but they are stopped at the SWIS server. This allows to avoid that an explicit acceptance is made necessary, by an action in the terminals UE_A and UE_B, of the connection also in packet network by the users User_A and User_B to enable the service and to send / receive the video. The activation of the menu options at the UE_A and UE_B terminals also takes place automatically, thanks to the reception of simple acknowledgment messages coming from the SWIS server. The lost shipment of orders sent by terminals UE_A and UE_B to the SWIS server and the use of acknowledgment messages as a trigger for procedures for activating menu options at terminals UE_A and EU_B allows to significantly reduce the number of signaling messages between terminals UE_A, UE_B and the SWIS server needed to enable the SWIS service. This advantageously allows the SWIS service to be made available to users User_A and User_B in an extremely short time.

Petition 870180034773, of 04/27/2018, p. 42/59 / 44

Referring again to Figure 5, in the case that the User_A user wants to start delivering a video to the User_B user, he presses the key (or 'softkey') corresponding to the menu option activated on the display of his own UE_A terminal. Optionally, the SWIS application running on the UE_A terminal automatically sends a Start Video notification (517) to the SWIS server, for example to allow the SWIS server to start a count of the time taken to deliver the video sent by the user UserA , for service charging purposes. In addition, the SWIS application running on the UE_A terminal modifies the menu option available on the UE_A terminal, in such a way as to make it correspond to an action to stop the transmission of the user_A video from the user (alternatively, disable the previous menu option. , and activates an additional video stop, which can be activated by a different key or 'softkey'). In addition, the SWIS application running on the UE_A terminal activates image capture from the video camera on the UE_A terminal, and the related encoding adapted to the transmission on the packet connection. Finally, the SWIS application running on the UE_A terminal sends the encoded images (518) to the UE_B terminal (possibly exploiting a temporary memory), over the enabled connection in the packet domain of the mobile communication network, using its IP_addB address. User_A can see the video he is sending to User_B on the display of his own UE_A terminal. Advantageously, at this stage, the SWIS server does not intervene in the communication between UE_A and UE_B. This allows to manage the SWIS service for a high number of users also with a device with a very limited processing capacity, since such device only has to manage simple signaling messages, not complex data flows. Upon receipt of the video (possibly executed by the UE_B terminal exploiting a temporary memory), the User_B user can see this on the display of his own UE_B terminal. The running SWIS application

Petition 870180034773, of 04/27/2018, p. 43/59 / 44 at the UE_B terminal preferably disables the video delivery menu option at the UE_B terminal, thus to avoid collisions in the connection established in the packet domain of the mobile communication network. When the User_A user decides to stop delivery of the video, he presses the key (or 'softkey') to stop video made recently available on the display of the UE_A terminal: the SWIS application running on the UE_A terminal stops capturing images from the video camera and transmitting the encoded images to the UE_B terminal. Optionally, the SWIS application running on the UE_A terminal automatically sends a Stop Video notification (519) to the SWIS server, for example to allow the SWIS server to stop counting the time taken to transmit the video sent by the user UserA , for service charging purposes.

Likewise, if the User_B user wants to start transmitting a video to the User_A user, he presses the key (or 'softkey') corresponding to the menu option activated on the display of his own UE_B terminal. Optionally, the SWIS application running on the UE_B terminal automatically sends a Start Video notification (520) to the SWIS server, for example to allow the SWIS server to start counting the time taken to transmit the video sent by the user UserB , for service charging purposes. Additionally, the SWIS application running on the UE_B terminal modifies the menu option available on the UE_B terminal, in such a way as to correspond to a stop action of the transmission of the user_B video of the user (alternatively, disables the previous menu option, and activates an additional video stop, which can be activated by a different key or 'softkey'). In addition, the SWIS application running on the UE_B terminal enables image capture by the video camera of the UE_B terminal, and the related encoding adapted to the transmission on the packet connection. Finally, the SWIS application running on the UE_B terminal sends the images

Petition 870180034773, of 04/27/2018, p. 44/59 / 44 coded (521) for the UE_A terminal (possibly exploiting a temporary memory), through the connection enabled in the packet domain of the mobile communication network using its IP_addA address. User_B can see the video he is sending to User_A on the display of his own UE_B terminal. Advantageously, at this stage, the SWIS server does not intervene in the communication between UE_B and UE_A. When receiving the video (possibly executed by the UE_A terminal using a temporary memory), the User_A user can see this on the display of his own UE_A terminal. The SWIS application running on the UE_A terminal preferably disables the video transmission menu option on the UE_A terminal, so as to avoid collisions in the connection established in the packet domain of the mobile network. When the User_B user decides to stop the video transmission, he presses the key (or 'softkey') to stop video made recently available on the display of the UE_B terminal: the SWIS application running on the UE_B terminal stops capturing images by the video camera and transmitting the encoded images to the UE_A terminal. Optionally, the SWIS application running on the UE_B terminal automatically sends a Stop Video notification (522) to the SWIS server, for example to allow the SWIS server to stop counting the time taken to transmit the video sent by the User_B user , for service charging purposes.

In the event that one of the two users, for example the user User_A, wants to end communication with the user UserB, he typically presses the appropriate key on the keyboard of his own UE_A terminal, thus notifying (523) the mobile communication network (in the domain circuit) your own intention to end the call. The SWIS application running on the UE_A terminal intercepts (524) such a notification and sends a finished service signal to the SWIS server (526). The UE_B terminal of the other User_B is notified (525) of the termination of the call

Petition 870180034773, of 04/27/2018, p. 45/59 / 44 in the circuit domain. The SWIS application running on the UE_B terminal intercepts such a notification and sends a finished service scan signal to the SWIS server (527). The SWIS server can respond to signals from terminals UE_A and UE_B with an acknowledgment (528, 529). Upon receipt of such recognition, the SWIS application running on terminals UE_A and UE_B can command the deactivation of connections from terminals UE_A and UE_B in the packet domain (530, 531), and the release of the IP_addA and IP_addB addresses. The termination of the call between terminals UE__A and UE_B in the circuit domain was indicated in Figure 5 by means of another thick gray line.

The previous description referred to a situation in which the terminals UE_A and UE_B were both capable of supporting the combinatorial service. In the event that a call is performed by a terminal (for example, UE_A) capable of supporting combinatorial service to a terminal not capable of supporting combinatorial service, the SWIS application running on terminal UE_A automatically activates the connection to the domain of packet, receives its own IP_addA address, and sends the registration request to the SWIS server.

Such a procedure can advantageously be disabled in the case that the call in progress is made for particular numbers, as already illustrated in the previous. In any case, if within a predetermined range (typically configurable), the UE_A terminal does not receive an IP address in an acknowledgment for your registration request or in a pair of receptacles, the SWIS application can automatically command the disconnection of the packet domain, thus to quickly release the wasted IP address uselessly. In the event that a call is received by a terminal (for example, UE_B) capable of supporting the combinatorial service, coming from a terminal not capable of supporting the combinatorial service, the SWIS application running on the UE_B terminal is active

Petition 870180034773, of 04/27/2018, p. 46/59 / 44 automatically connects to the packet domain, receives its own IP_addB address, and sends the registration request to the SWIS server. Such a procedure can advantageously be disabled in the event that the call in progress originates from particular numbers, as already illustrated in the previous. In any case, if within a predetermined range (typically configurable), the UE_B terminal does not receive an IP address in an acknowledgment of your registration request or in a pair of receptacles, the SWIS application can automatically command the disconnection of the packet domain, thus to quickly release the wasted IP address uselessly. Similar intervals can also be implemented to manage possible problems in establishing the packet connection. The duration of these intervals can be configured by the server using appropriate fields in the response message for the registration request or by typical operations over the air.

In a preferred version, it can be idealized that the terminals UE_A and UE_B exchange notification and acknowledgment messages to avoid situations of simultaneous video transmission from both terminals. For example, as shown in Figure 6a, after selecting the menu option related to the transmission of the user_A video from user_A on its own UE_A terminal, the SWIS application running on UE_A terminal automatically sends a notification message (indicated as INVITE in Figure 6a) for the UE_B terminal. Upon receipt of the notification message, the SWIS application running on the UE_B terminal establishes the reception of the video and automatically sends an acknowledgment message (indicated as ACK in Figure 6a) to the UE_A terminal. Upon receipt of the acknowledgment, the SWIS application running at the UE_A terminal begins to transmit the video.

In the case of simultaneous dispatch of notification messages from terminals UE_A and UE_B, as for example shown in

Petition 870180034773, of 04/27/2018, p. 47/59 / 44

Figure 6b, the implementation of a priority policy protocol can be devised. For example, such a policy may provide that the priority goes, in these cases, to the terminal that originated the call in the circuit domain. Other policies can be selected alternatively. In the example cited above, UE_A was the terminal that had originated the call in the circuit domain. As shown in Figure 6b, in the case that UE_B sent its own notification message simultaneously to UE_A, UE_B receives a notification message from UE_A instead of an acknowledgment of its own notification message. In such a case, the SWIS application running on the UE_B terminal, following the priority policy, sends the acknowledgment to the notification message coming from UE_A.

In an additional preferred version, the use of a session identifier can be added to the previously described features, assigned by the SWIS server to the UE_A, UE_B terminals, to identify the peer-to-peer connection between the two terminals. Such a session identifier allows to make the communication protocol more robust, and, as will be shown in the following description, it also allows to simplify the structure of at least some of the messages, so that the procedure for enabling the combinatory service is made more efficient and more fast. In detail, the previously illustrated procedure can be modified in such a way as to distinguish two different types of registration request from UE_A, UE_B terminals on the SWIS server: a first registration (for example, executed by the SWIS application on the first call executed or received by the related terminal after activation), a registration subsequent to the first. The two different types of registration request are distinguished by the fact that in the first registration request the SWIS application does not send the session identifier (hereinafter SessionID) to the SWIS server, while in the registration request following the first, the SWIS application inserts a SessionID previously received by the SWIS server.

Petition 870180034773, of 04/27/2018, p. 48/59 / 44

More particularly, with reference to the UE_A terminal, in the first registration on the SWIS server, the UE_A terminal sends a registration request to the SWIS server after opening the connection in the packet domain, including in the request its own IP_addA address and the number phone number CLI_B from UE_B terminal, as previously described. Additional parameters, for example parameters related to the configuration of the video encoding fixed in the UE_A terminal, and / or for the SWIS application version, and / or the APN address to which the UE_A terminal is connected to open the packet connection, can be included in the first registration application, as will be shown in more detail in the following description. In the first registration request, the SessionID parameter is not included, because the SWIS server has not yet communicated it to the UE_A terminal.

The SWIS server receives the registration request from the UE_A terminal, extracts its IP_addA address, and recognizes the absence of the SessionID parameter. Based on this, it asks the APN to acquire the phone number CLI_A of the UE_A terminal. Once the CLI_A phone number has been obtained, the SWIS server generates the session identifier SessionID. Such an identifier can be formed, for example, by a random sequence of numbers or alphanumeric characters. In a preferred embodiment, the SWIS server generates a key ID, with which it encodes the CLI_A phone number. From the key ID and the CLI_A phone number encoded with such a key, the SWIS server generates the SessionID session identifier, for example:

SessionID = (CLI_A) id + [ID] _x , where the notation (CLI_A) ID indicates the CLI_A phone number encoded using the key ID and the notation [ID] x indicates that the key ID is not in 'plaintext ', but is preferably calculated by the SWIS server with the same algorithm used to encrypt CLI_A (or with a different algorithm) and

Petition 870180034773, of 04/27/2018, p. 49/59 / 44 with an X key only known to the SWIS server. The SessionlD parameter thus produced is sent by the SWIS server to the UE_A terminal, in an acknowledgment message for its previous registration request. In such an acknowledgment message, the SWIS server may additionally include other information, such as for example possible changes to the video encoding placement parameters of the UE_A terminal. The same session identifier SessionID is also communicated to terminal UE_B, in a message acknowledging its registration request, since the SWIS server has verified that terminals UE_A and UE_B already have an ongoing call in the circuit domain. Such SessionID parameter can advantageously be included in the messages that the terminals UE_A and UE_B exchange once the peer-to-peer connection in the packet domain is established, to make the communication protocol more robust thanks to cross-consistency controls.

In the registration requests subsequent to the first, the UE_A terminal sends to its own IP_addA address, the telephone number of the interlocutor in the circuit domain (for example, the same UE_B terminal or a third UE_C terminal), and the SessionID parameter received by the server of SWIS in the registry preceding the current one. Preferably, in such a request, the UE_A terminal no longer sends the additional parameters previously described to the SWIS server. The SWIS server is able to extract the CLI_A phone number from the UE_A terminal that is sending the registration request for the SessionID parameter included in the registration request (by decrypting it using the key ID related to the previous registration request), without the need to interrogate the APN again to resolve the IP_addA address. This makes it possible to speed up the enabling procedure for the combinatory service, as well as to reduce the processing load on the APN access nodes of the packet domain. The SessionID session identifier expires on completion of the peer-to-peer connection between the two terminals, which is

Petition 870180034773, of 04/27/2018, p. 50/59 / 44 signaled by the same terminals to the SWIS server, as previously described.

In the following examples, possible compositions of some of the signaling messages previously described are reported. The compositions typically refer to fields to be inserted in the various messages. Here below, the exhaustive list is given of the fields present in all the examples reported in the following, with the related explanation:

• Command: indicates the command executed (in messages in which the beginning of a procedure is signaled);

• Version: indicates the version of the SWIS application installed on the terminal;

• Type: indicates the type of terminal;

• Remote IP: indicates the receiver's IP;

• Remote MSISDN: indicates the recipient's phone number;

• APN: indicates the APN used for the connection in the packet domain;

• Bitrate: indicates the speed of the video transmission used by the video encoder at the terminal;

• Framerate: indicates the number of video frames in the time unit used by the video encoder at the terminal;

• Interval: indicates the waiting time for a peer-to-peer session start message;

• Session-ID: indicates the peer-to-peer session;

• SizeDisplay: indicates the size of the screen;

• RFU: indicates a field reserved for possible future uses.

In all the examples reported below, it is intended that the signals be carried by TCP or UDP packets, already taking the assigned IP address to the sender's terminal: for this reason, such a

Petition 870180034773, of 04/27/2018, p. 51/59 / 44 address is never indicated among the fields to be inserted.

In a first example (table 1), a possible structure of a first terminal registration request message to the SWIS server is reported.

Table 1

FIELDS Value Required Optional Lost Command X Version X Type X Remote MSISDN X Session id X APN X Bit rate X Frame rate X Interval X SizeDisplay X RFU X

In a second example (table 2), a possible structure of a registration request message following the first from a terminal to the SWIS server is reported.

Table 2

FIELDS Value Required Optional Lost Command X Version X Type X Remote MSISDN X Session id X APN X Bit rate X Frame rate X Interval X SizeDisplay X RFU X

In a third example (table 3), a possible structure of an acknowledgment message sent by the SWIS server to a terminal that sent a first registration request is reported.

FIELDS Value Required Optional Lost Remote IP X (if present) Version X (if present) Type X (if present)

Petition 870180034773, of 04/27/2018, p. 52/59 / 44

Session id X APN X (if changed) Bit rate X (if changed) Frame rate X (if changed) Interval X (if changed) SizeDisplay RFU X

In a fourth example (table 4), a possible structure of an acknowledgment message sent by the SWIS server to a terminal that sent a registration request following the first is reported.

Table 4

FIELDS Value Required Optional Lost Remote IP X (if present) Version X (if present) Type X (if present) Session id X APN X Bit rate X Frame rate X Interval X SizeDisplay RFU X

In a fifth example (table 5), a possible structure of a signal signaling the completion of the peer-to-peer connection sent by the terminals to the SWIS server is reported.

Table 5

FIELDS Value Required Optional Lost Command X Session id X RFU X

In a sixth example (table 6), a possible structure of a peer-to-peer login message sent by one of the two terminals to the other is reported.

Table 6

FIELDS Value Required Optional Lost Session id X RFU X

In a seventh example (table 7), a possible structure of

Petition 870180034773, of 04/27/2018, p. 53/59 / 44 a video transmission start signaling message, sent by one of the terminals to the SWIS server is reported.

Table 7

FIELDS Value Required Optional Lost Command X Session id X APN RFU X

In an eighth example (table 8), a possible structure of an end of video transmission signaling message, sent by one of the terminals to the SWIS server is reported.

Table 8

FIELDS Value Required Optional Lost Command X Session id X RFU X

Such signaling messages can be produced by known protocols, such as for example HTTP and SIP. Signaling messages can be sent encrypted (using appropriate keys) or, preferably, encrypted (for example through Base64 or Huffman encryption), to increase the privacy level of the communication protocol.

The present description was made with specific reference to a mobile communication network. The Applicant believes, however, that the teachings given above can be applied or adapted also for services that can be enjoyed by a fixed network. In particular, it can be provided that the terminals of two users connected to one another in a call, and capable of enjoying a combinatorial service, are connected to a fixed network, one to a mobile network.

Petition 870180034773, of 04/27/2018, p. 54/59 / 4

Claims (12)

1. Method to enable a first (12) and a second (14) terminals of a communication network (20) to use a combinatorial service, comprising the steps of: establishing a first connection (C1) in a circuit domain of said communication network (20) between said first terminal (12) and said second terminal (14); receiving, in said first and said second terminals, an acknowledgment of the establishment of said first connection (C1); automatically connecting said first (12) and said second (14) terminals to a packet domain (51) of said communication network (20), as a result of receiving said recognition; the method characterized by the fact that it further comprises: designating said first (12) and said second (14) terminals respectively to a first and a second address in said packet domain (51) of said communication network (20), said first and said second addresses being respectively associated with a first and a second identifier of said first and said second terminals in said circuit domain (35) of said communication network; automatically sending a first request (509) from said first terminal to an apparatus included in said packet domain (51) of said communication network (20), said first request including said first address and said second identifier, as a result of receiving said first address; automatically sending a second request (512) from said second terminal to said device, said second request including said second address and said first identifier, as a result of receiving said second address; enable the establishment of a second connection (C2) in Petition 870180034773, of 04/27/2018, p. 55/59 2/4 said packet domain of said communication network (20) between said first (12) and said second (14) terminals, based on a first association between said first identifier and said first address and a second association between said second identifier and said second address, said first and said second associations being executed by said apparatus as a result of receiving said first and said second requests. 2. Method according to claim 1, characterized by the fact that enabling the establishment of said second connection (C2) includes: sending said first address to said second terminal from said device. 3. Method according to claim 2, characterized by the fact that it includes: activate, in said second terminal (14), a menu option related to at least one service that can be enjoyed by said second connection (C2), as a result of receiving said first address. 4. Method according to claim 2 or 3, characterized by the fact that enabling the establishment of said second connection (C2) includes: sending, from said second terminal (14), said second address to said first terminal. 5. Method according to claim 4, characterized by the fact that it includes: activate, in said first terminal (12), a menu option related to at least one service that can be enjoyed by said second connection (C2), as a result of receiving said second address. Method according to claim 4 or 5, characterized in that said activation of said at least one menu option in said first or said second terminal occurs within a predefined time interval of sending said first or second order. Petition 870180034773, of 04/27/2018, p. 56/59 3/4 Method according to claim 4 or 5, characterized in that said at least one menu option allows the transmission of a video from said first terminal to said second terminal or from said second to said first terminal by said second connection (C2). Method according to any one of claims 1 to 7, characterized in that said first or said second address includes a first or second IP address assigned to said first (12) or said second terminal (14 ). Method according to any one of claims 1 to 8, characterized in that said first or said second identifier includes a first or second phone number of said first or said second terminal (14). Method according to any one of claims 1 to 9, characterized in that said first or said second request for said first or said second terminal includes a first or a second TCP packet. 11. Method according to any one of claims 1 to 10, characterized in that it includes: terminate this first connection (C1); receiving, in said first (12) and in said second (14) terminals, an acknowledgment (523) of the termination of said first connection; automatically terminating said connection of said first and said second terminals to said packet domain of said communication network as a result of receiving said acknowledgment of the termination of said first connection (C1). 12. Method for enabling the use of at least one combinatorial service in at least one first terminal (12) of a first user of a communication network (20), comprising: establish a first connection in a circuit domain Petition 870180034773, of 04/27/2018, p. 57/59 4/4 of said communication network (20) from said first terminal (12) to a second terminal (14) of a second user of said communication network; receiving, in said first terminal, an acknowledgment of the establishment of said first connection (C1); and the_method characterized by the fact that it also comprises: automatically activating, at said first terminal (12), at least one menu option related to the use of said combinatorial service as a result of receiving said recognition. Petition 870180034773, of 04/27/2018, p. 58/59 1/6 2/6 3/6 127 416