Title of Invention

METHOD FOR PROCESSING SHORT VOICE MESSAGES IN A COMMUNICATION SYSTEM

Abstract The current invention relates to telecommunication domain and more particularly relates to a system and method for transmitting "voice message" to a recipient without any intervention of the network. The user initiates an SVM feature (Short Voice Messaging feature) and records voice message within the device. The user transmits the recorded voice message through normal voice call. During call set up, the recipient decodes the received call setup message and interprets that the call is a Voice message. The recipient sets up parameters for recording the voice message. Once the call set up is established, the user transmits recorded voice message directly to the recipient. The recipient records voice message and stores in Inbox. Thus the user is provided with an option of transmitting voice message directly without any text typing or text-speech conversion technique.
Full Text FIELD OF THE INVENTION
The present invention, in general relates to the field of mobile communication. Particularly the present invention describes a method that provides Short messaging service. More particularly, the invention relates to a method and system to send Short voice Service.
DESCRIPTION OF RELATED ART
US Patent no. 6954781 describes a Method to convert Voice Message to Text and send text message to receiver. However, this requires complex Speech Recognition Algorithms and Text-To-Speech Converters at the terminal
Currently we have voice mail box facility, for which user has to dial a number to retrieve the message
Aircel has introduced a technique in which user can send voice SMS which get stored in NW and receiver can retrieve it by dialing no 535 (Link:http://in.rediff.com/money/2006/apr/14mobile.htm ), similar to voice mail box.
In yet another us patent publication no. 20050286689 describe to send voice SMS to a Service Center in the form of text SMS.
PoC (Push to Talk) - PoC is the name of the Push to Talk service in cellular mobile networks. PoC is based upon packet-switched data transfer and uses Voice over IP methods to encode the voice transmission. In this method there is a delay of 1 - 2 seconds for data buffering in connection with voice data transfer.
Reliance Introduces Talking Message Service (TMS)- In this method one has to dial network number to record the message and network will in turn send that message to the intended recipient. If the recipient is busy and does not want to take the Talking Message call, they have to retrieving the Talking Message by dialing the same number. All calls made to 1234111 to record or retrieve a Talking Message are charged at Rs.2/Min.
However the above technology has certain limitations which has been explained ! below:
1. Speech Recognition Algorithms are not efficient to process native languages and recognize accents from diverse users
2. Converters are expensive to implement on terminal
3. There is a cumbersome process of typing text SMS with small keyboard.
4. One has to know specific language mainly English, illiterate person cannot use it.
5. SMS cannot be sent in most of the local Languages which is the major constrain.
6. Network intervention is needed in order to store the voice message.
7. Delay in transmission
8. Voice message can be sent only from mobile to mobile; there is no way to send it from mobile to Landline (PSTN) network.
9. Both originator and receiver are charged to send and retrieve the message from the network respectively.
10. There is a complex process to retrieve message form the network. SUMMARY OF THE INVENTION
The present invention provides a method and system wherein the originating user can send Short Voice Message (SVM) directly to the receiving user instead of typing text message and without any intervention of the NW thus avoiding all the problems listed above.
Accordingly this invention explains a method for sending short voice message comprising the steps of:
initiating an SVM feature (Short Voice Messaging feature) and recording voice message within the transmitting device;
transmitting the call setup message through a network as a normal voice call;
decoding the received call setup message and interpreting the call by the receiver as a Voice message during call setup; setting up parameters for recording the voice message by the receiver; transmitting recorded voice message directly to the recipient when the call set up is established; and recording and storing voice message in receivers inbox.
Accordingly this invention also explains a system for sending short voice message comprising:
a transmitting device initiating an SVM feature (Short Voice Messaging feature) and recording voice message;
a network for transmitting the call setup message as a normal voice call;
a receiver for decoding the received call setup message and interpreting the call as a Voice message during call setup; and
memory for recording and storing voice message in receivers inbox,
where the receiver sets up parameters for recording the voice message and when the call setup is established the transmitting device transmits recorded voice message directly to the recipient.
The SVM is sent directly from the originating terminal to the receiving terminal by establishing a normal voice call. The SVM gets recorded directly in the receiving terminal and stored in the inbox with a notification of reception of voice message without any intervention of the user. This allows the user to store the SVM same as like storing text SMS.
Second aspect of invention, if the user is busy (in meeting or driving etc...) and doesn't want to get disturbed, then he can set a profile like no incoming calls only SMS and/or SVM.
If a user wants to make a voice call to another user who does not want to get disturbed and has set the profile like no incoming calls, then in this condition originating user will initiate a voice call, since the profile at terminating terminal is set to no incoming calls, the originating user will get a message like "currently I'm busy please leave a message I will call you later". The originating user will speak the message and the message will get directly stored in the terminating terminal with out any intervention of the users.
These and other objects, features and advantages of the present invention will become more apparent from the ensuing detailed description of the invention taken in conjunction with the accompanying drawings.
BRIEF DESCRIPTION OF ACCOMPANYING DRAWINGS
Figure 1 depicts Flow Chart for Method of Sending SVM.
DETAILED DESCRIPTION OF THE INVENTION
The preferred embodiments of the present invention will now be explained with reference to the accompanying drawings. It should be understood however that the disclosed embodiments are merely exemplary of the invention, which may be embodied in various forms. The following description and drawings are not to be construed as limiting the invention and numerous specific details are described to provide a thorough understanding of the present invention, as the basis for the claims and as a basis for teaching one skilled in the art how to make and/or use the invention. However in certain instances, well-known or conventional details are not described in order not to unnecessarily obscure the present invention in detail.
Introduction - First aspect of this invention is to distinguish between Normal voice call and SVM.
To distinguish between normal voice call and SVM:
In SETUP message there is a field called User-User information. We can use this field in order to indicate user that it is Short Voice Message.
Table below shows the coding of User - User information in the SETUP message. Taken from 3GPP TS 24.008




The user - user signalling USS1 will be implicit activated, by user - user IE in
SETUP message.
Method:
(The complete method of sending Short Voice Message is New) Referring to figure 1:
1. Terminal will contain one soft key / menu to initiate a SVM
2. Originating user first press the soft key / go to SVM menu and record the message
3. Originating user can re-record his message after doing some modification if he wants to do so
4. After recording the message user will press the send button and provide the destination address
The message will be sent to the destination by using the following method:
1. Originating Terminal will in turn try to establish a normal voice call
2. A flag "Voice_Call_Type" is maintained in order to keep track whether it is Normal voice call or SVM.
3. The flag shall have two values:
a. NORMAL_ VOICE_ CALL
b. SHORT_VOICE_MESSAGE
4. NAS of UE will send CM_SERVICE_REQ with cause as Originating Voice Call
If Network sends CM_SERVICE_REJECT then
1. Originating User will try to send the message as per the re - transmission algorithm given below.
If Network sends CM_SERVICE_ACCEPT then
1. Network will respond with CM_SERVICE_ACCEPT assuming it to be a normal voice call
2. Depending upon the flag "Voice_Call_Type" NAS will set the parameter of the SETUP message:
a. Bearer capability Information Element (IE)
i. Is set with the default parameters as of normal voice call
b. User-User IE,
i. Octet 1 is set to TRUE (IE present or not)
ii. Octet 2 is set to Length of the data (= 1 byte)
iii. Octet 3 is set to User- Use Specific Protocol
iv. Octet 4 (data) is set to the value uSHORT_ VOICE_MESSAGE" (USS1 IMPLICIT)
3. NAS of UE will send this SETUP message to Network. If receiving user is reachable then
1. After receiving SETUP message Network will establish a normal Voice call
2. Receiving terminal will receive SETUP message and by decoding the User - User information it will get to know that it is "SHORT_ VOICEMESSA GE" and will set the flag "Voice_Call_Type" to uSHORT_VOICE_MESSAGE'
3. Receiving terminal will establish a normal voice call without giving any indication to the user of the incoming SVM.
4. The receiving terminal will send CONNECT_ACK to confirm the call and prepare to record the SVM by starting the recorder.
Recording of this message will be directly done by receiving
/
terminal with out any intervention of the receiving user.
5. When the call is established, originating terminal will get CONNECT ACK, after which Originating terminal will start playing the recorded message.
6. After the message is played Originating terminal will send DISCONNECT message
7. On reception of DISCONNECT message receiving terminal will stop recording and store the message in the SVM inbox folder and send RELEASE message.
8. On reception of RELEASE message Originating terminal will get to know that message has been delivered and then originating terminal will store the message in the SVM sent folder and send RELEASE COMPLETE
9. After the call is cleared Originating terminal will give a notification to the user that SVM has been delivered and it will be stored in SVM sent box.
10. After the call is cleared Receiving Terminal give a notification to the user of reception of Short Voice Message.
11. Receiving user can then listen to the message by going into the SVM inbox whenever he wants to.
12. Option can also be put in the application to auto play the Short Voice Message.
IN CASE THE USER IS NOT REACHABLE OR THE SENDING FAILS -
Receiving user is reachable or will not be known when network sends REJECT message with the cause as user not reachable / switch off.
If the user is not reachable or send fails then Originating terminal will try to send the message to the receiving user as pre the algorithm below. If originating terminal is not able to send the message with in 48hrs then it will delete that SVM and give a notification to the user that message cannot be delivered.
Algorithm
Every transmission/re-transmission notification will be send to the user with option "Retry" and "Ignore". If "Retry" option is selected by originating user then it will try to retransmit the message as per the schedule: 15min, 30min, 1hr, 2hr, 4hr after that every 4hr until we have exhausted 48hrs.
static time initial_time;
static int time_gap = 15; /* in seconds */
static time next_time_to_send_SVM;
algorithm_to_send_SVM() {
time current_time;
current_time = get_time_from_system();
/* checking if we are trying to send SVM for more then 48hrs */
If (time_gap If (next_time_to_send_SVM == current_time) {
If (pending_SVM == SVM_PENDING_TO_SEND) {
retransmission_option = notify_USER_for_SVM_retranmission()
If (retransmission _option = "Retry") {
pending_SVM = NO_SVM_PENDING_TO_SEND;
If (!send_pending_SVM()) {
pending_SVM = SVM_PENDING_TO_SEND;
if (time_gap >= 240) {
/* Now we will send SVM after every 4 hrs */ time_gap = time_gap + 240;
next_time_to_send_SVM = current_time + 240; }
else {
time_gap = time_gap * 2;
next_time_to_send_SVM = current_time + time_gap; }
} }
else {
/* User selected not to retransmit the message */
delete_pending_SVM();
pending_SVM = NO_SVM_PENDING_TO_SEND; }
} } }
else {
/* we cannot send the message since last 48hrs so now delete the SVM and give
a notification to user */
delete_pending_SVM();
notify_USER_for_SVM_Failure();
pending_SVM = NO_SVM_PENDING_TO_SEND; }
}
Storage requirement at originating / receiving terminal:
Originating / Receiving terminal is required to have at least 1MB of free storage
(Around 1 min of SVM).
At receiving side, After getting SETUP message from NW and knowing that it is for SVM, receiving terminal should check whether it has sufficient memory to store the SVM or not.
If the receiving terminal does not have sufficient storage then it will reject the incoming call setup with the cause as "BUSY" and giving a notification to the user that "MEMORY FULL. DELETE SOME SVM FOR THE INCOMMING SVM".
Receiving user will delete some messages by using Ul options.
If the Short voice message call drops during SVM transfer: At originating terminal:
Originating terminal will again try to send the SVM as per the algorithm At the receiving terminal:
Receiving terminal will store the half recorded message.
If the receiving terminal is busy with Normal CS call, and an MT SVM is received:
At originating terminal:
If busy tone is received at the originating terminal then originating terminal will again try to send the SVM as per the algorithm At the receiving terminal: Receiving terminal will send busy tone.
If originating terminal receives a normal MT voice call during SVM transfer then originating Terminal will send a busy tone to the MT voice call.
If receiving terminal receives a normal MT voice call during SVM transfer then the receiving terminal will send a busy tone to the MT voice call.
If the receiving terminal is on PS call, then also receiving terminal can receive the incoming SVM in background, with out affecting the ongoing PS call.
Extra Features
1 .Post Dated SVM
Post dated feature can also be implemented in the mobile. This feature will enable user to send the message at some post dated time. To do this user has to set time and date in the options of SVM. And on that time and date Mobile will send the message to the receiving user.
2. Independency of the receiving terminal type:
By this method we can even send the message to the land line. When originating user will send a message to the land line then a voice call session will be established. At the receiving side, if some one pick-up the phone then the recorded message will be played at the originating side and it can be heard by the receiving side.
ADVANTAGES
1. Independent of language, person can send the message in the language he knows.
2. Real time service is provided no delay in transmission.
3. Any person who cannot read or write can easily use SVM
4. Avoid cumbersome process of typing on small keypad
5. No need of GPRS technology, existing 2G/3G technology will be used.
6. In future it may replace SMS
7. Ease of use as it can be send just by press of one button
8. Independent of the receiving terminal type message can be delivered even to the landline terminals
9. No network interaction is needed.
10. No extra cost is involved from network perspective in this method
11. User can send SVM of any length limited by the amount of free memory available at originating and receiving side. In future mobile are expected to have GB of memory so there will be no constraints to the length of the voice message.
12. Only originator will be charged of the service and receiver need not to pay any thing to receive the message
It will also be obvious to those skilled in the art that other control methods and apparatuses can be derived from the combinations of the various methods and apparatuses of the present invention as taught by the description and the accompanying drawings and these shall also be considered within the scope of the present invention. Further, description of such combinations and variations is therefore omitted above. It should also be noted that the host for storing the applications include but not limited to a microchip, microprocessor, handheld communication device, computer, rendering device or a multi function device.
Although the present invention has been fully described in connection with the preferred embodiments thereof with reference to the accompanying drawings, it is to be noted that various changes and modifications are possible and are apparent to those skilled in the art. Such changes and modifications are to be understood as included within the scope of the present invention as defined by the appended claims unless they depart therefrom.
GLOSSARY OF TERMS AND THEIR DEFINITIONS
ME - Mobile Equipment SMS - Short Message Service SVM - Short Voice Message








We claim:
1. A method for sending short voice message comprising the steps of:
initiating an SVM feature (Short Voice Messaging feature) and recording voice message within the transmitting device;
transmitting the call setup message through a network as a normal voice call;
decoding the received call setup message and interpreting the call by the receiver as a Voice message during call setup; setting up parameters for recording the voice message by the receiver; transmitting recorded voice message directly to the recipient when the call set up is established; and
recording and storing voice message in receivers inbox.
2. A method as claimed in claim 1 wherein the transmitting device is adapted to modify the recorded message.
3. A method as claimed in claim 1 wherein the receiver notifies the reception of an SVM when the message arrives in the inbox.
4. A method as claimed in claim 1 wherein a call is identified as an SVM using a specific field in the call setup message.
5. A method as claimed in claim 1 wherein after receiving SETUP message a Network will establish a normal Voice call.
6. A method as claimed in claim 1 wherein the receiver is adapted to auto play the Short Voice Message.
7. A method as claimed in claim 1 wherein the receiver is adapted to post date the SVM.
8. A system for sending short voice message comprising:
a transmitting device initiating an SVM feature (Short Voice Messaging feature) and recording voice message;
a network for transmitting the call setup message as a normal voice call;
a receiver for decoding the received call setup message and interpreting the call as a Voice message during call setup; and
memory for recording and storing voice message in receivers inbox,
where the receiver sets up parameters for recording the voice message and when the call setup is established the transmitting device transmits recorded voice message directly to the recipient.
9. A method for sending short voice message substantially described and explained with reference to the drawings.
10. A system for sending short voice message substantially described and explained with reference to the drawings.

Documents:

1130-CHE-2006 EXAMINATION REPORT REPLY RECEIVED 03-06-2013.pdf

1130-CHE-2006 FORM-1 03-06-2013.pdf

1130-CHE-2006 FORM-13 03-06-2013.pdf

1130-CHE-2006 FORM-3 03-06-2013.pdf

1130-CHE-2006 OTHER PATENT DOCUMENT 03-06-2013.pdf

1130-CHE-2006 OTHER PATENT DOCUMENT 1 03-06-2013.pdf

1130-CHE-2006 AMENDED CLAIMS 01-07-2013.pdf

1130-CHE-2006 AMENDED CLAIMS 03-06-2013.pdf

1130-CHE-2006 AMENDED CLAIMS 13-06-2013.pdf

1130-CHE-2006 AMENDED PAGES OF SPECIFICATION 01-07-2013.pdf

1130-CHE-2006 AMENDED PAGES OF SPECIFICATION 03-06-2013.pdf

1130-CHE-2006 EXAMINATION REPORT REPLY RECEIVED 01-07-2013.pdf

1130-CHE-2006 EXAMINATION REPORT REPLY RECEIVED 13-06-2013.pdf

1130-CHE-2006 FORM-1 01-07-2013.pdf

1130-CHE-2006 POWER OF ATTORNEY 01-07-2013.pdf

1130-CHE-2006 POWER OF ATTORNEY 03-06-2013.pdf

1130-CHE-2006 POWER OF ATTORNEY 13-06-2013.pdf

1130-CHE-2006 ABSTRACT.pdf

1130-CHE-2006 CLAIMS.pdf

1130-CHE-2006 CORRESPONDENCE OTHERS.pdf

1130-CHE-2006 DESCRIPTION (COMPLETE).pdf

1130-CHE-2006 DRAWINGS.pdf

1130-CHE-2006 FORM 1.pdf

1130-CHE-2006 FORM 18.pdf

1130-CHE-2006 FORM 5.pdf

1130-che-2006-correspondence-others.pdf

1130-che-2006-description(provisional).pdf

1130-che-2006-drawings.pdf

1130-che-2006-form1.pdf

1130-che-2006-form26.pdf


Patent Number 256600
Indian Patent Application Number 1130/CHE/2006
PG Journal Number 28/2013
Publication Date 12-Jul-2013
Grant Date 05-Jul-2013
Date of Filing 30-Jun-2006
Name of Patentee SAMSUNG INDIA SOFTWARE OPERATIONS PRIVATE LIMITED,
Applicant Address BLOCK 'B' NO.66/1 , BAGMANE PARK, C V RAMAN NAGAR, BYRASANDRA, BANGALORE-560093.
Inventors:
# Inventor's Name Inventor's Address
1 SUSAMA PATHY BLOCK 'B' NO.66/1 , BAGMANE PARK , C V RAMAN NAGAR, BYRASANDRA , BANGALORE-560 093
2 ROY SINGH BIRDI BLOCK 'B' NO-66/1, BAGMANE TECH PARK, CV RAMAN NAGAR, BYRASANDRA, BANGALORE-560093.
PCT International Classification Number H04M 1/64
PCT International Application Number N/A
PCT International Filing date
PCT Conventions:
# PCT Application Number Date of Convention Priority Country
1 NA