WO2002075597A2

WO2002075597A2 - A method and system for providing a virtual unified product content repository

Info

Publication number: WO2002075597A2
Application number: PCT/IL2002/000206
Authority: WO
Inventors: Moshe Aelion
Original assignee: Federation Web Inc.
Priority date: 2001-03-15
Filing date: 2002-03-14
Publication date: 2002-09-26
Also published as: IL142039A0; WO2002075597A3

Abstract

Method for generating a virtual unified product content repository consisting of a plurality of different databases, each of which presented in a specific original schema, located at different sites that are connected through a data network. Selected sites which are access points to the data network are determined, such that each site is a source site of product content, from which a data package, selected from the product content, is sent to a remotely located destination site. At each source site that has permission to update the local product content stored therein, a request for a data package is received from the remotely located site. Predetermined rules for extracting and replicating data packages are activated and a generic schema for exchanging different types of data packages between remotely located sites is generated. Whenever a transfer of a data package from site to site is required, the original schema of the data package to be sent from the source site is converted on-the-fly into the generic schema. Both the original schema and the generic schema of the data package are stored and the data package is forwarded from the source site to the remotely located site, in the generic schema and over the data network, according to the predetermined rules. The data package in the generic schema, from the source site, is received at the remotely located site, which is the destination for the data package. The data package is converted from the generic schema into the local schema of the destination. Both the local and generic schema of the data package are stored and the data package represented in the local schema is affiliated to the local database of the destination.

Description

A METHOD AND SYSTEM FOR PROVIDING A VIRTUAL UNIFIED PRODUCT CONTENT REPOSITORY

Field of the Invention

The present invention relates to the field of data processing systems. More particularly, the invention relates to a method and apparatus for providing Collaborative-Commerce (C-Commerce) and engineering platform for Product Content Repositories (PCR).

Background of the Invention

Historically, system development had primarily emphasized on operational systems (i.e. information . systems that support the day-to-day mission operations of an enterprise/organization) and the data they process. Another part of Information Systems (ES) strategy has always been archiving the data that the operational systems have processed,, and strategic reporting of such information to facilitate planning, forecasting and managing the organization. Most of business data for large corporations had been stored on expensive mainframe computers, or archived to tapes to satisfy some of the need for strategic analysis. IS provided access to that data by using programs that generated reports and extracted data, usually overnight or over weekends, so that business analysis would not interfere with and degrade the performance of operational systems. However, the time required to develop a strategic reporting application, and enhance it as requirements changed frequently, turned out to be longer than acceptable by the end users. They needed to react quickly to changing business circumstances. This has been changed during the past decade with the proliferation of personal computers, as end users began to build their own specific applications with PC-based database and spread sheets. However, this model for business analysis has the drawback of leaving the data fragmented and oriented according to very specific needs. Control, capacity and integrity issues often got out of hand. The extracts were unable to address the needs of multiple users and tasks. The numerous "data islands" exacerbated the data access crisis suffered by many enterprises.

In order to overcome these drawbacks, a new technology has been developed: the Data Repository System (DWS). A data repository is an informational system, which is used for planning and managing an organization.

There are several types of DWS. One of them is the Product Data Repository (PDR). A PDR contains information that is required to define, design, manufacture, assemble, ship and maintain a product.

The main features of a conventional Production Data Repository (PDR) are the following:

(1) Data volume - The data volume in a PDR is rather large. The data stored in it is mostly produced by many operational systems. The PDR combines data from distributed systems- especially from operational systems- and might also be distributed itself.

(2) Data access - the data of the data repository is nonvolatile; i.e. once data is loaded into the repository from the application-oriented operational environment (and/or external sources), it does not change, but is merely accessed there. Data "updates" in the data repository environment require periodic massive loading of data from the operational environment.

(3) Time variance — in data reepositories, most of the stored business like data is historical. The data is updated without time-stamping it, i.e., there is no time track of updates that are made in the data repository.

(4) Diverse data sources - a project usually comprises several types of documents, which may be managed by several data sources:

4.1 Managed by ERP (Enterprise Resource Planning) systems:

• Bill of material

• Product configuration

• Effectivity

ERP is an industry term for a broad set of activities supported by multi-module application software that helps, e.g., a manufacturer, manage the important parts of his business, including product planning, parts purchasing, maintaining inventories, interacting with suppliers, providing customer service, and tracking orders.

4.2 Managed by PDM (Product Data Management) systems:

• Bill of material

• Product configuration

• Document management meta-data

Meta-data is 'data about data', namely meta-data describes how and when and by whom a particular set of data was collected, and how the data is formatted. Meta-data is essential for understanding information stored in data repositories. 4.3 Handled by CAD systems:

• Drawings

• Solid models

4.4 Managed by Component Supply Management (CSM) systems:

• Catalog component data

• Manufacturer data

• Component parameters

As may be appreciated, the PDR is a powerful tool. However, the traditional PDR has some major drawbacks, one of which is due to the fact that from, e.g., historical reasons, different (legacy) sites are likely to utilize different types of data systems. Consequently, such a PDR does not allow efficient collaboration between multiple sites of a global enterprise and different supply chain participants across the "extended enterprise". The second drawback is that it does not provide the users with real-time or even near real-time synchronization of multiple data sources with multiple users that share a common project.

All of the methods described above have not yet provided satisfactory solution to the problem of unifying different sources of information, based on different standards, when it comes to engineering and commercial collaboration between multiple buyers, sellers, sub-contractors, designers and manufacturers, that may use different types of Back- End- Systems (BES), such as a Product Data Management (PDM) system or other legacy systems, that are based on different standards.

It is an object of the present invention to provide a method and system for providing a virtual unified Product Content Repository. It is another object of the present invention to provide a method and system for providing an Internet-based technology of Collaborative- Commerce Engine (i.e. C-Commerce Engine).

It is still another object of the present invention to provide a method and system to allow each site of a global enterprise, a rapid access to a unified data store, in order to make productivity more efficient.

It is still another object of the present invention to allow original scalability and redundancy of the original ARPANET (Advanced Research Project Agency) network precursor to the Internet.

It is still another object of the present invention to provide a method and system to allow remote locations/users to retrieve nearly 'real-time' information, by using a common commercial and engineering platform.

