Methods and electronic device for managing a multi-device environment session for a client device

Abstract

The present disclosure discloses methods and electronic device for managing a Multi-Device Environment (MDE) session for a client device in a communication network. The method includes transmitting, by the client device, a request to a MDE server of the communication network via one of a plurality of communication protocols. The request comprises a tag indicating the request for one of a call forking session and a text based session. The method further includes receiving by the client device, one or more notification messages from the MDE server using the communication protocol used for transmitting the request data packet. The one or more notification messages comprise one or more JavaScript Object Notation (JSON) wrapped Session Initiation Protocol (SIP) messages when the one or more notification messages correspond to the call forking session.

Description

METHODS AND ELECTRONIC DEVICE FOR MANAGING A MULTI-DEVICE ENVIRONMENT SESSION FOR A CLIENT DEVICE

[0001] The present disclosure relates to wireless communication, and more particularly relates to an electronic device and a method for managing a Multi-Device Environment (MDE) session for a client device in a communication network.

[0002] In a Multi-Device Environment (MDE), calls and messages are synchronized across multiple electronic devices, enabling seamless communication. This environment comprises a primary device (PD), equipped with a SIM card, capable of placing calls through an operator network. Examples of PDs may include, but are not limited to, smartphones or any other device with SIM card. Users can connect one or more secondary devices (SDs) to the PD, which may or may not include a SIM card. These SDs encompass a range of devices, such as tablets, laptops, and battery-sensitive devices, smart glasses, smart rings, and smartwatches. By linking these devices to the PD's phone number through a shared account, MDE facilitates global communication and synchronization of calls and messages across all connected devices. As shown in FIG. 1, the PD and SDs may be connected to an MDE server to enable calls, Short Message Service (SMS), and notifications.

[0003] Further, MDE enables the users to respond to calls and messages from any connected device, even when the devices are not physically nearby. MDE also supports synchronization over local networks when the devices share the same network connection. Notably, MDE imposes no limitations on the number of SDs that can be connected, providing significant flexibility for users.

[0004] A notable feature of MDE is call forking, which allows users to make or receive calls on SDs or seamlessly switch ongoing calls between the PD and one of the SDs. FIG. 2 illustrates a call forking system 200, in accordance with related art. As shown, the call originated at the PD 202 is continued at the SD 204 via a Proxy-Call Session Control Function (P-CSCF) server 208. The call may be received from a remote device 206. In particular, the PD 202 sends call info update regarding the call to the P-CSCF server 208. The P-CSCF server 208 forwards the call info update to the SD 204 and the SD 204 then receives the call. The call forking functionality is achieved by establishing Transmission Control Protocol (TCP) or User Datagram Protocol (UDP) connections for Session Initiation Protocol (SIP) signaling with P-CSCF servers. These connections are maintained through a Keep-alive mechanism that periodically sends packets to prevent connection disruptions.

[0005] SIP is a signalling protocol used for initiating, maintaining, and ending real-time sessions between devices that include voice, video, and messaging. SIP is a mature, flexible, and extensible technology used in Voice Over Internet Protocol (VoIP) communications to establish and break sessions. The SIP protocol supports various communication paradigms (e.g., command, event, and session-based). Also, SIP can deliver different media types, from simple textual to rich media types. SIP can be carried by several transport layer protocols including Transmission Control Protocol (TCP), User Datagram Protocol (UDP), and Transport Layer Security (TLS). SIP clients typically use TCP or UDP or TLS on port numbers 5060 or 5061. However, as shown in FIG. 3, SIP requires a dedicated transport channel to be established between devices and the IP Multimedia Subsystem (IMS) server, which is maintained through a Keep-alive mechanism. However, this requirement leads to significant power consumption, exceeding the capabilities of typical battery-powered and resource-constrained SDs, such as speakers, cameras, - smart glasses, smart rings, etc.

[0006] In an MDE system, synchronization is achieved through two primary mechanisms, i.e., call syncing and message syncing. Call syncing allows PD and SD to register with the P-CSCF (i.e., call server) via SIP signaling, enabling users to pick up calls on SDs even when received on the PD. However, maintaining SIP signaling requires periodic Keep-alive packets, which results in high resource consumption. FIG. 3 illustrates an exemplary environment 300 showing call syncing, in accordance with related art. The PD302 receives a new incoming call from a remote device 306. The new incoming call is forked to one of the SDs through the P-CSCF server 308.

[0007] FIGS. 4A-4B illustrate signal flow diagrams 400A-400B showing the call syncing, in accordance with related art. As shown, the PD 302 and the SDs 304 perform SIP registration process with the P-CSCF server 308 through operations 401-407, which are well-known set of message exchanges. Subsequently, at operation 409, the SIP registration process is completed. Furthermore, a call is made from the remote device 306. Accordingly, at operation 411, the remote device 306 sends an SIP Invite message, i.e., Invite Volte / Vilte Call to the PD 302. At operation 413, the PD 302 initiates a call relay invite towards the SD 304 through the P-CSCF server 308. Then, at operation 415, the P-CSCF server checks if a Peer-to-Peer (P2P) connection is available, when there are more than one SD and all the SDs are present within a same local network. Accordingly, at operation 417, the PD 302 sends an invite to the P-CSCF server 308. At operation 419, the P-CSCF server 308 relays the invite to the SD 304. Hence, incoming call notification is indicated in both the PD 302 and the SD 304. Then, at operation 421, the SD 304 accepts the call. Accordingly, at operation 423, the SD 304 sends an acknowledgement, i.e., 200 OK (INVITE) to the P-CSCF server 308. Then, at operation 425, the P-CSCF server 308 relays the acknowledgement to the PD 302. At operation 427, the PD 302 relays the acknowledgement to the remote device 306. Accordingly, if the call is accepted in PD 302, then only one session is created, i.e., one Volte / Vilte session between the remote device 306 and the PD 302. However, if the call is accepted from the SD 304, then two sessions are created, i.e., one Volte / Vilte session between the remote device 306 and the PD 302, and another MDE session between the PD 302 and the SD 304. Accordingly, the call is transferred from the PD 302 to the SD 304 through operations 429 and 431. Further, when the call is ended by the remote device 306, both the Volte and MDE sessions get cleared and the user is notified on both the devices. In particular, at operation 433, the remote device 306 sends a BYE message to the PD 420. At operation 435, the PD 302 forwards the BYE message to the P-CSCF server 308. At operation 437, the P-CSCF server 308 forwards the BYE message to the SD 304. In response, at operation 439, the SD 304 responds with a 200 OK message. At operation 441, the P-CSCF server 308 forwards the 200 OK message to the PD 302. The PD 304 then forwards the 200 OK message to the remote device 306 at operation 443. Accordingly, the call is terminated at the PD 302 to the SD 304 through operations 445 and 447.

[0008] Further, message syncing enables the PD and SDs to register with a Network Message Server (NMS) via Hypertext Transfer Protocol (HTTP) signaling, ensuring that messages received on the PD are synchronized with SDs. FIG. 5A illustrates an exemplary environment 500A showing message syncing, in accordance with related art. The PD 502 receives a new incoming message from a remote device 506. The new incoming message is synced to one of the SDs through the NMS 508.

[0009] FIG. 5B illustrates a signal flow diagram 500B showing the call syncing, in accordance with related art. As shown, both the PD 502 and the SD 505 subscribes to the NMS Server 508 via HTTP protocol to enable Message Sync through operations 501-507, which are well-known set of message exchanges. Subsequently, at operation 509, Message Sync is subscribed with the NMS 508. At operation 511, the PD 502 receives an incoming message from a remote device 506 and the message is displayed at the PD 502. At operation 513, the PD 502 sends an acknowledgement, i.e., 200 OK to the remote device 506. At operation 515, the PD 502 posts the received message to the NMS 508. In response, at operation 517, the NMS508sends an acknowledgement, i.e., 200 OK to the PD 502. Hence, when the remote device 506 sends a message to the PD 502, the message is posted to the NMS 508 via HTTP. Then, the messages is pushed to other connected SDs, such as SD 504 via a Push Notification Server 510. Accordingly, at operation 519, the NMS 508 sends a Push Notification Message to the Push Notification Server 510. Then, at operation 521, the Push Notification Server 510 forwards the Push Notification Message to the SD 504. Then, at operation 523, the SD 504 sends a get message to the NMS 508. In response, at operation 525, the NMS 508 sends acknowledgement, i.e., 200 OK to the SD 504. At operation 527, the message is displayed at the SD 504. It should be noted that if the messages are sent from SDs, the same HTTP procedure is followed. Hence, HTTP protocol is established between PD / SD and the NMS server for Message sync using MDE service. Further, the Push notification Server 510 is used to push messages to the PD / SD.

