Multi-hub connectivity in a system for collaborative planning

Adaptable multi-hub connectivity in a system for collaborative planning. Collaborative planning partners communicate using a set of local hubs. Each local hub is disposed for receiving and sending collaborative planning messages, caching and modifying collaborative planning data, and coordinating with one or more regional authorities regarding access to data. The local hubs communicate with client devices, other local hubs, and regional authorities. Regional authorities control access to collaborative planning data, thus controlling who owns that data, who is allowed to modify that data, and who is allowed to read or cache that data. Regional authorities partition the collaborative planning data, each one thus having a distinct subset of that data for which that particular regional authority has the final say. Regional authorities coordinate so that each one can obtain instructions for data not belonging to that particular regional authority.

BACKGROUND OF THE INVENTION

1. Field of the Invention

This invention relates to multi-hub connectivity in a system of collaborative planning.

2. Related Art

Supply chain management systems frequently require many different levels of connectivity. For example, suppliers must be able to communicate with manufacturers, manufacturers with suppliers, buyers with sellers, sellers with buyers, and so forth. In many instances, these connections require the synchronization of information and management of exceptions so as to provide information that will be relevant to a particular transaction.

A first problem associated with processing information in a system for supply chain management arises when trading partners and collaborators use different standards when placing orders or creating lists of anticipated needs. These standards may refer to a number of products (for example, 12 gross, 12 dozen or 144) or to a characteristic of the product (for example, 120 millifarads or 0.12 farads). The lack of a specific set of standards makes it difficult or impossible to negotiate electronically if the parties use different standards.

A second problem associated with processing information in a system for supply chain management arises when trading partners and collaborators create demand lists of products or services they desire using different supply chain management tools such as those provided by Manugistics, i2 and others. It is difficult to evaluate information on a demand list, especially with respect to other demand lists, if the lists were created with different tools.

A third problem associated with processing information in a system for supply chain management arises when different entities that share a common supplier have distinctly different processes with respect to placing orders or soliciting bids. It is difficult to take advantage of economies of scale when various entities use different business processes to conduct business with a common supplier.

A fourth problem involves scalability and recovery from errors. The hub and spoke model is not readily scalable. In addition to this problem, a system that relies upon a single centralized hub is vulnerable to loss of business if the hub become temporarily unavailable. Failure is problematic when there is only a single, centralized hub.

SUMMARY OF THE INVENTION

The invention provides a method and system for adaptable multi-hub connectivity in a system for collaborative planning. Collaborative planning partners (such as for example buyers, sellers, and negotiators), communicate with the system using a set of local hubs. Each local hub is disposed for receiving and sending collaborative planning messages, for caching and modifying collaborative planning data, and for coordinating with one or more regional authorities regarding access to collaborative planning data. The local hubs communicate with client devices (used by collaborative planning partners), other local hubs, and regional authorities. Regional authorities control access to collaborative planning data, thus directing local hubs who owns that data, who is allowed to modify that data, and who is allowed to read or cache that data. Regional authorities partition the set of all collaborative planning data maintained by the system, each particular regional authority thus having a distinct subset of that data for which that particular regional authority has the final say. Regional authorities coordinate with each other so that each particular regional authority can obtain instructions for data not belonging to that particular regional authority.

Each regional authority has the final say for data owned by collaborative planners in a logical region, possibly coinciding with a geographical region (such as for example Taiwan, Western Canada, or Hawaii). The number and positioning of regional authorities is established either (1) by the regional authorities themselves, in peer to peer cooperation, or (2) by a global eye having knowledge of system activity. In preferred embodiments, the number and positioning of regional authorities is intended to be optimized for both elements of local control (such as for example distributed computing capability, failover capability, and lower communication latency) and for elements of clear cooperation (such as for example ease of identifying the appropriate regional authority, and simplicity of synchronization). In preferred embodiments, the number and positioning of regional authorities is responsive to one or more factors known to the system and related to collaborative planning (such as for example a number of data elements active or expected to be active in a particular region, a number of modifications to data elements being performed or expected to be performed in a particular region, or a partition of the system into a set of geographic or quasi-geographic regions). As described herein, data elements are “expected to be” active or “expected to be” modified in response to known business methods used by all or some collaborative planners, known schedules of particular collaborative planners, or known business methods used by particular collaborative planners (or particular pairs or groups of collaborative planners).