It is still another object of the present invention to provide a generic schema, in which data is stored and converted into a general schema, regardless of the original/native schema from which the data comes, and which allows automatic conversion between different types of schemas.

If is still another object of the present invention to provide a method and system for reducing network congestion that is caused by excessive interactions between remote users and applications with PDRs.

It is further still another object of the present invention to provide a method and system that provides a solution to the problem of Data ownership in a network that supports multi-participants and multi-tasks. Other objects and advantages of the invention will become apparent as the description proceeds.

Summary of the Invention

The present invention is directed to a method for generating a virtual unified product content repository consisting of a plurality of different databases, each of which presented in a specific original schema, located at different sites that are connected through a data network, such as the Internet or an Intranet. Selected sites which are access points to the data network are determined such that each site is a source site of product content, from which a data package, selected from the product content, is sent to a remotely located destination site. At each source site, having permission to update the local product content stored therein, a request for a data package is received from the remotely located site. Predetermined rules for extracting and replicating data packages are activated and a generic schema is generated for exchanging different types of data packages between remotely located sites. Whenever a transfer of a data package from site to site is required, the original schema of the data package to be sent from the source site is converted on-the-fly to a generic schema. Both the original schema and the generic schema of the data package are stored and the data package is forwarded from the source site to the remotely located site, in the generic schema and over the data network, according to the predetermined rules.

Using a generic schema has a significant benefit. Assuming, for example, that there are ten PDMs, and each PDM's data format is to be converted into every other PDM's format. In this case we would require ninety conversion systems. However, by using a generic schema as an intermediator, only twenty converting systems are required. The generic schema is used as, the infrastructure for transferring data packages, as well as changes/updates that were made in these data packages, from one site to another site.

At the remotely located site, which is the destination for the data package, the data package is received, from the source site in the generic schema. The data package is then converted from the generic schema into the local schema of the destination and both the local and generic schema of the data package are stored. The data package represented in the local schema is affiliated to the local database of the destination.

In each site, asynchronous storage, management and replication of data objects are carried out by using LDAP -based replication engine, being modified and extended to be orientated to manufacturing sites and product content. User-defined classes are generated according to the product content. Objects are created by using the user-defined classes and data objects are created by storing data in the objects. Replications of the data objects are selectively directed to remotely located sites.

Changes of data package(s) may be made at one site at a time, the site having permission to update the local product content stored therein, thereby being the owner of the data package(s). The ownership may be permanent, temporal, intermittent or transferred from one site to another site. Preferably, only changes are forwarded from a site, being an owner, to remotely located sites. Different sites may be allowed to access replications of selected data packages over the data network. Whenever . data package(s) can not be retrieved by a site, from a remotely located site, the site is allowed to retrieve the data package(s) from at least another remotely located site. Corresponding data changes may be stored in remotely located sites in response to the data changes that are forwarded by the owner of the data package(s). According to one aspect of the invention, access of a user that is connected to a site, may be limited to browse/search operations in the unified data repository. According to another aspect, determination and modifications of rules may be carried out remotely through a web site. According to still another aspect, the remote sites may be associated with different enterprises.

A site may be an E-marketplace that comprises an Exchange -engine, linked to a web site, the Exchange-engine being software for exchanging business-oriented data between different sites and a server for exchanging product-oriented data between different sites. The source site provides access to a buyer and the destination site provides access to a bidder.

Preferably, the buyer of a product publishes, or forwards, a Request For Proposal (RFP) of the product to one or more bidders, by performing the following steps: a) allowing the buyer to enter the E-marketplace; b) creating the RFP in the E- marketplace; c) converting the engineering specifications of the product into a generic schema; d) replicating data represented in the generic schema to the E- marketplace; e) replicating changes made to the original ISP engineering data; f) allowing the bidder to enter the E-marketplace; g) replicating the RFP from the Exchange-engine to the site of the bidder; h) replicating the engineering specification, associated with the

RFP; i) allowing the bidder to prepare the proposal according to the downloaded engineering specification; j) optionally, allowing the bidder to prepare a modified engineering specification; k) forwarding the proposal and the modified engineering specification to the E-marketplace; and 1) allowing the buyer to access the proposal and the modified engineering specification through the E-marketplace.

Browsing through the unified product content repository may be carried out. through a remote portal by using a hyperbolic tree.

The present invention is also directed to a data network for generating a virtual unified product content repository consisting of a plurality of different databases, each of which represented in a specific original schema, located at different sites that are connected through a data network, that comprises: a) A plurality of nodes being access points to the data network, each of which being a source site of product content, from which a data package, selected from the product content, is sent to a remotely located destination site; b) at each source site, having permission to update the local product content stored therein, comprising: b.l) means for receiving a request for a data package from the remotely located site; b.2) means for activating predetermined rules for extracting and replicating data packages; b.3) means for generating a generic schema for exchanging different types of data packages between remotely located sites; b.4) means for converting a data package, being represented in original schema, into the generic schema; b.5) means for storing both the original schema and the generic schema of the data package; and b.6) means for forwarding the data package from the source site to the remotely located site, in the generic schema and over the data network, according to the predetermined rules; c) at the remotely located site, being the destination for the data package: c.l) means for receiving, from the source site, the data package in the generic schema; c.2) means for converting the data package from the generic schema into the local schema of the destination; c.3) means for storing both the local and generic schema of the data package; and c.4) means for affiliating the data package represented in the local schema to the local database of the destination.

At each site, an asynchronous storage, management and replication of data objects may be carried out by using LDAP -based replication engine, being extended and modified to be orientated to manufacturing sites and product content, comprising: a) means for generating user-defined classes according to the product content; b) means for creating objects from the user-defined classes; c) means for creating data objects for storing data in the objects; and d) means for selectively directing replications of the data objects to remotely located sites.

Changes of data package(s) may be performed at one site at a time, such that the site having permission to update the local product content stored therein is the owner of the data package(s). Browsing through the unified product content repository may be carried out through a remote portal by using a hyperbolic tree.

Brief Description of the Drawings

The above and other characteristics and advantages of the invention will be better understood through the following illustrative and non-limitative detailed description of preferred embodiments thereof, with reference to the appended drawings, wherein:

