Electronic commerce community networks and intra/inter community secure routing implementation

• US 20040015596A1
• Filed: 07/19/2002
• Published: 01/22/2004
• Est. Priority Date: 07/19/2002
• Status: Active Grant

• Current Assignee: Perfect Commerce Holdings, LLC
• Original Assignee: Commerce One Operations Incorporated (Proactis Holdings Plc)
• Inventors: Sanfilippo, Joseph, Kasi, Jayaram Rajan, Sapuram, Raghunath, Klaus, Todd Christopher, Crall, Christopher
• Granted Patent: US 7,200,674 B2
• Time in Patent Office: Days
• US Class Current: 709/230
• CPC Class Codes: G06Q 10/10 Office automation; Time management

Abstract

The present invention includes devices and methods to establish networks of communities, route documents among communities having dissimilar interfaces and do so in a trusted and trustworthy manner. Particular aspects of the present invention are described in the claims, specification and drawings.

Claims

1. An electronic registry of connectors belonging to a community, including at least one entry corresponding to a connector belonging to the community, the entry comprising:

an identity of the connector;

one or more particular transport/envelope protocols that the connector supports;

capabilities of the connector to

communicate peer-to-peer with other connectors;

translate among transport/envelope protocols;

rules for the particular transport/envelope protocols that determine routing of an electronic commerce document, including inbound and outbound links with other connectors.

2. The electronic registry of claim 1, wherein the identity of the connector includes its name, description and URI.

3. The electronic registry of claim 1, wherein the particular transport/envelope protocols include:

an envelope protocol identifier;

a transport protocol identifier; and

a connector address for the transport protocol.

4. The electronic registry of claim 1, wherein the translate capabilities of the connector include capabilities to:

translate from one envelope protocol to another; and

translate, given a specific envelope protocol, from one transport protocol to another.

5. The electronic registry of claim 3, wherein the translate capabilities of the connector include capabilities to:

translate from one envelope protocol to another; and

translate, given a specific envelope protocol, from one transport protocol to another.

6. The electronic registry of claim 1, wherein the capability of the connector to communicate peer-to-peer is indicated by absence of an outbound link for the particular transport/envelope protocol.

7. The electronic registry of claim 3, wherein the capability of the connector to communicate peer-to-peer is indicated by absence of an outbound link for the particular transport/envelope protocol.

8. The electronic registry of claim 1, wherein the capabilities further include capabilities to act as a central connector, without requiring explicit inbound or outbound links, wherein the central connector includes at least one capability to translate among transport/envelope protocols.

9. The electronic registry of claim 1, wherein the capabilities further include capabilities to act as an external connector, visible to other communities and able to communicate with other external connectors associated with the other communities.

10. The electronic registry of claim 9, wherein the capabilities further include capabilities to act as an external connector, visible to other communities and able to communicate with other external connectors associated with the other communities.

11. An electronic registry of cross-community routings, a source-to-destination community routing including:

an address of a registry service corresponding to the destination community;

an external connector in the destination community; and

one or more transport/envelope protocols supported by the source-to-destination community routing of an electronic commerce document.

12. The electronic registry of claim 11, wherein the external connector comprises a connector address for the transport/envelope protocol and a connector URI.

13. The electronic registry of claim 11, further including an identification of an intermediary community through which the electronic commerce document is routed to reach the destination community.

14. A method of computing a route for sending an electronic commerce document from a source to a destination, compliant with routing rules expressed in a graph of parent-child relationships among connectors, including:

mapping the source and destination to connectors;

beginning at the source and destination connectors, building partial path lists of connectors, including

traversing from a child connector to one or more parent connectors;

considering alternative transport/envelope protocols available to communicate from the child connector to the parent connectors and treating available transport/envelope protocols as separate partial paths;

completing the partial path list of connectors for a particular transport/envelope protocol upon reaching a connector that has no parent connector available to communicate using the particular transport/envelope protocol;

linking respective source and destination partial path lists, alternatively

linking through a shared connector in the respective partial path lists, when the shared connector uses the same transport/envelope protocol in the respective partial path lists or when the shared connector has an ability to translate between transport/envelope protocols in the respective partial path lists;

