WO2012025970A1

WO2012025970A1 - 3rdparty assisted session management

Info

Publication number: WO2012025970A1
Application number: PCT/JP2010/005299
Authority: WO
Inventors: Xiaofei Zhou; Swaroop Sampath Kumar
Original assignee: Panasonic Corp
Current assignee: Panasonic Corp
Priority date: 2010-08-27
Filing date: 2010-08-27
Publication date: 2012-03-01
Anticipated expiration: 2013-02-27

Abstract

A system of enabling the 3^rd party assisted session management when a user does not clear about how to perform a complicated operation or need real-time help from a 3^rd party in a data communication network comprising of a help-seeking request generation capable terminal device that can choose a 3^rdparty for helping and generate help-seeking request during a session, a help-seeker side server device that can manage the UE under the help by other UE, a helper side server device that can manage the UE that is helping others, and a help-capable terminal device that can process help seeker session information and request on behalf of the help seeker. These apparatus are connected to each other through IMS platform, regardless of their subscriptions. A method of 3^rd party assist session management without join the session comprises the steps of pre-configuring the 3^rd party; sending a help-seeking message; receiving acknowledgement from 3^rd party; regularly updating session information; requesting actions by 3^rdparty on behalf of the help seeker; server re-packetizing helping requests from helper; and performing actions on help seeker UE.

Description

3RDPARTY ASSISTED SESSION MANAGEMENT

The present invention pertains to the field of telecommunication in a packet-switched communications network. More particularly, it concerns session control in an IP Multimedia System.

With the development of next generation network and IMS platform, more and more complicated services are introduced for future mobile communications. Although device providers try to enhance the friendliness of their User Interface and network operators try to simplifier user requirements, users still have to put much effort to understand details before initiating a specific service. The situation becomes frustrating for users who learn slowly or are difficult to remember all. Even for a user who is familiar with all service details, he may occasionally need non-technical help from a 3rd party.

3GPP TS 23.831-021, "IP Multimedia Subsystem (IMS) Service Continuity; Inter-UE Transfer enhancements; Stage 2(Release 10)"

In current accessible literatures, no general solutions to help people manage their session if they got problems during the session. Control transfer and pull-mode Inter-UE Transfer (IUT) in latest 3GPP TS23.831 [Non-patent document 1] may be a possible way to solve the problem. However, both control transfer and pull-mode IUT require the 3rd party join the collaborative session first. Pull-mode IUT even requires the 3^rd party pull media to itself before performing any control.

This brings many problems and redundant steps. Firstly, both control transfer and pull-mode media transfer are initiated by the 3rd party. However, the 3^rdparty may not know when the original controller needs help. Secondly, the original user (help seeker 51) still needs to provide co-operations like pull-mode IUT authorization which he may not familiar with. Thirdly, control/media transfers bring much delay and make the helping procedure more complicated. Fourthly, help seeker must transfer his session (including all media streams) to the 3^rd party for control, not only general session information. This may bring uncomfortable or security issues to help seeker, thus causes him to hesitate on seeking help. Finally, IUT solution only suitable for limited cases but not all supplementary services provided by IMS today. Thus a more basic solution is required for the problem.

We propose to solve the above mentioned problems by adding a simple HELP function on terminal device and network. User could use it to select who will be the 3rd party that going to help him and to tell the 3^rd party what he wants to do. If 3^rd party accepts the help request from original user, network will forward current session information to 3rd party. After that, any request coming from 3^rd party with HELP Indicator will be treated as requested from the original user. Thus 3^rd party helps the original user to manage his session and initiates requests without interrupting sessions on his own device.

This method is suitable for any case when user needs help. A 3^rd party could be another user or a service provider. It may be but not necessarily in the same session as help seeker. The method can be further extended to full remote control by a 3rd party device, in which help seeker's device is mirrored to helper's device and helper can operate directly on help seeker's device.

It is an objective of the invention to address the above mentioned problems, shortcomings, and incompleteness. In particular it aims to provide a method to enable user looking for and receiving real time support during the session whenever needed.