Fig. 1A schematically illustrates the general layout and functioning of the engineering collaboration system, according to a preferred embodiment of the invention;

Fig. IB schematically illustrates the general layout and functioning of the commercial and business collaboration system, according to another preferred embodiment of the invention;

Fig. 2 schematically illustrates the concept of the virtual unified data repository, according to a- preferred embodiment of the invention;

Fig. 3 schematically illustrates an example of traditional distributed manufacturing sites;

Fig. 4 schematically illustrates an example of distributed manufacturing sites, according to a preferred embodiment of the invention; Fig. 5 schematically illustrates an example of deploying new servers in different manufacturing sites, according to a preferred embodiment of the invention; and

Fig. 6 schematically illustrates an example of deploying new servers to coexist with Exchange engines, according to a preferred embodiment of the invention.

Detailed Description of Preferred Embodiments

In one aspect, the invention is directed to a method and apparatus for creating a scalable, Virtual Unified Product Content repository, by using selective peer to peer, asynchronous smart data replication within the multi-site enterprise and synchronization within the Enterprise and across the Supply Chain. According to the invention, a new Internet-based platform is created, that allows seamless integration of open Internet protocols and Web standards (e.g. extended Marked Language-XML, Component Object Model-COM+) with Exchange engines (e.g. Ariba, Commerce-One) and Back-End Systems (BES) systems, such as Enterprise Resource Planning (ERP), PDMs and CSMs systems.

According to one embodiment of the invention, the system comprises the following components:

(1) a Server, which is the backbone that maintains the repository integrity, manages the repository repositories and performs the seamless replication of complete product information. Several servers are deployed, depending on the number of sites that participate in the collaborative network. These can be remote sites within one organization, or servers may be deployed both at the buyer and its supplier's sites. The server has three major roles:

(la) "Traffic controller" - it defines and activates the rules by which data is extracted, replicated and integrated into the 'servers network'. These rules refer to the 'update frequency', security, authorization, data packaging (i.e. what data is replicated), etc: The controller also directs data package replications, extracts the data from the existing BES (legacy) system, inserts the data into the PCW, replicates the data between remote sites by using LDAP -based replication engine (which is explained later) and updates the local BES with the data package.

(lb) "Data Manager" - it stores the engineering data (divided into data packages) in the PCW and converts the data from one BES (native) schema to another. All the data is stored in two schemas: the original/native schema (i.e. the schema of the original BES system, from which the data was extracted), and the generic schema, which is the base for cross-schema conversions.

(lc) The server identifies the changes that were made in the data that is contained in the local BES, and forwards only these changes to other servers. This solution bypasses the Internet drawbacks (e.g. low speed), since only changes are forwarded through the Internet. Therefore, a lot of time is saved, the system as a whole is much more efficient and the near real-time effect is thus achieved.

As is mentioned above, the server(s) stores two schemas of every data package that it either sends to other sites (i.e. native and generic schemas), or receives from other sites. This way of handling data packages has two major advantages. The first one is that only changes in the data (i.e. updates), are transferred from the originator site to destination sites, resulting in a minimal transfer time over the data network. A second advantage is, that in a case where a certain data package is required in a new site, this data package may be available at least in one site, in which case there is no need to spend time in creating a new data package, which involves extracting the required data from the product content, converting the required data into the generic schema and making a replication of it prior to forwarding it to the new site.

(2) An adaptor, which interfaces between each local server and the conventional BES systems. This kind of interface is required, since the local servers exchange data with local BES systems that are based on different standards. Thus, each type of BES system requires a different type of adaptor. The data flow direction through the adaptor is governed by its local server. If a certain site wishes to send updates to other sites, these updates will be forwarded from this site's BES system, through the adaptor, to its corresponding server, and from this server to (by the data network) servers in remotely located sites. Adaptors transfer data at both directions; i.e. from BES system to its corresponding server and vice versa, in local/original/native schema(s).

(3) A schema broker, whose task is to convert original data, which may be represented by different/various schemas, into a generic schema, and to convert the generic schema to every other schema, whenever required.

(4) a Galactic Browser, which is an on-line tool that allows users to brows and search the unified product repository. (5) a Portal, which is a non-BES independent Web Portal, that allows access to the unified, product repository. This portal is a 'plug-in' software element, which allows browsing and accessing to servers in the network, wherein engineering data is contained. This portal has the ability to present to its user any engineering information contained in remotely located sites, assuming that these sites are connected to the data network by said servers. This information may be presented by the portal in the form of a graphical display and/or hierarchic form; e.g. in the form of 'product tree', 'document-tree' etc. The portal uses the graphical representation to navigate through a large hyperbolic tree, in an intuitive and efficient way.

(6) an Adviser, which is a Web-based tool, that logs all transactions, including the display of meta-data.

(7) a central Exchange Cbolt-on') server. Its role is, according to the invention, to add the engineering content to RFPs that are created in conventional Exchange sites, thus enhancing the functionality of said conventional Exchange sites. The central Exchange server is used, as an intermediator for transferring engineering data from a buyer to a bidder, and vice versa.

This central server is an option - it is not required in cases where the users/participants are contained within the same organization, enterprise or site; i.e. when using the same computerized systems, in which case there is no need for an intermediator (i.e. for a central Exchange server).

Two features; namely the 7^th layer of the Internet and the LDAP service are used. Some of the unique features of the invention are supported by the 7^th layer of the Internet, which is used as a backbone of the system. The 7^th layer of the Internet is the application layer, which is the highest layer in the Internet. This layer provides the means for application process to access the Open System Interconnection (OSI) environment. Its function is to serve as the passageway between application processes that are using OSI to exchange information; consequently, all application process parameters become known to the OSI environment through this layer.

The application layer provides all of the services (i.e. systems and applications management functions) that are directly used by the applications processes. Additional services provided by this layer, other than information transfer:

• Identifying intended communications partners.

• Determining current availability of the intended partners.

• Establishing the authority to communicate.

• Agreeing on responsibility for error recovery.

• Agreeing on procedures for controlling data integrity.