[0010] Further, a Keep-alive mechanism is particularly unnecessary for SDs, such as wearables, which are infrequently used or constrained by limited battery capacities. FIG. 6 illustrates a signal flow diagram 600 showing SIP registration procedure in the call forking system, in accordance with related art. In FIG. 6, a user enabled Multi device sync in the PD and the SD, to use the call forking feature. As shown, the PD / SD 602 starts SIP Registration process to the P-CSCF server 604. In particular, at operation 601, the PD / SD 602 sends a first SIP REGISTER request with last available access-token to the P-CSCF server 604. At operation 603, the request is challenged with 401 unauthorised. At operation 605, the PD / SD 602 fetches latest access-token from a user account server and sends a second REGISTER request with the updated access-token to the P-CSCF server 604. At operation 607, the P-CSCF server 604 responds with a 200 OK response. Further, the SIP registration is maintained. Also, a Keep-alive mechanism is maintained, as shown in FIG. 7. FIG. 7 illustrates a signal flow diagram 700 showing role of Keep-alive mechanism in the SIP Registration, in accordance with related art. As shown, The PD / SD 602 attempts to register its location with the IMS network to enable the routing of incoming calls to specific endpoints within the network. This process also establishes a Network Address Translation (NAT) binding, which is maintained using periodic “Keep-alive” packets exchanged between the PD / SD 602 and the P-CSCF server 604. A SIP packet generated by the PD / SD 602 reaches the NAT router 702. The NAT router 702 rewrites the source port (e.g., UDP 4534) and creates a NAT binding, such as Local Area Network (LAN): 192.168.1.8:UDP:5060 <-> Wide Area Network (WAN): 123.4.43.3:UDP:4534. In particular, at operation 701, the PD / SD 602 sends a register request to the NAT router 702. At operation 703, the NAT router 702 forwards the request to the P-CSCF server 604. At operation, 705, the PCSCF server 604 sends an acknowledgement, i.e., 200 OK to the NAT server 702. At operation 707, the NAT router 702 forwards the acknowledgement to the PD / SD 602. Normally, the PD / SD 602 closes the NAT binding after a short period of inactivity (typically 60-900 seconds, depending on the device). This behaviour prevents IMS servers from reaching clients (PD / SD) to alert them of incoming calls. To maintain the NAT binding, the SIP Keep-Alive technique is used, wherein the PD / SD periodically sends a message packet (with no functional purpose other than prompting the SIP server to respond with an acknowledgment) approximately usually every 30 seconds. However, transmitting these Keep-Alive packets significantly drains the battery, particularly in power-sensitive devices such as SDs, including smart glasses, smart rings, smartwatches, and similar devices.

[0011] Further, to enable both call and message synchronization, devices, PD and SD must establish separate stacks, protocols, or channels for SIP (calls) and HTTP (messages) across two different servers, i.e., P-CSCF and NMS. This approach creates unnecessary overhead, consuming additional resources and power, particularly for secondary devices with limited capabilities. FIG. 8 illustrates a signal flow diagram showing multiple stack / transport channel / server for message and call sync, in accordance with related art. In FIG. 8, a user enabled multi device sync in the PD and the SD. to use the call forking feature. For the purpose of the call forking, the PD / SD 802 brings up stack-1 (i.e., client side service / engine / protocol), The PD / SD 802 also connects and exchanges the SIP messages over TCP / UDP channel to the P-CSCF server 804. In particular, at operation 801, the PD / SD 802 sends a first SIP REGISTER to the P-CSCF server 804. At operation 803, the request is challenged with 401 unauthorised. At operation 805, the PD / SD 802 fetches latest access-token [a key required to login] from a user account server and sends a second REGISTER request with the updated access-token to the P-CSCF server 804. At operation 807, the P-CSCF server 804 responds with a 200 OK response. Accordingly, at operation 809, the PD / SD 802 completes the SIP registration process. Further, for the purpose of message sync, PD / SD 802 brings up stack-2. The PD / SD 802 connects and exchanges the HTTP messages over TCP / UDP channel to the NMS 806. In particular, at operation 811, the PD / SD 802 sends a HTTP subscription for message sync to the NMS 806. At operation 813, the NMS 806 responds with a 200 OK response. Accordingly, at operation 815, the PD / SD 802 completes the HTTP subscription process. Hence, in order to support message and call synchronization to SDs in the existing systems, there are two separate stacks, two dedicated channels, and two different server deployments, i.e., one for calls and the other for messages. This approach results in memory, power, and maintenance overhead. Additionally, although SDs are incapable of operator calling, the same stack-1 is brought up to support MDE call forking, even when stack-2 for message synchronization is already running.

[0012] Further, message synchronization is enabled in both cases, ensuring that the MDE subscription with NMS is maintained regardless of the call forking status. However, SIP registration with P-CSCF is performed only when the call forking is enabled in the existing techniques. At the PD level, enabling call forking leads to a moderate rise in power consumption. In contrast, at the SD level, the increase is significantly higher, which poses a major concern for battery-sensitive devices such as smart rings, smart glasses and smart watches. These devices often do not require call forking frequently, making the power drain unnecessary and inefficient.

[0013] Further, maintaining a dedicated channel (TCP / UDP) for SIP registration by intermittently sending keep-alive packets further accelerates battery consumption for these devices. From a client (PD / SD) perspective, two separate stacks, i.e., one for message subscription and another for call forking add to the power consumption overhead. On the server side, managing two subscriptions while synchronizing both the message and call servers increases resource utilization. Additionally, SIP server deployment across regions to enable the call forking feature creates further challenges, as any new feature enhancements depend strictly on server-side support, introducing additional complexity and dependencies.

[0014] These inefficiencies underscore the need for a more optimized and resource-efficient solution for multi-device synchronization. Addressing these challenges is critical to improving the efficiency of the multi-device environment (MDE) system and enhancing battery life for devices where power consumption is a primary concern.

[0015] Therefore, in view of the above-mentioned problems, it is advantageous to provide an improved electronic device and method that can overcome the above-mentioned problems and limitations associated with MDE.

[0016] This summary is provided to introduce a selection of concepts, in a simplified format, that are further described in the detailed description of the invention. This summary is neither intended to identify key or essential inventive concepts of the invention nor is it intended for determining the scope of the invention.

[0017] According to an embodiment of the present disclosure, disclosed herein is a method for managing a Multi-Device Environment (MDE) session for a client device in a communication network. The method includes transmitting, by the client device, a request to a MDE server of the communication network via one of a plurality of communication protocols. The request comprises a tag indicating the request for one of a call forking session and a text based session. The method further includes receiving by the client device, one or more notification messages from the MDE server using the communication protocol used for transmitting the request data packet. The one or more notification messages comprise one or more JavaScript Object Notation (JSON) wrapped Session Initiation Protocol (SIP) messages when the one or more notification messages correspond to the call forking session.

[0018] According to an embodiment of the present disclosure, disclosed herein is a method for managing a Multi-Device Environment (MDE) session for a client device in a communication network. The method includes transmitting, by the client device, a request to a MDE server of the communication network via one of a plurality of communication protocols. The request comprises a tag indicating the request for one of a call forking session and a text based session. The method further includes receiving by the client device, one or more SIP messages from a caller device when the request corresponds to the call forking session. The method further includes converting the one or more SIP messages to JSON wrapped SIP messages and transmitting the SIP messages to the MDE server.

[0019] According to an embodiment of the present disclosure, a system for managing a Multi-Device Environment (MDE) session for a client device in a communication network is disclosed. The system comprises at least one processor configured to transmit a request to a MDE server of the communication network via one of a plurality of communication protocols. The request comprises a tag indicating the request for one of a call forking session and a text based session. The at least one processor is further configured to receive one or more notification messages from the MDE server using the communication protocol used for transmitting the request data packet. The one or more notification messages comprise one or more JavaScript Object Notation (JSON) wrapped Session Initiation Protocol (SIP) messages when the one or more notification messages correspond to the call forking session.

[0020] According to an embodiment of the present disclosure, a system for managing a Multi-Device Environment (MDE) session for a client device in a communication network is disclosed. The system comprises at least one processor configured to transmit a request to a MDE server of the communication network via one of a plurality of communication protocols. The request comprises a tag indicating the request for one of a call forking session and a text based session. The at least one processor is further configured to receive one or more SIP messages from a caller device when the request corresponds to the call forking session. The at least one processor is further configured to convert the one or more SIP messages to JSON wrapped SIP messages and transmit the SIP messages to the MDE server.

[0021] To further clarify the advantages and features of the present invention, a more particular description of the invention will be rendered by reference to specific embodiments thereof, which is illustrated in the appended drawing. It is appreciated that these drawings depict only typical embodiments of the invention and are therefore not to be considered limiting its scope. The invention will be described and explained with additional specificity and detail with the accompanying drawings.

