Messaging

A mechanism enabling a user whose user device has received a notification on messages waiting delivery, messages being deferred or waiting for another reason, to convey message-specific, possibly different handling instructions in one go to a network entity responsible for handling of the waiting messages.

FIELD

The invention relates to the field of telecommunications and, particularly, to messaging.

BACKGROUND

The following description of background art may include insights, discoveries, understandings or disclosures, or associations together with disclosures not known to the relevant art prior to the present invention but provided by the invention. Some such contributions of the invention may be specifically pointed out below, whereas other such contributions of the invention will be apparent from their context.

The evolvement of communication technology, particularly IP-based communication technology and end user device, has enabled versatile communication possibilities and introduction of different services. For example, messaging has evolved from text string short messages with a very limited size to various messaging services able to deliver multimedia content not having size restrictions. Further, the messaging may be bi-directional conversation-type of messaging, such as instant messaging or chatting, or uni-directional messaging, called “one shot” or “standalone” messaging. Basically the difference is that in the bi-directional messaging a recipient of a message receives the message in near real-time fashion but in the uni-directional messaging the recipient may receive the message in near real-time fashion, or the message may be temporarily stored in the recipient's network to be delivered later. A reason for deferred delivery of a message may be that the user is not available or not willing to receive it, i.e. the recipient may be in offline state or lost temporarily connection to the network or the recipient's service settings may indicate that the user does not want to be disturbed at the moment, thereby indicating to hold the message, for example. Such messages are called herein waiting messages.

Some messaging services, such as instant messaging using SIMPLE (session initiation protocol for instant messaging and presence leveraging extensions) or converged IP (Internet protocol) messaging (CPM), provide alternatives for delivery of the waiting messages. Depending, for example, on the recipient's settings, message characteristics and/or service provider policies, the waiting messages may be pushed to the recipient automatically or the recipient may receive a notification on waiting messages and then decide whether to retrieve, delete, or to store to the user's network storage one or more of the deferred messages.

However, a problem is that selecting different alternatives for different messages within a notification is an iterative process. For example, if the user wants to delete two waiting messages and retrieve one waiting message in a SIP-based (session initiation protocol) messaging system, such as CPM, the user opens the notification, selects from the notification messages to be deleted, then selects delete action which triggers deletion function for deferred messages in user equipment the user is using, the deletion function closing the notification and sending delete instructions in SIP REFER request to address delete@hostname. Then the user opens the notification once again, selects from the notification the message(s) to be retrieved and selects retrieval action which triggers retrieval function for deferred messages in the user equipment, the retrieval function closing the notification, sending retrieval instructions in SIP INVITE request to address deferred@hostname.

SUMMARY

An object of the present invention is to enable a user having received a notification on waiting messages, deferred or waiting for another reason, to convey message-specific, possibly different handling instructions in one go. The object of the invention is achieved by means of methods, apparatuses, a system, and a computer program, and a computer readable storage medium as claimed in the independent claims. The preferred embodiments of the invention are disclosed in the dependent claims.

An advantage is that an “one go” solution helps to minimize complexity of a system and it may reduce signalling load of the system.

DETAILED DESCRIPTION OF SOME EMBODIMENTS

Exemplary embodiments of the present invention will now be described more fully hereinafter with reference to the accompanying drawings, in which some, but not all embodiments of the invention are shown. Indeed, the invention may be embodied in many different forms and should not be construed as limited to the embodiments set forth herein; rather, these embodiments are provided so that this disclosure will satisfy applicable legal requirements. Although the specification may refer to “an”, “one”, or “some” embodiment(s) in several locations, this does not necessarily mean that each such reference is to the same embodiment(s), or that the feature only applies to a single embodiment. Single features of different embodiments may also be combined to provide other embodiments.

Embodiments of present invention are applicable to any user device (i.e. user equipment), messaging server, corresponding component, corresponding apparatus, and/or to any communication system or any combination of different communication systems supporting different user selections relating to waiting messages. The communication system may be a wireless communication system or a communication system utilizing both fixed networks and wireless networks. The protocols used and the specifications of communication systems, and apparatuses, especially in wireless communication, develop rapidly. Such development may require extra changes to an embodiment. Therefore, all words and expressions should be interpreted broadly and are intended to illustrate, not to restrict, the embodiment.