Another objective of the invention is to meet the demanding complexity of future mobile usages. It is an intelligent system making better use of current network and terminal devices. In the system, help seeker and helper can be at the same or different locations and under the same or different operators. They can talk face to face if they are near each other or through IMS platform by initiating a separate voice session. All help activities can be done without interrupting the current on-going session on both help seeker and helper device.

In one aspect, help seeker may pre-configure a helper in the service profile or choose it instantaneously when request for help. When help seeker presses the HELP button or activates equivalent function, a Help-seeking request together with the 3^rdparty information is sent to server that serves the help seeker. Server forwards the request to helper. If helper accepts the request, subsequent messages will be exchanged between the server and the helper. Help seeker is marked as helping mode.

In another aspect, server that serves the help seeker requires additional functions to fulfill the operation. It has a function that can extract 3rd party information from help seeking request and forward the request to helper. It has a function that can differentiate requests with HELP Indicator from other normal requests. Furthermore, it has a function to detach helper device information from the request with HELP Indicator and attach help seeker information to the request. To fulfill this purpose, it also has a help-pair list to record and maintains information of paired help seeker and helper devices. The lists are used as database not only for information attach and detach procedure but also to mark help seeker status and to help other help-mode control decisions when necessary.

In yet another aspect, the helper device is able to understand help-seeking message and is capable of generate request on behalf of help seeker. If user agrees to help the help seeker, helper device activates a function to receive and display help seeker session information. Helper initiates request on behalf of help seeker using his own device. These requests are marked with HELP Indicator before sending. The HELP Indicator is used to inform the server which serving the helper that the request is issued on behalf of others and no need to be processed at helper side. During help procedure, helper can switch to his own session any time.

In another aspect, server (52) that serves the helper can forward the request with HELP Indicator to corresponding server that serves help seeker (50) without processing it. To assist this purpose, servers need to keep a help-pair list so that it knows where to forward the request.

In another aspect, session control is extended to a 3rd party with very little redundancy of space and processing time. The only space redundancy for the whole system is an additional help-pair list on server at help seeker side (50). The additional procedure for help seeker is generating a help-seeking signal. Additional procedures for server serving help seeker are sending help seeker's session information to helper and replacing information from helper device to help seeker device. Additional procedure for server serving helper is just checking HELP Indicator and forward request. Finally, the additional procedures for helper are receive and display help seeker session information and generating request with HELP Indicator on behalf of help seeker.

With these solutions, user is able to seek help from a trusted party for any problem encountered instantaneously. Terminals and servers just need small software modification to support such a helping feature. With this solution, newly designed value-add mobile services and modern devices would be accepted easier and faster.

FIG.1 is a diagram illustrating the overall system. It consists of a UE terminal-1 51 with the ability of generating help-seeking request; a server 50 that serves the help seeker; a server 52 that serves the helper; and a 3^rd party UE terminal-2 53 that acts as a helper. Intermediate is a packet switch network. FIG. 2 is the diagram of functions and structure of a Terminal Device that specifically perform as a Help Seeker (51). FIG. 3 is the diagram of functions and structure of a Terminal Device that specifically perform as a Helper (53). FIG. 4 is the diagram of functions and structure of Server (50) that serves Help Seeker, processing its requests and communicating with the network. FIG. 5 is the diagram of functions and structure of Server (52) that serves Helper, processing its requests and communicating with the network. FIG. 6 is a flowchart diagram illustrating the procedure that Help Seeker (51) follows when it generates help-seeking request and receives help from a 3^rdparty. FIG. 7 is a flowchart diagram illustrating the procedure that Helper (53) follows when it accepts or rejects a help-seeking request and generates request on behalf of help seeker if help request accepted. FIG. 8 is a flowchart diagram illustrating the procedure that Server (50) at help seeker side follows when it receives help-seeking request from help seeker, or when it receives messages with HELP Indicator generated by Helper (53) on behalf of help seeker. FIG. 9 is a flowchart diagram illustrating the procedure that Server (52) follows when it receives a help-seeking request or a message with HELP Indicator.

Description of Embodiment

The above and other objects and features of the invention will appear more fully hereinafter from a consideration of the following description taken in connection with the accompanying drawing wherein the solution is illustrated by way of example.