[0022] These and other features, aspects, and advantages of the present invention will become better understood when the following detailed description is read with reference to the accompanying drawings in which like characters represent like parts throughout the drawings, wherein:

[0023] FIG. 1 illustrates a block diagram of a Multi-Device Environment (MDE), in accordance with related art;

[0024] FIG. 2 illustrates a call forking system, in accordance with related art;

[0025] FIG. 3 illustrates an exemplary environment showing call syncing, in accordance with related art;

[0026] FIGS. 3A-3B illustrate signal flow diagrams showing the call syncing, in accordance with related art;

[0027] FIG. 5A illustrates an exemplary environment showing message syncing, in accordance with related art;

[0028] FIG. 5B illustrates a signal flow diagram showing the message syncing, in accordance with related art;

[0029] FIG. 6 illustrates a signal flow diagram showing Session Initiation Protocol (SIP) Registration procedure in the call forking system, in accordance with related art;

[0030] FIG. 7 illustrates a signal flow diagram showing the role of Keep-alive mechanism in the SIP Registration, in accordance with related art;

[0031] FIG. 8 illustrates a signal flow diagram showing multiple stack / transport channel / server for message and call sync, in accordance with related art;

[0032] FIG. 9 illustrates a signal flow diagram showing call syncing in the MDE, in accordance with related art;

[0033] FIG. 10 illustrates a block diagram of a Multi-Device Environment (MDE), in accordance with one or more embodiments of the disclosure;

[0034] FIG. 11 illustrates a block diagram of at least one of a system 1100, the PD 1001 or the SD 1003 for managing an MDE session for a client device in a communication network, in accordance with one or more embodiments of the disclosure;

[0035] FIGs. 12-13 illustrate showing flow charts showing methods for managing the MDE session for the client device in the communication network, in accordance with one or more embodiments of the disclosure;

[0036] FIG. 14 illustrates a signal flow diagram showing establishing the MDE session in the MDE, in accordance with one or more embodiments of the disclosure;

[0037] FIG. 15A illustrates message and call subscription flow impact in the MDE on a client device, in accordance with related art;

[0038] FIG. 15B illustrates message and call subscription flow impact in the MDE on the client device, in accordance with one or more embodiments of the disclosure;

[0039] FIG. 16A illustrates a signal flow diagram showing subscription flow impact in the MDE, in accordance with related art;

[0040] FIG. 16B illustrates a signal flow diagram showing subscription flow impact, in accordance with one or more embodiments of the disclosure;

[0041] FIG. 17A illustrates a signal flow diagram showing a Primary Device (PD) outgoing call flow impact in the MDE, in accordance with related art; and

[0042] FIG. 17B illustrates a signal flow diagram showing the PD going call flow impact in the MDE, in accordance with one or more embodiments of the disclosure.

[0043] FIG. 18 illustrates a block diagram of an exemplary electronic device 1800 capable of performing the operations described herein.

[0044] Further, skilled artisans will appreciate that those elements in the drawings are illustrated for simplicity and may not have necessarily been drawn to scale. For example, the flow charts illustrate the method in terms of the most prominent steps involved to help to improve understanding of aspects of the present invention. Furthermore, in terms of the construction of the device, one or more components of the device may have been represented in the drawings by conventional symbols, and the drawings may show only those specific details that are pertinent to understanding the embodiments of the present invention so as not to obscure the drawings with details that will be readily apparent to those of ordinary skill in the art having the benefit of the description herein.

[0045] For the purpose of promoting an understanding of the principles of the present disclosure, reference will now be made to the various embodiments and specific language will be used to describe the same. It will nevertheless be understood that no limitation of the scope of the present disclosure is thereby intended, such alterations and further modifications in the illustrated system, and such further applications of the principles of the present disclosure as illustrated therein being contemplated as would normally occur to one skilled in the art to which the present disclosure relates.

[0046] It will be understood by those skilled in the art that the foregoing general description and the following detailed description are explanatory of the present disclosure and are not intended to be restrictive thereof.

[0047] Whether or not a certain feature or element was limited to being used only once, it may still be referred to as “one or more features” or “one or more elements” or “at least one feature” or “at least one element.” Furthermore, the use of the terms “one or more” or “at least one” feature or element does not preclude there being none of that feature or element, unless otherwise specified by limiting language including, but not limited to, “there needs to be one or more…” or “one or more elements is required.”

[0048] Reference is made herein to some “embodiments.” It should be understood that an embodiment is an example of a possible implementation of any features and / or elements of the present disclosure. Some embodiments have been described for the purpose of explaining one or more of the potential ways in which the specific features and / or elements of the proposed disclosure fulfill the requirements of uniqueness, utility, and non-obviousness.

[0049] Use of the phrases and / or terms including, but not limited to, “a first embodiment,” “a further embodiment,” “an alternate embodiment,” “one embodiment,” “an embodiment,” “multiple embodiments,” “some embodiments,” “other embodiments,” “further embodiment”, “furthermore embodiment”, “additional embodiment” or other variants thereof do not necessarily refer to the same embodiments. Unless otherwise specified, one or more particular features and / or elements described in connection with one or more embodiments may be found in one embodiment, or may be found in more than one embodiment, or may be found in all embodiments, or may be found in no embodiments. Although one or more features and / or elements may be described herein in the context of only a single embodiment, or in the context of more than one embodiment, or in the context of all embodiments, the features and / or elements may instead be provided separately or in any appropriate combination or not at all. Conversely, any features and / or elements described in the context of separate embodiments may alternatively be realized as existing together in the context of a single embodiment.

[0050] Any particular and all details set forth herein are used in the context of some embodiments and therefore should not necessarily be taken as limiting factors to the proposed disclosure.

[0051] The terms “comprises”, “comprising”, or any other variations thereof, are intended to cover a non-exclusive inclusion, such that a process or method that comprises a list of steps does not include only those steps but may include other steps not expressly listed or inherent to such process or method. Similarly, one or more devices or sub-systems or elements or structures or components proceeded by “comprises... a” does not, without more constraints, preclude the existence of other devices or other sub-systems or other elements or other structures or other components or additional devices or additional sub-systems or additional elements or additional structures or additional components.

[0052] The term “couple” and the derivatives thereof refer to any direct or indirect communication between two or more elements, whether or not those elements are in physical contact with each other. The terms “transmit”, “receive”, and “communicate” as well as the derivatives thereof encompass both direct and indirect communication. The term “or” is an inclusive term meaning “and / or”. The phrase “associated with,” as well as derivatives thereof, refer to include, be included within, interconnect with, contain, be contained within, connect to or with, couple to or with, be communicable with, cooperate with, interleave, juxtapose, be proximate to, be bound to or with, have, have a property of, have a relationship to or with, or the like. The term “controller” refers to any device, system, or part thereof that controls at least one operation. The functionality associated with any particular controller may be centralized or distributed, whether locally or remotely. The phrase “at least one of,” when used with a list of items, means that different combinations of one or more of the listed items may be used, and only one item in the list may be needed. For example, “at least one of A, B, and C” includes any of the following combinations: A, B, C, A and B, A and C, B and C, and A and B and C, and any variations thereof. As an additional example, the expression “at least one of a, b, or c” may indicate only a, only b, only c, both a and b, both a and c, both b and c, all of a, b, and c, or variations thereof. Similarly, the term “set” means one or more. Accordingly, the set of items may be a single item or a collection of two or more items.

[0053] Moreover, multiple functions described below may be implemented or supported by one or more computer programs, each of which is formed from computer readable program code and embodied in a computer readable medium. The terms “application” and “program” refer to one or more computer programs, software components, sets of instructions, procedures, functions, objects, classes, instances, related data, or a portion thereof adapted for implementation in a suitable computer readable program code. The phrase “computer readable program code” includes any type of computer code, including source code, object code, and executable code. The phrase “computer readable medium” includes any type of medium capable of being accessed by a computer, such as Read Only Memory (ROM), Random Access Memory (RAM), a hard disk drive, a Compact Disc (CD), a Digital Video Disc (DVD), or any other type of memory. A “non-transitory” computer readable medium excludes wired, wireless, optical, or other communication links that transport transitory electrical or other signals. A non-transitory computer readable medium includes media where data may be permanently stored and media where data may be stored and later overwritten, such as a rewritable optical disc or an erasable memory device.