In the following, different embodiments will be described using, as an example of an architecture to which the embodiments may be applied, a converged IP messaging CPM enabler architecture without restricting the embodiments to such an architecture, however.

A general architecture of CPM is illustrated inFIG. 1.FIG. 1is a simplified architecture only showing some functional entities and elements used below in connection to describe different embodiments. The shown entities and elements are logical units whose implementation may differ from what is shown. The connections shown inFIG. 1are logical connections; the actual physical connections may be different. It is apparent to a person skilled in the art that CPM also comprises other functions and structures. It should be appreciated that the functions, structures, elements and the protocols used in or for messaging, are irrelevant to the actual invention. Therefore, they need not to be discussed in more detail here.

The CPM enabler (not shown inFIG. 1) provides a framework by defining a horizontal enabler built on top of a SIP/IP core infrastructure system100. This framework comprises a set of functional components and interfaces that have been designed to facilitate easy deployment of existing and future communication services. For example, the CPM enabler supports full instant messaging, other IP multimedia messaging, push to talk over cellular, and transparent interworking with legacy mobile messaging services in a multi-addresses and multi-devices110(only one illustrated inFIG. 1) environment. All CPM-based services will use functional components, such as participating function PF120, a message storage server150which provides a user-specific network storage for user's messages, for example, and interfaces provided by the framework. Non-CPM communication services require interworking functions130that provide adaptation/mapping between the CPM enabler and the different technologies to communicate with the framework. For interworking, also interworking selection functions140that select an interworking function that perform the actual interworking may be required.

However, the details of CPM are not essential and are therefore not described or illustrated in more detail herein. A more detailed description on CPM is disclosed in documents “Converged IP Messaging Architecture, Draft Version 1.0”, 20 Mar. 2009, OMA-AD-CPM-V1_0-20090320-D, “OMA Converged IP Messaging System Description, Draft Version 1.0”, 20 Mar. 2009, OMA-TS-CPM_System_Description-V1_0-20090320-D and “Converged IP Messaging Requirements, Draft Version 1.0”, 2 Feb. 2009, OMA-RD-CPM-V1_0-20090202-D, which are incorporated by reference herein.

The user device110illustrates one type of an apparatus with which a user may receive messages, notifications and give instructions. The user device110refers to a computing device that includes fixed communication devices, wireless mobile communication devices operating with or without a subscriber identification module (SIM), including, but not limited to, the following types of devices: mobile phone, smartphone, personal digital assistant (PDA), handset, laptop computer, desktop computer and a fixed phone. The user device110is configured to perform one or more of user device functionalities described below with an embodiment, and it may be configured to perform functionalities from different embodiments. For this purpose, the user equipment comprises a messaging client unit MCU111for providing functionality to form and transmit handling instructions for message waiting delivery according to one or more of the embodiments described below. The messaging client unit may be part of a CPM client. Further, the user device may comprise other clients, and it comprises different interfaces, such as a receiving unit112, a sending unit113and user interface114. The user interface may show the user first a handling instruction alternative, then information on waiting messages and then let the user to select messages to which the handling instruction alternative is to be applied, or the user may be provided with the handling instruction alternatives (i.e. options) message by message, so that the user select for each message an alternative. However, how it is implemented, bears no significance to the invention.

The user's home network200comprises the participating function PF120, which acts as the network-side surrogate for the user, including the coordination of interaction with the multiple CPM clients the user may have. The participating function may be seen as a user-specific functional component that may temporarily store in a memory124messages that are waiting delivery to the user. The participating function with its memory represents a network node (a computing apparatus) called a messaging server, and the term “messaging server” is used below. The messaging server120is configured to perform one or more of messaging server functionalities described below with an embodiment, and it may be configured to perform functionalities from different embodiments. For this purpose, the messaging server comprises a message handling unit MHU121for providing functionality to receive handling instructions for waiting messages according to one or more of the embodiments described below. The message handling unit121may further be configured to form a notification according to one or more of the embodiments described below. Further, the messaging server may comprise other handling units and functionalities, and it comprises different interfaces, such as a receiving unit122and a sending unit123.

It should be appreciated that the message storage server provides a permanent user-specific storage, whereas the messaging server provides only a temporary buffer which is shared among all users.