According to one aspect of the invention, the 7^th layer is used for transferring the product content between the servers, while assuring the data integrity of the product content, and providing the layer for the schemas conversions. Additionally, the 7^th layer ensures that the virtual PCW is always up and running. Consequently, this provides each user that is connected to the new system with relevant information, which is always up-to-date, despite of the fact that it is stored locally.

The second feature required to carry out the invention is a modified LDAP- based replication engine, which is used as an infrastructure for the virtual PCW. The LDAP-based replication engine is comprised of the following components:

1. 'Product content schema' - defines the structure of the classes that represent the product content in the engine's repository.

2. 'Repository' - Stores the product content objects that where either replicated from a remote site or uploaded from a local legacy system.

3. Connection Agreement Mechanism - selectively replicates product content packages to selected target sites. This mechanism extends current LDAP-based products that replicate all of the repository data to all the remote sites.

4. 'Data interface' . - used to insert and extract data to/from the repository (for example- inserting data from the legacy system or extracting data for the portal). The data interface is also used to maintain transactional integrity.

5. 'Analyzer' - identifies modifications to the product content and replicates them to the target sites by employing the above- mentioned Connection Agreement Mechanism.

The LDAP-based replication engine is used to create the new "Collaborative Community", by using up to hundreds of sites. The large number of such sites is a mandatory requirement for integration that involves many manufacturers, sub-contractors, buyers and suppliers. The new LDAP-based replication engine is also used to store, manage and replicate data. The LDAP protocol is used in the invention in a way which differs from its original intention, by modifying its schema. The original schema of the products that implement the LDAP protocol has been designed to handle distributed users, printers etc., while the new schema is used to handle distributed product content (such as items, bill of materials, etc.). In order to manage the schema of software product that utilizes the LDAP protocol (such as Active Directory or ORACLE Internet Directory), a special software package has also been developed. This software package extends the abilities of the original LDAP -products, by creating a product-content oriented schema and adding additional functionality such as selective replication. Each one of the servers contains the new LDAP-based rephcation engine, and the whole system consists of servers' network, such that every server can be looked over as one distributed directory, which may be accessed by users, whether by using BES systems, or by a direct access to a new portal. The servers' network is characterized by the fact, that there is no master server that has superiority over other servers, in terms of management. All of the servers are equal in that respect, namely each server can initiate the creation of, requesting and launching data packages.

The LDAP-based replication engine is based on two major guidelines:

1. Selective targeting on LDAP - the original LDAP tool has been modified to allow controlling the LDAP replication mechanism regarding target sites. In conventional systems, a Connection Agreement Mechanism is used as a basis for communication protocols, and its function is to allow sending data from one point to another point. According to the invention, such a mechanism is used to link between the LDAP protocol and the various servers in the data network, and it allows a selective transfer of data packages, from one site to another site. The organization's product content is stored in LDAP directory schema on each of the organization's sites, and is replicated to every remote site, where it is required, using the replication mechanism of LDAP. The connection agreement mechanism, thus, is used to direct each data object to a specific target site.

2. Using LDAP for keeping product content - the original LDAP data model has been modified to allow storing and replicating product content. The LDAP, which is normally used for storing network resources data, is used in the invention to store product content from the organization's database(s). In order to achieve that purpose, user- defined classes are created according to the product content structure. A class is an informational pattern, having several fields. Referring to the conventional Active Directory protocol, two such classes relate, for example, to a user and to a printer. A user class contains details of a user (e.g. name, telephone number, authorization level) etc. According to invention, classes are used, for example, for storing items and documents (i.e. data objects), that relate to the engineering content of the product, within the LDAP schema.

LDAP program interfaces are used for controlling and manipulating the data, as well as to transfer the data to, and from, the organization's database.

The modified LDAP tool has, in general, the same advantages as the conventional LDAP tool. More specifically it has the following advantages:

1. An efficient replication mechanism.

2. High scalability- it works well with large number of sites.

3. Selective data transfer, which meets the security requirements. 4. Efficient data storage structure, due to the LDAP data storage structure being optimized simultaneously for quick ook-up' in a situation wherein the data is geographically distributed

According to a preferred embodiment of the invention, there are basically two principal modes of operation: (1) exchanging engineering data in distributed manufacturing sites, and (2) exchanging commercial data (e.g. bids, sells, prices, proposals, catalog numbers) along with the relevant/corresponding engineering data.

There are, however, other situations, wherein a user in a site may view and/or retrieve and/or change and/or move forward and or receive data package(s) from/to other remotely located sites/users.

Regarding the first mode, a user can access the distributed engineering data by either connecting to a local BES (legacy) system, which is connected to a local server by an adaptor, or to a portal. Exchanging engineering data can be carried out only between two sites that have servers that are connected to the data network, because only these servers can handle the extraction, replication and forwarding of the required data from one site to another. However, according to one embodiment of the invention, a portal is also provided, by which a user in one site can view data in remotely located sites.

As to the second mode, there is a central Exchange Cbolt-on') server, according to one embodiment of the invention, which cooperates with essentially every server at each site, and with the existing Exchange engine(s). Several Exchange engines are currently available (e.g. Ariba, Commerce- One). An Exchange engine is a software product that forms the base for the Internet-marketplace. These conventional Exchange engines can handle only commercial transactional-based activities, such as creating and distributing RFPs, creating, delivering and evaluating the proposals and forward them onwards, sells, prices, orders, bids etc. Affiliating engineering data from the servers enhances these Exchange engines capabilities, thus forming a more comprehensive E-marketplace.

The central server works along side with the conventional Exchange engine, as it contributes the engineering content to the RFP, which is created in the Exchange site, thus enhancing the conventional Exchange site. Adding the engineering content to said RFPs is carried out by the RFP's publisher; i.e. the^' RFP's publisher (e.g. a buyer) forwards the relevant engineering data from his own BES, through his local server, to said central Exchange server. Since the latter server is a part of the enhanced/modified E-marketplace, the engineering data package, that was forwarded to the E-marketplace, becomes available to every user that has an interest in viewing or downloading this data (e.g. a seller). In a case of downloading this engineering data, said data is forwarded from the central Exchange server to said user's BES system. Moreover, this user (e.g. a seller) can answer the RFP by sending his bid together with his own engineering data, in which case said engineering data is forwarded from the seller/bidder's BES system to said central Exchange server, and from there to the buyer's BES system. In contrast to the prior art, and in accordance with the invention, the RFP's publisher can forward relevant engineering data to the Exchange site, in order to attach it to his RFP. The Exchange site may contain, therefore, both the commercial/business data (i.e. RFP) and its related engineering data. The RFP content resides in the conventional Exchange engine, while the engineering data resides in the central Exchange server. A seller, for example, may enter the same Exchange site and make his bid accordingly. Moreover, according to the invention, the seller has an option to 'click' a button in the Exchange site, that will redirect him to the annexed engineering data resides in the central Exchange server, which is a part of the enhanced/modified Exchange site.