For example, in one example embodiment, a first collaborative planner is located in (the mythical town of) Yksfonrews, while a second collaborative planner is located in (the mythical town of) Chelm. In the example, the first and second collaborative planners have a particular business process in which the first makes materials purchases on Mondays, the second makes commitments on Wednesdays (for delivery at later times), and the first approves those commitments on Fridays. In the example, the global eye, having knowledge of the particular business process, allocates a token for a regional authority to the local hub in Yksfonrews on Mondays, thus concentrating data synchronization in that location on those days when it is best used there, moves the token for the regional authority to the local hub in Chelm on Wednesdays, and moves the token for the regional authority back to the local hub in Yksfonrews on Fridays. In an extension of this example, the first collaborative planner might have offices in a set of locations Y1, Y2, Y3, and the like, while the second collaborative planner might have offices in a set of locations Ch1, Ch2, Ch3, and the like. In this extended example, the global eye, in response to this knowledge, moves a set of tokens for regional authorities to Y1, Y2, Y3, on Mondays and Fridays, and moves them back to Ch1, Ch2, Ch3, on Wednesdays.

In an aspect of the invention, each local hub includes an interface capable of receiving messages in a first collaborative planning protocol (such as for example RosettaNet, or for example from a product such as those offered by i2 or Manugistics). The interface may include one or more of: a software element disposed relatively local to the client device, an element disposed relatively local to the local hub, a software element disposed at a third location (such as for example at an intermediate device or at an ASP); the software element is capable of receiving messages in the first collaborative planning protocol and generating messages in a common collaborative planning protocol used by local hubs for communication among themselves. Thus, a client device only capable of communication in the first collaborative planning protocol can interact with a local hub and thus interact with the entire system. Similarly, each local hub includes an interface capable of sending messages in a second collaborative planning protocol (which may or may not be the same as the first collaborative planning protocol). The interface includes a software element capable of receiving messages in the common collaborative planning protocol and sending messages in the second collaborative planning protocol. Thus, a client device only capable of communication in the second collaborative planning protocol can interact with a local hub and thus interact with the entire system. Moreover, two separate client devices, a first only capable of communication in the first collaborative planning protocol and a second only capable of communication in the second collaborative planning protocol can interact with each other by means of one or more intermediate local hubs.

In an aspect of the invention, selected ones of the local hubs may be designated as private, that is, restricted to only selected types of traffic. In preferred embodiments, these selected types of traffic might be responsive to one or more of (1) the nature of the client device or the user employing that client device, such as for example a private local hub for the use of specified users or companies; (2) the nature of the data sought to be modified using that local hub, such as for example a private local hub for interacting with data from the second collaborative planner from Chelm noted above; (3) the nature of the markets sought to be accessed using that local hub, such as for example a private local hub for participating only in Dutch auctions; (4) the nature of the products sought to be accessed using that local hub, such as for example a private local hub for buying or selling only DRAM memories. Each regional authority might access or control only local hubs that are private, only local hubs that are public, or local hubs of either type. Moreover, each regional authority might direct particular local hubs to begin restricting their activities (thus becoming private), cease restricting their activities (thus becoming public), or change the restrictions on their activities (thus changing from a first to a second type of private local hub). In an example embodiment, a regional authority having knowledge of specific business processes between the first collaborative planner from Yksfonrews noted above and the second collaborative planner from Chelm noted above, might direct particular local hubs to change their status between private and public in response to aspects of that business process. For example, if a business process exception is noted between the first and the second collaborative planner, the regional authority might direct a particular local hub to restrict its activity to only those actions related to correcting or dealing with the exception.

In an aspect of the invention, an individual collaborative planner is associated, for each particular product associated with that collaborative planner, with a set of strategic suppliers and a set of first-tier suppliers, a set of second-tier suppliers, and so on. For each part of the particular product, the collaborative planner might obtain that part from its strategic suppliers or first-tier suppliers, that is, from those suppliers with whom the collaborative planner directly does business. Each of the first-tier suppliers provides that part to the collaborative planner, and in turn obtains sub-parts for that part from its own first-tier suppliers, which are therefore second-tier suppliers for the original collaborative planner. In preferred embodiments, the collaborative planner obtains each particular part from more than one such first-tier supplier; for example a buyer of DRAM memories might obtain 80% of its typical needs from the supplier in Yksfonrews and 20% of its typical needs from the supplier in Chelm. If an atypical circumstance occurs, such as for example the supplier in Yksfonrews is unable to supply that part, the collaborative planner might obtain all of its atypical needs from the supplier in Chelm. The nature of any particular supplier as a first-tier supplier, second-tier supplier, or the like, is responsive to both the selected individual collaborative planner and to the particular product, and might also be responsive to other market factors, such as the aggregate need for that product, the market pricing for that product, seasonality, or other factors.

