A data storage system (12) may include a plurality of source systems (14) and a common database server (16). Each source system (14) may include a source database (20), an extraction engine (24) and a transformation engine(26). At least two of the source systems (14) may have source databases (20) that store data in disparate formats and file structures. The extraction engine (24) may extract data from the source database (20). The transformation engine (26) may transform data extracted from the source database (20) into a common format and file structure. The common database server (16) may include a common database (32), a common database controller (34) and a load engine (48). The common database controller (34) may receive data transformed by the transformation engine (26). The load engine (48) may load the data received by the common database controller (34) into the common database (32).
|
14. A method of storing data from a plurality of source databases, comprising the steps of:
extracting data from a first source database; transforming the data of the first source database into a common format and a common file structure; loading the transformed data of the first source database into a common database; extracting data from a second source database, the first and second source databases storing data in disparate formats; transforming the data of the second source database into the common format and the common file structure; and loading the transformed data of the second source database into the common database.
1. A distributed data storage system, comprising:
a plurality of source systems, each including: a source database, at least two of the source systems having source databases operable to store data in disparate formats and file structures; an extraction engine operable to extract data from the source database; and a transformation engine operable to transform data extracted from the source database into a common format and a common file structure; and a common database server including: a common database; a common database controller operable to receive data transformed by the transformation engine; and a load engine operable to load the data received by the common database controller into the common database. 19. A method of storing data in a database table comprising the steps of:
storing in a first column of a data record an identifier uniquely identifying a subject of the data record; storing in a second column a category name for the data record; and storing in a third column a category value associated with the category name in the second column; wherein modifying the table to include a new category for the subject of the data record comprises the steps of: adding to the table a second data record for the subject; storing in the first column of the second data record, the identifier uniquely identifying the subject of the second data record; storing in the second column of the second data record, a name of the new category; and storing in the third column of the second data record, a category value associated with the new category name in the second column of the second data record. 2. The distributed data storage system of
3. The distributed data storage system of
4. The distributed data storage system of
5. The distributed data storage system of
6. The distributed data storage system of
7. The distributed data storage system of
8. The distributed data storage system of
9. The distributed data storage system of
12. The distributed data storage system of
13. The distributed data storage system of
15. The method of storing data of
16. The method of storing data of
determining a status of the transformed data of the source database; determining a status of the loaded data of the source database; comparing the status of the transformed data to the status of the loaded data; and setting an error flag if the status of the transformed data differs from the status of the loaded data.
17. The method of storing data of
determining if the table into which the transformed data of the source database was loaded is valid; setting an error flag if the table is invalid; determining if the field of the table is valid; and setting an error flag if the field is invalid.
18. The method of storing data of
storing in a first column of a data record an identifier uniquely identifying a subject of the data record; storing in a second column a category name for the data record; and storing in a third column a category value associated with the category name in the second column.
|
|||||||||||||||||||||||||||
The present invention relates generally to the field of data manipulation and storage, and more particularly to a data storage system and method.
Modern businesses often employ various computer systems to record information for different departments and operations. Typically, each department selects a database system that best suits its particular needs. Thus, for example, an accounting department may utilize a system designed especially for accounting tasks while a production department of the same business may utilize a system designed to fit its manufacturing needs. As a result, many businesses have data stored on a number of disparate database systems in different formats.
The lack of common functionality between database systems of a business is problematic because it does not allow data from different departments and operations to be readily integrated. Such integration is often desirable to allow managers to readily review, compare and combine data from all departments and operations of a business.
In accordance with the present invention, a data storage system and method is provided that substantially eliminates or reduces the disadvantages and problems associated with the prior systems.
The data storage system may include a plurality of source systems and a common database server. Each source system may include a source database, an extraction engine and a transformation engine. At least two of the source systems may have source databases that store data in disparate formats and file structures. The extraction engine may extract data from the source database. The transformation engine may transform data extracted from the source database into a common format and file structure. The common database server may include a common database, a common database controller and a load engine. In a particular embodiment, the common database may be a relational database. The common database controller may receive data transformed by the transformation engine. The load engine may load the data received by the common database controller into the common database.
In accordance with another aspect of the present invention, the common database may include a table having a first, second, and third column. The first column may store a plurality of data record IDs. The second column may store a category name for each data record ID. The third column may store a category value for each data record ID and category name combination.
Important technical advantages of the present invention include providing a common database and method. In particular, the invention extracts and transforms data from a variety of sources into a common format. The data may be extracted from sources that in their natural form do not relate to each other. In transforming the data, the invention may augment translation of the data with supplemental processing to facilitate consolidation. The transformed data may be loaded into a common database from which it may be accessed and manipulated by users of the system. Accordingly, the present invention integrates data from a variety of sources.
Another important technical advantage of the present invention includes providing an improved method for accommodating category schemes. In particular, database tables include columns for storing data record IDs, category names, and category values. Thus, the database table supports an unlimited number of category schemes without requiring the table to be modified or altered.
Still another important advantage of the present invention includes providing a maintenance engine that executes select long-running queries such as those that summarize large amounts of data during off-prime time cycles. The maintenance engine may also ensure that the common database remains synchronized with a user interface.
Other technical advantages will be readily apparent to those skilled in the art from the following figures, descriptions, and claims.
For a more complete understanding of the present invention, any advantages thereof, reference is now made to the following description taken in conjunction with the accompanying drawings, in which:
FIG. 1 illustrates a schematic block diagram of a distributed database system including a common database server in accordance with one embodiment of the present invention;
FIG. 2 illustrates a schematic block diagram of one embodiment of the interface of FIG. 1;
FIG. 3 illustrates a database table for use in connection with one embodiment of the common database of FIG. 1;
FIG. 4 is a flow chart of a method for extracting, receiving and loading data into the common database of FIG. 1; and
FIG. 5 is a flow chart of a method for executing queries of the common database of FIG. 1.
Referring now in more detail to the drawings, in which like numerals refer to like parts throughout the several views, FIG. 1 illustrates a schematic block diagram of a distributed database system 12 constructed in accordance with one embodiment of the present invention. The distributed database system 12 may comprise a plurality of source systems 14 in communication with a common server 16. The common server 16 may also be in communication with a plurality of client systems 18.
The source systems 14 may each include a source database 20 and a database controller 22. The source database 20 may consist of a number of records, each of which is constructed of fields of a particular type, together with a collection of operations that facilitate searching, sorting, recombination and similar activities.
In accordance with the present invention, the source systems 14 may include source databases 20 that store data in disparate formats and file structures. Thus, the source databases 20 may be of different types, operate on different platforms, and the like. For example, the source databases 20 may be relational, sequential and/or hierarchal databases.
Each source database 20 may record and store data pertaining to a particular department, operation or facet of a business. Traditionally, the data could only be accessed locally within the department or remotely by a similar system. Thus, a single system could not receive and integrate data from the disparate source databases 20. As described in detail below, the present invention extracts, transforms and loads data from the disparate source databases 20 into the common server 16.
The database controller 22 may manage requests for database action. The database controller 22 keeps track of the physical details of file locations and formats, indexing schemes, and the like. Additionally, the database controller 22 provides centralized control of security and data integrity requirements.
The database controller 22 may include an extraction engine 24 and a transformation engine 26. The extraction engine 24 operates in conjunction with the database controller 22 to extract data from the source database 20. The transformation engine 26 may transform the extracted data into a common format and file structure. In transforming the data, the transformation engine 26 translates the data. The transformation engine 26 also augments translation with supplemental processing to modify disparate file structures of the source databases 20 into structures that can be combined. Accordingly, data extracted from each source database 20 is transformed into the common format and file structure. As described in detail below, the common format and file structure allows data from disparate source databases 20 to be loaded into the common server 16.
The common format and file structure is preferably compatible with the common server 16. The common format and file structure is compatible with the common server 16 where it can be directly utilized by the common server 16. Thus, for example, the common format and file structure may be the format in which data is stored in the common server 16. It will be understood, however, that the common format and file structure may require further transformation, translation or manipulation to be compatible with the common server 16.
The database controller 22 may determine a status of the transformed data. In accordance with one embodiment, the status of the transformed data may be the number of rows of data that is transformed.
The source systems 14 may each include a network interface system (NIS) 28 in communication with a network 30. The network 30 may be a Local Area Network (LAN), a Wide Area Network (WAN) or a combination network. Data extracted and transformed by the database controller 22 may be transmitted by the network interface system 28 over the network 30 to the common server 16. The data may be received at the common server 16 by a network interface system (NIS) 29.
The common server 16 may comprise a common database 32 and a common database controller 34. In a particular embodiment, the common server 16 may be a PYRAMID Server. The common database 32 may include a number of tables 36, together with a collection of operations that facilitate searching, sorting, recombination and similar activities.
In a particular embodiment, the common database 32 may be a relational database, such as an ORACLE database. In this embodiment, the common database 32 may store information in tables 36 comprising rows 38 and columns 40 of data (FIG. 3). As described in detail below, each row 38 may represent a data record 41 while each column 40 may represent a field 42 of the data record 41. The common database 32 may conduct searches by using data in specified columns 40 of one table 36 to find additional data in another table 36.
In accordance with the one aspect of the present invention, each table 36 may include three columns 40 for each row 38. The columns may be any type of structure in which data of a particular type is stored, listed, referenced, accessed, or the like. In this embodiment, as best shown by FIG. 3, a first column 44 identifies the data record 41 of the row 38. In one embodiment, the first column 44 may include a data record ID. It should be understood, however, that the first column 44 may consist of any number of columns that uniquely identify the data record being categorized. The second column 45 lists a category name of the data record ID. A third column 46 lists a category value of the category name and data record ID combination. Thus, the table 36 includes a column that identifies the categories of the listed data record IDs. This category mapping conserves space and supports an unlimited number of category schemes without requiring the table 36 to be reconfigured.
By way of example, FIG. 3 illustrates exemplary table 36. Table 36 includes general ledger account codes "502361," "502362," "502363" and "502364." The general ledger account codes "502361" and "502364" may have a "Pur Grp" (purchasing group) category of "network." Thus, those general ledger account codes correspond to a network purchasing group. The general ledger account codes "502362" and "502363" may have a "Pur Grp" (purchasing group) category of "communications." Thus, those general ledger account codes correspond to a communications purchasing group
As shown by FIG. 3, the general ledger account codes may be combined for global spend data for telecommunications by assigning each general ledger account code a "Gbl Spnd" (global spend) category for "telecommunications." Accordingly, category mapping allows data to be combined and/or split out based on category names. Continuing the example of FIG. 3, the general ledger account code "502361" may include a special category for "modems." Thus, a specialized data record may be created in the table 36 to focus on a very limited subset of the data. As described below, category mapping allows particular categories of data records in the common database 32 to be specified for a query of a report. Thus, a report may be tailored the meet the particular needs of the user. Additionally, category mapping conserves space and supports an unlimited number of category schemes. Users may add category names with which they are particularly interested to data records without requiring that the structure of the table 36 be reconfigured.
Returning to FIG. 1, the database controller 34 may manage requests for database action. The database controller 34 may also keep track of the physical details of file locations and formats, indexing schemes, and the like. Additionally, the database controller 34 provides centralized control of security and data integrity requirements.
The database controller 34 may include a load engine 48. The load engine 48 operates in conjunction with the database controller 34 to load data received from the source system 14 into the common database 32. As previously discussed, the data is received from the source systems 14 in a common format and file structure. Accordingly, data from a number of source systems 14 may be loaded, combined and otherwise manipulated in the common database 32. Thus, the common database 32 allows users to access, summarize and/or combine data that originated with the source systems 14 into data that is more meaningful to them.
The load engine 48 may also determine a status of the loaded data. In accordance with one embodiment, the status of the loaded data may be the number of rows of data that is loaded. The load engine 48 may validate the data received from the source systems 14 by comparing the status of the loaded data to the status of the transformed data. As previously discussed, the status of the transformed data may be the number of rows of data that is transformed.
The common server 16 may be accessed by the client systems 18. The client systems 18 may be remote to the common server 16. In such a case, the client systems may include a network interface system (NIS) 49 in communication with the network 30.
Each client system 18 may include an interface 50 for accessing the common database 32 of the common server 16. As best shown by FIG. 2, the interface 50 may include a client database 51 and a client database controller 52. The client database 51 may include a number of tables 53 and reports 54. Each report 54 may be based on one or more queries 55 of the common database 32 along with information directing the manner in which the data obtained from the queries should be displayed to a user.
The client database controller 52 may manage requests for client database action. The database controller 52 may also keep track of the physical details of file locations and formats, indexing schemes, and the like. Additionally, the database controller 52 provides centralized control of security and data integrity requirements.
The client database controller 52 may also execute the queries 55 of the reports 54. The client database controller 52 may execute the queries 55 by transmitting them over the network 30 to the common database controller 34. The common database controller 34 may then directly query the common database 32. The common database controller 34 may receive data from the common database 32 in response to the query. These results may be transmitted by the common database controller 34 over the network 30 to the client database controller 52. The results may be stored in tables 53 of the client database 51, displayed to the user, or both. When displayed to the user, the results of a report may be configured in accordance with the display information of the report.
The client database controller 52 may include a user interface 56 and a maintenance engine 58. In a particular embodiment, the user interface 56 may be implemented in whole or part by MICROSOFT ACCESS. The user interface 56 may receive user requests for reports 54. The user interface 56 may allow particular categories of data records in the common database 32 to be specified for a report. Thus, a report may be tailored the meet the particular needs of the user. In response to a user request, the user interface 56 may initiate execution of the queries 55 of the report 54 by the client database controller 52.
The maintenance engine 58 may also initiate execution of the queries 55 of a report 54. The maintenance engine 58 may initiate execution of a report 54 during off-prime hours. For example, the maintenance engine 58 may initiate reports 54 during evening or weekend hours. The maintenance engine 58 may also initiate reports 54 periodically according to a schedule. For example, a particular report 54 may be initiated daily while another type of report is initiated at the end of each week.
In one embodiment, the maintenance engine 58 initiates reports that include extended or popular queries. An extended report may include summary data that is resource intensive to accumulate. A popular report may be used by a large number of users. Results of extended queries may be stored in table 53 of the client database 51. Results of reports 54 initiated by the maintenance engine 58 may be stored in the client database 51 for later use. Accordingly, a user may later access the results of the reports or queries from the interface 50 without having to communicate with the common server 16 over the network 30.
The maintenance engine 58 may also transmit results of reports 54 that it initiated over the network 30 to other client systems 18. Accordingly, client systems 18 that use a same report 54 need not each execute the report 54. Rather, the report 54 is executed once by a client system 18 and then shared with other client systems 18.
It is well known in the art of computer programming that an engine is a collection of subroutines and data structures and performs a particular task or function. Thus, it will be understood that the extraction engine 24, transformation engine 26, load engine 48 and maintenance engine 58 have been separately identified and discussed for the convenience of the reader, and that the functions performed by any of the engines could be performed by another or different engine, or another part of the distributed database system 12. Thus, for example, the transformation engine 26 may be stored in the common database controller 34. In such an embodiment, data from the source systems 14 may be transmitted in disparate formats and file structures to the common server 16 and there transformed into a common format and file structure.
The methods of the present invention will now be described. FIG. 4 is a flow chart of a method of extracting, receiving and loading data into the common database 32. The method begins at step 100 wherein data is extracted from the source database 20. The data may be extracted by the extraction engine 24. As previously discussed, the source databases 20 of the source systems 14 may store data in disparate formats and file structures. Accordingly, at step 102, the extracted data is transformed into a common format and file structure. The common format and file structure is preferably compatible with the common server 16 such that it can be directly utilized by the common server 16.
Proceeding to step 104, the transformed data is transmitted to the common server 16. In the embodiment of FIG. 1, where the source systems 14 and common server 16 are remote, the data may be transmitted over the network 30. As previously discussed, the network 30 may be a Local Area Network (LAN), a Wide Area Network (WAN) or a combined network. The data may be received at the common server 16 by the common database controller 34.
Next, step 106, the load engine 48 of the common server 16 loads the data received by the common database controller 34 into the common database 32. The data may be loaded into the tables 36 of the common database 32. As previously discussed, the common database 32 may employ category mapping to conserve space in the database 32 and to support an unlimited number of category schemes without requiring the tables 36 to be modified or altered.
Steps 108-118 validate the data loaded into the common database 32. At step 108, the load engine 48 may compare the status of the loaded data to the status of the transformed data. As previously discussed, the status of the transformed data may be the number of rows of data that is transformed. Similarly, the status of the loaded data may be the number of rows of data that is loaded.
Proceeding to decisional step 110, the load engine 48 determines whether the status of the loaded data is valid. In one embodiment, the status of the loaded data is valid if the number of rows of loaded data is equal to the number of rows of transformed data. If the status of the loaded data is valid, the YES branch of decisional step 110 leads to step 112.
At step 112, the load engine 48 may open the tables 36 of the common database 32 into which the data was loaded. Next, at decisional step 114 the load engine 48 determines if the tables 36 are valid. In one embodiment, the tables 36 may be valid if they can be successfully opened. If the tables are valid, the YES branch of decisional step 114 leads to step 116.
At step 116, the load engine 48 may sample one or more fields of the tables 36 to determine if the fields are valid. Next, at decisional step 118, load engine 48 determines whether the fields are valid. In accordance with one embodiment, the fields are valid where they contain the expected type of data. If the fields are valid, the YES branch of decisional step 118 leads to step 120.
At step 120 the load engine 48 reports the status of the loaded data. The status of the loaded data may be reported to an administrator of the common server 16 and of each of the client systems 18.
Returning to decisional step 110, if the status of the data is not valid, the NO branch of decisional step 110 leads to step 122. The NO branches of decisional steps 114 and 118 also lead to step 122. At step 122, the load engine 48 sets an error flag. Thus, a system administrator may be notified of any errors in the loaded data. Preferably, invalid data is automatically removed from the common database 32 by the load engine 48. However, the invalid data may be retained in the common database 32 for review, correction, and/or removal by a system administrator. After the error condition has been corrected, the system administrator may restart the process at step 100.
FIG. 5 is flow chart of a process for executing queries of the common database 32. The process begins at step 200 in which a report 54 is executed by the client system 18. As previously described, the report 54 includes at least one query of the common database 32. Execution of the report 54 may be initiated by the user interface 56 or the maintenance engine 58 of the client database controller 52. The client database controller 52 may execute the report 54 by transmitting queries 55 of the report 54 to the common database controller 34. The common database controller 34 may execute the queries of the common database 32 and passes the results back to the client database controller 52. The results may be stored in the tables 53 of the client database 51.
At step 202, the client database controller 52 may validate the configuration of the client system 18. Step 202 leads to decisional step 204. In accordance with one embodiment, the configuration of the client system 18 may be valid if it includes the current version and table layout of the common database 32. If the configuration of the client system 18 is valid, the YES branch of decisional step 204 leads to step 206.
Steps 206-216 validate the data received in response to the query of the common database 32. At step 206, the client database controller 52 may compare the status of the data received to the status of that data in the common database 32. The status of the data in the common database 32 may be the number of rows of the data in the common database 32. Similarly, the status of the data received may be the number of rows of data that is received.
Proceeding to decisional step 208, the client database controller 52 determines whether the status of the data received is valid. In one embodiment, the status of the data received is valid if the number of rows of data received is equal to the number of rows of that data in the common database 32. If the status of the data received is valid, the YES branch of decisional step 208 leads to step 210.
At step 210, the client database controller 52 may open the tables 53 of the client database 51 into which the data received was loaded. Next, at decisional step 212 the client database controller 52 determines if the tables 53 are valid. In one embodiment, the tables 53 may be valid if they can be successfully opened. If the tables are valid, the YES branch of decisional step 212 leads to step 214.
At step 214, the client database controller 52 may sample one or more fields of the tables 53 to determine if the fields are valid. Next, at decisional step 216, the client database controller 52 determines whether the fields are valid. In accordance with one embodiment, the fields are valid where they contain the expected type of data. If the fields are valid, the YES branch of decisional step 216 leads to step 218.
At step 218 the client database controller 52 reports the status of the data received. The status of the received data may be reported to an administrator of the client system 18.
Returning to decisional step 204, if the configuration is not valid, the NO branch of decisional step 204 leads to step 220. The NO branches of decisional steps 208, 212 and 216 also lead to step 220. At step 220, the client database controller 52 sets an error flag. Thus, a system administrator may be notified of any errors in the received data. Preferably, invalid data is automatically removed from the client database 51 by the client database controller 52. However, the invalid data may be retained in the client database 51 for review, correction, and/or removal by the system administrator. After the error condition has been corrected, the system administrator may restart the process at step 200.
Although the present invention and its advantages have been described in detail, it should be understood that various changes, substitutions and alterations can be made therein without departing from the spirit and scope of the invention as defined by the appended claims.
Hoyt, Ronald A., Owens, Geoffrey M., Brichta, Harriet B., Lewis, Gerald R., Knesek, Mark D.
| Patent | Priority | Assignee | Title |
| 10242077, | Dec 10 2001 | Method and system for the management of professional services project information | |
| 10769168, | Mar 31 2006 | United Services Automobile Association (USAA) | System and method for integrating data across different enterprise systems |
| 11500826, | Apr 04 2017 | HCL Technologies Limited | System for translating data, extracted from disparate datasources, based on a defined metadata and schema |
| 6098129, | Apr 01 1997 | Hitachi, Ltd. | Communications system/method from host having variable-length format to variable-length format first I/O subsystem or fixed-length format second I/O subsystem using table for subsystem determination |
| 6247018, | Apr 16 1998 | CA, INC | Method for processing a file to generate a database |
| 6308164, | Apr 28 1997 | Distributed project management system and method | |
| 6477535, | Nov 25 1998 | CA, INC | Method and apparatus for concurrent DBMS table operations |
| 6529976, | Apr 01 1997 | Hitachi, Ltd. | Heterogeneous computer system, heterogeneous input output system and data back-up method for the systems |
| 6668253, | Sep 08 1999 | The Reynolds and Reynolds Company | Enterprise information management system and methods |
| 6678700, | Apr 27 2000 | General Atomics | System of and method for transparent management of data objects in containers across distributed heterogenous resources |
| 6721841, | Apr 01 1997 | Hitachi, Ltd. | Heterogeneous computer system, heterogeneous input/output system and data back-up method for the systems |
| 6792431, | May 07 2001 | Petris Technology Corporation | Method, system, and product for data integration through a dynamic common model |
| 6823328, | Jun 05 2000 | International Business Machines Corporation | System and method for enabling unified access to multiple types of data |
| 6836776, | Jun 05 2000 | International Business Machines Corporation | System and method for managing hierarchical objects |
| 6871255, | Apr 01 1997 | Hitachi, Ltd. | Heterogeneous computer system, heterogeneous input/output system and data back-up method for the systems |
| 6892268, | Apr 01 1997 | Hitachi, Ltd. | Heterogeneous computer system, heterogeneous input/output system and data back-up method for the systems |
| 7089489, | Jun 02 1997 | Telefonaktiebolaget LM Ericsson | Method and arrangement for browsing documents in a database |
| 7143112, | Sep 10 2003 | GOOGLE LLC | Method and apparatus for data integration |
| 7257594, | Apr 06 2004 | Petris Technology Corporation | Method, system, and product for data integration through a dynamic common model |
| 7269604, | Apr 27 2000 | General Atomics | System of and method for transparent management of data objects in containers across distributed heterogenous resources |
| 7304960, | Oct 31 2002 | AT&T BLS Intellectual Property, Inc. | Methods and systems for provisioning SONET elements |
| 7308646, | Aug 30 2000 | International Business Machines Corporation | Integrating diverse data sources using a mark-up language |
| 7356480, | Aug 01 2002 | Meta Platforms, Inc | Method of data transformation via efficient path discovery using a digraph |
| 7386528, | May 31 2002 | Liberty Peak Ventures, LLC | System and method for acquisition, assimilation and storage of information |
| 7428531, | Feb 06 2002 | JPMORGAN CHASE BANK, N A | Customer information management system and method |
| 7438234, | Jul 01 2004 | Liberty Peak Ventures, LLC | System for biometric security using a smartcard |
| 7445149, | Jul 01 2004 | Liberty Peak Ventures, LLC | System for biometric security using a smartcard |
| 7451924, | Jul 01 2004 | Liberty Peak Ventures, LLC | System for biometric security using a smartcard |
| 7451925, | Jul 01 2004 | Liberty Peak Ventures, LLC | System for biometric security using a smartcard |
| 7494058, | Jul 01 2004 | Liberty Peak Ventures, LLC | Smartcard transaction method and system using voiceprint recognition |
| 7497375, | Jul 01 2004 | Liberty Peak Ventures, LLC | Smartcard transaction method and system using smellprint recognition |
| 7500616, | Jul 10 2001 | Liberty Peak Ventures, LLC | Authenticating fingerprints for radio frequency payment transactions |
| 7506806, | Jul 01 2004 | Liberty Peak Ventures, LLC | Smartcard transaction method and system using fingerprint recognition |
| 7506818, | Jul 10 2001 | Liberty Peak Ventures, LLC | Biometrics for radio frequency payment transactions |
| 7506819, | Jul 10 2001 | Liberty Peak Ventures, LLC | Biometric security using a fob |
| 7510115, | Jul 01 2004 | Liberty Peak Ventures, LLC | Smartcard transaction method and system using auditory scan recognition |
| 7523860, | Jul 01 2004 | Liberty Peak Ventures, LLC | Smartcard transaction method and system using facial scan recognition |
| 7530493, | Jul 01 2004 | Liberty Peak Ventures, LLC | Smartcard transaction method and system using iris scan recognition |
| 7533827, | Jul 01 2004 | Liberty Peak Ventures, LLC | Smartcard transaction method and system using signature recognition |
| 7543738, | Jul 10 2001 | Liberty Peak Ventures, LLC | System and method for secure transactions manageable by a transaction account provider |
| 7594612, | Jul 01 2004 | Liberty Peak Ventures, LLC | Smartcard transaction method and system using retinal scan recognition |
| 7610261, | May 31 2002 | Liberty Peak Ventures, LLC | System and method for acquisition, assimilation and storage of information |
| 7610299, | Nov 30 2006 | KYNDRYL, INC | Method of processing data |
| 7637434, | Jul 10 2001 | Liberty Peak Ventures, LLC | Registering a biometric for radio frequency transactions |
| 7639116, | Jul 10 2001 | Liberty Peak Ventures, LLC | Converting account data associated with a radio frequency device |
| 7668750, | Jul 10 2001 | Liberty Peak Ventures, LLC | Securing RF transactions using a transactions counter |
| 7690577, | Jul 10 2001 | Liberty Peak Ventures, LLC | Registering a biometric for radio frequency transactions |
| 7705732, | Jul 10 2001 | Liberty Peak Ventures, LLC | Authenticating an RF transaction using a transaction counter |
| 7725427, | May 25 2001 | Liberty Peak Ventures, LLC | Recurrent billing maintenance with radio frequency payment devices |
| 7735725, | Jul 10 2001 | Liberty Peak Ventures, LLC | Processing an RF transaction using a routing number |
| 7793845, | Jul 01 2004 | Liberty Peak Ventures, LLC | Smartcard transaction system and method |
| 7801850, | Apr 27 2000 | General Atomics | System of and method for transparent management of data objects in containers across distributed heterogenous resources |
| 7886157, | Jul 10 2001 | Liberty Peak Ventures, LLC | Hand geometry recognition biometrics on a fob |
| 7889052, | Jul 10 2001 | Liberty Peak Ventures, LLC | Authorizing payment subsequent to RF transactions |
| 8001054, | Jul 10 2001 | Liberty Peak Ventures, LLC | System and method for generating an unpredictable number using a seeded algorithm |
| 8016191, | Jul 01 2004 | Liberty Peak Ventures, LLC | Smartcard transaction system and method |
| 8090734, | May 31 2002 | Liberty Peak Ventures, LLC | System and method for assessing risk |
| 8180809, | Aug 01 2002 | International Business Machines Corporation | Method for efficient data transformation |
| 8284025, | Jul 10 2001 | Liberty Peak Ventures, LLC | Method and system for auditory recognition biometrics on a FOB |
| 8307175, | Jun 26 2009 | Intel Corporation | Data recovery and overwrite independent of operating system |
| 8438132, | Mar 31 2006 | UNITED SERVICES AUTOMOBILE ASSOCIATION USAA | System and method for integrating data across different enterprise systems |
| 8548927, | Jul 10 2001 | Liberty Peak Ventures, LLC | Biometric registration for facilitating an RF transaction |
| 9009098, | Jun 30 2008 | EMC IP HOLDING COMPANY LLC | Methods and apparatus for creating a centralized data store |
| 9024719, | Jul 10 2001 | Liberty Peak Ventures, LLC | RF transaction system and method for storing user personal data |
| 9031880, | Jul 10 2001 | Liberty Peak Ventures, LLC | Systems and methods for non-traditional payment using biometric data |
| 9454752, | Jul 10 2001 | Liberty Peak Ventures, LLC | Reload protocol at a transaction processing entity |
| 9594805, | Jun 17 2003 | Teradata US, Inc. | System and method for aggregating and integrating structured content |
| 9798790, | Mar 31 2006 | United Services Automobile Association (USAA) | System and method for integrating data across different enterprise systems |
| RE43157, | Sep 12 2002 | Liberty Peak Ventures, LLC | System and method for reassociating an account number to another transaction account |
| RE45416, | Jul 10 2001 | Liberty Peak Ventures, LLC | Processing an RF transaction using a routing number |
| Patent | Priority | Assignee | Title |
| 4714995, | Sep 13 1985 | Northrop Grumman Corporation | Computer integration system |
| 5058000, | Jun 30 1987 | NCR Corporation | System for accessing remote heterogeneous database including formatting retrieved data into applications program format |
| 5335278, | Dec 31 1991 | ST CLAIR INTELLECTUAL PROPERTY CONSULTANTS, INC , A MICHIGAN CORPORATION | Fraud prevention system and process for cellular mobile telephone networks |
| 5345595, | Nov 12 1992 | AUTHORIZE NET LLC | Apparatus and method for detecting fraudulent telecommunication activity |
| 5416917, | Mar 27 1990 | International Business Machines Corporation | Heterogenous database communication system in which communicating systems identify themselves and convert any requests/responses into their own data format |
| 5446880, | Aug 31 1992 | AT&T IPM Corp | Database communication system that provides automatic format translation and transmission of records when the owner identified for the record is changed |
| 5574904, | Jan 19 1990 | Fujitsu Limited | Database management system in an intelligent network using a common request data format |
| 5600833, | Sep 17 1993 | HEWLETT-PACKARD DEVELOPMENT COMPANY, L P | Attribute portion based document retrieval system with system query language interface |
| 5625816, | Apr 05 1994 | GLOBALFOUNDRIES Inc | Method and system for generating product performance history |
| 5642337, | Mar 14 1995 | Sony Corporation; Sony Electronics Inc. | Network with optical mass storage devices |
| 5649168, | Sep 29 1994 | International Business Machines Corporation | Computer program product for a query pass through in a heterogeneous distributed data base environment |
| Executed on | Assignor | Assignee | Conveyance | Frame | Reel | Doc |
| Jun 06 1996 | ELECTRONIC DATA SYSTEMS CORPORATION, A CORP OF TEXAS | ELECTRONIC DATA SYSTEMS CORPORATION, A DELAWARE CORPORATION | MERGER SEE DOCUMENT FOR DETAILS | 009059 | /0163 | |
| Jun 14 1996 | Electronic Data Systems Corporation | (assignment on the face of the patent) | / | |||
| Jun 14 1996 | BRICHTA, HARRIET E | ELECTRONIC DATA SYSTEMS CORPORATION, A CORP OF TX | ASSIGNMENT OF ASSIGNORS INTEREST SEE DOCUMENT FOR DETAILS | 008044 | /0290 | |
| Jun 14 1996 | LEWIS, GERALD R | ELECTRONIC DATA SYSTEMS CORPORATION, A CORP OF TX | ASSIGNMENT OF ASSIGNORS INTEREST SEE DOCUMENT FOR DETAILS | 008044 | /0290 | |
| Jun 14 1996 | KNESEK, MARK D | ELECTRONIC DATA SYSTEMS CORPORATION, A CORP OF TX | ASSIGNMENT OF ASSIGNORS INTEREST SEE DOCUMENT FOR DETAILS | 008044 | /0290 | |
| Jun 14 1996 | HOYT, RONALD A | ELECTRONIC DATA SYSTEMS CORPORATION, A CORP OF TX | ASSIGNMENT OF ASSIGNORS INTEREST SEE DOCUMENT FOR DETAILS | 008044 | /0290 | |
| Jun 14 1996 | OWENS, GEOFFREY M | ELECTRONIC DATA SYSTEMS CORPORATION, A CORP OF TX | ASSIGNMENT OF ASSIGNORS INTEREST SEE DOCUMENT FOR DETAILS | 008044 | /0290 | |
| Aug 29 2008 | Electronic Data Systems Corporation | ELECTRONIC DATA SYSTEMS, LLC | CHANGE OF NAME SEE DOCUMENT FOR DETAILS | 022460 | /0948 | |
| Mar 19 2009 | ELECTRONIC DATA SYSTEMS, LLC | HEWLETT-PACKARD DEVELOPMENT COMPANY, L P | ASSIGNMENT OF ASSIGNORS INTEREST SEE DOCUMENT FOR DETAILS | 022449 | /0267 |
| Date | Maintenance Fee Events |
| Sep 16 2002 | M183: Payment of Maintenance Fee, 4th Year, Large Entity. |
| Sep 01 2006 | M1552: Payment of Maintenance Fee, 8th Year, Large Entity. |
| Oct 18 2010 | REM: Maintenance Fee Reminder Mailed. |
| Mar 16 2011 | EXP: Patent Expired for Failure to Pay Maintenance Fees. |
| Date | Maintenance Schedule |
| Mar 16 2002 | 4 years fee payment window open |
| Sep 16 2002 | 6 months grace period start (w surcharge) |
| Mar 16 2003 | patent expiry (for year 4) |
| Mar 16 2005 | 2 years to revive unintentionally abandoned end. (for year 4) |
| Mar 16 2006 | 8 years fee payment window open |
| Sep 16 2006 | 6 months grace period start (w surcharge) |
| Mar 16 2007 | patent expiry (for year 8) |
| Mar 16 2009 | 2 years to revive unintentionally abandoned end. (for year 8) |
| Mar 16 2010 | 12 years fee payment window open |
| Sep 16 2010 | 6 months grace period start (w surcharge) |
| Mar 16 2011 | patent expiry (for year 12) |
| Mar 16 2013 | 2 years to revive unintentionally abandoned end. (for year 12) |