Although the apparatuses, i.e. the user device, the messaging server, the message storage server, the interworking function and the interworking selection function, have been depicted as one entity, they (not shown inFIG. 1) may be implemented in one or more physical or logical entities. The units and functions may be software and/or software-hardware and/or firmware components (recorded indelibly on a medium such as read-only-memory or embodied in hard-wired computer circuitry).

The apparatuses may generally include a processor (not shown inFIG. 1), controller, control unit, micro-controller, or the like connected to a memory and to various interfaces of the apparatus. Generally the processor is a central processing unit, but the processor may be an additional operation processor. The messaging client unit111, and/or the deferred message handling unit121may be configured as a computer or a processor, or a microprocessor, such as a single-chip computer element, or as a chipset, including at least a memory for providing storage area used for arithmetic operation and an operation processor for executing the arithmetic operation. The message client unit111, and/or the message handling unit121may comprise one or more computer processors, application-specific integrated circuits (ASIC), digital signal processors (DSP), digital signal processing devices (DSPD), programmable logic devices (PLD), field-programmable gate arrays (FPGA), and/or other hardware components that have been programmed in such a way to carry out one or more functions of one or more embodiments.

The receiving units and the transmitting units each provides an interface in an apparatus, the interface including a transmitter and/or a receiver or a corresponding means for receiving and/or transmitting information, such as data, content, control information, messages and performing necessary functions so that user data, content, control information, signalling and/or messages can be received and/or transmitted. The receiving and sending units may comprise a set of antennas, the number of which is not limited to any particular number.

The apparatuses may generally include volatile and/or non-volatile memory and typically store content, data, or the like. For example, the memory may store computer program code such as software applications (for example, for the message handling unit or the messaging client unit) or operating systems, information, data, content, or the like for the processor to perform steps associated with operation of the apparatus in accordance with embodiments. The memory may be, for example, random access memory, a hard drive, or other fixed data memory or storage device. Further, the memory, or part of it, may be removable memory detachably connected to the apparatus.

It should be appreciated that the apparatuses may comprise other units used in or for messaging, and other information transmission. However, they are irrelevant to the actual invention and, therefore, they need not to be discussed in more detail here.

Below different embodiments are disclosed assuming that user has waiting messages, and a notification on them is sent. The reasons why there are waiting messages or the event that triggers sending the notification bears no significance and therefore they are not described in detail here. In case the user has multiple devices, the notification may be sent to one, some or all of them. However, below it is assumed for clarity's sake that there is only one user device to which the notification is sent.

FIG. 2illustrates functionality of a messaging server, or more precisely, functionality of the message handling unit, in a situation in which a notification is to be formed, i.e. a situation in which a message is not directly delivered or waiting messages pushed without a request.

FIG. 2starts in a situation in which there are waiting messages, and an event, such as a user becoming available or willing to receive messages, happens. Then a notification is to be formed (step201). Therefore the messaging server obtains, in step202, information on capabilities of the user device(s) whereto the notification is to be sent, user-specific restrictions, if any. The information on the capabilities may be obtained from the user device's registration information, or acquired by using a standardized or proprietor method. The user-specific restrictions are settings set by the user and they may be set device-specifically or depending on message properties, such as size or content type. Examples of device capabilities include memory resources, support for media type(s) in a message, supported image/music rendering, supported text support/alphabet, processing capabilities, and video encoding. It should be appreciated that other features, such as information on the user device connectivity, applicable service provider settings, such as those relating to message delivery, and/or properties of networks participating in transmitting the message may also be taken into account.

Then the messaging server takes, in step203, a message, and determines, in step204, allowable handling instruction alternatives for this specific message by comparing the message features/characteristics (size, media type etc) with obtained device capabilities and user-specific restrictions. When the allowable alternatives have been determined, the messaging server adds, in step205metadata of the message with the allowable alternatives (or indication(s) to them) to a body of the notification. If allowable alternatives have been determined for all waiting messages (step206), the notification is sent, in step207. Otherwise the process returns to step203, and the next message is taken.

The notification may be an in-band notification or an out-of band notification. An in-band notification may be SIP NOTIFY, or a corresponding message having in a body, for example, a summary indicating how many messages there are waiting, and for each message the metadata. The metadata is a header summarizing and identifying the message. The header (metadata) contains preferably a message identifier, or corresponding information with which the specific message can be identified in the messaging server, and the header may further contain one or more of the following fields: to, from, subject, date, size, and priority. The same information may be sent in an out-of band notification, which may be a message sent, for example, as a short message to the user's device.

