US20070088787A1 - System and method of handling messages for forwarding field of the invention - Google Patents

System and method of handling messages for forwarding field of the invention Download PDF

Info

Publication number
US20070088787A1
US20070088787A1 US11/249,507 US24950705A US2007088787A1 US 20070088787 A1 US20070088787 A1 US 20070088787A1 US 24950705 A US24950705 A US 24950705A US 2007088787 A1 US2007088787 A1 US 2007088787A1
Authority
US
United States
Prior art keywords
message
message object
sms
donor
mail
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
US11/249,507
Other versions
US8745140B2 (en
Inventor
Michael Hardy
Robin Glennie
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Malikie Innovations Ltd
Original Assignee
Research in Motion Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Research in Motion Ltd filed Critical Research in Motion Ltd
Priority to US11/249,507 priority Critical patent/US8745140B2/en
Assigned to RESEARCH IN MOTION LIMITED reassignment RESEARCH IN MOTION LIMITED ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: GLENNIE, ROBIN ROY, HARDY, MICHAEL THOMAS
Priority to US11/554,999 priority patent/US8819144B2/en
Publication of US20070088787A1 publication Critical patent/US20070088787A1/en
Assigned to BLACKBERRY LIMITED reassignment BLACKBERRY LIMITED CHANGE OF NAME (SEE DOCUMENT FOR DETAILS). Assignors: RESEARCH IN MOTION LIMITED
Application granted granted Critical
Publication of US8745140B2 publication Critical patent/US8745140B2/en
Assigned to MALIKIE INNOVATIONS LIMITED reassignment MALIKIE INNOVATIONS LIMITED ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: BLACKBERRY LIMITED
Assigned to MALIKIE INNOVATIONS LIMITED reassignment MALIKIE INNOVATIONS LIMITED NUNC PRO TUNC ASSIGNMENT (SEE DOCUMENT FOR DETAILS). Assignors: BLACKBERRY LIMITED
Active legal-status Critical Current
Adjusted expiration legal-status Critical

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L51/00User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail
    • H04L51/21Monitoring or handling of messages
    • H04L51/214Monitoring or handling of messages using selective forwarding
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W4/00Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/12Messaging; Mailboxes; Announcements
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L51/00User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04MTELEPHONIC COMMUNICATION
    • H04M1/00Substation equipment, e.g. for use by subscribers
    • H04M1/72Mobile telephones; Cordless telephones, i.e. devices for establishing wireless links to base stations without route selection
    • H04M1/724User interfaces specially adapted for cordless or mobile telephones
    • H04M1/72403User interfaces specially adapted for cordless or mobile telephones with means for local support of applications that increase the functionality
    • H04M1/7243User interfaces specially adapted for cordless or mobile telephones with means for local support of applications that increase the functionality with interactive means for internal management of messages
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04MTELEPHONIC COMMUNICATION
    • H04M1/00Substation equipment, e.g. for use by subscribers
    • H04M1/72Mobile telephones; Cordless telephones, i.e. devices for establishing wireless links to base stations without route selection
    • H04M1/724User interfaces specially adapted for cordless or mobile telephones
    • H04M1/72403User interfaces specially adapted for cordless or mobile telephones with means for local support of applications that increase the functionality
    • H04M1/7243User interfaces specially adapted for cordless or mobile telephones with means for local support of applications that increase the functionality with interactive means for internal management of messages
    • H04M1/72436User interfaces specially adapted for cordless or mobile telephones with means for local support of applications that increase the functionality with interactive means for internal management of messages for text messaging, e.g. SMS or e-mail
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04MTELEPHONIC COMMUNICATION
    • H04M1/00Substation equipment, e.g. for use by subscribers
    • H04M1/72Mobile telephones; Cordless telephones, i.e. devices for establishing wireless links to base stations without route selection
    • H04M1/724User interfaces specially adapted for cordless or mobile telephones
    • H04M1/72469User interfaces specially adapted for cordless or mobile telephones for operating the device by selecting functions from two or more displayed items, e.g. menus or icons
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46Multiprogramming arrangements
    • G06F9/54Interprogram communication
    • G06F9/542Event management; Broadcasting; Multicasting; Notifications
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W4/00Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/18Information format or content conversion, e.g. adaptation by the network of the transmitted or received information for the purpose of wireless delivery to users or terminals
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W88/00Devices specially adapted for wireless communication networks, e.g. terminals, base stations or access point devices
    • H04W88/02Terminal devices
    • H04W88/06Terminal devices adapted for operation in multiple networks or having at least two operational modes, e.g. multi-mode terminals
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W88/00Devices specially adapted for wireless communication networks, e.g. terminals, base stations or access point devices
    • H04W88/18Service support devices; Network management devices
    • H04W88/184Messaging devices, e.g. message centre

Definitions

  • the present application relates to electronic messaging and, in particular, the handling of a message received on a first message handling service for forwarding on a second message handling service.
  • SMS Short Message Service
  • WAP Wireless Application Protocol
  • HTTP Hyper-Text Transfer Protocol
  • an exemplary wireless communication device may require an SMS client application, an e-mail client application, a WAP browsing application and an HTML browsing application.
  • the e-mail client application may present a user interface screen with various editboxes corresponding to fields of a standard e-mail message.
  • Such fields including a field for indicating a recipient, a field for indicating a subject and a field for the body of the e-mail message.
  • the user may then paste the previously copied payload of the SMS message into the editbox of the user interface screen, which editbox corresponds to the body field of the new outgoing e-mail message, specify a subject and a recipient and then direct the e-mail client application to send the new outgoing message.
  • FIG. 1 illustrates elements of an exemplary network environment for a first wireless mobile communication device
  • FIG. 2 illustrates components of the first wireless mobile data communication device of FIG. 1 , according to an embodiment of the present application
  • FIG. 3 illustrates steps in a known method of processing messages for forwarding
  • FIG. 4 illustrates steps in a method of handling messages for forwarding according to an embodiment of the present application
  • FIG. 5 illustrates an exemplary e-mail message viewing screen presented by a user interface object for a received e-mail donor message object that implements a new interface
  • FIG. 6 illustrates the exemplary e-mail message viewing screen of FIG. 5 overlaid by a dialog according to an embodiment of the present application
  • FIG. 7 illustrates an exemplary SMS message composition screen resulting from the selection of the e-mail option in the dialog of FIG. 6 ;
  • FIG. 8 illustrates steps in a method of processing a donor message object to produce a recipient message object according to an embodiment of the present application
  • FIG. 9 illustrates an exemplary SMS message viewing screen presented by a user interface object for a received SMS donor message object that implements the new interface
  • FIG. 10 illustrates the exemplary SMS message viewing screen of FIG. 9 overlaid by a dialog according to an embodiment of the present application.
  • FIG. 11 illustrates an exemplary e-mail message composition screen resulting from the selection of the e-mail option in the dialog of FIG. 10 .
  • a message received, over a first message handling service, on a mobile wireless communication device may be forwarded using a second message handling service.
  • Message model classes, on which message objects within the wireless communication device are based, are altered to implement a new interface and include method calls for determining, before requesting information elements from a second message object, whether the second message object implements the new interface. Accordingly, when a user wishes to forward a received message object associated with a first message handling service, the user may be provided, by a new verb object, with the option to forward the received message object as a new message object associated with a second message handling service. In the event that the user exercises the option, the new verb object selects a previously existing verb object for generating the new message object associated with the second message handling service.
  • the new verb object passes the received message object to the previously existing verb object for the second message handling service and forwarding is accomplished normally from the perspective of the previously existing verb object.
  • the new message object is based on an altered model class and, before requesting information elements from the received message object, determines whether the received message object implements the new interface.
  • a method of handling a received message for forwarding includes receiving a donor message object and determining whether the donor message object implements a predetermined interface class. If the donor message object implements the predetermined interface class, the method further includes requesting an information element from the donor message object via an implementation of the predetermined interface class, receiving the information element and populating a recipient message object with the information element.
  • a communication device is provided, with a processor adapted to perform this method, and a computer readable medium is provided to adapt a communication device to perform this method.
  • a method of handling a received message for forwarding includes receiving a received message object, where the received message object implements a predetermined interface class, and, responsive to the receiving the received message object, presenting a dialog, where the dialog includes a plurality of options, each option of the plurality of options corresponding to a type of message handling service.
  • the method further comprises receiving an indication of a selected option and, responsive to the receiving the indication of the selected option, passing the received message object to a verb object associated with a message handling service corresponding to the selected option.
  • a communication device is provided, with a processor adapted to perform this method, and a computer readable medium is provided to adapt a communication device to perform this method.
  • FIG. 1 illustrates elements of an exemplary network environment 100 for a first wireless mobile communication device 101 A.
  • the elements of the exemplary network environment 100 include multiple wireless carrier networks and a data communication network 108 , which may be considered to represent at least one wide area network, such as the present day Internet and successors, as well as, potentially, multiple local area networks.
  • a first base station antenna 102 A, with which the first wireless mobile communication device 101 A may communicate wirelessly, is provided as part of a first base station subsystem 104 A.
  • the first base station subsystem 104 A connects to a first wireless network subsystem 106 A.
  • the first wireless network subsystem 106 A includes, among other components, a mobile services switching center, a home location register, a visitor location register, a relay and a Short Messaging Service Center (SMSC). As illustrated in FIG. 1 , the first wireless network subsystem 106 A is connected to the data communication network 108 .
  • GSM Global System for Mobile communications
  • SMSC Short Messaging Service Center
  • a second wireless network subsystem 106 B is Also connected to the data communication network 108 . Similar to the first wireless network subsystem 106 A, the second wireless network subsystem 106 B may include a mobile services switching center, a home location register, a visitor location register, a relay and an SMSC. The second wireless network subsystem 106 A connects to a second base station subsystem 104 B with a second base station antenna 102 B. The second base station antenna 102 B may allow the second base station subsystem 104 B to communicate wirelessly with a second mobile device 101 B.
  • the first mobile device 101 A may be associated with an enterprise 110 connected to the data communication network 108 .
  • the enterprise 110 may, for instance, include a firewall or proxy server 112 connecting to the data communication network 108 and to a local area network (LAN) 114 .
  • the LAN 114 may allow communication between a mobile device server 116 and an enterprise server 118 .
  • Also connected to the data communication network 108 may be an e-mail server 120 and a desktop computer 122 , which may be associated with a user having an account on the e-mail server 120 . Also connected to the data communication network 108 may be a messaging portal 124 .
  • FIG. 2 illustrates the first wireless mobile communication device 101 A including a housing, an input device (a keyboard 214 ), and an output device (a display 226 ), which is preferably a full graphic or full color Liquid Crystal Display (LCD). Other types of output devices may alternatively be utilized.
  • a processing device (a microprocessor 228 ) is shown schematically in FIG. 2 as coupled between the keyboard 214 and the display 226 . The microprocessor 228 controls the operation of the display 226 , as well as the overall operation of the first mobile device 101 A, in response to actuation of keys on the keyboard 214 by a user.
  • the housing may be elongated vertically, or may take on other sizes and shapes (including clamshell housing structures).
  • the keyboard may include a mode selection key, or other hardware or software, for switching between text entry and telephony entry.
  • the first mobile device 101 A may have a battery 222 to power the active elements of the first mobile device 101 A.
  • the first mobile device 101 A is preferably a two-way radio frequency (RF) communication device having voice and data communication capabilities.
  • the first mobile device 101 A preferably has the capability to communicate with other computer systems via the Internet.
  • RF radio frequency
  • Operating system software executed by the microprocessor 228 is preferably stored in a computer readable medium, such as the flash memory 216 , but may be stored in other types of memory devices, such as a read only memory (ROM) or similar storage element.
  • system software, specific device applications, or parts thereof may be temporarily loaded into a volatile store, such as the RAM 218 .
  • Communication signals received by the mobile device may also be stored to the RAM 218 .
  • the microprocessor 228 in addition to its operating system functions, enables execution of software applications on the first mobile device 101 A.
  • a predetermined set of software applications that control basic device operations such as a voice communications module 230 A and a data communications module 230 B, may be installed on the first mobile device 101 A during manufacture.
  • An e-mail client application module 230 C may also be installed on the first mobile device 101 A during manufacture, to implement aspects of the application.
  • an SMS client application module 230 D may also be installed on the first mobile device 101 A during manufacture, to implement aspects of the application.
  • additional software modules illustrated as an other software module 230 N, which may be, for instance, a personal information manager (PIM) application, may be installed during manufacture.
  • PIM personal information manager
  • the PIM application is preferably capable of organizing and managing data items, such as e-mail messages, calendar events, voice mail messages, appointments, and task items.
  • the PIM application is also preferably capable of sending and receiving data items via a wireless carrier network represented in FIG. 2 by the first base station antenna 102 A.
  • the data items managed by the PIM application are seamlessly integrated, synchronized and updated via the wireless carrier network with the device user's corresponding data items stored or associated with a host computer system.
  • the communication subsystem 240 includes a receiver 250 , a transmitter 252 and one or more antennas, illustrated as a receive antenna 254 and a transmit antenna 256 .
  • the communication subsystem 240 also includes a processing module, such as a digital signal processor (DSP) 258 , and local oscillators (LOs) 260 .
  • DSP digital signal processor
  • LOs local oscillators
  • the communication subsystem 240 of the first mobile device 101 A may be designed to operate with the MobitexTM, DataTACTM or General Packet Radio Service (GPRS) mobile data communication networks and may also be designed to operate with any of a variety of voice communication networks, such as Advanced Mobile Phone Service (AMPS), Time Division Multiple Access (TDMA), Code Division Multiple Access (CDMA), Personal Communications Service (PCS), Global System for Mobile Communications (GSM), etc.
  • AMPS Advanced Mobile Phone Service
  • TDMA Time Division Multiple Access
  • CDMA Code Division Multiple Access
  • PCS Personal Communications Service
  • GSM Global System for Mobile Communications
  • Other types of data and voice networks, both separate and integrated, may also be utilized with the first mobile device 101 A.
  • the first mobile device 101 A may send and receive communication signals over the wireless carrier network.
  • Signals received from the first base station antenna 102 A by the receive antenna 254 are routed to the receiver 250 , which provides for signal amplification, frequency down conversion, filtering, channel selection, etc., and may also provide analog to digital conversion. Analog-to-digital conversion of the received signal allows the DSP 258 to perform more complex communication functions, such as demodulation and decoding.
  • signals to be transmitted to the base station antenna 102 A are processed (e.g., modulated and encoded) by the DSP 258 and are then provided to the transmitter 252 for digital to analog conversion, frequency up conversion, filtering, amplification and transmission to the first base station antenna 102 A via the transmit antenna 256 .
  • the DSP 258 provides for control of the receiver 250 and the transmitter 252 .
  • gains applied to communication signals in the receiver 250 and the transmitter 252 may be adaptively controlled through automatic gain control algorithms implemented in the DSP 258 .
  • a received signal such as an SMS message or web page download
  • the communication subsystem 240 is input to the microprocessor 228 .
  • the received signal is then further processed by the microprocessor 228 in preparation for output to the display 226 , or alternatively to some other auxiliary I/O devices 206 .
  • a device user may also compose data items, such as e-mail messages or SMS messages, using the keyboard 214 and/or some other auxiliary I/O device 206 , such as a touchpad, a rocker switch, a thumb-wheel, or some other type of input device.
  • the composed data items may then be transmitted to the base station antenna 102 A via the communication subsystem 240 .
  • a voice communication mode In a voice communication mode, overall operation of the device is substantially similar to the data communication mode, except that received signals may be output to the speaker 211 , and signals for transmission may be generated by the microphone 212 .
  • Alternative voice or audio I/O subsystems such as a voice message recording subsystem, may also be implemented on the first mobile device 101 A.
  • the display 226 may also be utilized in voice communication mode, for example, to display the identity of a calling party, the duration of a voice call, or other voice call related information.
  • the short-range communications subsystem 202 enables communication between the first mobile device 101 A and other proximate systems or devices, which need not necessarily be similar devices.
  • the short-range communications subsystem 202 may include an infrared device and associated circuits and components, or a BluetoothTM communication module, to provide for communication with similarly-enabled systems and devices.
  • An SMS message Protocol Data Unit includes a Payload element, Routing Data elements and elements including other metadata. It may be, as is currently typical, that the first mobile device 101 A executes code developed using object oriented programming techniques. In which case, an SMS message PDU received the first mobile device 101 A may be used as a basis, by code executed on the microprocessor 228 , for the creation of a new SMS message object.
  • the new SMS message object may be created as an instance of an SMS message model class, which defines an organization of the payload, routing data and other metadata found in the SMS message PDU.
  • the SMS message model class may also identify those actions that may be performed on the new SMS message object, such as Open, Reply, Forward, etc. Such actions may be performed on the new SMS message object responsive to user interaction with a user interface object.
  • an SMS message object may be considered to relate to instances of “verb” classes that are specific to the message handling service.
  • a verb is an object encapsulation of an action in the JavaTM programming language.
  • a verb is often, but not necessarily, presented to the user as an item in a pull down menu or hotkey; a verb contains the code to perform the action on a related data model and information on how to represent itself to the user in zero or more ways.
  • an SMS Open verb class may be associated with a method that presents a screen on the display 226 in which relevant data regarding a received SMS message PDU may be displayed.
  • SMS Open verb class i.e., an SMS Open verb object
  • information payload, routing data and other metadata
  • Each menu item of the menu may represent an optional action that may be performed on the given SMS message object, such as Open, Reply, Forward, etc. A user may select the Forward menu item.
  • the user interface object may instantiate an SMS Forward verb class and pass the given SMS message object to the newly created SMS Forward verb object.
  • Methods associated with the SMS Forward verb class may then execute the steps illustrated in FIG. 3 .
  • the given SMS message object may be considered an SMS donor message object.
  • the SMS Forward verb object may receive the given SMS message object (step 301 ). Responsive to receiving the SMS donor message object, a method of the SMS Forward verb object may construct an SMS recipient message object (step 302 ) according, in part, to the SMS message model class. A further method of the SMS Forward verb object may then pass the SMS donor message object to the SMS recipient message object (step 304 ). A method of the SMS recipient message object may request information elements from the SMS donor message object for use in populating the SMS recipient message object. At the least, the method of the SMS recipient message object may request the payload from the SMS donor message object. A still further method of the SMS Forward verb object may then spawn ( 306 ) an SMS message editing screen object to the display 226 , where the SMS message editing screen object shows information elements from the SMS recipient message object.
  • the user may input an SMS destination address for the SMS recipient message object and elect to send the SMS recipient message object.
  • the detailed mechanism of the sending of the SMS recipient message object is considered beyond the scope of the present application.
  • FIG. 3 may also be used to illustrate steps in the forwarding of an e-mail message received at the first mobile device 101 A.
  • An e-mail message PDU includes a body, subject, routing data and other metadata.
  • an e-mail message PDU received the first mobile device 101 A may be used as a basis, by code executed on the microprocessor 228 , for the creation of a new e-mail message object.
  • the new e-mail message object may be created as an instance of an e-mail message model class, which defines an organization of the body, subject, routing data and other metadata found in the e-mail message PDU.
  • the e-mail message model class may also identify those actions that may be performed on the new e-mail message object, such as Open, Reply, Forward, etc. Such actions may be performed on the new e-mail message object responsive to user interaction with the user interface object.
  • Each menu item of the menu may represent an optional action that may be performed on the given e-mail message object, such as Open, Reply, Forward, etc. A user may select the Forward menu item.
  • the user interface may instantiate an e-mail Forward verb class and pass the given e-mail message object to the newly created e-mail Forward verb object.
  • Methods associated with the e-mail Forward verb class may then execute the steps illustrated in FIG. 3 .
  • the given e-mail message object may be considered an e-mail donor message object.
  • the e-mail Forward verb object may receive the given e-mail message object (step 301 ). Responsive to receiving the e-mail donor message object, a method of the e-mail Forward verb object may construct an e-mail recipient message object (step 302 ) according, in part, to the e-mail message model class. A further method of the e-mail Forward verb object may then pass the e-mail donor message object to the e-mail recipient message object (step 304 ). A method of the e-mail recipient message object may request information elements from the e-mail donor message object for use in populating the e-mail recipient message object.
  • the method of the e-mail recipient message object may request the body and subject from the e-mail donor message object.
  • a still further method of the e-mail Forward verb object may then spawn ( 306 ) an e-mail message editing screen object to the display 226 , where the e-mail message editing screen object shows information elements from the e-mail recipient message object.
  • the user may input one or more e-mail destination addresses for the e-mail recipient message object and elect to send the e-mail recipient message object.
  • the detailed mechanism of the sending of the e-mail recipient message object is considered beyond the scope of the present application.
  • a given e-mail message body may be associated with different types of addressing fields such as: a “TO:” field for indicating addresses of primary recipients, a “CC:” field for indicating addresses of secondary recipients and a “BCC:” field for indicating addresses of recipients to kept secret from the other recipients.
  • an e-mail message may be further distinguished from an SMS message in that, unlike an SMS message, an e-mail message includes a subject field.
  • SMS message payload is standardized as 140 bytes: either 160 7-bit characters, 140 8-bit characters or 70 2-byte characters in languages such as Chinese, Korean, or Japanese when encoded using 2-byte UTF-16 character encoding.
  • each message model class which is used to define an object based on a received message PDU, may be required to implement a new interface.
  • the new interface may be defined such that, when methods of a recipient message object request information from a donor message object and the donor message object is an instantiation of a message model class that implements the new interface, the donor message object may respond to the request without regard for the type of message PDU on which the donor message object is based.
  • the new interface may be called, for example, “MessagePartsProvider”.
  • the donor message object may be an e-mail donor message object or an SMS donor message object and the recipient message object may be an e-mail recipient message object or an SMS recipient message object.
  • the recipient message object is configured to determine whether the donor message object implements the new interface. In the event that the donor message object implements the new interface, the recipient message object may make any of a predetermined set of requests of the donor message object. By virtue of implementing the new interface, the donor message object is configured to respond to all of the predetermined set of requests.
  • SMS messages and e-mail messages other types of data, such as pages composed in a markup language, facsimile messages, Instant Messaging (IM) messages, Multimedia Message Service (MMS) messages, Address Book-based messages or Calendar-based messages, may be either the donor message object or the recipient message object.
  • IM Instant Messaging
  • MMS Multimedia Message Service
  • a new verb class may be defined to allow a user to elect to forward a received message object associated with the first message handling service as a new message object using a second message handling service.
  • Each message model may already include a method call that may be used, say, by a user interface object, to determine the verb classes to associate with a message object whose creation is based on the message model.
  • the message models that implement the MessagePartsProvider interface may be slightly modified to include the “Forward As” verb class in the list of verb classes returned by this method call.
  • the user may interact with the user interface object, using the keyboard 214 and/or some auxiliary I/O device 206 , to prompt the user interface object to display a menu.
  • Some of the menu items may represent an optional action that may be performed on the given e-mail message object, such as Open, Reply, Forward, Forward As, etc.
  • a user may select the Forward As menu item.
  • the user interface object may instantiate the Forward As verb class and pass the given e-mail donor message object to the newly created Forward As verb object.
  • the Forward As verb object may then call associated methods to execute the steps illustrated in FIG. 4 .
  • the given e-mail donor message object may be considered a generic donor message object. That is, since the e-mail model class, instantiation of which led to the given e-mail donor message object, implemented the MessagePartsProvider interface, the donor message object need not be a SMS donor message object to appropriately respond to requests from an SMS recipient message object.
  • the Forward As verb object may receive the given e-mail donor message object (step 401 ). Responsive to receiving the given e-mail donor message object, a method of the Forward As verb object may construct a dialog object and instruct the dialog to present itself on the display 226 (step 402 ).
  • the dialog object may include as many options as types (E.G., SMS, e-mail) of Forward verb objects are available on the first mobile device 101 A.
  • the user may interact with the dialog object, using the keyboard 214 and/or some auxiliary I/O device 206 , to select one of the presented types.
  • a method of the Forward As verb object may receive an indication of the selected type (step 404 ), say, from a method of the dialog object.
  • a method of the Forward As verb object may then pass the generic donor message object (step 406 ) to the Forward verb object of the selected type.
  • the Forward verb object of the selected type may then operate normally, as discussed above in conjunction with reference to FIG. 3 .
  • FIG. 5 illustrates an exemplary e-mail message viewing screen 500 presented by the user interface object allowing a user to view elements of a received e-mail donor message object.
  • the user may, as discussed above, interact with the user interface object to prompt the user interface object to display a menu 502 .
  • the Forward As verb object responsive to receiving the given e-mail donor message object (step 401 , FIG. 4 ) arranges the presentation (step 402 ) of a dialog object 600 , as illustrated in FIG. 6 .
  • the exemplary dialog object 600 presents optional message types (message handling services) e-mail and SMS.
  • An indication of a user selection of the SMS message type is received (step 404 ) by the Forward As verb object.
  • a method of the Forward As verb object may then pass (step 406 ) the received e-mail donor message object to the SMS Forward verb object.
  • the received (step 301 , FIG. 3 ) e-mail donor message object may be considered, by the SMS Forward verb object, to be a donor message object without identity, since the SMS Forward verb object does not need to perform any object type-specific processing on the donor message object.
  • a method of the SMS Forward verb object may construct an SMS recipient message object (step 302 ) according, in part, to the SMS message model class.
  • a further method of the SMS Forward verb object may then pass the received e-mail donor message object to the SMS recipient message object (step 304 ).
  • a method of the SMS recipient message object may request information elements from the received e-mail donor message object for use in populating the SMS recipient message object.
  • a still further method of the SMS Forward verb object may then spawn (step 306 ) an SMS message editing screen object to the display 226 , where the SMS message editing screen object shows information elements from the SMS recipient message object.
  • FIG. 7 illustrates an exemplary SMS message editing screen object 700 spawned by the still further method of the SMS Forward verb object with information elements from the SMS recipient message object based on responses from the received e-mail donor message object, whose information elements are displayed in the exemplary e-mail message viewing screen 500 of FIG. 5 .
  • the exemplary SMS message editing screen object 700 allows a user to provide an SMS destination address 702 for the SMS recipient message object.
  • FIG. 8 illustrates steps of an exemplary method undertaken by the SMS recipient message object to populate itself.
  • the SMS recipient message object receives (step 801 ) the received e-mail donor message object.
  • the method of the SMS recipient message object may determine (step 802 ) whether the received e-mail donor message object is of the same type as the recipient message object. If, as in this case, the type of the donor message object differs from the type of the recipient message object, the method of the SMS recipient message object may determine (step 804 ) whether the received e-mail donor message object implements the MessagePartsProvider interface.
  • the SMS recipient message object may request that the received e-mail donor message object indicate whether the MessagePartsProvider interface is implemented.
  • the method of the SMS recipient message object may request (step 806 ) information elements (e.g., a Subject element; a Body element) from the received e-mail donor message object via the MessagePartsProvider interface.
  • the SMS recipient message object may then receive (step 808 ) the requested information elements from the received e-mail donor message object.
  • the SMS recipient message object may populate itself (step 816 ).
  • the method of the SMS recipient message object may end, since it may be considered that the does not have an appropriate interface to handle the donor message object.
  • the method of the SMS recipient message object may request (step 812 ) information elements (e.g., a Payload element) from the received donor message object via an SMS-specific interface.
  • the SMS recipient message object may then receive (step 814 ) the information elements from the received donor message object.
  • the SMS recipient message object may populate itself (step 816 ).
  • a method of the exemplary SMS message editing screen object 700 may request the Payload element from the SMS recipient message object. It may be that the Payload element exceeds the character limit of a standard SMS message, in which case, the exemplary SMS message editing screen object 700 may truncate the received Payload element (as shown in FIG. 7 ) to conform to the SMS standard.
  • the exemplary SMS message editing screen object 700 may inform the user, for example, by way of a dialog object, that the payload has been truncated.
  • SMS message editing screen classes are known to exist that allow the construction of a “macro” SMS message with more characters than are allowed in a standard SMS message.
  • Such a macro SMS message editing screen object may request the Payload element from the SMS recipient message object and the SMS recipient message object may respond to the request with a Payload element that exceeds the character limit of a standard SMS message.
  • the macro SMS message editing screen object may split the Payload element into Payload sub-elements that fit into the character limit of a standard SMS message and arrange the transmission of multiple SMS messages, where each SMS message includes one of the Payload sub-elements.
  • the user may address the SMS message by directly entering a telephone directory number (i.e., routing data, an SMS destination address) of an SMS-capable entity (say, the second mobile device 101 B) in the address field presented as part of the user interface of the SMS client application.
  • a telephone directory number i.e., routing data, an SMS destination address
  • the user may indicate, to the exemplary SMS message editing screen object 700 , a desire to select a contact from within a list of contact information maintained by the PIM application. Once the contact is selected, the user may then be presented with all telephone directory numbers associated with the contact. The user may then select one of the presented telephone directory numbers as the SMS destination address 702 for the SMS recipient message object.
  • the user may indicate that the SMS message payload is complete and should be sent. Further objects executed by the first mobile device 101 A may then arrange the transmission of an SMS message based on the SMS recipient message object to the first base station antenna 102 A via the communication subsystem 240 .
  • the detailed mechanism of the sending of the SMS recipient message object is considered beyond the scope of the present application.
  • the SMS message received at the first base station antenna 102 A may be later received at the mobile services switching center in the first wireless network subsystem 106 A. From the mobile services switching center, the SMS message may be sent to the SMSC, which may also be in the first wireless network subsystem 106 A. The SMSC may arrange the delivery of the SMS message to the second mobile device 101 B via the data communication network 108 , the second wireless network subsystem 106 B and the second base station subsystem 104 B.
  • FIG. 9 illustrates an exemplary SMS message viewing screen 900 presented by a user interface object of the second mobile device 101 B allowing a user to view information elements of a received SMS donor message object.
  • the received SMS donor message object is based on the new SMS donor message object, information elements of which are presented in the exemplary SMS message editing screen object 700 of FIG. 7 .
  • the user may, as discussed above, interact with the user interface object to prompt the user interface object to display a menu 902 .
  • the Forward As verb object responsive to receiving the given SMS donor message object (step 401 , FIG. 4 ) arranges the presentation (step 402 ) of a dialog object 1000 , as illustrated in FIG. 10 .
  • the exemplary dialog object 1000 presents optional message types: e-mail; and SMS.
  • An indication of a user selection of the e-mail message type is received (step 404 ) by the Forward As verb object.
  • a method of the Forward As verb object may then pass (step 406 ) the received SMS donor message object to the e-mail Forward verb object.
  • the received SMS donor message object may be considered, by the e-mail Forward verb object, to be a donor message object without identity, since the e-mail Forward verb object does not need to perform any object type-specific processing on the donor message object.
  • a method of the e-mail Forward verb object may construct an e-mail recipient message object (step 302 ) according, in part, to the e-mail message model class.
  • a further method of the e-mail Forward verb object may then pass the received SMS donor message object to the e-mail recipient message object (step 304 ).
  • a method of the e-mail recipient message object may request information elements from the received SMS donor message object for use in populating the e-mail recipient message object.
  • a still further method of the e-mail Forward verb object may then spawn (step 306 ) an e-mail message editing screen object to the display 226 , where the e-mail message editing screen object shows information elements from the e-mail recipient message object.
  • FIG. 11 illustrates an exemplary e-mail message editing screen object 1100 spawned by the still further method of the e-mail Forward verb object with information elements from the e-mail recipient message object based on responses from the received SMS donor message object, whose information elements are displayed in the exemplary SMS message viewing screen 900 of FIG. 9 .
  • the e-mail recipient message object receives (step 801 , FIG. 8 ) the received SMS donor message object.
  • the method of the e-mail recipient message object may determine (step 802 ) whether
  • the method of the e-mail recipient message object may determine (step 804 ) whether the received SMS donor message object implements the MessagePartsProvider interface. As in the case of the SMS recipient message object, the e-mail recipient object may request that the received SMS donor message object indicate whether the MessagePartsProvider interface is implemented.
  • the method of the e-mail recipient message object may request (step 806 ) several information elements (a Subject element; a Sender element; a Date Sent element; a Body element) from the received SMS donor message object via the MessagePartsProvider interface.
  • the e-mail recipient message object may then receive (step 808 ) the requested information elements from the SMS donor message object.
  • the e-mail recipient message object may populate itself (step 1816 ).
  • the received SMS donor message object may process the Payload element to create a Subject element from a portion of the first 25 characters of the Payload element. Once the received SMS donor message object has created the Subject element, the received SMS donor message object may respond to the request from the e-mail recipient message object with the created Subject element.
  • the created Subject element may include characters up to a cut-off point, where the cut-off point is defined as: the first carriage return in the Payload element; the first period in the Payload element; the first exclamation mark in the Payload element; or the first question mark in the Payload element. If none of these exemplary cut-off characters are found, the cut-off point may be defined as the first comma the Payload element. If a comma character is not found, the cut-off point may be defined as the last white space before the 25-character point in the Payload element. If a white space is not found before the 25-character point, the cut-off point may be defined as the 25-character point itself.
  • the method of the e-mail recipient message object may end, since it may be considered that the does not have an appropriate interface to handle the donor message object.
  • the method of the e-mail recipient message object may request (step 812 ) information elements from the received donor message object using via an e-mail-specific interface.
  • the e-mail recipient message object may then receive (step 814 ) the information elements from the received donor message object.
  • the e-mail recipient message object may populate itself (step 816 ).
  • a method of the exemplary e-mail message editing screen object 1100 may request the Body element from the e-mail recipient message object.
  • the e-mail recipient message object may respond to the request with a Body element created through requests to the received SMS donor message object.
  • the exemplary e-mail message editing screen object 1100 includes a Body element as supplied by the e-mail recipient message object.
  • the Body element is illustrated as formed from a Sender element 1104 , a Date Sent element 1106 and a Payload element 1108 .
  • the exemplary e-mail message editing screen object 1100 also includes a Subject element 1102 as supplied by the e-mail recipient message object.
  • the exemplary e-mail message editing screen object 1100 allows a user to provide an e-mail destination address 1110 for the e-mail recipient message object.
  • MMS Multimedia Messaging Service
  • MMS currently provides for transmission, from a wireless mobile communication device, of up to 100 kilobytes of data, such as text, short musical pieces, digital still images and brief digital video sequences. Additionally, often mobile device manufacturers or service providers may offer proprietary mobile device-to-mobile device transport mechanisms.
  • the message model classes are altered to implement a new interface and include method calls that determine, before requesting information elements from a second message object, whether the second message object implements the new interface.
  • the user may be provided, by a new verb object, with the option to forward the received message object as a new message object associated with a second message handling service.
  • the new verb object selects the correct, previously existing verb object for generating the new message object associated with the second message handling service.
  • the new verb object passes the received message object to the previously existing verb object for the second message handling service and forwarding is accomplished normally from the perspective of the previously existing verb object.
  • the new message object is based on an altered model class and, when requesting information elements from the received message object, the new message object determines whether the received message object implements the new interface.

Abstract

A message received, over a first message handling service, on a mobile wireless communication device may be forwarded using a second message handling service. When a user wishes to forward a received message object associated with a first message handling service, the user may be provided, by a new verb object, with the option to forward the received message object as a new message object associated with a second message handling service. In the event that the user exercises the option, the new verb object selects a previously existing verb object for generating the new message object. The new verb object then passes the received message object to the previously existing verb object.

Description

    FIELD OF THE INVENTION
  • The present application relates to electronic messaging and, in particular, the handling of a message received on a first message handling service for forwarding on a second message handling service.
  • BACKGROUND
  • Current mobile wireless communication devices provide features beyond basic wireless telephony that include an ability to send and receive Short Message Service (SMS) messages, an ability to send and receive e-mail messages and an ability to browse online information formatted using either the known Wireless Application Protocol (WAP) or the known Hyper-Text Transfer Protocol (HTML).
  • Each of the features is typically implemented in a separate client application executed on the wireless communication device. To implement the features outlined above as examples, an exemplary wireless communication device may require an SMS client application, an e-mail client application, a WAP browsing application and an HTML browsing application.
  • Unfortunately, when a user of the exemplary wireless communication device is intent on forwarding an SMS message to a recipient associated with an e-mail address, the user is required to copy, to a temporary memory (i.e., a “clipboard”), the payload of the SMS message while using the SMS client application to review the SMS message. The user is then required to exit the SMS client application and initialize the e-mail client application. While in the e-mail client application, the user may then take steps to edit a new outgoing e-mail message. Responsively, the e-mail client application may present a user interface screen with various editboxes corresponding to fields of a standard e-mail message. Such fields including a field for indicating a recipient, a field for indicating a subject and a field for the body of the e-mail message. The user may then paste the previously copied payload of the SMS message into the editbox of the user interface screen, which editbox corresponds to the body field of the new outgoing e-mail message, specify a subject and a recipient and then direct the e-mail client application to send the new outgoing message.
  • Such a set of actions may not be considered intuitive to the user and may be found to be tedious and time consuming.
  • BRIEF DESCRIPTION OF THE DRAWINGS
  • In the figures which illustrate example embodiments of this application:
  • FIG. 1 illustrates elements of an exemplary network environment for a first wireless mobile communication device;
  • FIG. 2 illustrates components of the first wireless mobile data communication device of FIG. 1, according to an embodiment of the present application;
  • FIG. 3 illustrates steps in a known method of processing messages for forwarding;
  • FIG. 4 illustrates steps in a method of handling messages for forwarding according to an embodiment of the present application;
  • FIG. 5 illustrates an exemplary e-mail message viewing screen presented by a user interface object for a received e-mail donor message object that implements a new interface;
  • FIG. 6 illustrates the exemplary e-mail message viewing screen of FIG. 5 overlaid by a dialog according to an embodiment of the present application;
  • FIG. 7 illustrates an exemplary SMS message composition screen resulting from the selection of the e-mail option in the dialog of FIG. 6;
  • FIG. 8 illustrates steps in a method of processing a donor message object to produce a recipient message object according to an embodiment of the present application;
  • FIG. 9 illustrates an exemplary SMS message viewing screen presented by a user interface object for a received SMS donor message object that implements the new interface;
  • FIG. 10 illustrates the exemplary SMS message viewing screen of FIG. 9 overlaid by a dialog according to an embodiment of the present application; and
  • FIG. 11 illustrates an exemplary e-mail message composition screen resulting from the selection of the e-mail option in the dialog of FIG. 10.
  • DETAILED DESCRIPTION
  • A message received, over a first message handling service, on a mobile wireless communication device may be forwarded using a second message handling service. Message model classes, on which message objects within the wireless communication device are based, are altered to implement a new interface and include method calls for determining, before requesting information elements from a second message object, whether the second message object implements the new interface. Accordingly, when a user wishes to forward a received message object associated with a first message handling service, the user may be provided, by a new verb object, with the option to forward the received message object as a new message object associated with a second message handling service. In the event that the user exercises the option, the new verb object selects a previously existing verb object for generating the new message object associated with the second message handling service. The new verb object passes the received message object to the previously existing verb object for the second message handling service and forwarding is accomplished normally from the perspective of the previously existing verb object. However, the new message object is based on an altered model class and, before requesting information elements from the received message object, determines whether the received message object implements the new interface.
  • In accordance with an aspect of the present application there is provided a method of handling a received message for forwarding. The method includes receiving a donor message object and determining whether the donor message object implements a predetermined interface class. If the donor message object implements the predetermined interface class, the method further includes requesting an information element from the donor message object via an implementation of the predetermined interface class, receiving the information element and populating a recipient message object with the information element. In other aspects of the application, a communication device is provided, with a processor adapted to perform this method, and a computer readable medium is provided to adapt a communication device to perform this method.
  • In accordance with an aspect of the present application there is provided a method of handling a received message for forwarding. The method includes receiving a received message object, where the received message object implements a predetermined interface class, and, responsive to the receiving the received message object, presenting a dialog, where the dialog includes a plurality of options, each option of the plurality of options corresponding to a type of message handling service. The method further comprises receiving an indication of a selected option and, responsive to the receiving the indication of the selected option, passing the received message object to a verb object associated with a message handling service corresponding to the selected option. In other aspects of the application, a communication device is provided, with a processor adapted to perform this method, and a computer readable medium is provided to adapt a communication device to perform this method.
  • Other aspects and features of the present application will become apparent to those of ordinary skill in the art upon review of the following description of specific embodiments of the application in conjunction with the accompanying figures.
  • FIG. 1 illustrates elements of an exemplary network environment 100 for a first wireless mobile communication device 101A. The elements of the exemplary network environment 100 include multiple wireless carrier networks and a data communication network 108, which may be considered to represent at least one wide area network, such as the present day Internet and successors, as well as, potentially, multiple local area networks. A first base station antenna 102A, with which the first wireless mobile communication device 101A may communicate wirelessly, is provided as part of a first base station subsystem 104A.
  • The first base station subsystem 104A connects to a first wireless network subsystem 106A. In an exemplary Global System for Mobile communications (GSM) implementation, the first wireless network subsystem 106A includes, among other components, a mobile services switching center, a home location register, a visitor location register, a relay and a Short Messaging Service Center (SMSC). As illustrated in FIG. 1, the first wireless network subsystem 106A is connected to the data communication network 108.
  • Also connected to the data communication network 108 is a second wireless network subsystem 106B. Similar to the first wireless network subsystem 106A, the second wireless network subsystem 106B may include a mobile services switching center, a home location register, a visitor location register, a relay and an SMSC. The second wireless network subsystem 106A connects to a second base station subsystem 104B with a second base station antenna 102B. The second base station antenna 102B may allow the second base station subsystem 104B to communicate wirelessly with a second mobile device 101B.
  • The first mobile device 101A may be associated with an enterprise 110 connected to the data communication network 108. The enterprise 110 may, for instance, include a firewall or proxy server 112 connecting to the data communication network 108 and to a local area network (LAN) 114. The LAN 114 may allow communication between a mobile device server 116 and an enterprise server 118.
  • Also connected to the data communication network 108 may be an e-mail server 120 and a desktop computer 122, which may be associated with a user having an account on the e-mail server 120. Also connected to the data communication network 108 may be a messaging portal 124.
  • FIG. 2 illustrates the first wireless mobile communication device 101A including a housing, an input device (a keyboard 214), and an output device (a display 226), which is preferably a full graphic or full color Liquid Crystal Display (LCD). Other types of output devices may alternatively be utilized. A processing device (a microprocessor 228) is shown schematically in FIG. 2 as coupled between the keyboard 214 and the display 226. The microprocessor 228 controls the operation of the display 226, as well as the overall operation of the first mobile device 101A, in response to actuation of keys on the keyboard 214 by a user.
  • The housing may be elongated vertically, or may take on other sizes and shapes (including clamshell housing structures). The keyboard may include a mode selection key, or other hardware or software, for switching between text entry and telephony entry.
  • In addition to the microprocessor 228, other parts of the first mobile device 101A are shown schematically in FIG. 2. These include: a communications subsystem 240; a short-range communications subsystem 202; the keyboard 214 and the display 226, along with other input/output devices including a set of auxiliary I/O devices 206, a serial port 208, a speaker 211 and a microphone 212; as well as memory devices including a flash memory 216 and a Random Access Memory (RAM) 218; and various other device subsystems 220. The first mobile device 101A may have a battery 222 to power the active elements of the first mobile device 101A. The first mobile device 101A is preferably a two-way radio frequency (RF) communication device having voice and data communication capabilities. In addition, the first mobile device 101A preferably has the capability to communicate with other computer systems via the Internet.
  • Operating system software executed by the microprocessor 228 is preferably stored in a computer readable medium, such as the flash memory 216, but may be stored in other types of memory devices, such as a read only memory (ROM) or similar storage element. In addition, system software, specific device applications, or parts thereof, may be temporarily loaded into a volatile store, such as the RAM 218. Communication signals received by the mobile device may also be stored to the RAM 218.
  • The microprocessor 228, in addition to its operating system functions, enables execution of software applications on the first mobile device 101A. A predetermined set of software applications that control basic device operations, such as a voice communications module 230A and a data communications module 230B, may be installed on the first mobile device 101A during manufacture. An e-mail client application module 230C may also be installed on the first mobile device 101A during manufacture, to implement aspects of the application. Additionally, an SMS client application module 230D may also be installed on the first mobile device 101A during manufacture, to implement aspects of the application. As well, additional software modules, illustrated as an other software module 230N, which may be, for instance, a personal information manager (PIM) application, may be installed during manufacture. The PIM application is preferably capable of organizing and managing data items, such as e-mail messages, calendar events, voice mail messages, appointments, and task items. The PIM application is also preferably capable of sending and receiving data items via a wireless carrier network represented in FIG. 2 by the first base station antenna 102A. Preferably, the data items managed by the PIM application are seamlessly integrated, synchronized and updated via the wireless carrier network with the device user's corresponding data items stored or associated with a host computer system.
  • Communication functions, including data and voice communications, may be performed through the communication subsystem 240 and, possibly, through the short-range communications subsystem 202. The communication subsystem 240 includes a receiver 250, a transmitter 252 and one or more antennas, illustrated as a receive antenna 254 and a transmit antenna 256. In addition, the communication subsystem 240 also includes a processing module, such as a digital signal processor (DSP) 258, and local oscillators (LOs) 260. The specific design and implementation of the communication subsystem 240 is dependent upon the communication network in which the first mobile device 101A is intended to operate. For example, the communication subsystem 240 of the first mobile device 101A may be designed to operate with the Mobitex™, DataTAC™ or General Packet Radio Service (GPRS) mobile data communication networks and may also be designed to operate with any of a variety of voice communication networks, such as Advanced Mobile Phone Service (AMPS), Time Division Multiple Access (TDMA), Code Division Multiple Access (CDMA), Personal Communications Service (PCS), Global System for Mobile Communications (GSM), etc. Other types of data and voice networks, both separate and integrated, may also be utilized with the first mobile device 101A.
  • When required network registration or activation procedures have been completed, the first mobile device 101A may send and receive communication signals over the wireless carrier network. Signals received from the first base station antenna 102A by the receive antenna 254 are routed to the receiver 250, which provides for signal amplification, frequency down conversion, filtering, channel selection, etc., and may also provide analog to digital conversion. Analog-to-digital conversion of the received signal allows the DSP 258 to perform more complex communication functions, such as demodulation and decoding. In a similar manner, signals to be transmitted to the base station antenna 102A are processed (e.g., modulated and encoded) by the DSP 258 and are then provided to the transmitter 252 for digital to analog conversion, frequency up conversion, filtering, amplification and transmission to the first base station antenna 102A via the transmit antenna 256.
  • In addition to processing communication signals, the DSP 258 provides for control of the receiver 250 and the transmitter 252. For example, gains applied to communication signals in the receiver 250 and the transmitter 252 may be adaptively controlled through automatic gain control algorithms implemented in the DSP 258.
  • In a data communication mode, a received signal, such as an SMS message or web page download, is processed by the communication subsystem 240 and is input to the microprocessor 228. The received signal is then further processed by the microprocessor 228 in preparation for output to the display 226, or alternatively to some other auxiliary I/O devices 206. A device user may also compose data items, such as e-mail messages or SMS messages, using the keyboard 214 and/or some other auxiliary I/O device 206, such as a touchpad, a rocker switch, a thumb-wheel, or some other type of input device. The composed data items may then be transmitted to the base station antenna 102A via the communication subsystem 240.
  • In a voice communication mode, overall operation of the device is substantially similar to the data communication mode, except that received signals may be output to the speaker 211, and signals for transmission may be generated by the microphone 212. Alternative voice or audio I/O subsystems, such as a voice message recording subsystem, may also be implemented on the first mobile device 101A. In addition, the display 226 may also be utilized in voice communication mode, for example, to display the identity of a calling party, the duration of a voice call, or other voice call related information.
  • The short-range communications subsystem 202 enables communication between the first mobile device 101A and other proximate systems or devices, which need not necessarily be similar devices. For example, the short-range communications subsystem 202 may include an infrared device and associated circuits and components, or a Bluetooth™ communication module, to provide for communication with similarly-enabled systems and devices.
  • An SMS message Protocol Data Unit (PDU) includes a Payload element, Routing Data elements and elements including other metadata. It may be, as is currently typical, that the first mobile device 101A executes code developed using object oriented programming techniques. In which case, an SMS message PDU received the first mobile device 101A may be used as a basis, by code executed on the microprocessor 228, for the creation of a new SMS message object. The new SMS message object may be created as an instance of an SMS message model class, which defines an organization of the payload, routing data and other metadata found in the SMS message PDU. The SMS message model class may also identify those actions that may be performed on the new SMS message object, such as Open, Reply, Forward, etc. Such actions may be performed on the new SMS message object responsive to user interaction with a user interface object.
  • The actions that may be performed on an SMS message object may be considered to relate to instances of “verb” classes that are specific to the message handling service. As will be clear to a person of ordinary skill in the art of object oriented programming, a verb is an object encapsulation of an action in the Java™ programming language. A verb is often, but not necessarily, presented to the user as an item in a pull down menu or hotkey; a verb contains the code to perform the action on a related data model and information on how to represent itself to the user in zero or more ways. For instance, an SMS Open verb class may be associated with a method that presents a screen on the display 226 in which relevant data regarding a received SMS message PDU may be displayed. Other methods associated with the SMS Open verb class may provide for the extraction, by an instance of the SMS Open verb class (i.e., an SMS Open verb object), of information (payload, routing data and other metadata) from the SMS message object so that the information may be presented as part of the screen.
  • While the user has focused attention of the user interface of the first mobile device 101A on a screen representation of a given SMS message object, the user may interact with the user interface object, using the keyboard 214 and/or some other auxiliary I/O device 206, to prompt the user interface object to display a menu. Each menu item of the menu may represent an optional action that may be performed on the given SMS message object, such as Open, Reply, Forward, etc. A user may select the Forward menu item.
  • As a result of this selection, the user interface object may instantiate an SMS Forward verb class and pass the given SMS message object to the newly created SMS Forward verb object. Methods associated with the SMS Forward verb class, may then execute the steps illustrated in FIG. 3.
  • The given SMS message object may be considered an SMS donor message object. Initially, the SMS Forward verb object may receive the given SMS message object (step 301). Responsive to receiving the SMS donor message object, a method of the SMS Forward verb object may construct an SMS recipient message object (step 302) according, in part, to the SMS message model class. A further method of the SMS Forward verb object may then pass the SMS donor message object to the SMS recipient message object (step 304). A method of the SMS recipient message object may request information elements from the SMS donor message object for use in populating the SMS recipient message object. At the least, the method of the SMS recipient message object may request the payload from the SMS donor message object. A still further method of the SMS Forward verb object may then spawn (306) an SMS message editing screen object to the display 226, where the SMS message editing screen object shows information elements from the SMS recipient message object.
  • In view of the SMS message editing screen object, the user may input an SMS destination address for the SMS recipient message object and elect to send the SMS recipient message object. The detailed mechanism of the sending of the SMS recipient message object is considered beyond the scope of the present application.
  • FIG. 3 may also be used to illustrate steps in the forwarding of an e-mail message received at the first mobile device 101A. An e-mail message PDU includes a body, subject, routing data and other metadata. As in the case of the received SMS message PDU, an e-mail message PDU received the first mobile device 101A may be used as a basis, by code executed on the microprocessor 228, for the creation of a new e-mail message object. The new e-mail message object may be created as an instance of an e-mail message model class, which defines an organization of the body, subject, routing data and other metadata found in the e-mail message PDU. The e-mail message model class may also identify those actions that may be performed on the new e-mail message object, such as Open, Reply, Forward, etc. Such actions may be performed on the new e-mail message object responsive to user interaction with the user interface object.
  • While the user has focused attention of the user interface of the first mobile device 101A on a screen representation of a given e-mail message object, the user may interact with the user interface object, using the keyboard 214 and/or some other auxiliary I/O device 206, to prompt the user interface object to display a menu. Each menu item of the menu may represent an optional action that may be performed on the given e-mail message object, such as Open, Reply, Forward, etc. A user may select the Forward menu item.
  • As a result of this selection, the user interface may instantiate an e-mail Forward verb class and pass the given e-mail message object to the newly created e-mail Forward verb object. Methods associated with the e-mail Forward verb class, may then execute the steps illustrated in FIG. 3.
  • The given e-mail message object may be considered an e-mail donor message object. Initially, the e-mail Forward verb object may receive the given e-mail message object (step 301). Responsive to receiving the e-mail donor message object, a method of the e-mail Forward verb object may construct an e-mail recipient message object (step 302) according, in part, to the e-mail message model class. A further method of the e-mail Forward verb object may then pass the e-mail donor message object to the e-mail recipient message object (step 304). A method of the e-mail recipient message object may request information elements from the e-mail donor message object for use in populating the e-mail recipient message object. For instance, the method of the e-mail recipient message object may request the body and subject from the e-mail donor message object. A still further method of the e-mail Forward verb object may then spawn (306) an e-mail message editing screen object to the display 226, where the e-mail message editing screen object shows information elements from the e-mail recipient message object.
  • In view of the e-mail message editing screen object, the user may input one or more e-mail destination addresses for the e-mail recipient message object and elect to send the e-mail recipient message object. The detailed mechanism of the sending of the e-mail recipient message object is considered beyond the scope of the present application.
  • In contrast to an SMS message payload, a given e-mail message body may be associated with different types of addressing fields such as: a “TO:” field for indicating addresses of primary recipients, a “CC:” field for indicating addresses of secondary recipients and a “BCC:” field for indicating addresses of recipients to kept secret from the other recipients. Additionally, an e-mail message may be further distinguished from an SMS message in that, unlike an SMS message, an e-mail message includes a subject field.
  • Current GSM SMS standards allow for no more than 160 characters per SMS message, while current TDMA and CDMA networks allow 200 characters per SMS message. In the GSM case, the SMS message payload is standardized as 140 bytes: either 160 7-bit characters, 140 8-bit characters or 70 2-byte characters in languages such as Chinese, Korean, or Japanese when encoded using 2-byte UTF-16 character encoding.
  • Unfortunately, when a user elects to forward a received message in a first message handling service, it has been, up until now, assumed that the forwarded message will use the same message handling service as the received message. As such, when an SMS recipient message object is passed a donor message object, methods of the SMS recipient message object request information of the donor message object based on an assumption that the donor message object is an SMS donor message object. Equally, when an e-mail recipient message object is passed a donor message object, methods of the e-mail recipient message object request information of the donor message object based on an assumption that the donor message object is an e-mail donor message object.
  • In overview, each message model class, which is used to define an object based on a received message PDU, may be required to implement a new interface. The new interface may be defined such that, when methods of a recipient message object request information from a donor message object and the donor message object is an instantiation of a message model class that implements the new interface, the donor message object may respond to the request without regard for the type of message PDU on which the donor message object is based. The new interface may be called, for example, “MessagePartsProvider”.
  • That is, the donor message object may be an e-mail donor message object or an SMS donor message object and the recipient message object may be an e-mail recipient message object or an SMS recipient message object. The recipient message object is configured to determine whether the donor message object implements the new interface. In the event that the donor message object implements the new interface, the recipient message object may make any of a predetermined set of requests of the donor message object. By virtue of implementing the new interface, the donor message object is configured to respond to all of the predetermined set of requests.
  • It should be clear that, while examples herein concentrate on SMS messages and e-mail messages, other types of data, such as pages composed in a markup language, facsimile messages, Instant Messaging (IM) messages, Multimedia Message Service (MMS) messages, Address Book-based messages or Calendar-based messages, may be either the donor message object or the recipient message object.
  • Furthermore, a new verb class, a Forward As verb class, may be defined to allow a user to elect to forward a received message object associated with the first message handling service as a new message object using a second message handling service. Each message model may already include a method call that may be used, say, by a user interface object, to determine the verb classes to associate with a message object whose creation is based on the message model. The message models that implement the MessagePartsProvider interface may be slightly modified to include the “Forward As” verb class in the list of verb classes returned by this method call.
  • In operation, while the user has focused attention of the user interface of the first mobile device 101A (e.g., opened or highlighted in a list) on a screen representation of, for example, a given e-mail message object, the user may interact with the user interface object, using the keyboard 214 and/or some auxiliary I/O device 206, to prompt the user interface object to display a menu. Some of the menu items may represent an optional action that may be performed on the given e-mail message object, such as Open, Reply, Forward, Forward As, etc.
  • A user may select the Forward As menu item. As a result of this selection, the user interface object may instantiate the Forward As verb class and pass the given e-mail donor message object to the newly created Forward As verb object. The Forward As verb object may then call associated methods to execute the steps illustrated in FIG. 4.
  • The given e-mail donor message object may be considered a generic donor message object. That is, since the e-mail model class, instantiation of which led to the given e-mail donor message object, implemented the MessagePartsProvider interface, the donor message object need not be a SMS donor message object to appropriately respond to requests from an SMS recipient message object.
  • Initially, the Forward As verb object may receive the given e-mail donor message object (step 401). Responsive to receiving the given e-mail donor message object, a method of the Forward As verb object may construct a dialog object and instruct the dialog to present itself on the display 226 (step 402). The dialog object may include as many options as types (E.G., SMS, e-mail) of Forward verb objects are available on the first mobile device 101A. The user may interact with the dialog object, using the keyboard 214 and/or some auxiliary I/O device 206, to select one of the presented types. A method of the Forward As verb object may receive an indication of the selected type (step 404), say, from a method of the dialog object. Responsive to receiving the indication of the selected type, a method of the Forward As verb object may then pass the generic donor message object (step 406) to the Forward verb object of the selected type. The Forward verb object of the selected type may then operate normally, as discussed above in conjunction with reference to FIG. 3.
  • Exemplary operation of the Forward As verb object in combination with the Forward verb object may be considered in view of FIGS. 5-10. FIG. 5 illustrates an exemplary e-mail message viewing screen 500 presented by the user interface object allowing a user to view elements of a received e-mail donor message object. The user may, as discussed above, interact with the user interface object to prompt the user interface object to display a menu 502.
  • User selection of the Forward As menu item results, as discussed above, in instantiation of the Forward As verb object and the user interface object passing the given e-mail donor message object to the Forward As verb object. The Forward As verb object, responsive to receiving the given e-mail donor message object (step 401, FIG. 4) arranges the presentation (step 402) of a dialog object 600, as illustrated in FIG. 6. The exemplary dialog object 600 presents optional message types (message handling services) e-mail and SMS. An indication of a user selection of the SMS message type is received (step 404) by the Forward As verb object. Responsive to receiving the indication of the user selection of the SMS message type, a method of the Forward As verb object may then pass (step 406) the received e-mail donor message object to the SMS Forward verb object.
  • The received (step 301, FIG. 3) e-mail donor message object may be considered, by the SMS Forward verb object, to be a donor message object without identity, since the SMS Forward verb object does not need to perform any object type-specific processing on the donor message object. A method of the SMS Forward verb object may construct an SMS recipient message object (step 302) according, in part, to the SMS message model class. A further method of the SMS Forward verb object may then pass the received e-mail donor message object to the SMS recipient message object (step 304). A method of the SMS recipient message object may request information elements from the received e-mail donor message object for use in populating the SMS recipient message object. A still further method of the SMS Forward verb object may then spawn (step 306) an SMS message editing screen object to the display 226, where the SMS message editing screen object shows information elements from the SMS recipient message object.
  • FIG. 7 illustrates an exemplary SMS message editing screen object 700 spawned by the still further method of the SMS Forward verb object with information elements from the SMS recipient message object based on responses from the received e-mail donor message object, whose information elements are displayed in the exemplary e-mail message viewing screen 500 of FIG. 5. The exemplary SMS message editing screen object 700 allows a user to provide an SMS destination address 702 for the SMS recipient message object.
  • FIG. 8 illustrates steps of an exemplary method undertaken by the SMS recipient message object to populate itself. Initially, the SMS recipient message object receives (step 801) the received e-mail donor message object. Before the method of the SMS recipient message object requests information elements from the received e-mail donor message object for use in populating the SMS recipient message object, the method of the SMS recipient message object may determine (step 802) whether the received e-mail donor message object is of the same type as the recipient message object. If, as in this case, the type of the donor message object differs from the type of the recipient message object, the method of the SMS recipient message object may determine (step 804) whether the received e-mail donor message object implements the MessagePartsProvider interface. To this end, the SMS recipient message object may request that the received e-mail donor message object indicate whether the MessagePartsProvider interface is implemented. Upon determining that the received e-mail donor message object does implement the MessagePartsProvider interface, the method of the SMS recipient message object may request (step 806) information elements (e.g., a Subject element; a Body element) from the received e-mail donor message object via the MessagePartsProvider interface. The SMS recipient message object may then receive (step 808) the requested information elements from the received e-mail donor message object. Using the received Subject element and Body element, the SMS recipient message object may populate itself (step 816).
  • Upon determining (step 804) that the received donor message object does not implement the MessagePartsProvider interface, the method of the SMS recipient message object may end, since it may be considered that the does not have an appropriate interface to handle the donor message object.
  • Upon determining (step 802), in another case, that the received donor message object is of the same type as the recipient message object, the method of the SMS recipient message object may request (step 812) information elements (e.g., a Payload element) from the received donor message object via an SMS-specific interface. The SMS recipient message object may then receive (step 814) the information elements from the received donor message object. Using the received Payload element, the SMS recipient message object may populate itself (step 816).
  • When the still further method of the SMS Forward verb object spawns (step 306, FIG. 3) the exemplary SMS message editing screen object 700, a method of the exemplary SMS message editing screen object 700 may request the Payload element from the SMS recipient message object. It may be that the Payload element exceeds the character limit of a standard SMS message, in which case, the exemplary SMS message editing screen object 700 may truncate the received Payload element (as shown in FIG. 7) to conform to the SMS standard. The exemplary SMS message editing screen object 700 may inform the user, for example, by way of a dialog object, that the payload has been truncated.
  • SMS message editing screen classes are known to exist that allow the construction of a “macro” SMS message with more characters than are allowed in a standard SMS message. Such a macro SMS message editing screen object may request the Payload element from the SMS recipient message object and the SMS recipient message object may respond to the request with a Payload element that exceeds the character limit of a standard SMS message. In such a case, the macro SMS message editing screen object may split the Payload element into Payload sub-elements that fit into the character limit of a standard SMS message and arrange the transmission of multiple SMS messages, where each SMS message includes one of the Payload sub-elements.
  • The user may address the SMS message by directly entering a telephone directory number (i.e., routing data, an SMS destination address) of an SMS-capable entity (say, the second mobile device 101B) in the address field presented as part of the user interface of the SMS client application. Alternatively, rather than directly entering a telephone directory number, the user may indicate, to the exemplary SMS message editing screen object 700, a desire to select a contact from within a list of contact information maintained by the PIM application. Once the contact is selected, the user may then be presented with all telephone directory numbers associated with the contact. The user may then select one of the presented telephone directory numbers as the SMS destination address 702 for the SMS recipient message object.
  • When the user has completed composition of the SMS message payload, the user may indicate that the SMS message payload is complete and should be sent. Further objects executed by the first mobile device 101A may then arrange the transmission of an SMS message based on the SMS recipient message object to the first base station antenna 102A via the communication subsystem 240. The detailed mechanism of the sending of the SMS recipient message object is considered beyond the scope of the present application.
  • The SMS message received at the first base station antenna 102A may be later received at the mobile services switching center in the first wireless network subsystem 106A. From the mobile services switching center, the SMS message may be sent to the SMSC, which may also be in the first wireless network subsystem 106A. The SMSC may arrange the delivery of the SMS message to the second mobile device 101B via the data communication network 108, the second wireless network subsystem 106B and the second base station subsystem 104B.
  • FIG. 9 illustrates an exemplary SMS message viewing screen 900 presented by a user interface object of the second mobile device 101B allowing a user to view information elements of a received SMS donor message object. In the illustrated case, the received SMS donor message object is based on the new SMS donor message object, information elements of which are presented in the exemplary SMS message editing screen object 700 of FIG. 7. The user may, as discussed above, interact with the user interface object to prompt the user interface object to display a menu 902.
  • User selection of the Forward As menu item results, as discussed above, in instantiation of the Forward As verb object and the user interface object passing the given SMS donor message object to the Forward As verb object. The Forward As verb object, responsive to receiving the given SMS donor message object (step 401, FIG. 4) arranges the presentation (step 402) of a dialog object 1000, as illustrated in FIG. 10. The exemplary dialog object 1000 presents optional message types: e-mail; and SMS. An indication of a user selection of the e-mail message type is received (step 404) by the Forward As verb object. A method of the Forward As verb object may then pass (step 406) the received SMS donor message object to the e-mail Forward verb object.
  • The received SMS donor message object may be considered, by the e-mail Forward verb object, to be a donor message object without identity, since the e-mail Forward verb object does not need to perform any object type-specific processing on the donor message object. A method of the e-mail Forward verb object may construct an e-mail recipient message object (step 302) according, in part, to the e-mail message model class. A further method of the e-mail Forward verb object may then pass the received SMS donor message object to the e-mail recipient message object (step 304). A method of the e-mail recipient message object may request information elements from the received SMS donor message object for use in populating the e-mail recipient message object. A still further method of the e-mail Forward verb object may then spawn (step 306) an e-mail message editing screen object to the display 226, where the e-mail message editing screen object shows information elements from the e-mail recipient message object.
  • FIG. 11 illustrates an exemplary e-mail message editing screen object 1100 spawned by the still further method of the e-mail Forward verb object with information elements from the e-mail recipient message object based on responses from the received SMS donor message object, whose information elements are displayed in the exemplary SMS message viewing screen 900 of FIG. 9.
  • Initially, the e-mail recipient message object receives (step 801, FIG. 8) the received SMS donor message object. Before the method of the e-mail recipient message object requests information elements from the received SMS donor message object for use in populating the e-mail recipient message object, the method of the e-mail recipient message object may determine (step 802) whether
  • whether the received SMS donor message object is of the same type as the recipient message object. If, as in this case, the type of the donor message object differs from the type of the recipient message object, the method of the e-mail recipient message object may determine (step 804) whether the received SMS donor message object implements the MessagePartsProvider interface. As in the case of the SMS recipient message object, the e-mail recipient object may request that the received SMS donor message object indicate whether the MessagePartsProvider interface is implemented. Upon determining that the received SMS donor message object does implement the MessagePartsProvider interface, the method of the e-mail recipient message object may request (step 806) several information elements (a Subject element; a Sender element; a Date Sent element; a Body element) from the received SMS donor message object via the MessagePartsProvider interface. The e-mail recipient message object may then receive (step 808) the requested information elements from the SMS donor message object. Using the received information elements, the e-mail recipient message object may populate itself (step 1816).
  • When the method of the e-mail recipient message object requests (step 806) the Subject element, in particular, from the received SMS donor message object via the MessagePartsProvider interface, the received SMS donor message object may process the Payload element to create a Subject element from a portion of the first 25 characters of the Payload element. Once the received SMS donor message object has created the Subject element, the received SMS donor message object may respond to the request from the e-mail recipient message object with the created Subject element.
  • The created Subject element may include characters up to a cut-off point, where the cut-off point is defined as: the first carriage return in the Payload element; the first period in the Payload element; the first exclamation mark in the Payload element; or the first question mark in the Payload element. If none of these exemplary cut-off characters are found, the cut-off point may be defined as the first comma the Payload element. If a comma character is not found, the cut-off point may be defined as the last white space before the 25-character point in the Payload element. If a white space is not found before the 25-character point, the cut-off point may be defined as the 25-character point itself.
  • Upon determining (step 804) that the received donor message object does not implement the MessagePartsProvider interface, the method of the e-mail recipient message object may end, since it may be considered that the does not have an appropriate interface to handle the donor message object.
  • Upon determining (step 802), in another case, that the received donor message object is of the same type as the recipient message object, the method of the e-mail recipient message object may request (step 812) information elements from the received donor message object using via an e-mail-specific interface. The e-mail recipient message object may then receive (step 814) the information elements from the received donor message object. Using the received information elements, the e-mail recipient message object may populate itself (step 816).
  • When the still further method of the e-mail Forward verb object spawns (step 306, FIG. 3) the exemplary e-mail message editing screen object 1100, a method of the exemplary e-mail message editing screen object 1100 may request the Body element from the e-mail recipient message object. The e-mail recipient message object may respond to the request with a Body element created through requests to the received SMS donor message object.
  • As illustrated in FIG. 11, the exemplary e-mail message editing screen object 1100 includes a Body element as supplied by the e-mail recipient message object. The Body element is illustrated as formed from a Sender element 1104, a Date Sent element 1106 and a Payload element 1108. The exemplary e-mail message editing screen object 1100 also includes a Subject element 1102 as supplied by the e-mail recipient message object.
  • The exemplary e-mail message editing screen object 1100 allows a user to provide an e-mail destination address 1110 for the e-mail recipient message object.
  • As will be understood by a person of ordinary skill in the art, although the above description provides, as exemplary message handling services, the known SMS transport mechanism and the known e-mail message transport mechanism, aspects of the present application may be applicable for several other message handling services such as those message handling services concerned with handling pages composed in a markup language, facsimile messages, IM messages, voice mail messages, Address Book-based messages or Calendar-based messages. Additionally, the known Multimedia Messaging Service (MMS) is a further exemplary message handling service that may be seen as an extension of the SMS transport mechanism. MMS currently provides for transmission, from a wireless mobile communication device, of up to 100 kilobytes of data, such as text, short musical pieces, digital still images and brief digital video sequences. Additionally, often mobile device manufacturers or service providers may offer proprietary mobile device-to-mobile device transport mechanisms.
  • In summary then, the message model classes are altered to implement a new interface and include method calls that determine, before requesting information elements from a second message object, whether the second message object implements the new interface. Accordingly, when a user wishes to forward a received message object associated with a first message handling service, the user may be provided, by a new verb object, with the option to forward the received message object as a new message object associated with a second message handling service. In the event that the user exercises the option, the new verb object selects the correct, previously existing verb object for generating the new message object associated with the second message handling service. The new verb object passes the received message object to the previously existing verb object for the second message handling service and forwarding is accomplished normally from the perspective of the previously existing verb object. However, the new message object is based on an altered model class and, when requesting information elements from the received message object, the new message object determines whether the received message object implements the new interface.
  • Other modifications will be apparent to those skilled in the art and, therefore, the invention is defined in the claims.

Claims (19)

1. A method of handling a received message for forwarding, said method comprising:
receiving a donor message object;
determining whether said donor message object implements a predetermined interface class;
if said donor message object implements said predetermined interface class, requesting an information element from said donor message object via an implementation of said predetermined interface class;
receiving said information element; and
populating a recipient message object with said information element.
2. The method of claim 1 wherein said donor message object is associated with a first message handling service and said recipient message object is associated with a second message handling service.
3. The method of claim 2 wherein said first message handling service is a Short Messaging Service.
4. The method of claim 3 wherein said second message handling service is an e-mail service.
5. The method of claim 1 wherein said first message handling service is an e-mail service.
6. The method of claim 5 wherein said second message handling service is a Short Messaging Service.
7. The method of claim 6 wherein said information element is a Subject element.
8. The method of claim 7 further comprising:
requesting a Body element from said donor message object;
receiving said Body element; and
populating said recipient message object with said Body element.
9. The method of claim 1 wherein said requesting said information element requires implementing a method specified in said predetermined interface class.
10. A communication device comprising a processor adapted to:
receive a donor message object;
determine whether said donor message object implements a predetermined interface class;
request an information element from said donor message object responsive to determining that said donor message object implements said predetermined interface class;
receive said information element; and
populate a recipient message object with said information element.
11. A computer readable medium containing computer-executable instructions that, when performed by processor in a communication device, cause said processor to:
receive a donor message object;
determine whether said donor message object implements a predetermined interface class;
request an information element from said donor message object responsive to determining that said donor message object implements said predetermined interface class;
receive said information element; and
populate a recipient message object with said information element.
12. A method of handling a received message for forwarding, said method comprising:
receiving a received message object, where said received message object implements a predetermined interface class;
responsive to said receiving said received message object, presenting a dialog, where said dialog includes a plurality of options, each option of said plurality of options corresponding to a type of message handling service;
receiving an indication of a selected option; and
responsive to said receiving said indication of said selected option, passing said received message object to a verb object associated with a message handling service corresponding to said selected option.
13. The method of claim 12 wherein said received message object is associated with a first message handling service and said message handling service corresponding to said selected option is a second message handling service.
14. The method of claim 13 wherein said first message handling service is a Short Messaging Service.
15. The method of claim 14 wherein said second message handling service is an e-mail service.
16. The method of claim 13 wherein said first message handling service is an e-mail service.
17. The method of claim 16 wherein said second message handling service is a Short Messaging Service.
18. A communication device comprising a processor adapted to:
receive a received message object, where said received message object implements a predetermined interface class;
present, responsive to said receiving said received message object, a dialog, where said dialog includes a plurality of options, each option of said plurality of options corresponding to a type of message handling service;
receive an indication of a selected option; and
pass, responsive to said receiving said indication of said selected option, said received message object to a verb object associated with a message handling service corresponding to said selected option.
19. A computer readable medium containing computer-executable instructions that, when performed by processor in a communication device, cause said processor to:
receive a received message object, where said received message object implements a predetermined interface class;
present, responsive to said receiving said received message object, a dialog, where said dialog includes a plurality of options, each option of said plurality of options corresponding to a type of message handling service;
receive an indication of a selected option; and
pass, responsive to said receiving said indication of said selected option, said received message object to a verb object associated with a message handling service corresponding to said selected option.
US11/249,507 2005-10-14 2005-10-14 System and method of handling messages for forwarding Active 2029-12-10 US8745140B2 (en)

Priority Applications (2)

Application Number Priority Date Filing Date Title
US11/249,507 US8745140B2 (en) 2005-10-14 2005-10-14 System and method of handling messages for forwarding
US11/554,999 US8819144B2 (en) 2005-10-14 2006-10-31 Method, device, software and graphical user interface for forwarding messages between message handling services

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
US11/249,507 US8745140B2 (en) 2005-10-14 2005-10-14 System and method of handling messages for forwarding

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US11/554,999 Continuation-In-Part US8819144B2 (en) 2005-10-14 2006-10-31 Method, device, software and graphical user interface for forwarding messages between message handling services

Publications (2)

Publication Number Publication Date
US20070088787A1 true US20070088787A1 (en) 2007-04-19
US8745140B2 US8745140B2 (en) 2014-06-03

Family

ID=37948775

Family Applications (1)

Application Number Title Priority Date Filing Date
US11/249,507 Active 2029-12-10 US8745140B2 (en) 2005-10-14 2005-10-14 System and method of handling messages for forwarding

Country Status (1)

Country Link
US (1) US8745140B2 (en)

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20090088189A1 (en) * 2007-10-02 2009-04-02 Michael Thomas Hardy Method and apparatus capable of unified multi-transport message handling
US8239784B2 (en) * 2004-07-30 2012-08-07 Apple Inc. Mode-based graphical user interfaces for touch sensitive input devices
US8381135B2 (en) 2004-07-30 2013-02-19 Apple Inc. Proximity detector in handheld device
US9059954B1 (en) * 2011-08-03 2015-06-16 Hunter C. Cohen Extracting indirect relational information from email correspondence
US9239673B2 (en) 1998-01-26 2016-01-19 Apple Inc. Gesturing with a multipoint sensing device
US9239677B2 (en) 2004-05-06 2016-01-19 Apple Inc. Operation of a computer with touch screen interface
US9292111B2 (en) 1998-01-26 2016-03-22 Apple Inc. Gesturing with a multipoint sensing device

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10069782B2 (en) 2016-08-12 2018-09-04 Xenovus Inc. Method and system to facilitate electronic communication between internal teams and external contacts

Citations (27)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5119475A (en) * 1991-03-13 1992-06-02 Schlumberger Technology Corporation Object-oriented framework for menu definition
US5590334A (en) * 1994-03-30 1996-12-31 Apple Computer, Inc Object oriented message passing system and method
US5946629A (en) * 1995-11-28 1999-08-31 Telefonaktiebolaget L M Ericsson Cellular telephone network having short message service interaction with other networks
US5951623A (en) * 1996-08-06 1999-09-14 Reynar; Jeffrey C. Lempel- Ziv data compression technique utilizing a dictionary pre-filled with frequent letter combinations, words and/or phrases
US5974449A (en) * 1997-05-09 1999-10-26 Carmel Connection, Inc. Apparatus and method for providing multimedia messaging between disparate messaging platforms
US6081832A (en) * 1995-12-19 2000-06-27 International Business Machines Corporation Object oriented mail server framework mechanism
US6151507A (en) * 1997-11-07 2000-11-21 Nokia Mobile Phones Ltd. Individual short message service (SMS) options
US6421707B1 (en) * 1998-02-13 2002-07-16 Lucent Technologies Inc. Wireless multi-media messaging communications method and apparatus
US6424828B1 (en) * 1999-06-03 2002-07-23 Ericsson Inc. Internet server and method for providing access to internet e-mail and internet web pages
US20020112014A1 (en) * 2000-08-15 2002-08-15 Simon Bennett Method and apparatus for a network independent short message delivery system
US20020133554A1 (en) * 2000-05-25 2002-09-19 Daniel Checkoway E-mail answering agent
US20020137530A1 (en) * 2001-03-08 2002-09-26 Katyayini Karve Cellular telephone with SMS message forwarding
US6651042B1 (en) * 2000-06-02 2003-11-18 International Business Machines Corporation System and method for automatic voice message processing
US20040006600A1 (en) * 1997-07-18 2004-01-08 Miller Stephen S. Apparatus and method for effecting correspondent-centric electronic mail
US20040057403A1 (en) * 2001-02-07 2004-03-25 Belhassen Jerbi Method for sending messages from an mms-system and a device therefor
US20040137884A1 (en) * 2002-10-15 2004-07-15 Engstrom G. Eric Unified communication thread for wireless mobile communication devices
US20060009243A1 (en) * 2004-07-07 2006-01-12 At&T Wireless Services, Inc. Always-on mobile instant messaging of a messaging centric wireless device
US20060031778A1 (en) * 2004-07-01 2006-02-09 Microsoft Corporation Computing platform for loading resources both synchronously and asynchronously
US20060053379A1 (en) * 2004-09-08 2006-03-09 Yahoo! Inc. Multimodal interface for mobile messaging
US20060052119A1 (en) * 2004-09-08 2006-03-09 Veen Raymond V Method and apparatus for interfacing to communications messages
US20060245555A1 (en) * 2005-05-02 2006-11-02 Nokia Corporation Dynamic message templates and messaging macros
US20060276208A1 (en) * 2005-06-07 2006-12-07 Jataayu Software (P) Ltd. Rule based processing of SMS messages
US7191449B2 (en) * 2001-02-16 2007-03-13 Microsoft Corporation System and method for providing componentized transports and forms
US7269431B1 (en) * 2004-01-16 2007-09-11 Cingular Wireless Ii, Llc System for forwarding SMS messages to other devices
US7447232B2 (en) * 2003-09-30 2008-11-04 Intel Corporation Data burst transmission methods in WLAN devices and systems
US20080278740A1 (en) * 2002-07-29 2008-11-13 Nicholas Rowland Bird Bulk Communications Process Using Multiple Delivery Media
US20080313282A1 (en) * 2002-09-10 2008-12-18 Warila Bruce W User interface, operating system and architecture

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FI108388B (en) * 1997-09-01 2002-01-15 Nokia Corp Electronic mail traffic in a mobile phone system
DE19911693A1 (en) 1999-03-16 2000-09-28 Siemens Ag Telecommunications system and method for operating the system
US7096033B1 (en) 2000-07-18 2006-08-22 Koninkiljke Phillips Electronics N.V. Mobile apparatus enabling inter-network communication
US7116994B2 (en) 2001-12-21 2006-10-03 Nokia Corporation Mobile network message to email redirection
GB0301203D0 (en) 2003-01-20 2003-02-19 Intellprop Ltd Telecommunications services apparatus
GB0306937D0 (en) 2003-03-26 2003-04-30 Intellprop Ltd Telecommunications services apparatus
US7870187B2 (en) 2003-12-31 2011-01-11 Microsoft Corporation Transport agnostic pull mode messaging service
EP1583301A1 (en) 2004-03-30 2005-10-05 Web. De AG Voice messaging system with email reply

Patent Citations (27)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5119475A (en) * 1991-03-13 1992-06-02 Schlumberger Technology Corporation Object-oriented framework for menu definition
US5590334A (en) * 1994-03-30 1996-12-31 Apple Computer, Inc Object oriented message passing system and method
US5946629A (en) * 1995-11-28 1999-08-31 Telefonaktiebolaget L M Ericsson Cellular telephone network having short message service interaction with other networks
US6081832A (en) * 1995-12-19 2000-06-27 International Business Machines Corporation Object oriented mail server framework mechanism
US5951623A (en) * 1996-08-06 1999-09-14 Reynar; Jeffrey C. Lempel- Ziv data compression technique utilizing a dictionary pre-filled with frequent letter combinations, words and/or phrases
US5974449A (en) * 1997-05-09 1999-10-26 Carmel Connection, Inc. Apparatus and method for providing multimedia messaging between disparate messaging platforms
US20040006600A1 (en) * 1997-07-18 2004-01-08 Miller Stephen S. Apparatus and method for effecting correspondent-centric electronic mail
US6151507A (en) * 1997-11-07 2000-11-21 Nokia Mobile Phones Ltd. Individual short message service (SMS) options
US6421707B1 (en) * 1998-02-13 2002-07-16 Lucent Technologies Inc. Wireless multi-media messaging communications method and apparatus
US6424828B1 (en) * 1999-06-03 2002-07-23 Ericsson Inc. Internet server and method for providing access to internet e-mail and internet web pages
US20020133554A1 (en) * 2000-05-25 2002-09-19 Daniel Checkoway E-mail answering agent
US6651042B1 (en) * 2000-06-02 2003-11-18 International Business Machines Corporation System and method for automatic voice message processing
US20020112014A1 (en) * 2000-08-15 2002-08-15 Simon Bennett Method and apparatus for a network independent short message delivery system
US20040057403A1 (en) * 2001-02-07 2004-03-25 Belhassen Jerbi Method for sending messages from an mms-system and a device therefor
US7191449B2 (en) * 2001-02-16 2007-03-13 Microsoft Corporation System and method for providing componentized transports and forms
US20020137530A1 (en) * 2001-03-08 2002-09-26 Katyayini Karve Cellular telephone with SMS message forwarding
US20080278740A1 (en) * 2002-07-29 2008-11-13 Nicholas Rowland Bird Bulk Communications Process Using Multiple Delivery Media
US20080313282A1 (en) * 2002-09-10 2008-12-18 Warila Bruce W User interface, operating system and architecture
US20040137884A1 (en) * 2002-10-15 2004-07-15 Engstrom G. Eric Unified communication thread for wireless mobile communication devices
US7447232B2 (en) * 2003-09-30 2008-11-04 Intel Corporation Data burst transmission methods in WLAN devices and systems
US7269431B1 (en) * 2004-01-16 2007-09-11 Cingular Wireless Ii, Llc System for forwarding SMS messages to other devices
US20060031778A1 (en) * 2004-07-01 2006-02-09 Microsoft Corporation Computing platform for loading resources both synchronously and asynchronously
US20060009243A1 (en) * 2004-07-07 2006-01-12 At&T Wireless Services, Inc. Always-on mobile instant messaging of a messaging centric wireless device
US20060053379A1 (en) * 2004-09-08 2006-03-09 Yahoo! Inc. Multimodal interface for mobile messaging
US20060052119A1 (en) * 2004-09-08 2006-03-09 Veen Raymond V Method and apparatus for interfacing to communications messages
US20060245555A1 (en) * 2005-05-02 2006-11-02 Nokia Corporation Dynamic message templates and messaging macros
US20060276208A1 (en) * 2005-06-07 2006-12-07 Jataayu Software (P) Ltd. Rule based processing of SMS messages

Cited By (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9239673B2 (en) 1998-01-26 2016-01-19 Apple Inc. Gesturing with a multipoint sensing device
US9292111B2 (en) 1998-01-26 2016-03-22 Apple Inc. Gesturing with a multipoint sensing device
US9606668B2 (en) 2002-02-07 2017-03-28 Apple Inc. Mode-based graphical user interfaces for touch sensitive input devices
US9239677B2 (en) 2004-05-06 2016-01-19 Apple Inc. Operation of a computer with touch screen interface
US8381135B2 (en) 2004-07-30 2013-02-19 Apple Inc. Proximity detector in handheld device
US8612856B2 (en) 2004-07-30 2013-12-17 Apple Inc. Proximity detector in handheld device
US8479122B2 (en) 2004-07-30 2013-07-02 Apple Inc. Gestures for touch sensitive input devices
US8239784B2 (en) * 2004-07-30 2012-08-07 Apple Inc. Mode-based graphical user interfaces for touch sensitive input devices
US9348458B2 (en) 2004-07-30 2016-05-24 Apple Inc. Gestures for touch sensitive input devices
US10042418B2 (en) 2004-07-30 2018-08-07 Apple Inc. Proximity detector in handheld device
US11036282B2 (en) 2004-07-30 2021-06-15 Apple Inc. Proximity detector in handheld device
US20090088189A1 (en) * 2007-10-02 2009-04-02 Michael Thomas Hardy Method and apparatus capable of unified multi-transport message handling
US7881243B2 (en) 2007-10-02 2011-02-01 Research In Motion Limited Method and apparatus capable of unified multi-transport message handling
US9059954B1 (en) * 2011-08-03 2015-06-16 Hunter C. Cohen Extracting indirect relational information from email correspondence

Also Published As

Publication number Publication date
US8745140B2 (en) 2014-06-03

Similar Documents

Publication Publication Date Title
US8819144B2 (en) Method, device, software and graphical user interface for forwarding messages between message handling services
US7881243B2 (en) Method and apparatus capable of unified multi-transport message handling
JP4751382B2 (en) System and method for integrating multiple messaging systems
US8745140B2 (en) System and method of handling messages for forwarding
US8320943B2 (en) System and method for enabling instant messages to be exchanged between mobile devices
US8204526B2 (en) Unified addressing
US20070283039A1 (en) Mail application with integrated text messaging functionality
US20020154746A1 (en) Apparatus, method, and record medium for automatically categorizing received mail messages
US8874678B2 (en) Recipient change notification
US20070088786A1 (en) Using separate icons for invoking a computer program for presenting distinct sets of service-specific electronic mail messages stored at a wireless communication device
CA2623323C (en) System and method of handling messages for forwarding
US20050198179A1 (en) Management of message stores
US20130290455A1 (en) System and method for image inclusion in e-mail messages
EP1775924A1 (en) Using separate icons for invoking a computer program for presenting distinct sets of service-specific electronic mail messages stored at a wireless communication device
CA2572276C (en) Unified addressing
KR20050041977A (en) System and method for formatting electronic messages from a mobile communication device
CA2640181C (en) Method and apparatus capable of unified multi-transport message handling
JP5255915B2 (en) Mail transmission processing method and communication terminal device
CA2815700C (en) Restrictions to data transmission
CA2619120C (en) System and method for image inclusion in e-mail messages

Legal Events

Date Code Title Description
AS Assignment

Owner name: RESEARCH IN MOTION LIMITED, CANADA

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:HARDY, MICHAEL THOMAS;GLENNIE, ROBIN ROY;REEL/FRAME:017093/0768

Effective date: 20051014

AS Assignment

Owner name: BLACKBERRY LIMITED, ONTARIO

Free format text: CHANGE OF NAME;ASSIGNOR:RESEARCH IN MOTION LIMITED;REEL/FRAME:032495/0694

Effective date: 20130709

STCF Information on status: patent grant

Free format text: PATENTED CASE

MAFP Maintenance fee payment

Free format text: PAYMENT OF MAINTENANCE FEE, 4TH YEAR, LARGE ENTITY (ORIGINAL EVENT CODE: M1551)

Year of fee payment: 4

MAFP Maintenance fee payment

Free format text: PAYMENT OF MAINTENANCE FEE, 8TH YEAR, LARGE ENTITY (ORIGINAL EVENT CODE: M1552); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY

Year of fee payment: 8

AS Assignment

Owner name: MALIKIE INNOVATIONS LIMITED, IRELAND

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:BLACKBERRY LIMITED;REEL/FRAME:064104/0103

Effective date: 20230511

AS Assignment

Owner name: MALIKIE INNOVATIONS LIMITED, IRELAND

Free format text: NUNC PRO TUNC ASSIGNMENT;ASSIGNOR:BLACKBERRY LIMITED;REEL/FRAME:064269/0001

Effective date: 20230511