Data processing: database and file management or data structures – Data integrity – Concurrent read/write management using locks
Reexamination Certificate
2000-11-22
2003-12-09
Robinson, Greta (Department: 2177)
Data processing: database and file management or data structures
Data integrity
Concurrent read/write management using locks
C707S793000, C707S793000
Reexamination Certificate
active
06662199
ABSTRACT:
FIELD OF THE INVENTION
The present invention relates to an-Internet-based Enterprise Resource Planning (ERP) tool that provides a common hosted environment for multiple users thereof while at the same time permitting individual user customizations for data representations, workflow representations and visual interfaces.
BACKGROUND
Enterprise resource planning (ERP) software applications have now been in use for several years. Generally, ERP applications handle a wide variety of planning, transaction processing and accounting functions in an integrated manner. While there is no standard definition of an ERP application, it is common for products in this category to handle sales and customer management, forecasting, master production scheduling, material requirements planning (MRP), rough cut capacity planning, production orders, product/material definition, purchasing, supplier management, inventory tracking and financial accounting, i.e., the complete gamut of activities within any business enterprise (hence the term ERP). Many ERP applications also support costing, human resources management, finite capacity scheduling (FCS), quality management and equipment maintenance. The defining characteristic of an ERP application then is its integration of information across many functional areas. In order to provide such integrated solutions, ERP systems tend to rely heavily on databases.
Databases are computer-based record keeping systems. Stated differently, a database is a combination of computer hardware and software that acts together to allow for the storage and retrieval of information (data). Modern databases grew out of older information storage and retrieval systems. For example, early computer-based file systems allowed for record keeping in the form of familiar rows and columns known-as tables. The rows were referred to as records and the columns were known as fields; in order to find a particular piece of information a user browsed through the table and then extracted the needed field or fields from the desired record. So-called “keys” provided more immediate access to information by operating as a sort of index to the data stored in the table.
As the volume of data stored in computer-based systems increased, more flexible storage models (databases) were created. Databases allow for the sharing of data among multiple users through manipulation of user interface tools or command line interfaces that handle the storage, retrieval and modification of the data. Some databases are analytic in nature, providing mainly historical data that is not subject to modification, while others are more operational, in that they allow for managing dynamic bits of data. Furthermore, databases can be segregated by the way in which they model the data stored therein.
Hierarchical databases define relationships among different bits of data according to a hierarchical or tree-like structure. In such databases, a single table acts as a “root”, and all other tables in the database somehow depend from that root table. Thus, tables at various levels of the hierarchy may be parents of lower-level child databases, while at the same time themselves being children of some higher-level parent table or the root table. The root table is then defined as a table with no parent tables. In a hierarchical database, a child table may have only one parent, but a parent can have many children.
Network databases are another form of database and allow for child tables to have multiple parents and parent tables to have multiple children. Such a structure can avoid data redundancies that might otherwise exist in hierarchical databases. Unfortunately, network databases can be complex to develop and maintain.
Recently, relational databases have become popular. At the core of the relational database model are the familiar tables (also known as relations) made up of records (rows or tuples) and fields (columns or attributes). Where or how the various tables of a relational database are stored makes no difference. What does matter is that any table can be identified by a unique name and that name can thus be used to locate the table. This different from the hierarchical or network models, which require that users know where in the various trees a particular piece of data is located.
In relational databases, operations that manipulate (i.e., store, retrieve or modify) data do so on the basis of the data values themselves. Thus, if a users wishes to retrieve a row from a particular table, he or she does so by comparing the value stored within a particular column for that row to some search criteria. Also, tables can store not only actual data, they can also be used a means for generating meta-data (data about the table and field names which form the database structure, access privileges to the database, data validation rules, etc.). Thus, relational systems can use operations recursively in order to provide information about the database.
Relational databases are often searched using a so-called structured query language (SQL). SQL provides the structure and idioms needed to query a relational database in a platform-independent fashion. Rather than referring to data as a set of pointers, the SQL provides predefined procedures that allow users to use any value in a table to relate to other tables in a database. Most modem relational databases are SQL databases that are composed of a set of row/column-based tables, indexed by a “data dictionary”. To access data in the tables, users employ the SQL to navigate the database and produce “views” based on various search criteria defined in a query. The data dictionary is a catalog maintained by the database that includes a list of all the tables in the database and pointers to their locations in the storage medium. When an SQL query is made, the database looks up the table referred to in the query in the data dictionary in order to know where to go to execute the search. The data dictionary itself, however, cannot be queried directly.
An SQL query is generally made up of several parts. First is a query type, for example SELECT, that defines the type of action requested. Next, the location from which the data is to be retrieved must be specified. Finally, the search criteria which defines the type of information being sought is set forth. In response to the SQL query, the database consults the data dictionary and then accesses the table from which the data has been requested to put together a view. The view is essentially a dynamically generated result table that contains the data retrieved from the table specified in the query according to the user-provided search criteria.
ERP systems that rely on relational (e.g., SQL) databases are common in manufacturing and other environments today. However, one serious drawback of such systems is the need for labor intensive customization at the time such systems are established. For example, for each business in which a particular ERP system is to be established, the underlying tables will have to be uniquely tailored to that business' work processes. Furthermore, the various user interfaces (e.g., so-called wizards), data entry and retrieval forms, data formats, and workflows will likewise have to be customized to the business. Because modern ERP applications are complex software tools, it is likely that the business purchasing the system will not have the in-house expertise needed to undertake this customization process. Hence, in addition to the capital expended to purchase the ERP application tool itself, the business will have to hire outside contractors to perform the customization and then train the business' own employees on the use and operation of the system. This represents a significant cost to the business owner and also means that the customized ERP system is not transportable to other end-users.
An additional shortcoming that results from the need for such business-specific customization of existing ERP tools is that such products cannot be easily ported to Web-based (i.e., hosted) environments. To understand why th
Flight John L.
Kothari Pravins S.
Lau Edward S.
Nelson Philip C.
Wallgren Anders
Black Linh
Blakely , Sokoloff, Taylor & Zafman LLP
Printcafe Systems, Inc.
Robinson Greta
LandOfFree
Method and apparatus for customized hosted applications 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 and apparatus for customized hosted applications, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Method and apparatus for customized hosted applications will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3099514