||||||||||||l|||||||||||||||||||||||||||||
`
` ||||||||||||||||||||||||||||||||
`
`USUUG45332931
`
`United States Patent
`(12)
`(10) Patent 1%.:
`US 6,453,329 B1
`
`Dodgen
`(45) Date of Patent:
`Sep. 17, 2002
`
`(54) METHOD FOR TRANSIATING DIS'I‘ILLED
`FILED FOR HANDLING OF LARGE DATA
`FILES AND PROGRAMS BY COMPUTING
`DEVICES WITH LIMITED PROCESSING
`CAPABILITY
`
`* 1012001 Nguyen at all.
`6304.915 Bl
`3 cited b
`examiner
`
`y
`Primary barometer—Le l-lien Luu
`(74) Attorney, Agent, or Firm—David G. Henry
`
`109121?
`
`(76)
`
`*
`
`(
`
`Inventor: Stephen image-n, 6824 Viking Dr.,
`Waco, IX (U5) 76710
`.
`.
`.
`1
`.
`.
`S‘"?“‘.f“_f“:3f allsilaimfi‘. weir-m [1“ ”3;:
`5:11;? Ll’fitlxlm: “18.; :(Juste
`uni er ‘ ‘
`'
`' "
`‘
`(i) )y
`ays.
`
`.
`_
`) Noncc'
`
`(31) APPI- bio-10916345423
`(22
`Filed:
`Aug. 3 2000
`’
`
`G061“ 17121; GOGF 15116
`Int. Cl.7
`(SI)
`
`7071516; 7091246
`(52) US. Cl.
`7"09t217, 246.
`(58) Field of Search
`7091247, 328; 379006.03; 3701465; 7071516
`
`(56)
`
`References Cited
`U.S. PATENT DOCUMENTS
`
`5,790,800 A "'
`0,041,365 A *
`6,013,174 A “
`
`8119.08 Holmes
`312000 Kleinerman
`6120010 Montgomerie el al.
`
`370.1406
`100.1328
`3791106113
`
`ABSTRACT
`(57)
`The technology of the present invention allows the creation
`of a single master document, called a script,
`to serve
`multiple functions by defining a set of data fields as well as
`a hierarchy of organization in terms ol‘loken-valuc pairs. By
`applying, a “distillation" process the content of the script
`may be optimized, efl‘ectively compressing the script
`for
`various purposes such as user interface generation, data
`processing, or data transmission. The size of a set of data
`records, for example, may be greatly reduced by separating
`the content of the data from the meaning, permitting a
`computer with limited resources such as a hand—held unit to
`transmit a very large amount of data in a small data record
`along with a "meaning token". The distilled data package
`may then be expanded by the receiving unit using the
`“meaning token" in the package. which contains the instruc-
`tions for the expansion process. Additionally,
`the script
`allows automatic creation of complex user interfaces and
`database storage without human intervention.
`
`4 Claims, 1 Drawing Sheet
`
`
`
`mm
`
`Created Uslng Text
`Edit»! or Authonng
`Tools
`
`t
`
`47—.
`Swill Ardlive
`A desktop summer, or Web
`Database. stores the oomph:
`original scripts inflamed by
`“meaning tag" or "scrlpt key".
`
`13D1'71_Jl_[
`
`
`
`
`
`
`
`Dull humour
`
`Interprets Distilled Dam Rmds
`in Terms of Script Rmvurad from
`Mitre
`
`
`
`
`
`UECIDEULJULJLLI
`
`4
`
`Wireless or Other data
`link, may be very-low-
`bandwidth
`
`4:
`Primer, or Blaine“ or Industrial
`Process
`
`
`RPX-1011
`RPX-1011
`Page 1 of 11
`Page 1 of 11
`
`

`

`US. Patent
`
`Sep.17,2002
`
`US 6,453,329 B1
`
`Origin-i sin-rm
`
`Created Using Text
`Editor or Authoring
`
`Tools
`
`———D
`
`Distillation
`
`
`
` Script Archive
`
`A desktop computer, or Web
`Database, stores the complete
`original scripts indexed by
`“meaning tag" or “script key”.
`
`DEDUDUD
`
`
`
`
`
`
`Palmtop Computer
`
`HierarchicalUser
`
`Interface
`For Rap“ Now of
`[up Amour: ornate
`
`$
`
`Distilled Data Records
`
`E! El CI [I [I [3 E! El [I E} El
`
`
`
`
`
`i
`
`' '—‘—
`
`e?
`Dblilloflon
`$
`
`I
`
`Processing Distillation
`
`Script Optimiud
`
`for Required Data
`
`Processing.
`
`f
`Meaning Tag Sent
`to iArchive For
`Script Retrieval
`
`
`
`
`
`Dita Processor
`
`é
`
`Interprets Distilled Data Records
`in Terms of Script Recovered from
`Archive
`
`
`q...-
`
`_
`Wireless 01' Other data
`link, may be very-low-
`bandwidth
`
`Printer, or Business or Industrial
`Process
`
`RPX-1011
`R PX-‘I 01 1
`Page 2 of 11
`Page 2 of 11
`
`

`

`US 6,453,329 B1
`
`1
`METHOD FOR TRANSIA'I‘ING DISTILLED
`FILED FOR HANDLING OF LARGE DATA
`FILES AND PROGRAMS BY COMPUTING
`DEVICES WITH LIMITED PROCESSING
`CAPABILITY
`
`FIELD OF THE INVEN'I’ION
`
`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
`
`it]
`
`IS
`
`Handheld computers (also known as “palms" or “palmv
`tops” 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 alter-
`native.
`
`A serious limitation of all palmtops relates to their capac-
`ity 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 sine 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 archi~
`lecture of the palmtops.
`The present invention presents a programming and data
`management methodology which greatly advances the
`capacity ofa 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 con-
`struction.
`
`As will be discussed below in considerable detail, prop-
`erly allocating data gathering and data processing and inter
`pretation 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 gen—
`eration 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:
`I) 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,
`lield identifiers are attached to each field
`individually, vastly increasing the bandwidth requirement of
`
`an
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`2
`the interaction. In the present system, data can be identilied
`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 represen-
`tation that can be used on any computer.
`5) The automatic generation ofa hierarchical representa-
`tion when distilling the script for the user interface process
`eliminates the "infinite maze" problem found in conven—
`tional hypertext systems. where the "forwardfback" para-
`digm 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 distillationrexpansion contained in the present
`invention. In fact, XML could be used as the underlying
`scripting language in a document distillation system. XML
`also dilfers conceptually in that
`it provides a document
`TYPE definition rather than a document INSTANCE defi—
`nition. 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 encod-
`ing typically produce compression ratios on the order of
`two—tonne, depending on the type of data.
`Consider a hypothetical example of a survey form con-
`sisting 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):
`ICIUO‘IEHUII'UHflJUCIO bytes.
`
`According to the present methodology, the data required
`is 4 bytes for the tag required to identify the original script,
`plus i hit per checkbox:
`4+] UDUI3=129 bytes.
`
`This yields an elfective compression ratio of:
`13mm129=1nuar
`
`Note that conventional compression schemes may be
`applied “on top oi" the data representations employed by the
`subject methodology. thereby resulting in further reductions.
`
`RPX-1011
`RPX-1011
`Page 3 of 11
`Page 3 of 11
`
`

`

`US 6,453,329 B1
`
`3
`Concerning external data representation, computer plat-
`forms differ in their binary l‘onnat for representing data. For
`example,
`in many palmtop computers integers are stored
`using most—significant—byte—first format, whereas on stan—
`dard 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" (RFC) system and the “sockets" system, which move
`data between dilferent 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 ptiWered” system and is trans-
`formed 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 lnter—platfon‘n 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 present invention solve several
`problems associated with software development in general
`and mobile computing in particular:
`Optimal use of limited bandwidth. The very-efficient data
`storage strategies of the present
`invention methodologies
`allow handheld computers with low data rate connections to
`transfer huge amounts of data. Today a central problem in
`practical computer usage is the ability to transfer informa-
`tion between networked computers. In desktop computers it
`is now common for home computers to have multi-megabit
`data rate connections to the internet through cable modems
`or other so—called “broadband" technologies. Palmtop com~
`puters are severely limited in their communications
`bandwidth, often operating over wireless connections at data
`rates of 9600 bps (bits per second) or even lower. This is a
`serious obstacle to the deployment of palmtop computers in
`remote data gathering applications.
`Traditional data compression techniques cannot achieve
`compression ratios of greater than about two-to-one without
`loss of data. I-Iigher ratios are possible for image data, but
`only in the case where image degradation through imperfect
`reconstruction is acceptable. Such popular image formats as
`"jpeg" use such techniques, but such "lossy" mechanisms
`are not applicable to transmission of binary data records of
`the type required by remote data collection applications.
`
`it]
`
`IS
`
`an
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`4
`Optimal use of limited memory and processing power on
`mobile and hand-held computer platforms. The “distilled"
`data records and documents of the present invention allow
`software applications with unprecedented levels of com—
`plexity to be stored and displayed rapidly on handheld
`computers with extremely limiter] processing power and
`memory.
`By removing information from the script that is irrelevant
`to the user-interface process, the parsing of the script
`is
`simplified on the handheld computer, giving its users opera-
`tional capabilities far in excess of that now possible with
`present day data management and structure, and presently
`otherwise possible only with vastly increased computing
`power. Many of the handheld computers often are entirely
`without the disk storage that is taken for granted on most
`desk top computers. In these devices all data records must be
`stored in small non-volatile memories, which are extremely
`limited in size. While a conventional word processing appli-
`cation may be able to use 3 megabyte of data for a simple
`document, handheld applications have no such luxury.
`By completely separating the "meaning” ot'the data from
`the data itself, one achieves very high “information density",
`making it possible to store large numbers of data records in
`even the limited memory of a diskless handheld computer.
`Enhanced software productivity. 'lhe new document types
`involved in the present invention allow a non-technical user,
`generally a “domain expert" or expert in the subject matter,
`to create the content, data flow, storage elements, and screen
`elements without
`the need for programmer involvement.
`This enables true software development by people with N0
`software backgound, and in fact even those with marginal
`computer literacy skills.
`Enhanced ability to capture expert knowledge and user
`Requirements. The knowledgecapture process is a peren—
`nial block to productivity in the software realm. The pres-
`ently described new document
`types allow the domain
`expert to perform his or her own knowledge capture without
`programmer involvement. Given the script which defines the
`data elements which the content developer wishes to
`capture,
`the present combined distillationt'expansion pro-
`cesses automatically perform user-interface creation. allo-
`cation ol' data storage, and report generation. The domain
`expert is therefore required only to specify the problem, the
`solution is generated automatically.
`The syntax of the scripting language used is not critical to
`the process. An example is given here, which emphasizes a
`plain-English syntax to enhance readability. Such a language
`has in fact been used directly by non-technical users with
`brief training. Simple authoring tools based on the well
`known RAD {rapid application development) paradigm are
`also possible to further simplify script creation.
`Ability to navigate very large amounts of data easily.
`“Information overload” is a serious problem with current
`computing paradigms. The ability of the present documents
`to automatically specify a hierarchical representation, and to
`specify filters which suppress irrelevant information, allow
`a user to navigate an unprecedented quantity of data in an
`extremely fast and eflicient manner.
`This problem of information overload and document
`navigation is particularly severe in the handheld arena,
`where display sizes are very limited. The hierarchy of
`display and filtering capabilities are essential
`to making
`practical the extraordinarily complex applications that are
`and will he required on handheld computers.
`Well-defined separation of client-side and server-side
`workload. In the present system, the different distillations
`
`RPX-1011
`RPX-1011
`Page 4 of 11
`Page 4 of 11
`
`

`

`US 6,453,329 B1
`
`5
`clearly delineate the purposes and responsibilities of differ-
`ent subsystems: The handheld component (the “infom‘talion
`retrieval computer"), who’s advantage is mobility and
`simplicity, is responsible for acqu hing and transmitting data.
`The "host" or “server" component {the “data processing
`computer”), is responsible [or associating data records with
`the original scripts, and for performing processing that is
`beyond the scope of the handheld system.
`In what follows,
`the new document
`type involved in
`practice of the present invention will be a “script”. Ascript
`defines a set of data fields as well as a hierarchy of
`organization. A script consists of token-value pairs. The
`specific tokens used here are not important, and in fact other
`tokens are substituted in some implementations.
`The exact syntax of the script is likewise irrelevant. The
`token=value syntax presented here is only one possible
`implementation.
`Script aspects. A key element of the script is the specifi-
`cation of multiple "aspects” of the problem in a way that can
`be “distilled" so that different users or computer systems
`need only deal with those aspects that concern them, and yet
`the ditIerent aspects may still interact when the results of
`different processes are combined by the expansion appara—
`tus. Described in more detail below are some possible
`aspects, which are among those used in the present inven-
`tion’s experimental implementation:
`The data field aspect
`The representation hierarchy aspect
`The contextual Filter aspect
`The data processing aspect
`The data position aspect
`The field—idtag aspect
`The user-defined aspect
`The constraint aspect
`The page~layout aspect
`Clearly other aspects are possible. The accompanying
`sample script illustrates some possible aspects including the
`ones mentioned here.
`
`The data field aspect. This aspect allows the specilication
`of individual data-entry fields, which may be simple or
`complex and have an associated data type.
`A simple example is a checkbox:
`BEGIN l-‘IELD
`FIELD TYPE=checkbox
`
`LABEL=cardio pulmonary arrest
`END FIELD
`
`This script speci fies that one wishes to create a checkbox and
`to label the checkbox “cardio pulmonary arrest". This is the
`most primitive aspect, which is combined with other script
`aspects to provide the significant benefits of the present
`invention.
`The representation hierarchy aspect. The script delines a
`hierarchy of representation for the data, allowing the build-
`ing of user interfaces using a shallow-tree hierarchy. This is
`done by defining sections and subsections within the script,
`which can then be used by a distillation device to produce a
`navigation hierarchy. One example of a syntax which
`accomplishes this is as follows:
`BEGIN SECI‘ION=(section I name)
`BEGIN SUBSECTION=(subsection 1.1 name)
`BEGIN FIELD
`
`END. FIELD
`END SUBSECTION
`
`5
`
`IE
`
`IS
`
`an
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`6
`BEGIN SUBSECTION=subsection 12 name
`BEGIN FIELD
`
`END FIELD
`END SUBSECTION
`END SECTION
`BEGIN SECTION=(section 2 name)
`
`END SECTION
`For example, in a palm computer implementation developed
`according to the subject invention, the end product allows up
`to 20 script sections with 20 submctions per section. This
`allows a user, with only two pen taps on a mobile computer
`with a very Limited display, to access 400 different subsec—
`tions of a computer application. Each of these subsections
`may contain an arbitrary number of fields which can then be
`found using page-forwardtpage-back commands much like a
`conventional book or multi-page form.
`This hierarchy may be extended by the nesting of fields:
`BEGIN FIELD
`FIELD TYPE=cheekbox
`
`BEGIN FIELD
`FIELD TYPE=popup list
`
`END FIELD
`END FIELD
`
`In this manner, by enabling fields to be contained within
`other lields and only displayed when "triggered" by use of
`the enclosing fields,
`the hierarchy may be extended to
`whatever depth required.
`The contextual filter aspect. To further enable the navi—
`gation of extremely large data sets with very limited com-
`puter resources and limited display sizes, scripts allow the
`definition of “topics”, "detail
`levels”, and other filtering
`mechanisms which can enable the display apparatus to
`selectively limit the display of data fields.
`For example, envision a medical application in which one
`wishes to display certain fields only if the user’s patient is
`suffering from a particular problem. One can then specify
`topics in the script .
`.
`.
`BEGIN TOPIC DEFINITIONS
`BEGIN TOPIC
`TOPIC lDThGuMaior Burn
`END TOPIC
`BEGIN TOPIC
`TOPIC IDTAG=Chest Pain
`END TOPIC
`END TOPIC DEFINITIONS
`
`One can then specify that the following field is only relevant
`for the “Burn" topic:
`BEGIN FIELD
`FIELD TYPE=checkbox
`LABEL=smoke inhalation
`TOPIC=Major Burn
`END FIELD
`Now the distillation apparatus may, at the time the field is
`presented, choose to display or not display each field based
`on the current context. The value of this filtering mechanism
`is greatly enhanced by the distillation process, which creates
`a new version of the script in which the enable status of each
`field is encoded in a single bit [or each topic. This distilled
`version is delivered to the user—interface process, which thus
`is not required to perform the computationally-intensive
`parsing operations that would be required by prior-art script
`processing systems in order to determine the run-time font]
`of the user interface.
`
`RPX-1011
`RPX-1011
`Page 5 of 11
`Page 5 of 11
`
`

`

`US 6,453,329 B1
`
`7
`Other contextual filters are possible and have been imple-
`mented. For example. the following field is only relevant for
`females in a certain age range. Note the SEX andAGE filters
`which are now included in the field .
`.
`.
`BEGIN FIELD
`
`FIELD TYPE-yesno
`LABEL=home pregnancy test used
`SEX=female
`MIN AGE YEARS=10
`MAX AGE. YEARS-=55
`END FIELD
`
`It]
`
`The data processing aspect. Data records produced using
`the script will in general be used for some type of analysis
`or reporting. Two examples are a printing process and an
`invoice-generation process.
`Suppose, for example, we have an automatic printing
`process which composes text based on the labels within a
`field. Suppose further that we have a "yeslno" control type
`where we wish to print a specific formal in the "no" case. We '
`might
`then use a "print control" aspect
`to override the
`default printing logic:
`BEGIN FIELD
`
`IS
`
`FIELD TYPE=yesno
`LABEL=remembers traumatic event
`I’RIN'I'CON IFNO PRINT=does not remember
`traumatic event
`END FIELD
`
`Consider a second example where an invoice generation
`process is used to automatically produce items based on the
`content of a distilled data record. To the user interface, this
`process is irrelevant, while to the billing process it is crucial.
`In the following field, we have used a BILLING CODE
`directive as an example of a data—processing aspect .
`.
`.
`BEGIN FIELD
`
`FIELD TYPE=yesno
`LABEbPatient defibrillated
`BILLING CODE=12345
`END FIELD
`
`Clearly other such processing aspects are possible.
`The data Position aspect. This aspect of the data is implicit
`within the script and depends on the simple observation that
`each field has a specific position within the overall script.
`The fields can simply be numbered from 1 to “N” where “N“
`is the total number of fields within the script. While seem-
`ingly trivial, this fact implies the ability to obtain the very
`efficient data storage described below.
`The field-idtag aspect. This aspect allows any field in the
`system to be “tagged” with a symbol, which may be used to
`identify the field unambiguously from another field or to
`provide special processing for that
`field. For example,
`suppose that We wish to present the same data field in two
`different locations in the same user interface. The first field
`in the following example creates a checkbox. The second
`takes advantage of the field idtag aspect to create a duplicate
`field, which will be slaved to the same database information
`and present the same label. Note also that other aspects of
`the field, such as the conditions under which it will be
`enabled, may be over—ridden by the duplicate field:
`BEGIN FIELD
`FIELD 'I'YPE=checkbox
`LABEL-normal I-IEENT exam
`PRINTCON USERDEFINED
`FIELD IDTAG-normal HEENT exam
`
`an
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`END FIELD
`
`BEGIN FIELD
`DUI’LICAI'E=normal HEEN’I‘ exam
`DEFAULT DI.EVEL2
`END FIELD
`Another use of the field idtag is to provide customized or
`non-standard processing for an individual field. One such
`example is outlined in the section discussing the “user-
`defined" aspect.
`Note that field idtags may either be generated by hand. or
`be automatically generated by a script processing stage.
`Automated authoring tools may be used to guarantee that the
`idtags are unique and persistent across script revisions, so
`that custom processing will not be lost or disrupted when the
`script is edited.
`In conventional script and computer language processing,
`the idtag concept is embodied as a "symbol table“. These are
`usually based on hashing or tree algorithms which require
`operating system support for large dynamic memory struc-
`tures and look-up algorithms. In the present implementation,
`when the distillation process generates a version of the script
`for use in data storage or user interface generation, We may
`use the data position aspect to replace the idtag with a simple
`numeric index, which aIIDWS inter-field references to be no
`more complex than array references. This makes idtags
`practical in a resource-constrained system such as a hand-
`held computer.
`The user-defined aspect.
`Consider the following field definition:
`BEGIN FIELD
`FIELD TYPE=checkbox
`LABEL=normal HEENT exam
`PRINTCON USERDEFINED
`FIELD lD'l‘AG=normal HEENT exam
`END FIELD
`
`Note the “PRINTCON USERDEFINED“ tag. This
`informs the system that when this. data is printed, the text to
`be printed is to be taken from a file generated by the user and
`associated with this field using the FIELD ID’I'AG. In the
`case where different users desire cliflerent custom
`processing. a separate file of user definitions is associated
`with every handheld device, and within that file field idtags
`are used to identify the fields to which custom processing
`applies. to this way the processing of the script may be
`completely customized on a per-Lister basis. The distilled data
`record need only be transmitted with some identifier specin
`fying the originator, and the processing modified accord-
`ingly by the server—based data processing.
`The constraint aspect. It is useful in many user interfaces
`to build in “constraints" on the data that may be entered,
`such as ranges on the data or inter~field constraints on data
`items that are mutually exclusive. An example is a set of
`checkboxes which are mutually exclusive, conventionally
`known as “radio buttons”. This constraint may be applied by
`a "group identifier syntax" such as the following:
`CREATE AUTO GROUP ID
`BEGIN FIELD
`FIELD ’l'Yl’E=eheckbox
`LABEL=Patient arrived via ambulance.
`GROUP ID=auto
`END FIELD
`BEGIN FIELD
`
`RPX-1011
`RPX-1011
`Page 6 of 11
`Page 6 of 11
`
`

`

`5
`
`It]
`
`15
`
`Clearly other such constraints are possible.
`The page layout aspect. In general a distillation apparatus
`can produce a user interface using only the hierarchy and
`field definitions. However, one aspect of the script allows us
`to override this automatic mechanism with tokens that give
`explicit "hints” or "directives“ to the distillation apparatus.
`For example. if we wish two lields to appear side-by-side on
`the display where the automatic user interface generation
`would normally place the second field on a new line, we
`might write as follows {note the SUPPRESS LINEFEED
`directive)
`BEGIN FIELD
`FIELD 'IYPE=checkbox
`I A]? EL: Fever
`END FIELD
`BEGIN FIELD
`FIELD TYPE-checkbox
`LABEL=Sore Throat
`SUPPRESS LINEFEED
`END FIELD
`Clearly other such directives are possible to selectively _
`override aspects of the automatic generation of user inter-
`faces.
`
`BRIEF DESCRIPTION OF THE DRAWING
`
`FIG. 1 is a flowchart showing how the system operates in
`practice. Initially the entire script is created using a text
`editor, or by means of the simplified authoring tools which
`do not require a high degree of programming expertise. 'Ihe
`desktop computer or Web Database stores the entire script,
`indexing it by "meaning tag" or "script key". In the drawing,
`two different branches of distillation are shown. One, the
`palmtop distillation, optimizes the script for display, and
`contains the "meaning tag" and pre-computed user-interface
`logic. In the other branch, the distillation process optimizes
`the script for data processing according to the requirements
`of the situation.
`
`During the palmtop distillation process, a hierarchical
`user interface has been created, allowing rapid navigation of
`large amounts of data and thus, a very efficient data entry
`process by the user. After the data have been entered, they
`are transmitted airing with the “meaning key" back to the
`data processor. This transmission, because of the minimal
`size of the packet, does not require a high bandwidth data
`link.
`
`Upon receiving the data and the “meaning key" (or
`“translation means” in the claims) the processor sends the
`key to the storage archive to retrieve the script and optimize
`it for data processing. The data may then be used for any or
`all of the usual activities; printed or stored patient records,
`billing procedures, or any other desired purpose.
`
`DETAILED DESCRIPTION OF THE
`INVENTION
`
`The present invention relates to enabling very complex
`computer application uses, data gathering, data processing,
`and data transmission, particularly in the context of using
`handheld or “palmtop" computers to gather the initial infor—
`mation for
`transmission to remote, higher-pUWered
`computers, which processes are not possible through prac-
`tice in the present art
`to the same degree as is possible
`though practice of the present invention.
`
`3o
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`9
`LABEL=Patient was brought in by parents
`GROUP lD=auto
`END FIELD
`
`US 6,453,329 B1
`
`10
`the
`invention depends on, as applicable,
`The present
`creation, use, or carrying out of the following components or
`steps:
`A “script" which is a machinenreadablc document.
`An apparatus for processing this script or “distilling” the
`meaning of the script into other representations which
`are reduced in size and optimized for various purposes,
`such as user interface generation, data processing, or
`data transmission.
`
`"Distilled” representations of the script which are in
`general very greatly reduced in size or optimized for
`alternative purposes, which contain "meaning tags“ for
`re-expansion of the distilled representations.
`Data records which are stored in an efficient manner by
`completely separating the meaning ofthe data from the
`data itself.
`
`An apparatus for regeneration or "expansion” of distilled
`representations for purposes of user-interface genera-
`tion.
`
`An apparatus for regeneration or "expansion" of distilled
`representations for purposes of data processing.
`Authoring tools to simplify the process of script creation.
`The present invention represents a new technology which
`admits the use ol‘ a single document, called a script, to serve
`many functions which were previously done by hand or by
`a number of separate tools. This process is called “distilla-
`tion" for present purposes. Also part of the present meth-
`odology are new types of data records which carry internal
`information allowing great flexibility and efliciency in their
`use.
`
`Some of the characteristics of this technology are:
`Very eflicient use ofthe resources ol‘handheld computers.
`Extremely spacecfiectivc data storage by complete sepa—
`ration of the “meaning" ofthe data from the data itself.
`Self-describing data records which allow movement of
`data between machines having dilferent internal dat