In an aspect of the invention, selected local hubs might be capable of aggregating collaborative planning information from a plurality of collaborative planners, and of treating aggregated information in a unified manner. For example, where individual demand from a particular company is generated and transmitted to the system using more than one set of collaborative planning software (such as for example software from i2 or Manugistics), the local hub to which that demand is presented might be capable of aggregating that demand and presenting that demand from that particular company as if it were generated as a unified collaborative planning demand. The unified collaborative planning demand might be directed to a selected counter-party, or might be distributed among a plurality of counter-parties, as described above with regard to strategic suppliers and first-tier suppliers. Similarly, for example, where a particular company commits to supply parts from more than one subunit of the company, the local hub to which that commitment is presented might be capable of aggregating that commitment and presenting that commitment from that particular company as if it were a unified collaborative planning commitment.

INCORPORATED DISCLOSURES

Inventions described herein can be used in conjunction with inventions described in the following applications:application Ser. No. 09/823,888, filed Mar. 30, 2001, in the name of inventor Gregory Clark, titled Private Collaborative Planning in a Many to Many Hub,application Ser. No. 10/087,444, filed Mar. 1, 2002, in the name of inventor Erik Stuart, titled “On-Line Auction with Different Rules Applicable to Different Phases”,application Ser. No. 09/967,905, filed Sep. 28, 2001, in the name of inventor Gregory Clark, titled “Method for Business to Business Collaborative Viral Adoption”,application Ser. No. 09/967,907, filed Sep. 28, 2001, in the name of inventor Gregory Clark, titled “Securing Information in a Design Collaboration and Trading Partner Enviroment”, in the name of inventor Gregory Clark.

These applications are hereby incorporated by reference as if fully set forth herein. They are collectively referred to as the “incorporated disclosures”.

System Elements

FIG. 1shows a block diagram of a system of collaborative planning including a plurality of hubs.

A system100includes a plurality of local hubs120and a communication network130. These local hubs120are geographically distributed in locations in the world where clients are likely to be located. For example, the system100may include a first local hub120in Tokyo, a second local hub120in Bangalore, and a third local hub120in London. Each local hub120can be coupled so as to share information with other local hubs120.

Each local hub120in the plurality of local hubs120also includes a server122, a database124and software126.

All databases124in the system100include the same information. Each database124is periodically updated with respect to every other database124in a process known as synchronization. Each portion of each database124has an identifiable owner. The owner of any particular portion of a database124is generally a client of the local hub120who also has rights to modify the data in that portion. Generally, this is limited to buyers and sellers. However, in other embodiments, ownership of data is determined in response to who has a right to the goods or money described by the information in the database124.

In a preferred embodiment, control of the data in a local hub120is vested in a regional authority128. The regional authority128has control of all of the data owned by the entities in a particular region of the world. The regional authority128preferably includes a local hub120, but in other embodiments, may include a specialized device that is distinct in function from a local hub120. In a first example, a local hub120in Kuala Lumpur may be designated as the regional authority128for all the local hubs120in southeast Asia. In a second example, a local hub120in San Jose, Calif. may be designed as the regional authority128for local hubs120in northern California.

The regional authority128maintains data consistency by controlling who may write to the data in at least one database124(or portion of a database124), and by controlling who may perform any other activity that changes the state of the information in the database124. Since the regional authority128does not allow multiple parties to write to the same information at the same time, the information can be maintained globally consistent.

A local hub120is designated as a regional authority128in response to an amount of business activity in its (geographic or other) region of the world. At various times, this may reflect the number of local hubs120in a particular region, dates and time of doing business, behavior in various parts of a supply chain or other factors. In one embodiment, the amount of business activity is measured by looking to the number of transactions that are occurring. In other embodiments, the amount of business activity is measured by other metrics, such as a monetary value of the trade, the number of units being traded or some other variable for measuring business activity.

When the designation of the regional authority128is responsive to the amount of business activity, a different regional authority128might be designated if the level of business activity drops off. Possession of a logical token129indicates what device (that is, which local hub120) is the regional authority128at that time. This token129is exchanged between an outgoing regional authority128and an incoming regional authority128. This token129may include a set of computer program code, a set of access privileges, or other similar indicator of authority.