In the following detailed description of exemplary embodiments of the invention, reference is made to the accompanied drawings, which form a part hereof, and which is shown by way of illustration, specific exemplary embodiments of which the invention may be practiced. Each embodiment is described in sufficient detail to enable those skilled in the art to practice the invention, and it is to be understood that other embodiments may be utilized, and other changes may be made, without departing from the spirit or scope of the present invention. The following detailed description is, therefore, not to be taken in a limiting sense and the scope of the present invention is defined only by the appended claims. In the following description, for the purpose of explanation, specific numbers, times, structures, protocols, and other parameters are set forth in order to provide a thorough understanding of the present invention. However, it will be apparent to anyone skilled in the art that the present invention may be practiced without these specific details.

Figure 1 illustrates a most basic system that supports the present invention, consisting of a Terminal-1 UE 51 that can generate help-seeking message to a 3^rdparty, a server 50 which serves Terminal-1 UE (51) that forwards help-seeking message to the 3^rd party and processes help message with HELP Indicator coming from helper, an server 52 which serves the helper UE (53) that coordinates with the help procedure by neglecting messages coming from helper with HELP Indicator, and the 3^rd party 53 that can receive and display help seeker's session information and generate messages on behalf of the help seeker UE 51. The network must support packet exchanges. It is preferred that the network supports SIP or IMS protocols, but the network could support other protocols.

Figure 2, is the structure of a terminal communication device with the capability of selecting a 3^rdparty for help and generating help-seeking message to the 3^rd party. It is the help seeker in the presented system. It contains additional HELP Initiation Function 100 and/or Help Initiation Function with Call 101 in UI for user to issue a help seeking trigger during a session. The trigger will activate Help Mode Control Function 104 for successive actions.

Help Mode Control Function 104 identifies the trigger from UI. Then it decides whether user needs to select a 3^rd party for its help-seeking request or user has already set it in the service profile. If a 3^rd party helper has already been set in the service profile, Help Mode Control Function 104 will inform Help Message Generating Function 103 to pack up a help-seeking message target at the 3^rd party UE, and is further sent out through Message Transmitter 105. On the other hand, if no 3^rd party pre-configured in service profile or user wants to change the selection this time, Help Mode Control Function 104 needs to activate 3^rd-party Selection Function 106 for user to choose a 3^rd party UE as helper instantaneously.

The 3^rd-party Selection Function 106 relies on the 3^rd Party Information Database 107 for selection. The 3^rd Party Information Database can be an additional database in future commercial UEs, or it can be just the phonebook or the mailing list stored in nowadays UEs. The 3^rd party information retrieved from 107 will be displayed on the UI. User selects the desired 3^rd party identity; Help Mode Control Function 104 sends the selection together with help-seeking request to 103 to generate a help-seeking message. Finally, the message is sent out through 105.

No matter the 3^rdparty accepts or rejects the helping request, help seeker will receive a notice through Message Receiver function 102. Help Mode Control Function 104 is the one that gathering such notices and display them on UI 100. If helping request is accepted by the chosen 3^rd party, Help Mode Control Function 104 will mark this terminal UE as helping mode.

In helping mode, help seeker could terminate the helping procedure anytime. Sequentially, the help-termination request is issued from UI, processed by Help Mode Control Function 104, packetized by Help Message Generating Function 103, and sent out through Message Transmitter 105. Terminating a helping procedure has no impact on the on-going sessions of helper seeker device.

The 3^rdparty assisted session management usually happens when help seeker and helper are far from each other and is not possible to talk directly. In this case, helper must know what help seeker intends to do before conducting the help. Thus when help seeker suddenly needs help during a session, there should be a way for him to tell the helper what is the problem. To fulfill this purpose, HELP Initiation with Call function 101 is used. Unlike HELP Initiation function 100 that only sends a message to the 3^rd party seeking for help, trigger initiated by 101 indicates that user needs to have a call with the selected 3^rdparty when requesting for help. With this button pressed, Help Mode Control Function 104 will automatically start a voice session with the 3^rdparty through Message Transmitter 105 besides raising a help-seeking message demand to Message Generating Function 103. After connecting the 3^rd party, previous on-going session will be either automatically suspended or invited to join the teleconference with the 3^rd party. Helping procedure could be conducted after termination of this voice session or in parallel.

