|Publication number||US7085286 B2|
|Application number||US 09/896,201|
|Publication date||1 Aug 2006|
|Filing date||29 Jun 2001|
|Priority date||29 Jun 2001|
|Also published as||US20030002526|
|Publication number||09896201, 896201, US 7085286 B2, US 7085286B2, US-B2-7085286, US7085286 B2, US7085286B2|
|Inventors||Daniel M. Dias, Stewart L. Palmer, Hidayatullah Shaikh, James Thomas Rayfield|
|Original Assignee||International Business Machines Corporation|
|Export Citation||BiBTeX, EndNote, RefMan|
|Patent Citations (7), Referenced by (14), Classifications (10), Legal Events (6)|
|External Links: USPTO, USPTO Assignment, Espacenet|
The present invention relates generally to electronic commerce systems, and more particularly relates to a business-to-business protocol exchange for connecting multiple electronic marketplaces, buyers and/or suppliers to each other using different communications protocols.
With the increasing popularity of the Internet (e.g., World Wide Web), businesses, including commercial enterprises, government and academia, can communicate with one another, for example, through electronic procurement (e-procurement) systems or electronic marketplaces (e-marketplaces). Many such marketplaces and/or trading networks have emerged and are commercially available, for example, WebSphere Commerce Suite Marketplace Edition (trademark of IBM Corporation), Ariba Buyer and Ariba Marketplace (trademarks of Ariba, Inc.), Market Set (trademark of SAPMarkets Inc.), and ConnectTrade (trademark of Metiom, Inc.).
Since there is no standard communication protocol which is used for all procurement systems, each of the conventional procurement systems and marketplaces may use different interaction protocols to communicate between buyers, the procurement system or marketplace, and suppliers for browsing catalogs, creating quotes or shopping carts, sending orders, etc. For example, Ariba has defined a punch-out process with messages defined in a Commerce XML (cXML) protocol, Metiom uses an Open Buying on the Internet (OBI) protocol, mySAP utilizes a protocol known as Open Catalog Interface (OCI), and other vendors have defined additional protocols. These protocols are stateful, meaning that data sent in one of the messages between the entities is used in a subsequent interchange between the entities. More specifically, the communications between the entities typically occurs in a long running conversation comprised of a sequence of messages, with the information contained in one message in the conversation being used in the content of later messages.
Presently, in a conventional e-commerce architecture buyers using a given procurement system or marketplace are limited to transacting with suppliers which implement the same protocol as that specified by the given procurement system or marketplace. Therefore, there is a need for a framework which enables buyers utilizing a procurement system or marketplace employing one (stateful) protocol to transact with a supplier or marketplace using another (stateful) protocol.
The present invention provides techniques for enabling buyers utilizing a procurement system or marketplace employing one stateful protocol to communicate with suppliers using another stateful protocol. The invention includes a business-to-business (B2B) protocol exchange, operatively connected to one or more buyers and suppliers, for translating a message received in one communication protocol into a translated message using one or more different communication protocols, as required by a predetermined recipient of the translated message. The translation of subsequent messages between a buyer and seller may depend on state information provided by previous messages of a conversation between the buyer and the seller.
In one illustrative aspect of the invention, a method of communicating between two business entities, each of the business entities utilizing a different communication protocol, wherein a business conversation is established between the entities, includes providing a B2B protocol exchange for facilitating communications between the business entities, the protocol exchange being operatively connected to the business entities. The method further includes receiving, at the B2B protocol exchange, a message from one of the business entities in a first communication protocol, translating the received message in the first communication protocol into a translated message in a second protocol used by another of the business entities, and sending the translated message to the other business entity.
In another illustrative aspect of the invention, a B2B system is provided which includes a B2B protocol exchange connected to one or more suppliers and at least one of a buyer and a procurement system. The protocol exchange of the present invention enables the buyer and/or procurement system which is communicating in a first protocol to operatively transact with the suppliers which are communicating in a different protocol by translating messages from one another into the protocol used by the particular system.
These and other objects, features and advantages of the present invention will become apparent from the following detailed description of illustrative embodiments thereof, which is to be read in connection with the accompanying drawings.
As previously stated, one difficulty with a conventional B2B framework is that there are a number of different buyer-to-supplier protocols presently being used (e.g., Ariba punch-out, Metiom OBI, etc.) or contemplated. Many buyer systems and supplier systems support only a single protocol. Consequently, a buyer system and supplier system that do not support the same protocol cannot communicate with one another using the conventional B2B framework. Although some buyer systems and/or supplier systems may support multiple protocols (e.g., Supplier 2 in
The present invention will be described herein in the context of a data processing system embodying an illustrative B2B framework for communicating between buyer systems and supplier systems that may be incompatible (i.e., those systems that do not support a common B2B interaction protocol or multiple protocols). It is to be appreciated, however, that the techniques described herein may be applied generally to a wide variety of system configurations for facilitating transactions between buyers and suppliers using disparate procurement systems and marketplaces. The term “network” as used herein is intended to refer generally to any type of communication medium or channel for conveying transmitted information, including a wireless communication link, such as, but not limited to, radio frequency, satellite, microwave, etc., and a dedicated communication connection, such as, but not limited to, telephone, cable, fiber optic, etc.
The B2B framework 200 also includes one or more supplier systems 228, 230, 232. Some of the supplier systems in the B2B framework may support multiple protocols (e.g., supplier system 230), in which case such supplier system can be connected directly to a buyer system communicating using the particular protocol(s) that are supported, for example, via network 220, 222. Other supplier systems (e.g., supplier systems 228, 232), however, which do not support the same protocol as a particular buyer system (e.g., buyer system 212, 210, respectively), cannot be directly connected.
Rather than the buyer systems being directly connected to supplier systems, as in the conventional framework, the B2B framework 200 of the present invention includes a B2B protocol exchange 214. A primary function of the protocol exchange 214 is to operatively translate messages from one protocol (e.g., protocol A) to another protocol (e.g., protocol B). The existence of the protocol exchange 214 is preferably transparent to either the buyer system(s) or the supplier system(s). On the inbound side, which may be defined as data flow from a buyer system (e.g., 210) to the protocol exchange 214, for example, via network 216, 218, the protocol exchange 214 preferably functions as a supplier system which communicates using the same protocol as the buyer system (e.g., protocol A). Likewise, on the outbound side, which may be defined as data flow from the protocol exchange 214 to a supplier system (e.g., 232), for example, via network 224, 226, the protocol exchange 214 functions as a buyer system which communicates using the same protocol as the supplier system (e.g., protocol B). Thus, no modifications to either the buyer system or supplier system protocol are required to use the B2B protocol exchange 214.
The protocol exchange 214 preferably maintains conversational state at least in part to perform the protocol translation function. Some message flows contain references to data contained in previous message flows. For example, a purchase order message may contain a “cookie” which refers to a previous exchange of authentication information (e.g., a user id and password). Without maintaining conversation state, the protocol exchange may not have sufficient context to translate subsequent messages. In addition, as will be described herein below, some protocols require replacement or introduction of information sent in an earlier message of a conversation to be used in translating and in the content of a subsequent message. Furthermore, the protocol exchange 214 may receive asynchronous messages relating to a conversation.
The B2B protocol exchange 214 will be described herein in further detail in the context of conversational B2B interactions for punchout processes used, for example, in B2B network catalog operations. Those skilled in the art will readily appreciate that the methods described for the B2B exchange can be used for other B2B transactions as well as for general stateful conversational processes.
Referring now to
In the conventional B2B architecture 300, message flow starts with the buyer 302 logging on to the procurement system 304 during step 312. During this step, the buyer 302 selects a desired network supplier 308 at whose website he wants to do his shopping. The procurement system 304 then looks up the catalog Universal Resource Locator (URL) address of the supplier 308 from its repository 310 along with the necessary security credentials. Procurement systems, like Ariba Buyer, obtain the catalog URL address by sending out a catalog operations request to the supplier 308 during step 316, along with the necessary security credentials and cookies. The supplier 308 then responds with a message containing the catalog URL address during step 318. During step 320, the buyer 302 is logged on to the supplier 308 and can do his shopping. The buyer is generally able to store desired items for purchase in a shopping cart or basket. When the buyer is ready to check out, the contents of his shopping cart are transferred to the procurement system 304 during step 322, where a purchase order can be generated and sent back to the supplier 308.
With reference now to
As stated above with regard to
With continued reference to
The supplier 408 responds to the catalog operations request by sending a catalog operations response containing, for example, the catalog URL address using the second protocol to the protocol exchange 406 during step 420. A translated catalog operations response is then sent to the buyer 402 during step 418. In this response, the supplier 408 preferably provides enough information for the buyer 402 (e.g., via a browser) to be able to log directly into the supplier 408. During step 422, the buyer 402 is logged into the supplier 408 and can do his shopping. The buyer is generally able to store desired items for purchase in a shopping cart or basket. The shopping basket employed by the present invention may be consistent with a conventional shopping cart. It is to be appreciated that the shopping session preferably occurs directly from the buyer's browser to the supplier, and only the shopping basket is returned to the protocol exchange 406 for translation. When the buyer is ready to check out, the contents of the shopping basket are transferred to the protocol exchange 406, in the second protocol, during step 426. The shopping basket contents are then translated into the first protocol and sent to the procurement system 404 during step 424, where a purchase order may be generated and sent back to the supplier.
By way of example only,
After receiving the request, the protocol exchange preferably determines, at block 504, whether or not a conversation identifier needs to be generated. If either the postback URL or the buyer identity have been supplied with the request and the buyer has not supplied a conversation identifier, the protocol exchange preferably generates and records a conversation identifier at block 506 to be returned with the message. The procedures of block 506 may be omitted if the conversation identifier is supplied by the buyer or procurement system, or if a conversation identifier is not used. It is to be appreciated that depending upon the particular protocol employed, the conversation identifier can be generated by either the buyer side or the supplier side. For protocols that do not use conversation identifiers at all, the protocol exchange preferably creates and records the conversation identifier (block 506) and transparently inserts it into the postback URL. The conversation identifier, if present, will be used by the protocol exchange in a subsequent method, as will be described below.
In accordance with the present invention, the protocol exchange uses the information included in the request to determine the location of the desired supplier catalog in block 508. In order to locate the supplier catalog, the protocol exchange may be configured with mapping information which maps between buyers in different protocol domains and suppliers in different protocol domains. In this specific case, the buyer may provide a target supplier in an incoming protocol domain and the protocol exchange converts this to a target supplier identification in an outgoing protocol domain. Once the location of the desired supplier catalog is found, the protocol exchange returns the catalog location and the conversation identifier, if used, by way of a network catalog operations response to the buyer in block 510.
In block 606, the protocol exchange preferably determines whether the conversation identifier is present. If the conversation identifier is present, the protocol exchange can look up identification information in block 608 that was previously supplied (e.g., in block 502 of
If the identification information is found in block 610, the protocol exchange preferably attempts to identify the buyer system in block 616. It is to be appreciated that blocks 610 and 616 attempt to identify the buyer system. Either the buyer identification is provided in the request or the request includes a conversation identifier which refers to buyer identification provided in the same conversation (e.g., with the same conversation identifier). The buyer identification is preferably a user id or other identifier (e.g., data universal numbering system (DUNS) number), together with a password or other authentication information. If the buyer system cannot be identified, an error response is returned to the buyer system in block 618 and the procedure 600 is terminated. If the buyer system has been identified, the protocol exchange saves the postback URL (e.g., in memory included in the protocol exchange) in block 622. The postback URL is preferably used by the protocol exchange in one or more subsequent operations (e.g., block 704 in
With continued reference to
After determining the target information, the protocol exchange preferably determines, in block 626, whether or not a conversation identifier is already present, or whether the protocol exchange must generate the conversation identifier. If no conversation identifier is present, the protocol exchange generates the conversation identifier in block 628. As previously stated, the conversation identifier is preferably used to identify a particular conversation when the shopping cart is returned (e.g., in block 702 in
With reference now to
In block 630, if the target protocol does not require that a separate request be made to the supplier system, the protocol exchange looks up the catalog location in block 642. The catalog location information preferably resides in a database which is internal to the protocol exchange, although the present invention similarly contemplates that the catalog location information may be obtained from an external information source as well. If the protocol exchange cannot obtain the catalog location, as determined in block 644, either because the information is not available or is otherwise invalid, an error response is returned to the buyer system in block 650 and the procedure 600 then terminates at 652.
If the protocol exchange obtains the catalog location in block 644 or if no error response is received from the supplier system in block 636, a complete catalog URL, including the identification of the postback URL, is preferably created in block 646. The postback URL identifies a receiving point within the protocol exchange. In block 648, the protocol exchange then sends a redirect back to the buyer system browser to direct it to the supplier system catalog.
After receiving the shopping cart from the supplier system, the protocol exchange preferably looks up the conversation identifier in the protocol exchange database in block 704. Associated with the conversation identifier is information relating to the conversation, including, for example, the protocol into which the shopping cart is to be translated as well as the original postback URL (e.g., saved in block 622 of
It is to be appreciated that some messages in a conversation may require interaction with third parties, such as, for example, authentication servers, in order to perform a required transformation. Message responses from the supplier to the buyer in protocol B may be synchronous or asynchronous with respect to the corresponding message request(s) from the buyer to supplier. These message responses in protocol B may be transformed using data provided in a prior message of the conversation, into one or more messages of protocol A, which are sent either directly to the buyer, or to the buyer via the procurement system.
Referring now to
A determination as to whether or not the buyer system identifier is found is made in block 806. Block 806 checks to see if the buyer system is configured in a local database in the protocol exchange. The configuration information for the buyer, which is preferably stored in the local database in the protocol exchange, specifies, for example, that the target protocol is Ariba and supplies the URL of the Ariba purchasing system. If the buyer system identifier is not found, an error response is sent to the mySAP buyer system in block 808 (which is consistent with block 618 in
In block 814, the protocol exchange sends a Commerce XML (cXML) protocol punchout setup request to the Ariba supplier system. The punchout setup request includes, for example, the identity of the buyer system, the postback URL, and the conversation identifier, which in an Ariba cXML protocol is referred to as a buyer cookie. The protocol exchange receives a punchout setup response from the Ariba supplier system in block 816. The punchout setup response preferably includes the location of the supplier catalog, in a manner consistent with block 634 in
With continued reference to
In block 824, the conversation identifier (e.g., generated in block 812) is preferably recorded in a local database in the protocol exchange for use in a subsequent operation. This record includes the conversation identifier, the identity of the buyer system, and the original postback URL from the initial mySAP logon request. The protocol exchange then creates, in block 826, a complete catalog URL, including the location of the supplier catalog, the conversation identifier and a postback URL that points to a location in the protocol exchange that is configured to receive a shopping cart in Ariba cXML format, in a manner consistent with that of block 646 in
After receiving the shopping cart, the conversation identifier is looked up in a database or similar storage medium in the protocol exchange. As previously stated, associated with the conversation identifier is information about the conversation, including the target protocol into which the shopping cart is to be translated as well as the original postback URL (e.g., saved in block 824 of
While a B2B framework employing the protocol exchange in accordance with the present invention is described herein with reference to a specific example of buyer and supplier protocols, those skilled in the art will readily appreciate that the B2B protocol exchange described herein can be used to map general stateful conversational processes as well.
Referring now to
With continued reference to
Accordingly, an application program, or software components thereof, including instructions or code for performing the methodologies of the invention, as described herein, may be stored in one or more of the associated memory devices (e.g., ROM, fixed or removable memory) and/or computer readable media and, when ready to be utilized, loaded in whole or in part (e.g., into RAM) and executed by a processor. In any case, it is to be appreciated that the B2B protocol exchange may be implemented in various forms of hardware, software, or combinations thereof.
It is to be appreciated that while the present invention has been described herein in the context of a data processing system, the methodologies of the present invention are capable of being distributed in the form of computer readable media, and that the present invention applies equally regardless of the particular type of signal-bearing media actually used to carry out the distribution. The term “computer readable media” as used herein is intended to include recordable-type media, such as, for example, a floppy disk, a hard disk drive, RAM, compact disk (CD) ROM, digital video disk (DVD) ROM, etc., and transmission-type media, such as digital and analog communication links, wired or wireless communication links using transmission forms, such as, for example, radio frequency and optical transmissions, etc. The computer readable media may take the form of coded formats that are decoded for use in a particular data processing system.
Although illustrative embodiments of the present invention have been described herein with reference to the accompanying drawings, it is to be understood that the invention is not limited to those precise embodiments, and that various other changes and modifications may be effected therein by one skilled in the art without departing from the scope or spirit of the invention.
|Cited Patent||Filing date||Publication date||Applicant||Title|
|US6757731 *||6 Jan 2000||29 Jun 2004||Nortel Networks Limited||Apparatus and method for interfacing multiple protocol stacks in a communication network|
|US6772413 *||8 Dec 2000||3 Aug 2004||Datapower Technology, Inc.||Method and apparatus of data exchange using runtime code generator and translator|
|US20010056504 *||26 Feb 2001||27 Dec 2001||Eugene Kuznetsov||Method and apparatus of data exchange using runtime code generator and translator|
|US20020120776 *||23 Dec 2000||29 Aug 2002||Eggebraaten Thomas John||Computer system, method, and business method for automating business-to-business communications|
|US20020147823 *||28 Feb 2001||10 Oct 2002||Eland Technologies Inc.||Computer network system|
|US20020165975 *||7 May 2001||7 Nov 2002||Michael Abbott||Dynamic mapping of communication protocols|
|US20020174034 *||17 May 2001||21 Nov 2002||International Business Machines Corporation||Method and apparatus for a distributed web commerce system|
|Citing Patent||Filing date||Publication date||Applicant||Title|
|US7814218 *||10 Sep 2003||12 Oct 2010||Astute Networks, Inc.||Multi-protocol and multi-format stateful processing|
|US8015303||2 Aug 2002||6 Sep 2011||Astute Networks Inc.||High data rate stateful protocol processing|
|US8151278||11 Sep 2008||3 Apr 2012||Astute Networks, Inc.||System and method for timer management in a stateful protocol processing system|
|US8473316 *||4 Jun 2010||25 Jun 2013||Amazon Technologies, Inc.||System and method for order processing state management|
|US8489436 *||4 Jun 2010||16 Jul 2013||Amazon Technologies, Inc.||System and method for an order handling data model with item-level granularity|
|US8495245 *||8 Jan 2009||23 Jul 2013||Alcatel Lucent||Connectivity, adjacencies and adaptation functions|
|US8751583||7 Feb 2007||10 Jun 2014||Acxess Inc.||System and method for providing business continuity through secure e-mail|
|US8800020||14 Feb 2014||5 Aug 2014||Elemica, Inc.||Method and apparatus for translation of business messages|
|US8904528||1 Oct 2013||2 Dec 2014||Elemica, Inc.||Method and apparatus for translation of business messages|
|US9049187 *||12 Apr 2013||2 Jun 2015||Alcatel Lucent||Connectivity, adjacencies and adaptation functions|
|US20050027559 *||8 Sep 2004||3 Feb 2005||Marathon Ashland Petroleum L.L.C.||Generic framework for applying object-oriented models to multi-tiered enterprise applications|
|US20050108316 *||18 Nov 2003||19 May 2005||Sbc Knowledge Ventures, L.P.||Methods and systems for organizing related communications|
|US20100174814 *||8 Jan 2009||8 Jul 2010||Alcatel-Lucent||Connectivity, adjacencies and adaptation functions|
|US20130227169 *||12 Apr 2013||29 Aug 2013||Peter Busschbach||Connectivity, adjacencies and adaptation functions|
|U.S. Classification||370/466, 709/230|
|International Classification||G06Q30/06, H04J3/16, H04L29/06|
|Cooperative Classification||H04L69/08, H04L29/06, G06Q30/06|
|European Classification||G06Q30/06, H04L29/06|
|29 Aug 2001||AS||Assignment|
Owner name: INTERNATIONAL BUSINESS MACHINES CORPORATION, NEW Y
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:DIAS, DANIEL M.;PALMER, STEWART L.;SHAIKH, HIDAYATULLAH;AND OTHERS;REEL/FRAME:012139/0820;SIGNING DATES FROM 20010718 TO 20010726
|17 Oct 2006||CC||Certificate of correction|
|21 Jan 2010||FPAY||Fee payment|
Year of fee payment: 4
|14 Mar 2014||REMI||Maintenance fee reminder mailed|
|11 Jul 2014||SULP||Surcharge for late payment|
Year of fee payment: 7
|11 Jul 2014||FPAY||Fee payment|
Year of fee payment: 8