If the buyer and the subcontractor/seller have different types of BES systems, and the seller wishes to download the buyer's engineering data, this data undergoes a conversion phase, which is carried out by the new servers, and only then is transferred to the seller's local legacy system.

It should be noted, that a user who 'clicks' said button in the Exchange site (i.e. to view or retrieve engineering data), is not aware of the fact that he is redirected to the central Exchange server for viewing or retrieving the required engineering data. From his point of view, he is still in the Exchange site. This way the engineering data is seamlessly integrated with the Exchange site.

Each local BES system contains essentially partial data. However, each local server gets replicas of selected data contained in the remotely located servers, and thus in the remote BESs. Consequently, each local server contains replicas of every data that is required by its corresponding local BES. Therefore, every user may access his local server, through his local BES and its corresponding adaptor, and if authorized, retrieve data from there, even though the data has originated from remotely located BES systems. The remote data is seamlessly integrated into the user's local BES system, and he may process that data on his traditional legacy system (e.g. BES), the same as he did before. Every change in the data is first updated in the local BES, and then in the local server. The local server then makes replicas of the changes, and sends them to the other servers.

According to a preferred embodiment of the invention, there are two kinds of data replications. The first one refers to data replications that are forwarded from one user's server to other remotely located servers (see the above description). This kind of rephcation is used for creating the required platform of the engineering data. The second kind of data replications refers to data replications that are forwarded from a user's (e.g. buyer, seller) server to an Exchange site, which is the site where Internet transactions (i.e. e-marketplace) are carried out. This kind of replications is used in order to allow an Exchange user to retrieve engineering data as well.

Another element required to implement the invention is that the current solution is based on a unified system, unlike other solutions that are based on centralized systems. Unified systems are advantageous compared to the centralized systems, in that in a unified system, every participant may get a copy of the required data, from any remote participant/user which is connected to the network, and use it (including changing it) without affecting other participants and/or tasks.