Figure 3, is the functions and structure of another terminal communication device with the capability of receiving and presenting help seeker session information, and generating requests on behalf of help seeker. It is the 3^rd party helper in the presented system. If a help-request message is received by Message Receiver 121, it will be passed to Help Mode Control Function 123. Help Mode Control Function presents it on UI 122 for user to decide accept or rejection.

Remote Party Information Database 124 stores all help seeker UE related information like personal identity and addresses, session related information like session ID and involved media status, and serves as a reference for Message Generating Function 125 to generate the messages. Message Receiver 121 is also responsible to receive original and updated help seeker's session information, while Help Mode Control Function 123 is responsible to project it on UI 122.

Whenever help screen is active on helper's device, the request issued by user is considered as helping request on behalf of a certain help seeker. This request, unlike other normal requests, has to be processed by Help Indicator Attaching Function 126 to attach a signal that it is not requested for the current UE but for a help seeker UE. However, if help screen is inactive on helper's device, the request issued by user is considered as normal request for current UE and will not be processed by

function

123 and 126. It goes from UI to 125 directly and sends out through 127 without passing 126, as illustrated by dotted line in Figure 3. Thus, the helper can continue its own sessions without interference with the help procedure. Helper could also terminate the help procedure any time within help mode. The trigger comes from UI 122 and processed by control function 123; then the request is generated by 125 and sent out by 127 directly without processing on 126.

The HELP Indicator is used for server serving the helper to differentiate helping message from normal messages. However, it requires server checking each incoming packet no matter there is UE under helping mode or not. Therefore, we propose another embodiment to decrease such redundant checking. In this embodiment, helper inserts a special bit in the response message or sends a separate message when accept the helping request. Server turns on its packet filter when such a bit is detected or such a signaling message is received. And the filter will be turned off when helping procedure terminated. With the filter off, server treats all messages as normal ones.

Figure 4, is the structure of a server that serves the help seeker UE. It contains a Message Receiver 151 that receives messages from UEs under its service and from the network. Message Processor 152 filters messages with HELP Indicator from normal messages and sent them to Helper Message Process Function 153. Here the information of helper UE (e.g. device identity, user subscription, session ID, etc) will be detached from the message. Furthermore, it will retrieve the corresponding information of help seeker for the message by searching Help Pair Information List 154.

Help Pair Information List 154 is a database created and updated by Help Message Process Function 153. It is used to record user information and UE status of paired help seeker and helper. For example, UE subscription, UE's current active service profile, which session of this UE is under helping, etc. After retrieving the corresponding information of help seeker, Helper Message Process Function 153 passes the help seeker information and the message to Help Seeker Information Attach Function 155, in which help seeker information is attached to the matching field in message packet. Request Process Function 156 is going to process this re-packed message as normal request coming from help seeker.

If response message needs to be sent to helper, it will be generated by Response Generation Function 158 and sent through Message Transmitter 157. Responses need to be sent to helper in helping mode, so Help Message Process Function 153 needs to pass 158 the helper information to fill correct destination address in the message. Though responses are sent to the helper, requested actions are done on help seeker's UE.

For those messages without HELP Indicator, Message Processor 152 directly filters them to Request Process Function 156.

One embodiment is server may lock the session under help on help seeker UE during helping procedure. UE is set as automatically agree all actions performed on it. That is, any request from help seeker regarding the session under help will be neglected since the session is under the control of helper. Another embodiment is server asks the acceptance from help seeker whenever helper requests for an operation on behalf of the help seeker. It offers better protection for help seeker but the redundancy may also bore the user. Yet another embodiment is that both help seeker UE and helper could request for the same session, server take the first coming one for action and discard the surplus requests.

Figure 5, is the structure of a server (52) that serves the helper UE. It contains a Message Receiver 171 that receives messages from UEs it serves and from network; a Request Checking Function 172 that distinguishes normal requests from requests with HELP Indicator; a Request Process Function 173 that processes normal requests; a Request Forward Function 174 that simply forwards those requests with HELP Indicator to the network; a Message Transmitter 176 that sends/forwards packet out; and an Help Pair Information List 175 which serves as reference database for message forwarding.