[0054] The current Multi-Device Environment (MDE) solution enables Secondary Devices (SDs) to accept / make calls through a Session Initiation Protocol (SIP) procedure-based stack solution. Also, the current MDE solution includes an HTTP-based stack solution to enable user messages sync to Primary Devices (PDs) / SDs. FIG. 9 illustrates a signal flow diagram showing call syncing in the MDE, in accordance with related art. As shown, both the PD 904 and the SD 910 subscribe to the NMS 908 for message sync requests and responses through operations 905-907. The request packet for subscribing includes a tag related to “message” which indicates the client (PD / SD) subscription for message sync services. Whenever there is a new message to sync, the NMS 908 sends a Push notification message to the PD / SD. The PD / SD further fetches full message content from the NMS 908. Further, the same PD / SD also has to perform IMS SIP registration (via TCP / UDP) procedure and maintain a keep-alive mechanism (operations 901-903) for the purpose of call-forking. When a remote device 902 calls the PD 904, the same SIP Invite is forwarded to the P-CSCF server 906 through operations 909-913. In response, an acknowledgment is received by the remote device 902 from the SD 910 through operations 915-919. Accordingly, the call is connected through operations 921 and 923. Further, when the call is disconnected, operations 925-935 are performed to release the call. It should be noted that operations 901-935 are well-known in the art. Hence, operations 901-935 are not explained in detail for the sake of brevity of the description.

[0055] To maintain MDE, it is necessary to support two separate channels, stacks, and servers. Specifically, SIP signaling over dedicated TCP / UDP is used as part of the IMS SIP procedure to enable call forking across connected devices. Additionally, HTTP-based subscription and Push Notification (PNF) services are employed to synchronize messages across these devices. As a result, an MDE solution that relies on two distinct stacks / protocols can be more expensive for battery-sensitive devices, potentially leading to unnecessary battery drain. This, in turn, negatively impacts the user experience.

[0056] Accordingly, the present disclosure provides techniques for using the same Hypertext Transfer Protocol (HTTP)-based stack / server to enable both call forking and message sync service in an MDE.

[0057] Embodiments of the present disclosure will be described below in detail with reference to the accompanying drawings.

[0058] For the sake of clarity, the first digit of a reference numeral of each component of the present disclosure is indicative of the Figure number, in which the corresponding component is shown. For example, reference numerals starting with digit “1” are shown at least in Figure 1. Similarly, reference numerals starting with digit “2” are shown at least in Figure 2. Further, similar reference numerals have been used to represent similar components in the Figures.

[0059] FIG. 10 illustrates a block diagram of a Multi-Device Environment (MDE) 1000, in accordance with one or more embodiments of the disclosure. As shown in FIG. 10, the MDE 1000 may include a Primary Device (PD) 1001, a Secondary Device (SD) 1003, a Remote Device 1005, and an MDE server 1007. The PD 1001 may be equipped with a Subscriber Identity Module (SIM) card, capable of placing calls through an operator network. Examples of the PD 1001 may include, but are not limited to, smartphones or any other device with SIM card or Embedded SIM (e-SIM) card. The SD 1003 may encompass a range of devices, such as tablets, laptops, and battery-sensitive devices, like and smartwatches. The PD 1001 and the SD 1003 may be connected to the MDE server 1007. The PD 1001 and the remote device 1007 may be connected to an operator server 1009. The operator server 1009 may correspond to a server associated with a Mobile Network Operator (MNO) providing network services to the PD 1001 and the remote device 1007.

[0060] In an embodiment, the Primary Device (PD) 1001 may include an electronic device. The Secondary Device (SD) 1003 may include an electronic device. The Remote Device 1005 may include an electronic device.

[0061] In an embodiment, the MDE server 1007 may correspond to a Network Message Server (NMS) of FIGS. 5A and 5B. In another embodiment, the MDE server 1007 may correspond to a Push Notification (PNF) server of a wireless communication network, such as a Fifth Generation (5G) network, a Sixth Generation (6G) network and similar networks. The PD 1001, the SD 1003 and the remote device 1005 may be connected in the wireless communication network. In an embodiment, the MDE server 1007 may perform all the functions of the NMS 508. The remote device 1005 may be equipped with a SIM card, capable of placing calls through an operator network. Examples of the remote device 1005 may include, but are not limited to, smartphones or any other device with SIM card or e-SIM card.

[0062] In an embodiment, the PD 1001 and the SD 1003 may be connected through a wireless communication link (not shown). It should be noted that even though only one SD 1003 has been referred to here, the PD 1001 may be connected to more than one SD. The PD 1001 and SD 1003 may be connected using a common user account. In an embodiment, the present disclosure provides techniques for managing an MDE session for a PD 1001 and / or SD 1003 (also referred to as a client device). In an embodiment, the disclosed techniques may be implemented in the PD 1001 and / or the SD 1003.

[0063] FIG. 11 illustrates a block diagram of at least one of a system 1100, the PD 1001 or the SD 1003 for managing the MDE session for the client device in the communication network, in accordance with one or more embodiments of the disclosure. FIGS. 12-13 illustrate showingflow charts methods 1200 and 1300 for managing the MDE session for the client device in the communication network, in accordance with one or more embodiments of the disclosure. In an embodiment, the description of FIGS. 11-13 are explained in conjunction with each other.

[0064] Referring to FIG. 11, the system 1100 may include, but is not limited to, at least one processor 1102 (herein referred to as a processor), memory 1104, modules 1106, and an interface 1108. The memory 1104, the modules 1106, and the interface 1108 may be coupled to the processor 1102.

[0065] In an embodiment, PD 1001 may include, but is not limited to, at least one processor 1102 (herein referred to as a processor), memory 1104, modules 1106, and an interface 1108. The memory 1104, the modules 1106, and the interface 1108 may be coupled to the processor 1102.

[0066] In an embodiment, SD 1003 may include, but is not limited to, at least one processor 1102 (herein referred to as a processor), memory 1104, modules 1106, and an interface 1108. The memory 1104, the modules 1106, and the interface 1108 may be coupled to the processor 1102.

[0067] In an embodiment, the system 1100 may be a part of the PD 1001 and / or the SD 1003. In another embodiment, the system 1100 may be coupled to the PD 1001 and / or the SD 1003. In such an embodiment, the system 1100 may be located on a device coupled to the PD 1001 and / or the SD 1003, such as a hub device configured to communicate with both the PD 1001 and the SD 1003.

[0068] The processor 1102 can be a single processing unit or several units, all of which could include multiple computing units. The processor 1102 may be implemented as one or more microprocessors, microcomputers, microcontrollers, digital signal processors, central processing units, state machines, logic circuitries, and / or any device that manipulates signals based on operational instructions. Among other capabilities, the processor 1102 is configured to fetch and execute computer-readable instructions and data stored in the memory 1104.

[0069] The memory 1104 may include any non-transitory computer-readable medium known in the art including, for example, volatile memory, such as static random access memory (SRAM) and dynamic random access memory (DRAM), and / or non-volatile memory, such as read-only memory (ROM), erasable programmable ROM, flash memories, hard disks, optical disks, and magnetic tapes. Further, the memory 1104 may include an operating system for performing one or more tasks of the system 1100, as performed by a generic operating system in the communications domain.

[0070] The modules 1106 amongst other things, include routines, programs, objects, components, data structures, etc., which perform particular tasks or implement data types. The modules 1106 may also be implemented as, signal processor(s), state machine(s), logic circuitries, and / or any other device or component that manipulates signals based on operational instructions.Further, the modules 1106 can be implemented in hardware, instructions executed by a processing unit, or by a combination thereof. The processing unit can comprise a computer, a processor, such as the processor 1102, a state machine, a logic array, or any other suitable wearable device capable of processing instructions. The processing unit can be a general-purpose processor which executes instructions to cause the general-purpose processor to perform the required tasks or, the processing unit can be dedicated to performing the required functions. In another embodiment of the present disclosure, the modules 1106 may be machine-readable instructions (software) which, when executed by a processor / processing unit, perform any of the described functionalities.

[0071] In some embodiments, the modules 1106 may include a set of instructions that may be executed to cause the system 1100 to perform any one or more of the methods disclosed herein. The modules 1106 may be configured to perform the steps of the present disclosure using the data stored in the memory 1104 to facilitate managing the MDE session for the client device in the communication network, as discussed throughout this disclosure. In an embodiment, each of the modules 1106 may be hardware units that may be outside the memory 1104.

[0072] In an embodiment, the modules 1106 may include a transmitting module 1110, a receiving module 1112, an establishing module 1114, and a converting module 1116. The modules 1106 and their working is further explained in detail in the following paragraphs.

[0073] In an embodiment, the memory 1104 may store the modules 1106 including instructions. the memory 1104 may store the transmitting module 1110 including instructions. the memory 1104 may store the receiving module 1112 including instructions. the memory 1104 may store the establishing module 1114 including instructions. the memory 1104 may store the converting module 1116 including instructions.