In another embodiment, the messaging server is configured not to indicate the allowable alternatives with the metadata if all alternatives are allowable. Depending on an implementation, the user device may show all handling alternatives if the indication of alternatives is missing, or the user device may comprise a set of default alternatives that the user device is configured to use if there is no indication of alternatives.

In another embodiment, the user device is configured to determine, on the basis of the received metadata, what alternatives are possible for the corresponding message, and to allow the user select amongst them only.

It should be appreciated that there are embodiments, in which the device capabilities, device connectivity, message characteristics, service provider policies and/or user-specific restrictions are not taken into account but all handling instruction alternatives provided to the user may be the same regardless of the device and/or message properties. At its simplest the notification forming procedure contains only adding to the notification metadata on waiting messages.

FIG. 3illustrates functionality of a messaging server, or more precisely, functionality of the message handling unit when instructions are received from a user device according to an embodiment. In the embodiment it is assumed that all handling instructions are received in one resource list, such as described inFIG. 5. It should be appreciated that the message handling unit may be configured to apply other handling instructions (such as a timer for temporary storing expiring and causing the message to be deleted) but they are irrelevant to the illustrated example and are not described herein. In the illustrated example it is assumed that all messages are found, and no error situation occurs. An example of an error situation is that no session set up confirmation is received from the user device, if there are messages to be delivered to the user device. These error situations are irrelevant to the illustrated embodiments and therefore are not described herein.

When the messaging server receives (step301), a message handling document, or other corresponding instructions how to handle one or more of waiting messages, it takes, in step302, a message identifier, or corresponding information, and the corresponding instruction.

If the instruction is “keep” (step303), the messaging server continues, in step304, to store the message in the temporary buffer. In other words, nothing is done to the message. Depending on an implementation, a timer may be updated, and/or the message be notified again later.

If the instruction is “store” (step305), the message is delivered, in step306, to the user's network storage.

If the instruction is “delete” (step307), the message is deleted, in step308, (without the user seeing/hearing it) from the temporary buffer.

If the instruction is “interwork” (step309), the messaging server checks, in step310, whether or not the instruction contains an extension label indicating what interworking function to use. If there is no label or the label indicates that the messaging server, or a network, may decide, the message is delivered, in step311, to the interworking selection function for further delivery to a proper interworking function. If there is a label indicating what interworking function to use (step310), the message is delivered, in step312, to a corresponding interworking function.

If the instruction is none of the above mentioned, in the embodiment the instruction is then “retrieve”, and the message is temporarily marked, in step313, for retrieval delivery.

The above described process from step302, i.e. from taking a message identifier, or corresponding information, and the corresponding instruction, is repeated until all instructions are handled (step314).

Then it is checked, in step315, whether or not there are any messages marked for retrieval delivery, and if yes, the session is set up in step316, the message(s) marked for retrieval delivery are delivered in step317, and the session is ended in step318.

If there is no message marked for retrieval delivery (step315), the process ends (step319).

In another embodiment of the invention, no extension labels are used, and all messages having the “interwork” instruction are delivered via the interworking selection function to an interworking function. In other words, steps310and312are omitted.

In another embodiment, if the extension label indicates what interworking function to use (i.e. answer in step311is yes), the interworking selection function is not by-passed, but the message is forwarded with the indication to the interworking selection function so that the interworking selection function can do the final selection.

Although not mentioned, it should be appreciated that after a message is delivered, it is deleted from the temporary buffer.

FIG. 4illustrates handling instruction functionality of a user device, or more precisely, functionality of the messaging client unit according to an embodiment.

The user device receives, in step401, a notification on waiting messages. As described above, the notification may be an in-band notification or an out-of band notification, and it may be SIP NOTIFY, or a corresponding message having in a body, for example, a summary indicating how many messages there are waiting and preferably for each message a header summarizing and identifying the message, i.e. metadata of the message.