Another embodiment is in Request Checking Function 172, there may be a filter to check HELP Indicator in a message. The inventive point is that this filter could be turned on if required and turned off if not used. If UE it serves is in normal mode, this HELP Indicator filter will be turned off to save processing time. All incoming packets from the UE will be passed directly to Request Process Function 173. However, if a signal for changing UE mode from normal to helping mode is received, the filter must be switched on because following messages may not target to the UE but a remote UE. This function will save a lot of server's computing time.

Figure 6 is a flowchart of help seeker UE during help procedure. Help seeker UE constantly checks whether user issued any request through UI. If a request is initiated at step 200, UE needs to check whether it is a request seeking for help at step 201.

For normal requests not seeking for help, UE simply passes them to Normalprocess 202; while help-seeking request is processed at 203. Then Help Mode Control Function 104 checks at step 204 whether a 3^rd party is already specified in user profile or user wants to configure it now.

If no pre-configuration of a 3^rd party or user want to select simultaneously, step 205 is performed to serve the purpose. Otherwise the help-seeking request will be sent to generate help message together with 3^rdparty information at 206. The help-seeking message is sent out at step 207. User should wait a reply at step 210 before continuing the help procedure. If selected 3^rd party rejects the help request, help seeker need to process the response at 203 and decide whether selecting another 3^rdparty or simply terminate the help seeking process.

If help-seeking request is accepted, Help Mode Control Function 123 will mark current UE as helping mode and cooperate with server to continue helping process at step 211. The cooperation may include agree to the operation helper does, lock UI input for the session under help, or keep an independent voice session with helper to eliminate wrong operations requested by helper for help seeker's UE. Upon completion of the help procedure, help seeker will terminate this help session at step 212. The termination could be triggered by releasing the HELP button, exiting help control function, terminating the session under help, etc.

Figure 7 is a flowchart of helper UE during help procedure. Helper receives the help-seeking message at 220 like any other normal message. Then it will check whether it is a help-seeking message at step 221. Non help-seeking message goes to normal process 222, and help-seeking message needs to query user for acceptance (223). User decides at step 224. Rejection decision only needs one further step 226 to inform the help seeker and goes to the end.

If help-seeking request is accepted, helper also needs to send at step 225 an acknowledgement to help seeker and servers in between to trigger the start of help procedure. Then in step 230, helper will receive from help seeker's server (50) sufficient information related to the session that seeker is asking for help. The information in sent to helper immediately when server received acknowledgement. The information may be sent in any format, as long as helper could understand.

Another embodiment is server at help seeker side (50) just provide basic information of the session for help. Helper asks for additional information whoever required, and help seeker should agree to release the additional information before helper could get it.

Another embodiment is server mirrors the help seeker's UE together with all ongoing sessions to helper's UE, so that helper could operate like using help seeker's UE directly. However, this embodiment has security issues and only suitable to closed and trusted parties.

After retrieving help seeker session information, user starts to generate requests on behalf of help seeker in step 231. As a rule, these requests will be automatically attached with helper UE information. However, these requests are not for helper UE but for others. So step 232 is necessary to add a HELP Indicator on these requests. With HELP Indicator, servers will know how to process them correctly. The HELP Indicator could be just a bit or a byte in the message. With HELP Indicator inserted, helper UE sends the message (233) and check if help procedure finished (234). If more actions needed, helper will repeat steps from 231.

Figure 8 is a flowchart of helping mode procedure for server that serves the help seeker. For message received at 250, server checks if it is a help-seeking message on step 251. Help-seeking message will be forwarded to the 3^rd party in 252; while other messages are sorted out for further check in 270 for the existence of a HELP Indicator.

For forwarded help-seeking message, server will wait for a response at step 253. Rejection response is forwarded to help seeker in 254 and that will end the help seeking process. Upon receiving accept response, server will update help-pair list at 255 and mark help seeker UE as help mode (256). Then the server will send help seeker's session information to helper UE (257) and wait for the helper's action (250).