One more element is the way data replications are carried out. Unlike 'mirror' replication, wherein the whole data is replicated as one entity, regardless of what parts of it are actually required, the present invention employs 'smart' data replications, wherein only specific/required/selected data packages are replicated and sent to their corresponding destinations (i.e. end user's local system).

Additional functionality offered by the new server is the collaboration evaluation of the bidders engineering proposals. Fig. lA schematically illustrates the general layout and functioning of the engineering collaboration system, according to a preferred embodiment of the invention. Several sites, i.e., A, B, C, D and E, are connected to the Internet (101, 102, 103, 104 and 105, respectively). These sites are only for illustration purpose, and the network may comprise more participants and/or users and or sites. A site (e.g. sites A, B and C) may comprise a user (11), a local BES system (12), an adaptor (13) and a local server (14). The local BES (12) may be any legacy system (e.g. PDM), by which users (11) develop/design their engineering projects/products.

Suppose that users (11) in site B (Fig. 1A: 102) have to collaborate with users (11) in site A (Fig. 1A: 101) on an engineering project, for example data group B (102: 18), which is currently managed only on the BES in site B (102: 12). The first step is defining, by a user in site B (102), the data package that contains the data required by users in site A (e.g. data group B, in site B). The next step is to define the replication rule of this package, which has to be forwarded from site B to site A. The replication rule is defined by users in site B, as site B is the originator/owner of the data. After activating this replication rule, the relevant data is extracted from the BES in site B (102: 12), through the local adaptor (102: 13), into the local server (102: 14), where it is converted into a generic schema and it is stored in the Product Content repository (PCW) both in the native (i.e. original) and generic schemas. A rephcation of the required data is forwarded from site B (102: 14) to site A (101: 14) through the Internet (23), and the replicated data is converted, in the server (101: 14), from the generic schema to the site A's specific native schema, that is used by site A's local BES (101: 12). The original replicated data package is stored in site A's server (101: 16), while changes may be made to the data by a user in site A (101: 11) in his local BES (101: 12) by using the local adaptor (101:13).

If a user in site B (102: 11) changes a data portion of the data that was replicated (102: 18) and forwarded to site A (101: 16), these changes are forwarded to the local server (102: 14), where they are converted from the local BES (102: 12) native schema to the generic schema, which is common to all of the local servers (14). These changes are forwarded to other sites that requested the original data (e.g. 101: 16, 103: 23, 104: 25). In that way, every local server (14) contains selected, synchronized and updated production/engineering content, that was forwarded from other BESs that are connected to the same designing/manufacturing project's platform/network. Sites A, B and D may be used as designing sites, as they have their original local BESs systems, by which they can make changes in the engineering data. Site C, however, may be used, for example, as a production site, since it has the ability only to read the required engineering data, by using its local server (103: 14). Site E has a more limited access to engineering data in the repository- it may have only a general view of the data repository.

There are two kinds of data 'ownership'. The first one is a permanent ownership, meaning that different parts of a product are forwarded to different sites, and each site becomes the sole owner of that particular part, until the accomplishment of its designing. After the designing phase is completed, the corresponding designing site may send a replication of its design to a remotely located manufacturing site, in which case the designing site remains the owner of this data. This kind of ownership is likely to be the more common case. The second kind of data ownership is a temporal ownership, in which case one site starts designing a product's part and it forwards the partially designed part to another site in order to add more input into that part. This way the site, which temporarily accepts the part for further development, becomes the temporal owner of that part. This part designing may be moved/shifted back and forth between two, or more, sites. This part's ownership will shift from one site to other site(s) accordingly. Becoming a data owner in the first case, and shifting ownership in the second case is essential, in order to prevent two, or more, sites from working on the same part(s) simultaneously. In other words, only one site handles one, or more, part(s) at a given time.

Updating the local servers with the corresponding local changes, is carried out on a local basis, namely every user (11) may decide how often he would like to update his local server (14). If, for example, a user makes frequent and extensive changes in his data, he would likely update his local server frequently.

A user in site A may request for a specific data from site B (i.e. the data source), by either sending an e-mail to site B, by making a phone call, or by interacting with site B, through the network, and specifying the required data. The other side (e.g. a user in site B, which is the originator of the data) prepares the required data, determines the replication rule and launches ('pushes') the data to the requester.

One of the new features of the invention is its redundancy capability. If site D (104), for example, needs a data from site B (102), and site B is not available or operative, site D can still get the required data from site A (101: 16) or, alternatively, from site C (103: 23).

Users may connect themselves to the unified data repository even if they do not have a BES system (e.g. sites C and E). According to another preferred embodiment of the invention, there is a new portal (24 in site C) that is connected to a local server, through which a user (11) may be connected to the unified data repository. This portal allows the user only to read information. Such a site may be used as a manufacturing site, since the presence of the server (14) allows the user (11) to review engineering data (e.g. drawings). The absence of BES in site C makes it impossible for the user (11 in site C) to change data.

Site E (105) is the simplest case, where a user (11) has very limited access to data in the unified data repository.

Fig. IB schematically illustrates the general layout and functioning of the e-commerce collaboration system, according to a preferred embodiment of the invention. Several buyers and bidders' sites (i.e. A through D) are connected to the Internet (106 through 112). These sites are only for illustration purpose, and the network may comprise more participants and or users and/or sites. A site (e.g. sites A, B and C) may comprise a combination of a user (11), a local BES system (12), an adaptor (13), a local Exchange 'bolt-on' server (28) and a portal (24).

According to a preferred embodiment of the invention, an improved E- marketplace is created (113) by connecting a new central server; i.e. Exchange 'bolt-on' server (30), to a conventional Exchange engine (29), such as Ariba and Commerce-One. The local Exchange 'bolt-on' server (28) allows buyers (11 in 106, 107 and 108) to aggregate engineered product design (e.g. tables, drawings), by using their local BES (12), into their Request for Proposal (RFP). A potential bidder (109 to 112) may, on the ^■ other hand, read the RFP while referring to the relevant technical data, and send back his bid, which may include the aggregated engineered product design, as well as his own product designs. BESs (12) allow the corresponding users to load and process engineering data, while portals (24) allow only to read limited data. According to Fig. IB, a buyer (106: 11) enters the Exchange site (29) in order to create his RFP (prior art). However, according to a preferred embodiment of the invention, the buyer can attach to his RFP his engineering data. This phase is carried out by the buyer selecting the relevant data and forwarding it from his BES (106: 12) to the central Exchange server (113: 30). Forwarding said engineering data, from one site to a remotely located site, is described in relation to Fig. A. A potential bidder, bidder A (109: 11) for example, may enter the E-marketplace (113: 29) for searching for RFPs of interest to him. After finding such a RFP, the bidder (109: 11) may 'click' a button (not shown) in the Exchange site (113: 29), after which he will be redirected, without noticing it, to the central Exchange server (113: 30), which keeps/holds the buyer's relevant engineering data. At this stage the bidder has several options, one of which is to only view the required engineering data using the web portal. The second option is to replicate the engineering data to his BES (109: 12) for further evaluation, and for using that data as a basis for changes. The bidder may add his own design (by using his own BES) to the central Exchange server (113: 30) to be read by the buyer. Every one of said options are accessible, according to the invention, by 'clicking' the desired button in the Exchange site (not shown). Such buttons may be, for example, "View Product", "Load RFP's Engineering Data", "Create Your Own Design" etc.

The new central server (113: 30) is essential for a user who does not wish to install a local Exchange 'bolt-on' server (28), but still wishes to access an Exchange site (113). It should be noted that each local Exchange lDolt-on' server is essentially the same server as in Fig. 1A (14), except that it contains a special software package that cooperates with the central Exchange l>olt-on' server (113: 30). The adaptor (13) could be either a 'stand alone' apparatus, embedded in a local Exchange lDolt-on' server (14,28) or integrated into the local BES system (12).

Fig. 2 illustrates a general virtual unified content repository. The connections between the various local BES (PDM) users and the new portal users, are made by using the Internet infrastructure. Despite of the fact, that each user may have a different kind of BES system, the new servers network is designed to interface between each other, as if they were all working within the same organization and using the same platform.

Fig. 3 illustrates three car's manufacturing sites e.g., in Detroit, Fremont, and Stuttgart (prior art). All of the three sites share a common project (i.e. designing the same car). Each site deals with different aspects of the design process. Since every site has different types of legacy systems (e.g. PDM CSM/CAD in Detroit, IMAN in Fremont etc.), exchanging engineering data, and other manufacturing data, is impossible.

According to a preferred embodiment of the invention, the problems illustrated in Fig. 3 are solved according to the schema illustrated in Fig. 4. Referring to Fig. 4, each site is connected, through an adaptor (401, 402 and 403), to a common informational platform (404). This platform allows efficiently distributing tasks among manufacturing sites. This figure shows, for example, that the drive train parts (405) are manufactured in Detroit, the chassis parts of the car (406) in Fremont, and the fuselage parts (407) in Stuttgart. Nevertheless, various parts designing may be forwarded, according to the invention, from one site to other site(s). For example, a need may arise, to start designing the pistons in Detroit, and then to forward the partially designed pistons to Fremont, or to Stuttgart, for further development. The piston's original owner is Detroit. However, in a case where the pistons are forwarded to Fremont, Fremont becomes the new owner of the pistons. In other words, ownership of a part (or parts) is forwarded along with the part(s), in order to prevent from two, or more, sites to design the same part(s) simultaneously.

Fig. 5 illustrates the implementation of the solution that is described in Fig. 4. According to a preferred embodiment of the invention, each site (e.g. Detroit- 501, Fremont- 502 and Stuttgart- 503) has its own original (legacy) BES (501b, 502b and 503b, respectively), which is connected through an adaptor (not shown), to a local server (501a, 502a and 503a, respectively), that makes the necessary conversions for the unified data repository. Since all of the servers are linked together by a network (504), the servers can exchange data between themselves, as was explained before, thus creating a common informational platform that allows each manufacturing site to retrieve data from remote sites. Users, for example in Detroit (501c and 501d), can design their parts by using their original BES (501b) just like they did before, and if user 501c, for example, needs some engineering data from user 502c, he requests this data from Fremont site, by ways that were described before, and Fremont forwards the requested data to Detroit. If user 501c changes the data that originated from Fremont, he (i.e. user 501c) decides how often he would like to update his local server (501a). After having his server (501a) updated, these changes are forwarded to other servers in the network that essentially have the same data package.

Fig. 6 illustrates the solution of enhancing conventional Exchange (604) engine's functionality, according to a preferred embodiment of the invention. The servers (601 and 602) are deployed essentially the same way as described in Fig. 5 (501a, 502a etc.). Each local server is also connected, through an Exchange 'bolt-on' server (603), to Exchange sites (604), thus allowing buyers and sellers an access to engineering and other designing data (605, 606).

A buyer publishes, by using the conventional Exchange engine (604), a request for proposal (RFP) for manufacturing some product. The relevant engineering data is contained in the buyer's local BES system (605), and is annexed to the RFP. The seller 'reads' the RFP, by using the same Exchange engine (604), and he may return the buyer his bid, which may include, besides the original buyer's technical data, his own engineering data (606).

It should be noted, that according to the invention, the local servers in Fig. 5 (501a, 502a and 503a) and the local servers in Fig. 6 (601 and 602), are essentially the same servers, as the servers in Fig. 5 may comprise a special software package that allows them to communicate with the central Exchange )olt-on' server (Fig. 6: 603).

