Patent Application
20130128801
The present disclosure generally relates to the use of short-message service (SMS) messages as a delivery channel for a multi-platform instant messaging service.
Short Message Service (SMS) functionality is an existing part of a number of different mobile telephony standards. These messages are typically restricted to 160 character messages, and are transmitted through control channels in many mobile telephony networks. Users are often charged by their carrier for sending or receiving messages, although in many networks incoming messages are freely delivered, and many carriers also offer rate plans that provide for either unlimited messaging or a very high volume of messages in a fixed fee package.
To provide SMS sending capabilities to users who do not want to use a mobile phone to send an SMS, some carriers provide an SMS sending service through a web-based interface. An example of such a service is shown in
Instant messaging services have proven to be very popular with a number of different market segments. Conventionally, these services have been single platform services that have relied on a data-packet based delivery channel. Among these popular services are Microsoft™'s MSN Messenger, and Yahoo!™'s Yahoo! Messenger. These platforms allow users to login to a server that tracks presence information about each user. By accessing the presence information associated with a list of contacts, users are able to find contacts that are online, and engage them in a chat session. One problem that users experience with these services is that they typically rely on a client designed for the computing platform of choice, or is accessed through a webpage. When a user starts a chat session using a desktop computer, and then moves to a different platform such as a mobile device, these services often treat the changeover as the start of a new chat session.
Some of these services have recognized the need to reach users that are not online, and thus allow users to send messages, through the chat server, to a phone number associated with a chat contact. In most of these systems, the setup is similar to the one shown in
To address this problem, a solution has been offered as shown in
This solution enables users to reach each other after a chat session has ended, but causes a series of different problems. Although the messages received on mobile device 58 can be replied to, based on the length of time that the pair-wise unique mapping is maintained, MSISDN168a cannot be relied upon as a number that the mobile device 58 can permanently associate with user 1. If the length of time is very large, it would require the entity offering the chat application to maintain a large pool of MSISDN's which is very expensive, and then still requires that user 2 assign a phone number to user 1 that can only be used during a chat session. As such, it is impractical for user 2 to be able to use the sending MSISDN of an incoming message to identify the sender of the address. Furthermore, there is no context associated with the message, as there is no indication of the previous messages that were exchanged via the chat session.
Other solutions to this problem have been to create chat clients for mobile devices that rely on a packet data delivery system. This is feasible on third generation (3G) networks and their successor networks (such as IEEE 802.16, commonly known as Worldwide Interoperability for Microwave Access (WiMax) and Long Term Evolution (LTE)), but still requires that users subscribe to the service and that they maintain themselves as online using these services. This generates more data traffic, which is a double edged sword for carriers. Although a carrier is able to charge for the use of data services, building a sufficiently robust data network is difficult for many carriers in high demand environments. Furthermore, for many users this requires the addition of a data service which comes with an associated cost.
Some services, such as voice-over-IP, allow a user to make use of a bridge between packet switched data services, such as the Internet, and circuit switched voice networks such as the Public Switched Telephone Network (PSTN). Some of these services allow a user to make outbound calls that are reported to the recipient as having originated at the MSISDN of another device. This allows a user to initiate a telephone call from a computer, and have the recipient see the caller ID data associated with the user's mobile phone. This is done through the control of the data provided in the Signaling System Seven (SS7) signaling channels. Skype™ provides such a service. Because these services recognize the need for their users to be able to have many different communication routes, many offer the ability for the user to send an SMS message. The delivery mechanism for these services is similar to that illustrated in
Chat services in the existing art do not typically allow users to easily switch between platforms. To offer users the ability to easily recognize who is sending a message, they require the use of data services which may not be available to all users.
SMS messages provide a number of advantages to carriers. Whereas the delivery of data packets involves the use of an otherwise scarce resource (bandwidth assigned to data), SMS messages are often thought of as traveling for free. SMS messages are sent through dedicated control channels, and make use of otherwise unused bandwidth. The fact that they can be charged for only increases the interest that carriers have in their use. SMS messages have proven so popular that extensions are offered that allow devices to split a message that exceeds 160 characters into more than one message (so-called long SMS message), and allow the receiving devices to recognize these multi-part messages as single messages for display. Additionally, Multimedia Message Service (MMS) messages have also been offered that allow SMS messages to be used as a delivery mechanism for rich content such as photos and videos.
Accordingly, it should be readily appreciated that it would be advantageous to provide a solution that allows carriers to leverage their investment in the SMS infrastructure to provide chat services to users on a plurality of different platforms.
It is an object of the present invention to obviate or mitigate at least one disadvantage of the prior art.
In a first aspect of the present invention there is provided a method for distributing messages by a network messaging center. The method comprises the steps of receiving a message from a first entity, associated with a first Mobile Subscriber Integrated Services Digital Network Number (MSISDN), addressed to a second MSISDN; transmitting the received message to the second MSISDN; and forwarding a copy of the received message to a second entity associated with the first MSISDN. The first entity can be a device to which the first MSISDN has been assigned, and the second entity can be an active address book associated with the first MSISDN. Alternatively, the first entity can be an active address book associated with the first MSISDN, and the second entity can be a device to which the first MSISDN has been assigned. The copy of the received message can be modified to indicate the first MSISDN as the sender. The step of forwarding the copy of the received message can be performed in response to determining that a suspend delivery condition is not active. The copy of the received message can be buffered prior to forwarding the copy to the second entity. The step of buffering can be performed in response to determining that a suspend delivery condition is active. Determining a suspend delivery condition to be active can be in accordance with activity associated with at least one of the first and second entities. A suspend delivery condition can apply to all messages addressed to the first MSISDN. A suspend delivery condition can apply to all messages associated with the second MSISDN.
In a second aspect of the present invention there is provided a method for distributing messages by a network messaging center. The method comprises the steps of receiving a message from a first Mobile Subscriber Integrated Services Digital Network Number (MSISDN) addressed to a second MSISDN; forwarding the received message to an entity associated with the second MSISDN; and withholding transmission of the received message to a device to which the second MSISDN has been assigned, in response to determining a suspend delivery condition associated with the second MSISDN is active. The entity associated with the second MSISDN can an active address book. The received message can be buffered for later delivery. The received message can be transmitted to the device to which the second MSISDN has been assigned in response to determining the suspend delivery condition is not active. The step of transmitting can include retrieving the withheld message from a storage, such as a Network Storage Solution.
In another aspect of the present invention there is provided a Short Message Service Center (SMS-C) node. An SMS-C interface is for sending messages to and receiving messages from a second SMS-C. A mobile device interface is for sending messages to and receiving messages from a mobile device to which a Mobile Subscriber Integrated Services Digital Network Number (MSISDN) has been assigned. An active address book interface is for sending messages to and receiving messages from an entity associated with the MSISDN. A processor is for receiving a message over one of the SMS-C interface, the mobile device interface, and the active address book interface and for forwarding the received message to the other two interfaces. The SMS-C can further comprise a buffer for queuing messages forwarded to the mobile device interface. The processor can include a delivery suspension engine for determining a suspend delivery condition associated with the MSISDN is active, and for forwarding the received message to a buffer in response to the determination. The processor can include a modification engine for modifying the received message prior to forwarding the message to the mobile device interface.
Other aspects and features of the present invention will become apparent to those ordinarily skilled in the art upon review of the following description of specific embodiments of the invention in conjunction with the accompanying figures.
Embodiments of the present invention will now be described, by way of example only, with reference to the attached Figures, wherein:
The present invention is directed to a system and method for distributing SMS messages during a chat session.
In the following discussion, methods and systems for providing chat type services will be discussed in the context of an SMS-based transport layer. Although the following discussion is based around users making use of a web-based chat client, any user client can be used. Clients can be specifically designed to work with a variety of computer operating systems, including mobile device operating systems. Although the discussion below focuses on a single non-mobile device interface, this is done for the sake of simplicity and it should be understood by those skilled in the art that other interfaces to the system described below can be implemented without departing from the scope of the present invention.
SMS messaging is a reliable and convenient transport mechanism for messages. The SMS delivery infrastructure can be leveraged to provide message transport layer for an instant messaging system. A non-mobile phone interface can provide a mechanism for both sending and receiving messages associated with an MSISDN that is assigned to a handset associated with a user. When messages are sent, they are preferably addressed from the MSISDN associated with the sending user. Thus, a recipient will receive the messages and they will appear as being sent from the sender's phone number. This allows the recipient to reply to the message and have the messages routed to the original sender's phone. In a further refinement, the SMS message can also be relayed back to the non-mobile phone interface. Two users using the non-phone interface will be able to have a live chat session without needing to interact through their mobile phones. If one of the parties leaves the computer, the chat can continue as the messages are directed to the MSISDN associated with each party, so the SMS messages will still be delivered to the phone. Replies from the mobile phone will still be delivered to the other party. The use of such a non-mobile phone interface for sending and receiving SMS messages can be completely transparent to the other party.
Some carriers offer a service referred to as an active address book. This service can be accessed over a data network such as the Internet and provides a user with the ability to synchronize contact information with a server provided by the carrier. Through these services, the user is able to make use of a series of different services. The interface to the active address book is often a web-based interface, and it can be used to provide the user with the ability to send SMS messages to contacts in the active address book directly from the web-based interface. The ability to use a full keyboard, and have access to a secure address book to select the people to whom to send the message are often seen as benefits of this service. As part of the use of an active address book, users are required to login to a secure server. This is sufficient proof to the carrier that the user of a service is associated with the subscriber associated with an account. The subscriber's account is also associated with an MSISDN, the MSISDN that is associated with the user's mobile device or phone. By allowing the active address book to both send messages on behalf on an MSISDN, and receive messages addressed to the MSISDN, an Instant Message-like chat service is created.
Referring now to
Although the user is able to continue the chat session from either entity, the problem arises that messages sent by the user from one of the two entities are only displayed on the entity that sent the message. This means that the user will have only a fragment of his own side of the conversation although the other part of the conversation will be complete. This impairs the ability of the user to understand the full context of the communication at a later point in time.
Another potential issue with such a system is that a user who is engaged in a chat session will often be generating a large number of messages on the computer 70. When a reply comes in, the user receives the reply on the computer 70 through AAB 72 but is also provided with a second notification on the phone 78. Typically, handset 78 will generate a notification for the received message. This can be distracting to the user who may not want to be alerted of receipt of a message that he may already be composing a reply to.
The “from” address can be either left the same so that the user sees that the message 116 came from him, in which case it will be a message from MSISDN1 to MSISDN1, or it can be modified so that another number is identified as the sender. In one option, the SMS-C 94 modifies the “from” address so that it is replaced with an address identified with the chat service. The body of the message can also be modified to include a tag. This tag could be used by an intelligent SMS client on a phone to associate the message with the identified recipient. In one embodiment, the body could be modified to be “[chat to MSISDN2]+[body]”. In another option, the “from” address could be modified to appear to be from MSISDN2, with a modification to the body indicating that the message 116 was actually originated from MSISDN1. This would allow the SMS client on the phone to automatically group the message with other between the two users. The body could also be modified (e.g. “[from you]+[body]”). As such, messages composed on the AAB 90 can be modified at the SMS-C 94 to identify the chat session by modifying the “from” address, the body of the message, or both of those fields.
This allows the user to not receive dual notifications of the received message 122 on both the computer and the handset 92. Determination of user presence can be done by determining if the user is logged in. If the user is not logged in, such a message 121 would not be provided to the SMS-C 94. If the user is logged in, but idle, the request for suspension message 121 can be cancelled.
It should be noted that it is uncommon for the suspension of message delivery to be utilized as a feature providing a service to a user. Typically, delivery suspension to a device to which an MSISDN has been assigned only occurs as a result of network issues, service interruption or the device being unavailable (e.g. device is powered off).
The SMS-C 94 determines a suspend delivery condition for the MSISDN associated with the user (i.e. MSISDN1), and forwards any received message, such as SMS 122, to the AAB 90 associated with MSISDN1 without transmitting the received message to the device 92 to which MSISDN1 has been assigned. During a suspend delivery condition, the SMS-C 94 can optionally delay or buffer any received messages. These messages can be queued for delivery to the device 92 upon determining that the suspend delivery condition is no longer active.
At some point, it may be determined that the user is no longer using the AAB 90. This may be the result of the user explicitly logging out, or of a message being delivered to the AAB 90, and the AAB 90 determining that the user has not read the message. It may also be the result of the AAB 90 determining that no activities have been performed at the computer. Another option is that when the user makes use of the phone 92 to send a message, the SMS-C 94 can determine that the handset is now an active platform. Alternatively, if a message is sent from the handset 92 and a copy is delivered to the AAB 90, it can serve as a trigger to the AAB 90 to release the delivery suspension condition.
Referring now to
Optionally, the client release notification 132 can trigger the SMS-C 94 to transmit a message 136 to a party in an active chat session as a notification that the user associated with MSISDN1 has now gone mobile. This will allow the other party to be aware that messages may be shorter, and may not be as frequent. This type of presence information can be transmitted as an SMS message 136. An AAB or an enhanced SMS client on a handset could receive this message 136 and use it to provide a status for the user who sent it.
In an alternate embodiment, instead of delivering each of the queued messages separately in step 135, a digest of the messages can be sent to the handset 92. In one embodiment, the digest can be an MMS message that provides a single document showing the conversation back and forth. The MMS message can contain a tag that would allow an SMS client to identify the digest as part of a conversation, parse the message to determine the two parties, and render the message as plaintext messages. Optionally, these messages can be inserted into a display format along with any other messages associated with MSISDN1 and MSISDN2.
In another alternate embodiment, the digest can be sent by flooding to and from messages to the handset 92 as SMS messages. The messages to MSISDN1 will be time-stamped, so a client would be able to put them into the correct order. Messages from MSISDN1 could be sent with modified addressing or bodies allowing identification by a smart client, or they could be sent with a modified body that allows the user to see who the messages were sent to (e.g. “[sent to MISDN2]+[body]”). Where needed, multipart messages can be sent to accommodate longer messages.
Those skilled in the art will appreciate that an entity can be any device which is assigned an MSISDN such as a phone, a mobile device, a tablet, a smart phone, etc. An entity can also be any service authorized to send and/or receive messages on behalf of a user associated with an MSISDN. Examples of such services are active address books, instant messaging applications, chat clients, etc.
In an alternative embodiment, the messaging center can determine a suspend delivery condition associated with the first MSISDN is active and the copy of the received message can be buffered prior to the step of forwarding 204. Forwarding the copy of the received message 204 can be performed in response to determining that the suspend delivery condition is no longer active.
Optionally, the suspend delivery condition can be determined to be active in accordance with an activity associated with the first or second entities. Examples of such activities include the use of the AAB to send or read a message, the user receiving but not reading a message on the handset while active on the AAB, other active uses of the AAB, and other non-messaging activities on the handset while logged into the AAB. The suspend delivery condition can apply to all messages addressed to the first MSISDN, or alternatively, all messages associated with the second MSISDN.
Although the above discussion has focused on determining that a delivery suspension is in place, and then buffering any received messages for later delivery, in other embodiments, the received messages can simply be discarded instead of queued for later delivery.
Optionally, the SMS-C 94 can include a buffer 228 for queuing messages forwarded from the processor 226 to the mobile device interface 222. The buffer 228 can store messages prior to forwarding them over the mobile device interface 222. Optionally, the processor 226 can include a delivery suspension engine for determining a suspend delivery condition associated with the MSISDN. The delivery suspension engine can forward a received message to the buffer 228 in response to determining a suspend delivery condition. Optionally, the processor 226 can also include a modification engine for modifying a received message to indicate the MSISDN as the sender prior to forwarding the message. Other interfaces can be buffered as well, as will be understood by those skilled in the art.
Those skilled in the art will appreciate that the node shown in
As indicated above, the SMS-C can set a suspend delivery condition to be active, which will prevent delivery of messages to the mobile device. Conversely, the SMS-C can also set the suspend delivery condition to not be active, thus allowing delivery of received messages. One skilled in the art will appreciate that if messages have been buffered, upon determining that the suspend delivery condition has been inactivated, the buffered message will then be delivered to the handset.
The suspend delivery condition can be associated only with the MSISDN of the handset, in which case delivery of all messages addressed to the MSISDN will be withheld. Conversely, the suspend delivery condition could be applied to the MSISDN of the second party, in which case only messages in a particular conversation stream would be withheld, allowing the on-handset notification to occur if a third party sends a message. Those skilled in the art will appreciate that other conditions can be set without departing from the intended scope of protection.
When determining if a suspend delivery condition should be applied to messages associated with an MSISDN, the SMS-C can base the activation of the suspend delivery condition on the use of the AAB to send a message, the reading of a received message on the AAB, the user receiving but not reading a message on the handset while active on the AAB, other active uses of the AAB, and other non-messaging activities on the handset while logged into the AAB (e.g. while logged in to the AAB, and while the handset is in active use for a voice call). These conditions can be selectable and customizable by the user.
In determining that a suspend delivery condition should be inactivated, the SMS-C can take into account a number of activities including the logging out of the user at the AAB, the user not using the AAB for a predetermined length of time (e.g. a timeout condition), and activity from the handset (e.g. if a user sends a message from the handset it may indicate that the user is no longer using the AAB).
One skilled in the art will appreciate that a suspend delivery condition may be activated when activities at the handset and AAB are broadly indicative that the user is using the AAB and not the handset. Similarly, the suspend delivery condition can be inactivated, or set to not active, when the user activities at the AAB and the handset indicate that the user is better served by not receiving messages exclusively at the AAB.
Based upon the foregoing, it should now be apparent to those of ordinary skill in the art that the present disclosure provides an advantageous solution. Although the system and method of the present disclosure have been described with particular reference to certain type of messages and nodes, it should be realized upon reference hereto that the innovative teachings contained herein are not necessarily limited thereto and may be implemented advantageously in various manners. It is believed that the operation and construction of the present disclosure will be apparent from the foregoing description.
Embodiments of the invention may be represented as a software product stored in a non-transitory machine-readable medium (also referred to as a computer-readable medium, a processor-readable medium, or a computer-usable medium having a computer-readable program code embodied therein). The machine-readable medium may be any suitable tangible medium including a magnetic, optical, or electrical storage medium including a diskette, compact disk read only memory (CD-ROM), digital versatile disc read only memory (DVD-ROM), memory device (volatile or non-volatile), or similar storage mechanism. The machine-readable medium may contain various sets of instructions, code sequences, configuration information, or other data, which, when executed, cause a processor to perform steps in a method according to an embodiment of the invention. Those of ordinary skill in the art will appreciate that other instructions and operations necessary to implement the described invention may also be stored on the machine-readable medium. Software running from the machine-readable medium may interface with circuitry to perform the described tasks.
The above-described embodiments of the present invention are intended to be examples only. Alterations, modifications and variations may be effected to the particular embodiments by those skilled in the art without departing from the scope of the invention, which is defined by the claims appended hereto.
