Method and apparatus for storing data as objects, constructing customized data retrieval and data processing requests, and performing householding queries

• US 6,708,166 B1
• Filed: 05/11/2000
• Issued: 03/16/2004
• Est. Priority Date: 05/11/1999
• Status: Expired due to Fees

• Current Assignee: Norbert Technologies LLC
• Original Assignee: Norbert Technologies LLC
• Inventors: Flynn, Richard, Dysart, Andrew, Hom, Norbert, Moy, Kan, OʼConnor, Paraic, Barron, Kevin, Craig, Byran, Zwolak, Michael
• Primary Examiner(s): Homere, Jean R.
• Assistant Examiner(s): Wong, Leslie
• Application Number:
  US09/568,502
• Time in Patent Office: 1,405 Days
• Field of Search: 707/2, 707/3, 707/5, 707/6, 707/202, 707/4, 707/101, 707/102, 707/1, 707/104.1, 700/29, 700/108, 382/190, 382/198
• US Class Current: 707/765
• CPC Class Codes: G06F 16/289 Object oriented databases
• CPC Class Codes: G06F 16/951 Indexing; Web crawling techniques
• CPC Class Codes: Y10S 707/99933 Query processing, i.e. searching
• CPC Class Codes: Y10S 707/99935 Query augmenting and refining, e.g. inexact access
• CPC Class Codes: Y10S 707/99936 Pattern matching access
• CPC Class Codes: Y10S 707/99943 Generating database or data structure, e.g. via user interface
• CPC Class Codes: Y10S 707/99945 Object-oriented database structure processing

Abstract

Compressed data objects are stored in a remote data store and are accessible to end users for data retrieval and processing. Descriptive information about data objects and processing logic is displayed and made available for viewing and access by end users having a client application which manipulates the descriptive information to create a customized data retrieval and processing request. The request can be submitted to several data stores in succession for automated data retrieval and processing without jeopardizing request security. The final request is submitted to the appropriate data store(s) and/or vendor(s) for automated processing in accordance with the customized instructions, and the data result set is returned in a format specified by the end user. Householding capability and security features are available. End users can customize their householding parameters, including end user specifications to improve flexibility, speed, and efficiency of the householding process.

Claims

1. A method of using execution tables, wherein a structural search is performed comprising:

analyzing all search patterns generated for a given input pattern and identifying the output table symbol for which an exact match is required most frequently in the same search pattern position;

prioritizing the search patterns identified in the previous step to eliminate at the beginning of the process the largest number of records that will not match the parsing table and continuing to prioritize search patterns using the same process until all search patterns are in order;

accessing input data according to the highest priority search pattern and determining whether the input data and parsing table, position determined by the highest priority search parameter, matches;

eliminating subsequent searches according to whether a match in the accessing step occurred and whether such a match is required in subsequent searches;

repeating accessing and eliminating steps until the input data matches the parsing table in relevant positions or until the search fails;

moving the matched data into a virtual memory table to retrieve input data, position determined by position of next search parameter, without losing the location of the matched data for the previous position, and

storing the frequency of matches of input data and parsing table data, position determined by search parameter, in a virtual memory table.

2. The method of using execution tables according to claim 1, wherein a second execution table performs the input data matching search comprising:

analyzing only the search patterns from the virtual memory table to match data input to the parsing table(s); and

matching the input data to the parsing table in order of the position and end user preferences, starting with the record fields that require an exact match and proceeding to fields in which the end user specified some tolerance data in data.

3. The method according to claim 2 wherein in the event that more than one field requires a match, the second execution table will examine the primary position first, followed by the secondary position.

4. The method of using execution tables according to claim 1 wherein there are two or more positions selected by an end user, comprising:

comparing the frequency of the primary position matches verses the frequency of secondary position matches; and

beginning with the position value that matched the fewest records, comparing the primary position value to the primary position and the secondary position value to the secondary position to assure both values match for records moved into virtual memory by the execution tables.

5. The method of using execution tables according to claim 1, wherein after the first two positions are matched, any other required matching is performed only on the remaining records that were moved into virtual memory.

6. The method of using execution tables according to claim 1, wherein a third execution table matches the input data to the parsing table for those fields that the end user selected as allowing for error tolerance, comprising:

accessing the data input for the first search pattern position in the first remaining search pattern for which deviation is permissible;

retrieving the data value for this search pattern position;

matching the data value to the parsing table; and

applying the fault tolerance logic as defined by the end user;

wherein a final, customized parsing search will contain;

(i) a complete and standardized set of information matching the key parameters; and

(ii) a complete and standardized set of information with the fault tolerance as defined by end user.