Data processing: database and file management or data structures – Database design – Data structure types
Reexamination Certificate
2000-10-19
2004-06-22
Shah, Sanjiv (Department: 2176)
Data processing: database and file management or data structures
Database design
Data structure types
C707S793000
Reexamination Certificate
active
06754672
ABSTRACT:
BACKGROUND OF THE INVENTION
1. Field of the Invention
The present invention is directed to a system designed to assist federal government organizations in facilitating the integration and sharing of core administrative and program data among disparate but inter-related application systems via a web-based portal and a back-end interoperability engine.
2. Description of the Related Art
Federal organizations perform their operations using a fragmented set of computer systems. Each computer system associated with a particular federal organization addresses specific administrative needs, such as financial management, procurement, property management, asset sales, and grants management. Each computer system may further support program specific activities specific to the federal organization's mission, for example, environmental permitting, patent application processing, or managing customer relationship for social services. The federal organization may build its computer system in-house, purchase commercial-off-the-shelf products vendors, or implement a system developed by other federal organizations (e.g., the National Institutes of Health's contractor past performance system). In addition, the federal organization may desire or be required to use external publicly accessible systems such as FedBizOpps (formerly known as the Electronic Posting System), the Central Contractor Registration (“CCR”), the Federal Procurement Data System (“FPDS”), or the Federal Acquisition Management Information System (proposed to replace FPDS).
Each system provides value to the corresponding federal organization in automating the individual processes and functions for which they are designed. However, the functions of these systems often overlap, or need to interoperate. Consider the simple example of buying a desk. A procurement system generates the purchase order, but the procurement process requires interoperability with several other systems. For instance, the purchasing agent may desire to post solicitation information to FedBizOpps to solicit bids. Further, as part of the procurement decision process, the purchasing agent is required to consider the past performance of potential vendors, for example, by accessing past performance systems such as the NIH past performance system. The purchasing agent may require additional detailed vendor data, which may be stored in a CCR system. Further, before an order is finalized, the organization's financial system needs to be polled to ensure that funds are available in the budget for the purchase and to obligate money for the ensuing payment. The purchasing agent may also need to report order data to FPDS. A property manager may also want to track the newly purchased item as a fixed asset in a property management system.
To date, federal organizations have had limited options to achieve system integration. The federal organizations may build individual interfaces between two systems to enable those two systems to communicate and then repeat the process for other systems. However, this approach may result in a confusing network of related but separately developed interfaces that pose a high risk of being out of synch. Some federal organizations resort to re-keying the data into each system; however, this approach is labor intensive and repetitive.
In the late 1990s, Enterprise Resource Planning (“ERP”) systems were implemented in an attempt to solve interoperability problems among administrative systems in federal organizations by providing a single application that performs a variety of administrative functions, ranging from human resource management to financial management and procurement. However, the ERP system posed its own set of problems. For instance, switching to the ERP system required organizations to replace legacy applications with a new system and encumbered major system implementation expenses and management issues.
Additionally, the ERP system capabilities in specific functions, such as procurement, often fell short of robust functionality offered by best-of-breed products that were designed specifically to support those functions, thereby forcing organizations to choose between achieving a minimum level of administrative integration at the expense of deep functional support. Furthermore, it is difficult for any single software application system to anticipate and support all of the federal organization's potential programmatic needs, as well as, administrative needs. Even though the ERP system may meet some needs, it still requires a network of interfaces to other applications within the organization (e.g., program support systems and administrative systems not covered by the ERP) and requires a network of interfaces to publicly owned applications such as CCR and FedBizOpps. Seamless integration and communication among the various application systems requires extensive infrastructure or middleware architecture.
Portal tools enable delivery of data to employees, customers and business partners via a web-based interface. Yet, the portal tools need underlying instructions regarding what data to share among business partners, and the rules within which that data should be shared (e.g., read only, not visible, editable, deletable).
Enterprise Application Integration (“EAI”) products offer robust tools for such interoperability tasks as mapping one system to a defined data schema and sending messages from one system to another. EAI tools often provide out-of-the-box, “no coding” adapters that integrate widely used commercial off the shelf (“COTS”) products. Which EAI tools provide a platform that can facilitate interoperability and out-of-the-box adapters may provide a good integration starting point, several factors exist that require an additional layer of interoperability automation. For example, in many cases, federal organizations have built their own custom systems for which no standard adapter schema for a COTS product exists.
Additionally, out-of-the-box adapters are typically designed and developed for lowest-common-denominator data integration needs and for corporate business processes, not for federal organizations. Although much can be leveraged from commercial adapters to create federal adapters, these adapters must be changed or rewritten to accommodate core federal requirements (e.g., verfying funds availability before a purchase order is finalized). A federal interoperability tool is needed that enables federal organizations to pull their disparate application systems together and to base the interoperability and integration on rules established as both government-wide and organization-wide policy.
SUMMARY OF THE INVENTION
It is an object of the present invention to provide for a system that allows internal government systems (e.g., program systems including customer relationship management, internal operations, and administrative systems including finance, procurement, property, asset sales, and grants) and external government systems (e.g., FedBizOpps, CCR, FPDS or the Federal Acquisition Management Information System) to communicate and exchange messages and allows an end user to access the plurality of disparate legacy, current, and emerging government application systems from a point of entry web-based portal in a computer communications network. Further, the present invention ensures that information is accessed and used only in authorized ways and maintains the integrity, availability, and/or confidentiality of the information.
It is an object of the present invention to provide for a system, a method, and a computer readable storage medium providing users of a federal organization administrative and program processes a single web-based system interface from which to conduct all business transactions and exchanges of information. In particular, a data source includes self-describing documents including data elements, definitions of data elements, data element contents, data element characteristics and business function interoperability rules for each data element in the application systems. An interoper
American Management Systems, Inc.
Shah Sanjiv
Staas & Halsey , LLP
LandOfFree
System and method for efficient integration of government... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with System and method for efficient integration of government..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and System and method for efficient integration of government... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3312291