linking between similar connectors in the respective partial path lists when the similar connectors support the same transport/envelop protocol.

15. The method of claim 14, wherein linking further alternatively includes linking to one or more central connectors that are not parent connectors, the central connectors having an ability to translate between transport/envelop protocols in the respective partial path lists.

16. A method of computing a route for sending an electronic commerce document from a source to a destination, compliant with routing rules expressed in a graph of parent-child relationships among connectors, including:

mapping the source and destination to connectors;

beginning at the source and destination connectors, building partial path lists of connectors, including

traversing from a child connector to one or more parent connectors;

considering alternative transport/envelope protocols available to communicate from the child connector to the parent connectors and treating available transport/envelope protocols as separate partial paths;

completing the partial path list of connectors for a particular transport/envelope protocol upon reaching a connector that communicates peer-to-peer with other connectors for the particular transport/envelope protocol;

linking respective source and destination partial path lists, alternatively

linking through a shared connector in the respective partial path lists, when the shared connector uses the same transport/envelope protocol in the respective partial path lists or when the shared connector has an ability to translate between transport/envelope protocols in the respective partial path lists;

linking between similar connectors in the respective partial path lists when the similar connectors support the same transport/envelop protocol.

17. The method of claim 16, wherein linking further alternatively includes linking to one or more central connectors that are not parent connectors, the central connectors having an ability to translate between transport/envelop protocols in the respective partial path lists.

18. A method of computing a route to send an electronic commerce document from a source to a destination in different communities, including:

mapping the source and destination to connectors within respective communities;

identifying one or more shared community networks in which the respective communities are registered and linking between similar external ports of the respective communities when the similar external ports use the same transport/envelope protocol;

computing intra-community routes within the respective communities from the source and destination connectors to respective external ports; and

specifying a route of intra-community connectors and external ports spanning from the source to the destination.

19. The method of claim 18, wherein identifying further includes:

accessing a local registry to determine if a direct route is known from the source community to the destination community; and

, if not,

accessing one or more global registries for one or more community networks available to the source community and determining if a route is known through the community network from the source community to the destination community.

20. The method of claim 18, wherein identifying alternatively includes identifying one or more entities available to the respective communities that provide translation services and linking from the respective external ports through the translation entities.

21. The method of claim 18, wherein identifying alternatively includes identifying one or more intermediary communities that belong to community networks available the respective source and destination communities and linking from external ports of the respective source and destination communities through the intermediary communities.

22. The method of claim 21, wherein the intermediary communities further provide translation services from a source transport/envelope protocol to a destination transport/envelope protocol.

23. A method to securely transmit an electronic commerce document from a source to a destination, between source and destination communities, comprising:

determining a security policy mutually acceptable to the source and destination communities;

authenticating the source to a SAML service;

receiving a SAML assertion from the SAML service;

packaging the SAML assertion and an electronic commerce document according to an envelope protocol;

routing the envelope to the destination through trusted connectors;

sending the envelope via the route to the destination.

24. The method of claim 23, further including:

receiving the envelope from the source;

comparing an electronic signature of the SAML assertion to an electronic signature for the source community that is registered with the destination community; and

determining from a destination community registry that the source community is trusted to send electronic commerce documents.

25. The method of claim 23, wherein the routing and sending steps further include:

routing the envelope through trusted connectors in at least one intermediary community;

receiving the envelope at the trusted community and comparing an electronic signature of the SAML assertion to an electronic signature for the source community that is registered with the intermediary community;

obtaining a SAML assertion corresponding to the intermediary community;

packaging the intermediary SAML assertion with the envelope in an annotated envelope; and

forwarding the annotated envelope.

26. The method of claim 25, wherein the receiving, obtaining, packaging and forwarding steps of claim 25 are repeated at more than one intermediary community.

27. The method of claim 26, wherein only one intermediary SAML assertion is conveyed with the annotated envelope.

28. The method of claim 26, further including:

receiving the envelope at the destination;

comparing an electronic signature of the SAML assertion of the intermediary community to an electronic signature for the intermediary community that is registered with the destination community;