For messages without HELP Indicator, server just processes it with normal message processing procedure 271. For messages with HELP Indicator, server will pre-process (272) the message to check at 273 whether an acknowledgement (ACK) is required. If required, an ACK is generated in 274 and sends out to corresponding party. It is an implementation issue on where to send the ACK. Since helper is a temporary controller for the session, the ACK may send to helper UE only. In another embodiment, help seeker may want to be informed about the progress of helping procedure. In this case, both help seeker UE and helper UE will receive the ACK.

After sent or skipped ACK message, server will replace helper's information in the message by help seeker's information in step 275. Then the message is re-packetized as a request sending from help seeker itself. Step 271 processes this re-packetized message as any other message without HELP Indicator. Finally, the actions performed on help seeker's session will trigger an information update at helper side (257) so that the helper knows the latest status of help seeker's session.

Figure 9 is a flowchart of helping mode procedure for server (52) that serves the helper. The function of server at helper side is simpler than the server at help seeker side (50). Here its flowchart is also simpler. Server (52) that serves the helper keeps on checking incoming messages in step 300 and differentiating them into three categories: normal message, help-seeking message coming from a help seeker, and message with HELP Indicator coming from a helper under its service.

Normal message is processed by normal message processing procedure 301. Help-seeking message is forwarded to the 3^rd party device in 302. Message with HELP Indicator is going to be forwarded to the network. Before that, server needs an additional step 310 to find help seeker address from help-pair list so that it knows where to forward the message in 311.

For the help-seeking request forwarded to the 3^rd party, server needs to wait for its response (303) and send back to help seeker no matter it is accepted (304) or rejected (306). If help-pair list is used, server also needs to update it for information like help seeker address, session ID under helping, etc.

This invention could be used in the following example cases but not limited to them.

Firstly, the invention could be used in an Inter-UE Transfer case where user A has an IUT capable UE. He is on a session at home with a remote party. Within the session there are video stream and audio stream. Now user A wants to transfer video stream to the big TV at his home while keep audio stream on his mobile. To realize this IUT action, he needs to turn on TV and issue a transfer request with identity of the session, video stream number, identity of TV and even his subscriptions. Furthermore, in request he should tell server that only transfer video stream to the specified TV. It is quite complicated if user A does not know how to use IUT function. With this invention, he can seek help from his closest friend or relative easily. Suppose he never sets anybody in his profile as 3^rd party helper. Now he asks the remote party wait a while and presses the "help with call" button on his mobile phone. He will receive a prompt window to enter a 3^rd party number or searching it in his phonebook. He input his son's (user B) phone number. The current session then be suspended and a call is connected to his son. Meanwhile a help-seeking message is sent to his son's mobile. He asks his son to move video to the TV and his son accept his request by pressing OK on help seeking request on his UI. Then all information related to user A's session is displayed on user B's mobile. User B may further request for additional message if necessary. User B requests an IUT of transferring video from the session to TV. This request is forwarded directly in network and only be processed by server that serves the user A. This server detaches user B's subscriptions and identities; replaced by user A's corresponding information. Then video on user A's mobile is transferred to TV. After that, user A just presses EXIT button to terminate the helping procedure.

Secondly, the invention could be used in service cases where user needs remote services from a service centre. For example user A is opening Internet Banking through his PDA but stacked by some operations in between. He presses the help button and input the bank's service number. With the help-seeking message, he describes the intention of open the Internet Banking service. Service provider receives his current status and subscription information from his mobile server and request on behalf of him. Meanwhile, he may need to collaborate with the helper by setting his account name and password.

Thirdly, the invention could be further extended to full remote control where the whole UE device, not only general information of being helped session, is under the view of helper. Helper operates like using help seeker's UE itself. This requires more information retrieved both from server and device itself. It is only operatable between secured users.

Claims