[0074] The various modules 1110-1116 may be in communication with each other. In an embodiment, the various modules 1110-1116 may be a part of the processor 1102. In another embodiment, the processor 1102 may be configured to perform the functions of modules 1110-1116.

[0075] Referring now to FIG. 12, at operation 1201, the method 1200 may include transmitting a request to the MDE server 1007 via one of a plurality of communication protocols. In an embodiment, the plurality of communication protocols may include, but is not limited to, a Hypertext Transfer Protocol Secure (http / s) communication protocol, and a Google Remote Procedure Call (gRPC) communication protocol.

[0076] In an embodiment, the instructions stored in the memory 1104, when executed by at least one processor 1102, collectively and / or individually, may cause at least one of the PD 1001, the SD 1003, or the system 1100, to perform the method 1200.

[0077] In an embodiment, at operation 1201, the instructions stored in the memory 1104, when executed by at least one processor 1102, collectively and / or individually, may cause at least one of the PD 1001, the SD 1003, or the system 1100, to transmit a request to the MDE server 1007 via one of a plurality of communication protocols.

[0078] In an embodiment, the transmitting module 1110 may transmit the request to the MDE server 1007 using either the http / s communication protocol or the gRPC communication protocol. The request may comprise a tag indicating the request for one of a call forking session and a text based session. The text based session may include but is not limited to text messages and web messages.

[0079] In an embodiment, the instructions stored in the memory 1104, when executed by at least one processor 1102, collectively and / or individually, may cause at least one of the PD 1001, the SD 1003, or the system 1100, to transmit the request to the MDE server 1007 using either the http / s communication protocol or the gRPC communication protocol.

[0080] Accordingly, the transmitted request. In a further embodiment, the transmitting module 1110 may transmit the request using the gRPC communication protocol, when the request corresponds to the call forking session.

[0081] In an embodiment, the instructions stored in the memory 1104, when executed by at least one processor 1102, collectively and / or individually, may cause at least one of the PD 1001, the SD 1003, or the system 1100, to transmit the request using the gRPC communication protocol, when the request corresponds to the call forking session.

[0082] Thereafter, at operation 1203, the method 1200 may include receiving the one or more notification messages from the MDE server 1007 using the communication protocol used for transmitting the request. For example, if the request was transmitted using the gRPC communication protocol, then the receiving module 1112 may receive one or more notification messages from the MDE server 1007 using the gRPC communication protocol. On the other hand, if the request was transmitted using the http / s communication protocol, then the receiving module 1112 may receive one or more notification messages from the MDE server 1007 using the http / s communication protocol.

[0083] In an embodiment, at operation 1203, the instructions stored in the memory 1104, when executed by at least one processor 1102, collectively and / or individually, may cause at least one of the PD 1001, the SD 1003, or the system 1100, to receive the one or more notification messages from the MDE server 1007 using the communication protocol used for transmitting the request.

[0084] In an embodiment, the one or more notification messages comprise one of the call forking session and the text based session indication to the client device i.e., the PD 1001 or the SD 1103. In particular, one or more notification messages notify the client device 1001 and / or 1003 whether the MDE session is the call forking session or the text-based session. Further, in an embodiment, when the one or more notification messages correspond to the call forking session, the one or more notification messages may comprise one or more JavaScript Object Notation (JSON) wrapped SIP messages. The one or more notification messages may further correspond to one of a push notification messages or OK Server Sent Events (OkSSE).

[0085] Further, the establishing module 1114 may establish the MDE session with a caller device, such as the remote device 1005 based on one of the call forking session and the text based session and using the JSON wrapped SIP messages. In an embodiment, the establishing module 1114 may include an SIP decoder to decode the JSON wrapped SIP messages into SIP messages to establish the MDE session.

[0086] In an embodiment, the instructions stored in the memory 1104, when executed by at least one processor 1102, collectively and / or individually, may cause at least one of the PD 1001, the SD 1003, or the system 1100, to establish the MDE session with a caller device, such as the remote device 1005 based on one of the call forking session and the text based session and using the JSON wrapped SIP messages.

[0087] In an embodiment, the instructions stored in the memory 1104, when executed by at least one processor 1102, collectively and / or individually, may cause at least one of the PD 1001, the SD 1003, or the system 1100, to decode the JSON wrapped SIP messages into SIP messages to establish the MDE session.

[0088] In an embodiment, the client device 1001 and / or 1003 subscribes to only one server, i.e., the MDE server 1007 for the purpose of both call and message syncing. Further, the client device 1001 and / or 1003 may use the one or more notification messages to establish the MDE session. In an embodiment, the converting module 1116 may include an SIP encoder to convert the one or more SIP messages to the JSON wrapped SIP messages. The method 1200 has been further explained in reference to FIG. 14.

[0089] In an embodiment, the instructions stored in the memory 1104, when executed by at least one processor 1102, collectively and / or individually, may cause at least one of the PD 1001, the SD 1003, or the system 1100, to convert the one or more SIP messages to the JSON wrapped SIP messages.

[0090] Referring now to FIG. 13, at operation 1301, the method 1300 may include transmitting a request to the MDE server 1007 via one of the plurality of communication protocols. In an embodiment, the transmitting module 1110 may transmit the request in accordance with techniques as described in reference to FIG. 12.

[0091] In an embodiment, the instructions stored in the memory 1104, when executed by at least one processor 1102, collectively and / or individually, may cause at least one of the PD 1001, the SD 1003, or the system 1100, to perform the method 1300.

[0092] Then, at operation 1303, the method 1300 may include receiving one or more SIP messages from the caller device 1105 when the request corresponds to the call forking session.

[0093] In an embodiment, at operation 1303, the instructions stored in the memory 1104, when executed by at least one processor 1102, collectively and / or individually, may cause at least one of the PD 1001, the SD 1003, or the system 1100, to receive one or more SIP messages from the caller device 1105 when the request corresponds to the call forking session.

[0094] In an embodiment, the receiving module 1112 may receive the one or more SIP messages in accordance with techniques known in the art. In an embodiment, the one or more SIP messages may correspond to the SIP messages related to the call forking session as per the techniques known in the art.

[0095] In an embodiment, the instructions stored in the memory 1104, when executed by at least one processor 1102, collectively and / or individually, may cause at least one of the PD 1001, the SD 1003, or the system 1100, to receive the one or more SIP messages in accordance with techniques known in the art.

[0096] Thereafter, at operation 1305, the method 1300 may include converting the one or more SIP messages to JSON wrapped SIP messages. In an embodiment, the converting module 1116 may convert the one or more SIP messages to the JSON wrapped SIP messages to establish the call forking session between the PD 1001 and the SD 1003. In an embodiment, the converting module 1116 may include an SIP encoder to convert the one or more SIP messages to the JSON wrapped SIP messages.

[0097] In an embodiment, at operation 1305, the instructions stored in the memory 1104, when executed by at least one processor 1102, collectively and / or individually, may cause at least one of the PD 1001, the SD 1003, or the system 1100, to convert the one or more SIP messages to JSON wrapped SIP messages.

[0098] In an embodiment, the instructions stored in the memory 1104, when executed by at least one processor 1102, collectively and / or individually, may cause at least one of the PD 1001, the SD 1003, or the system 1100, to convert the one or more SIP messages to the JSON wrapped SIP messages to establish the call forking session between the PD 1001 and the SD 1003.

[0099] In an embodiment, the instructions stored in the memory 1104, when executed by at least one processor 1102, collectively and / or individually, may cause at least one of the PD 1001, the SD 1003, or the system 1100, to convert the one or more SIP messages to the JSON wrapped SIP messages to convert the one or more SIP messages to the JSON wrapped SIP messages.

[0100] Then, at operation 1307, the method 1300 may include transmitting the JSON wrapped messages to the MDE server 1007. The JSON wrapped messages may be used in establishing the MDE session. The method 1300 has been further explained in reference to FIG. 14.

[0101] In an embodiment, at operation 1305, the instructions stored in the memory 1104, when executed by at least one processor 1102, collectively and / or individually, may cause at least one of the PD 1001, the SD 1003, or the system 1100, to transmit the JSON wrapped messages to the MDE server 1007.

[0102] FIG. 14 illustrates a signal flow diagram 1400 showingestablishing the MDE session in the MDE, in accordance with one or more embodiments of the disclosure. As shown, at operations 1401 and 1403, both the PD 1001 and the SD 1003 send a request to the MDE server 1007 to subscribe for the call forking session and the text-based session.

[0103] In an embodiment, at operations 1401 and 1403, the instructions stored in the memory 1104, when executed by at least one processor 1102, collectively and / or individually, may cause at least one of the PD 1001, the SD 1003, or the system 1100, to send a request to the MDE server 1007 to subscribe for the call forking session and the text-based session.

