Data processing: database and file management or data structures – Database design – Data structure types
Reexamination Certificate
1999-08-13
2003-02-04
Coby, Frantz (Department: 2171)
Data processing: database and file management or data structures
Database design
Data structure types
C707S793000, C707S793000, C707S793000, C707S793000
Reexamination Certificate
active
06516321
ABSTRACT:
STATEMENT REGARDING FEDERALLY SPONSORED RESEARCH OR DEVELOPMENT
Not applicable.
BACKGROUND OF THE INVENTION
The present invention relates to information processors and more particularly to a search system for generating links to a first information set which is referenced in a second information set and to a system which automatically inserts tags into records which can be used by other applications to identify specific types of information within the record.
The computer networking industry is constantly searching for new and improved ways to facilitate communication between network users and to access and manipulate data stored on network databases. To this end one common way to access data stored on a network has been to employ universal resource locators (URLs) common to the Internet. A URL is essentially an address which includes a plurality of fields which together operate as a pointer to information stored at a specific database address on a network. The address fields typically include two general information types including server specifier and specific data information. The server specifier information specifies a server which is linked to a database which includes specific information required. The specific data information provides a key which can be used by a server to determine the precise data required by a URL. For example, a first and typically broadest field for data stored on a hospital database may identify the hospital server (e.g., St. Mary's, Springfield, historical server). A narrower field may include specific data information indicating a specific hospital patient (e.g., a nine digit patient ID number).
When a URL is transmitted, the network routes the URL to the URL specified server. When the server receives the URL, the server parses the URL to identify the specific data information, retrieves the information and then performs some function (e.g., manipulation, providing the information back to the requesting network user, etc.) on the retrieved information.
One problem with URLs is that servers rely heavily on URL fields to identify URL specified data. As networks become more complex and as users and applications require access to relatively more specific data, additional fields are added to URLs and the URL scheme becomes much more complicated. For example, initially a hospital may include only a single server and therefore, once the hospital is specified in a single URL field, the server is known. However, as the hospital system expands and additional servers are added to the hospital system, additional server specifying fields need to be added. As another example, in a primitive system it may be sufficient to access complete ECG records for physician review. However, as a system becomes more complicated it may become desirable to enable access to more specific ECG record data such as heart rate.
Accessing specific data is further complicated when an application requires many small data segments from one or more records. For example, in a physician's report it may be advantageous to link references within the report to specific data stored at addresses linked to the report via the network. For instance, the desired links may be to an image, a heart rate and a diagnosis for a particular patient. In this case, three separate URLs would have to be specified by a user and linked to referencing text in the report, one URL for each of the image, heart rate and diagnosis. While such linking is advantageous, in many cases such linking is never contemplated because of the complexity of the required URL addressing scheme.
Recently another method and tool for accessing/manipulating data within a specific record has been developed which specifies universal “tags” which can be used within a record to earmark specific data types. An exemplary “tagging” language is the extensible markup language (XML). The tags are to be used by processor applications which are familiar with the tags to identify specific information types. Applications which are capable of recognizing tags are referred to hereinafter as “tag enabled” and records which include such tags are likewise referred to as tag enabled. Tags are typically paired including a “begin” tag and an “end” tag identifying the beginning and the end of a specific data type within a corresponding record. For example, in a patient record, a “<patient id>” tag may specify the beginning of a field including a patient ID and a corresponding “</patient id>” tag may specify the end of the patient ID field. Similarly, a “begin image” tag may specify the beginning of an image field while an “end image” tag specifies the end of the image field. Using a URL scheme a record can be retrieved by a tag enabled application. Thereafter, the application parses the record to identify specific data types required by the application and uses the identified data types.
Thus, tags and tag enabled applications can be combined with URLs to overcome some of the complexity associated with URL data specification within a specific record. Nevertheless, linking record segments and references together via URLs and tags requires knowledge about URL and operation and formats. For example, to link a reference in a first record to a segment in a second record, first the second record address has to be specified and the segment tags have to be specified. Then, the URL address of the second record and the tags of the record segment to be linked have to be linked to the reference in the first record. Because many record producers (e.g., physicians) do not have required URL and tag knowledge, despite the advantages associated with such linking, most such linking is foregone.
U.S. patent application Ser. No. 09/326,177 (hereinafter “the '177 reference”) entitled “Method for Specifying Enterprise-Wide Database Address Format” which was filed by the present inventor on Jun. 4, 1999 describes a system whereby URLs are automatically generated for data within a record thereby streamlining the process of linking references in one record to data stored at other network locations. To this end information in a first record is searched for data references (DRs) which reference other records. When a DR is identified, other record information is sought for constructing a URL address to the record associated with the data reference. After a URL corresponding to the record associated with the data reference is constructed, a link to the referenced record is formed. Exemplary links include hyperlinks, importation of the referenced record information into the referencing first record or electronic document, etc. Both real time and batch processing are contemplated.
A wrinkle of complexity is added to the referencing scheme whereby modifier references (MRs) may be used to further specify a specific record or record segment when a DR is identified. In this case, when a DR is identified, the record is further examined to identify modifier references (MRs) which identify a specific segment of a record which is associated with the data reference. When an MR is located, additional information is sought within the record for building an address to the record or record segment referenced by the DR/MR combination. Once again, a link is created between the referencing record and the referenced record or record segment.
Unfortunately, the '177 reference system also has several shortcomings in the area of html linking. The '177 reference recognizes that various search rules can be employed by a processor assigned the task of constructing referenced record addresses. Nevertheless, in the interest of simplifying explanation of the novel concepts in the '177 reference, the '177 reference assumes a simple searching rule wherein only the term immediately preceding a DR is examined to locate an MR. For example, where an ECG DR is located, only the term preceding the ECG term is sought for MRs (e.g., admission, post-op, etc.).
While such a simple MR search rule is advantageous for explanation purposes, it has been recognized that such a simp
Coby Frantz
Quarles & Brady LLP
LandOfFree
Method for database address specification 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 database address specification, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Method for database address specification will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3178254