Method for transmitting short messages over the internet
27 claims: 1 independent, 26 dependent
- 1Verfahren zum Übermitteln von Kurznachrichten (SMS) zwischen Rechnern (3, 8, 9) im AT 41 1 312 B Internet (4), wobei die Kurznachricht (SMS) in ein aus einem Kopfteil (10) und einem Nutzteil (32) bestehendes Datenformat gebracht wird, wobei in den Kopfteil (10) zumindest ein Datenfeld (11) zur Festlegung des Datenformats, zumindest ein Datenfeld (16) (SenderAddress) für die Senderidentifikation und zumindest ein Datenfeld (19) (Recipient-Address) für die Empfängeridentifikation eingefügt wird, dadurch gekennzeichnet, dass vor, während und allenfalls nach der Übermittlung der Kurznachricht (SMS) Zeichenketten (.LOGIN, .SELECT-CHANNEL) zur Steuerung verbindungsorientierter Sitzungen zwischen den Rechnern (3, 8, 9) ausgetauscht werden.
- 2Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass vor der Übermittlung der Kurznachricht (SMS) zumindest eine Zeichenkette (.SELECT-CHANNEL) zur Kanalauswahl zwischen den Rechnern (3, 8, 9) des Internet (4) ausgetauscht wird.
- 3Verfahren nach Anspruch 2, dadurch gekennzeichnet, dass vor der Übermittlung der Kurznachricht (SMS) zumindest eine Zeichenkette (.LOGIN) zur Authentifizierung des Senders der Kurznachricht (SMS) zwischen den Rechnern (3, 8, 9) des Internet (4) ausgetauscht wird, und dass diese Zeichenkette (.LOGIN) zumindest eine Benutzerkennung enthält.
- 4Verfahren nach einem der Ansprüche 1 bis 3, dadurch gekennzeichnet, dass im Datenfeld (11) zur Festlegung des Datenformats die MIME (Multipurpose Internet Mail Extensions) Version eingetragen wird.
- 5Verfahren nach einem der Ansprüche 1 bis 4, dadurch gekennzeichnet, dass in den Kopfteil (10) ein Datenfeld (12, MIME-Type) zur Definition der Art der Kurznachricht (SMS) eingefügt wird.
- 6Verfahren nach einem der Ansprüche 1 bis 5, dadurch gekennzeichnet, dass in den Kopfteil (10) ein Datenfeld (13, Message-Id) zur Angabe einer eindeutigen Identifikation für die Kurznachricht (SMS) eingefügt wird.
- 7Verfahren nach einem der Ansprüche 1 bis 6, dadurch gekennzeichnet, dass in den Kopfteil (10) ein Datenfeld (14, Sender-Ton) zur Angabe der Art des Netzwerkes des Senders der Kurznachricht (SMS) eingefügt wird.
- 8Verfahren nach einem der Ansprüche 1 bis 7, dadurch gekennzeichnet, dass in den Kopfteil (10) ein Datenfeld (15, Sender-Npi) für die Festlegung des Nummerierungsplans des Netzwerkes des Senders eingefügt wird.
- 9Verfahren nach einem der Ansprüche 1 bis 8, dadurch gekennzeichnet, dass in den Kopfteil (10) ein Datenfeld (17, Recipient-Ton) zur Festlegung der Art des Netzwerkes des Empfängers eingefügt wird.
- 10Verfahren nach einem der Ansprüche 1 bis 9, dadurch gekennzeichnet, dass in den Kopfteil (10) ein Datenfeld (18, Recipient-Npi) zur Definition des Nummerierungsplans des Netzwerkes des Empfängers eingefügt wird.
- 11Verfahren nach einem der Ansprüche 1 bis 10, dadurch gekennzeichnet, dass in den Kopfteil (10) ein Datenfeld (20, Protocol-Id) zur Kennung des für den mit der Kurznachricht (SMS) transportierten Inhalts eingefügt wird.
- 12Verfahren nach einem der Ansprüche 1 bis 11, dadurch gekennzeichnet, dass in den Kopfteil (10) ein Datenfeld (21, Is-Compressed) zur Anzeige einer Komprimierung der Nutzdaten eingefügt wird.
- 13Verfahren nach einem der Ansprüche 1 bis 12, dadurch gekennzeichnet, dass in den Kopfteil (10) ein Datenfeld (22, Message-Class) zur Unterscheidung der Klasse der Kurznachricht (SMS) eingefügt wird.
- 14Verfahren nach einem der Ansprüche 1 bis 13, dadurch gekennzeichnet, dass in den Kopfteil (10) ein Datenfeld (23, Alphabet) zur Festlegung der Codierung der Nutzdaten eingefügt wird.
- 15Verfahren nach einem der Ansprüche 1 bis 14, dadurch gekennzeichnet, dass in den Kopfteil (10) ein Datenfeld (24, Priority) zur Festlegung der Priorität der Kurznachricht (SMS) eingefügt wird.
- 16Verfahren nach einem der Ansprüche 1 bis 15, dadurch gekennzeichnet, dass in den Kopfteil (10) ein Datenfeld (25, Validity-Periode) zur Eingabe des Ablaufdatums der Kurznachricht (SMS) eingefügt wird.
- 17Verfahren nach einem der Ansprüche 1 bis 16, dadurch gekennzeichnet, dass in den AT 41 1 312 B Kopfteil (10) ein Datenfeld (26, Cod) zur Bestimmung, ob eine Bestätigung des Empfangs der Kurznachricht (SMS) verlangt wird, eingefügt wird.
- 18Verfahren nach einem der Ansprüche 1 bis 17, dadurch gekennzeichnet, dass in den Kopfteil (10) ein Datenfeld (27, Replace-If-Present) zur Festlegung, ob eine vorher verfasste Kurznachricht (SMS) durch die neue Kurznachricht (SMS) zu ersetzen ist, eingefügt wird.
- 19Verfahren nach einem der Ansprüche 1 bis 18, dadurch gekennzeichnet, dass in den Kopfteil (10) ein Datenfeld (28, Reply-Path) zur Bestimmung der Anzahl der Wiederholungen der Sendeversuche für die Kurznachricht (SMS) eingefügt wird.
- 20Verfahren nach einem der Ansprüche 1 bis 19, dadurch gekennzeichnet, dass in den Kopfteil (10) ein Datenfeld (29, Send-On) zur Festlegung eines gewünschten Sendezeitpunkts der Kurznachricht (SMS) eingefügt wird.
- 21Verfahren nach einem der Ansprüche 1 bis 20, dadurch gekennzeichnet, dass in den Kopfteil (10) ein Datenfeld (30, Created-On) zur Eintragung des Erstellungszeitpunkts der Kurznachricht (SMS) eingefügt wird.
- 22Verfahren nach einem der Ansprüche 1 bis 21, dadurch gekennzeichnet, dass in den Kopfteil (10) ein Datenfeld (31, Sender-lp-Address) zur Übertragung der Internetadressen (IP-Nummern) der an der Übertragung beteiligten Rechner eingefügt wird.
- 23Verfahren nach einem der Ansprüche 1 bis 22, dadurch gekennzeichnet, dass der Empfänger der Kurznachricht (SMS) auf die Übermittlung einer Zeichenkette (.LOGIN) zur Authentifizierung des Senders der Kurznachricht (SMS) eine Zeichenkette an den Sender übermittelt, welche zumindest einen Statuscode über den Erfolg der Authentifizierung enthält.
- 24Verfahren nach einem der Ansprüche 1 bis 23, dadurch gekennzeichnet, dass nach erfolgreicher Anmeldung vom Sender an den Empfänger der Kurznachricht (SMS) eine Zeichenkette (.SELECT-CHANNEL) übermittelt wird, welche Angaben über die Auswahl eines Ausgabekanals des empfangenden Rechners enthält.
- 25Verfahren nach Anspruch 24, dadurch gekennzeichnet, dass der Empfänger an den Sender der Kurznachricht (SMS) mit einer Zeichenkette antwortet, welche Angaben über den Erfolg der Auswahl des Ausgabekanals enthält.
- 26Verfahren nach einem der Ansprüche 1 bis 25, dadurch gekennzeichnet, dass vom Sender der Kurznachricht (SMS) eine Zeichenkette (.QUIT) übermittelt wird, welche einen Quittierungsbefehl zum Beenden der Übermittlung der Kurznachricht (SMS) enthält.
- 27Verfahren nach Anspruch 26, dadurch gekennzeichnet, dass eine Zeichenkette als Antwort des Empfängers der Kurznachricht (SMS) Angaben über den Erfolg des Quittierungsbefehls an den Sender der Kurznachricht übermittelt wird.
Independent claims27
88 paragraphs in 1 section, as filed
The present invention relates to a method for transmitting short messages between computers on the Internet, the short message being converted into a data format consisting of a header and a payload, with at least one data field for defining the data format, at least one data field for the sender identification and in the header at least one data field for the recipient identification can be inserted.
For the transmission of short messages, so-called short messages, a data service was created in GSM (Global System for Mobile Communication) based mobile radio networks, which has become known under the abbreviation SMS (Short Messages System). This data service is used to transfer short messages limited to 160 alphanumeric characters between mobile telephones or terminals quickly and cheaply. In addition to sending texts, it is also possible to send pictures or sounds via SMS. Accordingly, a distinction is made between textual and binary short messages. Longer documents, for which the 160 characters are not sufficient for transmission, can be sent using so-called segmented short messages, that is, individual short messages that can be chained together. The limitation to 160 characters per SMS is due to the technology of the end devices, such as cell phones.
To transmit short messages between two mobile phones, the desired short message is entered by the sender using the keyboard of a mobile phone and then sent. After the message has reached the short message center (SMSC - Short Message Service Center) of the respective cell phone network operator, it is saved there. The short message center SMSC tries to forward the short SMS message to the recipient by sending transmission information, the so-called Send Routing Information (SRI), to a register containing information about the addresses of the subscribers, the so-called Home Location Register (HLR). The recipient can be located in the HLR using the recipient number. The HLR replies to the short message center (SMSC) with information, and the short message center (SMSC) sends this information together with the short message to the corresponding switching unit, the so-called Mobile Switching Center (MSC), which the subscriber or the corresponding base station in the Cell, in which the subscriber is currently located, searches and sends the short message to this base station. The transmission within the mobile telephone network usually takes place according to the so-called SS7 (Signaling System No. 7) protocol.
Such a transmission of short messages within a telecommunications network is disclosed in US Pat. No. 5,915,222 A, for example. US Pat. No. 5,768,509 A also describes a short message service for mobile telecommunication networks. A method for transmitting short messages in a digital telecommunications system is known from WO 98/02005 A1, which does not require special SMS interfaces and thus ensures a simple and inexpensive structure.
It is also common to send short messages from data networks, such as the Internet, to mobile terminals. In this case, the short message is entered via the keyboard of a computer and forwarded via the data network, for example the Internet, to a corresponding converter, a so-called gateway. The short message is forwarded from the gateway to the short message center (SMSC) of the corresponding telecommunications network using a specific protocol. One of the following three protocols is usually used to exchange short messages between the data network and the telecommunications network:
1) Short Message Peer-To-Peer Protocol (SMPP)
2) Universal Communication Protocol (UCP)
3) Computer Interface for Message Distribution (CIMD)
All of these known protocols are suitable for connecting an application server to the short message center of a telecommunications network. For service providers of data networks, for example the Internet, who maintain the connections to the short message centers of more than one telecommunications network operator, problems arise in this context: The service providers must support all protocols, since different protocols can be used depending on the telecommunications network operator. Furthermore, there is no uniform format for the short messages which are used for the administration, storage and transmission of the same via data networks outside the telecommunication networks
AT 41 1 312 B could. To remedy this, the service providers have to develop and implement internal short message formats that differ from the data formats according to the three protocols mentioned above.
To transmit short messages from mobile terminals to data networks, a data line is required between the short message center of the telecommunications network operator and the corresponding data network. However, this confronts the service provider of the data network with enormous costs for renting corresponding, often international, data connections.
WO 00/36854 A1 discloses a method for transmitting short messages to analogue terminals, with a corresponding conversion of the digital content of the short message into analog signals, for example into audio signals. This enables short messages to be sent from cell phones to analog fax machines, for example.
US 6 078 820 A and US 6 125 281 A describe further methods for transmitting messages in telecommunication systems, although a direct connection between the short message center of the mobile telephone network operator and the respective server of the data network, for example the Internet, is required via a dedicated line.
WO 97/20442 A1, EP 0 777 394 A1 and US Pat. No. 6 067 529 A describe methods for transmitting short messages over the Internet, in which, for example, an e-mail is converted into a short message and transmitted to a mobile recipient within a cellular network or the conversion of a short message into a fax or into an e-mail.
WO 99/20062 A1 describes a method for transmitting short messages between a short message center and mobile terminals. The transmission of short messages between computers on the Internet is not dealt with in this document.
EP 0 954 146 A2 shows a method for the transmission of data via the Internet to a mobile terminal, using conventional data formats, so-called PDUs (Protocol Data Units).
An exchange of character strings between the computers on the Internet before, during and, if necessary, after the transmission of short messages is not described in any of the documents mentioned.
The aim of the present invention is to create a method for transmitting short messages over the Internet, using a generally applicable data format. Furthermore, the data format should be expandable for additional features of short messages and future new characteristics. The disadvantages of the known methods are to be avoided or at least reduced, so that sending short messages via data networks such as the Internet is possible in an efficient and cost-effective manner.
The object according to the invention is achieved in that character strings for controlling connection-oriented sessions are exchanged between the computers before, during and possibly after the transmission of the short message. By using such a generalized data format, which combines all parameters necessary for the description of the short messages in a data record, it is possible to transmit all types of short messages, namely binary, textual and segmented short messages. The data format according to the invention was constructed in a similar way to the e-mail formats on the Internet and differs significantly from the usual data formats, the so-called PDUs (Protocol Data Units), in the three existing protocols SMPP, UCP and CIMD. The useful part of the data format contains the actual information to be sent in the short message. The defined header together with the corresponding useful message makes it possible to transmit the short message over the Internet, regardless of the protocol used, between the short message centers of the telecommunication networks and the data network. In the data format according to the invention, short messages with more than 160 characters can be transmitted without having to segment short messages as usual and concatenate them after transmission. In the present case, messages that exceed 160 characters are only transmitted separated by line breaks.
At least one character string for channel selection is advantageously exchanged between the computers on the Internet before the short message is transmitted.
According to a further feature of the invention it is provided that before the transmission of the
AT 41 1 312 Β
Short message, at least one character string for authenticating the sender of the short message is exchanged between the computers on the Internet, and that this character string contains at least one user ID.
The so-called MIME version (Multipurpose Internet Mail Extensions) is preferably entered in the data field to determine the data format. This is an Internet standard for specifying file types for communication on the Internet. The value for the MIME type is currently fixed at 1.
Further parameters that are assigned to a short message can be set using additional data fields.
According to a further feature of the present invention it is provided that the header has a data field for defining the type of short message. The so-called MIME type is used to differentiate between different transported content (media objects). Accordingly, the data format according to the invention uses this field to differentiate between purely textual, binary or segmented short messages. When text messages are sent, the useful information of the short message is saved as normal text in ISO format. Binary short messages are transmitted as a sequence of hexadecimal-coded characters.
A data field for specifying a unique identification for the short message can also be provided in the header.
Furthermore, the header of the data format can contain a data field for specifying the type of network of the sender of the short message.
In addition, there can be a data field for defining the numbering plan of the network of the transmitter.
Optionally, there can also be a data field for defining the type of network of the recipient and a data field for defining the numbering plan of the network of the recipient.
An identifier for the content transported with the short message can also be advantageous for various applications. Accordingly, there can also be a field in the data format for this identifier.
Another field in the data format can be used to identify whether the user data is compressed in the short message.
Another data field can be provided to differentiate the class of the short message according to the GSM standard 03.38.
Another field can be reserved in the data format to define the coding of the user data of the short message. For example, a distinction can be made between a normal alphabet, 8-bit data, the so-called UCS2 coding and others.
To determine the priority of the short messages, for example, a scale ranging from 0 to 9 can be provided in a data field of the data format.
If there is another data field for entering the expiry date of the short message, it can be automatically deleted after this expiration time is exceeded and no longer transmitted.
Another field can be used to indicate whether a confirmation is required after the short message has been successfully delivered to the recipient or whether such a confirmation is not required.
Another data field in the data format according to the invention can be reserved for this purpose in order to indicate whether a previously delivered short message is to be replaced by the present short message. As a result, redundant short messages or short messages that are no longer up-to-date can be automatically replaced by up-to-date short messages.
Another data field can be used to determine whether the short message should be sent repeatedly or not.
Another option in the data format provides that a date on which the short message should be forwarded can be entered.
A data field for entering the date on which the short message was created can also be advantageous.
Another data field can be provided for the transmission of the Internet addresses (IP number addresses) of the computers involved in the transmission. This allows you to safely4
AT 411 312 B unit checks are made when receiving and transmitting the short messages.
In addition, the data format according to the invention can be expanded almost indefinitely to further data fields for future characteristics of short messages. The data format according to the present invention makes it possible to transmit short messages efficiently and inexpensively using existing data networks, such as the Internet, without the need for very expensive dedicated lines between the data network and the telecommunications network. The present invention therefore offers the possibility of transmitting short messages between both mobile and stationary terminals in a very favorable manner. When communicating within a data network, the short messages are transmitted in the data format according to the invention. In the case of communication between the Internet and different telecommunication networks, it is necessary to convert the protocol between the protocols usually used and a protocol based on the data format according to the invention. Such a conversion is preferably carried out in software in so-called gateways.
The character strings described together with the short message transmitted in the data format described above create a universal protocol for the transmission of short messages between computers in a data network. The sending computer first logs on to the receiving computer using a character string that contains a user ID and a password, to which the receiving computer replies to the sending computer with a character string that contains a status code and a status description that shows whether the Registration was successful or not. The sending computer then selects an output channel on the receiving computer and sends a character string together with the name of the output channel to the receiving computer. The receiving computer responds with a character string that contains a status code and a status message that shows whether the selection of the output channel was successful or not. Finally, the sending computer sends a short message to the receiving computer. The sending computer can end an existing session at any time by sending an acknowledgment string to the receiving computer. In such a case, the receiving computer ideally replies with a character string that contains a status code and a status message that indicates whether the operation was successful or not.
Accordingly, according to the present invention, a protocol for the transmission of short messages via computer networks is created in which so-called connection-oriented sessions are possible from one end point to another end point. So-called TCP / IP (Transmission Control Protocol / Internet Protocol) -based networks are an example of this.
The invention is explained in greater detail below on the basis of exemplary embodiments with reference to the accompanying drawings. 1 shows a schematic block diagram to illustrate the transmission of short messages between mobile telephones; 2 shows a schematic block diagram to illustrate the transmission of short messages from a stationary terminal, such as a computer to a mobile phone; Fig. 3 schematically the network architecture for the transmission of short messages over the Internet according to the present invention; and FIG. 4 schematically shows an example of a data format.
According to FIG. 1, a short message SMS is generated by a mobile phone 1 and transmitted to a short message center SMSC of the mobile network operator. The short message center SMSC sends what is known as Send Routing Information SRI to the home location register HRL, which uses the recipient number to locate the recipient and responds to the short message center SMSC with appropriate information. Together with the information received from the Home Location Register HRL and the short message SMS, the short message center SMSC sends the corresponding data to an associated switching unit, the corresponding Mobile Switching Center MSC. The MSC finally sends the short message SMS to a corresponding base station BS, namely that which belongs to the cell in which the subscriber is currently located, and forwards the short message SMS to the mobile phone 2 of the recipient.
Fig. 2 shows the case of the transmission of a short message SMS from a stationary terminal
AT 411 312 B advises a computer 3, for example, to use a data network 4, for example the Internet, to use a mobile terminal device, for example a mobile phone 2 of a recipient. For this purpose, the short message SMS is entered via the keyboard of the computer 3 and forwarded via the data network 4, for example the Internet, to a corresponding gateway 5, which converts the short message SMS into one of the usual protocols. The short message SMS is forwarded from the data network 4 to the short message center SMSC of the telecommunications network 7 via a data line 6. Within the telecommunications network 7, the short message SMS is forwarded to the mobile phone 2 of the recipient in accordance with the procedure indicated in FIG. 1. According to the prior art, a data line 6 designed as a dedicated line is often required between the data network 4 and the telecommunications network 7, which causes high costs that have to be transmitted to the sender and / or the recipient of the short messages.
3 shows a network architecture for the transmission of short messages over a data network, in particular the Internet, according to the present invention. A computer 3, via which a short message SMS can be transmitted to another computer 8, is arranged within the data network 4. The communication between the computers 3 and 8 takes place via the ISMTP protocol (Internet Short Message Transfer Protocol) based on the data format according to the invention. If the short messages are to be transmitted to a telecommunications network 7, the data format according to the invention must be converted to one of the protocols commonly used for communication between the data network 4 and a telecommunications network 7, which is carried out by the computer 8 or a gateway 9. In one of the protocols described, the Short Message PeerTo-Peer Protocol (SMPP), the Universal Communication Protocol (UCP) or the Computer Interface for Message Distribution (CIMD), the short message SMS arrives at a short message center SMSC of a telecommunication network 7 and is from there forwarded in a manner known per se to the mobile phone of a recipient (not shown in FIG. 3). In the data network 4, a distinction is made between three different types of nodes: the computer 3, which is a computer for generating and forwarding SMS short messages; the computer 8, which is set up to receive short messages that are sent via the computer 3 or of short messages that originate from a gateway 9 and forwards the corresponding short messages to other computers 8; and finally the gateways 9 as a third type of node within the data network 4, which can receive short messages from a transmitter via the computer 3 or a computer 8 located in the data network 4 and forward them to a short message center SMSC of a telecommunications network 7.
The functions of the computers in a data network 4, which are connected by means of the ISMTP protocol according to the invention, are designated as follows: The computer 3 is referred to as the ISMT client, the computer 8 as the ISMT transfer agent and the computer 9 as the ISMT gateway. The computer 9, the ISMT gateway, assumes the function of a so-called external short message unit ESME (External Short Message Entity), which is connected to the short message center SMSC via a direct connection. With the aid of the ISMTP protocol according to the invention, short messages are transmitted over data networks 4 between computer 3 (ISMT clients), computer 8 (ISMT transfer agents) and computer 9 (ISMT gateways). At the border of the data network 4, the short messages in the data format according to the invention are converted by the computer 9 (ISMT gateway) into the specific data formats required for communication with a short message center SMSC of a specific provider. The short messages are then transmitted to the short message center SMSC using one of the usual protocols SMPP, UCP or CIMD.
The ISMTP protocol according to the invention differs in two essential points from existing protocols for the transmission of short messages between so-called external short message units ESME and short message centers SMSC. First of all, the log is not only machine-readable, but can also be read by a human or used manually as a command language. At times, the protocol allows messages to be sent to computer 8 (ISMT transfer agent), which accept and process the short message before it is forwarded to another computer 8 (ISMT transfer agent) or delivered to a short message center SMSC. In contrast, existing Proto6
AT 41 1 312 B kolle designed only for the transmission of short messages from an external short message unit ESME to a short message center SMSC.
An example is given below in which a computer R1 sends a short message to a computer R2 using the ISMTP protocol according to the invention. The computers R1 and R2 mentioned can be one of the computers 3 (ISMT client) 8 (ISMT transfer agent) or 9 (ISMT gateway) described above. The computer R1 opens a session-oriented connection via a data network, which allows session-oriented connections. Typically, the computer R1 opens a TCP / IP connection via an IP-based network to a so-called dedicated port on the computer R2. Next, the computer R1 authorizes itself to the computer R2 by the computer R1 sending the character string .LOGIN together with a user ID and a password to the computer R2. The computer R2 also replies with a character string that contains a status code and a status description from which it can be seen whether the registration was successful or not. The computer R1 then selects a so-called output channel to which a short SMS message is to be transmitted in the following. The computer R1 sends a character string .SELECT-CHANNEL together with the name of an output channel to the computer R2. The computer R2 replies again with a character string which contains a status code and a status message from which it can be seen whether the selection of the output channel was successful or not. Finally, the computer R1 transmits a short message to the selected output channel at the computer R2 by R1 transmitting the character string .START-TRANSFER, followed by a short message in the data format according to the invention and the character string .END-TRANSFER to the computer R2. The computer R2 in turn replies with a character string that contains a status code and a status message from which it can be seen whether or not the message could be transmitted successfully. Furthermore, the computer R1 can send the character string .QUIT to the computer R2 at any time in order to end the existing session with the computer R2. In this case too, the computer R2 replies with a character string which contains a status code and a status message which indicates whether the operation was successful or not.
In the following, an example of a data format according to the invention consisting of a head part 10 and a useful part 32 is reproduced with a series of data fields 11-31 in the head part 10, which are explained in more detail below:
MIME (Multipurpose Internet Mail Extension) version: This data field 11 indicates the MIME version of the short message; this field 11 is currently fixed at the value 1. In the event of future changes, this can be entered in the corresponding data field 11 of the data format.
MIME (Multipurple Internet Mail Extension) type: This data field 12 indicates the type of content (media objects) transported in the short message, ie whether it is a textual, segmented or binary short message.
Message identification (Message-Id): This data field 13 can contain a unique identification which is defined by the sender of the short message. The value of this data field 13 is preferably in encrypted form.
Sender tone: This data field 14 indicates the type of network of the sender address and, in accordance with the GSM specification 03.40, 9.1.2.5, consists of a value between 0 and 7.
Sender-Npi: This data field 15 contains the network numbering plan of the sender address and has a value of 0, 1,3, 4, 8, 9 or 10 according to the GSM specification 03.40, 9.1.2.5.
Sender address (Sender-Address): This data field 16 contains the address of the sender in a format corresponding to the data field 14 for the entry of the sender tone and the data field 15 for the sender Npi.
Recipient tone: This data field 17 contains the entry for the recipient address in accordance with the data field 14 sender tone described above.
Recipient Npi: This data field 18 contains the network numbering plan for the recipient address, like data field 15 for the sender Npi.
Recipient-Address: This data field 19 contains the address of the recipient in a format corresponding to the data field 17 receiver-tone and the data field 18 receiver-Npi.
Protocol identification (Protocol-Id): This data field 20 contains an identifier for the with the
AT 411 312 B
SMS transported content and can have a value between 0 and 255 according to the GSM specification 03.40, 9.2.3.9.
Compression (Is-Compressed): This data field 21 indicates whether the user data in the short message is compressed or not and preferably has a value of 0 or 1.
Message class (MESSAGE class): This data field 22 contains information about the class of the short message according to the GSM standard 03.38, page 6.
Alphabet (alphabet): This data field 23 contains information about the coding of the useful data of the short message SMS.
Priority: This data field 24 contains an optional indication of the priority of the short message sent and can have values between 0 and 9, for example.
Expiry (Validity Period): This data field 25 can contain a date and / or a time at which the short message is to expire and is to be deleted accordingly.
Confirmation (Cod): This data field 26 can contain an entry as to whether a confirmation is required after the short message SMS has been successfully delivered to the terminal or not. This data field 26 preferably contains the value 0 or 1.
Replace (Replace-If-Present): This data field 27 indicates whether a previously delivered short message is to be replaced by the new short message, and can again have a value of 0 or 1.
Repetition (Reply-Path): This data field 28 contains an indication of whether the short message is to be repeated or not.
Send-On: This data field 29 contains information about the date and possibly the time at which or at which the short message is to be forwarded.
Creation date (created-on): This data field 30 contains information about the date and possibly the time of production of the short message.
Sender IP address (Sender IP address list): If necessary, the unambiguous Internet address (IP address) of the sender of the short message can be entered in the existing data format in a data field 31. In this way, all Internet addresses (IP number addresses) of the computers involved in the transmission can be specified. This enables security checks to be carried out when receiving and transmitting short messages.
Useful part 32: Here, after the data listed above, the actual useful message follows, which is either in textual form or in binary form. A hexadecimal conversion of the useful signal information can be provided.
In the simplest case, a data record of a short message according to the present invention contains information about the MIME version, information about the address of the sender, information about the address of the recipient and finally the short message in textual or hexadecimal form and a corresponding end character.
The following is an example of a short message in text format that is sent to the recipient address 436766688600:
MIME version: 1.0
Message-ID: T-Mobil-SMS-345672
MIME type: x-ismt / x-text-message
Sender address: 82668
Recipient address: 436766688600
Hi! This is a normal text SMS. Here is the payload.
The technology according to the invention enables short messages to be transmitted efficiently and inexpensively via computer networks, such as the Internet, outside of the mobile telephone networks. The invention is expressed in a special method or in a special transmission protocol and thus also in a special short message format.
5 sheets
Sheet 1 Sheet 2 Sheet 3 Sheet 4 Sheet 5
Every citation, both waysCites: the store holds 5 of 6
| Document | Relation | Office | Cited during |
|---|---|---|---|
| EP0777394A1 | Cites | European Patent Office (EPO) | Search report |
| EP0954146A2 | Cites | European Patent Office (EPO) | Search report |
| US6067529A | Cites | United States of America | Search report |
| WO9720442A1 | Cites | World Intellectual Property Organization (WIPO) | Search report |
| WO9920062A1 | Cites | World Intellectual Property Organization (WIPO) | Search report |
| BORENSTEIN N., AND N. FREED, "MIME (MULTIPURPOSE INTERNET MAIL EXTENSIONS) PART ONE: MECHANISMS FOR SPECIFYING AND DESCRIBING THE FORMAT OF INTERNET MESSAGE BODIES", RFC 1521, BELLCORE, INNOSOFT, SEPT. 1993. | Non-patent | – | Search report |
9 members in 5 offices
Priority claims2
| Document | Office | Kind | Date |
|---|---|---|---|
| 18092000 | Austria | A | |
| AT20000001809 | – | – | – |
Members9
| Document | Office | Kind | |
|---|---|---|---|
| WO0233985A2 | World Intellectual Property Organization (WIPO) | A2 | |
| AU1023402A | Australia | A | |
| WO0233985A3 | World Intellectual Property Organization (WIPO) | A3 | |
| WO0233985A8 | World Intellectual Property Organization (WIPO) | A8 | |
| ATA18092000A | Austria | A | |
| EP1327341A2 | European Patent Office (EPO) | A2 | |
| AT411312BThis record | Austria | B | |
| US2004029598A1 | United States of America | A1 | |
| US7243152B2 | United States of America | B2 |
2 legal events, as the office reported them to INPADOC
Over the term
Point at a mark for the eventEvents
| Event | Code | |
|---|---|---|
| Lapse because of not paying annual feesLapsedMM01 | MM01 | |
| Change in the person of patent ownerEIH | EIH |
Numbers
- Publication, DOCDB
- 411312
- Publication, EPODOC
- AT411312B
- Application
- 180900
- Application, DOCDB
- 18092000
- Application, EPODOC
- AT20000001809
Titles2
- German
- VERFAHREN ZUM ÜBERMITTELN VON KURZNACHRICHTEN (SMS) ZWISCHEN RECHNERN IM INTERNET
- English
- METHOD FOR TRANSMITTING BRIEFS (SMS) BETWEEN COMPUTERS OF THE INTERNET
Classification
- CPC, 7
- H04W4/14
- H04L29/12584
- H04L29/12896
- H04L51/066
- H04L61/2596
- H04L61/605
- H04W92/24
- IPC, 3
- H04L12 58
- H04W4 14
- H04W92 24