[0104] In an embodiment, both the PD 1001 and the SD 1003 subscribe to the MDE server 1007 for the call forking session and the text-based session via the http / s communication protocol. In an embodiment, the request at operations 1401 and 1403 is transmitted in accordance with techniques described in reference to FIG. 12. As a result, SIP registration with the P-CSCF following the IMS procedure is not required. This eliminates the need for keep-alive messages to maintain the SIP signaling session, thereby conserving battery power.

[0105] In an embodiment, at operation 1405, an operator server 1009 sends an SIP Invite message to the PD 1001. In an embodiment, the operator server 1009 is associated with the remote device 1005.

[0106] In an embodiment, at operation 1407, the PD 1001 encodes the SIP invite message into JSON wrapped SIP message and sends the invite message to the MDE server 1007.

[0107] In an embodiment, at operation 1409, the MDE server 1007 forwards the invite message to the SD 1003.

[0108] In an embodiment, at operation 1411, the SD 1003 sends a 400 Trying message to the MDE server 1007.

[0109] In an embodiment, at operation 1413, the MDE server 1007 sends a 100 Trying message to the PD 1001. In an embodiment, the 100 Trying message is JSON wrapped SIP message.

[0110] In an embodiment, at operation 1415, the PD 1001 decodes the JSON wrapped SIP message into an SIP message and sends an SIP 100 trying message to the operator server 1009. In an embodiment, further signalling between the PD 1001, the MDE server 1007, and the SD 1003 are carried out with the gRPC communication protocol for the MDE session establishment.

[0111] In an embodiment, at operation 1417, a PD-MDE gRPC channel is established between the PD 1001 and the MDE server 1007.

[0112] In an embodiment, at operation 1419, an SD-MDE gRPC channel is established between the SD 1003 and the MDE server 1007. Hence, whenever the PD 1001 receives a new call from the remote device 1005, the call invite message is sent by the MDE server 1007 to the SD 1003 via the http / s communication protocol and not SIP. Further, a push message is sent with JSON wrapping the contents of the SIP message (example: Initial Invite packet, etc.) to the SD 1003. Hence, the communication between the PD 1001 and the operator server 1009 occurs using SIP. However, the communication between the PD 1001 and the SD 1003 occurs using JSON wrapped SIP messages through the MDE server 1007. Accordingly, the PD 1001 decodes the JSON wrapped SIP messages from the SD 1003 and exchanges them with the remote device 1005. Table 1 below illustrates the difference between the SIP message and the corresponding JSON wrapped SIP message:

[0113] Example of SIP messageExample of corresponding JSON wrapped SIP message.INVITE sip:callee@example.com SIP / 2.0Via: SIP / 2.0 / UDP client.example.com:5060;branch=z9hG4bKndededMax-Forwards: 70To: <sip:callee@example.com>From: "Caller" <sip:caller@example.net>;tag=12312889Call-ID: a84b4c76e66710@test33.texa.comCSeq: 314189 INVITEContact: <sip:caller@client.example.com>Content-Type: application / jsonContent-Length: ...{"customParam": "value","additional info": {"key": "data"}}{"sipMessage": {"method": "INVITE","uri": "sip:callee@example.com","headers": {"Via": "SIP / 2.0 / UDP client.example.com:5060;branch=z9hG4bKndeded","Max-Forwards": "70","To": "<sip:callee@example.com>","From": " / "Caller / " <sip:caller@example.net>;tag=12312889","Call-ID": "a84b4c76e66710@test33.texa.com","CSeq": "314189 INVITE","Contact": "<sip:caller@client.example.com>","Content-Type": "application / sdp"},"additionalInfo": {"customParam": "value","someMoreData": "..."}}

[0114] Referring to FIG. 14, at operation 1421, a Volte / Vilte call is established between the PD 1001 and the operator server 1009 using SIP messages. In an embodiment, at operation 1423, the MDE call, i.e. the call forking session is established between the PD 1001 and the SD 1003 through the MDE server 1007 and using the JSON wrapped SIP messages.

[0115] In an embodiment, at operation 1425, a gRPC channel is chosen for communication between the PD 1001 and the MDE server 1007.

[0116] In an embodiment, at operation 1427, a gRPC channel is chosen for communication between the SD 1003 and the MDE server 1007.

[0117] In an embodiment, at the time of terminating the call, at operation 1429, the SD 1007 sends a JSON wrapped SIP Bye message to the MDE server 1007.

[0118] In an embodiment, at operation 1431, the MDE server 1007 forwards the JSON wrapped SIP Bye message to the PD 1001.

[0119] In an embodiment, at operation 1433, the PD 1001 decodes the JSON wrapped SIP Bye message and sends an SIP Bye message to the operator server 1009.

[0120] In an embodiment, at operation 1435, the operator server 1009 sends an acknowledgment, i.e., a 400K message using SIP to the PD 1001.

[0121] In an embodiment, at operation 1437, the PD 1001 converts the acknowledgment into JSON wrapped SIP message, i.e., a 200 OK message, and forwards the same to the MDE server 1007.

[0122] In an embodiment, at operation 1439, the MDE server 1007 forwards the 200 OK message to the SD 1003. Hence, the call is terminated.

[0123] It is important to note that although FIG. 14 has been explained with reference to a call received by the PD 1001, the signal flow described in FIG. 14 is equally applicable to the SD 1003 when the call is received on the SD 1003. In this scenario, the SD 1003 will handle the encoding and decoding of messages required for the call forking session. Additionally, in the case of a text-based session, a similar process, as described with reference to FIG. 14, will apply.

[0124] Hence, SIP messages wrapped in JSON for call signalling between the PD 1001 and the MDE server 1007 are exchanged between the PD 1001 and the SD 1003 through the MDE server 1007. SIP Messages received from the remote device 1005 are encoded to the JSON wrapped SIP messages to send to the SD 1003. Further, SIP Messages received from the SD 1003 are decoded to SIP messages to send back to the remote device 1005.

[0125] FIG. 15A illustrates message and call subscription flow impact in the MDE on a client device 1001 and / or 1003, in accordance with related art. FIG. 15B illustrates the message and call subscription flow impact in the MDE on the client device 1001 and / or 1003, in accordance with one or more embodiments of the disclosure. As shown in FIG. 15A, in the existing system, the P-CSCF server serves as the entry point for both PD and SD devices to facilitate call forking. Both devices maintain an "SIP Register for call" using a keep-alive mechanism with the P-CSCF server. This server, in turn, connects to other TAS server nodes. Additionally, the devices subscribe to the NMS server for message synchronization. When new information becomes available, the NMS server pushes updates to the clients via a Push Notification Server. PD / SD can then fetch additional details directly from the NMS server as needed. On the other hand, as shown in FIG. 15B, SIP registration for calls with the P-CSCF server is eliminated, thereby avoiding the need for a keep-alive mechanism. PD / SD, in addition to their existing subscription to the NMS (MDE) server, introduces a new service subscription specifically for "Call Forking." Whenever new call information becomes available on the NMS server, it is pushed to the PD / SD via the existing Push Notification Server. SIP-based call messages are encapsulated in JSON format, enabling the call paging message to carry any of these JSON-wrapped SIP messages, such as INVITE, 100 Trying, CANCEL, or BYE. To facilitate this process, a SIP-JSON encoder / decoder is integrated into the system 1100. Additionally, http / s and gRPC transactions are enabled to support signaling flows for call forking.

[0126] FIG. 16A illustrates a signal flow diagram 1600A showing subscription flow impact in the MDE, in accordance with related art. FIG. 16B illustrates a signal flow diagram 1600B showing subscription flow impact, in accordance with one or more embodiments of the disclosure. As shown in FIG. 16A, both the PD and the SD maintain the SIP Register for calls using the keep-alive mechanism with the P-CSCF server through operations 1601-1607. Further, the PD and SD also subscribe to the NMS for the purpose of Message sync through operations 1609-1615. In particular, at operation 1601, the PD sends a register request to the P-CSCF server. In response, at operation 1603, the P-CSCF server sends an acknowledgment, i.e., a 200 OK message to the PD. Similarly, at operation 1605, the SD sends a register request to the P-CSCF server. In response, at operation 1607, the P-CSCF server sends an acknowledgment, i.e., a 200 OK message to the SD. At operation 1609, the PD sends a subscription request to the NMS server. In response, at operation 1611, the NMS server sends an acknowledgment, i.e., a 200 OK message to the PD. Similarly, at operation 1613, the SD sends a subscription request to the NMS server. In response, at operation 1615, the NMS server sends an acknowledgment, i.e., a 200 OK message to the SD. On the other hand, as shown in FIG. 16B, both the PD 1001 and the SD 1003 do not maintain an SIP register for calls, meaning the keep-alive function no longer exists. Instead, the PD 1001 and the SD 1003 subscribe to the MDE server 1007 for message synchronization and call forking purposes. As a result, the same HTTP dedicated channel is reused for both message and call synchronization. In particular, at operation 1617, the PD 1001 sends a subscription request (for calls and messages) to the MDE server 1007. In response, at operation 1619, the MDE server 1007 sends an acknowledgment, i.e., a 200 OK message to the PD 1001. Similarly, at operation 1621, the SD 1003 sends the subscription request to the MDE server 1007. In response, at operation 1623, the MDE server 1007 sends an acknowledgment, i.e., a 200 OK message to the SD 1003.

[0127] In an existing technique, when the remote device calls the PD, the PD generates a new incoming SIP invite and sends it to the SDs through the SIP dedicated channel. The call rings on both the PD and SD, and the user can accept the call on either device. Once accepted, the call is established. Overall, SIP message transactions are used to establish the call. This process has been explained with reference to FIG. 9. On the other hand, in an embodiment, when the remote device 1005 calls the PD 1001, the PD 1001 creates a new incoming SIP invite and sends it to the SD 1003. However, instead of using a dedicated SIP channel, the invite is wrapped in JSON format and transmitted through the existing HTTP stack. To facilitate the exchange of SIP messages, a gRPC channel is established until the call is successfully set up. The call will ring on both the PD 1001 and the SD 1003, allowing the user to accept the call on either device. Once accepted, the call is established. This process has been explained with reference to FIG. 14. Hence, SIP messages over the existing HTTP stack are used to establish the call.

[0128] FIG. 17A illustrates a signal flow diagram 1700A showing a Primary Device (PD) outgoing call flow impact in the MDE, in accordance with related art. FIG. 17B illustrates a signal flow diagram 1700B showing the PD going call flow impact in the MDE, in accordance with one or more embodiments of the disclosure. As shown in FIG. 17A, when the PD initiates a call to a remote device, a SIP invite is sent through the operator network. Once the call is connected, the call states are communicated to the connected or available devices through a SIP Publish message. This call state indication allows the user to pull the ongoing call to these devices. In this process, SIP messages over the dedicated SIP channel are used to establish the call. In particular, at operations 1701 and 1703, the PD and the SD maintain a keep-alive mechanism with the P-CSCF server. At operations 1705 and 1707, the PD and SD send a subscription request to the NMS server. At operation 1709, the PD makes a call to a remote device. Accordingly, at operation 1711, the PD sends a SIP invite to the remote device. In response, at operation 1713, the remote device sends an acknowledgment, i.e., a 200 OK message to the PD. Accordingly, at operation 1715, the call is established between the PD and the remote device. In order to transfer the call to the SD, at operation 1717, the PD publishes the call to the P-CSCF server. At operation 1719, the P-CSCF server publishes the call to the SD. In response, at operation 1721, the SD sends an acknowledgment, i.e., a 200 OK message to the P-CSCF server. Then, at operation 1723, the P-CSCF server forwards the acknowledgment to the PD. Accordingly, at operation 1725, a Call Pull Notification is displayed on the SD.

[0129] On the other hand, as shown in FIG. 17B, when the PD 1001 calls the remote device 1005, the PD 1001 creates a new incoming SIP invite and sends it to the SD 1003 via the existing HTTP stack channel. After the call is connected, the call states are communicated to the connected or available devices through the same SIP Publish message, but wrapped in JSON format for transmission over the HTTP channel. This call state indication allows the user to pull the ongoing call to these devices. In this process, the same SIP message, wrapped in JSON, is exchanged between the PD 1001 and the SD 1003 over the existing HTTP channel instead of the dedicated SIP channel. In particular, at operations 1727 and 1729, the PD 1001 and the SD 1003 send a subscription request to the MDE server 1007. At operation 1731, the PD 1001 makes a call to the remote device 1005. Accordingly, at operation 1733, the PD 1001 sends a SIP invite to the remote device 1005. In response, at operation 1735, the remote device 1005 sends an acknowledgment, i.e., a 200 OK message to the PD 1001. Accordingly, at operation 1737, the call is established between the PD 1001 and the remote device 1005. In order to transfer the call to the SD 1003, at operation 1739, the PD publishes the call to the MDE server 1007 using JSON wrapped SIP message. At operation 1741, the MDE server 1007 publishes the call to the SD 1003 using the JSON wrapped SIP message JSON wrapped SIP message. In response, at operation 1743, the SD 1003 sends an acknowledgment, i.e., a 200 OK message to the MDE server 1007. Then, at operation 1745, the MDE server 1007 forwards the acknowledgment to the PD 1001. Accordingly, at operation 1747, a Call Pull Notification is displayed on the SD 1001.

[0130] Further, in existing techniques, both the PD and the SD register with the P-CSCF server in the case of SIP communication via the P-CSCF server. When the SD initiates a call to a remote device through the MDE network, the SD sends a SIP INVITE directly to the P-CSCF server. This message is then routed to the PD, which forwards it to the remote device over a dedicated SIP channel, establishing the call session. On the other hand, in accordance with the present disclosure, both the PD and the SD subscribe to the MDE server for HTTP-based communication via that MDE server, such as the NMS. When the SD initiates a call to the remote device through the MDE network, the SD sends SIP INVITE messages wrapped in JSON format to the MDE server. These messages are subsequently sent to the PD, where they are unwrapped and forwarded to the remote device over the existing HTTP stack, thus initiating the call session. Hence, while SIP messages in the existing techniques are transmitted over a dedicated SIP channel, the disclosed techniques involve wrapping SIP messages in JSON for transmission over the HTTP stack.

[0131] Further, in an embodiment, the present disclosure is primarily aimed at user light-weight, battery-sensitive SDs such as VST, watches, and other devices where maintaining a long TCP connection is costly in terms of battery consumption. Further, the disclosed techniques provide various advantages. For example, in the disclosed techniques, the deployment of an IMS server in intermediate proxy nodes is not required. Instead, the existing HTTP connection can be reused for message synchronization. Thus, the disclosed techniques avoid additional network and client device resource consumption for calls. Furthermore, the HTTP stack available on all the devices can be leveraged, and SIP parsing can be avoided, being done only at the endpoints. The new signaling flow is easy to deploy without the need for a SIP server. Further, the disclosed techniques result in reducing power consumption, especially in SDs.

[0132] FIG. 18 illustrates a block diagram of an exemplary electronic device 1800 capable of performing the operations described herein.

[0133] The electronic device 1800 may include the Primary Device (PD) 1001. The electronic device 1800 may include the Secondary Device (SD) 1003. The electronic device 1800 may include the Remote Device 1005. The electronic device 1800 may include the MDE server 1007. The electronic device 1800 may include the operator sever 1009.

[0134] Referring to FIG. 18, the electronic device 1800 may be one of various types of electronic devices, such as a notebook computer 1890, smartphones 1891 having various form factors (e.g., a bar-type smartphone 1891-1, a foldable smartphone 1891-2, or a slidable (or rollable) smartphone 1891-3), a tablet PC 1892, a cellular telephone (not shown), and any other similar computing devices (not shown). The components illustrated in FIG. 18, the relationships thereof, and the functions thereof are merely for illustration, and are not intended to limit the implementations described or claimed in the disclosure thereto. The electronic device 1800 may be referred to as a mobile device, a user equipment, a multifunctional device, a portable device, or a server.

[0135] The electronic device 1800 may comprise various components including at least one processor 1810 (hereinafter, the processor 1810), at least one memory 1820 (hereinafter, the memory 1820), at least one display 1840 (hereinafter, the display 1840), at least one image sensor 1850 (hereinafter, the image sensor 1850), at least one communication circuitry 1860 (hereinafter, the communication circuitry 1860), and / or at least one sensor 1870 (hereinafter, the sensor 1870). The aforementioned components are merely of an example. For example, the electronic device 1800 may comprise other components (e.g., a power management integrated circuitry (PMIC), an audio processing circuitry, an antenna, a rechargeable battery, or an input / output interface). For example, some components may be omitted from the electronic device (1800). For example, some components may be integrated into one component.

[0136] The processor 1810 may be implemented as one or more integrated circuit (or circuitry) (IC) chips and may perform various data processing. The processor 1810 may include at least one electrical circuitry and may process instructions (or program, data, and so on) stored in the memory 1820 individually or collectively in a distributed manner. The processor 1810 may include a processor assembly that includes one or more processing circuitries. The processor may include any processing circuitry that may be operative for controlling operations and performance of one or more components (e.g., the memory 1820, a display 1840, the image sensor 1850, the communication circuitry 1860, and / or the sensor 1870) of the electronic device. For example, the processor 1810 (e.g., an application processor (AP)) may be implemented as a system on chip (SoC) (e.g., one chip or chipset). For example, the processor 1810 may be implemented as a plurality of cores (or at least one core circuitry), a plurality of chips, or a plurality of chipsets. For example, the processor 1810 may comprise one or more processing circuitry. For example, the processor 1810 may comprise one or more processing circuitry which are individually and / or collectively configured to perform various functions of the present disclosure. As a non-limiting example, at least a portion of the processor 1810 may be included in a first chip of the electronic device 1800 and at least another portion of the processor 1810 may be included in a second chip of the electronic device 1800 different from the first chip of the electronic device 1800.

[0137] For example, the processor 1810 may comprise a central processing unit (CPU) 1811, a graphics processing unit (GPU) 1812, a neural processing unit (NPU) 1813, an image signal processor (ISP) 1814, a display controller 1815, a memory controller 1816, a storage controller 1817, a communication processor (CP) 1818, and / or a sensor interface 1819. These components of the processor 1810 are merely of an example. For example, the processor 1810 may further comprise other components. For example, some components of the processor 1810 may be omitted from the processor 1810. For example, some components of the processor 1810 may be included as separate components of the electronic device 1800 outside the processor 1810. For example, some components of the processor 1810 (e.g., the memory controller 1816) may be included in other components of the electronic device 1800 (e.g., at least a portion of the memory 1820, an interface (e.g., usable for connecting to at least one component of the electronic device 1800), the display 1840, and / or the image sensor 1850).

[0138] The processor 1810 may cause other components of the electronic device 1800 to perform various operations by executing instructions stored in the memory 1820. The CPU 1811 (or a central processing circuitry) may be configured to control the components of the processor 1810 based on execution of instructions stored in the memory 1820 (e.g., the volatile memory 1821 and / or the non-volatile memory 1822). The GPU 1812 (or a graphic processing circuitry) may be configured to execute parallel computations (e.g., rendering). The NPU 1813 (or a neural processing circuitry, or an artificial intelligence (AI) chip) may be configured to execute operations (e.g., convolution computations) for an artificial intelligence model. The ISP 1814 (or an image signal processing circuitry) may be configured to process a raw image obtained from the image sensor 1850 in a format suitable for a component in the electronic device 1800 or a component of the processor 1810. The display controller 1815 (or a display control circuitry, or a display processing unit (DPU)) may be configured to process an image obtained from the CPU 1811, the GPU 1812, the ISP 1814, or the memory 1820 (e.g., the volatile memory 1821) in a format suitable for the display 1840. The memory controller 1816 (or a memory control circuitry) may be configured to control reading data from the volatile memory 1821 and writing data to the volatile memory 1821. The storage controller 1817 (or a storage control circuitry) may be configured to control reading data from the non-volatile memory 1822 and writing data to the non-volatile memory 1822. The CP 1818 (or a communication processing circuitry) may be configured to process data obtained from a component of the processor 1810 in a format suitable for transmission to another electronic device via the communication circuitry 1860, or to process data obtained from another electronic device via the communication circuitry 1860 in a format suitable for processing of the component of the processor 1810. For example, the communication circuitry 1860 may comprise one or more communication circuitry. The sensor interface 1819 (or a sensing data processing circuitry, a sensor hub) may be configured to process data on a state of the electronic device 1800 and / or a state around the electronic device 1800, obtained through the sensor 1870, in a format suitable for a component of the processor 1810.

[0139] The memory 1820 may comprise one or more storage mediums (or one or more storage devices). For example, the memory 1820 may include a memory assembly that includes one or more storage mediums. For example, the one or more storage mediums may comprise a permanent memory (e.g., the non-volatile memory 1822) such as a hard drive, a flash memory, a read-only memory (ROM), a semi-permanent memory (e.g., the volatile memory 1821) such as a random access memory (RAM), a storage (or a storage assembly) of any other suitable type, or any combination thereof. The memory 1820 may comprise a cache memory which is a memory of one or more different types used to store data for performing a function or feature of the electronic device 1800 at least temporarily. As a non-limiting example, the cache memory may be included in the processor 1810. The memory 1820 may be fixedly embedded within the electronic device 1800, or may be incorporated onto one or more suitable types of components that may be repeatedly inserted into the electronic device 1800, and removed from the electronic device 1800 (e.g., a subscriber identity module (SIM) card, and / or a secure digital (SD) card).

[0140] For example, the memory 1820 may store one or more software applications such as an operating system (or a system) software application, a firmware software application, a driver software application, a plug-in (e.g., add-in, add-on, and / or applet) software application, and / or any other suitable software application. For example, the one or more software applications may include instructions executable by the processor 1810. For example, the memory 1820 may store instructions callable by an application programming interface (API). For example, the memory 1820 may store instructions in a library.

[0141] In this application, unless specifically stated otherwise, the use of the singular includes the plural, and the use of “or” means “and / or.” Furthermore, the use of the terms “including” or “having” is not limiting. Any range described herein will be understood to include the endpoints and all values between the endpoints. Features of the disclosed embodiments may be combined, rearranged, omitted, etc., within the scope of the invention to produce additional embodiments. Furthermore, certain features may sometimes be used to advantage without a corresponding use of other features.

[0142] While at least one exemplary embodiment has been presented in the foregoing detailed description, it should be appreciated that a vast number of variations exist.

Claims

1.A method for managing a Multi-Device Environment (MDE) session for a client device in a communication network, the method comprising:transmitting , by the client device, a request to an MDE server of the communication network via one of a plurality of communication protocols, wherein the request comprises a tag indicating the request for one of a call forking session and a text based session; andreceiving, by the client device, one or more notification messages from the MDE server using the communication protocol used for transmitting the request, wherein the one or more notification messages comprise one or more JavaScript Object Notation (JSON) wrapped Session Initiation Protocol (SIP) messages when the one or more notification messages correspond to the call forking session.2.The method of claim 1, wherein the plurality of communication protocols include a Hypertext Transfer Protocol Secure (http / s) communication protocol, and a Google Remote Procedure Call (gRPC) communication protocol.3.The method of claim 1, wherein transmitting the request to the MDE server comprises:transmitting the request using a gRPC communication protocol, when the request corresponds to the call forking session.4.The method of claim 1, wherein the one or more notification messages correspond to one of a push notification messages or OK Server Sent Events (OkSSE).5.The method of claim 1, wherein the one or more notification messages comprise one of the call forking session and the text based session indication to the client device.6.The method of claim 1, further comprising:establishing the MDE session with a caller device based on one of the call forking session and the text based session and using the JSON wrapped SIP messages.7.The method of claim 1, further comprising:receiving, by the client device, one or more SIP messages from a caller device when the request corresponds to the call forking session;converting the one or more SIP messages to JSON wrapped SIP messages; andtransmitting the JSON wrapped messages to the MDE server.8.An electronic device for managing a Multi-Device Environment (MDE) session for a client device in a communication network, the electronic device comprising:a communication circuit;memory storing instructions; andat least one processor;wherein the instructions, when executed by at least one processor, collectively and / or individually, cause the electronic device to:transmit a request to an MDE server of the communication network via one of a plurality of communication protocols, wherein the request comprises a tag indicating the request for one of a call forking session and a text based session; andreceive one or more notification messages from the MDE server using the communication protocol used for transmitting the request, wherein the one or more notification messages comprise one or more JavaScript Object Notation (JSON) wrapped Session Initiation Protocol (SIP) messages when the one or more notification messages correspond to the call forking session.9.The electronic device of claim 8, wherein the plurality of communication protocols include a Hypertext Transfer Protocol Secure (http / s) communication protocol, and a Google Remote Procedure Call (gRPC) communication protocol.10.The electronic device of claim 8, wherein the instructions, when executed by at least one processor, collectively and / or individually, cause the electronic device to transmit the request to the MDE server using a gRPC communication protocol when the request corresponds to the call forking session.11.The electronic device of claim 8, wherein the one or more notification messages correspond to one of a push notification messages or OK Server Sent Events (OkSSE).12.The electronic device of claim 8, wherein the one or more notification messages comprise one of the call forking session and the text based session indication to the client device.13.The electronic device of claim 8, wherein the instructions, when executed by at least one processor, collectively and / or individually, cause the electronic device to establish the MDE session with a caller device based on one of the call forking session and the text based session and using the JSON wrapped SIP messages.14.The electronic device of claim 8, wherein the instructions, when executed by at least one processor, collectively and / or individually, cause the electronic device to:receive one or more SIP messages from a caller device when the request corresponds to the call forking session;convert the one or more SIP messages to JSON wrapped SIP messages; andtransmit the JSON wrapped messages to the MDE server.

Images