In conventional systems, if a buyer and a seller have different types of BES (605 and 606), such a seller can not retrieve engineering data from the buyer's data sources (605). However, according to the new invention, if the seller needs some sketches, drawings or any other relevant engineering data, he may retrieve data that was "published" by the buyer's BES and was forwarded by the buyer to the new Exchange 'bolt-on' server 603 (the bid package that is a part of the RFP), and optionally transfers it to his local BES (606). After the seller analyzes the RFP and the annexed engineering data, he may send his proposal to the buyer, exactly the same way, but with a reversed order. When a seller answers a buyer's RFP, according to the invention, his evaluated futuristic costs are based on near real-time updated data.

Advantages of the invention:

1. Collaboration — the new invention allows a seamless collaboration between engineering/designing departments, and also between engineering departments and manufacturing departments. The collaboration is seamlessly carried out whether the departments belong to one organization or to different organizations. Different kinds of departments, from different organizations/enterprises and sites, can collaborate as if they were located in one site and managed by one organization.

2. Reliability - eliminating single points of failure in the Enterprise wide data repository. This goal is achieved by using the 7^th layer of the Internet. This way, the virtual PCW is always active and running. Additionally, reliability is achieved through redundancy, since different sites essentially replicate selected data several times. This way, if a connection with one site is aborted, the required data may be obtained from other servers.

3. Integrity — maintaining completeness and accuracy of the product information.

4. Productivity - allowing rapid access to data by making it local.

5. Availability — allowing to work around the world, around the calendar and around the clock, namely seven days a week, twenty-four hours a day.

6. Balancing engineering and manufacturing resources.

7. Balancing network loads.

8. "Scalability'- the system offers essentially unlimited scalability, because the LDAP-based rephcation engine creates a network that has the ability to support a large number of sites. The large number of sites is a mandatory requirement for value-chain integration, involving many buyers, suppliers and sub-contractor. 9. The enhanced functionality of conventional Exchange engines offers the following features: a) A better support for intensive engineering data RFPs. b) Bi-directional product content/data integration between buyer's and bidder's BES/ERP systems. c) Supporting intensive engineering data RFPs. d) Dissolving the boundary between procurement and fulfillment into a seamless C-Commerce process.

The above examples and description have of course been provided only for the purpose of illustration, and are not intended to limit the invention in any way. As will be appreciated by the skilled person, the invention can be carried out in a great variety of ways, employing more than one technique from those described above, all without exceeding the scope of the invention.

Claims

A method for generating a virtual unified product content repository consisting of a plurality of different databases, each of which presented in a specific original schema, located at different sites that are connected through a data network, comprising: a) determining selected sites being access points to said data network, each of which being a source site of product content, from which a data package, selected from said product content, is sent to a remotely located destination site; b) at each source site, having permission to update the local product content stored therein: b.l) receiving a request for a data package from said remotely located site; b.2) activating predetermined rules for extracting and replicating data packages; b.3) generating a generic schema for exchanging different types of data packages between remotely located sites; b-4) whenever a transfer of a data package from site to site is required, converting on-the-fly the original schema of said data package to be sent from said source site into said generic schema; b.5) storing both said original schema and said generic schema of said data package; and b.6) forwarding said data package from said source site to said remotely located site, in said generic schema and over said data network, according to said predetermined rules; c) at said remotely located site, being the destination for said data package: c.l) receiving, from said source site, said data package in said generic schema; c.2) converting said data package from said generic schema into the local schema of said destination; c.3) storing both said local and generic schema of said data package; and c.4) affiliation of said data package represented in said local schema to the local database of said destination.

2. A method according to claim 1, wherein in each site, asynchronous storage, management and replication of data objects are carried out by using LDAP-based replication engine, being modified and extended to be orientated to manufacturing sites and product content, comprising the following steps: a) generating user-defined classes according to said product content; b) creating objects by using said user-defined classes; c) creating data objects by storing data in said objects; and d) selectively directing replications of said data objects to remotely located sites.

3. A method according to claim 1, wherein the data network is the Internet.

4. A method according to claim 1, wherein the data network is an intranet.

5. A method according to claim 1, wherein changes of data package(s) are made at one site at a time, said site having permission to update the local product content stored therein, thereby being the owner of said data package(s).

6. A method according to claim 5, wherein the ownership may be permanent, temporal, intermittent or transferred from one site to another site.

