Data processing: database and file management or data structures – Database design – Data structure types
Reexamination Certificate
2000-08-08
2002-09-17
Luu, Le Hien (Department: 2152)
Data processing: database and file management or data structures
Database design
Data structure types
C709S246000
Reexamination Certificate
active
06453329
ABSTRACT:
FIELD OF THE INVENTION
The present invention relates to computer programming and data storage and transmission methods, as well as to user interface methods.
BACKGROUND OF THE INVENTION
A. General Background of Problem and Overview of Present Solution
Handheld computers (also known as “palms” or “palmtops” are increasing in popularity. They are small, light, and can do many desired tasks without the user having to carry, boot-up, charge, etc. a laptop of other computer-type alternative.
A serious limitation of all palmtops relates to their capacity to store information. Palmtops lack hard drives, and must store whatever information is to be stored in hardware memory. Memory can be expanded only to a finite degree without sacrificing the very size and weight characteristics for which palmtops were designed, and nothing resembling hard drives, as such, is likely to be found in palmtops in the foreseeable future.
The only material way in which the capabilities for palmtops to manage larger volumes of information in the foreseeable future is through manipulation and management of the information itself, not through changes in the architecture of the palmtops.
The present invention presents a programming and data management methodology which greatly advances the capacity of a palmtop to retrieve and process information to a magnitude far beyond any comparable quantitative level as might be achieved through use of prior art data management methods, or through reasonable changes in palmtop construction.
As will be discussed below in considerable detail, properly allocating data gathering and data processing and interpretation tasks between a palmtop and a central computing unit increases a palmtop's capacity to prompt a user in providing, and then retrieve and store information for later processing in volumes far in excess of that possible with a palmtop's present capabilities while using present art data management and programming regimens.
B. Present State of the Art
The current state-of-the-art for remote user-interface generation and reporting is the hypertext markup language or “HTML”. This system differs in lacking the data distillation aspect. This weakness is manifested in several ways:
1) When the script is transferred to the remote computer, the entire script is transferred, placing a greater burden on the bandwidth and storage requirements of the remote system.
2) The remote computer must deal with the original HTML document, which requires it to parse and process enormous amounts of data irrelevant to the purpose of user interface generation.
3) When a data record or “form” is returned from the remote site, field identifiers are attached to each field individually, vastly increasing the bandwidth requirement of the interaction. In the present system, data can be identified by it's position within a highly compacted data record, eliminating the need to transfer the id tags.
4) HTML does not provide a platform-independent binary representation of the user interface. This requires extensive parsing functions to be provided by the system used to display the interface. The present distillation process can produce, as one aspect of the document, a binary representation that can be used on any computer.
5) The automatic generation of a hierarchical representation when distilling the script for the user interface process eliminates the “infinite maze” problem found in conventional hypertext systems, where the “forward/back” paradigm commonly used does not give the user a clear mental image of the organization of the document.
Another language to be discussed in the data management realm is XML (extensible markup language). XML allows the development of custom tags, but does not contain the concept of distillation/expansion contained in the present invention. In fact, XML could be used as the underlying scripting language in a document distillation system. XML also differs conceptually in that it provides a document TYPE definition rather than a document INSTANCE definition. In other words, XML document processors refer to a template that describes in general terms the meaning of custom tags in the language, while a processor that operates on one of the distilled data records employed in the present methodology may also refer to the original document itself, which provides much more flexible and powerful processing capabilities, as well as the extreme data density allowed by the distillation process.
Conventional data compression techniques fall into two classes, “lossless” and “lossy”. An example of a lossy mechanism is that employed by conventional JPEG image files on the internet. Compression ratios in the range 50 or 100 to 1 are common, but at the expense of imperfect reconstruction of the original image. This is considered an acceptable tradeoff given the desire for rapid downloading of images.
In transferring data such as text, or selections from checkboxes on a user interface, clearly lossless compression is necessary. Lossless compression algorithms such as Lempel-Ziv-Welch (LZW) compression or Huffman encoding typically produce compression ratios on the order of two-to-one, depending on the type of data.
Consider a hypothetical example of a survey form consisting of 1000 checkboxes each with a twelve-character idtag as required by a conventional html system (the number twelve is an arbitrary but conservative estimate of the size of a typical field idtag, most programmers use “symbols” this large or larger). The data required for a single record by the conventional system would be at least (assuming no other formatting overhead and that the state of each checkbox is transmitted as a single byte of data):
1000*12+1000*1=13000 bytes.
According to the present methodology, the data required is 4 bytes for the tag required to identify the original script, plus 1 bit per checkbox:
4+1000/8=129 bytes.
This yields an effective compression ratio of:
13000/129=100.77
Note that conventional compression schemes may be applied “on top of” the data representations employed by the subject methodology, thereby resulting in further reductions.
Concerning external data representation, computer platforms differ in their binary format for representing data. For example, in many palmtop computers integers are stored using most-significant-byte-first format, whereas on standard PC platforms integers are stored in a least-significant-byte first format. The byte ordering must be reversed for data generated on one platform before it may be utilized on computers of the other platform.
In conventional systems such as the “remote procedure call” (RPC) system and the “sockets” system, which move data between different computer platforms, the process involves two stages of data translation into an intermediate “external” data representation, with the associated overhead. This intermediate representation may be binary or text-based, but always requires two translation layers.
According to the present invention, data is stored in the native format of the “low powered” system and is transformed only at the time of use. There is no wasted format translation, and no translation at all is required of the less capable platform.
Consider the following comparison between conventional inter-platform exchange and data exchange in accordance with the present invention:
Conventional Inter-platform Exchange.
Data entered on mobile system in native format
All data translated to “portable” format
Data sent to host computer
All data translated to host format
Some data accessed and used by host
The Current Invention's Inter-platform Exchange.
Data entered on mobile system in native format
Data sent to host system.
Data translated to host format only as required.
SUMMARY OF THE INVENTION
In what follows, note that the present techniques are not specific to the script syntax given as examples. In principle the present distillation mechanisms could be applied to industry-standard HTML, XML, or scripts based on other commonly used languages.
The methodologies of the prese
Henry David G.
Luu Le Hien
LandOfFree
Method for translating distilled filed for handling of large... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Method for translating distilled filed for handling of large..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Method for translating distilled filed for handling of large... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2882732