At some point, the body (the content of the notification) is shown (step402) to a user of the user device, either because the user specifically instructed so, or because of some other event. It is irrelevant what causes the content to be shown. In response to detecting (step403) that the user has selected a metadata of one message, different handling alternatives are shown, in step404to the user. In the illustrated example, the handling alternatives include “retrieve”, “keep”, “store”, “interwork” and “delete”, the meaning of these alternatives being described above. In response to the user selecting one of these alternatives, the selection is received, in step405, and an association is formed, in step406, with the metadata (or with the message identifier) and the selection. Then it is checked, in step407, whether or not each metadata has a selection (i.e. an association), and if not, it is then checked, in step408, whether a user instructions indicating that the user does not want to continue, is received. If the user wants to continue (i.e. no contradictory instruction have been received), the process proceeds to step403to detect that the user has selected a metadata of another message.

If each metadata has a selection (step407) or the user does not want to continue (step408), the user device forms (compiles), in step409, a message handling document using the associations to provide message-specific instructions. Examples of the message handling document are described withFIGS. 5 and 6. Then the user device generates, in step410, a SIP INVITE request, the request having in a multipart/mixed body an SDP (session description protocol) description for a session between the user device and the messaging server and then adds, in step411, the message handling document to the multipart/mixed body of the request, and includes, in step412, either in an accept contact header or in a require header field in the request the mime-type of the message handling document, and then sends, in step413, the request to the messaging server in the home network, the request being addressed to insert_server_function@hostname, for example. An example of a mime-type includes “application/vnd.cpm.message-handling+xml”.

In another embodiment, the user device may check, when generating the SIP INVITE, whether or not the alternative “retrieve” is selected at least once. If yes, the user device continues as described above, and if no, the SDP description (or no SDP description) in the SIP INVITE may indicate that the SIP INVITE is used for sending handling instruction and no session establishment is requested. In the embodiment, step315in the messaging server is replaced by checking whether or not the SIP INVITE is also for session establishment.

In a further embodiment, the user device may be configured to check after sending the SIP INVITE, whether or not the alternative “retrieve” is selected at least once. If yes, the user device continues the session set up, receives the messages and then ends the session If no, the user device cancels the session set up.

FIG. 5illustrates an example of message handling instructions according to an embodiment. In the example the message handling instructions is a system message based on XML (extensible markup language) 1.0 document and uses UTF-8 encoding (UTF is a universal character set transformation format), indicated by5-1. The document utilizes XML namespaces for identifying system management documents and document fragments.

A corresponding XML schema providing a formal description on an appearance of a message handling document illustrated inFIG. 5is as follows:

An advantage of the embodiment is that everything is in one body.

FIG. 6illustrates another example of message handling instructions according to a further embodiment. In the example the message handling instructions differ from the one illustrated inFIG. 5in that respect that the handling indications for “retrieve” are held in their own body as a resource-list, but the other handling indications are in a similar body than the body described withFIG. 5.

In other words, the message handling instructions is a system message based on XML (extensible markup language) 1.0 document and uses UTF-8 encoding (UTF is a universal character set transformation format), indicated by6-1. The actual message handling document600comprises two parts: a resource list (a first body6-6) comprising list elements6-5beginning with a root element6-4and a message handling document (a second body6-7) comprising leg elements6-3and beginning with a root element6-2, both root elements from the namespace6-21. Each list and leg element contains an “MSG-ID” attribute containing a unique identity of a message the requested handling instruction indicated by a “handling” attribute relates to. The message handling document may be identified with the mime-type “application/vnd.cpm.message-id+xml” in CPM. In other architectures another kind of mime-type may be used.

An advantage of the embodiment is that the prior art body for content type “application/resource-list+xml” used for retrieve messages can be reused without change.

It should be appreciated that in further embodiments, the message handling instructions may be formed so that there is a separate body for each different instruction alternative, or some of them may have a common body and some their own body. For example, “store” and “keep” may have a common body, but “retrieve”, “delete” and “interwork” their own body.

Although not shown inFIGS. 5 and 6, the SIP INVITE request contains also information describing the session to be formed to convey the messages having “retrieve” as their instruction.

FIG. 7illustrates signalling according to an embodiment of the invention in a situation in which the handling instruction comprises a separate body for “retrieve” and a separate body for other handling alternatives.

Referring toFIG. 7, the user device receives a notification7-1. The notification may be a SIP NOTIFY and in the illustrated example it informs that there are four messages M1, M2, M3and M4waiting. The user device receives, in point7-2, user input that indicates that messages M2and M4are to be retrieved, messages M1and M3discarded. Therefore the user device forms, in point7-3a handling instruction that contains list definitions for M2and M4and leg definitions for M1and M3. Then the user device sends the handling instructions7-3. The handling instruction may be SIP INVITE.