comparing an electronic signature of the SAML assertion of the source community to an electronic signature for the source community that is registered with the destination community; and

determining from a destination community registry that the source community is trusted to send electronic commerce documents.

29. A method to securely receive an electronic commerce document from a source at a destination, between source and destination communities, comprising:

providing a description of supported security protocols that the source or the source community may use;

receiving an envelope from the source, the envelope comprising an electronic commerce document and a SAML assertion;

comparing an electronic signature of the SAML assertion to an electronic signature for the source community that is registered with the destination community; and

determining from a destination community registry that the source community is trusted to send electronic commerce documents.

30. The method of claim 29, further including:

receiving the envelope from the source via at least intermediary community, the envelope further comprising a SAML assertion of the intermediary community; and

comparing an electronic signature of the SAML assertion of the intermediary community to an electronic signature for the intermediary community that is registered with the destination community.

31. A method to securely transmit an electronic commerce document from a source to a destination, between source and destination communities via an envelope translation gateway, comprising:

determining a security policy mutually acceptable to the source and destination communities;

authenticating the source to a first security service;

receiving a first assertion from the first security service;

computing a route through a trusted gateway to the destination via trusted connectors;

wherein the trusted gateway includes one or more services to validate the first security credential, to decrypt the electronic commerce document and re-encrypt it, to translate a first envelope protocol to a second envelope protocol, and to forward a second security credential with the electronic commerce document according to the second envelope protocol;

forwarding the first assertion and the electronic commerce document according to the first envelope protocol via the route to the destination.

32. The method of claim 31, further including:

receiving the envelope from the trusted gateway;

comparing the second security credential to an electronic signature for the trusted gateway that is registered with the destination community; and

determining from a destination community registry that the trusted gateway and the source community are trusted to send electronic commerce documents.

33. The method of claim 31, wherein authenticating the source includes:

providing a registry entry that authorizes an intermediate connector to authenticate the source to the first security service; and

invoking the intermediate connector, from the source, to authenticate with the first security service on behalf of the source.

34. The method of claim 32, wherein authenticating the source includes:

providing a registry entry that authorizes an intermediate connector to authenticate the source to the first security service; and

invoking the intermediate connector, from the source, to authenticate with the first security service on behalf of the source.

35. The method of claim 31, wherein the route includes a list of trusted connectors through which the electronic document passes, between the source and the destination.

36. The method of claim 32, wherein the route includes a list of trusted connectors through which the electronic document passes, between the source and the destination.

37. A method to securely receive an electronic commerce document from a source at a destination, between source and destination communities via an envelope translation gateway, comprising:

providing a description of supported security protocols that the source or the source community may use;

receiving an envelope from a trusted gateway, via trusted connectors, the envelope comprising an electronic commerce document from the source community and a second security credential;

wherein the trusted gateway includes one or more services to validate a first security credential from the source community, to decrypt the electronic commerce document and re-encrypt it, to translate a first envelope protocol to a second envelope protocol, and to forward the second security credential with the electronic commerce document according to the second envelope protocol;

comparing an electronic signature of the second security credential to an electronic signature for the trusted gateway that is registered with the destination community; and

determining from a destination community registry that the trusted gateway and the source community are trusted to send electronic commerce documents.

38. A method of establishing a network of commerce communities, a commerce community having a local registry and at least one service available to other commerce communities, the method including:

registering an operating arrangement, external port configurations and addresses, and security credentials in the local registries of at least two commerce communities;

establishing at least one global yellow pages service that exposes reference to services of the commerce communities in the network to members of the network;

establishing at least one global white pages including details of the services of the commerce communities, and the external port configurations and addresses of the commerce communities.

39. The method of claim 38, wherein the global yellow pages service is implemented according to a UDDI standard.

40. The method of claim 38, wherein the global yellow pages are hosted by a host community in the network of communities and a new community can join the network of communities, and become able to discover references to services from the global yellow pages service and able to access details of the services from the global white pages by exchanging with the host community an operating arrangement, external port configurations and addresses, and security credentials.