A method for a terminal device to seek and receive help from a 3^rd party device, comprising:
requesting to a 3^rdparty for help;
providing help seeker's information;
sending requests on behalf of help seeker device; and
processing help requests as requests from help seeker device.
The method according to claim 1, wherein said requesting to the 3^rdparty for help further includes sending a signal to server asking for help from a 3^rd party, forwarding such help-seeking message to the 3^rdparty, responding to the help-seeking message.
The method according to claim 2, wherein said the 3^rdparty can be pre-configured in service profile.
The method according to claim 2, wherein said the 3^rdparty can be selected when issuing the help-seeking message.
The method according to claim 2, wherein said the signal for help seeking includes enough information for servers and network to forward it to the 3^rd party.
The method according to claim 2, the signal further includes a indication on whether to initiate an independent call to the 3^rdparty together with the help-seeking message.
The method according to claim 1, wherein said providing help seeker's information further includes sending the help seeker's session information and updating help seeker's session information.
The method according to claim 7, wherein said the help seeker's information includes current session parameters and necessary device information to perform help activities.
The method according to claim 7, wherein said updating help seeker's session information is done regularly whenever changes happened on help seeker's session that under helping.
The method according to claim 7, wherein said the provided information for helping purpose cannot be saved in other device than servers.
The method according to claim 1, further includes maintaining a help list recording information of all paired devices under helping mode.
The method according to claim 11, information recorded in help pair lists are address information, session information, status information, and helping history of paired help seeker and helper UEs.
The method according to claim 1, wherein said sending requests on behalf of help seeker device further includes attaching a HELP Indicator on requests generated for helping purpose.
The method according to claim 13, wherein said a HELP Indicator can be configured in any signal format.
The method according to claim 13, wherein said a HELP Indicator is further configured to inform servers that the request is to help others but not for the user device that generates it.
The method according to claim 13, further includes checking of all incoming messages for HELP Indicator when helping procedure is going on.
The method according to claim 13, further includes forwarding the request with HELP Indicator to servers that serve the help seeker without processing it.
The method according to claim 1, wherein said processing help requests as requests from help seeker device further includes detaching information of helper's device from the request with HELP Indicator, attaching the information of help seeker's device on the corresponding place of the massage, and processing the re-packetized message as normal message from help seeker's device.
The method according to claim 18, wherein said detaching information of helper's device from the request with HELP Indicator further includes sending response or acknowledgement to the helper if required.
The method according to claim 18, wherein said processing the re-packetized message as normal message from help seeker's device further configured as performing all actions requested by the message to help seeker's device.
A system configured to help each other for on-going sessions, comprising:
terminals that can prepare and send help seeking message to the control server or equivalent agent that manages the session;
terminals that can process help-seeking message and initiate requests with HELP Indicator on behalf of help seeker;
servers that can forward help-seeking message to the 3^rd party and forward helping message with HELP Indicator to the help seeker; and
servers that can detach helper information from the requests with HELP Indicator and bind the help seeker information with the requests.
The system of claim 21, wherein said the help seeker terminal device contains independent functions to initiate help-seeking message and manage the session under helping.
The system of claim 22, wherein said terminal device of help seeker further includes help initiation function, message generating function, 3^rd party selection function, and 3^rd party information database to initiate help-seeking message.
The system of claim 22, wherein said terminal device of help seeker also includes help mode control function to control the message generation, information retrieve, and session status update.
The system of claim 22, wherein said the helper terminal device contains independent help-seeking response functions to response to help-seeking message and manage the session on behalf of the help seeker.
The system of claim 25, wherein said the help-seeking response function includes message generating function, remote party information database, and HELP Indicator attaching function.
The system of claim 25, wherein said the helper terminal also includes help mode control function to display the help seeker's session information on UI and generate help request representing the help seeker.
The system of claim 21, wherein said helping mode control functions are added in servers on both help seeker and helper sides.
The system of claim 28, wherein said the server that serves the help seeker includes help mode indicator and help-pair information list to trace help seeker status. It contains help message process function to process messages for actions requested by help seeker's UE.
The system of claim 28, wherein said the server that serves help seeker contains helper information detach function and help seeker information attach function to re-packetize the request issued by helper on behalf of help seeker, making it as normal request coming from help seeker UE.
The system of claim 28, wherein said the server that serves the helper further includes request checking function that will classify requests with and without HELP Indicator.
The system of claim 28, wherein said the server that serve the helper further includes a UE status list or a help-pair information list to record which UE it serves is currently under helping mode and which is under normal mode.