The plurality of local hubs120are also used to implement a failover configuration among the local hubs120. For example, if a local hub120in Los Angeles fails because of a local disaster (or due to overuse, or any other reason), clients can be transparently redirected to a different local hub in San Francisco. Redirection might be performed by a software element in a client device, by a software element in a redirecting router associated with the local hub120, or otherwise. Thus, there is no break in service or loss of data, due to synchronization to reflect activity at the local hubs120.

The communication network130is disposed for communicating data between (1) client devices under the control of trading partners and the local hubs120, and (2) among different local hubs120. In a preferred embodiment, the communication network130includes a packet switched network such as the Internet, as well as (in conjunction with or instead of) an intranet, an enterprise network, an extranet, a virtual private network, a virtual switched network, or in one preferred embodiment in conjunction with a set of dedicated communication links. In alternative embodiments, the communication network130may include any other set of communication links that couple the system for collaborative planning110with trading partners and collaborators.

Example System

FIG. 2shows an example of a system of collaborative planning and supply chain management including a plurality of hubs.

A system200includes a set of local hubs120, a first set of information flows210between the local hubs120and clients, a second set of information flows220between the local hubs120and each other, and a regional authority128.

The set of local hubs120includes a local hub120in Korea, a local hub120in Japan, and a local hub120in the United States.

The first set of information flows210includes data that is exchanged between the local hubs120and clients that are geographically situated so as to be relatively close to that particular local hub120. For example, as shown inFIG. 2, a first set of information flows210includes information that is shared between clients in the United States and the local hub120in the United State. Another first set of information flows210includes information that is shared between clients in Japan and the local hub120in Japan. Still another first set of information flows210includes information that is shared between clients in Korea and the local hub120in Korea.

The second set of information flows220includes data that is exchanged between the local hubs120and each other. As shown inFIG. 2, information flow220includes information that is shared between the local hub120in Japan and the local hub120in the United States and the local hub120in Korea. This second set of information flows220includes information that is shared between the local hub120in the United States and the local hub120in Japan and the local hub120in Korea. Similarly, the local hub120in Korea includes information that is shared between the local hub120in the United States and the local hub120in Japan.

The designated regional authority128in the system200is the local hub in Japan. However, since the regional authority128is designated on the basis of local business activity, the local hub120in the United States or the local hub120in Korea could alternatively be designated as the regional authority128, or could in addition be designated as an additional regional authority128(in which case the regional authorities128would partition their authority so that no local hub120is subject to more than one regional authority128).

A failover configuration can be implemented among the local hubs120. For example, if a first local hub120in Japan fails because of a local disaster, Japanese clients can be transparently redirected to a second local hub120in Korea. There is no break in service or loss of data; all local hubs120have been synchronized to reflect local activity at each local hub120.

Method of Operation

A method300includes a set of flow points and process steps as described herein.

The method300is performed by the system100. Although the method200is described serially, the steps of the method300can be performed by separate elements in conjunction or parallel, whether asynchronously, in a pipelined manner, or otherwise. There is no particular requirement that the method300be performed in the same order in which this description lists the steps, except where so indicated.

At a flow point310, the system100is ready to begin performing a method300. At the outset, a first local hub120is designated as the regional authority128for a plurality of other local hubs120. The regional authority possesses a token129. The token129allows the regional authority128to control who may write to a database124.

At a step315, a pattern of business activity within the system100changes so that peak business activity is no longer occurring in a region relatively proximate to the first local hub120. This shift in activity is detected by at least one local hub120, or by the regional authority128, when information is synchronized. A second local hub120corresponding to the peak business activity is identified.

At a step320, a token129is sent from the regional authority128to the local hub120that is most proximate (geographically or otherwise, preferably geographically with respect to location weighted by communication topology) to the location of peak business activity. The local hub120that receives the token becomes the new regional authority128. The former regional authority128no longer has the authority to synchronize data among the other local hubs120, and becomes an ordinary local hub120.

At a flow point325, the new regional authority128is ready to synchronize data on behalf of the system100. Steps315and320are repeated whenever there is a significant shift in business activity or in any other parameter such as may be used to identify the regional authority128.

ALTERNATIVE EMBODIMENTS

Although preferred embodiments are disclosed herein, many variations are possible which remain within the concept, scope and spirit of the invention; these variations would be clear to those skilled in the art after perusal of this application.