7. A method according to claim 5, wherein only changes are forwarded from a site, being an owner, to remotely located sites.

8. A method according to claim 1, further comprising allowing different sites to access replications of selected data packages over the data network.

9. A method according to claim 8, wherein whenever data package(s) can not be retrieved by a site, from a remotely located site, allowing said site to retrieve said data package(s) from at least another remotely located site.

10. A method according to claim 5, wherein corresponding data changes are stored in remotely located sites in response to said data changes that are forwarded by the owner of the data package(s).

11. A method according to claim 1, wherein access of a user that is connected to a site, is limited to browse/search operations in the unified data repository.

12. A method according to claim 1, wherein the determination and modifications of rules are carried out remotely through a web site.

13. A method according to claim 1, wherein the remote sites are associated with different enterprises.

14. A method according to claim 1, wherein at least one site is an E- marketplace, that comprises: a) an Exchange-engine, linked to a web site, said Exchange-engine being software for exchanging business-oriented data between different sites; and b) a server for exchanging product-oriented data between different sites.

15. A method according to claim 1, wherein the source site provides access to a buyer and the destination site provides access to a bidder.

16. A method according to claim 15, wherein the buyer of a product publishes, or forwards, a Request For Proposal (RFP) of said product to one or more bidders, by performing the following steps: a) allowing the buyer to enter the E-marketplace; b) creating said RFP in said E- marketplace; c) converting the engineering specifications of said product into a generic schema; d) replicating data represented in said generic schema to said E- marketplace; e) replicating changes made to the original ISP engineering data; f) allowing said bidder to enter said E-marketplace; g) replicating said RFP from the Exchange -engine to the site of said bidder; h) replicating said engineering specification, associated with said RFP; i) allowing said bidder to prepare said proposal according to the downloaded engineering specification; j) optionally, allowing said bidder to prepare a modified engineering specification; k) forwarding said proposal and said modified engineering specification to said E-marketplace; and 1) allowing said buyer to access said proposal and said modified engineering specification through said E-marketplace.

17. A method according to claim 11, wherein browsing through the unified product content repository is carried out through a remote portal by using a hyperbolic tree.

18. A data network for generating a virtual unified product content repository consisting of a plurality of different databases, each of which represented in a specific original schema, located at different sites that are connected through a data network, comprising: a) A plurality of nodes being access points to said data network, each of which being a source site of product content, from which a data package, selected from said product content, is sent to a remotely located destination site; b) at each source site, having permission to update the local product content stored therein, comprising: b.l) means for receiving a request for a data package from said remotely located site; b.2) means for activating predetermined rules for extracting and replicating data packages; b.3) means for generating a generic schema for exchanging different types of data packages between remotely located sites; b.4) means for converting a data package, being represented in original schema, into said generic schema; b.5) means for storing both said original schema and said generic schema of said data package; and b.6) means for forwarding said data package from said source site to said remotely located site, in said generic schema and over said data network, according to said predetermined rules; c) at said remotely located site, being the destination for said data package: c.l) means for receiving, from said source site, said data package in said generic schema; c.2) means for converting said data package from said generic schema into the local schema of said destination; c.3) means for storing both said local and generic schema of said data package; and c.4) means for affiliating said data package represented in said local schema to the local database of said destination.

19. A data network according to claim 18, in which at each site an asynchronous storage, management and replication of data objects are carried out by using LDAP-based replication engine, being extended and modified to Be orientated to manufacturing sites and product content, comprising: a) means for generating user-defined classes according to said product content; b) means for creating objects from said user-defined classes; c) means for creating data objects for storing data in said objects; and d) means for selectively directing replications of said data objects to remotely located sites.

20. A data network according to claim 18, being the Internet.

21. A data network according to claim 18, being an intranet.

22. A data network according to claim 18, in which changes of data package(s) are made at one site at a time, said site having permission to update the local product content stored therein, thereby being the owner of said data package(s).

23. A data network according to claim 22, in which the ownership may be permanent, temporal, intermittent or transferred from one site to another site.

24. A data network according to claim 22, in which only changes are forwarded from a site, being an owner, to remotely located sites.

25. A data network according to claim 18, in which access to replications of selected data packages is allowed for different sites over the data network.

26. A data network according to claim 25, in which whenever data package(s) can not be retrieved by a site, from a remotely located site, allowing said site to retrieve said data package(s) from at least another remotely located site.

27. A data network according to claim 22, in which data changes are stored in remotely located sites in response to said data changes that are forwarded by the owner of the data package(s).

28. A data network according to claim 18, in which access of a user that is . connected to a site, is limited to browse/search operations in the unified data repository.

29. A data network according to claim 18, in which the determination and modifications of rules are carried out remotely through a web site.

30. A data network according to claim 18, in which the remote sites are associated with different enterprises.

31. A data network according to claim 18, in which at least one site is an E- marketplace, that comprises: a) • an Exchange-engine, linked to a web site, said Exchange-engine being software for exchanging business-oriented data between different sites; and b) means for exchanging product-oriented data between different sites.

32. A data network according to claim 18, in which the source site provides access to a buyer and the destination site provides access to a bidder.

33. A data network according to claim 32, in which the buyer of a product publishes, or forwards, a Request For Proposal (RFP) of said product to one or more bidders, further comprising: a) means for allowing the buyer to enter the E-marketplace; b) means for creating said RFP in said E- marketplace; c) means for converting the engineering specifications of said product into a generic schema; d) means for replicating data represented in said generic schema to said E- marketplace; e) means for replicating changes made to the original ISP engineering data; f) means for allowing said bidder to enter said E-marketplace; g) means for replicating said RFP from the Exchange -engine to the site of said bidder; h) means for replicating said engineering specification, associated with said RFP; i) means for allowing said bidder to prepare said proposal according to the downloaded engineering specification; j) optionally, means for allowing said bidder to prepare a modified engineering specification; k) means for forwarding said proposal and said modified engineering specification to said E-marketplace; and 1) means for allowing said buyer to access said proposal ^"and said modified engineering specification through said E-marketplace.

34. A data network according to claim 28, in which browsing through the unified product content repository is carried out through a remote portal by using a hyperbolic tree.