davidwr's Journal: IP over SMS - inefficent internet that may be the best you can sometimes

[Note: This is NOT a submission for the "front page" so if it shows up in Firehose, please down-vote it. Comments are welcome. The purpose of making this public is to get people to start thinking about it for areas that are under-served by wireless internet and to make it clear that the general idea is too obvious to be patent-able, or at least it would be for any reasonable definition of "obvious." I'm not a lawyer and I'm very well aware that in patent law, the definition of "obvious" is sometimes neither obvious nor reasonable.]

IP over SMS

IP over SMS should be relatively trivial to implement.

Simply take data from higher in the stack, prepend headers and footers, and divide it into packets of 140 bytes packets, leaving room for per-packet headers and footers as well. The SMS source and data destination are transmitted with each packet seperately so they do not need to be in the data stream.

The following is just one of many obvious examples of how it can be done, it may not be the best implementation.
Other implementations may include things like encryption, using keys that were previously exchanged using a reliable method, such as by photographing a bar code that contains the other endpoint's public key, then sending the other party a one-time number encrypted with that key.

Example: incoming data from an IP layer above:

Note: For each SMS message sent, the SMS external header would contain the same information as any other SMS packet, including the source number and destination number. From the point of view of the SMS network the data below, including the SMS internal header in each SMS message, is just another text message or series of text messages.

IP header: From: 1.1.1.1 To: 2.2.2.2 Data: Forscore and seven years ago ... November 19, 1863

Divide this into several packets:

SMS internal header:
MAXMSGS, maximum messages at one time: variable length, 0 (1 bit) or starts with 1 and ends with 0: Take this number, add 2, and multiply by 128. 0=(0+2) * 128 = 256 simultaneous messages between SMS points A and B, 10 = (2+2)*128=512, 110=(6+2)*128=1024, etc.
Msg number (variable length, 1+ preceeding, with rollover). This allows up to MAXMSGS different communications to be going on between point A and point B at the same time.
Packet count within a message: (8, 16, 24, etc. bits) up to 6 bits followed by 00, OR leads with 0 followed by 6 bits followed by 1 followed by the same as many times as needed to hold packet count within message.
Number of packets left in message: same format as packet count.
Packet size 1 bit (0) OR 12 bits: 0 if the this SMS packet is "full," i.e. all 140 bytes are used, otherwise 1 followed by the number of BITS in this packet, including headers.
Data:
Remaining bits in SMS packet are devoted to data. Unused bits are not sent.

When this is practical:
Any time high-latency communication can be tolerated and a more efficient network is not available, this is practical.
This would be common in parts of the world where reliable internet is spotty or much more expensive than SMS, or in disaster situations where SMS may be much more reliable than other forms of Internet service.
However, practical does not imply useful.

Examples of when this is useful, given that it is practical in a given situation:

Group SMS, picture SMS, and other messages typically delivered over methods other than SMS (e.g. Apple's iMessages).
Email.
"Pushed" data such as weather, traffic, stock reports, banking alerts.
Exchanging authentication tokens or other small amounts of information.
Web browsing with a caching web browsing (compare with HoTMetaL, a circa-1993 caching web browser used for dialup), assuming the user is willing to put up with "page loading, check back in 15 minutes" messages, and assuming web pages that target this audience are designed to be used in an "ultra lightweight" mode.

Typical communication will be over UDP rather than TCP, with applications that are "high latency aware" managing things such as re-sending of data, etc.
The UDP layer or the application layer may manage encryption.

Patentability:

Most methods which is not unnecessarily convoluted would be obvious to anyone skilled in the art, and therefore it should not be patentable.
There may be some patent potential for some small efficiencies, but the difference between the "best engineered" implementation and a slightly-less efficient obvious one would be minimal and the benefit to using a non-patent-encumbered implementation far exceeds any small technical benefit of an optimized implementation in most cases.

A test - but not the only test - of obviousness would be to present the problem of "design an efficient method of solving the problem" to a large number of teams (more than 1000) of people trained in the field but who come from otherwise different backgrounds, and see if any of the solutions they arrived at are anywhere close to the solution you are seeking a patent on. If they are, it's probably obvious. The more teams that come up with a solution similar to yours, the more obvious it likely is. Include solutions the teams rejected for whatever reason, or solutions that they would obviously have found but for the fact that they rejected a particular line of inquiry because they thought it was a dead end or would lead to an inferior result.