Abstract: The present invention provides a method for enhancing multi-party call procedure in a code division multiple access (CDMA) network. In one embodiment, the method comprises the steps of: receiving, by a base station, a flash with information message (FWIM) message from a user equipment (UE), wherein the FWIM message comprises information on a multi-party call enhancement operation to be performed on the UE, performing the multi-party call enhancement operation on the UE in response to the FWIM message received from the UE, and indicating the performed multi-party call enhancement operation on the UE. The multi-party call enhancement operation comprises one of a call switching, call merging, call rejecting/releasing and call answering. Figure 1
CLIAMS:
1. A method of enhancing multi-party call procedure in a code division multiple access (CDMA) network, the method comprising the steps of:
receiving, by a base station, a flash with information message (FWIM) message from a user equipment (UE), wherein the FWIM message comprises information of a multi-party call enhancement operation to be performed on the UE;
performing the multi-party call enhancement operation on the UE in response to the FWIM message received from the UE; and
indicating the performed multi-party call enhancement operation on the UE.
2. The method as claimed in claim 1, wherein the multi-party call enhancement operation comprises of switching of calls between an ongoing call and an outgoing call initiated by the UE.
3. The method as claimed in claim 1, wherein the multi-party call enhancement operation comprises of merging of calls between an ongoing call and at least one call waiting call.
4. The method as claimed in claim 1, wherein the multi-party call enhancement operation comprises of releasing of a call from a conference call.
5. The method as claimed in claim 1, wherein the multi-party call enhancement operation comprises of answering a call waiting call when the UE is in an active call.
6. The method as claimed in claim 1, wherein the multi-party call enhancement operation comprises of rejecting an incoming call when the UE is in an active call.
7. A method of enhancing multi-party call procedure in a code division multiple access (CDMA) network, the method comprising the steps of:
sending a flash with information message (FWIM) message by a user equipment (UE), wherein the FWIM message comprises information on a multi-party call enhancement operation to be performed on the UE;
receiving a response from a base station; and
performing the multi-party call enhancement operation based on response received from a base station.
8. A user equipment for enhancing multi-party call procedure in a code division multiple access (CDMA) network, comprising:
a processor;
a memory coupled to the processor, wherein the memory comprises a flash with information message (FWIM) message generation module and a multi-party call enhancement module; and wherein the FWIM message generation module instructs the processor for sending a flash with information message (FWIM) message to a base station; and wherein the FWIM message comprises information on a multi-party call enhancement operation to be performed on the UE; and wherein the multi-party call management module instructs the processor for performing the multi-party call enhancement operation on the UE in response to the FWIM message received from the UE.
9. The user equipment as claimed in claim 8, wherein multi-party call enhancement module further instructs the processor to perform switching of calls between an ongoing call and an outgoing call initiated by the UE.
10. The user equipment as claimed in claim 8, wherein multi-party call enhancement module further instructs the processor to perform merging of calls between an ongoing call and at least one call-waiting call.
11. The user equipment as claimed in claim 8, wherein multi-party call enhancement module further instructs the processor to perform releasing of a call from a conference call.
12. The user equipment as claimed in claim 8, wherein multi-party call enhancement module further instructs the processor to perform answering a call waiting call when the UE is in an active call.
13. The user equipment as claimed in claim 8, wherein multi-party call enhancement module further instructs the processor to perform rejecting an incoming call when the UE is in an active call. ,TagSPECI:FIELD OF THE INVENTION
The present invention relates to the field of wireless communications, and more particularly relates to a method of enhancing multi-party call procedure in a code division multiple access (CDMA) network.
BACKGROUND OF THE INVENTION
The code division multiple access (CDMA) network provides users with features like call waiting and conference call to enable multiple user interactions or multi-party calling. The standards for code division multiple access (CDMA) systems including IS-95A, IS-95B and IS-2000 support multi-party calling. In multi-party calling, while a call is in progress, a subscriber can place or receive another call to or from a third party.
In a CDMA system, call switching during multi-party calling proceeds as follows: First, it is assumed that a first mobile terminal is in call active state for conversation with a second mobile terminal through a base station, and a third mobile terminal, trying to communicate or have a conversation with the first mobile terminal, is connected to the first mobile terminal and remain in call waiting state. To initiate a conversation with a third party during a call, the first mobile terminal sends a Flash With Information Message (FWIM) as a request signal to the base station. The base station sends a reply to the first mobile terminal and places the call between the third mobile terminal and the first mobile terminal in call active state.
However with the current implementation, there are certain limitations to these features. First, when the first mobile terminal is in communication with the second mobile terminal and the third mobile terminal attempts to communicate with the first mobile terminal, the third mobile terminal receives only call waiting indication. The first mobile terminal can only swap the call with the third mobile terminal, but there is no way that the first mobile terminal can merge call with both the second mobile terminal and the third mobile terminal.
Second, when the first mobile terminal, which is conversation with the second mobile terminal, decides to enter into a conference call with the second mobile terminal and third mobile terminal, puts call with the second mobile terminal on hold state, dials third mobile terminal to enter into conversation and merges call with the second mobile terminal to enter into the conference call with the second mobile terminal and third mobile terminal. The problem is, the first mobile terminal can only merge the call but cannot swap the call between two mobile terminals.
Third, when the first mobile terminal is in conference call with the second mobile terminal and the third mobile, terminal and if the first mobile terminal wishes to terminate the call with any of the mobile terminal, then it is not possible to drop the call with the particular mobile terminal and there is no mechanism to inform other mobile terminals in the conference call, via transmission of a release message, about releasing the particular mobile terminal.
Therefore, there is need for a method to enhance multi-party call procedure using Flash With Information message (FWIM) in a code division multiple access (CDMA) network.
SUMMARY OF THE INVENTION
The present invention relates to a method to enhance multi-party call procedure using Flash with Information message (FWIM) in a code division multiple access (CDMA) network to address the problems mentioned herein above. Apart from addressing the above mentioned problems, the present invention also provides a unified approach to all multi-party calling operations such as, but not limited to, answering a call, which is call waiting state, rejecting the call waiting call, selectively swapping between calls, merging plurality of calls to enter into conference state, and the like. The present invention provides easy and efficient method to mobile terminals by implementing the unified approach to all multi-party calling scenarios.
In accordance with an exemplary embodiment of the present invention, there is provided a method for enhancing multi-party call procedure in a code division multiple access (CDMA) network, wherein a base station receives a flash with information message (FWIM) message from a user equipment (UE), wherein the UE requests the base station for accessing multi-party call enhancing feature. The FWIM message transmitted by the UE comprises a multi-party call enhancement operation to be performed on the UE. The base station performs the multi-party call enhancement operation on the UE in response to the FWIM message received from the UE. The base station further indicates the UE with the performed multi-party call enhancement operation.
In an embodiment, the FWIM value is a binary value representing multi-party call enhancing services such as, but not limited to, answering the call, rejecting the call, merging the call, swapping the call, and the like.
These and other embodiments of the present invention will become apparent to those skilled in the art from the following brief description, which, taken in conjunction with the drawings of the present invention.
BRIEF DESCRIPTION OF THE ACCOMPANYING DRAWINGS
Figure 1 is a block diagram illustrating exemplary user equipment (UE) 100 showing various components for implementing embodiments of the present subject matter.
Figure 2 is a flowchart diagram illustrating an exemplary method of enhancing a
multi-party call procedure in a code division multiple access (CDMA) network, according to one embodiment.
Figure 3A to 3D are tabular representation illustrating a format of flash with information message (FWIM) used for enhancing multi-party call procedure, according to one embodiment.
Figure 4 is a flow diagram illustrating an exemplary process of swapping of calls using FWIM message, according to one embodiment.
Figure 5 is a flow diagram illustrating an exemplary process of merging of calls using FWIM message, according to one embodiment.
Figure 6 is a flow diagram illustrating releasing of a call by user equipment while the UE is in conference call, according to one embodiment.
Figure 7 is a flow diagram illustrating releasing of a call by user equipment while the UE is in conference call, according to another embodiment.
The drawings described herein are for illustration purposes only and are not intended to limit the scope of the present disclosure in any way.
DETAILED DESCRIPTION OF THE INVENTION
The embodiments of the present invention will now be described in detail with reference to the accompanying drawings. However, the present invention is not limited to the embodiments. The present invention can be modified in various forms. Thus, the embodiments of the present invention are only provided to explain more clearly the present invention to the ordinarily skilled in the art of the present invention. In the accompanying drawings, like reference numerals are used to indicate like components.
The specification may refer to “an”, “one” or “some” embodiment(s) in several locations. This does not necessarily imply that each such reference is to the same embodiment(s), or that the feature only applies to a single embodiment. Single features of different embodiments may also be combined to provide other embodiments.
As used herein, the singular forms “a”, “an” and “the” are intended to include the plural forms as well, unless expressly stated otherwise. It will be further understood that the terms “includes”, “comprises”, “including” and/or “comprising” when used in this specification, specify the presence of stated features, integers, steps, operations, elements and/or components, but do not preclude the presence or addition of one or more other features integers, steps, operations, elements, components, and/or groups thereof. It will be understood that when an element is referred to as being “connected” or “coupled” to another element, it can be directly connected or coupled to the other element or intervening elements may be present. Furthermore, “connected” or “coupled” as used herein may include operatively connected or coupled. As used herein, the term “and/or” includes any and all combinations and arrangements of one or more of the associated listed items.
Unless otherwise defined, all terms (including technical and scientific terms) used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this disclosure pertains. It will be further understood that terms, such as those defined in commonly used dictionaries, should be interpreted as having a meaning that is consistent with their meaning in the context of the relevant art and will not be interpreted in an idealized or overly formal sense unless expressly so defined herein.
Figure 1 is a block diagram illustrating exemplary user equipment (UE) 100 showing various components for implementing embodiments of the present subject matter. The user equipment 100 may be a mobile phone, smart phone, personal digital assistant, tablet, phablet, and the like. The user equipment 100 is capable of making multiple calls at a time.
In the example shown in Figure 1, the user equipment 100 includes one or more processors 102, a network interface 104, a storage device 110, a memory 112, and a display 106. In addition, the display 106 includes a user interface 108. The memory 112 further comprises a flash with information message (FWIM) message generation module 114 and a multi-party call management module 116.
The UE 100 may include additional components not shown in Figure 1 for purposes of clarity. For example, the UE 100 may also include a microphone and speaker. The UE 100 may also include a battery that provides power to the components of the UE 100. The UE 100 may also include other user interface components, such as a keypad, trackball, joystick, or other such user interfaces that allow the user to interact with the UE 100. Moreover, the components of the UE 100 shown in Figure 1 may not be necessary in every example of the UE 100.
The processor 102 may be configured to implement functionality and/or process instructions for execution within the electronic device 102. The processor 102 may be capable of processing instructions stored in the memory or instructions stored on the storage device 110. The processor 102 may include any one or more of a microprocessor, a controller, a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or equivalent discrete or integrated logic circuitry. Additionally, the functions attributed to the processor 102, in this disclosure, may be embodied as software, firmware, hardware or any combination thereof.
The storage device 110 may include one or more computer-readable storage media. The storage device may include non-volatile storage elements. Examples of such non-volatile storage elements may include magnetic hard discs, optical discs, floppy discs, flash memories, or forms of electrically programmable memories (EPROM) or electrically erasable and programmable (EEPROM) memories. In addition, the storage device 110 may, in some examples, be considered a non-transitory computer-readable storage medium. The term “non-transitory” may indicate that the storage medium is not embodied in a carrier wave or a propagated signal. However, the term “non-transitory” should not be interpreted to mean that the storage device is non-movable. In some examples, the storage device 110 may be configured to store larger amounts of information than the memory 112. In certain examples, a non-transitory storage medium may store data that can, over time, change (e.g., in Random Access Memory (RAM) or cache).
The memory 112 may be configured to store information within the user equipment 100 during operation. The memory 112 may, in some examples, be described as a computer-readable storage medium. The memory may be described as a volatile memory, meaning that the memory 112 does not maintain stored contents when the computer is turned off. Examples of volatile memories include random access memories (RAM), dynamic random access memories (DRAM), static random access memories (SRAM), and other forms of volatile memories known in the art. In some examples, the memory 112 may be used to store program instructions for execution by processor 102. For example, the memory 112 includes a FWIM message generation module 114 and a multi-party call management module 116 stored in the form of program instructions for execution by the processor 102.
The flash with information message (FWIM) message generation module 114 is capable of sending/receiving FWIM messages to/from the base station. The FWIM message further has multi-party call enhancement operations to be performed on the UE. In some embodiments, the (FWIM) message generation module 114 generates and sends one or more FWIM messages to a base station (BS) and enables the BS to perform a multi-party call enhancement operation. The multi-party call enhancement operation may be one of call switching, call merging, call rejecting/releasing and call answering. The format of FWIM message is explained in detail in Figure 3A to 3D.
The multi-party call management module 116 is configured for managing multiple calls at the user equipment 100. Based on the FWIM message received from FWIM message generation module, the multi-party call management module 116 identifies multi-party call enhancement operation to be performed on the UE. The multi-party call enhancement operations being performed is listed in Figure 3B. For example, if the FWIM message received from the UE comprises a “CALL_TYPE” field as “ANSWER” with a value corresponding to “00”, the base station understands that the UE wants to answer a call and performs the action accordingly. In the same way, other actions are also performed by the base station.
The UE 100 may utilize network interface 104 to communicate with external devices via one or more networks, such as one or more wireless networks. The network interface 104 may be a network interface card, such as an Ethernet card, an optical transceiver, a radio frequency transceiver, or any other type of device that can send and receive information. Examples of such network interfaces may include Bluetooth®, 3G and WiFi® radios in mobile electronic devices as well as USB. Examples of such wireless networks may include WiFi®, Bluetooth®, and 3G. In some examples, the UE 100 may utilize the network interface 104 to wirelessly communicate with an external device (not shown) such as a server, mobile phone, or other networked electronic device.
The user interface (“UI”) 108 allows a user of the user equipment to interact with user equipment 100. The UI 108 may generate a graphical user interface (“GUI”) that allows a user to initiate commands. In some embodiments, the UI 108 generates a GUI that is displayed on touch sensitive screen (“touch screen”). The GUI may include one or more touch sensitive UI elements. For example, a user may be able to interact with the user equipment 100 and initiate a command by touching one or more of the touch sensitive UI elements displayed on touch sensitive screen. The touch sensitive screen may comprise of a variety of display devices such as a liquid crystal display (LCD), an e-ink display, a cathode ray tube (CRT), a plasma display, an organic light emitting diode (OLED) display, or another type of display device.
Figure 2 is a flowchart diagram illustrating an exemplary method of enhancing a multi-party call procedure in a code division multiple access (CDMA) network, according to one embodiment. At step 202, a flash with information message is received from user equipment (UE). The FWIM message is generally used for transmitting and receiving message between user equipment and a base station. Other types of message formats such as alert with information message (AWIM) can also be used for communication between the UE and the base station. The FWIM message further includes information for performing a multi-party call enhancement operation on the UE. The multi-party call enhancement operation may be one of call switching, call merging, call rejecting/releasing and call answering. At step 204, any of the above mentioned multi-party call enhancement operation is performed on the UE in response to the FWIM message received from the UE. At step 206, the performed multi-party call enhancement operation is indicated on the user equipment.
Figures 3A-3D illustrates tabular representation illustrating a format of flash with information message (FWIM) used for enhancing multi-party call procedure, according to one embodiment. Figure 3A illustrates different fields and size of the fields present in the FWIM message. Figure 3B illustrates different options for field “CALL_OPTION” and values associated with each option. Figure 3C illustrates different multi-party calling feature types in the FWIM. Figure 3D illustrates FWIM formats for different calling types mentioned in Figure 3C. The person ordinarily skilled in the art understands that the format, structure, values and options mentioned in the above mentioned figures are for the purpose of the illustration of exemplary embodiments, but not to limit the scope of the invention.
Figure 3A illustrates different fields and size of the fields present in the FWIM. The FWIM message comprises of fields “RECORD TYPE”, “RECORD_LEN”, “CALL_OPTION”, and “NUM_LEN”. As shown in Figure 3A, “RECORD TYPE” is of 8 bits length that represents multi-party calling option, “RECORD_LEN” is of 8 bits length, “CALL_OPTION” is of 2 bits length that represents multi-party calling options, and “NUM_LEN” is of 8 bits length.
Figure 3B illustrates different options for field “CALL_OPTION” from Figure 3A and values associated with each option. Different calling options are of type called “OPTION_TYPE”, indicating multi-party calling options provided to the user, associated with two digit binary values. The “OPTION_TYPE” can include multi-party call options ANSWER, RELEASE/ REJECT, SWAP and MERGE. The option ANSWER is for answering a call, associated with value 00. The option RELEASE/ REJECT is for rejecting the call associated with value 01. The option SWAP is for swapping calls between user equipment’s (UE’s), associated with value 10. The option MERGE is for merging two calls from different UE’s to form a conference call, associated with value 11.
In an embodiment, the “OPTION_TYPE” of “CALL_OPTION” field can comprise of one or more of other calling options, such as, but not limited to, keeping call with one or more UE’s on mute, recording the call, and the like. In another embodiment, the value associated with call options can be, but not limited to, two or more digit binary number, ASCII number, natural number and the like.
Figure 3C illustrates different multi-party calling feature types in the FWIM. Different features of multi-party calling can be of type FEATURE associated with OTA. The feature, ANSWER is associated with OTA as FWIM_0. The feature, RELEASE/ REJECT is associated with OTA as FWIM_1. The feature, SWAP is associated with OTA as FWIM_2. The feature, MERGE is associated with OTA as FWIM_3.
Figure 3D illustrates FWIM formats for different calling feature types mentioned in Figure 3C. For each feature associated with FWIM type being described in Figure 3C, FWIM Format is described in detail in Figure 3D. The FWIM Format comprises of all necessary values, options and data length that is required for executing particular option in multi-party calling. The FWIM Format describes the FWIM message transmitted by the UE to the base station for accessing particular multi-party calling feature.
FWIM Type FWIM_0 comprises of FWIM Format with fields and values as, Msg Id = RTC- Flash With Information, RECORD TYPE = 36, wherein value 36 indicates multi-party calling option, RECORD_LEN = 12, CALL_OPTION = 00, wherein value 00 indicates option for answering a call, NUM_LEN = 10, and Chari = ASCII representation of the MDN of UE answered. The FWIM message with the following format transmitted from an UE is being received by base station, calling option is identified as answering the call and the base station allows the UE to answer the call.
FWIM Type FWIM_1 comprises of FWIM Format with fields and values as, Msg Id = RTC- Flash With Information, RECORD_LEN = 12, CALL_OPTION = 01, wherein value 01 indicates option for releasing or rejecting the call, NUM_LEN = 10, and Chari = ASCII representation of the MDN of UE answered. The FWIM message with the following format transmitted from an UE is being received by base station, calling option is identified as releasing or rejecting the call and the base station allows the UE to reject the call.
FWIM Type FWIM_2 comprises of FWIM Format with fields and values as, Msg Id = RTC- Flash With Information, RECORD_LEN = 1, and CALL_OPTION = 10, wherein value 10 indicates option for swapping calls between the UE’s, wherein one call is in call active state and the other UE is in call waiting state. The FWIM message with the following format transmitted from an UE is being received by base station, calling option is identified as swapping the call and the base station allows the UE to swap the call.
FWIM Type FWIM_3 comprises of FWIM Format with fields and values as, Msg Id = RTC- Flash With Information, RECORD TYPE = 36, wherein value 36 indicates multi-party calling option, RECORD_LEN = 1, CALL_OPTION = 11, wherein value 11 indicates option for merging calls to allow conference calling. The FWIM message with the following format transmitted from an UE is being received by base station, calling option is identified as merging the call and the base station allows the UE to merge the call.
Figure 4 is an exemplary flow diagram 400 illustrating swapping of calls in a call waiting scenario using FWIM message, according to one embodiment. The present flow diagram illustrates how the base station receives FWIM message from a user equipment 1 (UE1) and allows swapping of calls for UE 1 when UE1 is in call active state with an UE 2 and wants to make a new call with UE 3.
As shown in Figure 4, UE 1 initiates a call conversation with UE 2 via a base station, wherein initiating call conversation consists of standard calling procedure, which includes receiving call initiation request signal from the UE 1 to start the conversation with UE 2, paging UE 2 by the base station regarding reception of an incoming call from UE 1, receiving response from UE 2 to accept the call initiation request and allowing the UE 1 and UE 2 to enter into conversation. Now, consider that UE 1 wants to make a new call with UE 3 while in conversation with UE 2. To achieve this, a user of the UE 1 opens the dial pad and dials a number associated with the UE 3. At the processor of UE 1, a FWIM message indicating that UE 1 wants to call UE 3 while in conversation with UE 2 is sent to the base station. The FWIM message comprises of fields such as “RECORD_TYPE”, “RECORD LENGTH”, “CALL_OPTION” and “NUM_LEN” as shown in Figure 3A. When the base station receives FWIM message with multi-party call options, it triggers an action at the base station. The base station analyzes the received FWIM message and identifies a value of “10” corresponding to “CALL_OPTION” field. The base station further identifies that the value “10” corresponds to a call swapping operation. Accordingly, the base station puts the conversation between UE 1 and UE 2 on hold and allows the UE 1 to get connected with UE 3.
In other words, the present invention provides a method to swap calls between an ongoing call and an outgoing call initiated by the user using new FWIM message. Similarly, the UE 1 swaps the call again with UE 2 by repeating the process mentioned above. This is illustrated in Figure 4. In another embodiment, the swapping of calls can be performed in a call waiting scenario also.
Figure 5 is an exemplary flow diagram 500 illustrating merging of calls in a call waiting scenario using FWIM message, according to one embodiment.
The present flow diagram illustrates how the base station receives FWIM message from a user equipment 1 (UE 1) and allows merging of calls for UE 1. Merging of calls can be carried out when UE 1 is in call active state with other UE 2 and receives an incoming call from UE 3. In other words, the UE1 itself wishes to have conference conversation and wishes to involve multiple UE’s at a time while UE 1 is already being in conversation with the other UE.
As shown in Figure 5, UE 1 is in call conversation with UE 2 via the base station. At the same time, UE 1 receives an incoming call from UE 3. The UE 1 upon receiving call request from the UE 3 sends a number of UE 3 along with FWIM message to base station, wherein the FWIM message comprises a merge call option to merge the incoming call from UE 3 with the ongoing call conversation between UE 1 and UE 2. The base station merges the call in response to the received FWIM message and enables a conference call between UE 1, UE 2, and UE 3. Accordingly, the performed merge option is indicated on the display of UE 1.
Figure 6 is an exemplary flow diagram illustrating releasing of a call by user equipment while the UE is in a conference call, according to one embodiment.
The flow diagram of the present embodiment illustrates how the base station receives FWIM message from a user equipment 1 (UE 1) and allows releasing of one of UE from the conference call/ conversation. UE 1 is in call active state with more than one UE and wishes to release one of the UE from the call active state to end the conversation with the respective UE.
As shown in Figure 6, UE 1 is in conference call with user equipment 2 (UE 2) and user equipment 3 (UE 3), wherein the process of entering conference call is as described herein above with respect to Figure 5. While in the conference call with UE 2 and UE 3, UE 1 wishes to terminate the call with UE 3, thereby to end the conference call for UE 3. As shown in the flow diagram, the UE 1 can release call with UE 3 and end conference call by sending FWIM message to a base station. The FWIM message comprises number of the UE 3 and a call option to release the call of UE 3. The base station sends a release order to UE 3 thereby disconnecting the UE 3 from the conference call.
Figure 7 is an exemplary flow diagram illustrating releasing of a call by user equipment while the UE is in conference call using FWIM message, according to another embodiment.
The flow diagram illustrates another embodiment about how the base station receives FWIM message from a user equipment 1 (UE 1) and allows releasing of an UE from the conference call/ conversation, which has transmitted a release order to the base station for the release of itself from the conference conversation/ call. UE 1 is in call active state with more than one UE and one of the UE wishes to release from the conference call.
As shown in Figure 7, UE 1 is in conference call with user equipment 2 (UE 2) and user equipment 3 (UE 3), wherein the process of entering conference call is as described herein above with respect to Figure 5. While in the conference call with UE 2 and UE 3, UE3 wishes to terminate the call and release itself from the conference conversation.
In the present embodiment, the UE 3 transmits a release order to the base station to release itself from the conference conversation. The base station then communicates with the UE 1 and notifies the UE 1 regarding reception of UE 3 release order. The base station further transmits a FWIM message to UE 1 in response to release order request received from UE 3, informing that UE 3 wants to release itself from the conference call. Then, the base station acknowledges the release order received from UE 3 and disconnects the UE 3 from the conference call. The same is informed to other UEs who took part in the conference call as well.
Thus, the FWIM message with the new record type provides a unified approach not only to swap or merge in any situation but also facilities to use the same format to even answer call waiting calls, selectively release call from either at the user equipment or at the base station end.
The present embodiments have been described with reference to specific example embodiments; it will be evident that various modifications and changes may be made to these embodiments without departing from the broader spirit and scope of the various embodiments. Furthermore, the various devices, modules, and the like described herein may be enabled and operated using hardware circuitry, for example, complementary metal oxide semiconductor based logic circuitry, firmware, software and/or any combination of hardware, firmware, and/or software embodied in a machine readable medium. For example, the various electrical structure and methods may be embodied using transistors, logic gates, and electrical circuits, such as application specific integrated circuit.
| Section | Controller | Decision Date |
|---|---|---|
| # | Name | Date |
|---|---|---|
| 1 | 221-CHE-2014-US(14)-HearingNotice-(HearingDate-20-04-2021).pdf | 2021-10-17 |
| 1 | Form-18(Online).pdf | 2014-01-24 |
| 2 | POA_Samsung R&D Institute India-Bangalore.pdf | 2014-02-05 |
| 2 | 221-CHE-2014-IntimationOfGrant21-06-2021.pdf | 2021-06-21 |
| 3 | 221-CHE-2014-PatentCertificate21-06-2021.pdf | 2021-06-21 |
| 3 | 2013_PCG_1178_Drawings.pdf | 2014-02-05 |
| 4 | 221-CHE-2014-PETITION UNDER RULE 137 [27-04-2021(online)].pdf | 2021-04-27 |
| 4 | 2012_PCG_1178_Form 5.pdf | 2014-02-05 |
| 5 | 221-CHE-2014-Written submissions and relevant documents [27-04-2021(online)].pdf | 2021-04-27 |
| 5 | 2012_PCG_1178_Complete Specification.pdf | 2014-02-05 |
| 6 | abstract221-CHENP-2014.jpg | 2014-10-24 |
| 6 | 221-CHE-2014-Correspondence to notify the Controller [29-03-2021(online)].pdf | 2021-03-29 |
| 7 | 221-CHE-2014-FER.pdf | 2019-03-13 |
| 7 | 221-CHE-2014-ABSTRACT [13-09-2019(online)].pdf | 2019-09-13 |
| 8 | 221-CHE-2014-RELEVANT DOCUMENTS [06-08-2019(online)].pdf | 2019-08-06 |
| 8 | 221-CHE-2014-CLAIMS [13-09-2019(online)].pdf | 2019-09-13 |
| 9 | 221-CHE-2014-FORM-26 [06-08-2019(online)].pdf | 2019-08-06 |
| 9 | 221-CHE-2014-CORRESPONDENCE [13-09-2019(online)].pdf | 2019-09-13 |
| 10 | 221-CHE-2014-DRAWING [13-09-2019(online)].pdf | 2019-09-13 |
| 10 | 221-CHE-2014-FORM 13 [06-08-2019(online)].pdf | 2019-08-06 |
| 11 | 221-CHE-2014-FER_SER_REPLY [13-09-2019(online)].pdf | 2019-09-13 |
| 11 | 221-CHE-2014-Proof of Right (MANDATORY) [13-09-2019(online)].pdf | 2019-09-13 |
| 12 | 221-CHE-2014-OTHERS [13-09-2019(online)].pdf | 2019-09-13 |
| 13 | 221-CHE-2014-FER_SER_REPLY [13-09-2019(online)].pdf | 2019-09-13 |
| 13 | 221-CHE-2014-Proof of Right (MANDATORY) [13-09-2019(online)].pdf | 2019-09-13 |
| 14 | 221-CHE-2014-DRAWING [13-09-2019(online)].pdf | 2019-09-13 |
| 14 | 221-CHE-2014-FORM 13 [06-08-2019(online)].pdf | 2019-08-06 |
| 15 | 221-CHE-2014-CORRESPONDENCE [13-09-2019(online)].pdf | 2019-09-13 |
| 15 | 221-CHE-2014-FORM-26 [06-08-2019(online)].pdf | 2019-08-06 |
| 16 | 221-CHE-2014-CLAIMS [13-09-2019(online)].pdf | 2019-09-13 |
| 16 | 221-CHE-2014-RELEVANT DOCUMENTS [06-08-2019(online)].pdf | 2019-08-06 |
| 17 | 221-CHE-2014-ABSTRACT [13-09-2019(online)].pdf | 2019-09-13 |
| 17 | 221-CHE-2014-FER.pdf | 2019-03-13 |
| 18 | 221-CHE-2014-Correspondence to notify the Controller [29-03-2021(online)].pdf | 2021-03-29 |
| 18 | abstract221-CHENP-2014.jpg | 2014-10-24 |
| 19 | 2012_PCG_1178_Complete Specification.pdf | 2014-02-05 |
| 19 | 221-CHE-2014-Written submissions and relevant documents [27-04-2021(online)].pdf | 2021-04-27 |
| 20 | 221-CHE-2014-PETITION UNDER RULE 137 [27-04-2021(online)].pdf | 2021-04-27 |
| 20 | 2012_PCG_1178_Form 5.pdf | 2014-02-05 |
| 21 | 221-CHE-2014-PatentCertificate21-06-2021.pdf | 2021-06-21 |
| 21 | 2013_PCG_1178_Drawings.pdf | 2014-02-05 |
| 22 | POA_Samsung R&D Institute India-Bangalore.pdf | 2014-02-05 |
| 22 | 221-CHE-2014-IntimationOfGrant21-06-2021.pdf | 2021-06-21 |
| 23 | Form-18(Online).pdf | 2014-01-24 |
| 23 | 221-CHE-2014-US(14)-HearingNotice-(HearingDate-20-04-2021).pdf | 2021-10-17 |
| 1 | 2019-03-1217-28-14_12-03-2019.pdf |