When the messaging server receives, in point7-4, handling instructions7-3, it takes a first body, detects that there is list definitions, and therefore a session needs to be established, the session being described in the handling instruction7-3. Thus, the messaging server sends an acceptance7-5, such as SIP200OK, and retrieves, in point7-4, messages M2and M4. After receiving from the user device an acknowledgement7-6, such as SIP ACK, for the message sending session, the messaging server sends (point7-7) the messages M2and M4in message7-8, such as MSRP (message session relay protocol) SEND. When the user device has received messages M2and M4, the user devices acknowledges the reception by sending message7-9, such as MSRP OK. After receiving the acceptance, the messaging server ends (point7-10) the session by sending message7-11, such as SIP BYE, and the user device confirms that the session will end by sending message7-12, such as SIP200OK.

Meanwhile, or after that, the messaging server takes, in point7-13, a second body, and goes the leg definitions trough leg by leg. In this example, the messaging server deletes messages M1and M3from the temporary storage.

If no message is to be retrieved, the messaging server may acknowledge the handling instruction by sending a specific type of message indicating that the instructions are received but no session is established.

In another embodiment, if there is no instruction associated with a message, i.e. the resource list is formed so that it contains all the same identifiers that were sent in a notification, but the user has not provided any instruction for a message, the messaging server may be configured to use a default value, such as “keep”, or to treat the message as “non-notified”. The default-value may be user-specific or service provider-specific and it may depend on message content, size, user device capabilities, etc.

As can be seen from the above example, the invention is not limited to CPM but it may be implemented in any system utilizing SIP or corresponding platform. An example includes a SIMPLE instant messaging system.

The handling instruction alternatives given above are only exemplary and only some of them may be used, or in addition to them, or some of them, some other handling instructions, such as “forward”, may be used, or for the same purpose another term may be used. For example, in the above terms “delete” and “discard” have been used for the same purpose. In other words, the handling instruction alternatives are not restricted in any way.

Although in the above the embodiments have been described, for the sake of clarity, assuming that one message has one handling instruction, it should be appreciated that one message may have more than one handling instruction, and the messaging server performs them. For example, there may be only one waiting message, and the user instructs to forward the message to another user and in addition to store or retrieve it.

The steps/points, messages, information exchange and related functions described above inFIGS. 2 to 7are in no absolute chronological order, and some of the steps/points or functions may be performed and/or messages sent simultaneously or in an order differing from the given one. For example, messages may be delivered to a user device while other messages are deleted or stored. Other functions can also be executed between the points or functions or within the steps/points and other messages sent between the illustrated messages, such as sending acknowledgements. Some of the functions or the steps/points or part of the steps/points can also be left out or replaced by a corresponding function or step/point or part of the step/point. Further, functions, steps/points and/or messages described with different embodiments may be combined to obtain further embodiments. The messages are only exemplary and may even comprise several separate messages for transmitting the same information. In addition, the messages may also contain other information. Depending on the network technologies involved, other entities may take part to the signalling than those described above.

Although in the above the embodiments have been described assuming that the messaging server is in the user's home network, it should be appreciated that a solution, in which waiting messages are stored in another network than the home network, and the messaging server locates in such a network, is possible and straightforwardly implementable using the above descriptions.

The techniques described herein may be implemented by various means so that an apparatus implementing one or more functions of a corresponding user device or messaging server described with an embodiment comprises not only prior art means, but also means for implementing the one or more functions of a corresponding apparatus described with an embodiment and it may comprise separate means for each separate function, or means may be configured to perform two or more functions. For example, these techniques may be implemented in hardware (one or more apparatuses), firmware (one or more apparatuses), software (one or more modules), or combinations thereof. For a firmware or software, implementation can be through modules (e.g., procedures, functions, and so on) that perform the functions described herein. The software codes may be stored in any suitable, processor/computer-readable data storage medium(s) or memory unit(s) or article(s) of manufacture and executed by one or more processors/computers. The data storage medium or the memory unit may be implemented within the processor/computer or external to the processor/computer, in which case it can be communicatively coupled to the processor/computer via various means as is known in the art.